web scraper order;web scraper start url;titre;auteurs;lieu de publication-annee-maison d'edition;pays de publication;résumé;nombre_citation;nombre_versions;link_article;link_article_href;text;meta;page_article
1619094595-882;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;The distinction between fixed and random generators in group-based assumptions;J Bartusek, F Ma, M Zhandry ; Annual International Cryptology Conference, 2019  Springer;;"… give a generic group proof for the security of fixed-generator, low-entropy DDH (Canetti, Crypto

1997) … original motivation for studying point obfuscation was to realize useful properties of random

oracles [4] in … If \(H(\cdot )\) is a random oracle, observe that H(x) is a secure point …";Cité 10 fois;Les 5 versions;[PDF] iacr.org;https://eprint.iacr.org/2019/202.pdf;"
The Distinction Between Fixed and Random Generators in

Group-Based Assumptions

James Bartusek∗ Fermi Ma† Mark Zhandry‡

Princeton University

Abstract

There is surprisingly little consensus on the precise role of the generator g in group-based assumptions
such as DDH. Some works consider g to be a fixed part of the group description, while others take it to
be random. We study this subtle distinction from a number of angles.

• In the generic group model, we demonstrate the plausibility of groups in which random-generator
DDH (resp. CDH) is hard but fixed-generator DDH (resp. CDH) is easy. We observe that such
groups have interesting cryptographic applications.

• We find that seemingly tight generic lower bounds for the Discrete-Log and CDH problems with
preprocessing (Corrigan-Gibbs and Kogan, Eurocrypt 2018) are not tight in the sub-constant success
probability regime if the generator is random. We resolve this by proving tight lower bounds for
the random generator variants; our results formalize the intuition that using a random generator
will reduce the effectiveness of preprocessing attacks.

• We observe that DDH-like assumptions in which exponents are drawn from low-entropy distributions
are particularly sensitive to the fixed- vs. random-generator distinction. Most notably, we discover
that the Strong Power DDH assumption of Komargodski and Yogev (Komargodski and Yogev,
Eurocrypt 2018) used for non-malleable point obfuscation is in fact false precisely because it requires
a fixed generator. In response, we formulate an alternative fixed-generator assumption that suffices
for a new construction of non-malleable point obfuscation, and we prove the assumption holds in
the generic group model. We also give a generic group proof for the security of fixed-generator,
low-entropy DDH (Canetti, Crypto 1997).

1 Introduction

Starting with the seminal work of Diffie and Hellman [DH76], the Computational Diffie-Hellman (CDH)
assumption in certain cyclic groups has become a core pillar of modern cryptography. For a finite cyclic
group G and generator g, the assumption holds if it is hard to compute gab given (g, ga, gb) for random
a, b. The corresponding Decisional Diffie-Hellman (DDH) assumption, introduced by Brands [Bra94], is
that given (g, ga, gb) for random a, b, it is hard to distinguish gab from gc for random c.

A somewhat subtle issue is the precise role of g in these assumptions: is it fixed in the group description,
or is it randomly chosen along with a and b? For CDH in groups where the totient of the order is known,
a folklore equivalence between the fixed and random generator variants exists (e.g. see Chapter 21 of
Galbraith’s textbook [Gal12]). For DDH, Shoup [Sho99] observed that the fixed generator assumption
appears to be a stronger assumption than the random generator version, though a formal separation between

∗bartusek.james@gmail.com.
†fermima1@gmail.com.
‡mzhandry@princeton.edu.

1



the two is unknown. Despite this apparent distinction, the cryptographic literature commonly refers to both
the fixed and random generator variants simply as “DDH”.1

A likely explanation for this practice is that in most applications of cryptographic groups, it is straight-
forward to switch between fixed and random generators. For example, in ElGamal encryption [ElG84], users
who want the additional security of random-generator DDH can easily specify a random generator in their
public key.

Sadeghi and Steiner [SS01] observed that this justification does not apply in settings where the choice
of group generator is left to a potentially untrusted party.2 They give the example of a bank that offers
its customers an anonymous payment system, claiming provable security under group-based assumptions.
If the bank is free to choose parameters such as the group generator, then for security it is crucial that
any underlying assumptions hold in their (stronger) fixed generator form. While Sadeghi and Steiner did
not point to specific assumptions that can be broken simply by fixing the group generator, they stressed
that continuing to conflate these distinct assumptions could lead to serious ambiguities and mistakes in the
future.

In the nearly two decades since Sadeghi and Steiner [SS01] first called attention to the above issue,
dozens of new and increasingly sophisticated group-based assumptions have been introduced. Accordingly,
researchers have devoted significant effort to evaluating the plausibility of these assumptions (e.g. [BFF+14,
DHZ14]), frequently in idealized models such as the generic group model [Nec94, Sho97, Mau05]. We
observe that these generic group justifications generally ignore the question of whether the generator is
fixed or random, but that in most cases this distinction does not seem to affect real world security of these
assumptions.

In this work, however, we will see that this is not always the case.

1.1 Our Results

We first examine how the fixed vs. random generator distinction affects the classical Discrete-Log, CDH,
and DDH problems in a variety of different settings, obtaining the following results:

• Generic Separations for CDH and DDH. We prove that fixed- and random-generator DDH are
inequivalent assumptions in the generic group model [Nec94, Sho97, Mau05]. We show that for groups
of unknown order, fixed- and random-generator CDH are also inequivalent assumptions in the generic
group model. In addition, we give evidence (relying on a new assumption about arithmetic circuits)
that they are inequivalent even if the group order is known but its factorization is not.3

• Split-CDH and Split-DDH Groups. We define Split-CDH (resp. Split-DDH) groups for which
the fixed-generator variant of CDH (resp. DDH) is easy but the random-generator variant is hard,
and we observe that such groups imply interesting cryptographic applications. A split-CDH group
can be turned into a self-bilinear map [YYHK14, KKS15] where the random-generator variant of
the Multilinear CDH assumption holds. This implies powerful primitives such as multiparty non-
interactive key agreement (with trusted setup).4 A split-DDH group can be used to instantiate a
variant of the Boneh-Franklin identity-based encryption [BF01] scheme. We stress here that giving
candidate constructions of these groups is outside of the scope of this work. On the negative side,
we prove that a natural class of non-interactive key exchange protocols (without trusted setup) are
insecure in certain split-CDH groups.

1For example, the Katz-Lindell textbook [KL] defines DDH with a fixed generator, while Cramer-Shoup [CS98] defines DDH
with a random generator.

2Sadeghi and Steiner [SS01] actually consider the more general possibility of the untrusted party choosing the group itself
maliciously. This question is beyond the scope of our work, but in many cases it is an equally important consideration.

3This inequivalence was also suggested by Saxena and Soh [SS06].
4A similar observation was also made in [SS06].

2



• Asymptotic Bounds for Discrete-Log and CDH with Preprocessing. We revisit the recent
work of Corrigan-Gibbs and Kogan [CK18], which seemingly resolves the generic hardness of Discrete-
Log and CDH with preprocessing. We observe that while their lower bounds are tight for the fixed-
generator variants, they leave a gap in the random-generator setting for algorithms with sub-constant
success probability. We close these gaps by proving tight lower bounds for the random-generator
variants. Our bounds suggest that using a random generator can reduce the impact of preprocessing
attacks, and in turn group parameters can be set more aggressively than previously thought in situations
where random-generator Discrete-Log or CDH are sufficient.

Next, we turn our attention to the class of Diffie-Hellman-like assumptions involving non-uniform random
exponents. An example of such an assumption is Canetti’s “DDH-II” assumption [Can97], which states that
DDH remains hard even if the exponent a in (g, ga, gb, gab) is drawn from a well-spread distribution (so
that a has super-logarithmic min-entropy). While these assumptions are somewhat undesirable due to their
non-standard nature [GK16], Wee [Wee05] showed that these assumptions (ones that require hardness given
only super-logarithmic entropy) are necessary for applications such as point-function obfuscation.

Before we rely on such assumptions, it is important to rule out idealized adversaries that attack the
underlying structure of the assumption. The most common technique for achieving this is to prove the
assumption holds in the generic group model [Nec94, Sho97, Mau05]. Such proofs certainly do not imply
the validity of the assumption; instead, these proofs are generally viewed as a minimal level of guarantee we
need to gain confidence in an assumption [BFF+14].

Our central focus is on the recently proposed “Strong Power DDH” assumption of Komargodski and
Yogev [KY18a]. The assumption states that for x sampled from any arbitrary well-spread distribution D,

that gx, gx
2

, . . . , gx
k

is indistinguishable from k uniformly random group elements. Our results are the
following:

• Strong Power DDH is False for a Fixed Generator. We demonstrate the “Strong Power DDH”
assumption underlying Komargodski and Yogev’s non-malleable point obfuscator [KY18a] as well as
Fenteany and Fuller’s non-malleable digital locker [FF18] is false in the fixed-generator setting. This
results from a subtle issue in the order of quantifiers; if g is fixed, an arbitrary well-spread distri-
bution could depend on g. For example, x can come from the distribution that conditions on the
bit-representation of gx beginning with 0. Unfortunately, these constructions can only be instantiated
with a fixed generator, so the original security proofs in [KY18a] and [FF18] must rely on a false
assumption.5,6

In response to private communication from the authors of this work, Komargodski and Yogev have
offered a simple fix [KY18b] for their original construction through a new “Entropic Power DDH”
assumption.7 This new assumption suffices for non-malleable point obfuscation and is formulated
precisely to address the vulnerability described above.

• Fixing Non-Malleable Point Obfuscation and Justifying Assumptions in the Generic
Group Model. In this work, we offer an alternative resolution. We construct a new non-malleable
point obfuscator that is qualitatively different from the one in [KY18a]. Security of our construction
relies on a newly formulated fixed-generator entropic assumption that we prove holds in the generic
group model. Note that neither the Strong Power DDH Assumption [KY18a] nor the revised Entropic
Power DDH Assumption [KY18b] come with generic group proofs of security.

5Relying on a random generator would require a common random string, which is not the model considered in [KY18a] or
in the version of [FF18] dated Jan 30, 2019 at eprint.iacr.org/2018/957/20190130:190441.

6This issue appears in the Eurocrypt 2018 version of [KY18a], in an older ePrint version of [KY18b] dated May
1, 2018 at eprint.iacr.org/2018/149/20180211:142746, and in the ePrint version of [FF18] dated Jan 30, 2019 at
eprint.iacr.org/2018/957/20190130:190441.

7This refers to the newer ePrint version of [KY18b] dated Feb 21, 2019 available at
https://eprint.iacr.org/2018/149/20190221:133556.

3

https://eprint.iacr.org/2018/957/20190130:190441
https://eprint.iacr.org/2018/149/20180211:142746
https://eprint.iacr.org/2018/957/20190130:190441
https://eprint.iacr.org/2018/149/20190221:133556


Along the way, we develop general techniques (based heavily on [CDG18]) for proving generic security
of non-standard, entropic assumptions. As a final contribution, we demonstrate the applicability
of these techniques by showing that the fixed- and random-generator versions of Canetti’s DDH-II
assumption [Can97] hold in the generic group model.8 This assumption has been used in both its
fixed-generator form (e.g. [KLRZ08, CD08, DHZ14]) and random-generator form (e.g. [Can97, BC10]).

1.2 Reader’s Guide

Our contributions (and the following technical overview) are divided into 4 parts.

• Part 1 is collection of generic-group-based results that explore the fixed- or random-generator distinc-
tion for Discrete-Log, CDH, and DDH. We also describe our new split-CDH and split-DDH groups.
These results are contained in Section 3.

• Part 2 is a discussion on the negative implications of the fixed- or random-generator distinction, with
a focus on trusted set-up in Diffie-Hellman Key Exchange. The key technical result in this section
is a black-box separation between random-generator CDH and a natural class of non-interactive key
exchange protocols. This part is in Section 4.

• Part 3 considers the problem of generic algorithms with preprocessing in the random-generator setting.
Our lower bound for random-generator Discrete-Log and CDH is in Section 5.

• Part 4 studies the problem of non-malleable point obfuscation. We give our construction and prove
security under a new assumption in Section 6. We justify our new assumption with a generic group
model proof in Section 7. Our generic group model proof for DDH-II can be found in Section 7.3.

We encourage any readers interested in non-malleable point obfuscation or generic group proof techniques
to first read Part 4 in the following technical overview before visiting the proofs in Section 6, Section 7, and
Section 7.3.

1.3 Technical Overview

1.3.1 Part 1: Generic Separations and Split Groups.

Formalizing the Distinction. We will assume some process for generating a group description G of
order N . This group description is assumed to include a generator g. The fixed-generator DDH assumption,
or f-DDH, states that the tuples (gx, gy, gxy) and (gx, gy, gz) are computationally indistinguishable, given
the description of G. Here, x, y, z are chosen randomly in ZN . On the other hand, the random-generator
DDH assumption, or r-DDH, states that the tuples (h, hx, hy, hxy) and (h, hx, hy, hz) are computationally
indistinguishable. Here, x, y, z are chosen randomly in ZN , and h is a random generator of G (chosen,
say, by setting h = gr for a random r in Z∗N ). We can also define fixed- and random-generator variants
of Computational Diffie-Hellman (CDH) and Discrete-Log (DLog). For example, f-CDH states that given
(gx, gy) for random x, y, it is computationally infeasible to find gxy.

We consider the following three settings of groups: known prime group order, known composite group
order of unknown factorization, and unknown group order. For each of the three assumptions and three
settings (for 9 instances in total) we explore the relationship between the fixed- and random-generator
variants. Trivially, the f- variants of the assumptions are at least as strong as the r- variants. In the other
direction, some instances have known or folklore reductions showing equivalence [Gal12]. For each of the
cases that do not have a proof of equivalence, we provide a separation. This is formalized by augmenting
the generic group model [Sho97] with an oracle for the f- variant, and showing (potentially under reasonable
computational assumptions) that the r- variant still holds. Table 1 summarizes our findings.

8Previously, such proofs had been obtained by Bitanksy and Canetti [BC10] and Damg̊ard, Hazay, and Zottarel [DHZ14],
who considered the random- and fixed-generator versions, respectively. We observe that both of these proofs treat the well-
spread distribution as independent of the generic group labeling. Our proof handles distributions with arbitrary dependence on
the labels; for more discussion refer to Part 4 of Section 1.3.

4



DLog CDH DDH
Known Order X X ×

(FL/Lemma 5) (FL) (Theorem 2)
Unknown Factorization X ×? ×

(FL/Lemma 5) (Theorem 4) (Theorem 2)
Unknown order X ×? ×

(FL/Lemma 5) ([YYHK18]/Theorem 3) (Theorem 2)

Table 1: Generic equivalences and separations. FL denotes a folklore result. X means that the fixed and
random generator versions are equivalent. × means that the random generator version is harder than the
fixed generator version (in the generic model). ×? means the result holds under a plausible conjecture.

Applications of Split Groups. Looking at Table 1, we see that in the case of DDH, there is the potential
for a group where f-DDH is easy but r-DDH is hard. We will call such groups split-DDH groups. Similarly,
if the group order is unknown, potentially f-CDH is easy but r-CDH is hard; we call such groups split-
CDH groups. In this section, we will see that such split Diffie-Hellman groups have useful cryptographic
applications.

First, we observe that a split-CDH group is very close to a self-bilinear map [YYHK14]. A self-bilinear
map is a group G together with a pairing e : G2 → G such that e(gx, gy) = e(g, g)xy. Let g1 = g and
gn = e(g, gn−1). A typical computational assumption on self-bilinear maps would be the multilinear CDH

assumption [BS02]: for any n > 1, given gx0 , . . . , gxn , it is hard to compute g
∏n
i=0 xi

n . Notice that by applying

the mapping e(¡, ¡), it is only possible to compute g
∏n
i=0 xi

n+1 .
An f-CDH oracle gives such an oracle where e(g, g) = g. Therefore, a split-CDH group gives all the

functionality of a self-bilinear map. But notice that since e(g, g) = g, gn = g for any n. Therefore, the
multilinear CDH assumption is false. However, we observe that if we choose a random element h, then
e(h, h) = hr where h = gr. As such, the f-CDH oracle would also give a self-bilinear map with respect to the
random generator h. We then show that multilinear CDH is actually hard relative to h, assuming r-CDH is
hard. Thus, we obtain a self-bilinear map from any split-CDH group. As a consequence, following [YYHK14]
we would immediately obtain multiparty non-interactive key agreement, broadcast encryption satisfying a
distributed setup notion [BZ14], and attribute-based encryption for circuits.

In Section 3.2 we show that Split-DDH groups allow for a simple identity-based encryption (IBE) scheme
based on the Boneh-Franklin [BF01] construction.

Our results above demonstrate that finding groups where f- and r- assumptions are separated yields
interesting applications. In the next part, we discuss the negative implications of differing hardness between
f- and r- assumptions.

1.3.2 Part 2: Trusted Setup Assumptions

The previous sections demonstrated that the f- and r-DDH assumptions are distinct assumptions that may
not both be true. But then which DDH assumption should be used? In practice, g is typically part of a
standards library chosen by a trusted third party (e.g. NIST). As such, users have essentially three choices:

1. Believe that the trusted third party chose g at random, and use the r-DDH assumption.

2. Do not trust the third party, but instead assume that there are no bad g. In other words, rely on the
f-DDH assumption for g.

3. Do not trust the third party, but instead have one of the users generate a random g and distribute it
to everyone else. Then rely on r-DDH.

Option 1 means that users need to trust that no one could have subverted g and chosen a bad generator
for which DDH is actually easy; history has shown such trust could very well be misplaced. Only Options 2
and 3 remove the need to trust a third party.

5



Remark 1. Note that to remove trusted setup assumptions entirely, we would need to ensure that G itself is
guaranteed to satisfy f-DDH. One option is to assume that both G and g were generated by a deterministic
process, so that all parties can calculate G, g for themselves without any setup. For groups based on finite
fields, this requires deterministically generating large primes; while no polynomial-time provable algorithms
are known, there are very simple heuristic algorithms. For elliptic curve-based groups, other options are
available (e.g. using a field with small characteristic). For one approach to deterministic curve generation,
see [BCLN16].

In most cases, it is straightforward to switch between Options 2 and 3. A scheme designed for f-DDH can
often be converted into a scheme that relies only on r-DDH by having one of the parties choose a random
generator. On the other hand, a scheme designed for r-DDH can often be converted into an f-DDH scheme
by fixing a group element and not including it with the user’s messages, saving slightly on transmission costs.

The above means slightly different parameter sizes for the two assumptions. For example, for public key
schemes, the extra group element would naturally go in the public key. The result is that schemes secure
under r-DDH naturally require one additional group element in the public key relative to the f-DDH analog.
As authors often compare parameter sizes in terms of group elements (e.g. [Fuj16]), it is important that they
clearly identify which assumption is used.

In some cases, however, switching between f-DDH and r-DDH will have a more profound impact. For
example, in a protocol between mutually distrusting parties, which party will be entrusted to come up with
the generator? While we are not aware of any instances of protocols in the literature that cannot be made to
work with a random generator, it is straightforward to devise protocols where no single party can be trusted
to choose the generator. As such, care must be taken when using the r-DDH assumption in these settings.

Diffie-Hellman Key Exchange. For the remainder of this section, we will focus on a concrete setting
where it is not possible to trivially switch between f-DDH and r-DDH: Diffie-Hellman key exchange. In
the protocol, Alice chooses a random a ← ZN and computes A = ga, and Bob chooses a random b ← ZN
and computes B = gb. Then the two parties exchange A,B. In most treatments, Diffie-Hellman is a non-
interactive key exchange (NIKE), which means that A and B are sent simultaneously. Alice then computes
the secret key K = gab = Ba and Bob computes K = gab = Ab. By the DDH assumption, an eavesdropper
who learns A,B can learn nothing about K.

The key issue here is that Alice and Bob need to know g in order to generate their first message. So if we
want one of them, say Alice, to come up with the generator, the result is an interactive protocol with Alice
sending the first message, and only then can Bob send his. Therefore, in addition to requiring slightly more
communication, Option 3 actually changes the nature of the protocol. What we see is that Diffie-Hellman
can only remain a setupless NIKE under the f-DDH assumption.

Now, it is possible to alter Diffie-Hellman to work with CDH by extracting hardcore bits from the
unpredictable key. By the equivalence of f-CDH and r-CDH in known prime-order groups, we can obtain
a setupless NIKE protocol from r-CDH (and hence also r-DDH). In groups of unknown order, however,
this does not apply. As our main technical result from this section, we give evidence that in groups where
the totient of the order is unknown, r-CDH alone is insufficient for constructing setupless NIKE. This is
formalized by assuming that f-CDH is easy and demonstrating an attack on a wide class of key agreement
protocols that generalize the classical Diffie-Hellman protocol.

1.3.3 Part 3: Random-Generator Discrete-Log and CDH with Preprocessing.

A recent line of works [Mih, LCH11, BL13, CK18, CDG18] have explored non-uniform attacks on various
problems in cryptographic groups. Here, a computationally expensive offline pre-processing stage generates
an advice string, which in a later online stage can be used to speed up computation in the group. We are
interested in the relationship between the length S of the advice string, the running time T of the online
stage, the group order N , and the success probability Îľ.

6



Very recently, Corrigan-Gibbs and Kogan [CK18] seemingly resolve the non-uniform hardness of the

discrete logarithm problem. Namely, they show in the generic group model that ξ = Õ(ST 2/N), where the

Õ hides logarithmic factors. This matches known upper bounds (attacks) up to logarithmic factors.
However, all the works in this line (both lower bounds and attacks) only consider the fixed generator

version of discrete log. Corrigan-Gibbs and Kogan briefly mention this, concluding that “using a fixed
generator is essentially without loss of generality” since a discrete log with respect to one generator can be
solved by solving two discrete logs with respect to a different generator.

When considering just polynomial reductions between problems, the above is certainly true. However,
when it comes to precisely quantifying hardness, the problem no longer remains identical for different gener-
ators. In particular, suppose we have an algorithm that solves discrete log with respect to generator g with
probability Îľ and we want to solve a discrete log instance with respect to generator h = gr. To do so, on
input hx, we apply the algorithm twice to find the discrete logs of h and hx with respect to g. This gives r
and rx, allowing us to solve for x. But since we needed to solve both instances correctly, our overall success
probability is only Îľ2. Of course if Îľ is a constant so is Îľ2, but in the low success probability regime, squaring
the advantage significantly changes the hardness of the problem.

We resolve the question of the hardness of random-generator discrete log in the pre-processing setting,

showing that ξ = Θ̃
(
T 2

N + S2T 4

N2

)
. The attack side is simple: there are two natural ways to attack a

random-generator discrete log instance h, hx. One is to ignore the pre-processing, and apply the Baby-step

Giant-step algorithm, with success Ω(T
2

N ). The other is to use the pre-processing to solve two discrete log

instances relative to some fixed generator g, in the manner described above. This gives success Ω((ST
2

N )2),
as shown in [CK18]. By choosing which algorithm to use based on the parameters S, T,N , one obtains

ε = Ω
(
T 2

N + S2T 4

N2

)
.

On the other hand, to prove the lower bound we need to show, essentially, that the two algorithms above
are the only possible algorithms. This does not follow from the analysis of [CK18]. Instead, we use the tools
developed in subsequent works [CDGS18, CDG18] (based on the earlier pre-sampling techniques developed
by Unruh [Unr07] for the Random Oracle model) to switch to a “bit-fixing” model, where we then show
the optimality of the algorithms. In addition, we show that the same relationship holds as well for r-CDH.
Generically, auxiliary input r-CDH is as hard as either using the auxiliary information to solve two discrete
logarithms, or ignoring the input and solving one discrete logarithm.

1.4 Part 4: Low-Entropy Fixed-Generator Assumptions

Background: Point Obfuscation from Low-Entropy Assumptions. Our discussion thus far has
focused on Discrete Log/Diffie-Hellman-type assumptions where ga, gb are uniformly random group elements.
However, the security of many important cryptographic applications often relies on a stronger version of these
assumptions in which a and/or b might not be drawn uniformly at random.

Canetti’s construction of point function obfuscation is perhaps the most well-known example.9 A point
function fx(¡) is a boolean function that accepts on x and rejects on all other inputs. Roughly speaking, an
obfuscated point function O(fx(¡)) implements the same input/output functionality as fx(¡), but leaks no
information about x beyond what can be learned through black-box oracle queries to fx(¡). In other words,
the obfuscated program acts as a virtual black box for evaluating the function.10 Canetti’s point function
obfuscator is simple: to obfuscate fx(¡), draw a random group element gb and output (gb, gxb). Evaluation
on input y is done by computing (gb)y and accepting if it matches gxb.

The security of this construction follows from an assumption Canetti refers to as DHI-II (in subsequent
works it has been renamed to “DDH-II”; we will adopt this name), which states that (g, ga, gb, gab) ≈C
(g, ga, gb, gc) where g is a random generator, b, c are chosen uniformly at random, and a has super-logarithmic

9Canetti’s results [Can97] were originally described in the language of “oracle hashing”; the equivalence to point function
obfuscation was later pointed out by Wee [Wee05]. We describe Canetti’s results in Wee’s terminology.

10We defer a more detailed discussion on virtual-black-box obfuscation to [BGI+01] (see [Wee05] for specifics on point function
obfuscation).

7



min-entropy, i.e. it is sampled from a well-spread distribution D. We stress that DDH-II is technically an
infinite family of assumptions, since it requires indistinguishability if D is any well-spread distribution (even
ones that are not efficiently sampleable).

Under DDH-II, the obfuscated program (gb, gxb) hides all information about the point x as long as x is
drawn from a well-spread distribution, since gxb is indistinguishable from gc. This immediately implies a
notion of average-case virtual-black-box (VBB) security. Canetti proves that if a point function obfuscator
is average-case VBB for any well-spread distribution, this implies full (worst-case) VBB security. It was
later shown by Wee ([Wee05], Section 4.2) that Canetti’s approach is essentially inherent: VBB-secure point
function obfuscation requires strong assumptions that are hard for any well-spread distribution.

Background: Non-Malleable Point Obfuscation. Canetti’s original motivation for studying point ob-
fuscation was to realize useful properties of random oracles [BR93] in the standard model. If H(¡) is a random
oracle, observe that H(x) is a secure point obfuscation of fx(¡), where evaluation is a single random oracle
call followed by a comparison. Komargodski and Yogev [KY18a] observe that the random oracle obfuscator
H(x) satisfies a strong non-malleability property, in the sense that given H(x) it is impossible to compute
H(f(x)) for any (meaningfully) related point f(x), without first recovering x. This property is missing from
Canetti’s point obfuscator [Can97], e.g. since given (gb, gxb), one can easily compute (gb, g(x+1)b), which is
an obfuscation of the related point f(x) = x+ 1.

Komargodski and Yogev [KY18a] propose the following modification to Canetti’s point obfuscator. To

obfuscate the point x, sample a random b and output (gb, (gb)g
x4+x3+x2+x

). Note that for this expression to

make sense, gx
4+x3+x2+x must be mapped back into the exponent space under some fixed public mapping.

Evaluation on input y is done by computing gy
4+y3+y2+y, mapping this element back to the exponent space

and raising gb to that power, and finally comparing to (gb)g
x4+x3+x2+x

.
Komargodski and Yogev [KY18a] argue their obfuscation resists bounded-degree polynomial mauling

attacks, in which an adversary given an obfuscation of x attempts to produce an obfuscation of P (x) for some
bounded-degree polynomial P (¡). Roughly, the intuition is that the adversary cannot replace gb with any

other gb
′
, since generating (gb

′
)g
P (x)

does not appear possible given only (gb)g
x4+x3+x2+x

. But if the adversary
cannot change gb, the argument is that the linear constraints imposed by the form of x4 + x3 + x2 + x make
it impossible to replace x with P (x).

Formally, security in [KY18a] is proved under the newly introduced “Strong Power DDH” assumption,

which states it is hard to distinguish gx, gx
2

, . . . , gx
`

from ` random group elements, if x is drawn from any
well-spread distribution.

Fixed-Generator Strong Power DDH is False. In stating the assumption, Komargodski and Yo-
gev [KY18a] do not specify how g is chosen or the relationship between g and the distribution over x. We
observe that if g is a fixed generator, then their assumption is false. For a uniformly random group element,
there must be some bit in its description with noticeable entropy. If it is bit i, we let D be the distribution
over all points x such that the ith bit of the description of gx is 0. Then D has high min-entropy, and
moreover gx for x← D is distinguishable from a random group element by inspecting the ith bit.

If the assumption is taken in its random-generator formulation, the security proof in [KY18a] breaks
down, since an adversary can potentially replace g with a different generator g′. A natural idea to fix the
construction would be to generate g using a public source of randomness.11 However, this would move the
construction into the CRS model, where strong non-malleability results were previously known [CV09].

Fixin";"""date"",""2019-03-05T18:52:39Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2019-03-05T18:52:39Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017) kpathsea version 6.2.3""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2019-03-05T18:52:39Z""
""created"",""2019-03-05T18:52:39Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-03-05T18:52:39Z""
""resourceName"",""202.pdf""
""Author"",""""
""producer"",""pdfTeX-1.40.18""
""pdf:docinfo:producer"",""pdfTeX-1.40.18""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""7"",""1"",""14"",""5"",""0"",""0"",""14"",""0"",""23"",""7"",""5"",""6"",""13"",""39"",""72"",""148"",""19"",""27"",""17"",""4"",""41"",""8"",""47"",""19"",""23"",""20"",""29"",""32"",""29"",""32"",""39"",""0"",""0"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2019-03-05T18:52:39Z""
""Last-Modified"",""2019-03-05T18:52:39Z""
""dcterms:modified"",""2019-03-05T18:52:39Z""
""title"",""""
""Last-Save-Date"",""2019-03-05T18:52:39Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2019-03-05T18:52:39Z""
""meta:save-date"",""2019-03-05T18:52:39Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017) kpathsea version 6.2.3""
""Content-Length"",""644433""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""39""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""2475"",""3402"",""3689"",""3458"",""2958"",""3671"",""3929"",""3807"",""3991"",""3630"",""2841"",""3235"",""3081"",""2094"",""3406"",""3247"",""3128"",""3108"",""2470"",""3156"",""2777"",""2176"",""2496"",""2478"",""2735"",""2655"",""2187"",""2429"",""1831"",""2936"",""2283"",""2075"",""2790"",""2846"",""3098"",""2718"",""2783"",""2593"",""481""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-03-05T18:52:39Z""
";https://scholar.google.com/scholar?start=700&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094583-834;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Subverting decryption in AEAD;M Armour, B Poettering ; IMA International Conference on Cryptography …, 2019  Springer;;"… k_\mathsf {A}\) and has oracle access to both encryption and decryption oracles in the … associated

data were generated using the random.getrandbits method from the Crypto.Random library … The

expected number of calls to the transcript oracle for successful exfiltration is given …";Cité 6 fois;Les 5 versions;[PDF] royalholloway.ac.uk;https://pure.royalholloway.ac.uk/portal/files/35814548/main.pdf;"
Subverting Decryption in AEAD?

Marcel Armour1(B) and Bertram Poettering2[0000−0001−6525−5141]

1 Royal Holloway, University of London, Egham, UK
2 IBM Research – Zurich, Switzerland

marcel.armour.2017@rhul.ac.uk
poe@zurich.ibm.com

Abstract. This work introduces a new class of Algorithm Substitution
Attack (ASA) on Symmetric Encryption Schemes. ASAs were introduced
by Bellare, Paterson and Rogaway in light of revelations concerning mass
surveillance. An ASA replaces an encryption scheme with a subverted
version that aims to reveal information to an adversary engaged in mass
surveillance, while remaining undetected by users. Previous work posited
that a particular class of AEAD scheme (satisfying certain correctness
and uniqueness properties) is resilient against subversion. Many if not all
real-world constructions – such as GCM, CCM and OCB – are members
of this class. Our results stand in opposition to those prior results. We
present a potent ASA that generically applies to any AEAD scheme, is
undetectable in all previous frameworks and which achieves successful
exfiltration of user keys. We give even more efficient non-generic at-
tacks against a selection of AEAD implementations that are most used
in practice. In contrast to prior work, our new class of attack targets the
decryption algorithm rather than encryption. We argue that this attack
represents an attractive opportunity for a mass surveillance adversary.
Our work serves to refine the ASA model and contributes to a series of
papers that raises awareness and understanding about what is possible
with ASAs.

Keywords: Algorithm Substitution Attacks ¡ Privacy ¡ Symmetric Encryption
¡ Mass Surveillance

1 Introduction

The Snowden revelations in 2013 exposed that mass surveillance is a reality.
They also showed that even sophisticated adversaries with large resources have
been unable to break well established cryptographic primitives and hardness as-
sumptions, shifting their focus to circumventing cryptography. Together, these
? The research of Armour was supported by the EPSRC and the UK government
as part of the Centre for Doctoral Training in Cyber Security at Royal Holloway,
University of London (EP/P009301/1). The research of Poettering was supported by
the European Union’s Horizon 2020 project FutureTPM (779391). The full version
of this article is available at https://eprint.iacr.org/2019/987 [3].

https://eprint.iacr.org/2019/987


two facts suggest that the study of subverted implementations of cryptographic
primitives and protocols is a fruitful area of research; Rogaway has gone so far as
to call it a moral imperative [23]. The reader is referred to the survey by Schneier
et al. [28], which provides a broad overview of subversion of cryptography, with
some useful case studies. The idea that an adversary may embed a backdoor or
otherwise tamper with the implementation or specification of a cryptographic
scheme or primitive predates the Snowden revelations, and was initiated in a line
of work by Young and Yung that they named kleptography [30,31]. This area of
study can be traced back to Simmons’ work on subliminal channels, e.g. [29],
undertaken in the context of nuclear non-proliferation during the Cold War. In
the original conception, kleptography considered a saboteur who designs a cryp-
tographic algorithm whose outputs are computationally indistinguishable from
the outputs of an unmodified trusted algorithm. The saboteur’s algorithm should
leak private key data through the output of the system, which was achieved using
the same principles as Simmons’ earlier subliminal channels.

Preceding Work. Post-Snowden, work in this area was reignited by Bellare,
Paterson and Rogaway (BPR) [8], who formalised study of so-called algorithm
substitution attacks (ASAs) through the specific example of symmetric encryp-
tion schemes. In abstract terms, the adversary’s goal in an ASA is to create a
subverted implementation of a scheme that breaks some aspect of security (such
as IND-CPA) while remaining undetected by the user. There is a tension for ‘Big
Brother’ between mounting a successful attack and being detected; clearly an
attack that simply replaces the encryption algorithm with one that outputs the
messages in plaintext would be devastating yet trivially detectable. BPR stipu-
late that subverted schemes should at the very least decrypt correctly (according
to the unmodified specification) in order to have some measure of resistance to
detection, going on to define the success probability of a mass surveillance ad-
versary in carrying out a successful attack, as well as the advantage of a user in
detecting that an attack is taking place. BPR [8] demonstrate an attack against
randomized schemes that relies on influencing the randomness generated in the
course of encryption. Their attack applies to a sub-class of randomized schemes
satisfying a property they call ‘coin-injectivity’. Lastly, BPR also establish a
positive result that shows that under certain assumptions, it is possible for au-
thenticated encryption schemes to provide resistance against subversion attacks.

Degabriele, Farshim and Poettering (DFP) [12] critiqued the definitions and
underlying assumptions of BPR. Their main insight is that perfect decryptability
—as mandated by BPR— is a very strong requirement and artificially limits the
adversary’s set of available strategies. In practice, a subversion with negligible
failure probability should be considered effectively correct.3 As DFP note, de-
cryption failures may happen for reasons other than subverted encryption, and if
they occur sporadically may easily go unnoticed. DFP demonstrate how this can
be achieved with an input-triggered subversion, where the trigger is some input
3 This is analogous to the fundamental notion in cryptography that a symmetric en-
cryption scheme be considered secure even in the presence of adversaries with neg-
ligible advantage.



(message, associated data, nonce, or a combination thereof) that is difficult to
guess, making detection practically impossible.

Bellare, Jaeger and Kane (BJK) [6] improved on the attack of BPR, giving
an attack which is effective against all randomized schemes. Whereas the attack
of BPR is stateful and so vulnerable to detection through state reset, the BJK
attack is stateless. BJK furthermore formalised that the desired outcome of an
ASA from the point of view of a mass surveillance adversary is successful key
recovery.

In concurrent work, we study the effects of subverting the receiver in the
setting of message authentication codes [1,2]. Using similar techniques as in the
current report, we provide ASAs that result in successful key exfiltration and
thus universal forgeries.

Contributions. Our work continues a line of investigation that serves to raise
awareness of what is possible with ASAs, and highlights the importance of work
countering subverted implementations. We consider ASAs from a new perspec-
tive that leads to results of practical importance. Recall that BPR established a
covert channel through ciphertexts by manipulating the randomness generation;
their model stipulated perfect decryptability, which resulted in their definitions
being fragile. DFP identified this and proposed tolerating a (minimal) compro-
mise of correctness, allowing trigger messages. We note that attacks employing
trigger messages appear trivial to plant in formal security abstractions like IND-
CPA where the adversary has full control over encrypted messages, associated
data, and nonces. In practice, however, it is certainly questionable that adver-
saries have enough influence on any of the three to conduct DFP style attacks, as
messages are chosen in special formats mandated by applications, nonces are im-
plemented via counters, etc. We remove these dependencies, complementing the
DFP approach, by attacking from a different angle: leaving perfect correctness
intact, we (minimally) limit ciphertext integrity and establish a covert chan-
nel through decryption error events. Concretely, we manipulate the decryption
algorithm to accept certain bogus ciphertexts. This requires the surveillance ad-
versary to be able to observe whether a decryption implementation outputs a
message or rejects the ciphertext. In many practical scenarios this is a mild as-
sumption, for example if a decryption error results in a packet being dropped
and automatically retransmitted. Furthermore, a subverted decryption algorithm
could go beyond this by e.g. influencing timing information in future messages
sent to the network. We conclude that this attack represents an attractive and
easy to implement opportunity for a mass surveillance adversary.

Our results stand in opposition to previous work [8,12,6] which proposed
subversion resilience of a large class of AEAD schemes to which many if not
all real-world constructions such as GCM, CCM and OCB belong, as long as
their nonces are generated deterministically via a shared state maintained by
both encryptor and decryptor.4 The key observation to resolve this apparent
contradiction is that previous work has assumed, besides explicitly spelled out
4 The members of this class of schemes are deterministic and satisfy certain technical
correctness and uniqueness properties.



requirements like uniqueness of ciphertexts and perfect decryptability, implicit
notions such as integrity of ciphertexts. In the ASA setting for AEAD where
undermining the confidentiality of a scheme is the key goal of an adversary, it
seems just as natural to assume that the adversary is also willing to compromise
the integrity guarantees as well.

Related Work. We outlined the key publications on ASAs against symmetric
encryption schemes above. Other works, briefly described here, consider subver-
sion on different primitives and in different contexts. Berndt and Liskiewicz [9]
reunite the fields of cryptography and steganography. Ateniese, Magri and Ven-
turi [4] study ASAs on signature schemes. In a series of work, Russell, Tang,
Yung and Zhou [24,25,26,27] consider ASAs on one-way functions, trapdoor one-
way functions and key generation as well as defending randomized algorithms
against ASAs. Goh, Boneh, Pinkas and Golle [18] show how to add key recovery
to the SSL/TLS and SSH protocols. Dodis, Ganesh, Golovnev, Juels and Ris-
tenpart [13] provide a formal treatment of backdooring PRGs, another form of
subversion. Armour and Poettering [1,2] study subversion options for message
authentication schemes (MAC). Cryptographic reverse firewalls [21,14,20] rep-
resent an architecture to counter ASAs via trusted code in network perimeter
filters. Fischlin and Mazaheri show how to construct ASA-resistant encryption
and signature algorithms given initial access to a trusted base scheme [17]. Fis-
chlin, Janson and Mazaheri [16] show how to immunize (keyed and unkeyed)
hash functions against subversion. Bellare, Kane and Rogaway [7] explore using
large keys to prevent key exfiltration in the symmetric encryption setting. Bel-
lare and Hoang [5] give public key encryption schemes that defend against the
subversion of random number generators.

Camenisch, Drijvers and Lehmann [11] consider Direct Anonymous Attesta-
tion (DAA) in the presence of a subverted Trusted Platform Module (TPM).
We note that subversion attacks on cryptographic primitives (on DAA, but just
as well on message authentication as considered in the present article) manifest
a major attack vector in particular against embedded cryptographic hardware
modules like TPMs. This is because the main goal of such modules is to serve
as a root of trust in exposed devices for which losing system integrity could be
fatal. Subverting a TPM can thus have severe implications. As TPMs are widely
available today, including for being embedded into virtually every modern PC,
subverting them seems to be a promising option to conduct mass surveillance.

Structure. We first recall (Sect. 2) standard definitions for symmetric encryp-
tion schemes and their security. We next give definitions (Sect. 3) that provide
a general framework in which to study ASAs. These have been refined and ex-
tended from prior work, crucially including the decryption oracle which had
been ignored by previous work. Sect. 4 details our new type of attack, together
with formal theorems quantifying the ability of an adversary to exfiltrate keys
and the ability of the subversion to go undetected. We give two versions of our
ASA: one for a passive adversary (the adversarial model considered by previous
work), which we extend to a second ASA requiring an active trigger: a mod-
ified ciphertext provided to the decryption algorithm. We discuss the results



of a proof-of-concept implementation in Sect. 5. Lastly, Sect. 6 explains how
our attacks can be leveraged to compromise the security of popular practical
schemes even more effectively, demonstrating how powerful ASAs become when
conducted outside the clearly demarcated boundaries of a formal model. Con-
cretely, we give evidence that ASAs against standardized AEAD constructions
like GCM or OCB3 can be even more damaging than our attacks from Sect. 4.

2 Notation and Definitions

Notation. For a natural number k ∈ N, we let [k] = {0, 1, . . . , k − 1}. We refer
to an element x ∈ {0, 1}∗ as a string, and denote its length by |x|. By ε we
denote the empty string. The set of strings of length ` is denoted {0, 1}`. In
addition we denote by ⊥ /∈ {0, 1}∗ a reserved special symbol. For x ∈ {0, 1}∗,
we let x[i] denote the i-th bit of x, with the convention that we count from 0,
i.e., we have x = x[0] . . . x[|x|−1]. For two strings x, x′ we denote by x ‖ x′ their
concatenation. If S is a finite set, then s←$ S denotes choosing s uniformly at
random from S. If A is a randomized algorithm, we write y ←$ A(x) to indicate
that it is invoked on input x (and fresh random coins), and the result is assigned
to variable y. In security games we write AO1,...,Oc =⇒ 1 to denote the event
that the adversary outputs 1 after being given access to the c oracles.

In Appendix A, we recall standard definitions for (length-preserving) pseudo-
random functions and permutations.

2.1 Symmetric Encryption

We focus on the likely most widespread and practically useful encryption prim-
itive: Authenticated Encryption with Associated Data (AEAD). We recall stan-
dard definitions of (deterministic) nonce-based AEAD, as per [22].

AEAD. A symmetric encryption scheme Π providing authenticated encryption
with associated data is a triple of algorithms (Π.Gen,Π.Enc,Π.Dec). Associated
to Π are two parameters, Π.kl and Π.nl, representing the key length and the
nonce length. The key generation algorithm Π.Gen is a probabilistic algorithm
that takes as input the key length Π.kl and returns a key k ∈ {0, 1}Π.kl. Often
Π.Gen is taken as the algorithm choosing k uniformly at random from {0, 1}Π.kl.
The encryption algorithm Π.Enc is deterministic and takes key k, message m,
associated data d and nonce n ∈ {0, 1}Π.nl to deterministically obtain cipher-
text c ← Π.Enc(k,m, d;n). Decryption algorithm Π.Dec is deterministic and
Π.Dec(k, c, d;n) returns either a message m or the special symbol ⊥. For sim-
plicity, we assume that |Π.Enc(k,m, d;n)| is an affine function of the form |m|+τ
where τ is some constant associated to the encryption scheme (all practical en-
cryption schemes are of this type). We call τ the stretch of the encryption scheme.
Lastly, where the context is clear, we drop the prefix Π.



Definition 1. A symmetric encryption scheme Π is said to be δ-correct if for
all tuples (m, d;n) it holds that:

Pr [m 6= m′ | k ←$ Gen(kl), c← Enc(k,m, d;n),m′ ← Dec(k, c, d;n)] ≤ δ.

If δ = 0 the scheme is referred to as being perfectly correct.

The classic privacy notion used for AEAD is indistinguishability from ran-
dom bits under an adaptive chosen-plaintext-and-nonce attack, utilising stan-
dard game-based definitions. For the authenticity notion, we consider adversaries
that aim to create (strong) forgeries. Security notions are as in [22]. Intuitively,
the scheme provides confidentiality if the privacy advantage of any realistic ad-
versary is negligible and authenticity if the forging advantage of any realistic
adversary is negligible.

Definition 2. The privacy advantage of an adversary A is given by

Advpriv
Π (A) = Pr

[
AEnc(k,·,·;·) =⇒ 1 | k ←$ Gen(kl)

]
− Pr

[
A$(·,·;·) =⇒ 1

]
,

where the $ oracle returns c←$ {0, 1}|m|+τ for any query $(m, d;n). We assume
that A is nonce-respecting; that is, A does not make two queries with the same
nonce.

Definition 3. The authenticity advantage of an adversary A is given by

Advauth
Π (A) = Pr

[
AEnc(k,·,·;·),Dec(k,·,·;·) forges | k ←$ Gen(kl)

]
,

where we say that A forges if it receives any m′ 6= ⊥ from Dec where we require
that (c, d;n) is not the result of an encryption query (m, d;n). We assume that
A is nonce-respecting; that is, A does not make two encryption queries with the
same nonce.

3 ASAs on Symmetric Encryption Schemes

We now outline the framework which will allow us to describe our concrete
ASAs in Sect. 4. The aim of an ASA is to replace a given (symmetric encryption)
scheme with a compromised version; if the original scheme is denoted Π, we write
Π̃ for its subversion. The attacker may choose to replace one component of the
scheme, or multiple. We model the subverted scheme as having an embedded
attacker key which is shared with an external (mass surveillance) adversary.
This approach was first used by BPR [8]. From the attacker’s perspective, the
ASA should be undetectable by the user and result in effective surveillance.
We formalise these notions as detectability and key recovery. Our definitions are
inherited from prior work [8,6,12]. Whereas previous work assumed that only the
encryption algorithm might be subverted, we have generalised the definitions to
reflect the possibility that any component (one or multiple) of the symmetric



Game DetΠ,Π̃(D)
kA ←$ A.Gen
b←$ {0, 1}, b′ ←$ DOGen,OEnc,ODec

return (b = b′)

OGen(kl)
if (b = 1) then k ←$ Π.Gen(kl)
else k ←$ Π̃.Gen(kA, kl)
return k

OEnc(k,m, d;n)
if (b = 1) then c← Π.Enc(k,m, d;n)
else c← Π̃.Enc(kA, k,m, d;n)
return c

ODec(k, c, d;n)
if (b = 1) then m← Π.Dec(k, c, d;n)
else m← Π̃.Dec(kA, k, c, d;n)
return m

Fig. 1. Game to define the detectability advantage of D with respect to Π̃,Π.

encryption scheme could be subverted, and adapted to explicitly consider AEAD
schemes. We broadly follow the notational choices of BJK [6].

ASA Syntax. An algorithm substitution attack A on a scheme Π consists of a
triple (A.Gen,A.Ext, Π̃), where:

1. The attacker key generation algorithm A.Gen returns an attacker key kA ∈
{0, 1}A.kl for some constant A.kl.

2. Π̃ = (Π̃.Gen, Π̃.Enc, Π̃.Dec) is a subverted symmetric encryption scheme.
(a) The subverted key generation algorithm Π̃.Gen is a probabilistic algo-

rithm that takes as input the key length Π̃.kl and the attacker key kA,
returning a key k ∈ {0, 1}Π̃.kl.

(b) The subverted encryption algorithm Π̃.Enc takes the attacker key kA,
user key k, message m, associated data d and nonce n ∈ {0, 1}Π̃.nl, out-
putting ciphertext c← Π̃.Enc(kA, k,m, d;n).

(c) The subverted decryption algorithm Π̃.Dec(kA, k, c, d;n) returns either a
message m or the special symbol ⊥.

3. The key extraction algorithm A.Ext takes as input kA and has oracle access
to both encryption and decryption oracles in the case of an active adversary,
or to a transcript of ciphertexts in the case of a passive adversary. These
notions are formalised in the key recovery game in Fig. 2. The output of this
algorithm is a key k ∈ {0, 1}Π̃.kl.

We require that Π̃.kl = Π.kl and Π̃.nl = Π.nl, as the subverted algorithm would
otherwise be trivially detected. As in previous work, we assume throughout that
the key generation is unsubverted, but we retain a syntax that allows for the
more general case.

Detectability. In the formal notion of detectability, we allow a distinguisher D
to interact with subverted encryption, subverted decryption and (for generality)
subverted key generation. We assume that the distinguisher has access to its
own reference copy of the unsubverted algorithms. It wins if it can distinguish



between the base scheme and the subverted scheme in the game defined in Fig. 1.
The detectability advantage of D with respect to Π, Π̃ is given by

Advdet
Π,Π̃

(D) = 2 ¡ Pr
[
DetΠ,Π̃(D)

]
− 1.

This definition is adapted from strong undetectability of [6]. Notice that (infor-
mally) a ‘hard-to-detect’ subversion of a perfectly correct base scheme necessarily
satisfies some correctness condition. To see this, suppose that the subversion does
not satisfy δ-correctness: it is detectable with probability at least δ.

Key Recovery. Following [6], recovering the user’s secret key is a strong prop-
erty for an attacker. We give two flavours of the key recovery game, one for
passive adversaries PassiveKR and one for active adversaries ActiveKR, as given
in Fig. 2. In the passive case, we allow the adversary to observe ciphertexts and
whether they are rejected. This is formalised through the transcript oracleOTrans.
For the active case, we allow the attacker to generate valid ciphertexts via OEnc
and interact with a decryption oracle ODec that reveals whether a submitted
ciphertext is rejected. Both games are parametrised by a message sampler algo-
rithmM. Given its current state σ,M returns the next message with associated
data (m, d) to be encrypted, together with a nonce n ∈ {0, 1}Π.nl and an updated
state. It represents the choice of messages made by the sender. For simplicity,
we model M as non-adaptive and nonce-respecting. It could be argued that a
more realistic model might take into account that the adversary could influence
the user’s choice of messages to be encrypted. However, in constructing attacks
we assume the weakest properties of the attacker.

Adversary A wins if A.Ext recovers the user’s key k after interacting with the
subverted encryption scheme. The key recovery advantage of A with respect to
Π̃ andM is given by

Advkr
Π̃,M

(A) = Pr
[
KRΠ̃,M(A)

]
,

where KRΠ̃,M(A) refers to the appropriate key recovery game according to
whether the adversary is passive or active.

4 Mounting Attacks via Decryption Subversion

We now detail our ASAs, first for a passive surveillance adversary and then in the
active case. It is easy to see that the attacks are undetectable according to the
models in the literature [8,6,12], as the encryption algorithm is not subverted.

Imagine that Alice communicates with Bob. A passive adversary can observe
ciphertexts from Alice to Bob. In addition, an active adversary can replace ci-
phertexts in transmission and submit its own (forged) ciphertexts to Bob. In
the passive attack, the decryption algorithm is subverted so that it rejects a
fraction of valid ciphertexts, bounded by an attacker controlled parameter. In
the active attack, the decryption algorithm is subverted so that it accepts a
(similarly bounded) fraction of invalid ciphertexts. The active attack requires



Game ActiveKRΠ̃,M

kA ←$ A.Gen
k ←$ Π̃.Gen(Π̃.kl), σ ← ε
k′ ←$ A.ExtOEnc,ODec (kA)
return (k′ = k)

OEnc()
(m, d, n, σ)←$ M(σ)
c← Π̃.Enc(kA, k,m, d;n)
return (c, d, n)

ODec(c, d;n)
m← Π̃.Dec(kA, k, c, d;n)
return (m = ⊥)

Game PassiveKRΠ̃,M

kA ←$ A.Gen
k ←$ Π̃.Gen(Π̃.kl), σ ← ε
k′ ←$ A.ExtOTrans (kA),
return (k′ = k)

OTrans()
(m, d, n, σ)←$ M(σ)
c← Π̃.Enc(kA, k,m, d;n)
m← Π̃.Dec(kA, k, c, d;n)
return (c, d, n, (m = ⊥))

Fig. 2. Game to define the key recovery advantage of A with respect to Π̃ andM.

the adversary to send Bob bogus ciphertexts (derived from genuine ciphertexts)
that reveal Bob’s secret key using decryption errors. Normally, these bogus ci-
phertexts are unlikely to decrypt correctly, i.e., they would be rejected. In both
cases, if the decryptor is subverted then either real ciphertexts (in the passive
case) or bogus ciphertexts (in the active case) can either be accepted or rejected,
creating via the acceptance/rejection pattern a covert channel that will allow the
key to be exfiltrated.

From the point of view of a mass surveillance adversary this is an attractive
prospect: having passively collected all communications, triggered by some sus-
picion they can now target Alice and Bob’s communication. By recovering Bob’s
key they may now decrypt all of the stored communication between Alice and
Bob (and indeed from Bob to Alice as well).

We note that both of our attacks are stateless, which not only allows for much
easier backdoor implementation from a technical perspective but also should
decrease the likelihood that an implemented attack is detected through code
review or observing memory usage.

4.1 Attack 1: Passive

Consider the following subversion of a given symmetric encryption scheme
(Π.Gen,Π.Enc,Π.Dec). Let Π̃.Gen = Π.Gen and Π̃.Enc = Π.Enc. Let A.Gen
choose a key kA by kA ←$ {0, 1}A.kl. Algorithms Π̃.Dec and A.Ext are then spec-
ified in Fig. 3. The subverted decryptor Π̃.Dec takes the same input as Π.Dec
together with the attacker key, and utilises a pseudo-random function5 F with
F : {0, 1}A.kl×{0, 1}∗ → [Π.kl]×{0, 1}. In A.Ext, we use the symbol ? as a ternary
5 See Appendix A for definitions of pseudo-random functions and length-preserving
pseudo-random permutations.



Algorithm Π̃.Dec(kA, k, c, d;n)
1: parse F (kA, c ‖ d) as i ‖ b
2: if k[i] = b and B(δ) then
3: return ⊥
4: else
5: return Π.Dec(k, c, d;n)

Algorithm A.ExtOTrans (kA)
1: ∀i ∈ [Π.kl], key[i]← ?
2: while ∃j : key[j] = ? do
3: (c, d, v)← OTrans
4: if (v = 1) then
5: parse F (kA, c ‖ d) as i ‖ b
6: if (key[i] = ?) then
7: key[i]← b

8: return key

Fig. 3. Passive ASA against AEAD

symbol (neither 0 nor 1) to keep track of which key bits have been collected. In
line 2 of the algorithm for Π̃.Dec, we write B(δ) to denote a Bernoulli trial which
returns 1 with probability δ. Key extractor A.Ext takes as input the attacker key
and the transcript, consisting of triples (c, d, n, v) where v is a bit representing
whether or not the ciphertext decrypts to ⊥.

Theorem 1. Let Π be a perfectly-correct symmetric encryption scheme and let
` = Π.kl. Let Π̃.Dec and A.Ext be defined as in Fig. 3. Let M be a message
sampling algorithm, and F : {0, 1}A.kl × {0, 1}∗ → [`] × {0, 1} be a PRF with
Advprf

F (F) < Îľ for all efficient adversaries F . Then

(1) Advkr
Π̃,M

(A) ≥ 1− `e−
qδ
2` , where q is the number of queries that A.Ext makes

to the transcript oracle.
(2) For all distinguishers D, Advdet

Π,Π̃
(D) ≤ δq

2 (1 + Îľ) where D makes q queries
to its decryption oracle.

Proof of (1). We use a combinatorial argument. Notice that this is essentially
a coupon collection problem. We are looking for the probability that every key
bit has been exfiltrated. If we fix i key bits that are not exfiltrated, there are(
`
i

)
ways to choose those fixed key bits. The probability that (at least) i of the

key bits have not been exfiltrated is given by
(
`
i

)
(1 − iδ

2` )
q. Using the principle

of inclusion exclusion, the probability that no key bit has not been exfiltrated is
given by

Advkr
Π̃,M

(A) =
∑̀
i=0

(−1)i
(
`

i

)(
1− iδ

2`

)q
≥ 1− `

(
1− δ

2`

)q
≥ 1− `e−

qδ
2` . ut

Proof of (2). Clearly, the only way to distinguish between Π and Π̃ is to observe
Π̃.Dec output ⊥. Thus in order to distinguish, D must find (m, d;n) such that



⊥ = ODec(k, c, d;n) for c ← Π.Enc(k,m, d;n). This reduces to D finding some
c ‖ d such that F (kA, c ‖ d) = i ‖ k[i] for some index i. Call this event W . Notice
that for any F it holds that for all kA, c, d we have F (kA, c ‖ d) = i ‖ b for some
index i and bit b.

We note that Pr [W ] ≤ Pr [PRFF (F)] for all PRF adversaries F . If not, it
would be possible for F to act as a challenger to D and win its prf game whenever
W occurs. Thus,

Advdet
Π,Π̃

(D) = Pr
[
DetΠ,Π̃(D) | b = 1

]
+ Pr

[
DetΠ,Π̃(D) | b = 0

]
− 1

= 1− (1− δ · Pr [W ])q

≤ 1− (1− δ · Pr [PRFF (D)])q

≤ 1−
(

1− δ

2(1 + Advprf
F (D))

)q
≤ 1−

(
1− δ

2(1 + Îľ)
)q

≤ δq

2 (1 + Îľ). ut

Remark. Whereas (un)detectability does depend on the security of the PRF,
the PRF can be quite weak without much impacting the adversary’s key re-
covery advantage. If the base scheme Π’s ciphertexts are indistinguishable from
random (IND$), then the PRF could simply choose the first dlog(`)e + 1 many
bits of the ciphertext. This seems paradoxical, as strong privacy security is usu-
ally a desirable property but here it allows a simpler ASA to be successful.

We note that in practice, the subverted decryption algorithm Π̃.Dec can be
made more effective in a number of ways. Indeed, the model is very conservative
and in practice it may be possible for A.Ext to observe a number of distinguish-
able error messages following [10].

4.2 Attack 2: Active

Consider algorithms Π̃.Dec and A.Ext as specified in Fig. 4. The adversary A.Ext
crafts special messages using a length-preserving pseudo-random permutation E
under the attacker key6. We let E : {0, 1}A.kl×{0, 1}∗ → {0, 1}∗. The security of
E will determine how easily the distinguisher D will be able to recreate a special
message to trigger Π̃. Furthermore, as in the passive attack, Π̃.Dec makes use of
a PRF F to determine whether or not to reject submitted ciphertexts. We let
F : {0, 1}A.kl×{0, 1}∗ → [Π.kl]×{0, 1}. Although the notation implies keys are the
same, we assume independent behaviour of F,E.7 We analyse this construction
in the formal model defined by game ActiveKRΠ̃,M in Fig. 2.

6 See Appendix A for the definition of a length-preserving PRP.
7 Using only one key is just a trick to keep the notation compact.



Algorithm Π̃.Dec(kA, k, c, d;n)
1: m← Π.Dec(k, c, d;n)
2: if (m 6= ⊥) then
3: return m
4: c̃← E−1(kA, c)
5: m← Π.Dec(k, c̃, d;n)
6: if (m = ⊥) then
7: return ⊥
8: parse F (kA, c̃ ‖ d) as i ‖ b
9: if (k[i] = b) then
10: return m
11: else
12: return ⊥

Algorithm A.ExtOEnc,ODec (kA)
1: ∀i ∈ [Π.kl], key[i]← ?
2: while ∃j : key[j] = ? do
3: (c, d;n)← OEnc()
4: parse F (kA, c ‖ d) as i ‖ b
5: if (key[i] = ?) then
6: c̃← E(kA, c)
7: v ← ODec(c̃, d;n)
8: key[i]← b⊕ v
9: return key

Fig. 4. Active ASA against AEAD

Theorem 2. Let Π be a perfectly-correct symmetric encryption scheme and let
` = Π.kl. Let Π̃.Dec and A.Ext be defined as in Fig. 4. Let M be a message
sampling algorithm. Let ` = Π.kl and Advauth

Π < ε. Let F : {0, 1}A.kl × {0, 1}∗ →
[`] × {0, 1} be a PRF with Advprf

F (F) < 1 for all efficient adversaries F . Let E
be a lp-PRP with E : {0, 1}A.kl × {0, 1}∗ → {0, 1}∗ and Advprp

E (F ′) < ε′ for all
efficient PRP adversaries F ′. Then

(1) Advkr
Π̃,M

(A) ≥ 1 − `e−
q
` (1−ε), where A.Ext makes exactly Π.kl calls to the

decryption oracle and q calls to the encryption oracle.
(2) For every distinguisher D, Advdet

Π,Π̃
(D) ≤ q

2τ + ε′, where D makes q queries
to its decryption oracle.

Proof of (1). We use the same combinatorial argument as in Thm. 1. This time,
the probability that (at least) i of the key bits have not been correctly exfiltrated
is given by

(
`
i

) [
(1− i

` ) + Îąi
2`
]q. Here ι is the probability that Π.Dec(k, c̃, d;n) 6=

⊥ given that F−1(kA, c̃) = j ‖ k[j] for j in the set of indices being counted. We
note that Advauth

Π ≥ α.

Advkr
Π̃,M

(A) =
∑̀
i=0

(−1)i
(
`

i

)[
(1− i

`
) + Îąi

2`

]q
≥ 1− `

(
1 + 1

`
(α2 − 1)

)q
≥ 1− `e−

q
` (1−α2 )

≥ 1− `e−
q
` (1−ε). ut

Proof of (2). As in Thm. 1, the only way to distinguish between Π and Π̃ is by ob-
serving Π̃.Dec accepting a forged ciphertext. To do this, the distinguisher D must
find some ciphertext c with associated data d such that F (kA, c̃ ‖ d) = i ‖ k[i]



for some i ∈ [`] and where c̃ = E−1(kA, c). Noting that Advprf
F (F) < 1, we thus

obtain

Pr
[
DetΠ,Π̃(D) | b = 0

]
≤ Pr

[
D finds c with E−1(kA, c) = c̃ for some c̃
with Π.Dec(k, c̃, d;n) 6= ⊥, for some d, n

]
Consider the following game, which we will refer to as the pre-image game. For
b ∈ {0, 1} we define experiment b as follows:

1. The challenger ini";"""date"",""2020-01-06T16:05:49Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2020-01-06T16:05:49Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017) kpathsea version 6.2.3""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2020-01-06T16:05:49Z""
""created"",""2020-01-06T16:05:49Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-01-06T16:05:49Z""
""resourceName"",""main.pdf""
""Author"",""""
""producer"",""pdfTeX-1.40.18""
""pdf:docinfo:producer"",""pdfTeX-1.40.18""
""pdf:unmappedUnicodeCharsPerPage"",""3"",""0"",""0"",""0"",""5"",""12"",""22"",""11"",""20"",""44"",""28"",""67"",""24"",""8"",""1"",""20"",""13"",""0"",""0"",""10""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2020-01-06T16:05:49Z""
""Last-Modified"",""2020-01-06T16:05:49Z""
""dcterms:modified"",""2020-01-06T16:05:49Z""
""title"",""""
""Last-Save-Date"",""2020-01-06T16:05:49Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2020-01-06T16:05:49Z""
""meta:save-date"",""2020-01-06T16:05:49Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017) kpathsea version 6.2.3""
""Content-Length"",""597961""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""20""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""2045"",""2965"",""2835"",""2884"",""2299"",""2012"",""1859"",""2374"",""1847"",""1585"",""1782"",""1489"",""1868"",""1240"",""1502"",""2755"",""2065"",""2918"",""2850"",""1582""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-01-06T16:05:49Z""
";https://scholar.google.com/scholar?start=650&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094546-674;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[PDF][PDF] Risks of Blockchain for Data Protection: A European Approach;BS Jiménez;Gómez  Santa Clara High Tech. LJ, 2019  HeinOnline;;"… A Detailed Look at Cryptocurrency 's New Kid on the Block, BITCOIN MAGAZINE (Feb. 26, 2013),

https://bitcoinmagazine.com/articles/introducing- ripple. 5 Toshendra K. Sharma, Advantages

and disadvantages ofpermissionless blockchain, BLOCKCHAIN COUNCIL (Oct …";Cité 1 fois;Les 6 versions;[PDF] heinonline.org;https://heinonline.org/hol-cgi-bin/get_pdf.cgi?handle=hein.journals/sccj36&section=15&casa_token=Ol8iP14WDqIAAAAA:bH_Nd7ikGuhtPH00PU84qH35kVCupIymtpSJwMbr2T2g8hYGJOMXO-z2leIZG47MOF_BMAI;"

 ";"""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""REFRESH"",""1; url=https://heinonline.org/HOL/Page?handle=hein.journals/sccj36&div=15&g_sent=1&casa_token=Ol8iP14WDqIAAAAA:bH_Nd7ikGuhtPH00PU84qH35kVCupIymtpSJwMbr2T2g8hYGJOMXO-z2leIZG47MOF_BMAI""
""Content-Encoding"",""UTF-8""
""resourceName"",""get_pdf.cgi""
""language"",""""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=490&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094558-730;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Blockchain und maschinelles Lernen–Ein Literaturüberblick;J Tagliaferri ; Blockchain und maschinelles Lernen, 2019  Springer;;"… Gerade in Konsortium-Blockchains könnte es von großer Bedeutung sein, dass

maschinelle Lernverfahren mit in die Blockchain integriert werden oder mittels Oracles

auf die Daten der Konsortiumsblockchain zugreifen können …";Autres articles;;null;;;;https://scholar.google.com/scholar?start=540&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094590-866;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;On the property of blockchains: comments on an emerging literature;JZ Garrod ; Economy and Society, 2019  Taylor & Francis;;"… 1). Part of that work has already resulted in a partnership with cryptocurrency exchange Gemini …

Amazon has also started offering blockchain templates, allowing their customers to create

blockchain-based decentralized applications (dApps); Oracle, IBM and …";Cité 7 fois;Les 3 versions;[PDF] tandfonline.com;https://www.tandfonline.com/doi/pdf/10.1080/03085147.2019.1678316?casa_token=xiNqLZzoXloAAAAA:x3rbbyD3qrJghsStBjSyOy5SFcFxNXczPwQi-a4jWXZ62HCkikM6aUaNK7M0D2PvxD18We4rJv9KGQ;;;https://scholar.google.com/scholar?start=680&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094583-836;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Negative results on mining crypto-api usage rules in android apps;J Gao, P Kong, L Li, TF Bissyand酠; 2019 IEEE/ACM 16th …, 2019  ieeexplore.ieee.org;;"… apps. 2) Are crypto-API usage updates fixing misuses? Investigating actual API

usages with an oracle, based on security expert manual specifications, will eventually

help to conclude on the validity of our research hypothesis …";Cité 9 fois;Les 6 versions;[PDF] uni.lu;https://orbilu.uni.lu/bitstream/10993/42460/1/article.pdf;"
Negative Results on Mining Crypto-API Usage
Rules in Android Apps

Jun Gao∗, Pingfan Kong∗, Li Li†, Tegawendé F. Bissyandé∗, Jacques Klein∗
∗University of Luxembourg, Luxembourg

†Monash University, Australia
{jun.gao, pingfan.kong, tegawende.bissyande, jacques.klein}@uni.lu

li.li@monash.edu

Abstract—Android app developers recurrently use crypto-APIs
to provide data security to app users. Unfortunately, misuse of
APIs only creates an illusion of security and even exposes apps
to systematic attacks. It is thus necessary to provide developers
with a statically-enforceable list of specifications of crypto-API
usage rules. On the one hand, such rules cannot be manually
written as the process does not scale to all available APIs. On the
other hand, a classical mining approach based on common usage
patterns is not relevant in Android, given that a large share of
usages include mistakes. In this work, building on the assumption
that “developers update API usage instances to fix misuses”, we
propose to mine a large dataset of updates within about 40 000
real-world app lineages to infer API usage rules. Eventually, our
investigations yield negative results on our assumption that API
usage updates tend to correct misuses. Actually, it appears that
updates that fix misuses may be unintentional: the same misuses
patterns are quickly re-introduced by subsequent updates.

I. INTRODUCTION
Although software systems have greatly impacted the ef-

ficiency of transactions and communications in our digital
world, the security and privacy issues that they carry have
been raising concerns among all stakeholders. In this con-
text, the software development community is now urged to
implement means to protect user assets, most notably by
using cryptography for ensuring confidentiality of data and
transactions, as well as the authenticity of information. Un-
fortunately, several recent studies [1], [2], [3] have revealed
that developers often make mistakes when using cryptography
APIs (hereafter, crypto-APIs is used for short), even those
APIs implemented in widely used libraries such as the Java
Cryptography Architecture (JCA). These misuses, which may
lead to security mishaps [4], [5], actually carry an illusion
of safety for users and developers. Consequently, the research
community has started a new effort towards improving the
analysis and fix of crypto-APIs usage [6], [7].

To properly use crypto-APIs, developers must learn the
API usage rules. Similarly, to validate code, the research and
practice communities must build tools for checking API calls
against a database of the associated API usage rules. To the
best of our knowledge, there are three strategies commonly
adopted in the literature for the inference of general API usage
rules:
• manual specification: Recent literature on static analysis

for verifying crypto-API usages propose approaches that are
based on manually-written specifications [6], [8]. Although

such approaches offer a high degree of reliability, they may
require extensive security expertise, and do not scale to the
sheer number of cryptography libraries (and their associated
recurrent API updates).

• majority contest of usage patterns: A trivial approach
for systematically finding and updating API protocols is to
mine usage patterns in a representative dataset of developer
code [9], [10]. Most recurrent patterns are considered as
the correct protocol. Such approaches have been shown
effective in operating system code [11] where the majority
of developers have a significant level of expertise [12],
[13]. In the Android community, however, most developers
are novice and their usages of crypto-APIs are generally
incorrect [14].

• commit log mining: Recently, Paletov et al. [7] have
proposed to mine commit messages from software version
tracking systems to identify fixes of API usages and infer the
“correct” usages based on static code analysis. Theoretically,
this strategy is reliable (in contrast to simple popularity
voting of usage patterns). In practice, however, developers
often make uninformed updates, and it is now accepted
that commit messages are often less informative than what
researchers expect [15].
This paper. Our work is set in the context of the Android

development community where millions of apps are built and
regularly updated on markets. Our objective is to present
and investigate the suitability of an approach to infer crypto-
API usage rules based on developer updates. Although most
of Android apps are not associated with public source code
management systems, their different apk releases can be read-
ily reverse-engineered into intermediate representations (e.g.,
smali or Jimple) by using frameworks such as Apktool and
Soot [16]. These representations can then be statically analyzed
in a straightforward way for extracting usage instances, and
comparing usages across updates. Our approach will leverage
the AndroZoo [17] dataset where successive apk releases are
continuously crawled for the research community.

Our main assumption for inferring crypto-API usage rules
by mining code updates is that “API usage updates
generally transform incorrect usages into correct us-
ages”. Although this assumption is intuitively reasonable,
our investigations have yielded contradictory results. We



thus report on the negative results of mining crypto-API
usage rules by mining Android app updates. We focus in
this study on the widespread JCA APIs used in 598,875
apk releases associated with 39,213 lineages of real world
Android apps.

II. BACKGROUND
We now provide details on the crypto-APIs studied in this

work as well as the tool chain leveraged for statically checking
API usages (i.e., to build the ground truth for the study).

A. Crypto-APIs
Cryptography is the science that yields algorithms for hid-

ing information from third-parties. Encryption and decryption
mechanisms are used to support authentication as well as to
guarantee the confidentiality of transactions and information
integrity. In software development, crypto-APIs are provided
as part of programming toolkits to accelerate the inclusion of
cryptography functionalities in developer code. For example,
in the Java realm, the Java Cryptography Architecture (JCA)
APIs, which are officially provided by Oracle [18], are widely
used by developers. Given that most Android apps are built
in Java, the use of JCA APIs is also widespread in the
Android community. Although some alternate crypto-APIs,
such as Apache Commons Crypto [19] APIs, do exist, they are
substantially less widespread. Therefore, our work is focused
on JCA to investigate the potential API misuses among real-
world apps.

Table I enumerates the 23 API classes implemented in the
JCA library, where each class was designed to address a spe-
cific cryptography functionality: for example, the MessageDi-
gest class includes algorithm implementations for computing
the digest of some information (e.g., text message) which can
be used to check its integrity after transmission.

TABLE I: Java Cryptography Architecture (JCA) APIs.
API Class: Description

java.security.AlgorithmParameters: maintainer for security parameters for specific
algorithms
javax.crypto.Cipher: provide encryption and decryption functionality
javax.crypto.spec.DHGenParameterSpec: parameters for generating Diffie-
Hellman parameters for DH key agreement
javax.crypto.spec.DHParameterSpec: parameters used for DH algorithm
java.security.spec.DSAGenParameterSpec: parameters for DSA parameter gener-
ation
java.security.spec.DSAParameterSpec: parameters used for DSA algorithm
javax.crypto.spec.GCMParameterSpec: parameters for cipher using
Galois/Counter Mode
javax.xml.crypto.dsig.spec.HMACParameterSpec: parameters for the XML sig-
nature HMAC algorithm
javax.crypto.spec.IvParameterSpec: Initialization Vector for block cipher
javax.crypto.KeyGenerator: generate keys for encryption-decryption
java.security.KeyPair: holder of a publicprivate key pair
java.security.KeyPairGenerator: create publicprivate key pairs
java.security.KeyStore: a memory storage to maintain keys and certificates for later
usage
javax.crypto.Mac: Message Authentication Code for message integrity protection
java.security.MessageDigest: a one-way hash for messages
javax.crypto.spec.PBEKeySpec: specification of a Password Based Encryption key
javax.crypto.spec.PBEParameterSpec : parameters for password based encryption
java.security.spec.RSAKeyGenParameterSpec: parameters for RSA key pair gen-
eration
javax.crypto.SecretKey: a symmetric secret key
javax.crypto.SecretKeyFactory: convert key into key specification and vice-versa
javax.crypto.spec.SecretKeySpec: specification of a symmetric secret key
java.security.SecureRandom: generate secured pseudo-random numbers
java.security.Signature: digital signature

Implementation-wise, to perform a cryptography-related
task, an object associated with the relevant JCA class must
first be instantiated. Subsequently, a sequence of the object
methods is invoked in a specific order of steps. Listing 1 shows
a usage example of API PBEKeySpec retrieved from a human
resource management app named com.successfactors.android.
The code snippet is written in Jimple, the intermediate repre-
sentation of Soot, which we leveraged in this work to reverse
engineering Android apps.

First, the password (i.e., $r3) and salt (i.e., $r0) pa-
rameters of the constructor of PBEKeySpec are initialized
with the passed-in arguments (lines 7-10). Then, an object
of PBEKeySpec is constructed with the password and salt
(lines 11-12). There are 2 extra constants of type int used
when instantiating the object (line 12): the first one, (1 000 in
this example), is used to specified the iteration number, the
second one (i.e., 256) is used to specify the key length. The
PBEKeySpec object is used to further generate a SecretKey
object (line 13-14). After using the PBEKeySpec object, for
security consideration, the password is cleared from the mem-
ory (line 15). The rest part of the example is to create a
SecretKeySpec by using the previously generated objects and
return it for other utilizations.

1 private static javax.crypto.spec.SecretKeySpec
deriveEncryptrionKey(char[], byte[])

2 {
3 javax.crypto.spec.PBEKeySpec $r2;
4 javax.crypto.SecretKeyFactory $r5;
5 javax.crypto.SecretKey $r6;
6 javax.crypto.spec.SecretKeySpec $r7;
7 byte[] $r0;
8 char[] $r3;
9 $r0 := @parameter1: byte[];

10 $r3 := @parameter0: char[];
11 $r2 = new javax.crypto.spec.PBEKeySpec;
12 specialinvoke

$r2.<javax.crypto.spec.PBEKeySpec: void
<init>(char[],byte[],int,int)>($r3, $r0, 1000,
256);

13 $r5 = <com.sybase.persistence.SharedDataVault:
javax.crypto.SecretKeyFactory secretKeyFactory>;

14 $r6 = virtualinvoke
$r5.<javax.crypto.SecretKeyFactory:
javax.crypto.SecretKey
generateSecret(java.security.spec.KeySpec)>($r2);

15 virtualinvoke
$r2.<javax.crypto.spec.PBEKeySpec: void
clearPassword()>();

16 $r7 = new javax.crypto.spec.SecretKeySpec;
17 $r0 = interfaceinvoke

$r6.<javax.crypto.SecretKey: byte[]
getEncoded()>();

18 specialinvoke
$r7.<javax.crypto.spec.SecretKeySpec: void
<init>(byte[],java.lang.String)>($r0, ""AES"");

19 return $r7;
20 }

Listing 1: JCA API Usage Example (Jimple code representation)

In this example, there are several code locations where
developers can make mistakes that would lead to misuses of
the PBEKeySpec API:
• (line 9) - Security strength of a password is heightened when

salt is properly generated in a random way. In practice,
however, developers commonly hard code their salt value.
In the example code, salt is specified as parameter of
method deriveEncryptrionKey (line 1) and then stored in



$r0. So, a misuse could happen if a constant is passed to
deriveEncryptrionKey in the second parameter.

• (line 10) - Often, developers use a String object to hold
the password and then use toCharArray() to convert to the
required type (i.e., char[]) when necessary. However, the in-
tention of designing PBEKeySpec constructor to only accept
char[] instead of String is to avoid using String, since String
object is immutable, therefore, they cannot be destroyed or
modified after instantiation until garbage collection revokes
the memory. Given that garbage collection occurs randomly
and is out of the control of developers, the password can
survive in memory for a long time, increasing the risk of
being exploited by attacks.

• (line 12) - Documentation of JCA recommends an iteration
number above 1 000. It is however common to have cases
where developers, with little expertise, assign a smaller
iteration rate.

• (line 15) - Password information should be kept in memory
only for the duration it is needed, in order to minimize
attack opportunities. Thus it should not be held in a String
object and must be cleared immediately after the use of
the PBEKeySpec object. Developers unfortunately often
overlook the call to the clearPassword() of PBEKeySpec.
In this example code, the method clearPassword in line 15
is correctly called, so there is no misuse.

1 F i n d i n g s i n Java C l a s s : com . umeng . common . u t i l . h
2
3 i n Method : j a v a . l a n g . S t r i n g a ( j a v a . l a n g . S t r i n g )
4 C o n s t r a i n t E r r o r v i o l a t i n g CrySL r u l e f o r MessageDiges t
5 F i r s t p a r a m e t e r ( w i th v a l u e ""MD5"" ) s h o u l d be any of {SHA−256, SHA−384,

SHA−512}
6 a t s t a t e m e n t : $ r2 = s t a t i c i n v o k e <j a v a . s e c u r i t y . MessageDiges t :

j a v a . s e c u r i t y . MessageDiges t g e t I n s t a n c e ( j a v a . l a n g . S t r i n g )>(""MD5"" )
7
8 T y p e s t a t e E r r o r v i o l a t i n g CrySL r u l e f o r MessageDiges t
9 Unexpec ted c a l l t o method r e s e t on o b j e c t o f t y p e

j a v a . s e c u r i t y . MessageDiges t . Expec t a c a l l t o one o f t h e f o l l o w i n g
methods d i g e s t , u p d a t e

10 a t s t a t e m e n t : v i r t u a l i n v o k e $r2.< j a v a . s e c u r i t y . MessageDiges t : void
r e s e t ( ) >()

Listing 2: CogniCrypt SAST Report Example

B. Static API usage checker
We leverage CogniCryptSAST [20], a static analyzer of the

CogniCrypt [21] framework, for detecting JCA API misuses
in Java programs. This analyzer was selected as it has been
extended to be compatible with Android apps as well [20],
a static analyzer of the [22]. CogniCryptSAST checks JCA
APIs against a set of rules that were manually specified by
security experts using CrySL [6] (CogniCrypt Specification
Language). We consider CrySL rules as a reliable and accurate
oracle for deciding whether a JCA API is misused or not.
Concretely, given an Android apk, CogniCryptSAST iden-
tifies all instances of the 23 JCA API classes and checks
the usage against the CrySL rules to generate a report on
all detected misuses. Listing 2 showcases an example of a
report generated by CogniCryptSAST where misuses are
hierarchically grouped by classes and methods. In this exam-
ple, 2 misuses are found in method java.lang.String of class
com.umeng.common.util.h of app com.lovinc.radio:

• The first misuse, a ConstraintError of API Messagedigest,
is reported in line 4, with details indicating that argument

“MD5” is not recommended when invoking API method
getInstance(java.lang.String).

• The second misuse (TypestateError error) also relates to
the same API object $r2 and occurs in the same method.
It specifies that the misuse is caused by the fact that the
MessageDigest object had not been in the state to call
method reset(), instead, method digest or update should be
invoked before.
As demonstrated by this example, a single JCA API usage

instance can suffer from multiple misuse errors. Table II
enumerates and provides brief explanations on 6 misuse types
detected by CogniCryptSAST . Actually CogniCryptSAST ’s
reports may include ImpreciseValueExtractionError notifica-
tions, which indicate that CogniCryptSAST cannot obtain all
the information for the analysis, and thus no clear conclusion
can be given. We do not discuss such cases in this study.
Nevertheless, given that we must be able to assess whether a
misuse has actually been fixed in an app update, we must be
able to enumerate all usage locations. To that end, we have
developed on top of Soot [16] a dedicated tool for supporting
the extraction of JCA API usage instances.

TABLE II: CogniCrypt Misuse Types.

Type Explanation
Example

ConstraintError Unrecommended arguments are given.
e.g., MD5 as hashing algorithm.

RequiredPredicateError Arguments are not properly created.
e.g., constant values are used while values are required to be randomly generated.

TypestateError A JCA API object is not in the right state to
invoke a certain method

e.g., a method reset() of a MessageDigest object is invoked before passing any
information into it via calls to methods digest or update.

IncompleteOperationError Tasks are not completed using JCA API
objects.

e.g., a MessageDigest object is instantiated by invoking the getInstance method, but no
further method invocation on this object is performed. The digest task will therefore not
be achieved.

ForbiddenMethodError Unrecommended API methods are invoked.
e.g., PBEKeySpec(char[] password) is one of the constructor of JCA API PBEKeySpec
for deriving cryptographic keys from a given password. Since a key generated without
salt has been proven to be weak, this constructor should be used in specific scenarios.

NeverTypeOfError Certain types are forbidden when storing
sensitive information.

e.g., password value for PBEKeySpec should never be store as type String, but char[].
Since object String is immutable in Java, password information in this type cannot be
explicitly freed from memory. The garbage collector is in charging of deleting it, yet it
is unpredictable from a user standpoint, opening opportunities for password leakage.

Finally, we have implemented a crawler for collecting on
Google Play some metadata (e.g., category, rate, etc.) asso-
ciated to AndroZoo apks. These metadata are leveraged in
criteria for comprehensively dividing the dataset into relevant
subsets for further investigations.

III. SCOPE OF THE STUDY
In this section, we state the study problem along with the

research questions that we intend to investigate, and describe
the dataset of the study.

A. Problem Statement and Research Hypothesis
Given a crypto-API usage location, it is possible, with

security expertise, to assess whether there is a misuse or
not. Manual specification of usage rules however is tedious
to collect over a large set of APIs. Previous studies have
also shown that using a majority voting on usage patterns to
conclude on the correctness of crypto-API usages will lead



to poor results given that wrong usages are widespread in
Android apps. Our intuition however is that, as time goes by,
developers of a given app learn to fix API misuses. Thus,
it should be possible, by analysing code updates in an app
lineage (i.e., the series of apk versions released for a given
app), to infer crypto-API usage rules.

Our hypothesis is thus that: “updates in API usages across
an app lineage will tend to fix misuses”. Consequently, if
an extensively large set of app lineages can be collected in
the wild, it would be possible to retrieve a substantially large
and diverse set of crypto-API usage fixes. Then, by assessing
recurring patterns, we could infer API usage rules.

This work is about empirically assessing the validity of our
hypothesis for the case of the JCA APIs within Android apps.

B. Research Questions
The empirical study mainly aims at (re)investigating the

following questions:
1) To what extent do Android developers misuse crypto-APIs?

The literature claims, often based on few example apps, that
developers regularly make mistakes in using crypto-APIs.
We attempt to provide a thorough picture of the state of
crypto-API usages across a representative dataset of real-
world Android apps.

2) Are crypto-API usage updates fixing misuses? Investigating
actual API usages with an oracle, based on security expert
manual specifications, will eventually help to conclude
on the validity of our research hypothesis. We ensure in
this study, that the cases of specific app categories (e.g.,
high rating apps, financially sensitive apps, etc.) are also
analysed in comparison with the general trends.

3) What are the impacts caused by API usage updates? This
question investigates how crypto-API usages get updated,
in an attempt to derive explanations on the statistical results
obtained in the previous question. Concretely, we study the
proportions of updates that either successfully fix misuses,
or (re)introduce mistakes in correct usages, or that fail to
fix misuses.

C. Dataset
We leverage the largest repository of real-world Android

apps, AndroZoo [17], to collect data for our experiments.
AndroZoo is a growing repository where automated crawlers
continuously harvest Android apps from various app markets
including the official Google Play store. At the time of writing,
it was reported to contain over 8 million Android apks [23],
the most diverse dataset available to the research community.
Since AndroZoo continuously collects any apks that it has
never seen before, it generally includes successive versions
(i.e., apk releases) of the same app, which are relevant for
reconstructing app lineages.

1) App Lineage Reconstruction: To identify app lineages
from AndroZoo, we follow the approach proposed by Gao
et al. [24] and illustrated by the four steps in Fig. 1: (1)
extraction of application IDs, (2) app clustering by certificate,
(3) app clustering by the market, and (4) app sorting by version
code. This process was applied on a snapshot of AndroZoo

in September 2018. Out of the 8 million apps, we only
considered lineages which include at least 10 apk releases. The
lineage reconstruction yielded 43 365 app lineages accounting
for 745,101 apks. This lineage dataset is twice as large as the
dataset presented by Gao et al. in [24] .

2) Misuse detection: We assess crypto-API misuses based
on the reports of the CogniCryptSAST static checker. This
tool, which implements analysis based on expert manual spec-
ifications of API usage rules, is used to collect the oracle to
support our empirical assessment. Analyses are performed on
a High-Performance Computing (HPC) platform [25]. Overall,
we leveraged 142 HPC instances, each utilizing 24GB of
memory, to successfully parse all 745 thousands apks in 5
days.

AndroZoo 
Dataset

App IDs 
extraction

App Clustering 
by Certificate

App Clustering 
by Market

App Sorting 
by Version

App lineages
- Facebook lineage
- Maps lineage
- etc.

1 2 3 4

Fig. 1: App Lineages Re-construction Process [24].

3) Dataset Curation: We took steps to remove from our
study all irrelevant cases of apks or misuses reported by
CogniCryptSAST .
• Apk releases with no JCA API usages are excluded from

our study. Thus, 18% of our initial dataset is left out.
• Apk releases on which CogniCryptSAST fails to generate

a final report are also dropped from the study. Such cases
often occur when the process runs out of memory. While the
recommended memory size for CogniCryptSAST is 8GB,
we allocate 24GB in our experiments. Nevertheless, a few
apk analyses are not able to be completed.

• Obfuscated apk releases are left out from the study. Since
developers recurrently rely on obfuscation techniques to
prevent reverse engineering of their apps, static checkers
such as CogniCryptSAST are challenged in their analyses:
CogniCryptSAST reports ’?’ for erratic character series
that appear as class names. Given that our study of API mis-
uses leverages class names as the basic unit for localisation,
such unidentified class names constitute noise. Thus, after
analysis, when the generated report contains any unlocalised
class name, the corresponding apk is dropped.

TABLE III: Number of APKs and lineages in the Dataset

# lineages # APKs
initial dataset 43 365 745 101
remove because JCA API is not used -3 882 -135 752
remove due to CogniCrypt failures -108 -9 374
remove because of obfuscation -7 -1 100
remove due to combination of the 3 conditions1 -155
final dataset 39 213 598 875

Eventually, 146,226 apks are excluded from the dataset of
apks. Table III summarizes some statistical details about our
dataset. An apk is removed when the one of the situations
above occurs. However, an app lineage is only removed when
all its app versions are excluded.

Fig. 2 shows the distribution of the dex size of apks for
the initial and the final dataset. Our statistical tests indicate

1e.g., an app lineage of 10 app versions, 5 app versions could be removed
because of tool failure while the rest could be caused by obfuscation



no difference between the two distributions, implying that our
final dataset is still representative of the initial dataset (at least
w.r.t app sizes).

0 5 10 15 20 25 30 35
Dex Size in MB

Before

After

Fig. 2: Distribution of Dex Size before-after dataset curation

Metadata Collection. Some of our investigations require
up-to-data metadata (e.g., category, rating, number of installs)
from markets. Because GooglePlay implements location re-
strictions (only apps targeting a country’s users are made
visible in that country), we were able to collect metadata for
around 60% of the lineages.

IV. METHODOLOGY OF THE STUDY

We carry experiments to assess the hypothesis behind re-
lying on usage updates to mine crypto-API usage rules. We
explore usage updates:

• with an analysis of pairwise comparisons among apks
successive releases within the lineages in our dataset;

• with an overall lineage-wise study of the recurrence of
misuses in an app across its entire lineage.

We further investigated updates for selected subsets of apps to
confront the general trends against specific cases for popular
apps, or sensitive apps.

A. Pairwise comparisons of apks from the same lineage
Given an app lineage li, its associated apk releases are

combined into pairs (apkj−1, apkj), where 1 < j ≤ n, for
the purpose of checking differences between misuses in apkj
and apkj−1. The comparison takes into account only usage
instances that are found at the same code location in both
apps and that are relevant to the same API. In this study, a
code location (lo) is represented by both the class and method
in which the API usage is found. We consider the following
cases which may occur:

• misuse fixing (MF) update: the CogniCryptSAST anal-
ysis flags an issue with a usage in apkj−1 but not with
the usage at the same location in apkj . We conclude that
the misuse has been fixed by the update.

• misuse introducing (MI) update: the CogniCryptSAST

analysis flags an issue with a usage in apkj but not with
the usage at the same location in apkj−1. In contrast to
a MF update, such an update introduces misuses.

• misuse fixing and introducing (MFI) update: the
CogniCryptSAST analysis flags an issue with a usage at
a given location in both apkj and apkj−1, but the misuses
are different. This suggests that developers corrected the
previous misuse during the update, but somehow made
another mistake.

• none update: the CogniCryptSAST analysis flags the
same issue with a usage in apkj−1 and apkj at the same
location. We conclude that the developers did not notice
the issure during app updates.

To distinguish among different usages of the same API
at the same location, one should take into account variables
names associated to instantiated objects from API classes.
In practice, however, the reverse-engineering of apks assigns
random names to variables, making these names differ across
the pair of apps. We use simple heuristics to match relevant
pair of usage instances and iteratively start with identifying
none update cases, then MFI updates, before MF updates and
MI updates.

MI update and MFI update constitute two cases of mis-
updates, as they result in API misuses in the most recent
version of the app.

B. Investigations of updates across lineages
We investigate the overall evolution of a given app w.r.t.

its misuses of crypto-APIs. We then study the trends of usage
issues in app lineages. To that end, first, for each app version
apkj in an app lineage li, we compute a misuse ratio rj defined
in equation 1.

mj ← total number API misuses(apkj)
uj ← total number API usages(apkj)
rj :=

mj

uj

(1)

We consider the ordered ratio list Ri of app lineage li
as Ri := {r1, r2, ¡ ¡ ¡ , rn}, a list of misuse ratio of all apk
releases included in li with r1 being the misuse ratio of the
first apk of li, r2 the misuse ratio of the second apk, etc.
We then compute the slope si = linear regress(Ri) of the
regressed between all points of Ri. In this study, si is used
to characterize the misuse trend: a negative si indicates that
lineage li is evolving towards a better usage of crypto-APIs,
while a positive si suggests that the usage of crypto-APIs
is worsening with app updates. A null si indicates a status
quo. The bigger the value of |si|, the faster the evolution in a
lineage.

V. STUDY RESULTS

We now provide experimental results obtained while inves-
tigating the research questions enumerated in Section III-B.
In particular, we show statistics on crypto-API misuses in
the wild, summarize the success rates in API misuse updates
between apk releases, reveal the evolution of misuses across
lineages, and eventually discuss the difference between the
whole dataset and selected categories of apps.

A. RQ1: Crypto-API misuses in Android apps

0 5 10 15 20 25 30 35 40
# of usage per APK

Fig. 3: Distribution of JCA API usages in the study dataset

Crypto-APIs are widely used in Android apps. Statistics
presented earlier (Table III) indicated that over 80% (or 598
thousands apks) of the app versions in our sample dataset
of 745 thousands apks include code with JCA API usages.
Fig. 3 further shows the distribution of JCA API usages in
our dataset of 598k apks. The usage statistics are collected
from the analysis reports of CogniCryptSAST . On median



average, 10 JCA API usage instances can be identified per
app, while 75% of apks include at least 5 usage instances.

Table IV summarizes the statistics on API misuses among
the apks that include JCA API usages. 96% of apks include
misuses, and 97.6% of lineages include at least an apk version
with a misuse. On average 1 misuse is found among 6 usages
of JCA APIs.

TABLE IV: Statistics on API Misuses in the dataset apks

Types Numbers Related Information
Percentage of APKs
with misuse

96% number of APKs without mis-
uses is 24,880

Percentage of app lin-
eages with misuse

97.6% number of lineages without
misuses is 942

misuse to usage ratio 1 : 5.53 total number of API usages
is 23,281,216 and misuses is
4,210,667

We detail the misuse spread in Fig. 4. As shown by the
misuse distributions in apks represented in Fig. 4a, a given apk
contains commonly between 2 to 9 misuse cases. On median
average, 4 misuses can be found per app. We further show
in Fig. 4b the distribution of the ratio (as defined in Eq.1)
between misuses and usages within apks. Interestingly, there
are cases with the ratio is bigger than 1, i.e., there are more
misuse instances than usages. This suggests that developers
can make several mistakes when using a single crypto-API.

0.0 2.5 5.0 7.5 10.0 12.5 15.0 17.5
# of misuse per APK

(a) Distribution of # of Misuse per APK

0.0 0.5 1.0 1.5 2.0 2.5 3.0 3.5 4.0
Ratio per APK

0

25000

50000

75000

100000

125000

# 
of

 A
PK

(b) Distribution of Misuse to Usage Ratio per APK

Fig. 4: API Misuse Distribution
The preponderance of the different APIs to be affected

by misuses is detailed in Fig. 5. Over 60% of apks include
instances of the MessageDigest crypto-API with a misuse.
This is due to the widespread issue of using weak hashing
algorithms. While the percentage for Cipher, the API in the
second place, is around 21% for which the main misuse is
incompleted operation indicating that some further method
calls (e.g., update, doFinal) are expected but never achieved.

Table V further provides statistical details on the types of
errors that are raised by CogniCryptSAST as well as on
the top API methods that are concerned by misuses. Method
getInstance(java.lang.String) of crypto-API MessageDigest
takes as argument a String specifying the hashing algorithm.
This algorithm must offer a strong protection and thus should
be one of the recommended algorithms (e.g., SHA-256, SHA-
384 and SHA-512). When weak algorithms are used (e.g., MD5

or SHA-1), it represents a ConstraintError which makes the
app ex";"""date"",""2019-03-16T09:41:07Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2019-03-16T09:41:07Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016) kpathsea version 6.2.2""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2019-03-16T09:41:07Z""
""created"",""2019-03-16T09:41:07Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-03-16T09:41:07Z""
""resourceName"",""article.pdf""
""Author"",""""
""producer"",""pdfTeX-1.40.17""
""pdf:docinfo:producer"",""pdfTeX-1.40.17""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2019-03-16T09:41:07Z""
""Last-Modified"",""2019-03-16T09:41:07Z""
""dcterms:modified"",""2019-03-16T09:41:07Z""
""title"",""""
""Last-Save-Date"",""2019-03-16T09:41:07Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2019-03-16T09:41:07Z""
""meta:save-date"",""2019-03-16T09:41:07Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016) kpathsea version 6.2.2""
""Content-Length"",""372041""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""11""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""4502"",""5526"",""5656"",""5034"",""4359"",""4466"",""4353"",""4465"",""5342"",""5126"",""7611""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-03-16T09:41:07Z""
";https://scholar.google.com/scholar?start=650&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094546-671;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Blockchain-basiertes Fundraising als innovative Alternative der Unternehmensfinanzierung;K Himmer ; Springer Books, 2019  Springer;;"Page 1. Klaus Himmer Blockchain-basiertes Fundraising als innovative Alternative der

Unternehmensfinanzierung Eine steuer- und … Unternehmensfinanzierung Page 3. Klaus Himmer

Blockchain-basiertes Fundraising als innovative Alternative der Unternehmensfinanzierung …";Cité 2 fois;Les 6 versions;null;;;;https://scholar.google.com/scholar?start=490&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094560-738;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Análise da proposta de valor potencial na aplicaçăo do blockchain ŕ indústria de jogo online em Portugal;DES Jesus ;2019 repository.utl.pt;;"… ANÁLISE DA PROPOSTA DE VALOR POTENCIAL NA APLICAÇĂO DO BLOCKCHAIN Ŕ

INDÚSTRIA DE JOGO ONLINE EM PORTUGAL … ANÁLISE DA PROPOSTA DE VALOR POTENCIAL

NA APLICAÇĂO DO BLOCKCHAIN Ŕ INDÚSTRIA DE JOGO ONLINE EM PORTUGAL …";Autres articles;Version HTML;[PDF] utl.pt;https://www.repository.utl.pt/bitstream/10400.5/19709/1/DM-DESJ-2019.pdf;"
   

 
 

 

 

MESTRADO EM 

GESTÃO E ESTRATÉGIA INDUSTRIAL 
 
 
 

TRABALHO FINAL DE MESTRADO 
DISSERTAÇÃO 

 
 
 
 
ANÁLISE DA PROPOSTA DE VALOR POTENCIAL NA 

APLICAÇÃO DO BLOCKCHAIN À INDÚSTRIA DE JOGO 

ONLINE EM PORTUGAL 
 
 
 
 
 

 
DANNY EMMANUEL DA SILVA DE JESUS 
 
 
 
 

OUTUBRO DE 2019 
 



 
 

 
 

 

 

MESTRADO EM 

GESTÃO E ESTRATÉGIA INDUSTRIAL 
 
 
 

TRABALHO FINAL DE MESTRADO 
DISSERTAÇÃO 

 
 
 
 
ANÁLISE DA PROPOSTA DE VALOR POTENCIAL NA 

APLICAÇÃO DO BLOCKCHAIN À INDÚSTRIA DE JOGO 

ONLINE EM PORTUGAL 
 

 
DANNY EMMANUEL DA SILVA DE JESUS 
 
 
 
ORIENTAÇÃO E CO-ORIENTAÇÃO: 

PROFESSOR DOUTOR ANTÓNIO PALMA REIS 
PROFESSOR DR. BERNARDO CHAGAS 
 
 
 

OUTUBRO DE 2019



   

 
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

  

 

 

 



   

i 
 

GLOSSÁRIO 
 

CE: ComissĂŁo Europeia 

 

CRM: Customer Relationship Manager 

 

ECB: European Central Bank 

 

ICO: Initial Coin Offerings  

 

IQR: Interquartile Range  

 

RJO: Regime JurĂ­dico dos Jogos e Apostas Online  

 

SRIJ: Serviço de Regulação e Inspeção de Jogos 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 



Danny E. S. de Jesus                                ANÁLISE DA PROPOSTA DE VALOR POTENCIAL NA APLICAÇÃO DO  BLOCKCHAIN À INDUSTRIA 

DE JOGO ONLINE EM PORTUGAL 

ii 
 

RESUMO 
 
 

  O objetivo da presente dissertação consiste em analisar o impacto da 

implementação do Blockchain no modelo de negócio dos operadores licenciados no 

mercado português e definir os atributos que poderão estar na base da criação de uma 

nova proposta de valor na indústria de jogos online.. Neste âmbito, foram contactados 

alguns operadores licenciados na indĂşstria de jogos online em Portugal e profissionais da 

årea de gambling, cuja contribuição foi determinante para avaliar a necessidade e a 

potencial importância estratÊgica do Blockchain no modelo de negócios. A problemåtica 

levantada pela aplicação da nova tecnologia a uma indústria recentemente regulamentada 

deu origem a duas questþes de investigação 1) A tecnologia Blockchain Ê aplicåvel à 

indĂşstria de jogo online atualmente? 2) Quais os benefĂ­cios expectĂĄveis ou contributos 

para os jogadores e operadores? A metodologia de estudo utilizada foi a Delphi, que 

consiste num processo estruturado para recolher “conhecimento” de um grupo de 

especialistas (Adler & Ziglio, 1996). Os resultados obtidos permitiram identificar os 

principais desafios na potencial implementação, dos quais se destaca a regulamentação, 

o investimento, o estado embrionårio da tecnologia e a regulamentação. PorÊm, 

identificou-se a transparência como a principal vantagem na potencial aplicação do 

Blockchain no modelo de negĂłcios dos operadores.  O estudo permitiu verificar tambĂŠm 

que existe ainda alguma dificuldade por parte dos gestores e outros profissionais com 

cargos relevantes na hierarquia oganizacional, em percepcionar a potencialidade da 

tecnologia e dos seus atributos, à semelhança do que acontece em outros setores. 

 

 

 

 

 

 

 

 

Palavras-chave: modelo de negĂłcio, proposta de valor, tecnologia disruptiva, jogo online, 

Blockchain. 



Danny E. S. de Jesus                                ANÁLISE DA PROPOSTA DE VALOR POTENCIAL NA APLICAÇÃO DO  BLOCKCHAIN À INDUSTRIA 

DE JOGO ONLINE EM PORTUGAL 

iii 
 

 

ABSTRACT 
 

 

The objective of this dissertation is to analyze the impact of the implementation of 

Blockchain in the business model of licensed operators in the Portuguese market and to 

define the attributes that may be the basis of the creation of a new value proposition in 

the online gambling industry. Some licensed operators in the online gambling industry in 

Portugal and gambling professionals were contacted, whose contribution was crucial in 

assessing the need and potential strategic importance of Blockchain in the business model. 

The problem raised by applying new technology to a newly regulated industry has given 

rise to two research questions 1) Is Blockchain technology currently applicable to the 

online gambling industry? 2) What are the expected benefits or contributions to players 

and operators? The study methodology used was Delphi, which is a structured process 

for gathering “knowledge” from a group of experts (Adler & Ziglio, 1996). The results 

obtained allowed us to identify the main challenges in the potential implementation, such 

as regulation, investment, embryonic state of technology and regulation. However, 

transparency was identified as the main advantage in the potential application of 

Blockchain in the operators business model. The study also showed that there is still some 

difficulty on the part of managers and other professionals with relevant positions in the 

organizational hierarchy, in perceiving the potential of technology and its attributes, 

similarly to what happens in other sectors. 

 
 
 
 
 
 
 
 
Keywords: business model, value proposition, disruptive technology, online gambling, 

Blockchain. 



Danny E. S. de Jesus                                ANÁLISE DA PROPOSTA DE VALOR POTENCIAL NA APLICAÇÃO DO  BLOCKCHAIN À INDUSTRIA 

DE JOGO ONLINE EM PORTUGAL 

iv 
 

ÍNDICE 

GLOSSÁRIO ..................................................................................................................................... i 

RESUMO ........................................................................................................................................... ii 

ABSTRACT ...................................................................................................................................... iii 

AGRADECIMENTOS ....................................................................................................................... v 

1. INTRODUÇÃO .............................................................................................................................. 1 

2. REVISÃO DA LITERATURA ...................................................................................................... 4 

 
            2.1. Tecnologia ....................................................................................................................... 4 
            2.2. Modelos de negĂłcio ......................................................................................................... 5 
            2.3. Proposta de valor ............................................................................................................. 7 
            2.4. Blockchain ...................................................................................................................... 11 
                 2.4.1. Definição de Blockchain......................................................................................... 11 
                 2.4.2. Modelo de negĂłcio e Blockchain............................................................................ 12 
                 2.4.3. Blockchain e os seus atributos ................................................................................ 13 
                 2.4.4. Arquiteturas de Blockchain .................................................................................... 15 
                 2.4.5. Variedade de aplicaçþes do Blockchain ................................................................. 15 
                 2.4.6. Limitaçþes do Blockchain ...................................................................................... 16 

3. METODOLOGIA DE INVESTIGAÇÃO ..................................................................................... 17 

 
          3.1 Metodologia Delphi ........................................................................................................... 17 
          3.2. Escolha do setor em anĂĄlise .............................................................................................. 21 
          3.3. Caraterização da indústria do jogo online ......................................................................... 22 

4. ANÁLISE DE RESULTADOS ..................................................................................................... 25 

 
         4.1. Resultados e conclusĂľes da 1ÂŞ ronda ................................................................................. 25 
         4.2. Resultados e conclusĂľes da 3.ÂŞ ronda ................................................................................ 28 

5. CONCLUSÕES ............................................................................................................................. 30 

REFERÊNCIAS ................................................................................................................................ 36 

ANEXOS ........................................................................................................................................... 44 

ÍNDICE DE TABELAS 

Tabela I – Resultados da primeira ronda ........................................................................................... 25 

Tabela II – Resultados da terceira ronda ........................................................................................... 28 

 



Danny E. S. de Jesus                                ANÁLISE DA PROPOSTA DE VALOR POTENCIAL NA APLICAÇÃO DO  BLOCKCHAIN À INDUSTRIA 

DE JOGO ONLINE EM PORTUGAL 

v 
 

AGRADECIMENTOS 
 

A realização da presente dissertação foi um projeto longo e com bastantes desafios, 

tendo em conta que o Blockchain ĂŠ uma tecnologia embrionĂĄria e que a indĂşstria de jogo 

online foi recentemente regulamentada. Por estas razĂľes, foi essencial contar com o apoio 

de peritos da ĂĄrea, para esclarecimentos de dĂşvidas relacionados com o tema e 

complementarmente responder aos inquĂŠritos. 

 

Agradeço à Drª Manuela Bandeira, Diretora do Serviço de Regulação e Inspeção de 

Jogos (SRIJ) e ao Dr. Hugo Mira, coordenador de ĂĄrea do Departamento de Sistemas de 

Pagamentos do Banco de Portugal, pela disponibilidade e interesse que mostraram para a 

realização de uma entrevista e pelas opiniþes que foram fundamentais para definir o tema 

do Blockchain. 

 

Um agradecimento especial ao Professor Doutor AntĂłnio Palma Reis e ao Professor 

Dr. Bernardo Chagas, Orientador e Co-Orientador, respetivamente, pela disponibilidade, 

interesse e conhecimento transmitido ao longo da dissertação. 

 

À minha irmã pelas dicas preciosas, aos meus pais pela paciência e força constante 

que me deram ao longo do Mestrado, Ă  minha namorada LuĂ­sa Marques pela ajuda e 

compreensĂŁo e Ă  minha filha Beatriz que ĂŠ simplesmente a minha razĂŁo de ser e de nunca 

desistir.



   

1 
 

 
1. Introdução 

 

Durante dĂŠcadas, o comĂŠrcio baseou-se em estabelecimentos fĂ­sicos, mas a 

Internet possibilitou aos consumidores, a compra de produtos e serviços online (Olson & 

Olson, 2000). As plataformas digitais vieram facilitar o acesso a produtos e serviços de 

uma forma mais pråtica, cómoda e cÊlere e tambÊm a partilha de informaçþes sem custos 

entre organizaçþes, tornando-se uma ferramenta transversal a bastantes setores. Os 

“mercados virtuais” caraterizam-se pela alta conetividade (Soumitra & Segev, 1999), 

foco nas transaçþes (Balakrishnan, Kumara & Sundaresan, 1999) e pela inexistência de 

fronteiras geográficas (Zott & Amit, 2001). À medida que se torna mais fácil a 

interoperabilidade e globalização de serviços e aplicaçþes na internet (Sadiku, Musa & 

Nelatury, 2017), a lógica subjacente a algumas indústrias tradicionais começa a 

desintegrar-se (Zott & Amit, 2001). Recentemente, o surgimento de uma tecnologia 

disruptiva com a capacidade integral de desintermediação, o Blockchain, permitirå 

desempenhar um papel importante na criação de novos tipos de negócios (Seppälä, 2016).  

Contudo, “há uma série de desafios que retardam a adoção de Blockchain, 

incluindo a fase de desenvolvimento embrionårio da tecnologia, a regulação pesada de 

potenciais indústrias e a necessidade de uma rede para construir aplicações de valor” 

(Seppälä, 2016, p. 10). 

A indústria objeto de estudo desta dissertação Ê a de jogos online.  Se 

anteriormente apenas era possĂ­vel apostar em casinos fĂ­sicos, atualmente o apostador 

pode jogar online nas slots machines, roletas, blackjack, bingo ou apostas desportivas, 

entre outros. Embora o “casino online” esteja a crescer a nível mundial em termos de 

receita bruta, a indĂşstria tem-se deparado com desafios tecnolĂłgicos, dos quais se destaca 

o Blockchain. Neste trabalho serĂĄ abordado o impacto que a nova tecnologia terĂĄ no 

modelo de negĂłcio dos operadores de jogo online e definidos os atributos que podem 

contribuir para uma nova proposta de valor. Algumas propostas de valor podem ser 

inovadoras e representam uma oferta nova ou disruptiva enquanto que outras podem ser 

semelhantes Ă s ofertas de mercado existentes, mas com recursos e atributos adicionados 

(Osterwalder & Pigneur, 2010). A simbiose entre duas situaçþes relativamente recentes, 

nomeadamente o surgimento do Blockchain que carece de informação na sua aplicação, 



Danny E. S. de Jesus                                ANÁLISE DA PROPOSTA DE VALOR POTENCIAL NA APLICAÇÃO DO  BLOCKCHAIN À INDUSTRIA 

DE JOGO ONLINE EM PORTUGAL 

2 
 

em simultâneo com um setor recentemente regulamentado, originou a formulação das 

seguintes questþes de investigação:   

1. A tecnologia Blockchain ĂŠ aplicĂĄvel Ă  indĂşstria de jogo online atualmente? 

 

2. Quais os benefĂ­cios expectĂĄveis ou contributo para os jogadores e operadores? 

Relativamente à primeira questão “A tecnologia Blockchain é aplicável à indústria de 

jogo online atualmente?” é essencial conhecer bem as especificidades da tecnologia e 

dominar os conceitos implĂ­citos Ă  sua arquitetura. O novo sistema permitirĂĄ tambĂŠm 

melhorar a segurança relativamente a sistemas tradicionais, atravÊs da capacidade de 

imutabilidade e de mecanismos de contratos inteligentes. O desafio ĂŠ compreender a 

tecnologia e de que forma pode ser implementada para obter os melhores resultados 

possíveis e satisfazer novas necessidades de mercado. A exploração da atividade com 

base numa tecnologia disruptiva no modelo de negĂłcio ĂŠ incerta e nĂŁo linear, uma vez 

que os efeitos sĂŁo particularmente dificeis de determinar. O estudo pode ajudar a clarificar 

de que forma pode ser aplicada a tecnologia e identificar os benefĂ­cios que se esperam 

obter. Relativamente à questão “Quais os benefícios expectáveis ou contributo para os 

jogadores e operadores?” em primeira instância identificaram-se os benefícios do 

Blockchain referidos na literatura: 1) privacidade 2) risco de fraude 3) transparĂŞncia 4) 

segurança 5) acesso equitativo 6) velocidade 7) eficiência 8) qualidade 9) produtividade 

e 10) redução dos custos. PorÊm, alguns destes atributos foram excluídos devido à sua 

pouca representatividade face ao problema em anĂĄlise e por estarem relacionados com 

questĂľes de  performance dos operadores. ApĂłs reflexĂŁo foi decidido apenas selecionar a 

privacidade, a transparência, segurança, a velocidade e  a redução dos custos. Os 5 

atributos selecionados foram previamente analisados de forma a verificar a coerĂŞncia, 

face aos objetivos da dissertação, não tendo sido considerado o acesso equitativo, que de 

acordo com o Perito 4, “de nada serve este acesso se não for possível depois converter o 

ganho para uma moeda transacional pelo utilizador, o que vai incorrer na necessidade 

de uso de um qualquer sistema bancário tradicional.” Outras características não 

consideradas na anĂĄlise foram a eficiĂŞncia, qualidade e produtividade, uma vez que 

remetiam para atributos de carĂĄter operacional e nĂŁo estratĂŠgico.  



Danny E. S. de Jesus                                ANÁLISE DA PROPOSTA DE VALOR POTENCIAL NA APLICAÇÃO DO  BLOCKCHAIN À INDUSTRIA 

DE JOGO ONLINE EM PORTUGAL 

3 
 

Esta dissertação encontra-se organizada em 5 capítulos. O primeiro introduz o 

tema de investigação. O segundo consiste numa revisão da literatura, aprofundando os 

principais conceitos do estudo: tecnologia, modelo de negĂłcio, proposta de valor e 

Blockchain, destacando os seus atributos, limitaçþes e variedades de aplicação. O terceiro 

capĂ­tulo consiste na anĂĄlise da metodologia utilizada e na escolha da indĂşstria em questĂŁo. 

O quarto capĂ­tulo aborda a anĂĄlise dos resultados e o quinto as principais conclusĂľes, 

contribuiçþes para uma investigação futura e limitaçþes. 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 



Danny E. S. de Jesus                                ANÁLISE DA PROPOSTA DE VALOR POTENCIAL NA APLICAÇÃO DO  BLOCKCHAIN À INDUSTRIA 

DE JOGO ONLINE EM PORTUGAL 

4 
 

2. RevisĂŁo da literatura 

 

O objetivo da presente dissertação Ê analisar o impacto da implementação do 

Blockchain no modelo de negĂłcio dos operadores licenciados no mercado portuguĂŞs, 

determinando quais os fatores que poderão estar na base da criação de uma nova proposta 

de valor na indústria de jogos online. De forma a introduzir o tema da dissertação serå 

necessårio descrever o conceito de tecnologia e a relação com o modelo de negócio, 

proposta de valor e adicionalmente o conceito, atributos e arquiteturas do Blockchain.  

2.1. Tecnologia  

 

De acordo com Christensen (1997), todas as empresas dispĂľem de tecnologias. O 

termo tecnologia ĂŠ bastante difuso, amplo e usado por diversos autores. Um dos conceitos 

de tecnologia, é utilizado por Clayton Christensen (1997, p. 16) no seu livro “O dilema 

da inovação”, referindo-se”aos processos pelos quais uma organização transforma 

trabalho, capital, materiais e informação em produtos e serviços de maior valor”. A 

tecnologia “refere-se também a conhecimentos teóricos e práticos, habilidades e artefatos 

que podem ser usados para desenvolver produtos e serviços, bem como os seus sistemas 

de produção e entrega”. (Burgelman, Christensen & Wheelwright, 2009, p. 2). 

Schumpeter (1934), descreve o desenvolvimento tecnológico como uma mudança 

descontínua e em desequilíbrio resultante da inovação, identificando como vårias fontes 

de inovação, a introdução de novos produtos ou novos mÊtodos de produção, a criação de 

novos mercados, a descoberta de novas fontes de abastecimento e a reorganização das 

indĂşstrias. A tecnologia ĂŠ um elemento central e impulsionador na estratĂŠgia empresarial 

de criação de valor, contribuindo para a satisfação das necessidades específicas do 

mercado. A tecnologia pode ser um coeficiente de alavancagem e de diferenciação nas 

organizaçþes e indústrias e o seu desenvolvimento Ê geralmente considerado um 

empreendimento probabilĂ­stico e imprevisĂ­vel (Christensen, 1997). A decisĂŁo de 

enveredar pela aplicação de novas tecnologias Ê um fator estratÊgico essencial e vital para 

muitas organizaçþes pois representam uma oportunidade de incrementar a eficiência. A 

tecnologia Ê um recurso extremamente importante para muitas organizaçþes e a gestão 



Danny E. S. de Jesus                                ANÁLISE DA PROPOSTA DE VALOR POTENCIAL NA APLICAÇÃO DO  BLOCKCHAIN À INDUSTRIA 

DE JOGO ONLINE EM PORTUGAL 

5 
 

deste recurso para tornĂĄ-lo uma vantagem competitiva implica integrĂĄ-la na estratĂŠgia da 

empresa (Burgelman et al, 2009).  No entanto, as inovaçþes tecnológicas por si só não 

garantem o sucesso de uma empresa (Zott et al, 2011). PorĂŠm, uma das premissas 

favorĂĄveis ao desenvolvimento tecnolĂłgico ĂŠ que pode facilitar novos modelos de 

negócio (Baden-Fuller & Haefliger, 2013). Chesbrough (2010, p. 355), argumenta “que 

uma potencial nova tecnologia pode nĂŁo ter nenhum modelo de negĂłcio Ăłbvio, e nesses 

casos os gestores da tecnologia devem expandir as suas perspetivas de forma a encontrar 

um modelo de negócio apropriado a fim de poder capturar o valor dessa tecnologia”. 

Contudo, ĂŠ necessĂĄrio distinguir entre tecnologias sustentadoras e tecnologias disruptivas. 

As tecnologias disruptivas alteram a proposta de valor num mercado (Christensen, 1997) 

e quando surgem pela primeira vez quase sempre oferecem desempenhos mais baixos em 

termos dos atributos valorizados pelos consumidores do mercado dominante. As 

tecnologias disruptivas tĂŞm outros atributos valorizados por uma minoria (geralmente 

recente) de consumidores (Christensen, 1997). Segundo o mesmo autor, as tecnologias 

sustentadoras propiciam uma melhoria no desempenho dos produtos jĂĄ existentes e neste 

contexto, a anålise e o planeamento são praticåveis, enquanto que em inovação disruptiva, 

hå menos informação sobre o mercado e muita incerteza porque o seu valor e a sua 

aplicaçao são incertos. Na concepção de Osterwalder & Pigneur (2010), a tecnologia Ê 

um dos principais fatores que influenciam o desenvolvimento de modelos de negĂłcio, a 

par da tendĂŞncia regulatĂłria, societal, cultural e tambĂŠm sĂłcioeconĂłmica.  

 

2.2. Modelos de negĂłcio 

 

A complexidade na definição do conceito de modelo de negócio tem origem nas 

inĂşmeras referĂŞncias em trabalhos acadĂŠmicos, que tĂŞm contribuido com vĂĄrias 

perspetivas e modelos, o que torna difícil a sua anålise e clarificação. Zott et al (2011, p. 

1020), argumentam que os acadĂŠmicos nĂŁo estĂŁo de acordo sobre o que ĂŠ o modelo de 

negócio e “que a literatura se está a desenvolver em grande parte em silos, de acordo com 

os fenómenos de interesse dos respectivos investigadores”. Observa-se que os 

investigadores adotam frequentemente definiçþes idiossincråticas que se ajustam aos 

propĂłsitos dos seus estudos, mas que sĂŁo difĂ­ceis de conciliar uns com os outros (Zott et 



Danny E. S. de Jesus                                ANÁLISE DA PROPOSTA DE VALOR POTENCIAL NA APLICAÇÃO DO  BLOCKCHAIN À INDUSTRIA 

DE JOGO ONLINE EM PORTUGAL 

6 
 

al, 2011). Embora, existam diferenças substanciais nos vårios estudos analisados por Zott, 

houve alguns pontos em comum entre os vários investigadores, especificamente, “(1) o 

modelo de negĂłcio estĂĄ a emergir como uma nova unidade de anĂĄlise; (2) os modelos de 

negĂłcio enfatizam uma abordagem holĂ­stica em nĂ­vel de sistema para explicar como as 

empresas ""fazem negĂłcios""; (3) as atividades firmes desempenham um papel importante 

nas diversas conceptualizaçþes dos modelos de negócio propostos; e (4) modelos de 

negócio procuram explicar como o valor é criado e não apenas como é capturado” (Zott 

et al, 2011, p. 1019). Para Chesbrough e Richard Rosembloom, o modelo de negĂłcio deve 

cumprir algumas funçþes, das quais se destacam a articulação com a proposta de valor (i. 

e. o valor criado para os utilizadores por uma oferta baseada em tecnologia), identificação 

de um segmento de mercado e especificação do mecanismo de geração de receita 

(Chesbrough, 2010). Segundo Osterwalder & Pigneur (2010), o modelo de NegĂłcios 

descreve a lógica como uma organização cria, entrega e captura valor. Para Teece (2010), 

o modelo de negĂłcio descreve como a empresa cria e entrega valor aos consumidores, 

convertendo os pagamento recebidos em lucros, enquanto que Timmers (1998, p. 4), 

argumenta “que o modelo de negócio corresponde à 1) arquitetura para o produto, serviço 

e fluxos de informação, incluindo uma descrição dos vårios atores de negócios e os seus 

papÊis, 2)  a uma descrição dos potenciais benefícios para os vårios intervenientes 

empresariais e 3) a uma descrição das fontes de receitas”. Um bom modelo de negócio 

cria propostas de valor que sĂŁo atraentes para os clientes, atinge custos e estruturas de 

risco aceitĂĄveis e permite a captura de valor significativo pela empresa (Teece, 2010). Os 

modelos de negócio são “frequentemente exigidos pela inovação tecnológica que cria 

tanto a necessidade de trazer descobertas ao mercado como a oportunidade de satisfazer 

as necessidades do cliente não correspondidas” (Teece, 2010, p. 176). Mas, de forma a 

afigurar-se como uma vantagem competitiva, o modelo de negĂłcios tem de ser mais do 

que uma forma lĂłgica de fazer negĂłcios e atender Ă s necessidades especĂ­ficas dos clientes 

(Teece, 2010). No entanto, modelo de negĂłcio nĂŁo deve ser confundido com modelo de 

receita, que consiste no modo especĂ­fico em que um modelo de negĂłcios permite a 

geração de receita (Amit & Zott, 2001). Enquanto que um modelo de negócio se refere à 

criação de valor, um modelo de receita estå principalmente relacionado com a apropriação 

de valor (Amit & Zott, 2001). Segundo Mitchell & Coles (2003), alĂŠm de adotar modelos 

de negócio para facilitar a inovação tecnológica e a gestão da tecnologia, as empresas 



Danny E. S. de Jesus                                ANÁLISE DA PROPOSTA DE VALOR POTENCIAL NA APLICAÇÃO DO  BLOCKCHAIN À INDUSTRIA 

DE JOGO ONLINE EM PORTUGAL 

7 
 

podem ver o próprio modelo de negócios como um assunto de inovação. A inovação no 

modelo de negócio Ê importante, mas ainda dificil de alcançar (Chesbrough, 2010), 

devendo-se evitar o foco exclusivamente em segmentos de consumidores existentes e 

definir as suas visþes em segmentos novos ou não alcançados (Osterwalder & Pigneur, 

2010). As configuraçþes de ativos e processos e a incapacidade dos gestores para entender 

o potencial de valor de um novo modelo de negĂłcio afiguram-se como as principais 

barreiras à implementação de um novo modelo de negócio (Chesbrough, 2010). 

Chesbrough (2010) propþe ultrapassar as barreiras existentes à implementação de um 

novo modelo de negócio atravÊs da experimentação, embora não seja suficiente. A 

proposta inclui para alÊm da experimentação, a efetivação e uma liderança 

organizacional. Para experimentar deverĂŁo ser construidos mapas de modelos de negĂłcio 

considerando combinaçþes alternativas de processos. Segundo Chesbrough, (2010, p. 

362) “algumas experiências vão falhar, mas uma vez que informa sobre novas abordagens 

e ajuda na compreensão dentro das limitaçþes da perda disponível, este facto Ê expectåvel 

– ou mesmo incentivado”.  

 

2.3. Proposta de valor 

 

Segundo Tzocas & Saren (1999), o conceito de valor assume bastante importância 

para a disciplina de marketing, mas pouco esforço de investigação tem sido dedicado a 

examinar o que ĂŠ o valor, como ĂŠ produzido, entregue, consumido e como ĂŠ 

percepcionado pelo cliente. Este esforço foi principalmente localizado em åreas como a 

estratĂŠgia e gestĂŁo estratĂŠgica, psicologia e sociologia do comportamento do consumidor, 

contabilidade e finanças (Tzocas & Saren, 1999). Klang, WallnÜfer & Hacklin (2014), 

encontram na sua revisão que muitas definiçþes de modelo de negócio estão fortemente 

relacionadas com o conceito de valor e/ou o conceito de estratĂŠgia. De acordo com Klang 

et al (2014) os processos de valor e valor relacionados desempenham um papel central 

em todas as discussões relacionadas aos modelos de negócio. À semelhança do conceito 

de modelo de negócio, o valor tambÊm assume vårias definiçþes que evoluiram ao longo 

do tempo. Para Adam Smith (1776), o valor tem dois significados: Ă s vezes designa a 

utilidade de um determinado objeto, e outras vezes o poder de compra que o referido 



Danny E. S. de Jesus                                ANÁLISE DA PROPOSTA DE VALOR POTENCIAL NA APLICAÇÃO DO  BLOCKCHAIN À INDUSTRIA 

DE JOGO ONLINE EM PORTUGAL 

8 
 

objeto possui, em relação a outras mercadorias, em que o primeiro se designa de ""valor 

de uso"", e o segundo, ""valor de troca"". De acordo com Porter (1985, p.3), “valor é o que 

os compradores estão dispostos a pagar, e o valor superior decorre da oferta de preços 

mais baixos do que os concorrentes para benefĂ­cios equivalentes ou proporcionando 

benefícios únicos a um preço mais elevado”. Esta definição reflete o que Porter (1985) 

designa de vantagem competitiva, que pode ser obtida de duas formas: liderança em 

custos ou diferenciação. Segundo Porter (1985), na estratÊgia de diferenciação, a empresa 

procura ser Ăşnica no seu setor, em algumas dimensĂľes amplamente valorizadas pelos 

compradores enquanto que numa estratÊgia de liderança em custos, a empresa se propþe 

a produzir ao menor custo.  Se o produto de uma indĂşstria nĂŁo cria muito valor para seus 

compradores, hĂĄ pouco valor a ser capturado por empresas, nĂŁo obstante os outros 

elementos da estrutura (Porter, 1985). O valor pode ser criado pela diferenciação ao longo 

de cada etapa da cadeia de valor, atravĂŠs de atividades que resultam em produtos e 

serviços que reduzem os custos dos compradores ou aumentam o desempenho dos 

compradores (Porter, 1985). No entanto, Walter, Ritter & GemĂźnden, (2001, p. 366) 

entendem o valor como “o trade-off percepcionado entre múltiplos benefícios e 

sacrifĂ­cios adquiridos atravĂŠs de um relacionamento com o cliente pelos tomadores de 

decisão na organização do fornecedor”. De acordo com Amit & Zott (2001), os recentes 

avanços nas tecnologias da comunicação e da informação, como o surgimento e a råpida 

expansão da Internet e o råpido declínio dos custos de computação e comunicação, 

permitiram o desenvolvimento de novas formas de criar e entregar valor (como citado em 

Zott et al, 2011). Surgiram portanto outras definiçþes de valor orientadas para o e-

business, como a de Amit & Zott (2001), em que o termo ""valor"" refere-se ao valor total 

criado em transaçþes de e-Business, independentemente de ser a empresa, o cliente ou 

qualquer outro participante na transação que se aproprie desse valor. Ou seja, o conceito 

""valor"" (adotado de Brandenburger & Stuart. 1996), refere-se ao valor total criado como 

a soma dos valores apropriados por cada parte envolvidos numa transação. De acordo 

com Hamel (2000), as empresas devem desenvolver novos modelos de negĂłcio, nos quais 

a criação de valor e a captura de valor ocorrem numa rede de valor, que pode incluir 

fornecedores, parceiros, canais de distribuição, entre outros. Amit & Zott (2001, p. 496) 

argumentam que as “oportunidades de criação de valor nos mercados virtuais podem 

resultar de novas combinaçþes de informaçþes, produtos e serviços físicos, configuraçþes 



Danny E. S. de Jesus                                ANÁLISE DA PROPOSTA DE VALOR POTENCIAL NA APLICAÇÃO DO  BLOCKCHAIN À INDUSTRIA 

DE JOGO ONLINE EM PORTUGAL 

9 
 

inovadoras de transaçþes e a reconfiguração e integração de recursos, capacidades, 

funções e relacionamentos entre fornecedores, parceiros e clientes”. A criação de valor é 

uma parte fundamental no modelo de negĂłcios, descrevendo o que ĂŠ oferecido e como o 

valor ĂŠ criado para as vĂĄrias partes envolvidas: clientes, parceiros e outros participantes. 

(Johnson, Whittington, Scholes, Angwin & RegnÊr, 2017). A principal preocupação aqui 

ĂŠ, portanto, o segmento de clientes-alvo e a forma como as suas necessidades sĂŁo 

atendidas e os seus problemas resolvidos, mas tambĂŠm como criar valor para quaisquer 

outras partes (Johnson et al, 2017). Descobrir como fornecer valor ao cliente e como 

capturar esse valor constituem os principais problemas na concepção de um modelo de 

negĂłcio (Teece, 2010). Para descrever os modelos de negĂłcio, Johnson et al (2017), 

recorrem a um modelo composto por componentes inter-relacionados, nomeadamente a 

a) criação de valor, abordando as necessidades e problemas de um segmento de cliente 

específico e os de outros participantes, b) configuração de valor dos recursos e atividades 

que produzem esse valor e c) captura de valor, descrevendo os fluxos de receita e as 

estruturas de custos que permitem que a organização e outras partes interessadas 

obtenham uma parte do valor total gerado. No entanto, a anĂĄlise de Johnson et al (2017) 

ĂŠ limitativa, porque nĂŁo inclui a proposta de valor. PorĂŠm, no modelo CANVAS, a 

proposta de valor Ê incluída, sendo descrita como o pacote de produtos e serviços que 

criam valor para um segmento de cliente especĂ­fico, resolvendo um problema ou 

sa";"""date"",""2020-01-03T23:11:22Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.7""
""pdf:docinfo:title"",""Microsoft Word - Tese_Mestrado_Versao_final_a_submeter_Danny_Jesus_GEI.docx""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dc:creator"",""Danny Jesus""
""dcterms:created"",""2020-01-03T23:11:22Z""
""language"",""pt""
""Last-Modified"",""2020-01-03T23:11:22Z""
""dcterms:modified"",""2020-01-03T23:11:22Z""
""dc:format"",""application/pdf; version=1.7""
""title"",""Microsoft Word - Tese_Mestrado_Versao_final_a_submeter_Danny_Jesus_GEI.docx""
""Last-Save-Date"",""2020-01-03T23:11:22Z""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2020-01-03T23:11:22Z""
""meta:save-date"",""2020-01-03T23:11:22Z""
""pdf:encrypted"",""false""
""dc:title"",""Microsoft Word - Tese_Mestrado_Versao_final_a_submeter_Danny_Jesus_GEI.docx""
""modified"",""2020-01-03T23:11:22Z""
""Content-Length"",""1241239""
""pdf:hasMarkedContent"",""false""
""Content-Type"",""application/pdf""
""pdf:docinfo:creator"",""Danny Jesus""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Danny Jesus""
""meta:author"",""Danny Jesus""
""meta:creation-date"",""2020-01-03T23:11:22Z""
""created"",""2020-01-03T23:11:22Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""53""
""Creation-Date"",""2020-01-03T23:11:22Z""
""resourceName"",""DM-DESJ-2019.pdf""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""261"",""350"",""38"",""276"",""1951"",""1806"",""4105"",""1405"",""2384"",""2560"",""749"",""2388"",""2540"",""2898"",""2463"",""2882"",""2609"",""2009"",""2361"",""2469"",""2314"",""2423"",""1918"",""2031"",""2216"",""2425"",""2464"",""2388"",""2253"",""1950"",""2776"",""2358"",""2184"",""2099"",""2478"",""2671"",""638"",""2544"",""2699"",""2412"",""2429"",""2577"",""1822"",""2003"",""2233"",""2114"",""2265"",""2232"",""2208"",""1982"",""940"",""1082"",""1175""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""Author"",""Danny Jesus""
""producer"",""Microsoft: Print To PDF""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""Microsoft: Print To PDF""
""pdf:docinfo:created"",""2020-01-03T23:11:22Z""
";https://scholar.google.com/scholar?start=550&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094605-923;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Identity-based revocation from subset difference methods under simple assumptions;K Lee, JH Park ; IEEE Access, 2019  ieeexplore.ieee.org;;"… by combining the subset difference (SD) method of Naor, Naor, and Lotspiech (CRYPTO 2001)

and … is proven to be secure under q-type assumption in the random oracle model … an interesting

problem to build an SRE scheme under standard assumptions without random oracles …";Cité 6 fois;Les 5 versions;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/6287639/8600701/08708190.pdf;"
		
	";"""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""dc:title"",""IEEE Xplore Full-Text PDF:""
""Content-Encoding"",""UTF-8""
""resourceName"",""08708190.pdf""
""language"",""es""
""Content-Length"",""2565""
""title"",""IEEE Xplore Full-Text PDF:""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=740&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094616-980;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[HTML][HTML] Decentralized blacklistable anonymous credentials with reputation;R Yang, MH Au, Q Xu, Z Yu ; Computers & Security, 2019  Elsevier;;"… To see this, recall that in a blockchain-based (blacklistable) decentralized anonymous credential

system, users registers by putting its credential to the ledger … be generated by a simulator who

is only given the description of the statement (but may control the random oracle or the …";Cité 13 fois;Les 6 versions;[HTML] sciencedirect.com;https://www.sciencedirect.com/science/article/pii/S0167404818313282?casa_token=YBpUhIS0wbAAAAAA:o5XvMN43vX-8EwS-YwDK5_EHdZDC3AehqcIl7OOTM_wbBI5mhVP8_C-QFHJxaRuBzFAihVM-;;;https://scholar.google.com/scholar?start=790&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094658-1159;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[PDF][PDF] Distributed key generation with Ethereum smart contracts;P Schindler, A Judmayer, N Stifter, E Weippl ; CIW'19: Cryptocurrency …, 2019  sqi.at;;"… sufficient waiting times between phases, to ensure that agreement on a common-prefix [11] of

the Ethereum blockchain is reached … EIPS/eip-197.md, Accessed: 2018-12-15 6. Cachin, C.,

Kursawe, K., Shoup, V.: Random oracles in constantinople … In: Brassard, G. (ed.) CRYPTO …";Cité 2 fois;Les 3 versions;[PDF] sqi.at;https://www.sqi.at/resources/Schindler-2019-CIW-Distributed-Key-Generation-with-Ethereum-Smart-Contracts.pdf;"
Distributed Key Generation
with Ethereum Smart Contracts

Philipp Schindler1 ďż˝, Aljosha Judmayer1,
Nicholas Stifter1,2, and Edgar Weippl1,2

1 SBA Research, Austria
{pschindler,ajudmayer,nstifter,eweippl}@sba-research.org

2 Vienna University of Technology, Austria

Abstract. Distributed key generation (DKG) is a fundamental build-
ing block for a variety of cryptographic schemes and protocols, such as
threshold cryptography [9], multi-party coin tossing schemes [1], pub-
lic randomness beacons [20] or (BFT) consensus protocols [6,19]. More
recently, the surge in interest for blockchain technologies, and in partic-
ular the quest for developing scalable protocol designs, has renewed and
strengthened the need for efficient and practical DKG schemes. Surpris-
ingly, the availability of DKG protocol implementations and analyses of
their practicability is still highly limited, given their broad range of ap-
plications. We hereby help close this gap by presenting a fully functional,
well documented, economically viable DKG implementation3 for deriving
keys to use with BLS threshold signatures as an Ethereum smart con-
tract. Given the current Ethereum block gas limit (∟ 8M), it is possible
to support up to n = 256 nodes while ensuring that any necessary con-
tract call can still be executed within a single block. The practicability
of our implementation is further demonstrated through the deployment
and successful execution of our DKG contract in the Ropsten testnet.

1 Introduction

The goal of a DKG scheme is to agree on a secret that is shared among a set of n
participants such that only a subset of t < n nodes can use or reveal the secret.
Secret sharing schemes, e.g. Shamir Secret Sharing [24], or (publicly) verifiable
variants, assume a (trusted) dealer that wants to share a secret it knows. In
contrast, in a DKG protocol no single party has knowledge of the secret that is
being shared [14].

Interestingly enough, while the topic of DKG has already been extensively
discussed in the literature, for example, by the works of Genanaro et al. [12] or,
more recently, Kate and Goldberg [15], practical open source implementations of
DKG protocols are still rare. We aim to close this gap by providing a lightweight
implementation of a DKG protocol based on modern pairing based threshold

3 The source code, documentation, and logs of a successful execution in the Ropsten
testnet are available at https://github.com/PhilippSchindler/ethdkg/.

https://github.com/PhilippSchindler/ethdkg/


2 P. Schindler et al.

cryptography. Our implementation consists of (i) a client application executed
by each party participating in the DKG protocol, and (ii) an Ethereum smart
contract which ensures that adversarial behavior of any minority of clients cannot
prevent the protocol from producing the desired protocol output.

2 Use Cases

The ability to avoid or reduce the necessity to trust in any single third party
in a DKG is an appealing characteristic, in particular in the context of per-
missionless cryptocurrencies and blockchain technologies. Recent improvement
proposals for blockchain and other distributed ledger protocols, e.g. randomized
BFT consensus protocols such as Honeybadger [17], the Dfinity blockchain pro-
tocol [13] or Calypso [16], are increasingly relying on threshold cryptography
as part of the presented scheme. In this scenarios, one typically does not want
to trust a single centralized entity for the required protocol setup, but instead
use DKG protocols as an alternative without trusted authorities. Our DKG pro-
tocol is particularly suitable for such scenarios as it can be executed on the
readily available Ethereum platform, provides flexible means for registration of
the participants, and tolerates faulty or adversarial behavior of any minority of
participants.

Our smart contract based DKG protocol can also be used to bootstrap a
variety of interesting applications on the Ethereum platform itself. A candidate
example is a decentralized source of publicly-verifiable, bias-resistant and un-
predictable randomness, or short, a randomness beacon [20]. By levering the
security and uniqueness properties of BLS threshold signatures, the construc-
tion of a randomness beacon follows naturally. Within the Ethereum platform,
such trustworthy randomness beacons are particularly useful, as there are cur-
rently no built-in mechanisms for deriving randomness with the aforementioned
characteristics. Consequently, Ethereum smart contracts largely rely on less se-
cure sources of randomness (such as the block hash) or even depend on trusted
third parties. Beyond an application in Ethereum smart contracts, unpredictable
bias-resistant public randomness also plays an important role in a broad range of
fields, including proof-of-stake and sharding protocols, privacy preserving mes-
saging services, e-voting protocols, as well as gambling and lottery services [23].

Another Ethereum related use case for our DKG includes wallet contracts
where multiple signatures are required to initiate some action, such as performing
transactions, which can be verified with a constant amount of computation in
the contract.

Our DKG can also be used to setup the public key in a threshold public
key encryption scheme [8]. In such a scenario, a client could encrypt a message
under the generated master public key such that the decryption of the mes-
sage requires the collaboration of a threshold of participants from the DKG.
Combined with smart contracts, one can construct an incentive-based timelock
encryption protocol [22].



Distributed Key Generation with Ethereum Smart Contracts 3

3 Related Work

To the best of our knowledge, the DKG protocol [18] developed by the Orbs Net-
work team is the only publicly available protocol targeting a similar deployment
scenario, namely, an implementation of a DKG protocol using the Ethereum
platform. However, the presented prototypical implementation appears to be in-
complete and has not been updated in over 4 months. For example, countermea-
sures to protect against key cancellation attacks [2] are not (yet) implemented,
although documentation in the contract source code (dkg.sol) suggests that
the team is aware of the issue. In the herein presented DKG protocol we provide
a mechanism to protect against these kinds of attacks using a non-interactive
zero-knowledge proof, which can be efficiently verified by the smart contract.
Additionally, our protocol can tolerate up to f = dn2 e−1 Byzantine participants
while still completing successfully. In contrast, the Orbs Network implemen-
tation requires a protocol restart even if just a single adversarial participant
sends an invalid share. Furthermore, we not only provide an implementation of
the smart contract itself, but also make the the implementation of the client
software that handles the necessary interactions with the Ethereum blockchain
publicly available.

4 High Level Protocol Description

Our DKG protocol is tailored towards a practical implementation to be used with
the Ethereum blockchain and was not yet presented in a standalone setting. The
protocol is inspired by the original presentation of secret sharing by Shamir [24]
and the aggregation properties of the BLS signature scheme [2,3,4]. Our protocol
operates in four consecutive phases and the smart contract ensures that the
functions can only be executed during the correct phases. Further, the smart
contract and client software upholds sufficient waiting times between phases,
to ensure that agreement on a common-prefix [11] of the Ethereum blockchain
is reached (with high probability) before taking state dependent actions. The
protocol phases are:

1. Registration: Each participant submits a transaction to the smart con-
tract that contains an individual public key.

2. Key Sharing: All Participants perform secret sharing of their private keys
with the nodes successfully registered in the previous step.

3. Dispute: Participants may complain about invalid shares received.
4. Finalization: The master public key is constructed, uploaded and verified.

In the following, we discuss each of the protocol phases in more detail.

4.1 Registration

During the registration phase, each participant prepares a BLS keypair and sends
the public key together with a non-interactive zero-knowledge (NIZK) proof of
knowledge [7] of the secret key to the smart contract. This proof is required to
protect against rogue key attacks [2], where an adversary crafts a public key in



4 P. Schindler et al.

a way that, upon aggregation, cancels out the keys from other participants. Fur-
thermore we use this proof to tie the participant’s externally owned Ethereum
account to the BLS public key submitted, to prevent an adversary from reg-
istering themselves with a public key copied from an honest participant. The
contract verifies the proof, stores the public key received, assigns the registrant
an incrementing id 1, 2, ..., n and triggers a Registration event to notify all par-
ticipants.

4.2 Key Sharing

Each of the n registered participants uses Shamir’s Secret Sharing [24] to share
its BLS secret key among all previously registered nodes. We set the secret shar-
ing threshold t =

⌊
n
2

⌋
+ 1. The shares are encrypted using a shared key, derived

from the issuer’s secret key and the receiver’s registered public key, similar to
the Diffie-Hellman key exchange protocol [10]. This construction ensures an that
all shared keys (between two correct clients) are different without requiring to
verifiably distribute O(n2) keys. In section 4.3, we show how to use this property
to deal with disputes without having to abort the protocol under adversarial be-
havior. To allow for share verification, each participant further needs to commit
to the coefficients of the secret sharing polynomial. The encrypted shares and
commitment are sent as a transaction to the smart contract, which triggers a
KeySharing event upon successful processing in the smart contract. Upon receiv-
ing a transaction with encrypted shares, the smart contract verifies that (i) a
participant is eligible to upload (i.e. that the contract is in the key sharing phase
and the participants has previously registered) and (ii) has provided the correct
number of shares (n − 1) and commitments (t). However the contract does not
(and cannot) decrypt the provided shares and check their validity. This verifi-
cation is performed by the client software, which is actively monitoring the p2p
network for newly mined blocks and is listening for KeySharing events. When
such an event is fired, the client first decrypts their respective share and then
verifies the decrypted share against the commitment to ensure its correctness.

4.3 Dispute

If a participant discovers that one (or more) of its received shares are invalid, it
files a dispute for each of the individual shares. For this purpose, the decryption
key (i.e. the shared key between the malicious share issuer and itself) is sent as
part of the dispute transaction to the smart contract. The smart contract can
then attempt to decrypt the share and check for its correctness. However, the
contract additionally needs to verify that the provided decryption key is indeed
correct. Otherwise an adversary could easily claim that shares it received are
invalid by providing an invalid decryption key. To allow for this verification, in
addition to the decryption key, a participant has to provide a NIZK proof [7]
showing that the decryption key is indeed valid. Notice that sending a dispute
transaction renders the corresponding decryption key public knowledge. How-
ever, as we ensure that all decryption keys (between correct nodes) are different,
the adversary cannot learn any additional information by forcing a correct node
to submit a dispute.



Distributed Key Generation with Ethereum Smart Contracts 5

4.4 Finalization

During the finalization phase each participant first determines the set of partic-
ipants that successfully shared their secret key. A participant is only part of this
set if it registered and shared its key successfully and there were no successful
disputes filed against the participant. After this set is established, each partici-
pant can compute its (individual) group secret key by computing the sum of the
received shares. Furthermore the master public key can be computed by adding
all public keys. As soon as any of the participants uploads this master public
key, and the smart contract verifies its correctness, threshold signatures under
this public key can be verified by the smart contract.

5 Evaluation

To show the viability of our protocol we deployed our DKG contract in
the Ethereum test network Ropsten and simulated a simple scenario with
5 participants running the client software. Clients A, B and C follow the
prescribed protocol, while client D aborts after the registration phase and
client E actively tries to manipulate the protocol run by providing an in-
valid share. The contract can be found using an Ethereum block explorer
such as https://ropsten.etherscan.io/ by supplying the contract address
0x64eB9cbc8AAc7723A7A94b178b7Ac4c18D7E6269. This exemplary protocol ex-
ecution is further documented in the Github repository https://github.com/

PhilippSchindler/ethdkg/evaluation/.
To highlight the scalability of our approach, we provide gas usage measure-

ments for all types of transactions a client (potentially) needs to execute during
a protocol run. We tested our implementation with up to 256 nodes and ob-
serve that the consumed gas for all transactions is well below the current block
gas limit of ∟ 8M . Deployment of a contract instance consumed ∟ 3.5M gas.
The most expensive operation, i.e. filing a dispute, only has to be executed if an
adversary actively tries to manipulate the protocol run. As in this case the adver-
sarial behavior can be cryptographically proven to the smart contract, a security
deposit could be used to refund the costs for a rightful dispute claim. Using the
suggested gas price estimate of 2.5 Gwei from https://ethgasstation.info/,
the cost of submitting a dispute in a scenario with 256 nodes is only ∟ 0.018
ETH (∟ $1.50).

6 Challenges

One of the major challenges faced is the implementation of the required cryp-
tographic primitives within the constraints imposed by the Ethereum platform.
While elliptic curve operations such as additions, multiplications and pairings
are efficiently computable on modern hardware, one needs to use a very lim-
ited set of instructions (i.e. precompiled contracts [21,5]) to efficiently perform
these calculations within the Ethereum EVM. In principle, one could imple-
ment any required operation using the available EVM opcodes. In practice, this
however leads to very high gas consumption for more involved computations.

https://ropsten.etherscan.io/
https://ropsten.etherscan.io/address/0x64eB9cbc8AAc7723A7A94b178b7Ac4c18D7E6269/
https://github.com/PhilippSchindler/ethdkg/evaluation/
https://github.com/PhilippSchindler/ethdkg/evaluation/
https://ethgasstation.info/


6 P. Schindler et al.

4 8 16 32 64 128 256
number of nodes

50000

100000

200000

400000

800000

1600000

3200000

6400000

co
ns

um
ed

 g
as

 

registration
finalization
block gas limit

key sharing
dispute

Fig. 1. Measured gas consumption per contract phase and participant

Consequently, it is necessary to stick to the built-in primitives, and find effi-
cient alternatives for operations which are not available directly. One particular
limitation we had to work around is that there are no elliptic curve additions
and multiplications for one of the two groups used for BLS signatures. A pos-
sible solution used to overcome this problem is to perform the computations
offline and verify the correctness using the precompiled pairing contract. The
lack of built-in operations for e.g. symmetric key encryption or signature verifi-
cation further necessitated the implementation of practical alternatives by hand.
To give another example for the faced challenges, we recall the BLS signature
verification mechanism: a signature σ is valid if and only if the pairing check
e(σ, g2) = e(H(m), pubkey) is successful. The pairing check itself can be per-
formed efficiently using a precompiled contract in Ethereum. The involved hash
function H(¡) however needs to map into an elliptic curve group. Consequently,
the built-in primitives for Keccak or SHA-256 hash functions cannot be used
directly. We follow the description of Boneh et al. [4] to implement a proper
hash function mapping map into the elliptic curve group.

Considering the protocol design itself, we present an efficient solution for
following challenges (in increasing complexity): (i) detection of malicious actions,
(ii) cryptographically proving such behavior within the smart contract, and (iii)
tolerating any minority of Byzantine participants without a protocol restart.

7 Conclusion

In this paper we highlight the importance of practical DKG protocols for a
wide range of cryptographic schemes and applications. We provide a working
and documented open source implementation of a practical DKG protocol ready
for deployment on the Ethereum platform. Thereby, we show how major en-
vironmental challenges can be overcome. Despite the constraints imposed by
Ethereum and the EVM, we not only demonstrate the feasibly of our approach,
but also highlight its practicability in regard to gas costs and the possible number
of participants.



Distributed Key Generation with Ethereum Smart Contracts 7

References

1. Blum, M.: Coin flipping by telephone a protocol for solving impossible problems.
ACM SIGACT News 15(1), 23–27 (1983)

2. Boneh, D., Drijvers, M., Neven, G.: Compact multi-signatures for smaller
blockchains. In: International Conference on the Theory and Application of Cryp-
tology and Information Security. pp. 435–464. Springer (2018)

3. Boneh, D., Gentry, C., Lynn, B., Shacham, H.: Aggregate and verifiably encrypted
signatures from bilinear maps. In: International Conference on the Theory and
Applications of Cryptographic Techniques. pp. 416–432. Springer (2003)

4. Boneh, D., Lynn, B., Shacham, H.: Short signatures from the weil pairing. In: Inter-
national Conference on the Theory and Application of Cryptology and Information
Security. pp. 514–532. Springer (2001)

5. Buterin, V., Reitwiessner, C.: EIP 197: Precompiled contracts for optimal ate pair-
ing check on the elliptic curve alt bn128 (2018), https://github.com/ethereum/
EIPs/blob/master/EIPS/eip-197.md, Accessed: 2018-12-15

6. Cachin, C., Kursawe, K., Shoup, V.: Random oracles in constantinople: Practi-
cal asynchronous byzantine agreement using cryptography. In: Proceedings of the
nineteenth annual ACM symposium on Principles of distributed computing. pp.
123–132. ACM (2000), https://www.zurich.ibm.com/~cca/papers/abba.pdf

7. Camenisch, J., Stadler, M.: Proof systems for general statements about discrete
logarithms. Technical report/Dept. of Computer Science, ETH Zürich 260 (1997)

8. Cramer, R., Gennaro, R., Schoenmakers, B.: A secure and optimally efficient multi-
authority election scheme. European transactions on Telecommunications 8(5),
481–490 (1997)

9. Desmedt, Y., Frankel, Y.: Threshold cryptosystems. In: Brassard, G. (ed.)
CRYPTO. Lecture Notes in Computer Science, vol. 435, pp. 307–315. Springer
(1989)

10. Diffie, W., Hellman, M.: New directions in cryptography. IEEE transactions on
Information Theory 22(6), 644–654 (1976)

11. Garay, J., Kiayias, A., Leonardos, N.: The bitcoin backbone protocol: Analysis and
applications. In: Annual International Conference on the Theory and Applications
of Cryptographic Techniques. pp. 281–310. Springer (2015)

12. Gennaro, R., Jarecki, S., Krawczyk, H., Rabin, T.: Secure distributed key genera-
tion for discrete-log based cryptosystems. In: International Conference on the The-
ory and Applications of Cryptographic Techniques. pp. 295–310. Springer (1999)

13. Hanke, T., Movahedi, M., Williams, D.: Dfinity technology overview se-
ries consensus system (2018), https://dfinity.org/pdf-viewer/library/

dfinity-consensus.pdf, rev. 1
14. Kate, A.: Distributed key generation and its applications (2010)
15. Kate, A., Goldberg, I.: Distributed key generation for the internet. In: 2009 29th

IEEE International Conference on Distributed Computing Systems. pp. 119–128.
IEEE (2009)

16. Kokoris-Kogias, E., Alp, E.C., Siby, S.D., Gailly, N., Gasser, L., Jovanovic, P.,
Syta, E., Ford, B.: Calypso: Auditable sharing of private data over blockchains.
Cryptology ePrint Archive, Report 2018/209 (2018), https://eprint.iacr.org/
2018/209

17. Miller, A., Xia, Y., Croman, K., Shi, E., Song, D.: The honey badger of bft pro-
tocols. In: Proceedings of the 2016 ACM SIGSAC Conference on Computer and
Communications Security. pp. 31–42. ACM (2016)

https://github.com/ethereum/EIPs/blob/master/EIPS/eip-197.md
https://github.com/ethereum/EIPs/blob/master/EIPS/eip-197.md
https://www.zurich.ibm.com/~cca/papers/abba.pdf
https://dfinity.org/pdf-viewer/library/dfinity-consensus.pdf
https://dfinity.org/pdf-viewer/library/dfinity-consensus.pdf
https://eprint.iacr.org/2018/209
https://eprint.iacr.org/2018/209


8 P. Schindler et al.

18. Orbs Network: DKG for BLS threshold signature scheme on the EVM using solidity
(2018), https://github.com/orbs-network/dkg-on-evm, Accessed: 2018-12-11

19. Rabin, M.O.: Randomized byzantine generals. In: Foundations of Computer Sci-
ence, 1983., 24th Annual Symposium on. pp. 403–409. IEEE (1983), https:

//www.cs.princeton.edu/courses/archive/fall05/cos521/byzantin.pdf

20. Rabin, M.O.: Transaction protection by beacons. Journal of Computer and System
Sciences 27(2), 256–267 (1983)

21. Reitwiessner, C.: EIP 196: Precompiled contracts for addition and scalar multi-
plication on the elliptic curve alt bn128 (2018), https://github.com/ethereum/
EIPs/blob/master/EIPS/eip-196.md, Accessed: 2018-12-15

22. Rivest, R.L., Shamir, A., Wagner, D.A.: Time-lock puzzles and timed-release
crypto (1996)

23. Schindler, P., Judmayer, A., Stifter, N., Weippl, E.: Hydrand: Practical continuous
distributed randomness. IACR Cryptology ePrint Archive 2018, 319 (2018)

24. Shamir, A.: How to share a secret. Communications of the ACM 22(11), 612–613
(1979)

https://github.com/orbs-network/dkg-on-evm
https://www.cs.princeton.edu/courses/archive/fall05/cos521/byzantin.pdf
https://www.cs.princeton.edu/courses/archive/fall05/cos521/byzantin.pdf
https://github.com/ethereum/EIPs/blob/master/EIPS/eip-196.md
https://github.com/ethereum/EIPs/blob/master/EIPS/eip-196.md

	Distributed Key Generation with Ethereum Smart Contracts

";"""date"",""2018-12-18T18:49:38Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2018-12-18T18:49:38Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017/Debian) kpathsea version 6.2.3""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2018-12-18T18:49:38Z""
""created"",""2018-12-18T18:49:38Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2018-12-18T18:49:38Z""
""resourceName"",""Schindler-2019-CIW-Distributed-Key-Generation-with-Ethereum-Smart-Contracts.pdf""
""Author"",""""
""producer"",""pdfTeX-1.40.18""
""pdf:docinfo:producer"",""pdfTeX-1.40.18""
""pdf:unmappedUnicodeCharsPerPage"",""1"",""0"",""2"",""2"",""0"",""0"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2018-12-18T18:49:38Z""
""Last-Modified"",""2018-12-18T18:49:38Z""
""dcterms:modified"",""2018-12-18T18:49:38Z""
""title"",""""
""Last-Save-Date"",""2018-12-18T18:49:38Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2018-12-18T18:49:38Z""
""meta:save-date"",""2018-12-18T18:49:38Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017/Debian) kpathsea version 6.2.3""
""Content-Length"",""238911""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""8""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""2086"",""2604"",""2476"",""2754"",""2539"",""2021"",""2890"",""936""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2018-12-18T18:49:38Z""
";https://scholar.google.com/scholar?start=970&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094586-845;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[CITATION][C] A Note on the (Im) possibility of Verifiable Delay Functions in the Random Oracle Model.;M Mahmoody, C Smith, DJ Wu ; IACR Cryptol. ePrint Arch., 2019;;null;Cité 6 fois;;null;;;;https://scholar.google.com/scholar?start=660&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094654-1140;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[PDF][PDF] Investigation on sharing signatures of suspected malware files using blockchain technology;R Fuji, S Usuzaki, K Aburada, H Yamaba… ; … Multi Conference of …, 2019  iaeng.org;;"… 6. To build a virtual environment on the computer, we installed Ubuntu 18.04 LTS using Oracle

VM VirtualBox. Also, to build a blockchain within a private network, we installed Geth, an Ethereum

client, and interacted with Geth through a Python script using Web3.py …";Cité 2 fois;Les 2 versions;[PDF] iaeng.org;http://www.iaeng.org/publication/IMECS2019/IMECS2019_pp94-99.pdf;"
Investigation on Sharing Signatures of Suspected
Malware Files Using Blockchain Technology
Ryusei Fuji, Shotaro Usuzaki, Kentaro Aburada, Hisaaki Yamaba, Tetsuro Katayama, Mirang Park,

Norio Shiratori and Naonobu Okazaki

Abstract—In recent years, the amount of new malware has
been rapidly increasing. Because malware has an adverse
effect on the Internet, upon which modern society is increas-
ingly dependent, its detection is very important. In addition,
blockchain technology has attracted the attention of many
people in recent years due to its four main characteristics of
decentralization, persistency, anonymity, and auditability. In
this paper, we propose a system for sharing the signatures
of suspected malware files using blockchain technology. The
proposed system can share the signatures of suspected files
between users, allowing them to rapidly respond to increasing
malware threats. Further, it improves the accuracy of detection
and removal of malware by utilizing signatures recorded by
the blockchain. In the evaluation experiment, we created a
prototype of the proposed system and investigated its effect on
the accuracy of detection and removal of malware. Compared
with heuristic methods or behavior-based methods only, the
proposed system which uses these methods plus signature-based
method using shared signatures on the blockchain improved the
false negative rate by about 4% and the false positive rate by
about 2.5%.

Index Terms—malware detection, blockchain technology,
Ethereum, smart contract.

I. INTRODUCTION

MALWARE is a portmanteau word combining “mali-
cious” and “software”, and it operates illegally with

the purpose of theft or destruction of a computer’s internal
information. Malware achieves its objectives in an infected
computer by performing illegal operations without detection
of its presence. An example of damage caused by malware
infection is ransomware, which interrupts operation of the
computer or encrypts the data inside it. The attacker will
request a ransom from the user in exchange for releasing
the restriction on access to the computer or its data. The
amount of pecuniary damage from ransomware in 2017 is
said to be USD 5 billion [1], which is a serious problem. In
addition, the presence of malware in Internet of Things (IoT)
equipment has been confirmed, with the “Mirai” malware
at the head of the list. In 2016, denial of service attacks
of up to 1.5 Tbps have been executed by exploiting IoT
devices infected with “Mirai” [2]. According to Security
Report 2017/2018 [3] published by AV-TEST, in recent years
the number of new malware programs observed is more than

Manuscript received December 20, 2018; revised February 6, 2019. This
work was supported by the Japan Society for the Promotion of Science,
Kakenhi Grants JP17H01736, JP17K00139, and JP18K11268.

R. Fuji, S. Usuzaki, K. Aburada, H. Yamaba, T. Katayama, and
N. Okazaki are with the Faculty of Engineering, Univ. Miyazaki,
Gakuen-kibanadai-nishi-1-1, Miyazaki 889-2192, Japan e-mail:
aburada@cs.miyazaki-u.ac.jp

M. Park is with Kanagawa Institute of Technology, 1030 Shimo-Ogino,
Atsugi, Kanagawa 243-0292, Japan.

N. Shiratori is with Research and Development Initiative, Chuo Univer-
sity, 1-13-27 Kasuga, Bunkyo-ku, Tokyo 112-8551, Japan

100 million per year, which means that about 4 new malware
programs are discovered per second. Clearly, malware has a
serious adverse effect on modern society by impacting the
Internet that it has been founded upon.

Malware detection techniques are roughly divided into
three types: signature-based methods, behavior-based meth-
ods, and heuristic methods [4]. Signature-based methods
are commonly used to detect malware. The signature is a
sequence of bytes with features extracted from malware,
and if the contents of an inspected file match one of these
signatures, the file is determined to be malware. Signature-
based methods have the advantage of reliably detecting
known malware, but they have the disadvantage of not being
able to detect unknown malware. Behavior-based methods
perform their malware detection by actually executing the file
under inspection and observing its behavior. These methods
can detect unknown malware that cannot be detected by
signature-based methods. However, these methods have the
disadvantage of a high false positive rate (FPR), which is the
rate of benign files being labeled as malicious files. Heuristic
methods are techniques that detect malware using data min-
ing and machine learning techniques. The features utilized
in heuristics methods include API call sequences issued to
the operating system and machine language instruction. The
main advantages and disadvantages of heuristics methods are
similar to those of the behavior-based detection methods.

To prevent malware infection, usually anti-virus software
provided by a vendor is installed on the computer. Generally
the malware signatures used by the anti-virus software are
distributed from the anti-virus vendors, who provide and
update these signatures by collecting and analyzing malware-
related information from sources such as users and online
malware inspection and analysis services. Hashimoto et al.
[5] provided information on malware that could not be
detected by anti-virus software to the vendor to calculate the
subsequent malware detection rates, and evaluated the anti-
virus software. According to the study, the malware detection
rates 30 days after providing the malware information were
50% at most. In other words, it is conceivable that an anti-
virus vendor alone cannot respond adequately to malware
that is rapidly increasing.

The above discussion suggests that not only should anti-
virus vendors collect malware information, but also users
should share this information with each other. To realize such
sharing of malware information among users, we adopted
blockchain technology.

Blockchain technology is the fundamental technology of
various virtual currencies, including Bitcoin, and it has
attracted much attention in recent years. Blockchain technol-
ogy was proposed by Nakamoto [6] in 2008 to realize the
Bitcoin network. This technology enables rapid transactions

Proceedings of the International MultiConference of Engineers and Computer Scientists 2019 
IMECS 2019, March 13-15, 2019, Hong Kong

ISBN: 978-988-14048-5-5 
ISSN: 2078-0958 (Print); ISSN: 2078-0966 (Online)

IMECS 2019



Fig. 1. Blockchain example

between users with a low cost and without mediation of
a central authority. Further, blockchain-based decentralized
applications (Dapps), such as uPort [7], have been emerging.
Dapps save and use certain information on a blockchain, and
their use is expected to increase.

In this paper, we propose a system for sharing the signa-
tures of suspected malware files using blockchain technology.
The proposed system allows the signatures of suspected files
to be shared between users, and we can more rapidly respond
to increasing malware. Furthermore, the shared signatures
make it is possible to improve the malware detection accu-
racy.

II. RELATED WORK

Jingjing et al. [8] proposed a framework, called Con-
sortium Blockchain for Malware Detection and Evidence
Extraction (CB-MDEE), that detects and classifies malware
for mobile devices. The CB-MDEE is composed of two
blockchains, a public blockchain (PB) and a consortium
blockchain (CB). Users belonging to the PB use a multi-
feature model created from, for example, sensitive behavior
graphs and installation packages, to detect and classify
malware, and store the information on the PB for subsequent
malware detection and classification. Members of malware
detection organizations belonging to the CB use the infor-
mation to create a fact base for updating the malware feature
database. In evaluation experiments, the CB-MDEE achieved
a classification accuracy of 94% for android malware.

Roman et al. [9] proposed a system to support cyber
analysts by classifying and managing cyber incident reports
using blockchain technology and a deep autoencoder neural
network. When a cyber expert enters a cyber incident report
into the system, the system classifies the report and returns
past similar incident reports. Because the classification and
management are executed automatically, the cyber expert can
adopt suitable countermeasures quickly. In the evaluation,
they used 5,850 training documents and 584 test documents
to validate the effectiveness of their proposed system. For
the “fulldisclosure” category, they achieved a true positive
rate 0.991 and an FPR of 0.059.

This study is based on the assumption that users belonging
to the blockchain have a different malware detection system
using behavior-based methods or heuristic methods. Then,
these detection results are saved as votes on the blockchain
for later use. As a result, we can detect and eliminate mal-
ware by utilizing the results of our own malware detection
system and votes of other users stored on the blockchain,
which is different from the above studies.

III. BLOCKCHAIN TECHNOLOGY

A. Overview of blockchain technology

Blockchain technology was proposed as a fundamental
technology for realizing Bitcoin in the paper published by
Nakamoto [6] in 2008. Bitcoin was realized by combining
several inventions to decentralize functions, such as currency
issuance and mediation of transactions, which banks typically
do. Due to the decentralized function, Bitcoin makes it
possible to issue currency and create transactions among
users without third-party institutions, such as banks. An
example of the blockchain is shown in Fig. 1.

When remitting coins between users, the user on the
remittance side issues a transaction describing the transfer
of value, including information such as remittance amount,
address of destination, and digital signature of the user on
the remittance side. The issued transactions are transmitted
and received between mutually connected nodes. The node
that received the transaction verifies the transaction, and if
the transaction is valid, the node sends it to the next node. By
this transaction transmission and reception activity, the issued
transaction is propagated to the entire blockchain network.
Ultimately, the transaction is included in the block by a
miner, and the remittance process is completed by becoming
a part of the blockchain. The blockchain maintains data in-
tegrity by using consensus algorithms, such as Proof of Work
(PoW), Proof of Stake, and Delegated Proof of Stake. Bitcoin
adopted PoW, which determines a cryptographic nonce so
that the block hash value satisfies a specific hash value
and generates the next block. Blocks generated by PoW are
propagated to the entire Bitcoin network by transmission and
reception of blocks between the nodes, and independently
verified. As a result of the verification, if the block is valid,
it is accepted into the Bitcoin network and becomes part of
the blockchain.

The blockchain has four main characteristics: decentral-
ization, persistency, anonymity, and auditability [10]. Based
on the above characteristics, this study adopted blockchain
technology, which enables rapid sharing of suspected mal-
ware signatures between users without the intervention of
a central organization, such as an anti-virus vendor. It is
possible to use these signatures to eliminate malware.

B. Blockchain platforms

Blockchain is the basis for various platforms, such as
Ethereum [11] and Hyperledger [12]. Ethereum is a platform
for building Dapps in an open-source development environ-
ment. We can develop various applications by executing a
programmed contract called a smart contract on the Ethereum
blockchain. We used Ethereum because it is already used as
a blockchain platform in many Dapps, such as uPort [7].

IV. PROPOSED SYSTEM

In this section, we explain the proposed system.

A. Overview of proposed system

An overview of the proposed system is shown in Fig. 2.
The blockchain network is composed of users who want to
share and obtain malware information. Here, it is assumed
that each user’s computer hosts a heuristic or behavior-based

Proceedings of the International MultiConference of Engineers and Computer Scientists 2019 
IMECS 2019, March 13-15, 2019, Hong Kong

ISBN: 978-988-14048-5-5 
ISSN: 2078-0958 (Print); ISSN: 2078-0966 (Online)

IMECS 2019



TABLE I
DEFINITIONS FOR EACH SYMBOL

　 Symbols Definitions
Md Malicious degree
Mt Threshold for malicious degree
Vt Threshold for total votes
Vb The number of votes of ’benign’
Vm The number of votes of ’malicious’
Rv Voting confidence rate
Rs Self confidence rate
Dr Detection result of own malware detection system
Fv Voting fee
Rv The number of votes for compensation distribution

malware detection system and a signature-based system.
Also, we suppose these malware detection systems use
different features or methods. For example, the computer
of user 1 might have a heuristic malware detection system
based on API call sequences issued to the operating system
and the computer of user 2 might have a heuristic malware
detection system based on machine language instructions.
Both users also have a signature-based detection system. The
blockchain is used to store signatures (file hash values) and
other information from suspected malware files.

When a user downloads an executable file, heuristic or
behavior-based malware detection is executed first. If the
downloaded executable file is judged as malware, the user
sends the file hash value to the blockchain network as a sus-
pected malware file identity. When another user downloads
the same executable file, the user first checks whether the
file hash value of the executable file is already registered
as a suspected malware file identity on the blockchain. If
the same file hash value exists on the blockchain, the user’s
heuristic or behavior-based malware detection system judges
whether the file is malicious, and the result is sent as a vote
(malicious or benign) to the blockchain network. Thereafter,
based on the voting results on the blockchain and the results
of its own malware assessment, the user’s detection system
decides whether to remove the suspect file.

A flowchart showing the process for each user is provided
in Fig. 3, and symbols used in this paper are defined in
Table I.

B. Malware detection systems on user computers

In this study, we assume that each user belonging to
the blockchain network installs the following two malware
detection systems on the computer:

• Malware detection system using heuristic or behavior-
based methods
This program is executed when the user downloads an

executable file. In this study, it is assumed that each user
detects malware using different features or methods.

• Malware detection system using signature-based meth-
ods.

This system is responsible for investigating whether
signatures already exist on the blockchain. Also, it
calculates the degree of maliciousness and eliminates
the downloaded file according to the result.

Fig. 2. Overview of proposed system

Fig. 3. Flowchart of malware detection performed by each user

C. Detection of suspected files and transmission of file hash
values

When a user downloads an executable file, the heuristic
or behavior-based malware detection is executed first. Next,
the user’s computer checks whether the file hash value is
already registered as a suspected malware file hash value on
the blockchain. If the file hash value does not exist on the
blockchain, and if the malware detection system determines
that the downloaded file is malware, the computer sends the
file hash value to the blockchain network to share it and
then eliminates the file. When the file hash value exists on
the blockchain, the user’s detection system sends out the
result of its own malware analysis as a vote (“malicious”
or “benign”) to the blockchain network and then decides
whether to remove the file with the elimination decision
formula (see section IV-E).

D. Record components

Here we describe data such as file hash values and the
number of votes to be stored on the blockchain. Data stored
on the blockchain can be represented as a record, and its
details are shown in Fig. 4. As can be seen from Fig. 4, the
record is represented by the following five elements:

• Suspected file hash value
• Number of votes for “malicious”
• Number of votes for “benign”
• Addresses of users who voted “malicious”
• Addresses of users who voted “benign”

Proceedings of the International MultiConference of Engineers and Computer Scientists 2019 
IMECS 2019, March 13-15, 2019, Hong Kong

ISBN: 978-988-14048-5-5 
ISSN: 2078-0958 (Print); ISSN: 2078-0966 (Online)

IMECS 2019



Fig. 4. Details of a record

The numbers of votes for “malicious” and “benign”
are used to calculate the degree of maliciousness in the
elimination decision formula (section IV-E) to determine
whether to remove the file. The recording of user ad-
dresses prevents the same user from illegally voting more
than once. Here, the user address is not an IP ad-
dress but the address used on the blockchain, such as
“0xca35b7d915458ef540ade6068dfe2f44e8fa733c”.

E. Elimination decision formula

When the hash value of the downloaded file exists on the
blockchain, the user’s detection system determines whether
to remove the file based on the maliciousness degree given
by the elimination decision formula. That is, when equation
(1) is satisfied, the file is not deleted, and when equation (2)
is satisfied, the file is deleted.

Md ≤ Mt, (1)
Md > Mt, (2)

0 ≤ Md ≤ 1.

1) When Vm + Vb ≥ Vt: The user’s system uses only the
voting result on the blockchain and calculates the malicious-
ness degree with equation (3).

Md =
Vm

Vm + Vb
. (3)

2) When Vm + Vb < Vt: The user’s system calculates
maliciousness degree with expression (4), the results of vot-
ing on the blockchain, and its own malware detection results
by heuristic or behavior-based methods. Here, it is assumed
that the malware detection system outputs 1 when the file is
malware and 0 when it is benign. That is, Dr ∈ {0, 1}.

Md =
Vm

Vm + Vb
×Rv +Dr ×Rs. (4)

where Rv and Rs are defined by the following expressions:

Rv =
Vm + Vb

Vt
, (5)

Rs = 1−Rv. (6)

3) Example: Suppose that an executable file is down-
loaded and voting for the file hash value on the blockchain
is 10 “malicious” votes (Vm = 10) and 5 “benign” votes
(Vb = 5). Also, the malware detection system judges the file
to be malware (Dr = 1), the threshold for total votes is set
to 20 (Vt = 20), and the threshold for maliciousness degree
is set to 0.5 (Mt = 0.5). The malicious degree Md in this
example is calculated as follows:

Md =
10

10 + 5
× 10 + 5

20
+ 1× (1− 10 + 5

20
) =

3

4
.

Because 3
4 > 0.5, the file will be deleted.

Fig. 5. Blockchain address registration

F. Countermeasure against mass voting by malicious users

The records stored on the blockchain include the addresses
of users who voted in order to prevent duplicate voting by
the same address. However, since any user can generate an
unlimited number of addresses, it is insufficient to use only
the measures described above. Therefore, we tried to solve
this problem by establishing a web server by trustworthy
organizations and institutions to register voting addresses
and limit the addresses eligible to vote. Fig. 5 shows the
countermeasures against mass voting by malicious users.

First, users who wish to participate in the Ethereum
blockchain network access the web server installed by trust-
worthy organizations and institutions and register an address
to be used for voting. The web server accesses the Register
smart contract on the Ethereum blockchain and registers the
address. After that, the user joins the network and acquires,
registers, and votes for signatures. The Vote smart contract,
which is responsible for signature acquisition, registration,
and voting, accesses the Register smart contract and checks
whether the address exists in the Register smart contract. If
the address exists, acquisition, registration, and voting of the
signature are accepted; otherwise, these are rejected.

Here, the web server prohibits the registration of con-
secutive addresses from the same IP address and confirms
the human by CAPTCHA. From the above, it is possible to
prevent the registration of addresses by malicious users and
bots.

G. Incentive design

To encourage user voting, we designed incentives for
dominant votes. The user pays a small voting fee when voting
for a suspected file hash value. The user issues a message that
an execution fee (Gas in Ethereum) is required to vote, but
in this study, we set the fee to 0 (that is, we set gasPrice to
0). The Vote smart contract distributes the collected voting
fee for each Rv for a suspected file hash value. Here, we
define the votes belonging to the detection result with more
votes as the dominant vote and the result with fewer votes
as the inferior vote. The voting fees are distributed only
to users who voted for the dominant vote for every Rv .
Voting fees are not distributed to users who cast an inferior
vote. Suppose that the number of dominant votes is DV and
number inferior votes is IV . Then, the voting fee V Fdist to

Proceedings of the International MultiConference of Engineers and Computer Scientists 2019 
IMECS 2019, March 13-15, 2019, Hong Kong

ISBN: 978-988-14048-5-5 
ISSN: 2078-0958 (Print); ISSN: 2078-0966 (Online)

IMECS 2019



TABLE II
PARAMETER DEFINITIONS FOR EQUATIONS (10) AND (11)

Symbol Definition
True Positive (TP) The number of malware detected as malware correctly

True Negative (TN) The number of benign files judged as benign files correctly
False Positive (FP) The number of benign files detected as malware mistakenly

False Negative (FN) The number of malware judged as benign files mistakenly

Fig. 6. Overview of experiment environment

be distributed is determined by the following equations:

V Fdist =
Fv ×Rv

DV
(for dominant votes), (7)

V Fdist = 0(for inferior votes), (8)
DV > IV,DV + IV = Rv. (9)

By the above incentive design, the frequency and correctness
of user voting will be promoted.

V. EVALUATION

In this section, we explain an evaluation experiment to
verify the effectiveness of the proposed system. The purpose
of the experiment is to investigate whether the accuracy of
detecting and removing malware is improved by using the
proposed system. To conduct the experiment, we created a
prototype of the proposed system.

A. Overview of evaluation experiment

An overview of the experimental environment is shown in
Fig. 6. To build a virtual environment on the computer, we
installed Ubuntu 18.04 LTS using Oracle VM VirtualBox.
Also, to build a blockchain within a private network, we
installed Geth, an Ethereum client, and interacted with Geth
through a Python script using Web3.py.

B. Detection accuracy indicators

We used the false negative rate (FNR) and FPR as eval-
uation indexes for malware detection and removal accuracy.
FNR is the rate at which malware is mistakenly judged as
a benign file, and FPR is the rate at which a benign file is
erroneously detected as malware.

FNR =
FN

TP + FN
, (10)

FPR =
FP

TN + FP
. (11)

The definitions of the symbols in equations (10) and (11) are
given in Table II.

C. Simulation procedure

In the evaluation experiment, it is assumed that no mali-
cious user exists and each user possesses the malware detec-
tion systems described in section IV-B. In this experiment,
rather than implementing user-specific malware detection
systems, we created pseudo malware detection systems that
have FPR and FNR as parameters. In addition, it is assumed
that each user performs the malware detection of heuristic
methods or behavior-based methods for all the predefined
files regarded as malicious or benign, and registers, votes,
and obtains information from the blockchain as necessary.

First, we created an address representing each user using a
Python script and interacting with Geth. Next, we deployed
the Register and Vote smart contracts on the blockchain and
registered the addresses that we originally created with the
Register smart contract.

The simulation continued until each address representing
the user performed malware detection and removal for all
predefined files regarded as malicious or benign.

D. Parameters

In this experiment using the system prototype, the number
of user addresses was 30, the number of file hash values
assumed as malicious or benign was 30 each, Vt = 15, and
Mt = 0.5.

In addition, the FPR and FNR of the pseudo malware
detection systems were set with reference to the literature
[13], where Windows malware was detected using machine
instruction sequences. Specifically, malicious instruction ex-
traction and malicious sequential pattern extraction (MSPE)
were used to efficiently and effectively obtain malicious se-
quences by heuristic methods. In the evaluation experiment,
the detection result with MSPE combined with all-nearest-
neighbor was the best result, achieving a detection rate of
96.17% (FNR of 3.17%) and FPR of 6.13%

They also experimented with combinations of other clas-
sifiers, and we set the FNR to 5% and FPR to 6% based on
their experiment results.

E. Results and discussion

The experimental results are shown in Table III. Case A
and Case B in the table are as follows:

• Case A
Heuristic methods or behavior-based methods only.

• Case B
Heuristic methods or behavior-based methods plus
signature-based method using signatures on the
blockchain.

FNR and FPR in Case B are the average for all users.

Proceedings of the International MultiConference of Engineers and Computer Scientists 2019 
IMECS 2019, March 13-15, 2019, Hong Kong

ISBN: 978-988-14048-5-5 
ISSN: 2078-0958 (Print); ISSN: 2078-0966 (Online)

IMECS 2019



TABLE III
EXPERIMENTAL RESULTS

FNR FPR
Case A 0.05 0.06
Case B 0.013 0.035

FNR and FPR in Case A are the values from section V-D.
From Table III, FNR and FPR in Case B improved by about
4% and 3%, respectively. Therefore, the proposed system
that utilizes the signatures from the blockchain can improve
the accuracy of detection and removal of malware. However,
the standard deviations of FNR and FPR were 0.044 and
0.022, respectively. For this reason, it was revealed that some
users who use the proposed system have degraded malware
detection and removal accuracy.

VI. SUMMARY

In this paper, we proposed a system to share and uti-
lize signatures of suspected malware files using blockchain
technology. This system aims to quickly share signatures
of suspected files among users and improve the accuracy
of detection and removal of malware without a centralized
organization, such as an anti-virus vendor. In the evaluation
experiment, we created a prototype of the proposed system
and investigated its accuracy for detecting and removing mal-
ware. The evaluation experiment showed that the proposed
system improved the FNR by about 4% and the FPR by
about 2.5%. For future work, it is necessary to evaluate the
proposed system using malware detection systems based on
actual heuristic or behavior-based methods. In addition, it is
necessary to set each parameter and precondition so as to
more accurately reflect the real world.

REFERENCES

[1] Sultan, Hirra, et al. ”A SURVEY ON RANSOMWARE: EVOLUTION,
GROWTH, AND IMPACT.” International Journal of Advanced Re-
search in Computer Science vol 9, No. 2 (2018).

[2] Barrera, David, Ian Molloy, and Heqing Huang. ”IDIoT: Securing the
Internet of Things like it’s 1994.” arXiv preprint arXiv:1712.03623
(2017).

[3] AV-TEST ”SECURITY REPORT 2017/18” available at:https:
//www.av-test.org/fileadmin/pdf/security report/AV-TEST Security
Report 2017-2018.pdf (accessed 2018/12/02).

[4] Bazrafshan, Zahra, et al. ”A survey on heuristic malware detection
techniques.” Information and Knowledge Technology (IKT), 2013 5th
Conference (2013):113-120.

[5] Ryota Hashimoto, Katsunari Yoshioka , and Tsutomu Matsumoto .
”Evaluation of Anti-Virus Software based on the Correspondence to
Non-Detected Malware” (in Japanese) Distributed Processing System
(DPS) (2012): 1-8.

[6] Nakamoto, Satoshi. ”Bitcoin: A peer-to-peer electronic cash system.”
(2008).

[7] uPort.me at:https://www.uport.me/ (accessed 2018/12/02).
[8] Gu, Jingjing, et al. ”Consortium Blockchain-Based Malware Detection

in Mobile Devices.” IEEE Access 6 (2018): 12118-12128.
[9] Graf, Roman, and Ross King. ”Neural network and blockchain based

technique for cyber threat intelligence and situational awareness.” 2018
10th International Conference on Cyber Conflict (CyCon). IEEE, 2018.

[10] Zheng, Zibin, et al. ”An overview of blockchain technology: Archi-
tecture, consensus, and future trends.” IEEE 6th International Congress
on Big Data (2017): 557-564.

[11] Ethereum Project available at:https://www.ethereum.org/ (accessed
2018/12/02).

[12] Hyperledger - Open Source Blockchain Technologies available
at:https://www.hyperledger.org/ (accessed 2018/12/02).

[13] Fan, Yujie, Yanfang Ye, and Lifei Chen. ”Malicious sequential pattern
mining for automatic malware detection.” Expert Systems with Appli-
cations 52 (2016): 16-25.

Proceedings of the International MultiConference of Engineers and Computer Scientists 2019 
IMECS 2019, March 13-15, 2019, Hong Kong

ISBN: 978-988-14048-5-5 
ISSN: 2078-0958 (Print); ISSN: 2078-0966 (Online)

IMECS 2019




";"""date"",""2019-03-18T12:04:19Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.5""
""xmp:CreatorTool"","" TeX output 2019.02.06:1441""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dcterms:created"",""2019-02-06T05:41:40Z""
""language"",""en""
""Last-Modified"",""2019-03-18T12:04:19Z""
""dcterms:modified"",""2019-03-18T12:04:19Z""
""dc:format"",""application/pdf; version=1.5""
""xmpMM:DocumentID"",""uuid:ec979e2b-aa63-4081-a6db-d1f4a96429c7""
""Last-Save-Date"",""2019-03-18T12:04:19Z""
""pdf:docinfo:creator_tool"","" TeX output 2019.02.06:1441""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2019-03-18T12:04:19Z""
""meta:save-date"",""2019-03-18T12:04:19Z""
""pdf:encrypted"",""false""
""xmp:CreateDate"",""2019-02-06T14:41:40Z""
""modified"",""2019-03-18T12:04:19Z""
""Content-Length"",""1313993""
""pdf:hasMarkedContent"",""false""
""Content-Type"",""application/pdf""
""xmp:ModifyDate"",""2019-03-18T20:04:19Z""
""xmp:MetadataDate"",""2019-03-18T20:04:19Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""pdf:producer"",""dvipdfmx (20170318)""
""meta:creation-date"",""2019-02-06T05:41:40Z""
""created"",""2019-02-06T05:41:40Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""6""
""Creation-Date"",""2019-02-06T05:41:40Z""
""resourceName"",""IMECS2019_pp94-99.pdf""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""5467"",""5025"",""3609"",""3898"",""3638"",""3069""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""producer"",""dvipdfmx (20170318)""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""dvipdfmx (20170318)""
""pdf:docinfo:created"",""2019-02-06T05:41:40Z""
";https://scholar.google.com/scholar?start=950&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094621-991;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Enhancing IoT security and privacy using distributed ledgers with IOTA and the tangle;B Shabandri, P Maheshwari ; 2019 6th International …, 2019  ieeexplore.ieee.org;;"… In this paper, we lay out an architecture for incorporating a concept similar to Blockchain - the

technology that underpins the cryptocurrency Bitcoin and … IoT. [17] proposes an approach where

SGX extensions are used as an oracle to trustfully feed data into a blockchain …";Cité 17 fois;;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/8700085/8711482/08711591.pdf?casa_token=E1G3HANntC0AAAAA:nc4gGtV4OvyAZFtcvhoF0noAHV2byNg1EYUk6_O9JyAQwFVoOT4jlFfBUUjXx7zLLHItKQbt6SY;"
		Skip to Main Content


		
			
				
				

				

			

		


		
			
				
					
						








	
		
	

	







						

						





























	
	
		
	
	
		
			

		
	

	
	
	



						





	
	
		
			
				IEEE Account

					Change Username/Password
	Update Address


			

			
				Purchase Details

					Payment Options
	Order History
	View Purchased Documents


			

			
				Profile Information

					Communications Preferences
	Profession and Education
	Technical Interests


			

			
				Need Help?

					US & Canada: +1 800 678 4333
	Worldwide:  +1 732 981 0060

					
	Contact & Support


			

		

		
			
				
					
							About IEEE Xplore
	Contact Us
	Help
	Accessibility
	Terms of Use
	Nondiscrimination Policy
	Sitemap
	Privacy & Opting Out of Cookies


						
							A not-for-profit organization, IEEE is the world's largest technical professional organization dedicated to advancing technology for the benefit of humanity.
Š Copyright 2021 IEEE - All rights reserved. Use of this web site signifies your agreement to the terms and conditions.
						

					


					

				

				
			

		

	


	
	


						
						






		
		
		
		
		
		
		
		
		
		
		
		
		
			
				
			
			
			
			
		
		
		
		
		
		

			


			

			
			


		
 		
		
			 

						
						









































	

		
		

		
		
		

		
			
		
		
		

		

		
		


		

		
		
		
		
		
		
		
		
		
		
	
	


















		
		
			
				
					
					
								
					
								
			
				
					
					
								
					
								
			
				
					
						








 



					
					
								
			
				
					
					
								
			
				
					
					
								
					
								
			
				
					
					
								
					
								
			
				
					
					
								
					
								
			
				
					
					
								
					
								
			
				
					
					
								
					
								
			
				
					
					
								
					
								
			
		
	




























		
			
					
			
					
			
					
			
				
					








					
			
					
			
					
			
					
			
					
			
					
			
					
			
		
		
	





	
	
	
	
	
	
	


	
	
	

	

















					

				

			


			
				
			
		

	";"""og:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""twitter:title"",""Enhancing IoT Security and Privacy Using Distributed Ledgers with IOTA and the Tangle""
""twitter:card"",""summary""
""Description"",""The Internet of Things (IoT) devices currently rely on centralized, brokered communication models which call for a number of security flaws and threats. Privacy""
""og:title"",""Enhancing IoT Security and Privacy Using Distributed Ledgers with IOTA and the Tangle""
""resourceName"",""08711591.pdf""
""language"",""en""
""title"",""Enhancing IoT Security and Privacy Using Distributed Ledgers with IOTA and the Tangle | IEEE Conference Publication | IEEE Xplore""
""og:description"",""The Internet of Things (IoT) devices currently rely on centralized, brokered communication models which call for a number of security flaws and threats. Privacy & security remain a challenge owing to the existing systems being centralized - creating a single point of failure. In this paper, we lay out an architecture for incorporating a concept similar to Blockchain - the technology that underpins the cryptocurrency Bitcoin and many other cryptocurrencies to provide decentralized security and privacy for IoT devices. Currently, the issue with most IoT devices is that they lack the processing power, storage and computational overhead to run consensus algorithms to be an active part of the Blockchain network. The current issue with the blockchain on the other hand, is its low scalability and low number of transactions per second. We present an innovative approach using a technology called IOTA. This addresses some of the most important problems with existing blockchain infrastructure such as being able to run on lightweight devices with constrained memory. We eliminate transaction fees and the concept of mining which requires a large amount of processing power to compete with other miners. IOTA's main component is the Tangle, a guided acyclic graph (DAG) for transaction storage. We discuss creation of two IoT applications on the tangle - a smart utility meter system and a smart car transaction system which are connected to internet through Low Power Wide Area IoT networks.""
""twitter:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-UA-Compatible"",""IE=Edge""
""viewport"",""width=device-width, initial-scale=1.0""
""dc:title"",""Enhancing IoT Security and Privacy Using Distributed Ledgers with IOTA and the Tangle | IEEE Conference Publication | IEEE Xplore""
""twitter:description"",""The Internet of Things (IoT) devices currently rely on centralized, brokered communication models which call for a number of security flaws and threats. Privacy & security remain a challenge owing to the existing systems being centralized - creating a single point of failure. In this paper, we lay out an architecture for incorporating a concept similar to Blockchain - the technology that underpins the cryptocurrency Bitcoin and many other cryptocurrencies to provide decentralized security and privacy for IoT devices. Currently, the issue with most IoT devices is that they lack the processing power, storage and computational overhead to run consensus algorithms to be an active part of the Blockchain network. The current issue with the blockchain on the other hand, is its low scalability and low number of transactions per second. We present an innovative approach using a technology called IOTA. This addresses some of the most important problems with existing blockchain infrastructure such as being able to run on lightweight devices with constrained memory. We eliminate transaction fees and the concept of mining which requires a large amount of processing power to compete with other miners. IOTA's main component is the Tangle, a guided acyclic graph (DAG) for transaction storage. We discuss creation of two IoT applications on the tangle - a smart utility meter system and a smart car transaction system which are connected to internet through Low Power Wide Area IoT networks.""
""Content-Encoding"",""UTF-8""
""Content-Type-Hint"",""text/html; charset=utf-8""
""Content-Length"",""42850""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=810&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094644-1099;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[PDF][PDF] Formalization of Security Requirements and Attack Models for Cryptographic Hash Functions in ProVerif;T Yoshimura, K Arai, H Okazaki… ; Proceedings of the …, 2019  csce.ucmss.com;;"… the results be unreliable if the formal definitions of crypto- graphic functionalities are insufficient …

Thus, we can verify that this formalization of the random oracle holds onewayness and collision …

1We can use a private channel to formalize the random oracles for innocent users …";Cité 1 fois;Les 2 versions;[PDF] ucmss.com;https://csce.ucmss.com/cr/books/2019/LFS/CSREA2019/SAM9721.pdf;"
Formalization of Security Requirements and Attack Models for
Cryptographic Hash Functions in ProVerif

Togo Yoshimura1, Kenichi Arai2, Hiroyuki Okazaki1, and Yuichi Futa3
1Graduate School of Science and Technology, Shinshu University, Nagano–city, Nagano, Japan

2Graduate School of Engineering, Nagasaki University, Nagasaki-city, Nagasaki, Japan
3School of Computer Science, Tokyo University of Technology, Hachioji-city, Tokyo, Japan

Abstract— ProVerif and similar verification tools auto-
matically analyze the security of cryptographic protocols.
However, verification results will be incorrect if the formal
definitions of cryptographic functionalities are incomplete.
Unfortunately, to date, there has been no way to confirm
the symbolically analyzed behavior of such functionalities.
Furthermore, we have not been able to describe attacker
models using these tools. In this paper, we propose a
method to define cryptographic functionalities by verifying
their cryptographic requirements using ProVerif. Especially,
we focus on cryptographic hash functions. The proposed
method makes it possible to verify security requirements
other than the properties designated by formalized attacker
models. In addition, using symbolic verifiers, the proposed
method makes it possible to verify security requirements that
are cryptographically meaningful. Therefore, the proposed
method is expected to contribute to formally defining ad-
vanced cryptographic functionalities and accurately verify-
ing the security of cryptographic protocols comprising such
functionalities.

Keywords: Formal Verification, Security Requirements, Crypto-

graphic Hash Function, ProVerif

1. Introduction
Formal verification of cryptographic protocols has been

studied extensively in recent years. ProVerif[1], [2] is one

of the most successful automatic cryptographic protocol

verifiers. ProVerif and similar verification tools (Scyther[3],

AVISPA[4], etc) automatically analyze the security of cryp-

tographic protocols formally described in the Dolev-Yao

model[5]. Such tools consider cryptographic protocols as

interactions among processes that involve cryptographic

functionalities. Generally, we formally define cryptographic

functionalities as abstract functions. In symbolic analysis,

a function is considered a mapping from terms to terms,

and such functions are characterized by rewriting term

rules. Thus, we can describe functions by giving rewriting

rules for terms called reduction or equation. Verification

tools apply symbolic analysis to search the execution path

that breaks the cryptographic protocols. However, several

factors weaken the reliability of verification results, and

the results be unreliable if the formal definitions of crypto-

graphic functionalities are insufficient. For example, formal

definitions do not consider the security requirements of

cryptographic functionalities. In this paper, cryptographic

functionality refers to a function holding certain security

requirements. Here, a function is a relation between its input

and output, and a security requirement defines the properties

the function should hold. Verification tools only allow us

to define a function and check the designated properties.

The verifier repeatedly applies the given rewriting rule for

terms to analyze function behavior. Unfortunately, to date,

there has been no way to confirm the symbolically ana-

lyzed behavior of such functions. Therefore, when verifying

cryptographic protocols, we must assume that the defined

cryptographic functionalities are ideal without any evidence

of security requirements. Consequently, verification results

will be incorrect if the formal definitions of cryptographic

functionalities are incomplete. This is particularly true in a

detailed verification case. Even if we define cryptographic

functionalities or protocols and verify their security using

basic functions using ProVerif, we cannot confirm the cor-

rectness of the verification results without analyzing what the

results mean relative to security. Furthermore, we have not

been able to describe attacker models using these tools. For

example, when formal verifying cryptographic protocols that

use a cryptographic hash function, we use an ideal function

as hash functions. A cryptographic hash function must

hold the security requirements such as collision resistance,

onewayness. Here, ideal function means an arbitrarily chosen

one-to-one function. Therefore, in principle, collisions never

occur with ideal functions and calculating reverse images is

difficult. So, in formal verification, we verify the security

of the cryptographic protocols under the strong assumption

that cryptographic functionalities, such as cryptographic

hash function, are never broken. Similarly, other basic

cryptographic functionalities are formalized to seem having

corresponding security requirements under strong assump-

tions. In theory, it have been confirmed by cryptographers’

discussion that most of basic cryptographic functionalities

are formalized that hold corresponding security requirements

under the strong assumptions. However, no way is given to

confirm the formalized cryptographic functionalities security

requirements. The verification result of target cryptographic

Int'l Conf. Security and Management |  SAM'19  | 23

ISBN: 1-60132-509-6, CSREA Press Š



protocol may be wrong if the tool have some bugs or

tools limitation although the formalization of the protocol

is composed of such ideal cryptographic functionalities in

theory. Thus, we had to verify cryptographic protocols by

believing that the formalized cryptographic functionalities

would hold corresponding security requirements. Thus we

can make the reliability of protocol verification by checking

the security requirements of formalized functionalities with

the same verification tool. In addition, our method helps us to

formally define new cryptographic functionalities that must

hold complex security requirements. Moreover, introducing

the formalization of attacker model into the verification,

we can allow the attackers the advantage to break the

security requirements. In other words, the attack model

can appropriately weaken the above-mentioned too strong

assumptions. Consequently, we can verify the security of

cryptographic protocols under more realistic conditions by

introducing both security requirements and attacker model.

In this paper, we propose a method to define cryptographic

functionalities by verifying their cryptographic requirements

using ProVerif. First, we describe how to formalize security

requirements and attacker models in ProVerif. Specifically,

we consider typical cryptographic functionalities and pro-

pose a method to verify security requirements against active

attacks using ProVerif. Thus, the importance of security ver-

ification against such active attacks is increasing. Therefore,

we propose a method to check security requirements using

designated queries by introducing a process for instructing

detailed the attack goal into the protocol. In addition, we pro-

pose a method to formalize attacker models by introducing

an attack oracle as a process that the attacker is permitted to

access. First, to introduce our basic idea of proposed method,

we demonstrate the verification of the security requirements

of cryptographic hash functions, onewayness and collision-

resistance. Second, we show our formalization of random

oralce, and verify the equivalence between the behaiver of

cryptographic hash function and that of random oralce. In a

similar manner, we have proposed the security requirements

and attack models for public key cryptosystems in ProVerif

[6].

The proposed method makes it possible to verify secu-

rity requirements other than the properties designated by

formalized attacker models. In addition, using symbolic

verifiers, the proposed method makes it possible to verify

security requirements that are cryptographically meaningful.

Therefore, the proposed method is expected to contribute to

formally defining advanced cryptographic functionalities and

accurately verifying the security of cryptographic protocols

comprising such functionalities.

2. ProVerif
ProVerif[1], [2] is an automatic cryptographic protocol

verifier in the formal model (the Dolev–Yao model[5]).

ProVerif assumes that the cryptographic functionalities

are ideal. This is based on an abstract representation

of the protocol by Horn clauses[7] and can verify the

cryptographic properties of secrecy[8], authentication[9],

strong secrecy[10], weak secrecy[11], and observational

equivalence[11]. The ProVerif input file consists of a decla-

ration part and an execution part. In the declaration part, the

terms and components of cryptographic protocols, such as

variables, functions, and channels, are defined. We define

processes, define rewriting rules for terms, and include

queries in the declaration part. Note that adversaries can

use non-private terms in the verification phase, although we

define terms to construct processes. To define the protocol

to verify, we describe how the process is executed in the

execution part.

2.1 Syntax of Process Execution
In this section, we briefly review about the execution part.

We give the execution state of the protocol in the exe-

cution part. We describe the initiator process directly, and

the responder processes defined in the declaration part are

executed in parallel as follows:

Initiator | responder2 | responder1 | ¡ ¡ ¡ .
!P represents the unbounded number of replications of P

executed in parallel as follows:

P | P | P | . . . .

Processes communicate through the public channel. An

attacker can intercept messages through the public channel

and send any message to the channel. Furthermore, we omit

the details of the declaration part for the convenience of the

paper width. Please refer to [2] for details.

2.2 ProVerif Queries
In this section, we briefly review the queries for the

ProVerif verifier.

ProVerif has some queries that are directives to the verifier

for checking whether protocols have the designated security

properties or not. We are able to check basic security

requirements such as secrecy and authentication by using

these designated queries. However, ProVerif’s designated

queries are not sufficient for the security verification of

advanced security requirements. We will propose a method

that enable to check more detailed and advanced security

requirements by combining these queries and the processes

that indicate the attack goal. Here, we show the basic queries

appearing in this paper as follows:

Secrecy: “query attacker(X)”
The verifier checks whether the attacker can know

term X. If “not attacker (X)” is true, term X is kept

secret until the protocol has been terminated.

Correspondence Assertions:

24 Int'l Conf. Security and Management |  SAM'19  |

ISBN: 1-60132-509-6, CSREA Press Š



“query event(X(v)) =⇒ event(Y(v))”
The verifier checks whether event Y(v) is exe-

cuted when event X(v) is executed. If “event(X(v))

=⇒ event(Y(v))” is true, event Y(v) is always

executed when event X(v) is executed. Note that

“event(X(v)) =⇒ event(Y(v))” is true when the

variable v of each event is executed with the

same value. If “event(X(v)) =⇒ event(Y(v))” is

false, event X(v) can be executed without executing

event Y(v). Here, “event(X(v)) =⇒ event(Y(v))” is

false even if the variable v of each event can be

executed with a different value. We can express the

presence or absence of access to an oracle using

this event query. We describe a method to check

several cryptologic properties, such as existential

unforgeability, using this query in Section 3.

Strong Secrecy: “noninterf X”
The verifier checks whether the behavior of the

execution of a process depends on the variable X.

If “noninterf X” is true, the attacker cannot dis-

tinguish any difference in term X. In other words,

strong secrecy is a concept that is approximately

equivalent to semantic secrecy in cryptology.

Observational Equivalence: “choice[A, B]”
We construct the “choice” query in a process. First,

the verifier reconstructs a process that contains the

term “choice[A, B]” as two processes. One process

replaces “choice[A, B]” into A, and the other

replaces “choice[A, B]” as B. Next, the verifier

checks two bisimilar processes. The bisimilar pro-

cesses are observationally equivalent if “choice[A,

B]” is true. In Section 3, we present a method

to check several cryptologic properties, such as

indistinguishability, using the choice query.

3. Formalizing Security Requirements
and Attacker Models in ProVerif

In this section, we propose formalizations of security

requirements and attacker models in ProVerif.

Generally, we have not been able to describe attacker

models using ProVerif. Moreover, ProVerif’s designated

queries were insufficient for security verification of advanced

cryptologic protocols; however, we could check basic secu-

rity requirements, such as secrecy and authentication, using

the designated queries (Figure 1). Therefore, we propose

a method to check security requirements using designated

queries by introducing a process for instructing detailed

the attack goal into the protocol. In addition, we propose

a method to formalize attacker models by introducing an

attack oracle as a process that the attacker is permitted to

access (Figure 2), which makes it possible to verify security

requirements other than the designated properties under the

formalized attacker models.

Process A

ADV

Process B

Basic Security Requirements Only

Fig. 1: Conventional Verification Model in ProVerif.

Process A

ADV

Process B

Process C
(Process for Instructing 
Detailed Attack Goal)Process D

(Attack Oracle)
Attack Success Flag

Event

Permission to Access 
Attack Oracle

Security Requirements
Instruction for Attacker

More Detailed and Advanced Security Requirements 

Fig. 2: Our Method.

First, to introduce our basic idea of proposed method,

we demonstrate the verification of the security requirements

of cryptographic hash functions, onewayness and collision-

resistance. Second, we show our formalization of random

oralce, and verify the equivalence between the behaiver of

cryptographic hash function and that of random oralce.

3.1 Cryptographic Hash Function
In general, a cryptographic hash function holds two cryp-

tographic properties, onewayness and collision-resistance.

3.1.1 Onewayness
In ProVerif, a cryptographic hash function is often defined

as a simple function. We can confirm onewayness by veri-
fying the secrecy[8] of the input data of this function using
ProVerif, through the following protocol.

(* Code.1: Verifying Onewayness *)
free c: channel.
free s:bitstring [private].

Int'l Conf. Security and Management |  SAM'19  | 25

ISBN: 1-60132-509-6, CSREA Press Š



query attacker(s).

fun hash(bitstring): bitstring.

process
out(c, hash(s))

ProVerif judges the secrecy of variable is “true” (secure).

Thus, we verify that this hash function holds onewayness.

3.1.2 Collision-Resistance
Unfortunately, ProVerif does not have queries for ver-

ifying collision-resistance directly. In order to confirm

collision-resistance by ProVerif, we employ the following

process to indicate the goal of verification to ProVerif.

(* Code.2: Indicating-Process *)
(* for Collision-Resistance *)

let processA =
in (c, (ha1:bitstring,ha2:bitstring));
if(ha1 <> ha2 && hash(ha1) = hash(ha2))

then event COL.

In the verification, we execute this additional process in

parallel with main protocol. Although this process has no re-

lationship with the original protocol, it can trick adversaries

and ProVerif. Once a pair of variables that collide in the hash

function is input from the channel, the event COL will be

excuted. Thus, we can define the following protocol to verify

the collision-resistance of the hash function by ProVerif.

(* Code.3: Verifying Collision-Resistance *)
free c: channel.
free s: bitstring [private].

(* Query *)
event COL.
query event(COL).

(* Hash function *)
fun hash(bitstring): bitstring.
(* Indicating-Process *)
(* for Collision-Resistance *)
let processA =

in (c, (ha1:bitstring,ha2:bitstring));
if(ha1 <> ha2 && hash(ha1) = hash(ha2))

then event COL.

process
(!processA) | out(c, hash(s))

We can confirm the collision-resistance by verifying the

execution of event COL. ProVerif judges that the event COL

is not executed. Thus, we verify that this hash function holds

collision-resistance.

In order to confirm the validity of our method, we define

the following function and equation to formalize collision

occurrence:

(* Code.4: Occurring Collision *)
fun co(bitstring, bitstring): bitstring.
equation forall x:bitstring, y:bitstring;

hash(co(x,y)) = hash(co(y,x)).

We can easily occur collision using this definition and

equality. We confirm the collision-resistance by adding this

function and equation to Code.3. ProVerif judges that the

collision-resistance is “false” (not secure). When ProVerif

outputs false, it means that there is an attack that breaks

the collision-resistance. In other words, it means that the

collision-resistance has been broken. Therefore, our verifi-

cation method for cryptographic functionalities works well.

In Section 3.2, we will show our formalization of random

oralce, and verify the equivalence between the behaiver of

cryptographic hash function and that of random oralce.

3.2 Formalizing Cryptographic Functionalities
as Protocols in ProVerif

In Section 3.1, we proposed a method to verify security

requirements that could not be verified by ProVerif directly.

As an example of the proposed method, we verified the

collision-resistance of the hash function formalization using

ProVerif. We confirmed whether a function is defined to

hold the cryptographic requirements of the hash function.

In other words, we verified that the function is defined

as cryptographic functionalities of the cryptographic hash

function. Such functions are defined in too abstract a manner

to describe the cryptographic functionality in detail, because

we are allowed to describe the feature of a function by giving

rewriting rules, relationships between inputs and outputs

of the function. We confirmed that a function satisfies the

requirements of cryptographic hash function: onewayness

and collision-resistance. We have no information about the

function, except that it is an abstract oneway collision-

resistance function. Though collisions may occur in actual

hash functions, we cannot describe such a case in the

conventional method as mentioned above.

Thus, we propose a method to formalize cryptographic

functionalities as processes instead of functions. To intro-

duce our method, we describe how to formalize a random

oracle[12] as a process. In a similar manner, we can also

formalize other cryptographic functionalities.

3.2.1 Random Oracle
We formalize the random oracle process as follows:

(* Code.5: Process of Random Oracle *)
let processRolacle =

in (c, r:bitstring);
new hs: bitstring;
get RO(=r,hs’) in

out(c, (r,hs’))
else insert RO(r,hs);

out(c, (r,hs)).

where RO is a table kept secret from adversaries. Please
refer to [2] for details regarding this table. When a variable
r is input from the channel, the process refers to the RO
table. The processRoracle outputs the digest of r, if r is
already registered; otherwise, it registers a random nonce as
the digest of r and outputs it to the channel. We can define the
following protocol to verify the onewayness and collision-
resistance of the random oracle process using ProVerif
in a similar manner as that for verifying hash functions
mentioned in Section 3.1:

26 Int'l Conf. Security and Management |  SAM'19  |

ISBN: 1-60132-509-6, CSREA Press Š



(* Code.6: Verifying Random Oracle *)
free c: channel.
free s: bitstring [private].
event COL.
table RO(bitstring,bitstring).

query event(COL).
query attacker(s).

let processRolacle =
(* processRolacle is omitted for short *)

out(c, (r,hs)).

let processA =
in (c, (ha1:bitstring,ha2:bitstring));
get RO(=ha1,ha1d) in
get RO(=ha2,ha2d) in
if (ha1 <> ha2 && ha1d = ha2d)

then event COL.

process
(!processA) | (!processRolacle) |
(

(* MAIN PROCESS *)
new hs: bitstring;
insert RO(s,hs);
out(c, hs)

)

where processA is the trick process for the collision-

resistance of the random oracle. The processRoracle allows

adversaries to access it via the public channel. If the main

process refers to the oracle in the same way, communications

will be exposed to adversaries. In order to avoid such cases,

we formalized that the MAIN PROCESS can access the RO

table directly1.

ProVerif judges that the event COL is not executed and

the secrecy of s is true. Thus, we can verify that this

formalization of the random oracle holds onewayness and

collision-resistance.
We define the following processes to formalize collision

occurrence:

(* Code.7: Occurring Collision *)
let processC =

new n1:bitstring;
new n2:bitstring;
new c12:bitstring;
insert RO(n1,c12);
insert RO(n2,c12).

let processC1 =
new n1:bitstring;
new n2:bitstring;
new c12:bitstring;
insert RO(n1,c12);
insert RO(n2,c12);
out(c, n1).

let processC2 =
new n1:bitstring;
new n2:bitstring;
new c12:bitstring;
insert RO(n1,c12);

1We can use a private channel to formalize the random oracles for
innocent users. But we avoid using private channels because many problems
are reported with their use in the current version of ProVerif[2].

insert RO(n2,c12);
out(c, (n1,n2)).

ProcessC registers the same digest for both variables n1

and n2. ProcessC1 registers the same digest and reveals one

of the variables n1. ProcessC2 reveals both variables n1 and

n2. We confirm the collision-resistance by executing each of

these processes. ProVerif judges that the collision-resistance

is true if ProcessC or ProcessC1 is executed. ProVerif judges

that the collision-resistance is “false” (not secure) if Pro-

cessC2 is executed. Consequently, our verification method

for cryptographic functionalities works well.

3.3 Observational Equivalence between Primi-
tives

In Sections 3.1 and 3.2, we proposed two ways that can
verify that cryptographic functionality. Specifically, we gave
the formal definitions of hash functions and random oracles.
ProVerif also includes the query “choice,” which can be
used to check the observational equivalence between two
terms[11]. ProVerif judges whether adversaries can guess
which argument of “choice” is selected by observing the
behavior of the process. We can verify the observational
equivalence between hash functions and random oracles by
the following protocol:

(* Code.8: Checking Observational Equivalence *)
(* declaration part is omitted for short *)

process
(!processRolacle) |
(

(* MAIN PROCESS *)
new s: bitstring;
new hs: bitstring;
insert RO(s,hs);
out(c, choice[hs,hash(s)])

)

ProVerif judges that the observational equivalence be-

tween hash functions and random oracles is true.

Simple formalization, as mentioned in Section 3.1, is

better than the process described in Section 3.2, in terms

of verification accuracy. This is because checking ProVerif

queries is both costly and exhaustive. However, the latter

approach allows us to formalize a more detailed description.

We can expect that replacing formalization of cryptographic

primitives doesn’t cause serious trouble on the verification

result, if these primitives are observational equivalent. We

can conclude that the two proposed approaches should be

used selectively.

4. Conclusion
In this paper, we proposed a method to define cryp-

tographic functionalities by verifying their cryptographic

requirements using ProVerif. Specifically, we proposed a

method to check security requirements using designated

queries by introducing a process for instructing detailed

the attack goal into the protocol. In addition, we proposed

a method to formalize attacker models by introducing an

attack oracle as a process that the attacker is permitted

to access. First, to introduce our basic idea of proposed

Int'l Conf. Security and Management |  SAM'19  | 27

ISBN: 1-60132-509-6, CSREA Press Š



method, we demonstrate the verification of the security

requirements of cryptographic hash functions, onewayness

and collision-resistance. Second, we show our formalization

of random oralce, and verify the equivalence between the

behaiver of cryptographic hash function and that of random

oralce. The proposed method made it possible to verify

security requirements other than the designated properties

under formalized attacker models. The proposed method also

made it possible to verify security requirements meaningful

cryptographically using symbolic verifiers. Therefore, the

proposed method is expected to contribute to formally defin-

ing advanced cryptographic functionalities and accurately

verifying the security of cryptographic protocols comprising

such functionalities.

Acknowledgment
This study is partly supported by the JSPS KAKENHI

17K00182 and 18K02917. This work is based on the re-

search activity of CELLOS (Cryptographic protocol Evalua-

tion toward Long-Lived Outstanding Security). The authors

thank all colleagues from CELLOS who provided expertise

that greatly assisted the research.

References
[1] B.Blanchet(Project leader), “ProVerif: Cryptographic

protocol verifier in the formal model.” Available at
http://prosecco.gforge.inria.fr/personal/bblanche/proverif/.

[2] B.Blanchet, B.Smyth, and V.Cheval, “ProVerif 1.96: Automatic Cryp-
tographic Protocol Verifier, User Manual and Tutorial.” Available at
http://prosecco.gforge.inria.fr/personal/bblanche/proverif/manual.pdf.

[3] Cas J.F. Cremers, “The scyther tool: Verification, falsification, and
analysis of security protocols,” Proc. of 20th International Conference
on Computer Aided Verification (CAV’08), LNCS 5123, pp.414–418,
Springer-Verlag, 2008.

[4] A.Armando, D.Basin, Y.Boichut, Y.Chevalier, L.Compagna, J.Cuellar,
P.Hankes Drielsma, P.C.HeĂĄm, O.Kouchnarenko, J.Mantovani,
S.MĂśdersheim, D.von Oheimb, M.Rusinowitch, J.Santiago, M.Turuani,
L.Viganò, L.Vigneron, “The AVISPA Tool for the Automated
Validation of Internet Security Protocols and Applications,” Proc.
of 17th International Conference on Computer Aided Verification
(CAV’05), LNCS 3576, pp.281–285, Springer-Verlag, 2005.

[5] D.Dolev and A.Yao, “On the Security of Public Key Protocols,” IEEE
Transactions on Information Theory, Vol.29(2), pages 198–208, 1983.

[6] Hiroyuki Okazaki, Yuichi Futa, Kenichi Arai, “Suitable Symbolic
Models for Cryptographic Verification of Secure Protocols in ProVerif,”
The International Symposium on Information Theory and Its Applica-
tions(ISITA2018), pages 326–330, 2018.

[7] B.Blanchet, “Using Horn Clauses for Analyzing Security Protocols,”
Formal Models and Techniques for Analyzing Security Protocols,
volume 5 of Cryptology and Information Security Series, pages 86–
111, 2011.

[8] B.Blanchet, “An Efficient Cryptographic Protocol Verifer Based on Pro-
log Rules,” In 14th IEEE Computer Security Foundations Workshop,
pages 82–96, 2001.

[9] B.Blanchet, “From Secrecy to Authenticity in Security Protocols,” 9th
International Static Analysis Symposium (SAS’02), volume 2477 of
Lecture Notes in Computer Science, pages 342–359, 2002.

[10] B.Blanchet, “Automatic Proof of Strong Secrecy for Security Proto-
cols,” In IEEE Symposium on Security and Privacy, pages 86–100,
2004.

[11] B.Blanchet, M.Abadi, and C.Fournet, “Automated Verification of Se-
lected Equivalences for Security Protocols,” In 20th IEEE Symposium
on Logic in Computer Science (LICS 2005), pages 331–340, 2005.

[12] M.Bellare and P.Rogaway, “Random Oracles are Practical: A
Paradigm for Designing Efficient Protocols,” ACM Conference on
Computer and Communications Security, pages 62–73, 1993.

Appendix
This paper propose a method to define cryptographic

functionalities by verifying their cryptographic requirements

using ProVerif and a method to formalize security require-

ments and attacker models. In particular, we demonstrate

how to verify the security requirements of cryptographic

hash functions, onewayness, and collision-resistance. This

method is expected to formally define advanced crypto-

graphic functionalities and accurately verify the security of

the cryptographic protocols that include such functionalities.

Generally, ProVerif verifies the security of protocols con-

structed with ideal cryptographic functionalities; however,

such ideal functions are practically difficult to achieve.

Thus, we replace these ideal functionalities in such protocols

with feasible algorithms to develop real-world cryptographic

protocols.

We believe that these algorithms can also be verified using

ProVerif. In particular, simple cryptographic algorithms were

easy to verify. However, several cryptographic algorithms in-

cluding iteration and recursion are not supported by ProVerif.
In fact, most classical cryptographic hash functions, in-

cluding MD5 and SHA–1, are designed as the iteration of a
compression function called the Merkle–Damgård construc-
tion. Consequently, we are attempting to formalize iteration
in ProVerif, by regarding it as internal inter-process com-
munication using a private channel and tables. In ProVerif,
attackers cannot access tables or channels declared as being
private. Herein, we present a formalization of the Merkle–
DamgĂĽrd construction, although it does not capture the
following concrete configuration.

(* Code.9: MD-construction *)
free c:channel.
free t:channel[private].
free s:channel[private].
const zerotuple:bitstring.
fun block(bitstring):bitstring.
fun tail(bitstring):bitstring.
fun comp(bitstring,bitstring):bitstring.
fun len(bitstring):bitstring.
table nexttuple(bitstring,bitstring).
table MD(bitstring,bitstring).

event COL.
query event(COL).

let makeMD(mmm:bitstring,
mtail:bitstring,length:bitstring) =

in(s,(rm:bitstring,ha:bitstring));
get nexttuple(=rm,nextb) in
if(nextb <> mtail) then
(
let newha = comp(ha,nextb) in
out(s,(nextb,newha))

) else (
let MDh = comp(comp(ha,nextb),length) in
insert MD(mmm,MDh);
out(c,MDh)

).

28 Int'l Conf. Security and Management |  SAM'19  |

ISBN: 1-60132-509-6, CSREA Press Š



let Collison =
in(c, (a1:bitstring, a2:bitstring));
get MD(=a1,MDa1) in
get MD(=a2,MDa2) in
if(a1 <> a2 && MDa1 = MDa2)
then event COL.

process
!(

new mm:bitstring;
out(c,mm);

let b1 = block(mm) in
let b2 = block(b1) in
insert nexttuple(mm,b1);
insert nexttuple(b1,b2);
insert nexttuple(b2,tail(mm));

out(s,(mm,zerotuple));
!makeMD(mm,tail(mm),len(mm))

)
|!Collison

Int'l Conf. Security and Management |  SAM'19  | 29

ISBN: 1-60132-509-6, CSREA Press Š


";"""date"",""2019-07-08T03:35:54Z""
""pdf:PDFVersion"",""1.6""
""xmp:CreatorTool"",""pdftk 1.44 - www.pdftk.com""
""pdf:docinfo:title"",""Proceedings of SAM'19""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""language"",""en""
""dc:format"",""application/pdf; version=1.6""
""pdf:docinfo:creator_tool"",""pdftk 1.44 - www.pdftk.com""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""Proceedings of SAM'19""
""xmp:CreateDate"",""2019-07-07T20:35:51Z""
""modified"",""2019-07-08T03:35:54Z""
""pdf:hasMarkedContent"",""false""
""xmp:ModifyDate"",""2019-07-07T20:35:54Z""
""pdf:docinfo:creator"",""UCMSS""
""meta:author"",""UCMSS""
""meta:creation-date"",""2019-07-08T03:35:51Z""
""created"",""2019-07-08T03:35:51Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-07-08T03:35:51Z""
""resourceName"",""SAM9721.pdf""
""Author"",""UCMSS""
""producer"",""Acrobat Distiller 11.0 (Windows)""
""pdf:docinfo:producer"",""Acrobat Distiller 11.0 (Windows)""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""access_permission:modify_annotations"",""true""
""dc:creator"",""UCMSS""
""dcterms:created"",""2019-07-08T03:35:51Z""
""Last-Modified"",""2019-07-08T03:35:54Z""
""dcterms:modified"",""2019-07-08T03:35:54Z""
""title"",""Proceedings of SAM'19""
""xmpMM:DocumentID"",""uuid:78e464e7-3a38-47b0-979e-896011c3b2c8""
""Last-Save-Date"",""2019-07-08T03:35:54Z""
""pdf:docinfo:modified"",""2019-07-08T03:35:54Z""
""meta:save-date"",""2019-07-08T03:35:54Z""
""Content-Length"",""166838""
""Content-Type"",""application/pdf""
""xmp:MetadataDate"",""2019-07-07T20:35:54Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""UCMSS""
""pdf:producer"",""Acrobat Distiller 11.0 (Windows)""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""7""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""4611"",""4705"",""3335"",""4161"",""3698"",""5277"",""403""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-07-08T03:35:51Z""
";https://scholar.google.com/scholar?start=910&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094544-669;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[PDF][PDF] Decentralized Certificate Authority as a blockchain application;MR Mortensen, M Thomsen ;2019 blog.rostgaard.it;;"… Ether Native crypto currency of the Ethereum blockchain … 2.2.2 Blockchain The Ethereum

blockchain, which launched in 2015, is a generalized, trusted computing platform, which

allows anyone, who holds the native cryptocurrency 13 Page 14 …";;;[PDF] rostgaard.it;https://blog.rostgaard.it/files/Thesis.pdf;"
Decentralized Certificate Authority as a

blockchain application
Course code: KISPECI1SE

Mark Rostgaard Mortensen (mrom@itu.dk)
Markus Thomsen (matho@itu.dk)

June 3rd 2019

Abstract

Certificate Authorities have centralized power of the issuance of TSL
certificates. This makes them single points of failure, when it comes to
communicating over the HTTPS protocol.
This paper explores how it may be possible to decentralize the power
of Certificate Authorities using decentralized applications running on the
Ethereum blockchain. We developed two approaches:

The first approach use a Decentralized Autonomous Organization, that
will act as Certificate Authority enforcing multiple signatures of a re-
quested certificate.

The second approach, named Dapp-CA, replace the membership as-
pect with economical incentives, to incentivize honest, open participation.
Participants in the Dapp-CA stake valuable tokens on the validity of a cer-
tificates, with the risk of losing them if breaking the rules.

We conclude that it is possible to use blockchain to enforce decentral-
ization when approving certificates. However, changes are necessary to the
DNS record, for the Dapp-CA not to be vulnerable to attack. Scalability
remains an issue, making real-world usage impractical, without further
research.

1



Contents

1 Introduction 5
1.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.1.1 Transport Layer Security . . . . . . . . . . . . . . . . . . 5
1.1.2 Certificate Authorities . . . . . . . . . . . . . . . . . . . . 6

1.2 Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3 Related work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

1.3.1 Multi-signatures Certificate Authorities . . . . . . . . . . 7
1.3.2 HTTP Public Key Pinning . . . . . . . . . . . . . . . . . 8
1.3.3 Certificate Transparency . . . . . . . . . . . . . . . . . . . 8
1.3.4 Blockchain based proposals . . . . . . . . . . . . . . . . . 8

1.4 Hypothesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.4.1 Research question . . . . . . . . . . . . . . . . . . . . . . 10

2 Problem Analysis 11
2.1 Certificate Authorities . . . . . . . . . . . . . . . . . . . . . . . . 11

2.1.1 Certificate Issuance Process . . . . . . . . . . . . . . . . . 12
2.2 Decentralization as a solution . . . . . . . . . . . . . . . . . . . . 13

2.2.1 Decentralized Certificate Authorities . . . . . . . . . . . . 13
2.2.2 Blockchain . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.2.3 Certificate Transparency . . . . . . . . . . . . . . . . . . . 15
2.2.4 Economical incentives . . . . . . . . . . . . . . . . . . . . 16

3 User Guide and Requirements 17
3.1 Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.2 Smart contracts . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.2.1 Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.2.2 Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.2.3 DAO-CA . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.2.4 Dapp-CA . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.3 Firefox extension . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.3.1 Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.3.2 Extension building . . . . . . . . . . . . . . . . . . . . . . 22

4 Method 24
4.1 Certificate Transparency Log . . . . . . . . . . . . . . . . . . . . 24
4.2 DNS challenge . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.3 DAO-CA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

4.3.1 Smart contract . . . . . . . . . . . . . . . . . . . . . . . . 29
4.4 Dapp-CA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

4.4.1 Smart contracts . . . . . . . . . . . . . . . . . . . . . . . . 31
4.4.2 Certificate attestation . . . . . . . . . . . . . . . . . . . . 33
4.4.3 Governance Token . . . . . . . . . . . . . . . . . . . . . . 34
4.4.4 Forking . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

4.5 Frontend (Firefox implementationen) . . . . . . . . . . . . . . . . 37

2



5 Results 38
5.1 DAO-CA Cost . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
5.2 Dapp-CA Cost . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

6 Discussion 43
6.1 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

6.1.1 Blockchain censorship attack vectors . . . . . . . . . . . . 44
6.1.2 Certificate Transparency Attack Vectors . . . . . . . . . . 47
6.1.3 DAO Attack vectors . . . . . . . . . . . . . . . . . . . . . 47
6.1.4 Dapp-CA attack vectors . . . . . . . . . . . . . . . . . . . 49
6.1.5 Social layer . . . . . . . . . . . . . . . . . . . . . . . . . . 51

6.2 Economical Incentives . . . . . . . . . . . . . . . . . . . . . . . . 52
6.3 Scaling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

6.3.1 Plasma, Sidechains and off-chain scaling . . . . . . . . . . 53
6.4 Comparison of the established solution, DAO-CA and Dapp-CA 54

6.4.1 Established solution . . . . . . . . . . . . . . . . . . . . . 54
6.4.2 Proposed Solutions . . . . . . . . . . . . . . . . . . . . . . 55

6.5 What could have been done better . . . . . . . . . . . . . . . . . 57
6.5.1 Dapp-CA reliability on DNS text . . . . . . . . . . . . . . 57
6.5.2 Gas-usage optimization . . . . . . . . . . . . . . . . . . . 58

6.6 Future work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
6.6.1 Mechanism design improvements . . . . . . . . . . . . . . 58
6.6.2 Security Audit and formalization . . . . . . . . . . . . . . 59

6.7 Usability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
6.7.1 UI, UX, Firefox . . . . . . . . . . . . . . . . . . . . . . . . 60

7 Conclusion 61

A Smart Contract Code 65
A.1 CertificateTransparency.sol . . . . . . . . . . . . . . . . . . . . . 65
A.2 MinDAO.sol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
A.3 Controller.sol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
A.4 Tokens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

A.4.1 ERC20Basic.sol . . . . . . . . . . . . . . . . . . . . . . . . 75
A.4.2 BasicToken.sol . . . . . . . . . . . . . . . . . . . . . . . . 75
A.4.3 BurnableToken.sol . . . . . . . . . . . . . . . . . . . . . . 76
A.4.4 StakeableToken.sol . . . . . . . . . . . . . . . . . . . . . . 76
A.4.5 MigrateableToken.sol . . . . . . . . . . . . . . . . . . . . . 77
A.4.6 SafeMath.sol . . . . . . . . . . . . . . . . . . . . . . . . . 78

3



Glossary

Attestor A participant in the Dapp-CA or DAO-CA that is responsible for
accepting or rejecting certificates..

Crypto currency Native payment token of a public blockchain.

Ether Native crypto currency of the Ethereum blockchain.

Ethereum A public blockchain known for it’s ability to run smart contracts.

GOV The ERC-20 token created for the Dapp-CA.

Smart contract Smart contracts are the colloquial term used to describe pro-
grammable scripts deployed on blockchains.

Solidity The most used programming language for programming smart con-
tracts on Ethereum.

Acronyms

CA Certificate Authority.

CT Certificate Transparency.

DAO Decentralized Anonymous.

dApp Decentralized Application, typically one implemented with smart con-
tracts.

DNS Domain Name Server.

DPKI Decentralized Public-Key Infrastructure.

HPKP HTTP Public Key Pinning.

HTTPS Hypertext Transfer Protocol Secure.

IETF Internet Engineering Task Force.

PKI Public-Key Infrastructure.

RFC Request For Comments.

TLS Transport Layer Security.

4



1 Introduction

The World Wide Web have always been an excersize in decentralization. It
is possible to connect to many different terminals and servers, and exchange
messages between machines, without anyone’s approval. The internet funda-
mentally relies on routing messages through many different machines, and this
makes it harder to know, if you’re actually communication with who you think
you are. Securing and verifying the authenticity of the communication is there-
fore an important task that have been worked on for more than 26 years, when
the certificate standard X.509 was first defined in rfc1422[33].

With this standard came the concepts of trusted third-parties known as Cer-
tificate Authorities.[35] CAs are centralized entities, responsible for certifying
the identity of domain owners. The CAs doesn’t come without problems. They
present a single point of failure, and their power can be abused to impersonate
websites at will. This have presented problems for example hackings of CAs
compromising 300.000 users emails. These problems will be discussed in section
1.2.

Companies, academia and independent researcher are working on solving
the problems with centralized CAs. Some of these solutions are documented in
section 1.3.

In this paper we present research done, as a part of a research project, in
the spring of 2019 at the IT-University in Copenhagen. The project revolves
around TSL certificates and it’s signing using trusted third parties known as
’Certificate Authorities’.

1.1 Background

1.1.1 Transport Layer Security

The TLS protocol exist to provide security of communication over a network.
The fundamental architecture of the internet results in messages being routed
through many different machines, before arriving at their end destination. A
malicious actor controlling any of these machines, can change and read the
message as they see fit. To avoid this, protocols can be used, one of them is the
TLS protocol.
The TLS protocol aims to ensure, amongst other, the following properties:

• Privacy: The TLS protocol use asymmetric encryption to create a shared
secret, that is the base of the symmetric encryption which is used to
exchange information securely.

• Authentication: The identities of participants can be authenticated.

• Integrity: The protocol uses message authentication codes, which ensures
that messages can’t be tampered with or altered.

While all of these properties are important, this papers primary focus will be
on the property of authentication.

5



Authentication of participants in TLS is carried out with public-key cryptog-
raphy, and uses certificates, to attest to the identity of the party that is being
communicated with. TLS uses the X.509 certificate format, which includes in-
formation about the issuer of the certificate, the subject, information about the
signature, cryptographic algorithms used, and more.
A secure session starts when a browser sends a request to a server, the server
will respond with its certificate which contains a public key. The public key is
used to encrypt a session key, this session key is sent back to the server where
the server will decrypt the session key using the servers private key. When the
session key is decrypted on the server the communication between the clients
browser and the webserver can now all be encrypted symmetrically.

1.1.2 Certificate Authorities

When visiting a website that are using HTTPS, the issuer of the certificate will
in almost all cases be a Certificate Authority. CAs are third parties, which
both participants in the TLS protocol, should trust. Their purpose is to issue
certificates to website owners, and other untrusted parties, which can then use
said certificate to prove the authenticity of the communication. It’s important
to note, that certificates do not protect against any malicious behaviour by the
issuer, nor by the authenticated website, but merely ensures that the connection
can be trusted to actually be with who the other party says they are, I.E. the
domain you are visiting are owned by the certificate owner.
The certificates issued by a CA, only guarantees authenticity of communication,
as long as the CA can be trusted. Nothing in the protocol itself incentivize or
stops CAs from issuing misleading certificates to malicious third parties. The
threat of legal issues and financial ruin, coupled with reputation, is used to keep
CAs in-check.
Since certificates are issued by a single CA, and have no other parties which
attest to their veracity, a single compromised CA will compromise the security
of every certificate issued by that CA. Furthermore compromised CAs will be
able to issue valid certificates until it is publicly known that they have been
compromised. In other words, CAs are a single-point of failure in the current
implementation of TLS. This security hole has been misused by both hackers
and national intelligence agencies[11].

1.2 Problem

CAs can sign certificates for any ’Common Name’, also known as domains. For
a user to trust a certificate created by a domain owner, it first needs to be signed
by a CA.
Browsers and operating systems comes pre-installed with lists of trusted CAs
so the user knows which CAs the software trusts.

6



The process to become as trusted CA is difficult and often expensive. Mi-
crosoft have a process for becoming a trusted CA for their platforms. It is a long
and strenuous process[16]. Mozilla have a similarly difficult CA program[17] to
be included into the Mozilla software suite, the premiere product of which being
the Firefox browser.

It is necessary that the process to become a trusted CA is difficult. Because
one of SSL certificates main purposes is to establish authenticity of commu-
nication, this gives the CAs the power to impersonate any website. With a
critical single points of failure such as this, it becomes paramount, that no
entity can compromise it, however no such thing can be guaranteed. Human
failure, exploitation of software security holes and malicious insiders can all lead
to compromise of the CA system.
One of the more noteworthy cases has been the hack on DigiNotar in 2011.[11]

DigiNotar was compromised and more than 500 certificates were issued and
signed by DigiNotar, and considered to be valid by the browsers. The certificates
were used to read the emails of more than 300,000 Iranians. It took more than
a month after the breach was discovered, before DigiNotar went public with the
information.

Another story was that in 2015 Symantec’s subsidiary Thawte generated
SSL certificates, that weren’t requested by the owner of the domains, for testing
purposes.[5]

CAs can also be compelled into issuing false certificates by governments.
Attacks like these can be especially difficult to discover, as the certificate may
only be used to target very specific users.

These examples show that without trustworthy TSL certificates, HTTPS
traffic received over the Internet cannot be trusted.

1.3 Related work

There already exists research and proposed solutions to the problems described
in section 1.2. These range from already tried and failed solution such as HTTP
Public Key Pining, to currently implemented Certificate Transparency. Some
of the more recent research includes blockchains, and these mostly describe
how to decentralize the Public Key Infrastructure, used on the Internet today,
completely.

1.3.1 Multi-signatures Certificate Authorities

One proposal to decentralize certificate issuance, and thereby avoiding the single
point of failure, is to have multiple CAs sign every certificate. This is most effec-
tively accomplished by using threshold encryption schemes[26]. The drawbacks
to this approach, is that the certificate signing process would still be controlled
by CAs, many of which may be within the same jurisdiction. To avoid compro-
mise of certificates by nation states, it would be necessary to have certificate
issuers located in multiple jurisdictions, and preferably have the governments

7



of these jurisdictions be non-cooperative, or even adversarial. A benefit to this
approach, is that it could rather easily be extended from the current infrastruc-
ture. A drawback is that it can be hard to have transparency in who the signers
are, unless made an explicit part of the certificate information.

1.3.2 HTTP Public Key Pinning

HTTP Public Key Pinning is a protocol to pin a public key to a users browser[25].
The first time a user visits a website that have HPKP implemented, the server
sends one or more public keys with the HTTP header in the field named ’Public-
Key-Pins’. This field contains information as to how long the keys are expected
to be valid. After this initial pinning, the browser saves the information. The
browser will then only accept requests with certificates that are signed with the
pinned public key.

HPKP has been implemented in modern browser since 2015, but in 2018
Google discontinued HPKP in their Chrome browser, due to lack of use and
for security measures[37]. Pinning turned out to be too much responsibility in
the hands of inexperienced users. If a hacker or social engineer convince them
to use his public key, and therefore correctly pin a false certificate, it becomes
possible for him to make an attack, negating the upsides of pinning.

Google and other researchers has since moved to ensure that the certificates
presented are also correctly signed by a CA. This effort is called Certificate
Transparency and is moving towards completely replacing HPKP.

1.3.3 Certificate Transparency

Certificate Transperancy[22] is a protocol designed to enable anyone to monitor
the activity of CAs. It’s already implemented in most modern browsers and
working. This paper describes CT in greater detail in section 2.2.3.

1.3.4 Blockchain based proposals

Decentralization of the entire PKI structure using blockchains have been pro-
posed. One approach is Decentralized Public Key Infrastructure written by
Butterin et al.[30] and suggest using blockchains to register identities, such as
domains.

SCPKI: A Smart Contract-based PKI and Identity System written by Mustafa
Al-Bassam[21] is another one and this propose to use a reimplementation of the
web of trust model using Ethereum smart contracts to handle the signing and
revocation of trust.

Decentralized Public Key Infrastructure

DPKI propose to decentralize the entirety of public key infrastructure. This
would be a major departure from the current system, requiring every principal,
the owner of an identity such as a domain name, to never lose their signing keys,

8



or risk losing the ability to control their identity. The paper describes rules that
would need to be implemented to make it a decentralized, transparent and open
system:

• ”Each principal must be in complete control of their current identifier/public-
key binding.” [p. 6]

• ”Either every principal must witness every other principal’s updates to
their identifier/public-key binding or else no one may observe any up-
dates.” [p. 6]

• ”Permissionless Writes: Any principal can broadcast a message pro-
vided that it is well-formed. Other peers in the system do not require
admission control. This implies a decentralized consensus mechanism.”
[p. 7]

• ”Fork Choice Rule: Given two histories of updates, any principal can
determine which one is the ’most secure’ through inspection.” [p. 7]

• ”Private keys must be generated in a decentralized manner that ensures
they remain under the principal’s control.” [p. 7]

• ”Software must ensure that principals are always in control of their iden-
tifiers and the corresponding keys.” [p. 7]

• ”Software must ensure, to greatest degree possible, that no mechanism ex-
ists that would allow a single entity to deprive a principal of their identifier
without their consent.” [p. 8]

A principal, who is the domain owner, would have direct control and ownership
of a domain name by registering it in a blockchain. For this reason, the system
insist that each principal must be in complete control of their own key and not
allow web hosting or CAs to once again centralize control, by being key holders.
This way a malicious entity would need to compromise every principal they
want to attack, and not just a single CA.

The paper describes how principals can manage their public-key bindings.
It is crucial that the principals private keys are not lost. This would result in an
irretrievable loss of access to the principals identity. It’s proposed to shard the
master key. This would allow multiple identities to own a piece of the master
key, and when joined together, will create the master key. The sharding can use
threshold cryptography, so as to only need N out of M, where M >= N , pieces
of the shards are required to construct the master key.

A second proposal is to use smart contracts to create a multi-signature script
that needs N out of M signatures to execute and recover the key.

SCPKI: A Smart Contract-based PKI and Identity System

9



This paper is written by Mustafa Al-Bassam[21] and is a research project ex-
ploring how to use Ethereums smart contracts to systemize web of trust as
described by PGP 2.0.

The system is designed to let an entity create a new attribute for themselves,
such as a college degree, and then another entity, like the university, will be able
to sign that degree, or revoke it if the university no longer trust the validity of
the degree.

The system is based on trusting participants. For example if you trust a
university and they signed a degree for another entity, then you should trust
the validity of that degree. Where it differ from the current CA solution, is that
every participant would have to decide which organizations they trust.

Both SCPKI and DPKI proposes radical and ambitious ways to change the
current PKI system. SCPKI proposes a concrete solution while DPKI is mostly
a paper describing the rules of a decentralized PKI, rather than a concrete
implementation.

1.4 Hypothesis

We believe voting and economic mechanisms, can be used to design a decen-
tralized protocol, which allows participants to issue and verify TLS-certificates
in a decentralized manner, using the blockchain and smart contracts.

1.4.1 Research question

Is it possible to issue TLS-certificates in a decentralized manner, while keeping
the ability to resist loss of private keys, and revoking invalid certificates, using
the Ethereum blockchain?

10



2 Problem Analysis

2.1 Certificate Authorities

When a user visits a website, they will normally type in the domain name such
as ’www.facebook.com’, instead of the direct IP address. The browser will make
a DNS lookup and find the corresponding IP address of Facebooks server, and
establish a connection with that server.

If a malicious party has placed themselves between the user and Facebook,
the malicious party can impersonate Facebook. This allows them to collect
the data that Facebook and the user communicate between each other. This
is known as a man-in-the-middle attack. To alleviate this issue, a website can
provide the user a certificate to prove its identify and use the corresponding
private key to encrypt it’s messages, ensuring safe communication between the
user and the website.

Everyone can create and sign their own certificate, for this reason, a cer-
tificate alone is not enough information for the user to know, if it’s actually
Facebook or a malicious party they’re communicating with.

This is the reason that Certificate Authorities (CA) exist today. A CA is a
company, or another trusted third party, which exist to validate the ownership
of domains and sign requested certificates, if the ownership can be proven. This
way the user know to trust the certificate received by the website if the websites
certificate have been signed by a trusted CA.
It’s not in the scope of this paper to explain how you become a trusted CA. The
important aspect is that everyone can potentially be it and it is, in the end, up
to the software the user is using to decide whether a CA is trusted or not. In
other words, which CAs are trusted are defined on a software by software basis.
In some cases, users may have control over which certificates they trust, and
can add a CAs root certificate, thereby trusting any certificate signed by that
CA. The root certificate is the certificate the CA use to sign other certificates
to their system.

The duties of the CA is to receive certificate signing request, where a claimed
owner of a domain will ask the CA to sign their certificate so that they are able
to use it to prove their identity to the users of their website. The CA can do
this in different ways. One way, that the CA Let’s Encrypt uses, are the ACME
protocol’s DNS challenge[29]. Once a request have been deemed valid, the CA
will then sign the certificate, and the certificate is now ready to be used by the
domain owner. The CA is also responsible for revoking certificates, though CAs
at the current state have trouble enforcing this[38].

Having most of the Internets communication rely on these companies and
institutions, give them a lot of power. Once they are trusted by a users system
they can sign, certificate for every website. The power of a trusted CA can allow
a malicious party to assume the identity of any domain, and thereby break the
PKI system and the trust that follows, at least until the breach is discovered

11



and disclosed.

2.1.1 Certificate Issuance Process

Figure 1: Diagram of the certificate issuance process[31]

Figure 1 shows the process of certificate issuance. The protocol works as
follows:

A requester, Mario Rossi, needs a certificate to match his public key, so he
can provide it to visitors of his website. He sends information about the certifi-
cate he wish to create, to a CA he trusts. What information is required by the
CA to sign the certificate is up to the specific CA, and dependent on which ver-
ification protocol they use. Using Let’s Encrypt requires at least providing[12]:

• Common Name

• Subject Alternative Names

• Subject Public Key Info

Where common name is the name of Mario’s domain. Subject alternative
names is a list of all the domains associated with the certificate, for example
Facebook uses the same certificate for facebook.com and messenger.com. Lastly
the Subject Public Key Info is the corresponding public key to Mario’s private
key.

12



This information is used to create a Certificate Signing Request (CSR), and
Mario can then ask Let’s Encrypt to sign the CSR, which will create the signed
certificate.
Before Let’s Encrypt is willing to sign the CSR, Mario needs to prove that
he owns the domain. This can be done using Let’s Encrypts DNS challenge
as explained on their website[13] and or in the ACME protocol[29]. Once the
domain validation have passed, and Mario is considered the owner of the domain,
he will receive a certificate that he can use to prove his domains authenticity.

2.2 Decentralization as a solution

This paper proposes to decentralize the power of the CA by decentralizing parts
of the certificate signing process. The paper suggests two solutions.

The first is a Decentralized Autonomous Organization that acts as CA, the
description of this can be found in section 4.3.

The second proposed solution is a decentralized application that act as CA.
Anyone can participate in the decentralized application, provided the have the
capital necessary. This is described in detail in section 4.4.

Decentralization is not without it’s obstacles. Coordination between multiple
participants, is always difficult, especially when they have to arrive at consensus.
This is made more difficult by the existence of potential malicious participants.

2.2.1 Decentralized Certificate Authorities

To alleviate the problems with centralization as mentioned in section 1.2 it
seems that decentralization through blockchains, as described in section 2.2.2
might offer possible solutions.

We seek to accomplish two goals with our decentralized CAs
First, it should be an atomic action to accept a certificate, and have it directly
included in a decentralized Certificate Transparency log as described in section
2.2.3. There should be no middlemen between the decentralized application
and the CT log. This will ensure that newly issued certificates are broadcast
immediately to anyone watching the CT log.

Secondly; Every certificate request should require more than one approval
to be accepted by the decentralized application. Multiple participants in the
decentralized application, would need to accept the certificate before it is con-
sidered valid. This will fix the problems of CAs being single points of failure,
with more honest participants requiring more failures on part of the participants
as a whole.

Smart contract based decentralized applications, running on the Ethereum
blockchain, will be used in an attempt to reach this goal.

2.2.2 Blockchain

The Ethereum blockchain, which launched in 2015, is a generalized, trusted
computing platform, which allows anyone, who holds the native cryptocurrency

13



Ether, to publish and run programs on the platform. These programs are col-
loquially known as smart contracts. A smart contract is a set of instruction to
be executed when a trigger happens. A contract on the Ethereum protocol is
in of itself a fully-fledged Ethereum account. This means that the contract can
send and receive assets and maintain a permanent storage. The programmable
nature of the platform allows building a certificate transparency protocol on
top of the blockchain, which is already inherently decentralized and hard to
reorder[24].

Not only do the Ethereum blockchain allow for distributed, trusted comput-
ing, but it also allows us to program economic incentives. The introduction of
programmable economical incentives, which are censorship resistant, provides a
whole new toolbox for protocol and application design, as the transfer of value
is now as reliable as the underlying platform, as opposed to the vulnerable and
non-atomic transfers between financial institutions. This means that centuries
of economic game theory, can now be incorporated into protocol design, allow-
ing for novel approaches to old problems.

Blockchains come with some challenges as well, chief of them being the scal-
ability issue. Every transaction on a public blockchain will create data, that will
have to be duplicated on every node running in the system. As such, storing
data on public blockchains is an expensive operation. Because of this, we will
limit the scope of certificates in this project, to what we consider a minimal
viable certificate. These certificates will only contain a public key of the re-
quester, a common name for the URL, and an expiry time.

Ethereum have been chosen as the blockchain this project will build its
solutions on.
Smart Contracts
Smart contracts are code that executes on the Ethereum VM when blocks are
mined. Smart contracts are assigned their own public keys on the network upon
deployment, this is what makes it possible to identify them. Transactions can
then activate public methods in the smart contract. The code can be arbi-
trary because the programming language is Turing complete. This open up the
possibility to write sophisticated applications.

Gas is a fee payed to execute code, like transferring assets or creating a new
token. For this reason, a developer should focus on the quality of the smart
contract so that it can be run at a reasonable price. Furthermore, Ethereum is
not optimized for large amounts of data, since blocks have a maximum size based
on gas. Ethereums blocks can contain around 8 million gas, which is roughly 380
transactions. Executing smart contract code is more expensive than transferring
assets, as the user pays gas for every computation and read/write call.

It is interesting to consider how economic incentives can be applied to dis-
pute resolution and punishment of malicious participants in a decentralized
system such as Ethereum. Augur, a decentralized prediction market running on
Ethereum, uses economic game theory to encourage participants to report the
correct outcome of events. In the case of disagreement between which outcome

14



is correct, or a market maker maliciously deciding a wrong outcome, a dispute
resolution can be activated which essentially lets people bet on the correct out-
come being chosen. Since the outcome should be publicly known at this point,
it is theorized that the result of the dispute resolution will converge on the true
answer, as it becomes the Schelling point.

Smart contracts will be used to create the decentralized solutions for this
project.

2.2.3 Certificate Transparency

The goal of the Certificate Transparency protocol is to allow interested parties
to discover misissued certificates[22]. The protocol aims to achieve this by cre-
ating publicly auditable, append-only logs containing issued certificates. This
makes it possible";"""date"",""2020-11-30T13:57:15Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2020-11-30T13:57:15Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017) kpathsea version 6.2.3""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2020-11-30T13:57:15Z""
""created"",""2020-11-30T13:57:15Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-11-30T13:57:15Z""
""resourceName"",""Thesis.pdf""
""Author"",""""
""producer"",""pdfTeX-1.40.18""
""pdf:docinfo:producer"",""pdfTeX-1.40.18""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""1"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2020-11-30T13:57:15Z""
""Last-Modified"",""2020-11-30T13:57:15Z""
""dcterms:modified"",""2020-11-30T13:57:15Z""
""title"",""""
""Last-Save-Date"",""2020-11-30T13:57:15Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2020-11-30T13:57:15Z""
""meta:save-date"",""2020-11-30T13:57:15Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017) kpathsea version 6.2.3""
""Content-Length"",""1018789""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""79""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""1106"",""1782"",""1563"",""872"",""2117"",""2254"",""2305"",""2145"",""1985"",""1198"",""2425"",""805"",""2257"",""2634"",""2372"",""1336"",""2054"",""1771"",""1334"",""1198"",""1104"",""1747"",""256"",""2318"",""1935"",""2685"",""1477"",""2190"",""1754"",""1293"",""2189"",""2415"",""2354"",""1249"",""2454"",""504"",""1832"",""2131"",""1339"",""1102"",""1503"",""293"",""1905"",""2559"",""2275"",""2274"",""2339"",""2325"",""2394"",""1323"",""2184"",""2021"",""2547"",""2260"",""2565"",""2377"",""2268"",""2373"",""2335"",""1465"",""2413"",""118"",""1621"",""1751"",""1511"",""1411"",""1216"",""1381"",""1709"",""1263"",""1323"",""1590"",""1692"",""1256"",""1204"",""1198"",""1314"",""1054"",""621""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-11-30T13:57:15Z""
";https://scholar.google.com/scholar?start=480&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094534-622;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;A generic framework for a Peer to Peer Blockchain based Fog Architecture in Industrial Automation;EN Lallas, A Xenakis… ; 2019 4th SouthEast …, 2019  ieeexplore.ieee.org;;"… Sometimes, other entities that do not belong to the Blockchain system may temporarily need to

gain access and interact with the recorded events (eg, a single board CPU with Arduino OS).

This is feasible via oracles, which are python scripts that activate JSON remote …";Cité 4 fois;Les 2 versions;[PDF] researchgate.net;"https://www.researchgate.net/profile/Apostolis_Xenakis/publication/
337502070_A_generic_framework_for_a_Peer_to_Peer_Blockchain_based_Fog_Architecture_in_Industrial_Automation/links/5e3d50ab299bf1cdb91516df/A-generic-framework-for-a-Peer-to-Peer-Blockchain-based-Fog-Architecture-in-Industrial-Automation.pdf";;;https://scholar.google.com/scholar?start=440&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094565-758;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Smart contracts y Blockchain: calificación jurídica de los Smart contracts en el ecosistema de las Tecnologías de Registro Distribuido.;I Ortega Pérez, I Moralejo Menéndez ; zaguan.unizar.es;;"… de bloques. Por último, se debe ańadir que existe la posibilidad de introducir datos en los Smart

contracts a partir de fuentes de información externas a Blockchain. Los denominados oracles

(u oráculos) son tales fuentes externas que permiten a los Smart contracts ampliar …";Autres articles;Version HTML;[PDF] unizar.es;https://zaguan.unizar.es/record/85874/files/TAZ-TFG-2019-284.pdf;"
 

 

 

 

 

Trabajo Fin de Grado 
 

 

Smart contracts y Blockchain: calificaciĂłn jurĂ­dica de 

los Smart contracts en el ecosistema de las 

TecnologĂ­as de Registro Distribuido. 

 

Smart contracts and Blockchain: legal qualification of Smart 

contracts in the DLT ecosystem. 

 

 
Autora 

 

Irene Ortega PĂŠrez 

 

 
Director 

 

Ignacio Moralejo MenĂŠndez 

 

Facultad de EconomĂ­a y Empresa, Universidad de Zaragoza 

2018-2019 

  



 

 

Autora: Irene Ortega PĂŠrez. 

Director: Ignacio Moralejo MenĂŠndez. 

TĂ­tulo: Smart contracts y Blockchain: calificaciĂłn jurĂ­dica de los Smart contracts en el 

ecosistema de las TecnologĂ­as de Registro Distribuido.  

Title: Smart contracts and Blockchain: legal qualification of Smart contracts in the DLT 

ecosystem. 

TitulaciĂłn: Derecho y AdministraciĂłn y DirecciĂłn de Empresas. 

RESUMEN 

El objetivo de este trabajo es el anĂĄlisis jurĂ­dico de los Smart contracts en el nuevo 

ecosistema de las TecnologĂ­as de Registro Distribuido (DLT, por sus siglas en inglĂŠs). 

Estos Smart contracts, que se hallan en un estadio incipiente, consisten en secuencias de 

cĂłdigos capaces de ejecutar autĂłnomamente las prestaciones a las que las partes se 

obliguen.   

Con este fin y dada la todavĂ­a escasa literatura cientĂ­fica-legal al respecto, se ha abordado 

un doble enfoque con fuentes teĂłrico-acadĂŠmicas, acudiendo a doctrina reconocida para 

analizar la base contractual de esta tecnologĂ­a, y con fuentes alternativas de comunicaciĂłn 

del conocimiento propias de este ĂĄmbito, como foros, blogs o White papers donde los 

precursores de estas tecnologĂ­as se han manifestado.   

Mediante este estudio, se pretende determinar cuĂĄl debe ser la calificaciĂłn jurĂ­dica de los 

Smart contracs, asĂ­ como cuales son los principales retos jurĂ­dicos que plantea esta 

realidad. Asimismo, se analizarĂĄ el impacto de estos Smart contracts en el pago, respecto 

al notariado y en sede judicial. Por Ăşltimo, se pretende mostrar la iniciativa de ciertos 

paĂ­ses en incorporar a sus marcos legales esta nueva herramienta de ÂŤcontrataciĂłnÂť.  

ABSTRACT 

The aim of the current dissertation is to study from a legal point of view the Smart 

contracts in the new Distributed Ledger Technology (DLT) ecosystem. These Smart 

contracts, a technology in the early stages, consist of code sequences that are able to 

autonomous execute already agreed contractual benefits.    

In order to achieve this purpose and being aware of the scarce legal literature, a double 

approach has been taken, using legal doctrine to examine the contractual basis of this 



 

 

technology, as well as other alternative sources of knowledge commonly used in the 

technology field, such as Internet forums, blogs or White papers in which the precursors 

of the Smart contracts have spoken out.  

Through this study I intend to establish the legal qualification of the Smart contracts and 

the main legal challenges that this reality poses. Additionally, I examine the impact of the 

Smart contracts on the fulfilment of the agreement, on the public notaries role and on the 

courts. Finally, I present the endeavours of certain countries that are including this new 

“contractual” tool on their legal frameworks. 



 

 

 

ÍNDICE 

RESUMEN ....................................................................................................................... 1 

ABSTRACT ..................................................................................................................... 1 

I. INTRODUCCIÓN ........................................................................................................ 1 

II. BLOCKCHAIN ........................................................................................................... 3 

1. QUÉ ES ..................................................................................................................... 3 

2. FUNCIONAMIENTO .............................................................................................. 4 

III. SMART CONTRACTS .............................................................................................. 7 

1. CONCEPTO Y TIPOLOGÍA ................................................................................... 8 

2. CALIFICACIÓN JURÍDICA ................................................................................... 8 

2.1. CASO 1: EL CÓDIGO NO COEXISTE CON OTRO DOCUMENTO EN 

LENGUAJE NATURAL. ......................................................................................... 9 

2.2. CASO 2: SMART CONTRACT COMO EXIGENCIA DE FORMA 

CONSTITUTIVA.................................................................................................... 10 

2.3. CASO 3: LA DOCUMENTACIÓN EN SMART CONTRACT COMO 

PRESUPUESTO DE ÂŤEFICACIAÂť. ...................................................................... 11 

2.4. CASO 4: LA INTRODUCCIÓN DE UN TERCERO DE CONFIANZA....... 15 

3. UN EJEMPLO DE APLICACIÓN: THE DAO ...................................................... 18 

4. EL PAGO ................................................................................................................ 20 

5. EJECUCIÓN: ¿TÍTULOS EJECUTIVOS? ............................................................ 21 

6. EL NOTARIADO Y LA FUERZA PROBATORIA ............................................. 24 

7. CONFLICTOS JURÍDICOS .................................................................................. 27 

III. REGULACIÓN EN LA ACTUALIDAD: DERECHO COMPARADO ................. 33 

1. ESTADOS UNIDOS .............................................................................................. 33 

2. EUROPA ................................................................................................................ 34 

IV. CONCLUSIONES ................................................................................................... 36 

BIBLIOGRAFÍA ............................................................................................................... i 



1 

 

 

I. INTRODUCCIÓN 

El mundo hoy se enfrenta a una nueva revoluciĂłn tecnolĂłgica. DetrĂĄs de las numerosas 

noticias sobre Bitcoin y el resto de las criptomonedas, que tanta expectaciĂłn e inversiĂłn 

estĂĄn generando, se encuentra la tecnologĂ­a Blockchain. Cada vez mĂĄs agentes comienzan 

a estudiar y experimentar con las posibilidades que ofrece la tecnologĂ­a de la cadena de 

bloques.   

Algunos precursores de esta disruptiva tecnologĂ­a prevĂŠn transformaciones tan 

trascendentales como la desapariciĂłn del intermediario bancario tal y como se conoce 

hoy, el cambio del papel que desempeĂąan los Estados, el modo en que se realizan las 

transacciones o incluso la funciĂłn de los jueces. Si bien es cierto que la potencialidad de 

esta tecnologĂ­a, sobre todo, en sede empresarial y legal es inmensa, la burbuja del ÂŤ.comÂť 

fue una lecciĂłn de prudencia ante el impacto de las nuevas tecnologĂ­as.  

En este sentido, Internet supuso una nueva forma de hacer negocios y un punto de 

inflexiĂłn para la comercializaciĂłn de productos mĂĄs allĂĄ de las fronteras. Ahora bien, 

estas nuevas realidades de contrataciĂłn electrĂłnica se encontraron con un cuerpo jurĂ­dico 

capaz de asemejar las instituciones existentes a estos nuevos fenĂłmenos, adaptĂĄndose a 

las nuevas circunstancias y resolviendo los conflictos que surgĂ­an. La regulaciĂłn de la 

contrataciĂłn mercantil y civil incorporĂł al rĂŠgimen negocial las nuevas exigencias de la 

contrataciĂłn electrĂłnica, de defensa de consumidores y usuarios que contrataban 

electrĂłnicamente y la regulaciĂłn sobre firma electrĂłnica, entre otras. 

AsĂ­ las cosas, es necesario un estudio concienzudo de la tecnologĂ­a Blockchain y, 

especialmente, de los Smart contracts en el ĂĄmbito jurĂ­dico, en aras de aprovechar todas 

las oportunidades que pueden ofrecer (eficiencia, reducciĂłn de costes, objetivaciĂłn de la 

ejecución de las prestaciones…) sin tropezar con la especulación que ya se sufrió a finales 

del siglo pasado.  

Comprender jurĂ­dicamente la figura de los Smart contracts, entendiendo las ventajas y 

los inconvenientes que plantean para ciertos negocios, asĂ­ como los retos legales que 

suponen las notas caracterĂ­sticas de estos acuerdos deviene primordial en este momento.  

La concreciĂłn de los marcos legales adecuados a los efectos de conseguir seguridad 

jurĂ­dica es fundamental para que se pueda extraer el mayor potencial de esta nueva 



2 

 

tecnologĂ­a sin descuidar los intereses de todas las partes involucradas: consumidores, 

instituciones pĂşblicas y empresa privada.  

Por ello, el estudio de la cuestiĂłn de los Smart contracts desde una perspectiva legal es 

imprescindible para generar seguridad y fomentar el emprendimiento en una tecnologĂ­a 

que se asemeja en impacto a la revoluciĂłn que supuso Internet.      

En este momento en el que la tecnologĂ­a se encuentra en un estadio incipiente, este estudio 

tiene por objetivos el anĂĄlisis de la figura del Smart contract, planteando si responde 

realmente a un contrato en sentido jurĂ­dico y las cuestiones que ello conlleva en tĂŠrminos 

de lenguaje, documentaciĂłn, cumplimiento de obligaciones, funciĂłn contractual y prueba, 

entre otros.   

El trabajo queda dividido en los siguientes capĂ­tulos:  

− Un primer capítulo introductorio de la tecnología Blockchain, explicando su 

funcionamiento y sus fundamentos.  

− Un segundo capítulo donde se profundiza en el análisis legal de los Smart 

contracts estudiando su carĂĄcter contractual, las cuestiones de forma y 

documentaciĂłn, la construcciĂłn de la figura del tercero de confianza y lo relativo 

al pago como cumplimiento de las prestaciones. Asimismo, se presenta un 

ejemplo de aplicaciĂłn real, el caso The DAO. 

− Un tercer capítulo en el que se examinan otras cuestiones jurídicas que se verán 

afectadas por los Smart contracts como son la cuestiĂłn de la funciĂłn del notariado, 

la fuerza probatoria y los nuevos motivos de litigiosidad entre contratantes.  

− Un cuarto capítulo en el que se recorre sucintamente las propuestas de ciertos 

paĂ­ses que estĂĄn regulando sobre la materia, como Estados Unidos o Malta.   

− Finalmente, se presentan las conclusiones del análisis, donde se resumen los 

aspectos mĂĄs relevantes de los Smart contracts en el marco jurĂ­dico actual.  

  



3 

 

II. BLOCKCHAIN 

1. QUÉ ES 

Blockchain es un controlador distribuido (en inglĂŠs, Distributed Ledger Technology o 

DLT), esto es, un registro o una base de datos que se comparte y se replica en una red de 

nodos (miembros) descentralizada (NAKAMOTO, 2008; BRAKEVILLE y PEREPA, 

2018).  

En otras palabras, Blockchain se ha entendido como un libro contable que se duplica 

tantas veces como nodos tenga la red y que se actualiza continuamente para que la 

informaciĂłn sea consistente en todo momento.  

En este libro, las transacciones se introducen por bloques de informaciĂłn que, una vez 

validados, se incorporan a la cadena replicada en toda la red. Cada bloque cuenta con: i) 

un cĂłdigo alfanumĂŠrico que identifica al bloque predecesor (hash); ii) las transacciones; 

iii) un cĂłdigo alfanumĂŠrico para identificar al bloque siguiente. AsĂ­ todos los registros 

cuentan con una firma criptogrĂĄfica Ăşnica y una marca temporal (MORA, 2018).  

La cadena de bloques es, por tanto, un historial de transacciones de activos organizadas 

en bloques encadenados para generar una Ăşnica fuente de verdad. De este modo, si alguno 

de los nodos quisiera modificar una entrada previa, tambiĂŠn tendrĂ­a que alterar toda la 

cadena de bloques posterior para que fuera consistente. El nodo malicioso deberĂ­a cumplir 

esta tarea antes de que el resto de los nodos acabasen con el bloque en que ya se estĂĄ 

trabajando, o el proceso volverĂ­a a empezar. La capacidad computacional para ello es 

prĂĄcticamente inabarcable, lo que garantiza la autenticidad de la informaciĂłn. Esta 

configuraciĂłn estĂĄ basada en lo que se conoce como proof of work.  

En este sentido, el uso mĂĄs conocido de Blockchain es el de las criptomonedas, mĂĄs 

concretamente Bitcoin. Estas criptomonedas se apoyan en el registro contable distribuido 

de Blockchain para recoger sus transacciones. Ahora bien, las monedas no dejan de ser 

unidades de valor (los denominados tokens) o activos. Por lo tanto, las posibilidades de 

la cadena de bloques son numerosas, sobre todo en aquellos ĂĄmbitos donde concurra una 

red (empresarial), transacciones y un registro consensuado a prueba de manipulaciĂłn. 

ÂżCuĂĄl es la novedad de esta tecnologĂ­a? En relaciĂłn con las comunicaciones tradicionales 

a travĂŠs de Internet, un rasgo inherente a ellas ha sido desarticulado en estos primeros 

pĂĄrrafos sin que el lector haya sido expresamente avisado: ha desaparecido el principio 



4 

 

doble gasto. La disrupciĂłn que trae consigo esta tecnologĂ­a es la posibilidad de transmitir 

ÂŤverdaderamenteÂť un activo, de modo que una vez usado no se puede volver a disponer 

de ĂŠl.  

Internet ha permitido la transmisiĂłn de archivos e informaciĂłn en todo el mundo 

conectado. No obstante, hasta ahora lo que se ha transmitido de un lugar a otro de la red 

son copias, puesto que nada impedĂ­a el doble gasto. Si A envĂ­a un archivo de mĂşsica a B 

a cambio de un precio, B no puede confiar en que A no se haya quedado una copia de ese 

archivo de mĂşsica con la canciĂłn en su dispositivo.  

Frente a este paradigma, Blockchain se configura como el libro contable donde registrar 

activos a nivel global. AsĂ­, la propiedad de A, la transmisiĂłn de A a B y la nueva 

titularidad de B son recogidas de forma pĂşblica y verificable en toda esa red. A no puede 

volver a transmitir tal activo porque al reflejar su previa titularidad y la transmisiĂłn en el 

registro, ya no dispone de ĂŠl frente a ningĂşn tercero; informaciĂłn que es accesible para 

todos los miembros.  

AdemĂĄs, no serĂĄ un tercer intermediario el que mantenga una relaciĂłn con A y verifique 

su titularidad, registre la transmisiĂłn y dĂŠ prueba de la nueva situaciĂłn de B. Es el sistema 

el que, construido a partir de la desconfianza entre sus miembros, garantiza las 

titularidades.  

Todos los nodos cuentan con una copia consistente del historial de A que actualizan con 

las nuevas transacciones, es decir, es la propia comunidad la que autentifica su titularidad 

y la transmisiĂłn. La verdad registrada se consigue por consenso, por la aprobaciĂłn de ese 

registro por la mayorĂ­a de los nodos o miembros de la red. AsĂ­, no existe un intermediario 

privilegiado en el que reside el poder de decisiĂłn sobre la verdad -tĂ­picamente, un banco 

que registre en sus libros contables el dinero del que dispone A, y la transmisiĂłn a la 

cuenta de B, informaciĂłn en la que ambas partes confĂ­an. En contra de lo que era habitual 

hasta ahora, no rige el principio de centralizaciĂłn y, por tanto, dado que nadie controla la 

informaciĂłn centralizadamente, nadie concentra el poder.  

En conclusiĂłn, Blockchain es la tecnologĂ­a que permite la transmisiĂłn de activos entre 

iguales sin la necesidad del intermediario tradicional.  

2. FUNCIONAMIENTO 

Sin ĂĄnimo de desarrollar tĂŠcnicamente el funcionamiento de Blockchain, se presenta un 

ejemplo simplificado de una transacción registrada en la cadena de bloques (PÉREZ-



5 

 

SOLÀ y HERRERA-JOANCOMARTÍ, 2014). El objetivo es mostrar los procesos de 

validaciĂłn, afianzamiento, transmisiĂłn y almacenamiento de forma accesible. 

En el ejemplo Ana (A) desea enviar a Benito (B) 25 BITCOIN (aunque podrĂ­a ser 

cualquier otro activo, 25 tokens). Para ello, tanto Ana como Benito cuentan con una clave 

pĂşblica y una privada: {PKA, SKA}, {PKB, SKB}. La funciĂłn Addr{PK) permite obtener 

la direcciĂłn de la clave pĂşblica PK, H es una funciĂłn Hash (vinculaciĂłn con el bloque 

anterior) y Sigsk(m) representa la firma de m con la clave privada.  

Ana ha recibido inicialmente 25 BTC: 

 To = {inputo, outputo}  

 Inputo = {…}  

 Outputo = {Addr(PKA), 25}  

Ana ha recibido a travĂŠs de su clave pĂşblica la cantidad de 25 BTC a los que va a acceder 

mediante su clave privada para enviĂĄrselos a Benito. Por ello:  

T1 = {input1, output1}  

  Input1 = {H(To), SigskA(To + output1), PKA}  

 Output1 = {Addr(PKB), 25}  

El protocolo está diseñado para que Ana señale su “situación contable” previa con el 

Hash, decida disponer de ello mediante su clave privada aludiendo a la transacciĂłn previa 

por la que tiene los 25 BTC que quiere transmitir y su clave pĂşblica. Ahora bien, esa 

situaciĂłn contable previa no es tanto un balance total asociado a Ana, sino un conjunto 

de transacciones previas a las que ella puede referirse para futuros movimientos, en el 

ejemplo sĂłlo ha habido una To. 

Asimismo, Ana transfiere a Benito solicitando su clave pĂşblica y determinando la 

cantidad a transmitir. En futuras transacciones Benito se referirĂĄ a esta T1 para una 

potencial T2, disponiendo con su clave privada y conociendo su clave pĂşblica por la que 

ha recibido T1.  

En tĂŠrminos de validaciĂłn, no hay doble gasto ya que T1 se remite a To y eso sĂłlo es 

posible una vez. AdemĂĄs, Ana es propietaria de los 25 BTC dado que existe una 

posiciĂłn/transacciĂłn previa To. En cuanto al afianzamiento, la prueba de trabajo (proof of 

work) garantiza el registro comĂşn Ăşnico de la informaciĂłn que sĂłlo podrĂĄ ser alterada si 



6 

 

se consigue un poder de cĂłmputo mayor del 50%. La transmisiĂłn de la transacciĂłn se 

propaga por toda la red y el almacenaje supone que todos los nodos contienen una copia 

completa de la cadena de bloque por lo que todos validan cada transacciĂłn nueva.  

En caso de que Ana quisiera transferir a Benito una cantidad diferente y necesariamente 

menor a la recibida en To (por ejemplo, 20 BTC) el modelo varĂ­a, pero se consigue 

mantener las mismas virtudes. Grosso modo, Ana envĂ­a 25 BTC, recibiendo una 

transferencia por valor de 5 BTC que es el sobrante. Esta nueva transacción (T1’) de valor 

5 BTC permite a Ana disponer de lo que le queda; puesto que To ya ha sido gastada. Por 

su parte, Benito recibe los 20 BTC y cuenta con una transacción (T1’’) a la que referirse 

para futuras transacciones (COINEST.CO, 2017). 

Cabe seĂąalar que la cadena de bloques, en principio, no se preocupa del contrato 

subyacente por el cual Ana envĂ­a 25 BTC a Benito, ni siquiera de si la cantidad debida 

era mayor o inferior. Blockchain permite y registra la transacciĂłn. De igual manera que 

una entidad bancaria transmite lo que su cliente ordena a otra cuenta, independientemente 

del contrato subyacente; la cadena de bloques recoge la transacciĂłn y da prueba de ella. 

Por tanto, serĂĄ la justicia, en su caso, la que posteriormente decida si se ha cumplido el 

contrato; si bien, el juez podrĂĄ acudir a Blockchain para confirmar que efectivamente 25 

BTC ya han sido transferidos. Todo ello serĂĄ discutido en los siguientes capĂ­tulos.  

En conclusiĂłn, se obtiene un sistema de transmisiĂłn que es secuencial (garantiza un orden 

cronolĂłgico), consistente, resistente, distribuido, que evita el doble gasto y que no 

requiere de un intermediario, sino de una red de miembros.  

  



7 

 

III. SMART CONTRACTS 

Un Smart contract es un cĂłdigo de programaciĂłn informĂĄtico que permite, por operaciĂłn 

del propio ordenador, monitorizar y/o ejecutar un contrato, sin necesidad de intervenciĂłn 

humana (SZABO, 1994; STOKES y FREIRE RAMOS, 2017).  

En lĂ­nea con lo seĂąalado en el apartado anterior, un Smart contract permite transacciones 

mĂĄs complejas que la que concurrĂ­a entre los protagonistas del ejemplo mostrado. El 

cĂłdigo genera una cuenta ajena y controlada que ejecuta transacciones ante ciertas 

condiciones codificadas.  

En general, los Smart contracts cuentan con tres atributos a destacar respecto de los 

negocios habituales; son acuerdos autoejecutables, digitales y descentralizados. Ser 

autoejecutable implica que, si las condiciones predefinidas en el programa se cumplen, la 

consecuencia contractual se ejecuta de manera autĂłnoma. Esto es, las partes registran las 

condiciones y los hechos que deben estar configurados siguiendo el modelo: ÂŤsi X, 

entonces YÂť. De esta forma, una vez concurre el hecho desencadenante, el cumplimiento 

de la consecuencia escapa de la voluntad de las partes, es un hecho que tambiĂŠn ocurrirĂĄ. 

Por su parte, su conformaciĂłn digital permite que se halle en Blockchain y que pueda ser 

interpretado tanto por humanos como por mĂĄquinas. Esta interpretaciĂłn consiste en que 

las mĂĄquinas pueden leerlo y ejecutarlo, sin que sea posible (todavĂ­a) atribuirles una 

comprensiĂłn real de lo establecido. Finalmente, la descentralizaciĂłn evita al 

intermediario y proporciona veracidad y seguridad, gracias a la tecnologĂ­a de la cadena 

de bloques.  

Por Ăşltimo, se debe aĂąadir que existe la posibilidad de introducir datos en los Smart 

contracts a partir de fuentes de informaciĂłn externas a Blockchain. Los denominados 

oracles (u orĂĄculos) son tales fuentes externas que permiten a los Smart contracts ampliar 

su ĂĄmbito de aplicaciĂłn. PiĂŠnsese en una orden de compra de acciones cuando la 

cotizaciĂłn alcance un determinado nivel. El Smart contract se configura para que 

confirme la informaciĂłn con una determinada fuente (por ejemplo, la web oficial bolsa 

de Madrid) que las partes consideran fiable. AdemĂĄs, ya se estĂĄn planteando orĂĄculos en 

que la informaciĂłn responde a mĂĄs de una fuente, introduciendo el consenso y mayor 

fiabilidad a la informaciĂłn.  

A partir de todo lo expuesto, deviene necesario identificar la realidad jurĂ­dica que 

representan los Smart contracts, asĂ­ como alguno de los retos que plantean.  



8 

 

1. CONCEPTO Y TIPOLOGÍA 

Una vez mostradas las ideas fundamentales de un Smart contract, se debe tener en cuenta 

que este concepto nace del ĂĄmbito tecnolĂłgico y no del jurĂ­dico. AsĂ­ las cosas, el tĂŠrmino 

recoge una amplia gama de posibilidades, desde meros cĂłdigos de ordenador que ejecutan 

Ăłrdenes hasta cĂłdigos complejos que representan y acogen un ÂŤcontratoÂť.  

Con el objetivo de centrar el objeto de estudio resultan prĂĄcticas e interesantes las 

clasificaciones que realizan dos autores.  

STARK (2016) diferencia entre lo que ĂŠl denomina ÂŤSmart Contract CodeÂť y ÂŤSmart 

Legal ContractÂť. El primero hace referencia a un programa complejo, almacenado y 

ejecutado en Blockchain que gobierna algo valioso. Mientras, el segundo, utiliza el cĂłdigo 

para articular, verificar y hacer cumplir un acuerdo, combinando lenguaje mĂĄquina y 

natural. El valor de distinguir ambos conceptos reside en apartar del estudio aquellos 

cĂłdigos que no recogen un contenido jurĂ­dico relevante.  

Tomando los Smart Legal Contracts como punto de partida, se utilizarĂĄ la clasificaciĂłn 

material de FELIU REY (2018) para mostrar las realidades que abarca este concepto. En 

primer lugar, el cĂłdigo puede recoger por entero un previo contrato para su cumplimiento. 

En segundo lugar, el cĂłdigo puede ser el acuerdo, sin que coexista un soporte alternativo. 

En tercer lugar, el cĂłdigo puede recoger sĂłlo ciertas obligaciones de un negocio concluido 

previamente. En cuarto lugar, siendo una variante de los anteriores, el cĂłdigo puede 

responder a un contrato acordado en otro soporte en el que se ha decidido que ciertas 

obligaciones se establezcan directamente como Smart Legal Contract, por lo que ellas no 

cuentan con rĂŠplica en el negocio en lenguaje natural.  

Estas realidades merecen una calificaciĂłn jurĂ­dica distinta. Es por ello que, en los 

subsiguientes apartados, se valorarĂĄ cada uno de estos modelos de Smart Legal Contract 

y se plantearĂĄn las cuestiones legales mĂĄs relevantes.  

2. CALIFICACIÓN JURÍDICA 

En primer lugar, conviene realizar una introducciĂłn a la distinciĂłn entre forma y 

documentaciĂłn del contrato. Si bien esta diferenciaciĂłn no es nueva en materia de 

contrataciĂłn, resulta imprescindible recordarla en lo relativo a los Smart contracts.  

DÍEZ-PICAZO (2007) define la forma como «el vehículo o medio de expresión del cual 

las partes se sirven para emitir sus declaraciones de voluntad y para hacerlas llegar o 



9 

 

darlas a conocer a sus destinatariosÂť, mientras que documentaciĂłn es ÂŤla operaciĂłn 

necesaria para plasmar y recoger documentalmente las declaraciones de voluntad que 

forman la esencia del contratoÂť. 

AsĂ­ las cosas, el autor recalca la importancia de no confundir ambos conceptos. Es 

necesario distinguir que el documento puede no ser la forma, es decir, el medio de 

manifestar la voluntad, sino un documento posterior al contrato ya perfeccionado con el 

objetivo principal de conservarlo.  

El anĂĄlisis del autor sobre las situaciones entre acuerdo no documentado y documentaciĂłn 

constitutiva, acuerdo no documentado y documentaciĂłn como presupuesto de eficacia, 

asĂ­ como la de documentaciĂłn privada y necesidad de Escritura PĂşblica se pueden utilizar 

de soporte para analizar los diferentes supuestos de Smart contracts.   

2.1. CASO 1: EL CÓDIGO NO COEXISTE CON OTRO DOCUMENTO EN 

LENGUAJE NATURAL.  

En este primer caso, el Smart contract es la forma. El cĂłdigo es el vehĂ­culo mediante el 

cual las partes emiten sus declaraciones y manifiestan sus voluntades. Asimismo, el Smart 

contract tambiĂŠn es el documento escogido por las partes. Esto es, se concentran en el 

Smart contract la representaciĂłn de un contrato y la funciĂłn de recogerlo, fijarlo y 

conservarlo.  

Siendo el cĂłdigo el Ăşnico soporte en el que se plasma el contrato el reto principal de este 

caso es la comprensibilidad del lenguaje. PiĂŠnsese en un supuesto de DAO, donde las 

condiciones son pĂşblicas para cualquier miembro de la red, quien se puede adherir a las 

mismas, pero sĂłlo son legibles en formato cĂłdigo. AsĂ­, es necesario cuestionar si las 

partes emiten conscientemente el consentimiento cuando no hay “traducción” al lenguaje 

natural.  

SURDEN (2012), junto con otros autores, plantea algunas soluciones. Por un lado, la 

coexistencia de un contrato en lenguaje natural que sirva de sustrato y que incorpore el 

cĂłdigo, asĂ­ como la interpretaciĂłn de ĂŠste. Por otro, propone que las partes se suscriban a 

un estĂĄndar de datos preexistente que garantice una cierta interpretaciĂłn de los datos y las 

fĂłrmulas utilizadas. AdemĂĄs, se propone el uso de interfaces que traduzcan lo introducido 

en lenguaje natural a lenguaje mĂĄquina de una determinada manera. AsĂ­, las partes estĂĄn 

acordando implĂ­citamente que los criterios de la interfaz sean entendidos como los 

tĂŠrminos de interpretaciĂłn y traducciĂłn del acuerdo. Por Ăşltimo, los contratantes tambiĂŠn 



10 

 

pueden suscribir un acuerdo marco donde se determinan estas condiciones para aplicarlas 

a un conjunto de Smart contracts. 

En todo caso, las cuestiones de comprensibilidad son parecidas a las que concurren en 

sede de contrataciĂłn mercantil internacional, donde convergen diferentes ordenamientos 

y lenguajes. La funciĂłn que venĂ­a desarrollando el traductor e intĂŠrprete colaborando con 

el abogado o jurista para diseĂąar el contrato, corresponderĂĄ ahora al programador.  

En conclusiĂłn, el cĂłdigo puede ser una forma vĂĄlida, un medio de expresiĂłn reconocible 

por el derecho. En este sentido, conforme aumente la prĂĄctica contractual y dado que estos 

Smart contract tienen vocaciĂłn internacional, es fĂĄcil que los problemas de 

comprensibilidad vayan resolviĂŠndose. La elaboraciĂłn de cĂłdigos que uniformicen las 

fĂłrmulas, las interfaces o los acuerdos marco que se pueden tomar de referencia harĂĄn 

posible que ciertas transcripciones/traducciones sean aceptadas y sirvan de base para las 

subsiguientes.    

Con todo, si se tratara de un contrato que incorpora condiciones generales, hay que 

recordar que el art. 7.b) de la Ley 7/1998, de 13 de abril, sobre condiciones generales de 

la contrataciĂłn determina la no incorporaciĂłn de las condiciones generales que sean 

ÂŤilegibles, ambiguas, oscuras e incomprensiblesÂť. Por consecuencia, resultarĂĄ difĂ­cil 

aceptar que en estos casos sea posible la adhesiĂłn sin un previo acuerdo en lenguaje 

natural que muestre claramente las obligaciones. 

Asimismo, el Real Decreto Legislativo 1/2007, de 16 de noviembre, por el que se aprueba 

el texto refundido de la Ley General para la Defensa de los Consumidores y Usuarios, en 

concreto respecto a los contratos con consumidores y usuarios que utilizan clĂĄusulas no 

negociadas individualmente, exige claridad en su redacciĂłn, accesibilidad y legibilidad 

(artĂ­culo 80). Estos principios, a mi juicio, no se cumplirĂ­an cuando el acuerdo sĂłlo sea 

accesible en formato cĂłdigo.  

2.2. CASO 2: SMART CONTRACT COMO EXIGENCIA DE FORMA 

CONSTITUTIVA. 

En principio, la regulaciĂłn ampara la libertad de forma a la luz de los artĂ­culos 1.278 de 

CĂłdigo Civil (en adelante, Cc) y 51 del CĂłdigo de Comercio (en adelante, CCom). 

AdemĂĄs, los Principios UNIDROIT sobre los contratos comerciales internacionales 

(2016) consagran la libertad de forma en su artĂ­culo 1.2. A ello se aĂąade el reconocimiento 

de la forma electrĂłnica en las mismas condiciones que el soporte papel, art. 24 LSSI.  Por 



11 

 

lo que, a priori, el hecho de que el contrato se documente en cĂłdigo no es requisito 

constitutivo.  

En este sentido, FELIU REY (2018) seĂąala la posibilidad de que las partes pueden otorgar 

a la documentaciĂłn el mencionado carĂĄcter constitutivo, al amparo del art. 1.255 Cc. Esta 

posibilidad tambiĂŠn ha sido confirmada a nivel internacional en el artĂ­culo 2.1.13 de los 

mencionados Principios UNIDROIT (2016). De este modo, hasta que las obligaciones no 

queden plasmadas en un Smart contract, no hay contrato perfecto.  

El desarrollo de las negociaciones previas responde en el iter contractual a tratos 

preliminares, a la negociaciĂłn. AsĂ­, las partes podrĂĄn acudir a los Ăłrganos jurisdiccionales 

competentes en términos de responsabilidad precontractual (DÍEZ-PICAZO, 2007; 

MARTÍNEZ DE AGUIRRE, 2000).  

En conclusiĂłn, se estĂĄ ante un contrato formal en el que las partes acuerdan que el cĂłdigo 

sea la forma elegida. Al otorgarle carĂĄcter constitutivo a la documentaciĂłn en Smart 

contract, el documento privado o acuerdo verbal precedente no se instituye en fuente de 

obligaciones convencional y queda en el ĂĄmbito de los tratos preliminares.    

2.3. CASO 3: LA DOCUMENTACIÓN EN SMART CONTRACT COMO 

PRESUPUESTO DE ÂŤEFICACIAÂť.  

Este supuesto no plantea duda sobre la calificaciĂłn jurĂ­dica de contrato celebrado con 

anterioridad al cĂłdigo. En la medida en que existe este acuerdo en lenguaje natural, si en 

ĂŠl concurren los requisitos de consentimiento, objeto y causa que exige el CĂłdigo Civil 

en su artĂ­culo 1.261, deberĂĄ calificarse de contrato vĂĄlido. 

En cuanto al consentimiento, conforme al art. 1.262 Cc, se manifiesta por el concurso de 

la oferta y la aceptaciĂłn; y desde que las partes consienten a obligarse el contrato existe, 

al amparo del artĂ­culo 1.254 Cc. En este sentido, puede ser aplicable lo relativo a la 

contrataciĂłn entre ausentes y/o a distancia, pero no necesariamente.  

Así, con OBREGÓN SIEGMUND (2012), la contratación a distancia implica una 

separaciĂłn geogrĂĄfica entre las partes contratantes mientras que la contrataciĂłn entre 

ausentes exige un lapso temporal entre oferta y aceptaciĂłn. Esto es relevante por cuanto 

un contrato como el analizado puede existir tanto entre presentes, ya sea fĂ­sicamente 

acordando el negocio y la forma de Smart contract, ya sea virtualmente por medios 

tĂŠcnicos como la videoconferencia; como entre ausentes, pensando en una oferta reflejada 



12 

 

en la Web que posteriormente acepta un sujeto. Igualmente, puede tratarse de un contrato 

a distancia o no, si las partes se reĂşnen a negociar este acuerdo y la aplicaciĂłn de un Smart 

contract.  

Todo ello permite afirmar que, aunque el contrato quede recogido en un Smart contract, 

no necesariamente se tratarĂĄ de un contrato celebrado por vĂ­a electrĂłnica conforme a la 

definiciĂłn de la Ley 34/2002, de 11 de julio de Servicios de la Sociedad de la InformaciĂłn 

(en adelante, LSSI) en la letra h) del anexo, ni precisarĂĄ de los re";"""date"",""2019-01-16T15:36:39Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.7""
""xmp:CreatorTool"",""MicrosoftÂŽ Word 2016""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dc:creator"",""Irene Ortega""
""language"",""es""
""dcterms:created"",""2019-01-16T15:36:39Z""
""Last-Modified"",""2019-01-16T15:36:39Z""
""dcterms:modified"",""2019-01-16T15:36:39Z""
""dc:format"",""application/pdf; version=1.7""
""xmpMM:DocumentID"",""uuid:EEF678E9-2ABE-4520-9EDF-B138F116E68F""
""Last-Save-Date"",""2019-01-16T15:36:39Z""
""pdf:docinfo:creator_tool"",""MicrosoftÂŽ Word 2016""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2019-01-16T15:36:39Z""
""meta:save-date"",""2019-01-16T15:36:39Z""
""pdf:encrypted"",""false""
""xmp:CreateDate"",""2019-01-16T16:36:39Z""
""modified"",""2019-01-16T15:36:39Z""
""Content-Length"",""966169""
""pdf:hasMarkedContent"",""true""
""Content-Type"",""application/pdf""
""xmp:ModifyDate"",""2019-01-16T16:36:39Z""
""pdf:docinfo:creator"",""Irene Ortega""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Irene Ortega""
""dc:language"",""es-ES""
""meta:author"",""Irene Ortega""
""pdf:producer"",""MicrosoftÂŽ Word 2016""
""meta:creation-date"",""2019-01-16T15:36:39Z""
""created"",""2019-01-16T15:36:39Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""48""
""Creation-Date"",""2019-01-16T15:36:39Z""
""resourceName"",""TAZ-TFG-2019-284.pdf""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""394"",""2092"",""628"",""2737"",""2357"",""1828"",""2391"",""2440"",""2000"",""1754"",""2455"",""2410"",""2422"",""2456"",""2403"",""2533"",""2635"",""2561"",""2537"",""2663"",""2605"",""2381"",""2624"",""2430"",""2422"",""2523"",""2640"",""2428"",""2461"",""2423"",""1931"",""2609"",""2718"",""2462"",""2679"",""1501"",""2259"",""2366"",""1136"",""2283"",""2545"",""1777"",""1737"",""1760"",""2033"",""1998"",""1985"",""1254""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""Author"",""Irene Ortega""
""producer"",""MicrosoftÂŽ Word 2016""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""MicrosoftÂŽ Word 2016""
""pdf:docinfo:created"",""2019-01-16T15:36:39Z""
";https://scholar.google.com/scholar?start=570&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094614-965;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;PKP-Based Signature Scheme;G Macario;Rat, J Patarin, L Perret  Progress in Cryptology–INDOCRYPT …, 2019  Springer;;"… Unforgeable under Chosen Adaptive Mes- sage Attacks (EU-CMA) in the random oracle model,

if –the search version of the Permuted Kernel problem is intractable, –the hash functions and

pseudo-random generators are modeled as random oracles, –the commitment …";Autres articles;;null;;;;https://scholar.google.com/scholar?start=780&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094623-1005;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[PDF][PDF] Effective Privacy Preservation and Fast Signature Verification in Bitcoin Transaction.;Z Liu, Y Li, D Yuan, Y Liu ; IJ Network Security, 2019  ijns.jalaxy.com.tw;;"… aggregate signature scheme is proved to be unforgeable in the random oracles, and performance …

Each block contains multiple transactions in the bitcoin blockchain, and each transaction in- cludes …

t, and makes at most qh queries to hash function, qs queries to signing oracle …";Cité 1 fois;Les 2 versions;[PDF] jalaxy.com.tw;http://ijns.jalaxy.com.tw/contents/ijns-v21-n5/ijns-2019-v21-n5-p741-750.pdf;"
International Journal of Network Security, Vol.21, No.5, PP.741-750, Sept. 2019 (DOI: 10.6633/IJNS.201909 21(5).05) 741

Effective Privacy Preservation and Fast
Signature Verification in Bitcoin Transaction

Zhenhua Liu, Yuanyuan Li, Dong Yuan, and Yaohui Liu
(Corresponding author: Yuanyuan Li)

School of Mathematics and Statistics, Xidian University

Xi’an 710071, China

(Email: liyuanyuan4621@163.com)

(Received Jan. 29, 2018; Revised and Accepted July 20, 2018; First Online June 11, 2019)

Abstract

As a decentralized cryptocurrency, bitcoin has attracted
considerable attentions. In the original bitcoin system, a
transaction script is described as a plaintext and thus re-
veals the privacy. Furthermore, it takes at least one hour
to confirm one transaction, which causes high latency. In
view of these shortcomings, a new protocol is proposed
to preserve the transaction privacy and speed the verifi-
cation of transaction. Firstly, a modified homomorphic
Paillier cryptosystem is used to preserve transaction pri-
vacy for our protocol. Moreover, we combine Zhu et al.’s
interactive incontestable signature with Boneh et al.’s ag-
gregate technique to present a new aggregate signature
scheme, which can process a batch signature and greatly
reduce the storage space. Then our aggregate signature
scheme is applied to achieve fast verification for our pro-
tocol. Finally, our aggregate signature scheme is proved
to be unforgeable in the random oracles, and performance
analysis shows that our protocol has the property of pri-
vacy preserving and high efficiency.

Keywords: Aggregate Signature; Fast Verification; Pail-
lier Cryptosystem; Privacy Preserving

1 Introduction

Bitcoin blockchain can be essentially known as a decen-
tralized ledger system, which records the transactions
among bitcoin addresses. The transaction is a central
part of bitcoin blockchain, and the process of transaction
is divided into generation, propagation in the network,
proof of work, verification and record on the blockchain
in the end. In Nakamoto’s white paper, bitcoin is defined
as a chain-type string of digital signature. The owner of
bitcoin completes a transaction by making a digital sig-
nature of the previous transaction and the next owner’s
public key and attaching this signature to the transaction.
Various signature algorithms, such as multi-signature [8],
blind signature [9], proxy signature [10,12,14] and so on,
can be utilized in the process of signature [22]. Gener-

ally, each transaction in bitcoin includes multiple inputs
(one transaction can be sent by multiple individuals to
a user) and outputs (one transaction can be transferred
to multiple individuals). In addition, the input for each
new transaction is the unspent output of a transaction
(UTXO) and also needs to be signed by the private key
corresponding to the previous output, and all nodes on
the network verify the legitimacy of the new transaction
via UTXO and the signature algorithm. However, there
exist many problems and challenges with the development
of bitcoin [13].

There is a serious problem that the bitcoin system
only provides weak privacy protection. The unencrypted
transaction amounts might leak unpredictably massive in-
formation during the daily trading. The disclosure of pri-
vacy is mainly due to the public amount of transactions,
transaction metadata and distributed ledger, then the at-
tacker can extract a lot of information about the identity
of the user. Furthermore, the association between pay-
ment and receipt accounts allows the attacker to track
the entire historical transaction path [20].

In order to enhance privacy preservation, various meth-
ods have been proposed to improve the anonymity of bit-
coin. Bonneau et al. [4] proposed Mixcoin, which upsets
the relationship between the payment account and the
receive account, thereby increasing the anonymity of bit-
coin system. Wijaya et al. [25] also presented an improved
scheme to enhance the anonymity of bitcoin by lifting the
relevance of the transaction. Bergen et al. [2] established
an anonymous e-cash scheme CryptoNote by using ring
signature and concealing address. Miers et al. [16] de-
signed an extended bitcoin protocol Zerocoin based on
zero-knowledge proof. Ben-Sasson et al. [21] proposed
Zerocash based on the Zerocoin protocol by using the zk-
SNARKs [1] to achieve an anonymous e-cash system and
protect the transaction privacy, but Zerocash needs some
strong trust assumptions, which deviates from the original
trust intention. Ibrahim [11] constructed Securecoin to
improve anonymous in bitcoin. Wang et al. [24] adopted
Paillier Cryptosystem to hide the transaction amount and



International Journal of Network Security, Vol.21, No.5, PP.741-750, Sept. 2019 (DOI: 10.6633/IJNS.201909 21(5).05) 742

then improve the anonymity of the system, which is com-
patible with the bitcoin system.

Simultaneously, for legal digital currencies, there is an-
other problem that the bitcoin system suppplies sluggish
transaction speed. In the original bitcoin transaction [17],
the miners need to spend 10 minutes to dig a block. It
takes at least 1 hour to ensure the irreversible transaction.
Therefore, it is very meaningful to study on improving the
speed of transaction.

In order to solve this problem, some technologies such
as expansion, lightning network and other programs are
introduced. The expansion includes the isolation of wit-
ness and hard bifurcation block expansion [6, 23]. Light-
ning network is a side-chain technology, which reduces the
burden of the main chain transaction significantly and
expand more payment model [19]. In addition, Eyal et
al. [7] introduced a new interest measurement method
for quantifying the relationship between the security and
efficiency of bitcoin-like blockchain protocols. Micali et
al. [15] proposed an efficient public book agreement, a
variant of Proof-of-Stake mechanism, that can solve the
problem of bitcoin transaction delays, energy waste and
bifurcation, which requires the number of attackers or the
number of assets controlled by an attacker are less than
1/3 of the total amount. Zhu et al. [27] proposed an inter-
active incontestable signature scheme to achieve instant
confirmation.

Although the above schemes can solve the correspond-
ing problems about efficiency or privacy, they fail to bal-
ance efficiency and privacy issues in various bitcoin-like
systems. Chang et al. [5] modified Ohta-Okamoto digital
signature to achieve batch verification. Yuan et al. [26] ap-
plied aggregate signature technique to protect privacy and
improve the performance of signature, but their scheme
is not compatible with bitcoin system. There is still not
a perfect scheme that can not only increase the speed of
transaction confirmation but also protect users privacy
about transaction amount until now. Therefore, it is a
great deal to study a scheme that can both protect pri-
vacy and speed up signature verification.

Our Contributions. This paper mainly focuses on pri-
vacy preserving and fast confirmation in bitcoin sys-
tem. We propose a new scheme that can not only
protect users’ privacy but also increase the speed of
transaction confirmation. The main techniques and
contributions are summarized as follows:

1) To preserve the transaction privacy, we modify
Wang et al.’s scheme [24] to encrypt the appar-
ent amounts of users, which doesn’t undermine
the consensus mechanism;

2) In the process of signature, we propose a new
aggregate signature based on interactive incon-
testable signature and aggregate signature tech-
nology and prove its security, which can be ap-
plied to achieve fast verification for our protocol;

3) We combine the modified Wang et al.’s

scheme [24] with new aggregate signature tech-
nique to propose a new protocol for bitcoin sys-
tem, which achieves privacy preservation and
fast verification of signature.

Organization. The rest of this paper is organized as fol-
lows: Section 2 introduces some preliminaries. Sec-
tion 3 focuses on transaction privacy with Paillier
cryptosystem. Section 4 mainly presents our aggre-
gate signature and security proof. Section 5 proposes
our new protocol, gives the comparisons between new
protocol and related works in functionality, and an-
alyzes security and efficiency. Finally, the conclusion
is shown in Section 6.

2 Preliminaries

2.1 Paillier Cryptosystem

Paillier cryptosystem is a homomorphic encryption
scheme, which is based on the composite residuosity class
problem [18]. We review the encryption/decryption pro-
cess simply as follows:

KeyGen. Set n = pq, compute λ = λ(n) = lcm(p −
1, q−1), and select a base g ∈ G randomly satisfying
gcd(L(gÎť mod n2), n) = 1, where p and q are large
primes, G is a multiplicative group G =

{
w|w ∈ Z∗n2

}
and L (θ) = θ−1

n . The public key is pk = (n, g) and
secret key is sk = Îť.

Encrypt. For a message m < n, choose a random num-
ber r < n, and compute the corresponding ciphertext

c = Encpk (m) = gmrn mod n2

Decrypt. Decrypt the ciphertext c < n2 and obtain

m = Decsk (m) =
L(cÎť mod n2)

L(gÎť mod n2)
mod n.

Paillier cryptosystem has an additive homomorphic
property as:

Dec(Encpk(m1) ¡Encpk(m2) mod n2) = (m1+m2) mod n.

Paillier cryptosystem can perform efficiently both en-
cryption and decryption and be convincingly secure under
the chosen-plaintext attack in the standard model [18].
Due to the inherent additive homomorphic, the Paillier
cryptosystem can be applied to various fields, such as the
design of voting protocols, the threshold cryptosystem,
etc. Furthermore, to preserve the transaction privacy in
the bitcoin system, Wang et al. [24] utilized Paillier cryp-
tosystem to hide the transaction amounts.



International Journal of Network Security, Vol.21, No.5, PP.741-750, Sept. 2019 (DOI: 10.6633/IJNS.201909 21(5).05) 743

2.2 Bilinear Pairings

Let G1,GT be two cyclic groups of prime order p1. A
bilinear map is a map e : G1×G1 → GT with the following
properties:

1) Bilinearity. For all u, v ∈ G1 and a, b ∈ Zp1 , then
e(ua, vb) = e(u, v)ab.

2) Non-degeneration. There exist u, v ∈ G1,
e(u, v) 6= 1.

3) Computability. There is an algorithm to compute
e(u, v) for all u, v ∈ G1.

2.3 Complexity Assumptions

The security of our new aggregate signature will be re-
duced to the hardness of an extended Computational Bi-
linear Diffie-Hellman (eCBDH) [27]. We review the defi-
nition of the eCBDH problem briefly.

Definition 1. Given G,H,Gx, Hx, Hy ∈ G1 for un-
known x, y ∈ Z∗p1 , the eCBDH problem in G1 is to com-
pute Gxy.

Definition 2. We say that the (Îľ, t)-eCBDH assumption
holds in a group G1 if no algorithm running in time at
most t can solve the eCBDH problem in G1 with probabil-
ity at least Îľ.

3 Transaction Privacy with Pail-
lier Cryptosystem

It is important for users to maintain their transaction pri-
vacy in bitcoin the system. Wang et al. [24] hide transac-
tion amounts by using Paillier cryptosystem to preserve
transaction privacy, where there is a sender who initiates
many payments to multiple receivers. In this paper, we
will consider the opposite situation that k senders sepa-
rately send one payment to a receiver. To protect trans-
action privacy, we will modify Wang et al.’s scheme [24] to
encrypt transaction amounts. The original amounts are
replaced with the ciphertexts decrypted by only the re-
ceiver that owns the private key. Figure 1 shows the above
process about transaction privacy with Paillier, where the
definitions of letter symbols and parameters can be ex-
plained in Section 3.1.

3.1 Transaction Privacy Scheme with
Paillier

KeyGen. For the specific receiver, select two large
primes p, q, compute n = pq, λ = lcm (p− 1, q − 1),
and set g ∈ Z∗n2 . The public key is pk = (n, g) and
the secret key is sk = Îť. Furthermore, generate pub-
lic parameters (gÎą, hÎą) used in Verify phase and set
nα = n2, where gα ∈ Z∗nα and hα is an element of
the group generated by gÎą.

Verify

i

i

H c

E E

H E

=

=

=

Õ
Õ

1
1 modrmE g h na

a a a=

2 2

2 mod
m nc g r n=

1 2

1 mod
m nc g r n=

2
2 modrmE g h na

a a a=

2modkm n

kc g r n=

modkm r
kE g h na

a a a=

1u

2u

ku

1m ¢

km ¢

2m ¢

return 1 ( )

receiver :

,sk pk

next transaction

next transaction

next transaction

Figure 1: Transaction privacy with paillier cryptosystem

Encrypt. In our scheme, k senders initiate one payment
separately to a receiver. To protect transaction pri-
vacy, Paillier cryptosystem is used to hide the trans-
action amounts mi into ciphertexts ci under the re-
ceiver’s public key pk = (n, g). Each sender ui selects
r = hÎą and encrypts amounts as follows:

ci = Encpk(mi) = gmirn mod n2

Meanwhile, each sender ui makes a commitment
Ei = gmiι hrιι mod nι for mi, where rι = n.

Verify. In the Encrypt phase, the senders initiate bit-
coins to the specific receiver under pk. Now the
system will check the correctness of the transaction
amounts in process as follows: whether the output-

sum
k∑
i=1

m′i inside the cooperated cipher
k∏
i=1

ci is equal

to input-sum
k∑
i=1

mi inside the cooperated commit-

ment
k∏
i=1

Ei. The transaction will not be sent to the

receiver unless the verification process are valid. The
concrete details are divided into two steps:

Step 1. The system computes the cooperated ci-
phertexts and the cooperated commitments:

H =
∏

ci = g
∑
m′irn mod n2

E =
∏

Ei = g
∑
mi

ι hrιι mod nι

Step 2. From KeyGen and Encrypt, there are
nÎą = n2, r = hÎą, rÎą = n. The system checks
whether H is equal to E. If yes, this shows that

input-sum
k∑
i=1

mi is equal to output-sum
k∑
i=1

m′i,

then the system returns 1 for the next process.

Decrypt. As described in the previous process, the trans-
action will be sent to the specific receiver if the sys-
tem returns 1. The receiver uses sk = Îť to decrypt
ci (i = 1, ¡ ¡ ¡ , k):

m′i = Dec (ci) =
L(ci

Îť mod n2)

L(gÎť mod n2)
mod n.



International Journal of Network Security, Vol.21, No.5, PP.741-750, Sept. 2019 (DOI: 10.6633/IJNS.201909 21(5).05) 744

A transaction is finished when the receiver assures
the amounts are correct after decryption.

Broadcast. Finally, the transaction will be broadcast to
P2P network.

3.2 Correctness of Decryption

To show the correctness of decryption, a few definitions
and conclusions will be given firstly as follows [18]:

Definition 3. For RSA modulus n = pq where p and q
are large primes, g ∈ Z∗n2 , and εg is defined as:

(x, y)→ gx · yn mod n2

where x ∈ Zn, y ∈ Z∗n and c = gxyn mod n2 ∈ Z∗n2 .

Definition 4. For εg and c ∈ Z∗n2 , the unique integer x ∈
Zn is regarded as n-th residuosity class of w with respect
to g for which there exists y ∈ Z∗n such that εg (x, y) = c.
The class of w is denoted by [[w]]g.

Lemma 1. For any ci ∈ Z∗n2 , L
(
cÎťi mod n2

)
= Îť[[ci]]1+n.

Next, we will give a brief correctness analysis of Pail-
lier cryptosystem: Since [[g]]1+n = [[1 + n]]

−1
g is revertible,

which results in that L(gÎť mod n2) is revertible modulo
n. Therefore, for any g ∈ G and ci ∈ Z∗n2 , i = 1, · · · , k,
compute

L
(
cÎťi mod n2

)
L (gÎť mod n2)

=
Îť[[ci]]1+n
Îť[[g]]1+n

=
[[ci]]g[[g]]1+n

[[g]]1+n
= mi

the receiver decrypts ci correctly to acquire the original
amounts mi.

3.3 Security Analysis

Our scheme can resist two major types of attacks: active
attack and passive attack [24].

Active attack. Since each transaction in the bitcoin sys-
tem is broadcast eventually to the P2P network
and the attacker may destroy system deliberately
(tampering attack) or forge transactions maliciously
(Overlay attack) in different types. Our scheme in
Section 3.1 can resist the active attacks as described
above. We state security analysis:

Tampering attack. Our scheme uses the Paillier cryp-
tosystem to encrypt transaction amounts, and only
the receiver with private key can obtain the legal bit-
coin. The receiver will not decrypt if the attacker
tampers ciphertexts, which makes the transaction be
discarded. Then our scheme can resist the informa-
tion tampering attack.

Overlay attack. Overlay attack means that the at-
tacker adds a forgery encrypted amount cf to the
original encrypted amount under the receiver’s pk.
The input-sum and the output-sum will be unequal
if the attacker adds another amount to the transac-
tion, which results in that the verification process will
fail. Then our scheme can resist overlay attack.

Passive attack. The passive attacks usually contain in-
formation monitoring and traffic analysis. The at-
tackers intend to extract secret information from
the traders by monitoring communications between
senders and a receiver or analyzing the traffic data of
their transactions through internet, then the system
may be unsecure due to some sensitive information
in public. The Paillier cryptosystem is used to en-
crypt and protect the apparent amounts shown on
the scripts, and what we can see is an unrecognized
string which can only be readable to the receiver with
private key. Then our scheme can resist passive at-
tacks.

4 Aggregate Interactive Signature

Zhu et al. [27] addressed the problem of instant confir-
mation with incontestability in blockchain by adopting
interactive signature. Aggregate signature technique pro-
posed by Boneh et al. [3] can improve efficiency of signa-
ture verification. Next, we will combine interactive incon-
testable signature with aggregate signature technique to
form a new aggregate signature scheme. The detail will
be showed as follows.

4.1 The Proposed Signature Scheme

Setup. This algorithm firstly generates the bilinear
groups G1,GT of prime order p1. Let g1 be the
generator of G1. This algorithm chooses a random
element h ∈ G1 and outputs a master public key
mpk = (g1, h). Meanwhile, there is a hash function
H : {0, 1}∗ → G1.

KeyGen. Each sender ui (i = 1, ¡ ¡ ¡ , k) runs this algo-
rithm to generate private key ski = xi∈RZ∗p1 and
public key pki = hxi . The specific receiver runs this
algorithm to generate private key sk′ = d∈RZ∗p1 and

public key pk′ = gd1 .

Sign. Each block contains multiple transactions in
the bitcoin blockchain, and each transaction in-
cludes multiple inputs and outputs. Each sender
ui (i = 1, ¡ ¡ ¡ , k) and the specific receiver interact
separately as follows to generate a signature:

Step 1. The receiver selects a∈RZ∗p1 , calculates
Mi = H(Ti)

a ∈ G1 of transaction Ti, and trans-
mits Mi to the corresponding sender, where
transaction amounts in Ti are apparent. Mean-
while, the receiver outputs a witness W =
(wit1, wit2), where wit1 = ga1 , wit2 = (ha)sk

′
=

(ha)d;

Step 2. Each sender picks a number ri∈RZ∗p1 , com-
putes

σ′i =
(
g
xiH(IDi)
1 ¡Mi

)ri
and returns σ′i to the receiver, where IDi is the
identifier of transaction Ti;



International Journal of Network Security, Vol.21, No.5, PP.741-750, Sept. 2019 (DOI: 10.6633/IJNS.201909 21(5).05) 745

Step 3. The receiver calculates

σ′′i = (σ′i)
d

=
(
g
xiH(IDi)
1 ¡Mi

)rid
with his private key sk′ = d and delivers σ′′i to
the corresponding sender;

Step 4. Finally, each sender computes

σi = (σ′′i )
r−1
i =

(
g
xiH(IDi)
1 ¡Mi

)d
separately of Ti.

Aggregate. The signature σi of Ti is published in a block.
The system selects the master node to calculate an

aggregate signature σ =
k∏
i=1

σi.

Verify. The aggregate signature σ are given. In order to
verify the aggregate signature σ, the verifier checks

e (σ, h) =

k∏
i=1

e
(

(pk′)
H(IDi), pki

)
¡ e (H(Ti), wit2)

then accepts σ if the above equation holds.

4.2 Correctness of Aggregate Signature

The correctness of an aggregate signature σ is proved as
follows:

k∏
i=1

e
(

(pk′)
H(ID1), pki

)
¡ e (H (Ti) , wit2)

=
k∏
i=1

e
((
gd1
)H(IDi)

, hxi
)
¡ e
(
H (Ti) , h

ad
)

=
k∏
i=1

e

((
g
xiH(IDi)
1 ¡Mi

)d
, h

)
= e

(
k∏
i=1

σi, h

)

4.3 Existential Unforgeability

Boneh et al. [3] set up the security model about aggregate
signature at the first time. Aggregate signature means
that k users separately signs k distinct messages, then k
signatures are aggregated into a single signature. This
single signature will convince the verifier that k users did
indeed sign k messages. Therefore, the security model
about aggregate signature of Boneh et al. [3] is applied to
our aggregate interactive signature.

In our scheme, the adversary A’s advantage,
AdvAggSigA, is defined to be the probability of success
in the following game [3]:

Setup. The adversary A is provided with a public key
pk1 generated at random.

Queries. Proceeding adaptively, A requests signatures
with pk1 on the messages of his choices.

Response. Finally, A outputs k − 1 additional public
keys pk2, pk3, ¡ ¡ ¡ , pkk, here, k is at most N , a game
parameter. These keys, along with the initial key pk1,
will be included in A’s forged aggregate. A outputs
transaction messages T1, T2, ¡ ¡ ¡Tk and an aggregate
signature σ by k users.

The adversary A wins if the aggregate signature
σ is a valid on messages T1, T2, ¡ ¡ ¡Tk under keys
pk2, pk3, ¡ ¡ ¡ , pkk, and σ is nontrivial, i.e., A did not re-
quest a signature on T1 under pk1.

Definition 5. An aggregate forger A (t, Îľ, qh, qs)-breaks
an N -user aggregate signature scheme in the aggregate
chosen-key model if: A has advantage at least Îľ in the
above game, runs in time at most t, and makes at most qh
queries to hash function, qs queries to signing oracle. An
aggregate signature scheme is (t, Îľ, qh, qs)-secure against
existential forgery in the aggregate chosen-key model if
no forger (t, Îľ, qh, qs)-breaks it.

4.4 Security Proof

Theorem 1. Our aggregate signature scheme is
(t, Îľ, qh, qs)-secure against existential forgery in the aggre-
gate chosen-key model, if no algorithm running in time at
most t′ can solve the eCBDH problem in G1 with proba-
bility at least ε′, where

t+ cG1
(qh + 2qs +N + 5) +N + 1 ≤ t′

ε′ =

(
1− 1

qs +N

)qs+N−1
¡ 1

qs +N
¡ ξ

Proof. Suppose there exists a PPT adversary A that out-
puts a forged aggregate signature for new aggregate sig-
nature scheme with a non-negligible advantage Îľ. We can
use the algorithm A to construct a PPT algorithm C that
can break the eCBDH problem.

Setup. The algorithm C is given G,H,Gx, Hx, Hy ∈
G1, where x, y ∈ Z∗p1 , and his goal is to calculate
Gxy ∈ G1. C runs the aggregate interactive signa-
ture scheme to generate mpk = (G,H) = (g1, h) and
starts as follows:

Algorithm C maintains a list of seven tuples
(Ti, pki, pk

′,W, λi, c, a). We refer to this list as the K-
list, and the list is initially empty. When A performs
the queries of the transaction Ti under the public
keys, algorithm C responds as follows:

Step 1. If the query Ti already appears on the K-
list in some tuple (Ti, pki, pk

′,W, λi, c, a), then
algorithm C responds with pki, pk

′,W .

Step 2. Otherwise, C generates a random coin c ∈
{0, 1} so that Pr[c = 0] = 1/(qs +N).

Step 3. Algorithm C picks λi, a ∈ Z∗p1 . If c = 0
holds, assuming that ski = yÎťi, sk

′ = x/λi, C
computes

pki = (Hy)
λi , pk′ = Gx/λi



International Journal of Network Security, Vol.21, No.5, PP.741-750, Sept. 2019 (DOI: 10.6633/IJNS.201909 21(5).05) 746

wit1 = Ga = ga1 , wit2 = (Hx)
a

= had

W = (wit1, wit2)

If c = 1 holds, assuming that ski = αi ∈ Z∗p1 , C
computes pki = H = Ga = gαi1 , pk′ = Gx/λi .

Step 4. Algorithm C adds the tuple (Ti, pki, pk
′,W,

Îťi, c, a) to the K-list and responds to A as
pki, pk

′,W .

Note that, either way, pki, pk
′,W are uniform in G1

and are independent of A’s current view as required.

Hash queries. Algorithm A can query the random ora-
cle H to qh times. When A queries H (Ti) of Ti, al-
gorithm C responds as H (Ti) = Gh(Ti), where there
is a map: {0, 1}∗ → Z∗p1 and h (Ti) ∈ Z∗p1 .

Signature queries. Algorithm A requests a signature
on some transaction message Ti under the challenge
key pk1. Algorithm C responds to the query as fol-
lows:

1) Algorithm C runs the above algorithm to re-
spond the hash queries on Ti, obtaining the
corresponding tuple (Ti, pki, pk

′,W, λi, c, a). If
c = 0, then C reports failure and terminates.

2) Otherwise, algorithm C computes

σi = GxH(IDi)+h(Ti)xa

and returns σi to A.

Output. Finally, A halts. It either concedes failure, in
which case so does A, or it returns a value k (k ≤ N),
k−1 public keys pk2, pk3, · · · , pkk, k transaction mes-
sages T1, ¡ ¡ ¡ , Tk, and a forged aggregate signature σ.
A must not have requested a signature on T1. Algo-
rithm C runs the above algorithms at each Ti and ob-
tains k corresponding tuples (Ti, pki, pk

′,W, λi, c, a),
where i = 1, 2, ¡ ¡ ¡ , k.

Algorithm C now proceeds only if c = 0 when i = 1 ,
and, for 2 ≤ i ≤ k, c = 1; otherwise C declares failure
and halts. The aggregate signature σ must satisfy
the follow equation:

e (σ, h) =

k∏
i=1

e
(

(pk′)
H(IDi), pki

)
¡ e (H(Ti), wit2) .

For each i > 1, C sets σi = GxH(ID)i+h(Ti)xa, then

e (σi, h)
= e

(
GxH(IDi)+h(Ti)xa, h

)
= e

(
GxH(IDi), h

)
¡ e
(
Gh(Ti), hax

)
= e

(
(pk′)

H(IDi), h
)
¡ e
(
Gh(Ti), wit2

)

So σi is a valid signature on Ti. Now C constructs a

value σ1 : σ1 ← σ ·
(

k∏
i=2

σi

)−1
. Then

e (σ1, h)

= e (σ, h) ¡
k∏
i=2

e(σi, h)
−1

= e
(

(pk′)
H(ID1), pk1

)
¡ e (H (T1) , wit2)

If the above equation holds, σ1 is a valid signature
on T1. Then C can calculate and output his target
value

Gxy =
(
σ1

/
(Gx)

ah(T1)
)1/H(ID1)

The above steps complete the description of algorithm
C. It remains to show that C solves the eCBDH problem
in G1 with probability at least ε′. To do so, we analyze
the three events needed for C to succeed:

E1: C does not abort as a result of any of C’s signature
queries.

E2: A generates a valid, nontrivial aggregate signature
forgery (k, pk1, ¡ ¡ ¡ , pkk, T1, ¡ ¡ ¡ , Tk).

E3: Event E2 occurs, and, in addition, c = 0 when i = 1,
and, for 2 ≤ i ≤ k.

C succeeds if all these events happen. The probability
Pr [E1 ∧ E3] decomposes as

Pr [E1 ∧ E3] = Pr [E1] ¡ Pr [E2|E1] ¡ Pr [E3|E1 ∧ E2]

The following claims give a lower bound for each of
these terms.

Claim 1. The probability that algorithm C does not
abort as a result of A’s aggregate signature queries
are at least (1− 1/(qs +N))

qs . Hence,

Pr [E1] ≥ (1− 1/(qs +N))
qs

Claim 2. If algorithm C does not abort as results of A’s
queries, then algorithm A’s view is identical to its
view in the real attack. Hence,

Pr [E2|E1] ≥ ε

Claim 3. The probability that algorithm C does not
abort after A outputs a valid and nontrivial forgery
is at least (1− 1/qs +N)

N−1 · 1/(qs +N). Hence,

Pr [E3|E1 ∧ E2] ≥ (1− 1/qs +N)
N−1 · 1/qs +N

Algorithm C produces the correct answer with probability
at least

ε′ =

(
1− 1

qs +N

)qs+N−1
¡ 1

qs +N
¡ ξ



International Journal of Network Security, Vol.21, No.5, PP.741-750, Sept. 2019 (DOI: 10.6633/IJNS.201909 21(5).05) 747

( )
1

1 1 1

2

1

: ,

mod
m n

u sk pk

c g r n=

( )
2

2 2 2

2

2

: ,

mod
m n

u sk pk

c g r n=

( )
2

: ,

modk

k k k

m n

k

u sk pk

c g r n=

1

k

i

i

s s
=

=Õ ( )

( )

receiver:

,

,

sk pk

sk pk¢ ¢

next transaction

next transaction

next transaction

1
m¢

2
m¢

km¢

( )( )1 1

1 1 1

d
x H ID
g Ms × ¢= ×

( )( )2 2

2 2 2

d
x H ID
g Ms × ¢= ×

( )( )k k

d
x H ID

k k kg Ms
× ¢= ×

Figure 2: Transaction privacy with paillier cryptosystem

Algorithm C’s running time is the same as A’s running
time plus the time that is takes to respond to public-
key queries hash queries and signature queries, and the
time to transform A’s final forgery into the eCBDH so-
lution. Each hash query and signature query require
an exponentiation in G1. The output phase requires
at most N additional hash computations, three inver-
sions, two exponentiations, and N+1 multiplications. We
assume that exponentiation and inversion in G1 take
time cG1 . Hence, the total running time is at most
t+ cG1 (qH + 2qS +N + 5) +N + 1 ≤ t′ as required. The
above process complete the proof of Theorem 1.

5 New Protocol with Privacy Pre-
serving and Fast Verification

5.1 The Proposed Protocol

A new protocol that can achieve privacy preservation and
fast verification is proposed in this Section. Transaction
privacy with Paillier in Section 3 and new aggregate sig-
nature in Section 4 are used to reach our goals. The
sender signs a payment after transaction amounts are en-
crypted and verified by the system. Here, there exist k
senders initiate k payments to a receiver. Figure 2 shows
the structure of our protocol, where (ski, pki) is the sig-
nature key pair of each sender, (sk, pk) and (sk′, pk′) are
separately the encryption key pair and the signature key
pair of the receiver.

The concrete process of signature is shown as follows.

KeyGen. The system generates the bilinear group
G1,GT and chooses a random number h ∈ G1. Let g1
be the generator of G1. Each sender ui (i = 1, ¡ ¡ ¡ , k)
runs this algorithm to generate private key ski =
xi∈RZ∗p1 and public key pki = hxi . The specific
receiver runs this algorithm to generate private key
sk′ = d∈RZ∗p1 and public key pk′ = gd1 .

Sign. Each block contains multiple transactions in the
bitcoin blockchain. Then each sender and receiver
interact separately as follows to generate a signature
for a payment. Here, we denote the transaction as
T ′i , where each transaction amount mi has been en-
crypted as ci by Paillier cryptosystem.

Step 1. The receiver calculates the M ′i = H(T ′i )
a

of transaction T ′i with a∈RZ∗p1 , and then trans-
mits M ′i to each sender. Meanwhile, the receiver
outputs a witness W = (wit1, wit2), where

wit1 = ga1 , wit2 = (ha)
sk′

= (ha)
d

Step 2. Each sender selects a number ri∈RZ∗p1 and
delivers

σ′i =
(
g
xiH(IDi)
1 ·M ′i

)ri
to the receiver, where IDi is the identifier of T ′i ;

Step 3. The receiver calculates

σ′′i = (σ′i)
d

=
(
g
xiH(IDi)
1 ·M ′i

)rid
and returns σ′′i to the corresponding sender;

Step 4. Finally, each sender computes

σi = (σ′′i )
r−1
i =

(
g
xiH(IDi)
1 ·M ′i

)d
of T ′i .

Aggregate. The system selects the master node to cal-

culate aggregate signature σ =
k∏
i=1

σi.

Verify. An aggregate signature σ ∈ G1 is given. In order
to verify the signature σ, the verifier computes

e (σ, h) =

k∏
i=1

e
(

(pk′)
H(IDi), pki

)
· e (H(T ′i ), wit2)

then accepts σ if this equation holds. The transaction
will be sent to the receiver if the above steps are
performed correctly, where the transfer form of input
is ci = gmirn mod n2.

Decrypt. When the receiver gets ciphertexts, he can use
private key sk′ to decrypt:

mi = Dec (ci) =
L(ci

Îť mod n2)

L(gÎť mod n2)
mod n

A transaction is finished when the receiver assures
the amounts are correct after decryption.

Broadcast. Finally, the transaction will be broadcast to
P2P network.



International Journal of Network Security, Vol.21, No.5, PP.741-750, Sept. 2019 (DOI: 10.6633/IJNS.201909 21(5).05) 748

5.2 Security Analysis

In Sections 3 and 4, the security of transaction privacy
and aggregate signature have been revealed separately.
Then security analysis about our protocol are showed as
follows:

1) In the process of encrypting transaction amounts, our
scheme can resist active attack (such as tampering
attack and overlay attack) and passive attack (such
as information monitoring) due to the use of Paillier
cryptosystem. The details refer to Section 3.3.

2) In the process of signature, the new aggregate sig-
nature is proved to be unforgeable under eCBDH
assumption, which ensures that the attacker cannot
tamper with the aggregate signature and then any
single signature of all senders is unforgeable. The
details refer to Section 4.3.

Table 1: Functionality comparisons

Transaction
privacy

Fast
verification

Compatible
with bitcoin

[24]
√

×
√

[26]
√ √

×
[27] × ×

√

Ours
√ √ √

Table 2: Complexity Analysis of transaction privacy

Algorithm Computation Costs
KeyGen 2τm
Encrypt kτM + (k + 1) τE
Verify (2k − 2) τm + kτM + (k + 1) τE

Decrypt (k + 1) τm + (k + 1) τE

5.3 Functionality Comparisons

Features comparisons between our protocol and some re-
cent schemes are listed in Table 1. As can be seen from
the comparisons with some related works, our protocol
can achieve more functionality, where

√
means that the

corresponding scheme achieves this functionality, and ×
means that the corresp";"""date"",""2019-08-13T15:46:13Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""2"",""45"",""11"",""47"",""35"",""87"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.5""
""xmp:CreatorTool"",""TeX""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dcterms:created"",""2019-08-13T15:46:13Z""
""language"",""en""
""Last-Modified"",""2019-08-13T15:46:13Z""
""dcterms:modified"",""2019-08-13T15:46:13Z""
""dc:format"",""application/pdf; version=1.5""
""Last-Save-Date"",""2019-08-13T15:46:13Z""
""pdf:docinfo:creator_tool"",""TeX""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2019-08-13T15:46:13Z""
""meta:save-date"",""2019-08-13T15:46:13Z""
""pdf:encrypted"",""false""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is MiKTeX-pdfTeX 2.9.6668 (1.40.19)""
""modified"",""2019-08-13T15:46:13Z""
""Content-Length"",""540039""
""pdf:hasMarkedContent"",""false""
""Content-Type"",""application/pdf""
""PTEX.Fullbanner"",""This is MiKTeX-pdfTeX 2.9.6668 (1.40.19)""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""trapped"",""False""
""meta:creation-date"",""2019-08-13T15:46:13Z""
""created"",""2019-08-13T15:46:13Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""10""
""Creation-Date"",""2019-08-13T15:46:13Z""
""resourceName"",""ijns-2019-v21-n5-p741-750.pdf""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""3964"",""4194"",""3274"",""3911"",""3329"",""2798"",""3113"",""3226"",""3383"",""2662""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""producer"",""MiKTeX pdfTeX-1.40.19""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""MiKTeX pdfTeX-1.40.19""
""pdf:docinfo:created"",""2019-08-13T15:46:13Z""
";https://scholar.google.com/scholar?start=820&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094579-819;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Break-glass encryption;A Scafuro ; IACR International Workshop on Public Key …, 2019  Springer;;"… We abstract the properties of such verifiable permission mechanism in an ideal functionality

\(\mathcal {G}_{\mathsf{perm}}\) (see Fig. 2) and we discuss possible implementations using a

blockchain or an email provider (see Sect … On the Need of State, Obfuscation, Blockchain …";Cité 4 fois;Les 2 versions;[PDF] nsf.gov;https://par.nsf.gov/servlets/purl/10098718;"
Break-glass Encryption

Alessandra Scafuro(B)

NCSU, Raleigh, USA
ascafur@ncsu.edu

Abstract. “Break-glass” is a term used in IT healthcare systems to
denote an emergency access to private information without having the
credentials to do so.

In this paper we introduce the concept of break-glass encryption for
cloud storage, where the security of the ciphertexts – stored on a cloud
– can be violated exactly once, for emergency circumstances, in a way
that is detectable and without relying on a trusted party.

Detectability is the crucial property here: if a cloud breaks glass with-
out permission from the legitimate user, the latter should detect it and
have a proof of such violation. However, if the break-glass procedure is
invoked by the legitimate user, then semantic security must still hold
and the cloud will learn nothing. Distinguishing that a break-glass is
requested by the legitimate party is also challenging in absence of secrets.

In this paper, we provide a formalization of break-glass encryption and
a secure instantiation using hardware tokens. Our construction aims to
be a feasibility result and is admittedly impractical. Whether hardware
tokens are necessary to achieve this security notion and whether more
practical solutions can be devised are interesting open questions.

1 Introduction

The purpose of an encryption scheme [GM84] is to protect data against any
observer that is not the intended recipient of the data. Encryption has been
historically used to protect messages in transmission over untrusted channels.
Recently however, encryption is progressively being used in the context of cloud
storage to protect the confidentiality of the data uploaded by the users to the
cloud. In a cloud storage setting, the cloud is trusted to guarantee availability
of the uploaded data at any time, but it is not necessarily trusted (or held
accountable) for not leaking clients’ data to third parties. Thus, the cloud can
be seen as an untrusted but reliable channel that the client uses to communicate
data to herself in the future.

The Need to Break. But what happens if the user loses the key? Or more gener-
ally, what if the user loses the ability to access to the secret key (e.g. because she
lost her laptop, or simply because she is not alive anymore) but there is a need

A. Scafuro—Supported by NSF grant #1012798.

cŠ International Association for Cryptologic Research 2019
D. Lin and K. Sako (Eds.): PKC 2019, LNCS 11443, pp. 34–62, 2019.
https://doi.org/10.1007/978-3-030-17259-6_2

http://crossmark.crossref.org/dialog/?doi=10.1007/978-3-030-17259-6_2&domain=pdf
https://doi.org/10.1007/978-3-030-17259-6_2


Break-glass Encryption 35

to retrieve the documents that she uploaded to the cloud? For this emergency
condition, one would like to have a way to break the encryption without knowing
any cryptographic secret associated to the user.

Break-glass Encryption. We introduce the concept of break-glass1 encryption.
This is an encryption scheme that guarantees semantic security – just like any
traditional encryption scheme – but it additionally provides a new command
called Break that allows one designated party (the cloud) to help an alleged
user to break her ciphertexts. Each ciphertext can be broken at most one time
in a way that is detectable. Detectability is the crucial property. If the cloud
breaks the ciphertexts without having received any request from the user, then
the user should be able to detect and publicly prove this violation. A bit more
specifically, we consider a setting where a user uploads and updates a (potentially
large) number of ciphertexts and we want two properties: (1) a legitimate break-
glass procedure preserves semantic security, that is, an honest user should be
able to use the cloud to break her ciphertexts in such a way that the cloud
does not learn anything about the plaintexts; (2) an illegitimate break-glass
procedure is detectable, that is, if the cloud breaks user’s ciphertexts without
any permission, this violation is detectable and can be proven to a third party. In
other words, a legitimate break-glass procedure preserves the semantic security
of the ciphertext, while an illegitimate break-glass procedure leaks data but
provides a proof of the violation.

What Constitutes a Legitimate Break-glass Request? A peculiar aspect of a
break-glass encryption is that the break-glass procedure should be requested
without knowing any secret. This is indeed crucial since a user wants to break-
glass exactly because he does not remember his secrets.

However, if no secret are required to request to break-glass, how do we dis-
tinguish a legitimate request – coming from the owner of the data – from an
illegitimate one – coming from anyone else? What makes a request illegitimate?

This is a challenge unique for our setting. For any break-glass encryption,
one has to first design a permission mechanism for creating legitimate permis-
sions without any secret and identifying and/or denying illegitimate requests. To
devise such a permission mechanism we leverage the following observation. If a
user did not request a break-glass procedure, this means that she probably still
possesses her secrets, and therefore she can use them to delegitimize the request.

More concretely, the high-level idea behind the permission mechanism is the
following. Any user U has associated a (public) alert address (e.g., an email
address, a Bitcoin account), which we call alert-info. When the cloud receives a
break-glass request from a party on behalf of user U , will first send an “alert”
to user U , by forwarding the break-glass request to the address alert-info. The

1 The name break-glass encryption is inspired by the break-glass procedures used in
access control of various systems (healthcare, computer systems, etc.). In a break-
glass procedure the system administrator breaks into the account of a certain user
without the legitimate credentials in order to retrieve his data.



36 A. Scafuro

cloud will then wait a certain interval of time TWaitPermission, this time could
depend on the application and the permission mechanism. If the users knows
the secret associated to alert-info, then she will be able to stop or endorse the
permission by using her secrets. If not, the user will simply do nothing. After
waiting TWaitPermission steps, if no denying answer is received from U , the silence
is accepted as a proof that the user did indeed lose the key and a “silence”
permission that U wishes to break the glass. Crucially, it is important that a
cloud is not able to fabricate a “silence” permission; thus the silence response
must be publicly verifiable. This is necessary for protecting the user against a
malicious cloud that pretends that no answer was received; but also to protect
the cloud in case a malicious user remains silent but then later accuses the cloud
by fabricating a proof delegitimizing the request.

We abstract the properties of such verifiable permission mechanism in an
ideal functionality Gperm (see Fig. 2) and we discuss possible implementations
using a blockchain or an email provider (see Sect. 4.3).

Detectability: Why Simple Solutions Do Not Work. At first sight, the break-
glass property might seem trivial to achieve; after all we are adding a method to
reveal something and not to conceal. Unfortunately, this is not the case, and the
main reason is that for each breaking attempt we need to ensure detectability.
To show this, we now discuss some trivial solutions that do not work.

A straightforward solution could be to upload the ciphertexts in one cloud,
and give the secret key to another party, e.g., a friend, another cloud, a group
of colleagues, etc. This approach fails in achieving detectability: if the cloud
colludes with the party holding the key then ciphertexts can be decrypted at
any time and without leaving any trace. Similarly, the approach of selecting a
group of people that collectively holds the secret key suffers of the same problem:
if the group comes together and decides to decrypt, there is no way for the user
to ever notice. Furthermore, in this type of approach, it does not seem possible
to guarantee semantic security in presence of legitimate break-glass procedure.

Another relatively straightforward approach is to use a one-time hardware
token. Namely, the user prepares a token which has the secret key hardwired,
and when queried, it will output the key and then stop responding. The user
will then send to the cloud two things: the ciphertexts and the token, with the
understanding that the token should be used only in case of emergency. To break
the glass, the cloud simply queries the token and get the key. The user could
detect if the break-glass procedure has been illegitimately performed by peri-
odically pinging her token. This approach however does not achieve semantic
security in presence of legitimate break-glass procedure. Indeed, since the cloud
learns the key, will be able to decrypt everything even when following a legit-
imate request, and also trace the ciphertexts updates over time. Finally, this
solution does not allow for any granularity in case of illegitimate break-glass
procedure. Indeed, since the key is revealed, all ciphertexts are automatically
broken. Instead, we would like a more fine-grained mechanism that tells the user
exactly which ciphertexts have been compromised, or that it allows the user to



Break-glass Encryption 37

setup a leaking threshold (e.g., not more then 50% of the data should be ever
decrypted).

When to Use Break-glass Encryption? Break-glass security is reminiscent of
covert security [AL07], and it is meaningful in scenarios where the loss of rep-
utation is a strong deterrence against cheating. In particular, our definition is
stronger than covert security in that we explicitly require that, for any illegit-
imate breaking attempt, the client will get a proof that can be used to pub-
licly accuse the cloud. Thus, we target the scenario of cloud storage, where the
cloud is a functional and mostly credible company (e.g., Dropbox, iCloud Apple,
Google drive). In this scenario the stake for reputation is very high, therefore
it is very reasonable to assume that the benefit from breaking the security of a
single client, are less appealing than losing the reputation and thus all the other
clients. Clearly, break-glass encryption is not suitable for scenarios where the
cloud storage is an unknown server, that has not accountability or credibility. In
this case indeed, there is no reputation to maintain, thus not deterrence against
cheating.

What Break-glass Encryption is Not. Break-glass encryption is different from a
“trapdoored” encryption scheme, where one can put a trapdoor that allows a
designed party (who knows the trapdoor) to decrypt. The crucial difference is
that a trapdoor allows to decrypt undetectably, while we want to make sure that
each break is detectable and it can be performed at most one-time.

1.1 Our Contribution and Our Techniques

In this paper we provide two main contributions:

– Definition of break-glass encryption. We introduce the new concept of
break-glass encryption. This is an encryption scheme for the cloud stor-
age setting, that allows a honest user to break her own ciphertexts when
necessary, while preserving semantic security. We formally define break-glass
encryption via an ideal functionality Fbreak. In this context, we also introduce
a new ideal functionality, Gperm, for generating verifiable permissions for a
user U .

– Construction of a break-glass encryption. As a feasibility result, we
show that break-glass encryption can be constructed using (stateful) hardware
token [Kat07] in the (Gperm,Gclock)-hybrid model, where Gclock is the global
clock functionality. We also suggest implementations of Gperm using blockchain
or email systems.

In the remaining part of this section we provide more details about the tech-
nical aspects of each contribution.

Definition of Break-glass Encryption. We consider a setting where there
is a cloud C and a user U , and the cloud is used for memory outsourcing. The



38 A. Scafuro

user can perform the following actions (1) upload/download ciphertexts; (2)
update a ciphertext; (3) break-glass of one (or many) ciphertexts. Our ideal
functionality Fbreak should satisfy the following properties. If the cloud honestly
performs a legitimate break-glass procedure on behalf of a user, then semantic
security should still hold, namely, the cloud does not learn anything about the
decryption. If the cloud performs an illegitimate break-glass command, then this
action must be detectable by the user the very next time the user attempts to
read any ciphertext, and the violation should be publicly verifiable.

Defining Permission Without Secret: Gperm Functionality. We introduce the Gperm

functionality. This a functionality used by cloud C and user U to obtain and ver-
ify valid permissions from U . In Gperm each user Ui is associated to a public
information alert-infoi. We stress that this information is public and a user can
retrieve it even if she loses all her secrets. This functionality provides the fol-
lowing interface: Register, Create Permission, and Verify Permission. Register
is used by U to register the public information alert-info. Create Permission is
used by the cloud to obtain a permission πperm, which is either a publicly verifi-
able endorsement of the request or a publicly verifiable silence proof from Gperm.
This step uses timing information and invoke ideal functionality Gclock. This is
the global clock functionality, previously used in [BMTZ17] in the context of
defining the public ledger functionality and analysing the security of the bit-
coin protocol. VerifyPermission is used by any party who wishes to check that
(alert-info, πperm) is a valid permission granted by U . We discuss realization of
Gperm based on blockchain or email in Sect. 4.3.

Defining Break-glass: Fbreak Functionality. We capture the security properties
of detectability, accountability and semantic security in presence of legitimate
break-glass procedure in an ideal functionality Fbreak (Fig. 1). Fbreak interacts
with two parties, a cloud C and a user U . Fbreak takes in input messages
m1, . . . , ml from U , who can then update and retrieve her messages many times
(by invoking commands Update/Retrieve). Fbreak provides a Break command
that can be invoked by C only. It takes in input an index i (denoting the cipher-
text that the party wishes to decrypt), a proof of permission (alert-info, πperm) or
a proof of cheating (πcheat). Fbreak verifies the permission (alert-info, πperm) using
Gperm, and then proceeds by sending mi to the user U only. If the request is
illegitimate, Fbreak checks that πcheat is a proof of cheating. If the check passes,
Fbreak sends mi to the cloud, and records the cheating attempt.

For every operation requested by the user, Fbreak proceeds only after receiving
an ack from C. This captures the real world fact that a cloud can always refuse to
answer (note that this is true in any cloud system). In such case, our functionality
give no explicit guarantees, since the user will just receive the message (refuse,⊥).
In practice however, refusing the answer is a proof of misbehaviour and can be
turned into a legal proof via court.

Construction. Our construction relies on hardware tokens. The token is the
point of trust of the user. It is initialized with the secret key k used to encrypt the



Break-glass Encryption 39

data, a signing key sskT , and the verification key of the cloud vpkC . The token is
sent to the cloud C at the very beginning, and it stays with the cloud throughout
the execution. We consider the case where the user can encrypt arbitrarily long
files, but the size of the token is constant, that is, it must be independent on the
number of blocks encrypted. This size constraint rules out any solution where
we just keep all the ciphertexts inside the token or have the token record all the
ciphertexts for which the cloud invoked the Break command.

The token performs a computation only when the inputs are authenticated
wrt the cloud’s public key. Authenticated inputs serve two purposes: first, it pro-
vides a proof in case a cloud operated the token illegitimately; second, it protects
the cloud from false accusations about the operation of the token. Finally, the
outputs of the token is also authenticated, in order to avoid that the cloud sends
wrong information to the user.

Warm Up Solution Without Granularity. As warm up, we describe a solution
that does not provide any granularity. Namely, a user cannot detect which cipher-
texts have been violated and when. The first solution works as follows. The user
sends her ciphertexts C = (c1, . . . , cn), encrypted under a secret key k to the
cloud. Then she initializes a token T with the secret key k, the verification key of
the cloud vpkC and the signature key sskT used to authenticate T ’s outputs. The
token T performs a very simple functionality: on input a permission perm and a
fresh public key pk, it outputs the encryption of the secret key k and stops. Note
that the token only checks that the input perm, pk is correctly signed by C; but
does not check if the permission (if any) given in input is valid. This check will
be done later by the parties only in case of dispute. This solution is simple, but it
leaves little control on the illegitimate queries. Indeed, with one such query, the
cloud can immediately decrypt 100% of the ciphertexts. We would like a more
fine-grained approach that allows the user to identify precisely which ciphertexts
have been broken and potentially to setup a threshold on the total number of
ciphertexts that can be broken.

A Fine-Grained Solution: Breaking Ciphertexts Selectively. To break the cipher-
texts selectively, the token should not output the key. Instead, we need the token
to decrypt selectively. The idea is to give in input to the token also a ciphertext
ci, so that the token will answer with mi, i.e., the decryption of ci, rather than
the key. More precisely, the token will output an encryption of mi under the
public key pk, where pk is the public key chosen by the person who is requesting
to break ciphertext ci. Moreover, to make sure that ci is marked as broken, the
token will output a new version, c′

i = Enc(mi||broken||perm) that must replace
ci, where perm is the permission used to invoke the break procedure (perm might
be empty). Next time the user will download the i-th ciphertext, she will obtain
c′
i and if she still has the key k, she will detect that c′

i was illegitimately broken;
similarly, next time the cloud inputs c′

i to the token, the token will refuse to
decrypt.

This solution is too naive. A malicious cloud can simply ignore the new
marked ciphertext c′

i and send the old unbroken ci to the user. Namely, the



40 A. Scafuro

cloud can always replay old ciphertexts, defeating the checks of the token/user.
To overcome this problem, we propose a mechanism that makes valid ciphertext
evolve over time, or in other words, age. We do so by simply adding bookkeeping
information; namely, each encryption now will also contain a time ti when it was
last updated, the time T0 when the first break occurred (if any). This means that
by downloading any of the ciphertexts the user can determine if a break-glass has
happened. Each ciphertext ci needs to be refreshed every I timestamps (where
I is a parameter that can vary with application). Since updating ciphertexts
requires the use of the secret key, the cloud C will use the token to re-encrypt
each ciphertext upon each interval I. Updating a ciphertex simply means to re-
encrypt the message mi concatenated with the current time, and the time of the
first break-glass T0 (if any). Now, when a user downloads the i-th ciphertext ci,
and tries to decrypt it, she expects to obtain the most updated time (within a
window of I steps). If not, she will discard the ciphertext as stale, and consider
this as a cheating attempt from the cloud.

Therefore, in this fine grained approach, the token performs two operations
for the cloud: re-encryption and break. When the cloud inputs the command
‘re-encrypt’, then the token expects in input a ciphertext ci that needs to be
re-encrypted with the current time. The token will accept to re-encrypt only if
the time registered in ci are at most I steps behind the current time.

Finally, there is a subtle issue that requires a careful tradeoff between the
size of interval I and the size of the memory of the token. Consider the following
attack. The cloud queries the token to re-encrypt ci at time t obtaining ct

i.
The cloud then queries the token to break ct

i, at time t + 1 and obtains mi as
well as the new encryption ct+1

i which is marked as broken. Then, the cloud
completely discard ct+1

i and instead queries the token to re-encrypt ct
i at time

t + 2. If t + I < t + 2 then the token accepts to re-encrypt ct
i with the new

time t + 2, and output the new ciphertext ct+2
i which is not marked as broken

(however note that ct+2
i will still have the field T0 ďż˝= 0 signaling that a break-

glass took place). Thus, the cloud obtains a clean unmarked version of ci which
is updated to time t + 2, even if ci was broken at time t + 1 and the user will
not detect that this specific ciphertext was broken (however U will still know
that a ciphertext was broken). This problem arises because we allow a interval I
between re-encryptions and can be solved by simply remembering the indexes of
the ciphertexts broken within a window of I steps. The size of this list depends
on the size of I (and logn where n is the number of ciphertexts).

How to Get Rid of Clocks in the Token. In the outlined solution, the token uses a
clock to check the current time and identify stale ciphertexts. However, requiring
a clock (even only loosely synchronized) in the token is a strong assumption (the
token cannot simply connect to a public server to check the time). We remove this
assumption by having the cloud C provide the current time as input to the token.
Time is simply a monotonic function, and time is “correct” if it moves forward.
Thus, instead of requiring the token to keep its own clock, the token could receive
the time as input, store the last time it was queried, and accept a new “current”
time only if it goes in the forward direction. Checking whether the time provided



Break-glass Encryption 41

by C is actually good will be done by the user when downloading the ciphertext.
As long as the parties (i.e., the cloud and the user) agree on a common source
for reliable time, then there will be no dispute of the current time. We stress
that assuming that C and U agree on a common time is a natural assumption
made by most real world systems that we use in everyday life. The Network
Time Protocol (NTP) [MMBK,CHMV17] is one example of protocols used for
synchronization of the communications over the internet. There has been a lot of
work on attacks and defenses for the NTP protocols (see [MG16,MGV+17]), but
this problem is orthogonal to the one discussed in this paper. Moreover, we stress
that we only need C and U to be loosely synchronized, and the parameters of the
encryption (i.e., the interval I and TWaitPermission) can be tailored accordingly.

On the Need of State, Obfuscation, Blockchain. We got rid of the clock for the
token, by just assuming that the world (the cloud and the user) has a global
clock. Can we get rid of the state too by assuming that the world share a
global immutable state? If that was possible, we could use a stateless token,
or even further, can we replace the token with Indistinguishability Obfusca-
tion [ABG+13,GGH+13,GGHW17,BCP14]. Very recently blockchain technol-
ogy provides the world with a common state that everyone seems to agree on,
without trusting any party. Thus, a possible approach could be for the token
to store its state as a transaction in the blockchain, and the cloud can query
the token on input the transaction. However, this seems to be challenging since
a token could not verify the validity of a transaction without having access to
the entire blockchain. Recent work [LKW15,Jag15,KMG17,GG17] show how to
construct one-time programs [GKR08] and time-lock encryption leveraging the
blockchain (but they are based on witness encryption [GKP+13]). We do not
rule out that an interesting solution can be developed using weaker cryptographic
assumptions, we leave it as future work to explore this direction.

Other Considerations. For simplicity we assume that the token sent by the user
runs the prescribed code (i.e., the user does not embed malicious code into the
token). This is only for simplicity of exposition, since standard techniques using
zero-knowledge proof could allow us to remove this requirement. We believe that
this is a reasonable relaxation, especially for the envisioned application of break-
glass encryption, and since this is the first attempt to achieve such security
notion. We do not consider side-channel attacks on the token.

On Surveillance and Rational Adversaries. One can argue that this scheme has
the undesired effect that it can be used by a government to break the privacy of
its citizens (by subpoena the cloud). This is certainly true, but recall that the
citizens would detect that their privacy is violated. Therefore, one can be in two
cases. Case 1, one lives in a country where the state cares about citizens not
being aware that they are monitored. In this case, the state would not use the
break functionality to break encryption, but something more subtle. Case 2, one
lives in a country where citizens are aware that they are watched. In this case,
even if the state imposes the citizens to use a break-glass encryption scheme,



42 A. Scafuro

then the citizens can still break-glass encrypt a ciphertext (rather than their
messages). In this way, even if a break is performed, the perpetrator will only
learn more encryptions.

On Refusing to Provide the Service. Just like any client-server system, the cloud
can always refuse to provide the service and ignore user’s requests. In this case
the user will not have a cryptographic proof of cheating as promised by the break-
glass encryption scheme, however, the user can obtain a court order obligating
the cloud to release ciphertexts and users’ token.

2 Open Problems

The main goal of this work was to introduce the concept of break-glass encryp-
tion, and show that in principle is achievable. The proposed solution however is
quite impractical and only provides a feasibility result. Several questions are left
open: Are (stateful) hardware token necessary to achieve this notion of security?
Can we devise a solution that achieves some granularity but it does not require
the cloud to continuously update the ciphertexts by querying the token? What
are other interesting implementations of Gperm and can Gperm have applications
in other setting besides break-glass encryption?

3 Related Work

Concurrently and independently from our work, recently the concept of “dis-
posable cryptography” has been introduced by Chung, Georgiou, Lai and Zikas
in [CGLZ18]. While sharing some similarity with our work, the aims and the
techniques are very different. The goal of this work is to provide an encryp-
tion scheme for cloud storage, that can be broken by anyone exactly once, in a
detectable way. The motivation for break-glass is the case when the legitimate
user wants to decrypt the data she uploaded to the cloud, but she lost all her
secret keys. The goal of [CGLZ18] is to realize trapdoored cryptographic schemes
that can be violated once, by a designated entity who possesses the trapdoor,
which is not the legitimate user and without being detected. The motivation for
dispensable backdoors is to allow law enforcement to break the scheme exactly
once, the envisioned application is breaking into mobile phones undetectably.
Somewhat related to the concept of break-glass cryptography is the idea of time-
locked encryption [BN00,BGJ+16,BM09,BM17,LPS17]. In time-locked encryp-
tion some information is meant to be protected for a certain period time T ,
thus when the time expires, the cloud will be able to decrypt the information
contained in the ciphertext. The difference between break-glass and time-locked
encryption is in the fact that our cloud can always break the encryption if she
wishes to do so, but at the price of being detected. Our adversarial model is
very close in spirit to the covert model [BM09]. In this model the adversary is
allowed to cheat and violate the privacy to the parties, but by doing so he will
be caught and thus lose reputation.



Break-glass Encryption 43

4 Definitions

4.1 Break the Glass Encryption Scheme

A break-glass encryption is a private-key encryption scheme designed for the
cloud storage setting. It provides a procedure called Break which allows a user
to decrypt her ciphertexts without knowing the secret key, exactly once. At
high-level a break-glass encryption scheme must satisfy the following properties:

– Completeness. If the cloud and the user follow the protocol then the user is
able to obtain the plaintexts that she encrypted originally, without knowing
the key.

– Confidentiality (Semantic-Security). If no Break is performed, then the cipher-
texts are semantically secure against any PPT malicious cloud.

– Break-glass Confidentiality. If break-glass is requested by a legitimate user,
the cloud does not learn anything about the broken ciphertexts.

– Break-glass Detectability. If break-glass is performed by the cloud without
user’s permission, the cloud can decrypt each ciphertext exactly once, and
each violation is detected by the user (unless the cloud refuses to respond).

– Break-glass Accountability. A user should be able to prove that the cloud
performed an illegitimate break-glass request.

We provide a simulation-based definition [Gol04,HL10] and capture the above
security requirements via an ideal functionality Fbreak (Fig. 1). To capture break-
glass accountability, Fbreak is designed so that it will proceed with an illegitimate
break requested by the cloud C, only if C provides a proof of cheating, that we
denote by cheat-proof. Fbreak invokes ideal functionalities Gperm and Gclock (which
are defined as global functionalities). This definitional approach was used in
previous work in the (stronger) GUC setting by Badertscher et al. [BMTZ17].
Finally, Fbreak captures the real world fact that a cloud can always refuse to
provide a service. Thus, every operation on the outsourced messages is fulfilled
by Fbreak only if the cloud agrees on responding.

Definition 1 (Break-glass encryption scheme). A scheme Π is a secure
break-glass encryption scheme if it realizes the functionality Fbreak in the sense
of [HL10].

4.2 The Gperm Ideal Functionality

The ideal functionality Gperm is described in Fig. 2 and is inspired by the signature
ideal functionality of [Can04]. The purpose of this functionality is to alert the
user Ui, registered with alert address alert-infoi, that a permission request was
triggered by a party. The user Ui can then provide a proof to either legitimate
or to invalidate the permission request. This proof is then sent to the cloud
Ci associated to alert-infoi. If the user fails to provide any proof within time
TWaitPermission, then a proof of silence is generated and provided to C.



44 A. Scafuro

FunctionalityFbreak.
Participants: The cloud C, a user U , the adversary.
Variables: a boolean flag, when flag = 1 means that there has been an illegitimate
break. A vector Status = Status[1], . . . , Status[l], with Status[i] = b|nlegit where b = 1
means that the i-th ciphertext was broken; nlegit = 1 means that the break was
not legitimate. A vector CheatΠ[1], . . . , CheatΠcheat[l] collects proofs of illegitimate
break-glass.
External Functionality: Gperm.
Algorithms: Fbreak is parameterized by VrfyCheatProof to check the proofs of ille-
gitimate access provided by a corrupted cloud.
Procedure:
ďż˝ Upload. Upon receiving (upload, sid, m1, . . . , ml, U) from user U , store the vector
M = m1, . . . , ml. (Ignore any other request of this type). Send (uploaded, sid, l, U) to
the cloud C and the adversary.
ďż˝ Update. Upon receiving (update, sid, i, m) from user U , send (update, sid, i) to C.
If C is corrupted, then wait for answer (ack-updated, sid, U , resp). If resp = no send
(refuse, ⊥) to U . Else, update mi := m. Send (updated, sid, i) to U ,";"""date"",""2019-03-28T12:39:19Z""
""pdf:PDFVersion"",""1.6""
""xmp:CreatorTool"",""Springer""
""pdf:docinfo:title"",""Break-glass Encryption""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""Public-Key Cryptography – PKC 2019, doi:10.1007/978-3-030-17259-6_2""
""pdfa:PDFVersion"",""A-2b""
""xmpMM:History:Action"",""converted"",""converted""
""language"",""en""
""dc:format"",""application/pdf; version=""""A-2b"""""",""application/pdf; version=1.6""
""pdf:docinfo:custom:robots"",""noindex""
""pdf:docinfo:creator_tool"",""Springer""
""access_permission:fill_in_form"",""true""
""xmpMM:History:When"",""2019-03-28T18:08:11Z"",""2019-03-28T18:09:19Z""
""pdf:encrypted"",""false""
""dc:title"",""Break-glass Encryption""
""xmp:CreateDate"",""2019-03-28T18:05:50Z""
""modified"",""2019-03-28T12:39:19Z""
""cp:subject"",""Public-Key Cryptography – PKC 2019, doi:10.1007/978-3-030-17259-6_2""
""xmpMM:History:SoftwareAgent"",""pdfToolbox"",""pdfToolbox""
""pdf:docinfo:custom:CrossMarkDomains[1]"",""springer.com""
""robots"",""noindex""
""pdf:docinfo:subject"",""Public-Key Cryptography – PKC 2019, doi:10.1007/978-3-030-17259-6_2""
""pdf:hasMarkedContent"",""false""
""xmpMM:History:InstanceID"",""uuid:34351b40-ffda-4231-b02b-76efcb99c525"",""uuid:6c2d968b-3099-4488-aa49-e39394ea0963""
""xmp:ModifyDate"",""2019-03-28T18:09:19Z""
""pdf:docinfo:creator"",""Alessandra Scafuro ""
""meta:author"",""Alessandra Scafuro ""
""meta:creation-date"",""2019-03-28T12:35:50Z""
""pdf:docinfo:custom:CrossmarkMajorVersionDate"",""2010-04-23""
""created"",""2019-03-28T12:35:50Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-03-28T12:35:50Z""
""resourceName"",""10098718""
""pdfaid:part"",""2""
""pdf:docinfo:custom:CrossMarkDomains[2]"",""springerlink.com""
""pdf:docinfo:custom:doi"",""10.1007/978-3-030-17259-6_2""
""pdf:docinfo:custom:CrossmarkDomainExclusive"",""true""
""Author"",""Alessandra Scafuro ""
""CrossmarkDomainExclusive"",""true""
""doi"",""10.1007/978-3-030-17259-6_2""
""pdf:unmappedUnicodeCharsPerPage"",""1"",""0"",""0"",""0"",""0"",""5"",""1"",""0"",""0"",""0"",""5"",""5"",""2"",""0"",""5"",""2"",""2"",""13"",""9"",""3"",""22"",""2"",""1"",""3"",""0"",""0"",""29"",""0"",""0""
""dc:description"",""Public-Key Cryptography – PKC 2019, doi:10.1007/978-3-030-17259-6_2""
""access_permission:modify_annotations"",""true""
""dc:creator"",""Alessandra Scafuro ""
""description"",""Public-Key Cryptography – PKC 2019, doi:10.1007/978-3-030-17259-6_2""
""dcterms:created"",""2019-03-28T12:35:50Z""
""Last-Modified"",""2019-03-28T12:39:19Z""
""dcterms:modified"",""2019-03-28T12:39:19Z""
""title"",""Break-glass Encryption""
""xmpMM:DocumentID"",""uuid:3ac95b13-06a5-46bd-8bfe-489e8bbbccdb""
""Last-Save-Date"",""2019-03-28T12:39:19Z""
""CrossMarkDomains[1]"",""springer.com""
""pdf:docinfo:modified"",""2019-03-28T12:39:19Z""
""meta:save-date"",""2019-03-28T12:39:19Z""
""Content-Length"",""940013""
""Content-Type"",""application/pdf""
""xmp:MetadataDate"",""2019-03-28T18:09:19Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Alessandra Scafuro ""
""pdfaid:conformance"",""B""
""dc:language"",""EN""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""29""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""2116"",""2795"",""2873"",""2263"",""2824"",""2789"",""2904"",""2806"",""2425"",""2304"",""2180"",""2383"",""2537"",""2359"",""2309"",""1991"",""1819"",""1981"",""1695"",""2099"",""2430"",""2064"",""2390"",""2465"",""2197"",""1798"",""1644"",""2948"",""1416""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""CrossMarkDomains[2]"",""springerlink.com""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-03-28T12:35:50Z""
""CrossmarkMajorVersionDate"",""2010-04-23""
";https://scholar.google.com/scholar?start=630&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094579-820;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[PDF][PDF] Breaking Tweakable Enciphering Schemes using Simon's Algorithm.;S Ghosh, P Sarkar ; IACR Cryptol. ePrint Arch., 2019  eprint.iacr.org;;"… use the quantum period finding procedure called Simon's algorithm to attack several symmetric

crypto-systems … In the classical setting the adversary is given only classical access to the

corresponding oracles, ie all the oracle queries and other computations are classical …";Cité 2 fois;;[PDF] iacr.org;https://eprint.iacr.org/2019/724.pdf;"
Breaking Tweakable Enciphering Schemes using Simon’s Algorithm

Sebati Ghosh and Palash Sarkar
Indian Statistical Institute

203, B.T.Road, Kolkata, India - 700108.
{sebati r,palash}@isical.ac.in

January 13, 2021

Abstract

We show the applicability of Simon’s period finding quantum algorithm to the cryptanalysis
of several tweakable enciphering schemes (TESs), namely, CMC, EME, XCB, TET and FAST.
For XCB, TET and FAST, the attacks reveal portions of the secret key. For all of the five TESs,
we show distinguishing attacks based on two encryption queries.
Keywords: tweakable enciphering scheme, Simon’s algorithm.

1 Introduction

The eventual availability of large-scale quantum computers appears to be a certainty. This will
have major impact on cryptography. Public key cryptography based on factoring and discrete
logarithm problem will be completely broken by Shor’s algorithm [16]. The impact on symmetric
key cryptography will be less devastating. Exhaustive key search for symmetric key ciphers will
be speeded up by a quadratic factor using Grover’s algorithm [6]. Symmetric key primitives such
as block and stream ciphers are often used in modes of operations to build versatile cryptographic
functionalities. A series of works [12, 13, 11, 2, 4] have shown the applicability of Simon’s period
finding quantum algorithm [17] to cryptanalysis of certain modes of operations.

In the present work, we continue the line of work on using Simon’s algorithm to attack modes of
operations. Our target modes of operations are tweakable enciphering schemes (TESs) [9]. These
provide several important cryptographic functionalities including that of full disk encryption. We
refer to [9] for a description of how a TES can be used for disk encryption and to [3] for more
general functionalities. Some TESs have also been standardised [1].

We consider five TESs, namely, CMC [9], EME [10, 7], TET [8], XCB [14, 15] and FAST [3].
CMC was the first TES to be proposed; IEEE has standardised [1] XCB and EME; TET uses
invertible universal hash; and presently FAST provides the most recent development.

Following Kaplan et al. [11], the attacks that we describe are based on the application of Simon’s
algorithm. The algorithm performs the following task. Suppose f : {0, 1}m → {0, 1}n is a function
and there is an s 6= 0m such that for all x ∈ {0, 1}m, f(x) = f(x ⊕ s). This s is called the period
of the function. Using O(m) quantum queries to f , Simon’s algorithm can uncover s with high
probability. The description in [17] required f to be a 2-to-1 function which was later modified to
a looser condition in [11].

For each of the TES that we consider, we construct a function f based on the encryption
algorithm of the TES. The function f has a period which is based on variables that are used during

1



the computation, but is not revealed as part of the ciphertext. Applying Simon’s algorithm to f
uncovers the period and reveals the internal secret variable. In the cases of TET, XCB and FAST,
obtaining the period of f reveals a portion of the secret key of the TES resulting in a partial key
recovery attack. For all the five TESs, we show that using the period, it is possible to construct
two distinct plaintexts such that designated portions of the corresponding ciphertexts are equal.
This results in distinguishing attacks on all the TESs under consideration.

2 Preliminaries

For a binary string x, by len(x) we will denote the length of x. The concatenation of two strings
x1 and x2 will be denoted as x1||x2. Given an integer i in the range 0 ≤ i < 2k − 1, bink(i) denotes
the k-bit binary representation of i. A set containing bit strings of length l or more is denoted by
{0, 1}≥l, i.e. {0, 1}≥l = {x ∈ {0, 1}∗ : len(x) ≥ l}.

We fix a positive integer n. A block cipher is a function E : K × {0, 1}n → {0, 1}n, where K
is a finite non-empty set and for each K ∈ K, EK(·) ∆

= E(K, ¡) is a permutation of {0, 1}n. The
integer n denotes the block size and K is the key of the block cipher. The corresponding decryption

function is D : K × {0, 1}n → {0, 1}n, where for each K ∈ K, DK(·) ∆
= D(K, ¡) is the inverse of

EK(¡), i.e., for any x ∈ {0, 1}n, DK(EK(x)) = x.

2.1 Tweakable Enciphering Scheme

A tweakable enciphering scheme is a pair TES = (TES.Encrypt,TES.Decrypt) where

TES.Encrypt,TES.Decrypt : K × T × P → P

for finite non-empty sets K, T and P. The set K is called the key space, T is called the tweak space
and P is called the message/ciphertext space. We write TES.EncryptK(¡, ¡) (resp. TES.DecryptK(¡, ¡))
to denote TES.Encrypt(K, ¡, ¡) (resp. TES.Decrypt(K, ¡, ¡)). The functions TES.Encrypt and TES.Decrypt
satisfy the following two properties. For K ∈ K, T ∈ T and P ∈ P,

1. TES.DecryptK(T,TES.EncryptK(T, P )) = P ;

2. len (TES.EncryptK(T, P )) = len(P ).

The first property states that the encryption and the decryption functions are inverses of each
other while the second property states that the length of the ciphertext is equal to the length of
the plaintext. In other words, TES.EncryptK(T, ¡) is a length preserving permutation of P.

2.2 Simon’s Algorithm

Consider the following problem.

Simon’s problem: Given a function f : {0, 1}m → {0, 1}n and the promise that there exists
s ∈ {0, 1}m \ 0m such that for all x 6= y, f(x) = f(y) if and only if x⊕ y = s, find s.

2



The quantity s is often called the period of the function. Simon [17] described a quantum
algorithm which finds the period of f with O(m) quantum queries to the function f and additional
polynomial time classical computation.

Simon’s problem is a promise problem, i.e., the function f has to satisfy the stated condition
for Simon’s algorithm to work. There may be functions for which there is an s ∈ {0, 1}m \ 0m,
such that for all (x, y) ∈ {0, 1}m × {0, 1}m, x ⊕ y ∈ {0m, s} ⇒ f(x) = f(y), but f(x) = f(y)
does not necessarily imply x ⊕ y ∈ {s, 0m}, i.e., there could be t different from s and 0m, such
that f(x) = f(x ⊕ t). Such a t is called a spurious collision. This issue was considered in [11],
which defined the notion of approximate promise problem. For f : {0, 1}m → {0, 1}n such that
f(x⊕ s) = f(x) for all x, the following quantity was defined in [11].

ξ(f, s) = maxt∈{0,1}m\{0,s} Pr
x

[f(x) = f(x⊕ t)]. (1)

Collisions of the form f(x) = f(x⊕ t) for t 6= s are called spurious collisions.
If f satisfies the promise in Simon’s problem and has period s, then ε(f, s) = 0. We say that a

function f : {0, 1}m → {0, 1}n satisfies the promise in Simon’s problem approximately, if there is
an s such that f(x) = f(x⊕ s) for all x and 0 < ε(f, s) < 1. A modification of Simon’s algorithm
to solve the approximate promise problem has been considered in [11] where the following result
was proved.

Theorem 1 (Kaplan et al. [11]). If ε(f, s) ≤ p0 < 1, then for constant c, Simon’s algorithm returns
s with cm quantum queries, with probability at least 1− (2(1+p0

2 )c)m.

If f satisfies the approximate promise problem, then Theorem 1 shows that s can be recovered
with high probability.

Remarks:

1. A function satisfying the promise in Simon’s problem is a 2-to-1 function. Simon had consid-
ered a slightly different problem. Given a function f : {0, 1}m → {0, 1}n which is known to be
either injective or 2-to-1, determine the correct condition and if f is 2-to-1, then determine
its period.

2. In his formulation, Simon required n ≥ m. The analysis of Simon’s algorithm, on the other
hand, goes through without the condition n ≥ m and later works [11, 2, 5] have indeed also
considered n < m.

3 Outline of the Attacks

For each of the TESs that we consider, we identify a function f which either satisfies the promise
in Simon’s problem, or the approximate promise mentioned in Section 2.2. The functions f will be
defined from the encryption functions of the TESs. Applying Simon’s algorithm to f will recover
the period s of the function. To apply Simon’s algorithm, it will be required to make quantum
queries to the encryption function of the corresponding TES. This means that quantum access
to the encryption function of the TES is necessary. This is a strong attack model and has been
adopted in previous works [11, 2, 5].

The TESs that we consider use a block cipher as a building block. The function f is defined
based on the underlying block cipher. As mentioned above, for some of the TESs, we show that

3



f satisfies an approximate promise problem. The proof of approximate promise requires upper
bounding the probability of spurious collisions. Since the definition of f is based on the block
cipher, to bound the probability of spurious collisions of f , we need to make an assumption on the
underlying block cipher. The assumption that we make is to consider the block cipher to behave
like a uniform random function. Since a block cipher is an injective map, it would be appropriate
to assume the block cipher to behave like a uniform random permutation. If the number of inputs
on which the block cipher is invoked is below the birthday bound, then it is reasonable to consider
the block cipher to behave like a uniform random function. In our applications, we will consider
the application of the block cipher to only a few (at most six) inputs.

Once we are able to establish that f satisfies the promise of Simon’s problem (either exactly
or, approximately), application of Simon’s algorithm to f will provide the period of f with high
probability. After the period is determined, the quantum aspect is over. The rest of the attack
will be of two types. In the first type of attack, from the period a portion of the secret key can be
determined which leads to a distinguishing attack. In the second kind of attack, the period reveals
a portion of internal (non-key) state of the encryption and this also leads to a distinguishing attack.

We do not provide the formal definition of security of TES since this will not be required for our
work. The notion of security that we consider is that of indistinguishability from uniform random
strings. This implies other notions of security (see [9]). The distinguishing attacks that we describe
are of the following type. We show that using the period, it is possible to construct two distinct
inputs such that applying the encryption function of the TES to these inputs provide two outputs
such that a designated portions of these two outputs are equal. If the outputs were obtained by
applying a uniform random function to the two inputs, then the probability that the designated
portions of the outputs are equal would be negligible. So, the two inputs distinguish the encryption
function of the TES from a uniform random function.

In Section 4, we describe the attacks on TESs where it is possible to recover a portion of the
key, while in Section 5, we describe the distinguishing attacks on the other TESs.

4 Partial Key Recovery Attacks

4.1 XCB

XCB was proposed by McGrew and Fluhrer [14]. A later variant [15] was standardised by IEEE [1].
We describe the quantum attack on the standardised version [15] of XCB. A similar attack also
works on the previous version.

XCB is built using a block cipher and a polynomial hash function. The key K of XCB is the
same as the key of the underlying block cipher. XCB defines a tweak space. In our attack, we will
fix the tweak to be the empty string.

XCB can be used with an n-bit block cipher. For the sake of convenience, we fix n = 128. Let
EK denote the encryption function of the underlying block cipher instantiated with the key K.
Using EK , XCB derives the keys Ke, Kd, Kc and τ . Here τ is used as the key to a polynomial hash
function called GHASH, Kc is the key to the counter mode of encryption and Ke and Kd are used
as shown in Figure 1. The counter mode Ctr uses the function incr to obtain successive values to
be encrypted.

Our attack considers 3-block messages. So, we briefly describe the encryption of 3-block mes-
sages with reference to Figure 1. The message is partitioned into a single block and a 2-block
message. The functions h1 and h2 in Figure 1 are polynomial hash functions using the key τ . The

4



counter mode Ctr uses Q as the initialisation vector. The rest of the encryption algorithm can be
understood from Figure 1. We provide more details as part of the attack.

Figure 1: Enciphering a 3-block message α0||x||m or α1||x⊕α0τ⊕α1τ ||m with tweak ε under XCB.

EKe

A = m

P

h1

Q

S

DKd

V = y3

h2

Ctr

R

B = Îą0||x or
α1||x ⊕ α0τ ⊕ α1τ

y1||y2

Îľ

Fix m,ι0, ι1 ∈ {0, 1}n, such that ι0 6= ι1; let b denote a bit. For the standardised version [15],
we define the following function.

f : {0, 1} × {0, 1}n → {0, 1}n

(b, x)
f7−→ y3, where y1||y2||y3 ←− XCB.EncryptK(ε, αb||x||m). (2)

The function f defined in (2) satisfies the following property.

Proposition 1. Let b, b′ ∈ {0, 1}, x ∈ {0, 1}n. Then, f(b, x) = f(b′, x⊕ αbτ ⊕ αb′τ), where α0 and
α1 are as fixed before and τ is the hash key.

Proof. Let Îł be a 128-bit string which is formed by concatenating the 64-bit binary representation
of 128 and the 64-bit binary representation of 384. Let γ′ be a 128-bit string which is formed by
concatenating the 64-bit binary representation of 128 and the 64-bit binary representation of 256.

5



Let γ′′ = γ. For the input αb||x||m,

A = m;

B = Îąb||x;

P = EKe(m);

Q = EKe(m)⊕ αbτ3 ⊕ xτ2 ⊕ γτ ;

R = αb ⊕ EKc(Q)||x⊕ EKc(incr(Q));

S = EKe(m)⊕ αbτ3 ⊕ xτ2 ⊕ γτ ⊕ αbτ4

⊕EKc(Q)τ4 ⊕ xτ3 ⊕ EKc(incr(Q))τ3 ⊕ γ′τ2 ⊕ γ′′τ ;

V = DKd(S);

For the input αb′ ||x⊕ αbτ ⊕ αb′τ ||m,

A′ = m;

B′ = αb′ ||x⊕ αbτ ⊕ αb′τ ;

P ′ = EKe(m);

Q′ = EKe(m)⊕ αbτ3 ⊕ xτ2 ⊕ γτ ;

R′ = αb′ ⊕ EKc(Q′)||x⊕ αbτ ⊕ αb′τ ⊕ EKc(incr(Q′));
S′ = EKe(m)⊕ αbτ3 ⊕ xτ2 ⊕ γτ ⊕ αbτ4

⊕EKc(Q′)τ4 ⊕ xτ3 ⊕ EKc(incr(Q′))τ3 ⊕ γ′τ2 ⊕ γ′′τ ;

V ′ = DKd(S
′).

We observe, Q = Q′ results in S = S′, which implies V = V ′. So, the third blocks of the outputs
are same, establishing the result.

From the above it follows that 1||α0τ⊕α1τ is a period of f . Proposition 1 falls short of showing
that f satisfies the promise of Simon’s problem. We show below, that f satisfies an approximate
promise.

Proposition 2. Assume that the block cipher E instantiated with a uniform random key, behaves
like a uniform random function. Then, for f defined in (2), ε(f, 1||α0τ ⊕ α1τ) ≤ 5/2n.

Proof. Let η||t /∈ {0||0n, 1||α0τ ⊕ α1τ} be such that

Pr
b,x

[f(b, x) = f(b⊕ η, x⊕ t)]

= maxη′||t∈{0,1}×{0,1}n\{0||0n,1||α0τ⊕α1τ} Pr
b,x

[f(b, x) = f(b⊕ η′, x⊕ t)].

Case 1: Suppose Ρ = 0. Then t is necessarily non-zero. We have

f(b, x) = DKd(EKe(m)⊕ αbτ3 ⊕ xτ2 ⊕ γτ ⊕ αbτ4

⊕EKc(Q)τ4 ⊕ xτ3 ⊕ EKc(incr(Q))τ3 ⊕ γ′τ2 ⊕ γ′′τ);

f(b, x⊕ t) = DKd(EKe(m)⊕ αbτ3 ⊕ xτ2 ⊕ tτ2 ⊕ γτ ⊕ αbτ4 ⊕ EKc(Q⊕ tτ2)τ4 ⊕ xτ3 ⊕ tτ3

⊕EKc(incr(Q⊕ tτ2))τ3 ⊕ γ′τ2 ⊕ γ′′τ).

6



Then f(b, x) = f(b, x⊕ t) if and only if X1 = X2, where

X1 = EKc(Q)τ4 ⊕ EKc(incr(Q))τ3;

X2 = tτ2 ⊕ EKc(Q⊕ tτ2)τ4 ⊕ tτ3 ⊕ EKc(incr(Q⊕ tτ2))τ3.

Let E be the event that Q, incr(Q), Q⊕ tτ2 and incr(Q⊕ tτ2) are distinct. Note that Q and τ are
obtained by encryption under the block cipher E. Clearly Q and incr(Q) are distinct and so are
Q ⊕ tτ2 and incr(Q ⊕ tτ2). Under the assumption that EK is uniform random function, we have
Pr[E] ≤ 4/2n. Conditioned on E, and under the assumption that E behaves like a uniform random
function, the probability that X1 = X2 is at most 1/2n. So,

Pr
b,x

[f(b, x) = f(b⊕ η, x⊕ t)] = Pr[X1 = X2]

≤ Pr[X1 = X2|E] + Pr[E]

≤ 5

2n
.

Case 2: Suppose η = 1. Then t 6= α0τ ⊕ α1τ . Let b′ = b⊕ 1. We have

f(b, x) = DKd(EKe(m)⊕ αbτ3 ⊕ xτ2 ⊕ γτ ⊕ αbτ4

⊕EKc(Q)τ4 ⊕ xτ3 ⊕ EKc(incr(Q))τ3 ⊕ γ′τ2 ⊕ γ′′τ);

f(b⊕ η, x⊕ t) = f(b′, x⊕ t)
= DKd(EKe(m)⊕ αb′τ3 ⊕ xτ2 ⊕ tτ2 ⊕ γτ ⊕ αb′τ4

⊕EKc(Q′)τ4 ⊕ xτ3 ⊕ tτ3 ⊕ EKc(incr(Q′))τ3 ⊕ γ′τ2 ⊕ γ′′τ).

So, f(b, x) = f(b⊕ η, x⊕ t) if and only if Y1 = Y2, where

Y1 = EKc(Q)τ4 ⊕ EKc(incr(Q))τ3 ⊕ EKc(Q′)τ4 ⊕ EKc(incr(Q′))τ3;

Y2 = αbτ
3 ⊕ αb′τ3 ⊕ tτ2 ⊕ αbτ4 ⊕ αb′τ4 ⊕ tτ3.

A reasoning similar to Case 1 shows that Prb,x[f(b, x) = f(b⊕ η, x⊕ t)] is at most 5/2n.

In view of Proposition 2, it follows that f satisfies an approximate promise. So, Simon’s
algorithm applied to f uncovers the period 1||s with high probability, where s = α0τ ⊕ α1τ . Since
α0 and α1 are known, given s, it is possible to obtain τ . This provides the hash key of XCB.

Obtaining s also provides a distinguishing attack against XCB. Let y1||y2||y3 be the ciphertext
produced by encrypting α0||0128||m; and let y′1||y′2||y′3 be the ciphertext produced by encrypting
α1||s||m. Then y3 = y′3. This can be seen from Proposition 1 on putting x = 0128.

4.2 TET

TET [8] has key space K×K, where K is the key space for the underlying block cipher having block
size n. The tweak space is T = {0, 1}∗. The message space is P = {0, 1}m where m ∈ [n, 2n − 1].
Fix arbitrary (K1,K2) from the key-space and arbitrary T from the tweak-space.

The attack against TET also considers 3-block messages. Hence, we briefly explain the en-
cryption of 3-block messages with reference to Figure 2. EK2 is the encryption function of the
underlying block cipher instantiated with the key K2. The encryption consists of five layers; the
first, second, fourth and fifth being masking layers and the third layer being application of EK2 .

7



The quantities SP , ι, β and SC are masking elements; SP is formed by combining the message
blocks through a polynomial hash, the key to which is τ ; σ = 1⊕τ⊕τ2⊕τ3 (for a 3-block message).
The exact definitions of the masking elements are not required for our purpose, so, we skip these
details and refer to [8] for their definitions. We only note that ι and β are elements of the finite
field GF (2n) and arithmetic is done over this field.

Figure 2: Enciphering a 3-block message x||x1||x or x ⊕ δ||x1 ⊕ δ1||x ⊕ δ under TET, where δ =

α2β ⊕ β, δ1 = (α2β⊕β)(τ⊕τ3)
τ2

.

EK2

x1/x1 ⊕
δ1

SP
P2

Q2

R2

S2

ιβ

ιβ

SC

y2

EK2

x/x ⊕ δ

P3

Q3

R3

S3

SP

ι2β

ι2β

SC

y3

EK2

x/x ⊕ δ

P1

Q1

R1

S1

SP

β

β

SC

y1

We define the following function.

f : {0, 1}n × {0, 1}n → {0, 1}n

(x, x1)
f7−→ y1 ⊕ y3, where y1||y2||y3 ←− TET.EncryptK1,K2

(T, x||x1||x). (3)

The function f defined in (3) satisfies the following property.

Proposition 3. For x, x1 ∈ {0, 1}n, f(x, x1) = f(x⊕α2β⊕β, x1⊕ (α2β⊕β)(τ⊕τ3)
τ2

), where ι, β and
τ are as described earlier.

Proof. For the input x||x1||x, we have,

SP = (xτ3 ⊕ x1τ
2 ⊕ xτ)/σ;

Q1 = x⊕ SP ⊕ β;

Q2 = x1 ⊕ SP ⊕ αβ;

Q3 = x⊕ SP ⊕ α2β;

S1 = EK2(x⊕ SP ⊕ β)⊕ β;

S2 = EK2(x1 ⊕ SP ⊕ αβ)⊕ αβ;

S3 = EK2(x⊕ SP ⊕ α2β)⊕ α2β;

y1 ⊕ y3 = EK2(x⊕ SP ⊕ β)⊕ β ⊕ EK2(x⊕ SP ⊕ α2β)⊕ α2β;

8



For the input x⊕ α2β ⊕ β||x1 ⊕ (α2β⊕β)(τ⊕τ3)
τ2

||x⊕ α2β ⊕ β, we have,

SP ′ = (xτ3 ⊕ x1τ
2 ⊕ xτ)/σ;

Q′1 = x⊕ α2β ⊕ β ⊕ SP ′ ⊕ β
= x⊕ α2β ⊕ SP ′;

Q′2 = x1 ⊕
(α2β ⊕ β)(τ ⊕ τ3)

τ2
⊕ SP ′ ⊕ αβ;

Q′3 = x⊕ α2β ⊕ β ⊕ SP ′ ⊕ α2β

= x⊕ β ⊕ SP ′;
S′1 = EK2(x⊕ SP ′ ⊕ α2β)⊕ β;

S′2 = EK2(x1 ⊕
(α2β ⊕ β)(τ ⊕ τ3)

τ2
⊕ SP ′ ⊕ αβ)⊕ αβ;

S′3 = EK2(x⊕ SP ′ ⊕ β)⊕ α2β;

y′1 ⊕ y′3 = EK2(x⊕ SP ′ ⊕ α2β)⊕ β ⊕ EK2(x⊕ SP ′ ⊕ β)⊕ α2β.

Now, SP = SP ′ implies y1 ⊕ y3 = y′1 ⊕ y′3.
Hence, the proposition is proved.

The above proposition establishes that α2β ⊕ β|| (α
2β⊕β)(τ⊕τ3)

τ2
||α2β ⊕ β is a period of f . Again

Proposition 3 falls short of showing that f satisfies the promise of Simon’s problem. We show
below, that f satisfies an approximate promise.

Proposition 4. Assume that the block cipher E instantiated with a uniform random key, behaves

like a uniform random function. Then, for f defined in (3), ε(f, α2β⊕β|| (α
2β⊕β)(τ⊕τ3)

τ2
||α2β⊕β) ≤

15/2n.

Proof. Let t||t1 /∈ {0n||0n, α2β ⊕ β|| (α
2β⊕β)(τ⊕τ3)

τ2
} be such that

Pr
x,x1

[f(x, x1) = f(x⊕ t, x1 ⊕ t1)]

= max
t||t1∈{0,1}2n\{0n||0n,α2β⊕β|| (α

2β⊕β)(τ⊕τ3)
τ2

}
Pr
x,x1

[f(x, x1) = f(x⊕ t, x1 ⊕ t1)].

Let

SP = (xτ3 ⊕ x1τ
2 ⊕ xτ)/σ;

SP ′ = ((x⊕ t)τ3 ⊕ (x1 ⊕ t1)τ2 ⊕ (x⊕ t)τ)/σ;

We have

f(x, x1) = EK2(x⊕ SP ⊕ β)⊕ β ⊕ EK2(x⊕ SP ⊕ α2β)⊕ α2β;

f(x⊕ t, x1 ⊕ t1) = EK2(x⊕ t⊕ SP ′ ⊕ β)⊕ β ⊕ EK2(x⊕ t⊕ SP ′ ⊕ α2β)⊕ α2β.

Then f(x, x1) = f(x⊕ t, x1 ⊕ t1) if and only if X1 = X2, where

X1 = EK2(x⊕ SP ⊕ β)⊕ EK2(x⊕ SP ⊕ α2β);

X2 = EK2(x⊕ t⊕ SP ′ ⊕ β)⊕ EK2(x⊕ t⊕ SP ′ ⊕ α2β).

9



Let E be the event that Y1 = x ⊕ SP ⊕ β, Y2 = x ⊕ SP ⊕ α2β, Y3 = x ⊕ t ⊕ SP ′ ⊕ β and
Y4 = x ⊕ t ⊕ SP ′ ⊕ α2β are distinct. Note that β and τ are obtained by encryption under the
block cipher E on inputs which may or may not be equal. If the inputs are distinct, β and τ are
independent and uniform random strings under the assumption that E is uniform random function;
on the other hand if the inputs are equal, then β = τ . Under the assumption that EK2 behaves
like a uniform random function, we get the following.

Pr[Y1 = Y2] = Pr[Y3 = Y4] = Pr[β(1⊕ α2) = 0n] = 1/2n;

Pr[Y1 = Y3] = Pr[Y2 = Y4] = Pr[SP ⊕ SP ′ = t] = Pr[(t⊕ t1)τ2 = t] ≤ 2/2n;

Pr[Y1 = Y4] = Pr[Y2 = Y3] = Pr[SP ⊕ SP ′ = α2β ⊕ β ⊕ t] = p1 (say).

• When β and τ are independent and uniform random strings, the expression SP ⊕ SP ′ =
α2β ⊕ β ⊕ t turns into an equation involving β and τ . Here we get p1 = 1/2n.

• When β = τ , the expression SP ⊕ SP ′ = α2β ⊕ β ⊕ t turns into a degree 4 equation of τ .
Hence, in this case, p1 ≤ 4/2n.

Taking these together, we have Pr[E] ≤ 14/2n. Conditioned on E, and under the assumption
that EK2 behaves like a uniform random function, the probability that X1 = X2 is at most 1/2n.
So,

Pr
x,x1

[f(x, x1) = f(x⊕ t, x1 ⊕ t1)] = Pr[X1 = X2]

≤ Pr[X1 = X2|E] + Pr[E]

≤ 15

2n
.

In view of Proposition 4, it follows that f satisfies an approximate promise. So, Simon’s

algorithm applied to f uncovers the period s = α2β⊕β|| (α
2β⊕β)(τ⊕τ3)

τ2
||α2β⊕β with high probability.

Suppose the middle n-bit of the period is m. Then we obtain the equation mτ2⊕(τ⊕τ3)(β⊕α2β) = 0
which is a degree three equation in τ , from which the value of τ can be determined. This provides
the hash key of TET.

Obtaining s also provides a distinguishing attack against TET. Let y1||y2||y3 be the ciphertext
produced by encrypting 0128||0128||0128; and let y′1||y′2||y′3 be the ciphertext produced by encrypting

α2β ⊕ β|| (α
2β⊕β)(τ⊕τ3)

τ2
||α2β ⊕ β. Then y1 ⊕ y3 = y′1 ⊕ y′3. This can be seen from Proposition 3 on

putting x = x1 = 0128.

4.3 FAST

FAST was proposed by Chakraborty, Ghosh, López and Sarkar [3]. It is built using a fixed input
length pseudo-random function and an appropriate hash function. The key K of FAST is the same
as the key of the underlying pseudo-random function. The pseudo-random function maps n-bit
strings to n-bit strings. For the sake of concreteness, we fix n = 128. Let FK denote the pseudo-
random function instantiated with the key K. FAST is targeted towards two application scenarios.
We describe the quantum attack on the instantiation targeted towards the specific task of disk
encryption. In this case, the tweak space is T = {0, 1}n and the message space is P = {0, 1}mn,

10



Figure 3: Enciphering a 4-block message Îą0||x||m||m or Îą1||x||m||m under FAST.

CtrK

Hτ

τG’

   / 
0 1 m, mx

1P  1Q

S11R

y
1

y
2

y
3,

y
4

Feistel
Layer

Z

T

T

Îą Îą

FK

P 1 1Q

1R S 1

FK

FK

Z/Z ⊕ binn(3)

binn(2)

m

y4

FK

Z/Z ⊕ binn(3)

binn(1)

m

y3

where m > 2 is determined by the size of a disk sector. In our attack we will fix the tweak to be
an arbitrary T ∈ T .

Our attack considers 4-block messages. So, we briefly describe the encryption of 4-block mes-
sages with reference to Figures 3 and 4. From a top level view, FAST consists of three distinct
layers - hash-encrypt-hash. The hashing layers H and G are based on two universal hash functions
h and h′, both having the key τ . The encryption layer consists of a two-round Feistel network and
a counter mode Ctr. The two-round Feistel is built using the PRF FK and processes the first two
blocks of the plaintext. The third and fourth blocks are encrypted in a counter mode built using
FK . The offset for the counter mode is derived from the input and output of the Feistel layer. The
input of the Fiestel layer is obtained by processing the plaintext and the tweak through the first
hash layer. The second hash layer generates the first two blocks of the ciphertext by processing the
output of the Fiestel layer and the third and fourth blocks of the ciphertext. Some more details
are provided as part of the attack.

Figure 4: The hash functions H and G.

hτ

P3 T

A1

P1

·τ

F1

P2

hτ

P3 T

P1

A1

·τ

P2

F1

11



Fix m,α0, α1 ∈ {0, 1}n, such that α0 ⊕ α1 = 012611; let b denote a bit. We define the following
function.

f : {0, 1} × {0, 1}n → {0, 1}n

(b, x)
f7−→ y3 ⊕ y4, where y1||y2||y3||y4 ←− FAST.EncryptK(T, αb||x||m||m). (4)

The function f defined in (4) satisfies the following property.

Proposition 5. Let b, b′ ∈ {0, 1}, x ∈ {0, 1}n. Then, f(b, x) = f(b′, x⊕ αbτ ⊕ αb′τ). α0, α1 and τ
are as described before.

Proof. For the input (T, Îąb||x||m||m),

P1 = αb ⊕ hτ (T,m||m);

Q1 = x⊕ τ(αb ⊕ hτ (T,m||m));

R1 = αb ⊕ hτ (T,m||m)⊕ FK(Q1);

Z = Q1 ⊕ αb ⊕ hτ (T,m||m)⊕ FK(Q1);

y3 = m⊕ FK(Q1 ⊕ αb ⊕ hτ (T,m||m)⊕ FK(Q1)⊕ binn(1));

y4 = m⊕ FK(Q1 ⊕ αb ⊕ hτ (T,m||m)⊕ FK(Q1)⊕ binn(2));

y3 ⊕ y4 = FK(Q1 ⊕ αb ⊕ hτ (T,m||m)⊕ FK(Q1)⊕ binn(1))

⊕FK(Q1 ⊕ αb ⊕ hτ (T,m||m)⊕ FK(Q1)⊕ binn(2));

For the input (T, αb′ ||x⊕ αbτ ⊕ αb′τ ||m||m),

P ′1 = αb′ ⊕ hτ (T,m||m);

Q′1 = x⊕ αbτ ⊕ αb′τ ⊕ τ(αb′ ⊕ hτ (T,m||m))

= x⊕ αbτ ⊕ τhτ (T,m||m);

R′1 = αb′ ⊕ hτ (T,m||m)⊕ FK(Q′1);

Z ′ = Q′1 ⊕ αb′ ⊕ hτ (T,m||m)⊕ FK(Q′1);

y′3 = m⊕ FK(Q′1 ⊕ αb′ ⊕ hτ (T,m||m)⊕ FK(Q′1)⊕ binn(1));

y′4 = m⊕ FK(Q′1 ⊕ αb′ ⊕ hτ (T,m||m)⊕ FK(Q′1)⊕ binn(2));

y′3 ⊕ y′4 = FK(Q′1 ⊕ αb′ ⊕ hτ (T,m||m)⊕ FK(Q′1)⊕ binn(1))⊕ FK(Q′1 ⊕ αb′ ⊕ hτ (T,m||m)⊕ FK(Q′1)⊕ binn(2))

= FK(Q′1 ⊕ αb ⊕ binn(3)⊕ hτ (T,m||m)⊕ FK(Q′1)⊕ binn(1))⊕ FK(Q′1 ⊕ αb ⊕ binn(3)⊕ hτ (T,m||m)

⊕FK(Q′1)⊕ binn(2)), as αb ⊕ αb′ = binn(3)

= FK(Q′1 ⊕ αb ⊕ hτ (T,m||m)⊕ FK(Q′1)⊕ binn(2))

⊕FK(Q′1 ⊕ αb ⊕ hτ (T,m||m)⊕ FK(Q′1)⊕ binn(1)).

We observe that Q1 = Q′1, which implies y3 ⊕ y4 = y′3 ⊕ y′4. This proves the proposition.

The above discussion establishes that 1||α0τ ⊕ α1τ is a period of f . Proposition 5 falls short
of showing that f satisfies the promise of Simon’s problem. We show below, that f satisfies an
approximate promise.

Proposition 6. Assume that the PRF F instantiated with a uniform random key, behaves like a
uniform random function. Then, for f defined in (4), ε(f, 1||α0τ ⊕ α1τ) ≤ 3

2n .

12



Proof. Let η||t /∈ {0||0n, 1||α0τ ⊕ α1τ} be such that

Pr
b,x

[f(b, x) = f(b⊕ η, x⊕ t)]

= maxη′||t∈{0,1}×{0,1}n\{0||0n,1||α0τ⊕α1τ} Pr
b,x

[f(b, x) = f(b⊕ η′, x⊕ t)].

• Case 1: Suppose η = 0. Then t is necessarily non-zero. We have

f(b, x) = FK(Q1 ⊕ αb ⊕ hτ (T,m||m)⊕ FK(Q1)⊕ binn(1))

⊕FK(Q1 ⊕ αb ⊕ hτ (T,m||m)⊕ FK(Q1)⊕ binn(2));

f(b, x⊕ t) = FK(Q1 ⊕ t⊕ αb ⊕ hτ (T,m||m)⊕ FK(Q1 ⊕ t)⊕ binn(1))

⊕FK(Q1 ⊕ t⊕ αb ⊕ hτ (T,m||m)⊕ FK(Q1 ⊕ t)⊕ binn(2)).

Let

a1 = Q1 ⊕ αb ⊕ hτ (T,m||m)⊕ FK(Q1)⊕ binn(1),

a2 = Q1 ⊕ t⊕ αb ⊕ hτ (T,m||m)⊕ FK(Q1 ⊕ t)⊕ binn(1),

u = binn(1)⊕ binn(2);

Hence

f(b, x) = FK(a1)⊕ FK(a1 ⊕ u);

f(b, x⊕ t) = FK(a2)⊕ FK(a2 ⊕ u).

Let E be the event that a1, a1 ⊕ u, a2 and a2 ⊕ u are distinct. Clearly a1 and a1 ⊕ u are
distinct and so are a2 and a2 ⊕ u. Now we consider the following events.

– E1 := a1 = a2 or, equivalently FK(Q1)⊕ FK(Q1 ⊕ t) = t. As t 6= 0 and FK is assumed
to be a uniform random function, hence Pr[E1] = 1

2n .

– E2 := a1 = a2 ⊕ u or, equivalently FK(Q1) ⊕ FK(Q1 ⊕ t) = t ⊕ u. As in the previous
case, Pr[E2] = 1

2n .

Hence, E := E1 ∪ E2. Note that since u is a non-zero string E1 and E2 are disjoint. Hence,
Pr[E] = Pr[E1]+Pr[E2] = 2

2n . Conditioned on E, and under the assumption that FK behaves
like a uniform random function, the probability that f(b, x) = f(b, x⊕ t) is at most 1/2n. So,

Pr
b,x

[f(b, x) = f(b, x⊕ t)] ≤ Pr
b,x

[f(b, x) = f(b, x⊕ t)|E] + Pr[E]

≤ 3

2n
.

• Case 2: Suppose η = 1. Then t 6= α0τ⊕α1τ . Let b′ = b⊕1, Q′1 = x⊕t⊕τ(αb′⊕hτ (T,m||m)).
We have

f(b, x) = FK(Q1 ⊕ αb ⊕ hτ (T,m||m)⊕ FK(Q1)⊕ binn(1))

⊕FK(Q1 ⊕ αb ⊕ hτ (T,m||m)⊕ FK(Q1)⊕ binn(2));

f(b⊕ η, x⊕ t) = f(b′, x⊕ t)
= FK(Q′1 ⊕ αb′ ⊕ hτ (T,m||m)⊕ FK(Q′1)⊕ binn(1))

⊕FK(Q′1 ⊕ αb′ ⊕ hτ (T,m||m)⊕ FK(Q′1)⊕ binn(2));

13



Let

a1 = Q1 ⊕ αb ⊕ hτ (T,m||m)⊕ FK(Q1)⊕ binn(1)

a2 = Q′1 ⊕ αb′ ⊕ hτ (T,m||m)⊕ FK(Q′1)⊕ binn(1),

u = binn(1)⊕ binn(2);

Hence

f(b, x) = FK(a1)⊕ FK(a1 ⊕ u);

f(b⊕ η, x⊕ t) = FK(a2)⊕ FK(a2 ⊕ u).

A reasoning similar to Case 1 shows that Prb,x[f(b, x) = f(b⊕ η, x⊕ t)] is at most 3/2n.

In view of Proposition 6, it follows that f satisfies an approximate promise. So, Simon’s
algorithm applied to f uncovers the period 1||s with high probability, where s = α0τ ⊕ α1τ . Since
α0 and α1 are known, given s, it is possible to obtain τ . This provides the hash key of FAST.

Obtaining s also provides a distinguishing attack against FAST. Let y1||y2||y3||y4 be the cipher-
text produced by encrypting α0||0128||m||m; and let y′1||y′2||y′3||y′4 be the ciphertext produced by
encrypting α1||α0τ ⊕ α1τ ||m||m. Then y3 ⊕ y4 = y′3 ⊕ y′4. This can be seen from Proposition 5 on
putting x = 0128.

5 Distinguishing Attacks

5.1 CMC

CMC was proposed by Halevi and Rogaway [9], in 2003. It is based on the CBC mode of operation
of a block cipher. The block length of the block cipher can be assumed to be n-bit. CMC has the
key space K × K, where K is the key space for the underlying block cipher and the tweak space
T = {0, 1}n. The message space of CMC is P =

⋃
i∈I{0, 1}i for some non-empty index set I ⊆ N.

Let EK denote the encryption function of the underlying block cipher instantiated with the key K.
Our attack considers 3-block messages. Hence, we briefly describe the encryption of 3-block

messages with reference to Figure 5. Let CMC be instantiated with the key (K, K̃) ∈ K × K. In
our attack we will fix the tweak to be an arbitrary T ∈ T . K̃ is used as the key to the block cipher
E only to produce T from T . At a conceptual level, the CMC encryption function consists of three
layers. The first layer is essentially CBC encryption on the message blocks, followed by a layer
of masking and the third layer is CBC decryption. The rest of the encryption algorithm can be
understood from Figure 5. We provide more details as part of the attack.

Fix m,ι0, ι1 ∈ {0, 1}n, such that ι0 6= ι1; let b denote a bit and we define the following
function.

f : {0, 1} × {0, 1}n → {0, 1}n

(b, x)
f7−→ y1, where y1||y2||y3 ←− CMC.EncryptK,K̃(T,m||αb||x). (5)

The function f defined in (5) satisfies the following property.

14



Figure 5: Enciphering a 3-block message m||α0||x or m||α1||x⊕ s under CMC.

EK

Îą0/Îą1

EK

x/x ⊕ s

EK

m

T

P3

Q3

EK

M

P2

Q2

EK

M

P1

Q1

EK

M

T

y1 y2 y3

Pr";"""date"",""2021-01-13T11:25:55Z""
""pdf:unmappedUnicodeCharsPerPage"",""1"",""1"",""1"",""0"",""6"",""37"",""21"",""1"",""27"",""11"",""1"",""46"",""14"",""12"",""6"",""43"",""0"",""30"",""43"",""4"",""0""
""pdf:PDFVersion"",""1.5""
""xmp:CreatorTool"",""TeX""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dcterms:created"",""2021-01-13T11:25:55Z""
""language"",""en""
""Last-Modified"",""2021-01-13T11:25:55Z""
""dcterms:modified"",""2021-01-13T11:25:55Z""
""dc:format"",""application/pdf; version=1.5""
""Last-Save-Date"",""2021-01-13T11:25:55Z""
""pdf:docinfo:creator_tool"",""TeX""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2021-01-13T11:25:55Z""
""meta:save-date"",""2021-01-13T11:25:55Z""
""pdf:encrypted"",""false""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.20 (TeX Live 2019/Debian) kpathsea version 6.3.1""
""modified"",""2021-01-13T11:25:55Z""
""Content-Length"",""329956""
""pdf:hasMarkedContent"",""false""
""Content-Type"",""application/pdf""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.20 (TeX Live 2019/Debian) kpathsea version 6.3.1""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""trapped"",""False""
""meta:creation-date"",""2021-01-13T11:25:55Z""
""created"",""2021-01-13T11:25:55Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""21""
""Creation-Date"",""2021-01-13T11:25:55Z""
""resourceName"",""724.pdf""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""2339"",""2016"",""2441"",""3051"",""866"",""1145"",""1940"",""984"",""1135"",""2133"",""1161"",""1510"",""1342"",""1852"",""395"",""1292"",""1475"",""986"",""1333"",""2390"",""2056""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""producer"",""pdfTeX-1.40.20""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""pdfTeX-1.40.20""
""pdf:docinfo:created"",""2021-01-13T11:25:55Z""
";https://scholar.google.com/scholar?start=630&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094558-721;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Katal: A standard framework for finance;B França, S Radermacher, R Trinkler ; arXiv preprint arXiv:1903.01600, 2019  arxiv.org;;"… Town Crier was recently acquired by Chainlink [6], a project that provides decentralized oracles

for a … Oracle contracts in Katal are updated by Chainlink nodes using the Town Crier protocol …

Polkadot is composed of a central blockchain, called the relaychain, and a number of …";Autres articles;;[PDF] arxiv.org;https://arxiv.org/pdf/1903.01600;"
Katal
A standard framework for finance

Bruno França, Sophie Radermacher and Reto Trinkler
Trinkler Software

company@trinkler.software

Version 3 – July 3, 2019

Abstract—Katal is a new blockchain that provides a standard
way to build and deploy decentralized finance applications.

It brings together all the components necessary for the backend
of a financial application, namely: a high-performance consensus,
an authenticated data feed system, a standard for financial
contracts and connectivity to the rest of the blockchain ecosystem.

Katal enables and simplifies the creation of financial services
that are non-custodial, trustless, fast, convenient and interoper-
able.

I. INTRODUCTION

Katal aims to create a standard framework for the next stage
of decentralized finance. In order to do this, it combines a high-
performance blockchain, built using an innovative consensus
algorithm and virtual machine, with a runtime that allows easy
creation of assets, a standard for the creation of algorithmic
financial contracts, and connectivity to the outside world and
other blockchains.

Katal appeals to both developers and users:
• For developers, Katal is a low-latency and high-

throughput decentralized platform with native access to
oracles, stable assets, connectivity to other blockchains
and algorithmic contract templates that can be combined
to create any type of financial contract. This allows
developers to easily create decentralized financial services
on top of Katal since custodianship, settlement and data
feeds can be completely delegated to it.

• For users, Katal makes finance easy, using unprecedented
speed, security, and risk management. Funds always
remain under the user’s control, empowering them to truly
be their own banks. Settlement and data feeds are open
and decentralized eliminating the need to trust exchanges.
And, through a single Katal account, it is possible to
interact seamlessly with all the financial services built on
top of Katal (like futures and options exchanges, token
exchanges, margin trading, short selling, collateralized
loans, etc) and also with all the blockchains that connect
to it.

In this paper we will introduce and describe every compo-
nent of Katal and how they interact between themselves. The
rest of the paper is divided as follows:

This work is licensed under the Creative Commons Attribution-ShareAlike
4.0 International License.

• In section II we will discuss the main building blocks of
Katal.

• In section III we will give an overview of the runtime
and operation of Katal.

• In section IV we will delve into the runtime and describe
it in detail.

• In section V we will explore several examples of appli-
cations that can be built on top of Katal.

II. BUILDING BLOCKS

Katal is built on top of an infrastructure that is composed
of six pieces:

• A blockchain development framework called Substrate,
• A consensus algorithm called Albatross,
• A virtual machine called Enso,
• A standard for the algorithmic description of financial

contracts called ACTUS,
• An authenticated data feed system called Town Crier,
• And a heterogeneous multi-chain ecosystem called Polka-

dot.

We will now briefly explain each one of these components.

A. Substrate

Substrate is a software framework for blockchains created
by Parity Technologies. It packs a series of tools, written in
Rust, that enables developers to easily create a blockchain.

For developers who prefer simplicity over freedom, it is
possible to generate a new blockchain with just a simple
configuration file. While developers that prefer freedom can
create their own consensus algorithms and runtimes from
scratch.

Substrate is a combination of mostly two technologies,
WebAssembly and Libp2p. The built-in WebAssembly in-
terpreter enables developers to write their own ready-to-use
modules in any language they wish, as long as it compiles
down to WebAssembly, and Libp2p constitutes the bulk of
the networking functionality.

For Katal we will use the most bare-bones version of Sub-
strate, called Substrate Core, that provides only the network-
ing, the WebAssembly interpreter and some other auxiliary
tools and we will provide the consensus and runtime modules.

1

ar
X

iv
:1

90
3.

01
60

0v
3 

 [
cs

.C
R

] 
 3

 J
ul

 2
01

9



B. Albatross
Albatross [1] is a novel consensus algorithm, developed by

Trinkler Software and Nimiq, that is inspired by speculative
BFT consensus algorithms.

Speculative BFT is a class of classical consensus algorithms
that have very high performance when compared to older
algorithms like PBFT [2]. Speculative BFT consensuses have
two modes of operation: an optimistic mode where nodes
are assumed to be well-behaved thus resulting in greater
performance, and the pessimistic mode where it is assumed
that some nodes are malicious and the only goal is to make
progress.

Albatross takes a ’trust but verify’ attitude to block pro-
duction. Nodes are allowed to make updates to the state by
themselves but other nodes can revert the update if it is not
valid.

In Albatross there is a validator list that is selected at
random from the set of all nodes that stake tokens. The
validator list is changed every epoch, where an epoch is
composed of T micro blocks and one macro block.

Validators take turns producing micro blocks, which are
transaction-containing blocks that are signed by a single val-
idator. Macro blocks do not contain any transactions 1, being
instead used to change the validator set, and are produced with
PBFT.

If all validators follow the protocol correctly, Albatross will
produce blocks as fast as the network allows. Since macro
blocks don’t contain any transactions, there will be a small
pause at the end of every epoch, but that downtime constitutes
only a small percentage of the total time. So, in the optimistic
case, Albatross will come close to the theoretical limit for a
single-chain consensus algorithm.

However, if there are malicious validators they may misbe-
have. There are three ways in which they can do that:

• Invalid blocks: Validators may produce invalid blocks,
in this case the other validators will simply ignore those
blocks.

• Forking: Creating or continuing a fork will result in the
stakes of the misbehaving validators being confiscated.

• Delays: If a validator, in his turn, does not produce a
valid block after a predetermined amount of time, the

1We use same definition for transaction as the one taken by Parity. There
are extrinsics, which are any input to the state transition function, and
both transactions and inherents are mutually exclusive types of extrinsics.
Transactions are extrinsics that are propagated through the network and signed.
Inherents are neither propagated nor signed. An example of an inherent is a
timestamp.

other nodes will begin a view change protocol that will
allow another validator to produce a block.

Albatross has some desirable features besides its low latency
and high throughput. It allows nodes to bootstrap quickly by
only requiring them to download all of the macro blocks and
the most recent micro blocks. It offers strong probabilistic
finality, with a certainty of 99.9% being reached in only
6 blocks. And honest clients can get instant confirmation
that their transaction will be accepted by directly asking for
receipts from the validators.

C. Enso

Enso [3] is a general-purpose virtual machine for
blockchains developed by Trinkler Software.

Blockchains can be seen as distributed virtual machines,
since they are designed to run a given application on a network
of heterogeneous, and possibly malicious, nodes. We can
represent a blockchain as a stack:

App data ≡ State
App logic ≡ STF

Consensus
Networking

Where STF is the state transition function. Note that the
application logic, also called the runtime, is embedded into
the state transition function, while the application data is
embedded in the state. For example, in the case of Bitcoin
the application logic is that of a ledger and the application
data is the set of all unspent transactions. This model works
well for most cases but it is cumbersome to program and fails
when it is necessary to update the application logic.

We take a different approach and have the state transition
function be a general-purpose virtual machine. Then, the
application logic and data can reside in the blockchain state:

App logic & data ≡ State
Virtual machine ≡ STF

Consensus
Networking

Enso is this virtual machine. Having a general-purpose
virtual machine speeds up development, since only the state
needs to be programmed, and allows for simpler and more
fine-grained updates, because the state can be changed with
simple extrinsics instead of forks.

Enso itself is a relatively simple virtual machine, inside of it
everything is either an object or an event. Objects are entities
composed of:

• ID: An unique identifier of the object. It can be any string.
• Code: A block of code containing functions that can be

called by other objects.
• Storage: A data structure containing arbitrary informa-

tion and that can be read and modified by the code.
While events are asynchronous function calls from one

object to another and always have the following information:
• priority: The priority of the event, used for the event

queue.

2



• ID_to: The ID of the object that will receive the event.
• function_call: The name of the function that will

be called.
• parameters: A list of parameters that will be passed

to the function.
The state of the blockchain is the set of all objects, and it

is these objects that will contain all the application logic and
data. Everything is an object.

The virtual machine itself is composed of just two compo-
nents: the event queue and the super object.

The event queue is, as the name indicates, a queue for
events. It is an ordinary priority queue and, when any event is
created, it is added to this queue. Events with a higher priority
go to the top of queue, while events with a lower priority go
to the bottom.

The super object is a special object that is unique and can
not be deleted or changed in any way. It is similar to the super
user in Linux systems, in that it has complete control over the
state. In fact, it is the only object that can change the ID,
code and storage of other objects. The super object has the
following interface:

• Create(ID, code, storage): Creates a new ob-
ject with the given ID, code and storage.

• Delete(ID): Deletes object with the given ID.
• Check(ID): Checks if any object exists with the given

ID and returns the answer.
• Request_object(ID): Returns the code and storage

of the object with the given ID.
• Change_ID(ID, new_ID): Changes the ID of the

object with the given ID to new_ID.
• Change_code(ID, new_code): Changes the code

of the object with the given ID to new code.
• Change_storage(ID, new_storage): Changes

the storage of the object with the given ID to
new storage.

• Set_input(ID): Sets the input object to the object
with given ID.

The input object is the object that is designated to receive
extrinsics. An extrinsic in Enso is just a event like any other,
but with the caveat that it must be sent to the input object.
Any object can be the input object, the only requirement is
that it designated as such by the super object.

A state transition in Enso looks like this:
1) Receive an ordered list of extrinsics.
2) Add the first extrinsic to the event queue.
3) The resulting event will be sent to the input object. The

input object then may create more events, that in turn
will also be processed and create more events, and so
forth, until no more events are created.

4) Add the next extrinsic to the event queue and keep
repeating steps 3 and 4 until there are no more extrinsics.

D. ACTUS

The Algorithmic Contract Types Unified Standards [4], or
ACTUS, is a standard developed by the ACTUS Financial

Research Foundation. It seeks to describe all possible financial
contracts as algorithmic patterns of cash flows between two
parties.

In ACTUS, any financial contract can be replicated as a
combination of simpler contracts, called contract types. These
contract types include basic financial contracts, like annuities
and futures, and more exotic ones, like perpetual bonds and
credit default swaps. In total there are 32 contract types, and
together they form a taxonomy of financial contracts.

The contract types themselves are defined in algorithmic
form. In other words, for each contract type there is a
set of rules that, given some input parameters and external
data, determine unambiguously the cash flows between the
two parties to the contract. This allows them to be easily
implemented in smart contracts. And, by combining different
contract types, we can create any imaginable financial contract
in algorithmic form.

There are five types of parameters that define a contract
type: attributes, variables, contract events, payoff function and
state transition function:

• Attributes are parameters that are static. They are defined
when the contract is created and then they never change.

• Variables, as the name indicates, are parameters that
are dynamic. At the time of the contract creation they
are initialized to a given value, but they may change
afterwards.

• Contract events are actions that cause a cash flow and/or
a change in the variables. They may be scheduled, for
example at the beginning of every month, or initiated by
an external object, for example by one of the parties.

• The payoff function takes the attributes, the current
variables and an event as inputs, and outputs a cash flow
obligation from one party to another. The state transition
function takes exactly the same inputs, but it outputs new
values for the variables. Together, these two functions
constitute the logic of the contract.

Contracts have two interfaces that enable it to interact with
other objects: the risk factor observer and the child contract
observer.

The risk factor observer allows the contract to request data
from an oracle object, such data can be, for example, price
information or interest rates.

The child contract observer allows one contract to observe
the attributes, variables or events of another contract. This
functionality is what makes it possible for several contract
types to be joined together into more complex financial
contracts.

Another useful characteristic of ACTUS contracts is that
the cash flows between both parties of a contract, called the
creator and the counterparty, can be tokenized. By this we
mean that it is possible for users to have fractional ownership
of a contract, thus it is perfectly possible to have the creator’s
or counterparty’s cash flows (both positive and negative) be
divided among several different users.

Tokenization also creates a simple way of transferring
ownership of a contract. This feature is optional for any

3



Fig. 1. The ACTUS taxonomy of financial contracts.

contract, since in some cases it may be undesirable, but when
activated, it makes it possible for contracts to be sold in
secondary markets.

E. Town Crier

Town Crier [5], developed by the Initiative for cryptocur-
rency and Contract (IC3), is an authenticated data feed system
for smart contracts, also known as an oracle. It acts as a bridge
between HTTPS-enabled websites and blockchains, and does
so by taking advantage of a trusted execution environment,
specifically the Intel SGX.

A trusted execution environment can be thought of as a
space inside the CPU that allows programs that run inside
it to be protected from other programs, the operating system
and even from some types of hardware attacks. This space
is called an enclave, and it is basically a black box inside
which programs are certain to be executed correctly and with
confidentiality.

An enclave can only use the CPU and the RAM by itself
and needs to rely on the operating system for file and network
access. However, by using public key cryptography, it can
establish secure connections over the internet.

Another useful feature of enclaves is that they can provide
a publicly verifiable proof that a given program was executed
correctly and produced a given output. Such a proof is called
an attestation.

In order to serve source-authenticated data to smart con-
tracts, the Town Crier system only needs a specific smart
contract, called the oracle, and a relaying server, called the
TC server.

The oracle contract acts as the front-end for the blockchain,
creating requests for data, verifying attestations from enclaves
and distributing rewards to servers that provide data.

The TC server has two components: the relay and the
enclave. The relay handles all the network traffic to and
from the enclave, since the enclave itself has no networking
capabilities. The enclave establishes HTTPS connections to
websites and produces attestations.

The process works as follows:
1) The oracle contract produces a request for data. It does

this by updating its state and signaling that it is ready
to receive data from a TC server.

2) The relay, who periodically watches the blockchain, sees
the data request and relays it to the enclave.

4



Fig. 2. The Town Crier system.

3) The enclave processes the request and initiates a HTTPS
connection to the requested website.

4) The relay handles the traffic between the enclave and
the website during the HTTPS session.

5) The enclave scrapes the website for the requested data
and produces an attestation that the scraping was done
correctly. Then, it sends the data and the attestation to
the oracle.

6) The relay forwards the data and attestation to the oracle.
7) The oracle, after verifying that the attestation is correct,

updates its state with the new data. Then, if appropriate,
it distributes a reward to the TC server.

8) At any point, other contracts can fetch data from the
oracle by requesting its more recent state.

Town Crier was recently acquired by Chainlink [6], a project
that provides decentralized oracles for a variety of blockchains.
Oracle contracts in Katal are updated by Chainlink nodes using
the Town Crier protocol.

F. Polkadot

Polkadot [7] is a heterogeneous multichain framework in-
troduced by Gavin Wood in 2016. It is a protocol that allows
blockchains to exchange information, but unlike internet mes-
saging protocols like TCP/IP, Polkadot also enforces the order
and the validity of the messages between the blockchains.

Polkadot is composed of a central blockchain, called the
relaychain, and a number of peripheral blockchains, called
parachains, that connect to it. Parachains may outsource their
consensus to the relaychain or have their own consensus al-
gorithm and validators. The relaychain, as the name indicates,
acts as a relay for messages between different parachains.

Connecting to Polkadot enables Katal to not only exchange
information with other parachains but also for other parachains
to transfer tokens to the Katal blockchain and vice-versa.

III. OVERVIEW

The Katal technology stack is illustrated in Figure 4.
Analyzing it we see that Substrate Core is at the bottom

and is used for networking, module swaps and other auxiliary

Fig. 3. Polkadot: relaychain and parachains

Fig. 4. Katal technology stack

services. Albatross and Enso are, respectively, the consensus
algorithm and the virtual machine, and they will be imple-
mented as modules in Substrate. Lastly, there is the Katal
runtime on top.

It is the runtime that enables Katal capabilities and so,
for the rest of this paper, we will focus mostly on it. Both
Albatross and Enso are explained in detail in two other papers
[1] [3].

The Katal runtime is composed of a set of objects and the
interactions among them. Broadly speaking, the objects can
be divided in two categories:

• Kernel objects: All the objects that are created at the
genesis block and during updates to the blockchain. These
are the objects that define the rules for how the runtime
works and are unique objects, meaning that there is only
one instance of each object type. An example of a kernel
object is the governance object, which handles updates
to the blockchain.

• User objects: All the objects that are created by the users.
Any user can create user objects from a predetermined
list of object templates. For example, there is an account
template and each instance of that template, created by
the users, is an account object.

For a full description of the Katal runtime it is enough
to outline all the kernel objects plus all the different object

5



templates. Let us begin with the kernel objects:

• Dock object: It serves as the point of entry for extrinsics
and is always the first object to be called, in other words
it is the input object. It parses each extrinsic, verifies
their signatures and then creates the events to the desired
objects.

• Authentication object: It maintains a list of the IDs of
all user objects and their corresponding authentication
methods. The dock object calls this object to verify the
signatures on transactions. Other objects may also call it
when they need authentication services.

• Schedule object: It enables periodic, or scheduled, calls
to other objects. Every block it receives from the dock
object the current time and block number and then
proceeds by calling any objects that are scheduled to be
called at that particular time.

• Instantiation object: It creates all user objects. Users can
call it to create a new user object from a list of object
templates. It maintains the list of object templates and
defines which parameters are allowed for the instantiation
of those templates.

• Native issuance object: It is a special instance of the
more general issuance template. It manages the native
token (XTL) by maintaining a list of all object IDs and
their corresponding balance. It also deals with transfer-
ring, minting and burning XTL tokens.

• Governance object: It implements whichever gover-
nance method is chosen to update the blockchain. No-
tably, it is the only object that possesses unrestricted
access to the super object, thus allowing it to modify
any part of the Katal runtime.

• Consensus object: It manages certain tasks related to
the consensus algorithm. Namely, it maintains a list
of validators and their staking deposits, applies slash
inherents, distributes block rewards, etc.

Besides these seven kernel objects, the Katal runtime is also
composed of the following four user object templates:

• Account object: It is the most basic object in the
runtime, being basically just an ID. Whenever an ac-
count is created, a corresponding entry is created in the
authentication object with the authentication method and
parameters chosen by the user.

• Issuance object: It creates and manages its own tokens.
It can be user-controlled or automated, is capable of
managing several different token types and supports both
fungible and non-fungible tokens.

• Oracle object: It maintains an external data feed by
serving as the interface for Town Crier servers. It creates
requests for data, validates the data authenticity and
distributes rewards to servers.

• Contract object: There are actually 32 different con-
tract templates, one for each ACTUS contract type. All
contract objects are capable of interacting with issuance
objects, to create cash flows, and with oracle objects, to
fetch data. It also maintains a list of all its owners, both

creators and counterparties, for tokenization purposes.
The above list gives a rough description of all the objects

but it does not shed much light on how they interact together.
Even though it is not possible to detail all possible interactions
in this paper, we will now discuss some of the most common
ones.

A. Transaction docking

All transactions pass first through the dock object. Any
transaction is just a ‘bundle’ of function calls to other objects,
and the dock object must first verify the validity of the
transaction before creating the corresponding events for those
function calls.

When the dock object receives a transaction it will first
check that it is well-formed. Then it will call the authentication
object to verify the signatures contained in the transaction. If,
and only if, all signatures are valid then the dock object will
create the requested events. Each of these events will include,
as part of their parameters, the IDs of everyone that signed
the transaction.

B. Token transfers

Like ERC-20 tokens in Ethereum [8], tokens in Katal are
managed by a single object. In other words, instead of every
account storing the balance of every token that it owns, for
each token there is a single object that stores the ID and
balance of every account that owns those tokens. These objects
we call issuance objects.

When an account wants to transfer some tokens to another
account, it just sends a request to the issuance object of that
token. The issuance object will then update its internal ledger
to reflect this change.

6



C. Schedule functions

It is useful to have functions that are started at predefined
times. For example, we may want an oracle that is updated
every minute. In order for this to happen, some object needs
to call the oracle object every minute, so that it can accept
updates to its state. That object is the schedule object.

Every block the dock object sends the current block number
and time to the schedule object. The schedule object has a list
of functions, IDs and conditions. Upon receiving the block
number and time, it goes through this list and, if any of the
conditions is satisfied, it triggers the corresponding function
at the corresponding ID.

D. Oracles and data feeds

Each oracle contract only maintains one specific data feed.
When they request an update, a Town Crier server can send
a transaction containing the update and potentially receive a
reward. Other objects can send a function call requesting data
from the oracle and it will respond back with the most recent
data in its state.

E. Template instantiation

Users can create new objects using the instantiation object.
Through the dock object, a user can request the instantiation
object to create a new object from a list of templates. The
instantiation object then sends the necessary events to the
super object and also, in some cases, to the authentication
and schedule objects.

F. Governance

The main purpose of the governance object is to control
who can have unrestricted access to the state, and especially
to the super object. It will receive calls from the dock object
and, given its internal logic, it will decide if the calls are to
be forwarded or not.

IV. SPECIFICATION

In this section we will detail the runtime of Katal, beginning
by giving some general remarks and then by describing the
kernel and user objects. Our focus will be on the objects
interface and function.

A. General

1) Reserved namespace: There is a reserved namespace for
the kernel objects. The namespace consists of all the IDs that
begin with ’XTL’. For example, the dock object will have the
name ’XTL Dock’.

User objects are not allowed to have an ID that begins with
’XTL’. This is enforced by the instantiation object, who will
not accept any requests to create an user object with an ID in
that namespace.

2) Transactions: A transaction is a bundle of function calls
to objects. Users can join several different function calls into
the same transaction and sign them. The function calls are only
forwarded by the dock object if all the signatures are valid. A
transaction has the following format:

• [ID]: A list of the IDs that are authorizing this transac-
tion.

• [Function calls]: A list of the desired function calls.
• Window: Determines the time window in which this

transaction is valid. For example, if the window is
[2000, 2050] then the transaction will only be accepted
between the block number 2000 and the block number
2050.

• Nonce: A long integer chosen by the users. Together with
the validity it prevents replay attacks.

• [Signature]: A list of the signatures for this transaction,
one for each ID.

Where [.] represents a list. A transaction can also be thought
of as a wrapper to a series of function calls. These function
calls have the following format:

• ID_to: The ID of the destination object.

7



• call_function: The function to be called at the
destination object.

• [user_parameters]: A list of user-provided param-
eters to be passed to the function.

3) Origin ID: All function calls, except the extrinsics fed
into the dock object, will include in their parameters the field
ID_from which is the ID of the object that originated the
function call.

Adding this information to every function call allows objects
to have functions that can only be called by certain objects.
For example:

• Internal functions that can only be called by other func-
tions in the same object,

• Kernel functions that can only be called by kernel objects,
• User-forbidden functions which are functions that do not

accept calls from the dock object, thus they cannot be
called by users,

• User-only functions which are functions that are meant to
be called by users and as a result only accept calls from
the dock object.

4) Extrinsics order: A block is composed of several extrin-
sics, either transactions or inherents, and they are fed into the
dock object into a specific order:

• Timestamp:={time, block number}: An inher-
ent that contains timing information. It is forwarded to
the schedule object.

• Slash:={ID}: An inherent that is used to slash the
stake of a misbehaving validator. It is forwarded to the
consensus object.

• Seed:={seed}: An inherent that contains a random
seed used to select a new validator set. It is forwarded to
the consensus object only in macro blocks, otherwise it
is ignored.

• Transactions:={[transactions]}: The list of
transactions. They are only sent in micro blocks.

• Reward:={ID}: An inherent containing the ID to
which the block reward is paid to. It is forwarded to the
consensus object.

B. Kernel objects

1) Dock: The dock object acts as the point of entry for
extrinsics and its interface only has one function:

• input(extrinsic): Parses the extrinsic and veri-
fies its validity. If it is a transaction then it calls the
authorization object to verify the signatures and, if the
all signatures are valid, then forwards the function calls
to the correct objects.

For each function call in the extrinsic a new event is
created by the dock object with the format e(priority,
ID_to, call_function, ID_from, [auth_ID],
[user_parameters]), where [auth_ID] is the list of
every ID that signed the transaction.

2) Authentication: The authentication object verifies au-
thentication proofs provided by the users. To do so it maintains

the following internal key-value store, called the authentica-
tion registry:

Key Value
ID (Method, [Parameters])

Where method is any authentication method supported by
the authentication object. It can be a signature scheme like
ECDSA, Schnorr or BLS, or a multisignature scheme, or a
hash-lock, or even a zero-knowledge proof system. The pa-
rameters are any information necessary to authenticate proofs.
For example, in the case of ECDSA the parameters would be
the public key.

The next functions form the interface of the authentication
object:

• verify([message, ID, proof]): Goes through
the list verifying that each proof is a valid authentication
of the message by the corresponding ID. Accepts calls
from any object.

• method(message, proof, parameters):
General function type for authentication. There is one
instance for each different authentication method. It is
an internal function, and as such it accepts only calls
from the authentication object.

• add_key(ID, method, parameters): Adds the
ID with given method and parameters to the authentica-
tion registry. Does not accept calls from the dock object.

• change_key([auth_ID], ID, method,
parameters): Changes the authentication method of
the object with given ID. Accepts calls from any object,
but if the call originates from the dock object, it will
only be accepted if ID ∈ [auth_ID].

• delete_key([auth_ID], ID): Deletes the entry
in the authentication registry with given ID. Accepts calls
from any object, but if the call originates from the dock
object, it will only be accepted if ID ∈ [auth_ID].

3) Schedule: The schedule object serves to make function
calls to other objects at regular intervals. To achieve this,
it maintains an internal key-value store called the schedule
registry:

Key Val";"""date"",""2019-07-04T01:32:26Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2019-07-04T01:32:26Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016) kpathsea version 6.2.2""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2019-07-04T01:32:26Z""
""created"",""2019-07-04T01:32:26Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-07-04T01:32:26Z""
""resourceName"",""1903.01600""
""Author"",""""
""producer"",""pdfTeX-1.40.17""
""pdf:docinfo:producer"",""pdfTeX-1.40.17""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2019-07-04T01:32:26Z""
""Last-Modified"",""2019-07-04T01:32:26Z""
""dcterms:modified"",""2019-07-04T01:32:26Z""
""title"",""""
""Last-Save-Date"",""2019-07-04T01:32:26Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2019-07-04T01:32:26Z""
""meta:save-date"",""2019-07-04T01:32:26Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016) kpathsea version 6.2.2""
""Content-Length"",""3657708""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""13""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""3572"",""4165"",""4598"",""1880"",""2793"",""3676"",""2716"",""4123"",""4188"",""4133"",""3339"",""2802"",""2656""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-07-04T01:32:26Z""
";https://scholar.google.com/scholar?start=540&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094541-659;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Fraud Detection in Medical Insurance Claim with Privacy Preserving Data Publishing in TLS-N Using Blockchain;T Mohan, K Praveen ; International Conference on Advances in Computing …, 2019  Springer;;"… The solution proposed in the paper solves the TLS-N content hiding attack using generalization

of privacy preserving data publishing scheme and incorporating this on a blockchain oracle helps

provide immutability to the content related to a policy holder. References …";Autres articles;;null;;;;https://scholar.google.com/scholar?start=470&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094649-1116;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[HTML][HTML] The hazards of misusing the smart contract: An AHP approach to its risk;R Luciano ; Journal of Information Security, 2019  scirp.org;;"… lack of consensus when writing the code, inadequate verification and testing of smart contracts

prior to deploy them in the blockchain, the complexity … Reference [3] discussed the use of oracles

to overcome problems such as disputes or making the oracle represent the …";Cité 3 fois;Les 4 versions;[HTML] scirp.org;https://www.scirp.org/html/2-7800557_90112.htm;"


  

   [image: SCIRP LOGO][image: ACCESS LOGO]

  
    	Home
	Journals
	Books
	Conferences
	News
	About Us
	Jobs


  











  
    
      
       Journal of Information Security
        Vol.10 No.01(2019), Article ID:90112,20 pages 

        10.4236/jis.2019.101002 

      The Hazards of Misusing the Smart Contract: An AHP Approach to Its Risk

      Romulo Luciano 

    

    
      ●Abstract

      ●Full-Text PDF

      ●Full-Text HTML

      ●Full-Text ePUB

      ●Linked References

      ●How to Cite this Article

    

  

  Department of Post-Graduation and Research in Administration, IBMEC, Rio de Janeiro, Brazil

  [image: ]

  Copyright Š 2019 by author(s) and Scientific Research Publishing Inc.

  This work is licensed under the Creative Commons Attribution International License (CC BY 4.0).

  http://creativecommons.org/licenses/by/4.0/

  [image: ][image: ]

  [image: ]

  Received: December 14, 2018; Accepted: January 20, 2019; Published: January 23, 2019

  










ABSTRACT

This article explores four critical groups of systematic risk embedded in smart contract employment using the analytic hierarchy process (AHP). The four principal risk analysis groups include: 1) transparency in the light of corporate governance 2) IT security 3) contract management automation and 4) legality. The AHP assists both decision-makers and stakeholders alike in the evaluation process essential for identifying potential technological constraints posed within a permissioned blockchain environment using peer-to-peer format in the absence of digital currency. Based upon critical assessment, the AHP methodology enables pairwise comparisons among different features and consequently increases the knowledge regarding these attributes in light of the software’s risk assessment.

Keywords:

AHP, Blockchain, Smart Contract, Software Project Management

[image: ]

1. Introduction

The smart contract has received attention due to both its characteristics and numerous application possibilities, offering users potential cost savings in a variety of conventional commercial aspects. The most advantageous benefits include reducing legal and transactional costs as well as increasing the intangible trust value among dispersed entities. While the technology is developed on the blockchain platform and computer codes have been intensely investigated by technologists worldwide, methodical risks are manifest due the characteristics of the smart contract. The ensuing body of research provides specific information regarding the hazards of misusing the smart contract from an analytic hierarchy process (AHP) risk assessment perspective. The following is comprised of five sections concerned with the identification and exploration of four distinct areas of risk confronting private smart contract utilization using basic AHP methodology. The objective of this body of research is to provide decision makers with a comparison model in order to assess the identified risks associated with the smart contract. The author will begin with a review of emerging and associated literature in conjunction with exploratory research to provide an understanding of the interrelationship between the smart contract and blockchain, and more importantly, how that relationship impacts risk management in a software project. The second section of this paper will provide a definition of risk and its management within a software project as well as the methodology used to identify the four main risk clusters pertaining to the smart contract. The third section will introduce the AHP method including the elemental framework comprising the AHP followed by an application of the AHP with regards to the four critical groups of systematic risk. Conclusively, the final section will provide a summation and discussion of the author’s findings.

2. The Literature on Smart Contract and Software Risk Management

2.1. The Smart Contract

In 1994, Nicholas Szabo became the first author to mention the term smart contract [1] . The smart contract was developed to translate conventional paper-based contracts into secure self-executing digital protocols. Later, in 2008, Bitcoin, was developed using blockchain by Satoshi Nakamoto and became the first digital currency. Its technical characteristics were determined, defined, and subsequently deployed in the public market with reliability. As a result, the bitcoin became synonymous with cryptocurrency; offering users anonymity, transactional transparency, and tamper-proof peer-to-peer operations utilizing hash functions and an inherent value maintained on an open network without a central issuer or bank [2] . This system is not infallible. Adding a new block or transaction in the proof-of-work blockchain to improve the trustworthiness of the system requires caution.

As one of the originating authors of Ethereum, [3] explains the complex interrelationship among bitcoin, blockchain, and smart contract components, as an open platform based upon blockchain technology, enabling software developers to create a computer code that replaces traditional paper-based contracts. The computer code written for the blockchain is immutable and handles the consensus agreement among parties. This code is called a smart contract which is a self-executing code that meets the consensus terms and conditions customarily established in current contracts. It enforces the rules and automates contract management. These terms and conditions may include the payment process between parties, transference of rights and/or goods among participants, or a decentralized autonomous application objecting to eliminate intermediary services such as regulatory compliance and systematic voting. All these transactions are enforced and permissible if predefined conditions written as program code are satisfied. The smart contract can be programmed and deployed on the private blockchain. Currently, there are consortia of private organizations investigating and generating program codes for smart contracts as well as other blockchain applications such as Hyperledger and R3 entrepreneurial ventures in addition to the numerous technology companies that create customized smart contracts.

The permissioned private blockchain and smart contracts have characteristics and risks distinct from the public network blockchain which does not require permission. The main difference delineating a public blockchain is the trusted participants that are allowed on the network [4] . The permissioned private blockchain demands an invitation that requires authorization by either the network administrator or by a set of rules embedded in the system. Additionally, it specifies restrictions regarding who can join the network, and which transactions they may take part in. The access control mechanism can vary. For example, existing members may select future participants, issue licenses for participation via regulatory authority, or even make the decisions as a preexisting group instead. Once an organization has joined the network, it may play a role in maintaining the blockchain in a decentralized manner. Conversely, having a person, group of persons, or a set of rules acting as network administrator on a permissioned private blockchain and smart contract, naturally make it vulnerable for cyberattacks [4] .

In essence, the smart contract is a potentially disruptive innovative tool requiring a thorough understanding of both the benefits and potential harm implementation may render a business.

If smart contract employment is decided, identifying pertinent risks and monitoring their development and/or existence, becomes a matter of constant vigilance due to the clear research gap related to smart contract technology.

The foundation of this study concerns the organizations aspiring for consensus and collaboration in both the exploration and application of a private smart contract. The impetus of this study is a permissioned private blockchain network in conjunction with a smart contract developed for private trade in a peer-to-peer manner free from the use of a digital currency. The purpose for this is to attain a distributed reproduction of auditable transaction logs that are shared among the participants of interest. For clarity, the smart contract examined in this study takes into consideration that organizations and government that are involved in this process are ruled by the same set of applicable laws as shown in Figure 1.

2.2. Software Risk Management

Risk exists in all matters, and it is not different in business. Among several definitions of risk, [5] defines risk “as the chance of loss or the perils to the subject matter of an insurance contract.” Applying the same definition to information technology, [6] wrote about software risk management, proposing a framework that began with the planning phase and extended to the operational function.


  [image: ]

  [bookmark: f1]Figure 1. Business environment framework proposed by the author.



Reference [6] objected to prevent software risks in order to safeguard against costly operations and limit frustration to users and other stakeholders. Reference [6] split the risk management into two groups: risk assessment and risk control. The risk assessment is subdivided into three groups as well as the risk control. The risk assessment subgroups are: 1) risk identification, 2) risk analysis, and 3) risk prioritization. The risk control subgroups are: 1) risk management planning, 2) risk resolution, and 3) risk monitoring. Taken together, it is a complete set of checks that a planning team should focus on to minimize risk prior to implementing new software. Another framework developed by [7] for the National Institute of Standards and Technology highlights the importance of information technology risk management. It is a guideline which comprises three processes: risk assessment, risk mitigation, and evaluation assessment. It contains [6] ’s framework as a subset.

Corroborating, [8] went further than [6] , mentioning that risk management of new software should assess functionality, performance, resource use, safety, reliability, versatility, ease of learning, ease of use, and ease of modification.

Controversial but elucidating, the Chaos Report (1994) issued by [9] , showed a high failure of IT application development projects and costliness. The survey interviewed 365 respondents among different industry sizes. Although the methodology applied in the studies and survey was considered debatable, as [10] mentioned, it made the academy and entrepreneurs aware of such bad practices and possibly served to propose improvements in practice and theory afterward. One of the findings in the [9] was the incomplete requirements and specifications for such software development and applicability, which also follows the [8] study.

Additionally, [11] mentioned in his study that most aspects of failure in software projects are foreseeable and preventable. Among the most common factors of IT projects failures, two are noteworthy in this study: unmanaged risks and use of immature technology. The smart contract is an immature technology at the time this study was prepared, and this study attempts to identify the main group of risks.

Furthermore, [12] also wrote about risk management in software projects. He mentioned that one of the most common subjects in software projects found in the literature regarding risk management is risk identification, which might impact on the success of the plan.

In addition, [13] made a comparison among the authors who published studies regarding risk management in software projects. The study was based on the steps described by the Project Management Body of Knowledge (PMBoK) Guide from 2008. One step common to all authors is risk identification, as observed in this literature review.

Enriching the literature, [14] approached the general risk assessment in distributed software development. The aspects identified in the software risk management literature discussed by the authors were grouped as according to the Leavitt organizational model, i.e., task, structure, actors, and technology, which differs from the proposal of this research study. However, it is valuable to highlight the aspects which can be extended to smart contract software. They are the lack of trust in human skills and behavior, lack of security, complexity of code, and software quality.

Thus far, an attempt has been made to clarify that risk identification constitutes a precursor to software risk management. Hence, this study intends to help the decision-maker to fulfill part of the risk management process by identifying the main group of private smart contract risks and evaluating them utilizing the AHP method with the help of expert judgment.

2.3. Risks and Attributes of a Private Smart Contract

As aforementioned, the private smart contracts deployed on the permissioned private blockchain are distinguished by their characteristics and risks when compared to the permissionless blockchain and public network. One of the attributes of the private blockchain and the smart contract is to have a network administrator, either a person, a group of persons or a set of rules, which makes it the target for cyberattacks [4] .

Another important feature of the smart contract is the immutability of code [15] . Thus, it does not allow any part from singly changing the code or terms written. It prevents harmful cyberattacks to the code because the network administrator would be alerted about the possible invasion trying to change the code. As an additional attribute, the transactions are traceable and permanently recorded in the blockchain [1] .

Reference [16] performed a screening of academic papers and identified four main issues regarding the public smart contract. They are codifying issues, security issues, privacy issues, and performance issues. In addition, the study proposes solutions for each issue. These issues can be extended to the permissioned private smart contract with a fewer minor differences. Codifying issues can be summarized as the difficulty to write or modify the smart contract, which is intrinsically related to the human skills that are necessary to translate the terms and conditions of a regular paper-based contract to programming code. The security issue is the vulnerability of the code as such. If it has breaches, then cyberattacks can invade the network or suspend the network operability. The privacy issue is not relevant to the focus of this study because the transparency is akin to the permissioned private blockchain and smart contract, in contrast to the public environment. The unplanned display of data to the public concerns IT security.

The smart contract is encrypted before being deployed on the private blockchain. The performance issues mentioned by [16] are not pertinent since the private smart contract object of this study is unique, and it would run in the private blockchain, i.e., one smart contract to be deployed and run. Reference [16] mentioned performance issues when several smart contracts are deployed and are run on the public blockchain, which might affect the execution time of each transaction, as well as the reference by [1] of the throughput limits in the Ethereum blockchain environment.

Regarding the security of the blockchain system and a smart contract written on Ethereum, [17] performed a systematic inspection regarding its security, which was also addressed by [18] . They explore the literature about blockchain and smart contracts, highlighting the vulnerability observed after the cyberattacks on smart contracts developed using the Ethereum platform. In addition, they propose solutions to minimize the success probability of an attack.

The controversial misuse of the hard fork operation is less appropriate to the private smart contract object of this study [19] . The hard fork became a well-known operation, when in 2016, $60 million was hacked through the public Ethereum blockchain due to a vulnerability in the decentralized autonomous organization deployed on the Ethereum blockchain [20] . Using the soft fork and then a hard fork, it was possible to identify where the crypto money was and recover the stolen digital currency to its rightful owners. However, that created two blockchains: 1) with the fork, Ethereum, and 2) without the fork, Ethereum classic. At that time, it created reputational issues on blockchain usage regarding the security issues and consequently, the risk of financial loss. However, if a similar operation is required in a private consortium, the decision is made through a consensus of the stakeholders [19] .

Reference [4] points out the technological challenges in smart contracts without differentiating the permissioned private and the public smart contract. The lack of maturity issue highlighted in the study as well as cybersecurity and governance are common issues to private and public blockchains and smart contracts. Additionally, the legal and regulatory challenges mentioned are different from the public to the private environment since on the private network, the framework of the code would be created in consensus with all stakeholders involved in the program code process, including the government. For instance, the UK Government Office for Science [21] clearly recommends the facilitation of research and use of blockchain and smart contracts and highlights the potential benefits and possible synergies between government and private organizations such as increasing transparency and corporate governance and avoiding frauds in the system. However, it also indicates concerns regarding the infancy of a smart contract. The laws chosen for application to a contract are dependent on several factors, but that discussion goes beyond the objective of this study.

Regarding the contract that should be translated to code, if a contract does not encompass all rules and conditions, it might lead to transaction costs, conflict, or even worse, the ruin of the program if a consensus is not established [1] [22] . Drawing attention to the program code’s immutability is important. Despite the code’s immutability, another program code can replace the program code without significant interference to the process where the software has been deployed and run, or the code can be altered from what it was programmed for [1] [3] .

Regarding the legal perspective, [23] analyzed the legal validity, interpretation, and lifecycle of contracts in either imperative or declarative smart contracts. Imperative language is most commonly used in smart contracts, which “the programmer writes an explicit sequence of steps to be executed to produce the intended result. The programmer has to write what has to be done and how to perform it” [23] . On the other hand, the authors present the alternative declarative language, arguing that it is a more feasible representation of natural language which “the programmer does not have to write explicitly the sequence of steps to specify what has to be done. The programmer only describes what has to be done, without specifying how to do it” [23] . Regardless of the language used, what is essential for this study is to identify the main risks. In addition, the main risks are related to the lack of consensus when writing the code, inadequate verification and testing of smart contracts prior to deploy them in the blockchain, the complexity of writing the smart contract code, the immutability of the code, and the termination of the smart contract.

As mentioned by [22] , the smart contracts can be tailored to have flexibility, i.e., have a human factor to judge a specific transaction before its execution, thus classifying the smart contract as semi automated. Reference [3] discussed the use of oracles to overcome problems such as disputes or making the oracle represent the jurors to determine whether certain contractual terms have been met prior to code execution. Thus, the oracle can provide flexibility, but it can compromise the speed of the transaction. As explained by [24] , every person or organization can take the liberty to infringe on any contractual conditions. They might be legally responsible for that act, but the oracle can be implemented to minimize the impact of such possibilities and reduce the time to resolve a conflict. Using the previously established framework of existing law and terms, the oracle can settle disputes among parties. To corroborate, [25] cited the risks between common law and civil jurisdiction and the smart contracts, along with other risks such as security, in light of cyber attack risks and scalability. Therefore, it is important to emphasize the framework proposed for this study as per Figure 1, where all participants are enclosed under the same set of law and rules. In addition, the object of this study is the private smart contract deployed on the permissioned private blockchain network, without using a digital currency and where the stakeholders are aiming for a consensus agreement.

2.4. Research Gap

The research work calls for conducting the process of risk identification and analysis on smart contracts deployed on the permissioned private blockchain network for private trade. The topic of assessing the smart contract risks in the literature is still not recognized from this basis [16] ; hence, it is considered as a gap in smart contract matters. Furthermore, grouping the main smart contracts' attributes based on their meaning, i.e., to facilitate the risk identification and subsequently, to perform a smart contract attributes’ risk analysis, is prudent in software project management [12] , and it can be considered a gap in the emergent literature of private smart contracts.

In this context, therefore, a two-phase methodology has been proposed and utilized to meet the gaps mentioned above. The first phase is to group the most common smart contracts’ attributes based on their meaning after a review of smart contracts in the literature and resources. The second phase is the analysis of identified risks with expert judgment, with the intention of ranking them for determining their relative areas of concern under uncertain conditions by using the AHP approach.

2.5. Methodology

This research work was performed between December 2017 and March 2018 utilizing the same systematic mapping study used in current research topics regarding smart contracts described by [16] , which was previously successfully used by [26] for mapping studies in software engineering, as shown in Figure 2.

The search exercise was carried out with queries in ProQuest, Google Scholar, Elsevier, ScienceDirect, and Emerald Insight databases, focusing on quality papers published in conferences, journals, and workshops. The keywords used in the search were blockchain and smart contract, separated and in combination, using the connectors and/or, without excluding the books. Moreover, the search included the words: risk assessment, AHP, software risk management, and project management on the same databases. Additionally, based on the exclusion criteria performed by [16] , the author excluded pieces of literature without having the full text available, articles, newsletters, and gray literature.

There is a lack of research on the subject that is associated with risk assessment; therefore, this study is classified as exploratory research [27] .

To answer the research questions of which risks are intrinsic to private smart contracts and if they can be grouped, the data collection of smart contract characteristics was carried out based on the emergent literature review and interviews with specialists. The attempt was to group the repeated patterns identified


  [image: ]

  [bookmark: f2]Figure 2. Steps of systematic mapping study by [26] .



in the literature and to group them in a significant set. Later, confirmation of the relevance of the proposed four groups by the experts of that phenomenon was conducted during an interview. Thus, an effort was made to avoid the researcher’s bias and to confirm the concepts, based on the grounded theory research procedure as described by [28] and corroborated by [29] . The caution taken when grouping the attributes into four significant clusters is a tentative approach to building the information concerning the private smart contracts’ risks and to providing a plausible understanding. Nevertheless, a criticism may concern the extent, which cannot be considered exhaustive; however, this research study does not intend to be complete but rather serve as an initial approach to this subject.

The solution methodology applied in this research study is displayed in Figure 3.

As seen from the preceding chapters, the literature presents characteristics of the smart contract. To recapitulate and to structure them, the characteristics are organized in Table 1.

The software risk management and the features identified in Table 1 are not part of this study as such, but these characteristics are mentioned in the smart contract literature review and serve as premises to evaluate any software. The literature also highlights the importance of these characteristics when performing a risk identification of specific features that can impact one or more groups of risks.

A decision-making approach should have a consensus-building approach, and it should be natural to our intuition and general thinking. For simplification purposes, grouping the risk characteristics of smart contracts mentioned in Table 1 is suggested, narrowing them down to the four main sets, as shown in Table 2, with their respective meaning and source.

As observed, there are pieces of evidence that indicate that attributes of the smart contract can be set up in four main clusters in order to concentrate the software risk analysis. Consequently, the use of AHP was selected to provide a methodology for pairwise comparison of the aspects identified, which can guide the adoption of decisions. The AHP has been used in different fields such as decision-making in construction management [30] , health-safety and environmental risk assessment of refineries [31] , safety risk assessment [32] , project risk assessment [33] as well as other applications [34] .


  [image: ]

  [bookmark: f3]Figure 3. The flowchart of the research.




   [image: ]

  [bookmark: t1]Table 1. Smart contract’s feature within respective categories, summarized risk description, and source.




   [image: ]

  [bookmark: t2]Table 2. Defining private smart contract’s risks with their meaning and with sources.



3. The Analytical Hierarchy Process―AHP

AHP Method

The AHP developed by [35] is an effective multicriteria decision analysis methodology. By reducing complex decisions to a series of pairwise comparisons and then arranging the results, the AHP helps to capture both objective and subjective aspects to provide support to decision-makers. The AHP involves a relative judgment when making the pairwise comparison, and thus, the result has a relative form depending on the expert judgment and the business environment. It hierarchizes the elements in a primary way so that elements at the same level are of a similar order of scale and must be capable of being correlated to some or all elements at the next higher level. A typical hierarchy has a top level that reflects the overall objective of the decision problem. At the intermediate level, it shows the elements affecting the top-level objective. Similarly, at the lowest level, it encompasses the decision choices. This type of hierarchy provides a clear and simple diagram of all the aspects affecting the decision and their relations. At that point, the prioritization procedure commences, determining the relative importance of the element in each level of the hierarchy. Elements in each level are pairwise compared to their importance in making the decision under consideration. The AHP starts creating a pairwise comparison square matrix A of order
  
    
       n 
       × 
       n 
       
    
  
  whose elements represent the relative importance of an element i over an element j. These elements that denominate
  
    
      
         a 
        
           i 
           j 
        
      
    
  
  are represented by the ratio
  
    
      
        
          
             w 
             i 
          
        
         / 
        
          
             w 
             j 
          
        
      
    
  
  , where
  
    
      
         ( 
        
          
             w 
             1 
          
           , 
          
             w 
             2 
          
           , 
           ⋯ 
           , 
          
             w 
             n 
          
        
         ) 
      
    
  
  are the positive numerical entries which reflect the judgments. The elements
  
    
      
         a 
        
           i 
           j 
        
      
    
  
  of the matrix
  
    
      
         A 
        
           i 
           j 
        
      
    
  
  shall have the following condition according to Equation (1):


  
    
      
         a 
        
           i 
           j 
        
      
       = 
      
         1 
         / 
        
          
             a 
            
               j 
               i 
            
          
        
      
    
  
  is the generic element of the reciprocal positive matrix
  
    
      
         A 
        
           i 
           j 
        
      
    
  
  (1)Additionally, the matrix
  
    
      
         A 
        
           i 
           j 
        
      
    
  
  shall follow the condition (2) to be considered consistent.


  
    
      
         a 
        
           i 
           j 
        
      
       = 
      
        
          
             a 
            
               i 
               k 
            
          
        
         / 
        
          
             a 
            
               j 
               k 
            
          
        
      
    
  
  , where
  
    
      
         a 
        
           i 
           j 
        
      
       > 
       0 
    
  
  and
  
    
       i 
       , 
       j 
       , 
       k 
       = 
       1 
       , 
       ⋯ 
       , 
       n 
    
  
  (2)

The judgment scale of numbers used in AHP is from 1 to 9 [35] , and it helps the decision-maker to verbally express in a natural and intuitive way the intensity of the importance between every two elements as: equally important, moderately important, strongly important, very strongly important or extremely important, as well as allowing transition between these expression words.

Having the comparison matrix, it is possible to obtain a priority vector of a set of alternatives, such that n is the number of elements to be compared,
  
    
      
         Îť 
        
           max 
        
      
    
  
  is the priority vector of matrix A, and w is the vector of priorities, where
  
    
      
         Îť 
        
           max 
        
      
       = 
       n 
    
  
  and
  
    
      
         a 
        
           i 
           j 
        
      
       = 
      
        
          
             w 
             i 
          
        
         / 
        
          
             w 
             j 
          
        
      
    
  
  if the choices made by the decision-maker are consistent. This being so, the vector must be found to satisfy Equation (2), and by Equation (3), the priority vector is obtained.

After forming the comparison matrices, the process moves to the phase of deriving relative weights for the various elements. The relative weights of the elements of each level with respect to an element in the adjacent upper level are computed as the components of the normalized eigenvector associated with the largest eigenvalue of their comparison matrix. The composite weights of the decision alternatives are then determined by aggregating the weights through the hierarchy. This is accomplished by following a path from the top of the hierarchy to each alternative at the lowest level and multiplying the weights along each segment of the path. The outcome of this aggregation is a normalized vector of the overall weights of the options. The mathematical basis for determining the weights has been established.

The rank reversal phenomenon is debatable. The criticism has been extensively discussed by many authors such as [36] and [37] but a solution for this limitation is not exhausted yet. The rank reversal phenomenon's criticisms are based on";"""dc.publisher"",""Scientific Research Publishing""
""keywords"",""AHP, Blockchain, Smart Contract, Software Project Management"",
""AHP, Blockchain, Smart Contract, Software Project Management""
""citation_journal_title"",""Journal of Information Security""
""language"",""en""
""prism.number"",""01""
""prism.issnOnline"",""2153-1242""
""dc:title"",""The Hazards of Misusing the Smart Contract: An AHP Approach to Its Risk""
""Content-Encoding"",""UTF-8""
""citation_pdf_url"",""http://www.scirp.org/journal/PaperDownload.aspx?paperID=90112""
""robots"",""all""
""MSSmartTagsPreventParsing"",""True""
""resourceName"",""2-7800557_90112.htm""
""citation_abstract_html_url"",""http://www.scirp.org/journal/PaperInformation.aspx?PaperID=90112&#abstract""
""dc.date"",""2019-01-23""
""prism.volume"",""10""
""citation_doi"",""10.4236/jis.2019.101002""
""prism.publicationName"",""Journal of Information Security""
""dc.title"",""The Hazards of Misusing the Smart Contract: An AHP Approach to Its Risk""
""Author"",""Scientific Research Publishing""
""citation_volume"",""10""
""dc.language"",""en""
""citation_issnPrint"",""2153-1234""
""citation_title"",""The Hazards of Misusing the Smart Contract: An AHP Approach to Its Risk""
""citation_year"",""2019""
""citation_publisher"",""Scientific Research Publishing""
""dc.format"",""text/html""
""description"",""This article explores four critical groups of systematic risk embedded in smart contract employment using the analytic hierarchy process (AHP). The four principal risk analysis groups include: 1) transparency in the light of corporate governance 2) IT security 3) contract management automation and 4) legality. The AHP assists both decision-makers and stakeholders alike in the evaluation process essential for identifying potential technological constraints posed within a permissioned blockchain environment using peer-to-peer format in the absence of digital currency. Based upon critical assessment, the AHP methodology enables pairwise comparisons among different features and consequently increases the knowledge regarding these attributes in light of the software’s risk assessment."",""This article explores four critical groups of systematic risk embedded in smart contract employment using the analytic hierarchy process (AHP). The four principal risk analysis groups include: 1) transparency in the light of corporate governance 2) IT security 3) contract management automation and 4) legality. The AHP assists both decision-makers and stakeholders alike in the evaluation process essential for identifying potential technological constraints posed within a permissioned blockchain environment using peer-to-peer format in the absence of digital currency. Based upon critical assessment, the AHP methodology enables pairwise comparisons among different features and consequently increases the knowledge regarding these attributes in light of the software’s risk assessment.""
""citation_date"",""2019-01-23""
""title"",""The Hazards of Misusing the Smart Contract: An AHP Approach to Its Risk"",""The Hazards of Misusing the Smart Contract: An AHP Approach to Its Risk""
""citation_issnOnline"",""2153-1242""
""dc.source"",""Journal of Information Security""
""dc.type"",""Articles""
""MSThemeCompatible"",""Yes""
""dc.creator"",""Romulo Luciano""
""citation_fulltext_html_url"",""//file.scirp.org/Html/2-7800557_90112.htm""
""Content-Type-Hint"",""text/html; charset=utf-8""
""prism.publicationDate"",""2019-01-23""
""Content-Length"",""87556""
""Content-Type"",""text/html; charset=UTF-8""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""dc.description"",""This article explores four critical groups of systematic risk embedded in smart contract employment using the analytic hierarchy process (AHP). The four principal risk analysis groups include: 1) transparency in the light of corporate governance 2) IT security 3) contract management automation and 4) legality. The AHP assists both decision-makers and stakeholders alike in the evaluation process essential for identifying potential technological constraints posed within a permissioned blockchain environment using peer-to-peer format in the absence of digital currency. Based upon critical assessment, the AHP methodology enables pairwise comparisons among different features and consequently increases the knowledge regarding these attributes in light of the software’s risk assessment.""
""citation_abstract"",""This article explores four critical groups of systematic risk embedded in smart contract employment using the analytic hierarchy process (AHP). The four principal risk analysis groups include: 1) transparency in the light of corporate governance 2) IT security 3) contract management automation and 4) legality. The AHP assists both decision-makers and stakeholders alike in the evaluation process essential for identifying potential technological constraints posed within a permissioned blockchain environment using peer-to-peer format in the absence of digital currency. Based upon critical assessment, the AHP methodology enables pairwise comparisons among different features and consequently increases the knowledge regarding these attributes in light of the software’s risk assessment.""
""prism.doi"",""10.4236/jis.2019.101002""
""dcterms.issued"",""2019-01-23""
""prism.issnPrint"",""2153-1234""
""citation_authors"",""Romulo Luciano""
""X-UA-Compatible"",""IE=EmulateIE7""
""prism.startingPage"",""25""
""viewport"",""width=974px""
""prism.section"",""Articles""
""dc.identifier"",""doi:10.4236/jis.2019.101002""
";https://scholar.google.com/scholar?start=930&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094642-1083;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;(R) CCA Secure Updatable Encryption with Integrity Protection;M Klooß, A Lehmann, A Rupp ; … on the Theory and Applications of …, 2019  Springer;;"… (CRYPTO'13) and Lehmann and Tackmann (EUROCRYPT'18) only achieve CPA security and

provide no integrity … will only proceed when the input ciphertext is “valid” (which will become clear

in the oracle definitions given … For incorrect inputs, the oracles return \(\mathtt {invalid …";Cité 11 fois;;null;;;;https://scholar.google.com/scholar?start=900&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094555-715;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Validade e eficácia dos “testamentos inteligentes” via tecnologia Blockchain;LSM Rocha, FF Gomes, TCM Mafra ; Scientia Iuris  uel.br;;"… Validade E Eficácia Dos “Testamentos Inteligentes” Via Tecnologia Blockchain Validity And

Effectiveness Of “Smart Wills” Through Blockchain Technology Lucas Salles Moreira Rocha*

Frederico Felix Gomes** Tereza Cristina Monteiro Mafra … Palavras-chave: Blockchain …";Autres articles;;[PDF] uel.br;http://www.uel.br/revistas/uel/index.php/iuris/article/viewFile/33991/25173;"
63
LUCAS SALLES MOREIRA ROCHA E FREDERICO FELIX GOMES E TEREZA CRISTINA MONTEIRO MAFRA

SCIENTIA IURIS, Londrina, v.23, n.1, p. 63-80, mar. 2019. DOI: 10.5433/2178-8189.2019v23n1p63

Validade E Eficácia Dos “Testamentos Inteligentes” 
Via Tecnologia Blockchain

Validity And Effectiveness Of “Smart Wills” 
Through Blockchain Technology

Lucas Salles Moreira Rocha*
Frederico Felix Gomes**

Tereza Cristina Monteiro Mafra***

Como citar: ROCHA, Lucas Salles Moreira; GOMES, Frederico 
Felix; MAFRA, Tereza Cristina Monteiro. Validade e EficĂĄcia 
dos “Testamentos Inteligentes” via Tecnologia Blockchaim. 
Scientia Iuris, Londrina, v. 23, n. 1, p. 63-80, mar. 2019. DOI: 
10.5433/2178-8189.2019v23n1p63. ISSN: 2178-8189.

Resumo: O objetivo deste artigo ĂŠ analisar a validade e eficĂĄcia 
dos “testamentos inteligentes”, entendidos para fins deste trabalho 
como testamentos particulares autoexecutĂĄveis e possibilitados 
pela tecnologia blockchain. Pelos mĂŠtodos exploratĂłrio e 
analítico-dogmåtico, propþe-se a possibilidade de realização 
de “testamentos inteligentes” no Brasil, pela utilização dessa 
inovadora tecnologia. Primeiramente, analisa-se a tecnologia 
blockchain, sua estrutura como rede descentralizada e seu 
funcionamento, suas diferentes aplicações, com foco nos “smart 
contracts”. Após, é realizada uma revisão da literatura sobre os 
diferentes tipos de testamentos, principalmente dos testamentos 
particulares, suas principais caracterĂ­sticas, peculiaridades e as 
causas que fazem com que tal instrumento seja pouco utilizado 
atualmente. Em seguida, busca-se demonstrar como a tecnologia 
blockchain pode ajudar a tornar tais instrumentos mais confiĂĄveis 
e autoexecutĂĄveis, sem, contudo, ignorar as dificuldades tĂŠcnicas 
a serem superadas posteriormente. 

Palavras-chave: Blockchain. Contratos inteligentes. Testamentos 
particulares.

Abstract: The scope of this article is to analyze the legal validity 
and effectiveness of “smart wills”, also known as “cryptowills”, 
which can be understood as automatics or self-executables 
wills made possible through blockchain technology. Through 
exploratory and analytical-dogmatic methods, this article implies 
the possibility of realizing “intelligent wills” in Brazil, by the 
use of this innovative technology. First, this paper analyzes the 

*Mestre em Direito em 2017 
pela Faculdade Milton Campos 
(FMC)
PĂłs-Graduando em Direito em 
2016 pela IBMEC (IBMEC)
Graduado em Direito em 2013 
pela Faculdade Milton Campos 
(FMC)
E-mail: rocha.lucas@gmail.com

**Mestre em Direito em 2015 
pela Faculdade Milton Campus 
(FMC)
Especialista em Direito em 2011 
pela Faculdade Milton Campus 
(FMC)
Graduado em Direito em 2010 
pela Faculdade Milton Campus 
(FMC)
E-mail: ffelix2210@gmail.com

***Doutora em Direito em 2013 
pela Universidade Federal de 
Minas Gerais (UFMG)
Mestre em Direito em 2000 pela 
Universidade Federal de Minas 
Gerais (FDUFMG)
Graduada em Direito pela 
Universidade Federal de Minas 
Gerais (FMC)
E-mail: tereza.c.mafra@terra.
com.br

DOI: 10.5433/2178-8189.2019v23n1p63



64

SCIENTIA IURIS, Londrina, v.23, n.1, p. 63-80, mar. 2019. DOI: 10.5433/2178-8189.2019v23n1p63

VALIDADE E EFICÁCIA DOS “TESTAMENTOS INTELIGENTES” VIA TECNOLOGIA BLOCKCHAIN

blockchain technology, its different applications, its structure as a 
distributed computer network and how it works, focusing on smart 
contracts. After, it is reviewed the Brazilian legislation regarding 
testaments, mainly private testaments, its characteristics, 
peculiarities and the reasons why this kind of testaments are not 
often used nowadays. Finally, this article seeks do demonstrate 
how blockchain technology may help to make these testaments 
more trustworthy and self-executables, without disregard the 
technical difficulties to be overcome.

Keywords: Blockchain. Smart contracts. Private wills.



65
LUCAS SALLES MOREIRA ROCHA E FREDERICO FELIX GOMES E TEREZA CRISTINA MONTEIRO MAFRA

SCIENTIA IURIS, Londrina, v.23, n.1, p. 63-80, mar. 2019. DOI: 10.5433/2178-8189.2019v23n1p63

INTRODUÇÃO

O mundo encontra-se no limiar de mais uma revolução tecnológica. A rede mundial de 
computadores estĂĄ ingressando em uma nova etapa, marcada notadamente pelo fenĂ´meno da 
“descentralização”. Estudos realizados ao longo das últimas décadas resultaram em um grande 
avança nas åreas da criptografia e sistemas de computação distribuídos, resultando no surgimento 
de uma nova tecnologia com potencial disruptivo, conhecida como blockchain.

A tecnologia blockchain se trata de verdadeira evolução na economia P2P (“peer to 
peer”), ou de “ponta-a-ponta”, marcada notadamente pela colaboração entre os usuários dentro de 
uma rede descentralizada de computadores. Ao combinar uma rede “ponta-a-ponta”, algoritmos de 
criptografia, armazenamento de dados em nuvem e um mecanismo de consenso descentralizado, 
a tecnologia blockchain propicia, por exemplo, que seus usuårios expressem sua concordância em 
determinados negĂłcios jurĂ­dicos, bem como armazenem certos documentos de maneira segura e 
publicamente verificĂĄvel. 

Em razĂŁo dessas caracterĂ­sticas estruturais, a blockchain tem o potencial de desburocratizar 
diversas ĂĄreas dos setores pĂşblicos e privados, simplesmente eliminando a necessidade de 
“intermediários”. Suas aplicações são diversas, desde criptomoedas, como o bitcoin, até os 
chamados “smart contracts” ou “contratos inteligentes”. Dentre as diferentes espécies de “contratos 
inteligentes” encontram-se os “testamentos inteligentes”, passíveis de enquadramento no âmbito 
dos testamentos particulares. 

AlÊm dos requisitos gerais, a legislação påtria impþe restriçþes específicas quanto à 
forma do testamento, condicionando sua validade à observância de determinados pressupostos. 
Inobservada a forma prescrita e sendo invĂĄlido, a consequĂŞncia seria a ineficĂĄcia do instrumento. 
No que tange ao testamento particular, a projeção dos efeitos desejados estå condicionada, v.g., à 
confirmação judicial, algo que não se mostra viável no caso dos “testamentos inteligentes”. Seria 
possĂ­vel, nesse sentido, dotar tais instrumentos de validade e eficĂĄcia?

O presente artigo buscarĂĄ, portanto, analisar juridicamente e pelo mĂŠtodo exploratĂłrio 
as questþes que permeiam o tema, no intuito de contribuir para a evolução das discussþes sobre a 
matĂŠria no campo do direito.

AlÊm da introdução e das consideraçþes finais, o artigo estå organizado em quatro tópicos. 
No primeiro deles, tratar-se-å das aplicaçþes pråticas da tecnologia blockchain, que viabiliza a 
criação dos “testamentos inteligentes”. No segundo item será abordada a questão da autonomia 
privada e interferência estatal no âmbito da elaboração de “testamentos inteligentes”, para, no 
tĂłpico seguinte, tratar da existĂŞncia, validade e eficĂĄcia de tais instrumentos. No Ăşltimo item, o 
artigo versa sobre os desafios a serem superados pelos “testamentos inteligentes”, para que estes 
se tornem viĂĄveis e ganhem popularidade no mercado. 

1   A TECNOLOGIA BLOCKCHAIN E SUAS APLICAÇÕES PRÁTICAS



66

SCIENTIA IURIS, Londrina, v.23, n.1, p. 63-80, mar. 2019. DOI: 10.5433/2178-8189.2019v23n1p63

VALIDADE E EFICÁCIA DOS “TESTAMENTOS INTELIGENTES” VIA TECNOLOGIA BLOCKCHAIN

Antes do advento da tecnologia blockchain, era praticamente impossĂ­vel coordenar 
açþes individuais na rede mundial de computadores sem o auxílio     de uma autoridade ou órgão 
“central”, capaz de garantir a incolumidade dos dados trafegados. 

Podemos citar, por exemplo, uma transação bancåria via internet banking. AtÊ hoje, 
sempre foi necessårio que um terceiro, no caso a própria entidade bancåria, confirmasse a transação 
efetuada, emitindo um comprovante verificĂĄvel pelas partes envolvidas. A aparente necessidade 
de uma “autoridade verificadora” supostamente advém de um antigo problema proposto dentro da 
Ciência da Computação, intitulado “Problema dos Generais Bizantinos” (LAMPORT; SHOSTAK; 
PEASE, 1982).

A tecnologia blockchain resolve referido problema sob a Ăłtica da probabilidade. A citada 
tecnologia propicia que informaçþes trafegando dentro de uma rede de computadores se tornem 
mais transparentes e publicamente verificåveis, utilizando equaçþes matemåticas que demandam 
grande capacidade computacional para serem resolvidas. Isto faz com que eventuais ataques 
com objetivo de corromper uma base de dados distribuĂ­da sejam virtualmente impossĂ­veis, pois 
demandaria que os atacantes detivessem a maior parte do poder computacional de toda a rede.

Dessa maneira, podemos dizer que o protocolo blockchain garante que as transaçþes 
efetuadas dentro de uma determinada rede, que se utiliza deste protocolo, sejam vĂĄlidas e registradas 
no repositório compartilhado de informaçþes apenas uma vez, possibilitando, assim, que seus 
usuårios realizem transaçþes (dotadas de valor econômico ou não) de maneira descentralizada, 
sem necessidade de um terceiro garantidor, cuja função seria justamente verificar e validar tais 
transaçþes.

A blockchain nada mais Ê que uma base de dados que armazena diversas transaçþes, as 
quais sĂŁo organizadas de maneira cronolĂłgica e registradas por uma rede de computadores. Cada 
uma das plataformas blockchain existentes no mercado (ex.: bitcoin, ethereum, corda, quĂłrum, 
etc.) possuem uma criptografia prĂłpria, podendo todas serem divididas em conjuntos menores de 
dados, chamados “blocos” (“blocks”). 

Cada um desses blocos possui informaçþes sobre um certo número de transaçþes; uma 
referĂŞncia sobre o bloco predecessor; alĂŠm de uma resposta para um problema matemĂĄtico 
complexo, a qual Ê utilizada para validar as informaçþes associadas àquele bloco específico. 

Assim, uma cĂłpia da blockchain, como um todo, ĂŠ armazenada em todos os computadores 
dentro desta rede, que periodicamente realizam a sincronização dos dados, de modo que todos na 
rede possuam uma cĂłpia idĂŞntica daquela base de dados (BONNEAU et al., 2015).

Com objetivo de garantir que apenas transaçþes legítimas sejam registradas na blockchain, 
os computadores dentro da rede confirmam que eventuais novas transaçþes são vålidas sem que 
as transações antigas sejam invalidadas. Um novo “bloco” será anexado ao fim da blockchain 
somente após tais computadores chegarem a um consenso acerca da validade daquela transação. 
Por sua vez, tal consenso Ê alcançado dentro da rede por diferentes mecanismos de votação, sendo 
que o mais famoso destes mecanismos é o “Proof of Work”, que depende da quantidade de poder 
computacional “doado” para a rede (WRIGHT; FILIPPI, 2015).



67
LUCAS SALLES MOREIRA ROCHA E FREDERICO FELIX GOMES E TEREZA CRISTINA MONTEIRO MAFRA

SCIENTIA IURIS, Londrina, v.23, n.1, p. 63-80, mar. 2019. DOI: 10.5433/2178-8189.2019v23n1p63

O mecanismo acima citado (“Proof of Work”) demanda que determinados computadores 
dentro da rede, conhecidos popularmente como “mineiros” ou “mineradores” (“miners”) resolvam 
problemas matemĂĄticos extremamente complexos, enquanto outros verificam se a resposta para 
este problema não corresponde a uma transação previamente registrada. 

Como forma de incentivo ao “mineradores”, ou seja, para que estes continuem a despender 
grande poder computacional para resolver tais problemas matemĂĄticos, o que consome vultuosos 
recursos, estes podem receber uma certa quantidade de criptomoeda ou um crĂŠdito sobre as taxas 
(equivalentes a uma fração de uma criptomoeda) utilizadas para realização das transaçþes (ex.: 
bitcoin, ether, etc.).

Uma vez que um novo “bloco” é adicionado à blockchain, ele jamais poderá ser deletado, 
sendo que todas as transações registradas neste “bloco” poderão ser acessadas e verificadas por 
qualquer usuĂĄrio dentro da rede (GREENSPAN, 2016). De maneira ilustrativa, podemos dizer 
que a blockchain é uma espécie de “livro registro”, onde cada novo “bloco” representa uma nova 
pĂĄgina neste livro. Este ĂŠ inclusive um problema da tecnologia blockchain, eis que o crescimento 
da cadeia de blocos Ê proporcional ao tempo gasto para confirmação de uma transação (WRIGHT; 
FILIPPI, 2015). 

Atualmente, o tempo de espera para que uma transação atinja o consenso na rede Ê de 
aproximadamente dez minutos (WRIGHT; FILIPPI, 2015). Caso a cadeia fique muito grande, as 
transaçþes poderão ser inviåveis em razão do tempo de espera de confirmação destas transaçþes. 
Neste caso, a solução seria a limitação do número de transações registradas em cada “bloco”, ou 
então o aumento no número de usuário dispostos a “minerar” tais transações.

Analisado o conceito e estrutura da blockchain, pode-se facilmente perceber o seu enorme 
potencial. AlÊm da criação de criptomoedas, tal tecnologia Ê utilizada, por exemplo, no registro e 
assinatura de documentos, por meio de criptografia assimĂŠtrica, como a utilizada atualmente pela 
tecnologia do processo eletrônico judicial (PJe); na criação de mecanismos de votação seguros; 
além da implementação dos chamados “smart contracts”, ou “contratos inteligentes”.

Pode-se considerar os “contratos inteligentes” como a grande tecnologia disruptiva dentro 
da prĂĄtica jurĂ­dica, nas Ăşltimas dĂŠcadas. Ao se utilizar uma base de dados compartilhada, tal qual 
a blockchain, as partes contratantes podem confirmar que um evento ou condição de fato ocorreu, 
sem a necessidade de um terceiro de confiança. 

De maneira geral, os “contratos inteligentes” são a implementação de um negócio jurídico, 
cujas provisĂľes foram escritas e formalizadas atravĂŠs de um cĂłdigo fonte, que nada mais ĂŠ que um 
texto escrito na forma de uma determinada linguagem de programação (ex.: HTML5, Java, C++, 
Delphy, Python, etc.) e depois, traduzida para a linguagem de mĂĄquina (cĂłdigo binĂĄrio composto 
por valores 0 e 1), por meio de um compilador (WRIGHT; FILIPPI, 2015). 

Dessa maneira, as partes contratantes podem estruturar sua relação contratual de maneira 
mais clara, sem a presença de ambiguidades (devido à compreensão binåria de uma måquina), e, 
ainda, de maneira automatizada ou “auto executável”. 

Primeiramente, é preciso esclarecer que os “smart contracts” não foram criados a partir 



68

SCIENTIA IURIS, Londrina, v.23, n.1, p. 63-80, mar. 2019. DOI: 10.5433/2178-8189.2019v23n1p63

VALIDADE E EFICÁCIA DOS “TESTAMENTOS INTELIGENTES” VIA TECNOLOGIA BLOCKCHAIN

da tecnologia blockchain. Podemos dizer que as tradicionais mĂĄquinas de refrigerante, onde 
inserimos um certo valor pecuniĂĄrio com objetivo de receber uma lata ou garrafa da bebida, pode 
ser considerado um “smart contracts”, mesmo que primitivo. O mérito da tecnologia blockchain 
foi justamente tornar a relação entre as partes mais confiåvel, dispensando-se a necessidade de um 
terceiro fiduciĂĄrio. 

Os “smart contracts” podem ainda ser entendidos como a representação de um acordo, 
no qual se verifica o cumprimento de uma condição anteriormente estabelecida, que ocasiona uma 
consequĂŞncia, tambĂŠm previamente consentida. 

Assim, o funcionamento dos “smart contracts” segue a lógica “se X, então Y”, contida no 
cĂłdigo fonte pelo qual o contrato ĂŠ regido, tornando-se, assim, auto executĂĄvel, na medida em que 
o adimplemento de uma condição ou ocorrência de um evento desencadeia um resultado específico 
prĂŠ-estabelecido ou, literalmente, programado.

O leitor mais atento irá notar que os “contratos inteligentes”, na verdade, não são tão 
inteligentes assim. Isto porque sĂŁo limitados pela linguagem compreendida por um computador, que 
por sua vez ĂŠ binĂĄria. Obviamente, contratos redigidos por advogados sĂŁo muito mais complexos, 
contendo, por vezes, ambiguidades propositais, que demandam uma tarefa interpretativa pelo 
leitor do documento. 

Diferentemente, um “contrato inteligente” não foi feito para ser interpretado, mas sim 
executado no caso do advento de uma condição. Uma vez que o código do “contrato inteligente” é 
escrito em linguagem de programação, ele pode ser inserido e registrado na blockchain, e somente 
a lógica transcrita naquele contrato Ê que regerå a relação contratual tida entre as partes. 

Nota-se, portanto, que as provisões constantes dentro de um “contrato inteligente” são 
extremamente limitadas. As partes nĂŁo podem fazer usos de determinadas clĂĄusulas, como aquelas 
que estipulam direitos, obrigaçþes, foro competente, legislação aplicåvel, etc.

Em que pese tais limitações, o desenvolvimento de tecnologias envolvendo “smart 
contracts” está crescendo exponencialmente. Nos últimos anos, diversos projetos que utilizam 
a tecnologia blockchain - como Ethereum, Counterparty e Mastercoin - estĂŁo desenvolvendo 
linguagens de programação (aquelas utilizadas para redigir o código fonte de “contrato inteligente”) 
que possibilitam a criação de “smart contracts” cada vez mais sofisticados. 

Dentre estas novas espécies de “contratos inteligentes”, estão os “smart wills” ou 
“cryptowills”, que podem ser entendidos como verdadeiros testamentos auto executáveis, os quais 
chamaremos neste trabalho específico de “testamentos inteligentes”. 

Trata-se de uma nova realidade e que jĂĄ se encontra presente no mercado. A tĂ­tulo de 
exemplo, citamos a empresa “Blockchain Apparatus”, que se encontra desenvolvendo uma 
tecnologia que possibilitará a execução destes “testamentos inteligentes”1.

O objetivo dos “testamentos inteligentes” é justamente dar efetividade às declarações 
últimas de vontade de uma pessoa sem a necessidade de um terceiro, que faça cumprir esses 
desejos. Trata-se da possibilidade de eliminação das figuras do notårio, do testamenteiro ou mesmo 

1 DisponĂ­vel em: http://blockchainapparatus.com/smart-contracts/. Acesso em: 17 nov. 2017.



69
LUCAS SALLES MOREIRA ROCHA E FREDERICO FELIX GOMES E TEREZA CRISTINA MONTEIRO MAFRA

SCIENTIA IURIS, Londrina, v.23, n.1, p. 63-80, mar. 2019. DOI: 10.5433/2178-8189.2019v23n1p63

do juiz de direito, alĂŠm de prover eficĂĄcia e executividade ao instrumento.
Imagine-se a seguinte situação hipotÊtica: Fulano, titular de uma vultuosa carteira de 

criptomoedas, resolve deixar tal ativo para um de seus herdeiros, que tambĂŠm possui uma carteira 
própria dessas criptomoedas. Para tanto, Fulano resolve registrar um “testamento inteligente”, por 
exemplo, na blockchain da empresa Ethereum. Conforme o cĂłdigo transcrito nesse documento, 
no advento da morte de Fulano, os valores contidos em sua carteira de criptomoedas serĂŁo 
automaticamente transferidos para seu herdeiro, sem necessidade de confirmação por um terceiro. 

Todavia, serå que a legislação brasileira permite este tipo de transação por meio dos 
“testamentos inteligentes”? Qual seria a verdadeira eficácia destes instrumentos? Quais os limites? 
Quais problemas os “testamentos inteligentes” resolvem e quais os desafios a serem superados? 
Estas e outras questĂľes serĂŁo doravante analisadas. Todavia, antes de buscar tais respostas, mostra-
se necessĂĄria uma revisĂŁo das normas legislativas que regulam os atos sucessĂłrios no Brasil. 

2  INTERFERÊNCIA ESTATAL E AUTONOMIA PRIVADA NA CONFECÇÃO DE 
“TESTAMENTOS INTELIGENTES”

A legislação em vigor preceitua que a “sucessão dá-se por lei ou por disposição de última 
vontade” (Código Civil, art. 1.786) (BRASIL, 2002). Neste dispositivo, encontram-se identificadas 
as duas formas de sucessĂŁo autorizadas pelo ordenamento jurĂ­dico pĂĄtrio, quais sejam a legĂ­tima, 
disposta em lei, e a testamentĂĄria, que decorre da vontade do falecido2. 

Absoluta nĂŁo ĂŠ, entretanto, a autonomia do testador para dispor de seu patrimĂ´nio. O 
CC/02 (art. 1.845) determina que sĂŁo herdeiros necessĂĄrios os ascendentes, os descendentes e o 
cĂ´njuge, e atribui a estes a legĂ­tima, composta pela metade dos bens do de cujus (art. 1.846). O 
citado diploma, ao determinar que a legítima não pode ser objeto de testamento (art. 1.857, § 1º), 
restringe a autonomia privada e tenta equilibrar o interesse da famĂ­lia com a vontade do testador3. 

Assim, existindo herdeiros necessårios a herança Ê fracionada em duas metades iguais, 
quais sejam a legítima, reservada aos herdeiros necessårios, e a porção disponível, que pode ser 
objeto de livre disposição por testamento. Somente nos casos em que não haja herdeiros necessårios, 
ĂŠ que o testador poderĂĄ dispor livremente da totalidade de seus bens. Lado outro, em sendo a 
sucessĂŁo ab intestato, ou seja, sem testamento, os herdeiros legĂ­timos serĂŁo os Ăşnicos titulares dos 
bens deixados pelo de cujus. 

Segundo Washington de Barros Monteiro (2011, p. 23), a limitação à liberdade de testar 
se mostra mais adequada do que a autonomia plena para disposição dos bens após a morte, pois o 
elemento individual nĂŁo deve se sobrepor ao elemento social:

2 AlĂŠm de tratar dos aspectos patrimoniais da sucessĂŁo, afetos ao presente estudo, o testamento pode, ainda, dispor 
sobre questĂľes de carĂĄter nĂŁo patrimonial, ainda que o testador somente a elas se tenha limitado (CC/02, art. 1.857, 
§2º), tais como o reconhecimento de filhos (CC/02, art. 1.609, III), nomeação de tutor para o filho menor (CC/02, 
art. 1.634, VI) e a reabilitação do indigno (CC/02, art. 1.818). (BRASIL, 2002).

3 Existe, ainda, restrição com relação às clåusulas de inalienabilidade, impenhorabilidade e incomunicabilidade, que 
somente podem recair sobre a legĂ­tima se houver justa causa (CC/02, art. 1.848). (brasil, 2002).



70

SCIENTIA IURIS, Londrina, v.23, n.1, p. 63-80, mar. 2019. DOI: 10.5433/2178-8189.2019v23n1p63

VALIDADE E EFICÁCIA DOS “TESTAMENTOS INTELIGENTES” VIA TECNOLOGIA BLOCKCHAIN

Hå quem propugne pelo ilimitado direito de testar, sem nenhuma restrição, 
podendo abranger, destarte, todo o patrimĂ´nio do testador, sem reserva alguma. 
[...] Alegou-se, a propĂłsito, que a existĂŞncia da legĂ­tima implicaria ofensa ao 
direito de propriedade, contribuindo, ao mesmo tempo, para enfraquecimento da 
autoridade paterna. O sistema que afinal triunfou (liberdade de testar limitada), 
incontestavelmente, ĂŠ o melhor, porque de modo perfeito concilia os elementos em 
que se apoia o direito hereditĂĄrio: de um lado, a propriedade, elemento individual, 
de outro, a famĂ­lia, elemento social. Outorgar ao indivĂ­duo plena liberdade de 
testar seria conferir preeminĂŞncia ao elemento individual, em detrimento do 
social. Com irrestrita liberdade de testar, o testador poderia transformar-se num 
ser odioso, instrumento, talvez, de seu egoĂ­smo e de sua cegueira (MONTEIRO, 
2011, p. 23).

Na maior parte dos sistemas jurĂ­dicos hĂĄ regras limitadoras da liberdade de testar. Dentre 
aqueles que adotam um sistema hereditårio clåssico, fundado no modelo romano, como França, Itålia, 
Espanha, existe uma parte da herança que necessariamente Ê destinada a determinados herdeiros 
(legĂ­tima ou reserva). Lado outro, os paĂ­ses que adotam o sistema anglo-saxĂ´nico reconhecem uma 
mais ampla liberdade de testar, que, porĂŠm, nĂŁo ĂŠ absoluta, pois, em geral, exige o reconhecimento 
do direito a alimentos como devido a certos parentes e ao cĂ´njuge (Inglaterra, Estados Unidos, 
MĂŠxico). Deve-se, ainda, mencionar um modelo intermediĂĄrio, no qual os herdeiros necessĂĄrios 
sĂł fazem jus Ă  legĂ­tima na hipĂłtese de necessidade, a exemplo de RĂşssia, EstĂ´nia, EslovĂŞnia e 
Polônia (FERNÁNDEZ-HIERRO; FERNÁNDEZ-HIERRO, 2010, p. 26-27).

Para parte da doutrina contemporânea, a limitação à autonomia privada, imposta pela 
legítima, encontraria fundamento na proteção à família do testador (NEVARES, 2006, p. 163):

Na orientação do dever de solidariedade entre os membros da família, estão 
as regras da sucessĂŁo legĂ­tima, em especial aquelas que consagram a sucessĂŁo 
necessåria, pois estabelecem uma possibilidade de distribuição de valores 
materiais entre os familiares e, dessa forma, um mecanismo em potencial de 
libertação das necessidades, como meio de concretização de uma vida digna.

As restriçþes à autonomia privada, entretanto, podem tratar não apenas do conteúdo do 
negócio jurídico, como Ê o caso da legítima, mas tambÊm da sua formação. No que tange às 
restrições formais, “o princípio da liberdade de forma - que é uma das conquistas das civilizações 
modernas, jĂĄ consagrado no CĂłdigo Civil de 1916 (art. 129) e adotado pelo novo CĂłdigo Civil (art. 
107) - não se aplica ao testamento” (VELOSO, 2007, p. 141). 

No âmbito do testamento, o formalismo Ê imposto notadamente para garantir a existência 
e a veracidade da vontade do testador, pois os efeitos do testamento ocorrerĂŁo em momento em que 
este jĂĄ tiver falecido, ou seja, em momento que o autor do documento nĂŁo poderĂĄ agir para garantir 
a sua correta interpretação (PRETTO, 2015, p. 88). 

A legislação påtria impþe, portanto, restriçþes quanto à forma do testamento, e condiciona 
sua validade à observância de determinados requisitos. Duas são as categorias de testamentos 
previstas em lei, quais sejam os comuns e os especiais. 



71
LUCAS SALLES MOREIRA ROCHA E FREDERICO FELIX GOMES E TEREZA CRISTINA MONTEIRO MAFRA

SCIENTIA IURIS, Londrina, v.23, n.1, p. 63-80, mar. 2019. DOI: 10.5433/2178-8189.2019v23n1p63

No âmbito dos testamentos comuns, tem-se as formas pública, particular e cerrada (CC/02, 
art. 1.862). Na esfera dos testamentos especiais, encontram-se os marĂ­timos, aeronĂĄuticos e militares 
(CC/02, art. 1.886), os quais nĂŁo serĂŁo analisados, pois estes somente podem ser utilizados em 
situaçþes excepcionais, que não se enquadram nas hipóteses propostas por este estudo. 

Segundo Orlando Gomes (2008, p. 105), a orientação legislativa de permitir o testamento 
comum em vĂĄrias formas ĂŠ justificada por diversas razĂľes:

Razþes diversas justificam a orientação legislativa de permitir o testamento 
comum em vĂĄrias formas, todas inflexivelmente configuradas. Deixando-as 
Ă  escolha de quem se dispĂľe a testar, atende a lei, de um lado, a respeitĂĄveis 
conveniĂŞncias pessoais, e, de outro, a contingencias que privariam algumas 
pessoas do exercĂ­cio desse poder, se desatendidas. O receio de desaparecimento 
do escrito induz, nĂŁo raro, Ă  preferĂŞncia por forma testamentĂĄria que o afasta. O 
desejo de que permaneçam desconhecidas atÊ a morte as disposiçþes de última 
vontade satisfaz-se no testamento secreto. A impossibilidade de ler, escrever ou 
ouvir a declaração de vontade determina, por sua vez, a exigência de determinada 
forma 

Para fins deste trabalho, nĂŁo se mostra pertinente discorrer acerca dos diversos 
procedimentos e formalidades a serem seguidos para cada espĂŠcie de testamento. Entretanto, 
importante salientar que tanto os testamentos pĂşblicos, quanto os cerrados, tĂŞm como requisito 
fundamental a participação de tabelião ou substituto legal na confecção do instrumento (CC/02, 
arts. 1.864 e 1.868). 

Assim, dentre os testamentos comuns, importam para esta pesquisa os testamentos 
particulares, que, por dispensarem a participação de notårio na sua confecção, podem ser os 
únicos a serem classificados como “testamentos inteligentes” e, utilizados no âmbito da tecnologia 
blockchain. 

O testamento particular ĂŠ escrito pelo testador de prĂłprio punho ou por processo 
mecânico, lido a três testemunhas e por todos assinado, conforme determina o art. 1.876, §1º e 
§2º do CC/02. Não obstante ser a forma testamentåria mais simples prevista no ordenamento, 
sua eficåcia condiciona-se ao preenchimento das seguintes formalidades: (i) publicação em juízo, 
com citação dos herdeiros legítimos (CC/02, art. 1.877); (ii) inquirição de testemunhas, que 
deverĂŁo reconhecer em juĂ­zo suas prĂłprias assinaturas e a do testador (CC/02, art. 1.878)4; e (iii) 
confirmação do testamento pelo juiz. A força executória dos testamentos particulares tem, nesse 
sentido, sua eficåcia condicionada à confirmação judicial (GOMES, 2008, p. 126-128).

Feitas estas consideraçþes, mister se faz examinar, ainda que brevemente, as três dimensþes 
do negĂłcio jurĂ­dico, quais sejam existĂŞncia, validade e eficĂĄcia, sob a Ăłtica dos testamentos. A 
existência do testamento tem início com a declaração de vontade do testador, a qual deve ser 
dotada de forma e conteúdo que atendam às circunstâncias negociais, e que fazem com que o ato 

4 Somente em casos excepcionais, de morte ou ausĂŞncia, e de comparecimento de pelo menos uma testemunha, ĂŠ que 
o testamento poderĂĄ ser confirmado, se, a critĂŠrio do juiz, houver prova suficiente de sua veracidade (CC/02, art. 
1.878, parĂĄgrafo Ăşnico). (BRASIL, 2002).



72

SCIENTIA IURIS, Londrina, v.23, n.1, p. 63-80, mar. 2019. DOI: 10.5433/2178-8189.2019v23n1p63

VALIDADE E EFICÁCIA DOS “TESTAMENTOS INTELIGENTES” VIA TECNOLOGIA BLOCKCHAIN

seja visto socialmente como destinado a produzir seus efeitos jurĂ­dicos (AZEVEDO, 1974, p. 32-
33). 

O ingresso do testamento no plano da existĂŞncia nĂŁo importa, entretanto, na sua validade, 
que estĂĄ condicionada ao preenchimento de determinados requisitos. No ordenamento pĂĄtrio, os 
requisitos gerais do negĂłcio jurĂ­dico estĂŁo previstos no art. 104 do CC/02, que determinam serem 
necessĂĄrios: (i) agente capaz; (ii) objeto lĂ­cito, possĂ­vel, determinado ou determinĂĄvel; e (iii) forma 
prescrita ou nĂŁo defesa em lei. 

No caso do testamento particular, o CC/02 impĂľe, ainda, requisitos especĂ­ficos, como 
por exemplo, a necessidade de ser escrito de próprio punho ou mediante processo mecânico, de 
ser assinado pelo testador, e de ser lido na presença de ao menos três testemunhas, que tambÊm 
deverĂŁo assinar o documento. 

Por fim, ainda que o testamento exista e seja válido, ele ainda não é eficaz. É que os 
efeitos almejados a partir da realização do negócio jurídico somente serão alcançados se este 
passar pelos planos da existência e validade, alcançando, posteriormente, a dimensão da eficåcia, 
a qual se refere ao início da produção de efeitos do negócio jurídico. A respeito do tema, Pontes de 
Miranda (1955, p. 68) leciona:

Existindo o ato jurĂ­dico, pode ser vĂĄlido ou nĂŁo-vĂĄlido (= nulo ou anulĂĄvel), 
eficaz ou ineficaz. Se o negĂłcio jurĂ­dico nĂŁo existe, nĂŁo hĂĄ pensar-se em conceito 
de validade ou de eficĂĄcia. Primeiro vem o ser que o valor e o ter efeitos. De 
modo que, ao dizer-se ser ineficaz o negĂłcio jurĂ­dico, nĂŁo se lhe nega existĂŞncia: 
implicitamente se afirmou que existe negĂłcio jurĂ­dico; ao dizer-se que ĂŠ nulo, ou 
anulåvel, implícita estå, na afirmação de nulidade ou de ineficåcia, a de existência. 
O sem-efeitos que nĂŁo existe ĂŠ sem efeitos porque nĂŁo ĂŠ: nĂŁo ĂŠ; e, pois, seria 
absurdo que tivesse efeitos. O sem-efeitos, de que se pode falar e sĂł dele tem 
sentido falar-se, ĂŠ o ser que ĂŠ sem efeitos: ĂŠ, mas faltam-lhe efeitos. O que nĂŁo 
existe é nada; se lhe chama “nulo” é em sentido que não se põe no plano da 
validade: ĂŠ o nĂŁo-ser, que equivocamente se chamou de nulo. A falta de eficĂĄcia 
nĂŁo ĂŠ dĂŠfice do negĂłcio jurĂ­dico mesmo; ĂŠ nĂŁo-ser das consequĂŞncias.

A regra geral para que o testamento se torne eficaz reside na manutenção, pelo testador, de 
sua declaração, sem revogação, atÊ a morte. Somente após a morte do testador Ê que o testamento, 
atĂŠ entĂŁo limitado Ă s duas primeiras dimensĂľes do negĂłcio jurĂ­dico, poderĂĄ projetar os seus efeitos 
no mundo jurĂ­dico (AZEVEDO, 1974, p. 32-33). 

No que tange ao testamento particular, esta não Ê, entretanto, a única condição para 
ingresso no plano da eficåcia. Como foi visto oportunamente, a projeção dos efeitos desejados, 
neste caso, estå condicionada à confirmação judicial do instrumento. 

Para Washington de Barros Monteiro (2011, p. 165), o maior defeito do testamento 
particular ĂŠ a possibilidade de fraude, que sĂŁo menos passĂ­veis de acometer as outras formas 
previstas em lei, por demandarem a participação de notårio na sua confecção. Seguindo esta 
mesma linha de raciocĂ­nio, Arnoldo Wald (2009, p. 175-176) leciona que os inconvenientes do 
testamento particular residem na possibilidade de pressĂŁo, substitu";"""date"",""2019-03-28T05:29:10Z""
""pdf:PDFVersion"",""1.7""
""xmp:CreatorTool"",""Adobe InDesign CC 13.1 (Windows)""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""language"",""pt""
""dc:format"",""application/pdf; version=1.7"",""application/pdf; version=""""1.7 Adobe Extension Level 3""""""
""pdf:docinfo:creator_tool"",""Adobe InDesign CC 13.1 (Windows)""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""xmp:CreateDate"",""2019-03-28T02:29:08Z""
""modified"",""2019-03-28T05:29:10Z""
""pdf:hasMarkedContent"",""false""
""xmp:ModifyDate"",""2019-03-28T02:29:10Z""
""trapped"",""False""
""meta:creation-date"",""2019-03-28T05:29:08Z""
""created"",""2019-03-28T05:29:08Z""
""pdf:PDFExtensionVersion"",""1.7 Adobe Extension Level 3""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-03-28T05:29:08Z""
""resourceName"",""25173""
""xmpMM:DerivedFrom:DocumentID"",""xmp.did:750183fc-0f6e-f748-a305-5ec25c66818d""
""producer"",""Adobe PDF Library 15.0""
""pdf:docinfo:producer"",""Adobe PDF Library 15.0""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""access_permission:modify_annotations"",""true""
""dcterms:created"",""2019-03-28T05:29:08Z""
""Last-Modified"",""2019-03-28T05:29:10Z""
""dcterms:modified"",""2019-03-28T05:29:10Z""
""xmpMM:DocumentID"",""xmp.id:592994d1-d56e-2643-bfc1-32387e6ba3ee""
""Last-Save-Date"",""2019-03-28T05:29:10Z""
""pdf:docinfo:modified"",""2019-03-28T05:29:10Z""
""meta:save-date"",""2019-03-28T05:29:10Z""
""Content-Length"",""366232""
""Content-Type"",""application/pdf""
""xmp:MetadataDate"",""2019-03-28T02:29:10Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""dc:language"",""pt-BR""
""pdf:producer"",""Adobe PDF Library 15.0""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""18""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""2976"",""774"",""3119"",""3432"",""3472"",""3434"",""3586"",""3433"",""3436"",""3376"",""3179"",""3383"",""3612"",""3232"",""3097"",""2929"",""3029"",""759""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""xmpMM:DerivedFrom:InstanceID"",""xmp.iid:7a1f2427-f72a-8a4d-b955-104abfb898b2""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-03-28T05:29:08Z""
";https://scholar.google.com/scholar?start=530&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094668-1186;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Multiple channel with crash fault tolerant consensus blockchain network: a case study of vegetables supplier supply chain;H Yusuf, I Surjandari, AMM Rus ; 2019 16th International …, 2019  ieeexplore.ieee.org;;"… challenges and cybercrime, increasing privacy such as determining the details of which

transactions and increasing transaction speeds (real time) [5][7]. In fact, ERP companies such

as SAP and Oracle also want to implement the blockchain in their ERP because of this.[8] …";Cité 5 fois;;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/8876028/8887596/08887678.pdf?casa_token=SC6DXaNThpwAAAAA:uydKSFstXOQ6QOfqLx3LxOPQt6WzIuV8Hcu-ccX8b6gutt-XoQevEfNi8ZyzNYsBDDwgqZiundE;"
		Skip to Main Content


		
			
				
				

				

			

		


		
			
				
					
						








	
		
	

	







						

						





























	
	
		
	
	
		
			

		
	

	
	
	



						





	
	
		
			
				IEEE Account

					Change Username/Password
	Update Address


			

			
				Purchase Details

					Payment Options
	Order History
	View Purchased Documents


			

			
				Profile Information

					Communications Preferences
	Profession and Education
	Technical Interests


			

			
				Need Help?

					US & Canada: +1 800 678 4333
	Worldwide:  +1 732 981 0060

					
	Contact & Support


			

		

		
			
				
					
							About IEEE Xplore
	Contact Us
	Help
	Accessibility
	Terms of Use
	Nondiscrimination Policy
	Sitemap
	Privacy & Opting Out of Cookies


						
							A not-for-profit organization, IEEE is the world's largest technical professional organization dedicated to advancing technology for the benefit of humanity.
Š Copyright 2021 IEEE - All rights reserved. Use of this web site signifies your agreement to the terms and conditions.
						

					


					

				

				
			

		

	


	
	


						
						






		
		
		
		
		
		
		
		
		
		
		
		
		
			
				
			
			
			
			
		
		
		
		
		
		

			


			

			
			


		
 		
		
			 

						
						









































	

		
		

		
		
		

		
			
		
		
		

		

		
		


		

		
		
		
		
		
		
		
		
		
		
	
	


















		
		
			
				
					
					
								
					
								
			
				
					
					
								
					
								
			
				
					
						








 



					
					
								
			
				
					
					
								
			
				
					
					
								
					
								
			
				
					
					
								
					
								
			
				
					
					
								
					
								
			
				
					
					
								
					
								
			
				
					
					
								
					
								
			
				
					
					
								
					
								
			
		
	




























		
			
					
			
					
			
					
			
				
					








					
			
					
			
					
			
					
			
					
			
					
			
					
			
		
		
	





	
	
	
	
	
	
	


	
	
	

	

















					

				

			


			
				
			
		

	";"""og:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""twitter:title"",""Multiple Channel with Crash Fault Tolerant Consensus Blockchain Network: A Case Study of Vegetables Supplier Supply Chain""
""twitter:card"",""summary""
""Description"",""Blockchain has become one of important technologies because of its capabilities such as transparency and privacy. Many enterprises see these capabilities as a b""
""og:title"",""Multiple Channel with Crash Fault Tolerant Consensus Blockchain Network: A Case Study of Vegetables Supplier Supply Chain""
""resourceName"",""08887678.pdf""
""language"",""en""
""title"",""Multiple Channel with Crash Fault Tolerant Consensus Blockchain Network: A Case Study of Vegetables Supplier Supply Chain | IEEE Conference Publication | IEEE Xplore""
""og:description"",""Blockchain has become one of important technologies because of its capabilities such as transparency and privacy. Many enterprises see these capabilities as a breakthrough to many cases, such as supply chain. This paper discusses a case of a vegetables supplier's problems in term of ledger. Generally, the company need one day to finish the ledger and sometimes there are some information distortion between supplier and client. This paper use hyperledger fabric to build blockchain network that is compatible with the supplier problems. The Blockchain network created with nine channels and crash fault tolerant by using kafka. This blockchain network is tested with two iterations which each iteration consists of 40 rounds and each round contains 3000 transactions. The first iteration throughput average is 27.9 tps with the highest throughput is in round 1 with a throughput of 34.1 tps and the lowest is in round 37 with a throughput of 25.3 tps. The second iteration throughput average is 28.1 tps with the highest throughput is in round 1 with a throughput of 32.8 tps and the lowest is in round 40 with a throughput of 21.3 tps. This performance indicates that multiple channel blockchain network could help the vegetables supplier to improve their ledger capabilities to be less than one day.""
""twitter:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-UA-Compatible"",""IE=Edge""
""viewport"",""width=device-width, initial-scale=1.0""
""dc:title"",""Multiple Channel with Crash Fault Tolerant Consensus Blockchain Network: A Case Study of Vegetables Supplier Supply Chain | IEEE Conference Publication | IEEE Xplore""
""twitter:description"",""Blockchain has become one of important technologies because of its capabilities such as transparency and privacy. Many enterprises see these capabilities as a breakthrough to many cases, such as supply chain. This paper discusses a case of a vegetables supplier's problems in term of ledger. Generally, the company need one day to finish the ledger and sometimes there are some information distortion between supplier and client. This paper use hyperledger fabric to build blockchain network that is compatible with the supplier problems. The Blockchain network created with nine channels and crash fault tolerant by using kafka. This blockchain network is tested with two iterations which each iteration consists of 40 rounds and each round contains 3000 transactions. The first iteration throughput average is 27.9 tps with the highest throughput is in round 1 with a throughput of 34.1 tps and the lowest is in round 37 with a throughput of 25.3 tps. The second iteration throughput average is 28.1 tps with the highest throughput is in round 1 with a throughput of 32.8 tps and the lowest is in round 40 with a throughput of 21.3 tps. This performance indicates that multiple channel blockchain network could help the vegetables supplier to improve their ledger capabilities to be less than one day.""
""Content-Encoding"",""UTF-8""
""Content-Type-Hint"",""text/html; charset=utf-8""
""Content-Length"",""42408""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=410&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094633-1043;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Ring Signature;JK Liu ; Advances in Cyber Security: Principles, Techniques …, 2019  Springer;;"… The information on the blockchain (including the transaction amount, the pseudonym of the sender

and receiver) is … and the Adversary \(\mathcal {A}\) in which \(\mathcal {A}\) is given access to

oracles \(\mathcal {JO}\), \mathcal {CO}\), \mathcal {SO}\) and the random oracle …";Autres articles;;null;;;;https://scholar.google.com/scholar?start=860&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094642-1081;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[HTML][HTML] A short server-aided certificateless aggregate multisignature scheme in the standard model;VC Trinh ; Security and Communication Networks, 2019  hindawi.com;United Kingdom;"… type of scheme, recently showed in [25, 43], can be applied well to the Bitcoin blockchain

application … ReplacePK ora- cle, and he/she still can ask RequestSig({????, ??????}?????) oracle

even if … the target identity ????? to C. Queries: A1 may adaptively ask the following oracles with …";Cité 2 fois;Les 6 versions;[HTML] hindawi.com;https://www.hindawi.com/journals/scn/2019/3424890/abs/;"[image: logo]
	Journals
	Publish with us
	Publishing partnerships
	About us
	Blog




Security and Communication Networks
+Journal Menu
[image:  ]PDF[image:  ] 
    
     Icons/Arrow Right White
     Created with Sketch.
     
         
    
     
         
             
                 
                     
                         
                             
                                 
                            
                             
                             
                                 
                            
                        
                    
                
            
        
    



Journal overview
For authorsFor reviewersFor editorsTable of ContentsSpecial Issues
[image:  ]         

Submit






Security and Communication Networks / 2019 / Article
Article SectionsOn this page
AbstractIntroductionPreliminariesConclusionAppendixData AvailabilityConflicts of InterestAcknowledgmentsReferencesCopyright


Research Article | Open Access
Volume 2019 |Article ID 3424890 | https://doi.org/10.1155/2019/3424890
Viet Cuong Trinh, ""A Short Server-Aided Certificateless Aggregate Multisignature Scheme in the Standard Model"", Security and Communication Networks, vol. 2019, Article ID 3424890, 14   pages, 2019. https://doi.org/10.1155/2019/3424890

Show citation
A Short Server-Aided Certificateless Aggregate Multisignature Scheme in the Standard Model


Viet Cuong Trinh[image:  ]   .cls-1{fill:#a6ce39;}.cls-2{fill:#fff;}.cls-3{fill:none;} orchid     

11Hong Duc University, Thanh Hoa, Vietnam

Show more
Academic Editor: Bela Genge
Received05 Nov 2018
Accepted20 Feb 2019
Published18 Mar 2019


Abstract
Aggregate signature scheme allows each signer to sign a different message and then all those signatures are aggregated into a single short signature. In contrast, multisignature scheme allows multisigners to jointly sign only one message. Aggregate multisignature scheme is a combination of both aforementioned signature schemes, where signers can choose to generate either a multisignature or an aggregate signature. This combination scheme has many concrete application scenarios such as Bitcoin blockchain, Healthcare, Multicast Acknowledgment Aggregation, and so on. On the other hand, to deal with the problems of expensive certificates in certified public key cryptography and key escrow in identity-based cryptography, the notion of certificateless public key cryptography has been introduced by Riyami and Paterson at Asiacrypt’03. In this paper, we propose the first certificateless aggregate multisignature scheme that achieves the constant-size of signature and is secure in the standard model under a generalization of the Diffie-Hellman exponent assumption. In our scheme, however, the signature is generated with the help of the authority.
1. Introduction
Certificateless Cryptography. In public key cryptography, a public key is just a random number, to certify that a public key belongs to a specific user we need to provide for this public key a certificate. Public Key Infrastructure () was introduced for such purpose; however implementing such  in the real world requires using a lot of resources since we need to provide, maintain, and revoke a large amount of certificates. Shamir [1] came up with an idea that if a public key is an identity of a specific user (official email address, for example), there is no need to certify this public key; this leads to the introducing of the notion of identity-based cryptography. However, since each identity is mapped to an arbitrary given fixed number, the public key is an arbitrary given fixed number. In traditional public key cryptosystems such as RSA or ElGamal, given such public key, user cannot generate the corresponding secret key. In all identity-based cryptosystems, user’s secret key is in fact generated by a private key generator () who knows the master key of the system; this leads to the fact that  knows all secret keys of users in the system; this problem is so-called key escrow problem. To deal with the problems of providing, maintaining, and revoking a large amount of certificates in traditional  and key escrow in identity-based cryptography, the notion of certificateless public key cryptography has been introduced by Riyami and Paterson at Asiacrypt’03 [2]. In a certificateless cryptosystem, the user’s full secret key includes two parts: the first part is a partial secret key generated by  from master key and user’s identity; the second part is a secret value chosen by user himself/herself. Due to the fact that user’s public key is still associated with user’s identity and the user’s full secret key includes a secret value chosen by user himself/herself, there is no need to use certificate to certify user’s public key and  does not know the user’s full secret key.
Certificateless signature scheme was first introduced in [2] and then has been deeply studied in [6–15] to name a few. Regarding the certificateless signature schemes secured in the standard model, there are currently two approaches to construct. First, using the Waters’ hash function [8, 9] or Yum-Lee generic transformations [6, 7], the advantage of this approach is that the resulting schemes can be secure under standard assumptions. However, due to using Waters’ hash function or Yum-Lee generic transformations, these schemes suffer relatively large public parameters and heavy computing time. Second, using direct approach [14, 15], which leads to quite efficient resulted schemes (constant-size of both public parameters and signature, as well as efficient computing time); however these schemes are only secure under strong assumptions (generalization of the Diffie-Hellman exponent assumption,  assumption), although  assumption introduced by Boneh and Boyen at Eurocrypt’05 [16] now has been accepted widely by researchers [17–22].
Aggregate Signature. Aggregate signature was first introduced by Boneh et al. at Eurocrypt’03 [23]. In this scheme, each signer in an aggregating set signs a different message and then all those signatures are aggregated into a single short signature, which is called aggregate signature. As shown in [5, 23–25], aggregate signature can be applied well to several practical applications such as Bitcoin blockchain, Secure BGP protocol (SBGP) [26], Healthcare, and so on. Certificateless aggregate signature was first proposed in [27], since then it has been studied in numerous of papers such as [5, 28–35], to name a few. However, all of these schemes either are insecure [29, 30, 35] or suffer a drawback that the signature size is linear in the number of signers in the aggregating set [5, 28, 31–34]. Moreover, all of these schemes need to use random oracle to prove the security. Very recently, the authors in [5] proposed a new certificateless aggregate scheme with short public parameters and achieving the highest level of security according to the classification given by Huang el al. [13] under a standard assumption. However, their scheme still suffers two drawbacks: the signature size is linear in the number of signers in the aggregating set and their scheme needs to use random oracle to prove the security. To our knowledge, the task of designing a certificateless aggregate signature scheme with short signature size and secured in the standard model is still open.
Multisignature. In contrast to aggregate signature, multisignature scheme allows multisigners to jointly sign only one message. This scheme was first introduced in [36], and then it has been the topic of many other works such as [25, 37–43], to name a few. At ACM CCS’01, Micali el al. [37] first formalized the security model for a multisignature scheme; they also proposed a multisignature scheme based on Schnorr-signature secured in this model. In [25], the authors defined a multisignature scheme with public key aggregation, for which all public keys of signers in the aggregating set are aggregated into a short aggregate public key through a new additional Key Aggregation algorithm. The advantage of this scheme is that the verifier can only take a constant-size of input (multisignature and aggregate public key) to verify the multisignature, which were showed in [25, 43] that this type of scheme can be applied well to the Bitcoin blockchain application. However, the downside of this scheme is that each aggregating set of signers needs to publish in advance its aggregate public key. Very recently, Boneh el al. [43] proposed a new such compact multisignature scheme with public key aggregation; their scheme however is secure in the random oracle model. Regarding the multisignature scheme in the certificateless setting, several schemes were proposed [3, 4, 44, 45]. The authors in [3] addressed the problem of fast verification but they did not give a formal security proof of their schemes. The authors in [4] proposed a certificateless multisignature scheme without using Pairings; they also gave a formal security proof for their scheme under standard assumption. All of these schemes achieve constant-size of signature; however they did not address the problem of public key aggregation and still need to use random oracle to prove the security.
1.1. Our Contribution and Organization of the Paper
In this paper, we extend the work in [14] to consider the combination of an aggregate signature scheme and a multisignature scheme, and in the context of certificateless. More precisely, in our server-aided certificateless aggregate multisignature scheme (- for short), an aggregating set of signers can choose to generate either an aggregate signature or a multisignature with the help of private key generator (); for simplicity such signature is called an aggregate multisignature. If the aggregating set of signers contains only one signer, the resulting signature is a usual signature and the signer does not need the help from .
More precisely, our - scheme has following properties:(i)the first certificateless aggregate multisignature scheme;(ii)the signature which contains four elements in all cases;(iii)being secure against strong Type I and strong Type II adversaries (according to the classification given by Huang el al. [13]) in the standard model under  assumptions;(iv)server-aided scheme;(v)support public key aggregation;(vi)public key size, signing time, and verifying time which depend on the maximum number of signers for one aggregating set, which is fixed at the setup. More details can be found in the Tables 1 and 2.
		

	 	Signature	Secret-key	Public-key	Signing	Verifying
	

	[3]	1	1	2		3P + 1H
	

	[4]	1+ 1	2	2		(+ 3)exp + 2H
	

	[5]	(+ 1)	1+ 1	2	4exp + 3H	2exp + 3P (3+ 1)H
	

	Ours	3+ 1	3+ 1	3+ (n + 3)	(2+ 9)exp + (2+ 1)H	(+ 1)exp + 3P+(2+ 1)H
	





Table 1 
 is the size of the aggregating set of signers;  is fixed at the setup.  denotes pairing computation,  denotes exponentiation, and  denotes hash operation. Note that only our scheme is described in type 3 Pairings.


		

	 	Multi/Aggre	non-interactive	Security	PKA	Server-Aid
	

	[3]	yes/no	no	not known	no	no
	

	[4]	yes/no	no	ROM+Strong Type I,II+ECDLP assumption	no 
no	no 
no
	

	[5]	no/yes	yes	ROM+Super Type I,II
+CDH problem	no 
no	no 
no
	

	Ours	yes/yes	no	SM+Strong Type I,II+GDDHE assumption	yes	yes
	





Table 2 
ROM denotes random oracle model, SM denotes standard model, and PKA denotes supporting public key aggregation.


Although our - scheme requires server-aid and is secure in a strong assumption ( assumption), our scheme might be considered as a partial answer for the question of designing a certificateless aggregate signature scheme which has short signature size and is secure in the standard model. In addition, our scheme is not only certificateless aggregate signature but also certificateless multisignature with public key aggregation. This type of scheme, recently showed in [25, 43], can be applied well to the Bitcoin blockchain application. We also note that the server-aided model is not new; this model has been used in many other contexts. Regarding the context of signature, we can find several other signature schemes in the literature which use the server-aid model [46–49]. Regarding the  assumption, it is introduced by Boneh and Boyen at Eurocrypt’05 [16] and now has been accepted and used widely by researchers with a lot of papers based on it [50–52].
We give in Tables 1 and 2 the detailed comparison between our scheme and some latest relevant schemes in the literature.
In the Table 2, regarding noninteractive, to generate a multisignature, in [3] the first signer in the aggregating set signs the message and then sends the resulting signature to the second signer, the second signer based on this signature and his/her secret key to generate a new signature and sends this new signature to the third signer, and this process continues to the last signer. That means it needs  rounds to generate a multisignature,  is the size of the aggregating set. In [4], each signer needs to broadcast a value to  other signers and receives  values from  other signers before generating multisignature as in usual noninteractive scheme [40–42]. In our scheme, in the first round,  relies on the description of the aggregating set and messages to compute four elements and sends them to  signers, all signers then based on these values to generate aggregate multisignature as in usual noninteractive scheme [40–42].
Regarding security model, we only consider the selective model where adversary has to declare the identity of target user at the beginning of security game; the challenger thus does not need to guess the identity of target user at the beginning of security game. In scheme [4, 5], the authors considered a more practical model, the adaptive model where adversary does not have to declare the identity of target user at the beginning of security game; however in their security proof, the challenger needs to guess in advance the identity of the target user at the beginning of security game; their schemes therefore lose a factor in the reduction to the corresponding assumptions. We also note that all of these schemes need to use random oracle to prove the security.
Paper organization. In the Preliminaries section, we present definition and security model for our - scheme, and then some useful tools for our construction. We next describe our - scheme and its security analysis in Section 3. Section 4 is devoted for the conclusion.
2. Preliminaries
In this section, based on security models in [4, 5, 13] we first define the security model for our - scheme; we then give some useful tools that we need to construct our scheme such as Bilinear Groups, Target Collision Resistant Hash Function, and Assumptions.
2.1. Server-Aided Certificateless Aggregate Multisignature Scheme
2.1.1. Definition
There are three entities involved in our server-aided certificateless aggregate multisignature scheme:(1)a designated authority acting as a Private Key Generator ;(2)user (or signer) who combines with  and all other users in an aggregating set to generate an aggregate multisignature (either an aggregate signature or a multisignature). Note that if the aggregating set of users contains just one user, user relies solely on his/her full secret key (without the help of ) to generate the aggregate multisignature. In this case, the aggregate multisignature is exactly the usual user’s signature;(3)verifier who is able to check the validity of an aggregate multisignature.
We also note that, in a certificateless system, a user’s full secret key  includes two parts: the first part is a partial secret key  generated by the  from master key and user’s identity; the second part is a secret value  chosen by user himself/herself.
More formally, our - scheme consists of the following nine probabilistic algorithms.(i): it takes as input a security parameter ; this algorithm generates system parameters  implicitly including the maximum number of users in an aggregating set  and a master secret key .(ii)---: it takes as input , , and a user’s identity ; this algorithm generates the partial secret key .(iii)---: it takes as input the security parameter  and a user’s identity ; this algorithm generates the user’s secret value .(iv)--: it takes as input ; this algorithm generates the user’s public key .(v)---: it takes as input  and ; the algorithm generates the user’s full secret key .(vi) Aggregation: suppose that the aggregating set of users is . There are two cases: if  contains just one user with identity , the algorithm takes as input a message , a user’s full secret key , and ; it generates a signature ; note that in this case the algorithm works as a usual signing algorithm. If  contains more than one user, the algorithm now is run by  and all users in , takes as input messages  and the description of , and outputs an aggregate multisignature  on messages . Note that the signature is called multisignature as usual if all  are the same.(vii) Aggregation Verification: it takes as input an aggregate multisignature , the description of aggregating set of users , and messages  and outputs either  indicating that  is a valid signature or  indicating that  is not a valid signature.
2.1.2. Adversary’s Oracles
We have two types of adversary in our - scheme, the first one represents a third party adversary (so-called Type I adversary) and the second one represents the malicious  (so-called Type II adversary), and those adversary can ask the following oracles:(i): when adversary requests a partial secret key corresponding to identity , he/she should get the user’s partial secret key .(ii): when adversary requests a user’s secret value corresponding to identity , he/she should get the user’s secret value . Note that if adversary asks both  and  oracles on input , he/she will get the full secret key of user associated with identity .(iii): when adversary requests a public key corresponding to identity , he/she should get the user’s public key .(iv): adversary can choose  and replace the original public key  to a new public key  by making a query  to challenger.(v): when adversary requests an aggregate multisignature on messages  corresponding to users with identities , he/she should get a valid aggregate multisignature  corresponding to . In addition, in case , since in the  algorithm the aggregate multisignature is generated by  and all users in  via public channel; adversary may also get the output of  as well as the outputs of some users in .
Informally, a third party adversary (an outsider attacker) cannot know the master key; however he/she can replace any public key with a secret value of his/her choice. To exclude the trivial attack, he/she obviously cannot know the partial secret key of the target user. Regarding malicious  (an insider attacker), this adversary knows the master key; however to exclude the trivial attack he/she cannot know the secret value or replace the public key of the target user.
On the other hand, according to the classification given by Huang el al. [13], there are three levels of adversary:(i)normal adversary: this adversary cannot ask  oracle if at least one public key of a user in  has been replaced;(ii)strong adversary: this adversary still can ask  oracle even if all public keys of users in  have been replaced;(iii)super adversary: this adversary is not required to supply the secret value  when asking  oracle, and he/she still can ask  oracle even if all public keys of users in  have been replaced;
In this paper, we consider the strong adversary for both type I and type II.
2.1.3. Security Model
We define two selective security games corresponding to two types of adversary, Game 1 corresponds to third party adversary (denote -strong Type I adversary), and Game 2 corresponds to malicious  (denote -strong Type II adversary).
Our - scheme is secure if it resists both adversaries  and .
Game 1. The first game is between  and the challenger .
Initialization:  runs the  algorithm to generate a master secret key  and public system parameters .  keeps  secret and gives  to .  declares the target user by sending the target identity  to .
Queries:  may adaptively ask the following oracles with : , , , , and . Note that .
Output: Finally,  outputs (,), where , and  is an aggregate multisignature on messages . We say that  wins the game if the following conditions are verified: (1) and  have never been queried.(2) which outputs  is a valid aggregate multisignature on messages  under public keys corresponding to .
Denote  as the success probability that adversary  wins the above game.
Game 2. The second game is between  and the challenger .
Initialization:  runs the  algorithm to generate a master secret key  and public system parameters .  gives both public  and  to .  declares the target user by sending the target identity  to .
Queries:  may adaptively ask the following oracles with : , , , and  . Note that .
Output: Finally,  outputs (,), where , and  is an aggregate multisignature on messages . We say that  wins the game if the following conditions are verified: (1), , and  have never been queried.(2) which outputs  is a valid aggregate multisignature on messages  under public keys corresponding to .
Denote  the success probability that adversary  wins the above game.
Definition 3. We say that our server-aided certificateless aggregate multisignature scheme is selectively existentially unforgeable against polynomially bounded adversaries  and  if the success probabilities  and  are negligible, where  is the security parameter.
2.2. Bilinear Groups
In this section, we recall the definition of bilinear map and three types of Pairings. Let  is the security parameter, , and , , and  are three finite multiplicative abelian groups of order . Suppose that  are generators of  and , respectively. Denote  as an admissible asymmetric bilinear map, where for all (1);(2)for  and , ;(3) is efficiently computable.
 The tuple  is then called a bilinear map group system and is in(1)Type 1 Pairings if (2)Type 2 Pairings if  but there is an efficiently computable homomorphism (3)Type 3 Pairings if  but there is no efficiently computable homomorphism between  and 
In [16], the authors introduced the generalization of the Diffie-Hellman exponent assumption in Type 3 Pairings bilinear map group system.
Assume , and  are three -tuples of -variate polynomials over . Thus, , , and  are just three lists containing  multivariate polynomials each. We write ,  and impose that . For any function  and vector ,  stands for , . We use a similar notation for the -tuples  and . Let . It is said that  depends on , which denotes , when there exists a linear decomposition
Let  be as above and . The  problem is defined as follows.
Definition 4 ( [16]). Given the tuple  compute .
Definition 5 ( [16]). Given  as above and  decide whether .
2.3. Target Collision Resistant Hash Function
Definition 6. A target collision resistant hash function  guarantees that given a random element  which is from the valid domain of , a PPT adversary  cannot find  such that . We let  be the advantage of  in successfully finding collisions from a target collision resistant hash function , where DH is the valid input domain of ;  is the security parameter. If a hash function is chosen from a target collision resistant hash function family,  is negligible.
In this paper, for simplicity we call such target collision resistant hash function a hash function.
2.4. Assumptions
In this section, we recall one assumption and introduce a new assumption which are used to prove the security of our - scheme. Those assumptions are in the similar style of the PS assumption 1 in [52].
Definition 7.  Assumption 1. Let  be a bilinear group setting of type 3. Choose , we define the oracle  on input  that chooses a random  and outputs the tuple .
Given  and unlimited access to this oracle, no adversary can have nonnegligible success probability to generate a pair , with , for a new scalar  not asked to .
Intuitively, when comparing to PS assumption 1 in [52], we set  and the oracle  outputs just two more elements in the group  which offers no help for the adversary. It is thus obvious that our Assumption 1 holds and we refer the reader to [52] for details. We also note that this assumption was first introduced in [14].
Definition 8.  Assumption 2. Let  be a bilinear group setting of type 3, with  (resp., ) being a generator of  (resp., ). Choose ; we define two oracles: the oracle  which is on input  outputs the triplet, , ; the oracle  which is on input  for some set  chooses a random  and outputs the tuple , , , .
Given  and unlimited access to both oracles  and , no adversary can have nonnegligible success probability to generate a tuple , , , , with , and there exist at least one , not asked to , and input  not asked to .
For completeness, we prove that our Assumption 2 holds in Bilinear Generic Group in Appendix A.
3. Our - Scheme
In this section, we first gives the detailed construction of our - scheme, then in the next section we give the security analysis of our - scheme.
3.1. Construction
The construction of our - scheme is detailed as follows.
: it takes as input the security parameter ; the algorithm generates a bilinear map group system . Next, it chooses random scalars , and  is the maximum number of users in an aggregating set, as well as two hash functions  where
Finally, it sets the public parameter
and the master secret key .
---: it takes as input , , and the user ’s identity ; let ; the algorithm generates a partial secret key 
for user .
---: it takes as input user ’s identity ; the algorithm chooses  and sets  as user ’s secret value.
--: it takes as input  and ; the algorithm sets  as the public key of user .
---: it takes as input  and ; the algorithm outputs  as the full secret key of user .
: denote  as the aggregating set of users, . There are two cases, if , the algorithm takes as input , , , and a message . The algorithm first chooses  and computes  and then outputs signature , where
If , the algorithm now is run by  and all users in . More precisely, the algorithm consists of two separate following algorithms: note that :(1)First algorithm:  takes as input , the description of  as well as ; note that if all messages  are the same, the signature is multisignatures.  follows strictly the order of pair  to compute  as follows: Next, it chooses  and computes  are then sent to all users in  via public channel or  simply publishes it to the public domain.  then is not involved in the second algorithm.(2)Second algorithm: it takes as input  and runs by all users in . First, each user  takes as input  and computes the pair: Finally, select one user in  as designated combiner, , other remaining users in  send their above outputs to this designated combiner via public channel, and the aggregate multisignature is then built as follows: designated combiner takes as input  and chooses  and outputs the aggregate multisignature , where and . Note that the designated combiner computes: it take as input aggregate multisignature , the description of aggregating set of users , messages , and , the algorithm computes , and
note that he/she can compute  from  in .
Finally, the aggregate multisignature is accepted (output ) if the following equation holds:
Correctness. It is easy to show that 
Multisignature Scheme with Public Key Aggregation. In [25], the authors defined a multisignature scheme with public key aggregation, for which the public keys of users in the aggregating set  are aggregated into a short aggregate public key in advance through an additional Key Aggregation algorithm. The advantage of this scheme is that the verifier can only take a constant-size of input (multisignature and aggregate public key) to verify the multisignature, which were showed in [25, 43] that this type of scheme can be applied well to the Bitcoin blockchain application.
It is clear that our scheme is a multisignature scheme with public key aggregation as defined in [25], since we can add a new Key Aggregation algorithm which computes in advance the pair (, ) as an aggregate public key of the aggregating set . The verifier therefore just needs to take a constant-size of input to verify the validity of the signature. Note that we can use a short length of bits to describe the aggregating set .
Remark 9. We also note that, in our scheme, for an aggregate signature, we do not need to require that all messages  are different.
3.2. Efficiency
Regarding the signature size, as in the construction and detailed in Table 1, the signature in our - scheme just contains four elements, three in the group  and one in the group . If we decide to use NIST’s figures [53], then to achieve 80 bits or 128 bits of security (that means the adversary needs at least  or  operations to break the security of our scheme), each element in the group  is about 160 bits or 256 bits and in the group  is about 1024 bits or 3072 bits. This leads to the fact that the signature size of our scheme is 1504 bits or 3840 bits corresponding to the security parameter 80 bits or 128 bits, respectively.
Similarly, the user’s full secret key size of our scheme is 640 bits or 1024 bits corresponding to the security parameter 80 bits or 128 bits, respectively.
Regarding the signing phase, there are two cases:(1) = 1, the signing phase requires five exponentiations in , one exponentiation in , and two hash operations.(2), the signing phase requires  exponentiations in ,  exponentiations in , and  hash operations, where  is the size of the aggregating set of signers.
Regarding the verification phase, there are also two cases:(1) = 1, the verification phase requires two exponentiations in , three Pairings, and two hash operations.(2), the verification phase requires  exponentiations in , three Pairings, and  hash operations, where  is the size of the aggregating set of signers.
Overall, for both storage and computational complexity, our scheme can meet the requirements for a lightweight device, that means our scheme is suitable for resource-constrained applications such as Bitcoin blockchain, Healthcare, Multicast Acknowledgment Aggregation, vehicular ad hoc networks, wireless sensor networks, Internet of Things, and so on.
3.3. Security
We give in this section two theorems which show that our - scheme is secure.
3.3.1. Secure against Strong Type I Adversary
We first prove that our - scheme is secure against strong Type I adversary.
Theorem 10. If there exists a strong Type I adversary  defined in Game 1 (see Section 2.1.3), who breaks the security of our - scheme with probability , then there exists an adversary  who can break the security of the Assumption 2 with the same probability .
Proof. Suppose that  is an adversary against our Assumption 2; we let  act as a challenger in Game 1 (see Section 2.1.3), that means  simulates  and then uses the output of  to break the security of the Assumption 2.
At the beginning,  has an instance of Assumption 2: , , , , , , ,  as well as the right to access two oracles  and . Note that, for oracle , on input , output the triplet , , . For oracle , on input , choose a random  and output , , , .
Note that  does not know the values , , and .
To simulate ,  first receives from  the target identity  for which he/she intends to attack.
 chooses two hash functions  whereand then gives , , , , , ,  to  as public parameters.
To simulate ,  must manage to answer oracles as follows.
.  simply requests oracle  on input  and directly forwards the result to . Note that, following Game 1 (see Section 2.1.3),  cannot make  query on .
.  chooses  and gives  to .
.  first checks whether the  has been queried before; if it is not the case  first make this query on  itself, using the above descriptions. In both cases,  knows ; thus  gives  to .
.  knows  and then simply sets .
.  computes , and , then  requests oracle  on input  to get the tuple:Since  knows  (even if  has been replaced), he/she can easily compute the aggregate multisignature  as the  algorithm and returns  to .
We also note here that, in our  algorithm, the output of  and the outputs of users who are not designated combiner are sent via public channel (or made public), that means  can request to know these outputs.
Note that the output of  isand the output of each user in  isfor some . However, since  knows and all ,  can easily answer  by choosing  and implicitly sets .
Finally,  outputs a tuple , ,  for which  has never been queried; note that .
From , where,  is computed as in  algorithm, and  knows all ; it";"""dc.publisher"",""Hindawi""
""og:image"",""https://images.hindawi.com/journals/scn/scn.banner.jpg""
""og:image:width"",""600""
""twitter:card"",""summary_large_image""
""citation_journal_title"",""Security and Communication Networks""
""language"",""en""
""og:description"",""Aggregate signature scheme allows each signer to sign a different message and then all those signatures are aggregated into a single short signature. In contrast, multisignature scheme allows multisigners to jointly sign only one message. Aggregate multisignature scheme is a combination of both aforementioned signature schemes, where signers can choose to generate either a multisignature or an aggregate signature. This combination scheme has many concrete application scenarios such as Bitcoin blockchain, Healthcare, Multicast Acknowledgment Aggregation, and so on. On the other hand, to deal with the problems of expensive certificates in certified public key cryptography and key escrow in identity-based cryptography, the notion of<i> certificateless</i> public key cryptography has been introduced by Riyami and Paterson at Asiacrypt&#x2019;03. In this paper, we propose the first certificateless aggregate multisignature scheme that achieves the constant-size of signature and is secure in the standard model under a generalization of the Diffie-Hellman exponent assumption. In our scheme, however, the signature is generated with the help of the authority.""
""prism.issn"",""1939-0114""
""citation_issn"",""1939-0114""
""dc:title"",""A Short Server-Aided Certificateless Aggregate Multisignature Scheme in the Standard Model""
""Content-Encoding"",""UTF-8""
""citation_pdf_url"",""https://downloads.hindawi.com/journals/scn/2019/3424890.pdf""
""robots"",""index""
""google-site-verification"",""AxEuDsL7vXGOxRe53-uFhOk2ODN0bbXMeuBy6Pfq4ww""
""citation_author"",""Trinh, Viet Cuong""
""dc.date"",""2019/03/18""
""prism.volume"",""2019""
""citation_doi"",""https://doi.org/10.1155/2019/3424890""
""prism.publicationName"",""Security and Communication Networks""
""dc.title"",""A Short Server-Aided Certificateless Aggregate Multisignature Scheme in the Standard Model""
""Author"",""Hindawi""
""citation_volume"",""2019""
""dc.language"",""en""
""Content-Language"",""en""
""authors"",""Viet Cuong Trinh""
""citation_title"",""A Short Server-Aided Certificateless Aggregate Multisignature Scheme in the Standard Model""
""citation_year"",""2019""
""citation_publisher"",""Hindawi""
""dc.format"",""text/html""
""description"",""Aggregate signature scheme allows each signer to sign a different message and then all those signatures are aggregated into a single short signature. In contrast, multisignature scheme allows multisigners to jointly sign only one message. Aggregate multisignature scheme is a combination of both aforementioned signature schemes, where signers can choose to generate either a multisignature or an aggregate signature. This combination scheme has many concrete application scenarios such as Bitcoin blockchain, Healthcare, Multicast Acknowledgment Aggregation, and so on. On the other hand, to deal with the problems of expensive certificates in certified public key cryptography and key escrow in identity-based cryptography, the notion of<i> certificateless</i> public key cryptography has been introduced by Riyami and Paterson at Asiacrypt&#x2019;03. In this paper, we propose the first certificateless aggregate multisignature scheme that achieves the constant-size of signature and is secure in the standard model under a generalization of the Diffie-Hellman exponent assumption. In our scheme, however, the signature is generated with the help of the authority.""
""og:image:type"",""image/jpeg""
""citation_date"",""2019/03/18""
""title"",""A Short Server-Aided Certificateless Aggregate Multisignature Scheme in the Standard Model"",""A Short Server-Aided Certificateless Aggregate Multisignature Scheme in the Standard Model""
""twitter:image"",""https://images.hindawi.com/journals/scn/scn.banner.jpg""
""citation_online_date"",""2019/03/18""
""twitter:site"",""website""
""dc.type"",""Research Article""
""dc.source"",""Security and Communication Networks""
""dc.creator"",""Trinh, Viet Cuong""
""citation_fulltext_html_url"",""https://www.hindawi.com/journals/scn/2019/3424890/""
""prism.publicationDate"",""2019/03/18""
""Content-Length"",""3178083""
""citation_xml_url"",""https://downloads.hindawi.com/journals/scn/2019/3424890.xml""
""Content-Type"",""text/html; charset=UTF-8""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""og:type"",""website""
""twitter:title"",""A Short Server-Aided Certificateless Aggregate Multisignature Scheme in the Standard Model""
""dc.description"",""Aggregate signature scheme allows each signer to sign a different message and then all those signatures are aggregated into a single short signature. In contrast, multisignature scheme allows multisigners to jointly sign only one message. Aggregate multisignature scheme is a combination of both aforementioned signature schemes, where signers can choose to generate either a multisignature or an aggregate signature. This combination scheme has many concrete application scenarios such as Bitcoin blockchain, Healthcare, Multicast Acknowledgment Aggregation, and so on. On the other hand, to deal with the problems of expensive certificates in certified public key cryptography and key escrow in identity-based cryptography, the notion of<i> certificateless</i> public key cryptography has been introduced by Riyami and Paterson at Asiacrypt&#x2019;03. In this paper, we propose the first certificateless aggregate multisignature scheme that achieves the constant-size of signature and is secure in the standard model under a generalization of the Diffie-Hellman exponent assumption. In our scheme, however, the signature is generated with the help of the authority.""
""og:title"",""A Short Server-Aided Certificateless Aggregate Multisignature Scheme in the Standard Model""
""citation_abstract"",""Aggregate signature scheme allows each signer to sign a different message and then all those signatures are aggregated into a single short signature. In contrast, multisignature scheme allows multisigners to jointly sign only one message. Aggregate multisignature scheme is a combination of both aforementioned signature schemes, where signers can choose to generate either a multisignature or an aggregate signature. This combination scheme has many concrete application scenarios such as Bitcoin blockchain, Healthcare, Multicast Acknowledgment Aggregation, and so on. On the other hand, to deal with the problems of expensive certificates in certified public key cryptography and key escrow in identity-based cryptography, the notion of<i> certificateless</i> public key cryptography has been introduced by Riyami and Paterson at Asiacrypt&#x2019;03. In this paper, we propose the first certificateless aggregate multisignature scheme that achieves the constant-size of signature and is secure in the standard model under a generalization of the Diffie-Hellman exponent assumption. In our scheme, however, the signature is generated with the help of the authority.""
""og:image:height"",""315""
""prism.doi"",""https://doi.org/10.1155/2019/3424890""
""dcterms.issued"",""2019/03/18""
""viewport"",""width=device-width, initial-scale=1""
""twitter:description"",""Aggregate signature scheme allows each signer to sign a different message and then all those signatures are aggregated into a single short signature. In contrast, multisignature scheme allows multisigners to jointly sign only one message. Aggregate multisignature scheme is a combination of both aforementioned signature schemes, where signers can choose to generate either a multisignature or an aggregate signature. This combination scheme has many concrete application scenarios such as Bitcoin blockchain, Healthcare, Multicast Acknowledgment Aggregation, and so on. On the other hand, to deal with the problems of expensive certificates in certified public key cryptography and key escrow in identity-based cryptography, the notion of<i> certificateless</i> public key cryptography has been introduced by Riyami and Paterson at Asiacrypt&#x2019;03. In this paper, we propose the first certificateless aggregate multisignature scheme that achieves the constant-size of signature and is secure in the standard model under a generalization of the Diffie-Hellman exponent assumption. In our scheme, however, the signature is generated with the help of the authority.""
""dc.identifier"",""https://doi.org/10.1155/2019/3424890""
""prism.section"",""Research Article""
""og:url"",""https://www.hindawi.com/journals/scn/2019/3424890/""
";https://scholar.google.com/scholar?start=900&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094621-998;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[PDF][PDF] ?????????? ??????-????????? ?? ?????? ?????????: ????????? ????????? ?????-????????? ? ???????????????? ?????;?? ???????? ; ????????????? ?????????: ????. ????. ???? ?? …, 2019  nsuem.ru;;"… We argue in a favour of the following thesis: a concept of a smart- contract is not new and the

blockchain is only one variant for smart-contract implementation along with a trusted third party.

Key words: smart-contract, blockchain, cryptocurrency, business- process, oracle …";Autres articles;;[PDF] nsuem.ru;https://nsuem.ru/library/resources/sborniki-s-mezhdunarodnym-uchastiem/%D0%9F%D1%80%D0%B0%D0%B2%D0%BE%20%D0%B8%20%D1%8D%D0%BA%D0%BE%D0%BD%D0%BE%D0%BC%D0%B8%D0%BA%D0%B0_%D0%A71_%D0%A1%D0%B0%D0%B2%D1%87%D0%B5%D0%BD%D0%BA%D0%BE_%D1%81%D0%B1.%20%D1%81%D1%82%D0%B0%D1%82%D0%B5%D0%B9_%D1%8E%D1%80%D0%B8%D0%B4_%D1%84%D0%BE%D1%80%D1%83%D0%BC_2019.pdf#page=250;;;https://scholar.google.com/scholar?start=810&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094658-1155;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Knowledge Graph-Enhanced Blockchains by Integrating a Graph-Data Service-Layer;BA Naim, W Klas ; … Sixth International Conference on Internet of …, 2019  ieeexplore.ieee.org;;"… Abstract— No doubt that blockchain technology has revolutionized a decentralized consensus

technique allowing for increased security and trust among people and machines … Keywords—

Semantic Blockchain, Blockchain reasoning, Data Graphs …";Cité 1 fois;Les 2 versions;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/8924808/8939160/08939173.pdf?casa_token=37kb0D1KZNEAAAAA:RavOf1w-VUyzyr3Qtvfc27EI6hZy7icFEd19V_As29qTRxmVhq9XTQeLL3ObyQAtlwP_HRbhqCM;"
		Skip to Main Content


		
			
				
				

				

			

		


		
			
				
					
						








	
		
	

	







						

						





























	
	
		
	
	
		
			

		
	

	
	
	



						





	
	
		
			
				IEEE Account

					Change Username/Password
	Update Address


			

			
				Purchase Details

					Payment Options
	Order History
	View Purchased Documents


			

			
				Profile Information

					Communications Preferences
	Profession and Education
	Technical Interests


			

			
				Need Help?

					US & Canada: +1 800 678 4333
	Worldwide:  +1 732 981 0060

					
	Contact & Support


			

		

		
			
				
					
							About IEEE Xplore
	Contact Us
	Help
	Accessibility
	Terms of Use
	Nondiscrimination Policy
	Sitemap
	Privacy & Opting Out of Cookies


						
							A not-for-profit organization, IEEE is the world's largest technical professional organization dedicated to advancing technology for the benefit of humanity.
Š Copyright 2021 IEEE - All rights reserved. Use of this web site signifies your agreement to the terms and conditions.
						

					


					

				

				
			

		

	


	
	


						
						






		
		
		
		
		
		
		
		
		
		
		
		
		
			
				
			
			
			
			
		
		
		
		
		
		

			


			

			
			


		
 		
		
			 

						
						









































	

		
		

		
		
		

		
			
		
		
		

		

		
		


		

		
		
		
		
		
		
		
		
		
		
	
	


















		
		
			
				
					
					
								
					
								
			
				
					
					
								
					
								
			
				
					
						








 



					
					
								
			
				
					
					
								
			
				
					
					
								
					
								
			
				
					
					
								
					
								
			
				
					
					
								
					
								
			
				
					
					
								
					
								
			
				
					
					
								
					
								
			
				
					
					
								
					
								
			
		
	




























		
			
					
			
					
			
					
			
				
					








					
			
					
			
					
			
					
			
					
			
					
			
					
			
		
		
	





	
	
	
	
	
	
	


	
	
	

	

















					

				

			


			
				
			
		

	";"""og:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""twitter:title"",""Knowledge Graph-Enhanced Blockchains by Integrating a Graph-Data Service-Layer""
""twitter:card"",""summary""
""Description"",""No doubt that blockchain technology has revolutionized a decentralized consensus technique allowing for increased security and trust among people and machines. ""
""og:title"",""Knowledge Graph-Enhanced Blockchains by Integrating a Graph-Data Service-Layer""
""resourceName"",""08939173.pdf""
""language"",""en""
""title"",""Knowledge Graph-Enhanced Blockchains by Integrating a Graph-Data Service-Layer | IEEE Conference Publication | IEEE Xplore""
""og:description"",""No doubt that blockchain technology has revolutionized a decentralized consensus technique allowing for increased security and trust among people and machines. This has paved the way for many and various types of applications to make use of the notions of this promising technology. These applications are concerned with persisting historically attested and tamper resistant datasets. Having these datasets persisted calls for techniques that fulfill the emerging requirements for managing these stored datasets efficiently. This includes providing efficient and direct ways to access, query, interlink, and retrieve those datasets. The absence of such solutions imposes many hindrances to make use of the full extent of the blockchain technology. In this paper, we introduce our approach which aims at adding a data-graph service-layer to the component stack of a blockchain system. This added service-layer employs data graphs such as RDF-encoded data, reasoning, and the underlying inference rules allowing to implement applications with advanced requirements for sophisticated data models that need to be built on top of blockchain infrastructure.""
""twitter:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-UA-Compatible"",""IE=Edge""
""viewport"",""width=device-width, initial-scale=1.0""
""dc:title"",""Knowledge Graph-Enhanced Blockchains by Integrating a Graph-Data Service-Layer | IEEE Conference Publication | IEEE Xplore""
""twitter:description"",""No doubt that blockchain technology has revolutionized a decentralized consensus technique allowing for increased security and trust among people and machines. This has paved the way for many and various types of applications to make use of the notions of this promising technology. These applications are concerned with persisting historically attested and tamper resistant datasets. Having these datasets persisted calls for techniques that fulfill the emerging requirements for managing these stored datasets efficiently. This includes providing efficient and direct ways to access, query, interlink, and retrieve those datasets. The absence of such solutions imposes many hindrances to make use of the full extent of the blockchain technology. In this paper, we introduce our approach which aims at adding a data-graph service-layer to the component stack of a blockchain system. This added service-layer employs data graphs such as RDF-encoded data, reasoning, and the underlying inference rules allowing to implement applications with advanced requirements for sophisticated data models that need to be built on top of blockchain infrastructure.""
""Content-Encoding"",""UTF-8""
""Content-Type-Hint"",""text/html; charset=utf-8""
""Content-Length"",""41420""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=970&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094621-995;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;A survey on consensus mechanisms and mining strategy management in blockchain networks;W Wang, DT Hoang, P Hu, Z Xiong, D Niyato… ; IEEE …, 2019  ieeexplore.ieee.org;;"… ing immutable ledgers as well as platforms for data-driven autonomous organization.

Proposed by the famous grassroot cryptocurrency project “Bitcoin” [1], the blockchain

network VOLUME 4, 2016 1 Page 2. 2169-3536 (c) 2018 IEEE …";Cité 386 fois;D Niyato;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/6287639/6514899/08629877.pdf;"
		
	";"""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""dc:title"",""IEEE Xplore Full-Text PDF:""
""Content-Encoding"",""UTF-8""
""resourceName"",""08629877.pdf""
""language"",""es""
""Content-Length"",""2565""
""title"",""IEEE Xplore Full-Text PDF:""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=810&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094607-931;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[HTML][HTML] On tight security proofs for Schnorr signatures;N Fleischhacker, T Jager, D Schröder ; Journal of Cryptology, 2019  Springer;United States of America;"… for Schnorr signatures into an algorithm solving the discrete logarithm problem must lose a factor

of at least \(q^{1/2}\). Their result is quite strong, as they rule out reductions even for adversaries

that do not have access to a signing oracle and receive … At Crypto 2008 Garg et al …";Cité 7 fois;Les 3 versions;[HTML] springer.com;https://link.springer.com/article/10.1007/s00145-019-09311-5;"
    
    
    
        
            
            
                
            

            
        
    


    
        
        

        
            
                Advertisement

                    

            

        


    
        
            
                
    
        
            
            [image: SpringerLink]
        
        
        
    


            

            
                
    
        
            
                Search
                
                    
                
            
        
        
            	
                    Log in
                


        
    

    



            

        

    

    
        
            
                
                    
                        
    
        Search SpringerLink
        
            
            
                Search
                
                    
                
            
            
                
            
            
        

    




                    

                

            

        

    



        

    
        
            
                
                
                    
                        
                            On Tight Security Proofs for Schnorr Signatures
                        

                        
    
        
            
                Download PDF
                
            
        
    



                    

                

            

            
                
    
        
            
                Download PDF
                
            
        
    


            


            
                
    

            



            
                
                    
                        	Published: 06 February 2019



                        
                        On Tight Security Proofs for Schnorr Signatures

                        	Nils Fleischhacker1, 
	Tibor Jager2 & 
	Dominique SchrÜder3 


                        
                            
    Journal of Cryptology

                            volume 32, pages566–599(2019)Cite this article
                        

                        
    

                        
                            
    
        	
                    771 Accesses

                
	
                    5 Citations

                
	
                Metrics details

            


    




                        

                            
    

    

                    
                


                
                    Abstract
The Schnorr signature scheme is the most efficient signature scheme based on the discrete logarithm problem and a long line of research investigates the existence of a tight security reduction for this scheme in the random oracle model. Almost all recent works present lower tightness bounds and most recently Seurin EUROCRYPT 2012 showed that under certain assumptions the non-tight security proof for Schnorr signatures in the random oracle by Pointcheval and Stern EUROCRYPT’96 is essentially optimal. All previous works in this direction rule out tight reductions from the (one-more) discrete logarithm problem. In this paper, we introduce a new meta-reduction technique, which shows lower bounds for the large and very natural class of generic reductions. A generic reduction is independent of a particular representation of group elements. Most reductions in state-of-the-art security proofs have this property. It is desirable, because then the reduction applies generically to any concrete instantiation of the group. Our approach shows unconditionally that there is no tight generic reduction from any natural non-interactive computational problem \(\Pi \) defined over algebraic groups to breaking Schnorr signatures, unless solving \(\Pi \) is easy. In an additional application of the new meta-reduction technique, we also unconditionally rule out any (even non-tight) generic reduction from natural non-interactive computational problems defined over algebraic groups to breaking Schnorr signatures in the non-programmable random oracle model.



                    
    


                    

                    

                    
                        
                            Motivation
The security of a cryptosystem is nowadays usually confirmed by giving a security proof. Typically, such a proof describes a reduction from some (assumed-to-be-)hard computational problem to breaking a defined security property of the cryptosystem. A reduction is considered as tight, if the reduction solving the hard computational problem has essentially the same running time and success probability as the attacker on the cryptosystem. Essentially, a tight reduction means that a successful attacker can be turned into an efficient algorithm for the hard computational problem without any significant increase in the running time and/or significant loss in the success probability.Footnote 1 The tightness of a reduction thus determines the strength of the security guarantees provided by the security proof: A non-tight reduction gives weaker security guarantees than a tight one. Moreover, tightness of the reduction affects the efficiency of the cryptosystem when instantiated in practice: A tighter reduction allows to securely use smaller parameters (shorter moduli, a smaller group size, etc.). Therefore, it is very desirable for a cryptosystem to have a tight security reduction.
In the domain of digital signatures, tight reductions are known for many fundamental schemes, such as Rabin/Williams signatures [5], many strong-RSA-based signatures [28], and RSA Full-Domain Hash [20]. For Schnorr signatures [29, 30], however, the story is a bit different. Schnorr’s scheme is one of the most fundamental public-key cryptosystems and Pointcheval and Stern have shown that it is provably secure, assuming the hardness of the discrete logarithm (DL) problem [25] in the random oracle model (ROM) [3]. However, the reduction in Pointcheval and Stern from the discrete logarithm problem to breaking Schnorr signatures is not tight: It loses a factor of q in the time-to-success ratio, where q is the number of random oracle queries performed by the forger.
This has lead to a long line of research investigating the existence of tighter security proofs for Schnorr signatures. At Asiacrypt 2005 Paillier and Vergnaud [24] gave a first lower bound showing that any algebraic reduction (even in the ROM) converting a forger for Schnorr signatures into an algorithm solving the discrete logarithm problem must lose a factor of at least \(q^{1/2}\). Their result is quite strong, as they rule out reductions even for adversaries that do not have access to a signing oracle and receive as input the message for which they must forge (UUF-NMA, see Sect. 3.1 for a formal definition). However, their result also has some limitations: It holds only under the interactive one-more discrete logarithm assumption, they only consider algebraic reductions, and they only rule out tight reductions from the (one-more) discrete logarithm problem. At Crypto 2008 Garg et al. [18] refined this result, by improving the bound from \(q^{1/2}\) to \(q^{2/3}\) with a new analysis and show that this bound is optimal if the meta-reduction follows a particular approach for simulating the forger. At Eurocrypt 2012, Seurin [31] finally closed the gap between the security proof of Pointcheval and Stern [25] and known impossibility results, by describing a novel elaborate simulation strategy for the forger and providing a new analysis. All previous works [18, 24, 31] on the existence of tight security proofs for Schnorr signatures have the following in common:
	
                    1.
                    
                      They only rule out the existence of tight reductions from specific strong computational problems, namely the (one-more) discrete logarithm problem [2]. Reduction from weaker problems such as, e.g., the computational or decisional Diffie–Hellman problem (CDH/DDH) are not considered.

                    
                  
	
                    2.
                    
                      The impossibility results are not unconditional but instead are themselves only valid under the very strong OMDL hardness assumption.

                    
                  
	
                    3.
                    
                      They hold only with respect to a limited (but natural) class of reductions, so-called algebraic reductions.

                    
                  

It is not entirely unlikely that first the nonexistence of a tight reduction from strong computational problems is proven, and later a tight reduction from some weaker problem is found. A concrete recent example in the domain of digital signatures where this has happened is RSA Full-Domain Hash (RSA-FDH) [4]. First, at Crypto 2000 Coron [8] described a non-tight reduction from solving the RSA-problem to breaking the security of RSA-FDH, and at Eurocrypt 2002 [9] showed that under certain conditions no tighter reduction from RSA can exist. Later, at Eurocrypt 2012, Kakvi and Kiltz [20] gave a tight reduction from solving a weaker problem, the so-called Phi-Hiding problem. The leverage, used by Kakvi and Kiltz to circumvent the aforementioned impossibility results, was to assume hardness of a weaker computational problem, i.e., making a stronger assumption. As all previous works rule out only tight reductions from strong computational problems such as DL and OMDL, this might happen again with Schnorr signatures and the following question was left open for 25 years:

                  
                    Does a tight security proof for Schnorr signatures exist based on any weaker computational problem?
                  

                



Contribution
In this work, we answer this question in the negative for an overwhelming class of weaker problems, ruling out the existence of tight reductions for virtually all natural non-interactive computational problems defined over abstract algebraic groups. Like previous works, we consider universal unforgeability under no-message attacks (UUF-NMA-security). Moreover, our results hold unconditionally. In contrast to previous works, we consider generic reductions instead of algebraic reductions, but we believe that this restriction is marginal: The motivation of considering only algebraic reductions from [24] applies equally to generic reductions. In particular, to the best of our knowledge all known examples of algebraic reductions are also generic.
Fig. 1[image: figure1]
Procedures implementing the generic group oracle


Full size image

Our main technical contribution is a new approach for the simulation of a forger in a meta-reduction, i.e., “a reduction against the reduction”, which differs from previous works [18, 24, 31] and which allows us to show the following main result:

                Theorem 1

                (Informal) For almost any natural non-interactive computational problem \(\Pi \), there is no tight generic reduction from solving \(\Pi \) to breaking the universal unforgeability under no-message attacks of Schnorr signatures.

              Technical approach We begin with the hypothesis that there exists a tight generic reduction \(\mathcal {R}\) from some hard non-interactive problem \(\Pi \) to the UUF-NMA-security of Schnorr signatures. Then we show that under this hypothesis there exists an efficient algorithm \(\mathcal {M}\), a meta-reduction, which efficiently solves \(\Pi \). This implies that the hypothesis is false. The meta-reduction \(\mathcal {M}= \mathcal {M}^\mathcal {R}\) runs \(\mathcal {R}\) as a subroutine, by efficiently simulating the forger \(\mathcal {A}\) for the reduction \(\mathcal {R}\).
All previous works in this direction [18, 24, 31] followed essentially the same approach. The difficulty with meta-reductions is that \(\mathcal {M}= \mathcal {M}^\mathcal {R}\) must efficiently simulate the forger \(\mathcal {A}\) for \(\mathcal {R}\). Previous works resolved this by using a discrete logarithm oracle provided by the OMDL assumption, which allows to efficiently compute valid signatures in the simulation of forger \(\mathcal {A}\). This is also the reason why all previous results are only valid under the OMDL assumption and were only able to rule out reductions from the discrete log or the OMDL problem. To overcome these limitations, a new simulation technique is necessary.
We revisit the simulation strategy of \(\mathcal {A}\) applied in known meta-reductions and put forward a new technique for proving impossibility results. It turns out that considering generic reductions provides additional leverage for simulating a successful forger efficiently, essentially by suitably re-programming the group representation while computing valid signatures. The technical challenge is to prove that the reduction remains oblivious to these changes to the group representation during the simulation, except for some negligible probability. We show how to prove this by adopting the “low polynomial degree” proof technique of Shoup [32], which was originally introduced to analyze the complexity of certain algorithms for the discrete logarithm problem, to the setting considered in this paper.
This new approach turns out to be extremely powerful, as it allows to rule out reductions from any non-interactive representation-invariant computational problem. Since almost all common hardness assumptions in algebraic groups (e.g., DL, CDH, DDH, DLIN, etc.) are based on representation-invariant computational problems, we are able to rule out tight generic reductions from virtually any natural computational problem, without making any additional assumptions. Even though we apply it specifically to Schnorr signatures, the overall approach is general. We expect that it is applicable to other cryptosystems as well.
Generic reductions vs. algebraic reductions Similar to algebraic reductions, a generic reduction performs only group operations. The main difference is that the sequence of group operations performed by an algebraic reduction may (but, to our best knowledge, in all known examples does not) depend on the particular representation of group elements. A generic reduction is required to work essentially identical for any representation of group elements. Generic reductions are by definition more restrictive than algebraic ones, we explain below why we do not consider this restriction as very significant.
An obvious question arising with our work is the relation between algebraic and generic reductions. Is a lower bound for generic reductions much less meaningful than a bound for algebraic reductions? We argue that the difference is not very significant. The restriction to algebraic reductions was motivated by the fact most reductions in known security proofs treat the group as a black-box, and thus are algebraic [18, 24, 31]. However, the same motivation applies to generic reductions as well, with exactly the same arguments. In particular, virtually all examples of algebraic reductions in the literature are also generic.
The vast majority of reductions in common security proofs for group-based cryptosystems treats the underlying group as a black-box (i.e., works for any representation of the group), and thus is generic. This is a very desirable feature, because then the cryptosystem can securely be instantiated with any group in which the underlying computational problem is hard. In contrast, representation-specific security proofs would require to re-prove security for any particular group representation the scheme is used with. Therefore, considering generic reductions seems very reasonable.
Generic reductions versus security proofs in the generic group model We stress that we model only the reduction \(\mathcal {R}\) as a generic algorithm. We do not restrict the forger \(\mathcal {A}\) in this way, as commonly done in security proofs in the generic group model. It may not be obvious that this is possible, because \(\mathcal {A}\) expects as input group elements in some specific encoding, while \(\mathcal {R}\) can only specify them in the form of random encodings. However, the reduction only gets access to the adversary as a black-box, which means that the adversary is external to the reduction, and the environment in which the reduction runs can easily translate between the encodings used by reduction and adversary. Further, note that while some reduction from a problem \(\Pi \) may be generic, the actual algorithm solving said problem is not \(\mathcal {R}\) itself, but the composition of \(\mathcal {R}\) and \(\mathcal {A}\) which may very well be non-generic. In particular, this means that any results about equivalence of interesting problems in the generic group model do not apply to the reduction. See Sect. 3.4 and Fig. 2 for further explanation.
Generic reductions in the non-programmable random oracle model An orthogonal question to the one answered in our main result is whether security proofs—even non-tight ones—for Schnorr signatures exist in weaker models. Paillier and Vergnaud analyzed the security of Schnorr Signatures in the standard model [24]. In particular, they presented an impossibility result for security proofs based on algebraic reductions and the discrete logarithm problem. In a similar vein, Fischlin and Fleischhacker [14] presented a result about the security of Schnorr signatures in the non-programmable random oracle model. Essentially they prove that in the non-programmable ROM [15] no reduction from the discrete logarithm problem can exist that potentially invokes the adversary several times but always on the same input. This class is limited, but encompasses all forking lemma style reductions used to prove Schnorr signatures secure in the programmable ROM.
Both these results suffer from the same shortcomings already discussed earlier. They only show impossibility for the discrete logarithm problem and they are themselves not unconditional, in that they rely on the hardness of the one-more discrete logarithm problem.
By applying our new simulation technique to reductions in the non-programmable random oracle model, we continue this line of research and show the following result

                Theorem 2

                (Informal) For almost any natural non-interactive computational problem \(\Pi \), there is no (even non-tight) generic reduction from solving \(\Pi \) to breaking the universal unforgeability under no-message attacks of Schnorr signatures in the non-programmable random oracle model.

              Comparison to [16] The conference version of this work [16] (published at Asiacrypt 2014) claimed that Theorem 1 holds even for interactive computational problems. This was incorrect, as pointed out by Kiltz et al. [21], who in fact were able to give a tight security proof based on the hardness of an—arguably somewhat artificial—interactive computational problem. The question of the existence of a tight security reduction based on a non-interactive computational problem (which is of course much more desirable) remains open. The present version of this paper corrects the flaw from the conference version, and thus shows the inexistence of such reductions. Moreover, we have extended this version with Theorem 2 that unconditionally rules out any (even non-tight) generic reduction in certain settings.
Further related work Dodis et al. [10] showed that it is impossible to reduce any computational problem to breaking the security of RSA-FDH in a model where the RSA-group \({\mathbb {Z}}_N^*\) is modeled as a generic group. This result extends [11]. Coron [9] considered the existence of tight security reductions for RSA-FDH signatures [4]. This result was generalized by Dodis and Reyzin [12] and later refined by Kiltz and Kakvi [20].
In the context of Schnorr signatures, Neven et al. [23] described necessary conditions the hash function must meet in order to provide existential unforgeability under chosen-message attacks (EUF-CMA) and showed that these conditions are sufficient if the forger (not the reduction!) is modeled as a generic group algorithm.
Several works studied the security of the Schnorr signature scheme in the multi-user setting, showing essentially that single-user security tightly implies multi-user security [6, 17, 21].


Preliminaries
Notation If S is a set, we write \(s {\leftarrow \!\!{\tiny {\$}}}\,S\) to denote the action of sampling a uniformly random element s from S. If A is a probabilistic algorithm, we denote with \(a {\leftarrow \!\!{\tiny {\$}}}\,A\) the action of computing a by running A. We denote with \(\emptyset \) the empty string, the empty set, as well as the empty list, the meaning will always be clear from the context. We write \(\left[ n\right] \) to denote the set of integers from 1 to n, i.e., \(\left[ n\right] := \{1,\ldots ,n\}\).
Schnorr Signatures
Let \({\mathbb {G}}\) be a group of order p with generator g, and let \(H : {\mathbb {G}}\times \{0,1\}^k\rightarrow {\mathbb {Z}}_p\) be a hash function. The Schnorr signature scheme [29, 30] consists of the following efficient algorithms \((\textsf {KGen},\textsf {Sig},\textsf {Vf})\). 
	\(\textsf {KGen}(g)\)::
	
                        The key generation algorithm takes as input a generator g of \({\mathbb {G}}\). It chooses \(\mathsf {sk}{\leftarrow \!\!{\tiny {\$}}}\,{\mathbb {Z}}_p\), computes \(\mathsf {pk}:= g^\mathsf {sk}\), and outputs \((\mathsf {pk},\mathsf {sk})\).

                      
	\(\textsf {Sig}(\mathsf {sk},m)\)::
	
                        The input of the signing algorithm is a private key \(\mathsf {sk}\) and a message \(m \in \{0,1\}^k\). It chooses a random integer \(r {\leftarrow \!\!{\tiny {\$}}}\,{\mathbb {Z}}_p\), sets \(R := g^r\) as well as \(c := \mathsf {H}(R,m)\), and computes \(y := \mathsf {sk}\cdot c + r \bmod p\). It outputs \(\sigma =(R,y)\).

                      
	\(\textsf {Vf}(\mathsf {pk},m,(R,y))\)::
	
                        The verification algorithm outputs the truth value of \(g^y {\mathop {=}\limits ^{\! \tiny ? }}\!\mathsf {pk}^c \cdot R\), where \(c = \mathsf {H}(R,m)\).

                      


                  Remark 3

                  The above variant of Schnorr signatures is obtained by a straightforward application of the Fiat–Shamir heuristic [13] to Schnorr’s ID scheme. There exists an equivalent, in practice often more efficient variant of Schnorr signatures, where a signature consists of \(\sigma =(c,y)\) (computed exactly as above), and the verification algorithm outputs the truth value of \(c {\mathop {=}\limits ^{\! \tiny ? }}\!\mathsf {H}(\mathsf {pk}^c/g^y,m)\). Both variants are equivalent, as one can efficiently (and tightly) convert a valid signature from one variant into a valid signature of the other. In particular, our tightness bounds cover both variants, but the former is slightly more convenient to use in our proofs.

                Universal Unforgeability under No-Message Attacks Consider the following security experiment involving a signature scheme \((\textsf {KGen},\textsf {Sig},\textsf {Vf})\), an attacker \(\mathcal {A}\), and a challenger \(\mathcal {C}\).
	
                      1.
                      
                        The challenger \(\mathcal {C}\) computes a key-pair \((\mathsf {pk},\mathsf {sk}) {\leftarrow \!\!{\tiny {\$}}}\,\textsf {KGen}(g)\) and chooses a message \(m {\leftarrow \!\!{\tiny {\$}}}\,\{0,1\}^k\) uniformly at random. It invokes \(\mathcal {A}\) on input \((\mathsf {pk},m)\).

                      
                    
	
                      2.
                      
                        Eventually, \(\mathcal {A}\) stops, outputting a signature \(\sigma \).

                      
                    


                  Definition 4

                  We say that \(\mathcal {A}\)\((\epsilon ,t)\)-breaks the UUF-NMA-security of \((\textsf {KGen},\textsf {Sig},\textsf {Vf})\), if \(\mathcal {A}\) runs in time at most t and
[image: ]

where randomness is taken over the random choice of \(\mathsf {pk}\), m, and \(\mathcal {A}\)’s random coins.

                Note that UUF-NMA-security is a very weak security goal for digital signatures. Since we are going to prove a negative result, this is not a limitation, but instead, makes our result even stronger. In fact, if we rule out reductions from some problem \(\Pi \) to forging signatures in the sense of UUF-NMA, then the impossibility clearly holds for stronger security notions, such as existential unforgeability under adaptive chosen-message attacks [19], too.
Computational Problems
Let \({\mathbb {G}}\) be a cyclic group of order p and \(g \in {\mathbb {G}}\) a generator of \({\mathbb {G}}\). We write \(\mathsf {desc}({\mathbb {G}},g)\) to denote the list of group elements \( \mathsf {desc}({\mathbb {G}},g) = (g,g^2,\ldots ,g^p) \in {\mathbb {G}}^p. \) We say that \(\mathsf {desc}({\mathbb {G}},g)\) is the enumerating description of \({\mathbb {G}}\) with respect to g.

                  Definition 5

                  A non-interactive computational problem\(\Pi \) in \({\mathbb {G}}\) is specified by two (computationally unbounded) procedures \(\Pi = ({\mathcal {G}}_\Pi ,{\mathcal {V}}_\Pi )\), with the following syntax. 
	
                          \({{\mathcal {G}}_\Pi (\mathsf {desc}({\mathbb {G}},g))}\)
                        :
	
                          takes as input an enumerating description of \({\mathbb {G}}\), and outputs a state st and a problem instance (the challenge) \(C = (C_1,\ldots ,C_u,C') \in {\mathbb {G}}^u\times \{0,1\}^*\). We assume in the sequel that at least \(C_1\) is a generator of \({\mathbb {G}}\).

                        
	
                          \({\mathcal {V}}_\Pi (\mathsf {desc}({\mathbb {G}},g),st,S,C)\)
                        :
	
                          takes as input \((\mathsf {desc}({\mathbb {G}},g),st,C)\) as defined above, and \(S = (S_1,\ldots ,S_w,S') \in {\mathbb {G}}^w\times \{0,1\}^*\). It outputs 0 or 1.

                        

 The exact description and distribution of st, C, S and the concrete values of u and w depend on the considered computational problem.
                
                  Definition 6

                  An algorithm \(\mathcal {A}\)\((\epsilon ,t)\)-solves the non-interactive computational problem \(\Pi \) if \(\mathcal {A}\) has running time at most t and wins the following interactive game against a (computationally unbounded) challenger \(\mathcal {C}\)with probability at least \(\epsilon \), where the game is defined as follows:
	
                        1.
                        
                          The challenger \(\mathcal {C}\) generates an instance of the problem \((st,C) {\leftarrow \!\!{\tiny {\$}}}\,{\mathcal {G}}_\Pi (\mathsf {desc}({\mathbb {G}},g))\) and invokes \(\mathcal {A}\) on input C.

                        
                      
	
                        2.
                        
                          Eventually, algorithm \(\mathcal {A}\) outputs a candidate solution S. The algorithm \(\mathcal {A}\) wins the game (i.e., solves the computational problem correctly) if and only if \({\mathcal {V}}_\Pi (\mathsf {desc}({\mathbb {G}},g),st,C,S) = 1\).

                        
                      


                
                  Example 7

                  The discrete logarithm problem in \({\mathbb {G}}\) is specified by the following procedures. \({\mathcal {G}}_\Pi (\mathsf {desc}({\mathbb {G}},g))\) outputs (st, C) with \(st = \emptyset \) and \(C = (g,h)\), where \(h {\leftarrow \!\!{\tiny {\$}}}\,{\mathbb {G}}\) is a random group element. \({\mathcal {V}}_\Pi (\mathsf {desc}({\mathbb {G}},g),st,C,S)\) interprets \(S = S' \in \{0,1\}^*\) canonically as an integer in \({\mathbb {Z}}_p\), and outputs 1 iff \(h = g^{S'}\).

                
                  Example 8

                  The UUF-NMA-forgery problem for Schnorr signatures in \({\mathbb {G}}\) with hash function \(\mathsf {H}\) is specified by the following procedures. \({\mathcal {G}}_\Pi (\mathsf {desc}({\mathbb {G}},g))\) outputs (st, C) with \(st=m\) and \(C = (g,\mathsf {pk},m) \in {\mathbb {G}}^2\times \{0,1\}^k\), where \(\mathsf {pk}= g^\mathsf {sk}\) for \(\mathsf {sk}{\leftarrow \!\!{\tiny {\$}}}\,{\mathbb {Z}}_p\) and \(m {\leftarrow \!\!{\tiny {\$}}}\,\{0,1\}^k\). The verification algorithm \({\mathcal {V}}_\Pi (\mathsf {desc}({\mathbb {G}},g),st,C,S)\) parses S as \(S = (R,y) \in {\mathbb {G}}\times {\mathbb {Z}}_p\), sets \(c := \mathsf {H}(R,st)\), and outputs 1 if and only if \(\mathsf {pk}^c\cdot R = g^y\).

                Representation-Invariant Computational Problems
In our impossibility results given below, we want to rule out the existence of a tight reduction from as large a class of computational problems as possible. Ideally, we want to rule out the existence of a tight reduction from any computational problem that meets Definition 5. However, it is easy to see that this is not achievable in this generality: as Example 8 shows, the problem of forging Schnorr signatures itself is a problem that meets Definition 5. But necessarily there exists a trivial tight reduction from the problem of forging Schnorr signatures to the problem of forging Schnorr signatures! Therefore, we need to restrict the class of considered computational problems to exclude such trivial, artificial problems.
We introduce the notion of representation-invariant computational problems. This class of problems captures virtually any reasonable computational problem defined over an abstract algebraic group except for a few extremely artificial problems. In particular, the problem of forging Schnorr signatures is not contained in this class (see Example 11 below).
Intuitively, a computational problem is representation-invariant, if a valid solution to a given problem instance remains valid even if the representation of group elements in challenges and solutions is converted to a different representation of the same group. More formally we define it as follows:

                  Definition 9

                  We say that \(\Pi \) is representation-invariant, if and only if for all isomorphic groups \({\mathbb {G}},{{\hat{{\mathbb {G}}}}}\) and for all generators \(g \in {\mathbb {G}}\), all \(C = (C_1,\dots ,C_u,C') {\leftarrow \!\!{\tiny {\$}}}\,{\mathcal {G}}_\Pi (\mathsf {desc}({\mathbb {G}},g))\), all \(st=(st_1,\ldots ,st_t,st') \in {\mathbb {G}}^t \times \{0,1\}^*\), and all \(S=(S_1,\ldots ,S_w,S') \in {\mathbb {G}}^w \times \{0,1\}^*\) holds that \( {\mathcal {V}}_\Pi (\mathsf {desc}({\mathbb {G}},g),st,C,S) = 1 \iff {\mathcal {V}}_\Pi (\mathsf {desc}({{\hat{{\mathbb {G}}}}},{\hat{g}}),\hat{st},{\hat{C}},{\hat{S}}) = 1, \) where \({\hat{g}} = \phi (g) \in {\mathbb {G}}'\), \({\hat{C}} = (\phi (C_1),\dots ,\phi (C_u),C')\), \(\hat{st}=(\phi (st_1),\ldots ,\phi (st_t),st')\), and \({\hat{S}}=(\phi (S_1),\ldots ,\phi (S_w),S')\).

                Observe that this definition only demands the existence of an isomorphism \(\phi : {\mathbb {G}}\rightarrow {{\hat{{\mathbb {G}}}}}\) and not that it is efficiently computable.

                  Example 10

                  The discrete logarithm problem is representation-invariant. Let \(C = (g,h) \in {\mathbb {G}}^2\) be a discrete log challenge, with corresponding solution \(S' \in \{0,1\}^*\) such that \(S'\) canonically interpreted as an integer \(S' \in {\mathbb {Z}}_p\) satisfies \(g^{S'} = h \in {\mathbb {G}}\). Let \(\phi : {\mathbb {G}}\rightarrow {{\hat{{\mathbb {G}}}}}\) be an isomorphism, and let \(({\hat{g}},{\hat{h}}) := (\phi (g),\phi (h))\). Then it clearly holds that \({\hat{g}}^{{\hat{S}}'} = {\hat{h}}\), where \(\hat{S'} = S'\).

                Virtually all common hardness assumptions in algebraic groups are based on representation-invariant computational problems. Popular examples are, for instance, the discrete log problem (DL), computational Diffie–Hellman (CDH), decisional Diffie–Hellman (DDH), decision linear (DLIN), and so on.

                  Example 11

                  The UUF-NMA-forgery problem for Schnorr signatures with hash function H is not representation-invariant for any hash function H. Let \(C = (g,\mathsf {pk},m) {\leftarrow \!\!{\tiny {\$}}}\, {\mathcal {G}}_\Pi (\mathsf {desc}({\mathbb {G}},g))\) be a challenge with solution \(S = (R,y) \in {\mathbb {G}}\times {\mathbb {Z}}_p\) satisfying \(\mathsf {pk}^c\cdot R = g^y\), where \(c := \mathsf {H}(R,m)\).

                  Let \({{\hat{{\mathbb {G}}}}}\) be a group isomorphic to \({\mat";"""dc.publisher"",""Springer""
""og:image"",""https://media.springernature.com/w200/springer-static/cover/journal/145.jpg""
""twitter:card"",""summary""
""og:site_name"",""Journal of Cryptology""
""citation_reference"",""M. Abdalla, M. Bellare, P. Rogaway, The oracle Diffie–Hellman assumptions and an analysis of DHIES, in David Naccache, editor, Topics in Cryptology—CT-RSA 2001, Volume 2020 of Lecture Notes in Computer Science, San Francisco, CA, USA (Springer, Heidelberg, 2001), pp. 143–158"",""citation_journal_title=Journal of Cryptology; citation_title=The one-more-RSA-inversion problems and the security of Chaum’s blind signature scheme; citation_author=Mihir Bellare, Chanathip Namprempre, David Pointcheval, Michael Semanko; citation_volume=16; citation_issue=3; citation_publication_date=2003; citation_pages=185-215; citation_doi=10.1007/s00145-002-0120-1; citation_id=CR2"",""M. Bellare, P. Rogaway. Random oracles are practical: a paradigm for designing efficient protocols, in V. Ashby, editor, ACM CCS 93: 1st Conference on Computer and Communications Security, Fairfax, Virginia, USA (ACM Press, London, 1993), pp 62–73"",""M. Bellare, P. Rogaway. The exact security of digital signatures: how to sign with RSA and Rabin, in Ueli M. Maurer, editor, Advances in Cryptology—EUROCRYPT’96, Volume 1070 of Lecture Notes in Computer Science, Saragossa, Spain (Springer, Heidelberg, 1996), pp. 399–416"",""D.J. Bernstein. Proving tight security for Rabin–Williams signatures, in Nigel P. Smart, editor, Advances in Cryptology—EUROCRYPT 2008, Volume 4965 of Lecture Notes in Computer Science, Istanbul, Turkey (Springer, Heidelberg, 2008), pp. 70–87"",""D.J. Bernstein. Multi-user schnorr security, revisited. Cryptology ePrint Archive, Report 2015/996.                      https://eprint.iacr.org/2015/996                                         (2015)"",""D. Boneh, X. Boyen, Secure identity based encryption without random oracles, in Matthew Franklin, editor, Advances in Cryptology—CRYPTO 2004, Volume 3152 of Lecture Notes in Computer Science, Santa Barbara, CA, USA (Springer, Heidelberg, 2004), pp. 443–459"",""J.-S. Coron, On the exact security of full domain hash, in Mihir Bellare, editor, Advances in Cryptology—CRYPTO 2000, Volume 1880 of Lecture Notes in Computer Science, Santa Barbara, CA, USA (Springer, Heidelberg, 2000), pp. 229–235"",""J.-S. Coron, Optimal security proofs for PSS and other signature schemes, in Lars R. Knudsen, editor, Advances in Cryptology—EUROCRYPT 2002, Volume 2332 of Lecture Notes in Computer Science, Amsterdam, The Netherlands (Springer, Heidelberg, 2002), pp.272–287"",""Y. Dodis, I. Haitner, A. Tentes, On the instantiability of hash-and-sign RSA signatures, in Ronald Cramer, editor, TCC 2012: 9th Theory of Cryptography Conference, Volume 7194 of Lecture Notes in Computer Science, Taormina, Sicily, Italy (Springer, Heidelberg, 2012), pp. 112–132"",""Y. Dodis, R. Oliveira, K. Pietrzak, On the generic insecurity of the full domain hash, in Victor Shoup, editor, Advances in Cryptology—CRYPTO 2005, Volume 3621 of Lecture Notes in Computer Science, Santa Barbara, CA, USA (Springer, Heidelberg, 2005), pp. 449–466"",""Y. Dodis, L. Reyzin, On the power of claw-free permutations, in Stelvio Cimato, Clemente Galdi, and Giuseppe Persiano, editors, SCN 02: 3rd International Conference on Security in Communication Networks, Volume 2576 of Lecture Notes in Computer Science, Amalfi, Italy (Springer, Heidelberg, 2003), pp. 55–73"",""A. Fiat, A. Shamir, How to prove yourself: practical solutions to identification and signature problems, in Andrew M. Odlyzko, editor, Advances in Cryptology–CRYPTO’86, Volume 263 of Lecture Notes in Computer Science, Santa Barbara, CA, USA (Springer, Heidelberg, 1987), pp. 186–194"",""M. Fischlin, N. Fleischhacker, Limitations of the meta-reduction technique: the case of Schnorr signatures, in Thomas Johansson and Phong Q. Nguyen, editors, Advances in Cryptology—EUROCRYPT 2013, Volume 7881 of Lecture Notes in Computer Science, Athens, Greece (Springer, Heidelberg, 2013), pp. 444–460"",""M. Fischlin, A. Lehmann, T. Ristenpart, T. Shrimpton, M. Stam, S. Tessaro, Random oracles with(out) programmability, in Masayuki Abe, editor, Advances in Cryptology—ASIACRYPT 2010, Volume 6477 of Lecture Notes in Computer Science, Singapore (Springer, Heidelberg, 2010), pp. 303–320"",""N. Fleischhacker, T. Jager, D. Schröder, On tight security proofs for Schnorr signatures, in Palash Sarkar and Tetsu Iwata, editors, Advances in Cryptology—ASIACRYPT 2014, Part I, Volume 8873 of Lecture Notes in Computer Science, Kaoshiung, Taiwan, R.O.C (Springer, Heidelberg, 2014), pp. 512–531"",""citation_journal_title=Inf. Process. Lett.; citation_title=Public key signatures in the multi-user setting; citation_author=Steven D Galbraith, John Malone-Lee, Nigel P Smart; citation_volume=83; citation_issue=5; citation_publication_date=2002; citation_pages=263-266; citation_doi=10.1016/S0020-0190(01)00338-6; citation_id=CR17"",""S. Garg, R. Bhaskar, S.V. Lokam, Improved bounds on security reductions for discrete log based signatures, in David Wagner, editor, Advances in Cryptology—CRYPTO 2008, Volume 5157 of Lecture Notes in Computer Science, Santa Barbara, CA, USA (Springer, Heidelberg, 2008), pp. 93–107"",""citation_journal_title=SIAM Journal on Computing; citation_title=A digital signature scheme secure against adaptive chosen-message attacks; citation_author=Shafi Goldwasser, Silvio Micali, Ronald L Rivest; citation_volume=17; citation_issue=2; citation_publication_date=1988; citation_pages=281-308; citation_doi=10.1137/0217017; citation_id=CR19"",""S. A. Kakvi, E. Kiltz, Optimal security proofs for full domain hash, revisited, in David Pointcheval and Thomas Johansson, editors, Advances in Cryptology—EUROCRYPT 2012, Volume 7237 of Lecture Notes in Computer Science, Cambridge, UK (Springer, Heidelberg, 2012), pp. 537–553"",""E. Kiltz, D. Masny, J. Pan, Optimal security proofs for signatures from identification schemes, in Matthew Robshaw and Jonathan Katz, editors, Advances in Cryptology—CRYPTO 2016, Part II, Volume 9815 of Lecture Notes in Computer Science, Santa Barbara, CA, USA (Springer, Heidelberg, 2016), pp. 33–61"",""U.M. Maurer, Abstract models of computation in cryptography (invited paper), in Nigel P. Smart, editor, 10th IMA International Conference on Cryptography and Coding, Volume 3796 of Lecture Notes in Computer Science, Cirencester, UK (Springer, Heidelberg, 2005), pp. 1–12"",""citation_journal_title=Journal of Mathematical Cryptology; citation_title=Hash function requirements for Schnorr signatures; citation_author=Gregory Neven, Nigel Smart, Bogdan Warinschi; citation_volume=3; citation_issue=1; citation_publication_date=2009; citation_pages=69-87; citation_doi=10.1515/JMC.2009.004; citation_id=CR23"",""P. Paillier, D. Vergnaud, Discrete-log-based signatures may not be equivalent to discrete log, in Bimal K. Roy, editor, Advances in Cryptology—ASIACRYPT 2005, Volume 3788 of Lecture Notes in Computer Science, Chennai, India (Springer, Heidelberg, 2005), pp. 1–20."",""D. Pointcheval, J. Stern, Security proofs for signature schemes, in Ueli M. Maurer, editor, Advances in Cryptology—EUROCRYPT’96, Volume 1070 of Lecture Notes in Computer Science, Saragossa, Spain (Springer, Heidelberg, 1996), pp. 387–398"",""O. Reingold, L. Trevisan, S. P. Vadhan, Notions of reducibility between cryptographic primitives, in Moni Naor, editor, TCC 2004: 1st Theory of Cryptography Conference, Volume 2951 of Lecture Notes in Computer Science, Cambridge, MA, USA (Springer, Heidelberg, 2004), pp. 1–20"",""A. Rupp, G. Leander, E. Bangerter, A.W. Dent, A.-R. Sadeghi, Sufficient conditions for intractability over black-box groups: generic lower bounds for generalized DL and DH problems, in Josef Pieprzyk, editor, Advances in Cryptology—ASIACRYPT 2008, Volume 5350 of Lecture Notes in Computer Science, Melbourne, Australia (Springer, Heidelberg, 2008), pp. 489–505"",""S. Schäge, Tight proofs for signature schemes without random oracles, in Kenneth G. Paterson, editor, Advances in Cryptology—EUROCRYPT 2011, Volume 6632 of Lecture Notes in Computer Science, Tallinn, Estonia (Springer, Heidelberg, 2011), pp. 189–206"",""C.-P. Schnorr, Efficient identification and signatures for smart cards, in Gilles Brassard, editor, Advances in Cryptology—CRYPTO’89, Volume 435 of Lecture Notes in Computer Science, Santa Barbara, CA, USA (Springer, Heidelberg, 1990), pp. 239–252"",""citation_journal_title=Journal of Cryptology; citation_title=Efficient signature generation by smart cards; citation_author=Claus-Peter Schnorr; citation_volume=4; citation_issue=3; citation_publication_date=1991; citation_pages=161-174; citation_doi=10.1007/BF00196725; citation_id=CR30"",""Y. Seurin, On the exact security of Schnorr-type signatures in the random oracle model, in David Pointcheval and Thomas Johansson, editors, Advances in Cryptology—EUROCRYPT 2012, Volume 7237 of Lecture Notes in Computer Science, Cambridge, UK (Springer, Heidelberg, 2012), pp. 554–571"",""V. Shoup, Lower bounds for discrete logarithms and related problems, in Walter Fumy, editor, Advances in Cryptology—EUROCRYPT’97, Volume 1233 of Lecture Notes in Computer Science, Konstanz, Germany (Springer, Heidelberg, 1997), pp. 256–266"",""B.R. Waters, Efficient identity-based encryption without random oracles, in Ronald Cramer, editor, Advances in Cryptology—EUROCRYPT 2005, Volume 3494 of Lecture Notes in Computer Science, Aarhus, Denmark (Springer, Heidelberg, 2005), pp. 114–127""
""citation_journal_title"",""Journal of Cryptology""
""language"",""en""
""citation_cover_date"",""2019/04/01""
""og:description"",""The Schnorr signature scheme is the most efficient signature scheme based on the discrete logarithm problem and a long line of research investigates the existence of a tight security reduction for this scheme in the random oracle model. Almost all recent works present lower tightness bounds and most recently Seurin EUROCRYPT 2012 showed that under certain assumptions the non-tight security proof for Schnorr signatures in the random oracle by Pointcheval and Stern EUROCRYPT’96 is essentially optimal. All previous works in this direction rule out tight reductions from the (one-more) discrete logarithm problem. In this paper, we introduce a new meta-reduction technique, which shows lower bounds for the large and very natural class of generic reductions. A generic reduction is independent of a particular representation of group elements. Most reductions in state-of-the-art security proofs have this property. It is desirable, because then the reduction applies generically to any concrete instantiation of the group. Our approach shows unconditionally that there is no tight generic reduction from any natural non-interactive computational problem $$\Pi $$ Π defined over algebraic groups to breaking Schnorr signatures, unless solving $$\Pi $$ Π is easy. In an additional application of the new meta-reduction technique, we also unconditionally rule out any (even non-tight) generic reduction from natural non-interactive computational problems defined over algebraic groups to breaking Schnorr signatures in the non-programmable random oracle model.""
""prism.issn"",""1432-1378""
""citation_author_email"",""mail@nilsfleischhacker.de""
""twitter:image:alt"",""Content cover image""
""prism.number"",""2""
""citation_issn"",""1432-1378""
""citation_language"",""en""
""dc:title"",""On Tight Security Proofs for Schnorr Signatures | SpringerLink""
""Content-Encoding"",""UTF-8""
""citation_pdf_url"",""https://link.springer.com/content/pdf/10.1007/s00145-019-09311-5.pdf""
""citation_lastpage"",""599""
""DOI"",""10.1007/s00145-019-09311-5""
""citation_fulltext_world_readable"",""""
""citation_journal_abbrev"",""J Cryptol""
""prism.rightsAgent"",""journalpermissions@springernature.com""
""citation_author"",""Nils Fleischhacker"",""Tibor Jager"",""Dominique SchrĂśder""
""resourceName"",""s00145-019-09311-5""
""dc.date"",""2019-02-06""
""citation_springer_api_url"",""http://api.springer.com/metadata/pam?q=doi:10.1007/s00145-019-09311-5&api_key=""
""citation_issue"",""2""
""prism.volume"",""32""
""prism.publicationName"",""Journal of Cryptology""
""citation_doi"",""10.1007/s00145-019-09311-5""
""dc.title"",""On Tight Security Proofs for Schnorr Signatures""
""prism.url"",""https://link.springer.com/article/10.1007/s00145-019-09311-5""
""citation_volume"",""32""
""dc.language"",""En""
""Content-Language"",""en""
""format-detection"",""telephone=no""
""citation_publication_date"",""2019/04""
""prism.endingPage"",""599""
""citation_title"",""On Tight Security Proofs for Schnorr Signatures""
""citation_author_institution"",""Ruhr University Bochum, Bochum, Germany"",""Paderborn University, Paderborn, Germany"",""Friedrich-Alexander-University Erlangen-NĂźrnberg, NĂźrnberg, Germany""
""access"",""Yes""
""citation_publisher"",""Springer US""
""applicable-device"",""pc,mobile""
""dc.format"",""text/html""
""description"",""The Schnorr signature scheme is the most efficient signature scheme based on the discrete logarithm problem and a long line of research investigates the ex""
""title"",""On Tight Security Proofs for Schnorr Signatures | SpringerLink""
""citation_online_date"",""2019/02/06""
""twitter:site"",""@SpringerLink""
""dc.source"",""Journal of Cryptology 2019 32:2""
""dc.type"",""OriginalPaper""
""dc.copyright"",""2019 International Association for Cryptologic Research""
""dc.creator"",""Nils Fleischhacker"",""Tibor Jager"",""Dominique SchrĂśder""
""citation_fulltext_html_url"",""https://link.springer.com/article/10.1007/s00145-019-09311-5""
""prism.publicationDate"",""2019-02-06""
""Content-Type"",""text/html; charset=UTF-8""
""journal_id"",""145""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""dc.description"",""The Schnorr signature scheme is the most efficient signature scheme based on the discrete logarithm problem and a long line of research investigates the existence of a tight security reduction for this scheme in the random oracle model. Almost all recent works present lower tightness bounds and most recently Seurin EUROCRYPT 2012 showed that under certain assumptions the non-tight security proof for Schnorr signatures in the random oracle by Pointcheval and Stern EUROCRYPT’96 is essentially optimal. All previous works in this direction rule out tight reductions from the (one-more) discrete logarithm problem. In this paper, we introduce a new meta-reduction technique, which shows lower bounds for the large and very natural class of generic reductions. A generic reduction is independent of a particular representation of group elements. Most reductions in state-of-the-art security proofs have this property. It is desirable, because then the reduction applies generically to any concrete instantiation of the group. Our approach shows unconditionally that there is no tight generic reduction from any natural non-interactive computational problem                                                                               $$\Pi $$                                                                             defined over algebraic groups to breaking Schnorr signatures, unless solving                                                                               $$\Pi $$                                                                             is easy. In an additional application of the new meta-reduction technique, we also unconditionally rule out any (even non-tight) generic reduction from natural non-interactive computational problems defined over algebraic groups to breaking Schnorr signatures in the non-programmable random oracle model.""
""og:type"",""article""
""citation_article_type"",""Article""
""og:title"",""On Tight Security Proofs for Schnorr Signatures""
""prism.doi"",""doi:10.1007/s00145-019-09311-5""
""X-UA-Compatible"",""IE=edge""
""citation_firstpage"",""566""
""prism.startingPage"",""566""
""viewport"",""width=device-width, initial-scale=1""
""dc.rightsAgent"",""journalpermissions@springernature.com""
""prism.section"",""OriginalPaper""
""dc.identifier"",""doi:10.1007/s00145-019-09311-5""
""dc.subject"",""Coding and Information Theory"",""Computational Mathematics and Numerical Analysis"",""Combinatorics"",""Probability Theory and Stochastic Processes"",""Communications Engineering, Networks""
""og:url"",""https://link.springer.com/article/10.1007/s00145-019-09311-5""
""prism.copyright"",""2019 International Association for Cryptologic Research""
";https://scholar.google.com/scholar?start=750&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094586-841;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[PDF][PDF] Short Paper v1. 0.7 Clément Lesaege, Federico Ast, and William George September 2019;C Lesaege, F Ast ;2019 kleros.io;;"… SchellingCoin mechanisms have been used for decentralized oracles and prediction markets

(26) (23) (3). The fundamental insight is that voting … subcourts with a particularly low session time

(for example a subcourt solving disputes in a web to blockchain Oracle) this random …";Autres articles;;[PDF] kleros.io;https://kleros.io/whitepaper.pdf;;;https://scholar.google.com/scholar?start=660&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094633-1041;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[PDF][PDF] Threshold Cryptosystems in Asynchronous Networks;A Seši?, V Malbaša ; rcvt.tusofia.bg;;"… to prove yourself: practical solutions to identification and signature problems“, Advances in

Cryptology-Crypto '86, Springer … 12] M. Bellare and P. Rogaway, “Random oracles are practical …

S. Halevi, and T. Rabin, “Secure hash-and-sign signatures without the random oracle,” Proc …";Autres articles;Version HTML;[PDF] tu-sofia.bg;http://rcvt.tu-sofia.bg/ICEST2005_6.pdf;"
 

19 

Threshold Cryptosystems in Asynchronous Networks  
Aleksandra Sešić1, Veljko Malbaša2

 
Abstract−Threshold cryptography makes it possible to design 

cryptographic systems in which some operations require the 
collaboration of several users. As a result, security of the system 
is increased. This paper aims at guiding  readers into this 
interesting field under the asynchronous message-passing model 
of distributed computing.  

Keywords−Threshold cryptosystem, verifiable secret sharing, 
proactive  security, asynchronous system model. 

I. INTRODUCTION 

Distributed cryptography, introduced in 1987, is a variant  
of traditional cryptography intended for distributed services. 
Several  distributed cryptosystems  have been proposed until 
now.  Most of them  have a threshold structure, which means 
that  both the sets of corrupted servers that must be tolerated 
by the system and the sets that are qualified to perform some 
action are determined by their cardinality. Due to this fact, 
distributed cryptography is called also in general threshold 
cryptography. The surveys of threshold cryptography can be 
found in [1,2]. 

Threshold cryptosystem is a public key cryptosystem in 
which the secret key is shared among the set of users. Only 
some qualified subsets of users will be able to perform the 
operation  related to the secret key (decrypting or signing). In 
this way, security of the system is increased, because  the loss 
or theft of several shares of the secret key does not necessarily 
break the system’s security. 
 We are especially interested in protocols that require no 
interaction or synchronization among the servers, and as such 
can be efficiently run on an asynchronous communications 
network where messages are delivered with arbitrary delay 
and in which the speeds of the nodes can get out of 
synchronism to an arbitrary extent. It is the weakest model 
(i.e., methods for this model work in other models, too) and 
the most realistic for distributed computing in today’s large 
scale wide-area networks such  as the Internet. 

II. THRESHOLD CRYPTOSYSTEMS 

A threshold public-key cryptosystem [3] looks similar to an 
ordinary public-key cryptosystem with distributed decryption.  
Given a ciphertext resulting from encrypting  some message 
and more than t+1 valid decryption shares for that ciphertext, 
in a system which tolerates up to t faults, it is easy for a client 
to recover the message; this property is called robustness.  

1 Aleksandra Sešić is with Nopal, 21400 Bačka Palanka, Serbia and 
Montenegro, Email: asesic@nopal.co.yu 
2 Veljko MalbaĹĄa is with the School of Engineering, University of  
Novi Sad, 21000 Novi Sad, Serbia and Montenegro, Email: 
malbasa@uns.ns.ac.yu 

This means that corrupted players should not be able to 
prevent uncorrupted servers from decrypting ciphertexts, i.e., 
that the decryption service is available even if the adversary 
can send bad decryption shares. The key to robustness is 
validity checking, based on a public key system, where one 
can ignore all incorrect decryption shares without exhaustive 
searching to find out who sent the wrong decryption share. 
Notice that the message can be recovered without revealing  
the secret decryption key.  

The scheme must also be secure against chosen ciphertext 
attacks [4] in order to be useful for all conceivable  
applications. This type of attack is one in which a cryptanalyst 
attempts to determine the key from knowledge of plaintext 
that corresponds to ciphertext selected (i.e., chosen) by the 
analyst. This type of attack is generally most applicable to 
public-key cryptosystems, for once the (private) key is known, 
all subsequent messages from the same source can be 
deciphered. For the threshold case, security means that the 
adversary cannot obtain any meaningful information from a 
ciphertext unless she  has obtained a corresponding decryption 
share from at least one honest party. 

In a threshold signature scheme, each server  holds a share 
of the secret signing key and may generate shares of 
signatures on individual messages upon request. A signing 
algorithm takes as inputs a message, the public key and the 
secret key share. It outputs a signature share on the submitted 
message. The validity of a signature share can be verified for 
each server by a share verification algorithm. It takes as 
inputs a message, a signature share on that message  from a 
server Si along with the public key and local verification key 
of Si. A share combining algorithm takes as  input  a message 
and  t+1 valid  signature shares on that message, along with  
public keys and the verification keys and outputs a valid  
digital signature on that message without  knowing the actual 
secret signing key. This key speaks for the service  but is 
never materialized at individual servers comprising the 
service. The signature  can later be verified using the single, 
publicly known signature verification key. Notice that in 
particular, the threshold approach rules out the naĂŻve solution 
based on traditional secret sharing, where the secret key is 
shared in a group but reconstructed by a single player each 
time  when a signature is to be produced. Such a protocol 
would contradict the requirement that no t (or less) players 
can ever produce a new valid signature. 

The two basic security requirements are non-forgeability 
and  robustness. 

Non-forgeability property means that t or less corrupted 
servers will not be able to forge signatures, i.e., to provide a 
valid signature on a message for which no honest party 
generated a signature share. 

Robust threshold signature scheme can withstand the 
participation of dishonest signers during the signature 
computation operation. This is a mechanism that succeeds in 
constructing a valid signature even if the partial signatures 



 20

contributed by some of the signers are incorrect. Due to 
robustness, corrupted servers will not be able to prevent the 
uncorrupted servers from computing correct signatures, i.e., it 
is infeasible for a computational bounded adversary to 
produce  t+1 valid signature shares that cannot be combined 
to a valid signature. 

Threshold-cryptographic protocols ensure security  as long 
as  at most t of servers are broken into. They enhance the 
security against  break-in attacks in many scenarios. However, 
threshold cryptography is also limited. Given sufficient 
amount of time, an attacker can break into servers one by one, 
thus eventually compromise the security of the system. This 
danger is particularly eminent in systems that must remain 
secure for long periods of time (such as certification 
authorities) or where secure recovery may be difficult (such as 
with secure communication). 

Proactive security is a mechanism for protecting against 
such long-term attacks. Proactive cryptosystems operate in 
phases. They can tolerate the corruption of up to t different 
servers in every phase [5]. That is, first distribute the 
cryptographic capabilities among several servers. Next, have 
the servers periodically engage in a refreshment protocol that 
proactively reboots all servers at the beginning of every phase 
and subsequently refreshes the secret key shares. Knowledge 
of the shares from the previous phases becomes useless to 
attack the system in the future. This protocol will allow the 
servers to automatically recover from possible, undetected 
break-ins, and in particular will provide the servers with new 
shares of the sensitive data while keeping the sensitive data 
unmodified.  

Share refreshing is a distributed protocol and in all 
proactive cryptosystems it relies on verifiable secret sharing. 
Verifiable secret sharing is a fundamental primitive in 
distributed cryptography [6] that has found its application in 
threshold cryptosystems. A verifiable secret sharing protocol 
allows each shareholder  to verify that the share is consistent 
with other shares in case the dealer of shares  might be faulty. 

III. CRYPTOGRAPHY VERSUS DISTRIBUTED 
COMPUTING 

The field of multi-party cryptographic protocols is where 
cryptography and distributing computing meet [7]. However, 
this field  is considered as a part of cryptography, which is the 
consequence of the dominant role of cryptographic notions 
and techniques in the current research of cryptographic 
protocols. Most of the cryptographic research is concerned 
with two-party computations where typically an asynchronous 
message passing model is assumed (almost always implicitly). 
For multi-party cryptographic protocols  a  synchronous 
model consisting of either point-to-point channels or a single 
broadcast channel is used most frequently. Results for 
asynchronous communication and arbitrary networks of point-
to-point channels were presented in [8,9,10].   

IV. RELATED WORK 

A major complication for adopting threshold cryptography 
to asynchronous distributed systems is that many early 

protocols are not robust and that rely heavily on synchronous 
broadcast channels.  

Shoup and Gennaro [4] present the first robust threshold  
cryptosystem that is also  non-interactive, and as such 
integrates well into asynchronous communication model.  
Moreover, it  is  the first practical threshold cryptosystem that 
is provably secure against chosen ciphertext attack in the 
random oracle model. In the random oracle model  
cryptographic hash functions are replaced by a random oracle. 
This model was used informally by Fiat and Shamir [11] and 
later was rigorously formalized and more fully exploited in 
Bellare and Rogaway [12]. In the random oracle model the 
proof of security is viewed as “strong evidence“ that the 
scheme is actually secure in the “real world“. Authors 
presented and analyzed two schemes, which are based on the  
hardness of the Diffie-Hellman problem. 

The threshold RSA signature scheme of  Shoup [13]  is 
unforgeable and robust in the random oracle model, assuming 
the RSA problem is hard. Signature share generation and 
verification is completely non-interactive.  

First implementations of threshold signatures in 
asynchronous networks without random oracles are RSA 
signature schemes by Gennaro, Halevi and Rabin [14] and by 
Cramer and Shoup [15], which are based on strong RSA 
assumption. 

The first practical verifiable secret sharing protocol for 
asynchronous networks together with a proactive refresh 
protocol is proposed by Cachin et al. [16]. The authors 
propose a model of asynchronous proactive network that 
extends an asynchronous network by an abstract timer that is 
accessible to every server. The timer defines the phase of a 
server locally. They assume that the adversary corrupts up to  
t different servers who are in the same local phase. 
Uncorrupted servers who are  in the same local phase use 
private authenticated channels for communication. Message 
delay  in such a channel must be no longer than the local 
phase lasts. Otherwise  the message is lost. A proactive 
cryptosystem refreshes the shares of the secret key at the 
beginning of every phase. The liveness of the cryptosystem is 
based on the assumption that the adversary delays  messages 
of the refresh protocol for no longer than the phase lasts. 
Otherwise  the secret key may become inaccessible. This 
assumption seems reasonable because a phase typically lasts 
much longer than  the maximal delay of a message in the real-
world network. The proactive refresh protocol relies on a 
discrete logarithm-based verifiable secret sharing that is 
similar to Pedersen’s scheme [17]. The servers exchange two 
asynchronous rounds of messages to reach agreement on the 
success of the sharing. Agreement is achieved by using a 
randomized asynchronous multi-valued Byzantine agreement 
primitive [18]. Cachin et al. [16] left open the question of how 
proactive secure message transmission could be implemented. 

A protocol for proactive secure message transmission over 
an asynchronous network is presented in [19]. The authors 
specify proactive secure message transmission  in terms of an 
idealized service that has simple deterministic semantics and 
hides cryptographic objects from  its interfaces. Additionally, 
a real implementation is proposed and proved to be  at least as 
secure as the ideal service. The solution relies on a hardware 



 21

assumption, i.e., a secure co-processor that cannot be 
corrupted by the adversary.  

The first  purely asynchronous group key exchange 
protocol that tolerates a minority of servers to crash is 
presented in [20]. A group of servers communicate over an 
asynchronous network to establish a common session key 
such that anyone outside the group that can only observe  the 
network traffic cannot learn this key. Such a key can later be 
used to achieve multicast message confidentiality or data 
integrity. The protocol consists of the following two stages. In 
the first stage, the group members exchange keying 
information using two communication rounds. In the second 
stage, they execute consensus protocol to select the 
contributions  from the first stage where  the session key is 
computed. The protocol may use randomized asynchronous 
consensus  in the fully asynchronous model or a consensus 
protocol in the asynchronous model augmented with a failure 
detector. It is shown that any group exchange protocol among 
n servers that tolerates t>0 servers to crash can only provide 
forward secrecy  if the adversary occupies less than n-2t 
servers and  the presented protocol  achieves this bound. 

CODEX (COrnell Data Exchange)[21] is a distributed 
service for storage and dissemination of secret keys that uses 
an approach to building distributed services that are both 
fault-tolerant and attack tolerant. This approach includes  
asynchronous model of execution, which makes the system 
resistant to denial of service attacks. Byzantine quorum 
systems  are used  for storing the state, ensuring consistency 
among the servers, and proactive secret sharing with threshold 
cryptography implement confidentiality and authentication of 
service responses.  

The storage and transmission of data files in distributed 
systems gives rise to significant security and reliability 
problems.  Information dispersal algorithms store files by 
distributing them among a set of servers in a storage efficient 
way. The authors in [22] introduce the problem of verifiable 
information dispersal in an asynchronous network, where up 
to one third of servers as well as an arbitrary number of clients 
might  have Byzantine faults. Consistency of the stored 
information is ensured by verifiability. The secrecy of the 
stored data  is guaranteed  with respect to an adversary that 
may mount adaptive attacks. 

V. FUTURE RESEARCH 

The authors in [23] describe some research subjects that are 
important in the future development of distributed 
cryptography. For instance, there exist many situations in 
which general structures instead of threshold structures are 
required. Moreover, it is necessary to find new public key 
cryptosystems for non-threshold structures. The design of 
distributed cryptosystems with non-threshold access structure 
is closely related to the problem of performing multiparty 
computation on general access structures. The main question 
is how to find efficient linear secret sharing schemes with the 
multiplicative property and very little is known about that. 

 

VI. CONCLUSION 

We have presented main results in the field of threshold 
cryptography under the asynchronous model of distributed 
computing. We started with fundamental definitions, then 
pointed out the meeting place of cryptography  and distributed 
computing, and finally presented several solutions with 
concluding remarks concerning future research. 

REFERENCES 

[1] Y. Desmedt, “Threshold cryptography,” European Trans. on 
Telecommunicatons, 5(4), pp. 449-457, July-August 1994, 
(Invited paper). 

[2] Y. Desmedt, “Some Recent Research Aspects of Threshold 
Cryptography,” In Eiji Okamoto, George Davida, and Mashiro 
Mambo, editors, Information Security, The 1st International 
Workshop, ISW’97, Tatsunokuchi, Ishikawa  Japan, September 
17-19, 1997. 

[3] Y. Desmedt and Y. Frankel, “Threshold cryptosystems,” In G. 
Brassard, editor, Proc. CRYPTO 89, pages 307-315. Springer-
Verlag, 1990, Lecture Notes in Computer Science No. 435. 

[4] V. Shoup and R. Gennaro, “Securing threshold cryptosystem 
against chosen ciphertext attack,” Proc. EURO-CRYPT ’98, 
LNCS 1403, 1998. 

[5] R. Canneti, R. Gennaro, A.Herzberg, and D. Naor, “Proactive 
security: Long-term protection against break-ins,“ RSA 
Laboratories’ CryptoBytes, vol. 3, no.1, 1997. 

[6] B. Chor, S. Goldwasser, S. Micali, and B. Awerbuch, 
“Verifiable secret sharing and achieving simultaneity in the 
presence of faults,” Proc. 26th IEEE Symp. on Found. of 
Computer Science, pages 383-395, 1985. 

[7] O. Goldreich, “Cryptography and Cryptographic Protocols,” 
Distributed Computing, v.16, n.2-3, p.177-199, September 2003.  

[8] M. Ben-Or, R. Canetti and O. Goldreich, “Asynchronous Secure 
Computation,” 25th ACM Symposium on the Theory  of 
Computing, pages 52-61, 1993. 

[9] M. Ben-Or, B. Kelmer and T. Rabin, “Asynchronous Secure 
Computations with Optimal Resilience,”  13th ACM Symposium 
on Principles of Distributed Computing, pages 183-192, 1994. 

[10] D. Dolev, C. Dwork, O. Waarts, and  M. Yung, ”Perfectly 
secure message transmission,” Journal of the ACM, Vol. 40(1), 
pages 17-47, 1993. 

[11] A. Fiat and A. Shamir, “How to prove yourself: practical 
solutions to identification and signature problems“, Advances in 
Cryptology-Crypto ’86, Springer LNCS 263, pages 186-194, 
1987. 

[12] M. Bellare and P. Rogaway, “Random oracles are practical: a 
paradigm for designing efficient protocols“, First ACM 
Conference on Computer and Communications Security, pages 
62-73,1993. 

[13] V. Shoup, “Practical threshold signatures,” Proc. EURO-
CRYPT 2000, LNCS 1087, pp.207-220, 2000. 

[14] R. Gennaro, S. Halevi, and T. Rabin, “Secure hash-and-sign 
signatures without the random oracle,”  Proc. EUROCRYPT ’99, 
pp. 123-139, Springer, 1999. 

[15] R. Cramer and V. Shoup, “Signature schemes based on the 
strong RSA problem,” ACM Transactions on Information and 
System Security, vol. 3, no. 3, pp. 161-185, 2000. 

[16] C. Cashin, K. Kursawe, A. Lysyanskaya, and R. Strobl, 
“Asynchronous Verifiable Secret Sharing and Proactive 
Cryptosystems,”  Proc. 9th ACM Conference on Computer and 
Communications Security (CCS), pages 88-97, 2002.  



 22

[17] T. P. Pedersen, “Non-interactive and information-theoretic 
secure verifiable  secret sharing,” In J. Feigenbaum, editor, 
CRYPTO ’91, volume 576 of LNCS, pages 129-140, Springer, 
1992. 

[18] C. Cashin, K. Kursawe, F. Petzold, and V. Shoup, “Secure and 
efficient asynchronous broadcast protocols,” Advances in 
Cryptology-Crypto 2001, 2001.  

[19] M. Backes, C. Cashin, and R. Strobl, “Proactive Secure 
Message Transmission in Asynchronous Networks,” Proc. 22nd  
ACM Symposium on Principles of Distributed Computing 
(PODC 2003), pages 223-232, July 2003. 

[20] C. Cashin,  and R. Strobl “Asynchronous Group Key Exchange 
with Failures,” Proc. 23rd  ACM Symposium on Principles of 

Distributed Computing (PODC 2004), pages 357-366, July 
2004. 

[21] M. A. March, F. B. Schneider, “CODEX: A Robust and Secure 
Secret Distribution System,” IEEE Transactions on Dependable 
and Secure Computing, January-March 2004 (Vol.1, No.1) pp. 
34-47.  

[22] C. Cashin, S. Tessaro, “Asynchronous Verifiable Information 
Dispersal,” Research Report RZ 3569, IBM Research, December 
2004. 

[23] Research Group on Mathematics Applied to Cryptography, 
“Some trends for future research in distributed cryptography,” 
Stork Cryptography Workshop: Towards a Roadmap for Future 
Research, November 26-27, 2002. 

 


";"""date"",""2019-12-26T09:29:06Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""2.0""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dcterms:created"",""2019-12-26T09:29:06Z""
""language"",""en""
""Last-Modified"",""2019-12-26T09:29:06Z""
""dcterms:modified"",""2019-12-26T09:29:06Z""
""dc:format"",""application/pdf; version=2.0""
""Last-Save-Date"",""2019-12-26T09:29:06Z""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2019-12-26T09:29:06Z""
""meta:save-date"",""2019-12-26T09:29:06Z""
""pdf:encrypted"",""false""
""modified"",""2019-12-26T09:29:06Z""
""Content-Length"",""116236""
""pdf:hasMarkedContent"",""false""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""meta:creation-date"",""2019-12-26T09:29:06Z""
""created"",""2019-12-26T09:29:06Z""
""X-TIKA:EXCEPTION:warn"",""org.xml.sax.SAXParseException; lineNumber: 10; columnNumber: 26; The prefix """"xmp"""" for element """"xmp:CreateDate"""" is not bound.
	at org.apache.xerces.parsers.DOMParser.parse(Unknown Source)
	at org.apache.xerces.jaxp.DocumentBuilderImpl.parse(Unknown Source)
	at javax.xml.parsers.DocumentBuilder.parse(Unknown Source)
	at org.apache.tika.utils.XMLReaderUtils.buildDOM(XMLReaderUtils.java:421)
	at org.apache.tika.parser.pdf.PDMetadataExtractor.loadDOM(PDMetadataExtractor.java:329)
	at org.apache.tika.parser.pdf.PDMetadataExtractor.extract(PDMetadataExtractor.java:66)
	at org.apache.tika.parser.pdf.PDFParser.extractMetadata(PDFParser.java:281)
	at org.apache.tika.parser.pdf.PDFParser.parse(PDFParser.java:158)
	at org.apache.tika.parser.CompositeParser.parse(CompositeParser.java:280)
	at org.apache.tika.parser.CompositeParser.parse(CompositeParser.java:280)
	at org.apache.tika.parser.AutoDetectParser.parse(AutoDetectParser.java:143)
	at org.apache.tika.server.resource.TikaResource.parse(TikaResource.java:434)
	at org.apache.tika.server.resource.MetadataResource.parseMetadata(MetadataResource.java:130)
	at org.apache.tika.server.resource.MetadataResource.getMetadata(MetadataResource.java:62)
	at sun.reflect.GeneratedMethodAccessor5.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
	at java.lang.reflect.Method.invoke(Unknown Source)
	at org.apache.cxf.service.invoker.AbstractInvoker.performInvocation(AbstractInvoker.java:179)
	at org.apache.cxf.service.invoker.AbstractInvoker.invoke(AbstractInvoker.java:96)
	at org.apache.cxf.jaxrs.JAXRSInvoker.invoke(JAXRSInvoker.java:201)
	at org.apache.cxf.jaxrs.JAXRSInvoker.invoke(JAXRSInvoker.java:104)
	at org.apache.cxf.interceptor.ServiceInvokerInterceptor$1.run(ServiceInvokerInterceptor.java:59)
	at org.apache.cxf.interceptor.ServiceInvokerInterceptor.handleMessage(ServiceInvokerInterceptor.java:96)
	at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308)
	at org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121)
	at org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:265)
	at org.apache.cxf.transport.http_jetty.JettyHTTPDestination.doService(JettyHTTPDestination.java:247)
	at org.apache.cxf.transport.http_jetty.JettyHTTPHandler.handle(JettyHTTPHandler.java:79)
	at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
	at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:235)
	at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1435)
	at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:190)
	at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1350)
	at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
	at org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:191)
	at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
	at org.eclipse.jetty.server.Server.handle(Server.java:516)
	at org.eclipse.jetty.server.HttpChannel.lambda$handle$1(HttpChannel.java:388)
	at org.eclipse.jetty.server.HttpChannel.dispatch(HttpChannel.java:633)
	at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:380)
	at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:279)
	at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:311)
	at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:105)
	at org.eclipse.jetty.io.ChannelEndPoint$1.run(ChannelEndPoint.java:104)
	at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:336)
	at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:313)
	at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:171)
	at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:129)
	at org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:383)
	at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:882)
	at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:1036)
	at java.lang.Thread.run(Unknown Source)
""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""4""
""Creation-Date"",""2019-12-26T09:29:06Z""
""resourceName"",""ICEST2005_6.pdf""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""5763"",""6389"",""6114"",""1278""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-12-26T09:29:06Z""
";https://scholar.google.com/scholar?start=860&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094567-767;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Technische Grundlagen und Begriffe;R Wilkens, R Falk ; Smart Contracts, 2019  Springer;;"… Oracle) erfassen. Soll etwa eine Transaktion ausgeführt werden, wenn eine physische Ware

übergeben wurde, benötigt der Smart Contract zunächst diese Information. Mittels eines Oracles

für eingehende Daten können Datenfeeds über außerhalb der Blockchain eintretende …";;null;null;;;;https://scholar.google.com/scholar?start=580&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094551-700;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;DLT smart contract platforms for software lifecycle management;B Tsvetkov, H Kostadinov ; AIP Conference Proceedings, 2019  aip.scitation.org;;"… of the dApp is accessible by all participants of the processes, as EOS is a public blockchain. For

the purpose of the prototype a couple of oracles are established to test the abilities … First oracle

(O1) is responsible to update the catalog of supported software artifacts uploaded by …";Cité 1 fois;Les 2 versions;[PDF] scitation.org;https://aip.scitation.org/doi/pdf/10.1063/1.5130875?casa_token=hYKakJ4xAq4AAAAA:u0OJYTZaIL94bpIWMjLV3BfNV2o1NdDiiBuhxK9wT6oKT-cfZd28jxp8tOUpJM7f9xhJeSqIyg;;;https://scholar.google.com/scholar?start=510&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094637-1062;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[HTML][HTML] ?????????-10 ???: ??????? ????????????? ? ??????????? ??? ???????;?? ??????? ; ??????? ???????? ??????, 2019  cyberleninka.ru;;"… ???????? ?????: ????????, ????????????, ??????-????????, ??????, ??????,

??????????????????? ????????????,. Keywords: blockchain, cryptocurrency, business processes,

money, currency, business. ???????? … 1. Buterin, Vitalik Etereum and Oracles. Etereum Blog …";Cité 5 fois;Les 2 versions;[HTML] cyberleninka.ru;https://cyberleninka.ru/article/n/blokcheynu-10-let-illyuzii-razrabotchikov-i-perspektivy-dlya-biznesa;"
    

    


    
      
        



  [image: Научная статья на тему 'Блокчейну - 10 лет: иллюзии разработчиков и перспективы для бизнеса'][image: ]



  Блокчейну - 10 лет: иллюзии разработчиков и перспективы для бизнеса Текст научной статьи по специальности «Экономика и бизнес»

  
    

    
    
      [image: ]CC BY

    
    
      [image: ]30
[image: ]5

    

  


  
    
    

  


	
  
    
      
        
          

        

        
          

        

        

      

    

  

  
  
    
       
         i
         Надоели баннеры? Вы всегда можете 
           отключить рекламу.
       

    

  


	

  
    
			
      Журнал[image: ]

      Вестник Академии знаний
      
	      2019

        
  ВАК


      

    

    
      Область наук

      	ЭкОнОПика и йиСнос


    

  


  
  
    
      Ключевые слова

      
        
          BLOCKCHAIN / 
        
          CRYPTOCURRENCY / 
        
          BUSINESS PROCESSES / 
        
          MONEY / 
        
          CURRENCY / 
        
          BUSINESS / 
        
          БЛОКЧЕЙН / 
        
          КРИПТОВАЛЮТА / 
        
          БИЗНЕС-ПРОЦЕССЫ / 
        
          ДЕНЬГИ / 
        
          ВАЛЮТА / 
        
          ПРЕДПРИНИМАТЕЛЬСКАЯ ДЕЯТЕЛЬНОСТЬ
        
      
    

  

  

  
  
    
      Аннотация научной статьи по экономике и бизнесу, автор научной работы — Полянин А.В.

      В статье опровергается одно из базовых утверждение разработчиков блокчейн технологий и авторов большинства научных работ о том, что каждая учетная запись с переходом состояния является прямой передачей стоимости и информации между учетными записями. Обосновывается, что криптовалюты необходимо рассматривать как одну из форм безналичного расчета, в основе которого лежат реальные деньги, трансформируемые по средством майнинга в определенный заменитель, по своим свойствам мало отличимый от таких производных как например «полетные мили». На взгляд автора криптовалюта является инструментом привязки пользователя к определенной блокчейн технологии хранения и обработки данных. Любые криптовалюты привязывают пользователей к определенному распределенному регистру, то есть пользователи выбирают определенную технологию программного обеспечения для ведения хозяйственной деятельности. То есть пользователь выбирает только лишь услугу по отслеживанию и фиксации необходимых нам действий, но не передаче стоимости. В тоже время с точки зрения ведения бизнеса очень полезным является то, что блокчейн-платформы могут служить хранилищем имеющих общественную значимость записей, таких как реестры документов, событий, личных данных. Для бизнеса наиболее перспективным можно считать объединение блокчейн технологий и «больших данных», то есть появляется возможность моделировать большое количество бизнес-процессов.

    

  

  

	
	
		
			
			        
					

				

			        
					

				

			

		

	

  
  
    
       
         i
         Надоели баннеры? Вы всегда можете 
           отключить рекламу.
       

    

  


	

	
    
      Похожие темы научных работ по экономике и бизнесу , автор научной работы — Полянин А.В.

      	Профессиональный библиограф составит и оформит по ГОСТ список литературы для вашей работы
Подбор литературы
	
          
            Криптовалюты: сущность, эволюция и становление в качестве средства платежа

            2018 / Гуляев Роман Андреевич
          
        
	
          
            Трансформация мировой валютной системы: будущее за криптовалютой?

            2018 / Щеголева Наталья Геннадьевна, Терентьева Ольга Игоревна
          
        
	
          
            Криптовалюты как вектор диджитализации мировой валютной системы: риски и тренды

            2019 / Щеголева Наталья Геннадьевна, Мальсагова Радима Гапуровна
          
        
	
          
            Блокчейн: философия, технология, приложения и риски

            2019 / Годин В. В., Терехова А. Е.
          
        
	
          
            Влияние технологических аспектов функционирования криптовалют на их принятие в качестве ""альтернативных денег""

            2018 / Попов В.Б., Гавриков И.В.
          
        


    

  


  
    
       iНе можете найти то, что вам нужно? Попробуйте сервис подбора литературы.

    

  


  
    

  


	
  
    
      
        
          

        

        
          

        

      

    

  

  
  
    
       
         i
         Надоели баннеры? Вы всегда можете 
           отключить рекламу.
       

    

  


	

  
  
    
      Blockchain - 10 years: developer illusions and business prospects

      The article refutes one of the basic statements of the developers of blockchain technologies and the authors of most scientific works that each account with the transition of the state is a direct transfer of value and information between accounts. Proves that cryptocurrencies should be seen as a form of cashless payment, which is based on real money that is transformed by hashing into a specific substitute, their properties are indistinguishable from these derived such as ""mileage"". In the author's opinion, the cryptocurrency is a tool for binding the user to a certain blockchain technology of data storage and processing. Any cryptocurrency tie users to a particular distributed case, i.e. users select a specific software technology for business activities. Thanks to a certain blockchain platform or blockchain technology, the user chooses only the service of tracking and recording the actions we need, but not the transfer of cost. At the same time, from the point of view of doing business, it is very useful that blockchain platforms can serve as a repository of records of public importance, such as registers of documents, events, personal data. For business, the most promising can be considered a combination of blockchain technology and"" big data"", that is, there is an opportunity to simulate a large number of business processes

    

  

  
  
    
      Текст научной работы на тему «Блокчейну - 10 лет: иллюзии разработчиков и перспективы для бизнеса»

      
				
        
          

        

				
        
        08.00.05. Экономика и управление народным хозяйством (по отраслям и сферам деятельности)

         
        
        А.В. Полянин - профессор кафедры менеджмента и государственного управления, д.э.н., Среднерусский институт управления - филиал РАНХиГС (г. Орел) (polyanin.andrei@yandex.ru);

         
         
         
        
        A.V. Polyanin - Professor of the Department of management and public administration, doctor of economics, Central Russian Institute of management - branch of Ranepa (Orel).

         
         
         
        
        БЛОКЧЕЙНУ - 10 ЛЕТ: ИЛЛЮЗИИ РАЗРАБОТЧИКОВ И ПЕРСПЕКТИВЫ ДЛЯ БИЗНЕСА BLOCKED - 10 YEARS: DEVELOPERS 'ILLUSIONS AND PROSPECTS FOR BUSINESS

         
         
         
        
        Аннотация. В статье опровергается одно из базовых утверждение разработчиков блокчейн технологий и авторов большинства научных работ о том, что каждая учетная запись с переходом состояния является прямой передачей стоимости и информации между учетными записями. Обосновывается, что криптовалюты необходимо рассматривать как одну из форм безналичного расчета, в основе которого лежат реальные деньги, трансформируемые по средством майнинга в определенный заменитель, по своим свойствам мало отличимый от таких производных как например «полетные мили». На взгляд автора криптовалюта является инструментом привязки пользователя к определенной блокчейн технологии хранения и обработки данных. Любые криптовалюты привязывают пользователей к определенному распределенному регистру, то есть пользователи выбирают определенную технологию программного обеспечения для ведения хозяйственной деятельности. То есть пользователь выбирает только лишь услугу по отслеживанию и фиксации необходимых нам действий, но не передаче стоимости. В тоже время с точки зрения ведения бизнеса очень полезным является то, что блокчейн-платформы могут служить хранилищем имеющих общественную значимость записей, таких как реестры документов, событий, личных данных. Для бизнеса наиболее перспективным можно считать объединение блокчейн технологий и «больших данных», то есть появляется возможность моделировать большое количество бизнес-процессов.

         
         
         
        
        Annotation. The article refutes one of the basic statements of the developers of blockchain technologies and the authors of most scientific works that each account with the transition of the state is a direct transfer of value and information between accounts. Proves that cryptocurrencies should be seen as a form of cashless payment, which is based on real money that is transformed by hashing into a specific substitute, their properties are indistinguishable from these derived such as ""mileage"". In the author's opinion, the cryptocurrency is a tool for binding the user to a certain blockchain technology of data storage and processing. Any cryptocurrency tie users to a particular distributed case, i.e. users select a specific software technology for business activities. Thanks to a certain blockchain platform or blockchain technology, the user chooses only the service of tracking and recording the actions we need, but not the transfer of cost. At the same time, from the point of view of doing business, it is very useful that blockchain platforms can serve as a repository of records of public importance, such as registers of documents, events, personal data. For business, the most promising can be considered a combination of blockchain technology and"" big data"", that is, there is an opportunity to simulate a large number of business processes

         
         
         
        
        Ключевые слова: блокчейн, криптовалюта, бизнес-процессы, деньги, валюта, предпринимательская деятельность,

         
         
         
        
        Keywords: blockchain, cryptocurrency, business processes, money, currency, business.

         
         
         
        
        Введение. Прошло уже 10 лет со времени выхода знаменитой статьи Сатоши Накамото «Биткоин. Децентрализованная электронная денежная система» [2], где он описал базовую возможность блокчейна по выполнению функции доверенного лица без централизованного вмешательства или управления. Именно эта функция на наш взгляд является ключевой с точки зрения пользователя для ведения бизнеса. Ведь интернет мы используем, прежде всего, как систему обеспечивающую нас информацией и позволяющую нам реализовать нашу функцию «получения информации». Так и блокчейн прежде всего нам интересен с точки зрения эффективного межличностного взаимодействия «доступ без разрешений» по средством согласованного платежа [11]. В тоже время существуют много неоправданных ожиданий заявленных разработчиками, прежде всего, становится очевидным неправильная трактовка «передачи денег» на основании данной технологии. Многие разработчики и пользователи блокчейна не понимают главных отличий категорий «товарная стоимость» и «добавленная стоимость». Также не рассматриваются психологические и социальные аспекты деятельности человека при ведении хозяйственной деятельности, а также не учтено влияние политических и социальных институтов государства. Цель автора раскрыть заблуждения (иллюзии) разработчиков блокчейна и рассмотреть перспективы для бизнеса при использовании данной технологии.

         
         
         
        
        Заблуждения разработчиков и перспективы для бизнеса применения технологий блокчейн. В современной научной литературе утверждается, что интернет в форме протокола TCP/IP позволяет нам находить и владеть информацией («интернет информационного обеспечения»), а блокчейн позволяет по своей сути напрямую обмениваться ценностями, создается «интернет ценностей». И как говорят большинство авторов, таких как Уильям Могайар [9], Виталик Бутерин [1], Мелани Свон [12], Дон и Алекс Тапскотт [15], Пол Винья и Майкл

         
         
         
        
        Кейси [3], Артем Генкин и Алексей Михеев [4]: блокчейн это новая организационная парадигма для координации различных видов человеческой деятельности позволяющая децентрализовать многие сферы нашей жизни. Большинство авторов утверждают, что технология «блокчейн» является революционной инновацией, создан «протокол Господа Бога» [3], который создаст «схему новой экономики» [12], на ее основе произойдет «финансовая революция» [15] и т.д.

         
         
         
        
        Позволю себе с ними не согласиться. По сути блокчейн совмещает в своем технологическом воплощении три элемента: определенное программное обеспечение, методы криптозащиты и несколько математических методов из теории игр. Заметим, что совмещение последних двух элементов уже с 30-х годов ХХ века успешно используется в технике связи для шифровки и дешифровки информации. Базовые технические элементы блок-чейна такие как: криптозащита, одноранговая сеть и децентрализованный консенсус уже в 1970-80 годах применялись советскими инженерами в технике связи. В настоящий момент они используются в различных технических устройствах применяемых во многих отраслях. Перемещение этих известных технических элементов в структуру программного обеспечения позволяет сделать надстройку в интернете, а уже ее вид может быть очень разнообразным, что и доказывается сейчас тем, что количество блокчейн-платформ и блокчейн-приложений постоянно увеличивается.

         
         
         
        
        Описывая блокчейн как взаимосвязь одноранговой сети, алгоритма консенсуса, концепции «виртуальной машины» (явно позаимствованной из популярного подхода Java Virtual Machine) и распределенного регистра авторы абсолютно правы с технической точки зрения, действительно запись и обмен информации осуществляется именно между двумя пользователями и запись их обмена регистрируется и хранится постоянно, создавая «учетные записи». А вот дальше утверждается «каждая учетная запись с переходом состояния является прямой передачей стоимости и информации между учетными записями» [9], это в принципе не верно, так как информация передается, а стоимость нет! Стоимость это оценочный показатель, который либо отражает количество трудовых затрат, либо полезность товара, либо издержки производства и т.д. Подразумевая под формой стоимости деньги, авторы заявляют, что блокчейн позволит «напрямую обмениваться ценностями - будь то деньги, активы и конфиденциальные сведения, которые прежде никто не рискнул бы передать с помощью сети» [3], это и является на наш взгляд самой большой иллюзией.

         
         
         
        
        Главное заблуждение (иллюзия разработчиков) состоит в том, что авторы отождествляют деньги и материальные ценности, то есть рассматривают деньги как материальный ресурс. А деньги по своей природе ресурсом вообще не являются. Именно вызывает недоумение «передача денег». Так в чем причина, что передача денег в блокчейне мы ставим под сомнение? Да, передача денег в экономическом смысле в помощью блокчейна возможна, но это будет операция аналогичная интернет-банкингу и передачи денег с помощью электронных кошельков. Авторы которые говорят о революционности блокчейна по обмену ценностями такими как деньги, прежде всего забывают, что деньги это не столько экономический инструмент, сколько инструмент социальный!

         
         
         
        
        Напомним точку зрения Марселя Мосса изложенную в «Концепции денежно-валютной системы» [10], где он объясняет существование денег: «осознанием способности добиться общего согласия социума в использовании денег как законного выражения стоимости». То есть деньги по своей сути это социальные убеждения. Об этом говорят и научные работы таких выдающихся ученых как Франсуа Симиан [13] и Георг Земмель [5].

         
         
         
        
        Намерение обладать деньгами, а в последующем желание купить или продать происходит на основе восприятия и побуждений личности, у которой сформированы определенные ценности, навязанные ей обществом или спонтанно возникшие у нее в воображении. Люди в первую очередь живут в психологической реальности и ассоциируют деньги как источник удовлетворения своих личных стремлений. С точки зрения психологии человека единственное применение денег - это приобретение чего-то желанного, но в тоже время деньги могут выступать в качестве предпочтительной формы богатства, так как являются установленной обществом формой сохранения ценности. Деньги по своей природе происходят не из экономических или технологических процессов, а прежде всего из социальных убеждений и психоаналитических способностей личности.

         
         
           iНе можете найти то, что вам нужно? Попробуйте сервис подбора литературы.

         
         
        
        Следующим заблуждением является то, что в технологии блокчейн стоимость рассматривается как архаичные понятия «меновая стоимость» или «товарной стоимость», так как вся суть построения «учетных записей» в обмене ценностями. Но здесь следует отметить, что истории о бартере не имеют смысла в современном обществе по двум причинам. Во-первых, капиталистическое производство началось с денег, а не с товаров. Капиталисты не производят товар ради обмена на другие товары, они ждут денег, если их не получают, то производство данного товара прекращается. Товары производятся на продажу только с целью получения еще большей прибыли, то есть «добавленной стоимости», а именно денег, о чем свидетельствуют и Карл Маркс [8], и Адам Смит [14], и Джон Кейнс [7]. Во-вторых, деньги создает государство, выбирает в качестве платежного средства определенный нематериальный символ, закрепляет его законодательно и на основе него формирует налоговую систему, налоги в свою очередь являются движущей силой денег как социального инструмента. Кажущаяся простота сделки на блокчейне обманчива, так как это не более чем действие которое совершает человек приобретая товар через объявление в газете или на сайте, например на Avito или Youla. По сути приращения стоимости при такой сделке не происходит, оно изначально в нее не заложено.

         
         
         
        
        На наш взгляд также очень спорным является суждение, что «криптовалюта» является действительно деньгами и сочетает в себе обе базовые функции денег - платежное средство и расчетная единица. Использование цифровой валюты наиболее обсуждаемый элемент блокчейна, особенно если она является публичной, такие как Bitcoin, Litecoin, Dogecoin и другие. Как и в случае с традиционной валютой, это тоже определенный символ и

         
         
         
        
        на этом на наш взгляд сходства заканчиваются. Даже такой ярый сторонник блокчейна как Уильям Могайар констатирует: «Криптовалюта очень эффективна в сетях, но каждый раз когда она сталкивается с реальным миром традиционных валют, возникает трение» [9]. Почему так происходит? Начиная со времени «золотого стандарта» объединение функций платежного средства и расчетной единицы привело к появлению главной функции денег - сохранения стоимости. Эта позиция сохранилась и после отмены золотого стандарта и ввода бумажных денег. Национальные государственные валюты используемые как платежное средство имеют фиксированное отношение к расчетной единице и следовательно сохраняют стоимость.

         
         
         
        
        Сторонники блокчейна характеризуют криптовалюту как некапиталистическую форму доног, то есть пО их мнению отсутствуют посредники и соответственно сохраняется йаНанс интересов. Стоит отметить, что попытки создания некапиталистических валют уМо предпринимались и ранее. Наиболее ярким является пример «банкора». Выдающийся экономист Джон Кейнс разрабатывал систему в которой нет платежных средств, Đ° деньги являются нематериальной абстрактной расчетной единицей. Для международных транзакций создается международная валюта «банкор», которая генерируется каждый раз кОгда нуМнО профинансировать внешнеторговый дисйаНанс. Это предложение но нашНО свОогО применения на практике. На наш взгляд такая система ведет Đş неопределенности пО обязательствам и ликвидации гарантий пО возращению дОНга. Устраняет неопределенность только сохранение стоимости. И тот Мо самый Джон Кейнс в свОоП гНавнОП научном труде «Теория процентной ставки» констатирует, что «процентная ставка объясняется спросом на деньги как средство сохранения стоимости» [7]. Все остальные активы, Đ° всо криптовалюты ПОМнО отнести иПоннО Đş нематериальным активам, ноĐ";"""citation_keywords"",""BLOCKCHAIN, CRYPTOCURRENCY, BUSINESS PROCESSES, MONEY, CURRENCY, BUSINESS,
""og:image"",""https://cyberleninka.ru/article/n/blokcheynu-10-let-illyuzii-razrabotchikov-i-perspektivy-dlya-biznesa/og""
""og:image:width"",""1074""
""twitter:card"",""summary_large_image""
""eprints.ispublished"",""pub""
""og:site_name"",""КиберЛенинка""
""keywords"",""научная статья бесплатно на тему Блокчейну - 10 лет: иллюзии разработчиков и перспективы для бизнеса текст научной работы по экономике и бизнесу из научного журнала Вестник Академии знаний. BLOCKCHAIN, CRYPTOCURRENCY, BUSINESS PROCESSES, MONEY, CURRENCY, BUSINESS, БЛОКЧЕЙН, КРИПТОВАЛЮТА, БИЗНЕС-ПРОЦЕССЫ, ДЕНЬГИ, ВАЛЮТА, ПРЕДПРИНИМАТЕЛЬСКАЯ ДЕЯТЕЛЬНОСТЬ""
""eprints.pagerange"",""8-12""
""citation_journal_title"",""Вестник Академии знаний""
""eprints.publication"",""Вестник Академии знаний""
""language"",""ru""
""og:description"",""В статье опровергается одно из базовых утверждение разработчиков блокчейн технологий и авторов большинства научных работ о том, что каждая учетная запись с переходом состояния является прямой передачей стоимости и информации между учетными записями. Обосновывается, что криптовалюты необходимо рассматривать как одну из форм безналичного расчета, в основе которого лежат реальные деньги, трансформируемые по средством майнинга в определенный заменитель, по своим свойствам мало отличимый от таких производных как например «полетные мили». На взгляд автора криптовалюта является инструментом привязки пользователя к определенной блокчейн технологии хранения и обработки данных. Любые криптовалюты привязывают пользователей к определенному распределенному регистру, то есть пользователи выбирают определенную технологию программного обеспечения для ведения хозяйственной деятельности. То есть пользователь выбирает только лишь услугу по отслеживанию и фиксации необходимых нам действий, но не передаче стоимости. В тоже время с точки зрения ведения бизнеса очень полезным является то, что блокчейн-платформы могут служить хранилищем имеющих общественную значимость записей, таких как реестры документов, событий, личных данных. Для бизнеса наиболее перспективным можно считать объединение блокчейн технологий и «больших данных», то есть появляется возможность моделировать большое количество бизнес-процессов.""
""eprints.full_text_status"",""public""
""citation_issn"",""2304-6139""
""dc:title"",""Блокчейну - 10 лет: иллюзии разработчиков и перспективы для бизнеса – тема научной статьи по экономике и бизнесу читайте бесплатно текст научно-исследовательской работы в электронной библиотеке КиберЛенинка""
""eprints.place_of_pub"",""Россия, Краснодар""
""Content-Encoding"",""UTF-8""
""citation_pdf_url"",""https://cyberleninka.ru/article/n/blokcheynu-10-let-illyuzii-razrabotchikov-i-perspektivy-dlya-biznesa/pdf""
""robots"",""NOODP"",""noyaca""
""eprints.volume"",""""
""eprints.citation"",""Полянин А.В. Блокчейну - 10 лет: иллюзии разработчиков и перспективы для бизнеса // Вестник Академии знаний. 2019. Выпуск номер 1 (30), С.8-12""
""eprints.number"",""1 (30)""
""citation_author"",""Полянин А.В.""
""resourceName"",""blokcheynu-10-let-illyuzii-razrabotchikov-i-perspektivy-dlya-biznesa""
""citation_abstract_html_url"",""https://cyberleninka.ru/article/n/blokcheynu-10-let-illyuzii-razrabotchikov-i-perspektivy-dlya-biznesa""
""citation_issue"",""1 (30)""
""eprints.abstract"",""The article refutes one of the basic statements of the developers of blockchain technologies and the authors of most scientific works that each account with the transition of the state is a direct transfer of value and information between accounts. Proves that cryptocurrencies should be seen as a form of cashless payment, which is based on real money that is transformed by hashing into a specific substitute, their properties are indistinguishable from these derived such as """"mileage"""". In the author's opinion, the cryptocurrency is a tool for binding the user to a certain blockchain technology of data storage and processing. Any cryptocurrency tie users to a particular distributed case, i.e. users select a specific software technology for business activities. Thanks to a certain blockchain platform or blockchain technology, the user chooses only the service of tracking and recording the actions we need, but not the transfer of cost. At the same time, from the point of view of doing business, it is very useful that blockchain platforms can serve as a repository of records of public importance, such as registers of documents, events, personal data. For business, the most promising can be considered a combination of blockchain technology and"""" big data"""", that is, there is an opportunity to simulate a large number of business processes"",""В статье опровергается одно из базовых утверждение разработчиков блокчейн технологий и авторов большинства научных работ о том, что каждая учетная запись с переходом состояния является прямой передачей стоимости и информации между учетными записями. Обосновывается, что криптовалюты необходимо рассматривать как одну из форм безналичного расчета, в основе которого лежат реальные деньги, трансформируемые по средством майнинга в определенный заменитель, по своим свойствам мало отличимый от таких производных как например «полетные мили». На взгляд автора криптовалюта является инструментом привязки пользователя к определенной блокчейн технологии хранения и обработки данных. Любые криптовалюты привязывают пользователей к определенному распределенному регистру, то есть пользователи выбирают определенную технологию программного обеспечения для ведения хозяйственной деятельности. То есть пользователь выбирает только лишь услугу по отслеживанию и фиксации необходимых нам действий, но не передаче стоимости. В тоже время с точки зрения ведения бизнеса очень полезным является то, что блокчейн-платформы могут служить хранилищем имеющих общественную значимость записей, таких как реестры документов, событий, личных данных. Для бизнеса наиболее перспективным можно считать объединение блокчейн технологий и «больших данных», то есть появляется возможность моделировать большое количество бизнес-процессов.""
""eprints.eissn"",""2687-0983""
""citation_volume"",""""
""format-detection"",""telephone=no""
""citation_publication_date"",""2019""
""citation_title"",""Блокчейну - 10 лет: иллюзии разработчиков и перспективы для бизнеса""
""eprints.date"",""2019""
""citation_publisher"",""Общество с ограниченной ответственностью «Академия знаний»""
""eprints.type"",""article""
""description"",""В статье опровергается одно из базовых утверждение разработчиков блокчейн технологий и авторов большинства научных работ о том, что каждая учетная запись с переходом состояния является прямой передачей стоимости и информации между учетными записями. Обосновывается, что криптовалюты необходимо рассматривать как одну из форм безналичного расчета, в основе которого лежат реальные деньги, трансформируемые по средством майнинга в определенный заменитель, по своим свойствам мало отличимый от таких производных как например «полетные мили». На взгляд автора криптовалюта является инструментом привязки пользователя к определенной блокчейн технологии хранения и обработки данных. Любые криптовалюты привязывают пользователей к определенному распределенному регистру, то есть пользователи выбирают определенную технологию программного обеспечения для ведения хозяйственной деятельности. То есть пользователь выбирает только лишь услугу по отслеживанию и фиксации необходимых нам действий, но не передаче стоимости. В тоже время с точки зрения ведения бизнеса очень полезным является то, что блокчейн-платформы могут служить хранилищем имеющих общественную значимость записей, таких как реестры документов, событий, личных данных. Для бизнеса наиболее перспективным можно считать объединение блокчейн технологий и «больших данных», то есть появляется возможность моделировать большое количество бизнес-процессов.""
""title"",""Блокчейну - 10 лет: иллюзии разработчиков и перспективы для бизнеса – тема научной статьи по экономике и бизнесу читайте бесплатно текст научно-исследовательской работы в электронной библиотеке КиберЛенинка""
""eprints.document_url"",""https://cyberleninka.ru/article/n/blokcheynu-10-let-illyuzii-razrabotchikov-i-perspektivy-dlya-biznesa""
""twitter:site"",""@CyberLeninka""
""citation_fulltext_html_url"",""https://cyberleninka.ru/article/n/blokcheynu-10-let-illyuzii-razrabotchikov-i-perspektivy-dlya-biznesa""
""eprints.keywords"",""BLOCKCHAIN, CRYPTOCURRENCY, BUSINESS PROCESSES, MONEY, CURRENCY, BUSINESS, БЛОКЧЕЙН, КРИПТОВАЛЮТА, БИЗНЕС-ПРОЦЕССЫ, ДЕНЬГИ, ВАЛЮТА, ПРЕДПРИНИМАТЕЛЬСКАЯ ДЕЯТЕЛЬНОСТЬ""
""Content-Type-Hint"",""text/html; charset=utf-8""
""eprints.publisher"",""Общество с ограниченной ответственностью «Академия знаний»""
""Content-Type"",""text/html; charset=UTF-8""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""og:type"",""article""
""eprints.title"",""Блокчейну - 10 лет: иллюзии разработчиков и перспективы для бизнеса""
""og:title"",""Блокчейну - 10 лет: иллюзии разработчиков и перспективы для бизнеса""
""og:image:height"",""480""
""eprints.creators_name"",""Полянин А.В.""
""eprints.date_type"",""published""
""viewport"",""width=device-width, initial-scale=1""
""apple-mobile-web-app-capable"",""yes""
""og:url"",""https://cyberleninka.ru/article/n/blokcheynu-10-let-illyuzii-razrabotchikov-i-perspektivy-dlya-biznesa""
""citation_eissn"",""2687-0983""
""eprints.metadata_visibility"",""show""
""eprints.refereed"",""TRUE""
""eprints.issn"",""2304-6139""
";https://scholar.google.com/scholar?start=880&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094651-1126;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;White-box implementation of Shamir's identity-based signature scheme;Q Feng, D He, H Wang, N Kumar… ; IEEE Systems …, 2019  ieeexplore.ieee.org;;"… 1) Setup: For a given RSA instance (n, e, y = xe), B initials three empty lists Listh1 , Listh2 , and

ListKey and chooses two random oracles as hash functions h1 and h2. Finally, B sends (n, e,

h1,h2) as the system parameters params to A. 2) h1-Hash Oracle: For input of identity ID …";Cité 2 fois;Les 2 versions;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/4267003/4357939/08710266.pdf?casa_token=mi7AHnX5FCYAAAAA:TRIZnh3uEZew_HLllj_ZxJ61QUvvIGkfKB1aXcP7jl2lwLsqMem3QnIzUN3IJUX326oGcAT291E;"
		Skip to Main Content


		
			
				
				

				

			

		


		
			
				
					
						








	
		
	

	







						

						





























	
	
		
	
	
		
			

		
	

	
	
	



						





	
	
		
			
				IEEE Account

					Change Username/Password
	Update Address


			

			
				Purchase Details

					Payment Options
	Order History
	View Purchased Documents


			

			
				Profile Information

					Communications Preferences
	Profession and Education
	Technical Interests


			

			
				Need Help?

					US & Canada: +1 800 678 4333
	Worldwide:  +1 732 981 0060

					
	Contact & Support


			

		

		
			
				
					
							About IEEE Xplore
	Contact Us
	Help
	Accessibility
	Terms of Use
	Nondiscrimination Policy
	Sitemap
	Privacy & Opting Out of Cookies


						
							A not-for-profit organization, IEEE is the world's largest technical professional organization dedicated to advancing technology for the benefit of humanity.
Š Copyright 2021 IEEE - All rights reserved. Use of this web site signifies your agreement to the terms and conditions.
						

					


					

				

				
			

		

	


	
	


						
						






		
		
		
		
		
		
		
		
		
		
		
		
		
			
				
			
			
			
			
		
		
		
		
		
		

			


			

			
			


		
 		
		
			 

						
						









































	

		
		

		
		
		

		
			
		
		
		

		

		
		


		

		
		
		
		
		
		
		
		
		
		
	
	


















		
		
			
				
					
					
								
					
								
			
				
					
					
								
					
								
			
				
					
						








 



					
					
								
			
				
					
					
								
			
				
					
					
								
					
								
			
				
					
					
								
					
								
			
				
					
					
								
					
								
			
				
					
					
								
					
								
			
				
					
					
								
					
								
			
				
					
					
								
					
								
			
		
	




























		
			
					
			
					
			
					
			
				
					








					
			
					
			
					
			
					
			
					
			
					
			
					
			
		
		
	





	
	
	
	
	
	
	


	
	
	

	

















					

				

			


			
				
			
		

	";"""og:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""twitter:title"",""White-Box Implementation of Shamir’s Identity-Based Signature Scheme""
""twitter:card"",""summary""
""Description"",""Digital signature schemes have been extensively studied in the literature, where a large number of such schemes with different properties have been designed for""
""og:title"",""White-Box Implementation of Shamir’s Identity-Based Signature Scheme""
""resourceName"",""08710266.pdf""
""language"",""en""
""title"",""White-Box Implementation of Shamir’s Identity-Based Signature Scheme | IEEE Journals & Magazine | IEEE Xplore""
""og:description"",""Digital signature schemes have been extensively studied in the literature, where a large number of such schemes with different properties have been designed for different applications. For example, identity-based signature (IBS) schemes can efficiently map a user's digital public key to his/her real-world identity (e.g., e-mail address). However, existing implementations of IBS schemes are not generally designed for white-box security (WBS), particularly concerning the protection of the private key when special attackers have full access to the execution environment. Therefore, in this paper, we propose the first white-box implementation for the classical Shamir's IBS scheme. The basic idea is to utilize a mathematical transformation for embedding private key into some special tables, such that the original private key could be “invisible” during the execution process. We then analyze the security requirements achieved in our implementation, including the conventional black-box security under the random oracle model and WBS (e.g., key recovery attack resilience). This is the first IBS scheme implementation that satisfies WBS. It is also shown from the simulation that the implementation incurs a constant computational cost, which is realistic in deployments where a high security level is required.""
""twitter:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-UA-Compatible"",""IE=Edge""
""viewport"",""width=device-width, initial-scale=1.0""
""dc:title"",""White-Box Implementation of Shamir’s Identity-Based Signature Scheme | IEEE Journals & Magazine | IEEE Xplore""
""twitter:description"",""Digital signature schemes have been extensively studied in the literature, where a large number of such schemes with different properties have been designed for different applications. For example, identity-based signature (IBS) schemes can efficiently map a user's digital public key to his/her real-world identity (e.g., e-mail address). However, existing implementations of IBS schemes are not generally designed for white-box security (WBS), particularly concerning the protection of the private key when special attackers have full access to the execution environment. Therefore, in this paper, we propose the first white-box implementation for the classical Shamir's IBS scheme. The basic idea is to utilize a mathematical transformation for embedding private key into some special tables, such that the original private key could be “invisible” during the execution process. We then analyze the security requirements achieved in our implementation, including the conventional black-box security under the random oracle model and WBS (e.g., key recovery attack resilience). This is the first IBS scheme implementation that satisfies WBS. It is also shown from the simulation that the implementation incurs a constant computational cost, which is realistic in deployments where a high security level is required.""
""Content-Encoding"",""UTF-8""
""Content-Type-Hint"",""text/html; charset=utf-8""
""Content-Length"",""48374""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=940&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094579-818;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[HTML][HTML] Controlled secure social cloud data sharing based on a novel identity based proxy re-encryption plus scheme;XA Wang, F Xhafa, J Ma, Z Zheng ; Journal of Parallel and Distributed …, 2019  Elsevier;;"JavaScript is disabled on your browser. Please enable JavaScript to use all

the features on this page. Skip to main content Skip to article …";Cité 12 fois;Les 4 versions;[HTML] sciencedirect.com;https://www.sciencedirect.com/science/article/pii/S0743731519302345?casa_token=cEP_Ji0PJ_oAAAAA:1qb_czdaBRCZKR5hSw2692Q3T0oO9mYcot7F5qJaMhQ8w5ciZ6KC-3wGd4Em29G1meD9k9oS;;;https://scholar.google.com/scholar?start=630&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094605-921;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Upper and lower bounds for continuous non-malleable codes;D Dachman;Soled, M Kulkarni  IACR International Workshop on Public …, 2019  Springer;;"… (CRYPTO'18) considered the construction of a relaxed notion of 2-split-state CNMC from minimal

assumptions … mathsf {E}, \mathsf {D})\), where \(\mathsf {E}\) is the encoding function and \(\mathsf

{D}\) is the decoding function, the adversary interacts with an oracle \(\mathcal {O …";Cité 6 fois;Les 2 versions;[PDF] iacr.org;https://eprint.iacr.org/2018/517.pdf;"
Upper and Lower Bounds for
Continuous Non-Malleable Codes

Dana Dachman-Soled ? and Mukul Kulkarni

University of Maryland, College Park, USA
danadach@ece.umd.edu, mukul@terpmail.umd.edu

Abstract. Recently, Faust et al. (TCC’14) introduced the notion of continuous non-malleable codes
(CNMC), which provides stronger security guarantees than standard non-malleable codes, by allowing
an adversary to tamper with the codeword in a continuous way instead of one-time tampering. They
also showed that CNMC with information theoretic security cannot be constructed in the 2-split-state
tampering model, and presented a construction in the common reference string (CRS) model from
collision-resistant hash functions and non-interactive zero-knowledge proofs.
In this work, we ask if it is possible to construct CNMC from weaker assumptions. We answer this
question by presenting lower as well as upper bounds. We show that it is impossible to construct 2-
split-state CNMC, with no CRS, for one-bit messages from any falsifiable assumption, thus establishing
the lower bound. We additionally provide an upper bound by constructing 2-split-state CNMC for one-
bit messages, assuming only the existence of a family of injective one way functions. We note that
in a recent work, Ostrovsky et al. (CRYPTO’18) considered the construction of a relaxed notion of
2-split-state CNMC from minimal assumptions.
We also present a construction of 4-split-state CNMC for multi-bit messages in CRS model from the
same assumptions. Additionally, we present definitions of the following new primitives: 1) One-to-one
commitments, and 2) Continuous Non-Malleable Randomness Encoders, which may be of independent
interest.

Keywords: Continuous non-malleable codes, black-box impossibility, split-state.

1 Introduction

Non-malleable codes (NMC). Non-malleable codes were introduced by Dziembowski, Pietrzak and Wichs [36]
as a relaxation of error-correcting codes, and are useful in settings where privacy—but not necessarily
correctness—is desired. The main application of non-malleable codes proposed in the literature is for pro-
tecting a secret key stored on a device against tampering attacks, although non-malleable codes have also
found applications in other of areas of cryptography [25, 24, 48] and theoretical computer science [20].

Continuous Non-malleable codes (CNMC). Importantly, standard non-malleable codes achieve security only
against one-time tampering. So in applications, the non-malleable encoding of a secret key must be continually
decoded and re-encoded, incurring overhead in computation and in generation of randomness for re-encoding.
This motivated a stronger notion of non-malleable codes, continuous non-malleable codes (CNMC), intro-
duced by Faust et al. [39]. This definition allows many-time tampering–i.e. the adversary can continuously
tamper with the codeword and observe the effects of the tampering. Due to known impossibility results, there
must also be a “self-destruct” mechanism: If, upon decode, the device detects an error, then a “self-destruct”
mechanism, which erases the secret key, is triggered, rendering the device useless.

The notion of CNMC with respect to a tampering class F is as follows: Given a coding scheme Π = (E,D),
where E is the encoding function and D is the decoding function, the adversary interacts with an oracle
OΠ(C), parameterized by Π and an encoding of a message m, C ← E(m). We refer to the encoding C as the

? This work is supported in part by NSF grants #CNS-1840893, #CNS-1453045 (CAREER), by a research partner-
ship award from Cisco and by financial assistance award 70NANB15H328 from the U.S. Department of Commerce,
National Institute of Standards and Technology.



“challenge” encoding. In each round, the adversary submits a tampering function f ∈ F . The oracle evaluates
C ′ = f(C). If D(C ′) = ⊥, the oracle outputs ⊥ and a “self-destruct” occurs, aborting the experiment. If
C ′ = C, the oracle outputs a special message “same.” Otherwise, the oracle outputs C ′. We emphasize that
the entire tampered codeword is returned to the adversary in this case. A CNMC is secure if for every pair
of messages m0,m1, the adversary’s view in the above game is computationally indistinguishable when the
message is m0 or m1.

Recently, Ostrovsky et al. [62] proposed a relaxed definition of CNMC (sufficient for many applications)
along with a construction, in which the oracleOΠ(C) returns, if valid, the decoding of the tampered codeword
D(C ′) (or “same”) instead of the tampered codeword C ′ as in the standard (original) definition of [39]. In
terms of applications, the difference between the original notion (which we consider in this paper) and the
notion of [62], is that the notion we consider captures stronger types of side-channel attacks: Our notion
provides security against an adversary who tampers and additionally learns information about the modified
codeword C ′ through other side-channels. As a concrete example, an interesting research direction is to
compose a split-state CNMC (under the original definition) with a leakage-resilient circuit compiler, such
as the compiler of Ishai, Sahai and Wagner [50], in order to yield a compiler that simultaneously provides
security against tampering with memory and leakage on computation. For more discussion and comparison
of this paper with [62] see Section 1.2.

Split-state tampering. One of the most well-studied tampering classes for non-malleable codes is split-state
tampering. Here, the codeword is split into sections and the adversarial tampering function may tamper each
section independently. The case of 2-split-state tampering, where the codeword is split into two sections, is
of particular interest. See Section 1.4 for a discussion of prior work on NMC and CNMC against split-state
tampering.

Information-theoretic impossibility. The original CNMC paper of [39] showed an information-theoretic im-
possibility result for 2-split-state CNMC. To aid the subsequent discussion, we present an outline of this
result. The impossibility result considers a property of 2-split-state CNMC known as (perfect) “unique-
ness.” Informally, perfect uniqueness means that there do not exist triples (x, y, z) such that either (1)
y 6= z ∧ D(x, y) 6= ⊥ ∧ D(x, z) 6= ⊥ OR (2) x 6= y ∧ D(x, z) 6= ⊥ ∧ D(y, z) 6= ⊥. First, a perfectly unique
CNMC cannot be information-theoretically secure since, given L, the split-state tampering function can find
the unique R such that D(L,R) 6= ⊥ and then tamper based on m = D(L,R). On the other hand, if the
CNMC is not perfectly unique, then the following is an efficient attack (with non-uniform advice): Given a
tuple L′1, L

′
2, R

′ such that D(L′1, R
′) 6= ⊥ and D(L′2, R

′) 6= ⊥, the adversary can learn L bit-by-bit by using
the following tampering function in the i-th round: fL does the following: If the i-th bit of L is equal to 0,
replace L with L′1. Otherwise, replace L′ with L′2. fR always replaces R with R′. Now, in the i-th round,
if the oracle returns (L′1, R

′), then the adversary learns that the i-th bit of L is equal to 0. If the oracle
returns (L′2, R

′), then the adversary learns that the i-th bit of L is equal to 1. Once L is fully recovered, the
adversary can tamper based on m = D(L,R).

The computational setting. The above shows that the CNMC setting is distinguished from other NMC
settings, since information-theoretic (unconditional) security is impossible. Prior work has shown how to
construct 2-split-state CNMC in the CRS model under the assumptions of collision-resistant hash functions
and NIZK. On the other hand, CNMC’s imply commitment schemes, which in turn imply OWF. It remains
to determine where CNMC lies in terms of complexity assumptions and what are the minimal computational
assumptions needed to achieve CNMC. As mentioned previously, a very recent work of Ostrovsky et al. [62]
addressed minimizing computational assumptions under a relaxed definition of CNMC. See Section 1.2 for
more details.

Black-box reductions. In general, it is not feasible to unconditionally rule out the construction of a primitive
G from a cryptographic assumption H, since unconditionally ruling it out is as hard as proving P 6= NP .
Despite this, we can still show that the proof techniques we have at hand cannot be used to construct G
from assumption H. In the literature, this is typically done by showing that there is no black-box reduction

2



from primitive G to assumption H. In this work, what we mean by a black-box reduction is a reduction
that accesses the adversary in an input/output fashion only. However, we allow non-black-box usage of
the assumption H in both the construction and the proof (see Definition 6 for a formal definition tailored
to CNMC). While there are some exceptions [12, 14], the vast majority of cryptographic reductions are
black-box in the adversary.

1.1 Our Results

We present upper and lower bounds for CNMC in the 2-split-state model. First, we show that with no CRS,
single-bit CNMC in the 2-split-state model (with a black-box security proof) is impossible to construct from
any falsifiable assumption.

Theorem 1 (Informal). There is no black-box reduction from a single-bit, 2-split-state, CNMC scheme
Π = (E,D) to any falsifiable assumption.

On the other hand, in the CRS model, we show how to achieve single-bit CNMC in the 2-split-state
model from injective one-way functions.

Theorem 2. Assuming the existence of an injective one-way function family, there is a construction of
a 2-split-state CNMC for encoding single bit, in the CRS model. Moreover, the corresponding reduction is
black-box.

Actually, we show a somewhat more general result: First, we define a (to the best of our knowledge) new
type of commitment scheme called one-to-one commitment schemes in the CRS model. Informally, these
commitment schemes have the additional property that with all but negligible probability over ÎŁ produced
by CRS generation, for every string com, there is at most a single string d that will be accepted as a valid
decommitment for com (See Definition 9 for a formal definition). We also define the notion of a 2-split-state
CNM Randomness Encoder, which is the continuous analogue of the non-malleable randomness encoder
recently introduced by [53] (See Definition 5). We then show the following:

Theorem 3. Assuming the existence of one-to-one commitment schemes in the CRS model, there is a
construction of a 2-split-state CNM Randomness Encoder in the CRS model. Moreover, the corresponding
reduction is black-box.

One-to-one commitment schemes in the CRS model can be constructed from any injective one-way
function family. Furthermore, we show (in Appendix B) that 2-split-state CNM Randomness Encoders in
the CRS model imply 2-split-state CNMC for encoding single bit, in the CRS model. We therefore obtain
Theorem 2 as a corollary. Moreover, CNMC with perfect uniqueness in the CRS model implies one-to-one
commitment schemes in the CRS model in a straightforward way (see Appendix C).

We leave open the question of constructing CNMC in the CRS model from (non-injective) one-way func-
tions and/or showing a black-box separation between the two primitives. Finally, we extend the techniques
from our single-bit construction above to achieve the following:

Theorem 4. Assuming the existence of one-to-one commitment schemes in the CRS model, there is a
construction of a multi-bit, 4-split-state CNMC in the CRS model. Moreover, the corresponding reduction is
black-box.

Are prior CNMC reductions “black-box”? Prior CNMC reductions often proceed in a sequence of hybrids,
where in the final hybrid, the description of the adversary is incorporated in the definition of a leakage
function. It is then shown that the leakage-resilience properties of an underlying encoding imply that the view
of the adversary is statistically close when the encoded message is set to m0 or m1. While this may seem like
non-black-box usage of the adversary, we note that typically the leakage-resilience of the underlying encoding
is information-theoretic. When converting a hybrid-style proof to a reduction, the reduction will choose one
of the hybrid steps at random and use the fact that a distinguisher between some pair of consecutive hybrids
implies an adversary breaking an underlying assumption. Therefore, reductions of the type discussed above
are still black-box in the adversary, pairs of consecutive hybrids whose indistinguishability is implied by a
computational assumption yield a reduction in which the adversary is used in a black-box manner.

3



1.2 Comparison with Ostrovsky et al. [62]

The CNMC notion considered in this work is the original continuous non-malleable codes notion, first intro-
duced in [39] and then further studied in several follow-up works (including [51, 34, 40]). Recently, Ostrovsky
et. al. [62] introduced a relaxed notion of CNMC,1 which is sufficient for many applications. In the work
of Ostrovsky et. al. [62], they refer to the original notion as “continuous super-non-malleability” (since it
is analogous to “super-non-malleability”, a notion that was introduced in the non-continuous setting [41]).
They then presented a construction achieving the relaxed definition (which they simply call “continuous
non-malleability”), against 2-split-state tampering functions, assuming the existence of injective one-way
functions in the plain model (without CRS).

The difference between the two CNMC notions is that in the original CNMC notion, the tampering
oracle returns the entire modified codeword C ′ if C ′ = f(C) 6= C and D(C) 6= ⊥, whereas the relaxation
only requires the oracle to return D(C ′) but not C ′ itself. The original notion captures stronger types of
tampering attacks; specifically, it provides security against an adversary who learns arbitrary additional
information about the modified codeword C ′ through other side-channels.

Our result and the result of [62] are complementary and together give a full picture of the landscape of
assumptions required for CNMC. Our work shows that it is necessary to rely on setup assumptions (CRS) in
order to achieve the original, stronger security definition of CNMC. Moreover, if one is willing to assume the
existence of a CRS, we show that this type of CNMC can be achieved from nearly minimal computational
assumptions. In contrast, if one is not willing to assume the existence of a CRS, the work of [62] achieves
weaker security guarantees in the plain model (with no setup assumptions) from the same computational
assumptions. We also note that the work of Ostrovsky et. al. [62] explicitly lists the question we address in
this work as an interesting open problem. They state:

Interesting open questions related to our work are, for instance, whether continuous non-malleability
can be achieved, under minimal assumptions, together with additional properties, such as strong
non-malleability, super-non-malleability, augmented non-malleability, and locality . . .

1.3 Technical Overview

Lower bound. Recall that prior work has shown that if a CNMC is not perfectly unique, then there is an
efficient attack (with non-uniform advice). Thus, it remains to show that there is no black-box reduction
from a single-bit, perfectly unique CNMC scheme to any falsifiable assumption. We use the meta-reduction
approach, which is to prove impossibility by showing that given only black-box access to the split-state
adversary, A = (AL, AR), the reduction cannot distinguish between the actual adversary and a simulated
(efficient) adversary (which is possibly stateful). Since the view of the reduction is indistinguishable in the
two cases, the reduction must also break the falsifiable assumption when interacting with the simulated
adversary. But this in turn means that there is an efficient adversary (obtained by composing the reduction
and the simulated adversary), which contradicts the underlying falsifiable assumption. Consider the following
stateless, inefficient, split-state adversary A = (AL, AR), which leverages the uniqueness property of the
CNMC scheme: The real adversary, given L (resp. R), recovers the corresponding unique valid codeword
(L,R) (if it exists) and decodes to get the bit b. If b = 0, the real adversary encodes a random bit b′ using
internal randomness that is tied to (L,R), and outputs the left/right side as appropriate. If b = 1 or there
is no corresponding valid codeword, the real adversary outputs the left/right side of a random encoding of
a random bit, b′′ (generated using internal randomness that is tied to L or R respectively). The simulated
adversary is stateful and keeps a table containing all the L and R values that it has seen. Whenever a L
(resp. R) query is made, the simulated adversary first checks the table to see if a matching query to R
(resp. L) such that D(L,R) 6= ⊥ was previously made. If not, the simulated adversary chooses a random
encoding, (L′, R′), of a random bit b′, stores it in the table along with the L/R query that was made and
returns either L′ or R′ as appropriate. If yes, the simulated adversary finds the corresponding R (resp. L)

1 A similar relaxed definition was previously given for a variant of CNMC, known as R- CNMC [37], but in this
setting it was shown that it is actually impossible to achieve the stronger notion.

4



along with the pair (L′, R′) stored in the table. The simulated adversary then decodes (L,R) to find out b.
If b = 0, the simulated adversary returns either L′ or R′ as appropriate. Otherwise, the simulated adversary
returns the left/right side of an encoding of a random bit b′′. The uniqueness property allows us to prove that
the input/output behavior of the real adversary is identical to that of the simulated adversary. See Section 3
for additional details. For a discussion on why our impossibility result does not hold for the relaxed CNMC
notion considered by [62], see Appendix A.

Upper bound. For the upper bound, we construct a new object called a continuous non-malleable randomness
encoder (see Definition 5), which is the continuous analogue of the non-malleable randomness encoder recently
introduced by [53]. Informally, a continuous non-malleable randomness encoder is just a non-malleable code
for randomly chosen messages. It is then straightforward to show that a continuous non-malleable randomness
encoder implies a single-bit continuous non-malleable code (see Appendix B).

At a high level, the difficulty in proving continuous non-malleability arises from the need of the security
reduction to simulate the interactive tampering oracle, without knowing the message underlying the “chal-
lenge” encoding. The approach of prior work such as [39] was to include a NIZK Proof of Knowledge in
each part of the codeword to allow the simulator to extract the second part of the encoding, given the first.
This then allowed the simulator (with some additional leakage) to respond correctly to a tampering query,
while knowing only one of the two split-states of the original encoding. In our setting, we cannot use NIZK,
since our goal is to reduce the necessary complexity assumptions; therefore, we need a different extraction
technique.2 Our main idea is as follows: To respond to the i-th tampering query, we run the adversarial
tampering function on random (simulated) codewords (L′, R′) that are consistent with the output seen thus
far (denoted Outi−1A ) and keep track of frequent outcomes (occurring with non-negligible probability) of the

tampering function, L̂, R̂. I.e. SL (resp. SR) is the set of values of L̂ (resp. R̂) such that with non-negligible

probability over choice of L′ (resp. R′), it is the case that L̂ = fL(L′) (resp. R̂ = fR(R′)). We then show that
if the outcome of the tampering function applied to the actual “challenge” split-state L or R is not equal to
one of these frequent outcomes (i.e. fL(L) /∈ SL or fR(R) /∈ SR), then w.h.p. the decode function D outputs
⊥. This will allow us to simulate the experiment with only a small amount of leakage (to determine which of
the values in SL/SR should be outputted). Note that, while the sets SL/SR are small, and so only a few bits
are needed to specify the outcome, conditioned on the outcome being in SL/SR, the CNMC experiment runs
for an unbounded number of times, and so even outputting a small amount of information in each round can
ultimately lead to unbounded leakage. To solve this problem, we also consider the most frequent outcome in
the sets SL/SR. This is the value of L̂ (resp. R̂) that occurs with the highest probability when fL(L′) (resp.

fR(R′)) is applied to consistent L′ (resp. R′). Note that if a value L̂′ (resp. R̂′) is not the most frequent
value, then it occurs with probability at most 1/2. We argue that, for each round i of the CNMC experiment,

the probability that a value L̂′ (resp. R̂′) that is not the most frequent value is outputted by fL (resp. fR)
and self-destruct does not occur is at most 1/2. This allows us to bound, w.h.p., the number of times in
the entire tampering experiment that the value outputted by fL (resp. fR) is not the most frequent value.
Thus, when the value outputted by fL (resp. fR) is the most frequent value, the leakage function outputs
nothing, since the most frequent value can be reconstructed from the given information. In contrast, if the
value outputted by fL (resp. fR) is not the most frequent value, but is in the sets SL/SR, then it has a small
description and, moreover, this event occurs a bounded number of times. Therefore, we can afford to leak
this information up to some upperbounded number of rounds, while the total amount of leakage remains
small relative to the length of the encoding. Looking ahead, our construction will use a two-source extractor,
whose properties will guarantee that even given the leakage (which contains all the information needed to
simulate the CNMC experiment), the decoded value remains uniform random.

To show that if the outcome of the tampering function is not in SL or SR, then decode outputs ⊥
w.h.p., we first use the “uniqueness” property, which says that for every L̂ = fL(L) (resp. R̂ = fR(R)),

2 Note that our extraction technique is inefficient. This is ok, since the goal of the extraction technique is simply
to show that the view of the adversary can be simulated given a small amount of leakage on each of the two
split-states. Then, information-theoretic properties of the encoding are used to show that the view of the adversary
must be independent of the random encoded value.

5



there is at most a single “match”, R̂′ (resp. L̂′), such that DΣ(L̂, R̂′) 6= ⊥ (resp. DΣ(L̂′, R̂) 6= ⊥). Given the
“uniqueness” property, it is sufficient to show that for every setting of L,Outi−1A

Pr[fR(R) = R̂′ ∧ R̂′ /∈ SR | L ∧ Outi−1A ] ≤ negl(n) (1)

and that for every setting of R ∧ Outi−1A

Pr[fL(L) = L̂′ ∧ L̂′ /∈ SL | R ∧ Outi−1A ] ≤ negl(n). (2)

To prove the above, we first argue that for the “challenge” codeword, (L,R), the split-states L and R
are conditionally independent, given Outi−1A (assuming no ⊥ has been outputted thus far) and an additional
simulated part of the codeword. This means that the set of frequent outcomes SL (resp. SR) conditioned on
Outi−1A is the same as the set of frequent outcomes SL (resp. SR) conditioned on both Outi−1A and R (resp.

L). So for any R̂ /∈ SR,

Pr[fR(R) = R̂ | L ∧ Outi−1A ] ≤ negl(n)

and for any L̂ /∈ SL,
Pr[fL(L) = L̂ | R ∧ Outi−1A ] ≤ negl(n).

Since R̂′ (resp. L̂′) is simply a particular setting of R̂ /∈ SR (resp. L̂ /∈ SL), we have that (1) and (2) follow.
For the above analysis, we need the encoding scheme to possess the following property: The L,R sides of

the “challenge” codeword are conditionally independent given Outi−1A (and an additional simulated part of
the codeword), but any tampered split-state fL(L) or fR(R) created by the adversary has at most a single

“match,” R̂′ or L̂′.
To explain how we achieve this property, we briefly describe our construction. Our construction is based

on a non-interactive, equivocal commitment scheme in the CRS model and a two-source (inner product)
extractor. Informally, an equivocal commitment scheme is a commitment scheme with the normal binding
and hiding properties, but for which there exists a simulator that can output simulated commitments which
can be opened to both 0 and 1. In the CRS model, the simulator also gets to sample a simulated CRS.
Moreover, the CRS and commitments produced by the simulator are indistinguishable from real ones.

To encode a random value m, random vectors cL, cR such that 〈cL, cR〉 = m are chosen. We generate a
commitment com to cL||cR. The commitment scheme has the additional property that adversarially produced
commitments are statistically binding (even if an equivocal commitment has been released) and have at
most a single valid decommitment string. The left (resp. right) split-state L (resp. R) consists of com and
an opening of com to the bits of cL (resp. cR). The special properties of the commitment scheme guarantee
the “perfect uniqueness” property of the code. In the security proof, we replace the statistically binding
commitment com in the “challenge” codeword with an equivocal commitment. Thus, each split-state of
the challenge encoding, L (resp. R), contains no information about cR (resp. cL). Moreover, assuming “⊥”
is not yet outputted, the output received by the adversary in the experiment at the point that the i-th
tampering function is submitted, denoted Outi−1A is of the form (f1L(L) = v1, f

1
R(R) = w1), . . . , (f i−1L (L)) =

vi−1, f
i−1
R (R) = wi−1), where for j ∈ [i − 1], vj is equal to the left value outputted in response to the j-th

query and wj is equal to the right value outputted in response to the j-th query. (note that vj/wj can be set
to “same” if the tampering function leaves L/R unchanged). This allows us to argue that the distribution
of L | Outi−1A , R (resp. R | Outi−1A , L) is identical to the distribution of L | Outi−1A (resp. R | Outi−1A ) which
implies that the left and right hand sides are conditionally independent given Outi−1A and the equivocal
commitment, as desired. See Section 4 for additional details.

Extension to 4-state CNMC in CRS model from OWF. To encode a message m we now generate random
(cL,1, cR,1, cL,2, cR,2) conditioned on 〈cL,1, cR,1〉+〈cL,2, cR,2〉 = m (where addition is over a finite field). Now,
we generate a commitment com to cL,1||cR,1||cL,2||cR,2. Each of the four split states now consists of com and
an opening of com to the bits of cL,b (resp. cR,b). The analysis is similar to the previous case and requires the
property that at each point in the experiment the distribution of 〈cL,1, cR,1〉 (resp. 〈cL,2, cR,2〉) is uniform
random, conditioned on the output thus far. Our techniques are somewhat similar to those used in [34] in
their construction of 2t-split-state continuously non-malleable codes from t-split-state one-way continuously
non-malleable codes. See Section 5 for additional details.

6



1.4 Additional Related Work

Non-Malleable Codes. The notion of non-malleable codes (NMC) was formalized in the seminal work of
Dziembowski, Pietrzak and Wichs [36]. Split-state classes of tampering functions subsequently received a
lot of attention with a long line of works, including [59, 35, 4, 19, 3, 8, 2, 52, 56]. Other works focused on
various other classes of tampering functions, including [10, 7, 18, 38, 11, 9]. NMC have also been considered
in several other models for various applications such as in [29, 17, 15]. Other works on non-malleable codes
include [39, 22, 16, 6, 51, 40, 17, 54, 27, 34, 28].

Continuous Non-Malleable Codes Continuous Non-Malleable codes (CNMC) were introduced by Faust
etal. [39]. They gave a construction based on collision resistant hash functions and non-interactive zero
knowledge proof systems in the CRS model. They also showed the impossibility of constructing 2-split state
CNMC information theoretically. Subsequently, Jafargholi and Wichs [51] presented a general study of CN-
MCs and its variants with some existential results. Aggarwal et al. [5] gave the first information theoretic
construction in the 8-split-state model. Recently, Damg̊ard et al. [30] gave the first construction of infor-
mation theoretic CNMC against permutations. Faonio et al. [37] considered a variant of CNMC against
split-state tampering where the codeword is refreshed (to avoid self-destruct) in the CRS model. For a
discussion related to the recent work of Ostrovsky et al. [62], see Section 1.2 and Appendix A.

Non-Malleable Randomness Encoders (NMRE) NMRE were introduced recently by Kanukurthi et al. [53]
as a building block for constructing efficient (constant-rate) split-state NMC. In this work, we present the
stronger variant Continuous NMRE which allows continual tampering in split-state model.

Bounds on Non-Malleable Codes. Cheragachi and Guruswami [21] studied the “capacity” of non-malleable
codes and their work has been instrumental in asserting the claims of efficient constructions for non-malleable
codes since then (cf. [2, 7, 8]). A similar study was presented in [27] for locally decodable and updatable
NMC. This work studies bounds for continuous non-malleable codes in terms of complexity assumptions.

Black-Box Separations. Impagliazzo and Rudich ruled out black-box reductions from key agreement to
one-way function in their seminal work [49]. Their oracle separation technique was subsequently used to
rule out black-box reductions between various other primitives (cf. [69, 47] and many more). The meta-
reduction technique (cf. [26, 63, 45, 42, 64, 46, 1, 68, 13, 44]) has been useful for ruling out larger classes
of reductions—where the construction is arbitrary (non-black-box), but the reduction uses the adversary
in a black-box manner. The meta-reduction technique is often used to provide evidence that construction
of some cryptographic primitive is impossible under “standard assumptions” (e.g. falsifiable assumptions or
non-interactive assumptions).

2 Definitions and Preliminaries

Let N be the set of all natural numbers, i.e., N = {1, 2, 3, . . .}. For n ∈ N, we write [n] = {1, . . . , n}. For
a set S, x ← S denotes, sampling an element x uniformly at random from the set S. For an algorithm A,
y ← A(x) is the output obtained on execution of A on input x. If A(·, ·) is a randomized algorithm, then
y ← A(x, r), is the output random variable for input x and randomness r. We also write, A(x) instead of
A(x, r) if it is clear from the context for the brevity. A function δ(¡) is called negligible if for all sufficiently
large n and for every polynomial p(¡), it holds that δ(n) < 1/p(n). In this paper, we will denote a negligible
function by negl(¡).

For a random variable X, we sometimes also denote the corresponding probability distribution by X. An
ensemble of probability distributions {Xk}k∈N is a sequence of probability distributions. For two probability
ensembles {X}k and {Y }k, defined over a domain S with finite support we say that {X}k and {Y }k are
statistically indistinguishable if there exists a negligible function negl(¡) such that for all k ∈ N,

1

2

∑
s∈S
|Pr [Xk = s]− Pr [Yk = s]| ≤ negl(k)

7



We denote statistical indistinguishability by Xk
s
≈Yk.

Similarly, we say that two probability ensembles {X}k and {Y }k, defined over a domain S with finite
support we say that {X}k and {Y }k are computationally indistinguishable if for all probabilistic polynomial
time distinguishers D, there exists a negligible function negl(¡) such that for all k ∈ N,∣∣∣∣ Pr

x←Xk
[D(x) = 1]− Pr

y←Yk
[D(y) = 1]

∣∣∣∣ ≤ negl(k)

We denote computational indistinguishability by Xk
c
≈Yk.

If S is a set, we denote by US the uniform distribution over S. For k ∈ N, we denote by Uk the uniform
distribution over k-bit strings.

2.1 Randomness Extractors

The following lemma is from [66].

Lemma 1 (Inner-Product Two-Source Extractor). Let X,Y , Z be correlated variables, where X,Y

have their support in {0, 1}` = F
`
Îť

2Îť
and Îť|`, and are independent conditioned on Z. Let UÎť be uniform and

independent on F2Îť . Then
∆((Z, 〈X,Y 〉), (Z,Uλ)) ≤ 2−s

for ";"""date"",""2019-01-31T03:08:54Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2019-01-31T03:08:54Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017) kpathsea version 6.2.3""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2019-01-31T03:08:54Z""
""created"",""2019-01-31T03:08:54Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-01-31T03:08:54Z""
""resourceName"",""517.pdf""
""Author"",""""
""producer"",""pdfTeX-1.40.18""
""pdf:docinfo:producer"",""pdfTeX-1.40.18""
""pdf:unmappedUnicodeCharsPerPage"",""2"",""32"",""0"",""16"",""34"",""44"",""1"",""25"",""8"",""2"",""58"",""26"",""56"",""26"",""102"",""74"",""101"",""93"",""66"",""116"",""98"",""88"",""103"",""118"",""103"",""52"",""5"",""0"",""0"",""36"",""6""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2019-01-31T03:08:54Z""
""Last-Modified"",""2019-01-31T03:08:54Z""
""dcterms:modified"",""2019-01-31T03:08:54Z""
""title"",""""
""Last-Save-Date"",""2019-01-31T03:08:54Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2019-01-31T03:08:54Z""
""meta:save-date"",""2019-01-31T03:08:54Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017) kpathsea version 6.2.3""
""Content-Length"",""539118""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""31""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""3177"",""3917"",""3489"",""3968"",""4317"",""3665"",""3506"",""2041"",""1877"",""2158"",""2415"",""3292"",""3532"",""3059"",""2851"",""2032"",""2385"",""2852"",""2521"",""2804"",""2516"",""2089"",""2894"",""2422"",""1784"",""1070"",""2327"",""4133"",""4161"",""3436"",""1575""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-01-31T03:08:54Z""
";https://scholar.google.com/scholar?start=740&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094588-859;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Approaching the communication constraints of ethereum-based decentralized applications;M Pustišek, A Umek, A Kos ; Sensors, 2019  mdpi.com;;"… chain”. This shortcoming could be outdone by oracles [16]. These serve as

intermediaries, providing data feeds along with an authenticity proof to the blockchain

from/to external software (eg, web sites) or hardware entities …";Cité 8 fois;Les 9 versions;[PDF] mdpi.com;https://www.mdpi.com/1424-8220/19/11/2647/pdf;;;https://scholar.google.com/scholar?start=670&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094633-1050;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[PDF][PDF] Chaintegrity: blockchain-enabled large-scale e-voting system with robustness and universal verifiability;S Zhang, L Wang, H Xiong ; International Journal of Information Security, 2019  Springer;;"… 3. We prove that our system fulfills all the requirements that a blockchain-enabled large-scale

voting system should achieve … 1.1 Related works Initial attempts on designing e-voting protocols

over block- chain spawned cryptocurrency incentive systems …";Cité 10 fois;;[PDF] springer.com;https://idp.springer.com/authorize/casa?redirect_uri=https://link.springer.com/content/pdf/10.1007/s10207-019-00465-8.pdf&casa_token=wTolGPlv-k8AAAAA:WJ7ojE47mEwnOcQEazCx94Slip6xxAx4v-6nGSbyje5Rb4QjuPSexEMIJZn3CEvQnSsh6IFYp6qT7YE;;;https://scholar.google.com/scholar?start=860&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094590-864;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[CITATION][C] 13 Smart Contracts;LDM Tshibende;;;null;;null;null;;;;https://scholar.google.com/scholar?start=680&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094642-1082;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[CITATION][C] Commercializing Blockchain: Strategic Applications in the Real World;A Welfare ;2019 John Wiley & Sons;;null;Cité 5 fois;Les 2 versions;null;;;;https://scholar.google.com/scholar?start=900&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094541-654;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;The Latest from Corda: Cordite, Corda Enterprise, and Settler;D Mohanty ; R3 Corda for Architects and Developers, 2019  Springer;;"… 8. Oracle Sees 10% of Global GDP Stored in Blockchain by 2027 (www.nextbigfuture.com/2017/

10/oracle-sees-10-of-global-gdp-stored-in-blockchain-by-2027 … Banks Are Trying to Launch Crypto

Assets with R3 Tech (www.coindesk.com/banks-trying-launch-crypto-assets-r3 …";Cité 1 fois;;null;;;;https://scholar.google.com/scholar?start=470&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094600-903;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Bitcoin/Blockchain;DW Staat ; A Baseline of Development: Higher Education and …, 2019  books.google.com;;"… They have made five predictions about the future of blockchain technology by the year 2030: •

Prediction# 1: Government Crypto By 2030 most governments around the world will create or

adopt some form of virtual … wsj. com/oracle/5-ways-blockchain-revolutionizing-higher …";Autres articles;;null;;;;https://scholar.google.com/scholar?start=720&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094541-656;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;APRNET: Achieving Privacy-Preserving Real-Name Authentication over Blockchain for Online Services;Y Xu, B Cao, R Lu, Q Zhang ; 2019 11th International …, 2019  ieeexplore.ieee.org;;"… To achieve the above privacy requirement, any data published by SPs over blockchain can be

verified by the cloud server and … adopted, namely the bilinear pairing with composite order, BGN

homomorphic encryption [11], BB short signature without random oracle [12], and …";Autres articles;;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/8914721/8927844/08928072.pdf?casa_token=KLekqWNsGpEAAAAA:Gx5RVQyc1fD-6roRMnfYjFJf7M9BdC-K5AzrNmdY9UfR5yidcbCa1Y-_GCqsHSk6ZmT6aiHE1Ec;"
		Skip to Main Content


		
			
				
				

				

			

		


		
			
				
					
						








	
		
	

	







						

						





























	
	
		
	
	
		
			

		
	

	
	
	



						





	
	
		
			
				IEEE Account

					Change Username/Password
	Update Address


			

			
				Purchase Details

					Payment Options
	Order History
	View Purchased Documents


			

			
				Profile Information

					Communications Preferences
	Profession and Education
	Technical Interests


			

			
				Need Help?

					US & Canada: +1 800 678 4333
	Worldwide:  +1 732 981 0060

					
	Contact & Support


			

		

		
			
				
					
							About IEEE Xplore
	Contact Us
	Help
	Accessibility
	Terms of Use
	Nondiscrimination Policy
	Sitemap
	Privacy & Opting Out of Cookies


						
							A not-for-profit organization, IEEE is the world's largest technical professional organization dedicated to advancing technology for the benefit of humanity.
Š Copyright 2021 IEEE - All rights reserved. Use of this web site signifies your agreement to the terms and conditions.
						

					


					

				

				
			

		

	


	
	


						
						






		
		
		
		
		
		
		
		
		
		
		
		
		
			
				
			
			
			
			
		
		
		
		
		
		

			


			

			
			


		
 		
		
			 

						
						









































	

		
		

		
		
		

		
			
		
		
		

		

		
		


		

		
		
		
		
		
		
		
		
		
		
	
	


















		
		
			
				
					
					
								
					
								
			
				
					
					
								
					
								
			
				
					
						








 



					
					
								
			
				
					
					
								
			
				
					
					
								
					
								
			
				
					
					
								
					
								
			
				
					
					
								
					
								
			
				
					
					
								
					
								
			
				
					
					
								
					
								
			
				
					
					
								
					
								
			
		
	




























		
			
					
			
					
			
					
			
				
					








					
			
					
			
					
			
					
			
					
			
					
			
					
			
		
		
	





	
	
	
	
	
	
	


	
	
	

	

















					

				

			


			
				
			
		

	";"""og:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""twitter:title"",""APRNET: Achieving Privacy-Preserving Real-Name Authentication over Blockchain for Online Services""
""twitter:card"",""summary""
""Description"",""With the proliferation of mobile Internet applications, online services become a double-edge sword to our daily life, wherein security and privacy are notable. ""
""og:title"",""APRNET: Achieving Privacy-Preserving Real-Name Authentication over Blockchain for Online Services""
""resourceName"",""08928072.pdf""
""language"",""en""
""title"",""APRNET: Achieving Privacy-Preserving Real-Name Authentication over Blockchain for Online Services | IEEE Conference Publication | IEEE Xplore""
""og:description"",""With the proliferation of mobile Internet applications, online services become a double-edge sword to our daily life, wherein security and privacy are notable. To ensure data security, service providers may require users to register using real-name data. Thus, verifying the real-name information without privacy leakage is critical. In this paper, we propose a privacy-preserving real-name authentication scheme based on a classic blockchain paradigm, named APRNET. By taking advantages of cloud-enabled trusted authorities and bilinear pairing, APRNET verifies users' data in an encrypted form, which guarantees data security and user privacy. Detailed security and performance analysis validate the effectiveness of APRNET.""
""twitter:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-UA-Compatible"",""IE=Edge""
""viewport"",""width=device-width, initial-scale=1.0""
""dc:title"",""APRNET: Achieving Privacy-Preserving Real-Name Authentication over Blockchain for Online Services | IEEE Conference Publication | IEEE Xplore""
""twitter:description"",""With the proliferation of mobile Internet applications, online services become a double-edge sword to our daily life, wherein security and privacy are notable. To ensure data security, service providers may require users to register using real-name data. Thus, verifying the real-name information without privacy leakage is critical. In this paper, we propose a privacy-preserving real-name authentication scheme based on a classic blockchain paradigm, named APRNET. By taking advantages of cloud-enabled trusted authorities and bilinear pairing, APRNET verifies users' data in an encrypted form, which guarantees data security and user privacy. Detailed security and performance analysis validate the effectiveness of APRNET.""
""Content-Encoding"",""UTF-8""
""Content-Type-Hint"",""text/html; charset=utf-8""
""Content-Length"",""40549""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=470&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094539-642;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;… Analyse der Chancen und Risiken einer Zukunftstechnologie sowie der Vereinbarkeit der Systemkreise Technik und Recht (Blockchain Technology, Smart Contracts …;N Bilski ; Available at SSRN 3425805, 2019  papers.ssrn.com;;"… V I. Die Blockchain-Technologie. . . . . 1 … 27 III. Weitere technische Konzepte und Begrifflichkeiten. . . .

. 32 1. Oracles – Schnittstellen zur „realen Welt“ . . . . 32 2. TokenundICO …";Autres articles;;[PDF] researchgate.net;https://www.researchgate.net/profile/Nico_Bilski/publication/334883705_Blockchain-Technologie_Smart_Contracts_und_selbstvollziehende_Vertrage_-_Eine_Analyse_der_Chancen_und_Risiken_einer_Zukunftstechnologie_sowie_der_Vereinbarkeit_der_Systemkreise_Technik_und_Recht/links/5d44010b299bf1995b5e7bf5/Blockchain-Technologie-Smart-Contracts-und-selbstvollziehende-Vertraege-Eine-Analyse-der-Chancen-und-Risiken-einer-Zukunftstechnologie-sowie-der-Vereinbarkeit-der-Systemkreise-Technik-und-Recht.pdf;;;https://scholar.google.com/scholar?start=460&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094651-1122;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[PDF][PDF] The formation of smart contracts and beyond: Shaking the fundamentals of contract law;M Durovic, A Janssen ; Smart Contracts and Blockchain …, 2019  researchgate.net;;"… trigger the compensation can be verified reliably by oracles, which means by external sources …

It needs an external source, which is an 'oracle'. Oracle is a service called … Once the proposed

smart contract is posted on the blockchain and fulfilled the requirements …";Cité 9 fois;Les 2 versions;[PDF] researchgate.net;https://www.researchgate.net/profile/Andre_Janssen/publication/327732779_The_Formation_of_Smart_Contracts_and_Beyond_Shaking_the_Fundamentals_of_Contract_Law/links/5ba16339299bf13e603bbaa7/The-Formation-of-Smart-Contracts-and-Beyond-Shaking-the-Fundamentals-of-Contract-Law.pdf;;;https://scholar.google.com/scholar?start=940&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094656-1147;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;How New Business Models Can Address Human Rights Risks in the Cobalt Supply Chain;S Cremer ; Available at SSRN 3679885, 2019  papers.ssrn.com;;"… 4 'Ford Motor Company, Huayou Cobalt, IBM, LG Chem and RCS Global Launch Blockchain

Pilot to Address Concerns in Strategic Mineral Supply Chains', IBM News Room, 16 January

2019, https://newsroom.ibm.com/2019-01-16-Ford-Motor-Company-Huayou-Cobalt-IBM-LG …";Cité 2 fois;;[PDF] gcbhr.org;https://gcbhr.org/backoffice/resources/ssrn-id3679885.pdf;"
1 

How New Business Models Can Address Human Rights Risks in 
the Cobalt Supply Chain 
 

DorothĂŠe Baumann-Pauly & Serra Cremer Iyi 

 

 

Introduction 
 

In July 2019, 43 miners were killed in a landslide in a cobalt mine in southeastern 

Katanga Province of the Democratic Republic of the Congo (DRC). A subsidiary 

of Switzerland-based commodity trading and mining company Glencore operated 

the mine. The accident occurred in a concession designated exclusively for 

industrial mining. 1  Investigations of the Glencore accident revealed that the 

miners who died were not authorized to enter the concession but were among the 

estimated 2,000 artisanal miners who trespass on the concession on a daily basis 

to extract high-value metals with basic means.2  

 

The accident showed that unauthorized, informal mining is a business reality in 

the DRC, which has about half of the world’s cobalt reserves.3 Cobalt is vital for 

making rechargeable batteries, and its consumption is expected to multiply 

eightfold by 2026 and 14 times its current levels in the next decade.4 With no 

alternatives to the DRC’s production capacity, companies that manufacture 

batteries are dependent on Congolese cobalt.  

 

                                                
1 ‘Dozens killed in DRC Glencore copper mine accident’, The Guardian, (27 June 2019), 
2 Ibid.  
3 Thomas R. Yager, ‘The Mineral Industry of Congo (Kinshasa)’, (US Geological Survey (USGS), 2015). 
4 ‘Ford Motor Company, Huayou Cobalt, IBM, LG Chem and RCS Global Launch Blockchain Pilot to Address 
Concerns in Strategic Mineral Supply Chains’, IBM News Room, 16 January 2019, 
https://newsroom.ibm.com/2019-01-16-Ford-Motor-Company-Huayou-Cobalt-IBM-LG-Chem-and-RCS-
Global-Launch-Blockchain-Pilot-to-Address-Concerns-in-Strategic-Mineral-Supply-Chains (accessed 8 
August 2019); World Economic Forum, ‘Global Battery Alliance Value Chain Roadmap’, (5 August 2019). 

Electronic copy available at: https://ssrn.com/abstract=3679885



2 

The so-called artisanal small-scale mining (ASM), a term that refers to mining 

without heavy machinery, accounts for 20% to 30% of the country’s total cobalt 

production.5 ASM is common in the DRC, as mining provides the only livelihood 

other than farming for many communities. While there are several conflicting 

estimates as to the total number of artisanal miners in the country, the DRC 

Chamber of Mines and the International Institute for Sustainable Development 

estimate that in 2015 about 2 million Congolese were involved in ASM, while the 

global union IndustriALL puts the number at more than 12 million.6 Amnesty 

International estimates that there are 200,000 artisanal miners in the cobalt-rich 

Katanga region, with around 1.2 million people dependent on income from this 

activity.7 In 2012, UNICEF reported that there were 40,000 children working in 

artisanal mines in southern Katanga, while the U.S. Department of State reported 

in 2019 that 40% of Katanga’s miners were children who worked under the same 

dangerous conditions as adults.8 The U.S. Department of Labor 2017 findings on 

the Worst Forms of Child Labor stated that 36% of Congolese children between 

the ages of 5 and 14 were employed, often in mining activities.9 Due to the 

seasonal and price-sensitive nature of ASM, and the lack of oversight at ASM 

sites, it is very difficult to ascertain the exact number of artisanal miners and child 

workers and therefore the true extent of ASM-related human rights issues in the 

DRC.  
                                                
5  RCS Global, ‘The Emerging Cobalt Challenge’, (October 2016), https://www.rcsglobal.com/wp-
content/uploads/rcs/pdfs/RCS-Global-The-Emerging-Cobalt-Challenge.pdf (accessed 30 July 2019); ‘DRC: 
Miners on hold while government stalls’, The Africa Report, (2 August 2019) 
https://www.theafricareport.com/15892/drc-miners-on-hold-while-government-stalls/ (accessed 6 August 
2019).  
6 Chambre des Mines, Federation des Entreprises du Congo, ‘2015 DRC Mining Industry Annual Report’, 
(February 2016); Intergovernmental Forum on Mining, Minerals, Metals and Sustainable Development (IGF), 
‘Global Trends in Artisanal and Small-Scale Mining (ASM): A review of key numbers and issues’, (Winnipeg: 
IISD, 2017); ‘Calls for sustainable mining after 43 artisanal miners killed in DRC landslide’, IndstriALL, 4 July 
2019, http://www.industriall-union.org/calls-for-sustainable-mining-after-43-artisanal-miners-killed-in-drc-
landslide (accessed 7 August 2019). 
7 Amnesty International, ‘This is What We Die For: Human Rights Abuses in the Democratic Republic of 
Congo Power the Global Trade in Cobalt’, (London, 2016). 
8 UNICEF, ‘In DR Congo, UNICEF supports efforts to help child labourers return to school’, 13 June 2012, 
https://www.unicef.org/childsurvival/drcongo_62627.html (accessed 13 August 2019); US Department of 
State, ‘2018 Country Reports on Human Rights Practices: Democratic Republic of the Congo’, 13 March 
2019. 
9	
  U.S. Department of Labor, Bureau of International Labor Affairs, Child Labor and Forced Labor Reports, 
‘2017 Findings on the Worst Forms of Child Labor’, https://www.dol.gov/agencies/ilab/resources/reports/child-
labor/congo-democratic-republic-drc (accessed 19 August 2019).	
  

Electronic copy available at: https://ssrn.com/abstract=3679885



3 

 

What is evident is that working in the Congolese mining sector is dangerous, with 

particularly high risks related to legal yet largely unregulated ASM. Although the 

country’s newly amended Mining Code sets age and area limitations for ASM and 

requires miners to obtain an artisanal miner card,10 human rights issues have 

been documented in many artisanal mines in the country, including child labor, 

serious health and safety risks, and fatal accidents.11 Considering the projected 

rise in cobalt demand, finding collective and permanent solutions to human rights 

issues in ASM is a timely and urgent quest.  

 

Companies sourcing from the DRC are under increasing pressure to address 

these human rights challenges. Media reports have been highlighting the role of 

consumer-facing brands in the cobalt supply chain. Apple, for example, 

designated cobalt as a ‘conflict mineral’ in 2014 and requires its suppliers to 

adhere to stringent audit requirements. It completed its cobalt supply chain 

mapping in 2016 and publishes an annual supplier responsibility report, which 

includes a list of refiners and smelters from which Apple sources its cobalt. Since 

2016, Apple has achieved 100% participation by its cobalt suppliers in Apple’s 

independent third-party audits, which verify the accuracy of data provided by 

suppliers.12 It has removed two of its cobalt suppliers from its supply chain in 

2018. Apple also collaborates with the OECD, several NGOs, and trade chambers 

on various programs to address the social and environmental risks associated 

with obtaining cobalt from the DRC.13 Similarly, a multi-industry consortium that 

                                                
10 The Revised Mining Code of the DRC, art. 26, 27, 109, ‘Loi n°18/001 du 09 mars 2018 modifiant et 
complétant la Loi n° 007/2002 du 11 juillet 2002 portant Code minier’, Journal Officiel de la République 
DĂŠmocratique du Congo, 28 March 2018.  
11 “Between September 2014 and December 2015 alone, the DRC’s UN-run radio station, Radio Okapi, 
carried reports of fatal accidents involving more than 80 artisanal miners in the former province of Katanga.”  
‘This is What We Die For’, note 6, page 6, 28-33. See Annex 2 for a list of mining accidents that took place in 
the DRC between 2014 and 2019.  
12 	
  Apple, ‘Supplier responsibility 2019 Progress Report’, https://www.apple.com/supplier-
responsibility/pdf/Apple_SR_2019_Progress_Report.pdf (accessed 19 August 2019). 
13  Apple, ‘Supplier responsibility 2018 Progress Report’, https://www.apple.com/supplier-
responsibility/pdf/Apple_SR_2018_Progress_Report.pdf (accessed 7 August 2019); Apple, ‘Smelter and 
Refiner List 2018’, https://www.apple.com/supplier-responsibility/pdf/Apple-Smelter-and-Refiner-List.pdf 
(accessed 8 August 2019).  

Electronic copy available at: https://ssrn.com/abstract=3679885



4 

consists of BASF, BMW, and Samsung in partnership with the German 

development agency GIZ, launched a pilot project in late 2018 to identify and 

address systematic problems at artisanal mines.14 A third example of a project 

that seeks to ameliorate human rights abuses in cobalt mining is the blockchain 

project introduced by a consortium that consists of Ford, IBM, Huayou Cobalt, LG 

Chem, and RCS Global. This pilot seeks to increase transparency in ASM by 

creating an audit trail from mine to manufacturer, which will enable mine operators 

to sell their responsibly sourced and validated raw materials in the global 

market.15  

 

Our paper analyzes the business solutions that Western companies are currently 

exploring to formalize ASM. Addressing human rights issues in ASM requires 

companies to reorganize core business processes in a way that systematically 

integrates respect for human rights in all supply chain links upstream. In our initial 

case study we are focusing on a Swiss commodity trading company that is driving 

an innovative project to regulate ASM at a mining site at Kolwezi, in Katanga, 

DRC. We see this case study as a preliminary research phase into a comparative 

project of business models of companies sourcing precious metals from the DRC. 

The goal is to distill the business factors that have a systemic positive impact on 

the workers and communities involved in ASM.  

 

This paper is structured in four parts. The current draft outlines the research focus 

of this project but it does not yet provide empirical insights. These will be added 

after a field trip to the DRC in September 2019. In the first part of the paper, we 

provide data to underpin the relevance of the DRC for the global cobalt supply 

chain. We also highlight the role of ASM in this supply chain and the impact that 

cobalt price fluctuations have on ASM. In the second part, we outline the pilot 

project that the commodity firm Trafigura has set up at the Mutoshi mine in the 
                                                
14 ‘BMW, BASF and Samsung launch a project for sustainable cobalt mining’, Deutsche Gesellschaft für 
Internationale Zusammenarbeit (GIZ) GmbH, 29 November 2018, https://www.giz.de/en/press/72347.html 
(accessed 7 August 2019).  
15 ‘Blockchain Pilot’, note 4.  

Electronic copy available at: https://ssrn.com/abstract=3679885



5 

DRC to control for the human rights risks related to ASM. The case is considered 

as a model example for formalizing ASM. We describe our research plans to 

assess this project in the field in order to identify the business factors that need to 

be in place for such a project to be scalable and replicable by other companies, 

including companies in other sectors. The third part outlines other companies’ 

projects that attempt to control for human rights risks related to ASM. We hope to 

eventually to study them in greater detail in a comparative setting. Finally, in part 

four, we look at the specific role that commodity-trading companies play in the 

cobalt supply chain and the current drivers for the described pilot projects. We will 

also consider how multi-stakeholder initiatives in this industry can facilitate the 

development of standards for responsible ASM. 

 

 

Part I - The Cobalt Supply Chain and ASM’s Swing Capacity in the DRC 
 

Cobalt is an essential component of the lithium-ion batteries that power our 

phones, laptops, and other portable consumer electronics. The biggest demand 

for battery metals, however, comes from a growing global interest in switching 

from petrol and diesel to electric vehicles that can help reduce air pollution and 

meet climate change targets. Some projections forecast that in 20 years, one-third 

of cars will be electric and more than 140 million electric vehicles will hit the road 

by 2030, requiring 260,000 tons of cobalt per year, almost double the global 

production in 2018.16 

 

Governments are key drivers for this transition to so-called green energy. India, 

for example, plans to replace 30% of all vehicles in the country with electric 

                                                
16 ‘The Top Miners Are Split on How to Chase the EV Battery Boom’, Bloomberg, (5 August 2019), 
https://www.bloomberg.com/news/articles/2019-08-05/the-top-miners-are-split-on-how-to-chase-the-ev-
battery-boom (accessed 5 August 2019). See Annex 1 for a list of countries contributing to the global mined 
cobalt production in 2018. 

Electronic copy available at: https://ssrn.com/abstract=3679885



6 

models by 2030.17 China also created incentive systems for manufacturers and 

subsidies for consumers to use electric vehicles.18 In 2010, the U.S. federal 

government introduced a tax credit for plug-in electric vehicle purchases,19 while 

California has set an official target of reaching 5 million zero-emission electric 

vehicles on its roads by 2030.20  In Europe, the UK announced in July 2017 it 

would phase out sales of new petrol- and diesel-run cars by 2040.21 The EU has 

already tightened its limits for carbon dioxide to incentivize the use of electric 

vehicles.22 

 

Currently, 64% of the global mined cobalt is produced in the DRC, mainly as a by-

product of copper mining.23 Other cobalt-exporting countries are Russia, Cuba, 

Canada, Australia, the Philippines, and Madagascar, but none of these other 

nations contributes as much as 5% of the global cobalt production.24  

 

The projected green revolution thus depends on the DRC, a country of 84 million 

people known for poverty, armed conflict and high levels of corruption. According 

to Transparency International’s corruption index, the DRC is 161st out of 180 

countries in the world. The UN Human Development Index ranks the DRC 176th 

out of 189 countries, and the UNDP estimates that 90.5% of those employed 

                                                
17  ‘India Races Forward in Electric Cars’, Bloomberg, (21 December 2018) 
https://www.bloomberg.com/opinion/articles/2018-12-22/india-gets-policies-on-electric-car-infrastructure-right 
(accessed 5 August 2019). 
18 Jack Perkowski, ‘What China's Shifting Subsidies Could Mean For Its Electric Vehicle Industry’, Forbes, 
(13 July 2018), https://www.forbes.com/sites/jackperkowski/2018/07/13/china-shifts-subsidies-for-electric-
vehicles/#63b71c155703 (accessed 5 August 2019).  
19	
  Office of Energy Efficiency & Renewable Energy, ‘Electric Vehicles: Tax Credits and Other Incentives’, 
https://www.energy.gov/eere/electricvehicles/electric-vehicles-tax-credits-and-other-incentives (accessed 19 
August 2019).	
  
20 California Public Utilities Commission, ‘Zero-Emission Vehicles’, https://www.cpuc.ca.gov/zev/ (accessed 5 
August 2019). 
21 ‘New diesel and petrol vehicles to be banned from 2040 in UK’, BBC, https://www.bbc.com/news/uk-
40723581 (accessed 5 August 2019). 
22 ‘Carmakers Get a Road Map for Tougher EU Limits on Carbon Dioxide’, Bloomberg, (17 December 2018), 
https://www.bloomberg.com/news/articles/2018-12-17/carmakers-get-road-map-for-tougher-eu-limits-on-
carbon-dioxide (accessed 7 August 2019).  
23  ‘Congo, child labour and your electric car’, Financial Times, (7 July 2019), 
https://www.ft.com/content/c6909812-9ce4-11e9-9c06-a4640c9feebb (accessed 5 August 2019). 
24  US Geological Survey, National Minerals Information Center, ‘Cobalt Statistics and Information’, 
https://www.usgs.gov/centers/nmic/cobalt-statistics-and-information (accessed 7 August 2019). See Annex 1 
below for exact figures and share of production.  

Electronic copy available at: https://ssrn.com/abstract=3679885



7 

make less than $3.10 per day.25 In February 2019, the DRC made headlines 

when militia groups attacked international aid stations established to fight an 

Ebola outbreak in the Northern provinces.26 Health workers were forced to close 

these facilities, exacerbating the deadly epidemic.27   

 

Clearly there is a governance gap in the enforcement of the Congolese Mining 

Code, which by its terms would ensure health and safety standards in all mining 

activities. Given the poverty levels in the DRC, companies sourcing from this 

country need to acknowledge that ASM is one of the very few options Congolese 

have for earning a livelihood and hence a business reality in the cobalt supply 

chain.   

It’s worth noting that the DRC is not the only country where ASM is a common 

practice in the extractive sector. Worldwide, ASM produces approximately 80% of 

all sapphires, 25% of all tin, 20% of all gold, and up to 20% of all diamonds. ASM 

provides an income to estimated 100 million people globally.28 Understanding how 

businesses can help to mitigate human rights risks related to ASM in the DRC can 

thus serve as a model to develop standards for ASM generally that also apply to 

other commodities and countries. 

 

The number of people involved in ASM in the DRC and global cobalt prices are 

closely connected because of the “swing capacity” of the activity. This term refers 

to local communities switching back and forth between farming and mining, 

                                                
25  UNDP, Human Development Reports, ‘Table 1. Human Development Index and its components’, 
http://hdr.undp.org/en/composite/HDI (accessed 7 August 2019) and ‘Congo: Human Development 
Indicators’, http://hdr.undp.org/en/countries/profiles/COD (accessed 7 August 2019).  
26 ‘‘Crippling’ Attacks Force Doctors Without Borders to Close Ebola Centers in Congo’, The New York 
Times, 28 February 2019, https://www.nytimes.com/2019/02/28/world/africa/congo-ebola-doctors-without-
borders.html (accessed 7 August 2019). 
27 ‘How do you reform a country where gunmen torch Ebola clinics?’, The Economist, 3 August 2019, 
https://www.economist.com/middle-east-and-africa/2019/08/03/how-do-you-reform-a-country-where-gunmen-
torch-ebola-clinics (accessed 7 August 2019).  
28  ‘What is Artisanal & Small-Scale Mining (ASM)?’, Fair Congo Foundation, (23 August 2017), 
http://faircongo.com/2017/08/23/artisanal-small-scale-mining-asm/ (accessed 8 August 2019). 

Electronic copy available at: https://ssrn.com/abstract=3679885



8 

depending on which activity produces more income at a given moment.29 The 

price of cobalt has fluctuated significantly over the past decade. The number of 

artisanal miners increases with rising cobalt prices and declines with falling prices, 

as witnessed in the period between 2010 and 2016, when ASM cobalt production 

was low due to depressed prices. This activity picked up quickly when prices rose 

dramatically in 2017 and early 2018.30 

 

Despite forecasts of an increase in demand for battery metals, the price of cobalt 

is currently very low. After quadrupling from $22,000/metric ton in February 2016 

to $95,000/metric ton in March 2018, the price of cobalt decreased by 52.7% 

since the beginning of 2019, and the current price is roughly $28,000/metric ton.31 

This sharp decline in the second half of 2018 was caused by a surge in cobalt 

supply from the DRC, especially from artisanal miners who reacted swiftly to 

increasing prices in late 2016 and 2017 and entered the supply chain.32 It is 

estimated that ASM cobalt production in the DRC jumped from 6,500 tons in 2016 

to 24,000 tons in 2018,33 which was higher than the combined cobalt production 

of Russia, Cuba, Australia, the Philippines, and Canada in 2018, making the 

Congolese swing artisanal supply the second largest source of cobalt globally, 

after industrial mining in the DRC that year.34 With the ongoing reduction in cobalt 

prices this year, seasonal artisanal miners are not expected to return to cobalt 

mines and it is estimated that ASM cobalt production has fallen 70% from last 

year, to well below 5,000 tons.35  

 

                                                
29  Andy Home, ‘Why the cobalt market needs Congo’s ‘illegal’ miners’, Reuters, (12 July 2019), 
https://www.reuters.com/article/us-congo-cobalt-ahome/why-the-cobalt-market-needs-congos-illegal-miners-
andy-home-idUSKCN1U71VS (accessed 8 August 2019).  
30 Ibid.  
31 London Metal Exchange, ‘LME Cobalt, Historical Prices Graph’, https://www.lme.com/en-GB/Metals/Minor-
metals/Cobalt#tabIndex=2 (accessed 8 August 2019). 
32 ‘Plummeting cobalt prices takes toll on Democratic Republic of Congo’, Financial Times, 23 June 2019, 
https://www.ft.com/content/3317dc52-933a-11e9-aea1-2b1d33ac3271 (accessed 8 August 2019).  
33 Roskill, ‘Cobalt: Dramatic Price Fall Comes To An End’, (15 April 2019), https://roskill.com/news/cobalt-
dramatic-price-fall-comes-to-an-end/ (accessed 8 August 2019). 
34 See Table 1 below for exact production figures and share of production of each country. 
35 ‘Plummeting cobalt prices’, note 28.  

Electronic copy available at: https://ssrn.com/abstract=3679885



9 

This price decline was further exacerbated by stockpiling, particularly by Chinese 

buyers who play a pivotal role in the global cobalt market. While China accounts 

for only 1% of cobalt mine production, it is the world’s leading cobalt refiner and 

consumer, producing 50% of the world’s refined cobalt.36 In order to produce at 

this level, China sources 70% of its mined cobalt from the DRC.37 Roughly 80% of 

the mineral-processing plants in Katanga are operated by Chinese companies, 

and almost all of their output is exported to China for production of electronic 

devices and vehicles.38  

 

This close and volatile export relationship between the DRC and China renders 

the Congolese economy vulnerable to changes in Chinese buying behavior, often 

directed by government policies such as the 2000 “Going Out Strategy,” which 

incentivized Chinese companies to expand overseas for mineral resources. As a 

result of this policy, the Chinese government is able to stockpile natural resources 

it does not produce domestically, such as cobalt, at the Chinese State Reserve 

Bureau and reduces the country’s supply risks and dependency on global 

markets.39 As a consequence, a collective decision by Chinese buyers in the DRC 

to stockpile cobalt put a strain on the Congolese economy, which heavily depends 

on exports. In 2017, cobalt accounted for 42.9% of the DRC’s total exports; China 

is the destination for 45% of all Congolese exports.40  

 

According to Citibank’s cobalt price forecasts, the market will remain in surplus 

until 2022, following which supply growth is expected to slow and the projected 

increases in cobalt demand to kick in.41 Cobalt Investing News’ 2019 mid-year 

                                                
36 Gulley, McCullough, Shedd, ‘China’s domestic and foreign influence in the global cobalt supply chain’, 
(2019) Resources Policy 62, 317-323, p.320 
37 The Centre for Research on Multinational Corporations (SOMO) and PremiCongo, ‘“Go ahead, try to 
accuse us…”: Human rights violations by Chinese mining companies in the Democratic Republic of Congo’, 
(Lubumbashi, November 2018).   
38 KPMG Global Mining Institute, ‘Democratic Republic of Congo: Country mining guide’, (2014). 
39 ‘China’s domestic and foreign influence’, note 31, p.318. 
40  The Observatory of Economic Complexity, ‘Democratic Republic of the Congo’, 
https://oec.world/en/profile/country/cod/ (accessed 8 August 2019).  
41 Citi, ‘Cobalt 2019-2025 Outlook’, (4 December 2018). 

Electronic copy available at: https://ssrn.com/abstract=3679885



10 

cobalt market update estimated that excess supplies would continue for the next 

12 to 18 months.42 Most recently, Glencore announced its decision to close the 

world’s largest cobalt mine, the Mutanda mine in Katanga, which will reduce by 

about 20% of the global cobalt supply, foreshadowing a likely rise in cobalt prices.  

 

In light of these projections, the timing of our research project is critical. 

Developing business models that can effectively address the human rights risks 

involved in ASM should be an urgent priority before local farmers swing back to 

ASM. Trafigura’s Mutoshi project in Katanga is one example of a business model 

that seeks to formalize ASM as a way of sourcing cobalt responsibly. 

 

 

Part II – The Mutoshi ASM Pilot Project  
 

Trafigura Group Pte. Ltd., a Swiss-based commodity trading firm, runs a pilot 

ASM project at the Mutoshi mine, a copper and cobalt mining site at Kolwezi in 

Katanga. Kolwezi has 450,000 inhabitants and is a four-hour drive from 

Lubumbashi, the second-largest city in the DRC. 

 

The Mutoshi mine is operated by Chemaf SPRL (Chemaf), a local mining 

company headquartered in Lubumbashi, which is a subsidiary of Dubai-based 

Shalina Resources Ltd. Last year, the total production at Mutoshi accounted for 

5% of the global mined cobalt supply, all of which is purchased by Chemaf and 

then sold to Trafigura under an off-take agreement executed in 2018.43 Trafigura 

has agreed to purchase all cobalt sourced at Mutoshi for three years, until the end 

of 2020.   

 

                                                
42  'Cobalt Market Update: Q2 2019 in Review’, Cobalt Investing News, (17 July 2019), 
https://investingnews.com/daily/resource-investing/battery-metals-investing/cobalt-investing/cobalt-market-
update/ (accessed 8 August 2019). 
43  ‘Trafigura accelerates battery push with Congo cobalt deal’, Financial Times, (4 April 2018), 
https://www.ft.com/content/0d7fab08-3816-11e8-8b98-2f31af407cc8 (accessed 13 August 2019). 

Electronic copy available at: https://ssrn.com/abstract=3679885



11 

To develop the Mutoshi mine, Trafigura also entered into a marketing agreement 

with Chemaf for the pilot project that aims to mitigate the social and environmental 

risks of ASM.44 The extraction and processing activities at Mutoshi are carried out 

by Comiakol, a local cooperative representing more than 5,000 artisanal miners.45 

The appointment of a single authorized labor contractor enables the proper 

identification and training of each miner, standardization of working conditions, 

and uniformity in mining operations. These steps are supposed to minimize the 

risk of illegal entries, accidents, and human rights violations. Trafigura also 

engaged PACT, a U.S.-based non-profit organization with operations in the DRC, 

to ensure the implementation of responsible sourcing policies. PACT also 

provides training to artisanal miners on workplace safety and to local communities 

on eradicating child labor.46   

 

The mining conditions at Mutoshi differ significantly from the unmonitored, 

unfenced mining concessions in Katanga. In place of shafts and tunnels	
   that 

miners dig by	
  hand	
  with primitive tools,	
  small teams of artisanal miners in Mutoshi 

enter shallow pits of 10 square meters each, which are prepared in advance by 

heavy machinery, and dig only in a straight vertical line, maximum 10 meters deep 

and no horizontal tunnels.47 According to Trafigura, this method of extraction 

increases the productivity and thus the income of each miner while ensuring that 

safety controls are in place. In stark contrast to the pictures of barefoot, miners 

working with their bare hands and trespassing on industrial mining zones, the 

project requires miners at Mutoshi to enter the site from a single entry point, 

present their artisanal miners’ card (as required by the Congolese Mining Code) to 

verify identity and wear protective equipment: boots, gloves, blue uniforms, and 

yellow helmets.48 There are also limitations on the age and number of miners that 

can be present on the site at one time. Mutoshi standards prohibit children and 
                                                
44  ‘Responsible Sourcing: The Chemaf Case Study’, Trafigura, 
https://www.trafigura.com/responsibility/responsible-sourcing/ (accessed 9 August 2019) 
45 Comiakol, http://comiakol.org/ (accessed 13 August 2019). 
46 ‘Chemaf Case Study’, note 41 
47 Ibid.   
48 Ibid. 

Electronic copy available at: https://ssrn.com/abstract=3679885



12 

pregnant women from entering the premises. Trafigura reports that security at the 

concession is provided by the armed DRC mining police and an unarmed third-

party private security company.49  

 

Following extraction and washing, cobalt is brought to Chemaf’s buying station 

outside of Mutoshi and analyzed in labs. The pilot project requires that a separate 

and detailed log of cobalt from Mutoshi be kept to ensure that each mining group 

working in a specific pit is paid according to the purity and volume of its 

production.50All of the cobalt production from Mutoshi is purchased by Chemaf 

and payments are made to Comiakol representatives, not to the workers directly. 

Chemaf is prohibited from selling its production outside of Mutoshi or to other 

buyers. The project requires cobalt from Mutoshi to be kept separate from 

industrially mined cobalt and is processed in a different facility dedicated to ASM 

production.51  

 

At the end of the first six months of the Mutoshi ASM pilot project, Trafigura 

reported that there had been no instances of child labor or gross human rights 

abuses associated with ASM, although smaller accidents remain common.52 The 

company believes that this innovative multi-stakeholder project will serve as best 

practice for other players in Katanga, illustrating how companies in the mining 

industry can integrate human rights responsibilities into their policies and help 

formalize ASM, thereby transforming artisanal miners’ working and living 

conditions.  

 

Our research project will serve as the first case study in a series of case studies 

examining innovative business models to formalize ASM. Research into the 

Mutoshi project so far has been conducted exclusively through sources not 

independent from Trafigura. Our aim is to provide an independent and 360-degree 
                                                
49 Ibid. 
50 Ibid. 
51 Ibid. 
52 Ibid. 

Electronic copy available at: https://ssrn.com/abstract=3679885



13 

assessment of the project’s scalability. To accomplish this, we will have to 

understand the business factors that companies need to have in place to 

implement responsible sourcing policies. We plan to conduct on-site interviews 

with key representatives of the businesses involved in the cobalt supply chain in 

the DRC. This will include carrying out in-depth conversations with the Trafigura 

project lead at its headquarters in Geneva, international and local PACT staff, 

Chemaf senior management in Lubumbashi and Kolwezi, Comiakol 

representatives at Mutoshi, government agents from the state regulator of 

artisanal mining, SAEMAPE53, officials from mining companies that exclude ASM 

from their supply chains, and consultancy firms that advise various multinational 

auto and electronics companies sourcing from the DRC. In addition, we hope to 

consult other key implementers in the region, such as Impact or GIZ and local 

NGOs to achieve a balanced overview of the contribution of the Mutoshi project 

towards the improvement of socioeconomic conditions in mining communities as 

well as the challenges linked with the project.  

 

 

Part III – Other Projects to Formalize ASM 
 

Trafigura is not the only company that has set up a project to address the human 

rights risks involved in ASM in the DRC. Several companies have established 

similar pilots, yet neither the business elements of these various projects nor their 

impact on workers and local communities have ever been systematically 

compared.  

 

Three projects that stand out in this context are the pilots of Huayou,  

BMW and a blockchain project that involves Ford, Huayou, IBM, LG Chem, 

Volkswagen and Volvo.  

 
                                                
53  SAEMAPE stands for Service d'Assistance et d'Encadrement de l'exploitation artisanal Ă  Petit Echelle or 
in English, the Service for Assistance and Supervision of Artisanal and Small-Scale Mining.  

Electronic copy available at: http";"""date"",""2019-08-26T09:15:56Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.3""
""pdf:docinfo:title"",""Microsoft Word - Essex Conference Paper - Aug 21.docx""
""xmp:CreatorTool"",""Word""
""Keywords"",""""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""dcterms:created"",""2019-08-26T09:15:56Z""
""language"",""en""
""Last-Modified"",""2019-08-26T09:15:56Z""
""dcterms:modified"",""2019-08-26T09:15:56Z""
""dc:format"",""application/pdf; version=1.3""
""title"",""Microsoft Word - Essex Conference Paper - Aug 21.docx""
""Last-Save-Date"",""2019-08-26T09:15:56Z""
""pdf:docinfo:creator_tool"",""Word""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2019-08-26T09:15:56Z""
""meta:save-date"",""2019-08-26T09:15:56Z""
""pdf:encrypted"",""false""
""dc:title"",""Microsoft Word - Essex Conference Paper - Aug 21.docx""
""modified"",""2019-08-26T09:15:56Z""
""Content-Length"",""402602""
""pdf:hasMarkedContent"",""false""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""dc:subject"",""""
""meta:creation-date"",""2019-08-26T09:15:56Z""
""created"",""2019-08-26T09:15:56Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""25""
""Creation-Date"",""2019-08-26T09:15:56Z""
""resourceName"",""ssrn-id3679885.pdf""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""1952"",""3307"",""2828"",""2343"",""2129"",""3012"",""2497"",""2619"",""2533"",""2038"",""2413"",""1952"",""1982"",""2290"",""2300"",""2656"",""2455"",""2014"",""2518"",""2466"",""325"",""522"",""1513"",""1805"",""425""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""meta:keyword"",""""
""producer"",""Mac OS X 10.10.5 Quartz PDFContext""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""Mac OS X 10.10.5 Quartz PDFContext""
""pdf:docinfo:created"",""2019-08-26T09:15:56Z""
";https://scholar.google.com/scholar?start=960&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094656-1143;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Balancing Privacy and Accountability for Industrial Mortgage Management;L Xue, D Liu, J Ni, X Lin, XS Shen ; IEEE Transactions on …, 2019  ieeexplore.ieee.org;;"… and add the identity and the proof of the misbehavior to the mortgage blacklist maintained by

the blockchain … The adversary can make queries to oracles that are defined in the games … pkb,

pkT ) to A. Query: A can make a polynomial number of queries to the Register oracle …";Cité 2 fois;Les 2 versions;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/9424/4389054/08894387.pdf?casa_token=nAQXBReKJaAAAAAA:Kttg8bacEG51Ji5IygZuVZhC1hxlrYuK8TSF4tajdi28VJd67qg1SIqwIQe-eHl3qrVdk46MQBY;"
		Skip to Main Content


		
			
				
				

				

			

		


		
			
				
					
						








	
		
	

	







						

						





























	
	
		
	
	
		
			

		
	

	
	
	



						





	
	
		
			
				IEEE Account

					Change Username/Password
	Update Address


			

			
				Purchase Details

					Payment Options
	Order History
	View Purchased Documents


			

			
				Profile Information

					Communications Preferences
	Profession and Education
	Technical Interests


			

			
				Need Help?

					US & Canada: +1 800 678 4333
	Worldwide:  +1 732 981 0060

					
	Contact & Support


			

		

		
			
				
					
							About IEEE Xplore
	Contact Us
	Help
	Accessibility
	Terms of Use
	Nondiscrimination Policy
	Sitemap
	Privacy & Opting Out of Cookies


						
							A not-for-profit organization, IEEE is the world's largest technical professional organization dedicated to advancing technology for the benefit of humanity.
Š Copyright 2021 IEEE - All rights reserved. Use of this web site signifies your agreement to the terms and conditions.
						

					


					

				

				
			

		

	


	
	


						
						






		
		
		
		
		
		
		
		
		
		
		
		
		
			
				
			
			
			
			
		
		
		
		
		
		

			


			

			
			


		
 		
		
			 

						
						









































	

		
		

		
		
		

		
			
		
		
		

		

		
		


		

		
		
		
		
		
		
		
		
		
		
	
	


















		
		
			
				
					
					
								
					
								
			
				
					
					
								
					
								
			
				
					
						








 



					
					
								
			
				
					
					
								
			
				
					
					
								
					
								
			
				
					
					
								
					
								
			
				
					
					
								
					
								
			
				
					
					
								
					
								
			
				
					
					
								
					
								
			
				
					
					
								
					
								
			
		
	




























		
			
					
			
					
			
					
			
				
					








					
			
					
			
					
			
					
			
					
			
					
			
					
			
		
		
	





	
	
	
	
	
	
	


	
	
	

	

















					

				

			


			
				
			
		

	";"""og:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""twitter:title"",""Balancing Privacy and Accountability for Industrial Mortgage Management""
""twitter:card"",""summary""
""Description"",""Industrial mortgage enables companies to acquire loan for business venture or investment purposes by pledging their industrial assets to financial institutions.""
""og:title"",""Balancing Privacy and Accountability for Industrial Mortgage Management""
""resourceName"",""08894387.pdf""
""language"",""en""
""title"",""Balancing Privacy and Accountability for Industrial Mortgage Management | IEEE Journals & Magazine | IEEE Xplore""
""og:description"",""Industrial mortgage enables companies to acquire loan for business venture or investment purposes by pledging their industrial assets to financial institutions. To prevent double-mortgage fraud of borrowers, information exchange among different financial institutions is necessary. On the other hand, it results in the privacy leakage of borrowers. In this article, we construct a blockchain-based accountable and privacy-preserving industrial mortgage scheme (BAPIM). BAPIM enables financial institutions to share the mortgage data of borrowers in an efficient and secure manner, that achieves the borrower identity privacy and accountability at the same time. Specifically, borrower identity is concealed on the blockchain by anonymous identity credential, while financial institutions can still uncover the identity of a misbehaving borrower if he pledges the same asset for multiple mortgages. We demonstrate that BAPIM achieves the desirable security properties and has high computational efficiency, so as to be suitable for the industrial mortgage management.""
""twitter:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-UA-Compatible"",""IE=Edge""
""viewport"",""width=device-width, initial-scale=1.0""
""dc:title"",""Balancing Privacy and Accountability for Industrial Mortgage Management | IEEE Journals & Magazine | IEEE Xplore""
""twitter:description"",""Industrial mortgage enables companies to acquire loan for business venture or investment purposes by pledging their industrial assets to financial institutions. To prevent double-mortgage fraud of borrowers, information exchange among different financial institutions is necessary. On the other hand, it results in the privacy leakage of borrowers. In this article, we construct a blockchain-based accountable and privacy-preserving industrial mortgage scheme (BAPIM). BAPIM enables financial institutions to share the mortgage data of borrowers in an efficient and secure manner, that achieves the borrower identity privacy and accountability at the same time. Specifically, borrower identity is concealed on the blockchain by anonymous identity credential, while financial institutions can still uncover the identity of a misbehaving borrower if he pledges the same asset for multiple mortgages. We demonstrate that BAPIM achieves the desirable security properties and has high computational efficiency, so as to be suitable for the industrial mortgage management.""
""Content-Encoding"",""UTF-8""
""Content-Type-Hint"",""text/html; charset=utf-8""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=960&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094668-1189;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[CITATION][C] 10 Regulating Smart Contracts and Digital Platforms;J Wang, L Chen;;;null;;null;null;;;;https://scholar.google.com/scholar?start=410&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094668-1190;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Who is Causally Responsible for a Cryptocurrency?;P Řstbye ; Available at SSRN 3339537, 2019  papers.ssrn.com;;"… (2017) for a survey of possible attacks on the Bitcoin blockchain … For many cryptocurrencies,

interacting with the outside world is necessary; the cryptocurrency op- erations need … Such

information can be provided by oracles, and the information provided by oracles must be …";Autres articles;;null;;;;https://scholar.google.com/scholar?start=410&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094555-713;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Blockchain-basiertes Fundraising als innovative Alternative der Unternehmensfinanzierung;K Himmer ; Springer Books, 2019  Springer;;"Page 1. Klaus Himmer Blockchain-basiertes Fundraising als innovative Alternative der

Unternehmensfinanzierung Eine steuer- und … Unternehmensfinanzierung Page 3. Klaus Himmer

Blockchain-basiertes Fundraising als innovative Alternative der Unternehmensfinanzierung …";Cité 2 fois;Les 6 versions;null;;;;https://scholar.google.com/scholar?start=530&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094548-681;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Nutzenpotenziale der Blockchain-Technologie für die Assekuranz;F Fuchs, M Reich ; Handbuch Versicherungsmarketing, 2019  Springer;;"… Diese dezentralisierten Datenfeed?Services sind unter dem Begriff Oracle bekannt, was auf … Eine

vernetzte Gesundheitsdatenbank auf Basis von Blockchain würde den Gesundheits?Fragekatalog

in der … müsste sich in einem solchen Modell aus verschiedenen Oracles speisen …";Cité 2 fois;Les 2 versions;null;;;;https://scholar.google.com/scholar?start=500&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094553-709;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[PDF][PDF] Risks of Blockchain for Data Protection: A European Approach;BS Jiménez;Gómez  Santa Clara High Tech. LJ, 2019  HeinOnline;;"… A Detailed Look at Cryptocurrency 's New Kid on the Block, BITCOIN MAGAZINE (Feb. 26, 2013),

https://bitcoinmagazine.com/articles/introducing- ripple. 5 Toshendra K. Sharma, Advantages

and disadvantages ofpermissionless blockchain, BLOCKCHAIN COUNCIL (Oct …";Cité 1 fois;Les 6 versions;[PDF] heinonline.org;https://heinonline.org/hol-cgi-bin/get_pdf.cgi?handle=hein.journals/sccj36&section=15&casa_token=RIaRTL8vGtQAAAAA:zNcQOrlWWfol4oR8FN-c9aVyOaC7P9Vfg7xraDA4NBZ0Gd4AVTNsr_bTp-uFsqZHKn7Npcc;"

 ";"""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""REFRESH"",""1; url=https://heinonline.org/HOL/Page?handle=hein.journals/sccj36&div=15&g_sent=1&casa_token=RIaRTL8vGtQAAAAA:zNcQOrlWWfol4oR8FN-c9aVyOaC7P9Vfg7xraDA4NBZ0Gd4AVTNsr_bTp-uFsqZHKn7Npcc""
""Content-Encoding"",""UTF-8""
""resourceName"",""get_pdf.cgi""
""language"",""""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=520&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094630-1038;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Minimizing trust in hardware wallets with two factor signatures;A Marcedone, R Pass, A Shelat ; International Conference on Financial …, 2019  Springer;;"… signatures whose low-order bits leak different bits of c, after sufficiently many transactions that

are posted on a blockchain, the adversary could … Token Oracles. In our definitions, we will often

model a party/program implementing party \(T\). We say that a Token Oracle is a stateful …";Cité 1 fois;Les 2 versions;[PDF] nsf.gov;https://par.nsf.gov/servlets/purl/10094253;"
Minimizing Trust in Hardware Wallets with Two Factor Signatures

Antonio Marcedone1, Rafael Pass∗1, and abhi shelat†2

1Cornell Tech, {marcedone,rafael}@cs.cornell.edu
2Northeastern University, abhi@neu.edu

January 2, 2019

Abstract

We introduce the notion of two-factor signatures (2FS), a generalization of a two-out-of-two threshold
signature scheme in which one of the parties is a hardware token which can store a high-entropy secret, and
the other party is a human who knows a low-entropy password. The security (unforgeability) property of
2FS requires that an external adversary corrupting either party (the token or the computer the human
is using) cannot forge a signature.

This primitive is useful in contexts like hardware cryptocurrency wallets in which a signature conveys
the authorization of a transaction. By the above security property, a hardware wallet implementing
a two-factor signature scheme is secure against attacks mounted by a malicious hardware vendor; in
contrast, all currently used wallet systems break under such an attack (and as such are not secure under
our definition).

We construct efficient provably-secure 2FS schemes which produce either Schnorr signature (assuming
the DLOG assumption), or EC-DSA signatures (assuming security of EC-DSA and the CDH assumption)
in the Random Oracle Model, and evaluate the performance of implementations of them. Our EC-DSA
based 2FS scheme can directly replace currently used hardware wallets for Bitcoin and other major
cryptocurrencies to enable security against malicious hardware vendors.

1 Introduction

Cryptocurrency hardware wallets are increasingly popular among Bitcoin and Ethereum users as they offer
seemingly stronger security guarantees over their software counterparts. A hardware wallet is typically a
small electronic device (such as a USB device with an input button) that holds the secret key(s) to one or
more cryptocurrency “accounts”. It provides a simple interface that can be used by client software on a
computer or smartphone to request a signature on a particular transaction; the wallet returns a signature to
the client if the user has authorized it by pressing the physical button1. Typically, the user also has to enter
a pin or password, either on the device itself or through the client. Some hardware wallets like the Trezor
include a screen that can be used by the user to confirm the details of the transaction before authorizing it.

Ideally, a hardware wallet runs a firmware that is smaller and simpler than the software running on a
common laptop (and thus may be less vulnerable to bugs and exploits), is built using tamper proof hardware
that makes it difficult to directly read its memory, and is designed to prevent the private keys it holds from
ever leaving the device. Thus, stealing funds from an address controlled by a hardware wallet is considered
to be harder than stealing from a software wallet installed on the user’s laptop.

∗Supported in part by NSF Award CNS-1561209, NSF Award CNS-1217821, NSF Award CNS-1704788, AFOSR Award
FA9550-15-1-0262, AFOSR Award FA9550-18-1-0267, a Microsoft Faculty Fellowship, and a Google Faculty Research Award.
†Supported in part by NSF grants 1664445 and 1646671.
1The physical button prevents malware from abusing the wallet without cooperation from the user.

1



Can we trust the hardware manufacturer? However, most hardware wallets suffer from a serious issue:
since the wallet generates and holds the secret keys for the user’s account, a compromised wallet might be
used to steal the entirety of the coins it controls. Consider, for instance, a malicious wallet manufacturer
who introduces a backdoored pseudorandom generator (to be used, for example, to generate the signing
keys) into a hardware wallet. Because of the tamperproof properties of the hardware, such a backdoor might
be extremely hard to detect and go unnoticed even to a scrupulous user, especially if it only affects a small
portion of the company’s devices (perhaps those shipped to customers who hold large coin balances). Yet,
without the need of ever communicating with the devices again, the manufacturer might suddenly steal all
the money controlled by those addresses before anyone has time to react! This is also true in the case where
the user picks a password to supplement the entropy generated by the backdoored PRG, since passwords
have limited entropy which can be bruteforced and, as we detail later, the wallet can bias the randomness
in the signatures to leak information about such password.

Even if the company producing the wallet is reputable and trusted, supply chain attacks by single
employees or powerful adversaries are still hard to rule out for customers. For example, the NSA reportedly
intercepts shipments of laptops purchased online in transit to install malware/backdoors [18]. Indeed, trust
in a wallet manufacturer, its supply chain, and the delivery chain are a serious concern.

One possible solution is to store the funds in a multi-signature account controlled by a combination of
hardware (and possibly software) wallets from different manufacturers. However, the above is inconvenient
and limiting. It may also be possible for a single supplier to corrupt multiple manufacturers of hardware
wallets.

A Formal Treatment of Hardware Wallets In this paper, we initiate a formal study of the security of
hardware wallets. As discussed above, completely relying on the token to perform key generation and signing
operations requires a strong trust assumption on the hardware manufacturer. To avoid this, we focus on a
scenario in which the user has both a single hardware token and a (low-entropy) password, and formally define
appropriate an appropriate cryptographic primitive, which we name two factor signature scheme (2FS).

Roughly speaking, a 2FS scheme can be thought of a special type of two-out-of-two threshold signature
scheme [4] but where one of the parties (the user) only has a (potentially low-entropy) password, whereas the
other party (the hardware token) can generate and store high-entropy secrets. Even defining unforgeability
properties of such 2FS schemes turns out to be a non-trivial task; we provide the first such definitions.
Our notions of unforgeability consider both malicious clients, malicious tokens, and attackers that may have
selective access to honestly implemented tokens.

As already mentioned, as far as we know, in all currently known/used schemes, unforgeability does not
hold when the hardware token can be maliciously designed, and thus no currently known schemes satisfies
even a subset of our unforgeability definitions. Our main contribution is next the design of 2FS that satisfy
them. In fact, we present a general transformation from any two-out-of-two threshold signature scheme which
satisfies some additional technical property—which we refer to as statistical Non-Signalling—into a 2FS in
the random oracle model, which produces public keys and signatures of the same form as the underlying
threshold signature scheme.

We note that it may be possible to generically modify any TS to become Non-Signalling by having
the parties perform coin-tossing to generate the randomness, and then prove in zero knowledge that they
executed the signing protocol consistently with the pre-determined (and uniform) randomness. Using such a
method, however, would result in a (polynomial-time but) practically inefficient scheme. In contrast, in the
full version of this work [13], we show how to adapt two existing threshold signature schemes to satisfy this
new technical property with very little overhead. Using our transformation, this gives secure 2FS schemes
which efficiently generate Schnorr and ECDSA signatures.

Theorem (Informal). Assuming the discrete logarithm assumption, there exists a secure 2FS scheme in the
Random Oracle model which generates Schnorr Signatures.

Theorem (Informal). Assuming the DDH assumption holds and that EC-DSA is unforgeable, there exists a
secure 2FS scheme in the Random Oracle model that generates EC-DSA signatures.

The first construction is based on the Schnorr TS signature scheme of Nicolosi et al [15], while the second
one is a slight modification of an EC-DSA threshold scheme of Lee et al. [5]. As EC-DSA signature are

2



currently used in Bitcoin, Ethereum and most other major crypto currencies, our 2FS for EC-DSA can be
directly used for hardware wallets supporting those crypto currencies. To demonstrate its practicality, we
evaluate such scheme and estimate its performance on hardware tokens that are much less powerful than the
CPUs on which we can benchmark the protocol. We confirm that running the protocol on two server-class
CPUs (Intel) requires roughly 3ms to sign a message. When one of the parties is run on a weak computer
(e.g., a Raspberry Pi 3b) and the other is run on a server, the protocol requires roughly 50ms. Our estimates
confirm that the bottleneck in our scheme will be the processing capacity of the hardware token. Using a very
secure, but weak 8-bit 1Mhz ATECC family processor [14], we estimate that ECDSA keys can be produced
in under a minute and signatures can be completed in 3s. The entire signing process requires human input
to complete (button press), and thus is likely to take seconds overall anyway.

1.1 Technical overview

The Definition. At a high level, in a Two Factor Signature scheme the signatures are generated by two
parties: a client C who receives a (typically low entropy) password as input from a user, and a token T ,
which can store and generate secrets of arbitrary length, can produce signatures for multiple public keys and
as such keeps a state which can be modified to add the ability to sign for new public keys. It consists of
a tuple of algorithms (KeyGenC,KeyGenT,PKC,PKT,SignC,SignT,Ver), where KeyGenT(1Îş, sT )
and KeyGenC(pwd) are an interactive protocol used by the token and client respectively to produce a
public key and to accordingly update the token state sT by “adding a share of the corresponding secret key”;
PKC(pwd) and PKT(sT ) are two algorithms used by the client and the token (on input the password and
the current token state sT respectively) interacting with each other to retrieve a public key pk which was
previously generated using the first two algorithms; SignC(pwd,m) and SignT(sT ,m) are similarly used to
produce signatures; Ver(pk,m, σ) is used to verify the signatures.

We proceed to outline the unforgeability properties we require from such Two Factor Signature scheme.
We consider 4 different attack scenarios, and define “best-possible” unforgeability properties for each of them.
The first two are simply analogs of the standard unforgeability (for “party 1” and “party 2”) properties of
two-out-of-two threshold signatures.

1. For the Client : The simplest and most natural attack scenario is when the user’s laptop is compromised
(i.e. by malware), even before the key generation phase. We require that, except with negligible probability,
such an adversary cannot forge signatures on a message m with respect to a public key which the token
outputs (and would typically show to the user on its local screen) unless it asked the token to sign m.
This notion mirrors the classic one of unforgeability (for party 1) of threshold signature schemes.

2. For the Token: We next consider an attack scenario in which the adversary can fully control the token T .
We let it interact arbitrarily with an honest client, and receive the signatures and public keys output by
such client during these interactions. We require that the probability that such an adversary can produce
a forgery on a message m that would verify with respect to one of the public keys output by the client
(during a KeyGen execution) without asking the client to sign m, is bounded by the min-entropy of the
user’s password. Again, this notion mirrors the classic notion of unforgeability of threshold signatures (for
party 2), except that since the user only has a low-entropy password, we cannot require the probability
of forging to be negligible; instead, we bound it by q/2m where q is the number of random oracle queries
performed by the adversary, and m is the min-entropy of the password distribution.

Note that the unforgeability for the token security bound is rather weak (when the password has low entropy),
but is necessarily so because the only secret held by the client is the password, and thus an attacker that
“fully controls the token” (i.e., controls its input/outputs while at the same time participating in other
outside interaction) and gets to see public keys, can simply emulate the client algorithm with a guessed
password and attempt to create a forgery. Yet, note that to carry out this type of attack (which leads to
the “unavoidable” security loss) and profit from it is quite non-trivial in practice as it requires the token to
be able to somehow communicate with an attacker in the outside world (which is challenging given that a
hardware wallet is a physically separate entity without a direct network connection).

3



Consequently, we consider two alternative attack scenarios that leverage the fact that often the token
cannot communicate with the adversary and capture more plausible (i.e weaker) attack models. Yet, in these
weaker attack models, we can now require the forging probability bounds to be significantly stronger.

3. For the Token Manufacturer : We consider an adversary who cannot fully control the T party, but can
specify ahead of time a program Π which the T party runs. For example, this models the case of a
malicious token manufacturer who embeds a PRG with a backdoor. Program Π can behave arbitrarily,
but its answers to the interactions with any client have to satisfy the correctness properties of the scheme
with overwhelming probability (if the token aborted or caused the client to return signatures which do
not verify w.r.t. the expected public keys, the user could easily identify such token as faulty or malicious).
The adversary can then have an honest client interact arbitrarily with Π (A is given the resulting public
keys and signatures), and should not be able to produce a forgery on a message m that would verify with
respect to one of the public keys output by the client (during a KeyGen execution) unless it received a
signature on m as a result of such an interaction. We require the forging probability to be negligible (as
opposed to bounded by q/2m).

4. With Access to the Token: An alternative scenario is one where the token is not corrupted, but the attacker
can get access to it (for example, in the case of a lost/stolen token, or a token shared between multiple
users). More precisely, the adversary can interact with an honest T and may also interact with an honest
client C (which itself interacts with T ) and has to produce forgeries on a message m (which C did not
sign, but on which T can be queried) w.r.t. a public key which C output during an interaction with T .
Whereas unforgeability for the token implies that the above-mentioned adversary’s forging probability is
bounded by q/2m where q is the number of random oracle queries, we here sharpen the bound to q′/2m

where q′ is the number of invocations of T . (As T could rate-limit its answers by e.g., 1 sec, q′ will be
significantly smaller than q in practice.)

As far as we know, no previously known scheme satisfies all of the the above properties; in fact, none satisfy
even just (1) and (2), or (1) and (3).2

The Construction The high-level idea behind our construction is natural (although the approach is very
different from Trezor and other currently used hardware wallets). We would like to employ a two-out-of-two
threshold signature (TS) scheme where the token is one of the parties and the client is the other. The
problem is that the client only has a low-entropy password and cannot keep any persistent state. In fact,
even if it had a high-entropy password, it wouldn’t be clear how to directly use the threshold schemes as in
general (and in particular for EC-DSA), secret key shares for threshold schemes are generated in a correlated
way.

To overcome this issue, the key generation algorithm begins by running the key generation procedure for
the TS: the token and the client each get a secret key share (which we denote skT and skC respectively),
as well as the public key pk. Next, since the client cannot remember pk, skC , it encrypts pk, skC using a
key that is derived—by using a random oracle (RO)—from its password; additionally, the client generates
(deterministically) a random “handle” as a function of its password, again by applying the RO to the
password. It then sends both the handle and the (password-encrypted) ciphertext to the token for storage.

Later on, when a client wants to get a signature on a message m, it first asks the token to retrieve its
password-encrypted ciphertext: the token will only provide it if the client provides the correct handle (which
the honest client having the actual password can provide). Next, the client decrypts the ciphertext (again
using the password), and can recover its public and secret key. Finally, using its secret key, and interacting
with the token the client can engage in the threshold signing process to obtain the desired signature on m.

The Analysis: Exploiting Non-Signalling and Exponential-time Simulation While we can show
that the above construction satisfies properties 1,2 and 4 assuming the underlying threshold scheme is secure,
demonstrating property 3—that is, security against malicious token manufacturers, which in our opinion is
the most cruicial property—turns out to be non-trivial.

2Although we are not aware of any formal analysis of Trezor, it would seem that it satisfies (1) and (4), but there are concrete
attacks against the other properties.

4



The issue is the following: as already mentioned, if the token is fully controlled by the attacker (which
participates in outside interactions), then we can never hope to show that unforgeability happens with
negligible probability as the attacker can always perform a brute-force attack on the password. In particular,
in our scheme, the attacker can simply brute-force password guesses against the ciphertext c to recover the
client’s threshold secret key share. However, a malicious manufacturer which generates a malicious token but
cannot directly communicate with it, would have more trouble doing so. Even if the malicious token program
can perform a brute-force attack, it cannot directly communicate the correct password (or the client key
share) to the manufacturer! If the token could somehow signal these information to the manufacturer, then
the manufacturer could again break the scheme. And in principle, with general threshold signatures, there is
nothing that prevents such signalling. For example, if the token could cause the threshold signing algorithm
to output signatures whose low-order bits leak different bits of c, after sufficiently many transactions that
are posted on a blockchain, the adversary could recover c and brute force the password himself.

Towards addressing this issue, we define a notion of Non-Signalling for TS: roughly speaking, this notion
says that even if one of the parties (the token) is malicious, as long as they produce accepting signatures (with
overwhelming probability), they cannot bias the distribution of the signatures generated—i.e., such signatures
will be indistinguishable from honestly generated ones. In fact, to enable our proof of security—which
proceeds using a rather complex sequence of hybrid arguments relying on exponential-time simulation—we
will require the TS scheme to satisfy a statistical notion of Non-Signalling which requires that the distribution
of signatures generated interacting with the malicious party is statistically close to the honest distribution.

We next show that if the underlying TS indeed satisfies statistical Non-Signalling, then our 2FS also
satisfies property 3. Towards doing this, we actually first show that our 2FS satisfies an analogous notion
of Non-Signalling, and then show how to leverage this property to prove unforgeability for the token manu-
facturer. We mention that the notion of Non-Signalling for 2FS is interesting in its own right: it guarantees
that a maliciously implemented token Π (whose answers are restricted to satisfy the correctness properties
of the scheme with overwhelming probability) cannot leak (through the public keys and the signatures which
it helps computing) to an attacker any information which an honestly implemented token would not leak.
In particular, if the honest token algorithm generates independent public keys and uses stateless signing (as
the ones we consider do), even a malicious token cannot leak correlations between which public keys it has
been used to create, or what messages it has signed.

1.2 Additional Properties

Unlinkability Other than the Non-Signalling property, our scheme satisfies an additional desirable privacy
property, Unlinkability, which roughly speaking guarantees that multiple public keys (and signatures with
respect to different public keys) generated with the help of the same honest token (or with different tokens
on input the same password) look independent from each other as if they were generated by both different
tokens and passwords. This property holds even an adversary who can interact arbitrarily with such tokens,
as long as it cannot guess the passwords. This allows a user to have different public keys using the same
hardware token with the guarantee that such public keys will look unrelated to each other to any external
observer. Further, even if a token is lost or such user has to go through customs and her hardware wallet is
inspected, a public key cannot be linked to such token unless the corresponding password is known.

Backing up the token state If the token is lost, stolen or otherwise malfunctioning (due to hardware
failures, or even “ransom attacks” where the manufacturer might set up the token to stop working unless a
ransom is paid), the user might not be able to produce signatures any more, which would result in a loss
of money. Most current hardware wallet solutions derive all the secret keys for the addresses they sign for
from a single short seed (say 256 bits), and offer the possibility to backup the seed at initialization time, by
encoding it as a list of a few words that are displayed directly on the token’s secure display for the user to
write down [16]. This ensures that the seed is never stored on the user’s laptop and thus is out of reach from
malware.

In our case, the token’s state is much larger (as it includes randomness generated from the client and
a ciphertext encrypted under the user’s password), and therefore this method cannot be applied directly.

5



As an alternative solution, the token might encrypt its whole state at initialization time with a fresh key,
transfer the ciphertext to the client’s computer (so that it can be backed up), and give the key to the user
directly (again, in the form of a few words shown on the token’s screen for the user to write down). In
this case, extra care should be taken to ensure that a malicious token cannot leak information through the
ciphertext in the case where such ciphertext is later compromised (for example by choosing a key known
to the manufacturer or using biased randomness in the encryption). For this reason, the client should also
re-encrypt the ciphertext under a fresh key of its own choice (which the user should again write down and
store securely). We stress that both in this case and in existing hardware wallet solutions, correctness of the
backup is not guaranteed. As such, these backups should be verified using independent devices.

Handling multiple addresses efficiently Another important feature for hardware wallet users is to be
able to control multiple independent looking key pairs (addresses). Briefly, using several addresses rather
than a single one to store one’s currency makes tracking multiple transactions made by the same user more
difficult. For example in Bitcoin, when a transaction is performed, the “change” generated by the transaction
is often moved to a fresh address (controlled by the sender) rather than being sent back to the address which
is funding the transaction. While it is feasible to use more than one public key with the same hardware
wallet with our proposed Two Factor Signature scheme, by just running the KeyGen algorithm every time
a new address is needed, this is inconvenient because each such new “change” address generation requires a
separate backup step. Indeed, most commercial hardware wallets offer the possibility to derive more than
one signing key pair from the same seed.

One first approach to overcome this limitation would be to extend the scheme by generating more than
one independent key pair for the underlying threshold signature scheme every time the key generation
algorithm of the Two Factor Signature scheme is run. These different addresses could be distinguished by
a counter (which the user would provide as an additional parameter to the Sign and PK algorithms to
identify which of the key pairs to use). Moreover, they would all be encrypted and backed up together with
a single encryption key (using the mechanism of the previous paragraph) so that the number of words the
user has to write down doesn’t increase. As an additional optimization, in our EC-DSA based instantiation,
the most computationally expensive output of the key generation algorithm (namely the precomputed OT
extensions) could be reused accross multiple key pairs for increased efficiency.

Another possibility is to pick a threshold signature scheme that allows to efficiently sign w.r.t. multiple
independent looking public keys given a single pair of secret key shares (whose size does not depend on
the number of public keys). The EC-DSA based threshold scheme we describe can be modified in this
sense by applying a technique detailed in section 4.4 of [8] (this idea can be adapted to the Schnorr case
as well). Briefly speaking, in the original scheme, at the end of the KeyGen algorithm each party holds a
multiplicative share of the secret signing key. It is therefore easy to modify such algorithm so that the client
and the token can agree on an additional random string c (which is stored by the token and included by
the client in the ciphertext it sends to the token). Then, as an additional input to the Sign algorithm, the
client can pick any identifier i to distinguish each of the many public keys required (for example, a simple
counter): the public key associated with identifier i would be computed by both parties as pki = pkH(c,pk,i)

(where pk is the original public key and H is a hash function), and signatures could be computed by having
the client use skC,i = skC ¡H(c, pk, i) instead of skC as the secret key in the threshold signature algorithm
(the token would keep using the same secret key). See [8] for more details. Note that these modifications
to the signature scheme would require adapting the security definitions to fit this scenario, which we leave
to future work. For example, the Non-Signalling definition would also have to require that the many public
keys generated by different values of i look independent to an outside observer or to the token manufacturer.
Similarly, the unforgeability definitions and proofs would need to be adapted to ensure that a corrupted
client cannot use an execution of the signature algorithm where the token intends to produce a signature for
the key associated with counter i to produce a signature for a different identifier i′ (we conjecture that this
is the case for the EC-DSA signature scheme we propose).

6



1.3 Related Work

Threshold Signatures Threshold signatures [4, 7, 17, 2, 1] are signature schemes distributing the ability
to generate a signature among a set of parties, so that cooperation among at least a threshold of them is
required to produce a signature. Nicolosi et al. [15] present a threshold signature scheme for the Schnorr
signature scheme. Particularly relevant to the cryptocurrency application are the works of Goldfeder et
al. [8, 6], Lindell [9, 10], and Lee et al. [5] which propose a threshold signature scheme to produce ECDSA
signatures, which is already compatible with Bitcoin and Ethereum.

Passwords + Threshold signatures MacKenzie and Reiter [11, 12] and Camenish et al. [3] consider
notions somewhat similar to the one of a password-based threshold signature scheme: as in our setting,
signing requires knowledge of a password and access to an external party (in their case a server rather than
a hardware token), but in contrast to our setting the signer may additionally hold some high-entropy secret
state (and indeed, the schemes considered in those papers require such secret state). This rules out the usage
of such schemes in our scenario, as we want the user to be able to operate his wallet from any client without
relying on any external state beyond its password.

1.4 Organization of the paper

Section 2 introduces some notations, recalls the security definitions for encryption schemes and presents
some auxiliary lemmas. In Section 3 we recall the definition of Threshold Signature scheme and introduce
the Non-Signalling property. Section 4 defines Two Factor Signature schemes and Section 5 presents our
main construction and proofs of security. Section 6 presents the two modified TS schemes (based on Schnorr
and EC-DSA) which can be used to instantiate our construction, and Section 7 discusses the Unlinkability
property.

2 Preliminaries and Notation

If X is a probability distribution, we denote with x← X the process of sampling x according to X. When, in
a probabilistic experiment, we say that an adversary outputs a probability distribution, we mean that such a
distribution is given as a poly-time randomized program such that running the program with no input (and
uniform randomness) samples from such distribution. For two party (randomized) algorithms we denote
with 〈α;β〉 ← 〈A(a);B(b)〉 the process of running the algorithm A on input a (and uniform randomness as
needed) interacting with algorithm B on input b (and uniform randomness), where Îą is the local output of A
and β is the local output of B. Whenever an algorithm has more than one output, but we are interested in
only a subset of such outputs, we will use ¡ as a placeholder for the other outputs (for example we could write
(·, pk) ← KeyGen(1κ) to denote that pk is a public key output by the KeyGen algorithm of a signature
scheme in a context where we are not interested in the corresponding secret key).

Token Oracles. In our definitions, we will often model a party/program implementing party T . We say
that a Token Oracle is a stateful oracle which can answer KeyGen, PK, Sign queries. Initially, its state
is set to ⊥. To answer such queries, the oracle interacts with its caller by running the KeyGenT, PKT,
SignT algorithms respectively using its own inner state (and a message m supplied by the caller for Sign
queries). As a result of KeyGenT queries, its state is also updated. Moreover, when explicitly specified, the
oracle could also return to the caller the public keys pk which are part of its local output during KeyGenT

and SignT queries.

2.1 Symmetric encryption

Our construction requires indistinguishability under a chosen ciphertext attack: no adversary, given an
encryption oracle that, each time it is queried, takes as input two messages and always encrypts the first
or the second one, and a decryption oracle which cannot be queried on outputs of the first oracle, should

7



be able to tell which of the two messages the encryption oracle is encrypting. We also require integrity
of ciphertexts: no adversary, given an encryption oracle, should be able to create a new ciphertext which
successfully decrypts.

Definition 1 (Symmetric Encryption). A Symmetric Encryption scheme is a triple of PPT algorithms
SE = (SE.G,SE.E,SE.D) such that:

• SE.G(1κ) → ek is the “Key Generation algorithm”, which on input the security parameter κ outputs a
secret key ek. In this work, we assume without loss of generality that SE.G simply samples3 ek ←R {0, 1}κ.

• SE.E(ek,m)→ c is the “Encryption algorithm”, which on input a secret key ek and a message m outputs
a ciphertext c.

• SE.D(ek, c)→ m is the “Decryption algorithm”, which on input a secret key ek and a ciph";"""date"",""2019-05-15T03:16:30Z""
""pdf:PDFVersion"",""1.5""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:docinfo:title"",""""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""pdfa:PDFVersion"",""A-2b""
""xmpMM:History:Action"",""converted""
""language"",""en""
""dc:format"",""application/pdf; version=""""A-2b"""""",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""xmpMM:History:When"",""2019-05-14T23:16:30Z""
""pdf:encrypted"",""false""
""dc:title"",""""
""xmp:CreateDate"",""2019-01-02T16:26:46Z""
""modified"",""2019-05-15T03:16:30Z""
""cp:subject"",""""
""xmpMM:History:SoftwareAgent"",""Preflight""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""xmpMM:History:InstanceID"",""uuid:6108a866-6f29-ba4d-88d4-d2e217d025dc""
""xmp:ModifyDate"",""2019-05-14T23:16:30Z""
""pdf:docinfo:creator"",""""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2019-01-02T15:26:46Z""
""created"",""2019-01-02T15:26:46Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-01-02T15:26:46Z""
""resourceName"",""10094253""
""pdfaid:part"",""2""
""Author"",""""
""producer"",""pdfTeX-1.40.16""
""pdf:docinfo:producer"",""pdfTeX-1.40.16""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""3"",""0"",""1"",""4"",""2"",""3"",""10"",""23"",""15"",""0"",""10"",""11"",""1"",""3"",""2"",""0"",""4"",""13"",""8"",""6"",""4"",""10"",""1"",""1"",""5"",""11"",""7"",""1"",""9"",""10"",""0"",""5"",""11"",""11"",""18"",""8""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2019-01-02T15:26:46Z""
""Last-Modified"",""2019-05-15T03:16:30Z""
""dcterms:modified"",""2019-05-15T03:16:30Z""
""title"",""""
""xmpMM:DocumentID"",""uuid:24098e48-8b31-a949-82f0-0168d67f637c""
""Last-Save-Date"",""2019-05-15T03:16:30Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2019-05-15T03:16:30Z""
""meta:save-date"",""2019-05-15T03:16:30Z""
""Content-Length"",""388756""
""Content-Type"",""application/pdf""
""xmp:MetadataDate"",""2019-05-14T23:16:30Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""pdfaid:conformance"",""B""
""pdf:producer"",""pdfTeX-1.40.16""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""39""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""2810"",""4175"",""3995"",""3947"",""4206"",""4103"",""3266"",""2565"",""2340"",""2972"",""2870"",""3414"",""3030"",""3027"",""3550"",""2787"",""2940"",""2482"",""3499"",""798"",""3120"",""1312"",""2157"",""3478"",""3002"",""2603"",""3703"",""2483"",""3089"",""3380"",""2914"",""2926"",""2847"",""3639"",""2936"",""2597"",""3194"",""2573"",""3813""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-01-02T15:26:46Z""
";https://scholar.google.com/scholar?start=850&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094654-1138;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[PDF][PDF] A Review on Secure Data Transmission Using Identity based Encryption & Visual Cryptography;PS Ghatode, PD Bangade ;2019 academia.edu;;"… Berlin,Germany: Springer, 2004, vol. 3027, pp. 223–238. [13]. D. Boneh and X. Boyen, “Secure

identity based encryption without random oracles,” in Advances in Cryptology (CRYPTO?04),

M. Franklin, Ed. Berlin, Germany: Springer, 2004, vol. 3152, pp. 197–206. [14] …";;;[PDF] academia.edu;https://www.academia.edu/download/65381665/5629.pdf;;;https://scholar.google.com/scholar?start=950&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094534-628;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;An Overview of Blockchain-based Applications for Consumer Electronics;V Gatteschi, F Lamberti… ; 2019 IEEE 23rd …, 2019  ieeexplore.ieee.org;;"… During the mining process, nodes verify if a person is entitled to spend a given amount of

cryptocurrency (by inspecting previous … To gather data from the real world, smart contracts exploit

oracles, services which read data from outside and inject them in the blockchain …";Cité 1 fois;;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/8892348/8900973/08900981.pdf?casa_token=jx-qMJFK4AUAAAAA:gO7KhsSyjPF2blfzf7-uuwGEdizUjqUkXJNummUJNrYBxPpm_Olf2SntGAQDVNBJxndlScgrR1Q;;"""og:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""twitter:title"",""An Overview of Blockchain-based Applications for Consumer Electronics""
""twitter:card"",""summary""
""Description"",""A high number of research initiatives investigated the advantages of blockchain technology in different sectors. The objective of this work is to present an ove""
""og:title"",""An Overview of Blockchain-based Applications for Consumer Electronics""
""resourceName"",""08900981.pdf""
""language"",""en""
""title"",""An Overview of Blockchain-based Applications for Consumer Electronics | IEEE Conference Publication | IEEE Xplore""
""og:description"",""A high number of research initiatives investigated the advantages of blockchain technology in different sectors. The objective of this work is to present an overview of blockchain-based applications in the consumer electronics field. In particular this work reports around fifty blockchain initiatives in the contexts of healthcare, smart homes, smart cities, automotive and smart devices, and discusses advantages/limitations of this technology.""
""twitter:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-UA-Compatible"",""IE=Edge""
""viewport"",""width=device-width, initial-scale=1.0""
""dc:title"",""An Overview of Blockchain-based Applications for Consumer Electronics | IEEE Conference Publication | IEEE Xplore""
""twitter:description"",""A high number of research initiatives investigated the advantages of blockchain technology in different sectors. The objective of this work is to present an overview of blockchain-based applications in the consumer electronics field. In particular this work reports around fifty blockchain initiatives in the contexts of healthcare, smart homes, smart cities, automotive and smart devices, and discusses advantages/limitations of this technology.""
""Content-Encoding"",""UTF-8""
""Content-Type-Hint"",""text/html; charset=utf-8""
""Content-Length"",""39196""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=440&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094562-746;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Blockchain-From Cryptocurrency to Vertical Industries-A Deep Shift;MI Sarwar, K Nisar, A Khan ; 2019 IEEE International …, 2019  ieeexplore.ieee.org;;"… C. Payments & Remittances With the use of Crypto / Digital currencies, international payments

and … has gained the attention of many remarkable development companies like Oracle and SAP.

Data in Blockchain ledger is secure and immutable; therefore, this is the technology …";Autres articles;;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/8949349/8960683/08960795.pdf?casa_token=trBTU-z_socAAAAA:H5me4DH_9AJqUQe12_COnlYtXHk8uycCC_Aj6RJOyJN5igEHTULROQcNRKZWgzrRs1Y3mO6inEo;;"""og:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""twitter:title"",""Blockchain - From Cryptocurrency to Vertical Industries - A Deep Shift""
""twitter:card"",""summary""
""Description"",""A technology that has shifted the entire paradigm of computer applications during the last decade is undoubtedly, the Blockchain technology. The purpose of inve""
""og:title"",""Blockchain - From Cryptocurrency to Vertical Industries - A Deep Shift""
""resourceName"",""08960795.pdf""
""language"",""en""
""title"",""Blockchain - From Cryptocurrency to Vertical Industries - A Deep Shift | IEEE Conference Publication | IEEE Xplore""
""og:description"",""A technology that has shifted the entire paradigm of computer applications during the last decade is undoubtedly, the Blockchain technology. The purpose of inventing Blockchain was to develop a technology in which data is immutable, confidential and located on a de-centralized network. This technology was first used to build a cryptocurrency application, which is just one of many applications developed using Blockchain technology. Since, most of the emphasis has been on the money and finance related services, now the vertical industries have also started to implement Blockchain. This study contributes to review the opportunities of using Blockchain technology in vertical industries.""
""twitter:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-UA-Compatible"",""IE=Edge""
""viewport"",""width=device-width, initial-scale=1.0""
""dc:title"",""Blockchain - From Cryptocurrency to Vertical Industries - A Deep Shift | IEEE Conference Publication | IEEE Xplore""
""twitter:description"",""A technology that has shifted the entire paradigm of computer applications during the last decade is undoubtedly, the Blockchain technology. The purpose of inventing Blockchain was to develop a technology in which data is immutable, confidential and located on a de-centralized network. This technology was first used to build a cryptocurrency application, which is just one of many applications developed using Blockchain technology. Since, most of the emphasis has been on the money and finance related services, now the vertical industries have also started to implement Blockchain. This study contributes to review the opportunities of using Blockchain technology in vertical industries.""
""Content-Encoding"",""UTF-8""
""Content-Type-Hint"",""text/html; charset=utf-8""
""Content-Length"",""39688""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=560&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094623-1001;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[PDF][PDF] Toward a Stable Tokenized Medium of Exchange;A Lipton ; Cryptoassets. Legal, Regulatory and Monetary …, 2019  numerairefinancial.com;;"… the price of a crypto coin in terms of a fiat currency requires an oracle and automatically … Such

oracles are prone to manipulation, and more importantly at odds with the claimed decentralized

nature … Ideally, one should be able to directly observe this price from the blockchain in a …";Cité 5 fois;;[PDF] numerairefinancial.com;http://www.numerairefinancial.com/s/20-2019-Lipton-Toward-a-Stable-Tokenized-Medium-of-Exchange-Brummer_Legal__Regulatory__and_Monetary_.pdf;;;https://scholar.google.com/scholar?start=820&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094590-868;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Data sharing and privacy for patient iot devices using blockchain;G Srivastava, RM Parizi, A Dehghantanha… ; … Conference on Smart …, 2019  Springer;;"… https://media.consensys.net/a-visit-to-the-oracle-de9097d38b2f. 7. Dwivedi, AD, Malina, L.,

Dzurenda, P., Srivastava, G.: Optimized blockchain model for … Srivastava, G., Dwivedi, AD, Singh,

R.: Crypto-democracy: a decentralized voting scheme using blockchain technology …";Cité 19 fois;Les 3 versions;[PDF] researchgate.net;https://www.researchgate.net/profile/Reza_Parizi/publication/336672026_Data_Sharing_and_Privacy_for_Patient_IoT_Devices_Using_Blockchain/links/5dab4f43299bf111d4bee117/Data-Sharing-and-Privacy-for-Patient-IoT-Devices-Using-Blockchain.pdf;;;https://scholar.google.com/scholar?start=680&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094623-1003;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;How blockchain technology can be used for trade finance process in Nigeria;O Oye;Bamgbose 2019 esource.dbs.ie;;"… people believe the it would replace other centralized databases such as the Oracle,

however, this is an exaggerated view of the blockchain's potential. Blockchain is mainly

based on cryptography and consensus algorithms which …";Cité 2 fois;;[PDF] dbs.ie;https://esource.dbs.ie/bitstream/handle/10788/3659/mba_oye-bamgbose_o_2019.pdf?isAllowed=y&sequence=1;;"""date"",""2019-01-06T23:01:10Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.5""
""xmp:CreatorTool"",""MicrosoftÂŽ Word 2016""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dc:creator"",""fikayo oye""
""language"",""en""
""dcterms:created"",""2019-01-06T23:01:10Z""
""Last-Modified"",""2019-01-06T23:01:10Z""
""dcterms:modified"",""2019-01-06T23:01:10Z""
""dc:format"",""application/pdf; version=1.5""
""Last-Save-Date"",""2019-01-06T23:01:10Z""
""pdf:docinfo:creator_tool"",""MicrosoftÂŽ Word 2016""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2019-01-06T23:01:10Z""
""meta:save-date"",""2019-01-06T23:01:10Z""
""pdf:encrypted"",""false""
""modified"",""2019-01-06T23:01:10Z""
""Content-Length"",""2246516""
""pdf:hasMarkedContent"",""true""
""Content-Type"",""application/pdf""
""pdf:docinfo:creator"",""fikayo oye""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""fikayo oye""
""dc:language"",""en-GB""
""meta:author"",""fikayo oye""
""meta:creation-date"",""2019-01-06T23:01:10Z""
""created"",""2019-01-06T23:01:10Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""130""
""Creation-Date"",""2019-01-06T23:01:10Z""
""resourceName"",""mba_oye-bamgbose_o_2019.pdf""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""389"",""424"",""2641"",""2556"",""685"",""1361"",""798"",""2314"",""1985"",""1305"",""1724"",""1158"",""1587"",""1690"",""1463"",""1154"",""1642"",""1968"",""1849"",""1422"",""584"",""55"",""52"",""320"",""788"",""1715"",""1297"",""1638"",""1810"",""1971"",""2015"",""1968"",""1717"",""2008"",""1270"",""1135"",""1661"",""956"",""1343"",""613"",""939"",""1155"",""2046"",""1297"",""1987"",""1155"",""619"",""1644"",""1343"",""1488"",""1984"",""1763"",""1844"",""1162"",""1617"",""1785"",""1095"",""1945"",""1817"",""1731"",""1377"",""2199"",""1847"",""2095"",""2127"",""2175"",""2176"",""2110"",""2291"",""1474"",""2146"",""2008"",""1988"",""2079"",""2036"",""1438"",""2158"",""1813"",""1945"",""2123"",""311"",""1898"",""2226"",""1770"",""666"",""967"",""1397"",""2061"",""2329"",""2246"",""2631"",""2617"",""1889"",""2908"",""2280"",""2440"",""2186"",""1906"",""1925"",""2241"",""1041"",""3044"",""3377"",""3300"",""3401"",""3282"",""3201"",""3307"",""3034"",""2857"",""1040"",""2876"",""2976"",""2055"",""2200"",""786"",""2333"",""2234"",""2644"",""2580"",""2380"",""2767"",""288"",""2578"",""2140"",""737"",""71"",""7"",""11"",""8""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""Author"",""fikayo oye""
""producer"",""MicrosoftÂŽ Word 2016""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""MicrosoftÂŽ Word 2016""
""pdf:docinfo:created"",""2019-01-06T23:01:10Z""
";https://scholar.google.com/scholar?start=820&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094649-1120;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;On Value Preservation with Distributed Ledger Technologies, Intelligent Agents, and Digital Preservation;JL De La Rosa ; International Congress on Blockchain and Applications, 2019  Springer;;"… Agents Digital preservation Blockchain DLT Virtual currencies. Download conference paper PDF …

First topic, there is need to find out whether preservation is provided as a service (eg by currently

existing DP solutions providers) that can be called remotely through oracles or as …";Autres articles;;[PDF] easychair.org;https://easychair.org/publications/preprint_download/L7zn;;"""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.5""
""xmp:CreatorTool"",""PScript5.dll Version 5.2.2""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dc:creator"",""PeplluĂ­s""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""title"",""Microsoft Word - 1904 Agents and DLT for Value Preservation, position paper, v04""
""xmpMM:DocumentID"",""uuid:d6be97e6-4709-4379-a584-256f47779eb8""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""Microsoft Word - 1904 Agents and DLT for Value Preservation, position paper, v04""
""xmp:CreateDate"",""2019-04-04T16:13:55Z""
""Content-Length"",""254948""
""pdf:hasMarkedContent"",""false""
""Content-Type"",""application/pdf""
""xmp:ModifyDate"",""2019-04-04T16:13:55Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""PeplluĂ­s""
""meta:author"",""PeplluĂ­s""
""pdf:producer"",""Acrobat Distiller 10.1.16 (Windows)""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""9""
""resourceName"",""L7zn""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""250"",""2771"",""3337"",""3644"",""3406"",""2051"",""4046"",""3385"",""3712""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""Author"",""PeplluĂ­s""
""access_permission:can_modify"",""true""
";https://scholar.google.com/scholar?start=930&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094602-918;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[PDF][PDF] FROM CLAUSE TO CODE: TRANSFORMING CONTRACTS INTO SMART CONTRACTS;J Joos ;2019 lib.ugent.be;;"… Quantification through oracle input 77 … of oracles, as they bridge the gap between the online

environment of smart contracts and the physical … https://blockchainreview.io/crypto-assets-

cryptocurrencies-digital-blockchain-stablecoin-sto-bitcoin-altcoin/ (Consulted on 27 November …";Autres articles;Version HTML;[PDF] ugent.be;https://lib.ugent.be/fulltxt/RUG01/002/782/568/RUG01-002782568_2019_0001_AC.pdf;;"""date"",""2019-05-15T01:13:26Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.3""
""pdf:docinfo:title"",""Microsoft Word - Thesis final Word.docx""
""xmp:CreatorTool"",""Word""
""Keywords"",""""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""dcterms:created"",""2019-05-15T01:13:26Z""
""language"",""en""
""Last-Modified"",""2019-05-15T01:13:26Z""
""dcterms:modified"",""2019-05-15T01:13:26Z""
""dc:format"",""application/pdf; version=1.3""
""title"",""Microsoft Word - Thesis final Word.docx""
""Last-Save-Date"",""2019-05-15T01:13:26Z""
""pdf:docinfo:creator_tool"",""Word""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2019-05-15T01:13:26Z""
""meta:save-date"",""2019-05-15T01:13:26Z""
""pdf:encrypted"",""false""
""dc:title"",""Microsoft Word - Thesis final Word.docx""
""modified"",""2019-05-15T01:13:26Z""
""Content-Length"",""1808908""
""pdf:hasMarkedContent"",""false""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""dc:subject"",""""
""meta:creation-date"",""2019-05-15T01:13:26Z""
""created"",""2019-05-15T01:13:26Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""122""
""Creation-Date"",""2019-05-15T01:13:26Z""
""resourceName"",""RUG01-002782568_2019_0001_AC.pdf""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""417"",""1600"",""8"",""2829"",""768"",""7"",""910"",""1170"",""1038"",""644"",""8"",""2398"",""3717"",""2967"",""2791"",""2935"",""3326"",""206"",""2915"",""3397"",""3399"",""2136"",""3365"",""3158"",""2615"",""2882"",""3043"",""3166"",""3200"",""3621"",""2367"",""3147"",""2076"",""1999"",""2825"",""3648"",""3466"",""2567"",""2912"",""2714"",""3489"",""3423"",""2927"",""3730"",""3308"",""2976"",""3191"",""3106"",""2427"",""2130"",""2937"",""1120"",""2745"",""3289"",""3296"",""3559"",""3356"",""3306"",""3679"",""3343"",""2969"",""3333"",""3315"",""3518"",""2876"",""1558"",""1978"",""3105"",""3029"",""2576"",""3037"",""2987"",""2845"",""3255"",""2753"",""3156"",""3384"",""2841"",""3718"",""2155"",""3368"",""2340"",""1841"",""3896"",""2970"",""2471"",""2209"",""1745"",""2178"",""3104"",""3163"",""2143"",""3137"",""3189"",""3305"",""1817"",""1940"",""2853"",""2160"",""2989"",""2356"",""1439"",""2093"",""3088"",""9"",""2077"",""3096"",""846"",""2347"",""1087"",""2117"",""2190"",""2354"",""2491"",""2545"",""2300"",""2195"",""2226"",""2157"",""2638"",""2334"",""371""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""meta:keyword"",""""
""producer"",""macOS Version 10.14.4 (Build 18E226) Quartz PDFContext""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""macOS Version 10.14.4 (Build 18E226) Quartz PDFContext""
""pdf:docinfo:created"",""2019-05-15T01:13:26Z""
";https://scholar.google.com/scholar?start=730&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094548-685;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Enforcing trustworthy cloud SLA with witnesses: A game theory–based model using smart contracts;H Zhou, X Ouyang, J Su, C de Laat… ; … Practice and Experience, 2019  Wiley Online Library;;"… Oraclize‡ is a third trusted company currently offering the service as an oracle. Nevertheless,

a third trusted party exists single-point failure and deviates from the decentralization idea

of blockchain. Hence, ChainLink24 works on distributed oracles …";Cité 7 fois;;[PDF] wiley.com;https://onlinelibrary.wiley.com/doi/pdf/10.1002/cpe.5511;;;https://scholar.google.com/scholar?start=500&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094553-705;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Introduction: The Context of Time and Space;ER Onyejekwe ; Portable Health Records in a Mobile Society, 2019  Springer;;"… society! Come join the group! References. Blockchain in healthcare: a data-centric

perspective. 2018. https://medium.com/crypto-oracle/blockchain-in-healthcare-a-data-

centric-perspective-109e898d73f3. Accessed 6 Sept 2018 …";Autres articles;;null;;;;https://scholar.google.com/scholar?start=520&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094553-702;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Toward a sustainable circular economy powered by community-based incentive systems;MM Dapp ; Business Transformation through Blockchain, 2019  Springer;;"… pm/) and Augur (http://www.augur.net/) are decentralized, peer-to-peer oracle and prediction …

outcome of any future event, or viewed differently, to establish decentralized oracles powered

by … built into its core design by using cryptoeconomics based on blockchain technology to …";Cité 7 fois;Les 5 versions;[PDF] researchgate.net;https://www.researchgate.net/profile/Marcus_Dapp/publication/330023807_Toward_a_Sustainable_Circular_Economy_Powered_by_Community-Based_Incentive_Systems_Volume_II/links/5d85e91c299bf1996f83ea37/Toward-a-Sustainable-Circular-Economy-Powered-by-Community-Based-Incentive-Systems-Volume-II.pdf;;;https://scholar.google.com/scholar?start=520&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094626-1011;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Cryptographic Reverse Firewalls for Identity-Based Encryption;Y Zhou, Y Guan, Z Zhang, F Li ; … Conference on Frontiers in Cyber Security, 2019  Springer;;"… At the same time, many of the encryption schemes that are proven to be secure in Random Oracle

Model (ROM) may present undetectable vulnerabilities when implemented, and these

vulnerabilities may reveal a users' secrets, eg, the machine hides some backdoors without …";Cité 1 fois;Les 3 versions;null;;;;https://scholar.google.com/scholar?start=830&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094569-774;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;??????????? ?????????? ??????? ?????????? ?? ????????? ?????????? ??????? ????????????? ????? ???????? MS SQL server ?? Oracle;?? ?????, ?? ????????, ?? ???????, ?? ??? ;2019 biblio.umsf.dp.ua;;"… DBMS Oracle and MS SQL Server have standard built-in crypto data protection packets. The

purpose of this article is to consider merits and demerits of using these packages and analyze

possibility of their using in customs departments of fiscal service of Ukraine …";Autres articles;;[PDF] umsf.dp.ua;http://biblio.umsf.dp.ua/jspui/bitstream/123456789/3557/1/7%20%D0%9A%D0%B0%D0%B1%D0%B0%D0%BA%20%D0%9B.%20%D0%92..pdf;"
 

            ISSN 2521-6643                     Системи та технології, № 1 (57), 2019 212 107 

DOI:  
УДК 004.056.55 

 
Л. В. Кабак, кандидат технічних наук,  
доцент кафедри програмного  
забезпечення комп’ютерних систем  
Національного технічного університету  
“Дніпровська політехніка”  
О. Н. Молотков, кандидат технічних наук,  
доцент кафедри інформаційних систем  
та технологій Університету митної справи  
та фінансів  
О. П. Буланий, кандидат фізико-
математичних наук, доцент кафедри  
інформаційних систем та технологій  
Університету митної справи та фінансів  
В. В. Куц, студент Університету митної  
справи та фінансів 
 

ДОСЛІДЖЕННЯ МОЖЛИВОСТІ ЗАХИСТУ ІНФОРМАЦІЇ  
ЗА ДОПОМОГОЮ ВБУДОВАНИХ ПАКЕТІВ КРИПТОЗАХИСТУ 

 ДАНИХ СЕРВЕРІВ MS SQL SERVER ТА ORACLE 
 

Проведено дослідження, розглянуто можливості впровадження вбу-
дованих у сервер Oracle та MS SQL Server алгоритмів криптозахисту даних 
у спеціалізовані інформаційні системи на прикладі інформаційної системи 
Державної фіскальної служби України. Досліджено швидкодію роботи ал-
горитмів, оцінено зростання завантаження серверів і навантаження на 
комп’ютерну мережу через збільшення обсягу даних, що передаються. На-
був подальшого розвитку метод оцінювання роботи вбудованих симетричних 
алгоритмів шифрування даних. Запропоновано алгоритм універсальної функ-
ції, яка дає можливість шифрувати дані завдяки введеному ключеві та обра-
ному алгоритму. 

Ключові слова: криптоалгоритми; захист даних; шифрування даних; 
бази даних; спеціалізовані інформаційні системи. 
 

Проведено исследование и рассмотрены возможности внедрения встроен-
ных в сервер Oracle и MS SQL Server алгоритмов криптозащиты данных в 
специализированные информационные системы на примере информационной 

 
© Л. В. Кабак, О. Н. Молотков, О. П. Буланий, В. В. Куц, 2019 

Л. В. Кабак, О. Н. Молотков, О. П. Буланий, В. В. Куц 



 

            ISSN 2521-6643                    Системи та технології, № 1 (57), 2019 212 108 

системы Государственной фискальной службы Украины. Также исследова-
но быстродействие работы алгоритмов и проведена оценка роста загрузки 
серверов и нагрузка на компьютерную сеть за счет увеличения объемов пере-
даваемых данных. Получил дальнейшее развитие метод оценки работы 
встроенных симметричных алгоритмов шифрования данных. Предложен ал-
горитм универсальной функции, которая позволяет проводить шифрованые 
данных благодаря введенному ключу и выбранному алгоритму. 

Ключевые слова: криптоалгоритмы; защита данных; шифрование 
данных; базы данных; специализированные информационные системы. 

 
At the present time Oracle and MS SQL Servers are used for datastorage in 

the information system of department of customs control organization and for 
processing of State Fiscal Service of Ukraine. Data cumulated during customs 
clearance which requires access from all users are spread among many 
databases located between various physical storages. Data is passed between 
servers using different types of computer networks. With development of ramified 
informational systems and networks become a topical issue of ensuring sustaina-
bility, confidentiality and authenticity of data in customs departments of fiscal 
service of Ukraine, which are transmitted through open data line, through usage 
of modern cryptography methods. It's important to know that there are different 
methods that help to choose such set of security tools that will provide maximum 
data security. To protect data from unauthorized access are used modern data 
encryption algorithms. At the present time data is transmitted over the computer 
network without usage of any crypt protection system which may give attacker 
opportunity to capture data. DBMS Oracle and MS SQL Server have standard 
built-in crypto data protection packets. The purpose of this article is to consider 
merits and demerits of using these packages and analyze possibility of their using 
in customs departments of fiscal service of Ukraine. According to research tech-
nique in this article following tasks were solved: analyzing of built-in crypto data 
protection packets, as in their cryptostability, speed and volume increase of 
transmitted data, developing of plug-in for speed test of existing methods for crypt 
protection, considering possibility of implementation built-in packets into infor-
mational system of fiscal service of Ukraine. In this article, the speed of algo-
rithms work was investigated and an estimation of the growth of server loading 
and loading on the computer network was made due to the increase of data vo-
lumes being transmitted. In the article, the method for evaluating the work of em-
bedded symmetric data encryption algorithms has been further developed. 

Key words: grid system; partitioning; data consolidation; data bases; 
specialized information systems. 



 

            ISSN 2521-6643                     Системи та технології, № 1 (57), 2019 212 109 

Постановка проблеми. Нині в інформаційній системі департаменту 
організації митного контролю та оформлення Державної фіскальної служби 
України для збереження даних використовують сервери Oracle та MS SQL 
Server. Дані, що накопичуються під час митного оформлення, до яких необ-
хідний доступ усім користувачам, розкидані серед безлічі баз даних, розта-
шованих у різних фізичних місцях зберігання. Дані передаються між серве-
рами через різні типи комп’ютерних мереж. Із розвитком розгалужених ін-
формаційних систем і мереж стало актуальним питання забезпечення ціліс-
ності, конфіденційності та достовірності даних в митних підрозділах Дер-
жавної фіскальної служби України, які передаються через відкриті канали 
зв’язку, шляхом використання сучасних методів криптографії. Важливо зна-
ти, що існують різні методи, котрі допомагають обрати таку сукупність за-
собів захисту, яка забезпечить максимальну безпеку даних. Для захисту да-
них від несанкціонованого доступу використовують сучасні алгоритми шиф-
рування даних. Деякі стандартні алгоритми у вигляді пакетів постачаються 
разом із СКБД Oracle та MS SQL Server. Для організації роботи сучасної 
Єдиної інформаційної системи фіскальної служби використовуються засоби 
Оrасlе, які називаються розподіленою базою даних і тиражуванням даних. 
Кожна база даних керується власною локальною системою керування базою 
даних (далі – СКБД). Усі сервери баз даних у розподіленій базі даних спів-
працюють, щоб підтримувати погодженість глобальної бази даних. Однак 
нині дані передаються через комп’ютерну мережу без використання будь-
яких систем криптозахисту, це уможливлює перехоплення даних зловмис-
никами. СКБД Oracle має утиліту Oracle Advanced Security, яку потрібно ку-
пувати за окремі кошти, але вона не придатна для роботи гетерогенних роз-
поділених баз даних. СКБД Oracle та MS SQL Server мають стандартні вбу-
довані пакети криптозахисту даних. Мета дослідження – розглянути перева-
ги та недоліки використання цих пакетів, а також можливість їх викорис-
тання в митних підрозділах фіскальної служби України. 

Відповідно до мети наукового дослідження слід виконати такі завдання: 
– вивчити вбудовані пакети криптозахисту даних, а саме: їхню крипто-

стійкість, швидкодію та збільшення обсягу даних, що передаються; 
– розробити алгоритм тестування швидкодії наявних методів криптозахисту;  
– розглянути можливість втілення убудованих пакетів в інформаційну 

систему Державної фіскальної служби України. 
Аналіз останніх досліджень і публікацій. У СКБД Oracle та MS SQL 

Server наявні такі алгоритми шифрування даних: DES, DES3, AES.  
DES (англ. Data Encryption Standard) – це симетричний алгоритм 

шифрування певних даних, стандарт шифрування прийнятий урядом США з 
1976 р. до кінця 1990-х рр., із часом набув міжнародного застосування. Ще 



 

            ISSN 2521-6643                    Системи та технології, № 1 (57), 2019 212 110 

після розроблення алгоритм викликав неоднозначні відгуки. Оскільки DES 
містив засекречені елементи своєї структури, то виникали побоювання щодо 
можливості контролю з боку Національного Агентства Безпеки США (англ. 
National Security Agency). Алгоритм піддавався критиці через малу довжину 
ключа, що, зрештою, після бурхливих обговорень і контролю академічної 
громадськості не завадило йому стати загальноприйнятим стандартом. DES 
дав поштовх сучасним уявленням про блокові алгоритми шифрування та 
криптоаналіз [1–3].  

Нині DES вважається ненадійним, адже він має малу довжину ключа 
(56 біт) і розмір блоку (64 біти). У праці M. Mitsuru  [4] подано методику 
криптоаналізу, завдяки якій у 1999 р. ключ DES було публічно дешифрова-
но. Процес дешифрування тривав 22 год 15 хв. Нині цей алгоритм викорис-
товується в модифікації 3-DES, вважається, що в цій модифікації алгоритм 
досить надійний для застосування. DES поступово витісняється алгоритмом 
AES, що з 2002 р. є стандартом США [2; 4]. 

Робота над розробкою алгоритму шифрування AES почалась 1997 р. у 
NIST (National Institute of Standards and Technology). Співробітники цього 
інституту співпрацювали з промисловцями та вченою спільнотою, котра за-
ймалась криптозахистом інформації, й досліджували новітні методи для роз-
робки сучасного більш надійного, вдосконаленого стандартного стандарту 
шифрування. Мета полягала в тому, щоб розробити алгоритм шифрування, 
який можна використовувати як стандартний алгоритм шифрування. І цей 
алгоритм було зараховано до Федерального стандарту обробки інформації 
(далі – FIPS). Вважається, що він має достатню криптостійкість і зможе доб-
ре захистити інформацію уряду та інших організацій упродовж досить три-
валого проміжку часу. Нині цей алгоритм використовує уряд США та на до-
бровільних засадах будь-які підприємства. Крім того, цей алгоритм реалізо-
вує симетричну криптографію ключів як блоковий шифр, він підтримує ро-
зміри блоків 128 біт і розмір ключів 128, 192, 256 біт [5–8]. 

Мета статті – дослідження можливості використання вбудованих у 
СКБД Oracle та MS SQL Server криптографічних алгоримів захисту 
інформації на швидкодію, розмір даних, які отримуються після шифрування 
даних, і криптостійкість. Для тестування вбудованих алгоритмів розроблено 
спеціальний програмний додаток, за допомогою якого проводились експе-
рименти.  

Виклад основного матеріалу. В сучасній Єдиній автоматизованій ін-
формаційній системі митних підрозділів Державної фіскальної служби 
України використовуються СКБД ORACLE та MS SQL Server. 

У СКБД Oracle та MS SQL Server наявні такі алгоритми шифрування 
даних: DES, DES3, AES. Для реалізації цих алгоритмів використовується 



 

            ISSN 2521-6643                     Системи та технології, № 1 (57), 2019 212 111 

пакет DBMS_CRYPTO. Опис функцій, що зараховуються до пакета, подано 
в табл. 1. Пакет DBMS_CRYPTO надає тільки одну функцію для шифруван-
ня даних, саме тому тип шифрування зазначається в параметрі. Алгоритми 
шифрування, що підтримуються, та відповідні їм функції подано в табл. 1. 
Необхідна константа задається у форматі ім’я_пакета.ім’я_функції. Наприк-
лад, щоб обрати алгоритм Triple DES, слід використовувати функцію 
DBMS_CRYPTO.ENCRYPT_3DES.  

 
Таблиця 1 

 
Алгоритми шифрування пакета DBMS_CRYPTO 

 

Ім’я_функції Опис Довжина 
ключа, Bit 

ENCRYPT_DES Data Encryption Standard (DES) 56 
ENCRYPT_3DES_2KEY Modified Triple Data Encryption Standard 

обробляє кожен блок  
тричі, використовуючи 2 ключі 

112 

ENCRYPT_3DES Triple Data Encryption Standard (3DES); 
обробляє кожен блок тричі 156 

ENCRYPT_AES128 Advanced Encryption Standard 128 
NCRYPT_AES192 Advanced Encryption Standard 192 
ENCRYPT_AES256  Advanced Encryption Standard  256 
ENCRYPT_RC4 Потокове шифрування  

 
Під час застосування пакета слід обрати алгоритм шифрування, задав-

ши відповідне значення параметра typ. Під час шифрування даних кожен 
блок, який зашифровується, може бути зашифрований незалежно від інших 
або зчеплений з іншими для створення більш надійної (з погляду крипто-
графії) системи. В останньому випадку зашифроване значення краще захи-
щено. Щоб обрати метод зчеплення, слід зазначити відповідну константу з 
табл. 2 у значенні параметра typ, наприклад DBMS_CRYPTO.CHAIN_OFB. 

Під час використання алгоритмів шифрування слід явно доповнити 
дані так, щоб їхня довжина була кратна розміру блоку. Однак цей підхід не є 
криптографічно надійним. DBMS_CRYPTO дає змогу вказати необхідний тип 
доповнення. Більшість компаній використовує метод PKCS # 5 [9]. 

Щоб обрати метод доповнень, слід зазначити відповідну константу з 
табл. 3 у значенні параметра typ, DBMS_CRYP TO.PAD_PKCS5. 

 



 

            ISSN 2521-6643                    Системи та технології, № 1 (57), 2019 212 112 

Таблиця 2 
 

Типи зчеплень DBMS_CRYPTO 
 

Константа Опис 
CHAIN_CBC  Зчеплення блоків шифротексту – Cipher Block Chaining  
CHAIN_ECB Електронна книга кодів – Electronic Code Book 
CHAIN_CFB Шифрування зі зворотним зв’язком від шифротексту – 

Cipher Feedback 
CHAIN_OFB  Шифрування зі зворотним зв’язком за виходом – Output 

Feedback 
 

Таблиця 3 
Типи доповнення DBMS_CRYPTO 

 

Константа Опис 

PAD_PKCS5  Доповнення засобами криптографічної системи із  
загальним ключем (Public Key Cryptography System # 5) 

PAD_ZERO Доповнення нулями 
PAD_NONE Відсутність доповнення. Використовується в разі 

впевненості в тому, що довжина даних уже кратна 
розміру блоку, що зашифровується (кратно 8) 

 
Нині на митних постах для митного оформлення використовується 

ПІК “Інспектор 2006”, тому дані зберігаються у СКБД MS SQL Server. У 
СКБД MS SQL Server для шифрування даних використовуються вбудовані 
процедури PL/SQL, які послуговуються такими ж алгоритмами, що й у 
СКБД Oracle (рис. 1).  

Проаналізувавши інформаційну систему митних підрозділів, було ви-
явлено, що незаконний доступ до даних може отримати зловмисник під час 
передання інформації до ЦБД, а також адміністратор БД, який має доступ до 
незашифрованих даних, що зберігаються в БД. Для захисту даних слід за-
стосувати шифрування. Шифрування даних не розв’язує проблему контро-
лю доступу, однак значно підвищує безпеку збереження даних, адже до них 
не матимуть доступу всі рівні адміністраторів (рис. 3). Наприклад, якщо 
сервер центральної бази даних було неправильно налаштовано, і хакер зміг 
отримати доступ до даних, то вкрадені дані не матимуть ніякої цінності, як-
що вони зашифровані. 



 

            ISSN 2521-6643                     Системи та технології, № 1 (57), 2019 212 113 

 

Зловмисник

 

БД 

Інспектор 2006

 

БД 

Обласна митниця

 

БД 

Центральна БД

Адміністратор БД митниці
Адміністратор ЦБД

 
 

Рис. 1. Перехоплення секретної інформації зловмисником 
 

Хоча шифрування – надійний засіб захисту даних, його не слід засто-
совувати щодо всіх даних, тому що під час шифрування суттєво збільшу-
ються обсяг даних і навантаження на процесор сервера. Коли вирішується, 
чи потрібно шифрувати дані, слід оцінити, чи можуть отримати доступ до 
комп’ютерної мережі зловмисники. Якщо користувачі отримують доступ до 
даних через загальнодоступну мережу, для збільшення безпеки може знадо-
битися шифрування даних. Однак, якщо для доступу передбачено безпечну 
конфігурацію інтрамережі, шифрування може не знадобитися. Будь-яке ви-
користання шифрування також має містити стратегію обслуговування паро-
лів, ключів і сертифікатів. 

MS SQL Server дає змогу адміністраторам і розробникам обирати з де-
кількох алгоритмів, зокрема DES, Triple DES, TRIPLE_DES_3KEY, RC2, 
RC4, RC4 зі 128-розрядним ключем, DESX, AES зі 128-розрядним ключем, 
AES зі 192-розрядним ключем і AES із 256-розрядним ключем [9]. 

Якщо для шифрування даних на митних постах використовується MS 
SQL Server, а в ЦБД Oracle 11g, то потрібно, щоб алгоритми шифрування 
збігалися. В Oracle 11g асиметричних алгоритмів шифрування немає, їх мож-
на використовувати, якщо придбати утиліту Oracle Advanced Security. В 
табл. 4 відображено алгоритми шифрування, наявні в Oracle та в MS SQL 
Server. 

Адміністратор БД митниці Зловмисник Адміністратор ЦБД 

Інспектор 2006 Обласна митниця Центральна БД 



 

            ISSN 2521-6643                    Системи та технології, № 1 (57), 2019 212 114 

Таблиця 4 
 

Алгоритми шифрування, що збігаються 
 

Алгоритм Oracle Алгоритм MS SQL Server Довжина ключа, Byte 

DES DES 4 

Triple DES Triple DES 20 

3DES_2KEY 3DES_2KEY 14 

AES 128 AES 128 8 

AES 192 AES 192 12 

AES 256 AES 256 16 
 
Щоб виокремити алгоритми, які найдоцільніше використовувати в 

Єдиній інформаційній системі митної служби, маємо дослідити, як ці алго-
ритми працюють. 

Для проведення порівняльного аналізу запропонованих шифрів розгля-
немо їхні основні параметри: довжина ключа, кількість раундів шифрування, 
довжина оброблюваного блоку, який зашифрується, криптостійкість. 

Тепер визначимо, скільки часу забере спроба дібрати ключа до алгори-
тму. Спроба добору ключа розраховується за формулою: 

 

, 
 

де P – потужність алфавіту ключа, P = 2 (0 або 1); 
L – довжина ключа; 
V – швидкість перенабору на комп’ютері Pentium I 5 із 4 ядрами і тактовою  

частотою 2,7 GHz – приблизно  2 700 000 000  операцій за секунду,  
якщо будуть задіяні всі чотири ядра, то швидкість перенабору буде в  
4 рази більшою; 

n – коефіцієнт переведення, секунд за дні, n = 3 156 000; 
Значення розрахованих параметрів для криптоалгоритмів DES, AES по-

дано в табл. 5. 
 



 

            ISSN 2521-6643                     Системи та технології, № 1 (57), 2019 212 115 

Таблиця 5 
 

Параметри криптостійкості алгоритмів 
 

Алгоритм Довжина  
ключа, Bit 

Кількість  
перенаборів 

для розшифрування 

Кількість  
років для  

добору ключа 
DES 56 256 2,11 
Triple DES 168 2168 1,1*1034 
AES 128 128 2128 1*1022 
AES 192 192 2192 1,8*1041 
AES 256 256 2256 3,4*1064 

 
Як бачимо з табл. 5, жоден із алгоритмів неможливо зламати шляхом 

добору ключа, однак найбільш незахищеними алгоритмами є DES та AES 
128. Але й для цих алгоритмів спроба зламати алгоритм шляхом добору 
ключа забере дуже багато часу. 

Для оцінювання швидкодії роботи алгоритмів було розроблено про-
грамний додаток, що працює за певним алгоритмом (рис. 2). 

 

вибір таблиці яка підлягає шифруванню

шифрування даних

Збереження даних

Вихід

*

*

-Дослідник

*

-Система 

*

введення  ключа

вибір алгоритму шифрування

час початку шифрування

фіксація операції

час закінчення процесу шифрування

Вхід

 
 

Рис. 2. Алгоритм роботи програмного додатка 

вибір таблиці, яка підлягає шифруванню 



 

            ISSN 2521-6643                    Системи та технології, № 1 (57), 2019 212 116 

Дослідник обирає таблицю, тип алгоритму, який застосовуватиметься 
для шифрування, потім генерується ключ, далі обирається для шифрування 
зазначений стовпець із певним типом даних, який потрібно зашифрувати. Під 
час роботи додатка запам’ятовується ts  – час початку шифрування, tf  – час 
закінчення шифрування. Різницю між часом початку та закінченням шифру-
вання називаємо швидкодією обраного алгоритму: Tcr  = ts – tf. Коли дані буде 
зашифровано за допомогою вбудованих алгоритмів, експортуємо таблицю, в 
якій шифрували дані, й оцінюємо, наскільки збільшився розмір таблиці після 
шифрування. 

Для генерації ключів використовується така процедура над вхідними 
даними, що є довжиною ключа шифрування. 

CREATE OR REPLACE procedure  
 genkey (pl  IN PLS_INTEGER, key out raw) 
IS 

BEGIN 
key := dbms_crypto.randombytes (pl); 

END genkey; 
 
Для генерації ключа застосовується функція RANDOMBYTES із пакета 

DBMS_CRYPTO. 
Для шифрування даних у СКБД Oracle  використовується пакет 

DBMS_CRYPTO з функціями для шифрування даних. Для зручності в роботі 
з цим пакетом розробляємо функцію шифрування, алгоритм якої зображено 
на рис. 3. Вхідні дані у функцію – це назва алгоритму шифрування і стов-
пець із таблиці, який підлягає шифруванню. Оскільки вбудовані в пакет функ-
ції шифрування працюють тільки з даними у форматі RAW, то спочатку фу-
нкція дані зі стовпця перетворює на формат RAW, потім шифрує, після чого 
перетворює на формат CHAR і перезаписує вже зашифровані дані в табли-
цю. Функція для розшифрування даних працює аналогічно, тільки замість функції 
DBMS_CRYPTO.encrypt викликається функція DBMS_CRYPTO.dencrypt для 
розшифрування даних (рис. 3).  

Для дослідження роботи системи створюємо програмний додаток на 
мові C#. У проведенні дослідження використовуватимемо таблицю, яка є в 
демо БД Oracle 11, – це ";"""date"",""2019-06-26T07:32:54Z""
""pdf:PDFVersion"",""1.5""
""xmp:CreatorTool"",""Acrobat PDFMaker 11 для Word""
""pdf:docinfo:title"",""В""
""Company"",""""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""uk""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""Acrobat PDFMaker 11 для Word""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""В""
""xmp:CreateDate"",""2019-06-26T10:32:52Z""
""modified"",""2019-06-26T07:32:54Z""
""pdf:docinfo:custom:SourceModified"",""D:20190624090347""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""true""
""xmp:ModifyDate"",""2019-06-26T10:32:54Z""
""pdf:docinfo:creator"","" ""
""meta:author"","" ""
""meta:creation-date"",""2019-06-26T07:32:52Z""
""created"",""2019-06-26T07:32:52Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-06-26T07:32:52Z""
""resourceName"",""7%20%D0%9A%D0%B0%D0%B1%D0%B0%D0%BA%20%D0%9B.%20%D0%92..pdf""
""pdf:docinfo:custom:Comments"",""""
""Author"","" ""
""producer"",""Adobe PDF Library 11.0""
""pdf:docinfo:producer"",""Adobe PDF Library 11.0""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"","" ""
""dcterms:created"",""2019-06-26T07:32:52Z""
""Last-Modified"",""2019-06-26T07:32:54Z""
""dcterms:modified"",""2019-06-26T07:32:54Z""
""title"",""В""
""xmpMM:DocumentID"",""uuid:395428ee-deb3-4438-8ade-9e8c25f9f52b""
""Last-Save-Date"",""2019-06-26T07:32:54Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2019-06-26T07:32:54Z""
""meta:save-date"",""2019-06-26T07:32:54Z""
""Content-Length"",""443735""
""Content-Type"",""application/pdf""
""xmp:MetadataDate"",""2019-06-26T10:32:54Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"","" ""
""dc:language"",""UK""
""pdf:producer"",""Adobe PDF Library 11.0""
""dc:subject"",""""
""Comments"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""17""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""1826"",""2920"",""2864"",""2737"",""1935"",""1710"",""1635"",""1233"",""1023"",""2171"",""334"",""694"",""716"",""593"",""2123"",""2518"",""2137""
""access_permission:extract_content"",""true""
""pdf:docinfo:custom:Company"",""""
""access_permission:can_print"",""true""
""SourceModified"",""D:20190624090347""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-06-26T07:32:52Z""
";https://scholar.google.com/scholar?start=590&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094668-1187;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[CITATION][C] (Draft) A Taxonomic Approach to Understanding Emerging Blockchain Identity Management Systems;L Lesavre ;2019;;null;Autres articles;;null;;;;https://scholar.google.com/scholar?start=410&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094640-1080;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Trusted D2D-based IoT resource access using smart contracts;VA Siris, D Dimopoulos, N Fotiou… ; 2019 IEEE 20th …, 2019  ieeexplore.ieee.org;;"… We describe two approaches for utilizing blockchains and smart contracts in the authorization

process: in the first approach, only hashes of the authorization information are recorded on the

blockchain … However, it does not interact directly with the blockchain …";Cité 4 fois;Les 10 versions;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/8785898/8792923/08793041.pdf?casa_token=xFundQyHuPYAAAAA:8iEvdEus9xcSsZcUvVo639xGSREBWGjO0FxeWX-Ngs65Hw7_8My56ho5jNRAKJbaUzK7AJFtkmE;"
		Skip to Main Content


		
			
				
				

				

			

		


		
			
				
					
						








	
		
	

	







						

						





























	
	
		
	
	
		
			

		
	

	
	
	



						





	
	
		
			
				IEEE Account

					Change Username/Password
	Update Address


			

			
				Purchase Details

					Payment Options
	Order History
	View Purchased Documents


			

			
				Profile Information

					Communications Preferences
	Profession and Education
	Technical Interests


			

			
				Need Help?

					US & Canada: +1 800 678 4333
	Worldwide:  +1 732 981 0060

					
	Contact & Support


			

		

		
			
				
					
							About IEEE Xplore
	Contact Us
	Help
	Accessibility
	Terms of Use
	Nondiscrimination Policy
	Sitemap
	Privacy & Opting Out of Cookies


						
							A not-for-profit organization, IEEE is the world's largest technical professional organization dedicated to advancing technology for the benefit of humanity.
Š Copyright 2021 IEEE - All rights reserved. Use of this web site signifies your agreement to the terms and conditions.
						

					


					

				

				
			

		

	


	
	


						
						






		
		
		
		
		
		
		
		
		
		
		
		
		
			
				
			
			
			
			
		
		
		
		
		
		

			


			

			
			


		
 		
		
			 

						
						









































	

		
		

		
		
		

		
			
		
		
		

		

		
		


		

		
		
		
		
		
		
		
		
		
		
	
	


















		
		
			
				
					
					
								
					
								
			
				
					
					
								
					
								
			
				
					
						








 



					
					
								
			
				
					
					
								
			
				
					
					
								
					
								
			
				
					
					
								
					
								
			
				
					
					
								
					
								
			
				
					
					
								
					
								
			
				
					
					
								
					
								
			
				
					
					
								
					
								
			
		
	




























		
			
					
			
					
			
					
			
				
					








					
			
					
			
					
			
					
			
					
			
					
			
					
			
		
		
	





	
	
	
	
	
	
	


	
	
	

	

















					

				

			


			
				
			
		

	";"""og:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""twitter:title"",""Trusted D2D-Based IoT Resource Access Using Smart Contracts""
""twitter:card"",""summary""
""Description"",""We present and evaluate models that allow clients to access IoT resources using secure and trusted device-to-device (D2D) communication, while utilizing smart c""
""og:title"",""Trusted D2D-Based IoT Resource Access Using Smart Contracts""
""resourceName"",""08793041.pdf""
""language"",""en""
""title"",""Trusted D2D-Based IoT Resource Access Using Smart Contracts | IEEE Conference Publication | IEEE Xplore""
""og:description"",""We present and evaluate models that allow clients to access IoT resources using secure and trusted device-to-device (D2D) communication, while utilizing smart contracts to obtain the benefits of blockchain technology. These benefits include decentralized trust, immutability, transparency, and high availability. The models consider different network connection capabilities of the clients and the IoT resources, namely continuous network connectivity and D2D-only connectivity. We describe two approaches for utilizing blockchains and smart contracts in the authorization process: in the first approach, only hashes of the authorization information are recorded on the blockchain. In the second approach, a smart contract handles authorization requests. We implement the approaches using the OAuth 2.0 delegated authorization framework and evaluate the implementations on the public Ethereum testnet Rinkeby, in terms of execution cost, contract creation cost, and delay. Our evaluation quantifies the tradeoffs of blockchain cost and smart contract functionality, such as blocking and non-blocking operation, and the reduction of the transaction cost that can be achieved when multiple authorization requests are concatenated in a single transaction.""
""twitter:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-UA-Compatible"",""IE=Edge""
""viewport"",""width=device-width, initial-scale=1.0""
""dc:title"",""Trusted D2D-Based IoT Resource Access Using Smart Contracts | IEEE Conference Publication | IEEE Xplore""
""twitter:description"",""We present and evaluate models that allow clients to access IoT resources using secure and trusted device-to-device (D2D) communication, while utilizing smart contracts to obtain the benefits of blockchain technology. These benefits include decentralized trust, immutability, transparency, and high availability. The models consider different network connection capabilities of the clients and the IoT resources, namely continuous network connectivity and D2D-only connectivity. We describe two approaches for utilizing blockchains and smart contracts in the authorization process: in the first approach, only hashes of the authorization information are recorded on the blockchain. In the second approach, a smart contract handles authorization requests. We implement the approaches using the OAuth 2.0 delegated authorization framework and evaluate the implementations on the public Ethereum testnet Rinkeby, in terms of execution cost, contract creation cost, and delay. Our evaluation quantifies the tradeoffs of blockchain cost and smart contract functionality, such as blocking and non-blocking operation, and the reduction of the transaction cost that can be achieved when multiple authorization requests are concatenated in a single transaction.""
""Content-Encoding"",""UTF-8""
""Content-Type-Hint"",""text/html; charset=utf-8""
""Content-Length"",""42179""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=890&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094567-769;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[PDF][PDF] Problems of World Agriculture volume 18 (XXXIII), number 4, 2018: 146–151;I Glazkova, D Kozio?;Kaczorek, S Shmatko  sj.wne.sggw.pl;;"… Risk 2. Compromising the oracles Oracle programs are specialized services designed to bind

the digital world … In this case, the Oracle will constantly assume that it is dark and, as a …

Cryptocurrency and blockchain technology in digital economy: development genesis (in Russian …";Autres articles;;[PDF] sggw.pl;http://sj.wne.sggw.pl/pdf/PRS_2018_T18(33)_n4_s146.pdf;"
Scientific Journal Warsaw University of Life Sciences – SGGW  

Problems of World Agriculture volume 18 (XXXIII), number 4, 2018: 146–151 

DOI: 10.22630/PRS.2018.18.4.105 
Irina Glazkova1, Dorota Kozio -Kaczorek2, Sergey Shmatko3 
1,3 North-Caucasus Federal University, Russian Federation 
2 Warsaw University of Life Sciences – SGGW, Poland 

Smart Contracts as a New Technology in the Digital Economy 

Abstract. Digital technologies have a number of advantages that contribute to the development 
of the economy and make it more transparent. Some of the main features of modern digital 
technologies are speeding up business processes, reducing costs, eliminating the possibility of fraud, 
ensuring the transparency of the system and the ability to check and analyze the system. Regardless of 
whether a commercial or government organization uses the technology, in any case, there is a wide 
range of possibilities of its application. One of these technologies is blockchain. A blockchain is 
a distributed database in which storage devices are not connected to a shared server. This database 
stores an ever-growing list of ordered records called blocks. Each block contains a timestamp and 
a link to the previous block. The article defines a smart contract, describes the main areas of its 
application and provides processes similar to smart contracts, but working outside the blockchain. 
We also consider some of the risks that arise when working with smart contracts. 

Key words: smart contract, cryptocurrency, blockchain 

JEL Classification: D86, G23, O16, O31 

Introduction 

Technological progress does not stand still and over the past 20 years we have 
witnessed the rapid development of the Internet, which undoubtedly influenced both our 
daily lives and ways of doing business. Mentioned technological progress include also the 
emergence of e-Commerce. 

According to the Decree of the President of the Russian Federation dated 09.05.2017 
 203 “On the Strategy of development of the information society in the Russian 

Federation for 2017 – 2030” the current system of management should be transformed into 
a digital economy. The digitalization is, for example, the key factor of production because 
processing of large volumes data in digital form and the use of such analysis results can 
significantly improve the efficiency of production, technology, equipment, storage, sale, 
delivery of goods and services. The Decree of President of The Russian Federation marked 
the beginning of intensive use of information and communication technologies by state 
bodies, business and citizens (Babkin et al., 2017). As part of this trend, the main way to 
ensure the efficiency of economic activity of the subject should be the introduction of data 
processing technologies that will reduce costs in the production of goods and services. This 

                                                 
1 PhD; Department of Business Informatics, North-Caucasus Federal University, Brusneva 13-52 St., Stavropol, 
Russian Federation, e-mail: iu.glazkova@gmail.com; https://orcid.org/0000-0001-5721-9300 
2 PhD; Department of Agricultural Economics and International Economic Relations, Faculty of Economic 
Sciences WULS-SGGW, Nowoursynowska 166 St., 02-787 Warszawa, e-mail: dorota_koziol@sggw.pl;  
https://orcid.org/0000-0001-7582-0810 
3 PhD; Department of Business Informatics, North-Caucasus Federal University, Brusneva 13-52 St., Stavropol, 
Russian Federation, e-mail: sshmatko@yandex.ru 



Smart Contracts as a New Technology in the Digital Economy     147 

requirement has determined the relevance of this paper, the purpose of which is the 
economic justification of the effectiveness of the use of distributed registers and smart 
contracts in the course of economic activities of entities. Today we are witnessing the 
development and implementation of completely new technologies that can change the 
world, as the Internet did in its time. One such technology is the technology of the 
blockchain. In this paper we present only a basic characteristic of blockchain and smart 
contracts. 

The blockchain 

For the first time, the term blockchain appeared as the name of a fully replicated 
distributed database implemented in the Bitcoin system. This explain why the blockchain is 
often referred to transactions in various cryptocurrencies, but the technology of block chains 
can be extended to any interconnected information blocks (Genkin et al., 2017). Bitcoin was 
the first application of blockchain technology in October 2008 (Iansiti et al., 2017). 

Blockchain technology ensures that data will not be changed during transmission. 
Therefore, it can find application not only in the field of Finance, but also in other areas, 
including real estate and health. However, the financial sector is, if not the most promising, 
then the most solvent source of demand for smart contracts. Many business processes in the 
industry are still accompanied by piles of related securities, which complicate doing 
business, and make up a significant share of the revenue of intermediaries. Blockchain 
offers special features that are called smart contracts. The introduction of smart contracts 
can simplify these processes, so the major players themselves have started to develop in 
this area. Smart contracts are automatically created in the system, copied to different stores, 
and executed using distributed computing. Therefore, after the execution of the smart 
contract it cannot be corrected, even if later it is found vulnerabilities. 

A smart contract is an automatically used process that provides all possible options for 
the development of events and there is no possibility of making amendments. This term 
appeared in the article of the American cryptographer Nick Szabo, which was published in 
1994. According to Nick Szabo's idea, self-executing smart contracts, first of all, must 
fulfill the specified conditions of the ""contract"", reducing the number of costs and errors 

associated with the human factor. At the same time, smart contracts should save the world 

from intermediaries who are now involved in the performance and enforcement of the 

obligation in one way or another. In addition, Nick Szabo believed that with the advent of 

smart contracts virtually disappear all sorts of fraudulent transactions. 

Like any other contract, a smart contract has its own objects.  

 Signatories. Signatories are parties to a smart contract that accept or waive the terms 

using electronic signatures. A direct analogue is the signature of the sender of funds in 

the Bitcoin network, which confirms the transaction in the chain of blocks (Babkin et 

al., 2017). 

 Subject of contract. The subject of the contract can only be an object within the 

environment of the smartest contract, or it must be ensured unhindered, direct access 

of the smart contract to the subject of the contract without human intervention. This is 

the most difficult issue that could not be solved before the advent of cryptocurrencies 

in 2009. 



148     I. Glazkova, D. Kozio -Kaczorek, S. Shmatko 

 Conditions. The terms of the smart contract must have a full mathematical description, 

which can be programmed in the environment of the smart contract. It is 

in the conditions described the logic of execution of the points of the subject of the 

contract. 

A prerequisite for such contracts is the existence of a specific execution environment. 

Certain conditions are required: 

 The use of widespread electronic signature methods based on public and private keys 

(asymmetric encryption). 

 Existence of open, decentralized and trusting databases for executed transactions, the 

operation of which completely excludes the human factor. As an example: blockchain 

in Bitcoin. 

 Decentralization of the smart contract execution environment. As an example: 

Ethereum, Codius, Counterparty. 

 Reliability of the digital data source. As an example: root SSL certification authorities 

in databases of modern Internet browsers. 

A smart contract can update the data in the blockchain in accordance with the initially 

set rules — for example, transfer digital assets from one participant to another. As soon as 
the new technology gains momentum, smart contracts will make a real digital revolution, 
which will be comparable to the invention of HTML, which radically changed the Internet, 
and later the entire world economy. 

Proponents of smart contracts argue that many of their types can be made partially or 
completely self-executing and self-sufficient. Smart contracts based on cryptography can 
provide better security than traditional contracts based on the law, and reduce other 
transaction costs associated with the conclusion of contracts and possible legal costs. 

According to the British magazine The Economist, smart contracts have the prospect 
of becoming the most important application of blockchain technology (Genkin et al., 2017). 

The use of smart contracts in their activities helps various companies in many areas of 
life to simplify their activities. For example, the R3 consortium, which includes 45 large 
financial institutions, is developing in the field of blockchain application in the financial 
industry. More than 15 participating banks have developed prototypes of smart contracts 
for factoring operations, providing participants with the opportunity to see the data on 
transactions in real time. At the same time, in parallel, banks are also conducting their 
internal development: 

 Barclays uses smart contracts to automate the payment and the change of right to 
possession during the transaction. 

 HSBC and Bank of America replaced letters of credit with smart contracts (written 
guarantee from the payer's Bank to the payee's Bank) (Golikova et al., 2017). 
In Russian Federation, the technology has also been developed. Last year, Alfa-Bank 

and S7 conducted the first financial transaction using blockchain in Russia. Two smart 
contracts were used at once-for opening and execution (closing) of the letter of credit. 
Interacting with each other smart contracts are designed to reduce the negative 
consequences of a potential error in the code of one of them. 

Smart contracts are quite seriously considered as an alternative to existing exchanges 
for transactions with securities. Given the fact that securities are currently virtually all 
virtualized and exist only in the form of electronic registers, the transfer of securities 
trading to the blockchain is only a matter of time. 



Smart Contracts as a New Technology in the Digital Economy     149 

As an example, we will give the first transaction with securities in Russia with the use 
of smart contracts in the blockchain, held on September 29, 2017. This transaction was 
carried out by ÂŤNational settlement DepositoryÂť and consisted of execution of 
Raiffeisenbank's order to purchase MegaFon bonds (Butenko, 2014). 

The use of smart contracts is now possible in theory even in the election system. 
According to experts, it is almost impossible to falsify the election results, but thanks to 
smart contracts, it is possible to completely exclude the possibility of external interference 
in the voting system. In such a case, the votes would be placed in a distributed register and 
would require exceptional computing power to decode them. There are no such computers, 
so it will be impossible to hack this system. 

The full implementation of smart contracts in the election system is not yet a prospect 
for the nearest future. However, public services are already working hard on the most 
obvious advantage of the blockchain – reliable storage of documents. Thus, the Swedish 
cadastral service (Lantmäteriet), together with ChromaWay blockchain startup, Kairos 
Future consulting firm and Telia mobile provider, is working on its own blockchain 
solution. It is designed to eliminate errors related to manual data entry and improve the 
reliability of document transmission. At the same time, digital documentation of the 
transfer of real estate to the property is carried out with the help of the developed 
ChromaWay system of smart contracts. 

Since 2017, Moscow has been testing a blockchain platform for voting on urban 
governance issues in the Active citizen system. Russian Prime Minister Dmitry Medvedev 
believes that the emergence of distributed Ledger technology can have long – term 
consequences: ÂŤin a few years, cryptocurrencies may disappear, and the technology on the 
basis of which they develop – the blockchain will become part of everyday reality». 

Smart contracts certainly have their advantages. The advantages of this type of 
contract are as follows: 

 The safety. The smart contract is encrypted and stored in a distributed manner, which 
guarantees protection against loss or unauthorized modification. 

 The cheapness and speed. Most processes are automated, and most intermediaries are 
eliminated from the process. 

 The standardization. Today, there are many options for smart contracts, and you can 
choose the right one for a specific task. 

The risk of smart contracts 

However, despite its power and attractiveness, smart contracts are a source of risks. 
An only few types of risk is considered bellow.  

Risk 1. Errors in the development of smart contracts 

The rules of writing smart contracts are not formalized at the moment, but the main 
thing is that the rules of their verification are not described. However, it is not possible to 
make changes to the smart contract because it is by definition immutable.  

The simplest example: a smart contract is concluded, under the terms of which the 
buyer reserves the amount to transfer money when the goods arrive at the warehouse. But 
the program code of the smart contract was written with an error — the procedure for 
checking the receipt of goods to the warehouse was not implemented. As a result, the 



150     I. Glazkova, D. Kozio -Kaczorek, S. Shmatko 

money paid by the buyer, but the seller will never get, regardless of whether he delivered 
the goods or not delivered. Money for the seller lost. Especially carefully should be 
developed and smart contracts should be tested at ICO (Biswas et al., 2016). 

Risk 2. Compromising the oracles 

Oracle programs are specialized services designed to bind the digital world to the real 
world and provide smart contracts with input data for their execution. The question of the 
immutability and authenticity of the data received from these services. 

For example, an attacker could attack an Oracle that provides currency exchange rate 
data for currency exchange contracts. After changing its code, it will produce incorrect 
data, which entails quite specific financial risks for smart contracts that use this data. 

You can also replace the information or modify the physical information that comes to 
the entrance of the Oracle. The simplest example is to cover with a light-proof object the 
sensor of the Oracle transmitting information about the illumination to the smart contract of 
the ""Smart city"". In this case, the Oracle will constantly assume that it is dark and, as a 
result, the smart contract will not extinguish street lights. 

Risk 3. The loss of access 

All work with the blockchain is based on the fact that you can authorize yourself in the 
system only using the private part of the cryptographic key. If, in the case of ordinary 
contracts, transactions, etc., it is possible to authorize with the help of third parties (court, 
authorities issuing documents, notary, recommendations, etc.), in the case of blockchain 
and smart contracts, such a possibility is not provided. If the private part of the key is lost, 
you will never be able to recover it. 

Risk 4. Lack of legal framework 

Non-performance of a normal contract in the real world may be subject to legal 
proceedings. The world of blockchain is currently not an object of the legal field. All 
transactions conducted within the framework of smart contracts are provided only by the 
good will of the participants. 

Risk 5. No possibility of risk insurance 

Due to the fact that at the moment the legal field when working with the blockchain is 
not defined, there is no risk insurance in this market. In the event of any risk events with 
a smart contract, all financial consequences are entirely borne only by its participants. 

Summary 

Blockchain systems, as well as smart contracts, are good for ensuring interaction of 
subjects without using intermediaries, but their life is limited by the appearance of artificial 
intelligence. After the birth of a developed, devoid of feelings and interest in artificial 
intelligence, a place as an arbitrator and Trustee will be occupied by him.  

Thus, as a result of the analysis of the use of smart contracts by business entities and 
evaluation of its result, it can be concluded that this mechanism has a positive impact on the 
competitiveness of any business entity, as cost reduction increases the potential and 
sustainability of the organization. In other words, as a result of reducing costs on the above 
grounds, the organization will be able to effectively use the available funds for the 
expansion of economic activities, which will lead to an increase in profits. 



Smart Contracts as a New Technology in the Digital Economy     151 

In this paper we present only a basic characteristic of blockchain and smart contracts. 
More detailed and comprehensive analyzes are in preparation. 

References 

Babkin, A.V., Burkaltseva, D.D., Pshenichnikov, W.W., Tyulin, A.S. (2017). Cryptocurrency and blockchain 
technology in digital economy: development genesis (in Russian). St. Petersburg State Polytechnical 

University Journal. Economics, 10(5), 9-22. DOI:10.18721/JE.10501. 
Biswas, K., Muthukkumarasamy, V. (2017). Securing Smart Cities Using Blockchain Technology. IEEE 18th 

International Conference on High Performance Computing and Communications; IEEE 14th International 
Conferenceon Smart City; IEEE 2nd International Conference on Data Science and Systems 
(HPCC/SmartCity/DSS), Sydney, NSW, 1392-1393. 

Butenko, E.D. (2014). Bitcoin. State and prospects of cryptocurrency development (in Russian). Finance and 

Credit, 20(23), 44-47. 
Christidis, K., Devetsikiotis, M. (2016). Blockchains and Smart Contracts for the Internet of Things. IEEE Access, 

4, 2292-2303. 
Genkin, A., Mikheev, A. (2017). Blockchain. How it works and what awaits us tomorrow. Alpina Publisher, 

Moscow. 
Golikova, O.M., Fedotova, A.I. (2017). Is it possible for cryptocurrency based on the technology of blockchain to 

solve the problem of information security in the financial sector? (in Russian). ITportal, 3, 3. 
Iansiti, M., Lakhani, K.R. (2017). The Truth About Blockchain. Harvard Business Review. January–February, 

118-127. 

For citation: 

Glazkova I., Kozio -Kaczorek D., Shmatko S. (2018). Smart Contracts as a New Technology 
in the Digital Economy. Problems of World Agriculture, 18(4), 146–151; 
DOI: 10.22630/PRS.2018.18.4.105 


";"""pdf:unmappedUnicodeCharsPerPage"",""2"",""2"",""8"",""3"",""1"",""1""
""pdf:PDFVersion"",""1.4""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dcterms:created"",""2019-01-28T18:23:06Z""
""language"",""en""
""dc:format"",""application/pdf; version=1.4""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""Content-Length"",""430426""
""pdf:hasMarkedContent"",""false""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""meta:creation-date"",""2019-01-28T18:23:06Z""
""created"",""2019-01-28T18:23:06Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""6""
""Creation-Date"",""2019-01-28T18:23:06Z""
""resourceName"",""PRS_2018_T18(33)_n4_s146.pdf""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""3460"",""3514"",""3455"",""3342"",""3323"",""1735""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""producer"",""FPDF 1.81""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""FPDF 1.81""
""pdf:docinfo:created"",""2019-01-28T18:23:06Z""
";https://scholar.google.com/scholar?start=580&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094612-960;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[PDF][PDF] Public Administration in the Age of Globalization and Emerging Technologies: From Theories to;SCB Law, B Smart Contracts, B Jeff ; UMKC LAW REVIEW, 2019  HeinOnline;;"… Oracles can enable this injection, but require a strong reputation system or governance … See Nihat

Yuva & ismail Kirba§, Directed Acyclic Graph Based on Crypto Currency Application … MICHAEL

J. CASEY & PAUL VIGNA, THE TRUTH MACHINE: THE BLOCKCHAIN AND THE …";Autres articles;;[PDF] heinonline.org;https://heinonline.org/hol-cgi-bin/get_pdf.cgi?handle=hein.journals/umkc88&section=12&casa_token=edwkPk5xPggAAAAA:kJKfQeTpRQ6Hl-xmiqfS__nMNeUom5nlYs55MS9kGbcbEz_ra0GS6dadWX5dwVYm3WTG8_c;"

 ";"""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""REFRESH"",""1; url=https://heinonline.org/HOL/Page?handle=hein.journals/umkc88&div=12&g_sent=1&casa_token=edwkPk5xPggAAAAA:kJKfQeTpRQ6Hl-xmiqfS__nMNeUom5nlYs55MS9kGbcbEz_ra0GS6dadWX5dwVYm3WTG8_c""
""Content-Encoding"",""UTF-8""
""resourceName"",""get_pdf.cgi""
""language"",""""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=770&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094541-658;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Trusted and Flexible Electronic Certificate Catalog Sharing System Based on Consortium Blockchain;C Xu, H Yang, Q Yu, Z Li ; 2019 IEEE 5th International …, 2019  ieeexplore.ieee.org;;"… D. Blockchain Method BlocNchain is a breaNthrough in distributed ledger technology and the

ledger is created, with … attacN, the signing algorithm is made available, without any restriction,

hence the oracle notation sk S … [17] Bellare M, Rogaway p. Random Oracles are practical …";Cité 1 fois;;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/9048180/9064028/09064284.pdf?casa_token=dD1W2ExGuhEAAAAA:wzigXxhe961MI0OpKVArRZ2S4VxAcpKbwZH0Z4ZOywGDjFBu1CjdOXybN7Y3SxonvQCw7lzrza8;"
		Skip to Main Content


		
			
				
				

				

			

		


		
			
				
					
						








	
		
	

	







						

						





























	
	
		
	
	
		
			

		
	

	
	
	



						





	
	
		
			
				IEEE Account

					Change Username/Password
	Update Address


			

			
				Purchase Details

					Payment Options
	Order History
	View Purchased Documents


			

			
				Profile Information

					Communications Preferences
	Profession and Education
	Technical Interests


			

			
				Need Help?

					US & Canada: +1 800 678 4333
	Worldwide:  +1 732 981 0060

					
	Contact & Support


			

		

		
			
				
					
							About IEEE Xplore
	Contact Us
	Help
	Accessibility
	Terms of Use
	Nondiscrimination Policy
	Sitemap
	Privacy & Opting Out of Cookies


						
							A not-for-profit organization, IEEE is the world's largest technical professional organization dedicated to advancing technology for the benefit of humanity.
Š Copyright 2021 IEEE - All rights reserved. Use of this web site signifies your agreement to the terms and conditions.
						

					


					

				

				
			

		

	


	
	


						
						






		
		
		
		
		
		
		
		
		
		
		
		
		
			
				
			
			
			
			
		
		
		
		
		
		

			


			

			
			


		
 		
		
			 

						
						









































	

		
		

		
		
		

		
			
		
		
		

		

		
		


		

		
		
		
		
		
		
		
		
		
		
	
	


















		
		
			
				
					
					
								
					
								
			
				
					
					
								
					
								
			
				
					
						








 



					
					
								
			
				
					
					
								
			
				
					
					
								
					
								
			
				
					
					
								
					
								
			
				
					
					
								
					
								
			
				
					
					
								
					
								
			
				
					
					
								
					
								
			
				
					
					
								
					
								
			
		
	




























		
			
					
			
					
			
					
			
				
					








					
			
					
			
					
			
					
			
					
			
					
			
					
			
		
		
	





	
	
	
	
	
	
	


	
	
	

	

















					

				

			


			
				
			
		

	";"""og:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""twitter:title"",""Trusted and Flexible Electronic Certificate Catalog Sharing System Based on Consortium Blockchain""
""twitter:card"",""summary""
""Description"",""The development of information and communication technology has influenced every dimension of society, including the way government interacts with citizens. Gov""
""og:title"",""Trusted and Flexible Electronic Certificate Catalog Sharing System Based on Consortium Blockchain""
""resourceName"",""09064284.pdf""
""language"",""en""
""title"",""Trusted and Flexible Electronic Certificate Catalog Sharing System Based on Consortium Blockchain | IEEE Conference Publication | IEEE Xplore""
""og:description"",""The development of information and communication technology has influenced every dimension of society, including the way government interacts with citizens. Government bodies at all levels across the country issued a serial of guidelines to promote e-government services' quality and efficiency which include six national standards for electronic certificates. The legal validity of electronic certificates is equal to that of paper certificates issued by authorities at provincial, autonomous regional, municipal levels and related departments. This fact will accelerate the construction of e-government to further benefit people and motivate the market. In this paper, we propose a trusted and flexible electronic certificates catalog sharing (ECCS) system based on consortium blockchain to promote the accessibility and efficiency of e-government services which take advantage of immutability and time-stamping of transaction data in blockchain. Security analysis indicates that ECCS can achieve privacy-preservation of electronic certificates and catalog against unauthorized users, integrity of electronic data and authentication of data source. In comparison with other existing schemes which also achieve electronic certificates sharing services, ECCS has better efficiency in terms of traffic loads, and can fit for all scenarios related to electronic certificates sharing.""
""twitter:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-UA-Compatible"",""IE=Edge""
""viewport"",""width=device-width, initial-scale=1.0""
""dc:title"",""Trusted and Flexible Electronic Certificate Catalog Sharing System Based on Consortium Blockchain | IEEE Conference Publication | IEEE Xplore""
""twitter:description"",""The development of information and communication technology has influenced every dimension of society, including the way government interacts with citizens. Government bodies at all levels across the country issued a serial of guidelines to promote e-government services' quality and efficiency which include six national standards for electronic certificates. The legal validity of electronic certificates is equal to that of paper certificates issued by authorities at provincial, autonomous regional, municipal levels and related departments. This fact will accelerate the construction of e-government to further benefit people and motivate the market. In this paper, we propose a trusted and flexible electronic certificates catalog sharing (ECCS) system based on consortium blockchain to promote the accessibility and efficiency of e-government services which take advantage of immutability and time-stamping of transaction data in blockchain. Security analysis indicates that ECCS can achieve privacy-preservation of electronic certificates and catalog against unauthorized users, integrity of electronic data and authentication of data source. In comparison with other existing schemes which also achieve electronic certificates sharing services, ECCS has better efficiency in terms of traffic loads, and can fit for all scenarios related to electronic certificates sharing.""
""Content-Encoding"",""UTF-8""
""Content-Type-Hint"",""text/html; charset=utf-8""
""Content-Length"",""42492""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=470&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094651-1130;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;APLICACIÓN DE CADENAS DE BLOQUES Y CONTRATOS INTELIGENTES EN INDUSTRIAS DEL ÁMBITO NACIONAL;GJ FLORES CASTRO ;2019 repositorio.usm.cl;;"… En el presente trabajo se intenta hacer un primer acercamiento investigativo de la población

universitaria chilena con respecto a las tecnologías de cadenas de bloques, también nombrada

en lo sucesivo como blockchain, ya las aplicaciones derivadas más conocidas de ésta …";;;[PDF] usm.cl;https://repositorio.usm.cl/bitstream/handle/11673/49507/3560903501219UTFSM.pdf?sequence=1;"
UNIVERSIDAD TÉCNICA FEDERICO SANTA MARÍA 

DEPARTAMENTO DE INGENIERÍA COMERCIAL 

VALPARAÍSO-CHILE 

 

 

 

 
 

 

 

APLICACIÓN DE CADENAS DE BLOQUES Y CONTRATOS INTELIGENTES EN 

INDUSTRIAS DEL ÁMBITO NACIONAL  

 

 

 

 

 

GONZALO JAVIER FLORES CASTRO 

 

 

 

 

 

MEMORIA PARA OPTAR AL TÍTULO DE: 

INGENIERO COMERCIAL 

 

 

PROFESOR GUÍA:          SR. JUAN TAPIA 

PROFESOR CORREFERENTE:   SR. LUIS ACOSTA 

 

 

NOVIEMBRE 2019 

 

 



 
 

1 

RESUMEN 

 

 

 

        En el presente trabajo se intenta hacer un primer acercamiento investigativo de la 

poblaciĂłn universitaria chilena con respecto a las tecnologĂ­as de cadenas de bloques, tambiĂŠn 

nombrada en lo sucesivo como blockchain, y a las aplicaciones derivadas mĂĄs conocidas de 

ĂŠsta, como son las criptomonedas y los contratos inteligentes. AdemĂĄs se describirĂĄn dos 

sectores especĂ­ficos, como son la industria aseguradora y el sector gubernamental, puesto que 

ĂŠstos poseen a juicio de los expertos un enorme potencial para ser transformados por esta 

tecnologĂ­a.  

     Para esto se realizarĂĄ un anĂĄlisis exploratorio que tenga en cuenta las opiniones de la 

poblaciĂłn estudiada, y bibliogrĂĄfico para describir y estudiar los casos en los que blockchain 

ya estĂĄ transformando muchos paĂ­ses en el mundo. Se finalizarĂĄ con conclusiones y 

recomendaciones asociadas a los resultados hallados. 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 



 
 

2 

ÍNDICE 

 

1. Problema de InvestigaciĂłn 4 

 

2. Objetivos 6 

 

    2.1 Objetivo General 6 

    2.2 Objetivos EspecĂ­ficos   6 

 

3. Marco TeĂłrico   7 

   

     3.1       Algunos antecedentes                                                                                            7   

     3.1.1     Bitcoin                                                                                                                  7 

  3.1.2         Ethereum                                                                                                         8   

3.1.3          Ether                                                                                                               8 

3.2      El funcionamiento y las MatemĂĄticas del Blockchain  9 

3.3. Los contratos inteligentes  11 

3.4. La mĂĄquina virtual de Ethereum (EVM) 12 

3.5. OrĂĄculo 13 

3.6. Raiden Network (RDN) 14 

 

4. MetodologĂ­a 15 

 

4.1. La Encuesta                                                                                                           16 

4.1.1            Formato Encuesta  17 

4.1.2            Beneficios y Problemas de aplicar la encuesta 21 

 

 

 

 



 
 

3 

5.       Resultados                                                                                                                    23 

 

5.1 PoblaciĂłn y Blockchain                                                                                       23 

               5.2 Áreas de InterÊs y Posibles Desarrollos                                                           25   

5.3 Sector Seguros                                                                                                     25 

 5.4 Sector Gubernamental                                                                                       27 

 5.4.1 Estonia                                                                                                            27 

5.4.2 DubĂĄi                                                                                                               28 

5.4.3 Otros PaĂ­ses                                                                                                    29 

 

6. Conclusiones y Recomendaciones                                                                                     30 

 

 

  7. Referencias                                                                                                                         32                     

 

 

 

 

 

 

 

 

 

 

 

 

  

 

 



 
 

4 

   

     1 PROBLEMA DE INVESTIGACIÓN 

 

     Desde el nacimiento de la world wide web (www) en el aĂąo 1991 internet se ha masificado 

exponencialmente, las personas tienen acceso a esta a travĂŠs de smartphones, tablets, 

computadores, en prĂĄcticamente todos los rincones del planeta, dando lugar a una 

transformaciĂłn en casi la totalidad de los sectores industriales de la economĂ­a: retail, 

financiero, inmobiliario, educacional, instituciones gubernamentales, etc. 

 

     Dada la facilidad de acceso a Internet, a crear una pĂĄgina web, o a iniciar un negocio a 

travĂŠs de esta, serĂ­a lĂłgico pensar que Internet iba a ser un espacio democrĂĄtico, con muchos 

competidores y negocios, donde individuos y empresas transaran eficazmente y todo fluyera a 

travĂŠs de la libre competencia, pero con el pasar de los aĂąos nos encontramos con que unas 

pocas empresas dominan el mercado, Google, Apple, Amazon, Facebook y Microsoft, se han 

transformado en un oligopolio contra el que es prĂĄcticamente imposible entrar a competir dada 

la cantidad de recursos que estas empresas tecnolĂłgicas poseen (El PaĂ­s, 2018), ademĂĄs de los 

ecosistemas integrados de aplicaciones que tienen cada una de ellas, siendo Internet cada dĂ­a 

mas parecido a un espacio cerrado y centralizado. 

 

     Por otro lado los sistemas de aplicaciones a travĂŠs de nodos, sistemas y servidores cerrados 

y unidireccionales, esto es un equipo informĂĄtico que brinda servicio a otros equipos 

(Pandorafms, 2019)  en donde toda persona que desee entrar a una pĂĄgina web debe conectarse 

desde de su dispositivo a un servidor central, como por ejemplo para conectarse a bancos, 

instituciones financieras, educacionales, e informaciĂłn etc, han dado lugar a errores 

informĂĄticos por parte de estas organizaciones proveedoras del servicio en cuestiĂłn, por 

ejemplo hackeos, filtraciĂłn de datos personales, filtraciones de tarjetas de crĂŠdito, pĂŠrdidas de 

informaciĂłn sensible, o derechamente estafas, algunas recordadas como la filtraciĂłn de 41 mil 

tarjetas de crĂŠdito y 13 instituciones afectadas en 2018 (Emol, 2019).   

 

     Otra clase de problemas de confiar en una instituciĂłn y servidor central es que toda la 

confianza recae en los controladores. Digamos que dejamos nuestros ahorros en manos de 



 
 

5 

terceros, esto ha llevado a apropiaciones indebidas, posibles robos, malas elecciones de 

inversiĂłn e incluso estafas piramidales en la industria financiera. Recordados casos como el de 

182 mil millones de Pesos y mĂĄs de 10 mil clientes afectados (Tele13, 2019), demandas e 

imputados varios por la justicia chilena con el destape del caso AC Inversions, a los que luego 

se sumarĂ­an otros similares como Arcano, Investing Capital, RodrĂ­guez & Asociados y una 

serie de empresas mĂĄs. Hechos varios que provocan una irremediable falta de confianza en el 

sector, siendo actualmente vender productos financieros, especialmente administrar capitales 

de terceros, considerado por muchas empresas del rubro como vender “arena en el desierto” 

debido a la poca credibilidad y desconfianza por parte de los clientes y consumidores 

(Capitaria, 2019). 

 

 

     Otros temas como los ahorros previsionales y la desconfianza de los trabajadores en como 

estos son invertidos, la gran movilizaciĂłn nacional que se ha producido en los Ăşltimos aĂąos por 

parte una parte importante de la poblaciĂłn con el movimiento de No + AFP, iniciativa popular 

en reclamo a las bajas pensiones acumuladas por las personas en Chile a lo largo de su vida 

(NomasAFP, 2019), y las comisiones cobradas por las AFPs correspondiente a un tramo entre 

el 10% y 15% aproximadamente por sobre el capital neto recaudado mensualmente de los 

trabajadores, tambiĂŠn conocido como imposiciones obligatorias, porcentaje informado como 

“porcentaje de la remuneración o renta imponible” en promedio de 1,255% por la 

superintendencia de pensiones (superintendencia de pensiones, 2019). 

 

   Todos estos  tipos de problemas observados por parte del consumidor en la industria que 

provee los bienes y servicios requeridos, y que podemos plantearlos como falta de confianza 

en la contraparte, ademĂĄs los encontramos en contratos de trabajo, compra venta y arriendos  

inmobiliarios, derechos de autor, industria agrĂ­cola y un largo etc. En otras palabras donde 

quiera que exista un acto mercantil entre partes desconocidas, existe la falta de confianza 

inherente dado los diferentes niveles de reputaciĂłn de los individuos e instituciones. AsĂ­ todas 

las industrias a dĂ­a de hoy tienen en comĂşn que requieren la intervenciĂłn humana, la cual 

provoca fraudes, ambiciĂłn, conflictos de interĂŠs, luchas de ego, y mĂĄs importante aĂşn, 



 
 

6 

derechamente robos y estafas, afectando la confianza de los consumidores como las 

anteriormente vistas. 

 

 

      AcĂĄ nos encontramos con una posible soluciĂłn, la tecnologĂ­a de cadena de bloques (en 

adelante tambiĂŠn llamada blockchain), una tecnologĂ­a capaz de descentralizar aplicaciones y 

hacer la internet democrĂĄtica, sin que las aplicaciones dependan de un organismo o servidor 

central, sino que cada uno de los usuarios es participante tanto como parte usuario como parte 

controladora, a travĂŠs de donde este conectado, ya sea un ordenador, tablet, smartphone etc. 

     Blockchain tiene la capacidad de bajar al mĂ­nimo las comisiones transaccionales, eliminar 

todo tipo de intermediarios, ademĂĄs de brindar seguridad a las inversiones y ahorros de las 

personas. Lo mismo corre para contratos de trabajo, de arriendo, inmobiliarios, contratos 

industriales etc., los cuales deben ser fidedignos, confiables y supervisados.  

     Este trabajo abordarĂĄ y darĂĄ una descripciĂłn detallada de cĂłmo se pueden minimizar las 

altas comisiones monetarias, costos burocrĂĄticos y ademĂĄs quĂŠ industrias de servicios podrĂ­an 

ser transformadas, en distintos sectores del paĂ­s, aumentando la transparencia, productividad, 

bajando los costos, reduciendo las tasas de espera, como por ejemplo en: altas tasas de interĂŠs 

financiero para la poblaciĂłn, burocracia de contratos, de notarios pĂşblicos, de conservadores 

de bienes raĂ­ces, industrias con muchos intermediarios, acceso al crĂŠdito, corredores de 

propiedades, seguridad general etc. AdemĂĄs mediremos cuantitativamente cuĂĄl es el nivel de 

conocimiento de la poblaciĂłn respecto a tecnologĂ­as de cadena de bloques y sus aplicaciones 

derivadas, como contratos inteligentes, criptomonedas, etc, a fin de hacer un diagnĂłstico de 

quĂŠ tan preparados estĂĄn los profesionales del paĂ­s respecto a las tecnologĂ­as que se empiezan 

a usar con mayor fuerza en el planeta. 

 

 

     En general se referirĂĄ a los sectores de bienes y servicios que podrĂ­an quedar obsoletos en 

el futuro bajo el supuesto de implementar tecnologĂ­a blockchain y contratos inteligentes, y 

como los costos de estas industrias podrĂ­an en teorĂ­a ser prĂĄcticamente cero, con nula 

burocracia, sin comisiones de por medio y con total autonomĂ­a desde el instante inicial. 

 



 
 

7 

 

 

2 OBJETIVOS 

 

           

2.1 Objetivo General 

     Explorar nivel de familiarizaciĂłn  de la poblaciĂłn respecto a tecnologĂ­a de cadenas de 

bloques y describir sus utilizaciĂłn en industrias y paĂ­ses, a travĂŠs de una investigaciĂłn 

exploratoria con informaciĂłn disponible y recopilada, para reseĂąar industrias que podrĂ­an ser 

transformadas o creadas a nivel paĂ­s. 

.  

 

 

        2.2 Objetivos EspecĂ­ficos 

1. Describir el nivel de conocimiento del segmento universitario y profesional de la 

poblaciĂłn Chilena respecto al blockchain, a travĂŠs de encuestas, para reseĂąar el nivel 

educativo de las personas respecto a esta tecnologĂ­a en su posible implementaciĂłn . 

 

2. Explorar y describir el interĂŠs y atracciĂłn de la poblaciĂłn encuestada, en tecnologĂ­a 

blockchain y criptomonedas a travĂŠs de la encuesta, para seĂąalar posibles nuevas ĂĄreas 

de interĂŠs en este mercado en la actualidad.  

 

3. Analizar percepciones actuales del sector industrial de aseguradoras y sector 

gubernamental en Chile, a travĂŠs de encuestas y bibliografĂ­a, para describir cĂłmo se 

benefician estos sectores con tecnologĂ­a de cadenas de bloques. 

 



 
 

8 

3 Marco TeĂłrico 

 

3.1 Algunos antecedentes 

 

 

       3.1.1 Bitcoin 

 

       

       Hace 10 aĂąos atrĂĄs, aĂąo 2009 nace el proyecto llamado bitcoin, una moneda o activo digital 

que usa dĂŠcadas de estudios referentes a criptografĂ­a y se sustenta en la tecnologĂ­a de 

blockchain o cadena de bloques, difĂ­cilmente falsificable y semejante a un gran libro contable, 

pĂşblico y distribuido en el que queda reflejado el histĂłrico de todas las transacciones 

(Investopedia, 2019). 

 

     Siendo la cadena de bloques, una estructura de datos en la que la informaciĂłn contenida se 

agrupa en conjuntos o bloques, a los que se les aĂąade informaciones relativas a otro bloque de 

la cadena anterior en una lĂ­nea temporal, de manera que gracias a tĂŠcnicas criptogrĂĄficas, la 

informaciĂłn contenida en un bloque solo puede ser repudiada o editada modificando todos los 

bloques posteriores. Esta propiedad permite su aplicaciĂłn en entorno distribuido de manera 

que la estructura de datos blockchain puede ejercer de base de datos pĂşblica no relacional que 

contenga un histĂłrico irrefutable de informaciĂłn (Economist, 2011). 

 

     AdemĂĄs, el bitcoin se caracteriza por ser descentralizado, es decir, no estar respaldado por 

ningĂşn gobierno o entidad centralizada, como un banco central por ejemplo. Y utiliza un 

sistema de prueba de trabajo para impedir el doble gasto, esto es, que la moneda sea utilizada 

varias veces. A modo de ejemplo en un acto de mala fe, un usuario trata de enviar bitcoins a 2 

direcciones destinatarias (billeteras) distintas con el fin de gastar la misma moneda 2 veces 

(Queesbitcoin, 2016), esto serĂ­a impedido por la prueba de trabajo que imposibilita esta 

prĂĄctica. 



 
 

9 

 

       Bitcoin estĂĄ concebida desde sus orĂ­genes como una moneda digital, que permite realizar 

transacciones entre usuarios de nivel global a mĂ­nimos costos, por ejemplo la comisiĂłn de una 

transacciĂłn de envĂ­o de dinero, o de compra venta a travĂŠs de bitcoin puede costar tan sĂłlo 0,5 

USD (bitcoinfees, 2019), a diferencia del 1,49% + IVA, valor mĂĄximo que cobra transbank 

por utilizar su servicio de compras con tarjeta de dĂŠbito bancarias a la mayorĂ­a de PYMES del 

paĂ­s (Transbank, 2019).  

    

 

 

3.1.2 ETHEREUM 

 

     Por otro lado, Ethereum, organizaciĂłn fundada el aĂąo 2014, pretende ser una plataforma de 

desarrollo en sĂ­ misma, ĂŠsta representa una plataforma descentralizada que corre contratos 

inteligentes, los cuales son describidos como aplicaciones que funcionan y corren bajo un 

entorno computacional exactamente como fueron programadas, sin ninguna posibilidad de 

fraude, censura, o interferencia de terceras partes. AdemĂĄs Ethereum posee su propia 

criptomoneda en sĂ­ llamada Ether, la cual funciona como un Token, similar a un combustible, 

para recompensar a las partes que firman un contrato inteligente (Bitcoinist, 2019). 

     

     Ethereum fue concebida inicialmente por Vitalik Buterin, durante el aĂąo 2013, el cual 

definió a Ethereum como una “combinación de una red descentralizada de minería digital y 

una plataforma de desarrollo de software”, que facilita la creación de nuevos sistemas 

criptomonetarios que comparten una sola cadena de bloques (un registro pĂşblico criptogrĂĄfico 

de transacciones). (Futurethinkers, 2015) 

 

     Ethereum siguiĂł los pasos de la tecnologĂ­a previamente utilizada por Bitcoin y mejorĂł 

considerablemente sus capacidades. Se trata de una red que posee navegador de Internet, 

sistema de pago y lenguaje codificado, permitiendo a los usuarios la creaciĂłn de sus propias 

aplicaciones descentralizadas de Ethereum en Blockchain.  



 
 

10 

     AdemĂĄs, Ethereum se rige bajo un cĂłdigo de programaciĂłn abierto, esto es el software de 

cĂłdigo abierto que es producto de la colaboraciĂłn de infinidad de personas, es compartido 

libremente, se publica de manera transparente y se desarrolla para ser una comunidad en lugar 

de ser propiedad o negocio de una sola compaùía o ente (bitcoin.es, 2019). 

 

3.1.3 ETHER 

      

     El Ether consiste en un token cuya cadena de bloques es generada bajo la plataforma de 

Ethereum, el Ether puede ser transferido entre cuentas y usado para compensar a los nodos 

mineros participantes para los cĂĄlculos realizados, ademĂĄs es un sĂ­mbolo fundamental para el 

funcionamiento de Ethereum, que por lo tanto proporciona un libro mayor pĂşblico distribuido 

para las transacciones. El Ether es una unidad de cĂłmputo utilizada en transacciones y otras 

transiciones de estado, y por error entre el pĂşblico muchas veces se confunde el Ether con la 

misma red Ethereum,, siendo que esta Ăşltima es la plataforma bajo la que corre el Ether 

(Tapscott, 2016)  . 

 

     Algunas diferencias con Bitcoin es que el nĂşmero mĂĄximo de ĂŠstos se sitĂşa en 21 millones 

de unidades de Bitcoins, que serĂĄ alcanzado en un determinado momento y que bajo complejos 

algoritmos basados en criptografĂ­a controlan la oferta disponible (Investopedia, 2019), 

mientras que el suministro de Ether podrĂ­a ser infinito. En materia de minerĂ­a, los bloques de 

Bitcoin duran aproximadamente 10 minutos en ser minados y Ethereum ha marcado como 

objetivo mĂĄximo unos 12 segundos. Esto se traduce en que Ethereum tendrĂĄ validaciones mĂĄs 

veloces que las de Bitcoin. Ethereum es de momento, la segunda moneda criptogrĂĄfica mĂĄs 

grande del mundo detrĂĄs de Bitcoin, ha sufrido un crecimiento mayor y mucho mĂĄs rĂĄpido que 

ĂŠste, y se estĂĄ utilizando cada vez mĂĄs en el planeta (myethereum, 2019) 

 

 

3.2 El funcionamiento y las MatemĂĄticas del Blockchain 

 

 



 
 

11 

     El primer elemento del blockchain son los llamados bloques y luego el hash.  Los bloques 

son ficheros, normalmente de texto que contienen la informaciĂłn que se requiera guardar, 

forman una cadena ya que cada bloque tiene informaciĂłn sobre el bloque anterior, ĂŠste a su 

vez sobre el bloque anterior y asĂ­ sucesivamente hasta el primer bloque, de ahĂ­ yace su nombre 

de “blockchain” o lo que en castellano es “cadena de bloques”.  

     El hash es la informaciĂłn que cada bloque tiene sobre el bloque anterior y es un cĂłdigo o 

nĂşmero de serie matemĂĄtico, y que ademĂĄs posee toda la informaciĂłn encriptada. 

 

     El segundo elemento del blockchain es la red de ordenadores, todos los ordenadores de la 

red guardan una copia exacta de la cadena de bloques, lo que quiere decir que no existe un solo 

servidor u ordenador que guarde por si solo toda la informaciĂłn como sucede con los servidores 

de bases de datos tradicionales. En este sentido, todo aquel que funcione como un nodo, es 

decir personas que ocupan sus ordenadores, tablets o telĂŠfonos inteligentes, tienen una copia 

exacta de la informaciĂłn, lo que hace imposible que esta se pierda y hacen de la blockchain 

una red descentralizada, lo cual hasta ahora ha marcado su gran ĂŠxito.  

      

     Veamos como ejemplo el funcionamiento del bitcoin, criptomoneda pionera que usa la 

cadena de bloques desde su comienzo. El software de bitcoin es la red de ordenadores, tablets, 

smartphones etc que tienen este propio software instalado y por lo tanto descentralizado. 

AdemĂĄs es software libre, de cĂłdigo abierto, y la cadena de ficheros de bitcoin contiene todas 

y cada una de las transacciones de bitcoin de la historia. AsĂ­ por ejemplo, leyendo esta cadena 

de bloques se puede saber cuĂĄntos bitcoin tiene cada usuario y de dĂłnde han salido. Y cada 

bloque o fichero de la cadena de bitcoin contiene el hash de su bloque anterior seguido de una 

lista de transacciones. 

       

     El tercer elemento del blockchain es la prueba de trabajo, es una incĂłgnita (se denominarĂĄ 

“X”) y los llamados mineros. Como la información de los bloques está encriptada y sólo el que 

la creĂł la puede ver, a travĂŠs de criptografĂ­a de clave pĂşblica y clave privada (eso es lo que 

hace que la informaciĂłn sea segura y anĂłnima) serĂ­a lĂłgico preguntarse cĂłmo se aĂąaden 

bloques y cĂłmo se hace para que todos los nodos de la red tengan una copia exactamente igual 



 
 

12 

a los de la otra. AcĂĄ es donde entran unos nodos especiales de la red de bloques que son los 

mineros y la incógnita “X”. 

     Cada vez que  surge un nuevo bloque para aĂąadir a la cadena, por ejemplo nuevas 

transacciones con bitcoin que aĂąadir al historial, los mineros reciben un aviso. Para aĂąadir el 

bloque a la red hace falta que alguien calcule una variable “X” y la añada al bloque. El primer 

minero que lo consiga avisa a todo el resto de mineros, luego todos los demĂĄs mineros 

comprueban que la “X” calculada sea correcta, y el minero que consiguió calcular la incógnita 

“X” se lleva un premio. Hallar esta variable X es extremadamente difícil y esta tiene que ver 

con los hash (cĂłdigo, nĂşmero de serie) de cada bloque. 

     

     Como se ha explicado, un hash es un cĂłdigo o nĂşmero de serie matemĂĄtico. Y una funciĂłn 

de hacer hashes es una funciĂłn matemĂĄtica convertida en algoritmo que recibe un fichero de 

texto, letras, nĂşmeros, o caracteres en general y le asigna un nĂşmero Ăşnico, de tal forma que el 

nĂşmero Ăşnico depende del texto. Si cambiĂĄramos cualquier caracter el resultado ya no serĂ­a el 

mismo, ademĂĄs la forma de asignar el nĂşmero es extremadamente complicada, o sea que si 

hipotĂŠticamente se nos entregara el nĂşmero final es imposible saber el texto del que proviene, 

y esto es lo que hacen en el blockchain los mineros, buscan la variable “X” del problema. 

 

     Para resumir los puntos anteriores, surge un bloque nuevo que aĂąadir a la cadena, o sea por 

ejemplo nuevas transacciones con bitcoins que aĂąadir al historial etc. Luego, se debe buscar 

una variable X para unirla a la informaciĂłn del bloque y que en el hash (nĂşmero de serie) 

aparezca un nĂşmero que comienza por 30 ceros usando el algoritmo de generaciĂłn de hash, 

SHA 256.  

     Calcular este nĂşmero en la prĂĄctica es imposible, incluso si se conoce el algoritmo. La Ăşnica 

forma es probando al azar billones de combinaciones posibles hasta que salga lo que se 

requiere, y esto es lo que hacen los mineros de bitcoin.  

      

     Lo de los 30 ceros se llama dificultad de la prueba de trabajo y el protocolo bitcoin lo va 

ajustando para que cada bloque se tarda en minar mĂĄs o menos 10 minutos. El algoritmo SHA 

256 es extremadamente seguro, imposible de revertir, y se usa desde verificaciĂłn de paquetes 

Linux, protocolos de seguridad en internet, y hasta en tribunales internacionales.               



 
 

13 

      

     Al minero que consigue minar ese bloque se le dan 12,5 bitcoins (al momento de escribir 

estas palabras) y esta recompensa se reduce a la mitad por cada 210 mil bloques que se minan 

en la red. AdemĂĄs como todos los mineros tienen el mismo bloque para aĂąadir a la cadena, esto 

hace que nadie pueda falsificar un bloque, y que además cuando alguien consigue la “X” del 

algoritmo todos los demĂĄs mineros la comprueban y la mayorĂ­a tiene que estar de acuerdo en 

que es correcto, sino no se aĂąade.  

     Imagine por un momento que alguien intenta falsificar un bloque y cambia tan solo un 

caracter del fichero, un nĂşmero o una letra. Como todos los mineros estĂĄn tratando con el 

mismo problema matemĂĄtico la incĂłgnita X del falsificador no serĂĄ verificada por los demĂĄs 

mineros y no funcionarĂĄ a nadie mĂĄs, por lo tanto no se aĂąadirĂĄ el bloque y el falsificador no 

obtendrĂĄ su recompensa.  

 

     Minar consiste en probar billones de combinaciones al azar, por lo que obviamente al tener 

mĂĄs capacidad de cĂłmputo aumentan las posibilidades de conseguir el nĂşmero y la 

recompensa, esto ha dado pie para que en paĂ­ses como China, Venezuela o Islandia, donde la 

electricidad es subvencionada por el estado o poseen un clima helado muy favorable (para 

evitar el sobrecalentamiento de los ordenadores), se hayan instalado las llamadas granjas de 

minado, lugares de cientos de metros cuadrados industrializados con ordenadores tratando de 

descifrar los algoritmos las 24 horas del dĂ­a y asĂ­ obtener la recompensa. 

 

     Por Ăşltimo, se puede hacer la analogĂ­a de que la gran mayorĂ­a de criptomonedas y 

aplicaciones funcionando bajo blockchain poseen una lĂłgica y forma de funcionar similar a la 

descrita anteriormente. 

 

     Para concluir este punto 3.2, quisiera agradecer a don Eduardo SĂĄenz de CabezĂłn, Doctor 

en MatemĂĄticas de la Universidad de la Rioja, EspaĂąa, por ser el autor intelectual de gran parte 

de las ideas en que se basĂł este capĂ­tulo.  

 

 

 



 
 

14 

 

 

3.3 Los contratos inteligentes  

 

                   La mejor analogĂ­a para definir un contrato inteligente es pensar en un clĂĄsico contrato de 

toda la vida, por ejemplo de arrendamiento, inmobiliario, de trabajo, de prestaciĂłn de servicio 

etc, y llevarlo al ĂĄmbito digital.  La diferencia es que acĂĄ el contrato debe ser codificado y 

programado por una persona que se maneje en lenguaje de programaciĂłn y contarĂĄ con ciertas 

reglas y algoritmos donde se liberan los pagos involucrados automĂĄticamente a medida que las 

condiciones del contrato se van cumpliendo. 

                     Por ejemplo imagine un contrato de trabajo, donde el empleador y empleado firman un 

clĂĄsico contrato de trabajo, la diferencia es que acĂĄ utilizan la tecnologĂ­a de contrato inteligente 

y lo codifican. En este caso el contrato inteligente liberarĂĄ los pagos desde la cuenta del 

empleador al empleado en el dĂ­a pactado, pagarĂĄ las imposiciones correspondientes y realizarĂĄ 

otros trĂĄmites, y si no existe dinero disponible en la cuenta del empleador el dĂ­a 

correspondiente, puede dar aviso automĂĄticamente a la inspecciĂłn del trabajo, e incluso iniciar 

un juicio en caso de ser necesario, bajo la internet de las cosas (IoT),                tecnologĂ­a  

posiblemente ya totalmente desarrollada durante la prĂłxima dĂŠcada bajo el umbral 5G, 

velocidades inalĂĄmbricas de internet prĂĄcticamente instantĂĄneas y que precisamente este aĂąo 

2019 harĂĄ su debut en EEUU (Verizon, 2018).  

                      Para nombrar otros ejemplos prĂĄcticos de los contratos inteligentes y la 

desburocratizaciĂłn de actividades en potencia que poseen podemos imaginar el reemplazo de 

corredores de bolsa, de propiedades, notarios pĂşblicos, conservadores de bienes raĂ­ces, 

corredores de apuestas, etc. Actividades que pueden ser codificadas secuencialmente y que 

ayudarĂ­an a reducir enormes costos y sobre todo tiempo. Muchos servicios que hoy en dĂ­a 

funcionan de forma manual, teniendo el potencial para poder funcionar de forma automĂĄtica. 

 

 

 

          3.4  La mĂĄquina virtual de Ethereum (EVM) 

 



 
 

15 

 

     La MĂĄquina Virtual de Ethereum (o EVM, Ethereum Virtual Machine) es considerada la 

principal creaciĂłn de Ethereum. Se trata de un software completo de Turing con el que se puede 

resolver casi cualquier problema computacional y que es ejecutado dentro de la misma red de 

Ethereum. Su diseĂąo tiene como principal objetivo poner en marcha cĂłdigos algorĂ­tmicos 

complejos y facilitar el proceso de creaciĂłn de aplicaciones a travĂŠs de lenguajes de 

programaciĂłn mucho mĂĄs amigables, como es el caso de JavaScript, evitando la construcciĂłn 

de una cadena de bloques completamente nueva para cada una de las aplicaciones. Ethereum 

permite que cada una de las aplicaciones se desarrollen dentro de una misma plataforma.  

     A su vez, Ethereum Virtual Machine se encuentra separada del resto de la red, lo que 

permite que cualquier persona o empresa pueda aprender a crear un contrato inteligente mĂĄs 

grande y con mayor fuerza usando la EVM, sin necesidad de afectar a otras transacciones que 

tengan lugar en la cadena de bloques (Libertex, 2019). 

 

     La mĂĄquina virtual Ethereum se enfoca en brindar seguridad y ejecutar cĂłdigo no confiable 

en computadoras de todo el mundo. Para ser mĂĄs especĂ­fico, este proyecto se enfoca en 

prevenir los ataques de denegaciĂłn de servicio, que se han vuelto comunes en el mundo de las 

criptomonedas. AdemĂĄs,  EVM garantiza que los programas no tengan acceso al estado del 

otro, lo que garantiza que la comunicaciĂłn se puede establecer sin ninguna interferencia 

potencial. 

     Para poner esto en un lenguaje que todos puedan entender, Ethereum Virtual Machine estĂĄ 

diseĂąada para servir como un entorno de ejecuciĂłn para contratos inteligentes basados en 

Ethereum.  

 

     Dado que la MĂĄquina Virtual Ethereum estĂĄ completamente aislada del resto de la red 

principal, es un entorno de prueba perfecto, cualquier empresa que busque crear un contrato 

inteligente puede hacerlo utilizando la EVM, sin que esto afecte las operaciones principales de 

la cadena de bloques. La prueba de esta tecnologĂ­a es de suma importancia, ya que un cĂłdigo 

defectuoso puede significar la desapariciĂłn de incluso los contratos inteligentes mĂĄs grandes. 

AdemĂĄs, se podrĂ­a considerar al EVM como un ""entorno de aprendizaje"" para construir 

contratos inteligentes mĂĄs grandes, mejores y mĂĄs robustos. 



 
 

16 

 

     TambiĂŠn vale la pena mencionar que cada nodo Ethereum en la red ejecuta su propia 

implementaciĂłn de EVM y es capaz de ejecutar las mismas instrucciones, ademĂĄs es una puerta 

de entrada para construir contratos inteligentes adecuados, tanto para los principiantes como 

para los programadores experimentados que buscan obtener un enfoque prĂĄctico con Solidity, 

un lenguaje de alto nivel orientado a objetos para implementar contratos inteligentes (Solidity, 

2019). AdemĂĄs, el EVM se ha implementado en lenguajes de programaciĂłn mĂĄs tradicionales, 

tales como Python, Ruby, C ++ y algunos otros lenguajes de codificaciĂłn. (Themerkle, 2019) 

 

 

 

 

3.5 OrĂĄculo 

 

 

     

                    Suenan como algo de la mitologĂ­a griega y de alguna manera funcionan de forma similar, 

cuenta la leyenda que en el mundo antiguo las personas no tenĂ­an suficiente informaciĂłn para 

tomar decisiones y recurrieron a orĂĄculos para indagar mĂĄs allĂĄ de los lĂ­mites de su propia 

comprensiĂłn. 

                   De la misma manera, las cadenas de bloques como las de Bitcoin y Ethereum, no tienen 

acceso fĂĄcil a la informaciĂłn fuera de la cadena, por lo que no existe una forma directa de 

validar las condiciones en que se basan los contratos inteligentes. Un orĂĄculo es, simplemente, 

un traductor para la informaciĂłn proporcionada por una plataforma externa. Los orĂĄculos 

dentro del blockchain son fuentes de informaciĂłn externas y que permiten a los contratos 

inteligentes ejecutar Ăłrdenes con informaciĂłn imparcial, pĂşblica y no manipulada. 

                      Los orĂĄculos proporcionan los datos necesarios para que se ejecuten contratos 

inteligentes cuando se cumplan los tĂŠrminos originales del contrato. Estas condiciones podrĂ­an 

ser cualquier cosa asociada con el contrato inteligente: temperatura, finalizaciĂłn del pago, 

cambios de precio, etc. Estos orĂĄculos son la Ăşnica forma de que los contratos inteligentes 

interactĂşen con datos fuera del entorno de Blockchain. (Cointelegraph, 2019). 



 
 

17 

                    Es importante entender que los contratos inteligentes no pueden funcionar sin una fuente 

externa de datos fiable, si esto no pasara perderĂ­an su potencial enormemente. 

 

 

 

 

 

 

 

 

 

3.6 Raiden Network (RDN) 

 

     Raiden network es una red para transacciones instantĂĄneas, opera bajo la plataforma de 

Ethereum y es anĂĄloga a Lightning Network de bitcoin, siendo ĂŠsta un protocolo en capas de 

la parte superior de la cadena de bloques de bitcoin (Bitcoinlightning, 2019) que permite 

transacciones rĂĄpidas entre nodos participantes y se ha promocionado como una soluciĂłn al 

problema de escalabilidad del bitcoin.  

      

     Cuenta con un sistema de igual a igual para realizar micro pagos de criptomoneda a travĂŠs 

de una red de canales de pago bidireccionales sin ";"""date"",""2020-08-20T17:01:06Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.5""
""xmp:CreatorTool"",""MicrosoftÂŽ Word 2016""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dc:creator"",""JFlores""
""language"",""es""
""dcterms:created"",""2020-08-20T17:01:06Z""
""Last-Modified"",""2020-08-20T17:01:06Z""
""dcterms:modified"",""2020-08-20T17:01:06Z""
""dc:format"",""application/pdf; version=1.5""
""Last-Save-Date"",""2020-08-20T17:01:06Z""
""pdf:docinfo:creator_tool"",""MicrosoftÂŽ Word 2016""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2020-08-20T17:01:06Z""
""meta:save-date"",""2020-08-20T17:01:06Z""
""pdf:encrypted"",""false""
""modified"",""2020-08-20T17:01:06Z""
""Content-Length"",""1115840""
""pdf:hasMarkedContent"",""true""
""Content-Type"",""application/pdf""
""pdf:docinfo:creator"",""JFlores""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""JFlores""
""dc:language"",""es-ES""
""meta:author"",""JFlores""
""meta:creation-date"",""2020-08-20T17:01:06Z""
""created"",""2020-08-20T17:01:06Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""48""
""Creation-Date"",""2020-08-20T17:01:06Z""
""resourceName"",""3560903501219UTFSM.pdf""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""388"",""924"",""1124"",""1289"",""2244"",""2366"",""2268"",""1115"",""1671"",""1881"",""1891"",""2398"",""2389"",""1959"",""2060"",""2314"",""1984"",""1730"",""1958"",""1747"",""1797"",""1022"",""1109"",""780"",""1985"",""228"",""2247"",""2317"",""1866"",""1665"",""1558"",""1871"",""2175"",""1859"",""1834"",""2132"",""44"",""1149"",""1394"",""1145"",""305"",""302"",""239"",""424"",""474"",""171"",""633"",""8""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""Author"",""JFlores""
""producer"",""MicrosoftÂŽ Word 2016""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""MicrosoftÂŽ Word 2016""
""pdf:docinfo:created"",""2020-08-20T17:01:06Z""
";https://scholar.google.com/scholar?start=940&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094534-625;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Reversible proofs of sequential work;H Abusalah, C Kamath, K Klein, K Pietrzak… ; … Conference on the …, 2019  Springer;;"… discussion in [BBBF18]), blockchain designs like chia.net or proofs of replication [Fis19] … Ideal

permutations can be constructed from random oracles [CPS08, HKT11, DSKT16] (formally, the

ideal permutation model is indifferentiable from the random oracle model), so we …";Cité 4 fois;Les 3 versions;[PDF] iacr.org;https://eprint.iacr.org/2019/252.pdf;"
Reversible Proofs of Sequential Work

Hamza Abusalah1?, Chethan Kamath2??, Karen Klein2??, Krzysztof
Pietrzak2??, and Michael Walter2??

1 SBA Research
habusalah@sba-research.org

2 IST Austria, Am Campus 1, 3400 Klosterneuburg, Austria
{ckamath,kklein,pietrzak,mwalter}@ist.ac.at

Abstract. Proofs of sequential work (PoSW) are proof systems where a
prover, upon receiving a statement χ and a time parameter T computes
a proof φ(χ, T ) which is efficiently and publicly verifiable. The proof can
be computed in T sequential steps, but not much less, even by a malicious
party having large parallelism. A PoSW thus serves as a proof that T
units of time have passed since χ was received.

PoSW were introduced by Mahmoody, Moran and Vadhan [MMV11], a
simple and practical construction was only recently proposed by Cohen
and Pietrzak [CP18].

In this work we construct a new simple PoSW in the random permutation
model which is almost as simple and efficient as [CP18] but conceptually
very different. Whereas the structure underlying [CP18] is a hash tree,
our construction is based on skip lists and has the interesting property
that computing the PoSW is a reversible computation.

The fact that the construction is reversible can potentially be used for
new applications like constructing proofs of replication. We also show
how to “embed” the sloth function of Lenstra and Weselowski [LW17]
into our PoSW to get a PoSW where one additionally can verify correct-
ness of the output much more efficiently than recomputing it (though
recent constructions of “verifiable delay functions” subsume most of the
applications this construction was aiming at).

1 Introduction

Timed-release cryptography was envisioned by May [May93] and realised by
Rivest, Shamir and Wagner [RSW00] in the form of a “time-lock puzzle”. For
a time parameter T , such a puzzle can be efficiently sampled together with a
solution. However, solving it requires T sequential computational steps, and this
holds even for parties aided with massive parallelism. In other words, there are no
“shortcuts” to the solution. The application envisioned in [RSW00] was “sending
a message to the future”: generate a puzzle, derive a symmetric key from the

? Partially supported by FFG COMET under SBA-K1 grant
?? Supported by the European Research Council, ERC consolidator grant (682815 -

TOCNeT).



solution, encrypt your message using that key, then release the ciphertext and
the puzzle. Now everyone can decrypt by solving the puzzle which requires T
sequential steps.

The construction put forward in [RSW00] is in the RSA setting: the puzzle
is a tuple (N, x, T ), where N = p · q is an RSA modulus and x ∈ Z∗N a group

element, and the solution to the puzzle is x2
T

mod N . Although the solution can
be computed efficiently if the factorisation of N is known, it is conjectured to
require T sequential squarings given only N .

The assumption that underlies the soundness of the [RSW00] time-lock puzzle
is rather non-standard (which is basically that the puzzle is sound, i.e., there’s
no shortcut in computing the solution) and it’s an open problem to come up
with constructions under more standard assumptions. In a negative result, Mah-
moody, Moran and Vadhan [MMV11] show that there’s no black-box construc-
tion of a time-lock puzzle in the random oracle model. In subsequent work the
same authors [MMV13] propose and construct proofs of sequential work (PoSW).
This is a proof system wherein a prover P can convince a verifier V that it spent
T sequential time steps upon receiving some challenge χ. Even though PoSW
seem related to time-lock puzzles, they are not directly comparable. In particu-
lar, a PoSW does not require that one can sample the solution together with an
instance. On the other hand, a PoSW must be publicly verifiable3 and sampling
a challenge must be public-coin4 so it can be made non-interactive by the Fiat-
Shamir heuristic. [MMV13] construct a PoSW in the random oracle model (or
under a standard model assumption on hash functions called “sequentiality”).

As possible applications for PoSW [MMV13] suggest universally verifiable
CPU benchmarks and non-interactive time-stamping. The construction given in
[MMV13] is not practical as a prover needs not only T sequential time steps but
also linear in T space to compute a proof. Cohen and Pietrzak [CP18] resolved
this issue by constructing a PoSW where the prover requires just log(T ) space.

More recently there has been renewed interest in time-delayed cryptography
as it found applications in decentralized systems, including public randomness
beacons (cf. discussion in [BBBF18]), blockchain designs like chia.net or proofs
of replication [Fis19]. For the first two applications the PoSW need to be unique,
which means it should not be possible (or at least computationally hard) to
compute more than one accepting proof for the same challenge. This notion was
introduced in [CP18] but constructing such a PoSW was left as an open problem.

Our Contribution. Constructions of hash-based PoSW start with some un-
derlying graph structure, which in [MMV13] is a depth-robust graph and in

3 So everybody, not just the party who generated the challenge, can efficiently verify
correctness. Note that in the RSW time-lock puzzle only the party who generated the
challenge (which is called a puzzle in this context) and thus knows the factorization
can verify the proof efficiently.

4 This basically means that the challenge is just a uniformly random string. Note that
the RSW time-lock puzzle is not public-coin as the coins used to sample the RSA
modulus N must remain secret.

chia.net


[CP18] a binary tree with some extra edges. In this paper we construct a new
PoSW which is as simple and almost as efficient as [CP18] with the underlying
graph being a skip list. Our construction can be instantiated with permutations
– instead of hash functions – and is “reversible”.

Until recently the sloth hash function [LW17] was the closest we had to a
unique PoSW. It’s not a PoSW because the computation required for verification
is linear in the time parameter T (albeit around a 1000 times faster). The fact
that our PoSW is reversible allows us to “embed” sloth into our PoSW, this
way we get a PoSW where verification (of the claim that T sequential time steps
were spent) is very efficient (logarithmic in T ), while verifying correctness can be
done as efficiently as in sloth (in time O(T ) with a very small hidden constant).
We outline this construction in more detail in Section 1.1 below.

For applications of unique PoSW our construction is by now mostly subsumed
by very recent constructions of verifiable delay functions [BBBF18] (VDF). A
VDF is defined almost like a PoSW, but the (non-interactive) proof does not
only certify that T sequential time has been used to compute some value, but
the stronger property that this value is actually the correct value. A VDF is thus
basically a unique PoSW (the only reason it’s not exactly a unique PoSW is that
the proof itself could be malleable, but this doesn’t matter for any of the appli-
cations). The notion of a VDF has been introduced by Boneh et al. in [BBBF18]
who also construct a VDF using rather heavy machinery like incrementally veri-
fiable computation. Subsequently two extremely simple and efficient VDFs have
been proposed [Wes19, Pie19b], both papers basically show how to make the
RSW time-lock puzzle [RSW00] publicly verifiable, that is, they give proof sys-

tems for showing that a given tuple (x, y, T ) satisfies x2
T

= y in a group of
unknown order (e.g. Z∗N as used in [RSW00]). These constructions are clearly
favourable to ours as correctness (which here means that the output is correctly
computed) can be verified much more efficiently, though as they are not post-
quantum secure, ours is arguably still the best option in a post-quantum setting
for some applications. This hopefully will change in the near future as research
on post-quantum VDFs is ongoing [FMPS19].

The fact that our PoSW is reversible seems also useful in the context of proofs
of replication [Fis19, Fis18, Pie19a] for similar reasons that “decodable” VDFs
are useful in this context as discussed in [BBBF18], we are currently working
towards constructing simple proofs of replication based on the skip list based
PoSW presented in this paper.

1.1 Hash chains and the Sloth function.

A simple construction which is not quite a PoSW is a hash chain, where on
input x = x0 one outputs as proof xT which is recursively computed as xi =
hash(xi−1). If hash is a bijection and can be efficiently evaluated in both di-
rections (i.e., a permutation), then from a given state xi, one can compute the
previous state xi−1, we call such a construction reversible.

Verifying that xT has been correctly computed requires T hashes (so it’s no
a PoSW), but at least one can parallelize verification by additionally outputting



some q intermediate values x0, xT/q, x2T/q, . . . , xT (then the proof can be verified
in T/q time assuming one can evaluate q instantiations of hash in parallel: for
every i ∈ [q], verify that T/q times hashing x(i−1)T/q gives xiT/q).

Lenstra and Wesolowski [LW17] suggest a construction called “sloth”, which
basically is a hash chain but with the additional property that it can be verified
with a few hundred times less computation than what is required to compute it.
The construction is based on the assumption that computing square roots in a
field Fp of size p is around log(p) times slower than the inverse operation, which
is just squaring. A typical value would be log(p) ≈ 1000, going much higher is
problematic as then fast multiplication methods (e.g., Karatsuba, Schönhage-
Strassen) can be applied.

Their idea is to simply use a hash chain where the hash function is some
permutation π : Fp → Fp, where Fp is a finite field of size p, followed by taking

a square root: that is xi =
√
π(xi−1). Verification goes as for a standard hash

chain, but one computes backwards, checking xi−1 = π−1(x2i ), which – assuming
computing π, π−1 is cheap compared to squaring, and squaring is log(p) times
faster than taking square roots – gives the claimed speedup of ≈ log(p) compared
to a simple hash chain.

In Section 4 we show how sloth can be embedded into our skip list based
PoSW to get a construction such that it remains a good PoSW, while correctness
of the output can be verified as efficiently as in sloth, the constructions discussed
are summarized in the table below.

2 Construction

2.1 Notation

Throughout we denote the time parameter of our construction by N = 2n with
n ∈ N and assume it’s a power of 2. We reserve w, t ∈ N to denote two statistical
security parameters, w is the block size (say w = 256) and t denotes the number
of challenges: a cheating prover who only makes N(1−ε) sequential steps (instead
N) will pass verification with probability (1− ε)t. For integers m,m′ we denote
with [m,m′] = {m,m+ 1, . . . ,m′}, [m], [m]0 are short for [1,m] and [0,m].

We define 0̃ = n + 1 and for i ≥ 1 we denote with ĩ the number of trailing
zeros in the binary representation of i, plus 1

0̃, 1̃, 2̃, 3̃, 4̃, 5̃, 6̃, 7̃, 8̃, 9̃, . . . = n+ 1, 1, 2, 1, 3, 1, 2, 1, 4, 1, . . .

For σ ∈ {0, 1}w¡i we denote with σ(j) the jth w-bit block of σ, so that σ =
σ(1)‖ . . . ‖σ(i). σ(i...j) is short for σ(i)‖ . . . ‖σ(j).

For a permutation π over ` bit strings, we denote with π̇ the function over
bit stings of length ≥ ` which simply applies π to the ` bit prefix of the input,
and leaves the rest untouched.



construction (using # of stepsd # of stepsd to assumption step post reversible

time parameter T to verify verify if output quantum

and statistical sequential is correct

security parameter computation (uniqueness)

Ν) O(¡) of O(¡) of

hash chain T T random oraclea RO call yes yesb

sloth [LW17] T/ log(p) T/ log(p) log(p) gap computing x→
√
x yes yes√

x vs x2 and & RP call

random permutationa,c

PoSW [CP18] Ν ¡ log(T ) T random oraclea RO call yes no

PoSW Sec. 2 Ν ¡ log2(T )f T random permutationa,c RP call yes yes

Combined Sec. 4 λ · log2(T )f T/ log(p) like sloth x→
√
x yes yes

& RP call

[Pie19b] VDF λ · log(T ) λ · log(T ) (x, T )→ x2
T

requires x→ x2 no no

T sequential squaringse

[Wes19] VDF λ λ as above plus x→ x2 no no

“root assumption”

aOr a standard model assumption called “sequential hash function”.
bIf the function used is an efficiently invertible permutation.
cThe random permutation model is equivalent to the random oracle model.
dWhat a step is depends on the construction, but evaluating the function is always
assumed to require T sequential steps.
eThis assumption can only hold in groups of unknown order.
fStrictly speaking, the number of oracle calls required to verify is just Ν ¡ log T
(as in [CP18]), but in our constructions the input, on an average, consists of
log T/2 blocks (unlike [CP18], where it is 2 blocks) and therefore to make a fairer
comparison, we count the cost of an oracle call on an input of length k blocks as k calls.

0w

0w

0w

0w

π0

π1

π2

π3

π4

π5

π6

π7

π8

φ1

φ2

φ3

φ4

σ0 σ1 σ2 σ3 σ4 σ5 σ6 σ7 σ8

Fig. 1: Illustration of the computation of σΠ = (σ0, . . . , σN ) with n = 3, N =
2n = 8. The blocks represent the permutations, whereas the dashed vertical lines
represent the states. Note that the structure of the graph is the same as a skip
list with four layers, where a pointer in layer i, i ∈ {0, 1, 2, 3}, points to the 2i-th
element to its right on the list.



2.2 The sequence σΠ

At the core of our construction is a mapping based on the skip list data structure
(see Figure 1). It is built from a set of permutations Π = {πi}i∈[N ]0 , where

each πi is over {0, 1}w·̃i, and defines a sequence of states σΠ = σ0, . . . , σN ,
σi ∈ {0, 1}(n+1)¡w, recursively as

σ0 = π̇0(0w·(n+1)) and for i > 0 : σi = π̇i(σi−1)
(

= πi(σ
(1...̃i)
i−1 )‖σ((̃i+1)...(n+1))

i−1

)
.

2.3 The DAG GN

0 1 2 3 4 5 6 7 8

Fig. 2: The graph G8 that corresponds to the computation of σΠ with n = 3.

It will be convenient to consider the directed acyclic graph (DAG)

GN = (V,E) , V = [N ]0 , E = {(i, j) ∈ V 2 : ∃k ≥ 0 : j − i = 2k, 2k|i}

that is derived from the computation of σΠ as follows: identify the permutation
πi with the node i and add a directed edge (i, j) if in the computation of σΠ
part of the output of πi is piped through directly to πj (see Figure 2).

For i ∈ [N − 1] we denote with path(i) ⊆ V the subgraph of V induced by
the nodes on the shortest path in GN which starts at 0, ends at N and passes
through node i. For example, in Figure 1,

path(5) = ({0, 4, 5, 6, 8}, {(0, 4), (0, 8), (4, 5), (4, 6), (4, 8), (5, 6), (6, 8)}).

It’s not hard to check that the number of vertices in path(i) is n+ 3− ĩ, and in
particular is never more than n+ 2.

2.4 Consistent States/Paths

By construction, the σi ∈ σΠ satisfy σi = π̇−1i+1(σi+1), and more generally, for

every edge (i, j) ∈ E and d = min(̃i, j̃)

σ
(d...n+1)
i = (π̇−1j (σj))

(d...n+1).

We say two strings are consistent for (i, j) if they satisfy this condition.



Definition 1 (Consistent States/Path). ιi, ιj ∈ {0, 1}(n+1)¡w are consis-
tent for edge (i, j) ∈ E if with d = min(̃i, j̃)

Îą
(d...n+1)
i = (π̇−1j (αj))

(d...n+1) .

We say α′i ∈ {0, 1}ĩ·w, α′j ∈ {0, 1}j̃·w are consistent if they can be “padded” to
consistent Îąi, Îąj as above, which is the case if

α′
(d)
i = π−1(α′j)

(d).

We say {ιi}i∈path(k) are consistent with path(k) if ιi, ιj are consistent for every
edge (i, j) ∈ path(k).

Note that if αj is computed from αi by applying π̇i+1, . . . , π̇j to αi, then those
Îąi, Îąj will be consistent with (i, j), but the converse is not true (except if j =
i+ 1).

2.5 PoSW Construction

The protocol between P,V on common input T = N = 2n, w, t goes as follows

1. V samples χ ← {0, 1}w·n and sends it to P. This χ defines a fresh set of
random permutations Π (cf. Remark 1 below).

2. P computes σ0, . . . , σN and sends φ = σN to V.
3. V samples t challenges γ = (γ1, . . . , γt)← [N − 1]t and sends them to P.
4. P sends {σi}i∈path(j),j∈γ to V (cf. Remark 2 below).
5. V verifies for every j ∈ γ that {σi}i∈path(j) is consistent as in Definition 1. If

any check fails output reject, output accept otherwise.

Remark 1 (Seeding Random Oracles/Permutations). Ideal permutations can be
constructed from random oracles [CPS08, HKT11, DSKT16] (formally, the ideal
permutation model is indifferentiable from the random oracle model), so we
can realize Π in the standard random oracle model.5 Consider a fixed random
oracle H(¡) about which a potential adversary has some auxiliary input (i.e.,
it has queried it on many inputs before, and stored some information aux).
If one samples a random seed χ and uses it as a prefix to define the function
Hχ(x) = H(χ‖x), thisHχ – from the adversaries’ perspective – is a fresh random
oracle as long as this seed is just a bit longer that log(|aux|) [DGK17]. Thus, we
can also sample a fresh Π by just sending a seed χ.

Remark 2 (P’s Space Requirement). To avoid any extra computation in step
4., P would need to store the entire σΠ = {σi}i∈[N ]0 . By using a bit of extra
computation, one can reduce the space requirement (we remark that a similar
trade off comes up in [CP18]). Concretely, for some K = 2k, we let P only store
σi where 2k|i, thus storing only N/K states. From this, every state σi can be
computed making at most K/2 invocations to Π (and K/2 not K as we can also
compute backwards).
5 In practice, one could e.g. use χ to sample N + 1 AES keys k0, . . . , kN , and then use
AES(ki, ·) : {0, 1}256 → {0, 1}256 – i.e., AES with a fixed public key – to construct
πi, where for ĩ > 1 one would use domain extension for random permutations to
extend the domain to 256 ¡ ĩ bits.



3 Security Proof

Theorem 1. Consider a malicious prover P̃ which

1. makes at most N−∆ sequential queries to permutations in Π before sending
φ = σN (in step 3 of the protocol); and

2. queries the permutations in Π on at most q inputs in total during execution
of the protocol.

Then P̃ will win (i.e., make V output accept) with probability at most

Pr
(
P̃ wins

)
≤ 2q2(n+ 3)2

2w
+

(
N −∆
N

)t
. (1)

The proof of Theorem 1 mainly follows the intuition that sending φ “com-
mits” the prover to a set of challenges it can respond to. We prove this fact
formally in Lemma 7. If this set is a large fraction of the possible challenges,
it implies the existence of a long sequence (as defined below) that necessarily
requires many sequential steps.

To aid the proof we begin with a couple of definitions. The first one is merely
for notational convenience.

Definition 2. We use ∟ to denote that two strings (composed of w-bit blocks)
contain an identical block

α ∼ α′ ⇐⇒ ∃i, j : α(i) = α′
(j)
.

We then say that α and α′ collide.

The next definition characterizes the property that paths through our skiplist
construction satisfy and that we rely on for the proof.

Definition 3 (Π-Sequence). For a family of N permutations Π = {πi}i a Π-
sequence of length N ′ < N is an N ′-tuple of pairs of strings ((xj , yj))j together
with an N ′-tuple of strictly increasing integers (ij)j such that for all j

πij (xj) = yj and yj ∼ xj+1.

Below we show that Π-sequences are inherently sequential (cf. Lemma 6 and
Corollary 1), but that requires a few technical lemmas, so we defer the details
and proceed to the main proof. We now show how Lemma 7 and Corollary 1
imply Theorem 1.

Proof (of Theorem 1). Consider a malicious prover P̃ that convinces the verifier
on a random challenge with probability ≥ N−∆

N . Since the correct response to

any challenge is a distinct Π-sequence from 0 to φ, Lemma 7 implies that P̃ must
be able to respond to a fraction ≥ N−∆

N of the challenges. This is because the set

of Π-sequences from 0 to φ that P̃ can compute is essentially fixed after sending
φ and thus independent of the choice of challenges. This means there must exist



a set of N−∆ responses which can be pieced together to a Π-sequence of length
N −∆ from 0 to φ (details below). Note that all responses can be obtained by
sending all the challenges using rewinding (which does not increase the number
of queries). Then the result follows from Corollary 1.

It remains to establish the fact that the responses can be merged to a long
sequence. To see this, first assume that whenever two paths contain the same
node, the corresponding responses have the same state at this node. If this is
the case then merging the responses to k distinct challenges is easy: simply take
the “union” of the responses, which will be a Π-sequence of length at least k.

Finally, we show that different verifying reponses must have the same state
at intersecting nodes. The proof of this fact is recursive: consider the node N/2
and assume for contradiction that there are two paths that both verify and each
contains a state σN/2 and σ′N/2, respectively, with σN/2 6= σ′N/2. First note that

the states σ0 and σ′0 must both be equal to π0(0), so they are equal to each
other. Similarly, σN and σ′N must both be equal to φ in order to both verify.
Furthermore, verification ensures that σN/2 ∼ σ′N/2. Specifically, they are equal

in block n − 1, where they must both be equal to π−1N (σN )(n−1), since verifi-
cation checks the edge (N/2, N) for consistency (cf. Definition 1). Analogously,
verification ensures that π−1N/2(σN/2) ∼ π−1N/2(σ′N/2), since this corresponds to the

edge (0, N/2). Note that the latter pair of values could be extracted from the
prover by sending the appropriate challenges. By Lemma 5 (proved below) this

can only happen with probability ≤ 2q2(n+3)2

2w . We conclude that σN/2 is equal
among all valid responses with overwhelming probability. This allows to recurse
on the node N/4 and 3N/4, etc. ut

We now establish the remaining lemmas used in the main proof. Throughout
the rest of this section, w.l.o.g. we only consider algorithms that do not make re-
dundant queries. In all results in this section pertaining to random permutations
the probabilities are taken over the choice of the permutations.

First, we need a version of a PRP/PRF switching lemma that allows the
adversary oracle access to the permutation and its inverse. We have not seen
such a version in the literature so we prove it in the appendix.

Lemma 1. Let π : {0, 1}w 7→ {0, 1}w be a random permutation and consider an

algorithm Aπ,π
−1

with oracle access to π and π−1 that makes exactly q queries
in total. Assume that A does not repeat any queries to π nor any queries to π−1,
and that if it queries π at x, it does not query π−1 at π(x) and vice versa. Let
F1, F2 : {0, 1}w 7→ {0, 1}w be independent random functions. Then for any event

E over the output of A, we have Pr
(
Aπ,π

−1

∈ E
)
≤ Pr

(
AF1,F2 ∈ E

)
+ q(q−1)

2w ,

where the first probability is over the choice of π and the second over the choice
of F1, F2.

The Lemma shows that in the analysis we can replace the random permuta-
tion and its inverse oracle with random functions. Note that by a simple hybrid
argument, Lemma 1 also holds for families of permutations, where q is the sum
over all queries and w is the minimal input/output length over all permutations.



We now show that Lemma 1 implies a few restrictions on what an algorithm
can achieve when querying random permutations. Namely, we first show that
input/output pairs are hard to guess (cf., Lemma 2), that preimages are hard to
find without using the inverse oracle (cf., Lemma 3), and that it is hard to find
queries that result in collisions with earlier queries (cf., Lemma 4).

Lemma 2. Let Π = {πi}i be a family of random permutations. For any oracle
algorithm outputting a pair (x, y) and an integer i and making q queries to Π
except x in forward or y in backward direction, the probability that πi(x) = y is

≤ q2

2w .

Proof. We are trying to bound the probability that the algorithm is able to guess
the input/output pair of one of the permutations in Π (after making at most q
queries). If the πi were random functions, this probability would be ≤ 1

2w . By
Lemma 1 the bound follows. ut

Lemma 3. Let Π = {πi}i be a family of random permutations. For any algo-
rithm taking y as input and making q queries to Π except querying π−1i for y

and outputting some x and i, the probability that πi(x) = y is ≤ q2

2w .

Proof. If πi and π−1i were random function, the probability of finding such an x
would be 1

2w . Lemma 1 completes the proof. ut

Lemma 4. Let Π = {πi}i be a family of random permutations. For any algo-
rithm making q queries to Π the probability of a query to Π either in forward
or backward direction resulting in a response z that collides (in the sense of ∟)

with any of the previous queries (in either input or output) is ≤ 2q2(n+2)2

2w .

Proof. Assume we replace the permutations with random functions. The prob-
ability that the response to any query collides with a specific string is at most
(n+1)2/2w, since there are at most n+1 blocks in each string. By union bound,
the probability that a query collides with any of the previous queries is thus at
most 2q(n+1)2/2w, since there are two strings in each query (input and output).
Applying a final union bound to all queries shows that the probability of this
event is 2q2(n+ 1)2/2w. Lemma 1 now proves the result. ut

Using the basic lemmas above, we can make statements about certain cyclic
structures that are hard to find in random permutations and about the sequen-
tiality of random permutations.

Lemma 5. Let Π = {πi}i be a family of random permutations. For any algo-
rithm making q queries to Π and outputting two distinct values, x and x′, and

an integer i, the probability that x ∼ x′ and πi(x) ∼ πi(x′) is ≤ 2q2(n+3)2

2w .

Proof. Obtaining two such pairs requires to guess one of the two input/output
pairs or find a colliding query. Union bound over the two events (which are
bounded by Lemma 2 and 4, respectively) yields the bound. ut



Lemma 6 (Π-Sequentiality of Random Permutations). Let Π = {πi}i be
a family of random permutations. For any algorithm A taking as input x and
making a sequence Q of q queries to Π, and any Π-sequence s starting at x, the
probability of A outputting s and Q not containing the pairs in s in order and in

forward direction is ≤ 2q2(n+3)2

2w .

Proof. Producing a Π-sequence starting at a specific value without querying
the pairs in order and in forward direction, requires to either guess some in-
put/output pair (for some specific πi) or find a colliding query, similarly to
Lemma 5. ut

Corollary 1. Let Π = {πi}i be a family of random permutations. For any
algorithm taking as input x and making q sequential queries to Π, the probability

of outputting a Π-sequence of length longer than q is ≤ 2q2(n+3)2

2w . ut

We use the above observations to show that nothing the prover does after
sending its commitment φ will help responding to challenges.

Lemma 7. Let (PΠ1 ,PΠ2 ) be a pair of algorithms such that

– P1, on input x, makes q1 queries to Π, and outputs a state s1 and some y
– P2, on input s1, x, y, makes q2 queries to Π and outputs a Π-sequence s.

Let Q be the set of queries (including responses) made by P1, and let S be the
set of Π-Sequences between x and y computable6 from Q without any further

queries to Π. Then s ∈ S except with probability ≤ 2q2(n+3)2

2w , where q = q1 + q2.

Proof. Assume s /∈ S. Let (x′, y) be the last pair in s. First consider the case
that the query (x′, y) ∈ Q. Since s is a new sequence not computable from S it
must contain a pair (xi, yi) /∈ Q, so the queries in s were not made in order and

thus by Lemma 6 the probability of P2 outputting s is ≤ 2q2(n+3)2

2w .
Now consider the case (x′, y) /∈ Q. If P2 did not query x′ in forward direction,

by Lemma 6 the probability of P2 outputting s is ≤ 2q2(n+3)2

2w . Finally, if P2

queried x′ in forward direction, it did not submit an equivalent query in the
reverse direction by assumption. (Recall that we consider only algorithms that
do not make redundant queries.) It follow from Lemma 3 that the probability of

this event is ≤ q2

2w . ut

This completes the proof.

4 Embedding Sloth

As discussed in the introduction, we propose a reversible PoSW that is almost as
efficient as the construction from [CP18] but achieves a larger time gap between

6 By “computable” we mean here that there exists an algorithm for which the output
is correct with non-negligible probability.



the computation of the proof and the verification of correctness. To this aim, we
embed the sloth hash function from [LW17] into construction 2.5.

The idea underlying sloth is to use the fact that the best known algorithms for
computing modular square roots in a field Fp takes ≈ log(p) sequential squarings,
whereas verification of the result only takes a single modular squaring. Thus, this
gives a good candidate to build the slow-t imed hash function sloth.

Let p ≡ 3 mod 4 be a prime. We identify x ∈ F×p with its canonical repre-
sentant in [0, p− 1]. If x ∈ F×p is a quadratic residue, then there are two square
roots y, y′ ∈ F×p , where y′ = p − y, one of them being even, the other one odd.
Let +
√
x, −
√
x denote the (unique) even and odd square root of x, respectively. If

x ∈ F×p is not a quadratic residue, then −x is a quadratic residue, so it makes
sense to define a permutation ρ : F×p → F×p as

ρ(x) =

{
+
√
x, if x is a quadratic residue,

−
√
−x, otherwise.

Its inverse is defined by

ρ−1(x) =

{
x2, if x is even,

−x2, otherwise.

Unfortunately, one cannot directly build a hash chain by iterating ρ since
reducing modulo p − 1 in the exponent would yield a much faster computation
than sequentially computing ρ. Lenstra and Wesolowski [LW17] solve this prob-
lem by prepending an easily computable (in both directions) permutation π on
F×p to each iteration of the square rooting function ρ. Setting τ = ρ◦π, the sloth

function is hence defined as τN for some appropriate chain length N . Verification
can be done backwards by the computation (τN )−1 = (σ−1 ◦ ρ−1)N , which is by
a factor log p faster.

We now combine the ideas from [LW17] with our construction to achieve an
efficient PoSW while preserving the fast verification of correctness obtained by
the sloth construction. Let Π = {πi}i∈[N ]0 be a set of permutations where, for

each i ∈ [N ]0, πi : F×p × {0, 1}w·(̃i−1). We define the sequence σ̄Π = σ̄0, . . . , σ̄N
with σ̄i ∈ F×p × {0, 1}n·w recursively as

σ̄0 = ρ̇ ◦ π0((0, 0w·n))
(

= ρ
(
π0((0, 0w·n))(1)

)
‖π0((0, 0w·n))(2...n+1)

)
and

for i > 0 : σ̄i = ρ̇ ◦ π̇i(σ̄i−1)
(

= ρ
(
πi(σ̄

(1...̃i)
i−1 )(1)

)
‖πi(σ̄(1...̃i)

i−1 )(2...̃i)‖σ̄(̃i+1...n+1)
i−1

)
.

See Figure 3 for an illustration of the computation of σ̄Π . Defining Π ′ =
{π′i}i∈[N ]0 by π′i = ρ̇ ◦ πi, it holds σ̄Π = σΠ′ . Thus, using σ̄Π in our protocol
results in a PoSW that is secure in the random permutation model, almost as
efficient as the construction from [CP18], and at the same time achieves verifi-
cation of correctness as efficient as in sloth. More formally, the efficiency of the



Fp 3 0

0w

0w

0w

π0

ρ π1 ρ
π2 ρ π3 ρ

π4

ρ π5 ρ
π6 ρ π7 ρ

π8

ρ φ1

φ2

φ3

φ4

σ̄0 σ̄1 σ̄2 σ̄3 σ̄4 σ̄5 σ̄6 σ̄7 σ̄8

Fig. 3: Illustration of the computation of σ̄Π = (σ̄0, . . . , σ̄N ) with n = 3, N =
2n = 8.

combined scheme can be analysed as follows: First, consider the proof size:

|χ| = w · n, |φ| = log(p) + w · n, |γ| = t · n, |{σi}i,j | ≤ t · n(log(p) + w · n).

Hence, compared to [CP18], the proofs are by a factor n = log(N) = log(T )
larger. Next, consider the prover efficiency. To compute φ, the prover needs to
sequentially evaluate N + 1 permutations π′i = ρ̇ ◦ πi, i = 0, . . . , N . Storing only
the N/K states σi with K|i for some K = 2k, the prover can answer the c";"""date"",""2019-02-28T19:00:42Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2019-02-28T19:00:42Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.19 (TeX Live 2018) kpathsea version 6.3.0""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2019-02-28T19:00:42Z""
""created"",""2019-02-28T19:00:42Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-02-28T19:00:42Z""
""resourceName"",""252.pdf""
""Author"",""""
""producer"",""pdfTeX-1.40.19""
""pdf:docinfo:producer"",""pdfTeX-1.40.19""
""pdf:unmappedUnicodeCharsPerPage"",""12"",""0"",""0"",""13"",""0"",""3"",""5"",""10"",""15"",""11"",""11"",""19"",""7"",""0"",""8""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2019-02-28T19:00:42Z""
""Last-Modified"",""2019-02-28T19:00:42Z""
""dcterms:modified"",""2019-02-28T19:00:42Z""
""title"",""""
""Last-Save-Date"",""2019-02-28T19:00:42Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2019-02-28T19:00:42Z""
""meta:save-date"",""2019-02-28T19:00:42Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.19 (TeX Live 2018) kpathsea version 6.3.0""
""Content-Length"",""376765""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""15""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""1978"",""2718"",""2700"",""2104"",""1533"",""1205"",""2128"",""1732"",""2640"",""2205"",""1986"",""2067"",""1951"",""2518"",""712""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-02-28T19:00:42Z""
";https://scholar.google.com/scholar?start=440&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094663-1172;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Smart Contracts;R Wilkens, R Falk ; Smart Contracts, 2019  Springer;;"… Page 22. 14 3 Technische Grundlagen und Begriffe 3.2.2.3 Beschränkung auf Leistungen

in der Blockchain Smart Contracts können nur Leistungen erbringen, die sich digital in der

Blockchain abbilden lassen … „Oracles“ – Schnittstellen zur realen Welt";Cité 2 fois;Les 2 versions;null;;;;https://scholar.google.com/scholar?start=990&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094565-757;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[PDF][PDF] Smart contracts y Blockchain: calificación jurídica de los Smart contracts en el ecosistema de las Tecnologías de Registro Distribuido.;IO Pérez, IM Menéndez ; core.ac.uk;;"… de bloques. Por último, se debe ańadir que existe la posibilidad de introducir datos en los Smart

contracts a partir de fuentes de información externas a Blockchain. Los denominados oracles

(u oráculos) son tales fuentes externas que permiten a los Smart contracts ampliar …";Autres articles;Version HTML;[PDF] core.ac.uk;https://core.ac.uk/download/pdf/290001035.pdf;"
 

 

 

 

 

Trabajo Fin de Grado 
 

 

Smart contracts y Blockchain: calificaciĂłn jurĂ­dica de 

los Smart contracts en el ecosistema de las 

TecnologĂ­as de Registro Distribuido. 

 

Smart contracts and Blockchain: legal qualification of Smart 

contracts in the DLT ecosystem. 

 

 
Autora 

 

Irene Ortega PĂŠrez 

 

 
Director 

 

Ignacio Moralejo MenĂŠndez 

 

Facultad de EconomĂ­a y Empresa, Universidad de Zaragoza 

2018-2019 

  

CORE Metadata, citation and similar papers at core.ac.uk

Provided by Repositorio Universidad de Zaragoza

https://core.ac.uk/display/290001035?utm_source=pdf&utm_medium=banner&utm_campaign=pdf-decoration-v1


 

 

Autora: Irene Ortega PĂŠrez. 

Director: Ignacio Moralejo MenĂŠndez. 

TĂ­tulo: Smart contracts y Blockchain: calificaciĂłn jurĂ­dica de los Smart contracts en el 

ecosistema de las TecnologĂ­as de Registro Distribuido.  

Title: Smart contracts and Blockchain: legal qualification of Smart contracts in the DLT 

ecosystem. 

TitulaciĂłn: Derecho y AdministraciĂłn y DirecciĂłn de Empresas. 

RESUMEN 

El objetivo de este trabajo es el anĂĄlisis jurĂ­dico de los Smart contracts en el nuevo 

ecosistema de las TecnologĂ­as de Registro Distribuido (DLT, por sus siglas en inglĂŠs). 

Estos Smart contracts, que se hallan en un estadio incipiente, consisten en secuencias de 

cĂłdigos capaces de ejecutar autĂłnomamente las prestaciones a las que las partes se 

obliguen.   

Con este fin y dada la todavĂ­a escasa literatura cientĂ­fica-legal al respecto, se ha abordado 

un doble enfoque con fuentes teĂłrico-acadĂŠmicas, acudiendo a doctrina reconocida para 

analizar la base contractual de esta tecnologĂ­a, y con fuentes alternativas de comunicaciĂłn 

del conocimiento propias de este ĂĄmbito, como foros, blogs o White papers donde los 

precursores de estas tecnologĂ­as se han manifestado.   

Mediante este estudio, se pretende determinar cuĂĄl debe ser la calificaciĂłn jurĂ­dica de los 

Smart contracs, asĂ­ como cuales son los principales retos jurĂ­dicos que plantea esta 

realidad. Asimismo, se analizarĂĄ el impacto de estos Smart contracts en el pago, respecto 

al notariado y en sede judicial. Por Ăşltimo, se pretende mostrar la iniciativa de ciertos 

paĂ­ses en incorporar a sus marcos legales esta nueva herramienta de ÂŤcontrataciĂłnÂť.  

ABSTRACT 

The aim of the current dissertation is to study from a legal point of view the Smart 

contracts in the new Distributed Ledger Technology (DLT) ecosystem. These Smart 

contracts, a technology in the early stages, consist of code sequences that are able to 

autonomous execute already agreed contractual benefits.    

In order to achieve this purpose and being aware of the scarce legal literature, a double 

approach has been taken, using legal doctrine to examine the contractual basis of this 



 

 

technology, as well as other alternative sources of knowledge commonly used in the 

technology field, such as Internet forums, blogs or White papers in which the precursors 

of the Smart contracts have spoken out.  

Through this study I intend to establish the legal qualification of the Smart contracts and 

the main legal challenges that this reality poses. Additionally, I examine the impact of the 

Smart contracts on the fulfilment of the agreement, on the public notaries role and on the 

courts. Finally, I present the endeavours of certain countries that are including this new 

“contractual” tool on their legal frameworks. 



 

 

 

ÍNDICE 

RESUMEN ....................................................................................................................... 1 

ABSTRACT ..................................................................................................................... 1 

I. INTRODUCCIÓN ........................................................................................................ 1 

II. BLOCKCHAIN ........................................................................................................... 3 

1. QUÉ ES ..................................................................................................................... 3 

2. FUNCIONAMIENTO .............................................................................................. 4 

III. SMART CONTRACTS .............................................................................................. 7 

1. CONCEPTO Y TIPOLOGÍA ................................................................................... 8 

2. CALIFICACIÓN JURÍDICA ................................................................................... 8 

2.1. CASO 1: EL CÓDIGO NO COEXISTE CON OTRO DOCUMENTO EN 

LENGUAJE NATURAL. ......................................................................................... 9 

2.2. CASO 2: SMART CONTRACT COMO EXIGENCIA DE FORMA 

CONSTITUTIVA.................................................................................................... 10 

2.3. CASO 3: LA DOCUMENTACIÓN EN SMART CONTRACT COMO 

PRESUPUESTO DE ÂŤEFICACIAÂť. ...................................................................... 11 

2.4. CASO 4: LA INTRODUCCIÓN DE UN TERCERO DE CONFIANZA....... 15 

3. UN EJEMPLO DE APLICACIÓN: THE DAO ...................................................... 18 

4. EL PAGO ................................................................................................................ 20 

5. EJECUCIÓN: ¿TÍTULOS EJECUTIVOS? ............................................................ 21 

6. EL NOTARIADO Y LA FUERZA PROBATORIA ............................................. 24 

7. CONFLICTOS JURÍDICOS .................................................................................. 27 

III. REGULACIÓN EN LA ACTUALIDAD: DERECHO COMPARADO ................. 33 

1. ESTADOS UNIDOS .............................................................................................. 33 

2. EUROPA ................................................................................................................ 34 

IV. CONCLUSIONES ................................................................................................... 36 

BIBLIOGRAFÍA ............................................................................................................... i 



1 

 

 

I. INTRODUCCIÓN 

El mundo hoy se enfrenta a una nueva revoluciĂłn tecnolĂłgica. DetrĂĄs de las numerosas 

noticias sobre Bitcoin y el resto de las criptomonedas, que tanta expectaciĂłn e inversiĂłn 

estĂĄn generando, se encuentra la tecnologĂ­a Blockchain. Cada vez mĂĄs agentes comienzan 

a estudiar y experimentar con las posibilidades que ofrece la tecnologĂ­a de la cadena de 

bloques.   

Algunos precursores de esta disruptiva tecnologĂ­a prevĂŠn transformaciones tan 

trascendentales como la desapariciĂłn del intermediario bancario tal y como se conoce 

hoy, el cambio del papel que desempeĂąan los Estados, el modo en que se realizan las 

transacciones o incluso la funciĂłn de los jueces. Si bien es cierto que la potencialidad de 

esta tecnologĂ­a, sobre todo, en sede empresarial y legal es inmensa, la burbuja del ÂŤ.comÂť 

fue una lecciĂłn de prudencia ante el impacto de las nuevas tecnologĂ­as.  

En este sentido, Internet supuso una nueva forma de hacer negocios y un punto de 

inflexiĂłn para la comercializaciĂłn de productos mĂĄs allĂĄ de las fronteras. Ahora bien, 

estas nuevas realidades de contrataciĂłn electrĂłnica se encontraron con un cuerpo jurĂ­dico 

capaz de asemejar las instituciones existentes a estos nuevos fenĂłmenos, adaptĂĄndose a 

las nuevas circunstancias y resolviendo los conflictos que surgĂ­an. La regulaciĂłn de la 

contrataciĂłn mercantil y civil incorporĂł al rĂŠgimen negocial las nuevas exigencias de la 

contrataciĂłn electrĂłnica, de defensa de consumidores y usuarios que contrataban 

electrĂłnicamente y la regulaciĂłn sobre firma electrĂłnica, entre otras. 

AsĂ­ las cosas, es necesario un estudio concienzudo de la tecnologĂ­a Blockchain y, 

especialmente, de los Smart contracts en el ĂĄmbito jurĂ­dico, en aras de aprovechar todas 

las oportunidades que pueden ofrecer (eficiencia, reducciĂłn de costes, objetivaciĂłn de la 

ejecución de las prestaciones…) sin tropezar con la especulación que ya se sufrió a finales 

del siglo pasado.  

Comprender jurĂ­dicamente la figura de los Smart contracts, entendiendo las ventajas y 

los inconvenientes que plantean para ciertos negocios, asĂ­ como los retos legales que 

suponen las notas caracterĂ­sticas de estos acuerdos deviene primordial en este momento.  

La concreciĂłn de los marcos legales adecuados a los efectos de conseguir seguridad 

jurĂ­dica es fundamental para que se pueda extraer el mayor potencial de esta nueva 



2 

 

tecnologĂ­a sin descuidar los intereses de todas las partes involucradas: consumidores, 

instituciones pĂşblicas y empresa privada.  

Por ello, el estudio de la cuestiĂłn de los Smart contracts desde una perspectiva legal es 

imprescindible para generar seguridad y fomentar el emprendimiento en una tecnologĂ­a 

que se asemeja en impacto a la revoluciĂłn que supuso Internet.      

En este momento en el que la tecnologĂ­a se encuentra en un estadio incipiente, este estudio 

tiene por objetivos el anĂĄlisis de la figura del Smart contract, planteando si responde 

realmente a un contrato en sentido jurĂ­dico y las cuestiones que ello conlleva en tĂŠrminos 

de lenguaje, documentaciĂłn, cumplimiento de obligaciones, funciĂłn contractual y prueba, 

entre otros.   

El trabajo queda dividido en los siguientes capĂ­tulos:  

− Un primer capítulo introductorio de la tecnología Blockchain, explicando su 

funcionamiento y sus fundamentos.  

− Un segundo capítulo donde se profundiza en el análisis legal de los Smart 

contracts estudiando su carĂĄcter contractual, las cuestiones de forma y 

documentaciĂłn, la construcciĂłn de la figura del tercero de confianza y lo relativo 

al pago como cumplimiento de las prestaciones. Asimismo, se presenta un 

ejemplo de aplicaciĂłn real, el caso The DAO. 

− Un tercer capítulo en el que se examinan otras cuestiones jurídicas que se verán 

afectadas por los Smart contracts como son la cuestiĂłn de la funciĂłn del notariado, 

la fuerza probatoria y los nuevos motivos de litigiosidad entre contratantes.  

− Un cuarto capítulo en el que se recorre sucintamente las propuestas de ciertos 

paĂ­ses que estĂĄn regulando sobre la materia, como Estados Unidos o Malta.   

− Finalmente, se presentan las conclusiones del análisis, donde se resumen los 

aspectos mĂĄs relevantes de los Smart contracts en el marco jurĂ­dico actual.  

  



3 

 

II. BLOCKCHAIN 

1. QUÉ ES 

Blockchain es un controlador distribuido (en inglĂŠs, Distributed Ledger Technology o 

DLT), esto es, un registro o una base de datos que se comparte y se replica en una red de 

nodos (miembros) descentralizada (NAKAMOTO, 2008; BRAKEVILLE y PEREPA, 

2018).  

En otras palabras, Blockchain se ha entendido como un libro contable que se duplica 

tantas veces como nodos tenga la red y que se actualiza continuamente para que la 

informaciĂłn sea consistente en todo momento.  

En este libro, las transacciones se introducen por bloques de informaciĂłn que, una vez 

validados, se incorporan a la cadena replicada en toda la red. Cada bloque cuenta con: i) 

un cĂłdigo alfanumĂŠrico que identifica al bloque predecesor (hash); ii) las transacciones; 

iii) un cĂłdigo alfanumĂŠrico para identificar al bloque siguiente. AsĂ­ todos los registros 

cuentan con una firma criptogrĂĄfica Ăşnica y una marca temporal (MORA, 2018).  

La cadena de bloques es, por tanto, un historial de transacciones de activos organizadas 

en bloques encadenados para generar una Ăşnica fuente de verdad. De este modo, si alguno 

de los nodos quisiera modificar una entrada previa, tambiĂŠn tendrĂ­a que alterar toda la 

cadena de bloques posterior para que fuera consistente. El nodo malicioso deberĂ­a cumplir 

esta tarea antes de que el resto de los nodos acabasen con el bloque en que ya se estĂĄ 

trabajando, o el proceso volverĂ­a a empezar. La capacidad computacional para ello es 

prĂĄcticamente inabarcable, lo que garantiza la autenticidad de la informaciĂłn. Esta 

configuraciĂłn estĂĄ basada en lo que se conoce como proof of work.  

En este sentido, el uso mĂĄs conocido de Blockchain es el de las criptomonedas, mĂĄs 

concretamente Bitcoin. Estas criptomonedas se apoyan en el registro contable distribuido 

de Blockchain para recoger sus transacciones. Ahora bien, las monedas no dejan de ser 

unidades de valor (los denominados tokens) o activos. Por lo tanto, las posibilidades de 

la cadena de bloques son numerosas, sobre todo en aquellos ĂĄmbitos donde concurra una 

red (empresarial), transacciones y un registro consensuado a prueba de manipulaciĂłn. 

ÂżCuĂĄl es la novedad de esta tecnologĂ­a? En relaciĂłn con las comunicaciones tradicionales 

a travĂŠs de Internet, un rasgo inherente a ellas ha sido desarticulado en estos primeros 

pĂĄrrafos sin que el lector haya sido expresamente avisado: ha desaparecido el principio 



4 

 

doble gasto. La disrupciĂłn que trae consigo esta tecnologĂ­a es la posibilidad de transmitir 

ÂŤverdaderamenteÂť un activo, de modo que una vez usado no se puede volver a disponer 

de ĂŠl.  

Internet ha permitido la transmisiĂłn de archivos e informaciĂłn en todo el mundo 

conectado. No obstante, hasta ahora lo que se ha transmitido de un lugar a otro de la red 

son copias, puesto que nada impedĂ­a el doble gasto. Si A envĂ­a un archivo de mĂşsica a B 

a cambio de un precio, B no puede confiar en que A no se haya quedado una copia de ese 

archivo de mĂşsica con la canciĂłn en su dispositivo.  

Frente a este paradigma, Blockchain se configura como el libro contable donde registrar 

activos a nivel global. AsĂ­, la propiedad de A, la transmisiĂłn de A a B y la nueva 

titularidad de B son recogidas de forma pĂşblica y verificable en toda esa red. A no puede 

volver a transmitir tal activo porque al reflejar su previa titularidad y la transmisiĂłn en el 

registro, ya no dispone de ĂŠl frente a ningĂşn tercero; informaciĂłn que es accesible para 

todos los miembros.  

AdemĂĄs, no serĂĄ un tercer intermediario el que mantenga una relaciĂłn con A y verifique 

su titularidad, registre la transmisiĂłn y dĂŠ prueba de la nueva situaciĂłn de B. Es el sistema 

el que, construido a partir de la desconfianza entre sus miembros, garantiza las 

titularidades.  

Todos los nodos cuentan con una copia consistente del historial de A que actualizan con 

las nuevas transacciones, es decir, es la propia comunidad la que autentifica su titularidad 

y la transmisiĂłn. La verdad registrada se consigue por consenso, por la aprobaciĂłn de ese 

registro por la mayorĂ­a de los nodos o miembros de la red. AsĂ­, no existe un intermediario 

privilegiado en el que reside el poder de decisiĂłn sobre la verdad -tĂ­picamente, un banco 

que registre en sus libros contables el dinero del que dispone A, y la transmisiĂłn a la 

cuenta de B, informaciĂłn en la que ambas partes confĂ­an. En contra de lo que era habitual 

hasta ahora, no rige el principio de centralizaciĂłn y, por tanto, dado que nadie controla la 

informaciĂłn centralizadamente, nadie concentra el poder.  

En conclusiĂłn, Blockchain es la tecnologĂ­a que permite la transmisiĂłn de activos entre 

iguales sin la necesidad del intermediario tradicional.  

2. FUNCIONAMIENTO 

Sin ĂĄnimo de desarrollar tĂŠcnicamente el funcionamiento de Blockchain, se presenta un 

ejemplo simplificado de una transacción registrada en la cadena de bloques (PÉREZ-



5 

 

SOLÀ y HERRERA-JOANCOMARTÍ, 2014). El objetivo es mostrar los procesos de 

validaciĂłn, afianzamiento, transmisiĂłn y almacenamiento de forma accesible. 

En el ejemplo Ana (A) desea enviar a Benito (B) 25 BITCOIN (aunque podrĂ­a ser 

cualquier otro activo, 25 tokens). Para ello, tanto Ana como Benito cuentan con una clave 

pĂşblica y una privada: {PKA, SKA}, {PKB, SKB}. La funciĂłn Addr{PK) permite obtener 

la direcciĂłn de la clave pĂşblica PK, H es una funciĂłn Hash (vinculaciĂłn con el bloque 

anterior) y Sigsk(m) representa la firma de m con la clave privada.  

Ana ha recibido inicialmente 25 BTC: 

 To = {inputo, outputo}  

 Inputo = {…}  

 Outputo = {Addr(PKA), 25}  

Ana ha recibido a travĂŠs de su clave pĂşblica la cantidad de 25 BTC a los que va a acceder 

mediante su clave privada para enviĂĄrselos a Benito. Por ello:  

T1 = {input1, output1}  

  Input1 = {H(To), SigskA(To + output1), PKA}  

 Output1 = {Addr(PKB), 25}  

El protocolo está diseñado para que Ana señale su “situación contable” previa con el 

Hash, decida disponer de ello mediante su clave privada aludiendo a la transacciĂłn previa 

por la que tiene los 25 BTC que quiere transmitir y su clave pĂşblica. Ahora bien, esa 

situaciĂłn contable previa no es tanto un balance total asociado a Ana, sino un conjunto 

de transacciones previas a las que ella puede referirse para futuros movimientos, en el 

ejemplo sĂłlo ha habido una To. 

Asimismo, Ana transfiere a Benito solicitando su clave pĂşblica y determinando la 

cantidad a transmitir. En futuras transacciones Benito se referirĂĄ a esta T1 para una 

potencial T2, disponiendo con su clave privada y conociendo su clave pĂşblica por la que 

ha recibido T1.  

En tĂŠrminos de validaciĂłn, no hay doble gasto ya que T1 se remite a To y eso sĂłlo es 

posible una vez. AdemĂĄs, Ana es propietaria de los 25 BTC dado que existe una 

posiciĂłn/transacciĂłn previa To. En cuanto al afianzamiento, la prueba de trabajo (proof of 

work) garantiza el registro comĂşn Ăşnico de la informaciĂłn que sĂłlo podrĂĄ ser alterada si 



6 

 

se consigue un poder de cĂłmputo mayor del 50%. La transmisiĂłn de la transacciĂłn se 

propaga por toda la red y el almacenaje supone que todos los nodos contienen una copia 

completa de la cadena de bloque por lo que todos validan cada transacciĂłn nueva.  

En caso de que Ana quisiera transferir a Benito una cantidad diferente y necesariamente 

menor a la recibida en To (por ejemplo, 20 BTC) el modelo varĂ­a, pero se consigue 

mantener las mismas virtudes. Grosso modo, Ana envĂ­a 25 BTC, recibiendo una 

transferencia por valor de 5 BTC que es el sobrante. Esta nueva transacción (T1’) de valor 

5 BTC permite a Ana disponer de lo que le queda; puesto que To ya ha sido gastada. Por 

su parte, Benito recibe los 20 BTC y cuenta con una transacción (T1’’) a la que referirse 

para futuras transacciones (COINEST.CO, 2017). 

Cabe seĂąalar que la cadena de bloques, en principio, no se preocupa del contrato 

subyacente por el cual Ana envĂ­a 25 BTC a Benito, ni siquiera de si la cantidad debida 

era mayor o inferior. Blockchain permite y registra la transacciĂłn. De igual manera que 

una entidad bancaria transmite lo que su cliente ordena a otra cuenta, independientemente 

del contrato subyacente; la cadena de bloques recoge la transacciĂłn y da prueba de ella. 

Por tanto, serĂĄ la justicia, en su caso, la que posteriormente decida si se ha cumplido el 

contrato; si bien, el juez podrĂĄ acudir a Blockchain para confirmar que efectivamente 25 

BTC ya han sido transferidos. Todo ello serĂĄ discutido en los siguientes capĂ­tulos.  

En conclusiĂłn, se obtiene un sistema de transmisiĂłn que es secuencial (garantiza un orden 

cronolĂłgico), consistente, resistente, distribuido, que evita el doble gasto y que no 

requiere de un intermediario, sino de una red de miembros.  

  



7 

 

III. SMART CONTRACTS 

Un Smart contract es un cĂłdigo de programaciĂłn informĂĄtico que permite, por operaciĂłn 

del propio ordenador, monitorizar y/o ejecutar un contrato, sin necesidad de intervenciĂłn 

humana (SZABO, 1994; STOKES y FREIRE RAMOS, 2017).  

En lĂ­nea con lo seĂąalado en el apartado anterior, un Smart contract permite transacciones 

mĂĄs complejas que la que concurrĂ­a entre los protagonistas del ejemplo mostrado. El 

cĂłdigo genera una cuenta ajena y controlada que ejecuta transacciones ante ciertas 

condiciones codificadas.  

En general, los Smart contracts cuentan con tres atributos a destacar respecto de los 

negocios habituales; son acuerdos autoejecutables, digitales y descentralizados. Ser 

autoejecutable implica que, si las condiciones predefinidas en el programa se cumplen, la 

consecuencia contractual se ejecuta de manera autĂłnoma. Esto es, las partes registran las 

condiciones y los hechos que deben estar configurados siguiendo el modelo: ÂŤsi X, 

entonces YÂť. De esta forma, una vez concurre el hecho desencadenante, el cumplimiento 

de la consecuencia escapa de la voluntad de las partes, es un hecho que tambiĂŠn ocurrirĂĄ. 

Por su parte, su conformaciĂłn digital permite que se halle en Blockchain y que pueda ser 

interpretado tanto por humanos como por mĂĄquinas. Esta interpretaciĂłn consiste en que 

las mĂĄquinas pueden leerlo y ejecutarlo, sin que sea posible (todavĂ­a) atribuirles una 

comprensiĂłn real de lo establecido. Finalmente, la descentralizaciĂłn evita al 

intermediario y proporciona veracidad y seguridad, gracias a la tecnologĂ­a de la cadena 

de bloques.  

Por Ăşltimo, se debe aĂąadir que existe la posibilidad de introducir datos en los Smart 

contracts a partir de fuentes de informaciĂłn externas a Blockchain. Los denominados 

oracles (u orĂĄculos) son tales fuentes externas que permiten a los Smart contracts ampliar 

su ĂĄmbito de aplicaciĂłn. PiĂŠnsese en una orden de compra de acciones cuando la 

cotizaciĂłn alcance un determinado nivel. El Smart contract se configura para que 

confirme la informaciĂłn con una determinada fuente (por ejemplo, la web oficial bolsa 

de Madrid) que las partes consideran fiable. AdemĂĄs, ya se estĂĄn planteando orĂĄculos en 

que la informaciĂłn responde a mĂĄs de una fuente, introduciendo el consenso y mayor 

fiabilidad a la informaciĂłn.  

A partir de todo lo expuesto, deviene necesario identificar la realidad jurĂ­dica que 

representan los Smart contracts, asĂ­ como alguno de los retos que plantean.  



8 

 

1. CONCEPTO Y TIPOLOGÍA 

Una vez mostradas las ideas fundamentales de un Smart contract, se debe tener en cuenta 

que este concepto nace del ĂĄmbito tecnolĂłgico y no del jurĂ­dico. AsĂ­ las cosas, el tĂŠrmino 

recoge una amplia gama de posibilidades, desde meros cĂłdigos de ordenador que ejecutan 

Ăłrdenes hasta cĂłdigos complejos que representan y acogen un ÂŤcontratoÂť.  

Con el objetivo de centrar el objeto de estudio resultan prĂĄcticas e interesantes las 

clasificaciones que realizan dos autores.  

STARK (2016) diferencia entre lo que ĂŠl denomina ÂŤSmart Contract CodeÂť y ÂŤSmart 

Legal ContractÂť. El primero hace referencia a un programa complejo, almacenado y 

ejecutado en Blockchain que gobierna algo valioso. Mientras, el segundo, utiliza el cĂłdigo 

para articular, verificar y hacer cumplir un acuerdo, combinando lenguaje mĂĄquina y 

natural. El valor de distinguir ambos conceptos reside en apartar del estudio aquellos 

cĂłdigos que no recogen un contenido jurĂ­dico relevante.  

Tomando los Smart Legal Contracts como punto de partida, se utilizarĂĄ la clasificaciĂłn 

material de FELIU REY (2018) para mostrar las realidades que abarca este concepto. En 

primer lugar, el cĂłdigo puede recoger por entero un previo contrato para su cumplimiento. 

En segundo lugar, el cĂłdigo puede ser el acuerdo, sin que coexista un soporte alternativo. 

En tercer lugar, el cĂłdigo puede recoger sĂłlo ciertas obligaciones de un negocio concluido 

previamente. En cuarto lugar, siendo una variante de los anteriores, el cĂłdigo puede 

responder a un contrato acordado en otro soporte en el que se ha decidido que ciertas 

obligaciones se establezcan directamente como Smart Legal Contract, por lo que ellas no 

cuentan con rĂŠplica en el negocio en lenguaje natural.  

Estas realidades merecen una calificaciĂłn jurĂ­dica distinta. Es por ello que, en los 

subsiguientes apartados, se valorarĂĄ cada uno de estos modelos de Smart Legal Contract 

y se plantearĂĄn las cuestiones legales mĂĄs relevantes.  

2. CALIFICACIÓN JURÍDICA 

En primer lugar, conviene realizar una introducciĂłn a la distinciĂłn entre forma y 

documentaciĂłn del contrato. Si bien esta diferenciaciĂłn no es nueva en materia de 

contrataciĂłn, resulta imprescindible recordarla en lo relativo a los Smart contracts.  

DÍEZ-PICAZO (2007) define la forma como «el vehículo o medio de expresión del cual 

las partes se sirven para emitir sus declaraciones de voluntad y para hacerlas llegar o 



9 

 

darlas a conocer a sus destinatariosÂť, mientras que documentaciĂłn es ÂŤla operaciĂłn 

necesaria para plasmar y recoger documentalmente las declaraciones de voluntad que 

forman la esencia del contratoÂť. 

AsĂ­ las cosas, el autor recalca la importancia de no confundir ambos conceptos. Es 

necesario distinguir que el documento puede no ser la forma, es decir, el medio de 

manifestar la voluntad, sino un documento posterior al contrato ya perfeccionado con el 

objetivo principal de conservarlo.  

El anĂĄlisis del autor sobre las situaciones entre acuerdo no documentado y documentaciĂłn 

constitutiva, acuerdo no documentado y documentaciĂłn como presupuesto de eficacia, 

asĂ­ como la de documentaciĂłn privada y necesidad de Escritura PĂşblica se pueden utilizar 

de soporte para analizar los diferentes supuestos de Smart contracts.   

2.1. CASO 1: EL CÓDIGO NO COEXISTE CON OTRO DOCUMENTO EN 

LENGUAJE NATURAL.  

En este primer caso, el Smart contract es la forma. El cĂłdigo es el vehĂ­culo mediante el 

cual las partes emiten sus declaraciones y manifiestan sus voluntades. Asimismo, el Smart 

contract tambiĂŠn es el documento escogido por las partes. Esto es, se concentran en el 

Smart contract la representaciĂłn de un contrato y la funciĂłn de recogerlo, fijarlo y 

conservarlo.  

Siendo el cĂłdigo el Ăşnico soporte en el que se plasma el contrato el reto principal de este 

caso es la comprensibilidad del lenguaje. PiĂŠnsese en un supuesto de DAO, donde las 

condiciones son pĂşblicas para cualquier miembro de la red, quien se puede adherir a las 

mismas, pero sĂłlo son legibles en formato cĂłdigo. AsĂ­, es necesario cuestionar si las 

partes emiten conscientemente el consentimiento cuando no hay “traducción” al lenguaje 

natural.  

SURDEN (2012), junto con otros autores, plantea algunas soluciones. Por un lado, la 

coexistencia de un contrato en lenguaje natural que sirva de sustrato y que incorpore el 

cĂłdigo, asĂ­ como la interpretaciĂłn de ĂŠste. Por otro, propone que las partes se suscriban a 

un estĂĄndar de datos preexistente que garantice una cierta interpretaciĂłn de los datos y las 

fĂłrmulas utilizadas. AdemĂĄs, se propone el uso de interfaces que traduzcan lo introducido 

en lenguaje natural a lenguaje mĂĄquina de una determinada manera. AsĂ­, las partes estĂĄn 

acordando implĂ­citamente que los criterios de la interfaz sean entendidos como los 

tĂŠrminos de interpretaciĂłn y traducciĂłn del acuerdo. Por Ăşltimo, los contratantes tambiĂŠn 



10 

 

pueden suscribir un acuerdo marco donde se determinan estas condiciones para aplicarlas 

a un conjunto de Smart contracts. 

En todo caso, las cuestiones de comprensibilidad son parecidas a las que concurren en 

sede de contrataciĂłn mercantil internacional, donde convergen diferentes ordenamientos 

y lenguajes. La funciĂłn que venĂ­a desarrollando el traductor e intĂŠrprete colaborando con 

el abogado o jurista para diseĂąar el contrato, corresponderĂĄ ahora al programador.  

En conclusiĂłn, el cĂłdigo puede ser una forma vĂĄlida, un medio de expresiĂłn reconocible 

por el derecho. En este sentido, conforme aumente la prĂĄctica contractual y dado que estos 

Smart contract tienen vocaciĂłn internacional, es fĂĄcil que los problemas de 

comprensibilidad vayan resolviĂŠndose. La elaboraciĂłn de cĂłdigos que uniformicen las 

fĂłrmulas, las interfaces o los acuerdos marco que se pueden tomar de referencia harĂĄn 

posible que ciertas transcripciones/traducciones sean aceptadas y sirvan de base para las 

subsiguientes.    

Con todo, si se tratara de un contrato que incorpora condiciones generales, hay que 

recordar que el art. 7.b) de la Ley 7/1998, de 13 de abril, sobre condiciones generales de 

la contrataciĂłn determina la no incorporaciĂłn de las condiciones generales que sean 

ÂŤilegibles, ambiguas, oscuras e incomprensiblesÂť. Por consecuencia, resultarĂĄ difĂ­cil 

aceptar que en estos casos sea posible la adhesiĂłn sin un previo acuerdo en lenguaje 

natural que muestre claramente las obligaciones. 

Asimismo, el Real Decreto Legislativo 1/2007, de 16 de noviembre, por el que se aprueba 

el texto refundido de la Ley General para la Defensa de los Consumidores y Usuarios, en 

concreto respecto a los contratos con consumidores y usuarios que utilizan clĂĄusulas no 

negociadas individualmente, exige claridad en su redacciĂłn, accesibilidad y legibilidad 

(artĂ­culo 80). Estos principios, a mi juicio, no se cumplirĂ­an cuando el acuerdo sĂłlo sea 

accesible en formato cĂłdigo.  

2.2. CASO 2: SMART CONTRACT COMO EXIGENCIA DE FORMA 

CONSTITUTIVA. 

En principio, la regulaciĂłn ampara la libertad de forma a la luz de los artĂ­culos 1.278 de 

CĂłdigo Civil (en adelante, Cc) y 51 del CĂłdigo de Comercio (en adelante, CCom). 

AdemĂĄs, los Principios UNIDROIT sobre los contratos comerciales internacionales 

(2016) consagran la libertad de forma en su artĂ­culo 1.2. A ello se aĂąade el reconocimiento 

de la forma electrĂłnica en las mismas condiciones que el soporte papel, art. 24 LSSI.  Por 



11 

 

lo que, a priori, el hecho de que el contrato se documente en cĂłdigo no es requisito 

constitutivo.  

En este sentido, FELIU REY (2018) seĂąala la posibilidad de que las partes pueden otorgar 

a la documentaciĂłn el mencionado carĂĄcter constitutivo, al amparo del art. 1.255 Cc. Esta 

posibilidad tambiĂŠn ha sido confirmada a nivel internacional en el artĂ­culo 2.1.13 de los 

mencionados Principios UNIDROIT (2016). De este modo, hasta que las obligaciones no 

queden plasmadas en un Smart contract, no hay contrato perfecto.  

El desarrollo de las negociaciones previas responde en el iter contractual a tratos 

preliminares, a la negociaciĂłn. AsĂ­, las partes podrĂĄn acudir a los Ăłrganos jurisdiccionales 

competentes en términos de responsabilidad precontractual (DÍEZ-PICAZO, 2007; 

MARTÍNEZ DE AGUIRRE, 2000).  

En conclusiĂłn, se estĂĄ ante un contrato formal en el que las partes acuerdan que el cĂłdigo 

sea la forma elegida. Al otorgarle carĂĄcter constitutivo a la documentaciĂłn en Smart 

contract, el documento privado o acuerdo verbal precedente no se instituye en fuente de 

obligaciones convencional y queda en el ĂĄmbito de los tratos preliminares.    

2.3. CASO 3: LA DOCUMENTACIÓN EN SMART CONTRACT COMO 

PRESUPUESTO DE ÂŤEFICACIAÂť.  

Este supuesto no plantea duda sobre la calificaciĂłn jurĂ­dica de contrato celebrado con 

anterioridad al cĂłdigo. En la medida en que existe este acuerdo en lenguaje natural, si en 

ĂŠl concurren los requisitos de consentimiento, objeto y causa que exige el CĂłdigo Civil 

en su artĂ­culo 1.261, deberĂĄ calificarse de contrato vĂĄlido. 

En cuanto al consentimiento, conforme al art. 1.262 Cc, se manifiesta por el concurso de 

la oferta y la aceptaciĂłn; y desde que las partes consienten a obligarse el contrato existe, 

al amparo del artĂ­culo 1.254 Cc. En este sentido, puede ser aplicable lo relativo a la 

contrataciĂłn entre ausentes y/o a distancia, pero no necesariamente.  

Así, con OBREGÓN SIEGMUND (2012), la contratación a distancia implica una 

separaciĂłn geogrĂĄfica entre las partes contratantes mientras que la contrataciĂłn entre 

ausentes exige un lapso temporal entre oferta y aceptaciĂłn. Esto es relevante por cuanto 

un contrato como el analizado puede existir tanto entre presentes, ya sea fĂ­sicamente 

acordando el negocio y la forma de Smart contract, ya sea virtualmente por medios 

tĂŠcnicos como la videoconferencia; como entre ausentes, pensando en una oferta reflejada 



12 

 

en la Web que posteriormente acepta un sujeto. Igualmente, puede tratarse de un contrato 

a distancia o no, si las partes se reĂşnen a negociar este acuerdo y la aplicaciĂłn de un Smart 

contract.  

Todo ello permite afirmar que, aunque el contrato quede recogido en un Smart contract, 

no necesariamente se tratarĂĄ de un contrato cele";"""date"",""2019-01-16T15:36:39Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.7""
""xmp:CreatorTool"",""MicrosoftÂŽ Word 2016""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dc:creator"",""Irene Ortega""
""language"",""es""
""dcterms:created"",""2019-01-16T15:36:39Z""
""Last-Modified"",""2019-01-16T15:36:39Z""
""dcterms:modified"",""2019-01-16T15:36:39Z""
""dc:format"",""application/pdf; version=1.7""
""xmpMM:DocumentID"",""uuid:EEF678E9-2ABE-4520-9EDF-B138F116E68F""
""Last-Save-Date"",""2019-01-16T15:36:39Z""
""pdf:docinfo:creator_tool"",""MicrosoftÂŽ Word 2016""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2019-01-16T15:36:39Z""
""meta:save-date"",""2019-01-16T15:36:39Z""
""pdf:encrypted"",""false""
""xmp:CreateDate"",""2019-01-16T16:36:39Z""
""modified"",""2019-01-16T15:36:39Z""
""Content-Length"",""1020762""
""pdf:hasMarkedContent"",""true""
""Content-Type"",""application/pdf""
""xmp:ModifyDate"",""2019-01-16T16:36:39Z""
""pdf:docinfo:creator"",""Irene Ortega""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Irene Ortega""
""dc:language"",""es-ES""
""meta:author"",""Irene Ortega""
""pdf:producer"",""MicrosoftÂŽ Word 2016""
""meta:creation-date"",""2019-01-16T15:36:39Z""
""created"",""2019-01-16T15:36:39Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""48""
""Creation-Date"",""2019-01-16T15:36:39Z""
""resourceName"",""290001035.pdf""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""496"",""2092"",""628"",""2737"",""2357"",""1828"",""2391"",""2440"",""2000"",""1754"",""2455"",""2410"",""2422"",""2456"",""2403"",""2533"",""2635"",""2561"",""2537"",""2663"",""2605"",""2381"",""2624"",""2430"",""2422"",""2523"",""2640"",""2428"",""2461"",""2423"",""1931"",""2609"",""2718"",""2462"",""2679"",""1501"",""2259"",""2366"",""1136"",""2283"",""2545"",""1777"",""1737"",""1760"",""2033"",""1998"",""1985"",""1254""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""Author"",""Irene Ortega""
""producer"",""MicrosoftÂŽ Word 2016""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""MicrosoftÂŽ Word 2016""
""pdf:docinfo:created"",""2019-01-16T15:36:39Z""
";https://scholar.google.com/scholar?start=570&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094560-739;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Bidirectional asynchronous ratcheted key agreement with linear complexity;FB Durak, S Vaudenay ; International Workshop on Security, 2019  Springer;;"… At CRYPTO 2018, Poettering and Rösler (PR) [15] studied bidirectional asynchronous ratcheted

key … and presented a protocol which is secure in the random oracle model … and a signature scheme

and achieve strong security, without key-update primitives or random oracles …";Cité 20 fois;Les 3 versions;[PDF] epfl.ch;https://infoscience.epfl.ch/record/270821/files/sec_comm.pdf;"
Bidirectional Asynchronous Ratcheted Key Agreement

with Linear Complexity⋆

F. Betül Durak1,2 and Serge Vaudenay1

1 Ecole Polytechnique Fédérale de Lausanne (EPFL)
Lausanne, Switzerland

2 Robert Bosch LLC — Research and Technology Center
Pittsburgh PA, USA

Abstract. Following up mass surveillance and privacy issues, modern secure communica-
tion protocols now seek more security such as forward secrecy and post-compromise security.
They cannot rely on an assumption such as synchronization, predictable sender/receiver
roles, or online availability. Ratcheting was introduced to address forward secrecy and post-
compromise security in real-world messaging protocols. At CSF 2016 and CRYPTO 2017,
ratcheting was studied either without zero round-trip time (0-RTT) or without bidirectional
communication. At CRYPTO 2018, ratcheting with bidirectional communication was done
using heavy key-update primitives. At EUROCRYPT 2019, another protocol was proposed.
All those protocols use random oracles. Furthermore, exchanging n messages has complexity
O(n2) in general.

In this work, we define the bidirectional asynchronous ratcheted key agreement (BARK)
with formal security notions. We provide a simple security model and design a secure BARK

scheme using no key-update primitives, no random oracle, and with O(n) complexity. It is
based on a public-key cryptosystem, a signature scheme, one-time symmetric encryption,
and a collision-resistant hash function family. We further show that BARK (even unidirec-
tional) implies public-key cryptography, meaning that it cannot solely rely on symmetric
cryptography.

1 Introduction

In standard communication systems, protocols are designed to provide messaging services with
end-to-end encryption. Essentially, secure communication reduces to continuously exchanging keys,
because each message requires a new key. In bidirectional two-party secure communication, partic-
ipants alternate their role as senders and receivers. The modern instant messaging protocols are
substantially asynchronous. In other words, for a two-party communication, the messages should
be transmitted (or the key exchange should be done) even though the counterpart is not online.
Moreover, to be able to send the payload data without requiring online exchanges is a major design
goal called zero round trip time (0-RTT). Finally, the moment when a participant wants to send
a message is undefined, meaning that participants use random roles (sender or receiver) without
any synchronization. They could send messages at the same time.

Even though many systems were designed for the privacy of their users, they rapidly faced
security vulnerabilities caused by the compromises of the participants’ states. In this work, com-
promising a participant means to obtain some information about its internal state. We will call it
exposure. The desired security notion is that compromised information should not uncover more
than possible by trivial attacks. For instance, the compromised state of participants should not
allow decryption of messages exchanged in the past. This is called forward secrecy. Typically, for-
ward secrecy is obtained by updating states with a one-way function x → H(x) → H(H(x)) → ...
and deleting old entries. It is used, for instance, in RFID protocols [14, 15]. A popular technique
in mechanics, that allows forward movement but prevents moving backward is the use of a de-
vice called ratchet. In the context of secure communication, a ratchet-like action is achieved by

⋆ A short version of this paper appeared at IWSEC 2019 [9].



using randomness in every state update so that a compromised state is not sufficient for the de-
cryption of any future communication either. This is called future secrecy or backward secrecy or
post-compromise security or even self-healing. One thesis of the present work is that healing after
an active attack involving a forgery is not a nice property. We show that it implies insecurity.
After one participant is compromised and impersonated, if communication self-heals, it means
that some adversary can make a trivial attack which is not detected. We also demonstrate other
events leading to breach of security. Hence, we recommend that communication is totally cut after
active attacks.

Previous work. The security of key exchange was studied by many authors. The prominent models
are the CK and eCK models [4, 13].

Techniques for ratcheting first appeared in real life protocols. It appeared in the Off-the-
Record (OTR) communication system by Borisov et al. [3]. The Signal protocol designed by
Open Whisper Systems [17] later gained a lot of interest from message communication companies.
Today, the WhatsApp messaging application has reached billions of users worldwide [20]. It uses
the Signal protocol. A broad survey about various techniques and terminologies was made at
S&P 2015 by Unger et al. [18]. At CSF 2016, Cohn-Gordon et al. [6] studied bidirectional ratcheted
communication and proposed a protocol. However, their protocol does not offer 0-RTT and requires
synchronized roles. At EuroS&P 2017, Cohn-Gordon et al. [5] formally studied Signal.

0-RTT communication with forward secrecy was achieved using puncturable encryption by
Günther et al. at EUROCRYPT 2017 [10]. Later on, at EUROCRYPT 2018, Derler et al. made
it reasonably practical by using Bloom filters [7].

At CRYPTO 2017, Bellare et al. [2] gave a secure ratcheting key exchange protocol. Their
protocol is unidirectional and does not allow receiver exposure.

At CRYPTO 2018, Poettering and Rösler (PR) [16] studied bidirectional asynchronous ratch-
eted key agreement and presented a protocol which is secure in the random oracle model. Their
solution further relies on hierarchical identity-based encryption (HIBE) but offers stronger security
than required for practical usage, leaving ample room for improving the protocol. At the same
conference, Jaeger and Stepanovs (JS) [11] had similar results but focused on secure communica-
tion rather than key agreement. They proposed another protocol relying on HIBE. In both results,
HIBE is used to construct encryption/signature schemes with key-update security. This is a rather
new notion allowing forward secrecy but is expensive to achieve. In both cases, it was claimed
that the depth of HIBE is really small. However, when participants are disconnected and continue
sending several messages, the depth increases quite rapidly. Consequently, HIBE needs unbounded
depth.

Two papers appeared after the first version of the current paper was released.
At EUROCRYPT 2019, Jost, Maurer, and Mularczyk (JMM) [12] designed another ratcheting

protocol which has “near-optimal” security and does not use HIBE. Nevertheless, it still has a
huge complexity: When messages alternate well (i.e., no participant sends two messages without
receiving one in between), processing n messages requires O(n) operations in total. However, when
messages accumulate before alternating (for instance, because the participants are disconnected
by the network), the complexity becomes O(n2). This is also the case for PR [16] and JS [11].3

One advantage of the JMM protocol [12] comes with the resilience with random coin leakage as
discussed below.

At EUROCRYPT 2019, Alwen, Coretti, and Dodis (ACD) [1] designed two other ratcheting
protocols aiming at immediate decryption, i.e. the ability to decrypt even though some previous
messages have not been received yet. This is closer to real-life protocols but this comes with a
potential threat: keys to decrypt un-delivered messages are stored until the messages are delivered.
Hence, the adversary could choose to hold messages and decrypt them with future state exposure.
This prevents forward secrecy. Furthermore, unless the direction of communication changes (or

3 For JS, this is only visible in the corrected version of the paper on eprint [11]. Our complexity analysis
is based on how those protocols have been implemented (https://github.com/qantik/ratcheted). It
was presented at the WSM 2019 workshop.

2



more precisely, if the epoch increases), their protocols do not strictly adhere to the definition of
ratcheting as no random coins are used to update the state. This weakens post-compromise se-
curity as well. In Table 1, we call this weaker security “id-optimal” (not to say “insecure” in the
model we are interested in) because it is the best we can obtain with immediate decryption. The
lighter of the two protocols is not competing in the same category because it mostly uses sym-
metric cryptography. It is more efficient but with lower security. Namely, corrupting the state of a
participant A implies impersonating B to A, and also decrypting the messages that A sends. Other
protocols do not have this weakness. The second ACD [1] (in the full version) uses asymmetric
cryptography.

Some authors address the corruption of random coins in different ways. Bellare et al. [2] and
JMM [12] allow leaking the random coins just after use. JS [11] allow leaking it just before usage
only. ACD [1] allow adversarially chosen random coins. In most of the protocols, revealing (or
choosing) the random coins imply revealing some part of the new state which allows decrypting
incoming messages. It is comparable to state exposure. JMM [12] offers better security as revealing
the random coins reveals the new state (and allows to decrypt) only when the previous state was
already known.

Table 1: Comparison of Protocols: complexity for exchanging n messages in alternating or accumu-
lating mode, with timing (in seconds) for n = 900 of comparable implementations and asymptotic;
and types of coin-leakage security (⇒ state exposure means coins leakage implies a state exposure).

Security Complexity Coins leakage resilience Model
alternating accumulating

Poettering-Rösler [16] optimal 86.3 , O(n) 5897 , O(n2) no ROM

Jaeger-Stepanovs [11] optimal 58.1 , O(n) 9087 , O(n2) pre-send leakage, ⇒ state exposure ROM

Jost-Maurer-Mularczyk [12] near-optimal 2.08 , O(n) 11.4 , O(n2) post-send leakage ROM

BARK [this paper] sub-optimal 1.46 , O(n) 1.09 , O(n) no plain

Alwen-Coretti-Dodis [1] id-optimal 1.18 , O(n) 0.92 , O(n) chosen coins, ⇒ state exposure plain

Our contributions. We give a definition for a bidirectional asynchronous key agreement (BARK)
along with security properties. We start setting the stage with some definitions (such as matching
status) then identify all cases leading to trivial attacks. We split them into direct and indirect
leakages. Then, we define security with a KIND game (privacy). We also consider the resistance
to forgery (impersonation) and the resistance to attacks which would heal after active attacks
(RECOVER security). We use these two notions as building blocks to prove KIND-security. We
finally construct a secure protocol. Our design choices are detailed below and compared to other
papers. More comprehensive and technical comparisons between BARK and Bellare et al. [2],
JS [11], and PR [16] protocols are given in Appendix C.

1. Simplicity. Contrary to previous work, we define KIND security in a very comprehensive
way by bringing all notions under the umbrella of a cleanness predicate which identifies and
captures all trivial ways of attacking.

2. Strong security. In the same line as previous works, the adversary in our model can see
the entire communication between participants and control the delivery. Of course, he can replace
messages with anything. Scheduling communications is under the control of the adversary. This
means that the time when a participant sends or receives messages is decided by the adversary.
Moreover, the adversary is capable of corrupting participants by making exposures of their internal
data. We separate two types of exposures: the exposure of the state (that is kept in internal
machinery of a participant) and the exposure of the key (which is produced by the key agreement
and given to an external protocol). This is because states are (normally) kept secure in our protocol

3



while the generated key is transferred to other applications which may leak for different reasons.
We do not consider exposure of the random coins.

3. Slightly sub-optimal security. Using the result from exposure allows the adversary to
be active, e.g. by impersonating the exposed participant. However, the adversary is not allowed
to use exposures to make a trivial attack. Identifying such trivial attacks is not easy. As a design
goal, we adopt not to forbid more than what the intuitive notion of ratcheting captures. We
do forbid a bit more than PR [16] and JS [11] which are considered of having optimal security

and than JMM [12] (which has near-optimal security)4, though, allowing lighter building blocks.
Namely, we need no key-update primitives and have linear-time complexity in terms of the number
of exchanged messages, even when the network is occasionally down. This translates to an
important speedup factor, as shown on Table 1. We argue that this is a reasonable choice
enabling ratchet security as we define it: unless trivial leakage, a message is private as long as it
is acknowledged for reception in a subsequent message from the receiver.

4. Sequence integrity. We believe that duplex communication is reliably enforced by a lower
level protocol. This is assumed to solve non-malicious packet losses e.g. by resend requests and
also to reconstruct the correct sequence order. What we only have to care of is when an adversary
prevents the delivery of a message consistently. We make the choice to make the transmission of
the next messages impossible under such an attack. Contrarily, ACD [1] advocates for immediate
decryption, even though one message is missing. This lowers the security and we chose not to have
it.

In the BARK protocol, the correctness implies that both participants generate the same keys.
We define the stages matching status, direct leakage, indirect leakage. We aim to separate trivial
attacks and trivial forgeries from non-trivial cases with our definitions. Direct and indirect leak-
ages define when the adversary can trivially deduce the key generated due to the exposure of a
participant who can either be the same participant (direct) or their counterpart (indirect).

We construct a secure BARK protocol. We build our constructions on top of a public-key
cryptosystem and a signature scheme and achieve strong security, without key-update primitives
or random oracles. We further show that a weakly secure unidirectional BARK implies public-key
cryptography.

Notations. We have two characters: Alice (A) and Bob (B). When P designates a participant,
P refers to P’s counterpart. We use the roles send and rec for sender and receiver respectively.
We define send = rec and rec = send. When participants A and B have exclusive roles (like in
unidirectional cases), we call them sender S and receiver R.

Structure of the paper. In Section 2, we define our BARK protocol along with correctness definition
and KIND security. Section 3 proves that a simple unidirectional scheme implies public-key encryp-
tion. In Section 4 we define the security notions unforgeability and unrecoverability. In Section 5,
we give our BARK construction. Appendix A recalls definitions for underlying primitives. Using
plaintext-aware security, Appendix B shows that “optimally secure” protocols may still eliminate
attacks which are of no harm, hence eliminate more than necessary. In Appendix C, we make
some comments and comparison with the results of Bellare et al. [2], Poettering-Rösler [16], and
Jaeger-Stepanovs [11].

2 Bidirectional Asynchronous Ratcheted Communication

2.1 BARK Definition and Correctness

Definition 1 (BARK). A bidirectional asynchronous ratcheted key agreement (BARK) consists
of the following polynomially bounded algorithms:

– Setup(1λ)
$
−→ pp: This defines the common public parameters pp.

4 Those terms are more formally explained on p. 11.

4



– Gen(1λ, pp)
$
−→ (sk, pk): This generates the secret key sk and the public key pk of a participant.

– Init(1λ, pp, skP, pkP,P) → stP: This sets up the initial state stP of P given his secret key and
the public key of his counterpart.

– Send(stP)
$
−→ (st ′P, upd,k): The algorithm inputs a current state stP for P ∈ {A,B}. It outputs

a tuple (st ′P, upd,k) with an updated state st ′P, a message upd, and a key k.

– Receive(stP, upd) → (acc, st ′P,k): The algorithm inputs (stP, upd) where P ∈ {A,B}. It outputs
a triple consisting of a flag acc ∈ {true, false} to indicate an accept or reject of upd information,
an updated state st ′P, and a key k i.e. (acc, st ′P,k).

For convenience, we define the following initialization procedure for all games. It returns the initial
states as well as some publicly available information z.

Initall(1Îť, pp):
1: Gen(1λ, pp)→ (skA, pkA)
2: Gen(1λ, pp)→ (skB, pkB)
3: stA ← Init(1λ, pp, skA, pkB,A)

4: stB ← Init(1λ, pp, skB, pkA,B)
5: z← (pp, pkA, pkB)
6: return (stA, stB, z)

Initialization is splittable in the sense that private keys can be generated by their holders with no
need to rely on an authority (except maybe for authentication of pkA and pkB). Other protocols
from the literature assume a trusted initialization.

We consider bidirectional asynchronous communications. We can see, in Fig. 1, Alice and Bob
running some sequences of Send and Receive operations without any prior agreement. Their time
scale is different. This means that Alice and Bob run algorithms in an asynchronous way. We
consider a notion of time relative to a participant P. Formally, the time t for P is the number
of elementary steps that P executed since the beginning of the game. We assume no common
clock. However, events occur in a game and we may have to compare the time of two different
participants by reference to the scheduling of the game. E.g., we could say that time tA for A

happens before time tB for B. Normally, scheduling is under the control of the adversary except in
the CORRECT game in which there is no adversary. There, we define the scheduling by a sequence
of actions. Reading the sequence tells who executes a new step of the protocol.

The protocol also uses random roles. Alice and Bob can both send and receive messages. They
take their role (sender or receiver) in a sequence, but the sequences of roles of Alice and Bob
are not necessarily synchronized. Sending/receiving is refined by the RATCH(P, role, [upd]) call in
Fig. 2.

Correctness. We say that a ratcheted communication protocol functions correctly if the receiver
accepts the update information upd and generates the same key as its counterpart. Correctness
implies that the received keys for participant P have been generated in the same order as sent keys
of participant P. We formally define the CORRECT game in Fig. 2. We define variables. receivedPkey
(respectively sentPkey) keeps a list of secret keys that are generated by P when running Receive

(respectively, Send). Similarly, receivedPmsg (respectively sentPmsg) keeps a list of upd information
that are received (respectively sent) by P and accepted by Receive. The received sequences only
keep values for which acc = true.

Each variable v such as receivedPmsg, kP, or stP is relative to a participant P. We denote by

v(t) the value of v at time t for P. For instance, receivedAmsg(t) is the sequence of upd which were
received by A at time t for A.

We initialize the two participants in the CORRECT game in Fig. 2. The scheduling is defined
by a sequence sched of tuples of form either (P, send) (saying that P must send) or (P, rec) (saying
that P must receive). In this game, communication between the participants uses a waiting queue
for messages in each direction. Each participant has a queue of incoming messages and is pulling
them in the order they have been pushed in. Sent messages from P are buffered in the queue of P.

5



(TInit)Alice BobreceivedAlicekeysentAlicekey receivedBobkey sentBobkey

Send

(T0)

Send

(T1)

Receive

(T2)

Send

(T3)

Receive

(T4)

...

Send

(T5)

Send

(T6)

Send

(T7)

Receive

(T8)

Send

(T9)

Receive

(T10)

Receive

(T11)

k0

k1

k2

k4

k3

k2

k3

k5

k0

k6

k1

k4

Fig. 1: The message exchange between Alice and Bob.

Definition 2 (Correctness of BARK). We say that BARK is correct if for all sequence sched,
the CORRECT game of Fig. 2 never returns 1. Namely, for each P, receivedPkey is always prefix of

sentPkey
5 and each RATCH(., rec, .) call accepts.

Security. We model our security notion with an active adversary who can have access to some
of the states of Alice or Bob along with access to their secret keys enabling them to act both as
a sender and as a receiver. For simplicity, we have only Alice and Bob as participants. (Models
with more participants would be asymptotically equivalent.) We focus on three main security
notions which are key indistinguishability (denoted as KIND) under the compromise of states or
keys, unforgeability of upd information (FORGE) by the adversary which will be accepted, and
recovery from impersonation (RECOVER) which will make the two participants restore secure
communication without noticing a (trivial) impersonation resulting from a state exposure. A
challenge in these notions is to eliminate the trivial attacks. FORGE and RECOVER security will
be useful to prove KIND security.

2.2 KIND Security

The adversary can access four oracles called RATCH, EXPst, EXPkey, and TEST.

RATCH. This is essentially the message exchange procedure. It is defined in Fig. 2. The adversary
can call it with three inputs, a participant P, where P ∈ {A,B}; a role of P; and an upd

information if the role is rec. The adversary gets upd (for role = send) or acc (for role = rec)
in return.

EXPst. The adversary can expose the state of Alice or Bob. It inputs P ∈ {A,B} to the EXPst

oracle and it receives the full state stP of P.
EXPkey. The adversary can expose the generated key by calling this oracle. Upon inputting P, it

gets the last key kP generated by P. If no key was generated, ⊥ is returned.

5 By saying that receivedPkey is prefix of sentPkey, we mean that when n is the number of keys generated by

P running Receive, then these keys are the first n keys generated by P running Send.

6



Oracle RATCH(P, rec, upd)
1: (acc, st ′P, k)← Receive(stP, upd)
2: if acc then

3: updP ← upd

4: kP ← k

5: stP ← st ′P
6: append kP to receivedPkey
7: append updP to receivedPmsg

8: end if

9: return acc

Oracle RATCH(P, send)
10: (st ′P, updP,kP)← Send(stP)

11: stP ← st ′P
12: append kP to sentPkey
13: append updP to sentPmsg

14: return updP

Game CORRECT(1Îť, sched)
1: set all sent∗∗ and received∗∗ variables to ∅

2: Setup(1Îť)
$
−→ pp

3: Initall(1Îť, pp)
$
−→ (stA, stB, z)

4: initialize two FIFO lists incomingA and incomingB to empty
5: i← 1
6: while schedi exists do
7: (P, role)← schedi
8: if role = rec then

9: if incomingP is empty then return 0
10: pull upd from incomingP
11: acc← RATCH(P, rec, upd)
12: if acc = false then return 1
13: else

14: upd← RATCH(P, send)
15: push upd to incomingP
16: end if

17: if receivedAkey not prefix of sentBkey then return 1

18: if receivedBkey not prefix of sentAkey then return 1
19: i← i+ 1
20: end while

21: return 0

Fig. 2: The CORRECT game.

TEST. This oracle can be called only once to receive a challenge key which is generated either
uniformly at random (if the challenge bit is b = 0) or given as the last generated key of a
participant P specified as input (if the challenge bit is b = 1). The oracle cannot be queried if
no key was generated yet.

We specifically separate EXPkey from EXPst because the key k generated by BARK will be used
by an external process which may leak the key. Thus, EXPkey can be more frequent than EXPst,
however it harms security less.

To define security, we avoid trivial attacks. Capturing the trivial cases in a broad sense requires
a new set of definitions. All of them are intuitive.

Intuitively, P is in a matching status at a given time if his state is not dependent on an “active”
attack (i.e. could result from a CORRECT game).

Definition 3 (Matching status). We say that P is in a matching status at time t for P if

1. at any moment of the game before time t for P, receivedPmsg is a prefix of sentPmsg — this defines

the time t for P when P sent the last message in receivedPmsg(t);

2. at any moment of the game before time t for P, receivedPmsg is a prefix of sentPmsg.

We further say that time t for P originates from time t for P.

The first condition clearly states that each of the received (and accepted) upd message was sent
before by the counterpart of P, in the same order, without any loss in between. The second
condition similarly verifies that those messages from P only depend on information coming from
P. In Fig. 1, Bob is in a matching status with Alice because he receives the upd information in the
exact order as they have sent by Alice (i.e. Bob generates k2 after k1 and k4 after k2 same as it
has sent by Alice). In general, as long as no adversary switches the order of messages or creates
fake messages successfully for either party, the participants are always in a matching status.

7



The key exchange literature often defines a notion of partnering which is simpler. Asynchronous
random roles makes it more complicated.

Here is an easy property of the notion of matching status.

Lemma 4. If P is in a matching status at time t, then P is also in a matching status at any time
t0 6 t. Similarly, if P is in a matching status at time t and t for P originates from t for P, then
P is in a matching status at time t.

Proof. In Def. 3, it is clear that if the first property holds with time t for P, then it holds for any
time t0 < t for P. Similarly, if the second property holds with time t for P, then it holds for any
time t0 < t for P.

Hence, if P is in a matching status at time t, then he is in a matching status at any time t0 < t.
Furthermore, if P is in a matching status at time t and time t for P originates from time t for
t, we can exchange the roles of P and P, obtain the first property with time t instead of t, and
deduce the second property for some time which is even before. Hence, P is in a matching status
at time t. ⊓⊔

Definition 5 (Forgery). Given a participant P in a game, we say that upd ∈ receivedPmsg is a
forgery if at the moment of the game just before P received upd, P was in a matching status, but
no longer after receiving upd.

In a matching status, any upd received by P must correspond to an upd sent by P and the
sequences must match. This implies the following notion.

Definition 6 (Corresponding RATCH calls). Let P be a participant. We consider only the
RATCH(P, rec, .) calls by P returning true. We say that the ith receiving call corresponds to the
jth sending RATCH(P, send) call by P if i = j and P is in matching status at the time of this ith

accepting RATCH(P, rec, .) call.

Lemma 7. In a correct BARK protocol, two corresponding RATCH(P, rec, upd) and RATCH(P, send)
calls generate the same key kP = kP.

Proof. We let t be the time of the RATCH(P, rec, upd) call and t be the time of the RATCH(P, send).
If RATCH(P, rec, upd) and RATCH(P, send) correspond to each other, then P is in matching status
and t originates from t. We follow the sequence of RATCH calls made by the game until time t for
P and time t for P (i.e., we ignore what happens to P after time t and to P after time t). Due to
the properties of the matching status, we can model them as a sequence sched as in the CORRECT
game, where the upd messages are buffered. Using the same random coins, this game produces
the same keys. Due to correctness, we have receivedPkey = sentPkey. The ith element of receivedPkey is

kP(t). The jth element of sentPkey is kP(t). Since i = j, we have kP(t) = kP(t). ⊓⊔

Definition 8 (Ratcheting period of P). A maximal time interval during which there is no
RATCH(P, send) call is called a ratcheting period of P.

Consequently, a RATCH(P, send) call ends a ratcheting period for P and starts a new one. In Fig. 1,
the time between T1 and T3 or the interval T5 − T6 are called ratcheting period of Alice and Bob
respectively.

We now define when the adversary can trivially obtain a key generated by P due to an exposure.
We distinguish the case when the exposure was done on P (direct leakage) and on P (indirect
leakage).

Definition 9 (Direct leakage). Let t be a time and P be a participant. We say that kP(t) has
a direct leakage if one of the following conditions is satisfied:

– There is an EXPkey(P) at a time te such that the last RATCH call which is executed by P before
time t and the last RATCH call which is executed by P before time te are the same.

8



– P is in a matching status and there exists t0 6 te 6 tRATCH 6 t and t such that time t

originates from time t; time t originates from time t0; there is one EXPst(P) at time te; there
is one RATCH(P, rec, .) at time tRATCH; and there is no RATCH(P, ., .) between time tRATCH and
time t.

In the first case, it is clear that EXPkey(P) gives kP(te) = kP(t). In the second case (in Fig. 3)6,
the state which leaks from EXPst(P) at time te allows to simulate all deterministic Receive (by
skipping all Send) and to compute the key kP(tRATCH) = kP(t). The reason why we can allow the
adversary to skip all Send is that they make messages which are supposed to be delivered to P

after time t, so they have no impact on kP(t).
Consider Fig. 1. Suppose t is in between time T3 and T4. According to our definition P = A

and the last RATCH call is at time T3. It is a Send, thus the second case cannot apply. The next
RATCH call is at time T4. In this case, kA(t) has a direct leakage if there is a key exposure of Alice
between T3 and T4.

Suppose now that T8 < t < T9. We have P = B, the last RATCH call is a Receive, it is at
time tRATCH = T8, and t originates from time t = T0 which itself originates from the origin time
t0 = TInit for B. We say that t has a direct leakage if there is a key exposure between T8 − T9 or
a state exposure of Bob before time T8. Indeed, with this last state exposure, the adversary can
ignore all Send and simulate all Receive to derive k0.

P P

t0

(EXPst) te

tRATCH

t

tReceive

no RATCH

P P

t ′

tRATCH

t

t

te (EXPst)
Send

no RATCH

Fig. 3: Direct (left) and indirect (right) leakage

Definition 10 (Indirect leakage). We consider a time t and a participant P. Let tRATCH be the
time of the last successful RATCH call and role be its input role. (We have kP(tRATCH) = kP(t).)
We say that kP(t) has an indirect leakage if P is in matching status at time t and one of the
following conditions is satisfied

– There exists a RATCH(P, role, .) corresponding to that RATCH(P, role, .) and making a kP which
has a direct leakage for P.

– There exists t ′ 6 tRATCH 6 t and t 6 te such that P is in a matching status at time te, t
originates from t, te originates from t ′, there is one EXPst(P) at time te, and role = send.

In the first case, kP(t) = kP(tRATCH) is also computed by P and leaks from there. The second
case (in Fig. 3) is more complicated: it corresponds to an adversary who can get the internal state
of P by EXPst(P) then simulate all Receive with messages from P until the one sent at time tRATCH,
ignoring all Send by P, to recover kP(t).

6 Origin of dotted arrows indicate when a time originates from.

9



For example, let t be a time between T1 and T2 in Fig. 1. We take P = A. The last RATCH call
is at time tRATCH = T1, it is a Send and corresponds to a Receive at time T10, but t originates from
time t = TInit. We say that t has an indirect leakage for A if there exists a direct leakage for P = B

at a time between T10 and T11 (first condition) or there exists a EXPst(B) call at a time te (after
time t = TInit), originating from a time t ′ before time T1, so te < T10 (second condition). In the
latter case, the adversary can simulate Receive with the updates sent at time T0 and T1 to derive
the key k1.

Exposing the state of a participant gives certain advantages to the attacker and make trivial
attacks possible. In our security game, we avoid those attack scenarios. In the following lemma,
we show that direct and indirect leakage capture the times when the adversary can trivially win.
The proof is straightforward.

Lemma 11 (Trivial attacks). Assume that BARK is correct. For any t and P, if kP(t) has a
direct or indirect leakage, the adversary can compute kP(t).

Proof. We use correctness, Lemm";"""date"",""2019-09-09T09:36:34Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""1"",""6"",""0"",""9"",""1"",""6"",""2"",""12"",""21"",""5"",""40"",""7"",""4"",""0"",""3"",""11"",""3"",""4"",""1"",""2"",""1"",""0"",""5"",""9"",""0""
""pdf:PDFVersion"",""1.7""
""xmp:CreatorTool"",""dvips(k) 5.997 Copyright 2017 Radical Eye Software""
""pdf:docinfo:title"",""sec_comm.dvi""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dcterms:created"",""2019-09-09T09:36:34Z""
""language"",""en""
""Last-Modified"",""2019-09-09T09:36:34Z""
""dcterms:modified"",""2019-09-09T09:36:34Z""
""dc:format"",""application/pdf; version=1.7""
""title"",""sec_comm.dvi""
""xmpMM:DocumentID"",""uuid:dc953fd9-0b01-11f5-0000-4da6ff9df796""
""Last-Save-Date"",""2019-09-09T09:36:34Z""
""pdf:docinfo:creator_tool"",""dvips(k) 5.997 Copyright 2017 Radical Eye Software""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2019-09-09T09:36:34Z""
""meta:save-date"",""2019-09-09T09:36:34Z""
""pdf:encrypted"",""false""
""dc:title"",""sec_comm.dvi""
""xmp:CreateDate"",""2019-09-09T11:36:34Z""
""modified"",""2019-09-09T09:36:34Z""
""Content-Length"",""446202""
""pdf:hasMarkedContent"",""false""
""Content-Type"",""application/pdf""
""xmp:ModifyDate"",""2019-09-09T11:36:34Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""pdf:producer"",""GPL Ghostscript 9.26""
""meta:creation-date"",""2019-09-09T09:36:34Z""
""created"",""2019-09-09T09:36:34Z""
""xmp:About"",""uuid:dc953fd9-0b01-11f5-0000-4da6ff9df796""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""32""
""Creation-Date"",""2019-09-09T09:36:34Z""
""resourceName"",""sec_comm.pdf""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""3059"",""3793"",""3323"",""3285"",""3213"",""1906"",""2333"",""2812"",""2096"",""3337"",""2482"",""2559"",""2696"",""2583"",""3046"",""2887"",""2934"",""3016"",""2740"",""2378"",""2524"",""3376"",""1236"",""2118"",""2965"",""3280"",""2086"",""2066"",""2355"",""3342"",""3288"",""476""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""producer"",""GPL Ghostscript 9.26""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""GPL Ghostscript 9.26""
""pdf:docinfo:created"",""2019-09-09T09:36:34Z""
";https://scholar.google.com/scholar?start=550&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094656-1144;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Environmental Risks in Supply Chain: Recommendations and Directions for Future Research;A Mukhtar, A Romli, M Abdullateef… ; IOP Conference Series …, 2019  iopscience.iop.org;;"… In addition it helps to ensure that products are sold in an environmental friendly manner.

Nowadays, leading-edge firms such as Oracle, SAP, Walmart and IBM are already developing

Blockchain based cloud management solutions for the supply chain …";Autres articles;;[PDF] iop.org;https://iopscience.iop.org/article/10.1088/1757-899X/551/1/012034/pdf;"

    
        
            [image: Captcha Page]
        

        
            We apologize for the inconvenience...

            ...but your activity and behavior on this site made us think that you are a bot.

            Note: A number of things could be going on here.

            	If you are attempting to access this site using an anonymous Private/Proxy network, please disable that and try accessing site again.
	Due to previously detected malicious behavior which originated from the network you're using, please request unblock to site.


        

    

    
        

        
            
                 Please solve this CAPTCHA to request unblock to the website 

            
        

        

        
            
                
                

                

                


            

        

    




    
	
		You reached this page when trying to access
		https://iopscience.iop.org/article/10.1088/1757-899X/551/1/012034/pdf from
		83.76.85.89 on
		April 28 2021, 12:17:16 UTC
	





";"""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""viewport"",""width=device-width, initial-scale=1""
""dc:title"",""ShieldSquare Captcha""
""Content-Encoding"",""UTF-8""
""resourceName"",""pdf""
""language"",""en""
""Content-Length"",""2753""
""title"",""ShieldSquare Captcha""
""Content-Language"",""en""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=960&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094546-679;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[CITATION][C] Beyond the hype: A study of the applicability of blockchain-based smart contracts in the industry-Towards a proof of concept;C Gonzalez ;2019 matheo.uliege.be;;"… Oracle, Alibaba, Facebook, IBM, Amazon, Ford, Siemens, Toyota, Nestlé, Walmart, Carrefour,

ABInBev, all these giants have already invested millions of dollars … And yet… More than one year

after the celebration of its tenth birthday, blockchain technology has still not given birth …";;;null;;;;https://scholar.google.com/scholar?start=490&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094668-1192;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Opportunities and Challenges of DLT (Blockchain) in Mobility and Logistics;G Fridgen, N Guggenberger, T Hoeren, W Prinz… ;2019 orbilu.uni.lu;;"… application for DLT debuted in 2009 in the form of a blockchain for the Bitcoin cryptocurrency …

In the EU, 21 member states have joined in the European Blockchain Partnership to promote

the … into the DLT system, or pro- vide smart contracts for this process (so-called ""oracles"") …";Autres articles;;[PDF] uni.lu;https://orbilu.uni.lu/bitstream/10993/44503/1/Opportunities%20and%20Challenges.pdf;"
Opportunities and Challenges of 
DLT (Blockchain) in Mobility and 
Logistics





Translation 

  
 
  
 
 
 
 
 
 
 

 
  
 
 
 
 
Prof. Dr. Gilbert Fridgen 
Prof. Dr. Nikolas Guggenberger 
Prof. Dr. Thomas Hoeren 
Prof. Wolfgang Prinz (PhD) 
Prof. Dr. Nils Urbach 
 
 
Johannes Baur, Henning Brockmeyer, Wolfgang Gräther, Elisaweta Rabovskaja,  
Vincent Schlatt, AndrĂŠ Schweizer, Johannes Sedlmeir, Lars Wederhake 
 
Also with the participation of:  
Matthias Babel, Martin Brennecke, Patrick Camus, Benedict Drasch, Tobias Guggenberger, Luis Lämmermann, Jannik 
Lockl, Sven Radszuwill, Alexander Rieger, Nicolas Ruhland, Marco Schmidt, Nico Thanner, Patrick Troglauer, Malte 
Weißert, Felix Würmseher 
 
 
 

OPPORTUNITIES AND CHALLENGES OF  
DLT (BLOCKCHAIN) IN MOBILITY AND 
LOGISTICS 

FRAUNHOFER INSTITUTE FOR APPLIED INFORMATION TECHNOLOGY FIT  
 

 
 





 
 

Contents 
1  Management Summary ............................................................................................................ 6 

1.1 Purpose of This Report ..................................................................................................................... 6 
1.2 General Analysis ............................................................................................................................... 7 

 Technical aspects ................................................................................................................................................ 7 1.2.1
 Socioeconomic aspects ...................................................................................................................................... 8 1.2.2

1.2.2.1 Current situation ............................................................................................................................................. 8 
1.2.2.2 Generic roles and application patterns .......................................................................................................... 9 
1.2.2.3 Policy on promoting the spread of DLT ....................................................................................................... 10 
1.2.2.4 DLT in the mobility sector ............................................................................................................................ 11 

 Legal considerations ......................................................................................................................................... 11 1.2.3
1.2.3.1 Civil law ......................................................................................................................................................... 11 
1.2.3.2 Data protection law ...................................................................................................................................... 11 

1.3 Case Studies .................................................................................................................................... 12 
 Shipping documents ............................................................................................................................................. 12 1.3.1
 Charging of electric vehicles ............................................................................................................................. 13 1.3.2
 Ridesharing ........................................................................................................................................................... 14 1.3.3
 Platooning ........................................................................................................................................................ 15 1.3.4

1.4 Conclusions ..................................................................................................................................... 16 

2  Introduction ........................................................................................................................... 18 

2.1 Basic Concepts ................................................................................................................................ 18 
2.2 Organization of the Study .............................................................................................................. 19 

3  Technical Basics ..................................................................................................................... 21 

3.1 Basic Concepts ................................................................................................................................ 22 
 Blockchain networks ............................................................................................................................................ 22 3.1.1
 Transaction, distributed ledger, digital signature ............................................................................................ 23 3.1.2
 How transactions flow through the blockchain ................................................................................................... 23 3.1.3
 Hash values ....................................................................................................................................................... 23 3.1.4
 Blocks ................................................................................................................................................................ 24 3.1.5
 Consensus mechanisms .................................................................................................................................... 24 3.1.6
 Attributes of a blockchain .................................................................................................................................... 25 3.1.7

3.2 Other Concepts ............................................................................................................................... 25 
 Smart contracts ................................................................................................................................................ 26 3.2.1
 Other consensus mechanisms .......................................................................................................................... 27 3.2.2
 Sharding ............................................................................................................................................................ 28 3.2.3
 Integration of external data .............................................................................................................................. 28 3.2.4
 Oracles ..............................................................................................................................................................  28 3.2.5

3.3 Blockchain and DLT Infrastructures ................................................................................................ 29 
 Classification schemes .......................................................................................................................................... 29 3.3.1
 Bitcoin ............................................................................................................................................................... 30 3.3.2
 Ethereum ..............................................................................................................................................................  31 3.3.3
 Quorum ............................................................................................................................................................. 31 3.3.4
 Hyperledger Fabric ........................................................................................................................................... 31 3.3.5
 Corda .................................................................................................................................................................  32 3.3.6
 Sovrin .................................................................................................................................................................... 32 3.3.7
 IOTA .................................................................................................................................................................. 33 3.3.8
 Hedera Hashgraph ............................................................................................................................................ 34 3.3.9

1 
 



 

 Overview of DLT infrastructures ...................................................................................................................... 35 3.3.10

3.4 Governance of DLT Networks ........................................................................................................ 35 
 Blockchain networks ........................................................................................................................................ 35 3.4.1
 Technological governance ............................................................................................................................... 36 3.4.2
 Forks .................................................................................................................................................................  36 3.4.3

3.5 Interoperability and Standardization ............................................................................................. 37 
 Blockchain-to-Blockchain Communication ..................................................................................................... 37 3.5.1
 ISO standards ................................................................................................................................................... 39 3.5.2
 Sidechains ........................................................................................................................................................ 39 3.5.3

3.6 Trends ............................................................................................................................................. 39 
 Certification ...................................................................................................................................................... 39 3.6.1
 Quantum computing and blockchains ............................................................................................................. 40 3.6.2
 Identification of DLT-appropriate business processes .................................................................................... 41 3.6.3

4  Socioeconomic Foundations .................................................................................................... 42 

4.1 Characterization of DLT Within the Scope of Digitalization .......................................................... 42 
 DLT and the Internet of Things ........................................................................................................................ 43 4.1.1

4.1.1.1 The Internet of Things is changing business and society ............................................................................ 43 
4.1.1.2 The Internet of Things requires an integrated technology architecture ..................................................... 44 
4.1.1.3 The Internet of Things is the basis for using DLT in the physical world ...................................................... 44 

 DLT and Artificial Intelligence.......................................................................................................................... 45 4.1.2
4.1.2.1 The future-oriented technologies of DLT and AI are converging ............................................................... 45 
4.1.2.2 DLT as the database for AI ........................................................................................................................... 46 
4.1.2.3 DLT as a recording platform for AI .............................................................................................................. 46 

 DLT and privacy-preserving computational methods ..................................................................................... 47 4.1.3

4.2 The Potential of DLT ...................................................................................................................... 49 
 Status quo ........................................................................................................................................................ 49 4.2.1

4.2.1.1 Startups ........................................................................................................................................................ 53 
4.2.1.2 Consortia ...................................................................................................................................................... 53 
4.2.1.3 Established companies ................................................................................................................................ 54 
4.2.1.4 Public initiatives ........................................................................................................................................... 55 
4.2.1.5 Summary ...................................................................................................................................................... 55 

 The blockchain value proposition: trust .......................................................................................................... 56 4.2.2
 Generic roles of DLT ......................................................................................................................................... 60 4.2.3

4.2.3.1 Improvers ..................................................................................................................................................... 61 
4.2.3.2 Transformers ................................................................................................................................................ 61 
4.2.3.3 Enablers ........................................................................................................................................................ 61 

 Developmental stages of the Internet ............................................................................................................. 62 4.2.4
 Application categories ..................................................................................................................................... 63 4.2.5

4.2.5.1 Neutral platforms ......................................................................................................................................... 63 
4.2.5.2 Forgery-proof documentation ..................................................................................................................... 64 
4.2.5.3 Payments ..................................................................................................................................................... 64 
4.2.5.4 Management of cross-organizational processes ......................................................................................... 64 
4.2.5.5 Digital identities ........................................................................................................................................... 65 
4.2.5.6 Digital documents ........................................................................................................................................ 66 
4.2.5.7 Providerless services .................................................................................................................................... 69 
4.2.5.8 Economically autonomous machines .......................................................................................................... 70 

 Decision-making criteria for the use of blockchain ......................................................................................... 70 4.2.6
 Blockchain as a digital infrastructure ............................................................................................................... 71 4.2.7
 Informational self-determination and digital sovereignty .............................................................................. 73 4.2.8

4.3 Aspects of Implementation ............................................................................................................ 76 
 Diffusion of DLT-based innovations ................................................................................................................ 76 4.3.1

2 
 



 
 

4.3.1.1 The economic perspective ............................................................................................................................ 76 
4.3.1.2 The Business perspective ............................................................................................................................. 80 

 Obstacles .......................................................................................................................................................... 84 4.3.2
4.3.2.1 Energy consumption and transaction speed ................................................................................................ 84 
4.3.2.2 Security, misuse and crime ........................................................................................................................... 86 
4.3.2.3 Data protection and the GDPR ..................................................................................................................... 89 

 DLT and governance......................................................................................................................................... 91 4.3.3
4.3.3.1 Governance mechanisms for operating DLT systems ................................................................................. 91 
4.3.3.2 DLT as a governance mechanism ................................................................................................................. 93 

 Implications for competition policy .................................................................................................................. 95 4.3.4

4.4 DLT in the Mobility Sector .............................................................................................................. 97 
 Fields of application .......................................................................................................................................... 98 4.4.1
 Preview of the special part of the study ......................................................................................................... 101 4.4.2

5  Legal Foundations ................................................................................................................ 103 

5.1 Civil Law Considerations ............................................................................................................... 103 
 Smart contracts and automated contract execution ..................................................................................... 103 5.1.1
 Limitations on use .......................................................................................................................................... 103 5.1.2
 Conclusion of contracts .................................................................................................................................. 104 5.1.3

5.1.3.1 Smart contracts as objects of agreements................................................................................................. 104 
5.1.3.2 Conclusion of a contract using a smart contract ........................................................................................ 105 

 Contractual content and mandatory law ....................................................................................................... 106 5.1.4
5.1.4.1 Content review, Sections 307-309 of the German Civil Code .................................................................... 107 
5.1.4.2 Consumer contracts and special types of distribution ............................................................................... 109 

 Treatment of performance problems and reversal issues ............................................................................. 111 5.1.5
5.1.5.1 Performance problems ............................................................................................................................... 111 
5.1.5.2 Reversal of transactions ............................................................................................................................. 111 
5.1.5.3 Access to arbitration bodies/creation of judicial interfaces ....................................................................... 113 

 Digressions ..................................................................................................................................................... 114 5.1.6
5.1.6.1 Supervisory issues ...................................................................................................................................... 114 
5.1.6.2 Liability for smart contracts ....................................................................................................................... 115 

 Summary ............................................................................................................................................................ 116 5.1.7

5.2 Assessment from the Standpoint of Data Protection Law ........................................................... 116 
 Applicability of the GDPR ............................................................................................................................... 116 5.2.1
 Processing of personal data ........................................................................................................................... 117 5.2.2

5.2.2.1 Relevant data processing activities ............................................................................................................ 117 
5.2.2.2 Personal data .............................................................................................................................................. 118 
5.2.2.3 Intermediate findings ................................................................................................................................. 124 

 Responsibility for data processing ................................................................................................................. 124 5.2.3
5.2.3.1 Definition of responsibility ......................................................................................................................... 124 
5.2.3.2 Responsibility for entering data ................................................................................................................. 125 
5.2.3.3 Responsibility for reading data .................................................................................................................. 125 
5.2.3.4 Responsibility for storing data in the DLT layer ......................................................................................... 125 
5.2.3.5 Intermediate findings ................................................................................................................................. 132 

 Legal basis for data processing ...................................................................................................................... 132 5.2.4
5.2.4.1 Justifications for storing and reading data ................................................................................................. 132 
5.2.4.2 Justification of on-chain processing ........................................................................................................... 134 

 Implementation of the right to rectification and erasure .............................................................................. 135 5.2.5
5.2.5.1 Erasure in an “anonymization solution” ..................................................................................................... 135 
5.2.5.2 Erasure in “open solutions” and “centralized solutions” ............................................................................ 136 

 Summary ........................................................................................................................................................ 138 5.2.6
5.2.6.1 Exclusively B2B DLT applications ............................................................................................................... 138 
5.2.6.2 Other cases ................................................................................................................................................. 138 

3 
 



 

 Outlook for future legal reforms .................................................................................................................... 139 5.2.7

5.3 Existing Regulatory Approaches .................................................................................................. 141 
 International ................................................................................................................................................... 141 5.3.1

5.3.1.1 USA ............................................................................................................................................................. 141 
5.3.1.2 Switzerland ................................................................................................................................................ 141 
5.3.1.3 Malta, Liechtenstein .................................................................................................................................. 142 
5.3.1.4 Japan .......................................................................................................................................................... 142 

 Germany and Europe ..................................................................................................................................... 142 5.3.2

6  Shipping Documents ............................................................................................................. 144 

6.1 Economic and Technical Aspects .................................................................................................. 144 
 Definition and description of an example application ................................................................................... 144 6.1.1
 Status quo and challenges ............................................................................................................................. 147 6.1.2
 Possible solutions and the role of DLT........................................................................................................... 150 6.1.3
 Process description ........................................................................................................................................ 151 6.1.4
 Conclusions and recommendations for action .............................................................................................. 155 6.1.5

6.2 Legal Discussion ........................................................................................................................... 156 
 Trading documents ........................................................................................................................................ 156 6.2.1

6.2.1.1 International applications of German maritime trading law ..................................................................... 157 
6.2.1.2 Credit transactions in foreign trade ........................................................................................................... 157 
6.2.1.3 DLT-based trading documents .................................................................................................................. 158 
6.2.1.4 Use of DLT for data protection in the context of digital trading documents ............................................ 162 

 Conclusions and recommendations for action .............................................................................................. 164 6.2.2

7  Electric Vehicle Charging ...................................................................................................... 166 

7.1 Economic and Technical Aspects: Technical Part ......................................................................... 166 
 Definition and description of the application .................................................................................................... 166 7.1.1
 Status quo and challenges ............................................................................................................................. 176 7.1.2
 Possible solutions and roles of DLT ................................................................................................................... 177 7.1.3
 Process description ........................................................................................................................................ 179 7.1.4
 Conclusions and recommendations for action .................................................................................................. 181 7.1.5

7.2 Legal Discussion ........................................................................................................................... 181 
 Contractual relationships ............................................................................................................................... 182 7.2.1
 Blockchain-based data protection for electric vehicle charging infrastructure ............................................ 183 7.2.2

7.2.2.1 Data protection in connection with eRoaming when no information can be obtained about natural 
persons behind the eMSP and CPO ........................................................................................................................... 183 
7.2.2.2 Data protection with direct payment and eRoaming if information can be obtained on natural persons 
behind the eMSP and CPO ........................................................................................................................................ 183 

 Conclusions and recommendations for action .............................................................................................. 185 7.2.3

8  Ridesharing ........................................................................................................................... 186 

8.1 Economic and Technical Aspects: Technical Part ......................................................................... 186 
 Definition and description of the application ................................................................................................ 186 8.1.1
 Status quo and challenges ............................................................................................................................. 187 8.1.2
 Possible solutions involving DLT ................................................................................................................... 189 8.1.3
 Process description ........................................................................................................................................ 192 8.1.4
 Conclusions and recommendations for action .............................................................................................. 194 8.1.5

8.2 Legal Discussion ........................................................................................................................... 195 
 Passenger transportation law ........................................................................................................................ 195 8.2.1
 Data protection .............................................................................................................................................. 196 8.2.2
 Conclusions and recommendations for action .............................................................................................. 197 8.2.3

4 
 



 
 

9  Platooning ............................................................................................................................ 198 

9.1 Economic and Technical Aspects .................................................................................................. 198 
 Definition and description of the application ................................................................................................... 198 9.1.1
 Status quo and challenges .........................................................................................................";"""date"",""2020-04-08T10:03:26Z""
""pdf:PDFVersion"",""1.6""
""xmp:CreatorTool"",""Adobe InDesign CS5 (7.0.4)""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""xmpMM:History:Action"",""created"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved""
""language"",""en""
""dc:format"",""application/pdf; version=1.6""
""pdf:docinfo:creator_tool"",""Adobe InDesign CS5 (7.0.4)""
""access_permission:fill_in_form"",""true""
""xmpMM:History:When"",""2019-05-14T11:25:01Z"",""2019-05-14T11:25:40Z"",""2019-05-14T11:25:40Z"",""2019-05-14T11:26:36Z"",""2019-05-14T11:28:01Z"",""2019-05-14T11:28:58Z"",""2019-05-14T11:29:45Z"",""2019-05-14T11:30:59Z"",""2020-03-06T14:57:34Z"",""2020-03-06T14:57:34Z"",""2020-03-06T15:15:34Z"",""2020-03-06T15:21:11Z"",""2020-03-06T15:26:41Z"",""2020-04-08T12:02:28Z""
""pdf:encrypted"",""false""
""xmp:CreateDate"",""2020-04-08T12:02:43Z""
""modified"",""2020-04-08T10:03:26Z""
""xmpMM:History:SoftwareAgent"",""Adobe InDesign 7.0"",""Adobe InDesign 7.0"",""Adobe InDesign 7.0"",""Adobe InDesign 7.0"",""Adobe InDesign 7.0"",""Adobe InDesign 7.0"",""Adobe InDesign 7.0"",""Adobe InDesign 7.0"",""Adobe InDesign 7.0"",""Adobe InDesign 7.0"",""Adobe InDesign 7.0"",""Adobe InDesign 7.0"",""Adobe InDesign 7.0"",""Adobe InDesign 7.0""
""pdf:hasMarkedContent"",""true""
""xmpMM:History:InstanceID"",""xmp.iid:FFE1AF672676E9118E77BFBE344FB3F9"",""xmp.iid:00E2AF672676E9118E77BFBE344FB3F9"",""xmp.iid:01E2AF672676E9118E77BFBE344FB3F9"",""xmp.iid:21A0FD5C2A76E91187E3EB093D99E7D4"",""xmp.iid:22A0FD5C2A76E91187E3EB093D99E7D4"",""xmp.iid:25A0FD5C2A76E91187E3EB093D99E7D4"",""xmp.iid:AB45D2CF2A76E91187E3EB093D99E7D4"",""xmp.iid:AE45D2CF2A76E91187E3EB093D99E7D4"",""xmp.iid:B9CB4B9AB05FEA119FD7C3FE0073FCC0"",""xmp.iid:BCCB4B9AB05FEA119FD7C3FE0073FCC0"",""xmp.iid:BFCB4B9AB05FEA119FD7C3FE0073FCC0"",""xmp.iid:2EF67BBAB55FEA119FD7C3FE0073FCC0"",""xmp.iid:31F67BBAB55FEA119FD7C3FE0073FCC0"",""xmp.iid:12FE92717F79EA119F4EE8DC2119EAEB""
""xmp:ModifyDate"",""2020-04-08T12:03:26Z""
""trapped"",""False""
""meta:creation-date"",""2020-04-08T10:02:43Z""
""created"",""2020-04-08T10:02:43Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-04-08T10:02:43Z""
""resourceName"",""Opportunities%20and%20Challenges.pdf""
""xmpMM:DerivedFrom:DocumentID"",""xmp.did:FFE1AF672676E9118E77BFBE344FB3F9""
""producer"",""Adobe PDF Library 9.9""
""pdf:docinfo:producer"",""Adobe PDF Library 9.9""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""access_permission:modify_annotations"",""true""
""dcterms:created"",""2020-04-08T10:02:43Z""
""Last-Modified"",""2020-04-08T10:03:26Z""
""dcterms:modified"",""2020-04-08T10:03:26Z""
""xmpMM:DocumentID"",""xmp.did:BCCB4B9AB05FEA119FD7C3FE0073FCC0""
""Last-Save-Date"",""2020-04-08T10:03:26Z""
""pdf:docinfo:modified"",""2020-04-08T10:03:26Z""
""meta:save-date"",""2020-04-08T10:03:26Z""
""Content-Length"",""5618881""
""Content-Type"",""application/pdf""
""xmp:MetadataDate"",""2020-04-08T12:03:26Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""pdf:producer"",""Adobe PDF Library 9.9""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""244""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""74"",""0"",""732"",""0"",""7512"",""8042"",""8152"",""7294"",""2958"",""3592"",""3771"",""3455"",""3687"",""3815"",""3237"",""3459"",""3767"",""4066"",""3669"",""3519"",""2176"",""3472"",""3867"",""3835"",""2295"",""1989"",""2644"",""2387"",""3087"",""3469"",""2258"",""3280"",""2579"",""2652"",""3275"",""3584"",""2398"",""1551"",""2536"",""2827"",""2564"",""2825"",""2701"",""3594"",""900"",""2200"",""3809"",""3163"",""3575"",""3704"",""3787"",""3697"",""2685"",""2579"",""2547"",""2562"",""3390"",""2132"",""3393"",""3366"",""3426"",""3594"",""2246"",""2173"",""2908"",""2116"",""3435"",""3540"",""3647"",""3584"",""3560"",""2688"",""2571"",""3495"",""3649"",""3468"",""2877"",""3534"",""3721"",""3354"",""2110"",""3595"",""3853"",""2637"",""2980"",""1455"",""3258"",""2414"",""3453"",""2518"",""3282"",""3250"",""3018"",""3497"",""3182"",""2821"",""3212"",""2519"",""3692"",""2282"",""237"",""2181"",""3873"",""3787"",""2696"",""2978"",""2896"",""3365"",""3549"",""3992"",""3612"",""3468"",""3548"",""3684"",""3397"",""3623"",""3996"",""4089"",""3576"",""3313"",""3185"",""2854"",""3277"",""3273"",""3233"",""3345"",""3473"",""3164"",""2889"",""3400"",""3566"",""3665"",""3347"",""3403"",""3226"",""3205"",""3375"",""3343"",""3311"",""3689"",""3409"",""3364"",""3444"",""3710"",""3563"",""3464"",""1884"",""2912"",""1555"",""2249"",""3565"",""3621"",""3531"",""3625"",""3354"",""1735"",""2766"",""2588"",""3505"",""3241"",""3536"",""3419"",""3258"",""2987"",""3153"",""3063"",""3423"",""3146"",""1387"",""2812"",""2440"",""3152"",""2418"",""2728"",""3615"",""2741"",""2284"",""1295"",""3370"",""2537"",""3031"",""2911"",""1726"",""2320"",""2457"",""3695"",""3170"",""3177"",""1395"",""3373"",""3375"",""3086"",""2223"",""3376"",""3432"",""3115"",""2846"",""3461"",""2495"",""3318"",""797"",""2839"",""2439"",""3600"",""3481"",""3536"",""3519"",""2571"",""3050"",""3163"",""2532"",""3204"",""3233"",""2897"",""3276"",""3525"",""2894"",""3126"",""3421"",""1687"",""3789"",""3926"",""1453"",""2018"",""2469"",""2357"",""2450"",""2484"",""2362"",""2442"",""2405"",""2199"",""2334"",""2334"",""2405"",""2367"",""2458"",""2550"",""2401"",""2312"",""2036"",""7"",""429"",""11""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""xmpMM:DerivedFrom:InstanceID"",""xmp.iid:B9CB4B9AB05FEA119FD7C3FE0073FCC0""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-04-08T10:02:43Z""
";https://scholar.google.com/scholar?start=410&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094548-690;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[HTML][HTML] Les plateformes: assureurs du XXIe sičcle?;A Trescases ; Revue internationale de droit économique, 2019  cairn.info;;"… Dans ce cadre, une technologie retient particuličrement l'attention, la méta-technologie blockchain

(ou chaîne de blocs) [34 … conférer une indispensable confiance aux utilisateurs de ce systčme

dont l'une des principales critiques est qu'il est déshumanisé, l'Oracle pourrait ainsi …";Autres articles;;[HTML] cairn.info;https://www.cairn.info/revue-internationale-de-droit-economique-2019-3-page-291.htm;;;https://scholar.google.com/scholar?start=500&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094574-791;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[PDF][PDF] Projektbericht für die QS Qualität und Sicherheit GmbH, Bonn;K Schnitker, S Kemper ;2019 qs.de;;"… Ermittlung der Potenziale von ausgewählten Distributed Ledger Technologien (Blockchain) in

der Agri-Food-Chain am Beispiel des QS-Systems … 1.1 Blockchain – Ein erster Überblick ..... 6 …";Autres articles;;[PDF] q-s.de;https://www.q-s.de/services/files/qs-wissenschaftsfonds/Forschungsbericht-Ermittlung-Potenziale-ausgew%C3%A4hlte-Distri.pdf;"
 

 

 

__________________________________________________________ 

 

Projektbericht fßr die QS Qualität und Sicherheit GmbH, Bonn  

 

Ermittlung der Potenziale von ausgewählten Distributed Ledger 

Technologien (Blockchain) in der Agri-Food-Chain  

am Beispiel des QS-Systems 

 

__________________________________________________________ 

Prof. Dr. Karin Schnitker | Simone Kemper M.Sc. 

Fakultät Agrarwissenschaften & Landschaftsarchitektur 

Fachbereich UnternehmensfĂźhrung 

Oldenburger Landstraße 62 | 49090 Osnabrück 

__________________________________________________________ 

 

31. Oktober 2019 

 

 

 

  



2 
 

Inhaltsverzeichnis 

Abbildungsverzeichnis ....................................................................................................... 4 

Tabellenverzeichnis ............................................................................................................ 5 

1 Blockchain-Technologie .............................................................................................. 6 

1.1 Blockchain – Ein erster Überblick ................................................................................. 6 

1.1.1 Definition und Charakteristika der Blockchain-Technologie .............................. 6 

1.1.2 Abgrenzung verschiedener Blockchain-Arten ................................................... 9 

1.1.3 UrsprĂźnge der Blockchain-Technologie ...........................................................11 

1.2 Funktionsweisen von BCT ...........................................................................................12 

1.2.1 Kryptographische Hash-Funktionen ................................................................12 

1.2.2 Digitale Signatur ..............................................................................................13 

1.2.3 Blockchain-Datenstruktur ................................................................................15 

1.2.4 Blockaufbau ....................................................................................................16 

1.2.5 Netztopologie ..................................................................................................17 

1.2.6 Distribuierte Konsensverfahren .......................................................................18 

1.2.7 Smart Contracts und Oracles ..........................................................................24 

1.2.8 Decentralized Applications (DApps) ................................................................28 

1.3 Technische Bewertung ................................................................................................29 

1.3.1 Technische Grenzen und Herausforderungen von Blockchain ........................29 

1.3.2 Heutige Grenzen und Herausforderungen von Blockchain-Technologie ..........32 

1.3.3 Technische Chancen und Potenziale ..............................................................34 

1.3.4 Technische Weiterentwicklungen von Blockchain ...........................................35 

2 Entwicklungen von BCT im Agri-Food-Sektor und Anwendungsfelder ..................37 

2.1 MarktĂźbersicht von Blockchain-Projekten im Agri-Food-Sektor ...................................37 

2.2 Clusterung bisheriger Anwendungsfälle mit Relevanz fßr Lebensmittellieferketten ......43 

2.2.1 Supply Chain Management .............................................................................43 

2.2.1.1 Aktuelle Problemstellungen ......................................................................44 

2.2.1.2 LĂśsungspotenziale und Anwendungsbeispiele .........................................44 

2.2.1.3 Herausforderungen von Blockchain im Supply Chain Management .........50 

2.2.2 Auditierung und Zertifizierung ..........................................................................50 

2.2.2.1 Aktuelle Problemstellungen ......................................................................50 

2.2.2.2 LĂśsungspotenziale und Anwendungsbeispiele .........................................52 

2.2.2.3 Herausforderungen von Blockchain in der Auditierung und Zertifizierung .53 

2.2.3 Internet der Dinge (IoT) ...................................................................................53 

2.2.3.1 Aktuelle Problemstellungen ......................................................................53 

2.2.3.2 LĂśsungspotenziale und Anwendungsbeispiele .........................................54 

2.2.3.3 Herausforderungen von Blockchain in Verbindung mit IoT-LĂśsungen ......56 

 



3 
 

3 Hypothesen zur Relevanz von Blockchain fĂźr Lieferkette-Akteure .........................57 

3.1 H1: Form des Vertrauens in abgespeicherte Daten verändert sich durch Blockchain-

LĂśsung ........................................................................................................................57 

3.2 H2: Manipulationssicherheit der BCT kann besonders fĂźr Echtheitsnachweise im 

asiatischen Markt interessant werden/sein ..................................................................59 

3.3 H3: Hype um Blockchain unter Lebensmittelhändlern liegt im Interesse an maximaler 

Transparenz der ZulieferstrĂśme ..................................................................................60 

3.4 H4: Blockchain dient in diversen Projekten eher als Marketinginstrument ...................61 

3.5 H5: Eigenschaften der Blockchain kann Unternehmen / Branchen vor 

Reputationsschäden besser schßtzen .........................................................................62 

4 Hypothesen zur Relevanz von Blockchain fĂźr QS als Standardgeber.....................63 

4.1 H1: Zentrale, unabhängige Kontrollinstanzen wird es auch in einer „Blockchain-

Lieferkette“ bedürfen ...................................................................................................63 

4.2 H2: Blockchain kĂśnnte zu einem Paradigmenwechsel hinsichtlich des Eigentums an 

Daten im QS-System fĂźhren ........................................................................................65 

4.3 H3: Blockchain-Technologie als Katalysator fĂźr IoT und Big Data kĂśnnte kĂźnftig die Art 

und Weise von Audits verändern .................................................................................65 

4.4 H4: Derzeitige Blockchain-Entwicklungen im Handel kÜnnten u. U. zu einer stärkeren 

Verhandlungsmacht des LEHs ggĂź. Zulieferern und auch dem QS-System fĂźhren .....66 

5 Kritische WĂźrdigung der Methoden und Ergebnisse, Fazit und Ausblick ..............68 

5.1 Kritische WĂźrdigung der Methoden und Ergebnisse ....................................................68 

5.2 Fazit und Handlungsempfehlungen .............................................................................69 

Anhang ................................................................................................................................73 

Literaturverzeichnis ...........................................................................................................78 

 

  



4 
 

Abbildungsverzeichnis 

 Ausprägungen der Blockchain-Technologie (i. A. an Meinel et al. 2018) .............11 

 Technische Elemente der Blockchain-Technologie (eigene Darstellung) ............12 

 Verwendung asymmetrischer SchlĂźsselpaare (Hinckeldeyn 2019) .....................14 

 Blockaufbau und -struktur (eigene Darstellung) ..................................................15 

 Merkle Tree (Antonopoulos 2017) .......................................................................16 

 Unterschiede de-/zentraler und verteilter Netzwerktopologie (Swanson 2015) ....18 

 Komplexitätsgrad von Smart Contracts (Morrison 2016) .....................................26 

 Agri-Food-Akteure mit Blockchain-Pilotprojekten (eigene Darstellung) ...............38 

 Bereits relevante Akteure fĂźr den Ag/Food-Bereich im Blockchain-Ecosystem ...40 

 Agri-Food-Blockchainprojekte von 2016 bis 2019 (i.A. an Anhang 1) ..................42 

 Sawtooth fĂźr Seafood Supply Chain Traceability (Hyperledger Sawtooth 2018) .56 

 Ebenen der Vertrauensbildung (DĂźring et al. 2017, S. 452) ................................58 

 Entscheidungsbaum fĂźr Verwendung von Blockchain (i. A. an Peck 2017; 

KĂźckelhaus et al. 2018; Meunier 2018) ..............................................................71 

  



5 
 

Tabellenverzeichnis 

Tab. 1: Differenzierung des Blockchain-Begriffes (Burgwinkel 2016; Swan 2015) ........... 7 

Tab. 2: Merkmale verschiedener Blockchain-Ausprägungen (i. A. an Drescher 2017) ....11 

Tab. 3: Abgrenzung mĂśglicher Netzwerkstrukturen (Swanson 2015; Burgwinkel 2016) ..18 

Tab. 4: GegenĂźberstellung vorgestellter Konsensmodelle (Bogensperger et al. 2018) ...24 

Tab. 5: Ausprägungen von Smart Contract Oracles ........................................................27 

Tab. 6: Vor- und Nachteile von Smart Contracts fĂźr BCT ................................................27 

Tab. 7: Module des IBM Food Trust Systems (IBM Food Trust 2019) .............................48 

Tab. 8: Stärken, Schwächen, Chancen und Risiken der Blockchain-Technologie ...........69 

  



6 
 

1 Blockchain-Technologie 

1.1 Blockchain – Ein erster Überblick 

Im folgenden Abschnitt wird ein Überblick der wesentlichen Funktionsweisen sowie 

technischen Grundlagen von Blockchain-Technologie (BCT) gegeben. Neben einer 

Begriffsdefinition und -abgrenzung werden unterschiedliche Ausprägungen der BCT 

dargestellt. Das Kapitel schließt mit einer Darstellung der Ursprünge dieser Enabler-

Technologie ab. 

1.1.1 Definition und Charakteristika der Blockchain-Technologie 

Nach (Mattila 2016) oder (Swan 2015) lässt sich der Terminus Blockchain heute noch nicht 

einheitlich definieren. Die Betrachtung diverser Publikationen, die sich mit der Definition von 

BCT auseinandersetzen, zeigt aber dennoch wesentliche Gemeinsamkeiten, mit denen die 

Technologie beschrieben werden kann. So kann eine Blockchain als digitales Protokoll oder 

Register verstanden werden, indem Transaktionen, Ereignisinformationen oder sonstige 

Daten in einem dezentralen Netzwerk durch die Netzwerkteilnehmer verwaltet werden 

(Condos et al. 2016). Dabei werden Informationen „blockweise“ verarbeitet und 

chronologisch mittels kryptographischer Signaturen miteinander zu einer „Kette“ verknüpft 

(Walport 2015). Aus den Definitionen der zitierten Autoren wird deutlich, dass sich die 

Blockchain als elektronisches Kontenbuch oder Register von der dahinterstehenden 

Verwaltungssystematik der BCT unterscheidet. Glaser und Bezzenberger (2015) definieren 

die Blockchain-Technologie als einen dezentralen Konsensmechanismus, der auf Elementen 

der Kryptographie und Peer-to-Peer-Logik (P2P) aufbaut und so ein digitales 

Verwaltungssystem fĂźr manipulationssichere Daten ermĂśglicht. Anstelle einer einzigen 

zentralen, autoritären Kontrollinstanz werden neue Informationen im Netzwerk durch einen 

Konsens der Netzwerkteilnehmer selbst verifiziert (Schlatt et al. 2016). Hosp (2018) gibt 

folgende zusammenfassende Definition:  

„Eine Blockchain ist eine digitale Datei, in der dieselbe Information von allen Mitgliedern 

einer Gesellschaft abgespeichert und Updates in regelmäßigen Zeitblöcken an die 

bereits bestehende Information gehängt werden, sodass jeder Teilnehmer die gesamte 

Information besitzt und sich nicht auf andere verlassen muss.“  

Die wesentlichen Elemente der BCT – Kryptographie und Dezentralität – in Form von P2P-

Netzwerken werden nachfolgend näher erläutert: Nach Mullender (1995) lassen sich 

dezentrale Datenbanksysteme nicht eindeutig definieren und lediglich anhand diverser 

Charaktereigenschaften identifizieren. Entscheidend ist nach Schlatt et al. (2016) die 

Vernetzung räumlich verteilter, voneinander unabhängiger Rechner bzw. Netzwerkknoten zur 

Kommunikation und kontinuierlichen Synchronisation des aktuellen, replizierten 



7 
 

Informationsstatus. Bei einem Ausfall eines Rechners bzw. Knotenpunktes arbeitet das Ăźbrige 

Netzwerk ohne Beeinträchtigung weiter, sobald der ausgefallene Knotenpunkt wieder online 

im Netzwerk ist, aktualisiert sich seine gespeicherte Version der Blockchain auf den aktuellen 

Informationsstatus. Bezeichnend fĂźr ein Peer-to-Peer-Netzwerk ist zudem die bereits 

erwähnte, direkte Interaktion von Teilnehmern bzw. Knotenpunkten beim Austausch von 

Daten, ohne dass es einer zentralen Koordinations- / Kontrollinstanz bedarf (Schoder und 

Fischbach 2002; Glaser und Bezzenberger 2015). 

Bei der ersten Blockchain-Anwendung ‚Bitcoin‘ werden alle Transaktionsdaten aus einem 

Zeitfenster von zehn Minuten erfasst und als Block der bestehenden Blockchain angehangen. 

Auf diese Weise entsteht eine chronologische und lineare Aneinanderreihung von 

DatenblĂścken. Jeder neu angefĂźgte Block beinhaltet einen Referenzwert zu seinem 

Vorgängerblock, wodurch die Verkettung der einzelnen BlÜcke entsteht. Als Full Nodes 

bezeichnete Rechner im Netzwerk, realisieren dank ihrer ausreichenden Rechenleistung das 

sog. Mining. Neben der gesamten Blockchain haben diese Rechner bzw. ihrer Betreiber eine 

zusätzliche Mining-Applikation lokal installiert, um die Generierung neuer BlÜcke und die 

Verifizierung eingehender Transaktionen sicherzustellen (Swan 2015; Burgwinkel 2016). 

In der bestehenden Fachliteratur werden verschiedene Blockchain-Begriffe teilweise unter 

dem Oberbegriff „Blockchain“ angeführt. In der nachfolgende Tabellen 1 werden BCT-Begriffe 

differenziert, die oftmals fälschlicherweise unter dem identischen Oberbegriff gemeint sind: 

Tab. 1:  Differenzierung des Blockchain-Begriffes (Burgwinkel 2016; Swan 2015) 

Begriff Definition 

Blockchain als 
Architektur 

Gemeint ist die Kombination verschiedener Disziplinen der 
Informationstechnologie: Verschlüsselung mittels Hash-Algorithmus –  
z. B. SHA256 und der Nutzung einer digitalen Signatur bzw. 
asymmetrischer SchlĂźsselpaare. 

Blockchain-
Plattformen 

Gemeint ist das verteilte Netzwerk – bestehend aus über das Internet 
miteinander verbundenen, voneinander unabhängigen Rechnern – in 
denen die Blockchain-Software genutzt wird. 

Blockchain-
Software 

Gemeint ist der Programmcode, der notwendig ist, um im Netzwerk auch 
tatsächlich agieren zu kÜnnen. Bereits 2016 sind nach  
(Burgwinkel) Ăźber 20 Software-LĂśsungen (Open-Source und Kommerziell) 
vorhanden. Als Beispiele sind hier die Software von ‚Bitcoin‘ oder 
‚Ethereum‘ zu nennen. 

Blockchain-
Applikation 

Applikationen werden auf Basis der Software auf einer Blockchain 
Plattform angeboten. Bsp.: Auf der Ethereum-Software kĂśnnen mehrere 
Applikationen realisiert werden (IDEX oder EtherDelta). 

Blockchain 1.0 Die Anwendung von Blockchain in der ersten Generation bezog sich 
ausschließlich auf Kryptowährungen und den digitalen Zahlungsverkehr 

Blockchain 2.0 In der zweiten Generation von Blockchain-Anwendungen wurden mittels 
der Realisierung von Smart Contracts Geschäftsprozesse, die ßber eine 
Finanztransaktion hinausgehen, auf Basis einer Blockchain-Software 
abbildbar. 



8 
 

Blockchain 3.0 In der dritten Generation dehnt sich die Anwendung von Blockchain auf 
sämtliche Wirtschaftsbereiche (BehÜrden, Gesundheitssystem etc.) aus. 

Blockchain-as-
a-Service 
(BaaS) 

Blockchain als Service auf Basis einer Cloud-LĂśsung, wobei aber alle 
beschriebenen Ebenen berĂźcksichtigt sind. 

 

Zusammenfassend lassen sich an dieser Stelle bereits die wesentlichen 

Charaktereigenschaften von Blockchain Technologie festhalten. Neben den Grundprinzipien 

der Technologie, die bereits im ersten White Paper zu Blockchain bei Nakamoto (2009) 

inbegriffen waren, sind im Laufe der Entwicklung noch weitere Eigenschaften 

hinzugekommen. Heute finden sich diese Grundprinzipien jeweils unterschiedlich ausgeprägt 

immer wieder. Nachfolgend werden diese in KĂźrze dargestellt (Tanenbaum und van Steen 

2016; Mougayar und Buterin 2016; Tapscott und Tapscott 2018).  

Blockchain als verteiltes Netzwerk, das offen zugänglich ist und einen direkten Austausch 

zwischen den Netzwerkteilnehmern erlaubt: 

1. Es bedarf keines Vertrauensintermediärs, da das System ohne Vertrauen zwischen 

den Teilnehmern funktioniert. 

2. Einmal abgespeicherte Informationen in der „Blockkette“ sind nachträglich 

unveränderbar. 

3. Die Blockchain Technologie kennzeichnet sich durch ihre Sicherheit, die auf den 

Grundsätzen der Kryptographie basiert. Auf diese Weise ist zudem die anonyme 

Interaktion im Netzwerk abbildbar.  

Bedingt durch die Entwicklung hin zur zweiten Generation der Blockchain Technologie und die 

Umsetzung von Smart Contracts sind weitere Chrakteristika hinzugekommen (Swan 2015):  

4. Automatisierung von Geschäftsbedingungen / -prozessen. 

5. Interaktion im Rahmen einer Transaktion auf beliebige Prozessschritte ausdehnbar. 

Des Weiteren ist die Technologie in Bezug auf den Kontext unterschiedlich zu betrachten. 

Mougayar und Buterin (2016) grenzen hier drei Dimensionen voneinander ab:  

1. Technische Sichtweise = Blockchain als Datenbank-System im Backend, auf 

dessen Basis die Verwaltung eines digitalen, offenen 

Ledgers abbildbar ist. 

 

2. Wirtschaftliche Sichtweise  = Blockchain als Netzwerk, das den digitalen und 

direkten Austausch von Werten zwischen seinen 

Systemteilnehmern ermĂśglicht. 

 



9 
 

3. Rechtliche Sichtweise = Blockchain als Prinzip bzw. Verfahren um 

vertrauensbedĂźrftige Transaktionsprozesse digital 

ohne einen Intermediär abzubilden. 

 

1.1.2 Abgrenzung verschiedener Blockchain-Arten 

Eine Blockchain kann in verschiedenen Ausprägungen genutzt werden. Je nach 

Anforderungen der Netzwerkteilnehmer lässt sich das Protokoll der zu nutzenden Blockchain-

LÜsung entsprechend formulieren. Grundsätzlich lassen sich die unterschiedlichen 

Blockchain-Arten anhand von zwei Eigenschaften voneinander abgrenzen: (1) den 

Zugriffsrechten und (2) der Konsenslogik (Drescher 2017). 

Bei den Zugriffsrechten unterscheidet man zwischen sog. Private und Public Blockchains:  

Bei einer Ăśffentlichen (public) Blockchain kann jeder durch den Download des Codes am 

Netzwerk teilnehmen und einen Knotenpunkt betreiben. Handelt es sich dabei um eine sog. 

Permissionless Blockchain in Bezug auf die angewandte Konsenslogik, kann außerdem 

jeder Teilnehmer des Netzwerkes am Validierungsprozess neuer Transaktionen mitwirken. 

Eine solche Blockchain steht also grundsätzlich jedermann fßr weltweite Transaktionen offen. 

Transaktionen sind damit vollkommen transparent, aber dennoch anonym, da jeder 

Teilnehmer unter einem „Pseudonym“ – in Form seines öffentlichen Schlüssels – im Netzwerk 

agiert. Beispiele für diese Blockchain-Form sind die ‚Bitcoin‘-Blockchain, ‚Ethereum‘, ‚Litecoin‘ 

oder ‚Dash‘. Die wesentliche Motivation bei einer solchen Ausprägung liegt in dem Misstrauen 

ggü. zentralen Kontrollinstanzen. Den größten Einfluss kann diese Form von Blockchain daher 

auf die Disruption bestehender Geschäftsmodelle nehmen, die als Intermediäre zwischen den 

eigentlichen Geschäftspartnern agieren. Durch die absolute Dezentralität des Netzwerkes, 

verteilt auf die Rechner der Teilnehmer, minimieren sich zudem die Infrastrukturkosten, da 

kein großer Hauptserver gewartet und betrieben werden muss bzw. vor einem Ausfall oder 

Hacker-Angriffen aufwendig geschĂźtzt werden muss (Drescher 2017; Meinel et al. 2018). 

Konsortiale, Federated Blockchains: Im Gegensatz zu Ăśffentlichen, permissonless 

Blockchains, wie z. B. der ‚Bitcoin‘-Blockchain, werden konsortiale Blockchains von einer 

Gruppe von Unternehmen oder anderen Institutionen gefĂźhrt bzw. betrieben. Diese Form der 

Blockchain kann hinsichtlich der Lese- und Schreibrechte fßr jedermann frei zugänglich sein 

oder den Mitgliedern des Konsortiums vorbehalten sein. Die Validierung neuer Transaktionen 

obliegt aber vorab definierten Knotenpunkten, die i. d. R. verteilt bei den Mitgliedern des 

Konsortiums liegen. Durch die geringere Anzahl an Knotenpunkten, die am Konsensprozess 

teilnehmen, liegt bei dieser Blockchain-Form eine hĂśhere Skalierbarkeit vor. Transaktionen 

kĂśnnen somit schneller durchgefĂźhrt werden (Hosp 2018). Beispiele fĂźr konsortiale 

Blockchain-LĂśsungen finden sich im Bankensektor, der Energie- oder Logistikbranche: 20 



10 
 

Institutionen schließen sich zusammen, um eine branchenfähige Blockchain-Lösung zu 

realisieren und betreiben dazu jeweils einen Knotenpunkt fĂźr die Validierung von 

Transaktionen. Als Beispiele für diese Form der Blockchain-Technologie sind ‚r3‘, ‚Corda‘, 

‚EWF‘ (Energie) oder ‚B3i‘ (Versicherungen) zu nennen. Den größten Einfluss hat diese 

Ausprägung der BCT auf das Potenzial der Transaktionskostenreduktion, indem 

Dokumentations- und Compliance-Aufwand minimiert werden kĂśnnen (Meinel et al. 2018). 

Diese Form der BCT kann damit grundsätzlich als weniger disruptiv eingestuft werden, als die 

Public Blockchains. Die mĂśglichen Kosten- und Effizienzvorteile im Business-Kontext sind 

aber nichtsdestotrotz zu bedenken (Meinel et al. 2018; Hosp 2018) 

Private Blockchains umfassen Anwendungen der Blockchain-Technologie in einem einander 

bekannten Teilnehmerkreis, zwar mit verteilten Speichermedium, aber bspw. innerhalb eines 

Unternehmens oder einer Institution. 

 Bei dieser Ausprägung der BCT geht der eigentliche Mehrwert der Disintermediation verloren. 

So obliegen die Schreibrechte und der Konsensprozess zur Validierung neuer 

Transaktionsinformationen einer klar definierten Gruppe an Teilnehmern, die i. d. R. einer 

einzigen Organisation angehĂśren. Leserechte kĂśnnen in einem solchen Fall Ăśffentlich oder 

zumindest einer breiteren Anzahl an Nutzern erteilt werden. Während Skalierbarkeit und 

Datenschutz in solchen Blockchain-LĂśsungen ggĂź. Ăśffentlichen BCs optimiert sind, liegt das 

Problem in der VertrauenswĂźrdigkeit der prĂźfenden Teilnehmer, die eher zentralen Charakter 

haben. Denkbar sind solche Anwendungen fĂźr Datenmanagement oder Auditprozesse 

innerhalb eines Unternehmens oder einer Organisation. Ein Beispiel fßr diese Ausprägung von 

BCT ist ‚MultiChain‘ (Meinel et al. 2018). 

 



11 
 

 Ausprägungen der Blockchain-Technologie (i. A. an Meinel et al. 2018) 

Der Unterschied bzw. die Vorteile zwischen privaten und Üffentlichen Blockchains lässt sich 

anhand der folgenden Merkmale verdeutlichen:  

Tab. 2: Merkmale verschiedener Blockchain-Ausprägungen (i. A. an Drescher 2017) 

 

 

1.1.3 UrsprĂźnge der Blockchain-Technologie 

Um Blockchain zu begreifen, hilft es einen Blick auf die Entstehung der ersten Blockchain-

Anwendung ‚Bitcoin‘ zu werfen: Zu unterscheiden sind die beiden Begriffe relativ leicht. So ist 

‚Bitcoin‘ eine Anwendung der Blockchain-Technologie. Man kann sich vorstellen, dass 

Blockchain wie ein Betriebssystem vorhanden sein muss, um diverse Anwendungen nutzen 

zu kĂśnnen. Bitcoin ist dabei nur eine von vielen Anwendungen, die auf Basis von Blockchain 

realisierbar ist. Die Entwicklung der Blockchain-Technologie geht dabei in der Geschichte der 

Informatik weit zurĂźck. Als ersten Ansatzpunkt kann die Erfindung von Ralph Merkle im Jahr 

1979 mit dem Merkle-Tree-Prinzip genannt werden. Die erste elektronische Währung wurde 

1983 von David Chaum in einem White Paper diskutiert. In den 1990er-Jahre wurde erstmalig 

die kryptographische Verkettung einzelner Datensätze mittels Hash-BlÜcken entwickelt (Bayer 

et al. 1993). Adam Back stellte 1997 die Basis eines Algorithmus vor, der das Proof-of-Work-

Prinzip1 von Bitcoin darstellte und damit die Grundvoraussetzung digitaler Währungen 

darstellt. UrsprĂźnglich wurde Proof-of-Work entwickelt, um E-Mail-Spams entgegenzuwirken. 

Aus einer Kombination all dieser Ansätze ist Blockchain entstanden. Die ursprßngliche Idee 

dieser Technologie wird im Whitepaper von Bitcoin (2008) beschrieben: AuslĂśser waren 

Vertrauensverluste in zentrale Institutionen, die mit ihnen anvertrauten monetären Werten 

risikoreiche Geschäfte tätigten. Vertrauensmissbrauch und damit einhergehender 

Datenmissbrauch hatten globale Auswirkungen auf Wirtschaftssysteme. Die Idee hinter der 

Blockchain-Technologie war eine Veränderung auf systemischer Ebene, um Veruntreuung / 

                                                
1 Proof-of-Work ist das derzeit bekannteste Konsensverfahren in der Blockchain-Technologie und dient dazu, in 
einem dezentralen System ohne „die eine“ Kontrollinstanz Einigkeit unter den Teilnehmern über 
Wahrheitszustände zu definieren. Nähere Erläuterung in Kapitel 1.2.6 



12 
 

Betrug digital zu erschweren und zentrale Kontrolleinheiten mit einer ungleichen 

Machtverteilung in einem System ĂźberflĂźssig zu machen (Antonopoulos 2018; Rosenberger 

2018). 

1.2 Funktionsweisen von BCT 

Um die Funktionsweisen der Blockchain Technologie zu verstehen und nachzuvollziehen, 

warum die o. g. Charaktereigenschaften der Technologie Ăźberhaupt mĂśglich sind, hilft ein 

grundsätzliches Verständnis der Einzelelemente, die innerhalb der BCT ihre Anwendung 

finden. Aus technischer Sicht liegt die Innovation der BCT in der einzigartigen Kombination 

aus Elementen der Informatik zu einem kohärenten Ansatz, wie es ihn vorher eben nicht gab. 

Die nachfolgende Abbildung fasst diese Elemente zusammen, auf die im Nachgang jeweils in 

KĂźrze eingegangen wird. 

 

  Technische Elemente der Blockchain-Technologie (eigene Darstellung) 

1.2.1 Kryptographische Hash-Funktionen 

Eine Hash-Funktion ermĂśglicht die VerschlĂźsselung eines beliebig langen Inputwertes zu einer 

immer einheitlich langen Abfolge von hexadezimalen Zeichen, die als Hashwert bezeichnet 

wird. Verändert man die ursprßngliche Zeichenfolge nur minimal, so ändert sich der daraus 

resultierende Hash-Wert gravierend (Condos et al. 2016; Franco 2014). Hashfunktionen 

reduzieren damit große Datenmengen in eine kleinere Zeichenfolge und können als der 

digitale Fingerabdruck eines Datensatzes verstanden werden, Ăźber den ein Datensatz 

eindeutig identifiziert werden kann (Gupta 2017; Hinckeldeyn 2019). In der Blockchain-

Technologie wird derzeit der Secure Hash Algorithm SHA-256 verwendet. Die Zahl 256 gibt 

dabei an, dass ein Hash-Wert immer eine Größe von 256 Bit besitzt. Diese Hash-Funktion gilt 

bis heute als extrem sicher hinsichtlich der Verschlßsselung von Datensätzen (Narayanan et 

al. 2016). 

Grundsätzlich lassen sich fßnf Eigenschaften der kryptographischen Hashfunktionen 

zusammenfassen (Drescher 2017): 



13 
 

Zuerst sind kryptographische Hashfunktionen kollisionsresistent. Mit einer Kollision ist 

gemeint, dass aus zwei unterschiedlichen, voneinander unabhängigen Inputgrößen der 

gleiche Hashwert resultiert. Kollisionsresistenz besteht demnach, wenn kein identischer 

Hashwert fĂźr zwei voneinander abweichende Inputdaten generiert wird (Hinckeldeyn 2019). 

Aus mathematischer Sicht kann es zwar theoretisch zu einer solchen Kollision kommen, 

praktisch benĂśtigt ein Rechner, der 10.000 Hash-Werte/Sek. berechnen kann, bei einer 

SHA256-Hashfunktion ßber 1027 Jahre, um lediglich die Hälfte aller 

KombinationsmĂśglichkeiten auf eine Hash-Kollision zu prĂźfen (Paar et al. 2010). 

Dennoch sind die Hashwerte dabei deterministisch, d. h. eine Hashfunktion generiert bei 

identischem Dateninput immer wieder exakt den gleichen Hashwert. Die dritte Eigenschaft 

liegt in der Pseudozufälligkeit der generierten Hashwerte. Dies bedeutet, dass eine minimale 

Änderung bei der Dateneingabe zu einem völlig anderen Hashwert führt.  

Bei kryptographischen Hashfunktionen handelt es sich zudem um sog. Einwegfunktionen 

(Hinckeldeyn 2019). Bekannt unter dem Begriff Nonce (Number only used once), wird dem 

Inputdatensatz eine beliebige, geheime Zahl beigefßgt. Mittels dieses Nonce lässt sich ein 

Inputwert nachträglich nicht mehr einfach so ermitteln (Bogensperger et al. 2018). 

Die fĂźnfte Eigenschaft von Hash-Funktionen ist die sog. Puzzle Friendliness. Mathematisch 

beschrieben liegt hierin die Tatsache, dass ein Nonce-Wert in einer Hash-Funktion fĂźr jede 

OutputmĂśglichkeit n der Funktion nicht unterhalb der Zeit 2n gefunden werden kann. Diese 

Eigenschaft fĂźhrt dazu, dass sich keine LĂśsungsstrategie besser empfiehlt als das schiere 

Durchprobieren von mĂśglichen Nonce-Werten, bis der richtige Nonce-Wert gefunden wurde 

(Adolph et al. 2019). 

FĂźr die Blockchain-Technologie stellen kryptographische Hashfunktionen ein wesentliches 

Element dar. So lassen sich auf diese Weise Transaktionsdaten verschlĂźsseln, eindeutig 

identifizieren und verifizieren sowie signieren. Nach Wang et al. (2019) lassen sich generell 

sechs Anwendungen von Hashfunktionen in der Blockchain-Technologie kategorisieren: 

 Hiding-Prozess: Transaktionsdaten mit Zufallszahlen versehen 

 Verteilte Konsensmechanismen (siehe Kap. 1.2.6) 

 Signaturen bei Transaktionsdurchführung (siehe Kap. 1.2.2) 

 Identitätsnachweise 

 Blockgenerierung (siehe 1.2.3) 

 Adresserstellung für Blockchain-Anwendungen 

1.2.2 Digitale Signatur 

Das Prinzip der Digitalen Signaturen ist in der Kryptographie schon in den 1970er Jahren 

diskutiert worden und auf Diffie und Hellman (1976) zurĂźckzufĂźhren (Schlatt et al. 2016). Mit 



14 
 

der Generierung eines asymmetrischen, mathematisch miteinander verbundenen 

SchlĂźsselpaares (je ein privater und ein Ăśffentlicher SchlĂźssel) kĂśnnen digitale Signaturen 

erstellt werden (Franco 2014). Hierbei werden Hashwerte auf Basis von Sicherheitswerten 

erzeugt. Jeder Netzwerkteilnehmer erhält ein asymmetrisches Schlßsselpaar: der private 

SchlĂźssel muss dabei geheim bleiben, der Ăśffentliche SchlĂźssel wird dem Netzwerk vorgestellt 

(Hinckeldeyn 2019). Während der Ersteller einer Nachricht mit seinem privaten Schlßssel 

„unterschreibt“, sendet er die signierte Botschaft an den öffentlichen Schlüssel des 

Empfängers. Der Empfänger wiederrum kann die Nachricht nun mit dem Üffentlichen Schlßssel 

des Absenders abgleichen und so auf Authentizität ßberprßfen (Diffie und Hellman 1976). 

Entschlßsselt wird die Nachricht wiederrum mit dem privaten Schlßssel des Empfängers. Auf 

diese Weise liefert die digitale Signatur fßr jeden Teilnehmer im Netzwerk eine Identität. So 

lassen sich Aktionen im Netzwerk personalisieren und Signaturen nicht replizieren (Narayanan 

et al. 2016). Mit dieser Funktionsweise erfĂźllt die sog. Public-Key-Krypotgraphie zwei 

wesentliche Anforderungen an die Blockchain-Technologie: die sichere DatenĂźbertragung im 

Netzwerk und die eindeutige Identifikation von Netzwerkteilnehmern – zwar unter Pseudonym, 

aber unverfälschbar und sicher (Schlatt et al. 2016). Die nachfolgende Abbildung von 

Hinckeldeyn (2019) veranschaulicht die Verwendung in der Blockchain-Technologie: 

 

  Verwendung asymmetrischer SchlĂźsselpaare (Hinckeldeyn 2019) 



15 
 

1.2.3 Blockchain-Datenstruktur 

Die mittels Hash-Funktion verschlßsselten Datensätze gilt es in einem strukturierten Verfahren 

abzulegen. Dabei ist nicht nur der Dateninhalt selbst, sondern auch die Signatur und die 

VerknĂźpfung der einzelnen BlĂścke zueinander berĂźcksichtigt. Zur VerknĂźpfung der BlĂścke 

dient der sog. Hash-Pointer, welcher eine Referenz zu seinem Vorgänger-Block umfasst und 

damit die im Vorgängerblock berechneten Datensätze berßcksichtigt. Verändert sich ein Wert 

in einem Vorgängerblock, passt der Hash-Pointer des Folgeblocks nicht mehr und ab dieser 

Stelle ist die gesamte Kette in ihren Hash-Pointern nicht mehr in sich stringent. Ziel der Hash-

Pointer ist damit in erster Linie, die Manipulationssicherheit einer Blockchain zu realisieren. 

Die nachfolgende Abbildung 4 veranschaulicht die Struktur der BlĂścke. Im der unteren Kette 

werden dabei die Folgen eines Manipulationsversuchs veranschaulicht: Ändert sich ein 

Hashwert einer Transaktion in Block 2, ändert sich der Hash-Pointer dieses Blocks, sodass 

dieser nicht mehr mit den Daten in Block 3 Ăźbereinstimmt. 

  

 

  Blockaufbau und -struktur (eigene Darstellung) 

Neben den essentiellen Angaben in der Abbildung 4, die fĂźr die Verkettung der einzelnen 

BlĂścke wichtig sind, werden noch weitere Angaben in einem jeden Block hinterlegt. Auf diese 

wird im nachfolgenden Kapitel 1.2.4 noch weiter eingegangen. Zuvor wird in KĂźrze die 

Datenstruktur zur VerknĂźpfung einzelner BlĂścke in einer";"""date"",""2019-11-05T11:26:27Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.5""
""xmp:CreatorTool"",""MicrosoftÂŽ Word 2016""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dc:creator"",""Simone Kemper""
""language"",""de""
""dcterms:created"",""2019-11-05T11:26:27Z""
""Last-Modified"",""2019-11-05T11:26:27Z""
""dcterms:modified"",""2019-11-05T11:26:27Z""
""dc:format"",""application/pdf; version=1.5""
""Last-Save-Date"",""2019-11-05T11:26:27Z""
""pdf:docinfo:creator_tool"",""MicrosoftÂŽ Word 2016""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2019-11-05T11:26:27Z""
""meta:save-date"",""2019-11-05T11:26:27Z""
""pdf:encrypted"",""false""
""modified"",""2019-11-05T11:26:27Z""
""Content-Length"",""3468808""
""pdf:hasMarkedContent"",""true""
""Content-Type"",""application/pdf""
""pdf:docinfo:creator"",""Simone Kemper""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Simone Kemper""
""dc:language"",""de-DE""
""meta:author"",""Simone Kemper""
""meta:creation-date"",""2019-11-05T11:26:27Z""
""created"",""2019-11-05T11:26:27Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""85""
""Creation-Date"",""2019-11-05T11:26:27Z""
""resourceName"",""Forschungsbericht-Ermittlung-Potenziale-ausgew%C3%A4hlte-Distri.pdf""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""585"",""3837"",""2434"",""1272"",""775"",""2712"",""3066"",""2184"",""2887"",""1798"",""2345"",""1876"",""2655"",""1563"",""1837"",""2143"",""2523"",""1752"",""2931"",""2891"",""3049"",""3038"",""2879"",""2222"",""2834"",""2069"",""2795"",""2533"",""2742"",""2688"",""2961"",""2525"",""2547"",""2696"",""2694"",""1770"",""2751"",""1675"",""3097"",""1996"",""2823"",""353"",""2816"",""2765"",""2960"",""2828"",""2801"",""2723"",""2879"",""2521"",""2928"",""2774"",""2672"",""2924"",""1915"",""1471"",""2286"",""1863"",""3086"",""2969"",""2930"",""3072"",""2934"",""2996"",""3021"",""3105"",""644"",""2795"",""2295"",""2080"",""167"",""2877"",""12"",""6"",""6"",""7"",""9"",""3027"",""3244"",""2927"",""2820"",""3126"",""2875"",""2960"",""2044""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""Author"",""Simone Kemper""
""producer"",""MicrosoftÂŽ Word 2016""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""MicrosoftÂŽ Word 2016""
""pdf:docinfo:created"",""2019-11-05T11:26:27Z""
";https://scholar.google.com/scholar?start=610&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094581-826;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Tighter Security Proofs for Post-quantum Key Encapsulation Mechanism in the Multi-challenge Setting;Z Zhang, P Wei, H Xue ; … Conference on Cryptology and Network Security, 2019  Springer;;"… We consider quantum adversaries which are given quantum access to the random oracles. For

a oracle function \(H:\{0,1\}^n \rightarrow \{0,1\}^m\), the quantum access to H is modeled by

\(O_H:|x\rangle |y\rangle \rightarrow |x\rangle |y\oplus H(x)\rangle ,\) where \(x\in \{0,1\}^n …";Cité 1 fois;Les 3 versions;null;;;;https://scholar.google.com/scholar?start=640&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094583-837;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[CITATION][C] Traceable and linkable ring signatures, traceable range proofs and applications on regulatable privacy-preserving blockchains.;W Li, L Chen, X Lai, X Zhang, J Xin ; IACR Cryptol. ePrint Arch., 2019;;null;Cité 2 fois;;null;;;;https://scholar.google.com/scholar?start=650&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094628-1030;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Are These Pairing Elements Correct? Automated Verification and Applications;S Hohenberger, S Vusirikala ; Proceedings of the 2019 ACM SIGSAC …, 2019  dl.acm.org;;"Page 1. Are These Pairing Elements Correct? Automated Verification and Applications

Susan Hohenberger susan@cs.jhu.edu Johns Hopkins University Satyanarayana Vusirikala

satya@cs.utexas.edu University of Texas at Austin ABSTRACT …";Cité 1 fois;Les 2 versions;[PDF] acm.org;https://dl.acm.org/doi/pdf/10.1145/3319535.3339808?casa_token=JOlzsuiJm-sAAAAA:mWmReVUqnaVXMUe-XKNgFOBbe13V-48IO-GwaFFknUWbeyp4Fy-r75O89BWTU14otmRr5Dq7iG8;;;https://scholar.google.com/scholar?start=840&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094616-971;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Edge computing, iot and social computing in smart energy scenarios;I Sittón;Candanedo, RS Alonso, Ó García, L Muńoz…  Sensors, 2019  mdpi.com;;"… The oracles are responsible for verifying and sending data to the blockchain and work as

intermediaries between the blockchain and the devices … Thanks to the Crypto-IoT boards developed

by the BISITE Research Group of the University of Salamanca (Spain), this layer …";Cité 36 fois;Les 8 versions;[PDF] mdpi.com;https://www.mdpi.com/1424-8220/19/15/3353/pdf;;;https://scholar.google.com/scholar?start=790&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094579-816;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Direct CCA-secure KEM and deterministic PKE from plain LWE;X Boyen, Q Li ; International Conference on PostQuantum …, 2019  Springer;;"… security, these heuristic security arguments need to be made in quantum random-oracle models

[6] which are not very well understood. For these reasons, designing an efficient and practical

post-quantum KEM in the standard model (without random oracles) is already …";Cité 2 fois;Les 2 versions;[PDF] griffith.edu.au;https://research-repository.griffith.edu.au/bitstream/handle/10072/392997/Li301788-Accepted.pdf?sequence=2;"
Direct CCA-Secure KEM and Deterministic
PKE from Plain LWE

Xavier Boyen1 ?, Qinyi Li2 ??

1 QUT, Brisbane, Australia
2 Griffith University, Brisbane, Australia

qinyi.li@griffith.edu.au

Abstract. We present a particularly simple and efficient CCA-secure
public-key encapsulation scheme without random oracles or costly sam-
pling. The construction is direct in the sense that it eschews generic trans-
formations via one-time signatures or MACs typically found in standard-
model constructions. This gives us a compact, conceptually simpler, and
computationally efficient operation, that in particular does not require
any Gaussian sampling. Nevertheless, security is based on the hardness of
the plain learning-with-errors (LWE) problem with polynomial modulus-
to-noise ratio.
Of further interest, we also show how to obtain CCA-secure deterministic
public-key encryption (for high-entropy messages), that is more compact
and efficient than existing constructions.

1 Introduction

Public-key encryption (PKE) is a central cryptographic primitive to provide se-
cure communication over insecure networks without prior secret-key agreement.
In practice, due to its relative inefficiency, it is almost always used in conjunc-
tion with a secret-key cipher, where the former encrypts a random session key
for the latter, which then encrypts the actual data. This flow is the motiva-
tion for “hybrid encryption” [8], which consists of a (public-)key encapsulation
mechanism (KEM) and a data encapsulation mechanism (DEM). In terms of
security, it is well known [8] that if both KEM and DEM are CCA-secure, then
the hybrid encryption scheme is CCA-secure, which is the standard notion for
security of PKE against active attacks. While DEMs are readily obtained from
suitable symmetric-key modes of operation, in the case of KEMs substantial op-
timisations are to be gained by specialising them to work with random plaintexts
only.

Constructing CCA-secure KEMs is easy in principle. Applying the Fujisaki-
Okamoto transformations [10] to PKE/KEM schemes with weaker security guar-
antees (e.g., chosen-plaintext security) results in CCA-secure PKE/KEM schemes

? Research supported in part by ARC Discovery Project grant number DP140103885
and ARC Future Fellowship FT140101145 from the Australian Research Council.

?? Corresponding author



2

in the random oracle model. While this approach often leads to practical con-
structions, one can only make heuristic security arguments for them. Moreover,
when it comes to post-quantum security, these heuristic security arguments need
to be made in quantum random-oracle models [6] which are not very well un-
derstood. For these reasons, designing an efficient and practical post-quantum
KEM in the standard model (without random oracles) is already desirable and
well motivated.

There are two somewhat generic ways to construct CCA-secure PKE/KEM
from lattices in the standard model. The first one is via lossy trapdoor functions
[19] (e.g., the constructions from [19,21,16]) and the second one is via the BCHK
trasformation [5] from tag-based or identity-based encryption (IBE) (e.g. the
constructions from [15]). Both of them require strongly unforgeable one-time
signatures or message authentication codes (MACs) as building blocks. This
introduces noticeable extra overheads, making the schemes less efficient and less
compact.

In this paper, we primarily focus on constructing a KEM that is both con-
ceptually very simple and computationally efficient, but without compromising
its provable security. Specifically, we rely on a standard lattice problem (plain
learning with errors, a.k.a. LWE [20,17]) in the standard model. 3

1.1 Our Contributions

Our main contribution is a simple, compact, computationally efficient KEM
scheme without random oracles. The construction makes use of identity-based/tag-
based lattice trapdoor techniques [1,15]. The public key of our scheme includes
two matrices A ∈ Zn×mq and A1 ∈ Zn×wq , where w = ndlog qe, and a target-

collision-resistant compression or hash function f : Znq → {0, 1}λ, where λ is
the security parameter. The private key is a low norm matrix R ∈ Zm×w such
that A1 = AR (mod q). The ciphertext of our scheme contains two parts. The
first part is t = f(s) where s ∈ Znq is the randomness of the encapsulation al-

gorithm. The second part is a vector c> = b(p/q) · s> · [A|A1 + ϕ(t)G]c where
ϕ : Znq → Zn×nq is a full-rank difference encoding [1] (here t is encoded as a vec-
tor in Znq ) and G ∈ Zn×wq is the gadget matrix [15]. The session key is obtained
by applying a randomness extractor to s. When t is non-zero (which happens
with overwhelming probability), the lattice trapdoor (R,G) allows recovering s
and, thus, reproducing the session key. The key idea of our construction is to
make the identity/tag the hash value of the secret random vector s rather than
a verification key or a commitment in the BCHK transformation. In terms of
security, by using the LWE problem to (computationally) switch the rounding
function b(p/q) · s> · [A|A1 +ϕ(t)G]c to the so-called “lossy mode” [2], the ran-

3 We note that our approach here departs significantly from the recent NIST Post-
Quantum KEM competition, wherein most submitters chose to embrace random
oracles and stronger hardness assumptions (e.g., many variants of ring-LWE), to
address its rather idiosyncratic rules and success criteria.



3

dom vector s retains sufficient min-entropy (even conditioned on c and t) that
the session key would be random.

Our construction can be seen as a “direct” CCA-secure PKE/KEM con-
struction from identity-based/tag-based encryption in the sense that it does not
employ generic transformations. Such kind of direct constructions from pairing-
based IBE are known, e.g., [7,13,14]. From a high level idea, our KEM construc-
tion also has similarities to the CCA-secure PKE scheme from a lossy trapdoor
function (LTF) and all-but-one lossy trapdoor function (ABO-LTF) from [19].
In [19], the encryption is roughly done by evaluating a LTF and an ABO-LTF
(both are invertible) on the randomness. The well-formness of the ciphertext is
guaranteed by signing theses two evaluations with a one-time signature scheme
(the verification key also serves as the tag for the ABO-LTF). Our construction
“shrinks” this further by using only one (ABO) LTF plus a compression hash
function. For our KEM construction, the hash function, which is much lighter
than an LTF, is already lossy and enough to ensure that the ciphertext is well-
formed. One should also note that our construction is for CCA-secure KEM
which is a more specialised primitive than CCA-secure PKE studied in certain
earlier constructions.

Our KEM construction is of good computational efficiency. First, the en-
cryption process essentially involves a vector-matrix multiplication, a rounding
operation and a target-collision-resistant hash function. In particular, discrete
Gaussian sampling is avoided. Second, the decryption can be done efficiently in a
parallel fashion by using the so-called “gadget” trapdoor inversion first proposed
in [15].

In terms of space efficiency, since our KEM scheme is based on a relatively
stronger LWE assumption (but still with polynomial modulus-to-noise ratio),
compared to the most efficient existing CCA-secure lattice PKE/KEM construc-
tions in the standard model, e.g., [15], our construction would need relatively
larger matrix dimensions (to provide sufficient hardness for the LWE problem).
However, since our KEM ciphertext only consists of a single vector over a small
field and a small hash value (whose bit-size is the security parameter, e.g., 128),
and since our KEM private key is a low-norm matrix with very small entries (−1
and 1), the impact of requiring larger dimensions is rather limited.

As a by-product of our KEM scheme and its structure, we also give a CCA-
secure deterministic lattice PKE system. Deterministic PKE has useful direct
and indirect applications such as efficient searchable encryption and de-duplication
of encrypted databases. Our construction is efficient and compact than what
one would get through generic transformations (e.g., [4]). One drawback of our
deterministic PKE is that it requires an LWE hardness assumption here with
super-polynomial modulus-to-noise ratio, which is stronger than what we need
in the (randomised) KEM scheme.



4

2 Preliminaries

Notation. We denote the security parameter by Îť. We use bold lowercase letters
(e.g. a) to denote vectors and bold capital letters (e.g. A) to denote matrices. For
a positive integer q ≥ 2, let Zq be the ring of integers modulo q. We denote the
group of n×m matrices in Zq by Zn×mq . Vectors are treated as column vectors.

The transpose of a vector a is denoted by a>. For A ∈ Zn×mq and B ∈ Zn×m′

q ,

let [A|B] ∈ Zn×(m+m′)
q be the concatenation of A and B. We denote by x← X

the process of sampling x according to the distribution X. We denote s ←$ S
the process that of sampling element x uniformly from the set S.

For x ∈ Zp, define Transformq(x) = d(q/p)¡xe. For x ∈ Zq, define the rounding
function bxcp = b(p/q)¡xc. The functions Transformq(¡) and b¡cp naturally extend
to vectors by applying them component-wise.

For a security parameter Îť, a function negl(Îť) is negligible in Îť if it is smaller
than all polynomial fractions for a sufficiently large Îť.

Definition 1 (Bounded Distribution, [2]). For a distribution χ over the
reals, and a bound β, we say that χ is β-bounded if the average absolute value of
x← χ is less than β, i.e., if E[|x|] ≤ β.

Lemma 1. Let χ be a B-bounded distribution over Z. Let q ≥ p · (2B+1) ·nω(1)

be a prime. For e ← χ, u ←$ Zq, we have bu + ecp 6= bucp with probability
≤ (2B + 1) · p/q which is negligible in n.

We recall the notion of full-rank-difference encodings (FRD). Agrawal et al.
[1] gave an explicit construction of FRD, which we adapt in our construction.

Definition 2. Let n ≥ 1 be an integer and q be a prime. We say that a function
ϕ : Znq → Zn×nq is an encoding with full-rank differences (FRD) if:

1. ϕ is computable in polynomial time;
2. for all distinct u,v ∈ Znq , ϕ(u)− ϕ(v) ∈ Zn×nq is full rank (or invertible).

Definition 3. Let Îť be a security parameter, n = n(Îť), ` = `(Îť) and S be
a distribution over D. A set of functions F = {f : D → R} is a family of
compression hash functions if (1) There exists a p.p.t algorithm that takes as
input a security parameter 1Îť and uniformly samples a function f from F ; (2)
Given f , x ∈ D, the computation of f(x) can be done in p.p.t; (3) log |R| <
log |D|. We say F is second pre-image resistant if for all p.p.t algorithm A, the
advantage

AdvtcrF,A(Îť) =

[
x 6= x∗

and f(x∗) = f(x)
:
f ←$ F ; x∗ ← S
x← A(1λ, f, x∗)

]
≤ negl(λ)

We say F is Îľ-hard-to-invert w.r.t S if for all p.p.t algorithm A,

Pr[A(f(x), f) = x) : f ←$ F , x← S] ≤ ε.

A collection of compression hash functions is collision-resistant if it is second
pre-image resistant and negl(Îť)-hard-to-invert.



5

2.1 Public-Key Encapsulation

A public-key encapsulation (KEM) scheme Π = (KeyGen,Encap,Decap) with
key space KÎť consists of three polynomial-time algorithms. The key generation
algorithm KeyGen(1Îť) generates a public key Pk and private key Sk. The ran-
domised key encapsulation algorithm Encap(Pk) generates a session key K ∈ KΝ
and a ciphertext Ct. The decapsulation algorithm Decap(Pk,Sk,Ct) returns the
session key K or the error symbol ⊥. The correctness of a KEM scheme requires
that for all λ ∈ N, and all (K,Ct)← Encap(Pk),

Pr[Decap(Pk,Sk,Ct) = K] ≥ 1− negl(λ)

where the probability is taken over the choice of (Pk,Sk)← KeyGen(1λ) and the
random coins of Encap and Decap.

We recall the chosen-ciphertext security of KEM. The IND-CCA security of
a KEM scheme Π with session key space KΝ is defined by the following security
game. The challenger C runs (Pk,Sk) ← KeyGen(1λ), chooses a random coin
µ←$ {0, 1}, samples K∗0 ←$ Kλ, and computes (K∗1 ,Ct

∗)← Encap(Pk). Then C
passes (Pk,K∗µ,Ct

∗) to the adversary. The adversary launches adaptive chosen-
ciphertext attacks: It repeatedly chooses any Ct 6= Ct∗ and sends it over to C, to
which C returns Decap(Pk,Sk,Ct). Finally, A outputs µ′ and wins if µ′ = µ. We
define A’s advantage in the above security game as

Advind-ccaA,Π (λ) = |Pr[µ′ = µ]− 1/2|.

We say Π is IND-CCA-secure if Advind-ccaA,Π (Ν) is negligible in Ν.

2.2 Randomness Extraction

The statistical distance between two random variables X and Y over a finite
set S is SD(X,Y ) = 1

2

∑
s∈S |Pr[X = s]− Pr[Y = s]|. For any ε > 0, we say

X and Y are ε-close if SD(X,Y ) ≤ ε. The min-entropy of a random variable
X is H∞(X) = − log(maxs∈S Pr[X = s]). The average-case conditional min-
entropy of X given Y is H̃∞(X|Y ) = − log (Ey←Y [maxx Pr[X = x|Y = y]]). A
distribution (or a random variable) X is called k-source if H∞(X) ≥ k.

Lemma 2 ([9], Lemma 2.2). Let X, Y and Z be random variables where Z
has at most 2λ positive-probability values. Then H̃∞(X|Y,Z) ≥ H̃∞(X|Y ) − λ,
and in particular H̃∞(X|Z) ≥ H∞(X)− λ.

Definition 4. A collection of functions H = {h : D → R} is universal if for
any x1, x2 ∈ D such that x1 6= x2 it holds that PrH←H[H(x1) = H(x2)] = 1/|R|.

Lemma 3. Let X, Y be random variables such that X ∈ {0, 1}n, and H̃∞(X|Y ) ≥
k. Let H be a collection of universal hash functions from {0, 1}n to {0, 1}` where
` ≤ k − 2 log(1/ε). It holds that for h←$ H, and r ←$ {0, 1}`,

SD ((h, h(X), Y ), (h, r, Y )) ≤ ε



6

Lemma 4 ([1], Lemma 4). Suppose that m > (n+ 1) log q+ω(log n) and that
q > 2 is prime. Let R be an m×k matrix chosen uniformly in {1,−1}m×k mod q
where k = k(n) is polynomial in n. Let A and B be matrices chosen uniformly
in Zn×mq and Zn×kq respectively. Then the distribution (A,AR) is statistically
close to the distribution (A,B).

2.3 Computational Assumptions

We recall the LWE problem that was introduced by Regev [20].

Definition 5. Let Îť be the security parameter, n = n(Îť), m = m(Îť), q = q(Îť)
be integers and χ = χ(λ) be a distribution over Zq. The LWEn,m,q,χ problem asks
for distinguishing the following two distributions:

Real = (A, s>A + e>) and Rand = (A, c>)

where A ←$ Zn×mq , s ←$ Znq , e ← χm, and c ←$ Znq . We define the advantage
that an adversary A has in solving the LWE problem by

Adv
LWEn,m,q,χ
A (λ) = |Pr[A(1λ,Real) = 1]− Pr[A(1λ,Rand)]|.

We say the LWE assumption holds if for every p.p.t. algorithm A, Adv
LWEn,m,q,χ
A (Îť)

is negligible in Îť.

Usually, the distribution χ is the discrete Gaussian distribution DZ,αq where
the parameter α ∈ (0, 1) and αq ≥

√
n. We refer to [11] for details on discrete

Gaussian distributions and [17] for the recent result on the hardness of LWE.
In our construction, we consider the amortised LWE problem that asks to

distinguish between distributions (B,CB + F) and (B,A) where B ←$ Z`×mq ,

C←$ Zn×`q , F← χn×m and A← Zn×mq . It was shown, e.g., in [18] (Lemma 7.3),
that a p.p.t. algorithm that distinguishes the two distributions of the amortised
LWE problem with probability Îľ can be efficiently turned into a p.p.t. algorithm
that breaks the LWE`,m,q,χ problem (per Definition 5) with advantage ε/n.

We recall the following Lemma, first proven by Goldwasser et al. [12], and
used by Xie et al. [22]. It says that, for certain parameters, the LWE problem
remains hard even if the secret is chosen from an arbitrary distribution with
sufficient min-entropy in the presence of hard-to-invert auxiliary input.

Lemma 5. Let k ≥ log q and F = {f : {0, 1}n → {0, 1}∗} be a family of
one-way functions that are 2−k hard to invert with respect to distribution S
over {0, 1}n. For any super-polynomial q = q(Îť) and any m = poly(n), any
β, γ ∈ (0, 1) such that γ/β = negl(n), the distributions(

A, s>A + e>, f(s)
)

and
(
A, c>, f(s)

)
are computationally indistinguishable where A ←$ Zn×mq , s ← S, c ←$ Zmq ,

e← Dm
Z,βq, assuming the LWE`.m,q,DZ,γq assumption holds where ` ≥ k−ω(logn)

log q .



7

2.4 Lattice Trapdoors

Let n ≥ 1, q ≥ 2 and p ≤ q. Set k = dlog qe and w = nk, and define the n-by-w
gadget matrix G = In⊗ [1, 2, 4, ..., 2k−1] ∈ Zn×wq . We recall the following lemma
that applies the gadget trapdoor [15] to invert the LWE and LWR functions.
The lemma stems from Lemma 7.2 of [2] (the algorithm BigInvert). Here we
use the fact that the gadget matrix G has a (publicly known) trapdoor matrix
T ∈ Zw×w s.t. GT = 0 mod q and ‖T‖ ≤

√
5. (See [15], Proposition 4.2 for

details).

Lemma 6 ([3] Lemma 7.2). Let n ≥ 1, q ≥ 2, w = ndlog qe and m =
m̄ + w. Set , m̄ > (n + 1) log q + ω(log n). Let F = [A|AR + HG] where A ∈
Zn×m̄q , R ←$ {−1, 1}m̄×w and H ∈ Zn×nq be an invertible matrix. We have

for c> = bs>Fcp where s ∈ Znq , p ≥ O(m̄
√
n log q), there is a p.p.t algorithm

Invert(Transformq(c),F,H,R) that outputs s.

The following lemma is derived from Lemma 3.3 and Theorem 7.3 of [3].

Lemma 7. Let Îť be the security parameter. Let n,m, `, p, Îł be positive integers,
χ be a β-bounded distribution, w = ndlog qe, and q ≥ m̄βγn(m̄+w)p be a prime.
Then it holds that for s←$ Znq , A = CB + F ∈ Zn×m̄q , R←$ {−1, 1}m̄×w

H̃∞(s|
⌊
s>[A|AR]

⌋
p
) ≥ n log(2γ)− (`+ λ) log q

where B←$ Z`×m̄q , C←$ Zn×`q and F← χn×m̄.

3 The KEM Scheme

Let Îť be the security parameter. The scheme uses a full-rank difference encoding
function ϕ : Znq → Zn×nq which can be instatiated by the construction given by
Agrawal et al. [1]. The scheme also employs a family of hash functions F = {f :
Znq → {0, 1}λ} that is second pre-image resistant, and a family of universal hash

functions H = {h : Znq → {0, 1}λ} for which efficient constructions are known.
Let χ be a β-bounded distribution over Zq. Given the lattice dimension ` ≥ λ
for LWE problem, we set the parameters for our KEM scheme as follows.

– Let δ > 0 be a constant. Set the matrix dimension n large enough such that
n−4λ
nδ
≥ ` for Lemma 7 (ensuing that s sufficient leftover min-entropy).

– Set the matrix dimension m̄ = n1+δ to ensure that Lemma 4 applies. Here
we assume nδ = 2 log q.

– The rounding parameter p = 3m̄1.5 for Lemma 6.
– The parameter γ = 1 for Lemma 7
– Set β =

√
` as required by the hardness of LWE problem.

– The LWE modulus q = 12m̄5 that satisfies Lemma 7.

KeyGen(1Îť): On input the security parameter Îť, the key generation algorithm
does:



8

1. Choose A←$ Zn×m̄q , R←$ {−1, 1}m̄×w; Set A1 = AR mod q.
2. Randomly sample a hash function f ←$ F and a universal hash function
h←$ H.

3. Set Pk = (A,A1, f, h) and Sk = R.

Encap(Pk): On input the public key Pk, the encapsulation algorithm does:

1. Select s←$ Znq and compute t← f(s).

2. Encode t as a vector in Znq and compute c> =
⌊
s> · [A|A1 + ϕ(t)G]

⌋
p

3. Set K ← h(s) and Ct = (c, t).

Decap(Pk,Sk,Ct): On input the private key Sk and a ciphertext Ct = (c, t),
the decapsulation algorithm does:

1. Runs Invert(Transformq(c), [A|A1 + ϕ(t)G],R) to get s′ ∈ Znq .
2. Compute t′ = f(s′) and return ⊥ if t′ 6= t.
3. Return K ← h(s′).

The decryption correctness can be checked by the correctness of Invert as
stated in Lemma 6.

Theorem 1. If the family of hash functions F is second pre-image resistant and
the LWE`,m̄,q,χ assumption holds, then the KEM scheme is IND-CCA-secure.
More specifically, let Îť be the security parameter. Given a p.p.t adversary A
that breaks the KEM scheme Π with advantage Advind-ccaΠ,A (Ν), there exist a p.p.t
algorithm B1 that breaks the second pre-image resistance of F with advantage
AdvtcrF,B1

(λ) and a p.p.t algorithm B2 that breaks LWE`,m̄,q,χ with advantage

Adv
LWE`,m̄,q,χ
B2

(λ), such that Advind-ccaΠ,A (λ) ≤ AdvtcrF,B1
(Îť)+Adv

LWE`,m̄,q,χ
B2

(Îť)+negl(Îť)
where negl(Îť) is negligible in Îť.

Proof. We proceed with the proof as a sequence of games. For i = {0, 1, 2, 3, 4},
we denote the i-th game by Gamei. We denote by Gamei ⇒ 1 the event that
the adversary wins the security game, i.e., it outputs µ′ such that µ′ = µ.

The first game Game0 is the same as the IND-CCA security game. That
is, the adversary A receives a public key Pk = (A,A1, f, h) and a challenge
ciphertext Ct∗ = (c∗, t∗), where

t∗ = f(s∗) ; c∗> =
⌊
s∗> · [A|A1 + ϕ(t∗)G]

⌋
p

for some s∗ ←$ Znq , and a session key K∗µ, which is either a random value from

{0, 1}λ or h(s∗), from the challenger B. Then A adaptively issues decryption
queries Ct = (c, t) 6= Ct∗ and B runs the real decryption algorithm to return
the answers. Finally, A outputs a bit value µ′ indicating that Ct∗ encapsulates
a real session key or a random session key. According to the definition, we have

Pr[Game0 ⇒ 1] = Pr[µ′ = µ] = Advind-ccaΠ,A (λ) + 1/2

In Game1, we make a change in the way of answering decryption queries: ⊥
is returned if for the given decryption query Ct = (c, t), t = t∗; otherwise, Ct
is processed with the real decapsulation algorithm as in Game0. We argue that



9

unless the adversary breaks the second pre-image resistant property of the hash
function f , this change is not noticeable.

First of all, we must have c 6= c∗ (otherwise the decryption query is invalid as
it is the challenge ciphertext itself). To make the decryption oracle not to output
⊥, there must be a unique s 6= s∗ such that c> =

⌊
s> · [A|A1 + ϕ(t∗)G]

⌋
p

(and

such an s can be found by the algorithm Invert since the private key R is known).
Therefore we must have f(s) = f(s∗) = t∗ which makes s a valid second pre-
image for t∗. So, we have

|Pr[Game1 ⇒ 1]− Pr[Game0 ⇒ 1]| ≤ AdvtcrF,B1
(Îť)

for some proper adversary B1.
In Game2, we make the following changes on generating the matrix A1 from

the public key Pk. Firstly, we pick s∗ ←$ Znq and set t∗ = f(s∗). Then we
sample R ←$ {−1, 1}m̄×w and set A1 ← AR − ϕ(t∗)G mod q. s∗ is also used
to construct the challenge ciphertext:

t∗ ← f(s∗) ; c∗> ←
⌊
s∗> · [A|A1 + ϕ(t∗)G]

⌋
p

The decryption oracle is implemented as in Game1.
We argue that the adversary’s views in Game2 and Game1 are statistically

close. First, by Lemma 4, the distributions of A1 in these two games are statis-
tically close. This means that Pk generated in these two games are statistically
indistinguishable for A. Then we note that the decryption queries will be an-
swered properly. This is because by the standard technique of Agrawal et al.
[1], knowledge of the binary matrix R lets us transform the trapdoor for G into
a trapdoor for the whole matrix, as long as H is invertible. The simulator can
thus answer in the same way as the previous games, except for the ciphertexts
Ct = (c, t∗), which however, are already excluded:

[A|A1 + ϕ(t)G] = [A|AR + (ϕ(t)− ϕ(t∗))G]

= [A|AR + HG]

where, by the property of FRD, H ∈ Zn×nq is invertible. So we have

|Pr[Game2 ⇒ 1]− Pr[Game1 ⇒ 1]| ≤ negl1(λ)

for some negligible statistical error negl1(Îť).
In Game3 we change the way that the matrix A is constructed. In particular,

we obtain A ← CB + F where B ←$ Z`×m̄q , C ←$ Zn×`q and F ← χn×m̄. By
the LWE assumption (amortised version) we immediately have

Pr[Game3 ⇒ 1]− Pr[Game2 ⇒ 1] ≤ Adv
LWE`,m̄,q,χ
B2

(Îť)

for some proper adversary B2.
In Game4, we change the way of generating the challenge session key. In par-

ticular, K∗1 is chosen randomly from {0, 1}λ (recall that K∗0 is chosen uniformly



10

random from {0, 1}Îť in all previous games). We argue that Game3 and Game4

are statistically indistinguishable. First of all, t∗ in the challenge ciphertext has
at most 2λ values. Second, by the construction of the matrix A and c∗, we have

c∗> =
⌊
s∗> · [A|A1 + ϕ(t∗)G]

⌋
p

=
⌊
s∗> · [A|AR + (ϕ(t∗)− ϕ(t∗))G]

⌋
p

=
⌊
s∗> · [A|AR]

⌋
p

By Lemma 2,

H̃∞ (s∗|c∗, t∗) ≥ H̃∞ (s∗|c∗)− λ
≥ n log(2γ)− (λ+ `) log q − λ
≥ n− 2` log q − λ
= n− ` · nδ − λ
≥ 4λ− λ
= 3Îť

Let ε = 2−λ. So, we have H̃∞ (s∗|c∗, t∗) ≥ 2 log(1/ε) + λ. Applying Lemma 3
results in SD ((c∗, t∗, h, h(s∗), (c∗, t∗, h,K∗1 )) ≤ ε = 2−λ where K∗1 ← {0, 1}λ.
We therefore obtain

|Pr[Game4 ⇒ 1]− Pr[Game3 ⇒ 1]| ≤ 2−λ

Additionally, In Game4, K∗0 and K∗1 are all random strings chosen from {0, 1}λ.
So the adversary A has exactly probability 1/2 of correctly guessing Âľ, i.e.,

Pr[Game4 ⇒ 1] = 1/2

Combining the above steps gives us

Advind-ccaΠ,A (λ) ≤ AdvtcrF,B1
(Îť) + Adv

LWE`,m̄,q,χ
B2

(Îť) + negl(Îť)

where negl(λ) = negl1(λ) + 2−λ is negligible. This completes the proof. ut

4 CCA-Secure Deterministic Public-Key Encryption

In this section, we show a construction of CCA-secure deterministic public-key
encryption (D-PKE) in the standard model. Deterministic public-key encryption
only makes sense for high-min-entropy plaintexts, to preclude the obvious guess-
and-encrypt attack, but for such messages it has practical applications ranging
from encrypted keyword search to encrypted cloud storage with deduplication.

Our CCA-secure D-PKE has a similar structure as our KEM. We consider
the so-called PRIV-CCA security notion for single hard-to-guess message as in



11

[4]. 4 The security of our construction is again based on the hardness of the
LWE problem with high-min-entropy secret in the presence of hard-to-invert
auxiliary inputs, which is as hard as the standard form of LWE with certain
parameters [12]. Our construction is more efficient than the generic constructions
by Boldyreva et al. [4] which requires double encryption (e.g., using two lossy
trapdoor functions when instantiated with lattice-based primitives).

A D-PKE scheme consists of three algorithms. On input a security parameter
1Îť, the randomised key generation algorithm KeyGen(1Îť) outputs a pair of public
and private keys (Pk,Sk). The deterministic encryption algorithm Enc(Pk,m) re-
turns a ciphertext Ct. The decryption algorithm Dec(Pk,Sk,Ct) returns the mes-
sage m or ⊥. The correctness is required that for all m, (Pk,Sk)← KeyGen(1λ),

Pr[Dec(Pk,Sk,Enc(Pk,m)) = m] ≥ 1− negl(λ).

We recall the indistinguishability-based security definition of D-PKE for sin-
gle high-min-entropy messages. Here we consider a stronger version where we
require ciphertext pseudorandomness, i.e., that ciphertexts be computationally
indistinguishable from random stings. The security game with a D-PKE scheme
Π is defined as follows. The adversary A outputs a distribution M over the
message space. where H∞(M) ≥ k (i.e., M is a k-source). The challenger B
runs (Pk,Sk) ← KeyGen(1λ). It flips a coin µ ←$ {0, 1}. If µ = 0 it computes
Ct∗ ← Enc(Pk,m∗) where m∗ ← M . Otherwise it chooses Ct∗ uniformly at
random from the ciphertext space. B returns (Pk,Ct∗) to A. A then launches
adaptive decryption queries Ct 6= Ct∗ to which B returns Dec(Pk,Sk,Ct). Finally,
A outputs µ′ and wins if µ′ = µ. We define A’s advantage in the security game
as

Advpriv1-ccaΠ,A (λ) = |Pr[µ′ = µ]− 1/2|.

We say a D-PKE scheme Π is PRIV-CCA-secure w.r.t. a k-source single message
if for every p.p.t. adversary A, the advantage is negligible in Îť.

Construction. Our construction uses a full-rank difference encoding function
ϕ : Znq → Zn×nq as in our construction of KEM. The construction also uses a

family of second pre-image resistant functions F = {f : {0, 1}n → {0, 1}2λ} that
is universal and 2−k-hard-to-invert with respect to a k-source M over {0, 1}n.
Such a family of functions can be built from the standard Short Integer Solution
(SIS) problem.

The security of the construction is based on the hardness of LWE`,q,m̄,DZ,γq

where we need, for Lemma 5, ` ≥ k−ω(logn)
log q , γ ∈ (0, 1) such that γ/β = negl(n).

We set the parameters for decryption correctness and security as follows.

– Set the LWE modulus q = nω(1) and parameter β =
√
`/q for the LWE

hardness results of, e.g. [20,17].
– Set the dimension m̄ = n1+δ where nδ = O(log q) for Lemma 4.

4 It was shown in [4] that such a security notion is equevalent to the PRIV-CCA
security notion for multiple messages that form a block source. See [4] for details.



12

– The rounding parameter p = 3m̄1.5, to ensure that Lemma 6 applies.
– Finally, β = 1/(2p

√
nm̄) · n−ω(1) for applying Lemma 1.

KeyGen(1Îť): On input the security parameter Îť, the algorithm does:

1. Choose A←$ Zn×m̄q , R←$ {−1, 1}m̄×w; Set A1 = AR mod q.

2. Sample a universal, second pre-image resistant, 2k-hard-to-invert hash
function f ←$ F .

3. Set Pk = (A,A1, f) and Sk = R.

Enc(Pk,m): On input the public key Pk and message m ∈ {0, 1}n which comes
from some k-source, the algorithm does:

1. Compute t← f(m) and encode t as a vector in Znq .

2. Compute c> =
⌊
m> · [A|A1 + ϕ(t)G]

⌋
p

3. Set Ct = (c, t).

Dec(Sk,Ct): On input the private key Sk and a ciphertext Ct = (c, t), the
decryption algorithm does:

1. Runs Invert(Transformq(c), [A|A1 + ϕ(t)G],R) to get m′ ∈ {0, 1}n.
2. Compute t′ = f(m′). Return m′ if t′ = t or return ⊥ otherwise.

Security Proof. Now we give the security proof.

Theorem 2. Let k ≥ 2 log(1/n−ω(1)) + λ. If the family of functions F is uni-
versal, 2−k-hard-to-invert, second pre-image resistant, and Lemma 5 holds, the
above construction of D-PKE scheme is PRIV-CCA-secure for k-source single
message.

Proof. We proceed the proof by a sequence of games. For i = {0, 1, 2, 3, 4}, we
denote the i-th game by Gamei. We denote by Gamei ⇒ 1 the event that the
adversary wins the security game, i.e., it outputs µ′ such that µ′ = µ.

The first game Game0 is the original PRIV-CCA security game. That is,
the adversary A generates a k-source distribution M . The challenger samples a
challenge message m∗ ←M and a fair coin µ←$ {0, 1}. It then returns the public
key (A,A1, f) and the challnege ciphertext Ct∗µ to A, where Ct∗0 ← Enc(Pk,m∗)
and Ct∗1 is uniformly chosen from the ciphertext space. A then launches adaptive
chosen-ciphertext queries Ct subject to the condition that Ct 6= Ct∗. Finally, A
outputs µ′ and it wins if µ′ = µ. By definition we have

|Pr[Game0 ⇒ 1]− 1/2| = Advpriv1-ccaΠ,A (λ).

In the second game Game1, we slightly change the way of answering the
decryption query: Let the challenge ciphertext Ct∗µ = (c∗, t∗). A decryption
query Ct = (c, t) is rejected if t = t∗. First, we must have Ct 6= Ct∗µ by se-

curity definition. Second, if c 6= c∗, there is a m′ ∈ {0, 1}n such that c> =⌊
m′>[A|A1 + ϕ(t∗)]

⌋
p
. (In the case that Ct∗0 was returned, we must have m′ 6=

m∗.) Therefore, m′ is a valid second pre-image of t∗ on f , and m′ can be re-
covered efficiently through the decryption procedure. So a p.p.t distinguisher



13

between Game0 and Game1 leads to a second-pre-image inversion algorithm for
F and we have

|Pr[Game1 ⇒ 1]− Pr[Game0 ⇒ 1]| ≤ negl1(λ).

In Game2 we set A1 ← AR − ϕ(t∗)G. By making this change we have
challenge ciphertext Ct∗0 = (t∗ = f(m∗), c∗T = bm∗>[A|AR]cp). By Lemma 4,
A1 is distributed properly except for a negligible statistical error negl1Îť. So we
have

|Pr[Game2 ⇒ 1]− Pr[Game1 ⇒ 1]| ≤ negl2(λ).

In Game3, we make changes on computing the challenge ciphertext Ct∗0.
Specifically, given the challenge message m∗ ← M , we sample e ← Dm̄

Z,βq and
compute

c∗> =
⌊
m∗>[A|A1 + ϕ(t∗)G] + [e>|e>R]

⌋
p

=
⌊
m∗>[A|AR] + [e>|e>R]

⌋
p

where R is chosen as in the key generation phase. Since m∗ is a sample from the
distribution M which is chosen independent of A and AR, so m∗>[A|AR] is a
random sample from the uniform distribution over Zm̄+w

q (Recall A is randomly
chosen and AR statistically close to uniform as per Lemma 4). By Lemma 1 and
the fact that ‖e>R‖∞ ≤ βq

√
nm̄, with all but negligible probability negl3(λ),

c∗> =
⌊
m∗>[A|AR]

⌋
p

as produced in Game2. This shows that

|Pr[Game3 ⇒ 1]− Pr[Game2 ⇒ 1]| ≤ negl3(λ).

In Game4, we set Ct∗0 = (t∗ = f(m∗), c∗ = b[b>|b>R]cp where b ←$ Zm̄q
and m∗ ← M . by Lemma 5, the distributions (A";"""date"",""2020-04-14T04:02:06Z""
""pdf:PDFVersion"",""1.5""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:docinfo:title"",""""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""xmp:CreateDate"",""2020-04-07T10:29:14Z""
""modified"",""2020-04-14T04:02:06Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""xmp:ModifyDate"",""2020-04-14T14:02:06Z""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.16 (TeX Live 2015) kpathsea version 6.2.1""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2020-04-07T00:29:14Z""
""created"",""2020-04-07T00:29:14Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-04-07T00:29:14Z""
""resourceName"",""Li301788-Accepted.pdf""
""Author"",""""
""producer"",""pdfTeX-1.40.16""
""pdf:docinfo:producer"",""pdfTeX-1.40.16""
""pdf:unmappedUnicodeCharsPerPage"",""6"",""9"",""0"",""23"",""14"",""17"",""22"",""23"",""13"",""19"",""7"",""26"",""53"",""7"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2020-04-07T00:29:14Z""
""Last-Modified"",""2020-04-14T04:02:06Z""
""dcterms:modified"",""2020-04-14T04:02:06Z""
""title"",""""
""xmpMM:DocumentID"",""uuid:f482e0a7-9ecb-4c04-993c-6c0edb7c93dd""
""Last-Save-Date"",""2020-04-14T04:02:06Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2020-04-14T04:02:06Z""
""meta:save-date"",""2020-04-14T04:02:06Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.16 (TeX Live 2015) kpathsea version 6.2.1""
""Content-Length"",""372233""
""Content-Type"",""application/pdf""
""xmp:MetadataDate"",""2020-04-14T14:02:06Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""pdf:producer"",""pdfTeX-1.40.16""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""15""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""1987"",""2551"",""2504"",""2062"",""1976"",""1981"",""1813"",""1988"",""1880"",""1323"",""2402"",""1988"",""1468"",""2335"",""2263""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-04-07T00:29:14Z""
";https://scholar.google.com/scholar?start=630&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094586-850;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Public-key cryptography in the fine-grained setting;R LaVigne, A Lincoln, VV Williams ; Annual International Cryptology …, 2019  Springer;;"… CRYPTO 2019: Advances in Cryptology – CRYPTO 2019 pp 605-635 | Cite as … Where previous

works had to assume random oracles or the existence of strong one-way functions to get a … Merkle

puzzles by making an assumption of the existence of either a random oracle or an …";Cité 8 fois;Les 3 versions;[PDF] nsf.gov;https://par.nsf.gov/servlets/purl/10178933;"
Public-Key Cryptography
in the Fine-Grained Setting

Rio LaVigne(B), Andrea Lincoln(B), and Virginia Vassilevska Williams

MIT CSAIL and EECS, Cambridge, USA
{rio,andreali,virgi}@mit.edu

Abstract. Cryptography is largely based on unproven assumptions,
which, while believable, might fail. Notably if P = NP , or if we live
in Pessiland, then all current cryptographic assumptions will be broken.
A compelling question is if any interesting cryptography might exist in
Pessiland.

A natural approach to tackle this question is to base cryptography
on an assumption from fine-grained complexity. Ball, Rosen, Sabin, and
Vasudevan [BRSV’17] attempted this, starting from popular hardness
assumptions, such as the Orthogonal Vectors (OV) Conjecture. They
obtained problems that are hard on average, assuming that OV and
other problems are hard in the worst case. They obtained proofs of work,
and hoped to use their average-case hard problems to build a fine-grained
one-way function. Unfortunately, they proved that constructing one using
their approach would violate a popular hardness hypothesis. This moti-
vates the search for other fine-grained average-case hard problems.

The main goal of this paper is to identify sufficient properties for
a fine-grained average-case assumption that imply cryptographic prim-
itives such as fine-grained public key cryptography (PKC). Our main
contribution is a novel construction of a cryptographic key exchange,
together with the definition of a small number of relatively weak struc-
tural properties, such that if a computational problem satisfies them, our
key exchange has provable fine-grained security guarantees, based on the
hardness of this problem. We then show that a natural and plausible
average-case assumption for the key problem Zero-k-Clique from fine-
grained complexity satisfies our properties. We also develop fine-grained
one-way functions and hardcore bits even under these weaker assump-
tions.

R. LaVigne—This material is based upon work supported by the National Science
Foundation Graduate Research Fellowship under Grant No. 1122374. Any opinion,
findings, and conclusions or recommendations expressed in this material are those of the
authors(s) and do not necessarily reflect the views of the National Science Foundation.
Research also supported in part by NSF Grants CNS-1350619 and CNS-1414119, and
by the Defense Advanced Research Projects Agency (DARPA) and the U.S. Army
Research Office under contracts W911NF-15-C-0226 and W911NF-15-C-0236.
A. Lincoln—This work supported in part by NSF Grants CCF-1417238, CCF-1528078
and CCF-1514339, and BSF Grant BSF:2012338.
V. Williams—Partially supported by an NSF Career Award, a Sloan Fellowship, NSF
Grants CCF-1417238, CCF-1528078 and CCF-1514339, and BSF Grant BSF:2012338.

cŠ International Association for Cryptologic Research 2019
A. Boldyreva and D. Micciancio (Eds.): CRYPTO 2019, LNCS 11694, pp. 605–635, 2019.
https://doi.org/10.1007/978-3-030-26954-8_20

http://crossmark.crossref.org/dialog/?doi=10.1007/978-3-030-26954-8_20&domain=pdf
https://doi.org/10.1007/978-3-030-26954-8_20


606 R. LaVigne et al.

Where previous works had to assume random oracles or the existence
of strong one-way functions to get a key-exchange computable in O(n)
time secure against O(n2) adversaries (see [Merkle’78] and [BGI’08]),
our assumptions seem much weaker. Our key exchange has a similar gap
between the computation of the honest party and the adversary as prior
work, while being non-interactive, implying fine-grained PKC.

1 Introduction

Modern cryptography has developed a variety of important cryptographic prim-
itives, from One-Way Functions (OWFs) to Public-Key Cryptography to Obfus-
cation. Except for a few more limited information theoretic results [20,50,51],
cryptography has so far required making a computational assumption, P ďż˝= NP
being a baseline requirement. Barring unprecedented progress in computational
complexity, such hardness hypotheses seem necessary in order to obtain most
useful primitives. To alleviate this reliance on unproven assumptions, it is good
to build cryptography from a variety of extremely different, believable assump-
tions: if a technique disproves one hypothesis, the unrelated ones might still hold.
Due to this, there are many different cryptographic assumptions: on factoring,
discrete logarithm, shortest vector in lattices and many more.

Unfortunately, almost all hardness assumptions used so far have the same
quite stringent requirements: not only that NP is not in BPP, but that we
must be able to efficiently sample polynomially-hard instances whose solution
we know. Impagliazzo [31,47] defined five worlds, which capture the state of
cryptography, depending on which assumptions happen to fail. The three worlds
worst for cryptography are Algorithmica (NP in BPP), Heuristica (NP is not
in BPP but NP problems are easy on average) and Pessiland (there are NP
problems that are hard on average but solved hard instances are hard to sample,
and OWFs do not exist). This brings us to our main question.

Can we have a meaningful notion of cryptography even if we live in Pessiland
(or Algorithmica or Heuristica)?

This question motivates a weaker notion of cryptography: cryptography that
is secure against nk-time bounded adversaries, for a constant k. Let us see why
such cryptography might exist even if P = NP. In complexity, for most interesting
computational models, we have time hierarchy theorems that say that there are
problems solvable in O(n2) time (say) that cannot be solved in O(n2−ε) time for
any Îľ > 0 [28,30,53]. In fact, such theorems exist also for the average case time
complexity of problems [39]. Thus, even if P = NP, there are problems that are
hard on average for specific runtimes, i.e. fine-grained hard on average. Can we
use such hard problems to build useful cryptographic primitives?

Unfortunately, the problems from the time hierarchy theorems are difficult
to work with, a common problem in the search for unconditional results. Thus,
let us relax our requirements and consider hardness assumptions, but this time
on the exact running time of our problems of interest. One simple approach is



Public-Key Cryptography in the Fine-Grained Setting 607

to consider all known constructions of Public Key Cryptography (PKC) to date
and see what they imply if the hardness of the underlying problem is relaxed to
be nk−o(1) for a fixed k (as it would be in Pessiland). Some of the known schemes
are extremely efficient. For instance, the RSA and Diffie-Hellman cryptosystems
immediately imply weak PKC if one changes their assumptions to be about poly-
nomial hardness [23,49]. However, these cryptosystems have other weaknesses
– for instance, they are completely broken in a postquantum world as Shor’s
algorithm breaks their assumptions in essentially quadratic time [52]. Thus, it
makes sense to look at the cryptosystems based on other assumptions. Unfor-
tunately, largely because cryptography has mostly focused on the gap between
polynomial and superpolynomial time, most reductions building PKC have a
significant (though polynomial) overhead; many require, for example, multiple
rounds of Gaussian elimination. As a simple example, the Goldreich-Levin con-
struction for hard-core bits uses nω (where ω ∈ [2, 2.373) is the exponent of
square matrix multiplication [26,55]) time and n calls to the hard-core-bit dis-
tinguisher [27]. The polynomial overhead of such reductions means that if the
relevant problem is only n2−o(1) hard, instead of super-polynomially hard, the
reduction will not work anymore and won’t produce a meaningful cryptographic
primitive. Moreover, reductions with fixed polynomial overheads are no longer
composable in the same way when we consider weaker, polynomial gap cryptog-
raphy. Thus, new, more careful cryptographic reductions are needed.

Ball et al. [6,7] began to address this issue through the lens of the recently
blossoming field of fine-grained complexity. Fine-grained complexity is built upon
“fine-grained” hypotheses on the (worst-case) hardness of a small number of
key problems. Each of these key problems K, has a simple algorithm using
a combination of textbook techniques, running in time T (n) on instances of
size n, in, say, the RAM model of computation. However, despite decades of
research, no Õ(T (n)1−ε) algorithm is known for any ε > 0 (note that the tilde
∟ suppresses sub-polynomial factors). The fine-grained hypothesis for K is then
that K requires T (n)1−o(1) time in the RAM model of computation. Some of the
main hypotheses in fine-grained complexity (see [54]) set K to be CNF-SAT (with
T (n) = 2n, where n is the number of variables), or the k-Sum problem (with
T (n) = n�k/2�), or the All-Pairs Shortest Paths problem (with T (n) = n3 where
n is the number of vertices), or one of several versions of the k-Clique problem in
weighted graphs. Fine-grained complexity uses fine-grained reductions between
problems in a very tight way (see [54]): if problem A has requires running time
a(n)1−o(1), and one obtains an (a(n), b(n))-fine-grained reduction from A to B,
then problem B needs runtime b(n)1−o(1). Using such reductions, one can obtain
strong lower bounds for many problems, conditioned on one of the few key
hypotheses.

The main question that Ball et al. set out to answer is: Can one use fine-
grained reductions from the hard problems from fine-grained complexity to build
useful cryptographic primitives? Their work produced worst-case to average-case
fine-grained reductions from key problems to new algebraic average case prob-
lems. From these new problems, Ball et al. were able to construct fine-grained



608 R. LaVigne et al.

proofs of work, but they were not able to obtain stronger cryptographic prim-
itives such as fine-grained one-way-functions or public key encryption. In fact,
they gave a barrier for their approach: extending their approach would falsify the
Nondeterministic Strong Exponential Time Hypothesis (NSETH) of Carmosino
et al. [18]. Because of this barrier, one would either need to develop brand new
techniques, or use a different hardness assumption.

What kind of hardness assumptions can be used to obtain public-key
cryptography (PKC) even in Pessiland?

A great type of theorem to address this would be: for every problem P that
requires nk−o(1) time on average, one can construct a public-key exchange (say),
for which Alice and Bob can exchange a lg(n) bit key in time O(nak), whereas
Eve must take n(a+g)k−o(1) time to learn Alice and Bob’s key, where g is large,
and a is small. As a byproduct of such a theorem, one can obtain not just OWFs,
but even PKC in Pessiland under fine-grained assumptions via the results of Ball
et al. Of course, due to the limitations given by Ball et al. such an ideal theorem
would have to refute NSETH, and hence would be at the very least difficult to
prove. Thus, let us relax our goal, and ask

What properties are sufficient for a fine-grained average-case assumption so
that it implies fine-grained PKC?

If we could at least resolve this question, then we could focus our search for
worst-case to average-case reductions in a useful way.

1.1 Our Contributions

Our main result is a fine-grained key-exchange that can be formed from any
problem that meets three structural conditions in the word-RAM model of com-
putation. This addresses the question of what properties are sufficient to produce
fine-grained Public Key Encryption schemes (PKEs).

For our key exchange, we describe a set of properties, and any problem that
has those properties implies a polynomial gap PKE. An informal statement of
our main theorem is as follows.

Theorem [Fine-Grained Key-Exchange (informal)]. Let P be a computational
problem for which a random instance can be generated in O(ng) time for some g,
and that requires nk−o(1) time to be solved on average for some fixed k > g. Addi-
tionally, let P have three key structural properties of interest: (1) “plantable”:
we can generate a random-looking instance, choosing either to have or not to
have a solution in the instance, and if there is a solution, we know what/where it
is; (2) “average-case list-hard”: given a list of n random instances of the problem,
returning which one of the instances has a solution requires essentially solving all
instances; (3) “splittable”: when given an instance with a solution, we can split
it in O(ng) time into two slightly smaller instances that both have solutions.

Then a public key-exchange can be built such that Alice and Bob exchange
a lg(n) bit key in time n2k−g, where as Eve must take Ω̃(n3k−2g) time to learn
Alice and Bob’s key.



Public-Key Cryptography in the Fine-Grained Setting 609

Notice that as long as there is a gap between the time to generate a random
instance and the time to solve an instance on average, there is a gap between
N = n2k−g and n3k−2g = N3/2−1/(4(k/g)−2) and the latter goes to N3/2, as k/g
grows. The key exchange requires no interaction, and we get a fine-grained public
key cryptosystem. While our key exchange construction provides a relatively
small gap between the adversary and the honest parties (O(N1.5) vs O(N)), the
techniques required to prove security of this scheme are novel and the result is
generic as long as the three assumptions are satisfied. In fact, we will show an
alternate method to achieve a gap approaching O(N2) in the full version of this
paper.

Our main result above is stated formally and in more generality in Theorem5.
We will explain the formal meaning of our structural properties plantable, average-
case list-hard, and splittable later.

We also investigate what plausible average-case assumptions one might be
able to make about the key problems from fine-grained complexity so that the
three properties from our theorem would be satisfied. We consider the Zero-k-
Clique problem as it is one of the hardest worst-case problems in fine-grained
complexity. For instance, it is known that if Zero-3-Clique is in O(n3−ε) time for
some Îľ > 0, then both the 3-Sum and the APSP hypotheses are violated [54,57].
It is important to note that while fine-grained problems like Zero-k-Clique and
k-Sum are suspected to take a certain amount of time in the worst case, when
making these assumptions for any constant k does not seem to imply P ďż˝= NP
since all of these problems are still solvable in polynomial time.1

An instance of Zero-k-Clique is a complete k-partite graph G, where each
edge is given a weight in the range [0, R − 1] for some integer R. The problem
asks whether there is a k-clique in G whose edge weights sum to 0, modulo R.
A standard fine-grained assumption (see e.g. [54]) is that in the worst case, for
large enough R, say R ≥ 10n4k, Zero-k-Clique requires nk−o(1) time to solve.
Zero-k-Clique has no non-trivial average-case algorithms for natural distribu-
tions (uniform for a range of parameters, similar to k-Sum and Subset Sum).
Thus, Zero-k-Clique is a natural candidate for an average-case fine-grained hard
problem.

Our other contribution addresses an open question from Ball et al.: can a fine-
grained one-way function be constructed from worst case assumptions? While
we do not fully achieve this, we generate new plausible average-case assumptions
from fine-grained problems that imply fine-grained one-way functions.

1.2 Previous Works

There has been much prior work leading up to our results. First, there are a few
results using assumptions from fine-grained complexity and applying them to
cryptography. Second, there has been work with the kind of assumptions that
we will be using.

1 Assuming the hardness of these problems for more general k will imply P ďż˝= NP ,
but that is not the focus of our work.



610 R. LaVigne et al.

Fine-Grained Cryptography. Ball et al. [6,7] produce fine-grained wost-case
to average-case reductions. Ball et al. leave an open problem of producing a one-
way-function from a worst case assumption. They prove that from some fine-
grained assumptions building a one-way-function would falsify NSETH [6,18].
We avoid their barrier in this paper by producing a construction of both fine-
grained OWFs and fine-grained PKE from an average-case assumption.

Fine-Grained Key Exchanges. Fine-grained cryptography is a relatively unex-
plored area, even though it had its start in the 1970’s with Merkle puzzles: the
gap between honestly participating in the protocol versus breaking the security
guarantee was only quadratic [43]. Merkle originally did not describe a plausi-
ble hardness assumption under which the security of the key exchange can be
based. 30 years later, Biham, Goren, and Ishai showed how to implement Merkle
puzzles by making an assumption of the existence of either a random oracle or
an exponential gap one way function [16]. That is, Merkle puzzles were built
under the assumption that a one-way function exists which takes time 2n(1/2+δ)

to invert for some δ > 0. So while prior work indeed succeeded in building a fine-
grained key-exchange, it needed a very strong variant of OWFs to exist. It is
thus very interesting to obtain fine-grained public key encryption schemes based
on a fine-grained assumption (that might even work in Pessiland and below).

Another Notion of Fine-Grained Cryptography. In 2016, work by Degwekar,
Vaikuntanathan, and Vasudevan [22] discussed fine-grained complexity with
respect to both honest parties and adversaries restricted to certain circuit classes.
They obtained constructions for some cryptographic primitives (including PKE)
when restricting an adversary to a certain circuit class. From the assumption
NC1 �= ⊕L/poly they show Alice and Bob can be in AC0[2] while being secure
against NC1 adversaries. While [22] obtains some unconditional constructions,
their security relies on the circuit complexity of the adversary, and does not
apply to arbitrary time-bounded adversaries as is usually the case in cryptogra-
phy. That is, this restricts the types of algorithms an adversary is allowed to use
beyond just how much runtime these algorithms can have. It would be interest-
ing to get similar results in the low-polynomial time regime, without restricting
an adversary to a certain circuit class. Our results achieve this, though not
unconditionally.

Tight Security Reductions and Fine-Grained Crypto. Another area the world
of fine-grained cryptography collides with is that of tight security reductions
in cryptography. Bellare et.al. coined the term “concrete” security reductions
in [12,14]. Concrete security reductions are parametrized by time (t), queries (q),
size (s), and success probability (Îľ). This line of work tracks how a reduction
from a problem to a construction of some cryptographic primitive effects the
four parameters of interest. This started a rich field of study connecting theory
to practical cryptographic primitives (such as PRFs, different instantiations of
symmetric encryption, and even IBE for example [10,11,15,36]). In fine-grained
reductions we also need to track exactly how our adversary’s advantage changes



Public-Key Cryptography in the Fine-Grained Setting 611

throughout our reductions, however, we also track the running time of the honest
parties. So, unlike in the concrete security literature, when the hard problems are
polynomially hard (perhaps because P = NP ), we can track the gap in running
times between the honest and dishonest parties. This allows us to build one way
functions and public key cryptosystems when the hard problems we are given
are only polynomially hard (Fig. 1).

Fig. 1. A table of previous works’ results in this area. There have been several results
characterizing different aspects of fine-grained cryptography. *It was [16] who showed
that Merkle’s construction could be realized with a random oracle. However, Merkle
presented the construction.

Similar Assumptions. This paper uses hypotheses on the running times of
problems that, while solvable in polynomial time, are variants of natural NP-
hard problems, in which the size of the solution is a fixed constant. For instance,
k-Sum is the variant of Subset Sum, where we are given n numbers and we need
to find exactly k elements that sum to a given target, and Zero-k-Clique is the
variant of Zero-Clique, in which we are given a graph and we need to find exactly
k nodes that form a clique whose edge weights sum to zero.

With respect to Subset Sum, Impagliazzo and Naor showed how to directly
obtain OWFs and PRGs assuming that Subset Sum is hard on average [32]. The
OWF is f(a, s) = (a,a ¡ s), where a is the list of elements (chosen uniformly at
random from the range R) and s ∈ {0, 1}n represents the set of elements we add
together. In addition to Subset Sum, OWFs have also been constructed from
planted Clique, SAT, and Learning-Parity with Noise [34,41]. The constructions



612 R. LaVigne et al.

from the book of Lindell and the chapter written by Barak [41] come from a
definition of a “plantable” NP-hard problem that is assumed to be hard on
average.

Although our OWFs are equivalent to scaled-down, polynomial-time solvable
characterizations of these problems, we also formalize the property that allows us
to get these fine-grained OWFs (plantability). We combine these NP construc-
tions and formalizations to lay the groundwork for fine-grained cryptography.

In the public-key setting, there has been relatively recent work taking NP-
hard problems and directly constructing public-key cryptosystems [4]. They take
a problem that is NP-hard in its worst case and come up with an average-case
assumption that works well for their constructions. Our approach is similar, and
we also provide evidence for why our assumptions are correct.

In recent work, Subset Sum was also shown to directly imply public-key cryp-
tography [42]. The construction takes ideas from Regev’s LWE construction [48],
turning a vector of subset sum elements into a matrix by writing each element
out base q in a column. The subset is still represented by a 0–1 matrix, and error
is handled by the lack of carrying digits. It is not clear how to directly translate
this construction into the fine-grained world. First, directly converting from Sub-
set Sum to k-Sum just significantly weakens the security without added benefit.
More importantly, the security reduction has significant polynomial overhead,
and would not apply in a very pessimistic Pessiland where random planted Sub-
set Sum instances can be solved in quadratic time, say.

While it would be interesting to reanalyze the time-complexity of this con-
struction (and others) in a fine-grained way, this is not the focus of our work.
Our goal is to obtain novel cryptographic approaches exploiting the fine-grained
nature of the problems, going beyond just recasting normal cryptography in the
fine-grained world, and obtaining somewhat generic constructions.

1.3 Technical Overview

Here we will go into a bit more technical detail in describing our results. First,
we need to describe our hardness assumptions. Then, we will show how to use
them for our fine-grained key exchange, and finally, we will talk briefly about
fine-grained OWFs and hardcore bits.

Our Hardness Assumption. We generate a series of properties where if a problem
has these properties then a fine-grained public key-exchange can be built.

One property we require is that the problem is hard on average, in a fine-
grained sense. Intuitively, a problem is average case indistinguishably hard if
given an instance that is drawn with probability 1/2 from instances with no
solutions and with probability 1/2 from instances with one solution, it is com-
putationally hard on average to distinguish whether the instance has 0 or 1
solutions. The rest of the properties are structural; we need a problem that is
plantable, average-case list-hard, and splittable. Informally,



Public-Key Cryptography in the Fine-Grained Setting 613

– The plantable property roughly says that one can efficiently choose to gen-
erate either an instance without a solution or one with a solution, knowing
where the solution is;

– The average case list-hard property says that if one is given a list of instances
where all but one of them are drawn uniformly over instances with no solu-
tions, and a random one of them is actually drawn uniformly from instances
with one solution, then it is computationally hard to find the instance with
a solution;

– Finally, the splittable property says that one can generate from one average
case instance, two new average case instances that have the same number of
solutions as the original one.

These are natural properties for problems and hypotheses to have. We will
demonstrate in the full version Zero-k-Clique has all of these properties. We
need our problem to have all three of these qualities for the key exchange. For
our one-way function constructions we only need the problem to be plantable.

The structural properties are quite generic, and in principle, there could be
many problems that satisfy them. We exhibit one: the Zero-k-Clique problem.

Because no known algorithmic techniques seem to solve Zero-k-Clique even
when the weights are selected independently uniformly at random from [0, cnk]
for a constant c, folklore intuition dictates that the problem might be hard on
average for this distribution: here, the expected number of k-Cliques is Θ(1), and
solving the decision problem correctly on a large enough fraction of the random
instances seems difficult. This intuition was formally proposed by Pettie [46] for
the very related k-Sum problem which we also consider.

We show that the Zero-k-Clique problem, together with the assumption that
it is fine-grained hard to solve on average, satisfies all of our structural properties,
and thus, using our main theorem, one can obtain a fine-grained key exchange
based on Zero-k-Clique.

Key Exchange Assumption. We assume that when given a complete k-partite
graph with kn nodes and random weights [0, R − 1], R = Ω(nk), any adversary
running in time nk−Ω(1) time cannot distinguish an instance with a zero-k-
clique solution from one without with more than 2/3 chance of success. In more
detail, consider a distribution where with probability 1/2 one generates a ran-
dom instance of size n with no solutions, and with probability 1/2 one generates
a random instance of size n with exactly one solution. (We later tie in this dis-
tribution to our original uniform distribution.) Then, consider an algorithm that
can determine with probability 2/3 (over the distribution of instances) whether
the problem has a solution or not. We make the conjecture that such a 2/3-
probability distinguishing algorithm for Zero-k-Clique, which can also exhibit
the unique zero clique whenever a solution exists, requires time nk−o(1).

Public Key Exchange. So, what does the existence of a problem with our three
properties, plantable, average-case list-hard, and splittable, imply?



614 R. LaVigne et al.

The intuitive statement of our main theorem is that, if a problem has the
three properties, and is nk hard to solve on average and can be generated
in ng time (for Zero-k-Clique g = 2), then a key exchange exists that takes
O(N) time for Alice and Bob to execute, and requires an eavesdropper Eve
Ω̃(N (3k−2g)/(2k−g)) time to break. When k > g Eve takes super linear time in
terms of N . When k = 3 and g = 2, an important case for the Zero-k-Clique prob-
lem, Eve requires Ί̃(N5/4) time.

For the rest of this overview we will describe our construction with the prob-
lem Zero-k-Clique.

To describe how we get our key exchange, it is first helpful to consider Merkle
Puzzles [8,16,43]. The idea is simple: let f be a one way permutation over n bits
(so a range of 2n values) requires 2n( 1

2+Îľ) time to invert for some constant Îľ > 0.
Then, Alice and Bob could exchange a key by each computing f(v) on 10 ¡ 2n/2

random element v ∈ [2n] and sending those values f(v) to each other. With .9
probability, Alice and Bob would agree on at least one pre-image, v. It would
take an eavesdropper Eve Ί(2n( 1

2+Îľ)) time before she would be able to find the
v agreed upon by Alice and Bob. So, while Alice and Bob must take O(2n/2)
time, Eve must take O(2n( 1

2+Îľ)) time to break it.
Our construction will take on a similar form: Alice and Bob will send sev-

eral problems to each other, and some of them will have planted solutions. By
matching up where they both put solutions, they get a key exchange.

Concretely, Alice and Bob will exchange m instances of the Zero-k-
Clique problem and in

√
m of them (chosen at random), plant solutions. The

other m−√
m will not have solutions (except with some small probability). These

m problems will be indexed, and we expect Alice and Bob to have both planted a
solution in the same index. Alice can check her

√
m indices against Bob’s, while

Bob checks his, and by the end, with constant probability, they will agree on a
single index as a key. In the end, Alice and Bob require O(mng +

√
mnk) time to

exchange this index. Eve must take time Ω̃(nkm). When m = n2k−2g, Alice and
Bob take O(n2k−g) time and Eve takes Ω̃(n3k−2g). We therefore get some gap
between the running time of Alice and Bob as compared to Eve for any value
of k ≥ g. Furthermore, for all δ > 0 there exists some large enough k such that
the difference in running time is at least O(T (n)) time for Alice and Bob and
Ω̃(T (n)1.5−δ) time for Eve. Theorem 5 is the formal theorem statement.

To show hardness for this construction we combine techniques from both fine-
grained complexity and cryptography (see Fig. 2). We take a single instance and
use a self-reduction to produce a list of ďż˝ instances where one has a solution whp
if the original instance has a solution. In our reductions ďż˝ will be polynomial in
the input size. Then, we take this list and produce two lists that have a solution
in the same location with high probability if the original instance has a solution.
Finally, we plant

√
� solutions into the list, to simulate Alice and Bob’s random

solution planting.

One Way Functions. First, and informally, a fine-grained OWF is a function
on n bits that requires Õ(T (n)1−δ) time to evaluate for some constant δ > 0,
and if any adversary attempts to invert f in time Õ(T (n)1−δ′

) for any constant



Public-Key Cryptography in the Fine-Grained Setting 615

Fig. 2. A depiction of our reduction showing hardness for our fine-grained key
exchange.

δ′ > 0, she only succeeds with probability at most ε(n), where ε is considered
“insignificant.”

Ball et al. [6] defined fine-grained OWFs, keeping track of the time required to
invert and the probability of inversion in two separate parameters. We streamline
this definition by fixing the probability an adversary inverts to an insignificant
function of input size, which we define in Sect. 2.

For this overview, we will focus on the intuition of using specific problems
k-Sum-R (k-Sum modulo R) or Zero-k-Clique-R (Zero-k-Clique modulo R) to
get fine-grained OWFs, though in the full version, we construct fine-grained
OWFs from a general class of problems. Let N be the size of the input to these
problems. Note that if R is too small (e.g. constant), then these problems are
solvable quickly and the assumptions we are using are false. So, we will assume
R = Ί(nk).

OWF Assumptions. Much like for our key exchange, our assumptions are about
the difficulty of distinguishing an instance of k-Sum or Zero-k-Clique with prob-
ability more than 2/3 in time faster than nk/2 or nk respectively. Formally,
randomly generating a k-Sum-R instance is creating a k lists of size n with val-
ues randomly chosen from [0, R−1]. Recall that a random Zero-k-Clique instance
is a complete k-partite graph where weights are randomly chosen from [0, R−1].
Our ‘weak’ k-Sum-R and Zero-k-Clique-R assumptions state that for any algo-
rithm running in O(n) time, it cannot distinguish between a randomly generated
instance with a planted solution and one without with probability greater than
2/3.

Note that these assumptions are much weaker than the previously described
key-exchange assumption, where we allowed the adversary O(nk−Ω(1)) time
instead of sub-linear.

Theorem 1 (Fine-Grained OWFs (informal)). If for some constant δ > 0
and range R = Ί(nk) either k-Sum-R requires Ί(N1+δ) time to solve with



616 R. LaVigne et al.

probability >2/3 or Zero-k-Clique-R requires Ί(N (1+δ)) time to sol";"""date"",""2020-07-31T19:55:45Z""
""pdf:PDFVersion"",""1.6""
""xmp:CreatorTool"",""Springer""
""pdf:docinfo:title"",""Public-Key Cryptography in the Fine-Grained Setting""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""Advances in Cryptology – CRYPTO 2019, doi:10.1007/978-3-030-26954-8_20""
""pdfa:PDFVersion"",""A-2b""
""xmpMM:History:Action"",""converted"",""converted"",""converted""
""language"",""en""
""dc:format"",""application/pdf; version=""""A-2b"""""",""application/pdf; version=1.6""
""pdf:docinfo:creator_tool"",""Springer""
""access_permission:fill_in_form"",""true""
""xmpMM:History:When"",""2019-07-17T11:40:14Z"",""2019-07-17T11:41:13Z"",""2020-07-31T15:55:45Z""
""pdf:encrypted"",""false""
""dc:title"",""Public-Key Cryptography in the Fine-Grained Setting""
""xmp:CreateDate"",""2019-07-17T11:38:46Z""
""modified"",""2020-07-31T19:55:45Z""
""cp:subject"",""Advances in Cryptology – CRYPTO 2019, doi:10.1007/978-3-030-26954-8_20""
""xmpMM:History:SoftwareAgent"",""pdfToolbox"",""pdfToolbox"",""Preflight""
""pdf:docinfo:subject"",""Advances in Cryptology – CRYPTO 2019, doi:10.1007/978-3-030-26954-8_20""
""pdf:hasMarkedContent"",""false""
""xmpMM:History:InstanceID"",""uuid:f8f8b852-1c63-404c-b1c2-8145c0ddf666"",""uuid:c774bb94-e671-4000-b30e-c8f4f253cacb"",""uuid:3a8b800b-5d1c-4104-8cc6-ac4979a32ff1""
""xmp:ModifyDate"",""2020-07-31T15:55:45Z""
""pdf:docinfo:creator"",""Rio LaVigne ""
""meta:author"",""Rio LaVigne "",""Andrea Lincoln "",""Virginia Vassilevska Williams ""
""meta:creation-date"",""2019-07-17T06:08:46Z""
""created"",""2019-07-17T06:08:46Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-07-17T06:08:46Z""
""resourceName"",""10178933""
""pdfaid:part"",""2""
""Author"",""Rio LaVigne "",""Andrea Lincoln "",""Virginia Vassilevska Williams ""
""pdf:unmappedUnicodeCharsPerPage"",""1"",""3"",""4"",""0"",""2"",""1"",""0"",""0"",""0"",""8"",""3"",""0"",""0"",""16"",""4"",""0"",""9"",""18"",""11"",""6"",""0"",""2"",""2"",""33"",""16"",""32"",""12"",""0"",""0"",""0"",""0""
""dc:description"",""Advances in Cryptology – CRYPTO 2019, doi:10.1007/978-3-030-26954-8_20""
""access_permission:modify_annotations"",""true""
""dc:creator"",""Rio LaVigne "",""Andrea Lincoln "",""Virginia Vassilevska Williams ""
""description"",""Advances in Cryptology – CRYPTO 2019, doi:10.1007/978-3-030-26954-8_20""
""dcterms:created"",""2019-07-17T06:08:46Z""
""Last-Modified"",""2020-07-31T19:55:45Z""
""dcterms:modified"",""2020-07-31T19:55:45Z""
""title"",""Public-Key Cryptography in the Fine-Grained Setting""
""xmpMM:DocumentID"",""uuid:e23557a3-a1bf-4a85-a057-84625f2278ea""
""Last-Save-Date"",""2020-07-31T19:55:45Z""
""pdf:docinfo:modified"",""2020-07-31T19:55:45Z""
""meta:save-date"",""2020-07-31T19:55:45Z""
""Content-Length"",""702582""
""Content-Type"",""application/pdf""
""xmp:MetadataDate"",""2020-07-31T15:55:45Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Rio LaVigne "",""Andrea Lincoln "",""Virginia Vassilevska Williams ""
""pdfaid:conformance"",""B""
""dc:language"",""EN""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""31""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""2542"",""2593"",""2927"",""2460"",""2542"",""2816"",""1462"",""2520"",""2577"",""2708"",""1694"",""2359"",""2030"",""2157"",""1662"",""2076"",""2164"",""2209"",""2394"",""2234"",""2147"",""2535"",""2376"",""2336"",""2238"",""2379"",""2245"",""2998"",""2706"",""2861"",""548""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-07-17T06:08:46Z""
";https://scholar.google.com/scholar?start=660&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094626-1016;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Revelio: A MimbleWimble proof of reserves protocol;A Dutta, S Vijayakumaran ; … Valley Conference on Blockchain …, 2019  ieeexplore.ieee.org;;"… 7 2019 Crypto Valley Conference on Blockchain Technology (CVCBT) 978-1-7281-3669-

1/19/$31.00 Š2019 IEEE DOI 10.1109/CVCBT.2019.000-5 Page 2 … Let H : {0,1} ? ?? Zn be

a cryptographic hash function which is modelled as a random oracle …";Cité 3 fois;Les 4 versions;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/8782665/8787545/08787552.pdf?casa_token=CDngmngmyl8AAAAA:lJmoNYpN0lF7SkBXv2S4LHYykpB1icLqx0pF-wcjm-TrXDepB1j-S4UKtN6x1J0eo2o5iTFs2d0;"
		Skip to Main Content


		
			
				
				

				

			

		


		
			
				
					
						








	
		
	

	







						

						





























	
	
		
	
	
		
			

		
	

	
	
	



						





	
	
		
			
				IEEE Account

					Change Username/Password
	Update Address


			

			
				Purchase Details

					Payment Options
	Order History
	View Purchased Documents


			

			
				Profile Information

					Communications Preferences
	Profession and Education
	Technical Interests


			

			
				Need Help?

					US & Canada: +1 800 678 4333
	Worldwide:  +1 732 981 0060

					
	Contact & Support


			

		

		
			
				
					
							About IEEE Xplore
	Contact Us
	Help
	Accessibility
	Terms of Use
	Nondiscrimination Policy
	Sitemap
	Privacy & Opting Out of Cookies


						
							A not-for-profit organization, IEEE is the world's largest technical professional organization dedicated to advancing technology for the benefit of humanity.
Š Copyright 2021 IEEE - All rights reserved. Use of this web site signifies your agreement to the terms and conditions.
						

					


					

				

				
			

		

	


	
	


						
						






		
		
		
		
		
		
		
		
		
		
		
		
		
			
				
			
			
			
			
		
		
		
		
		
		

			


			

			
			


		
 		
		
			 

						
						









































	

		
		

		
		
		

		
			
		
		
		

		

		
		


		

		
		
		
		
		
		
		
		
		
		
	
	


















		
		
			
				
					
					
								
					
								
			
				
					
					
								
					
								
			
				
					
						








 



					
					
								
			
				
					
					
								
			
				
					
					
								
					
								
			
				
					
					
								
					
								
			
				
					
					
								
					
								
			
				
					
					
								
					
								
			
				
					
					
								
					
								
			
				
					
					
								
					
								
			
		
	




























		
			
					
			
					
			
					
			
				
					








					
			
					
			
					
			
					
			
					
			
					
			
					
			
		
		
	





	
	
	
	
	
	
	


	
	
	

	

















					

				

			


			
				
			
		

	";"""og:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""twitter:title"",""Revelio: A MimbleWimble Proof of Reserves Protocol""
""twitter:card"",""summary""
""Description"",""We reveal Revelio, a new privacy-preserving proof of reserves protocol for Grin exchanges. By design, Revelio allows the detection of collusion between exchange""
""og:title"",""Revelio: A MimbleWimble Proof of Reserves Protocol""
""resourceName"",""08787552.pdf""
""language"",""en""
""title"",""Revelio: A MimbleWimble Proof of Reserves Protocol | IEEE Conference Publication | IEEE Xplore""
""og:description"",""We reveal Revelio, a new privacy-preserving proof of reserves protocol for Grin exchanges. By design, Revelio allows the detection of collusion between exchanges while hiding the identities of the outputs owned by the exchange in a larger anonymity set of outputs.""
""twitter:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-UA-Compatible"",""IE=Edge""
""viewport"",""width=device-width, initial-scale=1.0""
""dc:title"",""Revelio: A MimbleWimble Proof of Reserves Protocol | IEEE Conference Publication | IEEE Xplore""
""twitter:description"",""We reveal Revelio, a new privacy-preserving proof of reserves protocol for Grin exchanges. By design, Revelio allows the detection of collusion between exchanges while hiding the identities of the outputs owned by the exchange in a larger anonymity set of outputs.""
""Content-Encoding"",""UTF-8""
""Content-Type-Hint"",""text/html; charset=utf-8""
""Content-Length"",""38049""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=830&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094621-997;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[PDF][PDF] CRED WORKING PAPER N o 2019-24;L Morhaim ;2019 cred.uparis2.fr;;"… react to information coming from external sources (sensors, human interfaces, other applications),

often called oracles in the … from the instrumental variable approach on the marginal cost of mining,

Metcalfe's law and crypto- currency value … 3.3.1 Blockchain cryptography …";Autres articles;Version HTML;[PDF] u-paris2.fr;http://cred.u-paris2.fr/sites/default/files/working_papers/WP%20CRED%202019-24.pdf;"
CRED WORKING PAPER N o 2019-24

Blockchain and cryptocurrencies technologies and network
structures: applications, implications and beyond

4 September 2019

Lisa Morhaim∗

∗CRED - Université Paris II. Chaire finance digitale. Email : lisa.morhaim@u-paris2.fr

1



Abstract

x

Blockchain technology is bringing together concepts and operations from several fields, including
computing, communications networks, cryptography, and has broad implications and consequences
thus encompassing a wide variety of domains and issues, including Network Science, computer sci-
ence, economics, law, geography, etc. The aim of the paper is to provide a synthetic sketch of issues
raised by the development of Blockchains and Cryptocurrencies, these issues are mainly presented
through the link between on one hand the technological aspects, i.e. involved technologies and net-
works structures, and on the other hand the issues raised from applications to implications. We
believe the link is a two-sided one. The goal is that it may contribute facilitating bridges between
research areas.
Keywords: Blockchain, Cryptocurrency, Technologies, Network structures, Applications, Implic-
ations, Economics, Law, Geography, Humanities, Interdisciplinary research.

1. Introduction

Blockchain technology is bringing together concepts and operations from several fields, including
computing, communications networks, cryptography, and artificial intelligence (Swan[454]). Addi-
tionnally, the separation between economics’ analysis, law analysis, etc can not be quite pertinent as
they often mix. The Blockchain technology has broad implications and consequences thus encom-
passing a wide variety of domains and issues. Network Science is a deeply interdisciplinary rooted
field. Keeping in that tradition, this paper proposes some paths to think about the Blockchain
revolution and analyze its technologies and structures, applications and implications in a deeply
interdisciplinary way.

The objective is mainly twice: to give a most possible synthetic panorama of issues raised by the
Blockchain technologies and network structures both for researchers working on a specific Blockchain
research area and for researchers working and thinking on the tools in one or some of the specific
domain(s) that are in the scope of the paper (which includes besides Network Science, economics, but
also computer science, law, geography, political science, etc) and we hope it will easy and enhance
interdisciplinary researches. As the paper is intended to easy bridges between area researches, it
has been conceived somehow self-contained and synthetic as possible.

The aim of the paper is to provide a synthetic sketch of issues raised by the development of Block-
chains and Cryptocurrencies. These issues are mainly presented through the link between on one
hand the technological aspects (involved technologies and networks structures) and on the other
hand the issues raised in Economics, Law, etc, from applications to implications and beyond. We
believe the link is a two-sided one. The goal is to contribute facilitating bridges between research
areas and to give a first introduction to these links and issues. It refers to many existing good
surveys and on-going research.

The panorama have been thought from the issues they raise and discuss. Given the fast rythm at
which new articles and analysis are provided, it is becoming impossible to cover exhaustively the
literature on Blockchain, cryptocurrencies and related fields. Choices have been made in order to
provide a quite wide range of questions and issues that are being currently discussed while easying

2



interdisciplinary research. Network Science is rooted as an interdisciplinary field using and providing
mathematical, physical, statistical as well as biological, engineering and computer science tools. As
the Blockchain technology field is spreading, it is becoming clearer and clearer that Network Science
can deeply fruitfully provide and develop tools at the interaction with some other various disciplines,
as Economics, Law, Geography, History, Anthropology, Sociology, Political Science, etc....The aim
of this paper is to give insights on what such an experience is already being done while providing
some motivation and will for future research, mainly through a few chosen examples and studies.
The main remarkable feature of blockchain technology is that it has been thought so that the users
trust the system without no longer having to trust the partner or an intermediary and so that it
solves the double-spending1 issue.

Cryptocurrency2. As reported by the ECB-European Central Bank[44, 45], Virtual Currency
Schemes (VCS) are diverse, ECB distinguishing closed, unidirectional, and bi-directional VCS while
underlying that the most common approach distinguishes centralised and decentralised VCS. De-
centralised bi-directional VCS (the vast majority of all VCS) can differ from various standpoints.4

The virtual currency ecosystem involves new categories of actors not before present in the payments
environment.5 Since Nakamoto’s seminal paper[341] on Bitcoin, the Blockchain technology is cur-
rently intensively studied in the scientific community. As Swan[454] underlines: Bitcoin terminology
can be confusing because the word Bitcoin is used to simultaneously denote three different things.
First, Bitcoin refers to the underlying blockchain technology platform. Second, Bitcoin is used
to mean the protocol that runs over the underlying blockchain technology to describe how assets
are transferred on the blockchain. Third, Bitcoin denotes a digital currency, Bitcoin, the first and
largest of the cryptocurrencies.

Blockchain and cryptocurrencies: definitions, technologies and specificities A block-
chain is the combination of several technologies and characteristics: distributed database over a
P2P network, public-key cryptography (including eventually digital signature) and eventually con-
sensus mechanisms (see Narayanan Clark[344]). Narayanan Clark[344] show that, in 2008 when
Nakamoto[341]’s paper on Bitcoin was published, nearly all of the technical components of bitcoin
originated in the academic literature of the 1980s and ‘90s.6. For a discussion on public blockchain
versus private (and semi-private) blockchain see Guegan[210].

A cryptographic hash function h is firstly a hash function i.e. one that maps a bit string x (of

1i.e. spending the same unit more than once.
2Cryptocurrencies date from Chaum 1983[118] and many developments have followed (see [412]). Haber Stor-

netta 1990[217], refering to Diffie Hellman[153]’s asymmetric (i.e. public-key) cryptography3 (see also RSA[407],
Merckle[323], Bayer Haber Stornetta[55]), first described the concept of a blockchain.

4ECB[44, 45]. They can differ from their validating systems (i.e. the methods used for validating the transactions
made and securing the network), the algorithms involved (i.e. the mathematical procedure for calculating and
processing data), their (total) supply of coins, a functional perspective (i.e. extra features available on the network).

5These are (ECB[44, 45]): inventors (known or unknown individuals or organisations that create a virtual currency
and develop the technical part of its network, issuers (that are able to generate units of the virtual currency), miners
(persons, sometimes working as a group, who voluntarily make computer processing available in order to validate a
set of transactions (a “block”) made with a decentralised VCS and add this to the payment ledger (a “blockchain”)),
processing service providers (facilitating the transfer of units from one user to another, these services being part
of the activity performed by the miners in decentralised VCS), users, wallet providers (offering a digital wallet to
users for storing their virtual currency cryptographic keys and transaction authentication codes, online or offline
wallets, although users can also set up and maintain a wallet themselves without making use of a wallet provider),
exchanges offer trading services (quoting exchange rates by which the exchange will buy/sell virtual currency against
the main currencies), trading platforms (that function as marketplaces) and various other actors not specific to the
VCS environment (merchants, payment facilitators, software developers, computer hardware manufacturers (building
specific equipment for mining) and ATM-Automated Teller Machine manufacturers).

6See also Sherman[436]

3



arbitrary length) to a short unique value h(x) (a short bit string of fixed length) such that computing
h(x) knowing x is easy. Given a hash function h, a collision is a couple (x, x′) such that x 6= x′ and
h(x) = h(x′). A cryptographic hash function h is collision resistant, i.e. it is infeasible7 to find a
collision. It is a one-way function: finding x from its hash value h(x) is infeasible. It is expected to
satisfy the avalanche effect: a small change in x must lead to a large change in h(x).8

Public-key (or asymmetric) cryptography is a cryptographic system that involves the use of two
keys, a public-key that may be disseminated widely9 by the owner and a private key known only to
the owner (and that must remain private to achieve efffective security). The key used to encrypt
the message cannot be used to decrypt it, and the message encrypted using one key can only be
decrypted with the other key. It can ensure confidentiality, the message (data) being encrypted by
the sender with the recipient’s public key and decrypted by the recipient with the recipient’s private
key. It can ensure authentication and data integrity through digital signatures, the message being
encrypted by the sender with her/his own private key and decrypted by anyone with the sender’s
public key.

Combining public-key cryptography and hash functions allows to ensure both authentication and
confidentiality efficiently.

A blockchain is a distributed ledger (i.e. a distributed database allowing to record and share data
across multiple data stores, the ledgers) with a linked list of blocks using hash pointers (i.e. pointers
to where some information is stored, together with a cryptographic hash of the information), such
that additions to the database are done through the procedure

• transactions are grouped with other transactions to form a block

• the network nodes determine collectively if the block is valide through a validation algorithm
called a consensus mechanism

• as an example, in the PoW consensus mechanism, a puzzle that needs time and computing
power has to be solved. The miner who first solves the puzzle sends the solution to the other
nodes of the network (who can easily check it and validate the transactions in the block), and
is rewarded for his contribution to the network by finding the puzzle solution.

• once a block (each block containing the transactions, a hash of its own, a hash of the previous
block, timestamp) is validated, it is added to the database and the blockchain is updated
accross the network.

Do you need a blockchain? Blockchain is not advantageous for every situation. On the way to
construct indicators for comparing Blockchains. A decision-model. A vademecum on Blockchain for
identifying when, which and how. Framework propositions for practitioners and decision-tree. On
DLT characteristics. On misconceptions. Insights to select a protocol..
As noted in Swan[454]: the Blockchain is not for every situation despite the many interesting
potential uses of blockchain technology, one of the most important skills in the developing industry
is to see where it is and is not appropriate to use cryptocurrency and blockchain models (Swan[454]).
So, firstly, do you need a Blockchain ? (see Wust[493]) or what blockchain alternative do you need

7meaning here that no process, not even one subject to arbitrary faults, can find a collision (Cachin Guerraoui
Rodrigues[99]). In particular, it does not mean that no collision exists. This can also be expressed in terms of
“easy/not easy” and is clearly related to algorithmic complexity issues (see Katz et al.[264, 263], Stallings[448]).

8h being clearly not continuous nor invertible.
9Each user will thus have a collection of public keys of the other users

4



? (see Koens[273]). Criteria are being developed. Guegan Henot[213] analyse from different aspects
why a company (in banking or insurance system, and industry) interested to develop its business
with a public blockchain decides that a blockchain protocol is more legitimate than another one for
the business it wants to develop looking at the legal (in case of dispute) points of view and introduce
the notion of probative or evidential value associated to a blockchain in order to provide to the
entrepreneurs an intrinsic value characterizing the blockchain he/she wants to use to develop his/her
business. By quantifying the revenues a 51% attack can create for the miners, a corresponding cost is
provided for each blockchain. Betzwieser 2019[70] propose a decision model for the implementation
of Blockchain solutions. Belotti et al.[59] provide a vademecum on Blockchain technologies, drawing
a picture to answer to when (when there are actual advantages in using blockchain instead of
any other traditional solution, such as centralized databases), which (which kind of blockchain
better meets use-case requirements) and how (how to use it). De 2019[148] propose a framework
of blockchain models to help practitioners understanding and potentially implement Blockchain-
based solutions based. Mulligan[337] propose a framework for practitioners (including a decision-
tree). Kannengiesser et al.[260] present a comprehensive set of 49 DLT characteristics synthesized
from the literature on DLT, which have been found relevant to consider when developing viable
applications on DLT. Conte[134]’s purpose is to clarify current and widespread misconceptions about
the properties of blockchain technologies. Shahaab[430] have listed consensus protocols against
basic features and sector preference in a tabular format to facilitate selection. They argue that no
protocol is a silver bullet, therefore should be selected carefully, considering the sector requirements
and environment.

Applicability. An applicability framework. A taxonomy of Blockchain applications.
Risius and Sohrer[406] provide a framework to understand where and how blockchain technology is
effectively applicable and where it has mentionable practical effects. Labazova[284] gives a taxonomy
of blockchain applications.

Layers Some analysis of Blockchain through layers.
A blockchain can be analyzed through its layers (see Singhal et al.[439]): application layer (i.e.
the layer where the desired functionalities are coded and made an application out of it for the end
users), execution layer (i.e. the layer where the executions of instructions ordered by the application
layer take place on all the nodes in a blockchain network, the instructions being simple instructions
or a set of multiple instructions in the form of a smart contract), semantic layer (the rules of the
system can be defined in this layer, such as data models and structures and how the blocks are
linked with each other), propagation layer (i.e. the peer-to-peer communication layer that allows
the nodes to discover each other), consensus layer (i.e. the layer getting all the nodes to agree on
one consistent state of the ledger). See also Casino[108]. Glaser Hawlitschek Notheisen in [162]
(volume 1 chapter 4) investigate the blockchain as a platform and present technical layers of the
system as well as institutional characteristics and governance implications, followed by a discussion
of the role of trust in blockchain systems.

Digital disruption Thinking the Blockchain revolution within innovations (and digital) disruption
Theories of disruptive innovations and managerial implications have been explored and developed
since the 1990’s. Moller[333] on characterizing digital disruption in the theory of disruptive innov-
ation. See also Lessig[290, 291], Wu[492], De Filippi Hassan[144], De Filippi Wright[147], Olleros
[359].

On previous and existing surveys
BooksMany books on Blockchain have been published. See Narayanan et al. 2016[343], Tapscott[460],
Casey[107], Burniske[96], Swan[454], Ammous 2018[20],Campbell-Verduyn [104], Treiblmaier Beck[162],

5



etc. On Blockchain economics: see Tasca 2016[462], Swan[456] and the references herein, and Block-
chain and the law: see De Filippi Wright[147].
Surveys General and technical on Blockchain. Cryptocurrencies. Bitcoin. Bitcoin research across
disciplines. Consensus and mining strategy. Architecture. Merkle tree. Security. Privacy. Applic-
ations. Platforms. Financial sector. ICO. FinTech. RegTech. Governance. Intellectual property.
Economics. Game theory. Law.
For a technical survey, see Tschorsch[474]. Refer to see Tasca et al.[463] and Casino Dasaklis
Patsakis[109] for general surveys. See also [303, 498, 495, 11]. Sejfuli 2018[428] provide a synthetic
and general overview of the Architecture, Security and Reliability of blockchain. Belotti et al.[58]
provide a vademecum on Blockchain technologies. Bonneau et al.[128] provide a systematic ex-
position of the second generation of cryptocurrencies, including Bitcoin and “altcoins.” Hardle[222]
provide some insights into the mechanics of cryptocurrencies, describing summary statistics and
focusing on potential future research avenues in financial economics. See also Kumar Smith[442].
Singh[438] perform a literature review on Bitcoin and its upsides, downside and divergent views
from previous studies. Holub 2018[235] surveys on Bitcoin research across discplines. Wang et
al.2019[483] survey on consensus mechanisms and mining strategy management. Yang 2019[500]
provides a survey on Blockchain-based internet service architecture (requirements, challenges, trends
and future). Bosamia[88] discusses the Merkle tree concept with its advantages and disadvantages
and its implementations. Dasgupta et al.[141] and Kolokotronis[275] survey on blockchain from
security perspective. See also Taylor[464]. Conti[135] on privacy. On Blockchain applications, see
Schedlbauer Wagner[422] for a literature review, Joude[252] for a recent survey on applications us-
age in different domains survey. For an overview Platforms based on Distributed Ledger Technology
see Schoenhals et al.[424]. Collomb[131] survey on implications on the financial sector. See also
Zhao Meng[508]. Li[293] for a recent discussion on ICO current research and future directions. On
Fintech see Kavuri 2019[265]. On RegTech see Johansson et al.[257]. For a literature review on use
of Blockchain in governance: Razzaq et al.[400]. Wang[481] for a recent summary of research on
Blockchain in the field of Intellectual property. On Blockchain economics, see among many Catalini
Gans[112] Davidson et al.[143], Abadi Brunnermeier[1], Davidson et al.[143], Halaburda[218] and
Qin[390] on economic issues in bitcoin mining and blockchain research. Liu[301] provides a survey
on applications of game theory in Blockchain. Benson[61] on implications of adopting Blockchain
technology on international sales transactions. For a survey on Blockchain issues and the law, we
refer to Filippi Wright[147] and Marmoz[312], Berg et al.[63], see also Ostbye[364] on liability issue
if a public cryptocurrency protocol fails. De Filippi Wright[491] on the widespread deployment of
Blockchains will lead to expansion of a new subset of law, which they term Lex Cryptographia.

Organization of the paper. Section 1 introduces the aims, definitions, literature and frameworks.
Section 2 provides a brief sketch of some of the many Blockchain applications. Section 3 describes
the technologies, specificities, network structures, implications and related issues of Blockchains and
Cryptocurrencies. Section 4 provides some insights on a broader scope. Section 5 concludes.

2. Applications a brief sketch

For a systematic literature review of Blockchain-based applications refer to Casino[109].
.

In the economic areas, one can insist on Fintech (see Kavuri 2019[265], Anand 2019[25]), Business
(see Viriyasitavat et al.[476] investigate the characteristics of Blockchain and business processe),
Tourism (see Horst et al. (volume 2 chapter 1 in Treiblmaier Beck 2019[162]), Intellectual property,

6



Industries (see Al-Jaroodi[9]), Payments industry (see Holotiuk et al. (volume 1 chapter 7 in [162]),
including a discussion agenda based on pain points and opportunities), Music industry, ICO Crowd-
funding and Microfinance (see Boreiko[85] describes all important aspects of Blockchain financing
and provide a comparative study of token sales versus crowdfunding and conventional financing
methods, provide a review of literature on token sale financing and challenges and provide empirical
related studies, Li 2019[293] for a recent discussion on ICO current research and future directions,
Fridgen[187] for a taxonomy blockchain and crowdfunding, Arnold et al.(volume 1 chapter 8 in
Treiblmaier Beck 2019[162]) on identifying industries and use cases that may benefit from adopting
blockchain when it comes to crowdfunding and showing how crowdfunding and initial coin offer-
ings differ and how the latter is reshaping the former, Cervhiello[114] for statistical approach to
detect characteristics of ICO significantly related to fraudulent behaviors, Holoweiko 2018[234] on
ico security, Garratt garratt2019entrepreneurial examines how financing a start-up through an ICO
changes the incentives of an entrepreneur relative to debt and venture capital financing: depending
on market characteristics, an ICO can result in a better or worse alignment of the interests of the
entrepreneur and the investors compared with conventional modes of financing), Humanitarian aid,
Shared Economy (see Huckle[245] (volume 1 chapter 3 in[162]) providing a technology adoption per-
spective on the Blockchain-Based decentralized business models in the sharing economy and apply
agent-based modeling to explore the circumstances under which a decentralized sharing economy
business model might achieve widespread adoption), Management and governance (DAO, dApps,
Howell 2019[241], Young 2018[502]), Supply Chain (see [478]), Supply Chain Finance (see [233]),
Marketing and Adertising uses.

In Law areas (see references in Bolotaeva[82], Filippi Hassan[147], De Filippi[147], one can insist on
Smart Contracts (SCs) (see Bakos Halaburda 2019[43], Howell 2019[241], see Alharby Moorsel[10],
see also[78, 225, 152], Meneghetti[322], senopra[285], [353], see Dargaye[140]10, Tonelli[469], Casino[108],
Marchesi Tonnelli[381], Krishnan [277] on smart contract and interoperability, O’Shields[361] and
Westerkamp[485]), Multisignature: Smart Complex Contracts, LegalTech (see Corrales Fenwick
Haapio[136]), Regulation (see Smith[441] for a framework, Melo[319], Baidoo[42]), Dispute resolu-
tion (Raymond 2014[398]), Crowdsourcing and Court system (Ast[34], Li 2018[295]).

Beside Economics and Law, many other applications are being developed: Archives (on decent-
ralized scientific publications, see Tenorio 2019[466] and on medical see Coghill[130]), Health (see
Burniske 2016[490], Sachin et al. (volume 2 chapter 5 in [162]) presenting a mobile healthcare system
for personal health data collection, sharing, and collaboration between individuals and healthcare
providers, as well as insurance companies, Genestier[193], review[281, 202, 159, 510, 266, 247, 276]),
Agriculture, Food traceability, Energy (see Strucker et al.(volume 2 chapter 2 in Treiblmaier Beck
2019[162]) having a close look at the energy sector and present some ideas on how blockchain
might potentially impact this sector in the not-so-far-off future, Peter[376]), Politics (see De Fil-
ippi Loveluck[146], Berg[69], Martinez[314] argues on Blockchain solution in eDemocracy platforms,
Grontas[203] on electronic voting, Dhillon Grammateia Riley[151] on voting questions for econom-
ists, Elsden[168]), Education (see Chen [120], Sommer[444], Palavinel[370]), Post-Disaster Recov-
ery (see Nawari Ravindran[345], Demir[150]), Smart cities (see Kitchin[270], Speed[446], Ramos
2019[394]), Prediction markets, Blockchain gaming (see Min[330], and Min[329] on security of block-

10Dargaye[140] presents a formal logical framework able to extend the execution of blockchain transactions to
events coming from external oracles: in many industrial applications smart contracts react to information coming
from external sources (sensors, human interfaces, other applications), often called oracles in the blockchain jargon,
which amplifies their vulnerability, these events being by essence non-reliable, since transaction execution can be
triggered by information whose veracity cannot be established by the blockchain

7



chain games).

3. Technologies, network structures and specificities

Technical aspects and specificities and related issues involved in applications and implications reveal
that advantages of Blockchain can sometimes also be their main limitations.

3.1 Distributed system, peer-to-peer (P2P) network, decentralization and
immutability

3.1.1 Distributed system, peer-to-peer (P2P) network and Blockchain

Distributed system. Processes cooperate? Distributed computing community. Theoretical aspects of
Blockchains.
Blockchain protocols are solving a classical distributed computing problem. When a program en-
compasses multiple processes (a process representing a computer, a processor in a computer, etc),
the fundamental problem is having all the processes cooperate on a common task. Important issues
then arise as the tolerance to uncertainty and adversarial influence in a distributed system, which
may arise from network delays, faults, or even malicious attacks (Cachin Guerraoui Rodrigues[99]).
There is growing work on the line of recent distributed computing11 community efforts dedicated
to the theoretical aspects of blockchains (see [28, 387, 214]). Anceaume et al.[26] is the first pa-
per specifying blockchains as a composition of abstract data types all together with a hierarchy
of consistency criteria that formally characterizes the histories admissible for distributed programs
that use them. Anceaume et al.[27] introduce the Distributed Register, a register that mimics the
behaviour of the Bitcoin ledger, the aim being to provide formal guarantees on the coherent evolu-
tion of Bitcoin.12 Rauchs et al.[396] establish a conceptual framework and terminology that can be
applied across DLT systems and to distinguish these newer technologies from ‘traditional’ databases
and other systems, providing a multidimensional tool for examining and comparing existing DLT
systems and their traits and features, it also can serve when examining new DLT systems proposals.
Siris et al.[440] discusses on the interledger approach: blockchains and more generally distributed
ledger technologies(DLTs)’ shortcomings becoming more apparent, a relatively recent approach to
address their performance, scalability, privacy, and other problems are to use multiple different
DLTs instead of relying on just one. Daniel Burkhardt et al. (volume 2 chapter 4 in [162]) argue
that distributed ledgers will enable new opportunities to replace existing components on all layers
of industrial IT architecture.

The main examples of distributed systems without blockchains are distributed systems based on
Directed Acyclic Graph (DAG). Instead of a chain, such distributed systems use a Directed Acyc-
lic Graph (DAG)13 as decentralized structure. Examples of such cryptocurrencies are Iota (based
on the DAG called Tangle), Hashgraph, and Nano. There are other distributed systems without
blockchains, for example Corda[227, 93, 92] used to treat financial legal agreements could look like

11see Cachin et al.[99], Fokkink[184, 183]
12Anceaume et al.[27] underlines that even though the behaviour of distributed ledgers is similar to abstractions

that have been deeply studied for decades in distributed systems no abstraction is sufficiently powerful to capture
the distributed ledger behaviour.

13i.e. une chaine avec des ramifications

8



a firms’ consortium blockchain but uses of a concept of change of states and transactions in place
of chain of blocks.

3.1.2 Decentralization

Distributed system and organization. New forms of organization. Institutional cryptoeconomics.
Dynamics. Organizational economics
Resnick[405] discusses how computer-modeling activities can help people move beyond the central-
ized mindset, helping them gain new insights into (and appreciation for) the workings of decent-
ralized systems. Blockchain can be thought of as an institutional innovation. Berg[68] introduces
the V-form organisation, a new form of firm organisation where vertical integration is outsourced to
a decentralised distributed ledger (a blockchain), and rely on the coordination of a (trusted) third
party. Allen[12] apply institutional cryptoeconomics to the information problems in global trade,
model incentives under which blockchain-based supply chain infrastructure will be built, and make
predictions about the future of supply chains, arguing blockchain will change the patterns and dy-
namics of how, where and what we trade through four main reasons. Berg[66] study the institutional
economic dynamics of a wide-spread blockchain technology adoption, examining the structural eco-
nomic effects of this institutional innovation as disintermediation in markets, dehierarchicalisation
of organisations, and growing private provision of economic infrastructure for exchange, contracting
and coordination. Schneider[423] discusses the very concept of decentralization, arguing that to be
a reliable concept, it should come with high standards of specificity. Takagi[459] study the economic
mechanisms behind blockchain-enabled decentralisation from the viewpoint of organizational eco-
nomics.

Decentralization analysis and networks. Consensus Network Topology. How to quantify decentraliz-
ation. Decentralization metrics. Decentralization function. Mining pools and endogenous fees.
See Tasca et al.[463]: Consensus Network Topology describes the type of interconnection between
the nodes and the type of information flow between them for transaction and/or for the purpose
of validation. Consensus Network Topology is linked to the level of (de)centralisation in the valid-
ation process, lthough it is not the only determinant as other factors influence it (like the reward
mechanism) (see Bonneau et al.[84]). Gencer et al.[192] study decentralization metrics in Bit-
coin and Ethereum networks, adapting Internet measurement techniques. Kwon et al.[282] define
(m, ξ, δ)-decentralization, a state satisfying that there are at least m participants running a node,
and the ratio between the total resource power of nodes run by the richest and the δ-th percent-
ile participants is less than or equal to 1 + ξ. So that when δ = ξ = 0 and m is large enough,
(m, ξ, δ)-decentralization is full decentralization. Kwon et al.[282] study decentralization in PoW-
based, proof-of-stake (PoS)-based and delegated proof-of-stake (DPoS)-based coins by the means
of studying (m, ξ, δ)-decentralization. Stifter[450] shows an example of data mining applied to the
analysis of the blockchain network. Bodo[81] analyzes decentralization related to distributed ledger
technologies (DLTs), its extent, its mode, the systems which it can refer to as the products of
particular economic, political, social dynamics around and within these techno-social systems. Chu
Wang[127] explore the trade-off decentralization-scalability, decentralization being quantified by the
decentralization level they define within the paper. Cong et al.[132] study the centralization and
decentralization forces in the creation and competition of mining pools.

Dapps (decentralized applications), DAOs (decentralized autonomous organizations), DACs (decent-
ralized autonomous corporations) and DASs (decentralized autonomous societies)

9



See Raval[397] for more details on Decentralized Applications. Hsieh[242] analyse Bitcoin as an
example to shed light on how a DAO works in the cryptocurrency industry.

Some limitations about decentralization. Centralization-decentralization tension. Is decentralization
always positive. On the role of the Law.
Swan[454] already notes that “There is a mix of forces both toward centralization and decentraliz-
ation operating in the blockchain industry”. Hsieh et al.[243] provide a statistical analysis whose
results may s";"""date"",""2019-09-05T02:41:59Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2019-09-05T02:41:59Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.1415926-2.5-1.40.14 (TeX Live 2013) kpathsea version 6.1.1""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2019-09-05T02:41:59Z""
""created"",""2019-09-05T02:41:59Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-09-05T02:41:59Z""
""resourceName"",""WP%20CRED%202019-24.pdf""
""Author"",""""
""producer"",""pdfTeX-1.40.14""
""pdf:docinfo:producer"",""pdfTeX-1.40.14""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""4"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2019-09-05T02:41:59Z""
""Last-Modified"",""2019-09-05T02:41:59Z""
""dcterms:modified"",""2019-09-05T02:41:59Z""
""title"",""""
""Last-Save-Date"",""2019-09-05T02:41:59Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2019-09-05T02:41:59Z""
""meta:save-date"",""2019-09-05T02:41:59Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.1415926-2.5-1.40.14 (TeX Live 2013) kpathsea version 6.1.1""
""Content-Length"",""669225""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""56""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""223"",""2879"",""4148"",""3131"",""3523"",""3453"",""3866"",""2859"",""3335"",""2622"",""3624"",""3474"",""2949"",""3074"",""3515"",""3825"",""3441"",""3087"",""3715"",""2769"",""3402"",""3070"",""3460"",""3074"",""2597"",""2535"",""2585"",""2432"",""2153"",""2680"",""2328"",""2494"",""2546"",""2462"",""2168"",""2373"",""2293"",""2264"",""2213"",""2436"",""2268"",""2436"",""2328"",""2604"",""2322"",""2387"",""2332"",""2582"",""2341"",""2221"",""2269"",""2604"",""2370"",""2301"",""2286"",""2044""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-09-05T02:41:59Z""
";https://scholar.google.com/scholar?start=810&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094583-835;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[HTML][HTML] A generic construction of integrated secure-channel free PEKS and PKE and its application to EMRs in cloud storage;T Suzuki, K Emura, T Ohigashi ; Journal of medical systems, 2019  Springer;United States of America;"… For example, the challenge ciphertext \(C^{\ast }_{\textsf {PEKS}}||C^{\ast }_{\textsf {PKE}}\) can

be modified such as \(C_{\textsf {PEKS}}||C^{\ast }_{\textsf {PKE}}\) where \(C_{\textsf

{PEKS}}\neq C^{\ast }_{\textsf {PEKS}}\), and one can send it to the decryption oracle …";Cité 6 fois;Les 7 versions;[HTML] springer.com;https://idp.springer.com/authorize/casa?redirect_uri=https://link.springer.com/article/10.1007/s10916-019-1244-2&casa_token=So6LT_mCHYsAAAAA:L68uVDEVz_ouXmnRvQIiU1v4FrlNsV3SUWTSJYTLxi6n_2x7egvJLleu4uJyUiQga4D3fYqH3SeXzpk;"
    
    
    
        
            
            
                
            

            
        
    


    
        
        

        
            
                Advertisement

                    

            

        


    
        
            
                
    
        
            
            [image: SpringerLink]
        
        
        
    


            

            
                
    
        
            
                Search
                
                    
                
            
        
        
            	
                    Log in
                


        
    

    



            

        

    

    
        
            
                
                    
                        
    
        Search SpringerLink
        
            
            
                Search
                
                    
                
            
            
                
            
            
        

    




                    

                

            

        

    



        

    
        
            

            
                
            


            
                
    
        
            
                Associated Content

                
                    
                        
                            Part of a collection:

                            
                                Systems-Level Quality Improvement
                            

                        
                    

                
            

        
    

            



            
                
                    
                        	Systems-Level Quality Improvement
	Published: 28 March 2019



                        
                        A Generic Construction of Integrated Secure-Channel Free PEKS and PKE and its Application to EMRs in Cloud Storage

                        	Tatsuya Suzuki1,2, 
	Keita Emura 
            ORCID: orcid.org/0000-0002-8969-35812 & 
	Toshihiro Ohigashi1,2 


                        
                            
    Journal of Medical Systems

                            volume 43, Article number: 128 (2019)
            Cite this article
                        

                        
    

                        
                            
    
        	
                    133 Accesses

                
	
                    3 Citations

                
	
                        1 Altmetric

                    
	
                Metrics details

            


    




                        

                            
    

    

                    
                


                
                    Abstract
To provide a search functionality for encrypted data, public key encryption with keyword search (PEKS) has been widely recognized. In actual usage, a PEKS scheme should be employed with a PKE scheme since PEKS itself does not support the decryption of data. Since a naive composition of a PEKS ciphertext and a PKE ciphertext does not provide CCA security, several attempts have been made to integrate PEKS and PKE in a joint CCA manner (PEKS/PKE for short). In this paper, we further extend these works by integrating secure-channel free PEKS (SCF-PEKS) and PKE, which we call SCF-PEKS/PKE, where no secure channel is required to send trapdoors. We give a formal security definition of SCF-PEKS/PKE in a joint CCA manner, and propose a generic construction of SCF-PEKS/PKE based on anonymous identity-based encryption, tag-based encryption, and one-time signature. We also strengthen the current consistency definition according to the secure-channel free property, and show that our construction is strongly consistent if the underlying IBE provides unrestricted strong collision-freeness which is defined in this paper. We also show that such an IBE scheme can be constructed by employing the Abdalla et al. transformations (TCC 2010/J. Cryptology 2018). Finally, as an application of SCF-PEKS/PKE, we strengthen the security of encrypted Electronic Medical Record (EMR) system proposed by Guo and Yau (J. Medical Sys. 2015).



                    
    


                    
                        
                            
                                This is a preview of subscription content, access via your institution.

                            

                        
                        
                            
                                
 Access options

 
  Buy single article

  
   
    Instant access to the full article PDF.

   

   
    CHF 34,95

    Tax calculation will be finalised during checkout.

    
     
     
     
     
     
     
     
     
     
     
    

   

  

  
 
 
  
   
    Rent this article via DeepDyve.

   

  

  
 
 
  
   
    Learn more about Institutional subscriptions

   

  

 
 


                            

                        
                        
                            
                        

                    

                    

                    

                    Notes
	1.As a similar primitive, decryptable searchable encryption has been proposed [20, 23] where keywords can be recovered from ciphertexts via the decryption procedure. One main difference from PEKS/PKE is that no plaintext space is defined.


	2.Remark that we do not consider security against keyword guessing attacks which is considered by Fang et al. [18], and leave it as a future work of this paper.


	3.This assumption is also natural since we do not consider keyword guessing attacks [18].


	4.Remark that, in our construction, the IBE-part is independent to the plaintext M. Thus, \(\mathcal {B}\) can choose the challenge plaintexts \((R_{0}^{\ast },R_{1}^{\ast })\) regardless of M∗.


	5.Remark that \(K^{\ast }_{v}\) can be chosen in the setup phase. Thus, TCR is enough rather than CR.


	6.Farshim et al. [19] showed that a transformation proposed by Mohassel [29] is also powerful enough to construct completely robust IBE,al though the transformation requires the random oracle.


	7.Although other anonymous IBE schemes without random oracles based on simple assumptions have been proposed, we cannot employ them. For example, the Chen et al. IBE scheme [13] and the Jutla-Roy IBE scheme [24, 25] are IBE-ANO-CPA secure. Although Jutla and Roy gave a CCA version, the scheme is not anonymous due to its public verifiability where one can check whether or not a ciphertext is valid for an identity.





References
	1.Abdalla, M., Bellare, M., Catalano, D., Kiltz, E., Kohno, T., Lange, T., Malone-Lee, J., Neven, G., Paillier, P., and Shi, H., Searchable encryption revisited: Consistency properties, relation to anonymous IBE, and extensions. J. Cryptol. 21(3):350–391, 2008.
Article 
    
                    Google Scholar 
                

	2.Abdalla, M., Bellare, M., and Neven, G.: Robust encryption. In: TCC, pp. 480–497, 2010

                    Google Scholar 
                

	3.Abdalla, M., Bellare, M., and Neven, G., Robust encryption. J. Cryptol. 31(2):307–350, 2018.
Article 
    
                    Google Scholar 
                

	4.Baek, J., Safavi-Naini, R., and Susilo, W.: On the integration of public key data encryption and public key encryption with keyword search. In: ISC, pp. 217–232, 2006

	5.Bellare, M., and Rogaway, P.: Random oracles are practical: A paradigm for designing efficient protocols. In: ACM Conference on Computer and Communications Security, pp. 62–73, 1993

	6.Bellare, M., and Shoup, S.: Two-tier signatures, strongly unforgeable signatures, and fiat-shamir without random oracles. In: Public Key Cryptography, pp. 201–216, 2007

	7.Boneh, D., Crescenzo, G. D., Ostrovsky, R., and Persiano, G.: Public key encryption with keyword search. In: EUROCRYPT, pp. 506–522, 2004

	8.Boneh, D., and Franklin, M. K.: Identity-based encryption from the weil pairing. In: CRYPTO, pp. 213–229, 2001

	9.Boyen, X., and Waters, B.: Anonymous hierarchical identity-based encryption (without random oracles). In: CRYPTO, pp. 290–307, 2006

	10.Buccafurri, F., Lax, G., Sahu, R. A., and Saraswat, V.: Practical and secure integrated PKE+PEKS with keyword privacy. In: SECRYPT, pp. 448–453, 2015

	11.Canetti, R., Goldreich, O., and Halevi, S., The random oracle methodology, revisited. J. ACM 51(4): 557–594, 2004.
Article 
    
                    Google Scholar 
                

	12.Canetti, R., Halevi, S., and Katz, J.: Chosen-ciphertext security from identity-based encryption. In: EUROCRYPT, pp. 207–222, 2004

	13.Chen, J., Lim, H. W., Ling, S., Wang, H., and Wee, H.: Shorter IBE and signatures via asymmetric pairings. In: Pairing-Based Cryptography, pp. 122–140, 2012

                    Google Scholar 
                

	14.Chen, Y., Zhang, J., Lin, D., and Zhang, Z., Generic constructions of integrated PKE and PEKS. Des. Codes Cryptography 78(2):493–526, 2016.
Article 
    
                    Google Scholar 
                

	15.Emura, K.: A generic construction of secure-channel free searchable encryption with multiple keywords. In: NSS, pp. 3–18, 2017

	16.Emura, K., Miyaji, A., Rahman, M. S., and Omote, K., Generic constructions of secure-channel free searchable encryption with adaptive security. Secur. Commun. Netw. 8(8):1547–1560, 2015.
Article 
    
                    Google Scholar 
                

	17.Fang, L., Susilo, W., Ge, C., and Wang, J.: A secure channel free public key encryption with keyword search scheme without random oracle. In: CANS, pp. 248–258, 2009

	18.Fang, L., Susilo, W., Ge, C., and Wang, J., Public key encryption with keyword search secure against keyword guessing attacks without random oracle. Inf. Sci. 238:221–241, 2013.
Article 
    
                    Google Scholar 
                

	19.Farshim, P., Libert, B., Paterson, K. G., and Quaglia, E. A.: Robust encryption, revisited. In: Public-Key Cryptography, pp. 352–368, 2013

                    Google Scholar 
                

	20.Fuhr, T., and Paillier, P.: Decryptable searchable encryption. In: ProvSec, pp. 228–236, 2007

	21.Gentry, C.: Practical identity-based encryption without random oracles. In: EUROCRYPT, pp. 445–464, 2006

                    Google Scholar 
                

	22.Guo, L., and Yau, W., Efficient secure-channel free public key encryption with keyword search for EMRs in cloud storage. J. Med. Syst. 39(2):11, 2015.
Article 
    
                    Google Scholar 
                

	23.Hofheinz, D., and Weinreb, E., Searchable encryption with decryption in the standard model. IACR Cryptology ePrint Archive 2008:423, 2008.

                    Google Scholar 
                

	24.Jutla, C. S., and Roy, A.: Shorter quasi-adaptive NIZK proofs for linear subspaces. In: ASIACRYPT, pp. 1–20, 2013

                    Google Scholar 
                

	25.Jutla, C. S., and Roy, A., Shorter quasi-adaptive NIZK proofs for linear subspaces. J. Cryptology 30(4): 1116–1156, 2017.
Article 
    
                    Google Scholar 
                

	26.Kiah, M. L. M., Nabi, M. S., Zaidan, B. B., and Zaidan, A. A., An enhanced security solution for electronic medical records based on AES hybrid technique with SOAP/XML and SHA-1. J. Med. Syst. 37(5):9971, 2013.
Article 
    
                    Google Scholar 
                

	27.Kiltz, E.: Chosen-ciphertext security from tag-based encryption. In: TCC, pp. 581–600, 2006

                    Google Scholar 
                

	28.Lu, C., Wu, Z., Liu, M., Chen, W., and Guo, J., A patient privacy protection scheme for medical information system. J. Med. Syst. 37(6):9982, 2013.
Article 
    
                    Google Scholar 
                

	29.Mohassel, P.: A closer look at anonymity and robustness in encryption schemes. In: ASIACRYPT, pp. 501–518, 2010

	30.Pedersen, T. P.: Non-interactive and information-theoretic secure verifiable secret sharing. In: CRYPTO, pp. 129–140, 1991

	31.Rhee, H. S., Park, J. H., and Lee, D. H., Generic construction of designated tester public-key encryption with keyword search. Inf. Sci. 205:93–109, 2012.
Article 
    
                    Google Scholar 
                

	32.Saraswat, V., and Sahu, R. A.: Short integrated PKE+PEKS in standard model. In: SPACE, pp. 226–246, 2017

	33.Suzuki, T., Emura, K., and Ohigashi, T.: A generic construction of integrated secure-channel free PEKS and PKE. In: ISPEC, pp. 69–86, 2018

                    Google Scholar 
                

	34.Wang, T., Au, M. H., and Wu, W.: An efficient secure channel free searchable encryption scheme with multiple keywords. In: NSS, pp. 251–265, 2016

                    Google Scholar 
                

	35.Wee, H.: Public key encryption against related key attacks. In: Public Key Cryptography, pp. 262–279, 2012

                    Google Scholar 
                

	36.Zhang, R., and Imai, H., Combining public key encryption with keyword search and public key encryption. IEICE Trans. 92-D(5):888–896, 2009.
Article 
    
                    Google Scholar 
                


Download references




Acknowledgements
We thank Dr. Yohei Watanabe for helpful discussion.


Funding
This work was supported in part by the JSPS KAKENHI Grant Number JP16H02808 and the MIC/SCOPE #162108102.


Author information
Affiliations
	Tokai University, 2-3-23, Takanawa, Minato-ku, Tokyo, 108-8619, Japan
Tatsuya Suzuki & Toshihiro Ohigashi

	National Institute of Information and Communications Technology (NICT), 4-2-1, Nukui-kitamachi, Koganei, Tokyo, 184-8795, Japan
Tatsuya Suzuki, Keita Emura & Toshihiro Ohigashi


Authors	Tatsuya SuzukiView author publications
You can also search for this author in
                        PubMed Google Scholar



	Keita EmuraView author publications
You can also search for this author in
                        PubMed Google Scholar



	Toshihiro OhigashiView author publications
You can also search for this author in
                        PubMed Google Scholar





Corresponding author
Correspondence to
                Tatsuya Suzuki.


Ethics declarations

              
              
                
                  Conflict of interests
                

                We declare that we have no conflict of interest.

              
              
                
                  Ethical approval
                

                This article does not contain any studies with human participants or animals performed by any of the authors.

              
            

Additional information
Publisher’s Note
Springer Nature remains neutral with regard to jurisdictional claims in published maps and institutional affiliations.
An extended abstract appears in the 14th International Conference on Information Security Practice and Experience (ISPEC 2018) [33]. This is the full version. In this version, we consider encrypted Electronic Medical Records (EMRs) proposed by Guo and Yau [22] as an application of SCF-PEKS/PKE. We can strengthen the security of the system by integrating SCF-PEKS and PKE. Moreover, we add all security proofs that were omitted in the proceedings version. See Section 2 Differences from the Proceedings Version.
This article is part of the Topical Collection on Systems-Level Quality Improvement


Rights and permissions
Reprints and Permissions


About this article
[image: Verify currency and authenticity via CrossMark]       


Cite this article
Suzuki, T., Emura, K. & Ohigashi, T. A Generic Construction of Integrated Secure-Channel Free PEKS and PKE and its Application to EMRs in Cloud Storage.
                    J Med Syst 43, 128 (2019). https://doi.org/10.1007/s10916-019-1244-2
Download citation
	Received: 17 September 2018

	Accepted: 24 February 2019

	Published: 28 March 2019

	DOI: https://doi.org/10.1007/s10916-019-1244-2



Keywords
	PEKS
	Integration of PEKS and PKE
	Secure-channel free
	Joint CCA security
	Encrypted EMR







                

            
        

        
            
                
                    
                


                
                    
    
        
            
                Associated Content

                
                    
                        
                            Part of a collection:

                            
                                Systems-Level Quality Improvement
                            

                        
                    

                
            

        
    

                


                
                    
                


                
                    
                        
                            
                                
 Access options

 
  Buy single article

  
   
    Instant access to the full article PDF.

   

   
    CHF 34,95

    Tax calculation will be finalised during checkout.

    
     
     
     
     
     
     
     
     
     
     
    

   

  

  
 
 
  
   
    Rent this article via DeepDyve.

   

  

  
 
 
  
   
    Learn more about Institutional subscriptions

   

  

 
 


                            

                        

                        
                            
    
        
            Advertisement

            

        

    



                        

                        

                        

                    

                

            
        

    


    
    

    
        
    


        
    
        
            
                Over 10 million scientific documents at your fingertips

                
                    
                        Switch Edition
                        	
                                Academic Edition
                            
	
                                Corporate Edition
                            


                    

                
            

        

        
            	Home
	Impressum
	Legal information
	Privacy statement
	California Privacy Statement
	How we use cookies
	Manage cookies/Do not sell my data
	Accessibility
	Contact us


            
    
        
            Not logged in
             - 83.76.85.89
        

        
            Not affiliated
        


    



            
                Springer Nature
                
                    
                    
                
            
            Š 2021 Springer Nature Switzerland AG. Part of Springer Nature.

            
        

        
    
        
            
        
        
            
        
        
            
        
        
            
        
        
            
        
        
            
        
        
            \
        
        
            
        
    

    



    

    
    
";"""dc.publisher"",""Springer""
""og:image"",""https://media.springernature.com/w200/springer-static/cover/journal/10916.jpg""
""twitter:card"",""summary""
""og:site_name"",""Journal of Medical Systems""
""citation_reference"",""citation_journal_title=J. Cryptol.; citation_title=Searchable encryption revisited: Consistency properties, relation to anonymous IBE, and extensions; citation_author=M Abdalla, M Bellare, D Catalano, E Kiltz, T Kohno, T Lange, J Malone-Lee, G Neven, P Paillier, H Shi; citation_volume=21; citation_issue=3; citation_publication_date=2008; citation_pages=350-391; citation_doi=10.1007/s00145-007-9006-6; citation_id=CR1"",""citation_title=Robust Encryption; citation_inbook_title=Theory of Cryptography; citation_publication_date=2010; citation_pages=480-497; citation_id=CR2; citation_author=Michel Abdalla; citation_author=Mihir Bellare; citation_author=Gregory Neven; citation_publisher=Springer Berlin Heidelberg"",""citation_journal_title=J. Cryptol.; citation_title=Robust encryption; citation_author=M Abdalla, M Bellare, G Neven; citation_volume=31; citation_issue=2; citation_publication_date=2018; citation_pages=307-350; citation_doi=10.1007/s00145-017-9258-8; citation_id=CR3"",""Baek, J., Safavi-Naini, R., and Susilo, W.: On the integration of public key data encryption and public key encryption with keyword search. In: ISC, pp. 217–232, 2006"",""Bellare, M., and Rogaway, P.: Random oracles are practical: A paradigm for designing efficient protocols. In: ACM Conference on Computer and Communications Security, pp. 62–73, 1993"",""Bellare, M., and Shoup, S.: Two-tier signatures, strongly unforgeable signatures, and fiat-shamir without random oracles. In: Public Key Cryptography, pp. 201–216, 2007"",""Boneh, D., Crescenzo, G. D., Ostrovsky, R., and Persiano, G.: Public key encryption with keyword search. In: EUROCRYPT, pp. 506–522, 2004"",""Boneh, D., and Franklin, M. K.: Identity-based encryption from the weil pairing. In: CRYPTO, pp. 213–229, 2001"",""Boyen, X., and Waters, B.: Anonymous hierarchical identity-based encryption (without random oracles). In: CRYPTO, pp. 290–307, 2006"",""Buccafurri, F., Lax, G., Sahu, R. A., and Saraswat, V.: Practical and secure integrated PKE+PEKS with keyword privacy. In: SECRYPT, pp. 448–453, 2015"",""citation_journal_title=J. ACM; citation_title=The random oracle methodology, revisited; citation_author=R Canetti, O Goldreich, S Halevi; citation_volume=51; citation_issue=4; citation_publication_date=2004; citation_pages=557-594; citation_doi=10.1145/1008731.1008734; citation_id=CR11"",""Canetti, R., Halevi, S., and Katz, J.: Chosen-ciphertext security from identity-based encryption. In: EUROCRYPT, pp. 207–222, 2004"",""citation_title=Shorter IBE and Signatures via Asymmetric Pairings; citation_inbook_title=Pairing-Based Cryptography – Pairing 2012; citation_publication_date=2013; citation_pages=122-140; citation_id=CR13; citation_author=Jie Chen; citation_author=Hoon Wei Lim; citation_author=San Ling; citation_author=Huaxiong Wang; citation_author=Hoeteck Wee; citation_publisher=Springer Berlin Heidelberg"",""citation_journal_title=Des. Codes Cryptography; citation_title=Generic constructions of integrated PKE and PEKS; citation_author=Y Chen, J Zhang, D Lin, Z Zhang; citation_volume=78; citation_issue=2; citation_publication_date=2016; citation_pages=493-526; citation_doi=10.1007/s10623-014-0014-x; citation_id=CR14"",""Emura, K.: A generic construction of secure-channel free searchable encryption with multiple keywords. In: NSS, pp. 3–18, 2017"",""citation_journal_title=Secur. Commun. Netw.; citation_title=Generic constructions of secure-channel free searchable encryption with adaptive security; citation_author=K Emura, A Miyaji, MS Rahman, K Omote; citation_volume=8; citation_issue=8; citation_publication_date=2015; citation_pages=1547-1560; citation_doi=10.1002/sec.1103; citation_id=CR16"",""Fang, L., Susilo, W., Ge, C., and Wang, J.: A secure channel free public key encryption with keyword search scheme without random oracle. In: CANS, pp. 248–258, 2009"",""citation_journal_title=Inf. Sci.; citation_title=Public key encryption with keyword search secure against keyword guessing attacks without random oracle; citation_author=L Fang, W Susilo, C Ge, J Wang; citation_volume=238; citation_publication_date=2013; citation_pages=221-241; citation_doi=10.1016/j.ins.2013.03.008; citation_id=CR18"",""citation_title=Robust Encryption, Revisited; citation_inbook_title=Public-Key Cryptography – PKC 2013; citation_publication_date=2013; citation_pages=352-368; citation_id=CR19; citation_author=Pooya Farshim; citation_author=Benoît Libert; citation_author=Kenneth G. Paterson; citation_author=Elizabeth A. Quaglia; citation_publisher=Springer Berlin Heidelberg"",""Fuhr, T., and Paillier, P.: Decryptable searchable encryption. In: ProvSec, pp. 228–236, 2007"",""citation_title=Practical Identity-Based Encryption Without Random Oracles; citation_inbook_title=Advances in Cryptology - EUROCRYPT 2006; citation_publication_date=2006; citation_pages=445-464; citation_id=CR21; citation_author=Craig Gentry; citation_publisher=Springer Berlin Heidelberg"",""citation_journal_title=J. Med. Syst.; citation_title=Efficient secure-channel free public key encryption with keyword search for EMRs in cloud storage; citation_author=L Guo, W Yau; citation_volume=39; citation_issue=2; citation_publication_date=2015; citation_pages=11; citation_doi=10.1007/s10916-014-0178-y; citation_id=CR22"",""citation_journal_title=IACR Cryptology ePrint Archive; citation_title=Searchable encryption with decryption in the standard model; citation_author=D Hofheinz, E Weinreb; citation_volume=2008; citation_publication_date=2008; citation_pages=423; citation_id=CR23"",""citation_title=Shorter Quasi-Adaptive NIZK Proofs for Linear Subspaces; citation_inbook_title=Advances in Cryptology - ASIACRYPT 2013; citation_publication_date=2013; citation_pages=1-20; citation_id=CR24; citation_author=Charanjit S. Jutla; citation_author=Arnab Roy; citation_publisher=Springer Berlin Heidelberg"",""citation_journal_title=J. Cryptology; citation_title=Shorter quasi-adaptive NIZK proofs for linear subspaces; citation_author=CS Jutla, A Roy; citation_volume=30; citation_issue=4; citation_publication_date=2017; citation_pages=1116-1156; citation_doi=10.1007/s00145-016-9243-7; citation_id=CR25"",""citation_journal_title=J. Med. Syst.; citation_title=An enhanced security solution for electronic medical records based on AES hybrid technique with SOAP/XML and SHA-1; citation_author=MLM Kiah, MS Nabi, BB Zaidan, AA Zaidan; citation_volume=37; citation_issue=5; citation_publication_date=2013; citation_pages=9971; citation_doi=10.1007/s10916-013-9971-2; citation_id=CR26"",""citation_title=Chosen-Ciphertext Security from Tag-Based Encryption; citation_inbook_title=Theory of Cryptography; citation_publication_date=2006; citation_pages=581-600; citation_id=CR27; citation_author=Eike Kiltz; citation_publisher=Springer Berlin Heidelberg"",""citation_journal_title=J. Med. Syst.; citation_title=A patient privacy protection scheme for medical information system; citation_author=C Lu, Z Wu, M Liu, W Chen, J Guo; citation_volume=37; citation_issue=6; citation_publication_date=2013; citation_pages=9982; citation_doi=10.1007/s10916-013-9982-z; citation_id=CR28"",""Mohassel, P.: A closer look at anonymity and robustness in encryption schemes. In: ASIACRYPT, pp. 501–518, 2010"",""Pedersen, T. P.: Non-interactive and information-theoretic secure verifiable secret sharing. In: CRYPTO, pp. 129–140, 1991"",""citation_journal_title=Inf. Sci.; citation_title=Generic construction of designated tester public-key encryption with keyword search; citation_author=HS Rhee, JH Park, DH Lee; citation_volume=205; citation_publication_date=2012; citation_pages=93-109; citation_doi=10.1016/j.ins.2012.03.020; citation_id=CR31"",""Saraswat, V., and Sahu, R. A.: Short integrated PKE+PEKS in standard model. In: SPACE, pp. 226–246, 2017"",""citation_title=A Generic Construction of Integrated Secure-Channel Free PEKS and PKE; citation_inbook_title=Information Security Practice and Experience; citation_publication_date=2018; citation_pages=69-86; citation_id=CR33; citation_author=Tatsuya Suzuki; citation_author=Keita Emura; citation_author=Toshihiro Ohigashi; citation_publisher=Springer International Publishing"",""citation_title=An Efficient Secure Channel Free Searchable Encryption Scheme with Multiple Keywords; citation_inbook_title=Network and System Security; citation_publication_date=2016; citation_pages=251-265; citation_id=CR34; citation_author=Tingting Wang; citation_author=Man Ho Au; citation_author=Wei Wu; citation_publisher=Springer International Publishing"",""citation_title=Public Key Encryption against Related Key Attacks; citation_inbook_title=Public Key Cryptography – PKC 2012; citation_publication_date=2012; citation_pages=262-279; citation_id=CR35; citation_author=Hoeteck Wee; citation_publisher=Springer Berlin Heidelberg"",""citation_journal_title=IEICE Trans.; citation_title=Combining public key encryption with keyword search and public key encryption; citation_author=R Zhang, H Imai; citation_volume=92-D; citation_issue=5; citation_publication_date=2009; citation_pages=888-896; citation_doi=10.1587/transinf.E92.D.888; citation_id=CR36""
""citation_journal_title"",""Journal of Medical Systems""
""language"",""en""
""citation_cover_date"",""2019/05/01""
""og:description"",""To provide a search functionality for encrypted data, public key encryption with keyword search (PEKS) has been widely recognized. In actual usage, a PEKS scheme should be employed with a PKE scheme since PEKS itself does not support the decryption of data. Since a naive composition of a PEKS ciphertext and a PKE ciphertext does not provide CCA security, several attempts have been made to integrate PEKS and PKE in a joint CCA manner (PEKS/PKE for short). In this paper, we further extend these works by integrating secure-channel free PEKS (SCF-PEKS) and PKE, which we call SCF-PEKS/PKE, where no secure channel is required to send trapdoors. We give a formal security definition of SCF-PEKS/PKE in a joint CCA manner, and propose a generic construction of SCF-PEKS/PKE based on anonymous identity-based encryption, tag-based encryption, and one-time signature. We also strengthen the current consistency definition according to the secure-channel free property, and show that our construction is strongly consistent if the underlying IBE provides unrestricted strong collision-freeness which is defined in this paper. We also show that such an IBE scheme can be constructed by employing the Abdalla et al. transformations (TCC 2010/J. Cryptology 2018). Finally, as an application of SCF-PEKS/PKE, we strengthen the security of encrypted Electronic Medical Record (EMR) system proposed by Guo and Yau (J. Medical Sys. 2015).""
""prism.issn"",""1573-689X""
""citation_author_email"",""t-suzuki@star.tokai-u.jp"",""k-emura@nict.go.jp"",""ohigashi@tsc.u-tokai.ac.jp""
""twitter:image:alt"",""Content cover image""
""prism.number"",""5""
""citation_issn"",""1573-689X""
""citation_language"",""en""
""dc:title"",""A Generic Construction of Integrated Secure-Channel Free PEKS and PKE and its Application to EMRs in Cloud Storage | SpringerLink""
""Content-Encoding"",""UTF-8""
""citation_pdf_url"",""https://link.springer.com/content/pdf/10.1007/s10916-019-1244-2.pdf""
""citation_lastpage"",""15""
""DOI"",""10.1007/s10916-019-1244-2""
""citation_journal_abbrev"",""J Med Syst""
""prism.rightsAgent"",""journalpermissions@springernature.com""
""citation_author"",""Tatsuya Suzuki"",""Keita Emura"",""Toshihiro Ohigashi""
""resourceName"",""casa""
""dc.date"",""2019-03-28""
""citation_springer_api_url"",""http://api.springer.com/metadata/pam?q=doi:10.1007/s10916-019-1244-2&api_key=""
""citation_issue"",""5""
""prism.volume"",""43""
""prism.publicationName"",""Journal of Medical Systems""
""citation_doi"",""10.1007/s10916-019-1244-2""
""dc.title"",""A Generic Construction of Integrated Secure-Channel Free PEKS and PKE and its Application to EMRs in Cloud Storage""
""prism.url"",""https://link.springer.com/article/10.1007/s10916-019-1244-2""
""citation_volume"",""43""
""dc.language"",""En""
""Content-Language"",""en""
""format-detection"",""telephone=no""
""citation_publication_date"",""2019/05""
""prism.endingPage"",""15""
""citation_title"",""A Generic Construction of Integrated Secure-Channel Free PEKS and PKE and its Application to EMRs in Cloud Storage""
""citation_author_institution"",""Tokai University, Tokyo, Japan"",""National Institute of Information and Communications Technology (NICT), Tokyo, Japan"",""National Institute of Information and Communications Technology (NICT), Tokyo, Japan"",""Tokai University, Tokyo, Japan"",""National Institute of Information and Communications Technology (NICT), Tokyo, Japan""
""access"",""No""
""citation_publisher"",""Springer US""
""applicable-device"",""pc,mobile""
""dc.format"",""text/html""
""description"",""To provide a search functionality for encrypted data, public key encryption with keyword search (PEKS) has been widely recognized. In actual usage, a PEKS ""
""title"",""A Generic Construction of Integrated Secure-Channel Free PEKS and PKE and its Application to EMRs in Cloud Storage | SpringerLink""
""citation_online_date"",""2019/03/28""
""twitter:site"",""@SpringerLink""
""dc.source"",""Journal of Medical Systems 2019 43:5""
""dc.type"",""OriginalPaper""
""dc.copyright"",""2019 Springer Science+Business Media, LLC, part of Springer Nature""
""dc.creator"",""Tatsuya Suzuki"",""Keita Emura"",""Toshihiro Ohigashi""
""citation_fulltext_html_url"",""https://link.springer.com/article/10.1007/s10916-019-1244-2""
""prism.publicationDate"",""2019-03-28""
""Content-Type"",""text/html; charset=UTF-8""
""journal_id"",""10916""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""dc.description"",""To provide a search functionality for encrypted data, public key encryption with keyword search (PEKS) has been widely recognized. In actual usage, a PEKS scheme should be employed with a PKE scheme since PEKS itself does not support the decryption of data. Since a naive composition of a PEKS ciphertext and a PKE ciphertext does not provide CCA security, several attempts have been made to integrate PEKS and PKE in a joint CCA manner (PEKS/PKE for short). In this paper, we further extend these works by integrating secure-channel free PEKS (SCF-PEKS) and PKE, which we call SCF-PEKS/PKE, where no secure channel is required to send trapdoors. We give a formal security definition of SCF-PEKS/PKE in a joint CCA manner, and propose a generic construction of SCF-PEKS/PKE based on anonymous identity-based encryption, tag-based encryption, and one-time signature. We also strengthen the current consistency definition according to the secure-channel free property, and show that our construction is strongly consistent if the underlying IBE provides unrestricted strong collision-freeness which is defined in this paper. We also show that such an IBE scheme can be constructed by employing the Abdalla et al. transformations (TCC 2010/J. Cryptology 2018). Finally, as an application of SCF-PEKS/PKE, we strengthen the security of encrypted Electronic Medical Record (EMR) system proposed by Guo and Yau (J. Medical Sys. 2015).""
""og:type"",""article""
""citation_article_type"",""Systems-Level Quality Improvement""
""og:title"",""A Generic Construction of Integrated Secure-Channel Free PEKS and PKE and its Application to EMRs in Cloud Storage""
""prism.doi"",""doi:10.1007/s10916-019-1244-2""
""X-UA-Compatible"",""IE=edge""
""citation_firstpage"",""1""
""prism.startingPage"",""1""
""viewport"",""width=device-width, initial-scale=1""
""dc.rightsAgent"",""journalpermissions@springernature.com""
""prism.section"",""OriginalPaper""
""dc.identifier"",""doi:10.1007/s10916-019-1244-2""
""dc.subject"",""Health Informatics"",""Health Informatics"",""Statistics for Life Sciences, Medicine, Health Sciences""
""og:url"",""https://link.springer.com/article/10.1007/s10916-019-1244-2""
""prism.copyright"",""2019 Springer Science+Business Media, LLC, part of Springer Nature""
";https://scholar.google.com/scholar?start=650&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094644-1100;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Omniring: Scaling private payments without trusted setup;RWF Lai, V Ronge, T Ruffing, D Schröder… ; Proceedings of the …, 2019  dl.acm.org;;"… Jiafan Wang Chinese University of Hong Kong ABSTRACT Monero is the largest cryptocurrency

with built-in crypto- graphic privacy features … A cryptocurrency typically consists of two components:

(1) a public ledger, eg, realized by a blockchain protocol, to publish …";Cité 13 fois;Les 3 versions;[PDF] acm.org;https://dl.acm.org/doi/pdf/10.1145/3319535.3345655?casa_token=W6O7q21Pi1UAAAAA:u5zXL8f_KU1c6FQhKAMEgl5E-iEAB0Gtb_FSIfIXWTJ0_OCyrFKo9KV8x691tDXXmmqxWnnRCcY;;;https://scholar.google.com/scholar?start=910&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094635-1053;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[PDF][PDF] The Rush Dilemma: Attacking and Repairing Smart Contracts on Forking Blockchains.;V Botta, D Friolo, D Venturi, I Visconti ; IACR Cryptol. ePrint Arch., 2019  media.voog.com;;"… where ZKSim1(?,x,w) = ZKSim1(?,x) if R(x, w) = 1, and both oracles ZKSim1 and Prove output ?

if R(x, w) = 0. Sometimes we call a non-interactive proof … where Q is the list of all queries to oracle

ZKSim1(? … In this section we focus on blockchain-aided MPC for parallel coin tossing …";Cité 2 fois;Les 3 versions;[PDF] voog.com;https://media.voog.com/0000/0042/1115/files/rush%20dilemma.pdf;"
The Rush Dilemma: Attacking and Repairing Smart

Contracts on Forking Blockchains

Vincenzo Botta1, Daniele Friolo2, Daniele Venturi2, and Ivan Visconti1

1Department of Computer Science, Sapienza University of Rome, Italy
2DIEM, University of Salerno, Italy

August 2, 2019

Abstract

We investigate the security of smart contracts within a blockchain that can fork (as Bit-
coin and Ethereum). In particular, we focus on multi-party computation (MPC) protocols
run on-chain with the aid of smart contracts, and observe that honest players face the fol-
lowing dilemma: Should I rush sending protocol’s messages based on the current view of the
blockchain, or rather wait that a message is confirmed on the chain before sending the next
one?

To the best of our knowledge, the (implicit) default option used in previous work is the
second one, and thus known on-chain MPC protocols take long time to be executed on those
blockchains with a long confirmation time (e.g., 1 hour per transaction in Bitcoin). While
the first option would clearly be preferable for efficiency, we show that this is not necessarily
the case for security, as there are natural examples of on-chain MPC protocols that simply
become insecure in presence of rushing players.

Our contributions are twofold:

• For the concrete case of fairly tossing multiple coins with penalties, we show that the
lottery protocol of Andrychowicz et al. (S&P ’14) becomes insecure in the presence of
rushing players. In addition, we present a new protocol that instead retains security
even if the players are rushing.

• We design a compiler that takes any on-chain MPC protocol and transforms it into
another one (for the same task) that remains secure even in the presence of rushing
players. The only (unavoidable) requirement is that honest players start to be rush-
ing after the first round of the protocol (by all players) has been confirmed on the
blockchain.

Our techniques are inspired by ideas on resettably secure computation (Goyal and Sahai,
EUROCRYPT ’09). We also provide a prototype implementation of our coin tossing protocol
using Ethereum smart contracts, and instantiate our generic compiler in a concrete setting,
showing that both our constructions yield considerable improvements in terms of efficiency.

Keywords: blockchain, forks, smart contracts, secure computation, resettability.



Contents

1 Introduction 1
1.1 Forks and the Double-Spending Problem . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Subtle Attacks to Smart Contracts: Efficiency vs Security . . . . . . . . . . . . . 1
1.3 Our Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.4 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2 Preliminaries 5
2.1 Notation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2 Standard Primitives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

3 Parallel Coin Tossing 7
3.1 The Protocol of Andrychowicz et al. . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2 A Simple Attack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.3 Our New Lottery Protocol: An Ethereum Smart Contract . . . . . . . . . . . . . 9

4 A Generic Compiler Exploiting Finality 13
4.1 ABC Resettability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.2 Compiler Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.3 Security Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

5 Efficiency Considerations 19
5.1 Setting the Stage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
5.2 Time to Completion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
5.3 Communication Complexity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

6 Conclusions 21

Appendix A Instantiating the Compiler 24
A.1 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
A.2 Security Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25



1 Introduction

The rise of blockchains1 is progressively changing the way transactions are executed over the
Internet. Indeed, the traditional client-server paradigm turns out to be insufficient when many
parties want to perform a joint computation, especially in cases where features like public
verifiability and automatic punishment are desired. Instead, blockchains through the execution
of smart contracts naturally allow many players to perform a joint computation, even when they
are not simultaneously online; moreover they allow to publicly check the actions of all players2

and enforce a proper behavior through financial punishments.

1.1 Forks and the Double-Spending Problem

Typical blockchains experience some delays before a transaction can be considered confirmed.
Indeed, a large part of the most used blockchains consists of a list of blocks that can temporary
fork. In such cases, fork-resolution mechanisms decide which branch is eventually part of the
list of blocks and which one is discarded, at the price of cutting off some transactions that for
some time have appeared on the blockchain.

The existence of transactions that appear and then disappear from a blockchain is the
source of the famous double spending attack. In such attack, the adversary performs a payment
thorough a transaction on the blockchain in order to receive a service off-chain. If later on the
transaction related to the payment disappears from the blockchain, due to the presence of forks,
then the attacker gets the money back and can spend it for something else. Therefore, at the
end of the day, the service was received for free. The crucial point of the double spending attack
is that, while the payment transaction disappears, the obtained service is not canceled since it
is not linked to the payment transaction happening on chain.

The solution to the double spending problem is pretty harsh: the receiver of a payment will
have to wait long time—essentially until the transaction is confirmed and somehow becomes
irreversible—before taking future actions. Obviously, this can be problematic when an entire
process consists of many sequential transactions and the confirmation time is long.

Interestingly, the double spending problem seems to disappear when instead the service
consists of another on-chain transaction that is connected to the payment transaction. Indeed,
in this case, if as consequence of a fork the payment transaction disappears, then the service
transaction disappears too. This chaining of transactions related to the same process can be
easily implemented through smart contracts. Indeed, a smart contract can have an initial
state s1 that is updated transaction by transaction obtaining s2, s3, and so on. Let ti be the
transaction that changes the state from si to si+1. If because of a fork the state goes back to
si from a state sj , only ti is again applicable to si, while instead all transactions ti+1, . . . , tj−1
are not applicable to state si. Therefore, by invalidating ti (similarly to the double spending
problem where money is used in a new transaction making ti invalid), then ti+1, . . . , tj−1 will
be invalidated too.

This motivates the possibility of running smart contracts efficiently, without waiting that
every single transaction is confirmed before broadcasting the next one. We have therefore the
following rush dilemma: to rush or not to rush?

1.2 Subtle Attacks to Smart Contracts: Efficiency vs Security

Since transactions take long time to be confirmed in a forking blockchain, the full execution
of a smart contract with multiple sequential transactions might take too long. It would thus

1Throughout the paper, we use the terms “blockchain” and “distributed ledger” interchangeably.
2We will often use the two terms “party” and “player” as synonyms.

1



be natural to speed up the execution of smart contracts by rushing and playing messages
immediately. Indeed, as mentioned above, by appropriately chaining the transactions of a
smart contract, attacks consisting in exploiting the cancellation of a transaction like the double-
spending attack are not effective, and therefore rushing could be a valid option.

However, we notice that forks can help an adversary to mount more subtle attacks. For
example, a player could answer to some transaction A by sending another transaction B as soon
as A appears on the blockchain. Obviously, in case of forks, the transaction A could appear on
the blockchain in different branches, and then multiple copies of B would follow A. While at first
sight this seems to be fine, an adversary computing A can exploit his view of B in a branch of a
fork to play adaptively a message different than A in another branch, invalidating some security
property of the smart contract. Indeed, different transactions A1 and A2 could be played in the
two branches of a fork, and (potentially different) transactions B1 and B2 might be required
and played as answers. Notice that the honest player could become aware of the fork only after
the fact, i.e., after A1 and B1 have been played already. Indeed, because of a fork, transactions
A1 and B1 would just disappear, and transaction A2 might appear instead. The honest player
therefore will have to compute B2 to continue the execution of the smart contract. The fact that
the adversary can play A2 adaptively after having seen B1 can produce a deviation from the
expected behavior of the smart contract, therefore compromising the appealing transparency
and robustness guarantees of this technology.

In addition, when the transactions represent an on-chain execution of an MPC protocol, the
above scenario can be a serious threat for confidential data of honest players.

1.3 Our Contributions

Motivated by the dilemma of rushing risking security or waiting paying on efficiency, we investi-
gate the security of smart contracts that leverage a forking blockchain. Our main contributions
are outlined below.

Insecurity of smart contracts with rushing players. Consider a simple smart contract
executed by two players, Alice and Bob, willing to establish jointly a random string:

1. Alice starts the protocol by sending to the smart contract a commitment to a random
string r1;

2. Bob sends a random string r2 to the smart contract;
3. Alice then opens the commitment, and if the opening is valid the common string is defined

to be r = r1 ⊕ r2.

For concreteness, say that Alice is honest and Bob is corrupted, and assume that a fork happens
after Alice already sent the commitment. If Bob runs the protocol honestly on the first branch,
he gets to see Alice’s opening, and thus he can completely bias the output on the other branch
by just sending r′2 = r′⊕r1 to the smart contract, for any value r′ of his choice. This motivating
example clearly shows that, unless one has proven some kind of resilience to forks, it is certainly
preferable to always wait that transactions are confirmed, at the price of having very slow
executions of the smart contract. Such slowness could be unacceptable in some applications.

As our first result, we analyze a variant of the above attack to the well-known smart con-
tract3 of Andrychowicz et al. [ADMM16], for securely realizing multi-party lotteries. The main
difference with the toy example from above is that each player commits to a random value ri
between 1 and n (where n is the total number of participants to the lottery), and then, after
all the commitments have been opened, the winner of the lottery is defined to be the player

3The protocol of [ADMM16] is actually based on Bitcoin, but this makes no difference for our attack.

2



w = r1 + . . .+rn (mod n)+1. An appealing feature of this protocol is that it achieves so-called
fairness with penalties: If a malicious player aborts the protocol (e.g., it does not open the
commitment before a certain time bound), then a previously deposited amount of coins is auto-
matically transferred to the honest players (i.e., to those that correctly opened the commitment
on time). Such a feature is particularly important in light of the negative result by Cleve [Cle86]
on achieving fairness without honest majority.

We note that in the protocol of Andrychowicz et al. it is vital that players are non-rushing,
and therefore post new transactions only after the previous transactions in the protocol are
already confirmed on the blockchain. Indeed, in the presence of rushing players, a simple
variant of the attack described above would allow a malicious party to commit to a value ri
such that

∑
i ri (mod n) + 1 = i, assuming that all players already opened the commitments

on a minor branch of a fork.

On-chain parallel coin tossing. As our second contribution, we go beyond the limits of the
protocol of [ADMM16], and present a smart contract that implements such functionality and
remains secure even if the players are rushing. In fact, the smart contract we design is more
general in that it allows the players to establish a common, uniformly random, string (which
in turn allows to run a lottery). Similar to [ADMM16], our protocol also achieves fairness with
penalties.

The main idea in our construction consists of using verifiable unpredictable functions (VUF)
[MRV99] in order to implement a commitment scheme that simultaneously: (i) has an unpre-
dictable opening for the receiver even in case of multiple openings of the commitment through
multiple evaluations of the VUF with the same key but with different inputs, and (ii) achieves
binding for the sender through the uniqueness of the VUF. We put together all the openings
into a long string that remains unpredictable as long as there is a single honest player. This
long string is then given in input to a random oracle to complete the generation of a random
string that can be used in various applications (e.g., to run a multi-party lottery).

Notice that this result makes no use of finality of transactions on a blockchain (i.e., we do
not need to know after how many blocks a transaction can be considered permanent). We stress
that we consider the adversary as a player that tries to exploit the existence of forks in order to
bias the output of the smart contract. We are not modelling the adversary of the smart contract
as a player that has control over forks, deciding which branch will eventually be discarded and
which one will become permanently part of the blockchain. Obviously, a powerful adversary
that has control over the forks can always play the protocol on each fork to then select the one
that produced the output that she likes the most. This is unavoidable when there is no use
of finality of transactions, and we tackle this in our next result that instead takes finality of
transactions into account.

On-chain MPC with rushing players. As final contribution, we show a general transform
to design smart contracts that retain security in the presence of forks (and thus, when properly
instantiated, can be more efficient since players are allowed to rush). Our transform is inspired
by previous works that show how to make MPC protocols secure against reset attacks [GS09,
GM11]. The main idea consists of asking each player to first commit to its input and randomness,
and then to run the underlying MPC protocol by additionally proving in zero knowledge4 that
each message has been computed correctly w.r.t. the initial commitment.

4Technically, the zero-knowledge proof must also be secure w.r.t. reset attacks. Moreover, the fact that such
proofs come from different players requires to protect them w.r.t. man-in-the-middle attacks. To fulfill both
requirements we use proofs that are non-interactive and non-malleable. Moreover, for simplicity, we will use the
term “proof” rather than “argument” even when computational soundness is sufficient.

3



In addition to connecting the problems of security w.r.t. fork attacks with previous work
on resettable security, we actually consider a slightly different setting that remained so far
unexplored in the literature. Indeed, in order to model forks we notice that: (i) honest rushing
players would use the same input on both branches of a fork, but the randomness would be fresh
(since it would be sampled multiple times and the random tape does not move back); (ii) while
reset attacks are generically allowed to any previous point of the computation, we can leverage
on the properties of a blockchain in order to make sure that there is a bound beyond which one
can consider a transaction finalized (e.g., 6 is the commonly recommended number of blocks
after which a transaction is considered irreversible in then Bitcoin blockchain), and therefore a
transaction can be considered confirmed at some point. Our transform takes advantage of the
above two simplifications by requiring honest players to wait for the confirmation of the first
transaction of each other player, and by avoiding the use of a pseudo-random function that is
traditionally used to change randomness after a reset [GS09].

Note that here we make a minimal use of the finality guarantee of a blockchain, since
we ask to wait for the confirmation of only the first message of each player. Waiting for a
single confirmation is optimal in light of known impossibility results for several interesting
functionalities5 in the presence of arbitrary reset attacks (for us, honest players that because of
forks end up playing multiple times the same step of a smart contract or of an MPC protocol).

We also discuss a concrete instantiation of our transform on a natural smart contract that
would be insecure in the presence of rushing players. Besides achieving security in case of forks,
the final protocol features an improved efficiency w.r.t. time to completion, at the price of a
small overhead in the communication complexity.

1.4 Related Work

Following [ADMM16], several other works focus on achieving fairness with penalties for different
applications of interest, including lotteries [BK14, BZ17], decentralized poker [KMB15, BKM17],
and general-purpose computation [BK14, KMS+16, KB16, KVV16]. In particular, the line of
works by Kumaresan et al. relies on an elegant paradigm working in two phases: During the
first phase, the players run an MPC protocol to obtain the output in hidden form (e.g., a
secret sharing of the output); since the output is hidden, such a protocol can be executed off
chain, as malicious aborts do not violate fairness. During the second phase, the output is then
reconstructed in a fair manner on chain.

Unfortunately, the security of this paradigm in the presence of rushing players is difficult
to assess, as it relies on intermediate ideal functionalities (such as the “claim-or-refund” and
“multi-lock” functionality [BK14, KB14]) that, while they can be implemented using Bitcoin or
Ethereum, offer a-priori no security guarantee in the presence of reset attacks due to blockchain
forks. Moreover, known results about designing protocols in a hybrid model that allows to make
calls to a functionality are applicable only to the classical setting where resets are not possible.
Also note that performing a large part of the computation off chain hinders one of the main
advantages of blockchain-aided MPC (i.e., public verifiability of the entire process). Our results,
in contrast, consider MPC protocols run completely on-chain through smart contracts.

A different line of works, shows how to perform MPC in the presence of an abstract transac-
tion ledger [KZZ16, GG17, BMTZ17, BGM+18, SSV19, CGJ19], of which Bitcoin and Ethereum
are possible implementations. However, such an idealized ledger does not account for the pos-
sibility of forks, thus (implicitly) meaning that the players using it are modeled as non-rushing.

5E.g., in oblivious transfer a malicious receiver by playing again his very first message would be allowed to
obtain both inputs of the sender.

4



2 Preliminaries

2.1 Notation

Given an integer n, we let [n] = {1, . . . , n}. If x is a string, we denote its length by |x|; if X is
a set, |X | is the number of elements in X . When x is chosen randomly in X , we write x←$ X .
When A is an algorithm, we write y←$ A(x) to denote a run of A on input x and output y; if
A is randomized, then y is a random variable and A(x;ω) denotes a run of A on input x and
random coins ω ∈ {0, 1}∗.

Throughout the paper, we denote the security parameter by Ν ∈ N. A function ν(Ν) is
negligible in Îť (or just negligible) if it decreases faster than the inverse of every polynomial in
Ν, i.e. ν(Ν) ∈ O(1/p(Ν)) for every positive polynomial p(¡). A machine is said to be probabilistic
polynomial time (PPT) if it is randomized, and its number of steps is polynomial in the security
parameter.

For a random variable X, we write P [X = x] for the probability that X takes a particular
value x in its domain. A distribution ensemble X = {X(Ν)}Ν∈N is an infinite sequence of random
variables indexed security parameter Ν ∈ N. Two distribution ensembles X = {X(Ν)}Ν∈N and
Y = {Y(λ)}λ∈N are said to be computationally indistinguishable, denoted X ≈c Y if for every
non-uniform PPT algorithm D there exists a negligible function ν(¡) such that:

|P [D(X(λ)) = 1]− P [D(Y(λ)) = 1]| ≤ ν(λ).

When the above equation holds for all (even unbounded) distinguishers D, we say that X and
Y are statistically close, denoted X ≈s Y.

2.2 Standard Primitives

Verifiable unpredictable functions. A verifiable unpredictable function (VUF) [MRV99]
is a tuple of polynomial-time algorithms (Gen,Eval,Prove,Ver) specified as follows. (i) The
randomized algorithm Gen takes as input the security parameter and outputs a secret key sk
together with a public verification key vk ; (ii) The deterministic algorithm Eval takes as input
the secret key sk and an input x within domain D, and outputs a value y belonging to some
range R; (iii) The deterministic algorithm Prove takes as input the secret key sk and an input
x ∈ D, and outputs a proof φ ∈ {0, 1}∗; (iv) The randomized algorithm Ver takes as an input
the verification key vk , an input/output pair (x, y), and a proof φ, and outputs a decision bit.
Correctness says that for sufficiently large Ν ∈ N, with overwhelming probability over the choice
of (sk , vk)←$ Gen(1λ), for all x ∈ {0, 1}` it holds that Ver(vk , x,Eval(sk , x),Prove(sk , x)) = 1.

As for security, we require two properties known as unique provability and unpredictability.

Definition 1 (Unique provability). We say that (Gen,Eval,Prove,Ver) satisfies unique prov-
ability if no values (vk , x, y0, y1, φ0, φ1) with y0 6= y1, even maliciously generated, can satisfy
Ver(vk , x, y0, φ0) = Ver(vk , x, y1, φ1). In words, for every string vk and every x ∈ D, there exists
at most one value y ∈ R for which there is an accepting proof.

Definition 2 (Unpredictability). We say that (Gen,Eval,Prove,Ver) satisfies computational
unpredictability if for all non-uniform valid PPT attackers A the following quantity is negligible:

P
[
Eval(sk , x) = y :

(vk , sk)←$ Gen(1λ)

(x, y)←$ AO(sk ,·)(vk)

]
,

where O(sk , ·) ≡ {Eval(sk , ·),Prove(sk , ·)}, and attacker A is called valid if it never queries x to
its oracles.

5



Verifiable unpredictable functions (a.k.a. unique signatures) exist based on a variety of as-
sumptions [BR96, MRV99, Lys02, Dod03, DY05, Jag15, HJ16, Bit17].

Commitment schemes. A non-interactive commitment Commit is a PPT algorithm taking
as input a message m ∈ {0, 1}`, and outputting a commitment γ = Commit(m; δ), where
δ ∈ {0, 1}∗ is the randomness used to generate the commitment. The pair (m, δ) is called the
opening.

Intuitively, a secure commitment satisfies two properties called binding and hiding. The first
property says that it is hard to open a commitment in two different ways. The second property
says that a commitment hides the underlying message.

Definition 3 (Binding). We say that a non-interactive commitment Commit is perfectly binding
if pairs (m0, δ0), (m1, δ1) such that m0 6= m1 and Commit(m0; δ0) = Commit(m1; δ1) do not exist.

Definition 4 (Hiding). We say that a non-interactive commitment Commit is computationally
hiding if for all non-uniform PPT adversaries A the following quantity is negligible∣∣∣P [ALR(0,¡,¡)(1Ν) = 1

]
− P

[
ALR(1,¡,¡)(1Ν) = 1

]∣∣∣ ,
where the oracle LR(b, ¡, ¡) with hard-wired b ∈ {0, 1} takes as input pairs of messages m0,m1 ∈
{0, 1}`, and outputs Commit(mb).

Non-interactive commitments satisfying the above properties can be obtained under the
assumption of injective one-way functions [GMW91].

Non-interactive zero knowledge. Let R be a relation, corresponding to an NP language
L. A non-interactive proof system for R is a tuple of efficient algorithms (Setup,Prove,Ver)
specified as follows. (i) The randomized algorithm Setup takes as input the security parameter
and outputs a common reference string σ; (ii) The randomized algorithm Prove(σ, (x,w)), given
a pair (x,w) s.t. R(x,w) = 1 outputs a proof φ; (iii) The deterministic algorithm Ver(σ, (x, φ)),
given an instance x and a proof φ outputs either 0 (for “reject”) or 1 (for “accept”). We say
that a NIZK for relation R is correct if for every Ν ∈ N, all σ as output by Setup(1Ν), and any
(x,w) s.t. R(x,w) = 1, we have that Ver(σ, (x,Prove(σ, (x,w)))) = 1.

We define two properties of a non-interactive proof system. The first property says that
honest proofs do not reveal anything beyond the fact that x ∈ L.

Definition 5 (Adaptive multi-theorem zero-knowledge [Gro06]). A non-interactive proof sys-
tem (Setup,Prove,Ver) for a relation R satisfies adaptive multi-theorem zero-knowledge if there
exists a PPT simulator ZKSim := (ZKSim0,ZKSim1) such that for all PPT non-uniform adver-
saries A the following quantity is negligible:∣∣∣P [AProve′(σ,·,·)(σ) = 1 : σ←$ Setup(1λ)

]
− P

[
AZKSim′1(ζ,·,·)(σ) = 1 : (σ, ζ)←$ ZKSim0(1

Îť)
] ∣∣∣,

where ZKSim′1(ζ, x, w) = ZKSim1(ζ, x) if R(x,w) = 1, and both oracles ZKSim′1 and Prove′

output ⊥ if R(x,w) = 0. Sometimes we call a non-interactive proof system satisfying adaptive
multi-theorem zero knowledge a NIZK proof system.

The second property states that knowledge soundness holds even if the adversary can see
simulated proofs for possibly false statements of its choice.

6



Definition 6 (Simulation extractability [Gro06]). A NIZK proof system (Setup,Prove,Ver) with
zero-knowledge simulator (ZKSim0,ZKSim1) for a relation R satisfies simulation extractability if
there exists a PPT algorithm KExt = (KExt0,KExt1) such that the output of KExt0 is identical to
that of ZKSim0 when restricted to the first two components, and moreover for every non-uniform
PPT adversary A the following quantity is negligible:

P

 Ver(σ, x∗, φ∗) = 1 ∧
(x∗, φ∗) 6∈ Q ∧
R(x∗, w∗) = 0

:

(σ, ζ, ξ)←$ KExt0(1
Îť)

(x∗, φ∗)←$ AZKSim1(ζ,·,·)(σ)
w∗←$ KExt1(ξ, x

∗, φ∗)

 ,
where Q is the list of all queries to oracle ZKSim1(Μ, ¡, ¡).

3 Parallel Coin Tossing

In this section we focus on blockchain-aided MPC for parallel coin tossing. Roughly, such
protocols allows a set of players to agree on a uniformly random string, and have many important
applications. (For instance, they trivially imply a fair lottery.) After recalling the lottery
protocol by Andrychowicz et al. [ADMM16], we show that this construction is not secure in
the presence of rushing players. We then propose a new protocol which achieves security in the
presence of rushing players, leveraging the power of smart contracts.

3.1 The Protocol of Andrychowicz et al.

Background on Bitcoin. In the Bitcoin ledger, each account is associated to a pair of keys
(pk , sk), where pk is the verification key of a signature scheme—representing the address of an
account—while sk is the corresponding secret key used to sign (the body of) the transactions.
Each block on the ledger contains a list of transactions, and new blocks are issued by an entity
called miner. The blockchain is maintained via a consensus mechanism based on the proof of
work (PoW) [DN92]; users willing to add a transaction to the ledger forward it to all the miners,
which will try to include it in the next minted block.

Due to the PoW consensus mechanism, each miner could have a different view of the ledger.
The common-prefix property [GKL15] roughly states that all the miners have the same view
of the blockchain up to a certain number k of blocks (before the last block); this guarantees
long-term consistency of the transactions in the ledger. Each view of the blockchain is called a
fork ; after k blocks, with high probability, one of these forks will be part of the common prefix.

We say that a transaction is valid if it is computed correctly (i.e., the signature is valid,
the coins have not been spent already, and so on) and that it is confirmed if it appears in
the common-prefix of all the miners (i.e., at least k blocks have passed). Each transaction Tx
contains the following information:

• A set of input transactions Tx1,Tx2, · · · from which the coins needed for the actual trans-
action Tx are taken;

• A set of input scripts containing the input for the output scripts of Tx1,Tx2, · · · ;
• An output script defining in which condition Tx can be claimed;
• The number of coins taken from the redeemed transactions;
• A time lock t specifying when Tx becomes valid (i.e., a time-locked transaction won’t be

accepted by the miners before time t has passed).

A transaction is called standard if its output script contains only the signature of the account’s
owner (i.e., it can be redeemed by the owner by simply signing it).

7



The protocol. The construction by [ADMM16] relies on a primitive called time-locked com-
mitment. Let n denote the number of parties. Each party Pj creates n− 1 Commitji 6=j transac-
tions containing a commitment to its lottery value. In particular, the output script of such a
transaction ensures that it can be claimed either by Pj via an Openji transaction exhibiting a
valid opening for the commitment, or by another transaction that is signed by both Pj and Pi.

Before posting these transactions on the ledger, Pj creates a time-locked transaction PayDepositji
redeeming Commitji , sends it off-chain to each Pi 6=j , and finally posts all the Commitji transac-
tions on the ledger. In case Pj does not open the commitment before time t, then each recipient

of a PayDepositji transaction can sign it and post it on the ledger; since time t has passed, the

miners will now accept the transaction as a valid transaction redeeming Commitji .
More in details, the protocol works as follows.

Deposit phase: Each player Pj computes a commitment yj = Hash(xj ||δj), where δj is some

randomness, sends off-chain the PayDepositji transactions (with time-lock t) to each Pi 6=j ,

and posts the Commitji transactions on the ledger.
Betting phase: Pj bets one coin in the form of a standard transaction PutMoneyj (redeeming a

previous transaction held by Pj , and with Pj ’s signature as output script). All the players
agree and sign off-chain a Compute transaction taking as input all the (PutMoneyj)j∈[n]
transactions, and then the last player that receives the Compute transaction posts it on the
ledger. In order to claim this transaction, a player Pw′ must exhibit the openings of the
commitments of all participants: The script checks that the openings are valid, computes
the index of the winner w (as a function of the values x1, . . . , xn), and checks that w′ = w
(i.e., the only participant that can claim the Compute transaction is the winner of the
lottery).

Compensation phase: After time t, in case some player Pj did not send all of its {Openji}i∈[n],i 6=j
transactions, all the other players Pi 6=j can post the PayDepositji transaction on the ledger,
thus obtaining at least a certain number of coins as compensation.

3.2 A Simple Attack

The main idea behind our attack is that, in the presence of rushing players, the protocol’s
messages can end-up on unconfirmed blocks. By looking at different forks, an attacker can try
to change an old unconfirmed transaction by re-posting it, with the hope that it will end-up on
a different fork and become part of the common prefix. This essentially corresponds to a reset
attack on the protocol.

The con";"""date"",""2019-08-02T12:29:14Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2019-08-02T12:29:14Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.19 (TeX Live 2018) kpathsea version 6.3.0""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2019-08-02T12:29:14Z""
""created"",""2019-08-02T12:29:14Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-08-02T12:29:14Z""
""resourceName"",""rush%20dilemma.pdf""
""Author"",""""
""producer"",""pdfTeX-1.40.19""
""pdf:docinfo:producer"",""pdfTeX-1.40.19""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""3"",""1"",""0"",""4"",""28"",""1"",""8"",""4"",""6"",""2"",""11"",""7"",""4"",""2"",""9"",""7"",""4"",""2"",""0"",""0"",""0"",""0"",""0"",""23"",""0"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2019-08-02T12:29:14Z""
""Last-Modified"",""2019-08-02T12:29:14Z""
""dcterms:modified"",""2019-08-02T12:29:14Z""
""title"",""""
""Last-Save-Date"",""2019-08-02T12:29:14Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2019-08-02T12:29:14Z""
""meta:save-date"",""2019-08-02T12:29:14Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.19 (TeX Live 2018) kpathsea version 6.3.0""
""Content-Length"",""545305""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""30""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""1981"",""1137"",""3193"",""3147"",""3460"",""3404"",""2631"",""2535"",""2706"",""3021"",""2972"",""3345"",""2480"",""3148"",""2655"",""3577"",""2576"",""2642"",""2702"",""2809"",""2702"",""2233"",""2856"",""2425"",""2060"",""2225"",""3035"",""2333"",""1883"",""2318""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-08-02T12:29:14Z""
";https://scholar.google.com/scholar?start=870&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094537-637;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;A decentralized social networking architecture enhanced by blockchain;S Zeng, Y Yuan, FY Wang ; 2019 IEEE International …, 2019  ieeexplore.ieee.org;;"… It is the underlying technology of Bitcoin, the first implementation of cryptocurrency … data from

the database, the correlative hash values can be gained from the blockchain to verify … by Micali,

Rabin, and Vadhan, are used to generator verifiable pseudo-random oracles for miners …";Autres articles;;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/8945268/8954999/08955104.pdf?casa_token=19RbnbdniaYAAAAA:r6QIWoCUA6W7VPoZhbP_TdlqbzchyCh14kr1APwCnKRZuYtaYUaNPRfd5mIi4wk62fSLY6lJnhI;"
		Skip to Main Content


		
			
				
				

				

			

		


		
			
				
					
						








	
		
	

	







						

						





























	
	
		
	
	
		
			

		
	

	
	
	



						





	
	
		
			
				IEEE Account

					Change Username/Password
	Update Address


			

			
				Purchase Details

					Payment Options
	Order History
	View Purchased Documents


			

			
				Profile Information

					Communications Preferences
	Profession and Education
	Technical Interests


			

			
				Need Help?

					US & Canada: +1 800 678 4333
	Worldwide:  +1 732 981 0060

					
	Contact & Support


			

		

		
			
				
					
							About IEEE Xplore
	Contact Us
	Help
	Accessibility
	Terms of Use
	Nondiscrimination Policy
	Sitemap
	Privacy & Opting Out of Cookies


						
							A not-for-profit organization, IEEE is the world's largest technical professional organization dedicated to advancing technology for the benefit of humanity.
Š Copyright 2021 IEEE - All rights reserved. Use of this web site signifies your agreement to the terms and conditions.
						

					


					

				

				
			

		

	


	
	


						
						






		
		
		
		
		
		
		
		
		
		
		
		
		
			
				
			
			
			
			
		
		
		
		
		
		

			


			

			
			


		
 		
		
			 

						
						









































	

		
		

		
		
		

		
			
		
		
		

		

		
		


		

		
		
		
		
		
		
		
		
		
		
	
	


















		
		
			
				
					
					
								
					
								
			
				
					
					
								
					
								
			
				
					
						








 



					
					
								
			
				
					
					
								
			
				
					
					
								
					
								
			
				
					
					
								
					
								
			
				
					
					
								
					
								
			
				
					
					
								
					
								
			
				
					
					
								
					
								
			
				
					
					
								
					
								
			
		
	




























		
			
					
			
					
			
					
			
				
					








					
			
					
			
					
			
					
			
					
			
					
			
					
			
		
		
	





	
	
	
	
	
	
	


	
	
	

	

















					

				

			


			
				
			
		

	";"""og:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""twitter:title"",""A decentralized social networking architecture enhanced by blockchain""
""twitter:card"",""summary""
""Description"",""The privacy issues become a major problem that should be resolved for the existing centralized online social networks, which have prompted researchers to consid""
""og:title"",""A decentralized social networking architecture enhanced by blockchain""
""resourceName"",""08955104.pdf""
""language"",""en""
""title"",""A decentralized social networking architecture enhanced by blockchain | IEEE Conference Publication | IEEE Xplore""
""og:description"",""The privacy issues become a major problem that should be resolved for the existing centralized online social networks, which have prompted researchers to consider the decentralization framework for online social networks. In this paper, we propose a novel decentralized social networking architecture enhanced by blockchain technology. We use a sharding framework to increase the system scalability, a blockchain system to ensure the data integrity and consistency, a reputation-based authority control method to improve the system security.""
""twitter:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-UA-Compatible"",""IE=Edge""
""viewport"",""width=device-width, initial-scale=1.0""
""dc:title"",""A decentralized social networking architecture enhanced by blockchain | IEEE Conference Publication | IEEE Xplore""
""twitter:description"",""The privacy issues become a major problem that should be resolved for the existing centralized online social networks, which have prompted researchers to consider the decentralization framework for online social networks. In this paper, we propose a novel decentralized social networking architecture enhanced by blockchain technology. We use a sharding framework to increase the system scalability, a blockchain system to ensure the data integrity and consistency, a reputation-based authority control method to improve the system security.""
""Content-Encoding"",""UTF-8""
""Content-Type-Hint"",""text/html; charset=utf-8""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=450&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094644-1092;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Continuous space-bounded non-malleable codes from stronger proofs-of-space;B Chen, Y Chen, K Hostáková, P Mukherjee ; Annual International …, 2019  Springer;;"… In addition, we show that the graph construction used as a building block for the

proof-of-space by Dziembowski et al. (CRYPTO 2015) satisfies challenge-hardness as well …

Oracles. Next we define space-bounded tampering oracle with self-destruct …";Cité 4 fois;Les 2 versions;[PDF] iacr.org;https://eprint.iacr.org/2019/552.pdf;"
An abridged version of this paper appears in the proceedings of the 39th International Cryptology
Conference—CRYPTO 2019. This is the full version.

Continuous Space-Bounded Non-Malleable Codes from
Stronger Proofs-of-Space

Binyi Chen∗1, Yilei Chen2, Kristina Hostáková†3, and Pratyay Mukherjee4

1University of California, Santa Barbara, binyichen@cs.ucsb.edu
2Visa Research, yilchen@visa.com

3TU Darmstadt, kristina.hostakova@cs.tu-darmstadt.de
4Visa Research, pratmukh@visa.com

Abstract
Non-malleable codes are encoding schemes that provide protections against various classes

of tampering attacks. Recently Faust et al. (CRYPTO 2017) initiated the study of space-
bounded non-malleable codes that provide such protections against tampering within small-
space devices. They put forward a construction based on any non-interactive proof-of-space
(NIPoS). However, the scheme only protects against an a priori bounded number of tam-
pering attacks.

We construct non-malleable codes that are resilient to an unbounded polynomial number
of space-bounded tamperings. Towards that we introduce a stronger variant of NIPoS called
proof-extractable NIPoS (PExt-NIPoS), and propose two approaches of constructing such a
primitive. Using a new proof strategy we show that the generic encoding scheme of Faust et
al. achieves unbounded tamper-resilience when instantiated with a PExt-NIPoS. We show
two methods to construct PExt-NIPoS:

1. The first method uses a special family of “memory-hard” graphs, called challenge-hard
graphs (CHG), a notion we introduce here. We instantiate such family of graphs based
on an extension of stack of localized expanders (first used by Ren and Devadas in
the context of proof-of-space). In addition, we show that the graph construction used
as a building block for the proof-of-space by Dziembowski et al. (CRYPTO 2015)
satisfies challenge-hardness as well. These two CHG-instantiations lead to continuous
space-bounded NMC with different features in the random oracle model.

2. Our second instantiation relies on a new measurable property, called uniqueness of
NIPoS. We show that standard extractability can be upgraded to proof-extractability
if the NIPoS also has uniqueness. We propose a simple heuristic construction of NIPoS,
that achieves (partial) uniqueness, based on a candidate memory-hard function in the
standard model and a publicly verifiable computation with small-space verification. In-
stantiating the encoding scheme of Faust et al. with this NIPoS, we obtain a continuous
space-bounded NMC that supports the “most practical” parameters, complementing
the provably secure but “relatively impractical” CHG-based constructions. Addition-
ally, we revisit the construction of Faust et al. and observe that due to the lack of
uniqueness of their NIPoS, the resulting encoding schemes yield “highly impractical”
parameters in the continuous setting.

We conclude the paper with a comparative study of all our non-malleable code construc-
tions with an estimation of concrete parameters.

∗Research conducted at Visa Research.
†Research conducted at Visa Research.



Contents

1 Introduction 1
1.1 Our Work . . . . . . . . . . . . . 2
1.2 Summary of our Contributions . 4
1.3 Technical Overview . . . . . . . . 5

2 Related Works 7

3 Preliminaries 8
3.1 Notation . . . . . . . . . . . . . . 8
3.2 Basic Definitions . . . . . . . . . 8
3.3 Bounded Algorithms . . . . . . . 9
3.4 Random Oracles . . . . . . . . . 10

4 Continuous Space-bounded Tam-
pering 10

5 Non-Interactive Proof of Space
(NIPoS) 12

6 Space-bounded NMC from Proof-
Extractable NIPoS 15

7 Constructing Proof-Extractable
NIPoS from CHG 19
7.1 Merkle Commitments . . . . . . 19
7.2 Graph Pebbling and Labeling . . 19
7.3 Challenge-Hard Graphs (CHG) . 22

7.4 Construction of PExt-NIPoS
from CHG . . . . . . . . . . . . . 24

7.5 Instantiating CHG . . . . . . . . 27
7.6 A comparison of the two CHG

constructions . . . . . . . . . . . 30
7.7 Instantiations of PExt-NIPoS

from CHGs . . . . . . . . . . . . 30

8 PExt-NIPoS from Memory-Hard
Functions 32
8.1 Memory-hard Functions . . . . . 32
8.2 Publicly verifiable computation . 32
8.3 Partially-unique Ext-NIPoS

from MHF and VC . . . . . . . . 33
8.4 Instantiating MHF . . . . . . . . 35
8.5 Instantiating VC . . . . . . . . . 37
8.6 Instantiating partially unique

NIPoS and PExt-NIPoS . . . . . 38

9 Instantiating and comparing our
NMC constructions 39
9.1 Instantiations from different

PExt-NIPoS . . . . . . . . . . . . 39
9.2 Comparing concrete parameters . 40

A Proof of Theorem 1 47

B Proof of Theorem 2 49



1 Introduction

Non-malleable codes and tamper-resilience. The notion of non-malleable codes (NMC)
was put forward by Dziembowski, Pietrzak and Wichs [DPW10] as an abstract tool for protect-
ing cryptographic devices against tampering attacks (e.g. [BDL01]). Intuitively, an encoding
scheme (Encode,Decode) is called non-malleable with respect to a class of tampering adversaries
(modeled as functions or algorithms) A if for any adversary A ∈ A and any message x, the output
Decode◦A◦Encode(x) is independent of x, unless it is equal to x. It is straightforward to see that
A can not contain all efficiently computable functions because in that case it is always possible
to just decode a codeword c to x, modify (for example add 1) and re-encode x + 1; hence one
must consider a restricted class A which excludes functions able to encode or decode. Therefore,
the NMC literature (for example [LL12, FMNV14, AAG+16, DLSZ15, FMNV15, JW15, ADL14,
CG14]) focuses on constructing encoding schemes that are non-malleable against a meaningful,
broad class of tampering functions; notice that non-malleability against a broader A translates
to protection against stronger tampering attacks.

Leaky NMC for space-bounded tampering. One such interesting tampering class is space-
bounded tampering, in that the only restriction on A is that any (efficient) tampering algorithm
in this class can only use a limited amount of memory. Space-bounded tampering captures the
essence of mauling attacks performed by malware that infect small-space devices like mobile
phones. However, as noticed by Faust et al. [FHMV17a] (henceforth FHMV), for such tamper-
ing class it is unreasonable to assume that a tampering algorithm can not decode. For example,
if decoding requires more space than what is available for the attacker, then the encoded se-
cret becomes unusable inside the device. The encoding algorithm, on the other hand, can be
reasonably space-intense and performed outside the device. Therefore, it is possible to assume
the space-bounded adversary cannot perform encoding, therefore avoiding the aforementioned
impossibility.

Moreover, even if A includes only Decode, “full-fledged” non-malleability is still not achiev-
able. To see this, consider an attacker that decodes c, learns the message x and based on the
first bit of x overwrites the memory of the device with a precomputed encoding — leaking the
first bit (this can be easily extended to an attack that leaks any log(|x|) bits by tampering
once). However, Faust et al. [FHMV17a] observed that all hope may not be lost if it is possi-
ble to guarantee that the leakage is “not too much”. Formally FHMV defines a weaker notion
called leaky non-malleability, which guarantees that an encoding scheme satisfying the notion
would leak only a limited amount of information about x. FHMV also showed that this is suf-
ficient for many applications. For example, they showed how one can use such leaky NMC by
trading-off tampering with leakage when x comes from a high-entropy distribution (see Section 7
of [FHMV17b] for more details).

Continuous space-bounded tampering. Traditional NMC (as defined in [DPW10]) guar-
antees non-malleability when the attacker tampers only once. To use such NMC for tamper-
resilience (see [DPW10] for more details), one needs to refresh the encoding after each tamper-
ing. To combat this issue, in 2014, Faust et al. [FMNV14] proposes the notion of continuous
non-malleable codes that tolerates an unbounded number of tampering attempts, which conse-
quently removes the necessity of re-encoding in the tampering application. Though FHMV’s
definition of (leaky) non-malleability allows continuous tampering, their construction (see The-
orem 3 of [FHMV17b]) only allows an a priori bounded number of tampering attempts (say θ)
because their parameters are related in a way that the leakage (say, `) is directly proportional
to θ. Hence, after a few tampering attempts, the leakage becomes as large as |x|. Coming up

1



with a construction that tolerates an unbounded (polynomially large) θ was left open in FHMV
(see Remark 2 of [FHMV17b]).

1.1 Our Work

Leaky NMC for continuous space-bounded tampering. In this work we address the
open problem by proposing various constructions of non-malleable codes, in all of which the
leakage ` is proportional to the logarithm of the number of tamperings, i.e. log(θ).1 No prior
bound is required for θ in this case. However, we do not claim that our solutions are strictly
stronger than that provided in FHMV, because we assume a “self-destruct” mechanism similar
to the prior works on continuous non-malleability (e.g. [FMNV14]). Roughly speaking, the
“self-destruct” mechanism requires the small-space device to erase its entire state (or make it
non-functional) once a tampering is detected. As already shown by FHMV, this is a necessary
requirement for achieving unbounded continuous space-bounded tampering.

Our approach: Stronger non-interactive proof-of-space. FHMV’s encoding scheme re-
lies on any extractable non-interactive proof of space (simply called NIPoS)2. In contrast, we
introduce a new and stronger property of NIPoS called proof-extractability and prove that when
FHMV’s encoding scheme is instantiated with a proof-extractable NIPoS (PExt-NIPoS), then
we obtain a continuous space-bounded NMC (CSNMC). We take two different approaches to
construct PExt-NIPoS — in the following few paragraphs we choose to outline them through
the natural flow of our attempts, instead of dividing strictly into two distinct approaches.

Proof-extractability from any NIPoS with uniqueness. Our starting point is the con-
struction of FHMV [FHMV17a] which is based on any NIPoS. We show that any NIPoS can be
upgraded to a PExt-NIPoS if it has a special property called uniqueness, which we define as a
quantitative measure of a NIPoS. We notice that the parameters of the resulting PExt-NIPoS
(and consequently the CSNMC scheme yielded via FHMV’s generic construction) is directly re-
lated to the uniqueness parameter of the starting NIPoS. For example, if a NIPoS has “maximal
uniqueness”, then the resulting CSNMC incurs “minimal leakage”, which is equal to p− |c| bits,
where p is the available (persistent) space.3 Unfortunately, we do not know of a provably secure
NIPoS construction with maximal, or even a “reasonably good measure” of uniqueness (later
we propose a construction that satisfies partial uniqueness based on heuristic assumptions). In
fact, we show that the NIPoS used in FHMV (which is in turn based on the PoS proposed by
Ren and Devadas in [RD16]) has poor uniqueness parameters and thus, when adapted to our
proof-extractability technique, yields a CSNMC which suffers from a leakage that is as large as
≈ p− |x|.

Modeling space-bounded adversary with bounded description. The lack of a NIPoS
with “good uniqueness” drives us to revisit the adversarial model of FHMV, in particular, how

1In the rest of the paper whenever we say that an encoding scheme satisfies continuous space-bounded non-
malleability or is a CSNMC, we mean that the encoding scheme is a leaky NMC for space-bounded tampering
with ` ∝ log(θ).

2In this section by NIPoS we informally refer to a (non-interactive) proof-of-space with extractability. Later
while treating formally we also say phrases like “extractable NIPoS” or “NIPoS has extractability” explicitly and
sometimes also use the abbreviation like Ext-NIPoS for that — but in general a NIPoS is assumed to have implicit
extractability.

3We assume that the entire space in the device is split into two parts, the persistent space which is reusable,
and the transient space which is refreshed after each tampering. An impossibility shown in FHMV (see Theorem 1
of [FHMV17b]) restricts the persistent space to remain relatively small when θ is unbounded.

2



they formalize the notion of space. In FHMV, which in turn follows the notion introduced
by Dziembowski et al. [DKW11b], the adversary is separated into two parts: a “big adversary”
which is a PPT adversary with no space-bound, and a “small adversary” that is a space-bounded
poly-time adversary. In a security game, the big adversary starts interacting with the challenger,
and then outputs small adversaries which will then have access to the target codeword (or the
proof, in case of NIPoS) and execute tampering in a space-bounded manner.

We notice that FHMV assumes that the small adversary can have arbitrary amount of
auxiliary information hardcoded in its description (see Page-5 of [FHMV17b]). In reality this
seems to be an overkill, because if the small adversary (e.g. malware) has a huge description, it
might not even fit into a small-space device (e.g. a mobile device), let alone executing tampering.
So, it is reasonable to assume that such adversary has a bounded size description. In particular,
we define a class of space-bounded adversaries as As,fspace containing all poly-time adversaries that
have a description of size at most f -bit and which require at most s-bit to execute.

PExt-NIPoS from Challenge-hard Graphs (CHG). We define a new family of “memory-
hard graphs” called challenge-hard-graphs and construct PExt-NIPoS for the class of space-
bounded adversaries As,fspace from that. We provide two instantiations of CHG: (i) The first one
extends the stack of local expanders (SoLEG), used by Ren and Devadas [RD16] in the context of
proof-of-space. We uses a novel technique to connect a gadget with a standard SoLEG in order to
amplify crucial challenge-hardness parameters. This technique may be of independent interest.
(ii) The second one uses the graph designed by Paul et al. [PTC76] and used by Dziembowski et
al. [DFKP15], who use the notion of challenge-hardness implicitly to construct proof-of-space.
Both of the constructions use standard graph-pebbling techniques to ensure memory-hardness
(and challenge-hardness) and work in the random oracle model. Plugging-in these PExt-NIPoS
constructions into FHMV’s encoding scheme, we obtain CSNMC schemes with “almost minimal
leakage” ` ≈ p− |c|.

A NIPoS with partial uniqueness based on heuristics. The constructions mentioned
above all come with rigorous security proofs (in the random oracle model). However, it turns
out that in order to achieve reasonable security, the concrete parameters of these constructions
are fairly impractical (see Section 9 for a detail analysis). For example, for a message of size
1 MB, the size of a codeword is almost 800 MB for the CHG-based NMC constructions (see Ta-
ble 2). To complement this, we take a step back on our initial idea of constructing NIPoS with
“good uniqueness”, and propose a simple and practical instantiation of NIPoS based on heuristic
assumptions. The construction uses a concrete instantiation of a memory-hard-function (MHF),
and applies a (non-interactive) publicly verifiable computation where the verification requires
small space. When the MHF is instantiated with the SoLEG-based construction of Ren and
Devadas [RD16], the resulting NIPoS has extractability and a “good measure of uniqueness”.
This yields a PExt-NIPoS with very good parameters and, consequently, plugging-in that to
FHMV’s encoding scheme we obtain a CSNMC with very small proof size (in killobytes), that
also allows a leakage, as small as p− 0.99|c|, in certain settings.

While the above scheme is practical, it is not provably secure, since we can not assume that
the hash-functions within the MHF are random oracles, as the prover needs to access the circuit
of the MHF to produce a proof of computation.4 Note that any MHF, while used in practice
with concrete hash functions (for example SHA3) for important practical applications [Tar],
provides provable guarantees only in the random oracle model (see, e.g. [ACP+17]). Instead, we

4This is similar in spirit to the works (e.g., [CGM16b, DFKP16]) that use zero-knowledge proofs of full-
domain-hash signatures — security of such signatures only holds in the random oracle model, while one needs to
have a concrete instantiation before applying zero-knowledge proofs.

3



Approach PExt-NIPoS type Assumptions Leakage Size of A

CHG SoLEG-based RO ≈ p− |c| Bounded
PTC-based RO ≈ p− |c| Bounded

Uniqueness FHMV-based RO ≈ p− |x| Unbounded poly
MHF-based Heuristic ≈ p− 0.99|c| Unbounded poly

Table 1: Among the above constructions, the MHF-based one is the most practical one whereas
the SoLEG-based one has the best concrete parameters among the provably-secure constructions.
For a detail comparison of the concrete parameters please see Table 2 in Section 9.

rely on heuristic assumptions that intuitively state that the MHF remains memory-hard when
the random oracle is instantiated with a standard hash function like SHA3.

Roadmap. We summarize our contributions below in Section 1.2. In Section 1.3 we provide
an elaborative technical overview. Then, after providing preliminaries in Section 3 and basic
definitions of Continuous Space-bounded Tampering in Section 4, we define the new NIPoS
properties (uniqueness and proof-extractability) in Section 5 where we also discuss their relations.
In Section 6, we show that the FHMV’s encoding scheme satisfies continuous space-bounded non-
malleability when instantiated with PExt-NIPoS. Section 7 introduces the notion of challenge-
hard-graphs and shows how to use them to construct PExt-NIPoS. We provide a heuristic
construction of NIPoS with (partial) uniqueness relying on memory-hard functions in Section 8
and finally in Section 9, we conclude with a instantiations and comparison of the important
concrete parameters of different encoding schemes we constructed.

1.2 Summary of our Contributions

Our overall contributions can be summarized as follows:

• We propose the first constructions of continuous space-bounded (leaky) non-malleable
codes (with a necessary “self-destruct” mechanism) and thus resolve an open problem
posed by FHMV [FHMV17a]. Overall we propose four different constructions of different
merits; we provide a comparison in Table 1:

• We introduce various abstract notions of NIPoS, like proof-extractability and uniqueness,
and show relations among them. The abstractions are targeted towards constructing
CSNMC as the main end goal, but may be of independent interests. We prove that
the FHMV encoding scheme is a CSNMC when instantiated with any PExt-NIPoS.

• We propose different techniques to construct a PExt-NIPoS. We introduce the notion
of challenge-hard graphs and show how to build PExt-NIPoS from that. We propose a
novel technique to bootstrap the important challenge-hardness parameters of a CHG by
carefully connecting a gadget to a special type of memory-hard graphs (SoLEG). Further-
more, we provide a simple construction of partially unique NIPoS that yields “reasonably
practical” parameters for the resulting PExt-NIPoS and CSNMC. It is based on heuristic
assumptions on memory-hard functions and complements the provably secure but “rela-
tively impractical” CHG-based constructions.

• Finally we provide a comparative study of the most important parameters of all our
CSNMC constructions with respect to concrete instantiations. This helps us to under-
stand the practical impacts of different techniques and constructions proposed in this
work.

4



1.3 Technical Overview

Revisiting FHMV’s construction. We start by briefly revisiting the construction of FHMV
[FHMV17a]. Recall that FHMV’s generic encoding scheme is based on any extractable (non-
interactive) proof-of-space (NIPoS).

First let us briefly recall the notion of proof-of-space introduced in [ABFG14, DFKP15].
In an interactive proof-of-space (PoS) protocol, a prover P interactively proves that she has
“sufficient amount of space/memory” to a space-bounded verifier V. One can use Fiat-Shamir
transformation [FS87] to make it non-interactive, in that the entire proof can be represented
as one single string, say πid , with respect to an identity id . The verifier is able to verify the
pair (id , πid ) within bounded space. Extractability of NIPoS guarantees that: given an honestly
generated pair (id , πid ), if a space-bounded “small adversary” A is able to compute another valid
(i.e. correctly verified) pair (id ′, πid ′) such that id 6= id ′, then id ′ can be efficiently extracted
from the RO queries made by the “big adversary” B (that has no space-restriction and may be
represented by a PPT algorithm) given a “small hint”5.

Given a NIPoS, FHMV’s encoding scheme works as follows. On input a message x, the
space-intense encoding algorithm runs the prover of NIPoS on an identity x to generate a proof
πx. The codeword c is simply the pair (x, πx). The space-bounded decoding algorithm, on
receiving c = (x, πx), runs the (space-bounded) verifier. If the verification passes, it returns x,
otherwise it returns ⊥ denoting the invalidity of c. Intuitively, non-malleability follows from
the guarantee provided by NIPoS; namely, whenever the small adversary tampers to a valid
codeword (x′, πx′), the new message x′ must be independent of the input message x.

To be slightly more formal, to show that this encoding scheme is non-malleable against space-
bounded attacker, one needs to simulate the tampering experiment with “a small leakage” on
x. Given the extractability, the simulator can be constructed as follows: the leakage is obtained
using the “small hint”. As guaranteed by the extractability of NIPoS, since the “small hint” (of
length η, say) is sufficient to extract id ′, each tampering can be simulated by first obtaining the
hint as a leakage and then running the NIPoS-extractor to obtain id ′. Clearly, this strategy runs
into problem for unbounded continuous tampering as the overall leakage ` becomes proportional
to θ ¡ Ρ (where θ denotes the number of tampering queries).

Proof-extractability to the recovery. The above discussion shows that we possibly need a
stronger guarantee from the underlying NIPoS to make FHMV’s encoding scheme a CSNMC. To-
wards that, we introduce a stronger property of a NIPoS called proof-extractability (PExt-NIPoS).
It guarantees that, given a “small hint” (of length η′, say), it is possible to construct a stronger
extractor that extracts not only the changed identity, but also the changed proof: (id ′, πid ′).
Intuitively, this means that if a small adversary computes a valid pair (id ′, πid ′), then the “big
adversary” must have computed the entire proof πid ′ (as opposed to a part of the proof as for
NIPoS) outside the small-space device; hence, enabling extracting the entire proof from the RO
queries made by B only.

Given the proof-extractor, the new NMC simulator works as follows: it uses the hint to get a
“small leakage” and then runs the proof-extractor to obtain (id ′, πid ′). Furthermore, the simula-
tor also needs an extra leakage, which consists of the “extra persistent space” (of size p− n)6 —
now the simulator reconstructs the entire persistent tampered state and can continue the rest of

5Note that we made some syntactical change to FHMV’s definition of extractability by introducing an explicit
hint-producing function. We introduce the length of the hint as a new extractability parameter which must be
small for making the definition meaningful. For example, if the leakage function leaks the entire pair (id ′, π′id),
then the definition would be trivially satisfied. Looking ahead, in the proof of CSNMC this hint will be used by
the NMC simulator as a leakage to simulate the tampering experiment. For more details we refer to Section 5.

6As discussed in Remark 3, this leakage is necessary in most of the natural settings.

5



the tampering experiment without having to make any further leakage query. However, to avoid
any leakage before the first tampering takes place (for example, if the first 100 tampering func-
tions are identities), the simulator needs to know the index when the target codeword changes
for the first time in the sequence of tampering and for that the leakage becomes proportional
to log(θ). Overall, the simulator only needs to make a constant number of leakage queries (two,
to be precise) to simulate any (polynomial) number of tampering, as opposed to making one
leakage query for each tampering. The overall leakage becomes ` ∝ log(θ) + η′+ (p−n) thereby
achieving CSNMC. Therefore, the main question that remains is how to construct PExt-NIPoS,
which will be described in the next few paragraphs.

Uniqueness and Proof-extractability. We observe that, if a NIPoS has a special property,
called uniqueness, then it satisfies proof-extractability. Intuitively, uniqueness means for a fixed
identity id , there exists exactly one string πid such that πid verifies correctly with respect to
id . Unfortunately, we do not know how to construct a NIPoS with such property (even under
heuristic assumptions). Therefore, to have a more relaxed and fine-grained notion, we define
uniqueness as a quantitative measure: a NIPoS has upos-uniqueness means that, for any identity
id , the first upos bits of any valid πid are fixed and can be computed efficiently with overwhelming
probability.

We then show (in Lemma 2) that any upos-unique NIPoS satisfies proof-extractability, where
the size η′ of the hint required for PExt-NIPoS depends on upos as: η′ = η + npos − upos, where
Ρ denotes the size of the hint of the starting NIPoS and npos denotes the size of the proof.
This follows naturally from the construction of the hint-producing function of PExt-NIPoS, as
the hint for the proof extractor needs to contain enough information to extract both id ′ and
πid ′ . Now id ′ can be extracted from the hint produced via the starting NIPoS (by standard
extractability); given id ′ the proof-extractor can compute the first upos bits of πid ′ ; but the
remaining part, which has length npos − upos, must be separately output by the hint-producing
function of PExt-NIPoS. Notice that, maximal uniqueness means upos = npos which in turn
implies η′ = η. Hence, if FHMV’s encoding scheme is instantiated with a maximally unique
NIPoS, part of the leakage of the resulting CSNMC would be determined by only Ρ and hence
would be minimal. We leave the task of constructing a maximally unique NIPoS as an interesting
open problem. On the other hand, we observe that the NIPoS considered by FHMV has upos ≈ 0
and hence the leakage is largely dominated by Ρ + npos, resulting in much worse parameters.

Partially unique-NIPoS from memory-hard functions. We are able to construct an
NIPoS with reasonably large upos from heuristic assumptions on memory-hard functions. The
construction is very simple: let M be a concrete instantiation of a memory-hard function, which
guarantees that any space-bounded adversary can not compute the function on a randomly
chosen input in polynomial time. Let us assume a verifiable computation scheme (VC) where
the verification can be done in small-space. Then the NIPoS prover works as follows: given an
identity id , first compute a hash (that is assumed to be a random oracle) to generate a random
value x := H(id), then compute y := M(x) and finally run the VC prover to produce a proof
πvc to prove that y is indeed obtained by computing M(x). The proof-of-space is then defined
to be the pair (M(x), πvc). The NIPoS verifier works naturally by first computing x = H(id)
and then verifying the proof πvc in small-space.

To see that the construction above yields a NIPoS with good uniqueness, first note that the
extractability follows from the fact that the functionM is memory-hard and can not be computed
on a random input by a space-bounded “small adversary”; hence, the “big adversary” must have
queried on id ′ beforehand enabling extraction of id ′ from B’s RO queries. Note that here we
also need to rely on the soundness of VC as otherwise the small adversary could just compute

6



a different “memory-easy” function and “fake” the proof of computation to fool the verifier.
Moreover, note that, the first part of the NIPoS proof is indeed uniquely determined (with
overwhelming probability any other string would fail to verify as guaranteed by the soundness
of the VC scheme), whereas the second part, i.e. the proof πvc, is not. So, overall we have a
NIPoS with upos = |y|. Since the VC produces a short proof to enable small-space verification
(we use Pinocchio [PHGR13] to instantiate), we are able to have a NIPoS with fairly large upos,
which in turn leads to a CSNMC with very good parameters.

PExt-NIPoS from Challenge-hard graphs (CHG). In addition to the heuristic construc-
tion above, we also construct a provably secure PExt-NIPoS in the random oracle model, albeit
with an additional restriction on the class of space-bounded adversaries, namely assuming that
the description size of a small-space adversary is also bounded (as discussed in Section 1.1).

To do so, we define a new notion of memory-hard graphs, called challenge-hard graphs
(CHG). Recall that, special types of DAGs are used for memory-hardness and for constructing
proof-of-space via graph-labeling games. Usually, labels are the output of the hash functions
modeled as random oracles (therefore are not “compressible”). In a graph-based proof of space
constructions (e.g. [RD16]), an honest prover computes the labeling of the entire graph ensuring
the usage of significant amount of space. Small-space verification is done by checking the labels
of a few randomly selected nodes (or challenge nodes) of the graph — this guarantees that the
“small adversary” cannot put too many fake labelings (a.k.a. faults) without storing them and
thereby ending up using less memory.

However, such verification leaves room for computing a small part of the proof inside the
small-space device — for example, consider a multi-layered DAG (e.g. a stack of bipartite
graphs), for which a “big adversary” computes the labeling of the entire graph except for a single
node in the last layer, and the “small adversary” easily computes the label of the node inside the
small-space device. As a result the entire proof can not be extracted only from B’s RO queries,
making proof-extractability impossible.

To remedy this issue, we replace the traditional memory hard graphs with CHG, which
contains another carefully chosen set of challenges and guarantees that, even if a “big adversary”
computes the labeling of the entire graph except for a few nodes and send a bounded hint to the
“small adversary”, it is still infeasible to compute the labels of the new challenge nodes with a
small-space device. Let us remark that such a guarantee is only possible when the small adversary
has a small description size (i.e., the hint from the “big adversary” is small), as otherwise the small
adversary, for example, can hard-code the entire labeling for whole graph including all possible
challenges, making challenge hardness impossible. As discussed in Section 1.1, we propose two
instantiations of CHGs with different merits with respect to their parameters.

2 Related Works

Our work can be categorized among the work on non-malleable codes against global tampering,
where the entire codeword is subject to tampering, as opposed to granular tampering, where
the codeword is split into independently tamperable parts. In the NMC literature, majority
of work, e.g. [LL12, GPR16, ADL14, AAG+16, CG14, KOS18, KOS17, CGM+16a] falls into
the the later category; among them [CGM+16a] considers, a weaker notion (non-malleability
with replacement) of NMC like us (leaky-NMC). A few other works, e.g. [FMVW14, AGM+15,
BDKM16, BDKM18] consider global tampering. Moreover, most of these work consider one-time
tampering. Continuous tampering, first proposed in [FMNV14], is addressed also in [FNSV18,
ADN+1";"""date"",""2019-05-23T21:23:27Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2019-05-23T21:23:27Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.19 (TeX Live 2018) kpathsea version 6.3.0""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2019-05-23T21:23:27Z""
""created"",""2019-05-23T21:23:27Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-05-23T21:23:27Z""
""resourceName"",""552.pdf""
""Author"",""""
""producer"",""pdfTeX-1.40.19""
""pdf:docinfo:producer"",""pdfTeX-1.40.19""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""1"",""2"",""1"",""0"",""21"",""12"",""0"",""0"",""4"",""0"",""14"",""14"",""4"",""2"",""27"",""10"",""20"",""32"",""4"",""11"",""3"",""2"",""2"",""2"",""16"",""6"",""3"",""3"",""6"",""0"",""2"",""0"",""8"",""2"",""3"",""4"",""10"",""10"",""3"",""12"",""4"",""0"",""0"",""0"",""0"",""0"",""35"",""26"",""39"",""16"",""17"",""14"",""38"",""34"",""22"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2019-05-23T21:23:27Z""
""Last-Modified"",""2019-05-23T21:23:27Z""
""dcterms:modified"",""2019-05-23T21:23:27Z""
""title"",""""
""Last-Save-Date"",""2019-05-23T21:23:27Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2019-05-23T21:23:27Z""
""meta:save-date"",""2019-05-23T21:23:27Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.19 (TeX Live 2018) kpathsea version 6.3.0""
""Content-Length"",""970637""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""58""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""2668"",""1109"",""3368"",""3232"",""3582"",""2697"",""3611"",""3477"",""3396"",""2610"",""2866"",""3001"",""2257"",""2924"",""1759"",""2587"",""2534"",""2577"",""3432"",""2133"",""2668"",""1741"",""2706"",""2741"",""2631"",""2373"",""1867"",""2213"",""2679"",""1591"",""2209"",""2714"",""1891"",""2599"",""2198"",""2266"",""2444"",""2879"",""2867"",""2739"",""2494"",""2606"",""2532"",""2644"",""2530"",""2728"",""2562"",""1129"",""1622"",""1870"",""2298"",""2642"",""2315"",""2264"",""2309"",""1798"",""2199"",""764""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-05-23T21:23:27Z""
";https://scholar.google.com/scholar?start=910&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094574-800;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Ring signatures based on middle-product learning with errors problems;D Das, MH Au, Z Zhang ; International Conference on Cryptology in Africa, 2019  Springer;;"… Looking ahead, we will require H to behave as a random oracle; and \(\mathcal {H}\) to be collision

resistant … Those parameters can be obtained from random oracles/hash functions, with a

“nothing-up-my-sleeve"" type of seed, for instance, the first 256 bits of \(\pi \) or e, etc …";Cité 2 fois;Les 2 versions;null;;;;https://scholar.google.com/scholar?start=610&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094597-893;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Blockchain-based healthcare: Three successful proof-of-Concept pilots worth considering;R Angeles ; Journal of International Technology and …, 2019  scholarworks.lib.csusb.edu;;"… Oracle Services are used to allow the Virtual Machine to interact with the Internet (McFarlane

et al., 2017) … 2017 61 ISSN: 1941-6679-On-line Copy The MEDRec network uses Ethereum's

cryptocurrency, Ether, to incentivize work on the blockchain network and secure itself …";Cité 4 fois;Les 4 versions;[PDF] csusb.edu;https://scholarworks.lib.csusb.edu/cgi/viewcontent.cgi?article=1390&context=jitim;"
Journal of International Technology and Information Management Journal of International Technology and Information Management 

Volume 27 Issue 3 Article 4 

1-1-2019 

Blockchain-Based Healthcare: Three Successful Proof-of-Concept Blockchain-Based Healthcare: Three Successful Proof-of-Concept 

Pilots Worth Considering Pilots Worth Considering 

Rebecca Angeles 
Univ of New Brunswick Fredericton, angeles.rebecca@gmail.com 

Follow this and additional works at: https://scholarworks.lib.csusb.edu/jitim 

 Part of the Computer and Systems Architecture Commons, Management Information Systems 

Commons, and the Technology and Innovation Commons 

Recommended Citation Recommended Citation 
Angeles, Rebecca (2019) ""Blockchain-Based Healthcare: Three Successful Proof-of-Concept Pilots Worth 
Considering,"" Journal of International Technology and Information Management: Vol. 27 : Iss. 3 , Article 4. 
Available at: https://scholarworks.lib.csusb.edu/jitim/vol27/iss3/4 

This Article is brought to you for free and open access by CSUSB ScholarWorks. It has been accepted for inclusion 
in Journal of International Technology and Information Management by an authorized editor of CSUSB 
ScholarWorks. For more information, please contact scholarworks@csusb.edu. 

https://scholarworks.lib.csusb.edu/jitim
https://scholarworks.lib.csusb.edu/jitim/vol27
https://scholarworks.lib.csusb.edu/jitim/vol27/iss3
https://scholarworks.lib.csusb.edu/jitim/vol27/iss3/4
https://scholarworks.lib.csusb.edu/jitim?utm_source=scholarworks.lib.csusb.edu%2Fjitim%2Fvol27%2Fiss3%2F4&utm_medium=PDF&utm_campaign=PDFCoverPages
http://network.bepress.com/hgg/discipline/259?utm_source=scholarworks.lib.csusb.edu%2Fjitim%2Fvol27%2Fiss3%2F4&utm_medium=PDF&utm_campaign=PDFCoverPages
http://network.bepress.com/hgg/discipline/636?utm_source=scholarworks.lib.csusb.edu%2Fjitim%2Fvol27%2Fiss3%2F4&utm_medium=PDF&utm_campaign=PDFCoverPages
http://network.bepress.com/hgg/discipline/636?utm_source=scholarworks.lib.csusb.edu%2Fjitim%2Fvol27%2Fiss3%2F4&utm_medium=PDF&utm_campaign=PDFCoverPages
http://network.bepress.com/hgg/discipline/644?utm_source=scholarworks.lib.csusb.edu%2Fjitim%2Fvol27%2Fiss3%2F4&utm_medium=PDF&utm_campaign=PDFCoverPages
https://scholarworks.lib.csusb.edu/jitim/vol27/iss3/4?utm_source=scholarworks.lib.csusb.edu%2Fjitim%2Fvol27%2Fiss3%2F4&utm_medium=PDF&utm_campaign=PDFCoverPages
mailto:scholarworks@csusb.edu


Journal of International Technology and Information Management  Volume 27, Number 3 2018 

ŠInternational Information Management Association, Inc. 2017 47         ISSN: 1941-6679-On-line Copy 

 

Blockchain-Based Healthcare:  

Three Successful Proof-of-Concept Pilots Worth 

Considering 
 

Rebecca Angeles 

University of New Brunswick Fredericton, Canada 

rangeles@unb.ca 

 

 

ABSTRACT 
 

This paper features the use of blockchain technology in the healthcare industry, 

with special focus on healthcare data exchange and interoperability; drug supply 

chain integrity and remote auditing; and clinical trials and population health 

research. This study uses the research method of analyzing the published case 

studies, academic articles, trade articles, and videos on MEDRec, Patientory, and 

the AmerisourceBergen/Merck alliance with SAP/CryptoWerk. The “blockchain” 

concept was introduced around October 2008 when a proposal for the virtual 

currency, bitcoin, was offered. Blockchain is a much broader concept than bitcoin 

and has the following key attributes: distributed database; peer-to-peer 

transmission; transparency with pseudonymity; irreversibility of records; and use 

of computational logic. The following three healthcare use cases have been taken 

up for proof-of-concept pilots by MEDRec, Patientory, and the 

AmerisourceBergen/Merck collaboration with SAP/CryptoWerk. While blockchain 

technology has a promising potential for specific use cases in the healthcare 

industry, there are major challenges to deal with as well. 

 

KEYWORDS: Blockchain, Healthcare, Smart contract, Technology innovation, 

Distributed peer-to-peer networks 

 

 

INTRODUCTION 
 

This paper features the use of blockchain technology in the healthcare industry, 

with special focus on the following use cases:  healthcare data exchange and 

interoperability; drug supply chain integrity and remote auditing; and clinical trials 

and population health research. Frost & Sullivan, a research organization 

specializing in information technology research, identified these promising use 

cases to pursue in the healthcare industry at this time (Frost & Sullivan (2017, June).  

This paper uses the proof-of-concept experiences of MEDRec, Patientory, and 

mailto:rangeles@unb.ca


Blockchain-Based Healthcare: Three Successful Proof of Concept Pilots Worth Considering             Rebecca Angeles 

ŠInternational Information Management Association, Inc. 2017         48       ISSN: 1941-6679-On-line Copy 

AmerisourceBergen in cooperation with Merck Co. to describe how blockchain 

technology might be successfully exploited in the healthcare industry at this time, 

with the current state of the technology. 

 

This study intends to understand the state-of-the-art blockchain technology 

application in the healthcare industry, a very important domain in society.  The 

initial deployment of the technology in the financial industry gave us a first glimpse 

into the possibilities with this technology for societal use.  It is not the intention of 

this paper to describe basic blockchain technology in great detail, but rather to 

describe its accompanying components used in the first publicized proof-of-concept 

deployments in the healthcare industry.  This paper also intends to drill down into 

the lessons we can learn from its most current organizational implementations. 

 

The paper is organized accordingly.  It opens with an introduction and literature 

review covering basic blockchain technology and use cases in the healthcare 

industry identified as most promising by Frost & Sullivan.  The qualitative case 

study and content analysis methods are described in the research method section.  

Detailed studies of three use cases are presented in the findings section of the paper.  

The last section of the paper is the “Conclusions” section consisting of three parts:  

the first part features a table comparing Patientory and MEDRec, highlighting 

differences and similarities; the second part shows detailed lessons learned specific 

to the three organizations; and the last part discusses lessons of a more general 

nature that would apply to a wider range of healthcare blockchain implementations. 

 

 

LITERATURE REVIEW 
 

Blockchain Technology 

 

Transactions in society between individuals and organizations are governed by 

contracts and records that describe the participation of certain stakeholders and 

details of the transactions that transpired.  Entire economies depend on the tools 

that enable the capture, storage, distribution, and protection of these instruments.  

But there are issues to contend with in the presence of centralized entities that 

control these instruments involving trustworthiness, security, reliability of the 

information.  While there is mistrust of intermediaries or centralized entities 

controlling these assets, there is also the paradoxical situation of separate siloed 

information systems that store this important information that have great difficulty 

exchanging data/information. 

 



Journal of International Technology and Information Management  Volume 27, Number 3 2018 

ŠInternational Information Management Association, Inc. 2017 49         ISSN: 1941-6679-On-line Copy 

 

The “blockchain” concept was introduced around October 2008 when a proposal 

for the virtual currency, bitcoin, was offered (Gupta, 2017).  The bitcoin platform 

would eliminate a central authority for issuing currency, confirming transactions, 

and transferring ownership of the currency.  Blockchain is not synonymous with 

bitcoin; it has many more business use applications besides digital currency and is 

the peer-to-peer network that is a layer above the Internet (Gupta, 2017).  Table 1 

explains the five basic principles underlying blockchain technology. 

 

 

Table 1: Basic Principles of Blockchain Technology 

 

Basic Principle Explanation 

1. Distributed Database 

 

Each party on a blockchain has access 

to the entire database and its complete 

history. No single party controls the 

data or the information. Every party can 

verify the records of its transaction 

partners directly, without an 

intermediary. 

 

2. Peer-to-Peer Transmission 

 

Communication occurs directly 

between peers instead of through a 

central node. Each node stores and 

forwards information to all other nodes. 

 

3. Transparency with Pseudonymity 

 

Every transaction and its associated 

value are visible to anyone with access 

to the system. Each node, or user, on a 

blockchain has a unique 30-plus-

character alphanumeric address that 

identifies it. Users can choose to remain 

anonymous or provide proof of their 

identity to others. Transactions occur 

between blockchain addresses. 

 

4. Irreversibility of Records Once a transaction is entered in the 

database and the accounts are updated, 

the records cannot be altered, because 

they’re linked to every transaction 

record that came before them (hence 

the term “chain”). Various 



Blockchain-Based Healthcare: Three Successful Proof of Concept Pilots Worth Considering             Rebecca Angeles 

ŠInternational Information Management Association, Inc. 2017         50       ISSN: 1941-6679-On-line Copy 

computational algorithms and 

approaches are deployed to ensure that 

the recording on the database is 

permanent, chronologically ordered, 

and available to all others on the 

network. 

 

5. Computational Logic 

 

The digital nature of the ledger means 

that blockchain transactions can be tied 

to computational logic and in essence 

programmed. So users can set up 

algorithms and rules that automatically 

trigger transactions between nodes.” 

 

 

Sources: (Gupta, 2017; Halamka,  Lippman, & Ekblaw, 2017; Iansiti & Lakhani, 

2017; Mainelli, 2017). 

 

Three Promising Healthcare Use Cases 

Frost & Sullivan (Frost & Sullivan, 2018, April 18; 2018, January; 2017, August 4; 

2017, June; 2016, November) established the relevance, timeliness, and urgency of 

experimenting with blockchain in the healthcare industry due to the urgent need to 

cut costs, service a growing aging population with underserved needs, and 

increasing pressures from government to justify exponential healthcare costs in the 

years ahead. 

 

Use Case 1:  Healthcare Data Exchange and Interoperability 

The first use case with maximum benefit potential is to use blockchain technology 

to enable healthcare data exchange and interoperability among different electronic 

healthcare record (EHR) or electronic record management (ERM) systems to serve 

the interests of the individual patient (Frost & Sullivan, 2017, June).  Blockchain 

technology can address major dysfunctions currently experienced in the healthcare 

industry in the context of information exchange and system interoperability.  

Looking at relevant statistics in the U.S., about 46 percent of US clinicians have no 

access to the complete picture of their patients’ records; conversely, US patients 

find it impossible to have a centralized and integrated view of their records and 

thus, are unable to share relevant information with care providers.  With today’s 

broken EHR and EMR systems, error rates for identifying records or integrating 

electronic files are as high as 25 percent for hospital and healthcare organizations, 

and higher even --- 50 to 60 percent --- outside of these systems.  All these problems 



Journal of International Technology and Information Management  Volume 27, Number 3 2018 

ŠInternational Information Management Association, Inc. 2017 51         ISSN: 1941-6679-On-line Copy 

 

cost US society about 150,000 lives and US$18.6 billion annually (Frost & 

Sullivan, 2017, June). 

 

Blockchain technology can open up solutions to these challenges.  First, patients 

can become more engaged with their health if they can gain access to 

cryptographically secure, irrevocable, and immutable historical and real-time data 

covering their in-patient, ambulatory, and remote patient monitoring (RPM) data.  

Just as importantly, care provider quick access to this data can significantly improve 

care coordination and manage emergency care situations.  Second, the use of 

identity management using predefined user access rules in peer-to-peer networks 

can give patients the ability to share their anonymized healthcare data to support 

medical research and medical innovations.  Third, important genomic and user-

generated data, especially data generated by new technologies like mobile health 

apps and Internet of Things-supported healthcare devices and wearable computers 

can be captured and stored securely.  Fourth, the blockchain network would 

override the previous siloed systems that prevented data/information exchange 

among different HER and EMR systems, and at the same time, reducing the costs 

and difficulty of data reconciliation among these systems (Frost & Sullivan, 2017, 

June). 

 

Use Case 2: Drug Supply Chain Integrity and Remote Auditing 

The pharmaceutical industry is beset with challenges in assuring its customers of 

the authenticity and non-tampering of its products.  An estimated US$200 billion is 

lost annually in the global market due to fake drugs (Frost & Sullivan, 2017, June).  

In the European Union drug market, an average of US$33.5 million worth of drugs 

are stolen in cargo theft yearly.  And about 30 percent of drugs sold in developing 

countries are counterfeit products.  In a related vein, outsourcing pharmaceutical 

contract research and manufacturing services globally spawns a wide range of 

administrative, legal, ethical, financial, and staff-related concerns.  In outsourcing 

the manufacturing drug products, greater risks are incurred in offloading production 

in a foreign country where controls may be more likely to be nonexistent.  It is more 

important to use tools to enable supply chain provenance and chain of custody from 

the time raw materials are acquired from suppliers through to production, 

distribution by the wholesaler, pharmacist (i.e., retailer), and final consumption 

point with end customers.  Using blockchain technology, an immutable hash is used 

to automate the serialization and geo-tagging process throughout all the steps 

involved --- R&D tasks, testing, and production in manufacturing facilities.  The 

process of serialization uses a system to track and trace the movement of 

prescription drugs through the supply chain, identifying each product using the 

following information --- unique serial number, product origin, shelf life, and batch 

number (Chatterjee, 2015, January 20). 



Blockchain-Based Healthcare: Three Successful Proof of Concept Pilots Worth Considering             Rebecca Angeles 

ŠInternational Information Management Association, Inc. 2017         52       ISSN: 1941-6679-On-line Copy 

Blockchain “smart contracts” can also be used to automate the auditing of 

outsourced contract manufacturing of drug products and quality compliance by the 

manufacturer.  Smart contracts can also be used for autonomous applications for 

due diligence, inventory management, and product recalls. Blockchain also enable 

the creation of proof of identity (or license) of drug products and immutable records 

which regulatory agencies could use to cut back the inflow into the country of 

counterfeit drugs and identify sources of compromised products.  A reporting 

system can also be established in order to inform citizens of adverse drug reactions 

associated with drug products.  Blockchain can improve the pharmaceutical supply 

chain financial transactions by facilitating the authenticity of transactions involving 

drug products, lowering credit risk, and speeding up payment cycles (Frost & 

Sullivan, 2017, June). 

 

Use Case 3: Clinical Trials and Population Health Research 

The current IT infrastructure undergirding the healthcare industry makes it difficult 

to report and share clinical trial results.  An estimated 50 percent of all clinical trials 

are unreported and as a rule, healthcare researchers/investigators are unable to 

disseminate their study results (Frost & Sullivan, 2017, June).  In the specific case 

of ClinicalTrials.gov, about 90 percent of the trials even lack results.  This creates 

an impoverished situation where the growth of healthcare knowledge capital is 

hindered, leading to serious health risks to society as a whole.   

 

Blockchain technology can be used for a number of scenarios to benefit clinical 

trials and population health research.  First, clinical trial protocols and results could 

be time stamped and render them immutable.  Second, patients can grant access to 

their personal health records securely to researchers and pharma clinical trials 

through the use of eConsenting and smart contracts.  Third, the clinical trial patient 

recruitment process could be more targeted using the eConsenting feature and 

gaining access to anonymized universal health records.  Fourth, new models like 

the use of research commons and renumerative models can be used to encourage 

data sharing and allowing access to anonymized medical metadata in the form of 

transaction fees for research use cases.  Fifth, blockchain technology can address 

the issue of “fraud” in medical research resulting in outcome switching, data 

snooping, and selective reporting --- all nefarious activities --- by assuring clinical 

trial integrity and enabling provenance of medical data trails (Frost & Sullivan, 

2017, June). 

 

 

 

 

 



Journal of International Technology and Information Management  Volume 27, Number 3 2018 

ŠInternational Information Management Association, Inc. 2017 53         ISSN: 1941-6679-On-line Copy 

 

RESEARCH METHOD 
 

While there are numerous articles on the potential of blockchain technology in the 

healthcare industry, there are fewer papers on the successful pilots conducted thus 

far.  Therefore, it is the main objective of this paper to provide a descriptive 

reporting and understanding of three prominent case studies that have reached 

successful proof-of-concept stage in the experimentation with blockchain 

technology.  The three use cases were identified by Frost & Sullivan Research 

(Frost & Sullivan, 2017, June) as the most promising areas to be exploited at this 

time in the healthcare industry.  Published case studies and related academic journal 

articles and trade articles were content analyzed, along with videos on MEDRec, 

Patientory, and SAP/CryptoWerk collaboration for blockchain in the 

pharmaceutical industry.   

 

 

FINDINGS 
 

Patientory 

 

As a Software as a Service firm, Patientory, offers a blockchain-based distributed 

application that enables patients, clinicians, and health organizations to access, 

store, and transfer information to meet patient needs and improve healthcare 

coordination among various institutions (McFarlane et al., 2017; Patientory, 2017a, 

June 20; Patientory, 2017b, July 24; Gaskell, 2017, May 3).  Patientory provides a 

platform for these entities to interact and communicate easily as it interconnects 

electronic medical record (EMR) systems such as Epic, Cerner, Allscripts and 

Meditech and other health related database systems.  The SaaS firm also offers 

patients a mobile app they can use to capture health-related data from both 

traditional and non-traditional sources (i.e., FitBit, etc.) and create their personal 

profiles, stored in secure HIPAA-compliant servers.  Encouraging greater patient 

engagement with their health, the app can also be used by patients to contact their 

care providers and other patients with similar health issues. 

 

Patientory was designed to address the major limitations of the healthcare system 

as it currently operates in the U.S.  The patient-centered enterprise software solution 

acts as an intermediary to the many siloed, fragmented, and centralized electronic 

medical record (EMR) keeping systems (Becker’s Health IT & CIO Report, 2017, 

January 19; Bitcoin Magazine (n.d.); Cohen, 2017, August 31; Health Transformer, 

2017, August 29; Ribitzky et al., 2018). 

 



Blockchain-Based Healthcare: Three Successful Proof of Concept Pilots Worth Considering             Rebecca Angeles 

ŠInternational Information Management Association, Inc. 2017         54       ISSN: 1941-6679-On-line Copy 

In order to do this, Patientory uses: (1) encrypted middleware to meet high-volume 

transaction exchanges in the healthcare industry; (2) application programming 

interfaces (APIs) to facilitate speedy information exchange and transfer; and (3) 

HIPAA-compliant health information storage assets that observe geography-

specific regulations (McFarlane et al., 2017). 

 

Patientory uses the Patientory token (PTOY) to support its operations (McFarlane 

et al., 2017; Patientory, 2017a, June 20; Patientory, 2017b, July 24).  Once patients 

subscribe for the service, they are given an allotted amount of space to store their 

personal health information for free.  They may purchase additional PTOYs using 

the platform or an exchange to enable them to purchase additional storage space in 

the nodes set up in hospital systems.  The PTOY also used by healthcare 

organizations which sign up for the SaaS via service contracts.  Healthcare 

organizations use the PTOY to pay for the creation and execution of smart contracts 

and transactions.  Patientory also incentivizes large healthcare organizations that 

possess large server storage space to trade PTOY tokens with small- and medium-

sized healthcare organizations interested in gaining access to the blockchain 

healthcare network without incurring the costs of implement nodes themselves.  

Overall, the PTOY regulates Patientory’s network storage allocation, healthcare 

quality measures, and revenue payment cycles. 

 

Other sources of revenue for Patientory include fees from providing technical 

support and population health management services as a result of using machine 

learning and aggregating data on the blockchain platform that provide physician 

diagnosis support, patient-care provider care coordination, and patient engagement. 

Patientory uses the Ethereum Blockchain platform that applies a Turing complete 

programming language executed on the Ethereum Virtual Machine.  Oracle 

Services are used to allow the Virtual Machine to interact with the Internet 

(McFarlane et al., 2017). 

 

Patientory uses a private implementation of the Ethereum blockchain which is a 

permissioned blockchain.  It consists of a network of blockchain nodes that can 

interact only with other blockchain nodes, a key authoring entity, the HIPAA 

compliant storage facility, and the remote procedure call (RPC) server.  Public and 

private key pairs to be used in the blockchain are generated by the key authoring 

entity.  The electronic private health information (ePHI) is stored by the HIPAA 

compliant data storage facility (McFarlane et al., 2017). 

 

The Patientory system contains three class level objects:  the institution, the 

institution’s employees, and customers (i.e., patients).  The “individual class 

contract” embodies information that indicates that every user maps to a private 



Journal of International Technology and Information Management  Volume 27, Number 3 2018 

ŠInternational Information Management Association, Inc. 2017 55         ISSN: 1941-6679-On-line Copy 

 

address on the private blockchain.  Also, each private address is authorized to speak 

to one contract in the blockchain.  The “institution contract” lists the customers (i.e., 

patients) who have granted permissions for viewing privileges to select institutions.  

This institution contract also lists its authorized employees.  The “customer 

contract” lists all the institutions patients have granted viewing permissions to.  The 

steps involved are (McFarlane et al., 2017): 

 

1) A requesting entity issues a request for information; this request is a 

cryptographically signed transaction which is sent to the remote procedure 

call (RPC) server.  This RPC server verifies the identity of the requesting 

entity using the signature in the login request. 

2) The database of permission login public keys receives the signature from 

the RPC server and checks if there is a matching entry in the database.  If 

there is a match, this database sends a message to accept the request. 

3) The RPC server also sends a copy of the incoming request to the data 

aggregation server, which, then, forwards this request to miners based on a 

load sharing mechanism.   

4) The miners sends the request to the requesting party’s controlling contract, 

which contains information on the permissions to access specific pieces of 

data that the requesting part is authorized to access.  If the controlling 

contract indicates the permission to access the information requested, then, 

the incoming request is deemed valid. 

5) The controlling contract has a system of hashed pointers that lead to 

requested information.  The controlling contract sends an event message to 

the HIPAA storage server, which contains the data and resolves the system 

of hash pointers.  The controlling contract executes as valid request 

transaction which, in effect, activates the blockchain event messaging 

system, which contacts the HIPAA forwarder. 

6) The HIPAA forwarder recognizes the valid request and creates an 

encrypted request against the HIPAA storage server based on the hashes of 

the event message, which contains the public key of the requesting party.   

7) Also, the data aggregation server sends the request to the private 

blockchain verifiers, which compare the information request against a 

“target contract.”  If the information request is deemed valid, then, the 

transaction is entered in the next block of the block chain via the mining 

process.  An event message in the blockchain is also generated. 

 

 

 

 

 



Blockchain-Based Healthcare: Three Successful Proof of Concept Pilots Worth Considering             Rebecca Angeles 

ŠInternational Information Management Association, Inc. 2017         56       ISSN: 1941-6679-On-line Copy 

MEDRec 

 

MEDRec is the product of the collaboration of the MIT Media Lab and the Beth 

Israel Deaconess Medical Center, along with the individuals, John Halamka, Ariel 

Ekblaw, Andrew Lippman, and Asaph Azaria, to pilot a blockchain-based record 

management system to process electronic healthcare records (Ekblaw, 2017, 2016; 

Halamka et al., 2017; Azaria et al., 2016).  MEDRec was not designed to store 

patients’ health records; instead, it stores the signatures of the patients’ records on 

the blockchain network and alerts them when transactions are initiated (Halamka et 

al., 2017).  The system is also designed to empower the patient as the locus of 

control in managing the flow of transactions on the blockchain. 

 

The MEDRec system uses three types of contracts: the registrar contract (RC), the 

patient-provider relationship contract (PPR), and the summary contract (SC) 

(Figure 1).   

 

 

Figure 1: Three Contract Types in MEDRec System  

 

 
Sources: (Azaria et al., 2016; Ekblaw et al., 2017; 2016) 

 

 

 

 



Journal of International Technology and Information Management  Volume 27, Number 3 2018 

ŠInternational Information Management Association, Inc. 2017 57         ISSN: 1941-6679-On-line Copy 

 

The Registrar Contract 

The registrar contract is also the global contract used to map participant identity 

strings to their Ethereum address identity, which is equivalent to a public key.  This 

contract contains policies that manage the registration of new identities or 

modification of the mapping of existing identities.  Only certified institutions can 

be processed via identity registration (Azaria et al., 2016; Ekblaw et al., 2017; 

2016). 

 

The Patient-Provider Relationship Contract (PPR) 

The patient-provider relationship contract can be implemented in any 

pairwise data stewardship interaction and is issued between two nodes in the 

system where one node manages medical records for the other node.  The 

following is a description of how the PPR behaves in the context of a 

healthcare provider’s database.  The PPR defines the data pointers and 

associated access permissions that identify the records in the healthcare 

provider’s database.  Every time a query string is executed in the provider’s 

database, the pointer associated with the query returns a subset of a patient’s 

data.  The system is designed to assure that no alterations to the data at the 

source have taken place through the use of a hash affixed to the query string.  

Using the hostname and port information, the location of the provider’s 

database in the network is given to enable access to it.  The healthcare 

provider designs the data queries and modifications to these queries 

whenever new records are added to the database (Azaria et al., 2016; Ekblaw 

et al., 2017; 2016). 

 

To enable patients to share their data with others, a hash table has been 

designed that maps third parties’ addresses to a list of additional query 

strings, which indicates the portion of the patient’s data a specific third party 

is allowed to view (Azaria et al., 2016; Ekblaw et al., 2017; 2016). 

 

The Summary Contract (SC) 

The SC holds a log of all interactions between a patient and care providers and other 

third-party institutions authorized by patients to access their data.  Likewise, the SC 

holds a log of transactions between care providers and patents and all third parties 

allowed by patients to access their information.  The SC blockchain log, therefore, 

contains histories of the participation of patients, care providers, and healthcare 

organizations in various past and current interactions involving nodes in the 

blockchain network.  The system is designed to ensure that the SC blockchain logs 

are maintained, backed up, and restored in cases of system crashes (Azaria et al., 

2016; Ekblaw et al., 2017; 2016). 

 



Blockchain-Based Healthcare: Three Successful Proof of Concept Pilots Worth Considering             Rebecca Angeles 

ŠInternational Information Management Association, Inc. 2017         58       ISSN: 1941-6679-On-line Copy 

The SC also enables notifications to be sent to patients regarding the status of 

transactions.  As a rule, care providers update patients’ records and could add new 

relationships in these records.  Patients, therefore, could consult their SCs and find 

notifications about new relationships being suggested to them or updates to their SC 

logs.  Patients have control in the sense that only they can accept new relationships 

being presented to them, and reject or delete these relationships --- deciding which 

records in their SC log they would like to acknowledge.  Patients may also leave the 

blockchain network many times and later, rejoin it.  They may gain access to their 

history with the blockchain network by downloading the latest blockchain in the 

network (Azaria et al., 2016; Ekblaw et al., 2017; 2016). 

 

The MEDRec system also works with four software components stored in servers:  

backend library, Ethereum client, database gatekeeper, and EHR manager (Azaria 

et al., 2016; Ekblaw et al., 2017; 2016). 

 

The Backend API Library 

MEDRec was designed to facilitate the interactions between external health record 

management applications and the blockchain network using a “backend API 

[application program interface] library.”  This library is a bundle of various 

utilities written to handle “hurdles” in interacting with the blockchain network 

such as verifying transactions so that they are accepted with high confidence by 

the network.  Examples of other “hurdles” include handling uncertainties 

associated with transactions that are mined and managing transactions that are 

";"""date"",""2020-06-03T19:23:49Z""
""pdf:PDFVersion"",""1.7""
""xmp:CreatorTool"",""Appligent AppendPDF Pro 6.3""
""pdf:docinfo:title"",""Blockchain-Based Healthcare: Three Successful Proof-of-Concept Pilots Worth Considering""
""Appligent"",""AppendPDF Pro 6.3 Linux 64 bit Aug 30 2019 Library 15.0.4""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""language"",""en""
""dc:format"",""application/pdf; version=1.7""
""pdf:docinfo:creator_tool"",""Appligent AppendPDF Pro 6.3""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""Blockchain-Based Healthcare: Three Successful Proof-of-Concept Pilots Worth Considering""
""xmp:CreateDate"",""2020-06-03T12:23:49Z""
""modified"",""2020-06-03T19:23:49Z""
""pdf:hasMarkedContent"",""true""
""xmp:ModifyDate"",""2020-06-03T12:23:49Z""
""pdf:docinfo:creator"",""Rebecca Angeles""
""meta:author"",""Rebecca Angeles""
""meta:creation-date"",""2020-06-03T19:23:49Z""
""created"",""2020-06-03T19:23:49Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-06-03T19:23:49Z""
""resourceName"",""viewcontent.cgi""
""Author"",""Rebecca Angeles""
""producer"",""Prince 12.5 (www.princexml.com)""
""pdf:docinfo:producer"",""Prince 12.5 (www.princexml.com)""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""access_permission:modify_annotations"",""true""
""dc:creator"",""Rebecca Angeles""
""dcterms:created"",""2020-06-03T19:23:49Z""
""Last-Modified"",""2020-06-03T19:23:49Z""
""dcterms:modified"",""2020-06-03T19:23:49Z""
""pdf:docinfo:custom:Appligent"",""AppendPDF Pro 6.3 Linux 64 bit Aug 30 2019 Library 15.0.4""
""title"",""Blockchain-Based Healthcare: Three Successful Proof-of-Concept Pilots Worth Considering""
""xmpMM:DocumentID"",""uuid:5f7971ea-ae8a-11b2-0a00-a07e2d010000""
""Last-Save-Date"",""2020-06-03T19:23:49Z""
""pdf:docinfo:modified"",""2020-06-03T19:23:49Z""
""meta:save-date"",""2020-06-03T19:23:49Z""
""Content-Length"",""720631""
""Content-Type"",""application/pdf""
""xmp:MetadataDate"",""2020-06-03T12:23:49Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Rebecca Angeles""
""dc:language"",""en""
""pdf:producer"",""Prince 12.5 (www.princexml.com)""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""38""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""1238"",""2205"",""2731"",""1881"",""2348"",""3147"",""2854"",""2545"",""3039"",""2665"",""1227"",""2778"",""2745"",""1493"",""3017"",""3002"",""3001"",""1646"",""2149"",""2369"",""2061"",""3084"",""3189"",""2815"",""2946"",""3057"",""2954"",""3036"",""3249"",""2738"",""3040"",""2318"",""2129"",""2071"",""2045"",""2089"",""2134"",""1446""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-06-03T19:23:49Z""
";https://scholar.google.com/scholar?start=710&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094581-824;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;ArchContract: using smart contracts for disposition;DA Batista, T Weingaertner ; … Conference on Big Data (Big Data …, 2019  ieeexplore.ieee.org;;"… II. APPRAISAL AND DISPOSITION ON BLOCKCHAIN SYSTEMS The need to select records

for destruction became evident in the middle of the 20th century, as organizational … The smart

contract will call the EDRMS by the usage of an oracle service to start the transfer process …";Cité 2 fois;Les 2 versions;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/8986695/9005444/09006221.pdf?casa_token=pMS377RnhssAAAAA:dqI2iSKbdSBhXRIuyoee6fbVfNfWNfrepfdLmafr6w6Xvk5nN_fLE2XI7hX5sObPv3ipnDalJXQ;"
		Skip to Main Content


		
			
				
				

				

			

		


		
			
				
					
						








	
		
	

	







						

						





























	
	
		
	
	
		
			

		
	

	
	
	



						





	
	
		
			
				IEEE Account

					Change Username/Password
	Update Address


			

			
				Purchase Details

					Payment Options
	Order History
	View Purchased Documents


			

			
				Profile Information

					Communications Preferences
	Profession and Education
	Technical Interests


			

			
				Need Help?

					US & Canada: +1 800 678 4333
	Worldwide:  +1 732 981 0060

					
	Contact & Support


			

		

		
			
				
					
							About IEEE Xplore
	Contact Us
	Help
	Accessibility
	Terms of Use
	Nondiscrimination Policy
	Sitemap
	Privacy & Opting Out of Cookies


						
							A not-for-profit organization, IEEE is the world's largest technical professional organization dedicated to advancing technology for the benefit of humanity.
Š Copyright 2021 IEEE - All rights reserved. Use of this web site signifies your agreement to the terms and conditions.
						

					


					

				

				
			

		

	


	
	


						
						






		
		
		
		
		
		
		
		
		
		
		
		
		
			
				
			
			
			
			
		
		
		
		
		
		

			


			

			
			


		
 		
		
			 

						
						









































	

		
		

		
		
		

		
			
		
		
		

		

		
		


		

		
		
		
		
		
		
		
		
		
		
	
	


















		
		
			
				
					
					
								
					
								
			
				
					
					
								
					
								
			
				
					
						








 



					
					
								
			
				
					
					
								
			
				
					
					
								
					
								
			
				
					
					
								
					
								
			
				
					
					
								
					
								
			
				
					
					
								
					
								
			
				
					
					
								
					
								
			
				
					
					
								
					
								
			
		
	




























		
			
					
			
					
			
					
			
				
					








					
			
					
			
					
			
					
			
					
			
					
			
					
			
		
		
	





	
	
	
	
	
	
	


	
	
	

	

















					

				

			


			
				
			
		

	";"""og:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""twitter:title"",""ArchContract: using smart contracts for disposition""
""twitter:card"",""summary""
""Description"",""Disposition is one of the consequences of the appraisal archival function. Although appraisal writ large is a function that no technology could execute, disposi""
""og:title"",""ArchContract: using smart contracts for disposition""
""resourceName"",""09006221.pdf""
""language"",""en""
""title"",""ArchContract: using smart contracts for disposition | IEEE Conference Publication | IEEE Xplore""
""og:description"",""Disposition is one of the consequences of the appraisal archival function. Although appraisal writ large is a function that no technology could execute, disposition has been already supported by different tools. In this paper, we propose a blockchain-based application for disposition, a smart contract called ArchContract, using two different repositories. We discuss appraisal and disposition on blockchain systems, the use of smart contracts as a disposition tool and present the model of ArchContract. We conclude that blockchain and smart contracts have the potential to support some of the records management functions such as disposition.""
""twitter:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-UA-Compatible"",""IE=Edge""
""viewport"",""width=device-width, initial-scale=1.0""
""dc:title"",""ArchContract: using smart contracts for disposition | IEEE Conference Publication | IEEE Xplore""
""twitter:description"",""Disposition is one of the consequences of the appraisal archival function. Although appraisal writ large is a function that no technology could execute, disposition has been already supported by different tools. In this paper, we propose a blockchain-based application for disposition, a smart contract called ArchContract, using two different repositories. We discuss appraisal and disposition on blockchain systems, the use of smart contracts as a disposition tool and present the model of ArchContract. We conclude that blockchain and smart contracts have the potential to support some of the records management functions such as disposition.""
""Content-Encoding"",""UTF-8""
""Content-Type-Hint"",""text/html; charset=utf-8""
""Content-Length"",""39382""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=640&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094600-910;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Aurora: Transparent succinct arguments for R1CS;E Ben;Sasson, A Chiesa, M Riabzev…  … conference on the …, 2019  Springer;;"… in Bitcoin [65] users broadcast their private payment details in the clear on the public blockchain

(so other … 1, the IOP underlying Ligero achieves the same oracle proof length, prover time, and

verifier time … Stark's prover uses an IOP with oracles of size \(O(N\log N)\), leading to an …";Cité 121 fois;Les 3 versions;[PDF] iacr.org;https://eprint.iacr.org/2018/828.pdf;"
Aurora: Transparent Succinct Arguments for R1CS

Eli Ben-Sasson
eli@cs.technion.ac.il

Technion

Alessandro Chiesa
alexch@berkeley.edu

UC Berkeley

Michael Riabzev
mriabzev@cs.technion.ac.il

Technion

Nicholas Spooner
nick.spooner@berkeley.edu

UC Berkeley

Madars Virza
madars@mit.edu

MIT Media Lab

Nicholas P. Ward
npward@berkeley.edu

UC Berkeley

May 8, 2019

Abstract

We design, implement, and evaluate a zkSNARK for Rank-1 Constraint Satisfaction (R1CS), a widely-
deployed NP-complete language that is undergoing standardization. Our construction uses a transparent
setup, is plausibly post-quantum secure, and uses lightweight cryptography. A proof attesting to the
satisfiability of n constraints has size O(log2 n); it can be produced with O(n log n) field operations
and verified with O(n). At 128 bits of security, proofs are less than 130 kB even for several million
constraints, more than 20× shorter than prior zkSNARK with similar features.

A key ingredient of our construction is a new Interactive Oracle Proof (IOP) for solving a univariate
analogue of the classical sumcheck problem [LFKN92], originally studied for multivariate polynomials.
Our protocol verifies the sum of entries of a Reed–Solomon codeword over any subgroup of a field.

We also provide libiop, an open-source library for writing IOP-based arguments, in which a
toolchain of transformations enables programmers to write new arguments by writing simple IOP sub-
components. We have used this library to specify our construction and prior ones.

Keywords: zero knowledge; interactive oracle proofs; succinct arguments; sumcheck protocol

1



Contents
1 Introduction 3

1.1 The need for a transparent setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Our goal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3 Our contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4 Prior implementations of transparent succinct non-interactive arguments . . . . . . . . . . . . . . . . . . . . . . . 6

2 Techniques 9
2.1 Our interactive oracle proof for R1CS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2 A sumcheck protocol for univariate polynomials . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.3 Efficient zero knowledge from algebraic techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.4 Perspective on our techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3 Roadmap 14

4 Preliminaries 15
4.1 Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.2 Representations of polynomials . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.3 The fast Fourier transform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.4 Subspace polynomials . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.5 Interactive oracle proofs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.6 Zero knowledge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.7 Reed–Solomon encoded IOP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.8 Univariate rowcheck . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

5 Univariate sumcheck 21
5.1 Zero knowledge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
5.2 Amortization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

6 Univariate lincheck 26

7 An RS-encoded IOP for rank-one constraint satisfaction 28
7.1 Zero knowledge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
7.2 Amortization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

8 From RS-encoded provers to arbitrary provers 34
8.1 Zero knowledge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

9 Aurora: an IOP for rank-one constraint satisfaction (R1CS) 40

10 libiop: a library for IOP-based non-interactive arguments 43
10.1 Library for IOP protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
10.2 BCS transformation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
10.3 Portfolio of IOP protocols and sub-components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

11 Evaluation 45
11.1 Performance of Aurora . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
11.2 Comparison of Ligero, Stark, and Aurora . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

A Proof of Lemma 5.4 48

B Adaptation of Ligero to the R1CS relation 49
B.1 Interleaved lincheck . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
B.2 Interleaved rowcheck . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
B.3 Interleaved ZKIPCP for R1CS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
B.4 From encoded IPCP to regular IPCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

C Additional comparisons 57
C.1 Comparison of the LDTs in Ligero, Stark, and Aurora . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
C.2 Comparison of the IOPs in Ligero, Stark, and Aurora . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

Acknowledgments 59

References 59

2



1 Introduction

A zero knowledge proof is a protocol that enables one party (the prover) to convince another (the verifier)
that a statement is true without revealing any information beyond the fact that the statement is true. Since
their introduction [GMR89], zero knowledge proofs have become fundamental tools not only in the theory of
cryptography but also, more recently, in the design of real-world systems with strong privacy properties.

For example, zero knowledge proofs are the core technology in Zcash [BCGGMTV14; Zca], a popular
cryptocurrency that preserves a user’s payment privacy. While in Bitcoin [Nak09] users broadcast their
private payment details in the clear on the public blockchain (so other participants can check the validity
of the payment), users in Zcash broadcast encrypted transaction details and prove, in zero knowledge, the
validity of the payments without disclosing what the payments are.

Many applications, including the aforementioned, require that proofs are succinct, namely, that proofs
scale sublinearly in the size of the witness for the statement, or perhaps even in the size of the computation
performed to check the statement. This strong efficiency requirement cannot be achieved with statistical
soundness (under standard complexity assumptions) [GH98], and thus one must consider proof systems that
are merely computationally sound, known as argument systems [BCC88]. Many applications further require
that a proof consists of a single non-interactive message that can be verified by anyone; such proofs are cheap
to communicate and can be stored for later use (e.g., on a public ledger). Constructions that satisfy these
properties are known as (publicly verifiable) succinct non-interactive arguments (SNARGs) [GW11].

In this work we present Aurora, a zero knowledge SNARG of knowledge (zkSNARK) for (an extension
of) arithmetic circuit satisfiability whose argument size is polylogarithmic in the circuit size. Aurora also has
attractive features: it uses a transparent setup, is plausibly post-quantum secure, and only makes black-box
use of fast symmetric cryptography (any cryptographic hash function modeled as a random oracle).

Our work makes an exponential asymptotic improvement in argument size over Ligero [AHIV17], a
recent zero knowledge non-interactive argument with similar features but where proofs scale as the square
root of the circuit size. For example, Aurora’s proofs are 30× smaller than Ligero’s for circuits with a million
gates (which already suffices for representative applications such as Zcash).

Our work also complements and improves on Stark [BBHR18a], a recent zkSNARK that targets compu-
tations expressed as bounded halting problems on random access machines. While Stark was designed for a
different computation model, we can still study its efficiency when applied to arithmetic circuits. In this case
Aurora’s prover is faster by a logarithmic factor (in the circuit size) and Aurora’s proofs are concretely much
shorter, e.g., 20× smaller for circuits with a million gates.

The efficiency features of Aurora stem from a new Interactive Oracle Proof (IOP) that solves a univariate
analogue of the celebrated sumcheck problem [LFKN92], in which query complexity is logarithmic in the
degree of the polynomial being summed. This is an exponential improvement over the original multi-variate
protocol, where communication complexity is (at least) linear in the degree of the polynomial. We believe
this protocol and its analysis are of independent interest.

1.1 The need for a transparent setup

The first succinct argument is due to Kilian [Kil92], who showed how to use collision-resistant hashing
to compile any Probabilistically Checkable Proof (PCP) [BFLS91; FGLSS96; AS98; ALMSS98] into a
corresponding interactive argument. Micali showed how a similar construction, in the random oracle model,
yields succinct non-interactive arguments (SNARGs) [Mic00]. Subsequent work showed that Micali’s
construction preserves a PCP’s zero knowledge [IMSX15] and proof of knowledge [Val08] properties.
However PCPs remain expensive, and this approach has not led to SNARGs with good concrete efficiency.

3



In light of this, a different approach was initially used to achieve SNARG implementations with good
concrete efficiency [PGHR13; BCGTV13]. This approach, pioneered in [Gro10; GGPR13; Lip13; BCIOP13],
relied on combining certain linearly homomorphic encodings with lightweight information-theoretic tools
known as linear PCPs [IKO07; BCIOP13; SBVBPW13]; this approach was refined and optimized in several
works [BCTV14b; BCTV14a; CFHKKNPZ15; Gro16; BISW17; GM17]. These constructions underlie
widely-used open-source libraries [SCI] and deployed systems [Zca], and their main feature is that proofs are
very short (a few hundred bytes) and very cheap to verify (a few milliseconds).

Unfortunately, the foregoing approach suffers from a severe limitation, namely, the need for a central
party to generate system parameters for the argument system. Essentially, this party must run a probabilistic
algorithm, publish its output, and “forget” the secret randomness used to generate it. This party must be
trustworthy because knowing these secrets allows forging proofs for false assertions. While this may sound
like an inconvenience, it is a colossal challenge to real-world deployments. When using cryptographic proofs
in distributed systems, relying on a central party negates the benefits of distributed trust and, even though it is
invoked only once in a system’s life, a party trusted by all users typically does not exist!

The responsibility for generating parameters can in principle be shared across multiple parties via
techniques that leverage secure multi-party computation [BCGTV15; BGG17; BGM17]. This was the
approach taken for the launch of Zcash [The], but it also demonstrated how unwieldy such an approach is,
involving a costly and logistically difficult real-world multi-party “ceremony”. Successfully running such a
multi-party protocol was a singular feat, and systems without such expensive setup are decidedly preferable.

Some setup is unavoidable because if SNARGs without any setup existed then so would sub-exponential
algorithms for SAT [Wee05]. Nevertheless, one could still aim for a “transparent setup”, namely one that
consists of public randomness, because in practice it is cheaper to realize. Recent efforts have thus focused
on designing SNARGs with transparent setup (see discussion in Section 1.4).

1.2 Our goal

The goal of this paper is to obtain transparent zkSNARKs that satisfy the following desiderata.

• Post-quantum security. Practitioners, and even standards bodies [NIS16], have a strong interest in crypto-
graphic primitives that are plausibly secure against efficient quantum adversaries. This is motivated by the
desire to ensure long-term security of deployed systems and protocols.
• Concrete efficiency. We seek argument systems that not only exhibit good asymptotics (in argument size

and prover/verifier time) but also demonstrably offer good efficiency via a prototype.

The second bullet warrants additional context. Most argument systems support an NP-complete problem,
so they are in principle equivalent under polynomial-time reductions. Yet, whether such protocols can be
efficiently used in practice actually depends on: (a) the particular NP-complete problem “supported” by the
protocol; (b) the concrete efficiency of the protocol relative to this problem. This creates a complex tradeoff.

Simple NP-complete problems, like boolean circuit satisfaction, facilitate simple argument systems; but
reducing the statements we wish to prove to boolean circuits is often expensive. On the other hand, one can
design argument systems for rich problems (e.g., an abstract computer) for which it is cheap to express the
desired statements; but such argument systems may use expensive tools to support these rich problems.

Our goal is concretely-efficient argument systems for rank-1 constraint satisfaction (R1CS), which is the
following natural NP-complete problem: given a vector v ∈ Fk and three matrices A,B,C ∈ Fm×n, can one
augment v to z ∈ Fn such that Az ◦Bz = Cz? (We use “◦” to denote the entry-wise product.)

We choose R1CS because it strikes an attractive balance: it generalizes circuits by allowing “native” field
arithmetic and having no fan-in/fan-out restrictions, but it is simple enough that one can design efficient

4



argument systems for it. Moreover, R1CS has demonstrated strong empirical value: it underlies real-world
systems [Zca] and there are compilers that reduce program executions to it (see [WB15] and references
therein). This has led to efforts to standardize R1CS formats across academia and industry [Zks].

1.3 Our contributions

In this work we study Interactive Oracle Proofs (IOPs) [BCS16; RRR16], a notion of “multi-round PCPs” that
has recently received much attention [BCGV16; BCFGRS17; BBCGGHPRSTV17; BBHR18b; BBHR18a;
BKS18]. These types of interactive proofs can be compiled into non-interactive arguments in the random
oracle model [BCS16], and in particular can be used to construct transparent SNARGs. The properties of
zero knowledge and proof of knowledge are inherited from the IOP, leading to transparent zkSNARKs.

Building on this approach, we present several contributions: (1) an IOP protocol for R1CS with attractive
efficiency features; (2) design, implementation, and evaluation of a transparent zkSNARK for R1CS, based on
this IOP; (3) a library for writing IOP-based non-interactive arguments. We now describe each contribution.

(1) IOP for R1CS. We construct a zero knowledge IOP protocol for rank-1 constraint satisfaction (R1CS)
with linear proof length and logarithmic query complexity.

Given an R1CS instance C = (A,B,C) with A,B,C ∈ Fm×n, we denote by N = Ω(m+ n) the total
number of non-zero entries in the three matrices and by |C| the number of bits required to represent these;
note that |C| = Θ(N log |F|). One can view N as the number of “arithmetic gates” in the R1CS instance.

Theorem 1.1 (informal). There is an O(logN)-round IOP protocol for R1CS with proof length O(N) over
alphabet F and query complexity O(logN). The prover uses O(N logN) field operations, while the verifier
uses O(N) field operations. The IOP protocol is public coin and is a zero knowledge proof of knowledge.

The core of our result is a solution to a univariate analogue of the classical sumcheck problem [LFKN92].
Our protocol (including zero knowledge and soundness error reduction) is relatively simple: it is specified in
a single page (see Fig. 5 in Section 9), given a low-degree test as a subroutine. The low degree test that we
use is a recent highly-efficient IOP for testing proximity to the Reed–Solomon code [BBHR18b].

(2) zkSNARK for R1CS. We design, implement, and evaluate Aurora, a zero knowledge SNARG of
knowledge (zkSNARK) for R1CS with several notable features: (a) it only makes black-box use of fast
symmetric cryptography (any cryptographic hash function modeled as a random oracle); (b) it has a transparent
setup (users merely need to “agree” on which cryptographic hash function to use); (c) it is plausibly post-
quantum secure (there are no known efficient quantum attacks against this construction). These features
follow from the fact that Aurora is obtained by applying the transformation of [BCS16] to our IOP for R1CS.
This transformation preserves both zero knowledge and proof of knowledge of the underlying IOP. The
following theorem is obtained straightforwardly by combining Theorem 1.1 with [BCS16, Theorem 7.1].

Theorem 1.2 (informal). There exists a zkSNARK for R1CS that is unconditionally secure in the random
oracle model with proof length OÎť(log2N). The prover runs in time OÎť(N logN) and the verifier in time
OΝ(N). (Here for simplicity we take the field F to have size 2Θ(Ν) where Ν is the security parameter.)

For example, setting our implementation to a security level of 128 bits over a 192-bit finite field, proofs
range from 40 kB to 130 kB for instances of up to millions of gates; producing proofs takes on the order of
several minutes and checking proofs on the order of several seconds. (See Section 11 for details.)

Overall, as indicated in Fig. 2, we achieve the smallest argument size among (plausibly) post-quantum
non-interactive arguments for circuits, by more than an order of magnitude. Other approaches achieve smaller
argument sizes by relying on (public-key) cryptography that is insecure against quantum adversaries.

5



(3) libiop: a library for non-interactive arguments. We provide libiop, a codebase that enables the
design and implementation of non-interactive arguments based on IOPs. The codebase uses the C++ language
and has three main components: (1) a library for writing IOP protocols; (2) a realization of [BCS16]’s
transformation, mapping any IOP written with our library to a corresponding non-interactive argument; (3) a
portfolio of IOP protocols. We have released libiop under a permissive software license for the community
(see https://github.com/scipr-lab/libiop). We believe that our library will serve as a useful tool in
meeting the increasing demand by practitioners for transparent non-interactive arguments.

1.4 Prior implementations of transparent succinct non-interactive arguments

We summarize prior work that has designed and implemented transparent SNARGs; see Fig. 2.1

Based on asymmetric cryptography. Bulletproofs [BCCGP16; BBBPWM18] proves the satisfaction of an
N -gate arithmetic circuit via a recursive use of a low-communication protocol for inner products, achieving a
proof with O(logN) group elements. Hyrax [WTSTW17] proves the satisfaction of a layered arithmetic
circuit of depth D and width W via proofs of O(D logW ) group elements; the construction applies the
Cramer–Damgård transformation [CD98] to doubly-efficient Interactive Proofs [GKR15; CMT12]. Both
approaches use Pedersen commitments, and so are vulnerable to quantum attacks. Also, in both approaches
the verifier performs many expensive cryptographic operations: in the former, the verifier uses O(N) group
exponentiations; in the latter, the verifier’s group exponentiations are linear in the circuit’s witness size.
(Hyrax allows fewer group exponentiations but with longer proofs; see [WTSTW17].)
Based on symmetric cryptography. The “original” SNARG construction of Micali [Mic00; IMSX15] has
advantages beyond transparency. First, it is unconditionally secure given a random oracle, which can be
instantiated with fast symmetric cryptography.2 Second, it is plausibly post-quantum secure, in that there are
no known efficient quantum attacks. But the construction relies on PCPs, which remain expensive.

IOPs are “multi-round PCPs” that can also be compiled into non-interactive arguments in the random
oracle model [BCS16]. This compilation retains the foregoing advantages (transparency, lightweight cryp-
tography, and plausible post-quantum security) and, in addition, facilitates greater efficiency, as IOPs have
superior efficiency compared to PCPs [BCGV16; BCFGRS17; BBCGGHPRSTV17; BBHR18b; BBHR18a].

In this work we follow the above approach, by constructing a zkSNARK based on a new IOP protocol.
Two recent works have also taken the same approach, but with different underlying IOP protocols, which have
led to different features. We provide both of these works as part of our library (Section 10), and experimentally
compare them with our protocol (Section 11). The discussion below is a qualitative comparison.

• Ligero [AHIV17] is a non-interactive argument that proves the satisfiability of an N -gate circuit via proofs
of size O(

√
N) that can be verified in O(N) cryptographic operations. As summarized in Fig. 1, the

IOP underlying Ligero achieves the same oracle proof length, prover time, and verifier time as our IOP.
However, we reduce query complexity from O(

√
N) to O(logN), which is an exponential improvement,

at the expense of increasing round complexity from 2 to O(logN). The arguments that we obtain are still
non-interactive, but our smaller query complexity translates into shorter proofs (see Fig. 2).

• Stark [BBHR18a] is a non-interactive argument for bounded halting problems on a random access machine.
Given a program P and a time bound T , it proves that P accepts within T steps on a certain abstract
1We omit a discussion of prior works without implementations, or that study non-transparent succinct non-interactive arguments;

we refer the reader to the survey of Walfish and Blumberg [WB15] for an overview of sublinear argument systems. We also note
that recent work [BBCPGL18] has used lattice cryptography to achieve sublinear zero knowledge arguments that are plausibly
post-quantum secure, which raises the exciting question of whether these recent protocols can lead to efficient implementations.

2Some cryptographic hash functions, such as BLAKE2, can process almost 1 gibibyte per second [ANWOW13].

6

https://github.com/scipr-lab/libiop


computer (when given suitable nondeterministic advice) via succinct proofs of size polylog(T ). Moreover,
verification is also succinct: checking a proof takes time only |P |+ polylog(T ), which is polynomial in
the size of the statement and much better than “naive verification” which takes time Ω(|P |+ T ).

The main difference between Stark and Aurora is the computational models that they support. While Stark
supports uniform computations specified by a program and a time bound, Aurora supports non-uniform
computations specified by an explicit circuit (or constraint system). Despite this difference, we can compare
the cost of Stark and Aurora with respect to the explicit circuit model, since one can reduce a given N -gate
circuit (or N -constraint system) to a corresponding bounded halting problem with |P |, T = Θ(N).

In this case, Stark’s verification time is the same as Aurora’s, O(N); this is best possible because just
reading an N -gate circuit takes time Ω(N). But Stark’s prover is a logarithmic factor more expensive
because it uses a switching network to verify a program’s accesses to memory. Stark’s prover uses an IOP
with oracles of size O(N logN), leading to an arithmetic complexity of O(N log2N). (See Figs. 1 and 2.)

Both Stark and Aurora have argument size O(log2N), but additional costs in Stark (e.g., due to switching
networks) result in Stark proofs being one order of magnitude larger than Aurora proofs. That said, we
view Stark and Aurora as complementing each other: Stark offers savings in verification time for succinctly
represented programs, while Aurora offers savings in argument size for explicitly represented circuits.

7



protocol round proof length query prover time verifier time
type complexity (field elts) complexity (field ops) (field ops)

Ligero IPCP † 2 O(N) O(
√
N) O(N logN) O(N)

Stark IOP O(logN) O(N logN) O(logN) O(N log2N) O(N)
Aurora IOP O(logN) O(N) O(logN) O(N logN) O(N)

Figure 1: Asymptotic comparison of the information-theoretic proof systems underlying Ligero, Stark,
and Aurora, when applied to an N -gate arithmetic circuit.
† An IPCP [KR08] is a PCP oracle that is checked via an Interactive Proof; it is a special case of an IOP.

post argument size verifier non-interactivity
name setup quantum? asymptotic N = 106 time technology

[Gro10][GGPR13]
[Lip13][BCIOP13]...

various private no Oλ(1) 128B Oλ(k) † linear PCP + linear encoding

[ZGKPP17a] ZK-vSQL private no OÎť(d logN) N/A OÎť(N) apply [CD98]-transform to doubly-
efficient IP [GKR15; CMT12]

[WTSTW17] Hyrax public no Oλ(d logN) ‡ 50 kB Oλ(N) as above (but using a different
polynomial commitment)

[BCCGP16]
[BBBPWM18]

Bulletproofs public no OÎť(logN) 1.5 kB OÎť(N) recursive inner product argument

[AHIV17] Ligero public yes OÎť(
√
N) 4.0MB OÎť(N) apply [BCS16]-transform to IPCP

[BBHR18a] Stark public yes OÎť(log
2N) 3.2MB OÎť(N) apply [BCS16]-transform to IOP

this work Aurora public yes OÎť(log
2N) 130 kB OÎť(N) apply [BCS16]-transform to IOP

Figure 2: Comparison of some non-interactive zero knowledge arguments for proving statements of the
form “there exists a secret w such that C(x,w) = 1” for a given arithmetic circuit C ofN gates (and depth
d) and public input x of size k. The table is grouped by “technology”, and for simplicity assumes that the
circuit’s underlying field has size 2O(λ) where λ is the security parameter. Approximate argument sizes
are given for N = 106 gates over a cryptographically-large field, and a security level of 128 bits; some
argument sizes may differ from those reported in the cited works because size had to be re-computed for
the security level and N used here; also, [ZGKPP17a] reports no implementation.
† Given a per-circuit preprocessing step.
‡ A tradeoff between argument size and verifier time is possible; see [WTSTW17].

8



2 Techniques

Our main technical contribution is a linear-length logarithmic-query IOP for R1CS (Theorem 1.1), which we
use to design, implement, and evaluate a transparent zkSNARK for R1CS. Below we summarize the main
ideas behind our protocol, and postpone to Sections 10 and 11 discussions of our system. In Section 2.1, we
describe our approach to obtain the IOP for R1CS; this approach leads us to solve the univariate sumcheck
problem, as discussed in Section 2.2; finally, in Section 2.3, we explain how we achieve zero knowledge. In
Section 2.4 we conclude with a wider perspective on the techniques used in this paper.

2.1 Our interactive oracle proof for R1CS

The R1CS relation consists of instance-witness pairs ((A,B,C, v), w), where A,B,C are matrices and v, w
are vectors over a finite field F, such that (Az)◦ (Bz) = Cz for z := (1, v, w) and “◦” denotes the entry-wise
product.3 For example, R1CS captures arithmetic circuit satisfaction: A,B,C represent the circuit’s gates, v
the circuit’s public input, and w the circuit’s private input and wire values.4

We describe the high-level structure of our IOP protocol for R1CS, which has linear proof length and
logarithmic query complexity. The protocol tests satisfaction by relying on two building blocks, one for
testing the entry-wise vector product and the other for testing the linear transformations induced by the
matrices A,B,C. Informally, we thus consider protocols for the following two problems.

• Rowcheck: given vectors x, y, z ∈ Fm, test whether x ◦ y = z, where “◦” denotes entry-wise product.

• Lincheck: given vectors x ∈ Fm, y ∈ Fn and a matrix M ∈ Fm×n, test whether x = My.

One can immediately obtain an IOP for R1CS when given IOPs for the rowcheck and lincheck problems.
The prover first sends four oracles to the verifier: the satisfying assignment z and its linear transformations
yA := Az, yB := Bz, yC := Cz. Then the prover and verifier engage in four IOPs in parallel:
– An IOP for the lincheck problem to check that “yA = Az”. Likewise for yB and yC .
– An IOP for the rowcheck problem to check that “yA ◦ yB = yC”.
Finally, the verifier checks that z is consistent with the public input v. Clearly, there exist z, yA, yB, yC that
yield valid rowcheck and lincheck instances if and only if (A,B,C, v) is a satisfiable R1CS instance.

The foregoing reduces the goal to designing IOPs for the rowcheck and lincheck problems.
As stated, however, the rowcheck and lincheck problems only admit “trivial” protocols in which the

verifier queries all entries of the vectors in order to check the required properties. In order to allow for
sublinear query complexity, we need the vectors x, y, z to be encoded via some error-correcting code. We
use the Reed–Solomon (RS) code because it ensures constant distance with constant rate while at the same
time it enjoys efficient IOPs of Proximity [BBHR18b].

Given an evaluation domain L ⊆ F and rate parameter ρ ∈ [0, 1], RS [L, ρ] is the set of all codewords
f : L → F that are evaluations of polynomials of degree less than ρ|L|. Then, the encoding of a vector
v ∈ FS with S ⊆ F and |S| < ρ|L| is v̂|L ∈ FL where v̂ is the unique polynomial of degree |S| − 1 such
that v̂|S = v. Given this encoding, we consider “encoded” variants of the rowcheck and lincheck problems.

3Throughout, we assume that F is “friendly” to FFT algorithms, i.e., F is a binary field or its multiplicative group is smooth.
4The reader may be familiar with a standard arithmetization of circuit satisfaction (used, e.g., in the inner PCP of [ALMSS98]).

Given an arithmetic circuit with m gates and n wires, each addition gate xi ← xj + xk is mapped to the linear constraint
xi = xj + xk and each product gate xi ← xj · xk is mapped to the quadratic constraint xi = xj · xk. The resulting system of
equations can be written as A · ((1, x)⊗ (1, x)) = b for suitable A ∈ Fm×(n+1)2 and b ∈ Fm. However, this reduction results in a
quadratic blowup in the instance size. There is an alternative reduction due to [Mei12; GGPR13] that avoids this.

9



• Univariate rowcheck (Definition 4.9): given a subset H ⊆ F and codewords f, g, h ∈ RS [L, ρ], check
that f̂(a) · ĝ(a)− ĥ(a) = 0 for all a ∈ H . (This is a special case of the definition that we use later.)

• Univariate lincheck (Definition 6.1): given subsets H1, H2 ⊆ F, codewords f, g ∈ RS [L, ρ], and a
matrix M ∈ FH1×H2 , check that f̂(a) =

∑
b∈H2

Ma,b · ĝ(b) for all a ∈ H1.

Given IOPs for the above problems, we can now get an IOP protocol for R1CS roughly as before. Rather
than sending z,Az,Bz,Cz, the prover sends their encodings fz, fAz, fBz, fCz . The prover and verifier then
engage in rowcheck and lincheck protocols as before, but with respect to these encodings.

For these encoded variants, we achieve IOP protocols with linear proof length and logarithmic query
complexity, as required. We obtain a protocol for rowcheck via standard techniques from the probabilistic
checking literature [BS08]. As for lincheck, we do not use any routing and instead use a technique (dating
back at least to [BFLS91]) to reduce the given testing problem to a sumcheck instance. However, since we
are not working with multivariate polynomials, we cannot rely on the usual (multivariate) sumcheck protocol.
Instead, we present a novel protoco";"""date"",""2019-05-08T19:49:26Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"","" Aurora: Transparent Succinct Arguments for R1CS ""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"","" Aurora: Transparent Succinct Arguments for R1CS ""
""modified"",""2019-05-08T19:49:26Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016) kpathsea version 6.2.2""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2019-05-08T19:49:26Z""
""created"",""2019-05-08T19:49:26Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-05-08T19:49:26Z""
""resourceName"",""828.pdf""
""Author"",""""
""producer"",""pdfTeX-1.40.17""
""pdf:docinfo:producer"",""pdfTeX-1.40.17""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""5"",""3"",""3"",""0"",""0"",""9"",""25"",""34"",""40"",""35"",""3"",""43"",""18"",""57"",""67"",""48"",""70"",""35"",""58"",""29"",""32"",""51"",""26"",""52"",""5"",""84"",""52"",""36"",""65"",""9"",""95"",""9"",""28"",""0"",""0"",""0"",""0"",""0"",""43"",""6"",""61"",""51"",""20"",""28"",""32"",""55"",""20"",""13"",""20"",""0"",""0"",""0"",""0"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2019-05-08T19:49:26Z""
""Last-Modified"",""2019-05-08T19:49:26Z""
""dcterms:modified"",""2019-05-08T19:49:26Z""
""title"","" Aurora: Transparent Succinct Arguments for R1CS ""
""Last-Save-Date"",""2019-05-08T19:49:26Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2019-05-08T19:49:26Z""
""meta:save-date"",""2019-05-08T19:49:26Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016) kpathsea version 6.2.2""
""Content-Length"",""1215146""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""64""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""1383"",""2823"",""3552"",""3643"",""3437"",""3782"",""1395"",""1778"",""3311"",""3325"",""3226"",""3790"",""144"",""1427"",""2663"",""3270"",""2710"",""3130"",""2815"",""2369"",""2477"",""1914"",""2265"",""2374"",""914"",""2652"",""1922"",""2701"",""2604"",""2817"",""2412"",""2595"",""358"",""3650"",""2476"",""2573"",""2718"",""2448"",""1240"",""2677"",""1214"",""930"",""3162"",""2398"",""3079"",""1614"",""1149"",""1673"",""2759"",""2212"",""2521"",""2021"",""2849"",""2799"",""2588"",""1249"",""3199"",""2592"",""2879"",""3282"",""2914"",""2976"",""2870"",""2050""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-05-08T19:49:26Z""
";https://scholar.google.com/scholar?start=720&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094532-614;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Devid: Blockchain-based portfolios for software developers;M de Vos, M Olsthoorn… ; 2019 IEEE International …, 2019  ieeexplore.ieee.org;;"… authority or an (Ethereum) smart contract that interacts with the dAppCoder application through

oracles … de Vos, and J. Pouwelse, “Trustchain: A sybil-resistant scalable blockchain,” Future

Generation … [11] C. LeMahieu, “Nano: A feeless distributed cryptocurrency network,” URL …";Cité 2 fois;Les 6 versions;[PDF] tudelft.nl;http://pure.tudelft.nl/ws/files/55377155/paper_camera_ready.pdf;"
 
 

Delft University of Technology

DevID: Blockchain-based Portfolios for Software Developers

de Vos, Martijn; Olsthoorn, Mitchell; Pouwelse, Johan

DOI
10.1109/DAPPCON.2019.00030
Publication date
2019
Document Version
Accepted author manuscript
Published in
Proceedings - 2019 IEEE International Conference on Decentralized Applications and Infrastructures,
DAPPCON 2019

Citation (APA)
de Vos, M., Olsthoorn, M., & Pouwelse, J. (2019). DevID: Blockchain-based Portfolios for Software
Developers. In P. Ruppel, S. Schulte, J. Xu, Y. Park, & A. Kupper (Eds.), Proceedings - 2019 IEEE
International Conference on Decentralized Applications and Infrastructures, DAPPCON 2019: Blockchain
and beyond (pp. 158-163). [8783158] https://doi.org/10.1109/DAPPCON.2019.00030
Important note
To cite this publication, please use the final published version (if applicable).
Please check the document version above.

Copyright
Other than for strictly personal use, it is not permitted to download, forward or distribute the text or part of it, without the consent
of the author(s) and/or copyright holder(s), unless the work is under an open content license such as Creative Commons.

Takedown policy
Please contact us and provide details if you believe this document breaches copyrights.
We will remove access to the work immediately and investigate your claim.

This work is downloaded from Delft University of Technology.
For technical reasons the number of authors shown on this cover page is limited to a maximum of 10.

https://doi.org/10.1109/DAPPCON.2019.00030
https://doi.org/10.1109/DAPPCON.2019.00030


DevID: Blockchain-based Portfolios for Software
Developers

Martijn de Vos, Mitchell Olsthoorn, and Johan Pouwelse (j.a.pouwelse@tudelft.nl)
Distributed Systems group, Delft University of Technology, The Netherlands

Abstract—Decentralized applications, also known as dApps,
are the new paradigm for writing business-critical software.
Recruiting developers with appropriate qualifications and skills
for this activity is key, yet challenging. The main problem is that
the portfolio of developers is usually scattered across centralized
platforms like GitHub and LinkedIn, and vendor locked. This
can result in an incomplete impression of their capabilities.

We address this problem and introduce DevID, a blockchain-
based portfolio for developers. Over time, this portfolio enables
developers to build up a trustworthy collection of records that
showcase their capabilities and expertise. They can import data
assets from third parties into a unified DevID portfolio, add
projects and skills, and receive endorsements. All portfolio
records are stored on a scalable distributed ledger and owned by
developers themselves. The essential idea is to exploit the tamper-
proof property of the blockchain while providing durable storage.

To demonstrate the practical value of DevID, we build the
competition-based platform, dAppCoder, for the development of
decentralized applications. On dAppCoder clients are able to
submit their ideas and developers can find work. dAppCoder
utilizes DevID portfolios to match these clients and developers.
We fully implement our ideas and conduct a deployment trial.
Our trial demonstrates that DevID is efficient at storing portfolio
records.

Index Terms—Unified Portfolio, Decentralized Applications
Development, dApp Development Platform, Developer Reputa-
tion and Identity, Distributed Ledger Technology

I. INTRODUCTION

Decentralized applications, also known as dApps, allow for
contractual logic that runs without the need for trusted inter-
mediaries. Finding the right talent to develop these business-
critical applications is becoming a real problem [1]. Yet, many
software developers are looking for work. Matching clients and
reputable developers is at the core of profit-driven companies
such as Upwork. However, each platform only provides access
to a subset of all available work and developers.

The main problem is that centralized approaches lead to
fragmentation and lock-in effects [2]. Many software devel-
opers have their data fragmented across multiple platforms,
like GitHub and LinkedIn. Each platform only yields a partial
impression on the capabilities and background of a developer.
Moreover, data assets are usually locked to one platform and
cannot easily be reused across different services.

Another issue with centralized approaches is data authority.
It raises much discussion in our society, mainly controlled by
data-driven corporates. By agreeing to the terms of service of
a company, one essentially gives them authority over most of
the personal data being shared.

This work was funded by NWO/TKI grant 439.16.614.

There currently is no independent platform for developer
portfolios without fragmentation, lock-in, and autonomy over
all data. Availability of such a platform would increase effi-
ciency and effectiveness when matching reputable developers
looking for work and clients that are in need of talent.

We address this deficiency and present DevID, a unified
portfolio specifically made for dApp developers. An impres-
sion of such a portfolio is given in Figure 1. DevID portfolios
are powered by a scalable blockchain ledger, used for durable
storage of records. Developers can add tamper-proof records
to their portfolio. These records are fully managed and owned
by developers themselves.

To show the practicality of DevID, we build a competition-
based platform for crowdsourcing the development of decen-
tralized applications, named dAppCoder. Crowdsourcing is a
relatively new model for software development, where an open
call is made for the documentation, design, coding, and testing
of software [3]. We believe that a single, public, and open
market is preferable compared to a centralized solution with
fragmentation and lock-in effects.

The main contributions of this work are tri-fold:
• DevID: a unified portfolio specifically for dApp develop-

ers, powered by a pairwise distributed ledger (Section III).
• dAppCoder: our application to crowdsource the develop-

ment of decentralized applications (Section IV).
• A deployment trial of DevID and dAppCoder, which

demonstrates the practicality of our work (Section V).

II. PROBLEM DESCRIPTION

The main challenge is to create a digital portfolio that gives
an accurate impression of the capabilities and expertise of
a developer. We now elaborate on two requirements for this
portfolio and clarify the problems we have to address.

Fig. 1: An impression of a DevID portfolio.



Wallet

Code Execution Environment

DAppCoder Client

Submission Validator
WalletWallets

TransactionsFraud Management

Scalable Blockchain Fabric

Distributed Storage

Tamper-proof Developer Portfolio

Trusted 
Notary 
Service 

DevID

DApp- 
Coder

Fig. 2: The architecture of DevID and dAppCoder.

First, we require that developers are able to import existing
data from other platforms into their portfolio. This streamlines
the bootstrapping process of a portfolio with relevant records.
The problem, however, is to ensure that data being imported
actually belongs to the user importing it. This is an essential
requirement to ensure trustworthy portfolios.

Second, we require our developer portfolio to be indepen-
dent of any trusted intermediary. Blockchain technology is
increasingly being used as middleware for building powerful
decentralized applications without centralized authority. For
example, platforms like Ethereum and EOS enable developers
to write and deploy smart contracts, self-executing code that
enforces agreements between two or more parties [4]. How-
ever, most blockchain fabrics are not suitable for large-scale
storage of portfolio records, or for data storage in general.

Given these two requirements, the research question of this
work is as follows: How can we provide software engineers
with a unified developer portfolio, efficient at storing tamper-
proof and accurate data records they control themselves?

III. DEVID: BLOCKCHAIN-BASED PORTFOLIOS FOR
SOFTWARE DEVELOPERS

We now present our unified portfolio, named DevID. The
architecture is given in Figure 2. This figure also includes the
architecture of dAppCoder, our platform to crowdsource the
development of decentralized applications. dAppCoder itself
is discussed in Section IV.

A. Supporting Generic Storage

We show how DevID portfolios support generic storage of
records and elaborate on different record types.

Statistics: The first record type we consider is statistics,
quantifiable and verifiable numbers that represent a specific
developer metric. For example, these records could represent
developer statistics like the number of years of programming
experience, or the total number of code reviews given. A
visualization of these records is shown in Figure 1 under the
section “Developer in Numbers”.

Projects: Developers can add projects that they worked
on to their DevID portfolio. In Figure 1, this information
is displayed under the section “Top Projects”. Optionally,
references to projects can be added to a DevID portfolio, like a
link to a GitHub repository or to the hash of a specific commit.

Skills: Developers can add skills to their DevID portfolio.
We consider the ability to highlight proficiency in specific
programming languages and familiarity with blockchain plat-
forms an essential feature of a developer portfolio. It aids
programmers in finding projects that match their expertise, and
it enables clients to find developers that fit their projects best.
For instance, applications that have access to DevID portfolios
can filter available developers on one or multiple skills.

Endorsements: The final record type we define is en-
dorsements. Developers can endorse other developers (e.g.,
by writing a letter of recommendation) or endorse specific
skills of others. Skills and endorsements can also be imported
from other platforms like LinkedIn. How we achieve this, is
discussed in the next section.

B. Unifying Developer Data

We now discuss how to import developer data from multiple
platforms and how to verify it for correctness.

Importing developer data: DevID allows developers to
import relevant information from different platforms into their
portfolio. For example, they can import data from LinkedIn
(e.g., skills or past projects) or from GitHub (e.g., the number
of followers and code contributions). Importing can be done by
querying their public interfaces (APIs) and request the relevant
data. To store the data in the portfolio, one can either add a
reference to the (external) data or copy the data assets into
the portfolio. To reduce dependency on third-party services,
we choose to copy the data and store it within a portfolio
record.

Verifying developer data: As discussed in Section II, it is
essential to ensure that imported data actually belongs to the
developer importing it. We propose two solutions to achieve
trustworthy importation of data: challenges and TLS auditing.

The first solution is to pose a challenge where the developer
importing the data, proves that they have control over this
data. For example, when importing data from GitHub, we can
require a public identifier (e.g., a public key) of the developer
to be part of the “bio” profile field. This information can then
be verified for correctness by other users who query the public
GitHub API. We call users who verify data witnesses. While
this is a basic mechanism to ensure the accuracy of imported
data, it heavily depends on the availability of a public API.

The second solution is TLS auditing [5]. The key idea is to
proxy a TLS connection through a random witness, which then
verifies and signs the data after the TLS connection terminates.
When the TLS session finishes, the client gives the witness the
private key used to decrypt HTTPS responses from the web
service. Note that this way the witness is not able to decrypt
the request made to the web service, which likely includes
credentials or access tokens. The role of a witness can either
be fulfilled by other entities in the network, or by a trusted



(a) Linear ledger (Ethereum). (b) DAG ledger (IOTA). (c) Pairwise ledger (Nano).

Fig. 3: Three different structures of distributed blockchain ledgers. Each arrow points to the subsequent block in the chain.

notary service. Depending on the significance of data being
imported, multiple witnesses can be used for this. Compared
to challenges, TLS auditing works when access to a public API
is absent but is more advanced. Our lab has implemented an
advanced TLS auditing mechanism, which is currently under
a security audit.

C. Verified Identities

To further improve trustworthiness of DevID portfolios, de-
velopers can optionally verify their digital identity. A verified
identity is uniquely linked to a real-world entity. Software built
on DevID can give preferential treatment to developers that
have verified their identity. For example, an application can
ignore endorsements that are given by unverified developers.

Identity verification can be done with an attestation given
by a trusted third party like the government or a notary.
Enforcing strong, long-lived identities in DevID is comparable
with account validation that many centralized platforms use
(e.g., the verification of a phone number). The requirement
for verified identities addresses the Sybil Attack, where an
adversary assumes multiple fake identities to influence or
subvert the network [6].

D. Efficient Blockchain Storage

DevID requires a blockchain fabric that can store tamper-
proof and accurate data records. We now explore three com-
mon blockchain structures, displayed in Figure 3.

Linear ledger: Figure 3a shows the linear blockchain
ledger used by Ethereum. The fundamental property of this
ledger is that at least a majority of users agree on the exact
sequence of transactions. A global consensus mechanism like
Proof-of-Work or Proof-of-Stake prevents the double-spend
attack where a malicious user intentionally creates a fork
of their chain [7]. While providing a high level of consis-
tency, the transaction throughput of these ledgers is often
not high enough to facilitate record creation and modification
by millions of users. This motivates us to consider different
blockchain structures for portfolio storage.

DAG ledger: Another blockchain structure is the Directed
Acyclic Graph (DAG) ledger, where each block can be refer-
enced by multiple other blocks. This ledger structure, shown in
Figure 3b, is adopted by blockchain platforms like IOTA and
Dagcoin [8] [9]. IOTA is optimized for micro-payments within

Internet-of-Things, and Dagcoin advertises itself as data stor-
age for arbitrary data (e.g., documents or ownership records).
Since these ledgers allow for different consensus mechanisms,
transaction throughput is often superior compared to that of
linear ledgers. However, they usually do not have the same
consistency guarantees. While these ledger structures are more
suitable for data storage, we consider current implementations
unfit for developer portfolios. The reason is that they either
rely on a centralized coordinator (IOTA) or a fixed group
of witness nodes (Dagcoin). Instead, our goal is to devise a
portfolio infrastructure without any authority with leveraged
permission.

Pairwise Ledger: A third blockchain structure we con-
sider is the pairwise distributed ledger. The key property of
this ledger, given in Figure 3c, is that each user maintains
and grows their individual chain with transactions. Each
block holds exactly one transaction and optionally contains
a (hash) pointer to a transaction in the individual chain of
another user. Blockchain fabrics like R3 Corda, Nano, and
TrustChain, use pairwise ledgers as their underlying data
structure [10] [11] [12]. These platforms address the double-
spending attack either by a trusted notary (Corda), a weighted
voting system (Nano) or by guaranteed eventual consistency
(TrustChain). In general, they provide superior scalability
compared to linear ledgers as used by Bitcoin and Ethereum
but lack global consensus.

We strongly believe that the pairwise distributed ledger is a
suitable data structure to store portfolio records as transactions.
Compared to linear and DAG ledgers, all data of a portfolio
owner is local to their own individual ledger and maintained
by themselves. Pairwise distributed ledgers enable selective
queries of data stored on the chains of other members, without
the need for full data replication across the network. In
DevID, each individual ledger stores all data associated with a
single portfolio, in a tamper-proof manner, and without global
agreement.

E. Storing Large Data Assets

While pairwise distributed ledgers are suitable for storing
small portfolio records, they are not suitable for storing
arbitrary large data assets. Such data assets can include source
code, documentation, and reviews. To overcome this, we intro-
duce an off-chain distributed storage solution that offers data



Fig. 4: The user interface of DAppCoder, our application to crowdsource the development of decentralized applications.

immutability and scalability. Figure 2 shows the distributed
storage, which comprises the lowest layer in our architecture.

Suitable distributed storage solutions for our work are a
Distributed Hash Table (DHT) like Kademlia, a BitTorrent
swarm or the InterPlanetary File System (IPFS) [13] [14] [15].
These solutions enable users to store large data assets, without
involvement of a trusted third party. Large data is inserted in
the distributed storage back-end, and a reference to the data
(i.e., a content hash) is included in the on-chain transaction.

IV. DAPPCODER: CROWDSOURCING DEVELOPMENT OF
DECENTRALIZED APPLICATIONS

By extending the DevID portfolio architecture and record
types, we create a competition-based crowdsourcing platform
for the development of decentralized applications. Running
completely without servers, our platform named dAppCoder
matches clients and dApp developers. The architecture of
dAppCoder is presented in the upper layer of Figure 2 and
the user interface is shown in Figure 4. We now elaborate on
the main functionalities of dAppCoder.

A. Creating Projects

Clients that want their idea realized (e.g., the implemen-
tation of a specific smart contract) can create a new project
in dAppCoder. Creating a new project requires the client to
specify a project title, requirements, a submission deadline,
the number of testers needed for each submission, and a list
of skills needed to work on the project. When creating a new
project, a single portfolio record with all project information
is constructed, appended to the individual ledger, and dissem-
inated in the network. Since the project requirements might
be of arbitrary length, we store it in the distributed storage
back-end and embed a pointer to it in the portfolio record.
For each new project, the client generates a project keypair,
which consists of a public and private key. These keys are
used when releasing the submissions for a project, which is
discussed in Section IV-B.

To incentivize developers to work on a particular project,
each project has a fixed monetary reward which is disbursed

by the client to the developer with the best submission. Prior
to posting a new project, the client determines the height
of the reward and transfers it to a Trusted Notary Service
(shown in Figure 2). This compensation, put into escrow,
directly addresses an attack where clients flood the system with
invalid or irrelevant projects. The trusted notary can either be
a centralized authority or an (Ethereum) smart contract that
interacts with the dAppCoder application through oracles.

Each project goes through two phases during its lifetime:
a submission and a testing phase. During the submission
phase, developers can create submissions for a project until
the submission deadline (which is determined by the client).
The duration of the testing phase depends on the time it takes
for the project to accumulate the required number of testers.

B. Creating Submissions

Developers looking for work can browse through the list
of open projects, or filter them based on the skills they have
added to their DevID portfolio. When a developer has found
an interesting project, they work towards a submission. A
submission must consist of source code and documentation,
which are inserted in the distributed storage back-end. For each
submission, a new portfolio record is created with a pointer to
the project and submission files. Incoming submissions after
the submission deadline has passed, will not be considered for
testing.

To prevent a free-riding attack where a developer copies the
solution of another participant, the content of each submission
is encrypted with the (public) project key [16]. To ensure that
testers can decrypt submissions, the client sends the private
project key to them after the submission deadline has passed.

C. Testing Submissions

After the submission deadline passed, all submissions
should be tested by other developers. For simplicity, we as-
sume that the client selects appropriate testers for submissions,
based on their expertise (indicated by their DevID portfolio)
and the total number of submissions tested in the past. To
incentivize developers to test submissions, testing activities



will be prominently displayed on their DevID portfolio. The
testing phase consists of two phases, where tests are written
and verified. To avoid collusion between developers, we re-
quire that individuals who have created a submission, written
tests, and verified these tests, are not affiliated.

Writing tests: First, testers write tests to verify the correct-
ness of a submission. These tests can be used to expose critical
vulnerabilities or programming errors in business-critical code.
If a tester found such an error, they can mark the submission
for exclusion and should provide a test that highlights it.

Besides writing tests, each tester grades the submission
based on compliance to the specifications. The given score
can range from ""very low"" (-2), ""low"" (-1), ""neutral"" (0),
""sufficient"" (1) or ""high"" (2).

Verifying tests: Second, developers inspect the tests, written
by testers in the previous phase. In particular, thoroughness
and completeness of the tests written by a specific tester will
be graded by giving a similar score as in the previous phase.

D. Paying Out Developers

When the testing phase of a project ends, the best submis-
sion is determined by having the highest average score rating.
The developer with the best submission is compensated for the
effort. Since all reviews are public, the trusted notary service
is able to transfer the reward to the eligible developer. This
reward is transferred to cryptocurrency wallets, which can be
added to dAppCoder.

V. IMPLEMENTATION AND DEPLOYMENT TRIAL

Next, we elaborate on the implementation of both the DevID
portfolio and the dAppCoder application. We also discuss our
deployment trial and present the results.

A. Our Implementation

We have implemented both DevID and dAppCoder in the
Python programming language. Our implementation consists
of all components shown in Figure 2, except for the trusted
notary service. The graphical user interface of dAppCoder is
implemented with the Qt5 library and communicates with the
back-end over a RESTful API. The open source implementa-
tions of both DevID and dAppCoder are available online.1

We build DevID, and by extension dAppCoder, on the
TrustChain ledger introduced by Otte et al [10]. We identified
two advantages of TrustChain over other pairwise distributed
ledgers like R3 Corda and Nano. First, TrustChain focuses
on fraud detection instead of prevention and as a result does
not require network-wide consensus. This makes TrustChain
a lightweight and simple data structure. Second, TrustChain is
already used as transaction fabric within a self-sovereign, de-
centralized identity system, described in the work of Stokkink
et al [17]. Availability of a self-sovereign identity system
aligns with our requirement for strong, long-lived identities
(see Section III-C). We use the InterPlanetary File System
(IPFS) to store large data assets like project specifications,
submissions and code reviews. Users can import statistics from

1https://github.com/tribler/dappcoder

0

30

60

90

120

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

Trial Participants

T
ra

n
s
a
c
ti
o
n
 C

o
u
n
t

Transaction

Import records

Add skill

Endorse skill

Create project

Review submission

Create submission

Fig. 5: Results from our deployment trial.

their GitHub profile using the challenge mechanism described
in Section III-B.

B. Deployment Trial

To assess the feasibility of dAppCoder and to get insight
into the efficiency of the TrustChain ledger, we conduct a
deployment trial. We present the trial setup and results.

Setup: For our trial, we recruited 15 participants among
local staff and students of our faculty. To bootstrap the appli-
cation, we initiated dAppCoder with five projects ourselves.
Two of these projects asked developers to resolve one or
more bugs in a piece of Python code. The other three projects
asked the developer to implement a small application. Since
only a fraction of our users is familiar with the development
of decentralized applications, we accepted submissions in
other programming languages during our trial, like Java. We
collected data and observed the growth of the distributed
ledger over a period of five working days. During this time,
developers were free to use the application as they see fit.

Results: Figure 5 shows the growth of the TrustChain
ledger when more participants join the trial. Each entry on
the horizontal axis represents the state of the ledger after a
participant was introduced, and the vertical axis shows the
transaction count for the six different types of transactions.
When more participants join, the distribution of transaction
types on the ledger changes slightly. We observe that the
growth of projects over time decreases, and users focus more
on creating submissions and reviews. Another observation is
that the number of skills added by each developer grows
rapidly, but the growth of endorsements stays behind.

At the end of our deployment trial, the average transaction
size in serialized form is 0.6 kB. The total size of all
transactions stored on the distributed ledger is 65.4 kB. Each
individual ledger stores on average 7.2 transactions, with an
average size of 4.1 kB. In comparison, when using a linear
ledger like Bitcoin, each user is required to store the entire
global ledger or parts of it. The time required to append
new transactions to the TrustChain ledger is in the range of
milliseconds and not of influence on the user experience. The



initial results of the trial look promising, and we are ready for
further evaluation of dAppCoder and DevID portfolios.

VI. RELATED WORK

We are the first to build a tamper-proof and unified devel-
oper portfolio, to the best of our knowledge. Already in 1995,
research has been conducted, that explores the advantages of
online electronic portfolios over traditional resumes, particu-
larly within an educational environment [18] [19]. The emer-
gence of the open source software paradigm enabled develop-
ers to use code contributions as proof of verifiable technical
expertise and to build an online reputation [20]. The work of
Cai et al. explores how this data can be used to construct a
theoretical reputation model, and what metrics would be best
suited for this [21]. Other work is focused on visualization
tools to highlight contributions of the individual developer on
platforms like GitHub or StackOverflow [22] [23] [24]. Their
research is primarily focused on the design and evaluation of
models to represent the technical skills, based on data from
open source projects. The focus of this work is on combining
records from different platforms and presenting them in a
unified portfolio.

The evolution of crowdsourcing and the benefits are well-
studied topics with an extensive literature corpus [3]. Top-
Coder Inc. is an example of a crowdsourcing platform where
clients can outsource software contributions to developers in a
competition-based environment [25]. In 2017, Li et al. intro-
duced CrowdBC, a decentralized blockchain-based framework
for crowdsourcing [26]. CrowdBC is a platform to crowd-
source generic micro-tasks and is not suitable to crowdsource
development of decentralized applications. Lu et al. devised
a privacy-preserving crowdsourcing mechanism on top of an
open blockchain [27]. Buccafurri et al. introduce TweetChain
and show how to build a crowdsourcing application which
stores all information on Twitter timelines [28]. TweetChain is
comparable with individual ledgers in TrustChain but depends
on a central authority for dissemination and storage of data
(Twitter). In comparison to most of the research performed
on blockchain-based crowdsourcing, this work focuses on a
specific use-case, namely crowdsourcing the development of
business-critical applications.

VII. CONCLUSION

We have presented DevID, a blockchain-based portfolio for
developers. DevID addresses the fragmentation and lock-in of
developer data across different platforms with a mechanism
to import data from third-party services. By building upon
a pairwise distributed ledger, DevID is capable of storing
tamper-proof records and does not depend on any trusted party.
Portfolio records are fully managed by developers themselves.

We have proven the potential of DevID by building a
crowdsourcing application for the development of decentral-
ized applications. Our application, dAppCoder, matches clients
and reputable developers. With a deployment trial, we have
demonstrated that dAppCoder is feasible.

Future work is focused on a large-scale deployment of
dAppCoder and better support for specific bug bounties. We
schedule to release in the first quarter of 2019. Using our
TLS auditing mechanism, we plan to expand DevID with ad-
ditional record importation from other platforms, in particular,
LinkedIn and StackOverflow. Finally, we aim to explore the
use of DevID within other domains besides crowdsourcing.

REFERENCES

[1] Nasdaq, “The blockchain developer shortage: Emerging trends
and perspectives,” URL https://www.nasdaq.com/article/the-blockchain-
developer-shortage-emerging-trends-and-perspectives-cm701294, 2016.

[2] J. Pouwelse, A. de Kok, J. Fleuren, P. Hoogendoorn, R. Vliegendhart,
and M. de Vos, “Laws for creating trust in the blockchain age,” European
Property Law Journal, vol. 6, no. 3, pp. 321–356, 2017.

[3] T. D. LaToza and A. van der Hoek, “Crowdsourcing in software engi-
neering: Models, motivations, and challenges,” IEEE software, vol. 33,
no. 1, pp. 74–80, 2016.

[4] N. Szabo, “Formalizing and securing relationships on public networks,”
First Monday, vol. 2, no. 9, 1997.

[5] “Tlsnotary - a mechanism for independently audited https sessions,” URL
https://tlsnotary.org/TLSNotary.pdf, 2014.

[6] J. R. Douceur, “The sybil attack,” in International workshop on peer-
to-peer systems. Springer, 2002, pp. 251–260.

[7] M. Vukolić, “The quest for scalable blockchain fabric: Proof-of-work
vs. bft replication,” in iNetSec. Springer, 2015, pp. 112–125.

[8] S. Popov, “The tangle, iota whitepaper,” 2018.
[9] S. D. Lerner, “Dagcoin: a cryptocurrency without blocks,” 2015.

[10] P. Otte, M. de Vos, and J. Pouwelse, “Trustchain: A sybil-resistant
scalable blockchain,” Future Generation Computer Systems, 2017.

[11] C. LeMahieu, “Nano: A feeless distributed cryptocurrency network,”
URL https://nano.org/en/whitepaper, 2017.

[12] R. G. Brown, “Introducing r3 corda: A distributed ledger designed for
finanial services, 2016,” 2017.

[13] P. Maymounkov and D. Mazieres, “Kademlia: A peer-to-peer informa-
tion system based on the xor metric,” in International Workshop on
Peer-to-Peer Systems. Springer, 2002, pp. 53–65.

[14] B. Cohen, “The bittorrent protocol specification,” 2008.
[15] J. Benet, “Ipfs-content addressed, versioned, p2p file system,” arXiv

preprint arXiv:1407.3561, 2014.
[16] X. Zhang, G. Xue, R. Yu, D. Yang, and J. Tang, “Keep your promise:

Mechanism design against free-riding and false-reporting in crowdsourc-
ing,” IEEE Internet of Things Journal, vol. 2, no. 6, pp. 562–572, 2015.

[17] Q. Stokkink and J. Pouwelse, Deployment of a Blockchain-Based Self-
Sovereign Identity, 1st ed. United States: IEEE, 8 2018, pp. 1336–1342.

[18] D. Riggsby et al., “Electronic portfolio: Assessment, re";"""date"",""2019-01-17T14:01:42Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.5""
""xmp:CreatorTool"",""TeX""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dcterms:created"",""2019-01-17T14:01:42Z""
""language"",""en""
""Last-Modified"",""2019-01-17T14:01:42Z""
""dcterms:modified"",""2019-01-17T14:01:42Z""
""dc:format"",""application/pdf; version=1.5""
""Last-Save-Date"",""2019-01-17T14:01:42Z""
""pdf:docinfo:creator_tool"",""TeX""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2019-01-17T14:01:42Z""
""meta:save-date"",""2019-01-17T14:01:42Z""
""pdf:encrypted"",""false""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016) kpathsea version 6.2.2""
""modified"",""2019-01-17T14:01:42Z""
""pdf:hasMarkedContent"",""false""
""Content-Type"",""application/pdf""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016) kpathsea version 6.2.2""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""trapped"",""False""
""meta:creation-date"",""2019-01-17T14:01:42Z""
""created"",""2019-01-17T14:01:42Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""7""
""Creation-Date"",""2019-01-17T14:01:42Z""
""resourceName"",""paper_camera_ready.pdf""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""1476"",""4191"",""4665"",""4163"",""3671"",""4566"",""6033""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""producer"",""pdfTeX-1.40.17""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""pdfTeX-1.40.17""
""pdf:docinfo:created"",""2019-01-17T14:01:42Z""
";
1619094551-696;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Succinct arguments in the quantum random oracle model;A Chiesa, P Manohar, N Spooner ; Theory of Cryptography Conference, 2019  Springer;;"… uses PCPs and random oracles. More generally, by using random oracles one can

construct a SNARG from a multi-round generalization of PCPs known as interactive

oracle proofs (IOPs) [13, 54]. All of these succinct arguments …";Cité 26 fois;Les 2 versions;[PDF] iacr.org;https://eprint.iacr.org/2019/834.pdf;"
Succinct Arguments in the Quantum Random Oracle Model

Alessandro Chiesa
alexch@berkeley.edu

UC Berkeley

Peter Manohar
pmanohar@cs.cmu.edu

Carnegie Mellon University

Nicholas Spooner
nick.spooner@berkeley.edu

UC Berkeley

January 14, 2020

Abstract

Succinct non-interactive arguments (SNARGs) are highly efficient certificates of membership
in non-deterministic languages. Constructions of SNARGs in the random oracle model are
widely believed to be post-quantum secure, provided the oracle is instantiated with a suitable
post-quantum hash function. No formal evidence, however, supports this belief.

In this work we provide the first such evidence by proving that the SNARG construction of
Micali is unconditionally secure in the quantum random oracle model. We also prove that, anal-
ogously to the classical case, the SNARG inherits the zero knowledge and proof of knowledge
properties of the PCP underlying the Micali construction. We thus obtain the first zero knowl-
edge SNARG of knowledge (zkSNARK) that is secure in the quantum random oracle model.

Our main tool is a new lifting lemma that shows how, for a rich class of oracle games, we can
generically deduce security against quantum attackers by bounding a natural classical property
of these games. This means that in order to prove our theorem we only need to establish classical
properties about the Micali construction. This approach not only lets us prove post-quantum
security but also enables us to prove explicit bounds that are tight up to small factors.

We additionally use our techniques to prove that SNARGs based on interactive oracle proofs
(IOPs) with round-by-round soundness are unconditionally secure in the quantum random oracle
model. This result establishes the post-quantum security of many SNARGs of practical interest.

Keywords: succinct arguments; quantum random oracle model; probabilistically checkable proofs



Contents

1 Introduction 1
1.1 SNARGs with random oracles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Our results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3 Related work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 Techniques 5
2.1 The construction of Micali . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2 Challenges in the quantum setting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3 Outline of our approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.4 From oracle games to database games . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.5 A basic lifting lemma for database games . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.6 Stronger lifting via conditional instability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.7 Instability of the Micali oracle game . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.8 zkSNARKs in the QROM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.9 The BCS construction: succinct arguments beyond Micali . . . . . . . . . . . . . . . . . . . . 12

3 Preliminaries 14
3.1 Quantum notation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.2 Oracle algorithms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.3 Non-interactive arguments in the quantum random oracle model . . . . . . . . . . . . . . . . 15
3.4 Probabilistically checkable proofs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.5 Databases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.6 Compressed phase oracle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

4 From oracle games to database games 18
4.1 The case of classical adversaries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.2 The case of quantum adversaries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

5 A lifting lemma for database games 21
5.1 Database properties and the basic lifting lemma . . . . . . . . . . . . . . . . . . . . . . . . . . 21
5.2 Conditional instability and the lifting lemma . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
5.3 Proof of Lemma 5.10 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

6 Soundness of the Micali construction 30
6.1 Some algorithms for Merkle trees . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
6.2 The oracle game for the Micali construction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
6.3 Proof of Theorem 6.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

7 zkSNARKs in the QROM 35
7.1 Zero knowledge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
7.2 Proof of knowledge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

8 The BCS construction in the QROM 38
8.1 Interactive oracle proofs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
8.2 The BCS construction and its oracle game . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
8.3 Round-by-round soundness and knowledge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
8.4 Our result . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
8.5 Proof of Theorem 8.6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
8.6 On the difference in hash chains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

A Proof of Lemma 3.2 47

B Round-by-round vs. strong round-by-round soundness
An appendix authored by James Hulett (jhulett@berkeley.edu) 48

Acknowledgments 51

References 51



1 Introduction

The design and analysis of cryptographic primitives that are plausibly secure against quantum
attackers is an increasingly important goal. The expected advent of quantum computers demands
the cryptography community to be prepared well in advance, so much so that the National Institute
of Standards and Technology (NIST) is already in the process of selecting, from among many
proposals, a new set of cryptography standards that are “post-quantum” [NIS16]. The proposals
involve schemes for key agreement, public-key encryption, and digital signatures, and are intended
to eventually replace existing standards based on the hardness of factoring or discrete logarithms.

In this paper we study the post-quantum security of a cryptographic primitive that has recently
received much attention across theoretical and applied communities: succinct arguments [GW11].
These are argument systems for non-deterministic languages where the communication complexity
between the prover and verifier is sublinear in the size of the non-deterministic witness.1 This
notion originates in seminal works of Kilian [Kil92] and Micali [Mic00], which construct succinct
arguments for languages in NTIME(T (n)) where communication complexity is poly(Îť, log T (n)) and
the time complexity of the verifier is poly(Îť, n, log T (n)); here Îť is the security parameter.

Researchers have studied many aspects of succinct arguments in the last two decades, leading to
numerous constructions with different tradeoffs [WB15], efficient realizations in code [SCI14; bell15;
SCI18; dalek18; stark18; SCI19; iden19], real-world deployments [Zc14; Co17], and standardization
efforts [ZKP17]. A particularly useful feature is that many succinct arguments can be made zero
knowledge with minimal overhead. At present, however, most approaches to obtain efficient succinct
arguments are “pre-quantum”, since they rely on the discrete logarithm problem (and more).

A notable exception is a class of succinct arguments obtained by combining two ingredients:
(a) probabilistic proof systems, which are unconditionally secure, and (b) cryptographic hash func-
tions, for which we have post-quantum candidates. This class includes the succinct interactive ar-
gument of Kilian [Kil92], which use probabilistically checkable proofs (PCPs) [BFLS91; FGLSS96;
AS98; ALMSS98] and collision-resistant hash functions. It also includes the succinct non-interactive
argument (SNARG) of Micali [Mic00], which uses PCPs and random oracles. More generally, by us-
ing random oracles one can construct a SNARG from a multi-round generalization of PCPs known
as interactive oracle proofs (IOPs) [BCS16; RRR16]. All of these succinct arguments are widely
believed to be post-quantum, provided the hash function is suitably instantiated [BBHR19].2

There is, however, no formal evidence that supports the above widely-held belief. Since suc-
cinct arguments are a fundamental cryptographic primitive with both theoretical and real-world
applications, it is important to prove guarantees on their post-quantum security.

1.1 SNARGs with random oracles

In this paper we focus our attention on the SNARG construction of Micali [Mic00], which is uncon-
ditionally secure in the random oracle model [BR93; PS96]. SNARGs in the random oracle model
are not only plausibly post-quantum secure but also enjoy other desirable features. Namely, the
random oracle can be heuristically instantiated via hash functions that avoid expensive public-key
cryptographic operations. Moreover, the SNARG uses a transparent (public-coin) setup, because
the only public parameter needed to produce/verify proofs is the choice of hash function.

1Achieving communication complexity that is sublinear in the witness size is known to require relaxing soundness
from statistical to computational, provided one assumes standard complexity conjectures [GH98; GVW02].

2There is also a class of lattice-based succinct arguments that is plausibly post-quantum; see Section 1.3.

1



We are thus interested in asking: can we establish formal evidence that the SNARG construction
of Micali is post-quantum secure? One way to establish formal evidence is to prove security in a
quantum analogue of the random oracle model, as we now explain. A quantum attacker can,
among other things, evaluate a hash function in superposition when given the hash function’s
code. This enables the attacker, for instance, to find pre-images [Gro96] or collisions [BHT98]
faster than a classical attacker. In light of this, Boneh et al. [BDFLSZ11] have argued that, in
the quantum setting, the correct way to model a random oracle is to allow the attacker to query
the random oracle in superposition. The resulting model is known as the quantum random oracle
model (QROM), and a line of work has established post-quantum security within this model for a
variety of cryptographic primitives; see, e.g., [BDFLSZ11; Zha12; Zha15; TU16; Eat17].

Our goal is to study the SNARG construction of Micali in the quantum random oracle model.
We also study the SNARG construction of BCS [BCS16], which yields SNARGs of practical interest.

1.2 Our results

The main result of this paper is establishing that the SNARG construction of Micali [Mic00] is
unconditionally secure in the quantum random oracle model. This is the first formal evidence that
supports the widely-held belief that this construction is post-quantum secure when the oracle is
instantiated via a suitable post-quantum hash function.

Theorem 1 (informal). The non-interactive argument of Micali, when based on a PCP with sound-
ness error Îľ, has soundness error O(t2Îľ+ t3/2Îť) against quantum attackers that make t queries to
a random oracle with output size Îť. This soundness error is tight up to small factors.

A key step in our proof, of independent interest, is a Lifting Lemma that shows how, for a rich
class of “oracle games”, we can generically deduce security against quantum attackers by bounding
a natural classical property of these games, instability, that we introduce. This means that to prove
Theorem 1 we only need to bound the instability of the Micali construction. This approach not only
yields the theorem but also enables us to prove explicit bounds that are tight up to small factors.

If we base the Micali construction on suitable PCPs, we obtain new statements about the
existence of post-quantum non-interactive arguments. First, if the PCP achieves (honest-verifier)
zero knowledge and proof of knowledge then through the Micali construction we obtain a zero
knowledge non-interactive argument of knowledge that is unconditionally secure in the quantum
random oracle model. This strengthens a result of Unruh [Unr15], which assumes the existence of
a post-quantum ÎŁ-protocol for NP. Moreover, if the PCP has polylogarithmic query complexity
and verifier running time then we obtain the first construction of a zero knowledge succinct non-
interactive argument of knowledge (zkSNARK) that is secure in the quantum random oracle model.

Theorem 2 (informal). There exists a zero knowledge non-interactive argument of knowledge for
NP in the quantum random oracle model. Moreover, the non-interactive argument is succinct, in
the sense that arguments have size Νc and can be verified in time (Ν ¡ n)c, where Ν is the random
oracle’s security parameter, n is instance size, and c ≥ 1 is a universal constant.

The above theorem is stated for NP only for simplicity. Analogously to the classical case, a
more general statement holds for all non-deterministic time languages by relying on suitable PCPs
for non-deterministic time. For example, the PCP in [BFLS91] achieves proof of knowledge, can be
made (honest-verifier) zero knowledge [DFKNS92; KPT97], and supports general non-deterministic
time computations.

2



The BCS construction. We conclude with a result that demonstrates how the tools in this
paper can be used to study the post-quantum security of protocols that are of practical interest.
Since known PCP constructions are expensive, efficient constructions of succinct arguments in
the random oracle model are typically based on the BCS construction [BCS16], which instead uses
interactive oracle proofs (IOPs) [BCS16; RRR16], a multi-round extension of PCPs. This extension
additionally captures IPs [Bab85; GMR89] and IPCPs [KR08] as special cases.

We prove that the BCS construction is unconditionally secure in the quantum random oracle
model, if applied to public-coin IOPs that have round-by-round soundness [CCHLRR18]. The
resulting argument inherits proof of knowledge and zero knowledge properties of the underlying
IOP.

Theorem 3 (informal). The non-interactive argument of BCS, when based on a public-coin IOP
with round-by-round soundness error Îľ, has soundness error O(t2Îľ + t3/2Îť) against quantum at-
tackers that make t queries to a random oracle with output size Îť. Moreover, it is an argument of
knowledge if the IOP has round-by-round proof of knowledge, and it is a (statistical) zero knowledge
argument if the IOP is honest-verifier zero knowledge.

Round-by-round proof of knowledge is a natural notion that we introduce, analogous to round-
by-round soundness, and is satisfied by many natural protocols. In particular, Theorem 3 enables
us to deduce the post-quantum security of succinct arguments based on well-known IPs such as
the sumcheck protocol [LFKN92] and the GKR protocol [GKR15], as well as zkSNARKs based
on recent IOPs such as [BBHR19; AHIV17; BCRSVW19]. These protocols (among others) are of
interest to practitioners, and our result can be used to guide parameter choices in practice.

1.3 Related work

Argument systems that use random oracles. Several works study the post-quantum security
of zero knowledge non-interactive arguments of knowledge that use random oracles, most notably
those obtained by applying the Fiat–Shamir transformation [FS86] to a post-quantum Σ-protocol.
These are used to achieve post-quantum digital signatures [CDGORRSZ17; KKW18; BN19], and
underlie constructions submitted to the NIST call for post-quantum cryptography [NIS16].

A security reduction for the Fiat–Shamir transformation in the quantum random oracle model
has been recently achieved [DFMS19; LZ19]. Obtaining a security reduction had been elusive, as
the classical approach of rewinding the adversary to reduce to special soundness of the ÎŁ-protocol
does not work for quantum adversaries.3 Before, researchers were only able to prove security if the
underlying ÎŁ-protocol satisfies special properties [DFG13; Unr17; KLS18], or resorted to proving
security for alternative, less efficient, constructions such as the Unruh transformation [Unr15].

The question that we study in this paper is complementary to these prior works. On the one
hand, prior works study the security of the Fiat–Shamir transformation given that the underlying
ÎŁ-protocol is secure against efficient quantum attackers. On the other hand, we study protocols
such as the Micali construction and BCS construction that can be viewed as applying the Fiat–
Shamir transformation to specific public-coin protocols that are known to be unconditionally secure
in the (classical) random oracle model. In particular, we establish unconditional security in the

3Rewinding quantum adversaries is a delicate matter [Wat09] and, more importantly, special soundness does not
imply post-quantum soundness (relative to some oracle) [ARU14]. These difficulties have been circumvented by using
new techniques that enable reducing directly to the (post-quantum) soundness of the underlying ÎŁ-protocol.

3



quantum random oracle model via an approach that considers the protocol as a whole (similarly
to the classical analysis of these protocols).

The foregoing differences are reflected in a technical analysis that departs from prior works.
Most of the effort in this paper is establishing classical security properties of the Micali and BCS
constructions, which we then use to generically deduce their quantum security. This approach,
besides being intuitive, yields tight bounds that can be used to guide parameter choices in practice.

Succinct arguments based on lattices. Several lattice problems are presumed to remain hard
even against quantum adversaries, and researchers have relied on such problems to propose numer-
ous cryptographic constructions that are plausibly post-quantum. A handful of works have used
lattices to achieve various notions of succinct arguments that are plausibly post-quantum. Baum et
al. [BBCPGL18] rely on the short integer solution (SIS) problem to obtain an argument system for
arithmetic circuits where the communication complexity grows with the square-root of circuit size;
the argument system is constant-round, public-coin, and honest-verifier zero knowledge. Boneh et
al. [BISW17; BISW18] and Gennaro et al. [GMNO18] rely on lattice knowledge assumptions to
construct designated-verifier SNARGs for boolean circuits, in the preprocessing model [BCIOP13].
Whether one can use lattices to obtain publicly-verifiable SNARGs remains an open problem.

4



2 Techniques

We discuss the main ideas behind our results. In Section 2.1 we recall the construction of Micali,
and then in Section 2.2 we explain the challenges that arise when trying to prove its security in the
quantum random oracle model. In Section 2.3 we outline our approach to obtain a proof of security
for the Micali construction (Theorem 1); we elaborate on our approach in Sections 2.4 to 2.7.
Finally, in Section 2.8 we discuss how to further establish zero knowledge and proof of knowledge;
we thus obtain the first zkSNARK secure in the quantum random oracle model (Theorem 2).

We conclude in Section 2.9 by explaining how our techniques extend to establish post-quantum
security for the BCS construction applied to many protocols of practical interest (Theorem 3).

2.1 The construction of Micali

The construction of Micali is a transformation that maps any probabilistically checkable proof (PCP)
into a corresponding non-interactive argument in the random oracle model. (See Section 3.4 for
the definition of a PCP, and Section 3.3 for that of a non-interactive argument.) The resulting
non-interactive argument is succinct, i.e. a SNARG, provided the PCP has suitable parameters.

Let (P,V) be a PCP for a relation R with soundness error Îľ, proof length ` over alphabet ÎŁ,
and query complexity q. The honest prover P takes as input an instance-witness pair (x,w) and
outputs a proof string Π: [`] → Σ. The honest verifier V takes as input the instance x, makes q
probabilistic queries to a (possibly malicious) proof string Π̃ : [`]→ Σ, and then accepts or rejects.

The PCP (P,V) for R is used to construct a SNARG (P,V) for R, as follows.
The SNARG prover P takes as input an instance x and witness w. First, P uses the random

oracle h to commit to the proof string Π := P(x,w) via a Merkle tree, obtaining a corresponding
root rt. Second, P applies the random oracle h to the root rt in order to derive randomness r for
the PCP verifier V. Third, P simulates the PCP verifier V with the proof string Π, input x, and
randomness r, in order to deduce the queried locations of Π. Finally, P assembles a SNARG proof
π that contains the root rt, answers to the queries, and an authentication path for each answer.

Observe that the SNARG proof π is succinct because it is small (it has size |π| = O(q · (log |Σ|+
Îť log `)) = OÎť(q) for `, |ÎŁ| = 2O(Îť)) and it is cheap to validate via the algorithm described next.

The SNARG verifier V takes as input an instance x and a (possibly malicious) SNARG proof π̃.
First, V uses the random oracle h to check that each answer in π̃ is certified by an authentication
path relative to the claimed root r̃t. Next, V applies the random oracle h to the root r̃t in order
to derive randomness r̃. Finally, V runs the PCP verifier V on the instance x and randomness r̃,
answering V’s queries using the claimed answers in π̃.

The intuition behind the construction is that the soundness guarantee of a PCP holds only if
the proof string Π̃ to be validated is fixed before the randomness r̃ for the PCP verifier is known,
and for this reason the SNARG prover must derive r̃ by hashing a commitment r̃t to Π̃.

This construction is unconditionally secure in the random oracle model [Mic00; Val08; BCS16]:

Theorem 2.1. The SNARG (P,V) has soundness error O(tÎľ+ t2/2Îť) against (classical) attackers
that make at most t queries to the random oracle. This soundness error is tight up to small factors.

A SNARG obtained via the Micali construction also inherits zero knowledge and proof of knowl-
edge properties of the underlying PCP. We discuss these additional properties and how we establish
them in the quantum setting later on in Section 2.8. We focus on soundness first.

5



2.2 Challenges in the quantum setting

Our goal is to show that the SNARG construction of Micali is unconditionally secure in the quantum
random oracle model. Suppose that P̃ is a t-query quantum prover that convinces the SNARG
verifier V with probability δ (over the random oracle). We wish to construct a malicious PCP
prover P̃ that, using P̃ as a subroutine, outputs a proof string Π̃ : [`]→ Σ that convinces the PCP
verifier V with related probability ξ(δ, t) (here the probability is over the randomness of P̃ and V).

A natural approach to reduce the SNARG prover P̃ to the PCP prover P̃ would be to try to
adapt to the quantum setting the reduction that is used for the classical setting. Below we recall
the classical reduction, and then explain why adapting it to the quantum case is challenging.

The reduction for classical attackers. The reduction from a classical SNARG prover P̃ to a
PCP prover P̃ relies on a straightline extractor, as we now explain.

While the SNARG prover P̃ outputs a short proof π that contains a Merkle root and a few
decommitted values, the PCP prover P̃ must output a “long” proof string Π̃. How can P̃ obtain
all this information from seeing only π? The answer is that, when running P̃ as a subroutine, P̃
observes the queries that P̃ makes to the oracle, and these queries reveal the proof string Π̃.

This is only a caricature of how P̃ actually works, though. The reason is that P̃ need not
produce a query sequence from which P̃ can just read off a proof string Π̃ consistent with the
Merkle root in π. For example, P̃ could try to commit to many possible proof strings “in its head”,
derive the corresponding randomness from each commitment, and then select which commitment
to include in π. Even worse, P̃ could try to commit to a partial proof string Π̃ via an incomplete
Merkle tree and, because the PCP verifier inspects only a small fraction of a proof string, hope
that queries will land to leaves of the Merkle tree that do exist.

The proof of Theorem 2.1 shows that, despite these complications, there is a way for P̃ to
observe all queries and answers of a single execution of the SNARG prover P̃, and then run an
algorithm on these to extract a suitable proof string Π̃.

How to deal with quantum attackers? If we now return to the case where the SNARG prover
P̃ is a quantum attacker, we are immediately confronted with a severe problem. Since P̃ can
query the random oracle in superposition, how can P̃ “observe” queries and answers to the oracle?
If P̃ were to just measure P̃’s query register, P̃ may detect this and stop working. This basic
problem has made obtaining security reductions against quantum attackers that access random
oracles exceedingly difficult when compared to the case of classical attackers. Papers that study
the security of cryptographic primitives in the quantum random oracle model have had to develop
clever techniques to somehow circumvent this problem in various settings of interest.

Most relevant to this paper is a work of Zhandry [Zha19] that introduces compressed oracles,
a set of notions and techniques that enables a quantum algorithm to simulate access to a random
oracle for a quantum attacker. This is achieved by replacing a random oracle h : {0, 1}m → {0, 1}n
with the action of a specially-crafted unitary O that implicitly keeps track of queries. This is a
quantum analogue of when, in the classical setting, a simulator merely observes the queries made by
the attacker and maintains a database of the query-answer pairs. Formally, the classical simulator
keeps track of a database D, which is a partial function D : {0, 1}m ⇀ {0, 1}n. The database
represents the part of the random oracle that has been “revealed” to the attacker by answering
its queries. In the quantum setting, the state space of the quantum attacker is augmented with
registers to store the database, which (loosely) keep track of the database D in superposition, as
it evolves from query to query. Thus, while the original oracle h operates on the state |ψA〉 of the

6



adversary, the unitary O operates on a bipartite state |ψA, ψD〉. This extended state represents a
purification of the mixed state of the adversary induced by choosing the oracle h at random.

One may conjecture that the compressed oracle technique, by virtue of “exposing” a quantum
attacker’s queries, makes proving the quantum security of the Micali construction, or indeed of any
construction that uses random oracles, straightforward. This is, unfortunately, not the case.

For example, the results of [Zha19] on compressed oracles allow us to argue directly that, given
an adversary that outputs a convincing SNARG proof π with high probability, if we measure the
database D after the adversary terminates, then with high probability one can find a convincing
SNARG proof π in the database D. This does not allow us to reduce to soundness of the underlying
PCP, however, because to do that we need to argue that one can extract a PCP proof Π from D
(containing a lot more information than π) that convinces the PCP verifier with high probability.

While the techniques in [Zha19] suffice for analyzing simple protocols like collision finding, it is
not clear how to analyze more complex protocols such as the Micali SNARG, as explained above. In
the next section we describe a general framework for analyzing complex protocols in the quantum
random oracle model.

2.3 Outline of our approach

The ideas that we use in this paper to analyze the Micali construction are almost entirely generic,
and can be used to analyze any oracle game. Informally, given a “base game” G ⊆ Ak×Bk×C, an
adversary with oracle access to a random oracle h wins the oracle game for G if it outputs a tuple
(a,b, c) ∈ G where h(ai) = bi for each i ∈ [k]. Oracle games are a natural notion that captures
many games of interest, such as finding pre-images or finding collisions. Producing a valid proof
in the Micali construction can also be cast as an oracle game,4 and we shall view the soundness
property of the Micali construction as stating that the value (maximum winning probability) of
this game is small (when the statement being proved is false).

Our proof of quantum security consists of two main parts. First, we generically reduce the value
of any oracle game to the instability of the game, a purely classical property of the game that we
introduce. Second, we analyze the instability of the oracle game induced by the Micali construction.
The instability of this oracle game is not too difficult to analyze because it is a classical quantity,
and the “hard work” is crisply, and conveniently, encapsulated within our generic reduction. We
view bounding values of oracle games via instability as the main technical contribution of this paper.

We now elaborate on our approach: in Section 2.4 we recast prior work in the language of oracle
games; in Section 2.5 we explain what is instability and how we use it to bound game values; in
Section 2.6 we introduce conditional instability and use it to prove tighter bounds on oracle game
values; and in Section 2.7 we outline the analysis of instability for the Micali construction.

2.4 From oracle games to database games

We begin with a sequence of three games whose values are closely related. These games play the
role of hybrids in our analysis, and are all defined relative to the given base game G ⊆ Ak×Bk×C.

• Oracle game. This is the game defined earlier that is played in the real world, using a random
oracle h. The adversary wins if it outputs a tuple (a,b, c) ∈ G with h(ai) = bi for each i ∈ [k].

4At a high level, G is the set of all proofs that cause the verifier to accept relative to some oracle; the h(ai) = bi
constraints ensure that the verifier accepts this proof relative to the specific oracle h. For more details, see Section 6.2.

7



• Simulated oracle game. The simulator of Zhandry [Zha19] is used to run the adversary and
its final state is measured, leading to a tuple (a,b, c) and a database D. The adversary wins if
(a,b, c) ∈ G and D(ai) = bi for each i ∈ [k]. (The oracle h : {0, 1}m → {0, 1}n is now replaced
by the database D : {0, 1}m ⇀ {0, 1}n stored by the simulator.)

• Database game. Again the simulator of Zhandry is used to run the adversary, leading to a
tuple (a,b, c) and a database D. However, now we ignore (a,b, c) and only consider D. The
adversary wins if there exists (a′,b′, c′) ∈ G such that D(ai) = bi for each i ∈ [k].

We let ω∗O(G, t), ω∗S(G, t), and ω∗D(G, t) denote the values of the oracle game, simulated oracle game,
and database game against quantum adversaries that make at most t oracle queries.

A result of Zhandry [Zha19, Lemma 5], when stated via the notions above, shows that
√
ω∗O(G, t) ≤√

ω∗S(G, t) +
√
k/2n. Moreover, ω∗S(G, t) ≤ ω∗D(G, t) holds trivially, because winning the simulated

oracle game implies winning the database game, by taking (a′,b′, c′) := (a,b, c). In sum:

Lemma 2.2. For any base game G,√
ω∗O(G, t) ≤

√
ω∗D(G, t) +

√
k/2n .

The above lemma is a conceptualization of prior work, and is the starting point for the technical
contributions of this paper. In particular, the lemma tells us that in order to bound the maximum
winning probability of a quantum adversary in an oracle game (played in the real world) it suffices
to bound the maximum winning probability of the adversary in the corresponding database game.

See Section 4 for more details.

2.5 A basic lifting lemma for database games

We describe how we use a classical quantity I(PG, t) to bound ω∗D(G, t), the maximum winning
probability of any t-query quantum algorithm i";"""date"",""2020-01-14T11:43:46Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""Succinct Arguments in the Quantum Random Oracle Model""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""Succinct Arguments in the Quantum Random Oracle Model""
""modified"",""2020-01-14T11:43:46Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016) kpathsea version 6.2.2""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2020-01-14T11:43:46Z""
""created"",""2020-01-14T11:43:46Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-01-14T11:43:46Z""
""resourceName"",""834.pdf""
""Author"",""""
""producer"",""pdfTeX-1.40.17""
""pdf:docinfo:producer"",""pdfTeX-1.40.17""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""2"",""2"",""0"",""17"",""4"",""1"",""13"",""28"",""25"",""0"",""4"",""0"",""80"",""46"",""62"",""49"",""17"",""34"",""40"",""23"",""41"",""72"",""14"",""64"",""108"",""196"",""226"",""161"",""10"",""32"",""35"",""44"",""11"",""2"",""40"",""40"",""12"",""23"",""26"",""65"",""45"",""69"",""56"",""43"",""1"",""150"",""63"",""37"",""26"",""0"",""0"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2020-01-14T11:43:46Z""
""Last-Modified"",""2020-01-14T11:43:46Z""
""dcterms:modified"",""2020-01-14T11:43:46Z""
""title"",""Succinct Arguments in the Quantum Random Oracle Model""
""Last-Save-Date"",""2020-01-14T11:43:46Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2020-01-14T11:43:46Z""
""meta:save-date"",""2020-01-14T11:43:46Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016) kpathsea version 6.2.2""
""Content-Length"",""653660""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""56""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""1616"",""2591"",""3423"",""3178"",""3214"",""1265"",""3048"",""3324"",""3118"",""2761"",""3007"",""2442"",""2682"",""3293"",""536"",""2481"",""2707"",""2529"",""2028"",""2846"",""2477"",""1939"",""1923"",""2186"",""1747"",""2049"",""1111"",""965"",""1152"",""1032"",""988"",""2847"",""2540"",""2530"",""2486"",""561"",""2701"",""2491"",""2232"",""2723"",""2621"",""2440"",""2186"",""2660"",""2365"",""2356"",""2851"",""470"",""1467"",""2330"",""2701"",""2035"",""3101"",""3471"",""3285"",""2430""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-01-14T11:43:46Z""
";https://scholar.google.com/scholar?start=510&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094558-729;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[PDF][PDF] Indra's Pearls Blockchain to Block Lattice;J Small ;2019 indraspearls.net;;"… In addition the IOTA cryptocurrency intro- duces the concept of a 'tangle' (Popov, 2017) … has to

be validated by more miners or block producers than in a standard blockchain, and those …

transaction to Bob to be confirmed and Bob to withdraw the tokens into fiat or another crypto …";Autres articles;;[PDF] indras-pearls.net;https://www.indras-pearls.net/rails/active_storage/blobs/eyJfcmFpbHMiOnsibWVzc2FnZSI6IkJBaHBIUT09IiwiZXhwIjpudWxsLCJwdXIiOiJibG9iX2lkIn19--ac8e0ff62b3ce217c0cf1f8c745fcf1d0c74483c/Indras_pearls_whitepaper.pdf;"
D
RA
FT

Indra’s Pearls

Blockchain to Block Lattice

John Small

May 20, 2019
Version 0.0.7

Abstract

The elegance and simplicity of Satoshi’s original design of Bitcoin
has proved its worth in the last decade. It does however suffer from a
scaling problem.

Preserving as much of that elegance and simplicity as we should,
we propose sharding a blockchain into a block lattice to ameliorate the
scaling problem. The shards in the lattice are mapped to an abstract
space equiped with a simple Euclidian metric which defines the concept
of distance between shards. Therefore shards have nearest neigbours.
When a new block is created in each shard then as well as using the
hash of the previous block it uses the hashes of the previous blocks of
its nearest neighbours to form a merkle root of hashes which is included
in the new block. This binds all the shards together such that reversing
the work of any shard requires reversing the work of all shards. Each
block receives confirmations when its hash is included in the next block
in the same shard, and also in the next block in neighbouring shards.
This rapidly adds confirmation depth, increases the entropy, and so
achieves finality more quickly.

In a sharded system it’s hard to maintain the abstraction of account
state, but relatively easy to work with transactions as in a UTXO sys-
tem. Therefore it’s a UTXO based system.

We also take the implicit assumptions in existing UTXO systems,
make them explicit and then generalise. This makes it possible to
have most of the features of fungible (ERC20) tokens and non-fungible
(ERC721, ERC1155) tokens and to exchange them in transactions.
The conservation rules of UTXO handle the accounting by default.

We introduce a new consensus method, a modified DPOS system
which partitions the orthogonal vectors implicit in present DPOS sys-
tems. It also uses logarithms of the vectors which favours smaller
producers and hence reduces centralisation. We also describe a way
to allow anyone to claim stakes by presenting a proof that a block is

1



D
RA
FT

invalid.

The next stage will include ideas to extend the type of records from
simple scalar quantities to non-scalars, e.g. durations and geographic
areas. This makes the system ideal for recording and exchanging prop-
erty inside virtual worlds and in the long run in the real world.

This is a draft. It’s a work in progress. The latest version will always be
available at
https://www.indras-pearls.net/about-us/white-paper

Contents

1 Introduction 3

2 Basic concepts 3
2.1 Standard blockchain . . . . . . . . . . . . . . . . . . . . . . . 3
2.2 Prior work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.3 Constructing a block lattice . . . . . . . . . . . . . . . . . . . 5
2.4 Why is it called Indra’s Pearls? . . . . . . . . . . . . . . . . . 10

3 UTXOs vs Account state 13
3.1 Relativity of simultaneity . . . . . . . . . . . . . . . . . . . . 14
3.2 Transactions are fundamental . . . . . . . . . . . . . . . . . . 16

4 An obvious extension to UTXO 17
4.1 Elegance in action . . . . . . . . . . . . . . . . . . . . . . . . 17
4.2 Token creation . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.3 Non-scalar values . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.4 Rights . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.5 Scripting language . . . . . . . . . . . . . . . . . . . . . . . . 19
4.6 Multi-party fair exchange protocol . . . . . . . . . . . . . . . 20

4.6.1 Example: Call Options . . . . . . . . . . . . . . . . . . 21
4.6.2 Merging and splitting tokens. FANIN & FANOUT . . 22

4.7 Principle token for rewards ’IPRL’ . . . . . . . . . . . . . . . 22

5 Inter-shard transfers 23
5.1 One possible method . . . . . . . . . . . . . . . . . . . . . . . 23

6 Block validation & finality 25
6.1 How we calculate ’stake’ . . . . . . . . . . . . . . . . . . . . . 26
6.2 How stake is posted . . . . . . . . . . . . . . . . . . . . . . . 28
6.3 How ’stake’ is used to select who produces a block . . . . . . 28
6.4 Reward incentives . . . . . . . . . . . . . . . . . . . . . . . . 29

2

https://www.indras-pearls.net/about-us/white-paper


D
RA
FT

6.5 Penalties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
6.6 Reward stability . . . . . . . . . . . . . . . . . . . . . . . . . 31
6.7 Centralised or Decentralised? . . . . . . . . . . . . . . . . . . 31
6.8 Fixing the problem of selfish collaboration . . . . . . . . . . . 32

7 Resarch and Development stages 33

8 Conclusion 34

1 Introduction

This paper outlines a natural extension of blockchains into block lattices.
Moving from a blockchain to a block lattice is much easier if it’s UTXO
based. Being UTXO based allows us to extend the UTXO model. Being
sharded forces us to ensure fast finality, which in turn requires a restricted
POS/DPOS system. We identify the new possibilities that open up and
the problems we’re going to face. The project is in an active research and
development. We have a working proof of concept which has actually been
running on up to 15 shards. As the design evolves some ideas will be dis-
carded and others put in their place. I’ve taken the view that perfection is
the enemy of done and so while it’s not perfect it does work.

Some of the idea introduced have been developed or have been suggested
by other groups, however the idea to combine them in one package is unique.
Also the method of probalistiticaly allocating the right to produce a block
according the logarithms of independent vectors forming ’stake’ appears to
be completely novel.

2 Basic concepts

2.1 Standard blockchain

(Nakamoto, 2008) introduced the notion of a chain of blocks of electronic
transactions where each block timestamps the transactions and thus pre-
vents double spending. The basic elements of a block chain are represented
in this figure. Time goes from left to right, each block takes a hash from the
previous block, data for that block and a nonce to create a new block hash,
which is used in the next block.

2.1.0.1 Blockchains are a thermodynamic process. Each block
depends on a hash of the previous block and therefore any change in any
previous block requires rewriting the entire chain of blocks. To create a new
block each participant must prove they’ve peformed computational work by

3



D
RA
FT

Block

Previous Hash nonce

Tx Tx . . . ,

Block

previous hash nonce

Tx Tx ...

Hash

Figure 1: The essential elements of a block chain from (Nakamoto, 2008)

solving a cryptograhic puzzle that depends on the block they’re proposing
to create. The effort required to do the work consumes lots of energy which
is dissipated as heat. Therefore the records in the blockchain are consid-
ered to be irrevocable. From a high level view of the process the fact that
it’s hard to alter previous records is at root because of the Second Law of
Thermodynamics. The Second Law of Thermodynamics accounts for the
asymmetry between past and future and this is why blockchains can create
a sequence of timestamped records.

In this sense mining Bitcoin, or any other cryptocurrency, is a type
of refrigerator that takes a source of low entropy, electricty, and produces
something even lower entropy, a highly ordered stream of electrical signals
and records stored in computer memory, and expels waste heat. The total
entripy always increases, and this is the fundamental reason why it’s hard to
reverse records written into the blockchain. The progressive extension of the
blockchain approximates the increase in entropy by summing the amount of
computational work that went into creating each block. When the chain
splits, clients decide which chain to follow by comparing the total amount
of work, and taking the branch with the most accumulated work, i.e. the
greatest increase of entropy that has occured as a result of the work, and
therefore the hardest to reverse. But...

Entropy can also be increased by expansion in space. That’s why heat
engines work, they heat a gas, the heated gas tries to expand and that expan-
sion is converted into mechanical work. Going from a hot gas in a confined
space to a cooler gas in a larger space increases the entropy. Therefore it
seems obvious and natural to extend the concept of a blockchain as a pro-
gression in a single dimension of time, to a lattice of blocks that increase
entropy by expanding outwards in space.

2.2 Prior work

Since this is such an obvious idea, it’s been suggested before, but rather
surprisingly there seems to be only one active project pursuing develop-
ment of it Kadena (Will Martino, Monica Quaintance, 2018). The idea of
merge mining between shards was suggested in the early stages of Ethereum
but dismissed under the heading ’What are some trivial but flawed ways of

4



D
RA
FT

solving the problem?’ (Ray and Buterin, 2019), though the reasons don’t
apply for this design. Also the notion of exchanging hashes between shards
is making a re-appearence in Ethereum 2.0. The Kadema team were very
dilgent in their background research and dug up one comment from 2014,
now only avaialble in the Web Archive about a braided rope of blockchains
(Marc-André Bélanger, 2014). In addition the IOTA cryptocurrency intro-
duces the concept of a ’tangle’ (Popov, 2017). But that’s not a blockchain
so it’s not directly comparable.

2.3 Constructing a block lattice

To construct a block lattice we have to introduce the concept of space. The
notion of ’expanding outwards’ also requires metric on that space so that
the notion of ’outwards’ has meaning. The simplest way to do this is to
divide up the blockchain into many blockchains, called shards (as in shards
of glass), and map them to a space equiped with a metric such that ’distance’
between shards has a consistent meaning Wikipedia, 2009. With a notion
of distance in place then each shard has closest neighbours. We now require
that each new block depends on the hash of the previous block and also on
the hash of its neighbours. The consequence is that any change to any data
in a block not only propagates forwards in time but also expands outwards
in space, which inceases the entropy much faster and makes things much
harder to reverse.

This is illustrated by removing the details inside the blocks and focusing
on the hash transferred from one block to the next, labeling the block number
with Bj and the hash with Hj we have

Bj Bj+1

Hj

Figure 2: Blockchain showing only the flow of the hashes from one block to
the next block in the sequence

5



D
RA
FT

We then set up many blockchains Bi, and label the j th block in the ith
chain Bi,j and the j th hash in the ith chain Hi,j

Bi,j Bi,j+1

Hi,j
Bi,j+2

Hi,j+1

Bi+1,j Bi+1,j+1

Hi+1,j
Bi,j+2

Hi,j+1

Bi+2,j Bi+2,j+1

Hi+2,j
Bi+2,j+2

Hi+2,j+1

Figure 3: A set of three separate block chains

6



D
RA
FT

Then we arrange for each block to take not only on the hash from the
previous block but also on the hashes from the previous blocks of its nearest
neigbours. It then gets the Merkle root of these and uses that in place of
the traditional previous block hash. This way the shards are tied together.
Notice we’ve introduced the concept of ”nearest neighbour”, which implies
a space of some sort.

Bi,j Bi,j+1

Hi,j
Bi,j+2

Hi,j+1

Bi+1,j

Hi+1,j

Bi+1,j+1

Hi+1,j

Hi,j

Hi+1,j+1

Bi,j+2

Hi+1,j+1

Hi,j+1

Bi+2,j

Hi+2,j

Bi+2,j+1

Hi+2,j

Hi+1,j

Hi+2,j+1

Bi+2,j+2

Hi+2,j+1

Hi+1,j+1

Figure 4: The chains are now interdependent and form a block lattice

2.3.0.1 Estimating the work done. With these modifications in
place we can now estimate how the calculation of the total work done to
produce a block is changed. In the case of a simple chain of blocks the work
done (the difficulty) is simply the work done in this block plus the sum of
the work done in all previous blocks. Let Wn be the total work accumulated
so far to the nth block, let BW be additional work done to produce the new

7



D
RA
FT

block and W(n+1) be the new total work at the n+1th block then we have

Wn+1 = Wi = n + BW (1)

Without too much loss of generality we can make the simplfying as-
sumption that a block lattice is infinite in extent (no edges). Considering
an example where the shards are mapped to a simple 2 dimensional square
lattice. Then each shard will have 8 neighbours. This means that each new
block will accept the hash from 9 previous blocks (its own shard, plus 8
neighbours). That means the total work done to produce a block has to be
summed over all 9 previous blocks. If we assume that producing a block
requires 1 unit of work BW = 1 then equation (1) becomes

WN+1 = (9×Wn) + BW (2)

The so that if W0 = 0 the genesis block, then the first block after that
W1 = 1 , and in the next block W2 = 9 + 1 = 10 which results in this
sequence

1 1
2 10
3 91
4 820
5 7381
6 66430
.. ..
17 2084647712458321

After a few iterations the equation converges to

Wn+1 = 9n (3)

which increases exponentially

This method of calculation is used in (Will Martino, Monica Quaintance,
2018) where they assign ’Merkle mass’ to each layer and comment

Known as Merkle mass..., it is the sum of the mass of the sequen-
tial layer intersections of the cone and it increases at a nearly
exponential rate

But the above method is double counting. Another way to add up the
work is to simply add up only the work added by the blocks a block depends
on. This gets a different figure
1 1
2 1 + 32 = 10
3 10 + 52 = 35
4 35 + 72 = 84

8



D
RA
FT

Let n be the count of the number of the block height, d be the dimension of
the lattice then we have

W =
n∑
1

(1 + 2n)d (4)

When d = 2 it increases only by adding the squares, since we’re adding up
the ’area’ of each preceding layer. Which is sub-exponential.

The two methods seem to be adding up different things, and I’m not
sure which is the correct calculation to use when calculating ’chain with
most work’. Which is required for Proof of Work consensus.

The total entropy, i.e the number of possible combinations, is increasing
exponentially and therefore in a block lattice it quickly becomes very hard
to reverse out any records. Any change in a block in a shard propagates
outwards and become incorporated into the hashes of more and more blocks
in other shards until all shards are affected. The measure of the total work
done is an indirect count of the number of states that have to be explored
to find that partcular state. In a block lattice that number increases expo-
nentially because each new block depends on blocks from more and more
distant shards and the number of possible states rapidly increases.

9



D
RA
FT

2.4 Why is it called Indra’s Pearls?

When deciding on a name for the project I thought it should be something
to do with space, but other projects had taken those names e.g. Chainspace
(Al-Bassam et al., 2017), the Latin word for space ”Ether” is taken, the
Sanskrit word for space ”Akasha” is used by another crypto project. Then
I remembered a nice description of a net of pearls where each one reflects
all the others, which is what happens in a block lattice as described above.

In the heaven of the great god Indra is said to be a vast
and shimmering net, finer than a spider’s web, stretching to the
outermost reaches of space. Strung at each intersection of its
diaphanous threads is a reflecting pearl. Since the net is infinite
in extent, the pearls are infinite in number.

In the glistening surface of each pearl are reflected all the
other pearls, even those in the furthest corners of the heavens.
In each reflection, again are reflected all the infinitely many other
pearls, so that by this process, reflections of reflections continue
without end.

(Mumford et al., 2002, Indra’s Pearls, Cambridge Universtity
Press)

Which is a fairly good analogy of what happens in a block lattice, each
shard in a block lattice is reflected in and is reflected by all the other shards.
Hence the name Indra’s Pearls

2.4.0.1 The consequences for finality. In (Nakamoto, 2008) to
preserve the integrity of the blockchain each miner must check the valid-
ity of the previous block before the start mining the current block. Using
the hash of the previous block in a current block is recognised as sign that
the previous block has been checked and found valid. After approximately 6
rounds of blocks the accumulated work is regarded as being so great it would
be impossible to redo and rewrite the history and the block is accepted as
’final’. In a blockchain the dependency on hashes only carries forwards in
time, but in a block lattice the dependencies spread out through the lattice
as well. The same rule applies, to use the hash of a preceding block in the
same shard and in its neighbours, you have to have validated the block. In
a simple block chain, after n rounds you have n confirmations. But in a
block lattice each round propagates the hash into (1 + 2n)d blocks, where n
is the number of rounds and d the number of dimensions in the lattice. In
our simple 1D block lattice, after 1 step we have 3 confirmations and after
2 rounds 3 + 5 = 8 confirmations. For a 2D lattice this becomes 32 = 9

10



D
RA
FT

confirmations after the first round and 32 + 52 = 34 confirmations after the
second round.

In general the total number of confirmations C after n steps in a d
dimensional lattice is

C =

n∑
1

(1 + 2n)d (5)

Which is the same equation as 4. The result is that a new block has to be
validated by more miners or block producers than in a standard blockchain,
and those block producers can be independent of each other. So the integrity
of records is greater and we get finality more quickly.

2.4.0.2 Preventing 51% attacks. Any Proof of Work (POW) or
Proof of Stake (POS) consensus system which allows anonymous mining or
block production, it’s possible for an anonymous malicious agent with suffi-
cient computing power to rewrite the history. Re-writing the history allows
double spending. For example they can branch off a new chain but keep
it private, in the main chain they make a transaction where Alice sends
tokens to Bob, while in their hidden chain Alice sends tokens to Cynthia.
They wait for a while waiting for enough blocks to be produced on the main
chain for the transaction to Bob to be confirmed and Bob to withdraw the
tokens into fiat or another crypto. Once that’s happened they publish their
hidden chain and because they have more computing power than everyone
else their newly published history has the greatest accumulated work, so it
overrides the main chain and the transaction sending tokens to Bob is wiped
out. This has happend in a number of smaller cryptocurrencies e.g. Verge
and Ethereum Classic (Gareth Johnson, 2019; Reporter, 2018, see) But in
a block lattice that’s very hard to do because no one chain is isolated from
the others. To overpower one shard you have to overpower its neighbours,
and the neighbours of the neighbours and so on to the entire lattice.

(Nakamoto, 2008) includes a calculation of the probability that adver-
sary creating a competing chain can catch up with the main chain. This
calculation has to be modified to work with block lattices. The Kadema
system (Quaintance, Io, and Martino, 2018) proposes a PoW model with
linked shards, similar to Indra’s Pearls. They’ve already extended this cal-
culation to work with a shared system, the proofs are quite complicated but
their summary is;-

...the proof is analogous to the probabilistic double-spend at-
tack analysis in the Nakamoto Bitcoin paper (Nakamoto, 2008)
expanded to the additional dimension of multple chains under
the Chainweb protocol. We present three versions of the

11



D
RA
FT

proof in successive levels of strictness that demonstrate
the viability of Chainweb as an extremely secure proto-
col. (my bolding)

Even so, a PoW system which permits anonymous mining can only ever
achieve probabilistic finality. There is always a small but non-zero proba-
bility that someone will turn up having mined a complete chain which is
longer and has more work. The critical thing is to limit the number of peo-
ple capable of producing blocks, that way we can ensure all potential block
producers are accounted for, and hence ensure that a block is final. This is
discussed in more detail in 6

2.4.0.3 Problems with this approach. Because it’s so hard to
rewrite the history in a block lattice that causes a problem if a network
split ever occurs. We think that network splits ought to be less frequent or
even impossible because every block in a shard has to refer previous blocks
in neighbouring shards, so the entire lattice is tightly tied together. But that
argument is not a proof and it does need to be proved. If a network split
happens and one section of the lattice gets two possible histories, then they’ll
be so tightly tangled up with the rest of the lattice that sorting it out will
be impossible. This is an inherent problem with all consensus mechanisms
that don’t limit the number of potential block producers. There’s always
a non-zero probability that someone can turn up a sequence of blocks that
has more work or more stake and hence require the history to be re-written.
In a block lattice the probability of this happening is much lower than in
a simple block chain, but it is still probabilistic finality. This is a problem
with all chain based finality systems. The alternative is to use some variant
of Byzantive Fault Tolerance consensus systems to assure instant finality.
They have their own issues but by combing the chain (or lattice) based ap-
proach we can get the best of both. See 6

2.4.0.4 The topology of practical block lattices. Real space has
no edges because it’s (probably) infinite but that’s impossible in a finite com-
puting system. Yet we can’t have edges since that means some nodes won’t
have the full complement of neighbours. The simplest thing use toroidal
topology. For a lattice with 1 dimension of space, we create circle by joining
the ends. In 2 dimensions we create a torus and so on to higher dimensions.
Then we can give each shard a unique location on the torus by assigning an
integer address and setting the size of each dimension to be a prime number.
Then the location is defined by the modulus of the address according to the
prime number used for each dimension. So for example an address of 9 in a
5× 7 torus would be 4 along the 5 axis and 2 along the 7 axis. Under a Eu-
clidean metric its closest neighbours have addresses 3, 8, 10, 15, 23, 24, 29, 30

12



D
RA
FT

The Kadema team in (Will Martino, Monica Quaintance, 2018) use a
construction based on a Peterson graph which provides maximal connections
across a minimum span, which is the best solution if restricted to a flat global
topology. It seems much easier just to use a toriodal global topology.

2.4.0.5 Increasing connectedness to enhance security. In (Quain-
tance, Io, and Martino, 2018), the Kadema team analysed cases where an
attacker takes over progressively larger and larger sections of the lattice as
cone of control marching forwards in time. However that proof assumes
only local connections between shards. The security of a block lattice relies
on its interconnectedness. A simple way to increase the connectedness of
a graph is to add a few long distance connections. Therefore we should
add one long range connection to another shard to be used along with the
nearest neighbours when calculating the merkle root of the previous block
hashes. There are many ways to do this, the long range connection could
either be permanent or calculated on the fly. If it’s fixed then the attacker
would know in advance that they also have to overwhelm another shard and
the shards that depend on its blocks in future. So we’ll choose a dynamic
method. The dynamic method will select another shard with deterministic
randomness as follows.

gather the prev ious block hashes from s e l f and ne ighbours
c a l c u l a t e the merkle root from the hashes
f i n d the remainder modulo the s i z e o f the l a t t i c e
choose the shard with address == remainder
add that shard ’ s b lock hash at the same he ight
r e c a l c u l a t e the merkel root

That makes it impossible (in truth very very hard) for an attacker to
take over any one section of a lattice. They have to take over the entire lat-
tice. The Kadema proofs in (Quaintance et al., 2018) need to be extended
to allow for long range connections, this is a research project.

Locating shards on a torus is the easy part, a more serious problem is
that it takes time for information to travel from one shard to another and
this causes an issue with state or account based systems.

3 UTXOs vs Account state

In all computer systems that have parallel processing there is a time delay
moving data from one process to another which makes it hard to agree on
the state of something ’now’. The state of an account in process A might
be X, but another process B running in parallel might alter the state of the

13



D
RA
FT

account to Y , but process A only gets to find out about it after a delay.
The state of something is the total of all past events that affect that thing
summed up to ’now’. In a parallel system there is no universal ’now’. We
have to introduce ways to create a fake ’now’. The usual way to do this
is via locking schemes but the UTXO system avoids all this, it’s inherently
parallelisable since it doesn’t maintain states of accounts

In a single blockchain this doesn’t cause a problem because within each
block there is a consistent ’now’ so we can generate state which rolls up all
past transactions and therefore have a state ’now’. That allows us to have
smart contract code that says

i f ( balanceOf [ address ] > 200) {
doSomething ;
}

But that’s not possible in sharded system because the balance of the address
might be held in different shard to the smart contract. You can’t roll up all
past transactions, because you might not know about some in other shards

3.1 Relativity of simultaneity

The problem is most clearly seen if we rotate diagram 4 anti-clockwise 90◦.
It then matches the standard format for space time diagrams used in physics.
In spacetime it takes time for signals to travel between points separated in
space, in the same way it takes time for signals to travel from one computing
process to another.

14



D
RA
FT

B2,3B1,3 B3,3

B2,2

B2,1B1,1 B3,1

time

space

causal past of E

causal future of E

Now E

Figure 5: Propagation of hashes in a block lattice is analogous to a space
time diagram

In special relativity there’s a name for the problem. It’s called Relativ-
ity of simultaneity Article, 2019 Now, this is critical for understanding
the difference between stateful blockchains such as Ethereum and UTXO
based systems such as Bitcoin.

In a state based system the totality of all past transactions come together
to create the current state of an account, and blocks update the states of
accounts. That’s analogous to all the information from the past coming
together into the central point of the above diagram ’Now’. State based
systems rely on being able to know what the state of an account is at that
moment of ’now’, inside the block being generated. In spacetime there is no
universal ’now’, events that appear simultaneous to one observer might not
be simultaneous for another observer. That’s why it’s called The relativity
of simultaneity, which is the physicists way of saying ”there is no universal

15



D
RA
FT

now”. The analogous situation in a sharded blockchain is that there is no
universal ’now’ for all accounts because they might be in different shards so
you can never write smart contract code like;-

i f ( balanceOf [ address ] > 200) {
doSomething ;

}

Because the account might not be in the same shard as the smart con-
tract and therefore the value is unknown. Which neatly brings us to the
next point.

3.2 Transactions are fundamental

Although this is only an analogy it does illustrate some useful features.
Transactions in a UTXO system map to events in spacetime. The notion of
accounts which hold state are abstractions from the history of past trans-
actions and are therefore a synthesised ’now’. In a single blockchain it’s
relatively easy to manipulate states of accounts because the transactions
happen in the same chain and the block being created defines a ’now’. So
we can have a consistent concept of ’now’ and therefore we can maintain a
consistent abstraction of ’account state’. When transactions that affect the
state of an account happen in many different shards it’s very hard to main-
tain that abstraction, which is why Ethereum 2.0 requires re-engineering
Ethereum to retrofit a transaction layer and has to add layers of complexity
to re-synthesise ’now’

We adopt the approach that we should work with UTXOs not accounts
as that simplyfies things enormously. In some ways each transaction is anal-
ogous to an event between sub-atomic particles which we can visualise with
a Feynman diagram. The basic conservation laws, what goes in must come
out, and the only things that can come out must have the same quantities
as went in. Which is the basic logic of a UTXO transaction

3.2.0.1 Sharding in other account based systems. To comment
adequately on each approach and dig out the problems would take us too
far away from the intent of this paper. This has to be a separate paper.
Suffice to say that each approach uses different and very complex methods
to maintain a synthetic view of the state ’now’. The core fundamental is-
sue is usually buried away in the small print and says effectively ”Oh and
by the way this extra layer holding the state assumes extemely fast connec-
tions between the nodes, and by the way it’s always going to be out of date”.

16



D
RA
FT

3.2.0.2 Synthesising ’now’ in your brain. As an aside, your brain
peforms a similar trick to synthesise the sense of ’now’ from all the different
events going on and messages it’s getting from your senses, and has a sim-
ilar delay problem. In the same way that a sharded account based system
constructs a synthetic ’now’ from all the different transactions going on in
different shards and is behind the time, that sense of ’now’ you experience
is actually behind the time. What you experience as ’now’ is actualy about
half a second behind reality (refs to be provided)

4 An obvious extension to UTXO

Building a UTXO system from scratch gives us the freedom to extend the
concept. Our general philosophy is make explicit what is implicit and then
generalise. For example a Bitcoin transaction contains the implicit under-
standing that it is Bitcoin that is being transferred. In the set of UTXO
records all values are assumed to be refer to the native token, e.g. Bitcoin.

Txn-hash position script to claim the output value

txn-hash 5 <some script> 6

We make that explicit by giving the thing being transferred an id.

Txn-hash position script to claim the output token id value

txn-hash 5 <some script> <some token id> 6

4.1 Elegance in action

We’ve generalised the UTXO method to handle almost any number of dif-
ferent tokens. The basic logic of UTXO, inputs must equal outputs, also
means we get these features for free.

1. The basic logic of UTXO means we can create transactions that ex-
change different tokens between parties.

2. It’s a distributed exchange by default.

3. It treats fungible (ERC-20) and non-fungible tokens (ERC-721) in the
same way.

4. No smart contract code is required to maintain the ledger for a token.

A simple design which accomplishes a lot is Elegance in action.

17



D
RA
FT

4.1.0.1 Prior art. The idea that the basic UTXO protocol of BTC,
ZEC and similar needs to be extended to include more than the base value
of whatever chain has a substantial history starting with the notion of
’colored coins’, (Charlon, Flavien; Andreev, Oleg; Gundry, Devon; azuchi,
Shigeyuki;Dorier, 2014) but that relied on using the existing UTXO struc-
ture and adding extra information into the unlocking script on the output
via an OP RETURN operation. That has problems because it’s using the
script to do something it’s not intended for, and also unless carefully coded,
the OP RETURN data won’t be transferred on to the next transaction, so
a coin can easily lose its color.

Cardano (Jones, 2019) have proposed a similar idea for multiple curren-
cies to be handled at the base UTXO layer in a future version of Cardano
instead at a higher level in smart contract";"""date"",""2019-05-20T18:16:21Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2019-05-20T18:16:21Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017) kpathsea version 6.2.3""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2019-05-20T18:16:21Z""
""created"",""2019-05-20T18:16:21Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-05-20T18:16:21Z""
""resourceName"",""Indras_pearls_whitepaper.pdf""
""Author"",""""
""producer"",""pdfTeX-1.40.18""
""pdf:docinfo:producer"",""pdfTeX-1.40.18""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""1"",""0"",""1"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2019-05-20T18:16:21Z""
""Last-Modified"",""2019-05-20T18:16:21Z""
""dcterms:modified"",""2019-05-20T18:16:21Z""
""title"",""""
""Last-Save-Date"",""2019-05-20T18:16:21Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2019-05-20T18:16:21Z""
""meta:save-date"",""2019-05-20T18:16:21Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017) kpathsea version 6.2.3""
""Content-Length"",""295475""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""37""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""1694"",""1431"",""1722"",""2020"",""1426"",""233"",""884"",""1190"",""923"",""2043"",""2065"",""2329"",""2007"",""1092"",""919"",""1884"",""1494"",""2325"",""1845"",""2183"",""2052"",""2074"",""1572"",""1799"",""2215"",""2044"",""1885"",""2125"",""2217"",""2031"",""2193"",""2162"",""1536"",""1481"",""1768"",""1768"",""224""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-05-20T18:16:21Z""
";https://scholar.google.com/scholar?start=540&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094600-904;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;PKP-based signature scheme;W Beullens, JC Faugčre, E Koussa… ; … on Cryptology in India, 2019  Springer;;"… PKP-DSS is Existential-Unforgeable under Chosen Adaptive Message Attacks (EU-CMA) in the

random oracle model, if: the search version of the Permuted Kernel problem is intractable,. the

hash functions and pseudo-random generators are modeled as random oracles …";Cité 3 fois;Les 4 versions;[PDF] iacr.org;https://eprint.iacr.org/2018/714.pdf;"
PKP-Based Signature Scheme

Ward Beullens1, Jean-Charles Faugère2, Eliane Koussa3, Gilles
Macario-Rat4, Jacques Patarin5, and Ludovic Perret2

1 imec-COSIC, KU Leuven ward.beullens@esat.kuleuven.be
2 INRIA and Sorbonne Universities/UPMC Uni Paris 6

jean-charles.faugere@inria.fr, ludovic.perret@lip6.fr
3 Versailles Laboratory of Mathematics, UVSQ EJKoussa@outlook.com

4 Orange gilles.macariorat@orange.com
5 Versailles Laboratory of Mathematics, UVSQ, CNRS, University of Paris-Saclay,

jpatarin@club-internet.fr

Abstract. In this document, we introduce PKP-DSS: a Digital Signa-
ture Scheme based on the Permuted Kernel Problem(PKP) [23]. PKP is
a simple NP-hard [10] combinatorial problem that consists of finding a
kernel for a publicly known matrix, such that the kernel vector is a per-
mutation of a publicly known vector. This problem was used to develop
an Identification Scheme (IDS) which has a very efficient implementa-
tion on low-cost smart cards. From this zero-knowledge identification
scheme, we derive PKP-DSS with the traditional Fiat-Shamir transform
[9]. Thus, PKP-DSS has a security that can be provably reduced, in the
(classical) random oracle model, to the hardness of random instances
of PKP (or, if wanted, to any specific family of PKP instances). We
propose parameter sets following the thorough analysis of the State-of-
the-art attacks on PKP presented in [17]. We show that PKP-DSS is
competitive with other signatures derived from Zero-Knowledge identi-
fication schemes. In particular, PKP-DSS-128 gives a signature size of
approximately 20 KBytes for 128 bits of classical security, which is ap-
proximately 30% smaller than MQDSS. Moreover, our proof-of-concept
implementation shows that PKP-DSS-128 is an order of magnitude faster
than MQDSS which in its turn is faster than Picnic2, SPHINCS,...
Since the PKP is NP-hard and since there are no known quantum attacks
for solving PKP significantly better than classical attacks, we believe that
our scheme is post-quantum secure.

Keywords: public-key cryptography, Fiat-Shamir, post-quantum cryp-
tography, 5-pass identification scheme, Public-key Signature, Permuted
Kernel Problem.

1 Introduction

The construction of large quantum computers would break most public-key cryp-
tographic schemes in use today because they rely on the discrete logarithm



problem or the integer factorization problem. Even though it isn’t clear when
large scale quantum computation would be feasible, it is important to anticipate
quantum computing and design new public key cryptosystems that are resis-
tant to quantum attacks. Therefore, there currently is a large research effort to
develop new post-quantum secure schemes, and a Post-Quantum Cryptography
standardization process has been initiated by the American National Institute
of Standards and Technology (https://www.nist.gov/). Because of this, there
has been renewed interest in constructing signature schemes by applying the
Fiat-Shamir transform [9] to Zero-Knowledge Identification Schemes. In partic-
ular, we are interested in post-quantum cryptographic schemes whose security
relies on the quantum hardness of some NP-Hard problem [2]. One of those prob-
lems is the Permuted Kernel Problem: the problem of finding a permutation of
a known vector such that the resulting vector is in the kernel of a given matrix.
This is a classical NP-Hard combinatorial problem which requires only simple
operations such as basic linear algebra and permuting the entries of a vector.
For quite some time, no new attacks on PKP have been discovered, which makes
it possible to confidently estimate the concrete hardness of the problem.

In 1989, Shamir [23] introduced a five-pass ZK-Identification scheme, based
on the PKP. This work uses the Fiat-Shamir transform [9] on this identification
scheme to develop a signature scheme that is provably secure in the Random Ora-
cle Model (ROM). However, since our goal is to have a post-quantum scheme, we
should also consider attackers in the Quantum Random Oracle Model (QROM).
The security of the Fiat-Shamir transform in the QROM has been studied in
[27,26,25], where the authors of [27,25] explain that the Fiat-Shamir transform
might not be secure against quantum computers. Thus, new techniques with ex-
tra properties (such as ”lossy IDS”) were developed to obtain a quantum-secure
transform. However, more recently, a number of works have proven the Fiat-
Shamir construction secure in the QROM[26,13] under very mild conditions. So
far, none of these works apply to five-round protocols (which is the kind of proto-
col we are considering in this work), but it is conceivable that the results can be
generalized to five-pass protocols, including ours. We consider this an important
open problem in post-quantum cryptography.

Previous work and State-of-the-art. Since quantum computers are ex-
pected not to be capable of solving NP -Hard problems in sub-exponential time
(in worst case), Zero-knowledge Identification schemes based on such problems
are interesting candidates for Post-Quantum Cryptography. The Fiat-Shamir
transform [9] is a technique that can convert such a zero-knowledge authenti-
cation scheme into a signature scheme. This approach was taken by Chen et
al. [7], who applied the Fiat-Shamir transform to a 5-pass identification scheme
of Sakumoto et al. [22]. This identification scheme relies on the hardness of
the (NP -Hard) problem of finding a solution to a set of multivariate quadratic
equations. Chen et al. proved that, in the random oracle model, applying the
Fiat-Shamir transform to this 5-pass identification scheme results in a secure

2

https://www.nist.gov/


signature scheme. A concrete parameter choice and an efficient implementation
of this signature scheme (which is called MQDSS) were developed, and this was
one of the submissions to the NIST PQC standardization project. At a security
level of 128 bits, the MQDSS scheme comes with a public key of 46 Bytes, a
secret key of 16 Bytes and a signature size of approximately 28 Kilobytes.

A different line of work resulted in the Picnic signature scheme. Chase et
al. [6] constructed this digital signature scheme by applying the Fiat-Shamir
transform to an identification scheme whose security relies purely on symmetric
primitives. At the 128-bit security level Picnic has a public key of 32 Bytes, a
secret key of 16 Bytes and signatures of approximately 33 Kilobytes. There is
a second version of this signature scheme, where the signatures are only 13.5
Kilobytes, but Picnic2 is 45 times slower than the original Picnic for signing and
25 times slower for verification.

Main results. The main contribution of this paper is to present PKP-DSS,
a new post-quantum secure signature scheme. Similar to the approaches cited
above, we use the Fiat-Shamir transform to construct a signature scheme from
the 5-pass PKP identification scheme by Shamir [23]. Following the complex-
ity analysis of the PKP [17], we choose secure parameter sets of the signature
scheme for 128/192/256 of classical security level. To date, there are no known
quantum algorithms for solving PKP (other than combining Grover search with
the classical algorithms), so we claim that our signatures achieve the NIST se-
curity levels I/III and V respectively. However, we recognize that the (quantum)
hardness of PKP deserves more research, and we hope that this work will inspire
researchers to investigate this topic further.

We have developed a constant-time C implementation of the new signature
scheme. By constant-time we mean that the running time and the memory ac-
cess pattern of the implementation are independent of secret material, therefore
blocking attacks from timing side channels. The resulting signature scheme com-
pares well with MQDSS and Picnic/Picnic2. Our scheme is much faster than
MQDSS and Picnic/Picnic2 in terms of signing and verification, we have small
public and private keys, and the signature sizes of our scheme are comparable to
those of MQDSS and Picnic2. This makes our signature scheme based on PKP
competitive with state of the art post-quantum signature schemes.

2 Preliminaries

2.1 The Permuted Kernel Problem (PKP)

The Permuted Kernel Problem (PKP) [23,10] is the problem on which the secu-
rity of PKP-DSS is based. PKP is a linear algebra problem which asks to find

3



a kernel vector of a given matrix under a vector-entries constraint. It’s a gen-
eralization of the Partition problem [10, pg.224]. More precisely, it is defined as
follows:

Definition 1 (Permuted Kernel Problem). Given a finite field Fp, a matrix
A ∈ Fm×np and a n-vector v ∈ Fnp , find a permutation π ∈ Sn such that Avπ = 0,
where vπ = (vπ(1), · · · , vπ(n))

A reduction of the 3-Partition problem proves PKP to be NP-Hard [10].
Moreover, solving random instances of PKP seems hard in practice. In fact, this
is the fundamental design assumption of PKP-DSS. The hardness of PKP comes
from, on the one hand, the big number of permutations, on the other hand, from
the small number of possible permutations that satisfy the kernel equations. Note
that, to make the problem more difficult, the n-vector v should have distinct
coordinates. Otherwise if there are repeated entries, the space of permutations
of v gets smaller. In the next section, we give the best known algorithm to solve
the PKP problem.

Best known algorithms for solving PKP The implementation’s efficiency of
the first IDS, proposed by Shamir [23], based on PKP problem has led to several
solving tools. There are various attacks for PKP, which are all exponential. We
will not describe them here. Instead, we refer to [17] for further details. To
estimate the concrete security of PKP, the authors of [17] review and compare
the efficiency of the best known attacks in terms of the number of operations
performed, for different finite fields. They bring together the Patarin-Chauvaud
attack [21] and Poupard’s algorithm [18] to provide an accurate program. The
paper gives security estimates that we used to pick secure parameters sets for
the Permuted Kernel Problem.

2.2 Commitment schemes

In our protocol, we use a commitment scheme Com : {0, 1}λ×{0, 1}? → {0, 1}2λ,
that takes as input Îť uniformly random bits bits, where Îť is the security pa-
rameter, and a message m ∈ {0, 1}? and outputs a 2Ν bit long commitment
Com(bits,m). In the description of our protocols, we often do not explicitly
mention the commitment randomness. We write S ← Com(m), to denote the
process of picking a uniformly random bit string r, and setting C← Com(r,m).
Similarly, when we write check C = Com(m), we actually mean that the prover
communicates r to the verifier, and that the verifier checks if C = Com(r,m).

We assume that Com is computationally binding, which means that no com-
putationally bounded adversary can produce a r, r′,m,m′ with m 6= m′ such that
Com(r,m) = Com(r′,m′). We also assume that Com is computationally hiding,
which means that for every pair of messages m,m′, no computationally bounded
adversary can distinguish the distributions of Com(m) and Com(m′).

4



2.3 2q-Identification schemes and 2q-extractors

In this paper, we will describe a so-called 2q-Identification Scheme [24]. This is
a 5-round identification scheme, where the first challenge is drawn uniformly at
random from a challenge space of size q, and the second challenge is a ran-
dom bit. Therefore, a transcript of an execution of a 2q-protocol looks like
(com, c, rsp1, b, rsp2). We now state the properties of a 2q-protocol more formally:

Definition 2 (2q-Identification scheme,[24]). A 2q-Identification scheme is
a canonical five-pass identification scheme (KeyGen,P,V) with challenge spaces
Ch1 and Ch2 for which it holds that |Ch1| = q and |Ch2| = 2. Moreover, we
require that the probability that the commitment com take a certain value is a
negligible function of the security parameter.

Definition 3 (Completeness). An Identification scheme (KeyGen,P,V) is cal-
led complete if when both parties follow the protocol honestly, the verifier accepts
with probability 1. That is, we have

Pr

[
(pk, sk)← KeyGen(1λ)
〈P(sk),V(pk)〉 = 1

]
= 1 ,

where 〈P(sk),V(pk)〉 stands for the common execution of the protocol between P

with input sk and V with input pk.

Definition 4 (Soundness with soundness error Îş). An identification sche-
me (KeyGen,P,V) is called Sound with soundness error Îş, if for any probabilistic
polynomial time adversary A, we have

Pr

[
(pk, sk)← KeyGen(1λ)
〈A(1λ, pk),V(pk)〉 = 1

]
≤ κ+ ε(λ) ,

for some negligible function Îľ(Îť).

Definition 5 ((computational) Honest-Verifier Zero-Knowledge). We
say an identification scheme (KeyGen,P,V) is HVZK if there exists a probabilistic
polynomial time Simulator S that outputs transcripts that are computationally
indistinguishable from transcripts of honest executions of the protocol.

Finally, we define the notion of a 2q-extractor, which is an algorithm that
can extract the secret key from 4 transcripts that satisfy some properties. This
is useful because when there exists a 2q-extractor for a 2q-Identification scheme,
this implies that the identification scheme has soundness with knowledge error
at most q+1

2q . Moreover, this implies that applying the Fiat-Shamir transform to
the identification scheme results in a secure signature scheme.

5



Definition 6 (2q-extractability). We say a 2q-identification scheme
(KeyGen, P, V) has 2q-extractability, if there exists a polynomial-time algorithm

that given four transcripts (com, c(i), rsp
(i)
1 , b(i), rsp

(i)
2 ) for i from 1 to 4, such that

c(1) = c(2) 6= c(3) = c(4)

rsp
(1)
1 = rsp

(2)
1 rsp

(3)
1 = rsp

(4)
1

b(1) = b(3) 6= b(2) = b(4)

can efficiently extract a secret key.

Theorem 1 ([24], Theorem 3.1 and Theorem 4.3). A 2q-extractable 2q-
identification scheme is sound with knowledge error at most q+1

2q . Moreover, ap-
plying the Fiat-Shamir transform to such an identification scheme results in a
EUF-CMA secure signature scheme in the Random Oracle Model.

3 Identification scheme (IDS) based on PKP

In this section, we first present the 5-pass Zero-Knowledge Identification Scheme
(ZK-IDS) based on the computational hardness of PKP [23,19], noted here PKP-
IDS. Then, we introduce our optimized version of PKP-IDS and we prove that
the optimized identification scheme is secure.

3.1 The original 5-pass PKP IDS

In this section, we present the original PKP-IDS [23,19], and we propose its
slightly modified version. It consists of three probabilistic polynomial time algo-
rithms IDS =

(
KeyGen, P, V

)
which we will describe now.

Generation of the public key and secret key in PKP-IDS. The users
first agree on a prime number p, and on n,m, the dimensions of the matrix A.
The public-key in PKP-IDS is an instance of PKP, a solution to this instance is
the secret-key. Thus, the prover picks a (right) kernel-vector w ∈ Ker(A), then
randomly generates a secret permutation of n elements sk = π and finishes by
computing v = wπ−1 . We summarize the key generation algorithm in Alg. 1.

5-pass identification protocol: Prover P and Verifier V.
The prover and verifier are interactive algorithms that realize the identification
protocol in 5 passes. The 5 passes consist of one commitment and two responses
transmitted from the prover to the verifier and two challenges transmitted from
the verifier to the prover. The identification protocol is summarized in Alg. 2.

6



Algorithm 1 KeyGen(n,m,p)

A
$←− Fm×np

w
$←− Ker(A)

π
$←− Sn

v← wπ−1

Return (pk = (A,v), sk = π)

Algorithm 2 The original 5-pass PKP identification protocol

P(sk, pk) V(pk)

σ
$←− Sn

r
$←− Fnp

C0 ← Com(σ,Ar)
C1 ← Com(πσ, rσ)

C0,C1−−−−→
c

$←− Fp

z← rσ + cvπσ

c←−−−−

z−−−−→
b

$←− {0, 1}

if b = 0 then
rsp← σ

else
rsp← πσ

end if

b←−−−−

rsp−−→
if b = 0 then

accept if C0 = Com(σ,Azσ−1)
else

accept if C1 = Com(πσ, z− cvπσ)
end if

7



Theorem 2. PKP-IDS is complete, moreover, if the used commitment scheme
is computationally hiding then PKP-IDS is computationally honest-verifier zero-
knowledge and if the commitment scheme is computationally binding, then
PKP-IDS is sound with soundness error Îş = p+1

2p .

Proof. We refer to [23] for the complete proof.

In such ZK-IDS, it is usually possible to cheat if a cheater can correctly guess
some challenges, so there is a nonzero probability (called the soundness error)
that the verifier accepts the proof, even though the prover does not know the
witness. In the case of PKP-IDS, this soundness error is p+1

2p . Thus, it is necessary
to repeat the protocol several times to reduce the probability of fraud. Sequen-
tially repeating the zero-knowledge proof N times results in an Identification
scheme with knowledge error Îşrepeated = ÎşN , hence it suffices to repeat the
protocol dÎť/ log2( 2p

p+1 )e times to get a soundness error κ ≤ 2−λ. The systems
are constructed such that executing the protocol does not reveal any secrets
(Zero-knowledge).

3.2 The modified version of PKP-IDS

We now describe several optimizations to reduce the communication cost of
the identification scheme, as well as the computational cost of the algorithms.
We will start by explaining a few standard optimizations that are common for
identification protocols based on zero-knowledge proofs. Then, we will explain
some novel optimizations that apply to the specific context of PKP-IDS.

Hashing the commitments. In the commitment phase of the protocol,

instead of transmitting all the 2N commitments C
(1)
0 ,C

(1)
1 , ¡ ¡ ¡ ,C(N)

0 ,C
(N)
1 the

prover can just hash all these commitments together with a collision resistant

hash function H and only transmit the hash h = H(C
(1)
0 , ¡ ¡ ¡ ,C(N)

1 ). Then, the

prover includes the N commitments C
(i)
1−bi in the second response. Since the ver-

ifier can reconstruct the Cibi himself, he now has all the 2N commitments, so he
can hash them together and check if their hash matched h. With this optimiza-
tion, we reduce the number of communicated commitments from 2N to N , at
the cost of transmitting a single hash value.

Use seeds and PRG. Instead of directly choosing the permutation σ at
random, we can instead choose a random seed of Îť bits and use a PRG to expand
this seed into a permutation σ. This way, instead of transmitting σ, we can just
transmit the Îť-bit seed. This reduces the communication cost per permutation
from log2(n!) bits to just Îť bits. For example for 128-bits of security, we have
n = 69, so the communication cost per permutation drops from log2(69!) ≈ 327
bits to just 128 bits.

8



Matrix A in systematic form. Now we get to the PKP-IDS-specific opti-
mizations. With high probability, we can perform elementary row operations on
A to put it in the form

(
Im A′

)
, for some (n −m)-by-m matrix A′. Since row

operations do not affect the right kernel of A, we can just choose the matrix A
of this form during key generation, without affecting the security of the scheme.
This makes the protocol more efficient because multiplying by a matrix of this
form requires only (n−m) ∗m multiplications instead of n ∗m multiplications
for a general matrix multiplication.

Optimizing key generation. It is of course not very efficient to include in
the public key the matrix A =

[
cAi , i ∈ {1, ¡ ¡ ¡ ,n}

]
, where cAi is the i-th column

of A. The first idea is to just pick a random seed, and use a PRG to expand this
seed to obtain the matrix A. The public key then consists of a random seed, and
the vector v of length n. However, we can do slightly better than this. We can
use a seed to generate A* which is formed by the first n−1 columns cA1 , · · · , cAn−1
of A and the vector v. Then we pick a random permutation π, and we solve for
the last column cAn of A such that vπ is in the right kernel of A. Now the public
key only consists of a seed and a vector of length m (instead of a vector of length
n). Another important advantage of this approach is that we do not need to do
Gaussian elimination this way (and if fact this was the motivation behind this
optimization). The optimized key generation procedure is given in Alg. 3.

Algorithm 3 KeyGen(n,m,p)

sk.seed←− Randomly sample λ bits
(seedπ, pk.seed)←− PRG0(sk.seed)
π ←− PRG1(seedπ)
(A∗,v)←− PRG2(pk.seed)
Compute cAn from A∗ and vπ
sk←− sk.seed
pk←− (pk.seed, cAn )
Return (pk, sk)

Sending seeds instead of permutations. Because of the second optimiza-
tion, we can send a Ν-bit seed instead of σ, if the challenge bit b = 0. However,
in the case b = 1, we still need to send the permutation πσ, because we cannot
generate both σ and πσ with a PRG. However, this problem can be solved. We
can generate rσ with a PRG, and then we can send this seed instead of πσ. This
seed can be used to compute πσ, because if the verifier knows z and rσ, then he
can compute z−rσ = cvπσ. And since v and c are known, it is easy to recover πσ
from cvπσ (we choose the parameters such that the entries of v are all distinct, so
there is a unique permutation that maps v to vπσ). Moreover, sending the seed

9



for rσ does not reveal more information than sending πσ, because given z and
πσ it is trivial to compute rσ, so this optimization does not affect the security of
the scheme. However, there is a problem: If c = 0, then the cvπσ = 0, and so the
verifier cannot recover πσ. To solve this problem we just restrict the challenge
space to Fp \ {0}. This increases the soundness error to p

2p−2 (instead of p+1
2p ),

but this is not a big problem. An important advantage of this optimization is
that the signature size is now constant. Without this optimization, a response
to the challenge b = 0 would be smaller than a response to b = 1. But with
the optimization, the second response is always a random seed, regardless of the
value of b. We summarize the one round of the optimized IDS modified version
in Algorithm 4.

Algorithm 4 The modified 5-pass of PKP-IDS

P(sk, pk) V(pk)

seed0, seed1
$←− {0, 1}λ

σ ←− PRG1(seedσ)
rσ ←− PRG2(rσ.seed)
C0 ← Com(σ,Ar)
C1 ← Com(πσ, rσ)

C0,C1−−−−→
c

$←− Fp \ {0}

z← rσ + cvπσ

c←−−−−

z−−−−→
b

$←− {0, 1}

rsp← seedb

b←−−−−

rsp−−→
if b = 0 then
σ ← PRG1(rsp)
accept if C0 = Com(σ,Azσ−1)

else
rσ ← PRG2(rsp)
if z−rσ is not a permutation of cv
then

Return reject
else

Let ρ ∈ Sn such that cvρ = z−rσ.
end if
accept if C1 = Com(ρ, rσ)

end if

10



3.3 Security proof of the optimized Scheme

Theorem 3. – The modified version of PKP-IDS is complete.
– If the commitment scheme is computationally binding, then the scheme is

sound with soundness error Îş = p
2p−2 .

– If the used commitment scheme is computationally hiding and the output
of PRG1 and PRG2 is indistinguishable from uniform randomness, then the
scheme is computationally honest-verifier zero-knowledge.

Proof. Completeness. In the case b = 0, if the prover acts honestly, then the
commitment check will succeed if Ar = Az−1σ = A(r + vπσσ−1), which holds if
and only if Avπ = 0. Therefore, if π is a solution to the PKP problem, then the
verifier will accept the transcript. In an honest execution with b = 1 the verifier
will always accept, regardless of whether π was a solution to the PKP problem
or not.

Soundness. First, we prove that the scheme has a q2-extractor [24]. That
is, we show that, given four accepted transcripts (C0,C1, c

(i), z(i), b(i), rsp(i)) for
i from 1 to 4, such that

c(1) = c(2) 6= c(3) = c(4)

z(1) = z(2) z(3) = z(4)

b(1) = b(3) 6= b(2) = b(4)

one can efficiently extract a solution for the PKP problem.

By relabeling the transcripts if necessary, we can assume that b(1) = b(3) = 0
and b(2) = b(4) = 1. Let us first look at transcripts 1 and 3. Let σ = PRG1(rsp(1))

and σ′ = PRG1(rsp(3)), and let x = Az
(1)
σ−1 and x′ = Az

(3)
σ′−1 . Then, because both

transcripts are accepted, we have

C0 = Com(σ,x) = Com(σ′,x′).

Therefore, the computationally binding property of Com implies that with
overwhelming probability we have σ = σ′ and x = x′.

Now, lets look at transcripts 2 and 4. Let y = PRG2(rsp(2)) and y′ =
PRG2(rsp(4)). Since both transcripts are accepted, we know that z(2) − y and
z(4) − y′ are permutations of c(2)v and c(4)v respectively. Let ρ and ρ′ be the
permutations such that c(2)vρ = z(2) − y and c(4)v′ρ = z(4) − y′. Since both
transcripts are accepted, we have

C1 = Com(ρ, y) = Com(ρ′, y′) ,

11



so the computationally binding property of Com implies that with overwhelming
probability we have ρ = ρ′ and y = y′. Now, we put everything together to get

0 = A(z
(1)
σ−1 − z

(3)
σ−1)

= A(z
(2)
σ−1 − z

(4)
σ−1)

= A(c(2)vρσ−1 − yσ−1 − c(4)vρσ−1 + yσ−1)

= (c(2) − c(4))Avρσ−1 .

Since c(2) − c(4) is nonzero, this means that ρσ−1 is a solution to the permuted
kernel problem. Moreover the extractor can efficiently extract this solution, be-
cause he can extract ρ from either transcript 2 or 4, and he can extract σ from
either transcript 1 or 3.

It is known that 2q-extractability implies soundness with error q+1
2q , where

q is the size of the first challenge space [22,24]. In our case, the first challenge
space has p− 1 elements, so the optimized IDS has soundness error p

2p−2 .

Honest-Verifier Zero-knowledge. To prove Honest-Verifier Zero-Knowle-
dge we construct a simulator that outputs transcripts that are computation-
ally indistinguishable from transcripts of honest executions of the identification
scheme. First, the simulator picks a uniformly random value c ∈ Fp \ {0} and a
uniformly random bit b. We treat the cases b = 0 and b = 1 separately.

Case b = 0 : The simulator picks a random seed seed0, a uniformly random
vector z, and computes σ = PRG1(seed0) and C0 = Com(σ,Az). The simu-
lator also commits to a dummy value to get C1. Now the simulator outputs
(C0,C1, c, z, b, seedσ).

This distribution is indistinguishable from honestly generated transcripts
with b = 0. Indeed, the values c, z, seed0 are indistinguishable from uniformly
random in both the simulated transcripts and the honest transcripts (here we
use the assumption that the output of PRG2 is indistinguishable from the uni-
form distribution). The first commitment C0 = Com(σ,Azσ−1) is a function of
seed0 and z, so it also has the same distribution in the simulated and the honest
transcripts. Finally, the commitment C1 is never opened, so the computationally
hiding property of Com guarantees that C1 in the simulated transcript is com-
putationally indistinguishable from the C1 in an honest transcript.

Case b = 1 : The simulator picks a uniformly random seed seed1 and a
uniformly random permutation ρ and computes rσ = PRG2(seed1), z = cvρ+ rσ
and C1 = Com(). The simulator also commits to a dummy value to produce a
commitment C0, then the simulator outputs the transcript (C0,C1, c, z, b, seed1).

We now show that the simulated transcripts are indistinguishable from hon-
estly generated transcripts with b = 1. It is clear that c and seed1 are uni-
formly random in both the simulated transcripts and the honestly generated

12



transcripts. Moreover, in both the simulated and the real transcripts, z is equal
to PRG2(seed1) + cvρ, and C1 = Com(ρ,PRG2(seed1)) where ρ is indistinguish-
able from a uniformly random permutation (here we need the assumption that
the output of PRG1 is indistinguishable from a uniformly random permutation).
Therefore z and C1 have the same distribution in the simulated and the hon-
est transcripts. Finally, the computationally hiding properties of Com guarantee
that the value of C0 in the simulated transcripts is indistinguishable from that
of C0 in honestly generated transcripts.

3.4 Communication cost

We can now provide the communication complexity of N rounds of the modified

IDS, of which the soundness error is
(

p
2p−2

)N
. The commitment consists of a

single hash value, which is only 2Îť bits. The first response consists of N vectors
of length n over Fp, so this costs Nndlog2 pe bits of communication. Lastly,
the second responses consist of N random Îť-bit seeds, N commitments (which
consist of 2Îť bits each) and N commitment random strings (which consist of Îť
bits each), so this costs 4NÎť bits of communication. In total, the communication
cost (ignoring the challenges) is

2Îť+N (ndlog2 pe+ 4Îť) .

4 Digital signature scheme (DSS) based on PKP

We present here the main contribution of this work which is to construct a digital
signature scheme, based on the PKP problem, from the optimized IDS defined
in Section 3. This is simply a direct application of the well-known Fiat Shamir
transformation [9].

The key generation algorithm is identical to the key generation algorithm
for the identification scheme. To sign a message m, the signer executes the first
phase of the commitment scheme to get a commitment com. Then he derives the
first challenge c = (c1, ¡ ¡ ¡ , cN ) from m and com by evaluating a hash function
H1(m||com). Then he does the next phase of the identification protocol to get the
N response vectors rsp1 = (z(1), ¡ ¡ ¡ , z(N)). Then he uses a second hash function
to derive b = (b1, . . . , bN ) from m, com and rsp1 as H2(m||com, rsp1). Then
he finishes the identification protocol to obtain the vector of second responses
rsp2 = (rsp(1), ¡ ¡ ¡ , rsp(N)). Then, the signature is simply (com, rsp1, rsp2).

To verify a signature (com, rsp1, rsp2) for a message m, the verifier simply uses
the hash function H1 and H2 to obtain c and b respectively. Then, he verifies
that (com, c, rsp1,b, rsp2) is a valid transcript of the identification protocol.

13



Algorithm 5 Sign(sk,m)

1: derive A,v and π from sk.
2: for i from 1 to N do
3: pick Îť-bit seeds seed

(i)
0 and seed

(i)
1 uniformly at random

4: σ(i) ← PRG1(seed
(i)
0 )

5: r
(i)
σ ← PRG2(seed

(i)
1 )

6: C
(i)
0 = Com

(
σ(i),Ar(i)

)
,

7: C
(i)
1 = Com

(
πσ(i), r

(i)
σ

)
.

8: end for
9: com := Hcom

(
C
(1)
0 , C

(1)
1 , ¡ ¡ ¡ ,C(N)

0 , C
(N)
1

)
10: c(1), · · · , c(N) ← H1

(
m||com

)
. ci ∈ Fp \ {0}

11: for i from 1 to N do
12: z(i) ← r

(i)
σ + c(i)vπσ(i)

13: end for
14: rsp1 ← (z(1), · · · , z(N))
15: b(1), · · · , b(N) ← H2(m||com||rsp1)
16: for i from 1 to N do
17: rsp

(i)
2 ← (seed

(i)

b(i)
||C(i)

1−b(i))

18: end for
19: rsp2 ← (rsp2

(1), ¡ ¡ ¡ , rsp2(N))
20: Return (com, rsp1, rsp2)

Algorithm 6 Verify(m, pk, σ = (com, rsp1, rsp2))

1: c(1), · · · , c(N) ← H1

(
m||com

)
.

2: b(1), · · · , b(N) ← H2(m||com||rsp1)
3: Parse rsp1 as z(1), ¡ ¡ ¡ , z(N)

4: Parse rsp2 as seed(1), ¡ ¡ ¡ , seed(N),C
(1)

1−b(1) , · · · ,C
(N)

1−b(N)

5: for i from 1 to N do
6: if b(i) = 0 then
7: σ(i) ← PRG1(seed(i))

8: C
(i)
0 ← Com(σ(i),Az

σ(i)−1)
9: else

10: r
(i)
σ ← PRG2(seed(i))

11: if z(i) − rσ is not a permutation of cv then
12: Return reject
13: else
14: πσ(i) ← the permutation that maps cv to z(i) − rσ.
15: end if
16: C

(i)
1 ← Com(πσ(i), r

(i)
σ )

17: end if
18: end for
19: com′ := Hcom

(
C
(1)
0 , C

(1)
1 , ¡ ¡ ¡ ,C(N)

0 , C
(N)
1

)
20: Return accept if and only if com = com′

14



The signing and verification algorithms are displayed in Algorithm 5 and 6
in more detail.

We then get the same security result as Th. 5.1 in [7].

Theorem 4. PKP-DSS is Existential-Unforgeable under Chosen Adaptive Mes-
sage Attacks (EU-CMA) in the random oracle model, if

– the search version of the Permuted Kernel problem is intractable,
– the hash functions and pseudo-random generators are modeled as random

oracles,
– the commitment functions are computationally binding, computationally hid-

ing, and the probability that their output takes a given value is negligible in
the security parameter.

The proof is the same as in [7].

4.1 Generic attack

If the number of iterations N is chosen such that ( p
2p−2 )N ≤ 2−λ, then the

cheating probability of the identification protocol is bounded by 2−λ. However,
a recent attack by Kales and Zaverucha on MQDSS reveals that this does not
meant that the Fiat-Shamir signature scheme has Îť bits of security [16]. They
give a generic attack that also applies to PKP-DSS. The attack exploits the fact
that if an attacker can guess the first ch";"""date"",""2019-10-28T10:00:05Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2019-10-28T10:00:05Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017) kpathsea version 6.2.3""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2019-10-28T10:00:05Z""
""created"",""2019-10-28T10:00:05Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-10-28T10:00:05Z""
""resourceName"",""714.pdf""
""Author"",""""
""producer"",""pdfTeX-1.40.18""
""pdf:docinfo:producer"",""pdfTeX-1.40.18""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""10"",""12"",""4"",""0"",""2"",""6"",""0"",""16"",""2"",""6"",""14"",""7"",""2"",""2"",""7"",""0"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2019-10-28T10:00:05Z""
""Last-Modified"",""2019-10-28T10:00:05Z""
""dcterms:modified"",""2019-10-28T10:00:05Z""
""title"",""""
""Last-Save-Date"",""2019-10-28T10:00:05Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2019-10-28T10:00:05Z""
""meta:save-date"",""2019-10-28T10:00:05Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017) kpathsea version 6.2.3""
""Content-Length"",""455443""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""21""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""2003"",""2788"",""2242"",""2254"",""1855"",""1709"",""331"",""2183"",""1976"",""1016"",""1580"",""2159"",""2043"",""1025"",""1633"",""1600"",""2059"",""1581"",""1820"",""2751"",""1290""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-10-28T10:00:05Z""
";https://scholar.google.com/scholar?start=720&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094651-1129;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Aktuelle und geplante Anwendungsfelder;R Wilkens, R Falk ; Smart Contracts, 2019  Springer;;"… die teilweise erforderliche Einbindung sog. Oracles (siehe Abschn. 3.2.2.4. ) läuft einem

mit der Blockchain-Technologie verfolgten Hauptziel zuwider, da die Notwendigkeit

des Vertrauens in Dritte gerade überwunden werden sollte; …";;null;null;;;;https://scholar.google.com/scholar?start=940&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094537-640;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[PDF][PDF] Blockchain in office building transactions;HPH Wouda ; pure.tue.nl;;"… Although, blockchain technology is what builds digital records of physical and contractual inform-

ation, it does also come with challenges … Currently, the correctness of documents need to be

validated by validating nodes (oracles) in the network, due to the lack of standardization …";Autres articles;;[PDF] tue.nl;https://pure.tue.nl/ws/portalfiles/portal/122361217/Wouda_2019.pdf;"
 Eindhoven University of Technology

MASTER

Blockchain in office building transactions

Wouda, H.P.

Award date:
2019

Link to publication

Disclaimer
This document contains a student thesis (bachelor's or master's), as authored by a student at Eindhoven University of Technology. Student
theses are made available in the TU/e repository upon obtaining the required degree. The grade received is not published on the document
as presented in the repository. The required complexity or quality of research of student theses may vary by program, and the required
minimum study period may vary in duration.

General rights
Copyright and moral rights for the publications made accessible in the public portal are retained by the authors and/or other copyright owners
and it is a condition of accessing publications that users recognise and abide by the legal requirements associated with these rights.

            • Users may download and print one copy of any publication from the public portal for the purpose of private study or research.
            • You may not further distribute the material or use it for any profit-making activity or commercial gain

https://research.tue.nl/en/studentthesis/blockchain-in-office-building-transactions(2548f1c9-fe04-4d9d-b6c8-a0841291cb0d).html


Blockchain in o�ce

building transactions

Master Thesis

H.P. (Hugo) Wouda

Department of the Built Environment (BE),

Industrial Engineering & Innovation Sciences (IE&IS)

Master Construction Management and Engineering

Final version

Amsterdam, Tuesday 12
th

February, 2019



Intentionally blank



Title
Blockchain in o�ce building transactions

A design science research towards the implementation of blockchain technology in the
transaction process of an o�ce building.

Master Thesis

Author
H.P. (Hugo) Wouda

ID: 0974255
Hugo.wouda@live.nl

University
Eindhoven University of Technology

Master Construction Management and Engineering

Graduation Committee
Academic supervisors

Prof. dr. ir. B. (Bauke) de Vries – Eindhoven University of technology
Dr. R.J.G. (Raymond) Opdenakker – Eindhoven University of technology

Dr. Q. (Qi) Han – Eindhoven University of technology

Company supervisor
F. (Frank) Kerstens - ABN AMRO N.V.



”The best way to predict the future, is to create it.”

- Abraham Lincoln

Blockchain in o�ce building transactions iv



Preface

Where everything started ’Zuidhorn’, Groningen.

Once my hometown, but also the first municipality in the Netherlands to introduce a blockchain
application (’Het Kindpakket ’), or at least they thought it was blockchain. Zuidhorn is no excep-
tion. Up to 80% of the initial coin o↵erings conducted in 2017 were scams (Satis Group LLC,
2018). Blockchain is a buzz word, a hype, with an underlying technology that is interesting, but
much of enthusiasm for this technology is because people lack of knowledge and incomprehension
of the technology.

’Blockchain technology – the solution for everything, but what is the problem?’

Although recent studies have examined the possibilities of applying blockchain technology, ap-
plications remain unclear. In this research, blockchain technology is proposed as a solution for
the problem: how to improve the transaction process of an o�ce building. It aims to identify the
challenges currently faced, and suggests how blockchain technology can solve them.

Plenty of people contributed to and supported the writing of this thesis. Firstly, I would like to
o↵er my gratitude to Frank Kerstens and Ruud Boots for keeping me on track during the writing
of my thesis. Pursuing my ideas freely and giving advice form a business perspective, was very
helpful. Also, I would like to thank my graduation buddy Dagmar Bokkinga for the writing days.

Additionally, I would like to o↵er my gratitude towards my TU/e supervisors Bauke de Vries and
Raymond Opdenakkker, for giving advice and support from an academic perspective on a topic
which is not very common within scientific research and the faculty of Construction Management
& Engineering. Without them, it would have been a lot more di�cult to complete this thesis.

Last, but definitely not least, at a personal level, I would like to thank my parents and brothers
– Ton, Ineke, Wijnand and Lodewijk Wouda – and in especially my girlfriend Diede, for their
support and motivation throughout my study and research. Looking back on the past couple of
years, this master thesis has formed a nice ending for my time as a student!

I hope reading this report is interesting and inspires you towards the implementation of blockchain
technology in the real estate sector.

Hugo Wouda
February 2019, Amsterdam

Blockchain in o�ce building transactions v



Blockchain in o�ce building transactions vi



Table of Contents

Management summary x

Management summary (Dutch) xii

Abstract xv

Abbreviations xvi

List of Figures xvii

List of Tables xviii

1 Introduction 1
1.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Problem definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3 Research question . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.4 Scientific relevance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.5 Practical relevance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.6 Reading guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2 Commercial real estate transaction process 7
2.1 What is commercial real estate? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.1.1 Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1.2 Characteristics of commercial real estate . . . . . . . . . . . . . . . . . . . . 8
2.1.3 Transaction market . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.2 Transaction process of an o�ce building . . . . . . . . . . . . . . . . . . . . . . . . 10
2.2.1 Actor roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2.2 Transaction phases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2.3 Information flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.3 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3 Blockchain technology 17
3.1 Blockchain basics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.1.1 Core components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.1.2 Blockchain types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.2 Blockchain tokens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.2.1 What are blockchain tokens? . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.2.2 Real-world asset tokens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.2.3 Blockchain tokens in practice . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.3 Benefits and limitations of blockchain technology . . . . . . . . . . . . . . . . . . . 25
3.4 Blockchain based transaction process . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.5 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

Blockchain in o�ce building transactions vii



4 Research methodology 31
4.1 Design science research . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.2 Research method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.2.1 Empirical research . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.2.2 Grounded Theory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

4.3 Modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.3.1 Business Process Model and Notation . . . . . . . . . . . . . . . . . . . . . 35
4.3.2 Unified Modeling Language . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.3.3 Prototype . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

4.4 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

5 Pain point identification 39
5.1 BPMN model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
5.2 Pain points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

5.2.1 Data quality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
5.2.2 Data structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
5.2.3 Pain point definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
5.2.4 Allocation pain points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
5.2.5 Property management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

5.3 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

6 Blockchain model 47
6.1 Current process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
6.2 Centralized database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

6.2.1 Centralized database features . . . . . . . . . . . . . . . . . . . . . . . . . . 48
6.2.2 Challenges centralized database . . . . . . . . . . . . . . . . . . . . . . . . . 55
6.2.3 Conclusion centralized database implementation . . . . . . . . . . . . . . . 56

6.3 Blockchain model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
6.3.1 Blockchain consideration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
6.3.2 Blockchain features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
6.3.3 Challenges blockchain model . . . . . . . . . . . . . . . . . . . . . . . . . . 62
6.3.4 Conclusion blockchain implementation . . . . . . . . . . . . . . . . . . . . . 63

6.4 Centralized database vs. Blockchain database . . . . . . . . . . . . . . . . . . . . . 63
6.5 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

7 Implementation & validation 67
7.1 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

7.1.1 Blockchain transaction model . . . . . . . . . . . . . . . . . . . . . . . . . . 67
7.1.2 User interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

7.2 Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
7.3 Role of the bank . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
7.4 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

8 Conclusion & Discussion 81
8.1 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
8.2 Limitations and recommendations for further research . . . . . . . . . . . . . . . . 85

8.2.1 Limitations of the research . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
8.2.2 Recommendations for further research . . . . . . . . . . . . . . . . . . . . . 86

8.3 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

Bibliography 89

Blockchain in o�ce building transactions viii



Appendix 95

A Information flow 95

B Interview protocols 96
B.1 Interview protocol 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
B.2 Interview protocol 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
B.3 Interview protocol 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

C Transcripts interviews 99

D Transaction process – BPMN 100
D.1 Preparation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
D.2 Marketing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
D.3 Due Diligence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
D.4 Completion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
D.5 BPMN model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

E Property manager activities 109

F Database input 110

G Standard rental agreement - ROZ-model 110

Blockchain in o�ce building transactions ix



Management summary

Technology advances, such as blockchain, are transforming markets across the globe,
including the commercial real estate sector. Transactions in this sector are known to
be time consuming and ine�cient, in part due to the lack of market transparency.
This research focuses on the development of a blockchain application that can enhance
the transaction process of o�ce buildings in the Netherlands.

Due to the commercial real estate (CRE) markets’ fundamental characteristics – heterogeneity
and immobility – real estate transactions face the joint challenges of information ine�ciencies and
corresponding high transaction costs (Ling and Archer, 2012). Noteworthy is the traditional role
of banks within the real estate transaction market. Financing CRE is usually done through lending
from banks (60% - 70% LTV) (Gout, 2017, p. 82). However, due to technology advancements,
changing client demand and stricter regulation (Basel III and Basel IV), the traditional role of
banks is under pressure (Deloitte, 2018). In this context, for banks to stay relevant, current
(internal) processes and new business model ’enablers’ should be researched.

Although recent studies have examined the possibilities of applying blockchain technology, ap-
plications remain unclear (Dijkstra, 2017; Seuren, 2018; Veuger, 2017). All studies indicate that
blockchain technology could lead to improvements in e�ciency, transparency and therefore trust.
Additionally, banks could use blockchain to better understand the risks associated with real estate
and streamline internal processes (Dijkstra, 2017; Deloitte, 2017). This research focuses on an
infrastructure for a blockchain-based application to improve the current way real estate is trans-
acted by introducing a more comprehensive, better quality and more complete asset information
overview, which may payo↵ for all involved parties (including new business model ’enablers’) and
could potentially increase the size of managed global real estate.

The transaction process of an o�ce building is divided into multiple stages (Crosby and McAl-
lister, 2015; Dijkstra, 2017; Hordijk and Teuben, 2008; Just and Stapenhorst, 2018): preparation,
marketing & pre- due diligence, due diligence and completion. Currently, due diligence phases and
negotiations are carried out to verify and validate information. These processes are a key indicator
of the lack of transparency and perceived unreliability of the data used in the transaction process.
Furthermore, the decentralized way of working with various ’non-digitized’ documents makes the
process complex and unstructured.

To support this complexity, semi-structured interviews were conducted to identify and map pain
points to specific phases and tasks in the transaction process. All interviewees indicated that
pain points mainly occur during the due diligence and completion phases and are related to
data structure and data quality. However, pain points are formed during the preparation phase
in the transaction process and the management of the real estate once the property has been
acquired. Implementing new technologies, such as blockchain, could lead to an improvement in
the transaction of an o�ce building in the future.

A blockchain distributed ledger is simply a new way of managing data and consists of five core ele-
ments (Hileman and Rauchs, 2017; Seuren, 2018; Swan, 2015; Tapscott and Tapscott, 2016; Tasca
et al., 2017): Cryptography, Peer-to-peer (P2P) network, Validity rules, Consensus mechanism

Blockchain in o�ce building transactions x



and Ledger. Blockchain and its deriving applications, e.g. smart contracts (Blockchain 2.0) and
applications (Blockchain 3.0), could support and enhance the reliability, e�ciency and security of
data transferred among a network (Swan, 2015, p. ix). Therefore, blockchain technology features
seem to provide a solution that could enhance the transaction of o�ce buildings. Besides, literat-
ure states that blockchain technology can be applied to real estate and could be a game-changer
in transacting real estate. The focus on a solution for a field problem – the cumbersome trans-
action process – is in line with design science research (Aken van and Romme, 2009; Hevner and
Chatterjee, 2010). Hence, this method is applied in developing a design proposition for a field
problem.

In summary, organizations currently work in a decentralized fashion which causes various pain
points and challenges. The proposed blockchain database is structured according to the data
requirements of a transaction (Property Markets Research Team, 2004), which are split into two
elements (indexes): physical (technical) and contractual (commercial-, legal- and financial- doc-
uments) elements. Physical and contractual data can be logged on a blockchain based on its
consensus mechanism and cryptographic encrypting method, also referred to as cryptographic
audit trail or hash chain. The original files are stored on the servers of the involved parties and
validation information (class diagram framework) is uploaded in the blockchain. The validated
framework consists of all essential data elements of e.g. a contract (e.g. index code, validation
date, involved parties etc.). Validated record-keeping is the first step towards creating digital real
estate transactions and resolving the pain points in the process.

Although, blockchain technology is what builds digital records of physical and contractual inform-
ation, it does also come with challenges. These are as a result of the immaturity of the technology,
a lack of standardization and limited examples of successful application. Hence the implementa-
tion of the proposed model is quite complex. Currently, the correctness of documents need to be
validated by validating nodes (oracles) in the network, due to the lack of standardization. For the
system to add value, data such as reports and inspection frameworks must be standardized. If this
is possible, the record-keeping application could be linked to various aggregation levels (Kadaster,
BAG, VHE, etc.) by way of an API. Therefore, data could be automatically validated without
the need for oracles, and analyzed by the user. Also, authorization rules in the network could be
much more detailed (e.g. data such as contract clauses could be recorded). All this could make the
proposed application suitable for managing physical and contractual data, which, consequentially,
could enhance the transaction process.

The process is sector wide known to be cumbersome, however there is not a great enough incentive
for one single party to develop a blockchain infrastructure – all parties would have to sign up to
use it for it to be valuable. Besides, all corporate parties could benefit from more reliability, trans-
parency and e�ciency. Hence, a collaboration between banks with a large market coverage would
be best placed to take the lead in standardizing documents for financing real estate and, in turn,
the development of a blockchain infrastructure as proposed. In this way, involved parties, such
as banks, will receive standard information, which they can use to optimize their own workflows
(e.g. risk assessments).

The design science research proposes a blockchain based infrastructure to improve the current
transaction process of an o�ce building. During validation of the application, all parties indicated
that the application is an interesting first step towards a digital and more transparent ecosystem.
The structure and quality of data – these are the main elements in a real estate transaction and so
are essential if the process is to be streamlined – available will be enhanced by implementing the
proposed blockchain infrastructure. The application improves the way specific asset are understood
by structuring physical and contractual information in one place, and guarantees the quality of
the data by using the blockchain mechanisms. Therefore, the tool is of immeasurable value for
the future of real estate data management and the transaction process.

Blockchain in o�ce building transactions xi



Management summary (Dutch)

Technologische ontwikkelingen zoals blockchain transformeren verschillende sectoren
wereldwijd, waaronder de commerciële vastgoedsector. Commerciële vastgoedtrans-
acties staan bekend als tijdrovend en ine�ciënt, onder andere vanwege het gebrek
aan transparantie van de markt. Dit onderzoek richt zich op de ontwikkeling van
een blockchain applicatie die het huidige transactieproces van kantoorgebouwen in
Nederland kan verbeteren.

Vanwege de primaire eigenschappen van vastgoed – heterogeen en immobiel – staat de commerciële
vastgoedmarkt bekend als ine�ciënt op het gebied van data-management. Dit resulteert in relatief
hoge transactiekosten in vergelijking tot andere kapitaalmarkten (aandelen, obligaties en fondsen)
(Ling and Archer, 2012). Noemenswaardig hierbij is dat banken een belangrijke rol spelen in de
huidge vastgoedmarkt. De financiering van vastgoed wordt meestal gerealiseerd door een lening bij
een bank (60 % - 70 % LTV) (Gout, 2017, p. 82). Als gevolg van technologische ontwikkelingen, de
veranderende vraag naar data en strengere regelgeving (Basel III en Basel IV) staat de traditionele
rol van banken als kredietverstrekker onder druk (Deloitte, 2018). In dit verband zouden banken
huidige (interne) processen en bedrijfsmodellen moeten analyseren om zich te positioneren in de
veranderende markt.

Hoewel recente studies de mogelijkheden van het toepassen van blockchain technologie in de vast-
goedmarkt hebben onderzocht, blijven daadwerkelijke applicaties en implementaties uit (Dijkstra,
2017; Seuren, 2018; Veuger, 2017). Alle studies geven echter aan dat blockchain technologie kan
leiden tot verbeteringen in e�ciëntie, transparantie en daarmee vertrouwen in de vastgoedsector.
Daarnaast kunnen banken deze technologie gebruiken om potentiële risico’s beter in kaart te bren-
gen en interne processen te stroomlijnen (Dijkstra, 2017; Deloitte, 2017). Dit onderzoek focust zich
daarom op de ontwikkeling van een blockchain applicatie om de huidige manier waarop vastgoed
wordt verhandeld te verbeteren. Dit kan mogelijk de basis vormen voor nieuwe bedrijfsmodellen
en mede tot een toename in stabielere vastgoedinvesteringen leiden.

Het huidige transactieproces van commercieel vastgoed is op te delen in verschillende fases (Crosby
and McAllister, 2015; Dijkstra, 2017; Hordijk and Teuben, 2008; Just and Stapenhorst, 2018):
preparation, marketing & pre-due diligence, due diligence and completion. Opmerkelijk is dat er
momenteel meerdere due diligence fases en onderhandelingen uitgevoerd worden, zowel vanuit de
verkopende als de kopende partij, om informatie te verifiëren en te valideren. Een mogelijk risico
kan zijn dat binnen het huidige transactieproces partijen de betrouwbaarheid van de aangeleverde
informatie betwisten. Bovendien resulteert de gedecentraliseerde manier van werken met niet-
gedigitaliseerde documenten in een complex en ongestructureerd proces.

Deze complexiteit is door middel van semi-gestructureerde interviews gëĹdentificeerd en gekoppeld
aan specifieke fasen en taken in het transactieproces. Uit ieder interview komt naar voren dat de
knelpunten met name ontstaan in de due diligence fase en completion fase, gerelateerd aan data
structuur en data kwaliteit. Deze knelpunten worden echter gevormd gedurende het beheer van
het vastgoed en de voorbereidende fase in het transactieproces. Een logische verklaring aangezien
knelpunten zichtbaar worden door het analyseren van data, hetgeen de basis vormt voor de on-

Blockchain in o�ce building transactions xii



derhandelingen in de completion fase. Het innoveren van het transactieproces en implementeren
van nieuwe technologieën, zoals blockchain, kan mogelijk leiden tot een verbetering van dit trans-
actieproces in de toekomst.

Een blockchain gedistribueerd grootboek is eenvoudigweg een nieuwe manier om gegevens te be-
heren en bestaat uit vijf kernelementen (Hileman and Rauchs, 2017; Seuren, 2018; Swan, 2015;
Tapscott and Tapscott, 2016; Tasca et al., 2017): ’cryptography’, ’peer-to-peer (P2P) network’,
’validity rules’, ’consensus mechanism’ en ’ledger’. Blockchain en de hieruit afgeleide toepassin-
gen, zoals ’smart contracts’, kunnen de betrouwbaarheid, e�ciëntie en veiligheid van informatie
die wordt overgedragen in een netwerk verbeteren (Swan, 2015, p. ix). Vanuit een theoretisch
perspectief kunnen de kernelementen van blockchain technologie een oplossing bieden voor het
huidige transactieproces van kantoorgebouwen.

Kortom, op dit moment werken organisaties op een gedecentraliseerde manier waardoor verschil-
lende knelpunten ontstaan in het transactieproces. De voorgestelde blockchain-database is on-
derverdeeld in twee hoofdelementen (Property Markets Research Team, 2004): fysieke en contrac-
tuele elementen. Fysieke en contractuele informatie wordt in een blockchain vastgelegd door mid-
del van het consensus mechanisme en de cryptografische coderingsmethodiek. In de voorgestelde
situatie worden originele bestanden opgeslagen op de servers van de betrokken partijen en wordt
informatie gerelateerd aan de validatie geüpload in de blockchain. Het hieruit voortvloeiende
gevalideerde kader bestaat uit alle essentiële informatie van een element (bijvoorbeeld codering,
validatie datum, betrokken partijen). De eerste stap naar het creëren van digitale transacties
en het oplossen van de knelpunten in het huidige proces is het valideren van de geregistreerde
informatie-elementen.

Hoewel blockchain technologie fysieke en contractuele informatie digitaal registreert, ontstaan er
ook uitdagingen. Onder andere het gevolg van de innovatieve technologie en een gebrek aan gest-
andaardiseerde documentatie. De verwachting is dat de implementatie van het voorgestelde model
vrij complex is, bijvoorbeeld omdat de juistheid van documenten momenteel wordt gevalideerd
door een aparte instantie in het netwerk, vanwege het gebrek aan standaardisatie. Indien docu-
mentatie zoals rapportages en inspecties worden gestandaardiseerd kan het voorgestelde systeem
van waarde zijn voor alle partijen. In deze optimale situatie kunnen systemen van verschillende
aggregatieniveaus (Kadaster, BAG, etc.) worden gekoppeld. Vervolgens is het mogelijk om data
input te controleren door Application Programming Interfaces (API’s) in plaats van een specifieke
partij in het netwerk. Daarnaast is het mogelijk om autorisatie in het netwerk gedetailleerder
plaats te laten vinden op bijvoorbeeld een enkel onderdeel van het huurcontract. Dit alles zou
de voorgestelde toepassing geschikt kunnen maken voor het beheren van fysieke en contractuele
informatie, die als gevolg daarvan het transactieproces verbetert.

Het proces staat sectorbreed bekend als omslachtig, toch is dat geen beweegreden voor partijen
om een blockchain applicatie te ontwikkelen. Indien het gehele netwerk de toegevoegde waarde
ziet en deelneemt aan het voorgestelde model, kan dit echter zeer e↵ectief zijn. Alle partijen
in het huidige transactieproces kunnen dan profiteren van meer betrouwbaarheid, transparantie
en e�ciëntie. Voor het standaardiseren van documenten voor de financiering van vastgoed zou
een samenwerking tussen banken interessant zijn gezien het marktaandeel van de banken en de
mogelijkheid om over betrouwbare informatie te beschikken. Zij kunnen het voortouw nemen
in het ontwikkelen van een infrastructuur zoals voorgesteld door de betrouwbare informatie te
gebruiken om hun eigen interne processen te optimaliseren. Externe partijen moeten daarvoor
standaard informatie aanleveren wat het ontwikkelen van een infrastructuur zoals omschreven
mogelijk maakt.

Dit ontwerp gericht onderzoek (Design Science research) stelt een op blockchain gebaseerde ap-
plicatie voor om het huidige transactieproces van een kantoorgebouw te verbeteren. Tijdens de
validatie van het prototype van de applicatie, hebben alle partijen aangegeven dat de applicatie
een interessante eerste stap is naar een digitaal en meer transparant ecosysteem. De structuur en
kwaliteit van de informatie die beschikbaar is zal worden verbeterd waardoor interne processen

Blockchain in o�ce building transactions xiii



geoptimaliseerd kunnen worden. De voorgestelde applicatie verbetert de manier waarop een kan-
toorgebouw wordt verhandeld door fysieke en contractuele informatie op één plaats te structureren
en garandeert daarnaast de kwaliteit van de gegevens door gebruik te maken van de blockchain
toepassingen. Dat maakt de tool van onschatbare waarde voor de toekomst van het beheer van
vastgoed gerelateerde informatie en het optimaliseren van het transactieproces.

Blockchain in o�ce building transactions xiv



Abstract

Technology advances, such as blockchain, are transforming markets across the globe, including the
commercial real estate sector. Due to the commercial real estate markets’ fundamental character-
istics – heterogeneity and immobility – real estate transactions face the joint challenges of time
consuming process, information ine�ciencies and corresponding high transaction costs. Although
recent studies have theoretically examined the possibilities of applying blockchain technology, ap-
plications remain unclear. The characteristics of blockchain technology could lead to improvements
in e�ciency, transparency and therefore trust. Therefore, this research focuses on a blockchain
solution for a field problem – the cumbersome transaction process – which is in line with design
science research. Hence, this method is applied in developing a design proposition.

In summary, organizations currently work in a decentralized fashion which causes various pain
points and challenges. To support this, semi-structured interviews were conducted to identify
and map pain points to specific phases and tasks in the transaction process. For mapping pain
points the transaction process is visualized by means of Business Process Model and Notation.
The obtained data is analyzed according to the Grounded Theory. From empirical findings it
could be stated that major pain points are related to data structure and data quality. To resolve
these pain points a blockchain application is proposed and pragmatically validated. Object related
information, such as contracts, can be logged on a blockchain based on its consensus mechanism
and cryptographic encrypting method. Original files are stored on the servers of the involved
parties and a validated framework – consisting of essential information, such as coding, validation
date, involved parties – is uploaded in the blockchain and visualized by means of UML and a
clickable user interface. Validated record-keeping is the first step towards creating digital real
estate transactions and resolving the pain points in the process.

Hence, this design science research proposes an infrastructure for a blockchain-based application
to improve the current way real estate is transacted by introducing a more comprehensive, better
quality and more complete asset information overview, which streamlines the transaction process,
may payo↵ for all involved parties and could potentially increase the size of managed global real
estate.

Blockchain in o�ce building transactions xv



Abbreviations

API Application Programming Interface
BPMN Business Process Model and Notation
CFL Commercial- Financial- and Legal index
CRE Commercial Restate Estate
DL Distrubuted Ledger
DLT Distrubuted Ledger Technology
GT Grounded Theory
IM Investment Memorandem
HoT Head of Terms
LTV Loan to Value
NDA Non- Disclosure Agreement
P2P Peer-to-Peer
PoA Proof-of-Autority
PoS Proof-of-Stake
PoW Proof-of-Work
PM Propert Management
RED Real Estate Development
REIT Real Estate Investment Trust
SPA Sales and Purchase Agreement
TTP Trusted Tird Parties
UML Unified Modeling Language

Blockchain in o�ce building transactions xvi



List of Figures

1 How much is the world worth? Source: (Savills, 2017). . . . . . . . . . . . . . . . . 2
2 Real estate characteristics. Sourc";"""date"",""2019-02-18T13:07:08Z""
""pdf:docinfo:custom:AAPL:Keywords"",""Blockchain technology"",""commercial real estate"",""design science research"",""innovation"",""information system"",""transactions""
""pdf:PDFVersion"",""1.4""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:docinfo:title"",""Master Thesis""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""Blockchain in office building transactions""
""language"",""en""
""dc:format"",""application/pdf; version=1.4""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""Master Thesis""
""xmp:CreateDate"",""2019-02-12T00:20:01Z""
""modified"",""2019-02-18T13:07:08Z""
""cp:subject"",""Blockchain in office building transactions""
""pdf:docinfo:subject"",""Blockchain in office building transactions""
""pdf:hasMarkedContent"",""false""
""xmp:ModifyDate"",""2019-02-18T14:07:08Z""
""pdf:docinfo:creator"",""H.P. (Hugo) Wouda""
""meta:author"",""H.P. (Hugo) Wouda""
""meta:creation-date"",""2019-02-12T00:20:01Z""
""created"",""2019-02-12T00:20:01Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-02-12T00:20:01Z""
""resourceName"",""Wouda_2019.pdf""
""Author"",""H.P. (Hugo) Wouda""
""producer"",""macOS Versie 10.14.1 (build 18B75) Quartz PDFContext""
""pdf:docinfo:producer"",""macOS Versie 10.14.1 (build 18B75) Quartz PDFContext""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""dc:description"",""Blockchain in office building transactions""
""Keywords"",""Blockchain technology, commercial real estate, design science research, innovation, information system, transactions"",""Blockchain technology, commercial real estate, design science research, innovation, information system, transactions""
""access_permission:modify_annotations"",""true""
""AAPL:Keywords"",""Blockchain technology"",""commercial real estate"",""design science research"",""innovation"",""information system"",""transactions""
""dc:creator"",""H.P. (Hugo) Wouda""
""description"",""Blockchain in office building transactions""
""dcterms:created"",""2019-02-12T00:20:01Z""
""Last-Modified"",""2019-02-18T13:07:08Z""
""dcterms:modified"",""2019-02-18T13:07:08Z""
""title"",""Master Thesis""
""xmpMM:DocumentID"",""uuid:ca15205b-f1d0-4254-8b90-3bbb5743539d""
""Last-Save-Date"",""2019-02-18T13:07:08Z""
""pdf:docinfo:keywords"",""Blockchain technology, commercial real estate, design science research, innovation, information system, transactions""
""pdf:docinfo:modified"",""2019-02-18T13:07:08Z""
""meta:save-date"",""2019-02-18T13:07:08Z""
""Content-Type"",""application/pdf""
""xmp:MetadataDate"",""2019-02-18T14:07:08Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""H.P. (Hugo) Wouda""
""pdf:producer"",""macOS Versie 10.14.1 (build 18B75) Quartz PDFContext""
""dc:subject"",""Blockchain technology, commercial real estate, design science research, innovation, information system, transactions"",""Blockchain technology, commercial real estate, design science research, innovation, information system, transactions""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""149""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""1133"",""234"",""18"",""540"",""97"",""1960"",""38"",""1665"",""2454"",""674"",""3049"",""3832"",""3076"",""3966"",""433"",""2159"",""539"",""2741"",""1670"",""0"",""2507"",""2470"",""2727"",""2313"",""3283"",""58"",""2149"",""2767"",""3836"",""3214"",""2897"",""3644"",""3744"",""3498"",""1251"",""85"",""2563"",""2725"",""2389"",""2823"",""2199"",""2039"",""1827"",""3041"",""3519"",""3431"",""3161"",""1736"",""2835"",""67"",""2650"",""2046"",""3213"",""3035"",""3349"",""1580"",""2451"",""66"",""2274"",""1654"",""2271"",""3160"",""2367"",""2579"",""3263"",""1146"",""2679"",""1924"",""2561"",""2429"",""982"",""2681"",""2313"",""869"",""3114"",""2813"",""1836"",""2672"",""1821"",""2670"",""2157"",""3375"",""3692"",""1670"",""3695"",""987"",""1992"",""1932"",""2089"",""2867"",""2118"",""125"",""899"",""1507"",""2314"",""3390"",""3530"",""3775"",""1192"",""72"",""2276"",""3155"",""3875"",""1761"",""3482"",""3539"",""3664"",""3085"",""1899"",""2567"",""2529"",""2446"",""1497"",""0"",""141"",""1563"",""2256"",""899"",""133"",""1726"",""2838"",""2709"",""2060"",""967"",""108"",""72"",""72"",""72"",""993"",""61"",""124"",""82"",""82"",""82"",""82"",""82"",""82"",""82"",""82"",""82"",""82"",""82"",""82"",""82"",""82"",""82"",""82"",""82"",""82""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""meta:keyword"",""Blockchain technology, commercial real estate, design science research, innovation, information system, transactions"",""Blockchain technology, commercial real estate, design science research, innovation, information system, transactions""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-02-12T00:20:01Z""
";https://scholar.google.com/scholar?start=450&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094668-1193;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Enabling Data Democracy in Supply Chain using Blockchain and IoT;D Sachdev ; Journal of Management, 2019  papers.ssrn.com;;"… ENABLING DATA DEMOCRACY IN SUPPLY CHAIN USING BLOCKCHAIN AND IOT Deepika

Sachdev Vice President Delivery, Knowesis UPES, Dehradun … It examines Use Cases and

benefits of current IoT and Blockchain integrated frameworks for SCM …";Cité 4 fois;Les 3 versions;[PDF] academia.edu;https://www.academia.edu/download/58563500/JOM_06_01_008.pdf;;;https://scholar.google.com/scholar?start=410&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094569-775;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;How to record quantum queries, and applications to quantum indifferentiability;M Zhandry ; Annual International Cryptology Conference, 2019  Springer;;"… CRYPTO 2019: Advances in Cryptology – CRYPTO 2019 pp 239-268 | Cite as. How to

Record Quantum Queries, and Applications to Quantum Indifferentiability … Then we will

give our compressed standard and phase oracles. Standard Oracle …";Cité 71 fois;Les 4 versions;[PDF] nsf.gov;https://par.nsf.gov/servlets/purl/10164789;"
How to Record Quantum Queries, and

Applications to Quantum Indifferentiability

Mark Zhandry

Princeton University & NTT Research

Abstract. The quantum random oracle model (QROM) has become
the standard model in which to prove the post-quantum security of
random-oracle-based constructions. Unfortunately, none of the known
proof techniques allow the reduction to record information about the ad-
versary’s queries, a crucial feature of many classical ROM proofs, including
all proofs of indifferentiability for hash function domain extension.
In this work, we give a new QROM proof technique that overcomes
this “recording barrier”. We do so by giving a new “compressed oracle”
which allows for efficient on-the-fly simulation of random oracles, roughly
analogous to the usual classical simulation. We then use this new technique
to give the first proof of quantum indifferentiability for the Merkle-
DamgĂĽrd domain extender for hash functions. We also give a proof
of security for the Fujisaki-Okamoto transformation; previous proofs
required modifying the scheme to include an additional hash term. Given
the threat posed by quantum computers and the push toward quantum-
resistant cryptosystems, our work represents an important tool for efficient
post-quantum cryptosystems.

1 Introduction

The random oracle model [BR93] has proven to be a powerful tool for heuristically
proving the security of schemes that otherwise lacked a security proof. In the
random oracle model (ROM), a hash function H is modeled as a truly random
function that can only be evaluated by querying an oracle for H. A scheme is
secure in the ROM if it can be proven secure in this setting. Of course, random
oracles cannot be efficiently realized; in practice, the random oracle is replaced
with a concrete efficient hash function. The hope is that the ROM proof will
indicate security in the real world, provided there are no structural weaknesses
in the concrete hash function.

Meanwhile, given the looming threat of quantum computers [IBM17], there
has been considerable interest in analyzing schemes for so called “post-quantum”
security [NIS17, Son14, ATTU16, CBH+17, YAJ+17, CDG+17, CDG+15]. Many
of the proposed schemes are random oracle schemes; Boneh et al. [BDF+11] argue
that the right way of modeling the random oracle in the quantum setting is to use
the quantum random oracle model, or QROM. Such a model allows a quantum
attacker to query the random oracle on a quantum superposition of inputs. The
idea is that a real-world quantum attacker, who knows the code for the concrete



hash function, can evaluate the hash function in superposition in order to perform
tasks such as Grover search [Gro96] or collision finding [BHT98]. In order to
accurately capture such real-world attacks, it is crucial to model the random
oracle to allow for such superposition queries. The quantum random oracle model
has been used in a variety of subsequent works to prove the post-quantum security
of cryptosystems [BDF+11, Zha12b, Zha15, TU16, Eat17].

The Recording Barrier. Unfortunately, proving security in the quantum random
oracle model can be extremely difficult. Indeed, in the classical random oracle
model, one can copy down the adversary’s queries as a means to learning what
points the adversary is interested in. Many classical security proofs crucially
use this information in order to construct a new adversary which solves some
hard underlying problem, reaching a contradiction. In the quantum setting, such
copying is impossible by no-cloning. One can try to record some information
about the query, but this amounts to a measurement of the adversary’s query
state which can be detected by the adversary. A mischievous adversary may
refuse to continue if it detects such a measurement, rendering the adversary
useless for solving the underlying problem. Because of the difficulty in reading
an adversary’s query, it also becomes hard to adaptively program the random
oracle, another common classical proof technique.

This difficulty has led authors to develop new quantum-sound proof tech-
niques to replace classical techniques, such as Zhandry’s small-range distribu-
tions [Zha12a] or Targhi and Unruh’s extraction technique [TU16]. These proof
techniques choose the oracle from a careful distribution that allows for proofs to
go through. However, every such proof technique always chooses a classical oracle
at the beginning of the experiment, and leave the oracle essentially unchanged
through the entire execution. The inability to change the oracle seems inherent,
since if the proof gives the adversary different oracles during different queries,
this is potentially easily detectable (even by classical adversaries)1

Constraining the oracles to be fixed functions seems to limit what can be
proved using such non-recording techniques. For example, Dagdelen, Fischlin, and
Gagliardoni [DFG13] show that such natural proof techniques are likely incapable
of proving the security of Fiat-Shamir2. This leads to a natural question: Is it
possible to record information about an adversary’s quantum query without the
adversary detecting

Enter Indifferentiability. The random oracle model (quantum or otherwise)
assumes the adversary treats the hash function as a monolithic object. Unfortu-
nately, hash functions in practice are usually built from smaller building blocks,
called compression functions. If one is not careful, hash functions built in this way

1 The one exception we are aware of is Unruh’s adaptive programming [Unr15]. This
proof does change the oracle adaptively, but only inputs for which adversary’s queries
have only negligible “weight”. Thus, the change is not detectable. The following
discussion also applies to Unruh’s technique.

2 We note that if the underlying building blocks are strengthened, Fiat-Shamir was
proven secure by Unruh [Unr16]

2



are vulnerable to attacks such as length-extension attacks. Coron et al. [CDMP05]
show that a hash function built from a compression function can be as good as
a monolithic oracle in many settings if it satisfies a notion of indifferentiability,
due to Maurer, Renner, and Holenstein [MRH04]. Roughly, in indifferentiability,
an adversary A has oracle access to both h and H, and the adversary is trying
to distinguish two possible worlds. In the “real world”, h is a random function,
and H is built from h according to the hash function construction. In the “ideal
world”, H is a random function, and h is simulated so as to be consistent with H.
A hash function is indifferentiable from a random oracle if no efficient adversary
can distinguish the two worlds.

Coron et al.’s proof of indifferentiability for Merkle-Damgard requires the
simulator to remember the queries that the adversary has made. This is actually
inherent for any domain extender, by a simple counting argument discussed below.
In the quantum setting, such recording presents a serious issue, as recording a
query is equivalent (from the adversary’s point of view) to measuring the query.
As any measurement will disturb the quantum system, such measurement may
be detectable to the adversary. Note that in the case where A is interacting
with a truly random h, there is no measurement happening. Therefore, if such
a measurement can be detected, the adversary can distinguish the two cases,
breaking indifferentiability.

Example. To illustrate what might go wrong, we will use the simple example from
Coron et al. [CDMP05]. Here, we will actually assume access to two independent
compression functions h0, h1 : {0, 1}2n → {0, 1}n. We will define H : {0, 1}3n →
{0, 1}n as H(x, y) = h1(h0(x), y), where x ∈ {0, 1}2n, y ∈ {0, 1}n.

To argue that H is indifferentiable from a random oracle, Coron et al. use the
following simulator S, which has access to H, and tries to implement the oracles
h0, h1. S works as follows:

– S keeps databases D0, D1, which will contain tuples (x, y). Db containing
(x, y) means that S has set hb(x) = y.

– h0 is implemented on the fly: every query on x looks up (x, y) ∈ D0, and
returns y if it is found; if no such pair is found, a random y is chosen and
returned, and (x, y) is added to D0.

– By default, h1 is answered randomly on the fly as in h0. However, it needs
to make sure that h1(h0(x), y) always evaluates to H(x, y), else it is trivial
to distinguish the two worlds. Therefore, on a query (z, y), h1 will check if
there is a pair (x, z) in D0 for some x. If so, it will reasonably guess that the
adversary is trying to evaluate H(x, y), and respond by making a query to
H(x, y). Otherwise it will resort to the default simulation.

Note that by defining the simulator in this way, if the adversary ever tries to
evaluate H on (x, z) by first making a query x to h0 to get y, and then making a
query (y, z) to h1, the simulator will correctly set the output of h1 to H(x, z), so
that the adversary will get a result that is consistent with H. However, note that
it is crucial that S wrote down the queries made to h0, or else it will not know
which point to query H when simulating h1.

3



Now consider a quantum adversary. A quantum query to, say, h0 will be the
following operation:

∑

x∈{0,1}2n,u∈{0,1}n

αx,u|x, u〉 7→
∑

x∈{0,1}2n,u∈{0,1}n

αx,u|x, u⊕ h0(x)〉

Now, imagine our simulator trying to answer queries to h0 in superposition.
For simplicity, suppose this is the first query to h0, so D0 is empty. The natural
approach is to just have S store its database D0 in superposition, performing a
map that may look like |x, u〉 7→ |x, u⊕ y〉 ⊗ |x, y〉, where y is chosen randomly,
and everything to the right of the ⊗ is the simulators state.

But now consider the following query by an adversary. It sets up the uniform
superposition

∑

x,u |x, u〉 and queries. In the case where h0 is a classical function,
then this state becomes

∑

x,u

|x, u⊕ h0(x)〉 =
∑

x,u

|x, u〉

Namely, the state is unaffected by making the query. In contrast, the simulated
query would result in

∑

x,u

|x, u⊕ y〉 ⊗ |x, y〉

Here, the adversary’s state is now entangled with the simulator’s. It is straight-
forward to detect this entanglement by applying the Quantum Fourier Transform
(QFT) to the adversary’s x registers, and then measuring the result. In the case
where the adversary is interacting with a random h0, the QFT will result in a 0.
In the simulated case, the QFT will result in a random string. These two cases
are therefore easily distinguishable.

To remedy this issue, prior works in the quantum regime have abandoned
on-the-fly simulation, instead opting for stateless simulation. Here, the simulator
commits to a function to implement the oracle in the very beginning, and then
sticks with this implementation throughout the entire experiment. Moreover, the
simulator never records any information about the adversary’s query, lest the
adversary detect the entanglement with the simulator. This will certainly fix the
issue above, and by carefully choosing the right implementations prior works
have shown how to translate many classical results into the quantum setting.

However, for indifferentiability, choosing a single fixed function for h0 intro-
duces new problems. Now when the adversary makes a query to h1, the simulator
needs to decide if the query represents an attempt at evaluating H, and if so,
it must program the output of h1 accordingly. However, without knowing what
inputs the adversary has queried to h0, it seems impossible for the simulator
to determine which point the adversary is interested in. For example, if the
adversary queries h1 on (y, z), there will be roughly 2n possible x that gave rise
to this y (since h0 is compressing). Therefore, the simulator must choose from
one of 2n inputs of the form (x, z) on which to query H.

To make matters even more complicated, an adversary can submit the uniform
superposition

∑

x |x, 0〉, resulting in the state
∑

x |x, h0(x)〉, which causes it to

4



“learn” y = h0(x). At this point, the simulator should be ready to respond to an h1

query on (y, z) by using x, meaning the simulator must be entangled with x. Then,
at some later time, the adversary can query again on the state

∑

x |x, h0(x)〉,
resulting in the original state

∑

x |x, 0〉 again. The adversary can test that it
received the correct state using the quantum Fourier transform. Therefore, after
this later query, the simulator must be un-entangled with x. Even more complex
strategies are possible, where the adversary can compute and un-compute h0 in
stages, so as to try to hide what it is doing from any potential simulator.

These issues are much more general than just the simple domain extender
above. Indeed, even classically domain extension with a stateless simulator is
impossible, by the following simple argument. Suppose there is a hash function
H : {0, 1}M → {0, 1}N built from a compression function h : {0, 1}m → {0, 1}n

as H = Ch for an oracle circuit C. Let L = M + log2 N, ` = m+ log2 n. Then
L, ` represent the logarithm of the size of the truth tables for H,h. Since we
are domain extending, we are interested in the case where Lďż˝ `. Suppose even
L ≥ `+ 0.001.

Suppose toward contradiction that h can be simulated statelessly, which we
will represent as SimH (since the function can make H queries). Then h has a
truth table of size 2`. In the real world, H agrees with Ch on all inputs; therefore
in order for indifferentiability to hold, in the simulated world a uniformly random
H must agree with Ch = CSim

H

on an overwhelming fraction of inputs. But
this is clearly impossible, as it would allow us to compress the random truth
table of H: simply output the truth table for SimH , along with the Îľ fraction
of of input/output pairs where H and CSim

H

disagree. The total length of this
compressed truth table is 2` + (Îľ2M )(MN) = 2` + ÎľN2L. As Îľ is negligible (and
therefore much smaller than 1/N) the compressed truth table will be smaller
than 2L, the size of the truth table for H. But since H is a random function its
truth table cannot be compressed, reaching a contradiction.

Therefore, any simulator for indifferentiability, regardless of the scheme, must
inherently store information about the adversary. But the existing QROM tech-
niques are utterly incapable of such recording. We therefore ask: Is indifferentiable
domain extension even possible?

1.1 This Work

In this work, perhaps surprisingly, we answer the question above in the affirmative.
Namely, we give a new compressed oracle technique, which allows for recording the
adversary’s queries in a way that the adversary can never detect. The intuition is
surprisingly simple: an adversary interacting with a random oracle can be thought
of as being entangled with a uniform superposition of oracles. As entanglement
is symmetric, if the adversary ever has any information about the oracle, the
oracle must also have information about the adversary. Therefore a simulator can
always record some information about the adversary, if done carefully.

We then use the technique to prove the indifferentiability of the Merkle-
DamgĂĽrd construction. We believe our new technique will be of independent

5



interest; for example our technique can be used to prove the security of the
Fujisaki-Okamoto transformation [FO99], and also gives very short proofs of
several quantum query lower bounds.

The Compressed Oracle Technique. In order to prove indifferentiability, we devise
a new way of analyzing quantum query algorithms

Consider an adversary interacting with an oracle h : {0, 1}m → {0, 1}n. It is
well established that the usual quantum oracle mapping |x, y〉 7→ |x, y ⊕ h(x)〉
is equivalent to the “phase” oracle, which maps |x, u〉 7→ (−1)u·h(x)|x, u〉 (we
discuss this equivalence in Section 3). For simplicity, in this introduction we will
focus on the phase oracle, which is without loss of generality.

Next, we note that the oracle h being chosen at random is equivalent (from
the adversary’s point of view) to h being in uniform superposition

∑

h |h〉. Indeed,
the superposition can be reduced to a random h by measuring, and measuring
the h registers (which is outside of A’s view) is undetectable to A. To put another
way, the superposition over h is a purification of the adversary’s mixed state.

Therefore, we will imagine the h oracle as containing
∑

h |h〉. When A makes
a query on

∑

x,u αx,u|x, u〉, the joint system of the adversary and oracle are

∑

x,u

αx,u|x, u〉 ⊗
∑

h

|h〉

The query introduces a phase term (−1)u·h(x), so the joint system becomes
∑

x,u

αx,u|x, u〉 ⊗
∑

h

|h〉(−1)u·h(x)

We normally think of the phase as being returned to the adversary, but the
phase really affects the entire system, so it is equivalent to think of the phase as
being added to the oracle’s state.

Now, we will think of h as a vector of length 2m × n by simply writing down
h’s truth table. We will think of each x, u pair as a point function Px,u which
outputs u on x and 0 elsewhere. Using our encoding of functions as vectors, we
can write u ¡ h(x) as Px,u ¡ h. We can therefore write the post-query state as

∑

x,u

αx,u|x, u〉 ⊗
∑

h

|h〉(−1)h·Px,u

In general, the state after making q queries can be written as
∑

x1,...,xq,u1,...,uq

Îąx1,...,xq,u1,...,uq
|ψx1,...,xq,u1,...,uq

〉 ⊗
∑

h

|h〉(−1)h·(Px1,u1
+¡¡¡+Pxq,uq )

Next, notice that by applying the Quantum Fourier transform to h, the h
registers will now contain (Px1,u1

+ ¡ ¡ ¡+ Pxq,uq
) mod 2. Working in the Fourier

domain, we see that each query simply adds Px,u (modulo 2) to the result. In
the Fourier domain, the initial state is 0.

Therefore, from A’s point of view, it is indistinguishable whether the oracle
for h is a random oracle, or it is implemented as follows:

6



– The oracle keeps as state a vector D ∈ {0, 1}n×2m

, initially set to 0.
– On any oracle query, the oracle performs the map |x, u〉 ⊗ |D〉 7→ |x, u〉 ⊗
|D ⊕ P (x, u)〉

Thus, with this remarkably simple change in perspective, the oracle can
actually be implemented by recording and updating phase information about the
queries being in made.

We can now take this a couple steps further. Notice that after q queries, D is
non-zero on at most q inputs (since it is the sum of q point functions). Therefore,
we can store the database in an extremely compact form, namely the list of (x, y)
pairs where y = D(x) and y 6= 0. Notice that this allows us to efficiently simulate
a random oracle, without an a priori bound on the number of queries. Previously,
simulating an unbounded number of queries efficiently required computational
assumptions, and simulation was only computationally secure. In contrast, simu-
lating random oracles exactly required 2q-wise independent functions [Zha12b]
and hence required knowing q up front. We therefore believe this simulation will
have independent applications for the efficient simulation of quantum oracles.
We will call this the compressed Fourier oracle.

We can then take our compressed Fourier oracle, and convert it back into
a primal-domain oracle. Namely, for each (x, y) pair, we perform the QFT on
the y registers. The result is a superposition of databases of (x,w) pairs, where
w roughly represents h(x). For any pair not in the database, h(x) is implicitly
a uniform superposition of inputs independent of the adversary’s view. We call
this the compressed standard oracle. It intuitively represents what the adversary
knows about the function h: if (x, y) is in the database then the adversary “knows”
h(x) = y, and otherwise, the adversary “knows” nothing about h(x). In Section 3,
we show how to directly obtain the compressed standard oracle.

Applying Compressed Oracles to Indifferentiability. The compressed standard
oracle offers a simple way to keep track of the queries the adversary has made.
In particular, it tracks exactly the kind of information needed in the classical
indifferentiability proof above, namely whether or not a particular value has
been queried by the adversary, and what the value of the oracle at that point
is. We use this to give a quantum indifferentiability proof for Merkle-DamgĂĽrd
construction using prefix-free encodings [CDMP05].

To illustrate our ideas, consider our simple example above with h0, h1 and
H. Our simulator will simulate h0 as in the compressed standard oracle, keeping
a (superposition over) lists D0 of (x, y) pairs. Next, our simulator must handle
h1 queries. When given a phase query |y, z〉, the simulator does the following.
If first looks for a pair (x, y′) in D0 with y′ = y. If one is found, it reasonably
guesses that the adversary is interested in computing H(x, z), and so it makes a
query on (x, z) to H. Otherwise, it is reasonable to guess that the adversary is
not trying to compute H on any input, since the adversary does not “know” any
inputs to h0 that would result in a query to h1 on (y, z).

While the above appears to work, we need to make sure the simulator does
not disturb the compressed oracle. Unfortunately, some disturbance is necessary.

7



Indeed, determining the value of h0(x) is a measurement in the primal domain.
On the other hand, the update procedure for the compressed oracles needs to
decide whether or not x belongs in the database, and this corresponds to a
measurement in the Fourier domain (since in the Fourier domain, h0(x) must
be non-zero). These two measurements do not commute, so by the uncertainty
principle it is impossible to perform both measurements perfectly.

Nonetheless, we show that the errors are small. Intuitively, we observe that
the simulator does not actually need to know the entire value of h0(x), just
whether or not it is equal to y. We call such information a “test”. Similarly, the
compressed oracle implementation just needs to know whether or not h0(x) is
equal to 0, but in the Fourier domain.

Now, these primal and Fourier tests still do not commute. Fortunately, they
“almost” commute, which we formalize in the full version [Zha18]. The intuition
is that, if a primal test of the form “is h0(x) = y” has a non-negligible chance
of succeeding, h0(x) must be very “far” from the uniform superposition. This
is because a uniform superposition puts an exponentially small weight on every
outcome. Recall that the uniform superposition maps to h0(x) = 0 in the Fourier
domain. Thus by being “far” from uniform, the Fourier domain test has a
negligibly-small chance of succeeding. Therefore, one of the two tests is always
“almost” determined, meaning the measurement negligibly affects the state. This
means that, no matter what initial state is, the two tests “almost” commute.

Thus, the simulator can perform these tests without perturbing the state
significantly. This shows that h0 queries are correctly simulated; we also need to
show that h1 queries are correctly simulated and consistent with H. The intuition
above suggests that h1 should be consistent with H, and indeed in Section 5 we
show this using a careful sequence of hybrids. Then in the full version [Zha18],
we use the same ideas to prove the indifferentiability of Merkle-DamgĂĽrd.

The Power of Forgetting. Surprisingly, our simulator ends up strongly resembling
the classical simulator. It is natural to ask, therefore, how the simulator gets
around the difficulties outlined above.

First, notice that if we translate the query
∑

x,u |x, u〉 in our example to a
phase query, it becomes

∑

x |x, 0〉. This query has no effect on the oracle’s state.
This means the oracle remains un-entangled with the adversary, as desired.

Second, a query
∑

x |x, 0〉 becomes
∑

x,u |x, u〉 for a phase query. Consider
applying the query to the compressed Fourier oracle. The joint quantum system
of the adversary and simulator becomes

∑

x,u 6=0

|x, u〉|{(x, u)}〉+
∑

x

|x, 0〉|{}〉

A similar expression holds for the compressed standard oracle. Note that the
simulator can clearly tell (whp) that the adversary has queried on x. Later, when
the adversary queries on the same state a second time, (x, u) will get mapped
to (x, 0), and will hence be removed from the database. Thus, after this later
query, the database contains no information about x. Hence, the adversary is
un-entangled with x, and so it’s tests will output the correct value.

8



Ultimately then, the key difference between our simulator and the natural
quantum analog of the classical simulator is that our simulator must be ready to
forget some of the oracle points it simulated previously. By implementing h0 as a
compressed oracle, it will forget exactly when it needs to so that the adversary
can never detect that it is interacting with a simulated oracle.

Other results We expect our compressed oracle technique will have applications
beyond indifferentiability. Here, we list two additional sets of results we are able
to obtain using our technique:

Post-quantum security of Fujisaki-Okamoto. The Fujisaki-Okamoto transforma-
tion [FO99] transforms a weak public key encryption scheme into a public key
encryption scheme that is secure against chosen ciphertext attacks, in the random
oracle model. Unfortunately, the classical proof does not work in quantum random
oracle model, owing to similar issues with indifferentiability proofs. Namely, in
one step of the proof, the reduction looks at the queries made by the adversary in
order to decrypt chosen ciphertext queries. This is crucial to allow the reduction
to simulate the view of the adversary without requiring the secret decryption
key. But in the quantum setting, it is no longer straightforward to read the
adversary’s queries without disrupting its state.

Targhi and Unruh [TU16] previously modified the transformation by including
an additional random oracle hash in the ciphertext. In the proof, the hash function
is set to be injective, and the reduction can invert the hash in order to decrypt.

In the full version [Zha18], we show how to adapt our compressed oracle
technique to prove the security of the original transform without the extra hash.
In addition, we show security against even quantum chosen ciphertext queries,
thus proving security in the stronger model of Boneh and Zhandry [BZ13]. We note
that recently, Jiang et al. [JZC+18] proved the security of the FO transformation
when used as a key encapsulation mechanism. Their proof is tight, whereas ours
is somewhat loose. On the other hand, we note that their proof does not apply if
FO is used directly as an encryption scheme, and does not apply in the case of
quantum chosen ciphertext queries.

Simple Quantum Query Complexity Lower Bounds. We also show that our
compressed oracles can be used to give very simple and optimal quantum query
complexity lower bounds for problems for random functions, such as pre-image
search, collision finding, and more generally k-SUM.

Our proof strategy is roughly as follows. First, since intuitively the adversary
has no knowledge of values of h outside of D, except with very small probability
any successful algorithm will output points in D. Therefore it suffices to bound
the number of queries required to get D to contain a pre-image/collision/k-sum.

For pre-image search, we re-prove the optimal lower bound of Ω(2n/2) queries
of [BBBV97], but for random functions; note that pre-image search for random
functions and worst-case functions is equivalent using simple reductions. The
proof appears superficially similar to [BBBV97]: we show that each query can

9



increase the “amplitude” on “good” databases by a small O(2−n/2) amount. After
q queries, this amplitude becomes O(q/2n/2), which we then square to get the
probability of a “good” database. The proof is only slightly over a page once the
compressed oracle formalism has been given.

We then re-prove the optimal collision lower bound of Ω(2n/3) queries for
random functions, matching the worst case bound [AS04] and the more recent
average case bound [Zha15]. Remarkably, our proof involves only a few lines
of modification to the pre-image lower bound. We show that the amplitude on
“good” databases increases by O(

√
q × 2n/2) for each query, where the extra

√
q

intuitively comes from the fact that the database has size at most q, giving q
opportunities for a collision every time a new entry is added to the database3.

In contrast to our very simple extension, the prior collision bounds involved
very different techniques and were much more complicated. Also note that prior
works could not prove directly that finding collisions were hard. Instead, they show
that distinguishing a function with many collisions from an injective function
was hard. This then only works directly for expanding functions, which are of
little interest to cryptographers. Zhandry [Zha15] shows for random functions a
reduction from expanding functions to compressing functions, giving the desired
lower bound for compressing functions. Our proof, in contrast, works directly
with functions of arbitrary domain and range. These features suggests that our
proof technique is fundamentally different than those of prior works.

By generalizing our collision bound slightly, we can obtain an Ω(2n/(k+1))
lower bound for finding a set of distinct points x1, . . . , xk such that

∑

i H(xi) = 0.
This bound is tight as long as n ≤ km by adapting the collision-finding algorithm
of [BHT98] to this problem. Again, our proof is obtained by modifying just a
few lines of the pre-image search proof.

1.2 Related Works

Ristenpart, Shacham, and Shrimpton [RSS11] shows that indifferentiability is
insufficient for replacing a concrete hash function with a random oracle in
the setting of multi-stage games. Nonetheless, Mittelbach [Mit14] shows that
indifferentiability can still be useful in these settings. Exploring the quantum
analogs of these results is an interesting direction for future research.

Acknowledgements

This work is supported in part by NSF and DARPA. Opinions, findings and
conclusions or recommendations expressed in this material are those of the
author(s) and do not necessarily reflect the views of NSF or DARPA.

3 and the square root comes from the fact that the norm of the sum of q unit vectors
of disjoint support is

√

q

10



2 Preliminaries

Distinguishing quantum states. The density matrix captures all statistical infor-
mation about a mixed state. That is, if two states have the same density matrix,
then they are perfectly indistinguishable.

For density matrices ρ, ρ′ that are not identical, we define the trace distance as
T (ρ, ρ′) = 1

2

∑

i |λi|, where λi are the eigenvalues of ρ−ρ′. The trace distance cap-
tures the maximum distinguishing advantage amongst all possible measurements
of the state.

We will need the following Theorem of Bennett et al. (which we have slightly
improved, see full version [Zha18] for the improved proof):

Lemma 1 ([BBBV97]). Let |φ〉 and |ψ〉 be quantum states with Euclidean
distance ε. Then T (|φ〉〈φ|, |ψ〉〈ψ|) = ε

√

1− ε2/4 ≤ ε.
We will also need the following relaxation of commuting operations:

Definition 1. Let U0, U1 be unitaries over the same quantum system. We say
that U0, U1 ξ-almost commute if, for any initial state ρ, the images of ρ under
U0U1 and U1U0 are at most Îľ-far in trace distance.

3 Oracle Variations

Here, we describe several oracle variations. The oracles will all be equivalent; the
only difference is that the oracle registers and/or the query registers are encoded
in different ways between queries. We start with the usual quantum random
oracle, which comes in two flavors that we call the standard oracle and phase
oracle. Then we will give our compressed standard and phase oracles.

Standard Oracle. Here, the oracle H : {0, 1}m → {0, 1}n is represented as its
truth table: a vector of size 2m where each component is an n-bit string.

The oracle takes as input a state consisting of three sets of registers: m-
qubit x registers representing inputs to the function, n-qubit y registers for
writing the response, and n2m-qubit H registers containing the truth table
of the actual function. The x, y registers come from the adversary, and the
H registers are the oracle’s state, which is hidden from the adversary accept
by making queries. On basis states |x, y〉 ⊗ |H〉, the oracle performs the map
|x, y〉 ⊗ |H〉 7→ |x, y ⊕H(x)〉 ⊗ |H〉

For initialization, the oracle H";"""date"",""2020-06-25T14:46:13Z""
""pdf:PDFVersion"",""1.4""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:docinfo:title"",""""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""pdfa:PDFVersion"",""A-1b""
""language"",""en""
""dc:format"",""application/pdf; version=""""A-1b"""""",""application/pdf; version=1.4""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""xmp:CreateDate"",""2020-06-25T10:46:13Z""
""modified"",""2020-06-25T14:46:13Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""xmp:ModifyDate"",""2020-06-25T10:46:13Z""
""pdf:docinfo:creator"",""""
""meta:author"",""""
""meta:creation-date"",""2020-06-25T14:46:13Z""
""created"",""2020-06-25T14:46:13Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-06-25T14:46:13Z""
""resourceName"",""10164789""
""pdfaid:part"",""1""
""Author"",""""
""producer"",""Neevia Document Converter Pro v7.1 build 94 (http://neevia.com)""
""pdf:docinfo:producer"",""Neevia Document Converter Pro v7.1 build 94 (http://neevia.com)""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""22"",""16"",""28"",""9"",""15"",""0"",""1"",""31"",""22"",""17"",""55"",""24"",""47"",""28"",""84"",""38"",""5"",""16"",""3"",""27"",""9"",""23"",""15"",""11"",""0"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2020-06-25T14:46:13Z""
""Last-Modified"",""2020-06-25T14:46:13Z""
""dcterms:modified"",""2020-06-25T14:46:13Z""
""title"",""""
""xmpMM:DocumentID"",""uuid:1e286fd3-b94e-11ea-0000-f447dbd208cf""
""Last-Save-Date"",""2020-06-25T14:46:13Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2020-06-25T14:46:13Z""
""meta:save-date"",""2020-06-25T14:46:13Z""
""Content-Length"",""288723""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""pdfaid:conformance"",""B""
""pdf:producer"",""Neevia Document Converter Pro v7.1 build 94 (http://neevia.com)""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""30""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""2157"",""2791"",""2594"",""2326"",""2635"",""2060"",""2697"",""2648"",""2657"",""2267"",""2279"",""2535"",""2076"",""1908"",""2199"",""1992"",""1917"",""1758"",""1799"",""2026"",""2290"",""2245"",""1959"",""2103"",""1834"",""1954"",""2253"",""2088"",""2341"",""1594""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-06-25T14:46:13Z""
";https://scholar.google.com/scholar?start=590&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094579-813;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[PDF][PDF] June 5, 2020 Original release: June 2019;A Klages;Mundt, A Minca  arXiv preprint arXiv:1906.02152, 2019  cointhinktank.com;;"… We further remark on oracle/governance manipulation in Section 7 … Most crypto-fiat pairs are

through Bitcoin or Ether, which act as a gateway to other cryptoassets … moving assets between

a number of exchanges and can take considerable time to confirm on the blockchain …";Autres articles;Version HTML;[PDF] cointhinktank.com;https://cointhinktank.com/upload/academic%20Deleveraging%20Spirals%20and%20STABLECOIN%20attacks.pdf;"
(In)Stability for the Blockchain: Deleveraging Spirals and

Stablecoin Attacks∗

Ariah Klages-Mundt† Andreea Minca‡

June 5, 2020
Original release: June 2019

Abstract

We develop a model of stable assets, including noncustodial stablecoins backed by cryp-
tocurrencies. Such stablecoins are popular methods for bootstrapping price stability within
public blockchain settings. We derive fundamental results about dynamics and liquidity
in stablecoin markets, demonstrate that these markets face deleveraging feedback effects
that cause illiquidity during crises and exacerbate collateral drawdown, and characterize
stable dynamics of the system under particular conditions. From these insights, we sug-
gest design improvements that aim to improve long-term stability. We also introduce new
attacks that exploit arbitrage-like opportunities around stablecoin liquidations. Using our
model, we demonstrate that these can be profitable. These attacks may induce volatility
in the ‘stable’ asset and cause perverse incentives for miners, posing risks to blockchain
consensus.

1 Introduction

In 2009, Bitcoin [19] introduced a new notion of decentralized cryptocurrency and trustless
transaction processing. This is facilitated by blockchain, which introduced a new way for mis-
trusting agents to cooperate without trusted third parties. This was followed by Ethereum [22],
which introduced generalized scripting functionality, allowing ‘smart contracts’ that execute al-
gorithmically in a verifiable and somewhat trustless manner. Cryptocurrencies promise notions
of cryptographic security, privacy, incentive alignment, digital usability, and open accessibility
while removing most facets of counterparty risk. However, as these cryptocurrencies are, by
their nature, unbacked by governments or physical assets, and the technology is quite new and
developing, their prices are subject to wild volatility, which affects their usability.

A stablecoin is a cryptocurrency with an economic structure built on top of blockchain
that aims to stabilize the purchasing power of the coin. A true stablecoin, often referred to as
the “Holy Grail of crypto”, would offer the benefits of cryptocurrencies without the unusable
volatility and remains elusive. A more tangible goal is to design a stablecoin that maximizes
the probability of remaining stable long-term. If one can establish guarantees for the stability
of such a stablecoin, this would be a significant step toward forming a robust decentralized
financial system and facilitating economic adoption of cryptocurrencies.

∗We thank David Easley, Steffen Schuldenzucker, Christopher Chen, Sergey Ivliev, Tomasz Stanczak, and
Sid Shekhar for helpful discussions. All errors are our own. AK and AM are funded through NSF CAREER
award #1653354. AK thanks Lykke, Binance, and Amherst College for additional financial support.
†Cornell University, Center for Applied Mathematics
‡Cornell University, Operations Research & Information Engineering

1

ar
X

iv
:1

90
6.

02
15

2v
2 

 [
q-

fi
n.

T
R

] 
 4

 J
un

 2
02

0



Cryptocurrency volatility Cryptocurrencies face difficult technological, usability, and reg-
ulatory challenges to be successful long-term. Many cryptocurrency systems develop different
approaches to solving these problems. Even assuming the space is long-term successful, there
is large uncertainty about the long-term value of individual systems.

The value of these systems depends on network effects: value changes in a nonlinear way as
new participants join. In concrete terms, the more people who use the system, the more likely
it can be used to fulfill a given real world transaction. The success of a cryptocurrency relies
on a mass of agents–e.g., consumers, businesses, and/or financial institutions–adopting the
system for economic transactions and value storage. Which systems will achieve this adoption
is highly uncertainty, and so current cryptocurrency positions are very speculative bets on new
technology. Further, cryptocurrency markets face limited liquidity and market manipulation. In
addition, the decentralized control and privacy features of cryptocurrencies can be at odds with
desires of governments, which introduces further uncertainty around attempted interventions
in the space.

These uncertainties drive price volatility, which feeds back into fundamental usability prob-
lems. It makes cryptocurrencies unusable as short-term stores of value and means of payment,
which increases the barriers to adoption. Indeed, today we see that most cryptocurrency trans-
actions represent speculative investment as opposed to typical economic activity.

Stablecoins Stablecoins aim to bootstrap price stability into cryptocurrencies as a stop-gap
measure for adoption. Current projects take one of two forms:

• Custodial stablecoins rely on trusted institutions to hold reserve assets off-chain (e.g.,
$1 per coin). This introduces counterparty risk that cryptocurrencies otherwise solve.

• Noncustodial (or decentralized) stablecoins create on-chain risk transfer markets
via complex systems of algorithmic financial contracts backed by volatile cryptoassets.

We focus on noncustodial stablecoins and, more generally, the stable asset and risk transfer
markets that they represent. Noncustodial systems are not well understood whereas custo-
dial stablecoins can be interpreted using existing well-developed financial literature. Further,
noncustodial stablecoins operate in the public/permissionless blockchain setting, in which any
agent can participate. In this setting, malicious agents can participate in stablecoin systems.
As we will see, this can introduce new economic attacks.

1.1 Noncustodial (decentralized) stablecoins

The noncustodial stablecoins that we consider create systems of contracts on-chain with the
following features encoded in the protocol. We refer to these as DStablecoins.

• Risk is transferred from stablecoin holders to speculators. Stablecoin holders receive
a form of price insurance whereas speculators expect a risky return from a leveraged
position.1

• Collateral is held in the form of cryptoassets, which backs the stable and risky positions.

• An oracle provides pricing information from off-chain markets.

• A dynamic deleveraging process balances positions if collateral value deviates too much.

• Agents can change their positions through some pre-defined process.

1‘Leverage’ means that the speculator holds > 1× their initial assets but faces new liabilities.

2



These systems are noncustodial (or decentralized) because the contract execution and collateral
are all completely on-chain; thus they potentially inherit all of the benefits of cryptocurrencies,
such as minimization of counterparty risk. DStablecoins are variants on contracts for difference,
which we describe next. The risk transfer typically works by setting up a tranche structure in
which losses (or gains) are borne by the speculators and the stablecoin holder holds an instru-
ment like senior debt.2 There are also other non-collateralized (or algorithmic) stablecoins–for
a discussion of these, see [4]. We don’t consider these directly in this paper; however, we discuss
in Section 7 how our model can accommodate these systems as well.

Contract for difference Two parties enter an overcollateralized contract, in which the spec-
ulator pays the buyer the difference (possibly negative) between the current value of a risky
asset and its value at contract termination.3 For example, a buyer might enter 1 Ether into
the contract and a speculator might enter 1 Ether as collateral. At termination, the contract
Ether is used to pay the buyer the original dollar value of the 1 Ether at the time of entry. Any
excess goes to the speculator. If the contract approaches undercollateralization (if Ether price
plummets), the buyer can trigger early settlement or the speculator can add more collateral.

Variants on contracts for difference DStablecoins differ from basic contracts for difference
in that (1) the contracts are multi-period and agents can change their positions over time, (2)
the positions are dynamically deleveraged according to the protocol, and (3) settlement times
are random and dependent on the protocol and agent decisions. The typical mechanics of these
contracts are as follows:

• Speculators lock cryptoassets in a smart contract, after which they can create new sta-
blecoins as liabilities against their collateral up to a threshold. These stablecoins are sold
to stablecoin holders for additional cryptoassets, thus leveraging their positions.

• At any time, if the collateralization threshold is surpassed, the system attempts to liqui-
date the speculator’s collateral to repurchase stablecoins/reduce leverage.

• The stablecoin price target is provided by an oracle. The target is maintained by a
dynamic coin supply based on an ‘arbitrage’ idea. Notably, this is not true arbitrage as
it is based on assumptions about the future value of the collateral.

– If price is above target, speculators have increased incentive to create new coins and
sell them at the ‘premium price’.

– If price is below target, speculators have increased incentive to repurchase coins
(reducing supply) to decrease leverage ‘at a discount’.

• Stablecoins are redeemable for collateral through some process. This can take the form of
global settlement, in which stakeholders can vote to liquidate the entire system, or direct
redemption for individual coins. Settlement can take 24 hours-1 week.

• Additionally, the system may be able to sell new ownership/decision-making shares as a
last attempt to recapitalize a failing system – e.g., the role of MKR in Dai (see [17]).

2Intuitively, these are like collateralized debt obligations (CDOs) with the important addition of dynamic
deleveraging according to the rules of the protocol. As we will see, it is critical to understand deleveraging
spirals as they affect the senior tranches.

3Intuitively, this is similar to a forward contract except that the price is only fixed in fiat terms while payout
is in the units of the underlying collateral.

3

https://makerdao.com/dai


Price (USD)

24
h 

Vo
l

NuBits Charts

Jan '15 Jul '15 Jan '16 Jul '16 Jan '17 Jul '17 Jan '18 Jul '18

2015 2016 2017 2018

$0

$0.500000

$1.00

0

Zoom 1d 7d 1m 3m 1y YTD ALL

From Sep 24, 2014 To Dec 12, 2018

Market Cap Price (USD) Price (BTC) 24h Vol
coinmarketcap.com

(a) NuBits trades at cents on the dollar.

Price (USD)

24
h 

Vo
l

bitUSD Charts

17. Sep 1. Oct 15. Oct 29. Oct 12. Nov 26. Nov 10. Dec

2016 2018

$0.600000

$0.800000

$1.00

0

Zoom 1d 7d 1m 3m 1y YTD ALL

From Sep 12, 2018 To Dec 12, 2018

Market Cap Price (USD) Price (BTC) Price (BTS) 24h Vol
coinmarketcap.com

(b) BitUSD has broken its USD peg.

Figure 1: Depeggings in decentralized stablecoins.

DStablecoin risks DStablecoins face two substantial risks:

1. Risk of market collapse,

2. Oracle/governance manipulation.

Our model in this paper focuses on market collapse risk. We further remark on oracle/governance
manipulation in Section 7.

Existing DStablecoins Examples of noncustodial stablecoins include Dai and bitUSD (as
well as other BitShares Market Pegged Assets). In Steem Dollars, Steem market cap is essen-
tially collateral. Steem dollars can be redeemed for $1 worth of newly minted Steem, and so
redemptions affect all Steem holders via inflation. Notably, unlike custodial stablecoins, Dai
is not currently considered as emoney or payment method subject to the Payment Services
Directive in the European Union since there is no single issuer or custodian. Thus it does not
have AML/KYC requirements.

In an academic white paper, [5] proposed a variation on cryptocurrency-collateralized DStable-
coin design. It standardizes the speculative positions by restricting leverage to pre-defined
bounds using automated resets. A consequence of these leverage resets is that stablecoin hold-
ers are partially liquidated from their positions during downward resets–i.e., when leverage rises
above the allowed band due to a cryptocurrency price crash. This compares with Dai, in which
stablecoin holders are only liquidated in global settlement. An effect of this difference is that,
in order to maintain a stablecoin position in the short-term, stablecoin holders need to re-buy
into stablecoins (at a possibly inflated price) after downward resets. Of the many designs, it is
unclear which deleveraging method would lead to a system that survives longer. This motivates
us to study the dynamics of DStablecoin systems.

Noncustodial stablecoins have faced surprising levels of volatility and failure. As discussed
in [11], Nubits has traded at cents on the dollar since 2018 (Figure 1a), and bitUSD and Steem
Dollars have broken their USD pegs periodically (Figure 1b). Since releasing the original form
of this paper, massive liquidation events around Black Thursday in March 2020 resulted in a
substantial depegging in Dai [16]. Despite these problems, there is a large interest to develop
new noncustodial stablecoins. For instance, Basis raised $133m in 2018 (although it has since
closed down), two other projects raised $32m each, and many other projects raised several
million [4].

4

https://bitshares.org/technology/price-stable-cryptocurrencies
https://www.steem.center/index.php?title=Steem_Dollar_(SBD)
https://nubits.com/
https://www.basis.io/


1.2 Relation to prior work

Stablecoins are active cryptocurrencies, for which pre-existing models do not understand how
the collateral rule enforces stability and how the interaction of different agents can affect sta-
bility.

With the notable exception of [5], rigorous mathematical work on noncustodial stablecoins
is lacking. They applied option pricing theory to valuing tranches in their proposed DStablecoin
design using advanced PDE methods. In doing so, they need the simplifying assumption that
DStablecoin payouts (e.g., from interest/fee payments and liquidations from leverage resets) are
exogenously stable with respect to USD. This may circularly cause stability. In reality, these
payouts are made in volatile cryptocurrency (ETH). From these ETH payments, stablecoin
holders can

1. Hold ETH and so take on ETH exposure,

2. Use the ETH to re-buy into stablecoin, likely at an inflated price as it endogenously
increases demand after a supply contraction,

3. Convert the ETH to fiat, which requires waiting for block confirmations in an exchange
(possibly hours) during times when ETH is particularly volatile and paying costs for fiat
conversion (fees, potentially taxes). Notably, this is not available in all jurisdictions.

To maintain a DStablecoin position, stablecoin holders need to re-buy into DStablecoins at
each reset at endogenously higher price. Stablecoin holders additionally face the risk that the
size of the DStablecoin market collapses such that the position cannot be maintained (and so
ends up holding ETH). As no stable asset models exist to understand these endogenous effects,
the analysis can’t be easily extended using the traditional financial literature.4 Our focus in
this paper is complementary to understand these endogenous stable asset effects.

[14] studied the evolution of custodial stablecoins.
In the context of central counterparty clearinghouses, the default fund contributions, margin

requirements and participation incentives have been studied in, e.g., [6], [1], and [8]. The
critical question in this area is understanding the effects of a liquidation policy of a member’s
portfolio in the case of a significant event. The counterpart of this in a decentralized setting is
understanding the impact of DStablecoin deleveraging on system stability.

Stablecoin holders bear some resemblance to agents in currency peg and international finance
models, e.g., [18] and [9]. In these models, the market maker is essentially the government but
is modeled with mechanical behavior and is not a player in the game. For instance, in [9],
devaluation is modeled by a simple exogenous threshold rule: the government abandons the
peg if the net demand for currency breaches the threshold and is otherwise committed to
maintaining the peg. In contrast to currency markets, no agents are committed to maintaining
the peg in DStablecoin markets. The best we can hope is that the protocol is well-designed
and that the peg is maintained with high probability through the protocol’s incentives. The
role of government is replaced by decentralized speculators, who issue and withdraw stablecoins
in a way to optimize profit. A fully strategic model would be a complicated dynamic game–
these tend to be intractable and, indeed, are avoided in the currency peg literature in favor
of a sequence of one period games. We enable a more endogenous modeling of speculators’
optimization problems under a variety of risk constraints. Our model is a sequence of one-
period optimization problems, in which dynamic coupling comes through the risk constraints.

4A secondary issue with their continuous model is that these systems are inherently discontinuous due to
the discrete nature of incorporating blockchain transactions into blocks. Thus resets can occur beyond the set
thresholds.

5



DStablecoin speculators are similar to market makers in market microstructure models (e.g.,
[20]). Like classical market microstructure, we do have a multi-period system with multiple
agents subject to leverage constraints that take recurring actions according to their objectives.
In contrast, in the DStablecoin setting, we do not have a truly stable asset that is efficiently
and instantaneously available. Instead, agents make decisions that endogenously affect the
price of the ‘stable’ asset and affect the agents’ future decisions and incentives to participate
in a non-stationary way. In turn, the (in)stability results from the dynamics of these decisions.

Since the initial release of our paper in June 2019, [13] has described a complementary model
of noncustodial stablecoins related to the model in this paper. That paper explores a different
model of liquidation structure that affects speculator decision-making and applies martingale
methods to analytically characterize stability. In contrast, in this paper we derive stability
results about a simpler model that is more amenable to simulations, which we perform, and
demonstrate stablecoin attacks that can arise from profitable bets against other agents.

1.3 This paper

We develop a dynamic model for noncustodial stablecoins that is complex enough to take into
account the feedback effects discussed above and yet remains tractable. Our model can be
interpreted as a market microstructure model in this new type of asset market.

Our model involves agents with different risk profiles; some desire to hold stablecoins and
others speculate on the market. These agents solve optimization problems consistent with a
wide array of documented market behaviors and well-defined financial objectives. As is common
in the literature on market microstructure and currency peg games, these agents’ objectives
are myopic. These objectives are coupled for non-myopic risk using a flexible class of rules that
are widely established in financial markets; these allow us to model the effects of a range of
cyclic and counter-cyclic behaviors. The exact form of these rules is selected and self-imposed
by speculators to match their desired responses and not part of the stablecoin protocol. Thus
well-established manipulation of similar rules as applied to traditional financial regulation is
not a problem here. Our model goes largely beyond a one-period model. We introduce this
model with supporting rationale for design choices in Section 2.

Using our model, we make the following contributions:

• We derive fundamental results bout dynamics and liquidity in our model (Section3).

• We demonstrate that stablecoins face deleveraging feedback effects that may cause illiq-
uidity during crises and exacerbate collateral drawdown (Section 3.3).

• We characterize stable dynamics of the system under certain conditions that guarantee
no liquidity crash (Section 4) and show instability can occur in simulations outside of this
setting (Section 4.2).

• We simulate a wide range of market behaviors and find that speculator behavior has a
large effect on realized volatilities, but that stablecoin failure times are largely determined
by underlying asset movements (Section 5).

• We describe new attacks that exploit arbitrage-like opportunities around stablecoin liq-
uidations (Section 6)

We relate these results to historicla stablecoin events, apply these insights to suggest design
improvements that aim to improve long-term stability. Based on these insights, we also sug-
gest that interactions between multiple speculators and attackers may be the most interesting
relationships to explore in more complex models.

6



2 Model

Our model couples a number of variables of interest in a risk transfer market between stablecoin
holders and speculators. The stablecoin protocol dictates the logic of how agents can interact
with the smart contracts that form the system; the design of this influences how the market
plays out. Many DStablecoin designs have been proposed. We set up our model to emulate a
DStablecoin protocol like Dai with global settlement, but the model is adaptable to different
design choices. Note that our model is formulated with very few parameters given the problem
complexity.

Our model builds on the model of traditional financial markets in [2] but is new in design by
incorporating endogenous stablecoin structure. In the model, we assume that the underlying
consensus layer (e.g., blockchain) works well to confirm transactions without censorship or
attack and that the system of contracts executes as intended.

Agents Two agents participate in the market.

• The stablecoin holder seeks stability and chooses a portfolio to achieve this.

• The speculator chooses leverage in a speculative position behind the DStablecoin.

Stablecoin holders are motivated by risk aversion, trade limitations, and budget constraints.
They are inherently willing to hold cryptoassets. In the current setting, this means they are
likely either traders looking for short-term stability, users from countries with unstable fiat
currencies, or users who are using cryptocurrencies to move money across borders. In the future,
cryptocurrencies may be more accepted in economic exchange. In this case, stablecoin holders
may be ordinary consumers who face risk aversion and budgeting for required consumption.

Speculators are motivated by (1) access to leverage and (2) security lending to borrow
against their Ether holdings without triggering tax incidence or giving up Ether ownership.
In order to begin participating, speculators need to either have confidence in the future of
cryptocurrencies, think they can make money trading the markets, or face unusually high tax
rates (or other barriers) that make security lending cheaper than outright selling assets. The
model in this paper focuses on the first motivation. We propose an extension to the model that
considers the second motivation.

Assets There are two assets. For simplicity, we give these assets specific names; however,
they could be abstracted to other cryptocurrencies or outside of a cryptocurrency setting.

• Ether: high risk asset whose USD market prices pEt are exogenous

• DStablecoin: a ‘stable’ asset collateralized in Ether whose USD price pDt is endogenous

Notably, a large DStablecoin system may have endogenous amplification effects on Ether
price, similarly to how CDOs affected underlying assets in the 2008 financial crisis. We discuss
this further in Section 7 but leave formal modeling of this to future work.

There are several barriers for trading between crypto and fiat, which motivate our choice
of assets. Most crypto-fiat pairs are through Bitcoin or Ether, which act as a gateway to other
cryptoassets. Trading to fiat can involve moving assets between a number of exchanges and can
take considerable time to confirm on the blockchain. Trading to a stablecoin is comparatively
simple. Trading to fiat can also trigger more clear tax incidence. Additionally, some countries
have imposed strict capital controls on trading between fiat and crypto.

7



Model outline At t = 0, the agents have endowments and prior beliefs. In each period t:

1. New Ether price is revealed

2. Ether expectations are updated

3. Stablecoin holder decides portfolio weights

4. Speculator, seeing demand, decides leverage

5. DStablecoin market is cleared

2.1 Stablecoin holder

The stablecoin holder starts with an initial endowment and decides portfolio weights to attain
the desired stability. The following table defines the agent’s state variables.

Variable Definition
n̄t Ether held at time t
m̄t DStablecoin held at time t
wt Portfolio weights chosen at time t

The stablecoin holder weights its portfolio by wt. We denote the components as wEt and
wDt for Ether and DStablecoin weights respectively. The stablecoin holder’s portfolio value at
time t is

At = n̄tp
E
t + m̄tp

D
t = n̄t−1p

E
t + m̄t−1p

D
t .

Given weights, n̄t and m̄t will be determined based on the stablecoin clearing price pDt .
The basic results in Section 3 hold generally for any wt ≥ 0 (i.e., there is no shorting). In this

case, wt could be chosen, e.g., from Sharpe ratio optimization, mean-variance optimization, or
Kelly criterion (among others). In Sections 4 & 5, in order to focus on the effects of speculator
decisions, we simplify the stablecoin holder as exogenous with unit price-elastic demand. In
this case, DStablecoin demand is constant in dollar terms.

2.2 Speculator

The speculator starts with an endowment of Ether and initial beliefs about Ether’s returns and
variance and decides leverage to maximize expected returns subject to protocol and self-imposed
constraints. The following table defines variables and parameters for the speculator.

Variable Definition
nt Ether held at time t
rt Expected return of Ether at time t
σ2
t Expected variance of Ether at time t
Lt Total stablecoins issued at time t
∆t Change to stablecoin supply at time t

Ν̃t Leverage bound at time t

Parameter Definition
Îł Memory parameter for return estimation
δ Memory parameter for variance estimation
β Collateral liquidation threshold
Îą Inverse measure of riskiness
b Cyclicality parameter

8



2.2.1 Ether expectations

The speculator updates expected returns rt, log-returns Âľt (used for the variance estimation),
and variance σ2

t based on observed Ether returns as follows:

rt = (1− γ)rt−1 + γ
pEt
pEt−1

,

µt = (1− δ)µt−1 + δ log
pEt
pEt−1

,

σ2
t = (1− δ)σ2

t−1 + δ
(

log
pEt
pEt−1

− µt
)2

.

(1)

For fixed memory parameters γ, δ (lower memory parameter = longer memory), these are ex-
ponential moving averages consistent with the RiskMetrics approach commonly used in finance
[15]. For sufficiently stepwise decreasing memory levels and assuming i.i.d. returns, this process
will converge to the true values supposing they are well-defined and finite. In reality, specula-
tors don’t outright know the Ether return distribution and, as we will see in the simulations,
the stablecoin system dynamics occur on timescales shorter than required for convergence of
expectations. Thus, we focus on the simpler case of fixed memory parameters.

Note that γ 6= δ may be reasonable. Current cryptocurrency markets are not very price
efficient, and so traders might reasonably take into account momentum when estimating returns
while using a wider memory for estimating covariance.

We additionally consider the case in which the speculator knows the Ether distribution
outright and γ = δ = 0. This is consistent with a rational expectations standpoint but ignores
how the speculator arrives at that knowledge.

2.2.2 Optimize leverage: choose ∆t

The speculator is liable for Lt DStablecoins at time t. At each time t, it decides the number of
DStablecoins to create or repurchase. This changes the stablecoin supply Lt = Lt−1 + ∆t. If
∆t > 0, the speculator creates and sells new DStablecoin in exchange for Ether at the clearing
price. If ∆t < 0, the speculator repurchases DStablecoin at the clearing price.

Strictly speaking, the speculator will want to maximize its long-term withdrawable value.
At time t, the speculator’s withdrawable value is the value of its ETH holdings minus collateral
required for any issued stablecoins: ntp

E
t − βLt. Maximizing this is not amenable to a myopic

view, however, as maximizing the next step’s withdrawable value is only a good choice when
the speculator intends to exit in the next step.

Instead, we frame the speculator’s objective as maximizing expected equity: ntp
E
t −E[pD]Lt.

In this, the speculator expects to be able to settle liabilities at a long-term expected value of
E[pD]. The market price of DStablecoin will fluctuate above and below $1 naturally depending
on prevailing market conditions. The actual expected value is nontrivial to compute as it
depends on the stability of the DStablecoin system. For individual speculators with small
market power, we argue that E[pD] = 1 is a an assumption they may realistically make, as we
discuss further below. This is additionally the value realized in the event of global settlement.

We suggest that this optimization is a candidate for ‘honest’ behavior of a speculator as it
is consistent with the speculator acting on perceived arbitrage in mispricings of DStablecoin
from the peg. In essence, the speculator expects to increase (reduce) leverage ‘at a discount’
when pDt is above (below) target. This is the typically cited mechanism by which these systems
maintain their peg and thus how the designers intend for speculators to behave. However, this

9



assumes that pDt is sufficiently stable/mean-reverting to $1 and so this behavior may not in
fact be a best response.

Aggregate vs. individual speculators In our model, the single speculative agent, which is
not a price-taker, is intended to reflect the aggregate behavior of many individual speculators,
each with small market power.5 In a normal liquid market, an individual speculator would be
able to repurchase DStablecoins at dollar cost and walk away with the equity. By maximizing
equity, the aggregate speculator considers its liabilities to be $1 per DStablecoin. This may turn
out to be untrue during liquidity crises as the repurchase price may be higher. In our model,
speculator’s don’t know the probability of crises and instead account for this in a conservative
risk constraint.

Formal optimization problem The speculator chooses ∆t by maximizing expected equity
in the next period subject to a leverage constraint:

max
∆t

rt

(
nt−1p

E
t + ∆tp

D
t (Lt)

)
− Lt

s.t. ∆t ∈ Ft

where Ft is the feasible set for the leverage constraint. This is composed of two separate
constraints: (1) a liquidation constraint that is fundamental to the protocol, and (2) a risk
constraint that encodes the speculator’s desired behavior. Both are introduced below.

If the leverage constraint is unachievable, we assume the speculator enters a ‘recovery mode’,
in which it tries to maximize its chances of returning to the normal setting. In this case, it
solves the optimization using only the liquidation constraint. If the liquidation constraint is
unachievable, the DStablecoin system fails with a global settlement.

2.2.3 Liquidation constraint: enforced by the protocol

The liquidation constraint is fundamental to the DStablecoin protocol. A speculator’s position
undergoes forced liquidation at time t if either (1) after pEt is revealed, nt−1p

E
t < βLt−1, or

(2) after ∆t is executed, ntp
E
t < βLt. The speculator aims to control against this as liquidations

can occur at unfavorable prices and are associated with fees in existing protocols (we exclude
these fees from our simple model, but they can be easily added).

Define the speculator’s leverage as the β-weighted ratio of liabilities to assets6

Îťt =
β ¡ liabilities

assets
.

The liquidation constraint is then λt ≤ 1.

2.2.4 Risk constraint: self-imposed speculator behavior

The risk constraint encodes the speculator’s desired behavior into the model. We assume
no specific type for the risk constraint in our analytical results, which are generic. For our
simulations, we explore a variety of speculator be";"""date"",""2020-06-05T00:42:02Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2020-06-05T00:42:02Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016) kpathsea version 6.2.2""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2020-06-05T00:42:02Z""
""created"",""2020-06-05T00:42:02Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-06-05T00:42:02Z""
""resourceName"",""academic%20Deleveraging%20Spirals%20and%20STABLECOIN%20attacks.pdf""
""Author"",""""
""producer"",""pdfTeX-1.40.17""
""pdf:docinfo:producer"",""pdfTeX-1.40.17""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""3"",""5"",""6"",""2"",""4"",""0"",""0"",""1"",""10"",""0"",""0"",""0"",""0"",""1"",""0"",""0"",""0"",""0"",""0"",""7"",""13"",""27"",""12""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2020-06-05T00:42:02Z""
""Last-Modified"",""2020-06-05T00:42:02Z""
""dcterms:modified"",""2020-06-05T00:42:02Z""
""title"",""""
""Last-Save-Date"",""2020-06-05T00:42:02Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2020-06-05T00:42:02Z""
""meta:save-date"",""2020-06-05T00:42:02Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016) kpathsea version 6.2.2""
""Content-Length"",""1407515""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""31""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""2605"",""2941"",""3041"",""2596"",""3224"",""3111"",""2875"",""1740"",""2795"",""2571"",""2526"",""1976"",""1360"",""2844"",""2597"",""1407"",""2594"",""2549"",""2778"",""2291"",""1751"",""2571"",""3157"",""3410"",""3176"",""2432"",""1835"",""1712"",""1354"",""1022"",""595""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-06-05T00:42:02Z""
";https://scholar.google.com/scholar?start=630&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094602-912;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Truffle tests for free--Replaying Ethereum smart contracts for transparency;P Hartel, M van Staalduinen ; arXiv preprint arXiv:1907.09208, 2019  arxiv.org;;"… summary The Ethereum blockchain is essentially a globally replicated public database … Over

10 million smart contracts have been deployed on the Ethereum blockchain. Executing a method

of a smart contract generates a transaction that is also stored on the blockchain …";Cité 3 fois;Les 6 versions;[PDF] arxiv.org;https://arxiv.org/pdf/1907.09208;"
ARTICLE TYPE

Truffle tests for free -
Replaying Ethereum smart contracts for transparency

Pieter Hartel1 | Mark van Staalduinen2

1iTRust, Singapore University of
Technology and Design, Singapore,
ORCID 0000-0002-0411-0421

2TNO-SEA, The Netherlands Organisation
for Applied Scientific Research, Singapore,
ORCID 0000-0001-9716-3815

Correspondence
Email: pieter_hartel@sutd.edu.sg

Funding
This work was supported in part by the
National Research Foundation (NRF), Prime
Minister’s Office, Singapore, under its
National Cybersecurity R&D Programme
(Award No. NRF2016NCR-NCR002-028)
and administered by the National
Cybersecurity R&D Directorate.

summary

The Ethereum blockchain is essentially a globally replicated public database. Pro-
grams called smart contracts can access this database. Over 10 million smart
contracts have been deployed on the Ethereum blockchain. Executing a method of
a smart contract generates a transaction that is also stored on the blockchain. There
are over 1 billion Ethereum transactions to date. Smart contracts that are transparent
about their function are more successful than opaque contracts. We have there-
fore developed a tool (ContractVis) to explore the transparency of smart contracts.
The tool generates a replay script for the historic transactions of a smart contract.
The script executes the transactions with the same arguments as recorded on the
blockchain, but in a minimal test environment. Running a replay script provides
insights into the contract, and insights into the blockchain explorer that was used to
retrieve the contract and its history. We provide five concrete recommendations for
blockchain explorers like Etherscan to improve the transparency of smart contracts.

KEYWORDS:
Blockchain, smart contracts, Ethereum, testing

1 INTRODUCTION

Software transparency is defined as the condition that all functions of software are disclosed to its users1. Most software is
complex, which makes it easy for developers to hide specific functions, either deliberately or inadvertently2. This complexity
reduces transparency. In this paper we study blockchain-related software, and in particular smart contracts on Ethereum, written
in Solidity. Smart contracts on Ethereum are not normally complex3, which should improve their transparency. Ethereum smart
contracts execute on a complex infrastructure, the backbone of which, the blockchain, is a globally replicated data structure that
is available for public scrutiny. This should also contribute to transparency of the infrastructure4.
One of the tools commonly used for the analysis of the public blockchain is the blockchain explorer. It interprets the blockchain

and shows the complete history of every contract ever made. The most prominent blockchain explorer for Ethereum is Etherscan.
In addition to the standard features of a blockchain explorer, such as listing blocks and transactions, Etherscan allows developers
to upload the source code of a smart contract. Etherscan then verifies that the bytecode that is deployed on the blockchain can
be reproduced by compiling the uploaded source. This allows the user of a verified smart contract to inspect the source code of
the contract. But what if the user is not able to audit the source code? An alternative approach would be to deploy sophisticated
program analysis tools to analyse the contract. Such approaches work with abstractions that must be proved sound. We discuss
the merits of the most prominent approaches in Section 7.

1

ar
X

iv
:1

90
7.

09
20

8v
1 

 [
cs

.S
E

] 
 2

2 
Ju

l 2
01

9



Our approach to analyse contracts is a different one. We propose to “Try the simplest thing first”. By this we mean executing
the contract in a minimal testing environment, and then to compare the execution results to the historic execution results of
the contract on the blockchain. We will work with the Solidity source of a smart contract. It would be possible to decompile
something resembling source code from bytecode but this will never be as transparent as the original source because comments
cannot be recovered by decompilation. We use standard tools to execute smart contracts, which means that soundness is not
an issue. We have developed a tool that generates a test script for a verified smart contract from its historic transactions on the
blockchain. If the contract fails, it must depend either on other contracts, or on the infrastructure. This is evidence of opacity. In
theory it is possible to discover the dependencies of a smart contract by analysing the blockchain. However, current blockchain
explorers do not disclose all dependencies. This made it necessary to develop ContractVis to discover (a) all dependencies, and
(b) the extent to which dependencies hide functions of smart contracts, thereby reducing transparency.
The tool can be used in three different ways. Firstly, when a test is executed in the minimal test environment, the historic

transactions are replayed. If the contract does not have any dependencies on other contracts, or on the infrastructure, it will
successfully execute. This is evidence of transparency.
Secondly, when the contract, the test, and / or the configuration of the environment are changed prior to replaying, we can run

experiments. For example we can explore what-if questions, such as what if the time stamp of the current block is a sequence
(e.g. 1,2,3)? Would our lottery contract still be fair?
Thirdly, a generated test can be used as a regression test in further development of the contract, or as input to other testing

tools, such as fuzzers and mutators.
Debuggers and fuzzers can also replay smart contracts. The Truffle development framework (See http://truffleframework.com)

represents the state-of-the-art in smart contract debugging. By specifying the unique hash of a transaction to the command
truffle debug it is possible to replay an existing transaction on the blockchain, stepping into and over calls, single-stepping
the execution of the bytecode etc. Other development environments offer similar facilities. However, debuggers usually do not
generate test scripts that developers can experiment with, hence exploring what-if questions is infeasible with existing debuggers.
Fuzzers5 generate tests with well-chosen, random inputs to drive the contract into an error state. The developer can then use

the information about the inputs and the error state to improve the contract. Our approach is different in that we use historic
inputs to drive the contract into a correct state. If this fails and the contract reaches an error state, the developer has gained
insight into the contract.
Smart contracts are unique in the sense that the complete set of historic inputs to each contract is available on the blockchain.

For programs other than smart contracts, some logging information is usually available, but this is rarely sufficient to replay the
program. For example checkpoint restart systems6 take great care to augment logs with the minimum information necessary
to replay an execution efficiently. Debugging systems for concurrent programs require significant sophistication to be able to
reproduce concurrent executions faithfully7.
Smart contracts should not need extra information for accurate replay. After all, each full node that joins the Ethereum peer-to-

peer network replays all historic transactions. The question is, to what extent the historic transactions of a smart contract can be
replayed on a minimal testing environment. By a minimal testing environment we mean using (a) the source of smart contracts
and historic transactions (i.e. Etherscan), (b) the testing framework to replay the contracts (i.e. the Truffle framework), and (c)
bespoke scripting (i.e. ContractVis) to translate historic transactions into truffle test scripts.
Our contributions are as follows. Firstly, we measure to what extent smart contracts depend on other contracts and on the

environment. To learn of all the functionalities of such contracts, users have to study not only the source, but also the dependen-
cies. The more dependencies a contract has, the more effort will be required to achieve transparency. Secondly, we show that
certain aspects of the behaviour of smart contracts can be tracked intuitively with automatically generated heat maps. Thirdly,
we suggest improvements to current blockchain explorers that give users and developers automated insight into the dependen-
cies. Finally, the paper contains details on the implementation of smart contracts on Ethereum that is available on the web but
not in one place. We hope that by exposing this information we contribute to transparency.
The next section discusses the background and presents the research questions. Section 3 describes the experimental approach

and Section 4 presents the results of the experiments. Recommendations for the developers of blockchain explorers are provided
in Section 5. This is followed by the discussion, related work, limitations, conclusions and future work.

2

http://truffleframework.com


2 BACKGROUND

We summarise how smart contracts are executed, how they can be replayed and how the accuracy of the replay scripts can be
measured. We then formulate a number of research questions.

2.1 Smart contracts
A smart contract is a program that executes and stores its data on a globally replicated database called a blockchain. The
constructor and the methods of a smart contract encode the business logic of a distributed web application called a Distributed
Application (DApp). The call to the constructor and every method call made by the DApp create one or more transactions,
which are stored in a specific block on the blockchain. The blockchain is basically an append-only, replicated database. A global
peer-to-peer network operated by so-called miners manages the Ethereum blockchain. The miners run a distributed agreement
protocol to decide which blocks are append to the blockchain. The miners are financially rewarded for their efforts. Once stored
in a block on the blockchain, transactions normally persist (except in the case of forks). Because of the global replication of the
blockchain, transactions are censorship resistant.
When a contract is deployed, the EthereumVirtual Machine (EVM) bytecode obtained by compiling the source of the contract

is also stored on the blockchain. The blockchain does not only store contracts and transactions but also accounts with a monetary
balance in Ether, which is the native currency of Ethereum. At the time of writing, the value of an Ether is about 330 US$.
There are two types of accounts: an externally owned account, defined by creation of a public private key pair and a contract
account, defined by the deployment of a contract. Each transaction has a unique hash and each contract account or externally
owned account is identified by a unique address.
When the constructor and the methods of a contract are executed, a sequence of transactions is generated, starting with the

transaction that created the contract. Each transaction changes the state of the contract variables. A transaction may change the
balance of accounts, and it usually emits events to pass information to the controlling DApp. A transaction does not have a
return value. Every successful transaction consumes a certain amount of gas proportional to the amount of work performed by
the contract. Gas costs Ether and the total gas consumption of a transaction is therefore an interesting output of a contract. A
transaction may fail and it therefore has a status. For example, if the amount of gas provided is insufficient, the transaction will
fail. This mechanism is used, amongst others, to prevent infinite loops. Transactions are cryptographically signed to ensure that
only users in possession of the appropriate private key can make transactions.
Ethereum has two types of transactions: internal and external. The external transactions are triggered by externally owned

accounts. Internal transactions are triggered by contract accounts.
Transactions can fail programmatically, via calls to either require() or assert(). require() is used to check external

consistency (e.g. to make sure that inputs satisfy specific requirements). assert() is used to check internal consistency (e.g. to
ensure that the balance of an account does not underflow).
A contract does not only contain methods that change the state but also pure functions that only read the state of the contract

from the blockchain. Pure functions are called to return information about the state of the contract to the DApp. Calls to pure
functions always succeed and do not consume gas.
By the outputs of a contractwe mean the state and gas consumption of transactions, and the emitted events of transactions. To

trace the execution of a contract, it would be useful to visualise all of the outputs on a time line. For example if most transactions
succeed but an occasional transaction fails, this should stand out in a visualisation. There are many outputs that can in principle
be tracked and visualised but the user would soon be overwhelmed. The challenge is to focus on the most useful outputs, and to
do so automatically.
Developers of smart contracts for Ethereum often use the Truffle framework to test contracts. The tests are written in JavaScript

and the truffle framework ensures that the tests can communicate with the contact when it is deployed on one of the test networks
or the main Ethereum network. The Truffle framework requires a directory with number of files as shown below. The directory
contracts contains the Solidity code of the contract to be tested (here Vitaluck.sol) as well as a migration contract that
is used by the Truffle framework in the deployment phase. The test directory contains the test script for the contract (here
vitaluck.js). Section 3.2 gives an example of a test script. We refer the reader to the documentation of the Truffle framework
for further details.

Vitaluck/
|-- contracts/

3



| |-- Migrations.sol
| +-- Vitaluck.sol
|-- migrations/
| +-- 1_initial_migration.js
+-- test/

|-- vitaluck.js
+-- truffle-config.js

2.2 A model of replay accuracy
We present a model of the differences between the historic execution of a smart contract as recorded on the blockchain and the
isolated replay on a minimal testing environment. We discuss the issues that will arise, and propose an experiment to measure
their effect on replay accuracy.
To assess the extent to which a contract has been replayed accurately we need a definition of replay accuracy. A strict definition

might require that all outputs of each transaction are the same in the replay as in the historic transaction. This would not be a
particularly useful definition as there are too many environmental parameters over which we have no control. For example the
amount of gas used by a transaction is not necessarily the same on all EVM implementations. Therefore, we propose a definition
of replay accuracy that takes the most important outputs into account: the transaction status, and the event parameters.
Status accuracy measures the extent to which the historic status of each transaction can be reached when replaying the contract

with historic inputs in a minimal testing environment.

status accuracy If the status of the first t ≤ T transactions of the replay run is the same as the status of the first T
transactions of the historic run, we have t∕T replay accuracy.

If the status of two transactions disagrees, the state variables of the historic and the replay run may also disagree. Therefore, we
stop counting after the first status disagreement.
Event accuracy measures to what extent the transaction events of the replay transaction agree with the transaction events of

the historic transactions. For each event emitted by a contract, each parameter of the historic transaction must be the same as
the corresponding parameter of the replay. If a replayed transaction fails where the historic transaction succeeds, there will not
be any output for the replay, and the comparison yield false. The definition of event accuracy is:

event accuracy If the event parameters of the first t ≤ T transactions of the replay run are the same as the event parameters
of the first T transactions of the historic run, we have t∕T event accuracy.

Status and event accuracy are numbers between 0 and 1. We will sometimes refer to just replay accuracy when it does not
matter which of the two is meant.
In the following sections we will discuss how the environment in which a contract is executed can affect replay accuracy.

Contracts can interact with the environment in two ways. A contract may (a) use special variables to access the environmental
parameters, or (b) it may call, or it may be called, by another contract.

2.3 Special contracts
Contracts are in principle deterministic. I.e. running the same sequence of transactions twice with the same inputs should lead to
the same sequence of outputs. However, if a contract uses special variables, replaying a sequence of transactions usually leads
to a different sequence of outputs. The special variables are block, which gives access to various properties of the current block,
now, the time stamp in seconds of the current block, and blockhash, the hash of any of the last 256 blocks. A contract that uses a
special variable will be called a special contract. A contract that does not use a special variable will be called a regular contract.
Since special contracts do not necessarily generate the same sequence of outputs when a particular sequence of transaction is

replayed, it makes sense to track not just the outputs of one sequence of replayed transactions but also the outputs of a number of
replay sequences. To visualise the output of these multiple replays, we can conveniently create a table for every individual output,
with rows enumerating the transactions and columns enumerating the individual replay runs. The behaviour of the individual

4



outputs can then be visualised with a heat map. For example the amount of the gas used by each transaction is a useful individual
output to track, as illustrated in Figure 2. We will explain the figure in more detail later.
Special contracts are designed to behave differently each time they are replayed, and we should expect the replay accuracy to

be reduced. Therefore we hypothesise that: Special contracts have lower replay accuracy than regular contracts.

2.4 Dependent contracts
Smart contracts often call methods of other smart contracts. For example Etheroll (See https://etherscan.
io/address/0xddf0d0b9914d530e0b743808249d9af901f1bd01#code) is a client that calls methods of a server
OraclizeAddressResolver (See https://etherscan.io/address/0x1d3b2638a7cc9f2cb3d298a3da7a90b67e5506ed#code).
This dependency is transparent because the name of the callee is explicitly mentioned in the source of the caller. A fragment of
the code of Etheroll is shown below, as an illustration of how a typical client obtains access to a server. The modifier coupon
contains a call to the method getAddress() of the address resolver contract OAR. The result is the current address of the Ora-
clize contract, which is stored in the variable oraclize, ready for further use. The bottom of the code fragment below shows
that the type of the hard coded address of the Oraclize proxy is cast into the contract interface type OraclizeAddrResolverI.
The result of the type cast is assigned to the variable OAR.

contract Etheroll {
....

}
contract OraclizeAddrResolverI { // Contract interface

function getAddress() returns (address _addr);
}
contract usingOraclize {

OraclizeAddrResolverI OAR;
OraclizeI oraclize;
modifier coupon(string code){

oraclize = OraclizeI(OAR.getAddress()); // Type cast to contract
...

}
...

OAR = // Type cast to proxy contract interface
OraclizeAddrResolverI(0x1d3B2638a7cC9f2CB3D298A3DA7a90B67E5506ed);

...
}

The hard coded address 0x1d3B... is the permanent address of the proxy of the Oraclize contract. The code of the proxy
contract OraclizeAddrResolver is shown in full below. The constructor stores the address of the account that deployed the
proxy in the variable owner. Only the owner can change this by calling the method changeOwner. The owner of the proxy
can also change the address of the server by calling setAddress(). A client of the proxy, such as Etheroll, can only call
getAddress() to obtain the current address of the server.

contract OraclizeAddrResolver {
address public addr;
address owner;
function OraclizeAddrResolver(){

owner = msg.sender; // Set initial owner
}
function changeOwner(address newowner){

if (msg.sender != owner) throw;
owner = newowner; // Change owner

}

5

https://etherscan.io/address/0xddf0d0b9914d530e0b743808249d9af901f1bd01#code
https://etherscan.io/address/0xddf0d0b9914d530e0b743808249d9af901f1bd01#code
https://etherscan.io/address/0x1d3b2638a7cc9f2cb3d298a3da7a90b67e5506ed#code


function setAddr(address newaddr){
if (msg.sender != owner) throw;
addr = newaddr; // Change server

}
function getAddress() returns (address oaddr){

return addr; // Return the current server
}

}

The proxy acts as gateway to the server contract. Putting a proxy between the client and the server makes it possible to update
the server without having to update the clients. This is useful, as contracts cannot be changed; they can only be redeployed.
However, having proxies is also opaque, as the client may rely on specific server functionality that can change without the client’s
knowledge. If we take the servers point of view, then on the one hand it is useful that any client can make use of the server.
On the other hand the server has no way of knowing a-priori which clients will be calling its functions. Unfortunately, current
blockchain explorers do not show a-posteriori who called a particular server. This is a significant transparency issue.
Replaying a smart contract without its dependencies usually fails. Therefore, we hypothesise that: A contract that casts an

address type to a contract type will have lower replay accuracy than a contract without such a type cast.

2.4.1 Calls from other contracts
Detecting calls from other contracts on the blockchain is a problem because with the current Ethereum APIs there is no efficient
way of locating all caller contracts that call a method of a specific callee. Basically one would have to search over a billion
transactions on the Ethereum blockchain to expose all calls. Google Big query offers a public data base of all Ethereum trans-
actions (See https://console.cloud.google.com/bigquery?p=bigquery-public-data&d=ethereum_blockchain) that makes such a
search possible. Since the service is paid, we do not consider it here as a source of data for our replay tooling. Current blockchain
explorers do not show callers from other contracts, but they do show all callees. It should therefore not be difficult to show also
the callers.
Replaying a smart contract without calls from other contracts may fail. Therefore, we hypothesise that: A contract that is

called by other contracts will have lower replay accuracy than a contract without such calls.

2.4.2 Ad-hoc address encoding
Smart contracts operate on the addresses of externally owned accounts and contract accounts. Since we do not possess the private
key associated with the externally owned accounts, we have to replace historic addresses that occur in contracts and transactions
by addresses for which we do have the private key in our minimal test environment. The basic set of addresses used by a contract
consists of the contract address, and the addresses passed via the from and to parameters of the transactions. Transactions may
also carry additional parameters of type address, and there may also be hard-coded addresses in the source of the contract. Most
contracts identify hard-coded addresses in the source by giving them the address type, but sometimes they are merely typed
as integers. Since all valid addresses are exactly 20 bytes, we assume, heuristically, that we are dealing with an address if we
encounter a 40 hex digit integer.
Unfortunately, addresses may also be encoded in an ad-hoc manner. For example the contract Ledger (See https://etherscan.io/

address/0xe6a51bd48f93abcd6c1d532112094044971d8d4e#code) contains the multiMintmethod shown below. The elements
of the array bits contain an encoding of address and amount pairs. The encoding is the concatenation of a 96-bit value with a
160-bit address. Since we use the standard tools to compile contracts and to replay transactions, we can simply extract all decoded
addresses from the debug output from ganache, the EVM client (See https://github.com/trufflesuite/ganache). A blockchain
explorer could in principle use the same strategy to extract decoded addresses.

function multiMint( uint[] bits ) {
for( uint i=0; i<bits.length; i++ ) {

address a = address( bits[i]>>96 );
uint amount = bits[i]&((1<<96) - 1);
mint( a, amount );

}

6

https://console.cloud.google.com/bigquery?p=bigquery-public-data&d=ethereum_blockchain
https://etherscan.io/address/0xe6a51bd48f93abcd6c1d532112094044971d8d4e#code
https://etherscan.io/address/0xe6a51bd48f93abcd6c1d532112094044971d8d4e#code
https://github.com/trufflesuite/ganache


}

Assuming that a minority of the historic addresses are encoded in an ad-hoc fashion, we think that there will be a relatively
small residue of such addresses in the replay scripts. Since these may cause transactions to fail, we hypothesise that: A residue
of ad-hoc encoded historic addresses has a negligible effect on replay accuracy.

2.5 Research questions
The above considerations lead to the following research questions:
Q1: To what extent does Etherscan provide the information necessary to replay contracts with Truffle?
Q2: To what extent does the presence of (a) special variables, (b) address-to-contract type casts, (c) internal transactions, and

(d) residual historic addresses influence replay accuracy?
Q3: How to track and visualise the most interesting outputs (e.g. status, event parameters) of the contracts?

2.6 A case study in transparency: Vitaluck
To illustrate the utility of replaying a contract with historic inputs we will elaborate on a case study presented in a recent publica-
tion8. Vitaluck (See https://etherscan.io/address/0xef7c7254c290df3d167182356255cdfd8d3b400b#code) is a lottery contract
with only 27 transactions. This makes it sufficiently small to be used as a case study.
The problem that we will focus on is not new, but we believe that our way of analysing the problem is more intuitive that

the usual source code inspection. While there are several proposals for a good source of randomness in smart contracts9, most
developers use special variables like now as a source of randomness. To some extent miners can manipulate special variables,
which makes this problematic. Vitaluck also uses now and we will replay all the transactions of the contract with a timestamp
that is perfectly controlled to illustrate the problem of using now.
The smart contract code of Vitaluck in essence uses the time stamp of the current block (viz. (now*2)%1000) as a random

number. On the public blockchain this should not be much of a problem as blocks are created about every 14 seconds. However,
if now increases by 1 each time a transaction occurs, as it does on our minimal testing environment, the random number used by
Vitaluck will only increase by two.
The heat maps of Figure 1 illustrate the problem. In each of the two panels, there are 5 columns, labelled 0 to 4. These

correspond to 5 replay runs of the sequence of 27 transactions of the contract. Each row corresponds to a transaction. Rows 0
and 1 represent the contract deployment. Rows 2 to 26 correspond to one execution of the Play method. The left panel tracks
number, which is one of the parameters of the NewPlay event, that is emitted by the Play transaction. The last column of the left
most panel (in green) shows that in run 4, the value of number is always above 900. The source code states, that the player then
has a 99.9% of winning again. This is also illustrated by the value of won for replay run 4 in the last column of (also in green)
of the right most panel. This shows that each transaction has produced a winner. The tables for number, and won show that a
heat map is sufficient to show the problematic behaviour of what was intended to be a fair lottery. The heat maps are produced
automatically and they can only be produced because we can replay the historic transactions with different block times.
Vitaluck also leaks information through its gas usage. Figure 2 shows the amount of gas used for each of the 27 transactions

of the five replay runs. The colours in the heat map illustrate the correlation with the rightmost panel in Figure 1. Inspecting
the code confirms that if there is a winner, the contract executes more code and therefore consumes more gas. The gas usage is
recorded in the blockchain; hence there should not be any expectations of confidentiality. In the case of Vitaluck the fact that
there has been a winner is completely transparent.
A lottery contract would not be successful if the users did not on occasion win. We can automatically track the balance of

relevant accounts to investigate this. For example, Figure 3 tracks the balance of different users executing the Playmethod of the
contract. The horizontal axis gives the transaction number and the vertical axis the balance (in excess of the minimum balance
of all accounts) of the relevant player. The colours in the graph correspond to replay runs. Each of the 5 different graphs gives
the output of one of the 5 replay runs. The general trend of the balance of a player is to go down, unless he/she wins, when it
goes up significantly. During transactions 1-10 and 13-14 only player 2 is active. Player 6 is only active during transactions 17-
24. Other players are active during other transactions but these have been removed from the graph to avoid clutter. The graph
shows that Player 6 has won once in two replay runs (2 and 3), at transaction 17, where his balance increased considerably,
and continues after his win. Player 2 has abandoned the game at transaction 13. All graphs shown in the case study are easily
produced from the output of the replay runs. We believe that the case study illustrates that being able to replay transactions

7

https://etherscan.io/address/0xef7c7254c290df3d167182356255cdfd8d3b400b#code


number won
0 1 2 3 4 0 1 2 3 4

0 	 	 	 	 	 0 	 	 	 	 	
1 	 	 	 	 	 1 	 	 	 	 	
2 467 583 699 839 955 2 1 1 1 1 1
3 469 585 701 839 955 3 1 1 1 0 1
4 469 587 701 841 957 4 0 1 0 1 1
5 471 587 703 843 957 5 1 0 1 1 1
6 473 589 705 845 959 6 1 1 1 1 1
7 473 589 705 845 961 7 0 0 0 0 1
8 475 591 707 847 961 8 1 1 1 1 1
9 475 591 709 849 963 9 0 0 1 1 1
10 477 593 709 849 963 10 1 1 0 0 1
11 477 593 711 851 965 11 0 0 1 1 1
12 479 595 711 851 965 12 1 1 0 0 1
13 479 595 713 853 967 13 0 0 1 1 1
14 481 597 713 855 969 14 1 1 0 1 1
15 483 597 715 855 969 15 1 0 1 0 1
16 483 599 715 857 971 16 0 1 0 1 1
17 485 601 717 857 971 17 1 1 1 0 1
18 485 601 719 859 973 18 0 0 1 1 1
19 487 603 719 859 973 19 1 1 0 0 1
20 489 603 721 861 975 20 1 0 1 1 1
21 489 605 721 861 975 21 0 1 0 0 1
22 491 605 723 863 977 22 1 0 1 1 1
23 493 607 725 863 979 23 1 1 1 0 1
24 493 607 725 865 979 24 0 0 0 1 1
25 495 609 727 867 981 25 1 1 1 1 1
26 495 611 727 867 981 26 0 1 0 0 1

FIGURE 1 Tracking the outputs of the Vitaluck con-
tract showing how low entropy randomness leads to unfair
behaviour.

gasUsed
0 1 2 3 4

0 942221 942221 942221 942221 942221
1 62314 62314 62314 62314 62314
2 267430 267430 267430 267430 277659
3 162430 162430 162430 127012 172659
4 127012 162430 127012 162430 172659
5 162430 127012 162430 162430 172659
6 162430 162430 162430 162430 172659
7 127012 127012 127012 127012 172659
8 162430 162430 162430 162430 172659
9 142012 142012 177430 177430 187659
10 162430 162430 127012 127012 172659
11 127012 127012 162430 162430 172659
12 162430 162430 127012 127012 172659
13 127012 127012 162430 162430 172659
14 162430 162430 127012 162430 172659
15 177430 142012 177430 142012 187659
16 142012 177430 142012 177430 187659
17 162430 162430 162430 127012 172659
18 127012 127012 162430 162430 172659
19 162430 162430 127012 127012 172659
20 162430 127012 162430 162430 172659
21 127012 162430 127012 127012 172659
22 162430 127012 162430 162430 172659
23 177430 177430 177430 142012 187659
24 142012 142012 142012 177430 187659
25 177430 177430 177430 177430 187659
26 142012 177430 142012 142012 187659

FIGURE 2 Tr";"""date"",""2019-07-23T00:57:14Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2019-07-23T00:57:14Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016) kpathsea version 6.2.2""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2019-07-23T00:57:14Z""
""created"",""2019-07-23T00:57:14Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-07-23T00:57:14Z""
""resourceName"",""1907.09208""
""Author"",""""
""producer"",""pdfTeX-1.40.17""
""pdf:docinfo:producer"",""pdfTeX-1.40.17""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""10"",""0"",""0"",""0"",""0"",""12"",""1"",""2"",""7"",""24"",""4"",""6"",""1"",""2"",""0"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2019-07-23T00:57:14Z""
""Last-Modified"",""2019-07-23T00:57:14Z""
""dcterms:modified"",""2019-07-23T00:57:14Z""
""title"",""""
""Last-Save-Date"",""2019-07-23T00:57:14Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2019-07-23T00:57:14Z""
""meta:save-date"",""2019-07-23T00:57:14Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016) kpathsea version 6.2.2""
""Content-Length"",""514277""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""20""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""3020"",""4599"",""4134"",""3321"",""2316"",""3400"",""4274"",""2317"",""3700"",""2724"",""2738"",""2617"",""1928"",""3420"",""2437"",""3504"",""4415"",""3945"",""3334"",""2448""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-07-23T00:57:14Z""
";https://scholar.google.com/scholar?start=730&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094644-1096;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Design of anonymous endorsement system in hyperledger fabric;S Mazumdar, S Ruj ; IEEE Transactions on Emerging Topics in …, 2019  ieeexplore.ieee.org;;"… well studied area [10], [11], [37], [14], its applicability in cryptocur- rencies and blockchain is being …

Monero, an anonymous cryptocurrency, improves on its existing Cryptonote [43] protocol by using

a new … p(x, ˜z, r) and ?(.) be error, ? : N ? [0, 1]. A probabilistic oracle machine K …";Cité 12 fois;Les 7 versions;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/6245516/6558478/08732411.pdf?casa_token=8VkacJpxKw0AAAAA:COo7ysXptbOZ0VhZ6Be55brhgkqNVJoa_gamGl0yLKJqen6VLzS6epytxszdq6ML2VxmjVY7wjg;"
		Skip to Main Content


		
			
				
				

				

			

		


		
			
				
					
						








	
		
	

	







						

						





























	
	
		
	
	
		
			

		
	

	
	
	



						





	
	
		
			
				IEEE Account

					Change Username/Password
	Update Address


			

			
				Purchase Details

					Payment Options
	Order History
	View Purchased Documents


			

			
				Profile Information

					Communications Preferences
	Profession and Education
	Technical Interests


			

			
				Need Help?

					US & Canada: +1 800 678 4333
	Worldwide:  +1 732 981 0060

					
	Contact & Support


			

		

		
			
				
					
							About IEEE Xplore
	Contact Us
	Help
	Accessibility
	Terms of Use
	Nondiscrimination Policy
	Sitemap
	Privacy & Opting Out of Cookies


						
							A not-for-profit organization, IEEE is the world's largest technical professional organization dedicated to advancing technology for the benefit of humanity.
Š Copyright 2021 IEEE - All rights reserved. Use of this web site signifies your agreement to the terms and conditions.
						

					


					

				

				
			

		

	


	
	


						
						






		
		
		
		
		
		
		
		
		
		
		
		
		
			
				
			
			
			
			
		
		
		
		
		
		

			


			

			
			


		
 		
		
			 

						
						









































	

		
		

		
		
		

		
			
		
		
		

		

		
		


		

		
		
		
		
		
		
		
		
		
		
	
	


















		
		
			
				
					
					
								
					
								
			
				
					
					
								
					
								
			
				
					
						








 



					
					
								
			
				
					
					
								
			
				
					
					
								
					
								
			
				
					
					
								
					
								
			
				
					
					
								
					
								
			
				
					
					
								
					
								
			
				
					
					
								
					
								
			
				
					
					
								
					
								
			
		
	




























		
			
					
			
					
			
					
			
				
					








					
			
					
			
					
			
					
			
					
			
					
			
					
			
		
		
	





	
	
	
	
	
	
	


	
	
	

	

















					

				

			


			
				
			
		

	";"""og:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""twitter:title"",""Design of Anonymous Endorsement System in Hyperledger Fabric""
""twitter:card"",""summary""
""Description"",""Permissioned Blockchain has become quite popular with enterprises forming consortium since it prioritizes trust over privacy. One of the popular platforms for d""
""og:title"",""Design of Anonymous Endorsement System in Hyperledger Fabric""
""resourceName"",""08732411.pdf""
""language"",""en""
""title"",""Design of Anonymous Endorsement System in Hyperledger Fabric | IEEE Journals & Magazine | IEEE Xplore""
""og:description"",""Permissioned Blockchain has become quite popular with enterprises forming consortium since it prioritizes trust over privacy. One of the popular platforms for distributed ledger solution, Hyperledger Fabric, requires a transaction to be endorsed or approved by a group of special members known as endorsers before undergoing validation. To endorse a transaction, an endorser mentions its identity along with the signature so that it can be verified later. However, for certain transactions, difference in opinion may exist among endorsers. Disclosing the identity of an endorser may lead to conflict within the consortium. In such cases, an endorsement policy which not only allows an endorser to support a transaction discreetly, but at the same time takes into account the decision of the majority is preferred. Thus we propose an Anonymous Endorsement System which uses a threshold endorsement policy in order to address the issue. To realize a t-out-of-n endorsement policy, using any of the existing threshold ring signature for our endorsement system would have violated the privacy of endorsers as either the identity or the secret key of the endorsers get revealed to the party who recombines the signature after collecting each signature share. All these factors motivated us to design a new ring signature scheme, called Fabric's Constant-Sized Linkable Ring Signature (FCsLRS) with Transaction-Oriented linkability for hiding identity of the endorsers. We have implemented the signature scheme in Golang and analyzed its security and performance by varying the RSA (Rivest-Shamir-Adleman) modulus size. Feasibility of implementation is supported by experimental analysis. Signature and tag generation time is quite fast and remains constant irrespective of change in message length or endorsement set size for a given RSA modulus value, assuming all the endorsers generates their signature in parallel. Each verifier is required to count and check individual valid ring signature. If the aggregate is above the threshold value, stated by the endorsement policy, then it confirms that the transaction is valid. This increases the verification time depending on the threshold value, but has very little effect on the scalability since generally  <formula xmlns:mml=""""http://www.w3.org/1998/Math/MathML"""" xmlns:xlink=""""http://www.w3.org/1999/xlink""""><tex>$t &lt;&lt; n$</tex></formula> . Lastly, we also discuss the integration of the scheme on v1.2 Hyperledger Fabric.""
""twitter:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-UA-Compatible"",""IE=Edge""
""viewport"",""width=device-width, initial-scale=1.0""
""dc:title"",""Design of Anonymous Endorsement System in Hyperledger Fabric | IEEE Journals & Magazine | IEEE Xplore""
""twitter:description"",""Permissioned Blockchain has become quite popular with enterprises forming consortium since it prioritizes trust over privacy. One of the popular platforms for distributed ledger solution, Hyperledger Fabric, requires a transaction to be endorsed or approved by a group of special members known as endorsers before undergoing validation. To endorse a transaction, an endorser mentions its identity along with the signature so that it can be verified later. However, for certain transactions, difference in opinion may exist among endorsers. Disclosing the identity of an endorser may lead to conflict within the consortium. In such cases, an endorsement policy which not only allows an endorser to support a transaction discreetly, but at the same time takes into account the decision of the majority is preferred. Thus we propose an Anonymous Endorsement System which uses a threshold endorsement policy in order to address the issue. To realize a t-out-of-n endorsement policy, using any of the existing threshold ring signature for our endorsement system would have violated the privacy of endorsers as either the identity or the secret key of the endorsers get revealed to the party who recombines the signature after collecting each signature share. All these factors motivated us to design a new ring signature scheme, called Fabric's Constant-Sized Linkable Ring Signature (FCsLRS) with Transaction-Oriented linkability for hiding identity of the endorsers. We have implemented the signature scheme in Golang and analyzed its security and performance by varying the RSA (Rivest-Shamir-Adleman) modulus size. Feasibility of implementation is supported by experimental analysis. Signature and tag generation time is quite fast and remains constant irrespective of change in message length or endorsement set size for a given RSA modulus value, assuming all the endorsers generates their signature in parallel. Each verifier is required to count and check individual valid ring signature. If the aggregate is above the threshold value, stated by the endorsement policy, then it confirms that the transaction is valid. This increases the verification time depending on the threshold value, but has very little effect on the scalability since generally  <formula xmlns:mml=""""http://www.w3.org/1998/Math/MathML"""" xmlns:xlink=""""http://www.w3.org/1999/xlink""""><tex>$t &lt;&lt; n$</tex></formula> . Lastly, we also discuss the integration of the scheme on v1.2 Hyperledger Fabric.""
""Content-Encoding"",""UTF-8""
""Content-Type-Hint"",""text/html; charset=utf-8""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=910&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094637-1068;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Building a product origins tracking system based on blockchain and PoA consensus protocol;AC An, PTX Diem, T Van Toi… ; … on Advanced Computing …, 2019  ieeexplore.ieee.org;;"… ACM. [2] Baliga, A., 2017. Understanding blockchain consensus models. In Persistent. [3] Burleson,

DK and Estabrook, G., 1999. Oracle SAP Administration. O'Reilly & Associates, Inc. [4]

Casado-Vara, R., González-Briones, A., Prieto, J. and Corchado, JM, 2018 …";Cité 3 fois;Les 2 versions;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/9036008/9044210/09044220.pdf?casa_token=WE9H2B95GooAAAAA:AHnD2Mxw-5qqvvtMULDUFXApF3ApI6BKBYRrQvMAwM84JQplOgA9SAJx3rtHyc9el8cl4EBq140;"
		Skip to Main Content


		
			
				
				

				

			

		


		
			
				
					
						








	
		
	

	







						

						





























	
	
		
	
	
		
			

		
	

	
	
	



						





	
	
		
			
				IEEE Account

					Change Username/Password
	Update Address


			

			
				Purchase Details

					Payment Options
	Order History
	View Purchased Documents


			

			
				Profile Information

					Communications Preferences
	Profession and Education
	Technical Interests


			

			
				Need Help?

					US & Canada: +1 800 678 4333
	Worldwide:  +1 732 981 0060

					
	Contact & Support


			

		

		
			
				
					
							About IEEE Xplore
	Contact Us
	Help
	Accessibility
	Terms of Use
	Nondiscrimination Policy
	Sitemap
	Privacy & Opting Out of Cookies


						
							A not-for-profit organization, IEEE is the world's largest technical professional organization dedicated to advancing technology for the benefit of humanity.
Š Copyright 2021 IEEE - All rights reserved. Use of this web site signifies your agreement to the terms and conditions.
						

					


					

				

				
			

		

	


	
	


						
						






		
		
		
		
		
		
		
		
		
		
		
		
		
			
				
			
			
			
			
		
		
		
		
		
		

			


			

			
			


		
 		
		
			 

						
						









































	

		
		

		
		
		

		
			
		
		
		

		

		
		


		

		
		
		
		
		
		
		
		
		
		
	
	


















		
		
			
				
					
					
								
					
								
			
				
					
					
								
					
								
			
				
					
						








 



					
					
								
			
				
					
					
								
			
				
					
					
								
					
								
			
				
					
					
								
					
								
			
				
					
					
								
					
								
			
				
					
					
								
					
								
			
				
					
					
								
					
								
			
				
					
					
								
					
								
			
		
	




























		
			
					
			
					
			
					
			
				
					








					
			
					
			
					
			
					
			
					
			
					
			
					
			
		
		
	





	
	
	
	
	
	
	


	
	
	

	

















					

				

			


			
				
			
		

	";"""og:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""twitter:title"",""Building a Product Origins Tracking System Based on Blockchain and PoA Consensus Protocol""
""twitter:card"",""summary""
""Description"",""In recent years, the traceability of product origins is strongly concerned, particularly for food products as they directly influence human health. Therefore, t""
""og:title"",""Building a Product Origins Tracking System Based on Blockchain and PoA Consensus Protocol""
""resourceName"",""09044220.pdf""
""language"",""en""
""title"",""Building a Product Origins Tracking System Based on Blockchain and PoA Consensus Protocol | IEEE Conference Publication | IEEE Xplore""
""og:description"",""In recent years, the traceability of product origins is strongly concerned, particularly for food products as they directly influence human health. Therefore, there have been some efforts to develop product origins tracking systems. In this paper, we propose an approach to building a supply chain management system based on the blockchain technology for agriculture product origins tracking. The supply chain model is borrowed from Walmart's and it is implemented based on the Ethereum framework using the PoA (Proof of Authority) consensus algorithm. Our experiment shows that the proposed system not only fulfills the requirements of a product origins tracking but also takes the advantages of the blockchain technology such as the immutability and security of data, the low cost in making the transactions, and so on.""
""twitter:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-UA-Compatible"",""IE=Edge""
""viewport"",""width=device-width, initial-scale=1.0""
""dc:title"",""Building a Product Origins Tracking System Based on Blockchain and PoA Consensus Protocol | IEEE Conference Publication | IEEE Xplore""
""twitter:description"",""In recent years, the traceability of product origins is strongly concerned, particularly for food products as they directly influence human health. Therefore, there have been some efforts to develop product origins tracking systems. In this paper, we propose an approach to building a supply chain management system based on the blockchain technology for agriculture product origins tracking. The supply chain model is borrowed from Walmart's and it is implemented based on the Ethereum framework using the PoA (Proof of Authority) consensus algorithm. Our experiment shows that the proposed system not only fulfills the requirements of a product origins tracking but also takes the advantages of the blockchain technology such as the immutability and security of data, the low cost in making the transactions, and so on.""
""Content-Encoding"",""UTF-8""
""Content-Type-Hint"",""text/html; charset=utf-8""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=880&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094642-1086;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;ICII 2019;J Gordon, V Kraj, T Wang, T Huang, M Shivers… ; computer.org;;"… with Sharding for Internet of Battlefield-Things in NS-3 , 241, Utsab Khakurel (Howard University),

Danda Rawat (Howard University),, and Laurent Njilla (US Air Force Research Lab),Decentralized

Access Control for IoT Data Using Blockchain and Trusted Oracles , 248, Hamda …";Les 2 versions;;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/9048088/9064856/09065137.pdf;"
		
	";"""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""dc:title"",""IEEE Xplore Full-Text PDF:""
""Content-Encoding"",""UTF-8""
""resourceName"",""09065137.pdf""
""language"",""es""
""Content-Length"",""2565""
""title"",""IEEE Xplore Full-Text PDF:""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=900&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094541-655;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[PDF][PDF] This is Not a Game: Blockchain Regulation and Its Application to Video Games;D Qiao ; N. Ill. UL Rev., 2019  HeinOnline;;"… banking account, such as stablecoins, and (b) synthetic derivatives that are (i) determined by

decentralized oracles or smart … A ""decentralized oracle"" is defined as ""service that sends and

verifies real world data from external sources outside of a blockchain and submits such …";Autres articles;;[PDF] heinonline.org;https://heinonline.org/hol-cgi-bin/get_pdf.cgi?handle=hein.journals/niulr40&section=9&casa_token=lihc_-mK3LgAAAAA:8dMc4k9_g_e1Qj2lsfhmKB4oFRaYXG9yhtxoOrOy1CgnK9T4zY0-RCn0vQnUpu4OZWXrs5w;"

 ";"""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""REFRESH"",""1; url=https://heinonline.org/HOL/Page?handle=hein.journals/niulr40&div=9&g_sent=1&casa_token=lihc_-mK3LgAAAAA:8dMc4k9_g_e1Qj2lsfhmKB4oFRaYXG9yhtxoOrOy1CgnK9T4zY0-RCn0vQnUpu4OZWXrs5w""
""Content-Encoding"",""UTF-8""
""resourceName"",""get_pdf.cgi""
""language"",""""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=470&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094576-808;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[CITATION][C] 7 Smart Contracts;C Poncibň, LA DiMatteo;;;null;Autres articles;;null;;;;https://scholar.google.com/scholar?start=620&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094555-716;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[HTML][HTML] ?????????? ????????? ?????????? ??? ?????????? ?????-?????????;?? ????????? ; ??????? ???????????? ???????????????? …, 2019  cyberleninka.ru;;"… The conclusion about the prospects of developing the smart-contract codes that, using blockchain

oracles, will be able to track multivariate scenarios of events in the real economic situation and

make decisions according to a predetermined algorithm is made …";Cité 2 fois;Les 2 versions;[HTML] cyberleninka.ru;https://cyberleninka.ru/article/n/dostizhenie-pravovogo-rezultata-pri-ispolnenii-smart-kontrakta;"
    

    


    
      
        



  [image: Научная статья на тему 'Достижение правового результата при исполнении смарт-контракта'][image: ]



  Достижение правового результата при исполнении смарт-контракта Текст научной статьи по специальности «Компьютерные и информационные науки»

  
    

    
    
      [image: ]CC BY

    
    
      [image: ]20
[image: ]4

    

  


  
    
    

  


	
  
    
      
        
          

        

        
          

        

        

      

    

  

  
  
    
       
         i
         Надоели баннеры? Вы всегда можете 
           отключить рекламу.
       

    

  


	

  
    
			
      Журнал

      Вестник Хабаровского государственного университета экономики и права
      
	      2019

        
  

      

    

    
      Область наук

      	Компьютерные и информационные науки


    

  


  
  
    
      Ключевые слова

      
        
          СМАРТ-КОНТРАКТ / 
        
          ПРАВОВОЙ РЕЗУЛЬТАТ / 
        
          НАДЛЕЖАЩЕЕ ИСПОЛНЕНИЕ / 
        
          АЛГОРИТМ ""ПРАВОВОЙ КВАЛИФИКАЦИИ"" / 
        
          SMART-CONTRACT / 
        
          LEGAL RESULT / 
        
          PROPER EXECUTION / 
        
          ALGORITHM OF ""LEGAL QUALIFICATION""
        
      
    

  

  

  
  
    
      Аннотация научной статьи по компьютерным и информационным наукам, автор научной работы — Коваленко Е.Г.

      В статье рассмотрено кодирование текстовых данных в смарт-контракте как способ фиксации волеизъявления сторон, направленного на совершение сделки. Установлено, что дефицит информации о реальной коммерческой деятельности, осуществляемой вне компьютерной сети, препятствует кодированию в смарт-контракте поэтапного отслеживания исполнения прописанных в нем условий. Сделан вывод о перспективности разработки кодов смарт-контракта, которые с использованием блокчейн-оракулов смогут отслеживать многовариантные сценарии развития событий в реальной экономической ситуации и принимать решения, согласно заранее заданному алгоритму.The article describes the encoding of text data in a smart-contract as a way of fixing the will of the parties aimed at the transactioning. It is established that the lack of information about real commercial activity carried out outside the computer network, prevents coding in the smart-contract of scheduling tracking in the execution of the conditions prescribed in it. The conclusion about the prospects of developing the smart-contract codes that, using blockchain oracles, will be able to track multivariate scenarios of events in the real economic situation and make decisions according to a predetermined algorithm is made.

    

  

  

	
	
		
			
			        
					

				

			        
					

				

			

		

	

  
  
    
       
         i
         Надоели баннеры? Вы всегда можете 
           отключить рекламу.
       

    

  


	

	
    
      Похожие темы научных работ по компьютерным и информационным наукам , автор научной работы — Коваленко Е.Г.

      	Профессиональный библиограф составит и оформит по ГОСТ список литературы для вашей работы
Подбор литературы
	
          
            Правовое регулирование смарт-контрактов во Франции

            2019 / Чуб Д. В.
          
        
	
          
            Правовая конструкция смарт-контракта: юридическая природа и сфера применения

            2019 / Гринь Олег Сергеевич, Гринь Елена Сергеевна, Соловьев Александр Владимирович
          
        
	
          
            Проблемы применения смарт-контрактов в сделках с виртуальным имуществом

            2019 / Богданова Елена Евгеньевна
          
        
	
          
            Смарт-контракты в России: перспективы законодательного регулирования

            2018 / Дядькин Дмитрий Сергеевич, Усольцев Юрий Михайлович, Усольцева Наталья Андреевна
          
        
	
          
            Проблемы правового регулирования использования смарт-контрактов

            2019 / Шайдуллина Венера Камилевна
          
        


    

  


  
    
       iНе можете найти то, что вам нужно? Попробуйте сервис подбора литературы.

    

  


  
    

  


	
  
    
      
        
          

        

        
          

        

      

    

  

  
  
    
       
         i
         Надоели баннеры? Вы всегда можете 
           отключить рекламу.
       

    

  


	

  
  
    
      Текст научной работы на тему «Достижение правового результата при исполнении смарт-контракта»

      
				
        
          

        

				
        
        х™™™ ПРОБЛЕМЫ ЮРИСПРУДЕНЦИИ И ПРАВОПРИМЕНЕНИЯ ™™Х™

         
        
        УДК 34:004 Е.Г. Коваленко, канд. юрид. наук,

         
         
         
        
        доцент кафедры трудового и предпринимательского права Хабаровского государственного университета экономики и права

         
         
         
        
        ДОСТИЖЕНИЕ ПРАВОВОГО РЕЗУЛЬТАТА ПРИ ИСПОЛНЕНИИ

         
         
         
        
        СМАРТ-КОНТРАКТА

         
         
         
        
        В статье рассмотрено кодирование текстовых данных в смарт-контракте как способ фиксации волеизъявления сторон, направленного на совершение сделки. Установлено, что дефицит информации о реальной коммерческой деятельности, осуществляемой вне компьютерной сети, препятствует кодированию в смарт-контракте поэтапного отслеживания исполнения прописанных в нем условий. Сделан вывод о перспективности разработки кодов смарт-контракта, которые с использованием блокчейн-оракулов смогут отслеживать многовариантные сценарии развития событий в реальной экономической ситуации и принимать решения, согласно заранее заданному алгоритму.

         
         
         
        
        Ключевые слова: смарт-контракт, правовой результат, надлежащее исполнение, алгоритм «правовой квалификации».

         
         
         
        
        The article describes the encoding of text data in a smart-contract as a way of fixing the will of the parties aimed at the transactioning. It is established that the lack of information about real commercial activity carried out outside the computer network, prevents coding in the smart-contract of scheduling tracking in the execution of the conditions prescribed in it. The conclusion about the prospects of developing the smart-contract codes that, using blockchain oracles, will be able to track multivariate scenarios of events in the real economic situation and make decisions according to a predetermined algorithm is made.

         
         
         
        
        Keywords: smart-contract, legal result, proper execution, algorithm of ""legal qualification "".

         
         
         
        
        Развитие технологии блокчейн (blockchain), использование смарт-контрактов (smart-contracts) позволяют говорить о необходимости проведения исследований на стыке знаний особого направления программирования и опыта правоприменения. В настоящее время еще недостаточно исследований, позволяющих определить систему координат, в рамках которых будет развиваться технология блокчейн, в том числе применение смарт-контрактов на основе платформы Etherium и Bitcoin. Актуальность исследования обусловлена тем обстоятельством, что использование современных технологий не имеет границ, а их правовое сопровождение следует с определен-

         
         
         
        
        ным временным отрывом практически во всех странах.

         
         
         
        
        Научные работы, посвященные вопросам создания и использования смарт-контрактов, достаточно разнообразны и затрагивают как технические, экономические, так и юридические аспекты этой технологии, работающей на основе блок-чейна. Ученые предлагают различные определения смарт-контракта. Так, Е.Г. Дубицкая определяет смарт-контракт как «специальный протокол, предназначенный для сторон, которые могут участвовать в переговорах, проверять их условия, реализовывать договоренности и контролировать выполнение контракта» [1]. Имеются и другие определения, отмеча-

         
         
         
        
        ющие автоматическое исполнение условий смарт-контракта, проведение транзакций и обмен активами между сторонами без участия третьих лиц, надежность и необратимость транзакций.

         
         
         
        
        В работах, затрагивающих кодирование смарт-контрактов, освещаются вопросы о языке программирования, вычислительной мощности в компьютерной сети, проверке кода смарт-контракта, структуры, дизайна пользовательского интерфейса, его интеграции с электронным «кошельком» и т.д. В исследованиях экономистов отмечаются экономические затраты, выгоды и риски от применения смарт-контракта, использование различных криптографических валют, отражение транзакций в бухгалтерском учете, налогообложение.

         
         
         
        
        Рассматривая смарт-контракт с позиций гражданско-правового подхода, можно говорить о кодировании текстовых данных как о способе фиксации волеизъявления сторон, направленного на совершение сделки.

         
         
         
        
        В исследовании К.П. Татаркиной, посвященном форме сделок, отмечается, что «волеизъявление лица приведет к наступлению желаемых правовых последствий при условии, что воля выражена в форме, которая обеспечивает ее восприятие адресатом», а «законом не запрещается совершение сделок легально нерегламенти-рованными способами» [2, с. 10].

         
         
           iНе можете найти то, что вам нужно? Попробуйте сервис подбора литературы.

         
         
        
        В.В. Епифанова в своей работе также подчеркивает возможность свободного выбора формы сделки, «в зависимости от содержания (существа оформляемого гражданского правоотношения)» [3, с. 9].

         
         
         
        
        Как один из вариантов оформления договоров допустимо использовать кодирование информации в смарт-контракте. По мнению А.И. Савельева, смарт-контракт может рассматриваться в каче-

         
         
         
        
        стве гражданско-правового договора, если «содержанием программного кода является совершение операций, которые представляют собой автоматизированный эквивалент действий сторон, которые могут выступать предметом гражданско-правового договора» [4, с. 44].

         
         
         
        
        Следует учесть, что применение блок-чейна определяет невозможность внесения изменений в строго установленную последовательность транзакций смарт-контракта. При кодировании определенного алгоритма, предлагаемого заказчиком и осуществляемого разработчиком смарт-контракта, определяется задача, которую необходимо решить заказчику с использованием смарт-контракта. Если эта задача лежит в плоскости гражданских правоотношений, то уместно говорить о достижении правового результата, юридических последствий сделки.

         
         
         
        
        В отличие от обычного гражданско-правового договора, в смарт-контракте прописываются не только условия его заключения (намерения сторон сделки), но и дальнейшая последовательность их действий по исполнению смарт-контракта.

         
         
         
        
        В связи с применением смарт-контрактов для реализации различных шаблонов гражданско-правовых договоров, правовой результат будет отличаться. По договору перевозки груза - это доставка груза управомоченному на его получение лицу (грузополучателю), по договору поставки - переход права собственности на имущество, по договору подряда - выполнение работ и передача их результата заказчику и т.д.

         
         
         
        
        Установление факта достижения правового результата связано с объемом полученной компьютерной программой информации. Возможность доступа к внешней информации позволяет получить данные об исполнении условий смарт-

         
         
         
        
        контракта и выполнить обязательства по его оплате путем автоматического перечисления платежа за товары, работы, услуги в криптовалюте. Получение, анализ и применение внешней информации возможны при совершенствовании способов идентификации объектов внешнего мира и успешном решении других технических задач. Для решения проблемы коммуникации смарт-контрактов с реальным миром и организации процесса интерпретации полученных данных для использования компьютерной программой применяют специальные версии инфраструктурных алгоритмов блокчейн-оракулов. Полученные вне компьютерной сети данные об исполнении сделки блок-чейн-оракулы преобразуют в формат, адаптированный для восприятия компьютерной программой. На практике дефицит информации об исполнении смарт-контракта может зависеть от сбоев в фиксации, передаче и получении компьютерной программой информации о реальной деятельности стороны договора вне компьютерной сети. Источники, которые предоставляют необходимую информацию о реальном исполнении смарт-контракта блокчейн-оракулу, должны иметь «электронную начинку» для обеспечения точности и надежности исходных данных. Блокчейн-оракулы могут использовать данные, поступающие от различных приборов и устройств. Следует обратить внимание на применение датчиков, RFID-меток, камер видеофиксации, сканеров различных объектов.

         
         
         
        
        Интересный опыт использования современных технологий, в том числе для получения данных об исполнении договорных обязательств, имеется в сфере логистики. Датчики, сенсорные метки позволяют осуществлять операторам логистики мониторинг информации об усло-

         
         
         
        
        виях перевозки товара, такой как местоположение, удар, вибрация, наклон, поломка, температура, давление, и влажность [5, с. 71].

         
         
         
        
        Стандартизация условий договоров перевозки, поставки и других для их кодирования при подготовке смарт-контрактов должна осуществляться с учетом ряда особенностей. В частности, если в рамках обычного договора поставки требование о взыскании неустойки в определенном диапазоне может заявлять как поставщик, так и покупатель, то с использованием смарт-контракта компьютерная программа не допустит возникновения таких оснований начисления неустойки, как просрочка оплаты товара поставщиком, так как средства будут списаны и перечислены покупателю автоматически. В будущем особый подход потребуется при описании алгоритма зачета встречных однородных требований, который практически не используется как вариант оплаты при кодировании смарт-контрактов, хотя в практике решения вопросов оплаты по обычным гражданско-правовым договорам контрагенты используют такие расчеты.

         
         
         
        
        Покупатель может включить в условия смарт-контракта такие основания взыскания неустойки в виде пени, как прострочка поставки товара. Начисление неустойки в виде штрафа за поставленный товар, к которому имеются претензии по количеству, ассортименту, качеству, будет зависеть от возможности зафиксировать и передать информацию для учета ее компьютерной программой о низком качестве товара или о поставке его в меньшем количестве.

         
         
         
        
        В случае заключения смешанного договора, содержащего в себе элементы договора поставки и договора подряда, надлежащим исполнением будет являться

         
         
         
        
        совершение поставщиком нескольких взаимосвязанных последовательных действий. Оценка надлежащего исполнения обязательств специалистом при поставке оборудования, его монтаже и испытании на сегодняшний день не может быть осуществлена компьютерной программой.

         
         
         
        
        Более сложной представляется задача технической реализации кодирования алгоритма смарт-контракта по шаблону договора подряда (субподряда). Формирование сметы, система оплаты с поэтапными, авансовыми платежами, намного затрудняют описание в виде компьютерного алгоритма приведенного процесса расчетов.

         
         
           iНе можете найти то, что вам нужно? Попробуйте сервис подбора литературы.

         
         
        
        Определенным препятствием автоматизации отслеживания выполнения строительных, монтажных работ является длительность процесса строительства и отсутствие технической возможности получать в автоматическом режиме информацию о качестве строительства, применении заявленных материалов, соблюдении технологии строительства, градостроительных норм и правил, экологических требований. Еще недостаточно развиты модульное домостроение, выполнение конструктивных элементов зданий с использованием строительных 3D-принтеров и другие современные технологии, которые в будущем могут облегчить получение данных о выполнении условий договора строительного подряда, оформленного в виде смарт-контракта.

         
         
         
        
        В настоящее время практически невозможно автоматически получать информацию о ходе монтажа, строительства и с использованием блокчейн-оракулов адаптировать эти данные для восприятия компьютерной программой. Кроме того, комплекс возможных ситуаций в ходе выполнения монтажа и строительства связанных с возникновением необходи-

         
         
         
        
        мости выполнения дополнительных работ, влиянием неблагоприятных погодных условий на сроки сдачи объекта и т.д. предусмотреть практически невозможно. Внешние обстоятельства, влияющие на исполнение условий договора подряда, настолько разнообразны, что в ближайшее время автоматизировать передачу данных о реальном выполнении различных этапов строительных работ для установления исполнения смарт-контракта вряд ли удастся.

         
         
         
        
        В самом общем виде можно констатировать, что достаточная информация в случае обработки ее компьютерной программой может служить основанием для вывода о надлежащем исполнении условий смарт-контракта.

         
         
         
        
        Для выявления нарушений условий смарт-контракта имеет значение разработка стандартных алгоритмов динамики исполнения смарт-контракта, включающих последовательность действий и сроки. В то же время нужно обеспечить получение и передачу информации об отклонении от заданного алгоритма, то есть о юридических фактах, признаваемых нарушениями договорных обязательств и являющихся основанием для применения санкций как правовых последствий нарушений.

         
         
         
        
        За основу следует принять практику исполнения аналогичных гражданско-правовых договоров в части, которая реально может быть включена в разрабатываемый код. Наиболее приемлемым следует признать включение в смарт-контракт элементов ответственности в виде взыскания договорной неустойки в виде штрафа или пени.

         
         
         
        
        Если проводить аналогию с работой юриста, то компьютерная программа должна распознавать юридические факты и по запрограммированному алгоритму

         
         
         
        
        осуществлять «правовую квалификацию» надлежащего исполнения условий смарт-контракта или нарушения его условий.

         
         
         
        
        Типичные нарушения различных видов договоров известны юристам, поэтому в алгоритм смарт-контракта можно включить возможные варианты нарушений условий смарт-контракта. Для программирования адекватных мер, применяемых за нарушение условий смарт-контракта, следует прописывать стандартные сценарии. Если произошло нарушение срока поставки, то смарт-контракт должен автоматически запускать запрограммированное начисление пеней, если товар поступил без сопроводительных документов, ненадлежащего качества, то автоматически начислять штраф. Пока такой алгоритм можно установить для простых в исполнении смарт-контрактов, выполняемых одним действием, нарушения которого маловари-антны, и их «правовая квалификация» может быть автоматической.

         
         
         
        
        Следовательно, элементы «правовой квалификации» с использованием стандартных сценариев допустимо Đ";"""citation_keywords"",""СМАРТ-КОНТРАКТ, ПРАВОВОЙ РЕЗУЛЬТАТ, НАДЛЕЖАЩЕЕ ИСПОЛНЕНИЕ, АЛГОРИТМ """"ПРАВОВОЙ КВАЛИФИКАЦИИ"""", SMART-CONTRACT, LEGAL RESULT, PROPER EXECUTION, ALGORITHM OF """"LEGAL QUALIFICATION""""""
""og:image"",""https://cyberleninka.ru/article/n/dostizhenie-pravovogo-rezultata-pri-ispolnenii-smart-kontrakta/og""
""og:image:width"",""1074""
""twitter:card"",""summary_large_image""
""eprints.ispublished"",""pub""
""og:site_name"",""КиберЛенинка""
""keywords"",""научная статья бесплатно на тему Достижение правового результата при исполнении смарт-контракта текст научной работы по компьютерным и информационным наукам из научного журнала Вестник Хабаровского государственного университета экономики и права. СМАРТ-КОНТРАКТ, ПРАВОВОЙ РЕЗУЛЬТАТ, НАДЛЕЖАЩЕЕ ИСПОЛНЕНИЕ, АЛГОРИТМ """"ПРАВОВОЙ КВАЛИФИКАЦИИ"""", SMART-CONTRACT, LEGAL RESULT, PROPER EXECUTION, ALGORITHM OF """"LEGAL QUALIFICATION""""""
""eprints.pagerange"",""114-118""
""citation_journal_title"",""Вестник Хабаровского государственного университета экономики и права""
""eprints.publication"",""Вестник Хабаровского государственного университета экономики и права""
""language"",""ru""
""og:description"",""В статье рассмотрено кодирование текстовых данных в смарт-контракте как способ фиксации волеизъявления сторон, направленного на совершение сделки. Установлено, что дефицит информации о реальной коммерческой деятельности, осуществляемой вне компьютерной сети, препятствует кодированию в смарт-контракте поэтапного отслеживания исполнения прописанных в нем условий. Сделан вывод о перспективности разработки кодов смарт-контракта, которые с использованием блокчейн-оракулов смогут отслеживать многовариантные сценарии развития событий в реальной экономической ситуации и принимать решения, согласно заранее заданному алгоритму.The article describes the encoding of text data in a smart-contract as a way of fixing the will of the parties aimed at the transactioning. It is established that the lack of information about real commercial activity carried out outside the computer network, prevents coding in the smart-contract of scheduling tracking in the execution of the conditions prescribed in it. The conclusion about the prospects of developing the smart-contract codes that, using blockchain oracles, will be able to track multivariate scenarios of events in the real economic situation and make decisions according to a predetermined algorithm is made.""
""eprints.full_text_status"",""public""
""citation_issn"",""2618-9526""
""dc:title"",""Достижение правового результата при исполнении смарт-контракта – тема научной статьи по компьютерным и информационным наукам читайте бесплатно текст научно-исследовательской работы в электронной библиотеке КиберЛенинка""
""eprints.place_of_pub"",""Россия, Хабаровск""
""Content-Encoding"",""UTF-8""
""citation_pdf_url"",""https://cyberleninka.ru/article/n/dostizhenie-pravovogo-rezultata-pri-ispolnenii-smart-kontrakta/pdf""
""robots"",""NOODP"",""noyaca""
""eprints.volume"",""""
""eprints.citation"",""Коваленко Е.Г. Достижение правового результата при исполнении смарт-контракта // Вестник Хабаровского государственного университета экономики и права. 2019. Выпуск номер 3 (101), С.114-118""
""eprints.number"",""3 (101)""
""citation_author"",""Коваленко Е.Г.""
""resourceName"",""dostizhenie-pravovogo-rezultata-pri-ispolnenii-smart-kontrakta""
""citation_abstract_html_url"",""https://cyberleninka.ru/article/n/dostizhenie-pravovogo-rezultata-pri-ispolnenii-smart-kontrakta""
""citation_issue"",""3 (101)""
""eprints.abstract"",""В статье рассмотрено кодирование текстовых данных в смарт-контракте как способ фиксации волеизъявления сторон, направленного на совершение сделки. Установлено, что дефицит информации о реальной коммерческой деятельности, осуществляемой вне компьютерной сети, препятствует кодированию в смарт-контракте поэтапного отслеживания исполнения прописанных в нем условий. Сделан вывод о перспективности разработки кодов смарт-контракта, которые с использованием блокчейн-оракулов смогут отслеживать многовариантные сценарии развития событий в реальной экономической ситуации и принимать решения, согласно заранее заданному алгоритму.The article describes the encoding of text data in a smart-contract as a way of fixing the will of the parties aimed at the transactioning. It is established that the lack of information about real commercial activity carried out outside the computer network, prevents coding in the smart-contract of scheduling tracking in the execution of the conditions prescribed in it. The conclusion about the prospects of developing the smart-contract codes that, using blockchain oracles, will be able to track multivariate scenarios of events in the real economic situation and make decisions according to a predetermined algorithm is made.""
""citation_volume"",""""
""format-detection"",""telephone=no""
""citation_publication_date"",""2019""
""citation_title"",""Достижение правового результата при исполнении смарт-контракта""
""eprints.date"",""2019""
""citation_publisher"",""Федеральное государственное бюджетное образовательное учреждение высшего образования «Хабаровский государственный университет экономики и права»""
""eprints.type"",""article""
""description"",""В статье рассмотрено кодирование текстовых данных в смарт-контракте как способ фиксации волеизъявления сторон, направленного на совершение сделки. Установлено, что дефицит информации о реальной коммерческой деятельности, осуществляемой вне компьютерной сети, препятствует кодированию в смарт-контракте поэтапного отслеживания исполнения прописанных в нем условий. Сделан вывод о перспективности разработки кодов смарт-контракта, которые с использованием блокчейн-оракулов смогут отслеживать многовариантные сценарии развития событий в реальной экономической ситуации и принимать решения, согласно заранее заданному алгоритму.The article describes the encoding of text data in a smart-contract as a way of fixing the will of the parties aimed at the transactioning. It is established that the lack of information about real commercial activity carried out outside the computer network, prevents coding in the smart-contract of scheduling tracking in the execution of the conditions prescribed in it. The conclusion about the prospects of developing the smart-contract codes that, using blockchain oracles, will be able to track multivariate scenarios of events in the real economic situation and make decisions according to a predetermined algorithm is made.""
""title"",""Достижение правового результата при исполнении смарт-контракта – тема научной статьи по компьютерным и информационным наукам читайте бесплатно текст научно-исследовательской работы в электронной библиотеке КиберЛенинка""
""eprints.document_url"",""https://cyberleninka.ru/article/n/dostizhenie-pravovogo-rezultata-pri-ispolnenii-smart-kontrakta""
""twitter:site"",""@CyberLeninka""
""citation_fulltext_html_url"",""https://cyberleninka.ru/article/n/dostizhenie-pravovogo-rezultata-pri-ispolnenii-smart-kontrakta""
""eprints.keywords"",""СМАРТ-КОНТРАКТ, ПРАВОВОЙ РЕЗУЛЬТАТ, НАДЛЕЖАЩЕЕ ИСПОЛНЕНИЕ, АЛГОРИТМ """"ПРАВОВОЙ КВАЛИФИКАЦИИ"""", SMART-CONTRACT, LEGAL RESULT, PROPER EXECUTION, ALGORITHM OF """"LEGAL QUALIFICATION""""""
""Content-Type-Hint"",""text/html; charset=utf-8""
""eprints.publisher"",""Федеральное государственное бюджетное образовательное учреждение высшего образования «Хабаровский государственный университет экономики и права»""
""Content-Type"",""text/html; charset=UTF-8""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""og:type"",""article""
""eprints.title"",""Достижение правового результата при исполнении смарт-контракта""
""og:title"",""Достижение правового результата при исполнении смарт-контракта""
""og:image:height"",""480""
""eprints.creators_name"",""Коваленко Е.Г.""
""eprints.date_type"",""published""
""viewport"",""width=device-width, initial-scale=1""
""apple-mobile-web-app-capable"",""yes""
""og:url"",""https://cyberleninka.ru/article/n/dostizhenie-pravovogo-rezultata-pri-ispolnenii-smart-kontrakta""
""eprints.metadata_visibility"",""show""
""eprints.refereed"",""TRUE""
""eprints.issn"",""2618-9526""
";https://scholar.google.com/scholar?start=530&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094541-651;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[PDF][PDF] Appearance of Blockchain Bonds: An Assessment of Blockchain Impact on Bond Issuance Process in European Debt Capital Market;P Sandner, M Hillebrand ;2019 frankfurtuniversity.de;;"… Page 3. II Abstract Beyond cryptocurrency, blockchain technology could be considered as one of

the most revolutionary driving force to reshape the current financial ecosystem. Focused mainly

on the traditional securities issuance in Europe, traditional bond issuance …";Autres articles;Version HTML;[PDF] frankfurt-university.de;https://www.frankfurt-university.de/fileadmin/standard/Sonstiges/Master_Thesis__Wanli_Chen_Qianxia_Wang.pdf;"
 
 

 
 
 
 
 
 

Master’s Thesis 
 

 
Appearance of Blockchain Bonds:  

An Assessment of Blockchain Impact on Bond 
Issuance Process in European Debt Capital Market 

 
 

 
 
 
 

Supervised by  
Prof. Dr. Philipp Sandner  

(Frankfurt School Blockchain Center) 
 

Dr. Martin Hillebrand 
(European Stability Mechanism) 

 
 
 

 
Submitted by 

Wanli Chen 8368527 
Qianxia Wang 8350685 

 
 
 
 

September 2019 



 I 

Acknowledgements  
 
Throughout the writing of the dissertation, we have received a great amount of support 
and guidance. We would first like to thank our supervisors, Prof. Dr. Philipp Sandner and 
Dr. Martin Hillebrand, who have provided us with continued tutoring, encouragement, 
and guidance over the course of this dissertation. It has been a pleasure working with and 
learning from you. 

We would like to acknowledge our colleagues from previous internships at UniCredit 
Bank AG and Deutsche Bank AG for their wonderful collaboration. An incredible thank 
you goes out to Mr. Bernd Loder, whose observation and extended network motivated us 
each and every day and provided us with continuous inspiration. 

A great thank you to all the experienced professionals that participated in our surveys. 
Your valuable insights have guided us in the right direction and tremendously contributed 
to the outcome of our research study. 

Finally, we would like to thank our family and friends for their unconditional supports 
and patience through the journey of the master’s degree. Without you all, we won’t have 
made this far. 

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 



 II 

Abstract 
 

Beyond cryptocurrency, blockchain technology could be considered as one of the 

most revolutionary driving force to reshape the current financial ecosystem. Focused 

mainly on the traditional securities issuance in Europe, traditional bond issuance 

process has been dependant on cumbersome manual workflows, intensive paperwork 

and involvement of a large number of intermediaries for decades. This thesis 

provides an in-depth analysis of current inefficiencies in the entire bond issuance 

value chain in Europe and how blockchain technology could be used to address these 

issues at stake on top of the existing conventional solutions. In particular, we aim to 

assess the overall impact from the perspectives of both practical implementation and 

market participants and thereby employ an approach of combing qualitative analysis 

with market observation and expert surveys. With the application of blockchain 

technology, bond issuance process could be driven towards an innovative path in 

both public and private sector, achieved by enabling smart contract-led automation, 

reduction of intermediaries, automated asset-servicing through a distributed ledger 

and 24/7 electronic audit trail along with the various phases. Given the potential 

streamlined process and workflows, blockchain technology could be a significant 

endeavour that digitalizes bond issuance process, integrates European debt capital 

markets, and shifts major market participants' role in the value chain. 

 

 

 

 

 

 

 

Keywords: Bond issuance, Blockchain, Distributed ledger technology, European 

debt capital market, Market inefficiencies, Post-trade process, Smart contract, 

Tokenization 



 III 

Table of Content 

Acknowledgements................................................................................................... I 
Abstract .................................................................................................................... II 
Table of Content .................................................................................................... III 
List of Tables ........................................................................................................... V 

List of Figures ........................................................................................................ VI 
List of Appendices ................................................................................................. VI 
List of Abbreviations ........................................................................................... VII 
1  Introduction .......................................................................................................... 4 
1.1 Blockchain as a Solution to the inefficiencies and Fragmentation of EU Debt 
Capital Market ..................................................................................................................... 4 
1.2 Identifying Research Questions and Study Structures ........................................... 5 

2  Literature Review and Theoretical Background .............................................. 6 
2.1 Overview of Eurobond Issuance ............................................................................... 6 
2.1.1 Key Participants and Their Roles ...................................................................................... 6 
2.1.2 Issuing a bond: pre-issuance and post-trade process ..................................................... 10 
2.2 Blockchain Technology ............................................................................................ 15 
2.2.1 Types of Blockchains ......................................................................................................... 16 
2.2.2 Smart Contract .................................................................................................................. 19 
2.2.3 Ethereum ............................................................................................................................ 20 
2.2.4 Tokenization – Security Tokens, Utility Tokens and Payment Tokens ........................ 22 
3  Data and Methodology....................................................................................... 26 
3.1 Market Observations from Current Initiatives ..................................................... 26 
3.1.1 Current Initiatives ............................................................................................................. 27 
3.1.2 Other Initiatives to Issue Bonds on Different DLT Framework ................................... 31 
3.2 Expert Surveys and Interviews ............................................................................... 35 
3.2.1 Criteria of Selection and Interviewees Profiles ............................................................... 35 
3.2.2 Survey Methodology .......................................................................................................... 35 
3.2.3 Questions Design ................................................................................................................ 36 
3.2.4 Data Collection and Analysis ............................................................................................ 37 
4  Results and Discussions ..................................................................................... 41 
4.1 Existing Inefficiencies in the Debt Capital Market ............................................... 41 
4.1.1 Inefficiencies in Pre-issuance Process .............................................................................. 41 
4.1.2 Inefficiencies in the Post-trade Landscape ...................................................................... 45 
4.2 Current Conventional Solutions under Development .......................................... 47 
4.2.1 Solutions for the Pre-issuance Process ............................................................................ 47 
4.2.2 Solutions for the Post-trade Process ................................................................................ 49 
4.3 Blockchain Technology Impact on Debt Issuance Process ................................... 52 
4.3.1 Blockchain Bonds .............................................................................................................. 52 
4.3.2 Potential Added-value from Blockchain ......................................................................... 55 
4.3.3 Changing Roles of Market Participants .......................................................................... 62 
4.4 Challenges and Obstacles ........................................................................................ 64 
4.4.1 Limits of Adoption ............................................................................................................. 64 
4.4.2 Regulatory and Legal Issues ............................................................................................. 67 
5  Conclusion, Limitations and Further Research .............................................. 69 



 IV 

5.1 Conclusion and Implications ................................................................................... 69 
5.2 Limitations and Further Research ......................................................................... 72 

6  References ........................................................................................................... 73 

7  Appendices .......................................................................................................... 78 
 

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 



 V 

List of Tables 

Table 1 Key Participants in the Pre-issuance Process and Their Main Roles............ 6 

Table 2 Key Participants in the Post-trade Process and Their Main Roles................ 7 

Table 3 List of Required Documents in a Bond Issuance ........................................ 12 

Table 4 Governance Models for Alternative Permissioned Blockchain Designs .... 18 

Table 5 Scope of Ethereum Application Area in the Financial Markets ................. 21 

Table 6 Key Benefits of Tokenization ..................................................................... 22 

Table 7 Examples of STOs in Europe ...................................................................... 24 

Table 8 New Blockchain Applications in the Debt Market ..................................... 31 

Table 9 Type of Survey Participants ........................................................................ 40 

Table 10 Technology Challenges in the Permissioned Blockchain ......................... 65 

  



 VI 

List of Figures 

Figure 1 Paradigm Timeline for a Plain Vanilla Bond by a Debut Issuer ............... 10 

Figure 2 Closing Procedures Delivery versus Payment ........................................... 14 

Figure 3 League Tables of US and EMEA Investment Grade Corporate Bonds .... 29 

Figure 4 Euro Denominated Debt Securities Issuance in the Eurozone .................. 30 

Figure 5 Importance of a Standardized Platform to Improve Documentation 
Workflow in the Pre-issuance Process ..................................................................... 38 

Figure 6 Probability of Substantial Intermediaries’ Function Reduction ................ 39 

Figure 7 Likelihood of Bond Issuance on Blockchain in a Decade ......................... 40 

Figure 8 Three Layers in the Post-trade Landscape ................................................. 45 

Figure 9 EDDI Standardized Toolkit for Pre-issuance ............................................ 48 

Figure 10 T2S Delivery versus Payment (DvP) Basis ............................................. 49 

Figure 11 EDDI End-to-end Channel ...................................................................... 51 

Figure 12 Potential Blockchain Design for Digitalised Bond Issuance ................... 54 

Figure 13 Potential Model for Due Diligence/KYC Process ................................... 58 

 

 
 
 
 
 
 
 
 
 
 

List of Appendices  

Appendix 1 Survey Design and Response Summary............................................... 78 

Appendix 2 Weighted Average Results of Rated Questions in the Survey ............. 92 

Appendix 3 Survey Participants’ Profiles ................................................................ 93 

  



 VII 

List of Abbreviations 

AML Anti-Money Laundry 

API  Application Programming Interface 

BaFin Bundesanstalt fĂźr Finanzdienstleistun gsaufsicht (German Federal 
Financial Supervisory Authority) 

CBDC Central Bank Digital Currency 

CCP Central Counterparties 

CSD Central Securities Depository  

CSDR Central Securities Depository Regulation 

DCM Debt Capital Market  

DLT  Distributed Ledger Technology 

DvP Delivery versus Payment 

EACH European Association of CCP Clearing Houses 

ECB European Central Bank 

ECSDA European Central Securities Depositories Association 

EDDI  European Distribution of Debt Instruments Initiative 

EMEA Europe, Middle East and Africa 

EMIR European Market Infrastructure Regulation 

EPTF European Post-Trade Forum 

EU European Union 

GDPR General Data Protection Regulation 

ITIN  International Token Identification Number 

ITP Independent Third Party 

KYC  Know Your Customer 

LML Legal Mark-up Language 

MiFID Markets in Financial Instruments Directive 

MiFIR Markets in Financial Instruments Regulation 

OTC Over-the-counter 

PFMI Principals for Financial Market Infrastructures 

STO Security Token Offering  



 VIII 

SME Small and Medium-sized Enterprises 

T2S Target2-securities 



 4 

 
1 Introduction 
1.1 Blockchain as a Solution to the inefficiencies and Fragmentation of EU 

Debt Capital Market 

In the last years, blockchain technology (also referred to as distributed ledgers 

technology) has been in the spotlight and touted as a panacea that will revolutionize 

banking and capital markets. One of the most likely areas for disruption is the 

traditional debt capital markets, where the old-school business could be advanced 

and transformed into a new era. The next frontier is the “primary” side of the banks’ 

lucrative debt underwriting businesses, where the often-knotty work of arranging 

issuers, investors, agents, and various parties could become much faster and more 

efficient.  

Although some senior bankers are dismissive, sneering at efforts to graft technology 

on to what is an essentially human-driven business, projects under the streamer of 

“blockchain bonds” are proliferating across the industry. Project Mars, for example, 

was formed by a consortium of six bulge bracket banks in 2018 to improve pricing 

technology and maintain market influence. However, in addition to transforming the 

bond issuance process, blockchain technology has more implications on the overall 

bond value chain. 

After a bond is first issued, the vintage capital distributing channels existing in the 

past decades have also raised concerns regarding fragmentation issues in European 

capital markets. Back in 2001, “Giovannini barriers” were identified, which describe 

the 15 main obstacles to efficient cross-border clearing and settlement in Europe. 

Later in 2017, a new review of the post-trade barriers was carried out by the European 

Post-Trade Forum (EPTF), which provide a detailed overview of the defined post-

trade priorities to be tackled in order to achieve more harmonization in the EU. Lately, 

in May 2019, ECB launched a potential Eurosystem initiative called EDDI and 

published a market consultation stating that “exiting ecosystem results in 

considerable heterogeneity and complexity for market actors, including the end-

investors”.  

Currently, how post-trade process of debt instruments including clearing, settlement, 

and future payment can be improved by blockchain technology can be found in rather 

extensive research dissertation and white papers, while the utility and impact on pre-



 5 

issuance phase remain vague and controversy. With concerns being raised by 

financial intermediaries regarding their role change along with technology adoption, 

we drove our research to unveil the seemingly abstract concept of distributed ledger 

technology and elaborate its influence on the entire bond issuance value chain and 

on a higher level, how it would contribute to a more efficient and harmonized EU 

capital market. 

1.2 Identifying Research Questions and Study Structures 

The purpose of this paper is to perform an in-depth analysis on i) blockchain 

technology as a potential solution to current inefficiencies in the process of bond 

issuance and ii) an evaluation of market perception regarding potential blockchain 

implementations through key market participants for a practical view of their 

expectations of how technology can drive the role change. Accordingly, we 

implement an approach combining the qualitative analysis with market evidence 

from i) market observations and ii) expert surveys. 

The paper is structured as follows. Section 2 first reviews the relevant literature on 

traditional Eurobond issuance practice, where concrete steps and parties involved in 

both pre-issuance phase as well as post-trade phase are illustrated. In addition, we 

demonstrate the essence of associated blockchain technologies, laying a foundation 

for further discussion on the main research questions. Section 3 depicts the 

qualitative methods for the exploration of the research model. Qualitative data from 

the approach of market observation are first presented, followed by an expert survey 

design aiming to collect first-hand empirical data to address both research questions. 

Specifically, current initiatives to issue bonds using blockchain technologies are 

outlined as market evidence. Together with our research results, the qualitative data 

are integrated into the expert survey questions design, which contributes to the 

unification of the research methodology. Section 4 then reports and discusses on the 

results from both market observation and expert surveys, including existing 

inefficiencies and current solutions in both pre-issuance process and post-trade 

landscape, blockchain impact and value-add on the value chain, as well as challenge 

and obstacles of the technology adoption - all addressing to the 2 main research 

questions. Subsequently, section 5 integrates the findings, highlights both the 

theoretical and practical implications, and reveals the research limitation along with 

further research direction.  



 6 

2 Literature Review and Theoretical Background  
2.1 Overview of Eurobond Issuance  

We concentrate on the parties and process involved in the issue of a Eurobond, which 

is among the most common form of debt securities and something of a paradigm for 

debt securities issued in the London markets. A Eurobond is a bond denominated in 

a globally recognized currency, which is not the currency of the country in which the 

bond is issued (Adams, 2016). The flourish of the Euromarkets was first due to 

raising restrictions in the domestic markets in the 1970s in the US. Later on, 

Euromarkets serve as a means to globalize the world’s capital markets, providing an 

issuer with access to a much greater and often cheaper source of funding than in its 

domestic market alone. 

2.1.1 Key Participants and Their Roles  

In order to generate a clear overlook of the market participants and their relevant 

roles, we have divided the descriptions into two parts: table 1 provides key 

participants descriptions for pre-issuance stage, and table 2 shows the same 

information but for the post-trade stage.    

Table 1 Key Participants in the Pre-issuance Process and Their Main Roles 

Issuer The entity that uses capital markets for raising money: 

1) companies, including corporates, banks and financial 
institutions 

2) governments / sovereign 
3) public authorities 
4) supranationals 

Lead Manager The financial institution mandated by the issuer to arrange the 
bond issuance and provide professional advice on the structure, 
pricing, and timing of the issue; serves as a sponsor and 
provide confirmation if the bond is to be listed. 

Syndicate The “co-managers” together with lead manager, providing a 
distribution network for the issue, sourcing investors, 
managing the book-building process, and completely or 
partially underwriting the securities. 

Auditors Auditors are involved when the issuer is an entity which 
produces accounts. They audit the issuer’s account for at least 
the previous three years. When asked, the issuer’s auditors will 
provide “comfort letters” addressed to the lead manager and 
the syndicate, mainly confirming no material change in the 
issuer’s financial condition since the last published accounts, 



 7 

and a “consent letter” consenting to the publication of their 
report in the offering document. 

Legal Advisers Separate legal advisors will be appointed by the issuer and the 
lead manager. If a trust arrangement is concerned, the trustee 
will also instruct solicitors. If the issue involves an overseas 
jurisdiction, lawyers form that jurisdiction bust be instructed to 
ensure compliance with local laws and regulations. The role of 
legal advisers in a primary issue comprises the preparation of 
documentation, participation in the due diligence process, and 
production of a legal opinion for the transaction. 

Listing Agent Appointed by the issuer to communicate with the listing 
authority on its behalf, to lodge the necessary documents with 
the listing authority, and to advise the issuer on the listing rules 
and process. 

 

Table 2 Key Participants in the Post-trade Process and Their Main Roles 

Fiscal Agent / 
trustee 

Either a fiscal agent or a trustee will be appointed by the issuers 
to help in future payments of the bonds and communications to 
bondholders. Main differences are that the fiscal agent only 
acts on behalf of the issuer, while the trustee represents the 
interests of the bondholders. 

Principal Paying 
Agent and 
Paying Agents 

Paying agents of the issuers help co-ordinate the principal and 
interest payments to the paying agents in the jurisdiction of 
bondholders where the payment is made. Alternatives can be 
the Fiscal agents when they have a presence in the 
jurisdictions. 

Clearing System Clearing systems were developed mainly to avoid physical 
handling of bearer instruments and facilitate transactions in 
both primary and secondary markets via participant’s securities 
clearance account and cash account within the system. In the 
international euro securities markets, the Euroclear system and 
the Clearstream Service are the two systems of paramount 
importance. 

Depository and 
Common 
Depository 

A depository is an eligible bank appointed to act on behalf of a 
clearing system as “safe keeper” of the physical securities. A 
common depository is the same bank required to use when an 
issue involves more than one clearing system. Under the “New 
Global Note” structure from July 2006, securities can also be 
physically held by the clearing systems themselves in order to 
be eligible as Eurosystem collateral. 



 8 

Custodian Bank A custodian bank takes full responsibility when ensuring that 
the assets are properly taken into custody and accounted for, 
and in the case of a sale, that the assets are properly delivered 
and agreed payment terms are met. Compared to the 
depository, a custodian bank does not have the control and 
legal ownership of securities and is not liable in terms of 
investment loss. 

Although a bond is newly issued (for detailed process see chapter 2.1.2) and entered 

into the market for future trading and settlement, the key players are intricately 

involved, and some of the key infrastructures are explained below:  

Central Securities Depository (CSD) 

A CSD is an entity which provides a central point for depositing financial securities, 

for example, bonds and shares. Historically, CSDs were set up by a country’s national 

financial authorities, while nowadays most European CSDs have become privately 

owned and operated in different governance structures. For instance, some CSDs are 

owned by publicly listed companies or users drawn from the clients’ pool, some 

operate as part of the corporate group including Stock Exchange and/or a CCP, while 

others operate separately from the trading and clearing venue. CSDs’ clients are 

typically financial institutions themselves (such as custodian banks and brokers) 

rather than individual investors (ECSDA, 2019).  

As introduced by the EU Regulation of 2014, there are three core functions 

performed by a CSD:  

1. Settlement service: CSDs operate IT platforms for the settlement of securities 

transactions. A transaction is “settled” once the CSD has credited the account of 

the buyer with the acquired securities (and debited the according cash amount), 

while debiting the account of the seller with the securities (and crediting its 

account with the according cash amount). Such credit and debit movements 

typically take place simultaneous, in the “Delivery versus payment” (see chapter 

2.1.2). 

2. Notary service: CSDs records newly issued securities in a book-entry system 

(called “issuer CSD”) and are often responsible for ensuring that the number of 

securities initially created equals the total number of securities in circulation 

(booked in investors’ accounts) at any time in the market. 



 9 

3. Central maintenance service: In settlement of a transaction, CSDs manage the 

rights and obligations linked to the securities holdings from the top of the 

securities chains, i.e. all holdings in a given financial instrument, whether by an 

individual or a financial institution, are ultimately kept in a security account at 

the CSD. CSDs therefore also provide for the safe keeping (or “central 

maintenance”) of securities, including, e.g. the processing of corporate actions 

such as dividend and interest payments, or voting rights execution in the case of 

shares securities. 

International CSD (ICSD) 

While CSDs were primarily created to serve their domestic market, ICSDs were 

created in the 1970s to settle Eurobonds. Over the years, ICSDs have extended the 

scope of their services to cover all types of internationally traded financial 

instruments, including equities and investment funds. There are two ICSDs in the 

European Union: Clearstream Banking located in Luxembourg and Euroclear Bank 

sit in Belgium. Both of them hold a banking license and provide settlement in 

different currencies (ECSDA, 2019). 

Central Clearing Counterparty (CCP) 

A CCP interposes itself between the two trading parties becoming the buyer to every 

seller and the seller to every buyer. The main function of a CCP is, therefore, to 

guarantee the reciprocal performance of obligations between buyers and sellers (i.e. 

the counterparties) of financial instruments negotiated on trading venues (e.g. a stock 

exchange) or bilaterally between trading parties (Over-The-Counter, OTC) through 

a process called clearing (EPTF Report, 2017). Clearing, technically, is the process 

of establishing positions, including the calculation of net obligations, and ensuring 

that financial instruments, cash, or both, are available to secure the exposures arising 

from those positions (EACH, 2019). 

CCP clearing provides several benefits for the post-trade process. First, CCPs 

facilitate risk mitigation by continuously managing the counterparty risks and 

maintain a “default waterfall” where the loss would not only be absorbed by clearing 

members’ margin and contribution to the default fund, but also CCP’s own capital 

reserve defined by EMIR. Another useful function that a CCP can provide is 

“netting”: if a counterparty buys and sells the same financial instruments in a day, 



 10 

these transactions can also be netted, compressing the quantity of cash and securities 

to be moved (EPTF Report, 2017). 

2.1.2 Issuing a bond: pre-issuance and post-trade process 

In Euromarkets, the fund-raising timeframe between the issuer first instructing and 

investment bank to arrange the issue and when the issuer receives the money may 

range from three weeks to more commonly six weeks for a stand-alone bond (Adams, 

2016). 

In figure 1, the paradigm below shows the usual order in which each stage of the 

bond issuance occurs, though at times, the next stage begins before the completion 

of the previous stage. The primary substance of each stage is explained afterwards. 

Figure 1 Paradigm Timeline for a Plain Vanilla Bond by a Debut Issuer 

Source: Banking and Capital Markets, Adams, 2016 
 
2.1.2.1 Pre-issuance Process 

a) Mandate 

At common practice, a particular company that decided to raise debt will appoint an 

investment banks to execute the issuance process. The company’s directors will first 

have lengthy meetings with investment bank originators and its own accountants as 

well as legal consultants to decide whether they are in need of raising capital. At this 

stage, the company usually receive tailored proposals from different investment 

banks, who have done preliminary research on the company and drafted various bond 

issuance schemes that fit the company’s situation and market condition. 



 11 

After reviewing the schemes proposed and going through the pitch presentations, the 

company will appoint one investment bank to lead-manage the deal. This is called as 

the “Mandate”. 

The issuer and lead manager must first reach agreement on a couple of important 

matters. These include the marketing strategy, whether to list the bonds, the identity 

of the fiscal agent or trustee and paying agents, and the fee structure. These matters 

will be documented in the “mandate letter” or “term sheet” together with the bond’s 

basic terms and conditions.  

Having the mandate, the lead manager will first advise as to the most appropriate 

structure for an issue (i.e. which type of security), the estimated volume, and the best 

market to target. For instance, the lead managers may be aware that the Middle East 

investors are especially interested in the type of business the company runs and 

recommend that the issue targets at them. The lead bank will then approach its clients 

from the Middle East who have funding capacities and will bring in other banks that 

have the relevant client base to form a syndicate group (bookrunners) to help sell the 

bonds to institutional investors or public later. 

b) Due Diligence 

The due diligence process helps with providing material for the prospectus (and 

listing particulars) and also in checking that appropriate matters are being disclosed. 

A due diligence process will usually involve meetings between the lead manager and 

its solicitor, the relevant officers of the issuer, and the issuer’s auditors to ascertain 

and verify the information needed for the issue. Obtaining the comfort letters in 

agreed form from the issuer’s auditors is also part of the due diligence process 

following analysis of the issuer’s accounts. In practice, procedures vary greatly from 

issue to issue depending on the security type issued and nature of the issuer and its 

business. 

c) Documentation 

A typical bond issue involves a substantial number of documents. The principal 

documentation required are listed in the chart below in two sections:  documents 

relating to the underwriting, subscription and distribution of the bonds and 

documents which relate to and constitute the bonds themselves. Furthermore, if the 

bond issue is to be listed, a draft of the prospectus or listing particulars must be sent 



 12 

to the appropriate listing authority usually three weeks before publication. The 

preparation and negotiation of these documents is the responsibility of the lead 

manager’s solicitors and will continue through signing and only considered complete 

on closing when the last documents of the issue are executed. 

Table 3 List of Required Documents in a Bond Issuance 

Documents related to underwriting, 
subscription and distribution 

Documents related to constitution of 
bonds  

a) mandate letter 
b) invitation telex 
c) allotment telex 
d) prospectus or other offering document 
e) subscription agreement  
f) agreement among managers 
g) auditor’s report and consent letter 
h) auditor’s comfort letters 
i) legal opinions 

a) fiscal agency agreement or trust 
deed 
b) paying agency agreement (if no 
fiscal agent) 
c) temporary global note 
d) permanent global note (or 
definitive form bond) 
e) deed of guarantee 
f) deed of covenant 

 
d) Marketing 

Marketing is an important job of the lead manager to help raise awareness for the 

issuer among investors. Roadshows in var";"""date"",""2019-09-26T20:46:25Z""
""pdf:docinfo:custom:AAPL:Keywords"",""Public""
""pdf:PDFVersion"",""1.3""
""xmp:CreatorTool"",""Microsoft Word""
""pdf:docinfo:title"",""Master’s ThesisAppearance of blockchain bonds: analysis of blockchain impact on bond issuance process in European primary market""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""Public"",""Public""
""language"",""en""
""dc:format"",""application/pdf; version=1.3""
""pdf:docinfo:creator_tool"",""Microsoft Word""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""Master’s ThesisAppearance of blockchain bonds: analysis of blockchain impact on bond issuance process in European primary market""
""xmp:CreateDate"",""2019-09-26T20:44:19Z""
""modified"",""2019-09-26T20:46:25Z""
""pdf:hasMarkedContent"",""false""
""xmp:ModifyDate"",""2019-09-26T20:44:19Z""
""pdf:docinfo:creator"",""Wanli cHEN""
""meta:author"",""Wanli cHEN""
""meta:creation-date"",""2019-09-26T20:46:25Z""
""created"",""2019-09-26T20:46:25Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-09-26T20:46:25Z""
""resourceName"",""Master_Thesis__Wanli_Chen_Qianxia_Wang.pdf""
""Author"",""Wanli cHEN""
""producer"",""Mac OS X 10.12.6 Quartz PDFContext""
""pdf:docinfo:producer"",""Mac OS X 10.12.6 Quartz PDFContext""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""Keywords"",""Public"",""Public""
""access_permission:modify_annotations"",""true""
""AAPL:Keywords"",""Public""
""dc:creator"",""Wanli cHEN""
""dcterms:created"",""2019-09-26T20:46:25Z""
""Last-Modified"",""2019-09-26T20:46:25Z""
""dcterms:modified"",""2019-09-26T20:46:25Z""
""title"",""Master’s ThesisAppearance of blockchain bonds: analysis of blockchain impact on bond issuance process in European primary market""
""xmpMM:DocumentID"",""uuid:7B876825-9A26-4008-ABE3-D043EF652E44""
""Last-Save-Date"",""2019-09-26T20:46:25Z""
""pdf:docinfo:keywords"",""Public""
""pdf:docinfo:modified"",""2019-09-26T20:46:25Z""
""meta:save-date"",""2019-09-26T20:46:25Z""
""Content-Length"",""1687555""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Wanli cHEN""
""dc:subject"",""Public"",""Public""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""100""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""366"",""1146"",""1662"",""5311"",""526"",""985"",""1661"",""1118"",""68"",""2313"",""2538"",""2210"",""2336"",""2258"",""2352"",""1416"",""2330"",""2108"",""2288"",""1329"",""2261"",""2351"",""2495"",""1816"",""2527"",""2355"",""2492"",""2317"",""2304"",""2557"",""2391"",""2289"",""2334"",""2353"",""2199"",""2356"",""2114"",""1706"",""2013"",""2167"",""2466"",""2285"",""1778"",""1702"",""1776"",""1593"",""2021"",""2444"",""2177"",""2339"",""1632"",""2621"",""2236"",""1839"",""1617"",""2307"",""1198"",""2483"",""2321"",""1817"",""2259"",""2219"",""2438"",""1572"",""2319"",""2537"",""2426"",""2342"",""2174"",""2197"",""2512"",""2499"",""2463"",""2583"",""2324"",""2606"",""2650"",""2194"",""2453"",""2485"",""3059"",""2811"",""1429"",""1946"",""2235"",""2508"",""2544"",""2695"",""1950"",""2601"",""2139"",""1433"",""2400"",""1903"",""1745"",""1753"",""2596"",""1198"",""1062"",""504""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""meta:keyword"",""Public"",""Public""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-09-26T20:46:25Z""
";https://scholar.google.com/scholar?start=470&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094612-952;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Understanding How to Use Static Analysis Tools for Detecting Cryptography Misuse in Software;A Braga, R Dahab, N Antunes… ; IEEE Transactions …, 2019  ieeexplore.ieee.org;;"… 35] studied the bug characteristics in eight open source systems for blockchain, examining bug …

of unen- crypted HTTP channels, insufficient TLS protection, and padding oracles, represented

by … as well as prototype tools like MalloDroid [26] and Padding Oracle Exploitation Tool …";Cité 5 fois;Les 2 versions;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/24/4378406/08863426.pdf?casa_token=zxDClA25NA4AAAAA:SKwr9TPmy525lf_0qjhfCPHanDma8RWkx4fqcyTjmNuFmkdP7Qvy-i7Bt9QdKNjwao0afnUKexs;"
		Skip to Main Content


		
			
				
				

				

			

		


		
			
				
					
						








	
		
	

	







						

						





























	
	
		
	
	
		
			

		
	

	
	
	



						





	
	
		
			
				IEEE Account

					Change Username/Password
	Update Address


			

			
				Purchase Details

					Payment Options
	Order History
	View Purchased Documents


			

			
				Profile Information

					Communications Preferences
	Profession and Education
	Technical Interests


			

			
				Need Help?

					US & Canada: +1 800 678 4333
	Worldwide:  +1 732 981 0060

					
	Contact & Support


			

		

		
			
				
					
							About IEEE Xplore
	Contact Us
	Help
	Accessibility
	Terms of Use
	Nondiscrimination Policy
	Sitemap
	Privacy & Opting Out of Cookies


						
							A not-for-profit organization, IEEE is the world's largest technical professional organization dedicated to advancing technology for the benefit of humanity.
Š Copyright 2021 IEEE - All rights reserved. Use of this web site signifies your agreement to the terms and conditions.
						

					


					

				

				
			

		

	


	
	


						
						






		
		
		
		
		
		
		
		
		
		
		
		
		
			
				
			
			
			
			
		
		
		
		
		
		

			


			

			
			


		
 		
		
			 

						
						









































	

		
		

		
		
		

		
			
		
		
		

		

		
		


		

		
		
		
		
		
		
		
		
		
		
	
	


















		
		
			
				
					
					
								
					
								
			
				
					
					
								
					
								
			
				
					
						








 



					
					
								
			
				
					
					
								
			
				
					
					
								
					
								
			
				
					
					
								
					
								
			
				
					
					
								
					
								
			
				
					
					
								
					
								
			
				
					
					
								
					
								
			
				
					
					
								
					
								
			
		
	




























		
			
					
			
					
			
					
			
				
					








					
			
					
			
					
			
					
			
					
			
					
			
					
			
		
		
	





	
	
	
	
	
	
	


	
	
	

	

















					

				

			


			
				
			
		

	";"""og:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""twitter:title"",""Understanding How to Use Static Analysis Tools for Detecting Cryptography Misuse in Software""
""twitter:card"",""summary""
""Description"",""The use of cryptography is nowadays common in software systems, with cryptographic libraries widely available to software developers. As such, the likely weakes""
""og:title"",""Understanding How to Use Static Analysis Tools for Detecting Cryptography Misuse in Software""
""resourceName"",""08863426.pdf""
""language"",""en""
""title"",""Understanding How to Use Static Analysis Tools for Detecting Cryptography Misuse in Software | IEEE Journals & Magazine | IEEE Xplore""
""og:description"",""The use of cryptography is nowadays common in software systems, with cryptographic libraries widely available to software developers. As such, the likely weakest link in sensitive software has moved from cryptographic function implementations to the application code surrounding such functions. Ordinary developers usually lack knowledge in practical cryptography, and support from specialists is rare. Frequently, these difficulties are addressed by running static analysis tools to automatically detect cryptography misuse during coding and reviews. However, the effectiveness of such tools is not yet well understood. This article studies how well programmatic misuse of cryptography is detected by free static code analysis tools. The performance of such tools in detecting misuse is correlated to coding tasks and use cases commonly found in development efforts; also, cryptography misuse is classified in comprehensive categories, easily recognizable by software security practitioners. Our research shows that the coverage of public-key cryptography by static code analysis tools is full of blind spots, because tools prioritize only those misuses related to the most frequent coding tasks and use cases, while neglecting infrequent use cases. We found that, in addition to a relatively low recall in our tests, evaluated tools also have a small overlap regarding the misuses detected by all the evaluated tools, as well as an intersection of false alarms, suggesting lack of discrimination between specific misuses and corresponding good uses of cryptography. In spite of that, well-selected tools can be useful when developing cryptographic software, but support of experts is still required for solving complex cases.""
""twitter:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-UA-Compatible"",""IE=Edge""
""viewport"",""width=device-width, initial-scale=1.0""
""dc:title"",""Understanding How to Use Static Analysis Tools for Detecting Cryptography Misuse in Software | IEEE Journals & Magazine | IEEE Xplore""
""twitter:description"",""The use of cryptography is nowadays common in software systems, with cryptographic libraries widely available to software developers. As such, the likely weakest link in sensitive software has moved from cryptographic function implementations to the application code surrounding such functions. Ordinary developers usually lack knowledge in practical cryptography, and support from specialists is rare. Frequently, these difficulties are addressed by running static analysis tools to automatically detect cryptography misuse during coding and reviews. However, the effectiveness of such tools is not yet well understood. This article studies how well programmatic misuse of cryptography is detected by free static code analysis tools. The performance of such tools in detecting misuse is correlated to coding tasks and use cases commonly found in development efforts; also, cryptography misuse is classified in comprehensive categories, easily recognizable by software security practitioners. Our research shows that the coverage of public-key cryptography by static code analysis tools is full of blind spots, because tools prioritize only those misuses related to the most frequent coding tasks and use cases, while neglecting infrequent use cases. We found that, in addition to a relatively low recall in our tests, evaluated tools also have a small overlap regarding the misuses detected by all the evaluated tools, as well as an intersection of false alarms, suggesting lack of discrimination between specific misuses and corresponding good uses of cryptography. In spite of that, well-selected tools can be useful when developing cryptographic software, but support of experts is still required for solving complex cases.""
""Content-Encoding"",""UTF-8""
""Content-Type-Hint"",""text/html; charset=utf-8""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=770&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094654-1135;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[HTML][HTML] Security tokens: architecture, smart contract applications and illustrations using SAFE;H Subramanian ; Managerial Finance, 2019  emerald.com;United Kingdom;"… The financial product should be tradeable either to fiat or to other crypto-tokens … Oracle registry –

the oracle registry is a store for user identifiable information, where parties (eg … who can participate

in a contract can store their personally identifiable information on the blockchain …";Cité 6 fois;Les 5 versions;[HTML] emerald.com;https://www.emerald.com/insight/content/doi/10.1108/MF-09-2018-0467/full/html?casa_token=Ng2yPbfj6IIAAAAA:EqqcVCROBav5-JHOJu0oBrUZPNZRiwIvNb67SKFrKuM2zJzkyPzlO61wBr2tP44ZLQtoKa-rU-SiIszs0jrkvKe11n4ar0e8kq1KPpehJem79DxqgA;"






    





    
    
    



    
        
        
            
                
                    Books and journals
                    Case studies
                    Expert Briefings
                    Open Access
                

            
        

    


    
    

            
    
        
            
            
        


        
            
                Advanced search
            


                    

    



        
    
        
            
            
        

    



    


    
        
    
    
        
            
                
                    
                                                To read the full version of this content please select one of the options below:

                        
    
        [image: Emerald logo icon]
        Access options
        
    
    
                    
        
                
            You may be able to access this content by logging in via Shibboleth, OpenAthens or with your Emerald account.
        

        
            
                Login
                
            
        

    

    
        
            
        
                
            
                Rent this content from DeepDyve
            

            
                    
                        Rent from DeepDyve
                        
                    
            

        

        
        
    
    
        
            If you think you should have access to this content, click to contact our support team.
        

        
            
                Contact us
                
            
        

    





            




                    

                

            

        

    


    
        
            
                
                    
                                                Please note you do not have access to teaching notes

                        
    
        [image: Emerald logo icon]
        Access options
        
    
    
                    
        
                
            You may be able to access teaching notes by logging in via Shibboleth, OpenAthens or with your Emerald account.
        

        
            
                Login
                
            
        

    

    
        
    
    
        
            If you think you should have access to this content, click to contact our support team.
        

        
            
                Contact us
                
            
        

    





            




                    

                

            

        

    


    
        
            
                
    Security tokens: architecture, smart contract applications and illustrations using SAFE

    
    
         Hemang  Subramanian
            (Department of Information Systems and Business Analytics, Florida International University, Miami, Florida, USA)
        

    

    
    
        
                    
                Managerial Finance
            

        
        
                    
                
                    ISSN:
                    0307-4358
                
            

        
        
            
                                                                Article publication date: 13 August 2019

                            
                    

                
            
        


                            
                Issue publication date: 29 August 2020
            

            

    
                    
    
    

            



    
            

        

    

    
        

            
            
                
            Abstract

                            
                                

                    
                    
                                            Purpose

                                        
                        Blockchain technologies have pervaded modern crowdfunding and capital sourcing through a variety of financial instruments implemented as smart contracts. Smart contracts provide a unique mechanism not only to create a unique one-of-a-type financial instrument, but also to enable unique innovations atop existing financial instruments due to underlying efficiencies. The smartness comes from the flexibility that programs provide which can create extremely unique financial instruments that are often complex to implement, yet easy to create, maintain through versioning, trade and destroy. The purpose of this paper is to describe the security token architecture as an application of smart contracts. Further, the author illustrates the implementation and design of a commonly used financial instrument known as Simple Agreement for Future Equity (SAFE) using the security token architecture proposed and smart contract functionality. The author then models the transaction using relational algebra, and, models the utility maximization. The author shows how on account of reduced information asymmetry between the investors and SAFE users (i.e. startups) utility is positive when smart contract-based security tokens are deployed for each state in the SAFE contract.

                    
                


                            
                                

                    
                    
                                            Design/methodology/approach

                                        
                        Using an existing well-adopted instrument called a SAFE contract, the author illustrates the architecture of a smart contract-based security token system. The author illustrates how different components of a SAFE contract can be implemented as a smart contract and discusses the advantages and disadvantages of applying blockchain-based smart contracts to design SAFE instruments. The author deploys two methods: a state space diagram to explain state transitions and a utility model to explain the utilities.

                    
                


                            
                                

                    
                    
                                            Findings

                                        
                        The key findings of this research study are the design of a security token architecture, which can be used to convert any the physical or contract-based financial instrument to a smart contract that runs on the blockchain. However, there are limitations to the implementation of the same which can be overcome. The model illustrates the positive utilities derived for all economic actors, i.e. the contractors, the utility providers, etc., in the market.

                    
                


                            
                                

                    
                    
                                            Originality/value

                                        
                        This paper is an original paper. For the very first time, the author explored the architecture of a security token system. Using a well-known financial instrument, namely the SAFE, the author describes various components, e.g. the four contracts that form SAFE and then model the utilities for the system.

                    
                


                    

    

                
        Keywords

        	 Financial instruments
	 Blockchain
	 Smart contracts
	 SAFE instrument
	 Security tokens
	 Utility maximization


    

                
                                    
    Citation

    
        Subramanian, H. (2020), ""Security tokens: architecture, smart contract applications and illustrations using SAFE"", Managerial Finance, Vol. 46 No. 6, pp. 735-748. https://doi.org/10.1108/MF-09-2018-0467
    


            
            
        

    
                
                
        Publisher
:
        Emerald Publishing Limited

    

                
        Copyright Š 2019, Emerald Publishing Limited
    

                        


            
                                    

                            

        

    


    
    

    

    
    
        
            
                [image: Emerald Publishing]
                
                    	 Opens in new window
	 Opens in new window
	 Opens in new window
	 Opens in new window


                

                Š 2021 Emerald Publishing Limited

            

            
                Services

                	Authors Opens in new window
	Editors Opens in new window
	Librarians Opens in new window
	Researchers Opens in new window
	Reviewers Opens in new window


            

            
                About

                	About Emerald Opens in new window
	Working for Emerald Opens in new window
	Contact us Opens in new window
	Publication sitemap


            

            
                Policies and information

                	Privacy notice
	Site policies
	Modern Slavery Act Opens in new window
	Chair of Trustees governance statement Opens in new window
	COVID-19 policy Opens in new window


            

        

    




    



    














  
  
    
    
        
            ×
        
    

    
        

    





    


    

    










  
    
      
        Support & Feedback 
      

    
    
      Manage cookies
    
  


  
    
      

        
          We’re listening — tell us what you think

          	
              Something didn’t work…

              Report bugs here

            
	
              All feedback is valuable

              Please share your general feedback

            
	
              Member of Emerald Engage?

              You can join in the discussion by joining the community or logging in here.
You can also find out more about Emerald Engage.

            


        


        
          Join us on our journey

          	
              Platform update page

              Visit emeraldpublishing.com/platformupdate to discover the latest news and updates

            
	
              Questions & More Information

              Answers to the most commonly asked questions here

            


        


      

    

  












";"""keywords"",""Financial instruments,Blockchain,Smart contracts,SAFE instrument,Security tokens,Utility maximization""
""dc.Title"",""Security tokens: architecture, smart contract applications and illustrations using SAFE""
""citation_journal_title"",""Managerial Finance""
""description"",""Security tokens: architecture, smart contract applications and illustrations using SAFE - Author: Hemang Subramanian""
""language"",""en""
""title"",""Security tokens: architecture, smart contract applications and illustrations using SAFE
 |  Emerald Insight""
""dc.Identifier"",""10.1108/MF-09-2018-0467"",""0307-4358""
""dc.Publisher"",""Emerald Publishing Limited""
""dc.Format"",""text/html""
""dc:title"",""Security tokens: architecture, smart contract applications and illustrations using SAFE
 |  Emerald Insight""
""csrf-token"",""XfkOolnOPjDS1Diji6IKcpJFLe59dyuYtZyfzDKQ""
""Content-Encoding"",""UTF-8""
""dc.Date"",""2019-08-13T00:00:00Z""
""citation_xml_url"",""https://www.emerald.com/insight/content/doi/10.1108/MF-09-2018-0467/full/xml""
""dc.Subject"",""Financial instruments,Blockchain,Smart contracts,SAFE instrument,Security tokens,Utility maximization""
""Content-Type"",""text/html; charset=UTF-8""
""dc.Contributor"",""Hemang Subramanian""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""dc.Type"",""article""
""resourceName"",""html""
""X-UA-Compatible"",""IE=edge""
""dc.Language"",""en""
""dc.Description"",""Blockchain technologies have pervaded modern crowdfunding and capital sourcing through a variety of financial instruments implemented as smart contracts. Smart contracts provide a unique mechanism not only to create a unique one-of-a-type financial instrument, but also to enable unique innovations atop existing financial instruments due to underlying efficiencies. The smartness comes from the flexibility that programs provide which can create extremely unique financial instruments that are often complex to implement, yet easy to create, maintain through versioning, trade and destroy. The purpose of this paper is to describe the security token architecture as an application of smart contracts. Further, the author illustrates the implementation and design of a commonly used financial instrument known as Simple Agreement for Future Equity (SAFE) using the security token architecture proposed and smart contract functionality. The author then models the transaction using relational algebra, and, models the utility maximization. The author shows how on account of reduced information asymmetry between the investors and SAFE users (i.e. startups) utility is positive when smart contract-based security tokens are deployed for each state in the SAFE contract.,Using an existing well-adopted instrument called a SAFE contract, the author illustrates the architecture of a smart contract-based security token system. The author illustrates how different components of a SAFE contract can be implemented as a smart contract and discusses the advantages and disadvantages of applying blockchain-based smart contracts to design SAFE instruments. The author deploys two methods: a state space diagram to explain state transitions and a utility model to explain the utilities.,The key findings of this research study are the design of a security token architecture, which can be used to convert any the physical or contract-based financial instrument to a smart contract that runs on the blockchain. However, there are limitations to the implementation of the same which can be overcome. The model illustrates the positive utilities derived for all economic actors, i.e. the contractors, the utility providers, etc., in the market.,This paper is an original paper. For the very first time, the author explored the architecture of a security token system. Using a well-known financial instrument, namely the SAFE, the author describes various components, e.g. the four contracts that form SAFE and then model the utilities for the system.""
""viewport"",""width=device-width, initial-scale=1""
""DCTERMS.bibliographicCitation"",""&ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Ajournal&rft.spage=735&rft.epage=748&rft.volume=46&rft.issue=6""
""dc.Coverage"",""world""
""Content-Language"",""en""
""format-detection"",""telephone=no""
";https://scholar.google.com/scholar?start=950&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094661-1162;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Collusion resistant broadcast and trace from positional witness encryption;R Goyal, S Vusirikala, B Waters ; IACR International Workshop on Public …, 2019  Springer;;"… However, we chose to refer to it as Broadcast and Trace system as it is more

appropriate. They have an additional tracing algorithm which given only the oracle

access to the box D can perform this traitor extraction. Broadcast …";Cité 6 fois;Les 2 versions;[PDF] iacr.org;https://eprint.iacr.org/2019/031.pdf;"
Collusion Resistant Broadcast and Trace from Positional Witness

Encryption

Rishab Goyal∗ Satyanarayana Vusirikala† Brent Waters‡

Abstract

An emerging trend is for researchers to identify cryptography primitives for which feasibility was
first established under obfuscation and then move the realization to a different setting. In this work we
explore a new such avenue — to move obfuscation-based cryptography to the assumption of (positional)
witness encryption. Our goal is to develop techniques and tools, which we will dub “witness encryption
friendly” primitives and use these to develop a methodology for building advanced cryptography from
positional witness encryption.

We take a bottom up approach and pursue our general agenda by attacking the specific problem
of building collusion-resistant broadcast systems with tracing from positional witness encryption. We
achieve a system where the size of ciphertexts, public key and private key are polynomial in the security
parameter Îť and independent of the number of users N in the broadcast system. Currently, systems
with such parameters are only known from indistinguishability obfuscation.

1 Introduction

Over the past five years the introduction of candidate indistinguishability obfuscation schemes [GGH+13b]
has produced a dramatic shift in the community’s view of which cryptographic primitives are plausibly
achievable. Starting with [SW14] there have been several works [SW14, BZ14, GGHR14, BP15, KLW15,
CLTV15, HJK+16, GPS16, BPW16] that leverage the power of indistiguishability obfuscation [BGI+01,
BGI+12] to give new solutions for problems ranging from deniable encryption to showing the hardness of
finding Nash equilibrium.

An emerging trend is for researchers to identify cryptography primitives for which feasibility was first
established under obfuscation and then move the realization to a different setting. For example, several
works [BP15, KW16, AP16, GKW17b, GKW17a, WZ17] proposed solutions under the Learning with Er-
rors [Reg05] (LWE) assumption of primitives (or impossibility results) that to that point were known only
under indistinguishability obfuscation. The motivation for this movement is that LWE is considered a
standard assumption with connections to certain problems on lattices, while current indistinguishability
obfuscation constructions are based on much newer multilinear map candidates. In a different line of re-
searchers [GPSZ17, LZ17] have shown how to base applications such as realizing trapdoor permutations and
the hardness of Nash equilibrium from functional encryption. While subexponentially hard functional en-
cryption is known to imply indistinguishability obfuscation [AJ15, BV15, AJS15], this direction is motivated
by building these primitives with only a polynomial loss in the reductions coupled with prospect of functional
encryption schemes realized from the polynomial hardness of standard assumptions.

In this work we explore a new such avenue — to move obfuscation-based cryptography to the assumption
of (positional) witness encryption [GGSW13, GLW14]. Recall that in a witness encryption scheme, say
for SAT, an encryption algorithm takes in a message m along with a boolean formula φ that operates an

∗University of Texas at Austin. Email: rgoyal@cs.utexas.edu.
†University of Texas at Austin. Email: satya@cs.utexas.edu.
‡University of Texas at Austin. Email: bwaters@cs.utexas.edu. Supported by CNS-1414082, DARPA SafeWare, Microsoft

Faculty Fellowship, and Packard Foundation Fellowship.

1



n bit input w producing a ciphertext ct. A decryptor can recover the message m from ct if it knows a
w such that φ(w) = 1. If no such w exists, then the message is computationally hidden. In addition to
serving as its own application, witness encryption is known to give rise to primitives such as identity-based
encryption [Sha85, BF01] and attribute-based encryption [SW05].

A natural question is why push for moving cryptography from indistinguishability obfuscation to posi-
tional witness encryption when current constructions for both rely on multilinear maps [GGH13a, CLT13,
GGH15, CLT15]. The justification (like in [GPSZ17, LZ17]) relies on some projection to the future. Since
witness encryption is a less powerful primitive than indistinguishability obfuscation, it is believed that the
community will likely arrive at a standard assumption solution earlier. This conjecture is supported by some
heuristic evidence:

• The work of [GLW14] showing provably secure positional witness encryption from simple multilinear
map assumptions came earlier than and was simpler than the later work [GLSW15] which gave a
similar result for obfuscation.

• Recently, it was shown [BJK+17] that attribute-based encryption gives rise to a non-trivial form
of witness encryption. This might lead to further advances in witness encryption which would not
necessarily translate to general obfuscation.

• Recently, the concept of lockable obfuscation [GKW17a, WZ17] was proposed and shown to be realiz-
able under the LWE assumption. Like witness encryption this is a general class of obfuscation, but is
more restricted than indistinguishability obfuscation.

• Very recently, Chen et al. [CVW18] gave a new candidate for witness encryption (albeit not posi-
tional witness encryption) inspired by [GGH15] multilinear encodings. An important feature of their
candidate is that it directly encodes read-once branching program representations of the associated
CNF formulae, thereby avoiding attacks such as input-mixing and more. Since read-once branching
programs are much less expressive than general branching programs, this also points towards reaching
the goal of witness encryption before obfuscation.

In addition, we expect future solutions to witness encryption to be practically more efficient than full blown
indistinguishability obfuscation.

Our goal is to develop techniques and tools, which we will dub “witness encryption friendly” primitives1,
and use these to develop a methodology for building advanced cryptography from positional witness encryp-
tion. While we don’t expect to move all or even “most” of obfuscation-based cryptography to positional
witness encryption, we believe that a long term effort could yield a number of applications which are compara-
ble to those achieved from the aforementioned efforts on building from functional encryption [GPSZ17, LZ17]
or lockable obfuscation [GKW17a, WZ17].

We will take a bottom-up approach and pursue our general agenda by attacking specific problems that
are not known from witness encryption. To that end in this work we study building collusion-resistant
broadcast systems with tracing from positional witness encryption. Our goal is to achieve where the size of
ciphertexts, public key and private key are polynomial in the security parameter Îť and independent of the
number of users N in the broadcast system.2 Below we provide an overview of prior work, present our new
results, toolkit of “witness encryption friendly” primitives, and the techniques that allow us to achieve the
above goals.

1.1 Overview

Broadcast Encryption with Tracing. Broadcast Encryption was introduced by Fiat and Naor [FN94].
A broadcast encryption scheme, like a standard public key encryption scheme, consists of three algorithms

1This is intended to mirror the term “iO friendly” used elsewhere in the literature.
2Following prior broadcast encryption literature we will not count a description S of the recipients of a ciphertext toward

the ciphertext overhead.

2



— setup, encryption and decryption. The setup algorithm outputs a public key and N secret keys, where
N represents the number of users given as an input. Using the encryption algorithm, a sender can encrypt
a message such that the corresponding ciphertext can only be decrypted by the “qualified” users S ⊆ [N ].3

Here the set S is given as input to the encryption algorithm. The decryption algorithm is self-explanatory.
For security it is required that no set of colluding users can decrypt a ciphertext if none of them are qualified.

Suppose that a set of users S1 collude to create a decoding box D which is capable of decrypting
ciphertexts intended for some (possibly different) set of users S2 with some non-negligible probability. A
broadcast system which provides tracing capabilities allows extraction of a non-empty set T (from the box
D) such that T ⊆ S1, i.e. contains at least one colluding user but none outside of it. Such broadcast systems
are referred to as Trace and Revoke systems in the folklore [NP00, NNL01]. However, we chose to refer to it
as Broadcast and Trace system as it is more appropriate. They have an additional tracing algorithm which
given only the oracle access to the box D can perform this traitor extraction.

Broadcast and Trace via Augmented Broadcast Encryption (AugBE). Boneh and Waters (BW) [BW06a]
built the first fully collusion resistant Broadcast and Trace scheme with sub-linear (in N) ciphertext size.
They also provided a framework for building Broadcast and Trace schemes by introducing an intermediate
primitive called augmented broadcast encryption (AugBE). We follow the same approach in this work and
therefore we elaborate on it now.

An AugBE scheme, as the name suggests, is a broadcast encryption scheme with an augmented en-
cryption functionality. Similar to a standard broadcast encryption scheme it consists of setup, encryption
and decryption algorithms. In an AugBE system, the encryption algorithm also receives a “cutoff” index
i ∈ [N + 1], in addition to a set S ⊆ [N ], as an input. This cutoff index affects the decryptability of the
ciphertext in such a way that the resultant ciphertext can only be decrypted by the users S′ = S \ [i − 1],
i.e. users whose indices are as large as i and belong to the set S are now labelled as qualified. BW defined
two security properties for an AugBE system — index hiding and message hiding security. The first security
property (index hiding) states that an encryption of m under set S to index i is indistinguishable from an
encryption of m under set S to index i+ 1, if either i /∈ S (even when the adversary has all the secret keys),
or the adversary does not have the ith key. The second property (message hiding) states that an encryption
of m0 under set S to index N + 1 is indistinguishable from an encryption of m1 under set S to index N + 1,
even when the adversary is given all N secret keys.

BW argued that if an AugBE scheme satisfies these two properties, then that is sufficient for constructing
a Broadcast and Trace (BT) scheme. In their transformation, the BT setup and decryption algorithm are
identical to their AugBE counterparts. For encryption, a sender runs the AugBE encryption algorithm with
the cutoff index value set to be 1. The tracing algorithm runs AugBE encryption varying the value of cutoff
index. Given a decoder box D and target set S, the tracing algorithm encrypts random messages under set S
to every index i = 1 to N +1, and estimates (for each index i) the probability D decrypts correctly. Suppose
the probability decoder D is successful, i.e. decrypts standard (index 1) ciphertexts correctly, is at least Îľ.
By message hiding property, we know that D can not have non-negligible success probability when run on
ciphertexts encrypting to index N + 1. This implies that there must exist an index i∗ ∈ [N ] such that the
decoder’s success probability in decrypting index i∗ ciphertexts is at least ≈ ε/N more than in decrypting
index i∗ + 1 ciphertexts. Every cutoff index i where there is a gap in the estimated success probabilities for
index i and i+ 1, the tracing algorithm adds that user i to the set of traitors. The main idea here is that if
an index i /∈ S or the adversary does not have the key for user i, then by index hiding security it should not
be able to distinguish between index i and i+ 1 ciphertexts.

Although the above transformation seems to work (at least intuitively), we would like to point out that
the proof provided in [BW06a] was inaccurate. Very briefly, the problem lies in the fact that there is a
“semantic gap” between the definitions of BT and AugBE schemes. The issue is that in a BT system an
adversary outputs a box which performs some decoding/decryption operations, whereas in an AugBE system
the adversary plays a distinguishing game. At first, it seems like one could use the decoder box to decrypt
the ciphertext and use its output for distinguishing. The problem is that decoder might work incorrectly

3Here qualified could alternatively be interpreted as “non-revoked”.

3



sometime and it would affect the success probability of the reduction algorithm. Similar issues were observed
by Goyal, Koppula and Waters [GKW18] in the context of (non-broadcast) traitor tracing. They resolved
the issue by upgrading the security requirements from the underlying intermediate primitives to match the
decoder-based security notions required for traitor tracing. In this work we fix the proof of security for the
BW transformation showing that it does lead to a secure BT scheme.4 More details are provided later in
Section 3.

Our Results and Prior Work. Our main result are new collusion-resistant Broadcast and Trace schemes
from positional witness encryption where the size of ciphertexts, public key and private key are polynomial
in the security parameter Îť and independent of the number of users N5. Currently, systems with such pa-
rameters are only known from indistinguishability obfuscation [NWZ16]. If we drop the tracing requirement,
that is consider only broadcast encryption, there are constructions based on multilinear maps [BWZ14] and
iO [BZ14]. If we drop the revocation requirement, that is consider only traitor tracing, schemes with such pa-
rameters are known based on iO [BZ14]. In bilinear groups we can achieve short ciphertexts [BGW05, GW09],
but with longer keys if we drop the tracing requirement. Additionally, we have solutions [BW06a] with ci-
phertexts that grow proportionally to

√
N if we keep it. Very recently, Goyal, Koppula and Waters [GKW18]

gave a polylog traitor tracing scheme from the LWE assumption. However, their system does not have the
capability to broadcast to arbitrary sets.

We further develop a toolkit of certain simpler primitives such that these could be used in conjunction
with positional witness encryption in similar vein to how we have iO friendly primitives to support appli-
cations of iO. Our BT scheme is secure assuming the existence of positional witness encryption and these
simpler primitives. We provide numerous instantiations of these primitives from a wide variety of standard
assumptions such as LWE, RSA and decision linear over bilinear groups. Now we describe our techniques
and main ideas to build a Broadcast and Trace system.

Building Augmented Broadcast Encryption from Positional Witness Encryption. The main
building block used in our construction is a positional witness encryption (PWE) scheme. In a PWE
scheme, the encryption algorithm also takes as input a cutoff index i ∈ {0, . . . , 2n} where n is the bit length
of witnesses on which the corresponding boolean formula (witness relation) φ operates. A decryptor can
recover the message m from ct if it knows a w such that φ(w) = 1 and w ≥ i.6 For security it has two
properties — message hiding and index hiding. First, message hiding states that a message encrypted for
index 2n (i.e., the last index) is hidden irrespective of the boolean formula used. Second, index hiding states
that an encryption of m under formula φ for index i is indistinguishable from an encryption of m under φ
to index i+ 1, if φ(i) = 0.

We now provide an outline of our AugBE construction. Let us start with a simple idea. Suppose during
setup, the algorithm samples a key pair for a standard signature scheme. Next, the secret key for ith user
consists of a signature σi on message i and the public key simply corresponds to the verification key vk. To
encrypt a message m under set S and index i, the encryptor runs the PWE encryption algorithm on message
m for index i || 0` and formula φvk,S , where φvk,S(j, σ) = 1 iff ‘j ∈ S’ and ‘σ is a valid signature on j under
vk’. Here ` denotes the length of the signatures. For decryption a user simply runs the PWE decryption with
its index and signature as the witness. Correctness of this scheme follows directly. However, this scheme is
clearly not compact since the set S is embedded in the formula φvk,S and since the size of PWE ciphertexts
could arbitrarily (but polynomially) depend on the size of the formula, thus the overall AugBE scheme could
be highly inefficient. In a few words the problem is that we are implementing a trivial set membership check
which breaks compactness.

To get around this problem we will use an alternate set membership check. Our idea is to embed only a
succinct commitment to the set S in the formula φ such that there exists proofs of membership in S that grow
at most logarithmically with the number of users N . Clearly such a primitive would resolve the inefficiency

4Here we only consider BT schemes with public traceability.
5Here we assume that number of users N is at most poly(Îť)
6Here comparisons between bit-strings is performed by interpreting each bit-string as non-negative integer.

4



problem. One possible execution of this idea is via a Merkle hash tree.7 Let IS represent the N -bit indicator
string corresponding to set S, i.e. ith bit of IS is 1 iff i ∈ S. We modify the encryption procedure as follows
— first compute a hash h of string IS ; next run the PWE encryption algorithm on message m for index
i || 0` || 0k and formula φvk,h,N , where φvk,h,N (j, σ, π) = 1 iff ‘j ≤ N ’, ‘π is a valid proof membership for
index j w.r.t. hash h’ and ‘σ is a valid signature on j under vk’. Here proof π simply corresponds to the
pre-images in the hash tree along the path from the root h to the leaf node containing the jth bit, and k
denotes the length of proof π. The decryption is then performed analogously where the decryptor computes
the membership proof by hashing IS and using the appropriate leaf-to-root path as a proof. This seems to
resolve the succinctness problem as the size of the ciphertext is independent of the number of users. Also,
at least intuitively, it seems that the scheme should satisfy both index hiding and message hiding security
properties. The intuition is that since φvk,h,N is not satisfied by any witness larger than (N + 1) || 0` || 0k,
by using security of PWE we can argue message hiding security for the above scheme.8 For arguing index
hiding security we would hope to use the fact that if i /∈ S, or if the adversary does not receive the key for
ith user, then the adversary does not know of any witnesses of the form i || {0, 1}` || {0, 1}k and thus we could
use PWE index hiding security. In the first case (i.e., i /∈ S) hardness of computing witnesses should follow
from collision resistance of the hash function, and in the second scenario it should follow from unforgeability
of the signature scheme. However, there is a problem here. Although we could argue that witnesses are
hard-to-compute while proving index hiding for AugBE, this won’t be sufficient overall as for applying PWE
index hiding security as it is necessary that there does not exist any witness of the form i || {0, 1}` || {0, 1}k.
Thus, unless the underlying PWE scheme provides some strong notion of extractable security, it is not clear
how to prove security of the above construction.9

To this end, we develop a toolkit of certain simpler primitives, which aid us in proving our construction
to be secure. Our motivation here is that using such primitives, we could somehow indistinguishably switch
between instances/formulae which have hard-to-compute witnesses to instances/formulae which do not have
any witnesses (in some particular pre-specified range). Thus this would enable applicability of the index
hiding security property of PWE scheme in the corresponding proof. Below we elaborate on two such
primitives — all-but-one signatures and somewhere perfectly binding hash functions (a primitive similar to
somewhere statistically binding hash functions described in [HW15, OPWW15]).10

A Toolkit for Witness Encryption. The first primitive we consider is a special type of signature scheme
called all-but-one (ABO) signatures. These are just like standard signatures, except the setup algorithm has
a special “punctured” mode in which it takes a message m∗ as an additional input and outputs a pair of
signing and verification key (sk, vk) such that there does not exist any signature that gets verified for message
m∗. In other words, the verification algorithm on inputs vk and m∗ rejects every signature σ. Now instead of
unforgeability-type security, we only require that an adversary should not be able to distinguish verification
keys that are output by punctured setup with message m∗ from those output by normal setup, even when
given access to the signing oracle.11 We note that the notion of ABO signatures is motivated by constrained
signatures [BZ14] and splittable signatures [KLW15], but is much weaker than both of those. In this work,
we also provide new constructions of ABO signatures from a wide variety of standard assumptions. Next we

7The idea of using Merkle hash tree for efficiently committing to large sets has also been previously used in works such
as [ABG+13, Zha16].

8The proof will invole an exponential number of hybrids. This is because for applying message hiding security property of
PWE the index used must be 2Îť+`+k (i.e., the last index), therefore we need to use index hiding security to go from index
(N + 1) || 0` || 0k to 2Îť+`+k which takes an exponential number of hybrid steps. Here the exact ordering of witness components,
i.e. i, σ, π, is very important for the proof to go through. We can only use the security of PWE scheme if index i is leading
term and corresponds to the most significant bits.

9Although the notion of witness encryption with extractable security has been well studied [GKP+13, GGHW14], extractabil-
ity in the case of positional witness encryption is rather non-trivial to define due to the fact that PWE already requires index
hiding to hold for all indices.

10We would like to point out that our techniques of relaxing extractably-secure assumptions to more standard
indistinguishability-based assumptions are in part inspired by analogous results in the regime of moving from differing-inputs
obfuscation (diO) to indistinguishability obfuscation (iO) [HW15, NWZ16, CDG+17].

11The adversary is not allowed to query the oracle on message m∗ to allow trivial distinguishing attacks.

5



discuss the second primitive we use, and later we will circle back to the new ABO signature constructions
we provide.

The next primitive we employ is a somewhere perfectly binding (SPB) hash function [HW15, OPWW15].
An SPB hash consists of four algorithms — setup, hash, open and verify. The setup algorithm is used to
sample a hash key hk, and has two modes (akin to ABO signatures) — normal and “binding”. In the binding
mode it takes an index i as an additional input, and it ensures that the corresponding hash function Hhk is
perfectly binding for the ith message position (i.e., the hash value completely determines the ith bit of the
pre-image). Additionally, SPB hashes have a local opening property which states that for any message m,
any index i ≤ |m| and hash h = Hhk(m), one could create a short proof π proving that the message’s ith bit
is m[i] and it hashes to h.12 Such proofs could be verified by running the verification algorithm which also
take as input the hash key, hash value and a position. For security it is required that an adversary should
not be able to distinguish between hash keys that are output by binding setup and those output by normal
setup.

Next we show that if we use ABO signatures and SPB hash functions in the previously described AugBE
construction then we can prove its security using positional witness encryption.

Completing AugBE Construction. As discussed earlier, ABO signature scheme and an SPB hash
function enable us to indistinguishably turn instances with hard-to-compute witnesses into instances which
have no witnesses (in a particular range). Therefore, by simply using an ABO signature scheme and an SPB
hash function in our AugBE construction, we can also prove index hiding property of our construction. The
construction is identical to the one described before, except that checking membership of index j will now
be done by SPB verification algorithm as follows — ‘π proves that there exists a string x such that x[j] = 1
and Hhk(x) = h’. The proof of AugBE message hiding stays the same as φvk,hk,h,N is not satisfied by any
witness larger than (N + 1) || 0` || 0k. The AugBE index hiding proof is divided in two parts. Let i be the
challenge index, S the challenge set and SA the set of keys in adversary’s possession. We know that either
i /∈ S or i /∈ SA. Consider the following cases.

- i /∈ SA : The idea here is that since the adversary does not have key for user i, thus we could instead
generate the (sk, vk) key pair by running punctured setup for message i. From adversary’s perspective
this can not be distinguished with non-negligible probability by ABO security. And now, since the
verification key vk no longer accepts any signature σ for message i, we get φvk,hk,h,N (w) = 0 for all
i || 0` || 0k ≤ w < (i+ 1) || 0` || 0k. As a result, we could use PWE index hiding security to switch from
index i AugBE ciphertexts to index i + 1 ciphertexts. Finally, we could un-puncture the key vk to
complete the proof.

- i /∈ S : The proof is very similar to the one described above. The only modification will be that instead
of puncturing the verification key at index i, we bind the hash key for position i. The intuition is
that since the ith bit of string IS is zero (as i /∈ S), thus if the hash key hk was (perfectly) binding
at position i then there will not exist any proof π that proves that there exists a string x such that
Hhk(IS) = Hhk(x) the ith bit of x is 1. Thus, as before φvk,hk,h,N (w) = 0 for all indices in that range
and we can apply PWE index hiding security.

At a high level, the proposed paradigm is to first use the developed toolkit to turn formulae with hard-to-
compute satisfying inputs into formulae with only range-restricted satisfying inputs, then use PWE security
to cut through the range of inactive inputs, and finally switch back to original formulae using our toolkit.
We believe that such a methodology will find more applications especially in bringing more primitives based
on obfuscation to the assumption of (positional) witness encryption. Finally, we talk about the new ABO
signature constructions that we provide.

12Technically one could visualize the proof π as only proving that the ith bit of pre-image is m[i]. The fact that it also proves
that the message hashes to Hhk(m) is just due to the structure of the proof.

6



ABO Signatures from Standard Assumptions. In this work we give two new pathways to build ABO
signatures. First, we show that an ABO signature scheme can be generically built from any verifiable random
function (VRF) [MRV99] and a perfectly-binding (non-interactive) commitment scheme. Second, we show
that any identity-based encryption (IBE) scheme [Sha85, BF01], that is anonymous [BBDP01] as well as
allows efficient key verifiability, also leads to an ABO signature scheme. VRFs can be based on a wide variety
of assumptions such as decision-linear over bilinear maps as well as RSA-like assumptions [MRV99, HJ16]
and perfectly-binding (non-interactive) commitment schemes can be based on assumptions such as DDH,
LWE and LPN [GHKW17] and perfectly injective OWFs. IBE schemes with such verifiability and anonymity
properties can be based on simple assumptions over bilinear maps as well as LWE [BW06b, SKOS09, ABB10,
LSJ+11, GKW17a, WZ17]. Thus this leads to new constructions of ABO signatures. We also point out that
ABO signatures can be built from constrained signatures [BZ14] and splittable signatures [KLW15] which
have been constructed under iO and OWFs. Constrained signatures have also been constructed from non-
interactive witness indistinguishable proofs and perfectly binding commitments [BZ14].

We now briefly highlight the main ideas to build these from VRFs. A VRF is like a pseudorandom
function (PRF) in which the secret key holder can also prove correctness and uniqueness of PRF evaluation.
Concretely, using the secret key sk, it could efficiently evaluate the function Fsk(¡) on any input x as well
as generate a proof π of the statement y = Fsk(x). An ABO signing key will simply correspond to the
VRF secret key sk, and the ABO verification key will contain the VRF verification key vk as well as a
commitment COM. Here COM commits to 0 during standard setup, whereas during punctured setup (with
message x∗) COM commits to 1 where the random coins used are Fsk(x

∗). A signature σ for any message
x will simply correspond to its function evaluation y = Fsk(x) as well as corresponding proof π. While
verifying a message-signature pair x, (y, π) w.r.t. key (vk,COM), the verifier checks two things — (1) π
proves that y is a correct evaluation on input x, and (2) COM does not match the commitment of bit 1
obtained using y as randomness. Clearly this scheme satisfies the ABO scheme correctness condition if the
underlying commitment scheme is perfectly binding as in case of normal setup, condition (2) will never be
satisfied. Both our ABO constructions are provided later in Section 5.

Lastly, one might think that the full power of ABO signatures is not needed to build the above Broadcast
and Trace system. Instead a restricted version where the message space is fixed to be {1, 2, . . . , N} might
suffice. It turns out that such a restricted ABO signature scheme can be directly constructed from any SPB
Hash function and length doubling pseudo-random generator (PRG). The idea is to sample an SPB hash key
hk, random Ν bit strings si for each message i ∈ [N ] during setup. The verification key consists of the hash
key hk and a hash value h, where h is computed as the SPB hash on the set {ti = PRG(si)}i. The signature
on message i consists of (si, πi) where πi is the SPB hash opening of hash h on index i. The verification
procedure first checks correctness of the hash proof πi, and then also checks that PRG(si) is ith block value.
For punctured setup at index i∗, the algorithm changes the following — 1) it samples SPB hash hk to be
binding at index i∗, 2) it samples ti∗ uniformly at random from {0, 1}2λ. With all-but-negligible probability,
ti∗ will lie outside the range space of PRG, therefore no valid signature for i∗ would exist under punctured
setup.

However, such an ABO scheme can only be used to build a Broadcast and Trace system in which the
numbers of users is a-priori (and polynomially) bounded. A more desirable setting would be where the
number of users that can be supported is exponential (i.e., unbounded), while allowing the encryptor to
choose any polynomial sized (a-priori unbounded) subset of users to broadcast to. Such a Broadcast and
Trace system would still require the full power of ABO signatures, thus we stick to the more general setting.

2 Preliminaries

Notations For a probability distribution D, we denote by x ← D that x is sampled according to D. If
S is a set, y ← S denotes that y is sampled from S according to the uniform distribution on S. We use
[m,n] to denote the set of contiguous integers {m, . . . , n} for some m,n ∈ Z. For simplicity, we simply use
[n] to denote the set [1, n] = {1, . . . , n} for any n ≥ 1. We sometimes slightly abuse notation and refer to
bit strings in {0, 1}` by integers, where the left most bit of x ∈ {0, 1}` is considered as the most significant

7



bit. For any set S, we denote the size of the set of |S|. We denote security parameter by Îť in the rest of the
paper. For any bit string t, we denote that int(t) as the integer representation of string t.

2.1 Positional Witness Encryption

In this section, we formally define Positional Witness Encryption (PWE) [GLW14] and list its correctness
and security properties. The encryption system is defined for an NP language L and a message space
{MΝ}Ν. Let R(¡, ¡) be t";"""date"",""2019-01-13T17:52:08Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2019-01-13T17:52:08Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.19 (TeX Live 2018) kpathsea version 6.3.0""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2019-01-13T17:52:08Z""
""created"",""2019-01-13T17:52:08Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-01-13T17:52:08Z""
""resourceName"",""031.pdf""
""Author"",""""
""producer"",""pdfTeX-1.40.19""
""pdf:docinfo:producer"",""pdfTeX-1.40.19""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""3"",""2"",""7"",""3"",""2"",""8"",""3"",""8"",""0"",""3"",""17"",""15"",""8"",""26"",""23"",""53"",""8"",""17"",""12"",""9"",""23"",""13"",""30"",""0"",""10"",""11"",""34"",""4"",""0"",""0"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2019-01-13T17:52:08Z""
""Last-Modified"",""2019-01-13T17:52:08Z""
""dcterms:modified"",""2019-01-13T17:52:08Z""
""title"",""""
""Last-Save-Date"",""2019-01-13T17:52:08Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2019-01-13T17:52:08Z""
""meta:save-date"",""2019-01-13T17:52:08Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.19 (TeX Live 2018) kpathsea version 6.3.0""
""Content-Length"",""547345""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""34""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""3021"",""3404"",""4169"",""3919"",""4464"",""3551"",""4004"",""2765"",""2283"",""2505"",""2149"",""2345"",""2394"",""2215"",""2058"",""2825"",""2874"",""1979"",""3166"",""3368"",""2777"",""2702"",""3523"",""2902"",""3249"",""3105"",""3090"",""2857"",""2175"",""2716"",""2816"",""2728"",""2807"",""1290""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-01-13T17:52:08Z""
";https://scholar.google.com/scholar?start=980&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094546-677;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Alternative Digital Signature Schemes In Blockchain;F Yavuzyi?it ;2019 openaccess.hacettepe.edu.tr;;"… “top” (or “tip”) is the most recent block. In blockchain structure, the identifier of each block is its

hash value, generated using crypto … Having the most common usage in this area, Bitcoin is an

application of blockchain. Blocks … Bitcoin is a cryptocurrency ecosystem on its own. It …";Autres articles;Version HTML;[PDF] hacettepe.edu.tr;http://www.openaccess.hacettepe.edu.tr:8080/xmlui/bitstream/handle/11655/9430/SON.pdf?sequence=1;"
ALTERNATIVE DIGITAL SIGNATURE SCHEMES

IN BLOCKCHAIN

BLOK ZİNCİRDE

ALTERNATİF DİJİTAL İMZA ŞEMALARI

FAHRETTİN YAVUZYİĞİT

ASSOC. PROF. DR. OĞUZ YAYLA

Supervisor

Submitted to

Graduate School of Science and Engineering of Hacettepe University

as a Partial Fulfillment to the Requirements

for the Award of the Degree of Master of Science

in Mathematics

2019





To the memory of my mother Kamile YAVUZYİĞİT







ABSTRACT

ALTERNATIVE DIGITAL SIGNATURE SCHEMES IN

BLOCKCHAIN

Fahrettin YAVUZYİĞİT

Master of Science, Department of Mathematics

Supervisor: Assoc. Prof. Dr. Oğuz YAYLA

June 2019, 51 pages

This thesis is a study on authentication methods of Bitcoin ecosystem which is an application

of blockchain. Firstly, the facilities given by Bitcoin along with its security requirements are

examined from a perspective that can be used in place of today’s banking system. Bitcoin

ecosystem is a use case of blockchain and its current transaction authentication methods are

well studied in the literature, and based on this, the questions are raised, ""Could the common

account and the proxy concepts of banking services also be possible in Bitcoin?"". Many

researches say that there are solutions based on bilinear pairings commonly, accountable

subgroup multi-signature and delectable credentials schemes. These schemas are studied in

this thesis. As a first alternative, accountable subgroup multi-signature (ASM) constructed

from Boneh – Lynn – Shacham (BLS) signature schemes gives us the opportunity of the

public key aggregation mechanism. In this way, it can be possible that more than one user

sign the same message jointly and only one public key is needed to verify the signature. This

approach allows lots of savings in storage of public keys in transaction scripts and that is

quite convenient to implement in Bitcoin. For the second alternative, delectable credentials

signature schema renders possibility that someone can give her signing authority to another.

Delegatable credentials can do this with a structure that is built on Groth and Schnorr signa-

ture schemes. Furthermore, the suggested delectable credential schema in this thesis is able

to store in secret or disclosed within the signature. This property is included in the usage

scenarios about need of delegation for individuals.

i



Keywords: Block Chain, Bitcoin, transaction, authentication, multi signature, accountable

subgroup multi signature, delegatable credentials.

ii



ÖZET

BLOK ZİNCİRDE ALTERNAFİT DİJİTAL İMZA ŞEMALARI

Fahrettin YAVUZYİĞİT

YĂźksek Lisans, Matematik BĂślĂźmĂź

Tez Danışmanı: Doç. Dr. Oğuz Yayla

Haziran 2019, 51 sayfa

Bu tez, bir blok zincir uygulaması olan Bitcoin ekosisteminin kimlik doğrulama yöntemleri

üzerine bir araştırmadır. İlk olarak, bugünün bankacılık sistemi yerine kullanılabilmesi bakış

açısıyla, güvenlik gereksinimlerinin yanı sıra Bitcoinin sağladığı olanaklar sorgulanmıştır.

Bir blok zincir uygulaması örneği olan Blockchain ve kendisine ait mevcut kimlik doğru-

lama metotlarĹ araştĹrĹlmĹş, elde edilen bilgiler ßzerinden ""BankacĹlĹk hizmetlerinde bulunan

ortak hesap ve vekalet kavramlarÄą aynÄą zamanda Bitcoin de mĂźmkĂźn mĂźdĂźr?"" sorusu ortaya

atĹlmĹştĹr. Cevap olabilecek birçok araştĹrma arasĹndan, en yeni çalĹşmalardan olmasĹ ve or-

tak şekilde bilinear parings kullanĹyor olmalarĹ sebebiyle hesap verebilir altgrup çoklu imza

ve devredilebilir yetki şemaları detaylı şekilde araştırılmıştır. İlk öneri olarak, hesap vere-

bilir altgrup çoklu imza yöntemi, açık anahtarların birleştirilmesine olanak sağlayan Boneh

– Lynn – Shacham (BLS) imzalama şeması üzerine inşa edilmiştir. Bu sayede birden fazla

kullanĹcĹnĹn aynĹ mesajĹ ortak şekilde imzalamasĹ ve bu imzanĹn yalnĹz bir açĹk anahtar ile

doğrulanması mümkün olabilmektedir. Bu yaklaşım, işlemler içinde açık anahtarların sak-

lanmasında tasarruf sağlamaya ve Bitcoin’e uyarlanmasının oldukça kolay olmasını sağla-

maktadır. İkincisi için çözüm olarak, delege edilebilir kimlikli imzalama yöntemi birinin

sahip olduğu imzalama yetkisini bir başkasına devredebilmesine olanak sağlamaktadır. Delege

edilebilir kimlik bu olanığı Groth ve Schnorr imzalama yapıları üzerine kurulan bir yapı ile

gerçekleştirebilmektedir. AynĹ zamanda bu tezde yer alan delege edilebilir kimlik şemasĹ

kullanĹcĹ Üzbilgilerini açĹkta veya gizli şekilde saklayabilmektedir. Bu Üzellik, tezimizin

bireysel delegasyon ihtiyacı üzerindeki kullanım örneğine dahil edilmiştir.

iii



Anahtar Kelimeler: Blok zincir, Bitcoin, işlem, kimlik doğrulama, çoklu imza, hesap vere-

bilir altgrup çoklu imzalama, delege edilebilir kimlik.

iv



ACKNOWLEDGEMENT

First of all, I would like to express my sincere gratitude to my supervisor Assoc. Prof. Dr.

Oğuz YAYLA for his invaluable suggestions, motivation, patience, and continuous support

in this thesis. His guidance helped me in all the time of research and writing of this thesis.

Besides my supervisor, I would like to thank the rest of my thesis committee: Prof. Dr. Evrim

AKALAN, Assoc. Prof. Dr. Murat CENK, Assoc. Prof. Dr. Sedat AKLEYLEK and As-

sist. Prof. Dr. Adnan ÖZSOY for their encouragement, insightful comments.

I would like to my special thank to my teacher dear Prof. Dr. Haşmet GÜRÇAY for always

believing and supporting me from bachelor to master degree.

Also, I’m grateful that my wife and daughter are in my life and with me in this process.

Thank you.

Fahrettin YAVUZYİĞİT

June 2019, Ankara

v



TABLE OF CONTENTS

Page

ABSTRACT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . i

ÖZET . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iii

ACKNOWLEDGEMENT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . v

TABLE OF CONTENTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vi

NOTATIONS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . x

1 INTRODUCTION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.1 Motivation for Writing This Thesis . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 Previous Works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.3 An Application of Blockchain, Bitcoin . . . . . . . . . . . . . . . . . . . . . 2

1.4 Suggestions for Bitcoin Transaction Authentication . . . . . . . . . . . . . . . 3

1.5 Outline of The Thesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2 BLOCKCHAIN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.1 Bitcoin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.2 Block Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.3 Transaction Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.4 Transaction Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.4.1 Pay To Public Key (P2PK) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.4.2 Pay To Public Key Hash (P2PKH) . . . . . . . . . . . . . . . . . . . . . . . . 12

2.4.3 Multisig (M-of-N Multi-Signature) . . . . . . . . . . . . . . . . . . . . . . . 14

3 ACCOUNTABLE SUBGROUP MULTI-SIGNATURE . . . . . . . . . . . . . 16

3.1 Bilinear Groups and Pairing Based Cryptography . . . . . . . . . . . . . . . . 16

3.2 Construction of ASM Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.3 Proof-of-Possession . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.4 Accountable-Subgroup Scheme with PoPs . . . . . . . . . . . . . . . . . . . . 22

3.5 Application ASM to Bitcoin . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

4 DELEGATABLE CREDENTIALS WITH HIDEABLE ATTRIBUTES . . . . 25

4.1 Practical Delegatable Anonymous Credentials System . . . . . . . . . . . . . 26

4.2 Signature Schemes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

4.2.1 Groth Structure-Preserving Signature Schema . . . . . . . . . . . . . . . . . . 27

4.2.2 Sibling Signatures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

vi



4.2.3 Constructing Sibling Signatures. . . . . . . . . . . . . . . . . . . . . . . . . . 29

4.3 Construction for Delegatable Credentials . . . . . . . . . . . . . . . . . . . . 30

4.4 Application of Delegatable Credentials to Bitcoin . . . . . . . . . . . . . . . . 33

5 CONCLUSION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

REFERENCES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

APPENDIX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

CURRICULUM VITAE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

vii



FIGURES

Figure 2.1. Converting public key to Bitcoin address . . . . . . . . . . . . . . . . . 7

Figure 2.2. Structure of a block . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

Figure 2.3. Structure of the header . . . . . . . . . . . . . . . . . . . . . . . . . . 8

Figure 2.4. Structure of a transaction . . . . . . . . . . . . . . . . . . . . . . . . . 8

Figure 2.5. Structure of a transaction output . . . . . . . . . . . . . . . . . . . . . 9

Figure 2.6. The transaction input structure . . . . . . . . . . . . . . . . . . . . . . 10

Figure 2.7. The unlocking and locking script combination . . . . . . . . . . . . . . 10

Figure 2.8. The P2PK script flow . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Figure 2.9. The P2PKH script flow . . . . . . . . . . . . . . . . . . . . . . . . . . 13

Figure 2.10. The m-of-n multisig script flow . . . . . . . . . . . . . . . . . . . . . . 15

Figure 4.1. The delegation chart . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

viii



LISTINGS

1 The Magma Codes of ASM Example . . . . . . . . . . . . . . . . . . . . . . . . 41

2 The Magma Codes of ASM with PoPs Example . . . . . . . . . . . . . . . . . . . 45

3 The pseudocode of presenting . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

4 The pseudocode of verifying . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

ix



NOTATIONS AND ACRONYMS

Notations
Z Integers

G Bilinear group generator

G Cyclic group

e Bilinear map

F Finite field

H Hash algorithm

$ Randomly generated

Acronyms
SHA-256 Secure Hash Algorithm with 256 bit version

RIPEMD-160 RACE Integrity Primitives Evaluation Message Diges with 160 bit

OP_CHECKSIG Operator that checks the signature validity

OP_DU Operator that duplicates the top stack element

OP_EQUAL Operator that checks either top two stack elements are equal

OP_HASH160 Operator that calculates SHA-256 + RIPEMD-160 hash

OP_0 Operator that pushes an empty array to the stack

OP_CHECKMULTISIG Operator that checks the signatures validity

ASM Accountable Subgroup Multi-Signatures

x



1 INTRODUCTION

1.1 Motivation for Writing This Thesis

Commercial relations, started with barter economy, have been continuing through banking

system that is most commonly used today. But in a globalized world, Bitcoin, a new payment

method brought by developing techniques and technologies in addition to different needs,

has a potential to replace the banking system we know. Although Bitcoin is currently only

a payment instrument, it may assume other functions in the banking system or come other

similar systems in the future.

The current Bitcoin system, used as a payment method, hosts some of the opportunities that

are accepted in the banking system. For example, Multi-signature, which allows Bitcoin

transactions to be signed by multiple users, corresponds to the common account in banking

system. In this thesis, studies on using Multisig, that is a type of transaction scripts, more

effectively and efficiently are examined. Also, the delegatable credential, which may be a

candidate as a signing method in Bitcoin system because of being equivalent to the transac-

tions carried out by proxy in banking, is studied.

1.2 Previous Works

Most used one of transaction scripts in Bitcoin ecosystem, even if Multisig can compress

the signature value, storing all public keys still take the major size in transactions. Multi-

signatures have been worked on different mathematical bases e.g. on RSA [19, 20], discrete

logarithm problem [21, 22, 5, 23, 6], parings [24, 25, 3], and lattices [26]. To reduce trans-

action sizes, the aggregating public-key algorithm has been clearly handled only in [6] and

[3]. The ""public-key aggregation"" is named firstly in the work of Maxwell [6]. With the

public-key aggregation, it can be enough that only the aggregated value of all public keys is

stored in transaction instead of them separately. According to [6], in signing stage, there is

a need for two tour of transmission between all signers. But one round of transmission can

be enough by [3]. With the name of ""Accountable subgroup multi-signatures (ASM)"", this

approach was firstly worked by Micali, Ohta and Reyzin [5]. In addition to not having key

1



aggregation algorithm, it bases on discrete logarithm problem and constructed from [18].

Boneh, Drijvers and Neven [3] take it to the next level via adding key aggregation and using

parings further.

There are some works on delegatable anonymous credentials [27, 28, 29, 30]. Chase and

Lysyanskaya [29] uses generic zero-knowledge proofs. By this approach, the size must grow

exponentially by the number of delegators. Therefore, this complexity limits the delegation

process and using this method practically is not possible. ""Hierarchical group signatures"" by

Trolin and WikstrĂśm [31] are an addition to the group signatures. This methods gives the

opportunity that includes a hierarchy of group managers. Users can sign a message for the

group with the credential of any managers. This property can be considered as a ""delegatable

credentials"". But, it differs from the suggested one in this thesis, because users are able to

do as a manager or as a user, not both of them, as only one. And, the managers can disclose

the signers in contrary to the anonymity.

1.3 An Application of Blockchain, Bitcoin

Blockchain is a kind of data structure. It can store data and connects one to another by link-

ing. To link the blocks, hash algorithm SHA-256 which is a cryptographic, namely mathe-

matical, method is used. Informally, lets think three number of blocks (Block-X, Block-Y,

Block-Z). The hash value of whole Block-X is stored in the Block-Y, and using the same,

whole Block-Y’s hash value is stored in the Block-Z. In this way, Block-X is linked to Block-

Y and Block-Y is linked to Block-Z. If there is an any change in Block-X, because of that it

results in change of Block-X’s hash value, Block-Y, which holds the hash of Block-X, will

also be altered. Likewise, any change in Block-Y affects Block-Z. In a situation where there

is a huge number of blocks, altering must be done from first changed block to the last one

and this process may be almost impossible in some specific hashing conditions.

Bitcoin ecosystem bases on this limitation. The blocks store data about the information that

an amount of Bitcoin have been transferred someone to another by the name of ""transaction"".

With the unchangeable data structure property, Bitcoin ecosystem gives an assurance to users

about keeping their assets. But there is another issue, which is authenticating transactions.

It may be more important that an amount of transaction is spent or transferred by real owner

2



than storing it safely. To authenticate transactions, another cryptographic method, digital

signing, is used. Unlike the general usage of digital sign, the ownership of a digital asset in

Bitcoin is not proved via signed by owner of asset, merely it must be signed by the previous

owner and new owner’s public key must be stored in it. To illustrate this, the paper check

example can be given. Using paper check payment method, signer is not owner of the money

currently, owner is whose name has been written on “Pay to the order of” field. In Bitcoin

system, to spend amount of Bitcoin, owner must give a valid signature that is signed using

the private key matching the public key which is stored in previous transaction. This ap-

proach allows two benefits, privacy and decentralization of authentication process. Because

of that no-one knows whose transaction specific public key is, privacy of Bitcoin ownership

is provided. And, there is not any need for certificate authority, so Bitcoin transactions are

decentralized. There is an only assurance for reliance the Bitcoin system. That is strong and

efficient transaction signing and validation mechanism. Bitcoin ecosystem has many kinds

of transaction authentication standards. Some of those are ""Pay To Public Key (P2PK)"",

""Pay To Public Key Hash (P2PKH)"" and ""Multisig"".

1.4 Suggestions for Bitcoin Transaction Authentication

Multisig is used for multi-ownership of Bitcoin amount or extra security needs by adding

another factor of authentication like Bitcoin wallet etc. in case of stolen individuals’ private

keys. Multisig has a bulky structure. It is described in Section 2.4.3 in detail. From this

point, ""Accountable Subgroup Multi-Signature (ASM)"" is a potential solution for improving

multi-signature need of Bitcoin. Rather than having necessity of keeping all public keys in

Multisig, ASM gives the opportunity that only one aggregated key which is the combination

of all signers’ public key can be enough to store in transaction. This gives a lot of data

and computational saving. In addition, accountability property of ASM provides another

security need. Owing to this property, all group members are responsible for the transactions

signed by a subgroup. In this way, the possibility of other group members repudiating the

transactions, committed by the subgroup of users, is eliminated.

The suggested ASM schema in [3] is constructed from ""Boneh – Lynn – Shacham (BLS)""

signature scheme [17] which is based on bilinear pairings. ASM schema has additional two

3



stages ""Key Aggregation"" and ""Group Setup"" to common signing protocols. With Key Ag-

gregation stage, the aggregated public key ”apk” is generated. In Group Setup, for all group

members, the membership keys ”mki” obtained from all members’ public and secure key

are generated. So, the accountability is provided because the membership keys are needed

in Signing stage.

Delegatable credentials is the suggestion that is not currently in Bitcoin ecosystem but can

be a solution to diversity needs of Bitcoin transaction authentications. As an example, to

visualize a need, let a firm make their payments through the Bitcoin. If the firm’s pay-

ments is needed to be done by more than one person, payment processes must be divided

to departments or employers. To do this, the firm either should share the Bitcoin confiden-

tial information like secret key and/or wallet ID and password or authorize the responsible

persons via delegating the owner’s credential.

The suggested schema [16] has four stages ""Setup"", ""Delegate"", ""Present"" and ""Verify"".

Setup is used for parameter generation, Delegate stage is for delegate the credential owned

to another user, Present is signing a massage or etc. by a delegate and generates the signature

by the name ""attribute token"" in this schema, Verify is matching the signature and message

with the attribute token value and only first delegator’s public key, described in detail in

Section 4.3. To the schema, any wanted attributes - e.g. name, gender, age, working position,

authority level etc. - of all delegates can be stored into attribute token or they can be hidden.

In this work, Groth and Schonorr signatures are combined and this combination is used with

sibling signature method, a new method first given in [16]

1.5 Outline of The Thesis

The rest of the thesis is organized as follows. In Chapter 2, the concept of blockchain is

introduced and Bitcoin ecosystem , a case study of blockchain, is briefly described up to

the transactions stage in a view of how its transaction authentication mechanisms work. In

Chapter 3, accountable subgroup multi-signature schema, which is a suggestion instead of

Bitcoin multi-signature, is given in detail. In Chapter 4, as a new authentication mechanism

that is likely to be included in Bitcoin ecosystem, delegatable credentials with concealable

attributes is suggested. Finally, the conclusions are included in Chapter 5.

4



2 BLOCKCHAIN

The blockchain is a data structure that is ordered and linked list of blocks. Blocks are linked

back each one referring to the previous one. In this way, the linked blocks create a chain,

that is why we call it blockchain. The blockchain data can be stored in a file like a simple

text file and also in a database. The blockchain can be considered as a stack that is left to

right, with blocks linked to top of next one and the initial block being the base of chain. In

blockchain terminology, “height” means the number of blocks from the initial block, and

“top” (or “tip”) is the most recent block.

In blockchain structure, the identifier of each block is its hash value, generated using crypto-

graphic hash algorithm SHA256 and stored in the header of the block. Besides, every block

refers the previous one, with the name of parent block, and the block header also has the par-

ent block hash. Connecting every block to its predecessor with hash values creates a chain,

that goes back the initial block.

It is possible that there can be more than one block whose parent’s hash value is same.

Namely, a block can possess more than one child. However, having only one parent hash

value field, there can be only one parent block. If a block has multiple children, that is

known as blockchain “fork,” which comes accidentally when different miners connects one

each new block to the same almost meanwhile. Finally, only one block is accepted as a part

of the chain and hence the fork situation is eliminated.

Since the predecessor block hash is stored in the block header, it affects the hash value of

current block. This means that if predecessor’s hash value changes, the child’s hash value

also changes. Altering the any value of parent block causes to change the predecessor’s hash.

The predecessor’s changed hash requires to change the previous block link of the successor

which is the hash value of it. This also results in the successor’s hash to alter, which requires

a change in the link of the two-next successor, which in order altering it, and so on. This

cascade effect ensures that when a block has many followers, it cannot be altered without

recalculation of all successor blocks. This needs huge computational power, so being a long

chain of blocks gives us the unreversibility property of the blockchain, that is one of the most

important properties of blockchain’s security [1].

5



2.1 Bitcoin

Having the most common usage in this area, Bitcoin is an application of blockchain. Blocks

are used for storing Bitcoin transactions that contains the information about sent amount of

Bitcoin from someone to someone. Bitcoin is a cryptocurrency ecosystem on its own. It

gives much opportunity to use money in a different way that we did ever. To illustrate, lets

see the similarity of Bitcoin transactions to banking checks. The Bitcoin address is for the

receiver identification, the beneficiary in banking terms, that is written on “Pay to the order

of”. The checks do not require a specific account, it can be the name of a bank account

holder, corporations, institutions, or even cash. The Bitcoin transaction usage is similar, the

Bitcoin address gives the bitcoin ecosystem flexibility. A Bitcoin address represents whose

the public key is.

Bitcoin Addresses

The Bitcoin address is a string value which is a character set, and it is used for receiving

money. Bitcoin addresses are generated from public keys. A Bitcoin address looks like:

19WVyUJ75rboXZymdgQdx3HENYWK7fsLpE.

Bitcoin address is generated from the signer’s public key using cryptographic hash functions.

In many stage, the hash functions are also needed. For example, they are also in script

addresses, and mining process etc. ""Secure Hash Algorithm (SHA)"" and ""RACE Integrity

Primitives Evaluation Message Digest (RIPEMD)"", especially SHA-256 and RIPEMD-160,

are used to generate the Bitcoin addresses.

With public key pk, first it is calculated using the SHA-256 and then the RIPEMD-160 of

the first result:

A = RIPEMD-160(SHA-256(pk))

Bitcoin addresses are generally encoded the format Base58Check (“Base58 and Base58Check

Encoding”), that contains 58 number of characters and a check-sum to guarantee ease of

spelling. Figure 2.1 gives the conversion in a chart.

6



Figure 2.1: Converting public key to Bitcoin address

Example 2.1. bitcoin’s Base58 alphabet

123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz

2.2 Block Structure

In the blockchain, a block contains data structure of collected transactions as a ledger, which

is kept public. Specifically, a block consists of a header including metadata about the block,

and a transactions list that occupies the majority of block size. Figure 2.2 shows the block

structure.

Figure 2.2: Structure of a block

7



Block Header

The block header has three kinds of metadata. First, a previous block hash field, which

connects the block to the predecessor. The second is for difficulty, timestamp, and nonce

fields which are required in the mining process. The third one is ""the Merkle tree root"", that

is a structure and is to digest the transactions in a block. Figure 2.3 shows the content of a

block header.

Figure 2.3: Structure of the header

2.3 Transaction Structure

A transaction is an information which records a transfer of Bitcoin amount from the source,

named input, to the destination, named output. Any kind of account is not used in generating

the input or output, only Bitcoin address is required personally. Bitcoins are locked with a

Bitcoin address that only person, owner or who knows it, be able to unlock. Figure 2.4 shows

the fields in a transaction.

Figure 2.4: Structure of a transaction

8



Transaction Outputs

Bitcoin transactions has outputs and they are stored in Bitcoin ecosystem. Pretty much of

all outputs create spendable Bitcoin called unspent transaction outputs (UTXO). The whole

network recognizes them and the owner can spend in later transactions. When transferring

Bitcoin to someone, the ""unspent transaction output (UTXO)"" is registered to receivers Bit-

coin address and ready to a next transfer.

A transaction output consists of two parts listed below.

• An amount of transferred bitcoin.

• A locking script that locks this amount and concern us fundamentally in this thesis.

Figure 2.5: Structure of a transaction output

Transaction Inputs

Transaction input is the pointer which links between the current transaction and previous

UTXO. It points to UTXO by reference to the transaction hash and sequence number where

the UTXO is recorded in the blockchain. In addition, the transaction input includes unlocking

script that meets the locking script. The unlocking script is generally a proof of the signature

ownership. Figure 2.3 shows the structure of a transaction input.

2.4 Transaction Scripts

When a new transaction is broadcast to the network to be included in the blockchain, each

node, aware of the transaction, validates it by evaluating the challenge and response scripts.

Most common three types of transaction scripts are below.

9



Figure 2.6: The transaction input structure

Script Construction (Lock + Unlock)

The validation of Bitcoin transaction process depends on two types of scripts, locking and

unlocking. A locking script is a hypothec on output, and it sets the conditions that must be

met to spend the output when spending an amount of bitcoin.

An unlocking script is to meet the conditions placed on an output by a locking script and

allows the output to be spent. Unlocking scripts are part of every transaction input, and

mostly they include a digital signature generated with the user’s private key.

Figure 2.7: The unlocking and locking script combination

2.4.1 Pay To Public Key (P2PK)

Pay-to-public-key is a simpler form of a Bitcoin payment than other methods. A pay-to-

public-key locking script is handled as:

<Public Key of A> OP_CHECKSIG

10



OP_CHECKSIG is an ECDSA signature verification procedure to check whether the signa-

ture of a user A is valid for a given public key in a transaction locking script.

The unlocking script is a simple signature:

<Signature by Private Key of A>

The combined script, to be validated, is:

<Signature by Private Key of A> <Public Key of A> OP_CHECKSIG

It is computationally hard to obtain the private key from the public key in an acceptable

time period. So the public key is safely used as an address for receiving Bitcoin payments.

In P2PK script template, public keys are called P2PK addresses. But nowadays, to ensure

better security P2PK addresses are left in place to P2PKH addresses [1, 2].

Figure 2.8: The P2PK script flow

11



2.4.2 Pay To Public Key Hash (P2PKH)

The most common type of transaction script in the Bitcoin network is P2PKH script tem-

plate. It’s locking script contains a public key hash instead of a plain public key as a Bitcoin

address. Therefore, the public key must be presented to unlock amount of Bitcoin and also a

digital signature created by the corresponding private key.

To illustrate P2PKH script template with an example, let Alice pay to Bob’s Cafe. Alice

made a payment of 0.015 Bitcoin to the Bitcoin address of the cafe. The locking script of

transaction output would be like:

OP_DUP OP_HASH160 <Cafe Public Key Hash> OP_EQUAL OP_CHECKSIG

Cafe Public Key Hash is the Bitcoin address of the cafe. The unlocking script corresponding

to the locking script is:

<Cafe Signature> <Cafe Public Key>

The validation script is as given below

<Cafe Signature> <Cafe Public Key> OP_DUP

OP_HASH160 <Cafe Public Key Hash> OP_EQUAL OP_CHECKSIG

This combined script’s execution results TRUE if the unlocking script matches the conditions

set by the locking script. In particular, the result will be TRUE if the unlocking script has a

valid signature generated by the cafe’s private key that corresponds to the public key hash set

as a hypothec. Figure 2.9 shows a step-by-step execution of the combined script to validate

the transaction [1, 2].

12



Figure 2.9: The P2PKH script flow

13



2.4.3 Multisig (M-of-N Multi-Signature)

In multi-signature script template, to release the hypothec, N public keys are recorded in the

locking script and at least M of N must match the corresponding signatures. This is also

called as an M-of-N scheme, where N is the total number of keys and M is the threshold

value of signatures required for validation.

To illustrate multi-signature script template with an example, a 2-of-3 multi-signature re-

quires that three public keys are listed as signers group, to create a valid transaction to spend

an amount of bitcoin, at least two of which must be used to create signatures. Standard mul-

tisignature scripts may have some limitation, e.g. at most 15 listed public keys, meaning you

can use maximum 15-participants group of signers. The maximum number can be adjusted

according to improvement in computational power in time.

The general form of a locking script setting an M-of-N multi-signature condition is:

M <Public Key 1> <Public Key 2> ...<Public Key N> N OP_CHECKMULTISIG

where N is the total number of public keys and M is the value that minimum number of

signatures is required to spend the output. For example, in a 2-of-3 multi-signature, the

locking script is:

2 <Public Key A> <Public Key B> <Public Key C> 3 OP_CHECKMULTISIG

The corresponding unlocking script that contains two signatures is:

OP_0 <Signature B> <Signature C>

or the other two-combination of signatures associated with declared three public keys. Hence,

the validation script is:

OP_0 <Signature B> <Signature C> 2

<Public Key A> <Public Key B> <Public Key C> 3 OP_CHECKMULTISIG

14



If two signatures in the un";"""date"",""2019-07-24T07:06:11Z""
""pdf:PDFVersion"",""1.6""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:docinfo:title"",""""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.6""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""xmp:CreateDate"",""2019-07-23T11:05:19Z""
""modified"",""2019-07-24T07:06:11Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""xmp:ModifyDate"",""2019-07-24T10:06:11Z""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017) kpathsea version 6.2.3""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2019-07-23T11:05:19Z""
""created"",""2019-07-23T11:05:19Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-07-23T11:05:19Z""
""resourceName"",""SON.pdf""
""Author"",""""
""producer"",""pdfTeX-1.40.18""
""pdf:docinfo:producer"",""pdfTeX-1.40.18""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""3"",""0"",""0"",""4"",""14"",""1"",""3"",""3"",""0"",""0"",""0"",""3"",""17"",""0"",""2"",""4"",""33"",""4"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2019-07-23T11:05:19Z""
""Last-Modified"",""2019-07-24T07:06:11Z""
""dcterms:modified"",""2019-07-24T07:06:11Z""
""title"",""""
""xmpMM:DocumentID"",""uuid:bd79d059-17e7-4d61-af4f-78eb2ac1b339""
""Last-Save-Date"",""2019-07-24T07:06:11Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2019-07-24T07:06:11Z""
""meta:save-date"",""2019-07-24T07:06:11Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017) kpathsea version 6.2.3""
""Content-Length"",""3580048""
""Content-Type"",""application/pdf""
""xmp:MetadataDate"",""2019-07-24T10:06:11Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""pdf:producer"",""pdfTeX-1.40.18""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""67""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""313"",""0"",""40"",""0"",""0"",""1609"",""129"",""1778"",""131"",""691"",""1642"",""386"",""662"",""229"",""589"",""1808"",""2063"",""2132"",""2020"",""1990"",""1559"",""429"",""741"",""1160"",""695"",""601"",""1120"",""29"",""1350"",""165"",""1508"",""1162"",""1680"",""799"",""867"",""1458"",""1065"",""1206"",""221"",""2136"",""1505"",""1421"",""879"",""1470"",""1221"",""1416"",""1238"",""1439"",""187"",""2015"",""191"",""1727"",""1736"",""1886"",""443"",""711"",""751"",""1063"",""789"",""800"",""650"",""827"",""953"",""36"",""35"",""0"",""464""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-07-23T11:05:19Z""
";https://scholar.google.com/scholar?start=490&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094649-1113;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;RKA security of identity-based homomorphic signature scheme;J Chang, H Ma, A Zhang, M Xu, R Xue ; IEEE Access, 2019  ieeexplore.ieee.org;;"… and then gave an ingenious implement in the random oracle (RO) model based on the bilinear

map and the assumption of computational Diffie-Hellman (CDH). In addition, they also claimed

that their scheme is very suitable to be used in the hot research field of blockchain …";Cité 9 fois;Les 2 versions;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/6287639/6514899/08676234.pdf;"
		
	";"""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""dc:title"",""IEEE Xplore Full-Text PDF:""
""Content-Encoding"",""UTF-8""
""resourceName"",""08676234.pdf""
""language"",""es""
""Content-Length"",""2565""
""title"",""IEEE Xplore Full-Text PDF:""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=930&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094661-1165;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;New construction of blind signatures from braid groups;L Wang, Y Tian, Y Pan, Y Yang ; IEEE Access, 2019  ieeexplore.ieee.org;;"… A is a probabilistic polynomial-time algorithm that receives input p, q and has access to two oracles

— the matching conjugate oracle Omc(ˇ) and the challenge oracle Och() — and wants to win the

experiment. FIGURE 1. One-more matching conjugate experiment …";Cité 1 fois;;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/6287639/8600701/08664179.pdf;"
		
	";"""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""dc:title"",""IEEE Xplore Full-Text PDF:""
""Content-Encoding"",""UTF-8""
""resourceName"",""08664179.pdf""
""language"",""es""
""Content-Length"",""2565""
""title"",""IEEE Xplore Full-Text PDF:""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=980&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094665-1178;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Ouroboros crypsinous: Privacy-preserving proof-of-stake;T Kerber, A Kiayias, M Kohlweiss… ; 2019 IEEE Symposium …, 2019  ieeexplore.ieee.org;;"… THE MODEL Following the recent line of works proving composable security of blockchain ledgers

[2], [1] we provide our protocol and security proof in Canetti's universal composition (UC)

framework [8]. In this … A global random oracle GRO for abstracting hash function queries …";Cité 35 fois;Les 14 versions;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/8826229/8835208/08835272.pdf?casa_token=hwF_SCYX3VsAAAAA:vz4N8uXkDJmfTQCV46JKuT0KqOD969_TD-tYIpeA4_yvVFyQC_LO87KZZROmAWq2PABfkQDgnI4;"
		
	";"""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""dc:title"",""IEEE Xplore Full-Text PDF:""
""Content-Encoding"",""UTF-8""
""resourceName"",""08835272.pdf""
""language"",""es""
""Content-Length"",""2533""
""title"",""IEEE Xplore Full-Text PDF:""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=420&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094612-951;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[PDF][PDF] Blocked-Chain: The Application of the Unauthorized Practice of Law to Smart Contracts;S Templin ; Geo. J. Legal Ethics, 2019  HeinOnline;;"… Securities and Exchange Commission brought an enforcement action against a crypto token

trading … This confinement is attributable to the fact that oracles, necessary mid- dleware that … 3s

The automatic performance of smart contracts based on blockchain technology inherently …";Cité 5 fois;Les 2 versions;[PDF] heinonline.org;https://heinonline.org/hol-cgi-bin/get_pdf.cgi?handle=hein.journals/geojlege32&section=48&casa_token=zCUrUFw0U1kAAAAA:5vqx-PqFqKRTpFTkWhXEmIEQV9NUOqTKmf2tPmFZLuhKcgoikieIunJWDTG3uqB-NQg4Usg;"

 ";"""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""REFRESH"",""1; url=https://heinonline.org/HOL/Page?handle=hein.journals/geojlege32&div=48&g_sent=1&casa_token=zCUrUFw0U1kAAAAA:5vqx-PqFqKRTpFTkWhXEmIEQV9NUOqTKmf2tPmFZLuhKcgoikieIunJWDTG3uqB-NQg4Usg""
""Content-Encoding"",""UTF-8""
""resourceName"",""get_pdf.cgi""
""language"",""""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=770&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094574-797;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[PDF][PDF] Blockchain, la tokenización de la economia y democratización de la inversión;N Guarín Cardona ;2019 core.ac.uk;;"… Hoy blockchain trae con ello un nuevo repertorio; algoritmos de consenso, contratos

inteligentes, cuentas distribuidas, oracles, billeteras digitales, tokens, llaves públicas

y privadas”, y agregaría ICOs, STO, IEO y cripto-economías …";Autres articles;;[PDF] core.ac.uk;https://core.ac.uk/download/pdf/237483403.pdf;"
1 

 

 

BLOCKCHAIN, LA TOKENIZACIÓN DE LA 

ECONOMÍA Y DEMOCRATIZACIÓN DE LA 

INVERSIÓN 
 

 

 

 

 

         
 

 

 

 

 

AUTOR: NICOLÁS GUARÍN CARDONA 

 

                                                     TUTOR: MARC ROCAS 

 

 

 

 

 

 

 

 

                                                     Septiembre/4/2019 

 

                     TRABAJO FIN DE MASTER-PROYECTO DE INVESTIGACIÓN 



2 

 

Agradecimientos 

 

 

Agradezco a mis padres por el gran esfuerzo que hicieron por darme la oportunidad de 

estudiar en el exterior. Agradezco a Alejandra por todo el amor y apoyo incondicional. Han 

sido el motor de mi esfuerzo y superaciĂłn. 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 



3 

 

Resumen 

El objetivo de este trabajo es, por medio de una investigaciĂłn, entender e identificar los 

efectos de la tecnologĂ­a blockchain y la tokenizaciĂłn de la economĂ­a. Comprender como 

blockchain abre una nueva economĂ­a digital por medio de criptomonedas y tokens. 

Identificar su estructura, atributos y caracterĂ­sticas propias. 

 

AdemĂĄs, analizar el efecto de los tokens contratos inteligentes para potencializar nuevos 

modelos de negocio en un sistema de activos programables. Por Ăşltimo, estudiar cĂłmo esta 

tecnologĂ­a puede ayudar a emprendedores a obtener financiaciĂłn y a la vez darle la 

oportunidad a un pĂşblico general de pequeĂąos inversionistas de ser incluidos y captar valor 

a partir de proyectos en sus fases iniciales. 

 

 

The objective of this work is, through research, to understand and identify the effects of 

blockchain technology and tokenization of the economy. Understanding how blockchain 

opens a new digital economy through cryptocurrencies and tokens. Identify its own structure, 

attributes and characteristics. 

In addition, analyze the effect of smart contracts tokens to potentialize new business models 

in a programmable asset system. Finally, to study how this technology can help 

entrepreneurs obtain financing and at the same time give the opportunity to the general 

public of small investors to be included and capture value from projects in their initial stages. 

 

 

 

 

 

 

 

 

 

 

 

 



4 

 

Glosario 

 

Bitcoin: Un sistema de efectivo electrĂłnico de usuario a usuario. Bitcoin con B mayĂşscula 

se refiere al protocolo y plataforma de pagos descentralizada. 

 

bitcoin: El token que circula en el protocolo Bitcoin; La unidad de intercambio nativa. 

 

Blockchain: La cadena de bloques es un registro pĂşblico de las transacciones Bitcoin en 

orden cronolĂłgico. La cadena de bloques se comparte entre todos los usuarios de Bitcoin. 

Se utiliza para verificar la estabilidad de las transacciones Bitcoin y para prevenir el doble 

gasto. 

 

P2P: Por sus siglas en inglĂŠs (Peer to Peer) Punto a punto o tambiĂŠn llamado de usuario a 

usuario. Se refiere a los sistemas que trabajan como una organizaciĂłn colectiva. 

permitiendo que cada individuo interactĂşe directamente con otros. En el caso de Bitcoin, la 

red se construye de tal manera que cada usuario estĂĄ transmitiendo transacciones de otros 

usuarios. Y algo muy importante, ningĂşn banco se requiere como intermediario. 

 

FOSS: Por sus siglas en inglĂŠs, free open software. Software que puede ser usado 

gratuitamente y desarrollado de forma transparente. 

 

Cripto activos: Un cripto activo es un activo digital que depende primordialmente de 

criptografĂ­a y tecnologĂ­a blockchain o similar; que no estĂĄ emitida por una autoridad pĂşblica 

o banco central y que puede utilizarse como medio de intercambio, con fines de inversiĂłn o 

para acceder a un producto o servicio en unas determinadas condiciones. 

 

Criptomoneda: Es una categorĂ­a de los cripto activos, cuya funciĂłn principal es operar 

como medio de valor de intercambio dentro de un sistema econĂłmico de igual a igual que 

utiliza la criptografĂ­a para verificar y asegurar transacciones, y controlar la creaciĂłn de 

unidades adicionales. 

 

Ethereum: Infraestructura computacional global, abierta, descentralizada que ejecuta 

programas llamados contratos inteligentes. Este utiliza una blockchain para sincronizar y 

almacenar los cambios de estado con su token nativo ether, para medir y limitar el costo de 

los recursos de ejecuciĂłn. 

 

Contratos inteligentes: Son programas informĂĄticos que pueden cumplirse de forma 

automĂĄtica una vez que las partes han acordado los tĂŠrminos. Se escriben y ejecutan sobre 

una blockchain. Ethereum fue el primer ecosistema blockchain en permitir la creaciĂłn y 

ejecuciĂłn de los mismos. 

 

Token: Una unidad de valor que una organizaciĂłn crea para autogestionar su modelo de 

negocio y capacitar a sus usuarios para interactuar con sus productos, al tiempo que facilita 

la distribuciĂłn y el intercambio de recompensas y beneficios para todos sus grupos de 

interĂŠs. 

 

https://bitcoin.org/es/vocabulario#doble-gasto
https://bitcoin.org/es/vocabulario#doble-gasto


5 

 

 

ERC: Por sus siglas en inglĂŠs Ethereum Request for Comment. Los ERC son estĂĄndares y 

convenios a nivel de aplicaciĂłn. 

 

EIP: Por sus siglas en inglĂŠs Ethereum Improvement Proposal. Propuesta de mejora de 

Ethereum. Es el primer mecanismo para proponer nuevas caracterĂ­sticas, para recopilar 

aportes tĂŠcnicos de la comunidad sobre un tema y para documentar las decisiones de 

diseĂąo que se han incluido en Ethereum. 

 

Token de Utilidad: Tokens que desde la dimensiĂłn legal no representan un valor 

negociable. Por el contrario, tienen una utilidad, generalmente es dar acceso a un servicio, 

red o producto o construir en una infraestructura descentralizada. 

 

ICO: Por sus siglas en inglĂŠs Initial Coin Offering. Oferta inicial de moneda. Proceso por el 

cual una startup recauda fondos ofreciendo a cambio un token de utilidad emitido en 

blockchain. 

 

STO: Por sus siglas en inglĂŠs, (Security Token Offering). Proceso de emisiĂłn de activos 

digitales-denominados tokens que representan valores negociables (securities: deuda o 

equity) en donde se usa la tecnologĂ­a blockchain para digitalizarlas. 

Security Token:  Tokens de valores negociables; pueden representar propiedad 

fraccionada de inmuebles, arte, acciones de una compaùía, deuda o un activo respaldado 

por algĂşn valor. 

 

Compliance platforms: Plataformas encargadas de alinear la tecnologĂ­a con las 

normativas y marcos regulatorios. Son conocidas como compliance platforms. 

 

ERC-20: Es un estĂĄndar tĂŠcnico usado para emitir e implementar tokens en la blockchain de 

Ethereum. Se entiende como un contrato inteligente, guĂ­a tĂŠcnica o especĂ­fica de un marco 

de reglas que se deben seguir para que el token funcione apropiadamente. Se les dice 

tokens ERC-20 a los tokens que son creados usando este estĂĄndar.  

 

Protocolo: Conjunto de reglas predefinidas con el propĂłsito de estandarizar el intercambio 

de informaciĂłn en actividades informĂĄticas. Al seguir un mismo protocolo se garantiza que 

habrĂĄ compatibilidad entre los dispositivos en los distintos puntos de un sistema informĂĄtico. 

 

Algoritmo: Conjunto prescrito de instrucciones o reglas bien definidas, ordenadas y finitas 

que permite llevar a cabo una actividad mediante pasos sucesivos que no generen dudas a 

quien deba hacer dicha actividad. 

 

Algoritmo de Consenso: Mecanismo a travĂŠs del cual una red blockchain alcanza 

consenso. Las blockchain pĂşblicas descentralizadas son sistemas distribuidos y, debido a 

que no dependen de una autoridad central, sus nodos necesitan ponerse de acuerdo 

respecto a la validez de las transacciones. Son los responsables de mantener la integridad y 

seguridad de los sistemas. 

 

dApp: Por sus siglas en inglĂŠs Decentralized Applications aplicaciones descentralizadas; 

aplicaciones que se ejecutan de forma distribuida,alojadas en una blockchain. 



6 

 

 

PoW:Por sus siglas en inglĂŠs (Proof of Work)Prueba de trabajo. Algoritmo de consenso 

utilizado por Bitcoin con el objetivo de proteger la red, requiriendo que los nodos 

participantes (mineros) realicen un procesamiento de datos para resolver un problema 

criptogrĂĄfico difĂ­cil. (por ejemplo, un problema matemĂĄtico) antes de permitir la realizaciĂłn 

de otra acciĂłn. 

 

PoS: Por sus siglas en inglĂŠs (Proof of Stake) Prueba de participaciĂłn. Algoritmo de 

consenso que asegura la red de una forma determinista. En este sistema no hay mineros 

procesando datos. Los usuarios interesados en participar en la red deben poner en 

participacion sus tokens y dejarlos quietos como garantĂ­a. Entre mĂĄs tokens tenga en 

participaciĂłn, es mĂĄs alta la recompensa. 

 

Mineros: MĂĄquinas especializadas que funcionan en el algoritmo de consenso PoW. 

Realizan cĂĄlculos matemĂĄticos para confirmar las transacciones en la red de Bitcoin y 

proteger la red. 

 

KYC: Por sus siglas en inglĂŠs (Know Your Client) Conoce a tu cliente. Procesos de 

supervisiĂłn que realiza una entidad para conocer a sus nuevos y antiguos clientes para 

identificar a quĂŠ se dedican y de dĂłnde proceden sus fondos, con la intenciĂłn de evitar 

mantener relaciones comerciales con personas involucradas en delitos de blanqueo de 

capitales, terrorismo, corrupciĂłn gubernamental, delitos relacionados con drogas. 

 

 AML: Por sus siglas en inglĂŠs (Anti Money Laundering) prevenciĂłn del blanqueo de 

capitales. 

 

 

FINMA: Swiss Financial Market Supervisory Authority. Autoridad Suiza supervisora de los 

mercados financieros. 

 

FATF: Por sus siglas en inglĂŠs, Financial Action Task Force. Grupo de AcciĂłn Financiera 

Internacional-GAFI.InstituciĂłn intergubernamental creada en 1989 para promulgar un marco 

internacional de las normas de prevenciĂłn. 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 



7 

 

 

 

 

 

 

Índice 
Agradecimientos ................................................................................................................. 2 

Resumen .............................................................................................................................. 3 

Glosario ............................................................................................................................... 4 

Pregunta de investigaciĂłn .................................................................................................. 9 

JustificaciĂłn de la InvestigaciĂłn ....................................................................................... 9 

I IntroducciĂłn .................................................................................................................... 11 

Blockchain ........................................................ 12 

EconomĂ­a & CentralizaciĂłn ............................................ 13 

ICOs & TokenizaciĂłn ........................................................................................................ 15 

II “Protocolos Gordos” ..................................................................................................... 15 

Token-EconomĂ­a a Cripto economĂ­a ..................................... 16 

Las 6 vidas de un Token y como definir su utilidad ........................... 17 

Circulo Cripto-econĂłmico ............................................. 19 

III TaxonomĂ­a de los Tokens ............................................................................................ 21 

Tokens en TĂŠrminos Legales .......................................... 21 

Propuesta de FINMA en TerminologĂ­a .................................... 22 

TaxonomĂ­a Propuesta por Autoridad Bancaria Europea ...................... 23 

TaxonomĂ­a de los tokens en tĂŠrminos tecnolĂłgicos. .......................... 25 

Propuesta de clasificaciĂłn de tokens de Untitiled INC ....................... 26 

Las 5 Dimensiones de los Tokens CriptogrĂĄficos........................... 27 

Capas de los sistemas DLT ..................................... 29 

Capa de Gobernabilidad en DLT ........................................ 30 

Decred-Decentralized Credit ........................................... 31 

IV Ethereum, la FĂĄbrica de Tokens .................................................................................. 32 

ERC ............................................................ 33 

ERC-20 el catalizador de los tokens ..................................... 33 

Top 10 Tokens ERC-20 .............................................. 36 

Monedas Estables ................................................. 37 

Tokens de Casas de Cambio ......................................... 38 



8 

 

ICOs Vs Inversionistas de capital de riesgo (VC) ............................ 39 

ERC-721 Tokens No Fungibles (NFT) .................................... 41 

ERC-725 EL estĂĄndar de la identidad en Ethereum .......................... 43 

ERC-1155 El estĂĄndar multi token y Gaming ............................... 44 

Enjin y su cripto economĂ­a para gamers ................................... 45 

Token contrato ERC-1155 para certificados de energĂ­a renovable en blockchain ..... 46 

VI Tokens de valor negociable ......................................................................................... 47 

Tokens de valores y cumplimiento de la normativa ........................... 48 

ERC-1400 = ST-20, El estĂĄndar de los tokens de valores. ..................... 49 

Infraestructura de tokens de valores ..................................... 50 

Tech Stack de Tokens de Valores ....................................... 50 

VII Tendencias de la tokenizaciĂłn ................................................................................... 52 

ICOFunding-Plataforma de TokenizaciĂłn ....................................................................... 55 

Entrevista a ICOFunding .............................................. 55 

VIII Conclusiones .............................................................................................................. 56 

Fase 0 de la tokenizaciĂłn ............................................. 56 

Fase 1 de la TokenizaciĂłn ............................................ 57 

Fase 2 de la TokenizaciĂłn ............................................ 57 

Fase 3 de la TokenizaciĂłn ............................................ 57 

Fase 4 de la TokenizaciĂłn ............................................ 58 

BibliografĂ­a ........................................................................................................................ 58 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 



9 

 

 

Preguntas de investigaciĂłn 

ÂżComo puede la tecnologĂ­a blockchain crear una economĂ­a tokenizada para democratizar la 

inversiĂłn? 

ÂżpodrĂĄ la tokenizaciĂłn democratizar el mercado global de inversiones y abrirlo para que los 

inversores mĂĄs pequeĂąos participen en ofertas atractivas? 

 

 

 

JustificaciĂłn de la InvestigaciĂłn 

Las grandes empresas de tecnologĂ­a que se han creado en las Ăşltimas dĂŠcadas han sido 

captadas por pequeĂąos y exclusivos grupos de VC (Venture Capitals) inversionistas 

concentrados en Silicon Valley. Startups como Uber y Airbnb, que se usan en casi la 

totalidad del mundo, solo fueron ofertadas en su inicio a un pequeĂąo grupo de inversores 

que pudieron captar todo el valor antes de que estas compaùías se volvieran públicas por 

medio de una IPO. Adicionalmente en Estados Unidos para poder acceder a ciertas ofertas 

de inversiĂłn tienes que ser un inversionista autorizado o acreditado. En el contexto de una 

persona natural, para ser un inversionista acreditado segĂşn las leyes de la ComisiĂłn de 

Intercambio de Valores de Estados Unidos: (Securities Exchange Commission). 

 

• Tener ingresos que superen los $200.000 USD o $300.000 en conjunto con tu pareja 

en los Ăşltimos 2 aĂąos y esperar lo mismo para el prĂłximo aĂąo.  

• Tener un capital que supere el millón de dólares solo o en conjunto con su esposa, sin 

incluir el valor de la primera residencia.  

• Cualquier fondo que exceda los $5 millones que no sea formado y que la compra sea 

por un inversionista denominado ¨Persona Sofisticada¨. 

• La persona sofisticada según el SEC debe tener suficiente conocimiento y experiencia 

en el sector financiero y en asuntos de negocio que sepa evaluar el riesgo.(SEC, 2019)  

 

Aunque estos requisitos no son para todas las inversiones, si excluyen a gran parte de los 

estadounidenses que no tienen un capital suficiente, pero quieren encontrar buenas ofertas 

de inversiĂłn. 

 

Por otro lado, en Europa, segĂşn MiFID, Markets in Financial Instruments Directive, el 

tĂŠrmino que se usa es Inversionista Experimentado y debe cumplir con ciertos requisitos: 

 

● Haber cumplido una transacción de comercio en una cantidad significativa de 

por lo menos €50.000, en un mercado relevante en un promedio de 

frecuencia de 10 por cada cuatrimestre en los Ăşltimas 4 cuatrimestres.  

● El tamaño del portafolio financiero del inversionista definido incluyendo los 

depósitos de efectivo e instrumentos financieros deben exceder €500.000. 



10 

 

● El inversionista trabaja o ha trabajado en el sector financiero por lo menos un 

aĂąo en una posiciĂłn profesional que requiere conocimiento de la transacciĂłn 

o servicio.(European Parliament, 2004)  

 

En primera instancia suena totalmente exclusivo y desde muchos aspectos puede serlo. La 

justificaciĂłn de estas medidas restrictivas es para proteger al pequeĂąo inversionista de sĂ­ 

mismo. Argumentos totalmente debatibles que pone a las personas mĂĄs ricas en una 

posiciĂłn de acceso a oportunidades de inversiĂłn en ventaja de los menos ricos. 

Entendiendo que en muchos paĂ­ses el lobbying se ha vuelto una herramienta para que los 

mĂĄs ricos creen las leyes a su beneficio, estas restricciones se pueden entender de igual 

manera como una forma para proteger a los mĂĄs ricos y ofrecerles las mejores 

oportunidades de una forma exclusiva. 

 

Aunque en Estados Unidos existe la regulaciĂłn A (Reg A) la cual permite a los 

inversionistas no acreditados invertir en una oferta de deuda o equity (Security Offering). 

Esta regulaciĂłn en la prĂĄctica es conocida por sus altos estĂĄndares de exigencia, sus altos 

costos y porque su proceso burocrĂĄtico se vuelve un proceso lento que puede llegar a tomar 

mucho tiempo en búsqueda de la protección del SEC¨.(The Tokenizer, 2019). 

 

Uno de los puntos importantes que se puede argumentar es el hecho de que aunque 

quitemos las regulaciones, igualmente el mercado no necesariamente serĂ­a mĂĄs 

democrĂĄtico o abierto e inclusivo. Esto se debe a que en muchas ocasiones la principal 

barrera para acceder a estas inversiones son los altos montos de capital que se exige como 

mĂ­nima inversiĂłn.  

 

 

 

 

 

 
 

 

 

 



11 

 

 

I IntroducciĂłn 

 

Nuestra economĂ­a estĂĄ fracasando en escalar. La revoluciĂłn industrial nos trajo el modelo 

de la jerarquĂ­a burocrĂĄtica, la organizaciĂłn, la instituciĂłn y la corporaciĂłn. Un esquema 

piramidal que nos permitiĂł hacer grandes avances tecnolĂłgicos como civilizaciĂłn pero que 

hoy no nos permiten solucionar los problemas de una civilizaciĂłn global. 

(Antonopoulos,2018) 

 

 

Las corporaciones se ven como una pirĂĄmide egipcia, en donde las acciones se hacen en la 

base y las decisiones se toman arriba a donde la informaciĂłn fluye y se concentra. El 

problema es que el poder tambiĂŠn es concentrado arriba y las personas que toman las 

decisiones tienen mucho poder e insuficiente informaciĂłn. EstĂĄn muy lejos del lugar donde 

las decisiones son ejecutadas y no pueden ver las consecuencias de esas decisiones y el 

poder los corrompe.  (Antonopoulos, 2018a) 

 

AsĂ­ como la revoluciĂłn industrial creĂł nuevos modelos organizacionales para incrementar la 

productividad. AsĂ­ como internet nos dio la forma de escalar el acceso a la informaciĂłn. Hoy 

Blockchain nos da una plataforma global que crea confianza como unidad de toma de 

decisiones descentralizadas sin usar un esquema jerĂĄrquico. 

 

La era de la informaciĂłn por medio del protocolo TCP/IP y HTTP, nos permitiĂł definir cĂłmo 

se transfiere la informaciĂłn en la web. SMTP es el protocolo que permitiĂł a las aplicaciones 

de e-mail enviar y recibir archivos de forma inmediata, sin importar distancia u hora. Sin 

embargo, cada vez que enviamos un archivo digital, en efecto lo estamos replicando y 

enviando una copia. 

 

En el 2004 el cientĂ­fico computacional y criptĂłgrafo Harold Thomas Finney II introduce un 

sistema RPoW por sus siglas en inglĂŠs (Reusable Proof Of Work) Prueba de trabajo 

reutilizable. En esencia este sistema resuelve el problema del doble gasto manteniendo la 

propiedad de los tokens registrados en un servidor confiable que fue diseĂąado para permitir 

a los usuarios de todo el mundo verificar su exactitud e integridad en tiempo real. (Finney, 

2004) Sin embargo en ese momento la informaciĂłn sigue siendo centralizada en un 

servidor.  

 

4 aĂąos despuĂŠs y tras una de las peores crisis financieras de la historia, una persona o un 

grupo de personas bajo el seudĂłnimo Satoshi Nakamoto publicĂł un libro blanco llamado 

Bitcoin; un sistema de efectivo electrĂłnico descentralizado de usuario-a-usuario. Lo 

describe como; una soluciĂłn al problema del doble-gasto utilizando un servidor de marcas 

de tiempo usuario-a-usuario distribuido para generar una prueba computacional del orden 



12 

 

cronolĂłgico de las transacciones. La red coloca estampas de tiempo a las transacciones al 

crear un hash de las mismas en una cadena continua de pruebas de trabajo basadas en 

hashes, formando un registro que no puede ser cambiado sin volver a recrear la prueba de 

trabajo. El sistema es seguro mientras que nodos honestos controlen colectivamente mĂĄs 

poder de procesamiento (CPU) que cualquier grupo de nodos atacantes en 

cooperaciĂłn.(Nakamoto, 2009) (Nakamoto, 2009) El diseĂąo de mecanismos planteado por 

Nakamoto incentiva a estos nodos (mineros) a participar, ya que al realizar el 

procesamiento estĂĄn protegiendo la red y a la vez participando para obtener los prĂłximos 

bitcoins que serĂĄn creados.  

 

Para verlo de otro modo; Visa, es un sistema de pagos internacional centralizado y dentro 

de ese sistema se mueven las cuentas de las monedas fiduciarias como el dĂłlar o euro, en 

un formato digital. Bitcoin con B mayĂşscula es un sistema de pagos internacional 

descentralizado y dentro de este se mueve su moneda nativa bitcoin, a la cual nos referimos 

con b minĂşscula y de los cuales solo puede haber 21 millones. Esto significa un sistema 

monetario con una unidad escasa, limitada, y con una inflaciĂłn controlada y programada en 

el cĂłdigo. 

Blockchain 

Lo que blockchain nos permite hacer es enviar activos digitales con la misma inmediatez y 

lo mĂĄs importante; sin crear copias, en esencia se transfiere propiedad. Por primera vez en 

la historia se puede transferir propiedad representada en activos digitales o tokens en una 

red descentralizada, pĂşblica, resistente a la censura, abierta, sin fronteras y sin un 

intermediario.  

 

Teniendo esto en cuenta, el nombre blockchain o bloques de cadena viene de uno de sus 

componentes mĂĄs representativos por su misma funciĂłn en el proceso, al tener una cadena 

de bloques protegidos criptogrĂĄficamente que actĂşa como un diario de todas las 

transacciones de estado verificadas y aceptadas. Antonopoulos describe una blockchain 

abierta y pĂşblica como un conjunto de componentes en el que usualmente deben de tener: 

 

● Una red punto a punto (P2P) que conecta a los participantes y propaga 

transacciones y bloques de transacciones verificadas, basado en un protocolo 

estandarizado de ""chismes"". 

 

● Mensajes, en forma de transacciones, que representan transiciones de 

estado. 

 

● Un conjunto de reglas de consenso que rigen lo que constituye una 

transacciĂłn y lo que hace una transiciĂłn de estado vĂĄlida. 

 

● Una máquina de estado que procesa transacciones de acuerdo con las 

reglas de consenso. 

 



13 

 

● Una cadena de bloques protegidos criptográficamente que actúa como un 

diario de todas las transiciones de estado verificadas y aceptadas. 

 

● Un algoritmo de consenso que descentraliza el control sobre la cadena de 

bloques, al obligar a los participantes a cooperar en la aplicaciĂłn de las reglas de 

consenso. 

 

● Un esquema de incentivo teóricamente sólido (por ejemplo, costos de prueba 

de trabajo mĂĄs recompensas en bloque) para asegurar econĂłmicamente la mĂĄquina 

de estado en un entorno abierto. 

 

● Una o más implementaciones de software de código abierto de los anteriores 

(""clientes"") (Antonopoulos & Woods, 2018) 

 

EconomĂ­a & CentralizaciĂłn 

La economĂ­a de hoy estĂĄ representada por producciĂłn, distribuciĂłn o intercambio y el 

consumo de bienes y servicios de diferentes agentes. DetrĂĄs de eso en esencia estĂĄ el 

comportamiento de grandes grupos de personas y la realidad es que este factor vuelve a la 

economĂ­a debatiblemente una ciencia social y el comportamiento de las personas no es 

algo que se pueda modelar muy bien matemĂĄticamente. El dinero ha existido en nuestra 

concepciĂłn durante miles de aĂąos, empezando como una forma de contabilizar los favores 

que se hacĂ­an dentro de una comunidad entre sus partes para facilitar el intercambio de 

bienes y servicios. Sus principales usos han sido: 

 

● Medio de intercambio 

● Reserva de Valor 

● Unidad de medida 

 

Sin embargo, desde que Richard Nixon en 1971 puso fin a la capacidad de los bancos 

centrales extranjeros para convertir su dĂłlar en oro, para evitar una fuga en las reservas de 

oro de EE. UU. y revertir el deterioro del saldo del paĂ­s.(Irwin, 2012)  el dinero que hoy 

conocemos tuvo un cambio en sus fundamentos, cumple una funciĂłn adicional; ser un 

sistema de control. Desde entonces el mundo ha tenido al dĂłlar como moneda internacional 

fiduciaria, respaldada Ăşnicamente por la fe y el crĂŠdito de las personas en el gobierno 

norteamericano. Esto deja a una autoridad central a cargo de la impresiĂłn de dinero y 

eventualmente a cargo del valor del medio de intercambio mĂĄs usado, formando una gran 

vulnerabilidad al sistema econĂłmico mundial. Es por esto que aunque las estructuras 

econĂłmicas son producto de aĂąos de investigaciĂłn, gobernanza y dinĂĄmica social, ante 

cĂ­clicas crisis econĂłmicas tenemos que aceptar que quizĂĄs estamos en un sistema 

econĂłmico parcialmente diseĂąado y con mejores diseĂąos de mecanismos por descubrir y 

nueva tecnologĂ­a por implementar para que este siga evolucionando. 

 

Es por esto que, aunque las personas creen que bitcoin es sobre el dinero, 

fundamentalmente es sobre la confianza. (Antonopoulos, 2016) 

 



14 

 

A pesar de que la informaciĂłn puede fluir instantĂĄneamente y la velocidad de conectividad a 

la web es cada vez mĂĄs rĂĄpida y nos sumergimos en un mundo cada vez mĂĄs digital, las 

transacciones bancarias internacionales siguen tomando mĂĄs tiempo de lo normal. Incluso 

hacer una transferencia nacional de un banco a otro puede ser un dolor de cabeza, ya que 

cada uno tiene su propia red cerrada de informaciĂłn. Debido a que cada entidad tiene su 

propia base de datos y no las comparte por motivos de seguridad. Esto crea silos de datos y 

son formas de almacenar informaciĂłn centralizada e ineficientemente. Esto debido a que 

para hacer transferencias internacionales los bancos deben recurrir a un tercero que sirva 

de ĂĄrbitro para que les proporcione una plataforma confiable y los comunique entre sĂ­. Esta 

es una de las funciones de (SWIFT) Society for Worldwide Interbank Financial 

Telecommunication. El cual provee una red de informaciĂłn para que los bancos puedan 

enviar y recibir informaciĂłn sobre transacciones financieras. Para verlo de otra forma es el 

¨mensajero internacional de los bancos¨, un intermediario cuya función es dar confianza a 

las partes y transferir datos globalmente. Sin embargo, aunque esta organizaciĂłn quiere 

ofrecer un servicio neutral, sus mecanismos de gobernabilidad no se lo permiten y por esto 

seguimos viendo cĂłmo pueden arbitrariamente excluir de su red a bancos de algunos 

paĂ­ses y funcionar como un arma polĂ­tica financiera.  

 

En el resumen ejecutivo del 2019 de las naciones unidas, sobre la situaciĂłn y perspectiva 

de la economĂ­a mundial; subrayan la urgencia de adoptar mecanismos que reduzcan los 

riesgos en los que la economĂ­a global se desestabilice.(ONU, 2015) Entre los objetivos de la 

agenda 2030, el nĂşmero 17 denominado Alianza para lograr los objetivos en mi opiniĂłn es 

vital para lograr los demĂĄs. Blockchain es una herramienta tecnologĂ­a que nos puede 

ayudar a lograr los objetivos, depende de la voluntad polĂ­tica y coordinaciĂłn de las naciones 

diseĂąar e implementar los mecanismos correctos. Cuando entendemos que los tokens 

pueden significar cualquier forma de incentivo para lograr un comportamiento deseado en 

un sistema podemos empezar a diseĂąar mecanismos para crear una sociedad mĂĄs 

sostenible. En donde debemos entender que, asĂ­ como el internet rompiĂł el cartel de la 

informaciĂłn, hoy Bitcoin rompe el del sistema financiero. (Pompliano,2019) y al ser su 

tecnologĂ­a FOSS podemos esperar una ola de innovaciĂłn para fortalecer la confianza en 

procesos econĂłmicos administrativos y de gobernabilidad en diferentes industrias, en los 

que los tokens son protagonistas. 

 

 

 

 

 

 

 

 

 

 

 

 



15 

 

ICOs & TokenizaciĂłn 

Es aquĂ­ donde, blockchain y las ICOs estĂĄn cambiando el espectro: Una ICO se puede 

resumir de la siguiente manera: un nuevo mĂŠtodo para recaudar fondos a travĂŠs de la oferta 

y venta de un grupo de desarrolladores o una empresa a una multitud (es decir, inversores o 

contribuyentes) de criptoactivos ad hoc (tambiĂŠn acuĂąados como ""tokens"") especĂ­ficamente 

creado y emitido en un libro mayor distribuido, a veces precedido por una venta anticipada 

de los activos de cifrado llamada ""preventa"", con el propĂłsito de iniciar un negocio o 

desarrollar un sistema de gobierno ad hoc de proyectos basados, en varios casos, en el 

tecnologĂ­a DLT, generalmente a cambio de criptoactivos 'principales' preexistentes.(Blemus 

& Guegan, 2019)  

 

Dicho proceso tambiĂŠn se puede entender como tokenizaciĂłn. En tĂŠrminos de inversiĂłn, la 

tokenizaciĂłn permite que pequeĂąos inversionistas puedan acceder a posibles proyectos 

innovadores de calidad sin ser inversionistas acreditados o tener grandes sumas de capital. 

Debido a que el proceso no necesita de intermediarios bancarios, el rango de acceso se 

abre y hay menos fricciĂłn. En un principio los inversionistas recibĂ­an un token, denominado 

token de utilidad y en muchos casos los emprendedores que los emitĂ­an los describĂ­an 

como un producto que no es un valor negociable, (security) todo con el propĂłsito de evitar 

regulaciones de las autoridades de valores. La utilidad del token se describĂ­a como un 

producto que da acceso a una red descentralizada, que permite construir o ejecutar 

programas en una plataforma descentralizada. 

 

Esta tesis analiza diferentes enfoques en taxonomĂ­as propuestas, diferentes ecosistemas o 

redes cripto econĂłmicas, cĂłmo interactĂşa su token y como crean valor. Estamos tratando 

con tecnologĂ­a que nos permite crear y diseĂąar nuevas formas de capital, (Monegro, 2019b) 

lo define como Capital de Red. Por primera vez en la historia tenemos las herramientas para 

crear organizaciones planas, descentralizadas y autĂłnomas que podemos diseĂąar para que 

sean incluyentes y proporcionen fuentes de ingresos al alcance de cualquier inversionista. 

Tokenizar la economĂ­a nos acerca a los servicios financieros universales bĂĄsicos que nos 

puede permitir que nuestra economĂ­a escale a una era digital. 

Las ICOs fueron solo el principio y abrieron el camino a los tokens de valores que pueden 

representar propiedad fraccionada de un activo fĂ­sico y se distribuyen por el proceso que se 

llama STO o Security Token Offering. 

 

ICOs, STOs, cripto-activos y tokenizaciĂłn, asĂ­ como, en tĂŠrminos mĂĄs generales, el uso de 

DLT y los contratos inteligentes podrĂ­an afectar la forma en que las empresas se rigen en 

varias formas. Las nuevas tecnologĂ­as, blockchain y cripto-activos en parti";"""date"",""2019-11-06T13:10:36Z""
""pdf:PDFVersion"",""1.7""
""xmp:CreatorTool"",""MicrosoftÂŽ Word 2016""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""language"",""es""
""dc:format"",""application/pdf; version=1.7""
""pdf:docinfo:creator_tool"",""MicrosoftÂŽ Word 2016""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""xmp:CreateDate"",""2019-09-05T01:29:56Z""
""modified"",""2019-11-06T13:10:36Z""
""pdf:hasMarkedContent"",""true""
""xmp:ModifyDate"",""2019-11-06T14:10:36Z""
""pdf:docinfo:creator"",""Usuario""
""meta:author"",""Usuario""
""meta:creation-date"",""2019-09-04T23:29:56Z""
""created"",""2019-09-04T23:29:56Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-09-04T23:29:56Z""
""resourceName"",""237483403.pdf""
""Author"",""Usuario""
""producer"",""MicrosoftÂŽ Word 2016""
""pdf:docinfo:producer"",""MicrosoftÂŽ Word 2016""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""access_permission:modify_annotations"",""true""
""dc:creator"",""Usuario""
""dcterms:created"",""2019-09-04T23:29:56Z""
""Last-Modified"",""2019-11-06T13:10:36Z""
""dcterms:modified"",""2019-11-06T13:10:36Z""
""xmpMM:DocumentID"",""uuid:A233B3CE-F628-4ED5-A1A2-4158AC86C784""
""Last-Save-Date"",""2019-11-06T13:10:36Z""
""pdf:docinfo:modified"",""2019-11-06T13:10:36Z""
""meta:save-date"",""2019-11-06T13:10:36Z""
""Content-Length"",""2307651""
""Content-Type"",""application/pdf""
""xmp:MetadataDate"",""2019-11-06T14:10:36Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Usuario""
""dc:language"",""es-ES""
""pdf:producer"",""MicrosoftÂŽ Word 2016""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""61""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""351"",""274"",""1406"",""2588"",""2788"",""1799"",""2720"",""1880"",""2425"",""1628"",""2550"",""2540"",""2608"",""2641"",""3235"",""1652"",""2703"",""762"",""498"",""1875"",""2403"",""2452"",""1492"",""1055"",""3046"",""2861"",""463"",""2562"",""864"",""1000"",""2903"",""1064"",""2483"",""1444"",""1400"",""30"",""1124"",""3035"",""1006"",""680"",""2606"",""1943"",""2898"",""2174"",""2370"",""1981"",""2938"",""2942"",""2848"",""1760"",""1992"",""1602"",""1787"",""1210"",""2217"",""2098"",""3528"",""2586"",""3609"",""3709"",""2289""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-09-04T23:29:56Z""
";https://scholar.google.com/scholar?start=610&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094640-1071;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Blockchain: Panacea for Corrupt Practices in Developing Countries;AI Sanka, RCC Cheung ; 2019 2nd International Conference of …, 2019  ieeexplore.ieee.org;;"… most successful cryptocurrency. Beside the cryptocurrencies, there are several other applications

of blockchain in healthcare, banking, insurance, identity management and so on [6]. There are

also increasing blockchain adoptions by many companies such as IBM, Oracle and …";Cité 2 fois;Les 3 versions;null;;;;https://scholar.google.com/scholar?start=890&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094656-1141;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Implementation of a tournament based distributed lottery on Ethereum;VF Andersen ;2019 ntnuopen.ntnu.no;;"… Data for gas price, ether price, and transaction throughput on the Ethereum blockchain was

gathered from Etherscan 3 and ETH … Hash functions as random oracles … Since this property is not

for- mally proven, a random oracle model assumption is often made for hash functions …";Autres articles;Version HTML;[PDF] ntnu.no;https://ntnuopen.ntnu.no/ntnu-xmlui/bitstream/handle/11250/2634465/no.ntnu%3Ainspera%3A2531122.pdf?sequence=1;"
N
TN

U
N

or
w

eg
ia

n 
U

ni
ve

rs
ity

 o
f S

ci
en

ce
 a

nd
 T

ec
hn

ol
og

y
Fa

cu
lt

y 
of

 In
fo

rm
at

io
n 

Te
ch

no
lo

gy
 a

nd
 E

le
ct

ri
ca

l
En

gi
ne

er
in

g
D

ep
ar

tm
en

t o
f C

om
pu

te
r 

Sc
ie

nc
e

M
as

te
r’

s 
th

es
is

Viktor Frede Andersen

Distributed lottery on Ethereum

Implementation of a tournament based
distributed lottery on Ethereum

Master’s thesis in Computer Science
Supervisor: Letizia Jaccheri

June 2019





Viktor Frede Andersen

Distributed lottery on Ethereum

Implementation of a tournament based distributed
lottery on Ethereum

Master’s thesis in Computer Science
Supervisor: Letizia Jaccheri
June 2019

Norwegian University of Science and Technology
Faculty of Information Technology and Electrical Engineering
Department of Computer Science





Distributed lottery on Ethereum

Preface

This is a Master’s thesis carried out during the spring semester of 2019 for the com-
pletion of the 5-year computer science program at Norwegian University of Science
and Technology, Trondheim. The idea for a tournament based lottery on Ethereum
was inspired by the works of Miller and Bentov and Bartoletti and Zunino. The
search for a thesis went over a long time during which I studied blockchain appli-
cations and learned about the blockchain space.

The readers of this report are assumed to have a background in computer sci-
ence with some knowledge of distributed systems and blockchains.

11-06-2019

Viktor Frede Andersen

i





Distributed lottery on Ethereum

Acknowledgment

I would like to thank the following persons for their great help during the thesis
work:
Mariusz Nowostawski for being an excellent supervisor and mentor with patience
and understanding.
My mom Liv Unni Andersen and dad Jan Kjetil Andersen for mental support, guid-
ance, and for pushing me when progress was slow.
All contributors to the academic work which I built this thesis on, including open
source contributors and advocates of Bitcoin, Ethereum, and associated software
projects.

V.F.A.

iii





Distributed lottery on Ethereum

Abstract

Distributed lotteries on the internet is an interesting application with uses in gam-
bling and other areas. Blockchains that function as smart contract platforms can be
used to both transfer value and enforce protocols for multiparty computing with-
out relying on a trusted intermediary. This has made it possible to design lotteries
with verifiable randomness and with a guarantee of successful completion.

One promising design of a distributed lottery on a blockchain is based on a tour-
nament of digital coin tosses. This thesis explores the feasibility of such a lottery
through making an implementation and doing measurements. The implementa-
tion is made for the Ethereum blockchain, which is currently the leading platform
for applications using smart contracts. The lottery is assessed by measuring trans-
action costs and transaction demand, as well as by discussing the security of the
lottery in the context of known security issues for blockchain applications and web
applications.

We successfully implement a lottery prototype which is likely to work for up to
about 100000 participants. Several directions of further research to improve the
scalability are identified and discussed. We find that the most concerning security
issue is transaction censorship by a powerful collusion of opportunistic miners,
which might be an issue for lotteries with a very large prize.

v





Distributed lottery on Ethereum

Abbreviations

P2P = Peer-to-Peer
PoW = Proof-of-Work
VRF = Verifiable Random Function
PRNG = Pseudo-Random Number Generator
API = Application Programming Interface
MPC = MultiParty Computation
BVM = Bitcoin Virtual Machine
EVM = Ethereum Virtual Machine
CA = Contract Account
EOA = Externally Owned Account
dApp = Decentralized Application
RPC = Remote Procedure Call
DoS = Denial-of-Service
PoS = Proof-of-Stake
HDS = Hierarchical Deterministic Secrets

vii





Distributed lottery on Ethereum

Contents

Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . i
Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iii
Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . v
Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii
Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix
List of Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii
List of Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv
Listings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvii
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.1 Thesis statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.2.1 Literature review . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2.2 Data collection . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2.3 Data analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.3 Thesis structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.1 Cryptography . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.1 Secure hash functions . . . . . . . . . . . . . . . . . . . . . . 5
2.1.2 Digital encryption . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1.3 Digital signatures . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.2 Verifiable randomness . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2.1 Introduction to verifiable random functions (VRF) . . . . . . 9
2.2.2 Categories of VRFs . . . . . . . . . . . . . . . . . . . . . . . . 10
2.2.3 Delay functions . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2.4 Random beacons . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.2.5 Verifiable random oracles . . . . . . . . . . . . . . . . . . . . 13

2.3 Lotteries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.4 Blockchain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.4.1 Transactions . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.4.2 Mining . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.4.3 Blockchain threats . . . . . . . . . . . . . . . . . . . . . . . . 22

2.5 Trustworthy computing . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.5.1 Smart contracts . . . . . . . . . . . . . . . . . . . . . . . . . . 24

ix



Distributed lottery on Ethereum

2.5.2 Ethereum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

3.1 Tournament lottery outline . . . . . . . . . . . . . . . . . . . . . . . 29
3.1.1 Digital coin toss . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.1.2 Note on the lottery being non-deterministic . . . . . . . . . . 31
3.1.3 Phases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

3.2 Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.2.1 Master contract . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.2.2 Match contract . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.2.3 Lottery setup code . . . . . . . . . . . . . . . . . . . . . . . . 39

4 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.1 Gas usage and transaction costs . . . . . . . . . . . . . . . . . . . . . 41
4.2 Ticket price . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

4.2.1 Lower and upper bound on ticket prices . . . . . . . . . . . . 45
4.2.2 A ticket price of zero . . . . . . . . . . . . . . . . . . . . . . . 46

4.3 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.3.1 Loss of connectivity . . . . . . . . . . . . . . . . . . . . . . . . 47
4.3.2 Blockchain reorganizations . . . . . . . . . . . . . . . . . . . 47
4.3.3 Censorship and transaction blocking . . . . . . . . . . . . . . 48
4.3.4 Compromised client and phishing . . . . . . . . . . . . . . . . 49

4.4 Cost of a censorship attack . . . . . . . . . . . . . . . . . . . . . . . . 50
4.5 Scalability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

4.5.1 Transaction throughput . . . . . . . . . . . . . . . . . . . . . 53
4.5.2 Transaction costs and max prize . . . . . . . . . . . . . . . . . 55
4.5.3 Scalability limits . . . . . . . . . . . . . . . . . . . . . . . . . 56

4.6 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
4.6.1 Consequences of interactivity . . . . . . . . . . . . . . . . . . 58
4.6.2 Tournament without a full binary tree . . . . . . . . . . . . . 60
4.6.3 Mitigating a censorship attack . . . . . . . . . . . . . . . . . . 61

5 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
5.1 Programming tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
5.2 Blockchain security . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
5.3 Experimentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
6.1 Future work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

6.1.1 Minimizing transaction costs . . . . . . . . . . . . . . . . . . 68
6.1.2 Minimizing interactivity . . . . . . . . . . . . . . . . . . . . . 68
6.1.3 Off-chain negotiation . . . . . . . . . . . . . . . . . . . . . . . 68
6.1.4 Formal analysis of security . . . . . . . . . . . . . . . . . . . . 69

x



Distributed lottery on Ethereum

Bibliography . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
A Listings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

A.1 Solidity contracts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
A.1.1 Abstract match contract . . . . . . . . . . . . . . . . . . . . . 79
A.1.2 First level match contract . . . . . . . . . . . . . . . . . . . . 79
A.1.3 Internal match contract . . . . . . . . . . . . . . . . . . . . . 81
A.1.4 Master contract . . . . . . . . . . . . . . . . . . . . . . . . . . 84

A.2 Javascript . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
A.2.1 Simulate lottery setup . . . . . . . . . . . . . . . . . . . . . . 86
A.2.2 Simulate lottery play . . . . . . . . . . . . . . . . . . . . . . . 86

B Simulation data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
B.1 Gas usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

xi





Distributed lottery on Ethereum

List of Figures

1 A chain of blocks linked with hashes. . . . . . . . . . . . . . . . . . . 19
2 Transactions in Bitcoin. . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3 A natural blockchain fork. . . . . . . . . . . . . . . . . . . . . . . . . 22
4 Flowchart of a digital coin toss. . . . . . . . . . . . . . . . . . . . . . 30
5 Tournament tree of 8 players. . . . . . . . . . . . . . . . . . . . . . . 31
6 Contracts in a lottery of 8 players . . . . . . . . . . . . . . . . . . . . 40
7 Cost ratio as a function of participants and max prize. . . . . . . . . 57
8 Prize as a function of participants and cost ratio. . . . . . . . . . . . 57
9 Cost ratio and prize as a function of participants and ticket price. . . 58

xiii





Distributed lottery on Ethereum

List of Tables

1 Keyword search on Scopus. . . . . . . . . . . . . . . . . . . . . . . . 3
2 Designs of lottery schemes. . . . . . . . . . . . . . . . . . . . . . . . 4
3 Average gas usage from simulation. . . . . . . . . . . . . . . . . . . . 42
4 Organizer gas usage. Single match contract. . . . . . . . . . . . . . . 43
5 Total gas usage. Single match contract. . . . . . . . . . . . . . . . . . 43
6 Organizer gas usage. Two types of match contracts. . . . . . . . . . . 44
7 Total gas usage. Two types of match contracts. . . . . . . . . . . . . . 44
8 Estimates of td if all transactions on the blockchain are used for our

lottery. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
9 Estimates of td if 10% of the transactions on the blockchain are used

for our lottery. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
10 Time for the entire lottery if 10% of the transactions on the blockchain

are used for our lottery. . . . . . . . . . . . . . . . . . . . . . . . . . 55
11 Statistics from dual match simulation with 256 participants. . . . . . 89

xv





Distributed lottery on Ethereum

Listings

3.1 Lottery master contract . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.2 Lottery first level match contract . . . . . . . . . . . . . . . . . . . . 36
3.3 Lottery internal match contract . . . . . . . . . . . . . . . . . . . . . 38
A.1 Full Solidity contract for AbstractLotteryMatch. . . . . . . . . . . . . 79
A.2 Full Solidity contract for FirstLevelMatch. . . . . . . . . . . . . . . . 79
A.3 Full Solidity contract for InternalMatch. . . . . . . . . . . . . . . . . 81
A.4 Full Solidity contract for LotteryMaster. . . . . . . . . . . . . . . . . . 84
A.5 Truffle test suite for simulating lottery setup. . . . . . . . . . . . . . . 86
A.6 Truffle test suite for simulating lottery play. . . . . . . . . . . . . . . 86

xvii





Distributed lottery on Ethereum

1 Introduction

A lottery can be defined as a random distribution of a prize fund to a set of partic-
ipants, or more generally, a random selection of a subset of winners from a larger
set of participants to receive some privilege. A lottery is often associated with its
use in gambling where one becomes a participant by contributing to a prize fund
by buying a ticket, whereupon a set of winning tickets is randomly drawn and a
part of the fund is redeemable by owning a winning ticket. Lotteries have also been
used in important societal functions such as leader election in democratic gover-
nance [1] or proof-of-stake systems, drafting of soldiers to war [2], jury selection,
and distribution of scarce goods [3], or as a game used in fundraising to a charita-
ble cause.

Since the stakes in a lottery can be quite high, as with large cash prizes or being
drafted to a war, it is crucial that the result is unpredictable and unbiased. For the
lottery to achieve its purpose of ultimately distributing the prize, it is important that
there is consensus of the result, and that the rules are enforced. Achieving unbiased
randomness and consensus is typically done in one of two ways: 1) auditing and
public verification of every step of the protocol, i.e. paper tickets being sold and
blindly drawn from a basket, as is common for small-scale charity lotteries, or 2)
trust in a central authority to conduct the lottery fairly and according to the rules,
which is typical for national lottos and government-backed lotteries. In lotteries of
very large scale, only the second way has typically been feasible.

With the advent of the internet and peer-to-peer (P2P) online communications,
it is natural to explore the possibility of porting lotteries to this domain. A lottery
is a system of several components and is conducted in a process where a set of
participants is defined, and a subset of winners is randomly chosen. Components
of the system include a random process to decide the winners, an authentication
process to decide the participants, a mechanism to distribute the prize, and often a
way to handle payments. A computerized lottery that is accessed over the internet
can be made by having an authoritative server handle the entire lottery process.
While this approach is not trivial and requires careful design [4, 5, 6, 7, 8, 9], it
assumes that the authoritative server or an auditor can be trusted to make sure
the process is conducted correctly. Lotteries where we cannot assume trustworthy
actors or a trusted intermediary will be referred to as distributed lotteries, and is
the type of lotteries this thesis is concerned about.

1



Distributed lottery on Ethereum

In a distributed lottery, all the components of the lottery must work in a dis-
tributed network setting. It should be resistant to adversarial behaviour by partic-
ipants such as sybil attacks [10] or attempts to manipulate the random process,
as well as a dishonest organizer. While there exists provably fair protocols to play
games that involve randomness between non-trusting players [11, 12, 13, 14], the
scale of a lottery makes these protocols impractical. The scaling problem can be
solved by making a random seed unpredictable with delay a function [15], or by
delegating the random process to a semi-trusted committee [16]. Even with good
approaches to the random process, other components of a lottery, such as handling
payments and enforcing the organizer to respect the result of the random process,
can be challenging to handle in a distributed setting.

Blockchain platforms with cryptocurrencies mark an important shift in P2P com-
puting, as they make it possible to transfer value and arrive at global consensus
without a trusted intermediary [17]. Due to the scripting capabilities of several
blockchain platforms, they support implementations of various financial instru-
ments and games involving money. There has been gambling and lottery appli-
cations on Bitcoin and Ethereum for some time, and the topic of lotteries has been
discussed in the academic literature [18, 19, 20, 21, 22, 23]. One class of lotteries
uses digital coin tosses organized in a tournament to fairly select a winner. This
scheme can in theory support a large amount of participants while also maintain-
ing a high degree of resistance from collusion as well as verifiability of the entire
lottery process.

A lottery of this sort has as far as we know been outlined as a proof-of-concept [22],
but not been analyzed and discussed in detail. Applications of smart contracts have
to cross a gap from theoretical soundness to practical feasibility. By analyzing an
implementation in detail, measuring the transaction costs to deploy and play it,
and discussing its security and other issues, we hope to get a better understanding
of lotteries on a blockchain.

1.1 Thesis statement

Miller and Bentov in [22] outline a fair lottery that can be implemented both on
the Bitcoin platform and on other blockchains with a more expressive scripting lan-
guage such as Ethereum. The authors note that an implementation of their lottery
on Ethereum is significantly less complex and more scalable than the same scheme
on Bitcoin. For this reason, as well as the fact that Ethereum has a rich ecosys-
tem of developer tools and user interfaces that make smart contract applications
accessible, we decided to implement a full version of the lottery on Ethereum.

Although there exists several lotteries on Ethereum already, to our knowledge
none are able to achieve fairness and resistance to manipulation to the degree of

2



Distributed lottery on Ethereum

Miller and Bentov’s lottery. The purpose of creating an implementation is to get
some insight into the viability of the lottery in a practical sense. While we will
discuss theoretical considerations for the lottery, we expect to discover new consid-
erations related to security, usability, and performance with a working implemen-
tation.

The theme of this thesis will be to assess the feasibility of a lottery similar to that
in [22] through making a full implementation. It will have an exploratory aspect
in that we expect to discover limitations and constraints for the lottery in a real
setting, and a more practical aspect in that a working proof-of-concept application
will be made.

1.2 Methodology

1.2.1 Literature review

A systematic literature review on distributed lotteries was conducted prior to writ-
ing this thesis in order to place the work in the context of published literature.
Sources were collected by conducting a keyword search in online databases for
published academic papers. The results from the search were restricted to the fields
of computer and information science, as there were many irrelevant hits from dif-
ferent fields. All papers that included a design of a distributed lottery were included
in the review. Additional relevant works were found in the reference list of papers
found through the keyword search.

Hits from the keyword search were first filtered based on their title and abstract.
Papers that were clearly about a different topic than distributed lotteries were not
included. Another round of filtering was done by reading the introduction, table
of contents, and conclusion where papers that did not include a lottery design or
something very similar were discarded.

Both the Scopus 1 and Web of Science 2 databases were queried, but the relevant
hits from Web of Science were a strict subset of the relevant hits from Scopus.

Table 1: Keyword search on Scopus.
term hits filtered hits lottery designs
Term 1 13 12 7
Term 2 44 20 14

Table of results from literature search. See terms below.

• Term 1: (bitcoin OR blockchain) AND (lottery OR lotteries)

1Scopus https://www.scopus.com/
2Web of Science v5.32 https://apps.webofknowledge.com/

3

https://www.scopus.com/
https://apps.webofknowledge.com/


Distributed lottery on Ethereum

• Term 2: (verifiable OR verifiability OR p2p OR ""peer-to-peer"" OR distributed)
AND (lottery or lotteries)

Table 2: Designs of lottery schemes.
from keyword search from references total
19 6 25

1.2.2 Data collection

A working implementation of a distributed lottery was implemented on a local
version of the Ethereum blockchain. This is a fully working proof-of-concept appli-
cation that can be simulated and interacted with in order to collect data and get a
sense of what a live implementation would look like. We collected data of transac-
tion costs necessary to set up a lottery of various sizes by measuring the gas usage
of simulations. We found the number of interactions a participant in the lottery
is needed to perform with the blockchain in order to complete the entire lottery
process successfully. Data for gas price, ether price, and transaction throughput on
the Ethereum blockchain was gathered from Etherscan 3 and ETH Gas Station 4.
Additional data from previous published papers are used when discussing results,
and these will be clearly referenced.

1.2.3 Data analysis

The data collected from simulations were of high quality and did not need pre-
processing. The data will be presented in Chapter 4, and is used as the basis for
analyzing certain properties of our lottery implementation.

1.3 Thesis structure

Chapter 2 introduces the reader to background material relevant to the topics dis-
cussed in the thesis.
Chapter 3 presents the implementation and design choices of the distributed lot-
tery on Ethereum this thesis investigates.
Chapter 4 is about the results generated from experiments with the implementa-
tion and an analysis of the viability and security of the implementation.
Chapter 5 is a discussion on the the work and process that was used when doing
the work for this thesis.
Chapter 6 summarizes the thesis, contains the conclusion, and presents ideas for
future work.

3Etherscan https://etherscan.io/
4ETH Gas Station https://ethgasstation.info/

4

https://etherscan.io/
https://ethgasstation.info/


Distributed lottery on Ethereum

2 Background

2.1 Cryptography

2.1.1 Secure hash functions

Hash functions are deterministic functions that take input of arbitrary finite length,
a preimage, and produce an output of fixed length, a hash [24, p. 153]. When the
length of a preimage is much larger than the output length, the hash function
is effectively a lossy compress function. A hash function can be used for various
purposes, and can be designed to have properties fit for its purpose. A secure hash
function is one that has properties that makes it useful for a range of cryptographic
uses.

Properties of secure hash functions

Collision resistance. A hash function is collision resistant if it is infeasible to find
two preimages m and m′ where m 6= m′ so that Hash(m) = Hash(m′). Such m

and m′ must exist, as the domain of arbitrary length inputs is larger than the range
of fixed length outputs. But the length of outputs in secure hash functions can be
so large that it’s computationally infeasible to find such preimages. A hash func-
tion that is collision resistant will implicitly also be preimage resistant and second-
preimage resistant. Second-preimage resistance means that given a preimage m it
is infeasible to find a m′ 6= m so that Hash(m) = Hash(m′). Preimage resistance
essentially means that a hash function is one-way.
One-way. A secure hash function is a one-way function in that it should not be
possible to find the preimage m given a hash h = Hash(m) by any other means
than guessing all possible m, i.e. a secure hash function should be infeasible to
invert. In cryptographic applications, the one-way property makes it possible to
publicly share hashes of secret preimages without risk of compromising the secrets.
We will see that this can be useful when a secret s at a later point will be revealed,
as it makes it possible to verify that a previously shared hash h is indeed the hash
of a secret by verifying that Hash(s) = h.
Avalanche effect. The avalanche effect is a term used to describe that a small
change in a function’s input will have a large effect on its output. A strict criterion
for the avalanche effect is that any change in the input of a hash function causes
each bit in the output to flip with a probability of 0.5. If similar hashes are more
likely to come from similar preimages, it would be possible to make good guesses
when attempting to reverse a hash function by employing statistical analysis, as

5



Distributed lottery on Ethereum

has been demonstrated in works such as [25].

Some applications of secure hash functions

Hashing to verify message integrity and authenticity. Hash functions can be
used to verify the integrity of a message [24, p. 158–164]. We assume one party,
Alice, has received the hash h of a long message m from a trusted party. Another
party Alice does not trust, Bob, claims to have m and offers to transmit it to Alice.
Since Alice knows the hash of the message, she can retrieve the message from Bob
and independently verify the message’s integrity and authenticity by verifying that
Hash(m) = h. This makes it possible to e.g. retrieve large files from untrusted
parties while only retrieving small hashes from trusted parties.
Hashes as digital fingerprints. The hash of any digital representation of informa-
tion, such as a file, can be considered as practically unique if the hash function is
collision resistant. This enables the hash be used as an identifier or fingerprint. This
is useful in content addressing and resource lookup in distributed file systems. This
concept is also useful for deduplication, as it provides a method for discovering
identical files within a storage system [24, p. 182-183].
Data structures linked by hashes. A block of data can be hashed and addressed
by its hash, as a data block’s hash serve as an identifier. If a data block contains the
hash of another block, we can create acyclic data structures with useful properties
in integrity and authenticity. This can be used to verify membership of some item
in a collection without knowing the entire collection.

A common data structure that uses data linked by hashes is the Merkle tree [26].
A collection of data blocks are ordered in {block0, block1, ..., blockn}. The ordered
items form the leaves of a full binary tree. The collection is padded with empty
items if the number of items is not a power of two. Each internal node is identified
by the hash of the concatenation of its children, and each leaf node by the hash of
its content. The root of any subtree will be a dependent on the data of the items
in its leaf nodes, and a change of the data in any item of the collection will cause
a change in the identifiers of the root of each subtree that contains the item. This
makes it possible to verify that an item exists in a collection if the verifier only
knows the identifier of the root node. A prover needs to provide the item as well
as the identifiers of all nodes in the branch from the root node to the leaf node of
the item.
Hash functions as random oracles. A secure hash function is collision resistant.
The implication of this is that no observer can know the preimage by seeing only the
hash, or feasibly guess the hash of a preimage without calculating it. The avalanche
effect makes it so that the mapping of inputs to outputs form a uniform distribution
of the range with all inputs being independent. This is a stronger assumption than
simply preimage and second preimage resistance, and is not formally proven by

6



Distributed lottery on Ethereum

any hash algorithm [24, p. 179-181]. Still, many applications assume that secure
hash functions’ outputs are uniformly distributed. Since this property is not for-
mally proven, a random oracle model assumption is often made for hash functions.
Under the random oracle model, a given hash function is assumed to have outputs
uniformly distributed and inhibit the avalanche effect.
Hashes in commitment schemes. A party can publish the hash of a message at
some time t to prove that it possessed the message at time t. The committing party
does not need to reveal anything about the message if we assume the hash function
is preimage resistant [24, p. 187–189]. This concept can be used in commitment
schemes [27] to create an unpredictable, but reproducible number that can be used
as a seed to a pseudo-random function. This allows untrusting parties to agree on
random numbers and can be used to implement digital coin tosses [12, 18].
Hashing in proof-of-work (PoW). Under the random oracle model, all values
within the range of a hash function are equally likely to be the output for any
given input. We can define a subspace within the range of any size and know the
probability of finding an input that maps to that subspace. E.g. if the range is all
bitstrings with length l, we can define a subspace of the range to be all bitstrings of
length l where the first z leading bits are zero. The probability of an input mapping
to this subspace will be pz = 1

2z . If we assume that calculating a hash has a cost,
we see that finding an input that maps to a limited range has an expected cost.
This makes it arbitrarily hard rather than infeasible to find a preimage that maps
to a certain subspace. While finding such a preimage may require millions of trials,
verifying that an input maps to the subspace requires only one calculation of the
hash function.

This fact has been used to enforce a price to be paid in number of expected
computations to be executed in some online protocols [28, 29]. In order to prevent
reusing of known hashes, a unique challenge c can be issued to the prover who
pays the price. The prover must produce a hash so that Hash(c||n) ∈ SS where SS
is the subspace, || is the concatenation operator, and n is a nonce which can be any
value.

2.1.2 Digital encryption

Digital encryption is realized by a set of algorithmsEncrypt(m, k)⇒ c and decrypt(c, k)⇒
m. Here, m is a message, c is a cipher and k is a key. A message is securely en-
crypted if it is computationally infeasible to decrypt the message without knowing
k. In symmetric cryptography, the same key is used for encryption and decryption,
while in asymmetric cryptography, different keys are used for encryption and de-
cryption. The former is also known as private-key encryption and is typically used
for secure communication over an insecure channel while the latter is also known

7



Distributed lottery on Ethereum

as public-key encryption and used for both secure communication and to enable
digital signatures.

Public and private key pairs

In [30], Diffie and Hellman describe an interactive protocol that makes it possible
to perform an interactive secure key exchange, often called a handshake, between
parties over an insecure channel where they can securely generate a secret key. In
addition to what became known as the Diffie-Hellman key exchange, the seminal
1976 paper also introduced the concept asymmetric cryptography, and is often con-
sidered to mark the beginning of a cryptographic revolution that made it possible
to use very";"""date"",""2019-06-11T17:56:43Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""8"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.7""
""xmp:CreatorTool"",""pdftk 2.02 - www.pdftk.com""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dcterms:created"",""2019-06-11T17:56:43Z""
""language"",""en""
""Last-Modified"",""2019-06-11T17:56:43Z""
""dcterms:modified"",""2019-06-11T17:56:43Z""
""dc:format"",""application/pdf; version=1.7""
""Last-Save-Date"",""2019-06-11T17:56:43Z""
""pdf:docinfo:creator_tool"",""pdftk 2.02 - www.pdftk.com""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2019-06-11T17:56:43Z""
""meta:save-date"",""2019-06-11T17:56:43Z""
""pdf:encrypted"",""false""
""modified"",""2019-06-11T17:56:43Z""
""Content-Length"",""7882834""
""pdf:hasMarkedContent"",""false""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""meta:creation-date"",""2019-06-11T17:56:43Z""
""created"",""2019-06-11T17:56:43Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""112""
""Creation-Date"",""2019-06-11T17:56:43Z""
""resourceName"",""no.ntnu%3Ainspera%3A2531122.pdf""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""345"",""0"",""327"",""0"",""564"",""0"",""462"",""0"",""1207"",""0"",""419"",""0"",""1622"",""1952"",""615"",""0"",""528"",""0"",""791"",""0"",""556"",""0"",""2228"",""2461"",""1865"",""1704"",""2020"",""2508"",""2391"",""2371"",""2445"",""2381"",""2410"",""2273"",""2323"",""2570"",""2497"",""2559"",""2620"",""2566"",""1929"",""1423"",""2373"",""1500"",""2653"",""2252"",""2429"",""2320"",""2392"",""584"",""1948"",""1490"",""1731"",""2400"",""2213"",""2162"",""1329"",""2093"",""1357"",""1214"",""1896"",""821"",""2072"",""1983"",""2079"",""2122"",""2469"",""2427"",""2298"",""2389"",""2322"",""2503"",""2515"",""2532"",""2473"",""1676"",""2144"",""2448"",""530"",""1412"",""2612"",""2452"",""1959"",""0"",""2121"",""2386"",""910"",""0"",""2316"",""2179"",""1510"",""0"",""1757"",""1798"",""1871"",""1698"",""1995"",""1783"",""820"",""0"",""1105"",""1693"",""1323"",""1681"",""1394"",""1394"",""1372"",""1296"",""1330"",""664"",""961"",""345""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""producer"",""itext-paulo-155 (itextpdf.sf.net-lowagie.com)""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""itext-paulo-155 (itextpdf.sf.net-lowagie.com)""
""pdf:docinfo:created"",""2019-06-11T17:56:43Z""
";https://scholar.google.com/scholar?start=960&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094605-929;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Potential risks of hyperledger fabric smart contracts;K Yamashita, Y Nomura, E Zhou, B Pi… ; … on Blockchain Oriented …, 2019  ieeexplore.ieee.org;;"… developers have to set the seed such as rand.Seed(time.Now().UnixNano()) or use crypto/rand

package … information from the outside of the blockchain, developers need to access an entity called

“oracle,” which provides data about the outside of the blockchain to smart …";Cité 42 fois;Les 2 versions;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/8663509/8666469/08666486.pdf?casa_token=e5tGfi6jp1wAAAAA:RIAhRRvTdHnp-33zKAgMeXaCorrQwm3J1DS-lYJUJ8WzlG0C-hSVYlz4erNjcuds2zupldLnq7I;"
		Skip to Main Content


		
			
				
				

				

			

		


		
			
				
					
						








	
		
	

	







						

						





























	
	
		
	
	
		
			

		
	

	
	
	



						





	
	
		
			
				IEEE Account

					Change Username/Password
	Update Address


			

			
				Purchase Details

					Payment Options
	Order History
	View Purchased Documents


			

			
				Profile Information

					Communications Preferences
	Profession and Education
	Technical Interests


			

			
				Need Help?

					US & Canada: +1 800 678 4333
	Worldwide:  +1 732 981 0060

					
	Contact & Support


			

		

		
			
				
					
							About IEEE Xplore
	Contact Us
	Help
	Accessibility
	Terms of Use
	Nondiscrimination Policy
	Sitemap
	Privacy & Opting Out of Cookies


						
							A not-for-profit organization, IEEE is the world's largest technical professional organization dedicated to advancing technology for the benefit of humanity.
Š Copyright 2021 IEEE - All rights reserved. Use of this web site signifies your agreement to the terms and conditions.
						

					


					

				

				
			

		

	


	
	


						
						






		
		
		
		
		
		
		
		
		
		
		
		
		
			
				
			
			
			
			
		
		
		
		
		
		

			


			

			
			


		
 		
		
			 

						
						









































	

		
		

		
		
		

		
			
		
		
		

		

		
		


		

		
		
		
		
		
		
		
		
		
		
	
	


















		
		
			
				
					
					
								
					
								
			
				
					
					
								
					
								
			
				
					
						








 



					
					
								
			
				
					
					
								
			
				
					
					
								
					
								
			
				
					
					
								
					
								
			
				
					
					
								
					
								
			
				
					
					
								
					
								
			
				
					
					
								
					
								
			
				
					
					
								
					
								
			
		
	




























		
			
					
			
					
			
					
			
				
					








					
			
					
			
					
			
					
			
					
			
					
			
					
			
		
		
	





	
	
	
	
	
	
	


	
	
	

	

















					

				

			


			
				
			
		

	";"""og:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""twitter:title"",""Potential Risks of Hyperledger Fabric Smart Contracts""
""twitter:card"",""summary""
""Description"",""Blockchain is a decentralized ledger technology, and it is the technology underlying Bitcoin and Ethereum. The interest in blockchain has been increasing since ""
""og:title"",""Potential Risks of Hyperledger Fabric Smart Contracts""
""resourceName"",""08666486.pdf""
""language"",""en""
""title"",""Potential Risks of Hyperledger Fabric Smart Contracts | IEEE Conference Publication | IEEE Xplore""
""og:description"",""Blockchain is a decentralized ledger technology, and it is the technology underlying Bitcoin and Ethereum. The interest in blockchain has been increasing since its emergence. Hyperledger Fabric is one of the permissioned blockchain frameworks. One of the characteristics of Hyperledger Fabric is it utilizes general-purpose programming languages, e.g., Go, Node.js, and Java, to implement smart contracts (called chaincode in Hyperledger Fabric). The advantages of utilizing these languages are already known to potential developers, and development tools might already exist. However, one of the disadvantages is that these languages were not originally designed for writing smart contracts. Hence, there may be risks that developers do not need to consider when using specific languages such as Solidity of Ethereum. Furthermore, even though development tools exist, how many risks are covered by the tools is an open question. In this paper, we focus on Go language and the tools. First, we surveyed what kind of risks are associated with chaincodes are developed using Go language and observed there are 14 potential risks. Then, we investigated how many risks can be covered by Go tools, e.g., golint and gosec, and a vulnerability detection tool for chaincodes called Chaincode Scanner. From our results, we observed that some risks are not covered by the existing tools. Hence, we develop a detection tool to cover risks by static analysis. Finally, in this paper, we describe how to find the risks with our tool and evaluate the usefulness.""
""twitter:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-UA-Compatible"",""IE=Edge""
""viewport"",""width=device-width, initial-scale=1.0""
""dc:title"",""Potential Risks of Hyperledger Fabric Smart Contracts | IEEE Conference Publication | IEEE Xplore""
""twitter:description"",""Blockchain is a decentralized ledger technology, and it is the technology underlying Bitcoin and Ethereum. The interest in blockchain has been increasing since its emergence. Hyperledger Fabric is one of the permissioned blockchain frameworks. One of the characteristics of Hyperledger Fabric is it utilizes general-purpose programming languages, e.g., Go, Node.js, and Java, to implement smart contracts (called chaincode in Hyperledger Fabric). The advantages of utilizing these languages are already known to potential developers, and development tools might already exist. However, one of the disadvantages is that these languages were not originally designed for writing smart contracts. Hence, there may be risks that developers do not need to consider when using specific languages such as Solidity of Ethereum. Furthermore, even though development tools exist, how many risks are covered by the tools is an open question. In this paper, we focus on Go language and the tools. First, we surveyed what kind of risks are associated with chaincodes are developed using Go language and observed there are 14 potential risks. Then, we investigated how many risks can be covered by Go tools, e.g., golint and gosec, and a vulnerability detection tool for chaincodes called Chaincode Scanner. From our results, we observed that some risks are not covered by the existing tools. Hence, we develop a detection tool to cover risks by static analysis. Finally, in this paper, we describe how to find the risks with our tool and evaluate the usefulness.""
""Content-Encoding"",""UTF-8""
""Content-Type-Hint"",""text/html; charset=utf-8""
""Content-Length"",""42475""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=740&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094628-1027;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Smart contracts and Internet of things: A qualitative content analysis using the technology-organization-environment framework to identify key-determinants;G Schmitt, A Mladenow, C Strauss… ; Procedia Computer …, 2019  Elsevier;;"… Secondly, smart contracts and blockchain are currently riding a wave of enthusiastic support

but once … When using smart contracts, both parties have to trust that the oracle publishes accurate

data … Firms might prefer to rely on oracles within the organization to have control over …";Cité 7 fois;Les 2 versions;[PDF] sciencedirect.com;https://www.sciencedirect.com/science/article/pii/S1877050919316758/pdf?md5=491956bef9f41587f03be4a4b5a19a87&pid=1-s2.0-S1877050919316758-main.pdf;;;https://scholar.google.com/scholar?start=840&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094569-777;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;PRIMJENE I MOGU?NOSTI BLOCKCHAIN TEHNOLOGIJE SA NAGLASKOM NA PAMETNE UGOVORE: Završni rad;M ?uže ;2019 zir.nsk.hr;;"… ZAVRŠNI RAD PRIMJENE I MOGU?NOSTI BLOCKCHAIN TEHNOLOGIJE SA

NAGLASKOM NA PAMETNE UGOVORE Mentor … 5 2. BLOCKCHAIN

TEHNOLOGIJA – POJAM, KARAKTERISTIKE I ZNA?AJ ..... 6 2.1 …";Autres articles;;[PDF] nsk.hr;https://zir.nsk.hr/islandora/object/efst:3217/datastream/PDF/download;"
PRIMJENE I MOGUĆNOSTI BLOCKCHAIN TEHNOLOGIJE
SA NAGLASKOM NA PAMETNE UGOVORE

Ćuže, Matej

Undergraduate thesis / ZavrĹĄni rad

2019

Degree Grantor / Ustanova koja je dodijelila akademski / stručni stupanj: University of 
Split, Faculty of economics Split / Sveučilište u Splitu, Ekonomski fakultet

Permanent link / Trajna poveznica: https://urn.nsk.hr/urn:nbn:hr:124:619986

Rights / Prava: In copyright

Download date / Datum preuzimanja: 2021-04-28

Repository / Repozitorij:

REFST - Repository of Economics faculty in Split

https://urn.nsk.hr/urn:nbn:hr:124:619986
http://rightsstatements.org/vocab/InC/1.0/
https://repozitorij.efst.unist.hr
https://zir.nsk.hr/islandora/object/efst:3217
https://repozitorij.svkst.unist.hr/islandora/object/efst:3217
https://dabar.srce.hr/islandora/object/efst:3217


SVEUČILIŠTE U SPLITU 

EKONOMSKI FAKULTET 

 

 

 

 

 

 

ZAVRĹ NI RAD 

 

PRIMJENE I MOGUĆNOSTI BLOCKCHAIN 

TEHNOLOGIJE SA NAGLASKOM NA 

PAMETNE UGOVORE 

 

 

 

 

 

 

 

 

 

 

 

 

 

Mentor: Student:                        

izv.prof.dr.sc. Maja Ćukušić Matej Ćuže 

 

Split, lipanj, 2019. 

 



2 

 

SADRŽAJ: 

 

1.UVOD ................................................................................................................ 4 

1.1. Definicija problema ................................................................................................... 5 

1.2. Cilj rada ...................................................................................................................... 5 

1.3. Metode rada ............................................................................................................... 5 

1.4. Strukture rada ........................................................................................................... 5 

2. BLOCKCHAIN TEHNOLOGIJA – POJAM, KARAKTERISTIKE I 

ZNAČAJ ............................................................................................................... 6 

2.1. Pojam blockchain tehnologije ................................................................................... 6 

2.1.1.  Povijest blockchain tehnologije ............................................................................. 7 

2.2. Karakteristike blockchain tehnologije..................................................................... 8 

2.2.1  Kriptografija ............................................................................................................ 8 

2.2.2. Kriptografija u blockchain tehnologiji ............................................................. 9 

2.2.3. Dokaz rada ( „Proof of work“) ....................................................................... 10 

2.2.4. Metoda „Proof of stake“ ................................................................................. 12 

2.2.5. Sigurnost u blockchain tehnologiji ................................................................. 12 

2.2.6. Privatni i javni ključ ....................................................................................... 13 

2.3. Značaj blockchain tehnologije ................................................................................ 15 

3. TRENUTNA PRIMJENA BLOCKCHAIN TEHNOLOGIJE ............. 16 

3.1. Virtualne valute ....................................................................................................... 16 

3.2. Blockchain Hyperledger ............................................................................................. 19 

3.2.1. Privatni i javni blockchain .................................................................................... 19 

3.3. Utjecaj na okoliĹĄ....................................................................................................... 20 

3.4. Blockchain u Republici Hrvatskoj ......................................................................... 21 

4. POTENCIJALNE PRIMJENE BLOCKCHAIN TEHNOLOGIJE .... 22 



3 

 

4.1. Financijski sektor .................................................................................................... 22 

4.2. Zdravstveni sektor ................................................................................................... 24 

4.3. Javna uprava ............................................................................................................ 25 

4.3.1. Evidencija digitalnih identiteta pravnih i fizičkih osoba ................................ 25 

4.3.2. Katastar ........................................................................................................... 25 

4.3.3. Nadzor lanca opskrbe ..................................................................................... 25 

5. PAMETNI UGOVORI – POJAM, KARAKTERISTIKE, ZNAČAJ I 

MOGUĆNOSTI PRIMJENE ........................................................................... 26 

5.1. Pojam pametnog ugovora ....................................................................................... 26 

5.2. Karakteristike pametnih ugovora .......................................................................... 27 

5.2.1. Ethereum platforma ........................................................................................ 27 

5.3. Značaj pametnih ugovora ....................................................................................... 29 

5.4. Mogućnosti primjene pametnih ugovora .............................................................. 30 

5.4.1. Osiguranje ....................................................................................................... 30 

5.4.2. Ugovori o radu ................................................................................................ 30 

5.4.3. Iznajmljivanje i kupoprodaja nekretnina ........................................................ 30 

6. ZAKLJUČAK ............................................................................................ 31 

LITERATURA .................................................................................................. 32 

GRAFIČKI PRILOZI ....................................................................................... 35 

SAŽETAK .......................................................................................................... 36 

SUMMARY ........................................................................................................ 37 

  



4 

 

1.UVOD 

 

U ovome radu će biti objašnjena blockchain tehnologija, njezine trenutne primjene te 

potencijalne mogućnosti primjene u budućnosti. Također poseban naglasak će biti stavljen na 

pametne ugovore, kako na njihovo tehničko uporište u blockchain tehnologiji tako i na njihovu 

potencijalne primjene u ekonomiji. Iako se blockchain tehnologija obično povezuje sa 

virtualnim valutama, posebice sa Bitcoinom, ona je zapravo puno viĹĄe od toga. 

Na temelju ubrzanog razvoja informatike i znanosti općenito u posljednjih nekoliko desetljeća 

došlo je do transformacije gospodarstva iz tradicionalnih načina poslovanja u potpuno ili 

djelomično digitalni način poslovanja. Vrlo važnu ulogu u toj transformaciji su imale i još 

uvijek imaju baze podataka koje su omogućile sveobuhvatno poboljšanje poslovnih procesa u 

globalnoj ekonomiji. Neke djelatnosti kao i pripadajuća radna mjesta su u potpunosti nestala, 

dok su nove djelatnosti nastale i još uvijek nastaju. Uz pomoć baza podataka i interneta koji je 

sve te baze učinio povezanim na globalnoj razini došlo je do značajnih promjena ne samo u 

gospodarstvu nego i u svakodnevnici običnih građana. Plaćanje karticama, podizanje novca na 

bankomatu, korištenje društvenih mreža, putne navigacije i još mnogo toga omogućuju upravo 

povezane baze podataka.  Sve baze podataka se nalaze fizički spremljene negdje na serveru te 

su centralizirane, što znači da u slučaju napada na centralnu jedinicu sustava, svi korisnici te 

baze gube pristup podacima i uslugama te baze. Zbog toga podatkovni centri su strogo čuvani 

i štićeni od fizičkih napada i kibernetičkih napada. Također postavlja se pitanje povjerenja i 

pouzdanosti administratora te baze podataka zbog same prirode čovjeka čiji osobni interesi nisu 

uvijek u skladu sa općim interesom korisnika te baze podataka tzv. „moral hazard“.  

Javlja se i kontradikcija između privatnosti korisnika i transparentnosti prilikom upravljanja 

bazom. U slučaju povećanja transparentnosti dolazi do povećanog otkrivanja osjetljivih 

podataka iz baze te povećanja sigurnosne ranjivosti baze.  

Razlog spominjanja baza podataka u ovome radu je upravo taj ĹĄto je i sam blockchain zapravo 

baza podataka koja ima potencijal rijeĹĄiti sve gore navedene nedostatke tradicionalnih baza. 

Upravo zbog toga blockchain nalazi toliko raznih mogućnosti primjene jer zapravo omogućava 

zamjenu tradicionalnih baza podataka koje se posvuda koriste sa novim i naprednijim tipom 

baze. 

U ovom radu će biti objašnjeno na koji način blockchain tehnologija rješava nedostatke 

tradicionalnih centraliziranih baza podataka i omogućava unapređenje svih procesa koji se 

odvijaju u druĹĄtvu te posebno u globalnom gospodarstvu. 



5 

 

1.1. Definicija problema 

 

Blockchain kao tehnologija postaje sve prisutnija u svakodnevnom Ĺživotu, posebice u 

financijskom sektoru u obliku virtualnih valuta. 

Ovaj rad raspravlja o trenutnoj primjeni ove tehnologije te o potencijalnim mogućnostima 

primjene blockchain tehnologije na druge sektore gospodarstva. 

Naglasak je stavljen na pametne ugovore kojima je glavna odlika uklanjanje posrednika iz 

transakcija, samim time i značajno smanjenje troškova. 

 

1.2.  Cilj rada 

 

Ciljevi ovog zavrĹĄnog rada su istraĹžiti i objasniti trenutnu primjenu blockchain tehnologije te 

predložiti mogućnosti primjene tehnologije u drugim sektorima, posebice kroz model pametnih 

ugovora te budućnost blockchain tehnologije. 

 

1.3. Metode rada 

 

Za izradu ovoga rada koristit će se sljedeće metode: analiza, sinteza, eksplanacija ,klasifikacija 

i komparacija. 

 

1.4. Strukture rada 

 

Rad se sastoji od ukupno ĹĄest poglavlja. Prvo poglavlje je uvod, drugo poglavlje objaĹĄnjava 

blockchain tehnologiju kao takvu te njezina tehnička uporišta kao kriptografiju, hash funkcije, 

sigurnosne aspektne i opće karakteristike. U trećem poglavlju se izlažu trenutne primjene 

blockchain tehnologije sa naglaskom na primjene u virtualnim valutama, pametnim ugovorima 

i financijskim uslugama. Četvrto poglavlje se bavi mogućnostima primjene tehnologije u 

budućnosti kroz primjene u medicini, javnoj upravi, lancima opskrbe, utvrđivanju porijekla 

robe i raznim drugim primjenama. Naposljetku u petom poglavlju detaljno se objaĹĄnjavaju 

pametni ugovori, njihove tehničke karakteristike te Ethereum platforma za programiranje 

ugovora. Također istražuju se potencijale mogućnosti primjene pametnih ugovora u budućnosti 

te nedostatke koje tek treba rijeĹĄiti. 



6 

 

2. BLOCKCHAIN TEHNOLOGIJA – POJAM, KARAKTERISTIKE I 

ZNAČAJ 

 

2.1. Pojam blockchain tehnologije 

 

Po definiciji blockchain je lista blokova u kojima su zapisani podaci, a sami blokovi su povezani 

pomoću kriptografije na način da se sprječava promjena podataka u blokovima koji su već 

dodani na lanac. Svaki blok sadržava takozvani kriptografski „hash“ prethodnog bloka, vrijeme 

kada je nastao „timestamp“ i podatke o transakciji. 

Blockchain se može zamisliti kao otvorenu knjigu u koju se upisuju transakcije između dvije 

strane, koje se verificiraju prije upisa i ostaju trajno zapisane u blockchainu. PoĹĄto se radi o 

otvorenoj i distribuiranoj knjizi da bi se spriječilo upisivanje pogrešnih podataka potreban je 

validacija tj. provjera istinitosti podataka prije dodavanja novog bloka koji sadrĹži te podatke 

više od pola sudionika koji su uključeni u validaciju novog bloka.1 

Blockchain se najbolje može objasniti na primjeru bitcoin transakcije između dvije osobe, neka 

se zovu Ivica i Marica. Ivica Ĺželi poslati 10 bitcoina Marici. Sve ĹĄto je potrebno za slanje je da 

Ivica zna adresu novčanika od Marice te da upiše iznos koji želi poslati. Nakon što Ivica obznani 

transakciju ostatku mreže u proces transakcije se uključuju „rudari“ koji provjeravaju 

ispravnost zadane transakcije. Točnije provjeravaju ima li Ivica zaista 10 bitcoina koje želi 

poslati.  PoĹĄto se rad o lancu blokova potrebno je zapravo provjeriti ulazne i izlazne transakcije 

i utvrditi ima li Ivica 10 ili više bitcoina kako bi mogao izvršiti transakciju. „Rudari“ koji 

obavljaju ovaj posao su motivirani time što za svaku verifikaciju prime određenu količinu 

virtualne valute tako da mogu pokriti troĹĄak infrastrukture i energije uloĹžene u sami proces 

verifikacije. Druga vrsta nagrade za „rudare“ je tzv. „miner fee“ koji određuju sami korisnici. 

Svrha ove naknade je dodatna motivacija „rudarima“ da brže verificiraju određenu transakciju. 

Transakciju je moguće zadati i bez dodatne naknade, ali posljedica toga je sporija verifikacija. 

Nakon što „rudari“ verificiraju transakciju blok se nadoda na lanac i time je transakcija završila. 

U slučaju pokušaja prevare mreže u smislu da Ivica pokuša poslati 10 bitcoina kojih zapravo 

nema mreža će odbiti transakciju.  Da bi se transakcija verificirala potrebna je suglasnost više 

od pola mreže „rudara“ što osigurava povjerenje u sustav sve dok je pola rudara „pošteno“. 

U slučaju manipulacije sa više od 50% rudara mreža bi postala nepovjerljiva. 2  

                                                 
1 https://en.wikipedia.org/wiki/Blockchain ( pristupljeno 10.06.2019.) 
2 https://www.bug.hr/tehnologije/sto-je-u-stvari-blockchain-i-kako-radi-3011 ( pristupljeno 10.06.2019.) 

https://www.bug.hr/tehnologije/sto-je-u-stvari-blockchain-i-kako-radi-3011


7 

 

2.1.1.  Povijest blockchain tehnologije 

 

Početak blockchain tehnologije seže u 1991. godinu kada su Stuart Haber i W. Scott Stornetta  

objavili rad na temu lanca blokova povezanih pomoću kriptografskih metoda. Jedna od prvih 

implementacija ovih ideja je nastala u obliku bitcoin virtualne valute.  U objavljenom „white 

paper“ dokumentu nepoznati autor ili skupina njih pod imenom Satoshi Nakamoto objavila je 

dokument u kojem je uvedeno poboljĹĄanje sustava kroz hashcash metodu. Dizajn je 2009. 

godine implementiran u virtualnu valutu bitcoin baziranu na blockchain tehnologiji. Također je 

zanimljivo napomenuti da je u izvornom „white paper“ dokumentu na kojem se temelji 

blockchain i virtualne valute termin pisan razdvojeno „block chain“ , no ipak vremenom se 

ustalila inačica blockchain.   3 

Bitno je također spomenuti i pojavu Ethereum sustava koji je iniciran od strane Vitalika 

Buterina koji je jedan od programera koji je radio na bitcoin sustavu. Vitalik Buterin je inicirao 

Ethereum blockchain zbog limitiranosti bitcoin sustava. Za razliku od bitcoina, ethereum 

blockchain omogućava programiranje pametnih ugovora, pozajmica i sličnih instrumenata. To 

omogućava široku paletu potencijalnim primjena u gospodarstvu što prepoznaju i velike 

kompanije koje uočavaju potencijal pametnih ugovora u svrhu smanjenja troškova i povećanja 

efikasnost poslovanja.  

Ethereum sustav je počeo sa radom u 2015. godini.4 

 

  

 

 

 

 

 

 

 

 

                                                 
3 https://en.wikipedia.org/wiki/Blockchain  ( pristupljeno 10.06.2019.) 
4https://www.forbes.com/sites/bernardmarr/2018/02/16/a-very-brief-history-of-blockchain-technology-everyone-

should-read/#1d8f7c157bc4 ( pristupljeno 10.06.2019.) 

https://en.wikipedia.org/wiki/Blockchain
https://www.forbes.com/sites/bernardmarr/2018/02/16/a-very-brief-history-of-blockchain-technology-everyone-should-read/#1d8f7c157bc4
https://www.forbes.com/sites/bernardmarr/2018/02/16/a-very-brief-history-of-blockchain-technology-everyone-should-read/#1d8f7c157bc4


8 

 

2.2. Karakteristike blockchain tehnologije 

 

Glavna karakteristika blockchaina je da je potpuno decentraliziran, što znači da nema vlasnika, 

nema fizičku adresu niti je kontroliran od stane neke institucije ili organizacije. Blockchain 

može koristiti svatko, bez ograničenja i bez potrebe za osobnim podacima korisnika sustava. 

Kao što je već spomenuto blockchain je zapravo baza podatak koja sadrži podatke, najčešće o 

financijskim transakcijama kao u slučaju bitcoin blockchaina.  

 

Glavno pitanje koje proizlazi iz gore navedenog je na koji se način ovaj sustav koji nema jasnog 

regulatora odrĹžava sigurnim.  

Tri su ključna faktora koja osiguravaju sigurnost blockchaina: 

• Kriptografija 

• Rudarenje 

• Decentraliziran i distribuiran sustav 

U nastavku će se služiti primjerom virtualnih valuta  u svrhu objašnjenja karakteristika 

sveukupne tehnologije koja stoji iza blockchaina. 5 

 

2.2.1  Kriptografija 

 

Definicija kriptografije glasi: „Kriptografija je znanstvena disciplina koja se bavi proučavanjem 

metoda za slanje poruka u takvom obliku da ih samo onaj kome su namijenjene može pročitati.„ 

Kriptografija ima dugu povijest, te je već korištena kod starih Grka i Rimljana.  

Svrha kriptografije je omogućiti dvjema osobama komunikaciju putem nesigurnog kanala tako 

da osoba koja ima pristup tom kanalu ne moĹže razumjeti poruke koje osobe izmjenjuju. 

Nakon što primalac primi tekst koji je šifriran potrebno je znati unaprijed dogovoreni ključ 

pomoću kojeg je moguće pročitati pravo značenje teksta.  Kriptografski algoritam označava 

matematičku funkciju koja služi za šifriranje i dešifriranje.  U kriptografiji se također 

primjenjuju javni i privatni ključ. Kod asimetričnih kriptosustava imamo javni ključ koji je 

svima dostupan za šifriranje ali iz njega se ne može praktično izračunati ključ za dešifriranje.  6 

 

                                                 
5 https://www.netokracija.com/sto-je-blockchain-132284 ( pristupljeno 10.06.2019.) 
6 https://web.math.pmf.unizg.hr/~duje/kript/osnovni.html ( pristupljeno 10.06.2019.) 

https://www.netokracija.com/sto-je-blockchain-132284
https://web.math.pmf.unizg.hr/~duje/kript/osnovni.html


9 

 

2.2.2. Kriptografija u blockchain tehnologiji 

 

Svaki blok je zapravo paket koji sadrĹži podatke, odnosno sadrĹži podatke o transakcijama u 

nekom vremenu. Blokovi se vežu jedan na drugi uz pomoć kriptografskog potpisa koji ima istu 

vrijednost na starom i na novom bloku. Taj potpis se zove hash. Hash je zapravo niz znakova 

koji na prvi pogled nemaju smisla. Ti znakovi su dobiveni uz pomoć složene hash matematičke 

funkcije koja bilo koji digitalni sadržaj putem matematičkih operacija pretvara u digitalni 

potpis. Tako možemo od bilo koje slike, pdf dokumenta ili nekog brojčanog zapisa dobiti hash. 

Bitna karakteristika hasha je da je uvijek iste duljine, nebitno o vrsti i količini ulaznih podataka. 

Bitno je također naglasiti da ako na iste datoteke primjenjujemo hash funkciju da ćemo uvijek 

dobiti isti hash. No ako se i najmanji dio te datoteke izmjeni, dobiveni hash će izgledati potpuno 

različito. U prikazu ispod možemo vidjeti primjer hash funkcije te na koji način dodavanje samo 

zareza uzrokuje potpuno različit rezultat.7 U ovome primjeru ćemo koristiti hash funkciju SH – 

256. 

 

 

Slika 1: Rezultat hash funkcije 

Izvor: http://www.sha1-online.com/ 

 

 

Slika 2: Rezultat hash funkcije nakon dodavanja zareza 

Izvor: http://www.sha1-online.com/ 

                                                 
7 https://www.netokracija.com/sto-je-blockchain-132284 ( pristupljeno 13.06.2019.) 

https://www.netokracija.com/sto-je-blockchain-132284


10 

 

U blockchain sustavu na ovaj način se potpisuju blokovi sa transakcijama. Generirani potpis na 

bloku automatski postaje dio sadržaja idućeg bloka. U slučaju pokušaja izmjene podataka u 

bloku, to automatski uzrokuje neispravnost potpisa. Ako napadač pokuša generirati ispravan 

potpis preko hash funkcije za izmijenjene podatke, dolazi automatski do greške u idućem bloku 

jer je on potpisan hash vrijednošću koja je dobivena na osnovu starog potpisa. Samim time idući 

blok postaje neispravan. Na taj način se u slučaju napada događa lančana reakcija, što znači da 

napad na blockchain ne može ostati neprimijećen. Ova osobina blockchain tehnologije je jedna 

od glavnih poluga sigurnosti cijelog sustava.8 

 

2.2.3. Dokaz rada ( „Proof of work“) 

 

Dokaz rada ili proof of work na engleskom jeziku je još jedna postavka koja omogućuje 

sigurnost blockchain sustava. Naime, izvrĹĄavanje hash funkcije ne iziskuje veliku procesorsku 

snagu računala. Samim time se otvara mogućnost napada na blockchain jer je moguće 

istovremeno promijeniti sve potpise u lancu i na taj način uspješno manipulirati cijelim 

sustavom. No idejni tvorci Blockchain su uspjeli riješiti i taj problem na način da blok nije 

moguće potpisati sa bilo kojim hash vrijednošću. Da bi hash bio valjan, mora počinjati sa 

određenim brojem nula. 9 

U hash funkcija ulaze sljedeće varijable: 

• indeks bloka 

• hash prethodnog bloka 

• podaci o transakciji 

• nonce ili promjenjiva vrijednost 

 

Varijabla nonce je jedina varijabla koju ju dopuĹĄteno mijenjati od svih podataka koji ulaze u 

hash funkciju. Pošto je hash vrijednost vrlo jednostavno izračunati postavlja se pitanje zašto 

rudari troše toliko sredstava na infrastrukturu i na električnu energiju za verificiranje novih 

blokova. Razlog tome leži u već spomenutoj postavki blockchaina da hash mora počinjati sa 

određenim brojem nula. Parametar koji se koristi kao mjera težine izračuna se zove „difficulty“. 

Kada algoritam odluči da novi blok mora imati na početku četiri nule, rudar mora tražiti hash 

sve dok ne zadovolji zadani kriterij. Od svih varijabli koje ulaze u hash funkciju jedino se smije 

                                                 
8 https://www.netokracija.com/sto-je-blockchain-132284 ( pristupljeno 14.06.2019.) 
9 https://www.netokracija.com/sto-je-blockchain-132284 ( pristupljeno 14.06.2019.) 

https://www.netokracija.com/sto-je-blockchain-132284
https://www.netokracija.com/sto-je-blockchain-132284


11 

 

mijenjati nonce varijabla. Mijenjanje vrijednosti nonce varijable je jedini način da se dođe do 

traĹžene hash vrijednosti. Nakon pronalaska ispravne vrijednosti rudar ĹĄalje prema mreĹži 

ispravan hash. Cilj algoritma unutar mreĹže je da se novi blok generira svakih 10 minuta. 

Algoritam mijenja težinu izračuna na bazi prethodnih 2016 generiranih blokova. Sama 

zahtjevnost izračuna je jako bitna jer čini mogućnost prevare težom. 10  

Također bitno je spomenuti i pojam „Hash rate“ ili „Hash power“ odnosno koliko hash 

vrijednosti neki rudar generira u jednoj sekundi. Na primjer, računalo koje generira 60 hash 

vrijednosti u sekundi ima „hash rate“  60.  Za same rudare bitno je nekoliko faktora koji utječu 

na samu profitabilnost djelatnosti. To su ponajprije cijena električne energije i cijena 

infrastrukture za rudarenje. 11 

U početku bitcoin blockchaina bilo je moguće rudariti i uz pomoć osobnog računala dok se sada 

na tržištu mogu naći specijalizirani ASIC uređaji bez kojih rudarenje nema isplativosti.  Cijene 

navedenih uređaja se kreću od 500 američkih dolara pa do nekoliko tisuća dolara. Za uspješnije 

rudarenje mnogi se udružuju u takozvane bazene rudara ili „mining pool“ na način da udruže 

procesorsku snagu i tako ostvaruju prednost ispred ostalih individualnih rudara.12 

 

 

Slika 3: TeĹžina rudarenja na bitcoin blockchainu 

Izvor: https://www.blockchain.com/en/charts/difficulty?timespan=all 

 

 

 

                                                 
10 https://www.bug.hr/tehnologije/sto-je-u-stvari-blockchain-i-kako-radi-3011 ( pristupljeno 14.06.2019.) 
11 https://www.buybitcoinworldwide.com/mining/hash-rate/ ( pristupljeno 14.06.2019.) 
12 https://www.investopedia.com/terms/b/bitcoin-mining.asp ( pristupljeno 14.06.2019.) 

https://www.bug.hr/tehnologije/sto-je-u-stvari-blockchain-i-kako-radi-3011
https://www.buybitcoinworldwide.com/mining/hash-rate/
https://www.investopedia.com/terms/b/bitcoin-mining.asp


12 

 

2.2.4.  Metoda „Proof of stake“  

 

Metoda dokaza rada je prvotni princip kojeg je osmislio Satoshi Nakamoto čime je riješen 

problem vjerodostojnosti. Problem metode dokaza rada je taj ĹĄto se troĹĄi iznimno puno 

električne energije i procesorske snage pošto se svi rudari natječu tko će prvi naći ispravnu hash 

vrijednost. Metoda  „Proof of stake “ nudi potencijalno rješenje za navedene nedostatke. Ova 

metoda se temelji na ulaganju postojećih virtualnih kovanica čime se ostvariva pravo na 

sudjelovanje u verifikaciji transakcija u mreĹži. Zarada tim korisnicima dolazi od transakcijske 

naknade koju plaćaju drugi korisnici kada transferiraju virtulanu valutu drugom korisniku. No, 

ipak postoje mnogi potencijalni nedostatci kod ove metoda, najprije mogućnost da rudar 

istovremeno verificira viĹĄe blokova poĹĄto nema troĹĄka energije i resursa da se blok potpiĹĄe kao 

u metodi dokaza rada.13 

 

2.2.5. Sigurnost u blockchain tehnologiji 

 

Blockchain se među njegovim zagovornicima smatra za jednim o najboljih načina za osiguranje 

transakcija. Razlog tome je što je svaki blok koji sadrži podatke koji su najčešće transakcije 

povezan sa svim blokovima ispred i iza sebe. Samim time jako je teĹĄko promijeniti jedan zapis 

jer bi to značilo da treba mijenjati i zapise u povezanim blokovima. Zapisi na blockchainu su 

osigurani putem kriptografije. Sudionici mreže imaju svoj privatni ključ koji je povezan na 

njihove transakcije i služi kao osobni digitalni potpis. U slučaju promjene zapisa, potpis će 

postat nevaljan te će cijela mreža odmah saznati da se nešto dogodilo. U cijelom procesu je 

bitno da je mreža brzo obaviještena kako bi se spriječila zloupotreba. 

Također još jedna temeljna postavka blockchain tehnologije je distribuiranost blockchaina 

preko cijele mreže. To mu omogućava svojstvo da nema takozvane „single point of failure“ 

odnosno da se mreĹžom ne moĹže manipulirati sa jednog mjesta u sustavu.14 

Jedna od mogućih sigurnosnih ugroza za blockchain je „51% napad“. Pretpostavimo da napadač 

želi manipulirati mrežom tako da može dva puta potrošiti neku količinu virtualne valute. Kako 

bi to uspio napadač mora izgraditi lanac koji je dulji od istinitog lanca i počinje se odvajati prije 

trenutka kad je potroĹĄio virtualnu valutu. Da bi napad bio uspjeĹĄan svi bi se blokovi morali 

                                                 
13 https://www.bug.hr/tehnologije/sto-je-u-stvari-blockchain-i-kako-radi-3011 ( pristupljeno 14.06.2019.) 
14https://www.ibm.com/blogs/blockchain/2017/12/blockchain-security-what-keeps-your-transaction-data-safe/     

( pristupljeno 14.06.2019.) 

https://www.bug.hr/tehnologije/sto-je-u-stvari-blockchain-i-kako-radi-3011
https://www.ibm.com/blogs/blockchain/2017/12/blockchain-security-what-keeps-your-transaction-data-safe/


13 

 

ponovno verificirati, a pošto je za to potrebna ogromna procesorska snaga koja bi nadjačala 

ostatak „poštenih“ korisnika mreže, napada je skoro nemoguće izvesti. 15 

 

2.2.6. Privatni i javni ključ 

 

Privatni ključ je oblik kriptografskog zapisa koji omogućava korisnica pristup podacima koji 

su dostupni samo njima. Upotreba privatnog ključa je jedan od temeljnih dijelova cijele 

blockchain tehnologije. Kod virtualnih valuta svaki korisnik ima javnu adresu i privatni ključ. 

Javni ključ je kreiran od privatnog ključa uz pomoć kompleksnih matematičkih operacija, no 

praktično nije moguće od javnog ključa operacijama dobiti privatni ključ. 

Privatni ključ im nekoliko različitih formi, obično kao niz brojeva i slova. Sustav privatnog i 

javnog ključa se najbolje može objasniti uz pomoć primjera poštanskog sandučića. Javni ključ  

je kao adresa koju svatko zna i svatko može ubaciti u sandučić što god želi ali samo osoba koja 

ima ključ od sandučića može upravljati sadržajem istog. Zbog toga je bitno čuvati privatni ključ 

na sigurnom. Digitalni novčanik sprema privatni ključ od korisnika. Kada dođe do transakcije, 

digitalni novčanik kreira digitalni potpis iz privatnog ključa. Potpis služi kako bi se potvrdilo 

da transakcija dolazi od nekog korisnika i osigurava da je nije moguće kasnije promijeniti. Ako 

korisnik izgubi privatni ključ više nije moguće pristupiti niti upravljati svojim računom. 

Privatni ključ se može spremiti na eksternoj memoriji, u obliku QR koda ili ga samo isprintati 

na papir. Ključ se može spremiti i putem servisa koji su povezani na internet kao na primjer na 

mobilne novčanike.  16  

 

 

Slika 4: Primjer privatnog ključa u bitcoin blockchainu 

Izvor: https://en.bitcoin.it/wiki/Private_key 

  

Iz privatnog ključa se generira javni ključ, a iz javnog ključa se skraćivanjem dolazi od javne 

adrese. Razlog skraćivanju je iznimno dug niz simbola koji sadrži javni ključ.  

Da bi se moglo ući u interakciju sa drugim korisnikom potrebno je obznaniti javnu adresu. 

Javna adresa se može shvatiti kao broj bankovnog računa. Pošiljatelj mora znati broj računa 

                                                 
15 Kraft, D. (2015); Difficulty Control for Blockchain-Based Consensus Systems, University of Graz, Graz, str. 3 
16 https://www.investopedia.com/terms/p/private-key.asp ( pristupljeno 15.06.2019.) 

https://www.investopedia.com/terms/p/private-key.asp


14 

 

kako bi mogao poslati novac dok primatelj ima privatni ključ koji mu omogućuje pristup tim 

sredstvima.17 

 

  

Slika 5: Javni ključ, privatni ključ i javna adresa 

Izvor: https://www.oreilly.com/library/view/mastering-bitcoin-2nd/9781491954379/ch04.html  

 

 

 

Slika 6: Javni ključ 

Izvor: https://www.comodo.com/resources/small-business/digital-certificates2.php  

 

 

 

Slika 7: Javna adresa 

Izvor: https://en.bitcoin.it/wiki/Address 

 

 

 

 

 

 

 

 

 

 

 

                                                 
17 https://www.investopedia.com/terms/p/public-key.asp ( pristupljeno 14.06.2019.) 

https://www.oreilly.com/library/view/mastering-bitcoin-2nd/9781491954379/ch04.html
https://www.comodo.com/resources/small-business/digital-certificates2.php
https://en.bitcoin.it/wiki/Address
https://www.investopedia.com/terms/p/public-key.asp


15 

 

2.3. Značaj blockchain tehnologije 

 

Značaj same tehnologije se ogleda u njezinoj univerzalnosti primjene. Internet je donio 

revoluciju u sve slojeve Ĺživota. Ta revolucija se i dalje oslanja velikim dijelom na baze 

podataka. Samim time ĹĄto je blockchain distribuirana baza podataka koja nosi mnoge prednosti 

u odnosu na klasičnu organizaciju i upravljanje podacima, ima veliki potencijal i bezbrojne 

mogućnosti primjene. Blockchain je već postao novac za internet i može postati „Internet of 

Money“ za financijske usluge spajajući korisnike na isti način na koji su spojeni uređaji u 

„Internet of things“ mreži. 18 Unatoč tome utjecaj virtualnih valuta na globalnoj razini je 

zanemariv. Na dan 14. prosinca 2017. u svijetu je bitcoinom provedeno oko 490 tisuća 

transakcija dok je ukupan broj prosječnih dnevnih bezgotovinskih platnih transakcija u 2016. 

godini samo u europodručju iznosio 484  milijuna, a u cijeloj 2016. godini provedene su 122 

milijarde platnih transakcija  

U Republici Hrvatskoj prosječno se dnevno izvrši više od 2,9 milijuna bezgotovinskih 

transakcija.  

Iz navedenog je jasno da su transakcije bitcoinom kao glavnim predstavnikom virtualnih valuta 

zanemarive na ukupan broj transakcija. Prema HNB-u upotreba virtualnih valuta u sadaĹĄnjem 

opsegu ne donosi rizik za provođenje ključnih ciljeva središnje banke poput stabilnosti cijena, 

financijske stabilnosti bankovnog sustava i stabilnosti platnog prometa19.  

 

 

Slika 8: Broj transakcija na bitcoin blockchainu 

Izvor: https://www.blockchain.com/en/charts/n-transactions?timespan=all 

                                                 
18 Swan, M. (2015): Blockchain: Blueprint for a New Economy, O'Reilly Media, Sebastopol, str. 5. 
19 https://www.hnb.hr/-/sto-su-virtualne-valute- ( pristupljeno 16.06.2019.) 

https://www.blockchain.com/en/charts/n-transactions?timespan=all


16 

 

3. TRENUTNA PRIMJENA BLOCKC";"""date"",""2021-04-28T09:49:41Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.4""
""xmp:CreatorTool"",""MicrosoftÂŽ Word for Office 365""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dc:creator"",""Matej""
""language"",""hr""
""dcterms:created"",""2021-04-28T09:49:41Z""
""Last-Modified"",""2021-04-28T09:49:41Z""
""dcterms:modified"",""2021-04-28T09:49:41Z""
""dc:format"",""application/pdf; version=1.4""
""xmpMM:DocumentID"",""uuid:F198675F-CE13-4E11-88ED-16E9D51C5AE0""
""Last-Save-Date"",""2021-04-28T09:49:41Z""
""pdf:docinfo:creator_tool"",""MicrosoftÂŽ Word for Office 365""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2021-04-28T09:49:41Z""
""meta:save-date"",""2021-04-28T09:49:41Z""
""pdf:encrypted"",""false""
""xmp:CreateDate"",""2019-06-29T15:59:20Z""
""modified"",""2021-04-28T09:49:41Z""
""Content-Length"",""1167130""
""pdf:hasMarkedContent"",""true""
""Content-Type"",""application/pdf""
""xmp:ModifyDate"",""2019-06-29T15:59:20Z""
""pdf:docinfo:creator"",""Matej""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Matej""
""dc:language"",""en-GB""
""meta:author"",""Matej""
""pdf:producer"",""MicrosoftÂŽ Word for Office 365""
""meta:creation-date"",""2021-04-28T09:49:41Z""
""created"",""2021-04-28T09:49:41Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""38""
""Creation-Date"",""2021-04-28T09:49:41Z""
""resourceName"",""download""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""506"",""252"",""2745"",""2385"",""2678"",""1717"",""2701"",""1712"",""2040"",""1386"",""2325"",""1738"",""2583"",""2330"",""571"",""1781"",""1320"",""1977"",""820"",""2044"",""1209"",""1195"",""2270"",""2080"",""1865"",""1923"",""2361"",""2231"",""1014"",""1705"",""2004"",""1259"",""1425"",""2229"",""1838"",""1870"",""1352"",""1198""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""Author"",""Matej""
""producer"",""dompdf 0.8.6
 + CPDF""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""dompdf 0.8.6
 + CPDF""
""pdf:docinfo:created"",""2021-04-28T09:49:41Z""
";https://scholar.google.com/scholar?start=590&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094572-787;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Revisiting post-quantum fiat-shamir;Q Liu, M Zhandry ; Annual International Cryptology Conference, 2019  Springer;;"… CRYPTO 2019: Advances in Cryptology – CRYPTO 2019 pp 326-355 | Cite as … a useful approach

to building non-interactive arguments (of knowledge) in the random oracle model … rewinding,

and (2) the inability of current techniques to adaptively program random oracles in the …";Cité 58 fois;Les 6 versions;[PDF] nsf.gov;https://par.nsf.gov/servlets/purl/10164788;"
Revisiting Post-Quantum Fiat-Shamir

Qipeng Liu1, Mark Zhandry1

Princeton University, Princeton NJ 08544, USA

Abstract. The Fiat-Shamir transformation is a useful approach to building non-interactive arguments
(of knowledge) in the random oracle model. Unfortunately, existing proof techniques are incapable of
proving the security of Fiat-Shamir in the quantum setting. The problem stems from (1) the difficulty of
quantum rewinding, and (2) the inability of current techniques to adaptively program random oracles
in the quantum setting.
In this work, we show how to overcome the limitations above in many settings. In particular, we give
mild conditions under which Fiat-Shamir is secure in the quantum setting. As an application, we show
that existing lattice signatures based on Fiat-Shamir are secure without any modifications.

1 Introduction

The Fiat-Shamir transformation is an approach to remove interaction in a protocol by using a hash function,
by setting one party’s messages to be hashes of the communication transcript. The transformation has many
important applications, from removing interaction from proofs to constructing efficient signatures.

With the growing threat of quantum computers, there is great need for so-called “post quantum” cryp-
tosystems, those secure against quantum attack. In the case of signatures, the most efficient construc-
tions [DKL+18] use the Fiat-Shamir transformation [FS87]. Fiat-Shamir is a general tool to remove in-
teraction from interactive protocols using a hash function.

Classically, the security of the transform is proved in the classical random oracle model (ROM) [BR93,
PS96]. Here, the hash function is replaced with a truly random function that can only be evaluated by query
access. As argued by Boneh et al. [BDF+11], the correct way to model random oracles in the quantum
setting is to allow quantum queries to the random oracle. While many techniques have been developed to
prove security in the quantum ROM [BDF+11, Zha12, BZ13, Unr17, TU15, Unr15, KLS18, Zha18], to date
the post-quantum security of general Fiat-Shamir remains unresolved.

In fact, there has been some compelling justification for this state of affiars. Dagdelen, Fischlin, and
Gagliardoni [DFG13] demonstrate that there cannot be a reduction with certain natural features (dis-
cussed below) which capture many of the existing techniques. What’s more, Ambainis, Rosmanis, and Un-
ruh [ARU14] show that many classical results about Fiat-Shamir that rely on rewinding are simply false in
the quantum setting. In particular, they show that special soundness is insufficient to prove the security of
Fiat-Shamir in the quantum ROM.

As a result, authors have proposed various ways to strengthen the underlying protocol so that post-
quantum Fiat-Shamir can be proved (e.g. [DFG13, Unr17, KLS18]) or use an alternative transformation
altogether (e.g. [Unr15]). However, in all cases, this leads to a less efficient and less elegant scheme.

1.1 Summary of Results

In this work, we revisit Fiat-Shamir, showing that in many cases Fiat-Shamir can be successfully applied for
post-quantum security without modifying the underlying protocols.

Our results come in two parts. The first set of results concerns the Fiat-Shamir transformation itself,
resurrecting standard classical results in the quantum ROM:

– If the underlying protocol is an argument (of knowledge), then Fiat-Shamir gives an argument (of knowl-
edge).



– If the underlying protocol is a secure identification scheme, then Fiat-Shamir gives a secure signature
scheme.

These results do not require making any additional assumptions on the underlying protocol than what
is needed classically (other than, of course, needing security to hold against quantum adversaries).

These results overcome the barrier of Dagdelen, Fischlin, and Gagliardoni [DFG13] by giving a proof
that is outside the class of natural reductions they consider. On the other hand, the results side-step the
rewinding barrier of Ambainis, Rosmanis, and Unruh [ARU14], as the rewinding barrier already applies to
the security of the underlying protocol.

Our second set of results concerns overcoming the rewinding barrier of [ARU14]. Classically, 2-soundness/2-
extractability1 are often used to prove that a protocol is an argument/argument of knowledge. While [ARU14]
show that in general these conditions are insufficient in the quantum setting, we show the following:

– We define a notion of collapsing for a protocol which is similar to the notion of collapsing for hash
functions [Unr16b].

– Abstracting a result of Unruh [Unr16b], we show that the usual classical results carry over to the quantum
setting, provided the protocol is collapsing. That is, 2-soundness plus collapsing implies an argument,
and 2-extractability plus collapsing implies an argument of knowledge.

– Next, we give two weaker conditions, either of which are sufficient for a protocol to be collapsing. The
first is that the protocol has an associated lossy function with certain properties. The second is that the
protocol is separable, a new notion we define.

– Finally, we then show that the lattice-based protocol of Lyubashevsky [Lyu12] is separable under the
LWE assumption. Piecing together with our other results, we demonstrate that Lyubashevsky’s protocol
is secure in the quantum random oracle model without any modifications. These results naturally extend
to protocols built from this protocol, such as [DKL+18].

A key feature of our results is that they can be used as a black box without requiring the complicated
details of quantum computing. In particular, the needed security properties are 2-soundness/2-extractability
and associated lossy functions/separability. These properties are essentially classical in nature (except for
having to hold with respect to quantum adversaries) and can be proved using classical proof techniques, and
trivially porting them into the quantum setting. All of the quantum difficulties are hidden inside our proofs.

1.2 Technical Details

A Quantum ROM Fiat-Shamir Proof Our first result is to prove the security of Fiat-Shamir in the
quantum random oracle model, showing that Fiat-Shamir is an argument (of knowledge) assuming the
original protocol is.

Fiat-Shamir operates on a sigma protocol, which is a three-message protocol with a public-coin verifier.
The prover has some witness w for a statement x. In the first message, the prover sends a commitment a.
Then the verifier chooses a random challenge c which it sends back. Finally, the prover comes up with a
response r. The verifier then looks at the transcript (a, c, r), which it accepts or rejects. The protocol is an
argument if no (computationally bounded) malicious prover can cause the verifier to output 1 in the case x
is false. The protocol is an argument of knowledge if, moreover, from any computationally bounded prover,
a valid witness w can be extracted.

Honest verifier zero knowledge means that it is possible to generate valid transcripts (a, c, r) without
knowing a witness. Note that this generation procedure typically chooses a based on c and maybe r; as such
a generation procedure does not allow one to break the soundness of the argument.

The Fiat-Shamir transformation, using a hash function H, simply replaces the verifier’s challenge with
c = H(a). Thus the prover can generate the entire interaction for himself. The hope is that the hash function
prevents a dishonest prover from using the zero knowledge property to generate the transcript, by forcing c

1 2-extractability is often called “special soundness” in the literature

2



to be determined after a. In fact, in the classical random oracle model, this idea can be turned into a proof,
showing how to turn any adversary for Fiat-Shamir into an adversary for the original sigma protocol.

In the classical proof, the reduction simulates the random oracle on the fly, keeping track of the points
the adversary queries and programming the random oracle to fresh random points with each query. It is
straightforward to prove that if the adversary eventually outputs a valid argument (a, c = H(a), r), then one
of the random oracle queries must have been on a. If the reduction knew which query this was at the time
of that query, it sends a as it’s commitment to the sigma protocol. When it receives c from the verifier, it
programs H(a) = c instead of choosing its own random value. Since the verifier chose c at random anyway,
this is undetectable to the adversary. Finally, when the adversary outputs (a, c, r), the reduction simply
sends r to the verifier, which will pass. Now, the reduction does not know which query will correspond to the
adversary’s output when the query is made, so the adversary simply guesses a query at random, and aborts
if the guess turned out wrong. The resulting adversary still succeeds with non-negligible probability.

This proof strategy is problematic once we consider quantum queries to the random oracle. The classical
on-the-fly simulation strategy of random oracles does not work once quantum queries are allowed. The reason
is that the simulation strategy requires recording the adversary’s queries; if the queries were quantum, the
result is effectively a measurement of the adversary’s query. Such a measurement is easily detectable. A
mischievous adversary could test for such a measurement, and refuse to keep working if detected.

This is a universal problem in the quantum ROM; as such, the typical solution is to avoid on-the-
fly simulation. Instead, the function is set once and for all to be a fixed function chosen from a careful
distribution [BDF+11, Zha12, BZ13, Unr17, TU15, Unr15, KLS18]. The reduction then answers the queries
with this function, without trying to record anything about the adversary’s query. By designing the function
to be indistinguishable from a truly random oracle, the adversary cannot tell that it was given a different
oracle.

However, while such fixed functions can be made to work in a wide variety of settings, they seem incapable
of proving the security of Fiat-Shamir. Indeed, an impossibility of this sort is formalized by [DFG13]. The
issue is that a Fiat-Shamir proof needs to extract a from the adversary’s queries and feed it into it’s own
verifier. But such an extraction constitutes a detectable measurement. Even worse, it then needs to program
the challenge c into the oracle, but this might be happening after many queries to the random oracle.
Therefore, it seems crucial for a proof to adaptively program the random oracle.

Compressed Oracles. Toward resolution, we start with a very recent technique that allows for on-the-fly
simulation of random oracles in the quantum setting: Zhandry’s compressed oracles [Zha18].

Zhandry’s key observation is that some sort of on-the-fly simulation analogous to the classical simulation
is possible if care is taken to implement the oracle correctly. Concretely, Zhandry simulates the random
oracle as a stateful oracle which stores a quantum superposition databases D, where a database is just a list
of input/output pairs (x, y). A database intuitively represents a partial specification of the oracle: if a pair
(x, y) is in the database, it means the oracle on input x is set to y, whereas if there is no pair that begins with
x, it means the oracle is un-specified at x. Since the oracle actually stores a superposition of databases, a
point x can be in superposition of being specified and unspecified. Originally, the database starts out empty.

In the classical setting, on query x, the oracle would look up x in the database and add a pair (x, y) for a
random y if x was not found. Afterward (since there is now guaranteed to be a pair (x, y)) it will output y.

In the quantum setting, something similar happens. The following description is slightly inaccurate, but
gives the high-level idea. On query x, very roughly, if x is not found in the database, a pair (x, y) is added,
where y is in uniform superposition over all possible y values. Recall that the query can be quantum, so this
addition to the database is happening in superposition. Then once x is guaranteed to be specified, the query
is answered (again in superposition).

Now, an important difference from the classical setting is this: in order to maintain perfect indistinguisha-
bility from a truly random oracle, a particular test is performed on the database after answering the query.
This test determines whether the adversary maintains any knowledge of the oracle at input x. If not, the
pair (x, y) is removed from the database.

The above description is informal and slightly inaccurate. But nonetheless by carrying out the operations
correctly, Zhandry shows that this approach can be made to correctly simulate a random oracle.

3



For us, Zhandry’s simulation gives a glimmer of hope. Indeed, we notice that the oracle is now recording
information about which points the adversary is interested in. Therefore, the database has all the information
we need to generate a. Unfortunately though, there is a problem: in order for the reduction to win against
the verifier, it must produce a classical a. However, in order to produce a classical a, we must measure the
adversary’s database. But such a measurement will affect the state of the oracle, and can be detected by the
adversary. Indeed, it is straightforward to devise adversaries that can catch such a measurement and refuse
to keep running.

Our New Extraction Technique. First, we observe that when the adversary outputs (a, c, r), the first thing
the verifier does is to check that c = H(a). If the adversary succeeds, it means that the adversary knows
about the value of H at a. But a Lemma of Zhandry [Zha18] whose that in the compressed oracle simulation,
the pair (a, c) must be in the oracles database (whp). By the end of the experiment, a has been measured
(since the adversary produces a classical output) which roughly has the effect of measuring a in the oracle’s
database. Since the oracle’s database starts out empty, this must mean that (a, c) was added at some query.
One may hope that this means it is possible to measure a random query to get a.

Unfortunately, things are not so straightforward. The problem is that a might not have been added
to the database at a well-defined point in time. It could be that each of the adversary’s queries is on
a superposition that contains a, and only after making several queries does the adversary have enough
information to determine H(a).

Now, as a thought experiment, consider running the adversary, and after each query measuring the
database in the compressed oracle. We will define the adversary’s history as the vector of resulting databases
(D1, . . . , Dq). Suppose the adversary still was able to output (a, c, r) that passed verification. Then we know
that (a, c) ∈ Dq, and so there must be some point i at which a first enters Di. But this means the adversary
actually queries on input a for query i. This means we could use the classical strategy for extracting a.

Unfortunately, measuring all the queries would of course destroy the adversary’s state, making it poten-
tially unlikely the adversary would still pass verification. The good news is that we can show the probability
of passing verification is at least non-zero. Indeed, Boneh and Zhandry [BZ13] give a measurement lemma
which says that if a measurement has T possibilities, it can only reduce the adversary’s success probability
by at most a multiplicative factor of T . Therefore, the adversary still passes with probability at least the
reciprocal of the number of database histories. Of course, the number of histories is exponentially large, so
this is not useful yet. We note that the measurement lemma is tight in general.

However, we can use this notion of a history to help us achieve an extraction technique with a higher
success probability. For a history h, let |φh〉 be the final state (where the queries were measured as above)
of the algorithm conditioned on observing the history h. Recall that quantum states are usually complex
vectors of unit norm. In contrast, |φh〉 will not be normalized, but instead have norm whose square is equal
to the probability of observing h.

Our key idea is to group histories in together, and apply a generalization of the measurement lemma to
the groups of histories. We show that a polynomial number of groups of histories are possible, leading to a
non-negligible chance of success.

In more detail, we observe that the adversary’s final state, if we did not measure the history, is exactly∑
h |φh〉 where the sum is over all possible histories. This is similar to the classical case, where the adversary’s

probability distribution is the sum of the conditional probability distributions for each history, weighted by
the probability of that history. The key difference is that in the quantum setting, the relation between states
and probabilities distributions requires squaring the amplitudes.

Next, we partition the histories into a polynomial number of sets S1, . . . , Sq. Set Si consists of all histories
(D1, . . . , Dq) for which:

– Di−1 does not contain a
– Di through Dq all contain a

For the clarity of exposition, we assume that the adversary always outputs a successful tuple (a, c, r),
meaning we know that a is in Dq. Therefore, Dq will contain a in all histories. As such, the sets Si in fact

4



do partition the space of all possible histories. In the more general case where the adversary may fail, we
would include a set S⊥ of histories where Dq does not contain q.

Now we consider the states |φSi
〉 = ∑

h∈Si
|φh〉. We note that

∑
i |φSi

〉 is exactly the adversary’s final
state, since the Si form a partition. By generalizing the Boneh-Zhandry measurement lemma, we can show
that the |φSi

〉 must result in (a, c, r) which pass verification with non-negligible probability.
Therefore, our goal is to extract a from the adversary’s query, and then hope that the resulting state is

|φSi
〉 for some i. First, we choose a random i. For that query, we measure two things:

– Whether that query resulted in a value being added to the database
– And if so, we measure that value to get a guess a′ for a

If successful, this corresponds to the requirement that histories have Di−1 which did not contain a and
Di contained a. If unsuccessful, we abort. Then, for each subsequent query, we measure if a′ is still in the
database, corresponding to the requirement that a ∈ Dj for all subsequent databases; if not we abort. At the
end, the we test that the value a′ we measured happens to match the a in the adversary’s output (a, c, r). If
a′ = a, the end result is exactly the state |φSi

〉, since our measurements remove all histories except those in
Si.

We show that this procedure succeeds with non-negligible probability, and then by applying the general-
ized measurement lemma we get that (a, c, r) passes verification with non-negligible probability. The result
is that we can actually extract the a at query time, and still have the adversary succeed in producing a valid
(a, c, r), just as in the classical setting.

Our New Programming Technique. Unfortunately, the above is not quite sufficient for a reduction. After all,
while we can now query the verifier on a, it is unclear what it should do with the response c. It could program
H(a) = c by adding the pair (a, c) to the database (recall that H was previously un-programmed at a since
a /∈ Di−1). However, this is different from what the compressed oracle would have done: the compressed
oracle would have added a uniform superposition over c of (a, c) pairs.

In particular, the information the compressed oracle uses to determine if a pair should be removed is
stored in the phase information of the output registers in the database. By inserting a classical value c into
the output, there is no phase information for the compressed oracle to use. Actually, this will cause the
compressed oracle to almost always decide to keep the value in the database, even if it should have been
removed.

A natural solution is: in query i once we have extracted a, switch the oracle database for input a to be
permanently “uncompressed”. On all other inputs, the database will behave as before, but on the special
input a, it will no longer run the check to remove a from the database.

Such a modification can indeed be made to Zhandry’s compressed oracle, allowing for programming a
random c. However, it does not quite work for us. Remember that our extraction technique above required
testing whether a was in the database after query i. But this test needed to be applied to the original
compressed oracle, not the new oracle which doesn’t compress a. In particular, the new compressed oracle
will always report that a is in the database. Roughly this means our extraction captures all histories where
a was added to the database at query i, even those where it was subsequently removed and added again.

Let Ti be the set of histories of this form. Notice that the Ti’s do not partition all histories: the multi-set
obtained by unioning the Ti contains each history multiple times. In fact, the number of times each history
is included is equal to the number of times a is added to the database in that history. Some histories will
add a many times.

In order to overcome this issue, we need a way to partition the set of histories such that the set of histories
for query i is independent of the history after the query. This corresponds to, after query i, no longer testing
whether a is in the database. If we do not need such a test, we can switch the oracle at a to be uncompressed
and then program a random c.

One thought is to reverse the sets Si. That is, let S′i the set of histories where a is not in the history
at any query up until i, and then is added at query i; we do not care after i if a is added or removed from
the database. These S′i certainly partition the set of all histories, but unfortunately they cannot be sampled

5



efficiently. The problem is that a is not known until it is added to the database in query i; yet, sampling
histories in S′i requires knowing a at the very beginning in order to test for a’s presence from the start.

Our solution is to try to combine the features of Si and S′i so that we do not need to know a at the
beginning, but also do not need to test for a’s presence at the end. Toward that end, we define sets Ti,j,k. A
history is in set Ti,j,k if:

– a is added to the database at query i
– a remains in the database until query j, at which point it is removed
– a remains absent from the database until query k, at which point it is added a second time.

These sets can be easily sampled: at query i, we measure to learn a guess a′ for a. Then we keep testing to
make sure that a′ is in the database until query j, at which point we make sure that a′ is removed. Then we
keep testing that a′ is absent until query k, when it is added back in. Once we get to query k, the database
is now programmed at point a′, and we will never need to check for the presence of a′ in the database again.
Therefore we can change the compressed oracle to be uncompressed at a′, and simply program it’s value to
c. When the adversary finally outputs (a, c, r), we test if a′ = a; if so, the adversary’s state is exactly the
collection of histories in Ti,j,k.

The problem, of course, is that these Ti,j,k also do not partition the space of all histories. In fact, if a
history adds a a total of ` times, it will appear in `−1 histories. Therefore the multi-set obtained by unioning
the Ti,j,k contains each history equal to the number of times a is added, minus 1.

Our final idea is to observe that if we take the multiset derived from the Ti’s, and subtract the multiset
derived from the Ti,j,k’s, we will get every history exactly once. That means if we define |φT 〉 =

∑
h∈T |φh〉,

we have that

|φ〉 =
(
∑

i

|φTi
〉
)
−


∑

i,j,k

|φTi,j,k
〉




Analogous to the case of the Si’s this allows us to sample a |φTi
〉 or |φTi,j,k

〉 — which let us extract a
and program c — and then have the adversary give us a valid (a, c, r) with non-negligible probability. The
reduction then simply sends r and convinces the verifier. The end result is any adversary for Fiat-Shamir
can be turned into an adversary for the original interactive protocol, completing the proof of security.

How to Rewind an Argument For our next set of results, we show how to rewind a sigma protocol
to allow for proving that the protocol is an argument (of knowledge). We note that [ARU14] show that
2-soundness/2-extractability is insufficient. Therefore, we aim to identify some mild extra conditions that
will allow for the proof to go through.

The difficulty in proving soundness comes from the difficulty of quantum rewinding, which was first
observed by Watrous [Wat06]. In a classical rewinding proof, the adversary commits to a, gets a challenge
c1 from the verifier, and responds with r1. Then, the adversary is rewound to just after a is produced. The
adversary is then run on a different challenge c2, which causes it to give a different response r2. Then the
tuple (a, c1, r1, c2, r2) either breaks 2-soundness, or in the case of 2-extractability can be used to generate a
witness. 2-soundness/2-extractability are typically easy to prove using standard tools.

In the quantum setting, a problem arises. Namely, while the adversary is quantum, the r1 it produces
during the first run is classical. This means that r1 must be measured. But this measurement in general cannot
be undone. As such, it is in general impossible to rewind back to the first message to try again. [ARU14]
formalizes this observation by showing (relative to an oracle) that there are schemes for which 2-soundness/2-
extractability are not enough to prove security.

The natural solution, and the approach we take in this work, is to show that for some schemes rewinding
is possible. Basically, in the absence of measurements quantum computation is reversible. Therefore we know
that if r1 is not measured, then the adversary can be rewound and it will succeed in producing r2. What
we need to show is that measuring r1 does not significantly impact the probability that the adversary will
successfully produce r2.

6



Unruh [Unr12] shows that if a sigma protocol additionally satisfies the notion of strict soundness —
meaning that for every a, c there is unique valid r — then rewinding is possible. The idea is that you can
leave r1 in superposition and not measure it. Then, just the fact that (a, c1, r1) passed verification means
that the superposition over r1 collapses to the unique valid r1. Therefore, measuring r1 has no additional
affect over measuring whether verification succeeded. Of course, measuring whether verification succeeded
will also affect the probability r2 passes, but Unruh shows that the probability is not too low.

Collapsing Protocols. Unfortunately, strict soundness is undesirable in practice, as it leads to inefficient
schemes. Instead, Unruh [Unr16b] shows that for a particular protocol built from an object known as a
collapse-binding commitment, rewinding is possible even though there are multiple valid r. Collapse-binding
commitments can in turn be built from a so-called a collapsing hash function.

We abstract Unruh’s ideas, defining a general notion of collapsing for sigma protocols. Roughly, a col-
lapsing sigma protocol is one where there may be many valid r’s for a given (a, c), but the adversary cannot
tell whether a superposition of valid r’s is measured or not. This is exactly what Unruh’s protocol guaran-
tees, and is exactly what is needed to be able to rewind in the setting of many r’s. By following Unruh’s
techniques, we show that collapsing is a sufficient extra condition to get the classical results to carry though
to the quantum setting

But now we face another challenge: how do we construct a collapsing sigma protocol? We can look
for techniques for building collapsing hash functions or commitments and see if they apply. However, the
techniques are sparse. [Unr16b] only shows that a random oracle is collapsing, and a more recent work of
Unruh’s [Unr16a] gives a construction using lossy trapdoor functions (LTDFs). However, trying to embed a
LTDF in the sigma protocol construction will result a less efficient scheme, which will be important for the
application to signatures. In particular, Lyubashevsky’s scheme is inherently lossy, and moving to a regime
where there is an injective mode will significantly increase parameter sizes.

Associated Lossy Functionss. Our resolution is to devise a new technique for proving that a sigma protocol
(or hash function) is collapsing. They key idea is that the protocol itself does not need to be lossy, just that
there is an associated lossy function (not necessarily trapdoored) with a useful relationship to the protocol.

In more detail, an associated lossy function for a sigma protocol consists of two sampling procedures
GenL,GenI . GenI(a, c) takes as input the first two messages of the protocol, and outputs a function f . It
guarantees that over the space of valid r, f is injective. In contrast, GenL(a, c) samples a lossy mode f , which
is guaranteed to be constant over the space of valid r. In either case, no guarantees are made on invalid r.
Lastly, we require that for any a, c, the two modes are computationally indistinguishable (even if the attacker
knows a, c).

Any scheme with an associated lossy function is collapsing. Indeed, given a, c and a superposition over
valid r, sample a lossy mode f . Then measuring f(r) has no effect on the state (since f is constant over
the set of valid r). Then we switch f to an injective mode and still measure f(r). By the computational
indistinguishability of the modes, this change is undetectable. Finally, in the injective mode, f(r) information-
theoretically contains all information about r, so measuring f(r) is equivalent to measuring r. This means
we can measure r without detection.

Next, we observe that typical lattice-based sigma protocols have associated lossy functions. For example,
Lyubashevsky’s signature scheme [Lyu12] uses a sigma protocol where the set of valid responses r are short
vectors such that A ¡r = u mod q where A is a short wide matrix that is part of the public key and u depends
on a, c. We will define our associated lossy function to be the natural lossy function built from the Learning
With Errors (LWE) problem [AKPW13]. A lossy mode f is sampled by choosing a tall skinny matrix C, a
matrix E with short entries, and computing B = C ¡A+E mod q. The function fB(r) is then bB ¡ r mod qe,
where b¡e represents a suitably course rounding. Since r is short and E has short entries, we will have that
B · r mod q ≈ C ·A · r mod q = C · u mod q, which is independent of which valid r is used.

For the injective mode, we simply choose B at random mod q. By choosing parameters correctly, one can
ensure that fB(r) is injective.

One problem with the above is that, in order for the lossy mode to be constant, we need that q is
super-polynomial. Otherwise, rounding errors will cause fB(r) in the lossy mode to not quite equal bC ¡ ue,

7



and the errors will depend on r. As such, for polynomial modulus, fB(r) is not constant on valid r. Using
a super-polynomial modulus will negatively impact the efficiency of the scheme, and requires a stronger
computational assumption.

Our first observation is that we do not actually need full indistinguishability of the measured vs not
measured r. For our application to sigma protocols, we just need that anything that happens when r is
unmeasured will also happen with reasonable probability when r is measured. But the two cases could be
distinguishable in the strict sense. This gives a weak notion of collapsing which is sufficient for rewinding.

What this allows us to do is shrink q to be small, and we will have that the lossy mode in constant with
non-negligible probability, which we show is sufficient. However, we still need q to be somewhat larger than
what is required classically. This is because when we prove that the lossy mode is constant, we need to union
bound over each row of C. Decreasing the height of C improves the probability of success, but we need to
keep C a certain height so that the injective mode is actually injective.

Separable Sigma Protocols. In order c";"""date"",""2020-06-25T14:43:10Z""
""pdf:PDFVersion"",""1.4""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:docinfo:title"",""""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""pdfa:PDFVersion"",""A-1b""
""language"",""en""
""dc:format"",""application/pdf; version=""""A-1b"""""",""application/pdf; version=1.4""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""xmp:CreateDate"",""2020-06-25T10:43:10Z""
""modified"",""2020-06-25T14:43:10Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""xmp:ModifyDate"",""2020-06-25T10:43:10Z""
""pdf:docinfo:creator"",""""
""meta:author"",""""
""meta:creation-date"",""2020-06-25T14:43:10Z""
""created"",""2020-06-25T14:43:10Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-06-25T14:43:10Z""
""resourceName"",""10164788""
""pdfaid:part"",""1""
""Author"",""""
""producer"",""Neevia Document Converter Pro v7.1 build 94 (http://neevia.com)""
""pdf:docinfo:producer"",""Neevia Document Converter Pro v7.1 build 94 (http://neevia.com)""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""4"",""14"",""24"",""6"",""3"",""0"",""4"",""29"",""27"",""44"",""12"",""23"",""30"",""34"",""57"",""48"",""49"",""75"",""48"",""47"",""20"",""22"",""35"",""9"",""24"",""24"",""31"",""37"",""22"",""46"",""33"",""47"",""28"",""25"",""52"",""0"",""0"",""78"",""39"",""87"",""13"",""2""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2020-06-25T14:43:10Z""
""Last-Modified"",""2020-06-25T14:43:10Z""
""dcterms:modified"",""2020-06-25T14:43:10Z""
""title"",""""
""xmpMM:DocumentID"",""uuid:b07c43d1-b94d-11ea-0000-525d500f962f""
""Last-Save-Date"",""2020-06-25T14:43:10Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2020-06-25T14:43:10Z""
""meta:save-date"",""2020-06-25T14:43:10Z""
""Content-Length"",""509280""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""pdfaid:conformance"",""B""
""pdf:producer"",""Neevia Document Converter Pro v7.1 build 94 (http://neevia.com)""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""45""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""2917"",""3492"",""4287"",""3804"",""3747"",""3450"",""4066"",""3407"",""3753"",""2557"",""2719"",""2331"",""2174"",""2018"",""3044"",""2427"",""2152"",""2164"",""1499"",""2650"",""2246"",""2042"",""1492"",""2347"",""1971"",""1368"",""1498"",""1413"",""1761"",""2805"",""2326"",""2633"",""2345"",""2515"",""2578"",""3171"",""2662"",""1440"",""3765"",""682"",""2217"",""2098"",""1889"",""2968"",""362""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-06-25T14:43:10Z""
";https://scholar.google.com/scholar?start=600&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094548-682;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;An Extended CTRT for AES-256;SH Shin, S Yamada, G Hanaoka, Y Ishida… ; … on Information Security …, 2019  Springer;;"… At CRYPTO 2000, Desai [6] suggested a new security definition for AONTs regarding key privacy

and a … In the ideal cipher model, we assume that we have an oracle access to \((F,F^{-1 … However,

since we allow them to access the oracles \((F, F^{-1})\), they may use the ideal …";Cité 1 fois;Les 2 versions;null;;;;https://scholar.google.com/scholar?start=500&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094628-1028;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[PDF][PDF] Securing Emergent IoT Applications;J Cuellar ; researchgate.net;;"… such as timeout transitions contracts and open Petri Net places; second, we extend our frame-

work to support requirement elicitation methods with practitioner-friendly tools, distributed

accountability, and generation of Petri Net based smart contracts for Blockchain; third, we …";Autres articles;Version HTML;[PDF] researchgate.net;https://www.researchgate.net/profile/Prabhakaran_Kasinathan/publication/332451374_Securing_Emergent_IoT_Applications/links/5cebad00a6fdccc9ddd2442e/Securing-Emergent-IoT-Applications.pdf;;;https://scholar.google.com/scholar?start=840&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094593-875;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[HTML][HTML] ???????? ?????????? ?????-?????????? ? ???????????? ????????;?? ??????? ; ????????????? ????????? ? ?????????? …, 2019  cyberleninka.ru;;"… ?????????? ??????????? / ?????????????? ???????? / ????????

?????????? ?????-????????? / ????????????? ???????? / LAW AND COMPUTER

CODE / BLOCKCHAIN ORACLES / DECENTRALIZED AUTONOMOUS ORGANIZATION …";Autres articles;En cache;[HTML] cyberleninka.ru;https://cyberleninka.ru/article/n/problemy-primeneniya-smart-kontraktov-v-deyatelnosti-kompanii;"
    

    


    
      
        



  [image: Научная статья на тему 'ПРОБЛЕМЫ ПРИМЕНЕНИЯ СМАРТ-КОНТРАКТОВ В ДЕЯТЕЛЬНОСТИ КОМПАНИИ'][image: ]



  ПРОБЛЕМЫ ПРИМЕНЕНИЯ СМАРТ-КОНТРАКТОВ В ДЕЯТЕЛЬНОСТИ КОМПАНИИ Текст научной статьи по специальности «Право»

  
    

    
    
      [image: ]CC BY

    
    
      [image: ]

    
      [image: ]27
[image: ]6

    

  


  
    
    

  


	
  
    
      
        
          

        

        
          

        

        

      

    

  

  
  
    
       
         i
         Надоели баннеры? Вы всегда можете 
           отключить рекламу.
       

    

  


	

  
    
			
      Журнал[image: ]

      Имущественные отношения в Российской Федерации
      
	      2019

        
  ВАК


      

    

    
      Область наук

      	Право


    

  


  
  
    
      Ключевые слова

      
        
          ПРАВО И КОМПЬЮТЕРНЫЙ КОД / 
        
          БЛОКЧЕЙН-ОРАКУЛЫ / 
        
          ДЕЦЕНТРАЛИЗОВАННАЯ АВТОНОМНАЯ ОРГАНИЗАЦИЯ / 
        
          САМОИСПОЛНЕНИЕ ДОГОВОРА / 
        
          ПРОБЛЕМЫ ПРИМЕНЕНИЯ СМАРТ-КОНТРАКТА / 
        
          РИКАРДИАНСКИЙ КОНТРАКТ / 
        
          LAW AND COMPUTER CODE / 
        
          BLOCKCHAIN ORACLES / 
        
          DECENTRALIZED AUTONOMOUS ORGANIZATION / 
        
          SELF-FULFILLMENT OF A CONTRACT / 
        
          PROBLEMS OF APPLYING A SMART CONTRACT / 
        
          RICARDIAN CONTRACT
        
      
    

  

  

  
  
    
      Аннотация научной статьи по праву, автор научной работы — Душаева Анастасия Александровна

      Автор анализирует сущность и содержание смарт-контракта, исследует предшествующие ему способы самоисполнения простых сделок, технологическое содержание такого контракта и юридические проблемы, возникающие в деятельности компаний при использовании смарт-контрактов в договорных отношениях. Выявляет особое значение и роль технического специалиста при создании таких контрактов. Делает вывод о возможности появления проблем при их реализации и предлагает способы фиксации условий смарт-контракта для устранения противоречий и ошибок.

    

  

  

	
	
		
			
			        
					

				

			        
					

				

			

		

	

  
  
    
       
         i
         Надоели баннеры? Вы всегда можете 
           отключить рекламу.
       

    

  


	

	
    
      Похожие темы научных работ по праву , автор научной работы — Душаева Анастасия Александровна

      	Профессиональный библиограф составит и оформит по ГОСТ список литературы для вашей работы
Подбор литературы
	
          
            СМАРТ-КОНТРАКТ: ПРОБЛЕМЫ И ПЕРСПЕКТИВЫ ПРАВОВОГО РЕГУЛИРОВАНИЯ

            2019 / Михайленко Нафисет Мурадиновна, Гнездилова Анастасия Владимировна
          
        
	
          
            К вопросу о понятии и сфере применения смарт-контрактов

            2019 / Новиков Р.В.
          
        
	
          
            Законодательное регулирование ""умных"" контрактов: проблемы и перспективы развития

            2018 / Митрофанова Ирина Александровна
          
        
	
          
            СМАРТ-КОНТРАКТЫ: ОКНО В ЭПОХУ ЦИФРОВОГО ПРАВА

            2019 / Данилов Кирилл Сергеевич
          
        
	
          
            ТЕХНОЛОГИЧЕСКИЙ И ПРАВОВОЙ АСПЕКТЫ СМАРТ-КОНТРАКТА

            2020 / Камалян В. М.
          
        


    

  


  
    
       iНе можете найти то, что вам нужно? Попробуйте сервис подбора литературы.

    

  


  
    

  


	
  
    
      
        
          

        

        
          

        

      

    

  

  
  
    
       
         i
         Надоели баннеры? Вы всегда можете 
           отключить рекламу.
       

    

  


	

  
  
    
      PROBLEMS OF APPLICATION OF SMART CONTRACTS IN THE COMPANY’S ACTIVITIES

      The author of the article analyzes the essence and content of the smart contract, examines the methods of execution of simple transactions preceding the smart contract, the technological content of the smart contract and the legal problems arising in the practice of companies when using smart contracts in contractual relations. Conclusions are drawn about possible problems in the implementation of a smart contract, the special importance and role of a technical specialist in the creation of a smart contract is revealed, and the author makes suggestions on ways to fix the conditions of a smart contract to eliminate contradictions and errors.

    

  

  
  
    
      Текст научной работы на тему «ПРОБЛЕМЫ ПРИМЕНЕНИЯ СМАРТ-КОНТРАКТОВ В ДЕЯТЕЛЬНОСТИ КОМПАНИИ»

      
				
        
          

        

				
        
        		DOI: 10.24411/2072-4098-2019-11003 Проблемы применения смарт-контрактов в деятельности компании

         
        
        А.А. Душаева адвокат Нижегородской областной коллегии адвокатов, аспирант кафедры теории и истории государства и права юридического факультета Национального исследовательского Нижегородского государственного университета им. Н.И. Лобачевского (г. Н. Новгород)

         
         
         
        
        Анастасия Александровна Душаева, Nastasieva@yandex.ru

         
         
         
        
        Содержание смарт-контракта

         
         
         
        
        Относительно новым явлением в предпринимательской деятельности является смарт-контракт. Согласно толковому словарю С.И. Ожегова контракт - это договор, соглашение (см. [1]). В толковом словаре русского языка Д.Н. Ушакова контракт имеет значение письменного договора, заключенного двумя сторонами с взаимными обязательствами (см. [2]). При грамматическом толковании термина «смарт-контракт» (англ. Smart contract - умный контракт) оказывается совсем не «умным» и даже не контрактом в подлинном значении, а характеризуется лишь особым свойством смарт-контракта к самоисполнению без постороннего вмешательства третьих лиц согласно заложенным в нем заранее условиям исполнения (подробнее см. [3]).

         
         
         
        
        Историческими предшественниками смарт-контрактов были, к примеру, вен-динговые аппараты продажи газированной воды, первый в мире игровой автомат Liberty Bell, созданный Чарльзом Фаем 1.

         
         
         
        
        Один из предшественников современных смарт-контрактов - рикардианский контракт (Ricardian contract), идея о котором появилась в 1996 году в работе Иэна Григга и Гэри Хоуланда, посвященной платежной системе Ricardo. Григг представлял рикар-дианский контракт как мост между текстовыми контрактами и кодом со следующими параметрами:

         
         
         
        
        •	одиночным документ - контракт, который эмитент предлагает держателям;

         
         
         
        
        •	как ценное право держателей, управляемое эмитентом;

         
         
         
        
        •	легко распознается людьми (как и обычный бумажный контракт);

         
         
         
        
        •	считывается программами;

         
         
         
        
        •	подписывается цифровым образом;

         
         
         
        
        •	содержит ключи и информацию о сервере;

         
         
         
        
        •	сочетается с уникальным и одноименным идентификатором (см. [4]).

         
         
         
        
        В современном значении смарт-контракт впервые появился на платформе блокчейна версии 2.0 Е^егеит. В блокчей-не версии 1.0 биткоина смарт-контракты не создаются и являются отличительной характеристикой блокчейна версии 2.0, обладая иными свойствами и возможностями реализации на его основе огромного количества технологических проектов различного характера и экономической направленности.

         
         
         
        
        В настоящее время смарт-контракты составляют критически важный компонент многих платформ и приложений, построенных на основе блокчейна, то есть технологии распределенного реестра. Как отмечает А.В. Варнавский, «Блокчейн как технология в первую очередь представляет собой базу данных, обладающую рядом специфических свойств... В частности, технология блокчейн подразумевает внесение в распределенный реестр информа-

         
         
           iНе можете найти то, что вам нужно? Попробуйте сервис подбора литературы.

         
         
        
        1 Liberty Bell - первый игровой автомат, появился в 1880 году. См. URL: http://pantikapei.ru/liberty-bell-pervyj-igrovoj-avtomat-poyavilsya-v-1880-godu.html (дата обращения: 16 декабря 2018 года).

         
         
         
        
        ции о движении некой расчетной единицы» [5].

         
         
         
        
        В технологическом значении смарт-контракт описывает компьютерный код, который исполняет соглашение или его части. Код хранится на платформе, построенной на основе блокчейна. Код бывает единственным объявлением о содержании соглашения либо дополняет традиционный текстовый контракт и определенные условия соглашения, к примеру, перевод денежных средств от А к Б. Код реплицируется на несколько узлов, или нод (узел), блокчейна и пользуется всеми преимуществами блокчейн-сети (сохранность, безопасность и неизменяемость). Реплицирование означает, что при добавлении каждого нового блока код может исполниться. Если стороны инициировали транзакцию и тем самым показали, что условия соблюдены, то это станет триггером и код выполнит какие-то действия. Если транзакция не инициирована, то и компьютерный код ничего не делает. Большинство смарт-контрактов написаны на специальном компьютерном языке, приспособленном для этих целей (например Solidity).

         
         
         
        
        Наиболее широкое распространение смарт-контракты получили в финансовой сфере (подробнее см. [6]) и банковских операциях (подробнее см. [7]), поскольку блокчейн позволяет совершать сделки с хорошей отслеживаемостью их истории, характеризуется прозрачностью и отсутствием посредников в совершении транзакции.

         
         
         
        
        Смарт-контракты оказывают существенное влияние на деятельность компаний, инициируя новые формы ведения бизнеса с использованием контрактов и сети блок-чейн, улучшение условий финансирования инновационных предприятий посредством краудфандинга и проведения ICO, а также существенные изменения в государственном секторе, например в социальном обеспечении (см. [8]), и т. д.

         
         
         
        
        Смарт-контракты могут реализовывать-ся в разных формах.

         
         
         
        
        Во-первых, в смарт-контракт можно записать все условия сделки. Таким образом,

         
         
         
        
        контракт может стать формой сделки, если он содержит все существенные и необходимые условия договора соответствующего вида. Необходимо, чтобы входные условия и этапы выполнения смарт-контрактов были конкретными и объективными измеряемыми параметрами. Иными словами, «если произойдет X, то сделать Y». Следовательно, смарт-контракты выполняют простые задачи, например перевод крип-товалюты с одного кошелька на другой при наступлении определенных условий. По мере распространения блокчейна и увеличения средств, вкладываемых в токены или отправляемых в рамках бокчейна, смарт-контракты будут усложняться и смогут выполнять сложные транзакции. Многие разработчики уже создают более сложные смарт-контракты, объединяя их в несколько этапов транзакций.

         
         
         
        
        Прежде чем созданный смарт-контракт будет исполнен, требуется оплатить тран-закционную комиссию за добавление контракта в блокчейн. Например, в блок-чейне Ethereum смарт-контракты исполняются в виртуальной машине Ethereum Virtual Machine (EVM), а комиссия в крип-товалюте ether (эфир) называется газом (gas). Чем сложнее смарт-контракт, тем больше газа требуется заплатить. Таким образом, газ становится условием, предохраняющим виртуальную машину от выполнения слишком больших или сложных смарт-контрактов.

         
         
         
        
        Сейчас смарт-контракты больше всего подходят для применения в ситуациях двух типов:

         
         
         
        
        1)	оплата, инициируемая различными событиями;

         
         
         
        
        2)	наложение финансовых санкций при наступлении определенных условий.

         
         
         
        
        Для выполнения этих двух типов транзакций не требуется участие людей, в том числе доверенных держателей условного депонирования или юридических представителей. Это позволяет снизить издержки на исполнение и правоприменение при исполнении контрактов.

         
         
         
        
        Во-вторых, смарт-контракт может стать программным кодом только для исполнения некоторых условий сделки, совершенной в форме классического контракта, то есть в простой письменной форме. В этом случае в письменном контракте фиксируется возможность исполнения некоторых условий с применением кода в смарт-контракте.

         
         
         
        
        Трудности понимания кода лицами без специального образования

         
         
           iНе можете найти то, что вам нужно? Попробуйте сервис подбора литературы.

         
         
        
        Смарт-контракт может содержать условия договора, а договор можно прописать в самом контракте и компьютерном коде. Однако здесь возникают сложности.

         
         
         
        
        Понять содержание договора в простой письменной форме может практически любой гражданин, обладающий средним образованием и не владеющий юридической терминологией. Однако проверить условия договора, записанные в компьютерном коде, при отсутствии специального образования и удостовериться в правильности записи условий сделки, содержании необходимых условий практически невозможно. Компьютерный код составляется на специальном компьютерном языке и с особым, отличным от правил речи, синтаксисом.

         
         
         
        
        Главное препятствие на пути широкого распространения смарт-контрактов заключается в следующем. Сторонам придется полагаться на мнение доверенных технических экспертов, которые будут реализо-вывать соглашения в коде или подтверждать точность кода, написанного другой стороной. Возможная аналогия с участием в сделке юриста, составляющего договор, при сравнении может оказаться едва ли приемлемой. Люди без юридического образования способны понять краткие, простые соглашения и многочисленные положения более длинных соглашений. Но если сторона договора не умеет программировать, то не сможет разобраться даже в самом простом смарт-контракте, поэтому значимость эксперта, который разъясняет, что написано в коде, гораздо выше.

         
         
         
        
        В какой-то мере неспособность сторон разобраться в коде смарт-контракта не помешает им заключать вспомогательные программные соглашения. Дело в том, что можно создать и использовать много базовых функций и текстовых шаблонов, обозначающих, какие параметры нужно ввести и как они будут исполняться. Допустим, простая функция смарт-контракта списывает со счета одного кошелька неустойку в случае просрочки оплаты к определенной договором дате. Однако стороне может понадобиться подтверждение того, что программный код действительно выполнит определенные в тексте условия, что отсутствуют дополнительные условия и параметры, особенно в случае, если шаблон смарт-контракта не предусматривает ответственности за неточность программного кода. Для анализа кода придется привлечь третье лицо - эксперта в программировании.

         
         
         
        
        При отсутствии шаблона и необходимости в разработке нового кода сторонам потребуется разъяснить цель соглашения программисту. Просто предоставление копии текстового юридического документа нецелесообразно, поскольку программист должен проанализировать соглашение и выявить список условий. В связи с этим сторонам, полагающимся на вспомогательные смарт-контракты, понадобится составить для программиста список условий, которые должен исполнять смарт-контракт.

         
         
         
        
        Также стороны могут быть заинтересованы в получении от программиста письменного подтверждения правильной работы кода. В результате для реализации требований, не учтенных в шаблоне, сторонам понадобится заключить письменное соглашение с программистом смарт-контрактов (это помимо контракта, который стороны могут заключить с поставщиком сервисов электронного обмена данными).

         
         
         
        
        Страховые компании также могут разработать методики защиты сторон от некорректного выполнения программного кода. Страховка даст дополнительную защиту на

         
         
         
        
        случай, если стороны не заметят ошибки при анализе кода. К тому же сторонам будет психологически комфортнее, если страховая компания сама проверит код, прежде чем застраховать их.

         
         
         
        
        При использовании исключительно программных смарт-контрактов во взаимоотношениях между компаниями и потребителями могут возникнуть дополнительные проблемы. Суды неохотно требуют исполнять соглашения, если потребители не получили адекватного описания условий соглашений, и могут с сомнением отнестись к идее обязательного исполнения смарт-контрактов, если потребителям не предоставляется базовое текстовое соглашение, в которое включены все определения (см. [9]).

         
         
         
        
        туру, определять наступление заморозков и отправлять эти сведения в смарт-контракт.

         
         
         
        
        Оракулы - это прекрасный способ доступа к off-chain ресурсам, однако их использование подразумевает привлечение третьей стороны. Придется заключать с ней отдельный контракт на поставку данных, только чтобы реализовать целевой смарт-контракт. В результате выгоды от децентрализации снижаются. Также оракул - это потенциальная точка отказа. Например, при сбое оракул прекратит работать или предоставит недостоверные данные. Нужно учесть эти риски до начала массового применения контрактов.

         
         
         
        
        Финальное соглашение сторон об условиях

         
         
         
        
        Смарт-контракты и их зависимость от off-chain ресурсов

         
         
         
        
        Смарт-контракт получает сведения, необходимые для реализации его условий, от внешних источников, расположенных не в блокчейне и именуемых оракулами (оракулы - доверенные третьи стороны, получающие информацию из внешних систем и передающие ее в блокчейн в заранее обусловленные моменты, по расписанию). При этом возникают две проблемы.

         
         
         
        
        Во-первых, смарт-контракты не могут сами забирать данные. Передачу данных должен инициировать источник.

         
         
           iНе можете найти то, что вам нужно? Попробуйте сервис подбора литературы.

         
         
        
        Во-вторых, код реплицирован на множество узлов блокчейн-сети, и если данные идут постоянным потоком, то ноды (узлы) будут получать разную информацию. Например, на узел-1 пришли сведения, что температура - 0,5 градуса, а на узел-2 - что температура 0 градусов. Для валидации транзакции нужен консенсус между узлами, а несогласованность данных может привести к тому, что условие смарт-контракта будет считаться невыполненным.

         
         
         
        
        Стороны соглашения смогут решить эту задачу с помощью оракулов. В описанном случае оракул будет отслеживать темпера-

         
         
         
        
        Анализируя традиционные текстовые контракты, суды изучают принятый сторонами финальный письменный документ, чтобы определить, соблюдают они свои обязательства или нарушают. Суды уже давно подчеркивают, что именно финальное соглашение отражает взаимное мнение сторон.

         
         
         
        
        В случае с исключительно программными смарт-контрактами исполняемый код (и результат его работы) представляет собой единственное объективное свидетельство согласованных сторонами условий. Вероятно, в подобных случаях электронная переписка между сторонами и устные обсуждения потенциальных функций смарт-кон";"""citation_keywords"",""ПРАВО И КОМПЬЮТЕРНЫЙ КОД, БЛОКЧЕЙН-ОРАКУЛЫ, ДЕЦЕНТРАЛИЗОВАННАЯ АВТОНОМНАЯ ОРГАНИЗАЦИЯ, САМОИСПОЛНЕНИЕ ДОГОВОРА, ПРОБЛЕМЫ ПРИМЕНЕНИЯ СМАРТ-КОНТРАКТА, РИКАРДИАНСКИЙ КОНТРАКТ, LAW AND COMPUTER CODE, BLOCKCHAIN ORACLES, DECENTRALIZED AUTONOMOUS ORGANIZATION, SELF-FULFILLMENT OF A CONTRACT, PROBLEMS OF APPLYING A SMART CONTRACT, RICARDIAN CONTRACT""
""og:image"",""https://cyberleninka.ru/article/n/problemy-primeneniya-smart-kontraktov-v-deyatelnosti-kompanii/og""
""og:image:width"",""1074""
""twitter:card"",""summary_large_image""
""eprints.ispublished"",""pub""
""og:site_name"",""КиберЛенинка""
""keywords"",""научная статья бесплатно на тему ПРОБЛЕМЫ ПРИМЕНЕНИЯ СМАРТ-КОНТРАКТОВ В ДЕЯТЕЛЬНОСТИ КОМПАНИИ текст научной работы по праву из научного журнала Имущественные отношения в Российской Федерации. ПРАВО И КОМПЬЮТЕРНЫЙ КОД, БЛОКЧЕЙН-ОРАКУЛЫ, ДЕЦЕНТРАЛИЗОВАННАЯ АВТОНОМНАЯ ОРГАНИЗАЦИЯ, САМОИСПОЛНЕНИЕ ДОГОВОРА, ПРОБЛЕМЫ ПРИМЕНЕНИЯ СМАРТ-КОНТРАКТА, РИКАРДИАНСКИЙ КОНТРАКТ, LAW AND COMPUTER CODE, BLOCKCHAIN ORACLES, DECENTRALIZED AUTONOMOUS ORGANIZATION, SELF-FULFILLMENT OF A CONTRACT, PROBLEMS OF APPLYING A SMART CONTRACT, RICARDIAN CONTRACT""
""eprints.pagerange"",""58-64""
""citation_journal_title"",""Имущественные отношения в Российской Федерации""
""eprints.publication"",""Имущественные отношения в Российской Федерации""
""language"",""ru""
""og:description"",""Автор анализирует сущность и содержание смарт-контракта, исследует предшествующие ему способы самоисполнения простых сделок, технологическое содержание такого контракта и юридические проблемы, возникающие в деятельности компаний при использовании смарт-контрактов в договорных отношениях. Выявляет особое значение и роль технического специалиста при создании таких контрактов. Делает вывод о возможности появления проблем при их реализации и предлагает способы фиксации условий смарт-контракта для устранения противоречий и ошибок.""
""eprints.full_text_status"",""public""
""citation_issn"",""2072-4098""
""dc:title"",""ПРОБЛЕМЫ ПРИМЕНЕНИЯ СМАРТ-КОНТРАКТОВ В ДЕЯТЕЛЬНОСТИ КОМПАНИИ – тема научной статьи по праву читайте бесплатно текст научно-исследовательской работы в электронной библиотеке КиберЛенинка""
""eprints.place_of_pub"",""Россия, Москва""
""Content-Encoding"",""UTF-8""
""citation_pdf_url"",""https://cyberleninka.ru/article/n/problemy-primeneniya-smart-kontraktov-v-deyatelnosti-kompanii/pdf""
""robots"",""NOODP"",""noyaca""
""eprints.volume"",""""
""eprints.citation"",""Душаева Анастасия Александровна ПРОБЛЕМЫ ПРИМЕНЕНИЯ СМАРТ-КОНТРАКТОВ В ДЕЯТЕЛЬНОСТИ КОМПАНИИ // Имущественные отношения в Российской Федерации. 2019. Выпуск номер 10 (217), С.58-64""
""eprints.number"",""10 (217)""
""citation_author"",""Душаева Анастасия Александровна""
""resourceName"",""problemy-primeneniya-smart-kontraktov-v-deyatelnosti-kompanii""
""citation_abstract_html_url"",""https://cyberleninka.ru/article/n/problemy-primeneniya-smart-kontraktov-v-deyatelnosti-kompanii""
""citation_issue"",""10 (217)""
""eprints.abstract"",""The author of the article analyzes the essence and content of the smart contract, examines the methods of execution of simple transactions preceding the smart contract, the technological content of the smart contract and the legal problems arising in the practice of companies when using smart contracts in contractual relations. Conclusions are drawn about possible problems in the implementation of a smart contract, the special importance and role of a technical specialist in the creation of a smart contract is revealed, and the author makes suggestions on ways to fix the conditions of a smart contract to eliminate contradictions and errors."",""Автор анализирует сущность и содержание смарт-контракта, исследует предшествующие ему способы самоисполнения простых сделок, технологическое содержание такого контракта и юридические проблемы, возникающие в деятельности компаний при использовании смарт-контрактов в договорных отношениях. Выявляет особое значение и роль технического специалиста при создании таких контрактов. Делает вывод о возможности появления проблем при их реализации и предлагает способы фиксации условий смарт-контракта для устранения противоречий и ошибок.""
""citation_volume"",""""
""format-detection"",""telephone=no""
""citation_publication_date"",""2019""
""citation_title"",""ПРОБЛЕМЫ ПРИМЕНЕНИЯ СМАРТ-КОНТРАКТОВ В ДЕЯТЕЛЬНОСТИ КОМПАНИИ""
""eprints.date"",""2019""
""citation_publisher"",""Негосударственное частное образовательное учреждение высшего образования «Московский институт экономики, политики и права»""
""eprints.type"",""article""
""description"",""Автор анализирует сущность и содержание смарт-контракта, исследует предшествующие ему способы самоисполнения простых сделок, технологическое содержание такого контракта и юридические проблемы, возникающие в деятельности компаний при использовании смарт-контрактов в договорных отношениях. Выявляет особое значение и роль технического специалиста при создании таких контрактов. Делает вывод о возможности появления проблем при их реализации и предлагает способы фиксации условий смарт-контракта для устранения противоречий и ошибок.""
""title"",""ПРОБЛЕМЫ ПРИМЕНЕНИЯ СМАРТ-КОНТРАКТОВ В ДЕЯТЕЛЬНОСТИ КОМПАНИИ – тема научной статьи по праву читайте бесплатно текст научно-исследовательской работы в электронной библиотеке КиберЛенинка""
""eprints.document_url"",""https://cyberleninka.ru/article/n/problemy-primeneniya-smart-kontraktov-v-deyatelnosti-kompanii""
""twitter:site"",""@CyberLeninka""
""citation_fulltext_html_url"",""https://cyberleninka.ru/article/n/problemy-primeneniya-smart-kontraktov-v-deyatelnosti-kompanii""
""eprints.keywords"",""ПРАВО И КОМПЬЮТЕРНЫЙ КОД, БЛОКЧЕЙН-ОРАКУЛЫ, ДЕЦЕНТРАЛИЗОВАННАЯ АВТОНОМНАЯ ОРГАНИЗАЦИЯ, САМОИСПОЛНЕНИЕ ДОГОВОРА, ПРОБЛЕМЫ ПРИМЕНЕНИЯ СМАРТ-КОНТРАКТА, РИКАРДИАНСКИЙ КОНТРАКТ, LAW AND COMPUTER CODE, BLOCKCHAIN ORACLES, DECENTRALIZED AUTONOMOUS ORGANIZATION, SELF-FULFILLMENT OF A CONTRACT, PROBLEMS OF APPLYING A SMART CONTRACT, RICARDIAN CONTRACT""
""Content-Type-Hint"",""text/html; charset=utf-8""
""eprints.publisher"",""Негосударственное частное образовательное учреждение высшего образования «Московский институт экономики, политики и права»""
""Content-Type"",""text/html; charset=UTF-8""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""og:type"",""article""
""eprints.title"",""ПРОБЛЕМЫ ПРИМЕНЕНИЯ СМАРТ-КОНТРАКТОВ В ДЕЯТЕЛЬНОСТИ КОМПАНИИ""
""og:title"",""ПРОБЛЕМЫ ПРИМЕНЕНИЯ СМАРТ-КОНТРАКТОВ В ДЕЯТЕЛЬНОСТИ КОМПАНИИ""
""og:image:height"",""480""
""eprints.creators_name"",""Душаева Анастасия Александровна""
""eprints.date_type"",""published""
""viewport"",""width=device-width, initial-scale=1""
""apple-mobile-web-app-capable"",""yes""
""og:url"",""https://cyberleninka.ru/article/n/problemy-primeneniya-smart-kontraktov-v-deyatelnosti-kompanii""
""eprints.metadata_visibility"",""show""
""eprints.refereed"",""TRUE""
""eprints.issn"",""2072-4098""
";https://scholar.google.com/scholar?start=690&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094532-611;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[CITATION][C] The Blockchain Journey: A guide to practical business applications;G Salviotti, LM De Rossi, N Abbatemarco ;2019 EGEA spa;;null;Autres articles;;null;;;;
1619094665-1182;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;A distributed autonomous organization for internet address management;S Angieri, A García;Martínez, B Liu…  IEEE Transactions …, 2019  ieeexplore.ieee.org;;"… a set of blockchain's smart contracts in Ethereum, and it imple- ments all the functions needed

for the management of a global pool of addresses without any human intervention. Any entity

may re- quest an allocation of addresses to the InBlock registry by perform- ing a (crypto) …";Cité 8 fois;;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/17/4429834/08798684.pdf?casa_token=mY8xevb7SuwAAAAA:x7x_Bvr9I7cDrbX3_6xNEU2Xxmmt9FQVcTCZNXrQLL3F9jxvxy8EuXH2koGg4Ud09IwJhA0lBqk;"
		Skip to Main Content


		
			
				
				

				

			

		


		
			
				
					
						








	
		
	

	







						

						





























	
	
		
	
	
		
			

		
	

	
	
	



						





	
	
		
			
				IEEE Account

					Change Username/Password
	Update Address


			

			
				Purchase Details

					Payment Options
	Order History
	View Purchased Documents


			

			
				Profile Information

					Communications Preferences
	Profession and Education
	Technical Interests


			

			
				Need Help?

					US & Canada: +1 800 678 4333
	Worldwide:  +1 732 981 0060

					
	Contact & Support


			

		

		
			
				
					
							About IEEE Xplore
	Contact Us
	Help
	Accessibility
	Terms of Use
	Nondiscrimination Policy
	Sitemap
	Privacy & Opting Out of Cookies


						
							A not-for-profit organization, IEEE is the world's largest technical professional organization dedicated to advancing technology for the benefit of humanity.
Š Copyright 2021 IEEE - All rights reserved. Use of this web site signifies your agreement to the terms and conditions.
						

					


					

				

				
			

		

	


	
	


						
						






		
		
		
		
		
		
		
		
		
		
		
		
		
			
				
			
			
			
			
		
		
		
		
		
		

			


			

			
			


		
 		
		
			 

						
						









































	

		
		

		
		
		

		
			
		
		
		

		

		
		


		

		
		
		
		
		
		
		
		
		
		
	
	


















		
		
			
				
					
					
								
					
								
			
				
					
					
								
					
								
			
				
					
						








 



					
					
								
			
				
					
					
								
			
				
					
					
								
					
								
			
				
					
					
								
					
								
			
				
					
					
								
					
								
			
				
					
					
								
					
								
			
				
					
					
								
					
								
			
				
					
					
								
					
								
			
		
	




























		
			
					
			
					
			
					
			
				
					








					
			
					
			
					
			
					
			
					
			
					
			
					
			
		
		
	





	
	
	
	
	
	
	


	
	
	

	

















					

				

			


			
				
			
		

	";"""og:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""twitter:title"",""A Distributed Autonomous Organization for Internet Address Management""
""twitter:card"",""summary""
""Description"",""The current system to manage the global pool of IP addresses is centralized in five transnational organizations, known as regional internet registries (RIRs). E""
""og:title"",""A Distributed Autonomous Organization for Internet Address Management""
""resourceName"",""08798684.pdf""
""language"",""en""
""title"",""A Distributed Autonomous Organization for Internet Address Management | IEEE Journals & Magazine | IEEE Xplore""
""og:description"",""The current system to manage the global pool of IP addresses is centralized in five transnational organizations, known as regional internet registries (RIRs). Each of them manages the address pool for many countries. In this paper, we present InBlock, a distributed autonomous organization that provides the decentralized management of IP addresses. The InBlock also fulfills the same objectives as those fulfilled by the current IP address allocation organizations, i.e., uniqueness, fairness, conservation, aggregation, registration, and minimized overhead. The InBlock is implemented as a set of blockchain's smart contracts in Ethereum, and it implements all the functions needed for the management of a global pool of addresses without any human intervention. Any entity may request an allocation of addresses to the InBlock registry by performing a (crypto)currency transfer to the InBlock. The fee required, along with the annual renewal fee, serves as a mechanism to deter stockpiling and other wasteful practices. As with any novel technology, there are many open questions about the usage of blockchains to build an IP address registry. For this reason, we believe that practical experimentation is required in order to have hands-on experience, so we propose to conduct an experiment on the InBlock as a starting point to inform about the future directions in this space.""
""twitter:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-UA-Compatible"",""IE=Edge""
""viewport"",""width=device-width, initial-scale=1.0""
""dc:title"",""A Distributed Autonomous Organization for Internet Address Management | IEEE Journals & Magazine | IEEE Xplore""
""twitter:description"",""The current system to manage the global pool of IP addresses is centralized in five transnational organizations, known as regional internet registries (RIRs). Each of them manages the address pool for many countries. In this paper, we present InBlock, a distributed autonomous organization that provides the decentralized management of IP addresses. The InBlock also fulfills the same objectives as those fulfilled by the current IP address allocation organizations, i.e., uniqueness, fairness, conservation, aggregation, registration, and minimized overhead. The InBlock is implemented as a set of blockchain's smart contracts in Ethereum, and it implements all the functions needed for the management of a global pool of addresses without any human intervention. Any entity may request an allocation of addresses to the InBlock registry by performing a (crypto)currency transfer to the InBlock. The fee required, along with the annual renewal fee, serves as a mechanism to deter stockpiling and other wasteful practices. As with any novel technology, there are many open questions about the usage of blockchains to build an IP address registry. For this reason, we believe that practical experimentation is required in order to have hands-on experience, so we propose to conduct an experiment on the InBlock as a starting point to inform about the future directions in this space.""
""Content-Encoding"",""UTF-8""
""Content-Type-Hint"",""text/html; charset=utf-8""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=420&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094630-1037;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;EU Business Law and Digital Revolution: Selected Studies from New Fields of Technology;J Glavanits, B Horváthy, L Knapp ;2019 real.mtak.hu;;"… 71 (Zsolt Bujtár) Fluidity of Term of Cryptocurrency–A Challenge for Regulators 89 (Sonja

Bun?i?–Alpar Lošonc–Andrea Ivaniševi?) Virtual Currencies–Legal Challenges … 193 (Olena

Demchenko) Smart Cities, Iot and Blockchain: The Importance of Oracles …";;;[PDF] mtak.hu;http://real.mtak.hu/117964/1/EU%20Business%20Law%20and%20Digital%20Revolution.pdf;"
EU Business Law and Digital Revolution 
 





 

EU Business Law and 

Digital Revolution 
 
 

– Selected Studies from  

New Fields of Technology 
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

SzĂŠchenyi IstvĂĄn University 

DeĂĄk Ferenc Faculty of Law and Political Sciences 

Department of International and European Law 

2019 



 
  

© Zsolt Bujtár, Sonja Bunčić, Neera Chopra, Olena Demchenko,  

Judit Glavanits, Zsolt Halász, Balázs Horváthy, Andrea Ivanišević,  

GĂĄbor KertĂŠsz, PĂŠter BĂĄlint KirĂĄly, LĂĄszlĂł Knapp, Andrea Labancz,  

Alpar Loťonc, Måria T. Patakyovå, Istvån Pesti-Farkas, Laura Stănilă, 

ZoltĂĄn Szegedi; 2019 

 

Editors: 

Judit Glavanits 

BalĂĄzs HorvĂĄthy 

LĂĄszlĂł Knapp 

 

The manuscript has been reviewed by LĂĄszlĂł Milassin. 

 

ISBN 978-615-5837-64-7 (Print) 

ISBN 978-615-5837-65-4 (PDF) 

 

This book has been published within the research stream of  

“Jean Monnet Module on EU Business Law” (EUBLAW) funded by  

the Erasmus+ Programme of European Union. 

Győr, 2019 

 
 

Published by Széchenyi István University – 

Deák Ferenc Faculty of Law and Political Sciences – 

Department of International and European Law  

(H-9026 Győr, Áldozat u. 12.) 

Tel.:+36/96/503-478 

Fax: +36/96/503-472 

Web: nejt.sze.hu 



 

Content 

 

 

 

Content ................................................................................................. 5 

 

Foreword  .............................................................................................. 7 

 

I. Artificial Intelligence: legal implications  

 

      Knight Rider’s Brothers Coming Soon – What About Their Legal 

            Situation? .................................................................................... 11 

      (GĂĄbor KertĂŠsz) 

 

      Artificial Intelligence and Bid Rigging .......................................... 29 

      (MĂĄria T. PatakyovĂĄ) 

 

      Fear the Robots? – Attitudes from the Supply Chain .................. 43 

      (István Pesti-Farkas – Zoltán Szegedi) 

 

      AI Risk Assessment Tools: The Trojan Horse of the Criminal 

           Justice System .............................................................................. 51 

      (Laura Stănilă) 

 

II. Cryptocurrencies 

 

     Central Bank Issued Digital Currencies: is it a Solution or a 

           Problem? ...................................................................................... 71 

      (Zsolt BujtĂĄr) 

 

     Fluidity of Term of Cryptocurrency – A Challenge for Regulators  89 

      (Sonja Bunčić – Alpar Lošonc – Andrea Ivanišević) 

 

     Virtual Currencies – Legal Challenges........................................ 113 

      (Zsolt HalĂĄsz) 

 

 



6 
 

    The Classification of Virtual Currencies Related to Blockchains 133 

    (PĂŠter BĂĄlint KirĂĄly) 

 

     Cryptocurrencies: A Theoretical Approach ................................. 149 

    (Andrea Labancz) 

 

III. Business and digitalization 

 

     Adoption of ICT in Higher education: Readiness of University 

          Students in Rural India................................................................ 171 

    (Neera Chopra) 

 

     Electronic Commerce in Gaming Industry. European Perspective 

          on the Legal Regulations of In-game Virtual Transactions ......... 193 

    (Olena Demchenko) 

 

     Smart Cities, Iot and Blockchain: The Importance of Oracles  ... 209 

    (Judit Glavanits) 

 

     Autonomous Vehicles – Challenges for EU Private 

     International Law  ....................................................................... 233 

     (BalĂĄzs HorvĂĄthy) 

 

Annex – The Centre for European Studies (CES)  at the 

     SzĂŠchenyi IstvĂĄn University .............................................................. 255 

 

 

 



 

Foreword 
 

 

 

 

 

 

 

 

 

In 2017 the Centre for European Studies (CES) of Faculty of Law and 

Political Sciences of the SzĂŠchenyi IstvĂĄn University launched the 

conference series ‘EU Business Law Forum’ with the aim to establish a 

regular event, which reflects on topical issues of EU business law and 

explores the related contemporary challenges in their legal, political, 

economic and social reality.  

The 2nd EU Business Law Forum “EU Business Law through the lens 

of Digital Revolution” held between 13–14 June 2019, was devoted to 

discuss the implications of the current technological revolution on the 

business environment in the European Union, particularly on the EU 

business law regulation. The Forum identified the recent challenges that 

the EU business actors are facing as a result of the digitalization and 

posed the question, whether – analogically to the concept of ‘Industry 

4.0’ – a process of a ‘Law 4.0’ is expected to become tangible in the EU 

business law regulation, responding adequately the challenges arising 

from the new disruptive technologies.  

This book offers an insight into the main focus areas of the 

conference. The first chapter (I. Artificial Intelligence: legal implications) 

reflects on the growing importance of using artificial intelligence and the 

role of the legal regulation. The articles pose questions form general as 

well as specific perspectives and illustrates the legal problems of the 

artificial intelligence by varieties of topics, from the public procurements 

to the supply chains. The second chapter collects the papers that are 

focusing on the new instruments of exchange (II. Cryptocurrencies). The 

chapter lays down the conceptual basis of cryptocurrencies and 

examines the legal and regulatory challenges arising from the current 

use and the probable future prevalence of the virtual currencies. The 

third chapter of the book pays attention to emerging fields of regulations 



 

(III. Business and digitalization). The papers examine the adoption of 

technological innovations in higher education, e-commerce related 

aspects of computer games, legal challenges of smart contracts and 

autonomous vehicles.  

The Forum was a part of the ‘Jean Monnet Module on EU Business 

Law’ (EUBLAW) project funded by the European Commission’s Erasmus+ 

Programme in the Period of 2016 – 2019, and this year, the CES 

organized the event in cooperation with the SmartLaw Research Group. 

 

 

Editors 

Győr, December 2019 

 



 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

I. Artificial Intelligence: legal 

implications 
 

 

 

 





 

 

Knight Rider’s Brothers Coming Soon – What About Their 

Legal Situation?

 

 

 

GĂĄbor KertĂŠsz*  
 

 
Abstract: Nowadays, we are confronted more and more times with the issues of 

artificial intelligence and (partly or completely) self-driving vehicles. How does this 

technical development change our daily lives? What can ""Law"" do with these? In the 

analysis I am looking for the answer how these technical novelties can fit into the 

structure and logic of the legal system. During this process I use examples of history 

and legal history, other social sciences and modern business logic as well. 

 

 

Keywords: artificial Intelligence, self-driving cars, responsibility for damages  

 

1.  Introduction 

In the 1990s, television channels broadcasted the Knight Rider 

action film in a huge number of countries around the world, in which one 

of the main characters was a self-driving car. That time it existed only at 

the level of dreams and on the design tables of engineers, today it is 

reality in some parts of the world.  

1.1. A bit of „layman philosphy” 

Our long-standing expectation towards machines to work perfectly, 

flawlessly. In the contrary our recurring experience is that ""nothing is 

perfect"" ""what may go wrong will go wrong"" and we have to admit that a 

thing without any errors has never been made by a non-perfect person. 

From this point of view, we can ask how many % of the errors are 

accepted in practice naming the thing ""perfect"" or rather appropriate. 

The concept of damage appears already in the earliest legal systems. 

The concept clarified in the old Roman law is still perfectly applicable 

today, according to which the damage has two parts: the real damage 

 

 
* College professor, International Business School (Budapest). 



12 GĂĄbor KertĂŠsz 

 

(dannum emergens) and the loss of profit (lucrum cessans). Based on 

these, it is a question of argumentation to determine whose (active or 

passive) behavior caused the damage and who bears responsibility for 

the damage. It is usually a judicial procedural task not to allow the 

evidence procedure to sink into the infinite marsh of the principle of 

conditio sine qua non. 

2. Historical examples 

2.1. Legal instruments nowadays that come from legal history 

These legal instruments of responsibility have been created in the 

history of law during the technical development to solve the current 

problem. Man first tamed / domesticated animals that typically followed 

his instructions, but sometimes did not or not well executed the 

instruction and caused damage. The issue of liability for such damages 

caused by animals has been established long ago, and its structure has 

not changed since the first civilizations, and our act uses their logic still 

today.1 Also, since the earliest settled civilizations where built 

environment has been built, the question of damage caused by objects 

falling from buildings2 is known. Although the material and design of our 

buildings have undergone many changes over the past millennia, the 

handling of damages by objects falling from the buildings has not 

changed much over the past two thousand years. The next form of 

responsibility was developed due to another historical step that was the 

industrial revolution. The concept and liability of dangerous operations3 

is approached by the structure that was formed at that time, although 

nowadays many of these types of ""operations"" operate on a daily basis, 

and only the detailed rules for the new types are added to the centuries-

old structure. The last type of liability (although it can still be argued that 

this is not yet clear, but still in the process of being developed) is product 

liability4, where the link is created between the manufacturer and the 

 
1 Liability for the damages caused by animals Ptk. 6.:562-563. §. Here and 

thereafter, I refer to certain provisions of the Hungarian Civil Code (Ptk.), which has the 

same content in civil law in all the legal systems of the world. 
2 Liablity for building damages Ptk. 6.:560-561. §. 
3 Liability for dangerous operations Ptk. 6.:535-539. §. 
4 Product liability Ptk. 6.:550-559. §. 



Knight Rider’s Brothers Coming Soon – What About Their Legal Situation? 13 

 

end user of the product by omitting the intermediate elements of the 

causal chain.  

As a continental lawyer I looked for similar cases for autonomous, 

self-driving vehicles.  One of the “precedents” - using several multiple 

quotation marks - is the case of animal damages5. In this case an animal 

with independent autonomous animal intelligence causes damage and it 

is a partial question if the owner “led” the animal, or is made itself 

independent or uncontrollable. The other case that could be a 

“precedent” is the liability of the legal entity, where the legal person that 

caused the damage, will be liable for the damage and the legal entity will 

be obliged by the court to pay the compensation for the damage. 

With legal logic and expert arguments on a case-by-case basis, it is 

possible to determine in which proportion and percentage the potential 

responsible people (responsible groups) listed and analyzed above are 

responsible for the damage. The traditional market logic provides 

insurance as a solution to a potential threat, where we can atomize the 

actual damage between the members of the risk community. 

Another possible answer of business logic is to burden the damage to 

the one who caused it. Here the legal logic says today that to oblige a 

damage-causing truly self-driving vehicle to indemnify the damage, it 

should be a legal entity. Not going into the solutions of ancient - not 

Roman - and medieval rights that have passed the ownership of the 

damage-causing animal, or the harmed received temporary use on the 

animal, in case of self-driving cars the similar solution is possible, as it is 

a fact that the damage-causing thing has a value for use and it is able to 

produce it regularly. 

2.2. Philip IV. (the Fair) 

The next example is about a minor change made by the legislator 

that made a huge change in the historical perspective and that 

fundamentally influences national identity. Philip the Fair, king of France 

ordered in 1308 that in a case between non-barons, the court 

established at that time and permanently operating at the Royal Palace 

in Paris should make a final decision either in direct action or in appeal 

against a provincial judgment. This court used the local language around 

 
5 Ptk. 6:562.563. § 



14 GĂĄbor KertĂŠsz 

 

Paris and its code of conduct made it clear to accept only contracts and 

actions written in the language of the court6. From the early Middle Ages 

in today's France, the provinces with individual feudal autonomy spoke 

their own local language7. As a result of this law, in just a few decades, 

the language of the court became known as a written language in every 

corner of the Kingdom of France, which we now know as a French 

language, as it was in everyone's interest to write all the contracts in that 

language. Nowadays, French is an important element of French national 

identity. 

This is a good example of the fact that standardization of the rules for 

the use of certain elements of Artificial Intelligence (e.g. self-driving cars) 

will be significant for all members of society and will have a social 

organizing and forming effect in the long run. 

3. Who can be liable if Knight Rider makes an accident? 

Let us shortly list the different human beings who have any 

connection with Knight Rider’s birth. 

3.1. Possible liable people 

3.1.1. Driver 

This is the only member of the coming list, where - according to the 

current Hungarian legal environment - only one natural person can be a 

subject. Until now, the liability of the driver was an evidence in the case 

of damages caused by man-, animal- or machine powered vehicles. 

Nowadays there are vehicles that are not driven by humans, but are 

driven by the intelligent / autonomous vehicle itself in self-driving, 

however in the Union they drive only on test fields, not in real traffic. 

After a broad social debate involving the whole human civilization, it can 

be agreed if the natural people in self-driving vehicles should, and if so 

at what level, control the proper / accident-free operation of the vehicle. 

Currently, although we have already met a few legal cases, where the 

 
6 PĂĄl HorvĂĄth, IstvĂĄn KajtĂĄr, LĂĄszlĂłnĂŠ Nagy, T. MihĂĄly RĂŠvĂŠsz, IstvĂĄn Stipta and 

Jånos Zlinszky, Általånos jogtÜrtÊnet I. (Nemzeti TankÜnyvkiadó 1994) 64. 
7 This was the language of the certain Gaul tribe from which the people of the 

province originate. 



Knight Rider’s Brothers Coming Soon – What About Their Legal Situation? 15 

 

responsibility of the driver has been established on the basis of 

traditional logic, neither the public opinion nor the legislator has 

conducted this increasingly necessary debate yet. If the decision is 

made, it can be translated then into a known form of liability. According 

to the current Hungarian rules, if the vehicle is in motion, one person 

must be in the driving position continuously8. The Hungarian practice 

has not yet faced a case when the vehicle was self-driven with an empty 

driver seat causing an accident / damage. However, with the 

development of technology the question has to be answered soon 

whether the person who switches the vehicle into self-driving mode is a 

driver according to the Road Traffic Code? Does this person stay a driver 

after leaving the vehicle, which continues the way in self-driving mode? 

With traditional legal deduction the question can be replied in a 

conventional way. In this case, the question is modified to the following: 

does it worth to invest in the development / acquisition of such a 

vehicle, if my responsibility for a self-driving vehicle is the same as if I 

were actually driving it? Or how worthy it is for me if I have possibility to 

do other activity(s) besides controlling the vehicle during sitting in the 

driver's seat? 

3.1.2. Owner 

The Road Traffic Code basically lays down rules for the traffic 

participants: the driver and the passenger, and the owner appears only 

once in the text9, but in the meantime the owner is recorded separately 

in the traffic license. We have been treating it for thousands of years as 

an evidence that the owner is responsible for the damage caused by his 

property.10 It is important to recall here for a moment the analogy that 

the tutelary is responsible for the damage caused by the unpunishable 

person.11 

 

 

 

 
8 Road Traffic Code (KRESZ) 4. §. 
9 Road Traffic Code (KRESZ) 59. § (3) subpar. 
10 See e.g. footnote no 2, 3, 4. 
11 Liability for damages caused by unpunishable person Ptk. 6:544-547. §. 



16 GĂĄbor KertĂŠsz 

 

3.1.3. Retailer, Wholesaler, Importer 

At this point, we arrived at to the actors of the sales chain, calling the 

person12 - in practice typically a legal person - a retailer who sold the 

vehicle to the owner; the other players are working on the basis of 

traditional trade contracts, their responsibilities are governed by the 

contracts, the relevant customs and the practice of the judiciary and 

arbitration court. 

3.1.4. Tester team 

Here, on the one hand, it is the task and responsibility of the team to 

perform all the necessary tests thoroughly and professionally and on the 

other hand to ensure that all relevant tests are performed. Although this 

team typically consists of engineers, they have to keep in mind that they 

have to test the vehicle in every theoretically possible situation and 

check how it behaves in each case. It is often told about us as lawyers 

that we are writing novel-length contracts as 'graphomans' in which we 

try to get prepared for every single theoretically imaginable risk factor. 

The test team has a similar task to examine how the vehicle responds in 

a self-driven mode to the variety of all theoretically possible situations. 

For the test team only the collective responsibility can be imagined, 

since the outstanding and indispensable contribution of a team member 

is theoretically conceivable, but apart from such extreme situations, the 

contribution of all members of the team is equally important for the 

proper performance of the test and the evaluation of the result. Although 

they are not members of the testing team, but the decision-makers of 

the enterprise also have a responsibility here, as the management 

decides based on the results of the tests, with engineer, lawyer and 

economist support if the vehicle is ready to be put on the market / in 

traffic or further development is needed. 

3.1.5. Software-developer team 

This team develops the software (system) that ensures the vehicle's 

self-driving ability. Nowadays, developers generally “teach” the systems 

 
12 I examine only the sales of new vehicles. The sales of used vehicles is out of 

scope of the examination. 



Knight Rider’s Brothers Coming Soon – What About Their Legal Situation? 17 

 

in a way that it faces decision-making situations continuously, and it 

achieves a better percentage of success due to this “learning”. The 

other, nowadays in minority applied solution is to program the ""right / 

good / desirable"" solution and the system has to avoid the rest. The 

responsibility of the developers is unavoidable for both methods. In the 

first method the responsibility originates in the examples that were the 

base for teaching the system. It can happen that even though the 

sample consists of a large number of elements, there can be cases that 

are out of the model and the machine will not recognize them and it will 

not be able to handle them well. In the second method, the more 

detailed description of the good solution is important, so that the 

machine can handle the situation that actually arises, even if it is new, 

but similar to a learned rule. At this point, the question of the need for 

ethics arises. If in a given situation only bad decisions can be made and 

non-decision is also a bad decision, which wrong decision should be 

made by the Artificial Intelligence that was taught and built in the 

system? 

A comprehensive research project was launched in 2016 with 40 

million people worldwide, related to the artificial intelligence-driven cars 

being developed nowadays. Researchers were looking for an answer to 

what people say: if there is no way to avoid an accident, who should hit 

the car? The answers outline a world-wide view of what we are protecting 

more and what less. The results of the research have been published 

only half a year ago13. The article first states that it cannot be considered 

worldwide statistically representative because of the limited possibilities 

of sampling, but the data collected show that children are more likely to 

be saved than adults, but this is only a global average statistical result, 

because the range of bad decisions differ from country to country and 

even more from culture to culture. The results of the world average are 

not the same as the results of the regions and metropolises that are the 

most multicultural according to sociologists. So according to the data, 

people in different cultures of the world set different order of 

importance, or approach the question from the other side, a different 

order is set in the list of other people and objects to be sacrificed. So, if 

 
13 Edmond Awad, Sohan Dsouza, Richard Kim, Jonathan Schulz, Joseph Henrich, 

Azim Shariff, Jean-François Bonnefon and Iyad Rahwan, ’The Moral Machine 

experiment’ (Nature, 24 October 2018). 



18 GĂĄbor KertĂŠsz 

 

there are such significant sequencing differences in case of people from 

different parts or different cultures of the world, in which order to protect 

the different values in an emergency, then Artificial Intelligence will also 

not be able to decide according to a generally accepted sequence, 

although such situations relatively  often occur during traffic. 

In this case, the question arises which culture’s prioritization will be 

the base for the self-driving vehicles choice, i.e. which sequence was 

programmed/taught by the programming team. Here, group dynamics 

and hierarchical relationships within the group as well within the 

organization can also influence the sequence they teach, along with the 

cultural patterns of the team members and other individuals involved. 

I.e. if the development team is culturally homogeneous and whether the 

final decision-making management has the same, homogeneous cultural 

background. For most of these companies, we cannot say yes to this 

question with a calm heart. This results in the following: there is a 

significant likelihood that the sequence of priority will be determined 

differently by not only the vehicle types produced by the different 

manufacturers, but also by the same brand and type of self-driving cars, 

if they are produced in different plants of the world far away from each 

other, if Artificial Intelligence is made independently in the plant, rather 

than installing a centrally-produced system in vehicles manufactured in 

all factories around the world. The issue is about the choice of victim14 in 

an inevitable situation of a self-driven vehicle programmed under the 

rules of other cultures. In my opinion this issue can be settled 

satisfactorily through an agreement resulting from a consultancy with 

the presence of the whole world, or if the producers mutate the vehicles 

into the different cultural regions where they are sold. It is not primarily a 

business law issue, but a fundamental rights issue if it is allowed to the 

owner/driver to download versions of other cultures; either because he 

disagrees with the culture of his place of residence and feels another his 

own, or because he is planning to go to the territory of this culture - 

though the latter can be automatically solved by the service that if the 

vehicle crosses the ""cultural boundary"" according to its GPS coordinates, 

the system downloads the version that is valid in that area. 

 
14  E.g. the choices were different when the vehicle hits the old person or the child 

in order to save the other one – see same as footnote no 13. 



Knight Rider’s Brothers Coming Soon – What About Their Legal Situation? 19 

 

3.1.6. Planner team 

This is a team consisting of mostly engineers who design the 

""hardware"" of the vehicle. In addition to the fault possibilities of 

conventional vehicle design, only one new risk factor appears here. It is 

a well-known experience in conventional vehicle driving that there are 

""dead spaces"" in case of all vehicles depending on the vehicle’s size, 

which are not visible to the driver. Their magnitude cannot be completely 

removed, only reduced with the rear-view mirror system. In case of self-

driving vehicles, however, the expectation is that the machine should 

see everything in real time, simultaneously and drive itself accordingly. 

That's why the design team here, beyond the usual design 

responsibilities of traditional vehicle design, has to meet „only” one new 

requirement. On the vehicle the environment sensors must be 

positioned so that they can continuously see all objects in real time 

within the current speed braking distance that would presents a risk of 

accident in case of going without change. (Of course, the danger of a 

new object that might come out of the cover of another object is 

excluded here.) If the design really reduced the size of ""dead spaces"" for 

self-guiding sensors to 0%, the design team does not have any more 

responsibilities than the ones coming from traditional design 

responsibilities. The current traffic situation was detected by the sensors 

that transmitted it to the software, which made the decision in self-

driving mode, which is the result of the work of the development team15. 

3.1.7. Controller team 

Modern states usually have a body that controls various activities 

carried out by economic actors. The depth of control that this body 

performs varies from body to body and from country to country. If a 

causal link can be established between the authorization procedure of 

the authority and the damage caused, the determination of damage 

caused by administrative law may arise if it was not possible to avert the 

damage by ordinary legal remedy or in administrative juridical action16. 

The theoretical possibility of this in the examined issue arises only if 

 
15 See footnotes no 13 and 14. 
16 Ptk. 6: 548. §. 



20 GĂĄbor KertĂŠsz 

 

such an error originating in the type of the self-driving vehicle, which has 

not been recognized either by the licensing authority or the 

manufacturer's designer, software developer and test team previously. 

3.1.8. Legislator  

Legal acts created by the legislator are applied by legal entities and 

by the executive and judiciary branches. And it is a century-old, if not a 

millennium-old fact, for which we can find more and more examples 

nowadays that it is possible to legislate only such situations that already 

occurred, or they could be predicted with significant possibility. The new 

life situations that have arisen after the legislation have typically 

appeared as a legal loophole in continental law systems, and in the 

Anglo-Saxon systems precedents are sought. From a legal point of view, 

the “legislator's silence” - if no law was created on the certain situation - 

cannot be interpreted as a damaging fault. However, economic actors 

can perceive it as a damaging fault according to the logic of the 

economy, of the business and if the market. The question that arises 

here is whether the legislator has created the legal system so that it is 

able to deal with the problem of damage caused by a self-driving vehicle, 

and whether this solution is appropriate for society (for voters?). 

3.2. How can Knight Rider be liable? 

According to the basic division in law, there are legal subjects and 

legal objects. There are no third and temporary categories. We neglect to 

discuss the historical development of the general, unconditional and 

equal legal subject people have. We only mention the last step in the 

development of legal entities, the second group of legal subjects known 

today: ""The legal personality of a legal person extends to all rights and 

obligations that, by their very nature, may not only be related to a human 

being""17, i.e. the legal personality of the legal person is not bound to a 

purpose, but it is general. It is not a matter of jurisdiction, but a matter of 

legislation which listed actors and in which extent are made liable for the 

damages caused by the self-driving vehicle. It is already the task of 

 
17 Ptk. 3:1. § (2) subpar. 



Knight Rider’s Brothers Coming Soon – What About Their Legal Situation? 21 

 

political science to examine political programs, political marketing, and 

legal lobbying of the interested companies. 

Taking the two premises into consideration that the self-driving 

vehicle is capable of making autonomous decisions - respecting the 

rules of social cohabitation - and is capable to generate financial value 

continuously, the business logic raises the question in a right way why 

this vehicle cannot be an actor in business life on its own? As besides 

people - nowadays mainly in the international business community, 

instead of people – it is worldwide an accepted evidence by everyone 

and everywhere that ”legal constructions” named legal entities have 

legal subject, independent from the fact that no one has seen a legal 

entity, only a person representing it, its logo, or its headquarters. 

However, the self-driving vehicle is a tangible physical reality. 

Since the concept of a legal person appeared in legal history till the 

present, there is clear evidence that non-human private entities 

ultimately have a human owner. Nowadays, a new concept has emerged 

on the periphery of the legal subjects, which is the ""actual beneficial 

owner"" who increases its assets with the values produced by the 

examined legal entity, or has the right to dispose of these assets either 

directly or through mandatory instructions given to the participants in the 

chain18. Not going into details in the psychological, corporate, and social 

sociological question of what group dynamics each company (regardless 

of its legal form) has; we can say that the purpose of the company (the 

legal entity in question) is to live / operate further. As an analogy to this 

approach, we can assume that the autonomous, self-driving vehicles are 

also aimed for further operation; however, this hypothesis gives the 

software development, testing, and control teams an important task. The 

mentioned research looked for a reply about who the vehicle would 

rather hit19. For a human driver, it is an existing option, for which there 

are some famous examples, that the person sacrifices his own life, and 

with this, saving many. With the sensors of the vehicle's seats, on the 

base of the weight of each passenger, the vehicle “knows”20 how many 

 
18 About the concepts „beneficial owner” and „actual beneficial owner” see the 

different conventions about avoiding double taxation and 7. point of 7. App of the 

Hungarian citizens income tax act. 
19 Awad et al. (n 13) 
20 Not going into details about the results of Awad et. al. (n 13), according to which 

the general cultural reply to this in Europe is that the driver puts suitcases on each seat 

 



22 GĂĄbor KertĂŠsz 

 

adults and how many children are traveling in it, and even through the 

impleme";"""date"",""2020-12-07T10:39:34Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""EUBLAW-WP""
""xmp:CreatorTool"",""MicrosoftÂŽ Word 2010""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dc:creator"",""Iroda""
""language"",""en""
""dcterms:created"",""2020-12-07T10:39:34Z""
""Last-Modified"",""2020-12-07T10:39:34Z""
""dcterms:modified"",""2020-12-07T10:39:34Z""
""dc:format"",""application/pdf; version=1.5""
""title"",""EUBLAW-WP""
""Last-Save-Date"",""2020-12-07T10:39:34Z""
""pdf:docinfo:creator_tool"",""MicrosoftÂŽ Word 2010""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2020-12-07T10:39:34Z""
""meta:save-date"",""2020-12-07T10:39:34Z""
""pdf:encrypted"",""false""
""dc:title"",""EUBLAW-WP""
""modified"",""2020-12-07T10:39:34Z""
""Content-Length"",""2226858""
""pdf:hasMarkedContent"",""true""
""Content-Type"",""application/pdf""
""pdf:docinfo:creator"",""Iroda""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Iroda""
""dc:language"",""hu-HU""
""meta:author"",""Iroda""
""meta:creation-date"",""2020-12-07T10:39:34Z""
""created"",""2020-12-07T10:39:34Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""258""
""Creation-Date"",""2020-12-07T10:39:34Z""
""resourceName"",""EU%20Business%20Law%20and%20Digital%20Revolution.pdf""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""40"",""0"",""240"",""865"",""1381"",""1031"",""1925"",""520"",""67"",""0"",""1736"",""2347"",""2321"",""2110"",""2073"",""2138"",""2625"",""2588"",""2256"",""2183"",""2704"",""2471"",""2659"",""2363"",""2602"",""2091"",""968"",""0"",""2169"",""2280"",""2653"",""2383"",""2542"",""2136"",""2590"",""2306"",""2311"",""2238"",""2312"",""1798"",""1790"",""676"",""1831"",""1382"",""776"",""2506"",""2587"",""2459"",""1728"",""0"",""2200"",""2483"",""2247"",""2469"",""2655"",""2168"",""2411"",""2657"",""2414"",""2244"",""2518"",""2287"",""2703"",""1928"",""2007"",""1949"",""1810"",""0"",""42"",""0"",""1883"",""2347"",""2910"",""2888"",""2727"",""2656"",""1069"",""2579"",""2452"",""2700"",""2408"",""2526"",""2580"",""2486"",""2195"",""1892"",""1829"",""0"",""2535"",""2609"",""2579"",""2502"",""2474"",""2544"",""2614"",""2744"",""2333"",""2217"",""2298"",""2522"",""2425"",""2298"",""2392"",""2385"",""2324"",""2425"",""2147"",""2499"",""2086"",""1840"",""1973"",""484"",""1924"",""2346"",""2454"",""2432"",""2190"",""2515"",""2335"",""2601"",""2434"",""2341"",""2238"",""2606"",""2535"",""2472"",""2624"",""2385"",""2792"",""2262"",""1781"",""1037"",""1913"",""2410"",""2496"",""2333"",""2235"",""2632"",""2394"",""2538"",""2645"",""2558"",""2287"",""2324"",""1766"",""1963"",""1853"",""634"",""2016"",""2355"",""2581"",""2717"",""2226"",""2225"",""2747"",""2395"",""2490"",""2376"",""2265"",""2203"",""2254"",""2258"",""2506"",""1992"",""1823"",""1829"",""1202"",""0"",""53"",""0"",""2270"",""2645"",""2699"",""2376"",""2655"",""2255"",""1454"",""2186"",""2544"",""1573"",""1965"",""1561"",""1682"",""581"",""1298"",""1362"",""2069"",""1962"",""2248"",""1677"",""392"",""0"",""2036"",""2380"",""1999"",""2294"",""2339"",""1840"",""2364"",""2298"",""2155"",""2099"",""2418"",""1985"",""1863"",""1841"",""1022"",""0"",""1848"",""2262"",""1060"",""2503"",""2657"",""2575"",""905"",""632"",""2493"",""2335"",""2272"",""2282"",""1317"",""1844"",""817"",""2285"",""2701"",""2388"",""2125"",""2181"",""1996"",""2040"",""1918"",""1629"",""2257"",""2690"",""3383"",""2858"",""2732"",""2340"",""2647"",""2216"",""2699"",""2557"",""2280"",""2671"",""2875"",""3011"",""2558"",""2234"",""2266"",""2486"",""2184"",""2035"",""1968"",""1441"",""1697"",""1864"",""2598"",""691""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""Author"",""Iroda""
""producer"",""MicrosoftÂŽ Word 2010""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""MicrosoftÂŽ Word 2010""
""pdf:docinfo:created"",""2020-12-07T10:39:34Z""
";https://scholar.google.com/scholar?start=850&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094583-838;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Efficient Hierarchical Identity-Based Encryption System for Internet of Things Infrastructure;L Guo, J Wang, WC Yau ; Symmetry, 2019  mdpi.com;;"… Article in Special Issue Smart Contract-Based Pool Hopping Attack Prevention for Blockchain

Networks … size ciphertext over prime-order groups, which was proven secure without random

oracles … achieved a constant-size ciphertext and private key without random oracle, but the …";Cité 1 fois;Les 3 versions;[HTML] mdpi.com;https://www.mdpi.com/2073-8994/11/7/913/htm;;;https://scholar.google.com/scholar?start=650&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094600-908;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Fully Secure Attribute-Based Encryption for t-CNF from LWE;R Tsabary ; Annual International Cryptology Conference, 2019  Springer;;"… Conference. CRYPTO 2019: Advances in Cryptology – CRYPTO 2019 pp 62-85 | Cite

as. Fully Secure Attribute-Based Encryption for t-CNF from LWE … assumptions. [BF03, Coc01]

constructed the first IBE schemes in the random oracle model …";Cité 16 fois;Les 2 versions;[PDF] iacr.org;https://eprint.iacr.org/2019/365.pdf;"
Fully Secure Attribute-Based Encryption for t-CNF from LWE

Rotem Tsabary∗

Abstract

Attribute-based Encryption (ABE), first introduced by [SW05, GPSW06], is a public key
encryption system that can support multiple users with varying decryption permissions. One
of the main properties of such schemes is the supported function class of policies. While there
are fully secure constructions from bilinear maps for a fairly large class of policies, the situation
with lattice-based constructions is less satisfactory and many efforts were made to close this
gap. Prior to this work the only known fully secure lattice construction was for the class of
point functions (also known as IBE).

In this work we construct for the first time a lattice-based (ciphertext-policy) ABE scheme
for the function class t-CNF, which consists of CNF formulas where each clause depends on at
most t bits of the input, for any constant t. This class includes NP-verification policies, bit-fixing
policies and t-threshold policies. Towards this goal we also construct a fully secure single-key
constrained PRF from OWF for the same function class, which might be of independent interest.

∗Weizmann Institute of Science, rotem.tsabary@weizmann.ac.il. Supported by the Israel Science Foundation
(Grant No. 468/14), Binational Science Foundation (Grants No. 2016726, 2014276), and by the European Union Hori-
zon 2020 Research and Innovation Program via ERC Project REACT (Grant 756482) and via Project PROMETHEUS
(Grant 780701).



1 Introduction

Atrribute-based Encryption (ABE), first introduced in [SW05,GPSW06], is a public key encryption
system that can support multiple users with varying decryption permissions. In this work we focus
on ciphertext-policy ABE schemes, where each ciphertext is associated with a public policy f and
each decryption key is associated with a public attribute x, such that decryption succeeds condi-
tioned on f(x) = 1. One of the main properties of an ABE scheme is the function class of policies
that can be attached to ciphertexts. In fact, ABE was originally suggested as a generalization of
identity-based encryption (IBE), in which each ciphertext is destined to a single attribute x (i.e.
the policies are point functions).

Bilinear Maps Constructions. It was shown in a long line of works that bilinear maps prove
to be useful for the task of constructing IBE and ABE under varying group assumptions. [BF03,
Coc01] constructed the first IBE schemes in the random oracle model. [CHK03, BB04a] showed
constructions in the standard model, however their security was proven under a weaker notion,
called selective security.

A few approaches were suggested to go beyond selective security. [BB04b, Wat05] introduced
the first constructions with full security in the standard model, using a partitioning technique.
Their solutions were proved to be secure via a lossy reduction, where the simulator aborts with
probability that grows with the number of keys owned by the adversary. [Gen06] introduced the
tagging technique, with which he managed to construct a fully secure IBE scheme with a tight
reduction, however the hardness assumption was still related to the number of keys. Finally, [Wat09]
introduced the dual system encryption technique and achieved the first fully secure IBE scheme
with a tight reduction to a fixed assumption.

The first ABE construction was suggested by [SW05] and supported threshold policies. Later,
[GPSW06] constructed a key-policy1 ABE scheme for policies that can be expressed as a linear
secret-sharing (LSSS) access structure and [OSW07] constructed a key-policy ABE scheme for all
formulas. [Wat11] showed a ciphertext-policy ABE construction for LSSS access structures. All of
those works were proved to be secure in the weaker selective mode. The works of [LOS+10,LW12,
KL15,CGKW18] expand the dual system technique of [Wat09] to derive fully secure ABE for LSSS
and recently [KW19] showed a construction for all monotone access structures in NC1.

Lattice-Based Constructions. The emerging interest in hard problems over lattices, which
are believed to be hard even at the presence of quantum machines, led to the development of a
cryptographic toolbox [Ajt96,Ajt99,Reg05] that allows to base the security of various systems over
random instances of such problems. This gave rise to a line of works about lattice-based IBE and
ABE schemes. The first lattice-based IBE constructions were introduced by [GPV08, CHKP12,
ABB10a] and were secure in the selective model. Shortly after, [ABB10b] presented a construction
with full security and [BL16] constructed a fully secure scheme with a tight reduction.

The first schemes to support richer classes of polices were [AFV11,ABV+12], which constructed
ABE for inner product policies and threshold policies respectively. [Boy13] showed key-policy ABE
schemes for LSSS access structures. Lastly, the works of [GVW13,BGG+14] constructed key-policy
ABE for all policies that can be described by a bounded-depth polynomial-size circuit.

1In key-policy ABE the policies are attached to the keys and the attributes are attached to the ciphertexts.

1



All of the aforementioned ABE constructions were proved to be selectively secure. The works of
[BV16,GKW16] showed how to boost the security of [GVW13,BGG+14] to an intermediate notion,
named semi-adaptive security, however it is not clear how to further develop those techniques. The
question of whether it is possible to construct fully-secure ABE schemes from lattices beyond point
functions remained open.

Our Contribution. In this work we construct for the first time a lattice-based ciphertext-policy
ABE scheme for the ensemble of function classes t-CNF, which consists of formulas in conjunctive
normal form where each clause depends on at most t bits of the input, for any constant t. Our
construction supports functions of unbounded size, that is, every function consisting of polynomial
number of clauses. Those function classes includes NP-verification policies, bit-fixing policies and
t-threshold policies. Towards this goal we also construct a fully secure single-key constrained PRF
from OWF for the same function class, which might be of independent interest.

1.1 Technical Background

Let us first describe the difference between full security and selective security. The former is modeled
as a game between an adversary A and a challenger C as follows. At the beginning of the game, C
publishes the public parameters of the scheme. At any point of the game, A can query for multiple
decryption keys to attributes x of its choice. In the challenge phase, A chooses a challenge policy
f∗ and C returns a ciphertext respective to f∗. The goal of A is to determine whether this is an
encryption of 0 or 1, and the scheme is secure if it cannot do that as long as none of its queried keys
x are authorized by f∗. The selective security game is identical, except that A has to announce
the challenge policy f∗ before the game begins.

In the latter game the security reduction has the opportunity to generate the public parameters
according to f∗. Selective security proofs usually follow a similar structure, where f∗ introduces a
partitioning of the identity space. The public parameters are generated in the security reduction
such that for all x for which f∗(x) = 0 (i.e. not authorized by f∗) it is possible to simulate a
decryption key, and for all x for which f∗(x) = 1, a key for x would allow to break the hard
problem. Since A can only query for keys of the first type, the reduction can still answer all of the
queries appropriately.

Tagging. In [Gen06] Gentry presented an adaptively secure IBE scheme from bilinear maps, using
a tagging technique as follows. In the real scheme, every ciphertext is associated with a random
tag rct and every key is associated with a random tag rsk. Decryption works as long as the IBE
condition is satisfied and rct 6= rsk. The probability that decryption fails is negligible since the tags
are random. In the security proof, a random degree-Q polynomial P is embedded into the public
parameters, such that it is possible to generate a challenge ciphertext respective to any x with
the tag rct = P (x) and similarly it is possible to generate a key respective to any x with the tag
rsk = P (x). That is, the security reduction can answer any key query and can generate a challenge
ciphertext respective to any x, however if it generates a ciphertext and a key for the same identity
then the decryption fails because they both have the same tag. Recall that in the security game A
is not allowed to query for a challenge and a key respective to the same attribute and therefore it
cannot detect that case. Since P is a random polynomial, the values of P on up to Q points are
distributed uniformly. For that reason security is guaranteed as long as A can only query for up
to Q − 1 keys. The evaluation of P has to be performed on a secret element in the exponent of a

2



group. Since it is only possible to compute linear functions over the exponent, the reduction needs
to get information that grows linearly with Q and makes the assumption stronger.

The BGG+ Lattice-Based Construction. A long sequence of works [ABB10b,MP12,GSW13,
AP14,BGG+14] led to a selectively secure key-policy ABE scheme with security based on LWE, for
the function class of all policies that can be described as a bounded-depth polynomial-size circuit.
We now give an overview of their technique.

The public parameters consist of a matrix A, and for each attribute x (resp. policy f) there
is a related efficiently computable matrix Ax ← EncodeX(A, x) (resp. Af ← EncodeF(A, f)).
Encryption for an attribute x is a Dual-Regev encryption (see [GPV08]) respective to the public
matrix Ax, while a decryption key for f is a Dual-Regev key respective to the public matrix Af .
The matrices Ax,Af are cleverly defined s.t., informally, for all x, f

f(x) = 1 ←→ It is possible to convert a ciphertext respective to Ax

to a ciphertext respective to Af .

Let Convert be the “ciphertext conversion algorithm” that satisfies the above condition, then we
can informally say that

f(x) = 1 ←→ Convert(Ax, x, f) = Af .

The property that is important to us, is that Convert works gate-by-gate and therefore respects
function composition. That is, if f = g2 ◦ g1, then for all x it holds that

Convert(Ax, x, f) = Convert (Convert(Ax, x, g1), g1(x), g2) (1)

and therefore
f(x) = 1 ←→ Convert (Convert(Ax, x, g1), g1(x), g2) = Af .

The security proof follows similar lines to other selectively-secure schemes as described at the
beginning of this section. That is, the challenge attribute x∗ is embedded into the public parameters
A such that it is possible to create a challenge ciphertext only respective to Ax∗ = EncodeX(A, x∗),
and it is possible to generate keys only respective to Af = EncodeF(A, f) for which f(x∗) = 0.

1.2 Our Techniques

Identity-Based Encryption. We first describe how to construct a fully secure IBE scheme with
our approach. The main idea is to use the tagging technique of [Gen06], but with a PRF instead
of a random polynomial. The rich function class supported by [BGG+14] allows us to compute a
PRF over a seed that is secretly embedded into the public parameters in the security proof. The
tag of a key for an attribute x is the value of the PRF on the input x, i.e. rx. That is, a key for
x can decrypt any ciphertext respective to x unless the ciphertext tag is equivalent to rx. In the
real scheme the tags of ciphertexts are sampled uniformly, while in the security reduction they are
determined by the PRF seed that is embedded into the public parameters. Details follow.

For all x we let Ux denote the circuit that on inuput σ evaluates the PRF on the point x with
the seed σ. For all r we let Īr denote the circuit that on input r′ returns 1 if and only if r′ 6= r.

The public parameters of the IBE scheme are identical to [BGG+14] and the master secret
key includes a PRF seed σ. To encrypt respective to x, one samples a fresh PRF seed σ′ and
computes the Dual-Regev encryption with the public matrix A′x = Convert(Aσ′ , σ

′, Ux) where

3



Aσ′ = EncodeX(A, σ′). To generate a key respective to x, one first computes rx = Ux(σ) and then
generates the Dual-Regev key respective to the matrix Afx = EncodeF(A, fx), where fx = Īrx ◦Ux.
Note that fx(σ′) = Īrx(Ux(σ′)) where rx = Ux(σ). Therefore, if σ = σ′ then fx(σ) = 0, but for
any uniformly sampled σ′, Ux(σ′) 6= Ux(σ) with high probability and therefore fx(σ′) = 1. That is,
with high probability over a uniform σ′ it holds that

fx(σ′) = 1 ←→ σ′ 6= σ

i.e.
Īrx ◦ Ux(σ′) = 1 ←→ σ′ 6= σ .

By the properties of [BGG+14] described above, it holds that

Īrx ◦ Ux(σ′) = 1 ←→ Convert
(
Convert(Aσ′ , σ

′, Ux), Ux(σ′), Īrx
)

= Afx

and therefore
σ′ 6= σ ←→ Convert

(
A′x, Ux(σ′), Īrx

)
= Afx .

That is, whenever σ′ 6= σ it is possible to convert a ciphertext respective to A′x to a ciphertext
respective to Afx and thus to decrypt. However, when σ′ = σ there is no such conversion algorithm.

In the security proof we encode σ in the public parameters, such that it is only possible to
simulate Dual-Regev encryptions respective to matrices of the form Ax = Convert(Aσ, σ, Ux) (where
Aσ = EncodeX(A, σ)) but not respective to any other σ′. The indistinguishability relies on the
pseudorandomness of the PRF and the properties of [BGG+14].

Expanding the Function Class. The main idea here is to replace the PRF with a constrained
PRF. A constrained PRF, first defined in [BW13,KPTZ13,BGI14], allows the key owner to generate
constrained keys σf respective to functions f , with which it is possible to compute the value of
the PRF only on points x where f(x) = 1. More formally, there are two additional algorithms
(Constrain, ConstrainEval) such that if σf = Constrain(σ, f), then for all x for which f(x) = 1 it
holds that ConstrainEval(σf , f, x) = Eval(σ, x), while for all x for which f(x) = 0, σf does not reveal
information about Eval(σ, x).

Our construction uses a cPRF for policies in a function class F in order to construct an ABE
scheme for policies in F . The cPRF has to be single-key adaptively secure, and in addition it has
to satisfy two properties as follows.

• Gradual Evaluation requires that for any f, x for which f(x) = 1, the circuit descriptions of
the algorithms Eval(¡, x) and ConstrainEval(Constrain(¡, f), f, x) are identical.

• Key Simulation requires an additional public algorithm KeySim(f)→ σ′f that allows to sim-
ulate constrained keys. The keys should be indistinguishable from real constrained keys to a
distinguisher with no access to evaluations on points x where f(x) = 1.

We call a cPRF that satisfies all of those properties a conforming cPRF. The ABE construction
from a cPRF is a generalization of the IBE construction from a PRF. Details follow.

In the encryption algorithm, in order to encrypt respective to a policy f we compute a Dual-
Regev encryption with the public matrix A′f = Convert(Aσ′ , σ

′, Uf ), where Aσ′ = EncodeX(A, σ′)
(as in the IBE construction) and Uf is the circuit description of Constrain(¡, f). The key generation
algorithm remains the same as in the IBE construction. To decrypt with a key respective to x, one

4



has to first convert the ciphertext to be respective to the matrix A′x. This is done by computing
Convert(A′f , Uf (σ′), Uf→x), where Uf→x is the circuit description of ConstrainEval(·, f, x). Note that

Convert(A′f , Uf (σ′), Uf→x) = Convert(Convert(Aσ′ , σ
′, Uf ), Uf (σ′), Uf→x)

= Convert(Aσ′ , σ
′, Ux) (2)

= A′x

where the last equation holds by definition, and Equation (2) holds since Uf→x ◦ Uf = Ux by
the gradual evaluation property of the cPRF, and since Convert respects function composition as
described in Equation (1).

The rest of the analysis is very similar to the IBE case. The key-simulation property guarantees
that the adversary cannot tell whether the challenge ciphertext f∗ is generated respective to σ or
to a random σ′, as long as it cannot query for evaluations of σ on points x where f∗(x) = 1 (which
is indeed guaranteed by the ABE security game).

Constructing a Conforming cPRF. We construct a conforming cPRF for the function class
t-CNF for any constant t. A policy f is in the class t-CNF if it can be described by a conjunctive
normal form (CNF) formula, where each clause depends on t bits of the input. Our construction
is inspired by the [DKNY18] construction of bit-fixing cPRF for a constant number of keys. In
fact, their technique can be generalized to instantiate a family of cPRF schemes with a tradeoff
between the “CNF locality” of the supported policies and the number of keys. They instantiate it
with CNF locality 1 (i.e. bit-fixing) and t keys, while we instantiate it with CNF locality t and a
single key. Details follow.

Let ` be the input length of the cPRF. We consider the set S = {(T, v)} of all pairs (T, v) such
that T ⊆ [`], |T | = t, v ∈ {0, 1}t. For any input x ∈ {0, 1}` we define the set Sx = {(T, xT )}T
where xT is the substring of x on indices T . For all f we define the set Sf ⊆ S of all of the pairs
(T, v) that do not violate any of the clauses of f . It is easy to verify that for all x and f ,

f(x) = 1 ←→ Sx ⊆ Sf . (3)

The master secret key is a key σ of a standard PRF. Evaluation on a point x returns the value rx,
computed as

rx =
⊕

(T,v)∈Sx

Eval(σ(T,v), x) where σ(T,v) = Eval(σ, (T, v)) .

A constrained key for f consists of the values {σ(T,v)}(T,v)∈Sf . Correctness holds by Equation (3), se-
curity and key simulation holds by the pseudorandomness of the underlying PRF and gradual evalu-
ation holds since the circuit CPRF.Eval(¡, x) is a sub-circuit of CPRF.ConstrainEval(Constrain(¡, f), f, x).

1.3 Related Work

The idea to embed a PRF seed in a [BGG+14]-like construction was previously suggested by
[BV16,BL16].

5



Comparison with BV16. The work of [BV16] focuses on key-policy ABE with unbounded
attribute length. In their scheme, the evaluation of the PRF allows to dynamically increase the
width of the A matrix, so that Ax ← EncodeX(A, x) can be computed for x of varying length.
In particular, the PRF is evaluated over values that only depend on the length of the attribute,
where in our scheme the PRF is evaluated over the attribute value itself. Their ciphertexts contain
two “pieces” for every bit of the attribute and they use an additional ABE scheme in a black-box
manner in order to control the access that keys have to those pieces.

Their construction achieves semi-adaptive security, which means that the challenge attribute x∗

has to be announced before the first key query, but possibly after seeing the public parameters. This
property is due to the fact that in their cihpertexts the attribute value is implicitly XORed with a
hidden random string ∆, that can be chosen in the security reduction at the first key generation.
We note that if one desires a semi-adaptive scheme for a fixed attribute length `, their technique
can be instantiated with a PRG with poly(`) stretch instead of a PRF. That is, the incentives for
using a PRF are different in their work and ours.

Comparison with BL16. The work of [BL16] focuses on fully-secure signatures and IBE schemes
with tight reductions. Their usage of a PRF in the IBE scheme has some similarities to an IBE
instantiation of our approach, however the technicalities are different and the cPRF expansion is
not applicable to their approach. They use a PRF with tight security that on input x outputs a
single bit bx. A ciphertext for an identity x contains two independent Dual-Regev encryptions of
the message under two matrices Ax,0,Ax,1, and a key for x can only decrypt one of them Ax,bx .
In the security proof the PRF seed is encoded into the public parameters such that it is possible
to simulate keys for Ax,bx without the master secret key, while it is only possible to simulate the
“undecryptable” ciphertext part respective to Ax,1−bx .

1.4 Paper Organization

In Section 2 we go over the definitions of ABE and cPRF, and summarize lattice techniques from
previous works. In section 3 we define the conforming cPRF and provide a construction for policies
in t-CNF. In Section 4 we construct a fully secure ABE scheme that can be instantiated with any
conforming cPRF.

2 Preliminaries

2.1 Constrained PRF, Attribute-Based Encryption, t-CNF Policies

Definition 2.1 ((Standard) PRF). A pseudo-random function family (PRF) is a pair of ppt algo-
rithms (Setup,Eval) with the following syntax. Setup(1λ)→ sk takes as input a security parameter
λ and outputs a secret key sk. Evalsk(x) → rx takes as input a secret key sk and a bit-string
x ∈ {0, 1}`, and outputs a bit-sting rx ∈ {0, 1}k.

Pseudorandomness. A PRF family is secure if for any ppt adversary A it holds that∣∣∣Pr[AEvalsk(·)(1λ) = 1]− Pr[AO(·)(1λ) = 1]
∣∣∣ = negl(Ν)

where sk← Setup(1λ) and O is a random oracle.

6



Definition 2.2 (Constrained PRF). Let F be a function class such that F ⊆ {0, 1}` → {0, 1}. A
constrained pseudo-random function (cPRF) for policies in F is a tuple of ppt algorithms with the
following syntax.

• Setup(1λ)→ pp,msk takes as input a security parameter λ and outputs public parameters pp
along with a master secret key msk.

• Evalmsk(x)→ rx is a deterministic algorithm that takes as input a master secret key msk and
a bit-string x ∈ {0, 1}`, and outputs a bit-sting rx ∈ {0, 1}k.

• Constrainmsk(f) → skf takes as input a master secret key msk and a function f ∈ F , and
outputs a constrained key skf .

• ConstrainEvalskf (x) is a deterministic algorithm that takes as input a constrained key skf and

a bit-string x ∈ {0, 1}`, and outputs a bit-string r′x ∈ {0, 1}k.

Correctenss. A cPRF scheme is correct if for all x ∈ {0, 1}` and f ∈ F for which f(x) = 1, it
holds that Evalmsk(x) = ConstrainEvalskf (x) where (pp,msk)← Setup(1λ) and skf ← Constrainmsk(f).

Pseudorandomness. The adaptive security game of a cPRF scheme between an adversary A
and a challenger C is as follows.

1. Initialization: C generates (pp,msk)← Setup(1λ) and sends pp to A.

2. Queries Phase I: A makes (possibly many) queries in an arbitrary order:

• Evaluation Queries: A sends a bit-string x ∈ {0, 1}`, C returns rx ← Evalmsk(x).

• Key Queries: A sends a function f ∈ F , C returns skf ← Constrainmsk(f).

3. Challenge Phase: A sends the challenge bit-string x∗ ∈ {0, 1}`. C uniformly samples b
$←

{0, 1}. If b = 0 then C returns r∗
$← {0, 1}k. Otherwise it returns r∗ ← Evalmsk(x

∗).

4. Queries Phase II: same as the first queries phase.

5. End of Game: A outputs a bit b′.

A wins the game if (1) b′ = b, (2) all of the evaluation queries are not for x∗ and (3) all of the
key queries f are such that f(x∗) = 0. The single-key adaptive security game is as described above,
except that A can only make a single key query throughout the entire game. A cPRF scheme is
secure (resp. single-key secure) if for any ppt adversary A, the probability that A wins in the
adaptive (resp. single-key adaptive) security game is at most 1/2 + negl(Îť).

Definition 2.3 (Attribute-Based Encryption). Let F be a function class such that F ⊆ {0, 1}` →
{0, 1}. A (ciphertext-policy) atrribute-based encryption (ctpABE) for policies in F is a tuple of
ppt algorithms with the following syntax.

• Setup(1λ)→ pp,msk takes as input a security parameter λ and outputs public parameters pp
along with a master secret key msk.

7



• KeyGenmsk(x)→ skx takes as input a master secret key msk and a bit-string x ∈ {0, 1}`, and
outputs a key skx.

• Enc(f, µ) → ct takes as input a function f ∈ F and plaintext µ ∈ {0, 1}, and outputs a
ciphertext ct.

• Decskx(ct, f) takes as input a key skx, a ciphertext ct and a function f ∈ F , and outputs a bit
µ′ ∈ {0, 1}.

Correctenss. A ctpABE scheme is correct if for all x ∈ {0, 1}` and f ∈ F for which f(x) = 1,
and for all ¾ ∈ {0, 1}, it holds that

Pr[Decskx(Enc(f, Âľ), f) 6= Âľ] = negl(Îť)

where (pp,msk)← Setup(1λ) and skx ← KeyGenmsk(x).

Security. The adaptive security game of a ctpABE scheme between an adversary A and a chal-
lenger C is as follows.

1. Initialization: C generates (pp,msk)← Setup(1λ) and sends pp to A.

2. Queries Phase I: A makes (possibly many) key queries. For each query, A sends a string
x ∈ {0, 1}` and C returns skx ← KeyGenmsk(x).

3. Challenge Phase: A sends the challenge function f∗ ∈ F . C uniformly samples b
$← {0, 1}

and returns ct∗ ← Enc(f∗, b).

4. Queries Phase II: same as the first queries phase.

5. End of Game: A outputs a bit b′.

A wins the game if (1) b′ = b and (2) all of the key queries x are such that f∗(x) = 0. A ctpABE
scheme is secure if for any ppt adversary A, the probability that A wins in the adaptive security
game is at most 1/2 + negl(Îť).

In this work we focus on the class of functions that can be described in a conjunctive normal
form (CNF), where each clause is of constant locality. We give now a definition.

Definition 2.4 (t-CNF). A t-CNF policy f : {0, 1}` → {0, 1} is a set of clauses f = {(Ti, fi)}i,
where for all i, Ti ⊆ [`], |Ti| = t and fi : {0, 1}t → {0, 1}. For all x ∈ {0, 1}` the value of f(x) is
computed as

f(x) =
∧
i

fi(xTi)

where xT is the length-t bit-string consisting of the bits of x in the indices T . A function class F
is t-CNF if it consists only of t-CNF policies for some fixed ` ∈ N and a constant t ≤ `. If F is a
t-CNF function class, we say that t is the CNF locality of F .

8



2.2 Lattice Trapdoors, Bounded Distributions, LWE

Lattice Trapdoors. Let n, q ∈ Z, g = (1, 2, 4, . . . , 2dlog qe−1) ∈ Zdlog qe
q and m = ndlog qe. The

gadget matrix G is defined as the diagonal concatenation of g n times. Formally, G = g ⊗ In ∈
Zn×mq . For any t ∈ Z, the function G−1 : Zn×tq → {0, 1}m×t expands each entry a ∈ Zq of the
input matrix into a column of size dlog qe consisting of the bits representation of a. For any matrix
A ∈ Zn×tq , it holds that G ·G−1(A) = A.

The (centered) discrete Gaussian distribution over Zm with parameter τ , denoted DZm,τ , is the

distribution over Zm where for all x, Pr[x] ∝ e−π‖x‖
2/τ2 . Let n,m, q ∈ N and consider a matrix

A ∈ Zn×mq . For all v ∈ Znq we let A−1
τ (v) denote the random variable whose distribution is the

Discrete Gaussian DZm,τ conditioned on A ·A−1
τ (v) = v.

A τ -trapdoor for A is a procedure that can sample from a distribution within 2−n statistical
distance of A−1

τ (v) in time poly(n,m, log q), for any v ∈ Znq . We slightly overload notation and
denote a τ -trapdoor for A by A−1

τ . The following properties had been established in a long sequence
of works.

Corollary 2.1 (Trapdoor Generation [Ajt96,MP12]). There exists an efficiently computable value
m0 = O(n log q) and an efficient procedure TrapGen(1n, q,m) such that for all m ≥ m0 outputs
(A,A−1

τ0 ), where A ∈ Zn×mq is 2−n-uniform and τ0 = O(
√
n log q log n).

We use the most general form of trapdoor extension as formalized in [MP12].

Theorem 2.2 (Trapdoor Extension [ABB10b, MP12]). Given A ∈ Zn×mq with a trapdoor A−1
τ ,

and letting B ∈ Zn×m′q be s.t. A = BS (mod q) where S ∈ Zm′×m with largest singular value s1(S),

then (A−1
τ ,S) can be used to sample from B−1

τ ′ for any τ ′ ≥ τ · s1(S).

A few additional important corollaries are derived from this theorem. We recall that s1(S) ≤√
m′m ‖S‖∞ and that a trapdoor G−1

O(1) is trivial. The first is a trapdoor extension that follows by

taking S = [Im′‖0m]T .

Corollary 2.3. Given A ∈ Zn×m′q , with a trapdoor A−1
τ , it is efficient to generate a trapdoor

[A‖B]−1
τ ′ for all B ∈ Zn×mq , for any m ∈ N and any τ ′ ≥ τ .

Next is a trapdoor extension that had been used extensively in prior work. It follows from
Theorem 2.2 with S = [−RT ‖Im]T .

Corollary 2.4. Given A ∈ Zn×m′q , and R ∈ Zm′×m with m = ndlog qe, it is efficient to compute

[A‖AR + G]−1
τ for τ = O(

√
mm′ ‖R‖∞).

Note that by taking A uniformly and R to be a high entropy small matrix, e.g. uniform in
{−1, 0, 1}, and relying on the leftover hash lemma, Corollary 2.1 is in fact a special case of this
one.

Lattice Evaluation. The following is an abstraction of the evaluation procedure in previous
LWE based FHE and ABE schemes, that developed in a long sequence of works [ABB10b, MP12,
GSW13,AP14,BGG+14,GVW15].

9



Theorem 2.5. There exist efficient deterministic algorithms EvalF and EvalFX such that for all
n, q, ` ∈ N and m = ndlog qe, for any depth d boolean circuit f : {0, 1}` → {0, 1}k and for every
x ∈ {0, 1}`, for any matrix A ∈ Zn×m·`q , the outputs H ← EvalF(f,A) and Ĥ ← EvalFX(f, x,A)

are both in Zm·`×m·k and it holds that ‖H‖∞ ,
∥∥∥Ĥ∥∥∥

∞
≤ (2m)d and

[A− x⊗G]Ĥ = AH− f(x)⊗G (mod q)2 .

Moreover, for any pair of circuits f : {0, 1}` → {0, 1}k, g : {0, 1}k → {0, 1}t and for any matrix
A ∈ Zn×m·`q , the outputs Hf ← EvalF(f,A), Hg ← EvalF(g,AHf ) and Hg◦f ← EvalF(g ◦ f,A)
satisfy HfHg = Hg◦f .

Bounded Distributions. The following definitions and corollaries, taken from [BV16], will allow
us to properly set the parameters of our scheme.

Definition 2.5. A distribution χ supported over Z is (B, ε)-bounded if Pr
x

$←χ
[|x| > B] < Îľ.

Definition 2.6. A distribution χ̃ supported over Z is (B, ε)-swallowing if for all y ∈ [−B,B] ∩ Z
it holds that χ̃ and y + χ̃ are within ε statistical distance.

Corollary 2.6. For every B, ξ, δ there exists an efficiently sampleable distribution that is both
(B, ξ)-swallowing and (B ¡

√
log (1/δ)/ξ,O(δ))-bounded.

Definition 2.7. A distribution χ̃ supported over Z is (χ, ε)-swallowing, for a distribution χ, if it
holds that χ̃ and χ+ χ̃ are within ε statistical distance. We omit the ε when it indicates a negligible
function in a security parameter that is clear from the context.

Corollary 2.7. Let B(λ) be some function and let B̃(λ) = B(λ) · λω(1), then there exists an
efficiently sampleable ensemble {χ̃λ}λ such that χ̃ is χ-swallowing for any B(λ)-bounded {χλ}λ,
and also B̃(Ν)-bounded.

Learning With Errors. The Learning with Errors (LWE) problem was introduced by Regev [Reg05].
In this work we will use its decisional version.

Definition 2.8 (Decisional LWE (DLWE) [Reg05] and its HNF [ACPS09]). Let Îť be the security
parameter, n = n(λ) and q = q(λ) be integers and let χ = χ(λ) be a probability distribution over
Z. The DLWEn,q,χ problem states that for all m = poly(n), letting A← Zn×mq , s← Znq , e← χm,

and u← Zmq , it holds that
(
A, sA + e

)
and

(
A,u

)
are computationally indistinguishable.

In this work we only consider the case where q ≤ 2n. Recall that GapSVPγ is the (promise)
problem of distinguishing, given a basis for a lattice and a parameter d, between the case where the
lattice has a vector shorter than d, and the case where the lattice doesn’t have any vector shorter
than γ ·d. SIVP is the search problem of finding a set of “short” vectors. The best known algorithms
for GapSVPγ ( [Sch87]) require at least 2Ω̃(n/ log γ) time. We refer the reader to [Reg05, Pei09] for
more information. The following corollary allows us to appropriately choose the LWE parameters
for our scheme according to known reductions from GapSVPγ and SIVPγ to DLWEn,q,χ.

2For all n ∈ Z and v ∈ {0, 1}n the term v ⊗G denotes a tensor product of the binary row-vector v = (v1, . . . , vn)
and the matrix G. That is, v ⊗G = [v1 ·G‖ . . . ‖vn ·G].

10



Corollary 2.8 ( [Reg05, Pei09, MM11, MP12, BLP+13]). For all Îľ > 0 there exists functions q =
q(n) ≤ 2n, χ = χ(n) such that χ is B-bounded for some B = B(n), q/B ≥ 2n

Îľ
and such that

DLWEn,q,χ is at least as hard as the classical hardness of GapSVPγ and the quantum hardness of

SIVPγ for γ = 2Ω(nε).

3 Conforming cPRF

Our ABE construction in the next section instantiates a constrained PRF that has to satisfy some
special properties, gathered under the following definition.

Definition 3.1 (Conforming cPRF). A cPRF scheme is conforming if, in addition";"""date"",""2019-06-02T13:01:49Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2019-06-02T13:01:49Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is MiKTeX-pdfTeX 2.9.6668 (1.40.19)""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2019-06-02T13:01:49Z""
""created"",""2019-06-02T13:01:49Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-06-02T13:01:49Z""
""resourceName"",""365.pdf""
""Author"",""""
""producer"",""pdfTeX-1.40.19""
""pdf:docinfo:producer"",""pdfTeX-1.40.19""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""1"",""7"",""39"",""16"",""9"",""10"",""13"",""32"",""37"",""9"",""14"",""23"",""43"",""131"",""17"",""84"",""0"",""0"",""0"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2019-06-02T13:01:49Z""
""Last-Modified"",""2019-06-02T13:01:49Z""
""dcterms:modified"",""2019-06-02T13:01:49Z""
""title"",""""
""Last-Save-Date"",""2019-06-02T13:01:49Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2019-06-02T13:01:49Z""
""meta:save-date"",""2019-06-02T13:01:49Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is MiKTeX-pdfTeX 2.9.6668 (1.40.19)""
""Content-Length"",""471031""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""23""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""1273"",""3070"",""3156"",""2597"",""2519"",""2097"",""2508"",""2024"",""1554"",""2203"",""2413"",""2152"",""2164"",""2937"",""2191"",""1783"",""1803"",""1411"",""2195"",""2335"",""2244"",""2365"",""485""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-06-02T13:01:49Z""
";https://scholar.google.com/scholar?start=720&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094647-1102;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Strong Known Related-Key Attacks and the Security of ECDSA;TH Yuen, SM Yiu ; International Conference on Network and System …, 2019  Springer;;"… This attack is captured in the Strong KRKA model, by signing oracle queries with the addition

function … signatures (including multi-signatures, aggregate signatures, threshold signatures, etc.)

are proposed in the blockchain system, it … In: Robshaw, M., Katz, J. (eds.) CRYPTO 2016 …";Cité 1 fois;Les 2 versions;null;;;;https://scholar.google.com/scholar?start=920&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094544-670;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;A classification framework for stablecoin designs;A Moin, EG Sirer, K Sekniqi ; arXiv preprint arXiv:1910.10098, 2019  arxiv.org;;"… StatiCoin is unique because it is crypto-collateralized but does not require overcollateralization,

an … is a malicious actor intent on sabotaging the stability, a price oracle can serve as … active and

popular stablecoins, including MakerDao, use only a few price oracles, making them a …";Cité 10 fois;Les 6 versions;[PDF] arxiv.org;https://arxiv.org/pdf/1910.10098;"
A Classification
Framework for Stablecoin Designs

Amani Moin, Emin Gün Sirer, and Kevin Sekniqi

Cornell University and AVA Labs

Abstract. Stablecoins promise to bridge fiat currencies with the world
of cryptocurrencies. They provide a way for users to take advantage of
the benefits of digital currencies, such as ability to transfer assets over the
internet, provide assurance on minting schedules and scarcity, and enable
new asset classes, while also partially mitigating their volatility risks. In
this paper, we systematically discuss general design, decompose exist-
ing stablecoins into various component design elements, explore their
strengths and drawbacks, and identify future directions.

Keywords: Stablecoins - Stable Payments

1 Introduction

Cryptoasset prices are famous for their volatility. Though many cryptoassets
aspire to become world currencies, most are frequently dismissed as no more
than speculative assets due to their wild price swings.

Money is supposed to have three functions: a store of value, a unit of account,
and a medium of exchange. Stability is key to all these functions. Store of value is
the most salient; if people store their wealth in an asset that constantly fluctuates
in value, their wealth will fluctuate accordingly. A volatile asset is also a poor unit
of account, because it is inconvenient to denominate prices in something which
constantly changes in value. Every time the value of the unit of account changes,
all prices must be adjusted accordingly. Finally, and most crucially, a currency
needs to be stable to function as a medium of exchange; this allows people to be
be fairly and predictably compensated for goods and services without changes
in value during the payment process.

Stablecoins are a class of cryptoassets created to address this problem. As the
name implies, they are designed to be price stable with respect to some reference
point. There has recently been an explosion in the number of stablecoin projects
announced, especially following the crash in Bitcoin prices in early 2018. There
are over a hundred stablecoins in existence or in progress, with the top three
projects now representing a market capitalization of $4.6B [22]. Although the
sheer number of projects seems overwhelming, they can all be decomposed into
a few key features.

ar
X

iv
:1

91
0.

10
09

8v
1 

 [
q-

fi
n.

G
N

] 
 1

8 
Se

p 
20

19



2 Amani Moin, Emin Gün Sirer, and Kevin Sekniqi

Roadmap. We briefly review related works in Section 2. In Section 3, we break
down the taxonomy of stablecoins based on the first three constituent axes: the
peg type, the collateral type, and the collateral amount. In Section 4, we expand
on additional axes by discussing the mechanism of action chosen by various
stablecoin families. In Section 5 we discuss methods to measure prices. In Section
6, we discuss some design features relevant to digital currencies in general, but
especially important for stablecoins. Finally, we discuss future directions for
stablecoins in Section 7.

2 Related Work

One of the first stablecoin taxonomies classified stablecoin projects by collat-
eral type and discussed pros and cons of each category [56]. Several papers
and reports have followed a similar taxonomy, adding more detail on individ-
ual projects [57] [58] [48]. A paper by Pernice et. al takes a different approach,
categorizing stablecoins by monetary and exchange rate regimes [54]. Our contri-
bution is extending the existing taxonomies with a discussion of other important
stablecoin design aspects, namely price stabilizing mechanisms and price mea-
surement methods. We also categorize many of the existing stablecoin projects
according to our extended taxonomy.

3 Peg and Collateral

3.1 Peg

The most salient choice for stablecoin design is the peg, which oftentimes is
included in the name of the stablecoin.1 USD is a popular choice, likely due
to USD being typically considered a stable store of value around the world. In
fact, it is not uncommon for foreign citizens, especially those in emerging and
developing economies, to store their wealth in USD rather than their national
currency. The other benefit of using USD is that price comparison is easy. A
singular fiat currency peg allows one to check whether the peg holds by simply
comparing the dollar price of an object to the pegged coin price of the same
object. Other stable fiat currencies, such as the Euro, the Japanese Yen, and the
Swiss Franc, are also popular choices for similar reasons.

Besides fiat, there are also stablecoins pegged to commodities, most com-
monly gold. Some examples include Digix [27] and HelloGold [31]. It is inter-
esting to note that, in general, there are fewer commodity-pegged coins than
fiat-pegged coins. A possible explanation is that commodity prices fluctuate in
value more than fiat currencies, although typically less severely than most digital
currencies.

Other stablecoins may choose to peg to a bundle of currencies and/or com-
modities. This has the benefit of insulating the stablecoin against shocks to any

1 Examples include TrueUSD [69], USDC [20], USDX [55], USDVault [71], A-Eurs [61],
and many others.



A Classification Framework for Stablecoin Designs 3

Stablecoins

Peg

Fiat

Commodity

Combination

Index

Collateral

Type

Fiat

Commodity

Combination

None

Crypto

Amount

Full	Reserve

Partial	Reserve

None

Overcollateralized

Mechanism

Reserve	of	Backed	Asset

Dual	Coin

Algorithmic

Leveraged	Loans

Price	Info

Oracle

Voting

Trades

Fig. 1. Stablecoin taxonomy, decomposed into four main axes: peg, collateral, mecha-
nism, and price information.

one country, currency, or commodity. However, pegging to a bundle can also
have the opposite effect and introduce noise if some of the assets included in the
bundle are very volatile. Saga [60], for example, is pegged to the IMF’s special
drawing rights (SDR), a basket of world currencies curated by the IMF. Cur-
rencies are selected into the SDR if the issuing country is one of the world’s top
exporters, the currency is widely used in international transactions, and the cur-
rency is widely traded in foreign exchange markets. However, the SDR is seldom
used in any context other than the IMF’s store of value and unit of account,
making it a less practical choice than the dollar. Facebook’s upcoming Libra
also plans to peg its currency to an as of yet undetermined basket of currencies
and assets.

Saga plans to later peg their currency to the consumer price index (CPI)
if they outgrow the SDR, i.e. if they become a dominant world currency. The
CPI is a unitless index which tracks the inflation of the price of a basket of
consumer goods. No stablecoin is currently pegged to the CPI, so it is unclear
how this would be executed. It is possible, for example, that the stablecoin supply
would be adjusted so the nominal price level remains constant. Pegging to a
fiat currency or commodity with finite supply can eventually lead to problems



4 Amani Moin, Emin Gün Sirer, and Kevin Sekniqi

of scale, and pegging to an index can circumvent this problem.2 However, the
choice of CPI as a peg is not ideal for a variety of reasons. It is typically measured
monthly or even less frequently, due to logistical challenges in determining what
should be in the basket and how much each component should be weighted. There
are also regional differences in consumption, so it is unclear how to construct a
basket that reflects global spending patterns.

3.2 Collateral

Emergent currencies often make use of collateral to ensure that the circulating
currency has redemption value. This provides a lower bound on the price, thereby
mitigating some of the risk of holding, using, and denominating debts in the
currency. Since the goal of collateralizing is to bound the redemption value, it is
easiest and most effective, but not necessary,3 to use whatever the stablecoin is
pegged to. If users can always redeem one unit of the stablecoin for one dollar,
arbitrageurs should ensure that it never trades at any other price.

Unfortunately, collateralizing a coin creates the problem of securely storing
large quantities of the collateral.Traditionally, the best place to store large quan-
tities of cash is in a bank, because it is secure, relatively easy to audit, and often
comes with deposit insurance. However, this is also centralized, thus making it
prone to deceptive practices. For example, Tether [66] recently admitted it was
only 74% collateralized [65], despite initially claiming full collateralization [66].
Moreover, there are often limits to how much deposit insurance covers, poten-
tially leaving the majority of the reserve uninsured. Some stablecoins avoid this
problem by storing their collateral as physical cash in a vault instead of a bank.
For example, Rockz [59] stores 90% of its collateral in the form of physical fiat
currency in an underground vault in the Swiss Alps.

Commodity backed stablecoins also suffer from the problem of where to store
their collateral, since there are fewer institutions which accept and insure de-
posits in the form of commodities than ones that accept cash. This, in turn,
leads to a high degree of centralization.

One way to avoid having to store large amounts of fiat is to collateralize
with another cryptocurrency. This has the advantage of potentially decentralized
operation, and allows for easier diversification across backing assets. The problem
with this approach is that digital collateral can itself be very volatile, making it
hard to use as a guarantee of value. Any stablecoin backed by cryptocurrencies
must have some mechanism built in to safely handle large swings in the value of
the underlying collateral. We discuss these mechanisms in section 4.

Other stablecoins do away with the problem of volatile collateral by simply
not collateralizing the currency at all. This has many advantages. First, not
having any collateral to store or unlock simplifies many logistical challenges.
Second, it is also cheap to operate, since it does not require the issuer to keep
real or crypto assets on hand. Unfortunately, this ease of operation comes with

2 This is one of the reasons the US went off of the gold standard.
3 USDVault for example is pegged to USD but collateralized with gold.



A Classification Framework for Stablecoin Designs 5

0.0

0.3

0.6

0.9

1.2

2015 2016 2017 2018 2019
Date

N
ub

its
 P

ric
e 

(U
S

D
)

Fig. 2. NuBits price collapse

drawbacks. Algorithms are usually gameable. The value of the currency in this
case stems purely from the reliability of the issuing mechanism and/or people’s
beliefs. Once users’ expectations of the coin’s stability change, whether due to a
flaw in design or idiosyncratic changes in sentiment, there may be little to keep
the price afloat because there is no inherent redemption value. Consequently,
when these stablecoins fail, they tend to do so swiftly and catastrophically. One
example is NuBits [45], which dropped from its pegged price of $1 to less than
$0.30 over the course of 2 weeks in early 2018. It never recovered its peg, and
has been trading below $0.10 for the past six months.4

3.3 Collateral amount

Hand in hand with the decision of collateral type comes the decision of collat-
eral amount. Since collateral serves to support the price by creating a reliable
redemption value, the best choice seems to be a fully collateralized stablecoin.
If every unit of currency can be redeemed for the underlying asset, there is vir-
tually no rational reason they should ever trade at different prices, thus making
price fluctuations minimal. However, one to one collateralization is sometimes
excessive, and sometimes insufficient.

Having a full reserve, where the value of the collateral is exactly the value of
the circulating currency, makes it hard for a currency to scale. As the stablecoin

4 Note that USD is not collateralized, and yet it remains stable. However, when the
dollar was a fledgling currency it was backed by gold. It was only after extensive
global adoption that the backing was gradually eased-off. Additionally, the US gov-
ernment has the infrastructure to support this type of regime. US federal law makes
it so that businesses are required to accept US issued currency as legal tender. There
are also regulatory and executive agencies that enforce compliance.



6 Amani Moin, Emin Gün Sirer, and Kevin Sekniqi

becomes more widely used, the issuers have to keep buying more collateral in
order to keep up with demand. Nevertheless, this stablecoin design has been
successfully utilized by Hong Kong’s currency board; the Hong Kong Dollar is
fully collateralized by USD and has maintained a roughly 7.8 to 1 peg to the US
dollar since the early 1980s. It is currently the 13th most traded currency in the
world [36].

Instead of staying fully collateralized, some currencies, like Saga, try to mimic
the historical trajectory taken by the US Dollar. Such currencies initially fully
collateralize their stablecoin, then slowly reduce their collateral ratio and ease off
the peg once the money supply has exceeded some threshold. Although Tether
eventually admitted they were not fully collateralized as they initially claimed,
there was no ostensible detriment to the price. A reason for the continued sta-
bility despite only partial collateralization is that full collateral is not necessary
as long as people do not believe that more than the entire reserve amount will
ever be cashed out at once. It is also worth noting that almost any supposedly
fully collateralized fiat backed stablecoin whose collateral is being held in a bank,
such as USDC, is functionally a partial reserve currency. All commercial banks
keep only some of their deposits on hand and use the rest for investments or to
issue loans. This does not cause any problems as long as they keep enough on
hand to satisfy demand for withdrawals.

Other coins, especially algorithmic ones such as Basis [2], do not keep any
collateral at all. Instead, value is preserved purely by expanding supply when
the price is too high and contracting it when the price is too low. On the other
end of the spectrum, many currencies collateralized by crypto-currencies keep
more than the value of the circulating currency in reserve to guard against price
swings in the collateral. This way, even if the collateral asset depreciates, there
is still enough for each unit of the stablecoin to be redeemed for an equivalent
amount of the underlying asset.

4 Mechanics

All stablecoins require some mechanism to adjust the price when it deviates
from the peg. Usually, this is done by expanding supply when the price is too
high and contracting it when the price is too low. This means that there usually
needs to be some way of measuring the price (covered further in the next section)
and knowing how much to expand or contract the supply. Most stablecoins are
designed such that rational, self interested users will act to restore the peg when
the price deviates. For example, this could be achieved by allowing users to
redeem stablecoins for collateral when the price of the stablecoin is too low.
Other stablecoins issue a secondary token designed to absorb the volatility of
the first, resulting in a stablecoin/volatilecoin pair. Still others depend on an
algorithmic market making mechanism or central-bank contract to manage the
supply.



A Classification Framework for Stablecoin Designs 7

Reserve of Pegged Asset Many stablecoins will build a mechanism where
users will be incentivized to expand or contract the supply until the price re-
turns to the peg. The simplest way to achieve this is in a fully collateralized
system backed by the pegged asset, and allow users to expand supply when
the price is too high and redeem when the price is too low. Arbitrageurs earn
money while helping maintain the peg. For example, if a stablecoin pegged to
USD is trading at less than $1, stablecoin holders should redeem the coin for
the underlying collateral, thereby buying a dollar for less than a dollar. This
will contract the supply until the price returns to the peg and the arbitrage
opportunity disappears, or until the reserve runs out.

On the other hand, if the market price of the stablecoin is above $1, many sys-
tems will allow users to expand the supply by wiring funds to the account where
the rest of the collateral is being held. This allows the user to buy something
worth more than $1 by paying only $1 for it. The simplicity and autonomy of
this system makes it extremely appealing, which is why a majority of stablecoins
in circulation today use this method, or a very similar one. However, it is not
foolproof. On October 15, 2018, the price of Tether briefly dropped below $0.93
due to a large selloff. The price recovered to above $0.98 within the day and
appears to have suffered no lasting effects [22]. Other notable examples of this
design include USDC, TrueUSD, Carbon [18], Paxos [19], Gemini Dollars [23],
and many others.

As stated previously, the main problem with allowing users to always redeem
for collateral is storing large amounts of collateral at some physical location.
Since it is expensive to provide the security needed to protect large sums of
money, most stablecoins rely on one central location, like a bank. This introduces
two issues: centralization and dependency on legacy financial institutions. USDC
gets around one of these problems by storing collateral at a network of banks
rather than a single one. However, it still relies heavily on existing banks. The
other problem with this type of system is the ability to scale. As previously
discussed, this makes it difficult, though not impossible, to become a global
currency due to the inconvenience of storing assets of such high value in a large
number of locations. This inconvenience, is one of the reasons USD outgrew the
gold standard.

A common variation on this design requires a central authority to mint the
coins, but allows people to redeem the stablecoin for the underlying collateral.
This creates a lower bound on the price of the stablecoin but not an upper
bound, since users can redeem when the stablecoin price is too low but cannot
mint when the price is too high. This is common in cases where the collateral is
not necessarily dollars, such as Digix. Since it would be inconvenient to accept
and verify gold deposits from individual users, users are not allowed to mint
Digix by contributing capital to the collateral pool. They can, however, still
redeem their Digix for physical gold, thereby creating a lower bound on the
value of Digix.

In addition to allowing people to mint coins, Tether was released in waves,
allegedly at strategic times to prop up the price of Bitcoin [34]. Users can redeem



8 Amani Moin, Emin Gün Sirer, and Kevin Sekniqi

Tether for USD, but since Tether is no longer fully collateralized, they also
reserve the right to deny people the right to redeem.

Another variation being employed by Facebook’s Libra [46] is to allow only
the set of validators to mint or redeem coins, instead of all users. This reduces
overhead since presumably larger amounts would be transacted each time, and
at a lower frequency. This may come at the cost of a lower speed of adjustment,
since the set of potential arbitrageurs who can correct the price is restricted.

Dual coin Another way to maintain stability is to pair the pegged coin with
a secondary coin which absorbs the volatility of the first. The most well known
example of this is the seigniorage shares model employed by the original formula-
tion of Carbon. When the price of the stablecoin dips below the peg, a secondary
coin is auctioned in exchange for the stablecoin. The proceeds from the auction
are then burned to contract the supply. When the price of the stablecoin is above
the peg, additional coins are minted to holders of the secondary token. Holders
of the secondary token help prop up the price when the currency inflates and
are rewarded during deflationary periods.

There are two big concerns with this type of system. One is that the secondary
coin often meets the SEC’s definition of a security. Regulatory complications
stemming from this designation were enough to keep Basis from launching [1].
Carbon also changed from a dual coin system to a fiat backed system, for undis-
closed reasons, possibly due to regulatory hurdles. The second concern is that if
holders of the primary token do not believe that the stablecoin will appreciate
in the future, there is no incentive to buy or hold the secondary token. In other
words, one needs a strong contingent of users who, even during a downturn, be-
lieve that the stablecoin will eventually appreciate in value. Additionally, since
cryptocurrency markets are often subject to long downturns, people may be re-
luctant to wait for extended, indeterminate amounts of time for their investment
to pay off. Since there is no collateral backing this system, if people are not will-
ing to buy the secondary coin, there will be no force propping up the value of
the stablecoin.

Variations on this design include USDX and Celo [39], which use concepts
from dual coin systems and redemption based systems to peg their tokens. USDX
is a stablecoin collateralized with Lighthouse (LHT), a digital currency. USDX is
pegged to USD but backed over 200% by LHT, which is stored in two centralized
funds. People are free to exchange LHT to USDX and vice versa at a valuation
of $1/USDX. As such, when USDX is trading at a price of less than $1, people
are incentivized to redeem it for $1 worth of LHT, contracting the supply and
raising the price. LHT ends up absorbing the volatility of USDX because the
supply of USDX is contracted by expanding the circulating supply of LHT. The
main issue in this design stems from USDX being 200% collateralized by LHT.
The largest possible market cap for USDX is half the market cap of LHT, and
if the market value of LHT declines, so does the potential market cap of USDX.
It is unclear what LHT derives its value from, so the potential market cap of
USDX might be small and/or unstable.



A Classification Framework for Stablecoin Designs 9

Celo works similarly to USDX, but with a few additions. Celo is backed by
CeloGold,5 Bitcoin, and Ethereum. In addition to allowing people to redeem
Celo for CeloGold and vice versa, there is an algorithmic central bank which
buys and sells Celo and CeloGold to stabilize the price.

StatiCoin/RiskCoin [62] is another variation of the dual coin system which
allows creation and redemption of coins to maintain a peg. Users who want
to mint StatiCoin send ETH to the contract and receive a dollar equivalent
amount of StatiCoin in return. When they want to redeem, they send StatiCoin
to the contract and receive an equivalent dollar amount of ETH. Users who want
to mint RiskCoin also send ETH to the contract and receive a corresponding
amount of RiskCoin in return, depending on what the current RiskCoin price
is. StatiCoin can always be redeemed for $1 worth of ETH, provided there is
enough collateral, while RiskCoin holders are the residual claimant to the ETH
held by the contract. If there is $100 worth of ETH held by the contract, 90
StatiCoins in circulation, and 2 RiskCoins in circulation, the value of all of the
outstanding Riskcoin is $10 and each RiskCoin is worth $5. If the next day the
value of the ETH held in the contract drops to $90, RiskCoin will be worth
$0 and users will not be allowed to mint additional RiskCoin until the dollar
value of collateral exceeds the number of StatiCoin issued. StatiCoin is unique
because it is crypto-collateralized but does not require overcollateralization, an
inefficient mechanism for absorbing volatility. If the value of the collateral falls
below the market cap of StatiCoin, StatiCoin may become unpegged because
not all holders of StatiCoin will be able to redeem for the underlying collateral.
If the price of ETH drops enough to reduce the price of RiskCoin to 0, then
StatiCoin will become an unreliable store of value precisely when Ethereum is
losing value and a stable valued asset is most needed.

Terra [40] is yet another dual coin stablecoin, with its volatility absorbed by
the secondary token Luna. Luna serves two purposes in this system. It absorbs
volatility because it is auctioned to contract the supply when the stablecoin
price is too low and purchased with Terra when the stablecoin price is too high.
It is also the staking token of the system. Fees and mining rewards, paid in
Terra, are increased when Terra decreases in value to incentivize holding Luna
and smooth the pro-cyclicality of the value of Luna. Unlike previously discussed
designs, such as Staticoin/Riskcoin, the secondary token Luna can retain value
and creates payoffs from fees and mining rewards even in an extended contrac-
tion. However, it does this by raising fees when the value of Terra is decreasing,
which discourages Terra use when the value of Terra is already low. Terra also
increases the staking pool in times when the market cap of Terra is small and
there is less need for stakers, and decreases it when the market cap is large and
more security is needed.

Yet another variation on the dual coin system is the triple coin system pro-
posed by Basis. Instead of having a singular volatility absorbing coin, Basis has
bond tokens and share tokens. Bond tokens are auctioned off when the price of
Basis decreases below $1, and each one is redeemable for 1 Basis when the price

5 Despite its name, CeloGold not actually backed by gold or any other asset



10 Amani Moin, Emin Gün Sirer, and Kevin Sekniqi

of Basis is above $1. If all of the Bond tokens have been redeemed and the price
of Basis is still above $1, additional Basis is minted pro rata to holders of share
tokens until the price of Basis returns to $1. Holders of Basis bonds absorb the
downside and are the first to benefit from increases in the market cap of Basis,
while holders of Basis shares benefit only when there are large expansions in the
value of Basis. There are infinite ways to tranche the volatility absorbing coin;
in theory there could be systems with four or more coins splitting the stablecoin
volatility across several parties.

Algorithmic Other currencies use a fully algorithmic approach to adjust the
supply of the stablecoin in response to price fluctuations. One such example
is Ampleforth, previously named Fragments [42]. Whenever the value of Am-
pleforth changes, token holders have their balances adjusted proportionally to
preserve the value of a single token. For example, if Ampleforth is originally
worth $1, then, after an increase of 10% to $1.10, all balances will automatically
be inflated by 10%. Likewise, if the value of Ampleforth declines, each Ample-
forth holder’s balance will be decreased accordingly. This makes Ampleforth a
stable unit of account, since by design, the ratio of Ampleforth’s market cap
to the number of Ampleforth tokens is periodically adjusted to be $1. Unfor-
tunately, this is not a good store of value. Holding Ampleforth is no different
than holding a non-pegged coin: if the market cap of Ampleforth declines, users’
balances and outstanding payments will decline proportionally.

A different algorithmic approach is employed by Saga. Although Saga does
not peg the value of its coin, it uses an algorithmic path-independent market
maker inspired by Bancor [35] to provide liquidity and to dampen sudden price
fluctuations. The market maker sets the price and bid ask spread for Saga based
on how much collateral it has in its reserve. For example, when Saga is just
starting out and its reserve is small, the price will be set at 1 SDR, and the
market maker will sell a Saga for 1.0015 SDR and buy for 0.9985 SDR. This
makes it so that users should not sell Saga on secondary markets for less than
0.9985 or buy for more than 1.0015 SDR, which limits how suddenly the price
can change. As the reserve grows and shrinks, the price and spread are gradually
adjusted in response. Like Ampleforth, Saga does not guarantee that the value
of Saga holdings will be stable over time. However, the market maker does guard
against sudden price movements, and thus provides short-term stability.

Leveraged loans Leveraged loans are a system of stablecoins which utilize
components from all the above classes. Dai [47] is the most successful example of
such a system. Users lock up collateral, such as Ethereum and other cryptoassets,
in collateralized debt positions (CDPs). They can then mint Dai, a stablecoin
pegged to $1, up to 2/3 the value of the collateral in the CDP. Users can then
unlock their collateral by paying back the borrowed Dai, plus a stability fee that
accrues over time. Dai is destroyed once it is paid back.

If the value of the collateral in a CDP drops below 1.5x the Dai borrowed, the
debt position is automatically liquidated, and the collateral is used to purchase



A Classification Framework for Stablecoin Designs 11

the amount of Dai borrowed against it. Any remaining collateral, minus a liqui-
dation fee, is returned to the original CDP owner. If the value of the collateral
depreciates quickly and drops below the value of the Dai borrowed, a secondary
coin is minted to cover the difference. Currently, the secondary coin is PETH,
but eventually it will be transitioned to MKR. Since MKR is the governance
token, and MKR holders are diluted when CDPs are underwater, there is an
incentive for the holders of the governance token to set parameters such that
users are not defaulting on their loans. However, we note that the probability of
the value of the collateral declining to less than the Dai borrowed is low since
the price of the collateral would have to suddenly drop by over 33%.

Users are incentivized to buy Dai and unlock their collateral when the price
of Dai decreases, because a decrease in the price of Dai makes it cheaper for
them to unlock their collateral. This contracts the supply and restores the peg.
If Dai continues to trade at a price lower than its intended peg, MKR holders
can vote to raise the stability fee charged to CDP holders. This serves as further
incentive for CDP holders to liquidate their positions and contract supply.

Dai received a lot of attention in March 2019 for consistently trading around
$0.98 instead of $1 as it was supposed to. Since then, it underwent a series
of stability fee increases, some of which quixotically lowered the price of Dai
instead of raising it as intended. Despite this issue and Ethereum’s price decrease
by ∟ 90% since Dai launched, Dai has managed to remain within ∟ 2% of its
pegged value.

0.5

1.0

500

1000

2018−01 2018−07 2019−01 2019−07
Date

D
ai

 P
ric

e 
(U

S
D

)

E
thereum

 P
rice (U

S
D

)

Dai

Ethereum

Fig. 3. DAI remains relatively price stable despite decline in ETH price.

Miscellaneous There are a few other designs that do not neatly fit into any of
the above categories. For example, Steem [63] props up the price of its stablecoin,
Steem Dollars, by paying interest on Steem Dollars. However, since they don’t



12 Amani Moin, Emin Gün Sirer, and Kevin Sekniqi

set negative interest rates, this mechanism may not work if the price of Steem
is too high and the interest rate is already low. Consequently, Steem Dollars
traded for more than its $1 peg for months despite an interest rate of 0%.

Another design is employed by NuBits (now defunct), a stablecoin which is
minted when holders of a secondary coin (NuShares) vote to create more. Users
are also paid interest if they temporarily remove their NuBits from circulation.
This project is no longer in operation, possibly due to voting on supply changes
being a slow process, thus forcing adjustments in price to lag by several days
or more. Additionally, if holders of NuShares also hold NuBits, they may be
reluctant to dilute the value of NuBits by printing more.

Kowala [4] keeps the price stable by adjusting its mining rewards. When the
price of the stablecoin is too high, rewards increase to dilute the supply; when
the price of the stablecoin is too low, transaction fees are burned to contract the
supply. Unfortunately, a decline in the price of the stablecoin might be correlated
with fewer transactions occurring, since a break from the peg would diminish
users’ confidence in the stablecoin. Since price adjustments are effected through
mining and transactions, recovering from a decrease in price would take a long
time. Also, since mining rewards decrease during contractionary periods, miners
have less incentive to provide se";"""date"",""2019-10-23T00:44:16Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2019-10-23T00:44:16Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016) kpathsea version 6.2.2""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2019-10-23T00:44:16Z""
""created"",""2019-10-23T00:44:16Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-10-23T00:44:16Z""
""resourceName"",""1910.10098""
""Author"",""""
""producer"",""pdfTeX-1.40.17""
""pdf:docinfo:producer"",""pdfTeX-1.40.17""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2019-10-23T00:44:16Z""
""Last-Modified"",""2019-10-23T00:44:16Z""
""dcterms:modified"",""2019-10-23T00:44:16Z""
""title"",""""
""Last-Save-Date"",""2019-10-23T00:44:16Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2019-10-23T00:44:16Z""
""meta:save-date"",""2019-10-23T00:44:16Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016) kpathsea version 6.2.2""
""Content-Length"",""555057""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""24""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""1995"",""2319"",""1496"",""2759"",""1706"",""2526"",""2795"",""2771"",""2880"",""2787"",""1765"",""2763"",""2891"",""2592"",""2622"",""2352"",""2478"",""2615"",""1778"",""441"",""944"",""1397"",""1524"",""1403""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-10-23T00:44:16Z""
";https://scholar.google.com/scholar?start=480&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094658-1153;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Quisquis: A new design for anonymous cryptocurrencies;P Fauzi, S Meiklejohn, R Mercer, C Orlandi ; International Conference on …, 2019  Springer;;"… is not sufficiently powerful to prevent honest transactions from being added to the blockchain

or to add … Intuitively, an anonymous cryptocurrency should provide anonymity for both the sender

and the recipient … sk}_i,\mathsf {bl}_{i})\) being stored in memory available to the oracle …";Cité 44 fois;Les 4 versions;[PDF] smeiklej.com;https://smeiklej.com/files/asiacrypt19.pdf;"
Quisquis: A New Design for Anonymous Cryptocurrencies

Prastudy Fauzi1, Sarah Meiklejohn2, Rebekah Mercer3, and Claudio Orlandi4

1Simula UiB, Bergen, Norway
2University College London, UK

3O(1) Labs, USA
4Department of Computer Science, DIGIT, Aarhus University, Denmark

Abstract

Despite their usage of pseudonyms rather than persistent identifiers, most existing cryptocurrencies
do not provide users with any meaningful levels of privacy. This has prompted the creation of privacy-
enhanced cryptocurrencies such as Monero and Zcash, which are specifically designed to counteract the
tracking analysis possible in currencies like Bitcoin. These cryptocurrencies, however, also suffer from
some drawbacks: in both Monero and Zcash, the set of potential unspent coins is always growing, which
means users cannot store a concise representation of the blockchain. Additionally, Zcash requires a
common reference string and the fact that addresses are reused multiple times in Monero has led to
attacks to its anonymity.

In this paper we propose a new design for anonymous cryptocurrencies, Quisquis, that achieves
provably secure notions of anonymity. Quisquis stores a relatively small amount of data, does not require
trusted setup, and in Quisquis each address appears on the blockchain at most twice: once when it is
generated as output of a transaction, and once when it is spent as input to a transaction. Our result
is achieved by combining a DDH-based tool (that we call updatable keys) with efficient zero-knowledge
arguments.

1



Contents
1 Introduction 1

2 Cryptographic Primitives 2
2.1 Notation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2.2 Zero-knowledge arguments of knowledge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2.3 Commitments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

3 Updatable Public Keys 3
3.1 Security definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.2 UPKs from DDH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

4 Threat Model 5
4.1 Updatable accounts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.2 The cryptocurrency setting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.3 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

5 Our Quisquis Construction 8
5.1 Overview and intuition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.2 Transactions in Quisquis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.3 Proofs of security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

6 Instantiating the Zero-knowledge Proof 13
6.1 The auxiliary functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
6.2 The proof system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

7 Performance 17

8 Related Work and Comparisons 18
8.1 Tumblers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
8.2 Zcash . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
8.3 Monero . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

9 Conclusions and Open Problems 20

A Proof of Lemma 2 23

B NIZK arguments for Trans 24
B.1 Implementing ÎŁivu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
B.2 Implementing ÎŁCom . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
B.3 Implementing ÎŁizero . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
B.4 Implementing ÎŁrange,sk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

C Full proof of Quisquis satisfying anonymity 26

D Full proof of Quisquis satisfying theft prevention 30

E Proof of security of the zero-knowledge protocol 32

2



1 Introduction
Bitcoin was introduced in 2008 [30], and at a high level it relies on the use of addresses, associated with
a public and private key pair, to keep track of who owns which coins. Users of the system can efficiently
create and operate many different addresses, which gives rise to a form of pseudo-anonymity. As is now
well known, however, Bitcoin and other cryptocurrencies relying on this level of pseudo-anonymity can, in
practice, have these addresses linked together and even linked back to their real-world identities with little
effort [33, 34, 3, 26, 37, 28].

Due to this, there has now been an extensive body of work aiming to provide privacy-enhanced solutions
for cryptocurrencies, although even some of these new solutions have also been subjected to empirical analyses
pointing out the extent to which they can be de-anonymized as well [29, 25, 27, 20, 19, 18, 40]. These solutions
typically fall into two main categories.

First, tumblers (also known as mixers or mixing services) act as opt-in overlays to existing cryptocur-
rencies such as Bitcoin [23, 36, 16] and Ethereum [24], and achieve enhanced privacy by allowing senders
to mix their coins with those of other senders. While these are effective and arguably have a high chance
of adoption due to their integration with existing cryptocurrencies, they also have some limitations. In
particular, they are generally either dependent on trusting a central mixer, which leaves users vulnerable to
attacks on availability, or they require significant coordination amongst the parties wishing to mix, which
leads to higher latency as users must wait for other people to mix with them.

Second, there are cryptocurrencies with privacy features built in at the protocol level. Of these, the ones
that have arguably achieved the most success are Dash [1], Monero [31], and Zcash [6]. Dash is derived
from a tumbler solution, Coinjoin [23], and thus inherits the properties discussed there. In Monero, senders
specify some number of addresses to “mix in” to their own transaction, and then use this list of public keys
to form a ring signature and hide which specific address was theirs. Observers of the blockchain thus learn
only that some unknown number of coins have moved from one of these input public keys. In Zcash, users
can put coins into a “shielded pool.” When they wish to spend these coins, they prove in zero-knowledge
that they have the right to spend some specific coins in the pool, without revealing which ones.

Between Monero and Zcash, there are already several differences. For example, because users in Monero
specify rings themselves, they achieve a form of plausible deniability : no one can tell if a user meant to
be involved in a given transaction, or if their address was simply used in a ring without their consent. In
Zcash, in contrast, every other user in a user’s anonymity set has no such deniability, as they at one point
intentionally put coins into the shielded pool.

One limitation central to both cryptocurrencies, however, is the information that peers in the network
are required to keep. In Bitcoin, the list of all addresses with a positive balance can be thought of as a set
of unspent transaction outputs (UTXOs). When a sender spends coins, their address ceases to be a UTXO,
so is replaced in the set with the address of their recipient. Full nodes can thus collapse the blockchain into
this UTXO set, and check for double spending simply by checking if a given input address is in the set or
not. In other words, it acts as a concise representation of the entire history of the blockchain. In October
2017, for example, there had been over 23 million Bitcoin transactions and the total size of the blockchain
was over 130 GB, but the size of the UTXO set was only 3 GB [12].

In Monero and Zcash, however, addresses can (essentially) never be removed from the UTXO set, as it
is never clear if an address has spent its contents or was simply used as part of the anonymity set in the
transaction of a different sender. The size of the UTXO set is thus monotonically increasing: with every
transaction, it can only grow and never shrink. This has a significant impact on full nodes, as they must
effectively store the entire blockchain without the option of the concise representation possible in Bitcoin.
Our Contributions We present Quisquis, a new design for anonymous cryptocurrencies that resolves the
limitations outlined above for existing solutions. In particular, users are able to form transactions on their
own, so do not need to wait for other interested users and incur the associated latency. They can also involve
the keys of other users without their permission, which gives the same degree of plausible deniability as
Monero. Finally, each transaction acts to replace all the input public keys in the UTXO set with all the
output public keys, thus allowing the UTXO set to behave in the same manner as in Bitcoin. Furthermore,

1



our transactions are relatively inexpensive to compute and verify, taking around 471ms to compute and 71ms
to verify for an anonymity set of size 16, with proofs of size approximately 13kB.

As a brief technical overview, Quisquis achieves anonymity using a primitive that we formalize in Section 3
called updatable public keys, which allows users to create updated public keys, indistinguishable from ones
that are freshly generated, without changing the underlying secret key. After formally defining our threat
model in Section 4, we present our full construction of Quisquis in Section 5. Roughly, senders take the keys
of other users, including their intended recipients, to form a list of public keys that act as the input to a
transaction. A sender can now “re-distribute their wealth” among these input keys, acting to move some of
their own coins to the recipient and keeping the (hidden) balances of the other members of the anonymity
set the same. To ensure anonymity, the output public keys are all updated, and all balances and amounts are
given only in committed form. Thus, by design, in Quisquis every address can only ever appear at most twice
on the blockchain: once when it is generated in the output of the transaction, and once when it is spent as
input to a different transaction. This greatly reduces (compared, e.g., to Monero) the ability of an attacker
to perform de-anonymization attacks based on how often a certain address participates in transactions.

To ensure integrity, the sender proves in zero-knowledge that they have correctly updated the keys
and have not taken money away from anyone except themselves. Crucially, because the witness for the
zero-knowledge proof is limited to this single transaction (as opposed to encompassing other parts of the
blockchain), we can use standard discrete-log-based techniques as opposed to the heavyweight zk-SNARKs
required in Zcash. This means that security can depend entirely on DDH, and no trusted setup is required (as
we use the random oracle model to make the proofs non-interactive and to generate other system parameters
and random values using “nothing up my sleeves” methods). As the design of Quisquis is modular, other
tradeoffs could be achieved as well: for instance, it could be possible to instantiate Quisquis with zk-SNARKs
as well, thus achieving even smaller transactions and faster verification at the cost of much slower transaction
generation and the stronger assumptions underlying zk-SNARKs.

To demonstrate the efficiency of Quisquis, we implement it and present performance benchmarks in
Section 7. We then provide a thorough comparison with existing solutions in Section 8 before concluding in
Section 9.

2 Cryptographic Primitives

2.1 Notation
Let logg h be the discrete log of h with respect to g. Define (a, b)c := (ac, bc) and (a, b) ¡ (c, d) := (ac, bd).
For vectors ~a and ~b, let ~a ◦~b be the Hadamard product of ~a and ~b; i.e., the vector ~c such that ci = aibi. We
use y ← A(x) to denote assigning to y the output of a deterministic algorithm A on input x, and y $← A(x)
if A is randomized; i.e., we sample a random r and then run y ← A(x; r). We use [A(x)] to denote the set
of values that have non-zero probability of being output by A on inputs x. We use r $← R for sampling an
element r uniformly at random from a set R. If ~y = (y1, . . . , yn) $← A(x) then we often denote yi by ~yi.

2.2 Zero-knowledge arguments of knowledge
Let R be a binary relation for instances x and witnesses w, and let L be its corresponding language; i.e.,
L = {x | ∃w : (x,w) ∈ R}. An interactive proof is a protocol where a prover P tries to convince a verifier
V , by an exchange of messages, that an instance x is in the language L. The set of messages exchanged is
known as a transcript, from which a verifier can either accept or reject the proof. The proof is public-coin
if an honest verifier generates his responses to P uniformly at random. An interactive proof is a special
honest-verifier zero-knowledge argument of knowledge if it satisfies the following properties:

• Perfect completeness: if x ∈ L, an honest P always convinces an honest V .

• Special honest-verifier zero-knowledge (SHVZK): there exists a simulator S that, given x ∈ L and an

2



honestly generated verifier’s challenge c, produces an accepting transcript which has the same (or indis-
tinguishably different) distribution as a transcript between honest P, V on input x.

• Argument of knowledge: if P convinces V of an instance x, there exists an extractor with oracle access to
P that runs in expected polynomial-time to extract the witness w.

A public-coin SHVZK argument of knowledge can be turned into a non-interactive zero knowledge (NIZK)
argument of knowledge using the Fiat-Shamir heuristic. Essentially, non-interactivity is achieved by replacing
the verifier’s random challenge with the output of a hash function, which in the security proof is modeled as
a random oracle.

2.3 Commitments
We use a commitment scheme Commit relative to a public key pk that, given a message m ∈ M and
randomness r ∈ R, computes com ← Commitpk(m; r). Our commitments must satisfy two properties:
first, they are computationally hiding, meaning for any two messages m0,m1, an adversary has negligible
advantage in distinguishing between Commitpk(m0;UR) and Commitpk(m1;UR), where UR is the uniform
distribution over the randomness space. Second, they are unconditionally binding, meaning even given the
sk relative to pk, a commitment cannot be opened to two different messages.

Beyond these two basic properties, we require two extra properties from our commitments. First, they
must be homomorphic in the sense that for some operation � it holds that Commitpk(m)�Commitpk(m

′) =
Commitpk(m + m′) (for appropriate randomness). Second, they must be key-anonymous, meaning that for
any honestly generated keys pk0, pk1 and adversarially chosen m, the tuple (m, pk0, pk1,Commitpk0(m)) is
indistinguishable from (m, pk0, pk1,Commitpk1(m)).

We can construct such commitments in a group (G, g, p) where the DDH problem is hard, by essentially
performing an ElGamal encryption in the exponent relative to public keys of the form pk = (gi, hi) (which
are what we use in our later constructions). In particular, Commitpk(v; r) returns com = (c, d) where c = gi

r

and d = gvhi
r. It is easy to verify that this commitment scheme is unconditionally binding, computationally

hiding, key-anonymous, and additively homomorphic.
Finally, we also use extended Pedersen commitments in the constructions of our zero-knowledge (ZK)

arguments; i.e., schemes that commit to a vector of values using a single group element.

3 Updatable Public Keys
This section introduces the notion of an updatable public key (UPK), in which public keys can be updated
in a public fashion, and such that they are indistinguishable from freshly generated keys. This idea has been
considered before in the context of several cryptographic primitives, such as signatures [14, 4] and public-key
encryption [39], but we wish to define it solely for keys, regardless of the primitive they are used to support.

We begin by defining security for UPKs. Our definitions of indistinguishability and unforgeability resem-
ble those that have already been used for Bitcoin stealth keys [24] and in the context of other cryptographic
primitives [4, 39, 22].

Indeed, we could continue to be inspired by stealth keys in our construction of a UPK scheme, but given
their reliance on hash functions this would render us unable to prove statements about the keys using discrete
log-based techniques, as we would like to do in our construction of Quisquis in Section 5. We thus present
instead a purely algebraic UPK scheme based on DDH, inspired by “incomparable public keys” [39].

3.1 Security definitions
An updatable public key system (UPK) is described by the following algorithms:

• params $← Setup(1κ) outputs the parameters of the scheme, including the public and secret key spaces
PK,SK. These are given implicitly as input to all other algorithms.

3



• (pk, sk) $← Gen(1κ) takes as input a security parameter κ and outputs a public key pk ∈ PK and a secret
key sk ∈ SK.

• ({pk′i}ni=1) $← Update({pki}ni=1) takes as input public keys (pk1, . . . , pkn) and outputs a new set of public
keys (pk′1, . . . , pk

′
n).

• 0/1← VerifyKP(pk, sk) takes as input pk ∈ PK and sk ∈ SK and checks whether or not (pk, sk) is a valid
key pair.

• 0/1 ← VerifyUpdate(pk′, pk, r) takes as input public keys pk′, pk, and randomness r and checks if pk′ was
output by Update(pk; r).

We require a UPK to satisfy the following properties.

Definition 1 (Correctness). A UPK satisfies perfect correctness if the following three properties hold for all
(pk, sk) ∈ [Gen(1κ)]: (1) the keys verify, meaning VerifyKP(pk, sk) = 1; (2) the update process can be verified,
meaning VerifyUpdate(Update(pk; r), pk, r) = 1 for all r ∈ R; and (3) the updated keys verify, meaning
VerifyKP(pk′, sk) = 1 for all pk′ ∈ [Update(pk)].

We next define indistinguishability, which says that an adversary cannot distinguish between a freshly
generated public key and an updated version of a public key it already knows.

Definition 2 (Indistinguishability). Consider the following experiment:

1. (pk∗, sk∗) $← Gen(1κ);

2. pk0
$← Update(pk∗);

3. (pk1, sk1) $← Gen(1κ).

A UPK satisfies indistinguishability if for any PPT adversary A:

|Pr[A(pk∗, pk0) = 1]− Pr[A(pk∗, pk1) = 1]| ≤ negl(κ).

Finally, we require that an adversary should not be able to learn the secret key of an updated public
key (unless it already knew the secret key for the original public key). This is formalized by saying that the
adversary cannot produce a public key for which it knows both the secret key and the randomness needed
to explain this public key as an update of an honestly generated public key.

Definition 3 (Unforgeability). A UPK satisfies unforgeability if for any PPT adversary A:

Pr[VerifyKP(pk′, sk′) = 1 ∧ VerifyUpdate(pk′, pk, r) = 1

| (pk, sk) $← Gen(1κ); (sk′, pk′, r) $← A(pk)] ≤ negl(κ).

3.2 UPKs from DDH
We present a construction of UPK based over a prime-order group (G, g, p) where the DDH assumption is
believed to hold. Thus, our Setup outputs only publicly verifiable parameters, and does not need to be run
by a trusted party. The rest of the algorithms are as follows:

• Gen(1κ): Sample r, sk $← Fp and output pk = (gr, gr·sk).

• Update({pki}ni=1): Parse pki = (gi, hi). Sample r $← Fp and compute pk′i = pkri = (gri , h
r
i ) for all i.

• VerifyKP(pk, sk): Parse pk = (g′, h′) and output (g′)sk
?
= h′.

• VerifyUpdate(pk′, pk, r): Output Update(pk; r)
?
= pk′.

4



Lemma 1. The scheme above is a UPK satisfying Definitions 1 - 3 if the DDH assumption holds in (G, g, p).

Proof. Correctness is straightforward to verify. To prove indistinguishability, our reduction receives a DDH
challenge chl = (g, gx, gy, gz), samples a value r $← Fp, and defines pk∗ = (gr, gxr) and pk′ = (gyr, gzr).
It then invokes the indistinguishability adversary A on input (pk∗, pk′). If chl is a DDH tuple then pk′

is distributed identically to pk0, and if chl is not a DDH tuple then pk′ is distributed identically to pk1.
Therefore, our reduction has the same (non-negligible) advantage in the DDH game as the A has in the
indistinguishability game.

To prove unforgeability, our reduction receives a DL challenge chl = (g, h), picks a random t $← Fp, and
sets (g0, h0) = (gt, ht). The reduction now runs (s, (g1, h1), r) $← A(g0, h0), and outputs s. The input to the
adversary in the reduction is distributed identically as in the definition of security. The winning condition of
the security definition requires that h1 = gs1 and (g1, h1) = (gr0, h

r
0) = (grt, hrt) thus implying that gsrt = hrt

or equivalently that h = gs, meaning s is a valid solution to the DL oracle.

4 Threat Model
In this section, we present our model for cryptocurrency transactions, in which we view a transaction not
as just transferring value from a sender to a recipient but as participants “re-distributing wealth” amongst
themselves. Before presenting this model in Section 4.2, we first present the notion of an updatable account
in Section 4.1, which is an extension of updatable public keys that associates them with a (hidden) balance;
this is mainly done as a way to simplify notation in future sections. We then present the relevant notions of
security in Section 4.3, focusing on anonymity (meaning no one can identify the “true” sender and recipient
within the set of participants in a transaction) and theft prevention (meaning no one can steal the coins of
other people or otherwise inflate their own wealth).

4.1 Updatable accounts
To represent an account in a cryptocurrency, we use pairs acct = (pk, com) of public keys, which act as the
pseudonym for a user, and commitments, which represent the balance associated with that public key.

In more detail, each account carries a balance bl ∈ V, where V ⊂M; i.e., the domain of values is a subset
of the messages that can be committed to using Commit. To create a new account with initial balance bl ∈ V,
one can run (acct, sk) $← GenAcct(1κ, bl), which internally runs (pk, sk) $← Gen(1κ) and com $← Commitpk(bl),
sets acct = (pk, com), and returns (acct, sk).

To verify that an account has a certain balance, it is necessary to be able to open a commitment
using the secret key corresponding to pk. This also allows the owner of sk to open a commitment or
prove statements about the committed message even without knowing the randomness used. We use
the notation VerifyCom(pk, com, sk,m), and require the commitment to be binding also with respect to
this function; i.e., that no PPT adversary can output (pk, com, sk,m, sk′,m′) with m 6= m′ but such
that VerifyCom(pk, com, sk,m) = VerifyCom(pk, com, sk′,m′) = 1. With this algorithm in place, one can
run 0/1 ← VerifyAcct(acct, (sk, bl)), which parses acct = (pk, com) and outputs 1 if VerifyCom(pk, com,
(sk, bl)) = 1 and bl ∈ V and 0 otherwise.

For an account acct = (pk, com), observe that the output of VerifyAcct is agnostic to updates of the public
key; i.e.,

VerifyAcct((pk, com), (sk, bl)) = VerifyAcct((Update(pk), com), (sk, bl)).

Additionally, VerifyAcct is agnostic to re-randomizations of the commitment; i.e., VerifyAcct((pk, com), (sk, bl)) =
VerifyAcct((pk, comďż˝ Commitpk(0; r)), (sk, bl)).

Thanks to these observations, we are able to “update” accounts using the following notation:

• {acct′i}ni=1
$← UpdateAcct({accti, vi}ni=1; r1, r2) takes as input a set of accounts accti = (pki, comi) and val-

ues vi such that |vi| ∈ V, and outputs a new set of accounts (acct′1, . . . , acct
′
n) where acct′i $← (Update(pk; r1),

comďż˝ Commitpk(vi; r2)).

5



• 0/1← VerifyUpdateAcct({acct′i, accti, vi}ni=1; r1, r2) outputs 1 if {acct′i}ni=1 = UpdateAcct({accti, vi}ni=1; r1, r2)
and |vi| ∈ V, and 0 otherwise.

4.2 The cryptocurrency setting
Modeling the security of a cryptocurrency is a complex problem, as there are many different actors operating
at different layers of the protocol: a user wishing to send some coins creates a transaction, which is then
broadcast to their peers in a peer-to-peer network. Those peers in turn perform some cryptographic validation
of the transaction, and if satisfied broadcast it to their peers. Eventually, it reaches a miner or validator,
who engages in some form of consensus protocol to confirm the transaction into the blockchain.

For the sake of simplicity, we focus solely on the transaction layer of a cryptocurrency, and assume
network-level or consensus-level attacks are out of scope; i.e., we assume that the system is free from eclipse
attacks [17] or other de-anonymization attacks that depend on network-level information (such as IP ad-
dresses) and that an adversary is not sufficiently powerful to prevent honest transactions from being added
to the blockchain or to add malicious transactions of their own.

Rather than use the traditional model of having a sender, in possession of some secret key and a coin,
send this coin to a recipient, we instead consider a set of participants who want to redistribute wealth amongst
themselves. This means we now model a transaction as taking place amongst a set of participants P who act
as both the senders and the recipients in the transaction, and who each come in with some initial balance
bl0,i and end with some balance bl1,i.

This still captures the traditional model of keeping senders and recipients separate, because for a sender
S sending one coin to a recipient R we can use P = (pkS , pkR), bl0 = (1, 0), and bl1 = (0, 1). The natural
question, however, is who is required to authorize this transaction; for efficiency reasons we do not want
every participant to have to do so, but to ensure that parties cannot simply steal each others’ money we
do need permission on behalf of the “true” senders. The simple way to provide both these properties is to
require authorization only on behalf of the public keys whose associated balance has gone down; i.e., for
every pki ∈ P such that bl1,i − bl0,i < 0.

Again, this model fully captures the traditional model of senders and recipients, but crucially makes it
easier to reason about cryptocurrencies designed to provide anonymity. More formally, a transaction layer
for cryptocurrencies consists of (Setup,Trans,Verify), as defined below.

The setup algorithm state $← Setup(1κ, ~bl) generates the initial state of the system. The vector ~bl
represents the initial balance of the accounts in the system and it must be such that bli ∈ V and

∑
i bli ∈ V.

We assume that Setup runs (accti, ski) $← GenAcct(1κ, bli) at some point, and that the state contains a set
UTXO consisting of all accounts accti. All other algorithms take as input the (current) state even when
omitted, and the state is updated in ways other than through these algorithms (e.g., by miners producing
blocks at the network layer).

To create a transaction, a sender in posession of a secret key sk runs tx← Trans(sk,P, A,~v).1 The vector
of values ~v ∈ V represents the desired change in balance for each participant, meaning they should end up
with bl1,i = bl0,i + vi (where bl0,i is their initial balance according to state). In creating a transaction, the
sender may want to achieve some degree of anonymity, meaning they want to hide the link between their
accounts and those of the recipient. To this end, we introduce an anonymity set A, which consists of other
accounts used to hide information about the sender. It is important that these accounts are “eligible” in
some way (where this depends on the concrete system, but can mean for example that they have not yet
spent their contents). If A is not explicitly specified, it is picked at random from the set of eligible accounts.
We denote by tx[inputs] = P ∪A the input accounts in a transaction, and by tx[outputs] the output accounts.

Finally, 0/state← Verify(state, tx) checks if a transaction is valid given the current state. If so, it outputs
an updated state, and if not it outputs 0.

We say a state is valid if it is output by Setup or if it was the output of Verify(state′, tx) for a valid state′ and
a transaction tx output by Trans. We say a transaction layer preserves value if for any valid state′ 6= ⊥ derived

1For simplicity we consider a single sender but the notation can easily be generalized to allow for arbitrarily many.

6



from a valid state, ValueOf(state.UTXO) = ValueOf(state′.UTXO), where ValueOf computes the number of
coins associated with the UTXO set induced by a state.

4.3 Security
Intuitively, an anonymous cryptocurrency should provide anonymity for both the sender and the recipient,
meaning that even they cannot identify which accounts belong to whom. From an integrity perspective, it
is also important to guarantee theft prevention, meaning an adversary can transfer value only from accounts
for which it knows the secret key (and thereofore the adversary cannot reduce the balance of the honest
parties either).

Regardless of the goal, the basic outline of our security experiment is the same, in order to capture
the different ways an adversary can interact with honest participants in the system. For example, the
adversary can instruct honest participants to engage in transactions, or form arbitrary (i.e., fully adversarial)
transactions itself, as long as they are valid.

Intuitively, the adversary begins by specifying the initial balances ~bl of all participants in the protocol.
We continue this full control by allowing the adversary to direct honest parties to make specific transactions
(via transact queries), and to inject fully malicious transactions in the system (via verify queries). It
can also learn the secret key for any account in the system (via disclose queries), although here we must
be careful to prevent “trivial” attacks resulting from these disclosures in challenge queries (in which the
adversary specifies two different senders, recipients, and values, and tries to guess between transactions
involving them).

These trivial attacks include: (1) the adversary controls the secret key of one or both of the senders; (2)
the adversary controls the secret key of a recipient, and (3) the adversary specified a sender who does not
have enough funds to complete the specified amount (meaning the output of Trans is ⊥ in this case but not
the other). Formally, our game is defined as follows:

1. b $← {0, 1};

2. ~bl $← A(1κ);

3. state $← Setup(1κ, ~bl);

4. b′ $← AO(·)(state).

Part of Setup involves running (accti, ski) $← Gen(1κ, bli), and we assume that this results in the values
(i, accti, ski, bli) being stored in memory available to the oracle.

For several of the oracle queries, there is some bookkeeping required to update the keys and balances
associated with these records. We define this bookkeeping subroutine with respect to a transaction tx and two
sets honest and corrupt as follows: For every acctj ∈ tx[outputs] identify the corresponding accti ∈ tx[inputs]
such that skj = ski. For every such j, create a new record of the form (j, acctj , ski, bli + v′i), where v′i is
either (1) vi if i ∈ P or (2) 0 if i ∈ A. Then, reset the value for every accti ∈ tx[inputs]; i.e., save the record
(i, accti, ski, 0). Finally, for every pair (i, j) as above: if i ∈ honest add j to honest, else add j to corrupt.

Initialize honest to be the set of all indices i in memory, and corrupt to be the empty set. The oracle O(¡)
allows the following queries:

• (disclose, i): If (i, accti, ski, bli) was stored, call J the set of all j such that there is a record (j, acctj , skj , blj)
with ski = skj . Remove i and J from honest, add them to corrupt, and return (ski, bli, J, {blj}j∈J) to the
adversary.

• (transact, i,P, A,~v): If (i, accti, ski, bli) was not stored return ⊥. Otherwise run tx $← Trans(ski,P, A,~v),
and state′ ← Verify(state, tx). If state′ 6= ⊥ update state = state′, run the bookkeeping for tx, and return
tx.

• (verify, tx): run state′ ← Verify(state, tx). If state′ 6= ⊥ update state = state′, run the bookkeeping for tx,
and return ";"""date"",""2019-09-16T18:06:52Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2019-09-16T18:06:52Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.19 (TeX Live 2018) kpathsea version 6.3.0""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2019-09-16T18:06:52Z""
""created"",""2019-09-16T18:06:52Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-09-16T18:06:52Z""
""resourceName"",""asiacrypt19.pdf""
""Author"",""""
""producer"",""pdfTeX-1.40.19""
""pdf:docinfo:producer"",""pdfTeX-1.40.19""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""9"",""4"",""20"",""16"",""11"",""18"",""3"",""3"",""21"",""7"",""1"",""39"",""53"",""66"",""78"",""17"",""0"",""0"",""0"",""0"",""0"",""22"",""35"",""18"",""8"",""35"",""24"",""23"",""13"",""32"",""38"",""27"",""2""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2019-09-16T18:06:52Z""
""Last-Modified"",""2019-09-16T18:06:52Z""
""dcterms:modified"",""2019-09-16T18:06:52Z""
""title"",""""
""Last-Save-Date"",""2019-09-16T18:06:52Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2019-09-16T18:06:52Z""
""meta:save-date"",""2019-09-16T18:06:52Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.19 (TeX Live 2018) kpathsea version 6.3.0""
""Content-Length"",""764237""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""36""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""1302"",""1640"",""4117"",""3505"",""3198"",""2088"",""3353"",""3861"",""3044"",""3457"",""3432"",""2863"",""3561"",""3625"",""3358"",""1803"",""3073"",""729"",""3077"",""2948"",""3706"",""3564"",""2758"",""2709"",""1969"",""1786"",""1261"",""1685"",""3591"",""2589"",""2524"",""3089"",""3466"",""2260"",""2231"",""777""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-09-16T18:06:52Z""
";https://scholar.google.com/scholar?start=970&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094579-814;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;The Tokenization of assets: using blockchains for equity crowdfunding;J Roth, F Schär, A Schöpfer ; Available at SSRN 3443382, 2019  papers.ssrn.com;;"… 14 Electronic copy available at: https://ssrn.com/abstract=3443382 Page 15. eral

approach of digital identities, oracles (providers of real-world data on the Blockchain),

decentralized exchanges or the use of tokens as collateral for loans …";Cité 12 fois;Les 3 versions;[PDF] researchgate.net;https://www.researchgate.net/profile/Fabian_Schaer2/publication/335927848_The_Tokenization_of_Assets_Using_Blockchains_for_Equity_Crowdfunding/links/5d8f1e2fa6fdcc2554a11588/The-Tokenization-of-Assets-Using-Blockchains-for-Equity-Crowdfunding.pdf;;;https://scholar.google.com/scholar?start=630&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094574-799;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Multi-Metall-Zertifizierung in der globalen Wertschöpfungskette mittels Blockchain-Technologie;R Bosch, R Bärligea, C Gagiu, K Baumann… ; Herausforderungen für …, 2019  Springer;;"Page 1. Multi-Metall-Zertifizierung in der globalen Wertschöpfungskette mittels Blockchain-

Technologie Robert Bosch, Ralph Bärligea, Cristina Gagiu, Kai Baumann und Florian Anderhuber …

250 2 Eigenschaften, Chancen und Anwendung einer Blockchain ..... 251 …";Autres articles;;null;;;;https://scholar.google.com/scholar?start=610&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094534-624;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[HTML][HTML] Mwpow: Multiple winners proof of work protocol, a decentralisation strengthened fast-confirm blockchain protocol;Y Xu, Y Huang ; Security and Communication Networks, 2019  hindawi.com;United Kingdom;"… On the one hand, the decentralisation and security of blockchain are in jeopardy. Permitless

blockchain usually uses cryptocurrency to reward its participants to encourage participation;

however, the less competitive nodes are expecting less or zero rewards …";Cité 3 fois;Les 8 versions;[HTML] hindawi.com;https://www.hindawi.com/journals/scn/2019/3674274/;"[image: logo]
	Journals
	Publish with us
	Publishing partnerships
	About us
	Blog




Security and Communication Networks
+Journal Menu
[image:  ]PDF[image:  ] 
    
     Icons/Arrow Right White
     Created with Sketch.
     
         
    
     
         
             
                 
                     
                         
                             
                                 
                            
                             
                             
                                 
                            
                        
                    
                
            
        
    



Journal overview
For authorsFor reviewersFor editorsTable of ContentsSpecial Issues
[image:  ]         

Submit






Security and Communication Networks / 2019 / Article
Article SectionsOn this page
AbstractIntroductionRelated WorkConclusionsData AvailabilityConflicts of InterestAcknowledgmentsReferencesCopyright


Special IssueComputing Infrastructure and Complex Algorithms for Information Security in Communication Networks
View this Special Issue

Research Article | Open Access
Volume 2019 |Article ID 3674274 | https://doi.org/10.1155/2019/3674274
Yibin Xu, Yangyu Huang, ""MWPoW: Multiple Winners Proof of Work Protocol, a Decentralisation Strengthened Fast-Confirm Blockchain Protocol"", Security and Communication Networks, vol. 2019, Article ID 3674274, 13   pages, 2019. https://doi.org/10.1155/2019/3674274

Show citation
MWPoW: Multiple Winners Proof of Work Protocol, a Decentralisation Strengthened Fast-Confirm Blockchain Protocol


Yibin Xu[image:  ]   .cls-1{fill:#a6ce39;}.cls-2{fill:#fff;}.cls-3{fill:none;} orchid     

1 and Yangyu Huang[image:  ]   .cls-1{fill:#a6ce39;}.cls-2{fill:#fff;}.cls-3{fill:none;} orchid     

21School of Computer Science and Informatics, Cardiff University, Cardiff, CF24 3AA, UK
2School of Electronic Engineering and Automation, Guilin University of Electronic Technology, Guilin 541004, China

Show more
Academic Editor: Veljko Milutinovic
Received11 Jul 2019
Accepted08 Oct 2019
Published18 Nov 2019


Abstract
Blockchain mining should not be a game among power oligarchs. In this paper, we present the Multiple Winners Proof of Work Protocol (MWPoW), a mining-pool-like decentralised blockchain consensus protocol. MWPoW enables disadvantaged nodes which post only a small amount of calculation resource in the mining game to create blocks together and compete with power oligarchs without centralised representatives. A precise Support Rate of blocks can be determined through the mining process; the mechanism of the mainchain determination is therefore changed and has become faster and more straightforward. A method that periodically adjusts the block size and the block interval is introduced into MWPoW, which increases the system flexibility in the changes of network conditions and data flow. Experiments suggest, without lifting calculation and bandwidth requirements, MWPoW is more attractive to disadvantaged nodes due to its mostly increased reward expectation for disadvantaged nodes. The transaction pending time is shortened chiefly, and either the block interval or the block size can be adapted amid the changes of overall network conditions.
1. Introduction
Bitcoin [1], Ethereum [2], and other blockchain systems take the research direction of acquiring a consistent view among mutually distrusting participants to public attention. Blockchain’s transparency and irreversibility make it a perfect mechanism for maintaining the integrity and public confidence in applications like crowd-funding and gambling, where trust is the essence. Blockchain also brings hope to change our financial system and other fields that are vulnerable to the catastrophe caused by a failure in a single central component. Blockchain achieved the named properties with the premise that more than half of the participated resources are always honest. Every decision in the blockchain is a decentralised consensus decision among the participants instead of a centralised order from the superior governor. A blockchain is entirely decentralised when it operates in a permitless mode where it opens the membership and sustains anonymous participants to join and leave the system freely. Nevertheless, there are problems with the design of permitless blockchain. With people seeking to extend the usage of permitless blockchain to various fields, they have found that the majority implemental barrier is the dilemma between the increment of throughput and the maintenance of decentralisation.
On the one hand, the decentralisation and security of blockchain are in jeopardy. Permitless blockchain usually uses cryptocurrency to reward its participants to encourage participation; however, the less competitive nodes are expecting less or zero rewards. In Bitcoin (Nakamoto blockchain), with a standard computer having a hash rate of , the computer has to mine for an average of 62,000 years to find a block [3]. The design that only the block creator receives remuneration in every iteration of the mining game has discouraged the disadvantaged nodes from participating in this tensed competition, causing a tendency to partly-centralisation. We see the same problem in Proof of Stake (PoS) [4] byzantine consensus protocol, the people with more tokens become oligarchs who are likely to win the game. The decentralisation is further damaged when nodes join in the mining pools for a higher reward expectation. A mining pool is a centralised node that gathers the resources from individual nodes, mine as one, and distribute the funding gained based on the resources individual nodes posted. The participated nodes generally have no sense of how their resources are used; thus, honest mining pool participants can also be an accomplice of byzantines. Merged mining [5] is an example of this, where the mining pool participants’ power can be used in multiple mining games of different blockchains without their acknowledgements. The same problem goes to DPoS, where the stakes of minorities are gathered by several prominent representatives, the system is partly centralised, and then the security concerns are aroused.
Blockchain needs to enable as many devices as possible to participate in maintaining the decentralisation. It must give disadvantaged devices enough time (block interval) to digest information, verify blocks, and reach a consensus with others. Every block interval consists of two subintervals: the time for creating a block and the time for broadcasting the block. The time allocation inside every block interval changes with the come and go of participants of diverse calculation ability and network situation. It is difficult to conclude a convincing reason for setting a specific block interval and whether a block interval adjustment improves the performance or damages the security. A previous research [6] shows that a significant propagation latency in blockchain network may cause miners to mine on dated blocks. If the block interval is too short, the impact of network advantage may surpass that of calculation advantage in the chance to win the mining game, causing a weakened security.
On the other hand, the throughput (transactions per second) of blockchain, in reality, is relatively low to power its potential applications. For the network latency and security concerns, the block size cannot be significant. If the block size is large, with the same block interval, the subinterval for creating a block is shorter compared to that with smaller block size. This setting may cause an unbalance of the time allocation between the two subintervals, further damaging the security of the blockchain.
Most blockchains [1, 4, 7] require three later block confirmations to confirm a transaction embedded to block. This rule brings a pending time of at least 30 minutes to accept the transaction in bitcoin [1], without counting the pending time before a block embeds this transaction. This rule also contributes to the low throughput problem because only the confirmed transactions can be used in further transactions. However, this rule is essential for the blockchain security. People only know if a branch of blocks is the longest one to their knowledge. They do not know the exact percentage of the overall calculation power that has agreed on that branch and if there is an unknown branch of blocks of more support. People must wait for a predefined time window to accept a block to the mainchain and prevent a wrong decision in a significant propagation latency. There are alternatives to this mainchain determine rule in protocols like Directed Acyclic Graph [8–10] which has uncertain transaction confirmation time and is more vulnerable to attacks. GHOST [11] shortens the time for mainchain determination by allowing people mine on the branch that has the most blocks instead of the highest branch. However, it still requires later block confirmations to accept a block finally. There is no clue of how much percentage of the overall calculation power in exact an attempt would take to overwrite the mainchain.
This problem also exists in other blockchain byzantine consensus protocols, e.g., Proof of Stake (PoS) [4] and Delegated Proof of Stake (DPoS) [7]. They take a long pending time to decide on a branch of blocks as the mainchain confidently. There are many byzantine consensus mechanisms in pre-blockchain eras; they often make security/performance trade-offs which make them no longer a trustworthy decentralised system. Byzantine consensus mechanisms such as those in [12–14] are specified working in a closed-membership setting, the participants are fixed, and they all know each other’s identities through authenticated third parties. These mechanisms are incredibly vulnerable to Sybil attacks [15], where the byzantine repeatedly creates different identities to acquire a significant influence on the system. More protocols such as those in [16–18] either scale poorly with the number of participants or are inefficient.
In this paper, we show Multiple Winners Proof of Work protocol (MWPoW), a consensus protocol that attempts to increase the scalability of blockchain while maintaining the decentralisation by (1) introducing a method to dynamically adjust the block interval and make it fit into the network situation, (2) changing the way of mainchain determination and shortening the transaction pending time, and (3) strengthening the decentralisation by increasing the chance for disadvantaged participants to receive remuneration.
In MWPoW, we encourage people to join in the blockchain directly by eliminating the reward-expectation gap between mining on the blockchain and mining in a mining pool. A block is not published by one miner but by a group of miners. Miners receive remuneration based on their contribution directly if they collectively mined a block. We improve the scalability of blockchain by shortening the time to accept a block finally: any node can calculate a precise Support Rate of a block without waiting later block confirmations. An exact percentage for time allocation in block interval can be derived, either the block size or the block interval can be dynamically adjusted safely and reasonably to fit into the data flow.
Compared to the previous MWPoW paper [19], this paper makes the following improvements; parts of the MWPoW are redesigned:(i)The mandatory grouping requirements are removed, and miners are not assigned into three predefined groups.(ii)The block Support Rate is systematically defined and analyzed.(iii)The branch choosing and the mainchain determination method are thoroughly redefined.(iv)The new approach to adjust block interval and block size is introduced.(v)The performance is compared with other fast-confirm protocols.
2. Multiple Winners Proof of Work Protocol
2.1. MWPoW Outline
2.1.1. Definition
(i)Calculation Power Claim. A miner’s calculation power is defined as the hash difficulty one can achieve in a fixed time window. Calculation Power Claim is the hash difficulty that a miner intends to reach in every round of the mining game:where  is the overall power claimed by registered participants, N is the number of registered participants in the network, and  is the Calculation Power Claim of registered participant N.(ii)New Join. New Join is a data set, which records the Calculation Power Claim of a participant and a wallet address of this participant (the wallet address is used for receiving remuneration). There is a Nonce field in New Join, which is used for adjusting the hash of New Join. For a New Join to be valid, the hash of this New Join must meet at least the Calculation Power Claim of this New Join. Table 1 shows the structure of New Join.(iii)Try Range. Try Range () is a number interval of the Nonce in block header:where N is the number of registered participants in the network. Miner  mines on .(iv)Acceptance Difficulty. The first block that reaches the Acceptance Difficulty in a round of mining should be placed in the mainchain. Acceptance Difficulty is adjusted based on how much time is consumed for the winner block to achieve the Acceptance Difficulty:where  is the Acceptance Difficulty at the block height X,  is the predefined block interval, and  is the time when block X is created.(v)Entrance Difficulty. A block is broadcasted to the network when this block reached Entrance Difficulty. Entrance Difficulty of a new round is adjusted base on how many blocks reached Entrance Difficulty in the previous round of the game:where  is the Entrance Difficulty at the block height X;  is the number of blocks reached Entrance Difficulty at block height ;  is the ideal number of , and we set .(vi)Share. Share is a container of Nonce when broadcasting. The Nonce inside a Share which is sent by a miner must make the hash of the block fulfill at least 25% of this miner’s Calculation Power Claim. Table 2 shows the structure of Share.(vii)Countable Share. If a miner has sent at least two valid Shares for a block, the difficulties of these Shares are counted toward the Support Rate of this block and the miner will be able to receive remuneration for announcing this block if this block wins the game later.(viii)Share Difficulty Cap. The maximum sum of difficulties of Countable Shares sent by a miner X in a round of game is  (its Calculation Power Claim). If it sends more, the sum is capped at .(ix)Support Rate. The Support Rate of a block is defined as the ratio between the sum of the difficulties of the Countable Shares for the branches stem from this block and the sum of difficulties of all Countable Shares of all the branches in the blockchain since the block height of this block:where  is the Support Rate of block X;  is the latest block on top of the blockchain branch stem from block X; k is the number of all the branches;  refers to the latest block on top of the specific branch;  is the total difficulty of the Countable Shares for block i. Figure 1 shows an example where red and blue dotted boxes include the branches stem from block 1 and block 2, respectively. The Support Rate of block 1 is 28.57% while which of block 2 is 71.43%.(x)Reward. The reward is given as follows:where  is the set of miners who contributed the Countable Shares for announcing block X;  is the overall reward assigned from the system for the block at the block height X; Shares of block X are embedded in block ;  is the total difficulty of the Countable Shares embedded in block ;  is the difficulty of the Countable Shares miner i contributed to; and  is the amount of remuneration given to miner i as a Coinbase transaction in block .(xi)Valid Block. A miner determines a block as a valid one when the transactions, New Joins and Shares in this block are correct; the Shares and New Joins must be more than  previously known to the miner.(xii)Registered Power. The Registered Power of a block height is defined as the sum of all the new calculation power shown in the New Joins embedded in the block sat this block height plus the sum of all the remaining calculation power after expelling unqualified miners who failed to show 50% of their powers when announcing the preceding block. Figure 2 shows an example, where the New Joins of miner A and miner B are embedded in block 1, Miner A worked on block 2, and miner B worked on block 3 (that is why they are expelled from the other branch). The New Joins of miners C, D, E, F, G, H, I, J, K, and L show up on the network and should be embedded into a block at the block height X; block 2 does not include L, and block 3 does not include D; however, both blocks can be accepted as the discrepancy does not excel 10% of the contents in the network. But, when calculating the Registered Power, all the new participants as well as the remained miners should count.(xiii)Restriction for Branch Choosing. If a miner has sent two Shares for a block, this miner is not allowed to change branches in this round of the game. If a miner broadcasted two or more valid Shares for blocks of different branches at the same block height, the miner would be expelled from the game and its contribution will not be counted toward the Support Rate.(xiv)Statement Rate. , where , k is the set of miners who have sent two valid Shares for a block at the block height X and are not violating the restriction for branch choosing, and  is the Registered Power at the block height X.(xv)Noncommittal Power. If a miner has not yet sent two Shares for a block, its power is counted toward the Noncommittal Power. If a miner breaks the restriction for branch choosing, its Shares will be eliminated from the Support Rate of all blocks at this block height and will not be counted toward Noncommittal Power.(xvi)Block Size. The number of transaction allowances per block.
		

	Filed	Purpose	Bytes
	

	HashPrevBlock	A 256-bit hash of the latest block in the mainchain	32
	Intended_difficulty	The power (difficulty) which the miner intended to place into the mining game	4
	Wallet address	For receiving compensation	34
	Nonce	Hash tried (A 256-bit number starts from 0)	32
	





Table 1 
Structure of New Join.


		

	Filed	Purpose	Size (bytes)
	

	L_4_D_IH	Last 4 bytes of the block header hash of a block candidate	4
	Nonce	Hash tried (A 256-bit number)	32
	





Table 2 
Structure of Share.


[image: ]


Figure 1 
The Support Rate of block 1 and block 2.


[image: ]


Figure 2 
Explanation for Registered Power.


2.1.2. Game Overview
Miners need to claim the calculation power they intended to put into the mining game before participating the game. Each miner is given a unique  based on the calculation power it claimed. When a miner creates a block and finds a Nonce that fulfill Entrance Difficulty in its , it will broadcast the block as well as the Share. Then other miners will attempt to find a Nonce in their  to make this block fulfill the Acceptance Difficulty if they acknowledge this block as a valid one. Ideally, miners should announce a block collectively by doing PoW in their  in parallel. When a Share of a block is broadcasted and the Nonce in it made the block reached the Acceptance Difficulty, this block is announced. The first block that reaches Acceptance Difficulty is the winner block, and miners who contribute Shares to this block will divide the remuneration of mining. During the announcement, miners should send Shares which do not fulfill the Acceptance Difficulty but fulfill at least  of the power they claimed previously as the proof of contribution. A miner can only send up to four Shares to the network per round of the game. If more than one block is successfully announced in a round of game, miners should mine on top of the one first reached Acceptance Difficulty from their perspectives (miners may have different views due to the network delay). Assume that this winner block is the block X, the blocks at the next block height (block ) will embed Shares of block X. According to the Shares embedded, if a miner failed to find the Shares which together weighted more than  of the power it previously claimed, this miner will be expelled from the game (its  will be cancelled since BH ). The remuneration for the miners of block X is given at the block height BH  through the Coinbase transaction. All the valid miners of block X divide the reward based on the difficulty of Shares they sent. As every miner oversees different Try Ranges, it is easy to determine who should receive remuneration and what amount of remuneration.
2.1.3. Game Procedure
(i)Register power: A new miner creates and submits a New Join to the system.(ii)Get a Try Range: Miners whose New Joins are embedded into a block will be assigned with Try Ranges.(iii)Mining: The miners try to create a block and find a Nonce that fulfills Entrance Difficulty in their; if a block created by a miner has reached Entrance Difficulty and other miners approve this block as a Valid Block, they will try to find a Nonce that fulfills Acceptance Difficulty in their Try Ranges.(iv)Getting reward: If the miner submitted adequate number of valid Shares for the winner block, the amount of reward would be given at the next block height.(v)Rearrange Try Range and start over: After every round of the game, the invalid miners will be globally expelled (miners who failed to send Shares which stand for at least 50% of the power they claimed, their Try Ranges will be cancelled). Then, new miners are added, and the Try Ranges for all the valid miners be rearranged. After that, a new round of the game starts. Miners who submitted New Join before and were not expelled do not need to register power again to participate the new round of the game.
2.2. Block Simplification and Bandwidth Demand
Because New Joins and Shares are embedded to the block, the block size is increased tremendously. We use a block simplification algorithm Graphene [20] to simplify the block as to lower the bandwidth demand. The structure of MWPoW block is given in Figure 3. Graphene is a block simplification method which uses Bloom filter (BF) [21] and IBLT [22]. It can encode 2000 transactions into 2.6 kbytes, and the encoded blocks can be decoded by nodes using the previously received transactions.
[image: ]


Figure 3 
Block overlook.


Though the block is simplified, nodes still need to promptly hear all the New Joins, Shares, and transactions in the system to decode the simplified blocks. A New Join sized  while a Share sized . Figure 4 shows the amount of data needed for hearing New Joins and Shares with the different number of valid miners in the network. Every miner sends four Shares to the network per round of the game, and in every round of the game, 200 new miners are added into the network until there are 10000 miners.
[image: ]


Figure 4 
The amount of data for New Join and Shares VS different miner number.


Bitcoin nowadays has a steady number of around 8000 miners worldwide in the network. Let us assume MWPoW also has this user scale, then the minimum bandwidth for a node will be , where Interval is the predetermined block interval (in minutes). The minimum bandwidth with different block interval is shown in Figure 5. It only requires an additional  to function MWPoW with the Bitcoin setting (block interval of 10 minutes).
[image: ]


Figure 5 
The minimum bandwidth for New Join, Shares VS block interval.


2.3. Distributed Remuneration
According to the Shares embedded in the block, the remuneration will be given to the miners of the winner group directly through a Coinbase transaction. The amount of remuneration for miners is calculated based on the total reward amount of the last block height multiplied the sum of the miner’s valid Share proportions to the sum of all the Shares in winner group. Figure 6 shows an example of this, where the sum of the difficulty of the Shares sent by the Miner A and Miner B is 212 and 49, respectively, and the sum of the difficulty of all the valid Shares of the group is 1000. The total reward amount of the last block height is 100. Miner A and Miner B receive 21.2 coins and 4.9 coins, respectively. It should be noticed that if the difficulty of the valid Shares of a miner excelled the difficulty it claimed in the New Join, the system should use the difficulty in the New Join to calculate remuneration.
[image: ]


Figure 6 
Reward assignment.


2.4. Fast Confirmation
It is predefined that the miners should mine on top of the block which, to their knowledge, first reached the Acceptance Difficulty. However, a miner may shift to mine on top of another block if this miner is allowed to change branches (when the miner has not yet sent two Shares for a specific block), and there is another block of Acceptance Difficulty with more Support Rate.
A block is finally accepted when the following finally acceptance criteria are satisfied:(1)This block is inside the highest branch of the mainchain.(2)The Statement Rate of the latest block height is larger than (3)The calculation power that reflected by the difference between the Support Rate of this block and the Support Rate of the second largest block at the same block height is larger than  of the Registered Power of the latest block height.
Figure 7 shows an example of the branch choosing. In , final acceptance criteria (3) is not met so that we cannot yet determine which block is the final accepted one. In , where there are succession blocks of blocks A, B, and C, the Support Rate of blocks A, B, and C are changed. Blocks C and D are finally accepted because the differences of difficulty between this branch and other branches are larger than 25% of the latest Registered Power. Block C and the branch stems from it have Shares that altogether stand for 6110 difficulties while the second popular block—block B and its branch altogether have 3172 difficulties; the difference is 2938, that is, about 41% of the Registered Power is exceeded the final acceptance criteria.
[image: (a)]
(a)
[image: (b)]
(b)

[image: (a)]
(a)[image: (b)]
(b)


Figure 7 
Finally accept a block.


2.5. Adjustment of the Block Interval and Block Size
Let  be the timestamp for the time of creating block x,  is the timestamp that indicates the time when the creator of block x heard first out of the four Shares of block  from miners whose Calculation Power Claim together stand for at least  of the overall registered power at the block height ; both  and  are embedded in the block header of block x. The block interval is defined as , where S is the time for synchronization and M is the time for mining. Real time S and M can be derived from (1)  and (2) . If a desire ratio  is predefined, the block interval and block size can be adjusted accordingly.
2.5.1. Block Interval Adjustment
Block interval is adjusted as follows:where ,  and  is the setting value of the block interval between the block height x and the block height .
2.5.2. Block Size Adjustment
The block size is adjusted as follows:where  is the block size of the block height x.
In the experiment section, we will examine how block interval, block size, and acceptance difficulties change when the number of nodes and the bandwidth of nodes fluctuates.
3. Security Analysis
3.1. Restriction of Branch Choosing
If a miner has sent two valid Shares for a block at a block height, this miner is not allowed to change branches in this iteration. This rule sets a bottom line for speculators; if the rule is broken, their power is not considered Registered Power and they are expelled since the next round of the game.
3.2. Attack
Because the Support Rate of a block may be reduced when a miner breaks the restriction of branch choosing, this brings the room for the attack. Figure 8 shows an example of the attack, where the rectangles in red stand for the attacker’s power. In (a), block  is finally accepted because its Support Rate is more significant than Bob (the second largest) for more than  of the Registered Power and the Statement Rate is more significant than . The attacker has placed at least two Shares for . Otherwise, its Shares are not Countable Shares for . Because the maximum sum of difficulties of Shares one can contribute to a block height is its Calculation Power Claim (the difficulty is capped if one contributed more), it takes at least  the attacker’s Calculation Power Claim to make two valid Shares for  (otherwise the Shares are not countable); after that, we entered situation (b). As condition (b) violates the restriction of branch choosing, the attacker’s power is eliminated from both  and  and then (c) is reached, where  is the finally accepted block instead of .
[image: ]


Figure 8 
The attack simulation.


Let us assume block  reached final acceptance criteria and had a F Support Rate; at that time, block  had  Support Rate in the network. The attacker must have placed at least D amount of Registered Power into block ’s branch through at least two Shares submitted at the latest block height of ’s branches. Then, a similar D amount of power must be used to create two more valid Shares for another branch which does not stem from  to make the attacker’s contribution to  invalid.
The attacker must have claimed a power that is around two times of D when joining in the game because each Share stands for at least  of the power and the maximum difficulty of the sum of the attacker’s countable Shares is its power claim. For block  to reach acceptance criteria at first, D must be equal to or larger than  of the overall Registered Power (see (3) of Fast confirmation section). So, an attack costs  power (at least  of the overall Registered Power.)
4. Related Work and Contributions
In 2013, Sompolinsky and Zohar [11] proposed the GHOST protocol. GHOST handles more transactions per second than Nakamoto blockchain because it can determine the mainchain faster. Not only the earliest block at each round of the game is accepted, other blocks, e.g., orphaned blocks, which are found later could also be accepted. GHOST accelerates the mainchain determination by allowing block parallelism in the network; it prevents the computational power to scale up the network. Some ideas of MWPoW are similar to GHOST: Shares in MWPoW function like fork blocks in GHOST for mainchain determination except Shares are much smaller and generated faster. Also, every Share brings an explicit increase or decrease of the Support Rate for every pending block.
Eyal et al. [23] improved the transaction per second in their blockchain protocol named Bitcoin-NG. Bitcoin-NG brings more blocks within one round of mining game. Key blocks and macroblocks are two different block types in Bitcoin-NG. The key blocks carry no transactions; they are used for leader elections solely. In the meantime, the macroblocks are employed to deliver transactions proposed by the creator of the key block. The Share structure of MWPoW is also similar to macroblocks in Bitcoin-NG, with no transaction attached. We do not add transactions into the Share structure, because the macroblocks in Bitcoin-NG are linearly linked to each other. They are sent by the key block creator only so that it guarantees the transactions are not duplicated. However, the Share structure does not link with other, and Shares are used to determine the Support Rate and reward distribution, which features the macroblocks cannot provide.
Lightning blocks [24] proposed by Poon et al. uses an off-chain micropayment channel between two parties to improve the transactions per second in the Bitcoin network. Micropayment channel allows both parties to send large transactions in an instant between the parties after only a few transactions been included into the blockchain. However, as it is only an application running on top of Bitcoin, it still underlies Nakamoto blockchain regardless of its contribution to enhance the transaction throughput. It does not solve the core problem of the Nakamoto protocol.
Buterin et al. [25] explore another approach that aims to ease the scalability problem. This approach involves sampling and challenging techniques. In their model, participants are split into several subcommittees in the network to distribute computation and verification cost. Random sample verifier verifies the correctness of others’ updates and challenges some others’ verification results. However, some invalid updates would never be detected under this mechanism.
Regarding block size/block interval adjustment or a clear view of the time allocation for data synchronisation and mining, we did not find any previous research that addresses these issues.
Besides the contribution toward a shorter transaction pending time ";"""dc.publisher"",""Hindawi""
""og:image"",""https://images.hindawi.com/journals/scn/scn.banner.jpg""
""og:image:width"",""600""
""twitter:card"",""summary_large_image""
""citation_journal_title"",""Security and Communication Networks""
""language"",""en""
""og:description"",""Blockchain mining should not be a game among power oligarchs. In this paper, we present the Multiple Winners Proof of Work Protocol (MWPoW), a mining-pool-like decentralised blockchain consensus protocol. MWPoW enables disadvantaged nodes which post only a small amount of calculation resource in the mining game to create blocks together and compete with power oligarchs without centralised representatives. A precise Support Rate of blocks can be determined through the mining process; the mechanism of the mainchain determination is therefore changed and has become faster and more straightforward. A method that periodically adjusts the block size and the block interval is introduced into MWPoW, which increases the system flexibility in the changes of network conditions and data flow. Experiments suggest, without lifting calculation and bandwidth requirements, MWPoW is more attractive to disadvantaged nodes due to its mostly increased reward expectation for disadvantaged nodes. The transaction pending time is shortened chiefly, and either the block interval or the block size can be adapted amid the changes of overall network conditions.""
""prism.issn"",""1939-0114""
""citation_issn"",""1939-0114""
""dc:title"",""MWPoW: Multiple Winners Proof of Work Protocol, a Decentralisation Strengthened Fast-Confirm Blockchain Protocol""
""Content-Encoding"",""UTF-8""
""citation_pdf_url"",""https://downloads.hindawi.com/journals/scn/2019/3674274.pdf""
""robots"",""index""
""google-site-verification"",""AxEuDsL7vXGOxRe53-uFhOk2ODN0bbXMeuBy6Pfq4ww""
""citation_author"",""Xu, Yibin"",""Huang, Yangyu""
""dc.date"",""2019/11/18""
""prism.volume"",""2019""
""citation_doi"",""https://doi.org/10.1155/2019/3674274""
""prism.publicationName"",""Security and Communication Networks""
""dc.title"",""MWPoW: Multiple Winners Proof of Work Protocol, a Decentralisation Strengthened Fast-Confirm Blockchain Protocol""
""Author"",""Hindawi""
""citation_volume"",""2019""
""dc.language"",""en""
""Content-Language"",""en""
""authors"",""Yibin Xu | Yangyu Huang""
""citation_title"",""MWPoW: Multiple Winners Proof of Work Protocol, a Decentralisation Strengthened Fast-Confirm Blockchain Protocol""
""citation_year"",""2019""
""citation_publisher"",""Hindawi""
""dc.format"",""text/html""
""description"",""Blockchain mining should not be a game among power oligarchs. In this paper, we present the Multiple Winners Proof of Work Protocol (MWPoW), a mining-pool-like decentralised blockchain consensus protocol. MWPoW enables disadvantaged nodes which post only a small amount of calculation resource in the mining game to create blocks together and compete with power oligarchs without centralised representatives. A precise Support Rate of blocks can be determined through the mining process; the mechanism of the mainchain determination is therefore changed and has become faster and more straightforward. A method that periodically adjusts the block size and the block interval is introduced into MWPoW, which increases the system flexibility in the changes of network conditions and data flow. Experiments suggest, without lifting calculation and bandwidth requirements, MWPoW is more attractive to disadvantaged nodes due to its mostly increased reward expectation for disadvantaged nodes. The transaction pending time is shortened chiefly, and either the block interval or the block size can be adapted amid the changes of overall network conditions.""
""og:image:type"",""image/jpeg""
""citation_date"",""2019/11/18""
""title"",""MWPoW: Multiple Winners Proof of Work Protocol, a Decentralisation Strengthened Fast-Confirm Blockchain Protocol"",""MWPoW: Multiple Winners Proof of Work Protocol, a Decentralisation Strengthened Fast-Confirm Blockchain Protocol""
""twitter:image"",""https://images.hindawi.com/journals/scn/scn.banner.jpg""
""citation_online_date"",""2019/11/18""
""twitter:site"",""website""
""dc.type"",""Research Article""
""dc.source"",""Security and Communication Networks""
""dc.creator"",""Xu, Yibin"",""Huang, Yangyu""
""citation_fulltext_html_url"",""https://www.hindawi.com/journals/scn/2019/3674274/""
""prism.publicationDate"",""2019/11/18""
""Content-Length"",""619448""
""citation_xml_url"",""https://downloads.hindawi.com/journals/scn/2019/3674274.xml""
""Content-Type"",""text/html; charset=UTF-8""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""og:type"",""website""
""twitter:title"",""MWPoW: Multiple Winners Proof of Work Protocol, a Decentralisation Strengthened Fast-Confirm Blockchain Protocol""
""dc.description"",""Blockchain mining should not be a game among power oligarchs. In this paper, we present the Multiple Winners Proof of Work Protocol (MWPoW), a mining-pool-like decentralised blockchain consensus protocol. MWPoW enables disadvantaged nodes which post only a small amount of calculation resource in the mining game to create blocks together and compete with power oligarchs without centralised representatives. A precise Support Rate of blocks can be determined through the mining process; the mechanism of the mainchain determination is therefore changed and has become faster and more straightforward. A method that periodically adjusts the block size and the block interval is introduced into MWPoW, which increases the system flexibility in the changes of network conditions and data flow. Experiments suggest, without lifting calculation and bandwidth requirements, MWPoW is more attractive to disadvantaged nodes due to its mostly increased reward expectation for disadvantaged nodes. The transaction pending time is shortened chiefly, and either the block interval or the block size can be adapted amid the changes of overall network conditions.""
""og:title"",""MWPoW: Multiple Winners Proof of Work Protocol, a Decentralisation Strengthened Fast-Confirm Blockchain Protocol""
""citation_abstract"",""Blockchain mining should not be a game among power oligarchs. In this paper, we present the Multiple Winners Proof of Work Protocol (MWPoW), a mining-pool-like decentralised blockchain consensus protocol. MWPoW enables disadvantaged nodes which post only a small amount of calculation resource in the mining game to create blocks together and compete with power oligarchs without centralised representatives. A precise Support Rate of blocks can be determined through the mining process; the mechanism of the mainchain determination is therefore changed and has become faster and more straightforward. A method that periodically adjusts the block size and the block interval is introduced into MWPoW, which increases the system flexibility in the changes of network conditions and data flow. Experiments suggest, without lifting calculation and bandwidth requirements, MWPoW is more attractive to disadvantaged nodes due to its mostly increased reward expectation for disadvantaged nodes. The transaction pending time is shortened chiefly, and either the block interval or the block size can be adapted amid the changes of overall network conditions.""
""og:image:height"",""315""
""prism.doi"",""https://doi.org/10.1155/2019/3674274""
""dcterms.issued"",""2019/11/18""
""viewport"",""width=device-width, initial-scale=1""
""twitter:description"",""Blockchain mining should not be a game among power oligarchs. In this paper, we present the Multiple Winners Proof of Work Protocol (MWPoW), a mining-pool-like decentralised blockchain consensus protocol. MWPoW enables disadvantaged nodes which post only a small amount of calculation resource in the mining game to create blocks together and compete with power oligarchs without centralised representatives. A precise Support Rate of blocks can be determined through the mining process; the mechanism of the mainchain determination is therefore changed and has become faster and more straightforward. A method that periodically adjusts the block size and the block interval is introduced into MWPoW, which increases the system flexibility in the changes of network conditions and data flow. Experiments suggest, without lifting calculation and bandwidth requirements, MWPoW is more attractive to disadvantaged nodes due to its mostly increased reward expectation for disadvantaged nodes. The transaction pending time is shortened chiefly, and either the block interval or the block size can be adapted amid the changes of overall network conditions.""
""dc.identifier"",""https://doi.org/10.1155/2019/3674274""
""prism.section"",""Research Article""
""og:url"",""https://www.hindawi.com/journals/scn/2019/3674274/""
";https://scholar.google.com/scholar?start=440&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094532-612;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[PDF][PDF] Blockchain for Internet of Things (IoT) Research Issues Challenges & Future Directions: A Review;M Alamri, NZ Jhanjhi… ; Int. J. Comput. Sci. Netw …, 2019  expert.taylors.edu.my;;"… Which can help solve many Blockchain challenges Like, Oracle was responsible for ensuring

that the contract condition was met. Overall, this Oracle was a trusted third party. Artificial

intelligence technology has enhanced Oracle's intelligent building …";Cité 17 fois;;[PDF] taylors.edu.my;https://expert.taylors.edu.my/file/rems/publication/109566_6018_1.pdf;"
IJCSNS International Journal of Computer Science and Network Security, VOL.19 No.5, May 2019 

 

244 

Manuscript received May 5, 2019 
Manuscript revised May 20, 2019 

Blockchain for Internet of Things (IoT) Research Issues 
Challenges & Future Directions: A Review 

Malak Alamri†, NZ Jhanjhi††, Mamoona Humayun† 
 

†College of Computer and Information Science, Jouf University Al-Jouf, Saudi Arabia 
††School of Computing and Information Technology, Taylor’s University, Malaysia 

 
Summary 
Internet of Things (IoT) becomes vital source of converting 
things into smart, including smart homes, smart cities, smart 
industries etc. Internet of things have the ability to connect 
billions of things at the same time, which seeks to develop 
information sharing requirements that improve our daily lives. 
By seeing things on the Internet, traditional devices become 
intelligent and independent, and this vision becomes real and 
realistic. The Blockchain appears a great source of providing 
security to new era technological applications. The high growth 
of IoT based smart applications have high demand of security to 
manage and maintain the IoT based application’s data safety, 
security integrity, and authentication. The merger of both 
technologies may provide our secure security solutions. This 
research explores the Internet of things security solutions by 
integrating IoT applications with blockchain. The research 
initially focused on the blockchain basics, types, design for 
Internet of things applications. Further we elaborate the several 
challenges and issue of BIoT applications linked to the energy 
efficiency, security, privacy, throughput, latency, block size, 
bandwidth, usability, multi chain management, versioning, forks, 
autonomy and enforcement. Finally, we explore the future 
directions of blockchain for the internet of things. The literature-
based results showed, that the integration of Blockchain with 
Internet of things provides significant solutions of security and 
privacy to IoT based application. 
Key words: 
Blockchain, Internet of Things, Challenges, Future directions 

1. Introduction 

The term ""Blockchain"" originated from its technical 
structure (Chain Blocks), meaning the association of each 
block with the block that precedes it. The blockchain 
concept works to interlink the connections or transactions 
of data in the clusters. The cluster is defined as the data 
structure which includes many financial transactions. 
Individuals or entities exchange transactions. These 
transactions may be financial in nature and sometimes 
(smart contracts). Blockchain participants are any person 
or institution that accepts protocol strings and helps 
develop them. The organizers of these networks and those 
responsible for software maintenance do not share the 
blockchain. In this section, the basics of blockchain, basic 

functions of blockchain, types of blockchain, blockchain 
and (IoT) are highlighted. 

The Basics of Blockchain 

The Blockchain idea was developed by Distributed Ledger 
Technology (DLT). This technology is developed to 
provide Convention validation technology across a 
network that may cover the entire word to facilitate peer-
to-peer transactions and all financial transactions. This 
mechanism marginalizes third party roles in financial 
transactions such as: Banks, agents, intermediaries or any 
authority that may be required to ensure and maintain the 
fulfillment or update of transaction data. Then ensure that 
each financial transaction is correct and save it as a new 
block for an existing transaction. Once the transaction is 
saved within the string, it cannot be changed, overwritten 
or deleted, which requires higher levels of security and 
transparency [1]. Figure 1 illustrates further about the 
primary idea of blockchain and IoT based integrated 
application domain for the users. 
 

 

Fig. 1  How blockchain technology works. [3] 

The Basic Functions of Blockchain  

The Blockchain is an electronic mechanism that deals with 
financial transactions and uses the ""Peer to Peer"" 
technology. It has three basic functions: 
1. Allow financial transactions between individuals and 

institutions around the world with a high degree of 
reliability and security because they destroy the so-
called ""double spending"". [2] 



IJCSNS International Journal of Computer Science and Network Security, VOL.19 No.5, May 2019 

 

245 

2. Enable traceability (the ability to track something on 
the Internet to its assets) for transactions, which means 
that transactions will be clear, transparent and have 
higher levels of security. 

3. Protect users from any attacks or violations by 
malicious users via the same system. And there is no 
need for central authorities to participate in financial 
transactions, and to ensure lower expenses.  

 

Fig. 2  Blockchain Features.   

Figure 2 illustrates the main features of block chain which 
makes block chain safer, faster, with increased capacity. 
The simple blockchain network can be illustrated as shown 
in Figure 3. 
 

 

Fig. 3  Blockchain Network [1] 

Types of Blockchain 

By reviewing the previous literature, the researcher noted 
the existence of two major types of Blockchain known by 
those interested in this field, namely: Blockchain licensed 
and without permission: 

1.2.1. Blockchain licensed 
 A licensed Blockchain is a network that is used by 
individuals or institutions to conduct their financial 
business, such as a group of institutions or banks that 
control financial transactions. This network is only 

delegated to a group of individuals or entities that can 
access data only. They have the ability to read target data 
and write only. The licensed Blockchain is more recent 
than permission without permission. Thus, a licensed 
Blockchain is a central entity such as a bank that has the 
ability to control the rights of individuals and identify them 
to participate in the process of reading or writing data. This 
type of Blockchain ensures higher degrees of privacy. With 
this in mind, the most widespread and known permissioned 
Blockchains are (Hyper ledger Fabric & R3). [1], [4]. 

1.2.2. Blockchain Permission 
The Permission less Blockchain is an open network that 
can be accessed and used by any individual or entity. 
Bitcoin and Ethereum frozen hoops are good examples of 
unauthorized Blockchain because users can move to each 
other without any controller using bitcoin or ethereum as a 
method of payment. Since this cluster is open and 
decentralized, anyone (peer) can access or join this 
network and free to leave at any time. The counterpart is 
entitled to read or write what has been established for 
treatment. There is no central authority to manage peer 
interaction in this network, control membership, or read or 
write. The openness available means that the written 
content is readable by all individuals. However, the 
cryptographic features allow designing permission less 
Blockchain and hiding the information related to the peers’ 
privacy. [5] 

Blockchain and (IoT) 

The concept of “IoT” is the interconnection of smart 
devices to gather information and make decisions. By 
combining Blockchain with Internet objects, things can 
eliminate the lack of security in Internet objects where 
Blockchain requires “security by design”. Blockchain 
features, such as (incompatibility, transparency, readability, 
data encryption, and operational flexibility), can be used to 
overcome Internet security issues. The integration of 
Blockchain and IoT is a promising area of research which 
was tackled by a considerable amount of research but 
contains many uncovered areas. [6 – 7]. Table 1 shows 
comparsion between blockchain and IoT.  

Table 1: Comparison Between Blockchain and IoT [8] 
Blockchain IoT 

Decentralized Centralized 
Resource consuming Resource restricted 
Block mining is time-

consuming Demands low latency 

Scale poorly with large 
network 

IoT considered to contains large 
number of devices 

High bandwidth 
consumption 

IoT devices have limited bandwidth 
and resources 

Has better security Security is one of the big challenges of 
IoT 



IJCSNS International Journal of Computer Science and Network Security, VOL.19 No.5, May 2019 

 

246 

2. Literature Review 

In this paper, the literature has been reviewed in three 
sections (architecture, current challenges and problems of 
BIoT applications and future trends). The review included 
a number of books, journals, letters, reports and other 
relevant documents as well as academic databases such as 
Science Direct, EBSCO, Emerald and SAGE. In order to 
search for relevant literature, a wide range of related terms, 
such as IOT, BIot, Block chain, Message Time, and 
Algorithms were used. With regard to the dates of review 
of sources of literature, the researcher reviewed a mixture 
of ancient and contemporary studies to provide an 
integrated account of the results in this field. 

Blockchain Design for Applications of IoT  

Blockchain technology is used in more than one Domain 
and situation. Different sources such as [9] It was 
suggested that progress in the application of blockchain 
started next to Bitcoin as Blockchain v1.0, and then 
changed with respect to smart conventions such as 
Blockchain v2.0 and subsequently progressed to justice, 
applications efionation, efiency and Blockchain v3.0. 
The authors of ""Blockchain everywhere"" stated that the 
main aid of Blockchain usage with smart contracts is that it 
can automatically evaluate these contracts. Adopting smart 
contracts, temperatures can be automatically evaluated and 
the sender and receiver notified. Besides, the saved data 
were counter-manipulative and could be used for 
conducting check by outer parties to assure the practice of 
good distribution of medical products. With Ethereum, 
such a decentralized system can be fully used to resist 
tampering at low cost, on every contract basis and on a 
byte basis. With the participation of many stakeholders in 
the supply chain, Blockchain technology can be used to 
automate processes and eventually save costs by making 
sure trust among stakeholders. [10] 

2.1.1. Architecture 
Blockchain was a complex sort of Lego and must be 
adapted to specific business requirements. Because of 
different usage situations it is difficult to get a single 
simple structure, so they need to create different versions 
of Blockchain applications and architectural applications 
that suit individual business / industry needs. 
The approach presented was a single hybrid. The 
Blockchain is used together with a centralized server and a 
database-based approach. The main architecture of 
blockchain can be viewed in Figure 4.  

 

Fig. 4  Blockchain Architecture. [56] 

The main components of this system are Etherrium 
Blockchain network, database, intelligent nodes, server, 
mobile devices and sensors.Where the temperature is 
secured by smart written contracts. For each new group of 
pharmaceutical products or shipments that involve 
excellent temperature requirements, intelligent contracts 
are configured and deployed by the server to ensure 
compliance requirements for good distribution practice 
(GDP). [11] Therefore, the map was drawn from the 
consignment to the contract title through a linked database 
at low cost. The server hosts the modum.io AG node 
Ethereum that is involved in the Etherreum network and 
may witness modifications to the smart nodes or produce a 
new contract or intelligent contracts. [12] The Ethereum 
node is connected to a Hyper Text Transfer Protocol 
(HTTP) server via JSON. The data that is stored is too 
large or too sensitive to be stored in the Blockchain stored 
in the PostgreSQL database and this involves raw 
temperature data, because large cannot be stored in 
intelligent nodes. The smart nodes verify the temperature 
range and store the verification result in the smart nodes 
with the global Uniform Resource Location (URL), which 
refers to the raw temperature data and the retail data. 
Android clients communicate in the front end of the server 
through a Representative Transport Protocol (REST) 
interface designed with JSON to encrypt and decrypt 
requests / responses. Through the mobile phone, users can 
register new shipments including the administrative details 
within the system and create a smart contract for each 
shipment. The API should also allow the recipient of the 
shipment to download measurements of temperature 
measurements reported by the sensor to the server. Both 
the sender and receiver must be informed of the contract 
outcome and able to access the temperature measurements, 
preferably using the graphical representation. [10]A web 
portal and an infrastructure were the main components 
stand on Multichain and IoT devices as things were listed 
in. Figure 5 illustrated the blockchain prototype 
architecture.   



IJCSNS International Journal of Computer Science and Network Security, VOL.19 No.5, May 2019 

 

247 

 

Fig. 5  Blockchain, Prototype Architecture. [57] 

The web portal provides developers with safe and accurate 
control over software updates. The web portal is 
characterized by having an entrance to the Blockchain 
infrastructure, which is shared and shared by 
manufacturers. Each manufacturer must provide at least 
one business node for the development of computing 
power and availability of infrastructure. For the prototype, 
a Blockchain contract was hosted on the XenServer server 
and implemented as Virtual Machines (VMs). Web portal 
and Internet devices may share things with software 
updates and confirmations, through the Blockchain 
infrastructure. The system relies on asymmetric encryption 
to ensure data integrity and confidentiality. The Internet 
devices were either physically performed (i) by evolution 
panels, such as Raspberry Pi, which were closer to real 
field machines, or (ii) by virtual Qemu devices, to assess 
typical scalability. [14] 

To push the software update: 

1. The factory logs on to the gate. 
2. Select the device to update it. 
3. Download the software update package with metadata. 
4. Choose one of these options (a) just sign the update, 

(b) sign and encrypt. 
 
The first method is good for pushing an unencrypted file to 
a Blockchain, while the second method involves 
confidentiality. Many files are required because of 
hardware. However, the decryption key is supposed to be 
set for each existing device. Blockchain infrastructure, and 
ensure transactions are correct in less than a second. Each 
IoT Device communicates regularly with the Blockchain 
and then ensures that a new update is available for 
download. Therefore, IoT Device installs and downloads 
the update. Then, issue a Blockchain response to the 
modern hardware tracking. [15] 

2.1.2. Cryptographic Algorithms 
In general, a Blockchain can be considered as a permanent 
record whose records are stored in specific time blocks. 
Where one block contains transactions. The cluster is 
defined by its hash and refers to the previous cluster 
fragmentation. Everything is stored in the public 
Blockchain. 
Pre-defined encryption keys were common on the Internet. 
Where they are executed in hardware firmware before 
shipment. Its purpose is to serve as a foundation in other 
encryption algorithms. However, there are a number of 
identical or non-random keys. These results allow an 
attacker to guess or know the encryption key used by the 
device. [16] 

2.1.3. Message Time stamping 
Data generated from IoT devices is extensive, combining 
simple data such as sites, and more complex data such as 
watch videos. For data analysis, historical data must be 
reverted, and data must be stored and stored somewhere. 
Thus, this means that data from Internet devices things will 
be high standards. This also means that given the variety of 
data acquisition devices, data will also be heterogeneous. 
Another aspect of Internet data object is the relationship 
between space and time. The Internet will place things in a 
specific location and will place a time dimension on 
important data in statistical analysis. Only a small amount 
of data captured by Internet devices will be useful. Visual 
video can be used as an example where some video frames 
you capture when someone breaks rules are useful, while 
working hours and working hours were not useful. [17] 

Block chain updating and Protocol Stacks 

It was said that the Blockchain update protocol achieves 
consensus (probabilistic) in a Byzantine environment if   
these characteristics (probabilistically) are achieved [18]: 

1. Health (Health) 

That if all valid nodes that are activated on a shared  
state require a Blockchain to be augmented by the 
same block, each documented node moves to a new 
local copy state, which is Blockchain that is headed by 
that block. 

2. Agreement (consistency) 
      If the trusted node confirms that a new cluster header 

exists, any trusted node that updates the local 
Blockchain screen will be updated by using this cluster 
head. 

3. Liveness (Termination) 
     All transactions that come from shonest nodes will be 

assured in the end.  
4. Total order 



IJCSNS International Journal of Computer Science and Network Security, VOL.19 No.5, May 2019 

 

248 

      All valid nodes accept the same transaction order as 
long as they are certain in their views of the local 
Blockchain. 

Protocols that are consensus differ with different 
Blockchain networks. Because allowed Blockchain 
networks to recognize more stringent control over the 
synchronization of consensus nodes, they may Byzantine 
Fault-Tolerant (BFT) protocols to present the needed 
compatibility characteristics. A typical application for such 
protocols can exist in the undulation network, where a 
group of concurrent Ripple servers extend Blockchain 
through the voting mechanism. Moreover, if an external 
Oracle is presented to set the initial node to generate the 
block, the practical BFT (PBFT) can be taken to 
implement a three-stage commitment schema to expand the 
Blockchain [19]. Table2 illustrated a comparison Between 
4 Major Blockchain Protocols 

Table 2: A Comparison Between 4 Major Blockchain Protocols. 
Protocol 

type 
Tasks Key features 

Bitcoin  Dealing with 
encrypted 
Bitcoin coin 

Characterized as less 
authorized, because it is a 
public key chain. Thus, 
anyone can join. 
- Each node is characterized 
by having complete 
information about the 
Blockchain, and this makes 
the network a decentralized 
one 
- The protocol allows users to 
perform non-reversible 
transactions without having to 
explicitly trust the third part 

Ethereum Launch their 
own 
Blockchain 
projects, 
including 
specially 
encrypted 
currencies 

The Blockchain is marked as 
generic, does not require 
permissions. 
- The same technological 
backbone, such as encryption 
defragmentation functionality, 
uses private and public key 
encryption. 

Ripple 
Protocol 

Facilitate the 
transfer of 
money at the 
lowest cost 

- RPCA nodes are applied 
every second. 
- The contract will have the 
last closed ledger. 
-RPCA happens in tours, and 
in every tour. 

Hyperledger Design and 
develop 
enterprise 
Blockchain. 

- It is an authorized key chain, 
and no entity can join except 
trusted by the organization. 
- Not suitable for coded 
currencies. 

 

Current Challenges and Issue for BIoT Applications  

Nowadays, developing the technologies in the BIoT 
environment is as Cyber-Physical Systems (CPS) [20] or 
RFID [21] and telemetry systems [22] or 4G/5G 
broadband communications [23] were lay in many 
challenges. In particular, the situation of the Mission and 
critical situations [24] Increased concerns were added. In 
addition, the mix indicates that the mix suggests additional 
operational and operational needs later, and the growth of 
BIoTs applications is a compound procedure, which was 
touched by numerous features, which were interconnected. 

1.2.3. Energy Efficiency 
BIoT endpoints typically benefit from the supplier of 
power-based coercive equipment with batteries. Thus, 
energy efficiency was essential to allow long-term node 
placement. On the contrary, many Blockchains are 
considered by the power driven. In these cases, most use is 
due to two elements: 
 
1. Mining  
Blockchain are similar to Bitcoin in providing use of large 
volumes quantities of electricity because of the mining 
process, that were implicates a consensus algorithm (PoW) 
which contains in a kind of physical power seek for a hash. 
2. P2P communications 
Communications need edge strategies, which have to be 
strengthened on constantly, that might chief to energy 
waste. There were some researchers suggested energy 
effective for P2P networks protocols; however, there is 
still a need to examine additional issues for the exact state 
of Internet objects [25]. 
With regard to mining, proposed that the energy consumed 
by work proofs can be used for useful things while at the 
same time providing the needed PoW [16] Getting These 
proofs must have a certain difficulty degree, while 
verification must be, actually fast. Some Blockchain-based 
initiatives, such as Gridcoin, reward research computing 
with volunteer coins (though, as an unanimity algorithm, 
Gridcoin uses PoS). There was another interesting example 
was Primecoin, whose PoW mechanism searches for 
chains of prime numbers. So, a huge infrastructure such as 
the one involved in IoT could also be with regard to P2P 
communications, it was necessary for a Blockchain to 
connect between blocks and peers, so the more updates a 
Blockchain performs; the more power consumption was 
allocated to communications. For decreasing the updates 
number, mini-Blokchains may permit IoT nodes for 
interacting straightly with a Blockchain, as they only retain 
the transactions that are final and decrease the 
computational demands of a full node [27] 
Regarding hashing algorithms, SHA-256 was considered 
the base for being the one used by Bitcoin, but new 



IJCSNS International Journal of Computer Science and Network Security, VOL.19 No.5, May 2019 

 

249 

algorithms as X11 or Scrypt were faster and may decrease 
power consumption in mining [26]. Other hashing 
algorithms, like Blake-256, have been proposed and some 
Blockchains were able to benefit from various hashing 
algorithms, although more analyses should be performed 
on the improvement and performance of advanced hash 
functions for using on IoT devices [28]. 

1.2.4. Security 
For a personal user, the key for keeping confidentiality is 
perfect management of his/her own particular keys, as what 
the attacker wants in conjunction with the public key is to 
steal something from him/her or embody someone. A good 
initiative about this subject was CONIKS [29]. A great 
management system was generated in order to free users 
from managing the encryption key. In equivalent a system 
the user first has requested for a public key to a provider, 
which requires only a username for registering in the 
CONIKS system [20]. When a user needs to send a 
message to another user, the CONIKS client searches for 
the key of the counterparty in the key directory. For 
avoiding key tampering from the provider of service 
(which might become involved) [30], two checks 
performed before sending any message: other clients 
confirmed the receiver's public key when connecting with 
the original user, and this key did not alter unusually over 
time. Identical answers have been presented for BIoT 
devices, using Blockchain technology in order to access 
management and foster their identity, presenting 
Blockchain is security against forgery attacks and IP 
spoofing [31]. 
Certificates were also necessary when ensuring security on 
the Internet. Thus, authorities of certificate use public-key 
infrastructure must provide trust to third parties [26]. 
However, such authorities have confirmed their failure on 
certain occasions, and then having to make previously 
presented certificates invalidated. Some latest initiatives 
have been sought to fix certain structural flaws existed in 
the Secure Sockets Layer (SSL) certificate system. In 
particular, the Google Transparency Certificate presents a 
framework for auditing and monitoring SSL certificates in 
real time. Because of using a distributed system based on 
Merkle a hash tree that permits third parties to verify and 
audit if a certificate was proper [32]. 
The other security feature was the availability although it is 
really considered the simplest to be achieved by 
Blockchain, which they were is designed by design to be 
handed out systems, allowing them to continue employing 
even when some nodes were under attack. However, the 
availability may be in compromise by other kinds of 
attacks. The most feared attack was a 51% attack (also 
known as the majority attack), where one miner controls a 
whole Blockchain and perform transactions at wish. In this 
case, the data is available, but the availability for doing 

transactions may be stopped by the attacker that controls 
the Blockchain. It is obvious that this type of attack has an 
effect on the integrity of data [30]. 

1.2.5. Privacy 
All the Blockchain users were known by its hash or their 
public key. It implies that anonymity was not achieved, 
because whole transactions were shared, it was potential 
for third parties to analyze and identify these transactions 
and infer the participants’ identities [33]. Privacy was more 
complicated in BIoT environments, because BIoT devices 
may discover special user data that can be saved in a 
Blockchain whose privacy requirements are different from 
a country to another country [34].Thus, in comparison with 
conventional online payments, which were general only 
seen to transacting parties and to an intermediary (such as, 
financial government, institutions), transparent transactions 
promoted by Blockchain were a privacy challenge. 
In a personal Blockchain, subsequently approach controls 
were achieved later, there was the smallest node which was 
identified with accesses the scheme. Supposing the 
neutrality of the access controller, the situation was likely 
to decrease exposure by founding an impartial Blockchain 
with each object a user’s were participating with. This 
system develops communications difficulty, although 
separates the user from none of the wanted to observe. For 
example, Multichain presents an explanation for 
organizing personal Blockchains which were assures that 
the events on the Blockchain may be checked by selected 
members [35]. 
Mixing methods may also help to improve privacy. Such 
methods may aggregate communications from varied IoT 
strategies and output actions or other transactions to 
dissimilar directs that were not connected to the unique 
strategies. These methods expand privacy, but they were 
not complete, thus they may be deanonymized over 
numerical detection attacks. Moreover, the mixing facility 
must be confidential, while a malicious mixer may 
depiction users and, in the economic transactions, it may 
stop stealing of coins. To processing such subjects, various 
proposals proposed subjecting theft over an accountability 
instrument or beating the input/output address charting 
from the mixing server [36]. 
Privacy may also be extended to none knowledge showing 
techniques such as those operated by Zerocoin and 
Zerocash or Zcash [37]. A zero of knowledge evidence 
was a technique that allows for showing to counterparty, 
which the users were recognized obvious information 
deprived of uncovering such information. In the case of 
BIoT applications, zero of knowledge proofs may be used 
for verification or through reliable transactions for 
preventing user identity detection or appropriate. However, 
notice that such evidences were not immune to attacks [38]. 



IJCSNS International Journal of Computer Science and Network Security, VOL.19 No.5, May 2019 

 

250 

In detail, as in the case of mixing methods, they were 
vulnerable to de-anonymization across statistical detection 
attacks, but they develop mixing methods by preventing 
the requirement for a mixing server, which may position 
pose and present a security and functioning bottleneck. 
A solution for achieving privacy was the homomorphic 
encryption use [39]. Like this type of encryption permits 
third-party BIoT facilities to procedure a transaction 
deprived of the reveal of the unencrypted data to those 
facilities. Many researchers have presented differences in 
the protocol of Bitcoin for achieving use of homomorphic 
promises.  

1.2.6. Throughput and Latency 
BIoT positions may require a Blockchain network 
capability to generate huge amounts of transactions per 
time element in clear networks. For example, a Blockchain 
of Bitcoin contains the highest default level of 7 
transactions per second, while it can be extended by 
dealing with distinct clusters or by adapting the obvious 
features of node behavior upon receipt of transactions. The 
assessment did not make the other networks unusually fast. 
For example, VisaNet (VisaNet) may control 25,500 
transactions per second. 
With regard to the disappearance, it was important to note 
that Blockchain transactions are appropriate for some time 
to deal with. In the case of Bitcoin, for example, the times 
of mass formation maintain Poisson distribution at a rate of 
10 minutes, while, in order to prevent double spending, the 
wholesalers were delayed for about an hour, and then six 
or seven blocks are often necessary to be extra for the 
series Earlier the deal was founded. This individual latency 
includes a few seconds in the visa position. [40] 
As for the assent latency, it may be determined that the 
difficulty of the consensus procedure was more important 
regarding latency than unusual hashing, but various 
blockchain’s, such as those verifications of Litecoin, which 
chosen for scrypt using, a hashing algorithm which was 
faintly faster than SHA-256 [41]. 

1.2.7. Block size  
Operators store their transactions, requiring larger initial 
transfer times and benefiting from the most powerful 
miners. Blockchain methods will be further studied, but the 
fact is that the largest Internet object node may not be able 
to handle a small fraction of traditional templates. He 
noted that different nodes had to store large amounts of 
data that were not of interest to them, and which could be 
observed as a loss in arithmetic supplies. This topic may be 
stopped using lightweight nodes that were able to achieve 
transactions on the Blockchain. On the contrary, this 
method needs to stay in the Internet hierarchy of things 
from the powerful nodes that may clearly Blockchain 

support for a restricted contract resource, indicating a clear 
data concentration. 
May contain different additional materials when using a 
mini-series/block [42]. This type of Blockchain produces a 
version tree usage, which provides supplies for the current 
state of each user of the Blockchain. Therefore, only the 
largest current transactions on the Blockchain must remain 
composed of the version tree. Thus, Blockchain only 
improves when new users have increased to Blockchain. 

1.2.8. Bandwidth  
To rise IoT’s bandwidth, developers have been suggesting 
the Software Defined Networking (SDN) tools, which 
offers smart routing and facilitate the process of making 
decisions through the SDN manager. [42] In recent times, 
Sharma et al. [43] suggested a distributed IoT network 
construction, called DistBlockNet. Depend on the 
blockchain equipment, DistBlockNet construction can 
offer extending and elasticity, deprived of the essential for 
a centralized controller. The distributed blockchain 
network usages two kind of nodes, specifically, I) the 
controller/confirmation node, which preserve the improved 
flow rules table information. II) The invitation/reaction 
node, which improved its flow rules table in a network of 
blockchain. [44] 
 Moreover, it is important to note that transaction and 
block volume were to be climbed agreeing to the 
bandwidth limits of IoT networks: various transactions that 
are small might increase the energy consumption 
connected to communications, although few great ones 
may include big payloads that may not be controlled by 
several IoT strategies. 

1.2.9. Usability  
In instruction to facilitate the designers’ work of 
Blockchain entering Application Programming Interface 
(APIs) would be as user welcoming as likely. The same 
would be op";"""date"",""2019-06-13T12:39:24Z""
""pdf:PDFVersion"",""1.5""
""xmp:CreatorTool"","" Word용 Acrobat PDFMaker 11""
""pdf:docinfo:title"",""Title""
""Company"",""Home""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"","" Word용 Acrobat PDFMaker 11""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""Title""
""xmp:CreateDate"",""2019-06-13T21:39:10Z""
""modified"",""2019-06-13T12:39:24Z""
""pdf:docinfo:custom:SourceModified"",""D:20190613122553""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""true""
""xmp:ModifyDate"",""2019-06-13T21:39:24Z""
""pdf:docinfo:creator"",""IJCSI""
""meta:author"",""IJCSI""
""meta:creation-date"",""2019-06-13T12:39:10Z""
""created"",""2019-06-13T12:39:10Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-06-13T12:39:10Z""
""resourceName"",""109566_6018_1.pdf""
""Author"",""IJCSI""
""producer"",""Adobe PDF Library 11.0""
""pdf:docinfo:producer"",""Adobe PDF Library 11.0""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""IJCSI""
""dcterms:created"",""2019-06-13T12:39:10Z""
""Last-Modified"",""2019-06-13T12:39:24Z""
""dcterms:modified"",""2019-06-13T12:39:24Z""
""title"",""Title""
""xmpMM:DocumentID"",""uuid:31108e36-3d87-479e-9a4e-2fb674803b7f""
""Last-Save-Date"",""2019-06-13T12:39:24Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2019-06-13T12:39:24Z""
""meta:save-date"",""2019-06-13T12:39:24Z""
""Content-Length"",""436954""
""Content-Type"",""application/pdf""
""xmp:MetadataDate"",""2019-06-13T21:39:24Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""IJCSI""
""pdf:producer"",""Adobe PDF Library 11.0""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""15""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""4241"",""3753"",""4668"",""4202"",""4727"",""5740"",""5392"",""3920"",""4801"",""4993"",""4970"",""5376"",""5378"",""4841"",""1645""
""access_permission:extract_content"",""true""
""pdf:docinfo:custom:Company"",""Home""
""access_permission:can_print"",""true""
""SourceModified"",""D:20190613122553""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-06-13T12:39:10Z""
";
1619094558-728;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;A New Law for Derivatives Markets and the Use of Smart Contracts;BO Bairan ; The PayTech Book: The Payment Technology …, 2019  Wiley Online Library;;"… concepts of applicable regulations in relevant financial derivatives markets and how the use of

smart derivatives through distributed ledger technology (eg blockchain) can be … Also, smart

contracts can incorporate external information using third-party providers, called oracles …";;null;null;;;;https://scholar.google.com/scholar?start=540&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094658-1151;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Aleph: Efficient atomic broadcast in asynchronous networks with byzantine nodes;A G?gol, D Le?niak, D Straszak, M ?wi?tek ; Proceedings of the 1st …, 2019  dl.acm.org;;"… At the core of virtually every cryptocurrency system lies a mech- anism that collects … best imitate

the highly adversarial execution environment of a typical permission- less blockchain system,

one … of applications, they have still not gained much recognition in the crypto-community …";Cité 13 fois;Les 7 versions;[PDF] acm.org;https://dl.acm.org/doi/pdf/10.1145/3318041.3355467?casa_token=Nm78CA_OOcYAAAAA:DA5QSQPY7pmDSitkxAcMZzYKAITCA8J3dnv__xilC7J2FfXk_kPXcaFt7yZmlWqkODqhhIFLT84;;;https://scholar.google.com/scholar?start=970&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094544-661;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Technical and Legal Challenges for Heal Thcare Blockchains and Smart Contracts;SA Wright ; 2019 ITU Kaleidoscope: ICT for Health: Networks …, 2019  ieeexplore.ieee.org;;"… a healthcare smart contract executing on a blockchain accepting data from an oracle reporting

on a … there may be a number of ancillary documents that users of the blockchain may be … with the

outside world for information and those external data sources are called oracles …";Cité 3 fois;Les 2 versions;[PDF] itu.int;https://www.itu.int/en/ITU-T/academia/kaleidoscope/2019/Documents/Presentations/S8.1_Steven_Wright.pdf;"
TECHNICAL AND LEGAL 

CHALLENGES FOR HEALTHCARE 

BLOCKCHAINS AND SMART 

CONTRACTS

4-6 December

Atlanta, Georgia, USA

Steven A. Wright MBA PhD JD

Georgia State University 

swright22@gsu.edu



4-6 December

Atlanta, Georgia, USA

TECHNICAL AND LEGAL CHALLENGES FOR 

HEALTHCARE BLOCKCHAINS AND SMART 

CONTRACTS
• Blockchain Introduction

• Healthcare Blockchains

– Data in Healthcare 
Blockchains

– Actors in Healthcare 
Blockchains

• Technology Issues

– Implementation Issues

– Identity & Trust Issues

• Legal Issues

– Entities

– Public Law 

– Private Law

• Recommendations

• Blockchain technology usually 

associated with cryptocurrency 

(e.g. Bitcoin)

• Broad range of applications 

proposed (e.g. financial, health, IoT)

• Code as Law -> DAOs

• Nascent Standardization efforts 

(e.g. ISO TC 307) 

• Open Source implementations 

(e.g. Hyperledger, Ethereum) 



4-6 December

Atlanta, Georgia, USA

Healthcare Blockchains:

• Variety of Blockchain applications proposed in Healthcare:

– Prevention of drug counterfeiting*, research/clinical trials, insurance 

claim adjudication, healthcare records, wearables, mhealth

– Good fit applications ?– multiple (competing) parties, more trust adds 

value, intermediary elimination, visible/auditable data

• Beyond proposals, some are being implemented:

– Primarily  on Ethereum and Hyperledger

• Benefits claimed:

– Decentralization, data security and privacy(?), health data ownership, 

availability, robustness, transparency and trust, data integrity

*The Drug Supply Chain Security Act (DSCSA) of 2013 requires the Food and Drug Administration (FDA)  to develop standards and
regulations for an interoperable electronic system to identify and trace medications.  A number of pilot projects for this purpose have 
been developed using blockchain technologies  (https://www.drstevenawright.com/pharmaceutical-supply-blockchains/).

https://www.drstevenawright.com/pharmaceutical-supply-blockchains/


4-6 December

Atlanta, Georgia, USA

Healthcare Blockchains: Data in Healthcare 
Blockchains

• Lots of data types across the healthcare blockchain proposals:

– Financial, transaction records, consent forms, clinical trial records, 

sensor data (e.g. temperature), medical records, personal records  

• Healthcare record categories / use cases:

– Electronic Medical Records (EMRs) stored by healthcare provider

– Personal Health Records (PHRs)  store data collected by patients 

themselves (e.g. using wearables) 

– Electronic Health Records (EHRs)  passed between healthcare 

providers

• Challenges:

– Storage – Size of records  

– Privacy – access controls, confidentiality assurance mechanisms



4-6 December

Atlanta, Georgia, USA

Healthcare Blockchains: Actors in Healthcare 
Blockchains

• Depends on specific use cases

• Non fungible data value/ trustworthiness comes from who adds it (e.g. lab 

results from a qualified lab) – pseudonymous, permissionless transactions 

may not be needed?

• Stakeholders – patients healthcare professionals, regulatory agencies, legal 

systems, the public

• Special cases for access – minors, healthcare power of attorney, heirs after 

death

• Other Off chain systems for computation, storage, etc. 

• Is the blockchain itself an actor? 



4-6 December

Atlanta, Georgia, USA

Blockchain Technology Issues:

• Technology issues add risks impeding design and deployment

• Technology at early stage of adoption 

– only 2% of papers in one study were reporting on implementations

• Identified challenges include  interoperability, security and privacy, 

scalability, speed and patient engagement

• Not just a technology exercise

– Need to consider broader issues for requirements, e.g. organization, 

legal context

• Blockchain as trust machine – but who needs to trust whom for what 

purpose?



4-6 December

Atlanta, Georgia, USA

Blockchain Technology Issues: Implementation 

Issues

• Software has bugs

– Cryptocurrency applications as an incentive stress test to find bugs

– Security and performance bugs can take some time to fix 

• Quality Metrics and benchmarks not yet agreed

– What to measure, how to apply across different blockchain technologies

• Software engineering tools  and methodologies still under development for 

blockchains

• Technology maturity



4-6 December

Atlanta, Georgia, USA

Blockchain Technology Issues: Identity & Trust 
Issues

• Blockchain sometimes referred to as trust machine, and most would 

consider trust important for healthcare applications

• What do we mean by trust in healthcare blockchain applications – is it the 

same sort of trust as in financial applications?

• Various Blockchains have limited capabilities across the security 

dimensions – confidentiality, availability, integrity, provenance, 

pseudonymity and selective disclosure – which are important for specific 

healthcare blockchain applications?

• Who do we need to trust and for what purpose in healthcare blockchain 

applications? What are the consequences of losing that trust?



4-6 December

Atlanta, Georgia, USA

Blockchain Legal Issues:

• Legal risks can impede the deployment of healthcare blockchains.

• Legal jurisdictions have geographic boundaries – blockchains do not -> may 

be impacted by laws of multiple jurisdictions.

• Blockchain code as law can violate, complement, supplement existing laws 

and substitute for law where none exist.

• Blockchain as trust machine, but legal systems also rely on trust.



4-6 December

Atlanta, Georgia, USA

Blockchain Legal Issues: Entities

• Law covers people and the things they own; legal risks associated with 

things revert back to the thing’s owners.

• Legal “people” includes corporations, partnerships, LLCs, etc.

• Even in absence of other documentation, participants in blockchain could be 

considered in a partnership -> joint liability.

• Proposals to create independent Digital Autonomous Entities on 

blockchains:

– Some claim possible within existing LLC enabling legislation

– State specific Legislation, e.g. Vermont BBLLC statute (S.269 (Act 205) 

2018 §4171-74).

• Under what circumstances would a Healthcare BBLLC make sense? 



4-6 December

Atlanta, Georgia, USA

Blockchain Legal Issues: Public Law 

• Blockchain specific legislation under consideration in many states 

– https://bit.ly/2OlWcJH

• General Statues impacting lots of  software technology implementations

– e.g. privacy legislation like GDPR requires corrections, but blockchains are immutable.

• Healthcare Specific laws and regulations

– e.g. Privacy regulations specific to healthcare (e.g. HIPPA) 

– e.g. Medical device regulations

– DSCSA

https://bit.ly/2OlWcJH


4-6 December

Atlanta, Georgia, USA

Blockchain Legal Issues: Private Law

• Contracts

– “Smart contracts” executing on blockchains

– Completeness / correctness / amiguity

• Torts (duties where no contract exists)

• Enforcement actions

– By the blockchain (self executing smart contract)

– Blockchain as arbitration

– Legal actions on a blockchain? 



4-6 December

Atlanta, Georgia, USA

Recommendations:

• Different approaches to reducing risks for deployment of healthcare 

blockchains.

• Availability of open source reduces cost/risk of experimentation  with new 

technologies - provides a design pattern example for commercial 

implementations. More specific open source communities around selected 

healthcare blockchain applications may be helpful.

• Standards are particularly helpful for enabling interoperability. While TC 307 has 

started work, more remains to be done particularly around standardizing the  

healthcare record formats “healthcare tokens”.

• Regulatory support through ”sandboxes”, etc. can help both the industry and its 

regulators understand the possibilities of the technology. More specific 

legislation/ regulation may then follow.

• Standardization (or perhaps parameterization) of smart contracts applicable to 

healthcare blockchains would be helpful if the use cases for those applications 

are well understood. 



Thank you


";"""date"",""2019-11-27T12:27:10Z""
""pdf:PDFVersion"",""1.7""
""xmp:CreatorTool"",""MicrosoftÂŽ PowerPointÂŽ for Office 365""
""pdf:docinfo:title"",""PowerPoint Presentation""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""language"",""en""
""dc:format"",""application/pdf; version=1.7""
""pdf:docinfo:creator_tool"",""MicrosoftÂŽ PowerPointÂŽ for Office 365""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""PowerPoint Presentation""
""xmp:CreateDate"",""2019-11-27T13:27:10Z""
""modified"",""2019-11-27T12:27:10Z""
""pdf:hasMarkedContent"",""true""
""xmp:ModifyDate"",""2019-11-27T13:27:10Z""
""pdf:docinfo:creator"",""Njume-Ebong, Ahone""
""meta:author"",""Njume-Ebong, Ahone""
""meta:creation-date"",""2019-11-27T12:27:10Z""
""created"",""2019-11-27T12:27:10Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-11-27T12:27:10Z""
""resourceName"",""S8.1_Steven_Wright.pdf""
""Author"",""Njume-Ebong, Ahone""
""producer"",""MicrosoftÂŽ PowerPointÂŽ for Office 365""
""pdf:docinfo:producer"",""MicrosoftÂŽ PowerPointÂŽ for Office 365""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""access_permission:modify_annotations"",""true""
""dc:creator"",""Njume-Ebong, Ahone""
""dcterms:created"",""2019-11-27T12:27:10Z""
""Last-Modified"",""2019-11-27T12:27:10Z""
""dcterms:modified"",""2019-11-27T12:27:10Z""
""title"",""PowerPoint Presentation""
""xmpMM:DocumentID"",""uuid:87DC8701-B0E2-4CC5-968C-FFA5FB8DC023""
""Last-Save-Date"",""2019-11-27T12:27:10Z""
""pdf:docinfo:modified"",""2019-11-27T12:27:10Z""
""meta:save-date"",""2019-11-27T12:27:10Z""
""Content-Length"",""505960""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Njume-Ebong, Ahone""
""dc:language"",""en-GB""
""pdf:producer"",""MicrosoftÂŽ PowerPointÂŽ for Office 365""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""14""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""179"",""619"",""986"",""665"",""554"",""527"",""451"",""698"",""424"",""653"",""460"",""328"",""972"",""9""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-11-27T12:27:10Z""
";https://scholar.google.com/scholar?start=480&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094656-1146;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Stateful public-key encryption: A security solution for resource-constrained environment;J Baek, W Susilo, K Salah, JS Ha, E Damiani… ; Advances in Cyber …, 2019  Springer;;"… BKS constructed another scheme aiming to remove the random oracle. Their construction is based

on the well-known Kurosawa and Desmedt's hybrid encryption scheme without random oracles

[33]. We call this scheme “\(\mathsf {BKS2}\)” and describe it in Fig …";Cité 4 fois;E Damiani;null;;;;https://scholar.google.com/scholar?start=960&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094597-895;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[PDF][PDF] Fully Distributed Non-Interactive Adaptively-Secure Threshold Signature Scheme with Short Shares: Efficiency Considerations and Implementation;B Libert, M Joye, M Yung, F Mouhartem ; Threshold, 2019  git.epheme.re;;"… 11/03/2019 8/19 Page 14. Construction in the random oracle model Based on linearly

homomorphic structure-preserving signatures (HSPS): (Libert-Peters-Joye-Yung, Crypto'13) ?

Messages are vectors ?M = (M1,..., MN) ? GN in a discrete-log-hard group G, for some N ? …";Autres articles;;[PDF] epheme.re;https://git.epheme.re/fmouhart/website-pro/raw/07df4df01a48b390683819e82699fd3aa7f05858/content/presentations/2019-03-11.NTCW.pdf;"
Fully Distributed Non-Interactive Adaptively-Secure Threshold Signature Scheme
with Short Shares: Efficiency Considerations and Implementation

BenoĂŽt Libert1,2 Marc Joye3 Moti Yung4 Fabrice Mouhartem2,5

NIST Threshold Cryptography Workshop 2019, March 11th
1CNRS, France

2École Normale Supérieure de Lyon, France

3OneSpan, Belgium

4Google Inc. and Columbia University, USA

5Microso t Research India

Fabrice Mouhartem Fully Distributed Non-Interactive Adaptatively-Secure Threshold Signature Scheme with Short Shares 11/03/2019 1/19



Motivation

Single points of failure is too risky:

▶ Surveillance by dedicated powerful adversaries (governments) on the Internet and its
encryption and signing methods has been highlighted

▶ Attacks on certification authorities lead to fake certificates distributed over the Internet and
destroy the “trust infrastructure”

e.g., DigiNotar was hacked and attacker produced a DigiNotar-signed “Google certificate”
(September 2011)

Darkmatter’s UAE security company, known for mass surveillance, requested to be a trusted CA
(February 2019)

▶ Threshold cryptography (Desmedt-Frankel, Crypto’89 & Boyd, IMA’89)
is a mechanism to deal with this by splitting keys among shareholders

Enhances the security of highly sensitive keys and the availability of systems

Fabrice Mouhartem Fully Distributed Non-Interactive Adaptatively-Secure Threshold Signature Scheme with Short Shares 11/03/2019 2/19



Threshold Signatures

(t,n)-threshold signature scheme:

m

sk1

ski

skn

...

...
Combiner

≥ t σ(m)

pk

b ∈ {0, 1}

m

σ1

σi

σn

Fabrice Mouhartem Fully Distributed Non-Interactive Adaptatively-Secure Threshold Signature Scheme with Short Shares 11/03/2019 3/19



Constructing Threshold Cryptography

Two main design families for threshold cryptography:

▶ Drop-in replacement: e.g., threshold (EC)DSA, (ACNS’16), threshold RSA (Crypto’91)
→ Most of the proposed solutions

▶ Optimized threshold: achieve certain performance using the best secure scheme

The second approach is more flexible (and allows proving adaptive security)

We optimize the following parameters simultaneously:

- Security

- Signature size

- Share size

- Communication

Fabrice Mouhartem Fully Distributed Non-Interactive Adaptatively-Secure Threshold Signature Scheme with Short Shares 11/03/2019 4/19



Constructing Threshold Cryptography

Two main design families for threshold cryptography:

▶ Drop-in replacement: e.g., threshold (EC)DSA, (ACNS’16), threshold RSA (Crypto’91)
→ Most of the proposed solutions

▶ Optimized threshold: achieve certain performance using the best secure scheme

The second approach is more flexible (and allows proving adaptive security)

We optimize the following parameters simultaneously:

- Security

- Signature size

- Share size

- Communication

Fabrice Mouhartem Fully Distributed Non-Interactive Adaptatively-Secure Threshold Signature Scheme with Short Shares 11/03/2019 4/19



Static vs Adaptive Corruptions

▶ Static corruptions: adversary corrupts servers before seeing the pk

▶ First threshold signatures:

- Desmedt-Frankel (Crypto’91): threshold RSA w/o robustness (heuristic)

- De Santis et al. (STOC’94): provably secure, but large partial signatures

- Gennaro et al. (Eurocrypt’96 & Crypto’96): threshold DSA & RSA signatures

- Frankel et al. (FOCS’97 & Crypto’97): threshold RSA with interaction

- …

▶ Robust threshold signatures without interaction:

- Shoup (Eurocrypt’00): practical threshold RSA signatures

- Katz-Yung (Asiacrypt’02): threshold Rabin signatures

- Boldyreva (PKC’03): short threshold signatures

- Wee (Eurocrypt’11): generic constructions

Fabrice Mouhartem Fully Distributed Non-Interactive Adaptatively-Secure Threshold Signature Scheme with Short Shares 11/03/2019 5/19



Static vs Adaptive Corruptions

▶ Static corruptions: adversary corrupts servers before seeing the pk

▶ First threshold signatures:

- Desmedt-Frankel (Crypto’91): threshold RSA w/o robustness (heuristic)

- De Santis et al. (STOC’94): provably secure, but large partial signatures

- Gennaro et al. (Eurocrypt’96 & Crypto’96): threshold DSA & RSA signatures

- Frankel et al. (FOCS’97 & Crypto’97): threshold RSA with interaction

- …

▶ Robust threshold signatures without interaction:

- Shoup (Eurocrypt’00): practical threshold RSA signatures

- Katz-Yung (Asiacrypt’02): threshold Rabin signatures

- Boldyreva (PKC’03): short threshold signatures

- Wee (Eurocrypt’11): generic constructions

Fabrice Mouhartem Fully Distributed Non-Interactive Adaptatively-Secure Threshold Signature Scheme with Short Shares 11/03/2019 5/19



Static vs Adaptive Corruptions

▶ Adaptive corruptions: adversary corrupts up to t servers at any time.

- Canetti et al. (Crypto’99) and Frankel-MacKenzie-Yung (ESA’99, Asiacrypt’99): reliance on erasures

- Jarecki-Lysyanskaya (Eurocrypt’00): no need for erasures, but much interaction at decryption

- Lysyanskaya-Peikert (Asiacrypt’01): adaptively secure signatures with interaction.

- Abe-Fehr (Crypto’04): adaptively secure UC-secure threshold signatures and encryption with
interaction

- Almansa-Damgaard-Nielsen (Eurocrypt’06): adaptively secure proactive RSA, but with interaction and
O(n) storage

- Libert-Yung (ICALP’11): adaptively secure signatures without interaction,
but using erasures and a trusted dealer

Fabrice Mouhartem Fully Distributed Non-Interactive Adaptatively-Secure Threshold Signature Scheme with Short Shares 11/03/2019 6/19



Threshold Signatures: Our Results (PODC'14, TCS'16)

▶ Adaptively secure threshold signatures have not been achieved with:

- Non-interactivity

- Robustness against malicious adversaries

- Optimal resilience (t = (n− 1)/2)

- No erasures

- Constant-size private key shares (regardless of t, n)

- Distributed key generation (no trusted dealer)

▶ We give efficient candidates with one-round distributed key generation

Theorem
In the random oracle model, constructions exist under standard assumptions

Fabrice Mouhartem Fully Distributed Non-Interactive Adaptatively-Secure Threshold Signature Scheme with Short Shares 11/03/2019 7/19



Threshold Signatures: Our Results (PODC'14, TCS'16)

▶ Adaptively secure threshold signatures have not been achieved with:

- Non-interactivity

- Robustness against malicious adversaries

- Optimal resilience (t = (n− 1)/2)

- No erasures

- Constant-size private key shares (regardless of t, n)

- Distributed key generation (no trusted dealer)

▶ We give efficient candidates with one-round distributed key generation

Theorem
In the random oracle model, constructions exist under standard assumptions

Fabrice Mouhartem Fully Distributed Non-Interactive Adaptatively-Secure Threshold Signature Scheme with Short Shares 11/03/2019 7/19



Security of Non-interactive Threshold Signatures

▶ Security under chosen-message attacks and adaptive corruptions:

1. Distributed key generation: Challenger runs Dist-Keygen with A

A can corrupt players during Dist-Keygen and obtains PK, {SKi}i∈C

2. Query stage: A makes adaptive queries

- Corruption i ∈ {1, . . . , n}: A receives SKi
and C := C ∪ {i} is updated

- Signature (i,M): A receives σi = Share-Sign(i, SKi,M)

3. Output: A outputs a pair (M⋆, σ⋆) and wins if

• Verify(PK,M⋆, σ⋆) = 1

• |V ∪ C| ≤ t where
V := {i ∈ {1, . . . , n} | (i,M⋆) was queried by A}

Fabrice Mouhartem Fully Distributed Non-Interactive Adaptatively-Secure Threshold Signature Scheme with Short Shares 11/03/2019 8/19



Security of Non-interactive Threshold Signatures

▶ Security under chosen-message attacks and adaptive corruptions:

1. Distributed key generation: Challenger runs Dist-Keygen with A

A can corrupt players during Dist-Keygen and obtains PK, {SKi}i∈C

2. Query stage: A makes adaptive queries

- Corruption i ∈ {1, . . . , n}: A receives SKi
and C := C ∪ {i} is updated

- Signature (i,M): A receives σi = Share-Sign(i, SKi,M)

3. Output: A outputs a pair (M⋆, σ⋆) and wins if

• Verify(PK,M⋆, σ⋆) = 1

• |V ∪ C| ≤ t where
V := {i ∈ {1, . . . , n} | (i,M⋆) was queried by A}

Fabrice Mouhartem Fully Distributed Non-Interactive Adaptatively-Secure Threshold Signature Scheme with Short Shares 11/03/2019 8/19



Security of Non-interactive Threshold Signatures

▶ Security under chosen-message attacks and adaptive corruptions:

1. Distributed key generation: Challenger runs Dist-Keygen with A

A can corrupt players during Dist-Keygen and obtains PK, {SKi}i∈C

2. Query stage: A makes adaptive queries

- Corruption i ∈ {1, . . . , n}: A receives SKi
and C := C ∪ {i} is updated

- Signature (i,M): A receives σi = Share-Sign(i, SKi,M)

3. Output: A outputs a pair (M⋆, σ⋆) and wins if

• Verify(PK,M⋆, σ⋆) = 1

• |V ∪ C| ≤ t where
V := {i ∈ {1, . . . , n} | (i,M⋆) was queried by A}

Fabrice Mouhartem Fully Distributed Non-Interactive Adaptatively-Secure Threshold Signature Scheme with Short Shares 11/03/2019 8/19



Construction in the random oracle model

Based on linearly homomorphic structure-preserving signatures (HSPS):
(Libert-Peters-Joye-Yung, Crypto’13)

▶ Messages are vectors M⃗ = (M1, . . . ,MN) ∈ GN in a discrete-log-hard group G, for some N ∈ N

▶ Homomorphism: given signatures {σi}ℓi=1 on vectors {M⃗i}ℓi=1, anyone can compute a signature
σ =

∏ℓ
i=1 σ

ωi
i on a linear combination M⃗ =

∏ℓ
i=1 M⃗

ωi
i

▶ Security: deriving a signature for M⃗ ̸∈ span(M⃗1, . . . , M⃗ℓ) is infeasible

▶ For N > 1, deciding if M⃗1, . . . , M⃗ℓ+1 ∈ GN are linearly independent is hard

Definition (K-linear assumption)
given vectors g⃗1, . . . , g⃗K+1 ∈R GK+1, no PPT algorithm can decide if dim(⟨g⃗1, . . . , g⃗k+1⟩) = K or K+ 1

Fabrice Mouhartem Fully Distributed Non-Interactive Adaptatively-Secure Threshold Signature Scheme with Short Shares 11/03/2019 9/19



Construction (cont.)

▶ Let Π = (Keygen, Sign, Verify,Derive) be a HSPS scheme

▶ Signature scheme based on the K-linear assumption

Keygen(1λ) : runs (pk, sk)← Π.Keygen(1λ, K+ 1) and chooses a hash function H : {0, 1}∗ → GK+1

Sign(sk,M) : computes (H1, . . . ,HK+1) = H(M) ∈ GK+1 and outputs

σ ← Π.Sign(sk, (H1, . . . ,HK+1))

Verify(pk,M, σ) : computes (H1, . . . ,HK+1) = H(M) ∈ GK+1 and returns 1 if and only if
Π.Verify(pk, (H1, . . . ,HK+1), σ) = 1

Theorem
In the ROM, the scheme is secure against chosen-message attacks if the K-linear assumption
holds in G.

Fabrice Mouhartem Fully Distributed Non-Interactive Adaptatively-Secure Threshold Signature Scheme with Short Shares 11/03/2019 10/19



Construction (cont.)

Distributing the system using specific properties of our HSPS:

▶ Key-homomorphism: For any M⃗, given σ1 ← Sign(sk1, M⃗) and σ2 ← Sign(sk2, M⃗), anyone can
compute σ ← Sign(sk1 + sk2, M⃗)

⇒ Convenient for non-interactive threshold signing
(reconstruction via interpolation in the exponent)

▶ In the security proof, the private key is known at any time

⇒ Allows handling adaptive corruption queries.

Fabrice Mouhartem Fully Distributed Non-Interactive Adaptatively-Secure Threshold Signature Scheme with Short Shares 11/03/2019 11/19



Construction (cont.)

Distributing the system using specific properties of our HSPS:

▶ Key-homomorphism: For any M⃗, given σ1 ← Sign(sk1, M⃗) and σ2 ← Sign(sk2, M⃗), anyone can
compute σ ← Sign(sk1 + sk2, M⃗)

⇒ Convenient for non-interactive threshold signing
(reconstruction via interpolation in the exponent)

▶ In the security proof, the private key is known at any time

⇒ Allows handling adaptive corruption queries.

Fabrice Mouhartem Fully Distributed Non-Interactive Adaptatively-Secure Threshold Signature Scheme with Short Shares 11/03/2019 11/19



Construction (cont.)

▶ Key is generated using Pedersen’s distributed key generation (DKG) protocol (Eurocrypt’91)

Only one round without faulty players

…but does not guarantee uniform keys, even for static adversaries
(Gennaro-Jarecki-Krawczyk-Rabin, Eurocrypt’99)

⇒ Reductions from a centralized scheme are impossible

▶ It is sometimes possible to prove security using direct proofs
(Gennaro-Jarecki-Krawczyk-Rabin, CT-RSA’03)

This approach is more suitable for optimized constructions

Fabrice Mouhartem Fully Distributed Non-Interactive Adaptatively-Secure Threshold Signature Scheme with Short Shares 11/03/2019 12/19



Construction (cont.)

▶ Based on bilinear maps (a.k.a. pairings)

e : G× Ĝ→ GT

such that

e(ga, ĥb) = e(gb, ĥa) = e(g, ĥ)ab ∀g ∈ G, ĥ ∈ Ĝ, a,b ∈ Z

▶ We assume the hardness of the Decision Diffie-Hellman (DDH problem) in G and Ĝ:

Definition (DDH Problem)
In a cyclic group G = ⟨g⟩ of order p, given (g, ga, gb, T) ∈ G4, decide whether T = gab or T ∈R G

(Coincides with the K-linear assumption for K = 1)

Fabrice Mouhartem Fully Distributed Non-Interactive Adaptatively-Secure Threshold Signature Scheme with Short Shares 11/03/2019 13/19



Outline of the Scheme

▶ Public key is
PK =

(
ĝ, ĥ, {ĝk = ĝak · ĥbk}2k=1

)
∈ Ĝ4

and SK = {(ak,bk)}2k=1 is shared as SKi = {(Ak(i),Bk(i))}2k=1 using

Ak[X] = ak0 + ak1X+ ¡ ¡ ¡+ aktXt, Bk[X] = bk0 + bk1X+ ¡ ¡ ¡+ bktXt

▶ Player i computes (H1,H2) = H(M) ∈ G2 and

(zi, ri) =
( 2∏

k=1

HAk(i)
k ,

2∏
k=1

HBk(i)
i

)
.

For any (t+ 1)-set S ⊂ {1, . . . ,n}, partial signatures {(zi, ri)}i∈S yield

(z, r) =
(∏

i∈S

z∆i,S(0)
i ,

∏
i∈S

r∆i,S(0)
i ),

such that e(z, ĝ) · e(r, ĥ) ·
∏2

k=1 e(Hk, ĝk) = 1GT

Fabrice Mouhartem Fully Distributed Non-Interactive Adaptatively-Secure Threshold Signature Scheme with Short Shares 11/03/2019 14/19



Outline of the Scheme

▶ Public key is
PK =

(
ĝ, ĥ, {ĝk = ĝak · ĥbk}2k=1

)
∈ Ĝ4

and SK = {(ak,bk)}2k=1 is shared as SKi = {(Ak(i),Bk(i))}2k=1 using

Ak[X] = ak0 + ak1X+ ¡ ¡ ¡+ aktXt, Bk[X] = bk0 + bk1X+ ¡ ¡ ¡+ bktXt

▶ Player i computes (H1,H2) = H(M) ∈ G2 and

(zi, ri) =
( 2∏

k=1

HAk(i)
k ,

2∏
k=1

HBk(i)
i

)
.

For any (t+ 1)-set S ⊂ {1, . . . ,n}, partial signatures {(zi, ri)}i∈S yield

(z, r) =
(∏

i∈S

z∆i,S(0)
i ,

∏
i∈S

r∆i,S(0)
i ),

such that e(z, ĝ) · e(r, ĥ) ·
∏2

k=1 e(Hk, ĝk) = 1GT

Fabrice Mouhartem Fully Distributed Non-Interactive Adaptatively-Secure Threshold Signature Scheme with Short Shares 11/03/2019 14/19



Outline of the Scheme

▶ Public key is
PK =

(
ĝ, ĥ, {ĝk = ĝak · ĥbk}2k=1

)
∈ Ĝ4

and SK = {(ak,bk)}2k=1 is shared as SKi = {(Ak(i),Bk(i))}2k=1 using

Ak[X] = ak0 + ak1X+ ¡ ¡ ¡+ aktXt, Bk[X] = bk0 + bk1X+ ¡ ¡ ¡+ bktXt

▶ Player i computes (H1,H2) = H(M) ∈ G2 and

(zi, ri) =
( 2∏

k=1

HAk(i)
k ,

2∏
k=1

HBk(i)
i

)
.

For any (t+ 1)-set S ⊂ {1, . . . ,n}, partial signatures {(zi, ri)}i∈S yield

(z, r) =
(∏

i∈S

z∆i,S(0)
i ,

∏
i∈S

r∆i,S(0)
i ),

such that e(z, ĝ) · e(r, ĥ) ·
∏2

k=1 e(Hk, ĝk) = 1GT

Fabrice Mouhartem Fully Distributed Non-Interactive Adaptatively-Secure Threshold Signature Scheme with Short Shares 11/03/2019 14/19



Security

Theorem
In the ROM, the fully distributed scheme is adaptively secure (under chosen-message attacks) if
the DDH problem is hard in G and Ĝ

Proof idea:

▶ PK =
(
ĝ, ĥ, {ĝak ĥbk}2k=1

)
reveals limited information about {(ak,bk)}2k=1

▶ For any message M, two distinct signatures allow breaking DDH in Ĝ

▶ Strategy: get the adversary to produce a different forgery σ⋆ than the reduction’s for M⋆

▶ Problem: PK is not uniform

▶ For each k ∈ {1, 2}, (ak,bk) = (ak,G + ak,Q\G ,bk,G + bk,Q\G)

▶ Key homomorphism allows turning a forgery for the private key {(ak,bk)}2k=1 into a forgery for
the key {(ak,G ,bk,G)}2k=1

Fabrice Mouhartem Fully Distributed Non-Interactive Adaptatively-Secure Threshold Signature Scheme with Short Shares 11/03/2019 15/19



Security

Theorem
In the ROM, the fully distributed scheme is adaptively secure (under chosen-message attacks) if
the DDH problem is hard in G and Ĝ

Proof idea (cont.):

▶ Other problem: make sure that signing queries do not leak too much information on
{(ak,G ,bk,G)}2k=1

▶ Program H : {0, 1}∗ → G2 so that

H(M⋆) ∈R G2 for the forgery message M⋆

H(M) ∈ G2 lives in a 1-dimensional subspace of G2 for each M ̸= M⋆

Change not noticeable if DDH is hard in G

▶ With probability Θ(1/q), the reduction gets two distinct signatures for a uniform key
{(ak,G ,bk,G)}2k=1

Fabrice Mouhartem Fully Distributed Non-Interactive Adaptatively-Secure Threshold Signature Scheme with Short Shares 11/03/2019 16/19



Performances

Algorithm Dist-KeyGen Share-Sign Combine Verify
( 1, 2) 26 2 23 11
( 5,11) 787 13 69 11
(11,20) 4 371 22 137 12
(26,51) 202 763 112 493 13

Table 1: PoC implementation results for (t, n)-threshold signatures in ms

Remarks on the implementation:

▶ It is a proof of concept implementation in C++ and is not optimized
▶ It is sequential and does not capture parallel computations
▶ Uses a wrapper on the Relic toolkit for pairing computations

Source code available: https://gitlab.inria.fr/fmouhart/threshold-signature

Fabrice Mouhartem Fully Distributed Non-Interactive Adaptatively-Secure Threshold Signature Scheme with Short Shares 11/03/2019 17/19

https://gitlab.inria.fr/fmouhart/threshold-signature


Summary

▶ Our results: an optimized threshold construction from pairings

First adaptively secure non-interactive threshold signatures with

• Robustness, O(1)-size private key shares, no erasures

• One-round distributed key generation

• Short signatures (i.e., 512 bits at the 128-bit security level) in the ROM

The construction can be made proactive (Ostrovsky-Yung, PODC’91)

▶ Open problems:

Construction in the standard model with short public parameters

Constructions based on the hardness of search (rather than decision) problems
(e.g., RSA or computational Diffie-Hellman)

Fabrice Mouhartem Fully Distributed Non-Interactive Adaptatively-Secure Threshold Signature Scheme with Short Shares 11/03/2019 18/19



Thank you for your attention.

Fabrice Mouhartem Fully Distributed Non-Interactive Adaptatively-Secure Threshold Signature Scheme with Short Shares 11/03/2019 19/19


	Security notions: chosen-message security under adaptive corruptions
	Construction in the Random Oracle Model
	A Construction in the standard model

";"""pdf:unmappedUnicodeCharsPerPage"",""1"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""Fully Distributed Non-Interactive Adaptively-Secure Threshold Signature Scheme with Short Shares: Efficiency Considerations and Implementation""
""xmp:CreatorTool"",""LaTeX with Beamer class""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dc:creator"",""BenoĂŽt Libert, Marc Joye, Moti Yung, Fabrice Mouhartem ""
""dcterms:created"",""2019-03-11T03:40:01Z""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""title"",""Fully Distributed Non-Interactive Adaptively-Secure Threshold Signature Scheme with Short Shares: Efficiency Considerations and Implementation""
""pdf:docinfo:creator_tool"",""LaTeX with Beamer class""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""Fully Distributed Non-Interactive Adaptively-Secure Threshold Signature Scheme with Short Shares: Efficiency Considerations and Implementation""
""pdf:hasMarkedContent"",""false""
""Content-Type"",""application/pdf""
""pdf:docinfo:creator"",""BenoĂŽt Libert, Marc Joye, Moti Yung, Fabrice Mouhartem ""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""BenoĂŽt Libert, Marc Joye, Moti Yung, Fabrice Mouhartem ""
""meta:author"",""BenoĂŽt Libert, Marc Joye, Moti Yung, Fabrice Mouhartem ""
""meta:creation-date"",""2019-03-11T03:40:01Z""
""created"",""2019-03-11T03:40:01Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""27""
""Creation-Date"",""2019-03-11T03:40:01Z""
""resourceName"",""2019-03-11.NTCW.pdf""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""468"",""766"",""215"",""527"",""527"",""714"",""714"",""750"",""543"",""543"",""576"",""576"",""576"",""689"",""573"",""472"",""472"",""546"",""438"",""499"",""499"",""499"",""631"",""579"",""563"",""617"",""145""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""Author"",""BenoĂŽt Libert, Marc Joye, Moti Yung, Fabrice Mouhartem ""
""producer"",""XeTeX 0.99999""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""XeTeX 0.99999""
""pdf:docinfo:created"",""2019-03-11T03:40:01Z""
";https://scholar.google.com/scholar?start=710&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094623-1010;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[PDF][PDF] QOS AND DEFENSE ENHANCEMENT USING BLOCK CHAIN FOR FLY WIRELESS NETWORKS;N Bhalaji ; Journal of trends in Computer Science and Smart …, 2019  researchgate.net;;"… Valdeolmillos, et al [2] the paper address the challenges in the different types of the crypto

currencies with the highest capitalization in the market and also … ""Trust management in a

blockchain based fog computing platform with trustless smart oracles."" Future …";Cité 8 fois;Les 2 versions;[PDF] researchgate.net;https://www.researchgate.net/profile/Bhalaji_Natarajan2/publication/337649800_QOS_AND_DEFENSE_ENHANCEMENT_USING_BLOCK_CHAIN_FOR_FLY_WIRELESS_NETWORKS/links/5e1acfaa4585159aa4c8c86d/QOS-AND-DEFENSE-ENHANCEMENT-USING-BLOCK-CHAIN-FOR-FLY-WIRELESS-NETWORKS.pdf;;;https://scholar.google.com/scholar?start=820&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094640-1075;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[PDF][PDF] Elastic Smart Contracts across Multiple Blockchains;S Dustdar, P Fernandez, JM García, A Ruiz;Cortés  infosys.tuwien.ac.at;;"… the trustless characteristic of blockchains, an additional agent, namely an oracle, needs to … of the

whole ecosystem; in this particular case, the software oracles are just … Furthermore, glue contracts

need to address possible divergences between blockchain implementations and …";Autres articles;;[PDF] tuwien.ac.at;http://www.infosys.tuwien.ac.at/Staff/sd/papers/FAB_2019_SD_Elastic.pdf;"
Found

The document has moved here.



Apache/2.4.25 (Debian) Server at www.infosys.tuwien.ac.at Port 80

";"""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""dc:title"",""302 Found""
""Content-Encoding"",""ISO-8859-1""
""resourceName"",""FAB_2019_SD_Elastic.pdf""
""language"",""en""
""Content-Length"",""338""
""title"",""302 Found""
""Content-Type"",""text/html; charset=ISO-8859-1""
";https://scholar.google.com/scholar?start=890&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094607-940;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[PDF][PDF] 2 Digital identity protection using blockchain for academic qualification certificates;L Mrsic, G Fijacko, M Balkovic ; Big Data Security, 2019  library.oapen.org;;"… is more powerful than it origi- nally thought, so if Bitcoin as a cryptocurrency does not live … is an

open- source platform that allows you to create or block your own blockchain, and man … 1 operating

system with virtual machine on a single physical server using Oracle VM VirtualBox …";Autres articles;;[PDF] oapen.org;https://library.oapen.org/bitstream/handle/20.500.12657/43819/external_content.pdf?sequence=1#page=23;"
Shibakali Gupta, Indradip Banerjee, Siddhartha Bhattacharyya (Eds.)
Big Data Security



De Gruyter Frontiers in
Computational Intelligence

Edited by Siddhartha Bhattacharyya

Volume 3
Already published in the series

Volume 2: Intelligent Multimedia Data Analysis
S. Bhattacharyya, I. Pan, A. Das, S. Gupta (Eds.)
ISBN 978-3-11-055031-3, e-ISBN (PDF) 978-3-11-055207-2,
e-ISBN (EPUB) 978-3-11-055033-7

Volume 1: Machine Learning for Big Data Analysis
S. Bhattacharyya, H. Baumik, A. Mukherjee, S. De (Eds.)
ISBN 978-3-11-055032-0, e-ISBN (PDF) 978-3-11-055143-3,
e-ISBN (EPUB) 978-3-11-055077-1



Big Data Security

Edited by Shibakali Gupta, Indradip Banerjee,
Siddhartha Bhattacharyya



Editors
Dr. Shibakali Gupta
Department of Computer Science & Engineering, University Institute of Technology
The University of Burdwan
Golapbag North
713104 Burdwan, West Bengal, India
skgupta.81@gmail.com

Dr. Indradip Banerjee
Department of Computer Science & Engineering, University Institute of Technology
The University of Burdwan
Golapbag North
713104 Burdwan, West Bengal, India
ibanerjee2001@gmail.com

Prof. (Dr.) Siddhartha Bhattacharyya
RCC Institute of Information Technology
Canal South Road, Beliaghata
700 015 Kolkata, India
dr.siddhartha.bhattacharyya@gmail.com

ISBN 978-3-11-060588-4
e-ISBN (PDF) 978-3-11-060605-8
e-ISBN (EPUB) 978-3-11-060596-9
ISSN 2512-8868

Library of Congress Control Number: 2019944392

Bibliographic information published by the Deutsche Nationalbibliothek
The Deutsche Nationalbibliothek lists this publication in the Deutsche Nationalbibliografie;
detailed bibliographic data are available on the Internet at http://dnb.dnb.de.

Š 2019 Walter de Gruyter GmbH, Berlin/Boston
Typesetting: Integra Software Services Pvt. Ltd.
Printing and binding: CPI books GmbH, Leck
Cover image: shulz/E+/getty images

www.degruyter.com

An electronic version of this book is freely available, thanks to the support of libra-
ries working with Knowledge Unlatched. KU is a collaborative initiative designed to 
make high quality books Open Access. More information about the initiative can be 
found at www.knowledgeunlatched.org

This work is licensed under the Creative Commons Attribution-NonCommercial-NoDerivs 4.0 License, 
as of February 23, 2017. For details go to http://creativecommons.org/licenses/by-nc-nd/4.0/.

http://dnb.dnb.de
http://www.degruyter.com


Dr. Shibakali Gupta would like to dedicate this book to his daughter, wife & parents.

Dr. Indradip Banerjee would like to dedicate this book to his son, wife & parents.

Prof. (Dr.) Siddhartha Bhattacharyya would like to dedicate this book to his parents
Late Ajit Kumar Bhattacharyya and Late Hashi Bhattacharyya, his beloved wife
Rashni, and his youngest sister’s parents-in-laws Late Anil Banerjee and Late
Sandhya Banerjee.





Preface

With the advent of a range of data-driven avenues and explosion of data, research
in the field of big data has become an important thoroughfare. Big data produces
exceptional amounts of data points, which give greater insights that determine sen-
sational research, better business decisions, and greater value for customers. To ac-
complish these endings, establishments need to be able to handle the data while
including measures for using sensitive private information efficiently and quickly,
and thus the implementation of security issue creates a vigorous role. End-point de-
vices create the main factors for observance of the big data. Processing, storage,
and other necessary responsibilities have to be performed with the help of input
data, which is generated by the end-points. Therefore, an association should make
sure to use an authentic and valid end-point security. Due to large amounts of data
generation, it is quite impossible to maintain regular checks by most of the estab-
lishments. Therefore, periodic observation and performing security checks can be
utmost promising in real time. On the other hand, cloud-based storage has enabled
data mining and collection. However, this big data and cloud storage incorporation
have introduced concerns for data secrecy and security threats.

This volume intends to deliberate some of the latest research findings regarding
the security issues and mechanisms for big data. The volume comprises seven well-
versed chapters on the subject.

The introductory chapter provides a brief and concise overview of the subject
matter with reference to the characteristics of big data, the inherent security con-
cerns, and mechanisms for ensuring data integrity.

Chapter 2 deals with the motivation for this research that came from lack of
practical applications of block chain technology, its history, and the principle of
how it functions within the digital identity and importance of EDU certificate trans-
parency and challenges in their sharing. In the theoretical part of the chapter, a
comparison of the “classical” identity and digital identity is set out, which is de-
scribed through examples of personal identity cards and e-citizen systems. Then,
following the introduction into block chain technology and describing the method
of achieving consensus and transaction logging, the principle of smart contracts is
described, which provide the ability to enter code or even complete applications
and put them into block chains, enabling automation of a multitude of processes.
The chapter also explains common platforms through examples that are described
as business models that use block chain as a platform for developing their pro-
cesses based on digital identity.

Chapter 3 describes the anomaly detection procedure in cloud database metric.
Each and every big data source or big database needs a security metric monitoring.
The monitoring software collects various metrics with the help of custom codes,
plugging, and so on. The chapter describes the approach of modifying the normal
metric thresholding to anomaly detection.

https://doi.org/10.1515/9783110606058-201

https://doi.org/10.1515/9783110606058-201


With the tangible and exponential growth of big data in various sectors,
every day-to-day activities like websites traversed, locations visited, movie timings,
and others were stowed by various companies such as Google through Android cell
phone. Even bank details are accessible by Google. In such situations, wherein a
person’s identity can be mentioned almost completely by just a small number of
datasets, the security of those datasets is of huge importance especially in terms of
situations where human manipulations are involved. Using social engineering to re-
trieve few sensitive information could lead to completely rip off a person’s identity
and his/her personal life. Chapter 4 deals with similar facts, that is, social engineer-
ing angle of hacking for big data along with other hacking methodologies that can
be used for big data and how to secure the systems from the same. This chapter
helps the users to visualize major vulnerabilities in data warehousing systems for
big data along with an insight of major such hacking in recent past, which lead to
disclosure of major private and sensitive data of millions of people.

Chapter 5 describes the information hiding technique as well as consumptions
of this one in big data. Global communication has no bounds and more information
is being exchanged over the public medium that serves an important role in the
communication mode. The rapid growth in the usage of sensitive information ex-
change through the Internet or any public platform causes a major security concern
in these days. More essentially, digital data has given an easy access to communica-
tion of its contents that can also be copied without any kind of degradation or loss.
Therefore, the urgency of security during global communication is obviously quite
tangible nowadays.

Some of the big data security Issues have been discussed in Chapter 6 with
some solution mechanisms. Big data is a collection of huge sets of data of different
categories, where it could be distinguished as structured and unstructured ways. As
are revolutionizing to zeta bytes from Giga/Tera/Peta/Exabytes in this phase of
computing, the threats have also increased in parallel. Big data analysis is flattering
essential means for automatic determination of astuteness that is concerned in the
recurrently stirring outline and secreted convention. This can facilitate companies
to obtain an improved resolution, to envisage and recognize revolution, and to cate-
gorize new fangled prospects. Dissimilar procedure in support of big data analysis
as well as numerical analysis, batch processing, machine learning, data mining, in-
telligent investigation, cloud computing, quantum computing, and data stream pre-
paring become possibly the most important factor.

Chapter 7 summarizes the main contributions and findings of the previously
discussed chapters and offers future research directions. A conclusion has also
been derived out on possible scope of extension or future direction. In this book,
several security issues have been addressed in big data domain.

The book is targeted to meet the academic and research interests of the big
data community. It would come to use to students and faculty members involved
in the disciplines of computer science, information science, and communication

VIII Preface



engineering. The editors would be more than happy if the readers find it useful in
exploring further ideas in this direction.

Shibakali Gupta
October 2019 Indradip Banerjee
Kolkata, India Siddhartha Bhattacharyya

Preface IX





Contents

Preface VII

List of Contributors XIII

Shibakali Gupta, Indradip Banerjee, Siddhartha Bhattacharyya
1 Introduction 1

Leo Mrsic, Goran Fijacko and Mislav Balkovic
2 Digital identity protection using blockchain for academic qualification

certificates 9

Souvik Chowdhury and Shibakali Gupta
3 Anomaly detection in cloud big database metric 25

Shibakali Gupta, Ayan Mukherjee
4 Use of big data in hacking and social engineering 47

Srilekha Mukherjee, Goutam Sanyal
5 Steganography, the widely used name for data hiding 75

Santanu Koley
6 Big data security issues with challenges and solutions 95

Shibakali Gupta, Indradip Banerjee, Siddhartha Bhattacharyya
7 Conclusions 143





List of Contributors

Ayan Mukherjee
Cognizant, Kolkata, India
mukherjeeayan16@gmail.com

Goran Fijacko
Algebra University College, Zagreb, Croatia
gfijacko@gmail.com

Goutam Sanyal
National Institute of Technology, Durgapur,
India
nitgsanyal@gmail.com

Indradip Banerjee
Department of Computer Science &
Engineering
University Institute of Technology,
The University of Burdwan
Burdwan, West Bengal, India
ibanerjee2001@gmail.com

Leo Mrsic
Algebra University College, Zagreb, Croatia
leo.mrsic@algebra.hr

Mislav Balkovic
Algebra University College, Zagreb, Croatia
mislav.balkovic@algebra.hr

Santanu Koley
Department of Computer Science and
Engineering
Budge Budge Institute of Technology,
Kolkata, India
santanukoley@yahoo.com

Shibakali Gupta
Department of Computer Science &
Engineering
University Institute of Technology,
The University of Burdwan
Burdwan, West Bengal, India
skgupta.81@gmail.com

Siddhartha Bhattacharyya
RCC Institute of Information Technology,
Kolkata, India
dr.siddhartha.bhattacharyya@gmail.com

Souvik Chowdhury
Oracle India, Bangalore, India
souvikcho@gmail.com

Srilekha Mukherjee
National Institute of Technology, Durgapur,
India
srilekha.mukherjee3@gmail.com

https://doi.org/10.1515/9783110606058-202

https://doi.org/10.1515/9783110606058-202




Shibakali Gupta, Indradip Banerjee, Siddhartha Bhattacharyya

1 Introduction

Security is one of the leading accomplishment of awareness in information technol-
ogy and communication system. In the contemporary communication epoch, digital
channels are used to communicate hypermedia content, which governs the field of
arts, entertainment, education, commerce, research, and so on. The users of the
field of the digital media technology are increasing massively, and they realized
that data on web is an extremely important aspect of modern life.

Devising discoursed certain security issues, there exist some chief principles.
Privacy principles specify that only sender and the receiver have a duty to be able
to access the message from the web. No other unsanctioned creature can access
this one. Authentication apparatuses help to launch the proof of identity. The au-
thentication confirms that the origin of a digital message is correctly recognized.
When the content of the message is altered after directing by the sender and be-
fore obtaining by the receiver, the uprightness of the message is lost. Access con-
trol regulates who should be able to admit the system and what. It has two areas:
role and rule management.

The digital data content includes audio, video, and image media, which can be
easily stored and manipulated. The superficial transmission and manipulation of dig-
ital content constitute an authentic threat to multimedia content engenderers and
traders.

Big data is a term that is used to explain datasets that are enormous in size
against normal database. Big data is becoming more and more popular each day. Big
data generally consists of unstructured, semistructured, or structured datasets. Some
algorithms as well as tools are used to process these data within the reasonable finite
amount of time, but the main prominence is known on the unstructured data [1].

The characteristics of big data mainly depend on 4Vs (volume, velocity, variety,
veracity) [2, 3]. Volume is a key characteristic of big data, which decides whether the
information is a normal dataset or not, the size of raw data or the data generated is
important because the time complexity, specifications cost which depend on it.
Velocity is the speed with a direction, which means the throughput or the speed of
the data processed. How fast the information can be generated in real time is to meet
the requirements. Variety is important in this literature because it stands for the qual-
ity and the type of data required in order to process it successfully. Data can be text,
audio, video, image, and so on. The quality of data on which the processing will be
done is vital, because if the information is corrupted or stolen then anybody can’t
expect accurate result from it.

https://doi.org/10.1515/9783110606058-001

https://doi.org/10.1515/9783110606058-001


To resolve these potential threats, the awareness of “Information Hiding” has
been weighed [4, 5]. The idiom Information Hiding is discussed to construct the in-
formation undetectable as well as keeping the survival of the information secret.
According to the Oxford English Dictionary [6], the implication of information is the
“formation or molding of the mind or character, training, instruction, teaching.”
This word is originated in the fourteenth century for English and some other
European languages. The theories of cryptography [7] and watermarking [8] were
also developed after the birth of the information concept. But elevating computa-
tional supremacy of those has been developed with the generation of modern-day
cryptographic and watermarking algorithms.

The word “Security” is not identically synonymous what it was in 10 years back,
because the research in capsizal engineering techniques has incremented the proc-
essing power and the most important race between the study in cryptanalysis [9] and
watermarking detection [10]. To solve the above specified problems, the concepts of
steganography [11] has been proposed by the researchers. Steganography diverges
from cryptography. Cryptography refers to a secure communication, which trans-
mutes the data into a concrete form and for that reason an eavesdropper can’t under-
stand it. Steganography techniques can endeavor to obnubilate the subsistence of
the message itself, so that an observer or eavesdropper does not know that the infor-
mation is present or not.

The term big data is used for large and complex dataset, which systematically
analyzes and processes data easily with a lesser amount of time ensemble. The key
responsibility of big data is data capturing and storage, searching of data through
several behaviors, sharing and transfer of information, data analysis, querying like
visualization, updating, and so on. Thus the security of information is very much
important in this terminology. From these points of view, the big data security is
very challenging in this literature.

In the last few decades, researchers, engineers, and scientists have developed
new models, techniques, and algorithms for the generation of robust security system
and better analysis principle. Nowadays, the researchers used different methodologies
for achieving better performance as well as improving the privacy of the hidden infor-
mation. This book investigates the current state-of-the-art big data security systems.

There are different types of information in today’s world, which are in the form
of Text information, Digital Image or Video Frames related information and infor-
mation of Audio signal additionally. This book aims at contributing toward the un-
derstanding of big data security in the form of Text and Digital Images through
various security principles which addresses both the theoretical parts and practical
observations. In this book, a throughout mathematical restorative has been carried
out for achieving better security models.

The book has been organized into eight chapters. Following is a brief descrip-
tion of each chapter:

2 Shibakali Gupta, Indradip Banerjee, Siddhartha Bhattacharyya



Chapter 2: Digital identity protection using
blockchain for academic qualification certificates

This chapter deals with the motivation for this research came from lack of practical
applications of block chain technology, its history, and the principle of how it func-
tions within the digital identity and importance of EDU certificate transparency and
challenges in their sharing. In the theoretical part of the chapter, a comparison of the
“classical” identity and digital identity is set out, which is described through exam-
ples of personal identity cards and e-citizen systems. Then, following the introduc-
tion into block chain technology and describing the method of achieving consensus
and transaction logging, the principle of smart contracts is described, which provides
the ability to enter code or even complete applications and put them into block
chains, enabling automation of a multitude of processes. This chapter explains com-
mon platforms through examples describing business models that use block chain as
a platform for developing their processes based on digital identity. Also, traditional
models with those based on smart deals have been compared. Through examples of
cancelation or delays in air travel, voting, music industry, and tracking of personal
health records, it was established that how existing models are actually sluggish, in-
effective, and prone to manipulation, and through examples of block chain imple-
mentation, they showed that these systems functioned faster, more transparent, and
most importantly, safer. The application of technology in several industries, from the
Fintech industry to the insurance and real estate industry, is also described in this
chapter. Concepts and test solutions are described, which are slowly implemented in
the production phase and show excellent results. For this reason, we believe that sim-
ilar solutions will implement increasing adoption of block chain technology globally.
In the last, practical part of the chapter, a survey of existing solutions that offer crea-
tion of its own block chain and a multichain platform was selected. By having easy to
apply and understand guidelines, it is easier for wider audience to accept and use/
reuse sometimes complex digital concepts as part of their solutions and business
processes.

Chapter 3: Anomaly detection in cloud big database
metric

This chapter describes the anomaly detection procedure in cloud database metric.
Each and every big data source or big database needs a security metric monitoring.
The monitoring software collects various metrics with the help of custom codes,
plugging, and so on. The chapter describes the approach of modifying the normal
metric thresholding to anomaly detection. In this concept, system administration

1 Introduction 3



possesses a common problem to deal with some intelligent alarm method, which
can produce predictive warnings, that is, the system can detect any anomalies or
problems before it occurs. The novel concept detects all the anomalies by analyzing
previous metric data continuously. The chapter also deals with the power exponen-
tial moving average and exponential moving standard deviation method to produce
an effective solution. The work has been tested on CPU utilization and memory uti-
lization of big database servers, which reflects the real-time quality of the solution.

Chapter 4: Use of big data in hacking and social
engineering

With the tangible and exponential growth of big data in various sectors, every day-to-
day activities like websites traversed, locations visited, movie timings, and so on were
stowed by various companies such as Google through Android cell phone. Even bank
details are accessible by Google.

In such situation, wherein a person’s identity can be mentioned almost completely
by just few datasets, the security of those datasets is of huge importance especially in
terms of situations where human manipulations are involved. Using social engineering
to retrieve few sensitive information could lead to completely rip off a person’s identity
and his personal life.

This chapter deals with similar facts, that is, social engineering angle of hack-
ing for big data along with other hacking methodologies that can be used for big
data and how to secure the systems from the same. This chapter helps users to visu-
alize major vulnerabilities in data warehousing systems for big data along with an
insight of such major hacking in recent past, which lead to disclosure of major pri-
vate and sensitive data of millions of people. The insight provided in this chapter
will help single users and corporates to visualize how their data are at stake and
what precautions they can take to secure them, let it be phishing type of social en-
gineering attack or Scareware type of attacks.

Chapter 5: Steganography, the widely used name
for data hiding

This chapter describes the information hiding technique as well as consumptions of
this one in big data. Global communication has no bounds and more information is
being exchanged over the public medium, which serves an important role in the
communication mode. The rapid growth in the usage of sensitive information ex-
change through the Internet or any public platform causes a major security concern

4 Shibakali Gupta, Indradip Banerjee, Siddhartha Bhattacharyya



these days. More essentially, digital data has given an easy access to communica-
tion of its content that can also be copied without any kind of degradation or loss.
Therefore, the urgency of security during global communication is obviously quite
tangible nowadays. Without the communication medium, the field of technology
seems to downfall. But appallingly, these communications often turn out to be fatal
in terms of preserving the sensitivity of vulnerable data. Unwanted sources hamper
the privacy of the communication and may even annoyance with such data. The
importance of security is thus gradually increasing in terms of all aspects of protect-
ing the privacy of sensitive data. Various concepts of data hiding are hence into
much progress. Cryptography is one such concept, the others being watermarking,
and so on. But to protect the complete data content with some seamlessness, this
chapter incorporates concepts of steganography. The realm of steganography rati-
fies the stated fact to safeguard the privacy of data. Unlike cryptography, steganog-
raphy brings forth various techniques that strive to hide the existence of any
hidden information along with keeping it encrypted. On the other hand, any appar-
ently visible encrypted information is definitely more likely to captivate the interest
of some hackers and crackers. Therefore, precisely saying, cryptography is a prac-
tice of shielding the very contents of the cryptic messages alone. On the other hand,
steganography is seriously bothered with camouflaging the fact that some confiden-
tial information is being sent, along with concealing the very contents of the mes-
sage. Hence, the data hiding in the seemingly unimportant cover medium is
perpetuated. The field of big data is quite into fame these days as they deal with
complex and large datasets. Steganographic methodologies may be used for the
purpose of enhancing security of big data since they also find ways of doing so.

Chapter 6: Big data security issues with challenges
and solutions

Some of the big data security issues have been discussed in this chapter with some
solution mechanism. Big data is a collection of huge sets of data of different catego-
ries, where it could be distinguished as structured and unstructured ways. As are rev-
olutionizing to zeta bytes from Giga/Tera/Peta/Exabytes in this phase of computing,
the threats have also increased in parallel. Big data analysis is flattering essential
means for automatic determination of astuteness that is concerned in the recurrently
stirring outline and secreted convention. This can facilitate companies to obtain an
improved resolution, to envisage and recognize revolutionize, and to categorize new-
fangled prospects. Dissimilar procedure in support of big data analysis as well as
numerical analysis, batch processing, machine learning, data mining, intelligent in-
vestigation, cloud computing, quantum computing, and data stream preparing be-
come possibly the most important factor. There is a gigantic open door for the big

1 Introduction 5



data industry in addition to plenty of possibilities for research and enhancement.
Besides big organizations, cost reduction is the criterion for the use of small- and me-
dium-sized organizations too, thus increasing the security threat. Checking of the
streaming data once is not the solution as security breaches cannot be understood.
The data stack up within the clouds is not the only preference as big data technology
is available for dispensation of both structured and unstructured data. Nowadays an
enormous quantity of data is provoked by mobile phones (Smartphone) of equally
the symphony form. Big data architecture is comprehend among the mobile cloud de-
signed for supreme consumption by means. The best ever implementation is able to
be conked out realistic for the use of a novel data-centric architecture of MapReduce
technology, while HDFS also acts immense liability in using data with divergent ar-
rangement. As time approaches the level of information and data engendered from
different sources, enhanced and faster execution is the claim for the same. Here in
this chapter the aim is to find out big data security vulnerable and also find out the
best possible solutions for them. Considering this attempt will dislodge a stride for-
ward along the way to an improved evolution in secure propinquity to opportunity.

Chapter 7: Conclusions

This chapter summarizes the main contributions and findings of the previously dis-
cussed chapters and offers future research directions. A conclusion has also been
derived out on the possible scope of extension or future direction. In this book, sev-
eral security issues have been addressed in big data domain. The book covers a
wide area of big data security as well as steganography and points to a fairly large
number of ideas, where the concepts of this book may be improvised. Design of nu-
merous big data security concept through steganography has been discussed,
which can meet different requirements like robustness, security, embedding capac-
ity, and imperceptibility. Experimental studies are carried out to compare the per-
formance of these developments. The comparative study of each method along with
the existing method is also established.

References

[1] Snijders, C., Matzat, U., & Reips, U.-D. “‘Big Data’: Big gaps of knowledge in the field of
Internet”. International Journal of Internet Science, (2012), 7(1)

[2] Martin, Hilbert. “Big Data for Development: A Review of Promises and Challenges.
Development Policy Review”. martinhilbert.net. Retrieved 7 October 2015.

[3] DT&SC 7-3: What is Big Data?. YouTube. 12 August 2015.
[4] Cheddad, Abbas., Condell, Joan., Curran, Kevin., & Kevitt, Paul Mc. Digital image steganography:

Survey and analysis of current methods Signal Processing 90, 2010,pp. 727–752.

6 Shibakali Gupta, Indradip Banerjee, Siddhartha Bhattacharyya



[5] Capurro, Rafael., & Hjørland, Birger. (2003). The concept of information. Annual review of
information science and technology (s. 343–411). Medford, N.J.: Information Today. A version
retrieved November 6, 2011.

[6] Anthony Reading. Meaningful Information: The Bridge Between Biology, Brain, and Behavior.
Originally published: January 1, 2011.

[7] Liu, Shuiyin., Hong, Yi., & Viterbo, E. “Unshared secret key cryptography”. IEEE Transactions
on Wireless Communications, 2014, 13(12), 6670–6683.

[8] Hsu, Fu-Hau., Min-Hao, Wu., & WANG, Shiuh-Jeng., “Dual-watermarking by QR-code
Applications in Image Processing”, 2012 9th International Conference on Ubiquitous
Intelligence and Computing and 9th International Conference on Autonomic and Trusted
Computing.

[9] Kaminsky, A., Kurdziel, M., & Radziszowski, S.”An overview of cryptanalysis research for the
advanced encryption standard”, Military Communications Conference, 2010 – MILCOM 2010,
San Jose, CA, Oct.31 2010-Nov.3 2010, 1310–1316, ISSN: 2155-7578

[10] Bian, Yong., & Liang, S. “Locally optimal detection of image watermarks in the wavelet
domain using Bessel K Form distribution”. IEEE Transactions on Image Processing, 2013, 22
(6), 2372–2384.

[11] EL-Emam, N.N. “Hiding a large amount of data with high security using steganography
algorithm,” Journal of Computer Science, 3(4), 223–232, April 2007.

1 Introduction 7





Leo Mrsic, Goran Fijacko and Mislav Balkovic

2 Digital identity protection using
blockchain for academic qualification
certificates

Abstract: Although it was always an important issue, digital era increases the im-
portance of both questions “what identity is” and “why is important to manage and
protect one.” There are many views and definitions of digital identity in the litera-
ture; however, this chapter explains the identity related to the identification of an
individual, his/her qualification, and his/her status in society. Using modern ap-
proach, this chapter focuses on the academic qualification of an individual where
blockchain is presented as an efficient concept for publishing, storing, and verify-
ing educational certificates/diplomas. Motivation for this research came from lack
of practical applications of blockchain and importance of EDU certificate transpar-
ency and challenges in their sharing (policy issues, national standard, etc.). By hav-
ing easy to apply and understand guidelines, it is easier for wider audience to
accept and use/reuse sometimes complex digital concepts as part of their solutions
and business processes. As part of institution research lab, explained approach and
proof of concept solution was developed in Algebra University College.

Keywords: digital identity, blockchain, smart contracts, academic qualification cer-
tificates, certificate Mrsic, Fijacko and Balkovic

2.1 Introduction

If we talk about a classical identity of an individual, we can think of personal identity
card, a birth certificate, a driving license but also a university certificate/diploma or
other EDU certificate. In terms of the digital identity of an individual, we can talk about
an e-personal ID card, e-birth certificate, e-homepages, e-driver’s license or e-diplomas
[1]. The e-name tag is electronic, which means these documents also have a digital
component. This digital component can be, for example, an electronic data carrier
(chip) that stores certain data or certificates that are readily uploaded to the computer
by a reader if needed. The data being displayed are centralized and are guaranteed by
and responsible to the institution issuing them, where the data is stored [2].

Digital identity does not necessarily have to be a physical document or docu-
ment [3]. It also includes our email addres";"""date"",""2020-04-02T07:44:59Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""1"",""2"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.6""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dcterms:created"",""2020-04-02T07:36:17Z""
""language"",""en""
""Last-Modified"",""2020-04-02T07:44:59Z""
""dcterms:modified"",""2020-04-02T07:44:59Z""
""dc:format"",""application/pdf; version=1.6""
""xmpMM:DocumentID"",""uuid:0d2da0a8-a966-4ae7-a7e9-bccdc47df8ec""
""Last-Save-Date"",""2020-04-02T07:44:59Z""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2020-04-02T07:44:59Z""
""meta:save-date"",""2020-04-02T07:44:59Z""
""pdf:encrypted"",""false""
""xmp:CreateDate"",""2020-04-02T10:36:17Z""
""modified"",""2020-04-02T07:44:59Z""
""Content-Length"",""2160105""
""pdf:hasMarkedContent"",""false""
""Content-Type"",""application/pdf""
""xmp:ModifyDate"",""2020-04-02T10:44:59Z""
""xmp:MetadataDate"",""2020-04-02T10:44:59Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""pdf:producer"",""iTextSharp 5.0.6 (c) 1T3XT BVBA""
""meta:creation-date"",""2020-04-02T07:36:17Z""
""created"",""2020-04-02T07:36:17Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""158""
""Creation-Date"",""2020-04-02T07:36:17Z""
""resourceName"",""external_content.pdf""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""76"",""440"",""78"",""1499"",""360"",""0"",""2670"",""2808"",""191"",""0"",""581"",""0"",""1098"",""0"",""2371"",""2717"",""2375"",""2136"",""2591"",""2416"",""1194"",""0"",""2151"",""1128"",""2501"",""2665"",""1346"",""2610"",""2546"",""2020"",""2340"",""2132"",""1985"",""1059"",""1386"",""1616"",""2653"",""1723"",""2074"",""2782"",""2311"",""1678"",""963"",""929"",""2086"",""1695"",""1522"",""1843"",""2006"",""780"",""1518"",""856"",""1539"",""1264"",""592"",""296"",""1440"",""3134"",""943"",""0"",""2545"",""2550"",""2042"",""2147"",""2509"",""1282"",""2263"",""2161"",""2288"",""2636"",""2324"",""2412"",""2367"",""2019"",""2325"",""2367"",""2562"",""446"",""2148"",""2240"",""1830"",""1282"",""2342"",""1143"",""2886"",""1552"",""2295"",""3011"",""2087"",""2497"",""1802"",""2605"",""2524"",""2659"",""2477"",""2696"",""2154"",""1087"",""1162"",""612"",""2245"",""2251"",""1953"",""3211"",""3101"",""3122"",""495"",""0"",""2123"",""2894"",""2803"",""2488"",""2422"",""1920"",""1493"",""2517"",""953"",""2645"",""1672"",""1809"",""1957"",""1927"",""719"",""2149"",""2093"",""2248"",""2490"",""2077"",""2387"",""2046"",""2197"",""1443"",""2929"",""1627"",""2240"",""2147"",""1918"",""1828"",""2067"",""2321"",""1345"",""1627"",""2285"",""797"",""2286"",""1868"",""2795"",""788"",""2203"",""2333"",""2891"",""1633"",""2477"",""1667"",""3348"",""3114"",""2574"",""1352""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""producer"",""iTextSharp 5.0.6 (c) 1T3XT BVBA""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""iTextSharp 5.0.6 (c) 1T3XT BVBA""
""pdf:docinfo:created"",""2020-04-02T07:36:17Z""
";https://scholar.google.com/scholar?start=750&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094637-1063;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Strong authenticity with leakage under weak and falsifiable physical assumptions;F Berti, C Guo, O Pereira, T Peters… ; … Conference on Information …, 2019  Springer;;"… (\mathsf {Oracle}\) \(mathsf {Vrfy … To model the ability of an adversary to get leakage on tag

generation and verification, we extend the \(\mathsf {FORGE}^{\mathsf {suf}\text {-}\mathsf {vcma}}\)

experiment by allowing the oracles to additionally return the evaluation of \(\mathsf {L} …";Cité 4 fois;Les 3 versions;[PDF] iacr.org;https://eprint.iacr.org/2019/1413.pdf;"
Strong Authenticity with Leakage under Weak and

Falsifiable Physical Assumptions

Francesco Berti1, Chun Guo2, Olivier Pereira1,
Thomas Peters1, and François-Xavier Standaert1

1 ICTEAM/ELEN/Crypto Group, UCL, Louvain-la-Neuve, Belgium
2 School of Cyber Science and Technology and Key Laboratory of Cryptologic

Technology and Information Security, Ministry of Education, Shandong University

Abstract. Authenticity can be compromised by information leaked via side-channels (e.g., power
consumption). Examples of attacks include direct key recoveries and attacks against the tag verification
which may lead to forgeries. At FSE 2018, Berti et al. described two authenticated encryption schemes
which provide authenticity assuming a leak-free implementation of a Tweakable Block Cipher (TBC).
Precisely, security is guaranteed even if all the intermediate computations of the target implementation
are leaked in full but the TBC long-term key. Yet, while a leak-free implementation reasonably models
strongly protected implementations of a TBC, it remains an idealized physical assumption that may
be too demanding in many cases, in particular if hardware engineers mitigate the leakage to a good
extent but (due to performance constraints) do not reach leak-freeness. In this paper, we get rid of
this important limitation by introducing the notion of Strong Unpredictability with Leakage for BC’s
and TBC’s. It captures the hardness for an adversary to provide a fresh and valid input/output pair
for a (T)BC, even having oracle access to the (T)BC, its inverse and their leakages. This definition is
game-based and may be verified/falsified by laboratories. Based on it, we then provide two Message
Authentication Codes (MAC) which are secure if the (T)BC on which they rely are implemented in a way
that maintains a sufficient unpredictability. Thus, we improve the theoretical foundations of leakage-
resilient MAC and extend them towards engineering constraints that are easier to achieve in practice.

1 Introduction

Message Authentication Codes (MAC) are widely used to authenticate data. Efficient MAC
are usually constructed from conceptually simpler symmetric primitives such as (tweakable)
block ciphers (e.g., CBC [5]) and hash functions (e.g., HMAC [5,4]), and enjoy reliable
“provable security guarantees”, i.e., security reductions to the underlying primitives.

Side-channel attacks, since introduced in the 1990s [21,22], have now been recognized
as one of the main real-world security threats (e.g., see [2, chapter 1.2]). In response, var-
ious implementation-level countermeasures have been proposed and even formally proved
effective. However, they typically induce significant overheads. As a complementary, the
methodology of leakage-resilience was proposed [14] and followed by many (see [20] for a sur-
vey). Schemes proved leakage-resilient enjoy security even if a moderate amount of sensitive
information is leaked via side-channels. Consequently, their implementations could leverage
less protected circuits and thus reduce the overall overheads.

It is not a surprise that with leakages, classical MAC such as CBC and HMAC are not se-
cure at all, even if leakages only contain the input/output values of the underlying functions
(see, e.g., [12]). This means their implementations have to be heavily protected when used in
sensitive settings such as the IoT, which may be hard to achieve given application cost con-
straints. Therefore, exploring the construction of leakage-resilient MAC is a natural direction,



which was initiated in [18,24,25,8] and later improved in [9,3,7] to achieve security in the
presence of both tag generation and verification leakages.1 We remark that the premises used
in these works are significantly different. For example, [24,3] leveraged bilinear maps in the
generic group model to ease secret-sharing/masking-based implementations of their MAC,
while [25,8,9,7] model a heavily protected (tweakable) block cipher (e.g., using high-order
masking [15,19]) as leak-free and focus on making the other mode-level leakages harmless.

From the efficiency viewpoint, sticking with simple symmetric primitives is naturally
desirable.2 Yet, a drawback of the aforementioned papers [25,8,9,7] is the use of leak-free
cipher model. Despite it is theoretically possible to reach very high security levels with
masking (approaching black box security [15,19]), it implies (very) high overheads that may
not be acceptable in practice. Besides, the leak-free assumption (that is, nothing is leaked
about the key used and the outputs remain pseudorandom) cannot be accompanied by any
well-defined security game—somewhat resembling the random oracle model.

Our contribution. The goal of this paper is to bridge the above theory gap (i.e., seeking for
some well-defined leakage assumptions on the block cipher that allows the leakage-resilient
MAC security reductions) while also enabling more modular security guarantees that may
degrade gracefully when the physical assumption is respected only to some extent. Our
answer to this challenge is Strong Unpredictability in the presence of Leakages for a (T)BC,
henceforth abbreviated as SUL2. In detail, it captures the hardness of providing a fresh
input/output pair for the (T)BC even having access to its leaking oracle and leaking inverse
oracle (following the notations of [17], the variant without leaking inverse oracle would be
SUL1). It can be viewed as a natural extension of the unpredictable block cipher assumption
introduced by Dodis and Steinberger [12,13].

With this new assumption, we revisit existing (tweakable) block cipher-based leakage-
resilient MAC. We first consider the simplest Hash-then-BC scheme τ = Fk(H(m)), the leakage
security of which was analyzed by Berti et al. [8,9]. While the security reduction seems
straightforward, Berti et al. [9] changed the verification process of Vrfyk(m, τ) from “If τ =
F∗k(H(m)), then return 1” to “If H(m) = F∗,−1k (τ), then return 1” (i.e., leveraging the inverse
F∗,−1k to avoid leaking sensitive information).3 As a result, they achieve better mode-level
leakage-resilience as the intermediate value F∗,−1k (τ) does not have to be protected: even
given this additional value it is still hard to forge a tag. However, their proof relies on leak-
free block ciphers. We show that the SUL2 assumption for F∗ is actually sufficient to obtain
similar guarantees, further assuming an ideal hash H.4 We then revisit the recently proposed
Hash-then-TBC scheme [7], which was also used in the NIST AE submission Spook [6]. In
detail, its tag generation is Tagk(m) = τ = F∗k(h1, h2), where h2 is the tweak of F∗ and
h1‖h2 = H(m) (i.e., the 2n-bit output of H is divided into two halves h1 and h2), while
for verification Vrfyk(m, τ) we compute h̃1 = F∗,−1k (τ, h2) and compare it with h1, with

1 Note that some MACs were parts of authenticated encryption (AE) proposals.
2 The MAC of [24,3] consumes ≈ 4 seconds to generate a tag on a 32-bit ARM.
3 F∗ means that the BC F is implemented in a leak-free way
4 This idealized assumption is used for simplifying our analyzes, since our focus is on the leak-free blocks. We leave

its relaxation as an interesting open problem.

2



h1‖h2 = H(m). We show that using a 2n-bit hash, we can improve the birthday bound of
the previous Hash-then-BC construction.

Both schemes are natural, extremely simple and should be easy to implement for practical
uses. We expect the block cipher based construction (next: HBC) to be slightly more efficient
than the tweakable version (next: HTBC) as a secure TBC typically consumes more rounds
than a secure BC. However, we also note that HBC admits forgery attacks with lower data
complexity (simply utilizing a hash collision), while HTBC solves this problem by doubling
the size of the hash and using a TBC (that has a larger input size) to absorb the digest.

In summary, our results improve the theory foundations for existing efficient (tweakable)
block cipher-based leakage-resilient MAC. We believe the SUL2 assumption could find more
applications in future leakage-resilient analyses. In practice, unpredictability is widely be-
lieved to be more relaxed than PRP [12].5 Thus it potentially enables using reduced-round
(tweakable) BCs for MAC. As the heavily protected ciphers are much more costly than the
hash functions (that do not need protection), they are expected to be the performance bottle-
neck, and reducing the number of rounds may significantly improve the overall performance
(e.g., in terms of latency and energy consumption).

Related work. The idea of basing MAC security on unpredictable ciphers is not new, dating
back to [1] and witnessing recent achievements [12,28,13]. In fact, as argued in [12], it is
natural to consider reducing the unpredictability of the “bigger” MAC to the unpredictability
of the “smaller” ciphers.

2 Background

Notations. A (q1, ..., qd, t)-adversary A in an experiment against Π is an algorithm A having
oracle access to Algo1, ...,Algod, making at most qi queries to oracle Algoi, running in time
bounded by t, and outputting a finite string of bits. The leakage function due to the imple-
mentation of an algorithm Algo is denoted LAlgo. This function might be non deterministic.
A leaking query to Algo is denoted LAlgo and results in running both Algo and LAlgo on the
same input.

The set of binary strings of length n is denoted by {0, 1}n, while the set of all finite
strings by {0, 1}∗. Given two strings, x and y, we let x||y denote the concatenation of these
two strings.

The view of a game consists of all queries made by the adversary to his oracles, the
oracles’ answers and the final output of the adversary. In a transcript every oracle query is
immediately followed by its answer. A value is fresh if it has never appeared in the view.

2.1 Multi-Collisions

Let 1 ≤ s ≤ q ≤ N . We consider the experiment where we uniformly throw q balls at random
into N bins. MultiColl(N, q) ≥ s denotes the event that at least one bin contains at least s
balls. We recall a useful upper-bound on the probability of multi-collisions.

5 Indeed, Unpr can be based on weaker complexity assumptions [11].

3



Theorem 1 ([26]).

Pr[MultiColl(N, q) ≥ s] ≤ 1

N s−1

(
q

s

)
.

We also need the following technical result.

Lemma 1. If 2q ≤ N ,

q∑
s=1

(s− 1) · Pr[MultiColl(N, q) ≥ s] ≤ 1

N

(
q

2

)(
1 +

2q

N

)
.

Proof. Looking at the generic term for s ≥ 3 after applying the theorem leads to

s− 1

N s−1

(
q

s

)
≤ 1

N s−2

(
q

s− 1

)
¡ q
N
≤ 1

N

(
q

2

)
¡
( q
N

)s−2
.

Then, the whole sum is upper-bounded by

1

N

(
q

2

)
¡

q∑
s=2

( q
N

)s−2
≤ 1

N

(
q

2

)
N

N − q
=

1

N

(
q

2

)(
1 +

q

N − q

)
.

Hence, the result since q ≤ N − q. ut

2.2 Cryptographic Primitives

Tweakable block ciphers A tweakable block cipher [23] (TBC) is a function F : K×T W×
X 7−→ Z, where K and T W are respectively called the key space and the tweak space, and
such that for any key k ∈ K and any tweak tw ∈ T W , the function Ftw

k : X 7→ Z;x 7→
Ftw
k (x) := Fk(tw, x) := F(k, tw, x) is a permutation. We denote the inverse of this function

by F−1k,tw so that, if Ftw
k (x) = y, then F−1k (tw, y) := F−1k,tw(y) = x. A Block Cipher (BC) is a

TBC with an empty tweak space: the only tweak is the “empty string”.

Message authentication codes with leakage A message authentication code (MAC) is
a couple of algorithms (Tag,Vrfy), Tag : K ×M 7−→ T and Vrfy : K ×M× T 7−→ {0, 1},
where K, M and T are respectively called the key space, the message space and the tag
space, and such that for any key k ∈ K and any message m ∈M, 1← Vrfyk(m,Tagk(m)).

Definition 1. A MAC = (Tag,Vrfy) is (qT , qV , t, Îľ) strongly existentially unforgeable against
chosen-message and verification attacks, or simply (qT , qV , t, Îľ)-suf-vcma for short, if for all
(qT , qV , t)-adversary A, we have

Pr[FORGEsuf-vcma
A,MAC = 1] ≤ ε

where the FORGEsuf-vcma experiment is defined in Tab. 1.

4



FORGEsuf-vcma
MAC,A experiment.

Initialization: Oracle Tag(m):

k
$← K τ ← Tagk(m)

S ← ∅ S ← S ∪ {(m, τ)}
Return τ

Finalization:

(m, τ)← ATag(·),Vrfy(·,·) Oracle Vrfy(m, τ):
If (m, τ) ∈ S Return 0 Return Vrfyk(m, τ)
Return Vrfyk(m, τ)

Table 1. The FORGEsuf-vcma experiment.

To model the ability of an adversary to get leakage on tag generation and verification,
we extend the FORGEsuf-vcma experiment by allowing the oracles to additionally return the
evaluation of LTag and LVrfy, where L = (LTag, LVrfy) is the leakage function pair due to an
implementation of the MAC. Given an adversary A, we write AL to specify that the adversary
knows the implementation and that it can learn the leakage for chosen keys, which models
any leakage learning phase on other devices with the same implementation.

Definition 2. A MAC = (Tag,Vrfy), whose implementation has leakage function pair L =
(LTag, LVrfy) is (qT , qV , qL, t, Îľ) strongly existentially unforgeable against chosen message and
verification attacks with leakage in tag-generation and verification, or (qT , qV , qL, t, Îľ)-suf-L2,
if for any (qT , qV , qL, t)-adversary A, we have

Pr[FORGE-L2suf-vcma
A,MAC,L = 1] ≤ ε,

where the FORGE-L2suf-vcma experiment is defined in Tab. 2, and where AL makes at most qL
queries to L.

FORGE-L2suf-vcma
MAC,A experiment.

Initialization: Oracle LTag(m):

k
$← K τ ← Tagk(m), `m ← LTag(k,m)

S ← ∅ S ← S ∪ {(m, τ)}
Return (τ, `m)

Finalization:

(m, τ)← ALTag(·),LVrfy(·,·),L Oracle LVrfy(m, τ):
If (m, τ) ∈ S, return 0 `v ← LVrfy(k,m, τ)
Return Vrfyk(m, τ) Return (Vrfyk(m, τ), `v)

Table 2. The FORGE-L2suf-vcma experiment.

Note that the L2 notation is for leakage during both tag generation and verification (the
variant without tag verification leakage would use L1, following [17]).

Unbounded leakage In the rest of this paper, we will consider that all the components
of our system, except for the BC/TBC, have an unbounded leakage. That is, all the I/Os of
these components (the compression function of hash functions, for instance) are offered by
the leakage function. Our paper then focuses on the single component that is not expected to

5



leak its I/Os in full and is used once per MAC computation or tag verification (independently
of the length of the message to be authenticated): the BC/TBC.

3 Unpredictability of leaking TBC

Dodis and Steinberger [12] introduced the definition of unpredictability with leakage for BC.
At a high level, the definition says it is unfeasible to produce a valid input-output couple of
the BC even if we got the leakage besides of the outcome of the computation of the BC on
chosen inputs. We extend this notion by granting the adversary with the inverse oracle of
the BC and its leakage. To save some place, we directly describe this notion for TBCs. We
get the corresponding notion for BCs by removing all the tweaks in the definition below.

We denote by L = (LEval, LInv) the leakage function pair associated to an implementation
of the TBC, where LEval(k, tw, x) (resp. LInv(k, tw, z)) is the leakage resulting from the com-
putation of Fk(tw, x) (resp. F−1k (tw, z)). We also allow the adversary A to profile the leakages
and write AL as before, like in [25].

Definition 3. A tweakable block cipher F : K × T W × X 7−→ Z with leakage function
pair L = (LEval, LInv) is (qE, qI , qL, t, Îľ) strongly unpredictable with leakage in evaluation and
inversion, or (qE, qI , qL, t, Îľ)-SUL2, if for any (qE, qV , qL, t)-adversary A, we have

Pr[SUL2A,F,L ⇒ 1] ≤ ε,

where the SUL2 experiment is defined in Tab. 3, and where AL makes at most qL (offline)
queries to L.

SUL2A,F,L experiment.

Initialization: Oracle LEval(tw, x):

k
$← K z = Fk(tw, x)

L ← ∅ `e = LEval(k, tw, x)
L ← L ∪ {(x, tw, z)}

Finalization: Return (z, `e)

(x, tw, z)← ALEval(·,·),LInv(·,·),L

If (x, tw, z) ∈ L Oracle LInv(tw, z):
Return 0 x = F−1

k (tw, z)
If z == Fk(tw, x) `i = LInv(k, tw, z)

Return 1 L ← L ∪ {(x, tw, z)}
Return 0 Return (x, `i)

Table 3. Strong unpredictability with leakage in evaluation and inversion experiment.

4 First leakage-resilient MAC: HBC

We now revisit one of the most common designs to build a MAC from a hash function H
and a block cipher F. This MAC is the well-known hash-then-BC scheme, named here HBC,
except that we analyze it in a leakage setting and through the lens of the unpredictability of

6



F. As we want to show the security of HBC even when F leaks its inputs and outputs in full,
we just have to tweak the usual verification algorithm by using the inversion of the BC to
avoid leaking valid tags just by processing invalid pairs (m, τ). As mentioned in introduction,
our analysis models H as a random oracle for simplicity and since our focus is on the leak-free
blocks. Yet, it does not suggest any reason why an ideal object would be needed, and its
relaxation is an interesting open problem.

4.1 HBC description

Let M = {0, 1}∗ and X = Z = {0, 1}n. Considering a hash function H : M 7→ X and a
block cipher F : K ×X 7→ Z, we build HBC = (Tag,Vrfy):

Tagk(m): compute h = H(m), then compute and output τ = Fk(h).
Vrfyk(m, τ ): compute h = H(m) and h̃ = F−1k (τ), then

output 1 if h = h′, and 0 otherwise.

We highlight that Tag only evaluates F while Vrfy only computes its inverse. This feature
is at the core of the argument showing that unbounded leakages do not decrease the unforge-
ability of this hash-then-BC design. This idea was already used for the authentication part
of the AE modes DTE2, EDT and FEMALE [9,17]. We illustrate HBC in Fig. 1.

Fig. 1. The leakage resilient MAC HBC. Leakage reveals the orange value.

4.2 Security of HBC

In the unbounded leakage model, the adversary receives all the ephemeral values computed
during the tag generation and the verification. Only the key of the BC, which is the key of the
MAC, remains hidden as implicitly defined by the leakage function pair of its implementation
L = (LEval, LInv). More precisely, the unbounded leakage function pair L∗ = (L∗Tag, L

∗
Vrfy) of HBC

is thus:

7



L∗Tag(k,m): return h = H(m) and LEval(k, h);

L∗Vrfy(k,m, τ): return h = H(m) and h̃ = F−1k (τ) as well as LInv(k, τ).

Despite H is a public function, we explicitly include its outputs in the leakage. It can be
considered as redundant but, as we rely on a random oracle to prove the security of HBC,
we prefer making them fully available to avoid any confusion.

Theorem 2. Let F : K × {0, 1}n 7−→ {0, 1}n be a (qT , qV , qL, t, εSUL2)-strongly unpredictable
block cipher in the presence of leakage, and H : S × {0, 1}∗ 7−→ {0, 1}n be a hash function
modeled as a random oracle that is queried at most qH times, then, HBC is a (qT , qV , qL, t, Îľ)-
strongly unforgeable MAC in the unbounded leakage setting, with L∗ = (L∗Tag, L

∗
Vrfy) defined

above, where

ε ≤ (qH + qV + 1)(qV + 1)εSUL2 + (qH + qT + qV + 1)2/2n,

and tH(qH + qT + qV + 1) + (qT + qL − q)tF + (qV + q)tF−1 ≤ t for any q ≤ qL, and where
we assume that all the H-query involved in the qL queries are already among the qH queries,
and if qV ≤ qH (which can be artificially fulfilled at the end of the experiment).

The advantage is bounded by 2qHqV εSUL2 + 4q2H2−n under the natural assumption qT +
qV + 1 ≤ qH (since qT and qV correspond to online queries while qH corresponds to offline
queries, it is expected to hold comfortably). The leading term is 2qHqV εSUL2: for εSUL2 = 2−128,
it implies that security holds up to qH = 264 and qV = 263 (i.e., slightly below the birthday
bound). For a more realistic εSUL2 = 2−96, it only holds with a stronger limit on the number
of verification queries (e.g., qH ≈ 264 and qV = 231). Note that the factor qHqV may be
due to the reduction proof technique, as it relates to a case where the adversary is likely to
produce a forgery early in the experiment and therefore much of the computational power
of the reduction seems useless to the adversary. Hence, it might be possible to obtain tighter
bounds using a different reduction approach. It would also be interesting to explore the
possibility of making a proof based on standard assumptions on the hash function. Such
assumptions would require to exclude damaging and implausible interactions between the
hash function and the PRF, and would be an interesting area for future research.

Idea of the proof. Assuming that an adversary A succeeds in the FORGE-L2suf-vcma
A,HBC,L∗ exper-

iment by making a total of qT leaking tag queries and qV leaking verification queries, let
(m, τ) be the forgery, i.e., the couple returned by A in the finalization phase. To bound this
winning probability, we partition this event into sub events: (1) The tag τ appears in the
answer to a leaking tag query (and thus, as an output of Fk); (2) The tag τ never appears in
the answer to a leaking tag query (and thus, τ can only be involved as an input of F−1k ) and:
(a) m appears as an input of H before F−1k (τ) was ever computed in the experiment; (b) τ
appears as an input of F−1k before H(m) was ever computed in the experiment. We cover
all the cases since when both m and τ are fresh in a verification query, we always compute
(or ask the computation of) H(m) first so that we can say that m appears “before” (the
computation of F−1k on input) τ , and since we view the last verification in the finalization as
the (qV + 1)-th verification query.

8



The goal of the proof is to show that the collision resistance of H ensures that winning
in case 1 is negligible, the unpredictability of F ensures that winning in case 2a is negligible
and that preimage resistance of H ensures that winning in case 2b is negligible as well.

In case 1, there is a tag query on m′ which defines τ = Fk(H(m′)). Since (m, τ) is a
forgery we have Fk(H(m)) = τ with m 6= m′. Then, m and m′ produce a collision as Fk is a
permutation: H(m) = F−1k (τ) = H(m′).

In case 2a, we assume that F is SUL2-secure. Since m appears before τ , as a challenger
we have to use the value h = H(m) and we “wait” for the good tag in a verification query
to win the SUL2 game. We do not have to consider the message for which A makes a tag
query. However, we cannot know in advance what will be the right tag and we cannot wait
until the finalization of the unfogeability experiment because even if A’s output (m, τ) is the
right pair, τ may have been already used in a previous verification query. If so, the challenger
should have already made a leaking inverse query of the block cipher with input τ to get
h̃ = F−1k (τ) and `i ← LInv(k,m) to simulate LVrfy(m, τ), and it could no more win the game
against F with τ . Therefore, for all possible m involved in a H-query or a verification query,
we have to guess what will be the right τ in verification. Then, we need to consider all the
possible such pairs and we thus have to make at most (qH + qV + 1)(qV + 1) reductions.

In case 2b, the reduction can generate the key k itself and then evaluate F and its inverse
by itself. The first time τ appears (in a leaking verification query) we define the H-target
h̃ = F−1k (τ) since the winning corresponding m is still not hashed by assumption. Note that
we even do not care whether h̃ already appeared or not in a response to an H-query since
fresh queries will result in independent hashes. Therefore, the validity of (m, τ) means that
m is a preimage of h̃, as H(m) = F−1k (τ), while H(m) is random.

Proof. To prove the theorem, we use a sequence of games. Given an adversary A, we start
with Game 0 which is the FORGE-L2suf-vcma

A,HBC,L∗ experiment and we end with a game where all
the leaking verification queries deem the given input pair (mi, τi) invalid, including the last
verification at the finalization which is the (qV + 1)-th verification query by convention.

Game 0. This game is depicted in Tab 2. Let E0 be the event that the adversary AL∗ wins
this game, that is, the output of the experiment is 1.

Game 1. We introduce a failure event F1 with respect to Game 0, where F1 occurs if among
the at most (qH + qT + qV + 1) hash computations there is at least one collision. In Game 1,
if F1 occurs we abort the game and return 0. We let E1 be the event that the adversary AL

wins this game.

Bounding |Pr[E0]− Pr[E1]|. Since Game 0 and Game 1 are identical as long as F1 does not
occur, if Q = qH + qT + qV + 1, we have

|Pr[E0]− Pr[E1]| ≤ Pr[F1] ≤ Q(Q+ 1)/2n+1.

Note: from now on, A wins if τ never appears in a leaking tag query. Moreover, h̃ = F−1k (τ)
is fresh when τ appears in a leaking verification query for the first time if m was never used
as input of H at that time. (See above.)

9



Game 2. We modify the winning condition of the previous game. In the finalization, once
A outputs (m, τ) we say that A does not win and return 0 if A fails as before or if m appears
as an input of H before the first apparition of τ during a leaking verification query. If we call
F2 the event that makes the adversary winning in Game 1 but loosing in Game 2, we have
|Pr[E2]− Pr[E1]| ≤ Pr[F2], where E2 is the event that A wins in this game.

Bounding Pr[F2]. If we call Vi the event that (m, τ) appears for the first time in the i-th
leaking verification query (mi, τ i), we just have to bound Pr[F2∩Vi], for all i = 1 to qV +1. By
considering all the input-output pairs defined by H before the i-th leaking verification query,
except those defined during a leaking tag query, we can build straightforwards reduction to
the SUL2-security of F. We thus have, Pr[F2 ∩ Vi] ≤ (qH + qV + 1)εSUL2 and finally

Pr[F2] =

qV +1∑
i=1

Pr[F2 ∩ Vi] ≤ (qH + qV + 1)(qV + 1)εSUL2.

Note: in Game 2, the adversary wins only if τ appears before m and τ first appears in a
leaking verification. The random value of H(m) is still undefined at that time.

Game 3. In this game we follow the specification of FORGE-L2suf-vcma
A,HBC,L∗ except that we always

output 0 at the end of the game.

Bounding |Pr[E3] − Pr[E2]| = Pr[E2]. From the last note, we know that h̃ = F−1k (τ) must
be reached from a fresh computation of H. Since any fresh H evaluation results in a uniform
output which is thus independent of the view of τ , Pr[H(m′) = h̃] = 1/2n for all hash eval-
uations on some m′ appearing after τ in a H-query or in a LVrfy query. But the number of
targets h̃ during the game is actually the number of different τ ′ in the LVrfy queries when
considering the hash evaluations after each such τ ′. Then Pr[E2] ≤ qV (qH + qV )/2n.

To summarize, we have

Pr[E0] ≤ (qH + qV + 1)(qV + 1)εSUL2 +
qV (qH + qV )

2n
+
Q(Q+ 1)

2 ¡ 2n

from which the result follows as 2qV (qH + qV ) ≤ Q(Q− 1). ut

In the next section we show how to improve the security bound.

5 Second leakage-resilient MAC: HTBC

The design of our second construction is similar to that of HBC. The main difference in HTBC
is that the hash function has a double output length. A TBC replaces the BC to use the tweak
as a support for the additional part of the digest. The primary goal of this modification is to
get a better bound, even in the unbounded leakage setting. However, we analyze this design
under the perspective of the unpredictability of the TBC for the first time.

10



5.1 HTBC description

Let M = {0, 1}∗ and T W = X = Z = {0, 1}n. Considering a hash function H : M 7→
X ×T W = {0, 1}2n and a tweakable block cipher F : K×T W ×X 7→ Z, we build HTBC =
(Tag,Vrfy):

Tagk(m): first compute h1‖h2 = H(m) and τ = Fk(h2, h1) and output τ .
Vrfyk(m, τ ): first compute h1‖h2 = H(m) and h̃1 = F−1k,h2

(τ), then

output 1 if h1 = h̃1, and 0 otherwise.

We stress again that Tag only evaluates F while Vrfy only computes its inverse. HTBC was
proposed as the authenticator of TEDT [7] (also adopted in [16,6]), with the motivation to
break the birthday security barrier in the Hash-then-Block-cipher HBC. As the hash digest
has been increased to 2n bits, the standard hash collision-based attack turns unfeasible. We
illustrate HTBC in Fig. 2.

Fig. 2. The leakage resilient HBC-scheme.

5.2 Security of HTBC

The unbounded leakage function pair L∗ = (L∗Tag, L
∗
Vrfy) of HTBC is defined as

L∗Tag(k,m): return h1‖h2 = H(m) and LEval(k, h2, h1);

L∗Vrfy(k,m, τ): return h1‖h2 = H(m) and h̃1 = F−1k,h2
(τ) as well as LInv(k, h2, τ).

As we rely on the random oracle model to prove the security of HTBC, we include the digests
in the leakage to capture the fact that H is actually a public function.

Theorem 3. Let H : {0, 1}∗ 7−→ {0, 1}n × {0, 1}n be a hash function modeled as a random
oracle, and F∗ : K × {0, 1}n × {0, 1}n 7−→ {0, 1}n be a (qT , qV , qL, t + t3, εSUL2)-strongly un-
predictable tweakable block cipher with leakage L = (LEval, LInv), then HTBC is a (qT , qV , t, Îľ)-
suf-L2 strongly unforgeable MAC with unbounded leakage function pair L∗ = (L∗Tag, L

∗
Vrfy) as

11



defined above, where

ε ≤ (qH + qT + qV )2

22n
+ (qV + 1) ¡ ξSUL2 +

q2HqV
2n
¡ ξSUL2 +

qV (qH + qV )

22n
,

and tH(qH + qT + qV + 1) + (qT + qL − q)tF + (qV + q)tF−1 ≤ t for any q ≤ qL, and where we
assume that all the H-query involved in the qL queries are already among the qH queries, as
long as 4 ≤ qH + qT + qV , 4qV ≤ qH and 10qH ≤ 2n.

The leading term in the security bound is εSUL2 · q2HqV 2−n. This time, for n = 128 and
εSUL2 ≈ 2−96, security holds up to qH ≈ 280 and qV = 264. As for Theorem 2, we are not
aware of a realistic matching attack (i.e., if a reasonable hash function and TBC are used in
the construction). Investigating whether the additional qH2−n factor that we gain compared
to the BC-based construction can get closer to 2−n is an interesting open problem.

The structure of the proof for HTBC is different from that of HBC. The main reason is that
the collision resistance of H does not cover all the winning cases when the adversary’s τ of the
forgery appears in an LTag query. Indeed, we might have H(m) = h1‖h2 6= h′1‖h′2 = H(m′)
such that Fk(h2, h1) = τ = Fk(h′2, h

′
1) with m′ in an LTag query. That is because Fk,h2 and

Fk,h′2
can be seen as two different permutations given that h2 6= h′2: an output τ defines many

possible tweak-input pairs. As we will see the distribution and the freshness of (h2, τ) will
play an important role in the proof.

Idea of the proof. Let (m, τ) be a forgery and write H(m) = h1‖h2. If no triple of the form
(?, h2, τ) appears during the computation of all the evaluations and inversions of F, (h1, h2, τ)
is a valid fresh triple for F which breaks the unpredictability of the TBC. However, if it is
not the case, the triple (?, h2, τ) appears either in the evaluation of F during an LTag query
or only in the inversion of F in an LVrfy query. In the former case, as the answer to an
LTag query is necessarily valid, the triple (?, h2, τ) must actually be (F−1k (h2, τ), h2, τ), i.e.
(h1, h2, τ). Of course, if the adversary has made an LTag query on m, it cannot win. If the
adversary is successful, it means that it managed to request the computation of a hash value
which collides on H(m), which only occurs with a beyond-birthday probability. We can thus
focus on the latter case where the triple (?, h2, τ) only appears when answering an LVrfy
query, i.e. in an inversion of F.

We split the remaining winning conditions into: (1) m appears as an input of H before
ever computing a TBC inversion on input (h2, τ) when answering a leaking verification query;
(2) m appears strictly after the first computation of a TBC inversion on input (h2, τ) when
answering a leaking verification query; no matter whether τ appears first in an LTag answer
or in an LVrfy query. We note that we no more need to consider the H computation in the
LTag queries as we already dealt with H-collisions. In a nutshell, the first case means the
adversary chooses τ depending on the view of the hash value h1‖h2 and hence it relates to the
unpredictability of F. In the second case, the target h1‖h2 is fixed in the leaking verification
query while the output of H(m) remains uniformly random and independent of the view at
that time. By convention, if m and τ first appear for the first time together in an LVrfy query,

12



we first compute H(m) so that we always consider that m appears “before” τ . In addition,
w";"""date"",""2019-12-05T20:45:22Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2019-12-05T20:45:22Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017/Debian) kpathsea version 6.2.3""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2019-12-05T20:45:22Z""
""created"",""2019-12-05T20:45:22Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-12-05T20:45:22Z""
""resourceName"",""1413.pdf""
""Author"",""""
""producer"",""pdfTeX-1.40.18""
""pdf:docinfo:producer"",""pdfTeX-1.40.18""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""1"",""1"",""36"",""7"",""8"",""3"",""10"",""7"",""10"",""10"",""24"",""23"",""16"",""29"",""10"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2019-12-05T20:45:22Z""
""Last-Modified"",""2019-12-05T20:45:22Z""
""dcterms:modified"",""2019-12-05T20:45:22Z""
""title"",""""
""Last-Save-Date"",""2019-12-05T20:45:22Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2019-12-05T20:45:22Z""
""meta:save-date"",""2019-12-05T20:45:22Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017/Debian) kpathsea version 6.2.3""
""Content-Length"",""966424""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""18""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""3016"",""3088"",""2451"",""1317"",""1762"",""1773"",""1336"",""2645"",""2563"",""2002"",""1275"",""2607"",""2764"",""2497"",""1662"",""2608"",""3744"",""1906""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-12-05T20:45:22Z""
";https://scholar.google.com/scholar?start=880&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094647-1106;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Automated Technology Transfer in MDE as a Service: Experiences and Research Directions;FP Basso, D Kreutz, E Rodrigues… ; Anais do I Workshop em …, 2019  sol.sbc.org.br;;"… Big market leaders like IBM, Google and Oracle embrace these soft- ware development assistants

innovations … produced in this direction, highlighting the potential of distributed architectures, which

can be built with technologies for smart contracts and blockchain, in gaining …";Autres articles;Version HTML;[PDF] sbc.org.br;https://sol.sbc.org.br/index.php/mssis/article/download/7563/7438;"
Automated Technology Transfer in MDE as a Service:
Experiences and Research Directions

FĂĄbio Paulo Basso1, Diego Luiz Kreutz1, Elder de Macedo Rodrigues1,
Maicon Bernardino1

1Laboratory of Empirical Studies in Software Engineering (LESSE),
Federal University of Pampa (UNIPAMPA), Alegrete, RS, Brazil

{fabiobasso,diego.kreutz,elderrodrigues}@unipampa.edu.br,bernardino@acm.org

Abstract. For years, researchers have sought to assist in the execution of Soft-
ware Engineering (ES) activities with toolboxes developed in the laboratory and
in-house. Big market leaders like IBM, Google and Oracle embrace these soft-
ware development assistants innovations. Unfortunately, innovations launched
by independent researchers simply cannot get space and are shelved. Due to
the lack of maturity of the product, there is a difficulty, in less than three years,
that it is the threshold for success or failure of a startup in Brazil, to enable the
transfer of these technologies from academia to industry. This paper presents
some experiences with a future vision for research that seeks to automate the
transfer of technology in the area through integration mechanisms for assets.
In particular, we discuss a set of works produced in this direction, highlighting
the potential of distributed architectures, which can be built with technologies
for smart contracts and blockchain, in gaining credibility within short time-to-
market.

Resumo. Hå tempo os pesquisadores vêm tentando apoiar a execução de ati-
vidades da Engenharia de Software (ES) com suporte ferramental desenvolvido
em laboratĂłrio e in-house. LĂ­deres de mercado como IBM, Google e Oracle
abraçam estas inovaçþes de base tecnológica para ES e, infelizmente, ainda
se observa que inovaçþes lançadas por pesquisadores independentes enfrentam
muitas dificuldades para conseguir espaço. Devido à falta de credibilidade do
produto por sua imaturidade, ĂŠ difĂ­cil nos primeiros trĂŞs anos determinantes
ao sucesso ou fracasso de uma startup no Brasil, se viabilizar a transferĂŞncia
de tecnologias da academia para a indĂşstria. Neste cenĂĄrio, o presente ar-
tigo apresenta algumas experiĂŞncias com uma visĂŁo de futuro para pesquisas
que buscam automatizar a transferĂŞncia de tecnologia da ĂĄrea por meio de me-
canismos de integração para assets. Em especial, discute-se um conjunto de
trabalhos produzidos neste rumo, destacando o potencial de arquiteturas distri-
buĂ­das, as quais podem ser construĂ­das com tecnologias como smart contracts
e blockchain, no ganho de credibilidade dentro do curto tempo de mercado.

1. Introdução
Atualmente, a sociedade brasileira impĂľe pressĂŁo para que as pesquisas conduzidas na
academia tenham aplicação na pråtica. Hoje se questiona se de fato, como pesquisa-
dores, estamos prontos para responder positivamente a esta pressĂŁo. Nesse cenĂĄrio, se



percebe que boa parte das pesquisas conduzidas na ĂĄrea de Engenharia de Software tem
um cunho prĂĄtico e sĂŁo realizadas por meio de estudos aplicados [Sommerville 2010]. No
entanto, sĂŁo raros os relatos de transferĂŞncia de tecnologia observados na literatura desta
ĂĄrea [Mikkonen et al. 2018], o que ĂŠ algo bastante controverso. Para uma ĂĄrea de pes-
quisa da computação construída nos estudos aplicados, Ê necessårio entender os motivos
que atrapalham a transferĂŞncia de tecnologia.

Hå anos, pesquisadores buscam apoiar a execução de atividades de Engenharia
de Software com suporte ferramental desenvolvido em laboratĂłrio e in-house [Mussba-
cher et al. 2014]. Empresas como IBM, Google e Oracle abraçam as inovaçþes de base
tecnolĂłgica para ES, o que ĂŠ positivo para algumas startups de base tecnolĂłgica que ti-
veram a competĂŞncia e sorte de convencĂŞ-los como investidores. PorĂŠm, isto tambĂŠm
deixa pouco espaço para pesquisadores independentes. Por exemplo, Flutter Ê um um
toolkit bastante adotado em fĂĄbricas de software para desenvolvimento de apps1. Este
toolkit ĂŠ mantido pela Google, oferece uma Domain Specific Language (DSL) [France
and Rumpe 2007] para desenvolvimento e permite a geração de código para múltiplas
plataformas. O fato interessante associado com a transferĂŞncia de tecnologia de ES ĂŠ que,
antes de 2000 [France and Rumpe 2007], muitas DSLs e toolkits foram concebidas com
o mesmo propĂłsito do Flutter, mas como parte de pesquisas em Model-Driven Enginee-
ring (MDE) [Mussbacher et al. 2014]. No entanto, sua expressiva adoção por fåbricas de
software nĂŁo foi observada atĂŠ entĂŁo [Basso 2017].

Segundo estudo recente executado pelo Sebrae, uma em cada quatro start-ups bra-
sileiras fecha antes de completar dois anos2. A julgar pelo perĂ­odo mĂŠdio dedicado por
incubadoras de base tecnolĂłgica como a RAIAR e Incubadora PampaTec Alegrete para as
startups, as novas ideias tĂŞm menos de trĂŞs anos para provar o seu valor ao mercado. Isso
requer agilidade para lançar o produto no mercado e para se obter o måximo de reputação
positiva para este produto em um curto espaço de tempo. Logo, Ê preciso romper com o
modus operandi da transferĂŞncia de tecnologia, uma vez que ĂŠ impossĂ­vel adquirir repu-
tação para tecnologias desenvolvidas in-house para assistir processos de desenvolvimento
de software, como ferramentas de produção construídas para MDE, em tão pouco tempo.
Portanto, para pesquisadores independentes e start-ups, aqui entra o grande desafio: aten-
der ao tempo de mercado, uma vez que alĂŠm de desenvolver o produto com qualidade ĂŠ
tambÊm preciso obter reputação para que o mesmo se torne visível para o público alvo.

Em um trabalho anterior, constatou-se que uma dificuldade estĂĄ em fazer os ativos
de tecnologia alcançarem o mercado [Neto et al. 2019], propondo ecossistemas como
um meio de se conseguir algumas facilidades, como busca de concorrentes e estabeleci-
mento de parcerias na comercialização e integração de ativos. Para a årea de Engenharia
de Software, a nossa definição de ativos, ou asset, inclui ferramentas de modelagem ou
de refinamento de modelos, bem como qualquer recurso que dĂŞ suporte para atividades
da Engenharia de Software por meio de modelos [Basso 2017]. Tais assets visam au-
mentar a qualidade dos produtos de software, assim como automatizar atividades como
a assistência para representação arquitetural do modelo do software [Basso et al. 2016]
e desenvolvimento de software baseado em modelos e geração de código [Basso et al.

1www.flutter.dev
2https://exame.abril.com.br/negocios/dino/1-a-cada-4-empresas-fecha-antes-de-completar-2-anos-no-

mercado-segundo-sebrae/



2013]. Portanto, independentemente da natureza do asset e de seus criadores (indĂşstria
ou academia), tem-se como meta introduzi-lo em fĂĄbricas de software, sendo o suporte
ferramental algo essencial para o sucesso neste tipo de serviço.

Esse artigo aborda a transferência de tecnologia por meio de serviços especialis-
tas, denominados por MDE como um Serviço (MDEaaS - MDE as a Service) [Basso
et al. 2017a]. MDEaaS inclui a execução de fases de integração de ativos em cadeias
de ferramentas (toolchains) e processos que atendem contextos especĂ­ficos de fĂĄbricas
de software operando em cenårios de coopetição, isto Ê, cenårios que envolvem a cola-
boração entre empresas competidoras [Ritala et al. 2014]. Nestes serviços, cadeias de
ferramentas sĂŁo customizadas e processos automatizados para cada caso de uma empresa
prospectada para transferĂŞncia de tecnologia. Outra caracterĂ­stica peculiar no MDEaaS ĂŠ
que cadeias de ferramentas e processos incluem ativos hĂ­bridos, geralmente ferramentas
produzidas por mais de um indivĂ­duo/empresa em contextos inter-organizacionais [Basso
2017]. Como operaram sobre negociaçþes inter-organizacionais, estes serviços precisam
considerar uma perspectiva tridimensional de dados [Neto et al. 2019], os quais incluem
visĂľes tĂŠcnicas, sociais e de negĂłcios como fontes de influĂŞncia na tomada de decisĂŁo.

Nesse contexto, o presente artigo destaca os benefícios que podem ser alcançados
com o uso de tecnologias como smart contracts e blockchains, que fornecem mecanismos
para se obter confiança nos ativos produzidos por desenvolvedores independentes, em
curto tempo de mercado. O artigo estå organizado da seguinte forma: a Seção 2 relata as
experiências no MDEaaS; a Seção 3 apresenta lacunas de pesquisa; e, por fim, a Seção 4
apresenta as conclusĂľes.

2. Experiências no MDE como um Serviço

A transferĂŞncia de tecnologia na Engenharia de Software caracteriza-se pela transferĂŞncia
de conhecimento tÊcnico ou científico para produção de software. Um dos elementos cen-
trais da transferência de tecnologias Ê elencar os fatores de produção associados com uma
determinada tecnologia, resultantes de pesquisas e investigaçþes científicas. Fatores de
produção, como a velocidade de entrega de histórias de usuårio por iteração do processo
de desenvolvimento e nĂşmero de defeitos detectados e corrigidos, sĂŁo sempre conside-
rados pelas fĂĄbricas de software em processos de tomada de decisĂŁo por determinadas
tecnologias. Estes fatores são muito associados com a adoção de tecnologias introduzidas
no mercado como forma de melhoria da qualidade e produtividade de software. Sendo
assim, o desconhecimento desses fatores ocasiona um dos principais problemas relatados
pela indústria na adoção de tecnologias de MDE: a falta de dados para investir em tecnolo-
gias produzidas in-house; dados estes que convençam candidatos à adoção de tecnologias
para automação de tarefas do processo de desenvolvimento.

A transferĂŞncia dessas tecnologias da ĂĄrea ainda ĂŠ realizada de modo ad-hoc. Em
pesquisas associadas com o MDEaaS, buscou-se tornar isto algo mais sistemĂĄtico e as-
sistido por ferramentas. Dessa forma, o MDEaaS pode ser uma possível solução para a
automação na transferência de tecnologias em negócios de ES. Ele Ê visto como um nicho
de negĂłcio por algumas empresas, indivĂ­duos atuando como profissionais liberais, bem
como visionårios que buscam criar suas primeiras empresas de serviços na årea, e Ê carac-
terizado por uma demanda de empresas que contratam tais profissionais para a introdução
de tecnologias para MDE em contextos de fĂĄbricas de software. Sob uma perspectiva pu-



ramente tÊcnica, tal demanda inclui a automação de uma ou mais atividades da Engenharia
de Software, usando-se um conjunto de ativos de MDE. Por exemplo, DSLs para repre-
sentação de requisitos de software em modelos, representação de processos de negócio e
de software, bem como ativos que transformam tais modelos em formatos interpretados
por ferramentas utilizadas ao longo de toda a cadeia produtiva do software.

Por meio das experiĂŞncias anteriormente citadas, prospectou-se que MDEaaS ĂŠ
de grande relevância para a automação da transferência de tecnologia em geral e pode
promover benefícios ainda não tangíveis para as inovaçþes da årea como: 1) a possibi-
lidade de realizar colaboraçþes/negociaçþes casadas de ativos, o que requer autenticação
das partes interessadas na composição de cadeias de ferramentas produzidas de modo in-
dependente de provedor/lĂ­der de tecnologia; 2) a abertura de novos negĂłcios por meio de
ativos representados e armazenados na deep-web, como assets distribuĂ­dos e sem a pre-
sença de um líder no processo; 3) ruptura total na forma como se aborda credibilidade
em relação a ativos, por meio de uma relação mais direta entre fåbricas de software e
fornecedores de tecnologias.

O foco do MDEaaS nĂŁo estĂĄ na modelagem dos sistemas e processos, mas no ser-
viço fornecido por um Engenheiro de Software na transferência de tecnologia de MDE
para um contexto de adoção. Logo, um portfólio de serviços pode incluir a automação de
diversas atividades em muitas fases de processos de desenvolvimento de software. Essa
automação atualmente Ê custosa e sua implementação depende de uma equipe interna
de uma fĂĄbrica de software que domina profundamente um conjunto bem limitado de
tecnologias. Como geralmente nĂŁo hĂĄ uma especialidade dentro da fĂĄbrica de software
para tratar disso, a automação Ê desencorajada. Jå os profissionais no MDEaaS devem
ser especialistas na transferĂŞncia de tecnologias de MDE. Eles devem dominar mĂşltiplas
tecnologias de MDE (ativos), que têm muitas aplicaçþes nas fases de processos de desen-
volvimento de software. Portanto, MDEaaS pode ser a solução que a indústria de software
busca na automação de seus processos.

MDE como um Serviço trata da introdução de ativos de MDE em contextos inter-
organizacionais, isto Ê, quando mais de uma empresa estå prospectada para adoção desses
ativos. Para exemplificar estes contextos, parte-se de um pequeno relato de implantação
de um negócio focado no MDEaaS: uma spin-off de mestrado provedora de serviços de
transferência dessas tecnologias. Para dar suporte para estes serviços, em 2006 propôs-
se a FOMDA DSL, uma ferramenta para tratar de questĂľes tĂŠcnicas na transferĂŞncia de
tecnologia de MDE. Em seguida, criou-se uma start-up, chamada Adapit, que operou de
2007 atÊ 2011 em um projeto para a implementação do MDEaaS. Por meio dessa start-up,
foi possível gerenciar semelhanças e diferenças de três contextos inter-organizacionais.
Em termos tÊcnicos, fez-se a transferência de tecnologia de MDE pela representação de
reutilização em ativos de MDE, em uma abordagem de reúso sistemåtico assistida por fer-
ramenta que implementa conceitos de Linha de Produtos de Software, Desenvolvimento
Baseado em Componentes, Cadeia de Transformação de Modelos e Testes Adaptativos.
A partir dessa representação, o Engenheiro de Software adapta automaticamente os ativos
para os contextos de adoção de tecnologias.

Essa experiĂŞncia mostrou que, apesar dos conhecimentos da Engenharia de Soft-
ware serem aplicĂĄveis ao MDEaaS, diversos desafios tĂŠcnicos e metodolĂłgicos precisa-
vam ser resolvidos para viabilizar tais serviços. Assim, de 2012 atÊ 2017, investigou-se



um desses problemas: uma abordagem para reĂşso oportunista, construĂ­da sobre uma re-
presentação comum para assets, que almeja viabilizar a colaboração e competição (coo-
petição) entre empresas de desenvolvimento de software como um desafio na transferên-
cia de tecnologias de MDE. Coopetição Ê caracterizada pela colaboração entre empresas
competidoras como, por exemplo, duas empresas A e B, que desenvolvem software em-
barcado, cada qual atendendo e mantendo a sua base de clientes isoladamente. Elas sĂŁo
competidoras em seus portfĂłlios. Mas, por nĂŁo possuĂ­rem especialistas e, para dividir os
custos na implantação de ativos de MDE, pretendem colaborar na automação de seus pro-
cessos. Nesse sentido, o MDEaaS Ê uma possível solução, em que o profissional atende
ambas as empresas e amortiza os custos na transferĂŞncia de tecnologias.

Em nossos estudos preliminares, se ofereceu soluçþes voltadas para problemas
tÊcnicos na implementação do MDEaaS [Basso et al. 2013, Basso et al. 2015, Basso
et al. 2016,Basso et al. 2017b]. PorÊm, estas contribuiçþes não tratam adequadamente de
questþes mais voltadas para negócio e tambÊm não ajudam com critÊrios de informaçþes
que se deve prover aos possĂ­veis clientes para a tomada de decisĂŁo na transferĂŞncia de
tecnologia como composição de sistemas. Assim, uma vez que se progrediu nas questþes
tÊcnicas que fundamentam uma representação comum para tais tecnologias, deve-se tam-
bÊm tratar de desafios tÊcnicos e metodológicos envolvendo a aquisição de tecnologias
como ativos negociados em cadeias de ferramentas.

Transferir uma tecnologia de Engenharia de Software para um determinado con-
texto parece uma atividade trivial, no entanto, isto provou-se bastante desafiador na teoria
e na prĂĄtica. Na prĂĄtica, a dificuldade para transferĂŞncia de tecnologia estĂĄ em tornar a
inovação atrativa para um grande provedor de tecnologia, a ponto deste adotå-la. Esta
dificuldade se deve a um modelo de negócio ruim, baseado em competição, em vez de
uma colaboração com os grandes provedores de tecnologia da årea, como Google, IBM e
Oracle. É muito difícil convencer estas empresas a tornarem-se colaboradoras, então elas
sĂŁo tratadas como concorrentes para aquilo que se produz em laboratĂłrio ou em in-house.
Isso Ê ruim para a inovação tecnológica, pois mata os produtos e serviços jå na raiz.

Falta uma visĂŁo mais mercadolĂłgica daquilo que se produz em ambiente acadĂŞ-
mico. Por exemplo, serviços de transferência de tecnologia envolvendo integração de
ferramentas em cadeias de ferramentas sĂŁo atualmente realizados de modo ad-hoc, ou
seja, sem uma boa fundamentação para sua execução, tanto processual quanto implemen-
tacional, que inclua a visão de negócios. Isso gera desconfiança do mercado potencial.
Neste sentido, as duas principais limitaçþes, não relacionadas com suporte ferramental,
que hoje atrapalham a automação da transferência de tecnologia na årea são:

1 - Faltam metodologias que sistematizam a transferĂŞncia de tecnologia da ĂĄrea.
Devido à existência de poucos relatos de experiência, percebe-se uma limitação na litera-
tura para sistematizar a transferĂŞncia de tecnologia de Engenharia de Software para MDE.
Logo, nĂŁo se tem conhecimento de uma abordagem sistemĂĄtica que possa ser repetida
diversas vezes para diferentes contextos de empresas, muito menos uma que considere
negociaçþes por meio de contratos inteligentes que garanta a segurança nas transaçþes e
a validade na integração dos ativos. Esta falta de uma sistematização se deve muito às
limitaçþes do corpo de conhecimento empírico na årea, o que gera incerteza de sucesso
na implementação do MDEaaS e aumenta os riscos na transferência dessas tecnologias
para as fĂĄbricas de software.



2 - Fatores de produção associados com ativos da årea são desconhecidos. Em
anĂĄlises do estado da arte anteriores, percebe-se a falta de um corpo de conhecimento
para fomentar tais iniciativas na årea. Por exemplo, não hå contribuiçþes científicas que
auxiliam no mapeamento dos riscos do MDEaaS por meio de blockchains, nem das boas
pråticas para a condução destes serviços. TambÊm inexiste uma abordagem sistemåtica
de suporte ao Engenheiro de Software para definir fatores de produção, como a anålise
e prospecção da curva de aprendizado derivada de transferências casadas de tecnologia,
melhoria/prejuízo de produção e o Retorno de Investimento (ROI) associado com os ativos
de MDE. Fatores de produção são sempre avaliados pela indústria de software antes de
investir na adoção de qualquer tecnologia, mas pouco se entende desses fatores no que
tange serviços de Engenharia de Software em geral.

Jå em relação ao suporte ferramental, nossa contribuição anterior trata de algumas
lacunas de pesquisa proeminentes [Neto et al. 2019]. A próxima seção Ê complementar e
trata da transferĂŞncia casada de tecnologia usando-se arquiteturas distribuĂ­das de ativos.

3. Lacunas de Pesquisa
Em experiĂŞncias anteriores, buscou-se, por exemplo, o desenvolvimento de outras inova-
çþes em laboratório, incluindo DSLs e geradores de código para Internet of Things (IoT)
por meio de redes de sensores sem fio [Paulon et al. 2014]. Na prĂĄtica, percebe-se que
a dificuldade não estå em conceber o produto, mas em conseguir espaço no mercado,
fornecendo credibilidade. Aprendeu-se que, sendo uma empresa pequena, assim como
sĂŁo hoje tambĂŠm os grupos de pesquisa das universidades, ĂŠ impossĂ­vel comercializar
algo para competir com grandes provedores de tecnologia para desenvolvimento de soft-
ware. Eles ditam as regras, ditam o que ĂŠ bom e o que ĂŠ ruim e, como consequĂŞncia, por
mais potencial que tenham alguns produtos e serviços, eles acabam engavetados. Neste
sentido, busca-se promover uma disruptura no modus operandi da transferĂŞncia de tecno-
logias da årea de Engenharia de Software, que pode ser realizada por meio da integração
do MDEaaS com contratos inteligentes e blockchain.

Contratos inteligentes (smart contracts) são protocolos de transação computado-
rizada que executam em termos de um contrato [Szabo 1996]. Os contratos inteligentes
vĂŞm sendo largamente utilizados e difundidos no contexto de blockchains e criptomoe-
das [Christidis and Devetsikiotis 2016]. No contexto de blockchains, os contratos inte-
ligentes são scripts armazenados no blockchain, que possuem um endereço único e são
acionados por meio da associação de uma transação. O contrato Ê, então, independente e
segue, automaticamente, instruçþes prÊ-definidas em todos os nós da rede.

Tipicamente, em blockchains de criptomoedas, os contratos inteligentes sĂŁo utili-
zados para definir funçþes de depósito e negociação de criptomoedas. De forma resumida
e simplificada, um usuĂĄrio A cria o contrato e deposita unidades de X no contrato. A fun-
ção de negociação estabelece que 1 unidade de X equivale a 5 unidades de Y. Assim que
o usuĂĄrio A receber 5 unidades de Y de um usuĂĄrio B, o contrato liberarĂĄ 1 unidade de X
para B e 5 unidades de X para A. Um contrato inteligente possui tambÊm uma função de
“cancelamento”, que permite ao usuário A “reverter” uma negociação e remover as suas
unidades X do contrato.

Todas as negociaçþes utilizando este tipo de contrato ocorrem entre partes mu-
tuamente nĂŁo confiĂĄveis, o que ĂŠ uma das caracterĂ­sticas mais interessantes e potencial-



mente disruptivas de contratos inteligentes e blockchains. NĂŁo ĂŠ para menos que hoje
os contratos inteligentes sĂŁo divulgados em mĂşltiplos domĂ­nios do conhecimento como
ferramentas confiåveis para eliminar intermediårios e estabelecer negociaçþes de ativos
ou qualquer coisa de valor. Como exemplo, podemos utilizar um contrato inteligente
para garantir um acordo de nível de serviço, em que caso o acordo seja cumprido, uma
recompensa ĂŠ dada, ou entĂŁo uma penalidade, em caso contrĂĄrio (podendo ou nĂŁo usar
criptomoedas).

Um dos desafios para integrar estas trĂŞs novidades ĂŠ identificar os requisitos de
armazenamento de informação, nos blocos da blockchain, e a definição de funçþes para
contratos inteligentes no escopo de negociação de ativos, no que se refere ao casamento de
informaçþes sobre ferramentas de produção de software em nível semântico e sintåtico,
tambÊm com autenticação das partes envolvidas no estabelecimento de cadeias de ferra-
mentas (cadeias de ferramentas). Assim, a tecnologia proposta deve permitir ao Enge-
nheiro de Software gerenciar todo o processo de integração, hoje executado manualmente
na automação de processos de desenvolvimento de software. Isso requer a execução de
pesquisas focadas e de longa duração, realizadas por pesquisadores com diferentes visþes
e experiĂŞncias na transferĂŞncia de tecnologia.

Por mais revolucionåria que seja a palavra ""blockchain"", sua aplicação em outros
cenĂĄrios, que nĂŁo criptomoedas, ainda nĂŁo estĂĄ consolidada e diversas pesquisas sĂŁo ne-
cessĂĄrias atĂŠ ela se tornar estabelecida. Existe a perspectiva que isto sĂł venha a acontecer
entre 5 e 10 anos, quando blockchain deve atingir o platĂ´ da produtividade, segundo o
Gartner [K. Panetta 2018]. Neste sentido, a aplicação de tecnologias para contratos in-
teligentes como um meio de promover automaticamente a transferĂŞncia de tecnologia de
MDE em contextos de Engenharia de Software nĂŁo ĂŠ tratada pela literatura, mas altamente
desejĂĄvel para a cadeia produtiva, visĂŁo tambĂŠm compartilhada pelo Gartner [Gartner
2013].

Embora as implementaçþes mais conhecidas de blockchain são em criptomoedas,
onde os blocos da cadeia armazenam conjuntos de transaçþes que guardam os registros
de movimentaçþes de valores específicos, abre-se espaço para investigar um problema
aplicado aos cenĂĄrios de negĂłcios da engenharia de software. AlĂŠm disso, os estudos
preliminares no MDEaaS focaram no desenvolvimento de tecnologias e no levantamento
de fatores de produção que afetam a transferência destas inovaçþes para contextos de få-
bricas de software por meio de cadeias de transformação de modelos. Prospecta-se que
para uma aplicação em transferência automåtica de tecnologias, novas pesquisas utiliza-
rĂŁo da temĂĄtica para desenvolver novas plataformas distribuĂ­das de assets com base em
blockchains e contratos inteligentes. A expectativa ĂŠ que o produto final desta integra-
ção viabilize e potencialize negociaçþes derivadas da pesquisa científica, inicialmente,
em Engenharia de Software, viabilizando a råpida disseminação de assets desenvolvidos
em laboratório e in-house, por meio de contratos inteligentes e negociaçþes par-a-par.
Portanto, promoverĂĄ um meio alternativo para se obter credibilidade na transferĂŞncia de
tecnologias, uma vez que negociaçþes se dariam entre entidades não confiåveis, isto Ê,
eliminando a necessidade de entidades intermediadoras (os grandes lĂ­deres).

Blockchain, com sua segurança e confiabilidade, garante que a transação na trans-
ferĂŞncia de tecnologia tenha ocorrido e nĂŁo possa ser alterada, ou seja, trata-se de uma
tecnologia que permite, hoje, a condução de estudos aplicados. O código da blockchain



automatiza as próximas etapas de transaçþes feitas pelos participantes de um bloco de
negĂłcio, o que, em nĂ­vel tĂŠcnico, significa estabelecer cadeias de ferramentas como cola-
boraçþes/vendas casadas entre múltiplas empresas. Assim, novas pesquisas podem inves-
tigar a aplicação do que jå se tem fundamentado em termos de MDEaaS, para estabelecer
negĂłcios implementados por meio de contratos inteligentes.

Atualmente, por meio de integração (semi-)automåtica de ativos [Basso 2017], Ê
possível divulgar inovaçþes em repositórios de assets, estabelecendo, por meio de pla-
taformas de assets, oportunidades para vendas, como produtos e serviços. Contratos in-
teligentes podem ser explorados neste sentido. AlĂŠm disso, tais tecnologias estĂŁo sendo
integradas de modo facilitado, quando construĂ­das sobre o guarda-chuva de MDE. Ou
seja, os ativos que podem ser negociados via contratos inteligentes sĂŁo ativos elabora-
dos com tecnologias de suporte ao MDE, mas de qualquer natureza para processos de
desenvolvimento de software, e que precisam ser introduzidos em contextos de fĂĄbricas
de software em negociaçþes que envolvem a transferência de tecnologia entre múltiplas
empresas. Logo, a tecnologia de blockchain pode promover uma ruptura em como essas
negociaçþes e integraçþes podem ser realizadas, necessitando investigaçþes em termos de
metodologias, ferramentas/plataformas e de formação de base de conhecimento na årea.

Por fim, uma vez que se tem por objetivo de longo prazo estabelecer as fundamen-
taçþes para a ruptura nos negócios envolvendo a transferência de tecnologia, conclui-se
que tecnologias para smart contract, blockchain e MDEaaS devem ser investigadas de
modo integrado. Em se tratando da transferĂŞncia de tecnologia pra a ĂĄrea foco, cujo ar-
tigo foi divulgado, assume-se que o foco de estudos futuros sĂŁo tecnologias especĂ­ficas de
Engenharia de Software, livres ou comerciais. As pesquisas de Engenharia de Software
têm, atÊ então, desenvolvido tais tecnologias de forma isolada, sem preocupação com sua
transferência para a indústria de software. É hora de promover mudanças.

4. ConclusĂľes

Como produtores de tecnologias que auxiliam nas atividades de Engenharia de Software
(ES), a dificuldade dos pesquisadores dessa ĂĄrea estĂĄ em fazer seus inventos adquiri-
rem um status de ativos de valor comercial. Por meio de experiĂŞncias em uma start-up
concebida para esta finalidade, percebeu-se que outras limitaçþes tambÊm atrapalham a
transferĂŞncia destas tecnologias (generalizadas como ativos): o corpo de conhecimento
escasso que fornece suporte metodolĂłgico ao Engenheiro de Software e a falta de suporte
ferramental que viabilize uma integração semi-automåtica desses ativos em processos
de fĂĄbricas de software do mundo real. A dificuldade para se progredir nessa temĂĄtica
estĂĄ, principalmente, na novidade do tema. O corpo de conhecimento em Engenharia de
Software carece de estudos empíricos que forneçam as bases para computação dos fa-
tores de produção associados com tecnologias de MDE e não fornece uma base para se
implementar vendas casadas de serviços em negociaçþes que ocorrem em cenårios inter-
organizacionais.

É preciso fundamentações para a transferência de tecnologia da área. Percebe-se
tambĂŠm que nĂŁo hĂĄ uma abordagem sistemĂĄtica para o MDEaaS que possa ser repetida
diversas vezes para diferentes contextos de empresas. Esta falta de uma sistematização se
deve muito às limitaçþes do corpo de conhecimento empírico na årea, o que gera incerteza
de sucesso na implementação do MDEaaS e aumenta os riscos na transferência do que se



produz na academia, como tecnologias, para as fĂĄbricas de software. Portanto, sem essas
bases, a transferĂŞncia de tecnologia continuarĂĄ uma tarefa ad-hoc, propensa a erros e com
um grande risco associado na oferta e contratação destes serviços pelos clientes.

Neste sentido, pesquisas em blockchain e contratos inteligentes (smart contracts),
em conjunto com uma linguagem de representação comum para ativos denominada
RAS++ [Basso 2017] (construĂ­da sobre o guarda-chuva de MDE), oferecem uma solu-
ção promissora. Tais tecnologias podem, por exemplo, promover benefícios ainda não
tangíveis para o cenårio, como: 1) a possibilidade de realizar colaboraçþes/negociaçþes
casadas de ativos, o que requer autenticação das partes interessadas na composição de ca-
deias de ferramentas produzidas de modo independente de provedor/lĂ­der de tecnologia;
2) a abertura de novos negĂłcios por meio de ativos representados e armazenados na deep-
web, como assets em repositórios distribuídos e sem a presença de um líder no processo; e
3) a ruptura total na forma como se aborda credibilidade em relação a ativos, por meio de
uma relação mais direta entre fåbricas de software e micro-fornecedores de tecnologias.

Por fim, vale ressaltar que uma solução para a transferência de tecnologia não Ê
meramente uma questĂŁo de oferecer um suporte ferramental, como as de foco de inves-
tigação neste artigo, mas que envolve uma mudança cultural do pesquisador. Observa-se
que na pesquisa brasileira, pouco se faz para ter um produto de mercado, pois se foca em
protĂłtipos. AlĂŠm disso, existe um viĂŠs na academia em que pesquisadores criam tecnolo-
gias muito incipientes, muitas vezes com o objetivo de publicar artigos e nĂŁo exatamente
de fomentar a literatura com dados que auxiliem na transferĂŞncia de tecnologia. Relaci-
onado com a divulgação da tecnologia, repositórios abertos como ReMoDD e SEMAT,
que recomendam o compartilhamento de diversos assets Ăşteis para a indĂşstria de software,
infelizmente não são muito explorados. Jå alternativas interessantes para publicação de
material em revistas que podem ser utilizadas com este propĂłsito, como Data in Brief,
MethodsX e SoftwareX, começam a ganhar notoriedade.

ReferĂŞncias
[Basso 2017] Basso, F. P. (2017). RAS++: Representing Hybrid Reuse Assets for MDE

as a Service. Av at <www.cos.ufrj.br/uploadfile/publicacao/2811.pdf>. PhD thesis,
Universidade Federal do Rio de Janeiro (UFRJ).

[Basso et al. 2017a] Basso, F. P., Oliveira, T. C., Werner, C. M., and Becker, L. B. (2017a).
Building the foundations for ‘mde as service’. IET Software, 11:195–206(11).

[Basso et al. 2013] Basso, F. P., Pillat, R. M., Oliveira, T. C., and Becker, L. B. (2013).
Supporting large scale model transformation reuse. In 12th International Conference
on Generative Programming: Concepts & Experiences., GPCE’13, pages 169–178.

[Basso et al. 2016] Basso, F. P., Pillat, R. M., Oliveira, T. C., Roos-Frantz, F., and Frantz,
R. Z. (2016). Automated design of multi-layered web information systems. Journal of
Systems and Software, 117:612 – 637.

[Basso et al. 2015] Basso, F. P., Pillat, R. M., Roos-Frantz, F., and Frantz, R. Z. (2015).
Combining mde and scrum on the rapid prototyping of web information systems. In-
ternational Journal of Web Engineering and Technology, 10(3):214–244.

[Basso et al. 2017b] Basso, F. P., Werner, C. M. L., and de Oliveira, T. C. (2017b). Automa-
ted approach for asset integration in eclipse IDE. In 2017 IEEE/ACM Joint 5th Interna-



tional Workshop on Software En";"""date"",""2019-08-18T19:52:19Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""pt""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2019-08-18T19:52:19Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017) kpathsea version 6.2.3""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2019-08-18T19:52:19Z""
""created"",""2019-08-18T19:52:19Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-08-18T19:52:19Z""
""resourceName"",""7438""
""Author"",""""
""producer"",""pdfTeX-1.40.18""
""pdf:docinfo:producer"",""pdfTeX-1.40.18""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2019-08-18T19:52:19Z""
""Last-Modified"",""2019-08-18T19:52:19Z""
""dcterms:modified"",""2019-08-18T19:52:19Z""
""title"",""""
""Last-Save-Date"",""2019-08-18T19:52:19Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2019-08-18T19:52:19Z""
""meta:save-date"",""2019-08-18T19:52:19Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017) kpathsea version 6.2.3""
""Content-Length"",""115828""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""10""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""2421"",""3081"",""3079"",""3104"",""3149"",""2994"",""3122"",""3046"",""2952"",""2471""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-08-18T19:52:19Z""
";https://scholar.google.com/scholar?start=920&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094537-633;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Sustainable Development Report: Blockchain, the Web3 & the SDGs;S Voshmgir, M Wildenberg, C Rammel, T Novakovic ;2019 epub.wu.ac.at;;"… Agenda 2030 & the SDGs 6 Socio-ecological transformations & the SDGs 6 Innovation and the

SDGs 7 Blockchain & the Web3 9 Blockchain Networks 9 Other Distributed Ledgers 11 Smart

Contracts 14 Oracles 15 Tokens 15 Interoperability 16 Scalability 17 Legal Challenges …";Autres articles;;[PDF] wu.ac.at;https://epub.wu.ac.at/7453/1/SustainableDevelopment%20Report_BlockchainWeb3_SDGs.pdf;"
S U S TA I N A B L E
D E V E L O P M E N T  R E P O R T

D E C  2 0 1 9

BLOCKCHA IN ,  WEB 3
& TH E  S DGS



Published by: 
Research Institute for Cryptoeconomics, Dec 2019
Vienna University of Economics,  Welthandelsplatz 1, 1020 Wien

This is an output paper of the applied research that was conducted between July 2018 - 
October 2019 funded by the Austrian Development Agency (ADA) and conducted by the 
Research Institute for Cryptoeconomics at the Vienna University of Economics and Business 
and RCE Vienna (Regional Centre of Expertise on Education for Sustainable Development).

Authors & other contributors: 
Main authors of this report are Dr. Shermin Voshmgir, Tatjana Novakovic, Dr. Martin 
Wildenberg, Dr. Christian Rammel. Other contributions to this report have been provided by 
Valentin Kalinov, Armin GreinĂścker, Alberto Medina, Sofya Parfenova, Mirna Smoljan and 
Marc Johnson.



 

 

Table of Contents 

 

Executive Summary 3 

Introduction 4 

How to read this Paper 5 

Background of this Report 5 

Agenda 2030 & the SDGs 6 

Socio-ecological transformations & the SDGs 6 

Innovation and the SDGs 7 

Blockchain & the Web3 9 

Blockchain Networks 9 

Other Distributed Ledgers 11 

Smart Contracts 14 

Oracles 15 

Tokens 15 

Interoperability 16 

Scalability 17 

Legal Challenges 17 

Energy Consumption of Blockchain Networks 17 

“Good Governance” Applications 19 

Use Case 1: Supply Chains 20 

Use Case 2: Impact Assessment 25 

Use Case 3: Collective Value Creation with Purpose-Driven Tokens 27 

Use Case 4: Corruption Prevention 28 

Use Case 5: Inclusion of Undocumented  
& Underbanked 28 

Use Case 6: Impact Entrepreneurship 
& Impact Investment 29 

Use Case 7: Energy Markets 30 

Potential Pilot Projects 34 

SDG 7: 3Fsolar, Africa Green Tech & The Sun Protocol 34 

SDG12: WWF & Tuna 36 

Successful Project Implementation 37 

Rethinking Development Funding 38 

Outlook 40 

Overview of Blockchain Projects  
in ADA (Austrian Development Agency) Partner Countries 41 

References 48 

 



 
 

   

 
 



Executive Summary 
The report explores how blockchain networks           
as a backbone of the Web3 and the               
cryptoeconomic mechanisms that enable them         
can support achieving the SDGs defined by the               
United Nations. Cryptoeconomics and       
sustainability researchers of the Vienna         
University of Business and Economics have           
worked closely together examining blockchain         
networks and their applications, and         
researching relevant sustainability issues,       
analysing use-cases and identifying relevant         
stakeholders. Outputs of this applied research           
are provided in this report.  

Analysing the potential of blockchain         
applications for the implementation of the           
SDGs in partner countries of the Austrian             
Development Agency, we came to the           
conclusion that the most promising cases for             
the successful application of blockchain are           
found in the context of SDG 7 (affordable and                 
clean energy) and in the context of SDG 12                 
(responsible consumption and production).  

In the broad field energy, blockchain networks             
can build smart contracts, decentralized         
organizations and tokens which are driving           
radical innovations in decentralized,       
environmentally friendly energy supply       
systems while offering sound bridges to the             
community engagement aspects of energy         
networks. Blockchain networks can also         
provide quickly an effective and decentralised           
market structure between suppliers and         
consumers (or prosumers) which are of special             
importance in the development context,         
especially in regions, with a fundamental lack             
of infrastructure and efficient public         
institutions. 

In the context of consumption and production             
blockchain networks and other distributed         
ledgers can refer to its already well explored               
and well documented advantages in supply           
chain management and to its strengths in the               
increasingly important field of impact         

assessment. Herein, supply chain management         
as well as for impact assessment provide             
promising links to recent initiatives in the             
context of fair trade or the integration of               
regional stakeholders for decentralized impact         
assessment along international supply chains. 

By examining use-cases in a number of             
different fields and industries such as supply             
chain, energy, impact and entrepreneurship,         
the report outlines not only the possible             
benefits but also challenges, like the large             
energy consumption of the Proof-of-Work         
consensus mechanisms which is partly being           
tackled by tailoring alternative consensus         
mechanisms and planning the transitions to           
less energy demanding networks.       
Technological advancements like scalability and         
interoperability of blockchain networks and         
other distributed ledgers remain to be seen in               
the near future. The rigidity of current legal               
systems might slow down the process of             
overcoming legal challenges and jurisdictions’         
readiness to adapt to decentralised governance           
models.  

Recording data on distributed ledgers like           
blockchain networks requires a comprehensive         
system design that examines the economic,           
legal, environmental and societal implications         
of such data models and events that derive               
from them. Grasping the wide range of             
implications and aligning them towards         
desirable outcomes demands collaboration       
across different institutions, juristictions and         
knowledge domains and strong and long           
lasting relationships between all stakeholders. 

On the journey of achieving such           
collaborations, a lot more attention should be             
dedicated to interdisciplinary research than has           
been witnessed over the past 10 years. For               
future work, identifying the enablers of           
interdisciplinary collaborations and     
implementing them will play a crucial role for               
successful uses of blockchain technology. For           
example, clear communication across       
disciplines can be supported by agreeing on             
term definitions as in case with           

………………………………….………………………………….………………………………….…………………………………………………………………….………………………………….………………………………….… 
Sustainable Development Report:​ Blockchain, the Web3 & the SDGs     ​     p. 3  



“cryptoeconomics”, a term which has just           
recently been confirmed to be context           
dependent and been given different definitions           
in regard to micro, meso and macro             
perspectives (Voshmgir and Zarghan 2019). 

 

Introduction 
Emerging technological innovations in specific         
the Internet with all its applications and use               
cases are setting new trends that provoke             
radical cultural and socio-economic       
transformation. This ongoing trends, often         
referred to as “digital transformation”, already           
affects our way of living and will affect it even                   
more in the future. Among the most recent               
innovations blockchain networks as the         
backbone for the next generation Internet,           
what some also refer as the Web3, is seen by                   
many as a game changer which also could be a                   
potential catalyst for achieving the Sustainable           
Development Goals of the United Nations           
(SDGs) - especially in the development context.             
Moreover, blockchain networks are a         
governance layer on top of the current Internet               
with the potential to create new social- and               
market dynamics.  

However, there is also criticism about the             
negative social and ecological impacts         
blockchain applications might have. This also           
reflects the global debate on the impact of new                 
digital technologies and the often associated,           
dangerous reduction of sustainable       
development to purely technological aspects.         
Against this background, this research report           
enters new transdisciplinary territory and dares           
to attempt to find a balance within a field of                   
tension between belief in technology and           
technological fears. 

The primary aim of this paper is a critical                 
analysis of the opportunities and best practices             
of blockchain applications for achieving the           
SDGs. This joint publication will further provide             
key-criteria and recommendations for the         
implementation of specific Blockchain & SDGs           

pilot projects in the Austrian Development           
Agency (ADA) partner countries. Herein,         
companies and impact entrepreneurs will learn           
through the analysed use cases and guidelines,             
how the adoption of blockchain can support             
their SDGs related activities in the Global             
South. 

Socio-ecological transformations lay in the root           
of the Agenda 2030 and call for a radical                 
change from “doing things better” to “doing             
better things”. In order for the socio-ecological             
transformations to take place, we need to             
provide an institutional and socio-economic         
environment that will enable innovations as           
well as new societal, economic, technological           
and political models that go far beyond just               
increasing efficiency and productivity. In this           
regard, blockchain technologies and blockchain         
networks have the potential to support the             
infrastructure layer of such models,         
contributing to transparency, eliminating       
power asymmetries, enhancing accountability       
and incentivising environmentally friendly       
behaviour.   

This output paper will examine if and to which                 
extent Web3 based use cases like blockchain             
networks and similar distributed ledgers can           
enable the 2030 Agenda to deliver on its               
transformative promise.  

It might seem that with this focus, we address                 
mainly the field of technological innovations           
and their contributions to the Agenda 2020 and               
the SDGs. But as Web3 networks and their               
applications also provide entirely new modes of             
decision-making and governance, our focus         
extends the boundary of technological         
systems. 

The vision of Agenda 2030 stresses the need to                 
go beyond existing approaches of improving           
unsustainable systems and to transform them           
instead. Additionally, transformative change       
addresses social and economic structures and           
relations that drive unsustainable practices and           
call for alternative socio-economic trajectories.         
This means that if blockchain networks want to               
become real game-changers and help us to             

………………………………….………………………………….………………………………….…………………………………………………………………….………………………………….………………………………….… 
Sustainable Development Report:​ Blockchain, the Web3 & the SDGs     ​     p. 4  



implement the SDGs, they have to exhibit the               
characteristics of disruptive and transformative         
innovations. Contributing to more business as           
usual, and even providing a new wave of               
start-ups improving existing modes of         
production and consumption will be an           
essential first step, but it’s not enough. This               
papers will explore whether Web3 applications           
can also be used to find new forms of value                   
creation towards a more sustainable future. 

 

How to read this Paper 
This paper can be read from three different               
perspectives: For researchers we provide an           
integrative and critical overview of the           
potential of blockchain networks for reaching           
the SDGs, highlighting the most promising           
applications in the context of development           
cooperation. 

For companies and policy makers this paper             
offers a comprehensive analysis of the current             
state and shows existing best practice use             
cases. Herein, we provide concrete guidance           
and recommendations in the context of           
development collaborations and the SDGs. 

For those who aim to implement their own               
SDGs-oriented-blockchain project, we will offer         
a basic roadmap for potential pilot projects.             
Herein, the list of key-criteria and           
recommendations can be found, and these will             
assist in evaluating potential blockchain         
applications in the general context of           
development cooperation as well as with the             
SDGs. 

 

Background of this Report 
This report is an output paper of a research                 
collaboration funded by the Austrian         
Development Agency (ADA). The research was           
conducted by the Research Institute for           
Cryptoeconomics together with Regional       
Centre of Expertise on Education for           
Sustainable Development Vienna (RCE Vienna)         

both institutions of the Vienna University of             
Economics and Business (WU). 

During the first phase of the project, we               
explored and assessed the potential of           
blockchain networks to help address the SDGs.             
As a second step, pilot projects were defined in                 
the context of development cooperation. We           
used an integrative and case-study-based         
approach to analyse the potential connections           
and contributions of blockchain to the SDGs.             
Considering the multidimensional facets of the           
SDGs the term ​integrative reflects a systemic             
setting in which our target groups, such as               
impact entrepreneurs, development agencies,       
CSOs, business networks, and international         
institutions interact and share knowledge with           
those holding expertise in blockchain and           
derived technologies. The aim was to:  

● Map potential blockchain applications that 
can provide a significant contribution to 
the SDGs. 

● Disseminate information about existing 
players in the market,possible applications 
and research areas.  

● Consolidate the knowledge retrieved and 
identify future research and development 
needs for blockchain-based development 
projects.  

 

In addition to the theoretical work, a             
conference - ​(UN)BLOCKED - was held in April               
2019 at the Vienna University of Economics and               
Business. The aim was to bridge multifaceted             
gaps in knowledge between technological         
experts with those who work in sustainability,             
to find a common ground between policy             
makers and developers. 600 people attended           
the conference, from researchers to start-ups           
and policy makers, including representatives of           
local and international institutions. 

 

 

   

………………………………….………………………………….………………………………….…………………………………………………………………….………………………………….………………………………….… 
Sustainable Development Report:​ Blockchain, the Web3 & the SDGs     ​     p. 5  

https://unblock3d.net/


Agenda 2030  
& the SDGs 
The Agenda 2030 and its Sustainable           
Development Goals (SDGs) were born at the             
United Nations Conference on Sustainable         
Development in Rio de Janeiro in 2012. The               
objective was to produce a set of universal               
goals that meet the urgent environmental,           
political and economic challenges facing our           
world.  

The Sustainable Development Goals are often           
referred to as “a radical plan for humanity” and                 
a new way of “doing development”. They are               
organised into 17 goals, which cover 169 more               
detailed targets. The goals are holistic – they               
cover social, environmental and economic         
aspects, and they are interlinked – meaning             
they influence each other and cannot be dealt               
with in isolation. Although there has been some               
success in reaching a number of the targets like                 
e.g. poverty reduction or some of the             
health-related goals. However, our failure to           
achieve most of the others, e.g. preserving the               
natural fundament of our societies, will also             
render the successes useless in the future. 

The UN General Assembly adopted the 17 SDGs               
in New York in 2015. They are binding for all                   
signatory states, including Austria. The official           
title is ""Transformation of our world: Agenda             
2030 for sustainable development"". Agenda         
2030 is to be seen as a global plan for                   
reconciling ""dignity, peace and prosperity for           
man and nature now and in the future"". In their                   
third year of implementation, the countries are             
currently translating this common vision into           
national development plans and strategies (UN,           
2018). 

Although criticism in earlier draft versions of             
the SDGs was more or less ignored (Sachs               
2012), asking for more incentives for business             
(Hajer et al. 2015), demanding inclusion of Safe               
Operating Space, Planetary Boundaries and the           
activation of societies suggesting priorities (Lu           

et al. 2015), the international reaction was             
overwhelmingly positive. One of the reasons           
for this positive echo from science and civil               
society was the fact that the SDGs can be seen                   
as concrete guiding posts for both           
policymakers as well as for business. Positive             
assessments refer to individual targets and to             
the overall content, although some authors           
highlight that the expected thematic benefits           
arise only if the SDGs as a whole are taken into                     
account (e.g. Orme et al. 2015; Waage et al.                 
2015). 

Replacing the Millennium Development Goals         
(MDGs), the SDGs are not only highly relevant               
for developing countries - the SDGs are of               
enormous importance especially for       
industrialised countries such as Austria, as           
these countries are increasingly confronted         
with the task of acting as driving forces for a                   
necessary socio-ecological transformation and       
of driving it forward rapidly. Addressing the             
SDGs also means that traditional boundaries           
for classifying countries as developing or           
developed have to be rethought: when a             
sustainability lens is applied, all countries are             
“developing” (…). The fight against global           
warming, the progressive loss of biodiversity,           
the increasing scarcity of natural resources,           
global inequalities, but also developments such           
as digitalisation, automation and changing         
demographics are just some of the many             
problems that make innovation and above all             
courageous action in economic, ecological and           
social areas indispensable – in all parts of the                 
globe. 

 

Socio-ecological 
transformations & the SDGs 
“Transforming our world”, as the 2030 Agenda             
is titled, is a far more challenging task than                 
business as usual and it goes far beyond the                 
narrow focus on efficiency gains and           
technological progress. Regarding the       
imperative of change emphasised by the           
climate and biodiversity crisis and our crossing             

………………………………….………………………………….………………………………….…………………………………………………………………….………………………………….………………………………….… 
Sustainable Development Report:​ Blockchain, the Web3 & the SDGs     ​     p. 6  



of several other planetary boundaries, this task             
is very necessary, and it lies at the very heart of                     
sustainable development itself. Transformation       
requires attacking the root causes that           
generate and reproduce economic, social,         
political and environmental problems, not         
merely their symptoms. It means nothing less             
than a radical shift in the way we produce,                 
consume, and make our decisions (Global           
Sustainable Development Report 2019). 

Therefore, the new transformative 2030         
Agenda is more than welcomed and highly             
needed. Instead of segregated policies in           
separate domains and economic sectors, it           
could lead to policy integration and push for an                 
“eco-social” shift that helps us to embark on               
different socio-economic trajectories, both in         
terms of human well-being and inclusive           
development. Such a transformative agenda         
aims at doing better things and not at doing                 
things better. This emphasises doing things           
differently to achieve radically different         
outcomes, rather than doing more of the same               
but in a more efficient way. Such a vision of                   
radical change inspires hope for breaking the             
vicious circle of poverty, inequality and           
environmental destruction confronting people       
and the planet. 

Against this imperative of change, we have to               
ask ourselves, what needs to happen to enable               
the 2030 Agenda to deliver on its             
transformative promise? What kind of new           
models, innovations and new approaches to           
socio-economic development do we need to           
enhance necessary transformations? 

Referring to the implicit transformative         
fundament of the SDGs, the challenges of             
implementing the SDGs are challenges of           
initiating qualitative changes in different         
societal, technological, economic and political         
domains that are necessary to achieve the             
SDGs. Obviously, innovation is key to these             
challenges, but the term ​innovation goes far             
beyond improving the status quo through           
increased efficiency and productivity. 

Innovation and the SDGs 
Researchers, as well as the UN, agree that to                 
achieve the SDGs, transformational processes         
are necessary, and these go far beyond             
business as usual. It is required to attack the                 
root causes that “generate and reproduce           
economic, social, political and environmental         
problems and inequities, not merely their           
symptoms… Indeed, it is the vision of doing               
things differently to achieve radically different           
outcomes, rather than doing more of the same,               
that inspires hope for breaking the vicious             
circle of poverty, inequality and environmental           
destruction confronting people and the         
planet.” (UNDRISD 2016)  

The UNDRISD Flagship Report 2016 (UNDRISD           
2016) names three characteristics that mark           
desirable transformative change: (i) progressive         
(in a normative sense of social justice), (ii)               
systemic (addressing various factors       
simultaneously and in an interrelated way), and             
(iii) long term (cannot be easily reversed in the                 
short term). This calls for innovation that             
supports transformation – leaving us with the             
question how such innovation could be           
characterised. In their paper on         
sustainability-oriented innovation (SOI) Broken       
et al (2015) present a model that can also be                   
used to characterise the transformative         
potential of innovation (see figure below).  

 

Figure 1. Model of SOI. Adapted from ‘Sustainability-oriented               
Innovation: A Systematic Review, by Adam et al., 2015,                 
International Journal of Management Reviews, 18, p.180 -               
205 

………………………………….………………………………….………………………………….…………………………………………………………………….………………………………….………………………………….… 
Sustainable Development Report:​ Blockchain, the Web3 & the SDGs     ​     p. 7  



Broken et al distinguish between three types             
of innovation which are differentiated along           
the axis of their objectives, outcomes and their               
relationship to the company. The first type             
“Operational optimisation” has an efficiency         
focus (doing the same things better) and             
represents an old fashioned view on innovation             
– often also characterised by a           
technology-centred focus on innovation. This         
kind of innovation might reduce harm but does               
not contribute to a transformation as defined             
above. The two other types of innovation             
“Organisational transformation” and “System       
building” both focus on “doing good by doing               
new things” – the former approach also             
including a strong community or         
cooperation-centred approach. Both of them         
open the possibility to foster sustainable           
transformation. Both also apply a wider           
people-centred approach to innovation.  

In this light, we ask the question how can                 
blockchain as an emerging and novel           
technology contribute to the SDGs, e.g. by             
introducing new, transformative changes in         
relevant sectors. Keeping the SOI model in             
mind, the answer is that transformation           
potential depends more on the context of the               
innovation and the resulting application case           
then on the technology itself.  

Blockchain Networks offer the potential to           
foster and enable new business models – and               
through the use case of the Bitcoin network, it                 
has shown its transformational potential         
(although not in the sense of sustainable             
transformation) in the field of finances and             
banking. The increase in efficiency in           
transactions and the like that is often brought               
forward as the main contribution of the             
technology in the context of its transformative             
potential actually is the least impactful           
contribution to the needed sustainable         
transformations - although it might be the best               
selling point for blockchain projects towards           
companies locked in the first stage of SOI.  

On the other hand, its ability to create               
self-organised and independent systems       

together with its focus on fostering           
behavioural change has a big potential for             
businesses interested in the second and third             
stage of SOI. Important for all blockchain             
projects striving to support sustainability         
transformation through innovation is to shift           
the focus from purely technological fixes to             
problems to a more holistic view on             
sustainability problems, conceptualising them       
as socio-technological challenges. The effects         
of a cluster of elements like, for example,               
regulations, user practice and markets cultural           
meaning, infrastructure and supply networks         
have to be considered leading to innovation             
beyond pure technical domains, i.e. adopting           
new business models.  

Implementing transformative change requires       
innovative approaches: in conceptualising";"""date"",""2020-01-22T14:58:26Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.3""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dcterms:created"",""2020-01-22T14:58:26Z""
""language"",""en""
""Last-Modified"",""2020-01-22T14:58:26Z""
""dcterms:modified"",""2020-01-22T14:58:26Z""
""dc:format"",""application/pdf; version=1.3""
""Last-Save-Date"",""2020-01-22T14:58:26Z""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2020-01-22T14:58:26Z""
""meta:save-date"",""2020-01-22T14:58:26Z""
""pdf:encrypted"",""false""
""modified"",""2020-01-22T14:58:26Z""
""Content-Length"",""11667626""
""pdf:hasMarkedContent"",""false""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""meta:creation-date"",""2020-01-22T14:58:26Z""
""created"",""2020-01-22T14:58:26Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""62""
""Creation-Date"",""2020-01-22T14:58:26Z""
""resourceName"",""SustainableDevelopment%20Report_BlockchainWeb3_SDGs.pdf""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""63"",""775"",""1027"",""6"",""3912"",""3912"",""3425"",""3806"",""3549"",""3120"",""3788"",""4134"",""4052"",""3927"",""4184"",""3107"",""3904"",""3874"",""3569"",""3208"",""3259"",""3882"",""3582"",""4186"",""3948"",""4067"",""3922"",""3864"",""4497"",""3704"",""3969"",""4006"",""3891"",""3869"",""2401"",""3719"",""3492"",""4119"",""3153"",""2859"",""3165"",""3300"",""6"",""6"",""3523"",""5162"",""4075"",""4644"",""4797"",""4424"",""3405"",""6"",""6"",""4515"",""5836"",""4478"",""2530"",""4765"",""859"",""6"",""0"",""96""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""producer"",""Mac OS X 10.12.6 Quartz PDFContext""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""Mac OS X 10.12.6 Quartz PDFContext""
""pdf:docinfo:created"",""2020-01-22T14:58:26Z""
";https://scholar.google.com/scholar?start=450&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094546-675;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;DeMetrA-Decentralized Metering with user Anonymity and layered privacy on Blockchain;M Vasile, B Groza ; … Conference on System Theory, Control and …, 2019  ieeexplore.ieee.org;;"… without random oracles. In International Conference on the Theory and Applications of

Cryptographic Techniques, pages 223–238. Springer, 2004. [6] M. Cebe, E. Erdin, K. Akkaya,

H. Aksu, and S. Uluagac. Block4forensic: An integrated lightweight blockchain framework for …";Autres articles;;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/8880038/8885414/08885761.pdf?casa_token=qBq9XZ6QEZwAAAAA:2XyJ7n3yntTgMAZzHKgMar9S1HPz0c97wdJleuEYbGzRbE4vNrv0O0hAIsiKktb83PPWR2qj3D0;"
		Skip to Main Content


		
			
				
				

				

			

		


		
			
				
					
						








	
		
	

	







						

						





























	
	
		
	
	
		
			

		
	

	
	
	



						





	
	
		
			
				IEEE Account

					Change Username/Password
	Update Address


			

			
				Purchase Details

					Payment Options
	Order History
	View Purchased Documents


			

			
				Profile Information

					Communications Preferences
	Profession and Education
	Technical Interests


			

			
				Need Help?

					US & Canada: +1 800 678 4333
	Worldwide:  +1 732 981 0060

					
	Contact & Support


			

		

		
			
				
					
							About IEEE Xplore
	Contact Us
	Help
	Accessibility
	Terms of Use
	Nondiscrimination Policy
	Sitemap
	Privacy & Opting Out of Cookies


						
							A not-for-profit organization, IEEE is the world's largest technical professional organization dedicated to advancing technology for the benefit of humanity.
Š Copyright 2021 IEEE - All rights reserved. Use of this web site signifies your agreement to the terms and conditions.
						

					


					

				

				
			

		

	


	
	


						
						






		
		
		
		
		
		
		
		
		
		
		
		
		
			
				
			
			
			
			
		
		
		
		
		
		

			


			

			
			


		
 		
		
			 

						
						









































	

		
		

		
		
		

		
			
		
		
		

		

		
		


		

		
		
		
		
		
		
		
		
		
		
	
	


















		
		
			
				
					
					
								
					
								
			
				
					
					
								
					
								
			
				
					
						








 



					
					
								
			
				
					
					
								
			
				
					
					
								
					
								
			
				
					
					
								
					
								
			
				
					
					
								
					
								
			
				
					
					
								
					
								
			
				
					
					
								
					
								
			
				
					
					
								
					
								
			
		
	




























		
			
					
			
					
			
					
			
				
					








					
			
					
			
					
			
					
			
					
			
					
			
					
			
		
		
	





	
	
	
	
	
	
	


	
	
	

	

















					

				

			


			
				
			
		

	";"""og:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""twitter:title"",""DeMetrA - Decentralized Metering with user Anonymity and layered privacy on Blockchain""
""twitter:card"",""summary""
""Description"",""Wear and tear are essential in establishing the market value of an asset. From shutter counters on DSLRs to odometers inside cars, specific counters, that encod""
""og:title"",""DeMetrA - Decentralized Metering with user Anonymity and layered privacy on Blockchain""
""resourceName"",""08885761.pdf""
""language"",""en""
""title"",""DeMetrA - Decentralized Metering with user Anonymity and layered privacy on Blockchain | IEEE Conference Publication | IEEE Xplore""
""og:description"",""Wear and tear are essential in establishing the market value of an asset. From shutter counters on DSLRs to odometers inside cars, specific counters, that encode the degree of wear, exist on most products. But malicious modification of the information that they report was always a concern. Our work explores a solution to this problem by using the blockchain technology, a layered encoding of product attributes and identity-based cryptography. Merging such technologies is essential since blockchains facilitate the construction of a distributed database that is resilient to adversarial modifications, while identity-based signatures set room for a more convenient way to check the correctness of the reported values based on the name of the product and pseudonym of the owner alone. Nonetheless, we reinforce security by using ownership cards deployed around NFC tokens. Since odometer fraud is still a major practical concern, we discuss a practical scenario centered on vehicles, but the framework can be easily extended to many other assets.""
""twitter:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-UA-Compatible"",""IE=Edge""
""viewport"",""width=device-width, initial-scale=1.0""
""dc:title"",""DeMetrA - Decentralized Metering with user Anonymity and layered privacy on Blockchain | IEEE Conference Publication | IEEE Xplore""
""twitter:description"",""Wear and tear are essential in establishing the market value of an asset. From shutter counters on DSLRs to odometers inside cars, specific counters, that encode the degree of wear, exist on most products. But malicious modification of the information that they report was always a concern. Our work explores a solution to this problem by using the blockchain technology, a layered encoding of product attributes and identity-based cryptography. Merging such technologies is essential since blockchains facilitate the construction of a distributed database that is resilient to adversarial modifications, while identity-based signatures set room for a more convenient way to check the correctness of the reported values based on the name of the product and pseudonym of the owner alone. Nonetheless, we reinforce security by using ownership cards deployed around NFC tokens. Since odometer fraud is still a major practical concern, we discuss a practical scenario centered on vehicles, but the framework can be easily extended to many other assets.""
""Content-Encoding"",""UTF-8""
""Content-Type-Hint"",""text/html; charset=utf-8""
""Content-Length"",""41320""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=490&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094588-854;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Towards Blockchain-enabled Searchable Encryption;Q Tang ; International Conference on Information and …, 2019  Springer;;"… One of the notable examples is Ethereum, which is the second largest cryptocurrency system

after … r)\) which is a random value if \(\mathsf {H}\) is modelled as a random oracle. Therefore, the

Blockchain does not affect the privacy guarantee regarding all potential attackers: one …";Cité 2 fois;Les 3 versions;[PDF] arxiv.org;https://arxiv.org/pdf/1908.09564;"
Towards Blockchain-enabled Searchable Encryption

Qiang Tang

Luxembourg Institute of Science and Technology
5 Avenue des Hauts-Fourneaux

4362 Esch-sur-Alzette, Luxembourg
qiang.tang@list.lu

November 21, 2019

Abstract. Distributed Leger Technologies (DLTs), most notably Blockchain
technologies, bring decentralised platforms which eliminate a single trusted
third party and avoid the notorious single point of failure vulnerability.
Since Nakamoto’s Bitcoin cryptocurrency system, an enormous number
of decentralised applications have been proposed on top of these tech-
nologies, aiming at more transparency and trustworthiness than their
traditional counterparts. These applications spread over a lot of areas, e.g.
financial services, healthcare, transportation, supply chain management,
and cloud computing. While Blockchain brings transparency and decen-
tralised trust intuitively due to the consensus of a (very large) group of
nodes (or, miners), it introduces very subtle implications for other desir-
able properties such as privacy. In this work, we demonstrate these subtle
implications for Blockchain-based searchable encryption solutions, which
are one specific use case of cloud computing services. These solutions rely
on Blockchain to achieve both the standard privacy property and the new
fairness property, which requires that search operations are carried out
faithfully and are rewarded accordingly. We show that directly replacing
the server in an existing searchable encryption solution with a Blockchain
will cause undesirable operational cost, privacy loss, and security vul-
nerabilities. The analysis results indicate that a dedicated server is still
needed to achieve the desired privacy guarantee. To this end, we propose
two frameworks which can be instantiated based on most existing search-
able encryption schemes. Through analysing these two frameworks, we
affirmatively show that a carefully engineered Blockchain-based solution
can achieve the desired fairness property while preserving the privacy
guarantee of the original searchable encryption scheme simultaneously.

1 Introduction

With the prevalence of cloud computing, many organizations are outsourcing
their data and services to the cloud. By doing so, an organization or individ-
ual can enjoy a wide spectrum of benefits such as agileness and cost-saving.
Moreover, the cloud service provider can deploy sophisticated cybersecurity
solutions to meet the requirements from the relevant security regulations. It
is widely perceived that the big cloud service providers, such as Amazon and

ar
X

iv
:1

90
8.

09
56

4v
2 

 [
cs

.C
R

] 
 1

9 
N

ov
 2

01
9



Microsoft, provide better protection in practice than most organizations if they
do it by themselves. However, there are indeed drawbacks for the outsourced
data and corresponding operations, among which loss of privacy is the most sig-
nificant one. As the cloud service provider can observe the data usage patterns
and potentially have access to the plain data, it becomes a concern when the
data contains sensitive information. The issue becomes more complex when the
services are cross-border and need to comply with privacy regulations from dif-
ferent regimes. Besides privacy, the verifiability of outsourced computing tasks
might also be a serious concern. In order to save cost, the cloud service provider
might not carry out the promised tasks faithfully. At the end, the incomplete
or even flawed computing results might damage the client’s business severely.
Therefore, how to guarantee privacy and verifiability in outsourcing has been
an active research area for many years.

Regarding the potential computing tasks on outsourced data, search is the
most fundamental one. To cater to the privacy needs, searchable encryption is
a category of cryptographic primitives that allows data to be outsourced in an
encrypted form while still being able to be searched over. Searchable encryption
typically assumes a standard client-server setting, where a client outsources its
encrypted data to a cloud server, which can then search on the client’s behalf
without decrypting the data. Existing searchable encryption schemes can be
broadly classified into two settings. In the asymmetric setting [2], the client can
publish a public key, by which anybody can generate searchable encrypted data
and store it on the server. Later, the client, who has access to the private key,
can let the server search on its behalf by issuing a trapdoor. In the symmetric
setting [16], a client uses symmetric keys to encrypt its own data and stores
the ciphertexts on the server. Later on, as in the asymmetric setting, the client
can let the server search on its behalf by issuing a trapdoor. Compared to
the symmetric setting, the asymmetric setting poses higher challenges to data
privacy, as shown in [1]. This implies that asymmetric searchable encryption
schemes leak much more information in reality, and potentially make such
schemes very undesirable facing strong attackers.

In this paper, we focus on symmetric searchable encryption schemes and
show how to properly leverage Blockchain to achieve verifiability and more
properties without sacrificing privacy. Nevertheless, our discussions and ap-
proaches could also be applied to other tasks.

1.1 Preliminary on Symmetric Searchable Encryption

We assume the client has a database DB, which contains the files which will
be searched based on an inverted inverted index. We assume a basic version
of symmetric searchable encryption scheme which only consists of two stages
Setup and Search, with an example shown in Section 3.1. In the Setup stage,
the client extracts a keyword set W from the files in the DB and builds an
encrypted inverted index, which is then stored on the server. In the Search
stage, the client interacts with the server to search for the files which contain
any keyword w ∈ W.

2



Remark 1. Since search is done over an inverted index, the actual files are not
relevant anymore once the inverted index has been constructed. Therefore,
the protection of the real files from DB can be done separately (e.g. they can
be encrypted via standard symmetric encryption schemes and stored on the
same or a different server). As a result, the search will result in file identifiers
instead of real files. Some schemes support additional operations, such as add,
delete or update the encrypted index, while others enable more complex search
queries such as conjuncted keywords. We leave them out for simplicity reasons.
Nevertheless, extending our discussions to these more general schemes will be
an interesting and separate line of research work.

To facilitate our discussions, we provide a high-level workflow of both
stages. Existing schemes might optimize their performances or security with
very specific tricks, e.g. index data structure. Nevertheless, most of them follow
the workflow. In the Setup stage, the following operations will occur.

1. Run by the client, it first generates the key materials, namely private key(s).
2. Given the database DB, a keyword set W is extracted and a plaintext

inverted index is built. The index is informally a table, shown in Figure 1
for example, where each row contains the file identifiers associated with a
specific keyword. Note that the client might choose to pad the rows so that
they contain certain number of file identifiers, e.g. all rows can be padded
to contain the same number of file identifiers.

Fig. 1. Inverted Index Example

3. Using the private key(s), the client encrypts the inverted index and obtains
an encrypted form of it. Note that the encryption here means not only the
hiding of keyword and identifier information but also can be the hiding of
other pattern information such as the ordering of the encrypted keywords
and identifiers. Finally, the encrypted index is stored on the server.

In the Search stage, if the client wants to find all the file identifiers associated
with a keyword w, the following operations will occur.

1. Using the private key(s), the client generates a trapdoor Tw based on its
private keys(s) and w, and sends it to the server.

3



2. With the trapdoor Tw, the server can go through the encrypted index and
match those elements which contain the same keyword (i.e. w) as that em-
bedded in the trapdoor.

3. For the matched elements, the server recovers the associated file identifiers,
denoted as a set IDw and return them to the client.

1.2 Privacy and Fairness Challenges

Searchable encryption can be seen as a derivative of standard encryption primi-
tives, but it is more complex due to the fact that, concerning privacy, we need to
consider not only the encrypted index but also the trapdoors. If there is a secure
channel between the client and the server, then the server is the main privacy
attacker. Intuitively, we will expect at least the encrypted index or trapdoors
alone do not leak any information about the embedded keywords. This can be
formulated in a similar way to the semantic security property of encryption
schemes [9], and easy to achieve. However, the situation is more complex for
searchable encryption, due to the fact that search operations link the encrypted
index and trapdoors so that more information will be leaked. In more detail,
there are concerns of access pattern leakage and search pattern leakage.

– Informally, access pattern is the file identifier information resulted from the
client’s search queries.

– While, search pattern is about whether two trapdoors contain the same
keywords or not.

These two types of leakages are clearly closely related. After receiving several
trapdoors, even if the server might not learn the keywords, it can derive sta-
tistical information about the keywords based on access pattern. In practice,
the statistical information can disclose the search pattern and even lead to full
recovery of the keywords. Besides privacy, the other practical concern related
to searchable encryption is the verifiability of search results. As we have men-
tioned before, it is desirable for the server to assure the client that the search
results have come from a faithful execution of the protocol. On the other side, it
is also desirable that the server is rewarded properly for the faithful execution
of the search protocol. Follow the literature work, if a searchable encryption
solution satisfies both requirements simultaneously, we say it is fair.

So far, very little has been done to design privacy-preserving and fair search-
able encryption solutions, except for some recent solutions that leverage on
Blockchain to achieve fairness [4,10]. We note that there are verifiable symmet-
ric searchable encryption schemes, e.g. [3], which however only guarantee that a
semi-honest server will follow the protocol. Being a technology that brings trust
as many believe, Blockchain infact results in very subtle tradeoffs among the
desirable properties, e.g. privacy and verifiability. Unfortunately, these trade-
offs have been ignored by many researchers. As such, it remains as an open
question how well these recent searchable encryption solutions have addressed
the privacy and fairness requirements.

4



1.3 Contribution and Organisation

Our contribution in this paper is two-fold. We start by examining some recent
Blockchain-based searchable encryption solutions, i.e. [4,10]. We show that di-
rectly replacing the server of a searchable encryption scheme with a Blockchain
is a very undesirable solution. First of all, it introduces considerable cost with
respect to storing the encrypted index and executing the smart contract which
implements the search operation. Secondly, these solutions suffer from the in-
herent issues of Blockchain, e.g. the forking problem1. This might cause serious
usability issues for these solutions. Thirdly, the privacy concerns of the under-
lying scheme are amplified by the Blockchain platform. The access pattern and
search pattern leakages are exposed to all entities who can access the Blockchain.
To mitigate the identified issues in our analysis, we then propose two frame-
works that can be instantiated based on most existing searchable encryption
schemes. In both frameworks, search operations are carried out by the server(s)
as in the traditional schemes, while Blockchain is leveraged to achieve the fair-
ness property only.

The rest of this paper is organised as follows. In Section 2, we give a brief
summary to Blockchain technologies. In Section 3, we present and analyse the
existing Blockchain-based solutions. In Section 4, we present our new frame-
works and provide corresponding analysis. In Section 5, we conclude the paper.

2 Blockchain in a Nutshell

Since the seminal report from Nakamoto [11], the concept of Blockchain has
become very popular not only in the research community but also in the society
at large. Its popularity largely comes from the fact that it is the key enabling
technology for the variety of cryptocurrency systems, including Bitcoin 2 and
the altcoins, even though the history of both the idea of cryptocurrency and the
techniques in Blockchain can be traced back to much earlier era [13]. As a matter
of fact, today there are over 1600 such systems according to Wikipedia 3.

2.1 Blockchain Overview

Informally, the data on a Blockchain is organized in the form shown in Figure 2.
Depending on who maintains the chain (i.e. generate and approve new blocks),
Blockchain systems can be roughly divided into two categories. If anyone can
publish and approve a new block, it is permissionless. Otherwise, if only par-
ticular nodes are allowed to do it, it is permissioned. More details about the
categorisation can be found in the NIST report [18]. From now on, we refer to
these particular privileged nodes as miners in the paper.

1 https://en.wikipedia.org/wiki/Fork_(blockchain)
2 https://bitcoin.org/en/
3 https://en.wikipedia.org/wiki/List_of_cryptocurrencies

5

https://en.wikipedia.org/wiki/Fork_(blockchain)
https://bitcoin.org/en/
https://en.wikipedia.org/wiki/List_of_cryptocurrencies


Fig. 2. Blockchain Structure

As the core characteristic of Blockchain, repeatedly, a certain number of new
data entries (e.g. transactions) will be packed into a new block and appended
to the existing (longest) chain. In the case of Bitcoin Blockchain, a new block
also includes the hash value of the last block of the current chain. The block is
formed with some specific features, e.g. a proof of work needs to be carried out
so that the hash value of the new block contains some number of consecutive
zeros. The new block will be broadcast to the whole network, and it will be
accepted in the network after everything being validated. Depending on the
variants and implementations, there are many subtle details on how a block is
formed and accepted to the chain, we refer the readers to the corresponding
technical specifications for the precise information.

Besides cryptocurrencies, Blockchain systems act as the key foundation plat-
form for smart contracts, which facilitate automated execution of software pro-
grams in a verifiable manner. One of the notable examples is Ethereum 4, which
is the second largest cryptocurrency system after Bitcoin and gains the popu-
larity because of its powerful smart contracts functionality. In practice, smart
contracts can enable a variety of trustworthy distributed applications, e.g. build-
ing digital Decentralized Autonomous Organizations (DAOs).

It is worth noting that Blockchain represents one special case of the broader
distributed ledger technologies (DLTs), which are decentralised databases that
rely on independent computers to record, share and synchronize digital transac-
tions. In many cases, say IOTA 5 and Hyperledger 6, the decentralised database
is not organised in a single chain of blocks. Instead, it can be a graph (e.g. IOTA)
or multiple chains of blocks (e.g. Hyperledger). Despite the different forms, a
DLT can possess similar properties to those from a Blockchain. For a more com-
prehensive review of cryptocurrencies, Blockchain and DLT technologies, we
refer the readers to the comprehensive books such as [8,12,17].

4 https://www.ethereum.org/
5 https://www.iota.org/
6 https://www.hyperledger.org/

6

https://www.ethereum.org/
https://www.iota.org/
https://www.hyperledger.org/


2.2 Properties of Blockchain

Regardless of the forms of a Blockchain or DLT in general, the following useful
properties can be expected.

– Democracy and Decentralised Control. Everyone can potentially act as a miner
and has the same privilege to generate blocks and approve blocks to the
Blockchain. This is generally true for systems employing the proof of work
(PoW) as the consensus mechanism in the permissionless scenario, while
it can be different in other cases. Regardless, Blockchain eliminates a sin-
gle fully trusted party and avoids the single point of failure vulnerability
correspondingly.

– Integrity and Immutability. If an attacker or a group of colluded attackers does
not dominate the consensus process, e.g. in the case of Bitcoin Blockchain
more than 51% of the computing power is at the hands of semi-honest
miners (see the explanation below for the semi-honest assumption), then it
will not be able to modify the existing blocks that have been agreed on by
the consensus.

– Consistency. There is a single consistent view of the chain even facing strong
attackers, based on assumptions mentioned above. However, note that when
nodes deviate from the predefined rules, forks could be generated and there
will be different views from different players, e.g. in the case of Ethereum7.

These properties further provide certain levels of auditability and trans-
parency, and generally increase the trustworthiness of the system. These afore-
mentioned properties or even a subset of them can be very desirable for many
applications from different sectors. Some people have considered Blockchain as
a trust machine for the society 8. The trust that users have towards Blockchain
systems is mainly from the fact that the majority of miners will be semi-honest
from the cryptographic perspective. The semi-honest assumption basically says
that these miners will follow the predefined protocols to perform what has
been specified and programmed in the Blockchain software, and particularly
this excludes the possibility that they will collude to interfere with the nor-
mal Blockchain operations. For PoW-based Blockchain, the trust depends on
the common assumption that 51% of the computing power lies at the hands
of semi-honest miners. While for other types of Blockchain, corresponding as-
sumptions need to be made. For example, for Proof of Stake (PoS)-based DLTs,
we need to assume that the parties that possess the majority of stakes will
behave honestly.

Besides cryptocurrencies, Blockchain has been widely promoted in design-
ing decentralised protocols, e.g. fair secure multiparty computation protocols
[6], confidentiality-preserving smart contracts [5], double auction [19], and the
Blockchain-based searchable encryption schemes [4,10]. In most of these works,
Blockchain is treated as a trusted platform that achieves some of the aforemen-
tioned properties persistently. However, we observe a dilemma with this trust

7 https://en.wikipedia.org/wiki/Ethereum
8 https://www.economist.com/leaders/2015/10/31/the-trust-machine

7

https://en.wikipedia.org/wiki/Ethereum
https://www.economist.com/leaders/2015/10/31/the-trust-machine


assumption and raise concerns about the feasibility of (some) existing solutions.
Let’s suppose a client originally deploys a service at a dedicated cloud server,
and now it wants to leverage Blockchain to improve the security.

– On one hand, all the promises of a Blockchain come from the holy assump-
tion that no single entity can significantly influence the operations of the
system and everything should be based on a consensus 9. This means that
a normal user like the client, will not play any significant role, particularly
the client may not be able to determine the miners or even know them.

– On the other hand, from the perspective of the client, it may desire absolute
certainty regarding the status of the Blockchain, the promised properties,
and other aspects such as efficiency and cost. Unfortunately, the satisfaction
of these requirements will depend on the consensus of some entities, which
are not supposed to be influenced by the client.

Clearly, there is a governance dilemma facing the client when it wants to de-
ploy its service on Blockchain. More consequences of this dilemma can be found
in Section 3.2 and 3.3. Nowadays, this dilemma is hindering the deployment of
Blockchain-based services , e.g. see the IBM-Maersk case 10.

3 Blockchain-enabled Searchable Encryption

In this section, we first briefly recap the Blockchain-based searchable solutions
from [4,10], and then present our analysis results from the economic, security
and privacy aspects.

3.1 Description of the Existing Solutions

The central idea of solutions from [4,10] is to treat Blockchain (that supports
smart contracts) as a transparent and neutral platform. Intuitively, these solu-
tions just replace the server in traditional scenarios with a Blockchain, which
interacts with the client via a smart contract. All search and fairness-related
logics are programmed into the smart contract. Based on the transparency and
neutrality assumptions, the following notion of ”fairness” can be achieved: (1)
search operations will be performed in the pre-defined manner if we assume
that a majority of the miners will not collude with each other; (2) the miner(s)
will be rewarded for their search operations due to the fact that deposits are
required before any search operation is carried out.

Let the client’s database be denoted asDB. Next we review the solution from
[10]. For simplicity, we only review the Setup and Search stages, while skipping
the add and delete stages as they do not affect our analysis.

– Setup(DB, λ): run by the client, the following operations are performed.

9 In fact, it is more complex when it comes to questions such as how the evolution of a
Blockchain platform should proceed, see the case of Bitcoin Blockchain

10 https://www.coindesk.com/ibm-blockchain-maersk-shipping-struggling

8

https://www.coindesk.com/ibm-blockchain-maersk-shipping-struggling


1. Initialize an empty list L, an empty dictionary σ, a counter c, and a block
size p.

2. Extract a keyword setW fromDB.
3. Select two pseudorandom functions F and G; Generate a secret key

K $
← {0, 1}λ.

4. For every keyword w ∈ W, do the following
(a) Compute K1 = F(K, 1||w) and K2 = F(K, 2||w), where || is a concatena-

tion operator.
(b) Set Îą = b

|DB(w)|
p c and c = 0, where DB(w) is the file identifier set

associated with w and |DB(w)| indicates the number of identifiers in
the set.

(c) Divide DB(w) into Îą + 1 blocks, and pad the last block into p entries
if necessary.

(d) For each block in DB(w), do the following

i. Set ĩd = id1|| ¡ ¡ ¡ ||idp, r $
← {0, 1}λ, d = ĩd ⊕G(K2, r), l = F(K1, c).

ii. Add (l, d, r) to the list L in lex order.
iii. Set c = c + 1.

5. Set EDB = L, partition EDB into n blocks EDBi (1 ≤ i ≤ n) and send them
to the smart contract.

6. For each received EDBi, the smart contract parses each entry in EDBi
into (l, d, r) and add it to the Blockchain.

– Search(K,w; ∗): run between the client and the Blockchain (via the smart
contract), the following steps are followed.

1. The client computes K1 = F(K, 1||w), K2 = F(K, 2||w).
2. The client sets c = 0, and sets an iteration number R and step size step.
3. For 0 ≤ i ≤ R, do the following

(a) The client sets STi = (K1,K2, c) and sends it to the smart contract.
(b) The smart contract asserts the gas cost is lower than the balance, and

then performs the following steps for i = 0 until i ≥ step. Note that
the solution assumes an Ethereum platform.

i. Set ` = F(K1, c).
ii. If Get(`) =⊥ stop; otherwise, set the result to be (d, r). The Get

function simply retrieves the tuple with the same `.
iii. Compute ĩd = d ⊕G(K2, r);
iv. Parse and save ĩd.
v. Set c = c + 1.

vi. Set i = i + 1.

The solution from [4] is pretty the same as the above solution. The main
difference is that it assumes a specific electronic health record (EHR) application
scenario and the keyword is in the form of an expression like ”(disease = ‘disease
name‘) AND (num1 ≤ age ≤ num2)”.

9



3.2 General Analysis w.r.t. Blockchain Usage

From an economic perspective, in comparison to a dedicated server based solu-
tion, it is clear that a Blockchain-based solution will incur more costs regarding
storage and computations, because several miners will need to perform the
same tasks in parallel. The computational cost might become a more significant
concern if a PoW-based consensus is employed by the underlying Blockchain
platform. In connection to fairness, one hidden concern is about the cost model
for the miners of the Blockchain. By default, it is common to estimate the cost
of operations based on the computations incurred by the smart contract execu-
tions. However, the real cost for the miners goes beyond that. For example, there
is also cost for the communication and storage. In addition, the miners need to
guarantee their availability for the searchable encryption services, which means
investment in security and diaster recovery countermeasures. In the proposed
solutions [4,10], it remains as a question how the client should estimate these
costs and include them in the offer. In connection to search complexity, a potential
concern is the storage of the encrypted index when addition and deletion are
enabled11. Suppose the Blockchain serves for searchable encryption services for
many clients, it will be the case that the newly added encrypted index for a
specific client will be stored in block(s) which are far away from those storing
the previous encrypted index. This means the search operation may need to
traverse through the whole chain to cover all relevant indexes for the specific
client. The situation gets much worse if a permissionless Blockchain is employed
because other applications will add a tremendous number of blocks over the
time.

Contrary to the common belief that Blockchain could act as a ”trust” ma-
chine to build secure applications, it actually brings its inherent security risks
that can be fatal to the applications on top. One prominent security issue is
around smart contracts, where one well-known example is the decentralized
autonomous organization (DAO) attack in 201612, which has exploited some
software bugs in the underlying Ethereum smart contracts, that leads to the
transfer of 3.6 million Ether to the attacker’s account. As a result of the attack,
the Ethereum Blockchain had to make a hard fork due to the lack of a unani-
mous consensus on the solution. Besides smart contracts, Blockchain systems
in general are also subject to other attacks, e.g. those against consensus mech-
anisms and distributed denial-of-service (DDoS) attacks [15]. In the traditional
setting, these issues might be easier to avoid or solve, or at least they can be
solved much more quickly.

3.3 Specific Analysis w.r.t. Privacy Guarantee

As noted in Section 1.2, almost all searchable encryption schemes leak certain
information to the server. Although a symmetric searchable encryption scheme

11 Note that such features are included in the solution by Hu et al. [10].
12 https://en.wikipedia.org/wiki/The_DAO_(organization)

10

https://en.wikipedia.org/wiki/The_DAO_(organization)


leaks less than its asymmetric counterpart, the leakage might still be considered
to be non-negligible. Take the scheme from Section 3.1 as an example, there are
(at least) two kinds of leakages, which are commonly shared by other similar
schemes.

– search pattern leakage. The Search algorithm is a deterministic function. This
means that if the client searches the same keyword more than once, then
the Blockchain miners will notice it. Based on such information, statistics
such as frequency of searched keywords can be established. In turn, such
statistics may allow the miners to recover the underlying keywords.

– access pattern leakage. In the Setup(DB) algorithm, DB(w) will be padded
to guarantee that every block has exactly p entries. However, this padding
operation does not anonymize the index length very well. Let’s assume
DB(w1) has p+1 entries and DB(w2) has 2p+1 entries. In this case, even after
the padding, the keyword w2 will result in p more entries on the Blockchain
than the keyword w1. As a result, the Search operation may reveal the size
relationship of the file identifier sets associated with the searched keywords.

Specific to this scheme, it is undesirable to reveal ĩd to the smart contract.
Nevertheless, this can be easily resolved by not sending K2 to the smart contract
and instead the client decrypts d by itself to recover ĩd at the end of the search
operation.

In comparison to the traditional scenario without using a Blockchain, where
the privacy information leakage is only limited to a single server, the leakage is
amplified in Blockchain-based solutions. The degree of the amplification effect
depends on which type of Blockchain is chosen by the solution.

– If a permissionless Blockchain is used, then the information leakage is avail-
able to everybody on the Internet. This is very likely not acceptable.

– If a permissioned Blockchain is used, then the information leakage is pro-
visionally available to those entities that can access the Blockchain. At the
first glance, the privacy issue is less serious than the other case. However,
the situation is rather complex, unless the searchable encryption scheme is
deployed on a dedicated Blockchain where the right to read the Blockchain
data is controlled by the client. Otherwise, the client will have no control
over who will see its encrypted index and search history (e.g. no control
over who will be the miners), which means it suffer from unexpected pri-
vacy leakage. This exemplifies the dilemma stated in Section 2.2.

For searchable encryption applications, the immutability property of Blockchain
might not be really necessary. In the contrary, this property might be undesir-
able concerning privacy protection. If the encrypted index and search histories
live forever on a Blockchain, then it will stay as a persistent attack surface for
any (emerging) attackers.

3.4 Summary and Roadmap

So far, we have analysed the advantages as well as disadvantages of Blockchain-
based solutions. Our analysis indicates that a solution built directly based on

11



a Blockchain, either permissioned or permissionless, causes issues from differ-
ent aspects, including cost, security and privacy. For the studied solutions, it
seems that the disadvantages will outweigh the advantages in practice. Nev-
ertheless, this does not imply that Blockchain is useless for these applications,
rather we believe that Blockchain will be a very useful tool to guarantee the
fairness property. Without it, it will be a very sophisticated task to design fair
and privacy-preserving searchable encryption solutions, and it may need to
make significant changes to existing privacy-preserving searchable encryption
schemes.

Based on our analysis, towards designing privacy-preserving and fair search-
able encryption solutions, a modular approach seems more appropriate: exploit-
ing Blockchain for the fairness guarantee and relying on dedicated server(s) for
the actual search operations on the basis of an existing searchable encryption
scheme. The key challenge is to guarantee that the involvement of Blockchain
does not affect the privacy guarantees of the underlying searchable encryption
scheme. This leads to two new frameworks in the next section.

4 New Generic Blockchain-based Frameworks

In this section, we propose two generic Blockchain-based frameworks, that can
be instantiated based on most symmetric searchable encryption schemes. In
both frameworks, there are three types of entities involved.

– Client: The client is the party that wants to outsource its encrypted index.
– Server(s): As in the traditional setting, the server(s) store the encrypted index

and carry out the search operations.
– Blockchain: The Blockchain acts as a semi-trusted platform to ensure fairness.

We assume there is a secure communication channel ( for confidentiality
and integrity) between the client and all server(s), while there is no such a link
between any entity and the Blockchain";"""date"",""2019-11-21T01:49:00Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2019-11-21T01:49:00Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016) kpathsea version 6.2.2""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2019-11-21T01:49:00Z""
""created"",""2019-11-21T01:49:00Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-11-21T01:49:00Z""
""resourceName"",""1908.09564""
""Author"",""""
""producer"",""pdfTeX-1.40.17""
""pdf:docinfo:producer"",""pdfTeX-1.40.17""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""5"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""2"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2019-11-21T01:49:00Z""
""Last-Modified"",""2019-11-21T01:49:00Z""
""dcterms:modified"",""2019-11-21T01:49:00Z""
""title"",""""
""Last-Save-Date"",""2019-11-21T01:49:00Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2019-11-21T01:49:00Z""
""meta:save-date"",""2019-11-21T01:49:00Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016) kpathsea version 6.2.2""
""Content-Length"",""498184""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""20""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""2262"",""2724"",""1848"",""2544"",""2319"",""1845"",""2592"",""2358"",""1616"",""2598"",""2563"",""2344"",""1297"",""2699"",""2637"",""1292"",""2377"",""2566"",""2561"",""2493""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-11-21T01:49:00Z""
";https://scholar.google.com/scholar?start=670&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094558-723;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[HTML][HTML] An efficient linkable group signature for payer tracing in anonymous cryptocurrencies;L Zhang, H Li, Y Li, Y Yu, MH Au, B Wang ; Future Generation Computer …, 2019  Elsevier;;"… address this issue by proposing a linkable group signature for signing cryptocurrency transactions,

which can be used to trace a payer's identity in consortium blockchain based anonymous … achieves

full-anonymity, full-traceability and linkability in the random oracle model …";Cité 10 fois;Les 7 versions;[HTML] sciencedirect.com;https://www.sciencedirect.com/science/article/pii/S0167739X19303115?casa_token=JuytUlAT_rsAAAAA:J2XHiSeDKc2VrWtHRdnoc6BMB4HzZIqSOHdEtlFivxEyq6gadEYx8NwixzznItjZGCKUqiqI;;;https://scholar.google.com/scholar?start=540&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094614-969;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Tight proofs of space and replication;B Fisch ; Annual International Conference on the Theory and …, 2019  Springer;;"… It has been proposed as an alternative Sybil resistance mechanism (eg for a blockchain) that

is not only ASIC resistant and eco-friendly, but … the pebbling game, but involves a cryptographic

hash function \(H: \{0,1\}^{dm} \rightarrow \{0,1\}^m\), often modeled as a random oracle …";Cité 24 fois;Les 4 versions;[PDF] iacr.org;https://eprint.iacr.org/2018/702.pdf;"
Tight Proofs of Space and Replication

Ben Fisch

Abstract

We construct a concretely practical proof-of-space (PoS) with arbitrarily tight security
based on stacked depth robust graphs and constant-degree expander graphs. A proof-of-space
(PoS) is an interactive proof system where a prover demonstrates that it is persistently using
space to store information. A PoS is arbitrarily tight if the honest prover uses exactly N
space and for any Îľ > 0 the construction can be tuned such that no adversary can pass
verification using less than (1 − ε)N space. Most notably, the degree of the graphs in our
construction are independent of Îľ, and the number of layers is only O(log(1/Îľ)). The proof
size is O(d/Îľ). The degree d depends on the depth robust graphs, which are only required
to maintain Ω(N) depth in subgraphs on 80% of the nodes. Our tight PoS is also secure
against parallel attacks.

Tight proofs of space are necessary for proof-of-replication (PoRep), which is a publicly
verifiable proof that the prover is dedicating unique resources to storing one or more retriev-
able replicas of a file. Our main PoS construction can be used as a PoRep, but data extraction
is as inefficient as replica generation. We present a second variant of our construction called
ZigZag PoRep that has fast/parallelizable data extraction compared to replica generation and
maintains the same space tightness while only increasing the number of levels by roughly a
factor two.

1 Introduction

Proof-of-space (PoS) has been proposed as an alternative to proof-of-work (PoW) for applications
such as SPAM prevention, DOS attacks, and Sybil resistance in blockchain-based consensus
mechanisms [18, 21, 31]. Several industry projects1 are underway to deploy cryptocurrencies
similar to Bitcoin that use proof-of-space instead of proof-of-work. Proof-of-space is promoted
as more egalitarian and eco-friendly that proof-of-work because it is ASIC-resistant and does
not consume its resource (space instead of energy), but rather reuses it.

A PoS is an interactive protocol between a prover and verifier in which the prover use
a minimum specified amount of space in order to pass verification. The protocol must have
compact communication relative to the prover’s space requirements and efficient verification. A
PoS is persistent if repeated audits force the prover to utilize this space over a period of time.
More precisely, there is an “offline” phase in which the prover obtains challenges from a verifier
(or simulates them non-interactively via Fiat-Shamir), generates an advice string S that it stores,
and outputs a compact tag τ to the verifier. This is followed by an “online” challenge-response
protocol in which the prover uses its advice S to efficiently compute responses to the verifier’s
challenges. The soundness of the PoS relies on timing bounds on the online prover’s runtime
enforced by frequent verifier audits. Timing bounds are necessary as otherwise the prover could

1https://chia.net/,https://spacemesh.io/, https://filecoin.io/

1

https://chia.net/
https://spacemesh.io/
https://filecoin.io/


store its compact transcript and simulate the setup to re-derive the advice whenever it needs
to pass an online proof. If the PoS resists parallelization attacks then it is unconditionally
secure in this audit model because the prover must use the minimum amount of space to pass
challenges within the wall-clock time allotted. Alternatively, soundness is reasoned through a
cost benefit analysis; it is assumed that a rational prover will not trade significant computation
for a relatively small reduction in its space utilization.

In an (S, T )-sound PoS protocol where the prover commits to persistently utilize N blocks of
space, the honest prover uses S = O(N) persistent space and any adversary who passes audits
in less than time T provably uses S = Ω(N) space. There is generally a gap between the honest
space utilization and the lower bound on the adversary’s space. If the honest prover uses N
space and some adversary might be able to use ÎľN space then this PoS has an Îľ space gap. A
tight PoS makes Îľ arbitrarily small depending on a construction parameter that will typically
impact concrete efficiency. All else equal, a tighter PoS is obviously more desirable as it has
tighter provable security. Nearly all existing PoS constructions have enormous space gaps [2,18],
including those that are currently being used in practice. The one exception is a recent PoS
protocol by Pietrzak [33] based on depth robust graphs, although it does not achieve a tight
space gap for concretely practical parameters.

Proof-of-replication (PoRep) [1, 19, 20, 33] is a recently proposed hybrid of PoS with proof-
of-retrievability (PoR) [23]. A PoR demonstrates that the prover can retrieve a particular data
file of interest, either known to the verifier, committed in a public commitment, or privately
preprocessed by a client who produces a verification tag for the file. A PoRep demonstrates
that the prover is dedicating unique resources to storing a retrievable copy of the file, and is
therefore a useful proof of space. It has therefore been proposed as an alternative Sybil resistance
mechanism that is not only ASIC resistant and eco-friendly, but also has a useful side-effect: it
provides file storage on real data. Furthermore, since the prover may run several independent
PoReps for the same file that each require unique resources, PoReps may be used as a publicly
verifiable proof of data replication/duplication.

A PoRep is required to be a PoS, and its security as a proof of data replication is closely
related to the space gap of the PoS. Formally, the security notion for PoReps is Îľ-rational
replication [19], which says that an adversary can save at most an Îľ fraction of its space by
deviating from storing the data in a replicated format. Storing data in a replicated format
is therefore an Îľ-Nash-equilibrium. This is the best possible security notion because a prover
can always sabotage its replicated format by scrambling its storage in an efficiently decodable
(yet no longer replicated) way. A PoRep that satisfies Îľ-rational replication is also a PoS with
an Îľ space gap. Intuitively, if a PoRep is not a tight proof of space then there may be some
adversary that would be rationally incentivized to deviate from honest behavior and therefore
likely destroy the replication format. This gives a whole new relevance to tight proofs of space,
because the security of PoReps is only meaningful when Îľ is reasonably small.

The goal of this work is to construct a practical and provably tight PoS that can also be
used as PoRep that satisfies Îľ-rational replication for arbitrarily small Îľ.

1.1 Related work

The original PoS of Dziembowski et. al. [18] was based on hard to pebble directed acyclic graphs
(DAGs), using a blend of techniques from superconcentrators, random bipartite expander graphs
and depth robust graphs [32]. During the offline initialization the prover computes a certain

2



labeling of the graph using a collision-resistant hash function where the label ev on each node
v ∈ G of the graph is the output of the hash function on the labels of all parent nodes of v. It
outputs a commitment to this labeling along with a proof (either interactive or non-interactive)
that the committed labeling was “mostly” correct. This offline proof consists of randomly
sampled labels and their parent labels, which the verifier checks for consistency. During the
online challenge-response phase the verifier simply asks for random labels that the prover must
produce along with a standard proof that these labels are consistent with the commitment.
Their construction leaves a space gap of at least 1− 1

512 .
The construction of Ren and Devadas from stacked bipartite expander graphs dramatically

improved on the space gap, although it is not secure against parallel attacks. Their construction
involves Îť levels V1, ..., VÎť consisting of n nodes each, with edges between the layers defined by
the edges of a constant-degree bipartite expander. The prover computes a labeling of the graph
just as in the Dziembowski et. al. PoS, however it only stores the labels on the final level.
Otherwise, the protocol is roughly the same. Their construction still leaves a space gap of at
least 1/2 (and much larger with practical parameters, e.g. their construction requires at least
degree 40 graphs to achieve a space gap of less than 2/3).

Recently, Abusalah et. al. [2] revived the simple PoS approach based on storing tables of
random functions. The basic idea is for the prover to compute and store the function table
of a random function f : [N ] → [N ] where f is chosen by the verifier or a random public
challenge. During the online challenge-response the verifier simply asks the prover to invert f
on a randomly sampled point x ∈ [n]. The intuition for why this should be secure is that a
prover who has not stored most of the function table will likely have to brute force f−1(x),
performing Ω(N) work. Unfortunately, this simple approach fails to be a PoS due to Hellman’s
time/space tradeoffs which enable a prover to succeed with S space and T computation for any
ST = O(N). However, Abusalah et. al. build on this approach to achieve a provable time/space
tradeoff of SkT = Ω(εkT k). This PoS is not secure against parallel attacks, and also has a very
large (even asymptotic) space gap of 1− 1

64 logN .
Pietrzak [33] and Fisch et. al [20] independently proposed a simpler variant of the graph

labeling PoS by Dziembowski et. al. based solely on pebbling a depth robust graph (DRG).
A degree d DAG on n nodes is (ι, β)-depth robust if any subgraph on ιn nodes contains a
path of at least length βn. It is trivial to construct DRGs of large degree (a complete DAG is
depth robust), but much harder to construct DRGs with small (constant or poly-logarithmic)
degree. Achieving constant α, β is only possible asymptotically with degree Ω(logN). Simply
instantiating the graph labeling PoS on a DRG results in a PoS with a 1 − α space gap that
is also secure against parallel attacks. Fisch et. al. also suggested combining this labeling PoS
with a verifiable delay function (VDF) [11] to increase the expense of labeling the graph without
increasing the proof verification complexity. The delay on the VDF can be tuned depending on
the value of n. Both of these constructions were proposed in the context of designing PoReps.
In this variant of the PoS protocol, the prover uses the labeling of the graph to encode a data
file on n blocks D = d1, ..., dn. The ith label ei is computed by first deriving a key ki by hashing
the labels on the parents of the ith node, and then setting ei = ki ⊕ di. If all the labels are
stored then any data block can be quickly extracted from ei by recomputing ki. We’ll call this
a DAG encoding of the data input. The VDF approach uses an additional encoding scheme
(enc, dec) inside the DAG encoding, where enc is sequentially slow and dec is fast, to derive
ei = enc(ki ⊕ di). The data is decoded by computing di = dec(ei ⊕ ki).

The labeling PoS on a DRG is not technically a tight PoS because decreasing Îą also decreases

3



the time bound βn on the prover’s required computation to defeat the PoS. Moreover, while
there exist constructions of (ι, β) DRGs for arbitrarily small ι, these constructions are purely
theoretical and are not viable in practice. Pietrzak [33] improved on the basic construction by
relying on a stronger property of special DRGs [6, 32] that are (ι, β,O(log n/ξ))-depth robust
for all (α, β) such that 1−α+ β ≥ 1− ε. In Pietrzak’s modified construction, the prover builds
a DRG on 4n nodes and only stores the labels on the topologically last n nodes. This can
similarly be used as a PoRep where the data is encoded only on the last level and the labels on
previous levels are just used as keys. This sacrifices on data extraction time because extracting
the data requires recomputing most of the keys from scratch, which is as expensive as the PoS
initialization.

Pietrzak shows that a prover who deletes an ε′ fraction of the labels on the last n nodes
will not be able to re-derive them in fewer than n sequential steps. The value ε′ can be made
arbitrarily small, but at the expense of increasing the degree of the graph proportionally to
1/ε′. Moreover, although these special DRGs achieve asymptotic efficiency and are incredibly
intriguing from a theoretical perspective, they still do not have concretely practical degree.
According to the analysis in [6], achieving just a 1/2 space gap with a PoS on N 32 byte
data blocks in Pietrzak’s construction would require instantiating these graphs with degree
2, 760 logN . The proof size is at least O(Îťd), so even for Îť = 10 (i.e. 10 bit security) and
N = 230 the proof size would be at least 26MB. Furthermore, as Îľ decreases Îť = O(1/Îľ) to
maintain the same security level. To achieve a space gap of 1/10 with 10-bit security would
require d = 19, 310 logN and Îť = 60 for a proof size of at least 1GB.

Boneh et. al. [11] describe a simple PoRep (also a PoS) just based on storing the output
of a decodable VDF on N randomly sampled points, which generalizes an earlier proposal by
Sergio Demian Lerner [25]. This is in fact an arbitrarily tight PoS with very practical proof sizes
(essentially optimal). However, the time complexity of initializing the prover’s O(N) storage
is O(N2), and therefore is not practically feasible for large N . This construction is similar to
the PoS based on storing function tables [2], but uses the VDF as a moderately hard (non-
parallelizable) function on a much larger domain (exponential in the security parameter) and
stores a random subset of its function table. The reason for the large initialization complexity
is that the prover cannot amortize its cost of evaluating the VDF on the entire subset of points.

In an independent concurrent work, Cecchetti et. al [14] developed a similar idea to our
stacked DRGs, using butterfly networks instead of expander graphs, to construct a primitive
they called publicly incompressible encodings (PIEs). We elaborate on a comparison in the
Appendix.

1.2 Summary of Contributions

We construct a new tight PoS based on graph labeling with asymptotic proof size O(logN/Îľ)
where Îľ is the achieved space gap. We can instantiate this construction with relatively weak
depth robust graphs that do not require any special properties other than retaining Ω(N) depth
in subgraphs on some constant fraction of the nodes bounded away from 1 (e.g. our concrete
analysis is for 80% subgraphs).

PoS from Stacked DRGs Our basic approach is a combination of the stacked bipartite
expanders of Ren and Devadas [35] with depth robust graphs. Instead of stacking Îť line graphs
we stack O(log(1/Îľ)) levels of fixed-degree DRGs where Îľ is a construction parameter. We refer

4



to this graph construction as Stacked DRGs. We are able to show that this results in a PoS that
has only an Îľ space gap. Intuitively, the expander edges between layers amplify the dependence
of nodes on the last layer and nodes on earlier layers so that deletion of a small Îľ fraction of node
labels on the last level will require re-derivation of nearly all the node labels on the first several
layers. Thus, since every layer is a DRG, recomputing the missing Îľ fraction of labels requires
Ω(N) sequential computation. It is easy to see that this would be the case if the prover were
only storing (1− ε)n labels on the last level and none of the labels on earlier levels, however the
analysis becomes much more difficult when the prover is allowed to store any arbitrary (1− ε)n
labels. This analysis is the main technical contribution of this work. Concretely, we analyze the
construction with an (n, 0.80n,Ω(n)) DRG, i.e. deletion of 20% of nodes leaves a high depth
graph on the 80% remaining nodes, regardless of the value of Îľ.

Our construction is efficient compared to prior constructions of tight PoS primarily because
we can keep the degree of the graphs fixed for arbitrary Îľ while only increasing the number of
levels logarithmically in 1/Îľ. In a graph labeling PoS, the offline PoS proofs sample O(1/Îľ) labels
along with their parent labels, which the verifier checks for consistency. Thus, any construction
based on this approach that requires scaling the degree of graphs by 1/Îľ also scales the proof size
by 1/Îľ, resulting in a proof complexity of at least O(1/Îľ2). In our stacked DRG PoS construction
the offline proof must include queries from each level to prove that each level of computed labels
are “mostly” correct. If done naively, O(1/ε) challenge labels are sampled from each level,
resulting in a proof complexity O(d/ξ ¡ log(1/ξ)) where d is the degree of the level graphs. This
is already an improvement, however with a more delicate analysis we are able to go even further
and show that the total number of queries over all layers can be kept at O(1/Îľ), achieving an
overall proof complexity O(d/Îľ).2

The PoS on Stacked DRGs can also be used as the basis for a PoRep that satisfies Îľ-rational
replication for arbitrarily small Îľ.

The PoRep variant on this PoS simply uses the labels on the `− 1st level as keys to encode
the n-block data input D = d1, ..., dn on the `th (last) level, using the same method described
earlier for encoding data into the labels of a PoS (see Related Work, [19, 20, 33]). However,
extracting data from this PoRep is as expensive as initializing the PoRep space because it
requires recomputing the keys on the `− 1st level.

PoRep from ZigZag Expander DRGs Our second contribution is a variant of the PoS on
Stacked DRGs that compromises slightly on efficiency (requires double the number of levels for
the same security guarantee) but improves the efficiency of extracting data when this is used as
a PoRep. Instead of adding edge dependencies between the layers, every layer is the union of a
DRG and a constant degree non-bipartite expander graph. The only edges between layers are
between nodes at the same indices. Since the graph is a DAG this means that the union of a
subset with its dependencies and targets is a constant fraction larger than the subset itself. By
alternating the direction of the edges between layers, forming a “zig-zag”, the dependencies of a
subset in one layer become targets of the same subset in the adjacent layer, and the dependencies
between layers expands. We refer to this graph construction as ZigZag DRGs. The PoRep on
ZigZag DRGs encodes in the labels of each layer the labels of the previous levels. The edges
within a layer enforce dependencies between labels by deriving a key for each encoding using a

2Asymptotically, this is close to the optimal proof complexity achievable for any PoS based on graph labeling
that has an Îľ space gap. If the prover claims to be storing n labels and the proof queries less than 1/Îľ then a
random deletion of an ε fraction of these labels evades detection with probability at least (1− ε)1/ε ≈ 1/e.

5



cryptographic hash function. A special key is derived for the encoding on each ith node from the
labels on the parents of the ith node within the same layer. Essentially, this construction iterates
the basic DAG encoding of the data inputs ` times (treating each layer as an independent DAG)
rather than performing a long key derivation. The labels in any layer can be used to recover the
labels in the preceding layer. Furthermore, the decoding step can be done in parallel.

c1 c2 c3 c4 c5

d1 d2 d3 d4 d5

c6 c7 c8 c9 c10

c11 c12 c13 c14 c15

Stacked DRGs

c1 c2 c3 c4 c5

d1 d2 d3 d4 d5

c6 c7 c8 c9 c10

c11 c12 c13 c14 c15

ZigZag DRGs

Figure 1.1: The topologies of the stacked DRGs and ZigZag DRGs are depicted with 3 layers
and 5 nodes per layer. Red edges are the DRG edges and blue edges are expander edges. The
blue edges in ZigZag DRGs are the same as in Stacked DRGs but projected into the layers. Blue
edges in ZigZag DRGs are reversed every other layer while red edges are redefined by reversing
the order of the nodes. Dashed edges correspond to encoding instead of hashing dependencies.
In the PoS on Stacked DRGs the prover computes a labeling of the graph and stores the labels on
the nodes in green. In the PoRep on ZigZag DRGs each labeling on a layer encodes the previous
layer and the prover stores only the encoding labels of the green nodes.

Contents

1 Introduction 1
1.1 Related work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 Summary of Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2 Preliminaries 7
2.1 Proof of Retrievable Commitment . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2 Proofs of Space . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.3 Proofs of Replication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.4 Graph pebbling games . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.5 Verifiable Delay Encodings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.6 Depth Robust Graphs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

6



2.7 Expander graphs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3 Stacked DRG Proof of Space 21
3.1 Review of the Stacked-Expander PoS . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.2 A tight PoS from stacked DRGs . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

4 “ZigZag” DRG Proof of Replication 30
4.1 ZigZag PoRep Construction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.2 Invertible pebbling games . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.3 PoS analysis of ZigZag PoRep . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

A Concurrent work: PIEs 41

B Stacked DRGs with Superconcentrators 44

C Mixing Data Labels in Stacked DRGs with Expanders 48

2 Preliminaries

2.1 Proof of Retrievable Commitment

A proof-of-retrievability (PoR) is an interactive proof system in which a verifier sends a file F
to a prover, retains a compact verification key, and later obtains a compact proof that prover
can retrieve F intact. The compactness requirement excludes trivial solutions, such as sending
the full file F back to the verifier or requiring the verifier to retain F . They were introduced
in [8,23] and further developed in [12,17,37]. An important security property of PoR is that the
verifier can extract and recover the file F through sufficiently many successful challenge-response
queries to the prover.

A proof-of-retrievability (PoR) [12,17,23,37], or the related proof-of-data-possession (PDP)
[8], is an interactive protocol that enables a prover to convince a verifier that it can retrieve the
correct contents of a prespecified file without incurring costly communication. The file is first
preprocessed by a client who publishes a data tag. The verifier does not need to store the file and
only retains the short data tag for verification. In a private-key PoR the verifier needs to also
know the private-key used to generate the data tag whereas in a public-key PoR the verification
can be performed by anyone without access the private-key. Crucially, the prover cannot learn
the private-key as otherwise this compromises the PoR/PDP security. PoR security is distinct
from PDPs because it requires that there is a public extraction algorithm that can actually
extract the contents of the file through sufficiently many repeated interactions with the prover.

A simple public PoR can be constructed from a Merkle commitment (i.e. a Merkle tree
over the blocks of the file). The verifier need only retain the Merkle commitment root. To
verify that the prover is still storing a (1 − ε) fraction of the committed file blocks it queries
for a randomly selected constant number of blocks. The prover then responds with the blocks
and Merkle inclusion proofs for each. This public PoR is distinct from both public-key and
private-key PoRs in that it is keyless and thus there is no secret key for the prover to potentially
compromise. This is a stronger form of public verifiability.

Another way to describe this protocol is as a proof-of-retrievable-commitment (PoRC) [19],
i.e. a publicly verifiable proof that the prover can retrieve the contents of a committed file. The

7



security of a PoRC does not rely on any client preprocessing. In fact, this technique is used
ubiquitously in interactive proofs, including proofs of space, CS proofs [29], and more generally
interactive oracle proofs (IOPs) [10]. Note that without erasure codes this is only a proof that
a (1− ε) fraction of the file blocks can be retrieved. This is a special case of a (1− ε, C)-PoRC,
where C is a set cover of the committed data, and the protocol guarantees that a (1− ε) fraction
of the sets (in this case blocks) can be retrieved.

The PoRC based on a Merkle commitment can be more generally constructed from any vector
commitment (VC) [13,27], which is a compact commitment to a vector of m values (x1, ..., xm)
that can be opened at any index with a succinct opening proof. A VC is position binding in the
sense that each ith position can only be opened to a unique value xi. This makes VCs distinct
from set commitments (e.g cryptographic accumulators), which only guarantee that membership
in the set can be verified. Merkle trees have O(logm) size opening proofs and there exist VCs
that trade larger public parameters for constant size opening proofs [13,26].

Similar to a PoR, the soundness of a PoRC is defined in terms of a public extraction algo-
rithm. An important distinction is that the public extraction algorithm does not require a key
to extract the data. Without going into the details of the security definition, a PoRC scheme
is a µ-sound (1 − ε)-PoRC if for any adversary passing the PoRC protocol with probability µ
there is a public extraction algorithm that can rewind the online adversary on challenges and
ultimately extract a (1− ε) fraction of the blocks of the file.

2.2 Proofs of Space

A (persistent) proof of space (PoS) [18] is an interactive proof between and prover and verifier
in which the prover can only succeed if it persistently stores some advice of a minimum size.
There is an “offline” phase in which the prover generates this advice and outputs a compact tag
to the verifier. This is followed by an “online” phase where the verifier challenges the prover
and the prover uses its advice to generate a response.

Formally, the PoS interactive protocol involves three protocols:

1. Setup The setup runs on security parameters Îť and outputs public parameters pp for the
scheme. The public parameters are implicit inputs to the next two protocols.

2. Initialization is an interactive protocol between a prover P and verifier V that run on
shared input (id,N). P outputs ÎŚ and S, where S is its storage advice and ÎŚ is a compact
O(polylog(N)) string given to the verifier.

3. Execution is an interactive protocol between P and V where P runs on input S and V runs
on input Φ. V sends challenges to P , obtains back a proof π, and outputs accept or reject.

The correctness and security requirements are as follows.

Efficiency. The commitment ÎŚ isO(polylog(N)) size and the verifier runs in timeO(polylog(N)).

Completeness. The prover succeeds with probability 1 (causes verifier to accept) if it follows
the protocol honestly.

8



Soundness. The PoS is (s, t, µ)-sound if any for all adversaries P ∗ running in time t and storing
advice of size s during Execution passes verification with probability at most Âľ = negl(Îť). The
PoS is parallel (s, t, µ)-sound if P ∗ may run in parallel time t.

2.3 Proofs of Replication

We review the syntax of a PoRep scheme from [19]. PoRep operates on arbitrary dataD ∈ {0, 1}∗
of up to O(poly(Îť)) size for a given security parameter Îť.

1. PoRep.Setup(λ, T ) → pp is a one-time setup that takes in a security parameter λ, time
parameter T , and outputs public parameters pp. T determines the challenge-response
period.

2. PoRep.Preproc(sk,D)→ D̃, τD is a preprocessing algorithm that may take a secret key sk
along with the data input D and outputs preprocessed data D̃ along with its data tag τD,
which at least includes the size N = |D| of the data. The preprocessor operates in keyless
mode when sk = ⊥ .

3. PoRep.Replicate(id, τD, D̃)→ R, aux takes a replica identifier id and the preprocessed data
D̃ along with its tag τD. It outputs a replica R and (compact) auxilliary information
aux which will be an input for the Prove and Verify procedures. (For example, aux could
contain a proof about the replication output or a commitment).

4. PoRep.Extract(pp, id,R)→ D̃ on input replica R and identifier id outputs the data D̃.

5. PoRep.Prove(R, aux, id, r)→ π on input replica R, auxilliary information aux, replica iden-
tifier id, and challenge r, outputs a proof πid.

6. PoRep.Poll(aux)→ r: This takes as input the auxiliary replica information aux and outputs
a public challenge r.

7. PoRep.Verify(id, τD, r, aux, π) → {0, 1} on input replica identifier id, data tag τD, public
challenge r, auxilliary replication information aux, and proof π it outputs a decision to
accept (1) or reject (0) the proof.

PoRep interactive protocol The PoRep interactive protocol is illustrated in Figure 1. The
setup (whether a deterministic, trusted, or transparent public setup) is run externally and pp is
given as an input to all parties. For each file D, a preprocessor (a special party or the prover
when operating in keyless mode, but not the verifier) runs (D̃, τD) ← PoRep.Preproc(sk,D).
The outputs D̃, τD are inputs to the prover and τD to the verifier.

Îľ-Rational Replication An ideal security goal for PoRep protocols would be to guarantee
that any prover who simultaneously passes verification in k distinct PoRep protocols (under k
distinct identities) where the input to PoRep.Replicate is a file Di in the ith protocol must be
storing k independent replicas, one for each Di, even if several of the files are identical.

Formally, “storing k independent replicas” means that the file can be partitioned into k
independent blocks (or more generally substrings) such that each block encodes the file and
there is a universal decode algorithm that can decode the file independently from each block.

9



Prover Verifier

Replication Phase

1 : R, aux←R PoRep.Replicate(id, τD, D̃)

id, aux

Challenge-Response Phase

2 : r ←R PoRep.Poll(aux)

r

3 : π ←R PoRep.Prove(R, aux, id, r)

id, π

4 : b←R PoRep.Verify(id, τD, r, aux, π)

Figure 2.1: The PoRep interactive protocol is depicted above. The setup and data preprocessing is run
externally generating pp and D̃, τD. The challenge-response protocol is timed, and the verifier rejects any
response that is received more than T time steps after sending the challenge. This is formally captured
by requiring PoRep.Prove to run in parallel time at most T . A PoRep protocol is a special case of a PoS
protocol where Initialization is the Replication Phase and Execution is the challenge-response phase.

We call this a k-replication of a file. Unfortunately, this security property is impossible to
achieve. An adversary can easily “sabotage” its replication storage, e.g. by encrypting it with a
key and storing the key separately. This still allows the adversary to decode the original string
quickly and otherwise interact with the verifier in exactly the same way.

Instead, a rational model of security is defined in [19]. This security model, called Îľ-rational
replication roughly says that a PoRep is a Âľ-sound Îľ-rational replication if for any adversary
passing the protocol with probability µ there is an “equivalent” adversary who passes with at
least the same probability and store a k-replication of the file without incurring more than a
1/(1−ε) storage overhead (i.e. the adversary saves at most an ε fraction of its storage by deviating
from a k-replication strategy). The security model also accounts for auxiliary information that
the adversary might be storing and ensures that the “equivalent” adversary can still extract all
the same information from its storage including data unrelated to the PoRep protocol.

Proof of space and PoRC A PoRep is implicitly a publicly verifiable proof of space (Sec-
tion 2.2). A prover t";"""date"",""2018-08-16T00:28:02Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""Tight Proofs of Space and Replication""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""Tight Proofs of Space and Replication""
""modified"",""2018-08-16T00:28:02Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""Ben Fisch""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.16 (TeX Live 2015) kpathsea version 6.2.1""
""meta:author"",""Ben Fisch""
""trapped"",""False""
""meta:creation-date"",""2018-08-16T00:28:02Z""
""created"",""2018-08-16T00:28:02Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2018-08-16T00:28:02Z""
""resourceName"",""702.pdf""
""Author"",""Ben Fisch""
""producer"",""pdfTeX-1.40.16""
""pdf:docinfo:producer"",""pdfTeX-1.40.16""
""pdf:unmappedUnicodeCharsPerPage"",""5"",""11"",""1"",""14"",""27"",""1"",""1"",""5"",""1"",""5"",""5"",""6"",""1"",""7"",""1"",""4"",""26"",""12"",""11"",""8"",""9"",""23"",""6"",""48"",""55"",""118"",""80"",""75"",""61"",""73"",""11"",""10"",""10"",""10"",""19"",""80"",""118"",""102"",""18"",""0"",""0"",""5"",""34"",""2"",""6"",""39"",""48"",""16""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""Ben Fisch""
""dcterms:created"",""2018-08-16T00:28:02Z""
""Last-Modified"",""2018-08-16T00:28:02Z""
""dcterms:modified"",""2018-08-16T00:28:02Z""
""title"",""Tight Proofs of Space and Replication""
""Last-Save-Date"",""2018-08-16T00:28:02Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2018-08-16T00:28:02Z""
""meta:save-date"",""2018-08-16T00:28:02Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.16 (TeX Live 2015) kpathsea version 6.2.1""
""Content-Length"",""873677""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Ben Fisch""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""48""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""2551"",""3255"",""3419"",""3054"",""3399"",""1585"",""2520"",""2523"",""2392"",""1946"",""2774"",""2803"",""2354"",""2234"",""2658"",""2460"",""2389"",""2471"",""2176"",""1912"",""2929"",""3023"",""2792"",""3177"",""2474"",""2803"",""2111"",""2382"",""2133"",""2254"",""2529"",""3212"",""2913"",""3063"",""2908"",""1833"",""2338"",""2175"",""1841"",""2730"",""2718"",""3257"",""3340"",""2013"",""3067"",""3163"",""2956"",""2987""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2018-08-16T00:28:02Z""
";https://scholar.google.com/scholar?start=780&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094544-667;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[PDF][PDF] The New ICO Intermediaries;V Villanueva Collao, V Winship ; Italian LJ, 2019  HeinOnline;;"… promoters ask participants to send funds (often in cryptocurrency) to a smart contract, which is …

architecture that makes certain terms self-executing.4 Smart contracts built on blockchain were,

at … has shifted to include retail investors as well.7 During the 2018 crypto exploit, retail …";Cité 5 fois;Les 5 versions;[PDF] heinonline.org;https://heinonline.org/hol-cgi-bin/get_pdf.cgi?handle=hein.journals/italj5&section=39&casa_token=T7YwpBErNEYAAAAA:GdLfk-R8itAxKW89df8uoYM-18PcZ1HYi4kMiDJuFZIpnAP8SGAw_1oeyPDsXJMEa666agg;"

 ";"""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""REFRESH"",""1; url=https://heinonline.org/HOL/Page?handle=hein.journals/italj5&div=39&g_sent=1&casa_token=T7YwpBErNEYAAAAA:GdLfk-R8itAxKW89df8uoYM-18PcZ1HYi4kMiDJuFZIpnAP8SGAw_1oeyPDsXJMEa666agg""
""Content-Encoding"",""UTF-8""
""resourceName"",""get_pdf.cgi""
""language"",""""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=480&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094562-743;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[PDF][PDF] Automatic Contracts and the Automatic Stay;A Rosenberg ; American Bankruptcy Institute Journal, 2019  mrthlaw.com;;"… in some of their vehicles, albeit for other applications.18 If GPS/SIDs are used to enforce

blockchain-based smart … to Smart-Contract Issues One way to prevent an inadvertent stay violation

is through the use of oracles — more specifically, an oracle that references the …";Cité 2 fois;Les 3 versions;[PDF] mrthlaw.com;http://www.mrthlaw.com/wp-content/uploads/2019/07/feature1_07-19.pdf;;;https://scholar.google.com/scholar?start=560&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094593-878;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Smart Contracts aus Sicht des Vertragsrechts-Funktionsweise, Anwendungsfälle und Leistungsstörungen;L Müller, R Seiler ; Aktuelle Juristische Praxis, 2019  alexandria.unisg.ch;;"… N 10 ff.; Bundesrat, DLT (FN 3), 23 f.; PHILIPP HACKER/CHRIS THOMALE, Crypto-Securities

Regulation … zuzugreifen, welche sich auf der Blockchain befinden.48 Um externe Informationen

in die Blockchain einzuspeisen, werden sogenannte Smart Oracles einge- setzt …";Cité 3 fois;Les 3 versions;[PDF] unisg.ch;https://www.alexandria.unisg.ch/256729/1/MUELLER_SEILER_AJP%2003_2019_S.317-328.pdf;"
317

S m a r t  C o n t r a c t s  a u s  S i c h t  d e s  V e r t r a g s r e c h t s

AJP/PJA 3/2019

Smart Contracts aus Sicht  
des Vertragsrechts 
Funktionsweise, Anwendungsfälle  
und LeistungsstĂśrungen

Smart Contracts lassen sich als automatisierbare, durchsetzbare digi-
tale Abbildungen von Obligationen umschreiben, welche mittels Block-
chain-Technologie einen automatischen ErfĂźllungsprozess vorsehen. 
In diesem Beitrag werden potenzielle Anwendungsbereiche von Smart 
Contracts besprochen, zu denen insbesondere standardisierbare, län-
gerfristige Geschäftsbeziehungen oder die Abwicklung von Kaufverträ-
gen gehĂśrt. Die Technologie, auf der Smart Contracts basieren, birgt 
dabei gewisse rechtliche Herausforderungen. Smart Contracts dienen 
als Ergänzung zur Standardisierung bestehender Vertragsverhältnisse 
und rufen daher nur wenige Probleme im Vertragsrecht hervor. Wichtig 
ist es, das System der LeistungsstĂśrungen bereits bei der Gestaltung 
der Smart Contracts zu berĂźcksichtigen. Falls die rechtlichen Vorgaben 
adäquat berßcksichtigt werden, kÜnnen operative Risiken, insbesonde-
re LeistungsstĂśrungen, minimiert werden.

InhaltsĂźbersicht

I. Smart Contracts im Überblick
A. Blockchain und Smart Contracts

1. Präzisierung des Begriffs Smart Contract
2. Funktionsweise und AnwendungsmĂśglichkeiten  

von Smart Contracts 
B. Die Nutzung von Smart Contracts

1. Smart Contracts in der Lebensmittel industrie
2. Smart Oracles als Verbindung der Smart Contracts  

mit der Aussenwelt
II. Rechtliches Grundverständnis im Umgang mit Smart Contracts

A. Smart Contracts und Verträge im rechtlichen Sinn
B. Vertragsabschluss und Leistungs erfĂźllung 

III. LeistungsstĂśrungen bei der Nutzung von Smart Contracts
A. Selbstdurchsetzung und Unveränderlichkeit der Smart 

Contracts 
B. LeistungsstĂśrungsrecht bei Smart Contracts 

1. LeistungsunmĂśglichkeit
2. Positive Vertragsverletzungen 
3. Verzug im Falle von Smart Contracts 

IV. Fazit und Ausblick

I. Smart Contracts im Überblick

A. Blockchain und Smart Contracts

Die britische Wochenzeitung ÂŤThe EconomistÂť hat 2015 
der Blockchain-Technologie das Potenzial zugesprochen, 
die Funktionsweise der globalen Wirtschaft massgeblich 
beeinflussen zu kĂśnnen.1 Smart Contracts werden hierbei 
als eine verheissungsvolle Anwendung der Blockchain 
gesehen.2 Ob sich diese hohen Erwartungen erfĂźllen, wird 
sich indes erst noch zeigen. Derzeit stellt sich die Frage, 
wie Smart Contracts und deren angedachte Nutzung im 
geltenden Recht einzuordnen sind.3 

Aus technischer Sicht sind Smart Contracts grundsätz-
lich als Software auf Basis der Blockchain zu verstehen.4 
Sobald bestimmte im Programmcode definierte Bedin-

1 ÂŤThe trust machineÂť, The Economist vom 31.10.2015, Internet:  
https://www.economist.com/news/leaders/21677198-technology-
behind-bitcoin-could-transform-how-economy-works-trust-machine 
(Abruf 6.2.2019).

2 Karen e. c. LeVy, Book-Smart, Not Street-Smart: Blockchain-
Based Smart Contracts and The Social Workings of Law, Engaging 
Science, Technology, and Society 2017, 1 ff., 3.

3 Siehe Bericht des Bundesrates vom 14.12.2018, ÂŤRechtliche 
Grundlagen fĂźr Distributed Ledger Technologie und Blockchain in 
der SchweizÂť (zit. Bundesrat, DLT), passim.

4 micha roon, Schlichtung und Blockchain, Anwaltsrevue 2016, 
359 ff., 361.

Les smart contracts (contrats intelligents) peuvent ĂŞtre dĂŠcrits comme 
des représentations numériques automatisables et exécutoires d’obli-
gations prévoyant un processus d’exécution automatique au moyen 
d’une technologie de type blockchain. Cet article traite des champs 
d’application potentiels des smart contracts, parmi lesquels on compte 
notamment les relations d’affaire standardisables et à long terme ou 
encore l’exécution de contrats de vente. La technologie sur laquelle 
les smart contracts sont basĂŠs prĂŠsente certains dĂŠfis juridiques. Les 
smart contracts servent de complĂŠment Ă  la standardisation de rela-
tions contractuelles prÊexistantes et ne soulèvent donc que peu de 
problèmes dans le droit des contrats. Il est important de prendre en 
compte le système des perturbations de performance lors de la concep-
tion des smart contracts. Pourvu que les prescriptions lĂŠgales soient 
adĂŠquatement respectĂŠes, les risques opĂŠrationnels, notamment les 
perturbations de performance, peuvent ĂŞtre minimisĂŠs.

Lukas mĂźLLer* reto seiLer**

*  LuKas mĂźLLer, Prof. Dr. oec. HSG, Rechtsanwalt, lic. iur., 
LL.M., MA UZH, Assistenzprofessor fĂźr Wirtschaftsrecht mit 
Schwerpunkt Gesellschaftsrecht, Institut fĂźr Finanzwissenschaft, 
Finanzrecht und Law and Economics (IFF-HSG), Universität 
St. Gallen.

**  reto seiLer, B.A. HSG in Rechtswissenschaft mit Wirtschafts-
wissenschaften.

Buch_AJP_03_2019.indb   317 01.03.19   10:41



318

L u k a s  M Ăź l l e r / R e t o  S e i l e r

AJP/PJA 3/2019

griffs ÂŤSmart ContractÂť vermuten liesse, ist der Begriff 
nicht wĂśrtlich zu verstehen.12 Einerseits bedarf es nicht 
zwingend einer Intelligenz, wie es die im Zusammen-
hang mit der Industrie 4.0 geläufige Bezeichnung smart 
implizieren kĂśnnte. Auf der anderen Seite ist ein Smart 
Contract nicht einfach mit einem Vertrag im juristischen 
Sinne gleichzusetzen.13 Zudem wird der Begriff oftmals 
unscharf verwendet,14 was auch den unterschiedlichen 
Nuancierungen in der konkreten technischen Ausgestal-
tung von Smart Contracts geschuldet ist.15

Smart Contracts lassen sich im weitesten Sinne als 
eine mit Datenquellen verknĂźpfte Software auf Basis 
der Blockchain beschreiben, welche die darin veranker-
ten vertraglichen Rechte und Pflichten bei ErfĂźllung be-
stimmter Bedingungen selbstständig vollzieht.16 Smart 
Contracts zeichnen sich durch die Eigenschaft aus, Trans-
aktionen als Konsequenz erfĂźllter Bedingungen automa-
tisch und ohne menschlichen Einfluss zu vollziehen.17

Der Inhalt mĂśglicher Transaktionen, die von einem 
Smart Contract ausgefßhrt werden, hängt entscheidend 
vom zugrunde liegenden Begriffsverständnis ab. Smart 
Contracts im weiteren Sinne sind in der Lage, traditionel-
le Transaktionen wie eine Kreditkartenzahlung auszulĂś-
sen. Die Vorteile der Smart Contracts werden hingegen 
erst mit der (rechtlichen und faktischen) VerfĂźgungs-
macht über digitale Vermögenswerte und Daten – etwa 

12 Vgl. reggie o’shieLds, Smart Contracts: Legal Agreements for 
the Blockchain, North Carolina Banking Institute Journal 2017, 
177 ff., 178 m.w.H.; pauLus/matzKe (FN 6), 432 ff.

13 KauLartz/hecKmann (FN 6), 618 f.; meyer/schuppLi (FN 5), 
208.

14 Siehe hierzu auch diedrich (FN 5), 166.
15 Jaccard (FN 11), N 9.
16 martin Fries, Smart Contracts: Brauchen schlaue Verträge noch 

Anwälte?, AnwBl 2018, 86 ff., 86; KauLartz/hecKmann (FN 6), 
618; siehe zu weiteren ähnlichen Definitionen: WaLter bLo-
cher, The next big thing: Blockchain – Bitcoin – Smart Contracts, 
 AnwBl 2016, 618 ff., 618; bettina mieLKe/christian WoLFF, 
 E-Justice, Justiz 3.0 und Legal Tech – eine Analyse, Jusletter IT 
vom 18.5.2017, N 49; christoph simmchen, Blockchain (R)
Evolution – Verwendungsmöglichkeiten und Risiken, MMR 2017, 
162 ff., 164.

17 diedrich (FN 5), 167.

gungen erfĂźllt sind, vollziehen Smart Contracts automa-
tisch vorprogrammierte Prozesse.5

Smart Contracts sollen Transaktionskosten und Risi-
ken im Rahmen der VertragserfĂźllung minimieren.6 Un-
ternehmen identifizieren beispielsweise in Logistikpro-
zessen Potenzial fĂźr Effizienzsteigerungen dank Smart 
Contracts.7 Ungeachtet der damit verbundenen Chancen 
birgt die Technologie rechtliche Herausforderungen, 
etwa im Kontext des Vertragsrechts,8 weshalb sich eine 
nähere Analyse anbietet.9 Diesbezßglich eignet sich eine 
Betrachtung der Lebensmittelindustrie, da die Logis-
tik – beispielsweise durch Sicherstellung der lückenlosen 
Kühlkette und der Einhaltung der Haltbarkeitsdaten – 
wesentlichen Einfluss auf die Qualität der Produkte hat. 
Analoge Überlegungen lassen sich bei Spezialtransporten 
in der Medizin oder in der Finanzindustrie beim Handel 
und bei der Übertragung von Wertpapieren sowie anderen 
VermĂśgenswerten anstellen.10

1. Präzisierung des Begriffs Smart Contract

Eine einheitliche Definition des Smart Contracts konnte 
sich bisher nicht etablieren,11 weshalb es einer Präzisie-
rung des Begriffs bedarf. Anders als der Wortlaut des Be-

5 henning diedrich, Ethereum: Blockchains, Digital Assets, 
Smart Contracts, Decentralized Autonomous Organizations, Lon-
don 2016, 167; stephan d. meyer/benediKt schuppLi, ÂŤSmart 
ContractsÂť und deren Einordnung in das schweizerische Vertrags-
recht, recht 2017, 204 ff., 208.

6 marKus KauLartz/Jörn hecKmann, Smart Contracts – Anwen-
dungen der Blockchain-Technologie, CR 2016, 618 ff., 618;  daVid 
pauLus/robin matzKe, Smart Contracts und das BGB – Viel 
Lärm um nichts?, ZfPW 2018, 431 ff., 432 ff.

7 Etwa die Smart Containers Group, Internet: https://smartcontain 
ers.ch/en/about.html (Abruf 6.2.2019), oder Ambrosus, Internet: 
https://ambrosus.com/de/ (Abruf 6.2.2019).

8 aLexander saVeLyeV, Contract law 2.0: ÂŤSmartÂť contracts as the 
beginning of the end of classic contract law, Information & Com-
munications Technology Law 2017, 116 ff., 128.

9 Zu einigen rechtlichen Herausforderungen siehe beispielsweise 
marKus KauLartz: Die Blockchain-Technologie – Hintergründe 
zur Distributed Ledger Technology und zu Blockchains, CR 2016, 
474 ff.; christoph g. pauLus/robin matzKe, Digitalisierung 
und private Rechtsdurchsetzung – Relativierung der Zwangsvoll-
streckung durch smarte IT-LĂśsungen?, CR 2017, 769 ff.

10 Vgl. Bundesrat, DLT (FN 3), 29; christoph g. pauLus/robin 
matzKe, Smart Contracts und Smart Meter – Versorgungssperre 
per Fernzugriff, NJW 2018, 1905 ff., diskutieren zudem die Leis-
tungsnutzung und -abrechnung von Strom oder Kommunikations-
medien mittels Smart Meter und Smart Contract.

11 Vgl. gabrieL Jaccard, Smart Contracts and the Role of Law, Jus-
letter IT vom 23.11.2017, N 9; diedrich (FN 5), 166; vgl. Kau-
Lartz/hecKmann (FN 6), 618; in IT-Kreisen wird der Begriff häu-
fig als Schlagwort genutzt, weshalb bei der Betrachtung von Smart 
Contracts jeweils eine klare Definition erforderlich ist.

Buch_AJP_03_2019.indb   318 01.03.19   10:41



319

S m a r t  C o n t r a c t s  a u s  S i c h t  d e s  V e r t r a g s r e c h t s

AJP/PJA 3/2019

Software, Tondateien oder Bilder18 – ausgeschöpft.19 Aus 
diesem Grund kategorisieren Vertreter einer engen Defi-
nition Formen, welche Transaktionen im traditionellen 
Sinn auslÜsen, bloss als elektronische Verträge, da Smart 
Contracts – dem restriktiven Verständnis folgend – aus-
schliesslich Ăźber digitale Daten auf der Blockchain ver-
fßgen kÜnnen.20 Zurzeit schränkt ein solcher Ansatz die 
potenziellen Anwendungsbereiche allerdings entschei-
dend ein, weshalb in diesem Beitrag – auch zugunsten 
einer Vereinfachung – einem weitergehenden Verständnis 
des Begriffs ÂŤSmart ContractÂť gefolgt wird. Dementspre-
chend lassen sich Smart Contracts als automatisierbare, 
durchsetzbare digitale Abbildungen von Obligationen de-
finieren, welche durch Software auf Basis der Blockchain 
automatisiert werden und mittels (relativ) manipulations-
sicherer AusfĂźhrung des Codes durchsetzbar sind.21 Ver-
einfacht formuliert handelt es sich bei Smart Contracts um 
auto matisierte Geschäftsabläufe und Rechtsvorgänge.22

Im Gegensatz zu vereinzelten ausländischen Jurisdik-
tionen ist der Begriff ÂŤSmart ContractÂť im Gesetz noch 

18 Auch Messdaten oder Software sind als digitale Daten zu verstehen 
und kÜnnten gemäss der Meinung von ecKert de lege lata gar als 
Sachen qualifiziert werden, vgl. hierzu martin ecKert, Digita-
le Daten als Wirtschaftsgut: Digitale Daten als Sache, SJZ 2016, 
245 ff., 247 f. Der sachenrechtlich zwingende Numerus clausus der 
dinglichen Rechte steht jedoch einer Qualifikation von digitalen 
Daten als Sache entgegen; vgl. LuKas mĂźLLer/miLena reut-
Linger/phiLippe J. a. Kaiser, Entwicklungen in der Regulierung 
von virtuellen Währungen in der Schweiz und der Europäischen 
Union, EuZ 2018, 80 ff., 87; gemäss Bundesrat, DLT (FN 3), 47, 
sei kein allgemeines Eigentumsrecht an Daten mĂśglich, sondern 
lediglich mit verschiedenen Instrumenten eine eigentumsähnliche 
Position an Daten vermittelbar.

19 diedrich (FN 5), 168.
20 Vgl. hierzu saVeLyeV (FN 8), 127.
21 Vgl. christopher d. cLacK/ViKram a. baKshi/Lee braine, 

Smart Contract Templates: foundations, design landscape and re-
search directions, 2016, Internet: https://arxiv.org/pdf/1608.00771.
pdf (Abruf 6.2.2019), 2: Die darin vorgeschlagene Definition ist 
weit gefasst, da ein solches Verständnis nicht zwingend eine au-
tomatische ErfĂźllung vorsieht, vgl. hierzu max rasKin, The Law 
and Legality of Smart Contracts, Georgetown Law Technology Re-
view 2017, 305 ff., 311; saVeLyeV (FN 8), 127.

22 Vgl. pauLus/matzKe (FN 6), 431 ff. Des Weiteren wird der Be-
griff des Smart Contracts gelegentlich in ÂŤSmart Contract CodeÂť 
und ÂŤSmart Legal ContractsÂť unterteilt. Smart Contract Code um-
schreibt den Code, welcher auf der Blockchain gespeichert wird. 
Smart Legal Contracts hingegen beschreiben die konkreten An-
wendungen, wie Verträge in Code ausgedrßckt und implementiert 
werden kĂśnnen, vgl. JOSH STARK, Making Sense of Blockchain 
Smart Contracts, coindesk vom 4.6.2016, Internet: https://www.
coindesk.com/making-sense-smart-contracts/ (Abruf 6.2.2019); 
cLacK/baKshi/braine (FN 21), 2; meyer/schuppLi (FN 5), 
207. Im Folgenden soll der Begriff des Smart Contracts aufgrund 
der besseren Verständlichkeit sowohl Smart Contract Code als auch 
Smart Legal Contracts umfassen.

nicht explizit geregelt. Die US-Bundesstaaten Arizona, 
Delaware und Nevada haben jedoch Smart Contracts 
bereits gesetzlich ausdrĂźcklich erfasst, um die Rahmen-
bedingungen zur Nutzung festzusetzen.23 Exemplarisch 
wird in der Gesetzgebung Arizonas die rechtliche GĂźl-
tigkeit und Durchsetzbarkeit von Smart Contracts fest-
gehalten.24 DiesbezĂźglich stellt sich die Frage, ob es im 
Schweizer Recht ebenfalls einer ausdrĂźcklichen gesetzli-
chen Regelung bedarf. Aufgrund der technologieneutra-
len Konzeption des Schweizer Rechts scheint prima facie 
der Anwendung bestehender Normen auf Smart Contracts 
grundsätzlich nichts im Wege zu stehen. Inwiefern dies zu 
Herausforderungen fßhrt, wird nachfolgend erläutert. 

2. Funktionsweise und AnwendungsmĂśglich-
keiten von Smart Contracts 

Grundlage der Smart Contracts ist die Blockchain-Tech-
nologie. Es existieren verschiedene Formen von Block-
chain-Anwendungen, die jeweils unterschiedliche Funk-
tionalitäten aufweisen. Die bekannte Bitcoin-Blockchain 
fokussiert sich beispielsweise einzig auf die Zahlungsab-
wicklung mittels Bitcoins.25 2015 wurde sodann mit der 
EinfĂźhrung der Ethereum-Blockchain die Basis fĂźr die 
AusfĂźhrung komplexerer Programme auf einer Block-
chain entwickelt.26 

Die Kernfunktion von Smart Contracts liegt darin, 
Parteivereinbarungen auf der Blockchain aufzuzeichnen 
und anschliessend die hierfĂźr notwendigen Transaktionen 
automatisch auszufĂźhren, sobald bestimmte, vordefinierte 
Bedingungen erfĂźllt sind.27 Der programmierte Inhalt des 
Smart Contracts wird mittels Blockchain grundsätzlich 
unveränderlich. Hinzu tritt die selbstständige Durchset-
zung der LeistungserfĂźllung als zweites entscheidendes 
Wesens merkmal.28

23 Vgl. gayLe m. hyman/mattheW p. digesti, New Nevada le-
gislation recognizes Blockchain and Smart Contract Technologies, 
Nevada Lawyer 2017, 13 ff., 13.

24 Arizona Revised Statutes, § 44-7061.
25 diedrich (FN 5), 27 f.; LuKas mĂźLLer/thomas stoLtz/ 

tobias a. KaLLenbach, Liberierung des Aktienkapitals mittels 
Kryptowährung – Eignen sich Bitcoins und andere Kryptowährun-
gen zur Kapitalaufbringung?, AJP 2017, 1319 ff.

26 Kristian LausLahti/Juri mattiLa/timo seppäLä, Smart 
Contracts – How will Blockchain Technology Affect Contractual 
Practices?, ETLA Report 2017, Internet: https://www.etla.fi/wp-
content/uploads/ETLA-Raportit-Reports-68.pdf (Abruf 6.2.2019), 
12 m.w.H.

27 LeVy (FN 2), 3.
28 KauLartz/hecKmann (FN 6), 619; siehe zum Inhalt und zur 

Funktionsweise der grundsätzlich unveränderbaren Daten ausfßhr-
lich roon (FN 4), 360 ff.

Buch_AJP_03_2019.indb   319 01.03.19   10:41



320

L u k a s  M Ăź l l e r / R e t o  S e i l e r

AJP/PJA 3/2019

Die Unveränderlichkeit und Sicherheit, die sich aus 
der Blockchain-Technologie in Kombination mit der 
selbstständigen Durchsetzung ergeben kann, soll dabei 
das in herkÜmmlichen Verträgen notwendige gegenseitige 
Vertrauen der Parteien ergänzen oder ersetzen, wodurch 
Märkte erschlossen werden kÜnnten, in denen es bisher 
aufgrund des mangelnden Vertrauens kaum zu Vertrags-
abschlĂźssen kommen konnte.29 Ebenso ist der Einsatz von 
Smart Contracts als Ersatz von Escrow-Agenten mĂśglich, 
wie dies bereits in einer internationalen Immobilientrans-
aktion erfolgte.30

Nichtsdestotrotz birgt die Funktionsweise von Smart 
Contracts Risiken, denn die grundsätzliche Unveränder-
lichkeit setzt das fehlerlose Programmieren von Smart 
Contracts voraus. Das ist bei zunehmender Komplexität 
des vorgesehenen Inhalts indes kaum zu erreichen.31 Dies 
zeigt sich besonders im Zusammenhang mit sogenann-
ten DAOs (ÂŤdecentralized autonomous organisationsÂť), 
welche sich aus verschiedenen, miteinander verknĂźpften 
Smart Contracts zusammensetzen und so in der Lage sein 
sollen, funktionierende Geschäftsmodelle zu automati-
sieren.32 Ein Beispiel zur Veranschaulichung der Risiken 
ist ÂŤThe DAOÂť, ein auf der Basis von Smart Contracts 
agierender Investmentfonds, dem aufgrund eines Pro-
grammierfehlers USD 50 Millionen entwendet werden 
konnten.33

Die NutzungsmĂśglichkeiten von Smart Contracts sind 
auf digital abbildbare Transaktionen beschränkt.34 Man 
denke dabei etwa an den Verkauf von digitalen Daten wie 
Bildern oder Musikdateien oder anderen VermĂśgenswer-
ten mithilfe eines Smart Contracts. Vertragsverhältnisse, 
die notwendigerweise eine physische Handlung in der 
ErfĂźllung voraussetzen, kĂśnnen allerdings nicht unmittel-

29 Siehe zu der mÜglichen Chance, neue Märkte durch den Einsatz 
von Smart Contracts zu schaffen, diedrich (FN 5), 173; LuKas 
mĂźLLer, Der Bitcoin- und Blockchain-Goldrausch, AJP 2018, 
680 f.

30 Vgl. andreas gLarner/stephan d. meyer, Smart Contracts in 
Escrow-Verhältnissen, Jusletter vom 4.12.2017, N 4 f. m.w.H.

31 Lee bacon/george bazinas, ÂŤSmart ContractsÂť: The Next Big 
Battleground?, Jusletter IT vom 18.5.2017, n 11.

32 meLanie sWan, Blockchain: blueprint for a new economy, Peking 
2015, 24 f.: Als Beispiel zu nennen wäre die Cloud-Speicherplatt-
form Storj, Internet: https://storj.io/ (Abruf 6.2.2019); eLeonor 
gyr, Dezentrale Autonome Organisation DAO, Jusletter vom 
4.12.2017, N 1 ff.

33 Siehe zum Fall ÂŤThe DAOÂť bacon/bazinas (FN 31), N 10 ff.; 
Bundesrat, DLT (FN 3), 23 f.; phiLipp hacKer/chris thomaLe, 
Crypto-Securities Regulation: ICOs, Token Sales and Cryptocur-
rencies under EU Financial Law, European Company and Financial 
Law Review 2018, 645 ff., 647 ff.

34 KauLartz/hecKmann (FN 6), 619 f.

bar in einem Smart Contract abgebildet und automatisiert 
werden.35 

Mit zunehmender Verbreitung vernetzter Gegenstände 
(des sogenannten ÂŤInternet of ThingsÂť bzw. ÂŤIoTÂť) er-
Üffnen sich zukßnftig neue Anwendungsfälle.36 Vielfach 
handelt es sich bei den angedachten EinsatzmĂśglichkei-
ten jedoch um blosse Konzepte, die zunächst einer funk-
tionierenden Umsetzung bedĂźrfen. Die Anwendung von 
Smart Contracts erscheint dort sinnvoll, wo ein hoher 
Grad an Automatisierung erzielt werden kann und deshalb 
standardisierte Smart Contracts genutzt werden kĂśnnen, 
etwa im Handel oder in der Verwaltung von Finanzinst-
rumenten.37 Der Smart Contract kĂśnnte etwa den Handel 
von Aktien und die Verwaltung damit verbundener Rechte 
(etwa Dividendenzahlungen, AusĂźbung der Stimmrech-
te, Meldung des Erwerbs von vinkulierten Namenaktien) 
Ăźbernehmen. Denkbar ist eine Anwendung derweil auch 
in standardisier- und automatisierbaren Vertriebsketten, 
wie nachfolgend am Beispiel der Lebensmittelindustrie 
näher darzulegen ist. 

Aus betriebswirtschaftlicher Sicht sollten Smart Con-
tracts insbesondere Effizienzgewinne erzielen, die aus der 
automatisierten Transaktionsabwicklung und durch den 
Verzicht auf Intermediäre erreicht werden sollen.38 Da-
von kĂśnnte etwa der globale Handel, Versicherungen oder 
Compliance-Abteilungen profitieren.39 Aber auch die 
Übertragung von Vermögenswerten mithilfe von Smart 
Contracts kĂśnnte ein Thema werden.40

Obwohl die Transaktionskosten durch den Verzicht 
auf Intermediäre im Rahmen der Vertragserfßllung in ge-
wissen Fällen abnehmen, kann nicht zwangsläufig davon 
ausgegangen werden, dass der Smart-Contract-Einsatz 
eine Vertragsbeziehung tatsächlich Ükonomisch effizien-
ter macht. Insbesondere die erforderliche Infrastruktur 

35 eLiza miK, Smart contracts: terminology, technical limitations 
and real world complexity, Law, Innovation and Technology 2017, 
269 ff., 298.

36 LeVy (FN 2), 3.
37 Siehe dazu das Beispiel der Smart Contract Templates: cLacK/

baKshi/braine (FN 21), 6 ff.
38 Vgl. diedrich (FN 5), 171: Intermediäre kÜnnten in Zukunft der-

weil neue Aufgaben Ăźbernehmen wie die Verwaltung der erforder-
lichen Technologie zum Betrieb von Smart Contracts.

39 Vgl. hierzu WEF, The future of financial infrastructure, Financial 
Services Series 2016, Internet: https://www.weforum.org/reports/
the-future-of-financial-infrastructure-an-ambitious-look-at-how-
blockchain-can-reshape-financial-services (Abruf 6.2.2019), 39 ff.

40 Siehe zur Übertragung von Asset-backed-Token auf der Block-
chain hans caspar Von der crone/Franz J. KessLer/Luca 
angstmann, Token in der Blockchain – privatrechtliche Aspekte 
der Distributed Ledger Technologie, SJZ 2018, 337 ff., 345; siehe 
zu den zivilrechtlichen Grundlagen der Übertragung von Token auf 
der Blockchain ausfĂźhrlich Bundesrat, DLT (FN 3), 47 ff.

Buch_AJP_03_2019.indb   320 01.03.19   10:41



321

S m a r t  C o n t r a c t s  a u s  S i c h t  d e s  V e r t r a g s r e c h t s

AJP/PJA 3/2019

und die aufwendigere Vertragsgestaltung führen – zumin-
dest in einem Anfangsstadium und solange nur wenig Er-
fahrung vorhanden ist – zu nicht unerheblichen Kosten.41 
Des Weiteren kĂśnnten die Wartungsarbeiten fĂźr die Soft-
ware ein zusätzlicher wichtiger Kostenpunkt werden.42 
Ein weiteres Risiko besteht darin, dass Smart Contracts 
automatisiert massenweise die gleiche Transaktionsstruk-
tur abwickeln sollen. Falls ein Programmfehler lange un-
erkannt bleibt, kĂśnnten die Folgen eines Fehlers ebenfalls 
im Massengeschäft auftauchen und damit erhebliche Aus-
wirkungen haben. Das bedeutet, dass der Smart Contract 
besonders sorgfältig konzipiert werden muss.

B. Die Nutzung von Smart Contracts

1. Smart Contracts in der Lebensmittel-
industrie

Die Lebensmittelindustrie ist aus verschiedenen GrĂźnden 
ein sinnvolles Einsatzgebiet fĂźr Smart Contracts. Einer-
seits wird im Supply-Chain-Management bewusst auf 
eine Effektivitäts- und Effizienzsteigerung abgezielt und 
andererseits begßnstigt die Häufigkeit ähnlicher Transak-
tionen eine potenzielle Verwendung von Smart Contracts. 
Dies scheint auch deshalb mĂśglich, weil vielverspre-
chende Ansätze der Technologie bereits vorhanden sind. 
So sollen die mit Sensoren ausgestatteten Container der 
Unternehmung FoodGuardians mithilfe der Blockchain-
Technologie eine ständige Überwachung der im Laufe 
der Vertriebskette wesentlichen Parameter wie der Tem-
peratur oder der Feuchtigkeit ermĂśglichen.43 Die laufende 
Überwachung und Qualitätskontrolle ist in der Lebens-
mittellogistik zentral, da verderbliche Lebensmittel bei 
unsachgemässer Distribution nicht nur ein Thema fßr 
(rechtliche) LeistungsstĂśrungen sind, sondern auch die 
Gesundheit der Konsumenten schädigen kÜnnen.

Eine weitere Integration von Smart Contracts in die 
WertschĂśpfungskette zeigt das Unternehmen Ambrosus 

41 Siehe hierzu saVeLyeV (FN 8), 127.
42 Im Zusammenhang mit den Ăźblicherweise hohen Unterhaltskosten 

eines IT-Systems wird davon ausgegangen, dass die Nutzung der 
Blockchain-Technologie diese Kosten durch die zusätzliche Effi-
zienz in der Abwicklung reduzieren kann, wie es am Beispiel einer 
mĂśglichen Nutzung der Blockchain durch das Medicaid Manage-
ment Information System (kurz ÂŤMMISÂť) der USA vorgebracht 
wird; siehe hierzu daVid randaLL/pradeep goeL/ramzi abu-
Jamra, Blockchain Applications and Use Cases in Health Informa-
tion Technology, Journal of Health & Medical Informatics 2017, 2.

43 Siehe hierzu FoodGuardians, Technology, Internet: https://foodgu-
ardians.ch/technology.html (Abruf 6.2.2019).

auf.44 Im Kern geht es um ein Blockchain-gestĂźtztes IoT-
Netzwerk, welches gemäss selbsterklärter Absicht neue 
Massstäbe im Supply-Chain-Management setzen soll.45 
Das dezentralisierte Protokoll mit dem Namen AMB-NET 
soll mithilfe von Sensoren in der Lage sein, die wichtigs-
ten Informationen Ăźber Lebensmittel in Echtzeit zu sam-
meln.46 Diese Daten sind der SchlĂźssel fĂźr eine mĂśgliche 
Anwendung von Smart Contracts, die gemäss Angaben 
von Ambrosus im AMB-NET programmiert werden und 
mithilfe der Inputs der Sensoren automatisch vordefinier-
te Handlungsprozesse auslĂśsen kĂśnnen.47 

In bestimmten Fällen kÜnnten Smart Contracts in der 
Lebensmittel industrie sinnvoll eingesetzt werden. Ein 
vereinfachtes Beispiel soll im Folgenden eine potenzielle 
Anwendung aufzeigen: Im Rahmen der Produktion von 
Fleischerzeugnissen kĂśnnen im Verarbeitungsprozess be-
reits die lebenden Tiere gekennzeichnet und entsprechen-
de Daten erhoben sowie verifiziert werden. So wĂźrde die 
artgerechte Haltung nach den gesellschaftlich erwĂźnsch-
ten Standards dokumentiert und von unabhängigen Stel-
len geprĂźft werden. Im Zuge der Fleischverarbeitung 
wĂźrden die Produkte verpackt und gekennzeichnet wer-
den. Während der Belieferung der Grosshändler zeichnen 
Sensoren in den Transportcontainern jegliche Temperatur-
schwankungen auf. Nun kommen Smart Contracts ins 
Spiel. Wenn im Lager eines Lebensmittelgeschäfts durch 
die entsprechenden Aufzeichnungen ein Mangel an ei-
nem bestimmten Produkt erkannt wird, kann ein Smart 
Contract automatisch eine Bestellung beim Grosshändler 
auslĂśsen, woraufhin unmittelbar die entsprechende Be-
stellung im Grosslager fraktioniert und versendet wird. 
Gleichzeitig Ăźberwachen Sensoren die gesamte Wert-
schĂśpfungskette. Bei einer Unterbrechung der KĂźhlket-
te oder bei einem Verstoss gegen Tierschutzvorschriften 
kĂśnnte beispielweise die Annahme der via Smart Contract 
bestellten Ware automatisch rechtlich und tatsächlich ver-
hindert werden. Dabei wird offensichtlich, wie wichtig 
die Schnittstellen zur physischen Welt, etwa die ange-
sprochenen Sensoren, tatsächlich sind. Sie werden in der 
Fachsprache als ÂŤSmart OraclesÂť bezeichnet und sind fĂźr 
Smart Contracts von grosser Bedeutung.

44 Vgl. hierzu Ambrosus, Internet: https://ambrosus.com/ (Abruf 
6.2.2019).

45 Siehe hierzu Ambrosus, Mission, Internet: https://ambrosus.com/
de/#mission (Abruf 6.2.2019).

46 Siehe hierzu Ambrosus, Sensoren, Internet: https://ambrosus.com/
de/#sensors (Abruf 6.2.2019).

47 Siehe hierzu Ambrosus, blockchain protocols, Internet: https://am 
brosus.com/de/#blockchain_protocols (Abruf 6.2.2019).

Buch_AJP_03_2019.indb   321 01.03.19   10:41



322

L u k a s  M Ăź l l e r / R e t o  S e i l e r

AJP/PJA 3/2019

2. Smart Oracles als Verbindung der  
Smart Contracts mit der Aussenwelt

Smart Contracts sind per definitionem nur fähig, auf In-
formationen zuzugreifen, welche sich auf der Blockchain 
befinden.48 Um externe Informationen in die Blockchain 
einzuspeisen, werden sogenannte Smart Oracles einge-
setzt. Sie ermĂśglichen den Informationsaustausch mit 
Quellen ausserhalb der Sphäre von Smart Contracts.49 
So kĂśnnen die zuvor angesprochenen Sensoren etwa die 
Temperatur der Lebensmittel während des Transports auf-
zeichnen oder andere als relevant definierte Daten erfas-
sen.50 

Der Nutzen solcher Smart Oracles liegt im Wesentli-
chen in ihrer Fähigkeit, einen entsprechenden Smart Con-
tract mit den notwendigen Informationen zu versorgen. 
Entdeckt ein Temperatursensor eine Unterbrechung der 
KĂźhlkette, wird der Smart Contract in der Lage sein, diese 
Information zu verwerten und entsprechende Massnah-
men auszulÜsen. In einem solchen Fall wäre eine automa-
tische, mittels Smart Contract vorgenommene Mängelrß-
ge denkbar.51

Wenn von einer externen Quelle Informationen auf 
den Smart Contract einwirken, ist es wichtig, deren Au-
thentizität zu gewährleisten. Diesbezßglich besteht auf 
der Blockchain die MĂśglichkeit, entsprechende Prozesse 
zu implementieren, um festzustellen, ob die Information 
von der dafĂźr vorgesehenen Stelle stammt.52 Gerade in 
solchen Fallkonstellationen, welche der Gefahr einer ein-
seitigen Beeinflussung der entsprechenden Smart Oracles 
ausgesetzt sind, scheint es angebracht, Sicherungsprozes-
se einzusetzen, um ein bestimmtes Mass an Vertrauen in 

48 diedrich (FN 5), 188.
49 Siehe hierzu diedrich (FN 5), 187 f.; christoFF graFF/mat-

thias zscherp/heLmut stoiber, Plattform sicherheit – Smart 
Contracts und TPM, Frankfurt 2015, 7.

50 Vgl. zum Beispiel zu den Sensoren in modernen Fahrzeugen, 
die Daten aufzeichnen und weiterleiten kĂśnnen, hans rudoLF 
trĂźeb, Smart Contracts, in: Pascal Grolimund et al. (Hrsg.), Fest-
schrift fĂźr Anton K. Schnyder zum 65. Geburtstag, ZĂźrich/Basel/
Genf 2018, 723 ff., 730; auch ausserhalb der Lebensmittelindust-
rie sind verschiedene Anwendungen von Smart Oracles denkbar, 
beispielsweise die Meldung eines Zahlungseingangs auf einem be-
stimmten Konto oder das Erzielen eines vordefinierten Quorums an 
einer Abstimmung, siehe hierzu andreas Furrer, Die Einbettung 
von Smart Contracts in das schweizerische Privatrecht, Anwaltsre-
vue 2018, 103 ff., 103; vgl. WiLLiam mougayar, The Business 
Blockchain, Promise, Practice, and Application of the Next Internet 
Technology, Hoboken 2016, 44 f.

51 Siehe zur Veranschaulichung der Funktionsweise von Smart Con-
tracts im Zusammenspiel mit Smart Oracles ferner tim sWanson, 
Great Chain of Numbers, A Guide to Smart Contracts, Smart Pro-
perty, and Trustless Asset Management, San Francisco 2014, 61.

52 Siehe hierzu ausfĂźhrlich Furrer (FN 50), 104.

Smart Oracles gewährleisten zu kÜnnen.53 Insgesamt birgt 
die VerknĂźpfung mit der physischen Welt stets ein Risiko 
fĂźr die automatische ErfĂźllung des Smart Contracts, da es 
die Fehleranfälligkeit erhÜht.54 

II. Rechtliches Grundverständnis  
im Umgang mit Smart Contracts

A. Smart Contracts und Verträge  
im rechtlichen Sinn

Der Vertrag als zweiseitiges Rechtsgeschäft ist ein wich-
tiges Gestaltungsmittel im Rahmen der Privatautonomie 
des Vertragsrechts.55 Gemäss Art. 1 OR bedarf es ßberein-
stimmender gegenseitiger Willenserklärungen, um einen 
Vertrag zu schliessen.56 Smart Contracts sind allerdings 
nicht mit herkÜmmlichen Verträgen im juristischen Sin-
ne gleichzusetzen und kÜnnen grundsätzlich unabhängig 
von der Blockchain oder vom Programmcode existieren.57 
Ebenso entsprechen sie nicht einfach einem digitalen 
Vertragsdokument, welches die Parteien in Ăźbereinstim-
mender Auffassung in Programmiersprache aufsetzen. 
Vielmehr kĂśnnen sie als AusfĂźhrung der Vertragsverein-
barung – im Sinne einer Abbildung des Vertragswillens 
mittels Programmcode – verstanden werden.58 

Der Vertragsinhalt bleibt vom Smart Contract und vom 
jeweiligen Inhalt auf der Blockchain grundsätzlich unab-
hängig. Im Regelfall bestimmt der Vertragsinhalt eben-
falls den Vertragstyp; der Smart Contract ist als solches 
fßr den Vertragsschluss grundsätzlich nicht notwendig.59 
Eine Ausnahme hierzu besteht, wenn der Smart Contract 
als Offerte qualifiziert. In diesem Fall kann die Annah-
meerklärung mit dem Smart Contract abgegeben werden. 
Ein Vertrag ist somit grundsätzlich – mangels anderslau-
tender Abmachung – immer noch gültig, selbst wenn der 

53 Vgl. hierzu gLarner/meyer (FN 30), N 37 m.w.H.
54 meyer/schuppLi (FN 5), 209; miK (FN 35), 299.
55 peter gauch/WaLter r. schLuep/JĂśrg schmid, Schweizeri-

sches Obligationenrecht, Allgemeiner Teil Band I, 10. A., ZĂźrich/
Basel/Genf 2014, N 612; aLFred KoLLer, Schweizerisches Obli-
gationenrecht, Allgemeiner Teil, 4. A., Bern 2017, § 3 n 1.

56 Vgl. BSK OR I-zeLLWeger-gutKnecht/bucher, Art. 1 N 1 ff., 
in: Heinrich Honsell";"""date"",""2019-03-13T12:55:54Z""
""pdf:PDFVersion"",""1.6""
""xmp:CreatorTool"",""Adobe InDesign CC 13.1 (Macintosh)""
""pdf:docinfo:title"",""Buch_AJP_03_2019.indb""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""language"",""de""
""dc:format"",""application/pdf; version=1.6""
""pdf:docinfo:creator_tool"",""Adobe InDesign CC 13.1 (Macintosh)""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""Buch_AJP_03_2019.indb""
""xmp:CreateDate"",""2019-03-01T10:41:22Z""
""modified"",""2019-03-13T12:55:54Z""
""pdf:hasMarkedContent"",""true""
""xmp:ModifyDate"",""2019-03-13T13:55:54Z""
""trapped"",""False""
""meta:creation-date"",""2019-03-01T09:41:22Z""
""created"",""2019-03-01T09:41:22Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-03-01T09:41:22Z""
""resourceName"",""MUELLER_SEILER_AJP%2003_2019_S.317-328.pdf""
""xmpMM:DerivedFrom:DocumentID"",""xmp.did:03c7268d-c64d-4a84-b89f-0c79bd7eb575""
""GTS_PDFXVersion"",""PDF/X-4""
""producer"",""Adobe PDF Library 15.0""
""pdf:docinfo:producer"",""Adobe PDF Library 15.0""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:docinfo:custom:GTS_PDFXVersion"",""PDF/X-4""
""access_permission:modify_annotations"",""true""
""dcterms:created"",""2019-03-01T09:41:22Z""
""Last-Modified"",""2019-03-13T12:55:54Z""
""dcterms:modified"",""2019-03-13T12:55:54Z""
""title"",""Buch_AJP_03_2019.indb""
""xmpMM:DocumentID"",""xmp.id:3339e351-0c38-4684-bcc0-3a4f7a090b9f""
""Last-Save-Date"",""2019-03-13T12:55:54Z""
""pdf:docinfo:modified"",""2019-03-13T12:55:54Z""
""meta:save-date"",""2019-03-13T12:55:54Z""
""Content-Length"",""1056052""
""Content-Type"",""application/pdf""
""xmp:MetadataDate"",""2019-03-13T13:55:54Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""pdf:producer"",""Adobe PDF Library 15.0""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""12""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""4606"",""5257"",""5828"",""5577"",""5190"",""5447"",""5327"",""4959"",""5197"",""5116"",""5179"",""1798""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""xmpMM:DerivedFrom:InstanceID"",""xmp.iid:cd47a0e1-b851-4eb4-a57a-9b59d24a9a99""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-03-01T09:41:22Z""
";https://scholar.google.com/scholar?start=690&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094654-1137;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Digital transformation of airline management as the basis of innovative development;A Sukhorukov, N Koryagin, J Sulyagina… ; International Scientific …, 2019  Springer;;"… As the analysis of the table shows, at present the majority of airlines use information systems

of manufacturers (SAP, Microsoft and Oracle), however, 1C: ERP is gaining more and more

popularity in Russia … Distributed ledger technology (Blockchain). Quantum technology …";Cité 5 fois;Les 3 versions;null;;;;https://scholar.google.com/scholar?start=950&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094640-1072;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[PDF][PDF] On the Impossibility of Structure-Preserving Deterministic Primitives;M Abe, J Camenisch, R Dowsley, M Dubovitskaya ; Journal of Cryptology, 2019  Springer;;"… The non-interactive versions of generalized Schnorr protocols are secure only in the random

oracle model, as they are obtained via the Fiat–Shamir heuristic [32], and it is well known

that random oracles cannot be instantiated securely [25,36] …";Cité 1 fois;Les 4 versions;[PDF] springer.com;https://idp.springer.com/authorize/casa?redirect_uri=https://link.springer.com/content/pdf/10.1007/s00145-018-9292-1.pdf&casa_token=pY-QoSKJA3YAAAAA:Guc6tS836DTQPso_XP67evL0a6xOHJsxiKy0CcXEZQ4SjLAWG5Acfix0yBJSvvoYSayLoO5uZhf7GFQ;;;https://scholar.google.com/scholar?start=890&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094665-1176;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Can blockchain solve the hold-up problem for shared databases?;C Barrera, S Hurder ; Prysm White Paper May, 2019  papers.ssrn.com;;"Page 1. Can Blockchain Solve the Hold-Up Problem for Shared Databases? Dr. Cathy Barrera?

Dr. Stephanie Hurder … tion partners. Blockchain can provide the economic structure for

organizations to enter shared databases without fear of being victim to the hold-up problem …";Cité 3 fois;;null;;;;https://scholar.google.com/scholar?start=420&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094621-1000;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Uma Visăo De Futuro Para Adoçăo De Smart Contracts Em M&A (A Future Vision for the Adoption of Smart Contracts in M&A);D Schechtman ; Available at SSRN 3430795, 2019  papers.ssrn.com;;"… “Ripple CEO: Facebook libra cryptocurrency push makes me happy” … 7 O principal exemplo é

a iniciativa Hyperledger, descrita oficialmente conforme segue: “Hyperledger is an open source

collaborative effort created to advance cross-industry blockchain technologies …";Cité 1 fois;;null;;;;https://scholar.google.com/scholar?start=810&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094569-772;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[LIVRE][B] R3 Corda for Architects and Developers: With Case Studies in Finance, Insurance, Healthcare, Travel, Telecom, and Agriculture;D Mohanty ;2019 books.google.com;;"… 70 Vault.....70 Oracles.....70 Project … and Perfect Money in 2007 were all crypto or digital …

Chapter 1 Barter to BloCkChain Note While all these currencies are …";Cité 7 fois;Les 4 versions;null;;;;https://scholar.google.com/scholar?start=590&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094565-752;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Digital Solidarity: Contracting in the Age of Smart Contracts;F Ghodoosi ; Available at SSRN 3449674, 2019  papers.ssrn.com;;"… 38 The future effectiveness of the blockchain is also dependent on the reliability of Oracle-type

blockchain platform for uncontroversial cases. Oracles “feed the smart contract with external

information that can trigger” actions by smart contracts, Blockchain Oracles …";Cité 1 fois;;null;;;;https://scholar.google.com/scholar?start=570&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094633-1048;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[CITATION][C] Testing Smart Contract;A D'Arco;;;null;Autres articles;;null;;;;https://scholar.google.com/scholar?start=860&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094656-1148;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Biased nonce sense: Lattice attacks against weak ECDSA signatures in cryptocurrencies;J Breitner, N Heninger ; … Conference on Financial Cryptography and Data …, 2019  Springer;;"… References. 1. The most repeated r value on the blockchain (2015) … https://en.bitcoin.it/wiki/

Address_reuse. 3. Akavia, A.: Solving hidden number problem with one bit oracle and advice.

In: Halevi, S. (ed.) CRYPTO 2009. LNCS, vol. 5677, pp. 337–354 …";Cité 32 fois;Les 7 versions;[PDF] nsf.gov;https://par.nsf.gov/servlets/purl/10174436;"
Biased Nonce Sense: Lattice Attacks against
Weak ECDSA Signatures in Cryptocurrencies

Joachim Breitner1[0000−0003−3753−6821] and Nadia Heninger2

1 DFINITY Foundation, Zug, joachim@dfinity.org
2 University of California, San Diego, nadiah@cs.ucsd.edu

Abstract. In this paper, we compute hundreds of Bitcoin private keys
and dozens of Ethereum, Ripple, SSH, and HTTPS private keys by
carrying out cryptanalytic attacks against digital signatures contained
in public blockchains and Internet-wide scans. The ECDSA signature
algorithm requires the generation of a per-message secret nonce. If this
nonce is not generated uniformly at random, an attacker can potentially
exploit this bias to compute the long-term signing key. We use a lattice-
based algorithm for solving the hidden number problem to efficiently
compute private ECDSA keys that were used with biased signature nonces
due to multiple apparent implementation vulnerabilities.

Keywords: Hidden number problem, ECDSA, Lattices, Bitcoin, Crypto

1 Introduction

The security of the ECDSA signature algorithm relies crucially on the proper
generation of a per-signature nonce value that is used as an ephemeral private
key. It is well known that if an ECDSA private key is ever used to sign two
messages with the same signature nonce, the long-term private key is trivial to
compute.[18,7,37,13,11,8]

Repeated nonce values are not the only type of bias that can render an
ECDSA key insecure, however. In fact, many types of nonuniformities in the
ECDSA signature nonces can reveal the private key, given sufficiently many
signatures. In this paper, we carry out lattice-based cryptanalytic attacks against
ECDSA signatures collected from the Bitcoin, Ethereum, and Ripple blockchains
as well as Internet-wide scans of HTTPS and SSH hosts, and efficiently compute
hundreds of Bitcoin private keys and a handful of Ethereum and SSH private
keys. As a side effect, we also find numerous Bitcoin, Ethereum, Ripple, SSH,
and HTTPS private keys that were compromised through repeated signature
nonces.

The lattice attacks we apply are based on algorithms for solving the hidden
number problem. [6] While the hidden number problem is a popular tool in
the cryptanalytic literature for recovering private keys based on side channel
attacks [5,14], to our knowledge we are the first to apply these techniques to
already-generated keys in the wild, and the first to observe that these techniques
may apply to signatures in cryptocurrencies. In total, we computed around 300



2 Joachim Breitner and Nadia Heninger

Bitcoin keys with these techniques. As of this writing, 818,975 satoshis, or around
$54, and 30.40 XRP, or about $14, remain in Bitcoin and Ripple accounts whose
keys we were able to compute, suggesting that these flaws do not yet appear to
be known, or else the funds would have already been stolen.

The attacks we use are significantly faster than naive brute force or the
state of the art algorithms for the elliptic curve discrete log problem. Using a
square root-time algorithm like Pollard rho [28], one could feasibly carry out
a targeted attack against a small number of the 64-bit or 128-bit nonces we
discovered; carrying out this attack against all of the approximately 230 signatures
in the Bitcoin blockchain would have required significantly more computational
resources than we have access to. In contrast, we spent around 40 CPU-years
total on our computations, implemented in Python, for all of the blockchains.

The nonce vulnerabilities fall into several classes that suggest that we have
found several independent implementation vulnerabilities. We first use the hidden
number problem algorithm to discover the long-term ECDSA signature key when
used with nonces that are shorter than expected, and found keys used with nonces
with lengths 64 bits, 110 bits, 128 bits, and 160 bits. We extend this technique
to discover nonces with shared prefixes and suffixes, and found keys used with
signature nonces that shared prefixes and varied in their 64 least significant bits,
as well as keys used with signature nonces that shared suffixes and varied in their
128 and 224 most significant bits.

Ethics. We are unable to validate the existence of these vulnerabilities without
actually computing the private keys for vulnerable addresses. In the case of
cryptocurrencies, these keys give us, or any other attacker, the ability to claim
the funds in the associated accounts. In the case of SSH or HTTPS, these keys
would give us, or any other attacker, the ability to impersonate the end hosts.
We did not do so, and in the course of our research we did not carry out any
cryptocurrency transactions or active attacks ourselves; our research is entirely
passive, and requires only observation of transactions or general-purpose network
measurements. However, given that we find evidence that other attackers are
already emptying the accounts of cryptocurrency users whose keys are revealed
through known vulnerabilities (both repeated nonces and private keys posted
online), we anticipate that users will be affected once knowledge of this flaw
becomes public. We have attempted to disclose flaws to the small number of
parties we were able to identify, but in most cases we were unable to identify any
particular vendors, maintainers, or users to responsibly disclose to.

Countermeasures. All of the attacks we discuss in this paper can be pre-
vented by using deterministic ECDSA nonce generation [29], which is already
implemented in the default Bitcoin and Ethereum libraries.

2 Related Work

The Hidden Number Problem and ECDSA. The Hidden Number Problem and
the lattice-based algorithm we used to solve it were formulated by Boneh and
Venkatesan, who used it to prove the hardness of computing most significant



Biased Nonce Sense 3

bits for Diffie-Hellman [6]. Howgrave-Graham and Smart [19] and Nguyen and
Shparlinski [26] applied the hidden number problem to show that the DSA
and ECDSA signature schemes are insecure if an attacker can learn some most
significant bits of the signature nonces. Since then, this technique has been
applied in practice in the context of side-channel attacks [5,14].

Repeated DSA/ECDSA signature nonces. A number of works have examined
vulnerabilities in DSA and ECDSA due to repeated signature nonces in the
wild. Heninger, Durumeric, Wustrow, and Halderman [18] compromised SSH
host keys for 1% of SSH hosts in 2012 by searching for repeated DSA signature
nonces from SSH handshakes. They traced the problems primarily back to
implementation vulnerabilities in random number generation on low-resource
devices. Bos, Halderman, Heninger, Moore, Naehrig, and Wustrow [7] documented
repeated nonces in the Bitcoin blockchain in 2013, as part of a broader study
of elliptic curve cryptography use. Valsorda studied repeated Bitcoin nonces in
2014 [37]. Courtois, Emirdag, and Valsorda [13] studied repeated Bitcoin nonces
in 2014 and noted that it would be possible to chain compromises across keys.
Castellucci and Valsorda studied repeated nonces and variants of weak keys and
nonces repeated across keys in Bitcoin in 2016 [11]. Brengel and Rosow examined
repeated nonces within signatures from the same key and chained compromised
nonces across signatures from different keys in the Bitcoin blockchain in 2018 [8].

Key generation issues in cryptocurrencies. In 2013, a major bug in Android
SecureRandom was blamed for the theft of Bitcoin from many users of Android
wallets, due to the faulty random number generators generating repeated ECDSA
signature nonces [20,22]. In 2015, the Blockchain.info Android application was
discovered to be generating duplicate private keys because the application was
seeding from random.org, which had started serving a 403 Redirect to their https
URL several months prior [35].

Cryptocurrency cryptanalysis. The Large Bitcoin Collider is a project that is
searching for Bitcoin private keys using an apparently linear brute force search
algorithm [30] that has searched up to a 54 bit key space. For public keys that
are already revealed, it would be more efficient to use square root discrete log
algorithms [28,34] to recover short private keys of this type, but we are unaware
of any dedicated efforts in this direction.

3 The elliptic curve digital signature algorithm (ECDSA)

The public domain parameters for an elliptic curve digital signature include an
elliptic curve E over a finite field and a base point G of order n on E. The private
signing key is an integer d modulo n, and the public signature verification key is
a point Q = dG. Elliptic curve public keys can be represented in uncompressed
form by providing both the x and y coordinates of the public point Q, or in
compressed form by providing the x coordinate only and a single parity bit from
the y value. [9]

To sign a message hash h, the signer chooses a per-message random integer
k modulo n, computes the point kG, and then computes the values (xr, yr) =



4 Joachim Breitner and Nadia Heninger

kG mod n, and outputs r = xr and s = k−1(h+ dr) mod n. The signature is the
pair (r, s). To verify a message hash using a public key Q, the verifier computes
(x′

r, y
′

r) = hs−1G+ rs−1Q and verifies that x′

r ≡ r mod n. If the bit length ` of
the curve is shorter than the bit length of the hash function used to compute h,
h is truncated to its ` most significant bits prior to the calculation. [25]

3.1 ECDSA in cryptocurrencies.

Bitcoin [23], Ethereum [10], and Ripple [33] all use the elliptic curve secp256k1 [9].
A Bitcoin address is derived from a public key by repeatedly hashing the un-
compressed or compressed ECDSA public key with SHA-256 and RIPEMD-160.
An Ethereum address is the last 20 bytes of the Keccak-256 hash of the un-
compressed ECDSA public key, where Keccak-256 is an early version of the
SHA-3 standard. Ethereum public keys are not explicitly included along with the
signature; instead, the signature includes an additional byte v that allows the
public key to be derived from the signature. A Ripple address is derived from a
compressed public key by repeatedly hashing with SHA-256 and RIPEMD-160,
and concatenating portions of the hashes. For the purposes of the analysis in our
paper, in all of these cryptocurrencies the ECDSA public key is only revealed
after an address has been used to sign a transaction. Bitcoin and Ripple explicitly
reveal the ECDSA public key in uncompressed or compressed format along with
a signature; in Ethereum, clients must derive the public key from the signature
itself using key recovery.

ECDSA signatures are used to authenticate the sending party of a transaction.
Addresses can be single signature, corresponding to a single public key, or
multisignature addresses, which require valid signatures from k out of a set of
n public keys in order to spend money from a transaction. Users are typically
recommended to use a fresh new address for every transaction [2].

Signature normalization. ECDSA signatures have the property that both the
signatures (r, s) and (r,−s) will validate with the same public key. In October
2015, Bitcoin introduced a change in the signing procedure to use the smaller of
s and −s mod n in a signature in order to make signatures unique.3 Ethereum
and Ripple also do this type of signature normalization, which affects our attack.

3.2 ECDSA in network protocols.

ECDSA signatures can also be used in other network protocols. In TLS, every
certificate is signed either by a certificate authority or is self-signed. Most of
these signatures remain RSA signatures in practice. However, when ephemeral
Diffie-Hellman key exchange is chosen as part of the cipher suite in TLS 1.2 and
below, the server signs its portion of the the key exchange, and the client uses
the public key in the certificate to validate this signature [16]. In SSH, every
host has a host key that it uses to sign the entire handshake between client and
server [38]. The client authenticates the server by verifying the signature with
the host public key.

3 https://github.com/bitcoin-core/secp256k1/commit/0c6ab2ff



Biased Nonce Sense 5

3.3 Elementary attacks on ECDSA

If an attacker learns the per-message nonce k used to generate an ECDSA
signature, the long-term secret key d is easy to compute as d = (sk−h)r−1 mod n.

It is also well known that if the same nonce k is used to sign two different
messages h1 and h2 with the same secret key, then the secret key is revealed.
Let (r1, s1) be the signature generated on message hash h1, and (r2, s2) be
the signature on message hash h2. We have immediately that r1 = r2, since
r1 = r2 = x(kG). Then we can compute k = (h1 − h2)(s1 − s2)

−1 mod n, and
recover the secret key as above.

4 Lattice Attacks on ECDSA

The signature nonce k must also be generated uniformly at random modulo n. If
only a subset of the possible values module n are produce as nonces, techniques
for solving the hidden number problem can be used to solve for the secret key d.

4.1 The hidden number problem.

In the hidden number problem as formulated by Boneh and Venkatesan [6], there
is a secret integer Îą modulo a public prime p, and one is given information
about the most significant bits of multiples tiÎą mod p, where the ti are generated
at random and known to the attacker. In other words, one is given m pairs of
integers {(ti, ai)}mi=1 such that tiα− ai mod p = bi with |bi| < B for some B < p.

One can reformulate this problem as seeking a solution x1 = b1, x2 = b2, . . . ,
xm = bm, y = Îą to the underconstrained system of linear equations

x1 − t1y + a1 ≡ 0 mod p

...

xm − tmy + am ≡ 0 mod p

(1)

There are two techniques used to solve this problem in the literature. The
first uses lattice-based techniques [6,19,26] to solve this system in the case of

M =



















p
p

. . .

p
t1 t2 . . . tm B/p
a1 a2 . . . am B



















(2)

larger biases and fewer samples (up to around
100 in practice, with B several bits smaller
than p), and the second uses Fourier anal-
ysis [3,15] and is more suitable with many
samples (at least 232) and very small bias. In
this paper, we focus on the former technique,
which is better suited to the limited number
of signatures we encounter in the wild.

To solve the hidden number problem us-
ing lattices, consider the lattice generated by the rows of matrixM in Equation (2).
The m×m upper left quadrant is a slightly rescaled version of the lattice given by
Boneh and Venkatesan, who suggest using a CVP algorithm to find a vector that



6 Joachim Breitner and Nadia Heninger

is close to the target, which is the (m+ 1)st row in our lattice basis. The most
efficient implementations of lattice algorithms are SVP approximation algorithms,
so we follow [5] in embedding this lattice basis into a slightly larger one and using
an SVP approximation algorithm instead.

The vector vb = (b1, b2, . . . , bm, BÎą/p,B) is a short vector generated by
the rows of Equation (2), and by construction |vb| <

√
m+ 2B. When |vb| ≤

detL1/ dimL, we hope to recover vb among the short vectors of a reduced basis for
the lattice generated by M . We have detM = B2pm−1 and dimM = m+2. The
LLL [21] or BKZ [31,32] lattice basis reduction algorithms can be used to find
short vectors in this lattice. In practice on random lattices, the LLL algorithm
will find a vector satisfying |v| ≤ 1.02dimL(detL)1/ dimL in polynomial time [27].
The performance of BKZ depends on the block size, and will in time exponential
in the block size β find vectors |v| ≤ (1 + ε)dimL

β (detL)1/ dimL where ξβ depends
on the block size, but ξβ = 0.01 is achievable in practice [12].

In this paper, we focus on relatively small dimension lattices, so that the
approximation factor of LLL or BKZ is largely insignificant. In this case, we
expect to solve the problem when logB ≤ blog p(m− 1)/m− (logm)/2c.

4.2 Optimizations.

There are two further optimizations that should be applied to this attack. The
first is that in the case of most significant bits known, the value bi is always
positive, and thus one can increase the bias by recentering the bi by writing
each equation as x′

i − tiy + am +B ≡ 0 mod p which has a solution x′

i = bi −B.
The second improvement is to decrease the dimension of the lattice by one by
eliminating the variable y from Equations (1) so that one has m− 1 equations in
m unknowns, all bounded.

4.3 Implicit prefixes.

We are also interested in the case where the bi share an identical prefix, or in
other words, that they share most significant bits when viewed as an integer
between 0 and p, but we do not know this prefix. That is, the input to the
problem is samples {ti, ai}mi=1 satisfying bi + c+ ai ≡ tiα mod p, with |bi| < B
and 0 ≤ c < p is unknown. We can reduce this problem to the previous problem
with m − 1 samples by using one of the samples to eliminate the unknown c.
That is, we solve the hidden number problem with input {t′i = ti − tm]}m−1

i=1 ,
a′i = ai − am, and the desired solutions b′i = bi − bm satisfy |b′i| ≤ 2B.

4.4 Implicit suffixes.

The technique described in Section 4.3 can also be adapted to solve for bi that
share an identical suffix, that is, that they share least significant bits when viewed
as an integer between 0 and p. More precisely, the input to our problem in this
case is samples {ti, ai}mi=1 satisfying 2`bi + c+ ai ≡ tiα mod p, with 0 ≤ bi < B,



Biased Nonce Sense 7

0 ≤ c < p unknown, and 2`B ≤ p. We can reduce this problem to the case of
shared prefixes by multiplying each sample by 2−` mod n, so that our rescaled
input is samples {2−`ti, 2

−`ai}mi=1 satisfying bi + 2−`c+ 2−`ai ≡ (2−`ti)α mod p,
where |bi| < B and 2−`c is still unknown. At this point this is precisely the
case of shared prefixes, so we may use the hidden number problem algorithm
to solve the case of m− 1 samples generated as {t′i = 2−`(ti − tm) mod n}m−1

i=1 ,
a′i = 2−`(ai−am) mod n, and the desired solutions b′i = bi− bm satisfy |b′i| ≤ 2B.

4.5 Breaking ECDSA with the hidden number problem

To attack ECDSA with biased k values using the hidden number problem [19,26],
note that each signature (ri, si) on hi satisfies

ki − s−1
i rid− s−1

i hi ≡ 0 mod n (3)

If the ki are all small (|ki| < B) or share a common prefix or suffix, then this is
precisely our setting for the hidden number problem variants we describe above,
with ki = bi, Îą = d, p = n, and si, ri, and hi public per signature.

We construct the input to our problem by hypothesizing that a set of signatures
contains one of the vulnerabilities necessary to carry out the attacks described in
Sections 4.1, 4.3, or 4.4, construct the corresponding lattice, and apply a lattice
basis reduction algorithm. For each candidate solution for ki, we compute the
value dki

= (siki−hi)r
−1
i mod n, and compare dki

G to the public key or address.
Experimentally, we found that for a 256-bit n, our case of interest for

secp256k1, we were able to recover the private key from two signatures with 128-
bit nonces by reducing a 3-dimensional lattice with 75% probability, from three
signatures with 170-bit nonces with a 4-dimensional lattice with 95% probability,
from 4 samples with 190-bit nonces with 100% probability; from 20 samples with
242-bit nonces by reducing a 21-dimensional lattice with 100% probability, and
from 40 samples with 248-bit nonces and 41-dimensional lattices.

One can keep continuing by increasing the dimension of the lattice, to a
practical limit of a bias of three or four bits for this 256-bit curve order, at the
cost of solving near-exact SVP, which runs in time exponential in the lattice
dimension, in a high-dimensional lattice.

Unfortunately for the attacker applying these attacks to cryptocurrency
signatures, the signature normalization described in Section 3.1 adds complexity.
We expect half of the signatures to contain a negated s value, but we will not be
able to tell which. From Equation (3), negating s will negate the derived value
of ki. Thus an attack on small ki would still be expected to succeed, since the
lattice algorithm can recover both small positive or small negative values, but
the normalizations required to solve for the case of shared prefixes in Section 4.3
or shared suffixes in Section 4.4 would produce outputs that do not have the
desired properties. For these cases, we brute forced signs for the si.

The signature normalization also means that the relations defining ECDSA
private key recovery from known or repeated nonces as described in Section 3.3
may not hold as described. For these cases we also brute forced sign values for s.



8 Joachim Breitner and Nadia Heninger

5 Bitcoin

5.1 Collecting data

To collect Bitcoin signatures we modified the official client to output hash values
and signatures as they are verified, and re-validated the entire blockchain.

We used a snapshot of the blockchain from September 13, 2018 (block height
541,244). At this point, the blockchain contained 975,560,082 signatures from
446,605,479 distinct keys. 40,497,752 of these keys had been used to generate
more than one signature. 569,396,463, or 58% of the signatures in our snapshot
had been generated by one of these keys.

5.2 Cryptanalytic tests for biased nonces

We clustered signatures by public key and eliminated signatures that were fully
identical, that is, that shared both the hash h and the signature (r, s). For keys
associated with m > 1 distinct signatures, we ran the following randomized tests
on subsamples of the signatures:

– Check if the set of distinct signatures generated by this key contains any
duplicate r values. If so, we compute the private key and all signature nonces
k using Section 3.3 and do not run any of the following.

– Select two signatures at random and check for nonces of length less than 128
bits. We repeated this test 2m times for each key.

– Select three signatures at random and check for nonces of length less than
170 bits. We repeated this test 2m times for each key.

– Select three signatures at random and check for nonces sharing 128 most
significant bits, brute forcing signature normalizations. We repeated this test
2m times for each key.

– Select three signatures at random and check for nonces sharing 128 least
significant bits, brute forcing signature normalizations. We repeated this test
2m times for each key.

– For m ≤ 40, check for nonces of length less than b256(m− 1)/mc − 1 bits,
using all m signatures without signature normalization.

– For m > 40, choose a random subset of 41 signatures and check for nonces
of length less than 248 bits. We repeated this test m/20 times for each key,
without signature normalization.

The parameters were chosen so that these tests would complete in a reasonable
length of time even for the most common keys.

5.3 Running the cryptanalysis

We implemented these tests in Sage [36], using the built-in BKZ implementation
for lattice basis reduction. We ran the computation parallelized across 2000
cores of a heterogeneous cluster with mostly Intel Xeon E5 processors. We ended
up running the computation twice, once without signature normalization on a



Biased Nonce Sense 9

snapshot of the blockchain from March 2018 and once with normalization in
September 2018. For the low-dimensional lattice attacks, the bottleneck of the
computation was the elliptic curve multiplications required to check whether we
had found the correct private key. The total running time for both jobs was 38
CPU years, and the longest-running job (corresponding to a single key that had
generated 1,021,572 signatures in March 2018) completed in 30 calendar days.

5.4 Results and analysis

Biased nonces. After running our attacks, we had computed the private keys
for 302 distinct keys that were compromised via small nonces, nonces with
shared prefixes, or nonces with shared suffixes. These keys had generated 6,026
signatures with these vulnerable nonces in the blockchain, and 7,328 signatures
overall, including signatures that we did not classify as using vulnerable nonces.

For further analysis, we used the BlockSci library [4]. We classified keys by
the signature nonce vulnerability that had compromised them and summarize
the data in Table 1. Nearly all of the compromised keys had been used as part
of multisignature addresses of type 1-out-of-1, 1-out-of-2, 1-out-of-3, 2-out-of-2,
2-out-of-3, 2-out-of-5, or 3-out-of-5.

On September 23, 2018, a total of 745,990 satoshis were in non-multisignature
addresses whose keys were compromised by these biased nonces. An additional
72,985 satoshis were in a multisignature address where we possessed all of the
necessary keys for the account. A further 6,480,000 satoshis were present in
addresses for which we possessed one out of two necessary signatures.

We plot the signatures from biased nonces over time in Figure 1. Nearly all
of the compromised nonces fell into a few clear classes based on the length of the
variable portion of the nonce. We found short nonces of length 160 bits, 128 bits,
110 bits, 64 bits, and a few sporadic nonces below 32 bits. We also found nonces
that shared a fixed prefix followed by a variable 64-bit suffix, and nonces that
varied in the 128 most significant bits and shared a fixed 128-bit suffix. Most of
the affected keys were part of multisignature addresses.

Table 1. Biased signatures and keys. We classified the compromised keys and
signatures by the type of nonce vulnerability that had compromised the private key.
Nearly all of the compromised keys had been used as part of multisignature addresses.

Nonce Type Signatures Distinct Keys Multisignature Keys

Prefix + 64 bits 27 2 0
128 bits + Suffix 121 13 4
160 bits 3 1 0
128 bits 4 2 2
110 bits 2 1 0
64 bits 5,863 280 279
≤ 32 bits 6 3 0



10 Joachim Breitner and Nadia Heninger

2014 2015 2016 2017 2018

32

64

64∗
110

128∗
160

128+suffix

128+suffix∗

prefix+64

N
o
n
ce

ty
p
e

Fig. 1. Bitcoin signatures with small and biased nonces over time. We plot
signatures with biased nonces over time, grouped by the class of bias we observed, and
whether they are used with multisignature addresses (marked with ∗). Larger circles
correspond to more signatures on a given date. We note that the different types of
biases appear at different date ranges, suggesting that these vulnerabilities are specific
to distinct implementations.

64-bit nonces. We found 5,863 signatures from 280 distinct keys that used 64-bit
nonces. All but one of these keys was used as part of multisignature addresses.
All of these signatures appeared between July 26, 2014 and June 1, 2015.

Two accounts related to these keys have a non-zero balance: One 2-out-of-2
address, for which we have one private key, has a single satoshi. One 2-out-of-3
address, for which we have two private keys, has a balance of 72,985 satoshis.

After we posted a preprint of this paper online, Gregory Maxwell in personal
communication identified the likely culprit: On July 12th, the bitcore library,
a general purpose JavaScript bitcoin library provided by BitPay, was updated
to use a different elliptic curve library. The changes introduced in this update
included setting the length of the random nonces to eight bytes.4 This matches
the July 2014 appearance of the vulnerable 64-bit nonces we identified.

The bug was fixed on August 11, 2014.5 Yet we observed these nonces for
almost a full year; this indicates that not all products that build on top of bitcore
upgrade their dependencies in a timely manner.

64-bit nonces and single-signature keys. Our lattice attack only applies when at
least two signatures with a small nonce are created using the same secret key.
A single 64-bit nonce requires only 232 time to break using Shanks’s baby-step-
giant-step algorithm [34] or the Pollard rho algorithm [28], feasible with only
modest computation resources. However, applying this attack to all of the 230

Bitcoin signatures was beyond our resources, so we searched a random sample.

4 https://github.com/bitpay/bitcore/pull/409/commits/ac4d318
5 https://github.com/bitpay/bitcore/commit/9f9e2f1d



Biased Nonce Sense 11

We precomputed a set of 239 small powers, storing the low 64 bits of the
x coordinate, and also computed a lookup table mapping 232 small powers to
their exponent. The bottleneck is the random accesses into the precomputed
lookup tables, so we chose the parameters so that they fit into the RAM of
our largest-memory machine (2.2TB). One signature takes approximately five
minutes on one core to search.6

We spent 4 calendar days of computation time, or 4,000 core-hours, to check
a random sample of 50,000 Bitcoin multisig signatures from the relevant period
in 2014-2015. We found 169 small nonces this way, revealing 116 private keys. Of
these, 108 were already compromised using the lattice attacks.

110-, 128-, and 160-bit nonces. We found a few sporadic signatures that used
larger nonce lengths that were broken by our lattice techniques. These may
be individual programming errors, but do not appear to be part of common
implementations. None of the affected accounts had a non-zero balance.

– Three 160-bit nonces, all of which were used with the same key, all on the
same date in September 2017. This key did not produce any more signatures
in our data. We hypothesized that a 160-bit nonce length might be explained
by a user generating a nonce using a hash function with 160-bit output, as
in deterministic ECDSA, but were unable to verify this.

– Four 128-bit nonces from two keys. Each key generated two signatures with
128-bit nonces on the same two days in March 2016, and no further signatures.

– One signed 110-bit nonce, used with one key in January 2017, which had
also generated a normal-looking 256-bit nonce on the same day.

256-bit nonces with shared 128-bit suffixes. 121 signatures were compromised by
nonces that shared a 128-bit suffix with at least one other signature. 55 of these
signatures were used with multisignature addresses and 66 were generated by
non-multisignature addresses. 13 keys were compromised this way, which had
generated a total of 224 signatures. There were 20 distinct suffixes that had been
used by these keys. The earliest signature of this type that we found was from
March 2015, and the most recent was from August 2018. Some of the keys were
used with nonces that all shared the same suffix, and some were used with nonces
of varying and occasionally unique suffixes.

We found that a number of the addresses associated with these compromised
signatures had been posted on the web along with their private keys for a variety
of reasons: they corresponded to small integer private keys, private keys derived
from easy-to-guess passwords such as “satoshi”, or private keys used as examples
in documentation. All of the affected accounts had a zero balance.

Interestingly, in 54 of the signatures, the 128-bit nonce suffix is identical
to the 128 most significant bits of the private key. The vulnerable transactions
emptied the relevant accounts. We hypothesize that the vulnerable nonce suffixes
we observe may actually be due to a custom implementation used by an attacker

6 The code can be found at:https://github.com/nomeata/secp265k1-lookup-table.



12 Joachim Breitner and Nadia Heninger

2011 2012 2013 2014 2015 2016 2017 2018

other repeat

other repeat∗

(n− 1)/2

Fig. 2. Bitcoin signatures with repeated nonces over time. We plot repeated
signature nonces over time, separating the value (n−1)/2, which seems to have been used
intentionally, from other repeated nonces. Larger circles correspond to more signatures
on a given date. Signatures involving multisignature addresses are marked with ∗. The
vertical bars mark when the development (left) and release (right) versions of the official
bitcoin client began to create nonces deterministically [29].

who is emptying accounts from Bitcoin addresses that were already compromised
online. The overlapping bits between the nonce and the private key might be an
artifact from a bug in a program written in a memory-unsafe language like C.

256-bit nonces with shared 192-bit prefixes. We computed 2 keys that had
been used with 27 signatures with nonces sharing prefixes. Each key had some
signatures with the shared prefix and some without. One of the two keys has a
balance of 495,990 satoshis, and seems to be in current use at the time of writing.

Repeated nonces As a side effect of our analysis, we";"""date"",""2020-07-22T23:13:23Z""
""pdf:PDFVersion"",""1.4""
""xmp:CreatorTool"",""LaTeX with hyperref""
""pdf:docinfo:title"",""""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""pdfa:PDFVersion"",""A-1b""
""language"",""en""
""dc:format"",""application/pdf; version=""""A-1b"""""",""application/pdf; version=1.4""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""xmp:CreateDate"",""2020-07-22T19:13:23Z""
""modified"",""2020-07-22T23:13:23Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""xmp:ModifyDate"",""2020-07-22T19:13:23Z""
""pdf:docinfo:creator"",""""
""meta:author"",""""
""meta:creation-date"",""2020-07-22T23:13:23Z""
""created"",""2020-07-22T23:13:23Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-07-22T23:13:23Z""
""resourceName"",""10174436""
""pdfaid:part"",""1""
""Author"",""""
""producer"",""Neevia Document Converter Pro v7.1 build 94 (http://neevia.com)""
""pdf:docinfo:producer"",""Neevia Document Converter Pro v7.1 build 94 (http://neevia.com)""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""5"",""0"",""12"",""14"",""2"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2020-07-22T23:13:23Z""
""Last-Modified"",""2020-07-22T23:13:23Z""
""dcterms:modified"",""2020-07-22T23:13:23Z""
""title"",""""
""xmpMM:DocumentID"",""uuid:71018f24-cecc-11ea-0000-63782dcfd35d""
""Last-Save-Date"",""2020-07-22T23:13:23Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2020-07-22T23:13:23Z""
""meta:save-date"",""2020-07-22T23:13:23Z""
""Content-Length"",""249867""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""pdfaid:conformance"",""B""
""pdf:producer"",""Neevia Document Converter Pro v7.1 build 94 (http://neevia.com)""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""18""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""2130"",""2724"",""2664"",""2580"",""1909"",""2277"",""2616"",""2085"",""2167"",""1936"",""2595"",""2288"",""1985"",""2106"",""2135"",""2623"",""2887"",""1146""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-07-22T23:13:23Z""
";https://scholar.google.com/scholar?start=960&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094668-1184;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Themis: Towards decentralized escrow of cryptocurrencies without trusted third parties;H Meng, E Bian, C Tang ; 2019 Sixth International Conference …, 2019  ieeexplore.ieee.org;;"… A. Transactions Between Different Digital Currencies Traditionally, transactions between digital

currencies are executed on cryptocurrency exchanges … Jiang Zhang, Yu Chen, Zhenfeng Zhang,

CRYPTO 2016 … [11] Astraea: A Decentralized Blockchain Oracle, Ryan Berryhill and …";Cité 2 fois;;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/8764267/8768486/08768704.pdf?casa_token=AJtNPmZtkz4AAAAA:rcrXF7sNxgnNoPQnFpRFN3o0Xw_2WMUdcSNOuBzSix_I8hQKX2TVTkBrrYri7KADgAq5kJZVa-4;"
		Skip to Main Content


		
			
				
				

				

			

		


		
			
				
					
						








	
		
	

	







						

						





























	
	
		
	
	
		
			

		
	

	
	
	



						





	
	
		
			
				IEEE Account

					Change Username/Password
	Update Address


			

			
				Purchase Details

					Payment Options
	Order History
	View Purchased Documents


			

			
				Profile Information

					Communications Preferences
	Profession and Education
	Technical Interests


			

			
				Need Help?

					US & Canada: +1 800 678 4333
	Worldwide:  +1 732 981 0060

					
	Contact & Support


			

		

		
			
				
					
							About IEEE Xplore
	Contact Us
	Help
	Accessibility
	Terms of Use
	Nondiscrimination Policy
	Sitemap
	Privacy & Opting Out of Cookies


						
							A not-for-profit organization, IEEE is the world's largest technical professional organization dedicated to advancing technology for the benefit of humanity.
Š Copyright 2021 IEEE - All rights reserved. Use of this web site signifies your agreement to the terms and conditions.
						

					


					

				

				
			

		

	


	
	


						
						






		
		
		
		
		
		
		
		
		
		
		
		
		
			
				
			
			
			
			
		
		
		
		
		
		

			


			

			
			


		
 		
		
			 

						
						









































	

		
		

		
		
		

		
			
		
		
		

		

		
		


		

		
		
		
		
		
		
		
		
		
		
	
	


















		
		
			
				
					
					
								
					
								
			
				
					
					
								
					
								
			
				
					
						








 



					
					
								
			
				
					
					
								
			
				
					
					
								
					
								
			
				
					
					
								
					
								
			
				
					
					
								
					
								
			
				
					
					
								
					
								
			
				
					
					
								
					
								
			
				
					
					
								
					
								
			
		
	




























		
			
					
			
					
			
					
			
				
					








					
			
					
			
					
			
					
			
					
			
					
			
					
			
		
		
	





	
	
	
	
	
	
	


	
	
	

	

















					

				

			


			
				
			
		

	";"""og:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""twitter:title"",""Themis: Towards Decentralized Escrow of Cryptocurrencies without Trusted Third Parties""
""twitter:card"",""summary""
""Description"",""We introduce an improvement fair exchange method called Themis, which does not require Trusted Third Parties. Themis system is implemented based on blockchain, ""
""og:title"",""Themis: Towards Decentralized Escrow of Cryptocurrencies without Trusted Third Parties""
""resourceName"",""08768704.pdf""
""language"",""en""
""title"",""Themis: Towards Decentralized Escrow of Cryptocurrencies without Trusted Third Parties | IEEE Conference Publication | IEEE Xplore""
""og:description"",""We introduce an improvement fair exchange method called Themis, which does not require Trusted Third Parties. Themis system is implemented based on blockchain, and can provide escrow services for secure exchanging between cryptocurrencies and physical goods. We propose many application scenarios for Themis, such as peer-to-peer escrow payments, exchanges among digital currencies. We implement a test-net for Themis and the experimental results shows that Themis protocol is practical in real-world distributed environment.""
""twitter:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-UA-Compatible"",""IE=Edge""
""viewport"",""width=device-width, initial-scale=1.0""
""dc:title"",""Themis: Towards Decentralized Escrow of Cryptocurrencies without Trusted Third Parties | IEEE Conference Publication | IEEE Xplore""
""twitter:description"",""We introduce an improvement fair exchange method called Themis, which does not require Trusted Third Parties. Themis system is implemented based on blockchain, and can provide escrow services for secure exchanging between cryptocurrencies and physical goods. We propose many application scenarios for Themis, such as peer-to-peer escrow payments, exchanges among digital currencies. We implement a test-net for Themis and the experimental results shows that Themis protocol is practical in real-world distributed environment.""
""Content-Encoding"",""UTF-8""
""Content-Type-Hint"",""text/html; charset=utf-8""
""Content-Length"",""39464""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=410&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094583-840;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Lattice RingCT V2. 0 with multiple input and multiple output wallets;WA Torres, V Kuchta, R Steinfeld, A Sakzad… ; … on Information Security …, 2019  Springer;;"… and decentralised cryptocurrency to date, having its three underlying building blocks: transactions,

blockchain and consensus … We now list all the adversarial oracles used in RCT, and we define

them as … AddGen(i): on input a query number i, this oracle picks randomness \(\tau _i …";Cité 8 fois;Les 7 versions;[PDF] iacr.org;https://eprint.iacr.org/2019/569.pdf;"
Lattice RingCT v2.0 with Multiple Input and Multiple Output
Wallets

Wilson Alberto Torres1, Veronika Kuchta1, Ron Steinfeld1,
Amin Sakzad1, Joseph K. Liu1 and Jacob Cheng2

1 Faculty of IT, Monash University, Melbourne, Australia
{Wilson.Torres,Veronika.Kuchta,Ron.Steinfeld,

Amin.Sakzad,Joseph.Liu}@monash.edu
2 Collinstar Capital, Melbourne, Australia

jacob@collinstar.com

Abstract. This paper presents the Lattice-based Ring Confidential Transactions “Lattice RingCT
v2.0” protocol. Unlike the previous Lattice RingCT v1.0 (LRCT v1.0) protocol, the new protocol
supports Multiple-Input and Multiple-Output (MIMO) wallets in transactions, and it is a fully
functional protocol construction for cryptocurrency applications such as Hcash. Since the MIMO
cryptocurrency setting introduces new balance security requirements (and in particular, security
against out-of-range amount attacks), we give a refined balance security model to capture such
attacks, as well as a refined anonymity model to capture amount privacy attacks. Our protocol
extends a previously proposed ring signature scheme in the LRCT v1.0 protocol, to support the
MIMO requirements while preserving the post-quantum security guarantees, and uses a lattice-based
zero-knowledge range proof to achieve security against out-of-range attacks. Preliminary parameter
estimates and signature sizes are proposed as a point of reference for future studies.

Keywords: Cryptocurrencies, Lattice-Based Cryptography, Post-Quantum Cryptography, RingCT.

1 Introduction

In the current digital age, cryptocurrencies are applications that use virtual assets and cryptographic
mechanisms to conduct e-commerce operations such as electronic payments or money transfers. Those
payments can be carried out among accounts or wallets, independently of a central party [11]. Cryptocur-
rencies lead to some advantages like lower transaction fees, theft resistance and anonymous transactions.
Bitcoin [26] is by far the most widely known and decentralised cryptocurrency to date, having its three
underlying building blocks: transactions, blockchain and consensus protocol. Contrary to the traditional
banking model, Bitcoin allows electronic financial operations in a decentralised Peer-to-Peer (P2P) net-
work. Although Bitcoin was intended to achieve the security properties of privacy and anonymity by using
pseudonyms, some analyses [30, 17] show that these security properties can be compromised, therefore
information about the payers, payees and transactions can be revealed. Thus Bitcoin is only a pseudo-
anonymous cryptocurrency.

Nonetheless, since its creation, Bitcoin has revolutionised the field of digital currency and motivated
the invention of new cryptocurrencies, also known as alcoins. As an example, CryptoNote [34] was proposed
to address the privacy weaknesses of Bitcoin, as it also offers a framework that can be extended by other
cryptocurrencies such Bytecoin [7] and Monero [25]. CryptoNote uses traceable ring signatures [16] as a
fundamental component to achieve true anonymity, where any member of the ring (or group) can create
a signature, but it is infeasible by a verifier to identify the real signer. This type of signature hides
information about the sender and receiver, and it also has a linking tag to prevent double spending coins.
Further enhancements to this framework have resulted in an extended protocol called Ring Confidential
Transactions “RingCT” [27]. The RingCT protocol uses three techniques: a new type of ring signature
Linkable Ring Signatures [19], a homomorphic commitment and a range proof, to preserve the privacy of
the sender and the receiver as well as the transaction amounts.

However, the security of this RingCT protocol relies on classical number-theory assumptions, such
as the hardness of discrete logarithms [14]. As a consequence, this protocol will be vulnerable in the



2 W. Alberto Torres et al.

event of powerful quantum computers [31]. This situation has motivated researchers in the area of post-
quantum cryptography to construct secure approaches against quantum attacks. Among the alternatives,
lattice-based cryptography has attracted attention due to its distinguishing features and robust security
guarantees [24, 9].

To the best of our knowledge, the first post-quantum RingCT scheme using Lattice-based cryptography
was proposed in [1]. However, this proposal is limited. Firstly, it only enables transfers from a single input
wallet to a single output wallet (SISO). In the RingCT model, signatures are one-time, then if one needs
to receive change after making a payment or transfer, a new output wallet is required, so this points out
the importance of supporting multiple input and output wallets. Secondly, having more than one output
wallet also introduces a new security problem like the negative output amount (or out-of-range) attack
[6], where an adversary is capable of creating extra coins. This attack is addressed in the previous RingCT
[27] by using a range proof technique; however, this technique is not post-quantum secure.

1.1 Contributions

– We construct the Lattice-based Ring Confidential Transactions (LRCT) for Multiple-Input and
Multiple-Output wallets (MIMO). This construction is a generalisation of the SISO.LRCT scheme in
[1] where we changed its underlying framework (L2RS signature) to be compatible. Our MIMO.LRCT
inherits the post-quantum security guarantees, like the hardness of lattice mathematical assumptions
as well as unconditional anonymity.

– We improve the MIMO.LRCT’s security model, in particular, the balance and anonymity properties.
We explicitly define a balance model that considers out-of-range attacks [6], and we prove the security
of our protocol which previous RingCT’s proposals [1, 33] did not address. User anonymity is only
addressed in [33], while we include the analysis of both user anonymity and amount privacy.

– We show how to incorporate a lattice-based range proof into our MIMO.LRCT protocol, which was a
missing ingredient in former proposals [1, 33]. To begin with, our protocol deals with the difficulties
of the imperfection of lattice-based zero-knowledge proofs, Section 5.1 discusses more on this. In
particular, range proofs follow the approach based on 1-of-2 OR-proofs, but our analysis shows that
directly applying lattice-based OR-proofs from [12] does not provide soundness for the range proof.
This argument leads us to carefully select the challenge space as we describe in Lemma 3. Although
these challenges are smaller (in norm) than the ones used in the OR-proofs, they are still larger than
the challenges in [18]. In this framework, we achieve lower soundness error than the previous lattice-
based range proof [18]. We also provide a thorough concrete analysis of the MIMO.LRCT protocol by
including this range proof analysis.

– We apply our concrete bounds to derive preliminary scheme parameters for regular RingCT transac-
tions that support 64-bit amounts along with fewer Multiple Input and Output wallets. This analysis
serves as a benchmark for future practical implementations.

The organisation of this work is as follows. Section 1.2 presents CryptoNote and RingCT protocols litera-
ture. After introducing the notation and concepts used in our work in Section 2, we define the MIMO.LRCT
as well as its security model in Section 3. Section 4.1 involves the concrete construction of the homomor-
phic commitment and the MIMO.L2RS signature schemes, then Section 5 illustrates the construction of
MIMO.LRCT. Section 6 and 7 point out the MIMO.LRCT’s security and performance analyses, respectively.

1.2 Related Work

Evaluations [22, 28] of CryptoNote have discovered serious vulnerabilities which impact the privacy of the
involved parties in the transactions. Therefore, the Ring Confidential Transactions RingCT [27] protocol
was devised to address these issues. The RingCT extends the CryptoNote scheme by using a new class of
linkable ring signature called Multi-layered Linkable Spontaneous Anonymous Group Signature (MLSAG)
[19]. This signature is spontaneous (or ad-hoc), which removes the dependency of a trusted third party
and group members are unaware of belonging to a determined group, thereby enhancing the anonymity
property. It is also multilayered, meaning that it enables multiple input and output wallets in transactions.
The security of RingCT is ameliorated by introducing the Confidential Transactions [23], which enables



Lattice RingCT v2.0 with Multiple Input and Multiple Output Wallets 3

amounts to be hidden by using the Pedersen Commitment [29] technique. This cryptographic primitive
enables a party to commit to a chosen secret value while keeping it hidden to other parties, where this
commitment can later be opened. Such a primitive offers homomorphic properties allowing parties to
prove the account balance by computing homomorphically input and output accounts to show that their
result is zero. RingCT added another verification mechanism for the committed output amounts which
was called range proof, guaranteeing that this amount lies in a range of non-negative values and avoiding
the creation of free money. Bulletproofs [6] is an efficient technique for this range preservation.

RingCT v2.0 [33] was later proposed. It provided sound security analysis of the (RingCT) protocol
as well as improved the size of the signature by using one-way accumulators [4] along with signatures of
knowledge “SoK” [8]. However, it requires a trusted setup for its accumulator to achieve the signature
constant size. The first post-quantum RingCT protocol was proposed in [1], where the authors named it
Lattice RingCT v1.0. This construction uses lattice-based cryptography to design a new Linkable Ring
Signature, which is called Lattice-based Linkable Ring Signature (L2RS). The L2RS follows the well known
Fiat-Shamir [15] transformation signature: Bimodal Lattice Signature Scheme (BLISS) [13], a practical
and secure lattice-based signature scheme. The L2RS offers computational security as per the hardness
of lattice assumptions for unforgeability, linkability and non-slanderability, it also achieves unconditional
anonymity. However, the proposed Lattice RingCT v1.0 showed no security definition or proofs, and
transactions were restricted to Single Input and Single Output wallets.

2 Preliminaries

The polynomial ring R = Z[x]/f(x), where f(x) = xn + 1 with n being a power of 2. The ring Rq is
then defined to be the quotient ring Rq = R/(qR) = Zq[x]/f(x), where Zq denotes the set of all positive
integers modulo q (a prime number q = 1 mod 2n) in the interval [−q/2, q/2]. The challenge space Sn,κ, is
the set of all binary vectors of length n and weight Îş. A hash function modeled as Random Oracle Model
(ROM), H1 with range Sn,κ ⊆ R2q. When we use x← D for a distribution D, it means that x is sampled
from D, and when we use x← S for a set S, it means that x is uniformly sampled at random from S. If
we use r||, it means r is concatenated such

(
r(1), . . . , r(θ)

)
for any θ. The discrete Gaussian distribution

over Zm with standard deviation σ ∈ R and center at zero, is defined by Dm
σ (x) = ρσ(x)/ρσ(Zm), where

ρσ is the m-dimensional Gaussian function ρσ(x) = exp(−‖x‖2/(2σ2)). Vector transposition is denoted
by vT . The hardness assumption of this work is the Module-SIS (Short Integer Solution) problem and is
defined as follows.

Definition 1 (MSISKq,m,k,β problem). Let K be some uniform distribution over the ring Rk×mq . Given

a random matrix A ∈ Rk×mq sampled from K distribution, find a non-zero vector v ∈ Rm×1
q such that

Av = 0 and ‖v‖2 ≤ β, where ‖ · ‖2 denotes the Euclidean norm.

Lemma 1 (Rejection Sampling-BLISS). (Based on [13], Lemma 2.1). Let V be an arbitrary set, and
h : V → R and f : Zm → R be probability distributions. If gv : Zm → R is a family of probability
distributions indexed by v ∈ V with the property that there exists a M ∈ R such that ∀v ∈ V,∀v ∈
Zm,M · gv(z) ≥ f(z). Then the output distributions of the following two algorithms are identical:

1. v ← h, z← gv, output(z, v) with probability f(z)/(M · gv(z)).
2. v ← h, z← f, output(z, v) with probability 1/M .

Lemma 2 (Rejection Sampling-Gaussian Distribution).

Lemma 3. (Based on [5]) Let R = Z[X]/(Xn + 1) where n > 1 is a power of 2 and 0 < i, j < 2n − 1.
Then all the coefficients of 2(Xi−Xj)−1 ∈ R are in {−1, 0, 1}. This implies that ‖2(Xi−Xj)−1‖ ≤

√
n.

Lemma 4. For a, b ∈ Rq = Zq[X]/(Xn + 1) the following relations hold ‖a‖ ≤
√
n‖a‖∞, ‖a · b‖ ≤√

n‖a‖∞ · ‖b‖∞, ‖a · b‖∞ ≤ ‖a‖ · ‖b‖.

Lemma 5 (Leftover Hash Lemma (LHL)). (Based on [13], Lemma B.1). Let H be a universal hash
family of hash functions from X to Y. If h← H and x← X are chosen uniformly and independently, then

the statistical distance between (h,h(x)) and the uniform distribution on H× Y is at most
1

2

√
|Y |/|X|.



4 W. Alberto Torres et al.

Remark 1. We use this lemma for a SIS family of hash function H(S) = A ¡ S ∈ Rq,with S ∈ DomS,

where each function is indexed by A ∈ R1×(m−1)
q and DomS ⊆ R1×(m−1)

q consists of vectors of Rq
elements with coefficients in Γ , (−2γ , 2γ). This is a universal hash family if for all S 6= S′, we have

Pr
[
A · S = A · S′

]
=

1

|Rq|
.

This is a universal hash family if there exists 1 ≤ i ≤ m − 1 such that si − s′i is invertible in Rq with
si, s

′
i ∈ Γn. This can be guaranteed by appropriate choice of q, e.g. as shown in ([21], Corollary 1.2), it is

sufficient to use q such that f(x) = xn + 1 factors into k irreducible factors modulo q and 2γ < 1√
k
¡ q1/k.

We assume that Rq is chosen to satisfy this condition.

2.1 Homomorphic Commitment Definition

This is a cryptographic technique that is used to provide confidential transactions, in particular cryp-
tocurrencies [27]. This primitive allows one party to commit to a chosen value while keeping it secret to
other parties, then this committed value can be revealed later. The definition of such technique, which is
based on [2], has three algorithms: (KeyGen, Com, Open), such that:

– Pub-Params ← KeyGen(1λ): A PPT algorithm that produces a public commitment parameter Pub-
Params after receiving the security parameter (Îť).

– c← Com: A PPT algorithm that receives the Pub-Params, the randomness r and the message m. This
algorithm generates the commitment c.

– m′ ← Open: A PPT algorithm that receives the commitment c along with the randomness r, and it
outputs m′. A valid commitment c is opened if (m′ = m).

The security properties of this non-interactive homomorphic commitment scheme are defined as:

Definition 2 (Hiding). This property ensures that the commitment Com(m, r) does not leak information
on m, that is, for any PPT adversary A, it holds that:∣∣∣∣Pr

[
A(cb) = b :

Pub-Params← KeyGen(1λ); r← RandGen(Pub-Params);
(m,m′)← A(Pub-Params); b← {0, 1}; cb ← Com(r,mb)

]
− 1

2

∣∣∣∣ ,
is negl(Îť).

Definition 3 (β−Binding). This property ensures that the commitment Com(m, r) can only be opened
in one way, that is, for any PPT adversary A, it holds that:

Pr

 r 6= r′ ∧
m 6= m′ ∧
Com(m, r) = Com(m′, r′)

:
Pub-Params← KeyGen(1λ);
r← RandGen(Pub-Params);
(m, r,m′, r′)← A(r)

 ≤ negl(λ),

where ‖r‖, ‖r′‖ ≤ β.

2.2 Fiat-Shamir Non-Interactive Zero-Knowledge Proofs in the Random Oracle Model

Zero-knowledge proof of knowledge (ZKPoK) is a two party protocol between the prover and the verifier,
which allows the prover to convince the verifier that he knows some information, without revealing
anything about the secret apart from what the claim itself already reveals [5].

Definition 4. Let be L ⊆ {0, 1}∗ the language that has witness relationship R ⊆ {0, 1}∗ × {0, 1}∗ if
x ∈ L ↔ ∃(x,w) ∈ R. We call w a witness for x ∈ L. Let (P,V) be a two-party protocol where P (prover)
and V (verifier) are PPT algorithms, and L,L′ be languages with witness relations R,R′ with R ⊂ R′.
Then (P,V) has a proof σ with completeness error ι, public input x and private input w, if the following
conditions are satisfied:



Lattice RingCT v2.0 with Multiple Input and Multiple Output Wallets 5

– The protocol uses a hash function H modeled as a random oracle which is called by both P and V.
This protocol has the following form: on input (x,w), P outputs a proof σ that is sent to V. On input
x, the verifier V accepts or rejects σ.

– Completeness: whenever (x,w) ∈ R, the honest verifier accepts the proof σ with probability at least
1− α.

– Soundness: given a dishonest prover A with input x, it outputs a valid proof σ with non-negligible
probability, then there there exists a PPT algorithm E (the knowledge extractor) that extracts a witness
w′ satisfying (x,w′) ∈ R′.

– Special honest-verifier zero-knowledgeness (HVZK): there exists two PPT algorithms S (the simulator)
and SH (random oracle simulator) that take x ∈ L, and output the proofs σsim = S(x) and SH(x, ¡)
such that is computationally indistinguishable from σ = P(x,w) and H(¡) generated by a real protocol.

3 Ring Confidential Transaction Protocol (RCT)

The RCT protocol is defined based on the former RingCT 2.0 protocol in [33].

Definition 5 (Account or wallet). A wallet has a public component “act” and a private component
“ask”. The act is composed of the user’s pk (or a valid address) and the coin cn, while the ask is formed
of the user’s sk along with the coin-key ck.

The RCT protocol has five PPT algorithms (RCT.Setup, RCT.KeyGen, RCT.Mint, RCT.Spend, RCT.Verify)
as well as the correctness (RCT.Correctness). The RCT’s algorithms are defined as follows:

– RCT.Setup: this PPT algorithm takes the security parameter λ and outputs the public parameters
Pub-Params.

– RCT.KeyGen: this PPT algorithm uses the Pub-Params to produce a pair of keys, the public-key pk
and the private-key sk.

– RCT.Mint: a PPT algorithm generating new coins by receiving Pub-Params and the amount $. This
algorithm outputs a coin cn and a coin-key ck.

– RCT.Spend: a PPT algorithm that receives the Pub-Params, a set of input wallets {IWi}i∈[w] with w
being the size of the ring, a user π’s input wallets IWπ along with its set of secret keys Kπ, a set of
output addresses OA, some transaction string µ ∈ {0, 1}∗, the output amount $ and the set of output
wallets OW . Then, this algorithm outputs: the transaction TX = (Âľ, IW,OW ), the signature sig and
a set of transaction/serial numbers TN , which is used to prevent the double spending coins.

– RCT.Verify: a deterministic PPT algorithm that takes as input the Pub-Params, the signature sig,
the TX, and the TN and verifies if the transaction was legitimately generated and outputs either:
Accept or Reject.

Transaction Correctness requirements: RCT.Correctness ensures that an honest user (payer) is
able to spend or transfer any of his accounts (wallets) into a group of destination accounts (payee), where
this transaction is accepted with overwhelming probability by a verifier. Thus the correctness of RCT is
guaranteed if for all PPT adversaries A, it holds that:

Pr


LRCT.Verify

(
TX, sig, TN

)
= 1:

Pub-Params←LRCT.Setup(1λ);
(µ, IW,OA)←A(Pub-Params, IWπ,Kπ)
with (IWπ,Kπ) as in Table 1;
(pk, sk)←LRCT.KeyGen(Pub-Params);
(cn, ck)←LRCT.Mint(Pub-Params, $);
(TX, sig, TN)←LRCT.Spend(µ,
Pub-Params, IWπ,Kπ, IW,OA, $(out)).


=1.

3.1 Oracles for adversaries

We now list all the adversarial oracles used in RCT, and we define them as:
– AddGen(i): on input a query number i, this oracle picks randomness τi, runs algorithm

(
pki, ski

)
←

RCT.KeyGen(Pub-Params, τi), and returns the public-key or one-time address pki.



6 W. Alberto Torres et al.

– ActGen(i, $i): on input a query number i and an amount $i, it runs (cni, cki) ←
RCT.Mint

(
Pub-Params, $i

)
. Then, ActGen adds i and the account acti =

(
pki, cni

)
to empty lists I

and IW , respectively. ActGen outputs (acti, cki) for the one-time address pki, where these addresses
are added to a list PK. The associated secret key with account acti is defined as aski , (ski, cki).
With this aski, the challenger calls MIMO.L2RS.SigGen(ski, ¡ , ¡ , ¡ ) to determine the transaction num-
ber TNi of acti and adds it to a list T N .

– O-Spend(µ, IW, IWπ, OA, $(out),Pub-Params): on input the transaction string µ, input ac-
counts (wallets) IW containing IWπ and output addresses OA, it runs (TX, sig, TN) ←
RCT.Spend(µ,Kπ, IW, IWπ, OA, $(out),Pub-Params) and adds the outputs to T , where IWπ ∈ IW .
We assume that at least one account/address in IWπ has not been corrupted. We define the set of
transaction numbers in the RCT.Spend queries as T N ∗.

– Corrupt(i): on input query number i ∈ I, uses account key aski to determine the transaction/serial
number TNi of account acti with address pki, then adds TNi and (TNi, $i) to lists C and B respectively
and finally returns τi.

3.2 Threat Model

The protocol RCT is modeled in terms of balance, anonymity and non-slanderability for security analysis
purposes, which are defined as follows.

Definition 6 (Balance). This property requires that any adversary cannot spend any account without
her control and cannot spend her own accounts with a larger output amount. This security property is
guaranteed if for all PPT adversaries A, it holds that:

Pr

[
A wins :

Pub-Params← LRCT.Setup(1λ);

({IW (k)
i }i∈[w],k∈[Nin], T )← AAddGen,ActGen,O-Spend,Corrupt(Pub-Params)

]
,

is negl(λ), where adversaries’ oracles are defined in Section 3.1. We have that IW
(k)
i =

{pk
(k)
(in),i, cn

(k)
(in),i}i∈[w],k∈[Nin] and T = (TX, sig, TN). These spends can be transferred to the challenger

with the account address pk(out) = {pk
(j)
(out)}j∈[Nout], where we assume not all of them are corrupted, and

at least one of them is honest. This pk(out) has been created by the AddGen oracle, so the challenger knows
all balances of the spent accounts and output accounts involved in the adversarial spends T . This means

that TX = (¾, IW,OW ) with OW = {OW (j)}j∈[Nout] = {pk
(j)
(out), cn

(j)
(out)}j∈[Nout] being the output wallet

corresponding to output account pk(out). The adversary A wins this experiment if her outputs satisfy the
following conditions:

1. RCT.Verify(TX, sig, TN) = 1.

2.
∑
k∈E(in)

$
(k)
(in),π <

∑
j∈G(out)

$
(j)
(out), where we let π ∈ [w] s.t. π′s row {pk

(1)
(in),π, . . . , pk

(Nin)
(in),π} are the

ones that have {TN (1)
π , . . . , TN

(Nin)
π } which are found in ActGen, E(in) are the corrupted inputs, and

G(out) are the not corrupted outputs in T . For each TN (k) let $
(k)
(in) be the amount queried to ActGen

at the index query i such TN ⊆ T N . $
(k)
(in) is also defined as equal to zero if IW

(k)
i is equal to some

input wallet IW queried to O-Spend, using same TN , which means that IW
(k)
i has been spent.

3. TN cannot be the output of previous queries to the O-Spend(·) (i.e. TN ∩ T N ∗ = ∅).
4. pkπ is queried to O-Spend oracle only once.

5. PK ⊆ PK, where PK , {pk
(k)
(in),i}i∈[w],k∈[Nin].

Our extended anonymity property captures two types of attacks (compared to one type in [33]) that
depend on the adversary’s choices for users π0, π1 ∈ [w] and output amounts $(out),0, $(out),1. It starts
with the user anonymity attack where the adversary selects π0 6= π1 with $(out),0 = $(out),1, while in the
amount privacy attack this adversary chooses π0 = π1 with $(out),0 6= $(out),1. We formally define this
property as:



Lattice RingCT v2.0 with Multiple Input and Multiple Output Wallets 7

Definition 7 (Anonymity). This property requires that two proofs of knowledge with the same trans-
action string Âľ, input accounts IW , output addresses OA, distinct both output amounts ($(out),0, $(out),1)
and spent accounts IWπ0 , IWπ1 ∈ IW are indistinguishable, meaning that the spender’s accounts and
amounts are successfully hidden among all the honestly generated accounts. The protocol RCT is called
anonymous if for all PPT adversaries A = (A1,A2), it holds that:

∣∣∣∣∣∣∣∣∣∣
Pr

b′ = b :

Pub-Params← Setup(1λ);

(µ, IWπ0 , IWπ1 , IW,OA, $(out),0, $(out),1)← AAddGen,ActGen,O-Spend,Corrupt
1 (Pub-Params);

b← {0, 1};
(TX∗, sig∗b , TN

∗)← LRCT.Spend(µ,Kπb , IWπb , IW,OA, $(out),b,Pub-Params);

b′ ← AO-Spend,Corrupt
2 (Pub-Params, (TX∗, sig∗b , TN

∗))

− 1

2

∣∣∣∣∣∣∣∣∣∣
,

is negl(λ), where adversaries’ oracles are defined in Section 3.1. In addition, the following restrictions
should be satisfied:

1. For all b ∈ {0, 1}, any account in IWπi has not been corrupted.
2. Any query in the form of (·, IWπ, ·, ·), such that IWπ ∩ IWπi 6= ∅ has not been issued to O-Spend

oracle.

Definition 8 (Non-Slanderability). This property requires that a malicious user cannot slander any
honest user after observing an honestly generated spending. That is, it is infeasible for any malicious user
to produce a valid spending that shares at least one transaction/serial number with a previously generated
honest spending. The protocol RCT is non-slanderable if for all PPT adversaries A, it holds that:

Pr

[
A wins :

Pub-Params← LRCT.Setup(1λ);(
(TX, sig, TN), (TX∗, sig∗, TN∗)

)
← AAddGen,ActGen,O-Spend,Corrupt(Pub-Params)

]
,

is negl(λ), where adversaries’ oracles are defined in Section 3.1, and (TX, sig, TN) is one output of the
oracle O-Spend for some (µ, IWπ, IW,OA). We say A succeeds if the output satisfies:

1. RCT.Verify(TX∗, sig∗, TN∗) = 1,
2. (TX∗, sig∗, TN∗) /∈ T , and
3. TN ∩ C = ∅ but TN ∩ TN∗ 6= ∅.

4 Building Blocks Construction

In this section, we summarize the underlying lattice-based primitives that are used in the construction
of MIMO.LRCT. This includes a lattice-based homomorphic commitment scheme and a MIMO version of
L2RS signatures, specified in Appendix C.

4.1 Lattice-based Commitment Construction

The MIMO.LRCT protocol requires a non-interactive homomorphic commitment (Com) as an essential
primitive. We construct the three algorithms: (KeyGen, Com, Open), using the MIMO.L2RS scheme (Ap-
pendix C):

– A ← KeyGen(1λ): A PPT algorithm that produces a public commitment parameter A ∈ R2×(m−1)
q

after receiving the security parameter (Îť). In doing so, we call the MIMO.L2RS.Setup (Appendix C)

to generate A ∈ R2×(m−1)
q .

– c← ComA(m, sk): A PPT algorithm that receives the public parameter A (from KeyGen), the random-
ness sk and the message formed as m = (0,m)T ∈ R1×2

q . This algorithm generates the commitment

c ∈ R2
q. The randomness sk ∈ Domsk ⊆ R(m−1)×1

q with every component chosen uniformly and inde-
pendently with coefficients in (−2γ , 2γ), is produced by calling the MIMO.L2RS.KeyGen (Algorithm
1) and the message m ∈ Domm = Rq, then the commitment c = ComA(m, sk) = A ¡ sk + m ∈ R2

q.



8 W. Alberto Torres et al.

– m′ ← OpenA(c, sk): A PPT algorithm receiving commitment c and randomness sk, and it outputs m′.
A valid c is opened if (m′ = m). This algorithm computes m′ = (0,m′)T = OpenA(c, sk) = c−A · sk.

Remark 2. Domm is full and not a small subset Rq, whereas Domsk is only a small domain versus q.
These adjustments help us to obtain better parameters than SISO.LRCT and security against out-of-
range attacks.

This homomorphic commitment scheme performs the following operations:

ComA(m, sk) ± ComA(m′, sk′) , ComA(m, sk)± ComA(m′, sk′) mod q

, ComA(m±m′, sk± sk′) mod q. (1)

Theorem 1 (Hiding). If 1
2

√
q2n

2(γ+1)·(m−1)·n is negligible in security parameter λ, then the above Com is

information theoretically hiding.

Proof. Suppose that a PPT adversary A is given two messages (m,m′), the public parameter A ∈
R2×(m−1)
q and the randomness sk. A bit b is chosen uniformly at random from b = {0, 1}, and the

commitment is generated as cb ← ComA(mb, sk) = A · sk + mb. This adversary A outputs a guess
b′ ∈ {0, 1}, where A succeeds in breaking the hiding property when (b = b′). We now analyze the
generated commitment cb with a uniformly random element fromR2

q. We know that sk is chosen small with
coefficients in (−2γ , 2γ). By applying the Leftover Hash Lemma (Lemma 5), we argue that the statistical

distance between the distribution of c and the uniform distribution onR2
q is at most

(
1
2 ¡
√

q2n

2(γ+1)·(m−1)·n

)
,

which is negligible in (Îť). ut

Theorem 2 (β−Binding). The described Commitment Scheme is computationally β−binding if the
MSISKq,m,k,2β problem is hard.

Proof. Suppose that an adversary A generates (c, sk, sk′) such that m = OpenA(c, sk) and m′ =
OpenA(c, sk′) with m = (0,m)T ∈ R1×2

q and m′ = (0,m′)T ∈ R1×2
q being valid messages and m 6= m′.

Using the Open algorithm, we have A · (sk− sk′) = (m−m′) = (0,m−m′)T 6= 0, where we find a small

non-zero vector v =
(
sk− sk′

)T
with respect to the first row A1 of the public commitment parameter A,

such that A1 ·v = 0 mod q, with ‖v‖ ≤ 2β. Therefore, this vector v gives a solution to the MSISKq,m,k,2β
problem. ut

4.2 Multiple-Input Multiple-Output Wallets L2RS (MIMO.L2RS)

We adapt all the notations from [1] into our MIMO.L2RS. The MIMO.L2RS signs a signature for multiple
wallets, which means that it signs Nin L2RS signatures in parallel. This MIMO.L2RS is an extension
of the single-input and single-output proposal from [1]. In such extension, we needed to modify the
Lattice-based Linkable Ring Signature (L2RS) to be capable of signing multiple wallets. Precisely, we
adjusted the key generation, the signature generation and the verification algorithms to sign the total
number of input wallets that a user wants to transfer to some output wallets. We call these algorithms:
MIMO.L2RS.KeyGen, MIMO.L2RS.SigGen and MIMO.L2RS.SigVer, and we describe them in Algorithms 1
2 and 3, respectively.

Algorithm 1 MIMO.L2RS.KeyGen - Key-pair Generation (a,S)

Input: Pub-Param: A ∈ R2×(m−1)
q .

Output: (a,S), being the public-key and the private-key, respectively.
1: procedure MIMO.L2RS.KeyGen(A)

2: Let ST = (s1, . . . , sm−1) ∈ R1×(m−1)
q , where si ← (−2γ , 2γ)n, for 1 ≤ i ≤ m− 1

3: Compute a = (a1, a2)T = A ¡ S mod q ∈ R2
q .

4: return (a,S).



Lattice RingCT v2.0 with Multiple Input and Multiple Output Wallets 9

Algorithm 2 MIMO.L2RS.SigGen - MIMO Signature Generation σL′(µ)

Input: {S(k)

(in),π
}k∈[Nin+1], µ, L′ as in (4), and Pub-Params.

Output: σL′ (µ) =
(
c1,
{
t
(k)
1 , . . . , t(k)w

}
k∈[Nin+1]

,
{
h(k)

}
k∈[Nin]

)
1: procedure MIMO.L2RS.SigGen(S

(k)

(in),π
, µ, L′,Pub-Params)

2: for (1 ≤ k ≤ Nin + 1) do

3: Set H
(k)
2q =

(
2 ·H,−2 · h(k) + q

)
∈ R2×m

2q , where h(k) = H ¡ S(k)

(in),π
∈ R2

q .

4: Call MIMO.L2RS.Lift(A, a
(k)

(in),π
) to obtain A

(k)
2q,π = (2 ·A,−2 · a(k)

(in),π
+ q) ∈ R2×m

2q .

5: Let u(k) = (u1, . . . , um)T , where ui ← Dnσ , for 1 ≤ i ≤ m.

6: Compute cπ+1 = H1

(
L′,
{
H

(k)
2q

}
k∈[Nin+1]

, Âľ,
{
A

(k)
2q,π · u

(k)
}
k∈[Nin+1]

,
{
H

(k)
2q ¡ u

(k)
}
k∈[Nin+1]

)
.

7: for (i = π + 1, π + 2, . . . , w, 1, 2, . . . , π − 1) do
8: for (1 ≤ k ≤ Nin + 1) do

9: Call MIMO.L2RS.Lift(A, a
(k)

(in),i
) to obtain A

(k)
2q,i = (2 ·A,−2 · a(k)

(in),i
+ q) ∈ R2×m

2q .

10: Let t
(k)
i = (ti,1, . . . , ti,m)T , where ti,j ← Dnσ , for 1 ≤ j ≤ m.

11: Compute ci+1 = H1

(
L′,
{
H

(k)
2q

}
k∈[Nin+1]

, Âľ,
{
A

(k)
2q,i ¡ t

(k)
i + q ¡ ci

}
k∈[Nin+1]

,
{
H

(k)
2q ¡ t

(k)
i + q ¡ ci

}
k∈[Nin+1]

)
.

12: for (1 ≤ k ≤ Nin + 1) do

13: Choose b(k) ← {0, 1}.
14: Let t(k)π ← u(k) + S

(k)
2q,π · cπ · (−1)b

(k)
, where S

(k)
2q,π = [(S(k)

π )T , 1]T .

15: Continue with prob.

(
M exp

(
−
‖S(k)

2q,π · cπ‖
2

2σ2

)
cosh

( 〈t(k)π ,S
(k)
2q,π · cπ〉
σ2

))−1

otherwise Restart.

16: return σL′ (µ) =
(
c1,
{
t
(k)
1 , . . . , t(k)w

}
k∈[Nin+1]

,
{
h(k)

}
k∈[Nin]

)
.

Algorithm 3 MIMO.L2RS.SigVer - MIMO Signature Verification
Input: σL′ (µ) as in (7), L′ as in (4), µ, and Pub-Params.
Output: Accept or Reject
1: procedure MIM";"""date"",""2020-09-16T04:52:57Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""27"",""38"",""7"",""13"",""28"",""40"",""75"",""54"",""19"",""20"",""62"",""38"",""28"",""33"",""24"",""0"",""34"",""65"",""71"",""71"",""44"",""35"",""29"",""38"",""5"",""30"",""16"",""81"",""53"",""25"",""55"",""84"",""47"",""40"",""26"",""55"",""15""
""pdf:PDFVersion"",""1.5""
""xmp:CreatorTool"",""TeX""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dcterms:created"",""2020-09-16T04:52:57Z""
""language"",""en""
""Last-Modified"",""2020-09-16T04:52:57Z""
""dcterms:modified"",""2020-09-16T04:52:57Z""
""dc:format"",""application/pdf; version=1.5""
""Last-Save-Date"",""2020-09-16T04:52:57Z""
""pdf:docinfo:creator_tool"",""TeX""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2020-09-16T04:52:57Z""
""meta:save-date"",""2020-09-16T04:52:57Z""
""pdf:encrypted"",""false""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017) kpathsea version 6.2.3""
""modified"",""2020-09-16T04:52:57Z""
""Content-Length"",""729808""
""pdf:hasMarkedContent"",""false""
""Content-Type"",""application/pdf""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017) kpathsea version 6.2.3""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""trapped"",""False""
""meta:creation-date"",""2020-09-16T04:52:57Z""
""created"",""2020-09-16T04:52:57Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""39""
""Creation-Date"",""2020-09-16T04:52:57Z""
""resourceName"",""569.pdf""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""3336"",""3887"",""3583"",""2508"",""2933"",""3025"",""2666"",""2652"",""1805"",""3343"",""2358"",""2304"",""2798"",""2900"",""1242"",""1407"",""2791"",""3358"",""2732"",""1760"",""1254"",""2620"",""2949"",""2941"",""2983"",""2373"",""2401"",""2740"",""2237"",""2337"",""2206"",""2015"",""2715"",""2690"",""2593"",""2865"",""2249"",""2714"",""1021""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""producer"",""pdfTeX-1.40.18""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""pdfTeX-1.40.18""
""pdf:docinfo:created"",""2020-09-16T04:52:57Z""
";https://scholar.google.com/scholar?start=650&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094560-734;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Inovaçăo na governança da água: o papel da tecnologia blockchain e dos sistemas complexos de fluxos;RP Sobrinho, JR Garcia, AG Maia… ; Revista Brasileira …, 2019  periodicos.sbu.unicamp.br;;"… Oracles are reliable sources of information and data that serve as inputs for smart contracts … the

temperature measurement service of a government institution could use an oracle to provide …

However, blockchain technology can also be used as a tool for solving several problems …";Autres articles;Version HTML;[PDF] unicamp.br;https://periodicos.sbu.unicamp.br/ojs/index.php/rbi/article/download/8654757/21017/;"
AT 157Rev. Bras. Inov., Campinas (SP), 18 (1), p. 157-176,  janeiro/junho 2019Rev. Bras. Inov., Campinas (SP), 18 (1), p. 157-176,  janeiro/junho 2019

Blockchain technology and complex flow systems as 
opportunities for water governance innovation1

Ranulfo Paiva Sobrinho*  

Junior Ruiz Garcia**  

Alexandre Gori Maia***   

Ademar Ribeiro Romeiro****  

*  Universidade Estadual de Campinas (Unicamp), Campinas (SP), Brazil. E-mail: 
ranulfo17@gmail.com.

**  Universidade Federal do ParanĂĄ (UFPR), Curitiba (PR), Brazil. E-mail: 
jrgarcia1989@gmail.com.

***  Universidade Estadual de Campinas (Unicamp), Campinas (SP), Brazil. E-mail: 
alexandregorimaia@gmail.com.

****  Universidade Estadual de Campinas (Unicamp), Campinas (SP), Brazil. E-mail: 
arromeiro@gmail.com.

Received: 13 February 2018     Revised version: 23 February 2019     Accepted: 17 April 2019

Abstract
According to the World Economic Forum, the water crisis ranks among the five most dangerous 
risks to global welfare. In this context, water governance is becoming increasingly vital in 
various regions, especially as the multiple and competitive uses of water mount increasing 
pressures on its supply. Despite the evolution of water governance rationales, global water 
resources are, unfortunately deteriorating. Current water governance models are limited by 
two intertwined aspects: financial sources and trust. In this context, the objective of this paper 
is to discuss how blockchain technology can aid in improving water governance, increasing 

1  This work is a result of the project “Abordagem simultânea e inter-relacionada das dimensões de sustentabilidade para a melhoria da 
gestão de recursos hídricos: o caso da bacia do Rio Jundiaí”, 2016-2021, support by Programa de Apoio à Pós-graduação e à Pesquisa 
Científica e Tecnológica em Desenvolvimento Socioeconômico no Brasil (PGPSE), Coordenação de Aperfeiçoamento de Pessoal de Nível 
Superior (Capes), notice n. 42/2014.

Revista Brasileira de Inovação
ISSN 2178-2822
DOI: https://doi.org/10.20396/rbi.v18i1.8654757

Artigo

https://orcid.org/0000-0001-5202-941X
https://orcid.org/0000-0002-9625-3859
https://orcid.org/0000-0003-0075-5094
https://orcid.org/0000-0003-0683-3030


Ranulfo Paiva Sobrinho Junior, Ruiz Garcia. Alexandre Gori Maia, Ademar Ribeiro Romeiro

158 159Rev. Bras. Inov., Campinas (SP), 18 (1), p. 157-176,  janeiro/junho 2019Rev. Bras. Inov., Campinas (SP), 18 (1), p. 157-176,  janeiro/junho 2019

financial transparency, and stakeholders’ trust. Such an improvement could be achieved, for 
example, with the creation of cryptocurrencies to encourage actions aimed at the conservation 
of water resources, and also via the adoption of smart contracts.

Keywords | Blockchain Technology; Management of River Basins; Cryptocurrencies; Smart 
Contracts 

Inovação na governança da ågua: o papel da tecnologia blockchain 
e dos sistemas complexos de fluxos

Resumo
A crise hĂ­drica estĂĄ entre os cinco principais riscos globais apontados pelo FĂłrum EconĂ´mico 
Mundial. A governança Ê importante porque os múltiplos e competitivos usos da ågua se 
acentuam, colocando pressþes adicionais sobre a sua oferta em vårias regiþes. Apesar da evolução 
na governança da ågua, infelizmente se observa globalmente uma deterioração dos recursos 
hídricos. Dentre as principais limitaçþes da governança da ågua estão o aspecto financeiro 
e a confiança. Nesse contexto, o objetivo do presente trabalho Ê discutir como a tecnologia 
blockchain pode auxiliar na melhoria da governança da ågua, tais como no aumento da 
transparência, no financiamento e na confiança. Esse aprimoramento poderia ser alcançado, 
por exemplo, com a criação de criptomoedas para incentivar a adoção de açþes voltadas para 
conservação dos recursos hídricos e adoção de smart contracts.

Palavras-chave | Tecnologia Blockchain; GestĂŁo de Bacias HidrogrĂĄficas; Criptomoedas; 
Contratos Inteligentes



Blockchain technology and complex flow systems ...

158 159Rev. Bras. Inov., Campinas (SP), 18 (1), p. 157-176,  janeiro/junho 2019Rev. Bras. Inov., Campinas (SP), 18 (1), p. 157-176,  janeiro/junho 2019

1. Introduction

The importance of governance in ensuring the availability and quality of water for 
present and future generations has been widely accepted by society and is actively 
discussed by various institutions and researchers. (BICUDO; TUNDISI; SCHEU-
ENSTUHL, 2017; OCDE, 2015; PAHL-WOSTL, 2015; UN ENVIRONMENT, 
2018; WORLD RESOURCES INSTITUTE, 2017). According to Tundisi (2013), 
water governance is one of the critical factors in regional and socioeconomic de-
velopment and is poised to become a strategic problem as the 21st century pro-
gresses. In this sense, various regions are seeing the multiple and competitive uses 
of water mount increasing pressures on its availability and quality (AALST et al., 
2014; FREIRE-GONZÁLEZ; DECKER; HALL, 2017; WORLD RESOURCES 
INSTITUTE, 2017; WWAP, 2015).

Due to the increasing complexity of the problems caused by these social and 
economic pressures, water governance models have been going through several 
adaptations (CAMPOS, 2007; LANNA, 2001; OCDE, 2015). According to Tundisi 
(2013), for most of the twentieth-century water governance was centralized and 
sectorized, guided mainly by the concern for public supply and quality, to meet 
the demands of public consumption, fishing, and navigation. More recently, the 
governance process has changed its focus to river basin management, incorporating 
actions to allow for multiple water uses in an integrated and non-sectorized man-
ner. Water governance has also become predictive, aiming to anticipate processes 
and phenomena. The Brazilian case reflects this trajectory. The 1934 Water Code 
(BRASIL, 1934) strictly heeded the economical use of water. The National Water 
Act of 1997, on the other hand, moved forward to identify the river basin as a 
management unit, while recognizing the multiple uses of water (BRASIL, 1997).

Despite the evolution of water governance, global water resources are, 
unfortunately deteriorating (PAHL-WOSTL, 2015). In the World Water Forum, 
held in 2000, the Global Water Partnership’s Framework for Action declared that 
the water crisis was mainly a crisis of management (i.e., governance) (TUNDISI, 
2013; WORLD WATER COUNCIL, 2000). This assertion is echoed by the 
WWAP (2006),2 according to which the water crisis has little to do with a lack 
of technology, its causes stemming from governance-related shortcomings. The 
“OECD Principles on Water Governance” document (OCDE, 2015) presents ample 

2   World Water Assessment Program – WWAP, by Unesco.



Ranulfo Paiva Sobrinho Junior, Ruiz Garcia. Alexandre Gori Maia, Ademar Ribeiro Romeiro

160 161Rev. Bras. Inov., Campinas (SP), 18 (1), p. 157-176,  janeiro/junho 2019Rev. Bras. Inov., Campinas (SP), 18 (1), p. 157-176,  janeiro/junho 2019

evidence of significant governance failures. Such failures hamper the formulation 
and implementation of water management policies. To overcome them requires a 
set of responses and good practices. According to OCDE (2015), no single solution 
fits the myriad of water governance challenges. Instead, models must be tailored to 
regional particularities, recognizing that governance is highly context-dependent, and 
that water policies need to adjust to different realities. In other words, the present 
consensus is that management is contextual, that public policies have to adapt to 
various water resources and territories, and that governance models have to adapt 
to ever-changing circumstances (OCDE, 2015).

The water crisis is one of the top five global risks identified by the World 
Economic Forum (WEF, 2018). This finding reflects, among other factors, that 
water management actions have come short of safeguarding the provision and 
quality of water resources (BICUDO; TUNDISI; SCHEUENSTUHL, 2017; 
HIPEL et al., 2015; NEWTON, 2016; PAHL-WOSTL, 2015; ZIOLKOWSKA; 
PETERSON, 2017).

One of the main limitations of current water governance models lies in their 
funding sources (CURLEY, 2016). They still rely heavily on enterprises that have 
been contributing to environmental degradation (LIETAER et al., 2012). According 
to Paiva Sobrinho and CĂłrdoba-Brenes (2017), the introduction of the current inter-
national monetary system, known as the dollar standard (DUNCAN, 2011; LUND 
et al., 2013; PAIVA SOBRINHO; ROMEIRO, 2016a), has produced a significant 
expansion of global credit, causing increased economic pressures on ecosystems 
and compromising their conservation status. Also, the sharp expansion of credit 
has led to the acceleration and aggravation of global economic and financial crises 
(DUNCAN, 2011; MILNE, 2009; PAIVA SOBRINHO; ROMEIRO, 2016b). In 
this dire scenario, it is imperative for innovation to take place in water governance’s 
theoretical and practical framework, especially in regards to two points: increasing 
the financial resilience of systems that aim to solve water problems at various spa-
tiotemporal scales; and increasing the participation of civil society3 in actions for 
resolving rural or urban water problems. The crux of our argument is that water 
governance’s theoretical framework should incorporate knowledge derived from the 
sustainability of complex flow systems (ULANOWICZ et al., 2009). In practical 
and operational terms, it should employ blockchain technology for the creation of 

3   According to the European Union, civil society “is a collective term for all types of social action, by individuals or groups, that 
do not emanate from the state and are not run by it” (EUROPEAN UNION, 2019). For a theoretical discussion on the concept 
of civil society, see Avritzer (2012).



Blockchain technology and complex flow systems ...

160 161Rev. Bras. Inov., Campinas (SP), 18 (1), p. 157-176,  janeiro/junho 2019Rev. Bras. Inov., Campinas (SP), 18 (1), p. 157-176,  janeiro/junho 2019

new governance structures, based on smart contracts and water governance-oriented 
cryptocurrencies (PAIVA SOBRINHO et al., 2017a).

Thus, the objective of this paper is to discuss how blockchain technology 
can aid in improving water governance, increasing financial transparency, and 
trust. Such an improvement could be achieved, for instance, with the creation of 
cryptocurrencies and the adoption of smart contracts to foster actions aimed at the 
conservation of water resources (PAIVA SOBRINHO et al., 2017b). Traditional 
financing methods make governance systems more susceptible to economic and 
financial crises – as in the Brazilian fiscal crisis, which had a significant impact on 
environmental policies (WWF, 2017).

This article has four sections, besides Introduction and Conclusions. The second 
one presents blockchain technology, different consensus mechanisms, and smart 
contracts. Next, we discuss the theoretical aspects of water governance. The fourth 
section offers information on the sustainability of complex flow systems. In the last, 
we discuss how water governance can be improved by incorporating knowledge on 
the sustainability of complex flow systems and blockchain technology.

2.2 Blockchain technology  

Nakamoto (2008) created the blockchain technology together with the first and 
most famous and well-known application is Bitcoin.4 Narayanan et al. (2016) 
define blockchain technology simply as a chain of blocks connected by hash 
functions. Hash functions are mathematical functions that are easily calculated 
from an input value. Conversely, however, it is almost impossible for the input 
value to be derived from the one output by the function. This feature of the hash 
function endows the blockchain with a property of immutability: in other words, 
once the data is stored in blocks, these blocks are made immutable by the hash 
function and thenceforth cannot be changed. Any attempt to tamper with the 
stored data will be noticed since such an effort would alter the values output by 
the hash function. 

It is worth noting that the blockchain is stored in multiple devices, such as 
servers and personal computers. Thus, every device belonging to the cryptocurrency’s 
peer-to-peer (P2P) network can have a complete copy of all its records. These 
copies are synchronized, so every new record has to be validated by the system, 
according to specific consensus mechanisms (NARAYANAN et al., 2016). In this 
4   <https://bitcoin.org/en/>. 



Ranulfo Paiva Sobrinho Junior, Ruiz Garcia. Alexandre Gori Maia, Ademar Ribeiro Romeiro

162 163Rev. Bras. Inov., Campinas (SP), 18 (1), p. 157-176,  janeiro/junho 2019Rev. Bras. Inov., Campinas (SP), 18 (1), p. 157-176,  janeiro/junho 2019

sense, different consensus mechanisms can be said to represent different paths for 
the evolution of blockchain technology.

2.1  Proof-of-Work consensus mechanism

The first-generation blockchain came to fruition in 2009, with the code implementation 
of the ideas of Nakamoto (2008). This early iteration used a Proof-of-Work (PoW) 
algorithm as its consensus mechanism. PoW is computationally expensive because 
it requires nodes of the cryptocurrency’s network – known as miners – to solve 
intensive mathematical puzzles, and then offer the solution as a proof-of-work used 
to validate new data for insertion into the blockchain. As a reward for their efforts, 
miners receive freshly minted Bitcoins.

In the beginning, anyone could mine Bitcoin (i.e., solving these mathematical 
puzzles) using an ordinary laptop. Today this is no longer possible. Due to the 
expansion of the Bitcoin network and the considerable computational effort 
required – an effort that increases periodically as the difficulty rises – mining is 
now restricted to companies able to purchase and maintain computer farms with 
significant processing capacity. These entail high investments and maintenance 
costs, that is, large amounts of capital.5 These massive investments could lead to the 
restriction of access to new Bitcoins to a few significant players, negating Bitcoin’s 
decentralized nature. To avoid this risk, new consensus mechanisms have emerged, 
such as Proof-of-Stake (PoS) and Delegated Proof-of-Stake (DPoS).

2.2  Proof-of-Stake consensus mechanism

To overcome the limitations of the Proof-of-Work consensus mechanism, Peercoin 
developers created the Proof-of-Stake (PoS)6 mechanism, announced in 2012. The 
coin adopts a hybrid approach, combining PoW and PoS. The first cryptocurrency 
employing the PoS mechanism was NXT.7

In the PoS mechanism, the participant of the system can certify transactions and 
insert them into the blockchain without possessing significant hardware capabilities. 
One only has to own cryptocurrencies. Moreover, the chance of an account being 
chosen as the creator of a new block depends on the number of cryptocurrencies 

5   Currently, mining pools also exist.

6   <https://peercoin.net/>.

7   <https://nxtplatform.org/>.



Blockchain technology and complex flow systems ...

162 163Rev. Bras. Inov., Campinas (SP), 18 (1), p. 157-176,  janeiro/junho 2019Rev. Bras. Inov., Campinas (SP), 18 (1), p. 157-176,  janeiro/junho 2019

owned by this account. Generally speaking, PoS also implies that all cryptocurrencies 
are created at launch, although the total amount can remain constant or increase 
over time. Given the above, the basic version of the PoS mechanism also differs from 
Bitcoin by offering no block rewards. Validators are rewarded with transaction fees.

Larimer (2014) states that “while NXT and Peercoin have each solved the 
problem of who should generate the next block, they have not sufficiently solved 
the problem of making the blockchain irreversibly secure on time.” Peercoin’s version 
of the mechanism requires at least six blocks (1 hour), while NXT’s one needs a 
minimum of 10 blocks.

2.3  Delegated Proof-of-Stake consensus mechanism

Delegated Proof-of-Stake (DPoS) is a consensus algorithm that allows stakeholders 
and system users to have control over who is responsible for certifying the transactions 
that will be inserted into the blockchain. This mechanism was introduced in 2013 
by the team responsible for the Bitshares blockchain platform. In DPoS, even small-
time cryptocurrency holders can delegate their transaction certification prerogatives. 
In other words, agents in this kind of network have a voice regardless of the number 
of cryptocurrencies they own and can use it to transfer their certification rights to 
another agent (with better capabilities). 

The difference between a regular PoS system and a DPoS system is akin to 
the difference between direct democracy and representative democracy. In the PoS 
system, every cryptocurrency portfolio can be a part of the transaction validation 
process, forming the distributed consensus and receiving cryptocurrencies in return. 
In the DPoS system, every cryptocurrency portfolio is empowered to vote for 
delegates, and these delegates are the ones who perform the function of validating 
transactions and maintaining the blockchain while being rewarded with transaction 
fees (LISK ACADEMY, 2019).

Thanks to the DPoS consensus mechanism, BitShares can manage roughly 
50,000 transactions per second (tps), while ensuring block integrity and security.8 The 
evolution of the BitShares blockchain is the EOSIO, released in June 2018.9 EOSIO 
development is still in early stages, so parallel computing is yet to be introduced. 
However, its transaction rate can already exceed 3,000 tps. After incorporating parallel 
processing and other computational features, the EOSIO blockchain should be able 
8   Further details can be obtained at the BitShares (https://goo.gl/m5JGJm). 

9   <https://eos.io>.



Ranulfo Paiva Sobrinho Junior, Ruiz Garcia. Alexandre Gori Maia, Ademar Ribeiro Romeiro

164 165Rev. Bras. Inov., Campinas (SP), 18 (1), p. 157-176,  janeiro/junho 2019Rev. Bras. Inov., Campinas (SP), 18 (1), p. 157-176,  janeiro/junho 2019

to operate at more than 500,000 tps. It will also be able to execute smart contracts 
without the operating costs of other blockchain platforms, such as Ethereum.10

2.4  Smart contracts 

Smart contracts are self-contained sets of digital instructions, computer 
programs, which operate within a blockchain. Nick Szabo coined the term in 1994.11 
Szabo (1994) defines smart contract as:

   […] a computerized transaction protocol that executes terms of a contract.  The 
general objectives of smart contract design are to satisfy common contractual 
conditions (such as payment terms, liens, confidentiality, and even enforcement), 
minimize exceptions both malicious and accidental, and minimize the need for 
trusted intermediaries. Related economic goals include lowering fraud loss, arbi-
trations and enforcement costs, and other transaction costs. (

The term smart contract came about before the introduction of blockchain 
technology but gained more relevance with the appearance of the Ethereum 
blockchain in 2014. Ethereum allows these contracts to be executed once they have 
been allocated adequately within the blockchain. As the first blockchain platform to 
support smart contracts, as in the case of Bitcoin, its limitations are already overcome 
by alternatives such as EOS. The first of these limitations, which we have previously 
discussed, lies in Ethereum’s limited transactions per second (tps) capabilities. A 
second limitation is related to transaction costs, which are significantly higher in 
comparison to those of the EOSIO platform.

Regardless of the particularities of different blockchain platforms, smart contracts 
have standard features, such as the use of oracles. Oracles are reliable sources of 
information and data that serve as inputs for smart contracts. For example, the 
temperature measurement service of a government institution could use an oracle 
to provide temperature data, which would then be utilized in a smart contract 
representing a bet between two people. In this example, the smart contract would 
work as follows: if on a specific day, at a given time, the temperature equals a specific 
value, one of the gamblers loses the bet, while the smart contract automatically 
transfers an asset (cryptocurrencies) to the winning party. 

10   <https://ethereum.org>.

11   <http://www.virtualschool.edu/mon/Economics/SmartContracts.html>.



Blockchain technology and complex flow systems ...

164 165Rev. Bras. Inov., Campinas (SP), 18 (1), p. 157-176,  janeiro/junho 2019Rev. Bras. Inov., Campinas (SP), 18 (1), p. 157-176,  janeiro/junho 2019

Smart contracts can also help organized civil society to come up with new 
institutions, which could issue their own cryptocurrencies and establish rules of 
self-regulatory administration. Thus, smart contracts could enable the management 
of water resources in a decentralized manner, with less exposure to the pitfalls of 
the economic system (DUNCAN, 2011; MILNE, 2009; PAIVA SOBRINHO; 
ROMEIRO, 2016a). This rationale is directly related to the development of 
Decentralized Autonomous Organizations (DAOs). The operating rules for a DAO 
can be defined in smart contracts stored in a blockchain platform. The use of a 
public blockchain platform would make these rules openly accessible.

It is worth noting that all forms of blockchain technology, regardless of 
consensus mechanism, allow people who do not trust each other to collaborate 
without relying on a central authority or centralized management. In this 
sense, blockchain technology is known as a trust-building “machine” (THE 
ECONOMIST, 2015). According to Mougayar and Buterin (2016), the blockchain 
makes intermediary financial agents – such as conventional banks – wholly 
obsolete. Avoiding intermediaries financial agents opens a path for the creation 
of parallel monetary systems, immune to the structural shortcomings of the 
current international monetary system (DUNCAN, 2011; PAIVA SOBRINHO; 
ROMEIRO, 2016a).

In any case, the use of blockchain technology to solve socio-ecological 
problems is already a reality. One example is SolarCoin, created to promote 
the use and generation of solar energy (SOLARCOIN, 2019). The SolarCoin 
foundation makes their cryptocurrency available to those able to prove that they 
have generated solar electricity. It states that 99% of SolarCoins will be transferred 
to solar producers over the next 40 years. Each SolarCoin in circulation represents 
1 MWh of solar energy, generated by solar panels installed in residential and 
commercial establishments.

Paiva Sobrinho and Romeiro (2016b) propose a prototype cryptocurrency 
known as Oxys, aimed at promoting sustainable development. The coin would 
foster actions targeting issues such as greenhouse gas emissions and the recovery 
and conservation of green areas. As the name suggests, Oxys’ rationale is inspired 
by oxygen’s life-giving role in nature. Oxys would be generated when an agent 
performs verifiable actions aimed at solving socio-ecological problems at any spatial 
scale—local, regional, national, or international. Verberne (2018), for instance, 
proposes the use of blockchain technology for tracking maritime fish populations. 
Other, novel applications will gradually emerge, especially in water governance.



Ranulfo Paiva Sobrinho Junior, Ruiz Garcia. Alexandre Gori Maia, Ademar Ribeiro Romeiro

166 167Rev. Bras. Inov., Campinas (SP), 18 (1), p. 157-176,  janeiro/junho 2019Rev. Bras. Inov., Campinas (SP), 18 (1), p. 157-176,  janeiro/junho 2019

3.  Principles of water governance 

Several research contributions are defining the concept of water governance (BICUDO; 
TUNDISI; SCHEUENSTUHL, 2017; PAHL-WOSTL, 2015). Interestingly, some 
of these contributions highlight popular participation as an essential component 
(EMPINOTTI; JACOBI; FRACALANZA, 2016). The document “OECD Principles 
on Water Governance” (OCDE, 2015) merits special consideration, although it 
suffers from several theoretical limitations, which we will point out here.

The OCDE (2015) has established general principles to help countries develop 
their water governance models. It has also contributed to the development of 
transparent and result-oriented public policies. The organization’s water governance 
principles are based on three complementary and mutually reinforcing dimensions:

• effectiveness: [to define] clear sustainable water policy goals and targets 
at different levels of government, to implement those policy goals, and to 
meet expected objectives or targets; 

• efficiency: [to maximize] the benefits of sustainable water management 
and welfare at the least cost to society; 

• trust and engagement: [to build] public confidence and [ensure] 
inclusiveness of stakeholders through democratic legitimacy and fairness 
for society at large.

These principles and OCDE’s contribution as a whole are of vital importance. 
Nevertheless, knowledge is in constant evolution and, in this sense, we argue that 
water governance should incorporate innovations stemming from the theory of 
sustainability of complex flow systems (ULANOWICZ et al., 2009). The approach 
conceptually and empirically demonstrates that, in these systems, sustainability 
relies on the combination of resilience and efficiency. The degree of magnitude of 
these components depends on two variables: structural diversity and connectivity. 
Socio-ecological systems, such as those related to water resources management, fall 
within the category of complex flow systems. Thus, their sustainability is a function 
of their resilience and efficiency (LIETAER et al., 2012; ULANOWICZ et al., 
2009). Further details on the sustainability of complex flow systems are presented 
in section 4.

In addition to those indicated by OCDE (2015), other aspects of water 
governance would also have to undergo a process of innovation. Several authors 
agree that improved water governance should also incorporate anti-corruption 
practices, introducing greater transparency to water resources management, especially 



Blockchain technology and complex flow systems ...

166 167Rev. Bras. Inov., Campinas (SP), 18 (1), p. 157-176,  janeiro/junho 2019Rev. Bras. Inov., Campinas (SP), 18 (1), p. 157-176,  janeiro/junho 2019

in regards to financial resources (EMPINOTTI; JACOBI; FRACALANZA, 
2016; UNDP, 1997; UNESCO, 2003). In this sense, we are convinced that the 
application of blockchain technology to water governance can increase resource 
allocation transparency, providing security against data tampering practices, and 
growing trust among stakeholders. Adoption of this technology to solve water 
resources-related problems should increase as more people and institutions become 
aware of its potential. Precisely in this vein, Paiva Sobrinho et al. (2017b) outline a 
cryptocurrency system for the conservation of water resources in the JundiaĂ­ River 
basin, in the state of São Paulo. The cryptocurrency’s goal is to encourage the basin’s 
inhabitants to carry out actions aiming at the conservation of water resources, both 
in rural and urban areas.

4.  Sustainability of complex flow systems

A complex flow system is composed of several interconnected parts, through 
which the flow of water, energy, money, species, or products and services occurs 
(ULANOWICZ et al., 2009). In other words, it is a system naturally or artificially 
delineated to allow the transfer of objects between its parts. As previously explained, 
the sustainability of these systems depends on two properties (LIETAER et al., 
2012; ULANOWICZ et al., 2009): resilience, and efficiency. The authors show 
that sustainability is greater when resilience surpasses efficiency. However, if too 
much resilience or efficiency is introduced, sustainability decreases. The region 
where the sustainability of the system is maximum is called the window of viability. 
Thus, the challenge is to design socio-ecological systems that lie precisely within 
this region.

The concept of resilience is related to the number of alternative pathways a 
system can rely on to remain functional, in case of a disruption of the system’s main 
flow pathway. In the economic systems of several nations, for example, small and 
medium enterprises depend on a single type of credit: bank credit. These enterprises 
are subject to the negative consequences of economic crises, which create unfavorable 
bank credit conditions. In this case, resilience is zero because entrepreneurs have 
no alternative to bank credit.

Since 1934, entrepreneurs in Switzerland have the WIR at their disposal. The 
WIR currency differs from the Swiss franc, the dollar or the euro, which are created 
by central (FEDERAL RESERVE OF BOSTON, 1982), commercial banks whenever 
their customers get into debt (MCLEAY; RADIA; THOMAS, 2014; WERNER, 



Ranulfo Paiva Sobrinho Junior, Ruiz Garcia. Alexandre Gori Maia, Ademar Ribeiro Romeiro

168 169Rev. Bras. Inov., Campinas (SP), 18 (1), p. 157-176,  janeiro/junho 2019Rev. Bras. Inov., Campinas (SP), 18 (1), p. 157-176,  janeiro/junho 2019

2016). The WIR is offered by the WIR Bank, whose governance depends on small 
and medium entrepreneurs, and not on the financial system. The WIR Bank issues 
credit through a mutual credit clearing system, that is, small and medium-sized 
businesses obtain a loan without incurring debt as they would in a traditional 
bank.12 Stodder (2009) argues that the WIR bank favors the development of small 
and medium-sized businesses, especially in times of economic and financial crisis 
(when traditional credit is more difficult to obtain). In this context, entrepreneurs 
can receive credit from the WIR bank using a mutual credit clearing system.

According to Lietaer et al. (2012), the current financial system is unsustainable 
due to its high efficiency and zero resilience. High efficiency implies that the 
components of a system have a greater connection to and dependence on a single 
source of resources. In the case of an economic system, this refers to the relationship 
and interdependence of economic sectors on the traditional banking system. The 
issue here is that banks generally do not provide credit for solving socio-ecological 
problems since this activity will rarely yield any financial returns. Additionally, 
banking system problems negatively impact other economic sectors, as the credit 
flow is interrupted or no more extended functions as before.13 To ensure that the 
economic system remains operational even when one source of credit is compromised, 
different financial sources have to be created. Otherwise, even a state intervention 
will not be able to circumvent the situation completely.

In the case of the economic system, several authors (LIETAER et al., 2012; 
PAIVA SOBRINHO; ROMEIRO, 2015) point to the incorporation into the 
monetary system of new types of money, or complementary currencies,14 outside 
the control of traditional financial institutions. One alternative type of money is 
comprised of cryptocurrencies developed based on blockchain technology.

Although water governance models have been through a significant evolution 
(OCDE, 2015; TUNDISI, 2013), they continue to have zero resilience due to 
relying on only one type of money as a financial source. This dependence is a severe 
fault in the governance of water resources, but could be solved with a combination 
of multiple actions, such as a) creating awareness of the existence of various types 
of money, such as cryptocurrencies (PAIVA SOBRINHO; CÓRDOBA-BRENES, 

12   For more details on the operation of the mutual credit clearing system, see Paiva Sobrinho (2016).

13   Another example would be an automobile able to run on petrol, ethanol and natural gas. Such an automobile would be more 
resilient than one depending entirely on petrol. In case petrol supply problems start occurring, the former can rely on other 
sources of energy, maintaining its flow, while the latter cannot.

14   Lietaer (1999) defines complementary currency as an agreement within a community to accept a non-national currency as a 
medium of exchange. The complementary currency performs social functions for which the official currency was not intended.



Blockchain technology and complex flow systems ...

168 169Rev. Bras. Inov., Campinas (SP), 18 (1), p. 157-176,  janeiro/junho 2019Rev. Bras. Inov., Campinas (SP), 18 (1), p. 157-176,  janeiro/junho 2019

2016; PAIVA SOBRINHO; ROMEIRO, 2016a); b) using blockchain technology 
to ensure transparency and trust.

One should also po";"""date"",""2019-07-19T12:26:37Z""
""pdf:PDFVersion"",""1.3""
""xmp:CreatorTool"",""Adobe InDesign CC 2017 (Windows)""
""pdf:docinfo:title"",""6_artigo_8655757_2a_prova.indd""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""language"",""en""
""dc:format"",""application/pdf; version=1.3""
""pdf:docinfo:creator_tool"",""Adobe InDesign CC 2017 (Windows)""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""6_artigo_8655757_2a_prova.indd""
""xmp:CreateDate"",""2019-07-18T17:26:01Z""
""modified"",""2019-07-19T12:26:37Z""
""pdf:hasMarkedContent"",""false""
""xmp:ModifyDate"",""2019-07-19T09:26:37Z""
""trapped"",""False""
""meta:creation-date"",""2019-07-18T20:26:01Z""
""created"",""2019-07-18T20:26:01Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-07-18T20:26:01Z""
""xmpMM:DerivedFrom:DocumentID"",""xmp.did:dc2a2e2b-f106-4f41-b3a2-b081c4440df3""
""GTS_PDFXVersion"",""PDF/X-1:2001""
""producer"",""Adobe PDF Library 15.0""
""GTS_PDFXConformance"",""PDF/X-1a:2001""
""pdf:docinfo:producer"",""Adobe PDF Library 15.0""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:docinfo:custom:GTS_PDFXVersion"",""PDF/X-1:2001""
""access_permission:modify_annotations"",""true""
""dcterms:created"",""2019-07-18T20:26:01Z""
""Last-Modified"",""2019-07-19T12:26:37Z""
""dcterms:modified"",""2019-07-19T12:26:37Z""
""title"",""6_artigo_8655757_2a_prova.indd""
""xmpMM:DocumentID"",""xmp.id:1f2124c8-faae-0948-8137-728f763700fe""
""Last-Save-Date"",""2019-07-19T12:26:37Z""
""pdf:docinfo:modified"",""2019-07-19T12:26:37Z""
""meta:save-date"",""2019-07-19T12:26:37Z""
""Content-Length"",""596867""
""Content-Type"",""application/pdf""
""xmp:MetadataDate"",""2019-07-19T09:26:37Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""dc:language"",""pt-BR""
""pdf:producer"",""Adobe PDF Library 15.0""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""20""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""2024"",""1665"",""2671"",""3040"",""2640"",""2446"",""2730"",""2585"",""2855"",""2702"",""2714"",""3325"",""2687"",""2814"",""2859"",""2240"",""2261"",""2301"",""2132"",""479""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""pdf:docinfo:custom:GTS_PDFXConformance"",""PDF/X-1a:2001""
""xmpMM:DerivedFrom:InstanceID"",""xmp.iid:6b9c9a34-0008-6344-a085-ee6e5183976b""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-07-18T20:26:01Z""
";https://scholar.google.com/scholar?start=550&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094581-829;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Tight reductions for Diffie-Hellman variants in the algebraic group model;T Mizuide, A Takayasu, T Takagi ; Cryptographers' Track at the RSA …, 2019  Springer;;"… In Crypto'18, Fuchsbauer, Kiltz, and Loss [FKL18] introduced an algebraic group model (AGM) …

Although the algebraic algorithm is not required to interact with an oracle for the computation,

it should output a record of a group operation which Fuchsbauer et al …";Cité 6 fois;Les 5 versions;[PDF] iacr.org;https://eprint.iacr.org/2018/1220.pdf;"
Tight Reductions for Diffie-Hellman Variants in the

Algebraic Group Model∗

Taiga Mizuide†, Atsushi Takayasu‡, Tsuyoshi Takagi§

June 29, 2019

Abstract

Fuchsbauer, Kiltz, and Loss (Crypto’18) gave a simple and clean definition of an alge-
braic group model (AGM) that lies in between the standard model and the generic group
model (GGM). Specifically, an algebraic adversary is able to exploit group-specific structures
as the standard model while the AGM successfully provides meaningful hardness results as the
GGM. As an application of the AGM, they showed a tight computational equivalence between
the computing Diffie-Hellman (CDH) assumption and the discrete logarithm (DL) assumption.
For the purpose, they used the square Diffie-Hellman assumption as a bridge, i.e., they first
proved the equivalence between the DL assumption and the square Diffie-Hellman assumption
in the AGM, then used the known equivalence between the square Diffie-Hellman assumption
and the CDH assumption in the standard model. In this paper, we provide an alternative proof
that directly shows the tight equivalence between the DL assumption and the CDH assumption.
The crucial benefit of the direct reduction is that we can easily extend the approach to several
variants of the CDH assumption, e.g., the bilinear Diffie-Hellman assumption. Indeed, we show
several tight computational equivalences and discuss applicabilities of our techniques. In this
full version, we provide further applications (including the matrix computational Diffie-Hellman
assumption and the kernel matrix Diffie-Hellman assumption) and a detailed overview of our
techniques.

∗We would like to thank anonymous reviewers of CT-RSA 2019 for their helpful comments and suggestions. This
research was supported by JST CREST Grant Number JPMJCR14D6, Japan. This is the full version of [MTT19].

†Department of Creative Informatics, The University of Tokyo.
‡Department of Mathematical Informatics, The University of Tokyo and National Institute of Advanced Industrial

Science and Technology (AIST). (takayasu@mist.i.u-tokyo.ac.jp)
§Department of Mathematical Informatics, The University of Tokyo.



Contents

1 Introduction 3
1.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Our Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3 Technical Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4 Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2 Computational Problems 6
2.1 Diffie-Hellman Variants in Cyclic Groups . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2 Diffie-Hellman Variants in Symmetric Bilinear Groups . . . . . . . . . . . . . . . . . 7
2.3 Matrix Diffie-Hellman Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

3 Algebraic Group Model 11

4 Reductions for Diffie-Hellman Variants in Cyclic Groups 13
4.1 DL to CDH Reduction via Affine Embedding . . . . . . . . . . . . . . . . . . . . . . 13
4.2 Master Theorem in Cyclic Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

5 Reductions for Diffie-Hellman Variants in Symmetric Bilinear Groups 16
5.1 Algebraic Symmetric Bilinear Group Model . . . . . . . . . . . . . . . . . . . . . . . 16
5.2 BDL to CBDH Reduction via Affine Embedding . . . . . . . . . . . . . . . . . . . . 16
5.3 Master Theorem in Symmetric Bilinear Groups . . . . . . . . . . . . . . . . . . . . . 18

6 Reduction for Matrix Computational Diffie-Hellman Problem 20
6.1 Algebraic Group Model for Matrix Computational Diffie-Hellman Problem . . . . . . 21
6.2 BDL to Computational k-Lin Reduction via Implicit Embedding . . . . . . . . . . . 21
6.3 Master Theorem for Matrix Computational Diffie-Hellman Problem . . . . . . . . . 22

7 Reduction for Matrix Kernel Diffie-Hellman Problem 26
7.1 Algebraic Group Model for Matrix Kernel Diffie-Hellman Problem . . . . . . . . . . 27
7.2 Master Theorem for Matrix Kernel Diffie-Hellman Problem . . . . . . . . . . . . . . 27

8 Conclusion 29



1 Introduction

1.1 Background

Diffie-Hellman Problem in the Generic Group Model. The discrete logarithm (DL) as-
sumption and the computational Diffie-Hellman (CDH) assumption including its variants have been
devoted to constructing numerous cryptographic protocols. Hence, estimating the computational
hardness of solving the problems is a fundamental research topic in cryptography. For the pur-
pose, the generic group model (GGM) [Nec94, BL96, Sho97, MW98, Mau05] over cyclic groups is
a wonderful tool and has successfully provided several fantastic results in the context. Generic al-
gorithms are not able to exploit specific structures of cyclic groups in the sense that the algorithms
are given group elements only via abstract handles. Then, the algorithms are able to output only
group elements which are computed by interacting with an oracle and applying group operations
to given elements. Therefore, generic algorithms such as a baby-step giant-step algorithm, the
Pohlig-Hellman algorithm [PH78] (in composite-order groups), and Pollard’s rho algorithm [Pol78]
work in any cyclic groups.

Furthermore, the most substantial benefit of the GGM is that we are able to derive information
theoretic lower bounds of computational problems, where analogous analyses seem infeasible in the
standard model. For example, any generic algorithms require at least O(

√
p) group operations to

solve the DL problem in cyclic groups of a prime-order p. Analogous analyses have also been made
for the CDH problem and its variants in an ad-hoc manner. Thus far, the GGM has been extended
and used for studying computational problems in bilinear (and multilinear) groups [BB08, Boy08,
KSW13, MRV16, EHK+17].

One main criticism of the GGM is that computational problems that are generically hard may
not be hard when instantiated in concrete groups. Jager and Schwenk [JS13] proved that computing
a Jacobi symbol of an integer modulo a composite n generically is equivalent to factorization;
however, the computation is easy when given an actual representation of Zn. Similarly, the number
field sieves [Gor93] in specific groups are able to solve the DL problem in subexponential time
in log p, i.e., faster than the generic algorithms. Hence, the GGM gives us certain confidence of
computational hardness while we want to obtain analogous results in the standard model or less
restricted models than the GGM.

Algebraic Group Model. In Crypto’18, Fuchsbauer, Kiltz, and Loss [FKL18] introduced an
algebraic group model (AGM). The definition of the AGM lies in between the standard model and
the GGM. Like the standard model and unlike the GGM, an algebraic algorithm is given an actual
representation of cyclic groups. On the other hand, like the GGM and unlike the standard model,
an algebraic algorithm is able to output only group elements by applying group operations to given
elements. Although the algebraic algorithm is not required to interact with an oracle for the compu-
tation, it should output a record of a group operation which Fuchsbauer et al. called a representa-
tion. Let G := (G, G, p) be a group description, where G is an additive cyclic group of a prime-order

p and G is a generator. When an algebraic algorithm is given
(
G, X⃗ := (X1, . . . , Xℓ) ∈ Gℓ

)
and

outputs Z ∈ G, it has to also output a vector z⃗ := (z0, z1, . . . , zℓ) ∈ Zℓ+1
p as a representation of Z

with respect to X⃗ such that Z =
∑ℓ

i=0 ziXi, where X0 := G. Similar definitions of an algebraic
algorithm are already known in [BV98, PV05]; however, Fuchsbauer et al.’s definition is simpler
and clearer.

The AGM is not allowed to derive computational lower bounds as the standard model. In turn,
as opposed to the standard model, Fuchsbauer et al. showed that the AGM is able to make a
tight reduction from the DL to the CDH. To be precise, they used the square Diffie-Hellman (DH)

3



problem [MW96, BDS98] as an intermediate step. They first proved a tight reduction from the DL
to the square DH in the AGM. Let (G, X) be a DL instance such that X := xG. The reduction
algorithm gives (G, X) to a square DH algorithm and receives an answer Z = x2G along with a
representation vector z⃗. Fuchsbauer et al. showed that the vector z⃗ and the relation

z0G+ z1X = Z

are sufficient to recover the DL solution x by solving an equation modulo a prime p. Then, thanks to
the known computational equivalence between the square DH and the CDH [MW99, BDZ03], their
reduction implies a tight reduction from the DL to the CDH in the AGM. Furthermore, a valuable
feature of the result is that the reduction algorithm is generic. Due to the fact, an existence of the
tight reduction implies an information theoretic lower bounds of the CDH as O(

√
p) in the GGM.

Fuchsbauer et al. claimed that a benefit of the AGM is that we are able to derive information
theoretic lower bounds of the CDH in the GGM via quite simple arguments. Indeed, Fuchsbauer
et al.’s reduction in the AGM is much simpler than the analogous analysis in the GGM. Therefore,
providing generic reductions from the DL to other computational problems of the CDH family in
the AGM has to be an interesting open problem.

1.2 Our Contributions

In this paper, we provide generic and tight reductions from the DL to several computational prob-
lems of the CDH family in the AGM. A starting point of our technique is a direct reduction from
the DL to the CDH without using the square DH as the intermediate step. Given the DL in-
stance (G, X), our reduction algorithm randomly samples r ∈ Zp and gives (G, (X1, X2)) to a CDH
algorithm, where

X1 := X = xG and X2 := X + rG = (x+ r)G.

Here, (G, (X1, X2)) is a properly distributed CDH instance in the sense that x and x + r are
independently distributed to uniform in Zp from the CDH algorithm’s view. Then, the reduction
algorithm receives a solution of the CDH Z = x(x+ r)G along with a representation vector z⃗. We
show that the vector z⃗ and the relation

z0G+ z1X1 + z2X2 = Z

are sufficient to recover x by solving an equation modulo a prime p. The approach is very simple
as Fuchsbauer et al.’s one and easily applicable to several CDH variants which are not studied
in [FKL18]. We believe that the simplicity is a main benefit of our result. To explain our technique
as simple as possible, we consider only tight reductions in the sense that the reduction algorithm
uses an algorithm for CDH variants only once.

Furthermore, we extend the AGM to an algebraic bilinear group model (ABGM) for studying
computational problems in symmetric bilinear groups equipped with a map e : G × G → GT . We
define an algebraic bilinear algorithm so that it is given

(
G := (G,GT , G, e, p), X⃗ := (X1, . . . , Xk) ∈

Gk, Y⃗ := (Y1, . . . , Yℓ) ∈ Gℓ
T

)
and outputs Z ∈ GT along with a representation vector z⃗ that indicates

how Z is computed by the given elements. Then, we extend the approach used in cyclic groups and
provide generic and tight reductions from the DL to several computational problems of the CDH
family including the computational bilinear Diffie-Hellman problem.

Finally, we provide our master theorems that indicate what kind of computational assumptions
can be reduced to from the DL assumption both in cyclic groups and bilinear groups of a prime-
order.

4



In the preliminary version [MTT19], our master theorem in cyclic groups does not capture the
computational k-linear problem. Thus, we gave a tailor-made reduction for the problem. In this
full version, we provide a new master theorem for the matrix computational Diffie-Hellman problem
that includes the computational k-linear problem as a special case. Furthermore, we show a new
application called the kernel matrix Diffie-Hellman problem in this full version.

1.3 Technical Overview

In this subsection, we provide more detailed explanation of our technique, where the discussion did
not appear in the preliminary version [MTT19].

In [FKL18], the reduction algorithm of Fuchsbauer et al. gives (G, X), which is exactly the DL
instance, to a square DH algorithm. We call the reduction approach an identity embedding since
the DL solution x is used only by xG = X as a group element. In other words, even if we want
to use an algorithm which takes multiple group elements (X1, X2, . . .) as the input, the identity
embedding can embed the DL solution x into only one group element. Since the square DH is
computationally equivalent to the CDH in the standard model, the identity embedding is enable
to show a computational equivalence between the DL and the CDH by using the square DH as the
intermediate bridge.

However, the identity embedding looks insufficient for providing a direct reduction from the DL
to the CDH. The limitation of the identity embedding is that the DL solution is used only for one
group element. When we try to use the identity embedding to provide a reduction for the CDH,
the reduction algorithm randomly samples r ∈ Zp and sets

X1 := X = xG and X2 := rG.

However, in this case the relation

z0G+ z1X1 + z2X2 = Z

obtained by the output of the CDH algorithm is insufficient for recovering the DL solution x.
Intuitively, the output of the CDH algorithm xrG does not give the reduction algorithm any
additional information, since the reduction algorithm is able to compute Z = xrG = rX by itself.

To this end, we introduce a new embedding which we call an affine embedding. As claimed above,
when we provide a reduction for the CDH problem, the reduction algorithm gives (G, (X1, X2)) to
a CDH algorithm, where

X1 := X = xG and X2 := X + rG = (x+ r)G

by picking a random r ∈ Zp. The affine embedding embeds the DL solution x into two group
elements (X1, X2), where x + r that is an exponent of X2 has an affine relation of x. Then,
the reduction algorithm is able to obtain non-trivial information since it is not able to compute
Z = x(x+ r)G (or x2G) by itself. Similarly, the affine embedding is able to embed the DL solution
x into multiple group elements ((x + r1)G, . . . , (x + rℓ)G) by picking random (r1, . . . , rℓ) ∈ Zℓ

p.

Note that the discrete logarithm of group elements (x, x+ r1, . . . , x+ rℓ) look random in Zℓ+1
p from

Diffie-Hellman algorithm’s view.
The affine embedding is still insufficient for the computational k-linear problem, i.e., given

(G, X1 := x1G, . . . ,Xk := xkG,Y1 := x1y1, . . . , Yk := xkykG) for random (x1, . . . , xk, y1, . . . , yk)
and compute (y1 + ¡ ¡ ¡ + yk)G. Specifically, by embedding an affine relation of the DL solution
x into some (x1, . . . , xk, y1, . . . , yk), then a relation obtained by the k-linear algorithm’s output

5



may result in a zero polynomial. To avoid the obstacle, we sample a random x1 by ourselves and
implicitly embed the DL solution x into x1y1. We call the embedding implicit embedding since we
do not know a value of y1. In other words, a k-linear algorithm enables us to obtain a non-trivial
value y1 = x1/x that enables us to provide a reduction from the DL to the k-linear problem.

1.4 Organization

In Section 2, we review several computational problems which we study in this paper. In Section 3,
we review a definition of the algebraic group model (AGM) defined by Fuchsbauer et al. [FKL18].
In Sections 4 and 5, we show our technique to provide generic and tight reductions from the DL
to the CDH family in cyclic groups and symmetric bilinear groups along with master theorems,
respectively. In Sections 6 and 7, we show new applications of this full version, i.e., generic and
tight reductions from the DL problem to the matrix computational Diffie-Hellman problem and the
matrix kernel Diffie-Hellman problem, respectively.

Notations. We use x
$← Zp to denote a uniformly random sampling from Zp and (x1, . . . , xℓ)

$← Zℓ
p

to denote every element is sampled by xi
$← Zp independently. Let a capital case bold letter A

and a lower case bold letter a denote a matrix and a column vector, respectively. Let 0k denote a
k-dimensional zero vector. For an (m+n)-variate polynomial f(x1, . . . , xm, y1, . . . , yn), we use deg f
to denote a degree of the polynomial and degx1,...,xm

f to denote a degree of the polynomial only
with respect to variables x1, . . . , xm. As an example for f(x, y, z) := x2yz, we use the notations
deg f = 4, degx f = 2, and degx,y = 3. As a notational convenience, we use deg f = 1/k for

f = x1/k and deg f = −k for f = x−k.

2 Computational Problems

In this section, we review several computational problems that we study in this paper. Specifically,
in Sections 2.1, 2.2, and 2.3, we review Diffie-Hellman variants in cyclic groups, symmetric bilin-
ear groups, and matrix Diffie-Hellman problems in asymmetric bilinear groups, respectively. The
contents of this section refer to [Boy08, KSW13, MRV16, EHK+17].

2.1 Diffie-Hellman Variants in Cyclic Groups

We review computational problems in cyclic groups. Let G := (G, G, p) be a group description,
where G is an additive group generated by G and has a prime-order p.1 For simplicity, when given
G we use the notation [a] := aG for a ∈ Zp.

We first define a discrete logarithm problem to which other problems will be reduced.

Definition 1 (Discrete Logarithm (DL) Problem). Given a group description G := (G, G, p) and

a group element X := [x] ∈ G;x
$← Zp, compute x ∈ Zp.

Then, we summarize the CDH problem and its variants which we study in this paper.

Definition 2 (Computational Diffie-Hellman (CDH) Problem [DH76]). Given a group description

G := (G, G, p) and group elements (X1 := [x1], X2 := [x2]) ∈ G2; (x1, x2)
$← Z2

p, compute Z :=
[x1x2] ∈ G.

1 To construct a reduction, we solve an equation modulo an order of G. Hence, if the order is composite, we do
not know how to solve it in general. Hence, we study only a prime-order group in this paper as [FKL18].

6



Definition 3 (k-party Diffie-Hellman (k-PDH) Problem [Bis08]). Given a group description G :=

(G, G, p) and group elements (X1 := [x1], . . . , Xk := [xk]) ∈ Gk; (x1, . . . , xk)
$← Zk

p, compute Z :=
[x1 ¡ ¡ ¡xk] ∈ G.

The following k-exponent Diffie-Hellman assumption for k = 2 called the square Diffie-Hellman
assumption was used in [MW96, BDS98].

Definition 4 (k-exponent Diffie-Hellman (k-EDH) Problem). Given a group description G :=

(G, G, p) and a group element X := [x] ∈ G;x
$← Zp, compute Z := [xk] ∈ G.

The following k-th root Diffie-Hellman problem for k = 2 called the square root Diffie-Hellman
problem was used in [KMS04].

Definition 5 (k-th Root Diffie-Hellman (k-RDH) Problem). Given a group description G :=

(G, G, p) and a group element X := [x] ∈ G;x
$← Zp, compute Z := [x1/k] ∈ G.

The following k-Inverse Diffie-Hellman problem for k = 1 called the inverse computational
Diffie-Hellman problem was used in [BDZ03].

Definition 6 (k-Inverse Diffie-Hellman (k-IDH) Problem). Given a group description G :=

(G, G, p) and a group element X := [x] ∈ G;x
$← Zp, compute Z := [x−k] ∈ G.

To provide our master theorem in cyclic groups, we define a generalized version of the Diffie-
Hellman problem as follows.

Definition 7 (Generalized Diffie-Hellman (GDH) Problem). Let f1(x1, . . . , xm, y1, . . . , yn), . . . ,
fℓ(x1, . . . , xm, y1, . . . , yn), and g(x1, . . . , xm) be known fixed non-zero polynomials. Given a group
description G := (G, G, p) and group elements

(X1 := [f1(x1, . . . , xm, y1, . . . , yn)], . . . , Xℓ := [fℓ(x1, . . . , xm, y1, . . . , yn)]) ∈ Gℓ;

(x1, . . . , xm, y1, . . . , yn)
$← Zm+n

p ,

compute
Z := [g(x1, . . . , xm)] ∈ G.

Note that the GDH problem contains the CDH, the k-PDH, the k-EDH, the k-RDH, and the
k-IDH problem as special cases.

2.2 Diffie-Hellman Variants in Symmetric Bilinear Groups

We review computational problems in bilinear groups. For simplicity, we focus only on symmetric
bilinear maps e : G×G → GT . Let G := (G,GT , G, e, p) be a bilinear group description, where G
is an additive group generated by G and has a prime-order p, and GT is a multiplicative group of
order p associated with a non-degenerate bilinear map e : G×G→ GT , i.e., e(G,G) is a generator
of GT and e(xG, yG) = e(G,G)xy. For simplicity, when given G we use the notations [a] := aG and
[a]T := e(G,G)a for a ∈ Zp.

We will provide a reduction from the DL in source groups G to CDH variants. Hence, we define
a bilinear discrete logarithm problem as follows.

Definition 8 (Bilinear Discrete Logarithm (BDL) Problem). Given a bilinear group description

G := (G,GT , G, e, p) and a group element X := [x] ∈ G;x
$← Zp, compute x ∈ Zp.

7



Then, we summarize the CDH variants in symmetric bilinear groups.

Definition 9 (Computational Bilinear Diffie-Hellman (CBDH) Problem [BF03, Jou04]). Given a
bilinear group description G := (G,GT , G, e, p) and group elements (X1 := [x1], X2 := [x2], X3 :=

[x3]) ∈ G3; (x1, x2, x3)
$← Z3

p, compute Z := [x1x2x3]T ∈ GT .

Definition 10 (k-party Bilinear Diffie-Hellman (k-PBDH) Problem). Given a group description

G := (G,GT , G, e, p) and group elements (X1 := [x1], . . . , Xk := [xk]) ∈ Gk; (x1, . . . , xk)
$← Zk

p,
compute Z := [x1 ¡ ¡ ¡xk]T ∈ GT .

Definition 11 (k-exponent Bilinear Diffie-Hellman (k-EBDH) Problem). Given a group description

G := (G,GT , G, e, p) and a group element X := [x] ∈ G;x
$← Zp, compute Z := [xk]T ∈ GT .

Definition 12 (k-th Root Bilinear Diffie-Hellman (k-RBDH) Problem). Given a group description

G := (G,GT , G, e, p) and a group element X := [x] ∈ G;x
$← Zp, compute Z := [x1/k]T ∈ GT .

Definition 13 (k-Inverse Bilinear Diffie-Hellman (k-IBDH) Problem). Given a group description

G := (G,GT , G, e, p) and a group element X := [x] ∈ G;x
$← Zp, compute Z := [x−k]T ∈ GT .

To provide our master theorem in bilinear groups, we define a generalized version of the bilinear
Diffie-Hellman problem as follows.

Definition 14 (Generalized Bilinear Diffie-Hellman (GBDH) Problem). Let f1(x1, . . . , xm, y1,
. . . , yn), . . . , fk(x1, . . . , xm, y1, . . . , yn), g1(x1, . . . , xm, y1, . . . , yn), . . . , gℓ(x1, . . . , xm, y1, . . . , yn), and
h(x1, . . . , xm) be known fixed non-zero polynomials. Given a bilinear group description G :=
(G,GT , G, e, p) and group elements(

X1 := [f1(x1, . . . , xm, y1, . . . , yn)], . . . , Xk := [fk(x1, . . . , xm, y1, . . . , yn)],
Y1 := [g1(x1, . . . , xm, y1, . . . , yn)]T , . . . , Yℓ := [gℓ(x1, . . . , xm, y1, . . . , yn)]T

)
∈ Gk ×Gℓ

T ;

(x1, . . . , xm, y1, . . . , yn)
$← Zm+n

p ,

compute
Z := [h(x1, . . . , xm)]T ∈ GT .

Note that the GBDH problem contains the CBDH, the k-PBDH, the k-EBDH, the k-RBDH,
and the k-IBDH problem as special cases.

2.3 Matrix Diffie-Hellman Problem

We review matrix Diffie-Hellman problems in asymmetric bilinear groups2. Let G := (G,GT ,
G1, G2, e, p) be an asymmetric bilinear group description, where G1 and G2 are additive groups
generated by G1 and G2 respectively, and has a prime-order p, and GT is a multiplicative group
of order p associated with a non-degenerate bilinear map e : G1 × G2 → GT , i.e., e(G1, G2) is a
generator of GT and e(xG1, yG2) = e(G1, G2)

xy. For simplicity, when given G we use the notations
[a]1 := aG1, [a]2 := aG2, and [a]T := e(G1, G2)

a for a ∈ Zp. Furthermore, for a matrix A = (ai,j)
we use the notation [A]1 to denote a matrix whose every (i, j) element is [ai,j ]1. We use analogous
notations to denote [A]2 and [A]T .

Matrix Distribution. Let Dk be a matrix distribution to sample a matrix A ∈ Z(k+1)×k
p . Let

Ā and a⊤ denote a top k × k submatrix and a bottom row vector of A, respectively. Escala
2The problem did not appear in the preliminary version [MTT19].

8



et al. [EHK+17] introduced a matrix decisional Diffie-Hellman (matrix DDH) problem. Roughly

speaking, the matrix DDH problem states that ([A]1, [As]1) and ([A]1, [u]1) in G(k+1)×k
1 × Gk+1

1

are computationally indistinguishable, where A ← Dk, s
$← Zk

p, and u
$← Zk+1

p . The matrix DDH
contains several decisional problems as special cases. For example, we show examples of matrix
distributions Dk for the Symmetric k-Cascade assumption (SCk), the k-Cascade assumption (Ck),
the decisional k-linear assumption (Lk), the incremental k-linear assumption (ILk) that were
introduced in [EHK+17], and the randomized k-linear assumption (RLk) that were introduced
in [JR14] (they called the assumption k-lifted assumption and the randomized k-linear assumption
was named in [MRV16]) as follows:

Lk : A =


a1 0

. . .

0 ak
1 ¡ ¡ ¡ 1

 , SCk : A =


a 0

1
. . .
. . . a

0 1

 , Ck : A =


a1 0

1
. . .
. . . ak

0 1

 ,

ILk : A =


a 0

a+ 1
. . .

0 a+ k − 1
1 ¡ ¡ ¡ 1

 , RLk : A =


a1 0

. . .

0 ak
ak+1 ¡ ¡ ¡ a2k

 .

We define a generalized matrix distribution to provide our master theorems as follows:

Definition 15 (Generalized Matrix Distribution GMk). Let fi,j(x1, . . . , xm) be known fixed poly-
nomials (which may include zero polynomials) for (i, j) ∈ {1, 2, . . . , k + 1} × {1, 2, . . . , k}. The

generalized matrix distribution GMk is defined by A = (ai,j) ∈ Z(k+1)×k
p for

ai,j = fi,j(x1, . . . , xm); (x1, . . . , xm)
$← Zm

p ,

where

• Ā is full rank with overwhelming probability.

• There is at least one index j ∈ {1, 2, . . . , k} such that fk+1,j(x1, . . . , xm) are non-zero polyno-
mials.

We use the notation Xi,j to denote [ai,j ]1.

We will provide generic and tight reductions for computational counter parts of matrix Diffie-
Hellaman problems based on the following bilinear discrete logarithm problem in a group G1.

Definition 16 (Bilinear Discrete Logarithm (BDL) Problem in G1). Given a bilinear group de-

scription G := (G1,G2,GT , G1, G2, e, p) and a group element X := [x]1 ∈ G1;x
$← Zp, compute

x ∈ Zp.

In this paper, we study computational counterparts of the matrix DDH assumption in the
following two ways as [MRV16].

Matrix Computational Diffie-Hellman Problem. The first computational counterpart is the
matrix computational Diffie-Hellman (MCDH) problem. Roughly speaking, the MCDH problem

states that given ([A]1, [Ās]1) ∈ G(k+1)×k
1 × Gk+1

1 then computing [a⊤s]1 ∈ G1 is computationally

hard, where A← Dk and s
$← Zk

p.

9



Definition 17 (Computational k-Linear (k-Lin) Problem). Given a group description G :=
(G,GT , G1, G2, e, p) and group elements (X1 := [x1]1, . . . , Xk := [xk]1, Y1 := [x1y1]1, . . . , Yk :=

[xkyk]1) ∈ G2k+1
1 ; (x1, . . . , xk, y1, . . . , yk)

$← Z2k
p , compute Z := [y1 + ¡ ¡ ¡+ yk]1 ∈ G1.

Definition 18 (Computational Symmetric k-Cascade (k-SCasc) Problem). Given a group de-
scription G := (G,GT , G1, G2, e, p) and group elements (X := [x]1, Y1 := [xy1]1, Y2 := [y1 +

xy2]1, . . . , Yk := [yk−1 + xyk]1) ∈ Gk+1
1 ; (x, y1, . . . , yk)

$← Zk+1
p , compute Z := [yk]1 ∈ G1.

Definition 19 (Computational k-Cascade (k-Casc) Problem). Given a group description G :=
(G,GT , G1, G2, e, p) and group elements (X1 := [x1]1, . . . , Xk := [xk]1, Y1 := [x1y1]1, Y2 := [y1 +

x2y2]1, . . . , Yk := [yk−1 + xkyk]1) ∈ G2k
1 ; (x1, . . . , xk, y1, . . . , yk)

$← Z2k
p , compute Z := [yk]1 ∈ G1.

Definition 20 (Computational Incremental k-Linear (k-IL) Problem). Given a group description
G := (G,GT , G1, G2, e, p) and group elements (X := [x]1, Y1 := [x1y1]1, Y2 := [(x+1)y2]1, . . . , Yk :=

[(x+ k − 1)yk]1) ∈ Gk+1
1 ; (x, y1, . . . , yk)

$← Zk+1
p , compute Z := [y1 + ¡ ¡ ¡+ yk]1 ∈ G1.

Definition 21 (Computational Radnomized k-Linear (k-RL) Problem). Given a group descrip-
tion G := (G,GT , G1, G2, e, p) and group elements (X1 := [x1]1, . . . , X2k := [x2k]1, Y1 :=

[x1y1]1, . . . , Yk := [xkyk]1) ∈ G3k
1 ; (x1, . . . , x2k, y1, . . . , yk)

$← Z3k
p , compute Z := [xk+1y1 + ¡ ¡ ¡ +

x2kyk]1 ∈ G1.

When the matrix distribution follows a generalized matrix distribution GMk in Definition 15,
we call the computational problem a generalized matrix computational Diffie-Hellman problem. We
formally define it as follows.

Definition 22 (Generalized Matrix Computational Diffie-Hellman (GMCDH) Problem). Let
fi,j(x1, . . . , xm) for (i, j) ∈ {1, 2, . . . , k + 1} × {1, 2, . . . , k} be polynomials in Definition 15. Given
a group description G := (G,GT , G1, G2, e, p) and group elements

((Xi,j := [fi,j(x1, . . . , xm)]1)(i,j)∈{1,2,...,k+1}×{1,2,...,k}, (Yi := [
k∑

j=1

fi,j(x1, . . . , xm)yj ]1)j∈{1,2,...,k}) ∈ Gk(k+2)
1 ;

(x1, . . . , xm, y1, . . . , yk)
$← Zm+k

p ,

compute

Z := [

k∑
j=1

fk+1,j(x1, . . . , xm)yj ]1 ∈ G1.

Note that the GMCDH problem contains computational variants of the k-SCasc, the k-Casc,
the k-Lin, k-IL, and the k-RL problems as special cases.

Matrix Kernel Diffie-Hellman Problem. The other computational counterpart is the matrix
kernel Diffie-Hellman (MKDH) problem. Roughly speaking, the MKDH problem states that given

[A]1 ∈ G(k+1)×k
1 then computing [v]2 ∈ Zk+1

p \ {0k+1} such that A⊤v = 0k is computationally
hard, where A← Dk.

Definition 23 (Kernel k-Linear (k-Lin) Problem). Given a group description G :=

(G,GT , G1, G2, e, p) and group elements (X1 := [x1]1, . . . , Xk := [xk]1) ∈ Gk; (x1, . . . , xk)
$← Zk

p,

compute (Z1 := [z1]2, . . . , Zk+1 := [zk+1]2) ∈ Gk+1
2 such that x1z1 + zk+1 = ¡ ¡ ¡ = xkzk + zk+1 = 0

and (z1, . . . , zk+1) ̸= 0k+1.

10



Definition 24 (Kernel Symmetric k-Cascade (k-SCasc) Problem). Given a group description

G := (G,GT , G1, G2, e, p) and a group element X := [x]1 ∈ G1;x
$← Zp, compute (Z1 :=

[z1]2, . . . , Zk+1 := [zk+1]2) ∈ Gk+1
2 such that xz1 + z2 = ¡ ¡ ¡ = xzk + zk+1 = 0 and (z1, . . . , zk+1) ̸=

0k+1.

Definition 25 (Kernel k-Cascade (k-Casc) Problem). Given a group description G :=

(G,GT , G1, G2, e, p) and group elements (X1 := [x1]1, . . . , Xk := [xk]1) ∈ Gk; (x1, . . . , xk)
$← Zk

p,

compute (Z1 := [z1]2, . . . , Zk+1 := [zk+1]2) ∈ Gk+1
2 such that x1z1 + z2 = ¡ ¡ ¡ = xkzk + zk+1 = 0 and

(z1, . . . , zk+1) ̸= 0k+1.

Definition 26 (Kernel Incremental k-Linear (k-IL) Problem). Given a group description

G := (G,GT , G1, G2, e, p) and a group element X := [x]1 ∈ G1;x
$← Zp, compute (Z1 :=

[z1]2, . . . , Zk+1 := [zk+1]2) ∈ Gk+1
2 such that xz1 + zk+1 = (x + 1)z2 + zk+1 = · · · = (x + k −

1)zk + zk+1 = 0 and (z1, . . . , zk+1) ̸= 0k+1.

Definition 27 (Kernel Radnomized k-Linear (k-RL) Problem). Given a group description G :=

(G,GT , G1, G2, e, p) and group elements (X1 := [x1]1, . . . , X2k := [x2k]1) ∈ G2k
1 ; (x1, . . . , x2k)

$←
Z2k
p , compute (Z1 := [z1]2, . . . , Zk+1 := [zk+1]2) ∈ Gk+1

2 such that x1z1 + xk+1zk+1 = ¡ ¡ ¡ = xkzk +
x2kzk+1 = 0 and (z1, . . . , zk+1) ̸= 0k+1.

When the matrix distribution follows a generalized matrix distribution GMk in Definition 15,
we call the kernel problem a generalized matrix kernel Diffie-Hellman problem.

Definition 28 (Generalized Matrix Kernel Diffie-Hellman (GMKDH) Problem). Let
fi,j(x1, . . . , xm) for (i, j) ∈ {1, 2, . . . , k + 1} × {1, 2, . . . , k} be polynomials in Definition 15. Given
a group description G := (G,GT , G1, G2, e, p) and group elements

(Xi,j := [fi,j(x1, . . . , xm)]1)(i,j)∈{1,2,...,k+1}×{1,2,...,k} ∈ Gk(k+1)
1 ; (x1, . . . , xm)

$← Zm
p ,

compute (Z1 := [z1]2, . . . , Zk+1 := [zk+1]2) ∈ Gk+1
2 such that

f1,j(x1, . . . , xm)z1 + ¡ ¡ ¡+ fk+1,j(x1, . . . , xm)zk+1 = 0

for all j ∈ {1, 2, . . . , k} and (z1, . . . , zk+1) ̸= 0k+1.

Note that the GMKDH problem contains kernel variants of the k-SCasc, the k-Casc, the k-Lin,
k-IL, and the k-RL problems as special cases.

3 Algebraic Group Model

In this section, we review basic notions of security games, the generic group model, and the algebraic
group model. The contents of this section heavily refer to [FKL18].

Algebraic Security Game. Let GG be an algebraic security game relative to a group description
G := (G, G, p); an adversary A receives G and an instance of the problem X⃗ from a challenger, then
returns an output. For example, we use CDHG to denote security games of the CDH problem
relative to G; an adversary A receives G and (X1, X2) from a challenger, then returns an output Z.
We use GA

G to denote an output of a game GG between a challenger and an adversary A. A is said

to win if GA
G = 1; CDHA

G = 1 when Z = [x1x2]. We define an advantage and a running time of an

adversar";"""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.5""
""xmp:CreatorTool"","" TeX output 2019.06.29:1757""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dcterms:created"",""2019-06-29T08:57:36Z""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"","" TeX output 2019.06.29:1757""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""Content-Length"",""193267""
""pdf:hasMarkedContent"",""false""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""meta:creation-date"",""2019-06-29T08:57:36Z""
""created"",""2019-06-29T08:57:36Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""31""
""Creation-Date"",""2019-06-29T08:57:36Z""
""resourceName"",""1220.pdf""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""1823"",""1350"",""3218"",""2744"",""2664"",""2555"",""2104"",""2354"",""2005"",""2326"",""2329"",""2860"",""1826"",""1784"",""1910"",""2346"",""1872"",""1928"",""1784"",""1728"",""2227"",""2302"",""1535"",""1715"",""1154"",""1820"",""2568"",""2277"",""2674"",""2584"",""1953""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""producer"",""dvipdfmx (20160307)""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""dvipdfmx (20160307)""
""pdf:docinfo:created"",""2019-06-29T08:57:36Z""
";https://scholar.google.com/scholar?start=640&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094539-648;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Uso de blockchain en la administración pública;E Mereles, J Ortellado ;2019 colibri.udelar.edu.uy;;"Page 1. UNIVERSIDAD DE LA REPÚBLICA FACULTAD DE INGENIERÍA Instituto de

Computación - InCo PROYECTO DE GRADO Uso de blockchain en la administración pública

Autores: Tutor: Eduardo Mereles Javier Barreiro Juan Ortellado … 2.1 Blockchain …";Autres articles;Version HTML;[PDF] udelar.edu.uy;https://www.colibri.udelar.edu.uy/jspui/bitstream/20.500.12008/20646/1/tg-mereles-ortellado.pdf;"
 

        

UNIVERSIDAD DE LA REPÚBLICA 

FACULTAD DE INGENIERÍA 

Instituto de ComputaciĂłn - InCo 

PROYECTO DE GRADO 

Uso de blockchain en la 

administraciĂłn pĂşblica 

Autores:         Tutor: 

Eduardo Mereles        Javier Barreiro 

Juan Ortellado 

Montevideo, Uruguay 

2019 

 



 

 



 

  

RESUMEN 
Blockchain es una tecnologĂ­a emergente que ha cobrado gran notoriedad en los Ăşltimos 
aĂąos en relaciĂłn a su uso en criptomonedas como Bitcoin. Esto ha provocado que se 

analicen en profundidad sus funcionalidades y se evalĂşe su aplicabilidad en otros 
contextos. 

Esta tecnologĂ­a presenta una serie de caracterĂ­sticas que dan indicios de aplicabilidad 

en escenarios que poco tienen que ver con criptomonedas, como lo son la 
descentralizaciĂłn en escenarios donde no hay confianza entre los participantes, 
escenarios donde es importante la inmutabilidad de la informaciĂłn agregada, 
escenarios donde la informaciĂłn no se pueda corromper, o en definitiva cualquier 
combinaciĂłn de estos tres.  

El objetivo de este proyecto fue investigar la tecnologĂ­a, asĂ­ como herramientas que 

permitan trabajar con blockchain y a travĂŠs de ellas evaluar su aplicabilidad a un caso 
de uso en la administraciĂłn pĂşblica. Se investigĂł Bitcoin, dado que es la primera 
implementaciĂłn en producciĂłn y habiendo comprendido los conceptos expuestos por la 
criptomoneda, se investigĂł la tecnologĂ­a abstrayĂŠndose de la misma. Luego el foco se 

puso en estudiar frameworks de desarrollo para blockchain, analizando las 
prestaciones ofrecidas en relaciĂłn a los distintos escenarios posibles donde aplicarlo. 
Por Ăşltimo, y en base al conocimiento adquirido, se relevaron casos de uso posibles en 
dĂłnde aplicar la tecnologĂ­a blockchain en el entorno de la administraciĂłn pĂşblica. Sobre 
los casos relevados, se consultaron distintos involucrados para entender mĂĄs en 
profundidad cada una de las realidades y de esa forma buscar el mejor escenario para 
el proyecto. Este proceso permitiĂł seleccionar un caso de uso particular, que fue 
sometido a dos cuestionarios genĂŠricos que asisten a quien lo usa para entender si el 
caso puede o no ser resuelto con blockchain, y en caso de que el resultado sea 

afirmativo, da indicios de quĂŠ tipo de blockchain se deberĂ­a utilizar. 

En base al anĂĄlisis previo, se eligiĂł uno de los casos de uso para el desarrollo de una 
aplicaciĂłn sobre la tecnologĂ­a blockchain, el cual implica una mejora en relaciĂłn a la 

soluciĂłn actual. Adicionalmente, el desarrollo fue realizado pensando en que este caso 
pueda ser extendido fĂĄcilmente, dado que fueron encontradas otras funcionalidades en 
las que tambiĂŠn serĂ­a de gran valor el uso de blockchain, pero se optĂł por no 
implementarlo debido al alcance del proyecto. 

Palabras clave: blockchain, Hyperledger, cadena de bloques.  



 

  



 

 

Contenido	

1. IntroducciĂłn .................................................................................................................. 7	

1.1. Objetivos ................................................................................................................ 8	

1.2. OrganizaciĂłn del documento ................................................................................. 8	

2. Marco Conceptual ...................................................................................................... 11	

2.1 Blockchain ............................................................................................................ 11	

2.1.1. Conceptos de blockchain .............................................................................. 13	

2.1.2. Tipos de blockchain ...................................................................................... 15	

2.1.3. Integridad ...................................................................................................... 18	

2.1.4. Smart Contracts ............................................................................................ 21	

2.1.5 Otros componentes ........................................................................................ 22	

2.2. Bitcoin .................................................................................................................. 23	

3. Casos de aplicaciĂłn ................................................................................................... 25	

3.1. SituaciĂłn actual ................................................................................................... 25	

3.2. Casos de uso en ĂĄmbito pĂşblico .......................................................................... 28	

4. Plataformas de blockchain ......................................................................................... 33	

4.1 Plataformas investigadas ...................................................................................... 34	

4.1.1 Ethereum ........................................................................................................ 34	

4.1.2 Corda ............................................................................................................. 34	

4.1.3 Credits ............................................................................................................ 35	

4.2 Hyperledger Fabric ............................................................................................... 35	

5. Caso de uso en administraciĂłn pĂşblica ...................................................................... 45	

5.1. Caso de uso: empadronamiento vehicular .......................................................... 45	

5.2. ValidaciĂłn de aplicabilidad .................................................................................. 45	

5.2.1. Primera validaciĂłn ......................................................................................... 46	



 

5.2.1. Segunda validaciĂłn ....................................................................................... 48	

6. Arquitectura de la soluciĂłn ......................................................................................... 51	

6.1. Vista lĂłgica .......................................................................................................... 51	

6.2. Vista fĂ­sica ........................................................................................................... 56	

6.3. Escenario ............................................................................................................. 57	

7. ImplementaciĂłn .......................................................................................................... 59	

7.1. TecnologĂ­as utilizadas ......................................................................................... 59	

7.2. Aspectos de la implementaciĂłn ........................................................................... 60	

7.3. Dificultades y limitaciones encontradas ............................................................... 63	

8. GestiĂłn del proyecto .................................................................................................. 67	

8.1. OrganizaciĂłn ........................................................................................................ 67	

8.2. PlanificaciĂłn y ejecuciĂłn ...................................................................................... 67	

9. Conclusiones y trabajo a futuro .................................................................................. 71	

Referencias .................................................................................................................... 73	

GLOSARIO ..................................................................................................................... 79	

APÉNDICE A - Instalación de Hyperledger Fabric ......................................................... 83	

APÉNDICE B - Instalación de la aplicación ................................................................... 85	

APÉNDICE C - Cambio versión Hyperledger ................................................................. 89	

ANEXO ........................................................................................................................... 91	

 

 

  



7 
 

1. IntroducciĂłn 
Aproximadamente en el aĂąo 2009 surge la criptomoneda llamada Bitcoin [1], a travĂŠs 

de la cual tambiĂŠn se le da origen a la tecnologĂ­a hoy conocida como blockchain. En los 
aĂąos subsiguientes, fueron creadas muchas otras criptomonedas emulando el 
funcionamiento de Bitcoin y a pesar de su gran uso en este contexto, blockchain es 
observado como una tecnologĂ­a revolucionaria por sus caracterĂ­sticas y posible 
aplicabilidad en muchos otros contextos. 

Muchas plataformas o servicios que se ofrecen en la actualidad dependen de un 
tercero de confianza para poder funcionar con las garantĂ­as que los usuarios exigen, 
como por ejemplo las aplicaciones bancarias. AquĂ­ los usuarios que desean transferir 

dinero entre ellos, delegan en los bancos el control sobre los saldos, confiando en que 
estos realizarĂĄn correctamente las transferencias. Este tipo de requerimientos, hace 
que se centralice el control y el punto de falla del sistema y por tanto se convierta en un 
componente crĂ­tico para la soluciĂłn. Esta situaciĂłn, se ve alentada por la intervenciĂłn 
de actores con malas intenciones, que encuentran vulnerabilidades y sacan provecho 
de ellas, afectando en algunos casos a todo el sistema informĂĄtico. 

Esta situaciĂłn ha despertado el interĂŠs de la aplicaciĂłn de la tecnologĂ­a blockchain por 

parte de mĂşltiples sectores, tales como la salud, gestiĂłn de mercaderĂ­a y propiedades, 
almacenamiento de informaciĂłn, verificaciĂłn de identidad y administraciĂłn pĂşblica, 
entre otros, por lo que han empezado a evaluar e implementar distintos casos de 
aplicaciĂłn [2]. 

En el gobierno uruguayo, AGESIC es una instituciĂłn que lidera el desarrollo del 
gobierno digital, la sociedad de la informaciĂłn y el conocimiento, desde Presidencia de 
la RepĂşblica. Es responsable por el desarrollo de la polĂ­tica digital del Estado y del 

Uruguay Digital. Algunos de los objetivos estratĂŠgicos son impulsar el gobierno abierto, 
facilitar el relacionamiento con el Estado, integrar digitalmente a los distintos 
organismos, fortalecer el ecosistema de ciberseguridad, simplificar los trĂĄmites 
mejorando los servicios, contribuir con la alfabetizaciĂłn digital, aportar soluciones 
informĂĄticas innovadoras para mejorar los servicios, entre otros. A travĂŠs del plan de 
gobierno digital 2020 [3] propuesto por AGESIC uno de los medios a travĂŠs de los 
cuales se pretende alcanzar los objetivos es facilitando instrumentos normativos, 
institucionales y tĂŠcnicos que habiliten el uso de nuevas tecnologĂ­as para la validez de 

registros, como blockchain. 

De esta forma es que surge el interĂŠs de investigar sus caracterĂ­sticas y si realmente 
es aplicable en otros contextos, en particular en la administraciĂłn pĂşblica. 



8 

 

1.1. Objetivos 

El objetivo general del proyecto es evaluar la aplicabilidad de la tecnologĂ­a blockchain 

en la administraciĂłn pĂşblica e implementar una prueba de concepto donde se pueda 
apreciar esa aplicabilidad. Para cumplir con este objetivo, es que se subdivide en los 
siguientes objetivos especĂ­ficos: 

● Entender el funcionamiento de la tecnología y los escenarios donde aporta valor 

aplicarlo. 
● Investigar herramientas disponibles que existen para implementar los distintos 

tipos de blockchain. 
● Evaluar casos de uso en la administración pública, en los que sea de utilidad 

aplicar una soluciĂłn basada en la tecnologĂ­a blockchain. 
● Elegir un caso de uso de los evaluados anteriormente e implementar una prueba 

de concepto. 

1.2. OrganizaciĂłn del documento 

El documento se encuentra dividido en 9 capĂ­tulos, los cuales se detallarĂĄn a 

continuaciĂłn. 

En el capĂ­tulo 2 se presenta el marco conceptual, donde se desarrollan los conceptos 
bĂĄsicos para comprender quĂŠ es blockchain y cĂłmo funciona, detallando componentes, 

su utilidad y otros conceptos fuertemente relacionados con la tecnologĂ­a. 

En el capĂ­tulo 3 se puede encontrar una descripciĂłn de los casos donde existe una 
mejor aplicabilidad y ejemplos de contextos en los que se estĂĄ aplicando o se 

encuentra en fases de pruebas, asĂ­ como tambiĂŠn casos en la administraciĂłn pĂşblica 
en los que se entiende es aplicable.  

En el capĂ­tulo 4 se presentan algunas de las herramientas utilizadas actualmente para 

implementar blockchain, asĂ­ como la elecciĂłn de una herramienta especĂ­fica para el 
desarrollo, profundizando en aspectos tĂŠcnicos y limitantes. 

En los capĂ­tulos 5 y 6 se presenta el caso de uso elegido sobre el cual se realizĂł la 

prueba de concepto y la arquitectura definida para su implementaciĂłn. 

El capĂ­tulo 7 hace referencia a la implementaciĂłn y allĂ­ se desarrollan las tecnologĂ­as 

utilizadas para poder realizar dicha implementaciĂłn y las decisiones tomadas. 

En el capĂ­tulo 8 se desarrolla todo lo referente a la gestiĂłn del proyecto, donde se 
puede encontrar principalmente lo planificado para su ejecuciĂłn y las situaciones que 

generaron desvĂ­os. 



9 

 

En el capĂ­tulo 9 se expone el trabajo a futuro y las conclusiones tanto de la tecnologĂ­a 

en sĂ­, como de la prueba de concepto realizada.   



10 

 

  



11 

 

2. Marco Conceptual 
En este capĂ­tulo se profundizarĂĄ en cada uno de los aspectos que se entienden 

relevantes para la comprensiĂłn de la tecnologĂ­a blockchain, analizando su 
funcionamiento, su utilidad y los componentes necesarios para su creaciĂłn. Esto serĂĄ 
de utilidad para comprender el anĂĄlisis e implementaciĂłn realizado sobre el caso de 
uso. Adicionalmente se describen problemĂĄticas y aspectos tĂŠcnicos relevantes para 
blockchain, asĂ­ como tambiĂŠn se mostrarĂĄ una categorizaciĂłn realizada en base a las 
caracterĂ­sticas que se pueden encontrar en la tecnologĂ­a. 

2.1 Blockchain 

La idea principal que se introduce con la tecnologĂ­a blockchain es la de eliminar a los 
intermediarios en las transacciones, pero esto supone un problema mayor, ya que 
estos intermediarios existen en gran medida para brindar confianza a las partes 

involucradas y al no estar, podrĂ­an generarse hechos maliciosos entre ellos, como por 
ejemplo el ataque gasto doble. Se define gasto doble [4] [5] como el ataque del uso 
acertado de los mismos medios dos veces. Para explicar este concepto, supongamos 
que entregamos a otra persona o entidad un objeto como por ejemplo una manzana, la 
propiedad de ese objeto deja de pertenecernos y pasa a esa persona o entidad y solo 
podremos recuperarlo si nos lo devuelve voluntariamente o por la fuerza, pero no 
podremos gastar ese objeto fĂ­sico de nuevo si no lo recuperamos. En este sentido, el 
problema con los ficheros digitales es que se pueden reproducir infinitamente, como 

por ejemplo un documento PDF y por este motivo, los sistemas digitales tienden a ser 
centralizados, de forma de garantizar que nadie mĂĄs pueda generar copias digitales de 
los activos con los que se trabaja.  

Como soluciĂłn al ataque de gasto doble, se propone que el control realizado por los 

intermediarios se lleve a cabo de forma distribuida, pero esto introduce un nuevo 
problema. Para realizar este control, los datos deben de estar distribuidos, lo cual 
genera la necesidad de asegurar la incorruptibilidad de los mismos. Esta problemĂĄtica 
es atacada utilizando la tĂŠcnica propuesta por Habert y Stornetta en 1991, en su 
investigaciĂłn ""How to time-stamp a digital document"" [6]. Esta plantea cĂłmo se podrĂ­an 
patentar documentos digitales, archivos de audio, video, etc, de forma que estas 
patentes no puedan alterarse. La investigaciĂłn menciona que no basta con agregar una 
fecha de creado o modificado, pues esto no es confiable y puede ser modificado 

fĂĄcilmente con otras intenciones y plantea que para resolverlo se debe utilizar una 
funciĂłn hash, que a partir de la informaciĂłn que se quiere patentar, genera un cĂłdigo 
Ăşnico llamado hash. Esto implica que, ante el cambio mĂĄs mĂ­nimo en la entrada, el 
cĂłdigo generado se vea modificado, dando como resultado los primeros fundamentos 
de la tecnologĂ­a blockchain. 



12 

 

En el año 2008, surge un documento de investigación cuyo nombre es “Bitcoin: A peer 

to peer electronic cash system” [1], el cual toma como insumo el concepto mencionado 
en el pĂĄrrafo anterior. Un aĂąo mĂĄs tarde, luego del desarrollo realizado por su autor en 
conjunto con otros colaboradores, se realiza la puesta en producciĂłn del sistema y es 
lo que hoy se conoce como Bitcoin, la primera moneda digital descentralizada. En la 
sección “2.2. Bitcoin” se profundizará en el concepto, ya que es fundamental en la 
investigaciĂłn para la definiciĂłn de blockchain.  

Por tanto, blockchain [7] se puede definir como un registro, un libro mayor de 
acontecimientos digitales que estĂĄ distribuido o es compartido entre muchas partes 
diferentes, y solo puede ser actualizado a partir del consenso de los participantes del 

sistema y, una vez introducida, la informaciĂłn nunca podrĂĄ ser borrada. 

Profundizando en las caracterĂ­sticas [8] de la tecnologĂ­a blockchain, la primera que se 
encuentra es que la informaciĂłn no puede ser borrada fĂĄcilmente. Esto es debido a que 

la informaciĂłn se encuentra replicada en cada uno de los participantes y en caso de 
que uno de ellos sufra un ataque, siempre existirĂĄ otro participante que tenga una copia 
de la informaciĂłn. La Ăşnica forma en que se podrĂ­a alcanzar ese objetivo, serĂ­a 
realizando un ataque simultĂĄneo a todos los participantes, lo cual acompaĂąado de 
medidas bĂĄsicas de seguridad, como por ejemplo el uso de certificados digitales, 
usuario y contraseĂąa, lo vuelve una tarea que requiere un gran poder computacional 
para poder ser llevada a cabo. Claramente, a medida que se aumenta en nĂşmero de 
participantes mĂĄs difĂ­cil se vuelve esta tarea. 

La segunda caracterĂ­stica estĂĄ relacionada con la mencionada anteriormente y hace 
referencia a la incorruptibilidad de la informaciĂłn. Si bien en parte la forma de 
protegerse contra este tipo de problemas viene dado por la replicaciĂłn de la 

informaciĂłn, aĂşn quedan situaciones en las que se podrĂ­a llegar a vulnerar lo 
registrado. Para protegerse de esas situaciones, es que se adapta la propuesta de 
Haber y Stornetta, haciendo uso de hashes para proteger la informaciĂłn guardada en la 
blockchain, como será explicado en la sección “2.1.5. Componentes”. 

La tercera caracterĂ­stica es que la informaciĂłn es actualizada a partir del consenso de 

los participantes de la red. Esta caracterĂ­stica juega un rol fundamental en el proceso 
de aprobaciĂłn o rechazo de la informaciĂłn a agregar en la blockchain y es el 
mecanismo que se utiliza para sustituir al intermediario que brinda confianza en la red. 
La idea detrĂĄs del consenso es que la propia red se defienda de los participantes 
maliciosos o agentes externos que intentan agregar informaciĂłn falsa, bajo la hipĂłtesis 
de que la mayorĂ­a de los participantes estarĂĄ en contra de esos actos. Cabe aclarar 

que dependiendo de las necesidades del negocio, puede variar la definiciĂłn de 
consenso para ese escenario. 



13 

 

En base a estas caracterĂ­sticas se puede identificar que esta tecnologĂ­a aplica a 

problemĂĄticas de coordinaciĂłn, confiabilidad y seguridad de datos entre mĂşltiples 
actores y sin intermediarios, asegurando tener en cada actor una copia fiel y ordenada 
de los mismos. Ejemplo de estos casos son [2]: moneda digital, registro catastral, voto 
electrĂłnico, manejo de identidad, trazabilidad en cadena de suministros, salud, sistema 
tributario, administraciĂłn de tĂ­tulos, etc. 

2.1.1. Conceptos de blockchain 

Los componentes [7] [9] de la blockchain bĂĄsicamente son tres: nodos, transacciones y 
bloques. A modo de ejemplo, se representa la blockchain como un libro de cuentas, 
donde los bloques se corresponden a hojas de ese libro, las transacciones pĂĄrrafos de 
cada hoja y los nodos cada lugar del mundo donde se encuentra una copia de ese 
libro. En la figura 2.1 [10] se muestra un diagrama ilustrativo de los componentes antes 
mencionados. 

 

Figura 2.1 - IlustraciĂłn de componentes de blockchain 

En algunos casos es posible encontrar otros componentes como lo son autoridades 
certificadoras u orĂĄculos y su uso varĂ­a dependiendo del tipo de blockchain sobre el 

cual se estĂŠ trabajando y la herramienta que se estĂŠ utilizando para su implementaciĂłn. 
A continuaciĂłn, se define y profundiza en cada uno de los componentes antes 
mencionados. 

 

 



14 

 

Transacciones 

Una transacciĂłn [9] [11] es un mensaje firmado digitalmente que autoriza alguna acciĂłn 
particular asociada a la red blockchain. Para el caso de las criptomonedas, el tipo de 

transacciĂłn dominante son las que involucran por lo menos a dos partes y estĂĄn 
asociadas al intercambio de bienes o servicios a cambio del capital correspondiente. A 
modo de ejemplo, supongamos una red blockchain compuesta por bancos, una 
transacciĂłn podrĂ­a ser representada por una transferencia de un monto de dinero de un 
banco a otro, o bien podrĂ­a representarse como suscripciĂłn de un nuevo cliente en uno 
de los bancos. 

De forma que los participantes de la red puedan leer y si corresponde validar la 
veracidad de las transacciones, las mismas no se encuentran encriptadas y los datos 
que conforman una transacciĂłn varĂ­an dependiendo de la plataforma sobre la cual se 
trabaje. De acuerdo a lo investigado se pueden identificar tres elementos que siempre 
se encuentran presentes, el identificador de la transacciĂłn, una marca de tiempo de 

cuando es ingresada la transacciĂłn a la red y un identificador de quiĂŠn es el emisor de 
la transacciĂłn. Adicionalmente dependiendo de la implementaciĂłn se pueden incluir 
otros elementos como: costo de realizar la transacciĂłn en la criptomoneda asociada, 
nĂşmero de bloque al cual pertenece, estado de transacciĂłn, conjunto de datos leĂ­dos y 
escritos al ejecutar la transacciĂłn, firma digital del origen de la transacciĂłn y firmas 
digitales de los participantes validadores. 

Bloque 
Los bloques [11] son un conjunto de registros que representan la informaciĂłn de la 

blockchain. Un bloque estĂĄ formado por un conjunto de transacciones confirmadas e 
informaciĂłn adicional que se ha incluido en la blockchain. Al igual que sucede con las 
transacciones, dependiendo de la plataforma sobre la que se trabaje, puede variar la 
informaciĂłn que lleva el bloque, pero en lĂ­neas generales algunos de estos campos se 
mantienen. Estos campos que forman parte de cualquier bloque de la cadena (excepto 
el bloque generatriz, que inicia la cadena) son: 

1. Un hash que enlaza con el bloque anterior 

2. El conjunto de transacciones que incluye (cuyo nĂşmero viene determinado por 

diferentes factores) 

3. Marca de tiempo de cuando se genero el bloque 

4. Otro hash que enlazarĂĄ con el siguiente bloque. 

A continuaciĂłn, se muestra la figura 2.2 [7] ilustrativa de cĂłmo se verĂ­a una cadena de 

bloques en construcciĂłn. 

 



15 

 

 

Figura 2.2 - Estructura de bloques 

El bloque en proceso o en construcciĂłn, es el siguiente bloque a ser ingresado en la 

blockchain, en este se ingresan las nuevas transacciones a ser agregadas. Antes de 
agregar este bloque en la blockchain, se debe obtener mediante cĂĄlculos el cuarto 
punto anteriormente indicado. Este punto refiere a un hash que es calculado a partir de 
los datos del bloque en progreso junto con el hash del bloque anterior, provocando que 
si algĂşn dato en ese bloque o el anterior es alterado, el hash generado no coincidirĂĄ 
con el original. De esta forma es posible detectar si un bloque fue corrompido y 
asegurar la detecciĂłn de cambios en los bloques. 

Nodo 

Un nodo es un ordenador conectado a la red blockchain utilizando un software que 

almacena y distribuye una copia de la informaciĂłn de la blockchain en tiempo real. 
Conceptualmente este nodo puede representar una organizaciĂłn, como por ejemplo 
una empresa o un organismo del estado. Dependiendo del tipo de blockchain y los 
privilegios que tenga el nodo, ĂŠste podrĂĄ validar bloques y transacciones, agregar 

transacciones a un bloque y aĂąadir bloques a la blockchain. Cada vez que un bloque es 
confirmado y se aĂąade a la cadena, es comunicado a todos los nodos y este se aĂąade 
a la copia que cada uno almacena. Cada nodo mantiene viva la plataforma blockchain, 
por lo que cuantos mĂĄs nodos haya en la plataforma, mĂĄs copias habrĂĄ y por tanto mĂĄs 
segura estarĂĄ la informaciĂłn en la blockchain. 

A continuaciĂłn, se identifican los distintos tipos de blockchain destacando sus distintas 

caracterĂ­sticas. 

2.1.2. Tipos de blockchain 

Dependiendo de las necesidades del caso de uso donde se va a aplicar, se pueden 
presentar distintos requerimientos para los participantes de la red blockchain. A modo 
de ejemplo, una instituciĂłn privada como un banco podrĂ­a querer utilizar la tecnologĂ­a 
restringiendo el acceso a ciertos participantes, otorgando permisos a quienes son de 
interĂŠs para el banco. Profundizando en el ejemplo, tambiĂŠn podrĂ­a requerir que 



16 

 

algunos de los que pueden acceder solo puedan leer y el resto agregar informaciĂłn. 
Este tipo de situaciones presentan la necesidad de categorizar los distintos tipos de 
tecnologĂ­a blockchain [12]que pueden ser construidos.  

Una primera categorizaciĂłn para las blockchain puede ser en tres tipos distintos, 

pĂşblicas, federadas y privadas, donde ĂŠstas refieren a los permisos de escritura y 
lectura que pueden tener los nodos sobre los datos, aunque ademĂĄs refieren a la 
relaciĂłn que tienen los participantes. A continuaciĂłn, se detalla cada una de estas. 

Blockchain pĂşblica [12] 

Las blockchains pĂşblicas, como lo indica su nombre se encuentran abiertas al mundo, 

por lo que cualquier interesado que desee, puede unirse. AdemĂĄs, todos pueden copiar 
los datos de la misma, leer o escribir nuevas transacciones y comenzar a participar del 
proceso de validaciĂłn de transacciones. Dado que en este tipo de blockchains todos 
los participantes validan transacciones, se deben utilizar mecanismos para prevenir 
posibles alteraciones de la informaciĂłn. Para protegerse de ello, se recomienda que al 
momento de agregar nueva informaciĂłn a la blockchain, se haga uso de algoritmos de 
consenso como proof of work o proof of stake, los cuales serĂĄn mencionados en la 

sección “2.1.3. Integridad”. Es importante destacar que la utilización de estos 
algoritmos presenta problemas de performance, ya que estos se basan en realizar 
cĂĄlculos que implican un gran costo computacional y que terminan generando demoras 
a la hora de agregar nueva informaciĂłn, como se explicarĂĄ en la secciĂłn mencionada 
anteriormente. 

 

Blockchain federada [12] 

Por otra parte, las blockchains federadas operan bajo el control de un grupo, estas no 

permiten que todos los miembros de la red blockchain participen del proceso de 
validaciĂłn. El derecho a leer de la blockchain puede ser pĂşblico o restringido a los 
participantes. Dado que en estas blockchains los nodos que validan las transacciones 
son un conjunto reducido e identificado, generalmente utilizan certificados para firmar 
sus transacciones, por lo que el ingreso de una transacciĂłn se realiza de forma ĂĄgil. Si 
bien esto reduce el costo de transacciĂłn, ĂŠste no es disruptivo.  

Este tipo de blockchain se ajusta fĂĄcilmente al sector bancario, dado que en este caso 

los bancos son las Ăşnicas autoridades capaces de validar las transacciones generadas 
por los usuarios. Por ejemplo, imaginemos un conjunto federado de 15 instituciones 
financieras, donde cada una opera un nodo y 10 de ellas deben firmar cada bloque 
para que sea vĂĄlido. 



17 

 

Existen argumentaciones que dicen que este tipo de sistemas no puede ser definido 

como blockchain, pero la tecnologĂ­a aĂşn se encuentra en sus primeras etapas y no es 
claro cĂłmo serĂĄ adoptado. 

 

Blockchain privada [12] 

Las blockchains privadas son las que pertenecen a una Ăşnica organizaciĂłn, en donde 
todos los participantes estĂĄn plenamente identificados. Pero a diferencia de las 

anteriores, el derecho a leer de la blockchain es restringido Ăşnicamente a los 
participantes. Al igual que en las blockchains federadas, al estar los nodos identificados 
se suelen firmar las transacciones con certificados, por lo que el ingreso de las mismas 
tambiĂŠn se hace de forma ĂĄgil, lo que reduce el costo de transacciĂłn, aunque este no 
es disruptivo. Este tipo de blockchain son ideales para el manejo de los procesos 
internos de las organizaciones, como por ejemplo datos de stock, lista de precios por 
cliente y demĂĄs datos internos y privados. 

Resumiendo, estos tipos de blockchains, en la figura 2.3 se presenta una tabla 

comparativa de aspectos como son el acceso, velocidad, seguridad e identidad. 

 Publica	 Privada	 Federada	

Acceso	 Lectura	/	Escritura	libre	
Lectura	/	Escritura	
libre	(para	los	
miembros	de	la	red)	

Lectura	/	Escritura	solo	para	los	
nodos	autorizados.	El	resto	de	
los	participantes	solo	lectura.	

Velocidad	 Lento	 RĂĄpido	 RĂĄpido	

Seguridad	
Proof	of	Work,	Proof	of	
Stake,	Otros	mecanismos	
de	consenso	

Participantes	
autorizados	 Participantes	autorizados	

Identidad	 Anonimos,	
Pseudoanonimos	 Identidades	conocidas	 Identidades	conocidas	

Figura 2.3: Tabla comparativa de tipos de blockchain 
 



18 

 

Otro tipo de categorizaciĂłn utilizado generalmente es en blockchain permisionadas [13] 
y no permisionadas [13], donde estas solo refieren a los permisos de escritura, lectura y 
validaciĂłn de las transacciones. 

Blockchain no permisionadas 

En este tipo de blockchain cualquier participante puede unirse a la red sin restricciones, 

ademĂĄs los mismos pueden leer, escribir y verificar transacciones. La validez de las 
transacciones es establecida mediante un algoritmo de consenso y, por otra parte, 
aunque las transacciones pueden ser leĂ­das por cualquier participante, es posible 
ocultar informaciĂłn sensible, mediante un algoritmo de cifrado de informaciĂłn, como 
por ejemplo AES-256 [14]. 

Blockchain permisionadas 

Para este tipo de blockchain hay una autoridad central encargada de otorgar permisos 

de lectura, escritura y verificaciĂłn de transacciones a los distintos participantes. Dado 
que el permiso de escritura es otorgado solo a participantes de confianza, se hace 
posible que el algoritmo de consenso sea mĂĄs simple y eficiente. Al igual que en las 
blockchains no permisionadas, el acceso de lectura puede ser pĂşblico. 

2.1.3. Integridad 

Como se vio en la sección “2.1.1. Conceptos de blockchain” la tecnología blockchain 
utiliza bloques para agrupar la informaciĂłn que allĂ­ se agrega, asegurando la integridad 
mediante la utilizaciĂłn de hashes. Existen distintas implementaciones de la tecnologĂ­a 
blockchain, las cuales implementan distintos mecanismos para garantizar la integridad 
de sus datos. Es importante destacar que la dificultad de violar la integridad no es 
solamente debido a la modificaciĂłn de los datos y la generaciĂłn de un nuevo hash en 
base a esas modificaciones, esto Ăşltimo es necesario por lo mencionado respecto al 

proceso de construcciĂłn. Para que tenga probabilidades, los subsiguientes bloques 
tambiĂŠn deben ser modificados de la misma forma y esta tarea debe ser llevada a cabo 
en todos los nodos de la red. Es por este motivo que se dice que es incorruptible. 

Algunos de los mecanismos mĂĄs utilizados para esto son: proof of work [1], proof of 

stake [15] y proof of authority [16]. Los mismos se comentan a continuaciĂłn. 

Proof of work 

Proof of work o prueba de trabajo, es el mecanismo utilizado por Bitcoin [1], Litecoin 
[17], Namecoin [18], Dogecoin [19] en la actualidad, y tambiĂŠn fue utilizado por 

Ethereum [20] en su orĂ­gen. Este hace referencia a la generaciĂłn de un hash que sea 
difĂ­cil de producir, pero fĂĄcil de verificar. Esto implica que se genera un hash de un 
valor, o una transacciĂłn en este caso, con un determinado algoritmo, como por ejemplo 



19 

 

SHA-256 [21] y que tambiĂŠn se ajuste a ciertas condiciones. Lo que se busca es que el 
generador de ese hash tenga que dedicar gran parte de sus recursos en la generaciĂłn 
del mismo, para satisfacer la prueba de trabajo y que a su vez la generaciĂłn de uno de 
esos hashes no sea fĂĄcil de reproducir o modi";"""date"",""2019-05-24T13:34:35Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.4""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dcterms:created"",""2019-04-22T18:13:52Z""
""language"",""es""
""Last-Modified"",""2019-05-24T13:34:35Z""
""dcterms:modified"",""2019-05-24T13:34:35Z""
""dc:format"",""application/pdf; version=1.4""
""xmpMM:DocumentID"",""uuid:f6788e2b-f151-4555-af39-1e79aadbaf93""
""Last-Save-Date"",""2019-05-24T13:34:35Z""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2019-05-24T13:34:35Z""
""meta:save-date"",""2019-05-24T13:34:35Z""
""pdf:encrypted"",""false""
""xmp:CreateDate"",""2019-04-22T18:13:52Z""
""modified"",""2019-05-24T13:34:35Z""
""Content-Length"",""4517561""
""pdf:hasMarkedContent"",""false""
""Content-Type"",""application/pdf""
""xmp:ModifyDate"",""2019-05-24T10:34:35Z""
""xmp:MetadataDate"",""2019-05-24T10:34:35Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""pdf:producer"",""macOS Version 10.14.4 (Build 18E226) Quartz PDFContext""
""meta:creation-date"",""2019-04-22T18:13:52Z""
""created"",""2019-04-22T18:13:52Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""91""
""Creation-Date"",""2019-04-22T18:13:52Z""
""resourceName"",""tg-mereles-ortellado.pdf""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""261"",""2"",""2472"",""3"",""2925"",""2325"",""2698"",""2123"",""142"",""6"",""2821"",""2944"",""1340"",""2429"",""2030"",""2560"",""1594"",""2596"",""1554"",""2868"",""2642"",""2674"",""996"",""1292"",""2614"",""2918"",""1616"",""1493"",""1379"",""3101"",""3049"",""2527"",""2813"",""2637"",""2549"",""948"",""970"",""2718"",""2623"",""2525"",""1935"",""1423"",""2034"",""16633"",""2324"",""2970"",""1353"",""1043"",""2437"",""1442"",""2404"",""1769"",""1465"",""954"",""697"",""1747"",""430"",""857"",""2112"",""1339"",""2687"",""1738"",""2415"",""2855"",""222"",""6"",""1666"",""1543"",""1021"",""6"",""2937"",""2900"",""2525"",""2450"",""2760"",""2848"",""1235"",""6"",""2276"",""2437"",""399"",""6"",""1094"",""6"",""1215"",""484"",""287"",""137"",""2184"",""6"",""1946""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""producer"",""macOS Version 10.14.4 (Build 18E226) Quartz PDFContext""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""macOS Version 10.14.4 (Build 18E226) Quartz PDFContext""
""pdf:docinfo:created"",""2019-04-22T18:13:52Z""
";https://scholar.google.com/scholar?start=460&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094555-717;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Protecting Data Privacy for Permissioned Blockchains using Identity-Based Encryption;M Zhang, S Wang, P Zhang, L He, X Li… ; 2019 IEEE 3rd …, 2019  ieeexplore.ieee.org;;"… without random oracles, has short public parameters and has a tight security reduction …

https://www.ibm.com/blogs/blockchain/2018/02/one-nations- move-to-increase-food-safety-with-

blockchain/,2018 … In: Blakely, GR, Chaum, D. (eds.) CRYPTO 1984. LNCS, vol. 196, pp …";Cité 2 fois;;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/8717364/8728967/08729244.pdf?casa_token=6E3Yw8SFy68AAAAA:-34E9VkwiS6rK1T3bDZGiJBP5p0PixzFt4WYJXx7SXN5Y_uLVafIxlgOLg2I14bnE9sgnKErTX0;"
		Skip to Main Content


		
			
				
				

				

			

		


		
			
				
					
						








	
		
	

	







						

						





























	
	
		
	
	
		
			

		
	

	
	
	



						





	
	
		
			
				IEEE Account

					Change Username/Password
	Update Address


			

			
				Purchase Details

					Payment Options
	Order History
	View Purchased Documents


			

			
				Profile Information

					Communications Preferences
	Profession and Education
	Technical Interests


			

			
				Need Help?

					US & Canada: +1 800 678 4333
	Worldwide:  +1 732 981 0060

					
	Contact & Support


			

		

		
			
				
					
							About IEEE Xplore
	Contact Us
	Help
	Accessibility
	Terms of Use
	Nondiscrimination Policy
	Sitemap
	Privacy & Opting Out of Cookies


						
							A not-for-profit organization, IEEE is the world's largest technical professional organization dedicated to advancing technology for the benefit of humanity.
Š Copyright 2021 IEEE - All rights reserved. Use of this web site signifies your agreement to the terms and conditions.
						

					


					

				

				
			

		

	


	
	


						
						






		
		
		
		
		
		
		
		
		
		
		
		
		
			
				
			
			
			
			
		
		
		
		
		
		

			


			

			
			


		
 		
		
			 

						
						









































	

		
		

		
		
		

		
			
		
		
		

		

		
		


		

		
		
		
		
		
		
		
		
		
		
	
	


















		
		
			
				
					
					
								
					
								
			
				
					
					
								
					
								
			
				
					
						








 



					
					
								
			
				
					
					
								
			
				
					
					
								
					
								
			
				
					
					
								
					
								
			
				
					
					
								
					
								
			
				
					
					
								
					
								
			
				
					
					
								
					
								
			
				
					
					
								
					
								
			
		
	




























		
			
					
			
					
			
					
			
				
					








					
			
					
			
					
			
					
			
					
			
					
			
					
			
		
		
	





	
	
	
	
	
	
	


	
	
	

	

















					

				

			


			
				
			
		

	";"""og:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""twitter:title"",""Protecting Data Privacy for Permissioned Blockchains using Identity-Based Encryption""
""twitter:card"",""summary""
""Description"",""Blockchain is an emerging decentralized architecture and distributed public ledger technology underlying Bitcoin, and has recently attracted intensive attention""
""og:title"",""Protecting Data Privacy for Permissioned Blockchains using Identity-Based Encryption""
""resourceName"",""08729244.pdf""
""language"",""en""
""title"",""Protecting Data Privacy for Permissioned Blockchains using Identity-Based Encryption | IEEE Conference Publication | IEEE Xplore""
""og:description"",""Blockchain is an emerging decentralized architecture and distributed public ledger technology underlying Bitcoin, and has recently attracted intensive attention from governments, financial institutions and high-tech enterprises. It is believed that blockchain can improve efficiency, reduce costs and enhance data security, but it is still in the face of serious privacy issues which may hinder the wide application of blockchain. In this paper, We present a practical scheme by adding the Identity-Based encryption system, which effectively improves the data privacy for non-transaction applications. Analyses show that our proposal has a high security level which can prevent both disguise and passive attacks, and is functional, effective and practical in many applications for non-transactional scenarios.""
""twitter:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-UA-Compatible"",""IE=Edge""
""viewport"",""width=device-width, initial-scale=1.0""
""dc:title"",""Protecting Data Privacy for Permissioned Blockchains using Identity-Based Encryption | IEEE Conference Publication | IEEE Xplore""
""twitter:description"",""Blockchain is an emerging decentralized architecture and distributed public ledger technology underlying Bitcoin, and has recently attracted intensive attention from governments, financial institutions and high-tech enterprises. It is believed that blockchain can improve efficiency, reduce costs and enhance data security, but it is still in the face of serious privacy issues which may hinder the wide application of blockchain. In this paper, We present a practical scheme by adding the Identity-Based encryption system, which effectively improves the data privacy for non-transaction applications. Analyses show that our proposal has a high security level which can prevent both disguise and passive attacks, and is functional, effective and practical in many applications for non-transactional scenarios.""
""Content-Encoding"",""UTF-8""
""Content-Type-Hint"",""text/html; charset=utf-8""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=530&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094607-933;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[PDF][PDF] Signature Scheme from Trapdoor Functions.;Y Wang, M Xiao, Y Miao, W Liu, Q Huang ; J. Internet Serv. Inf. Secur., 2019  isyou.info;;"… Random oracles are practical: A paradigm for designing efficient protocols … The random oracle

methodology, revisited … of the 29th Annual International Cryptology Conference (CRYPTO'09),

Santa Barbara, California, USA, volume 5677 of Lecture Notes in Computer Science …";Cité 1 fois;;[PDF] isyou.info;http://isyou.info/jisis/vol9/no2/jisis-2019-vol9-no2-02.pdf;"
Signature Scheme from Trapdoor Functions

Yuanhao Wang, Meiyan Xiao, Ying Miao, Wenbo Liu, and Qiong Huang∗

South China Agricultural University, Guangzhou 510642, China
yuanhao.wang@stu.scau.edu.cn, maymayxiao@scau.edu.cn,
{scauym, wenboliu}@stu.scau.edu.cn, qhuang@scau.edu.cn

Abstract

Digital Signature is a basic cryptographic primitive. Security of signature scheme has been studied
for decades. How to build an efficient signature scheme based on simple and standard assumptions
without relying on random oracle heuristic has been an interesting problem. In this paper we provide
a solution to this problem from another angle. We present a generic construction of digital signature
schemes existentially unforgeable under chosen message attacks from adaptive trapdoor function,
which has shown its power in building other important cryptographic primitives. Furthermore, we
extend the generic construction and present a construction of secure digital signature schemes from
tag-based adaptive trapdoor function. Since there are many instantiations of (tag-based) adaptive
trapdoor function, our constructions could be instantiated based on simple assumptions like CDH
and RSA in the standard model.

Keywords: digital signature, standard model, trapdoor function

1 Introduction

As the analogy of handwritting signatures in the digital world, digital signatures are a basic public-key
cryptographic primitive which ensure the integrity of an electronic document. The party who generates
signatures, usually named the signer, could not deny the source of a signature if it passes the prescribed
verification algorithm. This is called non-repudiation, and is usually achieved by requiring that no one
is able to forge a signature w.r.t. the signer’s public key if it is not given the corresponding secret key.

How to build a secure signature scheme has been a hot research topic in the community. There are
two ingredients to consider. The first is to define the security of signature schemes. Goldwasser et al
[6] clarified the security of signature schemes into several levels. The de facto security definition is
existentially unforgeable under adaptive chosen message attacks (EUF-CMA), in which the adversary is
required to forge signatures on a new message after seeing many signatures on messages of its choice
adaptively. The other ingredient is how to construct a scheme with EUF-CMA security. The community
has put great efforts on the construction of secure signature schemes. To name a few, a well-known and
efficient signature scheme is modified from Schnorr’s identification scheme [15], which was proved by
Pointcheval et al. [12] to be secure based on the discrete logarithm (DL) assumption in the random oracle
model [1]. Boneh et al. [2] proposed another signature scheme with short signature representation, which
is based on bilinear pairing and is EUF-CMA secure based on Computational Diffie-Hellman (CDH)
assumption in the random oracle model. Although powerful and admitting many efficient constructions,
random oracle model does not necessarily guarantee security when the random oracles are replaced with
real-life hash functions [4]. Researchers have been devoted to the construction of signature schemes
secure without random oracles. Remarkably, Cramer and Shoup proposed a practically efficient signature
scheme based on Strong RSA assumption with EUF-CMA security in the standard model [5]. Waters

Journal of Internet Services and Information Security (JISIS), volume: 9, number: 2 (May 2019), pp. 31-41
∗Corresponding author: Room 208, College of Mathematics and Informatics, South China Agricultural University, 483

Wushan Road, Guangzhou 510642, P.R. China, Tel: +86-20-85285389

31



Signature Scheme from Trapdoor Functions Wang, Xiao, Miao, Liu and Huang

proposed the first signature scheme secure based on CDH assumption without random oracles [16],
which works in groups equipped with a bilinear pairing. The scheme has been widely studied and used
to build other primitives, for example verifiably encrypted signature [10], multi-signature [10], aggregate
signature [10] and etc. Hohenberger and Waters proposed to associate each signature with an index
representing the number of signatures that the signer has issued [7], and gave two new signature schemes
based on RSA assumption and CDH assumption in bilinear groups. However, the signer is stateful so
that it has to remember the signature index. Soon after that, the same authors enhanced their results [8],
and proposed a new method of constructing stateless signature schemes with security based on RSA and
CDH assumptions in the standard model. Brakerski and Kalai described in [3] an approach to building
EUF-CMA secure signature scheme from AMU-SCMA secure (cf. Def. 2.4) one, which abstracts the
construction of Hohenberger and Waters [8].

(Trapdoor Functions). Trapdoor functions (TDF) are a special class of one-way functions, which allow
the inversion of images with the knowledge of a trapdoor. A trapdoor function consists of three prob-
abilistic polynomial-time algorithms. The key generation algorithm outputs a key pair of the function,
an evaluation key ek and a trapdoor td. Given ek, the evaluation algorithm outputs the image y of an
input x. Without td, it is infeasible to find the correct pre-image of a given y; however, it is easy to do
so if given the knowledge of td. The first trapdoor in the literature was due to Rivest et al. [13]. Trap-
door functions are an important cryptographic tool, and have played a central role in the construction
of cryptographic primitives, especially for secure public key cryptosystems. For example, Peikert and
Waters introduced a variant of trapdoor functions, called lossy trapdoor functions (lossy TDF) [11], and
showed its power in the construction of chosen-ciphertext secure (CCA secure) public key encryption
schemes. Their construction, different from the non-interactive zero-knowledge (NIZK) proof approach,
is very efficient and its security is solely based on that of the underlying lossy TDF and all-but-one TDF
(ABO-TDF, a variant of lossy TDF) [11]. It has been shown that lossy TDF can be constructed based
on various number-theoretic assumptions, for example, Decisional Diffie-Hellman assumption (DDH),
Decisional Composite Residuosity assumption (DCR), Learning With Error assumption (LWE) and etc.
Rosen and Segev weakened the requirement on trapdoor functions, and proposed a black-box construc-
tion of public key encryption from a new notion called correlated product TDF (CP-TDF). They also
showed that CP-TDF is a potentially weaker primitive than lossy TDF.

1.1 Our Work

In this paper we provide a new construction of digital signature schemes. We show how to build a
EUF-CMA secure signature scheme from adaptive trapdoor function by presenting generic transforms
step by step. First we give a construction of AMU-CMA secure (Def. 2.4) signature from adaptive one-
way TDF (Def. 2.5). Then we show how to transform AMU-CMA security to SMU-CMA security. We
complete the construction of EUF-CMA secure signature by giving a transform from SMU-CMA security
to EUF-CMA security, which makes use of a one-time signature. As an extension of our transform, we
show how to build a EUF-CMA secure signature scheme from tag-based trapdoor functions.

Since adaptive trapdoor functions could be instantiated based on various number-theoretic assump-
tions, as well as the underlying one-time signature, in turn we can obtain EUF-CMA secure signatures
based on these assumptions as well by applying our transform.

1.2 Paper Organization

In Sec. 2 we review some basic notions of digital signature and trapdoor functions. We provide the
generic constructions of EUF-CMA secure signature schemes from adaptive trapdoor functions and tag-
based adaptive trapdoor functions in Sec. 3 and Sec. 4, respectively. Finally we conclude the paper in

32



Signature Scheme from Trapdoor Functions Wang, Xiao, Miao, Liu and Huang

Sec. 6.

2 Backgrounds

2.1 Digital Signature

Definition 2.1 (Signature). A digital signature scheme consists of the following (probabilistic) polynomial-
time algorithms.

• Kg: On input 1k, output a public/private key pair (Pk,Sk).

• Sig: On input Sk and a message m ∈M to be signed, output a signature σ .

• Ver: On input Pk, m∈M and σ , output 1 if σ is a valid signature on m under Pk, and 0 otherwise.

Security of Signature Scheme: The de facto security requirement of a signature scheme is existential
unforgeability under chosen-message attacks (EUF-CMA for short). For any probabilistic polynomial-
time algorithm A , consider its advantage defined as below:

Adveuf-cma
A (k) def

= Pr[Ver(Pk,m∗,σ∗) = 1∧m∗ 6∈Q | (Pk,Sk)← Kg(1k);(m∗,σ∗)←A O(Sk)(Pk)],

where O(Sk) is the signing oracle which takes as input a message m and outputs σ ← Sig(Sk,m), and Q
is the set of messages that A issued to O(Sk).

Definition 2.2 (EUF-CMA Security). A signature scheme is EUF-CMA secure if for any probabilistic
polynomial-time adversary A , Adveuf-cma

A (k) is negligible.

A weak variant of EUF-CMA security is called selective-message unforgeability under chosen-
message attacks (SMU-CMA for short). For any probabilistic polynomial-time algorithm A = (A1,A2),
consider its advantage defined as below:

Advsmu-cma
A (k) def

= Pr[Ver(Pk,m∗,σ∗) = 1∧m∗ 6∈Q |

(m∗,st)←A1(1k);(Pk,Sk)← Kg(1k);σ
∗←A

O(Sk)
2 (Pk,st)],

where st is the state of A .

Definition 2.3 (SMU-CMA Security). A signature scheme is SMU-CMA secure if for any probabilistic
polynomial-time adversary A , Advsmu-cma

A (k) is negligible.

Another even weaker but still useful security definition is a-priori-message unforgeability under
chosen-message attacks (AMU-CMA for short). For any probabilistic polynomial-time algorithm A ,
consider its advantage defined as below:

Advamu-cma
A (k) def

= Pr[Ver(Pk,m∗,σ∗) = 1∧m∗ 6∈Q |
m∗←M ;(Pk,Sk)← Kg(1k);σ

∗←A O(Sk)(Pk,m∗)].

Definition 2.4 (AMU-CMA Security). A signature scheme is AMU-CMA secure if for any probabilistic
polynomial-time adversary A , Advamu-cma

A (k) is negligible.

33



Signature Scheme from Trapdoor Functions Wang, Xiao, Miao, Liu and Huang

2.2 Adaptive Trapdoor Functions

Recall that a trapdoor function (TDF) is a triple of (probabilistic) polynomial-time algorithms, where
Tdg takes as input 1k and generates an evaluation/trapdoor key pair (ek, td)← Tdg(1k), F(ek, ·) imple-
ments a function fek(·) over {0,1}k and F−1(td, ·) implements its inverse f−1

ek (¡). We require TDFs to
be injective. Briefly, a TDF is adaptive if it remains one-way after revealing the pre-images of points
chosen by the adversary adaptively. Let A be any probabilistic polynomial-time inverter. Consider its
advantage defined as below:

AdvaowA (k) def
= Pr[x′ = x | (ek, td)← Tdg(1k);x←{0,1}k;y← F(ek,x);x′←A F−1(td,·)(ek,y)],

where A is prohibited from querying y to F−1(td, ·).

Definition 2.5 (Adaptive One-wayness [9]). A TDF is adaptive one-way if for any probabilistic polynomial-
time adversary A , AdvaowA (k) is negligible.

A TDF with adaptive one-wayness is called Adaptive Trapdoor Function (ATDF).

We also consider tag-based trapdoor function. Let TDFtag = (Tdgtag,Ftag,F
−1
tag) be a tag-based TDF

with associated tag space TagSp(k), where Tdgtag is probabilistic and on input 1k generates an evalua-
tion/trapdoor key pair (ek, td)← Tdgtag(1k). Besides, for every t ∈ TagSp(k), Ftag(ek, t, ·) implements
a function fek,t(·) over {0,1}k and F−1

tag(td, t, ·) implements its inverse f−1
td,t(¡).

Definition 2.6 (Tag-based Adaptive One-wayness [9]). A tag-based TDF is tag-based adaptively one-
way if for any probabilistic polynomial-time adversary A = (A1,A2), its advantage defined as below is
negligible:

Advtb-aow
A (k) def

= Pr

[
x′ = x

t←A1(1k);(ek, td)← Tdgtag(1k);x←{0,1}k

y← Ftag(ek, t,x);x′←A
F−1

tag(td,¡,¡)
2 (ek, t,y)

]
,

where A is prohibited from querying y to F−1
tag(td, ¡, ¡).

3 Signature Scheme from Adaptive Trapdoor Functions

3.1 A Warmup

As a warmup, let us consider the following construction. Let {0,1}k be the message space to be signed
and TDF= (Tdg,F,F−1) be an adaptive trapdoor function over {0,1}k. The signature scheme works as
below.

Key Generation: On input 1k, run (ek, td)← Tdg(1k). Set Pk := ek and Sk := td. Return (Pk,Sk).

Signing: On input Sk= td and m ∈ {0,1}k, return σ ← F−1(td,m).

Verification: On input Pk= ek, m ∈ {0,1}k and σ ∈ {0,1}k, check if

F(ek,σ) = m. (1)

Output 1 if the equation holds, and 0 otherwise.

Observe that the definition of adaptive one-wayness of TDF (w.r.t. Definition 2.5) shares a close
similarity with that of AMU-CMA security (w.r.t. Definition 2.4) of signature schemes. Therefore, we
have the following theorem directly.

34



Signature Scheme from Trapdoor Functions Wang, Xiao, Miao, Liu and Huang

Theorem 3.1. If TDF is adaptive one-way, the signature scheme above is AMU-CMA secure.

The signature scheme supports to sign messages of fixed-length. To extend the message space to
include arbitrarily long strings, one may consider to make use of a collision-resistant hash function
H : {0,1}∗→ {0,1}k, and modify the scheme by replacing every occurrence of message m with its hash
H(m). Indeed, this is the common practice in the design of signature schemes. However, in contrary to
signature schemes with standard EUF-CMA security, the well-known ‘hash-then-sign’ paradigm does not
work for signature schemes with AMU-CMA security, i.e. we could not prove the resulting scheme to be
AMU-CMA secure. The difficulty is in that after receiving the target image y (as well as the evaluation
key ek), we do not know how to connect it with some ‘known’ message m∗ (that will be given to the
forger) so that H(m∗) = y, except by modeling H as a random oracle, by which we cannot achieve the
desired objective of this work.

Hence, in the following, we overcome the difficulty and propose a new signature scheme based on
TDF, which supports to sign arbitrarily long messages. We show its SMU-CMA (instead of AMU-CMA)
security if the given TDF is adaptive one-way.

3.2 The Basic Scheme: an Efficient Method to Achieve SMU-CMA Security from TDF

To overcome the difficulty aforementioned, we choose to separate the image y (to be inverted under F)
into two parts. One is the hash of message m and the other is another image Îą which is set as part
of the public key. Every signature is set to be the inversion of the combination of the message’s hash
and α . After receiving the target image y∗, we can connect it with the challenge message m∗ by setting
α := y∗⊕H(m∗) and adding α to the public key. Formally, our signature scheme works as follows.

Let TDF= (Tdg,F,F−1) be an adaptive trapdoor function over {0,1}k, and H : {0,1}∗→{0,1}k be
a collision-resistant hash function. We construct a signature scheme SIG = (Kg,Sig,Ver) from TDF as
follows.

Key Generation: On input 1k, run (ek, td)← Tdg(1k) and select at random α ← {0,1}k. Set Pk :=
(ek,Îą) and Sk := td. Return (Pk,Sk).

Signing: On input Sk= td and m ∈ {0,1}∗, compute σ ← F−1(td,H(m)⊕α).

Verification: On input Pk= (ek,α), m ∈ {0,1}∗ and σ ∈ {0,1}k, check if

F(ek,σ) = H(m)⊕α. (2)

Output 1 if the equation holds, and 0 otherwise.

Immediately, we have the following theorem.

Theorem 3.2. If TDF is adaptive one-way and H is collision-resistant, the signature scheme SIG con-
structed above is SMU-CMA secure.

Proof. Let G0 be the original SMU-CMA security game as defined in Def. 2.4. We first modify G0
so that if there exists any two message m,m′ during the game satisfying that H(m) = H(m′), the game
aborts. Denote by G1 the new game, and by Advsmu-cma

A ,i (k) the advantage of an adversary A in game Gi.
Obviously, we have the following claim:

Claim 3.3. If H is collision-resistant, Advsmu-cma
A ,0 (k)−Advsmu-cma

A ,1 (k) is negligible in k.

35



Signature Scheme from Trapdoor Functions Wang, Xiao, Miao, Liu and Huang

Next we consider the adversary’s advantage in game G1. Let F be an SMU-CMA adversary against
SIG under game G1, in which we omit the case where the game aborts. We build another algorithm A
to break the adaptive one-wayness of TDF.

Given (ek,y) from its challenger, A invokes F on input 1k and obtains a message m∗ on which F
intends to forge a signature. It then sets α← H(m∗)⊕y, and invokes F on input Pk := (ek,α). Note that
Îą looks uniform to F due to the randomness of y.

After receiving a signing query mi from F , A computes m′i← H(mi)⊕α , sends m′i to its inversion
oracle and obtains the inversion xi so that

F(ek,xi) = m′i.

A then returns σi := xi as the signature on mi to F .
Finally, F outputs its forgery σ∗ on m∗ w.r.t. Pk. We have that

F(ek,σ∗) = H(m∗)⊕α = H(m∗)⊕ (H(m∗)⊕ y) = y.

A simply outputs σ∗, which is a correct inversion of y as long as the forgery of F is valid.

Remark. One may observe that the definition of adaptive one-way security of TDF shares a close
similarity with that of SMU-CMA security of signature schemes, and would consider a simpler variant
of our proposal above, in which a signature on m is simply the inversion of H(m) under F. It seems that
if the TDF is adaptive one-way, the resulting signature scheme would be AMU-CMA (not SMU-CMA)
secure. However, we could not make a formal proof. The difficulty is in that after receiving the target
image y (and the evaluation key ek), we do not have a way to connect it with some ‘known’ message m∗

so that H(m∗) = y, except by modeling H as a random oracle.

3.3 From SMU-CMA Security to EUF-CMA Security

In this part we give a transform that given a signature scheme S= (Kg,Sig,Ver) that is SMU-CMA secure
and has message space {0,1}≤`, produces a scheme S′ = (Kg′,Sig′,Ver′) that is EUF-CMA secure. Let
OTS = (Kg,Sig,Ver) be a one-time signature scheme with space of verification key being {0,1}`. The
transform works as follows.

• Kg′(1k). Run (Pk,Sk)← S.Kg(1k). Return (Pk′,Sk′) := (Pk,Sk).

• Sig′(Sk′,m). Recall that Sk′ = Sk. Generate a one-time key pair (otvk,otsk)← OTS.Kg(1k).
Then for 1 ≤ i ≤ `, compute σi ← S.Sig(Sk,otvk≤i). Finally compute δ ← OTS.Sig(otsk,m).
Return σ ′ = ({σi}`i=1,δ ,otvk).

• Ver′(Pk′,m,σ ′). Recall that Pk′ = Pk and σ ′ = ({σi}`i=1,δ ,otvk). Output 1 if for all 1 ≤ i ≤ `,
S.Ver(Pk,otvk≤i,σi) outputs 1 and OTS.Ver(otvk,m,δ ) outputs 1 as well. Otherwise, output 0.

Theorem 3.4. If the underlying signature scheme S is SMU-CMA secure and OTS is one-time secure,
the resulting scheme S′ is EUF-CMA secure.

Proof. Let G0 be the original EUF-CMA security game as defined in Def. 2.4. Let σ∗=({σ∗i }`i=1,δ
∗,otvk∗)

be the signature output by the adversary, and σ ′( j) = ({σ ( j)
i }`i=1,δ

( j),otvk( j)) be the answer to the ad-
versary’s j-th signing query m( j).

We first modify G0 so that if there exists some 1 ≤ i ≤ q (where q is the number of signing queries
issued by the adversary), otvk∗ = otvk( j), the game aborts. Denote by G1 the new game, and by
Adveuf-cma

A ,i (k) the advantage of an adversary A in game Gi. Via a standard argument we have that

36



Signature Scheme from Trapdoor Functions Wang, Xiao, Miao, Liu and Huang

Claim 3.5. If OTS is one-time secure, Adveuf-cma
A ,0 (k)−Adveuf-cma

A ,1 (k) is negligible in k.

Next we consider the adversary’s advantage in game G1, in which we omit for simplicity the case
where G1 aborts. Let F ′ be an EUF-CMA adversary against S′ under G1. We construct another algorithm
F to break the SMU-CMA security of S. It works as below.

First of all, F generates q key pairs for the one-time signature scheme, denoted by (otvk( j),otsk( j))
for 1 ≤ i ≤ q, which will be used to answer the q signing queries submitted by F ′. It then samples at
random (i∗, j∗)← [`]× [q] and sets m̂∗← otvk

( j∗)
≤i∗ ⊕ei∗ , where ei∗ = 0i∗−11. F sends m̂∗ to its challenger

as the selective message to be forged in the SMU-CMA game.
After receiving the j-th signing query m( j), F sends otvk

( j)
≤1, · · · ,otvk

( j)
≤` to its signing oracle for

signatures, and is returned σ
( j)
1 , ¡ ¡ ¡ ,σ ( j)

` . It then computes δ ( j) ← OTS.Sig(otsk( j),m( j)), and returns
σ ′( j) := ({σ ( j)

i }`i=1,δ
( j),otvk( j)) to F ′. It is readily seen that the returned signature is identically dis-

tributed as in a real attack.
Finally, F ′ outputs its forgery (m∗,σ∗) = (m∗,({σ∗i }`i=1,δ

∗,otvk∗)). F returns σ̂∗ := σ∗i∗ as its
forgery on the selective message m̂∗. Suppose that F ′ is successful in forging. We have that

∀1≤ i≤ `, S.Ver(Pk,otvk∗≤i,σ
∗
i ) = 1, and OTS.Ver(otvk∗,m∗,δ ∗) = 1.

Since otvk∗ 6∈ {otvk( j)} j∈[q], there must exist an i′ ∈ [`] such that

otvk∗≤i′−1 ∈ {otvk
( j)
≤i′−1} j∈[q] but otvk∗≤i′ 6∈ {otvk

( j)
≤i′} j∈[q].

As the pair (i∗, j∗) was selected at random and the view of F ′ is independent of the pair, it holds that

Pr
[
(i∗ = i′)∧ (otvk∗≤i′−1 = otvk

( j∗)
≤i′−1)

]
≥ 1

`q
.

Suppose it is indeed the case where i∗ = i′ and otvk∗≤i′−1 = otvk
( j∗)
≤i′−1. Since otvk∗≤i∗ 6= otvk

( j∗)
≤i∗ , we have

otvk∗≤i∗ = otvk
( j∗)
≤i∗ ⊕ ei∗ = m̂∗.

That is, otvk∗≤i∗ is the selective message that F was committed to at the onset of the game. As shown
above, the signature σ̂∗ output by F could pass the verification of S . Namely, it holds that

S.Ver(Pk, m̂∗, σ̂∗) = 1.

Furthermore, the fact that otvk∗≤i∗ 6∈ {otvk
( j)
≤i∗} j∈[q] means that m̂∗ 6∈ {otvk( j)

≤i }(i, j)∈[`]×[q]. That is, F did
not ask its signing oracle for a signature on m̂∗. Therefore, F wins the SMU-CMA game.

Remark. Brakerski et al.’s construction [3] goes in three steps. First, they obtain SMU-SCMA security
from AMU-SCMA security, then obtain EUF-SCMA security from SMU-SCMA security, and finally
obtain EUF-CMA security from EUF-SCMA security. While in this work we first show how to build a
SMU-CMA secure signature scheme from adaptive trapdoor functions, in which the adversary could issue
signing queries adaptively instead of statically, and then show how to transform SMU-CMA security to
EUF-CMA security.

37



Signature Scheme from Trapdoor Functions Wang, Xiao, Miao, Liu and Huang

4 Signature from Tag-based Adaptive Trapdoor Functions

Let TDFtag = (Tdgtag,Ftag,F
−1
tag) be a tag-based TDF with associated tag space TagSp(k) and range

Range(Ftag). We construct a signature scheme SIG= (Kg,Sig,Ver) from TDFtag as follows.

Key Generation: On input 1k, run (ek, td)← Tdgtag(1k) and select a collision-resistant hash function
H : {0,1}∗→ TagSp(k). Select at random y← Range(Ftag) and set Pk := (ek,y,H) and Sk := td.
Return (Pk,Sk).

Signing: On input Sk= td and m ∈ {0,1}∗, compute t← H(m) and x← F−1
tag(td, t,y). Return σ = x.

Verification: On input Pk= (ek,y,H), m ∈ {0,1}∗ and σ = x, compute t← H(m) and check if

Ftag(ek, t,x) = y. (3)

Output 1 if the equation holds, and 0 otherwise.

Theorem 4.1. If TDFtag is tag-based adaptive one-way and H is collision-resistant, the resulting signa-
ture scheme above is SMU-CMA secure.

Proof. Let G0 be the original SMU-CMA security game as defined in Def. 2.4. We first modify G0
so that if there exists any two message m,m′ during the game satisfying that H(m) = H(m′), the game
aborts. Denote by G1 the new game, and by Advsmu-cma

A ,i (k) the advantage of an adversary A in game Gi.
Obviously, we have the following claim:

Claim 4.2. If H is collision-resistant, Advsmu-cma
A ,0 (k)−Advsmu-cma

A ,1 (k) is negligible in k.

Next we consider the adversary’s advantage in game G1. Let F be an SMU-CMA adversary against
SIG under game G1, in which we omit the case where the game aborts. We build another algorithm A
to break the tag-based adaptive one-wayness of TDFtag.

Given the input 1k, A invokes F on input 1k and obtains m∗ from F . It then sets t∗← H(m∗) and
submits t∗ to its own challenger. After receiving (ek,y) from the challenger, A sets Pk := (ek,y), and
gives it to the adversary.

After receiving the j-th signing query m j, A computes t j ← H(m j), sends (t j,y) to its inversion
oracle, and obtains the pre-image x j so that

Ftag(ek, t j,x j) = y.

A returns σ j := x j to the adversary.
Finally, F outputs its forgery σ∗ on message m∗. A simply outputs x∗ := σ∗ as the inversion of y

under the selective tag t∗. Suppose that F succeeds in the SMU-CMA game. We have that

Ftag(ek, t∗,x∗) = y∗,

which means that x∗ is the correct inversion. Furthermore, F did not ask for a signature on m∗, nor did
A ask the inversion of y under the tag t∗. Therefore, A wins in the tag-based adaptive one-wayness
game.

Full Security. The signature scheme above is SMU-CMA secure. To obtain the standard EUF-CMA
security, we could apply the transform presented in Sec. 3.3.

38



Signature Scheme from Trapdoor Functions Wang, Xiao, Miao, Liu and Huang

5 Discussions

Kiltz et al. [9] showed that adaptive trapdoor functions can be constructed from correlated-product
trapdoor functions [14], which in turn can be constructed from lossy trapdoor functions [11]. There are
many concrete and efficient constructions of lossy trapdoor functions, based on DDH, DCR and SIS
assumptions, respectively. Furthermore, as demonstrated in [9], tag-based trapdoor functions could be
constructed from instance-independent RSA assumption. Therefore, we could obtain signature schemes
based on a bunch of simple assumptions without random oracles, which enriches the research of secure
digital signatures from another angle.

On the other hand, Kiltz et al. showed the power of adaptive trapdoor function in the construction of
CCA-secure public key encryption schemes [9], while we showed its usage in constructing existentially
unforgeable digital signature schemes, further demonstrating the power of adaptive trapdoor functions.

6 Conclusion

In this paper we provided another solution to the construction of EUF-CMA secure digital signature
schemes in the standard model. We present a generic transform from SMU-CMA secure signature scheme
to EUF-CMA secure one without resorting to the random oracle model, which makes use of one-time
signature and the ‘prefix’ method. As an extension of the transform, we also showed how to build a
EUF-CMA secure signature scheme from tag-based adaptive trapdoor functions. Our construction is
generic so that it can be instantiated based on various number-theoretic assumptions, for example, RSA
assumption, CDH assumption and etc.

Acknowledgments

This work was supported by the National Natural Science Foundation of China (No. 61872152, 61472146).

References
[1] M. Bellare and P. Rogaway. Random oracles are practical: A paradigm for designing efficient protocols. In

Proc. of the 1st ACM Conference on Computer and Communications Security (CCS’93), Fairfax, Virginia,
USA, pages 62–73. ACM, November 1993.

[2] D. Boneh, B. Lynn, and H. Shacham. Short signatures from the weil pairing. Journal of Cryptology,
17(4):297–319, September 2004.

[3] Z. Brakerski and Y. T. Kalai. A framework for efficient signatures, ring signatures and identity based encryp-
tion in the standard model. IACR Cryptology ePrint Archive, 2010:86, 2010.

[4] R. Canetti, O. Goldreich, and S. Halevi. The random oracle methodology, revisited. In Proc. of the 30th
Annual ACM Symposium on the Theory of Computing (STOC’98), Dallas, Texas, USA, pages 209–218. ACM,
May 1998.

[5] R. Cramer and V. Shoup. Signature schemes based on the strong rsa assumption. In Proc. of the 6th ACM
Conference on Computer and Communications Security (CCS’99), Singapore, pages 46–51. ACM, Novem-
ber 1999.

[6] S. Goldwasser, S. Micali, and R. Rivest. A digital signature scheme secure against adaptive chosen-message
attack. SIAM Journal on Computing, 17(2):281–308, 1988.

[7] S. Hohenberger and B. Waters. Realizing hash-and-sign signatures under standard assumptions. In Proc.
of the 28th Annual International Conference on the Theory and Applications of Cryptographic Techniques
(EUROCRYPT’09), Cologne, Germany, volume 5479 of Lecture Notes in Computer Science, pages 333–350.
Springer, April 2009.

39



Signature Scheme from Trapdoor Functions Wang, Xiao, Miao, Liu and Huang

[8] S. Hohenberger and B. Waters. Short and stateless signatures from the RSA assumption. In Proc. of the 29th
Annual International Cryptology Conference (CRYPTO’09), Santa Barbara, California, USA, volume 5677
of Lecture Notes in Computer Science, pages 654–670. Springer, August 2009.

[9] E. Kiltz, P. Mohassel, and A. O’Neill. Adaptive trapdoor functions and chosen-ciphertext security. In Proc.
of the 29th Annual International Conference on the Theory and Applications of Cryptographic Techniques
(EUROCRYPT’10), Monaco / French Riviera, volume 6110 of Lecture Notes in Computer Science, pages
673–692. Springer, May-June 2010.

[10] S. Lu, R. Ostrovsky, A. Sahai, H. Shacham, and B. Waters. Sequential aggregate signatures and multisig-
natures without random oracles. In Proc. of the 25th Annual International Conference on the Theory and
Applications of Cryptographic Techniques (EUROCRYPT’06), St. Petersburg, Russia, volume 4004 of Lec-
ture Notes in Computer Science, pages 465–485. Springer, May-June 2006.

[11] C. Peikert and B. Waters. Lossy trapdoor functions and their applications. In Proc. of the 40th Annual ACM
Symposium on Theory of Computing (STOC’08), Victoria, British Columbia, Canada, pages 187–196. ACM,
May 2008.

[12] D. Pointcheval and J. Stern. Security arguments for digital signatures and blind signatures. J. Cryptology,
13(3):361–396, 2000.

[13] R. Rivest, A. Shamir, and L. M. Adleman. A method for obtaining digital signatures and public-key cryp-
tosystems. Communications of ACM, 21(2):120–126, 1978.

[14] A. Rosen and G. Segev. Chosen-ciphertext security via correlated products. In Proc. of the 6th Theory of
Cryptography Conference (TCC’09), San Francisco, CA, USA, volume 5444 of Lecture Notes in Computer
Science, pages 419–436. Springer, March 2009.

[15] C. Schnorr. Efficient signature generation by smart cards. J. Cryptology, 4(3):161–174, 1991.
[16] B. Waters. Efficient identity-based encryption without random oracles. In Proc. of the 24th Annual Interna-

tional Conference on the Theory and Applications of Cryptographic Techniques (EUROCRYPT’05), Aarhus,
Denmark, volume 3494 of Lecture Notes in Computer Science, pages 114–127. Springer, May 2005.

——————————————————————————

Author Biography

Yuanhao Wang received the B.S. degree in Network Engineering from South China
Agricultural University in 2017. He is currently pursuing the M.S. degree at Col-
lege of Mathematics and Informatics, South China Agricultural University. His re-
search interests include information security, digital signature and searchable encryp-
tion.

Meiyan Xiao received her master’s degree from South China Agricultural Univer-
sity, Guangzhou, China, in 2009. Currently, she is a teacher and also a PhD student at
College of Mathematics and Informatics, South China Agricultural University. Her re-
search interests include cyberspace security, public key cryptography and blockchain
security.

40



Signature Scheme from Trapdoor Functions Wang, Xiao, Miao, Liu and Huang

Ying Miao received her B.S. degree in Network Engineering from South China Agri-
cultural University in 2018. Currently, she is a master student at College of Mathe-
matics and Informatics, South China Agricultural University. Her research interests
include cryptography and blockchain.

Wenbo Liu received the B.S. degree from College of Computer Science and En-
gineering, Cangzhou Normal University in 2018. Currently, he is a M.S. degree
student at College of Mathematics and Informatics, South China Agricultural Uni-
versity. His research interests include public key encryption and functional encryp-
tion.

Qiong Huang got his PhD degree from City University of Hong Kong in 2010. Now
he is a professor at South China Agricultural University. His research interests include
cryptography and information security, in particular, cryptographic protocols design
and analysis.

";"""date"",""2019-06-05T03:46:44Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2019-06-05T03:46:44Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is MiKTeX-pdfTeX 2.9.6668 (1.40.19)""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2019-06-05T03:46:44Z""
""created"",""2019-06-05T03:46:44Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-06-05T03:46:44Z""
""resourceName"",""jisis-2019-vol9-no2-02.pdf""
""Author"",""""
""producer"",""pdfTeX-1.40.19""
""pdf:docinfo:producer"",""pdfTeX-1.40.19""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""3"",""6"",""2"",""29"",""35"",""2"",""0"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2019-06-05T03:46:44Z""
""Last-Modified"",""2019-06-05T03:46:44Z""
""dcterms:modified"",""2019-06-05T03:46:44Z""
""title"",""""
""Last-Save-Date"",""2019-06-05T03:46:44Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2019-06-05T03:46:44Z""
""meta:save-date"",""2019-06-05T03:46:44Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is MiKTeX-pdfTeX 2.9.6668 (1.40.19)""
""Content-Length"",""1831047""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""11""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""3169"",""3541"",""1812"",""2189"",""2533"",""2565"",""2313"",""2131"",""2820"",""2576"",""815""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-06-05T03:46:44Z""
";https://scholar.google.com/scholar?start=750&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094642-1089;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[PDF][PDF] Ethereum Transactions and Smart Contracts among Secure Identities.;F Buccafurri, G Lax, L Musarella, A Russo ; DLT@ ITASEC, 2019  researchgate.net;;"… every line of the code: we assume the reader is familiar with Solidity and Oraclize, which is the

leading oracle service for … Thanks to the assurance of authenticity and uniqueness of transactions,

blockchain starts to become the technical core of cryptocurrency, access control …";Cité 8 fois;Les 4 versions;[PDF] researchgate.net;https://www.researchgate.net/profile/Lorenzo_Musarella/publication/331981235_Ethereum_Transaction_and_Smart_Contracts_among_Secure_Identities/links/5c98b33f92851cf0ae9620cf/Ethereum-Transaction-and-Smart-Contracts-among-Secure-Identities.pdf;;;https://scholar.google.com/scholar?start=900&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094633-1049;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[PDF][PDF] Hyperledger-based Data Provenance in Distributed Computing Environments;AP Demichev, AP Kryukov, NV Prikhod'ko… ; … ??? ? ??????, 2019  russianscdays.org;;"… that do not require resource-consuming and slow “proof-of-work” mechanism which is intrinsic

for cryptocurrency blockchain networks [9 … history with the history recorded in a blockchain is

outside the scope of the blockchain technology (the so-called the Oracle Problem, see …";Autres articles;;[PDF] russianscdays.org;https://russianscdays.org/files/2019/pdf/24.pdf;"
Hyperledger-based Data Provenance in Distributed

Computing Environments∗

A.P. Demichev1, A.P. Kryukov1, N.V. Prikhod’ko2, J.Yu. Dubenskaya1, E.Yu. Fedotova1

and S.P. Polyakov1

1Skobeltsyn Institute of Nuclear Physics, Lomonosov Moscow State University, Moscow,
Russia,

2Yaroslav-the-Wise Novgorod State University, Velikiy Novgorod, Russia

A new approach to managing provenance metadata and data access rights in a dis-
tributed environment is proposed. It is based on the integration of blockchain tech-
nology, smart contracts and provenance metadata driven data management. We also
suggest a new method for delegation of rights from a user or service to another service
within distributed computing systems. The implementation of the proposed approach,
entitled ProvHL, is based on the permissioned blockchains and on the Hyperledger
Fabric blockchain platform in conjunction with Hyperledger Composer.

Keywords: distributed storage, provenance metadata, blockchain, smart contracts,
access rights, delegation of rights, Hyperledger Fabric.

1. Introduction

When implementing large-scale scientific or business projects related to storing and process-
ing large amounts of data and involving participants from different administrative domains, the
best solution may be that the project participants combine their local storage resources into a
single distributed pool and, if necessary, rent additional cloud storage resources, possibly from
several providers. Indeed, in existing centralized solutions, the main functions are performed
by data centers that collect and store (possibly with subsequent processing) data from periph-
eral (user) nodes of the network. Therefore, in this case, the need to store big data in any
scientific or production area leads to the necessity to build large and very expensive specialized
data centers. At the initial stage of implementing a project, it is very problematic both to
find sufficient funding for the establishment of such a center, and to estimate in advance the
necessary storage capacity for a sufficiently long period of time. The approach based on the
peer-to-peer (P2P) paradigm of storage networks (see the review [1] and references therein) is
totally opposite to the completely centralized approach. In this case, data storage services are
evenly distributed among all network participants, which provides a natural load balancing, the
absence of bottlenecks and points of failure. Special mechanisms of coding, fragmentation and
distribution of information over nodes can provide privacy and reliability of the system even
in case of failure of some storage nodes. However, a significant problem with this approach
is to ensure a stable pool of peers, that is storage resource providers, especially at the initial
stage of development of such a network. In other words, before such a P2P-based storage can
work stably, it will require significant technical, organizational and time costs from its orga-
nizers in the absence of a result guarantee, that is, a workable network with sufficient storage
capacity. Therefore, in many cases of large-scale projects, the above-mentioned solution that is
intermediate between the fully centralized and fully decentralized (P2P) solutions may be opti-
mal. In science, examples of such large projects are the Large Hadron Collider (CERN, Geneva;
https://home.cern/science/accelerators/large-hadron-collider) and experiments in astrophysics
(see e.g., [2]).

In the case of this intermediate approach, the problem arises of combining all local storages
and data in them into a unified storage system in a dynamically changing environment, as well

∗This work was funded by the Russian Science Foundation (grant No. 18-11-00075).

Суперкомпьютерные дни в России 2019 // Russian Supercomputing Days 2019 // RussianSCDays.org

24



as ensuring the implementation of mutual access policies to the data of the parties involved.
This implies the existence of methods for decentralized management of data access rights in
such a dynamically changing environment, ensuring consensus among the parties involved on
the content and order of data operations and ensuring reliable, immutable recording of proven
operations history, that is, provenance metadata. The latter are necessary for data storage and
usage consistency, as well as for consideration and resolving possible conflicts among project
participants or with the storage providers. In other words, it is necessary to provide tools to
support the implementation of business processes of storing and exchanging data in a distributed
environment and in the presence of administratively unrelated or loosely related organizations
involved in joint projects, or simply sharing data under certain conditions.

In this work, we propose an approach to solving this problem based on the use of blockchain
technology and smart contracts within the Hyperledger platform (https://www.hyperledger.org)
[3]. The basic principles of operation, architecture and algorithms of the ProvHL system (Prove-
nance HyperLedger) for managing provenance metadata and data access rights in distributed
storages are developed. At present, a testbed has been created in SINP MSU, on which a pre-
liminary version of the ProvHL prototype is deployed for elaboration of these principles and
algorithms. The paper is organized as follows. In Section 2 we describe business processes of
data storage and sharing in distributed environments. In Sections 3 and 4 the Hyperledger
blockchain platform and distributed consensus algorithms are presented, respectively. Section 5
is devoted to presentation of the ProvHL system and Section 6 describes delegation of rights in
the framework of this system. In Section 7 a short review of related works is given and, finally,
Section 8 contains conclusions.

2. Business Processes of Data Storage and Sharing in Distributed

Environments

The basic scenario of using the proposed system assumes that a virtual organization (VO) is
formed for the joint implementation of a certain project. VO includes several real organizations
which include, in turn, data providers, users and data handlers affiliated with them. It is assumed
that the implementation of such a project requires the use of a distributed data storage. This
distributed storage can be formed by renting multiple cloud storages, as well as integrating the
own storage resources of the organizations that form the VO. Thus, the hardware and software
basis of the business environment in this case is formed by a set of storages (possibly of different
types, e.g., cloud storages, file servers, tape storages, etc.), each of which can be managed by
its own data management system (DMS). For certainty, it is further assumed that the data is
stored as files, i.e. the file is a unit of data. Generally speaking, several VOs can coexist; the
storages with which they interact can form partially overlapping sets.

In such an environment, an immutable and distributed (as the environment itself) registry
and a consensus on the order of data operations are needed to resolve possible conflicts between
the VO/project participants related to the use of the data. In other words, to resolve possible
conflicts, one needs an undistorted history of data use by VO members. Conflicts may be
caused by priority issues upon obtaining results of data processing, use of results (including
funding issues), etc. A simple example of the causes of such conflicts are cases of deliberate or
accidental violation of the data access rights policy. Another example is when, based on shared
resources, participants from different administrative domains obtain similar important results,
and questions arise about how independently they were received and which of the participants
obtained them first.

The state of a data unit (file) is determined by its provenance metadata (PMD), which
consist of its global file identifier (ID) and its attributes, including: (1) local file name in a
storage; (2) storage identifier; (3) creator identifier; (4) owner identifier; (5) source; (6) number of
file downloads, etc. Here we mentioned only themost common possible attributes. The attribute

Суперкомпьютерные дни в России 2019 // Russian Supercomputing Days 2019 // RussianSCDays.org

25



set chosen may depend on the needs of a particular project using the distributed storage. The
full set of possible attributes is defined by the corresponding standard. In particular, in this
work we rely on one of the most widely used PMD standards, namely, W3C PROV [4]. The
set of values for all attributes of a file determines its current state. The state of the entire
distributed storage system is determined by the set of files stored in it with their states at the
moment.

It is supposed that the distributed storage works in the framework of immutable shared files
semantics [5]. Basic operations (comprising of a set of transactions) can be of the following types:
new file upload; file download; file copy within a storage; file deletion; file copy to another storage;
file transfer to another storage. Each active transaction, and therefore operation, corresponds
to an update of some state keys, for example, after the operation “file download” the values of
the following keys change: “number of file downloads” and “users who downloaded the file”.
There are, of course, transactions for changing file attributes, for example, changing the owner
of a file.

In addition to the task of recording the immutable history of working with data in a dis-
tributed storage environment, there exists the task of providing distributed management of
access rights to data. For example, the owner of a data file (the user who created the data
or the organization to which it belongs through its authorized representative) must be able to
manage its access rights for other users. Another example is when a cloud storage service grants
access to data stored on it only to users from organizations that have paid for this storage
service.

3. Hyperledger Blockchain Platform

A natural solution for the establishment of a distributed immutable registry for the PMD
records is the use of the blockchain technology. To implement this solution, it is convenient to
use existing blockchain platforms. We require the platform to be used to have the following prop-
erties: working with permissioned blockchains; using smart contracts to manage transactions
and organize business processes for sharing data and storage resources by project participants
located in different administrative domains; availability of tools for managing access rights to
certain actions with metadata; using a modular structure that allows one to use various algo-
rithms to achieve consensus between the participants of business processes, depending on the
needs of a specific distributed data computing system and its users; possibility of simultane-
ous independent work of several virtual organizations. Analysis of existing platforms (see, e.g.,
the reviews [6–8] and refs. therein) shows that the requirements above practically unambigu-
ously distinguish the Hyperledger Fabric blockchain platform (HLF; www.hyperledger.org) [3]
together with Hyperledger Composer (HLC; hyperledger.github.io/composer) as the best can-
didate (HLF&C-platform). The Hyperledger Composer is a set of tools for simplified use of the
blockchain.

A smart contract along with the registry form the basis of a blockchain system. While the
registry contains information about the current and historical state of a set of business objects,
a smart contract determines the executable logic that generates new states to be added to the
registry. Before parties of a business process can enter into interactions with each other, they
must define a common set of contracts covering common terms, data, rules, concept definitions
and processes. Taken together, these contracts define a business model that governs all interac-
tions between transactional parties. A smart contract defines these rules between the parties in
the form of executable code. In the framework of the HLF&C-platform the smart contracts are
implemented under the name chaincode. In particular, access rights to data files are defined by
the smart contracts in conjunction with special system acl-file (“acl” stands for “access control
language”).

To describe the business process within the framework of HLF&C-platform, a number of

Суперкомпьютерные дни в России 2019 // Russian Supercomputing Days 2019 // RussianSCDays.org

26



concepts are used, the main ones are assets, participants, transactions and events. Assets are
tangible or intellectual resources, services or property, records of which are kept in registries.
Assets can represent almost anything in a business network, such as a house for sale, a listing
for sale, a land registration certificate for that house, while insurance documents for that house
can be assets in one or more business networks. Assets must have a unique identifier, but they
can also contain any properties defined for them. In our case, the assets are data files; their
properties (attributes) are provenance metadata, as defined in the previous Section 2.

Participants are members of the business network. They can own assets and make transac-
tion requests. Like assets, the participants must have an ID and can have any other properties
if necessary. The transaction is the mechanism of interaction of participants with assets. The
definition of events is also established in the process of a business network construction, simi-
larly to the assets or participants. According to these definitions, event messages can be sent
by transaction processors to inform external software components of changes in the blockchain.
Applications can subscribe to receive event information via the HLC API.

From a functional point of view, the nodes in the HLF network are divided into three types:
clients make requests to execute transactions, participate in their processing, and broadcast
transactions to ordering services; peers carry out the transaction processing workflow, validate
them and manage the blockchain registry; ordering service nodes (OSN) establish the general
order of all transactions in the blockchain based on the distributed consensus algorithm. Unlike
public blockchain networks, which allow non-authenticated users to participate in their work,
members of the HLF&C-network must be registered with Membership Service Provider (MSP),
which, among other things, performs the functions of Certification Authority (CA). It should be
emphasized that although the CA is a centralized service, it does not violate the decentralized
nature of the HLF&C-network, distributed storage and PMD management system for two main
reasons: (1) the CA is not a party to the business process, but only a trusted third-party that
provides cryptographic material (digital certificates); although HLF&C provides software for
the organization of its own CA for the deployed network, third-party public CAs can also be
used; (2) the CA is not involved in the process of transaction processing and block formation,
so it does not affect system performance and fault tolerance. In other words, the CA is outside
the business network. Other MSP components, in particular those providing authentication and
authorization of participants, are distributed across network nodes.

4. Consensus Algorithms

As it was mentioned in the Introduction, data management via PMD requires a method
of ensuring consensus among participants in the business process about the content and or-
der of transactions with data. Nowadays there exits a number of consensus algorithms that
do not require resource-consuming and slow “proof-of-work” mechanism which is intrinsic for
cryptocurrency blockchain networks [9].

One of the first and most well known consensus algorithms is the Paxos algorithm [10]. This
algorithm is not designed to work in distributed systems with possible Byzantine errors. It is
very difficult for understanding and implementing [11]. The Raft algorithm [11, 12] realizes the
consensus by choosing a single leader, giving it full responsibility for managing the transaction
recordings. The leader accepts requests from clients, copies them to other servers, and tells
the rest of the servers when it is safe to use the entries in their replicated ledgers. The idea
of having a special leader simplifies the management of the replicated ledger. If the leader for
some reason stops working, the procedure for selecting a new leader begins. However, Raft is
also not designed to work in distributed systems in which a Byzantine type of error is possible
(malicious distortion of information by nodes).

The Practical Byzantine Fault Tolerance (PBFT) algorithm [13] was the first practical
solution to achieve consensus in the face of Byzantine failures. It uses the concept of replicated

Суперкомпьютерные дни в России 2019 // Russian Supercomputing Days 2019 // RussianSCDays.org

27



state machine, and nodes in a PBFT system are sequentially ordered with one node being the
leader and others referred to as backup nodes. All nodes in the system communicate with
one another with the goal being that all honest nodes will come to an agreement of the state
of the system using a majority rule. This algorithm requires 3n + 1 replicas to be able to
tolerate n failing nodes. Communication between nodes has two functions: nodes must prove
that messages came from a specific peer node, and they must verify that the message was not
modified during transmission. This approach imposes a low overhead on the performance of
the ordering service nodes (OSNs). However messaging overhead in the case of PBFT increases
significantly as the number of OSNs increase. However it remains acceptable for a couple of
dozens of OSNs (parties in a project using a distributed storage under the blockchain-based
management) [13, 14]. Currently we consider PBFT as a most suatable distributed consensus
algorithm since its properties match the system requirements and there exist exploratory studies
for its implementation within the HLF&C platform [14]. In the future we plan to consider and
test other BFT algorithms, such as SIEVE [15], XFT [16] and Hashgraph [17].

5. ProvHL System

This section outlines the basic principles of our ProvHL system for managing provenance
metadata and access rights to data in distributed storages based on the HLF&C blockchain
platform.

In general, two approaches are possible: (1) data management systems (DMS) manage data
and use blockchain as a distributed log (data driven data management); (2) first, the metadata
is written to the blockchain, and DMSs refer to the blockchain and performs the transactions
recorded there (metadata driven data management). In the first case, the functionality of
the blockchain system is very limited, it only provides a ledger which is resistant to malicious
attempts to modify the history of data in distributed storage. HLF&C-platform enables one to
implement the second approach, which in addition to simply maintaining the registry allows us
to solve the problem of distributed data access management. Note that the term “metadata
driven” is most often used in the context of ETL-technology (Extract, Transform, Load); we
use it solely to designate a way to manage data by pre-writing metadata to the HLF.

For each data operation, at least two types of transaction records aremade in the blockchain:
one corresponds to the client request, and the second corresponds to the server response.The
algorithms used are aimed at ensuring consistency between the state of the distributed storage
and the entries in the blockchain. In particular, when the “new file upload” transaction is per-
formed, the transaction on creating the new asset, that is the data file, with the “temporary”
label is first recorded in the blockchain. And only after the actual upload of the file in the stor-
age, DMS initiates a transaction removing the label “temporary” and turns the uploaded file
into a fully valid asset. This makes the level of correspondence between the history recorded in
the blockchain and the real history of the data in the distributed storage practically acceptable.
As is known, ensuring full compliance of the real world history with the history recorded in a
blockchain is outside the scope of the blockchain technology (the so-called the Oracle Problem,
see e.g., https://medium.com/@DelphiSystems/the-oracle-problem-856ccbdbd14f). The com-
pliance of ProvHL to the PMD standard W3C PROV [4], mentioned in Section 2, is provided by
the conformity of the basic triples in the both data models, namely {Asset, Operation/Trans-
action, Participant} (for HLF&C/ProvHL) and {Entity, Activity, Agent} (for W3C PROV). A
simplified scheme of the testbed with a preliminary version of the ProvHL system is presented in
figure 1. The operational purpose of the HLF&C-network nodes (peers, OSNs, MSP modules)
is specified in Section 3; the servers provide interaction with data management systems of local
storages.

Суперкомпьютерные дни в России 2019 // Russian Supercomputing Days 2019 // RussianSCDays.org

28



Figure 1. A simplified scheme of the ProvHL testbed.

6. Blockchain-Based Delegation of Rights in Distributed Storages

Delegation is the process of a user or a Web service handing over their authentication
credentials to another executing Web service. We will present themechanism of rights delegation
between services on the example of the data copy operation from one local storage (Storage1) to
another (Storage2). The definition of operations with files as the assets makes the mechanism
of the delegation very natural and flexible. In the framework of the HLF&C-platform assets
(as well as other business network entities) are defined with the help of an object-oriented
modeling language [18] in the so called .cto-file. For the delegation mechanism it is important
the operation definitions contain the obligatory attributes “requester” and “executor” as well
as inherit “file owner” attributes from the file asset definition. Upon receiving a request from a
User for a file copying, the DMS Storage1 (the data management system of the Storage1 which
contains the file to be copied) detects the type of the copy operation, namely decides if this is
local copying (within the Storage1) or copying to another storage. In the latter case it initiates,
on behalf of the User, the operation of uploading the required file to destination Storage2. For
this aim it interacts with the chaincode which, among other actions, defines that: (a) while
for the initial copy operation the value of the requester attribute is equal to the User and the
executor is DMS Storage1, for the induced upload operation the requester is DMS Storage1 and
the executor is DMS Storage2; (b) the owner of the file copy on the Storage2 is the same as the
owner of source file on the Storage1.

Thus, the second request is executed at the request of the User, but by the DMS Storage1
(source storage), and the file ownership does not change. Thismeans that all goals of a delegation
are completed. It is worth stressing that in contrast to the scheme based on proxy certificates [19],
in the blockchain-based approach the delegation is restricted solely to the specified operation.

7. Related Works

Although a number of projects have been implemented in recent years to create systems for
supporting and managing metadata, including the provenance of data, but the vast majority of
the implemented solutions are centralized (see the surveys [20, 21] and refs. therein), which is
poorly consistent with the use of a distributed dynamically changing environment, and the pos-
sibility of using metadata by organizationally unrelated or weakly related research communities.

On the other hand, in recent years, distributed registries based on blockchain technol-
ogy have become very popular in various applied areas due to a number of important advan-
tages [9,22]. Most recently, on the basis of blockchains, PMD management systems for storages

Суперкомпьютерные дни в России 2019 // Russian Supercomputing Days 2019 // RussianSCDays.org

29



have also been developed. The system ProvChain [23] is designed to work with one cloud stor-
age, not a distributed environment. The validation of the data provenance is done off-chain by
a centralized provenance auditor. The system consists of five components: users, cloud service
providers, blockchain network, provenance database, and the provenance auditor. The block-
chain network consists of virtual nodes inside the cloud and keep the data provenance records
in the blocks. The auditor retrieves the provenance data from the blockchain database and
validates the blockchain receipt. The system is based on a bitcoin-like blockchain. To solve
the issues of the initial distribution of ownership shares of resources during the operation of the
Proof-of-Stake algorithm, as well as the validation of this share, a special service is used. This
service starts with the beginning of the process of developing consensus and constantly works
together with blockchain validators (the blockchain nodes being virtual machines in the cloud)
to check their share of resources and select a leader in each round. This service also has the
right to determine remuneration for the successful creation of new blocks and at the same time
to punish (deprive a share of resources) if the validators act maliciously.

The SmartProvenance (DataProv) system [24] is implemented on top of the Ethereum block-
chain platform and consists of two types of components. They are the blockchain components,
which mainly consist of Ethereum smart contracts for access control, creating/storing PMDs and
conducting the voting process, as well as modules not related to the blockchain including the
client module that interacts with smart contracts and a script, working in the cloud, to check the
validity of changes to data files. A smart contract Document Tracker is used to track changes in
data and maintaining access control policies. Each PMD-related event, such as a modification of
a document, must be approved by voting with a special smart Vote contract. The main purpose
of the voting process is to prevent harmful changes that clearly violate the conditions of use
of the data. At the end of the voting stage, if a change decision is made, the Vote contract
submits a change in the Document Tracker contract to create a PMD record. Authorized voting
users use a special verification script that is located in the cloud storage of the system. In the
SmartProvenance system, the rejection of changes as a result of voting is punishable by a fine
using smart contracts and cryptocurrency (Ether) of the Ethereum platform. On the contrary,
voters who have discovered an attempt at unlawful changes receive a reward in the form of a
certain amount in the cryptocurrency.

Actually both ProvChain and SmartProvenance/DataProv does not utilize full fledged
blockchain technology and distributed consensus algorithms because though they use the block-
chain registries to store the data provenance records, the blockchain nodes do not represent
interests of the parties involved and the verification of the operations and the records is done
outside the blockchain network by centralized provenance service. Therefore they do not really
support business processes of data sharing between administratively unrelated parties. They
also inherit the bitcoin/Ethereum platform properties which poorly matching the needs of a
system for supporting business processes of data sharing in distributed storages. In particular,
the both systems use permissionless blockchains with their inherent shortcomings with which
we have to put up in the case of open blockchain networks but which are not inevitable in the
case of distributed storages.

Other existing suggestions and developments in the field of PMD management, including
those based on blockchains, are further from the ProvHL system proposed in this article, both
in their goals and objectives, as well as in the ways of their implementations. The reader may
find discussion of them in Section V of the survey [25].

Thus the traditional centralized techniques are mostly inefficient and have no specific pro-
tection for sensitive information [20, 21, 25]. The shortcomings and half-way solutions of the
discussed blockchain-based systems show that the blockchain-based data provenance needed
more research effort and can be further enhanced by proper utilization of the smart contracts.
We believe that our ProvHL system meets the challenge.

Суперкомпьютерные дни в России 2019 // Russian Supercomputing Days 2019 // RussianSCDays.org

30



8. Conclusion

In this paper, the new approach based on the integration of the blockchain technology, smart
contracts and metadata driven data management was suggested. On its basis, the principles
and algorithms of the system called ProvHL (Provenance HyperLedger) were developed. This
system is a fault-tolerant, secure and reliable system for managing provenance metadata, as well
as access rights to data in distributed storages. The problems of optimal choice of the blockchain
type for such a system, as well as the choice of the blockchain platform were studied. Namely, it
was proposed to use a permissioned type of blockchain and the Hyperledger blockchain platform,
on the basis of which the ProvHL system is implemented.

Provenance metadata are written to the blockchain beforehand, and the data management
system refers to the blockchain and performs the transactions recorded there (metadata driven
data management). At present, a testbed has been created on the basis of SINP MSU, where a
preliminary version of the ProvHL prototype is deployed to implement the developed principles
and refine the algorithms of the system. Within the testbed, smart contracts are implemented
to support basic operations with files (upload, download, copy to another storage, etc.). This
infrastructure is free from the significant drawbacks inherent to existing solutions, in particular,
from the vulnerabilities associated with the presence of a central services and the problems
related to the using permissionless blockchains. In addition, the suggested blockchain-based
delegation proves to be simple, natural and flexible. Creation of the ProvHL production level
system will significantly improve the quality and reliability of the results obtained on the basis
of data processing and analysis in a distributed computer environment.

References

1. Kryukov A. and Demichev A. Decentralized Data Storages: Technologies of Construction
// Programming and Computer Software. 2018. Vol. 44, No. 5. P.303-315.

2. Berghöfer, T., et al. Towards a model for computing in european astroparticle physics.
2015. arXiv preprint, arXiv:1512.00988.

3. Androulaki E.,et al. Hyperledger Fabric: A Distributed Operating System for
Permissioned Blockchains // Proceedings of the Thirteenth EuroSys Conference,
EuroSys’18, April 2326, 2018, Porto, Portugal, article No. 30. ACM, 2018.

4. PROV-DM: The PROV Data Model. W3C Recommendation. 2013. URL:
https://www.w3.org/TR/prov-dm (accessed 03.06.2019).

5. Levy E. and Silberschatz A. Distributed File Systems: Concepts and Examples // ACM
Computing Surveys. 1990. Vol. 22, No. 4. P.321-374.

6. Hamida E. B., et al. Blockchain for Enterprise: Overview, Opportunities and Challenges
// The Thirteenth International Conference on Wireless and Mobile Communications,
ICWMC2017,Nice, France, 2017.

7. Cachin C. and Vukolic M. Blockchain Consensus Protocols in the Wild. 2017. arXiv
preprint, arXiv:1707.01873.

8. Valenta M., Sandner P. Comparison of Ethereum, Hyperledger Fabric and Corda. FSBC
Working Paper. 2017. PP. 1-8.

9. Baliga A. Understanding Blockchain Consensus Models. Tech. rep., Persistent Systems
Ltd. 2017.

10. Lamport, L. The Part-Time Parliament.// ACM Transactions on Computer Systems.
1998. Vol 16. No. 2. PP. 133-169.

Суперкомпьютерные дни в России 2019 // Russian Supercomputing Days 2019 // RussianSCDays.org

31



11. Ongaro, D. and Ousterhout J.K. In search of an understandable consensus algorithm //
Proceedings of the USENIX Annual Technical Conference, USENIX Association, 2014.
PP. 305-319.

12. Howard H. ARC: analysis of Raft consensus. 2014. Technical Report No.
UCA";"""date"",""2019-10-08T12:14:37Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.5""
""xmp:CreatorTool"",""pdftk 2.02 - www.pdftk.com""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dcterms:created"",""2019-10-08T12:14:37Z""
""language"",""en""
""Last-Modified"",""2019-10-08T12:14:37Z""
""dcterms:modified"",""2019-10-08T12:14:37Z""
""dc:format"",""application/pdf; version=1.5""
""Last-Save-Date"",""2019-10-08T12:14:37Z""
""pdf:docinfo:creator_tool"",""pdftk 2.02 - www.pdftk.com""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2019-10-08T12:14:37Z""
""meta:save-date"",""2019-10-08T12:14:37Z""
""pdf:encrypted"",""false""
""modified"",""2019-10-08T12:14:37Z""
""Content-Length"",""186724""
""pdf:hasMarkedContent"",""false""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""meta:creation-date"",""2019-10-08T12:14:37Z""
""created"",""2019-10-08T12:14:37Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""9""
""Creation-Date"",""2019-10-08T12:14:37Z""
""resourceName"",""24.pdf""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""3272"",""3758"",""3578"",""3795"",""3523"",""2525"",""3857"",""2881"",""2557""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""producer"",""itext-paulo-155 (itextpdf.sf.net-lowagie.com)""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""itext-paulo-155 (itextpdf.sf.net-lowagie.com)""
""pdf:docinfo:created"",""2019-10-08T12:14:37Z""
";https://scholar.google.com/scholar?start=860&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094668-1188;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;… of blockchain technologies in manufacturing. Study of applicability of blockchain technology in manufacturing: blockchain typologies, manufacturing scenarios …;S VACCA TORELLI ;2019 politesi.polimi.it;;"… its paper (Nakamoto, 2009) the Blockchain structure, taking inspiration from the Hash- Chain.

Nakamoto proposed this block-based design as a core component of the crypto- currency

Bitcoin which was deployed the following year. Page 27. 26 …";Autres articles;Version HTML;[PDF] polimi.it;https://www.politesi.polimi.it/bitstream/10589/150965/1/2019_12_Vacca_Torelli.pdf;"
 
SCUOLA DI INGEGNERIA INDUSTRIALE E 

DELL’INFORMAZIONE 

Laurea Magistrale in Ingegneria Gestionale 

 

 

 

 

Potentials of Blockchain Technologies in 
Manufacturing:  

Study of applicability of Blockchain technology in manufacturing: 
Blockchain typologies, manufacturing scenarios, application benefits and 

technology constraints. 

 

 

 
Supervisor: Prof. Marco TAISCH 
Co-Supervisor: Ing. Claudio PALASCIANO 

Master of Science Thesis of:  

Simone VACCA TORELLI 

905294 

 

Academic Year: 2018/19 



 
1 

 

This page is intentionally left blank 

  



 
2 

 

 

 

 

 

 

“So, the problem is not so much to see what nobody has yet seen, as to 

think what nobody has yet thought concerning that which everybody 

sees.” 

Arthur Schopenhauer. 

  



 
3 

 

This page is intentionally left blank   



 
4 

 

Acknowledgements  

The process of writing this thesis has been both challenging and an invaluable learning 

experience. The writing of this thesis would not have been possible without the help of 

several knowledgeable and resourceful people, and I would like to take this opportunity to 

express my sincerest gratitude for their assistance.   

First, I would like to show my deepest gratitude to my academic supervisor, Prof. Marco 

Taisch, and, in particular, to my co-supervisor, Eng. Claudio Palasciano, for giving me the 

opportunity to work on this thesis and for the feedbacks that I have received which have been 

highly useful in setting the structure and the direction of this thesis.    

Lastly, I would like to express my sincerest gratitude and appreciation to my family and 

friends, for always supporting me and being there for me throughout all my studies.   

Thank you!     

Milan, December 2019.   



 
5 

 

This page is intentionally left blank   



 
6 

 

Abstract 

This thesis analyses the possibility of application of the innovative Blockchain technology 

within Manufacturing, taking into consideration different application scenarios, the possible 

resulting benefits and the technological constraints. 

Thanks to the diffusion of Bitcoins, which have gained great notoriety in recent years, the 

Blockchain has attracted the attention not only of researchers but also of investors who have 

begun to investigate the possibility of using this technology in other areas as well. 

Therefore, in this thesis this technology is first examined from an informatics point of view to 

understand the basic working mechanism and to find out what are the motivations that make 

it so interesting and so versatile; then the phenomenon of the fourth industrial revolution, 

the so-called Industry 4.0, is investigated in order to contextualize the current production 

scenario and the technologies with which the manufacturing world is evolving; finally, the 

definition of a decision-making framework will make it possible to establish the applicability 

of the Blockchain within different industrial applications taking into account the main 

technologies with which it will have to interface, the requirements it will have to respect and 

the benefits it will bring.   



 
7 

 

This page is intentionally left blank   



 
8 

 

Abstract (Italian Version) 

La tesi analizza la possibilitĂ  di applicazione della innovativa tecnologia Blockchain 

all’interno del Manufacturing, tenendo in considerazioni diversi scenari di applicazione, i 

possibili benefici risultanti ed i vincoli tecnologici. 

Grazie alla diffusione dei Bitcoin, che hanno acquisito una grande notorietĂ  negli ultimi anni, 

la Blockchain ha richiamato l’attenzione non solo di ricercatori ma anche di investitori che 

hanno iniziato ad indagare la possibilitĂ  di utilizzare questa tecnologia anche in altri ambiti. 

Pertanto, in questa tesi viene dapprima analizzata questa tecnologia da un punto di vista 

informatico per capire il meccanismo base di funzionamento e per scoprire quali sono le 

motivazioni che la rendono cosĂŹ interessante e cosĂŹ versatile; quindi viene analizzato il 

fenomeno della quarta rivoluzione industriale, il cosiddetto Industry 4.0, al fine di 

contestualizzare al meglio l’attuale scenario produttivo e le tecnologie con cui il mondo del 

Manufacturing si sta evolvendo; infine, la definizione di un framework decisionale 

permetterà di stabilire l’applicabilità della Blockchain all’interno di diverse applicazioni 

industriali tenendo conto delle principali tecnologie con cui essa dovrĂ  interfacciarsi, dei 

requisiti che dovrĂ  rispettare e dei benefici che potrĂ  portare.   



 
9 

 

This page is intentionally left blank   



 
10 

 

SUMMARY  
Acknowledgements ............................................................................................ 4 

Abstract ............................................................................................................. 6 

Abstract (Italian Version) .................................................................................. 8 

Table of Figures ................................................................................................. 14 

Table of Tables ..................................................................................................18 

Table of Acronyms ........................................................................................... 20 

1) Introduction to the Research ........................................................................ 22 

2) Introduction to the Blockchain Technology .................................................. 24 

2.1) What Blockchain Is ................................................................................. 24 

2.1.1) History: from the Hash-Chain to the Bitcoin Block-Chain ..................................... 24 

2.1.2) Main Elements of a Blockchain .............................................................................. 26 

2.1.2.1) Centralised, Decentralised, Distributed systems .............................................. 26 

2.1.2.2) Blocks in the Blockchain .................................................................................. 27 

2.1.2.3) Mining .............................................................................................................. 27 

2.1.2.3.1) Rewards and Transactions Fees ................................................................. 28 

2.1.2.4) Hash Value ....................................................................................................... 29 

2.1.2.4.1) Hash Algorithm: SHA256 .......................................................................... 29 

2.1.2.5) The Timestamp ................................................................................................. 30 

2.1.2.6) The Genesis Block ............................................................................................. 31 

2.1.2.7) Digital signature: Public & Private Key Pairs ................................................... 32 

2.2) How Blockchain Works .......................................................................... 34 

2.2.1) Stepping through key elements of Blockchain: ...................................................... 34 

2.2.2) Network Propagation of the Blockchain ................................................................ 42 

2.2.2.1) Block Size and Propagation Delay .................................................................... 43 

2.2.2.2) Blocks Dissemination and Forks ..................................................................... 44 

2.2.2.3) Improving Network Propagation Speed .......................................................... 47 

2.2.3) Fork Classes and Hard & Soft Types ...................................................................... 47 

2.2.4) Scalability and the Trilemma ................................................................................. 49 

2.2.5) Access Control ........................................................................................................ 54 

2.2.6) Consensus Mechanism ........................................................................................... 57 

2.2. Unanimity in unreliable distributed systems: The Byzantine Generals Problem . 58 

2.2.6.1.1 Illustration of the problem .......................................................................... 59 

2.2.6.1.2 Solutions to the problem ............................................................................. 59 

2.2.6.2 Consensus Algorithm ........................................................................................ 60 

2.2.6.2.1 Classification of Consensus Algorithms ...................................................... 60 

2.2.6.2.1.1) Proof of Work (PoW) ............................................................................ 61 

2.2.6.2.1.2) Proof of Stake (PoS) ............................................................................ 65 

2.2.6.2.1.3) Delayed Proof of Work (dPoW) .......................................................... 66 

2.2.6.2.1.4) Delegated Proof of Stake (dPoS) ......................................................... 67 



 
11 

 

2.2.6.2.1.5) Leased Proof of Stake (lPoS) ............................................................... 68 

2.2.6.2.1.6) Proof of Authority (PoA) ..................................................................... 69 

2.2.6.2.1.7) Proof of Reputation (PoRep) .............................................................. 69 

2.2.6.2.1.8) Proof of Elapsed Time (PoET) ............................................................ 70 

2.2.6.2.1.9) Proof of Space (PoSp) ......................................................................... 70 

2.2.6.2.1.10) Proof of History (PoH) ....................................................................... 71 

2.2.6.2.1.11) Proof of Stake Velocity (PoSV) ........................................................... 71 

2.2.6.2.1.12) Proof of Importance (PoI) ................................................................. 72 

2.2.6.2.1.13) Proof of Identity (PoId) ..................................................................... 72 

2.2.6.2.1.14) Proof of Retrievability (PoR) ............................................................. 73 

2.2.6.2.1.15) Proof of Activity (PoAc) ..................................................................... 73 

2.2.6.2.1.16) Proof of Time (PoT) ........................................................................... 74 

2.2.6.2.1.17) Proof of Weight (PoWe) .................................................................... 74 

2.2.6.2.1.18) Proof of Burn (PoB) ........................................................................... 75 

2.2.6.2.1.18) Ouroboros ......................................................................................... 75 

2.2.6.2.1.19) Proof of Authentication (PoAh) ........................................................ 76 

2.2.6.2.1.20) Proof of Devotion (PoD) ................................................................... 76 

2.2.6.2.1.21) Byzantine Fault Tolerance (BFT) .......................................................77 

2.2.6.2.1.22) Proof of Believability (PoBe) ............................................................. 79 

2.2.6.2.1.23) RAFT ................................................................................................. 80 

2.2.6.2.2) General comparison between consensus algorithms ................................ 81 

2.3) Evolution of Blockchain ......................................................................... 82 

2.3.1) Directed Acyclic Graphs (DAG) .............................................................................. 82 

2.3.2) Smart Contracts ....................................................................................................... 91 

2.3.3) Side Chains ............................................................................................................. 92 

2.5) Blockchain Application Industries ......................................................... 94 

2.4.1) Classification of Blockchain Application by Industries .......................................... 94 

2.4.2) Classification of Blockchain Applications in the Manufacturing Industry ............ 99 

2.4.2.1) Inbound & Outbound Logistic/Procurement................................................. 102 

2.4.2.2) Product, Process & Technology Development ............................................... 102 

2.4.2.3) Operations ..................................................................................................... 103 

2.4.2.4) Sales & Marketing .......................................................................................... 105 

2.4.2.5) Human Resource Management/Firm Infrastructure .................................... 106 

2.4.3) Smart Contracts for Manufacturing ......................................................................107 

3) The Industry 4.0 Scenario .......................................................................... 108 

3.1) Industry 4.0 and the rise of Smart Manufacturing Systems .................. 109 

3.1.1) The Evolution of Industrial Production: from 1.0 to 4.0 ..................... 109 

3.1.2) Definition and Key Components of Industry 4.0 ................................. 110 

3.2) Design Principles .................................................................................. 115 

3.2.1) Interconnection ...................................................................................................... 115 



 
12 

 

3.2.2) Information Transparency .................................................................................... 116 

3.2.3) Decentralized Decisions ........................................................................................ 116 

3.2.4) Technical Assistance .............................................................................................. 117 

3.3) Objectives .............................................................................................. 117 

3.4) Benefits .................................................................................................120 

3.5) Main Technological Pillars .................................................................... 123 

3.5.1) Autonomous Robots ...............................................................................................124 

3.5.2) Big Data & Analytics .............................................................................................. 125 

3.5.3) Cloud Computing ................................................................................................... 125 

3.5.4) Industrial Internet of Things (IIoT) ...................................................................... 127 

3.5.5) Horizontal and Vertical System Integration ......................................................... 130 

3.5.6) Simulation ............................................................................................................ 130 

3.5.7) Augmented & Virtual Reality ................................................................................. 131 

3.5.8) Additive Manufacturing ........................................................................................ 131 

3.5.9) Cybersecurity ......................................................................................................... 131 

3.6) Requirements for Industry 4.0 ............................................................. 133 

3.7) Challenges ............................................................................................. 135 

4) Potential Blockchain Applications in Manufacturing .................................. 138 

4.0.1) Preliminary Considerations .................................................................................. 138 

4.0.2) Definition of a Framework for Assessing Potential Blockchain Application ........139 

4.1) Blockchain Key Functions for Manufacturing Applications ................... 141 

4.2) Classification of Blockchain typologies based on their Characteristics . 148 

4.3) Requirements for Potential Manufacturing Applications ...................... 151 

4.4) Blockchain Typologies for Effective Manufacturing Applications ......... 156 

4.4.1) Blockchains for Internet of Things in Manufacturing Applications ...................... 157 

4.4.2) Blockchains for Horizontal & Vertical System Integration in Manufacturing 
Applications ..................................................................................................................... 159 

4.4.3) Blockchains for Big Data & Analytics in Manufacturing Applications ................. 161 

4.4.4) Blockchains for Augmented & Virtual Reality in Manufacturing Applications ....162 

4.4.5) Blockchains for Autonomous Robots & Vehicles in Manufacturing Applications 164 

4.4.6) Blockchains for Cloud Storage & Computing in Manufacturing Applications ..... 165 

4.4.7) Blockchains for Additive Manufacturing in Manufacturing Applications ........... 166 

4.4.8) Blockchains for Cybersecurity in Manufacturing Applications ........................... 168 

4.4.9) Blockchains for Simulation in Manufacturing Applications ................................ 168 

4.6) Final Results for Potentials of Blockchain Technologies in Manufacturing
 ..................................................................................................................... 169 

4.5) Further Conclusive Considerations ....................................................... 174 

4.5.1) Blockchain Achieved Benefits for Manufacturing Application .............................. 174 

4.5.2) Blockchain Solved Challenges for Manufacturing Application ............................. 177 

4.5.3) Main Blockchain Future Implementation Challenges for Manufacturing ............ 178 



 
13 

 

5) Conclusions ................................................................................................. 182 

Annex: Literature Review Research Methodology ........................................... 187 

Bibliography ................................................................................................... 191 

 

 

 

  



 
14 

 

Table of Figures 

Figure 1: Working Mechanism of a Hash Algorithm ............................................................... 24 

Figure 2: Possible Typologies of Network Structure ................................................................ 26 

Figure 3: Timestamp Effect on the Possible Event Occurence ................................................ 30 

Figure 4: Implication of the Genesis Block .............................................................................. 30 

Figure 5: Representation of Two Blocks with Two Different Hashes ...................................... 34 

Figure 6: Representation of a Replacing Activity on a Block ................................................... 35 

Figure 7: An Example of Simple Blockchain Consisting of Three Different Blocks ................ 35 

Figure 8: Effects of a Violation Attempt on the Original Blockchain ...................................... 36 

Figure 9: Effect of the Remining Activity on the Second Block ............................................... 36 

Figure 10: A Distributed Blockchain Owned by Two Different Nodes .................................... 37 

Figure 11: Node B’s Violation Attempt on the Distributed Database....................................... 37 

Figure 12: Token-based Distributed Blockchain ...................................................................... 38 

Figure 13: Example of a Couple of Private and Public Key ...................................................... 39 

Figure 14: Effect of Using the same Couple of Key on the same Message ............................... 39 

Figure 15: Transaction Signature in the Blockchain ................................................................ 40 

Figure 16: Representation of a Distributed and Signed Blockchain ......................................... 41 

Figure 17: Exchange of a Block between Two Nodes ............................................................... 42 

Figure 18: Influence of Block Size on the Propagation Delay .................................................. 43 

Figure 19: Propagation of a Block over the Blockchain Network ............................................ 44 

Figure 20: Propagation of Two Different Blocks over the Blockchain Network ...................... 44 

Figure 21: Representation of Two Partitions of the Network .................................................. 45 

Figure 22: Representation of a Detected Forking Event and coexistence of Two Partitions .. 46 

Figure 23: Resolution of a Forking Event and Synchronization Starting ................................ 46 

Figure 24: Normal and Rare Forkings ..................................................................................... 48 

Figure 25: Representation on a Hard Fork Event .................................................................... 49 

Figure 26: The Scalability Trilemma Represented in a Mechanical Logic .............................. 50 

Figure 27: Directed Acyclic Graph Representation.................................................................. 54 

Figure 28: Representation of the Logic for Access Control ..................................................... 55 

Figure 29: Ordinary Block Production in PoS ......................................................................... 67 

Figure 30: Example of a Malfuctioning or Malicious Activities in PoS ................................... 68 

Figure 31: Reaching the Limit of One-Third of Malevolent Node in PoS ................................ 68 

Figure 32: PoAh Representation in the Blockchain ................................................................. 76 

Figure 33: Phases in a Practical Byzatine Fault Tolerance ...................................................... 78 

Figure 34: Simple Cyclic Graph ............................................................................................... 83 

Figure 35: Directed Acyclic Graph ........................................................................................... 83 

Figure 36: Blockchain-Similar Directed Acyclic Graphs ......................................................... 83 

file:///C:/Users/VZ793XJ/Desktop/Potentials%20of%20Blockchain%20Technologies%20in%20Manufacturing%20Final_V1.docx%23_Toc26436902
file:///C:/Users/VZ793XJ/Desktop/Potentials%20of%20Blockchain%20Technologies%20in%20Manufacturing%20Final_V1.docx%23_Toc26436903
file:///C:/Users/VZ793XJ/Desktop/Potentials%20of%20Blockchain%20Technologies%20in%20Manufacturing%20Final_V1.docx%23_Toc26436907
file:///C:/Users/VZ793XJ/Desktop/Potentials%20of%20Blockchain%20Technologies%20in%20Manufacturing%20Final_V1.docx%23_Toc26436913
file:///C:/Users/VZ793XJ/Desktop/Potentials%20of%20Blockchain%20Technologies%20in%20Manufacturing%20Final_V1.docx%23_Toc26436915
file:///C:/Users/VZ793XJ/Desktop/Potentials%20of%20Blockchain%20Technologies%20in%20Manufacturing%20Final_V1.docx%23_Toc26436918
file:///C:/Users/VZ793XJ/Desktop/Potentials%20of%20Blockchain%20Technologies%20in%20Manufacturing%20Final_V1.docx%23_Toc26436919
file:///C:/Users/VZ793XJ/Desktop/Potentials%20of%20Blockchain%20Technologies%20in%20Manufacturing%20Final_V1.docx%23_Toc26436920
file:///C:/Users/VZ793XJ/Desktop/Potentials%20of%20Blockchain%20Technologies%20in%20Manufacturing%20Final_V1.docx%23_Toc26436925
file:///C:/Users/VZ793XJ/Desktop/Potentials%20of%20Blockchain%20Technologies%20in%20Manufacturing%20Final_V1.docx%23_Toc26436926
file:///C:/Users/VZ793XJ/Desktop/Potentials%20of%20Blockchain%20Technologies%20in%20Manufacturing%20Final_V1.docx%23_Toc26436927
file:///C:/Users/VZ793XJ/Desktop/Potentials%20of%20Blockchain%20Technologies%20in%20Manufacturing%20Final_V1.docx%23_Toc26436928
file:///C:/Users/VZ793XJ/Desktop/Potentials%20of%20Blockchain%20Technologies%20in%20Manufacturing%20Final_V1.docx%23_Toc26436929
file:///C:/Users/VZ793XJ/Desktop/Potentials%20of%20Blockchain%20Technologies%20in%20Manufacturing%20Final_V1.docx%23_Toc26436932
file:///C:/Users/VZ793XJ/Desktop/Potentials%20of%20Blockchain%20Technologies%20in%20Manufacturing%20Final_V1.docx%23_Toc26436933
file:///C:/Users/VZ793XJ/Desktop/Potentials%20of%20Blockchain%20Technologies%20in%20Manufacturing%20Final_V1.docx%23_Toc26436934
file:///C:/Users/VZ793XJ/Desktop/Potentials%20of%20Blockchain%20Technologies%20in%20Manufacturing%20Final_V1.docx%23_Toc26436937


 
15 

 

Figure 37: Forking Event in a Directed Acyclic Graph ............................................................ 84 

Figure 38: Complex Directed Acyclic Graph ............................................................................ 84 

Figure 39: Tangle Directed Acyclic Graph ............................................................................... 85 

Figure 40: Couples on the same horizontal level are incomparable with each other but also 

some other pairs at different level, such as {b} and {g}, are also incomparable. .................... 86 

Figure 41: Double Spending on a Directed Acyclic Graph ....................................................... 87 

Figure 42: Representation of Account Balance (on the left) and Fund Transfer (on the right) 

in Block-Lattice Data Structure ............................................................................................... 87 

Figure 43: Events Representation on Hashgraph .................................................................... 88 

Figure 44: Comparison Between Blockchain and Hashgraph ................................................. 89 

Figure 45: Round Creation and Election Starting ................................................................... 89 

Figure 46: Election Mechanism for Reaching Consensus and Confirming Events ................. 90 

Figure 47: Representation of a Sidechain Network with Three Sidechains ............................ 93 

Figure 48: Decentralization of Factory in Industry 4.0 with Blockchain. Adapted from 

(Rüßmann, et al., 2017) .......................................................................................................... 100 

Figure 49: Porter’s Value Chain. Adapted from (Porter, 1985) ............................................. 102 

Figure 50: Single modular cells in SMSs. ............................................................................... 113 

Figure 51: Interconnection between cells in SMSs. ................................................................ 113 

Figure 52: The whole physical system is represented and controlled at application level. .... 114 

Figure 53: Design Principles for Industry 4.0 (Hermann, Pentek & Otto, 2016) ................... 115 

Figure 54: Main Technologies in Industry 4.0 (Rüßmann, et al., 2017) .................................124 

Figure 55: Framework for the Assessment of Blockchain Application in Manufacturing 

(Author’s Own Finding) ......................................................................................................... 140 

Figure 56: Focus on Functions in the Framework (Author's Own Finding)........................... 141 

Figure 57: Classification of Blockchain Functions (Author's Own Findings) ......................... 141 

Figure 58: Focus on How Functions Satisfy Requirements in the Framework (Author's Own 

Finding) ................................................................................................................................... 147 

Figure 59: Focus of What Blockchain Types Enable Certain Functions in the Framework 

(Author's Own Finding) ......................................................................................................... 148 

Figure 60: Focus of Which Requirements each Manufacturing Application Needs in the 

Framework (Author's Own Finding) ....................................................................................... 152 

Figure 61: Application of the Results over the Whole Framework (Author's Own Findings) 156 

Figure 62: Level of Integrability of Blockchain with Main Technologies of Industry 4.0 

(Author's Own Findings)Table 21: Results for Potential Blockchain Application in 

Manufacturing (Author's Own Findings) ................................................................................ 171 

Figure 63: Level of Integrability of Blockchain with Main Technologies of Industry 4.0 

(Author's Own Findings) ......................................................................................................... 172 

file:///C:/Users/VZ793XJ/Desktop/Potentials%20of%20Blockchain%20Technologies%20in%20Manufacturing%20Final_V1.docx%23_Toc26436941
file:///C:/Users/VZ793XJ/Desktop/Potentials%20of%20Blockchain%20Technologies%20in%20Manufacturing%20Final_V1.docx%23_Toc26436941
file:///C:/Users/VZ793XJ/Desktop/Potentials%20of%20Blockchain%20Technologies%20in%20Manufacturing%20Final_V1.docx%23_Toc26436943
file:///C:/Users/VZ793XJ/Desktop/Potentials%20of%20Blockchain%20Technologies%20in%20Manufacturing%20Final_V1.docx%23_Toc26436943
file:///C:/Users/VZ793XJ/Desktop/Potentials%20of%20Blockchain%20Technologies%20in%20Manufacturing%20Final_V1.docx%23_Toc26436944
file:///C:/Users/VZ793XJ/Desktop/Potentials%20of%20Blockchain%20Technologies%20in%20Manufacturing%20Final_V1.docx%23_Toc26436945
file:///C:/Users/VZ793XJ/Desktop/Potentials%20of%20Blockchain%20Technologies%20in%20Manufacturing%20Final_V1.docx%23_Toc26436946
file:///C:/Users/VZ793XJ/Desktop/Potentials%20of%20Blockchain%20Technologies%20in%20Manufacturing%20Final_V1.docx%23_Toc26436947
file:///C:/Users/VZ793XJ/Desktop/Potentials%20of%20Blockchain%20Technologies%20in%20Manufacturing%20Final_V1.docx%23_Toc26436948
file:///C:/Users/VZ793XJ/Desktop/Potentials%20of%20Blockchain%20Technologies%20in%20Manufacturing%20Final_V1.docx%23_Toc26436949
file:///C:/Users/VZ793XJ/Desktop/Potentials%20of%20Blockchain%20Technologies%20in%20Manufacturing%20Final_V1.docx%23_Toc26436949
file:///C:/Users/VZ793XJ/Desktop/Potentials%20of%20Blockchain%20Technologies%20in%20Manufacturing%20Final_V1.docx%23_Toc26436951
file:///C:/Users/VZ793XJ/Desktop/Potentials%20of%20Blockchain%20Technologies%20in%20Manufacturing%20Final_V1.docx%23_Toc26436952
file:///C:/Users/VZ793XJ/Desktop/Potentials%20of%20Blockchain%20Technologies%20in%20Manufacturing%20Final_V1.docx%23_Toc26436953
file:///C:/Users/VZ793XJ/Desktop/Potentials%20of%20Blockchain%20Technologies%20in%20Manufacturing%20Final_V1.docx%23_Toc26436955
file:///C:/Users/VZ793XJ/Desktop/Potentials%20of%20Blockchain%20Technologies%20in%20Manufacturing%20Final_V1.docx%23_Toc26436956
file:///C:/Users/VZ793XJ/Desktop/Potentials%20of%20Blockchain%20Technologies%20in%20Manufacturing%20Final_V1.docx%23_Toc26436956
file:///C:/Users/VZ793XJ/Desktop/Potentials%20of%20Blockchain%20Technologies%20in%20Manufacturing%20Final_V1.docx%23_Toc26436959
file:///C:/Users/VZ793XJ/Desktop/Potentials%20of%20Blockchain%20Technologies%20in%20Manufacturing%20Final_V1.docx%23_Toc26436959
file:///C:/Users/VZ793XJ/Desktop/Potentials%20of%20Blockchain%20Technologies%20in%20Manufacturing%20Final_V1.docx%23_Toc26436963
file:///C:/Users/VZ793XJ/Desktop/Potentials%20of%20Blockchain%20Technologies%20in%20Manufacturing%20Final_V1.docx%23_Toc26436963
file:///C:/Users/VZ793XJ/Desktop/Potentials%20of%20Blockchain%20Technologies%20in%20Manufacturing%20Final_V1.docx%23_Toc26436963
file:///C:/Users/VZ793XJ/Desktop/Potentials%20of%20Blockchain%20Technologies%20in%20Manufacturing%20Final_V1.docx%23_Toc26436964
file:///C:/Users/VZ793XJ/Desktop/Potentials%20of%20Blockchain%20Technologies%20in%20Manufacturing%20Final_V1.docx%23_Toc26436964


 
16 

 

Figure 64: Potentiality of Application of Blockchain in Manufacturing with Each Technology 

in Industry 4.0  (Author's Own Findings) ............................................................................... 173 

Figure 65: Literature Review Research Process ..................................................................... 189 

Figure 66: Distribution of Documents over Years from 2009 and 2018 ............................... 189 

Figure 67: Google Trends Results regarding the Blockchain Keyword ................................. 189 

Figure 68: Documents Classification based on Three Main Categories ................................ 190 

 

  

file:///C:/Users/VZ793XJ/Desktop/Potentials%20of%20Blockchain%20Technologies%20in%20Manufacturing%20Final_V1.docx%23_Toc26436965
file:///C:/Users/VZ793XJ/Desktop/Potentials%20of%20Blockchai";"""date"",""2019-12-05T10:14:08Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.7""
""xmp:CreatorTool"",""MicrosoftÂŽ Word for Office 365""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dc:creator"",""Simone Vacca Torelli""
""language"",""en""
""dcterms:created"",""2019-12-05T10:14:08Z""
""Last-Modified"",""2019-12-05T10:14:08Z""
""dcterms:modified"",""2019-12-05T10:14:08Z""
""dc:format"",""application/pdf; version=1.7""
""xmpMM:DocumentID"",""uuid:09B4814D-4F64-408A-BF25-D486C84CBEB4""
""Last-Save-Date"",""2019-12-05T10:14:08Z""
""pdf:docinfo:creator_tool"",""MicrosoftÂŽ Word for Office 365""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2019-12-05T10:14:08Z""
""meta:save-date"",""2019-12-05T10:14:08Z""
""pdf:encrypted"",""false""
""xmp:CreateDate"",""2019-12-05T11:14:08Z""
""modified"",""2019-12-05T10:14:08Z""
""pdf:hasMarkedContent"",""true""
""Content-Type"",""application/pdf""
""xmp:ModifyDate"",""2019-12-05T11:14:08Z""
""pdf:docinfo:creator"",""Simone Vacca Torelli""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Simone Vacca Torelli""
""dc:language"",""en-US""
""meta:author"",""Simone Vacca Torelli""
""pdf:producer"",""MicrosoftÂŽ Word for Office 365""
""meta:creation-date"",""2019-12-05T10:14:08Z""
""created"",""2019-12-05T10:14:08Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""211""
""Creation-Date"",""2019-12-05T10:14:08Z""
""resourceName"",""2019_12_Vacca_Torelli.pdf""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""476"",""44"",""176"",""44"",""908"",""44"",""1298"",""44"",""1336"",""44"",""4442"",""4373"",""4241"",""338"",""4095"",""4004"",""655"",""46"",""4002"",""593"",""1046"",""459"",""2512"",""931"",""1863"",""2173"",""2140"",""2460"",""2721"",""2145"",""1821"",""2919"",""2652"",""1711"",""1736"",""820"",""868"",""574"",""1581"",""1375"",""1477"",""651"",""2098"",""1980"",""1101"",""1728"",""623"",""2090"",""1641"",""1649"",""1814"",""2732"",""2707"",""2195"",""1779"",""1668"",""2941"",""2674"",""2883"",""2224"",""2738"",""2809"",""2934"",""3011"",""3021"",""2817"",""2643"",""2606"",""1462"",""2584"",""2505"",""2507"",""2043"",""2907"",""2031"",""1790"",""2133"",""2628"",""1825"",""2833"",""2065"",""774"",""2673"",""923"",""1542"",""2368"",""1989"",""1491"",""2137"",""1058"",""1823"",""2517"",""2420"",""530"",""2197"",""2367"",""2002"",""2657"",""2039"",""2857"",""1692"",""2602"",""1473"",""2923"",""2814"",""2696"",""690"",""2388"",""2690"",""2849"",""2442"",""2931"",""2869"",""2698"",""2391"",""1642"",""2981"",""2849"",""2749"",""2347"",""2580"",""3501"",""1129"",""2782"",""1237"",""2919"",""2482"",""2547"",""2707"",""2373"",""2923"",""2767"",""586"",""2790"",""1820"",""3032"",""3834"",""2418"",""2823"",""2877"",""1164"",""1069"",""2786"",""2769"",""2805"",""2792"",""2771"",""207"",""2244"",""2733"",""2305"",""169"",""2273"",""2980"",""107"",""110"",""2297"",""3122"",""3029"",""2964"",""3117"",""2841"",""2889"",""2590"",""3137"",""3227"",""2913"",""2908"",""2884"",""2543"",""2810"",""103"",""119"",""139"",""2502"",""2688"",""2671"",""2574"",""2651"",""2981"",""2779"",""949"",""2390"",""2758"",""2221"",""2354"",""1899"",""1964"",""2679"",""1055"",""941"",""2196"",""2133"",""2256"",""2206"",""2422"",""2248"",""2141"",""2185"",""2329"",""2237"",""2312"",""2075"",""2160"",""2205"",""2136"",""2313"",""2240"",""2314"",""2452"",""1394""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""Author"",""Simone Vacca Torelli""
""producer"",""MicrosoftÂŽ Word for Office 365""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""MicrosoftÂŽ Word for Office 365""
""pdf:docinfo:created"",""2019-12-05T10:14:08Z""
";https://scholar.google.com/scholar?start=410&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094567-765;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Enhance generalized exchange economy using blockchain: a time banking case study;X Lin, R Xu, Y Chen, JK Lum ; the IEEE Blockchain Technical …, 2019  blockchain.ieee.org;;"… Enhance Generalized Exchange Economy Using Blockchain: A Time Banking Case Study.

Xuheng Lin, Dept … of Electrical and Computing Engineering, Binghamton University, SUNY. IEEE

Blockchain Technical Briefs, March 2019. Discuss this topic on IEEE Collabratec …";Cité 2 fois;;null;;;;https://scholar.google.com/scholar?start=580&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094593-872;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Key legal issues surrounding smart contract applications;P Sanz Bayón ; KLRI Journal of Law and Legislation, 2019  papers.ssrn.com;;"… external oracles that are under the control of the party that must perform the obligation.28 … by

alternative mechanisms, such as the creation of a SC linked to an oracle (a notary … Introducing

a blockchain ledger to record joint venture transactions and using SC to define, negotiate …";Cité 1 fois;Les 2 versions;[PDF] comillas.edu;https://repositorio.comillas.edu/xmlui/bitstream/handle/11531/36961/KJLL%20Vol9%20No1%202019%20article.pdf?sequence=-1&isAllowed=y;"
Legal Issues in Facilitation & Fair-Use of E-Procurement System 
- Lessons from Korean Experience -  
¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡Dae-in Kim

“Trade Wars are Good and Easy to Win” : from Security Exceptions to Post-WTO World
¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡Alexandr Svetlicinii

Key Legal Issues Surrounding Smart Contract Applications
¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡ Pablo Sanz Bayón

Ensuring the Rights of Juvenile Offenders in Vietnam’s Juvenile Justice – Towards 
Better Compliance with the Convention on the Rights of the Child
¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡Duc Tien Nguyen

The EU Legal Protection System against the Effects of Extra-territorial Application 
of Legislation Adopted by a Third Country, and Actions Based Thereon or Resulting 
Therefrom
¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡Stefan Brocza

Formation, Development and Improvement of the Constitutional Justice in the Republic 
of Uzbekistan in the Modern Conditions of the Society
¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡Mukhamedjanov Amanulla Zakirovich

KLRI
Journal of
Law and
Legislation

Volume 9
Number 1

2019

Articles



KLRI Journal of Law and Legislation

Editor-in-Chief 
 Soo-Geun Oh, Professor, Ewha Womans University

Editorial Board 
 Asif Qureshi, Professor, Korea University
 Birgit Daiber, Professor, Seoul National University 
 Dan Puchniak, Professor, National University of Singapore
 Dae-In Kim, Professor, Ewha Womans University
 Kyung-Sin Park, Professor, Korea University
 Woo-Young Rhee, Professor, Seoul National University
 Alexander Graser, Professor, University of Regensburg
 Adam Pritchard, Professor, University of Michigan
 Yuki Katagiri, Professor, Otaru University of Commerce
 Lincoln Davies, Professor, University of Utah

Managing Editors
 Hyung-Gun Kim, KLRI, Korea
 Min-Young Jang, KLRI, Korea
 Hyun-Jung Lee, KLRI, Korea 

Chair of the Executive Board
 Ik-Hyeon Rhee, President, KLRI, Korea

KLRI Journal of Law and Legislation 
ISSN 2234-7526
Printed by KS Sensation Co
Publication Date: May 31, 2019

Korea Legislation Research Institute
15 Gukchaegyeonguwon-ro
Sejong-si 30147
Republic of Korea
Tel : 82-44-861-0446 
Fax : 82-44-868-9913, 14
www.klri.re.kr

CopyrightŠ 2019 Korea Legislation Research Institute

All materials in this issue may be reproduced or distributed, in whole or in part, by nonprofit 
institutions for educational purposes including distribution to students, provided that the copies are 
distributed at or below cost and identify the author, the KLRI Journal of Law and Legislation, the 
volume, for educational and nonprofit purpose, and the year of the article’s publication. For-profit 
inquiries concerning the reproduction of articles should be addressed to the Managing Editor at 
KJLL@KLRI.RE.KR. 

All views expressed in KLRI Journal of Law and Legislation are those of the authors only and do not 

KJLL, or any associates of the journal.



KLRI
Journal of
Law and
Legislation

Volume 9
Number 1

2019



KLRI Journal of Law and Legislation

VOLUME 9 NUMBER 1, 2019

�������	

Legal Issues in Facilitation & Fair-Use of E-Procurement System

- Lessons from Korean Experience - 

1

Dae-in Kim

“Trade Wars are Good and Easy to Win”:

From Security Exceptions to the Post-WTO World

29

Alexandr Svetlicinii

Key Legal Issues Surrounding Smart Contract Applications 63

Pablo Sanz BayĂłn

Ensuring the Rights of Juvenile Offenders in Vietnam’s Juvenile 

Justice �� Towards Better Compliance with the Convention on the 

Rights of the Child

93

Duc Tien Nguyen

The EU Legal Protection System against the Effects of 

Extra-territorial Application of Legislation Adopted by a Third 

Country, and Actions Based Thereon or Resulting Therefrom

145

Stefan Brocza

Formation, Development and Improvement of the Constitutional 

Justice in the Republic of Uzbekistan in the Modern Conditions 

of the Society

199

Mukhamedjanov Amanulla Zakirovich

Contents



Key Legal Issues Surrounding Smart Contract 
Applications

Pablo Sanz BayĂłn*1

 I. A Basic Concept of Smart Contract

II. Blockchain as a Suitable Technology for Smart Contracts

III. Operation of Smart Contracts on Blockchain Platforms

A. The Main Problem of Contracts

B. The Blockchain Solution to the Main Problem of 

Contracts

IV. Legal Categorization of Smart Contracts and Some 

Problematic Aspects

A. Premises for a Legal Categorization of Smart Contracts

B. Problematic Aspects that Arise with Smart Contracts

C. The Path towards the Design of a Harmonized Supranational 

Legislative Policy for Smart Contracts: Main Challenges

V. Final Remarks

* Assistant Professor in Commercial Law. School of Law, Comillas Pontifical University 

(Madrid, Spain). Tel: +34 91 542 28 00, Email: psbayon�comillas.edu.



Abstract2

The aim of this work is to delve into some key legal issues surrounding Smart 

Contract applications. In the first and second parts, this paper defines the 

concept of Smart Contract and how it applies within the blockchain ecosystem. 

In the third part, this work exposes the functioning of this digital technology and 

the main advantage that it implies for solving the crucial issues of execution and 

breach of contracts. In the fourth section, this paper analyzes a set of 

problematic aspects that arise around Smart Contracts such as the scope and 

delimitation of them or the validity and certification of blockchain transactions. 

It also analyzes different issues related to the design of a legislative policy that 

addresses the design of a supranational and harmonized legal framework.

Keywords: Smart Contract, Blockchain, Distributed-Ledger Technology, 

Transactions, Self-executing Agreements, Enforcement, Legislative Policy

Manuscript received: Feb. 7, 2019; review completed: Mar. 14, 2019; accepted: Apr. 15, 2019



I. A Basic Concept of Smart Contract

The concept of Smart Contract (SC) was introduced at the end of the last 

century by the computer cryptographer Nick Szabo, who proposed it to 

automate the fulfillment of computerized promises.1 Szabo defined SC as a set 

of promises and specified in digital form, including protocols within which the 

parties perform on the other promises.2 The automation of the execution of 

contractual obligations is made possible through the translation of the terms of 

the contract into an executable program. This program allows the control over 

the physical or digital objects necessary to perform such execution. In this way, 

once the possibility of a dispute regarding the conditions has been closed 

(because they are codified and previously agreed upon by the parties), the key 

point is to wait for the conditions in the programming to be fulfilled or not in 

order to carry out the agreed obligations.

The functioning of the SC is given through conditional statements that have 

the form [if this (X), then (Y)]. This task can be entrusted to a software thanks to 

the possibility of putting in computer code some of the provisions of a contract 

(which may have been previously formalized in natural language).3 The 

1) Mr. Szabo was the first author to use the term “smart contracts” and is theorized to be the person 

behind the pseudonym of Satoshi Nakamoto, the creator of the cryptocurrency Bitcoin. For more 

information regarding these claims. See Nathaniel Popper, Decoding the Enigma of Satoshi 

Nakamoto and the Birth of Bitcoin, The New York Times (Apr. 26, 2019), https://www.nytimes 

.com/2015/05/17/business/decoding-the-enigma-of-satoshi-nakamoto-and-the-birth-of-bitcoin

.html. For more information: SZABO, N. (1997), The Idea of Smart contract. Retrieved from 

https://web.archive.org/web/20060615044959/http:/szabo.best.vwh.net/smart_contracts_idea.html

2) Nick Szabo, Smart contracts, Âś 1, (Apr. 26, 2019), Phonetic Sciences, University of Amsterdam 

http://www.fon.hum.uva.nl/rob/Courses/InformationInSpeech/CDROM/Literature/LOTwint

erschool2006/szabo.best.vwh.net/smart.contracts.html.

3) One of the SC applications based on private blockchain is led by a consortium of major 

international banks called R3. R3 successfully used its proprietary Corda blockchain for the first 

time to trade bonds as part of a pilot project. This is another case where blockchain-based SC 

has the potential to cut costs and speed up processes by automating manual tasks. Corda 

blockchain allows members to use the transaction platform whilst receiving exclusive access to 

the data and combining this system with SC in order to trade derivatives, as Barclays 

demonstrated in April 2016. The vision is for the SC to be capable of automatically transferring 

the value of a derivative to the account of the transaction´s beneficiary from the account of its 

counterparty. As Deloitte states in its report, the current legal framework still requires the 

counterparty owing the payment to authorize automated transfers, but technically it is already 

possible today to fully automate the process without leaving any possibility for intervention by 

the parties. The same process is possible for energy networks to be controlled through SC, since 



66 Key Legal Issues Surrounding Smart Contract Applications Pablo Sanz BayĂłn

importance of SC is of such magnitude that the Nobel Prize Laureate in 

Economics 2016, Oliver Hart, for his contribution to the Theory of Contracts, 

announced his interest in participating in some projects that are developing 

innovations in this field.4

II. Blockchain as a Suitable Technology for Smart 

Contracts

The blockchain technology constitutes a very useful computational platform 

for programming and registering this type of operations whoseself-execution 

depends on verifying the conditions previously established between the 

parties.All this is achieved without the intervention of any of the parties or of an 

intermediary or central authority. In this sense, any agreement between 

individuals or companies can include clauses whose execution is automated 

thanks to the use of blockchain technology.5

Blockchain is more well-known as the means to the end that it serves, since it 

is the technology that enables the functioning of Bitcoin (which is the most 

well-known cryptocurrency).6 This technology is a type of Distributed Ledger 

Technology (DLT),7 which has been characterized as “a distributed, shared, and 

they would signal to the system when to initiate what transactions based ojn predefined rules. 

See Felix Hasse, Axel von Perfall, Thomas Hillebrand, Erwin Smole, Lena Lay, and Maximilian 

Charlet, Blockchain - an opportunity for energy producers and consumers?, PwC global 

power & utilities, available at https://www.pwc.com/gx/en/industries/assets/pwc-blockchain 

-opportunity-for-energy-producers-and-consumers.pdf.

4) Michael del Castillo, Nobel Prize Winner Joins Blockchain Startup to Fix Smart Contracts, 

Forbes (Aug. 1, 2018), https://www.forbes.com/consent/?toURL=https://www.forbes.com/sites 

/michaeldelcastillo/2018/08/01/nobel-prize-winner-joins-blockchain-startup-to-fix-smart-contra

cts/#2faf421e7cc7. 

5) Tessa Hoser, Blockchain basics, commercial impacts and governance challenges, 68 Governance 

Directions, 608-12 (2016).

6) Bitcoin is a cryptocurrency created in 2009 that serves the function of money without requiring the 

control of a central authority, since it depends on cryptography through a consensus network. This 

cryptocurrency works via a peer to peer network that enables the use of this digital money. For more 

information, see Satoshi Nakamoto, Bitcoin: A Peer-to-Peer Electronic Cash System, available at 

https://bitcoin.org/bitcoin.pdf; see also Reuben Grinberg, Bitcoin: An Innovative Alternative Digital 

Currency, 4 Hastings Sci. & Tech. L.J. (2011), available at https://ssrn.com/abstract=1817857.

7) See A Report by the UK Government Chief Scientific Adviser, Distributed Ledger Technology: beyond  

  block chain, Government Office for Science (2016), available at https://www.gov.uk/government   



KLRI Journal of Law and Legislation VOLUME 9 NUMBER 1, 2019 67

encrypted database that serves as an irreversible and incorruptible repository of 

information.”8 Blockchain operates as a digital platform that validates and 

stores the history and timeline of transactions of all users throughout the 

network. By creating a new “block” in the chain, the platform contains all the 

information created from the transactions, and timestamps them in order to 

preserve all the information unaltered. Its operating is close to a double-entry 

bookkeeping system, in the sense that once the transaction has been carried out, 

the blockchain registers and sends it to all the users in the network. The blocks 

are chronologically saved and also connected to a database that will enable a 

secure and trustworthy way of ensuring the origin and owner of the digital file or 

asset that has been transferred.9 The transactions are verified by high-advanced 

cryptographic system, and once validated, they are stored in different blocks 

that are also later verified by the whole network of members (each through its 

node), and thus chained to one another, which is synchronized among the other 

nodes via Peer-to-Peer (P2P) protocol.10 

The main difference, and its main advantage over the more traditional 

systems of bookkeeping is that this digital accounting system is completely 

decentralized. This ensures that the possibility of tampering with the records is 

close to null. If some altering were to be done to a certain block or piece of 

information, the author would have to change all records of the whole 

blockchain network. This means to alter all the records which were sent to the 

network members, one by one, and in the shortest time as possible.11 

In practice, this technological advantage allows for transactions to occur and 

be approved without requiring the services of a middle-man or intermediary, 

since the whole network will ensure the instant legitimacy of the transaction 

deployed in the Peer-to-Peer platform.12 For this reason, the main virtue of this 

  /uploads/system/uploads/attachment_data/file/492972/gs-16-1-distributed-ledger-technology.pdf.

  8) See Hossein Kakavand, Nicolette Kost De Sevres, and Bart Chilton, The Blockchain Revolution: 

An Analysis of Regulation and Technology Related to Distributed Ledger Technologies, (2017), 

available at https://papers.ssrn.com/sol3/papers.cfm?abstract_id=2849251.

  9) See Matthew Spoke, How Blockchain Tech Will Change Auditing for Good (2015), coindesk, 

available at https://www.coindesk.com/blockchains-and-the-future-of-audit/.

10) See Kakavand, Sevres, and Chilton, supra note 8.

11) See Douglas W. Arner, Janos Nathan Barberis, and Ross P. Buckley, The Evolution of Fintech: A New 

Post-Crisis Paradigm?, Univ. H.K. Fac. L. Res. Paper No. 2015/047 (2015), UNSW L. Res. Paper 

No.2016-62 (2016), available at https://papers.ssrn.com/sol3/papers.cfm?abstract_id=2676553. 

12) See Special Report: Slings and Arrows, Blockchain - The Next Big Thing, The Economist (2015), 



68 Key Legal Issues Surrounding Smart Contract Applications Pablo Sanz BayĂłn

new digital technology is its unlimited applications.13 In fact, blockchain can be 

applied in all technological dimensions, but it can also be used in order to solve 

and fulfil operational, legal, and regulatory issues, by covering all aspects of 

market and corporate concerns, which could include: public registrars and 

filings (commercial and property ones, management of securities or intellectual 

property rights), notarization and public faith, and even invoice tracking.14 

III. Operation of Smart Contracts on Blockchain Platforms 

As indicated above, a SC is an automatable and enforceable agreement. 

Although some parts may require human input and control, it can be automated 

by computer. It is enforceable either by legal enforcement of rights and 

obligations or via tamper-proof execution of computer code.15 Its main utility in 

the network consists of serving as a condition to execute orders that allow the 

available at https://www.economist.com/news/special-report/21650295-or-it-next-big-thing.

13) For more information, see James Ray, Decentralized apps (dapps), Ethereum / wiki (2018), 

available at https://github.com/ethereum/wiki/wiki/Decentralized-apps-(dapps).

14) According to Maria Pedernal, Legal framework and international comparison of regulatory 

technologies (Regtech) and its implications for the financial sector, Universidad Pontificia 

Comillas (2018): “A great example of the interest that corporations have regarding this 

technology is the photograph-company Kodak, which caused a major fuzz in the markets once 

they announced that they were entering into a partnership agreement with WENN Digital to 

establish the management of photographers’ image rights on the blockchain, along with the 

launching of a “photo-centric cryptocurrency.” The result was prompt: their shares’ value 

increased in a 200%, despite the fact that they had filed for bankruptcy in 2012 and their 

revenues were declining since they returned to the printing business in 2013.” For more 

information, see Cory Johnson and Olga Kharif, Kodak CEO Plans to Seize Blockchain 

Moment and Win Over Skeptics, Bloomberg (2018), available at https://www.bloomberg.com 

/news/articles/2018-01-12/kodak-ceo-plans-to-seize-blockchain-moment-and-win-over-ske

ptics.

15) The use of the expression ""tamper-proof"" reflects the definition's indebtedness to the 

aforementioned blockchain technologies, which are fundamentally a way of creating 

tamper-proof electronic record of transactions – i.e. a record which neither the parties nor any 

third party can modify. What the definition is getting at here is that the enforceability of a SC 

may not necessarily lie in the fact that the output (i.e. its performance) can be enforced by a 

court, but, as an alternative sense of ""enforceable"", that it may be affected by an autonomous 

technological process which, once initiated, cannot be interfered with. See CLIFFORD 

CHANCE (2017), Are smart contracts contracts? Retrieved from http://globalmandatoolkit. 

cliffordchance.com/downloads/Smart_Contracts.pdf. 



KLRI Journal of Law and Legislation VOLUME 9 NUMBER 1, 2019 69

administration of digital assets (tokens), and therefore, of the data encrypted in 

the blocks of the chain.

From a computer perspective, each SC involves the processing of a set of 

automated orders. The SC is executed when an external agent to the chain (but 

connected to it) intervenes by stating a fact or verifying the fulfillment of a 

condition.16 Once the agent (usually a machine or an application called 

“oracle”) issues the command, the SC triggers a programmed digital event.17 

The execution of the provisions of a SC allows the virtual operators of the 

blockchain platform (or even of other interconnected blockchains) to display 

the consequences of the scheduled event online. Normally, such event will 

consist of a payment, the conclusion of a transaction, the transfer of digital 

assets, or any other predetermined event. Therefore, the automatic operation of 

SC in a blockchain platform is intended to produce facts with legal relevance.

Consequently, it is necessary to clarify that SC is a useful program to 

exchange digital assets when certain conditions are met or the external 

scheduled events occur. Thanks to this way of operating, SC can be very useful 

to automate markets, products, services, and even new systems of business 

organizations (Decentralized Autonomous Organizations or DAO).18 This 

automation of SC requires support and legal recognition in order to provide not 

only full effects among the parties but also erga omnes, insofar as the material 

consequences that they deploy on the network are the object of legal recognition 

regarding registered data with full evidentiary effects.19

16) See Vitalik Buterin, A Next Generation Smart contract and Decentralized Application Platform, 

Ethereum White Paper (2018), available at http://blockchainlab.com/pdf/Ethereum_white_paper-a 

_next_generation_smart_contract_and_decentralized_application_platform-vitalik-buterin.pdf.

17) See Angela Walch, The Path of the Blockchain Lexicon (and the Law), 36 Rev. Banking & Fin. 

L. 713 (2017), available at https://www.academia.edu/32573448/The_Path_of_the_Blockchain 

_Lexicon_and_the_Law.

18) See Andrew Hinkes, The Law of the DAO, coindesk, (2016), available at https://www.coindesk.com 

/the-law-of-the-dao/ and Reuben Bramanathan, Blockchains, Smart contracts and the Law. 

Unravelling the legal issues surrounding the DAO, The Coinbase Blog (2016), available at 

https://blog.coinbase.com/blockchains-smart-contracts-and-the-law -709c5b4a9895.

19) For example, in the Ethereum platform, SC is executed to achieve any goals pursued with the data 

incorporated into the token (transfer properties or credits or the creation of cryptocurrencies). 

Software developers are designing decentralized applications, strengthening the ecosystem and 

demand for Ether (Ethereum's gas or currency). See Financial Services Regulatory Authority, 

Supplementary Guidance - Regulation of Initial Coin Offerings and Virtual Currencies under the 

Financial Services and Market Regulations, Abu Dhabi Global Market (2017), available at https:// 

www.adgm.com/media/192772/20171009-fsra-guidance-for-icos-and-virtual-currencies.pdf.



70 Key Legal Issues Surrounding Smart Contract Applications Pablo Sanz BayĂłn

A. The Main Problem of Contracts

Blockchain has gained considerable strength in relation to the actual 

implementation of SC. This is because the technology of SC aims to solve the 

biggest inconvenience that economic agents have encountered throughout 

history: total, partial, or late non-compliance with the contractual obligations 

between the parties. When, for example, two parties agree to carry out any 

exchange, it is natural that the expectation of both is directed to both the one and 

the other complying with the agreement. However, over time, the interests or 

intentions of each of the parties may vary. If the fulfillment of a contract 

depends on the will of the parties, it may happen that one of them changes his or 

her mind and refrains from fulfilling it or does so incompletely or defectively. If 

this situation were to occur, the legitimate expectations of its counterpart would 

be frustrated. The traditional solution would be to go to court or to arbitration to 

demand compliance with the terms of the contract or the termination of the 

contract with compensation for damages. All this uncertainty about the 

execution of the contract implies time and costs for the plaintiff.20

B. The Blockchain Solution to the Main Problem of Contracts

Thanks to the SC and blockchain technology, the risk of lack of execution of 

contracts can be reduced and solved very efficiently. This is achieved through 

an automated mechanism that assurances a quick and cheap execution of the 

contract when certain agreed conditions are met. This mechanism is completed 

through the programming of algorithms. The algorithm itself searches the data it 

needs and then checks whether the condition has been met or not according to an 

20) The introduction of blockchain-based SC in a shared-ledger platform drives substantial 

efficiency, fraud prevention and cost take out. In the chemicals and petroleum industry, for 

instance, due to the vast and intricate geographies in which the companies operate, each 

participant in a supply chain must maintain their records, updated with their transactions and 

systems, which must be reconciled among other participants in the network. As a result, all 

participants in the supply chain incur costs and delays associated with this reconciliation. 

These issues are further complicated when third-party validation or intermediaries have to be 

brought to resolve disputes. As IBM states, much more than a technology to automate business 

transactions, blockchain create a new model for trust by establishing transactional relationship 

between businesses via SC, certifications and digital compliance. IBM Cross Business Unit 

White Paper, Blockchain can help transform supply chain networks in the chemicals and 

petroleum industry (2018), available at https://www.ibm.com/downloads/cas/B4OYMO5Q.



KLRI Journal of Law and Legislation VOLUME 9 NUMBER 1, 2019 71

oracle (which is a source of external information, for example, a webpage with 

information on asset prices).21 If the condition has been met, the transaction is 

executed by the SC (for example, a purchase order, payments, etc.).22

In this sense, blockchain helps solve potential difficulties in the execution of 

contracts. This is achieved thanks to the generation and maintenance of the 

information through an encrypted and decentralized registry that is supervised 

by each member of the network (nodes).23 Consequently, since there is no 

central depositor of the information with which the SC is going to operate, it 

would be necessary to hack or crack the entire network in order to modify the 

terms of the contract or take possession of the digital assets that it can dispose of. 

This hypothesis is practically impossible.

This advantageous feature of blockchain provides a very high level of 

security and transparency that is consistent with the objectives of operations 

carried out with SC. For this reason, it said that the great advantage of SC is that 

they are very difficult to be altered or revoked, once they have been operated 

and even more so when the automatic execution of the contracts has taken plac

e.24 The irreversibility and immutability of blockchain guarantee the fulfillment 

and effectiveness of the legal obligations. Thus, the nature of SC fits very well 

with the Blockchain ecosystem. Once programmed by the parties, the execution 

of the SC does not need any intermediary to carry them out. This means that 

many commercial exchanges are potentially more efficient by reducing the 

transaction costs associated with both the default of the counterparty and those 

derived from going to court to claim compensation.25

21) See Alexander Preukschat, Blockchain: la revoluciĂłn industrial de internet, (GestiĂłn 2000, 

2017).

22) Thanks to a blockchain platform operating SC some practices in certain sectors could be 

improved such as work order which are manually created and processed, inefficient notification 

across parties, lack of compliance checks, discrepancies in services performed and included on 

the invoice resulting in errors and unauthorized spend. See Accenture, A Digital Future for 

Oil and Gas: Blockchain – Understanding New Technologies (Sep. 12, 2017), available at 

h t tps : / / s3 .amazonaws.com/bizzabo.users . f i les /27UDMvJRJ6w3WSvUq8j1 

_BC%201%20-%20Rich%20Meszaros%20-%20Accenture.pdf. 

23) For more information, please see S. Asharaf and S. Adarsh, Decentralized Computing Using 

Blockchain Technologies and Smart contracts: Emerging Research and Opportunities, 

(Information Science Reference, 2017). 

24) See Max Raskin, The law and legality of smart contracts, 1 Geo. Tech. L. R. 305 (2017).

25) Blockchain-based SC have the potential of simplifying processes that can lead to enhanced 

efficiency and cost reductions, offering transactional verification instantly across the network, 

without relying on a central authority. This advantage has the potential of reducing operating 



72 Key Legal Issues Surrounding Smart Contract Applications Pablo Sanz BayĂłn

IV. Legal Categorization of Smart Contracts and Some 

Problematic Aspects

A. Premises for a Legal Categorization of Smart Contracts

Both legal traditions, Common Law and Civil Law, give the parties to a 

contract ample scope to reach agreements and negotiate the terms of a contract. 

Since the SC is based exclusively on the algorithmic configuration of a 

condition or a set of conditions, it is obvious that the contractual freedom will be 

subject to the limits of the conditions in accordance with the legal system under 

which it is celebrated. For instance, this is the case of the existing prohibitions 

for certain contracts because of their purpose (illicit activities or contrary to 

public order) or restrictions on what can or cannot be agreed, as it happens with 

consumers or labor contracts. Criminal law, consumer law, or labor law, in this 

sense, would operate as certain limits to contractual conditions. Therefore, a SC 

should respect them, to be considered valid and legally enforceable. Nothing 

prevents a contract from being subject to conditions. There are relatively simple 

contractual conditions to formulate in programming language and that the SC 

itself can verify. This verification can occur in two ways: using reliable sources 

within the blockchain environment itself (or outside through an external oracle) 

or through the contribution of a certain document of assessed content. For 

instance, this last method would be the proper one to execute an escrow 

contract.26

cost, managing data and improving the speed of transaction processing. Regarding oil and gas 

industry, Deloitte states that supply chains will be a good place to start in assessing practical 

value. SC in blockchain for this sector and markets can enhance supply chain efficiency, better 

secure real-time data generated during delivery, by creating a chain of order requests connecting 

engineers, analysts and laboratories. In this sense, through blockchain platforms oil and gas 

companies could forge new agreements with producers, suppliers, financial experts, 

record-keeping departments and third-party vendors, potentially leading to reduced cost, 

streamlined management and a clearer understanding of the assignments and expectations of 

each player on the field. See Mark Koeppen, David Shrier, and Morgan Bazilian, Is 

blockchain´s future in oil and gas transformative or transient?, Deloitte (2017), available 

at https://www2.deloitte.com/content/dam/Deloitte/de/Documents/energy-resources/gx

-blockchain-report-future-in-oil-and-gas.pdf.

26) SC can be an extraordinary instrument to improve value chain efficiency in the oil and gas 

sector. As Deloitte has explained, many years of volatility in commodity prices, growth 

stagnancy and limited expansion have put exploration and production companies in a tough 

spot. Because of this situation, they have been forced to drastically reduce drilling times and 



KLRI Journal of Law and Legislation VOLUME 9 NUMBER 1, 2019 73

B. Problematic Aspects that Arise with Smart Contracts

The previous legal categorization opens sev";"""date"",""2019-06-03T10:16:38Z""
""pdf:PDFVersion"",""1.5""
""xmp:CreatorTool"",""Adobe Acrobat Pro 10.1.16""
""pdf:docinfo:title"",""KJLL Vol9 No1 2019.pdf""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""Adobe Acrobat Pro 10.1.16""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""KJLL Vol9 No1 2019.pdf""
""xmp:CreateDate"",""2019-06-03T12:16:38Z""
""modified"",""2019-06-03T10:16:38Z""
""pdf:hasMarkedContent"",""false""
""xmp:ModifyDate"",""2019-06-03T12:16:38Z""
""pdf:docinfo:creator"",""Windows 사용자""
""meta:author"",""Windows 사용자""
""meta:creation-date"",""2019-06-03T10:16:38Z""
""created"",""2019-06-03T10:16:38Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-06-03T10:16:38Z""
""resourceName"",""KJLL%20Vol9%20No1%202019%20article.pdf""
""Author"",""Windows 사용자""
""producer"",""Acrobat Distiller 10.0.0 (Windows)""
""pdf:docinfo:producer"",""Acrobat Distiller 10.0.0 (Windows)""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""102"",""0"",""10"",""1"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""access_permission:modify_annotations"",""true""
""dc:creator"",""Windows 사용자""
""dcterms:created"",""2019-06-03T10:16:38Z""
""Last-Modified"",""2019-06-03T10:16:38Z""
""dcterms:modified"",""2019-06-03T10:16:38Z""
""title"",""KJLL Vol9 No1 2019.pdf""
""xmpMM:DocumentID"",""uuid:bbb86521-ebf7-4be6-aeb9-84304237d4e7""
""Last-Save-Date"",""2019-06-03T10:16:38Z""
""pdf:docinfo:modified"",""2019-06-03T10:16:38Z""
""meta:save-date"",""2019-06-03T10:16:38Z""
""Content-Length"",""354893""
""Content-Type"",""application/pdf""
""xmp:MetadataDate"",""2019-05-31T14:35:39Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Windows 사용자""
""pdf:producer"",""Acrobat Distiller 10.0.0 (Windows)""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""34""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""1847"",""1841"",""52"",""882"",""788"",""1029"",""3253"",""2822"",""3007"",""3107"",""3174"",""2891"",""3061"",""2970"",""3043"",""2755"",""2661"",""3163"",""2504"",""2824"",""2707"",""3013"",""3029"",""2610"",""3307"",""2825"",""3318"",""2501"",""1226"",""2236"",""2316"",""2352"",""1409"",""14""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-06-03T10:16:38Z""
";https://scholar.google.com/scholar?start=690&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094630-1033;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;The function-inversion problem: Barriers and opportunities;H Corrigan;Gibbs, D Kogan  Theory of Cryptography Conference, 2019  Springer;;"… We are particularly interested in function-inversion algorithms that only make black-box use of

the function f—or formally, that have only oracle access to f—since these algorithms invert all

functions … In this case, we will often denote the oracle as \(\pi \) instead of f. Definition 2 …";Cité 12 fois;Les 2 versions;[PDF] iacr.org;https://eprint.iacr.org/2019/1046.pdf;"
The Function-Inversion Problem:
Barriers and Opportunities

Henry Corrigan-Gibbs and Dmitry Kogan

Stanford University
{henrycg,dkogan}@cs.stanford.edu

Abstract. The task of function inversion is central to cryptanalysis:
breaking block ciphers, forging signatures, and cracking password hashes
are all special cases of the function-inversion problem. In 1980, Hellman
showed that it is possible to invert a random function f : [N ] → [N ] in
time T = Õ(N2/3) given only S = Õ(N2/3) bits of precomputed advice
about f . Hellman’s algorithm is the basis for the popular “Rainbow Tables”
technique (Oechslin, 2003), which achieves the same asymptotic cost and
is widely used in practical cryptanalysis.

Is Hellman’s method the best possible algorithm for inverting functions
with preprocessed advice? The best known lower bound, due to Yao (1990),
shows that ST = Ω̃(N), which still admits the possibility of an S = T =

Õ(N1/2) attack. There remains a long-standing and vexing gap between
Hellman’s N2/3 upper bound and Yao’s N1/2 lower bound. Understanding
the feasibility of an S = T = N1/2 algorithm is cryptanalytically relevant
since such an algorithm could perform a key-recovery attack on AES-128
in time 264 using a precomputed table of size 264.

For the past 29 years, there has been no progress either in improving
Hellman’s algorithm or in strengthening Yao’s lower bound. In this work,
we connect function inversion to problems in other areas of theory to
(1) explain why progress may be difficult and (2) explore possible ways
forward.

Our results are as follows:
– We show that any improvement on Yao’s lower bound on function-

inversion algorithms will imply new lower bounds on depth-two
circuits with arbitrary gates. Further, we show that proving strong
lower bounds on non-adaptive function-inversion algorithms would
imply breakthrough circuit lower bounds on linear-size log-depth
circuits.

– We take first steps towards the study of the injective function-
inversion problem, which has manifold cryptographic applications. In
particular, we show that improved algorithms for breaking PRGs with
preprocessing would give improved algorithms for inverting injective
functions with preprocessing.

– Finally, we show that function inversion is closely related to well-
studied problems in communication complexity and data structures.
Through these connections we immediately obtain the best known
algorithms for problems in these domains.



1 Introduction

A central task in cryptanalysis is that of function inversion. That is, given a
function f : [N ] → [N ] and a point y ∈ [N ], find a value x ∈ [N ] such that
f(x) = y, if one exists. The hardness of function inversion underpins the security
of almost every cryptographic primitive we use in practice: block ciphers, hash
functions, digital signatures, and so on. Understanding the exact complexity of
function inversion is thus critical for assessing the security of our most important
cryptosystems.

We are particularly interested in function-inversion algorithms that only make
black-box use of the function f—or formally, that have only oracle access to
f—since these algorithms invert all functions. A straightforward argument shows
that any black-box inversion algorithm that makes at most T queries to its
f -oracle succeeds with probability at most O(T/N), over the randomness of the
adversary and the random choice of the function. This argument suggests that
an attacker running in o(N) time cannot invert a black-box function on domain
[N ] with good probability.

When the inversion algorithm may use preprocessing, this logic breaks down.
An algorithm with preprocessing runs in two phases: In the preprocessing phase,
the algorithm repeatedly queries f and then outputs an “advice string” about f .
In the subsequent online phase, the algorithm takes as input its preprocessed
advice string and a challenge point y ∈ [N ]. It must then produce a value x ∈ [N ]
such that f(x) = y. When using these algorithms for cryptanalysis, the attacker
typically seeks to jointly minimize the bit-length S of the advice string and the
running time T of the online algorithm. The computation required to construct
the advice string, though usually expensive, can often be amortized over a large
number of online inversions.

A trivial preprocessing algorithm stores a table of f−1 in its entirety as
its advice string using S = Õ(N) bits and can then invert the function on all
points using a single lookup into the table. In contrast, constructing algorithms
that simultaneously achieve sublinear advice and online time S = T = o(N) is
non-trivial.

In a seminal paper, Hellman [48] introduced time-space tradeoffs as a tool
for cryptanalysis and gave a black-box preprocessing algorithm that inverts
a function f : [N ] → [N ] using only S = Õ(N2/3) bits of advice and online
time T = Õ(N2/3), where the algorithm is guaranteed to succeed only on a
constant fraction of functions. (More precisely, the algorithm has a constant
success probability over the uniformly random choice of the function f .) Fiat and
Naor [29, 30] later gave a rigorous analysis of Hellman’s algorithm and extended
it to invert all possible functions, albeit with a slightly worse trade-off of the
form S3T = Õ(N3) for any choice of N3/4 ≤ S ≤ N . Hellman’s trade-off is
the best known today, and his algorithm is a fundamental tool in real-world
cryptanalysis [7, 8, 61,63].

In this work, we investigate the following question:

Is it possible to improve upon Hellman’s time-space trade-off?

2



Yao first asked this question in 1990 [79] and proved that any preprocessing
algorithm for function inversion that uses S bits of advice and T online queries
must satisfy ST = Ω̃(N). (Counting only queries—and not online computation—
only strengthens lower bounds in this model.) Notably, this lower bound does not
rule out an algorithm that achieves S = T = Õ(N1/2). In contrast, Hellman’s
algorithm only gives an upper bound of S = T = Õ(N2/3), even for the slightly
easier case of inverting a random function. The question resurfaces in the work
of Fiat and Naor [30], Barkan, Biham, and Shamir [5] (who show that Hellman’s
method is optimal for a certain natural but restricted class of algorithms), De,
Trevisan and Tulsiani [23], and Abusalah et al. [1].

In addition to the problem’s theoretical appeal, determining the best possible
time-space trade-offs for function inversion is relevant to practice, since the differ-
ence between an online attack time of N2/3 and an N1/2 becomes crucial when
dealing with 128-bit block ciphers, such as the ubiquitous AES-128. Hellman’s
algorithm gives the best known preprocessing attack against AES-128, with
S = T ≈ 286. If we could improve Hellman’s algorithm to achieve S = T = N1/2,
matching Yao’s lower bound, we could break AES-128 in time 264 with a data
structure of size 264, albeit after an expensive preprocessing phase. While today’s
S = T = 286 attack is likely far beyond the power of any realistic adversary, an
improved S = T = 264 attack would leave us with an alarmingly narrow security
margin.

Recent work proves new lower bounds on preprocessing algorithms for various
cryptographic problems, using both incompressibility arguments [1, 25,34] and
the newer presampling method [20,67]. While this progress might give hope for an
improved lower bound for function inversion as well, both techniques mysteriously
fail to break the ST = Ω̃(N) barrier.

Non-adaptive algorithms. Another avenue for study is to explore the role
of parallelism or adaptivity in preprocessing algorithms for function inversion.
All non-trivial algorithms for function inversion, including Hellman’s algorithm
and Rainbow-table methods [63], critically use the adaptivity of their queries.
It would be very interesting to construct a highly parallelizable preprocessing
algorithm for function inversion. Such an algorithm would achieve the same
advice and time complexity S = T = Õ(N2/3) as Hellman’s algorithm, but
would make all Õ(N2/3) of its queries to the f -oracle in one non-adaptive batch.
Such a non-adaptive inversion algorithm could speed up function inversion on
cryptanalytic machines with a very large number of parallel processing cores.

We do not even know if there exists a non-adaptive algorithm with S =
T = o(N). Can we find new non-adaptive inversion algorithms, or is adaptivity
necessary for good time-space trade-offs? Proving lower bounds in this more
restricted model could be a stepping stone to improving the general lower bounds
on function inversion.

3



1.1 Our results

This work establishes new connections between the function-inversion problem and
well-studied problems in cryptography, complexity theory, and data structures.
These connections are useful in two directions.

First, they shed new light on the function-inversion problem: a connection
to circuit complexity suggests that improving on the known lower bounds for
function-inversion will be difficult. In particular, we show that new lower bounds
for function inversion will imply new circuit lower bounds and could even resolve
complexity-theoretic questions that predate Hellman’s results [68]. Moreover, a
new connection to the problem of breaking PRGs with preprocessing suggests
a new avenue for better inversion algorithms for injective functions. For many
of the cryptanalytic applications, progress on this variant of function inversion
would in fact be sufficient.

Second, these connections, together with classic cryptanalytic algorithms, give
rise to better algorithms for problems in the other areas of theory. For example,
a connection to communication complexity leads to the best known algorithm for
the multiparty pointer-jumping problem, improving upon a twenty-year-old upper
bound [65]. Similarly, a connection to data structures leads to a new upper bound
for the systematic substring-search problem, resolving an open question [31].

We now state our results in detail.

Proving better lower bounds for function-inversion implies new circuit
lower bounds. A major question in circuit complexity, open since the 1970s [68,
69], is to give an explicit family of functions Fn: {0, 1}n → {0, 1}n that cannot
be computed by fan-in-two circuits of size O(n) and depth O(log n). Following
ideas of Brody and Larsen [13], we demonstrate a close connection between this
classic problem in circuit complexity and non-adaptive preprocessing algorithms
for function inversion.

Specifically, we show that proving that every non-adaptive black-box function-
inversion algorithm that uses S = N logN/log logN bits of advice requires at
least T = Ω(N ε) oracle queries, for some constant ε > 0, would give an explicit
family of functions that cannot be computed by linear-size log-depth Boolean
circuits. This, in turn, would resolve a long-standing open problem in circuit
complexity. Though we cannot prove it, we suspect that the above lower bound
holds even for Îľ = 1.

This connection implies that proving lower bounds against non-adaptive
function-inversion algorithms that use the relatively large amount of advice
S = N logN/log logN should be quite difficult. A much more modest goal would
be to rule out any non-adaptive algorithm using S = T = Õ(N1/2+ξ), for some
ε > 0. This would represent only a slight strengthening of Yao’s ST = Ω̃(N)
bound for adaptive algorithms. However, we show that achieving even this far-
more-modest goal would improve the best known lower bound for circuits in
Valiant’s common-bits model [68,69]. This, in turn, would represent substantial
progress towards proving lower bounds against linear-size log-depth circuits.
In particular, since any lower bound against algorithms without a restriction

4



on adaptivity would only be more general, improving the ST = Ω̃(N) lower
bound for function inversion would imply new circuit lower bounds in Valiant’s
common-bits model.

We believe that the difficulty of proving such a circuit lower bound suggests
that beating the square-root barrier exhibited by both the compression [35,79]
and presampling [20,67] techniques might prove more difficult than previously
expected.

One-to-one function inversion from PRG distinguishers. Many cryptan-
alytic applications of Hellman tables (cryptanalysis of block ciphers, password
cracking, etc.) only require inverting injective functions. Does there exist a better-
than-Hellman algorithm for inverting injective functions with preprocessing?

One reason to hope for a better algorithm for injective functions is that for
the very special case of permutations, there exists an inversion algorithm with
preprocessing that achieves the improved trade-off ST = Õ(N) (i.e., S = T =
N1/2) [79]. Can we achieve the same trade-off for injective functions?

While we have not been able to answer this question yet, we do open one
possible route to answering it. In particular, we show that the problem of
inverting injective functions with preprocessing has a close connection to the
problem of breaking pseudorandom generators (PRGs) with preprocessing [2,
20,23,25,26]. Specifically, De, Trevisan, and Tulsiani [23] show that black-box
PRG distinguishers with preprocessing can realize the trade-off S = Õ(ξ2N), for
T = Õ(1) and for any choice of distinguishing advantage ξ.

We show that achieving a more general trade-off of the form ST = Õ(ξ2N),
for any constant Îľ, would imply a better-than-Hellman algorithm for invert-
ing injective functions. Thus, improving the known PRG distinguishers with
preprocessing can improve the known injective inversion algorithms.

New protocols for multiparty pointer jumping. We show that algorithms
for the black-box function-inversion problem are useful in designing new com-
munication protocols for a well-studied problem in communication complexity.
In particular, any black-box preprocessing algorithm for inverting permutations
yields a protocol for the permutation variant of the “k-party pointer-jumping”
problem (MPJpermN,k ) [10, 11, 14, 22, 58, 65, 72] in the number-on-the-forehead model
of communication complexity [16].

Then, by instantiating the permutation-inversion algorithm with a variant
of Hellman’s method, we obtain the best known protocol for MPJpermN,k for k =
ω(logN/log logN) players (this regime is in fact the most consequential for the
original motivation for studying this problem), improving the previous best
upper bound of O(N log logN/logN), by Pudlåk et al. [65], to Õ(N/k +

√
N).

We thus make progress on understanding the communication complexity of
multiparty pointer jumping, a problem with significance to ACC0 circuit lower
bounds [6, 49,80].

Beyond the quantitative improvement, our protocol is different from all
previous approaches to the problem and is an unexpected application of a
cryptanalytic algorithm to a communication-complexity problem. While the use

5



of a cryptanalytic algorithm in this context appears new, prior work has found
application of results in communication complexity to lower bounds [46] and
constructions [12] in the cryptographic setting.

This connection presents a path forward for proving non-adaptive lower bounds
for permutation inversion. In particular, we show that for every non-adaptive
black-box permutation-inversion algorithm using S bits of advice and T online
queries, it must hold that max{S, T} is at least as large as the communication
complexity of MPJpermN,3 . Any improvement on the lower bound for MPJpermN,3 would
give an improved lower bound for non-adaptive black-box permutation-inversion
algorithms. The best lower bound for MPJpermN,3 is Ω(

√
N) [3,75]. Interestingly, this

matches the best lower-bound for black-box permutation-inversion algorithms,
regardless of their adaptivity.

New time-space trade-off for systematic substring search. Finally, we
show that improved algorithms for function inversion will also imply improved
data structures for the systematic substring-search problem [24, 31,32,42,43]. In
particular, we prove that there is a preprocessing algorithm for the function-
inversion problem using few bits of advice and few online queries if and only if
there is a space- and time-efficient data structure for systematic substring search
in the cell-probe model [77]. In the systematic substring-search problem, we are
given a bitstring of length N (the “text”), and from it we must construct an
S-bit data structure (the “index”). Given a query string, we should be able to
determine whether the query string appears as a substring of the text by reading
the index and by inspecting at most T bits of the original text.

This connection is fruitful in two directions: First, we show that instantiating
this connection with the Fiat-Naor algorithm for function inversion [30] yields
an S3T = Õ(N3) systematic data structure, which is the best known in the
parameter regime S = Õ(Nι) for ι < 1. Gål and Miltersen [31] ask whether a
very strong S + T = Ω̃(N) lower bound on this problem is possible. By beating
this hypothetical lower bound, our algorithm answers their open question in the
negative.

Second, Gál and Miltersen prove an ST = Ω̃(N) lower bound for systematic
substring search. Our barrier to proving lower bounds against black-box algo-
rithms for function inversion implies that improving this lower bound would also
imply new lower bounds in Valiant’s circuit model and therefore may be quite
challenging.

1.2 Related work

We now recall a few salient related results on function inversion, and we discuss
additional related work at relevant points throughout the text.

Fiat and Naor [29,30] proved that Hellman’s algorithm [48] achieves a trade-off
of the form S2T = Õ(N2), when the algorithm needs only to invert a random
function with constant probability (i.e., in the cryptanalytically interesting case).
For the worst-case problem of inverting arbitrary functions, Fiat and Naor give
an algorithm that achieves a trade-off of the form S3T = O(N3). De, Trevisan,

6



and Tulsiani [23] improve the Fiat-Naor trade-off when the algorithm needs only
to invert the function at a sub-constant fraction of points.

For inverting functions, Yao [79] proved that every algorithm that uses S
bits of advice and makes T online queries must satisfy ST = Ω̃(N) lower bound.
Impagliazzo gives a short alternative proof [50]. Dodis et al. [25], building on
prior work [23,35], extended the lower bound to capture algorithms that invert
only a sub-constant fraction of functions f .

Barkan, Biham, and Shamir [5] show that, for a restricted class of preprocessing
algorithms, a Hellman-style trade-off of the form S2T = Õ(N2) is the best possible.
Their lower bound is powerful enough to capture the known inversion schemes,
including Hellman’s algorithm and Oechslin’s practically efficient “Rainbow tables”
technique [63]. At the same time, this restricted lower bound leaves open the
possibility that an entirely new type of algorithm could subvert their lower bound.

For inverting permutations, Yao [79] observed that a Hellman-style algorithm
can achieve the ST = Õ(N) upper bound and proved a matching lower bound.
Gennaro and Trevisan [35], Wee [73], and De, Trevisan, and Tulsiani [23] extend
this lower bound to handle randomized algorithms and those that succeed with
small probability.

Two recent works [41,54] use the function-inversion algorithm of Fiat and Naor
to obtain new algorithms for the preprocessing version of the 3-SUM problem.

1.3 Preliminaries

Notation. Through this paper, Z≥0 denotes the non-negative integers, and Z>0

denotes the positive integers. For any N ∈ Z>0 we write [N ] = {1, 2, . . . , N}. We
often identify every element x ∈ [N ] with the binary representation of x− 1 in
{0, 1}dlogNe. We use x← 4 to denote assignment and, for a finite set X , we use
x R← X to denote a uniform random draw from X . For a function f : A→ B, we
denote the image of the function as Im(f) = {f(x) | x ∈ A} ⊆ B, and y ∈ B,
we define the preimage set of y as f−1(y) := {x ∈ A | f(x) = y}. All logarithms
are base-two unless stated otherwise. Parameters S and T are always implicit
functions of the parameter N , and to simplify the bounds, we always implicitly
take S = T = Ω(1). The notation Ω̃(·) and Õ(·) hides factors polynomial in
logN .

Definition 1 (Black-box inversion algorithm with preprocessing). Let
N ∈ Z>0. A black-box inversion algorithm with preprocessing for functions on
[N ] is a pair (A0,A1) of oracle algorithms, such that A0 gets oracle access to a
function f : [N ]→ [N ], takes no input, and outputs an advice string stf ∈ {0, 1}∗.
Algorithm A1 gets oracle access to a function f : [N ] → [N ], takes as input a
string stf ∈ {0, 1}∗ and a point y ∈ [N ], and outputs a point x ∈ [N ]. Moreover,
for every x ∈ [N ], it holds that Af1 (Af0 (), f(x)) ∈ f−1(f(x)).

We can define a black-box inversion algorithm for permutations analogously
by restricting the oracle f : [N ]→ [N ] to implement an injective function. In this
case, we will often denote the oracle as π instead of f .

7



Definition 2 (Adaptivity). We say that an oracle algorithm is k-round adap-
tive if the algorithm’s oracle queries consist of k sets, such that each set of queries
depends on the advice string, the input, and the replies to the previous rounds
of queries. We call a 1-round adaptive algorithm non-adaptive. Finally, we say
that an algorithm is strongly non-adaptive if it issues a single set of queries that
only depends on the algorithm’s input, but not on the advice string. In all of the
above cases, when referring to the number of queries made by the algorithm, we
account for the sum over all rounds.

Worst case versus average case. The algorithms in Definition 1 are deter-
ministic and successfully invert all functions on all points. It is also interesting
to consider algorithms that invert successfully only with probability Îľ < 1, over
the random choice of: the function f : [N ] → [N ], the point to invert, and/or
algorithm’s randomness. As most of the results in this paper deal with barriers
for improving lower bounds, restricting ourselves to deterministic algorithms that
always succeed in inverting only makes these results stronger. In any case, assume
that all algorithms we consider halt with probability 1.

Running time versus query complexity. For the purposes of proving lower
bounds, and reductions towards proving lower bounds, it suffices to consider
the query complexity of a preprocessing algorithm’s online phase. Counting only
queries (and not computation time) only strengthens lower bounds proved in this
model. The algorithms we construct can be made to use only Õ(N) preprocessing
time in a suitable RAM model, when they are allowed to fail with small probability.
Furthermore, the running time of our algorithms’ T -query online phase is Õ(T ).

Non-uniformity. Our definition allows for “free” non-uniformity in the param-
eter N . Nevertheless, in a model that only “charges” the online algorithm for
queries to the oracle and ignores the actual running time, non-uniformity makes
little difference since a uniform algorithm can simply search for the optimal choice
of non-uniform advice without increasing its query complexity.

Shared randomness. We allow the preprocessing and online phases to access
a common stream of random bits. Allowing the adversary to access correlated
randomness in both phases only strengthens the lower bounds. Only one of our
upper bounds (Theorem 8) makes use of this correlated randomness.

2 Lower bounds on inversion imply circuit lower bounds

The motivating question of this work is whether Hellman’s S = T = Õ(N2/3)
algorithm for inverting random functions is optimal. In this section, we show
that resolving this question will require proving significant new lower bounds in
Valiant’s “common bits” model of circuits [68]. We also show that proving strong
lower bounds on non-adaptive algorithms for function inversion would imply new
lower bounds against linear-sized logarithmic-depth circuits.

We obtain these connections by observing that the function-inversion problem
is an example of a class of so called “succinct” static data-structure problems [4,

8



18, 32, 33, 42, 43, 45, 47, 51, 60, 66]. We show a barrier to proving lower bounds
against systematic data structures, which are a special case of succinct data
structures.

Related work. Brody and Larsen [13] showed that proving certain lower bounds
against linear data structures for dynamic problems would imply strong lower
bounds on the wire complexity of linear depth-two circuits. We follow their general
blueprint, but we instead focus on arbitrary algorithms for solving static data-
structure problems (e.g., function inversion), and our connection is to Valiant’s
common-bits model of circuits, rather than to linear depth-two circuits.

In recent independent work, Viola [71, Theorem 3] shows that lower bounds
against a large class of static data-structures problems imply circuit lower bounds.
In his work, Viola considers an incomparable circuit model that, on the one
hand, admits circuits of depth larger than two, but, on the other hand, restricts
the number of wires connected to the common bits. As a result, Viola’s work
does not seem to apply to the function-inversion problem within the relevant
parameter regime (namely, in the gap between Hellman’s upper bound and Yao’s
lower bound).

In another recent independent work, Dvir, Golovnev, and Weinstein [28]
connect data-structure lower bounds to matrix rigidity and circuit lower bounds.
Their focus is on linear data structures, whereas the function inversion problem,
considered in our work, does not have an apparent linear structure.

Boyle and Naor [9] make a surprising connection between cryptographic
algorithms and circuit lower bounds. They show that proving the non-existence of
certain “offline” oblivious RAM algorithms (ORAMs) [36,40,64] would imply new
lower bounds on the size of Boolean circuits for sorting lists of integers. Larsen
and Nielsen [56] recently skirted this barrier by proving a lower bound against
ORAMs in the “online” setting. Following that, Weiss and Wichs [74] showed that
a variant of the Boyle-Naor barrier still holds against “online read-only” ORAMs.

2.1 Systematic data structures and low-depth circuits

A major open question in circuit complexity is whether there exists an ex-
plicit family of Boolean functions (from n bits to one bit) that cannot be
computed by fan-in-two circuits of size O(n) and depth O(log n). An easier
problem, which is still famously difficult, is to find an explicit family of functions
Fn: {0, 1}n → {0, 1}n with n-bit output—often called Boolean operators—that
cannot be computed by this same class of circuits. Even this question has been
open since the 1970s [53,68,69].

More precisely, we say that a family of Boolean operators {Fn}n∈Z>0 , for
Fn: {0, 1}n → {0, 1}n, is an explicit operator if the decision problem associated
with each bit of the output of Fn is in the complexity class NP.

The main result of this section is that proving a certain type of data-structure
lower bound implies the existence of an explicit Boolean operator on n bits that
cannot be computed by fan-in-two circuits of size O(n) and depth O(log n). We
then show that a lower bound on function-inversion algorithms can be cast as

9



x1 x2 x3 x4
Inputs

Common
bits

Outputs

Fig. 1: Common-bits circuit with n = 4 inputs, degree d = 2, and width w = 2.

a data-structure lower bound, and therefore a function-inversion lower bound
implies a circuit lower bound.

We now give the necessary background on data-structure problems. A sys-
tematic data structure of size s and query complexity t for an operator Fn is a
pair of algorithms:
– a preprocessing algorithm, which takes as input the data x ∈ {0, 1}n and

outputs a string st ∈ {0, 1}s of length s = o(n), and
– a query algorithm, which takes as input the string st, and an index i ∈ [n],

may probe (read) t bits of the input x, and then outputs the ith bit of Fn(x).
A systematic data structure is non-adaptive if the query algorithm probes a set
of bits of the input data x whose location depends only on the index i and not
on the input data x.

The following theorem is the main result of this section.

Theorem 3. If an explicit operator {Fn}n∈Z>0 has fan-in-two Boolean circuits
of size O(n) and depth O(log n) then, for every Îľ > 0, then this operator admits a
non-adaptive systematic data structure of size O(n/log log n) and query complexity
O(nÎľ).

To prove this, we first recall Valiant’s common-bits model of circuits [68,69].

Valiant’s common-bits model. A circuit in the common-bits model of width
w and degree d computing a Boolean operator Fn: {0, 1}n → {0, 1}n contains an
input layer, a middle layer, and output layer (Figure 1). The input layer consists
of n input bits x1, . . . , xn ∈ {0, 1}, and the output layer consists of n output
gates. There are w gates in the middle layer of the circuit (the “common bits”);
each input feeds into each of these w middle gates, and the output of each of the
w middle gates feeds into each output gate. Further, each output gate reads from
at most d of the inputs. Unlike in a standard circuit, the gates in the middle
and output layers of the circuit compute arbitrary functions of their inputs. The
output of the circuit is the n-bit string formed at the output gates.

It is immediate that any Boolean operator Fn: {0, 1}n → {0, 1}n has common-
bits circuits of width n and degree 0 or, alternatively, of width 0 and degree

10



n. A non-trivial question is: For a given operator Fn and choice of degree (e.g.,
d = n1/3), what is minimal width of a common-bits circuit that computes Fn?

Lemma 4. If there exists a circuit in the common-bits model of width w and
degree d that computes an operator F : {0, 1}n → {0, 1}n, then there exists a
non-adaptive systematic data structure for F of size w and query complexity d.

Proof. Let C be a circuit in the common-bits model as in the statement of the
lemma. The data structure consists of the outputs of the w middle-layer gates in
the circuit C (i.e., the circuit’s common bits). On input i ∈ [n], the algorithm
reads all the input bits connected to the ith output gate of C and computes the
value of the output gate. Since each output gate in the circuit is connected to at
most d input bits, the query complexity of the systematic data structure is at
most d.

Theorem 3 then follows from Lemma 4 and the following result of Valiant:

Theorem 5 (Valiant [68, 69]). If every explicit operator has fan-in-two
Boolean circuits of size O(n) and depth O(log n), then for every constant Îľ > 0, ev-
ery explicit operator has circuits in the common-bits model of width O(n/log log n)
and degree nÎľ.

Viola [70, Section 3] and Jukna [52, Chapter 13] give detailed proofs of Theorem 5.

2.2 Consequences for function inversion

Observe that every function f : [N ]→ [N ] can be described using O(N logN) bits,
so there is a trivial strongly non-adaptive algorithm that inverts every function
using O(N logN) bits of advice and no queries to the function in the online
phase. We know of no non-adaptive function-inversion algorithm that inverts
with constant probability using o(N logN) bits of advice and o(N) queries. The
following theorem states that ruling out the existence of such a non-adaptive
algorithm is as hard as proving lower bounds against linear-size logarithmic-depth
Boolean circuits.

Theorem 6. If, for some Îľ > 0, every family of strongly non-adaptive black-
box algorithms for inverting functions f : [N ] → [N ] that uses O(N ε) queries
requires ω(N logN/log logN) bits of advice, then there exists an explicit operator
that cannot be computed by fan-in-two Boolean circuits of size O(n) and depth
O(log n).

The theorem considers a restricted class of inversion algorithms that: (i) may
only use strongly non-adaptive queries (the most restrictive type of query), (ii)
are only allowed, for example, O(N0.0001) queries (very few queries), and (iii)
must invert arbitrary functions with probability one (the most difficult variant of
the inversion problem).

So, even though we may suspect that there are no algorithms for inverting
functions f : [N ]→ [N ] using O(N logN/log logN) bits of advice and O(N0.0001)
non-adaptive queries, proving such an assert";"""date"",""2019-09-14T01:27:49Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2019-09-14T01:27:49Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is MiKTeX-pdfTeX 2.9.7029 (1.40.20)""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2019-09-14T01:27:49Z""
""created"",""2019-09-14T01:27:49Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-09-14T01:27:49Z""
""resourceName"",""1046.pdf""
""Author"",""""
""producer"",""pdfTeX-1.40.20""
""pdf:docinfo:producer"",""pdfTeX-1.40.20""
""pdf:unmappedUnicodeCharsPerPage"",""4"",""4"",""6"",""7"",""10"",""5"",""7"",""4"",""0"",""2"",""4"",""46"",""17"",""9"",""17"",""1"",""4"",""16"",""13"",""12"",""11"",""2"",""4"",""0"",""0"",""0"",""1"",""27"",""3"",""32"",""41"",""15"",""15"",""47"",""2"",""4"",""29""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2019-09-14T01:27:49Z""
""Last-Modified"",""2019-09-14T01:27:49Z""
""dcterms:modified"",""2019-09-14T01:27:49Z""
""title"",""""
""Last-Save-Date"",""2019-09-14T01:27:49Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2019-09-14T01:27:49Z""
""meta:save-date"",""2019-09-14T01:27:49Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is MiKTeX-pdfTeX 2.9.7029 (1.40.20)""
""Content-Length"",""770771""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""37""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""2080"",""2564"",""2537"",""2669"",""2658"",""2606"",""2483"",""2632"",""2644"",""1788"",""2324"",""2560"",""2572"",""2518"",""2694"",""2461"",""1615"",""2272"",""2433"",""2576"",""2567"",""2466"",""2294"",""2802"",""2989"",""3041"",""2555"",""2087"",""1774"",""1470"",""1278"",""1616"",""2246"",""2254"",""2142"",""2344"",""1651""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-09-14T01:27:49Z""
";https://scholar.google.com/scholar?start=850&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094588-860;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Challenges and research directions for blockchains in the internet of things;F Golatowski, B Butzin, T Brockmann… ; … on Industrial Cyber …, 2019  ieeexplore.ieee.org;;"… offers Hyperledger, Ethereum, and Corda for Azure, Amazon offers Blockchain as a Service, Oracle

offers Distributed … Examples of these applications are AI Crypto, Synapse Ai, or Dopamine …

Traceability applications: AI and blockchain are also being used in tandem to create end …";Cité 8 fois;Les 4 versions;[PDF] researchgate.net;https://www.researchgate.net/profile/Frank_Golatowski/publication/334654307_Challenges_and_Research_Directions_for_Blockchains_in_the_Internet_of_Things/links/5d386838a6fdcc370a5bf3f8/Challenges-and-Research-Directions-for-Blockchains-in-the-Internet-of-Things.pdf;;;https://scholar.google.com/scholar?start=670&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094532-620;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;On the communication complexity of key-agreement protocols;I Haitner, N Mazor, R Oshman, O Reingold… ; Innovations in …, 2019  par.nsf.gov;;"… Unfortunately, as shown by Impagliazzo and Rudich [STOC '89] and Barak and Mahmoody [Crypto

'09], such … The focus of the above works is on no-input random oracle protocols. Finding limitation

on the usefulness of random oracles for with-input protocols seems to be a more …";Cité 5 fois;Les 5 versions;[PDF] nsf.gov;https://par.nsf.gov/servlets/purl/10086783;"
On the Communication Complexity of Key-Agreement Protocols

Iftach Haitner∗† Noam Mazor†‡ Rotem Oshman § Omer Reingold ¶

Amir Yehudayoff ‖

February 15, 2018

Abstract

Key-agreement protocols whose security is proven in the random oracle model are an impor-
tant alternative to the more common public-key based key-agreement protocols. In the random
oracle model, the parties and the eavesdropper have access to a shared random function (an
“oracle”), but they are limited in the number of queries they can make to it. Unfortunately,
as shown by Impagliazzo and Rudich [STOC ’89] and Barak and Mahmoody [Crypto ’09], such
protocols can only guarantee limited secrecy: the key of any `-query protocol can be revealed
by an O(`2)-query adversary. This quadratic gap between the query complexity of the honest
parties and the eavesdropper matches the gap obtained by the Merkle’s Puzzles protocol of
Merkle [CACM ’78].

In this work we tackle a new aspect of key-agreement protocols in the random oracle model:
their communication complexity. In Merkle’s Puzzles, to obtain secrecy against an eavesdrop-
per that makes roughly `2 queries, the honest parties need to exchange Ω(`) bits. We show
that for protocols with certain natural properties, ones that Merkle’s Puzzle has, such high
communication is unavoidable. Specifically, this is the case if the honest parties’ queries are
uniformly random, or alternatively if the protocol uses non-adaptive queries and has only two
rounds. Our proof for the first setting uses a novel reduction from random-oracle protocols to
the set-disjointness problem in two-party communication complexity, which is known to have
high communication cost. For the second setting we prove the lower bound directly, using
information-theoretic arguments.

Understanding the communication complexity of protocols whose security is proven in the
random-oracle model is an important question in the study of practical protocols. Our results
and proof techniques are a first step in this direction.

Keywords: key agreement; random oracle; communication complexity; Merkle puzzles

∗The Blavatnik school of computer science,, Tel Aviv University. E-mail: iftachh@cs.tau.ac.il. Member of the
Check Point Institute for Information Security.

†Supported by ERC starting grant 638121.
‡The Blavatnik school of computer science, Tel Aviv University. E-mail: noammaz@gmail.com.
§The Blavatnik school of computer science, Tel Aviv University. E-mail: rotem.oshman@gmail.com. Supported

by the Israeli Centers of Research Excellence program 4/11 and BSF grant 2014256.
ÂśComputer Science Department, Stanford University. E-mail: reingold@stanford.edu. Supported by NSF grant

CCF-1763311.
‖Department of Mathematics, Technion-Israel Institute of Technology. E-mail: amir.yehudayoff@gmail.com.

Supported by ISF grant 1162/15.

 

ISSN 1433-8092 

Electronic Colloquium on Computational Complexity, Report No. 31 (2018)



1 Introduction

In a key-agreement protocol (Diffie and Hellman [5]), two parties communicating over an insecure
channel want to securely agree on a shared secret key, so that an eavesdropper observing their
communication cannot find the key. There are numerous candidate constructions of key-agreement
schemes, e.g., [16, 14, 1, 11], based on assumptions implying that public-key encryption schemes
exist. A fundamental open question is whether we can design key-agreement protocols based on
the security of symmetric primitives, e.g., private-key encryption; the security of such primitives is
believed to be more robust.

A first step in this direction was made by Merkle [12], presenting a key-agreement scheme called
Merkle’s Puzzles, which has some level of security in the random oracle model : the parties and the
eavesdropper have limited access to a random function (an “oracle”). In Merkle’s Puzzles, the
honest parties make ` queries, for an arbitrary parameter ` ∈ N, and the key remains secure as
long as the eavesdropper makes o(`2) oracle queries. While the quadratic gap between the `-query
honest parties and the `2-query eavesdropper achieved by Merkle’s Puzzles might not seem like
much, if the honest parties are willing to work hard enough (take large `) and only need the secrecy
of the key to hold for limited time, this limited gap might yield a good enough advantage.

It turns out that in the random oracle model it is not possible to achieve a better-than-quadratic
gap: Barak and Mahmoody [2] (following Impagliazzo and Rudich [9]) showed that Merkle’s Puzzles
have optimal secrecy, as the security of any protocol where the honest parties make O(`) queries
can be broken by an adversary that makes O(`2) queries, and can guess the secret key with high
success probability. Thus, the trade-off between the number of queries and security is completely
characterized in the random oracle model.

In this work we consider another crucial aspect of any distributed protocol: communication.
In many distributed systems, communication between the parties is the most energy and time-
consuming part of the computation, dwarfing even computation-expensive local tasks (e.g., in [4],
experiments show that a wireless network running Kerberos spends 95% of its energy consumption
on communication and only 5% on local computation). In such settings, even a key-agreement
protocol that uses a small number of queries cannot be considered truly efficient if it has high
communication requirements. In Merkle’s Puzzles, for example, the players need to send Θ(`) bits
(the answers to all their queries).

In this work we initiate the study of communication-efficient protocols in the random oracle
model. We show that under some restrictions on the protocol, the high communication incurred
by Merkle’s Puzzles is unavoidable: in order to achieve security against an adversary that can ask
Θ(`2) queries, the two parties must exchange Ω(`) bits of communication. Specifically, we show that
the bound above holds for protocols where the parties’ queries are uniformly random subsets, and
the bound also holds for any non-adaptive protocol that uses only two rounds of communication.
(These are both properties of Merkle’s Puzzles: there, the parties use uniformly random queries
and send one message each.) It is our hope that our work will initiate further interest in the
communication cost of cryptography in the random oracle model.

A key-agreement protocol is measured by two parameters: its agreement guarantee, which
is the probability that the honest parties output the same key, and its secrecy guarantee, the
probability that an eavesdropper guesses the common key. To simplify the discussion, we focus
below on protocols whose agreement guarantee is larger by some constant compared to their secrecy
guarantee. Our results generalize to any arbitrary trade-off between the protocol’s communication
cost and the eavesdropper’s query complexity.



Uniform-query protocols. An oracle protocol has uniform queries, if the parties’ oracle queries
are chosen independently and uniformly from a predetermined set. We give the following lower
bound on the communication complexity of such protocols.

Theorem 1.1 (lower bound on uniform-inputs protocols, informal). Any `-uniform-query key-
agreement protocol achieving non-trivial secrecy against o(`2)-query adversaries, has communication
complexity Ω(`).

Theorem 1.1 is proved by a novel reduction to set-disjointness — a problem in communication
complexity known to require high communication complexity, a reduction we believe to be of
independent interest. See more details in Section 1.1.1.

Two-message non-adaptive protocols. An oracle protocol has non-adaptive queries, if the
distribution of queries the parties make is fixed in advance — it is determined (arbitrarily) before
the parties communicate with each other and independently of the oracle’s answers. We give the
following lower bound on the communication complexity of such protocols.

Theorem 1.2 (lower bound on two-message non-adaptive protocols, informal). Any two-message
`-query non-adaptive key-agreement protocol of non-trivial secrecy against o(`2)-query adversaries
has communication complexity Ω(`).

We prove the above bound by presenting an o(`2)-query eavesdropper that prevents the par-
ties from exploiting the correlation induced by their random oracle calls, by asking all joint (i.e.,
intersecting) queries that the parties “understand” to be such. This is very different from the eaves-
dropper used by Barak and Mahmoody [2], and by Impagliazzo and Rudich [9]: their eavesdropper,
by making Θ(`2) queries, has high probability of finding all joint queries. Finding the right defini-
tion for what it means to “learn” that a given query is in the intersection, and constructing a low
query-complexity eavesdropper that manages to ask all such queries, is the main difficulty in our
proof. See more details in Section 1.1.2.

1.1 Our Technique

We give some high-level description of the techniques used for proving our two lower bounds (The-
orems 1.1 and 1.2).

1.1.1 Uniform-Query Protocols

The lower bound for uniform-query key-agreement protocols is proved via a reduction to set-
disjointness — two parties receive sets from a predetermined distribution, and have to decide
(by communicating) whether their sets intersect. We emphasize that the parties trying to solve
the set-disjointness problem have no oracle, but are allowed to use joint (public) randomness. Set-
disjointness was proved to require high communication complexity: for any ` ∈ N there exists
“hard” distribution over subsets of [`], such that in order to solve disjointness over this distribution
(even only with high probability), the parties have to exchange Θ(`) bits of communication. We
show how to transform an `-uniform-query key-agreement protocol of non-trivial secrecy against
o(`2)-query adversaries, to a protocol for solving set-disjointness over a hard distribution. This
yields an Θ(`) bound on the communication complexity of the key-agreement protocol. More
details below.

2



Let Π = (A,B) be an `-uniform-query key-agreement protocol. We assume for simplicity that
the key-length is one (i.e., a bit), that Π has perfect agreement (parties always agree) and that
an o(`2)-query cannot guess the key with probability larger than 3/4. We use Π to build two
(no-oracle) protocols ΛCom = (ACom,BCom) and ΛDist = (ADist,BDist), with the same communication
complexity as of Π, such that at least one of them can be used to solve set-disjointness well over
an hard distribution.

In protocol ΛCom, the parties interact in a random execution of Π using public (common) ran-
domness to emulate the random oracle: the common random string is interpreted as the description
of a random function. Since the joint distribution of the transcript and outputs induced by a ran-
dom execution of ΛCom equals to that induced by a random execution Π, protocol ΛCom has perfect
agreement. Furthermore, an adversary seeing only the protocol transcript, cannot guess the com-
mon key with probability better than 3/4. Indeed, such an adversary is equivalent to an adversary
that is trying to guess the key in a random execution of Π without using the oracle.

In the second protocol ΛDist, the parties also interact in a random execution of Π, but use their
private randomness to emulate the random oracle. In other words, each party uses a different
function as the random oracle. The joint distribution of the transcript and outputs induced by
a random execution of ΛDist, might be very far from the distribution induced by of Π. Yet, note
that conditioned that the queries are disjoint, it is easy to see that the two distributions are the
same. In particular, the perfect agreement of Π yields that the parties of ΛDist output the same
key under this conditioning. A second observation is that since the parties of ΛDist use no common
(public) randomness, their view is in a product distribution given the transcript. Hence, there exist
an adversary E that seeing only the transcript, finds the key with same probability that the parties
output the same value. Combining the above observations yields that one of the following must
holds:

Agreement gap: The agreement probability ΛDist is at most 7/8 (comparing to one in ΛCom), or

Secrecy gap: the probability that E guesses ADist’s output in ΛDist is at least 7/8 (comparing to
3/4 in ΛCom).

We start by describing the set-disjointness protocol assuming an accuracy gap exists, and later
explain how to address the case of secrecy gap.

Agreement gap. Recall that ΛDist has perfect agreement if the parties’ queries do not intersect,
and that, by assumption, its overall agreement is at most 7/8. Assume for simplicity that the
inaccuracy of ΛDist holds for every non zero intersection size. That is, the agreement probability
of ΛDist conditioned that the sets intersect with c queries is at most 7/8, for every c ∈ N. We
exploit the gap between the imperfect agreement of ΛDist when the parties’ inputs do not intersect,
to its perfect agreement when they do, to build a protocol for solving set-disjointness over any
distribution.1

The set-disjointness protocol ΛSet = (ASet,BSet) is defined as follows: first, each party permutes
its input set using a permutation defined by the common public randomness. The parties then
interact in ΛDist, with each party using the permuted value of its private input as its uniform
queries. At the end of the execution, party ASet sends its output to BSet, who outputs 1 if the
received value is equal to its own output.

1The agreement gap might only exist for some values of c. We handle this complication using specific properties

of a known hard distribution for set-disjointness. See Section 3.

3



If the parties’ input sets are disjoint, the permuted input sets are disjoint as well (the parties
permute their input sets using the same permutation defined by the public randomness) . Thus, the
parties’ outputs are equal with probability one. On the other hand, if the input sets do intersect,
the permuted input sets are random sets in the domain of the same intersection size. Thus the
parties’ output are equal with probability at most 7/8.

It follows that BSet outputs 1 with probability one if the parties’ input sets are disjoint, and with
probability at most 7/8 otherwise. Since the latter hold for any input, the above protocol solves set-
disjointness with error “too low” over hard distributions, and thus must have high communication
complexity.

Secrecy gap. We convert ΛCom and ΛDist into a pair of protocols with agreement gap, and then
continue as above. Consider protocol Λ′

Dist
= (A′

Dist
,B′

Dist
) in which the parties acts as in ΛDist, but

at the end of the execution B′
Dist

executes E on the transcript and outputs its output. Protocol
Λ′
Com

is defined analogously with respect to ΛCom. By assumption, E guesses ADist’s output in ΛDist

with probability at least 7/8, and guesses ACom’s output in ΛCom with probability at most 3/4.
Hence, Λ′

Dist
has agreement at least 7/8, and Λ′

Com
has agreement at most 3/4. Namely, there is

an agreement gap between Λ′
Dist

and Λ′
Com

, and we can apply a simple variant of the reduction
described above to solve set-disjointness.

1.1.2 Two-Message Non-Adaptive Protocols

Consider an oracle key-agreement protocol Π = (A,B). We show that to produce a shared key,
the parties of Π must transfer information about the intersection between their queries. Moreover,
the queries and their intersection need to be “unpredictable” (have high min-entropy) given the
transcript, otherwise an eavesdropper can make the same queries and neutralize the honest parties’
advantage. Since A does not know in advance her intersection with B’s queries, if she sends a short
message, she will not convey much information about the intersection; and similarly for B’s message.
More formally, if each query as probability at most δ of being asked by B, and A’s message has C
bits, then B learns no more than δC bits of information about the intersection, and this argument
can be carried to B’s return message as well. However, what should we do about queries with
probability higher than δ of being asked?

To guarantee that all queries have low prior probability of being asked by one of the players
(or viewed another way — to “neutralize” queries that are too predictable) we use a variant of the
eavesdropper of Barak and Mahmoody [2]. The eavesdropper in their work finds and queries all
the “heavy queries” — queries that were asked with probability at least δ given the eavesdropper’s
view (the messages it has seen and the queries it has asked). In our proof, we set the “heavy query”
threshold δ to Θ(1/C) instead of 1/`, where C is the communication complexity of the protocol.
Intuitively, this is because we only care about queries the players have talked to each other about,
not queries they asked but did not communicate to the other player.2 The eavesdropper asks all
the heavy queries at the beginning of every communication round, and at the end of the protocol, it
outputs the key it believes B would output, given the messages the eavesdropper observed between
the players and the queries it asked. We prove that the eavesdropper generates a total of only
Θ(C`) queries, and breaks the secrecy of the protocol.

2This is an over-simplification, since a player’s message can contain partial information about queries, e.g., XORs

of subsets of queries and so on.

4



Note that when C � `, an eavesdropper that asks only Θ(C`) queries stands no chance of finding
all the intersection queries shared by the parties. For example, if A and B each ask ` random queries,
but do not communicate with each other at all (C = 0), then our eavesdropper is not allowed to
make any queries (C · ` = 0), and in particular, even though with high probability A and B’s
queries intersect, the eavesdropper will not find an intersection query. This is a key difference
from the proof of [2, 9], whose eavesdropper with high probability asks all the intersection queries.
Nevertheless, we show that unless the parties can learn that a given query is in their intersection,
this query is not useful to them.

We assume without loss of generality that the secret key is the first bit of one of B’s queries
(we show that any protocol can be transformed into a protocol that has this property, without
harming consistency or security). The technical key to the proof is to bound the dependence
between B’s queries and A’s view: this dependence exactly captures the players’ “advantage” over
the eavesdropper. In particular, if the players can figure out an intersection query, they create a lot
of dependence that is hidden from the eavesdropper. We show that this does not happen, except
with small probability. Thus, the players have very small advantage over the eavesdropper, and
when at the end of the protocol the eavesdropper guesses B’s key, it has roughly the same chance
of agreeing with A’s key as B does.

The proof formalizes the intuition that any dependence between B’s queries and A’s view (or
vice-versa) is “created through” the intersection of their queries. We then show that (1) A’s message
does not convey much information about the intersection, and hence, (2) B’s message also does not
convey much information about the intersection.

The argument for (1) uses fairly standard ideas from information theory: when we consider n
random variables X1, . . . ,Xn and a function M(X1, . . . ,Xn), and choose an index i ∈ [n] with some
distribution that has high min-entropy, then I(M;Xi) is small. In our case, we choose not one index
but possibly several (as the intersection can be large), so the argument needs to be generalized
somewhat.3

The second message is a different story, because with some small probability, A’s first message
revealed too much information about the intersection. (The mutual information I(M;Xi) is, after
all, an expectation over messages.) If the players managed to establish such dependence, then
the eavesdropper no longer stands any chance of breaking the protocol’s secrecy. To deal with
this low-probability event, we switch to using statistical distance instead of mutual information.
Mutual information is unbounded, so even low-probability events can cost too much in expectation;
statistical distance on the other hand is bounded by one.

Statistical distance is less convenient to work with (e.g., it is not additive), so our argument for
the second message is more complex. It involves “pretending” that B learned nothing about the
intersection, proving that in this case his message also does not reveal much about the intersection,
and then switching back to the real distribution, where B knows a little about the intersection, and
accounting for the difference.

The reason we could not continue this argument to any number of rounds is that perversely,
after the second round, the eavesdropper’s own queries may create dependence between the queries
of the two parties.4 This means that, even though we bounded the dependence created by the

3For the reader familiar with Shearer’s inequality — we prove a Shearer-like statement for mutual information.
4For instance, A can send the answer to her first query, and B can reply with his first query, followed by the XOR

of the answers to his first two queries. In this case, the view of A is independent from the queries of B; however, after

the eavesdropper asks B’s first query, she learns whether or not B’s second query is equal to A’s first query. This

creates dependence between the honest parties’ views, when we condition on the eavesdropper’s view.

5



messages in the first two rounds, when the eavesdropper asks the heavy queries after the second
round, its own queries can increase the dependence and violate our bound.

1.2 Related Work

Impagliazzo and Rudich [9] showed that the key of any `-query key-agreement protocol in the
random-oracle model can be revealed by an O(`6) query eavesdropper. Barak and Mahmoody [2]
have improved upon the above presenting an O(`2) query eavesdropper for this task, yielding that
Merkle Puzzles is optimal in this respect. Haitner, Omri, and Zarosim [6] used the machinery of [2],
to show that any no-input `-query random oracle protocol, can be mapped into an “equivalent” no-
oracle protocol, using an O(`2)-query mapping, yielding that a no input task that is impassible to
achieve information theoretical, cannot be computed securely in the random-oracle model against
O(`2)-query adversaries. The focus of the above works is on no-input random oracle protocols.
Finding limitation on the usefulness of random oracles for with-input protocols seems to be a more
difficult question, Chor and Kushilevitz [3], and Mahmoody et al. [10] made some progress in this
direction. Finally, Haitner, Hoch, Reingold, and Segev [7] gave lower bounds on the communication
complexity of statistically hiding commitments and single-server private information retrieval in a
weaker oracle model that captures the hardness of one-way functions/permutation more closely.

Paper Organization

Formal definitions and notation used throughout the paper are given in Section 2. The bound for
uniform-query protocols is formally stated and proved in Section 3, and the bound for two-message
non-adaptive protocols is stated and proved in Section 4.

2 Preliminaries

2.1 Notations

We use calligraphic letters to denote sets, uppercase for random variables and lowercase for values.
For m ∈ N, let [m] = {1, . . . ,m}. For a random variable X, let x

R← X to denote that x is

chosen according to X. Similarly, for a set S let s
R← S to denote that s is chosen according to the

uniform distribution over S. The support of the distribution D, denoted Supp(D), is defined as
{u ∈ U : PrD [u] > 0}. The statistical distance between two distributions P and Q over a finite set
U , denoted SD(P,Q), is defined as 1

2

∑
u∈U |PrP [u]−PrQ [u] |, which is equal to maxS⊂U (PrP [S]−

PrQ [S]).
For a vector X = X1, ..., Xn and an index i ∈ [n], let X<i denote the vector X1, ..., Xi−1 and X≤i

denote the vector X1, ..., Xi. For a set of indexes T = {i1, . . . , ik} ⊆ [n] such that i1 < i2 < · · · < ik,
let XT denote the vector Xi1 , . . . , Xik . Similarly, XT,<i denotes the vector XT∩{1,...,i−1}. For a
function f , let f(X) = (f(X1), ..., f(Xn)).

For random variables A and B we use A|B=b to denote te distribution of A condition on the
event B = b.

2.2 Interactive Protocols

A two-party protocol Π = (A,B) is a pair of probabilistic interactive Turing machines. The com-
munication between the Turing machines A and B is carried out in rounds, where in each round

6



one of the parties is active and the other party is idle. In the j-th round of the protocol, the
currently active party P acts according to its partial view, writing some value on its output tape,
and then sending a message to the other party (i.e., writing the message on the common tape).
The communication transcript (henceforth, the transcript) of a given execution of the protocol
Π = (A,B), is the list of messages m exchanged between the parties in an execution of the protocol,
where m1,...,j denotes the first j messages in m. A view of a party contains its input, its random
tape and the messages exchanged by the parties during the execution. Specifically, A’s view is a
tuple vA = (iA, rA,m), where iA is A’s input, rA are A’s random coins, and m is the transcript of
the execution. Let outA denote the output of A in the end of the protocol, and outB B’s output.
Notice that given a protocol, the transcript and the outputs are deterministic function of the joint
view (iA, rA, iB, rB). For a joint view v, let trans(v), outA(v) and outB(v) be the transcript of the
protocol and the parties’ outputs determined by v. For a distribution D we denote the distribution
over the parties’ joint view in a random execution of Π, with inputs drawn from D by Π(D).

A protocol Π has r rounds, if for every possible random tapes for the parties, the number of
rounds is exactly r. The Communication Complexity of a protocol Π, denote as CC(Π) is the
length of the transcript of the protocol in the worst case.

2.3 Oracle-Aided Protocols

An oracle-aided two-party protocol Π = (A,B) is a pair of interactive Turing machines, where each
party has an additional tape called the oracle tape; the Turing machine can make a query to the
oracle by writing a string q on its tape. It then receives a string ans (denoting the answer for this
query) on the oracle tape. An oracle-aided protocol is `-queries protocol if each party makes at
most ` queries during each run of the protocol. In a non-adaptive oracle-aided protocol, the parties
choose their queries before the protocol starts and before querying the oracle. A uniform query
oracle-aided protocol, is a non-adaptive protocol in which the parties queries are chosen uniformly
form a predetermined set.

2.4 Key-Agreement Protocols

Since we are giving lower bounds, we focus on single bit protocols.

Definition 2.1 (key-agreement protocol). Let 0 ≤ γ, α ≤ 1 and q ∈ N . A two-party boolean output
protocol Π = (A,B) is a (q, ι, γ)-key-agreement relative to a function family F , if the following hold:

Accuracy: Π has (1− α)-accuracy. For every f ∈ F :

Pr
v

R
←Πf

[
outA(v) = outB(v)

]
≥ 1− α.

Secrecy: Π has (q, γ)-secrecy. For every q-query oracle-aided algorithm E:

Pr
f

R
←F ,v

R
←Πf

[
Ef (trans(v)) = outA(v)

]
≤ γ.

If F is a trivial function family (e.g., F only contains only the identity function), then all
correlation between the parties’ view is implied by the transcript. Hence, an adversary that on a
given transcript τ samples a random view for A that is consistent with τ , and outputs whatever A

7



would upon this view, agrees with B with the same probability as does A. This simple argument
yields the following fact.

Fact 2.2. For every 0 ≤ α ≤ 1 and 0 ≤ γ < 1− α, there exists no (q, α, γ)-key-agreement protocol
relative to the trivial family.

2.5 Entropy and Information

The Shannon Entropy of a random variable A is defined as H(A) =
∑

a∈Supp(A) PrA [a] log 1
PrA[a] .

The conditional Entropy of a random variable A given B is defined as H(A|B) = E
b
R
←B

[H(A|B = b)].
The following fact is called the chain rule of Shannon Entropy:

Fact 2.3 (Chain rule for entropy). For a random variable A = A1, ...,An the following holds:

H(A1, ...,An) =

n∑

i=1

H(Ai|A1, ...Ai−1).

The mutual information between two random variables A and B is defined as I(A;B) = H(A)−
H(A|B). The mutual information is known to be symmetric, and the following facts are known:

Fact 2.4 (Chain rule for information). For a random variables A = A1, ...,An and B,

I(A;B) =
n∑

i=1

I(Ai; B|A1, ...,Ai−1).

Fact 2.5. For every random variables A and B, 0 ≤ I(A;B) ≤ H(A) ≤ |A|.

Fact 2.6. Let A,B,C be random variables.

• If A is independent of C, Then I(A;B) ≥ I(A;B|C).

• If condition on B, A is independent of C, Then I(A;B) ≤ I(A;B|C).

Fact 2.7 (Data processing inequality). Let A,B be random variables, and f a function. Then:
I(f(A); B) ≤ I(A;B) and H(f(A)) ≤ H(A).

Lastly, a connection between mutual information and statistical distance is known:

Fact 2.8 (Pinsker’s inequality).

SD ((A,B) , (A× B)) ≤ 2
√
I(A;B).

We will also use the next general lemmas in our proof:

Lemma 2.9. For every random variables A,B,C and D it holds that

− I(A;D|C) ≤ I(A;B|C,D)− I(A;B|C) ≤ I(A;D|C,B)

.

8



Proof.
I(A;B|C,D)− I(A;B|C)

= H(A|C,D)−H(A|B,C,D)− [H(A|C)−H(A|B,C)]
= H(A|C,D)−H(A|C)− [H(A|B,C,D)−H(A|B,C)]
= I(A;D|C,B)− I(A;D|C)

The inequalities hold by the fact that mutual information is always positive. ďż˝

The next two lemmas are useful in bounding information by using Bernoulli random variables:

Lemma 2.10. Let J be a Bernoulli random variable, s.t. Pr [J = 1] ≤ 1/2. Then

H(J) ≤ Pr [J = 1] (log
1

Pr [J = 1]
+ 4).

Proof.

H(J) =Pr [J = 1] log
1

Pr [J = 1]
+ Pr [J = 0] log

1

Pr [J = 0]

≤ Pr [J = 1] log
1

Pr [J = 1]
+ log

1

1− Pr [J = 1]

Let f(x) = log 1
1−x − 4x. We need to show that f(x) ≤ 0 for all 0 ≤ x ≤ 1/2. f(0) = 0, therefore it

is enough to show that f ′(x) ≤ 0.

f ′(x) =
1

ln 2

1

1− x
− 4

≤ 2
1

1− x
− 4 ≤ 4− 4 = 0 (0 ≤ x ≤ 1/2)

ďż˝

Lemma 2.11. Let A,B,M and for each m ∈M Em be random variables. Let Jm be the indicator
for the event M = m, then

I(A;B|M,EM ) ≤
∑

m∈M

[
I(A;B|Em) + I(Jm; B|Em,A)

]
.

9



Proof.

I(A;B|M,EM ) =
∑

m∈M

Pr [M = m] I(A;B|M = m,Em)

=
∑

m∈M

Pr [Jm = 1] I(A;B|Jm = 1,Em)

≤
∑

m∈M

[
Pr [Jm = 1] I(A;B|Jm = 1,Em) + Pr [Jm = 0] I(A;B|Jm = 0,Em)

]

(Because I is non-negative)

=
∑

m∈M

I(A;B|Jm,Em)

≤
∑

m∈M

I(A, Jm; B|Em) (Chain rule)

=
∑

m∈M

[
I(A;B|Em) + I(Jm; B|Em,A)

]
(Chain rule)

ďż˝

2.5.1 Some Useful Facts

Fact 2.12 (Data processing inequality for statistical distance). Let A,B be random variables, and
f a function. Then: SD(f(A), f(B)) ≤ SD(A,B).

Fact 2.13. Let A,B,C be random variables. Then: SD((A,B), (A,C)) = E
a

R
←A

[SD(B|A=a,C|A=a)].

Fact 2.14. Let A,B,C be random variables. Then: SD((A× B), (A× C)) = SD(B,C).

Fact 2.15 (Hoeffding’s inequality[8]). Let A1, ...,An be independent random variables s.t. Ai ∈ [0, 1]
and let  = 1

nÎŁ
n
i=1Ai. It holds that:

Pr
[
Â− E

[
Â
]
≥ t

]
≤ e−2nt

2
.

Fact 2.16 (Jensen’s inequality). Let f be some convex function, and x1, ..., xn some numbers in
f ’s domain. And let w1, ..., wn be positive weights such that Σwi = 1. Then:

f(Σwixi) ≥ Σwif(xi).

The proofs for the next three lemmas are appear in Appendix B:

Lemma 2.17. Let A,B and C be random variables. Then

E
c
R
←C

[SD ((A,B|C=c) , (A|C=c)× (B|C=c))] ≤ 2SD ((A,C,B) , (A,C)× (B)) .

Lemma 2.18. Let A,B and M be random variables. Then

SD ((M,A) , (M×A)) ≤ E
b
R
←B

[SD ((M,A|B=b) , (M|B=b)× (A|B=b))] + SD ((A,B) , (A× B)) .

10



Lemma 2.19. Let A,B and M be random variables. Then

E
m

R
←M

[SD ((A,B|M=m) , ((A|M=m)× (B|M=m)))] ≤ 2 E
b
R
←B

[SD ((A,M|B=b) , ((A|B=b)× (M|B=b)))]

+ 2SD ((A,B) , (A× B)) .

For our proof we need only the following specific case of Lemma 2.19:

Corolla";"""date"",""2019-02-27T07:10:06Z""
""pdf:unmappedUnicodeCharsPerPage"",""69"",""11"",""14"",""2"",""11"",""5"",""7"",""6"",""4"",""7"",""18"",""30"",""15"",""22"",""41"",""33"",""27"",""40"",""12"",""22"",""15"",""24"",""40"",""14"",""8"",""16"",""15"",""29"",""8"",""0"",""17"",""23"",""69"",""100"",""66"",""23"",""14""
""pdf:PDFVersion"",""1.4""
""xmp:CreatorTool"",""Neevia DC Pro - PSPDF parser""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""pdfa:PDFVersion"",""A-1b""
""dcterms:created"",""2019-02-27T07:10:06Z""
""language"",""en""
""dc:format"",""application/pdf; version=""""A-1b"""""",""application/pdf; version=1.4""
""Last-Modified"",""2019-02-27T07:10:06Z""
""dcterms:modified"",""2019-02-27T07:10:06Z""
""title"",""Untitled""
""xmpMM:DocumentID"",""uuid:3599a942-3cba-11e9-0000-b511bc7ebece""
""Last-Save-Date"",""2019-02-27T07:10:06Z""
""pdf:docinfo:creator_tool"",""Neevia DC Pro - PSPDF parser""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2019-02-27T07:10:06Z""
""meta:save-date"",""2019-02-27T07:10:06Z""
""pdf:encrypted"",""false""
""dc:title"",""Untitled""
""xmp:CreateDate"",""2019-02-27T02:10:06Z""
""modified"",""2019-02-27T07:10:06Z""
""Content-Length"",""444177""
""pdf:hasMarkedContent"",""false""
""Content-Type"",""application/pdf""
""xmp:ModifyDate"",""2019-02-27T02:10:06Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""pdfaid:conformance"",""B""
""pdf:producer"",""Neevia Document Converter Pro v6.9 (http://neevia.com)""
""meta:creation-date"",""2019-02-27T07:10:06Z""
""created"",""2019-02-27T07:10:06Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""37""
""Creation-Date"",""2019-02-27T07:10:06Z""
""resourceName"",""10086783""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""2499"",""3337"",""2681"",""3071"",""3089"",""3463"",""2480"",""2507"",""1350"",""706"",""1079"",""1989"",""2412"",""1768"",""1959"",""1081"",""1449"",""2169"",""1560"",""1863"",""1750"",""1679"",""1740"",""1654"",""1355"",""1351"",""1795"",""927"",""1932"",""1910"",""1517"",""998"",""1162"",""1068"",""1609"",""882"",""358""
""access_permission:extract_content"",""true""
""pdfaid:part"",""1""
""access_permission:can_print"",""true""
""producer"",""Neevia Document Converter Pro v6.9 (http://neevia.com)""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""Neevia Document Converter Pro v6.9 (http://neevia.com)""
""pdf:docinfo:created"",""2019-02-27T07:10:06Z""
";
1619094637-1070;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;A blockchain-based access control scheme for smart grids;Y Zhou, Y Guan, Z Zhang, F Li ; 2019 International Conference …, 2019  ieeexplore.ieee.org;;"… addition, in an encryption scheme, an adversary can access the sig- nature oracle in a … D. He,

X. Huang, K.-KR Choo, and AV Vasilakos, “Bsein: A blockchain-based secure … Franklin,

“Identity-based encryption from the weil pairing,” in Advances in Cryptology — CRYPTO 2001 …";Cité 9 fois;Les 4 versions;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/9015954/9027508/09027588.pdf?casa_token=sVh4Jke8QVYAAAAA:PCStaRDbYcAH3pWXj4YpPHLiIOzNXXdenvT9sxUENtyIS7fn0gTlHeoFtOCcL4puJi4VTYYYejQ;"
		Skip to Main Content


		
			
				
				

				

			

		


		
			
				
					
						








	
		
	

	







						

						





























	
	
		
	
	
		
			

		
	

	
	
	



						





	
	
		
			
				IEEE Account

					Change Username/Password
	Update Address


			

			
				Purchase Details

					Payment Options
	Order History
	View Purchased Documents


			

			
				Profile Information

					Communications Preferences
	Profession and Education
	Technical Interests


			

			
				Need Help?

					US & Canada: +1 800 678 4333
	Worldwide:  +1 732 981 0060

					
	Contact & Support


			

		

		
			
				
					
							About IEEE Xplore
	Contact Us
	Help
	Accessibility
	Terms of Use
	Nondiscrimination Policy
	Sitemap
	Privacy & Opting Out of Cookies


						
							A not-for-profit organization, IEEE is the world's largest technical professional organization dedicated to advancing technology for the benefit of humanity.
Š Copyright 2021 IEEE - All rights reserved. Use of this web site signifies your agreement to the terms and conditions.
						

					


					

				

				
			

		

	


	
	


						
						






		
		
		
		
		
		
		
		
		
		
		
		
		
			
				
			
			
			
			
		
		
		
		
		
		

			


			

			
			


		
 		
		
			 

						
						









































	

		
		

		
		
		

		
			
		
		
		

		

		
		


		

		
		
		
		
		
		
		
		
		
		
	
	


















		
		
			
				
					
					
								
					
								
			
				
					
					
								
					
								
			
				
					
						








 



					
					
								
			
				
					
					
								
			
				
					
					
								
					
								
			
				
					
					
								
					
								
			
				
					
					
								
					
								
			
				
					
					
								
					
								
			
				
					
					
								
					
								
			
				
					
					
								
					
								
			
		
	




























		
			
					
			
					
			
					
			
				
					








					
			
					
			
					
			
					
			
					
			
					
			
					
			
		
		
	





	
	
	
	
	
	
	


	
	
	

	

















					

				

			


			
				
			
		

	";"""og:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""twitter:title"",""A Blockchain-Based Access Control Scheme for Smart Grids""
""twitter:card"",""summary""
""Description"",""At present, the access control schemes in the power grid are centralized. In the centralized system, the data of the network sensor nodes is transmitted by cent""
""og:title"",""A Blockchain-Based Access Control Scheme for Smart Grids""
""resourceName"",""09027588.pdf""
""language"",""en""
""title"",""A Blockchain-Based Access Control Scheme for Smart Grids | IEEE Conference Publication | IEEE Xplore""
""og:description"",""At present, the access control schemes in the power grid are centralized. In the centralized system, the data of the network sensor nodes is transmitted by centralized nodes, and the data itself may be illegally tamped with or lost, which can lead to reduced system reliability. For this feature, we apply blockchain technology to the design of access control schemes. In this paper, we propose a blockchain-based access control scheme that is suitable for multiple scenarios in the smart grid. Our access control scheme is based on an identity-based combined encryption, signature and signcryption scheme. In addition, we design a consensus algorithm in the power system for the consortium blockchain architecture to solve the key escrow problem of the untrusted third parties. Our scheme also ensures the confidentiality, integrity, authentication and non-repudiation of the data. Compared with the existing work, our scheme can use the same key pair to encrypt, sign and signcrypt the message, which has lower computation and communication costs in multiple scenarios of smart grids.""
""twitter:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-UA-Compatible"",""IE=Edge""
""viewport"",""width=device-width, initial-scale=1.0""
""dc:title"",""A Blockchain-Based Access Control Scheme for Smart Grids | IEEE Conference Publication | IEEE Xplore""
""twitter:description"",""At present, the access control schemes in the power grid are centralized. In the centralized system, the data of the network sensor nodes is transmitted by centralized nodes, and the data itself may be illegally tamped with or lost, which can lead to reduced system reliability. For this feature, we apply blockchain technology to the design of access control schemes. In this paper, we propose a blockchain-based access control scheme that is suitable for multiple scenarios in the smart grid. Our access control scheme is based on an identity-based combined encryption, signature and signcryption scheme. In addition, we design a consensus algorithm in the power system for the consortium blockchain architecture to solve the key escrow problem of the untrusted third parties. Our scheme also ensures the confidentiality, integrity, authentication and non-repudiation of the data. Compared with the existing work, our scheme can use the same key pair to encrypt, sign and signcrypt the message, which has lower computation and communication costs in multiple scenarios of smart grids.""
""Content-Encoding"",""UTF-8""
""Content-Type-Hint"",""text/html; charset=utf-8""
""Content-Length"",""41175""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=880&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094647-1110;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[HTML][HTML] Copyright Law on blockchains: Between new forms of rights administration and digital rights management 2.0;M Finck, V Moscon ; IICInternational Review of Intellectual Property and …, 2019  Springer;;"… The first blockchain was created to provide the technical infrastructure of Bitcoin in 2009. At the

time, the technology itself was considered to be merely a by-product of the cryptocurrency and

the term “blockchain” does not even figure in Satoshi Nakamoto's famous White Paper …";Cité 26 fois;Les 3 versions;[HTML] springer.com;https://link.springer.com/article/10.1007/s40319-018-00776-8;"
    
    
    
        
            
            
                
            

            
        
    


    
        
        

        
            
                Advertisement

                    

            

        


    
        
            
                
    
        
            
            [image: SpringerLink]
        
        
        
    


            

            
                
    
        
            
                Search
                
                    
                
            
        
        
            	
                    Log in
                


        
    

    



            

        

    

    
        
            
                
                    
                        
    
        Search SpringerLink
        
            
            
                Search
                
                    
                
            
            
                
            
            
        

    




                    

                

            

        

    



        

    
        
            
                
                
                    
                        
                            Copyright Law on Blockchains: Between New Forms of Rights Administration and Digital Rights Management 2.0
                        

                        
    
        
            
                Download PDF
                
            
        
    



                    

                

            

            
                
    
        
            
                Download PDF
                
            
        
    


            


            
                
    

            



            
                
                    
                        	Article
	
            Open Access
        
	Published: 20 December 2018



                        
                        Copyright Law on Blockchains: Between New Forms of Rights Administration and Digital Rights Management 2.0

                        	Michèle Finck1 & 
	Valentina Moscon2 


                        
                            
    IIC - International Review of Intellectual Property and Competition Law

                            volume 50, pages77–108(2019)Cite this article
                        

                        
    

                        
                            
    
        	
                    12k Accesses

                
	
                    8 Citations

                
	
                        7 Altmetric

                    
	
                Metrics details

            


    




                        

                            
    

    

                    
                


                
                    Abstract
This article examines the potential and limitations of blockchain technology and blockchain-based smart contracts in relation to copyright. Copyright has long been enforced through technological means, specifically Digital Rights Management. With the emergence of blockchains, many are now predicting a new era regarding the administration and enforcement of copyright through computer code. The article introduces the technology and related potential and limitations while stressing its capacity to act as a form of normative ordering that can express public or private objectives.



                    
    


                    

                    

                    
                        
                            Introduction
Law and technology have a complex relationship. Technology shapes legal development, while it is also shaped by law. The unfolding of copyright law confirms these dynamics as its development and enforcement have always been closely inspired by the technological state of the art.Footnote 1 With the emergence and sophistication of blockchain technology as well as blockchain-based smart contracts, some now perceive a new wave of technological transmutation on the horizon that could have a lasting influence on copyright law. Indeed, it is suggested that these technologies could provide new mechanisms for the management of intellectual property rights that could even take the place of current paradigms.

Copyright law has long leveraged the power of computer code to create binding norms for those that engage with related enforcement systems. Over the past decades, this objective has been achieved through reliance on Technological Protection Measures (TPMs) and Rights Management Information (RMI), two technologies that are key components of Digital Rights Management systems (DRM).Footnote 2
DRM and generally the technological enforcement of law, spurred by digitalization, datafication, and the online availability of copyrighted materials as well as ubiquitous computing, is transforming our understanding of law. Joel Reidenberg and Lawrence Lessig affirmed two decades ago that computer code is one of many forms of “law” (in the sense of normative constraints) that shape human behavior.Footnote 3 DRM can in certain scenarios be used as a behavior-constraining force given that computer code can enforce existing legal and contractual rules ex ante and in a more efficient manner.
At the same time, technology can also be relied on to circumvent existing legal protections.Footnote 4 DRM has been denoted as an additional layer of paracopyrightFootnote 5 constraints or technological self-protection – effectively creating a normative regime that can diverge from that designed by lawmakers. DRM as a matter of fact essentially may annihilate legally recognized protections such as exceptions and limitations in the EU and fair use under US copyright law.Footnote 6
As these problematic aspects of DRM attract wide consensus, blockchains and blockchain-based smart contracts are ever more frequently portrayed as the saving grace capable of using technology to enforce copyright law in a better and more balanced manner. Yet this depends on how these technologies are and will be designed. In this paper we provide an early examination of this area. Before introducing blockchain and blockchain-based smart contracts we chart the impact of digital rights management on copyright law taking into consideration the regulation provided for by international copyright treaties. These treaties opened up a tension between public and private ordering in the copyright law domain that has been replicated in national legislations. Examples will be taken from the US and European legal regimes, as they are influential illustrations of regional and national level implementations of international copyright law. Thereafter we provide an overview of the expected uses of blockchains and blockchain-based smart contracts as an alternative to current forms of DRM. The article will follow two main paths. Firstly, we will build on the experience gained so far with DRM systems to explore the delicate interplay between public and private ordering in blockchain environments. Whereas this is an important tension in copyright law, it also assumes a broader significance. In particular, we consider regulation of TPMs – de lege lata – and highlight – de lege ferenda – the need for legal rules to be technology neutral. We explore this point providing some general reflections on the implications of using code as a means of legal enforcement. Secondly, while looking at the prospects of application of blockchain technologies in the copyright domain we evaluate them particularly in relation to supporting an efficient and transparent administration of copyright and neighboring rights.


Digital Rights Management
In the last decades of the 20th century the information society triggered the dematerialization of copyrighted materials through digitalization while in the early 21st century datafication has reached a tipping point. This has not been without influence on copyright law. The emergence of those phenomena has caused the “fluidity” of digital subject matter leading to a paradigm shift that generated challenges for a copyright legal framework previously based on tangible assets.Footnote 7 Digital assets can, in principle, more easily be copied, mixed and shared. At the same time the dematerialization of copyrighted materials has made them more broadly accessible. This has led to a retreat of law in favor of private ordering and self-enforcement as the private sector has used the normative force of code to make it express its own interests and goals, sometimes to the detriment of public policy objectives.Footnote 8 DRM systems are a paradigmatic example of this tendency.

DRM Architecture
DRM refers to software and hardware that defines, protects and manages rules for accessing and using digital content (text, sounds, videos, etc.).Footnote 9 The first model of DRM was put forward in the late 1990s in the form of a system for controlling the distribution and use of digital material that expressed rules in machine-readable form.Footnote 10 These systems have been particularly appealing to the media industry to enforce copyright and neighboring rights protection.Footnote 11 DRM systems have evolved over time and can be used in various domains for different purposes.Footnote 12 In recent years, for example, the appeal of DRM for producers has been amplified in digital markets by the fact that the datafication and connectivity has extended DRM even to interconnected analogue products. As the Internet of Things progresses and copyright protectable software and databasesFootnote 13 become embedded in a wider range of goods the effect of DRM systems in economic and social processes may be pervasive.Footnote 14
DRM has been designed with the aim of giving right holders the broadest possible control over digital content in self-enforcing related terms and conditions of access and use.Footnote 15 For instance, DRM has been intended to support publishing and selling electronic books, digital movies, digital music, interactive games, computer software and other objects distributed in digital form.Footnote 16 Policies and business models of right holders are expressed in license agreements that leverage the exclusive rights recognized by copyright and neighboring rights to determine the rules of use of digital material. Contractual terms and conditions are translated into DRM architecture that concretely define how content can be used by third parties and restrict use possibilities accordingly.Footnote 17 Although there is no standard model of a DRM architecture, DRM solutions typically include a reference policy or business model and technical components for managing content to be protected; creating and managing licenses that specify the rules for consumption of content; tracking usage of content to ensure this is in line with license rules; and submitting packaged content for management by the DRM architecture. These components are also supported by a number of security services. The expectations on these services include guaranteeing the integrity of licenses, protecting content against tampering, authenticating consumers before protected content can be accessed, and safeguarding sensitive data at rest and in transit. These services are implemented to defend against attacks to DRM protocols, against DRM client software, and the software and hardware used to store and render the protected content.Footnote 18
Relevant components of DRM systems are technological protection measures (TPMs) and rights management information (RMI), which are both the subject of international copyright treaties.Footnote 19 TPMs include hardware and software to protect the rules and identify the content, the user’s IT system and the user him/herself. The different types of TPM all seek to provide an effective protection mechanism through which content owners may manage the use of their subject matter and access to it by third parties. TPMs can be as simple as a password system, which provides the entry of specific symbols to access a particular subject matter, or more sophisticated, capable of monitoring all conceivable uses of a work.Footnote 20 The most widely used TPMs are encryption, digital watermarking, copy control, fingerprinting, access control, authentication key management and other restrictions, all of which enforce conditions upon the users of digital subject matter. RMI is information that identifies content protected by copyright or neighboring rights, the rights owners in such content and the terms and conditions of use associated with it. It may provide the basis for user services, such as information accompanying a radio broadcast that gives right holders track and purchase details about particular songs. The WIPO Treaties protect all such RMI: information about works, phonograms and performances, as well as the identification of authors, phonogram producers, performers or other right holders. Protection also extends to information about terms and conditions of use of content. This may be either details of a license already granted or information about how and under what conditions a license can be obtained.Footnote 21
In addition, most DRM systems include certain technologies that enable the machine-readable expression of right holders’ policies, in particular rights expression languages (RELs). RELs are technical languages that have specific syntax and semantic vocabulary rules for expressing what kind of uses are permitted, forbidden or obligatory.Footnote 22 These computer markup languages express a number of permissions such as to stream, copy, delete, modify, embed, execute, export, extract, annotate, aggregate, install, backup, loan, sell, give, lease, play, print, and display in relation to a file. RELs are normally used to express rules contained in the license agreements.Footnote 23
DRM systems are variegated and their architectures are made up of many hardware and software components which are mostly proprietary and often not interoperable.Footnote 24 Interoperability of hardware and software is necessary, for example, for users to enjoy digital content from different devices.Footnote 25 For example, Netflix allows clients using a computer to watch the movies according to the licensing terms governing access and use of content and the interplay between DRM technologies that operate in their computers, the digital movie file, and on Netflix’s servers.Footnote 26 Also, Netflix’s subscribers can watch the movies with the Netflix mobile application. However, as Netflix fully relies on the Widevine DRM provided by Google,Footnote 27 it recently announced that devices that are not Google certified or have been altered will no longer work with the latest Netflix App.Footnote 28 As a result clients visiting Netflix with a device which is not fully interoperable with Netflix-streamed content cannot enjoy movies from that device. This scenario is just one example of how DRM incompatibility can hinder the enjoyment of digital subject matter.Footnote 29
The lack of interoperability is a consequence of either one company’s decision not to license its technology or, more generally, of the lack of standardization. Indeed interoperability and compatibility among different DRM systems depends on licence agreements between IT companies and standardization processes of DRM components.Footnote 30 However, establishing shared standards in the DRM domain has proven to be difficult.Footnote 31 The various existing proprietary DRM systems are often non-interoperable for at least two reasons. Firstly, companies have preferred to follow market strategies that have been aimed at not sharing some technologies with competitors. This can be seen as the consequence of incentives which strive to establish the dominating, rather an interoperable, standard and benefit from the fruits of such a monopoly (or at least market fragmentation) related to network externalities and lock-in effects.Footnote 32 Secondly, the diversity of digital content to be protected (e.g. video games, music, movies and texts) and the related variance in the relevant level of protection has made it difficult to develop a unitary standardized system.Footnote 33
However, some have argued that although lack of interoperability limits users’ experience, DRM interoperability is not always desirable.Footnote 34 To the extent that interoperability increases the network of devices and content within the reach of copyright owners, a world with interoperable DRM systems may consequently expand content control and further increase copyright owners’ control at the expense of otherwise legitimate and flexible uses. As will be explained in the following, DRMs can limit the range of uses a person can make with the digital content as a result of de facto elevation of copyright owners’ control over content.Footnote 35 In this sense, increasing interoperability between digital goods and devices should be balanced with measures allowing users’ rights to access and use digital content and flexibility. At the same time, it has been noted that, if the content industry had incentives to allow that balance among control and flexibility, then it might have incentives to develop an interoperable DRM standard, as interoperability is an important dimension of flexible use.Footnote 36
DRM Between Public and Private Ordering
DRM is an early example of how computer code can be leveraged as a means of public as well as private ordering. On the one hand, these measures give expression to elements of the copyright law regime, meaning that they are a code-based enforcement mechanism of legislative provisions providing right holders with exclusive rights. Copyright law seeks to create a balance between authors’ and users’ interests. Authors should be rewarded for their work as a means of incentivizing creativity, whereas knowledge should also be openly available.Footnote 37 As a consequence, despite recent legislative trends aimed at extending the scope and duration of copyright protection,Footnote 38 most national copyright systems recognize that copyright protection ought to be balanced with human rights, such as the right to privacy, freedom of expression, freedom of research and education, access to information and the right to participate in the cultural life of community.Footnote 39 The most important limits to copyright protection reflecting that balance include: that protection is guaranteed only if works are original; protection covers only the expressive form and not the content; the first sale doctrine and the exhaustion principle; that exclusive property rights can be subject to compulsory licenses; that exclusive rights are extinguished after a certain number of years when the subject matter of protection falls into the public domain; and copyright permitted uses such as exceptions and limitations.Footnote 40
On the other hand, DRM is a form of private ordering as the private sector has largely used these mechanisms to implement its own objectives, sometimes resulting in the disregard of legal protections such as limitations and exemptions or even in the creation of a factual exclusivity over digital subject matter not eligible for copyright protection.Footnote 41 DRM can indeed neutralize limits enshrined in law. Furthermore, in a mass-contract situation (which is the normal situation in the entertainment and culture digital market) licensors can model terms and conditions in their own favor, limiting the rights of the licensee to use the subject matter of protection.Footnote 42 Moreover, contractors in mass-markets cannot negotiate the terms of the license with the licensor individually, which has led to overly restrictive conditions.Footnote 43
With regard to copyright permitted uses, the example of academic publishing is emblematic.Footnote 44 Some publishers have converted to an e-only business supply, meaning that print versions are no longer available. Academic authors often grant publishers exclusive rights; therefore, publishers are the single source of academic subject matter and can limit use activities contractually and technically, including uses that are permissible based on statutory limitations or fair use.Footnote 45
Also, right holders offering e-books can restrict the number of times a book can be copied or printed. Alternatively, they can prohibit all copying even if the original purchaser agrees to delete their own copy.Footnote 46 Under such conditions it is impossible to transfer the e-book to third parties without transferring the reading device itself. In this business model, the exhaustion doctrine (or first-sale doctrine), which allows a book, movie or music that is legally purchased to be passed on to any third party without infringing copyright law, is challenged.Footnote 47
These examples illustrate that private ordering by code enhances the potential for abuse or misuse of an artificially created factual exclusivity. At the same time these examples also highlight that law sometimes struggles to keep up with digitalization. Going back to the example of the exhaustion doctrine (or first-sale doctrine),Footnote 48 these rules mainly reflect the widely accepted rationale of addressing the inherent contrast between exclusive rights in works and neighboring rights, and the free circulation of legally acquired goods. Exhaustion and first-sale doctrine rules were developed in a technological and economic environment in which the enjoyment and circulation of copyright-protected works presupposed their incorporation in physical carriers. These doctrines were essentially connected to the circulation of physical goods (such as, for example, books, records, etc.) and the right to enjoy the works embedded in those goods was inherent in the good itself. However, the digitalization of content has changed the modes of circulation and enjoyment of works. Both political opportunity and the legal suitability of “digital exhaustion” is challenged.Footnote 49 In this regard it has been questioned whether exhaustion rules are a better way to grant the effective operation of this area of law and businesses related thereto, creating a balance between the interests of the right owner and those of society (users). Some have recently argued that economic and legal challenges to these doctrines in the digital context provide a foundation for reconsidering exhaustion rules, suggesting that other areas of law might help in finding the abovementioned balance in the digital environment (e.g. antitrust law, consumer law).Footnote 50
Controversial Outsourcing to Private Ordering in Copyright Law
National and international law have legislated with a view to limit users’ ability to circumvent some DRM measures. The treaties on copyright and neighboring rights adopted within the framework of the World Intellectual Property Organization (WIPO) in December 1996Footnote 51 impose obligations to provide adequate legal protection and legal remedies against the circumvention of effective TPMs and the removal or alteration of RMI.Footnote 52 Attention was devoted to technological measures deployed to protect the interests of right holders.Footnote 53 These provisions parallel the substantive rules protecting copyright law and copyright neighboring rights in the sense that they safeguard the effective operation of technological means affording the exercise of copyright in the digital environment.Footnote 54 It is worth noting here that TPMs are individual technologies that protect works and other subject matter, while the term DRM, as explained above, describes more complex protection systems that use technological, contractual and statutory protection concurrently.Footnote 55 A comprehensive regulation of DRM is not provided. States fulfilling international obligations have adopted national schemes such as the US Digital Millennium Copyright ActFootnote 56 or the European Union’s Information Society Directive (InfoSoc Directive).Footnote 57 There legislative acts were enacted to implement the WIPO Treaties. Article 6 of the InfoSoc Directive contains the most general anti-circumvention provision in the European legal framework.Footnote 58 The InfoSoc Directive also harmonizes some aspects of copyright law across Europe.
US and European legislation exceeds international requirements and has been criticized for several reasons, including failing to clearly highlight the necessary functional link between technical measures protection and copyright protection.Footnote 59 The danger therefore is the excessive extension of the protection of technical measures even beyond the boundaries of exclusive rights.Footnote 60 Nonetheless, both schemes introduce strict sanctions for those who violate anti-circumvention rules.Footnote 61 Indeed, while the legal protection of technical measures is incisive, the law on the inverse situation where contracts and technical measures are used to override copyright limitations is weak. The current legislative framework does not offer effective means to limit private ordering based on contracts and technical measures, irrespective of the potential of such means to override limits to copyright exclusivity.Footnote 62
If we limit our focus to the legally permitted uses of protected subject matter (e.g. exceptions and limitations in the European legal framework and the fair use doctrine in the US), and leave aside for example the factual protection of non-protected material that should be in the public domain, one important issue is whether and how legislators reconcile legal, copyright-permitted uses with DRM. In fact, the technical prohibition of such uses – e.g. the use of works for scientific or educational purposes – is one of the typical ways in which right holders try to extend exclusivity beyond the scope intended by copyright protection.Footnote 63 Firstly, it is uncertain to what extent international copyright treaties allow contracting parties to protect technical measures, even in cases where the act of use which is prevented by such measures is permitted under a copyright limitation. It has been argued that the treaties might be interpreted as allowing the contracting parties to give preference to technical measures except in cases where the affected limitation is mandatory.Footnote 64 However, international copyright treaties provide only a few instances of mandatory copyright-permitted use.Footnote 65 At the national level, copyright legislation quite often does not provide a clear distinction as to whether a permitted use is mandatory. Derogations from copyright-permitted uses may therefore be governed by contract law, and copyright-permitted uses can be overridden through technical or contractual means (or a combination thereof).Footnote 66
Focusing on the European legal framework, the InfoSoc Directive provides very narrow and to some extent uncertain answers against the abuse of technical protection measures.Footnote 67 Article 6 of the InfoSoc Directive implements Arts. 11 WCT and 18 WPPT. As mentioned above, Art. 6(4) regulates the relationships to copyright exceptions or limitations. It is important to note first of all that Art. 6(4) specifically forbids the beneficiaries of copyright exceptions or limitations from circumventing technological measures and distributing the tools needed for such circumventions on their own. The consumer who circumvents the TPMs, even for the purpose of exerting an exception or limitation, would still be responsible for violating the anti-circumvention rules.Footnote 68 Compared to other anti-circumvention provisions around the world, the European solution is restrictive. The US, for example, has only considered the solution to exempt the user when the circumvention carried out relates to legitimate fair use.Footnote 69
Article 6(4) lists certain exceptions which Member States should ensure that their beneficiaries can enjoy even if TPMs apply.Footnote 70 More precisely, the first principle laid down in the Directive is to entrust the right holders with the task of reconciling TPMs with the safeguarding of exceptions. Adoption of “voluntary measures” by right holders appears to be the preferred solution. In the absence of “voluntary measures” taken by right holders, Member States must take appropriate measures to ensure that users can enjoy the listed exceptions, even if TPMs apply. The intervention of lawmakers is thus subsidiary to that of right holders. However, as already mentioned, the aforementioned obligation is not provided for all exceptions and limitations but only for those listed in Art. 6(4). Also, the Directive does not define the “voluntary measures” to be undertaken by right holders. Some commentators have considered “building copyright exception by design” as one example of “voluntary measures”.Footnote 71 The right holders could devise the technological measures as to accommodate some copyright exceptions and limitations. This approach, however, has been criticized with respect to its feasibility considering that copyright-permitted uses require a nuanced understanding of contextual and external circumstances which rigid computer code may be unable to replicate.Footnote 72
Further it is important to note that Art. 6(4) is very limited in scope. In fact, the limitations or exceptions to copyright listed in the InfoSoc directive are optional for Member States. If Member States do not implement exceptions under Art. 6(4), the mechanism provided for in this provision is meaningless.Footnote 73 In any case the applicability of exceptions and limitations depends directly on the methods of distribution to the public chosen by the right holder.Footnote 74 Article 6(4) establishes that where works and other subject matter have been made available on demand and access is conditioned on the formation of a contract, right holders are not obliged to undertake any activity to ensure that users can benefit from the exceptions and limitations, even though provided for by law.Footnote 75 In other words, and this is the most important restriction, Member States are not allowed to take any legislative action at all if the right holders offer technologically protected content over the Internet and access is conditional on the conclusion of an agreement.Footnote 76
This shift of copyright from public to private ordering enabled by both contracts and technological measures is highly controversial.Footnote 77 Many scholars criticized the approach of the European legislator, arguing that it conflicts with the very nature of exceptions and limitations.Footnote 78
The copyright domain accordingly confirms the ability of computer code to function as a means of private ordering. Its use has altered the factual availability of existing legal protections. It has also made possible a compression of external limits to copyright law that can be found in other fields of law such as competition law,Footnote 79 including consumer protection.Footnote 80 Right holders may in fact use DRM as a lever to influence market dynamics.Footnote 81 Code can represent a strategic barrier to entry in addition to a contract and the rules protecting the technology that facilitate its use, to erect strategic barriers even in secondary markets.Footnote 82 This has been discussed, for example, when DRM is embedded in a computer platform (think of the well-known case of video game consoles or operating systems), projecting effects both on the platform market and on the complementary goods market.Footnote 83 The technological standard may become the lever to raise barriers to market entry.Footnote 84
The use of computer code to enforce copyright legislation has accordingly generated a number of limitations and controversies. In light of such shortcomings, blockchain-based smart contracts are discussed as a new form of code to be taken into account as a potential alternative to existing systems.


Blockchain and Smart Contracts
In recent years, blockchain (also referred to as “Distributed Ledger Technology” or DLT) and blockchain-based smart contracts have been touted as suitable alternatives to current systems of DRM that could replace the latter.Footnote 85 Much hope is placed in these instruments in light of the controversies associated with DRM that we have outlined above. In this section we introduce these instruments before outlining associated promises.
Blockchain Technology
The first blockchain was created to provide the technical infrastructure of Bitcoin in 2009. At the time, the technology itself was considered to be merely a by-product of the cryptocurrency and the term “blockchain” does";"""dc.publisher"",""Springer""
""og:image"",""https://media.springernature.com/w200/springer-static/cover/journal/40319.jpg""
""twitter:card"",""summary""
""og:site_name"",""IIC - International Review of Intellectual Property and Competition Law""
""citation_reference"",""citation_title=Research handbook on the history of copyright law; citation_publication_date=2016; citation_id=CR1; citation_author=I Alexander; citation_author=T Gomez-Arostegui; citation_publisher=Edward Elgar Publishing"",""citation_title=Mastering bitcoin; citation_publication_date=2017; citation_id=CR2; citation_author=A Antonopoulos; citation_publisher=O’Reilly"",""Armstrong TK (2006) Digital rights management and the process of fair use. Harvard J Law Technol, 20: 49. Fall 2006; U of Cincinnati Public Law Research Paper No. 07-10.                      https://ssrn.com/abstract=885371                                         Accessed 30 Oct 2018"",""citation_title=An empirical analysis of smart contracts: platforms, applications, and design patterns; citation_inbook_title=Financial cryptography and data security; citation_publication_date=2017; citation_id=CR5; citation_author=M Bartoletti; citation_author=L Pompianu; citation_publisher=Springer"",""citation_title=The present and the future of DRM – musing on emerging legal problems; citation_inbook_title=Digital rights management. Technological, economic, legal and political aspects; citation_publication_date=2003; citation_pages=597-654; citation_id=CR6; citation_author=S Bechtold; citation_publisher=Springer"",""citation_journal_title=Am J Comp L; citation_title=Digital rights management in the United States and Europe; citation_author=S Bechtold; citation_volume=52; citation_publication_date=2003; citation_pages=323-382; citation_doi=10.2307/4144454; citation_id=CR7"",""citation_title=Information Society Directive; citation_inbook_title=Concise European copyright law; citation_publication_date=2016; citation_pages=421-490; citation_id=CR8; citation_author=S Bechtold; citation_publisher=Kluwer Law International"",""citation_journal_title=Int J Law Inf Technol; citation_title=Blockchain and smart contracts: the missing link in copyright licensing?; citation_author=B Bodo, D Gervais, PJ Quintais; citation_publication_date=2018; citation_id=CR9"",""Bogna J (2018) Sony develops blockchain system for digital rights management.                      https://cryptoslate.com/sony-develops-blockchain-system-for-digital-rights-management/                                        . Accessed 18 Oct 2018"",""citation_journal_title=Harv. JL Tech; citation_title=Fair use infrastructure for rights management systems; citation_author=DL Burk, JL Cohen; citation_volume=15; citation_publication_date=2001; citation_pages=42-83; citation_id=CR11"",""citation_journal_title=UCLA Law Rev; citation_title=Anti-circumvention misuse; citation_author=DL Burk; citation_volume=10; citation_publication_date=2003; citation_pages=1095-1140; citation_id=CR12"",""citation_journal_title=Fordham L Rev; citation_title=Market regulation and innovation: legal and technical standards in digital rights management; citation_author=DL Burk; citation_volume=74; citation_publication_date=2005; citation_pages=537-573; citation_id=CR13"",""Buterin V (2015) Ethereum white paper. A next generation smart contract & decentralized application platform.                      http://blockchainlab.com/pdf/Ethereum_white_paper-a_next_generation_smart_contract_and_decentralized_application_platform-vitalik-buterin.pdf                                        . Accessed 13 Aug 2018"",""Casanovas P (2015) Conceptualisation of rights and meta-rule of law for the web of data. Democracia Digital e Governo Eletrônico n. 12: 18–41.                      https://ssrn.com/abstract=2633365                                        . Accessed 8 Nov 2018"",""Caso R (2006) Digital rights management. Il commercio delle informazioni digitali tra contratto e diritto d’autore. Digital re-release, Trento.                      http://eprints.biblio.unitn.it/4375/1/Roberto.Caso_DRM.pdf                                        . Accessed 17 Oct 2018"",""Caso R (2008) Digital Rights Management: problemi teorici e prospettive applicative: atti del Convegno tenuto presso la Facoltà di Giurisprudenza di Trento il 21 ed il 22 marzo 2007. Quaderni del dipartimento di Scienze Giuridiche. Trento"",""citation_title=Il diritto d’autore dell’era digitale; citation_inbook_title=Il diritto dell’era digitale; citation_publication_date=2016; citation_id=CR18; citation_author=R Caso; citation_publisher=Il Mulino"",""Clark B (2018) Blockchain and IP law: a match made in crypto heaven?                      http://www.wipo.int/wipo_magazine/en/2018/01/article_0005.html                                        . Accessed 18 Oct 2018"",""citation_journal_title=Mich L Rev; citation_title=Lochner in cyberspace: the new economic orthodoxy of “rights management”; citation_author=JL Cohen; citation_volume=97; citation_publication_date=1998; citation_pages=462; citation_doi=10.2307/1290291; citation_id=CR21"",""Coyle K (2004) Rights expression languages: a report for the Library of Congress.                      http://www.loc.gov/standards/relreport.pdf                                        . Accessed 10 Oct 2018"",""Cortese A (2016) Blockchain technology ushers in “the internet of value”.                      https://newsroom.cisco.com/feature-content?articleId=1741667                                        . Accessed 3 April 2018"",""De Filippi P (2016) How Blockchain can support complement, or supplement intellectual property.                      https://github.com/COALAIP/specs/blob/master/presentations/COALA%20IP%20Report%20-%20May%202016.pdf                                        . Accessed 13 Dec 2018"",""citation_title=Blockchain and the law; citation_publication_date=2018; citation_id=CR27; citation_author=P Filippi; citation_author=A Wright; citation_publisher=Harvard University Press"",""citation_title=Securing digital video: techniques for DRM and content protection; citation_publication_date=2012; citation_id=CR28; citation_author=E Diehl; citation_publisher=Springer"",""citation_title=Adaptation of copyright to the information society; citation_publication_date=2015; citation_id=CR29; citation_author=G Dilşen Bulut; citation_publisher=Wissenschaftlicher Verlag Berlin"",""Docotorow C (2017) Amid unprecedented controversy, W3C greenlights DRM for the web.                      https://www.eff.org/deeplinks/2017/07/amid-unprecedented-controversy-w3c-greenlights-drm-web                                        . Accessed 7 Nov 2018"",""Duke science, technology & innovation paper No. 24. p 47 et seq.                      http://ssrn.com/abstract=1007817                                        . Accessed 18 Oct 2018"",""citation_journal_title=IIC; citation_title=Exceptions and technological measures in the European Copyright Directive of 2001; citation_author=S Dusollier; citation_volume=34; citation_issue=1; citation_publication_date=2001; citation_pages=62-75; citation_id=CR33"",""citation_journal_title=Fordham L Rev; citation_title=What contracts cannot do: the limits of private ordering in facilitating a creative commons; citation_author=N Elkin-Koren; citation_volume=74; citation_publication_date=2005; citation_pages=375-422; citation_id=CR34"",""Elkin-Koren N (2015) Copyright in a digital ecosystem: a user-rights approach. In: Okediji R (ed) Copyright in an age of limitations and exceptions. Cambridge University Press, Cambridge.                      https://ssrn.com/abstract=2637027                                        . Accessed 18 Oct 2018"",""Elkin-Koren N (2017) Fair use by design. UCLA Law Rev 64: 22.                      https://ssrn.com/abstract=3217839                                         Accessed 12 Nov 2018"",""Erickson K, Rodriguez Perez J, Sinha S (2017) How much do consumers value interoperability? Evidence from the price of DVD players.                      https://ssrn.com/abstract=2998767                                         or                      http://dx.doi.org/10.2139/ssrn.2998767                                        . Accessed 2 Nov 2018"",""citation_journal_title=J World Intellect Prop; citation_title=The right of access in digital copyright: right of the owner or right of the user?; citation_author=M Favale; citation_volume=15; citation_issue=1; citation_publication_date=2012; citation_pages=1-25; citation_id=CR38"",""citation_journal_title=SCRIPTed; citation_title=Human aspects of digital rights management: the perspective of content developers; citation_author=M Favale, N McDonald, S Faily, C Gatzidis; citation_volume=13; citation_publication_date=2016; citation_pages=289; citation_doi=10.2966/scrip.130316.289; citation_id=CR39"",""citation_journal_title=Commun ACM; citation_title=A sceptical view of DRM and fair use; citation_author=EW Felten; citation_volume=46; citation_publication_date=2003; citation_pages=56-59; citation_doi=10.1145/641205.641232; citation_id=CR40"",""Felten E (2018) Blockchain: what is it good for?                      https://freedom-to-tinker.com/2018/02/26/bloc                                        . Accessed 3 April 2018"",""Ferrari L (2006) L’incerto cammino della tutela giuridica delle misure tecnologiche di protezione del diritto d’autore: recenti orientamenti in materia di modifica di consoles per videogiochi (the troublesome path of the legal protection of the copyright anticircumvention measures: recent trends with regard to the alteration of videogames consoles). Diritto dell’Internet, p 269"",""citation_title=Blockchain regulation and governance in Europe; citation_publication_date=2018; citation_id=CR44; citation_author=M Finck; citation_publisher=Cambridge University Press"",""citation_title=Von Digital-Rights-Management zu Content Identification; citation_publication_date=2011; citation_id=CR45; citation_author=J Fitzner; citation_publisher=Nomos"",""citation_journal_title=Eur Intell Prop Rev; citation_title=Copyright imbalance: US and Australian responses to the WIPO Digital Copyright Treaty; citation_author=S Fitzpatrick; citation_volume=22; citation_publication_date=2000; citation_pages=214-228; citation_id=CR46"",""Geiger C, Frosio G, Bulayenko O (2018) The exception for text and data mining (TDM) in the proposed Directive on Copyright in the Digital Single Market – legal aspects. In-Depth Analysis, Brussels.                      http://www.europarl.europa.eu/RegData/etudes/IDAN/2018/604941/IPOL_IDA(2018)604941_EN.pdf                                        . Accessed 12 Nov 2018"",""citation_title=Research handbook on human rights and intellectual property; citation_publication_date=2015; citation_id=CR48; citation_publisher=Edwar Elgar"",""citation_journal_title=Eur Intell Prop Rev; citation_title=The cultural role(s) of collective management organizations; citation_author=DL Gervais; citation_volume=40; citation_issue=6; citation_publication_date=2018; citation_pages=349-356; citation_id=CR49"",""citation_journal_title=Comput Law Secur Rev; citation_title=Is a “smart contract” really a smart idea? Insights from a legal perspective; citation_author=M Giancaspro; citation_volume=33; citation_publication_date=2017; citation_pages=825-835; citation_doi=10.1016/j.clsr.2017.05.007; citation_id=CR50"",""citation_journal_title=Fordham Intell Prop Media Ent LJ; citation_title=Copyright 1992–2012: The most significant development?; citation_author=JC Ginsburg; citation_volume=23; citation_publication_date=2013; citation_pages=467-501; citation_id=CR51"",""Goldenfein J, Leiter A (2018) A legal engineering on the blockchain: “smart contracts” as legal conduct Jake Goldenfein and Andrea Leiter, “Legal engineering on the blockchain: ‘smart contracts’ as legal conduct”. Law and critique (Forthcoming).                      https://ssrn.com/abstract=3176363                                        . Accessed 12 Nov 2018"",""citation_journal_title=Wisconsin Law Rev; citation_title=Copyright and its substitutes; citation_author=P Goldstein; citation_volume=45; citation_publication_date=1997; citation_pages=865; citation_id=CR53"",""citation_title=Copyright highway: the law and core of copyright from Gutenberg to the celestial jukebox; citation_publication_date=2003; citation_id=CR54; citation_author=P Goldstein; citation_publisher=Stanford University Press"",""Grigg I (1996) The Ricardian contract.                      http://iang.org/papers/ricardian_contract.html                                        . Accessed 13 Aug 2018"",""citation_title=Copyright limitations and contracts. An analysis of the contract overridability of limitations on copyright; citation_publication_date=2002; citation_id=CR56; citation_author=L Guibault; citation_publisher=Kluwer Law International"",""Halaburda H (2018) Blockchain revolution without the blockchain.                      https://www.bankofcanada.ca/wp-content/uploads/2018/03/san2018-5.pdf                                        . Accessed 13 Aug 2018"",""Heap I (2017) Blockchain could help musicians make money again. Harvard Business Review.                      https://hbr.org/2017/06/blockchain-could-help-musicians-make-money-again                                        . Accessed 9 Nov 2018"",""citation_journal_title=J Digit Med Manag; citation_title=Managing digital rights with rights expression languages; citation_author=D Hess; citation_volume=4; citation_issue=1; citation_publication_date=2015; citation_pages=21-34; citation_id=CR59"",""citation_journal_title=J Copyright Soc’y USA; citation_title=Five lessons about copyright in the information society: reaction of the scientific community to over-protection and what policy makers should learn; citation_author=RM Hilty; citation_volume=53; citation_publication_date=2005; citation_pages=103-138; citation_id=CR60"",""citation_title=Balancing copyright a survey of national approaches; citation_publication_date=2012; citation_id=CR61; citation_author=RM Hilty; citation_author=S Nérisson; citation_publisher=Springer"",""citation_title=Exhaustion in the digital age; citation_inbook_title=Research handbook on intellectual property exhaustion and parallel imports; citation_publication_date=2016; citation_id=CR62; citation_author=RM Hilty; citation_publisher=Edward Elgar Publ"",""citation_title=IP and private ordering; citation_inbook_title=The Oxford handbook of intellectual property law; citation_publication_date=2018; citation_pages=10-47; citation_id=CR63; citation_author=RM Hilty; citation_publisher=Oxford University Press"",""citation_title=Permitted uses in copyright law – is there need for an international instrument?; citation_inbook_title=Comparative aspects of limitations and exceptions in copyright law; citation_publication_date=2018; citation_id=CR64; citation_author=RM Hilty; citation_author=V Moscon; citation_publisher=Cambridge University Press"",""Hohmann A (2016) Rights expression languages in libraries.                      https://hb.diva-portal.org/smash/get/diva2:970467/FULLTEXT01.pdf                                        . Accessed 10 Oct 2018"",""Holden R, Malani A (2017) Can blockchain solve the holdup problem in contracts?                      https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3093879                                        . Accessed 13 Aug 2018"",""citation_journal_title=BUJ Sci Tech L; citation_title=The misapplication of the DMCA to the aftermarket; citation_author=M Howell; citation_volume=11; citation_publication_date=2005; citation_pages=128-154; citation_id=CR67"",""Hughes J (2016) Motion pictures, markets, and copylocks. George Mason Law Rev 23. Loyola Law School, Los Angeles Legal Studies Research Paper No. 2016-10.                      https://ssrn.com/abstract=2758830                                        . Accessed 2 Nov 2018"",""Hugenholtz PB, Guibault L, Westkamp G et al. (2007) Study on the implementation and effect in Member States’ laws of Directive 2001/29/EC. Report to the European Commission, DG Internal Market. University of Amsterdam, IVIR, Amsterdam"",""citation_title=Evaluation of Logic-Based Smart Contracts for Blockchain Systems; citation_inbook_title=Rule technologies. Research, tools, and applications; citation_publication_date=2016; citation_id=CR70; citation_author=F Idelberger; citation_publisher=Springer"",""Ito K, O’Dair M (2018) A critical examination of the application of blockchain technology for intellectual property management. In: Treiblmaier H, Beck R (eds) Business transformation through blockchain, vol 2. Palgrave.                      http://eprints.mdx.ac.uk/25167/                                         (forthcoming in 2019)"",""citation_journal_title=Duke Law J; citation_title=Beyond bitcoin: issues in regulating blockchain transactions; citation_author=TI Kiviat; citation_volume=65; citation_publication_date=2015; citation_pages=605-608; citation_id=CR72"",""citation_journal_title=Proc IEEE; citation_title=The long march to interoperable digital rights management; citation_author=R Koenen; citation_volume=92; citation_issue=6; citation_publication_date=2004; citation_pages=883-897; citation_doi=10.1109/JPROC.2004.827357; citation_id=CR73"",""citation_title=Code and other laws of cyberspace; citation_publication_date=1998; citation_id=CR76; citation_author=L Lessig; citation_publisher=Basic Books"",""citation_journal_title=Wash Lee L Rev; citation_title=The law of unintended consequences: the Digital Millennium Copyright Act and the interoperability; citation_author=J Lipton; citation_volume=62; citation_publication_date=2005; citation_pages=487-546; citation_id=CR77"",""Lucchi N (2007) Countering the unfair play of DRM technologies. Texas intellectual property law journal, vol 16, No. 1; NYU Law School, Public Law Research Paper No. 07-02.                      https://ssrn.com/abstract=970995                                        . Accessed 12 Nov 2018"",""Margoni T, Dore G (2016) “Why we need a text and data mining exception (but it is not enough)”.                      https://zenodo.org/record/248048#.WXdf2oiGNEY                                        . Accessed 11 Nov 2018"",""Matzutt R et al. (2018) A quantitative analysis of the impact of arbitrary blockchain content on bitcoin.                      https://fc18.ifca.ai/preproceedings/6.pdf                                        . Accessed 3 April 2018"",""citation_journal_title=Boston Univ J Sci Technol Law; citation_title=DRM interoperability; citation_author=H Meléndez-Juarbe; citation_volume=15; citation_publication_date=2009; citation_pages=181-219; citation_id=CR81"",""citation_journal_title=Berkeley Technol Law J; citation_title=The end of friction? Property rights end contract in the Newtonian” world of online commerce; citation_author=R Merges; citation_volume=12; citation_publication_date=1997; citation_pages=116-136; citation_id=CR82"",""citation_title=Meet the unavoidable – the challenges of digital second-hand marketplaces to the doctrine of exhaustion; citation_inbook_title=Online distribution of content in the EU; citation_publication_date=2018; citation_id=CR83; citation_author=P Mezei; citation_publisher=Edward Elgar Publishing"",""citation_title=Dal peer-to-peer ai sistemi di digital rights management: primi appunti sul melting pot della distribuzione on line; citation_publication_date=2007; citation_id=CR84; citation_author=ML Montagnani; citation_publisher=Giuffrè Editore"",""citation_title=Misure tecnologiche di protezione, sistemi di DRM e barriere all’entrata; citation_inbook_title=Digital rights management. Problemi teorici e prospettive applicative; citation_publication_date=2008; citation_pages=215-239; citation_id=CR85; citation_author=ML Montagnani; citation_publisher=Trento University, Faculty of Law"",""Milosic K (2015) GRD’s Failure//music business journal.                      http://www.thembj.org/2015/08/grds-failure/                                        . Accessed 12 Nov 2018"",""citation_journal_title=Ital J Libr Inf Sci; citation_title=Rights expression languages: DRM vs. creative commons; citation_author=V Moscon; citation_volume=2; citation_issue=1; citation_publication_date=2011; citation_pages=4593-4619; citation_id=CR89"",""citation_title=Misure tecnologiche di protezione (diritto d’autore) (Technological Proctection Measures – Copyright); citation_inbook_title=Digesto delle discipline privatistiche – Sezione civile, Aggiornamento 8; citation_publication_date=2013; citation_id=CR88; citation_author=V Moscon; citation_publisher=UTET"",""citation_title=Academic freedom, copyright, and access to scholarly works: a comparative perspective; citation_inbook_title=Balancing copyright law in the digital age: some comparative perspectives; citation_publication_date=2015; citation_id=CR87; citation_author=V Moscon; citation_publisher=Springer"",""Nakamoto S (2018) Bitcoin: a peer-to-peer electronic cash system.                      https://bitcoin.org/bitcoin.pdf                                        . Accessed 20 Mar 2018"",""citation_journal_title=Commun ACM; citation_title=Bitcoin’s academic pedigree; citation_author=A Narayanan, J Clark; citation_volume=60; citation_publication_date=2017; citation_pages=36-45; citation_doi=10.1145/3132259; citation_id=CR91"",""citation_journal_title=The Yale Law J; citation_title=Copyright and a democratic civil society; citation_author=NW Netanel; citation_volume=106; citation_issue=2; citation_publication_date=1996; citation_pages=283-387; citation_doi=10.2307/797212; citation_id=CR92"",""Neuburger J (2018)                      https://www.blockchainandthelaw.com/2018/05/blockchain-as-a-content-distribution-technology-copyright-issues-abound/                                        . Accessed 8 Nov 2018"",""citation_journal_title=Calif L Rev; citation_title=The metamorphosis of contract into expand; citation_author=D Nimmer, E Brown, G Frischling; citation_volume=87; citation_publication_date=1999; citation_pages=17; citation_doi=10.2307/3481003; citation_id=CR94"",""citation_journal_title=Computer; citation_title=How computer systems embody values; citation_author=H Nissenbaum; citation_volume=34; citation_publication_date=2001; citation_pages=118-119; citation_doi=10.1109/2.910905; citation_id=CR95"",""citation_journal_title=Berkely Technol LJ; citation_title=From preemption to circumvention: if technology regulates, why do we need regulation (and vice versa)?; citation_author=H Nissenbaum; citation_volume=26; citation_publication_date=2011; citation_pages=1367-1386; citation_id=CR96"",""citation_journal_title=Nemode; citation_title=The networked record industry – How blockchain technology could transform the consumption and monetization of recorded music; citation_author=M O’Dair; citation_publication_date=2016; citation_id=CR97"",""Perkins S (2015) “Fixing” the first sale doctrine: adapting copyright law to the new media distribution paradigm. North Illinois Univ Law Rev 6(1)"",""Perry M (2005) Rights management information. In: Geist M (ed.) In the public interest: the future of Canadian copyright law.                      https://ssrn.com/abstract=1622462                                        . Accessed 15 Oct 2018"",""citation_title=Copyright in the age of online access. Alternative compensation systems in EU law; citation_publication_date=2017; citation_id=CR102; citation_author=JP Quintais; citation_publisher=Kluwer Law International"",""Reichman JH, Dinwoodie GB, Samuelson P (2007) A reverse notice and takedown regime to enable public interest uses of technically protected copyrighted works. UC Berkeley Public Law Research Paper No. 1007817: 982–1060"",""citation_journal_title=Tex L Rev; citation_title=Lex informatica: the formulation of information policy rules through technology; citation_author=JR Reidenberg; citation_volume=76; citation_publication_date=1998; citation_pages=553-593; citation_id=CR104"",""citation_title=Digital rights management. Business and technology; citation_publication_date=2002; citation_id=CR105; citation_author=B Rosenblatt; citation_author=B Trippe; citation_author=S Mooney; citation_publisher=M&T Books"",""citation_title=Integrating content management with digital rights management: imperatives and opportunities for digital content lifecycles; citation_publication_date=2003; citation_id=CR106; citation_author=B Rosenblatt; citation_author=G Dykstra; citation_publisher=Giant Steps"",""citation_journal_title=Berkeley Technol Law J; citation_title=Intellectual property and the digital economy: why the anti-circumvention regulations need to be revised; citation_author=P Samuleson; citation_volume=14; citation_publication_date=1999; citation_pages=504-566; citation_id=CR107"",""citation_title=Freedom to tinker; citation_inbook_title=Revolutionizing innovation: users, communities, and open innovation; citation_publication_date=2016; citation_id=CR108; citation_author=P Samuelson; citation_publisher=MIT Press"",""citation_journal_title=Comput Law Secur Rev; citation_title=Copyright in the blockchain era: promises and challenges; citation_author=A Savelyev; citation_volume=34; citation_publication_date=2018; citation_pages=550-561; citation_doi=10.1016/j.clsr.2017.11.008; citation_id=CR110"",""citation_title=WIPO Copyright Treaty; citation_inbook_title=Concise European copyright law; citation_publication_date=2016; citation_pages=93-139; citation_id=CR112; citation_author=M Senftleben; citation_publisher=Kluwer Law International"",""Silver J (2016) Blockchain or the chaingang? Challenges, opportunities and hype: the music industry and blockchain technologies, CREATe Working Paper.                      https://www.create.ac.uk/publications/blockchain-or-the-chaingang-challenges-opportunities-and-hype-the-music-industry-and-blockchain-technologies/                                        . Accessed 25 Oct 2018"",""citation_journal_title=Berkeley Technol LJ; citation_title=Shifting the possible: How digital property rights challenge US to rethink digital publishing; citation_author=M Stefik; citation_volume=12; citation_publication_date=1997; citation_pages=137-159; citation_id=CR115"",""Szabo N (1996) Smart contracts: building blocks for digital markets.                      http://www.fon.hum.uva.nl/rob/Courses/InformationInSpeech/CDROM/Literature/LOTwinterschool2006/szabo.best.vwh.net/smart_contracts_2.html                                        . Accessed 13 Aug 2018"",""Tresise A et al. (2018) What blockchain can and can’t do for copyright.                      https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3227381                                        . Accessed 8 Nov 2018"",""citation_journal_title=Berkeley Technol LJ; citation_title=Copyright formalities in the internet age: filters of protection or facilitators of licensing; citation_author=S Gompel; citation_volume=28; citation_publication_date=2013; citation_pages=1425; citation_id=CR119"",""von Lohmann F (2010) Unintended consequences: twelve years under the DMCA                      https://www.eff.org/wp/unintended-consequences-under-dmca                                        . Accessed 9 Oct 2018"",""citation_title=The whale and the reactor; citation_publication_date=1986; citation_id=CR121; citation_author=L Winner; citation_publisher=University of Chicago Press"",""citation_journal_title=Rev Finance; citation_title=Corporate governance and blockchains; citation_author=D Yermack; citation_volume=21; citation_publication_date=2017; citation_pages=7-31; citation_id=CR122"",""citation_journal_title=Philos Technol; citation_title=Digital art as “monetised graphics”: enforcing intellectual property on the blockchain; citation_author=M Zeilinger; citation_publication_date=2016; citation_id=CR123""
""citation_journal_title"",""IIC - International Review of Intellectual Property and Competition Law""
""language"",""en""
""citation_cover_date"",""2019/01/01""
""og:description"",""This article examines the potential and limitations of blockchain technology and blockchain-based smart contracts in relation to copyright. Copyright has long been enforced through technological means, specifically Digital Rights Management. With the emergence of blockchains, many are now predicting a new era regarding the administration and enforcement of copyright through computer code. The article introduces the technology and related potential and limitations while stressing its capacity to act as a form of normative ordering that can express public or private objectives.""
""prism.issn"",""2195-0237""
""citation_author_email"",""michele.finck@ip.mpg.de"",""valentina.moscon@ip.mpg.de""
""twitter:image:alt"",""Content cover image""
""prism.number"",""1""
""citation_issn"",""2195-0237""
""citation_language"",""en""
""dc:title"",""Copyright Law on Blockchains: Between New Forms of Rights Administration and Digital Rights Management 2.0 | SpringerLink""
""Content-Encoding"",""UTF-8""
""citation_pdf_url"",""https://link.springer.com/content/pdf/10.1007/s40319-018-00776-8.pdf""
""citation_lastpage"",""108""
""DOI"",""10.1007/s40319-018-00776-8""
""citation_fulltext_world_readable"",""""
""citation_journal_abbrev"",""IIC""
""prism.rightsAgent"",""journalpermissions@springernature.com""
""citation_author"",""Michèle Finck"",""Valentina Moscon""
""resourceName"",""s40319-018-00776-8""
""dc.date"",""2018-12-20""
""citation_springer_api_url"",""http://api.springer.com/metadata/pam?q=doi:10.1007/s40319-018-00776-8&api_key=""
""citation_issue"",""1""
""prism.volume"",""50""
""prism.publicationName"",""IIC - International Review of Intellectual Property and Competition Law""
""citation_doi"",""10.1007/s40319-018-00776-8""
""dc.title"",""Copyright Law on Blockchains: Between New Forms of Rights Administration and Digital Rights Management 2.0""
""prism.url"",""https://link.springer.com/article/10.1007/s40319-018-00776-8""
""citation_volume"",""50""
""dc.language"",""En""
""Content-Language"",""en""
""format-detection"",""telephone=no""
""citation_publication_date"",""2019/01""
""prism.endingPage"",""108""
""citation_title"",""Copyright Law on Blockchains: Between New Forms of Rights Administration and Digital Rights Management 2.0""
""citation_author_institution"",""Dr.; Senior Research Fellow, Max Planck Institute for Innovation and Competition, Munich, Germany"",""Ph.D; Senior Research Fellow, Max Planck Institute for Innovation and Competition, Munich, Germany""
""access"",""Yes""
""citation_publisher"",""Springer Berlin Heidelberg""
""applicable-device"",""pc,mobile""
""dc.format"",""text/html""
""description"",""This article examines the potential and limitations of blockchain technology and blockchain-based smart contracts in relation to copyright. Copyright has l""
""title"",""Copyright Law on Blockchains: Between New Forms of Rights Administration and Digital Rights Management 2.0 | SpringerLink""
""citation_online_date"",""2018/12/20""
""twitter:site"",""@SpringerLink""
""dc.source"",""IIC - International Review of Intellectual Property and Competition Law 2018 50:1""
""dc.type"",""OriginalPaper""
""dc.copyright"",""2018 The Author(s)""
""dc.creator"",""Michèle Finck"",""Valentina Moscon""
""citation_fulltext_html_url"",""https://link.springer.com/article/10.1007/s40319-018-00776-8""
""prism.publicationDate"",""2018-12-20""
""Content-Type"",""text/html; charset=UTF-8""
""journal_id"",""40319""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""dc.description"",""This article examines the potential and limitations of blockchain technology and blockchain-based smart contracts in relation to copyright. Copyright has long been enforced through technological means, specifically Digital Rights Management. With the emergence of blockchains, many are now predicting a new era regarding the administration and enforcement of copyright through computer code. The article introduces the technology and related potential and limitations while stressing its capacity to act as a form of normative ordering that can express public or private objectives.""
""og:type"",""article""
""citation_article_type"",""Article""
""og:title"",""Copyright Law on Blockchains: Between New Forms of Rights Administration and Digital Rights Management 2.0""
""prism.doi"",""doi:10.1007/s40319-018-00776-8""
""X-UA-Compatible"",""IE=edge""
""citation_firstpage"",""77""
""prism.startingPage"",""77""
""viewport"",""width=device-width, initial-scale=1""
""dc.rightsAgent"",""journalpermissions@springernature.com""
""prism.section"",""OriginalPaper""
""dc.identifier"",""doi:10.1007/s40319-018-00776-8""
""dc.subject"",""IT Law, Media Law, Intellectual Property""
""og:url"",""https://link.springer.com/article/10.1007/s40319-018-00776-8""
""prism.copyright"",""2018 The Author(s)""
";https://scholar.google.com/scholar?start=920&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094630-1036;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Blockchain ??? ?????? ?????????: ????????? ??? ???????????.;? ????????? ;2019 apothetirio.lib.uoi.gr;;"… Page 9. 8 ABSTRACT Blockchain became a popular topic soon after the emergence of bitcoin.

Bitcoin is the most successful example of cryptocurrency, until today … Keywords: blockchain,

smart contracts, cryptocurrency Page 10. 9 ??????? ???????????? …";Autres articles;Version HTML;[PDF] uoi.gr;https://apothetirio.lib.uoi.gr/xmlui/bitstream/handle/123456789/9945/BLOCKCHAIN%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20.pdf?sequence=1;;;https://scholar.google.com/scholar?start=850&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094661-1167;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;The potentials of smart contract in Islamic trade finance;L Safina, UA Oseni ; Fintech in Islamic Finance: Theory and …, 2019  books.google.com;;"… For example, cryptocurrency such as bitcoin, which is also based on blockchain technology, is

trading the value of its … If PKI, hash function and digital time stamp are the underlying technologies

of blockchain technology, which is the basis of smart contract, Oracle is the …";Cité 1 fois;Les 3 versions;[PDF] iefpedia.com;http://www.iefpedia.com/english/wp-content/uploads/2019/12/EBOOK9250.pdf#page=240;"


FINTECH IN ISLAMIC FINANCE

Featuring high-level analysis of Islamic law, this book examines fintech in 
Islamic finance from both theoretical and empirical perspectives. Whilst build-
ing on existing approaches, it also discusses the current application of fintech in 
promoting financial inclusion through innovative solutions in Muslim-majority 
countries, identifying future directions for policy-makers.

With original chapters written by prominent academics, senior lawyers and 
practitioners in the global Islamic finance industry, this book serves as the first 
standalone pioneering reference work on fintech in Islamic finance. It also, for 
the first time, examines the position of Islamic law on cryptocurrencies, such 
as bitcoin. Besides the conceptual analysis of the Sharī‘ah and legal aspects of 
fintech in Islamic finance, this book provides relevant case studies showing cur-
rent and potential developments in the application of fintech in various sectors 
ranging from crowdfunding and smart contracts, to Online Dispute Resolution, 
Investment Account Platform and identity verification in the KYC process.

Setting the agenda for researchers in the field, Fintech in Islamic Finance will be 
useful to students and scholars of Islamic finance and financial technology.

Umar A. Oseni is an Executive Director of the International Islamic Liquidity 
Management Corporation. He was an Associate Professor of Law and Regulation 
of Islamic Finance at the International Islamic University Malaysia.

S. Nazim Ali is Director of the Research Division of the College of Islamic 
Studies, at Hamad Bin Khalifa University. He was the Director of the Islamic 
Finance Project at Harvard University from 1995 to 2014.



https://taylorandfrancis.com/


FINTECH IN ISLAMIC 
FINANCE

Theory and Practice

Edited by Umar A. Oseni and S. Nazim Ali



First published 2019
by Routledge
2 Park Square, Milton Park, Abingdon, Oxon OX14 4RN

and by Routledge
52 Vanderbilt Avenue, New York, NY 10017

Routledge is an imprint of the Taylor & Francis Group, an informa business

Š 2019 selection and editorial matter, Umar A. Oseni and S. Nazim Ali; 
individual chapters, the contributors

The right of Umar A. Oseni and S. Nazim Ali to be identified as the 
authors of the editorial material, and of the authors for their individual 
chapters, has been asserted in accordance with sections 77 and 78 of the 
Copyright, Designs and Patents Act 1988.

All rights reserved. No part of this book may be reprinted or reproduced 
or utilised in any form or by any electronic, mechanical, or other 
means, now known or hereafter invented, including photocopying and 
recording, or in any information storage or retrieval system, without 
permission in writing from the publishers.

Trademark notice: Product or corporate names may be trademarks 
or registered trademarks, and are used only for identification and 
explanation without intent to infringe.

British Library Cataloguing-in-Publication Data
A catalogue record for this book is available from the British Library

Library of Congress Cataloging-in-Publication Data
A catalog record has been requested for this book

The views expressed in this book are those of the respective authors 
and do not necessarily reflect the views or policies of any organisation 
that any of the editors are currently serving or have served before in 
whatever capacity.

ISBN: 978-1-138-49479-4 (hbk)
ISBN: 978-1-138-49480-0 (pbk)
ISBN: 978-1-351-02558-4 (ebk)

Typeset in Bembo
by Deanta Global Publishing Services, Chennai, India



CONTENTS

List of figures viii
List of tables ix
Acknowledgements x
List of abbreviations xii
List of contributors xiv

PART I
INTRODUCTION 1

1 Fintech in Islamic finance 3
Umar A. Oseni and S. Nazim Ali

PART II
FINTECH AND FINANCIAL INTERMEDIATION 17

2 Fintech: The opportunity for Islamic finance 19
Harris Irfan and Daniel Ahmed

3 Implications of technological advance for financial 
intermediation in Islamic finance 33
Rodney Wilson

4 Fintech in Islamic finance: From collaborative finance to 
community-based finance 47
Celia de Anca



vi  Contents 

5  Financial intermediation, fintech and Sharī‘ah compliance 64
Shariq Nisar and Umar Farooq

6  E-commerce and Islamic financial intermediation 75
Hafis Bello

PART III
SETTING THE SHARĪ‘AH PARAMETERS 91

7  Fintech in the light of maqāsid al-Sharī‘ah 93
Mustafa Omar Mohammed and Mohamed Cherif El Amri

8  Fintech and Islamic finance: Setting the Sharī‘ah parameters 113
Mohamad Akram Laldin and Hafas Furqani

9  Currency in Islamic Law: A Sharī‘ah analysis of bitcoin 120
Mufti Faraz Adam and Mufti Abdul Kadir Barkatulla

10 Crowdfunding in Islamic Finance: Ensuring proper 
Sharī‘ah oversight 132
Muhammad Al-Amine Muhammad Al-Bashir

PART IV
LEGAL AND REGULATORY ISSUES 157

11 The regulation of fintech and cryptocurrencies 159
Nafis Alam and Abdolhossein Zameni

12 Fintech in Islamic finance: Business models and the need  
for legal solutions 174
Michael Gassner and Jonathan Lawrence

13 Blockchain technologies and the prospects of smart  
contracts in Islamic finance 183
Volker Nienhaus

14 The potentials of smart contract in Islamic trade finance 215
Leisan Safina and Umar A. Oseni



 Contents  vii

PART V
CASE STUDIES: FROM CONCEPT TO APPLICATION 233

15 The emergence of Islamic crowdfunding platforms:  
A case study of Ethis Ventures 235
Ahmad A. Sabree and Umar Munshi

16 The Investment Account Platform: A practical application 
of fintech in Malaysia 249
Noor Suhaida binti Kasri and Marjan Muhammad

17 Integrating waq f crowdfunding into the blockchain:  
A modern approach for creating a waq f market 266
Magda Ismail Abdel Mohsin and Aishath Muneeza

18 Blockdentity: A future beyond digital identity 281
Ishaq Mustapha Akinlaso, Ibrahim Opeyemi Adediran,  
Abdoulaye Kindy Diallo and Ziyaad Mahomed

19 Banking on ICT: The relevance of online dispute 
resolution in the Islamic banking industry in Malaysia 303
Umar A. Oseni and Sodiq O. Omoola

PART VI
FUTURE DIRECTIONS 325

20 Current trends and future impacts of fintech in Islamic  
finance 327
Sirajulhaq Yasini and Marifatulhaq Yasini

Index 337



FIGURES

 4.1   Community banking 51
 6.1   Retail e-commerce sales worldwide from 2014 to 2021  

(in billion US dollars)  80
 6.2   Global B2B e-commerce gross merchandise volume  

(GMV) from 2013 to 2017 (in billion US dollars)  81
 7.1   Al-Ghazali’s theoretical framework of maqāsid  99
 7.2   Sekaran’s operationalisation method 102
 7.3   Fintech maqāsid framework (FMF) 107
15.1   EthisCrowd mudārabah model 2017  242
16.1   General structure of investment account platform 252
18.1   Evolution of human identity 282
18.2   Trust, identity and transaction 283
18.3   Traditional identity system 287
18.4   Largest data-breach cases 2008–2018 290
18.5   Blockdentity snapshot 292
18.6   Personality identity information exposure:  

Traditional system vs Blockdentity 294
18.7   Blockdentity: Marketplace overview 296
19.1   Proposed Islamic finance ODR flowchart 317



TABLES

 4.1  Components of fintech in Islamic finance 57
 5.1  Fintech scope in the financial sector 68
 5.2  Potential direction and scope for fintech in enhancing 

Sharī‘ah compliance 72
 7.1  The dimensions of the essential of Māl 106
 7.2  The relationships between the dimensions and elements  

of the essential of Māl 108
 7.3  The relationships between the elements of the  

essential of Māl 109
 7.4  The relationships between the dimensions, elements and  

proposed indicators of the essential of Māl 110
16.1  Ventures funded through IAP (as at December 2017) 254
16.2  Brief information on Kobimbing Venture 255
16.3  Brief information on PKTB Venture 257
16.4  Brief information on ICT Zone Venture 258
16.5  Volume of fundraising via IAP (as at December 2017) 261



The whole idea of coming up with a book that brings together different concepts 
and case studies on fintech in Islamic finance started after the successful staging 
of the 11th LSE-HBKU Workshop on “Fintech and Islamic Finance: Applying 
Hiyal & Makharij and other Islamic Principles”. The workshop was held on 23 
February 2017 at the London School of Economics (LSE). Leading finance, legal 
and Sharī‘ah experts attended the workshop at LSE which was moderated by 
Professor Frank Vogel. We would like to thank the moderator, participants and 
the host, LSE.

After the workshop, which was very engaging and rich in discussion, we 
decided to invite some key contributors from across the world who are accom-
plished professionals to contribute to a book believed to be the first of its kind. 
Some of the chapters in this book were developed later based on preliminary 
written comments submitted for the workshop. From that moment onwards, we 
widened the potential contributors’ base to include other leading authors.

This painstaking effort in identifying leading authors for this pioneering 
project is unprecedented; and we would like to thank all contributors for their 
support and cooperation throughout the editing process. Despite the numerous 
iterations with the authors and scores of correspondences to ensure all chapters 
were turned in within a reasonable time, we found the authors to be very coop-
erative and responsive. We are convinced that this would not have been possible 
without the constant reminders from the publisher to meet the timeline for the 
book. Specifically, we appreciate the efforts of one of the contributors, Dr. Sodiq 
Omoola, and a research scholar, Abdurahman Jemal Yesuf, both of whom helped 
at different stages in ensuring all chapters comply with the standard referencing 
style in a consistent manner.

It is worth noting that Chapter 19 is reprinted by permission of Taylor & 
Francis. The original publication appeared as: “Banking on ICT: The relevance 

ACKNOWLEDGEMENTS



 Acknowledgements  xi

of online dispute resolution in the Islamic banking industry in Malaysia” by 
Umar A. Oseni & Sodiq O. Omoola Information & Communications Technology Law 
Vol 24:2 pp. 205–223 (2015).

We would like to thank the Publisher, Taylor & Francis, and its editors, par-
ticularly the fantastic Acquisition Editor, James “Joe” Whiting who understood 
the urgent need for the book from the very moment we introduced the topic 
to him. We wish to formally acknowledge Taylor and Francis Group, Ethis 
Ventures, and IAP Integrated Sdn Bhd, whose materials were used in some of 
the chapters of the book.

We hope these humble efforts will help to spur further research in this unique 
field and trigger further innovative fintech products, services and solutions in the 
global Islamic financial services industry.

Umar A. Oseni
S. Nazim Ali



AAOIFI Accounting and Auditing Organisation for Islamic Financial 
Institutions

ADR Alternative Dispute Resolution
AH After Hijrah. This is used to denote the Islamic Calendar, which 

counting began in the year Prophet Muhammad migrated from 
Makkah to Medina

AI Artificial Intelligence
AML Anti-Money Laundering
API Application Programming Interface
ATM An automated teller machine
B2B Business-to-business or trade conducted between business via the 

internet.
B2C Business-to-consumers or trade conducted between businesses 

and consumers via the internet.
BSAS Bursa Suq Al-Sila – an online platform in Malaysia for managing 

commodity murābahah transactions
BTC Bitcoin
CMTP Commodity Murabahah Trading Platform
CPU Central Processing Unit
DAG Directed acyclic non-recursive graph for storing transactions
DAO Decentralised autonomous organisation
DAPPS Decentralised applications
DFSA Dubai Financial Services Authority
DIAO Decentralised intelligent autonomous organization
DLT Distributed Ledger Technology
DMCC The Dubai Multi Commodities Centre
ECF Equity crowdfunding

ABBREVIATIONS



 Abbreviations  xiii

EPR Expected Profit Rate
ESG Environmental, Social and Governance
EY Ernst & Young
FAST Malaysia’s Fully Automated System for issuing/Tendering
GAFA Google, Amazon, Facebook and Apple
GCC Gulf Cooperation Council
GDP Gross Domestic Product
GDPR The European Union General Data Protection Regulation
GPS Global Positioning System
HNWI High Net Worth Investors
HTTP A simple but universal mechanism for retrieving resources
IAP Investment Account Platform
ICO Initial coin offering or initial currency offering (sometimes called 

“initial public coin offering”)
IFSB Islamic Financial Services Board
ICT Information and Communications Technology
IOT Internet of Things
IOTA A Distributed Ledger Technology developed by the IOTA 

Foundation
KYC Know Your Customer
LEI Legal entity identifier
MEPS Malaysian Electronic Payment System
MSMES Micro, Small and Medium Enterprises
ODR Online Dispute Resolution
P2P Peer-to-Peer
PBUH Peace be upon him [Prophet Muhammad]
R&D Research and development
REGTECH Regulatory technology
RELAB Regulatory laboratory
ROI Return on Investment
S&P Rating agency, Standard and Poor’s
SDG United Nations Sustainable Development Goals 2030
SME Small and medium enterprises
SPV Special Purpose Vehicles
SRI Socially Responsible Investing (or Investments)
SSID Self-Sovereign Identity
URIS A way to identify entities



Abdolhossein Zameni is a Lecturer at Henley Business School, University of 
Reading Malaysia. He obtained a BSc in Industrial Engineering at Mazandaran 
University of Science and Technology in Iran. In 2006, in order to pursue his 
education in an international environment, he moved to Malaysia and obtained 
his MBA in Finance at Multimedia University. In 2014, he was awarded a PhD in 
Finance by the National University of Malaysia (UKM). Dr. Zameni has experi-
ence in the delivery of educational programmes at undergraduate level, as well as 
business experience within the fields of finance, accounting and industry. His area 
of research revolves around IPO and fintech regulatory issues.

Abdoulaye Kindy Diallo is currently exploring application of blockchain technol-
ogy in the financial services industry. He holds a dual master’s degree in Science 
and Islamic Finance and a Bachelor’s degree in Computer Science. With nearly a 
decade experience in the IT industry, he works to bridge the gap between IT and 
Islamic Finance. 

Ahmad A. Sabree is the former Head of Business and Sharī‘ah Development and 
crowdfunding specialist for Ethis Ventures, and is from Atlanta, Georgia. He holds 
a BSc in Usul al-Fiqh (Sharī‘ah) and an MSc in Islamic Banking and Finance, both 
from International Islamic University Malaysia (IIUM). His thesis was on the topic 
of “Adapting Crowdfunding for SME Finance in Malaysia”. His research led him to 
become a specialist and consultant in crowdfunding. Ahmad provided Sharī‘ah and 
crowdfunding consultation to lawyers structuring the first Islamic P2P crowdfund-
ing contracts in Malaysia and was instrumental in coordinating Sharī‘ah discussions 
and decisions with leading international Sharī‘ah advisories to acquire the associ-
ated Pronouncements of Shariah compliance.

CONTRIBUTORS



 Contributors  xv

Aishath Muneeza is an Associate Professor at the International Centre for 
Education in Islamic Finance (INCEIF), Kuala Lumpur, Malaysia. She is the first 
female Deputy Minister of Ministry of Islamic Affairs and is the former Deputy 
Minister of Ministry of Finance & Treasury of the Republic of Maldives. She is 
also the chairwoman of Maldives Centre for Islamic Finance. She is considered 
to be the founder of Islamic finance in the Maldives. Her contribution to Islamic 
finance includes structuring of the corporate sukuks and sovereign private sukuk 
of the country, including the Islamic treasury instruments. She also drafted the 
Islamic Capital Market framework of the country and has been the only regis-
tered Sharī‘ah adviser for the Islamic capital market in the country since 2013. She 
played a key role in setting up the Tabung Haji of the Maldives, the Maldives Hajj 
Corporation, and was its first chairperson. She sits on various Shariah advisory 
bodies nationally and internationally and is chairman for many of these Shariah 
advisory bodies, including the apex Shariah Advisory Council for capital market 
in the Maldives. She has assisted more than 11 institutions to offer Islamic financial 
products/services.

Celia de Anca is currently the Director of the Saudi-Spanish Centre for Islamic 
Economics and Finance at IE Business School, Spain. She was previously the 
Director of Corporate Programmes at the Euro-Arab Management School (EAMS), 
Granada, Spain. She has also worked for the FundaciĂłn CooperaciĂłn Internacional 
y PromociĂłn Ibero-AmĂŠrica Europa (CIPIE) and at the International Division of 
Banco de Santander. She has a master’s degree from the Fletcher School of Law and 
Diplomacy (Boston, MA), and from the Universidad PolitĂŠcnica de Madrid. She 
holds a degree and PhD from the Universidad AutĂłnoma de Madrid, with a com-
parative thesis on Islamic, ethical/ecological investment funds and on the London 
Market. She is the Author of Beyond Tribalism, 2012, and co-author of Managing 
Diversity in the Global Organization, 2007. She has had articles published in special-
ised journals, in addition to regular articles in the press. She was an external advisor 
of the Merrill Lynch’s Diversity & Inclusion Council up to 2009. Ms. de Anca is 
fluent in Spanish, English, French and Arabic.

Daniel Ahmed is a Senior Analyst at the Prime Minister’s Office of the United 
Arab Emirates, and was previously part of the fintech practice at Deloitte. Daniel is 
a co-founder of the Islamic Finance & Ethics Society at the University of London, 
and is currently working with Finocracy to explore and develop solutions that will 
disrupt the Islamic finance industry. He holds a degree in Political Economy at 
King’s College London.

Hafas Furqani is currently a lecturer at the Faculty of Islamic Economics and 
Business, State Islamic University of Ar-Raniry, Banda Aceh, Indonesia. He 
received his PhD in Economics (2012) as well as Master of Economics (2006), 
from the Department of Economics, International Islamic University Malaysia. His 
Bachelor’s degree is in Sharī‘ah Mu’amalah from the State Islamic University (UIN)  



xvi  Contributors 

Syarif Hidayatullah, Jakarta (2002). Hafas has extensively written and presented  
papers in the areas of Sharī‘ah, Islamic economics, banking and finance in academic 
journals and conferences. His paper entitled “Theory appraisal in Islamic economic 
methodology: purposes and criteria”, published in Humanomics (2012), was chosen as 
a Highly Commended Award Winner at the Literati Network Awards for Excellence 
2013. His PhD thesis “The Foundations of Islamic Economics: A Philosophical Exploration 
of the Discipline” was awarded Gold Medal at the 2012 International Islamic University 
Malaysia Research, Invention and Innovation Exhibition (IRIIE 2012).

Hafis Bello is a Fintech Analyst, corporate strategist and experienced researcher. 
He has distinguished himself as a forward-looking executive with great potential 
in identifying opportunities, increasing productivity and excellent teamwork abili-
ties. Hafis worked at Centre for Islamic Finance at HBKU, Qatar. Prior to this, he 
was a Business Development Executive at SystemSpecs where he was responsi-
ble for business strategy and product support for the FinTech solution, REMITA, 
for microfinance banks and pension funds. He is a Council Member at Gerson 
Lehrman Group (GLG), USA. Hafis founded Leeds Interlinks Limited in 2013 and 
co-founded Carry-On Inc. in 2017. He is an Associate Fellow of the Institute of 
Islamic Banking & Insurance (IIBI), London. He coordinates training and motiva-
tion programmes aimed at unlocking potential and has written articles on self-
development initiatives. Some of his academic research in sustainable development, 
finance and social sciences are published in reputable journals. He has completed 
his coursework towards a PhD degree in Islamic Banking and Finance.

Harris Irfan is Chairman of the UK Islamic FinTech Panel and a Partner at 
Gateway LLP, the professional services firm. He is also the Managing Director 
of Cordoba Capital, the Islamic finance and fintech consulting firm. Harris co-
founded Deutsche Bank’s world leading Islamic finance team and was CEO of its 
Islamic finance subsidiary. He was subsequently appointed global head of Islamic 
finance at Barclays, and then Head of Investment Banking at EIIB/Rasmala. He is 
the author of Heaven’s Bankers: Inside the Hidden World of Islamic Finance and holds a 
degree in Physics from the University of Oxford, UK.

Ibrahim Opeyemi Adediran is a Chartered Accountant and Advance Certified 
Islamic Finance Executive. He has more than a decade of experience in auditing, 
commercial and educational sectors. He is a consultant for companies and pri-
vate individuals and a trainer on IFRS, accounting, internal control and regulatory 
compliance.

Ishaq Mustapha Akinlaso is a CIAWM doctoral scholar specialising in Innovative 
Financial Instruments for Infrastructure Development at the Global University for 
Islamic Finance (INCEIF), Malaysia. Mustapha is the project lead at Blockdentity, 
a next generation fintech player that is focused on revolutionising legacy identity 
systems using blockchain and integrated technologies.



 Contributors  xvii

Jonathan Lawrence is a Finance partner in the London office of the global law firm 
K&L Gates, where he has held this position since 2005. He plays a leadership role in 
the firm’s Islamic Finance practice, Legal 500 UK Islamic Finance. K&L Gates LLP 
is singled out for its “seamless global service”. Its cross-office team includes London-
based Jonathan Lawrence, who has “stunning in-depth knowledge of structuring 
shari’ah-compliant transactions”. One client describes him as a “real breath of fresh 
air”, saying: “What has impressed me the most is his ability to act very quickly when 
required, with a real sense of urgency and commercial awareness often lacking in 
other firms.” Lawrence writes regularly on fintech issues for www.fintechlawblog.
com. He is a member of the Editorial Board of the Journal of International Banking & 
Financial Law and sits on the Consultation Board of Practical Law Finance.

Leisan Safina is a Treasury Officer in Hayat Kimya, Russia. She was formerly an 
intern at the International Islamic Corporation for Development of the Private 
Sector (ICD), Islamic Development Bank Group, Kuala Lumpur office. She 
received her degree from Kazan Federal University (Russia) and later successfully 
completed her master’s degree in Islamic Banking and Finance from International 
Islamic University Malaysia. Her area of interests is Islamic banking and finance, 
and fintech, particularly blockchain applications, in Islamic finance. She has pre-
sented papers in conferences across the world including: “Utilizing Blockchain 
Technology for Post-Trade Securities Settlement: A Framework for Islamic Capital 
Markets in the GCC Region” in Gulf Research Meeting 2018 at the University of 
Cambridge; and “Utilizing Blockchain Technology for Post-Securities Settlement: 
A framework for Islamic Capital Market in Iran” in the 10th International Forum 
on Islamic Capital Markets, Tehran, Islamic Republic of Iran.

Magda Ismail Abdel Mohsin is an Associate Professor at the International Centre 
for Education in Islamic Finance (INCEIF), the Global University of Islamic 
Finance, Malaysia, teaching Islamic economics and finance. She is the author of 
the two books on waqf published by Pearson, and an editor of a recent book pub-
lished by Palgrave. She is also the recipient of four awards: Outstanding Women 
Achiever for the contribution and achievement in the field of Islamic Economics 
and Finance, given under the seal of Venus International Foundation, India, March 
2016; Recognition for Best Research Efforts Award, awarded by International 
Council of Islamic Finance Educators (ICIFE) in August 2015; Best/outstand-
ing paper award for the paper, “Financing through cash-waqf: A new innovation 
for the 21st Century” by the Emerald Group, 2013; Best Book written on waqf 
in 2014 (Corporate Waqf from Principle to Practice) selected by Sheikh Rashid bin 
Dail Research Chair for Endowments Studies, Imam Muhammad ibn Saud Islamic 
University Riyadh, Saudi Arabia.

Marifatulhaq Yasini is Sharī‘ah Executive at CIMB Islamic Bank Berhad. He 
received his Bachelor Degree in Law and Sharī‘ah from International Islamic 
University Malaysia.

http://www.fintechlawblog.com
http://www.fintechlawblog.com


xviii  Contributors 

Marjan Muhammad is currently the Head of Research Quality Assurance Office 
at the International Shari’ah Research Academy for Islamic Finance (ISRA), 
Kuala Lumpur, Malaysia. She was previously the Director of Research at ISRA. 
Prior to joining the organisation, she was a tutor at the Faculty of Law and 
Syari’ah, Islamic Science University of Malaysia (USIM). Dr. Marjan is currently 
a member of the Shari’ah Advisory Committee at Malaysia Building Society 
Berhad (MBSB), Malaysia. She also sits as a member of the Shari’ah Committee 
at Maybank Islamic Berhad, Malaysia and SME Bank, Malaysia. She obtained her 
Doctoral and Master’s degrees in Islamic Revealed Knowledge and Heritage (Fiqh 
and Usul al-Fiqh) from the International Islamic University Malaysia (IIUM), 
after graduating from the same university in 1998 with her Bachelor’s degree. 
Her research interests in Islamic finance focus on the Islamic capital market. She 
is the editor of textbooks on the Islamic Capital Markets: Principles and Practices 
(2015), Islamic Financial System: Principles and Operations (2nd ed, 2016), and Sukuk: 
Principles and Practices (2017).

Michael Gassner is Editor of IslamicFinance.de and Head of Islamic finance of 
a Swiss private bank and has been based in Switzerland since 2008. Michael is 
a member of the Sharia Board of Bosna Bank International in Sarajevo, and a 
member of the advisory board of the World Congress of Muslim Philanthropists 
in Chicago. He also teaches Islamic law, finance and economics at Geneva Business 
School and University of Lausanne.

Mohamad Akram Laldin is currently the Executive Director of International 
Sharī‘ah Research Academy for Islamic Finance (ISRA) and Professor at 
International Centre for Education in Islamic Finance (INCEIF), Malaysia. 
Prior to joining ISRA he was an Assistant Professor at the Kulliyah of Islamic 
Revealed Knowledge and Human Sciences, International Islamic University, 
Malaysia (IIUM). In the period 2002–2004, he was a Visiting Assistant Professor 
at the University of Sharjah, Sharjah, United Arab Emirates. At present, he is 
the Member of Bank Negara Malaysia Sharī‘ah Advisory Council, Chairman of 
Sharī‘ah Board of Employees Provident Fund Malaysia (EPF), Member of Shariah 
Supervisory Council of Labuan Financial Services Authority (FSA), Member of 
Shariah Advisory Board ZI Shariah Advisory, Member of Shariah Advisor of Dar 
Al Takaful, Dubai, Member of Shariah Advisory Board, Eco Islamic Bank, Republic 
of Kyrgstan, Member of Shariah Advisory Council International Islamic Financial 
Market (IIFM),Bahrain, Member of Shariah Advisor of National Takaful Company 
PSC, Watania, Abu Dhabi, Member Financial Regulation Advisory Council of 
Experts (FRACE), Central Bank of Nigeria, Member of The Panel of Recognized 
International Market Experts in Finance (“P.R.I.M.E. Finance”) and other Boards 
locally and internationally. He is the recipient of the Zaki Badawi Award for 
Excellence in Shariah Advisory and Research. Recipient of the Most Outstanding 
Individual Contribution to Islamic Finance during KLIFF 2016 organised by 
CERT. Winner of the 2017/1439H Malaysian Islamic Personality Award conferred 



 Contributors  xix

by The Government of Malaysia on the occasion of the birthday of the Prophet 
Muhammad (peace be upon him).

Mohamed Cherif El Amri is an Assistant Professor at the Faculty of Business and 
Management Sciences and specialises in Islamic Economics and Finance, at Istanbul 
Sabahattin Zaim University, Turkey. He completed his Bachelor’s degree in Islamic 
Studies from Ibn Tofail University in Morocco. He had his Master’s in Islamic 
Jurisprudence and its principles, while his PhD was in Islamic banking and finance 
from International Islamic University Malaysia. He worked as an intern at several 
Islamic financial institutions, such as the Islamic Capital Market Business Group, 
Securities Commission, Kuala Lumpur, Malaysia and Maybank Islamic. He worked 
as a researcher at the IIUM Institute of Islamic Banking and Finance, Malaysia. He 
was an Associated Consultant at Amanie Advisors, Kuala Lumpur, Malaysia. He is a 
member of the Scientific Committee of the International Review of Entrepreneurial 
Finance Journal and Journal of Islamic Economics and Finance. He has multiple research 
publications and presentations in the field of Islamic Finance and Economics.

Mufti Abdul Kadir Barkatulla is a prominent Sharia law expert based in the UK 
with a background in social, Muslim community work, economics and finance. 
He was trained extensively in Islamic and modern education systems in India and 
the UK. Mufti has contributed to the British Muslim community as an Imam, 
Lecturer, Shariah Judge, Developer of Islamic Law information databases, Anchor 
of Community Television, Media Commentator, Shariah Advisor of Islamic Banks 
and Funds in Europe and Asia.

Mufti Faraz Adam is the Director of Amanah Finance Consultancy Ltd, a plat-
form for specialist global Shariah advisory services based in the UK. He has spent 
almost a decade studying Islamic law. He completed his Islamic studies in the six-
year Alimiyyah degree at Darul Uloom Leicester. He then went on to specialise in 
Islamic law and graduated as a Mufti in South Africa at Darul Iftaa Mahmudiyyah, 
Durban, super-specialising in Islamic finance during his studies. Mufti Faraz went 
on to complete a Master’s Degree in Islamic Finance, Banking and Management 
at Newman University in 2017. During the past few years, he has attained vari-
ous industry qualifications. Mufti Faraz is a Shariah advisor at a number of Islamic 
financial institutions in the UK, Bahrain, Dubai, Singapore and Malaysia.

Muhammad Al-Amine Muhammad Al-Bashir is Sharī‘ah Advisor at Islamic 
Corporation for the Development of the Private Sector, Islamic Development 
Bank, Jeddah, Saudi Arabia. He was the Group Head of Sharī‘ah Compliance of 
Bank Alkhair. Prior to joining IDB he was at Bank Alkhair and the International 
Islamic Financial Market (IIFM). He was also a part-time Lecturer at the Faculty 
of Laws International Islamic University Malaysia; Ibn Sina Institute of Technology 
(Malaysia); the Matriculation Centre International Islamic University (Malaysia), 
the Bahrain Institute of Banking and Finance; the Kingdom University (Bahrain); 



xx  Contributors 

and The Open University of Malaysia in Bahrain. Al-Bashir is the author of Sukuk 
and Islamic Securitization Markets: Financial Engineering and Product Development (Brill, 
2012); Risk Management in Islamic Finance: An Islamic Analysis of Derivatives Instruments 
in Commodity Markets (Brill, 2008), Istisna (Manufacturing Contract) in Islamic Banking 
and Finance Law and Practice (A.S. Noordeen, 2001 and 2006) and Islamic Finance and 
Africa Economic Resurgence: Opportunities and Challenges (Palgrave Macmillan, 2016). 
He has also contributed a number of articles published in international journals.

Mustafa Omar Mohammed is presently the Head and an Associate Professor at 
the Department of Economics, International Islamic University Malaysia (IIUM) 
where he has been teaching for more than 15 years. He has published more than 50 
refereed journal articles and presented more than 70 papers, mostly at international 
conferences. He is actively involved in funded and commissioned research pro-
jects. His present research areas of interest are in Waqf, Zakat, Islamic Microfinance 
and Maqasid al-Sharī‘ah. He has supervised more than 45 dissertations at PhD and 
Master’s levels. He is also a journal editorial member and on the review panel of 11 
academic entities. He has received several quality awards for teaching and research. 
He was part of a committee responsible for setting up the Institute of Islamic 
Banking and Finance and recently, the Department of Islamic Fin";"""date"",""2019-12-26T08:27:59Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.6""
""xmp:CreatorTool"",""Adobe InDesign CC 13.1 (Windows)""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""language"",""en""
""dcterms:created"",""2019-05-30T05:19:25Z""
""Last-Modified"",""2019-12-26T08:27:59Z""
""dcterms:modified"",""2019-12-26T08:27:59Z""
""dc:format"",""application/pdf; version=1.6""
""xmpMM:DocumentID"",""xmp.id:2c249cec-319e-174a-8acf-0ec9690365f8""
""Last-Save-Date"",""2019-12-26T08:27:59Z""
""pdf:docinfo:creator_tool"",""Adobe InDesign CC 13.1 (Windows)""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2019-12-26T08:27:59Z""
""meta:save-date"",""2019-12-26T08:27:59Z""
""pdf:encrypted"",""false""
""xmp:CreateDate"",""2019-05-30T10:49:25Z""
""modified"",""2019-12-26T08:27:59Z""
""Content-Length"",""4860513""
""pdf:hasMarkedContent"",""false""
""Content-Type"",""application/pdf""
""xmp:ModifyDate"",""2019-12-26T11:27:59Z""
""xmp:MetadataDate"",""2019-12-26T11:27:59Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""dc:language"",""en-US""
""pdf:producer"",""Adobe PDF Library 15.0""
""trapped"",""False""
""meta:creation-date"",""2019-05-30T05:19:25Z""
""created"",""2019-05-30T05:19:25Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""375""
""Creation-Date"",""2019-05-30T05:19:25Z""
""resourceName"",""EBOOK9250.pdf""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""0"",""1688"",""0"",""85"",""1664"",""510"",""1066"",""895"",""850"",""756"",""1994"",""833"",""1064"",""1322"",""1807"",""3141"",""3075"",""3149"",""3180"",""3089"",""3329"",""3248"",""3286"",""3191"",""1850"",""18"",""0"",""2272"",""3257"",""3225"",""3118"",""3223"",""3032"",""3422"",""2553"",""2787"",""3304"",""3166"",""3036"",""3505"",""0"",""42"",""0"",""2011"",""3094"",""3328"",""3018"",""3318"",""3055"",""3202"",""3118"",""3311"",""3231"",""3066"",""3021"",""3095"",""580"",""2134"",""3193"",""3197"",""3326"",""3200"",""3197"",""3209"",""3170"",""3371"",""3137"",""3349"",""2722"",""3310"",""3077"",""1938"",""3071"",""2769"",""3146"",""2290"",""2785"",""2689"",""2881"",""2822"",""2901"",""2481"",""2847"",""2701"",""3227"",""3099"",""3502"",""1981"",""2096"",""3340"",""3048"",""3032"",""2232"",""3236"",""2881"",""3133"",""783"",""2867"",""2188"",""1961"",""3069"",""3253"",""2860"",""2757"",""1936"",""2021"",""2881"",""2881"",""2885"",""2971"",""3164"",""2727"",""2701"",""730"",""0"",""39"",""0"",""1928"",""3395"",""2922"",""3202"",""3433"",""2979"",""2412"",""3319"",""3129"",""2230"",""3441"",""2874"",""3118"",""2234"",""2619"",""1474"",""2104"",""2067"",""3540"",""2420"",""1757"",""3391"",""3123"",""3258"",""2804"",""3134"",""2370"",""1970"",""2961"",""2962"",""2636"",""3180"",""3115"",""2795"",""2843"",""3219"",""2801"",""3003"",""526"",""2024"",""3009"",""2930"",""3520"",""2452"",""3068"",""3394"",""2926"",""2955"",""2692"",""2987"",""2865"",""2734"",""3397"",""2990"",""3057"",""3018"",""3106"",""3201"",""2870"",""2868"",""3102"",""3175"",""3212"",""3435"",""34"",""0"",""2027"",""3160"",""3372"",""3406"",""3272"",""3282"",""2582"",""2293"",""2680"",""3268"",""3146"",""2887"",""3106"",""3423"",""3188"",""1799"",""2780"",""2962"",""3076"",""2773"",""2915"",""3013"",""2763"",""1682"",""1811"",""3347"",""3446"",""3162"",""3342"",""3407"",""3385"",""2747"",""2780"",""3048"",""3278"",""3081"",""3466"",""3404"",""3081"",""3122"",""3165"",""3410"",""3035"",""3362"",""3201"",""3051"",""3344"",""3277"",""3289"",""2983"",""3452"",""3557"",""3689"",""3373"",""3440"",""2343"",""2040"",""3198"",""3286"",""3075"",""3504"",""3344"",""3213"",""3453"",""3020"",""3400"",""3135"",""2887"",""3398"",""3430"",""3134"",""2982"",""3498"",""707"",""47"",""0"",""1936"",""2810"",""3372"",""3201"",""3332"",""3127"",""3032"",""763"",""2858"",""3109"",""3183"",""3112"",""3229"",""1718"",""2047"",""2853"",""3216"",""2136"",""2623"",""2176"",""2437"",""2558"",""2264"",""2393"",""2916"",""2824"",""2269"",""2789"",""2488"",""2904"",""2381"",""2118"",""3084"",""2798"",""2769"",""3079"",""2985"",""3239"",""3010"",""3188"",""3011"",""3142"",""3293"",""3464"",""2863"",""554"",""2019"",""2238"",""2551"",""3254"",""3250"",""3068"",""41"",""2838"",""2993"",""2740"",""3084"",""2097"",""2760"",""2394"",""3153"",""1730"",""2932"",""2914"",""3045"",""3197"",""3690"",""2833"",""2060"",""3309"",""2738"",""3136"",""2955"",""3269"",""3061"",""3215"",""2889"",""2468"",""2993"",""2902"",""2789"",""3143"",""1182"",""2764"",""3246"",""3420"",""3028"",""3334"",""2999"",""0"",""24"",""0"",""2046"",""3213"",""3348"",""2964"",""2808"",""3064"",""3168"",""3172"",""2781"",""2741"",""1481"",""2921"",""2870"",""3246"",""2823"",""2781"",""2897"",""2871"",""2942"",""2740"",""2734"",""3003"",""2864"",""345""
""access_permission:extract_content"",""true""
""xmpMM:DerivedFrom:DocumentID"",""xmp.did:f785e357-782a-174d-8184-a2a0faf84a50""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""xmpMM:DerivedFrom:InstanceID"",""xmp.iid:a8ed6a62-4ac7-444e-8492-3d95245c6bb3""
""producer"",""Adobe PDF Library 15.0""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""Adobe PDF Library 15.0""
""pdf:docinfo:created"",""2019-05-30T05:19:25Z""
";https://scholar.google.com/scholar?start=980&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094658-1156;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Dual-mode NIZKs from obfuscation;D Hofheinz, B Ursu ; International Conference on the Theory and …, 2019  Springer;;"… x. If A is a probabilistic algorithm, \(y \leftarrow _{\textsc {r}}A(\cdot )\) denotes the process of

running A on some appropriate input and assigning its output to y. The notation \(\mathcal {A}

^{\mathcal {O}}\) indicates that the algorithm \(\mathcal {A} \) is given oracle access to …";Cité 5 fois;Les 3 versions;[PDF] ethz.ch;https://people.inf.ethz.ch/dhofheinz/pdf/conf/asiacrypt/HofheinzU19.pdf;"
Dual-Mode NIZKs from Obfuscation

Dennis Hofheinz1, Bogdan Ursu1

Karlsruhe Institute of Technology
{dennis.hofheinz,bogdan.ursu}@kit.edu

Abstract. Two standard security properties of a non-interactive zero-
knowledge (NIZK) scheme are soundness and zero-knowledge. But while
standard NIZK systems can only provide one of those properties against
unbounded adversaries, dual-mode NIZK systems allow to choose dy-
namically and adaptively which of these properties holds uncondition-
ally. The only known dual-mode NIZK schemes are Groth-Sahai proofs
(which have proved extremely useful in a variety of applications), and
the FHE-based NIZK constructions of Canetti et al. and Peikert et al,
which are concurrent and independent to this work. However, all these
constructions rely on specific algebraic settings.
Here, we provide a generic construction of dual-mode NIZK systems for
all of NP. The public parameters of our scheme can be set up in one of
two indistinguishable ways. One way provides unconditional soundness,
while the other provides unconditional zero-knowledge. Our scheme relies
on subexponentially secure indistinguishability obfuscation and subexpo-
nentially secure one-way functions, but otherwise only on comparatively
mild and generic computational assumptions. These generic assumptions
can be instantiated under any one of the DDH, k-LIN, DCR, or QR as-
sumptions.
As an application, we reduce the required assumptions necessary for
several recent obfuscation-based constructions of multilinear maps. Com-
bined with previous work, our scheme can be used to construct multi-
linear maps from obfuscation and a group in which the strong Diffie-
Hellman assumption holds. We also believe that our work adds to the
understanding of the construction of NIZK systems, as it provides a con-
ceptually new way to achieve dual-mode properties.

Keywords: non-interactive zero-knowledge, dual-mode proof systems,
indistinguishability obfuscation.

1 Introduction

Obfuscation and structured assumptions. Indistinguishability obfuscation
(iO) is a powerful cryptographic object, and along with one-way functions, it
implies almost every cryptographic primitive, from deniable encryption [42] to
functional encryption [26] and fully-homomorphic encryption [18]. However, it
is not currently known whether iO gives rise to structures in which algebraic
assumptions hold (such as DDH, DCR, LWE etc.). In this work, we are motivated
by the following open problem:

mailto:dennis.hofheinz@kit.edu,bogdan.ursu@kit.edu


2 Dennis Hofheinz and Bogdan Ursu

Can structured objects (such as DDH groups) be bootstrapped from
unstructured objects (like generic one-way functions and iO)?

We make progress in this direction by developing the first construction of dual-
mode non-interactive zero-knowledge (NIZK) proof systems from unstructured
assumptions (iO, one-way functions and lossy trapdoor functions). This dual-
mode NIZK can be used in the constructions from [1,2,21], allowing us to answer
this question in the affirmative.
Zero-knowledge proof systems. Zero-knowledge (ZK) proof systems [28,29]
are (implicitly or explicitly) at the heart of countless cryptographic construc-
tions. In a ZK proof system, a prover P tries to convince a verifier V of the
validity of a statement x. “Validity” usually means that x ∈ L for some language
L ∈ NP. In this case, P obtains a witness w to x ∈ L. For security, we re-
quire soundness, which means that no dishonest prover can convince V of a false
statement x /∈ L. Additionally, we may want to protect P (and in particular the
used witness w) in several ways. For instance, the protocol is zero-knowledge if
it is possible to efficiently simulate (transcripts of) protocol runs even without
w. Alternatively, we can require the protocol to be witness-hiding or witness-
indistinguishable [23].

ZK proof systems can be interactive or non-interactive (the latter of which
means that the prover sends only one message to the verifier). In this work, we are
interested in non-interactive ZK (NIZK) proof systems [10]. There exist already
various NIZK proof systems, ranging from generic [22, 24, 42] to highly efficient
constructions based on concrete number-theoretic assumptions [24,32,44]. Some
of these systems only allow to prove x ∈ L for specific languages L, while others
can be used to prove statements from arbitrary languages L ∈ NP.
Dual-mode proof systems. Some NIZK systems enjoy statistical security,
i.e., information-theoretic soundness or zero-knowledge guarantees. However, in-
terestingly, no NIZK system can be statistically sound and statistically zero-
knowledge simultaneously. Hence, a NIZK system can be secure only either
against unbounded malicious provers or against unbounded malicious verifiers.

Fortunately, there is a compromise that combines the best of both worlds:
Groth-Sahai proofs [32] are statistically sound or statistically zero-knowledge
depending on the choice of public parameters crs. Furthermore, both choices
of parameters are computationally indistinguishable. This “dual-mode” property
leads to comparatively simple proofs for complex protocols (e.g., for anonymous
credentials [4] or payment systems [33]). In the case of [2, 21], a proof without
using dual-mode properties in fact does not seem obvious at all.1

Until recently, only Groth-Sahai proofs [32] (and their variants, e.g., [9,20,35])
were known to possess this dual-mode property.2 These proof systems all rely on
1 A bit more technically, dual-mode NIZK proofs allow to use both witness extraction
or simulation trapdoors in different stages of the proof, depending on the chosen
mode. (This is helpful in case of [4,33] and crucial in [2,21].) Furthermore, in complex
settings with mutually dependent statements and witnesses, statistical properties are
easier seen to compose.

2 We do not consider NIZK proofs in the random oracle model (such as [37]) here.



Dual-Mode NIZKs from Obfuscation 3

a very specific and structured algebraic setting (pairing-friendly cyclic groups).
In contrast, we rely on generic rather than algebraic techniques, resulting in a
fundamentally new way of obtaining dual-mode proof systems.

Concurrent work Concurrently and independently to this work, [19, 39] have
put forward breakthrough approaches to obtain dual-mode NIZKs from the LWE
assumption. These constructions rely on rich algebraic structures and are non-
blackbox. In contrast, our techniques are generic and our perspective is closer
to computational complexity, in that we investigate whether the existence of a
powerful non-algebraic object (iO) can lead to algebraic ones.

Our contribution In this paper, we give the first generic construction of dual-
mode NIZK proofs from (the combination of) the following ingredients:
– subexponentially secure indistinguishability obfuscation (iO, [3, 26]),
– subexponentially secure one-way functions,
– a (selectively) subexponentially secure functional encryption scheme,
– lossy encryption [5, 40], and
– lossy functions (LFs), a relaxation of lossy trapdoor functions [41] which we

introduce in this paper.
We stress that some of our ingredients are implied by (a combination of) others:
Functional encryption can be constructed from iO and one-way functions [26].
Conversely, subexponentially secure functional encryption implies subexponen-
tially secure iO and one-way functions (e.g., [8] and the references therein).
Furthermore, both LFs and lossy encryption are implied by lossy trapdoor func-
tions [41].

As a side note, we remark that thus, a subexponential variant of any of the
DDH, k-LIN, QR, DCR, or LWE assumptions, along with subexponential iO
implies all of our ingredients.3

Of course, since we assume iO, our construction is far from practical. Still,
it has interesting theoretical applications. For instance, it allows to instantiate
dual-mode NIZK proofs in the recent works [1, 2, 21] without any additional
assumptions, and in particular without pairing-friendly groups. (Incidentally,
these works already assume what we need for our construction.)

In particular, combining our results with the scheme from [1], shows that it
is possible to obtain a very structured object (namely, a cyclic group in which
Diffie-Hellman and similar assumptions hold) solely from an unstructured and
generic object (iO), and a mildly structured object (a lossy trapdoor function).4

3 See [11,25,41] for the corresponding instantiations of lossy trapdoor functions from
these concrete assumptions.

4 Indeed, except for a dual-mode NIZK proof system, all assumptions in [1] can be
instantiated from subexponentially secure iO and a subexponentially secure lossy
trapdoor function. We note, however, that [1] construct a group in which elements
have only a non-unique representation and no canonical form. Hence, their group
might not be considered a “standard group”, but still has a rich algebraic structure.



4 Dennis Hofheinz and Bogdan Ursu

Similarly, implementing [2,21] with our system (instead of with Groth-Sahai
proofs) yields a pairing-friendly group (with non-unique representation) from iO
and a DDH group (both subexponentially secure). Therefore, we also give an
answer to the following open problem:

Can bilinear groups be bootstrapped from DDH groups and iO?

Previous work This work + [1,2, 21]
[2] iO + Pairings+ SDDH⇒ Multilinear Maps iO + SDDH⇒ Multilinear Maps

[21] iO + Pairings+ SDDH⇒ Graded Encoding Schemes iO + SDDH⇒ Graded Encoding Schemes
[1] iO + Pairings⇒ Interactively Secure Groups iO + LTDF⇒ Interactively Secure Groups

Fig. 1. Some implications on previous results. “ iO”, “LTDF” and “SDDH” denote subex-
ponential versions of indistinguishability obfuscation, lossy trapdoor functions and the
“Strong DDH” (a q-type variant of the Diffie-Hellman assumption).

Open problems. We note that the groups from [1, 2, 21] all enjoy non-unique
representations of group elements. That is, equality of group elements can be
tested, but there does not exist a canonical form. Removing this limitation re-
mains an open problem.

Our techniques

Existing generic approaches. Before explaining our main ideas, we first men-
tion that generic constructions of NIZKs from iO already exist. Namely, [42]
present a NIZK construction that only assumes iO and one-way functions. Their
construction is (even perfectly) zero-knowledge. However, proofs are in their case
simply signatures of the corresponding statement x. Thus, their construction is
inherently limited to computational soundness, in the sense that it is not clear
how to tweak this construction to obtain statistical soundness.

Secondly, it is possible to construct a notion of trapdoor permutations from
iO that is in turn sufficient to construct statistically sound NIZK proofs [17]
(cf. [6, 7, 22, 30]). However, it is not clear how to tweak this NIZK construction
to obtain statistical zero-knowledge.

The hidden bits model. Similarly to [17], our starting point is also the generic
NIZK construction from [22]. This work presents a statistically sound and per-
fectly zero-knowledge NIZK protocol in an ideal model of computation called
the “hidden bits model” (HBM).5 It will be helpful to first recall the HBM be-
fore going further. In a nutshell, the HBM gives the prover P access to an ideal
random bitstring hrs = (hrs1, . . . , hrst) ∈ {0, 1}t. Next, P selects a subset I ⊆ [t]
and a proof π. Then, the verifier V is activated with I, π, the subset (hrsi)i∈I

5 Since their protocol is formulated in an ideal model of computation, it does not
contradict our remark above about the impossibility of simultaneously achieving
statistical soundness and statistical zero-knowledge. One of the two statistical prop-
erties will be lost when implementing this ideal model.



Dual-Mode NIZKs from Obfuscation 5

of hrs that is selected by I, and of course the instance x. Finally, V is supposed
to output a verdict b ∈ {0, 1}.
Two ways to implement the HBM. Note that the power of the HBM stems
from the fact that hrs is ideally random (and cannot be tampered with by P ),
but only revealed in part to V . When implementing the HBM, we will necessarily
have to compromise on some of these properties. However, it will be interesting
to see what the consequences of such compromises are. Specifically, when imple-
menting the HBM in the HBM-based NIZK protocol of [22], we can observe the
following:
(a) if we implement the HBM such that hrs is truly random (or selected from a

small set of possible hrs values, each of which is individually truly random),
then the resulting NIZK protocol is statistically sound and computationally
zero-knowledge,

(b) if we implement the HBM such that the unopened bits (hrsi)i/∈I are sta-
tistically hidden from V , then the resulting NIZK protocol is statistically
zero-knowledge and computationally sound.

Known implementations of the HBM (e.g., [22,30,31]) follow (a), and thus enjoy
statistical soundness guarantees. Our main strategy will be to build a dual-mode
NIZK proof system by implementing the HBM in a way that allows to switch
(by switching public parameters) between (a) and (b).

A first approach. Our first step will be to set up the hidden string hrs as

hrs = H(X)⊕ crs

for a value X chosen freely by P , a yet-to-be-defined function H, and a truly
random “randomizing string” crs fixed in the public parameters. If H is a pseu-
dorandom generator (that admits a suitable partial opening process, see [31] for
an explicit formulation), this yields the core of existing HBM implementations.
In particular, if H has a small image, then we are in case (a) above, and the
resulting NIZK is statistically sound.

However, suppose we can switch (in a computationally indistinguishable way)
H(X) to have a large image, such that in fact H(X) ∈ {0, 1}t is close to uniformly
distributed for random X. We call such a “switchable” object a lossy function
(LF). An LF can be easily constructed, e.g., by universally hashing the output
of a lossy trapdoor function F . For suitable choices of parameters, H(X) :=
h(F (X)) is close to uniform if F is injective (and X random), and has a small
range if F does.

With H(X) close to uniform, we are in case (b) above, assuming that the
process itself of revealing hrsI does not reveal additional information about other
bit positions. Hence, we obtain a statistically zero-knowledge NIZK protocol, and
in summary even a dual-mode NIZK that can be switched between statistically
sound and statistically zero-knowledge modes of operation.

Managing the opening process. The main problem with our first approach is
that it is not clear how to partially open a subset hrsI of hrs to a verifier V . Pre-
vious HBM implementations (e.g., [22, 31]) devised elaborate ways to partially



6 Dennis Hofheinz and Bogdan Ursu

open suitably designed pseudorandom generators (in the role of H above). We
cannot use those techniques for two reasons. First, their opening process might
reveal statistical information about the unopened parts of hrs. Second, these
techniques require specific H functions, and do not appear to work with “switch-
able” functions H as we need. Hence, we use the strong ingredients mentioned
above to design our own opening process.

We will use a functional encryption scheme FE. We will publicize a truly
random crs, a statement Z from a language L′ that is hard to decide, along
with an FE public key fmpk, and a corresponding secret key skf for the following
function f:

f(X, I, z, T ) :=

{
(T, I) if z is a witness to Z ∈ L′

(H(X)I , I) else.

An opening consists of an encryption

C = FE.Enc(fmpk, (X, I, 0, 0))

that will decrypt to f(X, I, 0, 0) = H(X)I under skf . The verifier will receive this
opening, retrieve H(X)I with skf , and compute hrsI = H(X)I ⊕ crsI .

Observe that this process has the following properties:
– If Z /∈ L′, then skf(C) = (H(X)I , I) always. Hence, if additionally H has a

small range, we are in case (a) above, and the corresponding NIZK protocol
is statistically sound.

– If Z ∈ L′ with witness z, then any prover who knows z can efficiently open
hrsI arbitrarily, by encrypting (0, I, z, T ) for T = crsI⊕hrsI and the desired
hrsI . Furthermore, such openings obviously do not contain any information
about potential other positions of hrs. This means we are in case (b) above,
and the corresponding NIZK protocol is statistically zero-knowledge.

By using FE’s security, it is possible to show that these two types of openings
are indistinguishable to a verifier. However, as formulated, they are of course
not indistinguishable to a prover yet. Hence, we will additionally publicize an
obfuscated algorithm PC that will get as input a statement x with witness w, and
random coins r. Depending on the mode (sound or zero-knowledge), PC(x,w, r)
will then either encrypt (X, I, 0, 0) or (0, I, z, T ), for pseudorandom X and T
derived from r.
A taste of the security proof. For security, we will show that the public
parameters in both modes are computationally indistinguishable. The security
proof is somewhat technical, and we would like to highlight only one interesting
theme here. Namely, observe that the prover algorithm PC is inherently proba-
bilistic. In the proof, we need to modify PC’s behavior, and in particular decouple
its output distribution from its input w. Specifically, when aiming at statistical
soundness, the output of PC will encrypt, and thus depend on w. But when
trying to achieve zero-knowledge, PC’s output should not reveal (in a statistical
sense) which witness w has been used.6

6 Formally, to achieve zero-knowledge, we must achieve witness-indistinguishability.



Dual-Mode NIZKs from Obfuscation 7

This decoupling process is particularly cumbersome to go through because
PC itself is public and can be run on arbitrary inputs. Any change that essen-
tially makes PC ignore its w input will be easily detectable. Hence, we add an
indirection that helps to remove dependencies on w. Specifically, we let PC first
compute a = LE.Enc(lpk, (x,w); r) using a lossy encryption scheme LE. If the
corresponding public key lpk is injective (i.e., leads to decryptable ciphertexts),
then a determines w. Hence, any case distinction (or hybrid argument) we make
for different values of w can alternatively be made for different values of a. On
the other hand, if lpk is lossy, then a will be statistically independent of the
plaintext (x,w).

Hence, a can be used as a single value that (a) can serve as a “fingerprint” of
(or in some sense even as a substitute for) w in the proof, but (b) can be easily
made independent of w by switching lpk into lossy mode. Equipped with this
gadget, we will structure the proof as a large hybrid argument over all values of
a (encrypted at this point with an injective lpk). In each step, we modify PC’s
behavior for one particular value of (x,w), and change the corresponding FE
ciphertext C from an encryption of (X, I, 0, 0) to (0, I, z, T ) for a pseudorandom
value T derived from a.
Roadmap. After recalling some preliminaries in Sec. 2, we present our proof
system in Sec. 3, followed by its analysis in Sec. 4. The appendix contains a
schematic overview over our main proof (App. A), a proof of a technical lemma
(App. B), a recap of the HBM-based NIZK from [22] (App. C), and an analysis
of the (statistical) extractability of our scheme (App. D).

2 Preliminaries

Notation. Throughout this paper, Îť denotes the security parameter. For a
natural number n ∈ N, [n] denotes the set {1, . . . , n}. A probabilistic polynomial
time algorithm (PPT, also denoted efficient algorithm) runs in time polynomial
in the (implicit) security parameter Îť. A positive function f is negligible if for
any polynomial p there exists a bound B > 0 such that, for any integer k ≥ B,
f(k) ≤ 1/|p(k)|. An event depending on λ occurs with overwhelming probability
when its probability is at least 1 − negl(λ) for a negligible function negl. Given
a finite set S, the notation x ←r S means a uniformly random assignment of
an element of S to the variable x. If A is a probabilistic algorithm, y ←r A(·)
denotes the process of running A on some appropriate input and assigning its
output to y. The notation AO indicates that the algorithm A is given oracle
access to O. We denote a← A; b← B(a); . . . for running the experiment where
a is chosen from A, after which b is chosen from B, which might depend on a
and so on. This determines a probability distribution over the outputs and we
write Pr[a ← A; b ← B(a); . . . : C(a, b, . . .)] for the probability of the condition
C(a, b, . . .) being satisfied after running the experiment. For two distributions
D1, D2, we denote by ∆(D1, D2) the statistical distance. We also write D1 ≡
D2 when the distributions are identical, D1 ≈c D2 when the distributions are
computationally indistinguishable and D1 ≈ε D2 when ∆(D1, D2) ≤ ε.



8 Dennis Hofheinz and Bogdan Ursu

2.1 Puncturable Pseudorandom Function

A pseudorandom function (PRF) originally introduced in [27], is a tuple of
PPT algorithms PRF = (PRF.KeyGen,PRF.Eval). Let K denote the key space,
X denote the domain, and Y denote the range. The key generation algorithm
PRF.KeyGen on input of 1Îť, outputs a random key from K and the evalua-
tion algorithm PRF.Eval on input of a key K and x ∈ X , evaluates the function
F : K×X 7→ Y. The core property of PRFs is that, on a random choice of key K,
no probabilistic polynomial-time adversary should be able to distinguish F (K, ¡)
from a truly random function, when given black-box access to it. Puncturable
PRFs (pPRFs) have the additional property that some keys can be generated
punctured at some point, so that they allow to evaluate the PRF at all points
except for the punctured point. As observed in [13, 14, 36], it is possible to con-
struct such punctured keys for the original construction from [27], which can be
based on any one-way functions [34].

Definition 1 (Puncturable Pseudorandom Function [13, 14, 36]). A
puncturable pseudorandom function (pPRF) is with punctured key space Kp is
a triple of PPT algorithms (PRF.KeyGen,PRF.Puncture,PRF.Eval) such that:

– PRF.KeyGen(1λ) outputs a random key K ∈ K,
– PRF.Puncture(K,x), on input K ∈ K, x ∈ X , outputs a punctured key
K{x} ∈ Kp,

– PRF.Eval(K ′, x′), on input a key K ′ (punctured or not), and a point x′,
outputs an evaluation of the PRF.

We require PRF to meet the following conditions:

Functionality preserved under puncturing. For all Ν ∈ N, for all x ∈ X ,

Pr[K ←r PRF.KeyGen(1λ),K{x} ←r PRF.Puncture(K,x) :

∀x′ ∈ X \ {x} : PRF.Eval(K,x′) = PRF.Eval(K{x}, x′)] = 1.

Pseudorandom at punctured points. For every stateful PPT adversary A
and every security parameter Ν ∈ N, the advantage of A in Exp-s-pPRF
(described in Figure 2) is negligible, namely:

Advs-cPRF(Îť,A) :=
∣∣Pr[Exp-s-pPRF(1λ,A) = 1]− 1

2

∣∣ ≤ negl(λ).

Sub-exponential security We say that PRF is sub-exponentially secure when it
satisfies Definition 1 and in addition it satisfies: for every PPT adversary A, the
advantage Advs-cPRF(λ,A) ≤ 1

2Νξ
, for some positive constant 0 < Îľ < 1.

Definition 1 corresponds to a selective security notion for puncturable pseudo-
random functions; adaptive security could be considered, but will not be required
in our work. For ease of notation we often write F (¡, ¡) instead of PRF.Eval(¡, ¡).



Dual-Mode NIZKs from Obfuscation 9

Experiment Exp-s-pPRF(1Îť,A)
Experiment Exp-s-pPRFA(Îť)
x∗ ←r A(1λ), b←r {0, 1},
K ←r PRF.KeyGen(1λ),
K{x∗} ←r PRF.Puncture(K,x∗),
y0 ← PRF.Eval(K,x∗), y1 ←r Y
b′ ←r A(K{x∗}, yb)
Return b = b′

Fig. 2. Experiment Exp-s-pPRFA(Îť) for the pseudo-randomness at punctured points.

2.2 Lossy functions

We generalize the notion of LTDF (lossy trapdoor function) due to [41] and
introduce lossy functions. LTDFs (Lossy trapdoor functions) can be sampled
in two indistinguishable modes: an injective and a lossy mode. When sampling
injective functions, the setup also provides a trapdoor which can be used to
invert the function. Unlike LTDFs, for lossy functions we require that functions
can be sampled in two modes, but in which one mode is “more lossy” than the
other. Thus, instead of an injective and a lossy mode, we have a “less lossy”
and a “more lossy” mode, which we denote as “dense” and “lossy” modes. Since
we do not necessarily have injectivity in the dense setting, we also do not have
trapdoors as in LTDFs.

Definition 2 (Lossy Functions). A tuple LF = (Setup,Eval) of PPT algo-
rithms is a family of (n, k,m, i)-lossy functions if the following properties hold:

– Sampling functions: Both Setup(1λ, dense) of dense functions and Setup(1λ,
lossy) of lossy functions output a function index s. We require that Eval(s, ¡) is
a deterministic function on {0, 1}n → {0, 1}m in both cases. In the following,
we use the shorthand notation s(¡) := Eval(s, ¡).

– Dense functions have images statistically close to uniformly random: for all
s←r LF(1λ,dense), we have that:

∆((s(Un), s), (Um, s)) ≤ 1
2i .

– Lossy functions have small image size: The image size of lossy functions is
bounded by 2k. In particular, for all s←r Setup(1λ, lossy),

|{Eval(s, x) : x ∈ {0, 1}n}| ≤ 2k.

– Indistinguishability: The outputs of Setup(1λ, lossy) and Setup(1λ, dense) are
computationally indistinguishable, i.e. {Setup(1λ, lossy)} ≈c {Setup(1λ, dense)}

We can generalise Definition 2 even further. Instead of asking that in dense
mode the evaluation of the function is statistically close to a uniformly random,
we may instead define the dense mode as havingH∞(Eval(s, Un)) ≥ m+2 log

(
1
Îľ

)
.

Then, by the leftover hash lemma, we can combine LF with a 2-universal hash
function to ensure that the output is statistically close to uniformly random as
in Definition 2. For clarity, we do not use this generalization in our proofs.



10 Dennis Hofheinz and Bogdan Ursu

Concrete instantiations: The lossy trapdoor functions from [41] are also
lossy functions in the sense of Definition 2. Moreover, composed with 2-universal
hash functions, they satisfy the necessary parameters in our construction (see
Section 3). This would yield suitable lossy functions based on DDH and LWE.

2.3 Lossy Encryption

Definition 3. [5, 40]: A lossy public-key encryption scheme is a tuple LE =
(Gen,Enc,Dec) of polynomial-time algorithms such that

– Gen(1λ, inj) outputs keys (pk, sk), keys generated by Gen(1λ, inj) are called
injective keys.

– Gen(1λ, lossy) outputs keys (pklossy,⊥), keys generated by Gen(1λ, lossy) are
called lossy keys.

– Enc(pk, ·, ·) :M ×R→ C.

Additionally, the algorithms must satisfy the following properties:

1. Correctness on injective keys. For all plaintexts x ∈ X,

Pr[(pk, sk)←r Gen(1λ, inj); r ← R : Dec(sk,Enc(pk, x, r)) = x] = 1.

2. Indistinguishability of keys. Public keys pk are computationally indistinguish-
able in lossy and injective modes. Specifically, if proj : (pk, sk) → pk is the
projection map, then:

{proj(Gen(1λ, inj))} ≈c {proj(Gen(1λ, lossy))}.

3. Lossiness of lossy keys. For all (pklossy,⊥)←r Gen(1λ, lossy), and all x0, x1 ∈
M , the two distributions {r ←r R : (pklossy,Enc(pklossy, x0, r))} and {r ←r
R : (pklossy,Enc(pklossy, x1, r))} are statistically close, i.e. the statistical dis-
tance is negligible in Îť.

We define a lossy encryption scheme LE to be µ-lossy if for all (pklossy,⊥) ←r

Gen(1Îť, lossy) and for all x0, x1, we have that:

{r ←r R : (pklossy,Enc(pklossy, x0, r))} ≈µ {r ←r R : (pklossy,Enc(pklossy, x1, r))}

2.4 Functional Encryption

Definition 4. [12, 38, 43] A functional encryption scheme for a class of func-
tions F = F(1Îť) over message spaceM =MÎť consists of four polynomial time
algorithms FE = (Setup,KeyGen,Enc,Dec):

1. Setup(1λ) – on input the security parameter λ outputs master public key mpk
and master secret key msk.

2. KeyGen(msk, f) – on input the master secret key msk and a description of
function f ∈ F and outputs a corresponding secret key skf .

3. Enc(mpk, x) – on input the master public key mpk and a string x, outputs a
ciphertext ct.



Dual-Mode NIZKs from Obfuscation 11

4. Dec(skf , ct) – on inputs the secret key skf and a ciphertext encrypting mes-
sage m ∈M , outputs f(m).

A functional encryption scheme is perfectly correct for F if for all f ∈ F and
all messages m ∈M:

Pr[(mpk,msk)←r Setup(1λ) : Dec(KeyGen(msk, f),Enc(mpk,m)) = f(m)] = 1

In addition, for the proof of theorem 14, we need a stronger property from
the functional encryption schemes we use in our construction, which we call spe-
cial correctness of decryption keys. Special correctness requires that decrypting
any (potentially maliciously generated) ciphertext under the decryption key skf
yields a result which lies in the range of the function f . The functional encryption
scheme based on iO and one-way functions from [26] satisfies this property.

Definition 5 (Special correctness of decryption keys). A functional en-
cryption scheme satisfies special correctness if for all Ν ∈ N, for all ct, for all
f ∈ F , there exists m ∈M, such that:

Pr

[
(mpk,msk)←r Setup(1λ),
skf ←r KeyGen(msk, f)

: Dec(skf , ct) ∈ {f(m),⊥}
]
≥ 1− negl(λ).

Definition 6 (Selectively Indistinguishable Security). A functional en-
cryption scheme FE is selectively indistinguishable secure ( SEL-IND-FE-CPA)
if for all stateful PPT adversaries A, the advantage of A in the experiment
Exp-s-IND-FE-CPA described in Figure 3 is negligible, namely:

AdvFEExp-s-IND-FE-CPA(Îť,A) :=
∣∣Pr[Exp-s-IND-FE-CPAFE(1λ,A) = 1]− 1

2 ]
∣∣ ≤ negl(λ)

Experiment Exp-s-IND-FE-CPAFE(1Îť,A)
(m0,m1)←r A(1λ);
(mpk,msk)←r FE.Setup(1λ)
b←r {0, 1}
ct←r FE.Enc(mpk,mb)

b′ ←r AFE.KeyGen(msk,·)(mpk, ct)
Return b = b′

Fig. 3. Experiment Exp-s-IND-FE-CPA for the selective indistinguishable security of
FE. The queries of A to oracle FE.KeyGen(msk, ¡) are restricted to functions f such
that f(m0) = f(m1).

Definition 7 (Sub-exponential Selectively Indistinguishability Security).
A functional encryption scheme FE is sub-exponentially selectively indistin-

guishability secure if it satisfies Definition 6 and in addition: for all PPT adver-
saries A:

AdvFEExp-s-IND-FE-CPA(λ,A) ≤ 1
2Νξ

, for some positive constant 0 < Îľ < 1.



12 Dennis Hofheinz and Bogdan Ursu

2.5 Indistinguishability Obfuscation

Definition 8 ( [3, 26] Indistinguishability Obfuscator). A uniform PPT
machine iO is called an indistinguishability obfuscator for a circuit class CÎť if
the following conditions are satisfied:

– For all security parameters λ ∈ N, for all C ∈ Cλ, for all inputs x, we have:

Pr[C ′(x) = C(x) : C ′ ←r iO(λ,C)] = 1

– For any (not necessarily uniform) PPT distinguisher A, for all security param-
eters Ν ∈ N, for all pairs of circuits C0, C1 ∈ CΝ, we have that if C0(x) = C1(x)
for all inputs x, then:

AdviO(λ,A) := |Pr[A(iO(λ,C0)) = 1]− Pr[A(iO(λ,C1)) = 1]| ≤ negl(λ)

Sub-exponential security We say that iO is sub-exponentially secure when it
satisfies Definition 8 and also it satisfies that: for every (not necessary uniform)
PPT distinguisher A, the advantage AdviO(Îť,A) is bounded by 1

2Νξ
, for some

positive constant 0 < Îľ < 1.

2.6 Dual-Mode NIWI Proof Systems

A dual-mode non-interactive witness indistinguishable (DM-NIWI) proof system
[32] is a special type of non-interactive witness indistinguishable (NIWI) proof
system, in which the common reference string (CRS) generation is dual-mode.
The dual-mode property means that these systems have common reference string
algorithms which generate indistinguishable CRS in “binding” or “hiding” modes.
The system satisfies statistical soundness and extractability in binding mode and
statistical witness indistinguishability in hiding mode.

Definition 9. A binary relation R is polynomially bounded if it is decidable
in polynomial time and there is a polynomial p such that |w| ≤ p(|x|), for all
(x,w) ∈ R. For any such relation and any x we set LR = {x| ∃w s.t. (x,w) ∈ R}.

Definition 10 ( [32] Dual-mode non-interactive witness indistinguish-
able proof systems). Let R be a polynomially-bounded binary relation R. A
dual-mode non-interactive witness indistinguishable (DM-NIWI) proof system
for language LR ∈ NP is a tuple of PPT algorithms DM-NIWI = (Setup,Prove,
Verify,Extract).

Setup(1Îť, binding) on input t";"""date"",""2019-09-10T21:44:27Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2019-09-10T21:44:27Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.19 (TeX Live 2018) kpathsea version 6.3.0""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2019-09-10T21:44:27Z""
""created"",""2019-09-10T21:44:27Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-09-10T21:44:27Z""
""resourceName"",""HofheinzU19.pdf""
""Author"",""""
""producer"",""pdfTeX-1.40.19""
""pdf:docinfo:producer"",""pdfTeX-1.40.19""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""5"",""2"",""14"",""5"",""0"",""10"",""4"",""14"",""16"",""5"",""0"",""0"",""2"",""9"",""0"",""2"",""1"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""6"",""0"",""16"",""11"",""0"",""3"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2019-09-10T21:44:27Z""
""Last-Modified"",""2019-09-10T21:44:27Z""
""dcterms:modified"",""2019-09-10T21:44:27Z""
""title"",""""
""Last-Save-Date"",""2019-09-10T21:44:27Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2019-09-10T21:44:27Z""
""meta:save-date"",""2019-09-10T21:44:27Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.19 (TeX Live 2018) kpathsea version 6.3.0""
""Content-Length"",""773845""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""39""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""2122"",""2865"",""2550"",""2384"",""2463"",""2362"",""2624"",""2017"",""2032"",""1812"",""1780"",""2061"",""1591"",""2123"",""2054"",""1785"",""2218"",""1783"",""2351"",""2366"",""2274"",""2284"",""2084"",""2341"",""2082"",""2339"",""1888"",""1933"",""2447"",""2879"",""2868"",""2411"",""2407"",""2090"",""1759"",""2594"",""2016"",""2282"",""1567""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-09-10T21:44:27Z""
";https://scholar.google.com/scholar?start=970&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094576-804;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Organizaciones autónomas descentralizadas (DAOs) para economía colaborativa utilizando Blockchain;D González Blanco, A Guevara Carpizo… ;2019 eprints.ucm.es;;"… formáticos llamados smart contracs. Dichos contratos están codificados en la Blockchain y existen

de manera autónoma pero también pueden requerir de una interacción externa (humana, oracles)

para realizar cierto tipo de trabajos que el contrato no puede completar …";Cité 1 fois;Les 3 versions;[PDF] ucm.es;https://eprints.ucm.es/56696/1/1136492049-334509_MANUEL_ANTONIO_FERN%C3%81NDEZ_ALONSO_Organizaciones_aut%C3%B3nomas_descentralizadas_DAOs_para_econom%C3%ADa_colaborativa_utilizando_Blockcha_1810491338.pdf;;;https://scholar.google.com/scholar?start=620&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094609-942;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;An Efficient Leakage-Resilient Authenticated Group Key Exchange Protocol;O Ruan, Y Yang, M Zhang ; … Conference on Network and System Security, 2019  Springer;;"… (1) Two oracles \(\varPi _{U_i}^t … Then, \(\textit{A}\) gets back the challenger's response; (3)

\(\textit{A}\) repeats the queries as it does in Step (1). However, the \(\lambda \)-BAFLR-freshness

of \(\textsf {Test}\) oracle should be obeyed; … In: Boneh, D. (ed.) CRYPTO 2003. LNCS, vol …";Cité 1 fois;;null;;;;https://scholar.google.com/scholar?start=760&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094621-994;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Decentralization as a new framework for the sharing economy;M Rocas;Royo  Handbook of the Sharing Economy, 2019  elgaronline.com;;"… Oracles, therefore, are the triggers for the execution of smart contracts. The ability to run smart

contracts confers to blockchain technology the capability to run autonomous … 2016, 19), and an

“open, self-organized network coordinated by crypto-economic incentives and self …";Autres articles;;null;;;;https://scholar.google.com/scholar?start=810&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094544-668;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Splitting a PRE-scheme on Private Blockchain;BS Rawal, Y Wang ; 2019 IEEE Canadian Conference of …, 2019  ieeexplore.ieee.org;;"… The electronic cryptocurrency platforms such as Bitcoin and Ethereum are developed on the … A.

Miller, A. Poelstra, J. Timón, and P. Wuille, ""Enabling blockchain innovations with … secure

unidirectional proxy re-encryption in the adaptive corruption model without random oracles …";Autres articles;;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/8852749/8861512/08861591.pdf?casa_token=_G4kKMPLBusAAAAA:Djk1fY6XJ3brPNUt2EC3D2Utb0OJo-gPF5lJ1gcgW1StwT-dJSfaun1ZK1csAeeRYOqOxbbJqXg;"
		Skip to Main Content


		
			
				
				

				

			

		


		
			
				
					
						








	
		
	

	







						

						





























	
	
		
	
	
		
			

		
	

	
	
	



						





	
	
		
			
				IEEE Account

					Change Username/Password
	Update Address


			

			
				Purchase Details

					Payment Options
	Order History
	View Purchased Documents


			

			
				Profile Information

					Communications Preferences
	Profession and Education
	Technical Interests


			

			
				Need Help?

					US & Canada: +1 800 678 4333
	Worldwide:  +1 732 981 0060

					
	Contact & Support


			

		

		
			
				
					
							About IEEE Xplore
	Contact Us
	Help
	Accessibility
	Terms of Use
	Nondiscrimination Policy
	Sitemap
	Privacy & Opting Out of Cookies


						
							A not-for-profit organization, IEEE is the world's largest technical professional organization dedicated to advancing technology for the benefit of humanity.
Š Copyright 2021 IEEE - All rights reserved. Use of this web site signifies your agreement to the terms and conditions.
						

					


					

				

				
			

		

	


	
	


						
						






		
		
		
		
		
		
		
		
		
		
		
		
		
			
				
			
			
			
			
		
		
		
		
		
		

			


			

			
			


		
 		
		
			 

						
						









































	

		
		

		
		
		

		
			
		
		
		

		

		
		


		

		
		
		
		
		
		
		
		
		
		
	
	


















		
		
			
				
					
					
								
					
								
			
				
					
					
								
					
								
			
				
					
						








 



					
					
								
			
				
					
					
								
			
				
					
					
								
					
								
			
				
					
					
								
					
								
			
				
					
					
								
					
								
			
				
					
					
								
					
								
			
				
					
					
								
					
								
			
				
					
					
								
					
								
			
		
	




























		
			
					
			
					
			
					
			
				
					








					
			
					
			
					
			
					
			
					
			
					
			
					
			
		
		
	





	
	
	
	
	
	
	


	
	
	

	

















					

				

			


			
				
			
		

	";"""og:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""twitter:title"",""Splitting a PRE-scheme on Private Blockchain""
""twitter:card"",""summary""
""Description"",""Splitting a PRE-scheme on the Private Block Chain (is a crucial decentralized management service and cryptographic access control mechanism for the decentralize""
""og:title"",""Splitting a PRE-scheme on Private Blockchain""
""resourceName"",""08861591.pdf""
""language"",""en""
""title"",""Splitting a PRE-scheme on Private Blockchain | IEEE Conference Publication | IEEE Xplore""
""og:description"",""Splitting a PRE-scheme on the Private Block Chain (is a crucial decentralized management service and cryptographic access control mechanism for the decentralized applications. By transporting private data distribution and design to the public block chain, proposed scheme enables everything from encrypted content marketplaces to secret credentials management to the file sharing system. In this paper, we propose splitting of Proxy re-encryption (PRE) scheme on the private block chain for flexibility, efficiency, extensibility, and privacy. We also experiment with the new use of proxy re-encrypting (PRE) scheme for the delegation of permission from one block to the other block. As per our knowledge, we have not seen any work which uses layered block chain technology with PRE-scheme.""
""twitter:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-UA-Compatible"",""IE=Edge""
""viewport"",""width=device-width, initial-scale=1.0""
""dc:title"",""Splitting a PRE-scheme on Private Blockchain | IEEE Conference Publication | IEEE Xplore""
""twitter:description"",""Splitting a PRE-scheme on the Private Block Chain (is a crucial decentralized management service and cryptographic access control mechanism for the decentralized applications. By transporting private data distribution and design to the public block chain, proposed scheme enables everything from encrypted content marketplaces to secret credentials management to the file sharing system. In this paper, we propose splitting of Proxy re-encryption (PRE) scheme on the private block chain for flexibility, efficiency, extensibility, and privacy. We also experiment with the new use of proxy re-encrypting (PRE) scheme for the delegation of permission from one block to the other block. As per our knowledge, we have not seen any work which uses layered block chain technology with PRE-scheme.""
""Content-Encoding"",""UTF-8""
""Content-Type-Hint"",""text/html; charset=utf-8""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=480&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094548-689;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[HTML][HTML] LoC—A new financial loan management system based on smart contracts;H Wang, C Guo, S Cheng ; Future Generation Computer Systems, 2019  Elsevier;;"… of locking and unlocking process of chaincode, construction of event oracle and the … Permissionless

blockchains typically involve a native cryptocurrency and often use consensus based on … One

major issue of permissionless blockchain is the high latency of block generation …";Cité 24 fois;Les 4 versions;[HTML] sciencedirect.com;https://www.sciencedirect.com/science/article/pii/S0167739X18324233?casa_token=0GKSBEfaiaQAAAAA:2t955j3YGQkVZVVKUUQitTVgY4J-6poSQCVBYCHEUXZNIfR48mSEsVgbWKU6yG91Z9iPRub7;;;https://scholar.google.com/scholar?start=500&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094656-1149;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;LaT-Voting: Traceable Anonymous E-Voting on Blockchain;P Li, J Lai ; International Conference on Network and System …, 2019  Springer;;"… Blockchain has the possibility of providing a trustworthy and decentralized mode to accelerate

its exploitation … If the verifier accepts a statement from a prover, there is a polynomial-time extractor

who can generate a valid witness when giving oracle access to the prover …";Cité 3 fois;;null;;;;https://scholar.google.com/scholar?start=960&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094537-635;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[CITATION][C] A Large-Scale Proof-of-Stake Blockchain in the Open Setting;L Fan, J Katz, HS Zhou;;;null;Cité 2 fois;;null;;;;https://scholar.google.com/scholar?start=450&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094560-733;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Rethinking general-purpose decentralized computing;EC Alp, E Kokoris;Kogias, G Fragkouli…  Proceedings of the …, 2019  dl.acm.org;;"… [4] WebAssembly. [5] Augur: A Decentralized Oracle & Prediction Market Protocol … Random Oracles

in Constantino- ple: Practical Asynchronous Byzantine Agreement Using Cryptogra- phy … Hawk:

The blockchain model of cryptography and privacy-preserving smart contracts …";Cité 4 fois;Les 6 versions;[PDF] acm.org;https://dl.acm.org/doi/pdf/10.1145/3317550.3321448?casa_token=l5V7Bo40Pn4AAAAA:vDZM2gJ4b_sAACyyAMPVhIaSWsSdCM7ECPfx4TPTv1bKmIx-F9Mz9LvB8stzNT66jxqxF-tt5aw;;;https://scholar.google.com/scholar?start=550&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094551-693;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Blockchain implementations.(c2019);AA Sabbagh ;2019 laur.lau.edu.lb;;"… associating it only with cryptocurrency. Throughout this study, Blockchain evolution

will be described to showcase how … field. Bitcoin is the most popular example that uses

blockchain technology based on the crypto currency model …";Autres articles;Version HTML;[PDF] lau.edu.lb;https://laur.lau.edu.lb:8443/xmlui/bitstream/handle/10725/12255/Ahmad_Al_Sabbagh_Thesis_Redacted.pdf?sequence=1&isAllowed=y;"
Lebanese American University 

 

Blockchain Implementations: A New Era in the 

Insurance Industry 

By 

Ahmad Al Sabbagh 

 

 

A thesis 

Submitted in partial fulfillment of the requirements  

for the degree of Master of Business Administration 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Adnan Kassar School of Business 

July 2019



  II 
 

 



  III 
 

 
 

 

 

 

 



  IV 
 

 
 

 

 

 

 

 

 

 
 

  



  V 
 

Blockchain Implementations: A New Era in the Insurance 

Industry 

Ahmad Al Sabbagh 

ABSTRACT 

The ""blockchain"" technology, supported by the decentralized digital currency Bitcoin, the 

artificial intelligence, and IoT technologies - has created much interest in the academia, 

industry, and the technology community. This is due to the fact that it is considered a 

breakthrough technology that could bring remarkable benefits to many different sectors, 

including health care, manufacturing, logistics, energy and precisely the financial 

industries among others. According to Gartner, blockchain is at the topmost of very high 

expectations, where the interest in the technology and the enthusiasm to implement it is at 

a peak level. Nonetheless, the technology is still viewed as not mature, thus yielding certain 

concerns. Within this paradox, the risk to adopt blockchain within the wave of enthusiasm, 

without objectively assessing its real added value is very high. Insurance is one of the 

finance sectors that, among others, started to carefully probe the possibilities of blockchain. 

For this specific sector, however, the hype cycle shows that the technology is still in the 

early innovation adoption phases, implying that the spectrum of possible uses and 

applications has not been fully explored yet. Insurers, as is the case with other firms that 

are not essentially active in the financial sector only, are at present expected to make a 

decision: adopt blockchain or not, unfortunately with the assessment of whether the 

investment was right not to be known till within 3–5 years. 

 



  VI 
 

Based on this, the study highlights the importance of implementing blockchain technology 

in this sector to gain optimal efficiency and effectiveness. Two blockchain technology 

models, the IBM proof-of-work model and the cryptocurrency model, are examined to 

highlight the benefits and the implications of implementing the technology in the insurance 

sector. The implementations of Blockchain technology in the insurance business using the 

IBM proof-of-work and Ethereum models are assessed and showcased through early 

adopters and major players in the industry. In addition, lessons learned are highlighted and 

experts’ insights collected through interviews and testimonials will be provided. Based on 

the findings, and using narrative analysis, a conceptual model for the adaptation and a 

strategy for the integration of the Blockchain technology into the business are proposed. 

The findings indicate that the Blockchain technology is resilient and secure tool in the 

insurance sector. The results also show that the use of smart contracts in the implementation 

of the blockchain technology in the insurance sector leads to increase in efficiency and 

decrease in the costs, fraud and processing time. 

KEYWORDS: Blockchain, Financial Industry, Bitcoin, Ethereum, Smart Contract, 

Insurance Economy, IoT, Artificial intelligence, B3i, UETA, ESIGN, FSI. 

  



  VII 
 

Table of Contents 
Chapter              Page 

I - Scope of the Study ........................................................................................................ 1 

1.1 Introduction: ........................................................................................................................... 1 

1.2 Blockchain Technology ......................................................................................................... 2 

1.3 Implementation of Blockchain Technology: .......................................................................... 3 

1.4 Blockchain in Financial Services Industry: ........................................................................... 4 

1.5 Aim of Study and Research Objectives: ................................................................................ 5 

1.6 Organization ........................................................................................................................... 6 

II - Blockchain Overview.................................................................................................. 7 

2.1 Basics of Blockchain.............................................................................................................. 7 

2.2 Types of Blockchain .............................................................................................................. 9 

2.3 Blockchain and Trust ........................................................................................................... 11 

2.4 Advantages and Disadvantages of Blockchain .................................................................... 12 

2.5 Blockchain Evolution........................................................................................................... 13 

2.6 Smart Contracts .................................................................................................................... 14 

III - Insurance & Blockchain Technology .................................................................... 16 

3.1 Insurance Overview ............................................................................................................. 16 

3.2 Insurance and Blockchain Technology ................................................................................ 20 

3.3 Smart Contracts and Insurance ............................................................................................ 21 

3.4 UETA and ESIGN ............................................................................................................... 22 

3.5 Big Data and Insurance ........................................................................................................ 24 

IV - Blockchain Technology Implementations ............................................................. 26 

4.1 Bitcoin Technology .............................................................................................................. 26 

4.2 Ethereum Blockchain ........................................................................................................... 28 

4.3 IBM Blockchain in Insurance .............................................................................................. 30 

4.4 Findings on Cryptocurrency & IBM Models ....................................................................... 33 

V - Benefits of Using Blockchain in Insurance ............................................................. 36 

5.1 Overview .............................................................................................................................. 36 

5.2 Blockchain is a secure investment tool based on trust ......................................................... 36 

5.3 Generating insurance smart contracts and in minimizing fraud ........................................... 38 

5.4 PTP investment and insurance policies will be the future of the insurance sector .............. 40 



  VIII 
 

5.5 Proof of work for insurance policies generated using blockchain technology .................... 41 

5.6 Benefits ................................................................................................................................ 46 

5.7 Implications ......................................................................................................................... 47 

VI - Implementation of Blockchain in the Insurance Industry .................................. 48 

6.1 Insurance sector vis a vis Blockchain .................................................................................. 48 

6.2 The B3i ................................................................................................................................ 51 

6.3 Kasko2Go & FidentiaX ....................................................................................................... 53 

6.4 Lessons Learned................................................................................................................... 54 

6.5 Blockchain and IoT .............................................................................................................. 56 

6.6 When Experts Share Their Insights ..................................................................................... 60 

6.7 Conceptual Model: Blockchain technology adoption in Insurance Companies .................. 63 

VII - Discussion & Conclusion ....................................................................................... 67 

7.1 Recap ................................................................................................................................... 67 

7.2 Benefits and Implications of Implementing Blockchain Technology in the Insurance 

Industry ...................................................................................................................................... 68 

7.3 Advantages and disadvantages ............................................................................................ 69 

7.4 Bottom Line ......................................................................................................................... 71 

References ........................................................................................................................ 73 

Appendix A: Interview Questions with SMEs  (Asadi, Hoang, 2018) ........................ 81 

Appendix B: “Benefits of utilizing blockchain in different industrial application 

domains” (Al-Jaroodi, Mohamed, 2019) ....................................................................... 82 

 

 

  



  IX 
 

LIST OF TABLES 

Table              Page 

Table I: Comparison between Various Blockchain Models     11 

Table II: Versions of Blockchain Technology       14 

Table III: Bitcoin, Ethereum, and IBM Blockchain Comparison     34  

Table IV: Blockchain integration with AI in the Insurance Business    58 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 



  X 
 

 

LIST OF FIGURES 

Figure              Page 

Figure 1. Graphical Representation of how Blockchain performs     09 

Figure 2. Global Life Insurance GWP Growth between Years 2015 and 2019   19 

Figure 3. Global Non-Life Insurance GWP Growth between Years 2015 and 2019  19 

Figure 4. Current non-bitcoin blockchain technology distribution    48 

Figure 5. Percentage of Respondents to Blockchain Technology & phases reached  49 

Figure 6. Investments & estimated capitals spending’s of blockchain between 2013 & 2019 52 

Figure 7: Conceptual Model: Insurance Business Process to Adopt Blockchain   66 

 

 

 



  1 
 

CHAPTER I 

Scope of the Study 

This chapter comprises an introduction and highlights the value and originality of 

the study. It is followed by the research questions to be tackled and is concluded with the 

thesis statement. 

1.1 Introduction: 

Blockchain technology has defined new aspects in the information technology 

field. As any other technological advancement, Blockchain affected positively several 

industries in general and the financial services industry (FSI) in particular. As this 

technology is highly disruptive, and as its implementation changed the market aspect, 

Blockchain is getting the attention of industry experts and academicians (Collomb, Sok, 

2016). The effect of Blockchain is snowballing to the extent it provided blueprints for a 

new economy (Swan, 2015). As introduced in the World Economic Forum, Blockchain is 

identified as a Digitalized Ledger Technology (DLT); however, many people are still 

associating it only with cryptocurrency. 

Throughout this study, Blockchain evolution will be described to showcase how 

its components contributed to the business applications. In addition, different executions 

of Blockchain technology implementation models (Bitcoin, Ethereum, and IBM) will be 

described and analyzed throughout this study to showcase their benefit and how they fit 

with insurance business applications. 

 



  2 
 

1.2 Blockchain Technology 

Blockchain is a distributed ledger technology preserved by a public or private 

network of nodes, recording transactions executed between. Data inserted in the 

blockchain is public to all users with the legitimate access, and impossible to alter 

(Gatteschi, Lamberti, Demartini, Pranteda, SantamarĂ­a, 2018). Smart contracts are 

automated contracts, publicly posted, and preserved on the blockchain, where its terms 

and conditions are spontaneously written into lines of code post consensus of involved 

parties (Szabo, 1997).  

Blockchain technology has defined new aspects in the information technology 

field. Bitcoin is the most popular example that uses blockchain technology based on the 

crypto currency model. Ethereum is another popular model of blockchain, which 

companies use as a ledger technology to build new programs. Although bitcoin is 

controversial, the underlying technology has worked flawlessly and has proven itself as a 

promising technology in both financial and non-financial sectors.  

As Blockchain is considered as a technological phenomenon with a lot yet to 

explore, it is getting associated with the following buzzwords: “The new Graal”, “The 

philosopher’s stone”, “The new black”, or “The next big thing” (Gatteschi, Lamberti, 

Demartini, Pranteda, SantamarĂ­a, 2018). Lately, Blockchain with the introduction of 

smart contracts is the contemporary hype as it has great potentials to our day-to-day 

activities and business processes. 



  3 
 

1.3 Implementation of Blockchain Technology: 

Blockchain is considered a technological breakthrough with the cryptocurrency 

implementation model (Nofer, Gomber, Hinz, Schiereck, 2017). It has great potentials as 

applications enabler across various domains(Al-Jaroodi, Mohamed, 2019). Below, a list 

of several industries identified in several studies and use cases that benefited from the 

Blockchain technology (Al-Jaroodi, Mohamed, 2019; Marr, 2017; Collomb, Sok, 2016; 

Insights, 2017; Jurowiec, 2018): 

1- Finance: Identity check and verification, transactions unicity, transactions 

validity, third party role minimization. Example: “Ethereum”    

2- Healthcare: Data protection (secure medical patients medical records), and 

Data accessibility. Example: “MedicalChain” 

3- Logistics and Transportation: synchronisation between the value chain 

stakeholders (from raw materials supplier to the customer). Example: “IBM 

Blockchain” 

4- Manufacture: Cost reduction, time management, inventory visibility, and 

logistics. Example: “SKUChain” 

5- Energy: Manage microgrids, and manage excess power to be sold and 

invoiced (Cohn, West, Parker, 2017). Example: “Transactivgrid” 

6- Robotics: Management without human intervention (better automation) 

across several sectors, enhance security measures, and accurate execution. 

Example: “robo-bee”. 



  4 
 

7- Others (including but not limited to pharma, construction, and agriculture): 

Took advantage from at least above-mentioned applications. Example: 

“Blockverify”. 

1.4 Blockchain in Financial Services Industry: 

The financial service industry is not limited to banking, but it also includes 

investing, insurance, and tax & accounting. With technological advancement, the 

financial service industry became highly dependent and interconnected with technology. 

It was clear how much the financial industry boosted along with technology evolution. As 

stated in the above section, Blockchain contribution in the financial was mainly in the 

application of Identity check and verification, transactions unicity, transactions validity, 

third party role minimization.  In addition, Blockchain introduced new concepts to the 

industry, among them:  

1- Cryptocurrency or Digital Currency: replacing the pool of hundreds of 

currencies worldwide with a single currency, example: “Bitcoin” (Ammous, 

2016)    

2- Cost-less Trading: eliminating central authority for stoke trading, which 

results in less additional cost and time, which increase transparency and 

accountability. Example: “tZero” (Del Castillo, 2016). 

3- Digital Marketplace for insurance: automating the full process of insurance 

contracts from policy negotiation, to premium and claims settlement, 

passing by reinsurance and conflict resolution using smart contracts 



  5 
 

component. The automated process is found to be highly cost (time and 

money) saving Example: “FidentiaX” (Marr, 2019).  

4- Financial settlements: implementing a fully transparent and accurate 

interconnected between different type of organizations and companies. 

Example: “SETL” (Yoo, 2017).  

5- Peer-to-Peer Global Financial Transactions: changing the funding concept 

from and to any individual and as it explains itself, removing any 

middleman. Example: “Ablrate” (Fattah, Fattan, 2002).  

1.5 Aim of Study and Research Objectives: 

The aim of this thesis is to Examine various modelling of blockchain 

implementations. In particular, analyse the IBM proof of work model and the 

cryptocurrency system model. In addition, the efficiency and effectiveness in using 

blockchain technology in peer to peer insurance as an investment (creating insurance 

companies) and in purchasing / issuing policies. To assess the efficiency and 

effectiveness of peer-to-peer insurance several hypotheses will be tested using Literature 

review of previous studies and through conducted number of interviews with Subject 

Matter Expert in the technology and insurance sectors.  

The objectives of this study discuss the following research matters that will be 

addressed and analysed:  

1. Identify and understand the technology behind blockchain.  

2. Understand the difference between the two famous implementations of 

blockchain, Bitcoin blockchain and Ethereum blockchain 



  6 
 

3. Discuss how the insurance industry could leverage from the blockchain 

technology as an investment tool and as an insurance contract generator. 

4. Discover the influence of blockchain technology on the insurance sector and 

highlight the companies that have adopted the technology and are adopting 

strategies. 

1.6 Organization  

This study explores how Blockchain technology offers potential adoption in 

insurance sector embracing the effectiveness of fraud, administrative costs, logistical 

costs, operational costs, peer-to-peer investments and service growth. The remainder of 

this thesis is as follows: Chapter 2 includes an overview of the blockchain technology and 

its types, its evolution, along with the basics of its important components, and the pros of 

cons. Chapter 3 provides a brief overview on the insurance industry, also a brief related 

to the relation of insurance with the blockchain technology. Following chapter 4 explores 

different implementations of Blockchain. In chapter 5, benefits of integrating Blockchain 

in the insurance industry are stated. Actual implementations of Blockchain technology in 

the insurance business are explored in chapter 6. Also, the latter chapter will showcase 

technology and insurance industry leaders’ point of view regarding embracing blockchain 

technology. This chapter will conclude with a conceptual model, on how the insurance 

business should pilot the blockchain technology adoption Finally, the last chapter will 

discuss and conclude with the findings reported throughout this thesis. 

 

 



  7 
 

CHAPTER II 

Blockchain Overview 

This chapter will provide the basics of blockchain along with its different versions 

and components. In addition to the advantages and disadvantages of the Blockchain. 

Blockchain evolution, concepts, and implementations presented in this chapter will be used 

throughout the thesis. 

2.1 Basics of Blockchain 

Before 2016, blockchain technology was unexplored. Today, it is recognized as the 

groundbreaking advance that is capable of reducing frictional costs and enabling new 

models of commercial and social actions (Sachs, 2006). Blockchain technology can be 

represented as a long DNA chain that expands with the addition of new information to 

related transactions. As the name implies, it is a chain of previously validated transactions 

noted as blocks sorted sequentially comprising a public ledger. A network of nodes 

maintains the chains and adds it to a new block after verifying the validity of transactions. 

This is known as the mining process. 

The blockchain gained recognition as the technology underpinning the 

cryptocurrency bitcoin. Without a central authority, blockchain technology in 

cryptocurrency maintained a safe, permanent and tamper-proof digital ledger of 

transactions to a set of parties. However, the potential applications of blockchain can go 

far beyond digital currencies and can be integrated in industries ranging from 

manufacturing to law, healthcare and even insurance. 



  8 
 

Transactions are carried out without the need of an intermediary.  Each user of the 

blockchain is capable of writing and viewing the public ledger without changing the 

regulations (Marr, 2017). All transactions are delivered in real time (EY, 2018). Invalid 

transactions are immediately identified, and transaction validity is maintained through 

different algorithms. Sustaining the integrity of the system depends on a variety of refined 

cryptographic algorithms (Binder, Mußhoff, 2017). Cryptography is a mechanism that 

protects the user’s identity and keep the transactions secure (El-Kassar, ElGammal, & 

Haraty, 2004) (El-Kassar, ElGammal, & Haraty, 2005). Users sign each transaction with a 

cryptographic key that validates the authenticity of the user and prevents vicious hackers 

from portraying legitimate users. Several transactions are combined to a single block. The 

cryptographic signature connects the block with the preceding block. Asymmetric 

encryption is used to implement keys operated to sign transactions.  Each user creates two 

keys, a private key that is kept exclusive for the user; and a public key that is publicly 

accessible. Sharing information is only applicable with sharing the public key (Vigna, 

Casey, 2015).  

As a public ledger, blockchain permits high-trust communications without the 

need for an intercessor. Bitcoin and Ethereum transactions are public and recognized via 

the user’s public key. The system retains its resilience by administering copies of the 

ledger.  On the other hand, blockchain can be private. These blockchains are managed by 

a single user or entity. Access to the ledger is restricted and needs further approval from 

the owner.  Blockchain could be implemented as public and as private. 



  9 
 

 

Figure 1. Graphical Representation of how Blockchain performs. (PwC, 2015). Money is 

no Object: Understanding the evolving cryptocurrency market  

2.2 Types of Blockchain 

Blockchain technology could be divided into the following 3 models: public 

blockchain, private blockchain and federated blockchain. The consensus in both private 

and federated blockchain is “permissioned” whereas that of public blockchain is 

“permissionless”. 

A. Public Blockchain 

Bitcoin, Ethereum, and NXT are good examples of what is known as public 

blockchain. Anonymous users can have access to the shared ledger, send transactions and 

verify newly added blocks using their computing power. A public blockchain is open to 

all entities and ensures transparency in the network. Cryptographic codes and economic 

inducements secure the public blockchain. This model of blockchain is not suitable for 

enterprises which favor access control and permissions to users within the chain. 

  



  10 
 

B. Private Blockchain 

Private Blockchains are useful in enterprise applications. This model allows 

specific industries or institutions to join the blockchain network. A central authority is 

granted the access and has the permission to add transactions to the ledger. These 

transactions are sustained through a process known as proof-of-authority. Users who 

would like to join these models can only have access if it has been granted by the 

industry or institution. The total number of users within a private blockchain is 

comparatively reduced than that of a public blockchain, which expedites the processing 

power and saves the processing time. Good examples of private blockchain are 

Everledger and Ripple. 

C. Federated Blockchain 

Federated Blockchain can be embedded as part of the private blockchain. As 

mentioned above, within a private blockchain, the access could be granted for a single 

institution. Unlike private blockchain, federated blockchain grants the access to multiple 

selected institutions. It can be seen as an intermediate between the private and public 

blockchain. Good examples of federated blockchain are B3i and R3. 

The table below displays a better understanding of the differences between the 

above mentioned blockchain models in terms of accessibility, efficiency, consensus, 

speed, immutability, network, security and assets. 

  



  11 
 

Table I: Comparison between Various Blockchain Models 

Feature Pubic Private Federated 

Accessibility Anyone Single Institute Multiple selected institutes 

Efficiency Low High High 

Consensus  
“Permissionless” with 

anonymous identities 

“Permissioned” with known 

identities 

“Permissioned” with known 

identities 

Speed Slow Fast Fast 

Immutability Impossible to tamper Could be tampered  Could be tampered 

Network Decentralized  Partially decentralized Partially decentralized 

Security Proof-of-work Pre-approved users  Pre-approved users 

Assets Native Any Any 

 

2.3 Blockchain and Trust 

Blockchain strengthens trust within a business network. It provides cryptographic 

proof over a set of transactions that can’t be altered, and any possible corruption is directly 

prominent. The dependence on the current level of governmental safeguards to monitor 

and control the flow of business is diminished with such self-policy. The burden on 

regulatory system is scaled down with blockchain, facilitating the reviewal of relevant 

transaction details for auditors and regulators. Trust with blockchain can be achieved 

through the following five aspects: 

1- Sustainability: The platform is not dependent on an individual entity. The 

ledger is shared and frequently updated in real time. 

2- Security: Cryptographic techniques maintain confidentiality, prevent 

unauthorized access to the network and ensure the identity of each 

participant. 



  12 
 

3- Transparency: Participants identify their identities and validate their 

transactions without the need of an arbitrator. 

4- Transactional: Consensus algorithms are integrated to validate the 

transaction by a participant. 

5- Flexibility: Blockchain can expand when supporting end-to-end business 

processes when it comes to business rules and smart contracts. 

2.4 Advantages and Disadvantages of Blockchain 

There are different speculations on blockchain technology. One school believes that 

the technology is promising and trustworthy (McConaghy, Trent, Marques, MĂźller, De 

Jonghe, McConaghy, McMullen, Henderson, Bellemare, Granzotto, 2016). The other 

school believes that the technology is still unrefined and overhyped (Bartlett, 2015). Below, 

we briefly state the advantages and disadvantages of the blockchain technology.  

Advantages  

- Trust among users through validating nodes and reducing intermediaries  

- Shared ledger which grants access to data and transactions which preventing 

the loss of important data 

- Accessibility to various users. All users can potentially read the 

data/transactions 

- With smart contracts, all activities are automated 

- Immutability, once data has been submitted, it cannot be altered 

- Transparency is secured, with all users having access to the history and the 

final state of transactions 



  13 
 

- Decentralization, with transactions running without a central authority 

Disadvantages  

- High power of consumption (Nofer, Gomber, Hinz, Schiereck, 2017) 

- The need of redundant mining requires expensive hardware. It is believed 

that a great part of the computing power is being wasted. 

- The need for gigantic space due to data replication, 105 GB for Bitcoin 

and 70 GB for Ethereum  

- Processing time is relatively slow. It takes 10 to 60 minutes to create a 

bitcoin block and 15 seconds for that of Ethereum  

- Smart contracts must not be dependent on external APIs  

2.5 Blockchain Evolution 

Blockchain technology was initially linked to cryptocurrencies. Bitcoins were the 

first prototype of cryptocurrency. At later stages, new applications were introduced to 

blockchain and several prototypes were developed. Evolution of blockchain technology 

served their versions:  

- Blockchain V1.0 identified to bitcoins and cryptocurrency (Tschorsch, 

Scheuermann, 2016)  

- Blockchain V2.0 assimilated with smart contracts 

- Blockchain V3.0 expanded to various sectors such as health, government, 

learning, and sciences 

  



  14 
 

Table II: Versions of Blockchain Technology (Euro Banking Association, 2015) 

Version Purpose Application Examples 

Blockchain 

1.0 
Financial Transactions 

Currencies 

Bitcoin 

Dash 

Dogecoin 

Asset-centric technologies 
Ripple 

Stellar 

Blockchain 

2.0 

Record & Verification 

Systems 
Asset Registry 

Colored Coins 

Everledger 

Mastwecoin 

Smart Contracts Application stacks 

Eris 

Ethereum 

Hyperledger 

 

2.6 Smart Contracts 

Smart contracts have been introduced in the 90s. Yet, their full potential has been 

revealed recently with the evolution of blockchain technology. By means of cryptography, 

smart contracts could be converted into computer codes, stored and replicated on the 

blockchain for various purposes. Smart contracts allow the user to exchange money, 

property, shared without the need of a third party. Using a smart contract is cost-effective 

due to the fact that this type of contracts eliminates operational expenses. Moreover, the 

speed of transactions is increased due to the fact that this type of contracts is automated 

and is not dependent on any human involvement. Many industries could benefit from this 

technology as part of their blockchain as it helps reduce fraud and overbilling. 

Smart contracts are automated, self-executed transactions having multiple benefits. 

From the name “SMART”, the contracts are written digitally and executed accurately 

through computer systems. Smart contracts are stored in coded commands and provides a 

powerful evidence for all parties agreeing on a certain issue or terms. Executing and 



  15 
 

administering the contracts by a third party or intermediary is no longer required (Buterin, 

2014). 

The year 2017 has been noted as “The Year of Smart Contracts”. Blockchain smart 

contracts have had a great impact in different industries. The technology has been 

integrated in new industries and kicked in new markets (Raskin, 2017).  

Each user of the smart contracts is required to use his/her private key to sign off a 

transaction. Identities are verified by these keys and a record of the transaction is created. 

A transaction is valid only when consensus is achieved. Thereafter, the transaction is added 

to a block to the chain of previous transactions forming an immutable ledger. Assuming, a 

user would rather delete or edit a transaction, a new transaction will be assembled instead 

of deleting a whole block from the chain – all historical transactions will never be deleted. 

Blockchain technology has been implemented in various industries. Yet, the usage 

of smart contracts has always been linked with Ethereum blockchain technology. The 

scripting language of Ethereum made it easier to embrace smart contracts. Startups have 

made good use of Ethereum because of its ability to create smart contracts (Marvin, 2017).  

Industry pioneers have already started investigating potential markets with new 

applica";"""date"",""2020-10-13T07:26:43Z""
""pdf:PDFVersion"",""1.7""
""xmp:CreatorTool"",""MicrosoftÂŽ Word for Office 365""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""language"",""en""
""dc:format"",""application/pdf; version=1.7""
""pdf:docinfo:creator_tool"",""MicrosoftÂŽ Word for Office 365""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""xmp:CreateDate"",""2019-07-26T11:01:16Z""
""modified"",""2020-10-13T07:26:43Z""
""pdf:hasMarkedContent"",""true""
""xmp:ModifyDate"",""2020-10-13T10:26:43Z""
""pdf:docinfo:creator"",""Ahmad Al Sabbagh""
""meta:author"",""Ahmad Al Sabbagh""
""meta:creation-date"",""2019-07-26T08:01:16Z""
""created"",""2019-07-26T08:01:16Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-07-26T08:01:16Z""
""resourceName"",""Ahmad_Al_Sabbagh_Thesis_Redacted.pdf""
""Author"",""Ahmad Al Sabbagh""
""producer"",""MicrosoftÂŽ Word for Office 365""
""pdf:docinfo:producer"",""MicrosoftÂŽ Word for Office 365""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""access_permission:modify_annotations"",""true""
""dc:creator"",""Ahmad Al Sabbagh""
""dcterms:created"",""2019-07-26T08:01:16Z""
""Last-Modified"",""2020-10-13T07:26:43Z""
""dcterms:modified"",""2020-10-13T07:26:43Z""
""xmpMM:DocumentID"",""uuid:151A18BC-BFB0-4DE1-A2A3-BFB7187581F4""
""Last-Save-Date"",""2020-10-13T07:26:43Z""
""pdf:docinfo:modified"",""2020-10-13T07:26:43Z""
""meta:save-date"",""2020-10-13T07:26:43Z""
""Content-Length"",""4183513""
""Content-Type"",""application/pdf""
""xmp:MetadataDate"",""2020-10-13T10:26:43Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Ahmad Al Sabbagh""
""dc:language"",""en-US""
""pdf:producer"",""MicrosoftÂŽ Word for Office 365""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""92""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""286"",""7"",""13"",""18"",""1591"",""1359"",""3891"",""2593"",""315"",""598"",""1346"",""1487"",""1337"",""1419"",""1453"",""1552"",""1436"",""1751"",""961"",""1362"",""1427"",""1339"",""1124"",""1535"",""1475"",""1572"",""1727"",""1538"",""801"",""1322"",""1913"",""1833"",""1784"",""1558"",""8"",""1681"",""1514"",""1641"",""1755"",""1813"",""1988"",""1917"",""1919"",""1322"",""798"",""1442"",""1901"",""1790"",""1498"",""1644"",""1651"",""1894"",""1882"",""1820"",""1440"",""1906"",""1732"",""1141"",""460"",""717"",""1761"",""1934"",""924"",""1844"",""1792"",""1810"",""1961"",""1351"",""1908"",""1889"",""1743"",""1892"",""1828"",""1751"",""1574"",""1103"",""1632"",""1886"",""1737"",""1636"",""1821"",""782"",""1830"",""1896"",""2066"",""2034"",""2088"",""2218"",""1977"",""984"",""1447"",""127""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-07-26T08:01:16Z""
";https://scholar.google.com/scholar?start=510&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094565-754;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[PDF][PDF] Open Climate;ME Wainstein ; Leveraging Blockchain for a Global, Transparent and …  lists.hyperledger.org;;"… In their blockchain use, the oracle's role is to filter, verify and harmonize real-world data so that

it can safely integrate into the blockchain and be used, for example, in the execution of smart

contracts. When equipped with machine-learning functionality, oracles can help rapidly …";Cité 1 fois;;[PDF] hyperledger.org;https://lists.hyperledger.org/g/climate-sig/attachment/193/0/Whitepaper_OpenClimate.pdf;"
 1 

 

open climate 
Leveraging blockchain for a global, transparent and integrated climate accounting system 

 

Martin E. Wainstein 
martin.wainstein@yale.edu 

 

 

 

Abstract  

The open climate project is an open source initiative exploring the application of distributed ledger technology 
(DLT) and other emerging technologies, such as IoT (Internet of Things), big data and machine learning, to the 
challenge of helping the world keep a transparent climate accounting system towards the climate targets set in 
the 2015 Paris Agreement—i.e. maintaining anthropogenic warming below 1.5oC. Global climate accounting, the 
process of recording climate actors and their actions in respect to the shared account of the planet’s climate state, 
occurs in diverse set of registry platforms that are individually centralized and collectively dispersed and unlinked. 
This is often due to lack of trust between actors, resisting to share data that exposes them to scrutiny. This project 
involves a software ‘platform of platforms,’ distinguished here as the Open Climate1 platform, the development of 
climate communication protocols, and a shared user interface as portal to the system. The platform acts as a 
common integrator that can reconcile climate records and functions from both legacy and DLT-based climate 
platforms in the pursuit of helping maintain a decentralized ‘ledger of ledgers’. With climate actors and their 
associated records mapped in a shared network— ranging from countries, to companies to individuals— DLT and 
other cryptographic tools are primarily used to: provide general transparency alongside individual data privacy, 
prevention of double counting in the digital certification and trading of climate actions, and a platform for 
contractual automation of rules and mechanisms with financial nature; from Paris Agreement stocktakes to carbon 
pricing and rewards for mitigation outcomes. 

We present here the architecture for the Open Climate platform as well as describe its full stack prototype. Whilst 
the platform is currently incubated at the Yale Open Innovation Lab (openlab) it combines multiple other platforms 
in advanced technological stages; incubated and developed by a growing network of collaborators. For the 
combined development, the open climate project adopts a multi-stakeholder open innovation framework and 
consortium to actualize this ambitious endeavor through radical collaboration.  
 

 

 

 

 

 

 

 

 

 

 

 

 

 
1 We distinguish with capitalized letters the ‘Open Climate platform’ from the ‘open climate project’ as a broader initiative i nvolving other networked platforms 
and protocols.  



 2 

Table of Content  

 

1. Introduction and problem statement 

a. Earth’s carbon and climate ledger challenge 

i. The Planet’s accounting track 

ii. The World’s accounting track 

b. Box 1. Our shared global budget 

2. Open Climate System and Platform of Platform: Solution overview 

a. Six project pillars: guidelines for success in the application of blockchain for global climate accounting  

b. Multi-domain linking of climate scopes 

c. Technology stack and platform development 

d. User experience and climate portal interface  

3. Architecture and highlighted functions 

a. Earth data consensus: towards a decentralized accounting of the planet’s carbon budget 

b. The Paris Agreement: a smart climate contract 

c. Climate actor accounts and user registration 

d. Nested accounting: metadata for incorporating non-state actor’s climate actions 

e. Climate Action Monitoring Reporting and Verification 

f. Climate Finance 

4. Integrated Platforms and working groups under an open innovation framework  

a. Introduction 

b. Integarted Platforms 

c. Working groups and pilots 

d. Open innovation framework and consortium effort 

5. Project notes 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 



 3 

Open Climate 

A platform of platforms and an open system for global climate accounting and planetary 
accountability 
 
 

We present here the Open Climate platform, an open source software enabling a decentralized and transparent 
global climate accounting system, operating as ‘platform of platform’ that acts as the system’s routing hub; 
integrating, via application programming interfaces (APIs), legacy climate data and accounting platforms with 
emerging blockchain based ones. Using decentralized ledger technology (DLT), the system proposes to harness a 
radically collaborative network to reconcile aclimate ‘ledger of ledgers.’ The Open Climate platform includes a user 
interface as a portal to the system, providing access to the main functions climate actors need to account their 
climate action progress and participate in compliance, trading and financial schemes. Moreover, it uses the power 
of smart contracts to automate key articles in the UNFCCC Paris Agreement, linking political actors and their 
commitments with the physical ecosystem state of the planet, and proposes a mechanism by which subnational 
and non-state actors can account their actions towards nationally determined contributions and participate in 
international markets of mitigation outcomes.   

The Open Climate platform, portal and integration protocols are in an alpha prototype phase. Platform can be 
accessed at www.openclimate.earth and source code can be found at 
www.github.com/YaleOpenLab/openclimate. 
  

 

1. Introduction & problem 
statement 
As we move to a stricter management of carbon in our 
atmospheric commons to prevent global warming from 
exceeding a dangerous threshold of 1.5/2oC, we must revise 
the process of transparent carbon and climate accounting. 
Historically, global accounting has been focused at the county-
level, where Parties to the United Nations Framework 

Convention on Climate Change (UNFCCC)— the primary 
international climate secretariat— negotiate commitments 
and submit their greenhouse gas inventories. Ensuring 
inventories follow the correct guidelines and have robust 
supporting data has been far from a simple task. Countries are 
often disincentivized to be fully transparent on their carbon 
accounting, particularly when economic opportunities are 
linked, or perceive to be linked, with higher emission 
practices. This dilemma has eroded trust in the political 
climate ecosystem.  

The 2015 Paris Agreement is a landmark international 
commitment that introduces guidelines to rebuild climate 
trust with a strong foundation in transparency and bottom-up 
action. It is considered a “bottom-up” climate change 
agreement because it proposes that countries define their own 
nationally determined contributions (NDCs) towards 
domestic emissions reductions. Countries are then expected to 
periodically revise their NDCs and strive to meet more 
ambitious targets. 

Many provisions of the Paris Agreement are obligatory but not 
legally binding. There are no consequences for failure to 
achieve one’s NDC other than the fact that nations around the 
world use political pressure to hold one another accountable. 
Nevertheless, Article 6 of the Paris Agreement opens up 
avenues for cooperation between nations, for example by 
allowing international transfers of mitigation outcomes —
essential the possibility of transacting climate credits between 
countries to fulfill NDCs efforts. Article 13 of the Paris 
Agreement encourages transparency amongst nation-states, 
as they must submit greenhouse inventories and information 
on their progress towards implementing their NDCs. This 
transparency drives the need for an innovative approach to 

Box 1. Our shared global budget  

Planet Earth’s atmosphere can hold a limited amount of 
carbon dioxide equivalent (CO2e) emissions before average 
global temperatures unleash the most costly and damaging 
impacts of climate change. The Paris Agreement set a 
global goal of holding global warming well below 2oC and 
aiming for a 1.5oC limit of warming, relative to pre- 
industrial levels.  

The limited quantity of emissions relative to this 1.5/2oC 
threshold has been termed our global ‘carbon budget’. 
Scientifically, the carbon budget is not a fixed number and 
never will be — it has an uncertainty range and the data 
and knowledge used to calculate it is updated every year 
(Rogelj et al., 2019). However, scientists estimate around 
600 GtCO2e remains in the budget, while global annual 
emissions are around 40 GtCO2e. Thus, the key take-away 
when looking at the carbon budget science is that if present 
emission pathways are left unchecked, the budget could be 
consumed in as little as 15 years. After this, we’ve crossed 
an irreversible threshold in planetary resilience. 

http://www.github.com/YaleOpenLab/openclimate


 4 

climate accounting. However, the exact mechanisms to deliver 
this are yet to be fully developed and would still continue to 
depend on the UNFCCC as the official warehouse tracking 
national climate actions. Furthermore, nation states are not 
the sole climate action stakeholders. Cities, provinces and 
regions (i.e., subnational actors), as well as business, investors 
and civil society —collectively referred here as non-state 
actors (NSA)— are increasingly recognized for their ability to 
catalyze, implement, and innovate climate actions (Hsu et al., 
2019). In some cases, these efforts go beyond or are more 
ambitious than national governments’ commitments.  

Consolidating a climate accounting system that can combine 
state and NSA climate actions is essential to the success of the 
Paris Agreement and the prevention of dangerous global 
warming. In fact, NSAs and their progress should inform 
national target-setting, tracking and policy-making that in 
turn should encourage even more non-state action 
commitments. Quantitatively assessing and tracking climate 
pledges and certifying the efforts to achieve them, however, 
are still fraught with difficulties. Existing measurement, 
reporting and verification (MRV) systems to track climate 
action —both from state and NSAs— are labor-intensive and 
costly, frequently requiring third-party consultants, which 
discourages resource-constrained actors from participating 
and recording actions in transnational climate action 
networks or measuring their climate change impacts at all.  

If we were to consolidate and maintain a single record-
keeping ledger with global consensus (i.e. where all parties 
agree) the task would be far from a simple under a trustless 
and competitive world. Decades of slow climate negotiations 
among countries attest to the intricacy of this challenge. The 
rise and maturity of blockchain and its cryptographic science, 
paired with emerging digital technologies such as internet-

connected sensors, big data and artificial intelligence can 
provide robust opportunities for existing and new climate 
platforms to streamline and incentivize data collection, 
climate action certification (i.e. MRV), accounting and trade. 
These tools could fill a critical gap in the understanding of how 
bottom-up non-state climate actions are implemented, what 
they achieve, and how to build a sustainable system that 
lowers measurement and reporting burdens to be more 
inclusive globally. 

Whilst the initial application of blockchain focused on digital 
currencies (e.g. Bitcoin), other non-financial applications 
quickly followed. In fact, its core promise of decentralized 
consensus eventually caught the attention of the climate 
world. Eventually, the UNFCCC declared its support for 
research on blockchain and distributed ledger technologies 
(UNFCCC, 2018). Following this announcement, initiatives like 
the Climate Chain Coalition have successfully created a 
growing network of entrepreneurial actors that are actively 
exploring the blockchain and climate intersection, each with 
their own set of technological value propositions.  

To date, however, there hasn’t been a compelling direct 
application of the technology, at least not in terms of a global 
internationally recognized framework for carbon and climate 
accounting that propose to leverage the power of trustless 
decentralization and automation to integrate legacy 
accounting practices with emerging technological ones. There 
has also been little discussion about how to address questions 
around the governance of these tools, data sharing between 
existing climate platforms, development of globally accepted 
accounting protocols for NSAs, and the dichotomy of 
maintaining actor data privacy alongside climate 
transparency.  

  

Figure 1. Emission pathways, carbon budgets and the planet vs. world accounting tracks 
The figure shows historic anthropogenic greenhouse gas emissions with ‘most likely’ projected emission trajectory, and those consistent with the 1.5/2oC 
climate targets set in the Paris Agreement, which define the remaining carbon budget —the total limited amount of CO2e humanity can still introduce into 
the atmosphere. The diagram is used to conceptualize the two principal carbon and climate accounting track; one relating to the physical planet, and the 
other involving the political boundaries involved in the human world.  



 5 

1.1 Earth’s carbon and climate ledger 
challenge 

Most of the ground-work and scientific basis for climate 
accounting mechanisms have been significantly developed 
thanks to decades of international scientific and political 
efforts. We propose that integrated blockchain development 
efforts, therefore, should focus on complementing existing 
frameworks; adding a protocol and standards layer for 
decentralized record-keeping and contractual automation (i.e. 
smart contracts) to optimize and reduce accounting and 
transaction costs. In general terms, the application of 
blockchain technology to provide global climate 
accountability should consider two distinct accounting tracks, 
each with both fixed and variable numerical components, 
whose state can be tracked with distributed ledgers (see 
figure 1 for a visual breakdown of these components):  

1.1.2 The Planet’s accounting track—  

This track must consider Earth as the physical planet devoid 
of human created political divisions, and purely based in 
physical science. In other words, this can be seen as 
decentralized Earth ledger that encompasses the main aspects 
covered by working group 1 of the intergovernmental panel 
on climate change (IPCC). The proposed two fundamental 
components to develop and track are: 1) A consensus 
mechanism to determine the remaining carbon budget and 
its unavoidable uncertainty range (see box 1 for more info 
outlining the importance of tracking the carbon budget). 
Whilst this number may need to be constantly updated, it can 
be a fixed value determined by a median range or 
democratically agreed by, for example, an international 
scientific committee. 2) The process to track the aggregate 
rate in which this budget is consumed, in real-time or another 
practical time period. Whilst the aggregate number is the key 
variable value to monitor, efforts should be placed to track 
emissions provenance (i.e. their root sources and path).  

1.1.2 The World’s accounting track —  

This accounting track is the one traditionally associated with 
climate accounting, and described above in section 1, since it 
must consider the self-defined boundaries in the human 
civilization: countries, provinces, cities, organizations, 
individuals, etc. As such, it involves a more intricate political 
and subjective process.  

The two core accounting components distributed ledger 
should cover are: 1) Open climate pledges taken by all the 
relevant actors. This includes nationally determined 
contributions (NDCs) in the case of countries, and general 
climate pledges stated by any NSA, presented as fixed 
numbers that states an intended positive climate action (eg. 
emission reduction) in the future relative to a base year. 2)  

The process to affordably track and certify what indeed was 
and was not emitted by the respective actor. This, in 
combination with the other components, is also a strong basis 
to roll-out global mechanisms to incentivize behavior change 
(eg. through rewards and penalties).  

2. Open Climate System & 
Platform of Platforms: Solution 
overview 
We propose the Open Climate platform and system based on 6 
key pillars. These pillars constitute critical insights derived 
from a landscape research and analysis of what constitutes 
success in the blockchain and climate intersection, briefly 
presented in section 1. These insights have been translated to 
the main design guidelines and features of the system. From 
these 6 pillars, we have defined the 5 climate dimensions that 
the project’s scope encompasses, and the 4 integrated layers 
that the software development effort comprises. This section 
describes the pillars, dimensions and layers of the project. 
Figure 2 provides a graphical abstract of this outline 

2.1. Six project pillars: guidelines for success 
in the application of blockchain for global 
climate accounting 

These pillars can be understood as the underlying 
assumptions of the project based on our accumulated 
research, as well as their accompanied resulting guidelines 
that have been considered in the project’s scope and 
architecture. The pillars are therefore presented here as a set 
of pairs; the insights about what the system should have the 
capacity to do, and the resulting features that our current 
prototype development includes. These pillars are: 

1. Consensus on the physical state of the 
planet > Earth ledger  

The main insight of this pillar has already been laid out above 
in section 1.1. There needs to be a clear distinction between 
the physical planet and the political world. The need for 
consensus of the Earth’s ecosystem state and key ‘vital signs’ 
are three-fold. First, a robust and scientific consensus needs to 
dispel any post-truth or climate skepticism from the general 
public, it needs to clearly record ‘the facts.’ Second, this data 
sets the baseline for all science-based climate targets from 
state and non-state actors. It also facilitates the evaluation of 
the aggregate effect of climate actor’s collective efforts. Finally, 
an established immutable value on a distributed ledger can be 
used for smart contracts to automate certain processes that 
need to be based on physical metrics. For example, a smart 
contract can deterministically tie carbon pricing to the 
remaining planetary carbon budget relative to a 1.5oC target 
using on-chain records.  

This pillar is translated in the concept of an Earth ledger. 
Section [3.1] describes the architecture and process flow to 
operate a decentralized carbon budget accounting 
mechanism, involving global CO2 internet-connected sensors, 
multi-source oracles, integrated assessment models, and 
Earth system governance to manage uncertainty ranges. While 
we focus here on the carbon modules of the Earth ledger, this 
is but one of many modules to consider. A natural extension of 
it could include the tracking of all planetary boundaries 
(Rockstrom et al., 2009). 



 6 

2. Seamless inclusion of state and non-state 
actions > Nested accounting 

Also outlined in section 1 is the importance of the capacity of 
a global climate accounting system to combine both 
commitments, actions and politics pertaining to nation-states, 
as well as those from all NSAs. This feature needs to be 
achieved without any risk of double counting, which happens 
to be one of the main values of distributed ledger technologies. 
This integration should be designed to take advantage of 
positive feedback loops involved in a win-win dynamic 
between state and NSA. Namely, accounting the actions of 
NSAs lessens the climate burden of the national governments, 
thus fostering federal incentives to support NSAs actions and 
the capacity building to utilize the same accounting 
methodologies. With incentives and motivation, NSAs can 
mobilize the lion share of capital required in finance the 
climate transition. Conversely, if an elected government from 
a nation-state loses track of scientific facts and shows 
minimum signs of planetary stewardship, a mechanism that 
incorporates NSA accounting can enable a country to maintain 
a paris-consistent track irrespective of the federal position. A 
clear example of this dynamic is seen with the Trump 
administration of the United States of America in regard to the 
potential pullout of the Paris Agreement, which lead to the 
immediate NSA backlash in the form of the #WeAreStillIn 
coalition.  

This pillar is translated in a proposed protocol to automate 
nested accounting of climate actions. This means that, for 
example, the mitigation certificates generated and retired by a 
forest conservation project developed by a private actor 
would automatically be included in the fulfillment of climate 
commitments of the subnational actor (eg. the province or 
region in which the project or company is located), and 
subsequently the nationally determined contribution of the 
involved country. If the mitigation certificates are sold from 
the private developer to a company incorporated in a different 
jurisdiction —and are retired by the buying actor— then, 
subject to countries approval, the accounting of those actions 
would fall under the nested scopes involved in the buyer’s 
jurisdiction. A nested accounting mechanism essentially 
operates the guidelines laid forth in article 6 of the Paris 
Agreement. Section 3.2.2 describes the architecture and 
process flow of this proposed features.  

3. Linking of all climate related information 
with financial value mobilization > 5 
integrated climate domains 

One of our analysis’ main insight is that one of the most 
important values of blockchain and related technologies to 
climate accounting is the capacity to integrate multiple 
climate-related records with financial capital. Leveraging the 
financial technology aspects of blockchains and smart 

Figure 2. Open Climate solution outline: 6 pillars, 5 climate dimensions and 4 software layers 
The Open Climate project is based on these six conceptual pillars, which are both insights from extensive research and analysis on the blockchain and 
climate intersection and the translation of these insights into core platform design features. These pillars then define the 5 climate domain scopes and 
their required linked blockchain-based records (see figure 3 for a metadiagram of these domain links) as well the software stack logic (see fIgure 4 for a 
full-stack description). The cross-section of the software stack with the climate domains defines the proposed meta architecture of the project.  



 7 

contracts can automate rules for deploying financial capital 
under positive feedback loop dynamics. In other words, 
different climate accounting aspects —which includes Earth 
data records, commitments of actors, the tracking of their 
progress, the minting of certificates attesting to their tracked 
action, and the transactions associated to the trading of these 
certificates— have dynamic influences between them, and the 
collective supply chain of this climate value information must 
inform and directly drive climate finance. This allows the 
application of smart contracts and digital finance to directly 
link capital with climate value in a low-cost a frictionless way. 
This can either take the form of tax burdens or pricing 
associated to negative climate value, and capital financing and 
rewards for positive climate value creation.  

This pillar is translated in a significantly broad scope of the 
project, involving the proposed direct linking of 5 different 
climate domains. These domains are: the Climate System (the 
physical dimension), Climate Agreements and their Actors 
(the political dimension and required registries), Climate 
Assets (the certifications of actions), Climate Markets (the 
networks and rules for transacting those assets) and Climate 
Finance (the mobilization of capital to finance climate value).  
Figure 3 shows a metadiagram of this multi-domain 
integration of climate aspects that can be associated to ledger 
records. This concept supports the proposition of using a 
‘ledger of ledgers’ and smart contracts to orchestrate a 
positive system dynamic of finance and information flow. In 
fact, the metadiagram in figure 3 conveys the scope of the open 
climate project and the incorporation of pillars 1 to 3.  

4. Intuitive and accessible user interface 
covering all aspects of the system > Open 
climate portal 

Blockchain, distributed ledgers and smart contracts are 
intricate concepts for the general public. Key climate data and 
actor’s action progress and accountability are scattered in 
different platforms, making it hard for both key stakeholders 
and general public to keep track of. As such, this pillar’s main 
insight is the value of a one-stop-shop portal that can connect 
all meaningful climate accounting records and functions under 
the same user interface.  

A single portal does not necessarily go against the 
decentralized nature of the project. Front-end software 
technology through the use of APIs, block explorers and secure 
credentials, can act as portals to an underlying network with 
multiple platforms and blockchain ecosystems, and allow 
logged in users to operate climate functions (eg. accounting, 
reporting, trading) hosted in different platforms but accessed 
through the same interface. Having the capacity to do this 
reduces reporting fatigue from actors that require compliant 
processes, simplifies user experience through intuitive 
processes and provide a main function for climate 
transparency and visibility. As an example, technological 
improvements in user experience have made the preparation 
and filing of annual tax returns an accessible process for 
layman citizens in the United States (eg. with the use of the 
Turbo Tax software). 

This pillar is translated in the creation of an open source front-
end platform with special focus on intuitive user experiences 
in the whole array of climate accounting functionality. Figures 
5 and 6 shows examples of the growing number of screens 
with multiple functionalities in the project’s front-end efforts.  

5. Capacity to interoperate between legacy 
and emerging technology climate platforms > 
Platform of platforms 

As mentioned in section 1, blockchain applications in the 
climate space should not try to replace existing climate 
accounting frameworks but rather build on top of them to 
drive higher levels of efficiency. Furthermore, the distributed 
ledger technology space is characterized by a high levels of 
entrepreneurial spirit and initiatives. If these are to directly 
compete against each other with a zero-sum mindset, then the 
capacity for having a unified climate accounting system is 
reduced. In other words, the world would not benefit from 
multiple carbon ledger systems that cannot interoperate with 
one another. The planet’s atmosphere is still a single limited 
space where all free greenhouse gases reside. Therefore, an 
open climate system needs the capacity to involve both 
existing legacy climate registries, platforms and databases, 
with blockchain based environments that subsequently 
should interoperate and reconcile records between each 
other.  

This pillar is translated into the effort of generating a platform 
of platforms (or PoP). Figure 4 shows the role that this PoP has 
as a middle layer between legacy and blockchain system, 
integrating them through protocols and APIs, and 
representing the collective in the user’s interface.  

6. Open source and radical collaboration > 
Consortium initiative towards a decentralized 
autonomous system  

Last but certainly not list, the sixth pillar guiding this project 
posits that the most important innovation the project should 
focus on is not just what needs to be built, but how. This points 
to the social innovation of driving software and solution 
architecture development through a mindset of radical 
collaboration, which puts forward a paradigm of unity among 
all planetary stakeholders, rather than a mindset of 
competition, which strengthens a paradigm and illusion of 
separation. This is perhaps the most challenging aspect of the 
project since modern innovation and technological progress 
has been driven by the latter mindset and zero-sum dynamics. 

The challenge of climate change and its irreversible erosion of 
planetary resilience is perhaps the ultimate opportunity to 
mobilize our mental structures. As such, a global climate 
accounting system needs to have a strong foundation on open 
data and open source software. A shared platform and its 
constituent parts need to represent an ecosystem of digital 
public goods for the global commons. This does not negate, yet 
indeed challenges, the use of commercial business models. 
Open source protocol layers can be compatible with 
proprietary software built on top of it, but innovative business 
models need to be introduced to allow developers and 



 8 

organizations to have the financial sustainability to operate 
and maintain such a system.  

This pillar translates not only into the open source publication 
of the Open Climate platform’s software, but on the 
development of a growing network of constituent platforms 
that can use a consortium model and open innovation 
framework to govern the initial development process. Part III 
fully focuses on this aspect and pillar. Furthermore, once an 
Open Climate PoP and system achieves the technological 
readiness to operate at a global level, the project has the 
intention to be released as a decentralized and autonomous 
organization.  

Perhaps one of the most powerful inventions underpinning 
the bitcoin network, which catalyzed the blockchain 
movement, is the fact that what was created was fully 
emancipated from the hand of the creator (i.e. Satoshi 
Nakamoto). This motivates the development of truly 
decentralized systems that require innovative governance 
schemes. An Open Climate platform and system, should be 
driven by a mechanism of Earth system governance that can 
tap into collective intelligence, rather than one centrally 
managed by a powerful few.  

 
2.2 Multi-domain linking of climate 
accounting scopes 
Building on pillars 1 to 4 mentioned in the previous section, 
the scope of the project’s vision crosses through 5 domains 
whose climate accounting aspects and records need to be 
linked to allow for the design of positive system dynamics. 
These domains are: 1) The Earth system, including the 
records with scientific consensus of the Climate system’s state 
as it pertains to (at least) carbon budget tracking; 2) World 
Actors & Registries, governed by Climate Agreement and 

including the record of climate actor pledges; 3) Climate 
Action & MRV, essentially the methodologies, records and 
certifications of Climate Actions (which in this case includes 
mitigation, adaptation and emission); 4) Networked Climate 
Markets, involving the transaction of these certificated 
Climate Assets under international climate markets, and 5) 
Climate Finance, the mobilization of financial capital towards 
climate action. (see figure 3 for the project’s scope and logic).  

Such a broad integrated system pertains to a core value 
proposition that blockchain technology provides. Hosting 
multiple climate accounting mechanisms connected through 
shared protocols, allows contractual automation in the link 
between finance and climate value flow based on agreed 

physical parameter of the Earth system (eg. 1.5oC warming). 
As a basis, this can act as a self-enforcing mechanism for the 
Paris Agreement, as well as enable new Paris-consistent smart 
contracts with reward & penalty functionalities to ensure 
accountability.  

As previously outlined, while the Paris Agreement pertains 
directly to countries’ roles and responsibilities (i.e. the parties 
to the UNFCCC), it is now well understood that the most 
relevant climate action champions are in fact subnational 
actors, such as cities, and non-state actors such as private 
corporations and organizations. Furthermore, article 6 of the 
Paris Agreements introduces the incorporation of bottom-up 
climate action efforts to parties’ accounts, and the cooperation 
between parties to achieve their respective NDCs using 
international transfer of mitigation ou";"""date"",""2019-10-29T18:41:46Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.7""
""xmp:CreatorTool"",""Microsoft Word""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dc:creator"",""Sarah Beatrice SÖDING""
""language"",""en""
""dcterms:created"",""2019-10-29T18:41:46Z""
""Last-Modified"",""2019-10-29T18:41:46Z""
""dcterms:modified"",""2019-10-29T18:41:46Z""
""dc:format"",""application/pdf; version=1.7""
""xmpMM:DocumentID"",""uuid:AA1814FD-0AD5-404E-8D8F-F692C41E2309""
""Last-Save-Date"",""2019-10-29T18:41:46Z""
""pdf:docinfo:creator_tool"",""Microsoft Word""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2019-10-29T18:41:46Z""
""meta:save-date"",""2019-10-29T18:41:46Z""
""pdf:encrypted"",""false""
""xmp:CreateDate"",""2019-10-29T18:41:46Z""
""modified"",""2019-10-29T18:41:46Z""
""Content-Length"",""3435637""
""pdf:hasMarkedContent"",""true""
""Content-Type"",""application/pdf""
""xmp:ModifyDate"",""2019-10-29T18:41:46Z""
""pdf:docinfo:creator"",""Sarah Beatrice SÖDING""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Sarah Beatrice SÖDING""
""dc:language"",""en-US""
""meta:author"",""Sarah Beatrice SÖDING""
""meta:creation-date"",""2019-10-29T18:41:46Z""
""created"",""2019-10-29T18:41:46Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""23""
""Creation-Date"",""2019-10-29T18:41:46Z""
""resourceName"",""Whitepaper_OpenClimate.pdf""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""2606"",""1153"",""4718"",""4368"",""5849"",""3538"",""6288"",""3619"",""1007"",""3041"",""4"",""4321"",""3136"",""6482"",""4621"",""2013"",""6560"",""3157"",""3493"",""14"",""5733"",""5295"",""4325""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""Author"",""Sarah Beatrice SÖDING""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-10-29T18:41:46Z""
";https://scholar.google.com/scholar?start=570&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094637-1066;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;A new blind ECDSA scheme for bitcoin transaction anonymity;X Yi, KY Lam ; Proceedings of the 2019 ACM Asia Conference on …, 2019  dl.acm.org;;"… In this paper, we use the term “Bitcoin” to refer to the technology and “bitcoin” to denote the

currency unit of the cryptocurrency … discovering the relationship between bitcoin wallet addresses

and the real user identity information through the Bit- coin network and the blockchain …";Cité 8 fois;Les 4 versions;[PDF] acm.org;https://dl.acm.org/doi/pdf/10.1145/3321705.3329816?casa_token=yk7p08ZjR_sAAAAA:G86WMeeFSXaW2zf_UJqaW2U5Whvy_eDXb9Ug95CAA97TnVDT4kIIgniH_RrL9y8SttoO-hQRPgM;;;https://scholar.google.com/scholar?start=880&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094602-911;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[HTML][HTML] Public key encryption with equality test via hash proof system;M Zeng, J Chen, K Zhang, H Qian ; Theoretical Computer Science, 2019  Elsevier;;"… In this work, we further explore the construction of PKEET in the standard model while using

random oracles has been indicated to have many … schemes with the well-known existing schemes,

find that our scheme is comparable with the schemes in the random oracle model in …";Cité 3 fois;Les 2 versions;[HTML] sciencedirect.com;https://www.sciencedirect.com/science/article/pii/S0304397519303822?casa_token=9oXno2-EF0QAAAAA:fXfQjn8b5_y9R1ThdRgniJ1vv56WlUKfSxXvZVR6aXNnQY-R_damigFvUZvo9GQk4qU8E0K3;;;https://scholar.google.com/scholar?start=730&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094548-687;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;A Certificate Life-cycle Management System Based on Blockchain in 5G;Y Jiang, J Liu, L Zhong, D Li, H Xu… ; 2019 6th International …, 2019  ieeexplore.ieee.org;;"… Management System Based on Blockchain in 5G … However, most telecom operators are not ready

enough for this. We present a certificate life-cycle management system based on blockchain

PKI to solve the problem of identity authentication of base stations …";Autres articles;;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/9102709/9107643/09107793.pdf?casa_token=O5_KReU2S0YAAAAA:gV4Z_UIVHr9CV-rDD4MHujWojBQ0jXBWTAjT_4KKzyZGtrgahIL1Q2VrqzrOfK6wCRm08BIr5XU;"
		Skip to Main Content


		
			
				
				

				

			

		


		
			
				
					
						








	
		
	

	







						

						





























	
	
		
	
	
		
			

		
	

	
	
	



						





	
	
		
			
				IEEE Account

					Change Username/Password
	Update Address


			

			
				Purchase Details

					Payment Options
	Order History
	View Purchased Documents


			

			
				Profile Information

					Communications Preferences
	Profession and Education
	Technical Interests


			

			
				Need Help?

					US & Canada: +1 800 678 4333
	Worldwide:  +1 732 981 0060

					
	Contact & Support


			

		

		
			
				
					
							About IEEE Xplore
	Contact Us
	Help
	Accessibility
	Terms of Use
	Nondiscrimination Policy
	Sitemap
	Privacy & Opting Out of Cookies


						
							A not-for-profit organization, IEEE is the world's largest technical professional organization dedicated to advancing technology for the benefit of humanity.
Š Copyright 2021 IEEE - All rights reserved. Use of this web site signifies your agreement to the terms and conditions.
						

					


					

				

				
			

		

	


	
	


						
						






		
		
		
		
		
		
		
		
		
		
		
		
		
			
				
			
			
			
			
		
		
		
		
		
		

			


			

			
			


		
 		
		
			 

						
						









































	

		
		

		
		
		

		
			
		
		
		

		

		
		


		

		
		
		
		
		
		
		
		
		
		
	
	


















		
		
			
				
					
					
								
					
								
			
				
					
					
								
					
								
			
				
					
						








 



					
					
								
			
				
					
					
								
			
				
					
					
								
					
								
			
				
					
					
								
					
								
			
				
					
					
								
					
								
			
				
					
					
								
					
								
			
				
					
					
								
					
								
			
				
					
					
								
					
								
			
		
	




























		
			
					
			
					
			
					
			
				
					








					
			
					
			
					
			
					
			
					
			
					
			
					
			
		
		
	





	
	
	
	
	
	
	


	
	
	

	

















					

				

			


			
				
			
		

	";"""og:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""twitter:title"",""A Certificate Life-cycle Management System Based on Blockchain in 5G""
""twitter:card"",""summary""
""Description"",""Currently, there are a large number of certificates need to be authenticated in 5G. However, most telecom operators are not ready enough for this. We present a ""
""og:title"",""A Certificate Life-cycle Management System Based on Blockchain in 5G""
""resourceName"",""09107793.pdf""
""language"",""en""
""title"",""A Certificate Life-cycle Management System Based on Blockchain in 5G | IEEE Conference Publication | IEEE Xplore""
""og:description"",""Currently, there are a large number of certificates need to be authenticated in 5G. However, most telecom operators are not ready enough for this. We present a certificate life-cycle management system based on blockchain PKI to solve the problem of identity authentication of base stations. We give a system model based on SM2 and commitment based on SM2. In the system, the certificate authority (CA) detects the service capability of 5G RAN, generates certificates, issues to users, and stores them on the blockchain. The CA can extract certificates from the blockchain. Besides, users in the system can verify the validity of certificates on the blockchain. What is more, they can know exactly whether a certificate is a new one or not according to the certificate pointer. We implemented a prototype, and analysis shows that the blockchain PKI eradicates the problem of single point failure and slow response. Besides, it has a good security, privacy protection, and highly efficient.""
""twitter:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-UA-Compatible"",""IE=Edge""
""viewport"",""width=device-width, initial-scale=1.0""
""dc:title"",""A Certificate Life-cycle Management System Based on Blockchain in 5G | IEEE Conference Publication | IEEE Xplore""
""twitter:description"",""Currently, there are a large number of certificates need to be authenticated in 5G. However, most telecom operators are not ready enough for this. We present a certificate life-cycle management system based on blockchain PKI to solve the problem of identity authentication of base stations. We give a system model based on SM2 and commitment based on SM2. In the system, the certificate authority (CA) detects the service capability of 5G RAN, generates certificates, issues to users, and stores them on the blockchain. The CA can extract certificates from the blockchain. Besides, users in the system can verify the validity of certificates on the blockchain. What is more, they can know exactly whether a certificate is a new one or not according to the certificate pointer. We implemented a prototype, and analysis shows that the blockchain PKI eradicates the problem of single point failure and slow response. Besides, it has a good security, privacy protection, and highly efficient.""
""Content-Encoding"",""UTF-8""
""Content-Type-Hint"",""text/html; charset=utf-8""
""Content-Length"",""41373""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=500&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094581-825;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Legal Analysis of the Functioning of Smart Contracts in Digital Transfers in the Financial Markets;M Naser, MH Razavi ; Iranian Journal of Trade Studies, 2019  pajooheshnameh.itsr.ir;;"… https://www.law.ox.ac.uk/business-law-blog/blog/2018/01/crypto-securities-regulation … to Smart

Contracts, July 17, 2014, https://github.com/codius/codius/wiki/Smart-Oracles:-A-Simple … Tom W.

Bell,(2016), Copyrights, Privacy, and the Blockchain, Ohio North University Law Review …";;;null;;;;https://scholar.google.com/scholar?start=640&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094581-828;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Blockchain-based e-Vote-as-a-Service;E Bellini, P Ceravolo, E Damiani ; 2019 IEEE 12th International …, 2019  ieeexplore.ieee.org;;"… Even if a number of cloud providers such as IBM and Oracle are offering ready-to- use blockchain

installation on cloud … munication Systems Services and Applications (TSSA) [22] F. Fusco, ML

Lunesu, F. Eros Pani and A. Pinna (2018) Crypto- voting, a Blockchain based e …";Cité 11 fois;Les 3 versions;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/8798376/8814488/08814575.pdf?casa_token=SO9UXNeptRQAAAAA:_EQWUFG8QRsgZrea-W1jtq_pTLBRwEyynxYQwuDDnodCqUuT2MgZtDovvh1CM4zR9zKWOr2_p9A;"
		Skip to Main Content


		
			
				
				

				

			

		


		
			
				
					
						








	
		
	

	







						

						





























	
	
		
	
	
		
			

		
	

	
	
	



						





	
	
		
			
				IEEE Account

					Change Username/Password
	Update Address


			

			
				Purchase Details

					Payment Options
	Order History
	View Purchased Documents


			

			
				Profile Information

					Communications Preferences
	Profession and Education
	Technical Interests


			

			
				Need Help?

					US & Canada: +1 800 678 4333
	Worldwide:  +1 732 981 0060

					
	Contact & Support


			

		

		
			
				
					
							About IEEE Xplore
	Contact Us
	Help
	Accessibility
	Terms of Use
	Nondiscrimination Policy
	Sitemap
	Privacy & Opting Out of Cookies


						
							A not-for-profit organization, IEEE is the world's largest technical professional organization dedicated to advancing technology for the benefit of humanity.
Š Copyright 2021 IEEE - All rights reserved. Use of this web site signifies your agreement to the terms and conditions.
						

					


					

				

				
			

		

	


	
	


						
						






		
		
		
		
		
		
		
		
		
		
		
		
		
			
				
			
			
			
			
		
		
		
		
		
		

			


			

			
			


		
 		
		
			 

						
						









































	

		
		

		
		
		

		
			
		
		
		

		

		
		


		

		
		
		
		
		
		
		
		
		
		
	
	


















		
		
			
				
					
					
								
					
								
			
				
					
					
								
					
								
			
				
					
						








 



					
					
								
			
				
					
					
								
			
				
					
					
								
					
								
			
				
					
					
								
					
								
			
				
					
					
								
					
								
			
				
					
					
								
					
								
			
				
					
					
								
					
								
			
				
					
					
								
					
								
			
		
	




























		
			
					
			
					
			
					
			
				
					








					
			
					
			
					
			
					
			
					
			
					
			
					
			
		
		
	





	
	
	
	
	
	
	


	
	
	

	

















					

				

			


			
				
			
		

	";"""og:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""twitter:title"",""Blockchain-Based E-Vote-as-a-Service""
""twitter:card"",""summary""
""Description"",""This article aims at introducing a new configurable and multipurpose electronic voting service based on the blockchain infrastructure. The objective is to desig""
""og:title"",""Blockchain-Based E-Vote-as-a-Service""
""resourceName"",""08814575.pdf""
""language"",""en""
""title"",""Blockchain-Based E-Vote-as-a-Service | IEEE Conference Publication | IEEE Xplore""
""og:description"",""This article aims at introducing a new configurable and multipurpose electronic voting service based on the blockchain infrastructure. The objective is to design an architecture to automatically translate service configuration defined by the end user into a cloud-based deployable bundle, automating business logic definition, blockchain configuration, and cloud service provider selection. The article presents the preliminary results of the system and a SOA-based services definition implemented with smart contracts.""
""twitter:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-UA-Compatible"",""IE=Edge""
""viewport"",""width=device-width, initial-scale=1.0""
""dc:title"",""Blockchain-Based E-Vote-as-a-Service | IEEE Conference Publication | IEEE Xplore""
""twitter:description"",""This article aims at introducing a new configurable and multipurpose electronic voting service based on the blockchain infrastructure. The objective is to design an architecture to automatically translate service configuration defined by the end user into a cloud-based deployable bundle, automating business logic definition, blockchain configuration, and cloud service provider selection. The article presents the preliminary results of the system and a SOA-based services definition implemented with smart contracts.""
""Content-Encoding"",""UTF-8""
""Content-Type-Hint"",""text/html; charset=utf-8""
""Content-Length"",""39200""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=640&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094572-790;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Tecnología Blockchain y su aplicación en la Automática;C Bordons Martínez ;2019 idus.us.es;;"Page 1. Proyecto fin de Máster Máster Universitario en Ingeniería Industrial Tecnología

Blockchain y su aplicación en la Automática Autor: Carlos Bordons Martínez Tutor: Luis

Fernando Castańo Castańo Dpto … 4 Page 28. 2 żPor qué el Blockchain …";Autres articles;;[PDF] us.es;https://idus.us.es/bitstream/handle/11441/94991/TFM-1589-BORDONS%20MARTINEZ.pdf?sequence=1;"
Proyecto Fin de Carrera
IngenierĂ­a de TelecomunicaciĂłn

Formato de PublicaciĂłn de la Escuela TĂŠcnica
Superior de IngenierĂ­a

Autor: F. Javier PayĂĄn Somet

Tutor: Juan JosĂŠ Murillo Fuentes

Dep. TeorĂ­a de la SeĂąal y Comunicaciones
Escuela TĂŠcnica Superior de IngenierĂ­a

Universidad de Sevilla

Sevilla, 2013

Proyecto fin de MĂĄster
MĂĄster Universitario en IngenierĂ­a Industrial

TecnologĂ­a Blockchain y su aplicaciĂłn en la

AutomĂĄtica

Autor: Carlos Bordons MartĂ­nez

Tutor: Luis Fernando CastaĂąo CastaĂąo

Dpto. de IngenierĂ­a de Sistemas y AutomĂĄtica

Escuela TĂŠcnica Superior de IngenierĂ­a

Universidad de Sevilla

Sevilla, 2019





Proyecto fin de MĂĄster

MĂĄster Universitario en IngenierĂ­a Industrial

TecnologĂ­a Blockchain y su aplicaciĂłn en la
AutomĂĄtica

Autor:

Carlos Bordons MartĂ­nez

Tutor:

Luis Fernando CastaĂąo CastaĂąo

Dr. Ingeniero Industrial

Dpto. de IngenierĂ­a de Sistemas y AutomĂĄtica

Escuela TĂŠcnica Superior de IngenierĂ­a

Universidad de Sevilla

Sevilla, 2019





Proyecto fin de MĂĄster: TecnologĂ­a Blockchain y su aplicaciĂłn en la AutomĂĄtica

Autor: Carlos Bordons MartĂ­nez

Tutor: Luis Fernando CastaĂąo CastaĂąo

El tribunal nombrado para juzgar el trabajo arriba indicado, compuesto por los siguientes profesores:

Presidente:

Vocal/es:

Secretario:

acuerdan otorgarle la calificaciĂłn de:

El Secretario del Tribunal

Fecha:







Agradecimientos

Quisiera aprovechar estas lĂ­neas para agradecer a todas las personas que han
hecho posible la realizaciĂłn de este Trabajo Fin de MĂĄster que marca el final
de mi etapa como estudiante de la Universidad de Sevilla.

En especial me gustarĂ­a agradecer a mi familia, mis padres Carlos y Ana y
a mi hermana Marta que me han empujado a terminar a tiempo el proyecto,
a mi pareja Laura que ha sufrido junto a mi muchas horas de investigaciĂłn y
experimentos, a mis amigos y compaĂąeros que me han apoyado durante todos
estos meses y me han empujado a no distraerme y a mi tutor Fernando, sin
cuya ayuda este proyecto no habrĂ­a salido adelante en tiempo y forma, tambiĂŠn
quiero agradecer a la comunidad Blockchain de Boston que me ofrecieron la
oportunidad de conocer este nuevo mundo tecnolĂłgico.

Carlos Bordons MartĂ­nez

Sevilla, 2019

i





Resumen
Este proyecto consiste en la introducciĂłn y descripciĂłn de la tecnologĂ­a Blockchain,

su importancia y su implementaciĂłn en un sistema real.
En este caso, el sistema consistirĂĄ en un control de temperatura con dispositivos IoT

controlado por Blockchain.
La implementaciĂłn del bucle de control PI en el sistema descrito radica en el desarro-

llo y ejecuciĂłn del controlador en un Smart Contract en la Blockchain.

La primera parte del proyecto consta de una introducciĂłn a la tecnologĂ­a Blockchain, sus
principales caracterĂ­sticas, por quĂŠ es importante, quĂŠ es y cĂłmo funciona.

La segunda parte describe como aplicar esta tecnologĂ­a al campo del control automĂĄti-
co.

La tercera parte consiste en un experimento de control de temperatura implementado en
tecnologĂ­a Blockchain.

iii





Abstract
This project consists of the introduction and description of Blockchain technology, its

importance and its implementation in a real system.
In this case, the systemwill consist of a temperature control with IoT devices controlled

by Blockchain.
The implementation of the PI control loop in the described system lies in the develop-

ment and execution of the controller in a Smart Contract in the Blockchain.

The first part of the project consists of an introduction to Blockchain technology, its main
characteristics, why it is important, what it is and how it works.

The second part describes how to apply this technology to the field of automatic con-
trol.

The third part consists of a temperature control experiment implemented in Blockchain
technology.

v





Índice

1. IntroducciĂłn 1
1.1. Contexto 1

1.1.1. La importancia de la confianza 1
1.1.2. Historia de la tecnologĂ­a Blockchain 2

El primer Blockchain 2
1.1.3. El Bitcoin 3

1.2. MotivaciĂłn 4
1.3. Objetivos y alcance del proyecto 4

2. ÂżPor quĂŠ el Blockchain? 5
2.0.1. El Internet del valor 6

2.1. La verdad online, actual vs Blockchain 6
2.2. La seguridad online, actual vs Blockchain 7

2.2.1. Tipos de Redes: 7
2.2.2. InteracciĂłn con la red: 9

2.3. La confianza online, actual vs Blockchain 10
2.3.1. ÂżQuĂŠ es la confianza? 10
2.3.2. Confianza Online 10
2.3.3. Smart Contracts frente a los proveedores online 12

3. ÂżQuĂŠ es el Blockchain? 15
3.0.1. DefiniciĂłn de Blockchain 15

3.1. Estructuras de Datos: Bases de Datos y Blockchain 16
3.1.1. IntroducciĂłn a las Bases de Datos 16

Por quĂŠ utilizar una base de datos 16
QuĂŠ es una base de datos 16
Sistemas de ficheros tradicionales 16
Sistemas de base de datos relacional 17
Sistemas de GestiĂłn de Bases de Datos 17

3.1.2. Bases de Datos en la Blockchain 18
Centralizadas, descentralizadas y distribuidas 18
ÂżQuĂŠ tipo de Base de Datos es una Blockchain? 19

vii



ÍNDICE

Bases de Datos vs Blockchain 20
3.2. Problemas computacionales que soluciona una Blockchain 23

3.2.1. El problema de los generales bizantinos: El problema clĂĄsico de la
computaciĂłn distribuida 23

3.2.2. Problema del doble gasto 25
3.3. Consensus 28

3.3.1. ÂżQuĂŠ es el Consensus? 28
3.3.2. Mecanismos de consenso disponibles y en desarrollo 29

Proof-of-Work (PoW), prueba de trabajo 29
Proof-of-Stake (PoS), prueba de participaciĂłn/posesiĂłn 31
Delegated proof of stake (DPoS), prueba de participaciĂłn/posesiĂłn

delegada 31
Leader-Based Consensus (LBC), consenso basado en el lĂ­der 32
Round Robin (RR), Robin circular 32
Federated Consensus (FC) / Federated Byzantine Agreement (FBA),

Consenso Federado/ Acuerdo Bizantino Federado 32
Practical Byzantine Fault Tolerance (PBFT), tolerancia prĂĄctica al fallo

bizantino 33
Proof-of-Activity, prueba de actividad 33
Proof-of-Burn, prueba de quema/eliminaciĂłn 33
Proof-of-Capacity, prueba de capacidad/espacio 34
Proof-of-Elapsed time, prueba de tiempo transcurrido 34
Resumen de los distintos mecanismos de consenso 35

3.4. criptografĂ­a 36
3.4.1. CriptografĂ­a simĂŠtrica 37

Seguridad 37
Inconvenientes 37

3.4.2. CriptografĂ­a asimĂŠtrica 38
Cifrado de clave pĂşblica 38
Firma Digital 39
Seguridad 39
Ventajas e inconvenientes 39

3.4.3. CriptografĂ­a de Curva ElĂ­ptica (CCE) 40
ParĂĄmetros de la curva 41
Propiedades de la curva 43
Uso en CriptografĂ­a 45

3.4.4. FunciĂłn Hash 46
Propiedades 47
Seguridad 48
FunciĂłn SHA-2 y SHA-256 48

3.5. Llaves pĂşblicas y privadas, direcciones y monederos 49
3.5.1. Llaves pĂşblicas y privadas en Blockchain 49

ÂżQuĂŠ son el par de llaves pĂşblica-privada? 50
Monederos o Wallets 51

viii



ÍNDICE

ÂżCĂłmo se genera el par de llaves pĂşblica-privada y las direcciones
pĂşblicas correspondientes? 51

Claves derivadas 53
3.6. Nodos y Mineros 55

3.6.1. Nodos 55
3.6.2. Nodos completos 55

OperaciĂłn de nodos completos 55
3.6.3. Supernodos o nodos de escucha 56
3.6.4. Nodos mineros 56

Pool de minerĂ­a 56
3.6.5. Nodos livianos/ligeros o SPV 56

3.7. Transacciones, Bloques y Blockchain 57
3.7.1. Transacciones 57

Componentes 57
ÂżQuĂŠ son las transacciones en Blockchain? 57
Firmar Transacciones 60

3.7.2. Bloques 61
Estructura Bloque 61
Árboles Merkle 62

3.7.3. Blockchain 63

4. ÂżCĂłmo funciona el Blockchain? 65
4.1. Transacciones 65

4.1.1. CreaciĂłn de la TransacciĂłn y firmado 65
4.1.2. TransmisiĂłn a la red 66
4.1.3. PropagaciĂłn y verificaciĂłn 66
4.1.4. ValidaciĂłn 69

4.2. Mecanismos de Consenso principales 69
4.2.1. Proof of Work (PoW) 69

Minado 69
Problema de las ramas 71

4.2.2. Proof of Stake (PoS) 72
ÂżCĂłmo se eligen a los validadores/forjadores? 73
PoW vs PoS 74

4.2.3. Delegated Proof of Stake (DPoS) 75
Ventajas y desventajas de la DPoS 77

4.2.4. Stellar Consensus Protocol (SCP) 78
Acuerdo Bizantino Federado 78
Ventajas del Stellar Consensus Protocol 79

4.3. TecnologĂ­a Blockchain - Observaciones 80

5. Criptomonedas, Smart Contracts, Dapps e Industria 4.0 81
5.1. Blockchain 1.0: Criptomoneda 82
5.2. Blockchain 2.0: Contratos Inteligentes 82

5.2.1. ÂżQuĂŠ es un smart contract? 83

ix



ÍNDICE

5.2.2. La Blockchain de Etherum 84
Estructura 84
Etherum Virtual Machine (EVM) 85

5.2.3. Los orĂĄculos 86
5.3. Blockchain 3.0: DApps 86
5.4. Blockchain 4.0: Haciendo blockchain utilizable en la industria 4.0 88

6. Blockchain en la AutomĂĄtica 91
6.1. Control AutomĂĄtico 91

6.1.1. IntroducciĂłn 91
6.1.2. Sistemas de Control 91

Lazos de Control 92
6.1.3. Estrategias de Control P, PI y PID 93

Control Proporcional (P) 93
Control Proporcional-Integral (PI) 93
Control Proporcional-Integral-Derivativo (PID) 94

6.1.4. AutomatizaciĂłn Industrial 95
IntroducciĂłn 95
Sistemas de control distribuido 96
AutĂłmata Programable/Programmable Logic Controller (PLC) 97
SupervisiĂłn, Control y AdquisiciĂłn de Datos (SCADA) 97

6.2. Blockchain y el Control AutomĂĄtico 98
6.2.1. IntroducciĂłn 98
6.2.2. ÂżCĂłmo puede ayudar Blockchain a la AutomatizaciĂłn Industrial? 98

Nivel de campo 98
Nivel de control 99
Nivel de supervisiĂłn 101

6.2.3. Conclusiones 103

7. Control PI en Blockchain 105
7.1. Estado del Arte 105
7.2. IntroducciĂłn 106
7.3. Objetivo, soluciĂłn adoptada y elementos utilizados 110

7.3.1. Objetivo y soluciĂłn adoptada 110
7.3.2. Elementos Hardware 110
7.3.3. Elementos Software 111

7.4. DiseĂąo y montaje 113
7.4.1. Circuito de lectura del sensor de temperatura DHT22 113
7.4.2. Montaje del circuito de control de los ventiladores 114
7.4.3. Desarrollo del cĂłdigo en Arduino 116

Funciones usadas en Arduino 120
7.4.4. Desarrollo del cĂłdigo del Smart Contract 122
7.4.5. Desarrollo de una interfaz web 125

7.5. Despliegue 130
7.5.1. Despliegue del cĂłdigo Arduino 130

x



ÍNDICE

ConfiguraciĂłn del Nodo Infura 130
7.5.2. Despliegue del cĂłdigo Solidity 132
7.5.3. Despliegue del cĂłdigo HTML 135

7.6. ExperimentaciĂłn 140
7.6.1. Diagrama conexiones del proyecto 140
7.6.2. ImplementaciĂłn 140
7.6.3. Resultados 141

Control en torno a punto de funcionamiento 141
Control con setpoint de bajada 142
Control con setpoint de subida 146

7.6.4. Ventajas e inconvenientes 149

8. Conclusiones 151
8.1. LĂ­neas futuras 152

Referencias 153

xi





Índice de Figuras

2.1. ÂżPor quĂŠ el Blockchain?(Gill, 2018) 6
2.2. Tipos de redes (Rautopia, s.f.) 7
2.3. BC PĂşblica vs Privada vs HĂ­brida (PĂŠrez, 2019) 9
2.4. Multitud de intermediarios(Casals, 2016) 12
2.5. Contratos tradicionales vs Smart Contracts(W, 2018) 14

3.1. Diferencia estructuras de BD y Blockchain (Tabora, 2018) 19
3.2. Problema Generales Bizantinos (Pease, 1995) 25
3.3. Problema Doble Gasto(Alon Gal, 2018) 26
3.4. Ataque del 51%(Jimi S., 2018) 27
3.5. Directed Acyclic Graphs (Fantom Foundation, 2018) 30
3.6. Funcionamiento criptografĂ­a SimĂŠtrica (Dolores Fuentes, 2016) 38
3.7. Funcionamiento criptografĂ­a AsimĂŠtrica (Ivan, 2017) 40
3.8. Curva ElĂ­ptica (Nick Sullivan, 2013) 41
3.9. Curva ElĂ­ptica secp256k1 (Shirriff, 2014) 43
3.10. Propiedades Curva ElĂ­ptica (Nick Sullivan, 2013) 44
3.11. MultiplicaciĂłn Curva ElĂ­ptica (RSK educate, 2015) 45
3.12. Funcionamiento de funciĂłn hash (Fercufer, 2011) 47
3.13. CaracterĂ­sticas SHA-256 (RSK educate, 2015) 49
3.14. Generar una direcciĂłn pĂşblica en Bitcoin (RSK educate, 2015) 53
3.15. Monedero Determinista tipo Cadena (Nick Adams, 2017) 54
3.16. Monedero Determinista tipo Árbol (Nick Adams, 2017) 54
3.17. Componentes de una TransacciĂłn (RSK educate, 2015) 57
3.18. Ejemplo de una TransacciĂłn (RSK educate, 2015) 58
3.19. TransacciĂłn Real de Bitcoin (sheinix, 2018) 59
3.20. TransacciĂłn con Retorno (Bit2Me, s.f.[c]) 59
3.21. Firma de una TransacciĂłn (Shirriff, 2014) 60
3.22. Cabecera de un Bloque (Wander, 2013) 62
3.23. ConexiĂłn Bloques (RSK educate, 2015) 63

4.1. TransacciĂłn (RSK educate, 2015) 65
4.2. Broadcasting de una TransacciĂłn (RSK educate, 2015) 66
4.3. Alice propaga dos transacciones distintas (CuriousInventor, 2013) 67
4.4. Tipos de cadenas en Blockchain (CuriousInventor, 2013) 68

xiii



ÍNDICE DE FIGURAS

4.5. PropagaciĂłn de una TransacciĂłn (RSK educate, 2015) 69
4.6. MinerĂ­a Blockchain, bĂşsqueda del Nonce (RSK educate, 2015) 70
4.7. MinerĂ­a Blockchain, rama mĂĄs larga (CuriousInventor, 2013) 72
4.8. Diferencias PoW y PoS (Schumann, 2018) 74
4.9. EconomĂ­as de Escala (Schumann, 2018) 75
4.10. Algoritmo de Consenso DPoS (Winterfield, 2018) 77
4.11. Acuerdo Bizantino Federado (FBA) (Renders, 2018) 79

5.1. EvoluciĂłn de Blockchain (InterValue, 2018) 82
5.2. Contratos en la Blockchain (Kristen Silverberg, 2016) 84
5.3. Estructura Bitcoin vs Etherum (Hertig, 2017b) 85
5.4. Estructura DApp (blockchainhub, 2019) 88

6.1. Control Lazo Abierto (Mateo Cruz, 2019) 92
6.2. Control Lazo Cerrado (Mateo Cruz, 2019) 92
6.3. Control P (Physicsch, 2015) 93
6.4. Control PI (Physicsch, 2015) 94
6.5. Control PID (Physicsch, 2015) 95
6.6. Sistema de Control Distribuido (Recursos, 2018) 96
6.7. Estructura de supervisiĂłn con SCADA(En Wikipedia, s.f.[u]) 97
6.8. Estructura conexiĂłn nivel campo y nivel control 98
6.9. ConexiĂłn niveles campo y control mediante tecnologĂ­a Tangle (ElaboraciĂłn pro-

pia, 2019) (iota community, 2018) 99
6.10. IntegraciĂłn de PLCs con Smart Contract (ElaboraciĂłn propia, 2019)(Rosic, 2016) 100
6.11. IntegraciĂłn de SCADA con Smart Contract y Storage Blockchain (ElaboraciĂłn

propia, 2019) (Rosic, 2016) 103
6.12. IntegraciĂłn Total sin dispositivos intermediarios (ElaboraciĂłn propia, 2019) (Ro-

sic, 2016) 104

7.1. Riesgos sistema centralizado bajo ataque (ElaboraciĂłn propia, 2019) 107
7.2. SoluciĂłn Blockchain propuesta (ElaboraciĂłn propia, 2019) 109
7.3. SoluciĂłn adoptada (ElaboraciĂłn propia, 2019) 110
7.4. Diagrama y resultado para lectura sensor de temperatura 114
7.5. Diagrama y resultado para alimentaciĂłn y control de ventiladores 115
7.6. Diagrama y resultado montaje final 116
7.7. ConfiguraciĂłn y monitorizaciĂłn del nodo en Infura 132
7.8. Despliegue del Smart Contract en Ropsten 134
7.9. Despliegue del Smart Contract en Ropsten, transacciĂłn en la Blockchain 135
7.10. Funcionamiento del webserver e interfaz web 137
7.11. Funcionamiento de interfaz web y Metamask 138
7.12. Transacciones recibidas y recogidas en el Smart Contract 139
7.13. Diagrama completo de conexiones (ElaboraciĂłn propia, 2019) 140
7.14. GrĂĄfica: Control en torno a punto de funcionamiento 141
7.15. GrĂĄfica: Control con Setpoint de bajada, test 1 143
7.16. GrĂĄfica: Control con setpoint de bajada, test 2 144
7.17. GrĂĄfica: Control con setpoint de bajada, test 3 146
7.18. GrĂĄfica: Control con Setpoint de subida 147

xiv



Índice de Tablas

3.1. Principales diferencias entre BD y Blockchain (Tabora, 2018) 23
3.6. Comparativa de Mecanismos de Consenso (RSK educate, 2015) 36

7.2. Resultados: Control en torno a punto de funcionamiento 142
7.4. Resultados: Control con setpoint de bajada, test 1 143
7.6. Resultados: Control con setpoint de bajada, test 2 145
7.8. Resultados: Control con setpoint de bajada, test 3 146
7.10. Resultados: Control con setpoint de subida, test 1 148
7.12. Resultados: Control con setpoint de subida, test 2 148
7.14. Resultados: Control con setpoint de subida, test 3 149

xv





1 IntroducciĂłn

1.1 Contexto

1.1.1 La importancia de la confianza

La sociedad se encuentra actualmente viviendo la RevoluciĂłn Digital o Tercera Revo-
luciĂłn Industrial, que marcĂł el comienzo de la Era de la InformaciĂłn.(Bryant, 2011)
La llegada de Internet permite a cualquier persona o mĂĄquina estar conectado con el

resto del mundo, la privacidad y protecciĂłn de datos se han convertido en una prioridad, la
posibilidad de manejar informaciĂłn sensible se encuentra focalizada en pocos individuos
y esto abre la posibilidad de la existencia de brechas de seguridad o uso fraudulento de esa
informaciĂłn, la sociedad vive en la Era de la InformaciĂłn pero sin tener control sobre esa
informaciĂłn (Romero, 2007).

Actualmente existen una decena de empresas/entidades que manejan la mayorĂ­a del trĂĄfico
del mundo y que actúan como intermediarios de los datos, son las “Trusted Third Par-
ties” o Terceros de confianza, su cometido es gestionar los datos entre dos o más agentes,
y se deposita en ellos la confianza de que las transacciones, acuerdos o trabajos a travĂŠs de
Internet entre estos agentes se llevarĂĄn a cabo (Cantor, 2018), algunos ejemplos serĂ­an:

Facebook: Gestiona datos personales de un usuario con el resto de usuarios de la
red, con la capacidad incluso de censurarlos o usarlos para otro fin.

PayPal: Gestiona los pagos entre dos usuarios, con capacidad de bloquear o retirar
el pago en caso de conflicto.

AirBnB/Uber: Gestionan alquileres de inmuebles y servicios entre usuarios de su
red.

Bancos y compaùías de tarjetas de crÊdito:Hacen de intermediario entre las cuen-
tas bancarias de comprador y vendedor.

Todas estas plataformas crean su valor como gestores de datos donde los usuarios depo-
sitan su confianza. La tecnologĂ­a Blockchain aparece para suplir la necesidad de acudir a
terceros de confianza para realizar transacciones en Internet con plena confianza de que
se llevarĂĄn a cabo, al igual que no es necesario un notario para realizar la compra del mes
o pedir un taxi.

1



1. INTRODUCCIÓN

1.1.2 Historia de la tecnologĂ­a Blockchain

En los aĂąos 90 un grupo de personas comenzĂł a reunirse para discutir problemas de
programaciĂłn y criptografĂ­a, esas reuniones evolucionaron a travĂŠs de una lista de emails,
a discusiones sobre matemĂĄticas, informĂĄtica, privacidad, libertad, filosofĂ­a y polĂ­tica,
el grupo creció y terminaron haciéndose llamar “Cypherpunks” (imchris, 2004; PetriB,
2018).
Un Cypherpunk es cualquier activista que aboga por el uso generalizado de criptogra-

fĂ­a y tecnologĂ­as que mejoren la privacidad como ruta hacia el cambio social y polĂ­tico
(PetriB, 2018; Manne, 2011).

En 1993 apareció un movimiento siguiendo el “Cypherpunkmanifesto” cuya clave prin-
cipal era la privacidad. Basado en ese principio se desarrollaron las primeras ideas sobre
las divisas digitales (PetriB, 2018; Manne, 2011; Narayanan, 2013).
Existieron varios intentos de aplicar transacciones anĂłnimas ymejoras en la privacidad

en la red:

Adam Back (1997): Creador de “Hascash”, un mecanismo anti-spam que añade
tiempo computacional al envĂ­o de emails, lo que convierte el envĂ­o de spam en un
proceso costoso (Back, 2002).

Wei Dai (1997-1998): Publicó la propuesta de “B-Money”, un sistema anónimo de
dinero efectivo electrĂłnico distribuido, un mĂŠtodo para almacenar la informaciĂłn de
las transacciones sin ser necesaria la existencia de Third Parties (Dai, 1998).

Hal Finney (2004): Creador del “Reusable Proof of Work”, un software que solu-
ciona el problema del “doble gasto”, problema fundamental de las divisas digitales
(nakamotoinstitute, 2004).

Nick Szabo (2005): Publicó una propuesta para “Bitgold”, un intento de replicar las
propiedades econĂłmicas del oro mejorando sus propiedades de seguridad, los bene-
ficios principales eran la independencia de instituciones financieras y transacciones
entre paĂ­ses sin problemas (Moskov, 2018).

El primer Blockchain

El primer trabajo en una cadena de bloques asegurados criptogrĂĄficamente fue descrito
en 1991 por Stuart Haber y W. Scott Stornetta (Narayanan y col., 2016; Haber y Stornetta,
1990). QuerĂ­an implementar un sistema donde las marcas de tiempo de los documentos
no pudieran ser alteradas. En 1992, Bayer, Haber y Stornetta incorporaron ĂĄrboles Merkle
al diseĂąo, lo que mejorĂł su eficiencia al permitir que varios certificados de documentos se
reunieran en un solo bloque (Narayanan y col., 2016; Bayer, Haber y Stornetta, 1993).

El primer Blockchain fue conceptualizado por una persona (o grupo de personas) conocida
como Satoshi Nakamoto en 2008. Nakamoto mejorĂł el diseĂąo de una manera importante,
utilizando un mĂŠtodo similar al de Hashcash para agregar bloques a la cadena sin requerir
que estén firmados por un “Trusted Party” (Narayanan y col., 2016). El diseño fue imple-
mentado el aĂąo siguiente por Nakamoto como un componente central de la criptomoneda
bitcoin, que sirve como el registro pĂşblico para todas las transacciones en la red (Econo-
mist, 2015).

2



1.1 Contexto

1.1.3 El Bitcoin

Conceptos bĂĄsicos:

Divisas: La moneda o unidad monetaria es una unidad de cambio que facilita la
transferencia de bienes y servicios, elimina la necesidad del trueque, la adopciĂłn de
divisas puede ser global, nacional o local.

Bancos: Entidades que almacenan las divisas de los usuarios, proporcionando una
promesa de pago (extracto bancario) que da derecho a retirar esa cantidad almacena-
da, el extracto bancario refleja las transacciones de divisas del usuario con el banco.
A cambio de pequeĂąas comisiones, el banco ofrece el servicio de ponerse en con-
tacto con bancos de otros usuarios para permitir transacciones entre usuarios de
distintas entidades, el servicio consiste en actualizar los extractos bancarios de am-
bos usuarios, evitando el “doble gasto” o que un usuario utilice el mismo dinero dos
veces.

Desventajas de este sistema bancario:

1. Transferencias internacionales muy costosas.

2. Es un sistema lento, la verificaciĂłn y los servicios de transferencia pueden
tardar varios dĂ­as en completarse.

3. Las cuentas pueden ser congeladas, o su saldo parcial o totalmente confiscado.

4. Los bancos y otros procesadores de pagos como PayPal, Visa y Mastercard
pueden negarse a procesar pagos para ciertas entidades legales.

5. Es necesario tener confianza plena en las Trusted Parties (bitcoin.it, 2011b).

Reserva fraccionaria: es un sistema bancario en el cual ĂŠstos mantienen sĂłlo una
fracciĂłn del monto de los depĂłsitos de sus clientes como reserva, teniendo al mis-
mo tiempo la obligaciĂłn de retornar esos depĂłsitos en demanda, es decir, en nuevos
prĂŠstamos para sus clientes.
Este sistema estĂĄ basado en el hecho de que los depositantes no suelen reclamar
todos sus depĂłsitos al mismo tiempo, ni tampoco todos los prestamistas prestan al
mismo tiempo, ni todos los deudores pagan al mismo tiempo. Dado su funciona-
miento, el sistema expande la cantidad de dinero en circulaciĂłn (este fenĂłmeno se
denomina el multiplicador bancario).
En consecuencia, y dada la prevalencia del sistema, el agregado monetario de un
paĂ­s es generalmente mayor que la base monetaria.
Economistas, notablemente los partidarios de la escuela austriaca, argumentan que
el principal negocio de la banca de reserva fraccional es la creaciĂłn de dinero, ge-
neralmente criticando este aspecto, dado que consideran que, debido a un privilegio
injustificable otorgado por el estado a la banca, esta causa deuda e inflaciĂłn (Golin
y Delhaise, 2013; Cochran y Call, 2000; Capella, 2009).

Satoshi Nakamoto en su paper “Bitcoin: A Peer-to-Peer Electronic Cash System” (Na-
kamoto y col., 2008) crea un sistema que permite realizar transacciones globales, seguras,
rĂĄpidas y de muy bajo coste, en la que el doble doble gasto de un activo digital no es po-
sible, sin depender de terceros agentes como bancos o procesadores de pagos, se trata de

3



1. INTRODUCCIÓN

un sistema que defiende la banca de reserva 100%, donde no se puede crear dinero con el
mĂŠtodo de la reserva fraccionaria, evitando la devaluaciĂłn del activo con el tiempo.

El 3 de enero de 2009, la red de bitcoins se creĂł cuando Nakamoto generĂł el primer bloque
de la cadena, conocido como el bloque de gĂŠnesis (Genesis Block).
Incluido en la coinbase de este bloque estĂĄ el siguiente texto: ""The Times 03/Jan/2009

Chancellor on brink of second bailout for banks"" (El Times 03/Ene/2009 Canciller a
punto de segundo rescate para los bancos). Esta nota se ha interpretado como una marca de
tiempo y un comentario sobre la inestabilidad causada por la banca de reserva fraccionaria
(oroyfinanzas, 2015; Davis, 2011).

1.2 MotivaciĂłn

Durante 2018-2019 he realizado una estancia en Boston, USA, dĂłnde he tenido con-
tacto con esta tecnologĂ­a y cuando se estudia con calma y en profundidad se da uno cuenta
de las posibilidades que el Blockchain tiene para mejorar la interacciĂłn de las personas
y las mĂĄquinas con Internet, y lo necesario que van a ser sus funcionalidades con la lle-
gada del Internet de las Cosas (IoT) y del Cloud Computing en tĂŠrminos de privacidad,
seguridad y confianza.
Este conocimiento, unido a mi formaciĂłn en ingenierĂ­a automĂĄtica me ha motivado a

realizar este proyecto e intentar unir ambas disciplinas.
Actualmente el Blockchain solo se conoce por su potencial en criptodivisas, pero a lo

largo de este Trabajo de Fin de MĂĄster quiero mostrar su potencial para integrarse con las
demĂĄs tecnologĂ­as, empresas y en particular con la rama del control automĂĄtico.

1.3 Objetivos y alcance del proyecto

El principal objetivo del presente proyecto es estudiar si existe campo de mejora en
el sector del control automĂĄtico al aplicar la tecnologĂ­a Blockchain y estudiar cĂłmo esta
tecnologĂ­a novedosa puede ayudar a integrar el control automĂĄtico con Internet (descen-
tralizaciĂłn, seguridad, computaciĂłn en la nube) y mejorar ciertos detalles de la implemen-
taciĂłn actual del control automĂĄtico en la industria.

4



2 ÂżPor quĂŠ el Blockchain?

En el capĂ­tulo 1, se ha destacado la importancia que tienen la confianza y la seguridad
en nuestra sociedad, y como ambos atributos dependen en la actualidad de terceros agentes
los Trusted Third Parties. En este capĂ­tulo haremos hincapiĂŠ en como el Blockchain puede
mejorar el funcionamiento de estos agentes o incluso sustituirlos.

Las principales desventajas de las transacciones en la red son que son lentas y dependen
de intermediarios que normalmente aĂąaden un coste a las transacciones por sus servi-
cios, a cambio se aseguran de que estas transacciones sean seguras, sean verdaderas/no
fraudulentas y fiables.

El objetivo de la tecnologĂ­a Blockchain es por tanto conseguir transacciones seguras, con-
fiables y verdaderas entre los usuarios, rĂĄpidas y a bajo coste, sin necesidad de interme-
diarios con acceso y control sobre los datos de los usuarios de la red.
Con Blockchain, podemos imaginar un mundo en el que los contratos se incorporan

en el cĂłdigo digital y se almacenan en bases de datos transparentes y compartidas, donde
estĂĄn protegidos contra la eliminaciĂłn, la manipulaciĂłn y la revisiĂłn. En este mundo, ca-
da acuerdo, cada proceso, cada tarea y cada pago tendrĂ­an un registro y una firma digital
que podrĂ­an identificarse, validarse, almacenarse y compartirse. Los intermediarios como
abogados, corredores y banqueros ya no serĂ­an necesarios. Los individuos, las organiza-
ciones, las mĂĄquinas y los algoritmos transarĂ­an e interactuarĂ­an libremente entre sĂ­ con
poca fricciĂłn. Este es el inmenso potencial de blockchain (Lansiti, 2017).

5



2. ¿POR QUÉ EL BLOCKCHAIN?

Figura 2.1 ÂżPor quĂŠ el Blockchain?(Gill, 2018).

2.0.1 El Internet del valor

El ""Internet del valor"" representa un mundo donde el dinero y los activos se inter-
cambian a la misma velocidad a la que la informaciĂłn se mueve hoy. Las transacciones se
producen en tiempo real y en redes globales, resolviendo el problema de los sistemas de
pago internacionales que no son interoperables o que los activos no se pueden trasladar
entre fronteras.
El problema que tenemos hoy en el mundo es que las redes de pago, incluso cuando

son eficientes, son no interoperables. Por primera vez, existe una tecnologĂ­a que resuelve
ese problema de falta de interoperabilidad entre redes y permitirĂĄ que el valor se mueva
como informaciĂłn (RSK educate, 2015; CME Open Markets - CME Group, 2015).

2.1 La verdad online, actual vs Blockchain

Conceptos:

Ledger: Cuya traducciĂłn directa es libro mayor o libro de cuentas, pero que en
tĂŠrminos de Blockchain abarcarĂĄ un ĂĄmbito mayor como registro de transacciones
(normalmente una base de datos), los Ledgers se llevan usando desde el 3000 a.C
(En Wikipedia, s.f.[e]).

Nodo: En redes de computadoras cada una de las mĂĄquinas es un nodo, y si la red
es Internet, cada servidor constituye tambiĂŠn un nodo (En Wikipedia, s.f.[r]).

Actualmente todas las transacciones en los distintos nodos de la red quedan registradas,
ese registro es lo que se va a denominar “Ledger” para la comparación de las tecnologías.
Por tanto todas las transacciones que ocurren en la red quedan registradas en el Ledger
de cada nodo principal, si una transacciĂłn no estĂĄ en el Ledger, a efectos reales no ha
ocurrido, por tanto ese Ledger es “La verdad” de esa red.
Es muy importante definir quiĂŠn puede escribir y editar ese Ledger:

Internet y comunicaciones actuales: el Ledger es escrito por uno o varios nodos
principales, y se encuentra centralizado en un nodo o descentralizado en varios no-
dos para aumentar la seguridad y evitar que el nodo principal se convierta en un

6



2.2 La seguridad online, actual vs Blockchain

“Honeypot” para los hackers que intenten alterar “La verdad” de esa red en su be-
neficio, o robar la informaciĂłn sensible almacenada (En areatecnologia, s.f.[b]; En
areatecnologia, s.f.[a]).

Blockchain: el Ledger estĂĄ distribuido, todos los nodos de la red pueden tener
permiso para escribir si cumplen unos requisitos y la propia tecnologĂ­a impide que
se alteren registros antiguos.
Al estar completamente distribuido entre todos los nodos, en caso de alterarse el
Ledger de un nodo de manera fraudulenta, comparando con las copias del resto de
la red es fácil discernir el Ledger manipulado del Ledger “global”, que contiene las
verdaderas transacciones, serĂ­a necesario modificar el 51% de los nodos para alterar
“La verdad” de esa red, por tanto la resistencia a hackers aumenta con el aumento
del nĂşmero de nodos que conforman la red (En Wikipedia, s.f.[c]).

Figura 2.2 Tipos de redes (Rautopia, s.f.).

Me gustaría compartir la siguiente cita del libro “The Truth Machine”:
Puede que te sorprenda leer esto, pero la idea mĂĄs subversiva, controvertida y anti-

autoritaria en el mundo de las finanzas, una idea tan poderosa que todos los gobiernos
del planeta estĂĄ tratando de averiguar si la utilizan o la prohĂ­ben, el sueĂąo de los liberta-
rios más fervientes y los habitantes de la dark-web, es un “Ledger” (Vigna y Casey, 2019).

Como veremos mĂĄs adelante el resultado de la tecnologĂ­a Blockchain es un mĂŠtodo de
registro que nos lleva a una versiĂłn comĂşnmente aceptada de la verdad que es mĂĄs con-
fiable que cualquier otra verdad que hayamos visto. Estamos llamando a la cadena de blo-
ques una MĂĄquina de la Verdad, y sus aplicaciones van mucho mĂĄs allĂĄ del dinero (Vigna
y Casey, 2019).

2.2 La seguridad online, actual vs Blockchain

La seguridad online es el reto de la actual generaciĂłn de criptĂłgrafos y matemĂĄticos, es
primordial que el Ledger o las bases de datos, no sean modificados con fines fraudulentos
por terceros ajenos a la red o por suplantadores de identidad.

2.2.1 Tipos de Redes:

Internet y comunicaciones actuales: normalmente son redes privadas donde es
necesario un usuario y contraseĂąa para acceder o hĂ­bridas que permiten acceder
a parte de la red sin identificarse, Internet puede considerarse una gran red pĂşblica
con servidores pĂşblicos y/o privados (En areatecnologia, s.f.[a]).

7



2. ¿POR QUÉ EL BLOCKCHAIN?

Blockchain: existen 4 tipos de Blockchain (Preukschat, 2017):

1. Blockchains pĂşblicas: son accesibles a cualquier usuario en el mundo. Lo
Ăşnico que se necesita es un ordenador y una conexiĂłn a Internet (ej: Bitcoin,
Ethereum).

2. Blockchains privadas: no estĂĄ abierta al pĂşblico, sino que solo se puede ac-
ceder a ella por invitaciĂłn, normalmente controlado por una sola organizaciĂłn
(ej: Hyperledger).

3. Blockchains de consorcios: se dice que es semi-descentralizado. TambiĂŠn el
acceso estĂĄ autorizado, pero en lugar de que una sola organizaciĂłn lo controle,
varias compaùías pueden operar un nodo en dicha red (ej: Quorum).

4. Blockchains hĂ­bridas: Las Blockchain hĂ­bridas son una combinaciĂłn de las
pĂşblicas y privadas. En una Blockchain hĂ­brida los nodos participantes son
invitados, pero todas las transacciones son pĂşblicas. Eso quiere decir que los
nodos participan en el mantenimiento y seguridad de esta Blockchain, pero to-
das las transacciones son visibles para usuarios en todo el mundo, a diferencia
de las Blockchains privadas en la cual las transacciones son privadas tambiĂŠn
(ej: Evernym).

8



2.2 La seguridad online, actual vs Blockchain

Figura 2.3 BC PĂşblica vs Privada vs HĂ­brida (PĂŠrez, 2019).

2.2.2 InteracciĂłn con la red:

Internet y comunicaciones actuales: para interactuar con l";"""date"",""2019-11-24T23:15:46Z""
""pdf:PDFVersion"",""1.4""
""xmp:CreatorTool"",""PDFCreator Free 3.5.1""
""pdf:docinfo:title"",""TFM_CarlosBordonsMartinez_20191124""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""es""
""dc:format"",""application/pdf; version=1.4""
""pdf:docinfo:creator_tool"",""PDFCreator Free 3.5.1""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""TFM_CarlosBordonsMartinez_20191124""
""xmp:CreateDate"",""2019-11-25T00:15:46Z""
""modified"",""2019-11-24T23:15:46Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""xmp:ModifyDate"",""2019-11-25T00:15:46Z""
""pdf:docinfo:creator"",""carlo""
""meta:author"",""carlo""
""meta:creation-date"",""2019-11-24T23:15:46Z""
""created"",""2019-11-24T23:15:46Z""
""xmp:About"",""uuid:d8141cc5-116b-11ea-0000-5fae65af5a6f""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-11-24T23:15:46Z""
""resourceName"",""TFM-1589-BORDONS%20MARTINEZ.pdf""
""Author"",""carlo""
""producer"",""PDFCreator Free 3.5.1""
""pdf:docinfo:producer"",""PDFCreator Free 3.5.1""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""1"",""0"",""3"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""2"",""2"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""146"",""133"",""31"",""160"",""232"",""169"",""165"",""228"",""126"",""150"",""229"",""202"",""130"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""carlo""
""dcterms:created"",""2019-11-24T23:15:46Z""
""Last-Modified"",""2019-11-24T23:15:46Z""
""dcterms:modified"",""2019-11-24T23:15:46Z""
""title"",""TFM_CarlosBordonsMartinez_20191124""
""xmpMM:DocumentID"",""uuid:d8141cc5-116b-11ea-0000-5fae65af5a6f""
""Last-Save-Date"",""2019-11-24T23:15:46Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2019-11-24T23:15:46Z""
""meta:save-date"",""2019-11-24T23:15:46Z""
""Content-Length"",""31941025""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""carlo""
""pdf:producer"",""PDFCreator Free 3.5.1""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""184""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""527"",""0"",""291"",""0"",""306"",""0"",""0"",""696"",""0"",""666"",""0"",""645"",""0"",""905"",""1421"",""1173"",""1328"",""386"",""0"",""1512"",""2157"",""488"",""0"",""1669"",""2502"",""2408"",""1712"",""1338"",""1667"",""1972"",""962"",""536"",""2256"",""2461"",""1844"",""1885"",""80"",""1999"",""2205"",""1721"",""2249"",""1493"",""2579"",""2684"",""2870"",""1541"",""2395"",""1169"",""1641"",""463"",""2215"",""2460"",""1980"",""2611"",""2497"",""2568"",""2242"",""1182"",""1290"",""1793"",""1947"",""2525"",""1852"",""1774"",""1538"",""620"",""96"",""1341"",""2593"",""1724"",""2110"",""799"",""2580"",""2351"",""2202"",""1706"",""981"",""2413"",""2440"",""1729"",""1253"",""1246"",""1666"",""2243"",""1927"",""1220"",""1351"",""1065"",""1417"",""939"",""1054"",""1449"",""1991"",""2358"",""1617"",""2551"",""1044"",""1648"",""2383"",""1553"",""2501"",""1824"",""648"",""1625"",""1842"",""1820"",""1922"",""926"",""2238"",""2267"",""1566"",""658"",""0"",""1430"",""1463"",""1385"",""1189"",""1116"",""990"",""1582"",""1705"",""1827"",""1593"",""2420"",""2157"",""1191"",""121"",""1743"",""718"",""88"",""1116"",""79"",""1292"",""1855"",""2194"",""1173"",""481"",""86"",""533"",""1036"",""927"",""1735"",""1459"",""1588"",""1098"",""846"",""1283"",""1869"",""671"",""1107"",""1089"",""908"",""1023"",""16"",""886"",""423"",""71"",""582"",""476"",""65"",""73"",""81"",""1327"",""934"",""1032"",""634"",""287"",""1050"",""599"",""1178"",""642"",""1245"",""823"",""1764"",""489"",""1932"",""2721"",""2809"",""2530"",""2780"",""2887"",""2970"",""2840"",""435""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-11-24T23:15:46Z""
";https://scholar.google.com/scholar?start=600&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094630-1039;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[PDF][PDF] Managing mistrust in construction using DLT: A review of use-case categories for technical design decisions;JJ Hunhevicz, DM Hall ; Proc., European Conf. for Computing in …, 2019  ec3.org;;"… A consensus mechanism for a public DLT is enabled by a crypto-economic design (CED … Oracles

might offer a solution to deal with problems of wrong or ambiguous information and … 2017) started

to think about a possible technical layout for the connection of blockchain and BIM …";Cité 8 fois;Les 3 versions;[PDF] ec-3.org;https://ec-3.org/conf2019/wp-content/uploads/sites/2/2019/08/Contribution_171_final.pdf;"
DOI:10.35490/EC3.2019.171Page 100 of 490

 
 

 

2019 European Conference on Computing in Construction 
 Chania, Crete, Greece 

July 10-12, 2019 

 

MANAGING MISTRUST IN CONSTRUCTION USING DLT: A REVIEW OF USE-CASE 
CATEGORIES FOR TECHNICAL DESIGN DECISIONS 

Jens J. Hunhevicz, Daniel M. Hall 

Institute of Construction and Infrastructure Management, Chair of Innovative and Industrial Construction, 
ETH Zurich, Zurich, Switzerland 

 

 

 
 

Abstract 
Blockchain, or more general distributed ledger technology 
(DLT), is seen as an opportunity to integrate digital 
information, management, and contracts to increase trust 
and collaboration within the construction industry. 
However, little research has analyzed and confirmed this 
linkage through case-studies. There seems to be a gap 
between use-case ideas and the technical system 
implementation. This paper aims to reduce this gap 
through a review of both DLT and its applications in 
construction. It proposed six use-case categories through 
clustering of analyzed use cases and a basic framework to 
match the categories to a suitable DLT design. For that, 
the trust level of the user group was used as a proxy for the 
needed fundamental properties of the system. The 
categories and framework can lead to a more connected 
and structured thinking between technological properties 
of DLT’s and use cases in construction. 

Introduction 
Construction project teams often work in cross-functional, 
geographically distributed teams (Zolin et al. 2004) 
composed of complex and fragmented supply chains. The 
successful completion of complex projects requires the 
development of trust and mutual confidence between the 
interacting parties (Pishdad-Bozorgi and Beliveau 2016). 
This has been found to be a major challenge for large, 
complex projects that rely on the interdependent actions of 
numerous stakeholders (Zolin et al. 2004). Without a 
strong foundation of trust, it is difficult to reach consensus 
and information exchange in a meaningful manner (Hall et 
al. 2014). Mistrust leads to guarded behaviors and conflict 
within project teams and results in individuals pursuing 
and protecting their own interests instead of the benefit of 
the overall projects (Pishdad-Bozorgi and Beliveau 2016). 
Furthermore, the construction industry suffers from 
longitudinal fragmentation that occurs when project teams 
disband at the end of projects and are selected on future 
projects by competitive bidding. They are thus unlikely to 
work with the same set of partner firms on future projects. 
Consequently, team members lose tacit knowledge about 
how to work together effectively (Dubois and Gadde 
2002) and organizations are unable to build long-term 
trusting relationships across firm boundaries. It is 
therefore not surprising that project sponsors and clients 
list a primary concern to be “trust and integrity in the 
construction process” (Thomsen et al. 2009). 

Scholars and practitioners argue that digital transformation 
can help overcome challenges of mistrust and 
fragmentation in order to increase the overall productivity 
of the construction industry (Agarwal et al. 2016; Whyte 
and Hartmann 2017). Digital tools such as Building 
Information Modelling (BIM) promises potential in this 
regard. BIM allows designers and builders to design, 
visualize, and coordinate construction systems with 
greater efficiency through the use of three-dimensional 
modelling tools and processes. While helpful for 
individual firms, BIM provides significantly more value 
when it can integrate information across multiple firms 
and organizations in the supply chain (Papadonikolaki and 
Wamelink 2017). However, the use of a shared model 
requires again trust in the other project participants that 
originally created the model (Hall et al. 2014); this trust is 
often not found in BIM practice (Miettinen and Paavola 
2014; Papadonikolaki 2018). Despite its potential, the 
adoption of BIM has lagged as project teams struggle with 
trust and liability concerns associated with sharing 
information on the project (Hall and Scott 2019). It seems 
that new technologies such as BIM are important but can 
only offer a partial solution to trust and liability. 

The emergence of Distributed Ledger Technologies 
(DLT), also known as blockchain, offers an opportunity to 
increase trust and collaboration within the construction 
industry by integrating digital information with 
management and contracts. It can help making the 
construction process more efficient, transparent, and 
accountable between all involved participants (Penzes 
2018). Past research has identified and summarized 
specific use cases where DLT can be applied to 
construction (e.g. Li et al. 2018). However, DLT is an 
emerging concept. Previous reviews of DLT have 
determined lists of single use cases but have not clustered 
applications into higher-order categorizations. 
Furthermore, past reviews of use cases lack consideration 
of the fundamental design decisions made for DLT’s. 
DLT’s can be chosen with different levels of 
decentralization according to the need of the users, which 
also impacts a DLT’s ability to overcome issues of trust. 
Much existing literature in construction does not take the 
technical design of DLT’s into consideration when 
reviewing its potential use cases. 

This paper attempts to further refine the understanding of 
potential use cases for DLT in construction. To do so, we 

http://doi.org/10.35490/EC3.2019.171


Page 101 of 490

review nine papers that identify multiple potential use 
cases for DLT in construction. From these papers, we 
identify 22 use cases. These use cases are then clustered 
into six higher-order use-case categories. For each of the 
six use-case categories, we map the technical requirements 
of the DLT’s onto the design decisions. The resulting 
framework is useful for researchers and practitioners to 
identify the technical design decisions required for future 
use-case implementations of DLT in construction. 

Distributed Ledger Technology 
Bitcoin as a blockchain-based crypto-currency introduced 
by Satoshi Nakamoto (2008) emerged as a combination of 
existing technologies (e.g. distributed ledgers, public-key 
encryption, merkle tree hashing, consensus protocols) 
(Tasca and Tessone 2017). Often called a disruptive 
technology, blockchain enables application beyond the 
specific case of Bitcoin as peer-to-peer money. It is 
possible with this new kind of distributed software 
architecture to operate a trusted, unchangeable ledger. 
Parties can execute and store any kind of peer-to-peer 
transactions over the internet without the need of a trusted 
intermediary party. However, the Bitcoin blockchain is 
unlikely to meet the requirements for all usage scenarios 
(Xu et al. 2017). This is why various other 
implementations and combinations of the technology 
emerged for different requirements. Blockchain is a new 
technology and the accepted terminology is still evolving. 
In this paper, we use the term distributed ledger 
technology (DLT) as an overarching term (Hileman and 
Rauchs 2017) that can capture all potential design options. 

Application of DLT’s has been structured into three 
categories: Blockchain 1.0, 2.0, and 3.0 (Swan 2015). 
Blockchain 1.0 includes the initial use case of blockchain 
as a currency. Blockchain 2.0 refers to all applications 
using transactions combined with smart contracts for 
business related cases. Shermin (2017) points out that 
DLT’s have the potential to become the new economic 
layer on top of the internet. From a business perspective, 
DLT is likely to impact finance and accounting, sales and 
marketing, legal affairs, and raising capital (Tapscott and 
Tapscott 2016). Therefore, DLT affects the main 
institutional pillars of industries and potentially disrupts 
business models by authenticating traded goods, 
improving operational efficiency, and facilitating 
disintermediation (Nowiński and Kozma 2017). This is in 
line with the main advantages for business processes of 
DLT showed by Viryasitavat et. al. (2018), namely 
enabling trust, faster transactions, and cost reductions 
through  disintermediation. In conclusion, most literature 
agrees that DLT should not be neglected when looking at 
future business development. On top, blockchain 3.0 
includes applications beyond finance, economics and 
markets, particularly in the areas of government, health, 
science, literature, culture, and art (Swan 2015). Finally, 
London et. Al.  (2018) stated that apart from the purist or 
academic value coming from DLT’s, they can also be used 
as a banner to modernize an industry from a digitization 
and collaboration perspective. DLT is gaining traction 
around the world in different industries. The report of 

Digital Catapult (2018) and Hileman and Rauchs (2017) 
give empirical evidence for the UK and global market 
respectively.  

Technology Stack 
The goal is to identify factors influencing the DLT design 
decision by focusing on the most important aspects. 
Detailed explanations on the underlying base technologies 
for DLT’s can be found for example in Wattenhofer 
(2017). Furthermore, various scholarship (Ballandies et al. 
2018; Tasca and Tessone 2017; Xu et al. 2017) introduce 
taxonomies for DLT’s and provide detailed information on 
different components. They were used as sources for this 
section. The information was structured based on an 
adapted version of the technology stack (Shermin 2017), 
pictured in Figure 1. The internet acts as the base 
technology for information sharing. A DLT, sometimes 
also referred to as protocol layer (Hileman and Rauchs 
2017), is built on top of the internet layer with three main 
components impacting its characteristics: Ledger, P2P 
Network, and Governance. An application layer is 
possible, if code can be executed on the protocol layer. 

 
Figure 1: Technology stack (adapted from Shermin 2017) 

• Ledger:  

The ledger represents the data structure of the DLT and 
can be, as in the case of Bitcoin, a blockchain with 
sequential entries and total order (Ballandies et al. 2018). 
Another type of ledger is the directed acyclic graph 
(DAG) with a stream of individual transactions entangled 
together (e.g. IOTA, see iota.org). Various elements of a 
ledger can be defined, such as the storage capabilities or 
data encryption, which is beyond the scope of this paper. 
Most importantly, if the ledger supports turing complete 
language on the protocol layer, an application layer for 
coded relations is possible (see Figure 1). This enables the 
use of smart contracts, described the first time by Szabo 
(1996). These self-executing and unchangeable codes 
open up a large scope of applications. They allow for 
automated and self-executing conditions based on the state 
of the ledger. Many smart contracts can be combined to 
build so-called decentralized applications (DApps) or 
decentralized autonomous organizations (DAOs), also 
described in the analysis part of this paper. Furthermore, 
so-called tokens for all kind of (mostly financial) purposes 
can be introduced (see Token Alliance 2018).  

• P2P Network: 

The ledgers are distributed on different nodes in the 
network. These nodes can be either permissionless, 
meaning everyone could set up a node and write 
transactions to the ledger, or permissioned, by limiting 



Page 102 of 490

write-access to the ledger. The second distinction is 
between public, meaning everyone can read the ledger, or 
private, where only defined members can access 
transactions on the ledger. The distribution and ownership 
of nodes impacts the decentralization of the system. Public 
permissionless DLT’s naturally lead to higher 
decentralization, as everyone can set up a node, leading to 
more nodes and higher variability in interests of the 
participating users. 

• Governance: 

The governance of the DLT defines the set of rules for 
users interacting with the system. The most important 
component is the consensus mechanism, responsible for 
defining how to write, validate, and agree on entries to the 
ledger. Next to proof-of-work, which was the real 
innovation behind Bitcoin (see Nakamoto 2008), also 
other consensus mechanism have been introduced such as 
proof-of-stake (see e.g. Tasca and Tessone 2017). A 
consensus mechanism for a public DLT is enabled by a 
crypto-economic design (CED). A native coin of the DLT 
incentivizes participants to behave in the interest of the 
system. This is important to prevent attacks, but also to 
compensate miners for their expenditures in running nodes 
and adding transactions. Multiple properties of  a CED can 
be defined, influencing the DLT’s governance (see also 
Ballandies et al. 2018). A private DLT might not 
necessarily need a CED, as consensus is often based on 
permissions. This can have an impact on the cost structure 
for users when interacting with different systems. Often, 
users pay for transactions on a public DLT with 
transaction fees in its native token. In contrary, for private 
DLT’s costs for the acquisition and maintenance of the 
infrastructure are predominant, while making transactions 
involves mostly no fee. 

Fundamental Properties 
The fundamental properties of DLTs are immutability, 
non-repudiation, integrity, and transparency (Xu et al. 
2017). If the network is decentralized and protected 
through a working consensus-mechanism, the chain is 
immutable. Each transaction is added only once, which 

leads to non-repudiation of the stored data. The 
cryptographic tools support data integrity, allowing to 
verify that all the data is complete and as initially written 
into the ledger.  Public access for everyone ensures 
transparency, and equal rights allow every participant the 
same ability to access and write to the ledger. Public 
permissionless DLT’s are able to achieve the highest level 
of trust. Trust in the DLT is achieved because the 
participants rely on the fundamental properties of a DLT 
itself rather than on trusted third-parties. The more 
permissions, the less trust in the technical system can be 
accomplished. Even though integrity can also be 
maintained through cryptography, permissions have an 
impact on the other aspects of the fundamental properties. 
In private DLT’s, immutability and non-repudiation are 
often ensured through verifying nodes or permission-
based consensus algorithms, with lower decentralization 
and increased possibility to act in self-interested behavior. 
Moreover, restricting read access to the ledger decreases 
transparency. This lowered trust in the technical system 
needs to be compensated by trusting the involved parties 
or a third party. Table 1 adapted from Xu et. Al. (2017) 
summarizes this for central databases and three typical 
design decisions of DLT’s: private, public permissioned, 
and public permissionless. The fundamental properties are 
less favorable with more permissions. Having said that, in 
some use cases this high trust in the technical system might 
not be needed. A more centralized system offers a better 
performance (scalability and latency), as fewer nodes are 
involved and it does not need to continuously reach 
consensus with resource intensive algorithms. In addition, 
privacy can be of concern with public DLT’s, if data 
encryption is considered too weak of a protection or parties 
want to have the possibility to control more aspects of the 
DLT (e.g. for easier implementation of system changes). 

Opportunities for DLT in Construction 
One vision for a digitized future construction process is 
described by some scholars as a combination of DLT, 
BIM, and the Internet of Things (IoT). IoT describes an 
environment where physical objects connect with the 
digital world, having sensors and connected devices 

Table 1: Impact on DLT-related design decisions:  fundamental properties and performance, using a spectrum from low (+) to 
high (++++) (adapted from Xu et al. 2017). 

Design Decision Comment Examples1 
Impact 

Fundamental 
Properties Performance 

Fully Centralized Central databases with a single or 
alternative providers - + ++++ 

Private DLT Private DLT’s with permissions on 
both  read & write of transactions 

Hyperledger 
Fabric / Corda ++ +++ 

Public Permissioned 
DLT 

Public DLT’s (permissionless read 
access) & permissions for write-access IOTA +++ ++ 

Public 
Permissionless DLT 

Public DLT’s (permissionless read 
access) & permissionless write-access Ethereum ++++ + 

1 Examples classified by Ballandies et. al. (2018): Ethereum (www.ethereum.org), IOTA (www.iota.org), Hyperledger Fabric 
(www.hyperledger.org/projects/fabric), and Corda (www.r3.com). 

 



Page 103 of 490

allowing to monitor and sense the environment with high 
spatial and time resolution (Fleisch 2010). Ye et al. (2018) 
describe in their conference paper a so-called “cup of 
water theory.” They compare the technological 
environment with the analogy of a water glass and state 
that DLT will be the “cup wall,” which is responsible to 
hold the data produced by IoT in a transparent, secure and 
convenient environment.  The “cup-bottom” and base for 
the new technologies is BIM as the main tool to digitize 
construction project data. The combination of the three 
would link the digital models to the physical buildings, 
enabling real-time digital twins to automate procedures. 
Additional literature implicitly aligns with this viewpoint. 
Mathews et al. (2017) list the required ingredients for a 
DLT adoption in the construction sector. Main ingredients 
include BIM and IoT. Additional consultancy reports 
(Kinnaird and Geipel 2017; Penzes 2018) concur that a 
future industry state will be characterized by the “circular 
economy of BIM things.” The produced data from projects 
and IoT can be fed into a common data environment 
managed and visualized through BIM, enabling a digital 
twin over the whole life cycle of a building. Benefits of 
these digital twins exist for the planning and construction 
process as well as in the operational phase (Penzes 2018). 
Having a digital model from the very beginning in the 
project throughout the construction phase can reduce 
efforts for the operation of the facility over its lifecycle. 
As more activities become digitalized, DLT’s offer a way 
for business process optimization and automation on the 
transaction level through the use of smart contracts for 
higher efficiency and accuracy. Furthermore, DLT could 
benefit construction with higher transparency in the 
project and supply chain due to data immutability and 
traceability. 

Challenges Facing DLT in Construction 
Despite the potential benefits of DLT in construction, 
many challenges exist for its successful application and 
adoption. Apart from technical barriers of DLT, various 
challenges regarding the nature of the construction 
industry and the involved humans exist, among them lack 
of awareness, skills, as well as resistance to change (Wang 
et al. 2017). Some scholars see the coding of relations into 
smart contracts as an especially challenging area in 
construction. Mason (2017) lists construction contracts of 
all kinds and investigates if a transition to smart contracts 
would be possible. He notes that smart contracts work best 
where they are short-term or are of instantaneous effect. 
This is sometimes at odds with the complicated and long-
running nature of construction projects. He believes that 
certain aspects of the construction contract cannot be fully 
intelligent, and the best that can be achieved in the short to 
medium term is a semi-automated position with human 
involvement. He found in a survey that construction 
industry participants mostly doubt that full automation 
with smart contracts is possible (Mason and Escott 2018). 
Furthermore, Kinnaird and Geipel (2017) emphasize that 
transaction entries in the DLT do not verify the correctness 
of data itself, therefore moderators might need to be 
involved to resolve disputes related to data sources. Belle 
(2017) summarized this saying that two kind of 

transactions are difficult for smart contracts: 1) ambiguous 
situations where third party expertise is needed; and 2) 
when turning a task, negotiation, or contract terms into 
algorithms is difficult. That is why some authors (e.g. 
Kinnaird and Geipel 2017; Mathews et al. 2017) propose 
to look more into oracles, which are third party or external 
information sources that interact with a smart contract. 
This can be human interaction, data from sensors or third-
party services. Oracles might offer a solution to deal with 
problems of wrong or ambiguous information and 
implementation. These challenges has been summarized 
using three dimensions: technical, political, and social in 
Li et al. (2018). 

As DLT has developed, academics and consultants have 
theorized the potential use cases for the technology. These 
use cases are a helpful starting place to understand how 
DLT can benefit the construction industry. However, there 
is an emerging gap between the described use case ideas 
and the technical system implementation required for DLT 
(Ye et al. 2018). To solve the emerging challenges 
described above, applications of DLT in construction must 
take the appropriate DLT design options into 
consideration. Yet no literature was found investigating 
what technical design option might be best suited for 
which use case in construction. Turk and Klinc (2017) 
started to think about a possible technical layout for the 
connection of blockchain and BIM. However, the 
proposed scenarios do not distinguish between different 
DLT’s. The question remains: how does one know which 
DLT to design for a certain use case? Furthermore, how 
can these use cases be clustered into broader categories 
based on their technical requirements for DLT? 

Methodology 
To answer these two questions, this paper conducts a 
review of recent papers written about DLT use cases. 
Because literature on DLT in construction is still limited, 
both scholarship and consulting reports were considered. 
The literature review conducted by Li et al. (2018) was 
used as a starting point to identify relevant papers. We then 
refined the papers reviewed based on relevance to the 
construction industry, and limited the literature to papers 
published in 2017 or later. In total, we identify nine papers 
written about DLT use cases (see Table 2). 
Table 2: Literature for use-case analysis (S: scholarly papers, 

C: consulting reports) 

# Literature Type 
[1] (Belle 2017) S 
[2] (Heiskanen 2017) S 
[3] (Kinnaird and Geipel 2017) C 
[4] (Mason 2017) S 
[5] (Mathews et al. 2017) S 
[6] (Penzes 2018) C 
[7] (Turk and Klinc 2017) S 
[8] (Wang et al. 2017) S 
[9] (Ye et al. 2018) S 

From these nine papers, we identify 22 individual use 
cases (see Table 3). Afterwards, use-case categories were 



Page 104 of 490

identified based on the clustering of use cases regarding 
similarities in their user group and/or their higher level 
application. If no use case was left without a category, it 
implied that they were able to capture the current state of 
DLT applications in construction.  

In a second step, the categories were evaluated according 
to their technical requirements based on the characteristics 
of the respective user group. If the requirements of one 
category varied from the other categories, each category 
was needed. The assessment from both the use case and 
technical view point leads to a robust argument that the 
proposed use-case categories are eligible for a first 
assessment regarding their technical design decisions. 

In the end, we identify six use-case categories. For each 
category, we describe the overarching characteristics 
identified in the literature, as well as the specific use case 
applications. Finally, we propose a basic framework and 
analysis to identify which DLT design is best suited for 
each use-case category. 

Findings 
Six final use-case categories were identified (Table 3): 

1. Internal Automation of Administrative Processes 

According to Wang et. Al. (2017), DLT could be used for 
storage and perfect notarization of each creation, deletion, 
and updating of files across an inter-organizational system 
(Table 3, 1.1).  This can simplify and automate 
administrative processes. Wang et. Al. (2017) mentions 
the recording of quality data or resource consumption data 
as examples.  

2. Transaction Automation & Optimization Between 
Stakeholders  

This use-case category focuses on the automation of 
transactions with smart contracts between different 
stakeholders, instead of one stakeholder as in the first use 
case category. The most mentioned use case in this 
category was the automatic triggering of payments (Table 
3, 2.1), as delays for monetary transactions have been 
mentioned repeatedly as a factor causing conflicts and 
disputes (Eastman 2011). This can be generalized to 
trigger various deliverables from contracts (Table 3, 2.2). 
Once a smart contract is written, its behavior is 
unambiguous and predictable. This can be used for self-

executing contract administration (Table 3, 2.3), such as 
monitoring and updating of the contract status (Wang et al. 
2017). Smart contracts are also mentioned as a way to 
enable automated information and data sharing in projects 
(Table 3, 2.4), ensuring consistent reporting for (sub-
)contractors and owners. Combined with digital signatures 
(Table 3, 2.5), decisions can be quickly approved and 
automatically trigger subsequent action. These use cases 
are independent of the project phase and can be applied for 
procurement and supply chain activities for higher 
accuracy and efficiency. 

3. Record of Transactions, Changes, Ownership 

The focus lies here on the immutability and transparency 
a DLT can provide by timestamping value transactions 
(Table 3, 3.1). The most mentioned use case is the record 
of changes and ownership (Intellectual Property) of digital 
models and components, especially in combination with 
BIM (Table 3, 3.2). Moreover, the ownership of physical 
property can be registered on a DLT (Table 3, 3.2). One 
other often mentioned use case is the tracking of supply 
chain logistics, including procurement, transportation, and 
storage of goods (Table 3, 3.4). Penzes (2018) expanded 
this towards use cases such as the tracking of project 
progress and worked hours (Table 3, 3.5), maintenance 
and operations data of buildings (Table 3, 3.6), health & 
safety incidents (Table 3, 3.7), and machine operations 
data (Table 3, 3.8).  

4. Decentralized Applications (DApps) 

DApps enable direct user interaction with a DLT, typically 
through web user interfaces. Even though it is possible to 
create web applications for the use cases in the previous 
categories during a project, we refer with DApps in this 
category to long-term and global users. They might be 
unknown and involved in various projects simultaneously. 
Different use cases for DApps are mentioned, such as 
managing identities (ID’s) of people or organizations on a 
DLT (Table 3, 4.1) for clear and trustworthy identification 
and reputation (see e.g. civic.com as an existing DApp for 
managing ID’s). Similarly, material and product passports 
with provenance-related information (Table 3, 4.2) can be 
maintained throughout the supply chain. This can be used 
for quality assurance in global construction projects 
(Wang et al. 2017) or to enable the reuse of materials at a 
later stage of a building towards a circular economy 

Figure 2: Assessment for level of Trust (LoT) from low (+) to high (++++). 1) Are users unknown (+) or known (++++)? 2) Do 
users have opposite (+) or aligned (++++) interests? 3) Is the data used long-term (+) or short-term (++++)? 

+ ++ +++ ++++ + ++ +++ ++++ + ++ +++ ++++
1) 1) 1)
2) 2) 2)
3) 3) 3)

LoT LoT LoT

+ ++ +++ ++++ + ++ +++ ++++ + ++ +++ ++++
1) 1) 1)
2) 2) 2)
3) 3) 3)

LoT LoT LoT

1. Internal Automation of Administrative Processes 2. Transaction Automation & Optimization 3. Record of Transactions, Changes, Ownership

4. Decentralized Applications (DApps) 5. Decentralized Autonomous Organizations (DAOs) 6. Coins/Tokens as Payment or Incentive Scheme



Page 105 of 490

(Kinnaird and Geipel 2017). Also, certification of products 
and buildings can profit from the availability of this trusted 
data. Decentralized marketplaces (Table 3, 4.3) can be set 
up based on the ID’s for objective data of the best-
qualified person or company in tendering, without the 
need to disclose sensitive data to third parties (Belle 2017). 
Lastly, decentralized common data environments (CDE) 
as a combination of cloud storage and DLT (see e.g. 
sia.tech or storj.io) are proposed to store digital models 
without the need to trust a third party server provider or 
run private servers vulnerable to attacks (Ye et al. 2018).  

5. Decentralized Autonomous Organizations (DAOs) 

DAOs represent a fully autonomous organization based on 
smart contracts, only running on a DLT without any 
human involvement. Governance rules are coded in smart 
contracts and incentive mechanisms are implied through 
crypto-economic design (CED). Even though fully 
automated construction companies seem futuristic, three 
sources (Belle 2017; Penzes 2018; Ye et al. 2018) 
mentioned automated building maintenance systems as 
one possibility for a DAO (Table 3, 5.1). The idea is that 
building performance can be monitored through sensors 
(IoT) in combination with BIM, enabling an automatized 

reaction to certain conditions based on predefined rules. 
This can include automatic ordering of spare parts or 
regulating technical installations. 

6. Coins/Tokens as Payment or Incentive Scheme 

This last use-case category includes all financial and 
incentive related use cases based on DLT’s. An obvious 
use case is the payment in cryptocurrencies (Table 3, 6.1), 
which allows to send money across boarders instantly and 
with small fees. Shared risk and reward structures with 
shared bank accounts and insurances could be further 
application (Table 3, 6.2). Finally, Mathews et al. (2017) 
propose the use of an #AECoin as a token to reward project 
contributors for the value of an artefact over its full life 
cycle. This should create superior value for the project, as 
contributors are incentivized to work better in order to earn 
from the value creation after the project handover to the 
client.  

Framework for Technical Design Decisions 
Having identified the categories based on use-case 
clustering (Table 3), we analyze them regarding their 
technical requirements. As seen in Table 1, Xu et al. 
(2017) structures different DLT design options according 

Table 3: Use-Case clustering into six categories, based on the literature listed in Table 2. 

Use-Case Category 
Literature 

[1] [2] [3] [4] [5] [6] [7] [8] [9] 
1 Internal Automation of Administrative Processes          
1.1 Notarization of Documents        X  
2 Transaction Automation & Optimization Between 

Stakeholders (Procurement & Supply Chain)          

2.1 Smart Contracts to Trigger Payments   X X  X  X X 
2.2 Triggering Contract Deliverables   X X  X    
2.3 Self-executing Contract Administration      X  X  
2.4 Automated Data/Information Sharing   X   X   X 
2.5 Approval of Work Packages with Digital Signatures   X   X    
3 Record of Transactions, Changes, Ownership          
3.1 Timestamping of “Value” Transactions  X   X     
3.2 Record of Changes and Ownership in BIM (IP-Rights) X  X X  X X  X 
3.3 Record of Physical Ownership (e.g. Property)   X X  X   X 
3.4 Tracking of Supply Chain Logistics  X X   X  X X 
3.5 Tracking of Project Progress and Worked Hours      X    
3.6 Record of Maintenance and Operations Data      X    
3.7 Tracking of Health & Safety Incidents      X    
3.8 Record of Machine Operation Data      X    
4 Decentralized Applications (DApps)          
4.1 Digital Identities for Reputation (People, Contractors) X  X   X    
4.2 Product Passports (Material & Product Provenance)   X   X    
4.2 Decentralized Market Places   X     X  
4.4 Decentralized Common Data Environments (CDE)   X      X 
5 Decentralized Autonomous Organizations (DAOs)          
5.1 Automated Building Maintenance Systems X     X   X 
6 Coins/Tokens as Payment or Incentive Scheme          
6.1 Payments in Cryptocurrencies        X X 
6.2 Shared Accounts & Insurances (Multi Party Risk)    X      
6.3 Token as Incentive over Whole Building-Lifecycle     X     
 



Page 106 of 490
";"""date"",""2019-08-19T20:34:08Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.3""
""pdf:docinfo:title"",""Microsoft Word - 171_A4_EC3_Word_Camera_Ready.docx""
""xmp:CreatorTool"",""Word""
""Keywords"",""""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""dcterms:created"",""2019-07-04T06:18:26Z""
""language"",""en""
""Last-Modified"",""2019-08-19T20:34:08Z""
""dcterms:modified"",""2019-08-19T20:34:08Z""
""dc:format"",""application/pdf; version=1.3""
""title"",""Microsoft Word - 171_A4_EC3_Word_Camera_Ready.docx""
""Last-Save-Date"",""2019-08-19T20:34:08Z""
""pdf:docinfo:creator_tool"",""Word""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2019-08-19T20:34:08Z""
""meta:save-date"",""2019-08-19T20:34:08Z""
""pdf:encrypted"",""false""
""dc:title"",""Microsoft Word - 171_A4_EC3_Word_Camera_Ready.docx""
""modified"",""2019-08-19T20:34:08Z""
""Content-Length"",""587475""
""pdf:hasMarkedContent"",""false""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""dc:subject"",""""
""meta:creation-date"",""2019-07-04T06:18:26Z""
""created"",""2019-07-04T06:18:26Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""10""
""Creation-Date"",""2019-07-04T06:18:26Z""
""resourceName"",""Contribution_171_final.pdf""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""5364"",""5801"",""5209"",""6084"",""5198"",""4205"",""4996"",""5268"",""4513"",""606""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""meta:keyword"",""""
""producer"",""macOS Version 10.14.5 (Build 18F132) Quartz PDFContext; modified using iTextSharp™ 5.5.12 ©2000-2017 iText Group NV (AGPL-version)""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""macOS Version 10.14.5 (Build 18F132) Quartz PDFContext; modified using iTextSharp™ 5.5.12 ©2000-2017 iText Group NV (AGPL-version)""
""pdf:docinfo:created"",""2019-07-04T06:18:26Z""
";https://scholar.google.com/scholar?start=850&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094537-631;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Use of blockchain technology and a distributed file system for building decentralized applications;MW Sieczkowski ;2019 repo.pw.edu.pl;;"… levels: from a comparison of client-server and Peer-to-Peer architectures, to a broad description

of tools used in DApps development, ie IPFS distributed file system and Ethereum blockchain …

It consists of a decentralized application and an oracle service supplying it with data …";Les 2 versions;En cache;null;;;;https://scholar.google.com/scholar?start=450&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094644-1094;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[PDF][PDF] Forward-Secure Multi-Signatures.;M Drijvers, G Neven ; IACR Cryptol. ePrint Arch., 2019  pdfs.semanticscholar.org;;"… Break in. The experiment records the break-in time Żt? t and hands the current signing key

skŻt to the adversary. This oracle can only be queried once, and after it has been queried, the

adversary can make no further queries to the key update or signing oracles …";Cité 3 fois;Les 2 versions;[PDF] semanticscholar.org;https://pdfs.semanticscholar.org/fda4/9869346fd1ddbb56959892b8dec46964af4c.pdf;"
    
    Skip to search formSkip to main content>



Semantic Scholar's Logo
Search




Sign InCreate Free Account


You are currently offline. Some features of the site may not work correctly.


Corpus ID: 75137537Forward-Secure Multi-Signatures
@article{Drijvers2019ForwardSecureM,
  title={Forward-Secure Multi-Signatures},
  author={Manu Drijvers and G. Neven},
  journal={IACR Cryptol. ePrint Arch.},
  year={2019},
  volume={2019},
  pages={261}
}
	Manu Drijvers, G. Neven
	Published 2019
	Computer Science
	IACR Cryptol. ePrint Arch.

Multi-signatures allow a group of signers to jointly sign a message in a compact and efficiently verifiable signature, ideally independent of the number of signers in the group. We present the first provably secure forward-secure multi-signature scheme by deriving a forwardsecure signature scheme from the hierarchical identity-based encryption of Boneh, Boyen, and Goh (Eurocrypt 2005) and showing how the signatures in that scheme can be securely composed. Multi-signatures in our scheme contain… Expand

View Paper
eprint.iacr.org



Save to Library
Create Alert
Cite
Launch Research Feed





Share This Paper

2 Citations
View All









Topics from this paper


	Antivirus software
	Type signature
	Provable security


	Digital signature
	ID-based encryption
	Computation


	Formal verification
	Eurocrypt






2 Citations



Citation Type
Citation Type

	All Types
	Cites Results
	Cites Methods
	Cites Background






Has PDF
Publication Type


Author


More Filters
More Filters
Filters

Sort by Relevance
Sort by Most Influenced Papers
Sort by Citation Count
Sort by Recency






Efficient Forward-Secure Threshold Signatures
	R. Kurek
	Computer Science
	IWSEC
	2020


Save
Alert
Research Feed




Dynamic large branching hash tree based secure and efficient dynamic auditing protocol for cloud environment
	R. Mishra, D. Ramesh, D. Edla
	Computer Science
	2020


Save
Alert
Research Feed








References


SHOWING 1-10 OF 41 REFERENCES
SORT BYRelevance
Most Influenced Papers
Recency




Identity-Based Multi-signatures from RSA
	M. Bellare, G. Neven
	Computer Science, Mathematics
	CT-RSA
	2007

	81

	PDF




Save
Alert
Research Feed




Forward-Secure Signatures with Optimal Signing and Verifying
	G. Itkis, Leonid Reyzin
	Mathematics, Computer Science
	CRYPTO
	2001

	261

	PDF




Save
Alert
Research Feed




Multisignatures as Secure as the Diffie-Hellman Problem in the Plain Public-Key Model
	Duc-Phong Le, A. Bonnecaze, A. Gabillon
	Mathematics, Computer Science
	Pairing
	2009

	19

	PDF




Save
Alert
Research Feed




A Forward-Secure Digital Signature Scheme
	M. Bellare, S. More
	Computer Science, Mathematics
	CRYPTO
	1999

	597

	PDF




Save
Alert
Research Feed




On the Security of Two-Round Multi-Signatures
	Manu Drijvers, Kasra Edalatnejad, +4 authors Igors Stepanovs
	Computer Science
	2019 IEEE Symposium on Security and Privacy (SP)
	2019

	26

	PDF




Save
Alert
Research Feed




Simple forward-secure signatures from any signature scheme
	H. Krawczyk
	Computer Science
	IACR Cryptol. ePrint Arch.
	2001

	182



Save
Alert
Research Feed




Forward-Secure Multi-signatures
	N. R. Sunitha, B. B. Amberker
	Computer Science
	ICDCIT
	2008

	7



Save
Alert
Research Feed




Sequential Aggregate Signatures and Multisignatures Without Random Oracles
	Steve Lu, R. Ostrovsky, A. Sahai, H. Shacham, B. Waters
	Computer Science, Mathematics
	EUROCRYPT
	2006

	295

	PDF




Save
Alert
Research Feed




Efficient discrete logarithm based multi-signature scheme in the plain public key model
	Changshe Ma, J. Weng, Yingjiu Li, R. Deng
	Mathematics, Computer Science
	Des. Codes Cryptogr.
	2010

	30



Save
Alert
Research Feed




A New Forward-Secure Digital Signature Scheme
	Michel Abdalla, Leonid Reyzin
	Computer Science
	ASIACRYPT
	2000

	257

	PDF




Save
Alert
Research Feed







...

1

2

3

4

5

...








Related Papers

















	Abstract
	Topics
	2 Citations
	41 References
	Related Papers







Stay Connected With Semantic Scholar
Sign Up

About Semantic Scholar
Semantic Scholar is a free, AI-powered research tool for scientific literature, based at the Allen Institute for AI.
Learn More →

Resources
DatasetsSupp.aiAPIOpen Corpus
Organization
About UsResearchPublishing PartnersData Partners
 
FAQContact



Proudly built by AI2 with the help of our Collaborators
Terms of Service•Privacy Policy

The Allen Institute for AI


By clicking accept or continuing to use the site, you agree to the terms outlined in our Privacy Policy, Terms of Service, and Dataset License
ACCEPT & CONTINUE




    
    
  
    
    

    
    
    






    
    
  ";"""citation_publication_date"",""2019""
""og:image"",""https://www.semanticscholar.org/img/semantic_scholar_og.png""
""citation_title"",""Forward-Secure Multi-Signatures""
""og:image:width"",""1110""
""twitter:card"",""summary_large_image""
""msapplication-square70x70logo"",""https://cdn.semanticscholar.org/86e6c2539915adc9/img/mstile-70x70.png""
""citation_journal_title"",""undefined""
""description"",""Multi-signatures allow a group of signers to jointly sign a message in a compact and efficiently verifiable signature, ideally independent of the number of signers in the group. We present the first provably secure forward-secure multi-signature scheme by deriving a forwardsecure signature scheme from the hierarchical identity-based encryption of Boneh, Boyen, and Goh (Eurocrypt 2005) and showing how the signatures in that scheme can be securely composed. Multi-signatures in our scheme contain just two group elements (one from each of the base groups) and require one exponentation and three pairing computations to verify.""
""msapplication-wide310x150logo"",""https://cdn.semanticscholar.org/86e6c2539915adc9/img/mstile-310x150.png""
""language"",""en""
""title"",""[PDF] Forward-Secure Multi-Signatures | Semantic Scholar""
""og:description"",""Multi-signatures allow a group of signers to jointly sign a message in a compact and efficiently verifiable signature, ideally independent of the number of signers in the group. We present the first provably secure forward-secure multi-signature scheme by deriving a forwardsecure signature scheme from the hierarchical identity-based encryption of Boneh, Boyen, and Goh (Eurocrypt 2005) and showing how the signatures in that scheme can be securely composed. Multi-signatures in our scheme contain just two group elements (one from each of the base groups) and require one exponentation and three pairing computations to verify.""
""og:image:secure_url"",""https://www.semanticscholar.org/img/semantic_scholar_og.png"",""https://www.semanticscholar.org/img/semantic_scholar_og.png""
""twitter:image"",""https://www.semanticscholar.org/img/semantic_scholar_og.png"",""https://www.semanticscholar.org/img/semantic_scholar_og.png""
""twitter:site"",""@allenai_org""
""msapplication-square310x310logo"",""https://cdn.semanticscholar.org/86e6c2539915adc9/img/mstile-310x310.png""
""dc:title"",""[PDF] Forward-Secure Multi-Signatures | Semantic Scholar""
""Content-Encoding"",""UTF-8""
""citation_pdf_url"",""https://eprint.iacr.org/2019/261""
""robots"",""noarchive,noindex""
""Content-Type"",""text/html; charset=UTF-8""
""s2-ui-version"",""2cfb8f55a25a62a824f97b333bd41eb95e1e3822""
""application-name"","" ""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""twitter:title"",""[PDF] Forward-Secure Multi-Signatures | Semantic Scholar""
""og:type"",""website""
""og:title"",""[PDF] Forward-Secure Multi-Signatures | Semantic Scholar""
""citation_author"",""Manu Drijvers"",""G. Neven""
""og:image:height"",""582""
""resourceName"",""9869346fd1ddbb56959892b8dec46964af4c.pdf""
""msapplication-square150x150logo"",""https://cdn.semanticscholar.org/86e6c2539915adc9/img/mstile-150x150.png""
""msapplication-TileColor"",""#FFFFFF""
""viewport"",""width=device-width,initial-scale=1""
""twitter:description"",""Multi-signatures allow a group of signers to jointly sign a message in a compact and efficiently verifiable signature, ideally independent of the number of signers in the group. We present the first provably secure forward-secure multi-signature scheme by deriving a forwardsecure signature scheme from the hierarchical identity-based encryption of Boneh, Boyen, and Goh (Eurocrypt 2005) and showing how the signatures in that scheme can be securely composed. Multi-signatures in our scheme contain just two group elements (one from each of the base groups) and require one exponentation and three pairing computations to verify.""
""og:locale"",""en_US"",""en_US""
""Content-Language"",""en""
""msapplication-TileImage"",""https://cdn.semanticscholar.org/86e6c2539915adc9/img/mstile-144x144.png""
";https://scholar.google.com/scholar?start=910&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094590-867;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Cryptanalysis of a Compact Anonymous HIBE with Constant Size Private Keys;XJ Lin, L Sun, H Qu, HQ Xian ; The Computer Journal, 2019  academic.oup.com;United Kingdom;"… To reduce the workload of a single private key generator (PKG), Gentry and Silverberg proposed

the first construction of hierarchical IBE (HIBE) [11] in the random oracle model … Boneh and Boyen

[2] presented an efficient HIBE without random oracles. In [3], Boneh et al …";Autres articles;;[PDF] oup.com;https://academic.oup.com/comjnl/article-pdf/62/8/1087/29162291/bxy130.pdf?casa_token=-2ogQxEjJBIAAAAA:sPje2_CazwAMaGom6WMmq69j0jXk4dtWnXMcqSv-TN1d2MZuhBceuv4DPpyPCTBCva753LYaeDU;"
    
        
            
        

            Skip to Main Content

    








    
        
    
    
        
    
    
        
    

        Advertisement


 
    


    


    
        
            
                
                    [image: Oxford University Press]
                
            


            	
                    
                        Search Menu
                    
                
	
                        
                            Account Menu
                        
                
	
                    
                        Menu
                    
                
	
                        
Sign In                            
                        
                        
                            

                        

                
	Register



            
                

            

        

    

    

        
        
            
                    
                        
                            Navbar Search Filter
                            This issue
All  The Computer Journal
All  BCS Journals
All  Journals







                            Mobile Microsite Search Term
                            

                            Search

                        

                    
            

        

        
        
            	
                    
                        
Sign In                        
                    
                    	
                            

                        


                
	
                        Register
                    


        

        
        


    
    	
                Issues
                
            
	
                More Content
                    
    	
                Advance Articles
                
            
	
                Special Issues
                
            



            
	
                Submit
                    
    	
                Author Guidelines
                
            
	
                Submission Site
                
            
	
                Open Access
                
            
	
                Reviewer Guidelines
                
            
	
                Guidelines for Editors
                
            
	
                Review and Appeals Process
                
            



            
	
                Purchase
                
            
	
                Alerts
                
            
	
                About
                    
    	
                About The Computer Journal
                
            
	
                About the BCS, The Chartered Institute for IT
                
            
	
                Editorial Board
                
            
	
                Advertising and Corporate Services
                
            
	
                Journals Career Network
                
            
	
                Self-Archiving Policy
                
            
	
                Dispatch Dates
                
            



            


        


    


    
        
                            
                    [image: The Computer Journal]
                

            
                    
                            
                                [image: BCS, The Chartered Institute for IT]
                            
                                            
            
 
        

    

    
        
            


    
    	
                Issues
                
            
	
                More Content
                    
    	
                Advance Articles
                
            
	
                Special Issues
                
            



            
	
                Submit
                    
    	
                Author Guidelines
                
            
	
                Submission Site
                
            
	
                Open Access
                
            
	
                Reviewer Guidelines
                
            
	
                Guidelines for Editors
                
            
	
                Review and Appeals Process
                
            



            
	
                Purchase
                
            
	
                Alerts
                
            
	
                About
                    
    	
                About The Computer Journal
                
            
	
                About the BCS, The Chartered Institute for IT
                
            
	
                Editorial Board
                
            
	
                Advertising and Corporate Services
                
            
	
                Journals Career Network
                
            
	
                Self-Archiving Policy
                
            
	
                Dispatch Dates
                
            



            


            
                
                    Close
                        
                            
                                search filter
                                This issue
All  The Computer Journal
All  BCS Journals
All  Journals



                                search input
                                

                                Search

                            

                        
                    Advanced Search

                
                Search Menu

        

    



    
    
    
    
    
    
        
        
        
        
        
        
        
        
        
    
    
 
    




    
            
                
                    Skip Nav Destination
                    




    
        Article Navigation
    

    
        
            Close mobile search navigation
        
        Article Navigation

        
    
        


    
    
            [image: Issue Cover]
    

    
        

            
                        Volume 62

                        Issue 8


            

        

        
August 2019        

        
    



 
    


            
    
        

Article Contents

	
            

                Abstract
            

        
	
            

                1. INTRODUCTION
            

        
	
            

                2. PRELIMINARIES
            

        
	
            

                3. ZHANG ET AL.’S ANONYMOUS HIBE
            

        
	
            

                4. CRYPTANALYSIS
            

        
	
            

                5. CONCLUSION
            

        
	
            

                FUNDING
            

        
	
            

                References
            

        


 
    


            

    
        	 
	
            Next >
        

 
    


        

    






    
        
            
                Article Navigation
            
        

    

    
    
        

    

    
        
                        



    
                
                    Cryptanalysis of a Compact Anonymous HIBE with Constant Size Private Keys
                

                
                    
                                






                                    Xi-Jun Lin, 

                                    

    
        
    Xi-Jun Lin
            



    


    
        Department of Computer Science and Technology, Ocean University of China, Qingdao, PR China
State Key Laboratory of Integrated Services Networks, Xidian University, Xi’an, PR China

    


    
        Corresponding author: linxj77@163.com
    

    
        Search for other works by this author on:
    



    Oxford Academic



    
        Google Scholar
    


                                    
                                
                                






                                    Lin Sun, 

                                    

    
        
    Lin Sun



    


    
        College of Liberal Arts, Qingdao University. Qingdao, PR China

    


    
        Search for other works by this author on:
    



    Oxford Academic



    
        Google Scholar
    


                                    
                                
                                






                                    Haipeng Qu, 

                                    

    
        
    Haipeng Qu



    


    
        Department of Computer Science and Technology, Ocean University of China, Qingdao, PR China

    


    
        Search for other works by this author on:
    



    Oxford Academic



    
        Google Scholar
    


                                    
                                
                                






                                    He-Qun Xian

                                    

    
        
    He-Qun Xian



    


    
        State Key Laboratory of Integrated Services Networks, Xidian University, Xi’an, PR China
College of Computer Science and Technology, Qingdao University, Qingdao, China

    


    
        Search for other works by this author on:
    



    Oxford Academic



    
        Google Scholar
    


                                    
                                

                    

                



        
            The Computer Journal, Volume 62, Issue 8, August 2019, Pages 1087–1091, https://doi.org/10.1093/comjnl/bxy130

        

        
            
                Published:

                20 December 2018

            

                
                    Article history
                
        

            
                
                    Received:

                    07 February 2018

                

                
                    Revision received:

                    04 November 2018

                

                
                    Accepted:

                    22 November 2018

                

                
                    Published:

                    20 December 2018

                

        



    






 
    

    
         
    



        
            
                
                    	
                            
                                
                                
                                    Views

                                    
                                

                            
                            


                                
	
                                    Article contents
                                
	
                                    Figures & tables
                                
	
                                    Video
                                
	
                                    Audio
                                
	
                                    Supplementary Data
                                


                        
                        	
    
        Cite


    Cite

        
            Xi-Jun Lin, Lin Sun, Haipeng Qu, He-Qun Xian,  Cryptanalysis of a Compact Anonymous HIBE with Constant Size Private Keys, The Computer Journal, Volume 62, Issue 8, August 2019, Pages 1087–1091, https://doi.org/10.1093/comjnl/bxy130

        


    
        
            
            
            Select Format
            Select format
.ris (Mendeley, Papers, Zotero)
.enw (EndNote)
.bibtex (BibTex)
.txt (Medlars, RefWorks)


            Download citation
        

    


    Close


 
    


                        
	
    
            
        
            
                Permissions Icon
            
            Permissions
        
    

 
    


                        
	
                            
                                
                                
                                    Share

                                    
                                

                            
                            


                                
	Email
	Twitter
	Facebook
	More


                        
                    
                    
    
        


    

        
        
            
                    
                        
                            Navbar Search Filter
                            This issue
All  The Computer Journal
All  BCS Journals
All  Journals







                            Mobile Microsite Search Term
                            

                            Search

                        

                    
            

        

        
        
            	
                    
                        
Sign In                        
                    
                    	
                            

                        


                
	
                        Register
                    


        

        
        

        


    



    
        
            

            
                
                    Close
                        
                            
                                search filter
                                This issue
All  The Computer Journal
All  BCS Journals
All  Journals



                                search input
                                

                                Search

                            

                        
                    Advanced Search

                
                Search Menu

        

    



 
    


                    

                

            

            
    
        
    





                    Abstract

Recently, Zhang et al. proposed a new anonymous hierarchical identity-based encryption (anonymous HIBE) over prime order groups to achieve both constant size private key and constant size ciphertext. Moreover, a double exponent technique was used to provide anonymity. They proved that their scheme is secure and anonymous against chosen plaintext attacks in the standard model. In this paper, we point out that their scheme is insecure.
                        

        



        


        
Š The British Computer Society 2018. All rights reserved. For permissions, please e-mail: journals.permissions@oup.com
This article is published and distributed under the terms of the Oxford University Press, Standard Journals Publication Model (https://academic.oup.com/journals/pages/open_access/funder_policies/chorus/standard_publication_model)



        

    




 
    

    
        
    
                
                    Issue Section:

                        Original Article
                        Section D: Security in Computer Systems and Networks
                


    



 
    

    
        
        
            

                    
                            Handling Editor:


                        

                            Chris Mitchell
                            

    
        
    Chris Mitchell



            
            Handling Editor
            

    



    
        Search for other works by this author on:
    



    Oxford Academic



    
        Google Scholar
    



                            

                        
                        

                    

            

        

 
    

    
        
 
    


                    
                        You do not currently have access to this article.
                    

                

                
                    Download all slides
                

                    
         
    


                
    
        

 
    

    
         
    


                

            

        


            
                


    Sign in

        
            
                Don't already have an Oxford Academic account? Register
            

        

    
            
    
            

        
            
                

            

        


        
            
                You could not be signed in. Please check your email address / username and password and try again.
            

        


        
            Oxford Academic account

            
                
                    Email address / Username
                    ?
                
                
            


            
                Password
                
            


            
                Sign In
                
                    Forgot password?
                

                
                    Don't have an account?
                

            


        



        
            HPC
        


        
        
    

    
        Email address / username
Most users should sign in with their email address. If you originally registered with a username please use that to sign in.

        Close
    

    

 
    


            

                    
                    

                    

                                    
                        Sign in via your Institution

                        Sign in

                    

            

    





    
            
        Purchase

        Subscription prices and ordering

            
                Short-term Access


                    
                        
                            To purchase short term access, please sign in to your Oxford Academic account above.
                        

                        
                            Don't already have an Oxford Academic account? Register
                        

                    


                Cryptanalysis of a Compact Anonymous HIBE with Constant Size Private Keys - 24 Hours access
                
                        
                            EUR €12.00
                        

                        
                            GBP ÂŁ10.00
                        

                        
                            USD $14.00
                        

                

                
            


    


    
        Rental

        
            
                [image: Read this now at DeepDyve]
            

            
                This article is also available for rental through DeepDyve.
            

        

    

 
    


                


            

    




    
        
    
    
        
    

        Advertisement


 
    

 

    

 

    

    
        



        

            

                
                        
                            188
                            Views
                        


                    
                        
0                        
                        Citations
                    

                    
                            
    
            
    

         
 
    


                            



                        

                    


                    
                        View Metrics
                    

            

                
                    
                        ×
                    

                

        

 
    

    
        
    
        Email alerts

                
                    Article activity alert
                

                
                    Advance article alerts
                

                
                    New issue alert
                

                    
                Receive exclusive offers and updates from Oxford Academic
            

        
            

            
                
            
        

    

 
    

    
         
    

    
            Related articles in

    
        	
                    Google Scholar
                


    

 
    

    
        
    Citing articles via

    
                    
                Google Scholar
            

                    
                Crossref
            

    


 
    

    
            	
                
                    Latest
                

            
	
                
                    Most Read
                

            
	
                
                    Most Cited
                

            


        






    




            
                    


    

    



        
Fog-assisted Energy Efficient Cyber Physical System for Panic-based Evacuation during Disasters    





        
            
        






    

    



        
Continuous Leakage-Amplified Public-Key Encryption With CCA Security    





        
            
        






    

    



        
Deep Multi-Stage Approach For Emotional Body Gesture Recognition In Job Interview    





        
            
        






    

    



        
A New Code-Based Blind Signature Scheme    





        
            
        






    

    



        
Differentially Private Publication For Correlated Non-Numerical Data    





        
            
        





                    

            





        
        
        
        
        
 
    


    




    



    
        
    
    
        
    

        Advertisement


 
    













                

            
    


        
        


        
            


    
            
    
        
    
    
        
    

        Advertisement


 
    


    



    



    	
    About The Computer Journal

	
    Editorial Board

	
    Author Guidelines

	
    About BCS

	
    Facebook


	
    Twitter

	
    Purchase

	
    Recommend to your Library

	
    Advertising and Corporate Services

	
    Journals Career Network







        
            

    [image: Council of European Professional Informatics Societies]
                        


        
            	Online ISSN 1460-2067
	Print ISSN 0010-4620
	Copyright Š 2021 British Computer Society


        



    


 
    


    
        
    
        


	
    About Us
    
	
    Contact Us
    
	
    Careers
    
	
    Help
    
	
    Access & Purchase
	
    Rights & Permissions
    
	
    Open Access
    





Connect

	
    Join Our Mailing List
    
	
    OUPblog
    
	
    Twitter
    
	
    Facebook
    
	
    YouTube
    
	
    Tumblr
    





Resources

	Authors
	Librarians
	Societies
	Sponsors & Advertisers
	Press & Media
	Agents





Explore

	Shop OUP Academic
	Oxford Dictionaries
	Epigeum
	OUP Worldwide
	University of Oxford





Oxford University Press is a department of the University of Oxford. It furthers the University's objective of excellence in research, scholarship, and education by publishing worldwide

[image: Oxford University Press]






	Copyright Š 2021 Oxford University Press
	Cookie Policy
	Privacy Policy
	Legal Notice
	Site Map
	Accessibility







    
    
     
    


        

    

    

    


        








    



    
        
    

    Close




    
        This Feature Is Available To Subscribers Only

        Sign In or Create an Account

    

    Close




    This PDF is available to Subscribers Only

    View Article Abstract & Purchase Options
    
        For full access to this pdf, sign in to an existing account, or purchase an annual subscription.

    

    Close


 
    


    







    
    


    
    
    

    
    

    



    

    
    




    


    
        
        
            [image: Scholarly IQ]
        



    

    
         
    


    



";"""msapplication-config"",""//oup.silverchair-cdn.com/UI/app/img/v-637520497125602725/browserconfig.xml""
""og:image"",""https://oup.silverchair-cdn.com/oup/backfile/Content_public/Journal/comjnl/Issue/62/8/1/m_cover.png?Expires=1682502913&Signature=3PnVaIEyYp3Gs1vA-BhgFqo3bJyL0npCdAOoV2N4ycOSlkDQEECF0-Snduhfy8fxWhO~d98Bklxccpgt~zSGuwwdcpBV3GxJ-Nz0iPSj55mxJkYPex-pYfzy~ebk9VRxFVkF8NuYfGs5u2nry-oj4WMv0dM9zm5Byo~-M~eZdXa2eyfGbZG7sf6sr2gZ5kBP8Yrh7neLb1LEwO0KWyRQT0z9n4crDYs-Q2x~pSdOpXZiLN0DCIR82J9tWKjneLzvyjiVqKwMQHOPsJOIi4vWSZ-bx9-A8kIUPzT2t729XsMsNQf2GOXbIed2BFc3f2lCSMljbcOk9RokmFHOeQEQQw__&Key-Pair-Id=APKAIE5G5CRDK6RD3PGA""
""citation_publication_date"",""2019/08/09""
""theme-color"",""#002f65""
""citation_author_institution"",""Department of Computer Science and Technology, Ocean University of China, Qingdao, PR China"",""State Key Laboratory of Integrated Services Networks, Xidian University, Xi’an, PR China"",""College of Liberal Arts, Qingdao University. Qingdao, PR China"",""Department of Computer Science and Technology, Ocean University of China, Qingdao, PR China"",""State Key Laboratory of Integrated Services Networks, Xidian University, Xi’an, PR China"",""College of Computer Science and Technology, Qingdao University, Qingdao, China""
""citation_title"",""Cryptanalysis of a Compact Anonymous HIBE with Constant Size Private Keys""
""og:site_name"",""OUP Academic""
""citation_reference"",""Abdalla M., Bellare M. and Catalano D. ( 2005 ) Searchable Encryption Revisited: Consistency Properties, Relation to Anonymous IBE, and Extensions. Proc. Advances in Cryptology-CRYPTO 05 , Santa Barbara, CA, USA, August 14–18, Lecturer Notes in Computer Science 3621, pp. 205–222. Springer, Berlin. "",""Boneh D. and Boyen X. ( 2004 ) Efficient Selective-ID Secure Identity Based Encryption Without Random Oracles. Proc. Advances in Cryptology- EUROCRYPT 04 , Interlaken, Switzerland, May 2–6, Lecturer Notes in Computer Science 3027, pp. 223–238. Springer, Berlin. "",""Boneh D., Boyen X. and Goh E. ( 2005 ) Hierarchical Identity based Encryption with Constant Ciphertext. Proc. Advances in Cryptology-Eurocrypt 05 , Aarhus, Denmark, May 22–26, Lecturer Notes in Computer Science 3494, pp. 440–456. Springer, Berlin. "",""Boneh D., Crescenzo G., Ostrovsky R. and Persiano G. ( 2004 ) Public Key Encryption with Keyword Search. Proc. Advances in Cryptology-Eurocrypt 04 , Interlaken, Switzerland, 2–6 May, Lecturer Notes in Computer Science 3027, pp. 506–522. Springer, Berlin. "",""Boneh D. and Franklin M. ( 2001 ) Identity-based Encryption from the Weil Pairing. Proc. Crypto’01 , Santa Barbara, CA, USA, August 19–23, pp. 213–229. Springer, Berlin. "",""Boyen X. and Waters B. ( 2006 ) Anonymous Hierarchical Identity-Based Encryption (Without Random Oracles). Proc. Advances in Cryptology-CRYPTO’06 , Santa Barbara, CA, USA, August 20–24, Lecturer Notes in Computer Science 5677, pp. 290–317. Springer, Berlin. "",""Caro A., Iovino V. and Persiano G. ( 2010 ) Fully Secure Anonymous HIBE and Secret Key Anonymous IBE with Short Ciphertexts. Proc. Pairing 10 , Yamanaka Hot Spring, Ishikawa, Japan, December 13–15, Lecturer Notes in Computer Science 6487, pp. 347–366. Springer, Berlin. "",""citation_title=Improved anonymous multi-receiver identity-based encryption; citation_author=Chien  H.Y.;  citation_journal_title=Comput. J.;  citation_year=2012;  citation_volume=55;  citation_pages=439-446; "",""citation_title=Identity-based key agreement protocols from pairings; citation_author=Chen  L.; citation_author=Cheng  Z.; citation_author=Smart  N.P.;  citation_journal_title=Int. J. Inf. Secur.;  citation_year=2007;  citation_volume=6;  citation_pages=213-241; "",""citation_title=Pairings for cryptographers; citation_author=Galbraith  S.; citation_author=Paterson  K.; citation_author=Smart  N.P.;  citation_journal_title=Discrete Appl. Math.;  citation_year=2008;  citation_volume=156;  citation_pages=3113-3121; "",""Gentry C. and Silverberg A. ( 2002 ) Hierarchical ID-Based Cryptography. Proc. Advances in Cryptology-ASIACRYPT 02 , Queenstown, New Zealand, December 1–5, Lecturer Notes in Computer Science 2501, pp. 548–566. Springer, Berlin. "",""Seo J., Kobayashi T., Ohkubo M. and Suzuki K. ( 2009 ) Anonymous Hierarchical Identity Based Encryption with Constant Size Ciphertexts. Proc. PKC 09 , Irvine, CA, USA, March 18–20, Lecturer Notes in Computer Science 5443, pp. 215–234. Springer, Berlin. "",""Shamir A. ( 1984 ) Identity-Based Cryptosystem and Signature Schemes. Proc. CRYPTO 84 , CA, USA, August 19–22, pp. 47–53. Springer, Berlin. "",""Shi E. and Waters B. ( 2008 ) Delegating Capabilities in Predicate Encryption Systems. Proc. ICALP 08 , Reykjavik, Iceland, 7–11 July, Part II, Lecturer Notes in Computer Science 5126, pp. 560–578. Springer, Berlin. "",""citation_title=Efficient revocable ID-based encryption with a public channel; citation_author=Tseng  Y.M.; citation_author=Tsai  T.T.;  citation_journal_title=Comput. J.;  citation_year=2012;  citation_volume=55;  citation_pages=475-486; "",""citation_title=A fully secure revocable ID-based encryption in the standard model; citation_author=Tsai  T.T.; citation_author=Tseng  Y.M.; citation_author=Wu  T.Y.;  citation_journal_title=Informatica;  citation_year=2012;  citation_volume=23;  citation_pages=481-499; "",""Waters B. ( 2005 ) Efficient Identity-Based Encryption without Random Oracles. Proc. Eurocrypt’05 , Aarhus, Denmark, May 22–26, pp. 114–127. Springer, Berlin. "",""citation_title=A revocable ID-based authenticated group key exchange protocol with resistant to malicious participants; citation_author=Wu  T.Y.; citation_author=Tseng  Y.M.; citation_author=Tsai  T.T.;  citation_journal_title=Comput. Netw.;  citation_year=2012;  citation_volume=56;  citation_pages=2994-3006; "",""citation_title=Compact anonymous hierarchical identity-based encryption with constant size private keys; citation_author=Zhang  L.; citation_author=Mu  Y.; citation_author=Wu  Q.;  citation_journal_title=Comput. J.;  citation_year=2016;  citation_volume=59;  citation_pages=452-461; ""
""citation_publisher"",""Oxford Academic""
""citation_journal_title"",""The Computer Journal""
""description"",""Abstract. Recently, Zhang et al. proposed a new anonymous hierarchical identity-based encryption (anonymous HIBE) over prime order groups to achieve both consta""
""language"",""en""
""title"",""Cryptanalysis of a Compact Anonymous HIBE with Constant Size Private Keys | The Computer Journal | Oxford Academic""
""og:description"",""Abstract. Recently, Zhang et al. proposed a new anonymous hierarchical identity-based encryption (anonymous HIBE) over prime order groups to achieve both consta""
""citation_issn"",""0010-4620""
""dc:title"",""Cryptanalysis of a Compact Anonymous HIBE with Constant Size Private Keys | The Computer Journal | Oxford Academic""
""Content-Encoding"",""UTF-8""
""Content-Type-Hint"",""text/html; charset=utf-8""
""citation_pdf_url"",""https://academic.oup.com/comjnl/article-pdf/62/8/1087/29162291/bxy130.pdf""
""Content-Length"",""105265""
""citation_xml_url"",""https://academic.oup.com/comjnl/article-xml/62/8/1087/5253748""
""citation_lastpage"",""1091""
""Content-Type"",""text/html; charset=UTF-8""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""og:type"",""article""
""citation_journal_abbrev"",""Comput J""
""og:title"",""Cryptanalysis of a Compact Anonymous HIBE with Constant Size Private Keys""
""citation_author"",""Lin, Xi-Jun"",""Sun, Lin"",""Qu, Haipeng"",""Xian, He-Qun""
""resourceName"",""bxy130.pdf""
""og:updated_time"",""2018-12-20""
""citation_issue"",""8""
""X-UA-Compatible"",""IE=Edge""
""citation_firstpage"",""1087""
""viewport"",""width=device-width, initial-scale=1, maximum-scale=1""
""citation_doi"",""10.1093/comjnl/bxy130""
""citation_volume"",""62""
""og:url"",""https://academic.oup.com/comjnl/article/62/8/1087/5253748""
""Content-Language"",""en""
""format-detection"",""telephone=no""
";https://scholar.google.com/scholar?start=680&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094649-1119;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;1 RSA Encryption in Practice;L Reyzin ; cs.bu.edu;;"… only CPA secure, but also secure against chosen-ciphertext attacks, in a special (unrealistic)

model known as “random oracle model.” Whether … protocols based on the RSA encryption standard

PKCS #1. In Hugo Krawczyk, editor, Advances in Cryptology—CRYPTO '98, volume …";Autres articles;Version HTML;null;;;;https://scholar.google.com/scholar?start=930&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094619-985;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[LIVRE][B] Applied Cryptography and Network Security: 17th International Conference, ACNS 2019, Bogota, Colombia, June 5–7, 2019, Proceedings;RH Deng, V Gauthier;Umańa, M Ochoa, M Yung 2019 books.google.com;;"… Gasti, Giuseppe Ateniese, and Fernando Perez-Cruz Blockchain and Cryptocurrency

Uncle-Block Attack: Blockchain Mining Threat … of Cryptographic Implementations Public

Immunization Against Complete Subversion Without Random Oracles …";Les 3 versions;;null;;;;https://scholar.google.com/scholar?start=800&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094635-1060;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Scalable Scanning and Automatic Classification of {TLS} Padding Oracle Vulnerabilities;R Merget, J Somorovsky, N Aviram, C Young… ; 28th {USENIX} Security …, 2019  usenix.org;;"… Contributions. In our work, we employ a novel scan- ning methodology that is capable of

scanning for TLS CBC padding oracles at scale. We use this methodology to find new

padding oracle vulnerabilities and perform responsi- ble disclosures …";Cité 4 fois;Les 5 versions;[PDF] usenix.org;https://www.usenix.org/system/files/sec19-merget.pdf;"
This paper is included in the Proceedings of the 
28th USENIX Security Symposium.

August 14–16, 2019 • Santa Clara, CA, USA

978-1-939133-06-9

Open access to the Proceedings of the 
28th USENIX Security Symposium 

is sponsored by USENIX.

Scalable Scanning and Automatic Classification of 
TLS Padding Oracle Vulnerabilities

Robert Merget and Juraj Somorovsky, Ruhr University Bochum; Nimrod Aviram, 
Tel Aviv University; Craig Young, Tripwire VERT; Janis Fliegenschmidt and JĂśrg Schwenk, 

Ruhr University Bochum; Yuval Shavitt, Tel Aviv University

https://www.usenix.org/conference/usenixsecurity19/presentation/merget



Scalable Scanning and Automatic Classification of TLS Padding Oracle
Vulnerabilities

Robert Merget1, Juraj Somorovsky1, Nimrod Aviram2, Craig Young3, Janis Fliegenschmidt1, JĂśrg
Schwenk1, and Yuval Shavitt2

1Ruhr University Bochum
2Department of Electrical Engineering, Tel Aviv University

3Tripwire VERT

Abstract

The TLS protocol provides encryption, data integrity, and
authentication on the modern Internet. Despite the protocol’s
importance, currently-deployed TLS versions use obsolete
cryptographic algorithms which have been broken using var-
ious attacks. One prominent class of such attacks is CBC
padding oracle attacks. These attacks allow an adversary to
decrypt TLS traffic by observing different server behaviors
which depend on the validity of CBC padding.

We present the first large-scale scan for CBC padding
oracle vulnerabilities in TLS implementations on the mod-
ern Internet. Our scan revealed vulnerabilities in 1.83% of
the Alexa Top Million websites, detecting nearly 100 differ-
ent vulnerabilities. Our scanner observes subtle differences
in server behavior, such as responding with different TLS
alerts, or with different TCP header flags.

We used a novel scanning methodology consisting of three
steps. First, we created a large set of probes that detect vul-
nerabilities at a considerable scanning cost. We then reduced
the number of probes using a preliminary scan, such that a
smaller set of probes has the same detection rate but is small
enough to be used in large-scale scans. Finally, we used the
reduced set to scan at scale, and clustered our findings with
a novel approach using graph drawing algorithms.

Contrary to common wisdom, exploiting CBC padding or-
acles does not necessarily require performing precise timing
measurements. We detected vulnerabilities that can be ex-
ploited simply by observing the content of different server
responses. These vulnerabilities pose a significantly larger
threat in practice than previously assumed.

1 Introduction

In 2002, Vaudenay presented an attack which targets mes-
sages encrypted with the Cipher Block Chaining (CBC)
mode of operation [39]. The attack exploits the malleability
of the CBC mode, which allows altering the ciphertext such
that specific cleartext bits are flipped, without knowledge of

the encryption key. The attack requires a server that decrypts
a message and responds with 1 or 0 based on the message va-
lidity. This behavior essentially provides the attacker with a
cryptographic oracle which can be used to mount an adaptive
chosen-ciphertext attack. The attacker exploits this behavior
to decrypt messages by executing adaptive queries.Vaudenay
exploited a specific form of vulnerable behavior, where im-
plementations validate the CBC padding structure and re-
spond with 1 or 0 accordingly.

This class of attacks has been termed padding oracle
attacks. Different forms of padding oracle attacks were
demonstrated to break cryptographic hardware [6], XML
Encryption [23], or web technologies like Java Server
Faces [33] and ASP.NET web applications [15]. Rizzo and
Duong used a padding oracle attack to steal secrets and forge
authentication tokens, gaining access to sensitive data [15].
In all of these works, the attacker was able to use a direct side
channel – different error messages – to instantiate a padding
oracle and decrypt confidential data.

Transport Layer Security (TLS) employs CBC mode in a
MAC-then-Pad-then-Encrypt scheme which makes it poten-
tially vulnerable to these attacks. Indeed, different types of
CBC padding oracles have been used to break confidential-
ity TLS connections [39, 4, 3, 20]. All these attacks require
the attacker to perform precise timing measurements. This
requirement stems from the properties of the TLS protocol;
after establishing a TLS connection, all TLS error messages
are sent encrypted and are of the same length. Therefore,
even if an attacker is able to cause the server to send differ-
ent error messages, the attacker is generally unable to distin-
guish between the different encrypted responses.

Since most previous analyses have only analyzed padding
oracle attacks based on timing side channels, they required
testing an implementation in a local environment. These
evaluations uncovered many new vulnerabilities [4, 3, 20].
However, implementing a proper countermeasure to these
vulnerabilities is very challenging and requires complex
constant-time implementations. It is not surprising that the
implementation of such countermeasures could introduce

USENIX Association 28th USENIX Security Symposium    1029



new attacks. For example, in an attempt to fix the Lucky
13 padding oracle, the OpenSSL cryptographic library intro-
duced a different vulnerability where OpenSSL responded
with different TLS alert messages [37]. Analysis of imple-
mentations in lab settings therefore requires laborious test-
ing for each new version of different implementations. This
is obviously unrealistic, and therefore this type of analysis is
performed sporadically.

Given the complexity of constant-time TLS padding veri-
fication, we expect that vulnerabilities similar to the one in-
troduced by OpenSSL [37] could have been introduced in
other implementations as well. Therefore, this work moves
away from the above method of lab analyses and evaluates
CBC padding oracles using large-scale Internet scans. We
attempt to answer the two following questions: How preva-
lent are padding oracle vulnerabilities? Are these attacks
only exploitable by using timing side-channels?

Contributions. In our work, we employ a novel scan-
ning methodology that is capable of scanning for TLS CBC
padding oracles at scale. We use this methodology to find
new padding oracle vulnerabilities and perform responsi-
ble disclosures. We identify nearly 100 different padding
oracles. We show that some of them can be exploitable
without subtle timing side channels and thus pose a signif-
icantly larger threat in practice compared to most recently-
discovered padding oracles.

New large-scale scanning methodology. Scanning at
scale for padding oracles is challenging. Such scans detect
vulnerabilities by sending different malformed inputs and
observing server behavior. As shown by BĂśck et al. [9], in
some cases these inputs only trigger vulnerabilities when us-
ing specific TLS versions or cipher suites. Scanning with
all possible combinations of protocol versions, cipher suites
and malformed inputs is not feasible since it would require
an enormous number of connections to each scanned host.

We overcome this limitation by carefully selecting a set
of probes, which allows for effective scans at scale. We sys-
tematically analyzed padding oracles previously described in
the literature [39, 4, 3, 20, 37, 27, 25, 10, 29, 28]. We then
carefully selected 25 inputs exhibiting padding oracle mal-
formities, which we refer to as malformed records. These
TLS records exhibit different combinations of valid and in-
valid padding and MAC, and are generated using the TLS-
Attacker framework [37].

Even with only 25 malformed records, scanning with ev-
ery combination of malformed record, TLS version and ci-
pher suite would be impractical. We refer to these combi-
nations as test vectors. We performed a preliminary scan
on 50,000 random TLS hosts with all test vectors. We then
reduced our test vector set, such that all vulnerabilities de-
tected in the preliminary scan are still triggered by the re-
duced set. We were able to scan the Alexa Top 1 Million

websites with this reduced test vector set within three days.
Our scanner observes different server responses, not only in
the TLS layer, but also in the TCP layer, similar to [9]. Our
results indicate that about 1.83% of TLS servers are vulner-
able to CBC padding oracle attacks.

Minimizing false positives. When a host first displays vul-
nerable behavior, we rescan it to make sure the behavior is
not a scanning artifact. We only consider a host to be vulner-
able if it responds identically in three separate scans to each
of our test vectors. It is unlikely that hosts will be mislabeled
as vulnerable under this criterion. We therefore believe our
statistics for vulnerability are a conservative lower estimate.

Nearly 100 different padding oracle vulnerabilities. The
detected vulnerabilities have to be clustered in order to notify
different vendors. Until now, this was done manually [9].
To achieve this automatically, we re-scan vulnerable hosts
against a larger set of test vectors. We refer to the set of the
host responses to all test vectors as the host’s response map.
This response map is essentially a fingerprint of the host’s
vulnerability. We then cluster the scanned hosts according
to their response maps. This process identified 93 different
response maps, i.e., 93 different vulnerabilities. These vul-
nerabilities include different behaviors, ranging from typical
padding oracles with different TLS alert messages [39], to
TCP connection timeouts triggered by specific invalid MAC
bytes, or closed connections observed when using invalid
padding values.

We treat distinct response maps as distinct vulnerabilities.
We argue that this is the natural way to count vulnerabilities
since it captures the case of the same vulnerability occurring
in similar, yet different implementations. Consider two hosts
that respond identically to all test vectors. These hosts likely
share an identical or very similar part of the implementation
that causes the vulnerability to manifest with identical re-
sponse maps. However, they do not necessarily share the ex-
act same code. They may use different versions of the same
TLS library, or two different libraries with a shared compo-
nent.

Effective clustering of vulnerable hosts. Before we re-
sponsibly disclosed our findings to the affected parties, we
grouped the vulnerable hosts by their response maps. To fur-
ther refine our grouped servers, we used a novel approach
based on a two-dimensional force-directed graph drawing
ForceAtlas2 algorithm [21]. This algorithm allowed us to
create a graph of vulnerable server hosts and thus, efficiently
handle our responsible disclosure process.

New vulnerabilities that are realistic to exploit. For
padding vulnerabilities to be exploitable, the attacker needs

1030    28th USENIX Security Symposium USENIX Association



to distinguish between different responses to correct and in-
correct padding. This is usually not the case in TLS: Even
if a server sends two different alert messages, the messages
are encrypted, and the attacker cannot observe the difference.
For this reason, most previous padding oracle attacks against
TLS relied on timing measurements to distinguish between
different error cases [4, 3, 20].

However, we show that many TLS implementations ex-
hibit observable differences between correct and incorrect
padding. For example, a server may gracefully close the TCP
connection in one error case and ungracefully close it in a
different case. Similarly, some servers send a different num-
ber of alert messages depending on specific padding errors.
Both behaviors are easily observable.

Responsible disclosure and ethical considerations. In
collaboration with affected website owners, we responsibly
disclosed our findings to several vulnerable vendors. As a
result of a successful attack, the attacker is able to decrypt
secret values repeatedly transmitted in the TLS connection.
By performing our scans, we were not able to reconstruct
server private keys or other confidential data. We performed
our scans with dummy data and never attempted to decrypt
real user traffic.

We responsibly disclosed our findings among others to
the following vendors and affected parties: IBM, Amazon,
Slack, Cisco, Citrix, Oracle, Heroku, Netflix, Sonicwall,
Venmo and Vine.

2 Background

The TLS protocol provides confidentiality, integrity, and au-
thentication on the modern Internet. The latest version of the
protocol is TLS 1.3 [31]. This version is gradually being de-
ployed as of this writing. Until TLS 1.3 is fully deployed,
the latest version in widespread use is TLS 1.2 [14]. Modern
clients and servers typically also support two previous ver-
sions, TLS 1.0 and 1.1 [12, 13]. In the rest of the paper, we
discuss only versions 1.0 to 1.2, which are commonly used
today and share a similar structure.

The TLS protocol consists of two phases. In the first
phase, called the handshake, the client and server choose the
cryptographic algorithms that will be used for the session and
establish session keys. In the second phase, the peers can se-
curely send and receive application data, which is encrypted
and authenticated using the keys and algorithms established
in the previous phase.

The aforementioned choice of cryptographic algorithms is
called a TLS cipher suite [14]. More precisely, a cipher suite
is a concrete selection of algorithms for all of the required
cryptographic tasks. Cipher suites are named by concate-
nating their choices for these algorithms. For example, the
cipher suite TLS_RSA_WITH_AES_128_CBC_SHA uses RSA
public-key encryption in order to establish a shared session

key in the first phase, and also uses symmetric AES-CBC
encryption with a 128-bit key and SHA-1-based HMACs in
order to encrypt and authenticate data in the second phase.

2.1 The TLS Handshake
The client initiates the TLS handshake with a ClientHello
message. This message advertises the TLS versions and ci-
pher suites supported by the client. The server then responds
with a ServerHello message specifying the selected ci-
pher suite. It also sends its certificate in the Certificate
message and indicates the end of transmission with the
ServerHelloDone message. The client then generates a
secret value called the premaster secret, encrypts it un-
der the server’s RSA key, and sends the encrypted cipher-
text in a ClientKeyExchange message. Having shared
knowledge of the premaster secret, both parties now de-
rive symmetric encryption and MAC keys to be used in the
session, based on the premaster secret. Finally, both par-
ties send the ChangeCipherSpec and Finished messages.
The ChangeCipherSpec message notifies the receiving peer
that subsequent messages will be encrypted and authenti-
cated under the session keys, and using the symmetric en-
cryption and HMAC algorithms specified in the cipher suite.
The Finished message contains an HMAC computed over
all the previous handshake messages based on a key derived
from the premaster secret. As this message is sent after the
ChangeCipherSpec message, it is the first message in the
session which is encrypted and authenticated using symmet-
ric encryption and MAC. If the Finished message correctly
decrypts and verifies on both sides, both parties can now se-
curely exchange application data.

2.2 CBC Mode
There are many possible encryption algorithms in TLS, but
we focus on the CBC encryption mode in this work. In CBC
mode, each plaintext block is XOR’ed to the previous ci-
phertext block before being encrypted by the block cipher.
Formally, if we denote plaintext blocks by pi, i = 0, . . ., ci-
phertext blocks by ci and the encryption with a block cipher
under key k as Enck(·), then ci = Enck(pi⊕ ci−1), i = 1, . . ..
The above holds for all blocks except the first one, where
there is no previous ciphertext block – instead, that block is
XOR’ed with an initialization vector (IV) before encryption:
c0 = Enck(p0⊕ IV ).

CBC mode malleability. The CBC mode allows an at-
tacker to perform meaningful plaintext modifications with-
out knowing the symmetric key. Concretely, assume the at-
tacker knows some block of the original plaintext pi, and
wants to alter the ciphertext such that block i instead de-
crypts to p′i. The attacker can change the previous ciphertext
block ci−1 to c′i−1 = ci−1⊕ pi⊕ p′i. This comes at the cost of

USENIX Association 28th USENIX Security Symposium    1031



corrupting the previous block, which now decrypts to some
value that the attacker, in general, cannot predict.

Furthermore, the attacker can change the order of blocks
while using this technique. If the attacker knows the plain-
text block pi and replaces ciphertext block c j with ci, then
block j will now decrypt to p′j = pi⊕ ci−1⊕ c j−1.

This “malleability” property of CBC mode has been used
in many cryptographic attacks, and is also a cornerstone of
the attacks presented here.

2.3 TLS Record Layer
The TLS record layer encapsulates protocol messages. In
essence, the record layer wraps the protocol message with
a header containing the message length, message type, and
protocol version. Once ChangeCipherSpec messages are
exchanged, subsequent TLS records will encapsulate mes-
sages which are encrypted.

In our work, we focus on cipher suites using the CBC
mode of operation. These cipher suites use a Message Au-
thentication Code (MAC) to protect the authenticity of TLS
records and encrypt application data using a block cipher
in CBC mode (e.g., AES or 3DES). The TLS specification
prescribes the MAC-then-Pad-then-Encrypt mechanism [14].
The encryptor first computes a MAC over the plaintext, con-
catenates the MAC to the plaintext, pads the message such
that its length is a multiple of the block length, and finally
encrypts the MAC’ed and padded plaintext using a block ci-
pher in CBC mode.

TLS specifies the exact value of the padding bytes. The
last byte of the padded plaintext specifies how many padding
bytes are used, excluding that last byte. The value of the rest
of the padding bytes is identical to the value of the last byte.
For example, if 4 padding bytes are used including the last
byte, then the value of all four bytes will be 0x03.

To demonstrate the full process, if the en-
cryptor encrypts five bytes of data with the
TLS_RSA_WITH_AES_128_CBC_SHA cipher suite, he
uses HMAC-SHA (whose output is 20 bytes long) and
AES-CBC. After applying HMAC-SHA to the original
plaintext, the concatenation is 25 bytes in length, which fits
into two AES 16-byte blocks. The encryptor will typically
select the minimum viable amount of padding, which would
be 7 bytes in this case. The first block contains the data and
the first 11 HMAC bytes. The second block contains the
remaining 9 HMAC bytes and 7 bytes of padding 0x06, see
Figure 1. Note that the encryptor can also choose longer
padding and append 23, 39, ...or 247 padding bytes (while
setting the value of the padding bytes accordingly).

3 A Brief History of Padding Oracle Attacks

One of the main design failures in SSLv3 and TLS is the
specification of the MAC-then-Pad-then-Encrypt scheme in

0c 0c 0c 0c 0c 0c 0c 0c 0c 0c 0c 0c 0c

43 4441 42 45 M M M M M M M M M M M

M M M M MM M M M M 0606 06 06 06 06 06

Figure 1: When processing five plaintext bytes with AES-
CBC and HMAC-SHA, the encryptor needs to append 20
bytes of the HMAC-SHA output and seven bytes of padding.

CBC cipher suites. This scheme was responsible for a series
of attacks on TLS implementations named padding oracle at-
tacks. Even though the countermeasures are explicitly sum-
marized in the TLS specification [14, Section 6.2.3.2], their
correct implementation is challenging.1

3.1 Vaudenay’s Padding Oracles

In 2002, Vaudenay showed that the MAC-then-Pad-then-
Encrypt scheme introduces potential vulnerabilities in secu-
rity protocols, in the form of so-called padding oracles [39].
The attacks leveraging these vulnerabilities are based on the
malleability of the CBC mode of operation. We focus on the
case of TLS.

Consider the TLS record layer when using CBC mode.
After decryption, the decrypting party needs to verify the
padding bytes and the MAC bytes. The natural way to im-
plement these two checks is first to verify the padding bytes
and, if they verify correctly, then verify the MAC bytes. If
the padding bytes are invalid, it is natural for an implemen-
tation to emit an error message, without checking the MAC
bytes. On the other hand, if the padding bytes are valid but
the MAC is invalid, it is then natural to emit a (potentially
different) error message.

Assume a decryptor that indeed emits two different error
messages in these cases. The attacker can decrypt the last
byte of any message block pi as follows. He sets the last ci-
phertext block to ci and replaces the last byte of the previous
block ci−1 with a value between 0 and 255. If the last cleart-
ext byte is 0x00, then the padding will be valid (other forms
of valid padding are much less likely). When the padding
byte correctly verifies, the attacker detects this by observ-
ing that the decryptor emitted an “invalid MAC"" error, rather
than an “invalid padding"" error. The attacker learns the value
of the last byte of pi after sending at most 255 ciphertexts to
the decryptor.

Using his knowledge of the last plaintext byte, the attacker
can proceed to decrypt the second-to-last byte of pi. By do-
ing so, he aims to create valid padding of length 2. More
generally, using this technique, the attacker can iteratively
decrypt every byte in pi. We omit the formal description of
the rest of the attack and refer the reader to [39].

1We note that the countermeasures summarized in [14] do not protect
from timing-based attacks [4].

1032    28th USENIX Security Symposium USENIX Association



Note that the above attack relies on the ability to distin-
guish between ciphertexts decrypting to valid and invalid
padding. It would therefore appear trivial for TLS imple-
mentations to prevent this attack by making sure they always
emit the same error message. Indeed, Vaudenay was unaware
of a way for an attacker to directly distinguish between these
two cases in the context of TLS. The reason is that even if
the TLS error messages differ, their distinction is impossible
since they are encrypted with TLS session keys. This is one
of the challenges we address in our work.

3.2 BEAST Attack Model
One question left open in Vaudenay’s paper is how to exploit
what he terms an “exploding oracle” – an oracle that is usable
only until it first returns a negative answer. This models the
problem where a TLS implementation will abort the session
as soon as a message doesn’t decrypt correctly. Hence, an
attacker that relies on changing messages in a TLS session
would not be able to continue the attack as soon as the first
decryption error arises.

Canvel et al. used a model where the client repeatedly
connects to the server [11], observing that this occurs due to
polling behavior of email clients at the time, and exfiltrating
an authentication password. The BEAST attack [34] essen-
tially used the same model, but rather relied on the behavior
of modern web browsers. In the simplest form of the BEAST
model, a victim is tricked into visiting a malicious website
controlled by the attacker. That website contains javascript
which causes the victim browser to repeatedly connect to
the victim website. Every website request then contains the
user authentication cookie, which is automatically sent by
the browser. This behavior allows the attacker to force the
victim to repeatedly send encrypted values to the server.

Our attacks work in this model. We assume that the at-
tacker can cause the victim client to repeatedly connect to a
victim server while retransmitting the same sensitive infor-
mation. We also assume the attacker is a man in the middle
(MitM) and can change messages in transit. This model has
now become standard in literature for modern attacks.

3.3 POODLE
The predecessor to TLS, SSLv3, uses a similar MAC-then-
Pad-then-Encrypt scheme. However, unlike TLS, the value
of the padding bytes in SSLv3 is under-specified. The last
byte of the plaintext denotes how many padding bytes are
present, but the rest of the padding bytes can take any value.

Consider a message with one full block of 16 padding
bytes. The last block of plaintext will have a last byte of
0x0F, and the first 15 bytes can take any value. Therefore,
an attacker can use the techniques described in Section 3.1
to replace the last block with any block whose last byte de-
crypts to 0x0F, and obtain a validly padded message. This

property of SSLv3 led to a devastating attack called “POO-
DLE”. See [27] for a full description of the attack.

Although POODLE relies on the under-specification of
the padding bytes in SSLv3, it surprisingly also affects TLS
implementations. In essence, there is nothing forcing a care-
less TLS developer to verify the (specified) padding bytes af-
ter decryption; a TLS implementation will interoperate just
fine even if it does not check the padding bytes at all. In fact,
it is easier for the developer to reuse the same code that han-
dles SSLv3 padding in a TLS implementation. This has led
to a variant of the POODLE attack that affects TLS imple-
mentations [25]. Even after these two high-profile discover-
ies, variants of POODLE continued emerging [10, 29, 28].
These works detected different TLS record processing vul-
nerabilities; some TLS implementations only verified the
first MAC byte, the others skipped validation of specific
padding bytes.

3.4 Lucky 13 and Other Timing Attacks

In 2013, AlFardan and Paterson [4] used a similar technique
to break TLS confidentiality and dubbed their attack “Lucky
13”. The attack relies on an important observation: Common
HMAC functions require different processing times when
processing inputs of different lengths. By performing clever
padding byte manipulations, the attacker can force the server
to execute HMAC computations on plaintexts of different
lengths. This is because the padding length determines the
amount of data used as input into the HMAC function. The
attacker can then measure the different processing times and
learn information about the padding byte. We refer the reader
to [4] for the full attack description.

The fix to Lucky 13 was to change the MAC verification
code in TLS implementations to be constant-time, regardless
of the number of processed cleartext blocks. This is possible,
but writing and maintaining such code is hard, even for ex-
perts. In 2016, Somorovsky identified a bug in the patched
code of OpenSSL [37]. The bug introduced a similar and
even more severe vulnerability which allowed an attacker to
distinguish between two alert messages. A different message
could be triggered if the decrypted message only contained
two or more valid padding blocks.

Amazon’s s2n TLS library was released in 2015 [24], af-
ter the Lucky 13 attack was published. s2n’s developers were
aware of Lucky 13 and introduced specific countermeasures
that seemed to render the code constant-time, thereby pre-
venting the attack. They also introduced randomized timing
delays to make the attack more difficult, in the unexpected
case that the code turned out to be vulnerable. Despite all
these efforts, s2n was still vulnerable to variants of Lucky
13 [3, 35]. All vulnerabilities were found despite the code
having been formally verified.

USENIX Association 28th USENIX Security Symposium    1033



3.5 Bleichenbacher’s Attack and its Variants

Bleichenbacher’s attack [8] is also a form of a padding oracle
attack. Rather than targeting symmetric encryption, it targets
a padding scheme used in RSA encryption, called PKCS#1
v1.5. It also similarly exploits a malleability property of
RSA encryption and relies on a decryptor (i.e., a server)
emitting error messages in case of invalidly-padded cleart-
exts. The standard countermeasure is similar to that of CBC
padding oracles; the server must not behave differently when
encountering error states in RSA decryption. This counter-
measure has become part of the TLS standard.

However, implementing the countermeasure correctly is
challenging. BĂśck et al. scanned for vulnerable TLS servers
vulnerable to Bleichenbacher’s attack [9]. They found vul-
nerabilities in servers used by high-profile websites such
as Facebook and Paypal. Interestingly, their vulnerabilities
could be triggered by using different TLS protocol flows
or exploiting TCP connection states (TCP resets or time-
outs). As with CBC padding oracles, Bleichenbacher’s at-
tack shows a similar sequence of an attack variant being dis-
covered every few years in different contexts [26, 22, 6].

4 Scanning and Evaluation Methodology

The ultimate goal of our research is to estimate the number
and the impact of padding oracle vulnerabilities and report
our findings to the responsible vendors. To accomplish this,
we proceed in three steps. We first define a list of test vectors
potentially triggering observable differences which result in
padding oracles. We then reduce this test vector list and per-
form a large-scale scan. Finally, we analyze the identified
vulnerabilities and responsible vendors.

4.1 Test Vector Generation

In order to detect padding oracles in implementations, we
connect and send various malformed records. These records
contain different malformities in regards to the padding,
MAC, and application data. We then observe if there are
any differences in responses, in the TLS layer, or in lower
layers. An implementation that responds differently to two
malformed records may be vulnerable.

It is infeasible to test with all possible malformed records.
For example, a vulnerable implementation could correctly
check all padding bytes unless the padding bytes are exactly
16 bytes long, in which case the implementation does not
check a specific bit in the padding.2 Since there could be
up to 256 padding bytes, testing the correct validation of
each bit for all possible padding lengths would require test-
ing with ∑

256
i=1 8i = 263,168 different records. These records

2The above behavior may sound contrived, but similar behaviors have
been found in the wild, see e.g. [29, 28, 37].

need to be tested with different cipher suites or protocol ver-
sions which makes such a comprehensive test infeasible. We
therefore carefully selected a set of malformed records which
are motivated by previous research.

We concede this way of selecting the set of malformed
records means we can only detect vulnerabilities that are
similar to known ones. However, this approach is cost-
effective and well-suited to large-scale scans. Since only a
limited number of messages can be sent to individual servers
during large-scale scans, automatic approaches for the test
vector generation, like fuzzing, are usually infeasible.

4.1.1 Malformed Records

Our malformed records are all 80 bytes in length. Equal
lengths ensure that differences in responses are likely caused
by a padding oracle vulnerability and are not false positives
triggered by different record lengths. Unusual record lengths
may lead to errors that are unrelated to decryption; for exam-
ple, recent OpenSSL versions respond with a different error
message if the encrypted TLS record is shorter than the MAC
length. We decided to use 80 bytes to have enough room for
an HMAC output combined with two full padding blocks.
This allows us to construct records protected by SHA-384,
whose output is 48 bytes in length. We summarize our 25
malformed records in the following paragraphs. See also Ta-
ble 1 for a summary of these malformed records for the case
of TLS_RSA_WITH_AES_128_CBC_SHA.

Flipped MAC bits. We start with a valid record containing
application data, a MAC, and four padding bytes. We then
create three malformed records based on this record: One by
flipping the most significant bit in the first MAC byte, one
by flipping a middle bit in the middle of the MAC bytes,
and one by flipping the least significant bit of the last MAC
byte. We chose these malformed records to detect imple-
mentations where the MAC is not completely checked. The
specific bit flipping positions are motivated by the recent
OpenSSL vulnerability [1], where OpenSSL only checked
the least significant bit of each byte on some platforms, and
by further vulnerabilities caused by incomplete MAC valida-
tions [29, 28].

Missing One MAC byte. We start with a val";"""date"",""2019-07-25T00:05:19Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""3"",""1"",""0"",""0"",""0"",""0"",""0"",""2"",""597"",""0"",""0"",""1"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.5""
""xmp:CreatorTool"",""TeX""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dcterms:created"",""2019-02-19T01:25:47Z""
""language"",""en""
""Last-Modified"",""2019-07-25T00:05:19Z""
""dcterms:modified"",""2019-07-25T00:05:19Z""
""dc:format"",""application/pdf; version=1.5""
""xmpMM:DocumentID"",""uuid:84b3a78b-75dc-f849-bfff-6ce7230226eb""
""Last-Save-Date"",""2019-07-25T00:05:19Z""
""pdf:docinfo:creator_tool"",""TeX""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2019-07-25T00:05:19Z""
""meta:save-date"",""2019-07-25T00:05:19Z""
""pdf:encrypted"",""false""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017) kpathsea version 6.2.3""
""xmp:CreateDate"",""2019-02-19T01:25:47Z""
""modified"",""2019-07-25T00:05:19Z""
""Content-Length"",""1012064""
""pdf:hasMarkedContent"",""false""
""Content-Type"",""application/pdf""
""xmp:ModifyDate"",""2019-07-24T17:05:19Z""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017) kpathsea version 6.2.3""
""xmp:MetadataDate"",""2019-07-24T17:05:19Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""pdf:producer"",""pdfTeX-1.40.18; modified using iTextŽ 7.1.4 Š2000-2018 iText Group NV (AGPL-version)""
""trapped"",""False""
""meta:creation-date"",""2019-02-19T01:25:47Z""
""created"",""2019-02-19T01:25:47Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""19""
""Creation-Date"",""2019-02-19T01:25:47Z""
""resourceName"",""sec19-merget.pdf""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""605"",""3902"",""4872"",""4663"",""4415"",""4761"",""4633"",""4073"",""3966"",""4570"",""4928"",""2522"",""3841"",""3265"",""4216"",""4259"",""4856"",""4573"",""2479""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""producer"",""pdfTeX-1.40.18; modified using iTextŽ 7.1.4 Š2000-2018 iText Group NV (AGPL-version)""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""pdfTeX-1.40.18; modified using iTextŽ 7.1.4 Š2000-2018 iText Group NV (AGPL-version)""
""pdf:docinfo:created"",""2019-02-19T01:25:47Z""
";https://scholar.google.com/scholar?start=870&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094546-676;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[CITATION][C] Einsatz von dezentralen Oracles für die Inter-Blockchain-Kommunikation in Multi-Ledger-Systemen;C Marx ;2019 Universität Hamburg;;null;;null;null;;;;https://scholar.google.com/scholar?start=490&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094607-935;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Towards fairness and decentralisation in modern cryptocurrencies;CA Carr ;2019 eprints.qut.edu.au;;"… should have an understanding of how blockchain technology works and what the main challenges

are. 2.1 Modern Cryptocurrencies It is now quite common to see the word 'cryptocurrencies', or

in some cases just 'crypto', referring to the myriad cryptocurrency schemes that …";Autres articles;;[PDF] qut.edu.au;https://eprints.qut.edu.au/130876/1/Christopher%20Alan_Carr_Thesis.pdf;"
Christopher Carr
BSc MSc

Towards Fairness and Decentralisation
in Modern Cryptocurrencies

Submitted in fulfilment of the requirement for the degree of
Doctor of Philosophy

2019

Queensland University of Technology
School of Electrical Engineering and Computer Science
Faculty of Science and Engineering
Norwegian University of Science and Technology
Department of Information Security and Communication Technology
Faculty of Information Technology and Electrical Engineering



Statement of original authorship

The work contained in this joint thesis undertaken between Queensland
University of Technology and the Norwegian University of Science and
Technology has not been previously submitted to meet the requirements
for an award at any other higher education institution. To the best of
my knowledge and belief, the thesis contains no material previously
published or written by any other person except where due reference is
made.

Signed

Date
June 2019

QUT Verified Signature



Abstract

The ideas contained within the thesis build towards the goal of improving both
fairness and decentralisation in modern cryptocurrencies. The thesis has four
main contributions. The first contribution is towards client puzzles, and how
blockchains can be used to improve their design for the sake of user fairness.
The second is a way of constructing proof-of-work puzzles that have intrinsic
value, as a way of capturing the computational expenditure for some useful
purpose, and thus mitigating the energy wastage problems. The third, more
minor, contribution is a way of using puzzles of this nature in applications of
blockchain technology. The fourth and final contribution describes a way of
designing a consensus mechanism from a directed acyclic graph structure, to
regain the decentralised aspect that is missing in blockchain proposals. It is
demonstrated that by constructing a system in this way, one can gain both
scalability and decentralisation at the same time.





Acknowledgements

First I would like to acknowledge my principal supervisor, Colin Boyd, who
has been immensely supportive throughout my entire PhD process, both on a
work and personal level. Kristain Gjøsteen and Xavier Boyen, who have both
supported me in a supervisory role, also deserve a special mention for their
guidance and encouragement, as well as Danilo Gligoroski whose enthusiasm
for research is inspiring.

I wish to acknowledge my office mates, HĂĽkon Jacobsen and Britta Hale,
with whom I spent the majority of my PhD life. Many a valuable and interest-
ing discussion was had in the confines of office B220 — as well as many more
discussions of great interest, but perhaps little value.

Mona Nordaune, Pül SÌther and Randi Flønes deserve special credit for
marking the department an incredibly efficient, helpful, and above all, wel-
coming place to work. Harald Øverby and Laurent Paquereau also deserve
their share of gratitude for their time leading and supporting the department
that helped make it such a rewarding workplace.

On a personal level I would like to start by mentioning my friends back
in England: Sam Taylor, Tom Rogers, Ross Middleton, Dan Rumble and Rob
Kelly. For the almost constant stream of amusing messages, for Glastonbury,
for struggling to catch waves in the winter seas of Wales, for Wine Club and
for everything in between.

I wish also to recognise the friendships that have developed while working
at NTNU: Lucy Chamberlin, who helped enormously with my preparation
for the Forsker Grand Prix, and who has been a steadfast friend to me; Sara
Anastasio, Nina Berggaard and Knut Jørgen Vie who I have known almost
since I first arrived in Trondheim, and whom I have had reason to celebrate



VI Acknowledgements

many an occasion with; David Palma and Ergys Puka, who have become good
friends to me. I would be remiss if I did not also mention Douglas Stebila,
Nick Rodofile and Craig Costello who helped make my time spent in Brisbane
a time worth remembering. In addition I would like to acknowledge those who
have supported me but, for one reason or another, have become distant.

Finally I would like to mention my family: my mom Ann, my dad Alan,
my brother Jon, my dog (and king) Tann and his loyal sidekick Kaz. Their
support and faith in me has shaped me into the person I am today.

To all, deeply and sincerely, thank you!



Contents

Notation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XIII

Terminology and Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XVII

1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.1 The Thesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.1.1 Motivation, Research Question and Objectives . . . . . . . . . . 2

1.1.2 On Fairness and Decentralisation . . . . . . . . . . . . . . . . . . . . . 3

1.1.3 Contributing Papers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.1.4 Non-contributing Papers and Articles . . . . . . . . . . . . . . . . . 4

1.1.5 Authorship . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.2 Organisation Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.3 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.1 Modern Cryptocurrencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.2 Bitcoin and the Blockchain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.2.1 A Digital Signature Scheme . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.2.2 Hash Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.2.3 Hash Chains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.2.4 Bitcoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.2.5 Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15



VIII Contents

2.2.6 Transactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.2.7 Blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2.2.8 The Blockchain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

2.3 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

2.3.1 Incentives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

2.3.2 51% Attack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

2.4 Open Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

2.4.1 Scalability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

2.4.2 Decentralisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

2.4.3 Energy Consumption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

2.4.4 Storage Space Demand . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

2.4.5 Revocation and Dispute Resolution . . . . . . . . . . . . . . . . . . . 36

2.4.6 ASIC Resistance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

2.4.7 Anonymity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

3 Fair Client Puzzles from the Blockchain . . . . . . . . . . . . . . . . . . . . 39

3.1 Chapter Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

3.1.1 Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

3.1.2 Chapter Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

3.2 Client Puzzles and Proofs of Work . . . . . . . . . . . . . . . . . . . . . . . . . . 41

3.3 Client Puzzles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

3.3.1 Security Notions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

3.3.2 Difficult Client Puzzles from the Blockchain . . . . . . . . . . . . 45

3.3.3 An Abstract Blockchain-based Client Puzzle . . . . . . . . . . . 46

3.3.4 Stronger Security from Cost-Based Puzzles . . . . . . . . . . . . . 47

3.3.5 Achieving Fair Client Puzzles . . . . . . . . . . . . . . . . . . . . . . . . 51

3.4 Application to Denial of Service Resistance . . . . . . . . . . . . . . . . . . 51

3.4.1 Client Puzzles for Denial of Service Resistance . . . . . . . . . . 52

3.4.2 Creating a Denial of Service Resistant Protocol . . . . . . . . . 53

3.4.3 Meeting the Denial of Service Resistant Criteria . . . . . . . . 54



Contents IX

3.5 A Proof of Concept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

3.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

3.6.1 Gaining Real-time Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

3.6.2 Traditional Payment Services? . . . . . . . . . . . . . . . . . . . . . . . . 59

3.6.3 Implementation Challenges . . . . . . . . . . . . . . . . . . . . . . . . . . 59

3.6.4 Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

4 Valuable Puzzles for Proofs-of-Work . . . . . . . . . . . . . . . . . . . . . . . 63

4.1 Chapter Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

4.1.1 Advantages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

4.1.2 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

4.1.3 Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

4.1.4 Chapter Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

4.2 Valuable Puzzles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

4.2.1 Requirements for Bitcoin-like Consensus . . . . . . . . . . . . . . . 69

4.2.2 Extended Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

4.2.3 Generic Bitcoin-like Construction . . . . . . . . . . . . . . . . . . . . . 77

4.3 Adapting Public Key Schemes for PoW Puzzles . . . . . . . . . . . . . . 79

4.3.1 Schnorr Signature Puzzles . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

4.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

4.4.1 Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

5 Public and Transparent Key Recovery . . . . . . . . . . . . . . . . . . . . . 89

5.1 Chapter Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

5.1.1 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

5.1.2 Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

5.1.3 Chapter Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

5.2 Key Escrow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

5.2.1 Oblivious Key Escrow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

5.2.2 Partial Key Escrow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

5.2.3 Ensuring a Distributed User Base . . . . . . . . . . . . . . . . . . . . . 94



X Contents

5.3 Key Recovery Design Principles . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

5.3.1 Principles: Inert and Public . . . . . . . . . . . . . . . . . . . . . . . . . . 95

5.3.2 Blockchains, Decentralised Ledgers and PKI . . . . . . . . . . . 95

5.4 Key Recovery Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

5.4.1 Proposal 1: Decentralised Oblivious Key Escrow . . . . . . . . 97

5.4.2 Proposal 2: Partial Key Escrow . . . . . . . . . . . . . . . . . . . . . . . 98

5.4.3 Proposal 3: Decentralised Oblivious Partial Key Escrow . 99

5.5 Methods for Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

5.5.1 Implementing Proposal 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

5.5.2 Implementing Proposal 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

5.5.3 Implementing Proposal 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

5.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

5.6.1 Preventing Criminal Activity . . . . . . . . . . . . . . . . . . . . . . . . . 104

5.6.2 Leveraging Existing Technology . . . . . . . . . . . . . . . . . . . . . . 105

5.6.3 Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

6 A Framework for a Blockchain-Free Cryptocurrency . . . . . . . 107

6.1 Chapter Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

6.1.1 A Graphchain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

6.1.2 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

6.1.3 Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

6.2 A Block-Free Ledger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115

6.2.1 Transactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115

6.2.2 Transaction Validity and Fee Collection . . . . . . . . . . . . . . . 119

6.2.3 Prize . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

6.2.4 Drain and Prize Depletion . . . . . . . . . . . . . . . . . . . . . . . . . . . 120

6.2.5 Drain Rate Adjustment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121

6.2.6 Verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

6.2.7 Conflict Resolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

6.2.8 Consensus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123



Contents XI

6.2.9 Mining and Minting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125

6.2.10 Monetary and Inflationary Policy . . . . . . . . . . . . . . . . . . . . . 125

6.2.11 Transaction Application Layer . . . . . . . . . . . . . . . . . . . . . . . . 126

6.3 Security and Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126

6.3.1 Double-Spending Resistance . . . . . . . . . . . . . . . . . . . . . . . . . 128

6.3.2 Graph Consolidation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129

6.3.3 Convergence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129

6.4 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131

6.4.1 Attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132

6.4.2 Practical Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134

6.5 Simulation and Experimental Results . . . . . . . . . . . . . . . . . . . . . . . 135

6.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136

6.6.1 Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136

7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139

7.1 Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139

7.1.1 Fairness . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140

7.1.2 Decentralisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140

7.2 Limitations and Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140

7.2.1 Decentralised Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . 141

7.2.2 Alternative Methods for Consensus . . . . . . . . . . . . . . . . . . . 141

7.2.3 Assumptions and Formality . . . . . . . . . . . . . . . . . . . . . . . . . . 141

7.2.4 Practicality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142

7.2.5 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143

7.2.6 Security Modelling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143

7.2.7 Open Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144

7.3 Addressing the Research Question . . . . . . . . . . . . . . . . . . . . . . . . . . 145

References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146





Notation

a 2 A a is an element of the set A

a
$ ďż˝ A Selecting an element a uniformly at

random from a set A

g : A! B A function g defining a mapping be-
tween two sets A and B

Img(g(a)) The set of all elements {b1, . . . , bn},
such that for any element g(bi) the
probability that g(bi) = g(a), is
greater than 0

dae The roof function where for any real
number a the function outputs the
closest integer a0 where a0 ďż˝ a and
0  a0 � a < 1

bac The floor function where for any real
number a the function outputs the
closest integer a0 where a0  a and
0  a� a0 < 1

A⌦ A group A equipped with the oper-
ator ⌦



XIV Contents

|a| The order of the element a in a
group A

|A| The total number of unique elements
in a set A

N,Z,R Denotes the set of Natural Numbers,
the set of Integers and the set of Real
Numbers respectively

Z⇤
p The group of integers modulo p with

operator ⇤

{0, 1}⇤ The space of all binary strings for
some undefined but finite length

A⇥ . . .⇥A| {z }
n

= An When n is a number, the Cartesian
product of a set A

(pk, sk) Usually used to represent a cor-
responding public-key, private-key
pair respectively

a||b The concatenation of two string a

and b, e.g., if a = 1459OF1 and
b = A71, then a||b = 1459OF1A71

a[i] The character in position i of string
a, where there first character is at
position 0, e.g., for a = 1459OF1

then a[3] = 9

a[i,j] The characters between and include
i and j

lsb(a), msb(a) The least significant bit of a, and the
most significant bit of a for some bi-
nary string a



Contents XV

negl(¡) A function negl : N ! R is negligi-
ble if for every polynomial function
poly(¡) there exists an N 2 Z > 0

such that for every x > N

|negl(x)| < 1

|poly(x)|

Pr[X] The probability that event X oc-
curs, for some event X

A,B, . . . Algorithms A, B, etc.

a A Algorithm A returns a

a
$ ďż˝ A Algorithm A returns a randomly

over the probability distribution for
A

a = A a is assigned to be the output of al-
gorithm A





Terminology and Abbreviations

Altcoin An alternative cryptocurrency to
Bitcoin. Most cryptocurrencies post
Bitcoin can be called an altcoin

Bitcoins Currency used in Bitcoin, further
subdivided into satoshis

Bitcoin-like Refers to the proof-of-work consen-
sus mechanism inherent in Bitcoin
and to cryptocurrencies that are
similar to Bitcoin in their operation
and goals

Block A collection of transactional, and
other, data, used in blockchained
systems

A blockchain The general blockchain construct

The Blockchain Bitcoin’s blockchain

Computationally In-
feasible

Impractical to compute in any rea-
sonable amount of time

Cryptocurrencies Digital currencies with security
properties that are reliant on cryp-
tographic schemes.



XVIII Contents

Efficient A synonym for quick, fast or easy in
a computational sense

Mining The process of expending computa-
tional resources in order to find a
block in a blockchain system

Puzzle A computational problem designed
to be solvable by a machine in a rea-
sonable amount of time. The chal-
lenge of forming a new block in the
Bitcoin blockchain is a puzzle

ASIC Application–Specific Integrated Cir-
cuit

DDoS Distributed Denial of Service

DoS Denial of Service

MAC Message Authentication Code

PoS Proof-of-Stake

PoW Proof-of-Work

UTXO Unspent Transaction Output



1

Introduction

Bitcoin has been with us for a short amount of time, but the ideas it has
inspired have proven very popular within both society and academia. Various
factors may account for Bitcoin’s success, but undoubtedly its detachment from
trusted authorities and its perceived immunity from government interference
played a significant part in its uptake.

With Bitcoin came a revolutionary new idea, the Blockchain. The Blockchain
allows for a distributed set of users, who don’t know or trust each other, to
reach consensus on the state of the Bitcoin system. They can do this provided
only that the majority of the participants act rationally. The Blockchain is the
underlying technology that allows Bitcoin to operate and it is now common-
place to see journals, conferences and workshops soliciting submissions related
to “Blockchain Technology”.

Blockchain technology has stimulated a considerable amount of research and
development into distributed consensus and modern cryptocurrencies. Indeed,
since Bitcoin first appeared there have been a host of alternative cryptocur-
rencies that have sprung up in its wake. Each offer some advantages over the
original Bitcoin design, but often at the cost of other desirable properties. Some
of the most popular of these are Ethereum [102], Litecoin [137], Monero [139],
Ripple [121], Stellar [140] and Z-Cash [145].

Some commentators argue that blockchain technologies are a passing phase,
with overly inflated valuations reliant on hype and marketing by those who have
a vested interest. Others are far more optimistic and assert that blockchain
technology is paving the way for how society will use not only cash, but a
variety of other digital services, in the future. Regardless of which stance you
choose, Bitcoin and blockchain technology have merit. Bitcoin represents the
first example of digital cash that has seen global take up, an accolade that



2 1.1. The Thesis

cannot be easily ignored. Above all, what is most fascinating is simply that it
works, and not just theoretically. Blockchain technology works, and people are
using it.

1.1 The Thesis

This thesis is submitted as a monograph, consisting of published material.
The contributions of this thesis fall under two broad themes, fairness and
decentralisation. Both themes have been the motivating factor in the direction
of research, and show up repeatedly throughout. Scalability and energy wastage
are also addressed as sub-themes.

1.1.1 Motivation, Research Question and Objectives

Modern cryptocurrencies, such as Bitcoin, cannot avoid an element of idealism.
This ideal is to throw away the banks, the governments and the corporations:
the trusted authorities. Most of us are used to trusted authorities. They are
necessary not only for dealing with money, but for a host of other services.
These authorities have great control over the systems they manage, which
many people are often forced into using as there is no viable alternative. Bitcoin
wanted to be this alternative for monetary transactions. At the very least, it
can be argued that decentralisation was part of the initial motivation and the
reason for its uptake. The principle was straightforward, anyone could join and
take part in all operations of the system: create accounts, create cash, spend
cash, verify transactions and secure the system.

Decentralised design comes with an implicit assumption that decentrali-
sation achieves something that is otherwise found wanting. But what does
decentralisation actually provide? Theoretically it was intended to allow indi-
viduals a share in the monetary system that they took part in, but does this
hold true in practice? We are already aware that decentralisation in modern
cryptocurrencies is not exactly as we might expect. Does this technology pro-
vide improvements that make things better for individuals over the trusted
authorities? Does it truly provide something for the little guy? Essentially,
does it improve fairness? These questions lead on to the overarching research
question:

Can we have truly decentralised cryptocurrencies, and how can they
be a benefit to society?



Introduction 3

The objectives set out to answer this question are as follows:

1. Investigate the decentralisation properties in modern cryptocurrencies.

2. Assess the benefits that decentralised cryptocurrencies offer in terms of
fairness for individual users.

3. Contribute to the understanding and improvement of decentralisation and
fairness in cryptocurrencies.

1.1.2 On Fairness and Decentralisation

Despite fairness and decentralisation being the main themes of this thesis,
in general neither fairness nor decentralisation have an accepted definition. If
there is a definition, it is contextual within the area of application. For ex-
ample, we can talk quite concretely about fair lotteries in a scientific context,
but the idea of fair play, a phrase associated with sport, is probably undefin-
able. Decentralisation has a similar issue, especially in the contexts it is most
often used, within politics and networked computer systems. The main point
is that both the notions of fairness and decentralisation hold some amount of
subjectivity.

This thesis does not attempt to define fairness or decentralisation. Still, the
remaining question is in the context of this thesis, what exactly is meant by
fairness and decentralisation? Decentralisation is explained within each chap-
ter and relates in context to what is dealt with there. In a broader sense,
decentralisation refers to the ideal that is borne out of Bitcoin. This ideal of
decentralisation could more correctly be called a distributed and decentralised
design. That in principle at least there is no central authority that decides on
either the rules of the system, the state of the system or the actors. In practice
decentralisation is a very nuanced term, as noted by both academia [100] and
by major players in the area [131].

Fairness is also contextual based on the chapter. The broader sense here
is the underlying idea arising from decentralisation — that a decentralised
system hands more control to the users of the system, in direct comparison
with traditional services. This can be viewed as more fair since it shares the
responsibility of managing and operating the system with the ones who actually
want to use it.



4 1.1. The Thesis

1.1.3 Contributing Papers

The thesis is structured around four published papers listed below in reverse
chronological order:

1. Valuable Puzzles for Proofs-of-Work. Colin Boyd and Christopher Carr.
In ESORICS ’18 International Workshops: DPM 2018 and CBT 2018,
Barcelona, LNCS, 2018. [28]

2. Blockchain-Free Cryptocurrencies: A Rational Framework for Truly Decen-
tralised Fast Transactions. Xavier Boyen, Christopher Carr and Thomas
Haines. In BCC@AsiaCCS ’18: 2nd ACM Workshop on Blockchains, Cryp-
tocurrencies, and Contracts, ACM 2018. [31]

3. Key Recovery: Inert and Public (KRIP). Colin Boyd, Xavier Boyen, Christo-
pher Carr and Thomas Haines. In Mycrypt ’16: Paradigm-shifting Crypto,
LNCS, 2016. [26]

4. Fair client puzzles from the bitcoin blockchain. Colin Boyd and Christopher
Carr. In ACISP ’16: 21st Australasian Conference on Information Security
and Privacy, LNCS, 2016. [27]

One of the primary contributions of this thesis is the work that started with
the paper entitled: “Blockchain-Free Cryptocurrencies: A Rational Framework
for Truly Decentralised Fast Transactions,"" originally published in 2016 on the
Cryptology ePrint Archive [30]. Since this time there have been several revi-
sions to this paper up until publication. This contribution makes up Chapter 6.

1.1.4 Non-contributing Papers and Articles

As well as the contributing works, there are additional papers and articles
resulting from work carried out during the PhD candidature. They are listed
as follows in reverse chronological order:

1. Zero-Knowledge Proof of Decryption for FHE Ciphertexts. Christopher
Carr, Anamaria Costache, Gareth T. Davies, Kristian Gjøsteen and Mar-
tin Strand. In Cryptology ePrint Archive: Report 2018/026, 2018. [35]

2. Bitcoin Unchained. Christopher Carr, Colin Boyd, Xavier Boyen and
Thomas Haines. In ERCIM News ’17, 2017. [34]

3. CARIBE: Cascaded IBE for Maximum Flexibility and User-Side Control.
Britta Hale, Christopher Carr and Danilo Gligoroski. In Mycrypt ’16:
Paradigm-shifting Crypto, LNCS, 2016. [64]



Introduction 5

4. A Guide to Fully Homomorphic Encryption. Frederik Armknecht, Colin
Boyd, Christopher Carr, Kristian Gjøsteen, Angela Jäschke, Christian A.
Reuter and Martin Strand. In Cryptology ePrint Archive: Report 2015/1192,
2015. [4]

1.1.5 Authorship

For the four works listed in Section 1.1.3, the contents of the thesis represent
the contributions of the thesis author. However, the simulation code in Chap-
ter 6, and the code snippets found in Chapter 5 were provided by a co-author,
Thomas Haines, and are included in this thesis as they help to better express
the ideas.

1.2 Organisation Chapter Summary

The thesis is a monograph with the contributing papers developed into chap-
ters.

Chapter 1: Introduction

Chapter 1 introduces and lays out the thesis. It defines the research question
and objectives and lists the research papers. It concludes by summarising the
chapters and the research results.

Chapter 2: Background

Chapter 2 introduces the ideas that will be used throughout the thesis, in-
cluding the fundamentals of blockchain and cryptocurrency technology. This
chapter also provides an understanding of the problems within modern cryp-
tocurrencies that are addressed in the following chapters.

Chapter 3: Fair Client Puzzles from The Blockchain

Chapter 3 re-examines the use of client puzzles within a blockchain context.
Client puzzles were originally proposed as a mechanism for proving the legiti-
mate intentions of a client. The idea is that when a client wishes to communi-
cate with some service, the client would have to provide a proof-of-work. The



6 1.2. Organisation Chapter Summary

proof-of-work is essentially some extra information that demonstrates that the
client has expended some computational effort. This method can be applied
to discourage malicious usage of resources, by only providing service to clients
willing to form some proof-of-work. However, one unresolved problem of client
puzzles is the difference in expected solving time of a puzzle on different com-
puting platforms. Essentially, the use of client puzzles does not address the
principle of equal access amongst legitimate users.

The contribution of this chapter is a construction for client puzzles that re-
quires widely distributed computational effort for their solution. These puzzles
are built so that they can be solved using the proof-of-work process of Bitcoin,
or a similar cryptocurrency. By adapting existing definitions for client puzzles,
the puzzle construction can satisfy formal requirements of client puzzles under
reasonable assumptions. Further, the chapter describes a way of transforming
client puzzles for use in both denial of service and distributed denial of service
scenarios, and defines fair client puzzles : puzzles where the solution time is
independent of the client device. The chapter concludes by demonstrating a
practical construction for fair client puzzles, and details how to use them to
mitigate certain attacks.

Chapter 4: Valuable Puzzles for Proofs-of-Work

Chapter 4 focuses on the proof-of-work mechanisms used in cryptocurrencies,
such as the one used in Bitcoin, which are considered wasteful due to their
associated energy consumption. A main driver of this criticism is that the com-
putation expended within most proof-of-work systems has no utility outside of
the system itself.

Focusing on useful computation, which we call valuable puzzles, we examine
the required conditions for adapting and utilizing computational challenges
with some intrinsic value for use in a distributed cryptocurrency scheme.

The contributions of this chapter are a formulation of requirements for
puzzles to be used in a distributed consensus mechanism with a competitive
reward structure. By ";"""date"",""2019-06-19T07:07:03Z""
""pdf:PDFVersion"",""1.7""
""xmp:CreatorTool"",""Preview""
""pdf:docinfo:title"",""MainThesisTemplate-May19-QUT.pdf""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.7""
""pdf:docinfo:creator_tool"",""Preview""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""MainThesisTemplate-May19-QUT.pdf""
""xmp:CreateDate"",""2019-06-16T18:08:31Z""
""modified"",""2019-06-19T07:07:03Z""
""pdf:hasMarkedContent"",""false""
""xmp:ModifyDate"",""2019-06-19T17:07:03Z""
""meta:creation-date"",""2019-06-16T18:08:31Z""
""created"",""2019-06-16T18:08:31Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-06-16T18:08:31Z""
""resourceName"",""Christopher%20Alan_Carr_Thesis.pdf""
""producer"",""macOS Version 10.14.5 (Build 18F132) Quartz PDFContext""
""pdf:docinfo:producer"",""macOS Version 10.14.5 (Build 18F132) Quartz PDFContext""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dcterms:created"",""2019-06-16T18:08:31Z""
""Last-Modified"",""2019-06-19T07:07:03Z""
""dcterms:modified"",""2019-06-19T07:07:03Z""
""title"",""MainThesisTemplate-May19-QUT.pdf""
""xmpMM:DocumentID"",""uuid:ada07fca-a6c9-4cab-a911-67f618e8e25f""
""Last-Save-Date"",""2019-06-19T07:07:03Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2019-06-19T07:07:03Z""
""meta:save-date"",""2019-06-19T07:07:03Z""
""Content-Length"",""1885415""
""Content-Type"",""application/pdf""
""xmp:MetadataDate"",""2019-06-19T17:07:03Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""pdf:producer"",""macOS Version 10.14.5 (Build 18F132) Quartz PDFContext""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""180""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""412"",""429"",""832"",""0"",""1438"",""520"",""1120"",""1686"",""1679"",""1689"",""1618"",""0"",""469"",""717"",""340"",""0"",""631"",""479"",""1608"",""1873"",""1850"",""1752"",""1339"",""1984"",""1955"",""973"",""1468"",""1953"",""1614"",""1676"",""1921"",""1502"",""1715"",""1941"",""1368"",""1785"",""2219"",""1621"",""1768"",""1585"",""1521"",""1530"",""1832"",""2046"",""1615"",""1916"",""2019"",""1870"",""1019"",""1407"",""2040"",""942"",""1896"",""1728"",""665"",""0"",""1604"",""2078"",""1939"",""1270"",""1610"",""1662"",""1652"",""1778"",""2091"",""1969"",""1908"",""1844"",""1967"",""1774"",""2102"",""1414"",""1899"",""2021"",""1465"",""1890"",""1980"",""1965"",""204"",""0"",""1446"",""1781"",""2186"",""2133"",""1842"",""1783"",""1972"",""1485"",""1789"",""1962"",""2062"",""1893"",""2048"",""2025"",""1812"",""1544"",""1571"",""1725"",""1383"",""879"",""1713"",""1987"",""1677"",""1901"",""389"",""0"",""1580"",""2002"",""1977"",""1747"",""1935"",""1952"",""1876"",""1996"",""1746"",""2085"",""1392"",""1214"",""1041"",""1760"",""1987"",""1737"",""1266"",""0"",""1303"",""2170"",""2054"",""1222"",""2454"",""2131"",""1606"",""1963"",""1503"",""1077"",""1850"",""1195"",""1834"",""1968"",""1794"",""1322"",""1753"",""1978"",""1765"",""1754"",""1781"",""1832"",""1601"",""1904"",""1818"",""1642"",""1869"",""1587"",""1903"",""1495"",""300"",""0"",""932"",""1844"",""1902"",""2188"",""1969"",""1585"",""1441"",""1332"",""1942"",""1820"",""2016"",""1886"",""1958"",""1984"",""1946"",""1886"",""1808"",""1868"",""1800"",""1963"",""1978"",""1615"",""1250"",""0""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-06-16T18:08:31Z""
";https://scholar.google.com/scholar?start=750&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094635-1057;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[PDF][PDF] REŠTAURA?NÉ TECHNIKY POUŽITÉ PRI OBNOVE HISTORICKÉHO RÁDIO PRIJÍMA?A RESTAURANT TECHNIQUES USED FOR RESTORING THE …;M Kopecký ; Úvod redakce  itev.olympiadatechniky.cz;;"… Tokens of standard of ERC20 which superstructure over Ether (Ethereum crypto-currency), have

high liquidity and can … For communication with Ethereum Blockchain used Web3 … Oracles were

used for interaction of Ethereum network with Off-chain [6]. Android OS was chosen as …";Autres articles;Version HTML;[PDF] olympiadatechniky.cz;http://itev.olympiadatechniky.cz/journal-itev-2018.pdf#page=78;"
 

 

 



 

 

Inovace a technologie ve vzdělávání 

Časopis o nových metodách a inovacích v technickém a přírodovědném vzdělávání. 

Obsahové zaměření časopisu 

Časopis se věnuje především problematice ve vzdělávání technických a přírodovědných oborů 

v rámci širokého spektra vzdělávacích institucí. Časopis je platformou pro transfer nových a 

inovativních poznatků do pedagogickÊ praxe. Specializuje se na výzkum, vývoj a evaluaci 

nových didaktických pomůcek, postupů a metod. Publikuje zejmÊna výsledky specifickÊho 

výzkumu s participací studentů a informace vedoucí ke zkvalitňovåní a zefektivňovåní 

vzdělávacího procesu. 

Časopis je zaměřený zejména na středoevropský prostor a státy s podobnými školskými 

systémy. Publikuje texty článků psané v jazyce českém, anglickém, slovenském a polském. 

Cílem časopisu je umožnit publikaci zajímavých myšlenek a vizí vědeckých a odborných 

pracovníků se zájmem o efektivní a kvalitní školství. Časopis vychází jednou ročně. 

 

Redakce 

Mgr. Jan KrotkĂ˝, Ph.D. a PhDr. Petr Simbartl, Ph.D. 

Redakční rada 

Prof. PaedDr. Jarmila Honzíková, Ph.D., PhDr. Petr Simbartl, Ph.D., PhDr. Šárka Pěchoučková, 

Ph.D., PhDr. LukĂĄĹĄ HonzĂ­k, Ph.D., PaedDr. Petr Mach, CSc., Mgr. Jan KrotkĂ˝, Ph.D., Mgr. Jan 

Fadrhonc, Mgr. Zuzana Izquierdo Montes. 

Adresa redakce 

Katedra matematiky, fyziky a technické výchovy, FPE ZČU v Plzni, Klatovská tř. 51, 306 14 

Plzeň 

Vydavatel 

Západočeská univerzita v Plzni (IČO: 49777513), Fakulta pedagogická, Univerzitní 8, 306 14 

Plzeň, Česká republika 

 



 

 

Úvod redakce 

První ročník časopisu, který jsme nazvali Inovace a technologie ve vzdělávání 

navazuje na šest předchozích ročníků sborníku příspěvků z mezinárodní 

studentskÊ konference Olympiåda techniky Plzeň. V letoťním roce jsme se 

rozhodli oddělit publikační výstupy účastníků od samotné účasti a prezentace na 

této oblíbené konferenci. Vzniklý časopis je tak otevřen i dalším zájemcům o 

publikování v rámci zaměření tohoto periodika. Zmiňovaná Olympiáda techniky 

Plzeň je platformou pro fyzickÊ setkåvåní talentovaných studentů technických 

oborů pedagogických fakult a jejich akademických pracovníků. Věříme, že 

většina zajímavých příspěvků a autorů bude opět pocházet právě z této 

specifické skupiny. Úkolem akademického pracovníka je kromě typických 

administrativních činností také práce se studenty, vyhledávání inovativních 

myšlenek, individuální přístup, spolupráce na projektech a výzkumu, obecný 

rozvoj a podněcování zájmu studentů. Nový časopis slouží primárně právě 

uvedeným cílům. Cílovou skupinou časopisu jsou jednak studenti a pracovníci 

pedagogických fakult, ale také učitelé základních a středních škol, kteří stojí v 

pomyslné první linii našeho školství. Náš nový časopis by měl být propojovacím 

článkem mezi široce pojatými aktivitami pedagogických fakult a školní praxí na 

různých stupních a úrovních.  

Časopis je formálně rozdělen na dvě části. V první části jsou články zabývající se 

především pedagogickým výzkumem, kde jsou autory prezentovány metody, 

postupy, zkušenosti a výsledky. Druhá část časopisu je tematicky pestřejší, neboť 

je určena pro publikaci odborných článků zabývajících se didaktickými 

pomůckami v tom nejširším pojetí. V této části najdete také články pojednávající 

o technických nebo technologických problÊmech v råmci spektra celÊho 

vzdělávacího kurikula a jejich řešení. Redakce časopisu Inovace a technologie ve 

vzdělávání přeje všem čtenářům inspirativní chvilky nad publikovanými 

myťlenkami a výsledky. 

 



Inovace a technologie ve vzdělávání 
1/2018 

4 

Obsah 

HISTORICKÝ A MEDZINÁRODNÝ KONTEXT V PREMENÁCH TECHNICKÉHO VZDELÁVANIA NA 
SLOVENSKU DO ROKU 2015 6 
ZLATICA HUĽOVÁ 

ROZVÍJENÍ PŘEDMATEMATICKÝCH PŘEDSTAV PROSTŘEDNICTVÍM POLYTECHNICKÉ VÝCHOVY 17 
EVA ROTHOVÁ, ŠÁRKA PĚCHOUČKOVÁ 

PEDAGOGICAL SUPPORT OF PROFESSIONAL SELF-DETERMINATION OF STUDENTS 22 
TATIANA ANTONOVA 

STEM POLICY’S INTEGRATION INTO THE GREEK EDUCATIONAL TEACHER TRAINING SYSTEM 25 
CHONDROGIANNI D., MALAISIADA E., TSAKOUMAGKOU P., ARMAKOLAS A. 

INDEPENDENT WORK AS MEANS OF ACTIVIZATION OF EDUCATIONAL COGNITIVE ACTIVITY OF 
PUPILS IN THE COURSE OF TRAINING OF TECHNOLOGY 40 
OKSANA SOKOLOVA 

METHODOLOGY OF DEVELOPMENT OF GENERAL EDUCATIONAL PUPILS SKILLS AT TECHNOLOGY 
LESSONS 43 
ELENA TUCAN 

VYUŽITÍ PRACOVNÍCH ČINNOSTÍ VE VÝUCE MATEMATIKY NA 1. STUPNI 46 
PAVLÍNA KOTKOVÁ, ŠÁRKA PĚCHOUČKOVÁ 

OPEN-SOURCE TOOLS IN EDUCATION: HOW ANDROID CAN FIND ITS PLACE IN A LEARNING 
ENVIRONMENT 52 
ZOTOS C., GOROGIA H., ARVANITAKI D. 

THE ROLE OF SOCIAL MEDIA IN EDUCATION: DESIGNING A NOVEL DIGITAL LEARNING 
ENVIRONMENT 59 
ZOTOS C., ARMAKOLAS S. 

3D MODELING AS AN ALTERNATIVE METHOD OF THE TASKS SOLUTION AT THE TECHNOLOGY 
LESSONS 66 
ALEXANDER SOLDATOV 

GETTING HYDROGEN FROM WATER 70 
G.M. IVANOVA 

WINDOW BLOCK FOR BUILDINGS WITH AUTOMATED CONTROL 72 
GALINA IVANOVA 

REŠTAURAČNÉ TECHNIKY POUŽITÉ PRI OBNOVE HISTORICKÉHO RÁDIO PRIJÍMAČA 78 
MIROSLAV KOPECKÝ 



Inovace a technologie ve vzdělávání 
1/2018 

5 

THEORETICAL APPROACHES TO THE CONTIBUTION OF ART IN EDUCATION 85 
PINELOPI TSAKOUMAGKOU 

UPROSZCZONY DYDAKTYCZNY MODEL UKŁADU SŁONECZNEGO 90 
ANDĹťELIKA SEREDA, ANNA SOLECKA 

DECENTRALIZED APPLICATION FOR LEASE/RENT LODGINGS BASED ON BLOCKCHAIN 93 
SALEH HADI, DZHONOV AZAMAT 

MODERNIZACE VÝUKY SLÉVÁRENSTVÍ 97 
JIŘÍ SEMERÁK 
 

 

 



Inovace a technologie ve vzdělávání 
1/2018 

6 

HISTORICKÝ A MEDZINÁRODNÝ KONTEXT V PREMENÁCH 
TECHNICKÉHO VZDELÁVANIA NA SLOVENSKU DO ROKU 

2015 

HISTORICAL AND INTERNATIONAL CONTEXT IN THE 
AREAS OF TECHNICAL EDUCATION IN SLOVAKIA UNTIL 

2015 

Zlatica HuÄžovĂĄ 

 

Abstrakt 

Technické vzdelávanie na primárnom stupni školy v súčasnosti vyžaduje značnú 
pozornosĹĽ nielen odbornej ale aj laickej verejnosti. OpomĂ­nanie a nerieĹĄenie akĂştnych 
problĂŠmov v oblasti technickĂŠho vzdelĂĄvania Ĺžiakov v mladĹĄom ĹĄkolskom veku 
determinuje zaoberaż sa touto problematikou. Hlavným cieĞom je mapovanie 
aktuálneho stavu v edukačnej praxi doma aj v zahraničí a analýza historického vývoja 
technickĂŠho vzdelĂĄvania v kontexte medzinĂĄrodnĂŠho porovnania.   
 
Kľúčové slová: technické vzdelávanie, primárny stupeň školy, edukačná prax, 
historický vývoj, medzinårodnÊ porovnanie   
 
Abstract 

Nowadays, technical education at primary schools requires substantial attention of not 
only professionals but also of the general public. The fact that urgent problems in 
technical education of primary school aged pupils are neglected and left unsolved 
determines the need to deal with this problem. The main objective is the mapping of 
the current state of educational practice at home and abroad and the analysis of 
historical development of technical education in the context of international 
comparison. 
 
Keywords: technical education, primary schools, educational practice, historical 
development, international comparison 
 

1 ÚVOD 

Technické vzdelávanie vo výchove mladého človeka je dôležité a nenahraditeľné, 
pretoĹže zĂ­skava zĂĄkladnĂŠ poznatky z oblasti vedy, techniky, nadobĂşda praktickĂŠ 
zručnosti, získava vzťah k technike, novým technológiám a zároveň si utvára hodnoty 
a postoje k vedecko-technickĂŠmu pokroku a k poĹžiadavkĂĄm doby. KvalitnĂŠ, modernĂŠ 
a efektívne vzdelávanie zabezpečuje jeho profesijnú prípravu a následné uplatnenie 
sa vo svete práce. Na Slovensku technické vzdelávanie začalo písať svoju históriu 
dňom zavedenia povinného predmetu ručné práce výchovné do vzdelávania.  
 V prvej Československej republike sa Slovensko podľa Deklarácie slovenského 
národa z 30. októbra 1918 stalo súčasťou nového štátu. Značné úlohy pripadli na 
školstvo, učiteľstvo, výchovu a vzdelávanie a na pedagogickú teóriu. V roku 1919 na 
zåklade Výnosu ministerstva ťkolstva a nårodnej osvety boli zavådzanÊ manuålne 



Inovace a technologie ve vzdělávání 
1/2018 

7 

pråce do Ğudových a meťtianskych ťkôl, ktorÊ mali vytvorenÊ vhodnÊ podmienky. Žiaci 
mali moŞnosż pracovaż s drevom, lepenkou a v novo zriadených ťkolských dielňach a 
zĂĄhradĂĄch.  
 V tom čase významné postavenie pracovnej výchove vo vzdelávaní pripisovali 
známi teoretici a metodici ako A. Bartoš, F. Čáda, V. Konvička, B. Weizettelová, J. 
Mauer, V. Rohlena, F. Strnad, A. Truhlář, K. Vavroušek a iní.  
 

2 TechnickĂŠ vzdelĂĄvanie na primĂĄrnom stupni ĹĄkĂ´l do roku 2015 

 V roku 1920 sa uskutočnila medzi učiteľmi anketa o potrebe zavádzania 
manuålnej pråce do výchovy a vzdelåvania. Na zåklade výsledkov tejto ankety boli 
spracované návrhy a následne v roku 1922 bol vydaný Malý školský zákon č. 226 Zb. 
zo dňa 13. júla 1922, v zmysle ktorÊho bol do Ğudových ťkôl zavedený povinný 
predmet ""ručné práce výchovné"". V § 4 v ods. 3 sa uvádza, že ministerstvo školstva 
a nårodnå osveta bude dohliadaż na vybavenosż ťkolských dielní, kuchýň a inÊho 
zariadenia, aby na prechodnú dobu školské úrady zavádzali vyučovanie ručných prác 
chlapčenských a domáce hospodárstvo na školách, ktorým sa vytvoria na výučbu 
vhodné podmienky (Zákon č. 226 /1922).  
 Od školského roka 1923/24 sa tento predmet vyučoval vo všetkých ľudových 
školách. V meštianskych školách to boli ručné práce ženské s náukou o domácom 
hospodĂĄrstve. Od vydania MalĂŠho ĹĄkolskĂŠho zĂĄkona boli vydĂĄvanĂŠ rĂ´zne publikĂĄcie, 
ktoré mali byť podporou pre učiteľa ručných prác výchovných, až kým sa systematicky 
od roku 1927 nezačali vydávať učebné osnovy a metodické príručky. K najznámejším 
v tom čase patrili ""Školník pre školy elementárne, slovenské"" od Bežo, G. a E., 1919, 
""Skladanky"" od Hapala, V., 1925, neskôr to boli ""Ručné práce výchovné na školách 
národných"" od Machytka, F., 1931, ""Dielňa maličkých"" od Steinhíbel, M., 1935, alebo 
""Slöjd- Metodická príručka k vyučovaniu ručným prácam výchovným pre ľudové a 
meĹĄtianske ĹĄkoly"" od Adler, A. 1932 a v kaĹždom nasledujĂşcom roku1 boli vydĂĄvanĂŠ 

učebné osnovy. V tabuľke č. 1 je zaznamenaný podrobný prehľad na základe 
vybraných ukazovateľov (rok, ročník, názov UO, predmet, počet hodín).  
 
Tabuľka  1    Prehľad počtu vyučovacích hodín pracovného vyučovania 
v učebných osnovách v jednotlivých ročníkoch v období rokov 1922-1989 - 1995 
 

Rok/ročník 1. 2. 3. 4. 5. spolu 

1922 

Názov Podrobné Učebné osnovy pre ľudové školy jednotriedne 

Predmet 

Ručné 

prĂĄce 

výchov

nĂŠ 

Ručné 

prĂĄce 

výchov

nĂŠ 

Ručné 

prĂĄce  

výchovnÊ 

Ručné 

prĂĄce 

 výchovnÊ 

 

 

Počet 

hodĂ­n 
1 1 1 1 

 
4 

                                                           
1 V tabuľke 1 sú chronologicky uvedené Učebné osnovy, ktoré boli tvorené buď Úniou učiteľov, pracovnými sekciami učiteľov 

jednotlivých okresov alebo ťkolskými inťpektoråtmi v Trnave, Žiline, Bratislave, Skalici, ai 



Inovace a technologie ve vzdělávání 
1/2018 

8 

 

1927 NĂĄzov 

NovĂŠ podrobnĂŠ osnovy pre ĹĄkoly ÄžudovĂŠ jedno aĹž trojtriedne s 

rozvrhom učebnej látky, vzorovým rozvrhom hodín na týždne 

a pokynmi pre ĹĄkolskĂş administratĂ­vu 

Predmet 

Ručné 

prĂĄce 

výchov

nĂŠ 

Ručné 

prĂĄce 

výchov

nĂŠ 

Ručné 

prĂĄce 

 výchovnÊ 

Ručné 

prĂĄce 

 výchovnÊ 

 

 

Počet 

hodĂ­n 
1 1 1 1  4 

1930 

Názov Nové učebné osnovy pre ľudové a meštianske školy  

Predmet 

Ručné 

prĂĄce 

výchov

nĂŠ 

Ručné 

prĂĄce 

výchov

nĂŠ 

Ručné 

prĂĄce 

 výchovnÊ 

Ručné 

prĂĄce 

 výchovnÊ 

  

Počet 

hodĂ­n 
1 1 1 1  4 

1934 

 
*2 

NĂĄzov 
Podrobné učebné osnovy y rozvrhy učiva podľa definitívnych 

učebných osnov 

Predmet 

Prvouka 

 

Prvouč

né ruč. 

prĂĄce 

Prvouka 

Prvouč

né ruč. 

prĂĄce 

Ručné práce 
chlapčenské 
Ručné práce 
dievčenské 
s nĂĄukou  

o domĂĄcom 
hospodĂĄrstve 

Ručné práce 
chlapčenské 
Ručné práce 
dievčenské 
s nĂĄukou 

 o domĂĄcom 
hospodĂĄrstve 

Ručné práce 
chlapčenské 
Ručné práce 
dievčenské 
s nĂĄukou  

o domĂĄcom 
hospodĂĄrstve 

 

Počet 

hodĂ­n 
4-(1) 4- (1) 1ch/3d 1ch/3d 1ch/3d 

2/3-

9* 

1937 

/ 

1938 

NĂĄzov 
Podrobná učebná osnova pre ľudové školy. Podľa dočasných 

normálnych učebných osnov 

Predmet 

Prvouka 
Prvouč
né ruč. 
prĂĄce 

Prvouka 
Prvouč
né ruč. 
prĂĄce 

Ručné 
prĂĄce 

výchovnÊ 

Ručné 
prĂĄce 

výchovnÊ 

Ručné 
prĂĄce 

výchovnÊ 

 

Počet 

hodĂ­n 
1 1 1 1 1 5 

1939 NĂĄzov 

Dočasné normálne učebné osnovy pre školy ľudové, 

meĹĄtianske  

a jednoročné učebné náukobehy na meštianskych školách 

                                                           
2 * V roku 1934 boli ručné práce v 1. a 2. ročníku v predmete Prvouka po 1hodine týždenne a v 3. až 5. ročníku mali chlapci 

po 1 hodine týždenne v každom ročníku a dievčatá po 3 hodiny týždenne.  

 



Inovace a technologie ve vzdělávání 
1/2018 

9 

Predmet 

Prvouka 
Prvouč
né ruč. 
prĂĄce 

Prvouka 
Prvouč
né ruč. 
prĂĄce 

Ručné práce 
chlapčenské 
Ručné práce 
dievčenské 
s nĂĄukou  

o domĂĄcom 
hospodĂĄrstve 

Ručné práce 
chlapčenské 
Ručné práce 
dievčenské 
s nĂĄukou  

o domĂĄcom 
hospodĂĄrstve 

Ručné práce 
chlapčenské 
Ručné práce 
dievčenské 
s nĂĄukou  

o domĂĄcom 
hospodĂĄrstve 

 

Počet 

hodĂ­n 
4-(1) 4- (1) 1ch/3d 1ch/3d 1ch/3d 

2/3-

9* 

1940 

NĂĄzov 

Učebné osnovy pre ľudové školy / Andrej Jusko/ 

Podrobná učebná osnova pre ľudové školy /pracovné sekcie 

učiteľstva školského inšpektorátu/ 

Predmet 

Prvouka 

Prvouč

né ruč. 

prĂĄce 

Prvouka 

Prvouč

né ruč. 

prĂĄce 

Ručné práce 
chlapčenské 
Ručné práce 
dievčenské 
s nĂĄukou  

o domĂĄcom 
hospodĂĄrstve 

Ručné práce 
chlapčenské 
Ručné práce 
dievčenské 
s nĂĄukou  

o domĂĄcom 
hospodĂĄrstve 

 
 

Ručné práce 
chlapčenské 
Ručné práce 
dievčenské 
s nĂĄukou  

o domĂĄcom 
hospodĂĄrstve 

 

 

 

2/3-
9* Počet 

hodĂ­n 
4-(1) 4- (1) 1ch/3d 1ch/3d 1ch/3d 

 

 

1945 

 
 

 
Učebné plány na šk. rok 1945/1946 pre školy ľudové, 

meštianske, stredné a učiteľské akadémie 

Predmet 

Prvouka 

Prvouč

né ruč. 

prĂĄce 

Prvouka 

Prvouč

né ruč. 

prĂĄce 

Ručné práce 
chlapčenské 
Ručné práce 
dievčenské 
s nĂĄukou  

o domĂĄcom 
hospodĂĄrstve 

Ručné práce 
chlapčenské  
Ručné práce 
dievčenské 
s nĂĄukou  

o domĂĄcom 
hospodĂĄrstve 

Ručné práce 
chlapčenské  
Ručné práce 
dievčenské 
s nĂĄukou  

o domĂĄcom 
hospodĂĄrstve  

 

Počet 

hodĂ­n 
4-(1) 4- (1) 1ch/3d 1ch/3d 1ch/3d 

2/3-

9* 

 

1948 

* 

Názov Učebné osnovy pre ľudové školy / Andrej Jusko/ 

Predmet 

Prvouka 
Prvouč
né ruč. 
prĂĄce 

Prvouka 
Prvouč
né ruč. 
prĂĄce 

Ručné práce 
chlapčenské 
Ručné práce 
dievčenské 
s nĂĄukou  

o domĂĄcom 
hospodĂĄrstve 

Ručné práce 
chlapčenské 
Ručné práce 
dievčenské 
s nĂĄukou  

o domĂĄcom 
hospodĂĄrstve 

Ručné práce 
chlapčenské 
Ručné práce 
dievčenské 
s nĂĄukou  

o domĂĄcom 
hospodĂĄrstve 

 

 

 

2/3-

9* 
Počet 

hodĂ­n 
4-(1) 4- (1) 1/3 1/3 1/3 



Inovace a technologie ve vzdělávání 
1/2018 

10 

1953
/ 

1954
**3 

NĂĄzov 
Prechodné učebné osnovy pre 1.-5. ročník národných škôl na 

ĹĄk. rok 1953/54 

Predmet ---**----- ---**-- ----**--- ----**--- PrĂ­rodopis  

0,5*

* 

Počet 

hodĂ­n 
0 0 0 0 2/0,5** 

1956 
/ 

1957 
 

Názov Učebné osnovy / Metodické state 

Predmet 
Ručné 
prĂĄce 

Ručné 
prĂĄce 

Ručné 
prĂĄce 

Ručné 
prĂĄce 

Ručné 
prĂĄce  

5 Počet 
hodĂ­n 

1 1 1 1 1 

1960 

NĂĄzov 
Učebné osnovy pre prvý až piaty ročník základnej deväťročnej 

ĹĄkoly 

Predmet PracovnĂŠ 
vyučovanie 

PracovnĂŠ 
vyučovanie 

PracovnĂŠ 
vyučovanie 

PracovnĂŠ 
vyučovanie 

PracovnĂŠ 
vyučovanie 

 

7 
Počet 

hodĂ­n 
1 1 1 2 2 

1968 

Názov Učebné osnovy pre 1. - 5. ročník základnej deväťročnej školy 

Predmet PracovnĂŠ 
vyučovanie 

PracovnĂŠ 
vyučovanie 

PracovnĂŠ 
vyučovanie 

PracovnĂŠ 
vyučovanie 

PracovnĂŠ 
vyučovanie  

 

7 

Počet 

hodĂ­n 
1 1 1 2 2 

 

1976 

Názov Učebné osnovy pre 1. - 4. ročník základnej deväťročnej školy 

Predmet PracovnĂŠ 
vyučovanie 

PracovnĂŠ 
vyučovanie 

PracovnĂŠ 
vyučovanie 

PracovnĂŠ 
vyučovanie 

 
 

4 
Počet 

hodĂ­n 
1 1 1 1  

1983 

Názov Učebné osnovy pre 1. - 4. ročník základnej školy 

Predmet PracovnĂŠ 
vyučovanie 

PracovnĂŠ 
vyučovanie 

PracovnĂŠ 
vyučovanie 

PracovnĂŠ 
vyučovanie 

 
 

4 
Počet 

hodĂ­n 
1 1 1 1  

1989

/ 

1990

***4 

Názov Učebné osnovy pre 1. - 4. ročník základnej školy*** 

Predmet PracovnĂŠ 
vyučovanie 

PracovnĂŠ 
vyučovanie 

PracovnĂŠ 
vyučovanie 

PracovnĂŠ 
vyučovanie 

 

4 *** Počet 

hodĂ­n 
1*** 1*** 1*** 1***  

                                                           
3 ** V roku 1953- pracovné vyučovanie bolo zahrnuté do predmetu Prírodopis a to len v piatom ročníku s jedno- tretinovou 

časovou dotáciou (a to 10hodín tvorili pestovateľské práce).  
4 ***Učebné osnovy z roku 1976 boli platné aj v rokoch 1989/1990 až do vydania IUO v roku 1991  



Inovace a technologie ve vzdělávání 
1/2018 

11 

1991 

NĂĄzov 

Pokyny na úpravu obsahu vyučovacích predmetov v 1. až 4. 

ročníku základnej školy a učebné osnovy nepovinných 

predmetov/ Inovované učebné osnovy pre 1. až 4. ročník 

zĂĄkladnej ĹĄkoly/ 

Predmet Prvouka Prvouka 
PracovnĂŠ 
vyučovanie 

PracovnĂŠ 
vyučovanie 

 

2 Počet 

hodĂ­n 
  1 1  

1995 Názov Učebné osnovy pre 1. stupeň základných škôl 

Predmet Prvouka Prvouka 
PracovnĂŠ 
vyučovanie 

PracovnĂŠ 
vyučovanie 

 

2 Počet 

hodĂ­n 
  1 1  

Zdroj: Vlastné spracovanie podľa učebných osnov vydávaných v rokoch 1922 - 1995 

 Z prehľadu jednoznačne vyplýva, že najlepšie obdobie pre technickú výchovu a 
vzdelávanie boli roky 1956 až 1975, kedy sa vyučovalo vo všetkých ročníkoch 
základnej školy s najvyššou možnou časovou dotáciou, zvlášť v rokoch 1960- 1968. V 
diagrame 1 sú uvedené medzníky rozmachu a úpadku pracovného vyučovania na 
primárnom stupni v čase.   
 
Diagram 1  Záznam rozmachu a úpadku pracovného vyučovania na primárnom 
stupni školy v čase 

 
  

V slovenskom vzdelĂĄvacom systĂŠme sa od roku 1995, kedy boli vydanĂŠ 
posledné inovované učebné osnovy dvadsiateho storočia a od roku 1997, kedy sa v 

                                                           
 



Inovace a technologie ve vzdělávání 
1/2018 

12 

zmysle týchto osnov a zmien v nich uvedených vydali aj učebnice k predmetu pracovné 
vyučovanie (vydané M. Kožuchovou v roku 1997), do roku 2008 nerealizovali žiadne 
reformy, nevydávali sa učebnice ani metodické príručky pre predmety technickej 
výchovy, či pracovného vyučovania. Reformná stagnácia a podceňovanie technického 
vzdelávania, výchovy k práci, prácou a pre prácu spôsobila súčasnú vysokú 
nezamestnanosť s nedostatkom odborníkov technického zamerania. Trinásťročné 
podceňovanie technickÊho vzdelåvania, ako konťtatujú aj  
odborníci zaoberajúci sa danou problematikou (Ďuriš 2007; Kožuchová 2011; Kozík 
2013; Bánesz 2014; Pavelka-Kuzma, 2014), pričom nemožno opomenúť aj 
predchĂĄdzajĂşcich 13 rokov (1974-1990), zanechalo na novej mladej generĂĄcii 
nepripravenosť kvalifikovane reagovať na spoločenské potreby a technický pokrok v 
prudko sa rozvĂ­jajĂşcej krajine.  
 Nový, modernizujúci sa spoločensko-ekonomický trh, plný dynamického vývoja 
techniky a technológii vyŞaduje jednotlivcov, ktorí by sa dokåzali veĞmi rýchlo 
adaptovaż na prudko sa meniace podmienky. Dlhých 13 a viac rokov vo vývoji 
jednotlivcov tvoriacich vyspelé spoločenské zoskupenie je príliš veľa na to, aby sa v 
oblasti výchovy a vzdelávania a ich prípravy na život mohlo nečinne prihliadať a 
stagnovať. Preto vláda Slovenskej republiky schválila 2. júla 2008 zákon č. 245/2008 
Z. z. o výchove a vzdelåvaní (ťkolský zåkon) a o zmene a doplnení niektorých zåkonov 
v znení neskorťích predpisov, ktorý voťiel do platnosti od septembra 2008. Po dlhých 
a rozsiahlych diskusiĂĄch o problĂŠmoch, o tom, Ĺže mladĂĄ generĂĄcia nie je pripravenĂĄ 
na plnenie požiadaviek trhu, pretože nemajú dostatočne rozvinuté potrebné a 
požadované dynamizáciou spoločnosti odborné profesijné kompetencie, sa rozhodla 
vlåda SR na nåvrh Ministerstva ťkolstva, vedy, výskumu a ťportu v spolupråci s 
organizáciami, ktorých je zriaďovateľom (ŠPÚ, ŠIOV, MPC a iné) pripraviť a vydať 
novĂŠ Ĺ tĂĄtne vzdelĂĄvacie programy pre vĹĄetky stupne ĹĄkĂ´l5.  

 Rok 2008 sa teda stal prelomovým reformným rokom po viac ročnej stagnácii, 
pretoŞe sa zaviedol model dvojúrovňovÊho kurikula, ktorý zdôrazňuje orientåciu cieĞov 
na rozvoj kľúčových kompetencií (Kmeť, 2011). Prvú úroveň tvoril Štátny vzdelávací 
program ako båza pre tvorbu kurikula druhej úrovne a to Školských vzdelåvacích 
programov. Pozitívom  bola voľnosť, ktorú malo mať vedenie škôl a učitelia pri tvorbe 
vlastných obsahov z ponúkaných obsahových a výkonových ťtandardov. Pri 
implementåcii do vlastných ťkolských vzdelåvacích programov si mali tvorcovia obsah 
prispôsobovaż poŞiadavkåm a podmienkam regiónov6, v ktorých ťkoly pôsobili. 

HumajovĂĄ - KrĂ­Ĺž - Pupala - Zajac (2008) vĹĄak upriamujĂş pozornosĹĽ na 
predimenzovanosĹĽ obsahov vzdelĂĄvania, na redefinovanie vzdelĂĄvacĂ­ch oblastĂ­, kde 
sa objavujú na jednej strane nové a na druhej tradičné predmety a tiež na iracionálne 
prerozdelenie disponibilných hodín. Poukazujú aj na skutočnosť, že zaradenie 
prierezových tém nie je v súlade so zámerom, ktorý mal umožňovať včleniť ich obsahy 
do ťkolských vzdelåvacích programov podĞa toho, v akom prostredí sa ťkoly 
nachádzajú a aké sú ich potreby či požiadavky. Nevytvorili sa ani podmienky pre 
participáciu učiteľa na tvorbe návrhov kurikulárnych zmien.  
 Za negatívum týchto zmien moŞno povaŞovaż aj to, Şe v råmci úprav pre 
primárne vzdelávanie bol samostatný predmet pracovné vyučovanie v 3. ročníku 
základnej školy zrušený a mohol sa vyučovať len ako voliteľný predmet. Povinný ostal 
iba vo 4. ročníku s jednohodinovou týždennou časovou dotáciou vo vzdelávacej oblasti 

                                                           
5 V zmysle medzinárodných štandardov vzdelávania sa súčasne po prvý krát v roku 2008 zaviedlo na Slovensku jednotné 

pomenovanie stupňov ťkôl (ISCED0- predprimårny, ISCED1-primårny, ISCED2-niŞťí sekundårny, ISCED3-vyťťí sekundårny 

a inĂŠ).  
6 Gasparova, M. 2017. Regionålna výchova v ranej edukåcii..Banskå Bystrica: Pf UMB. 2018. s. 9 - 11 



Inovace a technologie ve vzdělávání 
1/2018 

13 

Človek a svet práce. Definovanie cieľov predmetu vychádzalo zo všeobecných 
poŞiadaviek vedecko-technickej gramotnosti a vťeobecných cieĞov primårneho 
vzdelĂĄvania.  
 KoĹžuchovĂĄ - Stebila (2014) konĹĄtatovali, Ĺže kurikulĂĄrna reforma z roku 2008 
bola pre technické vzdelávanie likvidačná. V štátnom vzdelávacom programe bola 
vytvorená vzdelávacia oblasť Človek a svet práce a v nej vyučovací predmet Pracovné 
vyučovanie, ale časová dotácia predmetu však predstavovala len 1 hodinu vo 4. 
ročníku primárnej školy. Učebné osnovy predmetov Výtvarná výchova a Prvouka ostali 
nezmenené, ale predmety získali časovú dotáciu, ktorú získali likvidáciou pracovného 
vyučovania v 1. a 2. ročníku primárnej školy. Je to najväčší, najvážnejší a najakútnejší 
problĂŠm, ktorĂ˝ je potrebnĂŠ rieĹĄiĹĽ. 
 

3 TechnickĂŠ vzdelĂĄvanie na primĂĄrnom stupni ĹĄkoly 
v medzinĂĄrodnom porovnanĂ­ 

 Je problematickĂŠ uviesĹĽ krajinu, kde bolo po prvĂ˝ krĂĄt zavedenĂŠ technickĂŠ 
vzdelĂĄvanie do systĂŠmu vzdelĂĄvania, pretoĹže mnohĂ­ predstavitelia pedagogickĂŠho 
myslenia filozofických smerov, ktorých oblasż zåujmu o pracovno-technickÊ 
vzdelávanie, sa historicky v čase prelína. 
 Komparåciou vybraných indikåtorov týkajúcich sa technickej výchovy a 
technického vzdelávania na primárnom stupni školy vo vybraných krajinách EÚ7 z 

prísluťných kurikulårnych dokumentov je moŞnÊ porovnaż a zistiż rozdiely medzi 
vybranými krajinami. Preto ciele, obsahovÊ a výkonovÊ ťtandardy, nåzvy predmetov 
určených pre technické vzdelávanie, ako aj ich časová dotácia pre jednotlivé ročníky 
základných škôl tvoria hlavné ukazovatele na zisťovanie výučby technického 
vzdelĂĄvania, zvlĂĄĹĄĹĽ na primĂĄrnom stupni ĹĄkĂ´l do roku 2015. Na zĂĄklade podrobnĂŠho 
skúmania ťtåtnych kurikulårnych dokumentov vybraných krajín, bolo moŞnÊ 
porovnåvaż teoreticky rozpracovanÊ ciele, obsahovÊ, výkonovÊ ťtandardy predmetov 
určených pre technické vzdelávanie, ale aj ich časovú dotáciu určenú pre jednotlivé 
ročníky základných škôl.  V tabuľke 2 sú vybrané ukazovatele porovnávané a 
prezentované sú rozdiely nielen v názvoch predmetov, ale hlavne vo výučbe v 
ročníkoch s ich časovou dotáciou.  
 
TabuĞka 2  MedzinårodnÊ porovnanie technickÊho vzdelåvania vo vybraných 
krajinåch na  zåklade vybraných indikåtorov  na primårnom stupni do roku 
2014/15 
  

Štát  Názov predmetu  Ročník  
Časová 
dotĂĄcia  

Ĺ vĂŠdsko  PrĂĄce s textilom a drevom  celĂĄ zĂĄkladnĂĄ ĹĄkola  min. 330h  

FĂ­nsko  
Remeslá/zručnosti (Craft)  
RemeslĂĄ(Craft)/ technickĂŠ a 
textilnĂŠ prĂĄce  

1. - 6.  
7. - 9.  

min. 8 h  
-//-  3 h  

NĂłrsko  
Umenie a remeslĂĄ (Craft)  
Jedlo a zdravý Şivotný ťtýl  

1. - 7.  
8. - 9.  

v kompetencii 
 učiteĞa  

                                                           
7 Huľová, Z. 2017. Technické vzdelávanie a postoje učiteľov k obsahu pracovného vyučovania vo 4. ročníku na 

primárnom stupni  školy. Banská Bystrica: Pf UMB. Habilitačná práca. s. 54 - 82 



Inovace a technologie ve vzdělávání 
1/2018 

14 

Anglicko  
Desing and technology  
(Dizajn a technolĂłgie)  

Key stage 1 ( 5 -  7)  
Key stage 2 ( 7 -11)  
Key stage 3 (11 - 14)  
Key stage 4 (14 - 16)  

v kompetencii 
 učiteĞa  

PoÄžsko  
Zajęcia techniczne  
(Technickå výchova)  

1. - 3   ( 7 -  9)  
4. - 7. (10- 13)  

v kompetencii 
 učiteĞa  

Maďarsko  

TĂŠchnike,ĂŠletvitel ĂŠs 
gyakorlad  
(Technika , Şivotný ťtýl a 
prax)  

1. -  4.  1h/roč. = 4h  

Česko  Pracovní činnosti  
1. -  5.  
6.  - 9.  

1h/roč. = 5h  
1h/roč. = 4h  

Slovensko   Pracovné vyučovanie  4.  1h/roč. = 1h  

  
Vzhľadom k tomu, že na Slovensku v ročníkoch 1. - 3. bol do roku 2015 čiastočne 
obsahový a výkonový ťtandard integrovaný do predmetov Prvouka a Výtvarnå 
výchova, nie je možné jednoznačne konštatovať, že sa v týchto ročníkoch nevyučoval. 
Z uvedenÊho ale vyplýva, Şe na rozdiel od iných krajín je naruťenå kontinuita 
zavedenia nielen samostatného vyučovacieho predmetu, ale aj obsahových a 
výkonových štandardov pre technické vzdelávanie. Znížená je aj časová dotácia, čo 
značne ovplyvňuje kvalitu nadobúdania pracovno-technických poznatkov, návykov a 
zručností.  

TakĂĄto situĂĄcia nemĂĄ obdobu v celej histĂłrii vzdelĂĄvania na Slovensku (KozĂ­k, 
2013). Potvrdzuje to aj historický vývoj technického vzdelávania, ktorý je len čiastočne 
rozpracovaný v tomto príspevku. Ďuriš, M. aj Kozík, T. už v rokoch 2009 až 2011 
upozorňovali na nepriaznivú situåciu v oblasti technickÊho vzdelåvania. Kozík (2013) 
tiež uvádza, že od školského roku 2008/2009, v ktorom sa začala uplatňovať školská 
reforma, technickÊ predmety sa na zåkladných ťkolåch doståvajú do procesu 
postupnej likvidácie. V tomto období vzdelávacia oblasť Človek a svet práce má k 
dispozícii len 1 hodinu za týŞdeň.  Výsledok takÊhoto prístupu zodpovedných za 
technické vzdelávanie sa v súčasnosti už prejavuje v zníženej odbornej úrovni nielen 
Şiakov zåkladných ťkôl, ale hlavne Şiakov stredoťkolskÊho vzdelåvania a v zníŞenom 
zåujme absolventov zåkladných ťkôl o ťtúdium technických odborov na stredných 
odborných školách a rovnako ako dôsledok, aj na technických univerzitách, čo je v 
rozpore s nårodnými potrebami a potrebami zamestnåvateĞov (Vasiliak, 2007; Kozík, 
T., 2013, s. 3; ÚPSVaR, 2015). 

4 ZĂĄver 

 VzdelĂĄvacĂ­ systĂŠm na Slovensku je charakteristickĂ˝ podmienkami a je 
špecifický v každom časovom úseku spoločensko-kultúrneho vývoja. Celosvetové 
spoločenské  dianie a premeny neobchádzajú ani tak špecifický slovenský systém 
vzdelåvania, ktorý sa za ostatných dvadsażpäż rokov neuståle mení a hĞadå stabilnÊ 
ukotvenie v medzinárodnom konkurenčnom priestore. Prudký vedecko-technický 
rozvoj s modernou technikou a s rýchlo progredujúcimi technológiami zasahujúce aŞ 
na úroveň nanočastíc, vyžadujú progresívne zmeny v príprave mladej generácie s 
novým vedecko-technickým myslením. V tej súvislosti je potrebnÊ si uvedomiż, Şe 
vedecko-technické vzdelávanie už u najmladšej vekovej kategórie si vyžaduje značnú 
pozornosť, ktorej sa v období transformačných procesov na Slovensku nedostávalo. 
Podceňovanie, opomínanie a nerieťenie akútnych problÊmov pråve v oblasti 
technickĂŠho vzdelĂĄvania Ĺžiakov mladĹĄieho ĹĄkolskĂŠho veku vyĹžaduje potrebu hlbĹĄie sa 
zaoberaĹĽ  uvedenou problematikou. Je potrebnĂŠ meniĹĽ systĂŠm a pribliĹžovaĹĽ sa 



Inovace a technologie ve vzdělávání 
1/2018 

15 

poĹžiadavkĂĄm tak, aby sme nezaostĂĄvali za krajinami sveta a za poĹžiadavkami, ktorĂŠ 
boli formulovanĂŠ aj na Svetovom ekonomickom fĂłre na jar v roku 2018. OdbornĂ­ci sa 
zaviazali k zlepšeniu stavu sveta, z čoho vyplynula potreba rozvíjať nové zručnosti ako 
naprĂ­klad: vedieĹĽ navrhovaĹĽ, programovaĹĽ, tvorivo originĂĄlne a komplexne rieĹĄiĹĽ 
problĂŠmy, vedieĹĽ analyzovaĹĽ, kriticky a systematicky myslieĹĽ, systematizovaĹĽ, hodnotiĹĽ 
a inĂŠ, potrebnĂŠ pre novĂ˝ spĂ´sob Ĺživota v modernom svete.  
 
LiteratĂşra 

BANESZ, G. 2014. Premeny technickÊho vzdelåvania v råmci ťkolských reforiem. In 

Sborník příspěvků z mezinárodní studentské odborné konference Olympiáda techniky 

Plzeň 2014. Editor Doc. PaedDr. Jarmila Honzíkovå, Ph.D. a Mgr. Jan Krotký. 1. 

vydání, Plzeň: Západočeská univerzita v Plzni, 2014, 186 s., ISBN 978-80-261-0372-

1 

ĎURIŠ, M. 2007. Odborná a pedagogická spôsobilosť učiteľa technickej výchovy ako 

kľúčová kompetencia. In Kľúčové kompetencie a technické vzdelávanie [CD ROM] : 

zbornĂ­k prĂ­spevkov z VRVS videokonferencie, III. InEduTech 2007. PreĹĄov : PreĹĄovskĂĄ 

univerzita, FHPV, 2007. - ISBN 978-80-8068-624-6. - S. 12-16 

GAŠPAROVÁ, M. 2017. Regionålna výchova v ranej edukåcii..Banskå Bystrica: Pf 
UMB. 2018. 1. vyd. 95 s., ISBN 978-80-557-1413-4, s. 9 - 11 

HUĽOVÁ, Z. 2017. Technické vzdelávanie a postoje učiteľov k obsahu pracovného 
vyučovania vo 4. ročníku na primárnom stupni  školy. Banská Bystrica: Pf UMB. 
Habilitačná práca. 

HUMAJOVÁ, Z. – KRÍŽ, M. – PUPALA, B. – ZAJAC, P. 2008. Vzdelávanie pre život. 

Reforma ĹĄkolstva v sĂşvislostiach. Bratislava: KonzervatĂ­vny inĹĄtitĂşt M. R. Ĺ tefĂĄnika, 

2008. 57 s. ISBN 978-80-89121-12-0. 

KMEŤ, P. 2011. Štåtny a ťkolský vzdelåvací program: ZåkladnÊ dokumenty 

kurikulĂĄrnej transformĂĄcie vzdelĂĄvania na Slovensku. In: MedzinĂĄrodnĂĄ vedeckĂĄ 

elektronickå konferencia pre doktorandov, vedeckých pracovníkov a mladých 

vysokoškolských učiteľov, Prešov: FHPV PU, 2011, 506-514. 

KOZÍK, T. 2013. Je opodstatnené vyučovať techniku na základnej škole? In: Technical, 
";"""date"",""2019-01-11T23:10:23Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.7""
""xmp:CreatorTool"",""MicrosoftÂŽ Word 2016""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dc:creator"",""Petr Simbartl""
""language"",""sk""
""dcterms:created"",""2019-01-11T23:10:23Z""
""Last-Modified"",""2019-01-11T23:10:23Z""
""dcterms:modified"",""2019-01-11T23:10:23Z""
""dc:format"",""application/pdf; version=1.7""
""xmpMM:DocumentID"",""uuid:C5701B6A-CA51-4BFC-B30A-D91D3BEC4E90""
""Last-Save-Date"",""2019-01-11T23:10:23Z""
""pdf:docinfo:creator_tool"",""MicrosoftÂŽ Word 2016""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2019-01-11T23:10:23Z""
""meta:save-date"",""2019-01-11T23:10:23Z""
""pdf:encrypted"",""false""
""xmp:CreateDate"",""2019-01-12T00:10:23Z""
""modified"",""2019-01-11T23:10:23Z""
""Content-Length"",""3516570""
""pdf:hasMarkedContent"",""true""
""Content-Type"",""application/pdf""
""xmp:ModifyDate"",""2019-01-12T00:10:23Z""
""pdf:docinfo:creator"",""Petr Simbartl""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Petr Simbartl""
""dc:language"",""cs-CZ""
""meta:author"",""Petr Simbartl""
""pdf:producer"",""MicrosoftÂŽ Word 2016""
""meta:creation-date"",""2019-01-11T23:10:23Z""
""created"",""2019-01-11T23:10:23Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""103""
""Creation-Date"",""2019-01-11T23:10:23Z""
""resourceName"",""journal-itev-2018.pdf""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""3"",""1485"",""1956"",""1396"",""365"",""2368"",""2767"",""1595"",""1791"",""1693"",""1185"",""3995"",""2881"",""3237"",""2829"",""1375"",""2580"",""3788"",""3378"",""2205"",""1782"",""2104"",""2536"",""1982"",""3000"",""2110"",""3338"",""2913"",""2507"",""1114"",""877"",""1505"",""660"",""2966"",""420"",""1730"",""3520"",""2868"",""1179"",""2747"",""2808"",""1680"",""2340"",""1808"",""602"",""2537"",""3731"",""1082"",""2710"",""2188"",""270"",""2899"",""2953"",""562"",""2483"",""1971"",""2626"",""2036"",""2835"",""2540"",""2769"",""3029"",""2465"",""3064"",""726"",""2371"",""1651"",""94"",""880"",""2789"",""1748"",""3025"",""1307"",""2344"",""1540"",""2395"",""283"",""1638"",""627"",""1982"",""1203"",""1919"",""2466"",""992"",""3361"",""3516"",""3179"",""3283"",""2828"",""2550"",""1204"",""1388"",""1554"",""1328"",""1089"",""1303"",""2498"",""1926"",""2186"",""964"",""2066"",""399"",""381""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""Author"",""Petr Simbartl""
""producer"",""MicrosoftÂŽ Word 2016""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""MicrosoftÂŽ Word 2016""
""pdf:docinfo:created"",""2019-01-11T23:10:23Z""
";https://scholar.google.com/scholar?start=870&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094661-1170;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[HTML][HTML] ???????? ??????? ???????????????? ?????????? ? ????? ????? mssql ? mysql ??? sql-????;?? ?????????? ;2019 elartu.tntu.edu.ua;;"… ???? ?????????: 5.12.2019 3. ???????? // tadviser – [??????????? ??????] – ????? ???????:

http://www.tadviser.ru/index.php/??????:????????_(Blockchain) … ??????????????

???????????? ?????????? ???? Oracle // ???. ????. 2015 ? 2 (24). ?.72-85 …";Autres articles;En cache;[HTML] tntu.edu.ua;http://elartu.tntu.edu.ua/handle/lib/30595;"
Skip navigation
    
    
            
                

























       
         
           
           
           
         
         [image: DSpace logo]
       

       
         	 Домівка
	
             Перегляд 
             	Фонди та зібрання
	
	Огляд матеріалів:
	Дати випуску
	Автори
	Заголовки
	ТоПи
	УДК
	Дати збереження
	Типи вмісту
	Мови
	Журнали/збірники
	Конференції/заходи
	Видання, що містить
	ISSN
	Видавництва
	Приналежності
	Ступені дисертацій
	Градації дисертацій
	Дисципліни дисертацій 
	Дисертаційні ради
	Установи захисту дисертацій
	Дати подання


          
	Довідка




 
    
	 	
       Мова
        	
        
         中文
       
      
	
        
         українська
       
      
	
        
         Tßrkçe
       
      
	
        
         ไทย
       
      
	
        
         svenska
       
      
	
        
         русский
       
      
	
        
         portuguĂŞs
       
      
	
        
         polski
       
      
	
        
         norsk
       
      
	
        
         日本語
       
      
	
        
         italiano
       
      
	
        
         Bahasa Indonesia
       
      
	
        
         magyar
       
      
	
        
         Gallegan
       
      
	
        
         français
       
      
	
        
         Basque
       
      
	
        
         Eesti
       
      
	
        
         espaĂąol
       
      
	
        
         Ελληνικά
       
      
	
        
         Deutsch
       
      
	
        
         Welsh
       
      
	
        
         čeština
       
      
	
        
         catalĂ 
       
      
	
        
         български
       
      
	
        
         English
       
      


    


  

 
 
       
			
         
              Вхід: 
	             
             	Мій архів матеріалів
	Оновлення на e-mail
	Обліковий запис


           


          
	
	
	    
          
        

        

	


    

            






                


                



  

	ELARTU — Інституційний репозитарій ТНТУ імені Івана Пулюя
	Роботи студентів
	Магістр
	125 — кібербезпека




                



        


	
		
		






























		
		
		
		

                
                Будь ласка, використовуйте цей ідентифікатор, щоб цитувати або посилатися на цей матеріал:
                http://elartu.tntu.edu.ua/handle/lib/30595


        



    
    	Назва: 	Методика захисту конфіденційності інформації в базах даних mssql і mysql від sql-атак
	Інші назви: 	Methods of information confidentiality protection in mssql and mysql data bases against sql-attack
	Автори: 	Осельський, Сергій Віталійович
Oselskyi, Serhii
	Приналежність: 	Тернопільський національний технічний університет імені Івана Пулюя
	Бібліографічний опис: 	Осельський  С. В. Методика захисту конфіденційності інформації в базах даних mssql і mysql від sql-атак :  дипломна робота магістра за спеціальністю „125 — кібербезпека“/ С.В. Осельський . — Тернопіль: ТНТУ, 2019. — 107с.
	Дата публікації: 	гру-2019
	Дата внесення: 	20-січ-2020
	Країна (код): 	UA
	Науковий керівник: 	Козак, Руслан Орестович
	Теми: 	SQL-ін’єкції
MS SQL,
mySQL
конфіденційність
авторизації
блокчейн
SQL-injection
privacy
authorization
blockchain
	Діапазон сторінок: 	107
	Короткий огляд (реферат): 	Методика захисту конфіденційності інформації в базах даних MS SQL та mySQL від sql-атакУ роботі досліджено методи захисту інформації на рівні баз даних та авторизації. Проаналізовано основні принципи і методи захисту інформації. Запропоновано методи захисту баз даних від стороннього втручання. Розроблено метод захисту конфіденційності інформації в базах даних MS SQL.Ключові слова: SQL-ін’єкції, MS SQL, mySQL, конфіденційність, авторизації, блокчейн.
Methods of information confidentiality protection in mssql and mysql data basesThe methods of data protection in databases at the level of databases and authorization are investigated. The basic methods of information protection are analyzed. Methods for protecting databases from third-party interference are suggested. A method of protecting the privacy of information in MS SQL databases has been developed.
	Опис: 	Роботу виконано у Тернопільському національному технічному університеті імені Івана Пулюя.Керівник роботи:кандидат технічних наук, доцентКозак Руслан Орестович Тернопільський національний технічний університет імені Івана Пулюя,Рецензент:кандидат фізико-математичних наук, професор, завідувач кафедри МММихайлишин Михайло СтаховичТернопільський національний технічний університет імені Івана ПулюяЗахист відбудеться24 грудня 2019 р. о 9 год. на засіданні Державної екзаменаційної комісії у Тернопільському національному технічному університеті імені Івана Пулюя за адресою:46001, м. Тернопіль, вул. Танцорова, 2.
	Зміст: 	Анотація 41 Принципи захисту інформації в базах даних та її основні загрози 91.1 Принципи захисту інформації 91.1.1 Основні потреби в захисті інформації 101.1.2 Рівні захисту інформації 101.1.3 Закон про захист інформації 111.1.4 Заходи захисту інформації 111.1.5. Захист інформації в інтернеті 121.1.6 Захист інформації на підприємстві 121.1.7 Захист персональних даних 131.1.8 Захист носіїв інформації 131.2 Основні загрози безпеці інформації в базах даних 141.2.1 Поняття кіберзагрози 141.2.2 Тренди і прогнози розвитку кіберзагроз 151.2.3 Статистика кіберзагроз в Україні у ІІ кварталі 2019 року 161.2.2 Види загроз інформаційній безпеці 191.2.2.1 Використання шкідливого ПЗ 191.2.2.2 Соціальна інженерія 221.2.2.3 Хакінг 231.2.2.4 Експлуатація веб-вразливостей 241.2.2.5 Підбір облікових даних 251.2.3 Категорії жертв кіберзагроз 261.2.3.1 Державні організації 261.2.3.2 Промислові компанії 281.2.3.3 Медичні заклади 301.2.3.4 Фінансові організації 311.2.3.5 IT-компанії 33Висновки до першого розділу 342 Методи кібератак на конфіденційність інформації та її захисту в базах даних 362.1 SQL-ін’єкції як основний метод порушення конфіденційності інформації в базах даних 362.1.1 Причини виникнення SQL-ін’єкції 362.1.2 Атака SQL ін'єкції з метою отримання доступу до баз даних MSSQL 372.2 Методи захисту баз даних від SQL-ін'єкцій 402.2.1 Плейсхолдери як основний метод захисту від SQL-ін’єкцій 402.2.1.1 Робота з плейсхолдерами 422.2.1.2 Перелік основних недоліки наявних бібліотек 422.2.1.3 Самостійна реалізація плейсхолдеров 4432.2.1.4 Принципи форматування елементів SQL запиту 44 2.2.1.5 Форматування ідентифікаторів Для ідентифікаторів існують всього два правила: 452.2.1.6 Форматування строкових літералів 463 Висновки до другого розділу (Захист від sql-ін’єкцій) 463 Сучасні методи захисту конфіденційної інформації в базах даних Microsoft SQL Server та mySQL 473.1 Авторизація за допомогою алгоритму ТОТР 473.1.1 Хеш-функція 473.1.2 Принцип роботи ТОТР 483.1.3 Відмінність методів НОТР та ТОТР 483.1.4 Безпека алгоритм НОТР 493.2 Застосування технології Blockchain для захисту інформації 493.2.1 Поняття технології Blockchain 493.2.2 Принципи роботи технології Blockchain 51 3.2.3. Хеш-накопичувальне сховище (Hash Chained Storage) 523.2.4 Безпека та конфіденційність у ланцюзі Blockchain 533.2.5 Цифровий підпис 543.2.6 Алгоритм цифрового підпису еліптичної кривої (ECDSA) 543.3 Методика захисту інформації в базах даних 56Висновки до третього розділу 62 5 Охорона праці та безпека в надзвичайних ситуаціях 775.1 Охорона праці 775.2 Ергономічні вимоги до робочого міся користувача персональним комп’ютером(ПК) 815.3 Безпека в надзвичайних ситуаціях 87Екологія 906.1 Гости і стандарти на монітори і ПЕОМ 906.2 Робота з банками екологічної інформації 92Висновки 95Бібліографія 98
	URI (Уніфікований ідентифікатор ресурсу): 	http://elartu.tntu.edu.ua/handle/lib/30595
	Власник авторського права: 	„© Осельський Сергій Віталійович, рік“
	Перелік літератури: 	1. Баранчиков А.И., Баранчиков П.А., Пилькин А.Н. Алгоритмы и модели доступа к записям БД. М.: Горячая линия-Телеком, 2011. 182 с. . – Дата перегляду: 5.12.2019 2. Безопасность web-приложений: а нужно ли тестирование?. – [Електронний ресурс] – Режим доступу: http://www.jetinfo.ru/stati/bezopasnost-web-prilozhenij-a-nuzhno-li- testirovanie. – Дата перегляду: 5.12.2019 3. Блокчейн // tadviser – [Електронний ресурс] – Режим доступу: http://www.tadviser.ru/index.php/Статья:Блокчейн_(Blockchain) . – Дата перегляду: 5.12.2019 4. Блокчейн против базы данных: понимание различий между ними // 101blockchain. – [Електронний ресурс] – Режим доступу: https://101blockchains.com/ru/блокчейн-против-базы-данных/. – Дата перегляду: 5.12.2019 5. Бортовчук Ю.В., Крылова К.А., Ермолаева Л.В. Информационная безопасность в современных системах управления базами данных 99 99 Современные проблемы экономического и социального развития. 2010. № 6. С.224-225. . – Дата перегляду: 5.12.2019 6. Горбачевская Е.Н., Катьянов А.Ю., Краснов С.С. Информационная безопасность средствами СУБД Oracle // Укр. ВУиТ. 2015 № 2 (24). С.72-85. . – Дата перегляду: 5.12.2019 7. Защита информации - актуальность и методы // kak-bog.ru. – [Електронний ресурс] – Режим доступу: http://kak-bog.ru/zashchita-informacii-aktualnost-i-metody. – Дата перегляду: 5.12.2019 8. Защита от SQL-инъекций в PHP и MySQL // Хабрахабр. – [Електронний ресурс] – Режим доступу: https://habr.com/ru/post/148701/. – Дата перегляду: 5.12.2019 9. Зегжда П.Д. Обеспечение безопасности информации в условиях создания единого информационного пространства // Защита информации. Инсайд. 2007. № 4 (16). С.28-33. . – Дата перегляду: 5.12.2019 10. Информационная безопасность бизнеса. Исследование текущих тенденций в области информационной безопасности бизнеса. 2014.. – [Електронний ресурс] – Режим доступу: http://media.kaspersky.com/pdf/IT_risk_ report_Russia_2014.pdf. . – Дата перегляду: 5.12.2019 11. Как понять нужно ли интегрировать blockchain в ваш продукт? // Хабрахабр. – [Електронний ресурс] – Режим доступу: https://habr.com/ru/company/web_payment_ru/blog/301972/. – Дата перегляду: 30.11.2019 100 100 12. Катренко Л. А., Пістун І. П. Охорона праці в галузі освіти: Навч. Посіб. – Суми: ВДТ «Університетська книга», 2004. – 304 с. . – Дата перегляду: 30.11.2019 13. Концепция одноразовых паролей в системе аутентификации // bytemag. – [Електронний ресурс] – Режим доступу: https://www.bytemag.ru/articles/detail.php?ID=9101. – Дата перегляду: 30.11.2019 14. Методы защиты баз данных: защита паролем, шифрование, разграничение прав доступа. – [Електронний ресурс] – Режим доступу: https://habrahabr.ru/post/149238/. – Дата перегляду: 30.11.2019 15. Методы защиты баз данных: защита паролем, шифрование, разграничение прав доступа. – [Електронний ресурс] – Режим доступу: https://studopedia.ru/9_88862_aktualnost-zashchiti-bazi-dannih-metodi-. – Дата перегляду: 30.11.2019 16. Минимальная заработная плата // Статистика. – [Електронний ресурс] – Режим доступу: https://index.minfin.com.ua/labour/salary/min/. – Дата перегляду: 30.11.2019 17. Охорона праці [З.М. Яремко, С.В. Тимошук, О.І. Третяк та ін.:]; за ред. З.М. Яремка. – Львів: ВЦ ЛНУ імені Івана Франка, 2010. – 310 с. . – Дата перегляду: 30.11.2019 18. Охорона праці та промислова безпека: Навч. посіб. / К. Н. Ткачук, В. В. Зацарний, Р. В. Сабарно, С. Ф. Каштанов, Л. О. Мітюк, Л. Д. Третьякова, К. К.Ткачук, А.В. Чадюк. За ред. К.Н. Ткачука і В.В. Зацарного. – К., 2009. – 454 с. . – Дата перегляду: 30.11.2019 101 101 19. Охорона праці та промислова безпека: Навч. посіб. / К. Н. Ткачук, В. В. Зацарний, Р. В. Сабарно, С. Ф. Каштанов, Л. О. Мітюк, Л. Д. Третьякова, К. К.Ткачук, А.В. Чадюк. За ред. К.Н. Ткачука і В.В. Зацарного. – К., 2009. – 454 с. . – Дата перегляду: 30.11.2019 20. Подборка материалов по SQL Injection. – [Електронний ресурс] – Режим доступу: http://injection.rulezz.ru/. – Дата перегляду: 30.11.2019 21. Полтавцева М.А. Задача хранения прав доступа к данным в СУБД на примере Microsoft SQL Server // Актуальные направления фундаментальных и прикладных исследований: матер. V Междунар. научно-практич. конф. 2015 С. 118-120. . – Дата перегляду: 30.11.2019 22. Поляков А.М. Безопасность Oracle глазами аудитора: нападение и защита.М.: ДМК Пресс, 2014. 336 с. . – Дата перегляду: 30.11.2019 23. Потапов А.Е., Манухина Д.В., Соломатина А.С., Бадмаев А.И., Яковлев А.В., Нилова А.С. Безопасность локальных баз данных на примере SQL Server Compact // Укр. Тамбов. ун-та. Серия: Естественные и технические науки. 2014. № 3. С. 915-917. . – Дата перегляду: 30.11.2019 24. Смирнов С.Н. Безопасность систем баз данных. М.: Гелиос АРВ, 2007. 352 с. . – Дата перегляду: 20.11.2019 25. Ткаченко Н.А. Реализация монитора безопасности СУБД MySQL в dbf / dam системах // ПДМ. Дополнение. 2014. № 7. С. 99-101. . – Дата перегляду: 20.11.2019 102 102 26. Ткаченко Н.А. Реализация монитора безопасности СУБД MySQL в dbf / dam системах // ПДМ. Дополнение. 2014. № 7. С. 99-101. . – Дата перегляду: 20.11.2019 27. Трахтенберг І. М., Коршун М. М., Чебанова О. В. Гігієна праці та виробнича санітарія. – К.: Основа, 1997. – 464 с. . – Дата перегляду: 20.11.2019 28. Уязвимость CVE-2017-8570 // codeby. – [Електронний ресурс] – Режим доступу: http://catcut.net/gXVE. – Дата перегляду: 20.11.2019 29. Эргономика / Адамчук В. В., Варна Т. П., Воротникова В. В.и др.; Под ред. проф. Адамчука В. В. –М.: ЮНИТИ-ДАНА, 1999. –254 с. . – Дата перегляду: 20.11.2019 30. Эргономика / Адамчук В. В., Варна Т. П., Воротникова В. В.и др.; Под ред. проф. Адамчука В. В. –М.: ЮНИТИ-ДАНА, 1999. –254 с. . – Дата перегляду: 20.11.2019 31. Яремко З. М. Безпека життєдіяльності. Навч. посібник.–Львів: Видавничий центр ЛНУ імені Івана Франка, 2005. –301 с. . – Дата перегляду: 20.11.2019 32. 11 Steps to Secure SQL // upguard. – [Електронний ресурс] – Режим доступу: https://www.upguard.com/blog/11-steps-to-secure-sql. – Дата перегляду: 14.11.2019 33. Are SQL placeholder safe? // Codecademy. – [Електронний ресурс] – Режим доступу: http://catcut.net/ITVE. – Дата перегляду: 14.11.2019 34. Authentication, authorization, privileges, and auditing // IBM. – [Електронний ресурс] – Режим доступу: http://catcut.net/O1WE. – Дата перегляду: 14.11.2019 103 103 35. Blockchain – распределенная база данных // nvdaily. – [Електронний ресурс] – Режим доступу: https://nvdaily.ru/info/116465.html. – Дата перегляду: 14.11.2019 36. Blockchain technology — a very special kind of Distributed Database // Medium. – [Електронний ресурс] – Режим доступу: https://medium.com/@sbmeunier/blockchain-technology-a-very-special-kind-of-distributed-database-e63d00781118. – Дата перегляду: 14.11.2019 37. Burtescu E. Database security attacks and control me - thods. Journ. of Applied Quantitative Methods 2009, vol. 4, no. 4, pp. 449-454 . – Дата перегляду: 04.11.2019 38. Database Security Technical Implementation Guide (STIG). // US Department of Defense. Vers. 7. Release 1. 2004. – [Електронний ресурс] – Режим доступу: https://www.computer.org/cms/s2esc/s2esc_excom/Minutes/2005-03/ DISA% 20STIGs / DATABASE-STIG- V7R1.pdf. – Дата перегляду: 04.11.2019 39. Database SQL Language Reference // Oracle.com. – [Електронний ресурс] – Режим доступу: http://catcut.net/7VVE. – Дата перегляду: 04.11.2019 40. How To Prevent SQL Injection Attacks // Назва ресурсу. – [Електронний ресурс] – Режим доступу: http://catcut.net/JWVE. – Дата перегляду: 04.11.2019 41. How to protect your website agains SQL injection attacks // sitepoint. – [Електронний ресурс] – Режим доступу: http://catcut.net/XWVE. – Дата перегляду: 04.11.2019 104 104 42. INFOWATCH // Статистика атак на веб додатки – [Електронний ресурс] – Режим доступу: Посилання на ресурс https://www.infowatch.ru/analytics/leaks_monitoring/19302. – Дата перегляду: 04.11.2019 43. INFOWATCH // Статистика атак на веб додатки – [Електронний ресурс] – Режим доступу: Посилання на ресурс https://www.infowatch.ru/analytics/leaks_monitoring/19481. – Дата перегляду: 30.10.2019 44. Introducing SQL Server Security // ITproToday – [Електронний ресурс] – Режим доступу: http://catcut.net/N1WE. – Дата перегляду: 17.10.2019 45. Lesov P. Database security: a historical perspective.perspectiv. 2010. URL: http://arxiv.org/ftp/arxiv/papers/1004/1004.4022.pdf. – Дата перегляду: 17.10.2019 46. Murray M.C. Database security: what students need to know. JITE: IIP, vol. 9, 2010 pp. 61-77. . – Дата перегляду: 17.10.2019 47. OATH Submits TOTP: Time-Based One Time Password Specification to IETF // WebCite. – [Еле. – Дата перегляду: 30.10.2019ктронний ресурс] – Режим доступу: http://catcut.net/yXVE 48. OATH: yesterday, today, and tomorrow // LWN.net. – [Електронний ресурс] – Режим доступу: https://lwn.net/Articles/419968/. – Дата перегляду: 30.10.2019 49. Overview of SQL Server Security // Microsoft. – [Електронний ресурс] – Режим доступу: http://catcut.net/C1WE. – Дата перегляду: 30.10.2019 105 105 50. PHP mySQL Prepared Statements Tuturial to Prevent SQL Injection // Websitebeaver. – [Електронний ресурс] – Режим доступу: http://catcut.net/ZVVE. – Дата перегляду: 30.10.2019 51. PHP PDO prepared Statements Tuturial to Prevent SQL Injection // Websitebeaver – [Електронний ресурс] – Режим доступу: http://catcut.net/bWVE. – Дата перегляду: 21.10.2019 52. PL/SQL placeholder duplication // dba-oracle. – [Електронний ресурс] – Режим доступу: http://www.dba-oracle.com/t_plsql_placeholder_duplication.htm. – Дата перегляду: 21.10.2019 53. Placeholder SQL // osisoft. – [Електронний ресурс] – Режим доступу: http://catcut.net/ATVE. – Дата перегляду: 21.10.2019 54. Placeholders in SQL query // perlmonks. – [Електронний ресурс] – Режим доступу: https://www.perlmonks.org/?node_id=1103424. – Дата перегляду: 21.10.2019 55. PostgreSQL vs Oracle. – [Електронний ресурс] – Режим доступу: http://www.jetinfo.ru/stati/bezopasnost-web-prilozhenij-a-nuzhno-li- testirovanie. – Дата перегляду: 21.10.2019 56. Protecting against SQL injection // HACKSPLAINING. – [Електронний ресурс] – Режим доступу: https://cutt.ly/Se6EcKG. – Дата перегляду: 17.10.2019 57. Qiu M., Davis S. Database security mechanisms and implementation. IACIS, Issues in Inform. Syst. 2002 vol. 03 pp. 529-534. 58. Rohilla S., Mittal P.K. Database Security: Threads and Challenges. Intern. Journ. of Advanced Research in Computer Science and Software Engineering, 2013, vol. 3, iss. 5, pp. 810-813. . – Дата перегляду: 17.10.2019 106 106 59. Sandhu Ravi S., Jajodia Sushil. Data and database security and controls. Handbook of Information Security Management, Auerbach Publishers, 1993, pp. 181-199. – Дата перегляду: 17.10.2019 60. SQL injection // PORTSWIGGER. – [Електронний ресурс] – Режим доступу: https://portswigger.net/web-security/sql-injection. – Дата перегляду: 14.10.2019 61. SQL injection // Wikipedia – [Електронний ресурс] – Режим доступу: https://en.wikipedia.org/wiki/SQL_injection. – Дата перегляду: 14.10.2019 62. SQL placeholder in WHERE IN issue, inserted string fail // Stackoverflow. – [Електронний ресурс] – Режим доступу: http://catcut.net/hVVE. – Дата перегляду: 14.10.2019 63. SQL protection // habrahabr. – [Електронний ресурс] – Режим доступу: https://habr.com/ru/post/136809/. – Дата перегляду: 14.10.2019 64. SQL Server Security Basics // netwrixBlog. – [Електронний ресурс] – Режим доступу: http://catcut.net/F1WE. – Дата перегляду: 14.10.2019 65. SQL Server Security Best Practices for 2019 // dnsstuff. – [Електронний ресурс] – Режим доступу: https://www.dnsstuff.com/sql-server-security. – Дата перегляду: 14.10.2019 66. SQL Server Security Tips // mssqltips. – [Електронний ресурс] – Режим доступу: https://www.mssqltips.com/sql-server-tip-category/19/security/. – Дата перегляду: 14.10.2019 107 107 67. SQL Wildcards // w3schools – [Електронний ресурс] – Режим доступу: https://www.w3schools.com/sql/sql_wildcards.asp. – Дата перегляду: 12.10.2019 68. TOTP // wikipedia. – [Електронний ресурс] – Режим доступу: https://uk.wikipedia.org/wiki/Time-based_One-time_Password_algorithtml. – Дата перегляду: 12.10.2019 69. Use placeholders for any SQL query // Drupal.com. – [Електронний ресурс] – Режим доступу: https://cutt.ly/Qe6EchC. – Дата перегляду: 12.10.2019 70. What is the SQL injection vulnerability // netsparker. – [Електронний ресурс] – Режим доступу: http://catcut.net/QWVE. – Дата перегляду: 12.10.2019
	Тип вмісту: 	Master Thesis
	Розташовується у зібраннях:	125 — кібербезпека




Файли цього матеріалу:

	Файл	Опис	Розмір	Формат	 
	avtorska Oselskyi.pdf	Авторська довідка	628,96 kB	Adobe PDF	Переглянути/відкрити
	Avtoreferat Oselskyi.pdf	Автореферат	194,08 kB	Adobe PDF	Переглянути/відкрити
	Dyp_ Oselskyi_2019.pdf	Магістерська робота	1,38 MB	Adobe PDF	Переглянути/відкрити








    
        Показати повний опис матеріалу
    

    Перегляд статистики

    





    



    

    Усі матеріали в архіві електронних ресурсів захищені авторським правом, всі права збережені.

    












            

	

	
                    
            
            	Інструменти адміністратора

            	
                
                    
                    
                    
                

                
                    
                    
                    
                

                
                    
                    
                    
                

                
                    
                    
                

					 
                	
             

          

        
    

    
       




            
             
             
             Тема від [image: Logo CINECA]
			                                    
                                Програмне забезпечення DSpace Авторські права © 2002-2013 Массачусетський технологічний інститут та Х’юлет Пакард -
                                Зворотний зв’язок
                                

                                

			

    
    ";"""citation_keywords"",""SQL-ін’єкції"",""MS SQL,"",""mySQL"",""конфіденційність"",""авторизації"",""блокчейн"",""SQL-injection"",""privacy"",""authorization"",""blockchain"",""SQL-ін’єкції; MS SQL,; mySQL; конфіденційність; авторизації; блокчейн; SQL-injection; privacy; authorization; blockchain""
""citation_publication_date"",""2019-12""
""citation_author_institution"",""Тернопільський національний технічний університет імені Івана Пулюя""
""citation_title"",""Методика захисту конфіденційності інформації в базах даних mssql і mysql від sql-атак""
""DC.contributor"",""Козак, Руслан Орестович""
""citation_patent_country"",""UA""
""DCTERMS.references"",""1. Баранчиков А.И., Баранчиков П.А., Пилькин А.Н. Алгоритмы и модели доступа к записям БД. М.: Горячая линия-Телеком, 2011. 182 с. . – Дата перегляду: 5.12.2019 2. Безопасность web-приложений: а нужно ли тестирование?. – [Електронний ресурс] – Режим доступу: http://www.jetinfo.ru/stati/bezopasnost-web-prilozhenij-a-nuzhno-li- testirovanie. – Дата перегляду: 5.12.2019 3. Блокчейн // tadviser – [Електронний ресурс] – Режим доступу: http://www.tadviser.ru/index.php/Статья:Блокчейн_(Blockchain) . – Дата перегляду: 5.12.2019 4. Блокчейн против базы данных: понимание различий между ними // 101blockchain. – [Електронний ресурс] – Режим доступу: https://101blockchains.com/ru/блокчейн-против-базы-данных/. – Дата перегляду: 5.12.2019 5. Бортовчук Ю.В., Крылова К.А., Ермолаева Л.В. Информационная безопасность в современных системах управления базами данных 99 99 Современные проблемы экономического и социального развития. 2010. № 6. С.224-225. . – Дата перегляду: 5.12.2019 6. Горбачевская Е.Н., Катьянов А.Ю., Краснов С.С. Информационная безопасность средствами СУБД Oracle // Укр. ВУиТ. 2015 № 2 (24). С.72-85. . – Дата перегляду: 5.12.2019 7. Защита информации - актуальность и методы // kak-bog.ru. – [Електронний ресурс] – Режим доступу: http://kak-bog.ru/zashchita-informacii-aktualnost-i-metody. – Дата перегляду: 5.12.2019 8. Защита от SQL-инъекций в PHP и MySQL // Хабрахабр. – [Електронний ресурс] – Режим доступу: https://habr.com/ru/post/148701/. – Дата перегляду: 5.12.2019 9. Зегжда П.Д. Обеспечение безопасности информации в условиях создания единого информационного пространства // Защита информации. Инсайд. 2007. № 4 (16). С.28-33. . – Дата перегляду: 5.12.2019 10. Информационная безопасность бизнеса. Исследование текущих тенденций в области информационной безопасности бизнеса. 2014.. – [Електронний ресурс] – Режим доступу: http://media.kaspersky.com/pdf/IT_risk_ report_Russia_2014.pdf. . – Дата перегляду: 5.12.2019 11. Как понять нужно ли интегрировать blockchain в ваш продукт? // Хабрахабр. – [Електронний ресурс] – Режим доступу: https://habr.com/ru/company/web_payment_ru/blog/301972/. – Дата перегляду: 30.11.2019 100 100 12. Катренко Л. А., Пістун І. П. Охорона праці в галузі освіти: Навч. Посіб. – Суми: ВДТ «Університетська книга», 2004. – 304 с. . – Дата перегляду: 30.11.2019 13. Концепция одноразовых паролей в системе аутентификации // bytemag. – [Електронний ресурс] – Режим доступу: https://www.bytemag.ru/articles/detail.php?ID=9101. – Дата перегляду: 30.11.2019 14. Методы защиты баз данных: защита паролем, шифрование, разграничение прав доступа. – [Електронний ресурс] – Режим доступу: https://habrahabr.ru/post/149238/. – Дата перегляду: 30.11.2019 15. Методы защиты баз данных: защита паролем, шифрование, разграничение прав доступа. – [Електронний ресурс] – Режим доступу: https://studopedia.ru/9_88862_aktualnost-zashchiti-bazi-dannih-metodi-. – Дата перегляду: 30.11.2019 16. Минимальная заработная плата // Статистика. – [Електронний ресурс] – Режим доступу: https://index.minfin.com.ua/labour/salary/min/. – Дата перегляду: 30.11.2019 17. Охорона праці [З.М. Яремко, С.В. Тимошук, О.І. Третяк та ін.:]; за ред. З.М. Яремка. – Львів: ВЦ ЛНУ імені Івана Франка, 2010. – 310 с. . – Дата перегляду: 30.11.2019 18. Охорона праці та промислова безпека: Навч. посіб. / К. Н. Ткачук, В. В. Зацарний, Р. В. Сабарно, С. Ф. Каштанов, Л. О. Мітюк, Л. Д. Третьякова, К. К.Ткачук, А.В. Чадюк. За ред. К.Н. Ткачука і В.В. Зацарного. – К., 2009. – 454 с. . – Дата перегляду: 30.11.2019 101 101 19. Охорона праці та промислова безпека: Навч. посіб. / К. Н. Ткачук, В. В. Зацарний, Р. В. Сабарно, С. Ф. Каштанов, Л. О. Мітюк, Л. Д. Третьякова, К. К.Ткачук, А.В. Чадюк. За ред. К.Н. Ткачука і В.В. Зацарного. – К., 2009. – 454 с. . – Дата перегляду: 30.11.2019 20. Подборка материалов по SQL Injection. – [Електронний ресурс] – Режим доступу: http://injection.rulezz.ru/. – Дата перегляду: 30.11.2019 21. Полтавцева М.А. Задача хранения прав доступа к данным в СУБД на примере Microsoft SQL Server // Актуальные направления фундаментальных и прикладных исследований: матер. V Междунар. научно-практич. конф. 2015 С. 118-120. . – Дата перегляду: 30.11.2019 22. Поляков А.М. Безопасность Oracle глазами аудитора: нападение и защита.М.: ДМК Пресс, 2014. 336 с. . – Дата перегляду: 30.11.2019 23. Потапов А.Е., Манухина Д.В., Соломатина А.С., Бадмаев А.И., Яковлев А.В., Нилова А.С. Безопасность локальных баз данных на примере SQL Server Compact // Укр. Тамбов. ун-та. Серия: Естественные и технические науки. 2014. № 3. С. 915-917. . – Дата перегляду: 30.11.2019 24. Смирнов С.Н. Безопасность систем баз данных. М.: Гелиос АРВ, 2007. 352 с. . – Дата перегляду: 20.11.2019 25. Ткаченко Н.А. Реализация монитора безопасности СУБД MySQL в dbf / dam системах // ПДМ. Дополнение. 2014. № 7. С. 99-101. . – Дата перегляду: 20.11.2019 102 102 26. Ткаченко Н.А. Реализация монитора безопасности СУБД MySQL в dbf / dam системах // ПДМ. Дополнение. 2014. № 7. С. 99-101. . – Дата перегляду: 20.11.2019 27. Трахтенберг І. М., Коршун М. М., Чебанова О. В. Гігієна праці та виробнича санітарія. – К.: Основа, 1997. – 464 с. . – Дата перегляду: 20.11.2019 28. Уязвимость CVE-2017-8570 // codeby. – [Електронний ресурс] – Режим доступу: http://catcut.net/gXVE. – Дата перегляду: 20.11.2019 29. Эргономика / Адамчук В. В., Варна Т. П., Воротникова В. В.и др.; Под ред. проф. Адамчука В. В. –М.: ЮНИТИ-ДАНА, 1999. –254 с. . – Дата перегляду: 20.11.2019 30. Эргономика / Адамчук В. В., Варна Т. П., Воротникова В. В.и др.; Под ред. проф. Адамчука В. В. –М.: ЮНИТИ-ДАНА, 1999. –254 с. . – Дата перегляду: 20.11.2019 31. Яремко З. М. Безпека життєдіяльності. Навч. посібник.–Львів: Видавничий центр ЛНУ імені Івана Франка, 2005. –301 с. . – Дата перегляду: 20.11.2019 32. 11 Steps to Secure SQL // upguard. – [Електронний ресурс] – Режим доступу: https://www.upguard.com/blog/11-steps-to-secure-sql. – Дата перегляду: 14.11.2019 33. Are SQL placeholder safe? // Codecademy. – [Електронний ресурс] – Режим доступу: http://catcut.net/ITVE. – Дата перегляду: 14.11.2019 34. Authentication, authorization, privileges, and auditing // IBM. – [Електронний ресурс] – Режим доступу: http://catcut.net/O1WE. – Дата перегляду: 14.11.2019 103 103 35. Blockchain – распределенная база данных // nvdaily. – [Електронний ресурс] – Режим доступу: https://nvdaily.ru/info/116465.html. – Дата перегляду: 14.11.2019 36. Blockchain technology — a very special kind of Distributed Database // Medium. – [Електронний ресурс] – Режим доступу: https://medium.com/@sbmeunier/blockchain-technology-a-very-special-kind-of-distributed-database-e63d00781118. – Дата перегляду: 14.11.2019 37. Burtescu E. Database security attacks and control me - thods. Journ. of Applied Quantitative Methods 2009, vol. 4, no. 4, pp. 449-454 . – Дата перегляду: 04.11.2019 38. Database Security Technical Implementation Guide (STIG). // US Department of Defense. Vers. 7. Release 1. 2004. – [Електронний ресурс] – Режим доступу: https://www.computer.org/cms/s2esc/s2esc_excom/Minutes/2005-03/ DISA% 20STIGs / DATABASE-STIG- V7R1.pdf. – Дата перегляду: 04.11.2019 39. Database SQL Language Reference // Oracle.com. – [Електронний ресурс] – Режим доступу: http://catcut.net/7VVE. – Дата перегляду: 04.11.2019 40. How To Prevent SQL Injection Attacks // Назва ресурсу. – [Електронний ресурс] – Режим доступу: http://catcut.net/JWVE. – Дата перегляду: 04.11.2019 41. How to protect your website agains SQL injection attacks // sitepoint. – [Електронний ресурс] – Режим доступу: http://catcut.net/XWVE. – Дата перегляду: 04.11.2019 104 104 42. INFOWATCH // Статистика атак на веб додатки – [Електронний ресурс] – Режим доступу: Посилання на ресурс https://www.infowatch.ru/analytics/leaks_monitoring/19302. – Дата перегляду: 04.11.2019 43. INFOWATCH // Статистика атак на веб додатки – [Електронний ресурс] – Режим доступу: Посилання на ресурс https://www.infowatch.ru/analytics/leaks_monitoring/19481. – Дата перегляду: 30.10.2019 44. Introducing SQL Server Security // ITproToday – [Електронний ресурс] – Режим доступу: http://catcut.net/N1WE. – Дата перегляду: 17.10.2019 45. Lesov P. Database security: a historical perspective.perspectiv. 2010. URL: http://arxiv.org/ftp/arxiv/papers/1004/1004.4022.pdf. – Дата перегляду: 17.10.2019 46. Murray M.C. Database security: what students need to know. JITE: IIP, vol. 9, 2010 pp. 61-77. . – Дата перегляду: 17.10.2019 47. OATH Submits TOTP: Time-Based One Time Password Specification to IETF // WebCite. – [Еле. – Дата перегляду: 30.10.2019ктронний ресурс] – Режим доступу: http://catcut.net/yXVE 48. OATH: yesterday, today, and tomorrow // LWN.net. – [Електронний ресурс] – Режим доступу: https://lwn.net/Articles/419968/. – Дата перегляду: 30.10.2019 49. Overview of SQL Server Security // Microsoft. – [Електронний ресурс] – Режим доступу: http://catcut.net/C1WE. – Дата перегляду: 30.10.2019 105 105 50. PHP mySQL Prepared Statements Tuturial to Prevent SQL Injection // Websitebeaver. – [Електронний ресурс] – Режим доступу: http://catcut.net/ZVVE. – Дата перегляду: 30.10.2019 51. PHP PDO prepared Statements Tuturial to Prevent SQL Injection // Websitebeaver – [Електронний ресурс] – Режим доступу: http://catcut.net/bWVE. – Дата перегляду: 21.10.2019 52. PL/SQL placeholder duplication // dba-oracle. – [Електронний ресурс] – Режим доступу: http://www.dba-oracle.com/t_plsql_placeholder_duplication.htm. – Дата перегляду: 21.10.2019 53. Placeholder SQL // osisoft. – [Електронний ресурс] – Режим доступу: http://catcut.net/ATVE. – Дата перегляду: 21.10.2019 54. Placeholders in SQL query // perlmonks. – [Електронний ресурс] – Режим доступу: https://www.perlmonks.org/?node_id=1103424. – Дата перегляду: 21.10.2019 55. PostgreSQL vs Oracle. – [Електронний ресурс] – Режим доступу: http://www.jetinfo.ru/stati/bezopasnost-web-prilozhenij-a-nuzhno-li- testirovanie. – Дата перегляду: 21.10.2019 56. Protecting against SQL injection // HACKSPLAINING. – [Електронний ресурс] – Режим доступу: https://cutt.ly/Se6EcKG. – Дата перегляду: 17.10.2019 57. Qiu M., Davis S. Database security mechanisms and implementation. IACIS, Issues in Inform. Syst. 2002 vol. 03 pp. 529-534. 58. Rohilla S., Mittal P.K. Database Security: Threads and Challenges. Intern. Journ. of Advanced Research in Computer Science and Software Engineering, 2013, vol. 3, iss. 5, pp. 810-813. . – Дата перегляду: 17.10.2019 106 106 59. Sandhu Ravi S., Jajodia Sushil. Data and database security and controls. Handbook of Information Security Management, Auerbach Publishers, 1993, pp. 181-199. – Дата перегляду: 17.10.2019 60. SQL injection // PORTSWIGGER. – [Електронний ресурс] – Режим доступу: https://portswigger.net/web-security/sql-injection. – Дата перегляду: 14.10.2019 61. SQL injection // Wikipedia – [Електронний ресурс] – Режим доступу: https://en.wikipedia.org/wiki/SQL_injection. – Дата перегляду: 14.10.2019 62. SQL placeholder in WHERE IN issue, inserted string fail // Stackoverflow. – [Електронний ресурс] – Режим доступу: http://catcut.net/hVVE. – Дата перегляду: 14.10.2019 63. SQL protection // habrahabr. – [Електронний ресурс] – Режим доступу: https://habr.com/ru/post/136809/. – Дата перегляду: 14.10.2019 64. SQL Server Security Basics // netwrixBlog. – [Електронний ресурс] – Режим доступу: http://catcut.net/F1WE. – Дата перегляду: 14.10.2019 65. SQL Server Security Best Practices for 2019 // dnsstuff. – [Електронний ресурс] – Режим доступу: https://www.dnsstuff.com/sql-server-security. – Дата перегляду: 14.10.2019 66. SQL Server Security Tips // mssqltips. – [Електронний ресурс] – Режим доступу: https://www.mssqltips.com/sql-server-tip-category/19/security/. – Дата перегляду: 14.10.2019 107 107 67. SQL Wildcards // w3schools – [Електронний ресурс] – Режим доступу: https://www.w3schools.com/sql/sql_wildcards.asp. – Дата перегляду: 12.10.2019 68. TOTP // wikipedia. – [Електронний ресурс] – Режим доступу: https://uk.wikipedia.org/wiki/Time-based_One-time_Password_algorithtml. – Дата перегляду: 12.10.2019 69. Use placeholders for any SQL query // Drupal.com. – [Електронний ресурс] – Режим доступу: https://cutt.ly/Qe6EchC. – Дата перегляду: 12.10.2019 70. What is the SQL injection vulnerability // netsparker. – [Електронний ресурс] – Режим доступу: http://catcut.net/QWVE. – Дата перегляду: 12.10.2019""
""language"",""uk""
""citation_date"",""2019-12""
""title"",""ELARTU — Інституційний репозитарій ТНТУ імені Івана Пулюя: Методика захисту конфіденційності інформації в базах даних mssql і mysql від sql-атак""
""DC.title"",""Методика захисту конфіденційності інформації в базах даних mssql і mysql від sql-атак""
""citation_online_date"",""2020-01-20T14:02:05Z""
""DC.creator"",""Осельський, Сергій Віталійович"",""Oselskyi, Serhii""
""DC.identifier"",""http://elartu.tntu.edu.ua/handle/lib/30595""
""dc:title"",""ELARTU — Інституційний репозитарій ТНТУ імені Івана Пулюя: Методика захисту конфіденційності інформації в базах даних mssql і mysql від sql-атак""
""citation_language"",""uk""
""Content-Encoding"",""UTF-8""
""Content-Type-Hint"",""text/html; charset=UTF-8""
""DC.description"",""Роботу виконано у Тернопільському національному технічному університеті імені Івана Пулюя.
Керівник роботи:
кандидат технічних наук, доцент
Козак Руслан Орестович Тернопільський національний технічний університет імені Івана Пулюя,
Рецензент:
кандидат фізико-математичних наук, професор, завідувач кафедри ММ
Михайлишин Михайло Стахович
Тернопільський національний технічний університет імені Івана Пулюя
Захист відбудеться24 грудня 2019 р. о 9 год. на засіданні Державної екзаменаційної комісії у Тернопільському національному технічному університеті імені Івана Пулюя за адресою:
46001, м. Тернопіль, вул. Танцорова, 2.""
""DCTERMS.extent"",""107""
""citation_pdf_url"",""http://elartu.tntu.edu.ua/bitstream/lib/30595/8/avtorska%20Oselskyi.pdf""
""DC.rights"",""„© Осельський Сергій Віталійович, рік“""
""Content-Type"",""text/html; charset=UTF-8""
""DCTERMS.alternative"",""Methods of information confidentiality protection in mssql and mysql data bases against sql-attack""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""DCTERMS.tableOfContents"",""Анотація 4
1 Принципи захисту інформації в базах даних та її основні загрози 9
1.1 Принципи захисту інформації 9
1.1.1 Основні потреби в захисті інформації 10
1.1.2 Рівні захисту інформації 10
1.1.3 Закон про захист інформації 11
1.1.4 Заходи захисту інформації 11
1.1.5. Захист інформації в інтернеті 12
1.1.6 Захист інформації на підприємстві 12
1.1.7 Захист персональних даних 13
1.1.8 Захист носіїв інформації 13
1.2 Основні загрози безпеці інформації в базах даних 14
1.2.1 Поняття кіберзагрози 14
1.2.2 Тренди і прогнози розвитку кіберзагроз 15
1.2.3 Статистика кіберзагроз в Україні у ІІ кварталі 2019 року 16
1.2.2 Види загроз інформаційній безпеці 19
1.2.2.1 Використання шкідливого ПЗ 19
1.2.2.2 Соціальна інженерія 22
1.2.2.3 Хакінг 23
1.2.2.4 Експлуатація веб-вразливостей 24
1.2.2.5 Підбір облікових даних 25
1.2.3 Категорії жертв кіберзагроз 26
1.2.3.1 Державні організації 26
1.2.3.2 Промислові компанії 28
1.2.3.3 Медичні заклади 30
1.2.3.4 Фінансові організації 31
1.2.3.5 IT-компанії 33
Висновки до першого розділу 34
2 Методи кібератак на конфіденційність інформації та її захисту в базах даних 36
2.1 SQL-ін’єкції як основний метод порушення конфіденційності інформації в базах даних 36
2.1.1 Причини виникнення SQL-ін’єкції 36
2.1.2 Атака SQL ін'єкції з метою отримання доступу до баз даних MSSQL 37
2.2 Методи захисту баз даних від SQL-ін'єкцій 40
2.2.1 Плейсхолдери як основний метод захисту від SQL-ін’єкцій 40
2.2.1.1 Робота з плейсхолдерами 42
2.2.1.2 Перелік основних недоліки наявних бібліотек 42
2.2.1.3 Самостійна реалізація плейсхолдеров 44
3
2.2.1.4 Принципи форматування елементів SQL запиту 44 2.2.1.5 Форматування ідентифікаторів Для ідентифікаторів існують всього два правила: 45
2.2.1.6 Форматування строкових літералів 46
3 Висновки до другого розділу (Захист від sql-ін’єкцій) 46
3 Сучасні методи захисту конфіденційної інформації в базах даних Microsoft SQL Server та mySQL 47
3.1 Авторизація за допомогою алгоритму ТОТР 47
3.1.1 Хеш-функція 47
3.1.2 Принцип роботи ТОТР 48
3.1.3 Відмінність методів НОТР та ТОТР 48
3.1.4 Безпека алгоритм НОТР 49
3.2 Застосування технології Blockchain для захисту інформації 49
3.2.1 Поняття технології Blockchain 49
3.2.2 Принципи роботи технології Blockchain 51 3.2.3. Хеш-накопичувальне сховище (Hash Chained Storage) 52
3.2.4 Безпека та конфіденційність у ланцюзі Blockchain 53
3.2.5 Цифровий підпис 54
3.2.6 Алгоритм цифрового підпису еліптичної кривої (ECDSA) 54
3.3 Методика захисту інформації в базах даних 56
Висновки до третього розділу 62 5 Охорона праці та безпека в надзвичайних ситуаціях 77
5.1 Охорона праці 77
5.2 Ергономічні вимоги до робочого міся користувача персональним комп’ютером(ПК) 81
5.3 Безпека в надзвичайних ситуаціях 87
Екологія 90
6.1 Гости і стандарти на монітори і ПЕОМ 90
6.2 Робота з банками екологічної інформації 92
Висновки 95
Бібліографія 98""
""citation_abstract"",""Методика захисту конфіденційності інформації в базах даних MS SQL та mySQL від sql-атак
У роботі досліджено методи захисту інформації на рівні баз даних та авторизації. Проаналізовано основні принципи і методи захисту інформації. Запропоновано методи захисту баз даних від стороннього втручання. Розроблено метод захисту конфіденційності інформації в базах даних MS SQL.
Ключові слова: SQL-ін’єкції, MS SQL, mySQL, конфіденційність, авторизації, блокчейн."",""Methods of information confidentiality protection in mssql and mysql data bases
The methods of data protection in databases at the level of databases and authorization are investigated. The basic methods of information protection are analyzed. Methods for protecting databases from third-party interference are suggested. A method of protecting the privacy of information in MS SQL databases has been developed.""
""citation_author"",""Осельський, Сергій Віталійович"",""Oselskyi, Serhii""
""resourceName"",""30595""
""citation_abstract_html_url"",""http://elartu.tntu.edu.ua/handle/lib/30595""
""DC.language"",""uk""
""DC.type"",""Master Thesis""
""viewport"",""width=device-width, initial-scale=1.0""
""DCTERMS.dateAccepted"",""2020-01-20T14:02:05Z""
""DCTERMS.bibliographicCitation"",""Осельський  С. В. Методика захисту конфіденційності інформації в базах даних mssql і mysql від sql-атак :  дипломна робота магістра за спеціальністю „125 — кібербезпека“/ С.В. Осельський . — Тернопіль: ТНТУ, 2019. — 107с.""
""Generator"",""DSpace 5.6""
";https://scholar.google.com/scholar?start=980&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094581-827;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Tighter proofs of CCA security in the quantum random oracle model;N Bindel, M Hamburg, K Hövelmanns… ; Theory of Cryptography …, 2019  Springer;;"… Consider two quantum-accessible oracles \(G,H:X\rightarrow Y\). The oracles do not need to

be random. Suppose that G and H differ only on some small set \(S\subset X\), meaning that

\(\forall x\notin S, G(x) = H(x)\). Let \(\mathcal {A} \) be an oracle algorithm that takes an input …";Cité 23 fois;Les 10 versions;[PDF] iacr.org;https://eprint.iacr.org/2019/590.pdf;"
Tighter proofs of CCA security in the quantum
random oracle model

Nina Bindel1, Mike Hamburg2, Kathrin Hövelmanns3, Andreas Hülsing4, and
Edoardo Persichetti5

1 University of Waterloo, nlbindel@uwaterloo.ca
2 Rambus, mhamburg@rambus.com

3 Ruhr-Universitt Bochum, kathrin.hoevelmanns@ruhr-uni-bochum.de
4 Eindhoven University of Technology, andreas@huelsing.net

5 Florida Atlantic University, epersichetti@fau.edu

Abstract. We revisit the construction of IND-CCA secure key encapsu-
lation mechanisms (KEM) from public-key encryption schemes (PKE).
We give new, tighter security reductions for several constructions. Our
main result is an improved reduction for the security of the U 6⊥-transform
of Hofheinz, Hövelmanns, and Kiltz (TCC’17) which turns OW-CPA
secure deterministic PKEs into IND-CCA secure KEMs. This result
is enabled by a new one-way to hiding (O2H) lemma which gives a
tighter bound than previous O2H lemmas in certain settings and might
be of independent interest. We extend this result also to the case of
PKEs with non-zero decryption failure probability and non-deterministic
PKEs. However, we assume that the derandomized PKE is injective with
overwhelming probability.
In addition, we analyze the impact of different variations of the U 6⊥-
transform discussed in the literature on the security of the final scheme.
We consider the difference between explicit (U⊥) and implicit (U 6⊥) re-
jection, proving that security of the former implies security of the latter.
We show that the opposite direction holds if the scheme with explicit re-
jection also uses key confirmation. Finally, we prove that (at least from
a theoretic point of view) security is independent of whether the ses-
sion keys are derived from message and ciphertext (U 6⊥) or just from the
message (U 6⊥m).

1 Introduction

If a general-purpose quantum computer can be built, it will break most widely-
deployed public-key cryptography. The cryptographic community is busily de-
signing new cryptographic systems to prepare for this risk. These systems typ-
ically consist of an algebraic structure with cryptographic hardness properties,
plus a symmetric cryptography layer which transforms the algebraic structure
into a higher level primitive like a public-key encryption (PKE) scheme, a key
encapsulation mechanism (KEM), or a signature scheme. The algebraic struc-
tures underlying these so-called “post-quantum” systems have new properties,
and the quantum threat model requires changes in the way security is analyzed.



Therefore the transformations turning the algebraic structures into cryptosys-
tems have to be freshly examined.

In this work we focus on the construction of secure KEMs. In this setting the
algebraic structures usually provide a PKE from which a KEM is derived via a
generic transform. A new property of the algebraic structures used in many post-
quantum PKEs and KEMs gives them malleable ciphertexts, so they are at risk
from chosen-ciphertext attacks (CCA) [HNP+03]. The standard defenses against
CCA are variants of the Fujisaki-Okamoto (FO) transform [FO99]. Known secu-
rity proofs for the FO transform use the random oracle model (ROM) [BR93].
This is for two reasons. First, the FO transform has a circular structure–it
chooses coins for encryption according to the message being encrypted. This
leads to obstacles which we do not know how to overcome when proving security
in the standard model. In the ROM, we circumvent this by re-programming. Sec-
ond, in the ROM a reduction learns all the adversary’s queries to the random
oracle. This allows us to formalize the intuition that an adversary must have
known a challenge plaintext to extract said plaintext.

Since we are concerned with security against quantum attackers, we need to
extend these proofs to the quantum-accessible random oracle model (QROM)
[BDF+11]. This comes with two challenges for our setting. On the one hand, in
the QROM the adversary can query all inputs in superposition. Hence, it is no
longer trivial to break the circular dependency by re-programming, which results
in security bounds that do not tightly match known attacks. On the other hand,
a reduction cannot learn the adversarial queries by simple observation anymore.
The reason is that observation of a quantum state requires a measurement which
disturbs the state. Hence, more advanced techniques are required.

1.1 Our Contribution

QROM analysis of KEMs has advanced rapidly over the past several years.
The initial solutions were loose by a factor of up to q6 [TU16,HHK17], where
q is the number of times the adversary queries the random oracle. This has
improved to q2 [SXY18,JZC+18] and finally to q [HKSU18,JZM19a,JZM19c].
Some works provide tight proofs under stronger assumptions [SXY18,XY19].
Our work provides a proof of IND-CCA security for KEMs constructed from
deterministic PKEs (Theorem 2), which is tight except for a quadratic secu-
rity loss which might be impossible to avoid [JZM19b]. For KEMs constructed
from randomized PKEs our bound is still loose by a factor of up to q (Theo-
rem 1). In this particular case, our bound does not essentially differ from the
bound already given in [HKSU18]. In [HKSU18], the proof given is called ”semi-
modular”: it is first shown that derandomization and puncturing achieve the
stronger notion that [SXY18] requires to achieve tight security, and the tight
proof of [SXY18] is then applied to the derandomized and punctured scheme.
The strategy of [HKSU18] was deliberately chosen to deal with correctness er-
rors: The tight proof of [SXY18] could not trivially be generalized for non-perfect
schemes in a way such that the result still would have been meaningful for most

2



lattice-based encryption schemes. Our work deals with correctness errors in a
modular way by introducing an additional intermediate notion (called FFC).

At the heart of our bound is a new one-way to hiding (O2H) lemma which
gives a tighter bound than previous O2H lemmas (Lemma 5). This comes at
the cost of limited applicability. O2H lemmas allow to bound the difference in
the success probability of an adversary when replacing its oracle function by a
similar function. Previous lemmas lost a factor of roughly the number of the
adversary’s queries to this oracle or its square-root. Our lemma does not incur
any such loss. On the downside, our lemma only applies if the reduction has
access to both oracle functions and if the functions only differ in one position.
See Table 1 for a comparison.

Some post-quantum schemes feature an inherent probability of decryption
failure, say δ > 0 . Such failures can be used in attacks, but they also complicate
security proofs. As a result, previous bounds typically contain a term q

√
δ which

is not known to be tight. However, most of the obstacles that arise in our CCA
security proof can be avoided by assuming that encryption with a particular
public key is injective (after derandomization). This is generally the case, even
for imperfectly-correct systems; see Appendix D for a rough analysis of LWE
schemes. In that case, the adversary’s advantage is limited to the probability that
it actually finds and submits a valid message that fails to decrypt. This means
that our bounds apply to deterministic but failure-prone systems like certain
earlier BIKE [ABB+19] variants6, but our result is limited by the assumption of
injectivity.

Until today several variants of the FO-transform were proposed. We consider
the four basic transforms U⊥, U⊥m, U

6⊥, U 6⊥m [HHK17] and, in addition, we study
U⊥m in the presence of key confirmation. The two most notable differences re-
side in the use of implicit rejection (U 6⊥, U 6⊥m) versus explicit rejection (U⊥, U⊥m),
and whether the derivation of the session key should depend on the ciphertext
(U⊥m, U

6⊥
m) or not (U⊥, U 6⊥). Another important decision is the use of key con-

firmation which we also partially analyze. We come to the following results.
Security with implicit rejection implies security with explicit rejection (Theo-
rem 3). The opposite holds if the scheme with explicit rejection also employs key
confirmation (Theorem 4). Moreover, security is independent of the decision if
the session key derivation depends on the ciphertext (Theorem 5).

Notation. We will use the following notation throughout the paper.

– For two sets X,Y , we write Y X to denote the set of functions from X to Y .

– Let H : X → Y be a (classical or quantum-accessible) random oracle. Then
we denote the programming of H at x ∈ X to some y ∈ Y as H[x→ y].

– Let A be an algorithm. If A has access to a classical (resp., quantum-
accessible) oracle H, we write AH and call A an oracle (resp., quantum
oracle) algorithm.

6 After this paper was submitted, the BIKE team has changed their encryption
schemes to be randomized

3



2 One-way to Hiding

ROM reductions typically simulate the random oracle in order to learn the adver-
sary’s queries. In the classical ROM, the adversary cannot learn any information
about H(x) without the simulator learning both x and H(x). In the QROM
things are not so simple, because measuring or otherwise recording the queries
might collapse the adversary’s quantum state and change its behavior. However,
under certain conditions the simulator can learn the queries using “One-way to
Hiding” (O2H) techniques going back to [Unr15]. We will use the O2H techniques
from [AHU19], and introduce a novel variant that allows for tighter results.

Consider two quantum-accessible oracles G,H : X → Y . The oracles do not
need to be random. Suppose that G and H differ only on some small set S ⊂ X,
meaning that ∀x /∈ S,G(x) = H(x). Let A be an oracle algorithm that takes
an input z and makes at most q queries to G or H. Possibly A makes them in
parallel. Therefore, suppose that the query depth, i.e., the maximum number of
sequential invocations of the oracle [AHU19], is at most d ≤ q. If AG(z) behaves
differently from AH(z), then the O2H techniques give a way for the simulator
to find some x ∈ S with probability dependent on d and q.

We will use the following three O2H lemmas.

– Lemma 1 (original O2H) is the most general: the simulator needs to provide
only G or H but it has the least probability of success.

– Lemma 3 (semiclassical O2H) has a greater probability of success, but re-
quires more from the simulator: for each query x, the simulator must be able
to recognize whether x ∈ S, and if not it must return G(x) = H(x).

– Lemma 5 (our new “double-sided” O2H) gives the best probability of success,
but it requires the simulator to evaluate both G and H in superposition. It
also can only extract x ∈ S if S has a single element. If S has many elements,
but the simulator knows a function f such that {f(x) : x ∈ S} has a single
element, then it can instead extract that element f(x).

We summarize the three variants of O2H as shown in Table 1. In all cases,
there are two oracles H and G that differ in some set S, and the simulator
outputs x ∈ S with some probability ξ. The lemma then shows an upper bound
on the difference between AH and AG as a function of Îľ.

Variant Lemma Ref Oracles differ Sim. must know Bound

Original Lem. 1 [AHU19] Arbitrary H or G 2d
√
Îľ

Semi-classical Lem. 3 [AHU19] Arbitrary S and (H\S or G\S) 2
√
dÎľ

Double-sided Lem. 5 this work One place H and G 2
√
Îľ

Table 1. Comparison of O2H variants

Arbitrary joint distribution. The O2H lemmas allow (G,H, S, z) to be random
with arbitrary joint distribution. This is stronger than (G,H, S, z) being arbi-
trary fixed objects, because the probabilities in the lemma include the choice of

4



(G,H, S, z) in addition to A’s coins and measurements. Also, the lemmas are
still true if the adversary consults other oracles which are also drawn from a
joint distribution with (G,H, S, z).

2.1 Original O2H

We begin with the original O2H which first appeared in [Unr15]. We use the
phrasing from [AHU19] as it is more general and more consistent with our other
lemmata.

Lemma 1 (One-way to hiding; [AHU19] Theorem 3). Let G,H : X → Y
be random functions, let z be a random value, and let S ⊂ X be a random set such
that ∀x /∈ S,G(x) = H(x). (G,H, S, z) may have arbitrary joint distribution.
Furthermore, let AH be a quantum oracle algorithm which queries H with depth
at most d. Let Ev be an arbitrary classical event. Define an oracle algorithm
BH(z) as follows: Pick i

$← {1, . . . , d}. Run AH(z) until just before its ith round
of queries to H. Measure all query input registers in the computational basis,
and output the set T of measurement outcomes. Let

Pleft := Pr[Ev : AH(z)], Pright := Pr[Ev : AG(z)],

Pguess := Pr[S ∩ T 6= ∅ : T ← BH(z)].

Then

|Pleft − Pright| ≤ 2d
√
Pguess and

∣∣∣√Pleft −
√
Pright

∣∣∣ ≤ 2d
√
Pguess.

The same result holds with BG(z) instead of BH(z) in the definition of Pguess.

From this lemma we conclude the following result for pseudo-random functions
(PRFs, see Definition 10). It intuitively states that a random oracle makes a
good PRF, even if the distinguisher is given full access to the random oracle in
addition to the PRF oracle.

Corollary 1 (PRF based on random oracle). Let H : (K × X) → Y be
a quantum-accessible random oracle. This function may be used as a quantum-
accessible PRF Fk(x) := H(k, x) with a key k

$← K. Suppose a PRF-adversary
A makes q queries to H at depth d, and any number of queries to Fk at any
depth. Then

AdvPRF
Fk

(A) ≤ 2
√
dq/|K|.

Proof. The adversary’s goal is to distinguish (Fk, H) from (F,H), where F is
an unrelated uniformly random function. This is the same as distinguishing
(F,H[(k, x)→ F (x)]) from (F,H), and the set of differences between these two
H-oracles is S := {k}×X. By Lemma 1, the distinguishing advantage is at most
2d
√
Pguess, where Pguess = Pr[∃(k′, x) ∈ Q : k′ = k], for a random round Q of

parallel queries made by AF,H .

5



Since AF,H has no information about k, and in expectation Q contains q/d
parallel queries, we have Pguess ≤ q/(d · |K|), so

AdvPRF
Fk

(A) ≤ 2d
√
q/(d ¡ |K|) = 2

√
dq/|K|

as claimed. ut

Note that Corollary 1 is the same as [SXY18] Lemma 2.2 and [XY19] Lemma 4,
except that it takes query depth into account.

2.2 Semi-classical O2H

We now move on to semi-classical O2H. Here B is defined in terms of punctured
oracles [AHU19], which measure whether the input is in a set S as defined next.

Definition 1 (Punctured oracle). Let H : X → Y be any function, and
S ⊂ X be a set. The oracle H\S (“H punctured by S”) takes as input a value
x. It first computes whether x ∈ S into an auxilliary qubit p, and measures p.
Then it runs H(x) and returns the result. Let Find be the event that any of the
measurements of p returns 1.

The event is called Find because if the simulator chooses to, it can immedi-
ately terminate the simulation and measure the value x ∈ S which caused the
event. The oracle is called “punctured” because if Find does not occur, H\S
returns a result independent of H’s outputs on S, as shown by the following
lemma.

Lemma 2 (Puncturing is effective; [AHU19] Lemma 1). Let G,H : X →
Y be random functions, let z be a random value, and let S ⊂ X be a random
set such that ∀x /∈ S,G(x) = H(x). (G,H, S, z) may have arbitrary joint distri-
bution. Let AH be a quantum oracle algorithm. Let Ev be an arbitrary classical
event. Then

Pr[Ev ∧ Find : AH\S(z)] = Pr[Ev ∧ Find : AG\S(z)].

Also, puncturing only disturbs the adversary’s state when it is likely to Find.

Lemma 3 (Semi-classical O2H; [AHU19] Theorem 1). Let G,H : X → Y
be random functions, let z be a random value, and let S ⊂ X be a random set such
that ∀x /∈ S,G(x) = H(x). (G,H, S, z) may have arbitrary joint distribution.

Let AH be a quantum oracle algorithm which queries H with depth at most
d. Let Ev be an arbitrary classical event and let

Pleft := Pr[Ev : AH(z)], Pright := Pr[Ev : AG(z)],

Pfind := Pr[Find : AG\S(z)]
Lem. 2

= Pr[Find : AH\S(z)].

Then

|Pleft − Pright| ≤ 2
√
dPfind and

∣∣∣√Pleft −
√
Pright

∣∣∣ ≤ 2
√
dPfind.

6



The theorem also holds with bound
√

(d+ 1)Pfind for the following alternative
definitions of Pright:

Pright := Pr[Ev : AH\S(z)]

Pright := Pr[Ev ∧ Find : AH\S(z)]
Lem. 2

= Pr[Ev ∧ Find : AG\S(z)]

Pright := Pr[Ev ∨ Find : AH\S(z)]
Lem. 2

= Pr[Ev ∨ Find : AG\S(z)]

We might expect that if the adversary has no information about S, then Pfind

would be at most q|S|/|X|. But this is not quite true: the disturbance caused by
puncturing gives the adversary information about S. This increases A’s chances,
but only by a factor of 4, as explained next.

Lemma 4 (Search in semi-classical oracle; [AHU19] Theorem 2). Let
H : X → Y be a random function, let z be a random value, and let S ⊂ X
be a random set. (H,S, z) may have arbitrary joint distribution. Let AH be a
quantum oracle algorithm which queries H at most q times with depth at most
d.

Let BH(z) and Pguess be defined as in Lemma 1. Then

Pr[Find : AH\S(z)] ≤ 4dPguess.

In particular, if for each x ∈ X, Pr[x ∈ S] ≤ ε (conditioned on z, on other
oracles A has access to, and on other outputs of H) then

Pr[Find : AH\S(z)] ≤ 4qε.

2.3 Double-sided O2H

We augment these lemmas with a new O2H lemma which achieves a tighter
bound focusing on a special case. This focus comes at the price of limited appli-
cability. Our lemma applies when the simulator can simulate both G and H. It
also requires that S is a single element; alternatively if some function f is known
such that f(S) is a single element, it can extract f(S).

Lemma 5 (Double-sided O2H). Let G,H : X → Y be random functions, let
z be a random value, and let S ⊂ X be a random set such that ∀x /∈ S,G(x) =
H(x). (G,H, S, z) may have arbitrary joint distribution. Let AH be a quantum
oracle algorithm. Let f : X →W ⊆ {0, 1}n be any function, and let f(S) denote
the image of S under f . Let Ev be an arbitrary classical event.

We will define another quantum oracle algorithm BG,H(z). This B runs in
about the same amount of time as A, but when A queries H, B queries both G
and H, and also runs f twice. Let

Pleft := Pr[Ev : AH(z)], Pright := Pr[Ev : AG(z)], Pextract := Pr[BG,H(z) ∈ f(S)].

7



IND-CPA
rPKE

OW-CPA
dPKE

Thm. 1

T
OW-CPA

FFC
dPKE

IND-CCA
KEM

Thm. 2

U 6⊥

δ-correct
rPKE

FFC
dPKE

Lem. 6

T

IND-CCA
KEM U⊥

IND-CCA
KEM U 6⊥

IND-CCA
KEM U⊥m

IND-CCA
KEM U 6⊥m

IND-CCA
KEM U⊥m+keyconf

Thm. 5

Thm. 5

Thm. 3
Thm. 4

Fig. 1. Relations of our security notions using transforms T and U 6⊥ (above) and
relations between the security of different types of U -constructions (below). The solid
lines show implications which are tight with respect to powers of q and/or d, and the
dashed line shows a non-tight implication. The hooked arrows indicate theorems with
Îľ-injectivity constraints.

If f(S) = {w∗} is a single element, then B will only return ⊥ or w∗, and
furthermore

|Pleft − Pright| ≤ 2
√
Pextract and

∣∣∣√Pleft −
√
Pright

∣∣∣ ≤ 2
√
Pextract.

Proof. See Appendix B.

Note that if S = {x∗} is already a single element, then we may take f as the
identity. In this case B will return either ⊥ or x∗.

3 KEM and PKE Security Proofs

We are now ready to get to the core of our work. All the relevant security notions
are given in Appendix A. The implications are summarized in Figure 1.

3.1 Derandomization: IND-CPA P
QROM⇒ OW-CPA T (P, G)

The T transform [HHK17] converts a rPKE P = (Keygen,Encr,Decr) to a dPKE
T (P, G) = (Keygen,Encr1,Decr) by using a hash function G :M→R, modeled
as random oracle, to choose encryption coins, where

Encr1(pk,m) := Encr(pk,m; G(m)).

The following theorem shows that if a PKE P is IND-CPA secure7, then T(P, G)
is one-way secure in the quantum-accessible random oracle model.

7 The theorem actually only requires a weaker notion, IND-KPA-security, in which the
challenge messages are chosen at random instead of adversarially.

8



Theorem 1. Let P be an rPKE with messages in M and random coins in R.
Let G : M→ R be a quantum-accessible random oracle. Let A be an OW-CPA
adversary against P′ := T (P, G). Suppose that A queries G at most q times with
depth at most d.

Then we can construct an IND-CPA adversary B against P, running in about
the same time and resources as A, such that

AdvOW-CPA
P′ (A) ≤ (d+ 2) ·

(
AdvIND-CPA

P (B) +
8(q + 1)

|M|

)
.

Proof. See Appendix C.

Second preimages. In the traditional definition of one-way functions, the adver-
sary wins by finding any m′ where Encr(pk,m′) = c∗, whereas in our definition
(cf. Definition 7) of OW-CPA the adversary must find m∗ itself. This only mat-
ters if there is a second preimage, and thus a decryption failure. If P is δ-correct
and Îľ-injective, it is easily shown that a definition allowing second preimages
adds at most min(δ, ε) to the adversary’s OW-CPA-advantage.

Hashing the public key. Many KEMs use a variant of T which sets the coins to
G(pk,m). This is a countermeasure against multi-key attacks. In this paper we
only model single-key security, so we omit pk from the hashes for brevity. The
same also applies to the other transforms later in this paper, such as U 6⊥.

3.2 Deterministic P: OW-CPA P
QROM⇒ IND-CCA U 6⊥(P, F,H)

Our OW-CPA to IND-CCA conversion is in the style of [JZM19d]. However, that
bound is based on the failure probability δ of a randomized encryption algorithm,
whereas ours is based on the difficulty of finding a failure without access to the
private key. This means our theorem applies to deterministic but imperfectly-
correct algorithms, such as one of the three BIKE variants, BIKE-2 [ABB+19].
So instead we use injectivity and a game where the adversary tries to find ci-
phertexts which are valid but do not decrypt correctly.

Definition 2 (Valid ciphertext). Let P = (Keygen,Encr, Decr) be a dPKE.
Call a ciphertext c “valid” for a public key pk of P if there exists m such that
c = Encr(pk,m).

We introduce a new failure-finding experiment8, to capture the probability
that the adversary can find valid ciphertexts that cause a decryption failure.

Definition 3 (Finding Failing Ciphertext). The find-failing-ciphertexts ex-
periment (FFC) is shown in Figure 2. The FFC-advantage of an adversary A is
defined by

AdvFFC
P (A) := Pr[ExptFFCP (A)→ 1].

9



ExptFFCP (A):

1 H
$← H

2 (pk, sk)← Keygen()
3 L← AH(pk)
4 return [∃m ∈M, c ∈ L : Encr(pk,m) = c ∧ Decr(sk, c) 6= m]

Fig. 2. FFC experiment on a dPKE P. The instantiation of H generalizes to any number
of random oracles, including zero.

The U 6⊥ transform [HHK17] converts a dPKE P = (KeygenP,Encr,Decr)
into a KEM K = (Keygen,Encaps,Decaps) using a PRF F : KF × C → K and a
hash function H :M×C → K, modeled as a random oracle. The PRF is used
for implicit rejection, returning F(prfk, c) in case of an invalid ciphertext using a
secret prfk. The U 6⊥ transform is defined in Figure 3. We also describe variants
U 6⊥m, U

⊥, U⊥m of this transform from [HHK17], which make the following changes:

– On Encaps line 3 resp. Decaps line 7, the transformations U 6⊥m and U⊥m com-
pute H(m) resp. H(m′) instead of H(m, c) resp. H(m′, c).

– On Decaps lines 4 and 6, the transformations U⊥ and U⊥m return ⊥ instead
of F(prfk, c). These variants also don’t need prfk as part of the private key.

The transforms U⊥ and U⊥m are said to use explicit rejection because they return
an explicit failure symbol ⊥. U 6⊥ and U 6⊥m are said to use implicit rejection.

Keygen():

1 (pk, skP)← KeygenP()

2 prfk
$← KF

3 sk← (skP, prfk)
4 return (pk, sk)

Encaps(pk):

1 m
$←M

2 c← Encr(pk,m)
3 K ← H(m, c)
4 return (K, c)

Decaps(sk, c):

1 parse sk = (skP,prfk)
2 m′ ← Decr(skP, c)
3 if m′ = ⊥:
4 return F(prfk, c)
5 else if Encr(pk,m′) 6= c:
6 return F(prfk, c)
7 else: return H(m′, c)

Fig. 3. Transform U 6⊥(P,F) := (Keygen,Encaps,Decaps).

The next theorem states that breaking the IND-CCA security of U 6⊥(P,F, H)
requires either breaking the OW-CPA security of P, causing a decapsulation
failure, or breaking the PRF used for implicit rejection. In particular, we need
P to be an Îľ-injective dPKE as in Definition 6.

8 It is a stretch to even call this an “experiment”, because it may not be possible to
efficiently determine whether the adversary succeeded. In future work we hope to
force the adversary to find failing message, but this version is simpler to integrate
into our proof.

10



Theorem 2. Let H :M×C → K be a quantum-accessible random oracle and F :
KF×C → K be a PRF. Let P be an ε-injective dPKE which is independent of H.
Let A be an IND-CCA adversary against the KEM U 6⊥(P,F), and suppose that A
makes at most qdec decryption queries. Then we can construct three adversaries
running in about the same time and resources as A:

– an OW-CPA-adversary B1 against P
– a FFC-adversary B2 against P, returning a list of at most qdec ciphertexts
– a PRF-adversary B3 against F

such that

AdvIND-CCA
U 6⊥(P) (A) ≤ 2

√
AdvOW-CPA

P (B1) + AdvFFC
P (B2) + 2 ¡AdvPRF

F (B3) + Îľ.

In the common case that F(prfk, c) is implemented as H(prfk, c) it holds that if
A makes q queries at depth d, then

AdvPRF
F (B3)

cor. 1
≤ 2

√
dq/|M |.

Proof. Our proof is by a series of games. In some later games, we will define an
outcome “draw” which is distinct from a win or loss. A draw counts as halfway
between a win and a loss, as described by the adversary’s score wi:

wi := Pr[A wins: Game i] +
1

2
Pr[Draw: Game i]

=
1

2
(1 + Pr[A wins: Game i]− Pr[A loses: Game i])

Game 0 (IND-CCA). This is the original IND-CCA game against the KEM
U 6⊥(P,F, H), cf. Definition 12.

Game 1 (PRF is random). Game 1 is the same as Game 0, except the

simulator replaces F(prfk, ¡) with a random function R
$← KC .

We construct a PRF-adversary B3 (cf. Definition 10) which replaces its calls to
F(prfk, ¡) by calls to its oracle, runs A, and outputs 1 if A wins and 0 oth-
erwise. Now, by construction Pr

k
$←K

[
BF(k,¡) = 1

]
= Pr[A wins: Game 0] and

Pr
R

$←KC

[
AR(¡) = 1

]
= Pr[A wins: Game 1]. Hence,

|w1 − w0| = AdvPRF
F (A).

Game 2 (Draw on fail or non-injective pk). Let Fail be the event that
one or more of A’s decapsulation queries D(c) fails to decrypt, meaning that
c = Encr(pk,m) for some m, but Decr(sk, c) 6= m. Let NonInj be the event that
Encr(pk, ¡) is not injective, and let Draw := Fail∨NonInj. In Game 2 and onward,
if Draw occurs then the game continues, but at the end it is a draw instead of
the adversary winning or losing.

11



Let di := Pr[Draw : Game i]. Then |w2 − w1| ≤ 1
2d2. It is important to note

that the event Draw is a well-defined classical event and does not depend on H,
even though the simulator might not be able to determine efficiently whether it
occurred.

Game 3 (Reprogram H(m, c) to R(c)). Game 3 is the same as Game 2, but
the simulator reprograms H(m, c) where c = Encr(pk,m) to return R(c).

This produces the same win and draw probabilities as Game 2 as explained next.
For each m, the value H(m,Encr(pk,m)) is changed to a uniformly, indepen-
dently random value, except when the game is already a draw:

– It is uniformly random because R is uniformly random.
– It is independent of H(m′, c) for m′ 6= m because Encr(pk, ·) is injective or

else the game is a draw.
– H calls R(c) only for valid ciphertexts c = Encr(pk,m′). On the other hand,

the decapsulation oracle only calls R(c′) for rejected ciphertexts c′, i.e. ones
where c′ 6= Encr(pk,Decr(sk, c′)). If a valid ciphertext has been rejected and
passed to R in this way, then Draw has occurred and the return value of R
does not affect wi or di.

Therefore w3 = w2 and d3 = d2.

Game 4 (Decapsulation oracle returns R(c)). Game 4 is the same as
Game 3, but the simulated decapsulation oracle simply returns R(c) for all ci-
phertexts other than the challenge (for which it still returns ⊥).

In fact, the decapsulation oracle was already doing this in Game 3: The original
decapsulation returns either H(m, c) with c = Encr(pk,m) or F(prfk, c), but
both of those have been reprogrammed to return R(c). Therefore w4 = w3 and
d4 = d3. As of this game, the simulator does not use the private key anymore.

Bound draw. We now want to upper bound the draw probability. Let B2 be
the algorithm which, given a public key pk, simulates Game 4 for A and outputs
a list L of all of A’s decapsulation queries. Then B2 is a FFC-adversary against P
which runs in about the same time as A and succeeds whenever a draw occured
during the game. Consequently,

d2 = d3 = d4 ≤ AdvFFC
P (B2) + Îľ.

Game 5 (Change shared secret). In Game 5, the shared secret is changed to
a uniformly random value r. If b = 1, then for all m such that Encr(pk,m) = c∗,
the oracle H(m) is reprogrammed to return r. If b = 0, then H is not repro-
grammed.

If Encr(pk, ¡) is injective, then this is the same distribution as Game 4, and
otherwise the game is a draw. Therefore w5 = w4.

It remains to bound A’s advantage in Game 5. The simulation still runs in
about the same time as A. Suppose at first that Encr(pk, ¡) is injective, so that

12



the oracle H is reprogrammed only at m∗. Then the b = 0 and b = 1 cases are
now distinguished by a single return value from the H oracle. Hence, we can
consider two oracles H and H ′ := H[m∗ → r] as required by Lemma 5. Then
Lemma 5, states that there is an algorithm B1, running in about the same time
as A, such that for all H:

|Pr[Win : b = 0]− Pr[Lose : b = 1]| =
∣∣∣∣ Pr[A → 0 ∧ ¬Draw : b = 0]
−Pr[A → 0 ∧ ¬Draw : b = 1]

∣∣∣∣
=

∣∣∣∣ Pr[AH → 0 ∧ ¬Draw]

−Pr[AH′ → 0 ∧ ¬Draw]

∣∣∣∣
≤ 2
√

Pr[B1(pk, c)→ m∗].

The same inequality holds if Encr(pk, ¡) is not injective, for then the game is
always a draw and the left-hand side is zero. (The algorithm B1 still runs with
the same efficiency in that case; it just might not return m∗.) The inequality
also holds in expectation over H by Jensen’s inequality:

E
[
2
√

Pr[B1(pk, c)→ m∗] : H
$← K(M×C)

]
≤ 2

√
E
[
Pr[B1(pk, c)→ m∗] : H

$← K(M×C)
]

= 2

√
AdvOW-CPA

P (B1)

so that

|Pr[Win : b = 0]− Pr[Lose : b = 1]| ≤ 2

√
AdvOW-CPA

P (B1).

Likewise, for the same adversary B1,

|Pr[Win : b = 1]− Pr[Lose : b = 0]| ≤ 2

√
AdvOW-CPA

P (B1).

Since b is either 0 or 1 each with probability 1
2 , we have by the triangle inequality:

|Pr[Win]− Pr[Lose]| ≤ 2

√
AdvOW-CPA

P (B1)

so that
∣∣w5 − 1

2

∣∣ ≤√AdvOW-CPA
P (B1).

Summing up the differences in the previous games, we have∣∣∣∣w0 −
1

2

∣∣∣∣ ≤√AdvOW-CPA
P (B1) +

1

2
AdvFFC

P (B2) +
Îľ

2
+ AdvPRF

F (B3)

and finally

AdvIND-CCA
U 6⊥(P) (A) ≤ 2

√
AdvOW-CPA

P (B1) + 2 ¡AdvPRF
F (B3) + AdvFFC

P (B2) + Îľ.

This completes the proof of Theorem 2. ut

13



Tightness. This bound is essentially tight, since breaking the one-wayness of P
and finding decryption failures are both known to result in attacks. Breaking the
PRF harms security if and only if implicit rejection is more secure than explicit
rejection. For a correct P the bound boils down to the first two terms of the
sum. The square-root loss arises from OW being a weaker security notion than
IND [MW18], i.e., harder to break, and recent results [JZM19b] suggest that the
square-root loss might be unavoidable in the quantum setting.

3.3 Decryption failures

When the dPKE is constructed by derandomizing an rPKE, we can also bound
the FFC advantage.

Lemma 6. Let P = (Keygen,Encr,Decr) be a δ-correct rPKE with messages
in M and randomness in R. Let G : M → R be a random oracle, so that
T (P, G) := (Keygen,Encr1,Decr) is a derandomized version of P. Suppose that
T (P, G) is Îľ-injective. Let A be a FFC adversary against T (P, G) which makes
at most q queries at depth d to G and returns a list of at most qdec ciphertexts.
Then

AdvFFC
T (P,G)(A) ≤ ((4d+ 1)δ +

√
3ξ) ¡ (q + qdec) + ξ.

Proof. See Appendix E.

Note that if Îľ is negligible, and if the adversary can recognize which ciphertexts
will fail, then this is a Grover bound.

4 Explicit rejection and key confirmation

We now turn to systems with explicit rejection or key confirmation. The next the-
orem shows that the transform U⊥ (with explicit rejection) never yields KEMs
that are more ";"""date"",""2019-09-20T18:35:19Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2019-09-20T18:35:19Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.16 (TeX Live 2015) kpathsea version 6.2.1""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2019-09-20T18:35:19Z""
""created"",""2019-09-20T18:35:19Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-09-20T18:35:19Z""
""resourceName"",""590.pdf""
""Author"",""""
""producer"",""pdfTeX-1.40.16""
""pdf:docinfo:producer"",""pdfTeX-1.40.16""
""pdf:unmappedUnicodeCharsPerPage"",""5"",""0"",""6"",""5"",""15"",""14"",""3"",""15"",""10"",""17"",""12"",""10"",""49"",""11"",""11"",""4"",""0"",""4"",""25"",""28"",""12"",""51"",""46"",""45"",""14"",""45"",""52"",""62"",""32"",""23""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2019-09-20T18:35:19Z""
""Last-Modified"",""2019-09-20T18:35:19Z""
""dcterms:modified"",""2019-09-20T18:35:19Z""
""title"",""""
""Last-Save-Date"",""2019-09-20T18:35:19Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2019-09-20T18:35:19Z""
""meta:save-date"",""2019-09-20T18:35:19Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.16 (TeX Live 2015) kpathsea version 6.2.1""
""Content-Length"",""507819""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""30""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""2150"",""2667"",""2569"",""2257"",""1792"",""1682"",""1685"",""1365"",""1901"",""1664"",""1615"",""2058"",""1182"",""1938"",""1708"",""2285"",""2812"",""1910"",""1664"",""1290"",""1560"",""1846"",""1545"",""1573"",""1615"",""1223"",""1480"",""1424"",""1606"",""1692""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-09-20T18:35:19Z""
";https://scholar.google.com/scholar?start=640&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094635-1059;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Distributed computing with permissioned blockchains and databases (Dagstuhl Seminar 19261);C Mohan, BC Ooi, G Vossen ; Dagstuhl Reports, 2019  drops.dagstuhl.de;;"… among them Hyperledger and R3. Moreover, a number of companies have released

Blockchain-as-a-Service (BaaS) platforms, including IBM, Oracle, Amazon, Baidu,

and Alibaba. Except where otherwise noted, content of …";Cité 1 fois;Les 4 versions;[PDF] dagstuhl.de;https://drops.dagstuhl.de/opus/volltexte/2019/11488/pdf/dagrep_v009_i006_p069_19261.pdf;"
Report from Dagstuhl Seminar 19261

Distributed Computing with Permissioned Blockchains and
Databases
Edited by
C. Mohan1, Beng Chin Ooi2, and Gottfried Vossen3

1 IBM Almaden Center – San Jose, US, cmohan@us.ibm.com
2 National University of Singapore, SG, ooibc@comp.nus.edu.sg
3 Universität Mßnster, DE, vossen@wi.uni-muenster.de

Abstract
This seminar report contains the motivation, abstracts, and findings of Dagstuhl Seminar 19261
Distributed Computing with Permissioned Blockchains and Databases which took place in late
June 2019. It brought together a very good mix of people from academia and industry as well
as from databases and related areas for which blockchain is a current topic and who are either
users or developers in that field.

Seminar June 23–28, 2019 – http://www.dagstuhl.de/19261
2012 ACM Subject Classification Information systems → Data management systems
Keywords and phrases Distributed database, blockchain, permissioned
Digital Object Identifier 10.4230/DagRep.9.6.69

1 Executive Summary

C. Mohan
Beng Chin Ooi
Gottfried Vossen

License Creative Commons BY 3.0 Unported license
Š C. Mohan, Beng Chin Ooi, and Gottfried Vossen

The topic of blockchains, and in particular that of permissioned blockchains, has rapidly
gained interest in both the industrial and the research communities in recent years. It
particularly pertains to situations where trust among several parties that are about to do
business together is difficult to establish (e.g., due to organizational, financial, or timing
reasons) or impossible to establish at all. A blockchain is a decentralized, distributed ledger
that consists of immutable blocks containing transactions that can be accessed by any party,
and that provides trust via replication over all nodes and an agreed-upon execution order of
the transactions. Of particular interest are permissioned blockchains in which the associated
parties are known and authenticated, yet still do not fully trust each other.

Many applications have shown interest in the concept of blockchains, since the situation
just described applies to many real-world scenarios, including (global) supply chains, the
Internet of Things, connected cars, manufacturing, banking, and healthcare. As a consequence,
a number of players in the IT industry work on a development of the technology, and several
consortia have been formed to advance the technology across industries, among them
Hyperledger and R3. Moreover, a number of companies have released Blockchain-as-a-Service
(BaaS) platforms, including IBM, Oracle, Amazon, Baidu, and Alibaba.

Except where otherwise noted, content of this report is licensed
under a Creative Commons BY 3.0 Unported license

Distributed Computing with Permissioned Blockchains and Databases, Dagstuhl Reports, Vol. 9, Issue 6, pp.
69–94
Editors: C. Mohan, Beng Chin Ooi, and Gottfried Vossen

Dagstuhl Reports
Schloss Dagstuhl – Leibniz-Zentrum für Informatik, Dagstuhl Publishing, Germany

http://www.dagstuhl.de/19261
http://dx.doi.org/10.4230/DagRep.9.6.69
http://creativecommons.org/licenses/by/3.0/
http://creativecommons.org/licenses/by/3.0/
http://creativecommons.org/licenses/by/3.0/
http://creativecommons.org/licenses/by/3.0/
http://www.dagstuhl.de/dagstuhl-reports/
http://www.dagstuhl.de


70 19261 – Distributed Computing with Permissioned Blockchains and Databases

The technology has many links into the database community; however, the situation is
basically like it was in the database area many years ago, when only a few systems had been
released but users were on their own to figure out how to use them effectively. As the seminar
has shown, many interesting issues remain to be solved, and there is a wide variety of aspects
and research issues currently under investigation. Of these, the following were discussed:

Blockchain scalability w.r.t. transaction throughput, one of the main roadblocks to
business adoption
Transaction ordering and endorsement, consensus of transaction commit
Adjustments to the Proof of Work (PoW) consensus mechanism, other optimizations to
consensus algorithms (e.g., Byzantine consensus) in the presence of transaction failures
and in light of scalability
Block validation
Languages for smart-contract specification (e.g., Sandcastle SQL and Solidity)
Amendments to Hyperledger Fabric, such as channels
Cross-chain swaps using hashed timelocks
Energy efficiency of blockchain applications

In addition, several participants reported on various working applications of blockchain
technology.



C. Mohan, Beng Chin Ooi, and Gottfried Vossen 71

2 Table of Contents

Executive Summary
C. Mohan, Beng Chin Ooi, and Gottfried Vossen . . . . . . . . . . . . . . . . . . . 69

Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

Topic Areas Discussed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

State of Public and Private Blockchains: Myths and Reality
C. Mohan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

Introduction to Hyperledger
Hart Montgomery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

Usages of Blockchain Technologies for Data Stores
Bernhard Mitschang . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

Privacy, Confidentiality, Cryptography, and Security Modelling in Permissioned
Blockchains
Hart Montgomery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

A Hybrid Blockchain Architecture for Enhancing Privacy and Accountability
Murat Kantarcioglu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

Sandcastle: a SQL Ethereum Smart Contract Language
Shahan Khatchadourian . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

Blockchained Event Store
Dennis Przytarski . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

ExpoDB Fabric: Efficient Transaction Processing in Byzantine Fault Tolerant
Environments
Mohammad Sadoghi Hamedani . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

CUB, a Consensus Unit-based Storage Scheme for Blockchain System
Lei Chen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

Beyond Consensus in Permissioned Ledgers: Experiences in Using BFT Replication
on DLTs
Alysson Neves Bessani . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

Red Belly Blockchain: Byzantine Consensus Is Back but Is It the Same?
Vincent Gramoli . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

Enhancing Performance, Scalability, and Confidentiality of Permissioned Blockchains
Divyakant Agrawal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

Hyperledger Fabric’s Read-Set Conflicts and Conflict-Free Replicated Datatypes
Hans-Arno Jacobsen and Pezhman Nasirifard . . . . . . . . . . . . . . . . . . . . . 83

FastFabric: Scaling Hyperledger Fabric to 20,000 Transactions per Second
Srinivasan Keshav . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

Blockchains and Distributed Databases, a Twin Study
PingCheng Ruan and Beng Chin Ooi . . . . . . . . . . . . . . . . . . . . . . . . . . 84

Optical Chips
Yong Tang . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

19261



72 19261 – Distributed Computing with Permissioned Blockchains and Databases

Minimizing Transaction Failures in Permissioned Blockchains
Jeeta Ann Chacko and Hans-Arno Jacobsen . . . . . . . . . . . . . . . . . . . . . . 85

Blockchain Goes Green? A Time Energy Performance Study of Blockchain on Low
Power Systems
Dumitrel Loghin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

Blockchain and New Economies
Feida Zhu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

Blockchain-based Cross-Site Genomic Dataset Access Audit
Li Xiong . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

Leveraging Decentralized, Secure and Governed Exchange of Confidential Informa-
tion with Permissioned Blockchain
Gabriela Ruberg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

Blockchain Empowered Drug Development Financing
Yong Tang . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

Turning a Vehicle Into an Economic Platform
Michael Huth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

Distributed Blockchain Systems across Distributed Data Centers
Dilip Krishnaswamy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

Atomic Cross Chain Swaps
Eric Lo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

Blockchain Analytics
Murat Kantarcioglu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

Blockchain and Open Source Governance
Juho Lindman . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

Findings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

General Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

More Blockchain Analytics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

Virtual Assets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

Areas for Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

Participants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94



C. Mohan, Beng Chin Ooi, and Gottfried Vossen 73

3 Motivation

A new era is emerging in the world of distributed computing with the growing popularity
of blockchains. Traditionally, the Internet allows to exchange only data or information
directly between two parties or users; a transaction, say, involving the purchase of an item
requires a third party which can be trusted. Third parties often come in the form of a
digital marketplace, a bank, or a trusted intermediary. Blockchains can eliminate third
parties, since they are characterized by transparency, i.e., the blockchain content is visible
to each participant, and being append-only, which is crucial for updating a blockchain.
Conceptually, a blockchain is a decentralized and distributed digital ledger that consists of
records representing transactions; since these records are tied to their history using hash
values no existing record can be altered retroactively. The only kind of update allowed is
to extend a given blockchain by additional records, which, assuming that the majority of
participants does not pursue a dishonest intention, results in a stable view on transactions
(which implies that not every party or node maintaining the blockchain needs to trust
everybody else). The participants can verify and audit transactions, which results in a
trustable workflow where participants’ uncertainty regarding data security is marginal. The
use of a blockchain also eliminates infinite reproducibility of digital assets; it confirms that
each unit of value was transferred only once.

By storing data across its network, the blockchain eliminates the risks that come with
data being held centrally, yet opens up for an application of distributed technology that
was previously developed in other contexts. Blockchains come in two flavors: An open,
permissionless, or public, blockchain network does not require any guarding against bad
actors, and no access control is needed; anybody can join and leave. Hence applications can
be added to the network without the approval or trust of others, using the blockchain as a
transport layer. Permissioned (private) blockchains are emerging as open source protocols
where openness and collaboration are encouraged among authenticated participants. They
can hence restrict who can participate in the consensus processes as well as who can transact.

From a database point of view, a blockchain can be considered as a log of ordered
transactions, since nodes keep replicas of the data and agree on an execution order of
the transactions. A key property is the assumption that nodes behave in an arbitrary or
Byzantine fashion. By being able to tolerate Byzantine failure by design, a blockchain
offers stronger security than a database system. Although enterprise-grade database systems
support applications like security trading and settlement, asset and finance management, or
banking and insurance, blockchain technology has the potential to disrupt the status quo since
they incur lower costs of infrastructure and human labor. In particular the immutability and
transparency of a blockchain reduce human error as well as the need for manual intervention
due to conflicting data.

While there is currently no standard in the blockchain space, all the ongoing efforts involve
some combination of database, transaction, encryption, consensus and other distributed
systems technologies. Some of the application areas in which blockchain pilots are being
carried out are: smart contracts, supply chain management, know your customer, derivatives
processing and provenance management. The seminar has surveyed some of the ongoing
blockchain projects with respect to their architectures in general and their approaches to
some specific technical areas. Its focus has been on how the functionality of traditional and
modern data stores are being utilized or not utilized in different blockchain projects.

19261



74 19261 – Distributed Computing with Permissioned Blockchains and Databases

4 Topic Areas Discussed

This section lists the abstracts of talks given, ordered by the topic areas to which they belong.

Goals and Current State-of-the-Art of Blockchain Technology and
Systems
4.1 State of Public and Private Blockchains: Myths and Reality
C. Mohan (IBM Almaden Center – San Jose, US)

License Creative Commons BY 3.0 Unported license
Š C. Mohan

It has been a decade since the concept of blockchain was invented as the underlying core
data structure of the permissionless or public Bitcoin cryptocurrency network. Since then,
several cryptocurrencies, tokens and ICOs have emerged. After much speculation and hype,
a significant number of them have become problematic or worthless! The public blockchain
system Ethereum emerged by generalizing the use of blockchains to manage any kind of
asset, be it physical or purely digital, with the introduction of Smart Contracts. Over the
years, numerous myths have developed with respect to the purported utility and the need for
public blockchains. The adoption and adaptation of blockchains and smart contracts for use
in the permissioned or private environments is what I consider to be useful and of practical
consequence. Hence, the technical aspects of only private blockchains will be the focus of
my talk. Along the way, I will bust many myths associated with public blockchains. I will
also compare traditional database techniques with blockchain systems’ features and identify
desirable future research topics.

References
1 C. Mohan. State of Public and Private Blockchains: Myths and Reality. Proc. ACM

SIGMOD International Conference on Management of Data, Amsterdam, July 2019.
http://bit.ly/sigBcP

2 C. Mohan. Permissioned/Private Blockchains and Databases. http://bit.ly/CMbcDB

4.2 Introduction to Hyperledger
Hart Montgomery (Fujitsu Labs of America Inc. – Sunnyvale, US)

License Creative Commons BY 3.0 Unported license
Š Hart Montgomery

In this talk, I introduced Hyperledger, explained its structure and governance, and showed
how to participate and contribute. Hyperledger is a “greenhouse” under the Linux foundation
for permissioned blockchains. It is currently the largest and most popular permissioned
blockchain project.

http://creativecommons.org/licenses/by/3.0/
http://creativecommons.org/licenses/by/3.0/
http://creativecommons.org/licenses/by/3.0/
http://creativecommons.org/licenses/by/3.0/


C. Mohan, Beng Chin Ooi, and Gottfried Vossen 75

4.3 Usages of Blockchain Technologies for Data Stores
Bernhard Mitschang (Universität Stuttgart, DE)

License Creative Commons BY 3.0 Unported license
Š Bernhard Mitschang

Currently, blockchain technologies are seen as the foundation of a new business world: it will
change the way the economy runs and thus will change the way we act and work, all triggered
by means of some new ways to organize the relevant application data, e.g., in the areas of
supply chain, health, and event storage. Blockchain technologies and systems are still in
constant change and development. Hence, it is difficult to exactly define its ingredients and
properties of the underlying technologies.

After having identified these technologies and associated characteristics (like transparency,
provenance, fault tolerance, immutability, and authenticity), it is important to isolate and
separate them into components that are subsequently used to enhance existing data stores
as needed. Important questions that arise in this context are:

How do certain Blockchain technologies and applications match?
How to identify and separate Blockchain technologies?
How to “append/integrate” Blockchain technologies to/with existing data stores?

Cryptography and Blockchain
4.4 Privacy, Confidentiality, Cryptography, and Security Modelling in

Permissioned Blockchains
Hart Montgomery (Fujitsu Labs of America Inc. – Sunnyvale, US)

License Creative Commons BY 3.0 Unported license
Š Hart Montgomery

Achieving desired privacy and confidentiality properties on a blockchain can be quite difficult.
This is especially true on permissioned blockchains, where it may be more difficult to hide
or anonymize identities than on a public blockchain. In this talk, I explained some of the
challenges that are commonly faced when attempting to achieve privacy and confidentiality
on permissioned blockchains and how to go about using existing tools to achieve these
properties.

One of the most important things when designing secure permissioned blockchains is
the need for security modelling. Many people today pick cryptographic tools, apply them
to blockchains, and then try to analyze the security properties that they get (if they even
do that). This isn’t a good idea for many reasons, but, in particular, it often means that
blockchains do not provide the security guarantees that people want on a blockchain. For
instance, even if transactions on the blockchain are encrypted or hashed, it could be the case
that traffic analysis completely reveals the participants in a transaction or even information
about the contents of transactions [5]. Intuitively, one might expect encryption might prevent
such leakage, but it turns out that other “side channel” information on the blockchain nullifies
some of the security properties of encryption.

Another very important discussion point was the notion of privacy and anonymity, and
the fact that the two aren’t equivalent. Many blockchain practitioners (both of the public
blockchain and permissioned blockchain kind) frequently equate the two, and many disastrous

19261

http://creativecommons.org/licenses/by/3.0/
http://creativecommons.org/licenses/by/3.0/
http://creativecommons.org/licenses/by/3.0/
http://creativecommons.org/licenses/by/3.0/


76 19261 – Distributed Computing with Permissioned Blockchains and Databases

consequences can happen from this. As an example, I showed my credit card history from
a week last year, which, if extended further, would easily deanonymize me. Solving this
issue on a blockchain is a difficult task, and blockchain builders may not want to provide
perfect privacy to their users (in some cases, functionality even demands imperfect privacy,
like when KYC regulations apply). However, blockchain implementers certainly need to take
into account privacy (and anonymity) into their security models when building blockchains.

We next discussed cryptographic tools that can be useful for obtaining various privacy
and confidentiality properties in blockchain. The first topic was threshold signatures, which
allow a cryptographic signing key to be split into n different shares such that any t out of the
n shares are required to create a valid signature (and any t – 1 shares cannot “do anything”)
[1]. We went through the security game of threshold signatures in detail, which illustrated
how one should look at a security game for a blockchain. We also briefly defined functional
encryption [3] and explained why it would be very useful for a blockchain.

The next technique discussed was “channels.” Channels, developed in Hyperledger Fabric
[2], are a tool intended to enable private transactions on blockchains. The idea is that each
channel acts as a private “sub-blockchain” for a limited number of participants, and that
people without permission do not have visibility into what is going on inside the channel.
While channels are a useful tool, they have not quite reached their full potential, so if they
are to be used to achieve strong privacy requirements, more development on top of them is
generally required.

The final technique we discussed was trusted execution environments (TEEs). Although
they have been much maligned recently in terms of their security properties [4], TEEs such as
Intel’s SGX offer many potential benefits for secure and private blockchains. It is possible to
essentially run blockchain nodes inside TEEs such that (assuming the TEEs are secure), even
the blockchain node hosts cannot see what the blockchain is doing. TEEs could potentially
give us very strong privacy and confidentiality options on blockchain if they can, in fact, be
built securely.

The talk ended with many questions. Overall, the goal was to expose what was mostly
an audience of researchers focused on databases to some of the privacy, security, and
confidentiality challenges present on blockchain today.

References
1 Boldyreva, Alexandra: Threshold signatures, multisignatures and blind signatures based

on the gap-Diffie-Hellman-group signature scheme; International Workshop on Public Key
Cryptography. Springer, Berlin, Heidelberg, 2003.

2 Androulaki, Elli, et al: Hyperledger fabric: a distributed operating system for permissioned
blockchains; Proceedings of the Thirteenth EuroSys Conference. ACM, 2018.

3 Boneh, Dan, Amit Sahai, and Brent Waters: Functional encryption: Definitions and chal-
lenges; Theory of Cryptography Conference. Springer, Berlin, Heidelberg, 2011.

4 Kocher, Paul, et al.: Spectre attacks: Exploiting speculative execution; arXiv preprint
arXiv:1801.01203 (2018).

5 Murdoch, Steven J., and George Danezis: Low-cost traffic analysis of Tor; 2005 IEEE
Symposium on Security and Privacy (S & P’05). IEEE, 2005.



C. Mohan, Beng Chin Ooi, and Gottfried Vossen 77

4.5 A Hybrid Blockchain Architecture for Enhancing Privacy and
Accountability

Murat Kantarcioglu (University of Texas – Dallas, US)

License Creative Commons BY 3.0 Unported license
Š Murat Kantarcioglu

Joint work of Murat Kantarcioglu, Harsh Desai, Lalana Kagal

Unfortunately, existing public blockchains and smart contracts deployed on them may
disclose sensitive information. Although there is some ongoing work that leverage advanced
cryptography to address some of these sensitive information leakage issues, they require
significant changes to existing and popular blockchains such as Ethereum and are usually
computationally expensive. On the other hand, private blockchains have been proposed
to allow more efficient and privacy-preserving data sharing among pre-approved group of
nodes/participants. Although private blockchains address some of the privacy challenges by
allowing sensitive data to be only seen by the select group of participants, they do not allow
public accountability of transactions since transactions are approved by known set of users,
and cannot be accessed publicly. Given these observations, one natural question that arise is,
can we leverage both public and private blockchain infrastructures to enable efficient, privacy
enhancing and accountable applications ? In this talk, we try to address this challenge in
the context of digital auctions.

Mainly, we discuss a novel hybrid blockchain architecture [1] that combines private and
public blockchains to allow sensitive bids to be opened on a private blockchain so that
only the auctioneer can learn the bids, and no one else. At the same time, we leverage
public blockchains to make the auction winner announcement, and payments accountable
[2]. Furthermore, using smart contracts deployed on public blockchain, we show how to
incentivize truthful behavior among the auction participants. Our extensive empirical results
show that this architecture is more efficient in terms of run time and monetary cost compared
to pure public blockchain based auction implementations.

References
1 Harsh Bimal Desai, Murat Kantarcioglu, and Lalana Kagal. A hybrid blockchain archi-

tecture for privacy-enabled and accountable auctions. In The 2019 IEEE International
Conference on Blockchain (Blockchain-2019), 2019.

2 Aravind Ramachandran and Murat Kantarcioglu. Smartprovenance: A distributed, block-
chain based dataprovenance system. In Proceedings of the Eighth ACM Conference on Data
and Application Security and Privacy, CODASPY 2018, Tempe, AZ, USA, March 19-21,
2018, pages 35–42, 2018.

Data Models
4.6 Sandcastle: a SQL Ethereum Smart Contract Language
Shahan Khatchadourian (ConsenSys – Toronto, CA)

License Creative Commons BY 3.0 Unported license
Š Shahan Khatchadourian

Enterprises rely on data management frameworks in order to serve their customer. However,
enterprises face challenges when integrating blockchains with existing enterprise stacks in a
way that makes it easy to query, understand, and transact across systems. Challenges arise

19261

http://creativecommons.org/licenses/by/3.0/
http://creativecommons.org/licenses/by/3.0/
http://creativecommons.org/licenses/by/3.0/
http://creativecommons.org/licenses/by/3.0/


78 19261 – Distributed Computing with Permissioned Blockchains and Databases

due to the complex composition of database and blockchain paradigms. As well, developers
face the challenge of writing smart contracts in a low-level language like Solidity, with a need
to understand concepts like decentralization, smart contracts, consensus and identity. This
leads to developers building adhoc, incongruent solutions at application or protocol layers.

We propose Sandcastle, a SQL Ethereum smart contract language that integrates enter-
prise data management. Sandcastle works on all Ethereum blockchains (without modification
or configuration), including public, private, permissioned, and permissionless networks. We
showcase Sandcastle’s relational features such as aggregation, triggers, functions, indexes,
and row-based semantics in finance, electronic medical records, and governance use cases.
We give architectural details, including the translation of Sandcastle SQL to Solidity. The
Sandcastle roadmap includes optimization in performance, cost, and security. Sandcastle
aims to help traditional enterprises build scalable, data-oriented blockchain platforms that
span databases, Ethereum 1.0, and Ethereum 2.0 stacks and networks.

4.7 Blockchained Event Store
Dennis Przytarski (Universität Stuttgart, DE)

License Creative Commons BY 3.0 Unported license
Š Dennis Przytarski

Consider different scenarios such as transportation/trucking and supply chain integrity. All
these scenarios have one commonality: different parties generate events that need to be
shared among themselves in an immutable and tamper-resistant manner. Because the stored
events are used for forecasts, reports, or further process optimizations, powerful querying
capabilities both on current and historical states are needed.

In general, the blockchain technology is suitable for these scenarios because it offers data
immutability and tamper-resistance. For typical blockchain systems that assume transferable
assets (i.e., transfer ownership of an object from one person to another person), the key-value
data model and a simple query engine to answer queries such as “is a particular transaction
included in a particular block” are sufficient enough.

As soon as either the data model or the query requirements increase, this basic blockchain
setup does not suffice anymore. Instead, powerful query and data model capabilities are
needed with immutability and tamper-resistance guaranteed. Therefore, I propose using
triples (entity, attribute, value) as simple but powerful and flexible data model.

I am currently working on embedding the triple data model into a blockchain architecture
with a powerful query engine. This will lead to an immutable, shared, tamper-resistant, and
queryable data store for events. I am currently facing the following challenges: Data Model:

How are changes to the data model done?
How is the data in the triple data model (tamper-resistant) stored?

Query Language and Processing:
How could the query language look like when there is a history to query?
How to process a query on immutable data in the triple data model?

http://creativecommons.org/licenses/by/3.0/
http://creativecommons.org/licenses/by/3.0/


C. Mohan, Beng Chin Ooi, and Gottfried Vossen 79

Consensus Protocols and Blockchain
4.8 ExpoDB Fabric: Efficient Transaction Processing in Byzantine

Fault Tolerant Environments
Mohammad Sadoghi Hamedani (University of California – Davis, US)

License Creative Commons BY 3.0 Unported license
Š Mohammad Sadoghi Hamedani

The byzantine fault-tolerance model, studied in ExpoDB Fabric [6, 4, 5, 3, 2, 1], captures a
wide-range of failures–common in real-world scenarios–such as ones due to malicious attacks
and arbitrary software/hardware errors. We propose Blockplane [2], a middleware that
enables making existing benign systems tolerate byzantine failures. This is done by making
the existing system use Blockplane for durability and as a communication infrastructure.
Blockplane proposes the following: (1) A middleware and communication infrastructure to
make an entire benign protocol byzantine fault-tolerant, (2) Ahierarchical locality-aware
design to minimize the number of wide-area messages, (3) A separation of fault-tolerance
concerns to enable designs with higher performance.

We further investigate a protocol-agnostic approach to improve the design of primary-
backup consensus protocols. At the core of our approach is a novel wait-free design of
running several instances of the underlying consensus protocol in parallel [3]. To yield
a high-performance parallelized design, we present coordination-free techniques to order
operations across parallel instances, deal with instance failures, and assign clients to specific
instances. Consequently, the design we present is able to reduce the load on individual
instances and primaries, while also reducing the adverse effects of any malicious replicas. Our
design is fine-tuned such that the instances coordinated by non-faulty replicas are wait-free:
they can continuously make consensus decisions, independent of the behavior of any other
instances.

We further develop DeltaBFT, a novel consensus protocol in which all algorithms necessary
for normal-case operation only require linear communication costs, even if replicas fail [5].
At the center of our design is the delayed-replication algorithm, an algorithm we propose
to reliably broadcast consensus decisions made by some non-faulty replicas to all replicas
without any coordination and with low communication cost for all replicas involved. The
delayed-replication algorithm is supported by our partial consensus algorithm, which uses
threshold signatures to efficiently make consensus decisions.

The development of fault-tolerant distributed systems that can tolerate Byzantine behavior
has traditionally been focused on consensus protocols, which support fully-replicated designs.
For the development of more sophisticated high-performance Byzantine distributed systems,
more specialized fault-tolerant communication primitives are necessary. As a result, we
identify an essential communication primitive and study it in depth. In specifics, we formalize
the cluster-sending problem [4], the problem of sending a message from one Byzantine
cluster to another Byzantine cluster in a reliable manner. We not only formalize this
fundamental problem, but also establish lower bounds on the complexity of this problem
under crash failures and Byzantine failures. Fu";"""date"",""2019-11-19T13:04:42Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2019-11-19T13:04:42Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.20 (TeX Live 2019) kpathsea version 6.3.1""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2019-11-19T13:04:42Z""
""created"",""2019-11-19T13:04:42Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-11-19T13:04:42Z""
""resourceName"",""dagrep_v009_i006_p069_19261.pdf""
""Author"",""""
""producer"",""pdfTeX-1.40.20""
""pdf:docinfo:producer"",""pdfTeX-1.40.20""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2019-11-19T13:04:42Z""
""Last-Modified"",""2019-11-19T13:04:42Z""
""dcterms:modified"",""2019-11-19T13:04:42Z""
""title"",""""
""Last-Save-Date"",""2019-11-19T13:04:42Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2019-11-19T13:04:42Z""
""meta:save-date"",""2019-11-19T13:04:42Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.20 (TeX Live 2019) kpathsea version 6.3.1""
""Content-Length"",""3645247""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""26""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""2528"",""1059"",""1968"",""1491"",""3317"",""1943"",""2651"",""2906"",""2640"",""2683"",""3081"",""2544"",""2419"",""3334"",""2598"",""2444"",""2767"",""2225"",""2824"",""2993"",""3009"",""2577"",""1978"",""2978"",""1630"",""1437""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-11-19T13:04:42Z""
";https://scholar.google.com/scholar?start=870&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094609-949;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Research on privacy enhancement scheme of blockchain transactions;T Feng, X Chen, C Liu, X Feng ; Security and Privacy, 2019  Wiley Online Library;;"… We assume that active attacker monitors all traffic on the network, and can control some malicious

peers on the blockchain to tamper addresses … During the polynomial time t, A performs the following

queries: Hash query: A can obtain access to hash oracle in the scheme and get …";Cité 3 fois;;[PDF] wiley.com;https://onlinelibrary.wiley.com/doi/pdfdirect/10.1002/spy2.89;;;https://scholar.google.com/scholar?start=760&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094534-629;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[PDF][PDF] Blockchain and the Law;CL Reyes, NM Rosario, RM Cannon… ; J. Marshall J. Info. Tech. & …, 2019  HeinOnline;;"… In addition, he teaches a class called ""Blockchain, Cryptocurrency + Law"" at the Illinois Tech

Chicago-Kent College of Law … My friends and I joke that once you learn about blockchain

technology and crypto, it's so interesting that it sort of just takes over your life, and …";Cité 1 fois;Les 3 versions;[PDF] heinonline.org;https://heinonline.org/hol-cgi-bin/get_pdf.cgi?handle=hein.journals/jmjcila34&section=3&casa_token=FR72u0pCITsAAAAA:tXnF0RmBntk28szGtHapjwk_tlMd2NiFa_4tl2yMv8bYFac809fBgPfSOrBBq6BMeyXUaFU;"

 ";"""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""REFRESH"",""1; url=https://heinonline.org/HOL/Page?handle=hein.journals/jmjcila34&div=3&g_sent=1&casa_token=FR72u0pCITsAAAAA:tXnF0RmBntk28szGtHapjwk_tlMd2NiFa_4tl2yMv8bYFac809fBgPfSOrBBq6BMeyXUaFU""
""Content-Encoding"",""UTF-8""
""resourceName"",""get_pdf.cgi""
""language"",""""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=440&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094590-861;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;A New Identification Scheme based on Syndrome Decoding Problem with Provable Security against Quantum Adversaries.;B Santoso, C Su ; J. UCS, 2019  jucs.org;;"… security proof is interesting in its own right, since it only requires a non-programmable quantum

random oracle, in contrast to existing security proofs of digital signatures generated from ID

scheme via Fiat-Shamir transform which require programmable quantum random oracles …";Autres articles;;null;;;;https://scholar.google.com/scholar?start=680&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094544-663;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;The Case for Ontologies in Expressing Decisions in Decentralized Energy Systems;S Sánchez;Alonso  Metadata and Semantic Research: 12th International …, 2019  Springer;;"… Some proposals for decentralized oracles (as Astraea [1]) are possibly providing solutions

to such problems in the near future … References 1. Adler, J., Berryhill, R., Veneris, A., Poulos,

Z., Veira, N., Kastania, A.: Astraea: A Decentralized Blockchain Oracle …";Autres articles;;null;;;;https://scholar.google.com/scholar?start=480&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094569-779;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Fintech: Digital Tokens.;UV Sridharan, V Sridharan… ; Journal of Strategic …, 2019  search.ebscohost.com;;"… IBM, American Express, Toyota, JP Morgan Chase, Goldman Sachs, Walt Disney, Oracle, and

Facebook have … The computer code used to create the blockchain network is open source code,

which … Bitcoin is a virtual currency, or cryptocurrency, which was created in 2009 as an …";Cité 1 fois;Les 2 versions;null;;;;https://scholar.google.com/scholar?start=590&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094576-807;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[HTML][HTML] An identity-based encryption technique using subtree for fuzzy user data sharing under cloud computing environment;C Meshram, CC Lee, SG Meshram, MK Khan ; Soft Computing, 2019  Springer;Germany;"… encryption systems. These schemes require no random oracles and are semantically

secure under the discrete logarithm problem supposition. Still, the speed is essentially

slower than that of ElGamal. Abe et al. (2010), specializing …";Cité 12 fois;Les 3 versions;[HTML] springer.com;https://idp.springer.com/authorize/casa?redirect_uri=https://link.springer.com/article/10.1007/s00500-019-03855-1&casa_token=RH5mBin__AAAAAAA:Od81Oja4PN1wY4f7ZxTCh_dl7HG1o8BNQXPWRYB18pwPuuiniGuzT18k7cWptTr34QShHcDleTYMD70;"
    
    
    
        
            
            
                
            

            
        
    


    
        
        

        
            
                Advertisement

                    

            

        


    
        
            
                
    
        
            
            [image: SpringerLink]
        
        
        
    


            

            
                
    
        
            
                Search
                
                    
                
            
        
        
            	
                    Log in
                


        
    

    



            

        

    

    
        
            
                
                    
                        
    
        Search SpringerLink
        
            
            
                Search
                
                    
                
            
            
                
            
            
        

    




                    

                

            

        

    



        

    
        
            

            
                
            


            
                
    

            



            
                
                    
                        	Methodologies and Application
	Published: 23 February 2019



                        
                        An identity-based encryption technique using subtree for fuzzy user data sharing under cloud computing environment

                        	Chandrashekhar Meshram1, 
	Cheng-Chi Lee2,3, 
	Sarita Gajbhiye Meshram1 & 
	Muhammad Khurram Khan4 


                        
                            
    Soft Computing

                            volume 23, pages13127–13138(2019)Cite this article
                        

                        
    

                        
                            
    
        	
                    197 Accesses

                
	
                    12 Citations

                
	
                Metrics details

            


    




                        

                            
    

    

                    
                


                
                    Abstract
The advancement of the cloud storage technology opens up a wide range of possibilities for adaptable data sharing. When sharing data to an extensive number of users with fuzzy identities, the data proprietor must use an appropriate identity-based encryption technique that satisfies both efficiency and security prerequisites. Identity-based encryption is a promising possibility to ensure fuzzy user data sharing while meeting the security essentials; however, it may encounter efficiency trouble in multi-receiver settings. Recently, identity-based encryption has received much attention, and most of the research has aimed to apply the technique in real-world systems. A major concern about using identity-based encryption is the safety of the private keys, as disclosure of secret keys requires the reissuing of encryptions already doled out. The capability to minimize the risks associated with key disclosure is particularly important due to the increased use of mobile and unprotected devices. In this article, we shall propose a forward-secure identity-based encryption technique based on subtree for fuzzy user data sharing under cloud computing environment, and we shall demonstrate that the technique is semantically secure against a chosen subtree and chosen ciphertext attack (IND-CST–CCA). In addition, we will show the superiority of our new technique over the currently existing methods in terms of security and the length of public key. Then, we will also discuss the potential of our new technique to be deployed in pay TV systems and grid security.



                    
    


                    
                        
                            
                                This is a preview of subscription content, access via your institution.

                            

                        
                        
                            
                                
 Access options

 
  Buy single article

  
   
    Instant access to the full article PDF.

   

   
    CHF 34,95

    Tax calculation will be finalised during checkout.

    
     
     
     
     
     
     
     
     
     
     
    

   

  

  
 
 
  
   
    Rent this article via DeepDyve.

   

  

  
 
 
  
   
    Learn more about Institutional subscriptions

   

  

 
 


                            

                        
                        
                            Fig. 1[image: ]



                        

                    

                    

                    

                    References
	Abe M, Cui Y, Imai H, Kiltz E (2010) Efficient hybrid encryption from ID-based encryption. Des Codes Cryptogr 54:205–240
MathSciNet 
    Article 
    
                    Google Scholar 
                

	Benasser A, Samsudin A (2010) A new identity based encryption (IBE) scheme using extended Chebyshev polynomial over finite fields Z. Phys Lett A 374(46):4670–4674
MathSciNet 
    Article 
    
                    Google Scholar 
                

	Boneh D, Boyen X (2004) Efficient selective-id secure identity based encryption without random oracles. In: Advances in cryptology-EUROCRYPT 2004, Lecture Notes in Computer Science, vol 3027. Springer, Berlin, pp 223–238

	Boneh D, Franklin MK (2001) Identity-based encryption from the weil pairing. In: Advances in cryptology-CRYPTO 2001, Lecture Notes in Computer Science, vol 2193. Springer, Berlin, pp 213–229

	Boneh D, Franklin MK (2003) Identity based encryption from the Weil pairing. SIAM J Comput 32(3):586–615
MathSciNet 
    Article 
    
                    Google Scholar 
                

	Boneh D, Canetti R, Halevi S, Katz J (2003) Chosen-ciphertext security from identity-based encryption. SIAM J Comput 36(5):1301–1328
MathSciNet 
    Article 
    
                    Google Scholar 
                

	Boneh D, Gentry C, Hamburg M (2008) Space-efficient identity based encryption without pairings. In: Proceedings of the 49th annual IEEE symposium on foundations of computer science, pp 647–657

	Cao N, Wang C, Li M, Ren K, Lou W (2014) Privacy-preserving multi-keyword ranked search over encrypted cloud data. IEEE Trans Parallel Distrib Syst 25(1):222–233
Article 
    
                    Google Scholar 
                

	Chen HC (2016) A trusted user-to-role and role-to-key access control scheme. Soft Comput 20(5):1721–1733
Article 
    
                    Google Scholar 
                

	Chen R, Mu Y, Yang G, Guo F, Wang X (2015) A new general framework for secure public key encryption with keyword search. In: 20th Australasian conference on information security and privacy (ACISP 2015), Brisbane, QLD, Australia, LNCS, vol 9144. Springer, Berlin

	Deng H, Wu Q, Qin B, Domingo-Ferrer J, Zhang L, Liu J, Shi W (2014) Ciphertext-policy hierarchical attribute-based encryption with short ciphertexts. Inf Sci 275:370–384
MathSciNet 
    Article 
    
                    Google Scholar 
                

	ElGmal T (1995) A public key cryptosystem and a signature scheme based on discrete logarithms. IEEE Trans Inf Theory 31:469–472
MathSciNet 
    Article 
    
                    Google Scholar 
                

	Fang L, Susilo W, Ge C, Wang J (2013) Public key encryption with keyword search secure against keyword guessing attack without random oracle. Inf Sci 238:221–241
MathSciNet 
    Article 
    
                    Google Scholar 
                

	Fujisaki E, Okamoto T (1999) Secure integration of asymmetric and symmetric encryption schemes. In: Advances in Cryptology-Crypto’99, Lecture Notes in Computer Science, vol 1666. Springer, Berlin, pp 537–554

	Galindo D (2004) The exact security of pairing based encryption and signature schemes. Working Draft, November 1, 2004. http://www.cs.ru.nl/dgalindo/galindoEcrypt.pdf. Accessed 3–5 Nov 2004

	Galindo D (2015) Compact hierarchical identity-based encryption based on a harder decisional problem. Int J Comput Math 92(3):463–472
MathSciNet 
    Article 
    
                    Google Scholar 
                

	Gentry C, Silverberg A (2002) Hierarchical id-based cryptography. In: ASIACRYPT 2002, LNCS, vol 2501. Springer, Berlin, pp 548–566

	Heng S, Kurosawa K (2004) k-Resilient identity-based encryption in the standard model. In: Topics in Cryptology- CT-RSA 2004, Lecture Notes in Computer Science, vol 2964. Springer, Berlin, pp 67–80

	Heng S, Kurosawa K (2006) k-Resilient identity-based encryption in the standard model. IEICE Trans Fundam E89CA(1):39–46
Article 
    
                    Google Scholar 
                

	Huang X, Liu JK, Hua S, Xiang Y, Liang K, Zhou J (2015) Cost-effective authentic and anonymous data sharing with forward security. IEEE Trans Comput 64(4):971–983
MathSciNet 
    Article 
    
                    Google Scholar 
                

	Katz J, MacKenzie P, Taban G, Gligor V (2012) Two-server password-only authenticated key exchange. J Comput Syst Sci 78(2):651–669
MathSciNet 
    Article 
    
                    Google Scholar 
                

	Liu C, Zhu L, Wang M, Tan Y (2014) Search pattern leakage in searchable encryption: attacks and new construction. Inf Sci 265:176–188
Article 
    
                    Google Scholar 
                

	Liu W, Liu J, Wu Q, Qin B, Naccache D, Ferradi H (2017) Efficient subtree-based encryption for fuzzy-entity data sharing. Soft Comput. https://doi.org/10.1007/s00500-017-2743-z
                        
Article 
    MATH 
    
                    Google Scholar 
                

	Luo S, Shen Q, Jin Y, Chen Y (2011) A variant of Boyen–Waters anonymous IBE scheme. In: Lecture Notes in Computer Sciences, vol 7043, pp 42–56

	Ma S (2016) Identity-based encryption with outsourced equality test in cloud computing. Inf Sci 328:389–402
Article 
    
                    Google Scholar 
                

	Mao Y, Li J, Chen MR, Liu J, Xie C, Zhan Y (2016) Fully secure fuzzy identity-based encryption for secure IoT communications. Comput Stand Interfaces 44:117–121
Article 
    
                    Google Scholar 
                

	Meshram C (2015) An efficient ID-based cryptographic encryption based on discrete logarithm problem and integer factorization problem. Inf Process Lett 115(2):351–358
MathSciNet 
    Article 
    
                    Google Scholar 
                

	Meshram C, Meshram S (2011) An identity based beta cryptosystem. In: IEEE proceedings of 7th international conference on information assurance and security (IAS 2011) Dec 5–8, pp 298–303

	Meshram C, Meshram S (2013) An identity-based cryptographic model for discrete logarithm and integer factoring based cryptosystem. Inf Process Lett 113(10–11):375–380
MathSciNet 
    Article 
    
                    Google Scholar 
                

	Meshram C, Meshram SA (2017) Constructing new an ID-based cryptosystem for IFP and GDLP based cryptosystem. J Discrete Math Sci Cryptogr 20(5):1121–1134
MathSciNet 
    Article 
    
                    Google Scholar 
                

	Meshram C, Obaidat MS (2015) An ID-based quadratic-exponentiation randomized cryptographic scheme. In: IEEE proceeding of international conference on computer, information and telecommunication systems, (2015), pp 1–5

	Meshram C, Powar PL (2016) An efficient identity-based QER cryptographic scheme. Complex Intell Syst 2(4):285–291
Article 
    
                    Google Scholar 
                

	Meshram C, Meshram S, Zhang M (2012a) An ID-based cryptographic mechanisms based on GDLP and IFP. Inf Process Lett 112(19):753–758
MathSciNet 
    Article 
    
                    Google Scholar 
                

	Meshram C, Huang X, Meshram S (2012b) New Identity-based cryptographic scheme for IFP and DLP based cryptosystem. Int J Pure Appl Math 81(1):65–79
MATH 
    
                    Google Scholar 
                

	Meshram C, Powar PL, Obaidat MS, Lee CC (2016) An IBE technique using partial discrete logarithm. Procedia Comput Sci 93:735–741
Article 
    
                    Google Scholar 
                

	Meshram C, Tseng YM, Lee CC, Meshram SG (2017a) An IND-ID-CPA secure ID-based cryptographic protocol using GDLP and IFP. Informatica 28(3):471–484
MathSciNet 
    Article 
    
                    Google Scholar 
                

	Meshram C, Lee CC, Li CT, Chen CL (2017b) A secure key authentication scheme for cryptosystems based on GDLP and IFP. Soft Comput 21(24):7285–7291
Article 
    
                    Google Scholar 
                

	Meshram C, Lee CC, Meshram SG, Li CT (2018a) An efficient ID-based cryptographic transformation model for extended chaotic-map-based cryptosystem. Soft Comput. https://doi.org/10.1007/s00500-018-3332-5
                        
Article 
    MATH 
    
                    Google Scholar 
                

	Meshram C, Li CT, Meshram SG (2018b) An efficient online/offline ID-based short signature procedure using extended chaotic maps. Soft Comput. https://doi.org/10.1007/s00500-018-3112-2
                        
Article 
    MATH 
    
                    Google Scholar 
                

	Meshram C, Obaidat MS, Meshram SG (2018c) Chebyshev chaotic maps based ID-based cryptographic model using subtree and fuzzy-entity data sharing for public key cryptography. Secur Priv 1(1):e12
Article 
    
                    Google Scholar 
                

	Meshram C, Powar PL, Obaidat MS, Lee CC, Meshram SG (2018d) Efficient online/offline IBSS protocol using partial discrete logarithm for WSNs. IET Netw 7(6):363–367
Article 
    
                    Google Scholar 
                

	Orencik C, Selcuk A, Savas E, Kantarcioglu M (2016) Multi-keyword search over encrypted data with scoring and search pattern obfuscation. Int J Inf Secur 15(3):251–269
Article 
    
                    Google Scholar 
                

	Shamir A (1984) Identity-based cryptosystems and signature schemes. In: Proceedings of CRYPTO’84, Lecture Notes in Computer Science, vol 196, pp 47–53

	Sun W, Lou W, Hou Y, Li H (2014) Privacy-preserving keyword search over encrypted data in cloud computing. Secur Cloud Comput (Springer, Berlin) 2014:189–212
Article 
    
                    Google Scholar 
                

	Tsujii S, Itoh T (1989) An ID-based cryptosystem based on the discrete logarithm problem. IEEE J Sel Areas Commun 7:467–473
Article 
    
                    Google Scholar 
                

	Waters B (2005) Efficient identity-based encryption without random oracles. In: Advances in cryptology-CRYPTO 2005, Lecture Notes in Computer Science. Springer, Berlin, pp 114–127

	Xu P, Cui G, Lei F (2008) An efficient and provably secure IBE scheme without bilinear map. J Comput Res Dev 45(10):1687–1695

                    Google Scholar 
                

	Xu P, Cui G, Fu C, Tang X (2010) A more efficient accountable authority IBE scheme under the DL assumption. Sci China 53(3):581–592
MathSciNet 
    Article 
    
                    Google Scholar 
                

	Xu P, Jin H, Wu Q, Wang W (2013) Public-key encryption with fuzzy keyword search: a provably secure scheme under keyword guessing attack. IEEE Trans Comput 62:2266–2277
MathSciNet 
    Article 
    
                    Google Scholar 
                

	Yang X, Wu L, Zhang M, Wei P, Wei L (2011) An ideal lattice based IBE scheme in the standard model. Wuhan Univ J Nat Sci 16(5):439–446
MathSciNet 
    Article 
    
                    Google Scholar 
                

	Yu Y, Ni J, Yang H, Mu Y, Susilo W (2014) Efficient public key encryption with revocable keyword search. Secur Commun Netw 7(2):466–472
Article 
    
                    Google Scholar 
                

	Zhang L, Wu Q, Domingo-Ferrer J, Qin B, Zeng P (2014) Signatures in hierarchical certificateless cryptography: efficient constructions and provable security. Inf Sci 272:223–237
MathSciNet 
    Article 
    
                    Google Scholar 
                

	Zheng M, Xiang Y, Zhou H (2015) A strong provably secure IBE scheme without bilinear map. J Comput Syst Sci 81:125–131
MathSciNet 
    Article 
    
                    Google Scholar 
                


Download references




Acknowledgements
The authors would like to thank anonymous reviewers of soft computing for their careful and helpful comments.


Author information
Affiliations
	Department of Mathematics and Computer Science, Rani Durgavati University, Jabalpur, M.P., India
Chandrashekhar Meshram & Sarita Gajbhiye Meshram

	Department of Library and Information Science, Fu Jen Catholic University, New Taipei, 24205, Taiwan, ROC
Cheng-Chi Lee

	Department of Photonics and Communication Engineering, Asia University, Wufeng Shiang, Taichung, 413, Taiwan, ROC
Cheng-Chi Lee

	Center of Excellence in Information Assurance, King Saud University, Riyadh, Saudi Arabia
Muhammad Khurram Khan


Authors	Chandrashekhar MeshramView author publications
You can also search for this author in
                        PubMed Google Scholar



	Cheng-Chi LeeView author publications
You can also search for this author in
                        PubMed Google Scholar



	Sarita Gajbhiye MeshramView author publications
You can also search for this author in
                        PubMed Google Scholar



	Muhammad Khurram KhanView author publications
You can also search for this author in
                        PubMed Google Scholar





Corresponding author
Correspondence to
                Cheng-Chi Lee.


Ethics declarations

              
              
                Conflict of interest

                The authors declare that they have no conflict of interest.

              
              
                Ethical approval

                This article does not contain any studies with human participants or animals performed by any of the authors.

              
            

Additional information
Publisher’s Note
Springer Nature remains neutral with regard to jurisdictional claims in published maps and institutional affiliations.
Communicated by V. Loia.


Rights and permissions
Reprints and Permissions


About this article
[image: Verify currency and authenticity via CrossMark]       


Cite this article
Meshram, C., Lee, CC., Meshram, S.G. et al. An identity-based encryption technique using subtree for fuzzy user data sharing under cloud computing environment.
                    Soft Comput 23, 13127–13138 (2019). https://doi.org/10.1007/s00500-019-03855-1
Download citation
	Published: 23 February 2019

	Issue Date: December 2019

	DOI: https://doi.org/10.1007/s00500-019-03855-1



Keywords
	Identity-based encryption
	Cloud storage
	Subtree
	Bilinear pairings
	Random oracle
	Pay TV system
	Grid security







                

            
        

        
            
                
                    
                


                
                    
    

                


                
                    
                


                
                    
                        
                            
                                
 Access options

 
  Buy single article

  
   
    Instant access to the full article PDF.

   

   
    CHF 34,95

    Tax calculation will be finalised during checkout.

    
     
     
     
     
     
     
     
     
     
     
    

   

  

  
 
 
  
   
    Rent this article via DeepDyve.

   

  

  
 
 
  
   
    Learn more about Institutional subscriptions

   

  

 
 


                            

                        

                        
                            
    
        
            Advertisement

            

        

    



                        

                        

                        

                    

                

            
        

    


    
    

    
        
    


        
    
        
            
                Over 10 million scientific documents at your fingertips

                
                    
                        Switch Edition
                        	
                                Academic Edition
                            
	
                                Corporate Edition
                            


                    

                
            

        

        
            	Home
	Impressum
	Legal information
	Privacy statement
	California Privacy Statement
	How we use cookies
	Manage cookies/Do not sell my data
	Accessibility
	Contact us


            
    
        
            Not logged in
             - 83.76.85.89
        

        
            Not affiliated
        


    



            
                Springer Nature
                
                    
                    
                
            
            Š 2021 Springer Nature Switzerland AG. Part of Springer Nature.

            
        

        
    
        
            
        
        
            
        
        
            
        
        
            
        
        
            
        
        
            
        
        
            \
        
        
            
        
    

    



    

    
    
";"""dc.publisher"",""Springer""
""og:image"",""https://media.springernature.com/w200/springer-static/cover/journal/500.jpg""
""twitter:card"",""summary""
""og:site_name"",""Soft Computing""
""citation_reference"",""citation_journal_title=Des Codes Cryptogr; citation_title=Efficient hybrid encryption from ID-based encryption; citation_author=M Abe, Y Cui, H Imai, E Kiltz; citation_volume=54; citation_publication_date=2010; citation_pages=205-240; citation_doi=10.1007/s10623-009-9320-0; citation_id=CR1"",""citation_journal_title=Phys Lett A; citation_title=A new identity based encryption (IBE) scheme using extended Chebyshev polynomial over finite fields Z; citation_author=A Benasser, A Samsudin; citation_volume=374; citation_issue=46; citation_publication_date=2010; citation_pages=4670-4674; citation_doi=10.1016/j.physleta.2010.09.041; citation_id=CR2"",""Boneh D, Boyen X (2004) Efficient selective-id secure identity based encryption without random oracles. In: Advances in cryptology-EUROCRYPT 2004, Lecture Notes in Computer Science, vol 3027. Springer, Berlin, pp 223–238"",""Boneh D, Franklin MK (2001) Identity-based encryption from the weil pairing. In: Advances in cryptology-CRYPTO 2001, Lecture Notes in Computer Science, vol 2193. Springer, Berlin, pp 213–229"",""citation_journal_title=SIAM J Comput; citation_title=Identity based encryption from the Weil pairing; citation_author=D Boneh, MK Franklin; citation_volume=32; citation_issue=3; citation_publication_date=2003; citation_pages=586-615; citation_doi=10.1137/S0097539701398521; citation_id=CR5"",""citation_journal_title=SIAM J Comput; citation_title=Chosen-ciphertext security from identity-based encryption; citation_author=D Boneh, R Canetti, S Halevi, J Katz; citation_volume=36; citation_issue=5; citation_publication_date=2003; citation_pages=1301-1328; citation_doi=10.1137/S009753970544713X; citation_id=CR6"",""Boneh D, Gentry C, Hamburg M (2008) Space-efficient identity based encryption without pairings. In: Proceedings of the 49th annual IEEE symposium on foundations of computer science, pp 647–657"",""citation_journal_title=IEEE Trans Parallel Distrib Syst; citation_title=Privacy-preserving multi-keyword ranked search over encrypted cloud data; citation_author=N Cao, C Wang, M Li, K Ren, W Lou; citation_volume=25; citation_issue=1; citation_publication_date=2014; citation_pages=222-233; citation_doi=10.1109/TPDS.2013.45; citation_id=CR8"",""citation_journal_title=Soft Comput; citation_title=A trusted user-to-role and role-to-key access control scheme; citation_author=HC Chen; citation_volume=20; citation_issue=5; citation_publication_date=2016; citation_pages=1721-1733; citation_doi=10.1007/s00500-015-1715-4; citation_id=CR9"",""Chen R, Mu Y, Yang G, Guo F, Wang X (2015) A new general framework for secure public key encryption with keyword search. In: 20th Australasian conference on information security and privacy (ACISP 2015), Brisbane, QLD, Australia, LNCS, vol 9144. Springer, Berlin"",""citation_journal_title=Inf Sci; citation_title=Ciphertext-policy hierarchical attribute-based encryption with short ciphertexts; citation_author=H Deng, Q Wu, B Qin, J Domingo-Ferrer, L Zhang, J Liu, W Shi; citation_volume=275; citation_publication_date=2014; citation_pages=370-384; citation_doi=10.1016/j.ins.2014.01.035; citation_id=CR11"",""citation_journal_title=IEEE Trans Inf Theory; citation_title=A public key cryptosystem and a signature scheme based on discrete logarithms; citation_author=T ElGmal; citation_volume=31; citation_publication_date=1995; citation_pages=469-472; citation_doi=10.1109/TIT.1985.1057074; citation_id=CR12"",""citation_journal_title=Inf Sci; citation_title=Public key encryption with keyword search secure against keyword guessing attack without random oracle; citation_author=L Fang, W Susilo, C Ge, J Wang; citation_volume=238; citation_publication_date=2013; citation_pages=221-241; citation_doi=10.1016/j.ins.2013.03.008; citation_id=CR13"",""Fujisaki E, Okamoto T (1999) Secure integration of asymmetric and symmetric encryption schemes. In: Advances in Cryptology-Crypto’99, Lecture Notes in Computer Science, vol 1666. Springer, Berlin, pp 537–554"",""Galindo D (2004) The exact security of pairing based encryption and signature schemes. Working Draft, November 1, 2004.                      http://www.cs.ru.nl/dgalindo/galindoEcrypt.pdf                                        . Accessed 3–5 Nov 2004"",""citation_journal_title=Int J Comput Math; citation_title=Compact hierarchical identity-based encryption based on a harder decisional problem; citation_author=D Galindo; citation_volume=92; citation_issue=3; citation_publication_date=2015; citation_pages=463-472; citation_doi=10.1080/00207160.2014.912278; citation_id=CR16"",""Gentry C, Silverberg A (2002) Hierarchical id-based cryptography. In: ASIACRYPT 2002, LNCS, vol 2501. Springer, Berlin, pp 548–566"",""Heng S, Kurosawa K (2004) k-Resilient identity-based encryption in the standard model. In: Topics in Cryptology- CT-RSA 2004, Lecture Notes in Computer Science, vol 2964. Springer, Berlin, pp 67–80"",""citation_journal_title=IEICE Trans Fundam; citation_title=k-Resilient identity-based encryption in the standard model; citation_author=S Heng, K Kurosawa; citation_volume=E89CA; citation_issue=1; citation_publication_date=2006; citation_pages=39-46; citation_doi=10.1093/ietfec/e89-a.1.39; citation_id=CR19"",""citation_journal_title=IEEE Trans Comput; citation_title=Cost-effective authentic and anonymous data sharing with forward security; citation_author=X Huang, JK Liu, S Hua, Y Xiang, K Liang, J Zhou; citation_volume=64; citation_issue=4; citation_publication_date=2015; citation_pages=971-983; citation_doi=10.1109/TC.2014.2315619; citation_id=CR20"",""citation_journal_title=J Comput Syst Sci; citation_title=Two-server password-only authenticated key exchange; citation_author=J Katz, P MacKenzie, G Taban, V Gligor; citation_volume=78; citation_issue=2; citation_publication_date=2012; citation_pages=651-669; citation_doi=10.1016/j.jcss.2011.09.005; citation_id=CR21"",""citation_journal_title=Inf Sci; citation_title=Search pattern leakage in searchable encryption: attacks and new construction; citation_author=C Liu, L Zhu, M Wang, Y Tan; citation_volume=265; citation_publication_date=2014; citation_pages=176-188; citation_doi=10.1016/j.ins.2013.11.021; citation_id=CR22"",""citation_journal_title=Soft Comput; citation_title=Efficient subtree-based encryption for fuzzy-entity data sharing; citation_author=W Liu, J Liu, Q Wu, B Qin, D Naccache, H Ferradi; citation_publication_date=2017; citation_doi=10.1007/s00500-017-2743-z; citation_id=CR23"",""Luo S, Shen Q, Jin Y, Chen Y (2011) A variant of Boyen–Waters anonymous IBE scheme. In: Lecture Notes in Computer Sciences, vol 7043, pp 42–56"",""citation_journal_title=Inf Sci; citation_title=Identity-based encryption with outsourced equality test in cloud computing; citation_author=S Ma; citation_volume=328; citation_publication_date=2016; citation_pages=389-402; citation_doi=10.1016/j.ins.2015.08.053; citation_id=CR25"",""citation_journal_title=Comput Stand Interfaces; citation_title=Fully secure fuzzy identity-based encryption for secure IoT communications; citation_author=Y Mao, J Li, MR Chen, J Liu, C Xie, Y Zhan; citation_volume=44; citation_publication_date=2016; citation_pages=117-121; citation_doi=10.1016/j.csi.2015.06.007; citation_id=CR26"",""citation_journal_title=Inf Process Lett; citation_title=An efficient ID-based cryptographic encryption based on discrete logarithm problem and integer factorization problem; citation_author=C Meshram; citation_volume=115; citation_issue=2; citation_publication_date=2015; citation_pages=351-358; citation_doi=10.1016/j.ipl.2014.10.007; citation_id=CR27"",""Meshram C, Meshram S (2011) An identity based beta cryptosystem. In: IEEE proceedings of 7th international conference on information assurance and security (IAS 2011) Dec 5–8, pp 298–303"",""citation_journal_title=Inf Process Lett; citation_title=An identity-based cryptographic model for discrete logarithm and integer factoring based cryptosystem; citation_author=C Meshram, S Meshram; citation_volume=113; citation_issue=10–11; citation_publication_date=2013; citation_pages=375-380; citation_doi=10.1016/j.ipl.2013.02.009; citation_id=CR28"",""citation_journal_title=J Discrete Math Sci Cryptogr; citation_title=Constructing new an ID-based cryptosystem for IFP and GDLP based cryptosystem; citation_author=C Meshram, SA Meshram; citation_volume=20; citation_issue=5; citation_publication_date=2017; citation_pages=1121-1134; citation_doi=10.1080/09720529.2015.1032621; citation_id=CR29"",""Meshram C, Obaidat MS (2015) An ID-based quadratic-exponentiation randomized cryptographic scheme. In: IEEE proceeding of international conference on computer, information and telecommunication systems, (2015), pp 1–5"",""citation_journal_title=Complex Intell Syst; citation_title=An efficient identity-based QER cryptographic scheme; citation_author=C Meshram, PL Powar; citation_volume=2; citation_issue=4; citation_publication_date=2016; citation_pages=285-291; citation_doi=10.1007/s40747-016-0030-8; citation_id=CR31"",""citation_journal_title=Inf Process Lett; citation_title=An ID-based cryptographic mechanisms based on GDLP and IFP; citation_author=C Meshram, S Meshram, M Zhang; citation_volume=112; citation_issue=19; citation_publication_date=2012; citation_pages=753-758; citation_doi=10.1016/j.ipl.2012.06.018; citation_id=CR32"",""citation_journal_title=Int J Pure Appl Math; citation_title=New Identity-based cryptographic scheme for IFP and DLP based cryptosystem; citation_author=C Meshram, X Huang, S Meshram; citation_volume=81; citation_issue=1; citation_publication_date=2012; citation_pages=65-79; citation_id=CR33"",""citation_journal_title=Procedia Comput Sci; citation_title=An IBE technique using partial discrete logarithm; citation_author=C Meshram, PL Powar, MS Obaidat, CC Lee; citation_volume=93; citation_publication_date=2016; citation_pages=735-741; citation_doi=10.1016/j.procs.2016.07.282; citation_id=CR34"",""citation_journal_title=Informatica; citation_title=An IND-ID-CPA secure ID-based cryptographic protocol using GDLP and IFP; citation_author=C Meshram, YM Tseng, CC Lee, SG Meshram; citation_volume=28; citation_issue=3; citation_publication_date=2017; citation_pages=471-484; citation_doi=10.15388/Informatica.2017.139; citation_id=CR35"",""citation_journal_title=Soft Comput; citation_title=A secure key authentication scheme for cryptosystems based on GDLP and IFP; citation_author=C Meshram, CC Lee, CT Li, CL Chen; citation_volume=21; citation_issue=24; citation_publication_date=2017; citation_pages=7285-7291; citation_doi=10.1007/s00500-016-2440-3; citation_id=CR36"",""citation_journal_title=Soft Comput; citation_title=An efficient ID-based cryptographic transformation model for extended chaotic-map-based cryptosystem; citation_author=C Meshram, CC Lee, SG Meshram, CT Li; citation_publication_date=2018; citation_doi=10.1007/s00500-018-3332-5; citation_id=CR37"",""citation_journal_title=Soft Comput; citation_title=An efficient online/offline ID-based short signature procedure using extended chaotic maps; citation_author=C Meshram, CT Li, SG Meshram; citation_publication_date=2018; citation_doi=10.1007/s00500-018-3112-2; citation_id=CR38"",""citation_journal_title=Secur Priv; citation_title=Chebyshev chaotic maps based ID-based cryptographic model using subtree and fuzzy-entity data sharing for public key cryptography; citation_author=C Meshram, MS Obaidat, SG Meshram; citation_volume=1; citation_issue=1; citation_publication_date=2018; citation_pages=e12; citation_doi=10.1002/spy2.12; citation_id=CR39"",""citation_journal_title=IET Netw; citation_title=Efficient online/offline IBSS protocol using partial discrete logarithm for WSNs; citation_author=C Meshram, PL Powar, MS Obaidat, CC Lee, SG Meshram; citation_volume=7; citation_issue=6; citation_publication_date=2018; citation_pages=363-367; citation_doi=10.1049/iet-net.2018.0019; citation_id=CR40"",""citation_journal_title=Int J Inf Secur; citation_title=Multi-keyword search over encrypted data with scoring and search pattern obfuscation; citation_author=C Orencik, A Selcuk, E Savas, M Kantarcioglu; citation_volume=15; citation_issue=3; citation_publication_date=2016; citation_pages=251-269; citation_doi=10.1007/s10207-015-0294-9; citation_id=CR41"",""Shamir A (1984) Identity-based cryptosystems and signature schemes. In: Proceedings of CRYPTO’84, Lecture Notes in Computer Science, vol 196, pp 47–53"",""citation_journal_title=Secur Cloud Comput (Springer, Berlin); citation_title=Privacy-preserving keyword search over encrypted data in cloud computing; citation_author=W Sun, W Lou, Y Hou, H Li; citation_volume=2014; citation_publication_date=2014; citation_pages=189-212; citation_doi=10.1007/978-1-4614-9278-8_9; citation_id=CR43"",""citation_journal_title=IEEE J Sel Areas Commun; citation_title=An ID-based cryptosystem based on the discrete logarithm problem; citation_author=S Tsujii, T Itoh; citation_volume=7; citation_publication_date=1989; citation_pages=467-473; citation_doi=10.1109/49.17709; citation_id=CR44"",""Waters B (2005) Efficient identity-based encryption without random oracles. In: Advances in cryptology-CRYPTO 2005, Lecture Notes in Computer Science. Springer, Berlin, pp 114–127"",""citation_journal_title=J Comput Res Dev; citation_title=An efficient and provably secure IBE scheme without bilinear map; citation_author=P Xu, G Cui, F Lei; citation_volume=45; citation_issue=10; citation_publication_date=2008; citation_pages=1687-1695; citation_id=CR46"",""citation_journal_title=Sci China; citation_title=A more efficient accountable authority IBE scheme under the DL assumption; citation_author=P Xu, G Cui, C Fu, X Tang; citation_volume=53; citation_issue=3; citation_publication_date=2010; citation_pages=581-592; citation_doi=10.1007/s11430-010-0009-z; citation_id=CR47"",""citation_journal_title=IEEE Trans Comput; citation_title=Public-key encryption with fuzzy keyword search: a provably secure scheme under keyword guessing attack; citation_author=P Xu, H Jin, Q Wu, W Wang; citation_volume=62; citation_publication_date=2013; citation_pages=2266-2277; citation_doi=10.1109/TC.2012.215; citation_id=CR48"",""citation_journal_title=Wuhan Univ J Nat Sci; citation_title=An ideal lattice based IBE scheme in the standard model; citation_author=X Yang, L Wu, M Zhang, P Wei, L Wei; citation_volume=16; citation_issue=5; citation_publication_date=2011; citation_pages=439-446; citation_doi=10.1007/s11859-011-0777-0; citation_id=CR49"",""citation_journal_title=Secur Commun Netw; citation_title=Efficient public key encryption with revocable keyword search; citation_author=Y Yu, J Ni, H Yang, Y Mu, W Susilo; citation_volume=7; citation_issue=2; citation_publication_date=2014; citation_pages=466-472; citation_doi=10.1002/sec.790; citation_id=CR50"",""citation_journal_title=Inf Sci; citation_title=Signatures in hierarchical certificateless cryptography: efficient constructions and provable security; citation_author=L Zhang, Q Wu, J Domingo-Ferrer, B Qin, P Zeng; citation_volume=272; citation_publication_date=2014; citation_pages=223-237; citation_doi=10.1016/j.ins.2014.02.085; citation_id=CR51"",""citation_journal_title=J Comput Syst Sci; citation_title=A strong provably secure IBE scheme without bilinear map; citation_author=M Zheng, Y Xiang, H Zhou; citation_volume=81; citation_publication_date=2015; citation_pages=125-131; citation_doi=10.1016/j.jcss.2014.06.020; citation_id=CR52""
""citation_journal_title"",""Soft Computing""
""language"",""en""
""citation_cover_date"",""2019/12/01""
""og:description"",""The advancement of the cloud storage technology opens up a wide range of possibilities for adaptable data sharing. When sharing data to an extensive number of users with fuzzy identities, the data proprietor must use an appropriate identity-based encryption technique that satisfies both efficiency and security prerequisites. Identity-based encryption is a promising possibility to ensure fuzzy user data sharing while meeting the security essentials; however, it may encounter efficiency trouble in multi-receiver settings. Recently, identity-based encryption has received much attention, and most of the research has aimed to apply the technique in real-world systems. A major concern about using identity-based encryption is the safety of the private keys, as disclosure of secret keys requires the reissuing of encryptions already doled out. The capability to minimize the risks associated with key disclosure is particularly important due to the increased use of mobile and unprotected devices. In this article, we shall propose a forward-secure identity-based encryption technique based on subtree for fuzzy user data sharing under cloud computing environment, and we shall demonstrate that the technique is semantically secure against a chosen subtree and chosen ciphertext attack (IND-CST–CCA). In addition, we will show the superiority of our new technique over the currently existing methods in terms of security and the length of public key. Then, we will also discuss the potential of our new technique to be deployed in pay TV systems and grid security.""
""prism.issn"",""1433-7479""
""citation_author_email"",""cs_meshram@rediffmail.com"",""cclee@mail.fju.edu.tw"",""gajbhiyesarita@gmail.com"",""mkhurram@ksu.edu.sa""
""twitter:image:alt"",""Content cover image""
""prism.number"",""24""
""citation_issn"",""1433-7479""
""citation_language"",""en""
""dc:title"",""An identity-based encryption technique using subtree for fuzzy user data sharing under cloud computing environment | SpringerLink""
""Content-Encoding"",""UTF-8""
""citation_pdf_url"",""https://link.springer.com/content/pdf/10.1007/s00500-019-03855-1.pdf""
""citation_lastpage"",""13138""
""DOI"",""10.1007/s00500-019-03855-1""
""citation_journal_abbrev"",""Soft Comput""
""prism.rightsAgent"",""journalpermissions@springernature.com""
""citation_author"",""Chandrashekhar Meshram"",""Cheng-Chi Lee"",""Sarita Gajbhiye Meshram"",""Muhammad Khurram Khan""
""resourceName"",""casa""
""dc.date"",""2019-02-23""
""citation_springer_api_url"",""http://api.springer.com/metadata/pam?q=doi:10.1007/s00500-019-03855-1&api_key=""
""citation_issue"",""24""
""prism.volume"",""23""
""prism.publicationName"",""Soft Computing""
""citation_doi"",""10.1007/s00500-019-03855-1""
""dc.title"",""An identity-based encryption technique using subtree for fuzzy user data sharing under cloud computing environment""
""prism.url"",""https://link.springer.com/article/10.1007/s00500-019-03855-1""
""citation_volume"",""23""
""dc.language"",""En""
""Content-Language"",""en""
""format-detection"",""telephone=no""
""citation_publication_date"",""2019/12""
""prism.endingPage"",""13138""
""citation_title"",""An identity-based encryption technique using subtree for fuzzy user data sharing under cloud computing environment""
""citation_author_institution"",""Department of Mathematics and Computer Science, Rani Durgavati University, Jabalpur, India"",""Department of Library and Information Science, Fu Jen Catholic University, New Taipei, Taiwan, ROC"",""Department of Photonics and Communication Engineering, Asia University, Taichung, Taiwan, ROC"",""Department of Mathematics and Computer Science, Rani Durgavati University, Jabalpur, India"",""Center of Excellence in Information Assurance, King Saud University, Riyadh, Saudi Arabia""
""access"",""No""
""citation_publisher"",""Springer Berlin Heidelberg""
""applicable-device"",""pc,mobile""
""dc.format"",""text/html""
""description"",""The advancement of the cloud storage technology opens up a wide range of possibilities for adaptable data sharing. When sharing data to an extensive number""
""title"",""An identity-based encryption technique using subtree for fuzzy user data sharing under cloud computing environment | SpringerLink""
""citation_online_date"",""2019/02/23""
""twitter:site"",""@SpringerLink""
""dc.source"",""Soft Computing 2019 23:24""
""dc.type"",""OriginalPaper""
""dc.copyright"",""2019 Springer-Verlag GmbH Germany, part of Springer Nature""
""dc.creator"",""Chandrashekhar Meshram"",""Cheng-Chi Lee"",""Sarita Gajbhiye Meshram"",""Muhammad Khurram Khan""
""citation_fulltext_html_url"",""https://link.springer.com/article/10.1007/s00500-019-03855-1""
""prism.publicationDate"",""2019-02-23""
""Content-Type"",""text/html; charset=UTF-8""
""journal_id"",""500""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""dc.description"",""The advancement of the cloud storage technology opens up a wide range of possibilities for adaptable data sharing. When sharing data to an extensive number of users with fuzzy identities, the data proprietor must use an appropriate identity-based encryption technique that satisfies both efficiency and security prerequisites. Identity-based encryption is a promising possibility to ensure fuzzy user data sharing while meeting the security essentials; however, it may encounter efficiency trouble in multi-receiver settings. Recently, identity-based encryption has received much attention, and most of the research has aimed to apply the technique in real-world systems. A major concern about using identity-based encryption is the safety of the private keys, as disclosure of secret keys requires the reissuing of encryptions already doled out. The capability to minimize the risks associated with key disclosure is particularly important due to the increased use of mobile and unprotected devices. In this article, we shall propose a forward-secure identity-based encryption technique based on subtree for fuzzy user data sharing under cloud computing environment, and we shall demonstrate that the technique is semantically secure against a chosen subtree and chosen ciphertext attack (IND-CST–CCA). In addition, we will show the superiority of our new technique over the currently existing methods in terms of security and the length of public key. Then, we will also discuss the potential of our new technique to be deployed in pay TV systems and grid security.""
""og:type"",""article""
""citation_article_type"",""Methodologies and Application""
""og:title"",""An identity-based encryption technique using subtree for fuzzy user data sharing under cloud computing environment""
""prism.doi"",""doi:10.1007/s00500-019-03855-1""
""X-UA-Compatible"",""IE=edge""
""citation_firstpage"",""13127""
""prism.startingPage"",""13127""
""viewport"",""width=device-width, initial-scale=1""
""dc.rightsAgent"",""journalpermissions@springernature.com""
""prism.section"",""OriginalPaper""
""dc.identifier"",""doi:10.1007/s00500-019-03855-1""
""dc.subject"",""Computational Intelligence"",""Artificial Intelligence"",""Mathematical Logic and Foundations"",""Control, Robotics, Mechatronics""
""og:url"",""https://link.springer.com/article/10.1007/s00500-019-03855-1""
""prism.copyright"",""2019 Springer-Verlag GmbH Germany, part of Springer Nature""
";https://scholar.google.com/scholar?start=620&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094541-660;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Decentralizing Rehabilitation: Using Blockchain to Store Exoskeletons' Movement;DA da Silva, CAS Lelis, LH Coura… ; … New Generations (ITNG …, 2019  Springer;;"… was initially created to address the double spending problem of crypto-currencies … were

responsible for the definition and execution of the acceptance testings and its oracles … from these

three disciplines were involved in acquiring knowledge about Blockchain, implementing it …";Autres articles;;null;;;;https://scholar.google.com/scholar?start=470&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094590-862;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Energy consumption analysis of java command-line options;M Kumar, W Shi ; 2019 Tenth International Green and …, 2019  ieeexplore.ieee.org;;"… Benchmark client Open Oracle IFN Laptop IFN Laptop E T E T E T E T compress 10409.24

243.06 2535.53 244.24 10396.71 242.90 2537.34 244.81 crypto crypto.aes 10314.78

246.68 2596.89 250.46 10377.92 246.22 2599.21 248.59 …";Cité 2 fois;Les 3 versions;[PDF] wayne.edu;http://weisong.eng.wayne.edu/_resources/pdfs/kumar19-igsc.pdf;"
Energy Consumption Analysis of Java
Command-line Options

Mohit Kumar
Mobile and Internet Systems Laboratory

Wayne State University

Detroit, USA

Email: mohitkumar@wayne.edu

Weisong Shi
Mobile and Internet Systems Laboratory

Wayne State University

Detroit, USA

Email: weisong@wayne.edu

Abstract—In 2018 Turing Award lecture, John L. Hennessy
discusses software-centric opportunities to save Moore’s law. The
software is a major consumer of energy in ICT, IoT, and edge
systems, but even then the research to make it energy efficient
remains fractional. Java is one of the most commonly used
languages to develop software for these systems. Java has various
command-line options that an application user can use for JVM
tuning to enhance the performance of an application. However,
there is no study about how these Java command-line options
impact the energy consumption of an application. In this work,
we explore the impact of various Java command-line options on
SPECjvm2008 benchmarks in terms of energy consumption and
execution time using different JDKs. Our key findings are: 1)
Oracle JDK is more energy efficient than Open JDK, 2) Xint
command-line option is the least energy efficient, 3) UseG1GC
command-line option is the most energy efficient, and 4) Active
energy and execution time show a high correlation.

Index Terms—Java, JDK, Command-line, Energy-efficiency

I. INTRODUCTION

Information and Communications Technologies (ICT)

amounts for 10% of the world energy which will keep on

growing in future [1] and 3% of the overall carbon footprint

which is now more than the level of CO2 emission as that of

aviation industry [2]. Most of the green IT initiative in ICT

concentrate on the hardware part resulting in significant reduc-

tion of hardware energy consumption. However, a lot needs to

be done to improve the energy efficiency of the software. An

energy-aware software that can optimize execution time can

help to make ICT systems more energy efficient. Software

power savings are considered to be greater than the power

saving in hardware, but they are harder to achieve [3].

Java is one of the most commonly-used languages in ICT

systems. Java has different command-line options that can

be used to tune the JVM. These options can significantly

affect the energy behavior of Java applications. However,

there is no study characterizing the energy behavior of these

command-line options. Therefore, in this paper, we conduct a

comprehensive study to evaluate the energy efficiency of Java

command-line options. We use Intel Running Average Power

Limit (RAPL) technology to log the energy consumption

values. We first optimize the idle energy consumption of two

ICT systems and then evaluate the active energy consumption

of SPECjvm2008 benchmarks using different JDKs (Open and

Oracle) and Java command-line options. The Java command-

line options include client, server, Xbatch, Xcomp,

Xfuture, Xint, Xmixed, Xrs, AggressiveOpts,

AggressiveHeap, Inline, AlwaysPreTouch,

Xnoclassgc, UseSerialGC, UseParallelGC,

UseConcMarkSweepGC, and UseG1GC. Our work

answers the following questions:

• Do same versions of Open and Oracle JDK have same

energy efficiency?

• Which command-line option has the lowest energy effi-

ciency of JVM?

• Which command-line option has the highest energy effi-

ciency of JVM?

• What is the relation between active energy and execution

time?

Answers to these questions will help software users to tune

the JVM for energy efficiency. To the best of our knowledge,

no research optimized the idle energy consumption of a

system while evaluating the energy efficiency of different

JDKs and Java command-line options. Not optimizing the idle

energy consumption results in outliers which cause inaccurate

measurements. We optimize the idle energy consumption and

conduct statistical tests - independent sample t-test and one

way ANOVA [4]- to compare energy consumption in cases

where it is hard to decide whether the values are the same or

not. The following are the key findings of our work:

• For most of the command-line options, Oracle JDK

is more energy efficient than Open JDK. Open JDK

consumes up to 9% more energy than Oracle JDK.

• Xint command-line option results in the lowest energy

efficiency of most benchmarks with up to 125% in-

crease in energy consumption as compared to the default

server command-line option.

• UseG1GC command-line option results in the highest

energy efficiency of most benchmarks with up to 14%

decrease in energy consumption as compared to the

default server command-line option.

• Active energy and execution time show a high correlation

with a maximum value of 0.98 and a minimum value of

978-1-7281-5416-9/19 $31.00 Š 2019 IEEE



TABLE I
RAPL DOMAINS

Domain Component

Package CPU package

PP0 All cores and caches

PP1 GPU

DRAM DRAM

0.94.

The rest of the paper is organized as follows. Section 2, pro-

vides the background for energy measurement, optimization

and SPECjvm2008 benchmarks. Section 3, describes the en-

ergy consumption measurement setup. Section 4, investigates

the energy consumption traits of Java command-line options.

Section 5, analyzes the relation between active energy and

execution time. Section 6, discusses related work in the field.

Section 7, concludes the paper and discusses the future work

in energy efficient software.

II. BACKGROUND

In this section, we first introduce energy-related terms,

perf, systemd, and systemctl. Then, we describe

SPECjvm2008 benchmarks in detail.

The idle power is defined as the amount of power consumed

by a system when it is not performing any task. As defined

in [5], it is the sum of static and dynamic power, as systems

have a different number of background processes running all

the time. In this work, we try to reduce the dynamic power

to stabilize the idle power. The active power is defined as the

amount of power consumed by a system while performing

a specific task such as web browsing, printing, emailing,

listening to music or playing a game.

Intel introduced the Running Average Power Limit (RAPL)

feature starting with their Sandy Bridge processors, for mea-

suring the energy consumption of onboard hardware compo-

nents. It provides energy consumption information of different

CPU-level components as listed in Table I. It uses a soft-

ware power model which estimates the energy consumption

by leveraging hardware performance counters. A user can

configure and read RAPL information through Mode Specific

Registers in privileged kernel mode. We use Linux perf

tool which leverages RAPL technology to measure energy

consumption.

systemd is a critical suite of software for the Linux

operating system that manages and operates various units

like service, target, path, mount etc. Some of the units can

trigger other units and work together to add functionality. In

this work, we utilize the service unit to optimize the idle

energy consumption of the whole system as it is the most

commonly utilized service by system administrators. We use

systemctl command to start or stop a service.

SPECjvm2008 consists of 11 benchmarks which are split

into sub-benchmarks as shown in Table II. Compiler bench-

mark has two sub-benchmarks - compiler.compiler and

TABLE II
SPECJVM2008 BENCHMARKS

Benchmarks Sub-Benchmarks

Compiler compiler.compiler, compiler.sunflow
Compress compress

Crypto crypto.aes, crypto.rsa, crypto.signverify
Derby derby

MPEGaudio mpegaudio

Scimark.X.large

Scimark.X.small

scimark.fft.large, scimark.lu.large, scimark.sor.large,
scimark.sparse.large, scimark.fft.small, scimark.lu.small,

scimark.sor.small, scimark.sparse.small, scimark.monte carlo
Serial serial

Sunflow sunflow
XML xml.transform, xml.validation

Startup

startup.helloworld, startup.compiler.compiler, startup.compiler.sunflow,
startup.compress, startup.crypto.aes, startup.crypto.rsa,

startup.crypto.signverify, startup.mpegaudio, startup.scimark.fft,
startup.scimark.lu, startup.scimark.monte carlo, startup.scimark.sor,

startup.scimark.sparse, startup.serial, startup.sunflow,
startup.xml.transform, startup.xml.validation

compiler.sunflow. compiler.compiler compiles

javac itself. compiler.sunflow compiles the sunflow

sub-benchmark from SPECjvm2008. This benchmark has its

own FileManger to manage memory. compress benchmark

uses a modified Lempel-Ziv method to compress data. It is

deterministic as it first finds common substrings and then

replaces them with a variable size code. This benchmark

is ported from 129.compress benchmark from CPU95, how-

ever, it is modified to compress real data from files in-

stead of compressing synthetically generated data. Crypto

benchmark consists of three sub-benchmarks - crypto.aes,

crypto.rsa and crypto.signverify - which focuses

on different areas of crypto. crypto.aes performs en-

cryption and decryption using the AES and DES proto-

cols with an input data of size 100 bytes and 713 KB.

crypto.rsa performs encryption and decryption using the

RSA protocol with an input data of size 100 bytes and 16 KB.

crypto.signverify sign and verify using MD5withRSA,

SHA1withRSA, SHA1withDSA and SHA256withRSA pro-

tocols with an input data size of 1 KB, 65 KB, and 1

MB. derby benchmark focuses on BigDecimal computations

and database logic using an open-source database written in

pure Java. MPEGaudio benchmark utilizes JLayer, an LGPL

mp3 library, for mp3 decoding and is floating-point heavy.

Scimark benchmark is a floating point benchmark which is

consist of five sub-benchmarks - fft, lu, sor, sparse,

and monte_carlo. Each sub-benchmark has two versions

with different dataset size, except monte_carlo (as it uses

only scalars). The large dataset has a size of 32MB for

stressing the memory whereas the small dataset has a size

of 512 KB to stress the JVM. serial benchmark utilizes

data from the JBoss benchmark to serialize and deserialize

primitives and objects. sunflow benchmark utilizes half

the number of hardware threads to test graphics visualiza-

tion. Each of the hardware thread results in four internal

threads inside the benchmark. XML benchmark has two sub

benchmarks - xml.transform and xml.validation.

xml.transform stresses the JRE’s implementation of

javax.xml.transform by applying style sheets to XML docu-



TABLE III
SYSTEM SPECIFICATION

System Component Intel Fog Node Configuration Laptop Configuration

CPU Intel(R) Xeon(R) E3-1275 v5 Intel(R) Core(TM) i5-3317U v5
Number of cores 4 2

Number of threads 8 4
Kernel 4.13.0-37-generic 4.4.0-116-generic

OS Ubuntu Server 16.04.4 LTS Ubuntu Server 16.04.3 LTS
CPU governor powersave powersave

Memory 32GB SODIMM 2133 MHz 4GB DDR3 1600 MHz
JDK OpenJDK 64-Bit Server VM OpenJDK 64-Bit Server VM

JDK build 25.151-b12 25.151-b12
JDK version 1.8.0 151 1.8.0 151

Initial Heap Size 526MB 63MB
Maximum Heap Size 8.4GB 1GB

ments. xml.validation stresses the JRE’s implementation

of javax.xml.validation by validating XML instance documents

against XML schemata. startup benchmark starts each of

the above-discussed benchmarks for one operation. For every

benchmark run, a new JVM is launched and time is measured

from starting the JVM to finishing off the benchmark iteration.

SPECjvm2008 has two run categories - Base and Peak. Base

category run doesn’t allow the tuning of the JVM. Therefore,

in this work, we utilize the Peak category as we evaluate

various command-line options to tune the JVM. Except for

startup, each benchmark goes through one iteration in

which several operations (each invocation of a benchmark is

one operation) are executed for certain duration, by defaults

240 seconds. Each iteration finishes at least 5 operations. The

duration of an iteration is never less than the specified time,

however, it increases if at least five operations are not executed

within the specified duration of time. For this work, we utilize

the default duration of the iteration. The warmup is skipped

as it is not possible to remove the warmup energy from the

total energy of a benchmark run.

III. SET UP

We leverage two different ICT systems to conduct our ex-

periments: Intel Fog Node(IFN) and Laptop. The configuration

of these two systems is presented in Table III. We use the

same versions of Open and Oracle JDK for this study. Oracle

JDK is expected to consume lesser energy as it is maintained

by the same group of coders and is more consistent. For the

Laptop, the charger is plugged in a wall outlet all the time.

Both systems are disconnected from the internet all the time.

We use the Linux perf tool to gather energy consumption

values of package and core domains. The sampling rate is set

to 10Hz. The following command is executed for each run:

$ sudo perf stat -a -r 1 -I 100\

-e 'power/energy-pkg/'\

-o pack.txt\

java programFile

where -a specifies collection from all CPUs, -r indicates how

many times the command will be repeated, -I specifies the

time interval (msec), -e specifies the event selector, and -o

specifies the name of the output file.

The total energy consumption is the sum of active and idle

energy. As perf reports the total energy, one can subtract the

idle energy out of the total energy to find the active energy of

an application. However, the idle energy of a system can vary

a lot due to the background services running on an operating

system. These variations make it hard to measure an accurate

idle energy of a system. To measure the idle energy of both

systems considered here, we conduct an experiment in which

we first optimize the idle energy and then calculate the idle

energy of both systems by removing outliers and computing

the mean of values. We first measure the idle energy of both

systems without any optimization for 24 hours with a sampling

rate of 10Hz to determine how the idle energy varies. In Fig.

1a and 2a, we show the idle energy consumption of the two

systems. We can see that the idle energy can change abruptly

at any time for both systems.

Next, we stop the background services using systemctl

command to optimize the idle energy of the systems. For both

systems, we disable all the enabled services. We again measure

the idle energy and we observe that there is a lot of variation.

The reason is that the disabled services can still be enabled

because if a service is disabled, then it is not loaded during

boot time but it can be loaded if a service is started and it

depends on the disabled service. Next, we mask all the enabled

services using systemctl command to optimize the idle

energy. If a service is masked, then it cannot be loaded even

if it is required by some other service. This time we were able

to optimize the idle energy with a very few outliers as shown

in Fig. 1b and 2b. We go one step further and mask all the

disabled services and then obtain fewer outliers, as shown in

Fig. 1c and 2c. However, outliers were still there as we can’t

mask some of the services like log in, user manager and dbus.

The next step is to remove the outliers from the 24-hour

dataset shown in Fig. 1c and 2c and calculate the mean of

the values. We use Tukey’s method to remove the outliers [6].

For the IFN and the Laptop, the outliers represent 0.001%

and 0.002% of the total data set, respectively. We remove the

outliers from both datasets. The histogram and boxplot before

and after removing outliers for the IFN are shown in Fig. 3a

and 3b, and for the Laptop in Fig. 4a and 4b. The standard

deviation for the IFN is 0.0006, and for the Laptop is 0.0007.

The standard deviation indicates that both datasets have very

low variation. The mean idle energy consumed per one-tenth

of a second for the IFN and the Laptop was found to be 0.025

J and 0.229 J, respectively. We can now calculate the active

energy by subtracting the idle energy from the total energy.

IV. ENERGY CONSUMPTION ANALYSIS

In this section, we evaluate the energy consumption of

different Java command-line options. For better accuracy, we

measure the total energy consumption of each command-line

option ten times. We then check for outliers in those ten

measurements using Tukey’s method. We replace the outliers

measurements with new measurements and again check for

outliers. We repeat this process until no outlier is left. Next,

we subtract the idle energy from the total energy consumption



0
.0

0
.5

1
.0

1
.5

2
.0

No services masked

Time (H)

E
n
e
rg

y
 C

o
n
s
u
m

p
ti
o
n
 (

J
)

0 4 8 12 16 20 24

(a)

0
.0

0
.5

1
.0

1
.5

2
.0

Enabled services masked

Time (H)

E
n
e
rg

y
 C

o
n
s
u
m

p
ti
o
n
 (

J
)

0 4 8 12 16 20 24

(b)

0
.0

0
.5

1
.0

1
.5

2
.0

Every service masked

Time (H)

E
n
e
rg

y
 C

o
n
s
u
m

p
ti
o
n
 (

J
)

0 4 8 12 16 20 24

(c)

Fig. 1. Intel Fog Node package idle energy consumption: (a) with all services unmasked; (b) with enabled services masked, and (c) with enabled and disabled
services masked.

0
.2

0
.4

0
.6

0
.8

1
.0

No services masked

Time (H)

E
n
e
rg

y
 C

o
n
s
u
m

p
ti
o
n
 (

J
)

0 4 8 12 16 20 24

(a)

0
.2

0
.4

0
.6

0
.8

1
.0

Enabled services masked

Time (H)

E
n
e
rg

y
 C

o
n
s
u
m

p
ti
o
n
 (

J
)

0 4 8 12 16 20 24

(b)

0
.2

0
.4

0
.6

0
.8

1
.0

Every service masked

Time (H)

E
n
e
rg

y
 C

o
n
s
u
m

p
ti
o
n
 (

J
)

0 4 8 12 16 20 24

(c)

Fig. 2. Laptop package idle energy consumption: (a) with all services unmasked; (b) with enabled services masked, and (c) with enabled and disabled services
masked.

0.0 0.2 0.4 0.6 0.8 1.0

Intel Fog Node Dataset With Outliers

Energy Consumption (J)

F
re

q
u
e
n
c
y

0.0 0.2 0.4 0.6 0.8 1.0

0
4
0
0
0
0

8
0
0
0
0

1
2
0
0
0
0

(a)

0.022 0.024 0.026 0.028 0.030

Intel Fog Node Dataset Without Outliers

Energy Consumption (J)

F
re

q
u
e
n
c
y

0.022 0.024 0.026 0.028 0.030

0
2
0
0
0
0

4
0
0
0
0

6
0
0
0
0

(b)

Fig. 3. Intel Fog Node dataset: (a) with outliers, and (b) without outliers.

0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9

Laptop Dataset With Outliers

Energy Consumption (J)

F
re

q
u
e
n
c
y

0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9

0
4
0
0
0
0

8
0
0
0
0

1
2
0
0
0
0

(a)

0.226 0.227 0.228 0.229 0.230 0.231 0.232

Laptop Dataset Without Outliers

Energy Consumption (J)

F
re

q
u
e
n
c
y

0.226 0.227 0.228 0.229 0.230 0.231 0.232

0
2
0
0
0
0

4
0
0
0
0

6
0
0
0
0

(b)

Fig. 4. Laptop dataset: (a) with outliers, and (b) without outliers.

to determine the active energy of each benchmark. We then

calculate the mean of all the ten observations to determine

the total energy consumption and the execution time of each

benchmark. In cases where the means are close, we use the

independent sample t-test (two means) or one-way ANOVA

test (more than two means) to determine whether the means

are the same. For both tests, we consider alpha value as

0.05. We log the package, and the core energy but only

present the package energy consumption values as the core

energy measurements values are negligible compare to those

of the package. compiler benchmark is not shown in any

of the result tables as it is not supported by Java SE 8. Also,

fft.large and lu.large benchmark results are not

shown as they abort when run on both systems. Each table

in the next subsections of the paper represents the total active

energy consumption and the execution time of SPECjvm2008

benchmarks. For each table, Open and Oracle represent the

different JDKs. Under each JDK we have the two ICT systems

- IFN and Laptop. Under each ICT system is the measurement

of energy consumption (E) in Joule and execution time (T) in

second. server command-line option refers to default mode

as both systems use server JVM by default. Tables for only

specific Java command-line options are included due to space

limit.

A. -client and -server

The JDK supports two type of JVM - client and

server. These two JVMs have the same runtime envi-

ronment code base, however, they use a different type of

compilers. client JVM compiler offers lesser optimization,

which results in faster compiling for short-running applica-

tions. server JVM offers an advance adaptive compiler,

which supports complex optimization for maximizing peak

operating speed of long-running applications. We compare

the energy consumption of these two options in Table IV

and V. For the client, we can see that 20 benchmarks

on the IFN and 19 benchmarks on the Laptop have lower



TABLE IV
ENERGY CONSUMPTION FOR CLIENT OPTION

Benchmark

client
Open Oracle

IFN Laptop IFN Laptop

E T E T E T E T
compress 10409.24 243.06 2535.53 244.24 10396.71 242.90 2537.34 244.81

crypto
crypto.aes 10314.78 246.68 2596.89 250.46 10377.92 246.22 2599.21 248.59
crypto.rsa 10074.29 242.02 2439.42 243.55 9623.52 241.80 2346.07 242.31

crypto.signverify 9715.88 241.96 2469.04 243.58 9700.36 241.76 2446.63 243.17
derby 10916.68 259.56 2600.44 422.25 10953.10 259.51 2606.55 421.16

mpegaudio 10464.72 243.77 2517.06 245.30 10450.29 243.43 2511.49 246.42
scimark
fft.small 11456.44 241.94 2689.68 242.97 11447.94 241.81 2684 243.46
lu.small 14771.78 241.61 2854.29 243.27 14645.49 241.54 2857.34 242.95

monte carlo 9982.14 242.52 2367.98 244.66 9947.21 242.21 2348.31 244.54
sor.large 7639.63 247.87 2491.90 257.20 7580.28 252.00 2459.64 254.95
sor.small 8166.53 242.57 2066.18 244.06 8123.92 243.06 2063.16 244.18

sparse.large 6130.27 264.51 2695.02 253.13 6148.83 251.79 2630.65 255.68
sparse.small 9754.74 243.24 2845.30 245.05 11143.90 242.62 2793.65 243.99

serial 11149.01 243.58 2573.32 247.05 11198.22 243.47 2568.53 246.29
sunflow 10111.17 242.71 2587.03 245.25 10115.83 243.43 2581.64 243.38

xml
xml.transform 11362.00 254.01 2748.23 267.81 11356.21 253.84 2753.63 267.16
xml.validation 11742.37 241.67 2535.31 243.22 11741.60 241.65 2536.2 242.89

startup
compress 32.81 1.66 23.41 3.80 32.22 1.70 22.78 3.04
crypto.aes 48.27 2.67 38.13 5.21 50.41 2.80 40.87 5.57
crypto.rsa 28.68 1.26 21.63 2.50 25.90 1.05 20.19 2.33

crypto.signverify 28.62 1.30 21.99 2.61 25.92 1.27 20.17 2.47
mpegaudio 51.49 2.04 38.82 4.78 53.26 2.12 39.52 4.62
scimark.fft 26.43 1.26 19.92 2.43 24.78 1.29 19.37 2.48
scimark.lu 22.64 0.99 18.33 2.27 21.80 1.00 17.77 2.30

scimark.monte carlo 32.91 1.89 24.96 3.42 32.24 1.90 24.28 3.38
scimark.sor 31.05 1.87 23.11 3.29 30.18 1.93 22.51 3.21

scimark.sparse 30.32 1.54 23.50 3.07 29.67 1.53 23.06 2.97
serial 56.27 2.20 43.66 5.20 56.34 2.23 44.91 5.20

sunflow 54.51 1.80 42.13 4.46 54.92 1.81 42.46 4.40
xml.transform 264.16 13.33 207.03 27.06 269.16 13.52 211.76 27.51
xml.validation 48.94 1.62 41.22 4.43 48.88 1.61 42.28 4.53

TABLE V
ENERGY CONSUMPTION FOR SERVER OPTION

Benchmark

server

Open Oracle
IFN Laptop IFN Laptop

E T E T E T E T
compress 10446.44 242.68 2533.75 244.61 10409.98 242.99 2532.61 244.36

crypto
crypto.aes 10368.44 246.26 2599.44 250.21 10366.61 246.16 2597.92 247.87
crypto.rsa 10125.59 242.22 2440.72 243.51 9636.60 241.82 2345.5 242.41

crypto.signverify 9740.42 242.04 2458.03 243.66 9725.98 241.76 2452.33 243.24
derby 10948.96 258.71 2603.97 430.39 10949.42 259.49 2603.04 422.69

mpegaudio 10474.17 243.76 2519.12 245.18 10443.40 243.68 2516.17 245.40
scimark
fft.small 11474.26 241.95 2684.87 243.51 11430.56 241.91 2683.26 243.50
lu.small 14698.87 241.61 2852.07 242.88 14697.20 241.61 2856.52 242.68

monte carlo 9974.18 242.57 2365.99 244.86 9949.61 242.27 2349.11 244.32
sor.large 7591.76 249.50 2469.21 250.93 7567.83 248.40 2462.37 251.50
sor.small 8158.51 243.03 2063.81 244.01 8123.63 243.15 2060.24 243.63

sparse.large 6073.82 262.46 2658.77 250.84 5965.71 255.23 2635.06 261.88
sparse.small 9739.27 242.70 2821.39 244.70 11109.87 242.70 2786.99 244.95

serial 11157.09 243.07 2572.46 246.17 11168.14 243.15 2570.49 245.76
sunflow 10134.22 243.56 2581.23 244.03 10113.49 242.89 2579.16 243.59

xml
xml.transform 11359.57 253.98 2740.60 266.96 11355.62 253.96 2744.93 267.07
xml.validation 11738.44 241.72 2532.73 242.67 11735.22 241.66 2529.64 242.94

startup
compress 32.56 1.68 23.51 3.01 32.00 1.63 22.84 3.01
crypto.aes 48.46 2.62 38.44 5.09 50.32 2.74 40.92 5.36
crypto.rsa 29.38 1.27 21.78 2.64 25.72 1.06 20.47 2.42

crypto.signverify 28.24 1.28 22.05 2.68 25.77 1.24 20.23 2.52
mpegaudio 52.42 2.10 37.99 4.20 52.09 2.17 39.61 4.63
scimark.fft 26.17 1.25 19.73 2.56 24.73 1.26 19.43 2.49
scimark.lu 22.69 0.99 18.47 2.25 21.90 1.06 17.87 2.20

scimark.monte carlo 33.21 1.92 24.70 3.38 32.11 1.90 24.22 3.37
scimark.sor 31.36 1.94 23.07 3.16 29.98 1.94 22.5 3.24

scimark.sparse 31.05 1.50 23.58 3.14 29.71 1.48 22.97 2.97
serial 56.24 2.13 44.22 4.98 56.70 2.28 44.67 5.07

sunflow 54.29 1.83 42.11 4.17 53.77 1.83 42.10 4.50
xml.transform 265.36 13.31 209.15 26.45 268.01 13.34 211.96 26.81
xml.validation 49.18 1.58 41.63 4.40 48.23 1.55 41.82 4.68

energy consumption when executed on Oracle JDK instead

of Open JDK. For the server, these number jump to 25

and 24 benchmarks. For the IFN, 18 benchmarks consume

more energy for server option while using Open JDK.

Using Oracle JDK instead causes client option to consume

more energy for 23 benchmarks. For the Laptop, 18 and 17

benchmarks consume lesser energy for server option while

using Open and Oracle JDK, respectively.

Two benchmarks - crypto.rsa and sparse.small

- stands out with large variation in energy consumption

for different JDK types on the IFN. sparse.small not

only shows the highest variation on the IFN but also shows

higher energy efficiency using Open JDK. For the Laptop,

crypto.rsa shows the highest variation for different JDK

versions, however, sparse.small doesn’t show the same

behavior as on the IFN. For both systems, sparse results in

higher energy consumption for the smaller dataset instead of

the larger dataset. This happens because small dataset results

in up to five times higher ops/m than large dataset. Most of

the command-line options that we are going to discuss next

show the same behavior for energy consumption variation of

different benchmarks.

B. -Xbatch, -Xcomp, -Xint, -Xfuture, and -Xmixed

JVM runs a method in interpreted mode until the back-

ground compilation is finished. Xbatch option disables this

background compilation and runs the compilation in the

foreground. For the Xbatch option, Oracle JDK results in

better energy efficiency for 21 benchmarks, for both systems.

Xbatch also results in the lower energy efficiency on both

systems for at least 21 benchmarks as compared to the default

mode for both JDKs. Xcomp forces the compilation of a

method on the first invocation instead of doing that after a set

threshold of interpreted method invocations. For the Xcomp

option, Open JDK results in better energy efficiency for 24

benchmarks on the IFN and 23 benchmarks on the Laptop. For

both systems, Xcomp results in higher energy consumption of

at least 27 benchmarks than the default mode for both JDKs.

Xint causes the JVM to run in interpreted-only mode.

This option disables the just-in-time compilation, resulting in

a considerable slow down in execution. As shown in Table

VI, for 22 benchmarks on the IFN and 20 benchmarks on

the Laptop, Oracle JDK results in higher energy efficiency

than Open JDK. Open JDK results in up to 9% increase

in energy consumption. For both systems, Xint results in

higher energy consumption of at least 27 benchmarks than the

default mode for both JDKs. For crypto.aes and derby,

Xint results in significant increase in energy consumption.

Xint also causes different variation in energy consumption

than the default mode for most benchmarks. Xint causes the

highest energy consumption for most of the benchmarks with

up to 125% increase in the energy than the default mode.

Interestingly, Xint consumes up to 28% lesser energy than

the default mode for lu.small benchmark.

Xfuture results in stricter class-file format checks. For

the Xfuture option, Oracle JDK results in higher energy

efficiency as compared to Open JDK for 20 benchmarks on the

IFN and 21 benchmarks on the Laptop. For the IFN, Xfuture

results in the higher energy efficiency of most benchmarks for



TABLE VI
ENERGY CONSUMPTION FOR XINT OPTION

Benchmark

Xint
Open Oracle

IFN Laptop IFN Laptop

E T E T E T E T
compress 10262.54 305.11 3582.90 344.55 10448.47 300.76 3594.33 331.08

crypto
crypto.aes 14236.14 371.68 5906.80 585.48 13826.80 353.63 5856.40 611.91
crypto.rsa 11185.43 280.84 3321.55 326.19 10255.85 268.66 3215.92 310.36

crypto.signverify 10191.72 299.46 3774.37 376.81 10865.56 313.89 3695.84 360.63
derby 13474.05 517.50 5815.05 946.75 13401.37 514.11 5932.39 953.83

mpegaudio 11605.41 283.70 3288.36 326.60 11439.94 282.00 3247.07 319.73
scimark
fft.small 11358.65 255.44 2825.84 272.91 11261.74 252.42 2780.51 278.73
lu.small 10467.14 268.97 2925.48 284.71 10462.62 266.74 2869.83 277.54

monte carlo 12170.18 291.06 4291.29 417.89 12357.51 315.08 4067.55 393.57
sor.large 13097.32 334.18 3851.68 364.24 13065.95 333.69 3837.35 363.64
sor.small 10237.10 265.26 3019.37 284.22 10199.15 263.83 2806.69 268.06

sparse.large 13592.60 347.62 4016.89 401.54 13457.79 344.92 4004.76 389.23
sparse.small 10268.71 261.65 3172.02 300.26 10228.77 261.84 3150.17 294.87

serial 12284.70 297.22 4011.33 376.96 11750.90 298.43 4084.54 384.48
sunflow 12701.02 290.03 3103.53 286.03 12706.04 290.76 3154.03 291.20

xml
xml.transform 12082.03 317.74 3823.75 391.98 11668.35 328.32 3890.64 397.48
xml.validation 10913.75 268.58 2942.64 276.54 10362.28 270.72 2959.56 280.39

startup
compress 39.25 2.52 30.51 4.74 37.79 2.37 29.63 4.73
crypto.aes 54.69 3.50 45.58 6.72 56.09 3.58 47.37 6.97
crypto.rsa 35.48 2.09 29.52 4.47 31.95 1.81 27.00 3.86

crypto.signverify 34.74 2.21 29.57 4.59 31.77 2.00 27.01 4.12
mpegaudio 57.88 2.97 46.05 6.43 58.12 2.86 46.30 6.34
scimark.fft 32.77 2.10 27.06 4.36 30.61 1.93 26.03 4.13
scimark.lu 28.98 1.83 25.66 3.90 27.86 1.74 24.50 3.82

scimark.monte carlo 39.39 2.76 32.05 5.26 37.35 2.62 31.00 5.01
scimark.sor 37.54 2.74 29.60 4.92 35.80 2.62 29.17 4.75

scimark.sparse 36.76 2.41 30.52 4.71 35.52 2.25 29.50 4.61
serial 61.13 3.01 50.56 6.79 62.09 2.91 51.76 6.84

sunflow 59.39 2.61 49.14 6.12 59.49 2.56 48.41 6.04
xml.transform 268.57 14.30 214.08 28.14 271.84 14.30 219.26 28.58
xml.validation 54.83 2.42 48.09 5.91 54.32 2.38 48.65 6.19

both JDKs, except startup benchmark where the default

mode is more energy efficient. For the Laptop, the default

mode results in the higher energy efficiency of most bench-

marks for both JDKs, except startup benchmark where

the default mode is more energy efficient for each sub-

benchmarks. Xmixed option executes all bytecode except hot-

methods in interpreter mode. Hot methods are those methods

which are invoked very often. For the Xmixed option, Oracle

JDK results in the higher energy efficiency than Open JDK for

20 and 24 benchmarks on the IFN and the Laptop, respectively.

For the IFN, Xmixed results in the better energy efficiency of

20 benchmarks than the default mode for Open JDK. Using

Oracle JDK instead results in the lower energy efficiency of

Xmixed option for 20 benchmarks. For the Laptop, Xmixed

results in higher energy consumption than the default mode

for 18 benchmarks for both JDKs.

C. -Xrs

Xrs option prevents JVM from using some of the operating

system signals. In this option, an operating system handles

any raised signal. Enabling this option can reduce JVM

performance. For -Xrs option, Oracle JDK consumes lesser

energy than Open JDK for 17 and 24 benchmarks, on the IFN

and the Laptop, respectively. For the IFN, Xrs causes lower

energy consumption for most of the benchmarks on Open

JDK than the default mode but higher on Oracle JDK. For

the Laptop, Xrs causes higher energy consumption for most

of the benchmarks on Open JDK than the default mode but

lower on Oracle JDK. This shows that the same JDK shows

different behavior on different ICT systems.

D. -XX:+AggressiveOpts and

-XX:+AggressiveHeap

AggressiveOpts option enables the use of

aggressive performance optimization features. For the

AggressiveOpts option, Oracle JDK results in lower

energy consumption of 20 benchmarks on the IFN and 24

benchmarks on the Laptop as compared to Open JDK. For

the IFN, AggressiveOpts is more energy efficient for 20

benchmarks than the default mode for Open JDK, however,

lesser energy efficient for 24 benchmarks for Oracle JDK.

For the Laptop, AggressiveOpts results in higher energy

consumption of at least 18 benchmarks than the default server

option for both JDKs. AggressiveHeap option enables

Java heap optimization which is optimal for long-running

comput";"""date"",""2019-10-04T19:50:34Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.4""
""xmp:CreatorTool"",""UnknownApplication""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dcterms:created"",""2019-10-04T19:50:34Z""
""language"",""en""
""Last-Modified"",""2019-10-04T19:50:34Z""
""dcterms:modified"",""2019-10-04T19:50:34Z""
""dc:format"",""application/pdf; version=1.4""
""title"",""Untitled""
""xmpMM:DocumentID"",""uuid:ba7c142a-e93b-11e9-0000-b84f76a7f3ad""
""Last-Save-Date"",""2019-10-04T19:50:34Z""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2019-10-04T19:50:34Z""
""meta:save-date"",""2019-10-04T19:50:34Z""
""pdf:encrypted"",""false""
""dc:title"",""Untitled""
""xmp:CreateDate"",""2019-10-04T15:50:34Z""
""modified"",""2019-10-04T19:50:34Z""
""Content-Length"",""691229""
""pdf:hasMarkedContent"",""false""
""Content-Type"",""application/pdf""
""xmp:ModifyDate"",""2019-10-04T15:50:34Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""pdf:producer"",""GPL Ghostscript 9.25""
""meta:creation-date"",""2019-10-04T19:50:34Z""
""created"",""2019-10-04T19:50:34Z""
""xmp:About"",""uuid:ba7c142a-e93b-11e9-0000-b84f76a7f3ad""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""8""
""Creation-Date"",""2019-10-04T19:50:34Z""
""resourceName"",""kumar19-igsc.pdf""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""3959"",""4705"",""4937"",""3066"",""6427"",""5357"",""5739"",""5011""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""producer"",""GPL Ghostscript 9.25""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""GPL Ghostscript 9.25""
""pdf:docinfo:created"",""2019-10-04T19:50:34Z""
";https://scholar.google.com/scholar?start=680&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094626-1017;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Evmfuzzer: detect evm vulnerabilities via fuzz testing;Y Fu, M Ren, F Ma, H Shi, X Yang, Y Jiang… ; Proceedings of the …, 2019  dl.acm.org;;"… Finally, EVMFuzzer leverages benchmark EVMs as cross-referencing oracles to avoid manual

checking … [11] Etherscan. 2018. Ethereum (eth) blockchain explorer. https://etherscan.io/. [12]

Ying Fu, Meng Ren, Fuchen Ma, Yu Jiang, Heyuan Shi, and J. Tangting Sun. 2019 …";Cité 16 fois;Les 4 versions;[PDF] acm.org;https://dl.acm.org/doi/pdf/10.1145/3338906.3341175?casa_token=ae8kkUaYXT0AAAAA:BiheKluLVTsHIkI1aLZo_Fkey8jLep9GVjEll4uDyQW8lcpDXqINyZkgQDcDgezPrSUeisldB28;;;https://scholar.google.com/scholar?start=830&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094658-1157;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Assessment of the key-reuse resilience of NewHope;A Bauer, H Gilbert, G Renault, M Rossi ; Cryptographers' Track at the RSA …, 2019  Springer;;"… The danger of accessing a key mismatch oracle within some key agreement protocols in a key

share reuse context has been already exposed several times … Bleichenbacher's attack against

RSA PKCS\(\#\1 of Crypto'98 [4] can been viewed as an early reaction attack …";Cité 30 fois;Les 11 versions;[PDF] archives-ouvertes.fr;https://hal.archives-ouvertes.fr/hal-02139910/file/keyreuseresilience.pdf;;"""date"",""2019-01-22T12:47:45Z""
""pdf:PDFVersion"",""1.4""
""pdf:docinfo:title"",""Assessment of the Key-Reuse Resilience of NewHope""
""xmp:CreatorTool"",""HAL""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""Computer Science [cs]/Cryptography and Security [cs.CR], Computer Science [cs]/Symbolic Computation [cs.SC]""
""language"",""en""
""dc:format"",""application/pdf; version=1.4""
""pdf:docinfo:creator_tool"",""HAL""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""Assessment of the Key-Reuse Resilience of NewHope""
""modified"",""2019-01-22T12:47:45Z""
""cp:subject"",""Computer Science [cs]/Cryptography and Security [cs.CR], Computer Science [cs]/Symbolic Computation [cs.SC]""
""pdf:docinfo:subject"",""Computer Science [cs]/Cryptography and Security [cs.CR], Computer Science [cs]/Symbolic Computation [cs.SC]""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""AurĂŠlie Bauer, Henri Gilbert, GuĂŠnaĂŤl Renault, MĂŠlissa Rossi""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017) kpathsea version 6.2.3""
""meta:author"",""AurĂŠlie Bauer, Henri Gilbert, GuĂŠnaĂŤl Renault, MĂŠlissa Rossi""
""trapped"",""False""
""meta:creation-date"",""2021-04-09T15:06:16Z""
""created"",""2021-04-09T15:06:16Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2021-04-09T15:06:16Z""
""resourceName"",""keyreuseresilience.pdf""
""Author"",""AurĂŠlie Bauer, Henri Gilbert, GuĂŠnaĂŤl Renault, MĂŠlissa Rossi""
""producer"",""PDFLaTeX""
""pdf:docinfo:producer"",""PDFLaTeX""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""1"",""0"",""0"",""0"",""0"",""0"",""9"",""13"",""4"",""3"",""1"",""24"",""41"",""25"",""17"",""14"",""4"",""18"",""5"",""13"",""15"",""10"",""0"",""0"",""0"",""25"",""37"",""12"",""1""
""Keywords"",""PQ-crypto, Lattice based cryptography, Active attack, Side channels""
""access_permission:modify_annotations"",""true""
""dc:creator"",""AurĂŠlie Bauer, Henri Gilbert, GuĂŠnaĂŤl Renault, MĂŠlissa Rossi""
""dcterms:created"",""2021-04-09T15:06:16Z""
""Last-Modified"",""2019-01-22T12:47:45Z""
""dcterms:modified"",""2019-01-22T12:47:45Z""
""title"",""Assessment of the Key-Reuse Resilience of NewHope""
""Last-Save-Date"",""2019-01-22T12:47:45Z""
""pdf:docinfo:keywords"",""PQ-crypto, Lattice based cryptography, Active attack, Side channels""
""pdf:docinfo:modified"",""2019-01-22T12:47:45Z""
""meta:save-date"",""2019-01-22T12:47:45Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017) kpathsea version 6.2.3""
""Content-Length"",""883127""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""AurĂŠlie Bauer, Henri Gilbert, GuĂŠnaĂŤl Renault, MĂŠlissa Rossi""
""dc:subject"",""PQ-crypto, Lattice based cryptography, Active attack, Side channels""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""30""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""901"",""1999"",""2599"",""2523"",""2571"",""2563"",""2235"",""2299"",""1516"",""1661"",""2473"",""1229"",""1859"",""1545"",""1971"",""1354"",""1641"",""1672"",""1323"",""1693"",""1610"",""1228"",""2335"",""2647"",""1589"",""10"",""1683"",""1171"",""1567"",""475""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""PQ-crypto, Lattice based cryptography, Active attack, Side channels""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2021-04-09T15:06:16Z""
";https://scholar.google.com/scholar?start=970&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094576-801;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[PDF][PDF] Identity-Based Encryption with Security against the KGC: A Formal Model and Its Instantiations.;K Emura, S Katsumata, Y Watanabe ; IACR Cryptol. ePrint Arch., 2019  eprint.iacr.org;;"… and a pairing-based construction based on the Boneh–Franklin IBE scheme (CRYPTO 2001)

and … addition, A is allowed to access two oracles, namely, the key-generation and encryption

oracles … secret key skID for a randomly chosen identity ID from the key-generation oracle …";Autres articles;Version HTML;[PDF] iacr.org;https://eprint.iacr.org/2019/1384.pdf;;"""date"",""2019-12-01T23:46:01Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2019-12-01T23:46:01Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.20 (TeX Live 2019/W32TeX) kpathsea version 6.3.1""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2019-12-01T23:46:01Z""
""created"",""2019-12-01T23:46:01Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-12-01T23:46:01Z""
""resourceName"",""1384.pdf""
""Author"",""""
""producer"",""pdfTeX-1.40.20""
""pdf:docinfo:producer"",""pdfTeX-1.40.20""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""12"",""33"",""22"",""8"",""9"",""11"",""10"",""12"",""12"",""19"",""14"",""17"",""6"",""27"",""23"",""11"",""24"",""7"",""14"",""2"",""2"",""17"",""1"",""16"",""3"",""3"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2019-12-01T23:46:01Z""
""Last-Modified"",""2019-12-01T23:46:01Z""
""dcterms:modified"",""2019-12-01T23:46:01Z""
""title"",""""
""Last-Save-Date"",""2019-12-01T23:46:01Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2019-12-01T23:46:01Z""
""meta:save-date"",""2019-12-01T23:46:01Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.20 (TeX Live 2019/W32TeX) kpathsea version 6.3.1""
""Content-Length"",""460195""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""32""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""2419"",""3604"",""3740"",""3525"",""3027"",""2305"",""2287"",""2513"",""2648"",""2977"",""2965"",""2529"",""2737"",""2114"",""2784"",""2931"",""3012"",""2458"",""3099"",""3103"",""3087"",""2928"",""2395"",""2733"",""1670"",""2888"",""2910"",""2894"",""2630"",""2241"",""2107"",""2182""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-12-01T23:46:01Z""
";https://scholar.google.com/scholar?start=620&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094593-873;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[HTML][HTML] Building a digital twin for additive manufacturing through the exploitation of blockchain: A case analysis of the aircraft industry;C Mandolla, AM Petruzzelli, G Percoco, A Urbinati ; Computers in Industry, 2019  Elsevier;;"… To date, more than one billion dollars in venture capital funds have flowed into

Blockchain and cryptocurrency, mainly into applications, platforms, and other

start-ups [43]. Despite this exuberance, much of the Blockchain ecosystem …";Cité 65 fois;Les 3 versions;[HTML] sciencedirect.com;https://www.sciencedirect.com/science/article/pii/S0166361518308741?casa_token=XaglGCktGBQAAAAA:VOfk5PZJLVD9w_nE9I4bIyakNk0eINUS5oyP1ZSzDV2CgXZ2aDqiWtl5vnncIa6sIkVNN5a7;;;https://scholar.google.com/scholar?start=690&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094619-990;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[HTML][HTML] A provable secure key-escrow-free identity-based signature scheme without using secure channel at the phase of private key issuance;SC Sahana, ML Das, B Bhuyan ; S?dhan?, 2019  Springer;;"… oracles that can be accessed by the adversary A. A brief description of these oracles is given

here. 1. Create user and extract public key: Upon receiving an identity ID \(\in \{0,1\}^*\ if the ID

has already been created, nothing is to be carried out. Otherwise, this oracle runs the …";Cité 2 fois;Les 4 versions;[HTML] springer.com;https://idp.springer.com/authorize/casa?redirect_uri=https://link.springer.com/article/10.1007/s12046-019-1117-x&casa_token=sbnkF-q1OqMAAAAA:sY8rE8k8pcodRI9Lvi8eFVEtj7LiGuMGeNjGXHheFENyvWwkN-ttVBshyFQAvcFCuWFesDvE74wDp6c;;"""dc.publisher"",""Springer""
""og:image"",""https://media.springernature.com/w200/springer-static/cover/journal/12046.jpg""
""twitter:card"",""summary""
""og:site_name"",""Sādhanā""
""citation_reference"",""citation_title=Handbook of applied cryptography; citation_publication_date=1996; citation_id=CR1; citation_author=A Menezes; citation_author=S Vanstone; citation_author=PC Oorschot; citation_publisher=CRC Press"",""citation_title=Certificateless Public Key Cryptography; citation_inbook_title=Advances in Cryptology - ASIACRYPT 2003; citation_publication_date=2003; citation_pages=452-473; citation_id=CR2; citation_author=Sattam S. Al-Riyami; citation_author=Kenneth G. Paterson; citation_publisher=Springer Berlin Heidelberg"",""citation_title=Identity-based cryptosystems and signature schemes; citation_inbook_title=Advances in Cryptology-CRYPTO, LNCS 196; citation_publication_date=1984; citation_pages=47-53; citation_id=CR3; citation_author=A Shamir; citation_publisher=Springer-Verlag"",""citation_title=A paradoxical identity-based signature scheme resulting from zero-knowledge; citation_inbook_title=Advances in Cryptology-CRYPTO, LCNS 403; citation_publication_date=1988; citation_pages=216-231; citation_id=CR4; citation_author=L Guillou; citation_author=JJ Quisquater; citation_publisher=Springer-Verlag"",""citation_title=How to prove yourself: practical solutions to identification and signature problems; citation_inbook_title=Advances in Cryptology-CRYPTO’86, LCNS 263; citation_publication_date=1986; citation_pages=186-194; citation_id=CR5; citation_author=A Fiat; citation_author=A Shamir; citation_publisher=Springer-Verlag"",""citation_journal_title=Front. Electr. Electron. Eng. China; citation_title=ID-based signatures schemes from bilinear pairing: a survey; citation_author=A Sahu Rajeev, P Sahadeo; citation_volume=6; citation_issue=4; citation_publication_date=2011; citation_pages=487-500; citation_doi=10.1007/s11460-011-0119-1; citation_id=CR6"",""citation_title=Identity-based encryption from the Weil pairing; citation_inbook_title=Advances in Cryptology-CRYPTO 2001; citation_publication_date=2001; citation_pages=213-229; citation_id=CR7; citation_author=D Boneh; citation_author=M Franklin; citation_publisher=Springer"","" Barreto P S L M 2007 The pairing-based crypto lounge.                      http://paginas.terra.com.br/informatica/paulobarreto/pblounge.html                                        . Accessed date 15th October, 2017"",""citation_journal_title=Inf. Sci.; citation_title=Security analysis of an identity-based strongly unforgeable signature scheme; citation_author=K Lee, DH Lee; citation_volume=286; citation_publication_date=2014; citation_pages=29-34; citation_doi=10.1016/j.ins.2014.07.022; citation_id=CR9"",""citation_journal_title=IJ Netw. Secur.; citation_title=Provably secure online/off-line identity-based signature scheme for wireless sensor network; citation_author=J Kar; citation_volume=16; citation_issue=1; citation_publication_date=2014; citation_pages=29-39; citation_id=CR10"",""Joonsang B and Yuliang Z 2004 Identity-based threshold signature scheme from the bilinear pairings. In: IEEE International Conference on Information Technology: Coding and Computing, Information Assurance and Security Track, IEEE Computer Society. ISBN: 0-7695-2108-8/04, pp. 124–128"",""citation_title=Applications of Multiple Trust Authorities in Pairing Based Cryptosystems; citation_inbook_title=Infrastructure Security; citation_publication_date=2002; citation_pages=260-275; citation_id=CR12; citation_author=L. Chen; citation_author=K. Harrison; citation_author=D. Soldera; citation_author=N. P. Smart; citation_publisher=Springer Berlin Heidelberg"",""citation_title=Certificate-Based Encryption and the Certificate Revocation Problem; citation_inbook_title=Lecture Notes in Computer Science; citation_publication_date=2003; citation_pages=272-293; citation_id=CR13; citation_author=Craig Gentry; citation_publisher=Springer Berlin Heidelberg"",""Lee B, Boyd C, Dawson E, Kim K, Yang J and Yoo S 2004 Secure key issuing in ID-based cryptography. In: Proceedings of the Australian Information Security Workshop, AISW-04, pp. 69–74"",""Das M L, Saxena A and Phatak D B 2007 A proxy signature scheme with effective revocation using bilinear pairings. Arxiv preprint 07                      arXiv:0712.3084                                                                 "",""citation_journal_title=Cryptologia; citation_title=A key escrow-free identity-based signature scheme without using secure channel; citation_author=ML Das; citation_volume=35; citation_issue=1; citation_publication_date=2010; citation_pages=58-72; citation_doi=10.1080/01611194.2010.515905; citation_id=CR16"",""citation_title=A course in number theory and cryptography; citation_publication_date=1994; citation_id=CR17; citation_author=N Koblitz; citation_publisher=Springer Science & Business Media"",""citation_title=Proceedings of elliptic curve cryptography-04; citation_publication_date=2004; citation_id=CR18; citation_author=D Hankerson; citation_author=A Menezes; citation_author=S Vanstone; citation_publisher=Springer"",""citation_title=An efficient identity based signature schemes based on pairings; citation_inbook_title=Selected Areas in Cryptography, SAC2002, LCNS 2595; citation_publication_date=2002; citation_pages=310-324; citation_id=CR19; citation_author=F Hess; citation_publisher=Springer-Verlag"",""citation_journal_title=Groups Complex. Cryptol.; citation_title=Key-escrow free multi-signature scheme using bilinear pairings; citation_author=ML Das; citation_volume=7; citation_issue=1; citation_publication_date=2015; citation_pages=47-57; citation_id=CR20"",""citation_title=Security Proofs for Signature Schemes; citation_inbook_title=Advances in Cryptology — EUROCRYPT ’96; citation_publication_date=1996; citation_pages=387-398; citation_id=CR21; citation_author=David Pointcheval; citation_author=Jacques Stern; citation_publisher=Springer Berlin Heidelberg"",""Huang X, Yi M, Willy S, Wong D and Wei W 2007 Certificateless signature revisited. In: Information Security and Privacy. Berlin/Heidelberg: Springer, pp. 308–322"",""Cha C J and Cheon J H 2003 An identity-based signature from gap Diffie–Hellman groups. In: Proceedings of the International Workshop on Public Key Cryptography. Berlin/Heidelberg: Springer, pp. 18–30"",""citation_title=Efficient Identity-Based Signatures and Blind Signatures; citation_inbook_title=Cryptology and Network Security; citation_publication_date=2005; citation_pages=120-133; citation_id=CR24; citation_author=Zhenjie Huang; citation_author=Kefei Chen; citation_author=Yumin Wang; citation_publisher=Springer Berlin Heidelberg"",""citation_journal_title=J. Cryptol.; citation_title=Security arguments for digital signatures and blind signatures; citation_author=P David, J Stern; citation_volume=13; citation_issue=3; citation_publication_date=2000; citation_pages=361-396; citation_doi=10.1007/s001450010003; citation_id=CR25"",""The pairing based cryptography (pbc) library.                      https://crypto.stanford.edu/pbc/                                        . Accessed date 17th October, 2017""
""citation_journal_title"",""Sādhanā""
""language"",""en""
""citation_cover_date"",""2019/06/01""
""og:description"",""The identity-based cryptosystems furnish us with simplest key management procedures. Yet, they have a very slow adoption in cryptography due to the key escrow problem and the necessity of a secure channel between the user and the Private Key Generator (PKG) to transmit the created private key to the user. In this paper, we propose an identity-based signature scheme that not only solves the key escrow problem but also eliminates the requirement of the secure channel. The proposed scheme is secure against existential forgery under adaptively chosen message and ID attacks in the random oracle model assuming the hardness of the Computational Diffie–Hellmann Problem (CDHP). Furthermore, we compare the efficiency of our scheme to that of a similar established scheme.""
""prism.issn"",""0973-7677""
""citation_author_email"",""subhas.sahana@gmail.com"",""maniklal@gmail.com"",""b.bhuyan@gmail.com""
""twitter:image:alt"",""Content cover image""
""prism.number"",""6""
""citation_issn"",""0973-7677""
""citation_language"",""en""
""dc:title"",""A provable secure key-escrow-free identity-based signature scheme without using secure channel at the phase of private key issuance | SpringerLink""
""Content-Encoding"",""UTF-8""
""citation_pdf_url"",""https://link.springer.com/content/pdf/10.1007/s12046-019-1117-x.pdf""
""citation_lastpage"",""9""
""DOI"",""10.1007/s12046-019-1117-x""
""citation_journal_abbrev"",""Sādhanā""
""prism.rightsAgent"",""journalpermissions@springernature.com""
""citation_author"",""SUBHAS CHANDRA SAHANA"",""MANIK LAL DAS"",""BUBU BHUYAN""
""resourceName"",""casa""
""dc.date"",""2019-05-06""
""citation_springer_api_url"",""http://api.springer.com/metadata/pam?q=doi:10.1007/s12046-019-1117-x&api_key=""
""citation_issue"",""6""
""prism.volume"",""44""
""prism.publicationName"",""Sādhanā""
""citation_doi"",""10.1007/s12046-019-1117-x""
""dc.title"",""A provable secure key-escrow-free identity-based signature scheme without using secure channel at the phase of private key issuance""
""prism.url"",""https://link.springer.com/article/10.1007/s12046-019-1117-x""
""citation_volume"",""44""
""dc.language"",""En""
""Content-Language"",""en""
""format-detection"",""telephone=no""
""citation_publication_date"",""2019/06""
""prism.endingPage"",""9""
""citation_title"",""A provable secure key-escrow-free identity-based signature scheme without using secure channel at the phase of private key issuance""
""citation_author_institution"",""Department of Information Technology, North Eastern Hill University, Shillong, India"",""Faculty Block 2, Dhirubhai Ambani Institute of Information and Communication Technology (DA-IICT), Gandhinagar, India"",""Department of Information Technology, North Eastern Hill University, Shillong, India""
""access"",""No""
""citation_publisher"",""Springer India""
""applicable-device"",""pc,mobile""
""dc.format"",""text/html""
""description"",""The identity-based cryptosystems furnish us with simplest key management procedures.  Yet, they have a very slow adoption in cryptography due to the key es""
""title"",""A provable secure key-escrow-free identity-based signature scheme without using secure channel at the phase of private key issuance | SpringerLink""
""citation_online_date"",""2019/05/06""
""twitter:site"",""@SpringerLink""
""dc.source"",""Sādhanā 2019 44:6""
""dc.type"",""OriginalPaper""
""dc.copyright"",""2019 Indian Academy of Sciences""
""dc.creator"",""SUBHAS CHANDRA SAHANA"",""MANIK LAL DAS"",""BUBU BHUYAN""
""citation_fulltext_html_url"",""https://link.springer.com/article/10.1007/s12046-019-1117-x""
""prism.publicationDate"",""2019-05-06""
""Content-Type"",""text/html; charset=UTF-8""
""journal_id"",""12046""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""dc.description"",""The identity-based cryptosystems furnish us with simplest key management procedures.  Yet, they have a very slow adoption in cryptography due to the key escrow problem and the necessity of a secure channel between the user and the Private Key Generator (PKG) to transmit the created private key to the user. In this paper, we propose an identity-based signature scheme that not only solves the key escrow problem but also eliminates the requirement of the secure channel. The proposed scheme is secure against existential forgery under adaptively chosen message and ID attacks in the random oracle model assuming the hardness of the Computational Diffie–Hellmann Problem (CDHP). Furthermore, we compare the efficiency of our scheme to that of a similar established scheme.""
""og:type"",""article""
""citation_article_type"",""Article""
""og:title"",""A provable secure key-escrow-free identity-based signature scheme without using secure channel at the phase of private key issuance""
""prism.doi"",""doi:10.1007/s12046-019-1117-x""
""X-UA-Compatible"",""IE=edge""
""citation_firstpage"",""1""
""prism.startingPage"",""1""
""viewport"",""width=device-width, initial-scale=1""
""dc.rightsAgent"",""journalpermissions@springernature.com""
""prism.section"",""OriginalPaper""
""dc.identifier"",""doi:10.1007/s12046-019-1117-x""
""dc.subject"",""Engineering, general""
""og:url"",""https://link.springer.com/article/10.1007/s12046-019-1117-x""
""prism.copyright"",""2019 Indian Academy of Sciences""
";https://scholar.google.com/scholar?start=800&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094534-627;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Blockchain-based contract signing protocol for confidential contracts;M Mut;Puigserver, MM PayerasCapellŕ…  2019 IEEE/ACS 16th …, 2019  ieeexplore.ieee.org;;"… Jan. 2019. [5] HR Hasan, K. Salah. Proof of delivery of digital assets using blockchain and smart

contracts. IEEE Access 6, 65439-65448, 2018. [6] Q. Huang, G. Yang, D. Wong, W. Susilo, ”A

new efficient optimistic fair exchange protocol without random oracles”, Int …";Cité 1 fois;Les 2 versions;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/9006726/9035208/09035363.pdf?casa_token=WMHyx_uql0EAAAAA:-hpt5o-IzGOdca9s32OyhsBb3f1Z0NKtfxewoVrXqCEGS4Ze59t9ML6FIYpEo2_0RC-ectxMam0;;"""og:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""twitter:title"",""Blockchain-Based Contract Signing Protocol for Confidential Contracts""
""twitter:card"",""summary""
""Description"",""Contract signing is a trust service that requires a fair exchange of elements: each signer's signature on the contract. This kind of service usually relies heav""
""og:title"",""Blockchain-Based Contract Signing Protocol for Confidential Contracts""
""resourceName"",""09035363.pdf""
""language"",""en""
""title"",""Blockchain-Based Contract Signing Protocol for Confidential Contracts | IEEE Conference Publication | IEEE Xplore""
""og:description"",""Contract signing is a trust service that requires a fair exchange of elements: each signer's signature on the contract. This kind of service usually relies heavily on the use of trusted third parties. These entities are an obstacle to extend the use of this service. In this paper we use blockchain-based technologies to provide a contract signing protocol that removes completely the involvement of trusted third parties while satisfying the requirements of this kind of service. We present a protocol that can be used for the signature of public contracts but also for the signature of private and confidential contracts. The protocol has been designed taking into account its possible extension to multiparty contracts.""
""twitter:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-UA-Compatible"",""IE=Edge""
""viewport"",""width=device-width, initial-scale=1.0""
""dc:title"",""Blockchain-Based Contract Signing Protocol for Confidential Contracts | IEEE Conference Publication | IEEE Xplore""
""twitter:description"",""Contract signing is a trust service that requires a fair exchange of elements: each signer's signature on the contract. This kind of service usually relies heavily on the use of trusted third parties. These entities are an obstacle to extend the use of this service. In this paper we use blockchain-based technologies to provide a contract signing protocol that removes completely the involvement of trusted third parties while satisfying the requirements of this kind of service. We present a protocol that can be used for the signature of public contracts but also for the signature of private and confidential contracts. The protocol has been designed taking into account its possible extension to multiparty contracts.""
""Content-Encoding"",""UTF-8""
""Content-Type-Hint"",""text/html; charset=utf-8""
""Content-Length"",""40184""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=440&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094607-936;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Certificateless Authenticated Key Agreement for Decentralized WBANs;M Gervais, L Sun, K Wang, F Li ; International Conference on Frontiers in …, 2019  Springer;;"… It is a mechanism used in blockchain to make an agreement on data value or network state among

the distributed … Every party possesses an identity \(ID_{i}\). The characteristics of A represented

by the number of oracles kept by \(\mathcal {C}\). Assume that an oracle \(\phi ^{r …";Cité 1 fois;Les 3 versions;null;;;;https://scholar.google.com/scholar?start=750&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094612-954;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Tight quantum security of the Fiat-Shamir transform for commit-and-open identification schemes with applications to post-quantum signature schemes;A Chailloux ; arXiv preprint arXiv:1906.05415, 2019  arxiv.org;;"… 1 Page 2. translating the Random Oracle Model1 (ROM) to the Quantum ROM (QROM) and

we need to rewrite all the security proofs involving the QROM … However, we only have black

box access to ? and we don't have access to a inversion oracle …";Cité 4 fois;Les 13 versions;[PDF] arxiv.org;https://arxiv.org/pdf/1906.05415;;"""date"",""2021-03-17T02:42:58Z""
""pdf:PDFVersion"",""1.4""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.4""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""xmp:CreateDate"",""2021-03-16T22:42:58Z""
""modified"",""2021-03-17T02:42:58Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""xmp:ModifyDate"",""2021-03-16T22:42:58Z""
""pdf:docinfo:creator"",""""
""meta:author"",""""
""meta:creation-date"",""2021-03-17T02:42:58Z""
""created"",""2021-03-17T02:42:58Z""
""xmp:About"",""uuid:0862b801-bee7-11f6-0000-04c9ac5af3af""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2021-03-17T02:42:58Z""
""resourceName"",""1906.05415""
""Author"",""""
""producer"",""dvips + GPL Ghostscript GIT PRERELEASE 9.22""
""pdf:docinfo:producer"",""dvips + GPL Ghostscript GIT PRERELEASE 9.22""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""5"",""4"",""6"",""2"",""22"",""12"",""4"",""0"",""6"",""23"",""13"",""42"",""5"",""20"",""11"",""76"",""38"",""47"",""41"",""38"",""9"",""0"",""0"",""0"",""3"",""44"",""5"",""6""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2021-03-17T02:42:58Z""
""Last-Modified"",""2021-03-17T02:42:58Z""
""dcterms:modified"",""2021-03-17T02:42:58Z""
""title"",""""
""xmpMM:DocumentID"",""uuid:0862b801-bee7-11f6-0000-04c9ac5af3af""
""Last-Save-Date"",""2021-03-17T02:42:58Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2021-03-17T02:42:58Z""
""meta:save-date"",""2021-03-17T02:42:58Z""
""Content-Length"",""398232""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""32""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""2421"",""2875"",""3237"",""2871"",""2807"",""2750"",""3064"",""3019"",""2621"",""2219"",""2774"",""2591"",""1632"",""1925"",""2028"",""1883"",""1955"",""1897"",""2465"",""1931"",""1339"",""1740"",""1744"",""1558"",""2275"",""2209"",""2174"",""234"",""1614"",""1826"",""1623"",""858""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2021-03-17T02:42:58Z""
";https://scholar.google.com/scholar?start=770&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094600-901;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[PDF][PDF] Efficient Controlled Signature for a Large Network with Multi Security-level Setting.;P Thorncharoensri, W Susilo, J Baek ; J. Wirel. Mob. Networks Ubiquitous …, 2019  isyou.info;;"… on a new message M?. This model provides an assurance that, with access to the signing oracle

SSO, the verifying oracle VCO, pkS … To precisely describe the ability of adversaries breaking the

unforgeability of an MLCS scheme, SSO and VCO oracles are illustrated as below …";Cité 1 fois;Les 2 versions;[PDF] isyou.info;http://isyou.info/jowua/papers/jowua-v10n3-1.pdf;;"""date"",""2019-10-20T04:11:24Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2019-10-20T04:11:24Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is MiKTeX-pdfTeX 2.9.6668 (1.40.19)""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2019-10-20T04:11:24Z""
""created"",""2019-10-20T04:11:24Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-10-20T04:11:24Z""
""resourceName"",""jowua-v10n3-1.pdf""
""Author"",""""
""producer"",""pdfTeX-1.40.19""
""pdf:docinfo:producer"",""pdfTeX-1.40.19""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""19"",""2"",""2"",""0"",""6"",""20"",""3"",""17"",""0"",""6"",""0"",""0"",""0"",""0"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2019-10-20T04:11:24Z""
""Last-Modified"",""2019-10-20T04:11:24Z""
""dcterms:modified"",""2019-10-20T04:11:24Z""
""title"",""""
""Last-Save-Date"",""2019-10-20T04:11:24Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2019-10-20T04:11:24Z""
""meta:save-date"",""2019-10-20T04:11:24Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is MiKTeX-pdfTeX 2.9.6668 (1.40.19)""
""Content-Length"",""416199""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""20""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""2883"",""3762"",""4078"",""1928"",""2466"",""2315"",""1921"",""2560"",""2664"",""1498"",""2124"",""1428"",""1871"",""2655"",""2425"",""2179"",""3416"",""3940"",""4033"",""2618""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-10-20T04:11:24Z""
";https://scholar.google.com/scholar?start=720&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094567-768;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Please, do not decentralize the Internet with (permissionless) blockchains!;PG Lopez, A Montresor, A Datta ; 2019 IEEE 39th International …, 2019  ieeexplore.ieee.org;;"… tive models of participation, resource contribution and consensus in crypto-currencies could … of

a core backbone of commercial stable servers to sustain the cryptocurrency, along with … For

example, Oracle's BlockChain Cloud, built on Hyperledger Fabric, can pro- vide blockchain …";Cité 9 fois;Les 8 versions;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/8867821/8884790/08885359.pdf?casa_token=nPqEyWmxO6wAAAAA:hWaYiHD2cekvdxVQXaHubLN97s57ErfdNZT1XMNtL2rBpCtkOsDaNwNpFaqvVJ5wGLa8t8tPISA;;"""og:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""twitter:title"",""Please, do not Decentralize the Internet with (Permissionless) Blockchains!""
""twitter:card"",""summary""
""Description"",""The old mantra of decentralizing the Internet is coming again with fanfare, this time around the blockchain technology hype. We have already seen a technology s""
""og:title"",""Please, do not Decentralize the Internet with (Permissionless) Blockchains!""
""resourceName"",""08885359.pdf""
""language"",""en""
""title"",""Please, do not Decentralize the Internet with (Permissionless) Blockchains! | IEEE Conference Publication | IEEE Xplore""
""og:description"",""The old mantra of decentralizing the Internet is coming again with fanfare, this time around the blockchain technology hype. We have already seen a technology supposed to change the nature of the Internet: peer-to-peer. The reality is that peer-to-peer naming systems failed, peer-to-peer social networks failed, and yes, peer-to-peer storage failed as well. In this paper, we will review the research on distributed systems in the last few years to identify the limits of open peer-to-peer networks. We will address issues like system complexity, security and frailty, instability and performance. We will show how many of the aforementioned problems also apply to the recent breed of permissionless blockchain networks. The applicability of such systems to mature industrial applications is undermined by the same properties that make them so interesting for a libertarian audience: namely, their openness, their pseudo-anonymity and their unregulated cryptocurrencies. As such, we argue that permissionless blockchain networks are unsuitable to be the substrate for a decentralized Internet. Yet, there is still hope for more decentralization, albeit in a form somewhat limited with respect to the libertarian view of decentralized Internet: in cooperation rather than in competition with the superpowerful datacenters that dominate the world today. This is derived from the recent surge in interest in byzantine fault tolerance and permissioned blockchains, which opens the door to a world where use of trusted third parties is not the only way to arbitrate an ensemble of entities. The ability of establish trust through permissioned blockchains enables to move the control from the datacenters to the edge, truly realizing the promises of edge-centric computing.""
""twitter:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-UA-Compatible"",""IE=Edge""
""viewport"",""width=device-width, initial-scale=1.0""
""dc:title"",""Please, do not Decentralize the Internet with (Permissionless) Blockchains! | IEEE Conference Publication | IEEE Xplore""
""twitter:description"",""The old mantra of decentralizing the Internet is coming again with fanfare, this time around the blockchain technology hype. We have already seen a technology supposed to change the nature of the Internet: peer-to-peer. The reality is that peer-to-peer naming systems failed, peer-to-peer social networks failed, and yes, peer-to-peer storage failed as well. In this paper, we will review the research on distributed systems in the last few years to identify the limits of open peer-to-peer networks. We will address issues like system complexity, security and frailty, instability and performance. We will show how many of the aforementioned problems also apply to the recent breed of permissionless blockchain networks. The applicability of such systems to mature industrial applications is undermined by the same properties that make them so interesting for a libertarian audience: namely, their openness, their pseudo-anonymity and their unregulated cryptocurrencies. As such, we argue that permissionless blockchain networks are unsuitable to be the substrate for a decentralized Internet. Yet, there is still hope for more decentralization, albeit in a form somewhat limited with respect to the libertarian view of decentralized Internet: in cooperation rather than in competition with the superpowerful datacenters that dominate the world today. This is derived from the recent surge in interest in byzantine fault tolerance and permissioned blockchains, which opens the door to a world where use of trusted third parties is not the only way to arbitrate an ensemble of entities. The ability of establish trust through permissioned blockchains enables to move the control from the datacenters to the edge, truly realizing the promises of edge-centric computing.""
""Content-Encoding"",""UTF-8""
""Content-Type-Hint"",""text/html; charset=utf-8""
""Content-Length"",""43216""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=580&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094637-1064;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[HTML][HTML] A survey on zero knowledge range proofs and applications;E Morais, T Koens, C Van Wijk, A Koren ; SN Applied Sciences, 2019  Springer;Switzerland;"… For instance, if we consider a cryptocurrency exchange with 2 million clients, current

implementation of … In the context of DLT and blockchain applications, we would like to avoid this …

of this heuristic is that it makes the cryptosystem secure under the random oracle model [4] (ROM …";Cité 15 fois;Les 6 versions;[HTML] springer.com;https://idp.springer.com/authorize/casa?redirect_uri=https://link.springer.com/article/10.1007/s42452-019-0989-z&casa_token=pM6RLqPOSRQAAAAA:RbepzGQlY-tg9NhbYnusb1MeVLTVkXb4z8aLFotRYM3GpYB_sn8g69t_s8tY6PWn5notN3gsPYoX4AY;;"""dc.publisher"",""Springer""
""og:image"",""https://media.springernature.com/w200/springer-static/cover/journal/42452.jpg""
""twitter:card"",""summary""
""og:site_name"",""SN Applied Sciences""
""citation_reference"",""Adida B (2008) Helios: web-based open-audit voting. In: Proceedings of the 17th conference on security symposium, SS’08, USENIX Association, Berkeley, pp 335–348"",""Baldimtsi F, Camenisch J, Dubovitskaya M, Lysyanskaya A, Reyzin L, Samelin K, Yakoubov S (2017) Accumulators with applications to anonymity-preserving revocation. In: 2017 IEEE European symposium on security and privacy, EuroS&P 2017, Paris, 26–28 April 2017, pp 301–315"",""citation_title=Pairing-friendly elliptic curves of prime order; citation_inbook_title=Selected areas in cryptography; citation_publication_date=2006; citation_pages=319-331; citation_id=CR3; citation_author=P Barreto; citation_author=M Naehrig; citation_publisher=Springer"",""Bellare M, Rogaway P (1993) Random oracles are practical: a paradigm for designing efficient protocols. In: Proceedings of the 1st ACM conference on computer and communications security, CCS ’93, ACM, NY, pp 62–73"",""Boneh D, Bünz B, Fisch B (2018) Batching techniques for accumulators with applications to iops and stateless blockchains. Cryptology ePrint Archive, Report 2018/1188.                    https://eprint.iacr.org/2018/1188                                                             "",""citation_title=Short Signatures from the Weil Pairing; citation_inbook_title=Advances in Cryptology — ASIACRYPT 2001; citation_publication_date=2001; citation_pages=514-532; citation_id=CR6; citation_author=Dan Boneh; citation_author=Ben Lynn; citation_author=Hovav Shacham; citation_publisher=Springer Berlin Heidelberg"",""Bünz B, Bootle J, Boneh D, Poelstra A, Wuille P, Maxwell G (May 2018) Bulletproofs: Short proofs for confidential transactions and more. In: 2018 IEEE symposium on security and privacy (SP), pp 315–334"",""citation_title=Dynamic accumulators and application to efficient revocation of anonymous credentials; citation_inbook_title=Advances in cryptology–CRYPTO 2002; citation_publication_date=2002; citation_pages=61-76; citation_id=CR8; citation_author=J Camenisch; citation_author=A Lysyanskaya; citation_publisher=Springer"",""citation_title=A signature scheme with efficient protocols; citation_inbook_title=Security in communication networks; citation_publication_date=2003; citation_pages=268-289; citation_id=CR9; citation_author=J Camenisch; citation_author=A Lysyanskaya; citation_publisher=Springer"",""citation_title=Efficient group signature schemes for large groups; citation_inbook_title=Advances in cryptology—CRYPTO ’97; citation_publication_date=1997; citation_pages=410-424; citation_id=CR10; citation_author=J Camenisch; citation_author=M Stadler; citation_publisher=Springer"",""citation_title=Efficient protocols for set membership and range proofs; citation_inbook_title=Advances in cryptology—ASIACRYPT 2008; citation_publication_date=2008; citation_pages=234-252; citation_id=CR11; citation_author=J Camenisch; citation_author=R Chaabouni; citation_author=A Shelat; citation_publisher=Springer"",""Camenisch J, Kohlweiss M, Soriente C (2009) An accumulator based on bilinear maps and efficient revocation for anonymous credentials. In: Public key cryptography—PKC 2009, 12th international conference on practice and theory in public key cryptography, Irvine, CA, March 18–20, 2009. Proceedings, pp 481–500"",""citation_title=New results for the practical use of range proofs; citation_inbook_title=Public key infrastructures, services and applications; citation_publication_date=2014; citation_pages=47-64; citation_id=CR13; citation_author=S Canard; citation_author=I Coisel; citation_author=A Jambert; citation_author=J Traoré; citation_publisher=Springer"",""Canetti R, Goldwasser S, Ishai Y, Krawczyk H, Shi E, Tromer E, Venkitasubramaniam M, Zohar A. Zero knowledge proof standardization workshop.                    https://zkproof.org/index.html                                                             "",""Certicom Research (2000) SEC 2: recommended elliptic curve domain parameters. In: Standards for efficient cryptography"",""Chaabouni R (2017) Enhancing privacy protection set membership, range proofs, and the extended access control. p 239"",""citation_title=Additive combinatorics and discrete logarithm based range protocols; citation_inbook_title=Information security and privacy; citation_publication_date=2010; citation_pages=336-351; citation_id=CR17; citation_author=R Chaabouni; citation_author=H Lipmaa; citation_author=A Shelat; citation_publisher=Springer"",""citation_title=A non-interactive range proof with constant communication; citation_inbook_title=Financial cryptography and data security; citation_publication_date=2012; citation_pages=179-199; citation_id=CR18; citation_author=R Chaabouni; citation_author=H Lipmaa; citation_author=B Zhang; citation_publisher=Springer"",""citation_title=Easy come—easy go divisible cash; citation_inbook_title=Advances in cryptology—EUROCRYPT’98; citation_publication_date=1998; citation_id=CR19; citation_author=A Chan; citation_author=Y Frankel; citation_author=Y Tsiounis; citation_publisher=Springer"",""citation_journal_title=Commun ACM; citation_title=Security without identification: transaction systems to make big brother obsolete; citation_author=D Chaum; citation_volume=28; citation_issue=10; citation_publication_date=1985; citation_pages=1030-1044; citation_doi=10.1145/4372.4373; citation_id=CR20"",""Chen G, Chen S, Xiao Y, Zhang Y, Lin Z, Lai TH (2018) SgxPectre attacks: stealing intel secrets from SGX enclaves via speculative execution. In: arXiv, Cornnell University Library.                    https://arxiv.org/abs/1802.09085                                     (visited on 19/09/2018)"",""citation_title=Removing the strong rsa assumption from arguments over the integers; citation_inbook_title=Advances in cryptology—EUROCRYPT 2017; citation_publication_date=2017; citation_pages=321-350; citation_id=CR22; citation_author=G Couteau; citation_author=T Peters; citation_author=D Pointcheval; citation_publisher=Springer International Publishing"",""Dagher G, Bünz B, Bonneau J, Clark J, Boneh D (2015) Provisions: privacy-preserving proofs of solvency for bitcoin exchanges. In: Proceedings of the 22Nd ACM SIGSAC conference on computer and communications security, CCS ’15, ACM, NY, pp 720–731"",""citation_title=Payment systems and credential mechanisms with provable security against abuse by individuals; citation_inbook_title=Advances in cryptology—CRYPTO’ 88; citation_publication_date=1990; citation_pages=328-335; citation_id=CR24; citation_author=IB Damgård; citation_publisher=Springer"",""citation_journal_title=J Cryptol; citation_title=Practical and provably secure release of a secret and exchange of signatures; citation_author=I Damgård; citation_volume=8; citation_issue=4; citation_publication_date=1995; citation_pages=201-222; citation_doi=10.1007/BF00191356; citation_id=CR25"",""citation_journal_title=Int J Inf Secur; citation_title=A generalization of paillier’s public-key system with applications to electronic voting; citation_author=I Damgård, M Jurik, JB Nielsen; citation_volume=9; citation_issue=6; citation_publication_date=2010; citation_pages=371-385; citation_doi=10.1007/s10207-010-0119-9; citation_id=CR26"",""citation_title=Short signatures without random oracles; citation_inbook_title=Advances in cryptology—EUROCRYPT 2004; citation_publication_date=2004; citation_pages=56-73; citation_id=CR27; citation_author=B Dan; citation_author=B Xavier; citation_publisher=Springer"",""citation_title=Evaluating 2-DNF formulas on ciphertexts; citation_inbook_title=Theory of cryptography; citation_publication_date=2005; citation_pages=325-341; citation_id=CR28; citation_author=B Dan; citation_author=G Eu-Jin; citation_author=N Kobbi; citation_publisher=Springer"",""citation_title=Efficient proofs that a committed number lies in an interval; citation_inbook_title=Advances in cryptology—EUROCRYPT 2000; citation_publication_date=2000; citation_pages=431-444; citation_id=CR29; citation_author=B Fabrice; citation_publisher=Springer"",""citation_title=How to prove yourself: Practical solutions to identification and signature problems; citation_inbook_title=Advances in cryptology—CRYPTO’ 86; citation_publication_date=1987; citation_pages=186-194; citation_id=CR30; citation_author=A Fiat; citation_author=A Shamir; citation_publisher=Springer"",""citation_title=Statistical zero knowledge protocols to prove modular polynomial relations; citation_inbook_title=Advances in cryptology—CRYPTO ’97; citation_publication_date=1997; citation_pages=16-30; citation_id=CR31; citation_author=E Fujisaki; citation_author=T Okamoto; citation_publisher=Springer"",""citation_journal_title=Discrete Appl Math; citation_title=Pairings for cryptographers; citation_author=S Galbraith, K Paterson, N Smart; citation_volume=156; citation_issue=16; citation_publication_date=2008; citation_pages=3113-3121; citation_doi=10.1016/j.dam.2007.12.010; citation_id=CR32"",""citation_title=Foundations of cryptography; citation_publication_date=2006; citation_id=CR33; citation_author=O Goldreich; citation_publisher=Cambridge University Press"",""Goldwasser S, Micali S, Rackoff C (1985) The knowledge complexity of interactive proof-systems. In: Proceedings of the seventeenth annual ACM symposium on theory of computing, STOC ’85, ACM, New York, pp 291–304"",""citation_title=Efficient Zero-Knowledge Arguments from Two-Tiered Homomorphic Commitments; citation_inbook_title=Lecture Notes in Computer Science; citation_publication_date=2011; citation_pages=431-448; citation_id=CR35; citation_author=Jens Groth; citation_publisher=Springer Berlin Heidelberg"",""citation_title=Non-interactive zero-knowledge arguments for voting; citation_inbook_title=Applied cryptography and network security; citation_publication_date=2005; citation_pages=467-482; citation_id=CR36; citation_author=J Groth; citation_publisher=Berlin HeidelbergSpringer"",""citation_title=Short pairing-based non-interactive zero-knowledge arguments; citation_inbook_title=Advances in cryptology—ASIACRYPT 2010; citation_publication_date=2010; citation_pages=321-340; citation_id=CR37; citation_author=J Groth; citation_publisher=Springer"",""citation_title=CM-curves with good cryptographic properties; citation_inbook_title=Advances in cryptology—CRYPTO ’91; citation_publication_date=1992; citation_pages=279-287; citation_id=CR38; citation_author=N Koblitz; citation_publisher=Springer"",""Koens T (2018) Consensus by trusted hardware.                    https://www.linkedin.com/pulse/consensus-trusted-hardware-tommy-koens                                                             "",""Koens T, Ramaekers C, van Wijk C. Efficient zero-knowledge range proofs in ethereum. ING media.                    https://www.ingwb.com/media/2122048/zero-knowledge-range-proof-whitepaper.pdf                                                             "",""Kosba A, Miller A, Shi E, Wen Z, Papamanthou C (2016) Hawk: The blockchain model of cryptography and privacy-preserving smart contracts. In: 2016 IEEE symposium on security and privacy (SP), pp 839–858"",""citation_title=Lattice-based zero-knowledge arguments for integer relations; citation_inbook_title=Advances in cryptology—CRYPTO 2018; citation_publication_date=2018; citation_pages=700-732; citation_id=CR42; citation_author=B Libert; citation_author=S Ling; citation_author=K Nguyen; citation_author=H Wang; citation_publisher=Springer International Publishing"",""citation_title=On diophantine complexity and statistical zero-knowledge arguments; citation_inbook_title=Advances in cryptology—ASIACRYPT 2003; citation_publication_date=2003; citation_pages=398-415; citation_id=CR43; citation_author=H Lipmaa; citation_publisher=Springer"",""citation_title=Secure vickrey auctions without threshold trust; citation_inbook_title=Financial cryptography; citation_publication_date=2003; citation_pages=87-101; citation_id=CR44; citation_author=H Lipmaa; citation_author=N Asokan; citation_author=V Niemi; citation_publisher=Springer"",""citation_title=Pseudonym systems; citation_inbook_title=Selected areas in cryptography; citation_publication_date=2000; citation_pages=184-199; citation_id=CR45; citation_author=A Lysyanskaya; citation_author=RL Rivest; citation_author=A Sahai; citation_author=S Wolf; citation_publisher=Springer"",""Maxwell Gregory (2016) Confidential transactions.                    https://people.xiph.org/~greg/confidential_values.txt                                                             "",""citation_journal_title=Commun ACM; citation_title=Cryptography miracles, secure auctions, matching problem verification; citation_author=S Micali, M Rabin; citation_volume=57; citation_issue=2; citation_publication_date=2014; citation_pages=85-93; citation_doi=10.1145/2574871; citation_id=CR47"",""Morais E, Koens T, van Wijk C. Zero knowledge set membership. ING media.                    https://www.ing.com/Newsroom/All-news/Blockchain-innovation-improves-data-privacy-for-clients.htm                                                             "",""Morais E, Rudgers P, van Wijk C, Koens T, Ramaekers C (2018) Zero knowledge range proof implementation. Github.                    https://github.com/ing-bank/zkrangeproof                                                             "",""Parkes D, Rabin M, Shieber S, Thorpe C (2006) Practical secrecy-preserving, verifiably correct and trustworthy auctions. In: Proceedings of the 8th international conference on electronic commerce: the new e-commerce: innovations for conquering current barriers, obstacles and limitations to conducting successful business on the internet, ICEC ’06, ACM, New York, pp 70–81"",""citation_title=Non-interactive and information-theoretic secure verifiable secret sharing; citation_inbook_title=Advances in cryptology—CRYPTO ’91; citation_publication_date=1992; citation_pages=129-140; citation_id=CR51; citation_author=T Pedersen; citation_publisher=Springer"",""Poelstra A (2016) Mimblewimble.                    https://download.wpsoftware.net/bitcoin/wizardry/mimblewimble.pdf                                                             "",""citation_journal_title=Commun Pure Appl Math; citation_title=Randomized algorithms in number theory; citation_author=MO Rabin, JO Shallit; citation_volume=39; citation_issue=S1; citation_publication_date=1986; citation_pages=S239-S256; citation_doi=10.1002/cpa.3160390713; citation_id=CR53"",""citation_title=Strictly-black-box zero-knowledge and efficient validation of financial transactions; citation_inbook_title=Automata, languages, and programming. ICALP 2012; citation_publication_date=2012; citation_pages=738-749; citation_id=CR54; citation_author=MO Rabin; citation_author=Y Mansour; citation_author=S Muthukrishnan; citation_author=M Yung; citation_publisher=Springer"",""citation_journal_title=J Cryptol; citation_title=Efficient signature generation by smart cards; citation_author=C-P Schnorr; citation_volume=4; citation_issue=3; citation_publication_date=1991; citation_pages=161-174; citation_doi=10.1007/BF00196725; citation_id=CR55"",""Schoenmakers B (2001) Some efficient zero-knowledge proof techniques. In: Workshop on cryptographic protocols"",""Schoenmakers B (2005) Interval proofs revisited. Slides presented at the international workshop on frontiers in electronic elections"",""citation_title=Malware guard extension: using SGX to conceal cache attacks; citation_inbook_title=Detection of intrusions and malware, and vulnerability assessment; citation_publication_date=2017; citation_pages=3-24; citation_id=CR58; citation_author=M Schwarz; citation_author=S Weiser; citation_author=D Gruss; citation_author=C Maurice; citation_author=S Mangard; citation_publisher=Springer International Publishing"",""The World Bank. Guidelines procurement under IBRD loans and IDA credits. The International Bank for Reconstruction and Development.                    http://siteresources.worldbank.org/INTPROCUREMENT/Resources/Procurement-Guidelines-November-2003.pdf                                                             "",""citation_journal_title=Appl Math Comput; citation_title=Still wrong use of pairings in cryptography; citation_author=O Uzunkol, MS Kiraz; citation_volume=333; citation_publication_date=2018; citation_pages=467-479; citation_id=CR60"",""Wood G (2014) Ethereum: A secure decentralized transaction ledger.                    http://gavwood.com/paper.pdf                                                             ""
""citation_journal_title"",""SN Applied Sciences""
""language"",""en""
""citation_cover_date"",""2019/08/01""
""og:description"",""In last years, there has been an increasing effort to leverage distributed ledger technology (DLT), including blockchain. One of the main topics of interest, given its importance, is the research and development of privacy mechanisms, as for example is the case of zero knowledge proofs (ZKP). ZKP is a cryptographic technique that can be used to hide information that is put into the ledger, while still allowing to perform validation of this data. In this work we describe different strategies to construct zero knowledge range proofs (ZKRP), as for example the scheme proposed by Boudot (in: Bart (ed) Advances in cryptology—EUROCRYPT 2000, Springer, Berlin, 2000) in 2001; the one proposed by Camenisch et al. (in: Josef (ed) Advances in cryptology—ASIACRYPT 2008, Springer, Berlin, 2008), and bulletproofs (Bünz et al., in: 2018 IEEE symposium on security and privacy (SP), 2018), proposed in 2017. We also compare these strategies and discuss possible use cases. Since bulletproofs (Bünz et al. 2018) is the most efficient construction, we will give a detailed description of its algorithms and optimizations. Bulletproofs is not only more efficient than previous schemes, but also avoids the trusted setup, which is a requirement that is not desirable in the context of DLT and blockchain. In case of cryptocurrencies, if the setup phase is compromised, it would be possible to generate money out of thin air. Interestingly, bulletproofs can also be used to construct generic ZKP, in the sense that it can be used to prove generic statements, and thus it is not only restricted to ZKRP, but it can be used for any kind of proof of knowledge. Hence Bulletproofs leads to a more powerful tool to provide privacy for DLT. Here we describe in detail the algorithms involved in Bulletproofs protocol for ZKRP. Also, we present our implementation, which was open sourced (Morais et al., in: Zero knowledge range proof implementation, 2018. https://github.com/ing-bank/zkrangeproof ).""
""prism.issn"",""2523-3971""
""citation_author_email"",""eduardo.morais@gmail.com""
""twitter:image:alt"",""Content cover image""
""prism.number"",""8""
""citation_issn"",""2523-3971""
""citation_language"",""en""
""dc:title"",""A survey on zero knowledge range proofs and applications | SpringerLink""
""Content-Encoding"",""UTF-8""
""citation_pdf_url"",""https://link.springer.com/content/pdf/10.1007/s42452-019-0989-z.pdf""
""citation_lastpage"",""17""
""DOI"",""10.1007/s42452-019-0989-z""
""citation_fulltext_world_readable"",""""
""citation_journal_abbrev"",""SN Appl. Sci.""
""prism.rightsAgent"",""journalpermissions@springernature.com""
""citation_author"",""Eduardo Morais"",""Tommy Koens"",""Cees van Wijk"",""Aleksei Koren""
""resourceName"",""casa""
""dc.date"",""2019-07-31""
""citation_springer_api_url"",""http://api.springer.com/metadata/pam?q=doi:10.1007/s42452-019-0989-z&api_key=""
""citation_issue"",""8""
""prism.volume"",""1""
""prism.publicationName"",""SN Applied Sciences""
""citation_doi"",""10.1007/s42452-019-0989-z""
""dc.title"",""A survey on zero knowledge range proofs and applications""
""prism.url"",""https://link.springer.com/article/10.1007/s42452-019-0989-z""
""citation_volume"",""1""
""dc.language"",""En""
""Content-Language"",""en""
""format-detection"",""telephone=no""
""citation_publication_date"",""2019/08""
""prism.endingPage"",""17""
""citation_title"",""A survey on zero knowledge range proofs and applications""
""citation_author_institution"",""ING, Amsterdam, The Netherlands"",""ING, Amsterdam, The Netherlands"",""ING, Amsterdam, The Netherlands"",""ING, Amsterdam, The Netherlands""
""access"",""Yes""
""citation_publisher"",""Springer International Publishing""
""applicable-device"",""pc,mobile""
""dc.format"",""text/html""
""description"",""In last years, there has been an increasing effort to leverage distributed ledger technology (DLT), including blockchain. One of the main topics of interes""
""title"",""A survey on zero knowledge range proofs and applications | SpringerLink""
""citation_online_date"",""2019/07/31""
""twitter:site"",""@SpringerLink""
""dc.source"",""SN Applied Sciences 2019 1:8""
""dc.type"",""OriginalPaper""
""dc.copyright"",""2019 Springer Nature Switzerland AG""
""dc.creator"",""Eduardo Morais"",""Tommy Koens"",""Cees van Wijk"",""Aleksei Koren""
""citation_fulltext_html_url"",""https://link.springer.com/article/10.1007/s42452-019-0989-z""
""prism.publicationDate"",""2019-07-31""
""Content-Type"",""text/html; charset=UTF-8""
""journal_id"",""42452""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""dc.description"",""In last years, there has been an increasing effort to leverage distributed ledger technology (DLT), including blockchain. One of the main topics of interest, given its importance, is the research and development of privacy mechanisms, as for example is the case of zero knowledge proofs (ZKP). ZKP is a cryptographic technique that can be used to hide information that is put into the ledger, while still allowing to perform validation of this data. In this work we describe different strategies to construct zero knowledge range proofs (ZKRP), as for example the scheme proposed by Boudot (in: Bart (ed) Advances in cryptology—EUROCRYPT 2000, Springer, Berlin, 2000) in 2001; the one proposed by Camenisch et al. (in: Josef (ed) Advances in cryptology—ASIACRYPT 2008, Springer, Berlin, 2008), and bulletproofs (Bünz et al., in: 2018 IEEE symposium on security and privacy (SP), 2018), proposed in 2017. We also compare these strategies and discuss possible use cases. Since bulletproofs (Bünz et al. 2018) is the most efficient construction, we will give a detailed description of its algorithms and optimizations. Bulletproofs is not only more efficient than previous schemes, but also avoids the trusted setup, which is a requirement that is not desirable in the context of DLT and blockchain. In case of cryptocurrencies, if the setup phase is compromised, it would be possible to generate money out of thin air. Interestingly, bulletproofs can also be used to construct generic ZKP, in the sense that it can be used to prove generic statements, and thus it is not only restricted to ZKRP, but it can be used for any kind of proof of knowledge. Hence Bulletproofs leads to a more powerful tool to provide privacy for DLT. Here we describe in detail the algorithms involved in Bulletproofs protocol for ZKRP. Also, we present our implementation, which was open sourced (Morais et al., in: Zero knowledge range proof implementation, 2018.                  https://github.com/ing-bank/zkrangeproof                                ).""
""og:type"",""article""
""citation_article_type"",""Research Article""
""og:title"",""A survey on zero knowledge range proofs and applications""
""prism.doi"",""doi:10.1007/s42452-019-0989-z""
""X-UA-Compatible"",""IE=edge""
""citation_firstpage"",""1""
""prism.startingPage"",""1""
""viewport"",""width=device-width, initial-scale=1""
""dc.rightsAgent"",""journalpermissions@springernature.com""
""prism.section"",""OriginalPaper""
""dc.identifier"",""doi:10.1007/s42452-019-0989-z""
""dc.subject"",""Engineering, general"",""Materials Science, general"",""Earth Sciences, general"",""Applied and Technical Physics"",""Chemistry/Food Science, general"",""Environment, general""
""og:url"",""https://link.springer.com/article/10.1007/s42452-019-0989-z""
""prism.copyright"",""2019 Springer Nature Switzerland AG""
";https://scholar.google.com/scholar?start=880&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094551-697;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[PDF][PDF] Blockchain perspectives on privacy protection and interactive network Assistance;MJM KIKI, Z Jianbiao, S SAKHO… ; International Journal of …, 2019  academia.edu;;"… Sub-linear size traceable ring signatures without random oracles. IEICE Transactions on

Fundamentals of Electronics, Communications and Computer Sciences, E95.A(1):151–166,

2012 … Applications of blockchain technology beyond cryptocurrency …";Autres articles;Version HTML;[PDF] academia.edu;https://www.academia.edu/download/58598160/16_Paper_31011931_IJCSIS_Camera_Ready_pp119-123.pdf;;;https://scholar.google.com/scholar?start=510&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094612-959;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Adaptively secure proxy re-encryption;G Fuchsbauer, C Kamath, K Klein… ; … International Workshop on …, 2019  Springer;;"… (CRYPTO'17) proposed a framework that in some cases allows to give adaptive security proofs

for schemes which were previously only … security definition can be strengthened to

chosen-ciphertext attack (CCA) by allowing the adversary access to a decryption oracle which …";Cité 11 fois;Les 8 versions;[PDF] iacr.org;https://eprint.iacr.org/2018/426.pdf;;"""date"",""2018-06-18T08:06:40Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2018-06-18T08:06:40Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016) kpathsea version 6.2.2""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2018-06-18T08:06:40Z""
""created"",""2018-06-18T08:06:40Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2018-06-18T08:06:40Z""
""resourceName"",""426.pdf""
""Author"",""""
""producer"",""pdfTeX-1.40.17""
""pdf:docinfo:producer"",""pdfTeX-1.40.17""
""pdf:unmappedUnicodeCharsPerPage"",""3"",""0"",""0"",""0"",""4"",""0"",""0"",""0"",""17"",""22"",""20"",""31"",""4"",""0"",""20"",""29"",""11"",""2"",""2"",""5"",""14"",""16"",""7"",""15"",""26"",""15"",""4"",""24"",""37"",""36"",""16"",""24"",""18"",""36"",""18"",""26"",""35"",""8"",""35"",""6"",""42"",""36"",""0"",""3"",""20"",""33"",""8"",""11"",""4""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2018-06-18T08:06:40Z""
""Last-Modified"",""2018-06-18T08:06:40Z""
""dcterms:modified"",""2018-06-18T08:06:40Z""
""title"",""""
""Last-Save-Date"",""2018-06-18T08:06:40Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2018-06-18T08:06:40Z""
""meta:save-date"",""2018-06-18T08:06:40Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016) kpathsea version 6.2.2""
""Content-Length"",""611539""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""49""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""2195"",""2545"",""2580"",""2631"",""2742"",""2925"",""2635"",""1858"",""1679"",""1943"",""1874"",""1855"",""2152"",""730"",""1853"",""1444"",""2071"",""2136"",""2255"",""1853"",""1958"",""2240"",""2521"",""2198"",""1947"",""2363"",""1885"",""1664"",""1959"",""1882"",""1728"",""1915"",""1897"",""1994"",""2284"",""2029"",""1804"",""1994"",""1830"",""2082"",""1928"",""2191"",""2518"",""2544"",""905"",""1859"",""2449"",""1810"",""1633""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2018-06-18T08:06:40Z""
";https://scholar.google.com/scholar?start=770&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094555-714;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[CITATION][C] Blockchain-Technologie in der Logistik: Darstellung der Einsatzmöglichkeit der Blockchain ab Version 2.0, sowie der Grundlagen für die Implementierung;D Horwath ;2019 GRIN Verlag;;null;Autres articles;;null;;;;https://scholar.google.com/scholar?start=530&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094612-958;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Adaptively secure constrained pseudorandom functions;D Hofheinz, A Kamath, V Koppula, B Waters ; International Conference on …, 2019  Springer;;"… It could even be the case that an existing blockchain could be obliviously … not adaptively secure),

used subexponential assumptions and the random oracle model … the problem of achieving

adaptive security from indistinguishability obfuscation alone, avoiding random oracles …";Cité 29 fois;Les 6 versions;[PDF] ethz.ch;https://people.inf.ethz.ch/dhofheinz/pdf/conf/fc/HofheinzKKW19.pdf;;"""date"",""2016-12-25T00:07:39Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""1"",""2"",""0"",""9"",""15"",""18"",""10"",""12"",""15"",""6"",""25"",""16"",""0"",""0""
""pdf:PDFVersion"",""1.5""
""xmp:CreatorTool"",""TeX""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dcterms:created"",""2016-12-25T00:07:39Z""
""language"",""en""
""Last-Modified"",""2016-12-25T00:07:39Z""
""dcterms:modified"",""2016-12-25T00:07:39Z""
""dc:format"",""application/pdf; version=1.5""
""Last-Save-Date"",""2016-12-25T00:07:39Z""
""pdf:docinfo:creator_tool"",""TeX""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2016-12-25T00:07:39Z""
""meta:save-date"",""2016-12-25T00:07:39Z""
""pdf:encrypted"",""false""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016) kpathsea version 6.2.2""
""modified"",""2016-12-25T00:07:39Z""
""Content-Length"",""413223""
""pdf:hasMarkedContent"",""false""
""Content-Type"",""application/pdf""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016) kpathsea version 6.2.2""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""trapped"",""False""
""meta:creation-date"",""2016-12-25T00:07:39Z""
""created"",""2016-12-25T00:07:39Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""15""
""Creation-Date"",""2016-12-25T00:07:39Z""
""resourceName"",""HofheinzKKW19.pdf""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""1407"",""4063"",""4041"",""3910"",""2987"",""2983"",""2583"",""2186"",""2275"",""2736"",""2374"",""2372"",""3038"",""2632"",""1725""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""producer"",""pdfTeX-1.40.17""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""pdfTeX-1.40.17""
""pdf:docinfo:created"",""2016-12-25T00:07:39Z""
";https://scholar.google.com/scholar?start=770&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094644-1091;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[LIVRE][B] Information Security and Cryptology–ICISC 2018: 21st International Conference, Seoul, South Korea, November 28–30, 2018, Revised Selected Papers;K Lee ;2019 books.google.com;;"… There are also works which consider adversaries making quantum superposition queries

not only to the random oracle but to all oracles … 233 Romar B. dela Cruz and Say Ol A

New Privacy-Preserving Searching Model on Blockchain …";Les 2 versions;;null;;;;https://scholar.google.com/scholar?start=910&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094532-619;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;"Anwendungsmöglichkeiten der Blockchain-Technologie im industriellen Kontext; eine Betrachtung des gesamten Product Life Cycle";A Porsch ;2019 repositum.tuwien.at;;"Page 1. Anwendungsmöglichkeiten der Blockchain – Technologie im … Insbesondere da es sich

dabei um eine neuartige Art der Vernetzung handelt und Vernetzung als logische

Schlussfolgerung die zentrale Rolle in der Industrie 4.0 spielt.1 2.2 Blockchain – Grundbegriffe …";Autres articles;Version HTML;[PDF] tuwien.at;https://repositum.tuwien.at/bitstream/20.500.12708/7597/2/Anwendungsmoeglichkeiten%20der%20Blockchain%20-%20Technologie%20im%20industriellen%20Kontext%20eine%20Betrachtung%20des%20gesamten%20Product%20Life%20Cycle.pdf;;;
1619094623-1006;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;A novel medical blockchain model for drug supply chain integrity management in a smart hospital;F Jamil, L Hang, KH Kim, DH Kim ; Electronics, 2019  mdpi.com;;"… Regardless, the dispensation rate is limited (ie, Ethereum cryptocurrency and is capable of up

to 20 transactions per second only, which is very limited). Nevertheless, many challenges exist

in the current blockchain-based healthcare system using a permissionless blockchain …";Cité 76 fois;Les 3 versions;[PDF] mdpi.com;https://www.mdpi.com/2079-9292/8/5/505/pdf;;;https://scholar.google.com/scholar?start=820&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094567-766;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[CITATION][C] Design of intelligent lighting controller based on bluetooth, pp. 1-4 Shuangshuang Yi, Jianqi Li, Xiaoqing Ou, Qingshan Zhou, Jianying Li A Kind of …;L Wei, Z Yu, J Yu, S Li, T Pan, M He ; ieeexplore.ieee.org;;"… A. Vega-Mejía A Novel Blockchain Oracle Implementation Scheme Based on

Application Specific Knowledge Engines, pp.258-262 Shuai Wang, Hao Lu, Xingkai

Sun, Yong Yuan, Fei-Yue Wang A Blockchain-based Framework …";;null;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/8945268/8954999/08955066.pdf;;"""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""dc:title"",""IEEE Xplore Full-Text PDF:""
""Content-Encoding"",""UTF-8""
""resourceName"",""08955066.pdf""
""language"",""es""
""Content-Length"",""2565""
""title"",""IEEE Xplore Full-Text PDF:""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=580&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094614-961;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[PDF][PDF] Online dispute resolution for smart contracts;A Schmitz, C Rule ; J. Disp. Resol., 2019  HeinOnline;;"… terminate the DAO and admit defeat.1 o' Some also raise the ""oracle problem"" as a … of a reliable

and secure delivery mechanism that exchanges real time information with blockchain data systems …

ing oracles are run on centralized or single source services which have the same …";Cité 19 fois;Les 9 versions;[PDF] heinonline.org;https://heinonline.org/hol-cgi-bin/get_pdf.cgi?handle=hein.journals/jdisres2019&section=23&casa_token=JcIzkdcQRowAAAAA:PyFxfEsKal52pA90HyNr8Cb-ZgW42BRPOagjITJMKdwlMmWiOaJeJEmW8wgftICcsbY1p08;;"""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""REFRESH"",""1; url=https://heinonline.org/HOL/Page?handle=hein.journals/jdisres2019&div=23&g_sent=1&casa_token=JcIzkdcQRowAAAAA:PyFxfEsKal52pA90HyNr8Cb-ZgW42BRPOagjITJMKdwlMmWiOaJeJEmW8wgftICcsbY1p08""
""Content-Encoding"",""UTF-8""
""resourceName"",""get_pdf.cgi""
""language"",""""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=780&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094553-710;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[PDF][PDF] To Analyse How Blockchain Technology can be used to Securely Store Different Information Sources;A Smith ; ijisrt.com;;"… to more sophisticated attacks that use deviations in system behavior as so-called ""oracles"" to

obtain … However, since Blockchain applications are designed for extremely long lifetimes - think

of a notary function, for … For blockchains such a ""crypto agility"" does not exist so far [23,34 …";Autres articles;Version HTML;[PDF] ijisrt.com;https://ijisrt.com/wp-content/uploads/2019/02/IJISRT19JA332.pdf;;;https://scholar.google.com/scholar?start=520&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094532-618;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[PDF][PDF] UniqueChain: A Fast, Provably Secure Proof-of-Stake Based Blockchain Protocol in the Open Setting.;P Ni, H Li, X Meng, D Pan ; IACR Cryptol. ePrint Arch., 2019  eprint.iacr.org;;"UniqueChain: A Fast, Provably Secure Proof-of-Stake Based Blockchain Protocol in the Open

Setting … 1 Introduction Blockchain, the technique of the most concern, has been investigated in

various fields in recent years and believed to make huge changes to the future world …";Cité 2 fois;Les 2 versions;[PDF] iacr.org;https://eprint.iacr.org/2019/456.pdf;;"""date"",""2019-05-14T06:46:02Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""3"",""8"",""0"",""0"",""17"",""36"",""19"",""32"",""18"",""10"",""10"",""108"",""19"",""38"",""81"",""131"",""2"",""3"",""28"",""0"",""7"",""5"",""0"",""3"",""5"",""30"",""49"",""79""
""pdf:PDFVersion"",""1.5""
""xmp:CreatorTool"",""TeX""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dcterms:created"",""2019-05-14T06:46:02Z""
""language"",""en""
""Last-Modified"",""2019-05-14T06:46:02Z""
""dcterms:modified"",""2019-05-14T06:46:02Z""
""dc:format"",""application/pdf; version=1.5""
""Last-Save-Date"",""2019-05-14T06:46:02Z""
""pdf:docinfo:creator_tool"",""TeX""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2019-05-14T06:46:02Z""
""meta:save-date"",""2019-05-14T06:46:02Z""
""pdf:encrypted"",""false""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is MiKTeX-pdfTeX 2.9.4307 (1.40.12)""
""modified"",""2019-05-14T06:46:02Z""
""Content-Length"",""547562""
""pdf:hasMarkedContent"",""false""
""Content-Type"",""application/pdf""
""PTEX.Fullbanner"",""This is MiKTeX-pdfTeX 2.9.4307 (1.40.12)""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""trapped"",""False""
""meta:creation-date"",""2019-05-14T06:46:02Z""
""created"",""2019-05-14T06:46:02Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""30""
""Creation-Date"",""2019-05-14T06:46:02Z""
""resourceName"",""456.pdf""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""1962"",""2778"",""2990"",""2951"",""2892"",""2603"",""2185"",""2130"",""1756"",""2870"",""2640"",""2375"",""2378"",""2960"",""2402"",""2492"",""2100"",""1861"",""2306"",""2126"",""2187"",""2085"",""2277"",""2431"",""2453"",""2779"",""1407"",""2241"",""2334"",""2015""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""producer"",""MiKTeX pdfTeX-1.40.12""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""MiKTeX pdfTeX-1.40.12""
""pdf:docinfo:created"",""2019-05-14T06:46:02Z""
";
1619094567-770;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[PDF][PDF] Rechtsinformatiker GbR: Technical Notes–Blockchain/Ethereum;IT Josephy ;2019 researchgate.net;;"… Stiftung ECC, Quantum, Crypto Analysis IoT Crypto Grundsatz 26.05.2019 Ralf

Josephy, Ingo Schmidt (visa eV) und Walter Schmeing Ralf Josephy DigitalLibrary –

Jutta Riedel und Dirk Freund (Blockchain Survey) Low Energy …";Autres articles;;[PDF] researchgate.net;https://www.researchgate.net/profile/Ralf_Josephy2/publication/332105708_Josephy_IT_Rechtsinformatiker_GbR_Technical_Notes_-_BlockchainEthereum_Content/links/5cfa63d3a6fdccd130890dd7/Josephy-IT-Rechtsinformatiker-GbR-Technical-Notes-Blockchain-Ethereum-Content.pdf;;;https://scholar.google.com/scholar?start=580&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094649-1118;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;ROYALE: A framework for universally composable card games with financial rewards and penalties enforcement;B David, R Dowsley, M Larangeira ; International Conference on Financial …, 2019  Springer;;"… assumptions (DDH) in the restricted programmable and observable global random oracle model

of [9]. As the contract is ultimately implemented by a blockchain-based solution … 7] is to execute

an unfair protocol without any interaction with the cryptocurrency network, relying …";Cité 6 fois;Les 13 versions;[PDF] ifca.ai;http://www.ifca.ai/fc19/preproceedings/111-preproceedings.pdf;;"""date"",""2019-01-05T10:58:03Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2019-01-05T10:58:03Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017) kpathsea version 6.2.3""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2019-01-05T10:58:03Z""
""created"",""2019-01-05T10:58:03Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-01-05T10:58:03Z""
""resourceName"",""111-preproceedings.pdf""
""Author"",""""
""producer"",""pdfTeX-1.40.18""
""pdf:docinfo:producer"",""pdfTeX-1.40.18""
""pdf:unmappedUnicodeCharsPerPage"",""6"",""0"",""0"",""0"",""0"",""1"",""0"",""1"",""0"",""3"",""14"",""2"",""2"",""6"",""0"",""0"",""0"",""0"",""5"",""16"",""19"",""0"",""16"",""0"",""13"",""0"",""4"",""6"",""6"",""0"",""1"",""8"",""0"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2019-01-05T10:58:03Z""
""Last-Modified"",""2019-01-05T10:58:03Z""
""dcterms:modified"",""2019-01-05T10:58:03Z""
""title"",""""
""Last-Save-Date"",""2019-01-05T10:58:03Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2019-01-05T10:58:03Z""
""meta:save-date"",""2019-01-05T10:58:03Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017) kpathsea version 6.2.3""
""Content-Length"",""547657""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""35""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""2144"",""3132"",""3397"",""3324"",""3035"",""2993"",""3083"",""3144"",""2985"",""3111"",""2485"",""2904"",""3152"",""2531"",""2465"",""3107"",""3071"",""2639"",""2359"",""2018"",""1887"",""3090"",""2309"",""3001"",""2420"",""2894"",""2943"",""2890"",""2728"",""2800"",""2567"",""2370"",""1834"",""1774"",""890""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-01-05T10:58:03Z""
";https://scholar.google.com/scholar?start=930&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094619-983;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Regulating Securities Financing Transactions and Shadow Banking Transactions;M Ojo ; papers.ssrn.com;;"… Plus,Oracle is using blockchain technology to track declining honeybee populations and verify

that honey from beehives in its network is sustainably produced.” • … Whilst potentials exist for the

increasingly popular crypto asset markets … Intelligence and blockchain technologies …";Les 2 versions;;[PDF] researchgate.net;https://www.researchgate.net/profile/Marianne_Ojo_D_Delaney/publication/334605301_Regulating_Securities_Financing_Transactions_and_Shadow_Banking_Transactions_Financial_Stability_Board_Recommendations_and_Recent_Developments/links/5d35f7e8299bf1995b4282e4/Regulating-Securities-Financing-Transactions-and-Shadow-Banking-Transactions-Financial-Stability-Board-Recommendations-and-Recent-Developments.pdf;;;https://scholar.google.com/scholar?start=800&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094602-916;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;SoK: Consensus in the age of blockchains;S Bano, A Sonnino, M Al;Bassam, S Azouvi…  Proceedings of the 1st …, 2019  dl.acm.org;;"… This typically takes the form of a crypto- graphic lottery—eg, a random beacon, a periodically

gen- erated … as it empowers a small set of pool masters to control what is added to the blockchain …

min- ers should have an interest in the long-term success of the cryptocurrency—but in …";Cité 115 fois;Les 9 versions;[PDF] acm.org;https://dl.acm.org/doi/pdf/10.1145/3318041.3355458?casa_token=V2z7WYXPrYEAAAAA:Vvnn4y7D15bz_PY7uX-CfpD1HtEdUVPuuKQLm6xT28HPhjzNfyAV45lAdKkj1eOQIEBblc2PgGw;;;https://scholar.google.com/scholar?start=730&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094532-613;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[PDF][PDF] Dispelling the Myths and Identifying the Risks for the in-House Lawyer Confronted with Blockchain and Artificial Intelligence;C Stetzel ; Int'l. InHouse Counsel J., 2019  HeinOnline;;"… a normal contract you could rescind the contract but in the case of the blockchain if the … the term

of the contract by using a third-party source known by programmers as an oracle. Oracles refer

to external data fields or individuals such as the London Interbank Offered Rate (LIBOR …";;null;[PDF] heinonline.org;https://heinonline.org/hol-cgi-bin/get_pdf.cgi?handle=hein.journals/iihcj12&section=34&casa_token=QhYK1qZfR9UAAAAA:vzyqdx84Q0bk1uyAR3_wvQ-Zvu8W5ii7hM823NJSo3AmQk0wiwqHeSKjYSxvMhd1-TY_baM;;"""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""REFRESH"",""1; url=https://heinonline.org/HOL/Page?handle=hein.journals/iihcj12&div=34&g_sent=1&casa_token=QhYK1qZfR9UAAAAA:vzyqdx84Q0bk1uyAR3_wvQ-Zvu8W5ii7hM823NJSo3AmQk0wiwqHeSKjYSxvMhd1-TY_baM""
""Content-Encoding"",""UTF-8""
""resourceName"",""get_pdf.cgi""
""language"",""""
""Content-Type"",""text/html; charset=UTF-8""
";
1619094544-665;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[LIVRE][B] Blockchain für die Praxis: Kryptowährungen, Smart Contracts, ICOs und Tokens;P Egloff, E Turnes ;2019 books.google.com;;"… 35 3.2.1 Verteiltes Peer-to-Peer-Netzwerk . . . . . 36 3.2.2 Private versus öffentliche Blockchain . . . . .

38 3.3 Eigentumssicherung … 141 7.1.1 Schnittstellen und Oracles …";Cité 6 fois;;null;;;;https://scholar.google.com/scholar?start=480&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094593-871;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Non-uniformly sound certificates with applications to concurrent zero-knowledge;C Freitag, I Komargodski, R Pass ; Annual International Cryptology …, 2019  Springer;;"… CRYPTO 2019: Advances in Cryptology – CRYPTO 2019 pp 98-127 | Cite as … map all possible

ways the adversary can cheat to first encode the random oracle \(\mathcal {O … than the adversary's

advice, then the adversary can succeed only on a small fraction of random oracles …";Cité 2 fois;Les 2 versions;[PDF] iacr.org;https://eprint.iacr.org/2019/631.pdf;;"""date"",""2019-06-02T13:44:27Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2019-06-02T13:44:27Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.19 (TeX Live 2018) kpathsea version 6.3.0""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2019-06-02T13:44:27Z""
""created"",""2019-06-02T13:44:27Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-06-02T13:44:27Z""
""resourceName"",""631.pdf""
""Author"",""""
""producer"",""pdfTeX-1.40.19""
""pdf:docinfo:producer"",""pdfTeX-1.40.19""
""pdf:unmappedUnicodeCharsPerPage"",""4"",""0"",""0"",""3"",""0"",""9"",""0"",""0"",""0"",""2"",""0"",""0"",""1"",""0"",""12"",""0"",""5"",""2"",""0"",""0"",""4"",""6"",""6"",""0"",""8"",""3"",""16"",""0"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2019-06-02T13:44:27Z""
""Last-Modified"",""2019-06-02T13:44:27Z""
""dcterms:modified"",""2019-06-02T13:44:27Z""
""title"",""""
""Last-Save-Date"",""2019-06-02T13:44:27Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2019-06-02T13:44:27Z""
""meta:save-date"",""2019-06-02T13:44:27Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.19 (TeX Live 2018) kpathsea version 6.3.0""
""Content-Length"",""465924""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""30""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""2123"",""2774"",""2691"",""2611"",""2259"",""2781"",""2669"",""2440"",""2498"",""2831"",""2830"",""2391"",""2087"",""2104"",""2237"",""2415"",""2052"",""2238"",""2261"",""2579"",""1935"",""2097"",""1980"",""2167"",""2173"",""2455"",""1975"",""2622"",""3011"",""1708""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-06-02T13:44:27Z""
";https://scholar.google.com/scholar?start=690&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094595-889;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[CITATION][C] Fundamentals of Smart Contract Security;R Ma, J Gorzny, E Zulkoski, K Bak, OV Mack ;2019 Momentum Press;;null;Cité 2 fois;;null;;;;https://scholar.google.com/scholar?start=700&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094609-946;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[HTML][HTML] Multidivisible Online/Offline Cryptography and Its Application to Signcryptions;D Yamamoto, W Ogata ; Security and Communication Networks, 2019  hindawi.com;United Kingdom;"… We can use crypto- graphic schemes as building blocks to achieve security for them, only if it

is taken … the op- eration of a turing machine A with inputs x, y, ... and access to oracles oracle1,

oracle2 … for any adversary A that runs in time t and makes at most q queries to oracle sign …";Cité 1 fois;Les 5 versions;[HTML] hindawi.com;https://www.hindawi.com/journals/scn/2019/1042649/;;"""dc.publisher"",""Hindawi""
""og:image"",""https://images.hindawi.com/journals/scn/scn.banner.jpg""
""og:image:width"",""600""
""twitter:card"",""summary_large_image""
""citation_journal_title"",""Security and Communication Networks""
""language"",""en""
""og:description"",""We introduce a general concept of <i>multidivisible online/offline (MDO) cryptography</i>, which covers the previous works including online/offline cryptographic schemes, divisible online/offline signatures, incrementally executable signcryptions, and multidivisible online/offline encryptions. We then present the notion of <i>multidivisible online/offline signcryptions</i> (MDOSCs) as novel application of MDO cryptography. We define several security notions for MDOSCs and show implications and separations between these security notions. We also present a generic construction of MDOSC that achieves the strongest security notions with regard to confidentiality and unforgeability. Using MDOSC schemes, the computationally restricted and/or bandwidth-restricted devices can transmit messages in both confidential and authenticated way with low computational overhead and/or low-bandwidth network.""
""prism.issn"",""1939-0114""
""citation_issn"",""1939-0114""
""dc:title"",""Multidivisible Online/Offline Cryptography and Its Application to Signcryptions""
""Content-Encoding"",""UTF-8""
""citation_pdf_url"",""https://downloads.hindawi.com/journals/scn/2019/1042649.pdf""
""robots"",""index""
""google-site-verification"",""AxEuDsL7vXGOxRe53-uFhOk2ODN0bbXMeuBy6Pfq4ww""
""citation_author"",""Yamamoto, Dan"",""Ogata, Wakaha""
""dc.date"",""2019/10/08""
""prism.volume"",""2019""
""citation_doi"",""https://doi.org/10.1155/2019/1042649""
""prism.publicationName"",""Security and Communication Networks""
""dc.title"",""Multidivisible Online/Offline Cryptography and Its Application to Signcryptions""
""Author"",""Hindawi""
""citation_volume"",""2019""
""dc.language"",""en""
""Content-Language"",""en""
""authors"",""Dan Yamamoto | Wakaha Ogata""
""citation_title"",""Multidivisible Online/Offline Cryptography and Its Application to Signcryptions""
""citation_year"",""2019""
""citation_publisher"",""Hindawi""
""dc.format"",""text/html""
""description"",""We introduce a general concept of <i>multidivisible online/offline (MDO) cryptography</i>, which covers the previous works including online/offline cryptographic schemes, divisible online/offline signatures, incrementally executable signcryptions, and multidivisible online/offline encryptions. We then present the notion of <i>multidivisible online/offline signcryptions</i> (MDOSCs) as novel application of MDO cryptography. We define several security notions for MDOSCs and show implications and separations between these security notions. We also present a generic construction of MDOSC that achieves the strongest security notions with regard to confidentiality and unforgeability. Using MDOSC schemes, the computationally restricted and/or bandwidth-restricted devices can transmit messages in both confidential and authenticated way with low computational overhead and/or low-bandwidth network.""
""og:image:type"",""image/jpeg""
""citation_date"",""2019/10/08""
""title"",""Multidivisible Online/Offline Cryptography and Its Application to Signcryptions"",""Multidivisible Online/Offline Cryptography and Its Application to Signcryptions""
""twitter:image"",""https://images.hindawi.com/journals/scn/scn.banner.jpg""
""citation_online_date"",""2019/10/08""
""twitter:site"",""website""
""dc.type"",""Research Article""
""dc.source"",""Security and Communication Networks""
""dc.creator"",""Yamamoto, Dan"",""Ogata, Wakaha""
""citation_fulltext_html_url"",""https://www.hindawi.com/journals/scn/2019/1042649/""
""prism.publicationDate"",""2019/10/08""
""Content-Length"",""3656009""
""citation_xml_url"",""https://downloads.hindawi.com/journals/scn/2019/1042649.xml""
""Content-Type"",""text/html; charset=UTF-8""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""og:type"",""website""
""twitter:title"",""Multidivisible Online/Offline Cryptography and Its Application to Signcryptions""
""dc.description"",""We introduce a general concept of <i>multidivisible online/offline (MDO) cryptography</i>, which covers the previous works including online/offline cryptographic schemes, divisible online/offline signatures, incrementally executable signcryptions, and multidivisible online/offline encryptions. We then present the notion of <i>multidivisible online/offline signcryptions</i> (MDOSCs) as novel application of MDO cryptography. We define several security notions for MDOSCs and show implications and separations between these security notions. We also present a generic construction of MDOSC that achieves the strongest security notions with regard to confidentiality and unforgeability. Using MDOSC schemes, the computationally restricted and/or bandwidth-restricted devices can transmit messages in both confidential and authenticated way with low computational overhead and/or low-bandwidth network.""
""og:title"",""Multidivisible Online/Offline Cryptography and Its Application to Signcryptions""
""citation_abstract"",""We introduce a general concept of <i>multidivisible online/offline (MDO) cryptography</i>, which covers the previous works including online/offline cryptographic schemes, divisible online/offline signatures, incrementally executable signcryptions, and multidivisible online/offline encryptions. We then present the notion of <i>multidivisible online/offline signcryptions</i> (MDOSCs) as novel application of MDO cryptography. We define several security notions for MDOSCs and show implications and separations between these security notions. We also present a generic construction of MDOSC that achieves the strongest security notions with regard to confidentiality and unforgeability. Using MDOSC schemes, the computationally restricted and/or bandwidth-restricted devices can transmit messages in both confidential and authenticated way with low computational overhead and/or low-bandwidth network.""
""og:image:height"",""315""
""prism.doi"",""https://doi.org/10.1155/2019/1042649""
""dcterms.issued"",""2019/10/08""
""viewport"",""width=device-width, initial-scale=1""
""twitter:description"",""We introduce a general concept of <i>multidivisible online/offline (MDO) cryptography</i>, which covers the previous works including online/offline cryptographic schemes, divisible online/offline signatures, incrementally executable signcryptions, and multidivisible online/offline encryptions. We then present the notion of <i>multidivisible online/offline signcryptions</i> (MDOSCs) as novel application of MDO cryptography. We define several security notions for MDOSCs and show implications and separations between these security notions. We also present a generic construction of MDOSC that achieves the strongest security notions with regard to confidentiality and unforgeability. Using MDOSC schemes, the computationally restricted and/or bandwidth-restricted devices can transmit messages in both confidential and authenticated way with low computational overhead and/or low-bandwidth network.""
""dc.identifier"",""https://doi.org/10.1155/2019/1042649""
""prism.section"",""Research Article""
""og:url"",""https://www.hindawi.com/journals/scn/2019/1042649/""
";https://scholar.google.com/scholar?start=760&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094656-1145;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[PDF][PDF] Timed-Release Encryption With Master Time Bound Key (Extended).;G Choi, S Vaudenay ; J. Wirel. Mob. Networks Ubiquitous Comput …, 2019  isyou.info;;"… We first define security games with oracles in Table 1. Table 1: Outputs of the decryption

oracles O1 and O2, and the time bound key oracle Q for security games by attack types.

O1(? ,c ) O2(? ,c ) Q(t ) CPA ? ? C.Broadcast(skTS,t ,?) …";Autres articles;Version HTML;[PDF] isyou.info;http://isyou.info/jowua/papers/jowua-v10n4-6.pdf;;"""date"",""2020-01-11T04:36:20Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2020-01-11T04:36:20Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is MiKTeX-pdfTeX 2.9.6668 (1.40.19)""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2020-01-11T04:36:20Z""
""created"",""2020-01-11T04:36:20Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-01-11T04:36:20Z""
""resourceName"",""jowua-v10n4-6.pdf""
""Author"",""""
""producer"",""pdfTeX-1.40.19""
""pdf:docinfo:producer"",""pdfTeX-1.40.19""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""2"",""13"",""0"",""16"",""4"",""14"",""12"",""13"",""12"",""18"",""66"",""32"",""23"",""0"",""0"",""8"",""0"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2020-01-11T04:36:20Z""
""Last-Modified"",""2020-01-11T04:36:20Z""
""dcterms:modified"",""2020-01-11T04:36:20Z""
""title"",""""
""Last-Save-Date"",""2020-01-11T04:36:20Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2020-01-11T04:36:20Z""
""meta:save-date"",""2020-01-11T04:36:20Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is MiKTeX-pdfTeX 2.9.6668 (1.40.19)""
""Content-Length"",""436200""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""21""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""2776"",""3931"",""3422"",""2036"",""1953"",""2872"",""2355"",""2132"",""1813"",""1411"",""1428"",""1954"",""2414"",""1656"",""2900"",""3512"",""2585"",""2854"",""2589"",""3957"",""2073""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-01-11T04:36:20Z""
";https://scholar.google.com/scholar?start=960&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094572-786;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[PDF][PDF] Tokenization of Infrastructure;D Uzsoki ; A blockchainbased solution to financing sustainable …, 2019  iisd.org;;"… by Satoshi Nakamoto in 2009 to serve as the public transaction ledger for the cryptocurrency

bitcoin … the cost of transfer of any number of tokens on the Ethereum blockchain, where most …

Currently, most crypto exchanges are not ready to list security tokens, as they would need to …";Cité 1 fois;Les 3 versions;[PDF] iisd.org;https://www.iisd.org/system/files/publications/tokenization-infrastructure-blockchain-solution.pdf;;;https://scholar.google.com/scholar?start=600&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094609-948;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[CITATION][C] Visual Arts And The Law A Handbook For Professionals Handbooks In International Art Business;PO Gtfo, A Lambda, D Guide;;;null;;null;null;;;;https://scholar.google.com/scholar?start=760&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094539-641;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[PDF][PDF] Design and implementation of a blockchain-based trusted VNF package repository;M Keller ;2019 files.ifi.uzh.ch;;"Page 1. Design and Implementation of a Blockchain-based Trusted VNF Package Repository

Manuel Keller Zürich, Switzerland … However, current projects have yet to extend to the repositories.

Page 27. Chapter 4 Blockchain-based Trusted VNF Repository …";Cité 2 fois;;[PDF] uzh.ch;https://files.ifi.uzh.ch/CSG/staff/scheid/extern/theses/MA-M-Keller.pdf;;"""date"",""2019-05-15T08:49:38Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2019-05-15T08:49:38Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017) kpathsea version 6.2.3""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2019-05-15T08:49:38Z""
""created"",""2019-05-15T08:49:38Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-05-15T08:49:38Z""
""resourceName"",""MA-M-Keller.pdf""
""Author"",""""
""producer"",""pdfTeX-1.40.18""
""pdf:docinfo:producer"",""pdfTeX-1.40.18""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2019-05-15T08:49:38Z""
""Last-Modified"",""2019-05-15T08:49:38Z""
""dcterms:modified"",""2019-05-15T08:49:38Z""
""title"",""""
""Last-Save-Date"",""2019-05-15T08:49:38Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2019-05-15T08:49:38Z""
""meta:save-date"",""2019-05-15T08:49:38Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017) kpathsea version 6.2.3""
""Content-Length"",""5418401""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""69""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""338"",""158"",""1919"",""2"",""2178"",""2"",""513"",""2"",""692"",""1040"",""53"",""9"",""2189"",""2422"",""1551"",""1205"",""1852"",""2782"",""1017"",""31"",""1557"",""2094"",""2145"",""1322"",""1221"",""1748"",""1599"",""1326"",""1805"",""1452"",""2471"",""1993"",""1832"",""1562"",""1838"",""2233"",""1848"",""2216"",""2236"",""1070"",""1763"",""309"",""43"",""47"",""1933"",""2671"",""2030"",""1702"",""2159"",""1943"",""1545"",""2350"",""954"",""14"",""453"",""14"",""1123"",""10"",""667"",""15"",""174"",""14"",""555"",""10"",""919"",""1307"",""197"",""34"",""142""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-05-15T08:49:38Z""
";https://scholar.google.com/scholar?start=460&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094630-1031;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;New techniques for efficient trapdoor functions and applications;S Garg, R Gay, M Hajiabadi ; … International Conference on the Theory and …, 2019  Springer;;"… Our approach builds on the recent framework of Garg and Hajiabadi [CRYPTO 2018]. As

applications of our techniques, we obtain … Strong versions of this notion have so far been realized

in the random oracle model [BBO07] and are subject to impossibility results [Wic13] …";Cité 13 fois;Les 3 versions;[PDF] iacr.org;https://eprint.iacr.org/2018/872.pdf;;"""date"",""2019-05-23T23:13:52Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2019-05-23T23:13:52Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017) kpathsea version 6.2.3""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2019-05-23T23:13:52Z""
""created"",""2019-05-23T23:13:52Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-05-23T23:13:52Z""
""resourceName"",""872.pdf""
""Author"",""""
""producer"",""pdfTeX-1.40.18""
""pdf:docinfo:producer"",""pdfTeX-1.40.18""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""4"",""1"",""0"",""2"",""23"",""35"",""1"",""24"",""6"",""9"",""9"",""5"",""4"",""16"",""5"",""4"",""17"",""22"",""8"",""54"",""15"",""15"",""10"",""26"",""37"",""34"",""15"",""21"",""23"",""29"",""1"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2019-05-23T23:13:52Z""
""Last-Modified"",""2019-05-23T23:13:52Z""
""dcterms:modified"",""2019-05-23T23:13:52Z""
""title"",""""
""Last-Save-Date"",""2019-05-23T23:13:52Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2019-05-23T23:13:52Z""
""meta:save-date"",""2019-05-23T23:13:52Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017) kpathsea version 6.2.3""
""Content-Length"",""497821""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""34""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""2356"",""3171"",""2719"",""3350"",""3118"",""3459"",""3287"",""2121"",""2179"",""1726"",""1922"",""1864"",""1573"",""1955"",""2592"",""2537"",""1680"",""2118"",""2175"",""2300"",""1914"",""2073"",""1589"",""2140"",""1857"",""2186"",""2017"",""2001"",""2310"",""1541"",""1960"",""2184"",""2238"",""2191""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-05-23T23:13:52Z""
";https://scholar.google.com/scholar?start=850&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094619-982;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;What is stablecoin?: A survey on price stabilization mechanisms for decentralized payment systems;M Mita, K Ito, S Ohsawa… ; 2019 8th International …, 2019  ieeexplore.ieee.org;;"… Price Index (CPI) to stabilize against fiat currencies and their blockchain system is designed in

a decentralized way using the Basis–USD exchange rate via an Oracle system … How to Make

a Digital Currency on a Blockchain Stable … Volatility and Welfare in a Crypto Economy …";Cité 22 fois;Les 7 versions;[PDF] arxiv.org;https://arxiv.org/pdf/1906.06037;;"""date"",""2020-06-23T01:31:56Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2020-06-23T01:31:56Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016) kpathsea version 6.2.2""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2020-06-23T01:31:56Z""
""created"",""2020-06-23T01:31:56Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-06-23T01:31:56Z""
""resourceName"",""1906.06037""
""Author"",""""
""producer"",""pdfTeX-1.40.17""
""pdf:docinfo:producer"",""pdfTeX-1.40.17""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""1"",""1"",""1"",""1"",""6"",""1"",""1"",""1"",""1"",""17"",""1"",""1"",""1"",""1"",""1""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2020-06-23T01:31:56Z""
""Last-Modified"",""2020-06-23T01:31:56Z""
""dcterms:modified"",""2020-06-23T01:31:56Z""
""title"",""""
""Last-Save-Date"",""2020-06-23T01:31:56Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2020-06-23T01:31:56Z""
""meta:save-date"",""2020-06-23T01:31:56Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016) kpathsea version 6.2.2""
""Content-Length"",""285102""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""16""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""2435"",""2655"",""2789"",""3244"",""3658"",""2872"",""3308"",""3479"",""3099"",""3434"",""2411"",""2133"",""2190"",""2300"",""2211"",""814""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-06-23T01:31:56Z""
";https://scholar.google.com/scholar?start=800&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094607-939;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[PDF][PDF] DDH-based Multisignatures with Public Key Aggregation.;DP Le, G Yang, A Ghorbani ; IACR Cryptol. ePrint Arch., 2019  eprint.iacr.org;;"… The public keys of all co-signers also should be recorded on the blockchain for the purpose of …

information params, a challenging public key pk? corresponding to the honest signer and signing

and hash oracles … is said to be (t, qS,qH,N,?)-secure in the random oracle model if …";Cité 3 fois;;[PDF] iacr.org;https://eprint.iacr.org/2019/771.pdf;;"""date"",""2019-07-02T13:27:56Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""8"",""0"",""7"",""26"",""12"",""23"",""3"",""34"",""13"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.5""
""xmp:CreatorTool"",""TeX""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dcterms:created"",""2019-07-02T13:27:56Z""
""language"",""en""
""Last-Modified"",""2019-07-02T13:27:56Z""
""dcterms:modified"",""2019-07-02T13:27:56Z""
""dc:format"",""application/pdf; version=1.5""
""Last-Save-Date"",""2019-07-02T13:27:56Z""
""pdf:docinfo:creator_tool"",""TeX""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2019-07-02T13:27:56Z""
""meta:save-date"",""2019-07-02T13:27:56Z""
""pdf:encrypted"",""false""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017) kpathsea version 6.2.3""
""modified"",""2019-07-02T13:27:56Z""
""Content-Length"",""352103""
""pdf:hasMarkedContent"",""false""
""Content-Type"",""application/pdf""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017) kpathsea version 6.2.3""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""trapped"",""False""
""meta:creation-date"",""2019-07-02T13:27:56Z""
""created"",""2019-07-02T13:27:56Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""15""
""Creation-Date"",""2019-07-02T13:27:56Z""
""resourceName"",""771.pdf""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""1438"",""2996"",""2321"",""1675"",""1814"",""2230"",""1381"",""1253"",""1531"",""2033"",""2164"",""2535"",""1945"",""1930"",""563""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""producer"",""pdfTeX-1.40.18""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""pdfTeX-1.40.18""
""pdf:docinfo:created"",""2019-07-02T13:27:56Z""
";https://scholar.google.com/scholar?start=750&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094661-1168;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Problemas con la ejecución de los legal smart contracts;P Río Castillo ;2019 repositorio.comillas.edu;;"… métodos externos a la blockchain para poder reforzar el uso y ejecución de los smart contracts.

24 Egberts, A. (2017), The Oracle Problem - An Analysis of how Blockchain Oracles Undermine

the Advantages of Decentralized Ledger Systems. Page 20. 20 …";Autres articles;Version HTML;[PDF] comillas.edu;https://repositorio.comillas.edu/xmlui/bitstream/handle/11531/29324/TFG-%20del%20RAo%20Castillo%2C%20Paloma.pdf?sequence=1;;"""date"",""2019-06-13T20:01:58Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.5""
""xmp:CreatorTool"",""MicrosoftÂŽ Word 2016""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dc:creator"",""Paloma Del RĂ­o""
""language"",""es""
""dcterms:created"",""2019-06-13T20:01:58Z""
""Last-Modified"",""2019-06-13T20:01:58Z""
""dcterms:modified"",""2019-06-13T20:01:58Z""
""dc:format"",""application/pdf; version=1.5""
""Last-Save-Date"",""2019-06-13T20:01:58Z""
""pdf:docinfo:creator_tool"",""MicrosoftÂŽ Word 2016""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2019-06-13T20:01:58Z""
""meta:save-date"",""2019-06-13T20:01:58Z""
""pdf:encrypted"",""false""
""modified"",""2019-06-13T20:01:58Z""
""Content-Length"",""962523""
""pdf:hasMarkedContent"",""true""
""Content-Type"",""application/pdf""
""pdf:docinfo:creator"",""Paloma Del RĂ­o""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Paloma Del RĂ­o""
""dc:language"",""es-ES""
""meta:author"",""Paloma Del RĂ­o""
""meta:creation-date"",""2019-06-13T20:01:58Z""
""created"",""2019-06-13T20:01:58Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""44""
""Creation-Date"",""2019-06-13T20:01:58Z""
""resourceName"",""TFG-%20del%20RAo%20Castillo%2C%20Paloma.pdf""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""218"",""2435"",""626"",""2504"",""280"",""2885"",""2686"",""2570"",""2516"",""2509"",""2401"",""2294"",""2805"",""2747"",""2734"",""2729"",""2418"",""2167"",""2323"",""2594"",""2632"",""2442"",""2487"",""2380"",""2674"",""2479"",""2132"",""2620"",""2706"",""2542"",""2522"",""2592"",""2652"",""2735"",""2705"",""2409"",""2647"",""2054"",""2687"",""2236"",""2006"",""1814"",""1642"",""1975""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""Author"",""Paloma Del RĂ­o""
""producer"",""MicrosoftÂŽ Word 2016""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""MicrosoftÂŽ Word 2016""
""pdf:docinfo:created"",""2019-06-13T20:01:58Z""
";https://scholar.google.com/scholar?start=980&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094642-1090;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;A formal treatment of deterministic wallets;P Das, S Faust, J Loss ; Proceedings of the 2019 ACM SIGSAC …, 2019  dl.acm.org;;"… rate into our model hot wallet security breaches, access to derived public keys and corresponding

signatures that may appear on the blockchain … assumed to be over all the random coins in game

G. Random Oracle Model. We model hash functions as random oracles [BR93] …";Cité 8 fois;Les 3 versions;[PDF] acm.org;https://dl.acm.org/doi/pdf/10.1145/3319535.3354236?casa_token=wNLJmaLdjkkAAAAA:6QkSst4ibRLx45geGvdh5EhAqhAoV_s-tJpfH6vUhb5hOS0rUS9N5_RRJU9Zzf0P_aFhv2IxfUw;;;https://scholar.google.com/scholar?start=900&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094619-986;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Practical lattice-based multisignature schemes for blockchains;C Ma, M Jiang ; IEEE Access, 2019  ieeexplore.ieee.org;;"… INDEX TERMS Lattice, multisignature scheme, public key aggregation, random oracle model …

Blockchain could be regarded as a public ledger and all committed transactions are stored in

a list of blocks [9]. A typical modern blockchain for cryptocurrency applications consists …";Cité 6 fois;;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/6287639/8600701/08930510.pdf;;"""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""dc:title"",""IEEE Xplore Full-Text PDF:""
""Content-Encoding"",""UTF-8""
""resourceName"",""08930510.pdf""
""language"",""es""
""Content-Length"",""2565""
""title"",""IEEE Xplore Full-Text PDF:""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=800&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094628-1021;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Lossy algebraic filters with short tags;B Libert, C Qian ; IACR International Workshop on Public Key …, 2019  Springer;;"… When the adversary is equipped with a decryption oracle, the ability to publicly compute

encryptions of the decryption key may be a problem as decryption queries could end up

revealing that key … If \(t \not \in \mathcal {T}\), the oracle outputs \(\perp \) …";Cité 3 fois;Les 4 versions;[PDF] inria.fr;https://hal.inria.fr/hal-02124968/file/LAF-PKC.pdf;;"""date"",""2019-04-08T10:51:35Z""
""pdf:PDFVersion"",""1.4""
""pdf:docinfo:title"",""Lossy Algebraic Filters With Short Tags""
""xmp:CreatorTool"",""HAL""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""Computer Science [cs]/Cryptography and Security [cs.CR]""
""language"",""en""
""dc:format"",""application/pdf; version=1.4""
""pdf:docinfo:creator_tool"",""HAL""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""Lossy Algebraic Filters With Short Tags""
""modified"",""2019-04-08T10:51:35Z""
""cp:subject"",""Computer Science [cs]/Cryptography and Security [cs.CR]""
""pdf:docinfo:subject"",""Computer Science [cs]/Cryptography and Security [cs.CR]""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""BenoĂŽt Libert, Chen Qian""
""PTEX.Fullbanner"",""This is MiKTeX-pdfTeX 2.9.6839 (1.40.19)""
""meta:author"",""BenoĂŽt Libert, Chen Qian""
""trapped"",""False""
""meta:creation-date"",""2021-04-28T05:57:41Z""
""created"",""2021-04-28T05:57:41Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2021-04-28T05:57:41Z""
""resourceName"",""LAF-PKC.pdf""
""Author"",""BenoĂŽt Libert, Chen Qian""
""producer"",""PDFLaTeX""
""pdf:docinfo:producer"",""PDFLaTeX""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""1"",""4"",""0"",""1"",""3"",""6"",""14"",""9"",""13"",""8"",""11"",""22"",""22"",""16"",""9"",""6"",""5"",""35"",""73"",""29"",""11"",""14"",""10"",""18"",""24"",""10"",""6"",""0"",""0"",""6"",""53"",""19"",""43"",""4"",""24"",""14""
""Keywords"",""Lossy algebraic filters, efficiency, tight security, standard assumptions""
""access_permission:modify_annotations"",""true""
""dc:creator"",""BenoĂŽt Libert, Chen Qian""
""dcterms:created"",""2021-04-28T05:57:41Z""
""Last-Modified"",""2019-04-08T10:51:35Z""
""dcterms:modified"",""2019-04-08T10:51:35Z""
""title"",""Lossy Algebraic Filters With Short Tags""
""Last-Save-Date"",""2019-04-08T10:51:35Z""
""pdf:docinfo:keywords"",""Lossy algebraic filters, efficiency, tight security, standard assumptions""
""pdf:docinfo:modified"",""2019-04-08T10:51:35Z""
""meta:save-date"",""2019-04-08T10:51:35Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is MiKTeX-pdfTeX 2.9.6839 (1.40.19)""
""Content-Length"",""786015""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""BenoĂŽt Libert, Chen Qian""
""dc:subject"",""Lossy algebraic filters, efficiency, tight security, standard assumptions""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""38""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""817"",""2200"",""2953"",""2727"",""2549"",""2958"",""2234"",""2172"",""2227"",""1749"",""2201"",""1555"",""1377"",""1357"",""2301"",""1737"",""1699"",""1881"",""2022"",""1717"",""1960"",""1658"",""1373"",""1341"",""1981"",""1209"",""1395"",""1190"",""1711"",""2617"",""2134"",""1776"",""1667"",""1802"",""1458"",""1995"",""2096"",""1492""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""Lossy algebraic filters, efficiency, tight security, standard assumptions""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2021-04-28T05:57:41Z""
";https://scholar.google.com/scholar?start=840&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094555-712;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Multi-client functional encryption for linear functions in the standard model from LWE;B Libert, R ?i?iu ; International Conference on the Theory and …, 2019  Springer;;"… While efficient, the schemes of [27] both require the random oracle model. Chotard et al. thus

left open the problem of designing a (D)MCFE system under well-studied hardness assumptions

without using random oracles: even in the centralized setting, the only known MCFE …";Cité 10 fois;Les 5 versions;[PDF] inria.fr;https://hal.inria.fr/hal-02352139/file/MCFE.pdf;;"""date"",""2019-10-29T10:26:39Z""
""pdf:PDFVersion"",""1.4""
""pdf:docinfo:title"",""Multi-Client Functional Encryption for Linear Functions in the Standard Model from LWE""
""xmp:CreatorTool"",""HAL""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""Computer Science [cs]/Cryptography and Security [cs.CR]""
""language"",""en""
""dc:format"",""application/pdf; version=1.4""
""pdf:docinfo:creator_tool"",""HAL""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""Multi-Client Functional Encryption for Linear Functions in the Standard Model from LWE""
""modified"",""2019-10-29T10:26:39Z""
""cp:subject"",""Computer Science [cs]/Cryptography and Security [cs.CR]""
""pdf:docinfo:subject"",""Computer Science [cs]/Cryptography and Security [cs.CR]""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""BenoĂŽt Libert, Radu Titiu""
""PTEX.Fullbanner"",""This is MiKTeX-pdfTeX 2.9.6839 (1.40.19)""
""meta:author"",""BenoĂŽt Libert, Radu Titiu""
""trapped"",""False""
""meta:creation-date"",""2021-04-16T00:51:03Z""
""created"",""2021-04-16T00:51:03Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2021-04-16T00:51:03Z""
""resourceName"",""MCFE.pdf""
""Author"",""BenoĂŽt Libert, Radu Titiu""
""producer"",""PDFLaTeX""
""pdf:docinfo:producer"",""PDFLaTeX""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""3"",""11"",""10"",""13"",""44"",""52"",""7"",""8"",""1"",""26"",""24"",""35"",""21"",""28"",""42"",""21"",""28"",""29"",""51"",""48"",""28"",""69"",""56"",""107"",""33"",""46"",""28"",""1"",""0"",""0"",""18"",""35"",""63"",""82"",""52"",""46"",""59"",""20"",""43"",""31"",""51"",""67"",""87"",""65"",""5"",""69"",""84"",""32"",""15"",""36"",""33"",""42"",""25"",""2""
""Keywords"",""Multi-client functional Encryption, inner product evaluation, LWE, standard model, decentralization""
""access_permission:modify_annotations"",""true""
""dc:creator"",""BenoĂŽt Libert, Radu Titiu""
""dcterms:created"",""2021-04-16T00:51:03Z""
""Last-Modified"",""2019-10-29T10:26:39Z""
""dcterms:modified"",""2019-10-29T10:26:39Z""
""title"",""Multi-Client Functional Encryption for Linear Functions in the Standard Model from LWE""
""Last-Save-Date"",""2019-10-29T10:26:39Z""
""pdf:docinfo:keywords"",""Multi-client functional Encryption, inner product evaluation, LWE, standard model, decentralization""
""pdf:docinfo:modified"",""2019-10-29T10:26:39Z""
""meta:save-date"",""2019-10-29T10:26:39Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is MiKTeX-pdfTeX 2.9.6839 (1.40.19)""
""Content-Length"",""1018728""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""BenoĂŽt Libert, Radu Titiu""
""dc:subject"",""Multi-client functional Encryption, inner product evaluation, LWE, standard model, decentralization""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""55""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""920"",""2259"",""2717"",""2816"",""2681"",""2594"",""2689"",""2823"",""2945"",""2918"",""2249"",""1911"",""1935"",""2348"",""2223"",""2241"",""2433"",""2409"",""1953"",""1689"",""2115"",""1430"",""1875"",""1808"",""2136"",""2063"",""1588"",""2003"",""2303"",""2714"",""2795"",""2570"",""2389"",""2461"",""2408"",""2071"",""2230"",""2333"",""1709"",""1605"",""1857"",""1428"",""1273"",""1576"",""1800"",""1914"",""2075"",""1396"",""1846"",""2098"",""1741"",""1695"",""1897"",""1915"",""190""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""Multi-client functional Encryption, inner product evaluation, LWE, standard model, decentralization""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2021-04-16T00:51:03Z""
";https://scholar.google.com/scholar?start=530&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094555-718;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Alternative Digital Signature Schemes In Blockchain;F Yavuzyi?it ;2019 openaccess.hacettepe.edu.tr;;"… “top” (or “tip”) is the most recent block. In blockchain structure, the identifier of each block is its

hash value, generated using crypto … Having the most common usage in this area, Bitcoin is an

application of blockchain. Blocks … Bitcoin is a cryptocurrency ecosystem on its own. It …";Autres articles;Version HTML;[PDF] hacettepe.edu.tr;http://www.openaccess.hacettepe.edu.tr:8080/xmlui/bitstream/handle/11655/9430/SON.pdf?sequence=1;;"""date"",""2019-07-24T07:06:11Z""
""pdf:PDFVersion"",""1.6""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:docinfo:title"",""""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.6""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""xmp:CreateDate"",""2019-07-23T11:05:19Z""
""modified"",""2019-07-24T07:06:11Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""xmp:ModifyDate"",""2019-07-24T10:06:11Z""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017) kpathsea version 6.2.3""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2019-07-23T11:05:19Z""
""created"",""2019-07-23T11:05:19Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-07-23T11:05:19Z""
""resourceName"",""SON.pdf""
""Author"",""""
""producer"",""pdfTeX-1.40.18""
""pdf:docinfo:producer"",""pdfTeX-1.40.18""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""3"",""0"",""0"",""4"",""14"",""1"",""3"",""3"",""0"",""0"",""0"",""3"",""17"",""0"",""2"",""4"",""33"",""4"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2019-07-23T11:05:19Z""
""Last-Modified"",""2019-07-24T07:06:11Z""
""dcterms:modified"",""2019-07-24T07:06:11Z""
""title"",""""
""xmpMM:DocumentID"",""uuid:bd79d059-17e7-4d61-af4f-78eb2ac1b339""
""Last-Save-Date"",""2019-07-24T07:06:11Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2019-07-24T07:06:11Z""
""meta:save-date"",""2019-07-24T07:06:11Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017) kpathsea version 6.2.3""
""Content-Length"",""3580048""
""Content-Type"",""application/pdf""
""xmp:MetadataDate"",""2019-07-24T10:06:11Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""pdf:producer"",""pdfTeX-1.40.18""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""67""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""313"",""0"",""40"",""0"",""0"",""1609"",""129"",""1778"",""131"",""691"",""1642"",""386"",""662"",""229"",""589"",""1808"",""2063"",""2132"",""2020"",""1990"",""1559"",""429"",""741"",""1160"",""695"",""601"",""1120"",""29"",""1350"",""165"",""1508"",""1162"",""1680"",""799"",""867"",""1458"",""1065"",""1206"",""221"",""2136"",""1505"",""1421"",""879"",""1470"",""1221"",""1416"",""1238"",""1439"",""187"",""2015"",""191"",""1727"",""1736"",""1886"",""443"",""711"",""751"",""1063"",""789"",""800"",""650"",""827"",""953"",""36"",""35"",""0"",""464""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-07-23T11:05:19Z""
";https://scholar.google.com/scholar?start=530&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094558-724;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[LIVRE][B] Blockchain e Organizaçőes Descentralizadas;JG Lyra ;2019 books.google.com;;"… juntamente com os enigmas computacionais de Hashcash criado por Adam Back, surgindo o

conceito de cryptocurrency, mas ainda … 12 Blockchain e Organizaçőes Descentralizadas A

resoluçăo do “problema dos generais bizantinos” na computaçăo P2P se apre- senta como …";Cité 2 fois;;null;;;;https://scholar.google.com/scholar?start=540&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094595-890;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Smart Contracts: Some clarifying remarks from a German legal point of view;D Linardatos ; Available at SSRN 3193588, 2019  papers.ssrn.com;;"… out by an independent third party, who is called oracle in the context of the blockchain network.

Oracles link the blockchain with the outside world by supplying the network with data from the

analog world (eg weather data, exchange and stock market prices, geometrical data25 …";Les 3 versions;;null;;;;https://scholar.google.com/scholar?start=700&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094576-810;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Toward a policy-based blockchain agnostic framework;E Scheid, B Rodrigues, B Stiller ; 2019 IFIP/IEEE Symposium …, 2019  ieeexplore.ieee.org;;"… For instance, considering only the supply-chain sector, there are several startups (eg,

modum.io, Everledger, Provenance [2]–[4]) as well as companies (eg, IBM, Microsoft, and Oracle,

[5]– [7]) providing blockchain-based solutions for increasing trans- parency and traceability …";Cité 11 fois;Les 5 versions;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/8713766/8717786/08717826.pdf?casa_token=YF0bdix1NagAAAAA:la0ghDkDJCOXNZkti1vW4Zg2gJRYjCC4KROQ74sdQ8-3U3iTwirfZSJlw7nkO9AFLZHfKRjt-mI;;"""og:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""twitter:title"",""Toward a Policy-based Blockchain Agnostic Framework""
""twitter:card"",""summary""
""Description"",""Blockchain technology is developing at a rapid pace. For consumers that are only interested in simplifying processes and reducing costs by using a blockchain so""
""og:title"",""Toward a Policy-based Blockchain Agnostic Framework""
""resourceName"",""08717826.pdf""
""language"",""en""
""title"",""Toward a Policy-based Blockchain Agnostic Framework | IEEE Conference Publication | IEEE Xplore""
""og:description"",""Blockchain technology is developing at a rapid pace. For consumers that are only interested in simplifying processes and reducing costs by using a blockchain solution a new problem has occurred. It is not only necessary to select the appropriate solution, but also to configure and operate considering blockchain interoperability with different chains. For the industry, there is a need for solutions based on open standards. This paper proposes a Policy-based Blockchain Agnostic Framework that not only connects different blockchains but also facilitates their configuration and operation. Moreover, a case study is presented considering the cold-chain supply-chain, where each actor defines its policies based on blockchain requirements.""
""twitter:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-UA-Compatible"",""IE=Edge""
""viewport"",""width=device-width, initial-scale=1.0""
""dc:title"",""Toward a Policy-based Blockchain Agnostic Framework | IEEE Conference Publication | IEEE Xplore""
""twitter:description"",""Blockchain technology is developing at a rapid pace. For consumers that are only interested in simplifying processes and reducing costs by using a blockchain solution a new problem has occurred. It is not only necessary to select the appropriate solution, but also to configure and operate considering blockchain interoperability with different chains. For the industry, there is a need for solutions based on open standards. This paper proposes a Policy-based Blockchain Agnostic Framework that not only connects different blockchains but also facilitates their configuration and operation. Moreover, a case study is presented considering the cold-chain supply-chain, where each actor defines its policies based on blockchain requirements.""
""Content-Encoding"",""UTF-8""
""Content-Type-Hint"",""text/html; charset=utf-8""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=620&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094590-870;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[PDF][PDF] A Provably Secure Conditional Proxy Re-Encryption Scheme without Pairing.;A Paul, SSD Selvi, CP Rangan ; IACR Cryptol. ePrint Arch., 2019  eprint.iacr.org;;"… Owing to its transformational property, a major application of PRE is enabling secure file sharing

in blockchain powered data … an environment running PRE for the adversary A by providing A with

access to the following oracles and answering the oracle queries issued …";Autres articles;Version HTML;[PDF] iacr.org;https://eprint.iacr.org/2019/1135.pdf;;"""date"",""2019-10-02T12:48:04Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2019-10-02T12:48:04Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017) kpathsea version 6.2.3""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2019-10-02T12:48:04Z""
""created"",""2019-10-02T12:48:04Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-10-02T12:48:04Z""
""resourceName"",""1135.pdf""
""Author"",""""
""producer"",""pdfTeX-1.40.18""
""pdf:docinfo:producer"",""pdfTeX-1.40.18""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""8"",""0"",""9"",""5"",""13"",""31"",""9"",""35"",""40"",""41"",""13"",""23"",""16"",""49"",""14"",""0"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2019-10-02T12:48:04Z""
""Last-Modified"",""2019-10-02T12:48:04Z""
""dcterms:modified"",""2019-10-02T12:48:04Z""
""title"",""""
""Last-Save-Date"",""2019-10-02T12:48:04Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2019-10-02T12:48:04Z""
""meta:save-date"",""2019-10-02T12:48:04Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017) kpathsea version 6.2.3""
""Content-Length"",""385633""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""21""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""2570"",""3419"",""3451"",""2656"",""2224"",""2507"",""2108"",""1934"",""1460"",""1077"",""2622"",""2379"",""2347"",""1994"",""1442"",""2519"",""2044"",""1825"",""3380"",""3503"",""560""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-10-02T12:48:04Z""
";https://scholar.google.com/scholar?start=680&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094537-634;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[CITATION][C] Blockchain para leigos;T Laurence ;2019 Alta Books;;null;Cité 2 fois;;null;;;;https://scholar.google.com/scholar?start=450&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094609-944;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[PDF][PDF] LITHOPIA PROJECT;DR Kera ; academia.edu;;"… platform hosted by The Linux Foundation in association with several corporations (IBM, Oracle,

etc … as a prop to explore the modes of resistance to future „crypto and data … test a possibility of

anticipatory governance of emergent distributed ledger and blockchain technologies and …";Autres articles;;[PDF] academia.edu;https://www.academia.edu/download/60640727/design-tech-2019-conference-ebook_120190919-40182-4j7zzz.pdf;;;https://scholar.google.com/scholar?start=760&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094649-1112;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Systematic testing of post-quantum cryptographic implementations using metamorphic testing;S Pugh, MS Raunak, DR Kuhn… ; 2019 IEEE/ACM 4th …, 2019  ieeexplore.ieee.org;;"… Horse malware using combinatorial methods [11], and fuzz testing applied to crypto- graphic

libraries [12 … issues involved in testing research is the availability and cost of developing test oracles …

and black- box, under regular circumstances, assumes the presence of a test oracle …";Autres articles;;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/8778445/8785437/08785645.pdf?casa_token=gicgbKCz0uUAAAAA:k7iXqgNT3Tq1g1BEQ9_BF-41vLdveX-KgV403XxRlzPnMlkl23TIFHE_zcHp23EFzcJYmPnLZwU;;"""og:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""twitter:title"",""Systematic Testing of Post-Quantum Cryptographic Implementations Using Metamorphic Testing""
""twitter:card"",""summary""
""Description"",""Cryptographic algorithms are usually complex, and their code is highly compact. Moreover, there is often no test oracle to easily test some of these algorithms.""
""og:title"",""Systematic Testing of Post-Quantum Cryptographic Implementations Using Metamorphic Testing""
""resourceName"",""08785645.pdf""
""language"",""en""
""title"",""Systematic Testing of Post-Quantum Cryptographic Implementations Using Metamorphic Testing | IEEE Conference Publication | IEEE Xplore""
""og:description"",""Cryptographic algorithms are usually complex, and their code is highly compact. Moreover, there is often no test oracle to easily test some of these algorithms. Together these attributes make it extremely challenging to run tests and to discover bugs in them. Structural coverage based approaches such as statement or branch coverage are typically not very effective in discovering bugs in these types of programs. In this paper, we investigate the effectiveness of a systematic testing approach for discovering bugs in highly complex cryptographic algorithm implementations. In this work, we identify metamorphic relations based on the specifications of the algorithms, and design test cases such that a systematic coverage of the input space is achieved. Our results show that this approach is highly effective in discovering faults in complex cryptographic implementations.""
""twitter:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-UA-Compatible"",""IE=Edge""
""viewport"",""width=device-width, initial-scale=1.0""
""dc:title"",""Systematic Testing of Post-Quantum Cryptographic Implementations Using Metamorphic Testing | IEEE Conference Publication | IEEE Xplore""
""twitter:description"",""Cryptographic algorithms are usually complex, and their code is highly compact. Moreover, there is often no test oracle to easily test some of these algorithms. Together these attributes make it extremely challenging to run tests and to discover bugs in them. Structural coverage based approaches such as statement or branch coverage are typically not very effective in discovering bugs in these types of programs. In this paper, we investigate the effectiveness of a systematic testing approach for discovering bugs in highly complex cryptographic algorithm implementations. In this work, we identify metamorphic relations based on the specifications of the algorithms, and design test cases such that a systematic coverage of the input space is achieved. Our results show that this approach is highly effective in discovering faults in complex cryptographic implementations.""
""Content-Encoding"",""UTF-8""
""Content-Type-Hint"",""text/html; charset=utf-8""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=930&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094600-906;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[PDF][PDF] How DLT can improve the IPO value journey for companies and investors;M Cantamessa, D Santorsola ; webthesis.biblio.polito.it;;"… Gas: since, as it was just explained, Ether is traded on Crypto-exchanges, its price is not fixed

and depends on the Crypto-exchanges demands and offerings. This implicate that … who holds

the blockchain's base cryptocurrency (in Ethereum's case, ether) can …";Autres articles;Version HTML;[PDF] polito.it;https://webthesis.biblio.polito.it/12679/1/tesi.pdf;;"""date"",""2019-09-17T08:39:52Z""
""pdf:PDFVersion"",""1.7""
""xmp:CreatorTool"",""Word""
""pdf:docinfo:title"",""Microsoft Word - PoliTo_Masterthesis_IPO Blockchain_Danilo Santorsola_vFinal.docx""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""pdfa:PDFVersion"",""A-2u""
""xmpMM:History:Action"",""converted""
""language"",""en""
""dc:format"",""application/pdf; version=""""A-2u"""""",""application/pdf; version=1.7""
""pdf:docinfo:creator_tool"",""Word""
""access_permission:fill_in_form"",""true""
""xmpMM:History:When"",""2019-09-17T10:39:52Z""
""pdf:encrypted"",""false""
""dc:title"",""Microsoft Word - PoliTo_Masterthesis_IPO Blockchain_Danilo Santorsola_vFinal.docx""
""xmp:CreateDate"",""2019-09-17T08:29:42Z""
""modified"",""2019-09-17T08:39:52Z""
""xmpMM:History:SoftwareAgent"",""3-Heights(TM) Document Converter 4.8.25.5 (www.pdf-tools.com)""
""pdf:hasMarkedContent"",""false""
""xmpMM:History:InstanceID"",""urn:uuid:9432202c-80d1-471c-8abc-80dd1afa3d42""
""xmp:ModifyDate"",""2019-09-17T10:39:52Z""
""meta:creation-date"",""2019-09-17T08:29:42Z""
""created"",""2019-09-17T08:29:42Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-09-17T08:29:42Z""
""resourceName"",""tesi.pdf""
""pdfaid:part"",""2""
""producer"",""3-Heights(TM) Document Converter 4.8.25.5 (www.pdf-tools.com)""
""pdf:docinfo:producer"",""3-Heights(TM) Document Converter 4.8.25.5 (www.pdf-tools.com)""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""access_permission:modify_annotations"",""true""
""dcterms:created"",""2019-09-17T08:29:42Z""
""Last-Modified"",""2019-09-17T08:39:52Z""
""dcterms:modified"",""2019-09-17T08:39:52Z""
""title"",""Microsoft Word - PoliTo_Masterthesis_IPO Blockchain_Danilo Santorsola_vFinal.docx""
""Last-Save-Date"",""2019-09-17T08:39:52Z""
""pdf:docinfo:modified"",""2019-09-17T08:39:52Z""
""meta:save-date"",""2019-09-17T08:39:52Z""
""Content-Length"",""3213302""
""Content-Type"",""application/pdf""
""xmp:MetadataDate"",""2019-09-17T10:39:52Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""pdfaid:conformance"",""U""
""pdf:producer"",""3-Heights(TM) Document Converter 4.8.25.5 (www.pdf-tools.com)""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""90""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""242"",""20"",""955"",""1094"",""2300"",""2379"",""2403"",""2124"",""2284"",""2471"",""1492"",""2103"",""1549"",""2150"",""2315"",""2290"",""1882"",""1385"",""2384"",""1252"",""1904"",""2482"",""2407"",""2497"",""1861"",""2067"",""2392"",""2216"",""2023"",""1773"",""2391"",""2107"",""1874"",""2540"",""2589"",""2446"",""1924"",""2009"",""1952"",""2209"",""2069"",""2101"",""2357"",""2482"",""2756"",""1922"",""2264"",""2047"",""1829"",""2006"",""2273"",""1329"",""1208"",""2474"",""2227"",""2318"",""2131"",""1921"",""1326"",""970"",""2101"",""2204"",""1111"",""1284"",""1012"",""618"",""1352"",""2497"",""205"",""1426"",""2111"",""47"",""2145"",""1332"",""1007"",""1765"",""1622"",""2296"",""1996"",""2225"",""2261"",""2469"",""1058"",""1378"",""1874"",""1386"",""1430"",""1538"",""23"",""820""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-09-17T08:29:42Z""
";https://scholar.google.com/scholar?start=720&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094602-915;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[PDF][PDF] A course design framework for distributed ledger technologies;M Obert ; researchgate.net;;"… Association lists cryptography, peer to peer, ledger, consensus, validity rules, and

crypto-economics as … & Jo Jeannie, 2019, p. 3). Stanford also offers a class about blockchain

technology ""CS … Other colleges like the University of Maryland offered a cryptocurrency lab course …";Autres articles;Version HTML;[PDF] researchgate.net;https://www.researchgate.net/profile/Marius_Obert/publication/340828203_A_course_design_framework_for_distributed_ledger_technologies_A_course_design_framework_for_distributed_ledger_technologies_Ein_Framework_zum_Entwurf_von_Distributed_Ledger_Technologie_Kursen/links/5e9ff01ca6fdcc20bb360fc8/A-course-design-framework-for-distributed-ledger-technologies-A-course-design-framework-for-distributed-ledger-technologies-Ein-Framework-zum-Entwurf-von-Distributed-Ledger-Technologie-Kursen.pdf;;;https://scholar.google.com/scholar?start=730&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094668-1191;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[PDF][PDF] Blockchain Architecture to Higher Education Systems;K Palanivel ; International Journal of Latest Technology in …, 2019  academia.edu;;"… Transactions - A transaction represents a transfer of the cryptocurrency between blockchain

network users. Each block in a blockchain can contain zero or more transactions. A

blockchain network user sends information to the blockchain network …";Cité 4 fois;Les 2 versions;[PDF] academia.edu;https://www.academia.edu/download/58597592/Blockchain_Architecture_to_Higher_Education_Systems.pdf;;;https://scholar.google.com/scholar?start=410&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094647-1103;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[PDF][PDF] Musiikkiala lohkopeleissä: Lohkoketjuteknologian soveltaminen musiikkialalla;J Nikander ;2019 theseus.fi;;"… ja visioita (All Crypto Whitepapers 2019; Perez 2019). Rakenteeltaan tämä opinnäytetyö etenee

johdannosta olennaisimpien käsitteiden … Oraakkeli (Oracle) on kolmannen osapuolen ohjelma,

joka lähettää tietoa lohkoket … The blockchain takes that multiplicity of functions further …";Autres articles;Version HTML;[PDF] theseus.fi;https://www.theseus.fi/bitstream/handle/10024/263490/Musiikkiala%20lohkopeleiss%C3%A4%20Lohkoketjuteknologian%20soveltaminen%20musiikkialalla.pdf?sequence=2;;"""date"",""2019-11-27T20:48:00Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.7""
""xmp:CreatorTool"",""MicrosoftÂŽ Word for Office 365""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dc:creator"",""Emilia Reponen""
""language"",""fi""
""dcterms:created"",""2019-11-27T20:48:00Z""
""Last-Modified"",""2019-11-27T20:48:00Z""
""dcterms:modified"",""2019-11-27T20:48:00Z""
""dc:format"",""application/pdf; version=1.7""
""xmpMM:DocumentID"",""uuid:153D0EC3-DBAD-45C7-9950-FA78CE686672""
""Last-Save-Date"",""2019-11-27T20:48:00Z""
""pdf:docinfo:creator_tool"",""MicrosoftÂŽ Word for Office 365""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2019-11-27T20:48:00Z""
""meta:save-date"",""2019-11-27T20:48:00Z""
""pdf:encrypted"",""false""
""xmp:CreateDate"",""2019-11-27T22:48:00Z""
""modified"",""2019-11-27T20:48:00Z""
""Content-Length"",""818499""
""pdf:hasMarkedContent"",""true""
""Content-Type"",""application/pdf""
""xmp:ModifyDate"",""2019-11-27T22:48:00Z""
""pdf:docinfo:creator"",""Emilia Reponen""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Emilia Reponen""
""dc:language"",""fi-FI""
""meta:author"",""Emilia Reponen""
""pdf:producer"",""MicrosoftÂŽ Word for Office 365""
""meta:creation-date"",""2019-11-27T20:48:00Z""
""created"",""2019-11-27T20:48:00Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""73""
""Creation-Date"",""2019-11-27T20:48:00Z""
""resourceName"",""Musiikkiala%20lohkopeleiss%C3%A4%20Lohkoketjuteknologian%20soveltaminen%20musiikkialalla.pdf""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""219"",""1975"",""1898"",""2887"",""2389"",""2564"",""2535"",""669"",""2089"",""2320"",""2006"",""1612"",""2326"",""2569"",""2500"",""2437"",""2117"",""2336"",""2360"",""2211"",""2477"",""2347"",""2381"",""1976"",""2421"",""2510"",""2591"",""2750"",""2548"",""2677"",""2327"",""2496"",""1601"",""2305"",""2387"",""1972"",""2324"",""2229"",""2243"",""2534"",""2655"",""2545"",""2456"",""2365"",""2486"",""2531"",""2444"",""2391"",""2637"",""2583"",""2548"",""2333"",""2459"",""1761"",""2138"",""2514"",""2392"",""2403"",""1926"",""1309"",""1572"",""1421"",""1353"",""1732"",""1401"",""1506"",""1631"",""861"",""682"",""842"",""207"",""77"",""5""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""Author"",""Emilia Reponen""
""producer"",""MicrosoftÂŽ Word for Office 365""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""MicrosoftÂŽ Word for Office 365""
""pdf:docinfo:created"",""2019-11-27T20:48:00Z""
";https://scholar.google.com/scholar?start=920&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094616-974;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;In Code We Trust? Trustlessness and Smart Contracts;M Zou, G Cheng, M Soria Heredia ; Trustlessness and Smart …, 2019  papers.ssrn.com;;"… To adapt to changing circumstances, smart contracts often use oracles to decide whether pre-

determined conditions have … in this case, flight delay information) provided by a third party outside

the blockchain means that an element of trust will remain – the oracle must be …";;null;null;;;;https://scholar.google.com/scholar?start=790&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094590-869;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Los contratos inteligentes en Espańa;P Medina Fernández ;2019 riull.ull.es;;"… 25 BUCK J., “Oráculos de Blockchain, explicados”, Cointelegraph. Recuperado de:

https://es.cointelegraph.com/explained/blockchain-oracles-explained (última consulta:

4 de junio de 2019) y “What's a blockchain Oracle?”, BlockchainHub …";Autres articles;Version HTML;[PDF] ull.es;https://riull.ull.es/xmlui/bitstream/handle/915/14876/Los%20contratos%20inteligentes%20en%20Espana.pdf?sequence=1;;"""date"",""2019-06-13T21:47:50Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.7""
""xmp:CreatorTool"",""MicrosoftÂŽ Word para Office 365""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dc:creator"",""LIDIA MARLENE RAMOS PEREZ""
""language"",""es""
""dcterms:created"",""2019-06-13T21:47:50Z""
""Last-Modified"",""2019-06-13T21:47:50Z""
""dcterms:modified"",""2019-06-13T21:47:50Z""
""dc:format"",""application/pdf; version=1.7""
""xmpMM:DocumentID"",""uuid:3B789346-BDE0-425A-A530-A31F07FF3F43""
""Last-Save-Date"",""2019-06-13T21:47:50Z""
""pdf:docinfo:creator_tool"",""MicrosoftÂŽ Word para Office 365""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2019-06-13T21:47:50Z""
""meta:save-date"",""2019-06-13T21:47:50Z""
""pdf:encrypted"",""false""
""xmp:CreateDate"",""2019-06-13T22:47:50Z""
""modified"",""2019-06-13T21:47:50Z""
""Content-Length"",""462137""
""pdf:hasMarkedContent"",""true""
""Content-Type"",""application/pdf""
""xmp:ModifyDate"",""2019-06-13T22:47:50Z""
""pdf:docinfo:creator"",""LIDIA MARLENE RAMOS PEREZ""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""LIDIA MARLENE RAMOS PEREZ""
""dc:language"",""es-ES""
""meta:author"",""LIDIA MARLENE RAMOS PEREZ""
""pdf:producer"",""MicrosoftÂŽ Word para Office 365""
""meta:creation-date"",""2019-06-13T21:47:50Z""
""created"",""2019-06-13T21:47:50Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""38""
""Creation-Date"",""2019-06-13T21:47:50Z""
""resourceName"",""Los%20contratos%20inteligentes%20en%20Espana.pdf""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""470"",""1926"",""950"",""2076"",""2097"",""2260"",""2185"",""1535"",""2039"",""2157"",""2465"",""2937"",""2050"",""2562"",""2615"",""2226"",""2054"",""1840"",""2374"",""1861"",""2135"",""2339"",""2469"",""2172"",""2600"",""2260"",""1693"",""2446"",""1833"",""2049"",""2155"",""2204"",""1097"",""1431"",""1308"",""1756"",""1491"",""556""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""Author"",""LIDIA MARLENE RAMOS PEREZ""
""producer"",""MicrosoftÂŽ Word para Office 365""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""MicrosoftÂŽ Word para Office 365""
""pdf:docinfo:created"",""2019-06-13T21:47:50Z""
";https://scholar.google.com/scholar?start=680&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094553-706;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[PDF][PDF] Should Code Be Law? Smart Contracts, Blockchain, and Boilerplate;J Lingwall, R Mogallapu ; UMKC L. Rev., 2019  HeinOnline;;"… execute automatically regardless of the state of the world (absent information from oracles, which

must … As with blockchain itself, smart contracting enables the sociality of the market whether the

parties … can reference the outside world, but must do so through an ""oracle,"" a source …";Autres articles;;[PDF] heinonline.org;https://heinonline.org/hol-cgi-bin/get_pdf.cgi?handle=hein.journals/umkc88&section=16&casa_token=wWvm2CZ5L14AAAAA:zJehLdZkwYWISj6XaPwVubWd-GJvEci-7dvFmsOkD-5uIew2lnsBGCR5ZMQ8XRfNIb64pIY;;"""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""REFRESH"",""1; url=https://heinonline.org/HOL/Page?handle=hein.journals/umkc88&div=16&g_sent=1&casa_token=wWvm2CZ5L14AAAAA:zJehLdZkwYWISj6XaPwVubWd-GJvEci-7dvFmsOkD-5uIew2lnsBGCR5ZMQ8XRfNIb64pIY""
""Content-Encoding"",""UTF-8""
""resourceName"",""get_pdf.cgi""
""language"",""""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=520&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094546-673;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[PDF][PDF] To Analyse How Blockchain Technology can be used to Securely Store Different Information Sources;A Smith ; ijisrt.com;;"… to more sophisticated attacks that use deviations in system behavior as so-called ""oracles"" to

obtain … However, since Blockchain applications are designed for extremely long lifetimes - think

of a notary function, for … For blockchains such a ""crypto agility"" does not exist so far [23,34 …";Autres articles;Version HTML;[PDF] ijisrt.com;https://ijisrt.com/wp-content/uploads/2019/02/IJISRT19JA332.pdf;;;https://scholar.google.com/scholar?start=490&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094628-1023;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Watermarking PRFs from lattices: stronger security via extractable PRFs;S Kim, DJ Wu ; Annual International Cryptology Conference, 2019  Springer;;"… lattice-based construction of secret-key watermarking due to Kim and Wu (CRYPTO 2017) only …

against adversaries that have access to both the marking and the extraction oracles … PRFs from

standard lattice assumptions where the adversary has access to the extraction oracle …";Cité 17 fois;Les 3 versions;[PDF] virginia.edu;https://www.cs.virginia.edu/dwu4/papers/WatermarkingExt.pdf;;"""date"",""2019-05-31T22:55:45Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2019-05-31T22:55:45Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.16 (TeX Live 2015/Debian) kpathsea version 6.2.1""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2019-05-31T22:55:45Z""
""created"",""2019-05-31T22:55:45Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-05-31T22:55:45Z""
""resourceName"",""WatermarkingExt.pdf""
""Author"",""""
""producer"",""pdfTeX-1.40.16""
""pdf:docinfo:producer"",""pdfTeX-1.40.16""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""4"",""0"",""3"",""30"",""1"",""0"",""0"",""0"",""12"",""20"",""17"",""0"",""21"",""32"",""22"",""8"",""20"",""27"",""10"",""1"",""15"",""7"",""14"",""6"",""71"",""84"",""31"",""4"",""0"",""0"",""0"",""0"",""9"",""22"",""3"",""0"",""3"",""0"",""3"",""0"",""0"",""0"",""0"",""0"",""8"",""0"",""43"",""67"",""93"",""50"",""58"",""85"",""19"",""34"",""97"",""54"",""120"",""114"",""11"",""68"",""97"",""121"",""108"",""124"",""52"",""5"",""75"",""47"",""14"",""14"",""4"",""22"",""34"",""14"",""5"",""15"",""23"",""26"",""3"",""34"",""41"",""17"",""18"",""5"",""4"",""5"",""1"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2019-05-31T22:55:45Z""
""Last-Modified"",""2019-05-31T22:55:45Z""
""dcterms:modified"",""2019-05-31T22:55:45Z""
""title"",""""
""Last-Save-Date"",""2019-05-31T22:55:45Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2019-05-31T22:55:45Z""
""meta:save-date"",""2019-05-31T22:55:45Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.16 (TeX Live 2015/Debian) kpathsea version 6.2.1""
""Content-Length"",""858392""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""89""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""2491"",""3387"",""3561"",""3304"",""2506"",""3547"",""3517"",""3610"",""3376"",""2931"",""2883"",""3034"",""3465"",""3208"",""2740"",""2363"",""2188"",""2440"",""2282"",""2208"",""2615"",""2043"",""2802"",""2435"",""2788"",""1809"",""1868"",""2371"",""2417"",""2874"",""3091"",""3391"",""3283"",""1807"",""3434"",""2621"",""2907"",""2661"",""2575"",""2633"",""2929"",""2029"",""2092"",""1991"",""1814"",""2146"",""2721"",""1767"",""2004"",""2076"",""2345"",""2182"",""1978"",""2292"",""1949"",""1702"",""1788"",""1623"",""1786"",""2664"",""2251"",""2010"",""1594"",""1930"",""1716"",""1959"",""1880"",""2192"",""2385"",""2321"",""2564"",""2395"",""2495"",""2597"",""2368"",""2726"",""2191"",""2441"",""2469"",""2473"",""2720"",""2668"",""2511"",""2228"",""2154"",""2640"",""2347"",""2441"",""705""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-05-31T22:55:45Z""
";https://scholar.google.com/scholar?start=840&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094583-831;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[CITATION][C] 9 Blockchains;E Mik;;;null;Autres articles;;null;;;;https://scholar.google.com/scholar?start=650&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094661-1164;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Sora: A Decentralized Autonomous Economy;M Takemiya ; … Conference on Blockchain and Cryptocurrency  …, 2019  ieeexplore.ieee.org;;"… basket of goods). Instead, stability must be guaranteed through a mechanism that

backs a stable measure of value with a volatile measure. This can be implemented

using blockchain technology by having a pricing oracle in a …";Autres articles;;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/8744142/8751228/08751489.pdf?casa_token=1LVDU_Mld9oAAAAA:pL4UJDwZSznijC1mdg9nNEyyC_DCioNjdJ7bCO1ntAuI8sjXcQhwZjeBqEmLij57Nj3J31b_Rdg;;"""og:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""twitter:title"",""Sora: A Decentralized Autonomous Economy""
""twitter:card"",""summary""
""Description"",""Money, when viewed as a social construct, can be a powerful tool for organizing society and allocating finite resources. However, existing monetary systems are ""
""og:title"",""Sora: A Decentralized Autonomous Economy""
""resourceName"",""08751489.pdf""
""language"",""en""
""title"",""Sora: A Decentralized Autonomous Economy | IEEE Conference Publication | IEEE Xplore""
""og:description"",""Money, when viewed as a social construct, can be a powerful tool for organizing society and allocating finite resources. However, existing monetary systems are highly centralized and this centralization has caused many crises in recent times. We therefore propose a token-based economic system that is self-regulating, can adjust the quantity of tokens to provide liquidity as needed, and avoids moral hazards. An early version of this system has been implemented on a blockchain platform as the Sora decentralized autonomous economy (DAE). Through allocating votes in a Sybil-resistant way, the Sora DAE democratically allocates new purchasing power according to open referendums. A dual-token system allows both stability of value for payments and creation of tokens for economic growth.""
""twitter:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-UA-Compatible"",""IE=Edge""
""viewport"",""width=device-width, initial-scale=1.0""
""dc:title"",""Sora: A Decentralized Autonomous Economy | IEEE Conference Publication | IEEE Xplore""
""twitter:description"",""Money, when viewed as a social construct, can be a powerful tool for organizing society and allocating finite resources. However, existing monetary systems are highly centralized and this centralization has caused many crises in recent times. We therefore propose a token-based economic system that is self-regulating, can adjust the quantity of tokens to provide liquidity as needed, and avoids moral hazards. An early version of this system has been implemented on a blockchain platform as the Sora decentralized autonomous economy (DAE). Through allocating votes in a Sybil-resistant way, the Sora DAE democratically allocates new purchasing power according to open referendums. A dual-token system allows both stability of value for payments and creation of tokens for economic growth.""
""Content-Encoding"",""UTF-8""
""Content-Type-Hint"",""text/html; charset=utf-8""
""Content-Length"",""39469""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=980&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094619-984;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Smart Contracts and Void Declarations of Intent;T Hoffmann ; International Conference on Advanced Information …, 2019  Springer;;"… The term Smart Contract has gone somewhat rogue, as even oracles are labelled Smart Contracts,

although their purpose is restriced to collecting and … This question can be controversial if the Smart

Contract has been set up on a blockchain consensus architecture, as it is today …";Cité 2 fois;Les 3 versions;[PDF] researchgate.net;https://www.researchgate.net/profile/Thomas-Hoffmann/publication/333315551_Smart_Contracts_and_Void_Declarations_of_Intent/links/5db6b3aa4585155e270b6418/Smart-Contracts-and-Void-Declarations-of-Intent.pdf;;;https://scholar.google.com/scholar?start=800&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094569-776;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Quantum security of hash functions and property-preservation of iterated hashing;B Hamlin, F Song ; International Conference on PostQuantum …, 2019  Springer;;"… are indispensable in constructing key-establishment, authentication, encryption, digital signature,

cryptocurrency, and more … Another property of classical random oracles is that they can be

adaptively … of queries have been made, the algorithm simulating the oracle can change …";Cité 3 fois;Les 3 versions;[PDF] arxiv.org;https://arxiv.org/pdf/1902.08709;;"""date"",""2019-02-26T02:01:14Z""
""pdf:PDFVersion"",""1.4""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.4""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""xmp:CreateDate"",""2019-02-25T21:01:14Z""
""modified"",""2019-02-26T02:01:14Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""xmp:ModifyDate"",""2019-02-25T21:01:14Z""
""pdf:docinfo:creator"",""""
""meta:author"",""""
""meta:creation-date"",""2019-02-26T02:01:14Z""
""created"",""2019-02-26T02:01:14Z""
""xmp:About"",""uuid:f20840a8-7186-11f4-0000-bda1ff0ed584""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-02-26T02:01:14Z""
""resourceName"",""1902.08709""
""Author"",""""
""producer"",""dvips + GPL Ghostscript GIT PRERELEASE 9.22""
""pdf:docinfo:producer"",""dvips + GPL Ghostscript GIT PRERELEASE 9.22""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""9"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2019-02-26T02:01:14Z""
""Last-Modified"",""2019-02-26T02:01:14Z""
""dcterms:modified"",""2019-02-26T02:01:14Z""
""title"",""""
""xmpMM:DocumentID"",""uuid:f20840a8-7186-11f4-0000-bda1ff0ed584""
""Last-Save-Date"",""2019-02-26T02:01:14Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2019-02-26T02:01:14Z""
""meta:save-date"",""2019-02-26T02:01:14Z""
""Content-Length"",""309850""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""20""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""2053"",""2735"",""2730"",""2594"",""2438"",""1625"",""1576"",""1789"",""2334"",""1962"",""2148"",""1903"",""2713"",""1698"",""1674"",""1316"",""1686"",""1479"",""1253"",""1901""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-02-26T02:01:14Z""
";https://scholar.google.com/scholar?start=590&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094588-851;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Data-driven and digital procurement governance: Revisiting two well-known elephant tales;A Sanchez;Graells  Available at SSRN 3440552, 2019  papers.ssrn.com;;"… The paper then assesses the promises of blockchain and smart contracts for procurement

governance and raises the prospect that these may be new white elephants that do not offer

significant advantages over existing sophisticated databases, or beyond narrow back-office …";Autres articles;;null;;;;https://scholar.google.com/scholar?start=670&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094626-1019;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Simple proofs of space-time and rational proofs of storage;T Moran, I Orlov ; Annual International Cryptology Conference, 2019  Springer;;"… As long as these conditions are met, it seems reasonable to assume that real-world users would

choose storage over work (especially in a crypto-currency setting … Formally, we describe the

protocol in the presence of two types of random oracles, a “work” oracle \(H^{(\text {work …";Cité 10 fois;Les 3 versions;[PDF] iacr.org;https://eprint.iacr.org/2016/035.pdf;;"""date"",""2019-02-28T22:18:57Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2019-02-28T22:18:57Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017/Debian) kpathsea version 6.2.3""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2019-02-28T22:18:57Z""
""created"",""2019-02-28T22:18:57Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-02-28T22:18:57Z""
""resourceName"",""035.pdf""
""Author"",""""
""producer"",""pdfTeX-1.40.18""
""pdf:docinfo:producer"",""pdfTeX-1.40.18""
""pdf:docinfo:custom:HG.Rev"",""42e1f8763d76 tip""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""4"",""8"",""14"",""0"",""6"",""13"",""1"",""12"",""73"",""22"",""8"",""38"",""57"",""12"",""17"",""7"",""0"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2019-02-28T22:18:57Z""
""Last-Modified"",""2019-02-28T22:18:57Z""
""dcterms:modified"",""2019-02-28T22:18:57Z""
""title"",""""
""Last-Save-Date"",""2019-02-28T22:18:57Z""
""HG.Rev"",""42e1f8763d76 tip""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2019-02-28T22:18:57Z""
""meta:save-date"",""2019-02-28T22:18:57Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017/Debian) kpathsea version 6.2.3""
""Content-Length"",""252159""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""23""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""3629"",""4091"",""4495"",""3909"",""3061"",""3124"",""2653"",""4108"",""2854"",""2823"",""1351"",""2935"",""1556"",""2513"",""2142"",""2344"",""1589"",""2307"",""3225"",""3282"",""3293"",""3309"",""1024""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-02-28T22:18:57Z""
";https://scholar.google.com/scholar?start=830&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094633-1046;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Exploring the role of trust in blockchain adoption: an inductive approach;M Fleischmann, B Ivens ; … of the 52nd …, 2019  scholarspace.manoa.hawaii.edu;;"… The financial sector is seen as pioneering the blockchain idea, having launched digital

crypto-currencies as its most well-known application … What are the weaknesses of blockchain

technology … The cryptocurrency Bitcoin [25] is one of the most widely used blockchain applications …";Cité 7 fois;Les 5 versions;[PDF] hawaii.edu;https://scholarspace.manoa.hawaii.edu/bitstream/10125/60120/0680.pdf;;"""date"",""2018-09-17T21:07:55Z""
""pdf:PDFVersion"",""1.6""
""xmp:CreatorTool"",""Acrobat PDFMaker 15 fĂźr Word""
""pdf:docinfo:title"",""Author Guidelines for 8""
""Company"",""Shidler College of Business""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.6""
""pdf:docinfo:creator_tool"",""Acrobat PDFMaker 15 fĂźr Word""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""Author Guidelines for 8""
""xmp:CreateDate"",""2018-09-17T14:07:23Z""
""modified"",""2018-09-17T21:07:55Z""
""pdf:docinfo:custom:SourceModified"",""D:20180917203624""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""true""
""xmp:ModifyDate"",""2018-09-17T14:07:55Z""
""pdf:docinfo:creator"",""HICSS_PC""
""meta:author"",""HICSS_PC""
""meta:creation-date"",""2018-09-17T21:07:23Z""
""created"",""2018-09-17T21:07:23Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2018-09-17T21:07:23Z""
""resourceName"",""0680.pdf""
""pdf:docinfo:custom:Comments"",""""
""Author"",""HICSS_PC""
""producer"",""Adobe PDF Library 15.0""
""pdf:docinfo:producer"",""Adobe PDF Library 15.0""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""HICSS_PC""
""dcterms:created"",""2018-09-17T21:07:23Z""
""Last-Modified"",""2018-09-17T21:07:55Z""
""dcterms:modified"",""2018-09-17T21:07:55Z""
""title"",""Author Guidelines for 8""
""xmpMM:DocumentID"",""uuid:09503fe3-5302-4537-a99d-4f3d75e809c4""
""Last-Save-Date"",""2018-09-17T21:07:55Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2018-09-17T21:07:55Z""
""meta:save-date"",""2018-09-17T21:07:55Z""
""Content-Length"",""287979""
""Content-Type"",""application/pdf""
""xmp:MetadataDate"",""2018-09-17T14:07:55Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""HICSS_PC""
""pdf:producer"",""Adobe PDF Library 15.0""
""dc:subject"",""""
""Comments"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""10""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""4407"",""5393"",""5609"",""5193"",""4577"",""4904"",""5842"",""5589"",""5251"",""5756""
""access_permission:extract_content"",""true""
""pdf:docinfo:custom:Company"",""Shidler College of Business""
""access_permission:can_print"",""true""
""SourceModified"",""D:20180917203624""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2018-09-17T21:07:23Z""
";https://scholar.google.com/scholar?start=860&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094628-1029;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Raptor: a practical lattice-based (linkable) ring signature;X Lu, MH Au, Z Zhang ; … Conference on Applied Cryptography and Network …, 2019  Springer;;"… To date, linkable ring signature has become a mainstream solution to protect sender privacy

in cryptocurrency transaction [43] … Both of the RST and AOS constructions are secure in the

random oracle model and the signature sizes are linear to the ring size …";Cité 19 fois;Les 3 versions;[PDF] iacr.org;https://eprint.iacr.org/2018/857.pdf;;"""date"",""2019-03-13T15:28:43Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""2"",""0"",""1"",""5"",""19"",""39"",""13"",""2"",""9"",""19"",""24"",""19"",""14"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""1"",""2"",""22"",""28"",""21"",""42"",""67"",""68"",""44""
""pdf:PDFVersion"",""1.5""
""xmp:CreatorTool"",""TeX""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dcterms:created"",""2019-03-13T15:28:43Z""
""language"",""en""
""Last-Modified"",""2019-03-13T15:28:43Z""
""dcterms:modified"",""2019-03-13T15:28:43Z""
""dc:format"",""application/pdf; version=1.5""
""Last-Save-Date"",""2019-03-13T15:28:43Z""
""pdf:docinfo:creator_tool"",""TeX""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2019-03-13T15:28:43Z""
""meta:save-date"",""2019-03-13T15:28:43Z""
""pdf:encrypted"",""false""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.19 (TeX Live 2018) kpathsea version 6.3.0""
""modified"",""2019-03-13T15:28:43Z""
""Content-Length"",""493686""
""pdf:hasMarkedContent"",""false""
""Content-Type"",""application/pdf""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.19 (TeX Live 2018) kpathsea version 6.3.0""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""trapped"",""False""
""meta:creation-date"",""2019-03-13T15:28:43Z""
""created"",""2019-03-13T15:28:43Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""30""
""Creation-Date"",""2019-03-13T15:28:43Z""
""resourceName"",""857.pdf""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""2221"",""2630"",""2737"",""2121"",""2388"",""2354"",""2010"",""1665"",""2464"",""1653"",""1821"",""1970"",""1972"",""2187"",""2809"",""2933"",""2874"",""2936"",""1806"",""1590"",""2176"",""1765"",""1885"",""1619"",""1852"",""2287"",""2356"",""2459"",""2251"",""2317""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""producer"",""pdfTeX-1.40.19""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""pdfTeX-1.40.19""
""pdf:docinfo:created"",""2019-03-13T15:28:43Z""
";https://scholar.google.com/scholar?start=840&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094597-892;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[CITATION][C] A simpler construction of traceable and linkable ring signature scheme;LC Wulu Li, X Lai, X Zhang, J Xin;;;null;Autres articles;;null;;;;https://scholar.google.com/scholar?start=710&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094576-805;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;On Graph Based Cryptocurrency Systems;EL Helland ;2019 ntnuopen.ntnu.no;;"… This thesis emphasizes the trade-offs made when moving from a blockchain to a DAG as the

data structure in a cryptocurrency system … This is the most common version of the blockchain and

the one used for all current cryptocurrency implementations of some scale …";Autres articles;Version HTML;[PDF] ntnu.no;https://ntnuopen.ntnu.no/ntnu-xmlui/bitstream/handle/11250/2623160/no.ntnu%3Ainspera%3A2527126.pdf?sequence=1;;"""date"",""2019-06-09T19:00:11Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.7""
""xmp:CreatorTool"",""pdftk 2.02 - www.pdftk.com""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dcterms:created"",""2019-06-09T19:00:11Z""
""language"",""en""
""Last-Modified"",""2019-06-09T19:00:11Z""
""dcterms:modified"",""2019-06-09T19:00:11Z""
""dc:format"",""application/pdf; version=1.7""
""Last-Save-Date"",""2019-06-09T19:00:11Z""
""pdf:docinfo:creator_tool"",""pdftk 2.02 - www.pdftk.com""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2019-06-09T19:00:11Z""
""meta:save-date"",""2019-06-09T19:00:11Z""
""pdf:encrypted"",""false""
""modified"",""2019-06-09T19:00:11Z""
""Content-Length"",""8292215""
""pdf:hasMarkedContent"",""false""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""meta:creation-date"",""2019-06-09T19:00:11Z""
""created"",""2019-06-09T19:00:11Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""106""
""Creation-Date"",""2019-06-09T19:00:11Z""
""resourceName"",""no.ntnu%3Ainspera%3A2527126.pdf""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""336"",""0"",""320"",""0"",""1207"",""0"",""1232"",""0"",""1203"",""0"",""509"",""0"",""1161"",""1332"",""0"",""1636"",""2393"",""115"",""0"",""480"",""0"",""1903"",""2302"",""2071"",""2194"",""1573"",""0"",""1665"",""1757"",""1753"",""2281"",""2505"",""2482"",""2403"",""1809"",""2637"",""2534"",""2519"",""2567"",""1137"",""1180"",""1700"",""2450"",""1941"",""1788"",""2464"",""1227"",""1803"",""2117"",""2457"",""2179"",""803"",""0"",""1560"",""1463"",""1643"",""2424"",""1771"",""2466"",""1699"",""2031"",""1401"",""2411"",""1252"",""2053"",""2209"",""2570"",""2298"",""2436"",""825"",""0"",""1553"",""2523"",""1156"",""2285"",""1328"",""2392"",""2517"",""1757"",""1034"",""1818"",""1613"",""1526"",""1061"",""364"",""549"",""0"",""1657"",""2319"",""2528"",""2392"",""2275"",""2512"",""2531"",""733"",""1884"",""1939"",""1664"",""0"",""1551"",""1803"",""1754"",""1843"",""1912"",""606"",""336""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""producer"",""itext-paulo-155 (itextpdf.sf.net-lowagie.com)""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""itext-paulo-155 (itextpdf.sf.net-lowagie.com)""
""pdf:docinfo:created"",""2019-06-09T19:00:11Z""
";https://scholar.google.com/scholar?start=620&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094595-881;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;An efficient privacy-preserving authentication scheme for energy internet-based vehicle-to-grid communication;P Gope, B Sikdar ; IEEE Transactions on Smart Grid, 2019  ieeexplore.ieee.org;;"… a probabilis- tic polynomial-time adversary A, in distinguishing f from another function f . We say

that f is a (n, q, ?)-secure pseu- dorandom function if there is no feasible algorithm H that can

distinguish f from f with advantage AdvH ? ?, while making at most q oracle queries to f …";Cité 17 fois;Les 3 versions;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/5165411/5446437/08680695.pdf?casa_token=zIaa72XAXUoAAAAA:cwtFXFrs_xGAU_7tfho9nnxb3Uwis8z_UlK_SWJRoN5hRBqN0-wPgRW4rwvfQ4lrfAz2i99UGcg;;"""og:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""twitter:title"",""An Efficient Privacy-Preserving Authentication Scheme for Energy Internet-Based Vehicle-to-Grid Communication""
""twitter:card"",""summary""
""Description"",""The energy Internet (EI) represents a new electric grid infrastructure that uses computing and communication to transform legacy power grids into systems that s""
""og:title"",""An Efficient Privacy-Preserving Authentication Scheme for Energy Internet-Based Vehicle-to-Grid Communication""
""resourceName"",""08680695.pdf""
""language"",""en""
""title"",""An Efficient Privacy-Preserving Authentication Scheme for Energy Internet-Based Vehicle-to-Grid Communication | IEEE Journals & Magazine | IEEE Xplore""
""og:description"",""The energy Internet (EI) represents a new electric grid infrastructure that uses computing and communication to transform legacy power grids into systems that support open innovation. EI provides bidirectional communication for analysis and improvement of energy usage between service providers and customers. To ensure a secure, reliable, and efficient operation, the EI should be protected from cyber attacks. Thus, secure and efficient key establishment is an important issue for this Internet-based smart grid environment. In this paper, we propose an efficient privacy-preserving authentication scheme for EI-based vehicle-to-grid communication using lightweight cryptographic primitives such as one-way non-collision hash functions. In our proposed scheme, a customer can securely access services provided by the service provider using a symmetric key established between them. Detailed security and performance analysis of our proposed scheme are presented to show that it is resilient against many security attacks, cost effective in computation and communication, and provides an efficient solution for the EI.""
""twitter:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-UA-Compatible"",""IE=Edge""
""viewport"",""width=device-width, initial-scale=1.0""
""dc:title"",""An Efficient Privacy-Preserving Authentication Scheme for Energy Internet-Based Vehicle-to-Grid Communication | IEEE Journals & Magazine | IEEE Xplore""
""twitter:description"",""The energy Internet (EI) represents a new electric grid infrastructure that uses computing and communication to transform legacy power grids into systems that support open innovation. EI provides bidirectional communication for analysis and improvement of energy usage between service providers and customers. To ensure a secure, reliable, and efficient operation, the EI should be protected from cyber attacks. Thus, secure and efficient key establishment is an important issue for this Internet-based smart grid environment. In this paper, we propose an efficient privacy-preserving authentication scheme for EI-based vehicle-to-grid communication using lightweight cryptographic primitives such as one-way non-collision hash functions. In our proposed scheme, a customer can securely access services provided by the service provider using a symmetric key established between them. Detailed security and performance analysis of our proposed scheme are presented to show that it is resilient against many security attacks, cost effective in computation and communication, and provides an efficient solution for the EI.""
""Content-Encoding"",""UTF-8""
""Content-Type-Hint"",""text/html; charset=utf-8""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=700&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094576-809;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[PDF][PDF] CERBE;P Limata ;2019 repec.lumsa.it;;"… Hence, crypto-contracts … Moreover, the so-called “oracle problem” (Egberts, Page 14. 2017) –

introducing an external third party into the blockchain environment that may not be trustworthy –

raises crucial issues regarding the security, privacy, and reliability of data …";Autres articles;;[PDF] lumsa.it;https://repec.lumsa.it/wp/wpC36.pdf;;"""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.3""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""22""
""resourceName"",""wpC36.pdf""
""language"",""en""
""pdf:hasXMP"",""false""
""dc:format"",""application/pdf; version=1.3""
""pdf:charsPerPage"",""695"",""3044"",""3365"",""4328"",""4058"",""4593"",""4152"",""4172"",""3627"",""4192"",""3952"",""3720"",""3965"",""1846"",""2710"",""2851"",""2968"",""2902"",""2785"",""2716"",""2596"",""527""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""producer"",""PyPDF2""
""Content-Length"",""437512""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""PyPDF2""
""pdf:hasMarkedContent"",""false""
""Content-Type"",""application/pdf""
";https://scholar.google.com/scholar?start=620&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094576-806;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;DAPS: A Decentralized Anonymous Payment Scheme with Supervision;Z Wang, Q Pei, X Liui, L Ma, H Li, S Yu ; International Conference on …, 2019  Springer;;"… If query type is CreateAddress, then the same address is generated at both oracles … More

specifically, A adaptively interacts with a DAPS scheme oracle \( O^{DAPS} \) and then outputs

a … IEEE (2016)Google Scholar. 3. Lazarovich, A.: Invisible Ink: blockchain for data privacy …";Autres articles;;null;;;;https://scholar.google.com/scholar?start=620&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094607-937;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Secure Sharing Model Based on Block Chain in Medical Cloud (Short Paper);T Feng, Y Jiao, J Fang ; International Conference on Collaborative …, 2019  Springer;;"… It not only can reduce the access overhead of the blockchain but also better resist the collusion

attack. Furthermore, our security analysis indicates that the proposed scheme achieves provable

security under the q-DBDHE assumption in the random oracle model …";Autres articles;;null;;;;https://scholar.google.com/scholar?start=750&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094567-762;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;DABKE: Secure deniable attribute-based key exchange framework;Y Tian, Y Li, G Yang, W Susilo, Y Mu… ; Journal of Computer …, 2019  content.iospress.com;;"… States. We define a system user set U with n users, ie | U | = n . We say an instance oracle ? U

i (eg, session i of user U) may be used or unused, and a user U has unlimited number of instances

called oracles. The oracle is considered as unused if it has never been initialized …";Autres articles;Y Mu;[PDF] smu.edu.sg;https://ink.library.smu.edu.sg/cgi/viewcontent.cgi?article=5353&context=sis_research;;"""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""Content-Encoding"",""windows-1252""
""resourceName"",""viewcontent.cgi""
""language"",""""
""robots"",""noindex,nofollow""
""Content-Length"",""212""
""Content-Type"",""text/html; charset=windows-1252""
";https://scholar.google.com/scholar?start=580&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094597-898;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[PDF][PDF] Lohkoketjuteknologia yritysten liiketoiminnassa;M Sorjonen ;2019 theseus.fi;;"… Also, it does not compare technology providers nor has statement of the service providers at the

market. Block- chain solutions around cryptocurrency are not the main target for the the- sis …

Lohkoketju (Blockchain) Hajautettu, jaettu ja läpinäkyvä tietokanta … (Oracle, 2018) …";Autres articles;Version HTML;[PDF] theseus.fi;https://www.theseus.fi/bitstream/handle/10024/263392/Opinn%C3%A4ytety%C3%B6_ManuSorjonen.pdf?sequence=2;;"""date"",""2019-11-25T12:39:56Z""
""pdf:PDFVersion"",""1.7""
""xmp:CreatorTool"",""MicrosoftÂŽ Word for Office 365""
""pdf:docinfo:title"",""ManuSorjonen_OpinnäytetyÜ""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""opinnäytetyÜ, opinnäytetyÜmallipohja, mallipohja, raporttipohja"",""opinnäytetyÜ, opinnäytetyÜmallipohja, mallipohja, raporttipohja""
""language"",""fi""
""dc:format"",""application/pdf; version=1.7""
""pdf:docinfo:creator_tool"",""MicrosoftÂŽ Word for Office 365""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""ManuSorjonen_OpinnäytetyÜ""
""xmp:CreateDate"",""2019-11-25T14:39:56Z""
""modified"",""2019-11-25T12:39:56Z""
""pdf:hasMarkedContent"",""true""
""xmp:ModifyDate"",""2019-11-25T14:39:56Z""
""pdf:docinfo:creator"",""manu sorjonen""
""meta:author"",""manu sorjonen""
""meta:creation-date"",""2019-11-25T12:39:56Z""
""created"",""2019-11-25T12:39:56Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-11-25T12:39:56Z""
""resourceName"",""Opinn%C3%A4ytety%C3%B6_ManuSorjonen.pdf""
""Author"",""manu sorjonen""
""producer"",""MicrosoftÂŽ Word for Office 365""
""pdf:docinfo:producer"",""MicrosoftÂŽ Word for Office 365""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""Keywords"",""opinnäytetyÜ, opinnäytetyÜmallipohja, mallipohja, raporttipohja"",""opinnäytetyÜ, opinnäytetyÜmallipohja, mallipohja, raporttipohja""
""access_permission:modify_annotations"",""true""
""dc:creator"",""manu sorjonen""
""dcterms:created"",""2019-11-25T12:39:56Z""
""Last-Modified"",""2019-11-25T12:39:56Z""
""dcterms:modified"",""2019-11-25T12:39:56Z""
""title"",""ManuSorjonen_OpinnäytetyÜ""
""xmpMM:DocumentID"",""uuid:DD9375D3-4550-438D-95E6-71401CCCBCB4""
""Last-Save-Date"",""2019-11-25T12:39:56Z""
""pdf:docinfo:keywords"",""opinnäytetyÜ, opinnäytetyÜmallipohja, mallipohja, raporttipohja""
""pdf:docinfo:modified"",""2019-11-25T12:39:56Z""
""meta:save-date"",""2019-11-25T12:39:56Z""
""Content-Length"",""920587""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""manu sorjonen""
""dc:language"",""fi-FI""
""pdf:producer"",""MicrosoftÂŽ Word for Office 365""
""dc:subject"",""opinnäytetyÜ, opinnäytetyÜmallipohja, mallipohja, raporttipohja"",""opinnäytetyÜ, opinnäytetyÜmallipohja, mallipohja, raporttipohja""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""40""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""230"",""1780"",""1790"",""1425"",""115"",""4199"",""1993"",""2714"",""1607"",""1826"",""1596"",""2016"",""1571"",""1710"",""1733"",""1451"",""2614"",""2973"",""1805"",""1552"",""1393"",""1666"",""2882"",""1202"",""1810"",""1994"",""2956"",""2905"",""2755"",""1607"",""2756"",""1407"",""2544"",""2850"",""750"",""2953"",""2122"",""2232"",""1968"",""1238""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""meta:keyword"",""opinnäytetyÜ, opinnäytetyÜmallipohja, mallipohja, raporttipohja"",""opinnäytetyÜ, opinnäytetyÜmallipohja, mallipohja, raporttipohja""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-11-25T12:39:56Z""
";https://scholar.google.com/scholar?start=710&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094605-927;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Smart Contract-Driven Business Transactions;BJ Butijn, WJ van den Heuvel… ; Essentials of Blockchain …, 2019  books.google.com;;"… An account includes an address and private key/address pairs, and can store crypto- currencies …

Two current examples of oracles are Town Crier [27] and Oraclize [28] … Hawk: The blockchain

model of cryptography and privacy-preserving smart contracts …";Autres articles;;null;;;;https://scholar.google.com/scholar?start=740&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094616-977;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[PDF][PDF] An efficient certificateless signcryption scheme without random oracles;S Shan ; International Journal of Electronics and Information …, 2019  ijeie.jalaxy.com.tw;;"… Given g, g, gs, gx, gy, gx, gy and unlimited access to both oracles O2 and … [4] R. Canetti, O.

Goldreich, and S. Halevi,“The random oracle methodology,” Journal … A. Shamir,“Identity-based

cryptosystem and signature scheme,” in Proceedings of Cryptology- CRYPTO 1984, Lecture …";Cité 6 fois;Les 3 versions;[PDF] jalaxy.com.tw;http://ijeie.jalaxy.com.tw/contents/ijeie-v11-n1/ijeie-v11-n1.pdf#page=12;;"""date"",""2019-08-23T08:07:09Z""
""pdf:PDFVersion"",""1.6""
""xmp:CreatorTool"",""Adobe Acrobat Pro DC 19.12.20040""
""pdf:docinfo:title"",""""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""language"",""en""
""dc:format"",""application/pdf; version=1.6""
""pdf:docinfo:creator_tool"",""Adobe Acrobat Pro DC 19.12.20040""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""xmp:CreateDate"",""2019-08-23T16:07:09Z""
""modified"",""2019-08-23T08:07:09Z""
""pdf:hasMarkedContent"",""true""
""xmp:ModifyDate"",""2019-08-23T16:07:09Z""
""pdf:docinfo:creator"",""user66""
""meta:author"",""user66""
""meta:creation-date"",""2019-08-23T08:07:09Z""
""created"",""2019-08-23T08:07:09Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-08-23T08:07:09Z""
""resourceName"",""ijeie-v11-n1.pdf""
""Author"",""user66""
""producer"",""Adobe Acrobat Pro DC 19.12.20040""
""pdf:docinfo:producer"",""Adobe Acrobat Pro DC 19.12.20040""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""1"",""3"",""28"",""0"",""0"",""0"",""5"",""0"",""4"",""3"",""0"",""1"",""0"",""0"",""5"",""1"",""6"",""2"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""access_permission:modify_annotations"",""true""
""dc:creator"",""user66""
""dcterms:created"",""2019-08-23T08:07:09Z""
""Last-Modified"",""2019-08-23T08:07:09Z""
""dcterms:modified"",""2019-08-23T08:07:09Z""
""title"",""""
""xmpMM:DocumentID"",""uuid:62672d2d-b39f-4c11-a6dc-2eb6d656cb26""
""Last-Save-Date"",""2019-08-23T08:07:09Z""
""pdf:docinfo:modified"",""2019-08-23T08:07:09Z""
""meta:save-date"",""2019-08-23T08:07:09Z""
""Content-Length"",""2712867""
""Content-Type"",""application/pdf""
""xmp:MetadataDate"",""2019-08-23T16:07:09Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""user66""
""pdf:producer"",""Adobe Acrobat Pro DC 19.12.20040""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""51""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""54"",""3446"",""691"",""2272"",""2286"",""2379"",""1939"",""1408"",""2445"",""2750"",""1027"",""2549"",""2241"",""2185"",""1354"",""1563"",""2399"",""1587"",""2334"",""4047"",""2341"",""1826"",""1700"",""1057"",""1529"",""3261"",""1692"",""2341"",""2912"",""2109"",""3568"",""1950"",""3223"",""2063"",""1956"",""3308"",""1543"",""3675"",""1706"",""245"",""2877"",""1719"",""2557"",""2046"",""3437"",""3297"",""3362"",""3139"",""3086"",""288"",""3336""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-08-23T08:07:09Z""
";https://scholar.google.com/scholar?start=790&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094663-1171;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Diseńo de un modelo basado en contratos inteligentes aplicado al matrimonio contraído por una pareja según la legislación colombiana;W Pinilla Ramos, JM Ortíz Ruíz ; repository.udistrital.edu.co;;"… 25 4.2.2. Acuerdos Prenupciales . . . . . 26 2 Page 3. ÍNDICE GENERAL 3 4.3. Blockchain

Propuesta . . . . . 26 4.3.1. Selección de Blockchain . . . . . 26 4.3.2. Smart Contracts …";Autres articles;Version HTML;[PDF] udistrital.edu.co;http://repository.udistrital.edu.co/bitstream/11349/15807/1/Ort%C3%ADzRu%C3%ADzJeimyMarcela2019.pdf;;;https://scholar.google.com/scholar?start=990&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094534-623;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Application of blockchain technologies to logistics and to container's transportation industry;L Morra ;2019 tesi.luiss.it;;"Department of Business and Management Master Thesis in International Economics

and Industrial Dynamics Application of blockchain technologies to logistics and to

container's transportation … 34 Chapter 2: Blockchain technologies ..... 37 …";Autres articles;;[PDF] luiss.it;http://tesi.luiss.it/24134/1/688641_MORRA_LUIGI.pdf;;"""date"",""2019-01-29T15:28:27Z""
""pdf:PDFVersion"",""1.5""
""xmp:CreatorTool"",""PScript5.dll Version 5.2.2""
""pdf:docinfo:title"",""Microsoft Word - TESI""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""PScript5.dll Version 5.2.2""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""Microsoft Word - TESI""
""xmp:CreateDate"",""2019-01-29T16:28:27Z""
""modified"",""2019-01-29T15:28:27Z""
""pdf:hasMarkedContent"",""false""
""xmp:ModifyDate"",""2019-01-29T16:28:27Z""
""pdf:docinfo:creator"",""sony""
""meta:author"",""sony""
""meta:creation-date"",""2019-01-29T15:28:27Z""
""created"",""2019-01-29T15:28:27Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-01-29T15:28:27Z""
""resourceName"",""688641_MORRA_LUIGI.pdf""
""Author"",""sony""
""producer"",""Acrobat Distiller 10.0.0 (Windows)""
""pdf:docinfo:producer"",""Acrobat Distiller 10.0.0 (Windows)""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""access_permission:modify_annotations"",""true""
""dc:creator"",""sony""
""dcterms:created"",""2019-01-29T15:28:27Z""
""Last-Modified"",""2019-01-29T15:28:27Z""
""dcterms:modified"",""2019-01-29T15:28:27Z""
""title"",""Microsoft Word - TESI""
""xmpMM:DocumentID"",""uuid:838caea4-0c14-4ef5-9aa9-d792588e1f87""
""Last-Save-Date"",""2019-01-29T15:28:27Z""
""pdf:docinfo:modified"",""2019-01-29T15:28:27Z""
""meta:save-date"",""2019-01-29T15:28:27Z""
""Content-Length"",""810474""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""sony""
""pdf:producer"",""Acrobat Distiller 10.0.0 (Windows)""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""101""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""433"",""3076"",""795"",""2253"",""1111"",""1939"",""2200"",""1426"",""1600"",""1883"",""2428"",""1068"",""1871"",""1795"",""908"",""1463"",""2309"",""1350"",""313"",""2470"",""2381"",""2482"",""2357"",""2385"",""2272"",""2426"",""2347"",""1492"",""844"",""2325"",""2232"",""2332"",""1971"",""1598"",""2427"",""1421"",""2135"",""2415"",""2226"",""1432"",""1337"",""2188"",""2318"",""1684"",""2448"",""687"",""2518"",""2242"",""1953"",""1831"",""1607"",""2197"",""2102"",""2211"",""1626"",""215"",""2111"",""1734"",""2378"",""1827"",""1439"",""2325"",""2570"",""2297"",""2012"",""2155"",""1453"",""2371"",""2202"",""2087"",""2115"",""2126"",""2277"",""2088"",""1956"",""1583"",""1826"",""2122"",""2463"",""2225"",""1333"",""2288"",""2086"",""2206"",""2213"",""2061"",""2352"",""2265"",""1635"",""2175"",""2343"",""702"",""2147"",""2403"",""2373"",""1463"",""2107"",""2155"",""1313"",""1141"",""734""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-01-29T15:28:27Z""
";https://scholar.google.com/scholar?start=440&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094572-785;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;(Tightly) QCCA-Secure Key-Encapsulation Mechanism in the Quantum Random Oracle Model;K Xagawa, T Yamakawa ; International Conference on PostQuantum …, 2019  Springer;;"… and Open image in new window be two independent random oracles. If an unbounded time

quantum adversary Open image in new window makes a query to \(\mathsf {H}\) at most

\(q_{\mathsf {H}}\) times, then we have Open image in new window. where all oracle accesses …";Cité 6 fois;;null;;;;https://scholar.google.com/scholar?start=600&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094593-880;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Identity-based encryption with security against the KGC: a formal model and its instantiation from lattices;K Emura, S Katsumata, Y Watanabe ; European symposium on research in …, 2019  Springer;;"… In addition, \(\mathcal {A}\) is allowed to access two oracles, namely, the key-generation and

encryption oracles. First, \(\mathcal {A}\) obtains the secret key \(\mathsf{sk}_{\mathsf{ID}}\) for

a randomly chosen identity \(\mathsf{ID}\) from the key-generation oracle …";Cité 6 fois;;null;;;;https://scholar.google.com/scholar?start=690&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094651-1127;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Unifying blockchian and IoT: Security requirements, challenges, applications and future trends;T Sharma, S Satija, B Bhushan ; … International Conference on …, 2019  ieeexplore.ieee.org;;"… With this down fall of cryptocurrency many companies and countries showed importance to

blockchain technology as they had high expectations from it. Better known companies like Google,

Facebook, Oracle and Alibaba not just scratched the surface of the Blockchain …";Cité 20 fois;;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/8966553/8974457/08974552.pdf?casa_token=K81vly9Jb9EAAAAA:sFj5RIKRZlNO7LEkbTGJ_z7HT3AegmRYfr6gJv1zYwO303cAV4aW-YdXChZKeI8nY3mO2yO-Ja0;;"""og:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""twitter:title"",""Unifying Blockchian and IoT:Security Requirements, Challenges, Applications and Future Trends""
""twitter:card"",""summary""
""Description"",""Blockchain is a decentralized and distributed public ledgers which holds sensitive and invariant data in an encrypted and secured manner to ensure no mid-way al""
""og:title"",""Unifying Blockchian and IoT:Security Requirements, Challenges, Applications and Future Trends""
""resourceName"",""08974552.pdf""
""language"",""en""
""title"",""Unifying Blockchian and IoT:Security Requirements, Challenges, Applications and Future Trends | IEEE Conference Publication | IEEE Xplore""
""og:description"",""Blockchain is a decentralized and distributed public ledgers which holds sensitive and invariant data in an encrypted and secured manner to ensure no mid-way alterations are possible in a transaction, proving user a secure and trustable facility. While cryptocurrency like Bitcoin are major and most popular faces, Blockchain technology has gained a huge momentum recently. Objective of this paper is to layout a detailed survey on blockchain technology, to explain some important terminologies related to Blockchain, to compare IoT and traditional network on the basis of security, compatibility and capacity and to provide an insight on blockchain based IoT and Industrial IoT. Later, the challenges faced while adopting blockchain in IoT and it's future scopes are discussed.""
""twitter:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-UA-Compatible"",""IE=Edge""
""viewport"",""width=device-width, initial-scale=1.0""
""dc:title"",""Unifying Blockchian and IoT:Security Requirements, Challenges, Applications and Future Trends | IEEE Conference Publication | IEEE Xplore""
""twitter:description"",""Blockchain is a decentralized and distributed public ledgers which holds sensitive and invariant data in an encrypted and secured manner to ensure no mid-way alterations are possible in a transaction, proving user a secure and trustable facility. While cryptocurrency like Bitcoin are major and most popular faces, Blockchain technology has gained a huge momentum recently. Objective of this paper is to layout a detailed survey on blockchain technology, to explain some important terminologies related to Blockchain, to compare IoT and traditional network on the basis of security, compatibility and capacity and to provide an insight on blockchain based IoT and Industrial IoT. Later, the challenges faced while adopting blockchain in IoT and it's future scopes are discussed.""
""Content-Encoding"",""UTF-8""
""Content-Type-Hint"",""text/html; charset=utf-8""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=940&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094555-719;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Blockchain and the Chief Strategy Officer: How Distributed Ledger Technology Will Change Strategy Design and Delivery;KD Sandberg, RV Vargas, EC Conforto… ; … Oumarou,'Blockchain …, 2019  papers.ssrn.com;;"… Miners refer to those devices running the full blockchain software stack and competing to solve

a difficult mathematical problem and create the next block, in exchange for a cryptocurrency

reward. The term also refers to the parties that own those devices …";Autres articles;;[PDF] researchgate.net;https://www.researchgate.net/profile/Kirsten_Sandberg/publication/335201055_BLOCKCHAIN_AND_THE_CHIEF_STRATEGY_OFFICER_How_Distributed_Ledger_Technology_Will_Change_Strategy_Design_and_Delivery/links/5f45ac0ea6fdcccc43051dce/BLOCKCHAIN-AND-THE-CHIEF-STRATEGY-OFFICER-How-Distributed-Ledger-Technology-Will-Change-Strategy-Design-and-Delivery.pdf;;;https://scholar.google.com/scholar?start=530&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094586-848;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;The GNU Taler system: practical and provably secure electronic payments;F Dold ;2019 tel.archivesouvertes.fr;;"… Pendant que les crypto-monnaies basées sur la preuve de travail ŕ l'instar de Bitcoin doivent

encore ętre mises ŕ l'échelle pour servir de substituant aux systčmes de paiement établis, d'autres

systčmes plus efficaces basés sur … 48 3.2.2. Oracles … 92 4.2.4. Blockchain Integration …";Cité 4 fois;Les 10 versions;[PDF] archives-ouvertes.fr;https://tel.archives-ouvertes.fr/tel-02138082/document;;"""date"",""2019-05-23T12:35:56Z""
""pdf:PDFVersion"",""1.4""
""xmp:CreatorTool"",""LaTeX with hyperref""
""pdf:docinfo:title"",""The GNU Taler system: practical and provably secure electronic payments""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""Computer Science [cs]/Cryptography and Security [cs.CR]""
""language"",""en""
""dc:format"",""application/pdf; version=1.4""
""pdf:docinfo:creator_tool"",""HAL""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""The GNU Taler system: practical and provably secure electronic payments""
""xmp:CreateDate"",""2019-05-15T11:21:51Z""
""modified"",""2019-05-23T12:35:56Z""
""cp:subject"",""Computer Science [cs]/Cryptography and Security [cs.CR]""
""pdf:docinfo:subject"",""Computer Science [cs]/Cryptography and Security [cs.CR]""
""pdf:hasMarkedContent"",""false""
""xmp:ModifyDate"",""2019-05-23T14:35:56Z""
""pdf:docinfo:creator"",""Florian Dold""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.19 (TeX Live 2018/Arch Linux) kpathsea version 6.3.0""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2021-04-15T03:41:44Z""
""created"",""2021-04-15T03:41:44Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2021-04-15T03:41:44Z""
""resourceName"",""document""
""Author"",""""
""producer"",""PDFLaTeX""
""pdf:docinfo:producer"",""PDFLaTeX""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""2"",""0"",""0"",""41"",""3"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""1"",""3"",""0"",""2"",""8"",""2"",""1"",""1"",""4"",""2"",""0"",""8"",""5"",""1"",""2"",""2"",""11"",""5"",""10"",""2"",""4"",""4"",""28"",""1"",""5"",""3"",""2"",""10"",""9"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""3"",""0"",""5"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""4"",""12"",""18"",""8"",""8"",""26"",""8"",""6"",""14"",""26"",""10"",""5"",""18"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""2"",""0"",""2"",""8"",""0"",""0"",""3"",""0"",""0"",""0"",""6"",""16"",""6"",""1"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""4"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""Keywords"",""Electronic Cash, Cryptography, Distributed SystemsMonnaie Êlectronique, Cryptographie, Systèmes distribuÊs""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2021-04-15T03:41:44Z""
""Last-Modified"",""2019-05-23T12:35:56Z""
""dcterms:modified"",""2019-05-23T12:35:56Z""
""title"",""The GNU Taler system: practical and provably secure electronic payments""
""xmpMM:DocumentID"",""uuid:0157fa0c-94cd-429a-aa04-a4cc11ec6032""
""Last-Save-Date"",""2019-05-23T12:35:56Z""
""pdf:docinfo:keywords"",""Electronic Cash, Cryptography, Distributed SystemsMonnaie Êlectronique, Cryptographie, Systèmes distribuÊs""
""pdf:docinfo:modified"",""2019-05-23T12:35:56Z""
""meta:save-date"",""2019-05-23T12:35:56Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.19 (TeX Live 2018/Arch Linux) kpathsea version 6.3.0""
""Content-Length"",""2693993""
""Content-Type"",""application/pdf""
""xmp:MetadataDate"",""2019-05-23T14:35:56Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""pdf:producer"",""pdfTeX-1.40.19""
""dc:subject"",""Electronic Cash, Cryptography, Distributed SystemsMonnaie Êlectronique, Cryptographie, Systèmes distribuÊs""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""211""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""808"",""1009"",""2935"",""2975"",""0"",""1587"",""0"",""1700"",""2028"",""2076"",""1213"",""1976"",""663"",""1999"",""2339"",""2128"",""2004"",""2492"",""2118"",""2173"",""921"",""163"",""121"",""145"",""1617"",""2383"",""2453"",""2016"",""799"",""1494"",""1558"",""2578"",""2629"",""2544"",""2461"",""2307"",""2126"",""2122"",""2551"",""2747"",""2019"",""2382"",""2475"",""2327"",""1963"",""2395"",""2295"",""2276"",""2296"",""2186"",""2347"",""1613"",""0"",""1790"",""2365"",""2473"",""1691"",""2224"",""1987"",""2459"",""2441"",""1974"",""1993"",""2455"",""1816"",""2054"",""1928"",""1579"",""1718"",""2012"",""1931"",""1923"",""1773"",""1471"",""1491"",""1417"",""1694"",""2149"",""2210"",""1763"",""2289"",""1161"",""2193"",""284"",""0"",""1841"",""2438"",""1428"",""2232"",""1301"",""2543"",""1570"",""2265"",""327"",""2789"",""2396"",""2106"",""2443"",""2253"",""2342"",""1668"",""2043"",""1806"",""1956"",""1950"",""1385"",""1281"",""2137"",""1257"",""2155"",""1404"",""1079"",""2113"",""2312"",""2032"",""2178"",""1643"",""860"",""2306"",""1366"",""853"",""559"",""341"",""774"",""694"",""457"",""984"",""914"",""1662"",""2064"",""2280"",""994"",""2569"",""1501"",""969"",""910"",""2393"",""2200"",""2292"",""2340"",""2341"",""1782"",""2252"",""2487"",""2439"",""2146"",""2246"",""2783"",""2324"",""1812"",""1968"",""1918"",""2093"",""2069"",""1439"",""437"",""1520"",""620"",""1587"",""446"",""581"",""1238"",""2230"",""2628"",""1167"",""2632"",""1951"",""1644"",""1414"",""1794"",""1539"",""1967"",""0"",""1807"",""2155"",""2039"",""2076"",""2087"",""2034"",""1967"",""2047"",""2123"",""1849"",""2039"",""2026"",""2144"",""1858"",""1993"",""2080"",""2083"",""2063"",""2345"",""2347"",""2101"",""2106"",""1049"",""0"",""1080"",""1497"",""1640"",""1536"",""1288"",""1519"",""1080"",""791"",""1385"",""415"",""1206"",""655"",""649"",""643""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""Electronic Cash, Cryptography, Distributed SystemsMonnaie Êlectronique, Cryptographie, Systèmes distribuÊs""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2021-04-15T03:41:44Z""
";https://scholar.google.com/scholar?start=660&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094551-695;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Potenzielle Auswirkungen der Blockchain-Technologie auf die Wertschöpfungskette der Finanzberichterstattung;P Leibfried, H Petry ; Controlling & Innovation 2019, 2019  Springer;;"… Durch die Verbindung mit weiteren Technologien wie Smart Contracts, die automatisiert in der

Blockchain festgeschriebene Vertragskonsequenzen ausführen können, und Oracles, welche

als Informationsquelle über die Erfüllung entsprechender Vertragsbedingungen dienen …";Autres articles;;null;;;;https://scholar.google.com/scholar?start=510&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094600-909;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Dsse: distributed security shielded execution for communicable cyber threats analysis;S Singh, A Lamba, S Rela ; International Journal of Current …, 2019  papers.ssrn.com;;"… Secure identity based encryption without random oracles. In Annual International Cryptology

Conference (pp. 443-459) … The random oracle model, revisted … Distributed blockchain-based data

protection framework for modern power systems against cyber-attacks …";Cité 6 fois;Les 2 versions;null;;;;https://scholar.google.com/scholar?start=720&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094567-764;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[CITATION][C] Decentralized Voting System;A Balamurli, A Mishra, A Sharma, SR Campus ; International Journal of Engineering …, 2019;;null;Autres articles;;null;;;;https://scholar.google.com/scholar?start=580&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094546-672;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[PDF][PDF] Money Supply for a Utility Cryptocurrency;A Díaz, GF de;Córdobab, LA Puchc 2019 cryptoeconomics.genexies.net;;"… sense. The state of the ledger is maintained by the blockchain and the process of price-setting

may … Tm Exchange B uys crypto Pa ys fi a t … q0 = 100 coin/€ Sideblock Foundation * ICO (fixes M0) *

Writes Dapps * Writes smart contracts * Sets oracles * Endorses this Yellow Paper …";Autres articles;Version HTML;[PDF] genexies.net;http://cryptoeconomics.genexies.net/ICOresearch.pdf;;"""date"",""2019-03-03T09:44:01Z""
""pdf:unmappedUnicodeCharsPerPage"",""1806"",""2421"",""2650"",""2363"",""1151"",""1987"",""2355"",""1158"",""2253"",""1077"",""1658"",""1840"",""1145"",""1148"",""903"",""1980"",""495"",""1008"",""686"",""743"",""1480"",""1809"",""1025"",""116"",""52"",""54"",""2085"",""2108"",""1519"",""1099""
""pdf:PDFVersion"",""1.5""
""xmp:CreatorTool"",""TeX""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dcterms:created"",""2019-03-03T09:44:01Z""
""language"",""en""
""Last-Modified"",""2019-03-03T09:44:01Z""
""dcterms:modified"",""2019-03-03T09:44:01Z""
""dc:format"",""application/pdf; version=1.5""
""Last-Save-Date"",""2019-03-03T09:44:01Z""
""pdf:docinfo:creator_tool"",""TeX""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2019-03-03T09:44:01Z""
""meta:save-date"",""2019-03-03T09:44:01Z""
""pdf:encrypted"",""false""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017/Debian) kpathsea version 6.2.3""
""modified"",""2019-03-03T09:44:01Z""
""Content-Length"",""534293""
""pdf:hasMarkedContent"",""false""
""Content-Type"",""application/pdf""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017/Debian) kpathsea version 6.2.3""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""trapped"",""False""
""meta:creation-date"",""2019-03-03T09:44:01Z""
""created"",""2019-03-03T09:44:01Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""30""
""Creation-Date"",""2019-03-03T09:44:01Z""
""resourceName"",""ICOresearch.pdf""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""1816"",""2421"",""2650"",""2363"",""1360"",""2018"",""2355"",""1392"",""2266"",""1111"",""1674"",""1972"",""1304"",""1374"",""1075"",""2039"",""495"",""1295"",""861"",""967"",""1554"",""1908"",""1025"",""118"",""52"",""63"",""2111"",""2110"",""1519"",""1099""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""producer"",""pdfTeX-1.40.18""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""pdfTeX-1.40.18""
""pdf:docinfo:created"",""2019-03-03T09:44:01Z""
";https://scholar.google.com/scholar?start=490&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094546-680;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Validade e eficácia dos “testamentos inteligentes” via tecnologia Blockchain;LSM Rocha, FF Gomes, TCM Mafra ; Scientia Iuris  uel.br;;"… Validade E Eficácia Dos “Testamentos Inteligentes” Via Tecnologia Blockchain Validity And

Effectiveness Of “Smart Wills” Through Blockchain Technology Lucas Salles Moreira Rocha*

Frederico Felix Gomes** Tereza Cristina Monteiro Mafra … Palavras-chave: Blockchain …";Autres articles;;[PDF] uel.br;http://www.uel.br/revistas/uel/index.php/iuris/article/viewFile/33991/25173;;"""date"",""2019-03-28T05:29:10Z""
""pdf:PDFVersion"",""1.7""
""xmp:CreatorTool"",""Adobe InDesign CC 13.1 (Windows)""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""language"",""pt""
""dc:format"",""application/pdf; version=1.7"",""application/pdf; version=""""1.7 Adobe Extension Level 3""""""
""pdf:docinfo:creator_tool"",""Adobe InDesign CC 13.1 (Windows)""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""xmp:CreateDate"",""2019-03-28T02:29:08Z""
""modified"",""2019-03-28T05:29:10Z""
""pdf:hasMarkedContent"",""false""
""xmp:ModifyDate"",""2019-03-28T02:29:10Z""
""trapped"",""False""
""meta:creation-date"",""2019-03-28T05:29:08Z""
""created"",""2019-03-28T05:29:08Z""
""pdf:PDFExtensionVersion"",""1.7 Adobe Extension Level 3""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-03-28T05:29:08Z""
""resourceName"",""25173""
""xmpMM:DerivedFrom:DocumentID"",""xmp.did:750183fc-0f6e-f748-a305-5ec25c66818d""
""producer"",""Adobe PDF Library 15.0""
""pdf:docinfo:producer"",""Adobe PDF Library 15.0""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""access_permission:modify_annotations"",""true""
""dcterms:created"",""2019-03-28T05:29:08Z""
""Last-Modified"",""2019-03-28T05:29:10Z""
""dcterms:modified"",""2019-03-28T05:29:10Z""
""xmpMM:DocumentID"",""xmp.id:592994d1-d56e-2643-bfc1-32387e6ba3ee""
""Last-Save-Date"",""2019-03-28T05:29:10Z""
""pdf:docinfo:modified"",""2019-03-28T05:29:10Z""
""meta:save-date"",""2019-03-28T05:29:10Z""
""Content-Length"",""366232""
""Content-Type"",""application/pdf""
""xmp:MetadataDate"",""2019-03-28T02:29:10Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""dc:language"",""pt-BR""
""pdf:producer"",""Adobe PDF Library 15.0""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""18""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""2976"",""774"",""3119"",""3432"",""3472"",""3434"",""3586"",""3433"",""3436"",""3376"",""3179"",""3383"",""3612"",""3232"",""3097"",""2929"",""3029"",""759""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""xmpMM:DerivedFrom:InstanceID"",""xmp.iid:7a1f2427-f72a-8a4d-b955-104abfb898b2""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-03-28T05:29:08Z""
";https://scholar.google.com/scholar?start=490&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094560-735;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Using smart contracts to attract conservation investment;C Chesney ;2019 ora.ox.ac.uk;;"… 12 Figure 4.1: Overview of Oracle Services …………… 26 Figure 5.1: Herd Tokenisation

process using smart contracts …………… 38 Figure 5.2: Example smart contract for …

Each cryptocurrency operates on its own blockchain and can …";Autres articles;Version HTML;[PDF] ox.ac.uk;https://ora.ox.ac.uk/objects/uuid:00e721ba-9117-4887-843d-5bcbebfbbe44/download_file?file_format=pdf&safe_filename=1019150_BCM_MSc_Dissertation_dissemination.pdf&type_of_work=Thesis;;"""date"",""2019-05-16T16:06:43Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.6""
""xmp:CreatorTool"",""MicrosoftÂŽ Word 2016""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""language"",""en""
""dcterms:created"",""2018-09-03T10:08:37Z""
""Last-Modified"",""2019-05-16T16:06:43Z""
""dcterms:modified"",""2019-05-16T16:06:43Z""
""dc:format"",""application/pdf; version=1.6""
""xmpMM:DocumentID"",""uuid:fee98f48-032c-4c65-90c3-c4d4be974486""
""Last-Save-Date"",""2019-05-16T16:06:43Z""
""pdf:docinfo:creator_tool"",""MicrosoftÂŽ Word 2016""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2019-05-16T16:06:43Z""
""meta:save-date"",""2019-05-16T16:06:43Z""
""pdf:encrypted"",""false""
""xmp:CreateDate"",""2018-09-03T10:08:37Z""
""modified"",""2019-05-16T16:06:43Z""
""pdf:hasMarkedContent"",""true""
""Content-Type"",""application/pdf""
""xmp:ModifyDate"",""2019-05-16T17:06:43Z""
""xmp:MetadataDate"",""2019-05-16T17:06:43Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""dc:language"",""en-US""
""pdf:producer"",""www.ilovepdf.com""
""meta:creation-date"",""2018-09-03T10:08:37Z""
""created"",""2018-09-03T10:08:37Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""125""
""Creation-Date"",""2018-09-03T10:08:37Z""
""resourceName"",""download_file""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""95"",""1285"",""965"",""1999"",""6234"",""2522"",""2396"",""2511"",""2666"",""2414"",""2408"",""2183"",""1328"",""814"",""2329"",""2334"",""2560"",""2252"",""2284"",""2402"",""1389"",""2381"",""2767"",""2108"",""1709"",""2758"",""2851"",""1173"",""2666"",""1751"",""1335"",""2387"",""2238"",""1487"",""1806"",""1950"",""1054"",""2205"",""2180"",""1468"",""1044"",""1028"",""1430"",""1272"",""1158"",""1546"",""1270"",""918"",""338"",""2483"",""2862"",""2895"",""2863"",""2913"",""2575"",""2946"",""2852"",""2580"",""1038"",""788"",""2173"",""2344"",""2173"",""2411"",""2174"",""2297"",""2137"",""2008"",""176"",""247"",""1251"",""978"",""1648"",""1580"",""1460"",""1480"",""1502"",""1323"",""1334"",""893"",""1296"",""1337"",""1344"",""211"",""1325"",""1512"",""1263"",""1264"",""1193"",""1390"",""1161"",""1115"",""923"",""735"",""424"",""550"",""608"",""788"",""826"",""822"",""606"",""224"",""1749"",""286"",""2203"",""1312"",""2625"",""1054"",""992"",""2103"",""1708"",""2114"",""1088"",""2181"",""2490"",""2654"",""2084"",""1956"",""1907"",""2078"",""354"",""2524"",""1681"",""2323"",""221""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""producer"",""www.ilovepdf.com""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""www.ilovepdf.com""
""pdf:docinfo:created"",""2018-09-03T10:08:37Z""
";https://scholar.google.com/scholar?start=550&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094628-1026;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[HTML][HTML] Public-key encryption with integrated keyword search;V Saraswat, RA Sahu, G Sharma, V Kuchta… ; Journal of Hardware and …, 2019  Springer;Switzerland;"… More precisely, their scheme can be viewed as a transformation of the Boneh-Franklin IBE [10]

into a PEKS. They have proved their scheme to be IND-CPA secure on random oracle model

based on bilinear Diffie-Hellman (BDH) assumption. In 2005, Abdalla et al …";Cité 2 fois;Les 6 versions;[HTML] springer.com;https://idp.springer.com/authorize/casa?redirect_uri=https://link.springer.com/article/10.1007/s41635-019-00066-w&casa_token=0NyAbzDv3TsAAAAA:2_NrWh7h7dtgJa5gn1sP9Ez9QJbL8FswZqbRHoHu07uloWcEtviICJ8ktR3fIOwv3NT8WpHqpP6ufDk;;"""dc.publisher"",""Springer""
""og:image"",""https://media.springernature.com/w200/springer-static/cover/journal/41635.jpg""
""twitter:card"",""summary""
""og:site_name"",""Journal of Hardware and Systems Security""
""citation_reference"",""Abdalla M, Bellare M, Catalano D, Kiltz E, Kohno T, Lange T, Malone-Lee J, Neven G, Paillier P, Shi H (2005) Searchable encryption revisited: consistency properties, relation to anonymous IBE, and extensions. In: CRYPTO, Volume 3621 of LNCS, pp 205–222"",""Abdalla Mi, Bellare M, Neven G (2010) Robust encryption. In: TCC, Volume 5978 of LNCS, pp 480–497"",""Baek J, Safavi-Naini R, Susilo W (2006) On the integration of public key data encryption and public key encryption with keyword search. In: Information Security, Volume 4176 of LNCS, pp 217–232"",""Baek J, Safavi-Naini R, Susilo W (2008) Public key encryption with keyword search revisited. In: ICCSA, Volume 5072 of LNCS, pp 1249–1259"",""Barker E, Barker W, Burr W, Polk W, Smid M (2006) Recommendation for key management-part 1 General (revised. In: NIST Special publication"",""Barreto PSLM, Naehrig M (2005) Pairing-friendly elliptic curves of prime order. In: SAC, Volume 3897 of LNCS, Springer, pp 319–331"",""Behnia R, Ozmen MO, Yavuz AA (2018) Lattice-based public key searchable encryption from experimental perspectives. IEEE Transactions on Dependable and Secure Computing"",""Bellare M, Desai A, Pointcheval D, Rogaway P (1998) Relations among notions of security for public-key encryption schemes. In: CRYPTO, Volume 1462 of LNCS, pp 26–45"",""Boneh D, Di Crescenzo G, Ostrovsky R, Persiano G (2004) Public key encryption with keyword search. In: Eurocrypt, volume 3027 of LNCS, pp 506–522"",""Boneh D, Franklin M (2001) Identity-based encryption from the weil pairing. In: CRYPTO, Volume 2139 of LNCS, pp 213–229"",""Boyen X, Waters B (2006) Anonymous hierarchical identity-based encryption (without random oracles). In: CRYPTO, Volume 4117 of LNCS, pp 290–307"",""citation_journal_title=Des Codes Crypt; citation_title=Elliptic curves suitable for pairing based cryptography; citation_author=F Brezing, A Weng; citation_volume=37; citation_issue=1; citation_publication_date=2005; citation_pages=133-141; citation_doi=10.1007/s10623-004-3808-4; citation_id=CR12"",""Buccafurri F, Lax G, Sahu RA, Saraswat V (2015) Practical and secure integrated PKE+PEKS with keyword privacy. In: SECRYPT, SciTePress, pp 448–453"",""Chatterjee S, Hankerson D, Menezes A (2010) On the efficiency and security of pairing-based protocols in the type 1 and type 4 settings. In: Arithmetic of finite fields, Volume 6087 of LNCS, pp 114–134"",""citation_journal_title=Discret Appl Math; citation_title=On cryptographic protocols employing asymmetric pairings – the role of ψ revisited; citation_author=S Chatterjee, A Menezes; citation_volume=159; citation_issue=13; citation_publication_date=2011; citation_pages=1311-1322; citation_doi=10.1016/j.dam.2011.04.021; citation_id=CR15"",""Chen J, Lim HW, Ling S, Wang H, Wee H (2012) Shorter IBE and signatures via asymmetric pairings. In: Pairing, Volume 7708 of LNCS, pp 122–140"",""Yu C, Zhang J, Lin D, Zhang Z (2014) Generic constructions of integrated PKE and PEKS. Des Codes Crypt, pp 1–34"",""Cocks C (2001) An identity based encryption scheme based on quadratic residues. In: Cryptography and coding, pp 360– 363"",""Di Crescenzo G, Saraswat V (2007) Public key encryption with searchable keywords based on Jacobi symbols. In: Indocrypt, Volume 4859 of LNCS, pp 282–296"",""Dodis Y, Katz J (2005) Chosen-ciphertext security of multiple encryption. In: TCC, Volume 3378 of LNCS, pp 188–209"",""citation_journal_title=J Cryptol; citation_title=A taxonomy of pairing-friendly elliptic curves; citation_author=D Freeman, M Scott, E Teske; citation_volume=23; citation_issue=2; citation_publication_date=2010; citation_pages=224-280; citation_doi=10.1007/s00145-009-9048-z; citation_id=CR21"",""Fuhr T, Paillier P (2007) Decryptable searchable encryption. In: Provable security, Volume 4784 of LNCS, pp 228–236"",""citation_journal_title=Discret Appl Math; citation_title=Pairings for cryptographers; citation_author=SD Galbraith, KG Paterson, NP Smart; citation_volume=156; citation_issue=16; citation_publication_date=2008; citation_pages=3113-3121; citation_doi=10.1016/j.dam.2007.12.010; citation_id=CR23"",""citation_journal_title=J Comput Syst Sci; citation_title=Probabilistic encryption; citation_author=S Goldwasser, S Micali; citation_volume=28; citation_issue=2; citation_publication_date=1984; citation_pages=270-299; citation_doi=10.1016/0022-0000(84)90070-9; citation_id=CR24"",""citation_journal_title=Int J Inf Technol; citation_title=Public key encryption with keyword search from lattices; citation_author=C Gu, Y Guang, Y Zhu, Y Zheng; citation_volume=19; citation_issue=1; citation_publication_date=2013; citation_pages=1-10; citation_id=CR25"",""Ibraimi L, Nikova S, Hartel P, Jonker W (2011) Public-key encryption with delegated search. In: ACNS, Volume 6715 of LNCS, pp 532–549"",""Jutla CS, Roy A (2013) Shorter quasi-adaptive NIZK proofs for linear subspaces. In: Asiacrypt, Volume 8269 of LNCS, pp 1–20"",""Kuchta V, Markowitch O (2016) Identity-based threshold encryption on lattices with application to searchable encryption. In: International Conference on Applications and Techniques in Information Security, Springer, pp 117–129"",""Kurosawa K (2002) Multi-recipient public-key encryption with shortened ciphertext. In: PKC, Volume 2274 of LNCS, pp 48–63"",""Miyaji A, Nakabayashi M, Takano S (2001) Characterization of elliptic curve traces under FR-reduction. In: ICISC 2000, Volume 2015 of LNCS, pp 90–108"",""citation_journal_title=IACR Cryptology ePrint Archive; citation_title=Searchable keyword-based encryption; citation_author=DJ Park, J Cha, PJ Lee; citation_volume=2005; citation_publication_date=2005; citation_pages=367; citation_id=CR31"",""Paterson KG, Schuldt JCN, Stam M, Thomson S (2011) On the joint security of encryption and signature, revisited. In: Asiacrypt, volume 7073 of LNCS, pp 161–178"",""Ramanna SC, Chatterjee S, Sarkar P (2012) Variants of Waters’ dual system primitives using asymmetric pairings. In: PKC, Volume 7293 of LNCS, pp 298–315"",""citation_journal_title=Human-centric Computing and Information Sciences; citation_title=Implementation of searchable symmetric encryption for privacy-preserving keyword search on cloud storage; citation_author=IMd Salam, W-C Yau, J-J Chin, S-H Heng, H-C Ling, RCW Phan, GS Poh, S-Y Tan, W-S Yap; citation_volume=5; citation_issue=1; citation_publication_date=2015; citation_pages=19; citation_doi=10.1186/s13673-015-0039-9; citation_id=CR34"",""Saraswat V, Sahu RA (2017) Short integrated PKE+PEKS in standard model. In: SPACE, Volume 10662 of LNCS, Springer, pp 226–246"",""citation_journal_title=ACM SIGMOD Rec; citation_title=Database encryption: an overview of contemporary challenges and design considerations; citation_author=E Shmueli, R Vaisenberg, Y Elovici, C Glezer; citation_volume=38; citation_issue=3; citation_publication_date=2010; citation_pages=29-34; citation_doi=10.1145/1815933.1815940; citation_id=CR36"",""citation_journal_title=Discret Appl Math; citation_title=On computable isomorphisms in efficient asymmetric pairing-based systems; citation_author=NP Smart, F Vercauteren; citation_volume=155; citation_issue=4; citation_publication_date=2007; citation_pages=538-547; citation_doi=10.1016/j.dam.2006.07.004; citation_id=CR37"",""Strizhov M, Ray I (2014) Multi-keyword similarity search over encrypted cloud data. In: SEC, volume 428 of IFIP Advances in Information and Communication Technology, pp 52–65"",""Waters Brent (2009) Dual system encryption: Realizing fully secure IBE and HIBE under simple assumptions. In: Crypto, volume 5677 of LNCS, pages 619–636"",""Zhang R, Imai H (2007) Generic combination of public key encryption with keyword search and public key encryption. In: Cryptology and Network Security, volume 4856 of LNCS, pp 159–174""
""citation_journal_title"",""Journal of Hardware and Systems Security""
""language"",""en""
""citation_cover_date"",""2019/03/01""
""og:description"",""Since the last decade, the public-key encryption with keyword search (PEKS) has been studied as a popular technique for searching data over encrypted files. The notion finds useful application for fine-grained data search on outsourced encrypted data like iCloud, mobile cloud data, etc. In this paper, we present a concrete public-key encryption (PKE)+PEKS scheme and prove its security in the standard model. We prove that our scheme is both IND-PKE-CCA secure, that is, provides message confidentiality against an adaptive chosen-ciphertext adversary, and IND-PEKS-CCA secure, that is, provides keyword privacy against an adaptive chosen-ciphertext adversary, under the Symmetric eXternal Diffie-Hellman (SXDH) assumption. Our construction uses asymmetric pairings which enable a fast implementation useful for practical applications. Our scheme has much shorter ciphertexts than other known PKE+PEKS schemes. Particularly, we compare our scheme with other proposed PEKS and integrated PKE+PEKS schemes and provide a relative analysis of various parameters including assumption, security, and efficiency.""
""prism.issn"",""2509-3436""
""citation_author_email"",""vishal.saraswat@gmail.com"",""rajeevs.crypto@gmail.com"",""gsharma@ulb.ac.be"",""Veronika.Kuchta@monash.edu"",""olivier.markowitch@ulb.ac.be""
""twitter:image:alt"",""Content cover image""
""prism.number"",""1""
""citation_issn"",""2509-3436""
""citation_language"",""en""
""dc:title"",""Public-Key Encryption with Integrated Keyword Search | SpringerLink""
""Content-Encoding"",""UTF-8""
""citation_pdf_url"",""https://link.springer.com/content/pdf/10.1007/s41635-019-00066-w.pdf""
""citation_lastpage"",""25""
""DOI"",""10.1007/s41635-019-00066-w""
""citation_journal_abbrev"",""J Hardw Syst Secur""
""prism.rightsAgent"",""journalpermissions@springernature.com""
""citation_author"",""Vishal Saraswat"",""Rajeev Anand Sahu"",""Gaurav Sharma"",""Veronika Kuchta"",""Olivier Markowitch""
""resourceName"",""casa""
""dc.date"",""2019-03-05""
""citation_springer_api_url"",""http://api.springer.com/metadata/pam?q=doi:10.1007/s41635-019-00066-w&api_key=""
""citation_issue"",""1""
""prism.volume"",""3""
""prism.publicationName"",""Journal of Hardware and Systems Security""
""citation_doi"",""10.1007/s41635-019-00066-w""
""dc.title"",""Public-Key Encryption with Integrated Keyword Search""
""prism.url"",""https://link.springer.com/article/10.1007/s41635-019-00066-w""
""citation_volume"",""3""
""dc.language"",""En""
""Content-Language"",""en""
""format-detection"",""telephone=no""
""citation_publication_date"",""2019/03""
""prism.endingPage"",""25""
""citation_title"",""Public-Key Encryption with Integrated Keyword Search""
""citation_author_institution"",""Indian Institute of Technology Jammu, Jammu, India"",""UniversitĂŠ Libre de Bruxelles, Brussels, Belgium"",""UniversitĂŠ Libre de Bruxelles, Brussels, Belgium"",""Monash University, Melbourne, Australia"",""UniversitĂŠ Libre de Bruxelles, Brussels, Belgium""
""access"",""No""
""citation_publisher"",""Springer International Publishing""
""applicable-device"",""pc,mobile""
""dc.format"",""text/html""
""description"",""Since the last decade, the public-key encryption with keyword search (PEKS) has been studied as a popular technique for searching data over encrypted files""
""title"",""Public-Key Encryption with Integrated Keyword Search | SpringerLink""
""citation_online_date"",""2019/03/05""
""twitter:site"",""@SpringerLink""
""dc.source"",""Journal of Hardware and Systems Security 2019 3:1""
""dc.type"",""OriginalPaper""
""dc.copyright"",""2019 Springer Nature Switzerland AG""
""dc.creator"",""Vishal Saraswat"",""Rajeev Anand Sahu"",""Gaurav Sharma"",""Veronika Kuchta"",""Olivier Markowitch""
""citation_fulltext_html_url"",""https://link.springer.com/article/10.1007/s41635-019-00066-w""
""prism.publicationDate"",""2019-03-05""
""Content-Type"",""text/html; charset=UTF-8""
""journal_id"",""41635""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""dc.description"",""Since the last decade, the public-key encryption with keyword search (PEKS) has been studied as a popular technique for searching data over encrypted files. The notion finds useful application for fine-grained data search on outsourced encrypted data like iCloud, mobile cloud data, etc. In this paper, we present a concrete public-key encryption (PKE)+PEKS scheme and prove its security in the standard model. We prove that our scheme is both IND-PKE-CCA secure, that is, provides message confidentiality against an adaptive chosen-ciphertext adversary, and IND-PEKS-CCA secure, that is, provides keyword privacy against an adaptive chosen-ciphertext adversary, under the Symmetric eXternal Diffie-Hellman (SXDH) assumption. Our construction uses asymmetric pairings which enable a fast implementation useful for practical applications. Our scheme has much shorter ciphertexts than other known PKE+PEKS schemes. Particularly, we compare our scheme with other proposed PEKS and integrated PKE+PEKS schemes and provide a relative analysis of various parameters including assumption, security, and efficiency.""
""og:type"",""article""
""citation_article_type"",""Article""
""og:title"",""Public-Key Encryption with Integrated Keyword Search""
""prism.doi"",""doi:10.1007/s41635-019-00066-w""
""X-UA-Compatible"",""IE=edge""
""citation_firstpage"",""12""
""prism.startingPage"",""12""
""viewport"",""width=device-width, initial-scale=1""
""dc.rightsAgent"",""journalpermissions@springernature.com""
""prism.section"",""OriginalPaper""
""dc.identifier"",""doi:10.1007/s41635-019-00066-w""
""dc.subject"",""Circuits and Systems"",""Computer Hardware"",""Systems and Data Security"",""Information Systems Applications (incl.Internet)""
""og:url"",""https://link.springer.com/article/10.1007/s41635-019-00066-w""
""prism.copyright"",""2019 Springer Nature Switzerland AG""
";https://scholar.google.com/scholar?start=840&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094581-822;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[HTML][HTML] An efficient ID-based cryptographic transformation model for extended chaotic-map-based cryptosystem;C Meshram, CC Lee, SG Meshram, CT Li ; Soft Computing, 2019  Springer;Germany;"… ID-based cryptography, on the other hand, is an augmentation of the public key cryptography

paradigm, which was first suggested by Shamir (1984) at CRYPTO'84 … Their technique does not

require random oracles and is semantically secure under the DL supposition …";Cité 14 fois;Les 3 versions;[HTML] springer.com;https://idp.springer.com/authorize/casa?redirect_uri=https://link.springer.com/article/10.1007/s00500-018-3332-5&casa_token=gELjA8WNtH0AAAAA:gzMIFzMthiTzD3hQUsiPmsSBx88VYA6_p8I1Oz2b08qY6XoAaIGR2NpUZTA0Adz3wNlAZOwvpHfRdNY;;"""dc.publisher"",""Springer""
""og:image"",""https://media.springernature.com/w200/springer-static/cover/journal/500.jpg""
""twitter:card"",""summary""
""og:site_name"",""Soft Computing""
""citation_reference"",""citation_journal_title=Phys Lett A; citation_title=A new identity based encryption (IBE) scheme using extended Chebyshev polynomial over finite fields Zp; citation_author=MB Algehawi, A Samsudin; citation_volume=374; citation_publication_date=2010; citation_pages=4670-4674; citation_doi=10.1016/j.physleta.2010.09.041; citation_id=CR1"",""citation_journal_title=IEEE Trans Circuits Syst I; citation_title=Security of public key cryptosystems based on Chebyshev polynomials; citation_author=P Bergamo, P D’Arco, A Santis, L Kocarev; citation_volume=52; citation_issue=7; citation_publication_date=2005; citation_pages=1382-1393; citation_doi=10.1109/TCSI.2005.851701; citation_id=CR2"",""Boneh D, Boyen X (2004) Efficient selective-id secure identity based encryption without random oracles. In: Advances in cryptology-EUROCRYPT 2004, lecture notes in computer science, vol 3027. Springer, Berlin, pp 223–238"",""citation_journal_title=SIAM J Comput; citation_title=Identity based encryption from the Weil pairing; citation_author=D Boneh, MK Franklin; citation_volume=32; citation_issue=3; citation_publication_date=2003; citation_pages=586-615; citation_doi=10.1137/S0097539701398521; citation_id=CR4"",""Canetti R, Halevi S, Katz J (2003) A forward-secure public-key encryption scheme. In: Advances in cryptology—Eurocrypt 2003, vol 2656, pp 255–271"",""citation_journal_title=Commun Nonlinear Sci Numer Simul; citation_title=Period distribution analysis of some linear maps; citation_author=F Chen, X Liao, KW Wong, Q Han, Y Li; citation_volume=17; citation_publication_date=2012; citation_pages=3848-3856; citation_doi=10.1016/j.cnsns.2012.02.021; citation_id=CR6"",""Cocks C (2001) An identity based encryption protocol based on quadratic residues. In: International conference on cryptography and coding (proceedings of IMA), lecture notes in computer science, vol 2260. Springer, pp 360–363"",""citation_journal_title=IEEE Trans Inf Theory IT; citation_title=New directions in cryptography; citation_author=W Diffie, ME Hellman; citation_volume=22; citation_issue=4; citation_publication_date=1976; citation_pages=454-644; citation_doi=10.1109/TIT.1976.1055581; citation_id=CR8"",""citation_journal_title=IEEE Trans Inf Theory; citation_title=A public key cryptosystem and a signature scheme based on discrete logarithms; citation_author=T ElGmal; citation_volume=31; citation_publication_date=1995; citation_pages=469-472; citation_doi=10.1109/TIT.1985.1057074; citation_id=CR9"",""citation_journal_title=Choas Soliton Fractals; citation_title=Chaotic map based key agreement with/out clock synchronization; citation_author=S Han, E Chang; citation_volume=39; citation_issue=3; citation_publication_date=2009; citation_pages=1283-1289; citation_doi=10.1016/j.chaos.2007.06.030; citation_id=CR10"",""citation_journal_title=IEICE Trans Fundam; citation_title=k-Resilient identity-based encryption in the standard model; citation_author=S Heng, K Kurosawa; citation_volume=E89CA; citation_issue=1; citation_publication_date=2006; citation_pages=39-46; citation_doi=10.1093/ietfec/e89-a.1.39; citation_id=CR11"",""citation_journal_title=Comput Stand Interfaces; citation_title=An efficient user identification scheme based on ID-based cryptosystem; citation_author=MS Hwan, JW Lo, SC Lin; citation_volume=26; citation_publication_date=2004; citation_pages=565-569; citation_doi=10.1016/j.csi.2004.03.006; citation_id=CR12"",""Hwu F (1993) The interpolating random spline cryptosystem and the chaotic-map public-key cryptosystem. Ph.d. thesis, University of Missouri Rolla"",""citation_journal_title=Comput Methods Progr Biomed; citation_title=Secure anonymous mutual authentication for star two-tier wireless body area networks; citation_author=MH Ibrahim, S Kumari, AK Das, M Wazid, V Odelu; citation_volume=135; citation_publication_date=2016; citation_pages=37-50; citation_doi=10.1016/j.cmpb.2016.07.022; citation_id=CR14"",""Kiltz E, Vahlis Y (2008) CCA2 secure IBE: standard model efficiency through authenticated symmetric encryption. CT-RSA, lecture notes in computer science, vol 4964. Springer, pp 221–239"",""citation_journal_title=IEEE Circuits Syst Mag; citation_title=Chaos-based cryptography: a brief overview; citation_author=L Kocarev; citation_volume=1; citation_publication_date=2001; citation_pages=6-21; citation_doi=10.1109/7384.963463; citation_id=CR16"",""Kocarev L, Tasev Z (2003) Public-key encryption based on chebyshev maps. In: Proceedings of the 2003 international symposium on circuits and systems.                      https://doi.org/10.1109/iscas.2003.1204947                                                                 "",""citation_journal_title=Nonlinear Dyn; citation_title=A secure biometric-based remote user authentication with key agreement scheme using extended chaotic maps; citation_author=CC Lee, CW Hsu; citation_volume=71; citation_issue=1–2; citation_publication_date=2013; citation_pages=201-211; citation_doi=10.1007/s11071-012-0652-3; citation_id=CR18"",""citation_journal_title=J Netw Comput Appl; citation_title=Constructing identity-based cryptosystems for discrete logarithm based cryptosystems; citation_author=WC Lee, KC Liao; citation_volume=22; citation_publication_date=2004; citation_pages=191-199; citation_doi=10.1016/j.jnca.2004.03.001; citation_id=CR19"",""citation_journal_title=Nonlinear Dyn; citation_title=An extended chaotic maps-based key agreement protocol with user anonymity; citation_author=CC Lee, CL Chen, CY Wu, SY Huang; citation_volume=69; citation_issue=1–2; citation_publication_date=2012; citation_pages=79-87; citation_doi=10.1007/s11071-011-0247-4; citation_id=CR20"",""citation_journal_title=J Med Syst; citation_title=An enhanced mobile-healthcare emergency system based on extended chaotic maps; citation_author=CC Lee, CW Hsu, YM Lai, AV Vasilakos; citation_volume=37; citation_issue=5; citation_publication_date=2013; citation_pages=9973; citation_doi=10.1007/s10916-013-9973-0; citation_id=CR21"",""citation_journal_title=Nonlinear Dyn; citation_title=A three-party password-based authenticated key exchange protocol with user anonymity using extended chaotic maps; citation_author=CC Lee, CT Li, CW Hsu; citation_volume=73; citation_issue=1–2; citation_publication_date=2013; citation_pages=125-132; citation_doi=10.1007/s11071-013-0772-4; citation_id=CR22"",""citation_journal_title=Nonlinear Dyn; citation_title=A new three-party-authenticated key agreement scheme based on chaotic maps without password table; citation_author=CC Lee, CT Li, ST Chiu, YM Lai; citation_volume=79; citation_issue=4; citation_publication_date=2014; citation_pages=2485-2495; citation_doi=10.1007/s11071-014-1827-x; citation_id=CR23"",""citation_journal_title=Nonlinear Dyn; citation_title=An extended chaotic-maps-based protocol with key agreement for multiserver environments; citation_author=CC Lee, DC Lou, CT Li, CW Hsu; citation_volume=76; citation_issue=1; citation_publication_date=2014; citation_pages=853-866; citation_doi=10.1007/s11071-013-1174-3; citation_id=CR24"",""citation_journal_title=J Med Syst; citation_title=A secure chaotic maps and smart cards based password authentication and key agreement scheme with user anonymity for telecare medicine information systems; citation_author=CT Li, CC Lee, CY Weng; citation_volume=38; citation_issue=9; citation_publication_date=2014; citation_pages=77; citation_doi=10.1007/s10916-014-0077-2; citation_id=CR25"",""citation_journal_title=Soft Comput; citation_title=A novel three-party password-based authenticated key exchange protocol with user anonymity based on chaotic maps; citation_author=CT Li, CL Chen, CC Lee; citation_publication_date=2017; citation_doi=10.1007/s00500-017-2504-z; citation_id=CR26"",""citation_journal_title=Soft Comput; citation_title=Efficient subtree-based encryption for fuzzy-entity data sharing; citation_author=W Liu, J Liu, Q Wu, B Qin, D Naccache, H Ferradi; citation_publication_date=2017; citation_doi=10.1007/s00500-017-2743-z; citation_id=CR27"",""citation_title=Chebyshev polynomials; citation_publication_date=2003; citation_id=CR28; citation_author=JC Mason; citation_author=DC Handscomb; citation_publisher=Chapman & Hall/CRC"",""citation_title=Handbook of applied cryptography; citation_publication_date=1997; citation_id=CR29; citation_author=A Menezes; citation_author=PV Oorschot; citation_author=S Vanstone; citation_publisher=CRC"",""citation_journal_title=Inf Process Lett; citation_title=An efficient ID-based cryptographic encryption based on discrete logarithm problem and integer factorization problem; citation_author=C Meshram; citation_volume=115; citation_issue=2; citation_publication_date=2015; citation_pages=351-358; citation_doi=10.1016/j.ipl.2014.10.007; citation_id=CR30"",""citation_journal_title=Int J Secur Appl; citation_title=An efficient ID-based beta cryptosystem; citation_author=C Meshram; citation_volume=9; citation_issue=2; citation_publication_date=2015; citation_pages=189-202; citation_id=CR31"",""citation_journal_title=Int J Hybrid Inf Technol; citation_title=Factoring and discrete logarithm using IBC; citation_author=C Meshram; citation_volume=8; citation_issue=3; citation_publication_date=2015; citation_pages=121-132; citation_doi=10.14257/ijhit.2015.8.3.12; citation_id=CR32"",""Meshram C, Meshram S (2011) An identity based beta cryptosystem. In: IEEE Proceedings of 7th international conference on information assurance and security (IAS 2011) Dec 5–8, pp 298–303"",""citation_journal_title=Inf Process Lett; citation_title=An identity-based cryptographic model for discrete logarithm and integer factoring based cryptosystem; citation_author=C Meshram, S Meshram; citation_volume=113; citation_issue=10–11; citation_publication_date=2013; citation_pages=375-380; citation_doi=10.1016/j.ipl.2013.02.009; citation_id=CR34"",""citation_journal_title=J Discrete Math Sci Cryptogr; citation_title=Constructing new an ID-based cryptosystem for IFP and GDLP based cryptosystem; citation_author=C Meshram, SA Meshram; citation_volume=20; citation_issue=5; citation_publication_date=2017; citation_pages=1121-1134; citation_doi=10.1080/09720529.2015.1032621; citation_id=CR35"",""Meshram C, Obaidat MS (2015) An ID-based quadratic-exponentiation randomized cryptographic scheme. In: IEEE proceeding of international conference on computer, information and telecommunication systems, pp 1–5"",""citation_journal_title=Inf Process Lett; citation_title=An ID-based cryptographic mechanisms based on GDLP and IFP; citation_author=C Meshram, S Meshram, M Zhang; citation_volume=112; citation_issue=19; citation_publication_date=2012; citation_pages=753-758; citation_doi=10.1016/j.ipl.2012.06.018; citation_id=CR37"",""citation_journal_title=Int J Pure Appl Math; citation_title=New Identity-based cryptographic scheme for IFP and DLP based cryptosystem; citation_author=C Meshram, X Huang, S Meshram; citation_volume=81; citation_issue=1; citation_publication_date=2012; citation_pages=65-79; citation_id=CR38"",""citation_journal_title=Int J Appl Math; citation_title=Constructing identity-based cryptographic scheme for beta cryptosystem; citation_author=C Meshram, S Meshram, C Ram; citation_volume=25; citation_issue=5; citation_publication_date=2012; citation_pages=609-624; citation_id=CR39"",""citation_journal_title=Procedia Comput Sci; citation_title=An IBE technique using partial discrete logarithm; citation_author=C Meshram, PL Powar, MS Obaidat, CC Lee; citation_volume=93; citation_publication_date=2016; citation_pages=735-741; citation_doi=10.1016/j.procs.2016.07.282; citation_id=CR40"",""citation_journal_title=Informatica; citation_title=An IND-ID-CPA secure ID-based cryptographic protocol using GDLP and IFP; citation_author=C Meshram, YM Tseng, CC Lee, SG Meshram; citation_volume=28; citation_issue=3; citation_publication_date=2017; citation_pages=471-484; citation_doi=10.15388/Informatica.2017.139; citation_id=CR41"",""citation_journal_title=Soft Comput; citation_title=A secure key authentication scheme for cryptosystems based on GDLP and IFP; citation_author=C Meshram, CC Lee, CT Li, CL Chen; citation_volume=21; citation_issue=24; citation_publication_date=2017; citation_pages=7285-7291; citation_doi=10.1007/s00500-016-2440-3; citation_id=CR42"",""citation_journal_title=Soft Comput; citation_title=An efficient online/offline ID-based short signature procedure using extended chaotic maps; citation_author=C Meshram, CT Li, SG Meshram; citation_publication_date=2018; citation_doi=10.1007/s00500-018-3112-2; citation_id=CR43"",""citation_journal_title=Commun ACM; citation_title=A method for obtaining digital signatures and public-key cryptosystems; citation_author=RL Rivest, A Shamir, L Adleman; citation_volume=21; citation_publication_date=1978; citation_pages=120-126; citation_doi=10.1145/359340.359342; citation_id=CR44"",""Shamir A (1984) Identity-based cryptosystems and signature schemes. In: Proceedings of CRYPTO’84, lecture notes in computer science, vol 196. Springer, pp 47–53"",""citation_journal_title=Inf Sci; citation_title=A provably secure short signature scheme based on discrete logarithms; citation_author=Z Shao; citation_volume=177; citation_publication_date=2007; citation_pages=5432-5440; citation_doi=10.1016/j.ins.2007.05.039; citation_id=CR46"",""citation_title=Cryptography: theory and practice; citation_publication_date=2002; citation_id=CR47; citation_author=D Stinson; citation_publisher=CRC"",""citation_journal_title=IEEE J Sel Areas Commun; citation_title=An ID-based cryptosystem based on the discrete logarithm problem; citation_author=S Tsujii, T Itoh; citation_volume=7; citation_publication_date=1989; citation_pages=467-473; citation_doi=10.1109/49.17709; citation_id=CR48"",""Waters B (2005) Efficient identity-based encryption without random oracles. In: Advances in cryptology-CRYPTO 2005, lecture notes in computer science, vol 3494. Springer, Berlin, pp 114–127"",""citation_journal_title=Soft Comput; citation_title=Forward and backward secure fuzzy encryption for data sharing in cloud computing; citation_author=J Wei, X Hu, W Liu; citation_publication_date=2017; citation_doi=10.1007/s00500-017-2834-x; citation_id=CR50"",""citation_journal_title=Chaos Solitons Fractals; citation_title=Cryptanalysis of the public key encryption based on multiple chaotic systems; citation_author=L Zhang; citation_volume=37; citation_issue=3; citation_publication_date=2008; citation_pages=669-674; citation_doi=10.1016/j.chaos.2006.09.047; citation_id=CR51""
""citation_journal_title"",""Soft Computing""
""language"",""en""
""citation_cover_date"",""2019/08/01""
""og:description"",""Recently, the chaos theory has been dealt with as a decent approach to reducing the computational complexity of a cryptographic technique while fulfilling the security necessities. In an ID-based cryptographic system where public keys are distributed to individual users, the application of chaotic maps allows users to set their network addresses or names as their individual public keys. This makes the public key cryptographic technique very user-friendly in that the public key confirmation process can be very informal and direct. In such a design, no huge public key database is required, and therefore, those security issues arising as a result of the existence of a public key database can be avoided. The aim of this article is to go deep into the possibility of transforming a chaotic-map-based cryptosystem into an ID-based technique without having to build a new framework from scratch or to do adjustment to the chaotic maps.""
""prism.issn"",""1433-7479""
""citation_author_email"",""cs_meshram@rediffmail.com"",""cclee@mail.fju.edu.tw"",""gajbhiyesarita@gmail.com"",""th0040@mail.tut.edu.tw""
""twitter:image:alt"",""Content cover image""
""prism.number"",""16""
""citation_issn"",""1433-7479""
""citation_language"",""en""
""dc:title"",""An efficient ID-based cryptographic transformation model for extended chaotic-map-based cryptosystem | SpringerLink""
""Content-Encoding"",""UTF-8""
""citation_pdf_url"",""https://link.springer.com/content/pdf/10.1007/s00500-018-3332-5.pdf""
""citation_lastpage"",""6946""
""DOI"",""10.1007/s00500-018-3332-5""
""citation_journal_abbrev"",""Soft Comput""
""prism.rightsAgent"",""journalpermissions@springernature.com""
""citation_author"",""Chandrashekhar Meshram"",""Cheng-Chi Lee"",""Sarita Gajbhiye Meshram"",""Chun-Ta Li""
""resourceName"",""casa""
""dc.date"",""2018-06-19""
""citation_springer_api_url"",""http://api.springer.com/metadata/pam?q=doi:10.1007/s00500-018-3332-5&api_key=""
""citation_issue"",""16""
""prism.volume"",""23""
""prism.publicationName"",""Soft Computing""
""citation_doi"",""10.1007/s00500-018-3332-5""
""dc.title"",""An efficient ID-based cryptographic transformation model for extended chaotic-map-based cryptosystem""
""prism.url"",""https://link.springer.com/article/10.1007/s00500-018-3332-5""
""citation_volume"",""23""
""dc.language"",""En""
""Content-Language"",""en""
""format-detection"",""telephone=no""
""citation_publication_date"",""2019/08""
""prism.endingPage"",""6946""
""citation_title"",""An efficient ID-based cryptographic transformation model for extended chaotic-map-based cryptosystem""
""citation_author_institution"",""Department of Mathematics and Computer Science, Rani Durgavati University, Jabalpur, India"",""Department of Mathematics, RTM Nagpur University, Nagpur, India"",""Department of Library and Information Science, Fu Jen Catholic University, New Taipei, Taiwan, ROC"",""Department of Photonics and Communication Engineering, Asia University, Wufeng Shiang, Taichung, Taiwan, ROC"",""Department of Mathematics and Computer Science, Rani Durgavati University, Jabalpur, India"",""Department of Information Management, Tainan University of Technology, Tainan, Taiwan, ROC""
""access"",""No""
""citation_publisher"",""Springer Berlin Heidelberg""
""applicable-device"",""pc,mobile""
""dc.format"",""text/html""
""description"",""Recently, the chaos theory has been dealt with as a decent approach to reducing the computational complexity of a cryptographic technique while fulfilling ""
""title"",""An efficient ID-based cryptographic transformation model for extended chaotic-map-based cryptosystem | SpringerLink""
""citation_online_date"",""2018/06/19""
""twitter:site"",""@SpringerLink""
""dc.source"",""Soft Computing 2018 23:16""
""dc.type"",""OriginalPaper""
""dc.copyright"",""2018 Springer-Verlag GmbH Germany, part of Springer Nature""
""dc.creator"",""Chandrashekhar Meshram"",""Cheng-Chi Lee"",""Sarita Gajbhiye Meshram"",""Chun-Ta Li""
""citation_fulltext_html_url"",""https://link.springer.com/article/10.1007/s00500-018-3332-5""
""prism.publicationDate"",""2018-06-19""
""Content-Type"",""text/html; charset=UTF-8""
""journal_id"",""500""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""dc.description"",""Recently, the chaos theory has been dealt with as a decent approach to reducing the computational complexity of a cryptographic technique while fulfilling the security necessities. In an ID-based cryptographic system where public keys are distributed to individual users, the application of chaotic maps allows users to set their network addresses or names as their individual public keys. This makes the public key cryptographic technique very user-friendly in that the public key confirmation process can be very informal and direct. In such a design, no huge public key database is required, and therefore, those security issues arising as a result of the existence of a public key database can be avoided. The aim of this article is to go deep into the possibility of transforming a chaotic-map-based cryptosystem into an ID-based technique without having to build a new framework from scratch or to do adjustment to the chaotic maps. ""
""og:type"",""article""
""citation_article_type"",""Methodologies and Application""
""og:title"",""An efficient ID-based cryptographic transformation model for extended chaotic-map-based cryptosystem""
""prism.doi"",""doi:10.1007/s00500-018-3332-5""
""X-UA-Compatible"",""IE=edge""
""citation_firstpage"",""6937""
""prism.startingPage"",""6937""
""viewport"",""width=device-width, initial-scale=1""
""dc.rightsAgent"",""journalpermissions@springernature.com""
""prism.section"",""OriginalPaper""
""dc.identifier"",""doi:10.1007/s00500-018-3332-5""
""dc.subject"",""Computational Intelligence"",""Artificial Intelligence"",""Mathematical Logic and Foundations"",""Control, Robotics, Mechatronics""
""og:url"",""https://link.springer.com/article/10.1007/s00500-018-3332-5""
""prism.copyright"",""2018 Springer-Verlag GmbH Germany, part of Springer Nature""
";https://scholar.google.com/scholar?start=640&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094558-722;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Catagora: Shared Library Cataloguing on the Ethereum Blockchain;K Joseph ;2019 era.library.ualberta.ca;;"… has-come-up-with-a-use-case-for- blockchain-ee98c180100; Kai Stinchcombe, “Blockchain Is

Not Only Crappy Technology but a Bad Vision for the Future,” Medium (blog), April 5, 2018,

https://medium.com/@kaistinchcombe/decentralized-and- trustless-crypto-paradise-is …";Autres articles;;[PDF] ualberta.ca;https://era.library.ualberta.ca/items/d2c52230-ba41-4909-b50b-aa9dec750a97/view/b19a0c96-3e46-40d8-942d-f3557b7342db/Joseph_Kris_201906_MA-MLIS.pdf;;"""date"",""2019-06-29T13:24:09Z""
""pdf:PDFVersion"",""1.4""
""xmp:CreatorTool"",""Word""
""pdf:docinfo:title"",""Microsoft Word - JosephKris_Thesis_Final.docx""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""pdfa:PDFVersion"",""A-2b""
""xmpMM:History:Action"",""converted""
""language"",""en""
""dc:format"",""application/pdf; version=""""A-2b"""""",""application/pdf; version=1.4""
""pdf:docinfo:creator_tool"",""Word""
""access_permission:fill_in_form"",""true""
""xmpMM:History:When"",""2019-06-29T07:24:08Z""
""pdf:encrypted"",""false""
""dc:title"",""Microsoft Word - JosephKris_Thesis_Final.docx""
""xmp:CreateDate"",""2019-06-29T13:22:25Z""
""modified"",""2019-06-29T13:24:09Z""
""xmpMM:History:SoftwareAgent"",""Preflight""
""pdf:hasMarkedContent"",""false""
""xmpMM:History:InstanceID"",""uuid:1e387d1a-38f9-c44d-bd64-92aca28aac14""
""xmp:ModifyDate"",""2019-06-29T07:24:09Z""
""meta:creation-date"",""2019-06-29T13:22:25Z""
""created"",""2019-06-29T13:22:25Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-06-29T13:22:25Z""
""resourceName"",""Joseph_Kris_201906_MA-MLIS.pdf""
""pdfaid:part"",""2""
""producer"",""macOS Version 10.15 (Build 19A487m) Quartz PDFContext""
""pdf:docinfo:producer"",""macOS Version 10.15 (Build 19A487m) Quartz PDFContext""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""access_permission:modify_annotations"",""true""
""dcterms:created"",""2019-06-29T13:22:25Z""
""Last-Modified"",""2019-06-29T13:24:09Z""
""dcterms:modified"",""2019-06-29T13:24:09Z""
""title"",""Microsoft Word - JosephKris_Thesis_Final.docx""
""xmpMM:DocumentID"",""uuid:43600d6a-6abc-484b-8d34-09e8088d25d9""
""Last-Save-Date"",""2019-06-29T13:24:09Z""
""pdf:docinfo:modified"",""2019-06-29T13:24:09Z""
""meta:save-date"",""2019-06-29T13:24:09Z""
""Content-Type"",""application/pdf""
""xmp:MetadataDate"",""2019-06-29T07:24:09Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""pdfaid:conformance"",""B""
""pdf:producer"",""macOS Version 10.15 (Build 19A487m) Quartz PDFContext""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""172""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""552"",""1839"",""1338"",""758"",""235"",""1394"",""2451"",""1175"",""1388"",""3152"",""2908"",""1839"",""2702"",""1580"",""2157"",""1468"",""2050"",""1815"",""2435"",""2327"",""2125"",""2180"",""2581"",""1751"",""1729"",""2062"",""2373"",""1668"",""2427"",""2075"",""1694"",""2183"",""2147"",""2340"",""1846"",""1984"",""1427"",""1755"",""2480"",""2288"",""2330"",""2459"",""2433"",""2442"",""1303"",""1881"",""1947"",""1772"",""1869"",""1998"",""1946"",""1895"",""2248"",""1556"",""2232"",""426"",""194"",""644"",""1947"",""1986"",""1913"",""1838"",""1850"",""2363"",""2235"",""1974"",""2118"",""2202"",""1968"",""2007"",""2106"",""1720"",""2054"",""2126"",""2064"",""1565"",""1756"",""2377"",""1973"",""1944"",""2123"",""2552"",""1819"",""1996"",""1810"",""2112"",""1720"",""1844"",""1815"",""1690"",""1797"",""1436"",""1988"",""2241"",""1843"",""1767"",""1902"",""1691"",""1555"",""1447"",""109"",""1746"",""1855"",""1742"",""2182"",""1044"",""165"",""1370"",""559"",""1023"",""729"",""1299"",""836"",""714"",""727"",""1270"",""1806"",""2642"",""2347"",""1834"",""2197"",""1748"",""2213"",""1766"",""2170"",""1904"",""2033"",""2030"",""1913"",""1777"",""1873"",""1852"",""546"",""2071"",""1989"",""2265"",""2284"",""1898"",""2588"",""1778"",""2135"",""1920"",""2061"",""1841"",""1725"",""1746"",""1603"",""2317"",""1638"",""191"",""1838"",""1940"",""1138"",""2351"",""2523"",""2404"",""2434"",""2334"",""2286"",""2511"",""2401"",""2232"",""2569"",""2379"",""2617"",""2163"",""2580"",""2509"",""2599"",""2348"",""2577"",""594""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-06-29T13:22:25Z""
";https://scholar.google.com/scholar?start=540&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094597-891;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[PDF][PDF] Digital Signatures for Consensus.;S Gorbunov, H Wee ; IACR Cryptol. ePrint Arch., 2019  dprating.osscnshanghai.aliyuncs …;;"… The use of forward-secure signatures prevent adaptive attacks on a PoS-based blockchain, where

an adversary waits till the … a standard q-type assumption in the random oracle model (or in the

generic group model without random oracles) … To simulate signature oracle for (t,M …";Cité 3 fois;Les 7 versions;[PDF] aliyuncs.com;https://dprating.oss-cn-shanghai.aliyuncs.com/prod/frontend/project/15788167285967088.pdf;;"""date"",""2019-03-06T16:23:39Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2019-03-06T16:23:39Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017) kpathsea version 6.2.3""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2019-03-06T16:23:39Z""
""created"",""2019-03-06T16:23:39Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-03-06T16:23:39Z""
""resourceName"",""15788167285967088.pdf""
""Author"",""""
""producer"",""pdfTeX-1.40.18""
""pdf:docinfo:producer"",""pdfTeX-1.40.18""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""5"",""10"",""5"",""7"",""26"",""89"",""0"",""0"",""14""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2019-03-06T16:23:39Z""
""Last-Modified"",""2019-03-06T16:23:39Z""
""dcterms:modified"",""2019-03-06T16:23:39Z""
""title"",""""
""Last-Save-Date"",""2019-03-06T16:23:39Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2019-03-06T16:23:39Z""
""meta:save-date"",""2019-03-06T16:23:39Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017) kpathsea version 6.2.3""
""Content-Length"",""145876""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""10""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""2535"",""3138"",""2224"",""3124"",""1904"",""1980"",""1944"",""3648"",""1950"",""206""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-03-06T16:23:39Z""
";https://scholar.google.com/scholar?start=710&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094539-647;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[CITATION][C] Einsatz von dezentralen Oracles für die Inter-Blockchain-Kommunikation in Multi-Ledger-Systemen;C Marx ;2019 Universität Hamburg;;null;;null;null;;;;https://scholar.google.com/scholar?start=460&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094605-925;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;ReHand: Secure Region-Based Fast Handover With User Anonymity for Small Cell Networks in Mobile Communications;CI Fan, JJ Huang, MZ Zhong, RH Hsu… ; IEEE Transactions …, 2019  ieeexplore.ieee.org;;"… However, the performance might be limited by the usage of blockchain systems. Nonetheless,

Ni et al … ? gives the resulting public parameters params. An encryption oracle Esk and the

decryption oracle Dsk are given a key sk. The above oracles hold the secret key secretly …";Cité 2 fois;Les 4 versions;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/10206/4358835/08772129.pdf?casa_token=1wMXqWIlf2IAAAAA:5tqushqo_k3teykIYy2pP0NGpevZp9yT4uz3xU9zB2NsL3vigr7bEH3bj-wsvyexWF0NNVtlel0;;"""og:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""twitter:title"",""ReHand: Secure Region-Based Fast Handover With User Anonymity for Small Cell Networks in Mobile Communications""
""twitter:card"",""summary""
""Description"",""Due to the fact that the higher density of mobile devices is expected, the fifth generation (5G) mobile networks introduce small cell networks (SCNs) to prevent""
""og:title"",""ReHand: Secure Region-Based Fast Handover With User Anonymity for Small Cell Networks in Mobile Communications""
""resourceName"",""08772129.pdf""
""language"",""en""
""title"",""ReHand: Secure Region-Based Fast Handover With User Anonymity for Small Cell Networks in Mobile Communications | IEEE Journals & Magazine | IEEE Xplore""
""og:description"",""Due to the fact that the higher density of mobile devices is expected, the fifth generation (5G) mobile networks introduce small cell networks (SCNs) to prevent exhausting radio resources. SCNs improve radio spectrum utilization by deploying more base stations (BSs) in the networks. Even though authenticated key exchange (AKE) is still essential to ensure entity authentication and confidentiality in mobile communications. Besides, user anonymity is required to guarantee the footprints of mobile communications being concealed. However, AKE with user anonymity may increase the latency of communications dramatically in total due to several times more frequency in SCNs. The increase of latency will be more serious when an AKE protocol supports user anonymity, where traceability and revocability to users are necessary. Thus, this paper presents a secure region-based handover scheme (ReHand) with user anonymity and fast revocation for SCNs. ReHand greatly reduces the communication latency when user equipments (UEs) roam between small cells within the region of a macro BS, i.e., eNB, and the computation costs due to the employment of symmetry-based cryptographic operations. Compared to the three related prior arts, ReHand dramatically reduces the latency from 82.92% to 99.99% by region-based secure handover. Nevertheless, this paper demonstrates the security of ReHand by theoretically formal proofs.""
""twitter:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-UA-Compatible"",""IE=Edge""
""viewport"",""width=device-width, initial-scale=1.0""
""dc:title"",""ReHand: Secure Region-Based Fast Handover With User Anonymity for Small Cell Networks in Mobile Communications | IEEE Journals & Magazine | IEEE Xplore""
""twitter:description"",""Due to the fact that the higher density of mobile devices is expected, the fifth generation (5G) mobile networks introduce small cell networks (SCNs) to prevent exhausting radio resources. SCNs improve radio spectrum utilization by deploying more base stations (BSs) in the networks. Even though authenticated key exchange (AKE) is still essential to ensure entity authentication and confidentiality in mobile communications. Besides, user anonymity is required to guarantee the footprints of mobile communications being concealed. However, AKE with user anonymity may increase the latency of communications dramatically in total due to several times more frequency in SCNs. The increase of latency will be more serious when an AKE protocol supports user anonymity, where traceability and revocability to users are necessary. Thus, this paper presents a secure region-based handover scheme (ReHand) with user anonymity and fast revocation for SCNs. ReHand greatly reduces the communication latency when user equipments (UEs) roam between small cells within the region of a macro BS, i.e., eNB, and the computation costs due to the employment of symmetry-based cryptographic operations. Compared to the three related prior arts, ReHand dramatically reduces the latency from 82.92% to 99.99% by region-based secure handover. Nevertheless, this paper demonstrates the security of ReHand by theoretically formal proofs.""
""Content-Encoding"",""UTF-8""
""Content-Type-Hint"",""text/html; charset=utf-8""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=740&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094539-645;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Tecnologia Blockchain-Potencial de Aplicaçăo no âmbito dos Processos de Negócio das Cadeias de Abastecimento;TA Borrego ;2019 repositorioaberto.up.pt;;"… 13 2.4.4 Smart Contracts . . . . . 14 2.4.4.1 Blockchain Oracles . . . . . 15 2.4.4.2

Exemplo de Implementaçăo . . . . . 16 2.4.5 Verificaçăo . . . . . 17 …";Autres articles;Version HTML;[PDF] up.pt;https://repositorio-aberto.up.pt/bitstream/10216/123225/2/361648.pdf;;"""date"",""2019-10-22T21:31:10Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""pt""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2019-10-22T21:31:10Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017) kpathsea version 6.2.3""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2019-10-22T21:31:10Z""
""created"",""2019-10-22T21:31:10Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-10-22T21:31:10Z""
""resourceName"",""361648.pdf""
""Author"",""""
""producer"",""pdfTeX-1.40.18""
""pdf:docinfo:producer"",""pdfTeX-1.40.18""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""1"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2019-10-22T21:31:10Z""
""Last-Modified"",""2019-10-22T21:31:10Z""
""dcterms:modified"",""2019-10-22T21:31:10Z""
""title"",""""
""Last-Save-Date"",""2019-10-22T21:31:10Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2019-10-22T21:31:10Z""
""meta:save-date"",""2019-10-22T21:31:10Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017) kpathsea version 6.2.3""
""Content-Length"",""2167269""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""106""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""309"",""24"",""187"",""0"",""2008"",""2"",""1787"",""2"",""569"",""2"",""83"",""1879"",""1476"",""9"",""1769"",""17"",""1044"",""17"",""246"",""0"",""1089"",""1882"",""1967"",""11"",""1298"",""1339"",""1992"",""2012"",""2055"",""1547"",""1620"",""1158"",""1542"",""2063"",""1766"",""1359"",""1218"",""1222"",""524"",""1010"",""2044"",""1299"",""1460"",""1381"",""1596"",""439"",""1648"",""1530"",""916"",""22"",""549"",""1637"",""1433"",""1310"",""1812"",""1773"",""1755"",""1770"",""1754"",""1675"",""1346"",""1457"",""1792"",""1997"",""1832"",""2116"",""1359"",""827"",""1431"",""1437"",""1617"",""1056"",""741"",""787"",""209"",""21"",""1136"",""1346"",""1879"",""2167"",""662"",""1522"",""1431"",""1648"",""1673"",""1439"",""1623"",""2029"",""1670"",""1618"",""1682"",""1510"",""443"",""352"",""756"",""60"",""1416"",""2369"",""8"",""8217"",""2049"",""2100"",""1716"",""2120"",""2098"",""538""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-10-22T21:31:10Z""
";https://scholar.google.com/scholar?start=460&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094534-630;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[HTML][HTML] A ledger of me: personalizing healthcare using blockchain technology;G Leeming, J Cunningham, J Ainsworth ; Frontiers in medicine, 2019  frontiersin.org;Switzerland;"… Building on the initial work to design a crypto-currency a new platform was started, called

Ethereum (19) … Oracle services are application programming interfaces (APIs) that interact with

software and data that is available separate to the blockchain, introducing an often …";Cité 32 fois;Les 6 versions;[HTML] frontiersin.org;https://www.frontiersin.org/articles/10.3389/fmed.2019.00171/full;;"""citation_keywords"",""Blockchain; Health Infomatics; Distributed Ledger Technologies; Personal health record (PHR); Digital Health""
""og:image"",""https://www.frontiersin.org/files/MyHome%20Article%20Library/434914/434914_Thumb_400.jpg""
""citation_publication_date"",""2019/07/24""
""citation_title"",""A Ledger of Me: Personalizing Healthcare Using Blockchain Technology""
""citation_author_institution"",""Division of Informatics, Imaging and Data Sciences, Health eResearch Centre, Manchester Academic Health Science Centre, University of Manchester, United Kingdom"",""Division of Informatics, Imaging and Data Sciences, Health eResearch Centre, Manchester Academic Health Science Centre, University of Manchester, United Kingdom"",""Division of Informatics, Imaging and Data Sciences, Health eResearch Centre, Manchester Academic Health Science Centre, University of Manchester, United Kingdom""
""Description"",""Personal Health Records (PHRs) have the potential to give patients fine-grained, personalized and secure access to their own medical data and to enable self-management of care. Emergent trends around the use of Blockchain, or Distributed Ledger Technology, seem to offer solutions to some of the problems faced in enabling these technologies, especially to support issues consent, data exchange, and data access. We present an analysis of existing blockchain-based health record solutions and a reference architecture for a “Ledger of Me” system that extends PHR to create a new platform combining the collection and access of medical data and digital interventions with smart contracts. Our intention is to enable patient use of the data in order to support their care and to provide a strong consent mechanisms for sharing of data between different organizations and apps. Ledger of Me is based on around the principle that this combination of event-driven smart contracts, medical record data, and patient control is important for the adoption of blockchain-based solutions for the PHR. The reference architecture we present can serve as the basis of a range of future blockchain-based medical application architectures.""
""Keywords"",""Blockchain, Health Infomatics, Distributed Ledger Technologies, Personal health record (PHR), Digital Health""
""citation_publisher"",""Frontiers""
""citation_journal_title"",""Frontiers in Medicine""
""description"",""Personal Health Records (PHRs) have the potential to give patients fine-grained, personalised and secure access to their own medical data and to enable self-management of care. Emergent trends around the use of Blockchain, or Distributed Ledger Technology, seem to offer solutions to some of the problems faced in enabling these technologies, especially to support issues consent, data exchange and data access. We present an analysis of existing blockchain-based health record solutions and a reference architecture for a “Ledger of Me” system that extends PHR to create a new platform combining the collection and access of medical data and digital interventions with smart contracts. Our intention is to enable patient use of the data in order to support their care and to provide a strong consent mechanisms for sharing of data between different organisations and apps. Ledger of Me is based on around the principle that this combination of event-driven smart contracts, medical record data and patient control is important for the adoption of blockchain-based solutions for the PHR. The reference architecture we present can serve as the basis of a range of future blockchain-based medical application architectures.""
""language"",""en""
""citation_date"",""2019""
""title"",""Frontiers | A Ledger of Me: Personalizing Healthcare Using Blockchain Technology | Medicine""
""citation_online_date"",""2019/07/08""
""citation_author_email"","""","""",""""
""citation_issn"",""2296-858X""
""dc:title"",""Frontiers | A Ledger of Me: Personalizing Healthcare Using Blockchain Technology | Medicine""
""citation_language"",""English""
""Content-Encoding"",""UTF-8""
""citation_pdf_url"",""https://www.frontiersin.org/articles/10.3389/fmed.2019.00171/pdf""
""Content-Length"",""178019""
""Content-Type"",""text/html; charset=UTF-8""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""og:type"",""article""
""citation_journal_abbrev"",""Front. Med.""
""citation_abstract"",""Personal Health Records (PHRs) have the potential to give patients fine-grained, personalised and secure access to their own medical data and to enable self-management of care. Emergent trends around the use of Blockchain, or Distributed Ledger Technology, seem to offer solutions to some of the problems faced in enabling these technologies, especially to support issues consent, data exchange and data access. We present an analysis of existing blockchain-based health record solutions and a reference architecture for a “Ledger of Me” system that extends PHR to create a new platform combining the collection and access of medical data and digital interventions with smart contracts. Our intention is to enable patient use of the data in order to support their care and to provide a strong consent mechanisms for sharing of data between different organisations and apps. Ledger of Me is based on around the principle that this combination of event-driven smart contracts, medical record data and patient control is important for the adoption of blockchain-based solutions for the PHR. The reference architecture we present can serve as the basis of a range of future blockchain-based medical application architectures.""
""citation_author"",""Leeming, Gary"",""Cunningham, James"",""Ainsworth, John""
""Title"",""A Ledger of Me: Personalizing Healthcare Using Blockchain Technology""
""resourceName"",""full""
""citation_pages"",""171""
""url"",""https://www.frontiersin.org/article/10.3389/fmed.2019.00171/full""
""site_name"",""Frontiers""
""X-UA-Compatible"",""IE=edge""
""frontiers:type"",""Article""
""viewport"",""width=device-width, initial-scale=1, maximum-scale=1""
""citation_doi"",""10.3389/fmed.2019.00171""
""dc.identifier"",""doi:10.3389/fmed.2019.00171""
""citation_volume"",""6""
""Content-Language"",""en""
";https://scholar.google.com/scholar?start=440&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094619-989;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Postcards from the post-http world: Amplification of https vulnerabilities in the web ecosystem;S Calzavara, R Focardi, M Nemec… ; … IEEE Symposium on …, 2019  ieeexplore.ieee.org;;"… This list is not meant to be exhaustive, yet it is rich enough to cover important security

implications of existing crypto- graphic flaws of TLS on major websites … RSA signature oracles:

A very fast decryption oracle can be used to compute RSA signatures …";Cité 19 fois;Les 13 versions;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/8826229/8835208/08835223.pdf?casa_token=7lkrKQSC2w0AAAAA:4YRaGuUr-h8ab7mYM8b3IglN8laKOheccF6mp6F81jOCCgHTt0I0HzrFMce1CJNVCYtvydD1dZs;;"""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""dc:title"",""IEEE Xplore Full-Text PDF:""
""Content-Encoding"",""UTF-8""
""resourceName"",""08835223.pdf""
""language"",""es""
""Content-Length"",""2533""
""title"",""IEEE Xplore Full-Text PDF:""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=800&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094665-1183;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Statement voting;B Zhang, HS Zhou ; … Conference on Financial Cryptography and Data …, 2019  Springer;;"… the tally phase, the voter's ballots will be decrypted, and their statements will define their final

votes based on the latest information provided by News oracles on the blockchain … Common

Reference String (CRS) and Random Oracle (RO) are two popular choices in practice …";Cité 5 fois;Les 12 versions;[PDF] lancs.ac.uk;https://eprints.lancs.ac.uk/id/eprint/130298/1/mainStatement.pdf;;"""date"",""2018-12-29T13:25:10Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2018-12-29T13:25:10Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.19 (TeX Live 2018) kpathsea version 6.3.0""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2018-12-29T13:25:10Z""
""created"",""2018-12-29T13:25:10Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2018-12-29T13:25:10Z""
""resourceName"",""mainStatement.pdf""
""Author"",""""
""producer"",""pdfTeX-1.40.19""
""pdf:docinfo:producer"",""pdfTeX-1.40.19""
""pdf:unmappedUnicodeCharsPerPage"",""7"",""0"",""13"",""20"",""14"",""6"",""21"",""19"",""4"",""13"",""7"",""17"",""27"",""27"",""6"",""20"",""9"",""25"",""24"",""9"",""30"",""26"",""83"",""66"",""71"",""5"",""4"",""3"",""2"",""8"",""8"",""7"",""11"",""23"",""43"",""28"",""14"",""25"",""6"",""9"",""0"",""5"",""43"",""25"",""21"",""16"",""21"",""20"",""19""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2018-12-29T13:25:10Z""
""Last-Modified"",""2018-12-29T13:25:10Z""
""dcterms:modified"",""2018-12-29T13:25:10Z""
""title"",""""
""Last-Save-Date"",""2018-12-29T13:25:10Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2018-12-29T13:25:10Z""
""meta:save-date"",""2018-12-29T13:25:10Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.19 (TeX Live 2018) kpathsea version 6.3.0""
""Content-Length"",""919136""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""49""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""1065"",""1775"",""3765"",""4145"",""4060"",""3301"",""2586"",""2205"",""1580"",""2840"",""2472"",""2343"",""2252"",""1621"",""2740"",""1966"",""2182"",""1362"",""2816"",""2284"",""2106"",""2811"",""1963"",""2286"",""1662"",""2801"",""2702"",""2780"",""1813"",""2245"",""2630"",""2529"",""1945"",""2280"",""2326"",""1414"",""1236"",""2676"",""2456"",""2541"",""874"",""2165"",""2736"",""2720"",""2518"",""2237"",""2350"",""2154"",""1399""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2018-12-29T13:25:10Z""
";https://scholar.google.com/scholar?start=420&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094572-788;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[PDF][PDF] CRYPTOGRAPHY: THE CASE OF CRYPTOGRAPHIC DESIGN IN ASP .NET;G Gudi ; ijaconline.com;;"… The attacks combine decryption oracles, unauthenticated encryptions, and the reuse of keys

for different encryption purposes … Keywords: Cryptography, Application Security, Web security,

Decryption oracle attack … However, implementing crypto is error-prone …";Autres articles;Version HTML;[PDF] ijaconline.com;http://www.ijaconline.com/wp-content/uploads/2019/02/11-Ganga-Gudi.pdf;;"""date"",""2019-02-19T13:48:28Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.5""
""xmp:CreatorTool"",""MicrosoftÂŽ Word 2016""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dc:creator"",""Rahul Gaikwad""
""language"",""en""
""dcterms:created"",""2019-02-19T13:48:28Z""
""Last-Modified"",""2019-02-19T13:48:28Z""
""dcterms:modified"",""2019-02-19T13:48:28Z""
""dc:format"",""application/pdf; version=1.5""
""Last-Save-Date"",""2019-02-19T13:48:28Z""
""pdf:docinfo:creator_tool"",""MicrosoftÂŽ Word 2016""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2019-02-19T13:48:28Z""
""meta:save-date"",""2019-02-19T13:48:28Z""
""pdf:encrypted"",""false""
""modified"",""2019-02-19T13:48:28Z""
""Content-Length"",""237698""
""pdf:hasMarkedContent"",""false""
""Content-Type"",""application/pdf""
""pdf:docinfo:creator"",""Rahul Gaikwad""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Rahul Gaikwad""
""dc:language"",""en-IN""
""meta:author"",""Rahul Gaikwad""
""meta:creation-date"",""2019-02-19T13:48:28Z""
""created"",""2019-02-19T13:48:28Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""4""
""Creation-Date"",""2019-02-19T13:48:28Z""
""resourceName"",""11-Ganga-Gudi.pdf""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""2439"",""4086"",""1834"",""2451""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""Author"",""Rahul Gaikwad""
""producer"",""MicrosoftÂŽ Word 2016""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""MicrosoftÂŽ Word 2016""
""pdf:docinfo:created"",""2019-02-19T13:48:28Z""
";https://scholar.google.com/scholar?start=600&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094633-1047;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[CITATION][C] Implementing Aggregate-Key for Sharing Data in Cloud Environment using Cryptographic Encryption;KP Kaliyamurthie, G Michael, R Elankavi, SA Jijo ; International Journal of Innovative …, 2019;;null;Cité 1 fois;;null;;;;https://scholar.google.com/scholar?start=860&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094586-849;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[PDF][PDF] Agree-and-Prove: Generalized Proofs Of Knowledge and Applications.;C Badertscher, D Jost, U Maurer ; IACR Cryptol. ePrint Arch., 2019  eprint.iacr.org;;"… can formally not be guaranteed, which typically are settings where one assumes setup

functionalities such as a random oracle, a database, or a blockchain ledger, and where … A proof

relation ROF (ˇ,ˇ, which is a PPT oracle machine taking … contains three oracles that operate …";Cité 2 fois;Les 2 versions;[PDF] iacr.org;https://eprint.iacr.org/2019/662.pdf;;"""date"",""2020-02-11T13:05:15Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""Agree-and-Prove: Generalized Proofs Of Knowledge and Applications""
""xmp:CreatorTool"",""LaTeX with hyperref""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""Agree-and-Prove: Generalized Proofs Of Knowledge and Applications""
""modified"",""2020-02-11T13:05:15Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""Christian Badertscher, Daniel Jost, and Ueli Maurer""
""PTEX.Fullbanner"",""This is MiKTeX-pdfTeX 2.9.7029 (1.40.20)""
""meta:author"",""Christian Badertscher, Daniel Jost, and Ueli Maurer""
""trapped"",""False""
""meta:creation-date"",""2020-02-11T13:05:15Z""
""created"",""2020-02-11T13:05:15Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-02-11T13:05:15Z""
""resourceName"",""662.pdf""
""Author"",""Christian Badertscher, Daniel Jost, and Ueli Maurer""
""producer"",""MiKTeX pdfTeX-1.40.20""
""pdf:docinfo:producer"",""MiKTeX pdfTeX-1.40.20""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""13"",""4"",""37"",""8"",""0"",""51"",""0"",""0"",""1"",""11"",""2"",""8"",""17"",""8"",""16"",""50"",""30"",""8"",""17"",""43"",""1"",""0"",""1"",""1"",""0"",""0"",""0"",""20"",""17"",""20"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""Christian Badertscher, Daniel Jost, and Ueli Maurer""
""dcterms:created"",""2020-02-11T13:05:15Z""
""Last-Modified"",""2020-02-11T13:05:15Z""
""dcterms:modified"",""2020-02-11T13:05:15Z""
""title"",""Agree-and-Prove: Generalized Proofs Of Knowledge and Applications""
""Last-Save-Date"",""2020-02-11T13:05:15Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2020-02-11T13:05:15Z""
""meta:save-date"",""2020-02-11T13:05:15Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is MiKTeX-pdfTeX 2.9.7029 (1.40.20)""
""Content-Length"",""1044317""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Christian Badertscher, Daniel Jost, and Ueli Maurer""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""37""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""2951"",""4040"",""3797"",""3416"",""2759"",""3098"",""2800"",""3424"",""2368"",""2898"",""3688"",""2052"",""3728"",""3821"",""3247"",""2462"",""3253"",""3197"",""3011"",""2637"",""3299"",""2888"",""2586"",""3203"",""2810"",""2713"",""3080"",""2546"",""2860"",""2791"",""2964"",""2715"",""2566"",""2817"",""2259"",""2756"",""3184""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-02-11T13:05:15Z""
";https://scholar.google.com/scholar?start=660&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094626-1018;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;?????????? ???????? ??? ?????? ??????????? ??????-?????????? ????????????;?? ???????? ; ???????????? ????????, 2019  elibrary.ru;;"… ????????, ???????? Microsoft ???-???????? Coco Framework ??? ?????? Azure Blockchain,

??????? ???????? ????????????? ????????-????????. Blockchain Cloud Service ????????

Oracle, ? ????? ????????-???????-?? ???????? IBM ????? ??????? ????????? …";Cité 2 fois;;null;;;;https://scholar.google.com/scholar?start=830&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094602-917;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[PDF][PDF] Hush Version 3;D Leto ;2019 git.hush.is;;"… https://tools.ietf.org/html/draft-thomas-crypto-conditions-04 Hush will enable the following

CryptoConditions initially, and plans to enable others as time goes on: • Heir - cryptocoin

inheritance • Gateway - tokenized representations of foreign blockchain assets • Oracle - bridge …";Autres articles;;[PDF] hush.is;https://git.hush.is/hush/hush-v3-whitepaper/raw/branch/master/hush-v3.pdf;;;https://scholar.google.com/scholar?start=730&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094565-756;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[PDF][PDF] IMPLEMENTATION OF BLOCK-CHAIN TECHNOLOGY FOR STUDENT DATABASE IN JAVA PLATFORM;LA Kumar, MP Ram, PJ Reddy, BP Kumar ; ripublication.com;;"… In this paper, we are going to integrate the Oracle database to implement Block Chain … of this project

is to use basic concepts of the implementation behind the Blockchain and similar digital ledger

techniques in JAVA platform and beyond its application to crypto-currency …";Autres articles;;[PDF] ripublication.com;http://www.ripublication.com/ijaerspl2019/ijaerv14n6spl_01.pdf;;"""date"",""2019-04-18T12:37:56Z""
""pdf:PDFVersion"",""1.5""
""xmp:CreatorTool"",""MicrosoftÂŽ Word 2013""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""MicrosoftÂŽ Word 2013""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""xmp:CreateDate"",""2019-04-02T17:57:43Z""
""modified"",""2019-04-18T12:37:56Z""
""pdf:hasMarkedContent"",""true""
""xmp:ModifyDate"",""2019-04-18T18:07:56Z""
""pdf:docinfo:creator"",""admin""
""meta:author"",""admin""
""meta:creation-date"",""2019-04-02T12:27:43Z""
""created"",""2019-04-02T12:27:43Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-04-02T12:27:43Z""
""resourceName"",""ijaerv14n6spl_01.pdf""
""Author"",""admin""
""producer"",""MicrosoftÂŽ Word 2013""
""pdf:docinfo:producer"",""MicrosoftÂŽ Word 2013""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0""
""access_permission:modify_annotations"",""true""
""dc:creator"",""admin""
""dcterms:created"",""2019-04-02T12:27:43Z""
""Last-Modified"",""2019-04-18T12:37:56Z""
""dcterms:modified"",""2019-04-18T12:37:56Z""
""xmpMM:DocumentID"",""uuid:887bd82f-ec54-4ec6-9d5a-a29d6fa952f6""
""Last-Save-Date"",""2019-04-18T12:37:56Z""
""pdf:docinfo:modified"",""2019-04-18T12:37:56Z""
""meta:save-date"",""2019-04-18T12:37:56Z""
""Content-Length"",""820343""
""Content-Type"",""application/pdf""
""xmp:MetadataDate"",""2019-04-18T18:07:56Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""admin""
""dc:language"",""en-US""
""pdf:producer"",""MicrosoftÂŽ Word 2013""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""4""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""3886"",""3749"",""3343"",""3439""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-04-02T12:27:43Z""
";https://scholar.google.com/scholar?start=570&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094572-782;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Securely trading unverifiable information without trust;Y Kong, Y Ma, Y Wu ; arXiv preprint arXiv:1903.07379, 2019  arxiv.org;;"… 2 Related work Decentralized prediction market With the bloom of researches on blockchain,

decentralized information trading platforms are developed on chain [31, 35, 1, 39], mostly

addressing the decen- tralization of prediction market … realizes smart contract on blockchain …";Cité 2 fois;Les 2 versions;[PDF] arxiv.org;https://arxiv.org/pdf/1903.07379;;"""date"",""2019-03-19T01:10:48Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2019-03-19T01:10:48Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016) kpathsea version 6.2.2""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2019-03-19T01:10:48Z""
""created"",""2019-03-19T01:10:48Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-03-19T01:10:48Z""
""resourceName"",""1903.07379""
""Author"",""""
""producer"",""pdfTeX-1.40.17""
""pdf:docinfo:producer"",""pdfTeX-1.40.17""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""2"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""1"",""0"",""0"",""0"",""0"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2019-03-19T01:10:48Z""
""Last-Modified"",""2019-03-19T01:10:48Z""
""dcterms:modified"",""2019-03-19T01:10:48Z""
""title"",""""
""Last-Save-Date"",""2019-03-19T01:10:48Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2019-03-19T01:10:48Z""
""meta:save-date"",""2019-03-19T01:10:48Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016) kpathsea version 6.2.2""
""Content-Length"",""1209017""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""29""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""2838"",""3273"",""2727"",""2222"",""2134"",""2218"",""2376"",""2510"",""1427"",""2464"",""1662"",""1337"",""2682"",""2045"",""2146"",""3023"",""2485"",""2305"",""2634"",""2414"",""959"",""1992"",""1306"",""2188"",""2475"",""1882"",""2492"",""2311"",""156""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-03-19T01:10:48Z""
";https://scholar.google.com/scholar?start=600&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094619-981;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Blockchain Enabled Distributed Data Management-A Vision;F Baig, F Wang ; 2019 IEEE 35th International Conference on …, 2019  ieeexplore.ieee.org;;"… Blockchain has gained much attention in recent academic and research works not only in

crypto-currency but … Oracle Local WL Local Planing Local Index … We presented an overview of

blockchain based transaction processing, dis- cussed its limitations and proposed possible …";Cité 5 fois;Les 4 versions;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/8743499/8750905/08750909.pdf?casa_token=q5j-QR9F0TMAAAAA:IYH9NG9r7LuQT6lvkLOq8vqz9eCHtDLqKa3rWnDUGA7Krk0YBxxNHY4H7V8f0-Yy9QIG6kJN8uU;;"""og:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""twitter:title"",""Blockchain Enabled Distributed Data Management - A Vision""
""twitter:card"",""summary""
""Description"",""Blockchain has gained much attention in recent academic and research works not only in crypto-currency but also in many other fields such as supply chain, healt""
""og:title"",""Blockchain Enabled Distributed Data Management - A Vision""
""resourceName"",""08750909.pdf""
""language"",""en""
""title"",""Blockchain Enabled Distributed Data Management - A Vision | IEEE Conference Publication | IEEE Xplore""
""og:description"",""Blockchain has gained much attention in recent academic and research works not only in crypto-currency but also in many other fields such as supply chain, health, storage etc. The application of blockchain in data management domain, however, is mostly geared towards the aspect of security and immutability. In this paper we propose integrating blockchain with distributed data management and study some open challenges and assumptions in doing so. We claim that, from data management perspective, blockchain's ability to handle unequal participants is more important than security and immutability. Finally, we propose possible ideas to integrate blockchain into distributed data transaction and management workflows to design a globally consistent data store ensuring availability guarantees along with support for unifying heterogeneous data backends.""
""twitter:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-UA-Compatible"",""IE=Edge""
""viewport"",""width=device-width, initial-scale=1.0""
""dc:title"",""Blockchain Enabled Distributed Data Management - A Vision | IEEE Conference Publication | IEEE Xplore""
""twitter:description"",""Blockchain has gained much attention in recent academic and research works not only in crypto-currency but also in many other fields such as supply chain, health, storage etc. The application of blockchain in data management domain, however, is mostly geared towards the aspect of security and immutability. In this paper we propose integrating blockchain with distributed data management and study some open challenges and assumptions in doing so. We claim that, from data management perspective, blockchain's ability to handle unequal participants is more important than security and immutability. Finally, we propose possible ideas to integrate blockchain into distributed data transaction and management workflows to design a globally consistent data store ensuring availability guarantees along with support for unifying heterogeneous data backends.""
""Content-Encoding"",""UTF-8""
""Content-Type-Hint"",""text/html; charset=utf-8""
""Content-Length"",""40052""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=800&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094553-701;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[PDF][PDF] Beyond cryptocurrencies: financial applications of blockchain technology;M Booyens ;2019 ujcontent.uj.ac.za;;"… distributed on a blockchain. Ecosystem An open social system of organisational fields that consist

of directly … facilitates the activity by providing authentication and guarantee services.

Cryptocurrency A digital representation of value that can be digitally traded and functions …";Autres articles;Version HTML;[PDF] uj.ac.za;https://ujcontent.uj.ac.za/vital/access/services/Download/uj:34936/SOURCE1;;"""date"",""2020-06-08T09:14:32Z""
""pdf:PDFVersion"",""1.7""
""xmp:CreatorTool"",""MicrosoftÂŽ Word for Office 365""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""language"",""en""
""dc:format"",""application/pdf; version=1.7""
""pdf:docinfo:creator_tool"",""MicrosoftÂŽ Word for Office 365""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""xmp:CreateDate"",""2019-10-30T19:32:23Z""
""modified"",""2020-06-08T09:14:32Z""
""pdf:hasMarkedContent"",""true""
""xmp:ModifyDate"",""2020-06-08T11:14:32Z""
""pdf:docinfo:creator"",""elton mpinyuri""
""meta:author"",""elton mpinyuri""
""meta:creation-date"",""2019-10-30T17:32:23Z""
""created"",""2019-10-30T17:32:23Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-10-30T17:32:23Z""
""resourceName"",""SOURCE1""
""Author"",""elton mpinyuri""
""producer"",""MicrosoftÂŽ Word for Office 365""
""pdf:docinfo:producer"",""MicrosoftÂŽ Word for Office 365""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""access_permission:modify_annotations"",""true""
""dc:creator"",""elton mpinyuri""
""dcterms:created"",""2019-10-30T17:32:23Z""
""Last-Modified"",""2020-06-08T09:14:32Z""
""dcterms:modified"",""2020-06-08T09:14:32Z""
""xmpMM:DocumentID"",""uuid:1D40A22B-F133-4164-8DE3-D4E2F569B7EE""
""Last-Save-Date"",""2020-06-08T09:14:32Z""
""pdf:docinfo:modified"",""2020-06-08T09:14:32Z""
""meta:save-date"",""2020-06-08T09:14:32Z""
""Content-Length"",""3769528""
""Content-Type"",""application/pdf""
""xmp:MetadataDate"",""2020-06-08T11:14:32Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""elton mpinyuri""
""dc:language"",""en-US""
""pdf:producer"",""MicrosoftÂŽ Word for Office 365""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""89""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""761"",""379"",""422"",""910"",""3179"",""3180"",""2765"",""2284"",""1566"",""682"",""565"",""2891"",""2708"",""2671"",""2685"",""2546"",""758"",""2668"",""2742"",""2814"",""2760"",""2694"",""2858"",""2979"",""2101"",""1888"",""2792"",""2608"",""2768"",""2979"",""2246"",""1649"",""2791"",""2998"",""2790"",""2604"",""2720"",""2737"",""2534"",""1554"",""963"",""2288"",""2179"",""2309"",""2829"",""2699"",""2471"",""2723"",""2946"",""1934"",""2607"",""2726"",""2664"",""2698"",""2485"",""2790"",""186"",""2715"",""2637"",""2860"",""2709"",""2267"",""2983"",""2877"",""742"",""2516"",""2609"",""2649"",""2852"",""3045"",""2863"",""2787"",""2866"",""2625"",""2925"",""2763"",""2625"",""1937"",""2738"",""2116"",""2444"",""2644"",""2662"",""2540"",""2598"",""2630"",""2358"",""2527"",""2190""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-10-30T17:32:23Z""
";https://scholar.google.com/scholar?start=520&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094658-1160;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Efficient verifiable delay functions;B Wesolowski ; Annual International Conference on the Theory and …, 2019  Springer;;"… Watermarking consists in tying a proof to the evaluator's identity; in a blockchain setting, this allows

to give credit (and a reward) to the party who spent time and resources evaluating … (\mathcal

B^{\mathcal O}(x)\) outputs a value \(y\), where \(\mathcal O\) is an oracle that outputs …";Cité 102 fois;Les 7 versions;[PDF] core.ac.uk;https://core.ac.uk/download/pdf/301632250.pdf;;"""date"",""2019-04-05T08:55:14Z""
""pdf:PDFVersion"",""1.6""
""xmp:CreatorTool"",""Springer""
""pdf:docinfo:title"",""Efficient Verifiable Delay Functions""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""Advances in Cryptology – EUROCRYPT 2019, doi:10.1007/978-3-030-17659-4_13""
""pdfa:PDFVersion"",""A-2b""
""xmpMM:History:Action"",""converted"",""converted""
""language"",""en""
""dc:format"",""application/pdf; version=""""A-2b"""""",""application/pdf; version=1.6""
""pdf:docinfo:custom:robots"",""noindex""
""pdf:docinfo:creator_tool"",""Springer""
""access_permission:fill_in_form"",""true""
""xmpMM:History:When"",""2019-04-05T14:24:13Z"",""2019-04-05T14:25:14Z""
""pdf:encrypted"",""false""
""dc:title"",""Efficient Verifiable Delay Functions""
""xmp:CreateDate"",""2019-04-05T14:23:18Z""
""modified"",""2019-04-05T08:55:14Z""
""cp:subject"",""Advances in Cryptology – EUROCRYPT 2019, doi:10.1007/978-3-030-17659-4_13""
""xmpMM:History:SoftwareAgent"",""pdfToolbox"",""pdfToolbox""
""pdf:docinfo:custom:CrossMarkDomains[1]"",""springer.com""
""robots"",""noindex""
""pdf:docinfo:subject"",""Advances in Cryptology – EUROCRYPT 2019, doi:10.1007/978-3-030-17659-4_13""
""pdf:hasMarkedContent"",""false""
""xmpMM:History:InstanceID"",""uuid:fe7f1fb7-c760-44d1-b960-aeae03097c58"",""uuid:b05d5b32-c6ab-4e2c-a2a0-6d12e5325f6a""
""xmp:ModifyDate"",""2019-04-05T14:25:14Z""
""pdf:docinfo:creator"",""Benjamin Wesolowski ""
""meta:author"",""Benjamin Wesolowski ""
""meta:creation-date"",""2019-04-05T08:53:18Z""
""pdf:docinfo:custom:CrossmarkMajorVersionDate"",""2010-04-23""
""created"",""2019-04-05T08:53:18Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-04-05T08:53:18Z""
""resourceName"",""301632250.pdf""
""pdfaid:part"",""2""
""pdf:docinfo:custom:CrossMarkDomains[2]"",""springerlink.com""
""pdf:docinfo:custom:doi"",""10.1007/978-3-030-17659-4_13""
""pdf:docinfo:custom:CrossmarkDomainExclusive"",""true""
""Author"",""Benjamin Wesolowski ""
""CrossmarkDomainExclusive"",""true""
""doi"",""10.1007/978-3-030-17659-4_13""
""pdf:unmappedUnicodeCharsPerPage"",""2"",""0"",""0"",""4"",""2"",""14"",""0"",""6"",""0"",""19"",""31"",""33"",""32"",""22"",""12"",""0"",""10"",""9"",""30"",""28"",""27"",""17"",""3"",""9"",""15"",""4"",""0"",""0"",""0""
""dc:description"",""Advances in Cryptology – EUROCRYPT 2019, doi:10.1007/978-3-030-17659-4_13""
""access_permission:modify_annotations"",""true""
""dc:creator"",""Benjamin Wesolowski ""
""description"",""Advances in Cryptology – EUROCRYPT 2019, doi:10.1007/978-3-030-17659-4_13""
""dcterms:created"",""2019-04-05T08:53:18Z""
""Last-Modified"",""2019-04-05T08:55:14Z""
""dcterms:modified"",""2019-04-05T08:55:14Z""
""title"",""Efficient Verifiable Delay Functions""
""xmpMM:DocumentID"",""uuid:3ac0e2fa-8910-44c6-9925-52e50eedc393""
""Last-Save-Date"",""2019-04-05T08:55:14Z""
""CrossMarkDomains[1]"",""springer.com""
""pdf:docinfo:modified"",""2019-04-05T08:55:14Z""
""meta:save-date"",""2019-04-05T08:55:14Z""
""Content-Length"",""504480""
""Content-Type"",""application/pdf""
""xmp:MetadataDate"",""2019-04-05T14:25:14Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Benjamin Wesolowski ""
""pdfaid:conformance"",""B""
""dc:language"",""EN""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""29""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""2320"",""2402"",""2652"",""2694"",""2331"",""2371"",""2301"",""1960"",""2517"",""2511"",""1709"",""1229"",""1685"",""1057"",""2524"",""2039"",""2361"",""2323"",""2186"",""1818"",""1984"",""2657"",""2526"",""1891"",""2080"",""2518"",""2709"",""2628"",""1139""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""CrossMarkDomains[2]"",""springerlink.com""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-04-05T08:53:18Z""
""CrossmarkMajorVersionDate"",""2010-04-23""
";https://scholar.google.com/scholar?start=970&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094619-987;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Supporting reuse of smart contracts through service orientation and assisted development;L Guida, F Daniel ; 2019 IEEE International Conference on …, 2019  ieeexplore.ieee.org;;"… for example to decide whether to release a given amount of cryptocurrency upon the … The paper

specifically focuses on Ethereum, the most used blockchain platform for smart contracts, and

on … contract inherited to access Oraclize (http: //www.oraclize.it), an oracle service with …";Cité 7 fois;Les 5 versions;[PDF] floriandaniel.it;http://www.floriandaniel.it/papers/GuidaDappCon2019.pdf;;"""date"",""2019-01-21T09:08:52Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.5""
""xmp:CreatorTool"",""TeX""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dcterms:created"",""2019-01-21T09:08:52Z""
""language"",""en""
""Last-Modified"",""2019-01-21T09:08:52Z""
""dcterms:modified"",""2019-01-21T09:08:52Z""
""dc:format"",""application/pdf; version=1.5""
""Last-Save-Date"",""2019-01-21T09:08:52Z""
""pdf:docinfo:creator_tool"",""TeX""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2019-01-21T09:08:52Z""
""meta:save-date"",""2019-01-21T09:08:52Z""
""pdf:encrypted"",""false""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017) kpathsea version 6.2.3""
""modified"",""2019-01-21T09:08:52Z""
""Content-Length"",""1354605""
""pdf:hasMarkedContent"",""false""
""Content-Type"",""application/pdf""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017) kpathsea version 6.2.3""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""trapped"",""False""
""meta:creation-date"",""2019-01-21T09:08:52Z""
""created"",""2019-01-21T09:08:52Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""10""
""Creation-Date"",""2019-01-21T09:08:52Z""
""resourceName"",""GuidaDappCon2019.pdf""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""4769"",""5181"",""4936"",""2827"",""4629"",""3071"",""3034"",""3007"",""3924"",""6213""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""producer"",""pdfTeX-1.40.18""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""pdfTeX-1.40.18""
""pdf:docinfo:created"",""2019-01-21T09:08:52Z""
";https://scholar.google.com/scholar?start=800&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094537-632;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Wenzel Pilar von Pilchau Organic Computing Group, Universität Augsburg, Augsburg, Germany;W Pilar;von  Organic Computing: Doctoral Dissertation …, 2019  books.google.com;;"… Oracles fill this void by watching the Blockchain for events and respond to them by

publishing the results of a query back to the contract … Technically, an oracle is a smart

contract which is fed from an external service with the suitable data …";Autres articles;;null;;;;https://scholar.google.com/scholar?start=450&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094656-1150;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Uncheatable Machine Learning Inference;M Canim, A Kundu, J Payne ; arXiv preprint arXiv:1908.03270, 2019  arxiv.org;;"… Clients who desire a verification of a model M send requests with tokens to the chain to receive

verified performance metrics on M, and oracles that cast votes on performance metrics of M which

are in the majority are rewarded with tokens. The blockchain is not open to the …";Autres articles;;[PDF] arxiv.org;https://arxiv.org/pdf/1908.03270;;"""date"",""2019-08-12T00:34:42Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2019-08-12T00:34:42Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016) kpathsea version 6.2.2""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2019-08-12T00:34:42Z""
""created"",""2019-08-12T00:34:42Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-08-12T00:34:42Z""
""resourceName"",""1908.03270""
""Author"",""""
""producer"",""pdfTeX-1.40.17""
""pdf:docinfo:producer"",""pdfTeX-1.40.17""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""6"",""0"",""2"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2019-08-12T00:34:42Z""
""Last-Modified"",""2019-08-12T00:34:42Z""
""dcterms:modified"",""2019-08-12T00:34:42Z""
""title"",""""
""Last-Save-Date"",""2019-08-12T00:34:42Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2019-08-12T00:34:42Z""
""meta:save-date"",""2019-08-12T00:34:42Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016) kpathsea version 6.2.2""
""Content-Length"",""2040668""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""6""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""4223"",""4558"",""4955"",""2711"",""3916"",""3547""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-08-12T00:34:42Z""
";https://scholar.google.com/scholar?start=960&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094558-726;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Citizens Vote to Act: Smart contracts for the management of water resources in smart cities;A Bracciali, I Chatzigiannakis, A Vitaletti… ; 2019 First …, 2019  ieeexplore.ieee.org;;"… REFERENCES [1] The provabletm blockchain oracle for modern dapps. https://provable. xyz/,

2019 … [8] Chris Dannen. Introducing Ethereum and Solidity: Foundations of Cryptocurrency and

Blockchain Programming for Beginners. Apress, Berkely, CA, USA, 1st edition, 2017 …";Cité 1 fois;Les 5 versions;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/8933294/8938028/08938093.pdf?casa_token=GEKt9khpZbkAAAAA:dD8PN8M-izwziRftrj7QXfji_QFHuSrHPQmhQ-sDZYlXB34fmJa8sQK3cGKVA7e2LQFYaSKrJB0;;"""og:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""twitter:title"",""Citizens Vote to Act: smart contracts for the management of water resources in smart cities""
""twitter:card"",""summary""
""Description"",""Smart cities leverage Information and Communication Technologies (ICTs) to enhance the quality of urban services. However, it is nowadays clear that the success""
""og:title"",""Citizens Vote to Act: smart contracts for the management of water resources in smart cities""
""resourceName"",""08938093.pdf""
""language"",""en""
""title"",""Citizens Vote to Act: smart contracts for the management of water resources in smart cities | IEEE Conference Publication | IEEE Xplore""
""og:description"",""Smart cities leverage Information and Communication Technologies (ICTs) to enhance the quality of urban services. However, it is nowadays clear that the success of a smart city largely depends on the level of engagement of its citizens. In this paper we explore to what extent disruptive blockchain technologies can be used to incentivise the democratic participation of citizen. The investigated approach extends the standard IoT cycle 1) sense data, 2) cloudify and elaborate them, and 3) push information to the users. Here, the user takes an active role by means of data-informed votes on policies, therefore influencing behaviours. We illustrate such an approach by means of a proof-of-concept decentralised application (dApp) supporting the negotiation of polices for the management of urban water resources. The dApp consists of a smart contract that manages the execution of other smart contracts (the policies) according to the data-driven choices of the community. This use case demonstrates how suitably blockchain technologies can support fair and safe access to data and user engagement in smart cities.""
""twitter:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-UA-Compatible"",""IE=Edge""
""viewport"",""width=device-width, initial-scale=1.0""
""dc:title"",""Citizens Vote to Act: smart contracts for the management of water resources in smart cities | IEEE Conference Publication | IEEE Xplore""
""twitter:description"",""Smart cities leverage Information and Communication Technologies (ICTs) to enhance the quality of urban services. However, it is nowadays clear that the success of a smart city largely depends on the level of engagement of its citizens. In this paper we explore to what extent disruptive blockchain technologies can be used to incentivise the democratic participation of citizen. The investigated approach extends the standard IoT cycle 1) sense data, 2) cloudify and elaborate them, and 3) push information to the users. Here, the user takes an active role by means of data-informed votes on policies, therefore influencing behaviours. We illustrate such an approach by means of a proof-of-concept decentralised application (dApp) supporting the negotiation of polices for the management of urban water resources. The dApp consists of a smart contract that manages the execution of other smart contracts (the policies) according to the data-driven choices of the community. This use case demonstrates how suitably blockchain technologies can support fair and safe access to data and user engagement in smart cities.""
""Content-Encoding"",""UTF-8""
""Content-Type-Hint"",""text/html; charset=utf-8""
""Content-Length"",""41427""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=540&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094616-972;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Decentralizing inner-product functional encryption;M Abdalla, F Benhamouda, M Kohlweiss… ; … Workshop on Public Key …, 2019  Springer;;"… (CRYPTO 2018) and Chotard et al … 1, where the oracles are defined as: Corruption oracle

\(\mathsf {QCor}(i)\): Outputs the encryption key \(\mathsf {sk}_i\) of slot i. We denote by

\(\mathcal {CS}\) the set of corrupted slots at the end of the experiment …";Cité 27 fois;Les 10 versions;[PDF] iacr.org;https://eprint.iacr.org/2019/020.pdf;;"""date"",""2019-01-07T23:38:35Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""Decentralizing Inner-Product  Functional Encryption""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""Decentralizing Inner-Product  Functional Encryption""
""modified"",""2019-01-07T23:38:35Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""Michel Abdalla, Fabrice Benhamouda, Markulf Kolhweiss, and Hendrik Waldner""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016) kpathsea version 6.2.2""
""meta:author"",""Michel Abdalla, Fabrice Benhamouda, Markulf Kolhweiss, and Hendrik Waldner""
""trapped"",""False""
""meta:creation-date"",""2019-01-07T23:38:35Z""
""created"",""2019-01-07T23:38:35Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-01-07T23:38:35Z""
""resourceName"",""020.pdf""
""Author"",""Michel Abdalla, Fabrice Benhamouda, Markulf Kolhweiss, and Hendrik Waldner""
""producer"",""pdfTeX-1.40.17""
""pdf:docinfo:producer"",""pdfTeX-1.40.17""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""8"",""7"",""15"",""7"",""5"",""14"",""14"",""7"",""6"",""9"",""8"",""43"",""41"",""7"",""40"",""25"",""13"",""17"",""46"",""20"",""6"",""9"",""6"",""9"",""19"",""17"",""16"",""0"",""0"",""16"",""54"",""14"",""33"",""24"",""19"",""27"",""56"",""57"",""69"",""56"",""22""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""Michel Abdalla, Fabrice Benhamouda, Markulf Kolhweiss, and Hendrik Waldner""
""dcterms:created"",""2019-01-07T23:38:35Z""
""Last-Modified"",""2019-01-07T23:38:35Z""
""dcterms:modified"",""2019-01-07T23:38:35Z""
""title"",""Decentralizing Inner-Product  Functional Encryption""
""Last-Save-Date"",""2019-01-07T23:38:35Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2019-01-07T23:38:35Z""
""meta:save-date"",""2019-01-07T23:38:35Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016) kpathsea version 6.2.2""
""Content-Length"",""762977""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Michel Abdalla, Fabrice Benhamouda, Markulf Kolhweiss, and Hendrik Waldner""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""44""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""1434"",""1752"",""2825"",""2643"",""2337"",""2740"",""2669"",""2599"",""2104"",""2470"",""1764"",""2295"",""1621"",""1760"",""1441"",""2158"",""2327"",""1686"",""2045"",""1392"",""1640"",""1697"",""2108"",""1960"",""2061"",""796"",""1906"",""2101"",""2008"",""1765"",""2639"",""169"",""1345"",""1768"",""1420"",""1009"",""1245"",""2004"",""2023"",""1065"",""1032"",""1949"",""2432"",""742""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-01-07T23:38:35Z""
";https://scholar.google.com/scholar?start=790&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094607-932;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Refinement and verification of CBC casper;R Nakamura, T Jimba, D Harz ; … Conference on Blockchain …, 2019  ieeexplore.ieee.org;;"… proof of safety in this abstract form and elaborate on the safety of blockchain consensus protocols …

and properties, CBC Casper implements a general decision mechanisms called safety oracle

so that … Different types of safety oracles are proposed including the clique oracle [18] …";Cité 5 fois;Les 5 versions;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/8782665/8787545/08787558.pdf?casa_token=OCFpFmLJ3MQAAAAA:RSkyCNFrf6EebY5CtSH4R_CKi3hLxsQ3M0izUnFDIgx3XKahoMolt50Oe2QGqSm7V8HOtWig7G4;;"""og:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""twitter:title"",""Refinement and Verification of CBC Casper""
""twitter:card"",""summary""
""Description"",""Decentralised ledgers are a prime application case for consensus protocols. Changing sets of validators have to agree on a set of transactions in an asynchronou""
""og:title"",""Refinement and Verification of CBC Casper""
""resourceName"",""08787558.pdf""
""language"",""en""
""title"",""Refinement and Verification of CBC Casper | IEEE Conference Publication | IEEE Xplore""
""og:description"",""Decentralised ledgers are a prime application case for consensus protocols. Changing sets of validators have to agree on a set of transactions in an asynchronous network and in the presence of Byzantine behaviour. Major research efforts focus on creating consensus protocols under such conditions, with proof-of-stake (PoS) representing a promising candidate. PoS aims to reduce the waste of energy inherent to proof-of-work (PoW) consensus protocols. However, a significant challenge is to get PoS protocols """"right"""", i.e. ensure that they are secure w.r.t. safety and liveness. The """"Correct-by-Construction"""" (CBC) Casper approach by the Ethereum project employs pen-and-paper proofs to ensure its security. CBC Casper is a framework to define consensus protocols and aims to prove safety without loss of abstractness. Each member of the CBC Casper family of protocols is defined by five parameters. CBC Casper models the protocol by a state of each validator and messages sent by validators. Each validator can transition its state using messages by other validators that include their current consensus value and a justification (i.e. their previous messages). We extend CBC Casper in three ways. First, we summarise the research of CBC Casper and extend the definitions of safety and liveness properties. To this end, we discuss an instance of CBC Casper called Casper The Friendly GHOST (TFG), a consensus protocol using a variant of the GHOST fork-choice rule. Second, we refine the properties of messages and states in CBC Casper and give a definition of blockchain safety for Casper TFG. Third, we formally verify the CBC Casper framework together with our refined message and state properties as well as our blockchain safety definition in the Isabelle/HOL proof assistant.""
""twitter:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-UA-Compatible"",""IE=Edge""
""viewport"",""width=device-width, initial-scale=1.0""
""dc:title"",""Refinement and Verification of CBC Casper | IEEE Conference Publication | IEEE Xplore""
""twitter:description"",""Decentralised ledgers are a prime application case for consensus protocols. Changing sets of validators have to agree on a set of transactions in an asynchronous network and in the presence of Byzantine behaviour. Major research efforts focus on creating consensus protocols under such conditions, with proof-of-stake (PoS) representing a promising candidate. PoS aims to reduce the waste of energy inherent to proof-of-work (PoW) consensus protocols. However, a significant challenge is to get PoS protocols """"right"""", i.e. ensure that they are secure w.r.t. safety and liveness. The """"Correct-by-Construction"""" (CBC) Casper approach by the Ethereum project employs pen-and-paper proofs to ensure its security. CBC Casper is a framework to define consensus protocols and aims to prove safety without loss of abstractness. Each member of the CBC Casper family of protocols is defined by five parameters. CBC Casper models the protocol by a state of each validator and messages sent by validators. Each validator can transition its state using messages by other validators that include their current consensus value and a justification (i.e. their previous messages). We extend CBC Casper in three ways. First, we summarise the research of CBC Casper and extend the definitions of safety and liveness properties. To this end, we discuss an instance of CBC Casper called Casper The Friendly GHOST (TFG), a consensus protocol using a variant of the GHOST fork-choice rule. Second, we refine the properties of messages and states in CBC Casper and give a definition of blockchain safety for Casper TFG. Third, we formally verify the CBC Casper framework together with our refined message and state properties as well as our blockchain safety definition in the Isabelle/HOL proof assistant.""
""Content-Encoding"",""UTF-8""
""Content-Type-Hint"",""text/html; charset=utf-8""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=750&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094635-1055;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Sebdb: Semantics empowered blockchain database;Y Zhu, Z Zhang, C Jin, A Zhou… ; 2019 IEEE 35th …, 2019  ieeexplore.ieee.org;;"… Corresponding author. 1www.oracle.com 2https://www.ibm.com/analytics/us/

en/db2 3https://www.mysql.com … Blockchain systems: Blockchain was originally

derived from Bitcoin [6], a decentralized cryptocurrency …";Cité 22 fois;Les 2 versions;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/8725877/8731337/08731416.pdf?casa_token=byX4dHBYoioAAAAA:nh7NHe9VdiLgdIo-Xc1HR-A7IycYw_c9_eELG8NMkeKcUyDVZt8h0jrU1JQAE7JgFNBtwt9nK9I;;"""og:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""twitter:title"",""SEBDB: Semantics Empowered BlockChain DataBase""
""twitter:card"",""summary""
""Description"",""Blockchain has been adopted in many applications to construct trust among multiple participants, such as supply chain management, digital assets transfer, phila""
""og:title"",""SEBDB: Semantics Empowered BlockChain DataBase""
""resourceName"",""08731416.pdf""
""language"",""en""
""title"",""SEBDB: Semantics Empowered BlockChain DataBase | IEEE Conference Publication | IEEE Xplore""
""og:description"",""Blockchain has been adopted in many applications to construct trust among multiple participants, such as supply chain management, digital assets transfer, philanthropy, etc. Blockchain platforms are often used as decentralized databases. However, existing blockchain platforms are far less convenient to use than traditional databases. They are lack of the capability of modelling complex tasks conveniently and efficiently, especially when both on-chain and off-chain data are involved at the same time. In this paper, we propose and implement a novel blockchain database, called SEBDB, which leverages the existing databases' functionality which are optimized for decades. Comparing to existing works, SEBDB is the first platform which considers both useability and scalability. Specifically, first, weaddrelationaldata semantics into blockchain platform, where each transaction is a tuple with multiple attributes in a pre-defined table. Second, we use SQL-like language as the general interface, instead of code-level APIs, to support convenient application development, in which intrinsic operations are re-defined and re-implemented to suit for blockchain platform. Third, as RDBMS has achieved great success in the past decades, our system, though not relying on RDBMS, treats it as an important component. Finally, we define a mini-benchmark to evaluate the performance of the blockchain database. Extensive experiments demonstrate the effectiveness and efficiency of our proposed system.""
""twitter:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-UA-Compatible"",""IE=Edge""
""viewport"",""width=device-width, initial-scale=1.0""
""dc:title"",""SEBDB: Semantics Empowered BlockChain DataBase | IEEE Conference Publication | IEEE Xplore""
""twitter:description"",""Blockchain has been adopted in many applications to construct trust among multiple participants, such as supply chain management, digital assets transfer, philanthropy, etc. Blockchain platforms are often used as decentralized databases. However, existing blockchain platforms are far less convenient to use than traditional databases. They are lack of the capability of modelling complex tasks conveniently and efficiently, especially when both on-chain and off-chain data are involved at the same time. In this paper, we propose and implement a novel blockchain database, called SEBDB, which leverages the existing databases' functionality which are optimized for decades. Comparing to existing works, SEBDB is the first platform which considers both useability and scalability. Specifically, first, weaddrelationaldata semantics into blockchain platform, where each transaction is a tuple with multiple attributes in a pre-defined table. Second, we use SQL-like language as the general interface, instead of code-level APIs, to support convenient application development, in which intrinsic operations are re-defined and re-implemented to suit for blockchain platform. Third, as RDBMS has achieved great success in the past decades, our system, though not relying on RDBMS, treats it as an important component. Finally, we define a mini-benchmark to evaluate the performance of the blockchain database. Extensive experiments demonstrate the effectiveness and efficiency of our proposed system.""
""Content-Encoding"",""UTF-8""
""Content-Type-Hint"",""text/html; charset=utf-8""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=870&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094661-1166;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Accountable Anonymous Credentials;Z Yu, MH Au, R Yang ; Advances in Cyber Security: Principles, Techniques …, 2019  Springer;;"… Early constructions of ring signature schemes are mainly proposed in the random oracle model

[10, 14, 35, 64] via … The spend transaction will be put on the blockchain only if the proof is valid …

Ring signatures: Stronger definitions, and constructions without random oracles …";Cité 1 fois;Les 3 versions;null;;;;https://scholar.google.com/scholar?start=980&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094593-879;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;??????????????;T Ya;Che  ?????????????, 2019  airitilibrary.com;;"… TOP?. Blockchain is the core technology underlying the first decentralized cryptocurrency, Bitcoin,

introduced … knowledge range proof (ZKRP), that has been applied in blockchain-based payments …

of the proposed scheme is rigorously proved in the random oracle model based …";;null;null;;;;https://scholar.google.com/scholar?start=690&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094595-886;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Seedless fruit is the sweetest: Random number generation, revisited;S Coretti, Y Dodis, H Karthikeyan, S Tessaro ; Annual International …, 2019  Springer;;"… CRYPTO 2019: Advances in Cryptology – CRYPTO 2019 pp 205-234 | Cite as … assumption, but

instead carefully modeling what constitutes entropy in the much more realistic, oracle-dependent

setting … a random bit b chosen by the challenger, who offers a set of oracles to the …";Cité 4 fois;Les 3 versions;[PDF] iacr.org;https://eprint.iacr.org/2019/198.pdf;;"""date"",""2019-03-25T17:58:30Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2019-03-25T17:58:30Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.19 (TeX Live 2018) kpathsea version 6.3.0""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2019-03-25T17:58:30Z""
""created"",""2019-03-25T17:58:30Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-03-25T17:58:30Z""
""resourceName"",""198.pdf""
""Author"",""""
""producer"",""pdfTeX-1.40.19""
""pdf:docinfo:producer"",""pdfTeX-1.40.19""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""3"",""0"",""0"",""0"",""0"",""0"",""0"",""11"",""2"",""2"",""9"",""6"",""6"",""3"",""5"",""2"",""0"",""5"",""7"",""30"",""18"",""9"",""10"",""7"",""15"",""0"",""0"",""4"",""13"",""13"",""9"",""48"",""17"",""16"",""7"",""7"",""30"",""72"",""67"",""36"",""11"",""25"",""62"",""41"",""22"",""15"",""10"",""34"",""3"",""19"",""9"",""20"",""37"",""66"",""49"",""36"",""29"",""55"",""36"",""54"",""15"",""19"",""62"",""21"",""0"",""0"",""0"",""0"",""0"",""2"",""23"",""15"",""8"",""26"",""13"",""87"",""41"",""18"",""28"",""9""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2019-03-25T17:58:30Z""
""Last-Modified"",""2019-03-25T17:58:30Z""
""dcterms:modified"",""2019-03-25T17:58:30Z""
""title"",""""
""Last-Save-Date"",""2019-03-25T17:58:30Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2019-03-25T17:58:30Z""
""meta:save-date"",""2019-03-25T17:58:30Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.19 (TeX Live 2018) kpathsea version 6.3.0""
""Content-Length"",""765398""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""85""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""2460"",""2020"",""428"",""3187"",""2920"",""3562"",""3279"",""3215"",""3303"",""3552"",""3048"",""3386"",""2572"",""2334"",""1852"",""1474"",""2340"",""3204"",""2045"",""2827"",""2199"",""2025"",""1711"",""2003"",""1264"",""1911"",""1276"",""1774"",""2514"",""1605"",""2087"",""1134"",""2182"",""1825"",""2138"",""2414"",""1616"",""1531"",""1287"",""2472"",""2406"",""1508"",""1327"",""1159"",""2124"",""1720"",""1952"",""1297"",""1386"",""1725"",""1768"",""1754"",""943"",""2207"",""1431"",""1666"",""2186"",""1398"",""1831"",""1938"",""1805"",""2574"",""1625"",""2081"",""2046"",""1555"",""1642"",""1843"",""1526"",""2754"",""2564"",""2556"",""750"",""2981"",""2065"",""1662"",""2041"",""2058"",""1902"",""1943"",""1743"",""2103"",""1593"",""1781"",""1695""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-03-25T17:58:30Z""
";https://scholar.google.com/scholar?start=700&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094551-699;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[PDF][PDF] Money Supply for a Utility Cryptocurrency;A Díaz, GF de;Córdobab, LA Puchc 2019 cryptoeconomics.genexies.net;;"… sense. The state of the ledger is maintained by the blockchain and the process of price-setting

may … Tm Exchange B uys crypto Pa ys fi a t … q0 = 100 coin/€ Sideblock Foundation * ICO (fixes M0) *

Writes Dapps * Writes smart contracts * Sets oracles * Endorses this Yellow Paper …";Autres articles;Version HTML;[PDF] genexies.net;http://cryptoeconomics.genexies.net/ICOresearch.pdf;;"""date"",""2019-03-03T09:44:01Z""
""pdf:unmappedUnicodeCharsPerPage"",""1806"",""2421"",""2650"",""2363"",""1151"",""1987"",""2355"",""1158"",""2253"",""1077"",""1658"",""1840"",""1145"",""1148"",""903"",""1980"",""495"",""1008"",""686"",""743"",""1480"",""1809"",""1025"",""116"",""52"",""54"",""2085"",""2108"",""1519"",""1099""
""pdf:PDFVersion"",""1.5""
""xmp:CreatorTool"",""TeX""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dcterms:created"",""2019-03-03T09:44:01Z""
""language"",""en""
""Last-Modified"",""2019-03-03T09:44:01Z""
""dcterms:modified"",""2019-03-03T09:44:01Z""
""dc:format"",""application/pdf; version=1.5""
""Last-Save-Date"",""2019-03-03T09:44:01Z""
""pdf:docinfo:creator_tool"",""TeX""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2019-03-03T09:44:01Z""
""meta:save-date"",""2019-03-03T09:44:01Z""
""pdf:encrypted"",""false""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017/Debian) kpathsea version 6.2.3""
""modified"",""2019-03-03T09:44:01Z""
""Content-Length"",""534293""
""pdf:hasMarkedContent"",""false""
""Content-Type"",""application/pdf""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017/Debian) kpathsea version 6.2.3""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""trapped"",""False""
""meta:creation-date"",""2019-03-03T09:44:01Z""
""created"",""2019-03-03T09:44:01Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""30""
""Creation-Date"",""2019-03-03T09:44:01Z""
""resourceName"",""ICOresearch.pdf""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""1816"",""2421"",""2650"",""2363"",""1360"",""2018"",""2355"",""1392"",""2266"",""1111"",""1674"",""1972"",""1304"",""1374"",""1075"",""2039"",""495"",""1295"",""861"",""967"",""1554"",""1908"",""1025"",""118"",""52"",""63"",""2111"",""2110"",""1519"",""1099""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""producer"",""pdfTeX-1.40.18""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""pdfTeX-1.40.18""
""pdf:docinfo:created"",""2019-03-03T09:44:01Z""
";https://scholar.google.com/scholar?start=510&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094651-1125;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[HTML][HTML] Decentralized document version control using ethereum blockchain and IPFS;N Nizamuddin, K Salah, MA Azad, J Arshad… ; Computers & Electrical …, 2019  Elsevier;;"… cannot be tampered, and which traditional database systems such as MySQL and Oracle do

not … The DAO was meant to operate like a venture capital fund for crypto and decentralized … platform

and also put limelight on the security of cryptocurrency and Blockchain technology …";Cité 58 fois;Les 7 versions;[HTML] sciencedirect.com;https://www.sciencedirect.com/science/article/pii/S0045790618333093?casa_token=rRzK96GCJFMAAAAA:u5HotJ37H1AF_ZFPCEMVJE4bMOeIJP88-Q3Uwb5UJdcZk1dGgDGODj9eHQqkrb7whYKJddbu;;;https://scholar.google.com/scholar?start=940&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094562-745;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Aplicación basada en blockchain que permita el intercambio de puntos de fidelización entre empresas;F Mato Picardo ;2019 repositorio.comillas.edu;;"… greater than the total value of Bitcoin. For this reason, it is a challenge to try to use the technology

that made possible the birth of the crypto coins, but now with loyalty points. Blockchain technology

consists of a database in the form of a distributed ledger where …";;;[PDF] comillas.edu;https://repositorio.comillas.edu/xmlui/bitstream/handle/11531/35105/TFG%20-%20Mato%20Picardo%2C%20Fernando.pdf?sequence=1;;"""date"",""2019-07-01T09:23:41Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.3""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dcterms:created"",""2019-07-01T09:23:41Z""
""language"",""es""
""Last-Modified"",""2019-07-01T09:23:41Z""
""dcterms:modified"",""2019-07-01T09:23:41Z""
""dc:format"",""application/pdf; version=1.3""
""Last-Save-Date"",""2019-07-01T09:23:41Z""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2019-07-01T09:23:41Z""
""meta:save-date"",""2019-07-01T09:23:41Z""
""pdf:encrypted"",""false""
""modified"",""2019-07-01T09:23:41Z""
""Content-Length"",""2141992""
""pdf:hasMarkedContent"",""false""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""meta:creation-date"",""2019-07-01T09:23:41Z""
""created"",""2019-07-01T09:23:41Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""118""
""Creation-Date"",""2019-07-01T09:23:41Z""
""resourceName"",""TFG%20-%20Mato%20Picardo%2C%20Fernando.pdf""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""284"",""753"",""3372"",""1957"",""282"",""2659"",""2088"",""2760"",""2706"",""2301"",""2719"",""2016"",""2818"",""2682"",""269"",""2726"",""2665"",""2632"",""2352"",""1688"",""2446"",""2545"",""2899"",""2742"",""2853"",""2388"",""2730"",""1707"",""1657"",""2835"",""2994"",""2700"",""2531"",""2780"",""2471"",""2725"",""2793"",""2542"",""2538"",""2734"",""1719"",""2766"",""2701"",""2529"",""2201"",""2253"",""1865"",""2689"",""2653"",""2698"",""2808"",""2745"",""2871"",""2157"",""2618"",""2617"",""2836"",""2647"",""1902"",""1830"",""2712"",""2700"",""2648"",""1874"",""2653"",""2670"",""2540"",""2691"",""2681"",""2530"",""2791"",""2649"",""2760"",""2826"",""2997"",""2473"",""2560"",""1681"",""702"",""568"",""352"",""1414"",""1583"",""2847"",""1143"",""2117"",""2328"",""2326"",""1522"",""1371"",""2734"",""2039"",""1562"",""1782"",""1486"",""2360"",""2772"",""2453"",""1515"",""2095"",""2408"",""2597"",""2623"",""2727"",""2521"",""2718"",""2441"",""2331"",""2465"",""2111"",""2261"",""2510"",""2717"",""2617"",""2091"",""2239"",""2286"",""1232""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""producer"",""iOS Version 12.3.1 (Build 16F203) Quartz PDFContext""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""iOS Version 12.3.1 (Build 16F203) Quartz PDFContext""
""pdf:docinfo:created"",""2019-07-01T09:23:41Z""
";https://scholar.google.com/scholar?start=560&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094544-664;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;An Efficient MQ-based Signature in the QROM;H Furue, DH Duong, T Takagi ; 2019 Seventh International …, 2019  ieeexplore.ieee.org;;"… digital signature scheme secure in the quantum ran- dom oracle model (QROM). SOFIA is

constructed by applying an extended version of the Unruh transform (EUROCRYPT 2015) to

the MQ-based 5-pass identification scheme (IDS) proposed by Sakumoto et al. (CRYPTO 2011 …";Autres articles;;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/8949788/8958293/08958471.pdf?casa_token=NN5GNKpHokYAAAAA:BMF01900WGXQqEXK19H2G8vqfj77GiXPr7Bx6HqWFA8IO-A_uV6M1TWZLEulxlw0FNmU_QXC0Us;;"""og:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""twitter:title"",""An Efficient MQ-Based Signature in the QROM""
""twitter:card"",""summary""
""Description"",""At PKC 2018, Chen et al. proposed SOFIA, the first MQ-based digital signature scheme secure in the quantum random oracle model (QROM). SOFIA is constructed by a""
""og:title"",""An Efficient MQ-Based Signature in the QROM""
""resourceName"",""08958471.pdf""
""language"",""en""
""title"",""An Efficient MQ-Based Signature in the QROM | IEEE Conference Publication | IEEE Xplore""
""og:description"",""At PKC 2018, Chen et al. proposed SOFIA, the first MQ-based digital signature scheme secure in the quantum random oracle model (QROM). SOFIA is constructed by applying an extended version of the Unruh transform (EUROCRYPT 2015) to the MQ-based 5-pass identification scheme (IDS) proposed by Sakumoto et al. (CRYPTO 2011). In this paper, we propose an MQ-based 3-pass IDS with impersonation probability of 1/2 and apply the original version of the Unruh transform to it to obtain a more efficient MQ-based digital signature scheme secure in the QROM. The signature size with our digital signature scheme decreases by about 30% compared with SOFIA.""
""twitter:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-UA-Compatible"",""IE=Edge""
""viewport"",""width=device-width, initial-scale=1.0""
""dc:title"",""An Efficient MQ-Based Signature in the QROM | IEEE Conference Publication | IEEE Xplore""
""twitter:description"",""At PKC 2018, Chen et al. proposed SOFIA, the first MQ-based digital signature scheme secure in the quantum random oracle model (QROM). SOFIA is constructed by applying an extended version of the Unruh transform (EUROCRYPT 2015) to the MQ-based 5-pass identification scheme (IDS) proposed by Sakumoto et al. (CRYPTO 2011). In this paper, we propose an MQ-based 3-pass IDS with impersonation probability of 1/2 and apply the original version of the Unruh transform to it to obtain a more efficient MQ-based digital signature scheme secure in the QROM. The signature size with our digital signature scheme decreases by about 30% compared with SOFIA.""
""Content-Encoding"",""UTF-8""
""Content-Type-Hint"",""text/html; charset=utf-8""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=480&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094630-1032;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Towards automatically penalizing multimedia breaches;EV Mangipudi, K Rao, J Clark… ; 2019 IEEE European …, 2019  ieeexplore.ieee.org;;"… settling intentional or unintentional data breaches with a Bitcoin (or other blockchain) smart

contract … Our APB protocol is a crypto-augmented smart contract system to obtain an

arbitrator-free … 18] and the additional verification step forces the receiver to make oracle queries …";Cité 6 fois;Les 4 versions;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/8790672/8802376/08802429.pdf?casa_token=OFLfuybi3jcAAAAA:uGQVXgkOicFxMUjC1RSJ3iNTjMXPKscUrzD7Dp9U-Afpspw5jNywKmb5ujmuMdudoOX1aELmP9k;;"""og:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""twitter:title"",""Towards Automatically Penalizing Multimedia Breaches (Extended Abstract)""
""twitter:card"",""summary""
""Description"",""This work studies the problem of automatically penalizing intentional or unintentional data breach (APB) by a receiver/custodian receiving confidential data fro""
""og:title"",""Towards Automatically Penalizing Multimedia Breaches (Extended Abstract)""
""resourceName"",""08802429.pdf""
""language"",""en""
""title"",""Towards Automatically Penalizing Multimedia Breaches (Extended Abstract) | IEEE Conference Publication | IEEE Xplore""
""og:description"",""This work studies the problem of automatically penalizing intentional or unintentional data breach (APB) by a receiver/custodian receiving confidential data from a sender. We solve this problem for multimedia data by augmenting a blockchain on-chain smart contract between the sender and receiver with an off-chain cryptographic protocol, such that any significant data breach from the receiver is penalized through a monetary loss. Towards achieving the goal, we use an oblivious transfer scheme when used with a robust watermarking and a claim-or-refund blockchain contract provides the necessary framework to realize the APB protocol in a provably secure manner. In our APB protocol, a public data breach by the receiver leads to her Bitcoin (or other blockchain) private signing key getting revealed to the sender, which allows him to penalize the receiver by claiming the deposit from the claim-or- refund contract. Interestingly, the protocol also ensures that the malicious sender cannot steal the deposit, even as he knows the original multimedia document or releases it in any form.""
""twitter:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-UA-Compatible"",""IE=Edge""
""viewport"",""width=device-width, initial-scale=1.0""
""dc:title"",""Towards Automatically Penalizing Multimedia Breaches (Extended Abstract) | IEEE Conference Publication | IEEE Xplore""
""twitter:description"",""This work studies the problem of automatically penalizing intentional or unintentional data breach (APB) by a receiver/custodian receiving confidential data from a sender. We solve this problem for multimedia data by augmenting a blockchain on-chain smart contract between the sender and receiver with an off-chain cryptographic protocol, such that any significant data breach from the receiver is penalized through a monetary loss. Towards achieving the goal, we use an oblivious transfer scheme when used with a robust watermarking and a claim-or-refund blockchain contract provides the necessary framework to realize the APB protocol in a provably secure manner. In our APB protocol, a public data breach by the receiver leads to her Bitcoin (or other blockchain) private signing key getting revealed to the sender, which allows him to penalize the receiver by claiming the deposit from the claim-or- refund contract. Interestingly, the protocol also ensures that the malicious sender cannot steal the deposit, even as he knows the original multimedia document or releases it in any form.""
""Content-Encoding"",""UTF-8""
""Content-Type-Hint"",""text/html; charset=utf-8""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=850&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094661-1169;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Wissenschaftliche Reihe BWL-Bank–Band 7;A Kahlert, CE Rzepka ;2019 econstor.eu;;"… Dr. Thorsten Wingenroth Alexander Kahlert Potenzialanalyse der Blockchain-Technologie in Bezug

auf das Trade-Finance- Geschäft einer globalen Universalbank Constanze Ellen Rzepka … Page

6. Potenzialanalyse der Blockchain- Technologie in Bezug auf das …";Autres articles;;[PDF] econstor.eu;https://www.econstor.eu/bitstream/10419/198045/1/Schriftenreihe-BWL-Bank-Band-7.pdf;;"""date"",""2021-04-28T09:56:44Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.5""
""xmp:CreatorTool"",""MicrosoftÂŽ Word 2016""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dc:creator"",""Gotzel, Sarah""
""language"",""de""
""dcterms:created"",""2019-05-27T07:01:19Z""
""Last-Modified"",""2021-04-28T09:56:44Z""
""dcterms:modified"",""2021-04-28T09:56:44Z""
""dc:format"",""application/pdf; version=1.5""
""Last-Save-Date"",""2021-04-28T09:56:44Z""
""pdf:docinfo:creator_tool"",""MicrosoftÂŽ Word 2016""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2021-04-28T09:56:44Z""
""meta:save-date"",""2021-04-28T09:56:44Z""
""pdf:encrypted"",""false""
""modified"",""2021-04-28T09:56:44Z""
""Content-Length"",""3280528""
""pdf:hasMarkedContent"",""false""
""Content-Type"",""application/pdf""
""pdf:docinfo:creator"",""Gotzel, Sarah""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Gotzel, Sarah""
""dc:language"",""de-DE""
""meta:author"",""Gotzel, Sarah""
""meta:creation-date"",""2019-05-27T07:01:19Z""
""created"",""2019-05-27T07:01:19Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""197""
""Creation-Date"",""2019-05-27T07:01:19Z""
""resourceName"",""Schriftenreihe-BWL-Bank-Band-7.pdf""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""1717"",""493"",""1045"",""3105"",""643"",""142"",""4453"",""2093"",""1887"",""2840"",""3031"",""2658"",""2818"",""1761"",""2633"",""2290"",""3112"",""2842"",""2651"",""3113"",""2809"",""3125"",""2425"",""1851"",""2677"",""2176"",""2855"",""2920"",""2194"",""2961"",""2767"",""2768"",""2076"",""2732"",""2287"",""1892"",""2880"",""2315"",""2146"",""2908"",""2444"",""2284"",""2305"",""1444"",""3386"",""3085"",""3045"",""3199"",""2546"",""2798"",""3009"",""2916"",""2218"",""2183"",""3133"",""2533"",""2736"",""2824"",""2756"",""3116"",""1761"",""982"",""3119"",""3415"",""3360"",""3227"",""3251"",""3022"",""2703"",""3107"",""3142"",""3123"",""2870"",""2979"",""3443"",""1993"",""2243"",""3041"",""3107"",""3142"",""2891"",""2722"",""3162"",""3284"",""319"",""1603"",""308"",""308"",""309"",""206"",""269"",""170"",""174"",""3388"",""3419"",""3058"",""2785"",""653"",""186"",""3781"",""450"",""3109"",""2482"",""2898"",""3154"",""3319"",""3159"",""3207"",""3229"",""2958"",""1274"",""3387"",""3114"",""3645"",""3451"",""3271"",""3217"",""3184"",""3197"",""2992"",""3269"",""1598"",""2041"",""2882"",""3347"",""3357"",""2627"",""3473"",""3256"",""3419"",""3462"",""3349"",""3450"",""2647"",""831"",""2213"",""2762"",""3002"",""2992"",""3138"",""3402"",""3391"",""3090"",""3174"",""3463"",""3429"",""3196"",""3311"",""3206"",""3127"",""3267"",""2899"",""3439"",""3212"",""2798"",""2961"",""1981"",""1949"",""2061"",""2237"",""2099"",""2364"",""2277"",""1745"",""2086"",""1778"",""1787"",""1935"",""2264"",""3143"",""3478"",""3200"",""3581"",""1950"",""2489"",""2892"",""2808"",""3063"",""3368"",""3170"",""2420"",""2602"",""2702"",""1014"",""2867"",""1720"",""250"",""51"",""47"",""42"",""42"",""42"",""267"",""97"",""255"",""940"",""1299""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""Author"",""Gotzel, Sarah""
""producer"",""MicrosoftŽ Word 2016; modified using iTextŽ 5.1.3 Š2000-2011 1T3XT BVBA""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""MicrosoftŽ Word 2016; modified using iTextŽ 5.1.3 Š2000-2011 1T3XT BVBA""
""pdf:docinfo:created"",""2019-05-27T07:01:19Z""
";https://scholar.google.com/scholar?start=980&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094640-1074;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[LIVRE][B] Fintech: Law and regulation;J Madi ;2019 books.google.com;;"… payments and e-wallets Open banking/APIs Artificial intelligence (AI) and big data Machine

learning Biometrics Robo-advice 7. Blockchain 2. 3. 4 … 4.65 D. UNITED STATES 4.73 1. Overview

4.73 2. New York: the BitLicense regime 4.74 3. Other state cryptocurrency statutes 4.82 …";Cité 7 fois;;null;;;;https://scholar.google.com/scholar?start=890&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094595-883;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;R3 Corda for Architects and Developers;T Travel, D Mohanty ; Springer;;"… Oracles .....70 … DigiCash in 1992, CyberCash in 1994, E-Gold in 1996,

WebMoney in 1998, Liberty Reserve in 2006, and Perfect Money in 2007 were

all crypto or digital … CHAPTER 1 BARTER TO BLOCKCHAIN …";;null;null;;;;https://scholar.google.com/scholar?start=700&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094597-899;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[PDF][PDF] Improved Identity-Based Anonymous Broadcast Encryption with Chosen Ciphertext Security;VC Iwuchukwu, EC Nwokorie, SA Okolie, UM Obi ;2019 pdfs.semanticscholar.org;;"… keys, while it also runs on secured selective chosen ciphertext attacks in random oracle model

[16] … [3] X. Boyen and B. Waters, “Anonymous Hierarchical Identity-Based Encryption (without

random oracles)”, Dwork, C. (ed.): In Advances in Cryptology - CRYPTO 2006, 26th …";Autres articles;;[PDF] semanticscholar.org;https://pdfs.semanticscholar.org/5d02/4665c7f2c034e9402fba9041f0b20cc86ae0.pdf;;"""citation_publication_date"",""2019""
""og:image"",""https://www.semanticscholar.org/img/semantic_scholar_og.png""
""citation_title"",""Improved Identity-Based Anonymous Broadcast Encryption with Chosen Ciphertext Security""
""og:image:width"",""1110""
""twitter:card"",""summary_large_image""
""msapplication-square70x70logo"",""https://cdn.semanticscholar.org/86e6c2539915adc9/img/mstile-70x70.png""
""citation_journal_title"",""""
""description"",""1Lecturer, Department of Computer Science, Federal University of Technology, Owerri, Nigeria 2Senior Lecturer, Department of Computer Science, Federal University of Technology, Owerri, Nigeria 3Lecturer, Department of Computer Science, Federal University of Technology, Owerri, Nigeria 4Lecturer, Department of Computer Science, Federal University of Technology, Owerri, Nigeria ---------------------------------------------------------------------***---------------------------------------------------------------------Abstract Anonymous receiver encryption is an important cryptographic primitive. It allows a sender to use the public identities of multiple receivers to encrypt messages so that only the authorized receivers or a privileged set of users can decrypt the messages, and the identities of the receivers are not revealed. The increasing need to protect users’ identity in an era of improved digital technology and cyber crime is very crucial. As such, the idea of anonymity in all fields of modern cryptography is given due attention so as to improve users’ experience and security. Generally, in broadcast encryption schemes, a broadcaster first chooses a set S of users who will be able to decrypt broadcast messages as authorized users’ set and encrypts a computed secret broadcast as a part of a ciphertext. Pay televisions use the Conditional Access System (CAS) which is the bedrock of the anonymous broadcasting. This work will improve the Anonymous Identity-Based Encryption Schemes using security based on bilinear groups and decisional bilinear Diffie-Hellman problem in improving the ciphertext security. The methodology used is the Objectoriented System Analysis and Design Methodology and a design that focuses on reuses. Implementation of work was done using PHP programming language and Heidi Structured Query Language (HeidiSQL) in the Laragon platform as the backend.""
""msapplication-wide310x150logo"",""https://cdn.semanticscholar.org/86e6c2539915adc9/img/mstile-310x150.png""
""language"",""en""
""title"",""[PDF] Improved Identity-Based Anonymous Broadcast Encryption with Chosen Ciphertext Security | Semantic Scholar""
""og:description"",""1Lecturer, Department of Computer Science, Federal University of Technology, Owerri, Nigeria 2Senior Lecturer, Department of Computer Science, Federal University of Technology, Owerri, Nigeria 3Lecturer, Department of Computer Science, Federal University of Technology, Owerri, Nigeria 4Lecturer, Department of Computer Science, Federal University of Technology, Owerri, Nigeria ---------------------------------------------------------------------***---------------------------------------------------------------------Abstract Anonymous receiver encryption is an important cryptographic primitive. It allows a sender to use the public identities of multiple receivers to encrypt messages so that only the authorized receivers or a privileged set of users can decrypt the messages, and the identities of the receivers are not revealed. The increasing need to protect users’ identity in an era of improved digital technology and cyber crime is very crucial. As such, the idea of anonymity in all fields of modern cryptography is given due attention so as to improve users’ experience and security. Generally, in broadcast encryption schemes, a broadcaster first chooses a set S of users who will be able to decrypt broadcast messages as authorized users’ set and encrypts a computed secret broadcast as a part of a ciphertext. Pay televisions use the Conditional Access System (CAS) which is the bedrock of the anonymous broadcasting. This work will improve the Anonymous Identity-Based Encryption Schemes using security based on bilinear groups and decisional bilinear Diffie-Hellman problem in improving the ciphertext security. The methodology used is the Objectoriented System Analysis and Design Methodology and a design that focuses on reuses. Implementation of work was done using PHP programming language and Heidi Structured Query Language (HeidiSQL) in the Laragon platform as the backend.""
""og:image:secure_url"",""https://www.semanticscholar.org/img/semantic_scholar_og.png"",""https://www.semanticscholar.org/img/semantic_scholar_og.png""
""twitter:image"",""https://www.semanticscholar.org/img/semantic_scholar_og.png"",""https://www.semanticscholar.org/img/semantic_scholar_og.png""
""twitter:site"",""@allenai_org""
""msapplication-square310x310logo"",""https://cdn.semanticscholar.org/86e6c2539915adc9/img/mstile-310x310.png""
""dc:title"",""[PDF] Improved Identity-Based Anonymous Broadcast Encryption with Chosen Ciphertext Security | Semantic Scholar""
""Content-Encoding"",""UTF-8""
""robots"",""noarchive,noindex""
""Content-Type"",""text/html; charset=UTF-8""
""s2-ui-version"",""2cfb8f55a25a62a824f97b333bd41eb95e1e3822""
""application-name"","" ""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""twitter:title"",""[PDF] Improved Identity-Based Anonymous Broadcast Encryption with Chosen Ciphertext Security | Semantic Scholar""
""og:type"",""website""
""og:title"",""[PDF] Improved Identity-Based Anonymous Broadcast Encryption with Chosen Ciphertext Security | Semantic Scholar""
""citation_author"",""M. Uchenna""
""og:image:height"",""582""
""resourceName"",""4665c7f2c034e9402fba9041f0b20cc86ae0.pdf""
""msapplication-square150x150logo"",""https://cdn.semanticscholar.org/86e6c2539915adc9/img/mstile-150x150.png""
""msapplication-TileColor"",""#FFFFFF""
""viewport"",""width=device-width,initial-scale=1""
""twitter:description"",""1Lecturer, Department of Computer Science, Federal University of Technology, Owerri, Nigeria 2Senior Lecturer, Department of Computer Science, Federal University of Technology, Owerri, Nigeria 3Lecturer, Department of Computer Science, Federal University of Technology, Owerri, Nigeria 4Lecturer, Department of Computer Science, Federal University of Technology, Owerri, Nigeria ---------------------------------------------------------------------***---------------------------------------------------------------------Abstract Anonymous receiver encryption is an important cryptographic primitive. It allows a sender to use the public identities of multiple receivers to encrypt messages so that only the authorized receivers or a privileged set of users can decrypt the messages, and the identities of the receivers are not revealed. The increasing need to protect users’ identity in an era of improved digital technology and cyber crime is very crucial. As such, the idea of anonymity in all fields of modern cryptography is given due attention so as to improve users’ experience and security. Generally, in broadcast encryption schemes, a broadcaster first chooses a set S of users who will be able to decrypt broadcast messages as authorized users’ set and encrypts a computed secret broadcast as a part of a ciphertext. Pay televisions use the Conditional Access System (CAS) which is the bedrock of the anonymous broadcasting. This work will improve the Anonymous Identity-Based Encryption Schemes using security based on bilinear groups and decisional bilinear Diffie-Hellman problem in improving the ciphertext security. The methodology used is the Objectoriented System Analysis and Design Methodology and a design that focuses on reuses. Implementation of work was done using PHP programming language and Heidi Structured Query Language (HeidiSQL) in the Laragon platform as the backend.""
""og:locale"",""en_US"",""en_US""
""Content-Language"",""en""
""msapplication-TileImage"",""https://cdn.semanticscholar.org/86e6c2539915adc9/img/mstile-144x144.png""
";https://scholar.google.com/scholar?start=710&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094548-688;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[PDF][PDF] A Business Process Model for Blockchain-based South African Real Estate Transactions;JL Tilbury ;2019 core.ac.uk;;"… 165 Page 10. ix List of Terms Terms Definitions 51% Network Attack An attack on a blockchain

network whereby a group of miners gain a 51% control of the network, enabling them to determine

the outcome of transactions … Bitcoin The first cryptocurrency to be invented …";Autres articles;;[PDF] core.ac.uk;https://core.ac.uk/download/pdf/323917855.pdf;;"""date"",""2020-05-19T09:54:30Z""
""pdf:PDFVersion"",""1.7""
""xmp:CreatorTool"",""MicrosoftÂŽ Word for Office 365""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""language"",""en""
""dc:format"",""application/pdf; version=1.7""
""pdf:docinfo:creator_tool"",""MicrosoftÂŽ Word for Office 365""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""xmp:CreateDate"",""2020-02-25T02:09:07Z""
""modified"",""2020-05-19T09:54:30Z""
""pdf:hasMarkedContent"",""true""
""xmp:ModifyDate"",""2020-05-19T11:54:30Z""
""pdf:docinfo:creator"",""Jack Tilbury""
""meta:author"",""Jack Tilbury""
""meta:creation-date"",""2020-02-25T02:09:07Z""
""created"",""2020-02-25T02:09:07Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-02-25T02:09:07Z""
""resourceName"",""323917855.pdf""
""Author"",""Jack Tilbury""
""producer"",""MicrosoftÂŽ Word for Office 365""
""pdf:docinfo:producer"",""MicrosoftÂŽ Word for Office 365""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""access_permission:modify_annotations"",""true""
""dc:creator"",""Jack Tilbury""
""dcterms:created"",""2020-02-25T02:09:07Z""
""Last-Modified"",""2020-05-19T09:54:30Z""
""dcterms:modified"",""2020-05-19T09:54:30Z""
""xmpMM:DocumentID"",""uuid:C9F3A2B8-008B-4A70-BC33-E846CE7DFF29""
""Last-Save-Date"",""2020-05-19T09:54:30Z""
""pdf:docinfo:modified"",""2020-05-19T09:54:30Z""
""meta:save-date"",""2020-05-19T09:54:30Z""
""Content-Length"",""5951821""
""Content-Type"",""application/pdf""
""xmp:MetadataDate"",""2020-05-19T11:54:30Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Jack Tilbury""
""dc:language"",""en-GB""
""pdf:producer"",""MicrosoftÂŽ Word for Office 365""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""231""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""383"",""524"",""2545"",""5955"",""6162"",""6367"",""992"",""3511"",""2059"",""3387"",""2819"",""780"",""2095"",""1102"",""2859"",""2863"",""2934"",""2762"",""2201"",""2805"",""2516"",""2781"",""2788"",""2712"",""2768"",""1055"",""2483"",""2341"",""2709"",""2807"",""2339"",""2746"",""2610"",""2484"",""2855"",""2106"",""2488"",""2744"",""2701"",""2022"",""2610"",""7044"",""8090"",""7660"",""2902"",""2975"",""2858"",""2792"",""3021"",""3380"",""2524"",""2959"",""2829"",""2546"",""2824"",""691"",""2995"",""2020"",""2964"",""2822"",""2496"",""2792"",""1692"",""2872"",""2740"",""2634"",""175"",""783"",""767"",""180"",""264"",""2867"",""2705"",""2654"",""3212"",""2213"",""2829"",""2879"",""2973"",""2854"",""2401"",""2681"",""2983"",""2923"",""2332"",""3067"",""2850"",""3026"",""2958"",""2848"",""2881"",""2474"",""3038"",""2977"",""3008"",""2944"",""2905"",""2829"",""473"",""2657"",""2504"",""2885"",""2439"",""3065"",""1941"",""2860"",""2902"",""2921"",""2217"",""3022"",""2263"",""208"",""3039"",""2219"",""2144"",""3019"",""2881"",""2407"",""3004"",""2860"",""2749"",""1415"",""234"",""2639"",""2483"",""2674"",""2643"",""2611"",""2347"",""2593"",""2650"",""2377"",""1692"",""2617"",""1739"",""605"",""677"",""876"",""982"",""1749"",""137"",""2529"",""3127"",""3110"",""2666"",""2719"",""2661"",""2562"",""2846"",""2775"",""2914"",""2769"",""3003"",""3097"",""3144"",""3160"",""3159"",""2928"",""2982"",""2494"",""3018"",""2341"",""2730"",""2666"",""2760"",""2572"",""2778"",""2587"",""2865"",""1646"",""2983"",""2969"",""1168"",""790"",""2809"",""3346"",""3143"",""2889"",""2730"",""3156"",""2391"",""2672"",""2454"",""2742"",""1038"",""2425"",""2934"",""2705"",""3045"",""2846"",""2767"",""2901"",""2652"",""3142"",""2763"",""189"",""1805"",""1975"",""2048"",""1911"",""1950"",""1860"",""2038"",""2030"",""1903"",""1757"",""1748"",""1987"",""2004"",""1566"",""411"",""2576"",""3115"",""3015"",""3420"",""1356"",""2934"",""2991"",""1423"",""2943"",""2635"",""868"",""2302"",""506"",""1527"",""812"",""2875"",""1383"",""906"",""2781"",""1559""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-02-25T02:09:07Z""
";https://scholar.google.com/scholar?start=500&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094605-926;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;KCRS: A Blockchain-Based Key Compromise Resilient Signature System;L Xu, L Chen, Z Gao, X Fan, K Doan, S Xu… ; … Conference on Blockchain …, 2019  Springer;;"… Theorem 2. The KCRS construction is IND-SPK secure under the VH-DDH assumption in the

random oracle model. Proof … In: Proceedings of the ACM Workshop on Blockchain,

Cryptocurrencies and Contracts, pp. 35–40 … In: Wiener, M. (ed.) CRYPTO 1999. LNCS, vol. 1666 …";Cité 2 fois;S Xu;[PDF] nsf.gov;https://par.nsf.gov/servlets/purl/10197157;;"""date"",""2020-01-18T00:18:47Z""
""pdf:PDFVersion"",""1.6""
""xmp:CreatorTool"",""Springer""
""pdf:docinfo:title"",""KCRS: A Blockchain-Based Key Compromise Resilient Signature System""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""Blockchain and Trustworthy Systems, doi:10.1007/978-981-15-2777-7_19""
""pdfa:PDFVersion"",""A-2b""
""xmpMM:History:Action"",""converted"",""converted""
""language"",""en""
""dc:format"",""application/pdf; version=""""A-2b"""""",""application/pdf; version=1.6""
""pdf:docinfo:custom:robots"",""noindex""
""pdf:docinfo:creator_tool"",""Springer""
""access_permission:fill_in_form"",""true""
""xmpMM:History:When"",""2020-01-18T05:48:07Z"",""2020-01-18T05:48:47Z""
""pdf:encrypted"",""false""
""dc:title"",""KCRS: A Blockchain-Based Key Compromise Resilient Signature System""
""xmp:CreateDate"",""2020-01-18T05:46:29Z""
""modified"",""2020-01-18T00:18:47Z""
""cp:subject"",""Blockchain and Trustworthy Systems, doi:10.1007/978-981-15-2777-7_19""
""xmpMM:History:SoftwareAgent"",""pdfToolbox"",""pdfToolbox""
""pdf:docinfo:custom:CrossMarkDomains[1]"",""springer.com""
""robots"",""noindex""
""pdf:docinfo:subject"",""Blockchain and Trustworthy Systems, doi:10.1007/978-981-15-2777-7_19""
""pdf:hasMarkedContent"",""false""
""xmpMM:History:InstanceID"",""uuid:32691fa4-ffd0-422f-b9b6-1b08d9e10270"",""uuid:23982e46-a0be-4e46-b019-9164a1614e7f""
""xmp:ModifyDate"",""2020-01-18T05:48:47Z""
""pdf:docinfo:creator"",""Lei Xu ""
""meta:author"",""Lei Xu "",""Lin Chen "",""Zhimin Gao "",""Xinxin Fan "",""Kimberly Doan "",""Shouhuai Xu "",""Weidong Shi ""
""meta:creation-date"",""2020-01-18T00:16:29Z""
""pdf:docinfo:custom:CrossmarkMajorVersionDate"",""2010-04-23""
""created"",""2020-01-18T00:16:29Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-01-18T00:16:29Z""
""resourceName"",""10197157""
""pdfaid:part"",""2""
""pdf:docinfo:custom:CrossMarkDomains[2]"",""springerlink.com""
""pdf:docinfo:custom:doi"",""10.1007/978-981-15-2777-7_19""
""pdf:docinfo:custom:CrossmarkDomainExclusive"",""true""
""Author"",""Lei Xu "",""Lin Chen "",""Zhimin Gao "",""Xinxin Fan "",""Kimberly Doan "",""Shouhuai Xu "",""Weidong Shi ""
""producer"",""Acrobat Distiller 10.1.8 (Windows)""
""CrossmarkDomainExclusive"",""true""
""pdf:docinfo:producer"",""Acrobat Distiller 10.1.8 (Windows)""
""doi"",""10.1007/978-981-15-2777-7_19""
""pdf:unmappedUnicodeCharsPerPage"",""1"",""0"",""0"",""0"",""20"",""4"",""0"",""2"",""2"",""0"",""0"",""0"",""0"",""0""
""dc:description"",""Blockchain and Trustworthy Systems, doi:10.1007/978-981-15-2777-7_19""
""Keywords"",""Digital signature,Key Compromise Resilient,Blockchain,Privacy,Exposure detection"",""Digital signature,Key Compromise Resilient,Blockchain,Privacy,Exposure detection""
""access_permission:modify_annotations"",""true""
""dc:creator"",""Lei Xu "",""Lin Chen "",""Zhimin Gao "",""Xinxin Fan "",""Kimberly Doan "",""Shouhuai Xu "",""Weidong Shi ""
""description"",""Blockchain and Trustworthy Systems, doi:10.1007/978-981-15-2777-7_19""
""dcterms:created"",""2020-01-18T00:16:29Z""
""Last-Modified"",""2020-01-18T00:18:47Z""
""dcterms:modified"",""2020-01-18T00:18:47Z""
""title"",""KCRS: A Blockchain-Based Key Compromise Resilient Signature System""
""xmpMM:DocumentID"",""uuid:f1a40bc8-c601-483a-a144-2e5ddbdd5195""
""Last-Save-Date"",""2020-01-18T00:18:47Z""
""CrossMarkDomains[1]"",""springer.com""
""pdf:docinfo:keywords"",""Digital signature,Key Compromise Resilient,Blockchain,Privacy,Exposure detection""
""pdf:docinfo:modified"",""2020-01-18T00:18:47Z""
""meta:save-date"",""2020-01-18T00:18:47Z""
""Content-Length"",""435068""
""Content-Type"",""application/pdf""
""xmp:MetadataDate"",""2020-01-18T05:48:47Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Lei Xu "",""Lin Chen "",""Zhimin Gao "",""Xinxin Fan "",""Kimberly Doan "",""Shouhuai Xu "",""Weidong Shi ""
""pdfaid:conformance"",""B""
""dc:language"",""EN""
""pdf:producer"",""Acrobat Distiller 10.1.8 (Windows)""
""dc:subject"",""Digital signature,Key Compromise Resilient,Blockchain,Privacy,Exposure detection"",""Digital signature,Key Compromise Resilient,Blockchain,Privacy,Exposure detection""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""14""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""2110"",""2509"",""2060"",""2170"",""2125"",""2525"",""1773"",""1464"",""2175"",""2184"",""2724"",""2049"",""2788"",""2289""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""CrossMarkDomains[2]"",""springerlink.com""
""meta:keyword"",""Digital signature,Key Compromise Resilient,Blockchain,Privacy,Exposure detection"",""Digital signature,Key Compromise Resilient,Blockchain,Privacy,Exposure detection""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-01-18T00:16:29Z""
""CrossmarkMajorVersionDate"",""2010-04-23""
";https://scholar.google.com/scholar?start=740&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094579-812;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[CITATION][C] Simulation-Sound Proofs for LWE and Applications to KDM-CCA2 Security.;B Libert, K Nguyen, A Passelčgue, R Titiu ; IACR Cryptol. ePrint Arch., 2019;;null;Autres articles;;null;;;;https://scholar.google.com/scholar?start=630&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094640-1078;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Blockchain-Based Smart Contract Access Control System;W Dai, C Wang, C Cui, H Jin… ; 2019 25th AsiaPacific …, 2019  ieeexplore.ieee.org;;"… C. Utility Module All emitted commands need to be signed to determine their initiators' identities.

The Crypto Module mainly handles the signature and verification for commands … Therefore, it

is necessary to design a secure oracle to transmit trusted data to blockchain …";Autres articles;;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/9007534/9026396/09026509.pdf?casa_token=RxXetYnGgqUAAAAA:-KzBC2V7yLCmHUpLy9mfWgzfXYwe31BeSH8bZc3bAunzOB4sY4hzQTjc9GqlSfW7Fti_n1vumro;;"""og:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""twitter:title"",""Blockchain-Based Smart Contract Access Control System""
""twitter:card"",""summary""
""Description"",""Research has shown that smart contracts have become a significant and promising technology. However, the lack of mature and stable security mechanism, such as a""
""og:title"",""Blockchain-Based Smart Contract Access Control System""
""resourceName"",""09026509.pdf""
""language"",""en""
""title"",""Blockchain-Based Smart Contract Access Control System | IEEE Conference Publication | IEEE Xplore""
""og:description"",""Research has shown that smart contracts have become a significant and promising technology. However, the lack of mature and stable security mechanism, such as access control, makes smart contracts quite vulnerable. To mitigate this problem, we present an attributed-based access control system based on blockchain by building a hierarchical management mechanism of contract administrator and contract owner. After combining blockchain inherent synchronization function with our designed system-level smart contract, all peers can easily get access control rules timely. Moreover, we modify the original smart contract finite state machine to prevent malicious modification on the rules through system contract. In our evaluation, the system only introduces 2%-5% additional cost with assured security on Hyperledger.""
""twitter:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-UA-Compatible"",""IE=Edge""
""viewport"",""width=device-width, initial-scale=1.0""
""dc:title"",""Blockchain-Based Smart Contract Access Control System | IEEE Conference Publication | IEEE Xplore""
""twitter:description"",""Research has shown that smart contracts have become a significant and promising technology. However, the lack of mature and stable security mechanism, such as access control, makes smart contracts quite vulnerable. To mitigate this problem, we present an attributed-based access control system based on blockchain by building a hierarchical management mechanism of contract administrator and contract owner. After combining blockchain inherent synchronization function with our designed system-level smart contract, all peers can easily get access control rules timely. Moreover, we modify the original smart contract finite state machine to prevent malicious modification on the rules through system contract. In our evaluation, the system only introduces 2%-5% additional cost with assured security on Hyperledger.""
""Content-Encoding"",""UTF-8""
""Content-Type-Hint"",""text/html; charset=utf-8""
""Content-Length"",""40962""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=890&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094600-907;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[PDF][PDF] Five Ways to GDPR-Compliant Use of Blockchains;J Erbguth ; Eur. Data Prot. L. Rev., 2019  HeinOnline;;"… oracles that enter outside data. Smart contracts might be created by one of the parties of a trans-

action or be created and provided by a third per son; Transaction level: when a user creates a

transac- tion, signs it with his/her private key and sends it to a node of the blockchain …";Cité 1 fois;Les 3 versions;[PDF] heinonline.org;https://heinonline.org/hol-cgi-bin/get_pdf.cgi?handle=hein.journals/edpl5&section=64&casa_token=xn4tDWm6yuAAAAAA:n8bn-WD66O-5BTynP88gVUnIbbSB70OO2L6m5qf0aNHazyINZbfKq5-Lj6VhAdfBxU2olXk;;"""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""REFRESH"",""1; url=https://heinonline.org/HOL/Page?handle=hein.journals/edpl5&div=64&g_sent=1&casa_token=xn4tDWm6yuAAAAAA:n8bn-WD66O-5BTynP88gVUnIbbSB70OO2L6m5qf0aNHazyINZbfKq5-Lj6VhAdfBxU2olXk""
""Content-Encoding"",""UTF-8""
""resourceName"",""get_pdf.cgi""
""language"",""""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=720&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094614-964;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[PDF][PDF] A Cryptocurrency Orientation for Property Insurance Professionals;J Lavoie ; The Brief, 2019  iadclaw.org;;"… a blockchain.44 One blockchain project called Augur is attempting to become an oracle, but its …

Fifty-one percent attack: a mass computing attack to overpower an entire blockchain 4. Sybil …

outsourcing to the cloud 2. Cold storage: storing private keys that access crypto assets off …";Autres articles;;[PDF] iadclaw.org;https://www.iadclaw.org/assets/1/6/14_1_MY2020_Lavoie_Cryptocurrency_for_Property_Insurance_Professionals_REVIEWED.pdf;;"""date"",""2019-11-21T20:26:58Z""
""pdf:PDFVersion"",""1.5""
""xmp:CreatorTool"",""Acrobat PDFMaker 11 for Word""
""pdf:docinfo:title"",""JLavoieCryptoPropertyInsPpr 042919  (C1925269.DOCX;1)""
""Company"",""""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""Acrobat PDFMaker 11 for Word""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""JLavoieCryptoPropertyInsPpr 042919  (C1925269.DOCX;1)""
""xmp:CreateDate"",""2019-11-21T14:26:49Z""
""modified"",""2019-11-21T20:26:58Z""
""pdf:docinfo:custom:SourceModified"",""D:20191120190039""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""true""
""xmp:ModifyDate"",""2019-11-21T14:26:58Z""
""pdf:docinfo:creator"",""Harper-Alport, Jane""
""meta:author"",""Harper-Alport, Jane""
""meta:creation-date"",""2019-11-21T20:26:49Z""
""created"",""2019-11-21T20:26:49Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-11-21T20:26:49Z""
""resourceName"",""14_1_MY2020_Lavoie_Cryptocurrency_for_Property_Insurance_Professionals_REVIEWED.pdf""
""pdf:docinfo:custom:Comments"",""""
""Author"",""Harper-Alport, Jane""
""producer"",""Adobe PDF Library 11.0""
""pdf:docinfo:producer"",""Adobe PDF Library 11.0""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""Harper-Alport, Jane""
""dcterms:created"",""2019-11-21T20:26:49Z""
""Last-Modified"",""2019-11-21T20:26:58Z""
""dcterms:modified"",""2019-11-21T20:26:58Z""
""title"",""JLavoieCryptoPropertyInsPpr 042919  (C1925269.DOCX;1)""
""xmpMM:DocumentID"",""uuid:8efa5c69-d3b1-414b-9a8f-4e5d0547e287""
""Last-Save-Date"",""2019-11-21T20:26:58Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2019-11-21T20:26:58Z""
""meta:save-date"",""2019-11-21T20:26:58Z""
""Content-Length"",""85168""
""Content-Type"",""application/pdf""
""xmp:MetadataDate"",""2019-11-21T14:26:58Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Harper-Alport, Jane""
""dc:language"",""EN-US""
""pdf:producer"",""Adobe PDF Library 11.0""
""dc:subject"",""""
""Comments"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""11""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""3155"",""3742"",""3832"",""3870"",""3702"",""3860"",""2831"",""3159"",""2223"",""2110"",""774""
""access_permission:extract_content"",""true""
""pdf:docinfo:custom:Company"",""""
""access_permission:can_print"",""true""
""SourceModified"",""D:20191120190039""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-11-21T20:26:49Z""
";https://scholar.google.com/scholar?start=780&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094626-1015;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[PDF][PDF] Compound: The money market protocol;R Leshner, G Hayes ; White Paper, 2019  digitalcoindata.com;;"… References 9 1 Page 2. 1 Introduction The market for cryptocurrencies and digital blockchain

assets has developed into a vibrant ecosystem of investors, speculators, and traders, exchanging

thousands [1] of blockchain assets … For blockchain assets, two major flaws exist today …";Cité 10 fois;Les 6 versions;[PDF] digitalcoindata.com;https://www.digitalcoindata.com/whitepapers/compound-whitepaper.pdf;;"""date"",""2018-07-23T22:59:02Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.4""
""xmp:CreatorTool"",""Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.99 Safari/537.36""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dcterms:created"",""2018-07-23T22:59:02Z""
""language"",""en""
""Last-Modified"",""2018-07-23T22:59:02Z""
""dcterms:modified"",""2018-07-23T22:59:02Z""
""dc:format"",""application/pdf; version=1.4""
""Last-Save-Date"",""2018-07-23T22:59:02Z""
""pdf:docinfo:creator_tool"",""Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.99 Safari/537.36""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2018-07-23T22:59:02Z""
""meta:save-date"",""2018-07-23T22:59:02Z""
""pdf:encrypted"",""false""
""modified"",""2018-07-23T22:59:02Z""
""Content-Length"",""190695""
""pdf:hasMarkedContent"",""false""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""meta:creation-date"",""2018-07-23T22:59:02Z""
""created"",""2018-07-23T22:59:02Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""9""
""Creation-Date"",""2018-07-23T22:59:02Z""
""resourceName"",""compound-whitepaper.pdf""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""766"",""2876"",""2666"",""1799"",""1816"",""2278"",""2815"",""1987"",""441""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""producer"",""Skia/PDF m67""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""Skia/PDF m67""
""pdf:docinfo:created"",""2018-07-23T22:59:02Z""
";https://scholar.google.com/scholar?start=830&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094654-1132;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Fast-to-finalize Nakamoto-like consensus;S Tang, SSM Chow, Z Liu, JK Liu ; Australasian Conference on …, 2019  Springer;;"… For a positive integer \(T_0\), oracle Open image in new window outputs the minimal hash value

in \({T_0}\) hash … main function that returns (the inverse of) the finality rate \(\varLambda _{\alpha }\)

of the blockchain with potential … In: Gennaro, R., Robshaw, M. (eds.) CRYPTO 2015 …";Cité 3 fois;Les 3 versions;null;;;;https://scholar.google.com/scholar?start=950&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094607-934;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Immutability and decentralized storage: An analysis of emerging threats;F Casino, E Politou, E Alepis, C Patsakis ; IEEE Access, 2019  ieeexplore.ieee.org;;"… For instance, ContracFuzzer [28] generates fuzzing inputs based on the ABI specifications of

SCs, defines test oracles to detect vulnerabilities, and analyses logs of SCs runtime behaviour

to detect security … Child Abuse Images Hidden in Crypto-Currency Blockchain …";Cité 8 fois;;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/6287639/8948470/08941045.pdf;;"""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""dc:title"",""IEEE Xplore Full-Text PDF:""
""Content-Encoding"",""UTF-8""
""resourceName"",""08941045.pdf""
""language"",""es""
""Content-Length"",""2565""
""title"",""IEEE Xplore Full-Text PDF:""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=750&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094651-1128;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Classical verification of quantum computations with efficient verifier;NH Chia, KM Chung, T Yamakawa ; arXiv preprint arXiv:1912.00990, 2019  arxiv.org;;"… work. • We construct a two-round CVQC protocol in the quantum random oracle model

(QROM) where a cryptographic hash function is idealized to be a random function. This …

7 Page 8. 2.2 Quantum Random Oracle Model The quantum …";Cité 4 fois;Les 3 versions;[PDF] arxiv.org;https://arxiv.org/pdf/1912.00990;;"""date"",""2020-03-16T00:48:08Z""
""pdf:PDFVersion"",""1.4""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.4""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""xmp:CreateDate"",""2020-03-15T20:48:08Z""
""modified"",""2020-03-16T00:48:08Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""xmp:ModifyDate"",""2020-03-15T20:48:08Z""
""pdf:docinfo:creator"",""""
""meta:author"",""""
""meta:creation-date"",""2020-03-16T00:48:08Z""
""created"",""2020-03-16T00:48:08Z""
""xmp:About"",""uuid:5a6ad37c-9f3c-11f5-0000-863eb2976521""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-03-16T00:48:08Z""
""resourceName"",""1912.00990""
""Author"",""""
""producer"",""dvips + GPL Ghostscript GIT PRERELEASE 9.22""
""pdf:docinfo:producer"",""dvips + GPL Ghostscript GIT PRERELEASE 9.22""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""19"",""14"",""9"",""0"",""6"",""14"",""18"",""15"",""28"",""15"",""54"",""61"",""68"",""103"",""132"",""102"",""40"",""68"",""30"",""41"",""64"",""28"",""13"",""2"",""13"",""13"",""12"",""12"",""0"",""0"",""0"",""14"",""7""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2020-03-16T00:48:08Z""
""Last-Modified"",""2020-03-16T00:48:08Z""
""dcterms:modified"",""2020-03-16T00:48:08Z""
""title"",""""
""xmpMM:DocumentID"",""uuid:5a6ad37c-9f3c-11f5-0000-863eb2976521""
""Last-Save-Date"",""2020-03-16T00:48:08Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2020-03-16T00:48:08Z""
""meta:save-date"",""2020-03-16T00:48:08Z""
""Content-Length"",""412277""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""35""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""2213"",""2771"",""3170"",""3330"",""3419"",""3260"",""3046"",""1751"",""2277"",""1253"",""1898"",""2249"",""2807"",""2429"",""1860"",""1847"",""1815"",""2301"",""1965"",""1781"",""1950"",""2156"",""1864"",""1924"",""2303"",""2183"",""1909"",""2355"",""2458"",""2026"",""2185"",""2375"",""2247"",""2291"",""355""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-03-16T00:48:08Z""
";https://scholar.google.com/scholar?start=940&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094565-759;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[HTML][HTML] Blockchain to Secure a More Personalized Pharma: Digital ledgers can detect fake drugs, enable virtual trials, and advance personalized medicine;J Woods, R Iyengar;Emens  Genetic Engineering & Biotechnology …, 2019  liebertpub.com;;"… Jordan Woods. Radhika Iyengar-Emens. Though the cryptocurrency side of blockchain

technology has dominated news headlines in the last year, the technology has real

promise in biotechnology and the life sciences. A recent …";;null;[HTML] liebertpub.com;https://www.liebertpub.com/doi/full/10.1089/gen.39.01.08?casa_token=YHURcG21gjMAAAAA:WwGaj1NqGsQ9v57VkE1yLtTbZyT7qZExi4v4HH80fWIaWD06dHG5GViMhEKFYBbFHOs43q1iLCzQ;;"""og:image"",""https://www.liebertpub.com/action/showCoverImage?journalCode=""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""og:site_name"",""Mary Ann Liebert, Inc., publishers""
""msvalidate.01"",""C94B97D2C737B949406DF8EF4F9563A6""
""resourceName"",""gen.39.01.08""
""language"",""en""
""title"",""""
""pbContext"","";wgroup:string:Publication Websites;page:string:Cookie Absent;website:website:mal-site""
""viewport"",""width=device-width,initial-scale=1,maximum-scale=1, user-scalable=0""
""dc:title"",""""
""Content-Encoding"",""UTF-8""
""robots"",""noarchive,noindex,nofollow""
""og:url"",""https://www.liebertpub.com/doi/abs/""
""Content-Language"",""en""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=570&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094621-996;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[PDF][PDF] FACULTY OF COMPUTER SCIENCE AND TELECOMMUNICATION;D PERMITTED ;2019 researchgate.net;;"… combines is $1 Billion Dollars. The total revenue for oracle is about $37 Billion Dollars form …

Some blockchains creates a new block every five seconds which makes the transaction to

complete very fast in time. In cryptocurrency terms, if a blockchain network …";Autres articles;Version HTML;[PDF] researchgate.net;https://www.researchgate.net/profile/Rajendra_Kuvvarapu/publication/331157708_BOOK_VERSION_Master_Thesis_Final_ENG_LATpdf/data/5c68acf04585156b57015705/BOOK-VERSION-Master-Thesis-Final-ENG-LAT.pdf;;;https://scholar.google.com/scholar?start=810&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094612-957;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Snow White: Robustly Reconfigurable Consensus and Applications to Provably Secure Proof of Stake;P Daian, R Pass, E Shi ; … Conference on Financial Cryptography and Data …, 2019  Springer;;"… in the past decade a new breakthrough called Bitcoin established a new, blockchain-based

paradigm … 2\kappa : -\kappa ]\) which is then used to seed the block-proposer-selection random

oracle … obtain voting power roughly proportional to their stake in the cryptocurrency system …";Cité 91 fois;Les 8 versions;[PDF] ifca.ai;http://www.ifca.ai/fc19/preproceedings/141-preproceedings.pdf;;"""date"",""2019-01-05T22:39:37Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2019-01-05T22:39:37Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016) kpathsea version 6.2.2""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2019-01-05T22:39:37Z""
""created"",""2019-01-05T22:39:37Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-01-05T22:39:37Z""
""resourceName"",""141-preproceedings.pdf""
""Author"",""""
""producer"",""pdfTeX-1.40.17""
""pdf:docinfo:producer"",""pdfTeX-1.40.17""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""2"",""0"",""0"",""0"",""3"",""10"",""2"",""0"",""0"",""0"",""3"",""0"",""0"",""1"",""10"",""0"",""0"",""0"",""0"",""0"",""0"",""4"",""0"",""3"",""10"",""10"",""0"",""4"",""0"",""7"",""0"",""8"",""3"",""3"",""2"",""2"",""0"",""0"",""2"",""5"",""6"",""6"",""9"",""27"",""20"",""13"",""15"",""10"",""5"",""24"",""40"",""36"",""23"",""5"",""33"",""14"",""24"",""9"",""10"",""14"",""42"",""27"",""5"",""7"",""16"",""2"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2019-01-05T22:39:37Z""
""Last-Modified"",""2019-01-05T22:39:37Z""
""dcterms:modified"",""2019-01-05T22:39:37Z""
""title"",""""
""Last-Save-Date"",""2019-01-05T22:39:37Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2019-01-05T22:39:37Z""
""meta:save-date"",""2019-01-05T22:39:37Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016) kpathsea version 6.2.2""
""Content-Length"",""776414""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""72""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""1851"",""2686"",""2837"",""2771"",""2499"",""2816"",""2374"",""2668"",""2606"",""2518"",""2741"",""2299"",""2730"",""2403"",""2491"",""2624"",""2828"",""2609"",""2601"",""2116"",""2552"",""2549"",""2512"",""1442"",""2493"",""2421"",""2302"",""1992"",""1994"",""1643"",""2665"",""1851"",""2101"",""1553"",""2532"",""1633"",""2309"",""2313"",""2402"",""2132"",""2852"",""2715"",""2514"",""1947"",""1980"",""1992"",""2321"",""1809"",""2550"",""2287"",""2041"",""1863"",""2343"",""2594"",""2445"",""2148"",""1698"",""2356"",""1910"",""2013"",""2458"",""2395"",""2292"",""2189"",""2384"",""2258"",""2190"",""2416"",""2222"",""2307"",""2756"",""994""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-01-05T22:39:37Z""
";https://scholar.google.com/scholar?start=770&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094642-1088;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Efficient leveled (multi) identity-based fully homomorphic encryption schemes;T Shen, F Wang, K Chen, K Wang, B Li ; IEEE Access, 2019  ieeexplore.ieee.org;;"… In CRYPTO 2015, Clear and McGoldrick [15] constructed the first MIFHE scheme in the random

oracle model based on the GPV-IBE scheme [24], which was simpli- fied by Mukherjee and Wichs

[38] who presented a construc- tion of MKFHE in EUROCRYPT 2016 …";Cité 9 fois;;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/6287639/8600701/08736214.pdf;;"""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""dc:title"",""IEEE Xplore Full-Text PDF:""
""Content-Encoding"",""UTF-8""
""resourceName"",""08736214.pdf""
""language"",""es""
""Content-Length"",""2565""
""title"",""IEEE Xplore Full-Text PDF:""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=900&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094602-913;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Assessment of decentralized system of smart-contacts effect on total output in digital economy;D Gubanov, M Oborin ; IOP Conference Series: Materials …, 2019  iopscience.iop.org;;"… Let's consider the main restrictions containing in the smart contracts: – transparency may not

always be an advantage, as it provides access to confidential information; – the “Oracle” problem

(adding information to the blockchain not included in it, but is necessary for smart …";Autres articles;;[PDF] iop.org;https://iopscience.iop.org/article/10.1088/1757-899X/497/1/012073/pdf;;"""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""viewport"",""width=device-width, initial-scale=1""
""dc:title"",""ShieldSquare Captcha""
""Content-Encoding"",""UTF-8""
""resourceName"",""pdf""
""language"",""en""
""Content-Length"",""2753""
""title"",""ShieldSquare Captcha""
""Content-Language"",""en""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=730&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094651-1124;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[CITATION][C] QAP-based Simulation-Extractable SNARK with a Single Verification.;J Kim, J Lee, H Oh ; IACR Cryptol. ePrint Arch., 2019;;null;Cité 3 fois;;null;;;;https://scholar.google.com/scholar?start=940&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094551-692;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[PDF][PDF] Exploring blockchain and new ways forward in the energy sector: A case study in Japan;A Ahl, M Yarime, S Chopra… ; … : MIT A+ B …, 2019  energyproceedings.org;;"… However, due to their higher efficiencies for PoW and cryptocurrency mining, graphics … Blockchain

platforms with smart contracts can cost-efficiently decentralize transactions and support … Oracles,

external digital agents integrated in smart contracts to monitor external parameters …";Autres articles;;[PDF] energy-proceedings.org;http://www.energy-proceedings.org/wp-content/uploads/2020/01/AEAB2019_paper_145.pdf;;"""date"",""2019-11-24T03:15:58Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.5""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dcterms:created"",""2019-11-24T03:15:58Z""
""language"",""en""
""Last-Modified"",""2019-11-24T03:15:58Z""
""dcterms:modified"",""2019-11-24T03:15:58Z""
""dc:format"",""application/pdf; version=1.5""
""xmpMM:DocumentID"",""uuid:2aba0a23-b5fe-43a4-88c6-c4cc57aca89b""
""Last-Save-Date"",""2019-11-24T03:15:58Z""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2019-11-24T03:15:58Z""
""meta:save-date"",""2019-11-24T03:15:58Z""
""pdf:encrypted"",""false""
""xmp:CreateDate"",""2019-11-23T22:15:58Z""
""modified"",""2019-11-24T03:15:58Z""
""Content-Length"",""546679""
""pdf:hasMarkedContent"",""false""
""Content-Type"",""application/pdf""
""xmp:ModifyDate"",""2019-11-23T22:15:58Z""
""xmp:MetadataDate"",""2019-11-23T22:15:58Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""pdf:producer"",""Skia/PDF m74""
""meta:creation-date"",""2019-11-24T03:15:58Z""
""created"",""2019-11-24T03:15:58Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""12""
""Creation-Date"",""2019-11-24T03:15:58Z""
""resourceName"",""AEAB2019_paper_145.pdf""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""4847"",""6400"",""6029"",""6015"",""6673"",""6296"",""6718"",""5407"",""5846"",""7671"",""7599"",""6587""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""producer"",""Skia/PDF m74""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""Skia/PDF m74""
""pdf:docinfo:created"",""2019-11-24T03:15:58Z""
";https://scholar.google.com/scholar?start=510&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094633-1042;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;UC-secure CRS generation for SNARKs;B Abdolmaleki, K Baghery, H Lipmaa, J Siim… ; … on Cryptology in Africa, 2019  Springer;;"… Zero-knowledge SNARKs (zk-SNARKs) have recently found various applications in verifiable

computation and blockchain applications (Zerocash), but … Differently from the previous work, the

new CRS-generation protocol also avoids the random oracle model which is typically …";Cité 12 fois;Les 4 versions;[PDF] kuleuven.be;https://www.esat.kuleuven.be/cosic/publications/article-3267.pdf;;"""date"",""2019-05-08T18:32:54Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2019-05-08T18:32:54Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is MiKTeX-pdfTeX 2.9.4902 (1.40.14)""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2019-05-08T18:32:54Z""
""created"",""2019-05-08T18:32:54Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-05-08T18:32:54Z""
""resourceName"",""article-3267.pdf""
""Author"",""""
""producer"",""pdfTeX-1.40.14""
""pdf:docinfo:producer"",""pdfTeX-1.40.14""
""pdf:unmappedUnicodeCharsPerPage"",""2116"",""2805"",""2734"",""2533"",""2414"",""2035"",""1314"",""2125"",""1455"",""2017"",""1896"",""271"",""2295"",""1194"",""1789"",""1167"",""2169"",""1571"",""1655"",""2096"",""1785"",""1558"",""1452"",""1772"",""2560"",""1499""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2019-05-08T18:32:54Z""
""Last-Modified"",""2019-05-08T18:32:54Z""
""dcterms:modified"",""2019-05-08T18:32:54Z""
""title"",""""
""Last-Save-Date"",""2019-05-08T18:32:54Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2019-05-08T18:32:54Z""
""meta:save-date"",""2019-05-08T18:32:54Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is MiKTeX-pdfTeX 2.9.4902 (1.40.14)""
""Content-Length"",""762524""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""26""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""2123"",""2812"",""2795"",""2690"",""2705"",""2489"",""2047"",""2633"",""1930"",""2607"",""2788"",""458"",""2907"",""1992"",""2382"",""2204"",""2688"",""2335"",""2263"",""2433"",""2227"",""2201"",""2152"",""2447"",""2560"",""1499""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-05-08T18:32:54Z""
";https://scholar.google.com/scholar?start=860&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094644-1097;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[HTML][HTML] Tradeoff gain and loss optimization against man-in-the-middle attacks based on game theoretic model;Y Jie, KKR Choo, M Li, L Chen, C Guo ; Future Generation Computer …, 2019  Elsevier;;"… Multi-double oracles algorithm and a constraint method … 4, we present our multi-double oracle

algorithm, designed to compute the optimal defender strategy and analyze the complexity for

the defender oracle problem … There have been attempts to introduce the use of Blockchain …";Cité 3 fois;Les 2 versions;[HTML] sciencedirect.com;https://www.sciencedirect.com/science/article/pii/S0167739X18315541?casa_token=1sqvhqpAsjoAAAAA:HKPO2xOLNf8pl40vPSmoOhFuP7_hYs2imQmEouXO6w-CmQvrNs1ukPZONHy90LsVhRKluPhE;;;https://scholar.google.com/scholar?start=910&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094572-784;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[PDF][PDF] K? TOÁN VŔ KI?M TOÁN TRONG TH?I ??I C?A CÔNG NGH? BLOCKCHAIN;TSNPB ?n, TSPT Lam, NCSTNH Běnh… ; K? Y?U H?I TH?O  soa.ueh.edu.vn;;"… Vasarhelyi, 2017). Ví d?, chu?i cung ?ng s? d?ng blockchain có th? d?a vŕo th? RFID

???c k?t n?i v?i tŕi s?n v?t ch?t ?? ?óng vai trň lŕ ph?n c?ng d? báo (hardware oracles)

?? thông báo ??n h?p ??ng thông minh khi Page 29. K? …";Autres articles;Version HTML;[PDF] ueh.edu.vn;http://soa.ueh.edu.vn/KYYEUHOITHAO_AIS_11%202019.pdf#page=6;;;https://scholar.google.com/scholar?start=600&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094614-963;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[PDF][PDF] Secure and Fair Computations on Forking Blockchains;V Botta, D Friolo, D Venturi, I Visconti ;2019 allquantor.at;;"… therefore post new transactions only after the previous ones are already confirmed on the

blockchain … idea in our construction consists of combining unique signatures [Lys02] and random

oracles as follows … Then this long string is given in input to a random oracle that therefore …";Cité 1 fois;;[PDF] allquantor.at;https://allquantor.at/blockchainbib/pdf/botta2019rush.pdf;;"""date"",""2020-03-09T09:12:28Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2020-03-09T09:12:28Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is MiKTeX-pdfTeX 2.9.6354 (1.40.18)""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2020-03-09T09:12:28Z""
""created"",""2020-03-09T09:12:28Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-03-09T09:12:28Z""
""resourceName"",""botta2019rush.pdf""
""Author"",""""
""producer"",""pdfTeX-1.40.18""
""pdf:docinfo:producer"",""pdfTeX-1.40.18""
""pdf:unmappedUnicodeCharsPerPage"",""2"",""0"",""0"",""0"",""3"",""0"",""1"",""0"",""15"",""7"",""5"",""15"",""7"",""5"",""4"",""6"",""6"",""22"",""30"",""21"",""11"",""12"",""13"",""6"",""15"",""8"",""21"",""7"",""9"",""3"",""0"",""2"",""0"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2020-03-09T09:12:28Z""
""Last-Modified"",""2020-03-09T09:12:28Z""
""dcterms:modified"",""2020-03-09T09:12:28Z""
""title"",""""
""Last-Save-Date"",""2020-03-09T09:12:28Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2020-03-09T09:12:28Z""
""meta:save-date"",""2020-03-09T09:12:28Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is MiKTeX-pdfTeX 2.9.6354 (1.40.18)""
""Content-Length"",""588470""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""35""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""2148"",""1255"",""3196"",""3043"",""3357"",""3540"",""3621"",""3038"",""2594"",""3097"",""3098"",""2709"",""2763"",""3072"",""3063"",""1336"",""3170"",""2886"",""2948"",""2932"",""3163"",""3124"",""2947"",""3289"",""2787"",""3052"",""3263"",""2910"",""2788"",""1979"",""1625"",""2007"",""2068"",""2113"",""234""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-03-09T09:12:28Z""
";https://scholar.google.com/scholar?start=780&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094637-1069;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Truxen: A Trusted Computing Enhanced Blockchain;C Zhang ; arXiv preprint arXiv:1904.08335, 2019  arxiv.org;;"… Town Crier [49] uses TEE as an Oracle to retrieve the data feed for smart contract … Additionally,

it has the ability to invoke off-chain system, that makes blockchain more flexible and … In M. Bellare,

editor, Advances in Cryptology — CRYPTO 2000, volume 1880 of LNCS, pages 255 …";Cité 1 fois;Les 2 versions;[PDF] arxiv.org;https://arxiv.org/pdf/1904.08335;;"""date"",""2019-04-17T15:49:51Z""
""pdf:PDFVersion"",""1.7""
""xmp:CreatorTool"",""MicrosoftÂŽ Word 2019""
""pdf:docinfo:title"",""Truxen- A Trusted Computing Enhanced Blockchain""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""language"",""en""
""dc:format"",""application/pdf; version=1.7""
""pdf:docinfo:creator_tool"",""MicrosoftÂŽ Word 2019""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""Truxen- A Trusted Computing Enhanced Blockchain""
""xmp:CreateDate"",""2019-04-17T23:49:51Z""
""modified"",""2019-04-17T15:49:51Z""
""pdf:hasMarkedContent"",""true""
""xmp:ModifyDate"",""2019-04-17T23:49:51Z""
""pdf:docinfo:creator"",""zhangchao""
""meta:author"",""zhangchao""
""meta:creation-date"",""2019-04-17T15:49:51Z""
""created"",""2019-04-17T15:49:51Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-04-17T15:49:51Z""
""resourceName"",""1904.08335""
""Author"",""zhangchao""
""producer"",""MicrosoftÂŽ Word 2019""
""pdf:docinfo:producer"",""MicrosoftÂŽ Word 2019""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""access_permission:modify_annotations"",""true""
""dc:creator"",""zhangchao""
""dcterms:created"",""2019-04-17T15:49:51Z""
""Last-Modified"",""2019-04-17T15:49:51Z""
""dcterms:modified"",""2019-04-17T15:49:51Z""
""title"",""Truxen- A Trusted Computing Enhanced Blockchain""
""xmpMM:DocumentID"",""uuid:B7EDFBDA-58AB-41CD-A5CE-4E58FF3CD095""
""Last-Save-Date"",""2019-04-17T15:49:51Z""
""pdf:docinfo:modified"",""2019-04-17T15:49:51Z""
""meta:save-date"",""2019-04-17T15:49:51Z""
""Content-Length"",""561051""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""zhangchao""
""dc:language"",""zh-CN""
""pdf:producer"",""MicrosoftÂŽ Word 2019""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""17""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""2523"",""2568"",""1980"",""3069"",""2870"",""3012"",""2739"",""3009"",""2459"",""1925"",""1700"",""2272"",""2143"",""2070"",""2913"",""3452"",""3421""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-04-17T15:49:51Z""
";https://scholar.google.com/scholar?start=880&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094553-708;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;DeMetrA-Decentralized Metering with user Anonymity and layered privacy on Blockchain;M Vasile, B Groza ; … Conference on System Theory, Control and …, 2019  ieeexplore.ieee.org;;"… without random oracles. In International Conference on the Theory and Applications of

Cryptographic Techniques, pages 223–238. Springer, 2004. [6] M. Cebe, E. Erdin, K. Akkaya,

H. Aksu, and S. Uluagac. Block4forensic: An integrated lightweight blockchain framework for …";Autres articles;;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/8880038/8885414/08885761.pdf?casa_token=UAD1NCd0RpkAAAAA:RoMYPTXcyaQDQD7uZjTH5hlwO7QvQ_ojEec4g3UmtQLOEonpJn23w3kQi1uNT6o_A0e7Bg9MyE8;;"""og:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""twitter:title"",""DeMetrA - Decentralized Metering with user Anonymity and layered privacy on Blockchain""
""twitter:card"",""summary""
""Description"",""Wear and tear are essential in establishing the market value of an asset. From shutter counters on DSLRs to odometers inside cars, specific counters, that encod""
""og:title"",""DeMetrA - Decentralized Metering with user Anonymity and layered privacy on Blockchain""
""resourceName"",""08885761.pdf""
""language"",""en""
""title"",""DeMetrA - Decentralized Metering with user Anonymity and layered privacy on Blockchain | IEEE Conference Publication | IEEE Xplore""
""og:description"",""Wear and tear are essential in establishing the market value of an asset. From shutter counters on DSLRs to odometers inside cars, specific counters, that encode the degree of wear, exist on most products. But malicious modification of the information that they report was always a concern. Our work explores a solution to this problem by using the blockchain technology, a layered encoding of product attributes and identity-based cryptography. Merging such technologies is essential since blockchains facilitate the construction of a distributed database that is resilient to adversarial modifications, while identity-based signatures set room for a more convenient way to check the correctness of the reported values based on the name of the product and pseudonym of the owner alone. Nonetheless, we reinforce security by using ownership cards deployed around NFC tokens. Since odometer fraud is still a major practical concern, we discuss a practical scenario centered on vehicles, but the framework can be easily extended to many other assets.""
""twitter:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-UA-Compatible"",""IE=Edge""
""viewport"",""width=device-width, initial-scale=1.0""
""dc:title"",""DeMetrA - Decentralized Metering with user Anonymity and layered privacy on Blockchain | IEEE Conference Publication | IEEE Xplore""
""twitter:description"",""Wear and tear are essential in establishing the market value of an asset. From shutter counters on DSLRs to odometers inside cars, specific counters, that encode the degree of wear, exist on most products. But malicious modification of the information that they report was always a concern. Our work explores a solution to this problem by using the blockchain technology, a layered encoding of product attributes and identity-based cryptography. Merging such technologies is essential since blockchains facilitate the construction of a distributed database that is resilient to adversarial modifications, while identity-based signatures set room for a more convenient way to check the correctness of the reported values based on the name of the product and pseudonym of the owner alone. Nonetheless, we reinforce security by using ownership cards deployed around NFC tokens. Since odometer fraud is still a major practical concern, we discuss a practical scenario centered on vehicles, but the framework can be easily extended to many other assets.""
""Content-Encoding"",""UTF-8""
""Content-Type-Hint"",""text/html; charset=utf-8""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=520&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094612-953;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Seedless Fruit Is the Sweetest: Random Number Generation, Revisited;S Tessaro ; Advances in Cryptology–CRYPTO 2019: 39th Annual …, 2019  books.google.com;;"… natural sources of entropy we want to extract from do not natively evaluate crypto- graphic hash …

but instead carefully modeling what constitutes entropy in the much more realistic,

oracle-dependent setting … a random bit b chosen by the challenger, who offers a set of oracles …";Autres articles;;null;;;;https://scholar.google.com/scholar?start=770&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094635-1051;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Adding linkability to ring signatures with one-time signatures;X Wang, Y Chen, X Ma ; International Conference on Information Security, 2019  Springer;;"… of their work is restricted to the same message, which may not be suited for cryptocurrency … Before

introducing the security definitions of RS, we first assume there are three oracles as following …

Joining oracle \(pk\leftarrow \mathcal {O}_{\text {join}}(\bot )\): \mathcal {O}_{\text {join …";Cité 3 fois;Les 5 versions;[PDF] iacr.org;https://eprint.iacr.org/2019/371.pdf;;"""date"",""2019-09-03T14:01:27Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2019-09-03T14:01:27Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.19 (TeX Live 2018/W32TeX) kpathsea version 6.3.0""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2019-09-03T14:01:27Z""
""created"",""2019-09-03T14:01:27Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-09-03T14:01:27Z""
""resourceName"",""371.pdf""
""Author"",""""
""producer"",""pdfTeX-1.40.19""
""pdf:docinfo:producer"",""pdfTeX-1.40.19""
""pdf:unmappedUnicodeCharsPerPage"",""2"",""1"",""3"",""24"",""11"",""0"",""10"",""0"",""1"",""12"",""10"",""8"",""19"",""15"",""21"",""4"",""0"",""0"",""0"",""2""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2019-09-03T14:01:27Z""
""Last-Modified"",""2019-09-03T14:01:27Z""
""dcterms:modified"",""2019-09-03T14:01:27Z""
""title"",""""
""Last-Save-Date"",""2019-09-03T14:01:27Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2019-09-03T14:01:27Z""
""meta:save-date"",""2019-09-03T14:01:27Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.19 (TeX Live 2018/W32TeX) kpathsea version 6.3.0""
""Content-Length"",""399684""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""20""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""1832"",""2638"",""2572"",""2691"",""1113"",""2531"",""1796"",""1610"",""1659"",""1577"",""2033"",""2119"",""2128"",""2166"",""2045"",""1423"",""1542"",""2655"",""2130"",""1478""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-09-03T14:01:27Z""
";https://scholar.google.com/scholar?start=870&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094665-1179;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Blockchain kompakt;HG Fill, A Meier ; Springer;;"Page 1. Blockchain kompakt Hans-Georg Fill Andreas Meier Grundlagen, Anwendungsoptionen …

Weitere Bände in der Reihe http://www.springer.com/series/8297 Page 4. Hans-Georg Fill ˇ

Andreas Meier Blockchain kompakt Grundlagen, Anwendungsoptionen und …";Cité 1 fois;;null;;;;https://scholar.google.com/scholar?start=420&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094546-678;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[HTML][HTML] Secure smart contract-enabled control of battery energy storage systems against cyber-attacks;N Mhaisen, N Fetais, A Massoud ; Alexandria Engineering Journal, 2019  Elsevier;;"… Sensing devices of each node are modeled as “oracles” of the blockchain. A blockchain

oracle is a system independent from the blockchain network that provides information from

the real world necessary for the smart contracts to execute [30] …";Cité 8 fois;Les 5 versions;[HTML] sciencedirect.com;https://www.sciencedirect.com/science/article/pii/S111001681930122X;;;https://scholar.google.com/scholar?start=490&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094588-856;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Crowdsourced traffic event detection and source reputation assessment using smart contracts;J Mihelj, Y Zhang, A Kos, U Sedlar ; Sensors, 2019  mdpi.com;;"… vehicular technology field [25]. Researchers in [26] proposed an incentive mechanism

that uses a blockchain-based cryptocurrency as a secure way for user incentivization.

Another interesting blockchain-based crowdsourcing …";Cité 5 fois;Les 10 versions;[PDF] mdpi.com;https://www.mdpi.com/1424-8220/19/15/3267/pdf;;;https://scholar.google.com/scholar?start=670&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094539-650;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[PDF][PDF] … The Editor shares key concepts and definitions of blockchain Industry Promoting innovation through education: The blockchain industry, law enforcement and …;CG Steen, LLP Hamilton, A Skadden, M Slate… ; skadden.com;;"… While oracles represent an elegant, and for the time- being necessary, solution to smart contracts …

to impact smart contracts would likely have an easier time exploiting the oracle's data feed … solely

because that contract contains a smart contract term.”38 Blockchain technology is …";Autres articles;;[PDF] skadden.com;https://www.skadden.com/-/media/files/publications/2019/11/legalissuessurroundingtheuseofsmartcontracts.pdf;;;https://scholar.google.com/scholar?start=460&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094583-833;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Incremental proofs of sequential work;N Döttling, RWF Lai, G Malavolta ; … on the Theory and Applications of …, 2019  Springer;;"… All parties have access to a random oracle Open image in new window … For all Open image in

new window , all Open image in new window , all random oracles Open image in new window ,

and all statements Open image in new window we say that a tuple Open image in new …";Cité 11 fois;Les 4 versions;[PDF] iacr.org;https://eprint.iacr.org/2019/650.pdf;;"""date"",""2019-06-03T08:35:47Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2019-06-03T08:35:47Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.19 (TeX Live 2018) kpathsea version 6.3.0""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2019-06-03T08:35:47Z""
""created"",""2019-06-03T08:35:47Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-06-03T08:35:47Z""
""resourceName"",""650.pdf""
""Author"",""""
""producer"",""pdfTeX-1.40.19""
""pdf:docinfo:producer"",""pdfTeX-1.40.19""
""pdf:unmappedUnicodeCharsPerPage"",""2"",""21"",""16"",""0"",""0"",""4"",""15"",""11"",""52"",""45"",""99"",""24"",""31"",""13"",""58"",""23"",""31"",""36"",""13"",""27"",""59"",""59"",""44"",""6""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2019-06-03T08:35:47Z""
""Last-Modified"",""2019-06-03T08:35:47Z""
""dcterms:modified"",""2019-06-03T08:35:47Z""
""title"",""""
""Last-Save-Date"",""2019-06-03T08:35:47Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2019-06-03T08:35:47Z""
""meta:save-date"",""2019-06-03T08:35:47Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.19 (TeX Live 2018) kpathsea version 6.3.0""
""Content-Length"",""425805""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""24""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""3115"",""3288"",""4386"",""2926"",""2002"",""3312"",""1740"",""1596"",""2375"",""3496"",""3076"",""1821"",""2332"",""1826"",""1827"",""2665"",""2366"",""1562"",""3225"",""2506"",""2463"",""2597"",""1552"",""346""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-06-03T08:35:47Z""
";https://scholar.google.com/scholar?start=650&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094612-955;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;STEM: Secure Token Exchange Mechanisms;M Darisi, J Savla, M Shirole, S Bhirud ; International Conference on …, 2019  Springer;;"… name and R the rate at which he would like to trade in the base blockchain currency … of the atomic

swap solutions involve 1:1 backing up of tokens and do not involve oracles to aid … STEP 3. Token

Contract A subscribes to an oracle [19] and generates a random number s which is …";Autres articles;;null;;;;https://scholar.google.com/scholar?start=770&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094532-615;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Prediction of Cryptocurrency Market Price Using Deep Learning and Blockchain Information;G Senthuran, MN Halgamuge ; Essentials of Blockchain …, 2019  books.google.com;;"… information was utilized. According to the results presented in Figures 15.3 and 15.4,

the accuracy of the prediction for the cryptocurrency is more accurate when using

the blockchain data and crypto data. Figures 15.5 and 15.6 …";Cité 1 fois;Les 3 versions;null;;;;
1619094661-1163;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[PDF][PDF] A garden of forking paths: the several and multifaceted perspectives in the relationship between privacy and technical enablers;R Montanari, S Saleri ; Eur. J. Privacy L. & Tech., 2019  HeinOnline;;"… IEEE Int. Conf. Secur. Privacy 321-33. 19X Boyenand, B Waters, 'Anonymous hierarchical

identity-based encryption -without ran- dom oracles' (2006) vol. 4117, Proc. Adv. Cryptol … 4 9 B.

Scott, How Can Cryptocurrency and Blockchain Technology Play a Role in Building So …";Autres articles;;[PDF] heinonline.org;https://heinonline.org/hol-cgi-bin/get_pdf.cgi?handle=hein.journals/ejplt2019&section=34&casa_token=qnCp3izj1MUAAAAA:yJ-urxve2DcJG8hsFPkOm8fgM8EDczw3cKqwjEdWkeQKxy8XGPTtecN7hOjHvEZbHvjis5g;;"""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""REFRESH"",""1; url=https://heinonline.org/HOL/Page?handle=hein.journals/ejplt2019&div=34&g_sent=1&casa_token=qnCp3izj1MUAAAAA:yJ-urxve2DcJG8hsFPkOm8fgM8EDczw3cKqwjEdWkeQKxy8XGPTtecN7hOjHvEZbHvjis5g""
""Content-Encoding"",""UTF-8""
""resourceName"",""get_pdf.cgi""
""language"",""""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=980&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094544-666;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[PDF][PDF] Enhancing Stakeholders' Trust in Megaproject Supply Chain Through Blockchain: An Exploratory Study;YR Jing, W Ron, L Sainan, Z Jiwan ; Trust in Major and Mega Projects  researchgate.net;;"… As a part of a smart contract, oracles verify the real-world events and upload authentic information

to the smart contract … In order to use a blockchain system, every participant must register an account

(eg, not easy as register a new email) and buy some cryptocurrency …";Autres articles;;[PDF] researchgate.net;https://www.researchgate.net/profile/Markku_Lehtonen/publication/343022681_History_Trust_and_Mistrust_Lessons_From_Radioactive_Waste_Disposal_Megaprojects/links/5f123723299bf1e548c0b8f2/History-Trust-and-Mistrust-Lessons-From-Radioactive-Waste-Disposal-Megaprojects.pdf#page=25;;;https://scholar.google.com/scholar?start=480&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094562-747;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Towards Advanced Artificial Intelligence using Blockchain Technologies;JL Marechaux ; IEEE Blockchain Technical Briefs, 2019  blockchain.ieee.org;;"… Non-cryptocurrency use of blockchain is becoming a game changer in supply chain, government

agencies, accounting or human resources, and blockchain solutions are deployed by Walmart,

Maersk, the UN Refugee Agency or the Government of Estonia [1][2][3][4]. Because …";Cité 2 fois;Les 2 versions;null;;;;https://scholar.google.com/scholar?start=560&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094623-1008;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[PDF][PDF] Provably Secure, Smart Contract-based Naming Services: Design, Implementation and Evaluation?;C Patsonakis ;2019 di.uoa.gr;;"… security is based on the strong RSA assumption in the Ran- dom Oracle model … In: Pro- ceedings

of the ACM Workshop on Blockchain, Cryptocurrencies and Contracts (2017) 40 … of the 37th Annual

International Conference on the Advances in Cryptology (CRYPTO) (2017) 47 …";;;[PDF] uoa.gr;https://www.di.uoa.gr/sites/default/files/documents/grad/phdbook/Christos%20Patsonakis.pdf;;;https://scholar.google.com/scholar?start=820&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094576-803;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Secure image transferring using asymmetric crypto system;KKK Oo, YN Soe, YM Myint ; International Journal for Advance …, 2019  ijarnd.com;;"… Secure image transferring using asymmetric crypto system … The OAEP algorithm is a form of Feistel

network which uses a pair of random oracles G and H to … When combined with any secure trapdoor

one-way permutation f, this processing is proved in the random oracle model to …";Autres articles;Version HTML;[PDF] ijarnd.com;https://www.ijarnd.com/manuscripts/v4i9/V4I9-1138.pdf;;;https://scholar.google.com/scholar?start=620&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094644-1095;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Blockchain-based anonymous authentication with selective revocation for smart industrial applications;Y Yu, Y Zhao, Y Li, X Du, L Wang… ; IEEE Transactions on …, 2019  ieeexplore.ieee.org;;"… to-peer network, cryptography, and consensus mechanisms to establish the Bitcoin cryptocurrency

system [13] … authentication with selective revocation with blockchain to establish BASS, a

blockchain- based anonymous … We define the oracle O(m) on input m ? Zq that selects a …";Cité 11 fois;Les 2 versions;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/9424/4389054/08853326.pdf?casa_token=cyyPYnqrjisAAAAA:E37zkr9e2sOaVTsx8aFngBMKpneyEpMPyd9ya4cIwoOo6mXRtISvRua9wOYsTN4bvQyhFcuuEYs;;"""og:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""twitter:title"",""Blockchain-Based Anonymous Authentication With Selective Revocation for Smart Industrial Applications""
""twitter:card"",""summary""
""Description"",""Personal privacy disclosure is one of the most serious challenges in smart industrial applications. Anonymous authentication is an effective solution to protect""
""og:title"",""Blockchain-Based Anonymous Authentication With Selective Revocation for Smart Industrial Applications""
""resourceName"",""08853326.pdf""
""language"",""en""
""title"",""Blockchain-Based Anonymous Authentication With Selective Revocation for Smart Industrial Applications | IEEE Journals & Magazine | IEEE Xplore""
""og:description"",""Personal privacy disclosure is one of the most serious challenges in smart industrial applications. Anonymous authentication is an effective solution to protect personal privacy. However, the existing anonymous credential protocols are not perfectly suitablefor smart industrial environments such as smart vehicles in the sense that the credential revocation issue is not well-solved. In this article, we propose a Blockchain-based Anonymous authentication with Selective revocation for Smart industrial applications (BASS) for smart industrial applications supporting attribute privacy, selective revocation, credential soundness, and multishowing-unlinkability. Specifically, an efficient selective revocation mechanism is proposed based on dynamic accumulators and the signature algorithm due to Pointcheval and Sanders as the overlay of the BASS. According to the diverse demands of credential authorities, BASS can selectively provide revocation of credentials or revocation of users. We extend BASS from single-attribute privacy to multiattribute privacy as well. Finally, we implement a prototype to evaluate the cryptographic core primitives of BASS by deploying smart contracts in Ethereum to demonstrate the validity of BASS in smart industrial applications.""
""twitter:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-UA-Compatible"",""IE=Edge""
""viewport"",""width=device-width, initial-scale=1.0""
""dc:title"",""Blockchain-Based Anonymous Authentication With Selective Revocation for Smart Industrial Applications | IEEE Journals & Magazine | IEEE Xplore""
""twitter:description"",""Personal privacy disclosure is one of the most serious challenges in smart industrial applications. Anonymous authentication is an effective solution to protect personal privacy. However, the existing anonymous credential protocols are not perfectly suitablefor smart industrial environments such as smart vehicles in the sense that the credential revocation issue is not well-solved. In this article, we propose a Blockchain-based Anonymous authentication with Selective revocation for Smart industrial applications (BASS) for smart industrial applications supporting attribute privacy, selective revocation, credential soundness, and multishowing-unlinkability. Specifically, an efficient selective revocation mechanism is proposed based on dynamic accumulators and the signature algorithm due to Pointcheval and Sanders as the overlay of the BASS. According to the diverse demands of credential authorities, BASS can selectively provide revocation of credentials or revocation of users. We extend BASS from single-attribute privacy to multiattribute privacy as well. Finally, we implement a prototype to evaluate the cryptographic core primitives of BASS by deploying smart contracts in Ethereum to demonstrate the validity of BASS in smart industrial applications.""
""Content-Encoding"",""UTF-8""
""Content-Type-Hint"",""text/html; charset=utf-8""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=910&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094553-703;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[LIVRE][B] Blockchain: La Nuova Rivoluzione Industriale;A Basile ;2019 books.google.com;;"… Corda 2.5. Altre blockchain 2.5.1. Kadena 2.5.2. Ripple 2.5.3. Stellar 2.5.4. Rootstock 2.6.

Crypto tax and legal 2.6.1. Fuori dall'Italia 2.6.2. E in Italia? 3. Parliamo di smart contract e

ICO 3.1. Smart contract 3.2. DAO e DApp 3.2.1. DAO 3.2.2. DApp 3.3 …";Autres articles;;null;;;;https://scholar.google.com/scholar?start=520&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094635-1058;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[PDF][PDF] Block Chains-The Technology and Application in Supply Chain Management;V Lall, R Rumb, C Dufault ; Journal of Global Business Management, 2019  jgbm.org;;"… most prominent, application of Blockchains has been for digitally encrypted ""crypto-coins"" (CCs) …

Bitcoin, the first Blockchain-based cryptocurrency-the first decentralized payment method of … smart

contracts through a permission Blockchain through “a Blockchain oracle: a trusted …";Cité 1 fois;;[PDF] jgbm.org;http://www.jgbm.org/page/1%20Ruth%20Lumb.pdf;;"""date"",""2019-05-09T01:15:34Z""
""pdf:PDFVersion"",""1.4""
""xmp:CreatorTool"",""PScript5.dll Version 5.2.2""
""pdf:docinfo:title"",""Microsoft Word - 1 Ruth Lumb.doc""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""language"",""en""
""dc:format"",""application/pdf; version=1.4""
""pdf:docinfo:creator_tool"",""PScript5.dll Version 5.2.2""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""Microsoft Word - 1 Ruth Lumb.doc""
""xmp:CreateDate"",""2019-05-09T09:15:34Z""
""modified"",""2019-05-09T01:15:34Z""
""pdf:hasMarkedContent"",""false""
""xmp:ModifyDate"",""2019-05-09T09:15:34Z""
""pdf:docinfo:creator"",""user""
""meta:author"",""user""
""meta:creation-date"",""2019-05-09T01:15:34Z""
""created"",""2019-05-09T01:15:34Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-05-09T01:15:34Z""
""resourceName"",""1%20Ruth%20Lumb.pdf""
""Author"",""user""
""producer"",""Acrobat Distiller 10.0.0 (Windows)""
""pdf:docinfo:producer"",""Acrobat Distiller 10.0.0 (Windows)""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""access_permission:modify_annotations"",""true""
""dc:creator"",""user""
""dcterms:created"",""2019-05-09T01:15:34Z""
""Last-Modified"",""2019-05-09T01:15:34Z""
""dcterms:modified"",""2019-05-09T01:15:34Z""
""title"",""Microsoft Word - 1 Ruth Lumb.doc""
""xmpMM:DocumentID"",""uuid:fbe1b4a2-6a5b-40e4-b756-18d057ca4f69""
""Last-Save-Date"",""2019-05-09T01:15:34Z""
""pdf:docinfo:modified"",""2019-05-09T01:15:34Z""
""meta:save-date"",""2019-05-09T01:15:34Z""
""Content-Length"",""1106260""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""user""
""pdf:producer"",""Acrobat Distiller 10.0.0 (Windows)""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""11""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""3240"",""2516"",""2418"",""1076"",""998"",""3620"",""2432"",""2753"",""3899"",""3606"",""3935""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-05-09T01:15:34Z""
";https://scholar.google.com/scholar?start=870&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094654-1139;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Reversible Proofs of Sequential Work;M Walter ; Advances in Cryptology–EUROCRYPT 2019: 38th …, 2019  books.google.com;;"… When applied to a blockchain, our new PoSW allows extremely efficient rejection of wrong proofs

while … 3-319-78375-815 Coron, J.-S., Patarin, J., Seurin, Y.: The random oracle model and … 1 Dodis,

Y., Guo, S., Katz, J.: Fixing cracks in the concrete: random oracles with auxiliary …";Autres articles;;null;;;;https://scholar.google.com/scholar?start=950&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094553-704;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Selected Scenarios for a Crypto-AI World;H Arslanian, F Fischer ; The Future of Finance, 2019  Springer;;"… The use of blockchain as the transactional backbone of this system allows us to consider how …

New machines might be added to the system in order to act as 'oracles' for such … bank–backed

digital currency, they might just as easily incorporate other forms of crypto-assets, such …";;null;null;;;;https://scholar.google.com/scholar?start=520&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094532-616;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[PDF][PDF] Blockchain en het recht;M Schellekens, ETT Tai, W Kaufmann, F Schemkes… ;2019 pure.uvt.nl;;"… aan de hand van gegevens buiten de blockchain (ingebracht via een zogenaamd oracle), maar

het … Bij het gebruik van menselijke 'oracles' voor de beoordeling van omstandigheden wordt het

smart contract … In a permissioned blockchain, only authorized managers can be active …";Cité 1 fois;Les 7 versions;[PDF] uvt.nl;https://pure.uvt.nl/ws/portalfiles/portal/32229671/Blockchain_en_het_recht.pdf;;"""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.7""
""xmp:CreatorTool"",""PDFium""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dcterms:created"",""2020-01-27T16:03:55Z""
""language"",""nl""
""dc:format"",""application/pdf; version=1.7""
""pdf:docinfo:creator_tool"",""PDFium""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""pdf:hasMarkedContent"",""false""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""meta:creation-date"",""2020-01-27T16:03:55Z""
""created"",""2020-01-27T16:03:55Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""138""
""Creation-Date"",""2020-01-27T16:03:55Z""
""resourceName"",""Blockchain_en_het_recht.pdf""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""1340"",""461"",""533"",""5132"",""4957"",""498"",""3642"",""3678"",""3577"",""3214"",""3897"",""7"",""3567"",""3940"",""3334"",""3609"",""1616"",""3301"",""2436"",""3633"",""4338"",""3984"",""2732"",""3086"",""3113"",""3856"",""3640"",""3852"",""4224"",""3662"",""3881"",""4600"",""4365"",""4405"",""4207"",""3996"",""4148"",""4186"",""4233"",""4322"",""4943"",""4255"",""4537"",""4654"",""4177"",""4537"",""4633"",""4287"",""4506"",""4765"",""4062"",""4661"",""3992"",""4798"",""4234"",""4572"",""4499"",""4252"",""4281"",""4302"",""3954"",""4622"",""4222"",""4395"",""3680"",""4242"",""4593"",""2718"",""4173"",""4124"",""3743"",""4014"",""3882"",""3499"",""4189"",""3995"",""187"",""3345"",""4344"",""4498"",""4308"",""4071"",""5012"",""4604"",""552"",""3817"",""4769"",""4385"",""4748"",""4703"",""4320"",""3148"",""3798"",""3754"",""3114"",""3477"",""3911"",""3950"",""3830"",""1739"",""3471"",""3880"",""3491"",""3501"",""3779"",""3818"",""3970"",""3888"",""3816"",""4003"",""3732"",""3684"",""3889"",""1148"",""3575"",""3551"",""3748"",""1276"",""9"",""2416"",""2166"",""2175"",""2160"",""2126"",""2027"",""2441"",""2239"",""2038"",""2085"",""2096"",""1975"",""2180"",""2139"",""1078"",""349"",""208"",""3663"",""120""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""producer"",""PDFium""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""PDFium""
""pdf:docinfo:created"",""2020-01-27T16:03:55Z""
";
1619094551-694;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[CITATION][C] Smart Contracts and Dispute Resolution–A Chance to Raise Efficiency?;F Kreis, M Kaulartz ; ASA Bulletin, 2019  kluwerlawonline.com;Switzerland;"… a flight, etc.). Therefore, a link between the real world and the blockchain is needed.

Such links are called “oracles”. An oracle can be any interface where information

from the real world enters the “digital world”. With regard …";;;[PDF] kluwerlawonline.com;https://kluwerlawonline.com/api/Product/CitationPDFURL?file=Journals\ASAB\ASAB2019031.pdf&casa_token=7-gw5yv35MwAAAAA:oeVkSr5Azq_yuDTRtayOos3vfyAPeoIccSxYk3BeBXBual23XatjCu5wC_uxrzO-kDW9vSY;;"""citation_publication_date"",""2019-06-01""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""expires"",""0""
""theme-color"",""#000000""
""citation_title"",""Smart Contracts and Dispute Resolution &#150; A Chance to Raise Efficiency?""
""google-site-verification"",""yPf3b_LBIcwb60gWAxtIU7pmoud47QpZXBY9IxwLKb4""
""Content-Location"",""/""
""citation_journal_title"",""ASA Bulletin""
""citation_author"",""Falco Kreis"",""Markus Kaulartz""
""description"",""View Smart Contracts and Dispute Resolution &#150; A Chance to Raise Efficiency? by Falco Kreis,Markus Kaulartz - ASA Bulletin""
""resourceName"",""CitationPDFURL""
""language"",""en""
""title"",""""
""citation_issue"",""2""
""pragma"",""no-cache""
""viewport"",""width=device-width,initial-scale=1,shrink-to-fit=no""
""dc:title"",""""
""Content-Encoding"",""UTF-8""
""citation_pdf_url"",""https://kluwerlawonline.com/api/Product/CitationPDFURL?file=Journals\ASAB\ASAB2019031.pdf""
""citation_volume"",""37""
""cache-control"",""no-cache""
""Content-Language"",""en""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=510&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094574-798;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[PDF][PDF] Homomorphic Encryption Random Beacon.;A Cherniaeva, I Shirobokov… ; IACR Cryptol. ePrint …, 2019  researchgate.net;;"… In our analysis we instantiate HERB using ElGamal encryption and a public blockchain …

With decentralized systems and blockchain technology gaining popularity over the recent

years, research in randomness beacons has gained interest …";Cité 4 fois;Les 2 versions;[PDF] researchgate.net;https://www.researchgate.net/profile/Ilia_Shirobokov/publication/337548820_Homomorphic_Encryption_Random_Beacon/links/5ddd9ea0a6fdcc2837ed8126/Homomorphic-Encryption-Random-Beacon.pdf;;;https://scholar.google.com/scholar?start=610&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094586-842;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[PDF][PDF] Timed-Release Encryption With Master Time Bound Key (Full Version).;G Choi, S Vaudenay ; IACR Cryptol. ePrint Arch., 2019  eprint.iacr.org;;"… in the rest of this paper. We first define security games with oracles in Table 1. Table

1. Outputs of the decryption oracles O1 and O2, and the time bound key oracle Q

for security games by attack types. O1(? , c ) O2(? , c ) Q(t ) …";Cité 1 fois;;[PDF] iacr.org;https://eprint.iacr.org/2019/904.pdf;;"""date"",""2019-08-05T13:24:57Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""4"",""12"",""0"",""16"",""4"",""14"",""0"",""18"",""9"",""12"",""55"",""33"",""37"",""18"",""2"",""0"",""0""
""pdf:PDFVersion"",""1.5""
""xmp:CreatorTool"",""TeX""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dcterms:created"",""2019-08-05T13:24:57Z""
""language"",""en""
""Last-Modified"",""2019-08-05T13:24:57Z""
""dcterms:modified"",""2019-08-05T13:24:57Z""
""dc:format"",""application/pdf; version=1.5""
""Last-Save-Date"",""2019-08-05T13:24:57Z""
""pdf:docinfo:creator_tool"",""TeX""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2019-08-05T13:24:57Z""
""meta:save-date"",""2019-08-05T13:24:57Z""
""pdf:encrypted"",""false""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016/W32TeX) kpathsea version 6.2.2""
""modified"",""2019-08-05T13:24:57Z""
""Content-Length"",""404430""
""pdf:hasMarkedContent"",""false""
""Content-Type"",""application/pdf""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016/W32TeX) kpathsea version 6.2.2""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""trapped"",""False""
""meta:creation-date"",""2019-08-05T13:24:57Z""
""created"",""2019-08-05T13:24:57Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""20""
""Creation-Date"",""2019-08-05T13:24:57Z""
""resourceName"",""904.pdf""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""1968"",""2875"",""2748"",""2160"",""1815"",""1936"",""2060"",""2057"",""1719"",""1382"",""1793"",""1124"",""1600"",""1727"",""2387"",""1414"",""2214"",""2292"",""2194"",""2675""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""producer"",""pdfTeX-1.40.17""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""pdfTeX-1.40.17""
""pdf:docinfo:created"",""2019-08-05T13:24:57Z""
";https://scholar.google.com/scholar?start=660&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094558-727;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Contributions of Blockchain to the Supply Chain and Logistics in the Vehicle Industries Platform;F Kaya ;2019 search.proquest.com;;"… individuals have the ability to eliminate third parties. Blockchain technology, distributed ledger

technology (DLT), is an underlying technology of bitcoin and other crypto-currency. With

blockchain ledger, all participants can hold their own database in the network. When new …";Autres articles;;null;;;;https://scholar.google.com/scholar?start=540&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094586-843;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;The forthcoming data ecosystem for business measurement and assurance;S Cho, MA Vasarhelyi, C Zhang ;2019 meridian.allenpress.com;United States of America;"… goals. We argue that the most notable technologies for the current wave of change

are Robotic/Intelligent Process Automation, Machine Learning, Blockchain, and

Continuous Measurement and Assurance applications. Furthermore …";Cité 5 fois;Les 2 versions;[HTML] aaajournals.org;https://www.aaajournals.org/doi/full/10.2308/jeta-10699;;"""msapplication-config"",""//allen.silverchair-cdn.com/Themes/Client/app/img/favicons/v-637520496823169254/browserconfig.xml""
""citation_publication_date"",""2019/09/01""
""theme-color"",""#002f65""
""citation_author_institution"",""Rutgers, The State University of New Jersey"",""Rutgers, The State University of New Jersey"",""Rutgers, The State University of New Jersey"",""Southwestern University of Finance and Economics""
""citation_title"",""The Forthcoming Data Ecosystem for Business Measurement and Assurance""
""citation_reference"",""citation_author=Amatriain  X.;  citation_year=2015; "",""citation_author=American Institute of Certified Public Accountants (AICPA); citation_publisher=AICPA, New York, NY; Audit Analytics and Continuous Audit: Looking Towards the Future;  citation_year=2015; "",""citation_title=Securing Big Data provenance for auditors: The Big Data provenance black box as reliable evidence; citation_author=Appelbaum  D.;  citation_journal_title=Journal of Emerging Technologies in Accounting;  citation_year=2016;  citation_volume=13;  citation_issue=1;  citation_pages=17-36; "",""citation_title=Ethical implications for the audit of AI in the public sector; citation_author=Appelbaum  D.; citation_author=Issa  H.; citation_author=Strauss  R.; citation_publisher=Montclair State University;  citation_year=2019; "",""citation_title=Big Data and analytics in the modern audit engagement: Research needs; citation_author=Appelbaum  D.; citation_author=Kogan  A.; citation_author=Vasarhelyi  M. A.;  citation_journal_title=Auditing: A Journal of Practice & Theory;  citation_year=2017;  citation_volume=36;  citation_issue=4;  citation_pages=1-27; "",""citation_title=Impact of business analytics and enterprise systems on managerial accounting; citation_author=Appelbaum  D.; citation_author=Kogan  A.; citation_author=Vasarhelyi  M. A.; citation_author=Yan  Z.;  citation_journal_title=International Journal of Accounting Information Systems;  citation_year=2017;  citation_volume=25;  citation_pages=29-44; "",""citation_title=A linear method for deviation detection in large databases; citation_author=Arning  A.; citation_author=Agrawal  R.; citation_author=Raghavan  P.;  citation_year=1996; "",""citation_title=The data briefing: Mapping the Big Data ecosystem of U.S. agriculture; citation_author=Brantley  B.;  citation_year=2016; "",""citation_title=Big Data and audit evidence; citation_author=Brown-Liburd  H.; citation_author=Vasarhelyi  M. A.;  citation_journal_title=Journal of Emerging Technologies in Accounting;  citation_year=2015;  citation_volume=12;  citation_issue=1;  citation_pages=1-16; "",""citation_title=Measuring with exogenous data (MED) and government economic monitoring (GEM); citation_author=Brown-Liburd  H.; citation_author=Cheong  A.; citation_author=Wang  X.; citation_author=Vasarhelyi  M. A.;  citation_journal_title=Journal of Emerging Technologies in Accounting;  citation_year=2019; "",""citation_title=Principles of rule-based expert systems; citation_author=Buchanan  B. G.; citation_author=Duda  R. O.;  citation_journal_title=Advances in Computers;  citation_year=1983;  citation_volume=22;  citation_pages=163-216; "",""citation_title=Convolutional neural networks for multimedia sentiment analysis; citation_author=Cai  G.; citation_author=Xia  B.; citation_publisher=Springer International Publishing AG, Cham, Switzerland;  citation_journal_title=Natural Language Processing and Chinese Computing;  citation_year=2015;  citation_pages=159-167; "",""citation_title=How big data and AI work together; citation_author=Casey  K.;  citation_year=2019; "",""citation_title=Detecting management fraud in public companies; citation_author=Cecchini  M.; citation_author=Aytug  H.; citation_author=Koehler  G. J.; citation_author=Pathak  P.;  citation_journal_title=Management Science;  citation_year=2010;  citation_volume=56;  citation_issue=7;  citation_pages=1146-1160; "",""citation_title=Making words work: Using financial text as a predictor of financial events; citation_author=Cecchini  M.; citation_author=Aytug  H.; citation_author=Koehler  G. J.; citation_author=Pathak  P.;  citation_journal_title=Decision Support Systems;  citation_year=2010;  citation_volume=50;  citation_issue=1;  citation_pages=164-175; "",""citation_title=If you cannot measure it, you cannot manage it: Assessing the quality of cybersecurity risk disclosure through textual imagification; citation_author=Cheong  A.; citation_author=Cho  S.; citation_author=No  W.; citation_author=Vasarhelyi  M. A.;  citation_year=2019; "",""citation_title=Exploring new audit evidence: The application of process mining in auditing; citation_author=Chiu  T.;  citation_year=2018; "",""citation_title=Using machine learning to understand the Ethereum blockchain; citation_author=ConsenSys;  citation_year=2018; "",""citation_title=Blockchain technology and its potential impact on the audit and assurance profession; citation_author=CPA Canada and AICPA;  citation_year=2017; "",""citation_title=The rise of Big Data: How it's changing the way we think about the world; citation_author=Cukier  K.; citation_author=Mayer-Schoenberger  V.;  citation_journal_title=Foreign Affairs;  citation_year=2013;  citation_volume=92;  citation_issue=3;  citation_pages=28-40; "",""citation_title=Toward blockchain-based accounting and assurance; citation_author=Dai  J.; citation_author=Vasarhelyi  M. A.;  citation_journal_title=Journal of Information Systems;  citation_year=2017;  citation_volume=31;  citation_issue=3;  citation_pages=5-21; "",""citation_title=What the shifting data center ecosystem means for education; citation_author=Dedinsky  D.;  citation_year=2019; "",""citation_title=Internal controls over financial reporting considerations for developing and implementing bots; citation_author=Deloitte;  citation_year=2018; "",""citation_title=The first ten years of public-key cryptography; citation_author=Diffie  W.;  citation_journal_title=Proceedings of the IEEE;  citation_year=1988;  citation_volume=76;  citation_issue=5;  citation_pages=560-577; "",""citation_title=Enter the data economy: EU policies for a thriving data ecosystem; citation_author=European Political Strategy Centre;  citation_year=2017; "",""citation_title=Expert systems in the 1980s; citation_author=Feigenbaum  E. A.;  citation_year=1981; "",""citation_title=The convergence computing model for big sensor data mining and knowledge discovery; citation_author=Finogeev  A. G.; citation_author=Parygin  D. S.; citation_author=Finogeev  A. A.;  citation_journal_title=Human-centric Computing and Information Sciences;  citation_year=2017;  citation_volume=7;  citation_issue=1;  citation_pages=11-16; "",""citation_title=Big Data ecosystem updates: Machine learning, deep learning, and the edge; citation_author=Foote  K. D.;  citation_year=2019; "",""citation_author=Franks  B.; citation_publisher=John Wiley & Sons, Hoboken, NJ; Taming the Big Data Tidal Wave: Finding Opportunities in Huge Data Streams with Advanced Analytics;  citation_year=2012;  citation_volume=Volume 49; "",""citation_title=Query issues in continuous reporting systems; citation_author=Gal  G.;  citation_journal_title=Journal of Emerging Technologies in Accounting;  citation_year=2008;  citation_volume=5;  citation_issue=1;  citation_pages=81-97; "",""citation_title=Extracting value from chaos; citation_author=Gantz  J.; citation_author=Reinsel  D.;  citation_year=2011; "",""citation_title=Comparison of statistical and machine learning methods in modelling of data with multicollinearity; citation_author=Garg  A.; citation_author=Tai  K.;  citation_journal_title=International Journal of Modelling Identification and Control;  citation_year=2013;  citation_volume=18;  citation_issue=4;  citation_pages=295-312; "",""citation_title=A multi-agent based system with big data processing for enhanced supply chain agility; citation_author=Giannakis  M.; citation_author=Louis  M.;  citation_journal_title=Journal of Enterprise Information Management;  citation_year=2016;  citation_volume=29;  citation_issue=5;  citation_pages=706-727; "",""citation_title=Developing risk advisor: An expert system for risk identification; citation_author=Graham  L.; citation_author=Damens  E.; citation_author=Van Ness  J.;  citation_journal_title=Auditing: A Journal of Practice & Theory;  citation_year=1991;  citation_volume=10;  citation_issue=1;  citation_pages=69-96; "",""citation_title=Blockchain for dummies; citation_author=Gupta  M.;  citation_year=2017; "",""citation_author=Hinton  G. E.; citation_author=Sejnowski  T. J.; citation_publisher=Springer Science, New York, NY; Unsupervised Learning: Encyclopedia of Machine Learning and Data Mining;  citation_year=1999; "",""citation_author=Institute of Electrical and Electronics Engineers (IEEE);  citation_year=2017; "",""citation_title=Research ideas for artificial intelligence in auditing: The formalization of audit and workforce supplementation; citation_author=Issa  H.; citation_author=Sun  T.; citation_author=Vasarhelyi  M. A.;  citation_journal_title=Journal of Emerging Technologies in Accounting;  citation_year=2016;  citation_volume=13;  citation_issue=2;  citation_pages=1-20; "",""citation_title=A field study on the use of process mining of event logs as an analytical procedure in auditing; citation_author=Jans  M.; citation_author=Alles  M. G.; citation_author=Vasarhelyi  M. A.;  citation_journal_title=The Accounting Review;  citation_year=2014;  citation_volume=89;  citation_issue=5;  citation_pages=1751-1773; "",""citation_title=Data mining tasks and methods: subgroup discovery: deviation analysis; citation_author=KlĂśsgen  W.; citation_publisher=Oxford University Press, Inc, Oxford, U.K;  citation_journal_title=Handbook of Data Mining and Knowledge Discovery;  citation_year=2002;  citation_pages=354-361; "",""citation_author=Lacity  M. C.; citation_author=Willcocks  L. P.; citation_publisher=SB Publishing, London, U.K; Robotic Process Automation and Risk Mitigation;  citation_year=2017; "",""citation_author=Lev  B.; citation_author=Gu  F.; citation_publisher=John Wiley & Sons, Hoboken, NJ; The End of Accounting and the Path Forward for Investors and Managers;  citation_year=2016; "",""citation_title=Developing a cognitive assistant for the audit plan brainstorming session; citation_author=Li  Q.; citation_author=Vasarhelyi  M. A.;  citation_journal_title=The International Journal of Digital Accounting Research;  citation_year=2018;  citation_volume=18;  citation_pages=119-140; "",""citation_title=The application of exploratory data analysis in auditing; citation_author=Liu  Q.;  citation_year=2014; "",""citation_title=Intelligent process automation: The engine at the core of the next-generation operating model; citation_author=McKinsey;  citation_year=2017; "",""citation_title=Integrated customer insights; citation_author=Mindtree;  citation_year=2017; "",""citation_title=AIS in an age of Big Data; citation_author=Moffitt  K. C.; citation_author=Vasarhelyi  M. A.;  citation_journal_title=Journal of Information Systems;  citation_year=2013;  citation_volume=27;  citation_issue=2;  citation_pages=1-19; "",""citation_title=Robotic process automation for auditing; citation_author=Moffitt  K. C.; citation_author=Rozario  A. M.; citation_author=Vasarhelyi  M. A.;  citation_journal_title=Journal of Emerging Technologies in Accounting;  citation_year=2018;  citation_volume=15;  citation_issue=1;  citation_pages=1-10; "",""citation_title=An intelligent personal assistant for task and time management; citation_author=Myers  K.; citation_author=Berry  P.; citation_author=Blythe  J.; citation_author=Conley  K.; citation_author=Gervasio  M.; citation_author=Mcguinness  D. L.; citation_author=Morley  D.; citation_author=Pfeffer  A.; citation_author=Pollack  M.; citation_author=Tambe  M.;  citation_journal_title=AI Magazine;  citation_year=2007;  citation_volume=28;  citation_issue=2; -47; "",""citation_title=Bitcoin: A peer-to-peer electronic cash system; citation_author=Nakamoto  S.;  citation_year=2008; "",""citation_title=Factorizing Yago: Scalable Machine Learning for Linked Data; citation_author=Nickel  M.; citation_author=Tresp  V.; citation_author=Kriegel  H. P.;  citation_year=2012; "",""citation_title=Multidimensional audit data selection (MADS): A framework for using data analytics in audit data selection process; citation_author=No  W. G.; citation_author=Lee  K.; citation_author=Huang  F.; citation_author=Li  Q.;  citation_journal_title=Accounting Horizons;  citation_year=2019;  citation_volume=33;  citation_issue=3;  citation_pages=127-140; "",""citation_title=Automated trading and yearly reporting: The need for RT-XBRL; citation_author=Pei  D.; citation_author=Vasarhelyi  M. A.;  citation_year=2019; "",""citation_title=The growing role of machine learning in cybersecurity; citation_author=Perlman  A.;  citation_year=2019; "",""citation_title=Financial statement fraud detection: An analysis of statistical and machine learning algorithms; citation_author=Perols  J.;  citation_journal_title=Auditing: A Journal of Practice & Theory;  citation_year=2011;  citation_volume=30;  citation_issue=2;  citation_pages=19-50; "",""citation_title=A survey of machine learning for big data processing; citation_author=Qiu  J.; citation_author=Wu  Q.; citation_author=Ding  G.; citation_author=Xu  Y.; citation_author=Feng  S.;  citation_journal_title=EURASIP Journal on Advances in Signal Processing;  citation_year=2016;  citation_volume=67;  citation_issue=May; "",""citation_title=A measurement theory perspective on business measurement; citation_author=Romero  S.; citation_author=Gal  G.; citation_author=Mock  T. J.; citation_author=Vasarhelyi  M. A.;  citation_journal_title=Journal of Emerging Technologies in Accounting;  citation_year=2012;  citation_volume=9;  citation_issue=1;  citation_pages=1-24; "",""citation_title=Gartner: Cybersecurity skills shortage requires a new approach; citation_author=Roy  M.;  citation_year=2019; "",""citation_title=Reengineering the audit with blockchain and smart contracts; citation_author=Rozario  A. M.; citation_author=Thomas  C.;  citation_journal_title=Journal of Emerging Technologies in Accounting;  citation_year=2019; "",""citation_title=Auditing with smart contracts; citation_author=Rozario  A. M.; citation_author=Vasarhelyi  M. A.;  citation_year=2018; "",""citation_title=Data ecosystems: How third-party information can enhance data analytics; citation_author=Schatsky  D.; citation_author=Camhi  J.; citation_author=Muraskin  C.;  citation_year=2019; "",""citation_title=Developing ExperTAXsm: An expert system for corporate-tax accrual and planning; citation_author=Shpilberg  D.; citation_author=Graham  L. E.;  citation_journal_title=Auditing: A Journal of Practice & Theory;  citation_year=1986;  citation_volume=6;  citation_issue=1;  citation_pages=75-94; "",""citation_title=The machine learning bazaar: Harnessing the ML ecosystem for effective system development; citation_author=Smith  M. J.; citation_author=Sala  C.; citation_author=Kanter  J. M.; citation_author=Veeramachaneni  K.;  citation_year=2019; "",""citation_author=Sullivan  J.; citation_author=Zutavern  A.; citation_publisher=Hachette UK, London, U.K; The Mathematical Corporation: Where Machine Intelligence and Human Ingenuity Achieve the Impossible;  citation_year=2017; "",""citation_author=Sutton  R.; citation_author=Barto  A. G.; citation_publisher=MIT Press, Cambridge, MA; Reinforcement Learning: An Introduction;  citation_year=2018; "",""citation_title=Smart contracts; citation_author=Szabo  N.;  citation_year=1994; "",""citation_title=The remote audit; citation_author=Teeter  R. A.; citation_author=Alles  M. G.; citation_author=Vasarhelyi  M. A.;  citation_journal_title=Journal of Emerging Technologies in Accounting;  citation_year=2010;  citation_volume=7;  citation_issue=1;  citation_pages=73-88; "",""citation_title=How the world will change as computers spread into everyday objects;  citation_journal_title=The Economist;  citation_year=2019;  citation_issue=September 12; "",""citation_title=Masters of the universe;  citation_journal_title=The Economist;  citation_year=2019;  citation_issue=October 5); "",""citation_title=Accounting information systems: The challenge of the real-time reporting; citation_author=Trigo  A.; citation_author=Belfo  F.; citation_author=EstĂŠbanez  R. P.;  citation_journal_title=Procedia Technology;  citation_year=2014;  citation_volume=16;  citation_pages=118-127; "",""citation_author=Tukey  J. W.; citation_publisher=Addison-Wesley, Boston, MA; Exploratory Data Analysis;  citation_year=1977; "",""citation_author=Vasarhelyi  M. A.; citation_publisher=Markus Wiener Publishers, Inc, Princeton, NJ; Artificial Intelligence and Expert Systems in Accounting and Auditing;  citation_year=1989;  citation_volume=Volume 1; "",""citation_author=Vasarhelyi  M. A.; citation_publisher=Markus Wiener Publishers, Princeton, NJ; Artificial Intelligence and Expert Systems in Accounting and Auditing;  citation_year=1994;  citation_volume=Volume 2; "",""citation_author=Vasarhelyi  M. A.; citation_publisher=Markus Wiener Publishers, Princeton, NJ; Artificial Intelligence and Expert Systems in Accounting and Auditing. Volume 3;  citation_year=1994; "",""citation_title=The continuous audit of online systems; citation_author=Vasarhelyi  M. A.; citation_author=Halper  F. B.;  citation_journal_title=Auditing: A Journal of Practice & Theory;  citation_year=1991;  citation_volume=10;  citation_issue=1;  citation_pages=110-125; "",""citation_author=Vasarhelyi  M. A.; citation_author=Kogan  A.; citation_publisher=Markus Wiener Publishers, Princeton, NJ; Artificial Intelligence in Accounting and Auditing: Towards New Paradigms. Volume 4;  citation_year=1998; "",""citation_author=Vasarhelyi  M. A.; citation_author=O'Leary  D.; citation_publisher=Markus Wiener Publishers, Princeton, NJ; Artificial Intelligence in Accounting and Auditing: Adding Value to Business. Volume 5;  citation_year=2005; "",""citation_title=Intelligent software agents in accounting: An evolving scenario; citation_author=Vasarhelyi  M. A.; citation_author=Hoitash  R.;  citation_year=2005; "",""citation_title=What CPAs should know about machine learning vs. deep learning; citation_author=Vetter  A.;  citation_year=2018; "",""citation_title=Distributed ledger technology: Beyond blockchain; citation_author=Walport  M.;  citation_year=2016; "",""citation_title=Designing confidentiality: Preserving blockchain-based transaction processing systems; citation_author=Wang  Y.; citation_author=Kogan  A.;  citation_journal_title=International Journal of Accounting Information Systems;  citation_year=2018;  citation_volume=30;  citation_issue=September;  citation_pages=1-18; "",""citation_title=Machine learning for ecosystem services; citation_author=Willcock  S.; citation_author=MartĂ­nez-LĂłpez  J.; citation_author=Hooftman  D. A. P.; citation_author=Bagstad  K. J.; citation_author=Balbi  S.; citation_author=Marzo  A.; citation_author=Prato  C.; citation_author=Sciandrello  S.; citation_author=Signorello  G.; citation_author=Voigt  B.; citation_author=Villa  F.; citation_author=Bullock  J. M.; citation_author=Athanasiadis  I. N.;  citation_journal_title=Ecosystem Services;  citation_year=2018;  citation_volume=33;  citation_issue=B;  citation_pages=165-174; "",""citation_title=Big Data as audit evidence: Utilizing weather indicators; citation_author=Yoon  K.; citation_author=Kogan  A.; citation_author=Vasarhelyi  M. A.; citation_publisher=University of San Francisco;  citation_year=2019; "",""citation_title=Intelligent process automation in audit; citation_author=Zhang  C.;  citation_journal_title=Journal of Emerging Technologies in Accounting;  citation_year=2019; "",""citation_author=Zhang  C.; citation_author=Ma  Y.; citation_publisher=Springer Science and Business Media, New York, NY; Ensemble Machine Learning: Methods and Applications;  citation_year=2012; "",""citation_title=The impact of disruptive technologies on accounting and auditing education: How should the profession adapt?; citation_author=Zhang  C. A.; citation_author=Dai  J.; citation_author=Vasarhelyi  M. A.;  citation_journal_title=The CPA Journal;  citation_year=2018;  citation_volume=88;  citation_issue=9;  citation_pages=20-26; "",""citation_title=New methods for deviation-based outlier detection in large database; citation_author=Zhang  Z.; citation_author=Feng  X.; citation_publisher=IEEE, Piscataway, NJ;  citation_journal_title=Proceedings of the 2009 Sixth International Conference on Fuzzy Systems and Knowledge Discovery;  citation_year=2009;  citation_volume=Volume 1;  citation_pages=495-499; "",""citation_author=Zuboff  S.; citation_publisher=PublicAffairs, New York, NY; The Age of Surveillance Capitalism: The Fight for a Human Future at the New Frontier of Power;  citation_year=2019; ""
""citation_publisher"",""Allen Press""
""citation_journal_title"",""Journal of Emerging Technologies in Accounting""
""language"",""en""
""title"",""The Forthcoming Data Ecosystem for Business Measurement and Assurance | Journal of Emerging Technologies in Accounting""
""citation_issn"",""1554-1908""
""dc:title"",""The Forthcoming Data Ecosystem for Business Measurement and Assurance | Journal of Emerging Technologies in Accounting""
""Content-Encoding"",""UTF-8""
""Content-Type-Hint"",""text/html; charset=utf-8""
""citation_pdf_url"",""https://meridian.allenpress.com/jeta/article-pdf/16/2/1/2424840/jeta-10699.pdf""
""Content-Length"",""91487""
""citation_xml_url"",""https://meridian.allenpress.com/jeta/article-xml/16/2/1/428475""
""citation_lastpage"",""21""
""Content-Type"",""text/html; charset=UTF-8""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""citation_journal_abbrev"",""Journal of Emerging Technologies in Accounting""
""citation_author"",""Cho, Soohyun"",""Vasarhelyi, Miklos A."",""Zhang, Chanyuan (Abigail)""
""resourceName"",""jeta-10699""
""citation_issue"",""2""
""X-UA-Compatible"",""IE=Edge""
""citation_firstpage"",""1""
""viewport"",""width=device-width, initial-scale=1, maximum-scale=1""
""citation_doi"",""10.2308/jeta-10699""
""citation_volume"",""16""
""Content-Language"",""en""
""format-detection"",""telephone=no""
";https://scholar.google.com/scholar?start=660&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094548-686;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Deniable Secret Handshake Protocol-Revisited;S Panja, S Dutta, K Sakurai ; International Conference on Advanced …, 2019  Springer;;"… In: IEEE S&P 2003, pp. 180–196 (2003)Google Scholar. 2. Bellare, M., Rogaway, P.: Random

oracles are practical: a paradigm for designing efficient protocols … Pass, R.: On deniability in the

common reference string and random oracle model. In: CRYPTO 2003, pp …";Cité 1 fois;Les 2 versions;null;;;;https://scholar.google.com/scholar?start=500&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094569-780;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[HTML][HTML] Creating markets in no-trust environments: The law and economics of smart contracts;H Eenmaa;Dimitrieva, MJ SchmidtKessen  Computer law & security …, 2019  Elsevier;;"… that can arise due to smart contracts having to rely on third-party sources, so-called oracles, to

verify whether a relevant event for the smart contract has occurred in the real world. 59 Many

authors point out that the reliance on sources external to the blockchain that could be …";Cité 17 fois;Les 5 versions;[HTML] sciencedirect.com;https://www.sciencedirect.com/science/article/pii/S0267364918303558?casa_token=0b_y2HDfIFUAAAAA:lVigJQ3rXs9qMNePyxofO9hY0sXRxvune6NgRzm1c1BdM8oPtYCfHOHJdj2hFCwwVLQ891Zp;;;https://scholar.google.com/scholar?start=590&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094654-1133;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[CITATION][C] Updatable crs simulationextractable zk-snarks with a single verification;J Kim, J Lee, H Oh ; … Report 2019/586, 2019. https://eprint …;;null;Cité 4 fois;;null;;;;https://scholar.google.com/scholar?start=950&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094597-900;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[HTML][HTML] ???????? ????????????? ?????-?????????? ?? ???????;?? ??? ; ?????????? ???????? ??????????? ?????, 2019  cyberleninka.ru;;"… ??????. ?????????? ???????? ??????????? ????? 2019. ???. ??????? ????. ?????.

???????? ?????. ???????? / ?????-???????? / ?????? / ??????? / ???????? /

BLOCKCHAIN / SMART CONTRACT / ORACLE / CONTRACT / PROGRAM …";Cité 6 fois;Les 5 versions;[HTML] cyberleninka.ru;https://cyberleninka.ru/article/n/18282846;;"""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""Content-Encoding"",""UTF-8""
""resourceName"",""18282846""
""language"",""en""
""Content-Length"",""98""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=710&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094588-853;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[PDF][PDF] Key Legal Issues Surrounding Smart Contract Applications;PS Bayón ;2019 klri.re.kr;;"… should avoid clauses that could be self-executed by SC that use external oracles that are … Likewise,

the proposal of optimal systems for resolving conflicts in blockchain will have to play a highly … by

alternative mechanisms, such as the creation of a SC linked to an oracle (a notary …";Cité 2 fois;Les 2 versions;[PDF] klri.re.kr;http://klri.re.kr:9090/bitstream/2017.oak/8945/1/17711k.pdf;;"""date"",""2019-05-28T04:23:26Z""
""pdf:PDFVersion"",""1.4""
""xmp:CreatorTool"",""PScript5.dll Version 5.2.2""
""pdf:docinfo:title"",""3. PABLO SANZ BAYON_내지(63-92).hwp""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""language"",""en""
""dc:format"",""application/pdf; version=1.4""
""pdf:docinfo:creator_tool"",""PScript5.dll Version 5.2.2""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""3. PABLO SANZ BAYON_내지(63-92).hwp""
""xmp:CreateDate"",""2019-05-28T13:23:26Z""
""modified"",""2019-05-28T04:23:26Z""
""pdf:hasMarkedContent"",""false""
""xmp:ModifyDate"",""2019-05-28T13:23:26Z""
""pdf:docinfo:creator"",""Administrator""
""meta:author"",""Administrator""
""meta:creation-date"",""2019-05-28T04:23:26Z""
""created"",""2019-05-28T04:23:26Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-05-28T04:23:26Z""
""resourceName"",""17711k.pdf""
""Author"",""Administrator""
""producer"",""Acrobat Distiller 10.1.16 (Windows)""
""pdf:docinfo:producer"",""Acrobat Distiller 10.1.16 (Windows)""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""access_permission:modify_annotations"",""true""
""dc:creator"",""Administrator""
""dcterms:created"",""2019-05-28T04:23:26Z""
""Last-Modified"",""2019-05-28T04:23:26Z""
""dcterms:modified"",""2019-05-28T04:23:26Z""
""title"",""3. PABLO SANZ BAYON_내지(63-92).hwp""
""xmpMM:DocumentID"",""uuid:f41f346f-e7ab-4210-be38-2997f91b6c2c""
""Last-Save-Date"",""2019-05-28T04:23:26Z""
""pdf:docinfo:modified"",""2019-05-28T04:23:26Z""
""meta:save-date"",""2019-05-28T04:23:26Z""
""Content-Length"",""198676""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Administrator""
""pdf:producer"",""Acrobat Distiller 10.1.16 (Windows)""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""30""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""788"",""1029"",""3253"",""2822"",""3007"",""3107"",""3174"",""2891"",""3061"",""2970"",""3043"",""2755"",""2661"",""3163"",""2504"",""2824"",""2707"",""3013"",""3029"",""2610"",""3307"",""2825"",""3318"",""2501"",""1226"",""2236"",""2316"",""2352"",""1409"",""0""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-05-28T04:23:26Z""
";https://scholar.google.com/scholar?start=670&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094595-887;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Smart contracts: a Requiem;DE Mik ; Journal of Contract Law, Forthcoming, 2019  papers.ssrn.com;;"… they were rightful “owners” of the crypto-asset in question, etc … and cannot be validated. If goods

are to be paid for with a cryptocurrency, the blockchain cannot determine … must rely on third parties

(so-called “oracles”) that confirm delivery and, if possible, conformance …";Cité 3 fois;;null;;;;https://scholar.google.com/scholar?start=700&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094621-999;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[HTML][HTML] Machine learning based privacy-preserving fair data trading in big data market;Y Zhao, Y Yu, Y Li, G Han, X Du ; Information Sciences, 2019  Elsevier;;"… 2.2. Security requirements. The following security requirements should be achieved in a

blockchain-based data trading protocol … s k ? = z 1 p 2 p 2 ? p 1 + z 2 p 1 p 1 ? p 2 ( a , b ) =

Y ? H 1 ( s k ? ). The DAPS is provably secure in the random oracle model …";Cité 38 fois;Les 2 versions;[HTML] sciencedirect.com;https://www.sciencedirect.com/science/article/pii/S0020025518309174?casa_token=RJSHJDJRAsgAAAAA:_xCNYCFuV7A17HG39LDVH0Ozt_AXVluz9oq6lbLOaXhRzX9PYPNc8FEFjWmxUHq0Zidb86o7;;;https://scholar.google.com/scholar?start=810&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094576-802;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[PDF][PDF] Aplikace technologie Blockchain ve smluvním právu;K Juran ;2019 is.muni.cz;;"… Ústav pr{va a technologií Brno 2019 Aplikace technologie Blockchain ve smluvním právu

Diplomová práce Kirill Juran … Problematika je zpracov{na z pohledu ?eského pr{va. Klí?ov{ slova

Blockchain, smart contracts, DAO, ICO, DAPPs, vymahatelnost, platnost smlouvy. Abstract …";Autres articles;;[PDF] muni.cz;https://is.muni.cz/th/uprl5/Juran_Mgr_final_JM_jaz4f.pdf;;"""date"",""2019-03-27T16:10:53Z""
""pdf:PDFVersion"",""1.4""
""xmp:CreatorTool"",""MicrosoftÂŽ Office Word 2007""
""pdf:docinfo:title"",""Aplikace technologie Blockchain ve smluvnĂ­m prĂĄvu""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""pdfa:PDFVersion"",""A-1b""
""language"",""cs""
""dc:format"",""application/pdf; version=""""A-1b"""""",""application/pdf; version=1.4""
""pdf:docinfo:creator_tool"",""MicrosoftÂŽ Office Word 2007""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""Aplikace technologie Blockchain ve smluvnĂ­m prĂĄvu""
""xmp:CreateDate"",""2019-03-27T16:10:53Z""
""modified"",""2019-03-27T16:10:53Z""
""pdf:hasMarkedContent"",""false""
""xmp:ModifyDate"",""2019-03-27T16:10:53Z""
""pdf:docinfo:creator"",""Kirill Juran""
""meta:author"",""Kirill Juran""
""meta:creation-date"",""2019-03-27T16:10:53Z""
""created"",""2019-03-27T16:10:53Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-03-27T16:10:53Z""
""resourceName"",""Juran_Mgr_final_JM_jaz4f.pdf""
""pdfaid:part"",""1""
""Author"",""Kirill Juran""
""producer"",""MicrosoftÂŽ Office Word 2007""
""pdf:docinfo:producer"",""MicrosoftÂŽ Office Word 2007""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""access_permission:modify_annotations"",""true""
""dc:creator"",""Kirill Juran""
""dcterms:created"",""2019-03-27T16:10:53Z""
""Last-Modified"",""2019-03-27T16:10:53Z""
""dcterms:modified"",""2019-03-27T16:10:53Z""
""title"",""Aplikace technologie Blockchain ve smluvnĂ­m prĂĄvu""
""xmpMM:DocumentID"",""1E7793D4-E526-4657-9B6D-75AAD4ECEE08""
""Last-Save-Date"",""2019-03-27T16:10:53Z""
""pdf:docinfo:modified"",""2019-03-27T16:10:53Z""
""meta:save-date"",""2019-03-27T16:10:53Z""
""Content-Length"",""2289692""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""pdfaid:conformance"",""B""
""creator"",""Kirill Juran""
""dc:language"",""cs-CZ""
""pdf:producer"",""MicrosoftÂŽ Office Word 2007""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""91""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""170"",""0"",""375"",""0"",""535"",""0"",""1224"",""0"",""1791"",""775"",""245"",""935"",""2429"",""2763"",""2567"",""371"",""2534"",""2334"",""2379"",""2512"",""2436"",""2653"",""298"",""2313"",""3163"",""2878"",""2511"",""2685"",""2455"",""2699"",""1498"",""1112"",""2252"",""2363"",""2591"",""2552"",""2771"",""2470"",""2759"",""2095"",""2158"",""2564"",""2730"",""2756"",""2335"",""2866"",""2514"",""3041"",""2941"",""2566"",""2424"",""2926"",""2429"",""2525"",""2612"",""2590"",""2743"",""2656"",""2841"",""2571"",""2706"",""2777"",""2283"",""2328"",""2846"",""2517"",""2664"",""2250"",""2587"",""3193"",""2313"",""2417"",""2786"",""2747"",""2526"",""3159"",""747"",""2479"",""2658"",""1267"",""1951"",""2072"",""1981"",""2140"",""1850"",""1952"",""1967"",""2085"",""2044"",""2054"",""1582""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-03-27T16:10:53Z""
";https://scholar.google.com/scholar?start=620&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094579-815;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;A minimal core calculus for Solidity contracts;M Bartoletti, L Galletta, M Murgia ; … , Cryptocurrencies and Blockchain …, 2019  Springer;;"… transactions, which represent procedure calls, and may possibly involve transfers of

crypto-currency from … The sequence of transactions on the blockchain determines the state of each

contract, and … on the most basic features of Solidity, ie transfers of cryptocurrency and external …";Cité 11 fois;Les 5 versions;[PDF] arxiv.org;https://arxiv.org/pdf/1908.02709;;"""date"",""2019-08-08T01:56:10Z""
""pdf:PDFVersion"",""1.4""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.4""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""xmp:CreateDate"",""2019-08-07T21:56:10Z""
""modified"",""2019-08-08T01:56:10Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""xmp:ModifyDate"",""2019-08-07T21:56:10Z""
""pdf:docinfo:creator"",""""
""meta:author"",""""
""meta:creation-date"",""2019-08-08T01:56:10Z""
""created"",""2019-08-08T01:56:10Z""
""xmp:About"",""uuid:3e2ceec5-f19c-11f4-0000-cdb06305a382""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-08-08T01:56:10Z""
""resourceName"",""1908.02709""
""Author"",""""
""producer"",""dvips + GPL Ghostscript GIT PRERELEASE 9.22""
""pdf:docinfo:producer"",""dvips + GPL Ghostscript GIT PRERELEASE 9.22""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""2"",""80"",""14"",""48"",""38"",""0"",""0"",""0"",""0"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2019-08-08T01:56:10Z""
""Last-Modified"",""2019-08-08T01:56:10Z""
""dcterms:modified"",""2019-08-08T01:56:10Z""
""title"",""""
""xmpMM:DocumentID"",""uuid:3e2ceec5-f19c-11f4-0000-cdb06305a382""
""Last-Save-Date"",""2019-08-08T01:56:10Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2019-08-08T01:56:10Z""
""meta:save-date"",""2019-08-08T01:56:10Z""
""Content-Length"",""245208""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""14""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""2283"",""2964"",""2606"",""1803"",""2081"",""2113"",""1411"",""1485"",""1751"",""1494"",""1861"",""1848"",""2805"",""2563""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-08-08T01:56:10Z""
";https://scholar.google.com/scholar?start=630&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094635-1056;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Sok: A systematic study of anonymity in cryptocurrencies;N Alsalami, B Zhang ; 2019 IEEE Conference on Dependable …, 2019  ieeexplore.ieee.org;;"… Hence, the crypto community has been looking for a more succinct and faster to verify which … This

commitment [52] is used in many blockchain platforms, such as Monero … knowledge proofs require

some setup assumptions, such as common reference string, random oracle, etc …";Cité 11 fois;Les 5 versions;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/8930388/8937557/08937681.pdf?casa_token=mAeBYeWw8dcAAAAA:MRic3fDuLORFZdoipDY0KgYyf8arPAD5t7XdFZOOm8rP6uTYIOxEvh2kDTovXlM4dDl8s0IPeeE;;"""og:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""twitter:title"",""SoK: A Systematic Study of Anonymity in Cryptocurrencies""
""twitter:card"",""summary""
""Description"",""Blockchain and cryptocurrencies have been widely deployed and used in our daily life. Although there are numerous works in the literature surveying technical ch""
""og:title"",""SoK: A Systematic Study of Anonymity in Cryptocurrencies""
""resourceName"",""08937681.pdf""
""language"",""en""
""title"",""SoK: A Systematic Study of Anonymity in Cryptocurrencies | IEEE Conference Publication | IEEE Xplore""
""og:description"",""Blockchain and cryptocurrencies have been widely deployed and used in our daily life. Although there are numerous works in the literature surveying technical challenges and security issues in blockchains, very few works focused on the anonymity guarantees provided in cryptocurrencies. In this work, we conduct a systematic survey on anonymity in cryptocurrencies with a clear categorization for the different tiers of anonymity offered in the various cryptocurrencies as well as their known weaknesses and vulnerabilities. We also study the techniques that have been used to achieve each tier of anonymity. Finally, we asses the current techniques, and present a forecast for the technological trends in this field.""
""twitter:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-UA-Compatible"",""IE=Edge""
""viewport"",""width=device-width, initial-scale=1.0""
""dc:title"",""SoK: A Systematic Study of Anonymity in Cryptocurrencies | IEEE Conference Publication | IEEE Xplore""
""twitter:description"",""Blockchain and cryptocurrencies have been widely deployed and used in our daily life. Although there are numerous works in the literature surveying technical challenges and security issues in blockchains, very few works focused on the anonymity guarantees provided in cryptocurrencies. In this work, we conduct a systematic survey on anonymity in cryptocurrencies with a clear categorization for the different tiers of anonymity offered in the various cryptocurrencies as well as their known weaknesses and vulnerabilities. We also study the techniques that have been used to achieve each tier of anonymity. Finally, we asses the current techniques, and present a forecast for the technological trends in this field.""
""Content-Encoding"",""UTF-8""
""Content-Type-Hint"",""text/html; charset=utf-8""
""Content-Length"",""39285""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=870&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094654-1131;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Blockchain-Based Ubiquitous Transport and Logistics Monitoring System;A Rivero;García, I SantosGonzález…  Multidisciplinary Digital …, 2019  mdpi.com;;"… Some communications, like the smartphone and web application query to the blockchain using

the oracle, can be made in a parallel way, allowing that more than one user or authority can

verify the correctness and trace of the container and his merchandise …";Cité 2 fois;Les 2 versions;[PDF] mdpi.com;https://www.mdpi.com/2504-3900/31/1/9/pdf;;;https://scholar.google.com/scholar?start=950&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094616-978;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[PDF][PDF] Towards a Decentralized Certificate Authority;K Finlow;Bates 2019 researchgate.net;;"… but the requirements for an OV certificate can be met through leveraging the checks performed

by current Cryptocurrency Exchanges (verification … DCA blockchain genesis block, 2) Report

existing root certificates on the blockchain, 3) Establish a blockchain Oracle to determine …";Autres articles;Version HTML;[PDF] researchgate.net;https://www.researchgate.net/profile/Keir_Finlow-Bates/publication/339948587_Towards_a_Decentralized_Certificate_Authority/links/5e6f6998299bf12e23ca5620/Towards-a-Decentralized-Certificate-Authority.pdf;;;https://scholar.google.com/scholar?start=790&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094658-1152;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Structure-preserving and re-randomizable RCCA-secure public key encryption and its applications;A Faonio, D Fiore, J Herranz, C Rŕfols ; … on the Theory and Application of …, 2019  Springer;;"… state of the art perfectly re-randomizable schemes (eg, Prabhakaran and Rosulek, CRYPTO'07 …

protocol is the most efficient universally verifiable Mix-Net (without random oracle) where the … the

standard model, whereas the one in [14] rely on non-programmable random oracles …";Cité 8 fois;Les 2 versions;[PDF] iacr.org;https://eprint.iacr.org/2019/955.pdf;;"""date"",""2021-03-16T19:28:02Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2021-03-16T19:28:02Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.20 (TeX Live 2019/Debian) kpathsea version 6.3.1""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2021-03-16T19:28:02Z""
""created"",""2021-03-16T19:28:02Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2021-03-16T19:28:02Z""
""resourceName"",""955.pdf""
""Author"",""""
""producer"",""pdfTeX-1.40.20""
""pdf:docinfo:producer"",""pdfTeX-1.40.20""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""5"",""0"",""50"",""14"",""28"",""5"",""36"",""55"",""48"",""21"",""28"",""32"",""28"",""30"",""16"",""6"",""43"",""26"",""28"",""15"",""29"",""10"",""19"",""13"",""10"",""0"",""0"",""30"",""46"",""23"",""36"",""13"",""34"",""10"",""16"",""26"",""37"",""0"",""0"",""0"",""12"",""13"",""18"",""22"",""1""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2021-03-16T19:28:02Z""
""Last-Modified"",""2021-03-16T19:28:02Z""
""dcterms:modified"",""2021-03-16T19:28:02Z""
""title"",""""
""Last-Save-Date"",""2021-03-16T19:28:02Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2021-03-16T19:28:02Z""
""meta:save-date"",""2021-03-16T19:28:02Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.20 (TeX Live 2019/Debian) kpathsea version 6.3.1""
""Content-Length"",""662575""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""49""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""1370"",""2697"",""3468"",""3600"",""3180"",""3271"",""3306"",""3067"",""1954"",""2644"",""2164"",""1994"",""2309"",""2765"",""2338"",""2374"",""2253"",""2430"",""2197"",""2822"",""2571"",""2938"",""2815"",""3190"",""3084"",""2294"",""3186"",""3363"",""2897"",""3837"",""4383"",""2673"",""1745"",""2730"",""2527"",""2892"",""2653"",""2943"",""2586"",""2144"",""2259"",""3501"",""3163"",""2517"",""2222"",""2682"",""2256"",""2060"",""249""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2021-03-16T19:28:02Z""
";https://scholar.google.com/scholar?start=970&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094649-1114;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Towards a Multi-chain Future of Proof-of-Space;S Tang, J Zheng, Y Deng, Z Wang, Z Liu, D Gu… ; … Conference on Security …, 2019  Springer;;"… A PoC scheme built on a hash oracle H is described as \(\mathrm {\Pi }_{\text {PoC}}=(\textsf

{init},\textsf … Scholar. 7. Kiayias, A., Russell, A., David, B., Oliynykov, R.: Ouroboros: a provably

secure proof-of-stake blockchain protocol. In: Katz, J., Shacham, H. (eds.) CRYPTO 2017 …";Cité 1 fois;Les 3 versions;[PDF] arxiv.org;https://arxiv.org/pdf/1907.07896;;"""date"",""2019-07-19T00:54:22Z""
""pdf:PDFVersion"",""1.4""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.4""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""xmp:CreateDate"",""2019-07-18T20:54:22Z""
""modified"",""2019-07-19T00:54:22Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""xmp:ModifyDate"",""2019-07-18T20:54:22Z""
""pdf:docinfo:creator"",""""
""meta:author"",""""
""meta:creation-date"",""2019-07-19T00:54:22Z""
""created"",""2019-07-19T00:54:22Z""
""xmp:About"",""uuid:4bc5c520-e1dc-11f4-0000-87c597f89426""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-07-19T00:54:22Z""
""resourceName"",""1907.07896""
""Author"",""""
""producer"",""dvips + GPL Ghostscript GIT PRERELEASE 9.22""
""pdf:docinfo:producer"",""dvips + GPL Ghostscript GIT PRERELEASE 9.22""
""pdf:unmappedUnicodeCharsPerPage"",""2"",""0"",""0"",""0"",""5"",""3"",""3"",""1"",""4"",""16"",""0"",""6"",""0"",""0"",""0"",""22""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2019-07-19T00:54:22Z""
""Last-Modified"",""2019-07-19T00:54:22Z""
""dcterms:modified"",""2019-07-19T00:54:22Z""
""title"",""""
""xmpMM:DocumentID"",""uuid:4bc5c520-e1dc-11f4-0000-87c597f89426""
""Last-Save-Date"",""2019-07-19T00:54:22Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2019-07-19T00:54:22Z""
""meta:save-date"",""2019-07-19T00:54:22Z""
""Content-Length"",""268639""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""16""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""2119"",""2696"",""1905"",""2286"",""2218"",""1842"",""2334"",""2303"",""1798"",""1100"",""1349"",""1658"",""1726"",""2899"",""2212"",""2184""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-07-19T00:54:22Z""
";https://scholar.google.com/scholar?start=930&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094640-1077;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Secure Stern signatures in quantum random oracle model;H Feng, J Liu, Q Wu ; International Conference on Information Security, 2019  Springer;;"… In the classical world, this transformation could give a secure signature in the Random

Oracle Model (ROM), and its security proof relies on the abilities of rewinding Turing

Machines and adaptively programming random oracles …";Cité 2 fois;;null;;;;https://scholar.google.com/scholar?start=890&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094658-1158;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[PDF][PDF] Student Privacy Preserving Framework Based on Blockchain Technology;S Noureen ;2019 thesis.cust.edu.pk;;"… sumption (DBDH) in the random oracle model. Also because of (IB-PRES) our … The well-known

application of blockchain technology is Bitcoin [47], which is a cryptocurrency whose users without

going through the central banking authority can make and receive payments …";Cité 1 fois;;[PDF] cust.edu.pk;https://thesis.cust.edu.pk/UploadedFiles/Saba%20Noureen.pdf;;;https://scholar.google.com/scholar?start=970&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094628-1024;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[CITATION][C] Blockchain und Distributed Ledgers–Grundlagen, Technologien, Funktionsweisen;Z Fazekas;;;null;Autres articles;;null;;;;https://scholar.google.com/scholar?start=840&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094616-979;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Security Analysis and Improvement of a Certificateless Signature Scheme in the Standard Model;X YANG, M WANG, X PEI, Y LI, C CHEN… ; Acta Electronica …, 2019  en.cnki.com.cn;;"… and Jing proposed a strongly unforgeable certificateless signature scheme whose security does

not depend on the ideal random oracle.In this … the improved scheme has lower computational

overhead and shorter private key length,and can be applied to blockchain,Internet of …";Cité 2 fois;En cache;null;;;;https://scholar.google.com/scholar?start=790&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094609-945;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Adaptively Single-Key Secure Constrained PRFs for;N Attrapadung, T Matsuda, R Nishimaki… ; … Workshop on Public …, 2019  Springer;;"… In the random oracle model, Hofheinz, Kamath, Koppula and Waters [32] constructed an adaptively

secure collusion-resistant CPRF for all circuits without relying on complexity leveraging based

on indistinguishability obfuscation (IO) [4, 27], and Attrapadung et al …";Cité 3 fois;Les 2 versions;[PDF] iacr.org;https://eprint.iacr.org/2018/1000.pdf;;"""date"",""2019-04-03T07:29:22Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2019-04-03T07:29:22Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017/W32TeX) kpathsea version 6.2.3""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2019-04-03T07:29:22Z""
""created"",""2019-04-03T07:29:22Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-04-03T07:29:22Z""
""resourceName"",""1000.pdf""
""Author"",""""
""producer"",""pdfTeX-1.40.18""
""pdf:docinfo:producer"",""pdfTeX-1.40.18""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""1"",""1"",""7"",""26"",""0"",""3"",""12"",""4"",""39"",""2"",""4"",""16"",""37"",""11"",""22"",""13"",""13"",""21"",""37"",""51"",""85"",""48"",""44"",""21"",""35"",""10"",""14"",""7"",""27"",""10"",""6"",""0"",""0"",""0"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2019-04-03T07:29:22Z""
""Last-Modified"",""2019-04-03T07:29:22Z""
""dcterms:modified"",""2019-04-03T07:29:22Z""
""title"",""""
""Last-Save-Date"",""2019-04-03T07:29:22Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2019-04-03T07:29:22Z""
""meta:save-date"",""2019-04-03T07:29:22Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017/W32TeX) kpathsea version 6.2.3""
""Content-Length"",""557605""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""39""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""1074"",""980"",""3431"",""2925"",""3286"",""3130"",""3308"",""3532"",""2969"",""2548"",""2377"",""2660"",""2668"",""1829"",""1847"",""2114"",""2012"",""1678"",""2102"",""1818"",""2058"",""1315"",""1614"",""1563"",""1346"",""1797"",""2452"",""2135"",""2010"",""2180"",""1651"",""2621"",""3072"",""2835"",""2465"",""2492"",""2628"",""2459"",""367""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-04-03T07:29:22Z""
";https://scholar.google.com/scholar?start=760&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094562-750;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[PDF][PDF] Adoçăo de blockchain na gestăo de cadeias de suprimentos do Brasil;M Aquino ;2019 fgvcelog.fgv.br;;"… Depois de vários meses de discussőes no setor, o ano fechou com a primeira

experimentaçăo da aplicabilidade de blockchain da indústria no “Logistics Tech

Challenge”, organizado por Intelipost, Oracle e a ABRALOG: uma maratona de …";Cité 1 fois;Les 2 versions;[PDF] fgv.br;https://fgvcelog.fgv.br/sites/gvcelog.fgv.br/files/dissertacoes/magali_aquino-adocao_de_blockchain_na_gestao_de_cadeias_de_suprimentos_do_brasil_magali_aquino.pdf;;"""date"",""2019-04-02T23:58:31Z""
""pdf:PDFVersion"",""1.3""
""pdf:docinfo:title"",""Adoção de Blockchain na Gestão de Cadeias de Suprimentos do Brasil Magali Aquino""
""xmp:CreatorTool"",""Word""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""pt""
""dc:format"",""application/pdf; version=1.3""
""pdf:docinfo:creator_tool"",""Word""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""Adoção de Blockchain na Gestão de Cadeias de Suprimentos do Brasil Magali Aquino""
""modified"",""2019-04-02T23:58:31Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""Magali Aquino""
""meta:author"",""Magali Aquino""
""meta:creation-date"",""2019-04-02T23:58:31Z""
""created"",""2019-04-02T23:58:31Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-04-02T23:58:31Z""
""resourceName"",""magali_aquino-adocao_de_blockchain_na_gestao_de_cadeias_de_suprimentos_do_brasil_magali_aquino.pdf""
""Author"",""Magali Aquino""
""producer"",""macOS VersĂŁo 10.14.3 (Fase 18D109) Quartz PDFContext""
""pdf:docinfo:producer"",""macOS VersĂŁo 10.14.3 (Fase 18D109) Quartz PDFContext""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""Magali Aquino""
""dcterms:created"",""2019-04-02T23:58:31Z""
""Last-Modified"",""2019-04-02T23:58:31Z""
""dcterms:modified"",""2019-04-02T23:58:31Z""
""title"",""Adoção de Blockchain na Gestão de Cadeias de Suprimentos do Brasil Magali Aquino""
""Last-Save-Date"",""2019-04-02T23:58:31Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2019-04-02T23:58:31Z""
""meta:save-date"",""2019-04-02T23:58:31Z""
""Content-Length"",""3115463""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Magali Aquino""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""86""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""196"",""419"",""788"",""733"",""243"",""1401"",""2302"",""2062"",""3315"",""559"",""247"",""1533"",""207"",""2982"",""2300"",""2589"",""1432"",""2228"",""734"",""2320"",""2888"",""2536"",""1536"",""1870"",""2437"",""2451"",""1224"",""2225"",""2529"",""2520"",""2402"",""2442"",""2269"",""2262"",""1247"",""1623"",""2069"",""2496"",""2501"",""1167"",""2764"",""2353"",""2297"",""2327"",""1635"",""2239"",""2421"",""1944"",""318"",""1762"",""74"",""99"",""239"",""2548"",""162"",""1473"",""731"",""6"",""2564"",""2411"",""566"",""675"",""1468"",""2290"",""1530"",""284"",""110"",""114"",""104"",""803"",""2161"",""1091"",""1556"",""1593"",""1641"",""1845"",""1677"",""1814"",""1702"",""962"",""2557"",""308"",""1292"",""1248"",""2799"",""3089""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-04-02T23:58:31Z""
";https://scholar.google.com/scholar?start=560&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094619-988;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Password-based Selective Linkable Convertible Ring Blind Signature;Y Zhang, T Song, Y Zhang ; Journal of Physics: Conference …, 2019  iopscience.iop.org;;"… At the same time, under the random oracle model, the scheme satisfies the unforgeability under

the adaptive selection message attack … It is widely used in information security, privacy protection,

Blockchain [2-3] and other fields due to the ambiguity of the signer's identity …";Autres articles;;[PDF] iop.org;https://iopscience.iop.org/article/10.1088/1742-6596/1302/2/022039/pdf;;"""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""viewport"",""width=device-width, initial-scale=1""
""dc:title"",""ShieldSquare Captcha""
""Content-Encoding"",""UTF-8""
""resourceName"",""pdf""
""language"",""en""
""Content-Length"",""2754""
""title"",""ShieldSquare Captcha""
""Content-Language"",""en""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=800&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094588-858;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[PDF][PDF] Tighter post-quantum secure encryption schemes using semi-classical oracles;R Tőnisson ; core.ac.uk;;"… Keywords: Post-quantum cryptography, random oracle model, public-key encryption,

semi-classical oracles … In the quantum random oracle model, quantum adversaries are given

quantum access to the random oracles and classical access to all other oracles …";Autres articles;Version HTML;[PDF] core.ac.uk;https://core.ac.uk/download/pdf/237084559.pdf;;"""date"",""2019-05-21T08:49:40Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2019-05-21T08:49:40Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is MiKTeX-pdfTeX 2.9.6959 (1.40.20)""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2019-05-21T08:49:40Z""
""created"",""2019-05-21T08:49:40Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-05-21T08:49:40Z""
""resourceName"",""237084559.pdf""
""Author"",""""
""producer"",""pdfTeX-1.40.20""
""pdf:docinfo:producer"",""pdfTeX-1.40.20""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""1"",""0"",""5"",""0"",""14"",""0"",""16"",""8"",""8"",""0"",""6"",""7"",""2"",""0"",""1"",""2"",""0"",""6"",""6"",""30"",""7"",""4"",""6"",""12"",""22"",""29"",""83"",""39"",""52"",""20"",""17"",""17"",""25"",""48"",""27"",""12"",""0"",""0"",""0"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2019-05-21T08:49:40Z""
""Last-Modified"",""2019-05-21T08:49:40Z""
""dcterms:modified"",""2019-05-21T08:49:40Z""
""title"",""""
""Last-Save-Date"",""2019-05-21T08:49:40Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2019-05-21T08:49:40Z""
""meta:save-date"",""2019-05-21T08:49:40Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is MiKTeX-pdfTeX 2.9.6959 (1.40.20)""
""Content-Length"",""566698""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""43""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""223"",""2118"",""807"",""2288"",""2027"",""2288"",""1612"",""1629"",""1047"",""1626"",""229"",""1992"",""1435"",""1604"",""1406"",""1610"",""1836"",""1954"",""2088"",""1517"",""1338"",""1224"",""1070"",""1334"",""1115"",""720"",""1362"",""1171"",""1661"",""1191"",""1485"",""1371"",""1033"",""1055"",""1052"",""1314"",""1404"",""195"",""1099"",""1803"",""1769"",""1796"",""1044""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-05-21T08:49:40Z""
";https://scholar.google.com/scholar?start=670&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094555-720;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Blockchain Smart Contracts, the new rebar in the construction industry?;V Björklund, T Vincze ;2019 gupea.ub.gu.se;;"… was introduced in 2008 when a person or a group under the pseudonym Satoshi Nakamoto

released a white paper and proposed a digital platform system for electronic transactions, also

known as the cryptocurrency Bitcoin or now referred to as Blockchain 1.0 (Nakamoto, 2008 …";Autres articles;Version HTML;[PDF] gu.se;https://gupea.ub.gu.se/bitstream/2077/60862/1/gupea_2077_60862_1.pdf;;"""date"",""2019-07-02T09:40:02Z""
""pdf:PDFVersion"",""1.7""
""xmp:CreatorTool"",""MicrosoftÂŽ Word fĂśr Office 365""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""language"",""en""
""dc:format"",""application/pdf; version=1.7""
""pdf:docinfo:creator_tool"",""MicrosoftÂŽ Word fĂśr Office 365""
""access_permission:fill_in_form"",""false""
""pdf:encrypted"",""true""
""xmp:CreateDate"",""2019-05-24T11:14:57Z""
""modified"",""2019-07-02T09:40:02Z""
""pdf:hasMarkedContent"",""true""
""xmp:ModifyDate"",""2019-07-02T11:40:02Z""
""pdf:docinfo:creator"",""Viktor BjĂśrklund""
""meta:author"",""Viktor BjĂśrklund""
""meta:creation-date"",""2019-05-24T09:14:57Z""
""created"",""2019-05-24T09:14:57Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-05-24T09:14:57Z""
""resourceName"",""gupea_2077_60862_1.pdf""
""Author"",""Viktor BjĂśrklund""
""producer"",""MicrosoftÂŽ Word fĂśr Office 365""
""pdf:docinfo:producer"",""MicrosoftÂŽ Word fĂśr Office 365""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""access_permission:modify_annotations"",""false""
""dc:creator"",""Viktor BjĂśrklund""
""dcterms:created"",""2019-05-24T09:14:57Z""
""Last-Modified"",""2019-07-02T09:40:02Z""
""dcterms:modified"",""2019-07-02T09:40:02Z""
""xmpMM:DocumentID"",""uuid:4C7E6078-8CCB-4F99-B985-7932CFBF1A53""
""Last-Save-Date"",""2019-07-02T09:40:02Z""
""pdf:docinfo:modified"",""2019-07-02T09:40:02Z""
""meta:save-date"",""2019-07-02T09:40:02Z""
""Content-Length"",""4709938""
""Content-Type"",""application/pdf""
""xmp:MetadataDate"",""2019-07-02T11:40:02Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Viktor BjĂśrklund""
""dc:language"",""sv-SE""
""pdf:producer"",""MicrosoftÂŽ Word fĂśr Office 365""
""access_permission:assemble_document"",""false""
""xmpTPg:NPages"",""118""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""294"",""539"",""2772"",""1107"",""5798"",""5629"",""7841"",""354"",""349"",""3603"",""3463"",""3107"",""4134"",""3456"",""1663"",""3171"",""3632"",""2333"",""3607"",""2518"",""1847"",""2821"",""3631"",""2435"",""3119"",""3321"",""2344"",""3229"",""3013"",""2969"",""2883"",""4031"",""3997"",""1112"",""3668"",""3967"",""3631"",""3089"",""3318"",""3761"",""4036"",""3833"",""2960"",""2242"",""2576"",""3750"",""3504"",""3601"",""636"",""2070"",""2335"",""2625"",""1795"",""1327"",""3661"",""2534"",""3224"",""2361"",""3331"",""2891"",""3279"",""3093"",""3671"",""3201"",""2059"",""3197"",""3273"",""3545"",""3666"",""3075"",""3282"",""3736"",""2087"",""3257"",""2041"",""3535"",""3372"",""3573"",""3400"",""4028"",""3922"",""3185"",""3240"",""3273"",""3697"",""3670"",""3296"",""3585"",""3880"",""2552"",""2456"",""3636"",""3224"",""2298"",""3311"",""3038"",""2495"",""1932"",""3236"",""3312"",""1808"",""3903"",""4161"",""3875"",""3941"",""2728"",""60"",""2924"",""3179"",""3220"",""3210"",""2954"",""2451"",""2400"",""132"",""1092"",""2506"",""3092""
""access_permission:extract_content"",""false""
""access_permission:can_print"",""true""
""access_permission:can_modify"",""false""
""pdf:docinfo:created"",""2019-05-24T09:14:57Z""
";https://scholar.google.com/scholar?start=530&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094626-1014;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[HTML][HTML] Automated analysis of cryptographic assumptions in generic group models;G Barthe, E Fagerholm, D Fiore, J Mitchell… ; Journal of …, 2019  Springer;United States of America;"… Finally, interactive assumptions are those in which the adversary is granted access to additional

oracles (in addition to the oracles for the algebraic … the Coq proof assistant to formalize the Generic

Group model, on its own and in conjunction with the Random Oracle model, and …";Cité 1 fois;Les 4 versions;[HTML] springer.com;https://link.springer.com/article/10.1007/s00145-018-9302-3;;"""dc.publisher"",""Springer""
""og:image"",""https://media.springernature.com/w200/springer-static/cover/journal/145.jpg""
""twitter:card"",""summary""
""og:site_name"",""Journal of Cryptology""
""citation_reference"",""citation_journal_title=J. Cryptol.; citation_title=Reconciling two views of cryptography (the computational soundness of formal encryption); citation_author=M Abadi, P Rogaway; citation_volume=20; citation_issue=3; citation_publication_date=2007; citation_pages=395; citation_doi=10.1007/s00145-007-0203-0; citation_id=CR1"",""M. Abdalla, D. Pointcheval, Interactive Diffie–Hellman assumptions with applications to password-based authentication, in A. Patrick, M. Yung, editors, FC 2005, vol. 3570 of LNCS (Springer, 2005), pp. 341–356"",""G. Ateniese, J. Camenisch, B. de Medeiros, Untraceable RFID tags via insubvertible encryption, in V. Atluri, C. Meadows, A. Juels, editors, ACM CCS 05 (ACM Press, 2005), pp. 92–101"",""C. E. Z. Baltico, D. Catalano, D. Fiore, R. Gay, Practical functional encryption for quadratic functions with applications to predicate encryption, in Advances in Cryptology—CRYPTO 2017 (2017)."",""G. Barthe, J. Cederquist, S. Tarento, A machine-checked formalization of the generic model and the random oracle model, in Automated Reasoning—Second International Joint Conference, IJCAR 2004, Cork, Ireland, July 4–8, 2004, Proceedings, pp. 385–399 (2004)"",""G. Barthe, E. Fagerholm, D. Fiore, A. Scedrov, B. Schmidt, M. Tibouchi, Strongly-optimal structure preserving signatures from type ii pairings: Synthesis and lower bounds, in J. Katz, editor, Public-Key Cryptography—PKC 2015, vol. 9020 of LNCS (Springer, Berlin, 2015), pp. 355–376"",""G. Barthe, S. Tarento, A machine-checked formalization of the random oracle model, in Types for Proofs and Programs, International Workshop, TYPES 2004, Jouy-en-Josas, France, December 15–18, 2004, Revised Selected Papers (2004), pp. 33–49"",""K. Benson, H. Shacham, B. Waters, The k-BDH assumption family: Bilinear map cryptography from progressively weaker assumptions, in E. Dawson, editor, CT-RSA 2013, vol. 7779 of LNCS, (Springer, Feb. / Mar. 2013), pp. 310–325"",""B. Blanchet. Security protocol verification: Symbolic and computational models, in POST 2012, vol. 7215 of Lecture Notes in Computer Science (Springer, Heidelberg, 2012), pp. 3–29"",""A. Boldyreva, C. Gentry, A. O’Neill, D. H. Yum, Ordered multisignatures and identity-based sequential aggregate signatures, with applications to secure routing, in P. Ning, S. D. C. di Vimercati, P. F. Syverson, editors, ACM CCS 07 (ACM Press, 2007), pp. 276–285"",""A. Boldyreva, C. Gentry, A. O’Neill, D. H. Yum, Ordered multisignatures and identity-based sequential aggregate signatures, with applications to secure routing. Cryptology ePrint Archive, Report 2007/438, revised 21 Feb 2010 (2007)"",""D. Boneh, X. Boyen. Short signatures without random oracles. In C. Cachin, J. Camenisch, editors, EUROCRYPT 2004, vol. 3027 of LNCS (Springer, 2004), pp. 56–73"",""D. Boneh, X. Boyen, E.-J. Goh. Hierarchical identity based encryption with constant size ciphertext, in R. Cramer, editor, EUROCRYPT 2005, vol. 3494 of LNCS (Springer, 2005), pp. 440–456"",""D. Boneh, X. Boyen, E.-J. Goh. Hierarchical identity based encryption with constant size ciphertext. Cryptology ePrint Archive, Report 2005/015 (2005)"",""D. Boneh, M. K. Franklin, Identity-based encryption from the Weil pairing, in J. Kilian, editor, CRYPTO 2001, vol. 2139 of LNCS (Springer, 2001), pp. 213–229"",""D. Boneh, C. Gentry, B. Waters. Collusion resistant broadcast encryption with short ciphertexts and private keys, in V. Shoup, editor, CRYPTO 2005, vol. 3621 of LNCS (Springer, 2005), pp. 258–275"",""D. Boneh, E.-J. Goh, K. Nissim, Evaluating 2-DNF formulas on ciphertexts, in J. Kilian, editor, TCC 2005, vol. 3378 of LNCS (Springer, 2005), pp. 325–341"",""X. Boyen. The uber-assumption family (invited talk), in S. D. Galbraith, K. G. Paterson, editors, PAIRING 2008, vol. 5209 of LNCS (Springer, 2008), pp. 39–56"",""E. Bresson, Y. Lakhnech, L. Mazaré, B. Warinschi, A generalization of DDH with applications to protocol analysis and computational soundness, in A. Menezes, editor, CRYPTO 2007, vol. 4622 of LNCS (Springer, 2007), pp. 482–499"",""H. Cohen, A course in computational algebraic number theory, vol. 138 of Graduate Texts in Mathematics (Springer, Berlin, 1993)"",""L. De Moura, N. Bjørner, Z: An efficient smt solver, in Tools and Algorithms for the Construction and Analysis of Systems (Springer, 2008), pp. 337–340"",""A. Escala, G. Herold, E. Kiltz, C. Ràfols, J. Villar. An algebraic framework for Diffie–Hellman assumptions, in R. Canetti, J. A. Garay, editors, CRYPTO 2013, Part II, vol. 8043 of LNCS (Springer, 2013), pp. 129–147"",""D. M. Freeman, Converting pairing-based cryptosystems from composite-order groups to prime-order groups, in H. Gilbert, editor, EUROCRYPT 2010, vol. 6110 of LNCS (Springer, 2010), pp. 44–61"",""S. Garg, C. Gentry, A. Sahai, B. Waters. Witness encryption and its applications, in D. Boneh, T. Roughgarden, J. Feigenbaum, editors, 45th ACM STOC (ACM Press, 2013), pp. 467–476"",""K. Gjøsteen, Ø. Thuen. Password-based signatures, in Public Key Infrastructures, Services and Applications (Springer, 2012), pp. 17–33"",""S. Halevi, A plausible approach to computer-aided cryptographic proofs. Cryptology ePrint Archive, Report 2005/181 (2005)"",""C. Hanser, D. Slamanig, Structure-preserving signatures on equivalence classes and their application to anonymous credentials, in P. Sarkar, T. Iwata, editors, Advances in Cryptology—ASIACRYPT 2014, vol. 8873 of Lecture Notes in Computer Science (Springer, Berlin, 2014), pp. 491–511"",""C. Hanser, D. Slamanig. Structure-preserving signatures on equivalence classes and their application to anonymous credentials, in P. Sarkar, T. Iwata, editors, Advances in Cryptology—ASIACRYPT 2014, vol. 8873 of Lecture Notes in Computer Science (Springer, Berlin, 2014), pp. 491–511"",""S. Hohenberger, A. Sahai, B. Waters, Full domain hash from (leveled) multilinear maps and identity-based aggregate signatures, in R. Canetti, J. A. Garay, editors, CRYPTO 2013, Part I, vol. 8042 of LNCS (Springer, 2013), pp. 494–512"",""J. Y. Hwang, D. H. Lee, M. Yung, Universal forgery of the identity-based sequential aggregate signature scheme, in W. Li, W. Susilo, U. K. Tupakula, R. Safavi-Naini, V. Varadharajan, editors, ASIACCS 09 (ACM Press, 2009), pp. 157–160"",""T. Jager, A. Rupp, The semi-generic group model and applications to pairing-based cryptography, in M. Abe, editor, ASIACRYPT 2010, vol. 6477 of LNCS (Springer, 2010), pp. 539–556"",""T. Jager, J. Schwenk, On the equivalence of generic group models, in J. Baek, F. Bao, K. Chen, X. Lai, editors, ProvSec 2008, vol. 5324 of LNCS (Springer, 2008), pp. 200–209"",""D. Jovanović, L. De Moura, Solving non-linear arithmetic, in Automated Reasoning(Springer, 2012), pp. 339–354"",""J. Katz, A. Sahai, B. Waters, Predicate encryption supporting disjunctions, polynomial equations, and inner products, in N. P. Smart, editor, EUROCRYPT 2008, vol. 4965 of LNCS (Springer, 2008), pp. 146–162"",""J. Katz, A. Sahai, B. Waters, Predicate encryption supporting disjunctions, polynomial equations, and inner products. Journal of Cryptology, 26(2), 191–224 (2013)"",""A. Lysyanskaya, R. L. Rivest, A. Sahai, S. Wolf, Pseudonym systems, in H. M. Heys, C. M. Adams, editors, SAC 1999, vol. 1758 of LNCS (Springer, 1999), pp 184–199"",""citation_journal_title=Dokl. Akad. Nauk SSSR; citation_title=Enumerable sets are diophantine; citation_author=JV Matijasevic; citation_volume=191; citation_publication_date=1970; citation_pages=279-282; citation_id=CR37"",""U. M. Maurer, Abstract models of computation in cryptography (invited paper), in N. P. Smart, editor, 10th IMA International Conference on Cryptography and Coding, vol. 3796 of LNCS (Springer, 2005), pp. 1–12"",""U. M. Maurer, S. Wolf. Diffie–Hellman oracles, in N. Koblitz, editor, CRYPTO’96, vol. 1109 of LNCS (Springer, 1996), pp. 268–282"",""M. Naor, On cryptographic assumptions and challenges (invited talk), in D. Boneh, editor, CRYPTO 2003, vol. 2729 of LNCS (Springer, 2003), pp. 96–109"",""citation_journal_title=Mathematical Notes; citation_title=Complexity of a determinate algorithm for the discrete logarithm; citation_author=VI Nechaev; citation_volume=55; citation_issue=2; citation_publication_date=1994; citation_pages=165-172; citation_doi=10.1007/BF02113297; citation_id=CR41"",""T. Okamoto, K. Takashima, Fully secure functional encryption with general relations from the decisional linear assumption, in T. Rabin, editor, CRYPTO 2010, vol. 6223 of LNCS (Springer, 2010), pp. 191–208"",""citation_journal_title=Fundamenta Mathematicae; citation_title=Solution of a problem of tarski; citation_author=A Robinson; citation_volume=47; citation_issue=2; citation_publication_date=1959; citation_pages=179-204; citation_doi=10.4064/fm-47-2-179-204; citation_id=CR43"",""citation_journal_title=J. ACM; citation_title=Fast probabilistic algorithms for verification of polynomial identities; citation_author=JT Schwartz; citation_volume=27; citation_publication_date=1980; citation_pages=701-717; citation_doi=10.1145/322217.322225; citation_id=CR44"",""H. Shacham, A cramer-shoup encryption scheme from the linear assumption and from progressively weaker linear variants. Cryptology ePrint Archive, Report 2007/074 (2007).                      http://eprint.iacr.org/2007/074                                        ."",""V. Shoup, Lower bounds for discrete logarithms and related problems, in W. Fumy, editor, EUROCRYPT’97, vol. 1233 of LNCS (Springer, 1997), pp. 256–266"",""W. Stein et al. Sage Mathematics Software (Version 5.12). The Sage Development Team (2013)                      http://www.sagemath.org                                                                 "",""M. Szydlo, A note on chosen-basis decisional Diffie–Hellman assumptions, in Financial Cryptography and Data Security (Springer, 2006), pp. 166–170"",""R. Zippel, Probabilistic algorithms for sparse polynomials, in E. W. Ng, editor, EUROSM ’79, vol. 72 of Lecture Notes in Computer Science (Springer, 1979), pp. 216–226""
""citation_journal_title"",""Journal of Cryptology""
""language"",""en""
""citation_cover_date"",""2019/04/01""
""og:description"",""We initiate the study of principled, automated methods for analyzing hardness assumptions in generic group models, following the approach of symbolic cryptography. We start by defining a broad class of generic and symbolic group models for different settings—symmetric or asymmetric (leveled) k-linear groups—and by proving “computational soundness” theorems for the symbolic models. Based on this result, we formulate a very general master theorem that formally relates the hardness of a (possibly interactive) assumption in these models to solving problems in polynomial algebra. Then, we systematically analyze these problems. We identify different classes of assumptions and obtain decidability and undecidability results. Next, we develop and implement automated procedures for verifying the conditions of master theorems, and thus the validity of hardness assumptions in generic group models. The concrete outcome of this work is an automated tool which takes as input the statement of an assumption and outputs either a proof of its generic hardness or shows an algebraic attack against the assumption.""
""prism.issn"",""1432-1378""
""citation_author_email"",""gilles.barthe@imdea.org"",""edvard.fagerholm@gmail.com"",""dario.fiore@imdea.org"",""mitchell@cs.stanford.edu"",""scedrov@math.upenn.edu"",""beschmi@gmail.com""
""twitter:image:alt"",""Content cover image""
""prism.number"",""2""
""citation_issn"",""1432-1378""
""citation_language"",""en""
""dc:title"",""Automated Analysis of Cryptographic Assumptions in Generic Group Models | SpringerLink""
""Content-Encoding"",""UTF-8""
""citation_pdf_url"",""https://link.springer.com/content/pdf/10.1007/s00145-018-9302-3.pdf""
""citation_lastpage"",""360""
""DOI"",""10.1007/s00145-018-9302-3""
""citation_fulltext_world_readable"",""""
""citation_journal_abbrev"",""J Cryptol""
""prism.rightsAgent"",""journalpermissions@springernature.com""
""citation_author"",""Gilles Barthe"",""Edvard Fagerholm"",""Dario Fiore"",""John Mitchell"",""Andre Scedrov"",""Benedikt Schmidt""
""resourceName"",""s00145-018-9302-3""
""dc.date"",""2018-12-18""
""citation_springer_api_url"",""http://api.springer.com/metadata/pam?q=doi:10.1007/s00145-018-9302-3&api_key=""
""citation_issue"",""2""
""prism.volume"",""32""
""prism.publicationName"",""Journal of Cryptology""
""citation_doi"",""10.1007/s00145-018-9302-3""
""dc.title"",""Automated Analysis of Cryptographic Assumptions in Generic Group Models""
""prism.url"",""https://link.springer.com/article/10.1007/s00145-018-9302-3""
""citation_volume"",""32""
""dc.language"",""En""
""Content-Language"",""en""
""format-detection"",""telephone=no""
""citation_publication_date"",""2019/04""
""prism.endingPage"",""360""
""citation_title"",""Automated Analysis of Cryptographic Assumptions in Generic Group Models""
""citation_author_institution"",""IMDEA Software Institute, Madrid, Spain"",""IMDEA Software Institute, Madrid, Spain"",""University of Pennsylvania, Philadelphia, USA"",""NVIDIA, Santa Clara, USA"",""IMDEA Software Institute, Madrid, Spain"",""Stanford University, Stanford, USA"",""University of Pennsylvania, Philadelphia, USA"",""National Research University Higher School of Economics, Moscow, Russian Federation"",""IMDEA Software Institute, Madrid, Spain"",""Google, Mountain View, USA""
""access"",""Yes""
""citation_publisher"",""Springer US""
""applicable-device"",""pc,mobile""
""dc.format"",""text/html""
""description"",""We initiate the study of principled, automated methods for analyzing hardness assumptions in generic group models, following the approach of symbolic crypt""
""title"",""Automated Analysis of Cryptographic Assumptions in Generic Group Models | SpringerLink""
""citation_online_date"",""2018/12/18""
""twitter:site"",""@SpringerLink""
""dc.source"",""Journal of Cryptology 2018 32:2""
""dc.type"",""OriginalPaper""
""dc.copyright"",""2018 International Association for Cryptologic Research""
""dc.creator"",""Gilles Barthe"",""Edvard Fagerholm"",""Dario Fiore"",""John Mitchell"",""Andre Scedrov"",""Benedikt Schmidt""
""citation_fulltext_html_url"",""https://link.springer.com/article/10.1007/s00145-018-9302-3""
""prism.publicationDate"",""2018-12-18""
""Content-Type"",""text/html; charset=UTF-8""
""journal_id"",""145""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""dc.description"",""We initiate the study of principled, automated methods for analyzing hardness assumptions in generic group models, following the approach of symbolic cryptography. We start by defining a broad class of generic and symbolic group models for different settings—symmetric or asymmetric (leveled) k-linear groups—and by proving “computational soundness” theorems for the symbolic models. Based on this result, we formulate a very general master theorem that formally relates the hardness of a (possibly interactive) assumption in these models to solving problems in polynomial algebra. Then, we systematically analyze these problems. We identify different classes of assumptions and obtain decidability and undecidability results. Next, we develop and implement automated procedures for verifying the conditions of master theorems, and thus the validity of hardness assumptions in generic group models. The concrete outcome of this work is an automated tool which takes as input the statement of an assumption and outputs either a proof of its generic hardness or shows an algebraic attack against the assumption.""
""og:type"",""article""
""citation_article_type"",""Article""
""og:title"",""Automated Analysis of Cryptographic Assumptions in Generic Group Models""
""prism.doi"",""doi:10.1007/s00145-018-9302-3""
""X-UA-Compatible"",""IE=edge""
""citation_firstpage"",""324""
""prism.startingPage"",""324""
""viewport"",""width=device-width, initial-scale=1""
""dc.rightsAgent"",""journalpermissions@springernature.com""
""prism.section"",""OriginalPaper""
""dc.identifier"",""doi:10.1007/s00145-018-9302-3""
""dc.subject"",""Coding and Information Theory"",""Computational Mathematics and Numerical Analysis"",""Combinatorics"",""Probability Theory and Stochastic Processes"",""Communications Engineering, Networks""
""og:url"",""https://link.springer.com/article/10.1007/s00145-018-9302-3""
""prism.copyright"",""2018 International Association for Cryptologic Research""
";https://scholar.google.com/scholar?start=830&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094644-1093;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;From Key Encapsulation to Authenticated Group Key Establishment—A Compiler for Post-Quantum Primitives;E Persichetti, R Steinwandt, A Suárez Corona ; Entropy, 2019  mdpi.com;;"… for Signal Detection via Hybrid MPI/OpenMP. Next Article in Special Issue A Blockchain-Driven

Supply … We consider an adversary to be active if it has access to all of the above oracles. To capture

a passive adversary, we can replace access to Send oracle with access to an …";Cité 2 fois;Les 6 versions;[PDF] mdpi.com;https://www.mdpi.com/1099-4300/21/12/1183/pdf;;;https://scholar.google.com/scholar?start=910&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094605-922;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[HTML][HTML] An efficient online/offline ID-based short signature procedure using extended chaotic maps;C Meshram, CT Li, SG Meshram ; Soft Computing, 2019  Springer;Germany;"… (2016). Between these methods, Joye (2008) and Kurosawa and Schmidt-Samoa (2006)

are proven secure without random oracles, while Boneh and Boyen (2008) is the most

efficient one … It is exhibited ensured in the random oracle …";Cité 18 fois;Les 2 versions;[HTML] springer.com;https://idp.springer.com/authorize/casa?redirect_uri=https://link.springer.com/article/10.1007/s00500-018-3112-2&casa_token=38lbn9JidJkAAAAA:FVQLPWoRIxQG_pf1oFLTB2oq3mvncfyaS9qwq8td7FuCMnOKlx9CGifdSNfAkqTn0hn6QsPEfTpaeLw;;"""dc.publisher"",""Springer""
""og:image"",""https://media.springernature.com/w200/springer-static/cover/journal/500.jpg""
""twitter:card"",""summary""
""og:site_name"",""Soft Computing""
""citation_reference"",""citation_journal_title=J Cryptol; citation_title=Security proofs for identity based identification and signature schemes; citation_author=M Bellare, C Namprempre, G Neven; citation_volume=22; citation_publication_date=2009; citation_pages=1-61; citation_doi=10.1007/s00145-008-9028-8; citation_id=CR1"",""citation_journal_title=J Cryptol; citation_title=Short signatures without random oracles the SDH assumption in bilinear groups; citation_author=D Boneh, X Boyen; citation_volume=2; citation_publication_date=2008; citation_pages=149-177; citation_doi=10.1007/s00145-007-9005-7; citation_id=CR2"",""Cha J, Cheon J (2003) An identity-based signature from gap Diffie Hellman groups. In: Proceedings of PKC’2003. Lecture notes in computer science. Springer, Berlin, vol 2567, pp 18–30"",""citation_journal_title=Nonlinear Dyn; citation_title=A new digital signature scheme based on chaotic maps; citation_author=K Chain, WC Kuo; citation_volume=74; citation_publication_date=2013; citation_pages=1003-1012; citation_doi=10.1007/s11071-013-1018-1; citation_id=CR4"",""citation_journal_title=Chaos Solitons Fractals; citation_title=A symmetric image encryption scheme based on 3D chaotic cat maps; citation_author=G Chen, Y Mao, C Chui; citation_volume=21; citation_issue=3; citation_publication_date=2004; citation_pages=749-761; citation_doi=10.1016/j.chaos.2003.12.022; citation_id=CR5"",""citation_journal_title=Chaos Solitons Fractals; citation_title=An extended method for obtaining S-boxes based on three-dimensional chaotic baker maps; citation_author=G Chen, Y Chen, X Liao; citation_volume=31; citation_issue=3; citation_publication_date=2007; citation_pages=571-579; citation_doi=10.1016/j.chaos.2005.10.022; citation_id=CR6"",""Chen X, Zhang F, Susilo W, Mu Y (2007b) Efficient generic online/offline signatures without key exposure. In: Proceedings of ACNS ’07. Lecture notes in computer science. Springer, Berlin, vol 4521, pp 18–30"",""citation_journal_title=IEEE Trans Circuits Syst I Fundam Theory Appl; citation_title=Chaos and cryptography; citation_author=F Dachselt, W Schwarz; citation_volume=48; citation_issue=12; citation_publication_date=2001; citation_pages=1498-1509; citation_doi=10.1109/TCSI.2001.972857; citation_id=CR8"",""citation_journal_title=Commun Nonlinear Sci Numer Simul; citation_title=Analysis and improvement of a chaos-based Hash function construction; citation_author=S Deng, Y Li, D Xiao; citation_volume=15; citation_issue=5; citation_publication_date=2010; citation_pages=1338-1347; citation_doi=10.1016/j.cnsns.2009.05.065; citation_id=CR9"",""Even S, Goldreich O, Micali S (1989) On-line/off-line digital signatures. In: Proceedings of CRYPTO ’89. Lecture notes in computer science. Springer, New York, vol 2442, pp 263-277"",""Galindo D, Garcia F (2009) A schnorr-like lightweight identity-based signature scheme. In: Progress in cryptology-AFRICACRYPT 2009. Lecture notes in computer science. Springer, Berlin, vol 5580, pp 135–148"",""citation_journal_title=Int J Netw Secur; citation_title=An improved online/offline identity-based signature scheme for WSNs; citation_author=Y Gao, P Zeng, KK Raymond Choo, F Song; citation_volume=18; citation_issue=6; citation_publication_date=2016; citation_pages=1143-1151; citation_id=CR12"",""Guillou LC, Quisquater JJ (1989) A “Paradoxical” identity-based signature scheme resulting from zero-knowledge. In: Proceedings of CRYPTO 88. Lecture notes in computer science. Springer, Berlin, vol 403, pp 216–231"",""citation_journal_title=Choas Soliton Fractals; citation_title=Chaotic map based key agreement without clock synchronization; citation_author=S Han, E Chang; citation_volume=39; citation_issue=3; citation_publication_date=2009; citation_pages=1283-1289; citation_doi=10.1016/j.chaos.2007.06.030; citation_id=CR14"",""citation_journal_title=Comput J; citation_title=Deterministic identity-based signatures for partial aggregation; citation_author=J Herranz; citation_volume=49; citation_issue=3; citation_publication_date=2005; citation_pages=322-330; citation_doi=10.1093/comjnl/bxh153; citation_id=CR15"",""Hess F (2003) Efficient identity based signature schemes based on pairings. In: Selected area in cryptography, SAC2002. Lecture notes in computer science. Springer, Berlin, vol 2595, pp 310–324"",""Joye M (2008) An efficient on-line/off-line signature scheme without random oracles. In: Proceedings of CANS ’08. Lecture notes in computer science. Springer, Berlin, vol 5339, pp 98–107"",""citation_journal_title=Nonlinear Dyn; citation_title=A speech encryption using fractional chaotic systems; citation_author=S Jye; citation_volume=65; citation_publication_date=2011; citation_pages=103-108; citation_doi=10.1007/s11071-010-9877-1; citation_id=CR18"",""citation_journal_title=J Syst Softw; citation_title=A novel identity-based strong designated verifier signature scheme; citation_author=B Kang, C Boyd, E Dawson; citation_volume=82; citation_publication_date=2009; citation_pages=270-273; citation_doi=10.1016/j.jss.2008.06.014; citation_id=CR19"",""citation_journal_title=Int J Netw Secur; citation_title=Provably secure online/off-line identity-based signature scheme for wireless sensor network; citation_author=J Kar; citation_volume=16; citation_issue=1; citation_publication_date=2014; citation_pages=29-39; citation_id=CR20"",""citation_journal_title=IEEE Circuits Syst Mag; citation_title=Chaos-based cryptography: a brief overview; citation_author=L Kocarev; citation_volume=1; citation_issue=3; citation_publication_date=2001; citation_pages=6-21; citation_doi=10.1109/7384.963463; citation_id=CR21"",""Kurosawa K, Schmidt-Samoa K (2006) New online/offline signature schemes without random oracles. In: Proceedings of PKC ’06. Lecture notes in computer science. Springer, Berlin, vol 3958, pp 330–346"",""citation_journal_title=PLoS ONE; citation_title=A new ticket-based authentication mechanism for fast handover in mesh network; citation_author=YM Lai, PJ Cheng, CC Lee, CY Ku; citation_volume=11; citation_issue=5; citation_publication_date=2016; citation_pages=e0155064; citation_doi=10.1371/journal.pone.0155064; citation_id=CR23"",""citation_journal_title=Nonlinear Dyn; citation_title=A secure biometric-based remote user authentication with key agreement scheme using extended chaotic maps; citation_author=CC Lee, CW Hsu; citation_volume=71; citation_issue=1–2; citation_publication_date=2013; citation_pages=201-211; citation_doi=10.1007/s11071-012-0652-3; citation_id=CR24"",""citation_journal_title=Nonlinear Dyn; citation_title=An extended chaotic maps-based key agreement protocol with user anonymity; citation_author=CC Lee, CL Chen, CY Wu, SY Huang; citation_volume=69; citation_issue=1–2; citation_publication_date=2012; citation_pages=79-87; citation_doi=10.1007/s11071-011-0247-4; citation_id=CR25"",""citation_journal_title=J Med Syst; citation_title=An enhanced mobile-healthcare emergency system based on extended chaotic maps; citation_author=CC Lee, CW Hsu, YM Lai, AV Vasilakos; citation_volume=37; citation_issue=5; citation_publication_date=2013; citation_pages=9973; citation_doi=10.1007/s10916-013-9973-0; citation_id=CR26"",""citation_journal_title=Nonlinear Dyn; citation_title=A three-party password-based authenticated key exchange protocol with user anonymity using extended chaotic maps; citation_author=CC Lee, CT Li, CW Hsu; citation_volume=73; citation_issue=1–2; citation_publication_date=2013; citation_pages=125-132; citation_doi=10.1007/s11071-013-0772-4; citation_id=CR27"",""citation_journal_title=Nonlinear Dyn; citation_title=A new three-party-authenticated key agreement scheme based on chaotic maps without password table; citation_author=CC Lee, CT Li, ST Chiu, YM Lai; citation_volume=79; citation_issue=4; citation_publication_date=2014; citation_pages=2485-2495; citation_doi=10.1007/s11071-014-1827-x; citation_id=CR28"",""citation_journal_title=Nonlinear Dyn; citation_title=An extended chaotic-maps-based protocol with key agreement for multiserver environments; citation_author=CC Lee, DC Lou, CT Li, CW Hsu; citation_volume=76; citation_issue=1; citation_publication_date=2014; citation_pages=853-866; citation_doi=10.1007/s11071-013-1174-3; citation_id=CR29"",""Li F, Shirase M, Takagi T (2008) On the security of online/offline signatures and multisignatures from acisp’06. In: Proceedings of CANS ’08. Lecture notes in computer science. Springer, Berlin, vol 5339, pp 108–119"",""citation_journal_title=J Med Syst; citation_title=A secure chaotic maps and smart cards based password authentication and key agreement scheme with user anonymity for telecare medicine information systems; citation_author=CT Li, CC Lee, CY Weng; citation_volume=38; citation_issue=9; citation_publication_date=2014; citation_pages=77; citation_doi=10.1007/s10916-014-0077-2; citation_id=CR31"",""citation_journal_title=J Med Syst; citation_title=A secure dynamic identity and chaotic maps based user authentication and key agreement scheme for e-healthcare systems; citation_author=CT Li, CC Lee, CY Weng, SJ Chen; citation_volume=40; citation_issue=11; citation_publication_date=2016; citation_pages=233; citation_doi=10.1007/s10916-016-0586-2; citation_id=CR32"",""citation_title=Chebyshev polynomials; citation_publication_date=2003; citation_id=CR33; citation_author=JC Mason; citation_author=DC Handscomb; citation_publisher=Chapman and Hall/CRC"",""citation_journal_title=Inf Process Lett; citation_title=An efficient ID-based cryptographic encryption based on discrete logarithm problem and integer factorization problem; citation_author=C Meshram; citation_volume=115; citation_issue=2; citation_publication_date=2015; citation_pages=351-358; citation_doi=10.1016/j.ipl.2014.10.007; citation_id=CR34"",""citation_journal_title=Int J Secur Appl; citation_title=An efficient ID-based beta cryptosystem; citation_author=C Meshram; citation_volume=9; citation_issue=2; citation_publication_date=2015; citation_pages=189-202; citation_id=CR35"",""citation_journal_title=J Inf Optim Sci; citation_title=New efficient key authentication protocol for public key cryptosystem using DL over multiplicative group; citation_author=C Meshram, X Li; citation_volume=10; citation_issue=1080/02522667; citation_publication_date=2017; citation_pages=1411013; citation_id=CR36"",""citation_journal_title=Inf Process Lett; citation_title=An identity-based cryptographic model for discrete logarithm and integer factoring based cryptosystem; citation_author=C Meshram, S Meshram; citation_volume=113; citation_issue=10–11; citation_publication_date=2013; citation_pages=375-380; citation_doi=10.1016/j.ipl.2013.02.009; citation_id=CR37"",""citation_journal_title=J Discrete Math Sci Cryptogr; citation_title=Constructing new An ID-based cryptosystem for IFP and GDLP based cryptosystem; citation_author=C Meshram, SA Meshram; citation_volume=20; citation_issue=5; citation_publication_date=2017; citation_pages=1121-1134; citation_doi=10.1080/09720529.2015.1032621; citation_id=CR38"",""Meshram C, Obaidat MS (2015) An ID-based quadratic-exponentiation randomized cryptographic scheme. In: IEEE proceeding of international conference on computer, information and telecommunication systems, pp 1–5"",""citation_journal_title=Complex Intell Syst; citation_title=An efficient identity-based QER cryptographic scheme; citation_author=C Meshram, PL Powar; citation_volume=2; citation_issue=4; citation_publication_date=2016; citation_pages=285-291; citation_doi=10.1007/s40747-016-0030-8; citation_id=CR40"",""citation_journal_title=Inf Process Lett; citation_title=An ID-based cryptographic mechanisms based on GDLP and IFP; citation_author=C Meshram, S Meshram, M Zhang; citation_volume=112; citation_issue=19; citation_publication_date=2012; citation_pages=753-758; citation_doi=10.1016/j.ipl.2012.06.018; citation_id=CR41"",""citation_journal_title=Proc Comput Sci; citation_title=An IBE technique using partial discrete logarithm; citation_author=C Meshram, PL Powar, MS Obaidat, CC Lee; citation_volume=93; citation_publication_date=2016; citation_pages=735-741; citation_doi=10.1016/j.procs.2016.07.282; citation_id=CR42"",""citation_journal_title=Proc Comput Sci; citation_title=An UF-IBSS-CMA protected online/offline identity-based short signature technique using PDL; citation_author=C Meshram, PL Powar, MS Obaidat; citation_volume=93; citation_publication_date=2016; citation_pages=847-853; citation_doi=10.1016/j.procs.2016.07.253; citation_id=CR43"",""citation_journal_title=Soft Comput; citation_title=A secure key authentication scheme for cryptosystems based on GDLP and IFP; citation_author=C Meshram, CC Lee, CT Li, CL Chen; citation_volume=21; citation_issue=24; citation_publication_date=2017; citation_pages=7285-7291; citation_doi=10.1007/s00500-016-2440-3; citation_id=CR44"",""citation_journal_title=Informatica; citation_title=An IND-ID-CPA secure ID-based cryptographic protocol using GDLP and IFP; citation_author=C Meshram, YM Tseng, CC Lee, SG Meshram; citation_volume=28; citation_issue=3; citation_publication_date=2017; citation_pages=471-484; citation_doi=10.15388/Informatica.2017.139; citation_id=CR45"",""Meshram C, Obaidat MS, Meshram SG (2017c) Chebyshev chaotic maps based ID-based cryptographic model using subtree and fuzzy-entity data sharing for public key cryptography. Secur Priv.                      https://doi.org/10.1002/spy2.12                                                                 "",""citation_journal_title=Adv Inf Comput Secur; citation_title=Identity-based deterministic signature scheme without forking-lemma.; citation_author=SD Selvi, V Sree, CP Rangan; citation_volume=7038; citation_publication_date=2011; citation_pages=79-95; citation_id=CR47"",""Shamir A, Tauman Y (2001) Improved online/offline signature schemes. In: Proceedings of CRYPTO ’01. Lecture notes in computer science. Springer, Berlin, vol 2139, pp 355–367"",""citation_journal_title=Commun Nonlinear Sci Numer Simul; citation_title=A block cipher with dynamic S-boxes based on tent map; citation_author=Y Wang, K Wong, X Liao, T Xiang; citation_volume=14; citation_issue=7; citation_publication_date=2009; citation_pages=3089-3099; citation_doi=10.1016/j.cnsns.2008.12.005; citation_id=CR49"",""citation_journal_title=Nonlinear Dyn; citation_title=A chaotic image encryption algorithm based on perceptron model; citation_author=X Wang, L Yang, R Liu; citation_volume=62; citation_publication_date=2010; citation_pages=615-621; citation_doi=10.1007/s11071-010-9749-8; citation_id=CR50"",""citation_journal_title=Nonlinear Dyn; citation_title=Chaotic encryption algorithm based on alternant of stream cipher and block cipher; citation_author=X Wang, X Wang, J Zhao; citation_volume=63; citation_publication_date=2011; citation_pages=587-597; citation_doi=10.1007/s11071-010-9821-4; citation_id=CR51"",""citation_journal_title=Phys Lett A; citation_title=A fast chaotic cryptography scheme with dynamic look up table; citation_author=KW Wong; citation_volume=298; citation_issue=4; citation_publication_date=2002; citation_pages=238-242; citation_doi=10.1016/S0375-9601(02)00431-0; citation_id=CR52"",""citation_journal_title=Commun Nonlinear Sci Numer Simul; citation_title=A chaos-based hash function with both modification detection and localization capabilities; citation_author=D Xiao, F Shih, X Liao; citation_volume=15; citation_issue=9; citation_publication_date=2010; citation_pages=2254-2261; citation_doi=10.1016/j.cnsns.2009.10.012; citation_id=CR53"",""Xu S, Mu Y, Susilo W (2006) Online/offline signatures and multisignatures for AVOD and DSR routing security. In: Proceedings of ACISP ’06. Lecture notes in computer science. Springer, Berlin, vol 4058, pp 99–110"",""citation_journal_title=Chaos, Solitons Fract; citation_title=Cryptanalysis of the public key encryption based on multiple chaotic systems; citation_author=L Zhang; citation_volume=37; citation_issue=3; citation_publication_date=2008; citation_pages=669-674; citation_doi=10.1016/j.chaos.2006.09.047; citation_id=CR55""
""citation_journal_title"",""Soft Computing""
""language"",""en""
""citation_cover_date"",""2019/02/01""
""og:description"",""Chaos has been dealt with a decent approach to reduce computational complexity while fulfilling security necessities of a cryptographic techniques. In this article, we purpose an efficient online/offline ID-based short signature procedure based on extended chaotic maps and also demonstrated that it is protected under unforgeability of ID-based short signature under chosen message attack. Some of the intriguing arrangements of presented procedures is that it gives multi-time use of the offline stockpiling, which permits the signer to reuse the offline pre-administered information in polynomial time, rather than one-time use in all past online/offline signature procedures.""
""prism.issn"",""1433-7479""
""citation_author_email"",""cs_meshram@rediffmail.com"",""th0040@mail.tut.edu.tw"",""gajbhiyesarita@gmail.com""
""twitter:image:alt"",""Content cover image""
""prism.number"",""3""
""citation_issn"",""1433-7479""
""citation_language"",""en""
""dc:title"",""An efficient online/offline ID-based short signature procedure using extended chaotic maps | SpringerLink""
""Content-Encoding"",""UTF-8""
""citation_pdf_url"",""https://link.springer.com/content/pdf/10.1007/s00500-018-3112-2.pdf""
""citation_lastpage"",""753""
""DOI"",""10.1007/s00500-018-3112-2""
""citation_journal_abbrev"",""Soft Comput""
""prism.rightsAgent"",""journalpermissions@springernature.com""
""citation_author"",""Chandrashekhar Meshram"",""Chun-Ta Li"",""Sarita Gajbhiye Meshram""
""resourceName"",""casa""
""dc.date"",""2018-03-09""
""citation_springer_api_url"",""http://api.springer.com/metadata/pam?q=doi:10.1007/s00500-018-3112-2&api_key=""
""citation_issue"",""3""
""prism.volume"",""23""
""prism.publicationName"",""Soft Computing""
""citation_doi"",""10.1007/s00500-018-3112-2""
""dc.title"",""An efficient online/offline ID-based short signature procedure using extended chaotic maps""
""prism.url"",""https://link.springer.com/article/10.1007/s00500-018-3112-2""
""citation_volume"",""23""
""dc.language"",""En""
""Content-Language"",""en""
""format-detection"",""telephone=no""
""citation_publication_date"",""2019/02""
""prism.endingPage"",""753""
""citation_title"",""An efficient online/offline ID-based short signature procedure using extended chaotic maps""
""citation_author_institution"",""Department of Mathematics and Computer Science, Rani Durgavati University, Jabalpur, India"",""Department of Mathematics, RTM Nagpur University, Nagpur, India"",""Department of Information Management, Tainan University of Technology, Tainan, Taiwan, ROC"",""Department of Mathematics and Computer Science, Rani Durgavati University, Jabalpur, India"",""Department of Water Resources Development and Management, Indian Institute of Technology, Roorkee, India""
""access"",""No""
""citation_publisher"",""Springer Berlin Heidelberg""
""applicable-device"",""pc,mobile""
""dc.format"",""text/html""
""description"",""Chaos has been dealt with a decent approach to reduce computational complexity while fulfilling security necessities of a cryptographic techniques. In this""
""title"",""An efficient online/offline ID-based short signature procedure using extended chaotic maps | SpringerLink""
""citation_online_date"",""2018/03/09""
""twitter:site"",""@SpringerLink""
""dc.source"",""Soft Computing 2018 23:3""
""dc.type"",""OriginalPaper""
""dc.copyright"",""2018 Springer-Verlag GmbH Germany, part of Springer Nature""
""dc.creator"",""Chandrashekhar Meshram"",""Chun-Ta Li"",""Sarita Gajbhiye Meshram""
""citation_fulltext_html_url"",""https://link.springer.com/article/10.1007/s00500-018-3112-2""
""prism.publicationDate"",""2018-03-09""
""Content-Type"",""text/html; charset=UTF-8""
""journal_id"",""500""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""dc.description"",""Chaos has been dealt with a decent approach to reduce computational complexity while fulfilling security necessities of a cryptographic techniques. In this article, we purpose an efficient online/offline ID-based short signature procedure based on extended chaotic maps and also demonstrated that it is protected under unforgeability of ID-based short signature under chosen message attack. Some of the intriguing arrangements of presented procedures is that it gives multi-time use of the offline stockpiling, which permits the signer to reuse the offline pre-administered information in polynomial time, rather than one-time use in all past online/offline signature procedures.""
""og:type"",""article""
""citation_article_type"",""Foundations""
""og:title"",""An efficient online/offline ID-based short signature procedure using extended chaotic maps""
""prism.doi"",""doi:10.1007/s00500-018-3112-2""
""X-UA-Compatible"",""IE=edge""
""citation_firstpage"",""747""
""prism.startingPage"",""747""
""viewport"",""width=device-width, initial-scale=1""
""dc.rightsAgent"",""journalpermissions@springernature.com""
""prism.section"",""OriginalPaper""
""dc.identifier"",""doi:10.1007/s00500-018-3112-2""
""dc.subject"",""Computational Intelligence"",""Artificial Intelligence"",""Mathematical Logic and Foundations"",""Control, Robotics, Mechatronics""
""og:url"",""https://link.springer.com/article/10.1007/s00500-018-3112-2""
""prism.copyright"",""2018 Springer-Verlag GmbH Germany, part of Springer Nature""
";https://scholar.google.com/scholar?start=740&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094565-751;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Security of the Fiat-Shamir transformation in the quantum random-oracle model;J Don, S Fehr, C Majenz, C Schaffner ; Annual International Cryptology …, 2019  Springer;;"… Annual International Cryptology Conference. CRYPTO 2019: Advances in Cryptology –

CRYPTO 2019 pp 356-383 | Cite as. Security of the Fiat-Shamir Transformation in

the Quantum Random-Oracle Model. Authors; Authors …";Cité 70 fois;Les 11 versions;[PDF] arxiv.org;https://arxiv.org/pdf/1902.07556;;"""date"",""2020-07-28T00:58:45Z""
""pdf:PDFVersion"",""1.4""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.4""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""xmp:CreateDate"",""2020-07-27T20:58:45Z""
""modified"",""2020-07-28T00:58:45Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""xmp:ModifyDate"",""2020-07-27T20:58:45Z""
""pdf:docinfo:creator"",""""
""meta:author"",""""
""meta:creation-date"",""2020-07-28T00:58:45Z""
""created"",""2020-07-28T00:58:45Z""
""xmp:About"",""uuid:09759443-088a-11f6-0000-f673f08e5cc7""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-07-28T00:58:45Z""
""resourceName"",""1902.07556""
""Author"",""""
""producer"",""dvips + GPL Ghostscript GIT PRERELEASE 9.22""
""pdf:docinfo:producer"",""dvips + GPL Ghostscript GIT PRERELEASE 9.22""
""pdf:unmappedUnicodeCharsPerPage"",""3"",""3"",""0"",""26"",""22"",""172"",""86"",""3"",""20"",""20"",""29"",""30"",""12"",""35"",""8"",""0"",""0"",""0"",""0"",""62"",""110""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2020-07-28T00:58:45Z""
""Last-Modified"",""2020-07-28T00:58:45Z""
""dcterms:modified"",""2020-07-28T00:58:45Z""
""title"",""""
""xmpMM:DocumentID"",""uuid:09759443-088a-11f6-0000-f673f08e5cc7""
""Last-Save-Date"",""2020-07-28T00:58:45Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2020-07-28T00:58:45Z""
""meta:save-date"",""2020-07-28T00:58:45Z""
""Content-Length"",""391144""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""21""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""3329"",""3665"",""3940"",""2605"",""2417"",""1957"",""2654"",""2241"",""2864"",""2403"",""2209"",""1994"",""2291"",""2808"",""3352"",""3387"",""3717"",""3249"",""4062"",""2468"",""1442""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-07-28T00:58:45Z""
";https://scholar.google.com/scholar?start=570&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094595-885;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Masking fuzzy-searchable public databases;A Boldyreva, T Tang, B Warinschi ; International Conference on Applied …, 2019  Springer;;"… server may be trusted to protect its data storage against malicious compromises with traditional

crypto and security … h},P_2+\frac{L}{2^h})\), where h is the output length of the random oracle G …

Given some parameters \(P=k||L||g_L(\cdot )\), random oracles G and H and \(\mathbf{I …";Cité 1 fois;Les 2 versions;[PDF] iacr.org;https://eprint.iacr.org/2019/434.pdf;;"""date"",""2019-04-27T21:51:56Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2019-04-27T21:51:56Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.19 (TeX Live 2019/dev/Debian) kpathsea version 6.3.1/dev""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2019-04-27T21:51:56Z""
""created"",""2019-04-27T21:51:56Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-04-27T21:51:56Z""
""resourceName"",""434.pdf""
""Author"",""""
""producer"",""pdfTeX-1.40.19""
""pdf:docinfo:producer"",""pdfTeX-1.40.19""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""2"",""2"",""0"",""2"",""10"",""8"",""16"",""4"",""20"",""23"",""1"",""0"",""33"",""0"",""7"",""22"",""7"",""0"",""0"",""45"",""19"",""18"",""24"",""24"",""20"",""1"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2019-04-27T21:51:56Z""
""Last-Modified"",""2019-04-27T21:51:56Z""
""dcterms:modified"",""2019-04-27T21:51:56Z""
""title"",""""
""Last-Save-Date"",""2019-04-27T21:51:56Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2019-04-27T21:51:56Z""
""meta:save-date"",""2019-04-27T21:51:56Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.19 (TeX Live 2019/dev/Debian) kpathsea version 6.3.1/dev""
""Content-Length"",""530812""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""28""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""2466"",""3708"",""3812"",""3602"",""3287"",""1777"",""2484"",""3157"",""2723"",""3362"",""2034"",""3348"",""3874"",""2142"",""3217"",""3645"",""2549"",""2001"",""3285"",""2973"",""2292"",""3378"",""1687"",""2032"",""1995"",""2720"",""3398"",""481""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-04-27T21:51:56Z""
";https://scholar.google.com/scholar?start=700&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094633-1045;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;(Linkable) Ring Signature from Hash-Then-One-Way Signature;X Lu, MH Au, Z Zhang ; … On Trust, Security And Privacy In …, 2019  ieeexplore.ieee.org;;"… Page 2. As a reference, the traditional ring signatures employed in current cryptocurrency Monero

is about 11 … We first introduce the following oracles to model the capability of the adversary. -

Registration Oracle RO(?) ? pki: Upon request, RO generates a new user and …";Autres articles;;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/8883860/8887294/08887320.pdf?casa_token=CWIKn3Z3cbgAAAAA:mvUB6dop4asOwjOz-QhLtoV6dH8UmOX1urfYdZpAGte2aKhRT66Icr8aDaL7a3Flhcyf9uALW6E;;"""og:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""twitter:title"",""(Linkable) Ring Signature from Hash-Then-One-Way Signature""
""twitter:card"",""summary""
""Description"",""In this paper, we revisit the generic construction of ring signatures from hash-then-one-way type (Type-H) signatures proposed by Abe et al. (AOS) in 2004 and m""
""og:title"",""(Linkable) Ring Signature from Hash-Then-One-Way Signature""
""resourceName"",""08887320.pdf""
""language"",""en""
""title"",""(Linkable) Ring Signature from Hash-Then-One-Way Signature | IEEE Conference Publication | IEEE Xplore""
""og:description"",""In this paper, we revisit the generic construction of ring signatures from hash-then-one-way type (Type-H) signatures proposed by Abe et al. (AOS) in 2004 and made the following contributions. First, we give a proof for the generic construction, in a strengthened security model. Previously, this was only done for concrete instantiations, in a weaker model. Second, we extend AOS's framework to generically construct one-time linkable ring signatures from Type-H signatures and one-time signatures. Lastly, we instantiate the generic construction with an NTRU-based Type-H signature: Falcon~and obtain a post-quantum linkable ring signature scheme. Our analysis shows that the resulting linkable signature is more efficient than any existing lattice based solutions for small to moderate number of users.""
""twitter:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-UA-Compatible"",""IE=Edge""
""viewport"",""width=device-width, initial-scale=1.0""
""dc:title"",""(Linkable) Ring Signature from Hash-Then-One-Way Signature | IEEE Conference Publication | IEEE Xplore""
""twitter:description"",""In this paper, we revisit the generic construction of ring signatures from hash-then-one-way type (Type-H) signatures proposed by Abe et al. (AOS) in 2004 and made the following contributions. First, we give a proof for the generic construction, in a strengthened security model. Previously, this was only done for concrete instantiations, in a weaker model. Second, we extend AOS's framework to generically construct one-time linkable ring signatures from Type-H signatures and one-time signatures. Lastly, we instantiate the generic construction with an NTRU-based Type-H signature: Falcon~and obtain a post-quantum linkable ring signature scheme. Our analysis shows that the resulting linkable signature is more efficient than any existing lattice based solutions for small to moderate number of users.""
""Content-Encoding"",""UTF-8""
""Content-Type-Hint"",""text/html; charset=utf-8""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=860&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094637-1067;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;??? ???????? ?? ?????????? ??????: ????? ?????? ? ???? ????? ???;???? ????? ; ?????????? ???? ??????, 2019?  iranjournals.nlai.ir;;"… Key Words: Smart Contracts, Blockchain, Artificial intelligence, Oracle, Digital signatures, Intention. *

Assistant Professor, Private Law Department, Faculty of Law and Political Science, University

of Judicial Sciences, Iran (Corresponding Author). Mahdirashvand58@gmail.com …";Les 3 versions;Version HTML;[PDF] nlai.ir;https://iranjournals.nlai.ir/bitstream/handle/123456789/176838/80399447485D3723C47A9A5A99CE71AE.pdf?sequence=-1&isAllowed=y;;"""date"",""2019-09-25T06:48:24Z""
""pdf:PDFVersion"",""1.3""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""fa""
""dc:format"",""application/pdf; version=1.3""
""pdf:docinfo:creator_tool"",""""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2019-09-25T06:48:24Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""meta:author"",""""
""meta:creation-date"",""2019-09-23T08:56:01Z""
""created"",""2019-09-23T08:56:01Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-09-23T08:56:01Z""
""resourceName"",""80399447485D3723C47A9A5A99CE71AE.pdf""
""Author"",""""
""producer"",""Foxit PhantomPDF Printer Version 3.1.0.0815""
""pdf:docinfo:producer"",""Foxit PhantomPDF Printer Version 3.1.0.0815""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2019-09-23T08:56:01Z""
""Last-Modified"",""2019-09-25T06:48:24Z""
""dcterms:modified"",""2019-09-25T06:48:24Z""
""title"",""""
""Last-Save-Date"",""2019-09-25T06:48:24Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2019-09-25T06:48:24Z""
""meta:save-date"",""2019-09-25T06:48:24Z""
""Content-Length"",""987648""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""31""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""2038"",""2476"",""7272"",""6673"",""6028"",""7396"",""9049"",""6775"",""8335"",""7117"",""7154"",""7268"",""7658"",""9017"",""6839"",""9771"",""9144"",""10109"",""10162"",""9271"",""8676"",""8768"",""7913"",""8437"",""9592"",""8667"",""8347"",""7067"",""7881"",""9314"",""5270""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-09-23T08:56:01Z""
";https://scholar.google.com/scholar?start=880&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094579-811;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[PDF][PDF] Fine-Grained and Controlled Rewriting in Blockchains: Chameleon-Hashing Gone Attribute-Based.;D Derler, K Samelin, D Slamanig… ; IACR Cryptol. ePrint …, 2019  researchgate.net;;"… we use calligraphic letters, eg, A. Furthermore, we assume that all oracles defined within … insiders)

from learning whether adaptations of certain objects, eg, transactions, in the blockchain have

taken … adversary access to the secret key and a left-or-right style HashOrAdapt oracle …";Cité 36 fois;Les 4 versions;[PDF] researchgate.net;https://www.researchgate.net/profile/Daniel_Slamanig/publication/346108990_Fine-Grained_and_Controlled_Rewriting_in_Blockchains_Chameleon-Hashing_Gone_Attribute-Based/links/5fbc0699a6fdcc6cc65e0ce8/Fine-Grained-and-Controlled-Rewriting-in-Blockchains-Chameleon-Hashing-Gone-Attribute-Based.pdf;;;https://scholar.google.com/scholar?start=630&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094539-646;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Efficient fair multiparty protocols using Blockchain and trusted hardware;S Paul, A Shrivastava ; … on Cryptology and Information Security in Latin …, 2019  Springer;;"… 1 This protocol can be implemented using the existing (and easily available) infrastructure, such

as Blockchain, Google's CT log and Intel SGX [1 … Here, \(\mathcal {S}\) has access to the honest

oracles: the enclave \(\mathcal {G}\) and the public ledger BB in a similar fashion as …";Autres articles;;[PDF] iacr.org;https://eprint.iacr.org/2020/133.pdf;;"""date"",""2019-07-16T11:03:27Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""10"",""23"",""1"",""5"",""5"",""4"",""16"",""6"",""19"",""10"",""13"",""10"",""1"",""1"",""8""
""pdf:PDFVersion"",""1.5""
""xmp:CreatorTool"",""TeX""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dcterms:created"",""2019-07-16T11:03:27Z""
""language"",""en""
""Last-Modified"",""2019-07-16T11:03:27Z""
""dcterms:modified"",""2019-07-16T11:03:27Z""
""dc:format"",""application/pdf; version=1.5""
""Last-Save-Date"",""2019-07-16T11:03:27Z""
""pdf:docinfo:creator_tool"",""TeX""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2019-07-16T11:03:27Z""
""meta:save-date"",""2019-07-16T11:03:27Z""
""pdf:encrypted"",""false""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017/Debian) kpathsea version 6.2.3""
""modified"",""2019-07-16T11:03:27Z""
""Content-Length"",""666208""
""pdf:hasMarkedContent"",""false""
""Content-Type"",""application/pdf""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017/Debian) kpathsea version 6.2.3""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""trapped"",""False""
""meta:creation-date"",""2019-07-16T11:03:27Z""
""created"",""2019-07-16T11:03:27Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""20""
""Creation-Date"",""2019-07-16T11:03:27Z""
""resourceName"",""133.pdf""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""1935"",""2421"",""1090"",""2380"",""2196"",""2093"",""1954"",""2185"",""1583"",""1866"",""2696"",""1940"",""2499"",""2423"",""2464"",""2364"",""2687"",""1175"",""2870"",""1327""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""producer"",""pdfTeX-1.40.18""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""pdfTeX-1.40.18""
""pdf:docinfo:created"",""2019-07-16T11:03:27Z""
";https://scholar.google.com/scholar?start=460&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094600-902;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[CITATION][C] Panorama des applications des blockchains ŕ l'énergie;S Tucci, G Deleuze;;;null;;null;null;;;;https://scholar.google.com/scholar?start=720&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094649-1111;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Lower bounds for oblivious data structures;R Jacob, KG Larsen, JB Nielsen ; Proceedings of the Thirtieth Annual ACM …, 2019  SIAM;;"… Moreover, a recent lower bound for ORAMs by Larsen and Nielsen [CRYPTO'18] show that they …

Partially supported by the Concordium Blockchain Research Center, Aarhus University, Denmark …

long uniform random bit string R, which is referred to as the random oracle bit string …";Cité 18 fois;Les 13 versions;[PDF] arxiv.org;https://arxiv.org/pdf/1810.10635;;"""date"",""2018-10-26T00:39:35Z""
""pdf:PDFVersion"",""1.4""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.4""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""xmp:CreateDate"",""2018-10-25T20:39:35Z""
""modified"",""2018-10-26T00:39:35Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""xmp:ModifyDate"",""2018-10-25T20:39:35Z""
""pdf:docinfo:creator"",""""
""meta:author"",""""
""meta:creation-date"",""2018-10-26T00:39:35Z""
""created"",""2018-10-26T00:39:35Z""
""xmp:About"",""uuid:292f4dd7-10d4-11f4-0000-91f00015f56e""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2018-10-26T00:39:35Z""
""resourceName"",""1810.10635""
""Author"",""""
""producer"",""dvips + GPL Ghostscript GIT PRERELEASE 9.22""
""pdf:docinfo:producer"",""dvips + GPL Ghostscript GIT PRERELEASE 9.22""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""4"",""0"",""6"",""0"",""0"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2018-10-26T00:39:35Z""
""Last-Modified"",""2018-10-26T00:39:35Z""
""dcterms:modified"",""2018-10-26T00:39:35Z""
""title"",""""
""xmpMM:DocumentID"",""uuid:292f4dd7-10d4-11f4-0000-91f00015f56e""
""Last-Save-Date"",""2018-10-26T00:39:35Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2018-10-26T00:39:35Z""
""meta:save-date"",""2018-10-26T00:39:35Z""
""Content-Length"",""201266""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""11""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""3348"",""3666"",""3853"",""3046"",""3224"",""3706"",""3063"",""2749"",""2948"",""2689"",""1506""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2018-10-26T00:39:35Z""
";https://scholar.google.com/scholar?start=930&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094562-748;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[PDF][PDF] Ergo: A resilient platform for contractual money;E Developers ;2019 ergoplatform.org;;"… Ethereum. Thus, Ergo mining could not have started before certain events in the

real world and the cryptocurrency space. • Treasury … otherwise. To deliver the

temperature into the blockchain, a trusted oracle is needed. In …";Cité 3 fois;Les 2 versions;[PDF] ergoplatform.org;https://ergoplatform.org/docs/whitepaper.pdf;;;https://scholar.google.com/scholar?start=560&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094626-1012;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;CCA-Secure Deterministic Identity-Based Encryption Scheme;M Huang, B Yang, Y Zhao, K Liang, L Xue… ; Journal of Universal …, 2019  jucs.org;;"… encrypting a plaintext into a unique ciphertext without involving any randomness, was introduced

by Bellare, Boldyreva, and O'Neill (CRYPTO 2007) as … Constructions of DPKE schemes satisfying

the notions of security were proposed in the random oracle model by Bellare et al …";Cité 1 fois;Les 6 versions;[PDF] surrey.ac.uk;http://epubs.surrey.ac.uk/852687/1/CCA-Secure%20Deterministic%20Identity-Based%20Encryption%20Scheme%20-%20VoR.pdf;;"""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""dc:title"",""301 Moved Permanently""
""Content-Encoding"",""ISO-8859-1""
""resourceName"",""CCA-Secure%20Deterministic%20Identity-Based%20Encryption%20Scheme%20-%20VoR.pdf""
""language"",""en""
""Content-Length"",""323""
""title"",""301 Moved Permanently""
""Content-Type"",""text/html; charset=ISO-8859-1""
";https://scholar.google.com/scholar?start=830&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094621-992;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Algorithms on graph-structured data with imperfect information;H Zhou ;2019 ideals.illinois.edu;;"… to ask queries and collect information from the oracle. In this work, we study two kinds of oracles:

the pointwise oracle F0 : V ?? [k] and the pairwise oracle 4 Page 12. O0 : V × V ?? {0,1}, which

are defined as follows. For all v1,v2 ? V , F0(v1) = f(v1), O0(v1,v2) = ? ? ? …";Autres articles;;[PDF] illinois.edu;https://www.ideals.illinois.edu/bitstream/handle/2142/105609/ZHOU-THESIS-2019.pdf?sequence=1;;"""date"",""2019-06-15T03:01:20Z""
""pdf:unmappedUnicodeCharsPerPage"",""1"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""8"",""3"",""1"",""0"",""5"",""7"",""0"",""6"",""0"",""4"",""1"",""1"",""4"",""0"",""0"",""1"",""0"",""0"",""3"",""1"",""2"",""3"",""3"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""6"",""7"",""8"",""0"",""1"",""3"",""1"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.5""
""xmp:CreatorTool"",""TeX""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dcterms:created"",""2019-06-15T03:01:20Z""
""language"",""en""
""Last-Modified"",""2019-06-15T03:01:20Z""
""dcterms:modified"",""2019-06-15T03:01:20Z""
""dc:format"",""application/pdf; version=1.5""
""Last-Save-Date"",""2019-06-15T03:01:20Z""
""pdf:docinfo:creator_tool"",""TeX""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2019-06-15T03:01:20Z""
""meta:save-date"",""2019-06-15T03:01:20Z""
""pdf:encrypted"",""false""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017) kpathsea version 6.2.3""
""modified"",""2019-06-15T03:01:20Z""
""Content-Length"",""798819""
""pdf:hasMarkedContent"",""false""
""Content-Type"",""application/pdf""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017) kpathsea version 6.2.3""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""trapped"",""False""
""meta:creation-date"",""2019-06-15T03:01:20Z""
""created"",""2019-06-15T03:01:20Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""51""
""Creation-Date"",""2019-06-15T03:01:20Z""
""resourceName"",""ZHOU-THESIS-2019.pdf""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""16"",""304"",""1728"",""500"",""37"",""1238"",""903"",""1373"",""2048"",""792"",""1421"",""1412"",""1990"",""1452"",""1216"",""1735"",""1522"",""1680"",""1382"",""1344"",""569"",""1468"",""1102"",""1963"",""1232"",""1430"",""911"",""1219"",""1571"",""1298"",""1523"",""1502"",""953"",""1515"",""2055"",""945"",""1469"",""836"",""376"",""1699"",""1288"",""1678"",""1670"",""1496"",""861"",""1236"",""924"",""313"",""1443"",""1836"",""1631""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""producer"",""pdfTeX-1.40.18""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""pdfTeX-1.40.18""
""pdf:docinfo:created"",""2019-06-15T03:01:20Z""
";https://scholar.google.com/scholar?start=810&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094555-711;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[PDF][PDF] Contribution of Blockchain Applications on the Economy in Global Logistic;S Adiguzel ; academia.edu;;"… If the conditions of a smart contract depend upon real world data, systems called “oracles” can

be implemented to monitor and verify this data (Krystsina Sadouskayap p 11) … The blockchain

technology, which is the substructure of the crypto money that enters into …";Autres articles;Version HTML;[PDF] academia.edu;https://www.academia.edu/download/64297788/CONTR%C4%B0BUT%C4%B0ON%20%20TAM%20MET%C4%B0N.pdf;;;https://scholar.google.com/scholar?start=530&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094637-1065;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[PDF][PDF] Smart contracts may become a risk for computer scientists;AW Hamburg ; blockchain.pwias.ubc.ca;;"… deposited via his cryptographic owner-address? The transaction itself, which may

trigger the smart contract from outside as Oracle? The miner who runs the process

on the blockchain? Against this background, a smart contract …";Autres articles;Version HTML;[PDF] ubc.ca;https://blockchain.pwias.ubc.ca/sites/blockchain.pwias.ubc.ca/files/report-files/SKWAREK%20Smart%20contracts%20as%20a%20risk%20for%20computer%20scientists_Skwarek%20Hoffmann.v3.pdf;;"""date"",""2019-03-22T00:23:22Z""
""pdf:PDFVersion"",""1.6""
""xmp:CreatorTool"",""Acrobat PDFMaker 19 fĂźr Word""
""pdf:docinfo:title"",""""
""Company"",""""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""ZOTERO_PREF_1"",""<data data-version=""""3"""" zotero-version=""""5.0.63""""><session id=""""TczoUYbt""""/><style id=""""http://www.zotero.org/styles/ieee"""" locale=""""en-GB"""" hasBibliography=""""1"""" bibliographyStyleHasBeenSet=""""1""""/><prefs><pref name=""""fieldType"""" value=""""Field""""/><pref name=""""automaticJour""
""ZOTERO_PREF_2"",""nalAbbreviations"""" value=""""true""""/></prefs></data>""
""language"",""en""
""dc:format"",""application/pdf; version=1.6""
""pdf:docinfo:creator_tool"",""Acrobat PDFMaker 19 fĂźr Word""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""xmp:CreateDate"",""2019-03-22T11:23:17Z""
""modified"",""2019-03-22T00:23:22Z""
""pdf:docinfo:custom:SourceModified"",""D:20190322002247""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""true""
""xmp:ModifyDate"",""2019-03-22T11:23:22Z""
""pdf:docinfo:creator"",""Thomas Hoffmann""
""meta:author"",""Thomas Hoffmann""
""meta:creation-date"",""2019-03-22T00:23:17Z""
""created"",""2019-03-22T00:23:17Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-03-22T00:23:17Z""
""resourceName"",""SKWAREK%20Smart%20contracts%20as%20a%20risk%20for%20computer%20scientists_Skwarek%20Hoffmann.v3.pdf""
""pdf:docinfo:custom:Comments"",""""
""Author"",""Thomas Hoffmann""
""producer"",""Adobe PDF Library 19.10.123""
""pdf:docinfo:producer"",""Adobe PDF Library 19.10.123""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""pdf:docinfo:custom:ZOTERO_PREF_2"",""nalAbbreviations"""" value=""""true""""/></prefs></data>""
""pdf:docinfo:custom:ZOTERO_PREF_1"",""<data data-version=""""3"""" zotero-version=""""5.0.63""""><session id=""""TczoUYbt""""/><style id=""""http://www.zotero.org/styles/ieee"""" locale=""""en-GB"""" hasBibliography=""""1"""" bibliographyStyleHasBeenSet=""""1""""/><prefs><pref name=""""fieldType"""" value=""""Field""""/><pref name=""""automaticJour""
""dc:creator"",""Thomas Hoffmann""
""dcterms:created"",""2019-03-22T00:23:17Z""
""Last-Modified"",""2019-03-22T00:23:22Z""
""dcterms:modified"",""2019-03-22T00:23:22Z""
""title"",""""
""xmpMM:DocumentID"",""uuid:9ae58d55-868e-4a82-b382-8149f53af60a""
""Last-Save-Date"",""2019-03-22T00:23:22Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2019-03-22T00:23:22Z""
""meta:save-date"",""2019-03-22T00:23:22Z""
""Content-Type"",""application/pdf""
""xmp:MetadataDate"",""2019-03-22T11:23:22Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Thomas Hoffmann""
""pdf:producer"",""Adobe PDF Library 19.10.123""
""dc:subject"",""""
""Comments"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""6""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""4806"",""5171"",""5669"",""5595"",""5524"",""2771""
""access_permission:extract_content"",""true""
""pdf:docinfo:custom:Company"",""""
""access_permission:can_print"",""true""
""SourceModified"",""D:20190322002247""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-03-22T00:23:17Z""
";https://scholar.google.com/scholar?start=880&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094562-741;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;On the complexity of collision resistant hash functions: New and old black-box separations;N Bitansky, A Degwekar ; Theory of Cryptography Conference, 2019  Springer;;"… Oracles. We consider oracle-aided algorithms (or circuits) that make repeated calls to an

oracle \(\varGamma \). Throughout, we will consider deterministic oracles \(\varGamma \)

that are a-priori sampled from a distribution \(\varGamma \) on oracles …";Cité 6 fois;Les 2 versions;[PDF] iacr.org;https://eprint.iacr.org/2019/686.pdf;;"""date"",""2019-09-23T00:41:15Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2019-09-23T00:41:15Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017) kpathsea version 6.2.3""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2019-09-23T00:41:15Z""
""created"",""2019-09-23T00:41:15Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-09-23T00:41:15Z""
""resourceName"",""686.pdf""
""Author"",""""
""producer"",""pdfTeX-1.40.18""
""pdf:docinfo:producer"",""pdfTeX-1.40.18""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""14"",""10"",""6"",""40"",""67"",""30"",""12"",""14"",""22"",""15"",""59"",""48"",""16"",""34"",""18"",""42"",""35"",""5"",""16"",""25"",""12"",""23"",""21"",""20"",""33"",""37"",""36"",""37"",""36"",""0"",""1"",""0"",""0"",""42"",""22"",""31""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2019-09-23T00:41:15Z""
""Last-Modified"",""2019-09-23T00:41:15Z""
""dcterms:modified"",""2019-09-23T00:41:15Z""
""title"",""""
""Last-Save-Date"",""2019-09-23T00:41:15Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2019-09-23T00:41:15Z""
""meta:save-date"",""2019-09-23T00:41:15Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017) kpathsea version 6.2.3""
""Content-Length"",""383677""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""40""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""1446"",""1152"",""3217"",""2604"",""2392"",""2861"",""3213"",""2961"",""2127"",""2065"",""1854"",""2300"",""2348"",""2002"",""1339"",""2068"",""2300"",""1625"",""2183"",""1862"",""2287"",""1962"",""2205"",""1491"",""1901"",""2030"",""2558"",""2688"",""1204"",""2277"",""1856"",""1711"",""2020"",""2001"",""2093"",""2136"",""2020"",""1561"",""2040"",""825""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-09-23T00:41:15Z""
";https://scholar.google.com/scholar?start=560&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094626-1020;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;A lattice-based linkable ring signature supporting stealth addresses;Z Liu, K Nguyen, G Yang, H Wang, DS Wong ; European Symposium on …, 2019  Springer;;"… Note that \(L_{dpk}\) captures the scenarios that the valid derived public keys are stored on the

blockchain and are publicly accessible … (\mathcal A\) can adaptively query the following oracles:

Derived Public Key Adding Oracle \(\mathsf{ODPKAdd}(\cdot , \cdot )\) …";Cité 5 fois;DS Wong;null;;;;https://scholar.google.com/scholar?start=830&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094649-1115;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Mixeth: efficient, trustless coin mixing service for ethereum;IA Seres, DA Nagy, C Buckland… ; … on Blockchain …, 2019  drops.dagstuhl.de;;"… 2.6 Ethereum Ethereum is a cryptocurrency built on top of a blockchain. Similarly to Bitcoin,

network participants broadcast transactions in a peer-to-peer network, where transactions are

bundled together into blocks that are appended to a public ledger called blockchain …";Cité 6 fois;Les 5 versions;[PDF] dagstuhl.de;https://drops.dagstuhl.de/opus/volltexte/2019/11403/pdf/OASIcs-Tokenomics-2019-13.pdf;;"""date"",""2019-10-18T15:58:22Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""MixEth: Efficient, Trustless Coin Mixing Service for Ethereum""
""xmp:CreatorTool"",""LaTeX with oasics-v2019.cls and hyperref.sty""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""OASIcs, Vol.71, Tokenomics 2019; Copyright (C) IstvĂĄn AndrĂĄs Seres, DĂĄniel A. Nagy, Chris Buckland, and PĂŠter Burcsi; licensed under Creative Commons License CC-BY""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with oasics-v2019.cls and hyperref.sty""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""MixEth: Efficient, Trustless Coin Mixing Service for Ethereum""
""modified"",""2019-10-18T15:58:22Z""
""cp:subject"",""OASIcs, Vol.71, Tokenomics 2019; Copyright (C) IstvĂĄn AndrĂĄs Seres, DĂĄniel A. Nagy, Chris Buckland, and PĂŠter Burcsi; licensed under Creative Commons License CC-BY""
""pdf:docinfo:subject"",""OASIcs, Vol.71, Tokenomics 2019; Copyright (C) IstvĂĄn AndrĂĄs Seres, DĂĄniel A. Nagy, Chris Buckland, and PĂŠter Burcsi; licensed under Creative Commons License CC-BY""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""IstvĂĄn AndrĂĄs Seres, DĂĄniel A. Nagy, Chris Buckland, PĂŠter Burcsi""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.20 (TeX Live 2019) kpathsea version 6.3.1""
""meta:author"",""IstvĂĄn AndrĂĄs Seres, DĂĄniel A. Nagy, Chris Buckland, PĂŠter Burcsi""
""trapped"",""False""
""meta:creation-date"",""2019-10-18T15:58:22Z""
""created"",""2019-10-18T15:58:22Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-10-18T15:58:22Z""
""resourceName"",""OASIcs-Tokenomics-2019-13.pdf""
""Author"",""IstvĂĄn AndrĂĄs Seres, DĂĄniel A. Nagy, Chris Buckland, PĂŠter Burcsi""
""producer"",""pdfTeX-1.40.20""
""pdf:docinfo:producer"",""pdfTeX-1.40.20""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""3"",""0"",""0"",""0"",""0"",""0"",""2"",""0"",""0"",""0"",""0"",""6"",""2"",""5"",""0"",""0""
""Keywords"",""Cryptography, Verifiable shuffle, Anonymity, Cryptocurrency, Ethereum, Coin mixer, State Channel""
""access_permission:modify_annotations"",""true""
""dc:creator"",""IstvĂĄn AndrĂĄs Seres, DĂĄniel A. Nagy, Chris Buckland, PĂŠter Burcsi""
""dcterms:created"",""2019-10-18T15:58:22Z""
""Last-Modified"",""2019-10-18T15:58:22Z""
""dcterms:modified"",""2019-10-18T15:58:22Z""
""title"",""MixEth: Efficient, Trustless Coin Mixing Service for Ethereum""
""Last-Save-Date"",""2019-10-18T15:58:22Z""
""pdf:docinfo:keywords"",""Cryptography, Verifiable shuffle, Anonymity, Cryptocurrency, Ethereum, Coin mixer, State Channel""
""pdf:docinfo:modified"",""2019-10-18T15:58:22Z""
""meta:save-date"",""2019-10-18T15:58:22Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.20 (TeX Live 2019) kpathsea version 6.3.1""
""Content-Length"",""595562""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""IstvĂĄn AndrĂĄs Seres, DĂĄniel A. Nagy, Chris Buckland, PĂŠter Burcsi""
""dc:subject"",""Cryptography, Verifiable shuffle, Anonymity, Cryptocurrency, Ethereum, Coin mixer, State Channel""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""20""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""2341"",""3109"",""2623"",""2311"",""3137"",""3076"",""3022"",""2197"",""1961"",""2485"",""3434"",""2995"",""2247"",""3394"",""1352"",""1276"",""1837"",""1860"",""2068"",""1016""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""Cryptography, Verifiable shuffle, Anonymity, Cryptocurrency, Ethereum, Coin mixer, State Channel""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-10-18T15:58:22Z""
";https://scholar.google.com/scholar?start=930&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094562-742;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Darstellung der Blockchain-Technologie;K Himmer ; Blockchainbasiertes Fundraising als innovative …, 2019  Springer;;"… Ausgestaltungen ermöglichen durch die Hinzunahme von sogenannten Oracles die

Vertragsinhalte … Das Oracle kann ebenfalls eine automatisierte Instanz sein und übernimmt … Coin

Offering (ICO): Unternehmensfinanzierung auf Basis der Blockchain-Technologie, Wiesbaden …";Autres articles;;null;;;;https://scholar.google.com/scholar?start=560&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094560-736;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;A Provable Secure Server Friendly Two-Party SM2 Singing Protocol for Blockchain IoT;H Tian, Y Su, Z Liang ; 2019 IEEE Globecom Workshops (GC …, 2019  ieeexplore.ieee.org;;"… So the probability of successful simulation about the random oracle is at least 1 ? qH … Polyzos,

“Interacting with the Internet of Things Using Smart Contracts and Blockchain Technologies,”

G … Secure Two-Party ECDSA Signing,” J. Katz and H. Shacham (Eds.): CRYPTO 2017, Part …";Cité 1 fois;;null;;;;https://scholar.google.com/scholar?start=550&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094574-794;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;A lightweight cryptographic protocol with certificateless signature for the internet of things;L Zhou, C Su, KH Yeh ; ACM Transactions on Embedded Computing …, 2019  dl.acm.org;;"… In light of the deployment of certificateless signature and bilinear pairing crypto-primitives, the

analysis is with the adversary abilities and security models … In general, AI and AII are able to query

the following oracles: —CreateUser: Given a query ID ? {0, 1}? , the oracle gets (sID …";Cité 5 fois;;[HTML] acm.org;https://dl.acm.org/doi/fullHtml/10.1145/3301306?casa_token=m5SXlQvyEK8AAAAA:vvD0U2CF8zVRvHaiDKHDh1MSmWiZvC9GRjrv88Z8vDDX0-1qOfFtww9wuTRAhLSYWnZ6JDDYa0k;;;https://scholar.google.com/scholar?start=610&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094630-1040;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[HTML][HTML] Blockchain characteristics and consensus in modern business processes;W Viriyasitavat, D Hoonsopon ; Journal of Industrial Information Integration, 2019  Elsevier;;"… After the success of Bitcoin [1], the first cryptocurrency appeared in early 2009, Blockchain

technology has attracted attentions from academia and industry sectors [2]. Currently, the rise

of Blockcahin applications spans across diverse range far beyond crytocurrencies, including …";Cité 150 fois;Les 3 versions;[HTML] sciencedirect.com;https://www.sciencedirect.com/science/article/pii/S2452414X18300815?casa_token=jYizV4n3jDgAAAAA:tgNvJllo19bxWExlQNbnnkNkkD7sZmERVSFBlo6o9-Ixya4CW-TYu7014pgM131bDIWW5BJv;;;https://scholar.google.com/scholar?start=850&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094541-657;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;A Survey on Range Proof and Its Applications on Blockchain;C Deng, J Fan, Z Wang, Y Luo, Y Zheng… ; … on CyberEnabled …, 2019  ieeexplore.ieee.org;;"… In the range proof, especially in the blockchain technology, anyone can verify the transaction

on the chain … 1) Extended Domain Method: In Crypto in 1987, Brickel et al … proving that does not

rely on the fiar-shamir heuristic and the safety is not dependent on the random oracles [16 …";Cité 2 fois;Les 2 versions;null;;;;https://scholar.google.com/scholar?start=470&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094647-1105;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;A unifying model of legal smart contracts;J Ladleif, M Weske ; International Conference on Conceptual Modeling, 2019  Springer;;"… Especially in the area of blockchain-based smart contracts, many visualization approaches have

been explored for … DataSources are specialized into Parameters, Variables and Oracles … An Oracle

could be an online service (eg, providing currency exchange rates), or an event …";Cité 9 fois;Les 2 versions;[PDF] researchgate.net;https://www.researchgate.net/profile/Jan_Ladleif/publication/336849018_A_Unifying_Model_of_Legal_Smart_Contracts/links/5dc00747299bf1a47b11de4e/A-Unifying-Model-of-Legal-Smart-Contracts.pdf;;;https://scholar.google.com/scholar?start=920&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094539-649;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Assessing the Merits of Blockchain Technology for Global Sustainable Development Initiatives;SL Chamberlain ;2019 dash.harvard.edu;;"… energy efficiency while contributing to sustainable development initiatives? Maintaining and

adding to the blockchain, in the case of cryptocurrency, requires what is known as hashing blocks.

Hashing blocks for cryptocurrency is known as Proof of Work (PoW) …";Cité 1 fois;Les 4 versions;[PDF] harvard.edu;https://dash.harvard.edu/bitstream/handle/1/42004229/CHAMBERLAIN-DOCUMENT-2019.pdf?sequence=1;;"""date"",""2019-10-21T23:31:38Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.4""
""xmp:CreatorTool"",""MicrosoftÂŽ Word 2010""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dc:creator"",""Stacia""
""dcterms:created"",""2019-10-21T23:16:39Z""
""language"",""en""
""Last-Modified"",""2019-10-21T23:31:38Z""
""dcterms:modified"",""2019-10-21T23:31:38Z""
""dc:format"",""application/pdf; version=1.4""
""Last-Save-Date"",""2019-10-21T23:31:38Z""
""pdf:docinfo:creator_tool"",""MicrosoftÂŽ Word 2010""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2019-10-21T23:31:38Z""
""meta:save-date"",""2019-10-21T23:31:38Z""
""pdf:encrypted"",""false""
""modified"",""2019-10-21T23:31:38Z""
""Content-Length"",""939055""
""pdf:hasMarkedContent"",""false""
""Content-Type"",""application/pdf""
""pdf:docinfo:creator"",""Stacia""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Stacia""
""meta:author"",""Stacia""
""meta:creation-date"",""2019-10-21T23:16:39Z""
""created"",""2019-10-21T23:16:39Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""86""
""Creation-Date"",""2019-10-21T23:16:39Z""
""resourceName"",""CHAMBERLAIN-DOCUMENT-2019.pdf""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""706"",""396"",""63"",""1641"",""1732"",""92"",""1018"",""2242"",""1209"",""238"",""586"",""1327"",""498"",""1652"",""1979"",""1782"",""1286"",""1814"",""1763"",""1835"",""1800"",""1911"",""1748"",""1963"",""1848"",""921"",""1911"",""1649"",""1958"",""1996"",""1379"",""1162"",""1720"",""1836"",""2171"",""1877"",""663"",""1140"",""3066"",""2353"",""2306"",""2093"",""3081"",""1714"",""1379"",""1632"",""144"",""88"",""800"",""76"",""1468"",""1698"",""1877"",""1938"",""1956"",""1880"",""1872"",""2022"",""1840"",""1961"",""1851"",""1812"",""1975"",""1776"",""1901"",""1809"",""1905"",""1751"",""1957"",""1071"",""1909"",""1052"",""2204"",""1919"",""1816"",""1903"",""1997"",""1760"",""1278"",""1952"",""2077"",""2144"",""2212"",""2090"",""2289"",""335""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""Author"",""Stacia""
""producer"",""MicrosoftÂŽ Word 2010""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""MicrosoftÂŽ Word 2010""
""pdf:docinfo:created"",""2019-10-21T23:16:39Z""
";https://scholar.google.com/scholar?start=460&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094635-1052;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[PDF][PDF] Master's Degree Course in Computer Engineering;A Doglioli, F Lamberti ;2019 webthesis.biblio.polito.it;;"… 48 - 3.13.2. Oracles … As explained before, in literature most of the applications

of blockchain are in the FinTech area … considering the well-known scenario of an

exchange of a certain digital asset (eg a cryptocurrency) …";Autres articles;Version HTML;[PDF] polito.it;https://webthesis.biblio.polito.it/12411/1/tesi.pdf;;"""date"",""2019-10-08T13:30:32Z""
""pdf:PDFVersion"",""1.7""
""xmp:CreatorTool"",""Word""
""pdf:docinfo:title"",""Microsoft Word - Thesis_AD 3.docx""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""pdfa:PDFVersion"",""A-2b""
""xmpMM:History:Action"",""converted""
""language"",""en""
""dc:format"",""application/pdf; version=""""A-2b"""""",""application/pdf; version=1.7""
""pdf:docinfo:creator_tool"",""Word""
""access_permission:fill_in_form"",""true""
""xmpMM:History:When"",""2019-10-08T15:30:32Z""
""pdf:encrypted"",""false""
""dc:title"",""Microsoft Word - Thesis_AD 3.docx""
""xmp:CreateDate"",""2019-10-08T13:28:32Z""
""modified"",""2019-10-08T13:30:32Z""
""xmpMM:History:SoftwareAgent"",""3-Heights(TM) Document Converter 4.8.25.5 (www.pdf-tools.com)""
""pdf:hasMarkedContent"",""false""
""xmpMM:History:InstanceID"",""urn:uuid:072ceed3-c1a8-4456-98b7-69ac1c93b7e8""
""xmp:ModifyDate"",""2019-10-08T15:30:32Z""
""meta:creation-date"",""2019-10-08T13:28:32Z""
""created"",""2019-10-08T13:28:32Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-10-08T13:28:32Z""
""resourceName"",""tesi.pdf""
""pdfaid:part"",""2""
""producer"",""3-Heights(TM) Document Converter 4.8.25.5 (www.pdf-tools.com)""
""pdf:docinfo:producer"",""3-Heights(TM) Document Converter 4.8.25.5 (www.pdf-tools.com)""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""9"",""0"",""0"",""0"",""0"",""2"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""access_permission:modify_annotations"",""true""
""dcterms:created"",""2019-10-08T13:28:32Z""
""Last-Modified"",""2019-10-08T13:30:32Z""
""dcterms:modified"",""2019-10-08T13:30:32Z""
""title"",""Microsoft Word - Thesis_AD 3.docx""
""Last-Save-Date"",""2019-10-08T13:30:32Z""
""pdf:docinfo:modified"",""2019-10-08T13:30:32Z""
""meta:save-date"",""2019-10-08T13:30:32Z""
""Content-Length"",""7286296""
""Content-Type"",""application/pdf""
""xmp:MetadataDate"",""2019-10-08T15:30:32Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""pdfaid:conformance"",""B""
""pdf:producer"",""3-Heights(TM) Document Converter 4.8.25.5 (www.pdf-tools.com)""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""102""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""287"",""9"",""1925"",""390"",""4914"",""5905"",""4243"",""1768"",""2714"",""1644"",""1108"",""1513"",""3437"",""3098"",""3432"",""2572"",""3389"",""2610"",""3297"",""3466"",""2746"",""1780"",""1560"",""3050"",""2244"",""2937"",""3624"",""2979"",""3062"",""3048"",""2684"",""2806"",""3579"",""3731"",""3726"",""2996"",""3328"",""2873"",""2773"",""3177"",""3127"",""3084"",""3531"",""2917"",""2468"",""3492"",""2862"",""3481"",""2983"",""727"",""3193"",""2096"",""2646"",""3264"",""2369"",""3941"",""2388"",""1592"",""3448"",""1494"",""1310"",""2851"",""3152"",""2309"",""1414"",""2559"",""948"",""1759"",""3071"",""1701"",""2633"",""3045"",""1293"",""1833"",""2682"",""1992"",""2155"",""1837"",""1699"",""2906"",""1221"",""2647"",""1944"",""2524"",""1659"",""1515"",""2517"",""1798"",""1227"",""2554"",""2354"",""1915"",""2649"",""1406"",""2263"",""1026"",""1232"",""949"",""3584"",""2147"",""3183"",""1601""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-10-08T13:28:32Z""
";https://scholar.google.com/scholar?start=870&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094614-968;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Decentralized react native android application;H Järvinen ;2019 theseus.fi;;"… enabling building android application to utilize smart contract in Ethereum blockchain. International

system Usual name Effigy 10-18 – attoether wei Wei Dai … compile java programs [78]. JDK is

developed by a company called Oracle [79]. JDK is development environment …";Autres articles;Version HTML;[PDF] theseus.fi;https://www.theseus.fi/bitstream/handle/10024/169052/Henri_J%C3%A4rvinen_Thesis_12_05_2019.pdf?sequence=2&isAllowed=y;;"""date"",""2019-05-12T18:54:26Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.7""
""xmp:CreatorTool"",""MicrosoftÂŽ Word for Office 365""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""language"",""en""
""dcterms:created"",""2019-05-12T18:54:26Z""
""Last-Modified"",""2019-05-12T18:54:26Z""
""dcterms:modified"",""2019-05-12T18:54:26Z""
""dc:format"",""application/pdf; version=1.7""
""xmpMM:DocumentID"",""uuid:35337BE5-84EC-4533-A366-ADAD6E32EA34""
""Last-Save-Date"",""2019-05-12T18:54:26Z""
""pdf:docinfo:creator_tool"",""MicrosoftÂŽ Word for Office 365""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2019-05-12T18:54:26Z""
""meta:save-date"",""2019-05-12T18:54:26Z""
""pdf:encrypted"",""false""
""xmp:CreateDate"",""2019-05-12T21:54:26Z""
""modified"",""2019-05-12T18:54:26Z""
""Content-Length"",""1135090""
""pdf:hasMarkedContent"",""true""
""Content-Type"",""application/pdf""
""xmp:ModifyDate"",""2019-05-12T21:54:26Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""dc:language"",""en-FI""
""pdf:producer"",""MicrosoftÂŽ Word for Office 365""
""meta:creation-date"",""2019-05-12T18:54:26Z""
""created"",""2019-05-12T18:54:26Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""60""
""Creation-Date"",""2019-05-12T18:54:26Z""
""resourceName"",""Henri_J%C3%A4rvinen_Thesis_12_05_2019.pdf""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""182"",""1246"",""1260"",""791"",""160"",""482"",""2151"",""2500"",""1849"",""1647"",""2081"",""1627"",""2111"",""1684"",""2231"",""1186"",""1210"",""2003"",""1781"",""1923"",""1884"",""867"",""1870"",""1765"",""953"",""310"",""865"",""1099"",""1054"",""1187"",""598"",""1042"",""734"",""974"",""513"",""1321"",""1591"",""1636"",""2246"",""1266"",""1493"",""712"",""529"",""1182"",""1493"",""1533"",""1335"",""1407"",""645"",""781"",""923"",""1689"",""1670"",""1677"",""1570"",""1641"",""1374"",""1550"",""1025"",""23""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""producer"",""MicrosoftÂŽ Word for Office 365""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""MicrosoftÂŽ Word for Office 365""
""pdf:docinfo:created"",""2019-05-12T18:54:26Z""
";https://scholar.google.com/scholar?start=780&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094640-1076;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Post-collusion security and distance bounding;S Mauw, Z Smith, J Toro;Pozo…  Proceedings of the 2019 …, 2019  dl.acm.org;;"… in form of a cryptographic oracle, which outputs the result of a crypto-operation , without … In their

model for terrorist fraud, the adversary queries a distant prover's oracle to obtain … The basic

deviation consists of leakage of session data, cryptographic oracles, reuse of nonces, or …";Cité 6 fois;Les 3 versions;[PDF] acm.org;https://dl.acm.org/doi/pdf/10.1145/3319535.3345651?casa_token=tdOPFpJcfFYAAAAA:jUPNretslIw51rvlhbqQHJQ7lI4LkaMgJk4gWGicW8TK7IhFxev7ngdyXGgTsHUmlf2cW4n5OEo;;;https://scholar.google.com/scholar?start=890&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094588-855;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Direct CCA-Secure KEM and Deterministic PKE from Plain LWE;PKE Deterministic ; … Conference, PQCrypto 2019, Chongqing, China, May …, 2019  Springer;;"… from the recent NIST Post- Quantum KEM competition, wherein most submitters chose to embrace

random oracles and stronger … challenge ciphertext: t?? f (s?); c?? ? s?ˇ[A| A1+ ? (t?) G] ? p

The decryption oracle is implemented … In: Canetti, R., Garay, JA (eds.) CRYPTO 2013 …";Autres articles;;null;;;;https://scholar.google.com/scholar?start=670&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094602-920;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Generic Construction of ElGamal-Type Attribute-Based Encryption Schemes with Revocability and Dual-Policy;S Xu, Y Zhang, Y Li, X Liu, G Yang ; … Conference on Security and Privacy in …, 2019  Springer;;"… available. Otherwise, it first runs the key generation oracle and key update oracle

to obtain the secret key \(sk_{id}\) and the key update \(ku_t\). \(mathcal {A}\) is

allowed to issue above oracles with the following restrictions: 1 …";Cité 1 fois;G Yang;[PDF] smu.edu.sg;https://ink.library.smu.edu.sg/cgi/viewcontent.cgi?article=6193&context=sis_research;;"""X-UA-Compatible"",""IE=edge,chrome=1""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""viewport"",""initial-scale=1.0""
""Content-Encoding"",""ISO-8859-1""
""resourceName"",""viewcontent.cgi""
""language"",""ca""
""Content-Length"",""817""
""ROBOTS"",""NOINDEX, NOFOLLOW""
""Content-Type"",""text/html; charset=ISO-8859-1""
""format-detection"",""telephone=no""
";https://scholar.google.com/scholar?start=730&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094532-617;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Enabling the Sharing Economy: What can Blockchain contribute to online Home-sharing platforms?;H Amarouche ;2019 theseus.fi;;"Enabling The Sharing Economy: What can Blockchain contribute to the online … Identification number:

Author: Hamza Amarouche Title: Enabling The Sharing Economy: What can Blockchain contribute

to the online Home-sharing platforms? Supervisor (Arcada): Dr. Mats Nylund …";Les 2 versions;Version HTML;[PDF] theseus.fi;https://www.theseus.fi/bitstream/handle/10024/261259/Amarouche_Hamza.pdf?sequence=2&isAllowed=y;;"""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.5""
""xmp:CreatorTool"",""Writer""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dc:creator"",""Anjum""
""language"",""en""
""dcterms:created"",""2019-10-17T13:55:39Z""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""Writer""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""Content-Length"",""599537""
""pdf:hasMarkedContent"",""false""
""Content-Type"",""application/pdf""
""pdf:docinfo:creator"",""Anjum""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Anjum""
""dc:language"",""fi-FI""
""meta:author"",""Anjum""
""meta:creation-date"",""2019-10-17T13:55:39Z""
""created"",""2019-10-17T13:55:39Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""53""
""Creation-Date"",""2019-10-17T13:55:39Z""
""resourceName"",""Amarouche_Hamza.pdf""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""213"",""1716"",""2367"",""2413"",""1691"",""1656"",""1201"",""1786"",""1130"",""1431"",""888"",""1716"",""1347"",""2075"",""1758"",""1765"",""1913"",""1837"",""2006"",""1803"",""1731"",""1781"",""1007"",""1647"",""1986"",""1901"",""1774"",""1795"",""512"",""1652"",""1000"",""1942"",""2013"",""1064"",""1756"",""1890"",""1872"",""2037"",""2034"",""2001"",""2123"",""1628"",""1714"",""1849"",""2082"",""2078"",""1850"",""550"",""1663"",""1430"",""982"",""737"",""198""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""Author"",""Anjum""
""producer"",""LibreOffice 6.2""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""LibreOffice 6.2""
""pdf:docinfo:created"",""2019-10-17T13:55:39Z""
";
1619094628-1022;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Design of a lightweight and anonymous authenticated key agreement protocol for wireless body area networks;A Ostad?Sharif, M Nikooghadam… ; International Journal …, 2019  Wiley Online Library;;"… is presented completely in Section 5. The security analysis of the proposed protocol using the

AVISPA tool and random oracle model is … Afterwards, Igbal et al20 suggested a lightweight smart

crypto solution by authenticated key exchange coupled with cluster head development …";Cité 15 fois;;[PDF] wiley.com;https://onlinelibrary.wiley.com/doi/pdf/10.1002/dac.3974?casa_token=vlyoVGaDIncAAAAA:mrXfWBkUTDJQlnzh6NKqZQJVTlqSHwyUCgHN7sRRbRBfHajVxoaNJ_rogORN8UAkD-M6yScHJX5gfw;;;https://scholar.google.com/scholar?start=840&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094586-846;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[PDF][PDF] A STUDY ON THE LIMITATIONS OF BLOCKCHAIN AND THE USAGE OF CONSENSUS MODELS IN BLOCKCHAIN TECHNOLOGY;S KIRAN, P NIRANJAN, P SHIREESHA ; academia.edu;;"… Community copes with Crypto Currency, afterward a scenario could happen where a few Crypto

Currency Might … Consequence, jobs like'Mineable Oracle Agreement' [3] Have Lately appeared

to Allow oracle intake in a Manner That's motivated by blockchain technology and …";Autres articles;Version HTML;[PDF] academia.edu;https://www.academia.edu/download/59324146/11.A_STUDY_ON_THE_LIMITATIONS_OF_BLOCKCHAIN20190520-51772-teumn5.pdf;;;https://scholar.google.com/scholar?start=660&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094614-966;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Scalable zero knowledge with no trusted setup;E Ben;Sasson, I Bentov, Y Horesh…  Annual international …, 2019  Springer;;"… way, facilitating exponential savings in verification time and space (like compressing Bitcoin's

blockchain to a … messages are public random coins), and the prover replies with an oracle, a long …

random locations and need not read in entirety (jumping ahead, these oracles will be …";Cité 62 fois;;null;;;;https://scholar.google.com/scholar?start=780&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094569-778;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[PDF][PDF] Secure Randomness on the Blockchain;K Chatterjee, A Goharshady, IST Austria ; pdfs.semanticscholar.org;;"… Openness: Drawing should be open to everyone. Let's do it on the blockchain! Page 11. The

Lottery Story … Relying on block hash/timestamp (Ed is the miner) • Using an oracle (Ed is the oracle

owner) • Using commitment schemes (No incentivization for random inputs) …";Les 2 versions;Version HTML;[PDF] semanticscholar.org;https://pdfs.semanticscholar.org/7a8b/78c566a1d703dd8cf0c947ca36ca0c3e15f6.pdf;;"""date"",""2019-05-16T23:39:07Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""MicrosoftÂŽ PowerPointÂŽ 2016""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dc:creator"",""Amir""
""language"",""en""
""dcterms:created"",""2019-05-16T23:39:07Z""
""Last-Modified"",""2019-05-16T23:39:07Z""
""dcterms:modified"",""2019-05-16T23:39:07Z""
""dc:format"",""application/pdf; version=1.5""
""title"",""""
""Last-Save-Date"",""2019-05-16T23:39:07Z""
""pdf:docinfo:creator_tool"",""MicrosoftÂŽ PowerPointÂŽ 2016""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2019-05-16T23:39:07Z""
""meta:save-date"",""2019-05-16T23:39:07Z""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2019-05-16T23:39:07Z""
""Content-Length"",""489240""
""pdf:hasMarkedContent"",""true""
""Content-Type"",""application/pdf""
""pdf:docinfo:creator"",""Amir""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Amir""
""dc:language"",""en-US""
""meta:author"",""Amir""
""meta:creation-date"",""2019-05-16T23:39:07Z""
""created"",""2019-05-16T23:39:07Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""18""
""Creation-Date"",""2019-05-16T23:39:07Z""
""resourceName"",""78c566a1d703dd8cf0c947ca36ca0c3e15f6.pdf""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""175"",""351"",""282"",""219"",""236"",""290"",""244"",""302"",""194"",""201"",""238"",""338"",""362"",""437"",""157"",""239"",""516"",""285""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""Author"",""Amir""
""producer"",""MicrosoftÂŽ PowerPointÂŽ 2016""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""MicrosoftÂŽ PowerPointÂŽ 2016""
""pdf:docinfo:created"",""2019-05-16T23:39:07Z""
";https://scholar.google.com/scholar?start=590&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094609-950;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;4-round Luby-Rackoff construction is a qPRP;A Hosoyamada, T Iwata ; International Conference on the Theory and …, 2019  Springer;;"… 4). No proofs (Insecure). Distinguishing attack. \(O(2^{n/4})\) queries [28]. \(O(2^{n/4})\) queries

[28]. \(O(2^{n/6})\) queries [Ours] (Sect. 5). O(n) queries [17]. Zhandry's compressed oracle

technique enables us to overcome the obstacle when oracles are truly random functions …";Cité 16 fois;Les 2 versions;null;;;;https://scholar.google.com/scholar?start=760&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094614-967;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[PDF][PDF] Confidential Assets on MimbleWimble;Z Yi, H Ye, P Dai, S Tongcheng, V Gelfer ; rin  docs.beam.mw;;"… arbitrary bit string to a point on an elliptic curve but also are indifferentiable from random oracles …

someone deliberately chooses a mes- sage difficult to hash and sends it to the blockchain, plenty

of … We use an extension of [11] as a random oracle for users to generate asset tags …";Autres articles;Version HTML;[PDF] beam.mw;https://docs.beam.mw/1435.pdf;;"""date"",""2019-12-10T03:43:01Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2019-12-10T03:43:01Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.20 (TeX Live 2019) kpathsea version 6.3.1""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2019-12-10T03:43:01Z""
""created"",""2019-12-10T03:43:01Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-12-10T03:43:01Z""
""resourceName"",""1435.pdf""
""Author"",""""
""producer"",""pdfTeX-1.40.20""
""pdf:docinfo:producer"",""pdfTeX-1.40.20""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""16"",""2"",""28"",""2"",""5"",""4"",""2"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2019-12-10T03:43:01Z""
""Last-Modified"",""2019-12-10T03:43:01Z""
""dcterms:modified"",""2019-12-10T03:43:01Z""
""title"",""""
""Last-Save-Date"",""2019-12-10T03:43:01Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2019-12-10T03:43:01Z""
""meta:save-date"",""2019-12-10T03:43:01Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.20 (TeX Live 2019) kpathsea version 6.3.1""
""Content-Length"",""220628""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""9""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""1936"",""1373"",""1591"",""1449"",""2083"",""1182"",""2147"",""1879"",""608""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-12-10T03:43:01Z""
";https://scholar.google.com/scholar?start=780&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094583-832;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;On ELFs, deterministic encryption, and correlated-input security;M Zhandry ; Annual International Conference on the Theory and …, 2019  Springer;;"… pseudorandomness, correlation intractability, extractability, and more. Unfortunately,

random oracles do not exist in the real world, and some random oracle properties are

uninstantiable by concrete hash functions [11]. This has lead to a …";Cité 1 fois;Les 5 versions;[PDF] princeton.edu;https://www.cs.princeton.edu/~mzhandry/docs/papers/CorInputs.pdf;;"""date"",""2019-02-23T19:10:11Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2019-02-23T19:10:11Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.16 (TeX Live 2015) kpathsea version 6.2.1""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2019-02-23T19:10:11Z""
""created"",""2019-02-23T19:10:11Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-02-23T19:10:11Z""
""resourceName"",""CorInputs.pdf""
""Author"",""""
""producer"",""pdfTeX-1.40.16""
""pdf:docinfo:producer"",""pdfTeX-1.40.16""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""2"",""0"",""0"",""0"",""3"",""2"",""0"",""0"",""11"",""4"",""12"",""16"",""38"",""62"",""0"",""0"",""6"",""7"",""6"",""11"",""28"",""20"",""14"",""5"",""14"",""3"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2019-02-23T19:10:11Z""
""Last-Modified"",""2019-02-23T19:10:11Z""
""dcterms:modified"",""2019-02-23T19:10:11Z""
""title"",""""
""Last-Save-Date"",""2019-02-23T19:10:11Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2019-02-23T19:10:11Z""
""meta:save-date"",""2019-02-23T19:10:11Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.16 (TeX Live 2015) kpathsea version 6.2.1""
""Content-Length"",""645477""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""29""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""1987"",""2590"",""2513"",""2735"",""2622"",""2532"",""2645"",""2539"",""2768"",""2690"",""1844"",""2134"",""1852"",""1445"",""2218"",""2003"",""1739"",""2078"",""2059"",""2075"",""2415"",""1806"",""2326"",""2234"",""2227"",""1761"",""2444"",""2377"",""2682""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-02-23T19:10:11Z""
";https://scholar.google.com/scholar?start=650&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094569-771;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;The local forking lemma and its application to deterministic encryption;M Bellare, W Dai, L Li ; International Conference on the Theory and …, 2019  Springer;;"… Instead we are able to re-program the random oracle at just one point in the rewinding and argue

that the two executions both result in correct guesses by the … There is a great deal of work on

D-PKE including many schemes without random oracles [6, 13, 14, 19, 20, 27, 30] …";Cité 1 fois;Les 3 versions;[PDF] nsf.gov;https://par.nsf.gov/servlets/purl/10200007;;"""date"",""2020-10-31T20:58:51Z""
""pdf:PDFVersion"",""1.4""
""xmp:CreatorTool"",""LaTeX with hyperref""
""pdf:docinfo:title"",""""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""pdfa:PDFVersion"",""A-1b""
""language"",""en""
""dc:format"",""application/pdf; version=""""A-1b"""""",""application/pdf; version=1.4""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""xmp:CreateDate"",""2020-10-31T13:58:51Z""
""modified"",""2020-10-31T20:58:51Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""xmp:ModifyDate"",""2020-10-31T13:58:51Z""
""pdf:docinfo:creator"",""Mihir Bellare and Wei Dai and Lucy Li""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.21 (TeX Live 2020) kpathsea version 6.3.2""
""meta:author"",""Mihir Bellare and Wei Dai and Lucy Li""
""trapped"",""False""
""meta:creation-date"",""2020-10-31T20:58:51Z""
""created"",""2020-10-31T20:58:51Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-10-31T20:58:51Z""
""resourceName"",""10200007""
""pdfaid:part"",""1""
""Author"",""Mihir Bellare and Wei Dai and Lucy Li""
""producer"",""pdfTeX-1.40.21""
""pdf:docinfo:producer"",""pdfTeX-1.40.21""
""pdf:unmappedUnicodeCharsPerPage"",""1"",""0"",""3"",""0"",""0"",""12"",""9"",""8"",""16"",""15"",""14"",""12"",""0"",""22"",""0"",""9"",""83"",""73"",""54"",""7"",""5"",""0"",""7"",""11"",""6"",""2"",""6"",""6"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""Mihir Bellare and Wei Dai and Lucy Li""
""dcterms:created"",""2020-10-31T20:58:51Z""
""Last-Modified"",""2020-10-31T20:58:51Z""
""dcterms:modified"",""2020-10-31T20:58:51Z""
""title"",""""
""Last-Save-Date"",""2020-10-31T20:58:51Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2020-10-31T20:58:51Z""
""meta:save-date"",""2020-10-31T20:58:51Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.21 (TeX Live 2020) kpathsea version 6.3.2""
""Content-Length"",""656096""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Mihir Bellare and Wei Dai and Lucy Li""
""pdfaid:conformance"",""B""
""pdf:producer"",""pdfTeX-1.40.21""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""30""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""2181"",""2815"",""2773"",""2662"",""2562"",""2455"",""1827"",""1495"",""1957"",""1737"",""1868"",""2094"",""2151"",""1570"",""2491"",""1775"",""1704"",""1780"",""1952"",""1723"",""2119"",""1218"",""1316"",""2031"",""1456"",""2154"",""1698"",""1662"",""3014"",""2204""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-10-31T20:58:51Z""
";https://scholar.google.com/scholar?start=590&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094663-1173;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;????????????????? ????????? ?? ??????????????? ????? ???????? ??????????? ??????? ? ?????????? ??????? …;?? ????????, ?? ????????? ; ?????????? ?????????????? ????????? …, 2019  elibrary.ru;;"… ??????????, ???????? ??? ?????? ???????????????? ???, ? ????? ???????, ??? Big-data

(???????), Blockchain (????????), Smartcontract … ????????? ?? ??????????? ???? ????????:

1) SAS Institute (???); 2) DeticaNetReveal (??????); 3) Oracle Corporation (???) …";Autres articles;;null;;;;https://scholar.google.com/scholar?start=990&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094590-863;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[CITATION][C] The Rainbow Network: An Off-Chain Decentralized Synthetics Exchange;D Robinson ;2019;;null;Autres articles;;null;;;;https://scholar.google.com/scholar?start=680&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094572-783;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;An association ring signature for block chain e-money transactions;K Yang, M Hu, Z Jia, B Gong, X Zhang ; Wuhan University Journal of …, 2019  Springer;;"… This method has strong anonymity and can be applied to blockchain scenes … It is therefore

traceable. Finally, the adaptive selection message of the scheme and the unforgeability under

the selection of public key attack are proved under the random oracle model …";Cité 2 fois;;[PDF] springer.com;https://idp.springer.com/authorize/casa?redirect_uri=https://link.springer.com/content/pdf/10.1007/s11859-019-1382-x.pdf&casa_token=aMFwLEX2y7YAAAAA:DPpmWZW67cMST0IrLeMfVmE7z9X95eg_ZAz1_m4CqRtGhkvdDwlgcDYp0D5QONmv9Z6Ezzp-QUKkYSI;;;https://scholar.google.com/scholar?start=600&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094583-839;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Delegatable order-revealing encryption;Y Li, H Wang, Y Zhao ; Proceedings of the 2019 ACM Asia Conference …, 2019  dl.acm.org;;"… the generic bilinear group model, where all the group and pairing operations are accomplished

as oracles to the … ID2, ??20, ??21), (ID3, ??30, ??31), (ID4, ??40, ??41) (ID5, ??50, ??51)} to the encoding

oracle, obtains ????ID4 … Let ?? : {0, 1}* ? G1 be a crypto- graphic hash function …";Cité 5 fois;;[PDF] acm.org;https://dl.acm.org/doi/pdf/10.1145/3321705.3329829?casa_token=3OlnIGGQU5gAAAAA:FO0KWviYz5N0puuKVNZ79f6NxrCXm7djEU4u3xaBsSouz7Le7YjvAt-YQ9JsudTWfoIngy8TL8w;;;https://scholar.google.com/scholar?start=650&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094569-773;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;On the Real-World Instantiability of Admissible Hash Functions and Efficient Verifiable Random Functions;T Jager, D Niehues ; International Conference on Selected Areas in …, 2019  Springer;;"… For instance, the Algorand blockchain uses a VRF to randomly select a committee for a … Partitioning

is often used in the random oracle model [5], where an idealized cryptographic hash … tool to enable

partitioning proofs in the standard model, that is, without random oracles …";Cité 3 fois;Les 3 versions;[PDF] iacr.org;https://eprint.iacr.org/2019/1335.pdf;;"""date"",""2019-11-20T10:31:29Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2019-11-20T10:31:29Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.20 (TeX Live 2019/Arch Linux) kpathsea version 6.3.1""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2019-11-20T10:31:29Z""
""created"",""2019-11-20T10:31:29Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-11-20T10:31:29Z""
""resourceName"",""1335.pdf""
""Author"",""""
""producer"",""pdfTeX-1.40.20""
""pdf:docinfo:producer"",""pdfTeX-1.40.20""
""pdf:unmappedUnicodeCharsPerPage"",""6"",""0"",""0"",""0"",""0"",""12"",""11"",""16"",""5"",""0"",""13"",""5"",""45"",""25"",""3"",""4"",""5"",""6"",""17"",""15"",""6"",""8"",""7"",""38"",""12"",""25"",""9"",""3"",""2"",""0"",""0"",""0"",""3"",""2"",""2"",""1""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2019-11-20T10:31:29Z""
""Last-Modified"",""2019-11-20T10:31:29Z""
""dcterms:modified"",""2019-11-20T10:31:29Z""
""title"",""""
""Last-Save-Date"",""2019-11-20T10:31:29Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2019-11-20T10:31:29Z""
""meta:save-date"",""2019-11-20T10:31:29Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.20 (TeX Live 2019/Arch Linux) kpathsea version 6.3.1""
""Content-Length"",""546699""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""36""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""2122"",""2456"",""2768"",""2583"",""2645"",""1723"",""2094"",""1652"",""1903"",""2351"",""2106"",""2146"",""1798"",""1793"",""1771"",""1864"",""1753"",""2013"",""2016"",""1027"",""1536"",""2077"",""1346"",""1905"",""1733"",""1842"",""2558"",""2636"",""2149"",""2907"",""2958"",""2708"",""1401"",""2149"",""2168"",""1093""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-11-20T10:31:29Z""
";https://scholar.google.com/scholar?start=590&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094586-844;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Token economics framework;L Tan ; Available at SSRN 3381452, 2019  papers.ssrn.com;;"… 2. Community information (Automated mechanism) (a) Oracles to aggregate the flow of information

and data within the token ecosystem (Eg Etherisc, TLSNotary, VeChain, Weeve, Ora- clize, Airbie,

Blockchain Nervous System in Difinity, Ultimate Oracle in Gnosis) …";Cité 5 fois;;null;;;;https://scholar.google.com/scholar?start=660&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094600-905;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;The Digital Transformation of FinTech: Disruptions and Value Paths.;M El;Masri, K AlYafi, KS Sherif  PACIS, 2019  aisel.aisnet.org;;"… Applications: The degree at which end-user applications, such as digital wallets, smart contracts,

and third-party services (ie oracles) are secure … Furthermore, some features that participated in

the success of blockchain technology for cryptocurrency services may …";Cité 2 fois;Les 2 versions;null;;;;https://scholar.google.com/scholar?start=720&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094654-1134;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[PDF][PDF] Analysis of the Tangle in the IoT Domain;S Bachmann ; files.ifi.uzh.ch;;"… The cryptocurrency IOTA tries to address these issues with a directed acyclic

architecture … Sybil Attack A single oracle could impersonate multiple oracles at

the same time in order to receive a larger cut of the reward …";Autres articles;Version HTML;[PDF] uzh.ch;https://files.ifi.uzh.ch/CSG/staff/Rafati/Simon_MBM_IOTA.pdf;;"""date"",""2019-07-01T10:31:12Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.5""
""xmp:CreatorTool"",""TeX""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dcterms:created"",""2019-07-01T10:31:12Z""
""language"",""en""
""Last-Modified"",""2019-07-01T10:31:12Z""
""dcterms:modified"",""2019-07-01T10:31:12Z""
""dc:format"",""application/pdf; version=1.5""
""Last-Save-Date"",""2019-07-01T10:31:12Z""
""pdf:docinfo:creator_tool"",""TeX""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2019-07-01T10:31:12Z""
""meta:save-date"",""2019-07-01T10:31:12Z""
""pdf:encrypted"",""false""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.19 (TeX Live 2018) kpathsea version 6.3.0""
""modified"",""2019-07-01T10:31:12Z""
""Content-Length"",""1105218""
""pdf:hasMarkedContent"",""false""
""Content-Type"",""application/pdf""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.19 (TeX Live 2018) kpathsea version 6.3.0""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""trapped"",""False""
""meta:creation-date"",""2019-07-01T10:31:12Z""
""created"",""2019-07-01T10:31:12Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""43""
""Creation-Date"",""2019-07-01T10:31:12Z""
""resourceName"",""Simon_MBM_IOTA.pdf""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""292"",""160"",""1521"",""2"",""738"",""706"",""1540"",""1057"",""1258"",""1843"",""1348"",""2309"",""1120"",""1688"",""1987"",""1508"",""836"",""20"",""981"",""2899"",""2343"",""26"",""1235"",""1950"",""1862"",""554"",""1432"",""2403"",""839"",""32"",""1646"",""2065"",""189"",""14"",""351"",""14"",""285"",""10"",""560"",""15"",""14"",""14"",""98""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""producer"",""pdfTeX-1.40.19""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""pdfTeX-1.40.19""
""pdf:docinfo:created"",""2019-07-01T10:31:12Z""
";https://scholar.google.com/scholar?start=950&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094544-662;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Big data and blockchain;H Hassani, X Huang, ES Silva ; … big data, blockchain and cryptocurrency, 2019  Springer;;"… Oracle Blockchain Cloud Service … latency has severely limited the amount of transaction, users,

as well as extended applications on the open-source Blockchain. As is evident by the story of

the extremely popular Crypto Kitties game on Ethereum, its huge success resulted in …";Cité 2 fois;;null;;;;https://scholar.google.com/scholar?start=480&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094605-928;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;????? ????? ????????????? ????????????? ????????????:Ť??????? ????????ť;N Ismailova ; ????? ??????? ????????????, 2019  tsue.scienceweb.uz;;"… of Ťblockchainť, tract terminology for this phenomenon different author and island, analyzers

and modern aspects of various Oracle technology through the Ťblockchainť … Keywords:

Ťblockchainť, Ťbitcoinť, Ťcryptocurrencyť, digital registry, startup, globalization …";Cité 3 fois;;[PDF] scienceweb.uz;https://tsue.scienceweb.uz/index.php/archive/article/download/431/272;;"""date"",""2019-12-26T11:26:53Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.7""
""xmp:CreatorTool"",""MicrosoftÂŽ Word 2019""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dc:creator"",""Мамсик ПК""
""language"",""ru""
""dcterms:created"",""2019-12-26T11:26:53Z""
""Last-Modified"",""2019-12-26T11:26:53Z""
""dcterms:modified"",""2019-12-26T11:26:53Z""
""dc:format"",""application/pdf; version=1.7""
""xmpMM:DocumentID"",""uuid:30D87436-2784-4581-90E6-2DF8B243427B""
""Last-Save-Date"",""2019-12-26T11:26:53Z""
""pdf:docinfo:creator_tool"",""MicrosoftÂŽ Word 2019""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2019-12-26T11:26:53Z""
""meta:save-date"",""2019-12-26T11:26:53Z""
""pdf:encrypted"",""false""
""xmp:CreateDate"",""2019-12-26T16:26:53Z""
""modified"",""2019-12-26T11:26:53Z""
""Content-Length"",""263299""
""pdf:hasMarkedContent"",""true""
""Content-Type"",""application/pdf""
""xmp:ModifyDate"",""2019-12-26T16:26:53Z""
""pdf:docinfo:creator"",""Мамсик ПК""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Мамсик ПК""
""dc:language"",""ru-RU""
""meta:author"",""Мамсик ПК""
""pdf:producer"",""MicrosoftÂŽ Word 2019""
""meta:creation-date"",""2019-12-26T11:26:53Z""
""created"",""2019-12-26T11:26:53Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""15""
""Creation-Date"",""2019-12-26T11:26:53Z""
""resourceName"",""272""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""1719"",""2000"",""1810"",""1865"",""1936"",""2626"",""1980"",""1970"",""1888"",""1892"",""1958"",""1985"",""1907"",""2344"",""889""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""Author"",""Мамсик ПК""
""producer"",""MicrosoftÂŽ Word 2019""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""MicrosoftÂŽ Word 2019""
""pdf:docinfo:created"",""2019-12-26T11:26:53Z""
";https://scholar.google.com/scholar?start=740&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094537-636;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Immutable Storage of EV Charge Records Using Blockchain Technology;A Gautam ;2019 theseus.fi;;"… immutable ledger. The developer must pay 'Ether', a type of cryptocurrency, to … be stored.

BigchainDB can be connected with other blockchain platforms which run smart contracts like

HLF via oracles or inter-chain communication protocols. [14.] Page 19. 13 …";Autres articles;Version HTML;[PDF] theseus.fi;https://www.theseus.fi/bitstream/handle/10024/172679/AmritGautam_BachelorThesis_SoftwareEngineering_FINAL.pdf?sequence=2;;"""date"",""2019-06-02T18:52:05Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.7""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""language"",""en""
""dcterms:created"",""2019-06-02T18:52:05Z""
""Last-Modified"",""2019-06-02T18:52:05Z""
""dcterms:modified"",""2019-06-02T18:52:05Z""
""dc:format"",""application/pdf; version=1.7""
""xmpMM:DocumentID"",""uuid:53A4E5AF-DD19-4E5F-B59D-481A695D291C""
""Last-Save-Date"",""2019-06-02T18:52:05Z""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2019-06-02T18:52:05Z""
""meta:save-date"",""2019-06-02T18:52:05Z""
""pdf:encrypted"",""false""
""xmp:CreateDate"",""2019-06-02T18:52:05Z""
""modified"",""2019-06-02T18:52:05Z""
""Content-Length"",""1967605""
""pdf:hasMarkedContent"",""true""
""Content-Type"",""application/pdf""
""xmp:ModifyDate"",""2019-06-02T18:52:05Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""dc:language"",""en-US""
""meta:creation-date"",""2019-06-02T18:52:05Z""
""created"",""2019-06-02T18:52:05Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""44""
""Creation-Date"",""2019-06-02T18:52:05Z""
""resourceName"",""AmritGautam_BachelorThesis_SoftwareEngineering_FINAL.pdf""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""204"",""2410"",""910"",""283"",""618"",""383"",""2563"",""865"",""1091"",""2005"",""1283"",""1618"",""1824"",""987"",""593"",""1795"",""2257"",""2189"",""2541"",""2332"",""1862"",""660"",""2161"",""2330"",""1819"",""1160"",""1048"",""707"",""908"",""964"",""2508"",""1032"",""1299"",""1881"",""1906"",""428"",""881"",""2332"",""1901"",""1865"",""829"",""2086"",""2160"",""758""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-06-02T18:52:05Z""
";https://scholar.google.com/scholar?start=450&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094581-830;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[PDF][PDF] SCHEME OF INSTRUCTION AND SYLLABI Effective from academic year 2019-20;M Tech ; nitw.ac.in;;"… 2. M. Gertz, S. Jajodia, Handbook of Database Security, Springer, 2008 3. Ben-Natan, RB,

Implementing Database Security and Auditing: Includes Examples for Oracle, SQL Server, Db2

Udb, Sybase, Digital Press, 2005 4. Mike Shema, Hacking … http://crypto.stanford.edu/pbc …";Autres articles;Version HTML;[PDF] nitw.ac.in;https://www.nitw.ac.in/media/uploads/2019/09/05/mtech-csis.pdf;;"""date"",""2019-09-05T11:54:11Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.5""
""xmp:CreatorTool"",""MicrosoftÂŽ Office Word 2007""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dc:creator"",""Hitesh Verma""
""language"",""en""
""dcterms:created"",""2019-09-05T11:54:11Z""
""Last-Modified"",""2019-09-05T11:54:11Z""
""dcterms:modified"",""2019-09-05T11:54:11Z""
""dc:format"",""application/pdf; version=1.5""
""Last-Save-Date"",""2019-09-05T11:54:11Z""
""pdf:docinfo:creator_tool"",""MicrosoftÂŽ Office Word 2007""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2019-09-05T11:54:11Z""
""meta:save-date"",""2019-09-05T11:54:11Z""
""pdf:encrypted"",""false""
""modified"",""2019-09-05T11:54:11Z""
""Content-Length"",""1160832""
""pdf:hasMarkedContent"",""true""
""Content-Type"",""application/pdf""
""pdf:docinfo:creator"",""Hitesh Verma""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Hitesh Verma""
""dc:language"",""en-US""
""meta:author"",""Hitesh Verma""
""meta:creation-date"",""2019-09-05T11:54:11Z""
""created"",""2019-09-05T11:54:11Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""62""
""Creation-Date"",""2019-09-05T11:54:11Z""
""resourceName"",""mtech-csis.pdf""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""238"",""1269"",""1131"",""1396"",""942"",""337"",""626"",""1119"",""2140"",""2641"",""1878"",""1842"",""1849"",""665"",""1977"",""2136"",""1606"",""1445"",""1631"",""2090"",""1691"",""1628"",""1883"",""1743"",""1810"",""2372"",""114"",""2529"",""2140"",""2221"",""2294"",""3106"",""1970"",""2536"",""4"",""1794"",""2253"",""3803"",""934"",""686"",""1405"",""2155"",""2903"",""1806"",""1096"",""3768"",""1052"",""1884"",""4"",""1616"",""1402"",""2008"",""2221"",""2429"",""2590"",""2308"",""1704"",""2654"",""645"",""2146"",""2726"",""108""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""Author"",""Hitesh Verma""
""producer"",""MicrosoftÂŽ Office Word 2007""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""MicrosoftÂŽ Office Word 2007""
""pdf:docinfo:created"",""2019-09-05T11:54:11Z""
";https://scholar.google.com/scholar?start=640&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094567-761;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[PDF][PDF] Blockchains' twilight zones.;P Limata ; econometica.it;;"… alt signifying 'alternative' and coin signifying (in essence) 'cryptocurrency.' Altcoins are … using a

distributed, cryptographically secure, and crypto-economically incentivized consensus engine

(Da … A decade later, the blockchain technology has moved beyond cryptocurrencies, but …";Autres articles;;[PDF] econometica.it;http://www.econometica.it/wp/wp76.pdf;;"""date"",""2019-11-26T15:07:35Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""11"",""45"",""47"",""85"",""12"",""15"",""70"",""58"",""88"",""66"",""57"",""31"",""77"",""27"",""70"",""22"",""48"",""8"",""64"",""75"",""69"",""102"",""20"",""87"",""30"",""48"",""110"",""100"",""127"",""50"",""57"",""45"",""29"",""7"",""0"",""7"",""1"",""12"",""28"",""0"",""0""
""pdf:PDFVersion"",""1.3""
""pdf:docinfo:title"",""wp76 16.06.37.pdf""
""xmp:CreatorTool"",""Anteprima""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dcterms:created"",""2019-11-26T15:07:35Z""
""language"",""en""
""Last-Modified"",""2019-11-26T15:07:35Z""
""dcterms:modified"",""2019-11-26T15:07:35Z""
""dc:format"",""application/pdf; version=1.3""
""title"",""wp76 16.06.37.pdf""
""Last-Save-Date"",""2019-11-26T15:07:35Z""
""pdf:docinfo:creator_tool"",""Anteprima""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2019-11-26T15:07:35Z""
""meta:save-date"",""2019-11-26T15:07:35Z""
""pdf:encrypted"",""false""
""dc:title"",""wp76 16.06.37.pdf""
""modified"",""2019-11-26T15:07:35Z""
""Content-Length"",""827508""
""pdf:hasMarkedContent"",""true""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""meta:creation-date"",""2019-11-26T15:07:35Z""
""created"",""2019-11-26T15:07:35Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""42""
""Creation-Date"",""2019-11-26T15:07:35Z""
""resourceName"",""wp76.pdf""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""111"",""2869"",""4225"",""3663"",""3941"",""3815"",""2416"",""3974"",""5153"",""3821"",""4071"",""3831"",""4265"",""4116"",""4509"",""4379"",""3635"",""4104"",""4268"",""4684"",""4221"",""4231"",""3953"",""4106"",""4213"",""3878"",""3753"",""3841"",""3922"",""4121"",""3820"",""4134"",""3669"",""3272"",""3195"",""3058"",""3183"",""3016"",""3013"",""3118"",""2750"",""1158""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""producer"",""macOS Versione 10.15.1 (Build 19B88) Quartz PDFContext""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""macOS Versione 10.15.1 (Build 19B88) Quartz PDFContext""
""pdf:docinfo:created"",""2019-11-26T15:07:35Z""
";https://scholar.google.com/scholar?start=580&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094651-1123;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Quantum chosen-ciphertext attacks against Feistel ciphers;G Ito, A Hosoyamada, R Matsumoto, Y Sasaki… ; Cryptographers' Track at …, 2019  Springer;;"… at CRYPTO 2016 … O}\), since we use only the lower n / 2 bits of the output of \({\mathcal O}\).

However, the oracle may return … To solve this problem, Hosoyamada and Sasaki showed how

to simulate truncation of outputs of the oracles without destroying quantum entanglements …";Cité 30 fois;Les 8 versions;[PDF] aliyuncs.com;https://osch.oss-cn-shanghai.aliyuncs.com/blogAttachment/1551750658086.pdf;;"""X-Parsed-By"",""org.apache.tika.parser.EmptyParser""
""resourceName"",""1551750658086.pdf""
""language"",""""
""Content-Length"",""1561586""
""Content-Type"",""application/octet-stream""
";https://scholar.google.com/scholar?start=940&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094562-744;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[HTML][HTML] Implementing a blockchain from scratch: why, how, and what we learned;F Knirsch, A Unterweger, D Engel ; EURASIP Journal on Information …, 2019  Springer;;"… therefore prevents malicious nodes from forging data or—in the case of crypto currencies—from …

Blockchain-based solutions to trade energy between households have been proposed … In [34,

35], a custom cryptocurrency for local energy trading is proposed which changes its …";Cité 35 fois;Les 7 versions;[HTML] springer.com;https://link.springer.com/article/10.1186/s13635-019-0085-3;;"""dc.publisher"",""SpringerOpen""
""og:image"",""https://media.springernature.com/w200/springer-static/cover/journal/13635.jpg""
""og:site_name"",""EURASIP Journal on Information Security""
""citation_reference"",""S. Nakamoto, Bitcoin: A Peer-to-Peer Electronic Cash System. Technical report (2008).                      https://bitcoin.org/bitcoin.pdf                                        ."",""citation_journal_title=IEEE Commun. Surv. Tutor.; citation_title=Bitcoin and beyond: a technical survey on decentralized digital currencies; citation_author=F. Tschorsch, B. Scheuermann; citation_volume=18; citation_issue=3; citation_publication_date=2016; citation_pages=2084-2123; citation_doi=10.1109/COMST.2016.2535718; citation_id=CR2"",""citation_journal_title=IEEE Access; citation_title=Blockchains and smart contracts for the Internet of Things; citation_author=K. Christidis, M. Devetsikiotis; citation_volume=4; citation_publication_date=2016; citation_pages=2292-2303; citation_doi=10.1109/ACCESS.2016.2566339; citation_id=CR3"",""citation_title=Privacy-Preserving Smart Grid Tariff Decisions with Blockchain-Based Smart Contracts; citation_inbook_title=Sustainable Cloud and Energy Services: Principles and Practices. Chap. 4; citation_publication_date=2017; citation_pages=85-116; citation_id=CR4; citation_author=F. Knirsch; citation_author=A. Unterweger; citation_author=G. Eibl; citation_author=D. Engel; citation_publisher=Springer"",""citation_journal_title=J. Comput. Sci. Res. Dev. (CSRD).; citation_title=Privacy-preserving blockchain-based electric vehicle charging with dynamic tariff decisions; citation_author=F. Knirsch, A. Unterweger, D. Engel; citation_volume=33; citation_issue=1; citation_publication_date=2018; citation_pages=71-79; citation_doi=10.1007/s00450-017-0348-5; citation_id=CR5"",""citation_title=Blockchains for decentralized optimization of energy resources in microgrid networks; citation_inbook_title=2017 IEEE Conference on Control Technology and Applications (CCTA); citation_publication_date=2017; citation_pages=2164-2171; citation_id=CR6; citation_author=E. Munsing; citation_author=J. Mather; citation_author=S. Moura; citation_publisher=IEEE"",""citation_journal_title=Comput. Sci. Res. Dev.; citation_title=A blockchain-based smart grid: towards sustainable local energy markets; citation_author=E. Mengelkamp, B. Notheisen, C. Beer, D. Dauer, C. Weinhardt; citation_volume=33; citation_issue=1; citation_publication_date=2018; citation_pages=207-214; citation_doi=10.1007/s00450-017-0360-9; citation_id=CR7"",""G. Greenspan, MultiChain Private Blockchain - White Paper. Technical report, Coin Sciences Ltd (2015).                      http://www.multichain.com/download/MultiChain-White-Paper.pdf                                        ."",""G. Wood, Ethereum: A Secure Decentralised Generalised Transaction Ledger. Technical report, Ethereum (2017). arXiv:1011.1669v3.                      https://ethereum.github.io/yellowpaper/paper.pdf                                        ."",""citation_title=On Scaling Decentralized Blockchains; citation_inbook_title=International Conference on Financial Cryptography and Data Security; citation_publication_date=2016; citation_pages=106-125; citation_id=CR10; citation_author=K. Croman; citation_author=C. Decker; citation_author=I. Eyal; citation_author=A. E. Gencer; citation_author=A. Juels; citation_author=A. Kosba; citation_author=A. Miller; citation_author=P. Saxena; citation_author=E. Shi; citation_author=E. Gün Sirer; citation_author=D. Song; citation_author=R. Wattenhofer; citation_publisher=Springer"",""citation_title=Majority Is Not Enough: Bitcoin Mining Is Vulnerable; citation_inbook_title=Financial Cryptography and Data Security, 18th International Conference, FC 2014, Christ Church, Barbados, March 3-7, 2014, Revised Selected Papers; citation_publication_date=2014; citation_pages=436-454; citation_id=CR11; citation_author=I. Eyal; citation_author=E. G. Sirer; citation_publisher=Springer"",""citation_title=CHAINIAC: Proactive Software-Update Transparency via Collectively Signed Skipchains and Verified Builds; citation_inbook_title=26th USENIX Security Symposium (USENIX Security 17); citation_publication_date=2017; citation_pages=1271-1287; citation_id=CR12; citation_author=K. Nikitin; citation_author=E. Kokoris-Kogias; citation_author=P. Jovanovic; citation_author=L. Gasser; citation_author=N. Gailly; citation_author=I. Khoffi; citation_author=J. Cappos; citation_author=B. Ford; citation_publisher=USENIX Association"",""citation_title=Zerocash: Decentralized Anonymous Payments from Bitcoin; citation_inbook_title=Proceedings – IEEE Symposium on Security and Privacy; citation_publication_date=2014; citation_pages=459-474; citation_id=CR13; citation_author=E. Ben-Sasson; citation_author=A. Chiesa; citation_author=C. Garman; citation_author=M. Green; citation_author=I. Miers; citation_author=E. Tromer; citation_author=M. Virza; citation_publisher=IEEE"",""citation_title=Lessons Learned from Implementing a Privacy-Preserving Smart Contract in Ethereum; citation_inbook_title=2018 9th IFIP International Conference on New Technologies, Mobility and Security (NTMS); citation_publication_date=2018; citation_id=CR14; citation_author=A. Unterweger; citation_author=F. Knirsch; citation_author=C. Leixnering; citation_author=D. Engel; citation_publisher=IEEE"",""citation_journal_title=ACM Trans. Program. Lang. Syst.; citation_title=The Byzantine Generals Problem; citation_author=L. Lamport, R. Shostak, M. Pease; citation_volume=4; citation_issue=3; citation_publication_date=1982; citation_pages=382-401; citation_doi=10.1145/357172.357176; citation_id=CR15"",""citation_title=Fast Asynchronous Byzantine Agreement with Optimal Resilience 1 Introduction; citation_inbook_title=Proceedings of the Twenty-fifth Annual ACM Symposium on Theory of Computing; citation_publication_date=1993; citation_pages=42-51; citation_id=CR16; citation_author=R. Canetti; citation_author=T. Rabin; citation_publisher=ACM"",""citation_title=The Quest for Scalable Blockchain Fabric: Proof-of-Work vs. BFT Replication; citation_inbook_title=Open Problems in Network Security; citation_publication_date=2016; citation_pages=112-125; citation_id=CR17; citation_author=M. Vukolić; citation_publisher=Springer"",""citation_title=Introduction to Modern Cryptography, 1st edn; citation_publication_date=2007; citation_id=CR18; citation_author=J. Katz; citation_author=Y. Lindell; citation_publisher=Chapman and Hall/CRC"",""I. Abraham, D. Malkhi, K. Nayak, L. Ren, A. Spiegelman, in The 21st International Conference on Principles of Distributed Systems. Solida: A Blockchain Protocol Based on Reconfigurable Byzantine Consensus (Lisbon, 2017), pp. 1–17. http://arxiv.org/abs/1612.02916. Accessed 24 Jan 2019."",""citation_journal_title=Energy Pol.; citation_title=Design of an economically efficient feed-in tariff structure for renewable energy development; citation_author=J. A. Lesser, X. Su; citation_volume=36; citation_issue=3; citation_publication_date=2008; citation_pages=981-990; citation_doi=10.1016/j.enpol.2007.11.007; citation_id=CR20"",""L. Krampe, M. Wünsch, Schlussbericht Mieterstrom – Rechtliche Einordnung, Organisationsformen, Potenziale und Wirtschaftlichkeit von Mieterstrommodellen (MSM). Technical report (2017).                      https: //www.bmwi.de/Redaktion/DE/Publikationen/Studien/schlussbericht-mieterstrom.pdf?__blob=publicationFile&v=10                                        ."",""citation_journal_title=Appl. Energy.; citation_title=Designing microgrid energy markets: A case study: The Brooklyn Microgrid; citation_author=E. Mengelkamp, J. Gärttner, K. Rock, S. Kessler, L. Orsini, C. Weinhardt; citation_volume=210; citation_publication_date=2018; citation_pages=870-880; citation_doi=10.1016/j.apenergy.2017.06.054; citation_id=CR22"",""Bundeskanzleramt, Kleine Ökostromnovelle –Erläuterungen (2017).                      https://www.ris.bka.gv.at/Dokumente/RegV/REGV_COO_2026_100_2_1346954/COO_2026_100_2_1347360.pdf                                        . Accessed 24 Jan 2019."",""Nationalrat, Änderung des Ökostromgesetzes 2012, des Elektrizitätswirtschafts- und -organisationsgesetzes 2010, des Gaswirtschaftsgesetzes 2011, des KWK-Punkte-Gesetzes und des Energie-Control-Gesetzes sowie Bundesgesetz, mit dem zusätzliche Mittel aus von der..BGBl. I Nr. 108/2017 (NR: GP XXV RV 1519 AB 1527 S. 190. BR: 9831 AB 9873 S. 870.) (2017).                      https://www.ris.bka.gv.at/eli/bgbl/I/2017/108                                        . Accessed 24 Jan 2019."",""citation_journal_title=Bundesgesetzblatt Teil I; citation_title=Gesetz zur Förderung von Mieterstrom und zur Änderung weiterer Vorschriften des Erneuerbare-Energien-Gesetzes; citation_author=; citation_volume=2017; citation_issue=49; citation_publication_date=2017; citation_pages=2532-2539; citation_id=CR25"",""Nationalrat, Bundesgesetz, mit dem die Organisation auf dem Gebiet der Elektrizitätswirtschaft neu geregelt wird (Elektrizitätswirtschafts- und -organisationsgesetz 2010 – ElWOG 2010). BGBl. I Nr. 110/2010 (NR: GP XXIV RV 994 AB 997 S. 86. BR: 8420 AB 8421 S. 791.) (2010).                      https://www.ris.bka.gv.at/eli/bgbl/I/2010/110                                        . Accessed 24 Jan 2019."",""Nationalrat, Bundesrecht konsolidiert: Gesamte Rechtsvorschrift für Elektrizitätswirtschafts- und -organisationsgesetz 2010, Fassung vom 14.02.2018 (2018).                      https://www.ris.bka.gv.at/GeltendeFassung.wxe?Abfrage=Bundesnormen&Gesetzesnummer=20007045                                        . Accessed 24 Jan 2019."",""citation_journal_title=Bundesgesetzblatt Teil I; citation_title=Gesetz zur grundlegenden Reform des Erneuerbare-Energien-Gesetzes und zur Änderung weiterer Bestimmungen des Energiewirtschaftsrechts; citation_author=; citation_volume=2014; citation_issue=33; citation_publication_date=2014; citation_pages=1066-1132; citation_id=CR28"",""Bundestag, Erneuerbare-Energien-Gesetz vom 21. Juli 2014 (BGBl. I S. 1066), das zuletzt durch Artikel 1 des Gesetzes vom 17. Juli 2017 (BGBl. I S. 2532) geändert worden ist (2017).                      https://www.gesetze-im-internet.de/eeg_2014/BJNR106610014.html                                        . Accessed 24 Jan 2019."",""K. Wüst, A. Gervais, Do you need a Blockchain.                      https://eprint.iacr.org/2017/375.pdf                                        ."",""European Parliament and Council of the European Union, Directive 2009/72/EC of the European Parliament and of the Council of 13 July 2009 concerning common rules for the internal market in electricity and repealing Directive 2003/54/EC (2009).                      http://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32009L0072                                        . Accessed 24 Jan 2019."",""M. Hearn, Corda: A distributed ledger, Version 0.5. Technical report. Corda. Accessed September 2018 (2016).                      https://www.corda.net/content/corda-technical-whitepaper.pdf                                        ."",""citation_journal_title=IEEE Trans. Dependable Secure Comput.; citation_title=Security and Privacy in Decentralized Energy Trading through Multi-signatures, Blockchain and Anonymous Messaging Streams; citation_author=; citation_volume=15; citation_issue=5; citation_publication_date=2016; citation_pages=840-852; citation_doi=10.1109/TDSC.2016.2616861; citation_id=CR33"",""citation_title=NRGcoin: Virtual currency for trading of renewable energy in smart grids; citation_inbook_title=11th International Conference on the European Energy Market, EEM; citation_publication_date=2014; citation_id=CR34; citation_author=M. Mihaylov; citation_author=S. Jurado; citation_author=N. Avellana; citation_author=K. Van Moffaert; citation_author=I. M. De Abril; citation_author=A. Nowé; citation_publisher=IEEE"",""citation_title=NRG-X-Change - A Novel Mechanism for Trading of Renewable Energy in Smart Grids; citation_inbook_title=Proceedings of the 3rd International Conference on Smart Grids and Green IT Systems; citation_publication_date=2014; citation_pages=101-106; citation_id=CR35; citation_author=M. Mihaylov; citation_author=S. Jurado; citation_author=K. V. Moffaert; citation_author=A. Now; citation_publisher=SciTePress"",""citation_journal_title=Appl. Energy.; citation_title=Blockchain technology in the chemical industry: Machine-to-machine electricity market; citation_author=J. J. Sikorski, J. Haughton, M. Kraft; citation_volume=195; citation_publication_date=2017; citation_pages=234-246; citation_doi=10.1016/j.apenergy.2017.03.039; citation_id=CR36"",""citation_title=An energy market for trading electricity in smart grid neighbourhoods; citation_inbook_title=IEEE International Conference on Digital Ecosystems and Technologies; citation_publication_date=2012; citation_pages=1-6; citation_id=CR37; citation_author=D. Ilic; citation_author=P. G. Da Silva; citation_author=S. Karnouskos; citation_author=M. Griesemer; citation_publisher=IEEE"",""citation_journal_title=IEEE Trans. Smart Grid; citation_title=A game-theoretic approach to energy trading in the smart grid; citation_author=Y. Wang, W. Saad, Z. Han, H. V. Poor, T. Başar; citation_volume=5; citation_issue=3; citation_publication_date=2014; citation_pages=1439-1450; citation_doi=10.1109/TSG.2013.2284664; citation_id=CR38"",""citation_title=Enhancing Bitcoin Security and Performance with Strong Consistency via Collective Signing; citation_inbook_title=25th USENIX Security Symposium (USENIX 2016); citation_publication_date=2016; citation_pages=279-296; citation_id=CR39; citation_author=E. Kokoris-Kogias; citation_author=P. Jovanovic; citation_author=N. Gailly; citation_author=I. Khoffi; citation_author=L. Gasser; citation_author=B. Ford; citation_publisher=USENIX Association"",""citation_title=Security and Trust in Cryptocurrencies; citation_inbook_title=Central European Conference In Finance And Economics; citation_publication_date=2015; citation_pages=14-24; citation_id=CR40; citation_author=J. Bucko; citation_author=D. Paľová; citation_author=M. Vejačka; citation_publisher=Technical University of Košice"",""A. Unterweger, F. Knirsch, C. Leixnering, D. Engel, Update: Lessons Learned from Implementing a Privacy-Preserving Smart Contract in Ethereum. Technical report, Center for Secure Energy Informatics, Salzburg University of Applied Sciences, Austria (nov 2017).                      http://www.en-trust.at/papers/Unterweger18a-t.pdf                                        ."",""F. Knirsch, A. Unterweger, K. Karlsson, D. Engel, S. B. Wicker, Evaluation of a Blockchain-based Proof-of-Possession Implementation. Technical report, Center for Secure Energy Informatics, Salzburg University of Applied Sciences, Austria (2018).                      http://www.en-trust.at/papers/Knirsch18a-t.pdf                                        ."",""citation_title=Evaluating Blockchains for IoT; citation_inbook_title=9th IFIP Conference on New Technologies, Mobility & Security (NTMS 2018); citation_publication_date=2018; citation_pages=0-4; citation_id=CR43; citation_author=R. Han; citation_author=V. Gramoli; citation_author=X. Xu; citation_publisher=IEEE/IFIP"",""citation_title=Hawk: The Blockchain Model of Cryptography and Privacy-Preserving Smart Contracts; citation_inbook_title=2016 IEEE Symposium on Security and Privacy (SP); citation_publication_date=2016; citation_pages=839-858; citation_id=CR44; citation_author=A. Kosba; citation_author=A. Miller; citation_author=E. Shi; citation_author=Z. Wen; citation_author=C. Papamanthou; citation_publisher=IEEE"",""D. Mazières, The Stellar Consensus Protocol: A Federated Model for Internet-level Consensus. Technical report, Stellar Development Foundation (2016).                      https://www.stellar.org/papers/stellar-consensus-protocol.pdf                                        ."",""E. Kokoris-Kogias, P. Jovanovic, L. Gasser, N. Gailly, E. Syta, B. Ford, OmniLedger: A Secure, Scale-Out, Decentralized Ledger via Sharding. IEEE Symp. Secur. Priv., 583–598 (2018)."",""citation_journal_title=IEEE Trans. Smart Grid; citation_title=Wavelet-Based Multiresolution Smart Meter Privacy; citation_author=D. Engel, G. Eibl; citation_volume=8; citation_issue=4; citation_publication_date=2017; citation_pages=1710-1721; citation_doi=10.1109/TSG.2015.2504395; citation_id=CR47"",""citation_journal_title=Datenschutz und Datensicherheit - DuD; citation_title=Das BSI-Schutzprofil: Anforderungen an den Datenschutz und die Datensicherheit für Smart Metering Systeme; citation_author=D. Laupichler, S. Vollmer, H. Bast, M. Intemann; citation_volume=35; citation_issue=8; citation_publication_date=2011; citation_pages=542-546; citation_doi=10.1007/s11623-011-0134-7; citation_id=CR48"",""citation_title=The Art of Multiprocessor Programming, rev. 1st edn; citation_publication_date=2012; citation_id=CR49; citation_author=M. Herlihy; citation_author=N. Shavit; citation_publisher=Morgan Kaufmann"",""E. Barker, W. Barker, W. Burr, W. Polk, M. Smid, C. S. Division, NIST 800-57: Computer Security. NIST (2012). National Institute of Standards & Technology.                      https://csrc.nist.gov/publications/detail/sp/800-57-part-1/revised/archive/2007-03-01                                        ."",""T. Dierks, E. Rescorla, The Transport Layer Security (TLS) Protocol Version 1.2. RFC 5246 (2008).                      https://tools.ietf.org/html/rfc5246                                        . Accessed 24 Jan 2019."",""C. Decker, R. Wattenhofer, Information propagation in the Bitcoin network Information Propagation in the Bitcoin Network (IEEE P2P 2013 Proceedings, Trento, 2013)."",""citation_title=Proofs of Work and Bread Pudding Protocols (Extended Abstract); citation_inbook_title=Secure Information Networks: Communications and Multimedia Security IFIP TC6/TC11 Joint Working Conference on Communications and Multimedia Security (CMS’99) September 20–21, 1999, Leuven, Belgium; citation_publication_date=1999; citation_pages=258-272; citation_id=CR53; citation_author=M. Jakobsson; citation_author=A. Juels; citation_publisher=Springer"",""citation_title=Bitcoin-NG: A Scalable Blockchain Protocol; citation_inbook_title=Proceedings of the 13th Usenix Conference on Networked Systems Design and Implementation. NSDI’16; citation_publication_date=2016; citation_pages=45-59; citation_id=CR54; citation_author=I. Eyal; citation_author=A. E. Gencer; citation_author=E. G. Sirer; citation_author=R. van Renesse; citation_publisher=USENIX Association"",""citation_title=On the Instability of Bitcoin Without the Block Reward; citation_inbook_title=Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security - CCS’16; citation_publication_date=2016; citation_pages=154-167; citation_id=CR55; citation_author=M. Carlsten; citation_author=H. Kalodner; citation_author=S. M. Weinberg; citation_author=A. Narayanan; citation_publisher=ACM""
""citation_journal_title"",""EURASIP Journal on Information Security""
""language"",""en""
""og:description"",""Blockchains are proposed for many application domains apart from financial transactions. While there are generic blockchains that can be molded for specific use cases, they often lack a lightweight and easy-to-customize implementation. In this paper, we introduce the core concepts of blockchain technology and investigate a real-world use case from the energy domain, where customers trade portions of their photovoltaic power plant via a blockchain. This does not only involve blockchain technology, but also requires user interaction. Therefore, a fully custom, private, and permissioned blockchain is implemented from scratch. We evaluate and motivate the need for blockchain technology within this use case, as well as the desired properties of the system. We then describe the implementation and the insights from our implementation in detail, serving as a guide for others and to show potential opportunities and pitfalls when implementing a blockchain from scratch.""
""prism.issn"",""2510-523X""
""prism.number"",""1""
""citation_issn"",""2510-523X""
""citation_language"",""en""
""dc:title"",""Implementing a blockchain from scratch: why, how, and what we learned | SpringerLink""
""Content-Encoding"",""UTF-8""
""citation_pdf_url"",""https://link.springer.com/track/pdf/10.1186/s13635-019-0085-3""
""citation_lastpage"",""14""
""DOI"",""10.1186/s13635-019-0085-3""
""citation_fulltext_world_readable"",""""
""citation_journal_abbrev"",""EURASIP J. on Info. Security""
""prism.rightsAgent"",""reprints@biomedcentral.com""
""citation_author"",""Fabian Knirsch"",""Andreas Unterweger"",""Dominik Engel""
""resourceName"",""s13635-019-0085-3""
""dc.date"",""2019-03-11""
""citation_issue"",""1""
""prism.volume"",""2019""
""prism.publicationName"",""EURASIP Journal on Information Security""
""citation_doi"",""10.1186/s13635-019-0085-3""
""dc.title"",""Implementing a blockchain from scratch: why, how, and what we learned""
""prism.url"",""https://link.springer.com/articles/10.1186/s13635-019-0085-3""
""citation_volume"",""2019""
""dc.language"",""En""
""Content-Language"",""en""
""citation_publication_date"",""2019/12""
""prism.endingPage"",""14""
""citation_title"",""Implementing a blockchain from scratch: why, how, and what we learned""
""citation_author_institution"",""Salzburg University of Applied Sciences, Center for Secure Energy Informatics, Puch bei Hallein, Austria"",""Salzburg University of Applied Sciences, Center for Secure Energy Informatics, Puch bei Hallein, Austria"",""Salzburg University of Applied Sciences, Center for Secure Energy Informatics, Puch bei Hallein, Austria""
""access"",""Yes""
""citation_publisher"",""SpringerOpen""
""applicable-device"",""pc,mobile""
""dc.format"",""text/html""
""description"",""Blockchains are proposed for many application domains apart from financial transactions. While there are generic blockchains that can be molded for specific use cases, they often lack a lightweight and easy-to-customize implementation. In this paper, we introduce the core concepts of blockchain technology and investigate a real-world use case from the energy domain, where customers trade portions of their photovoltaic power plant via a blockchain. This does not only involve blockchain technology, but also requires user interaction. Therefore, a fully custom, private, and permissioned blockchain is implemented from scratch. We evaluate and motivate the need for blockchain technology within this use case, as well as the desired properties of the system. We then describe the implementation and the insights from our implementation in detail, serving as a guide for others and to show potential opportunities and pitfalls when implementing a blockchain from scratch.""
""title"",""Implementing a blockchain from scratch: why, how, and what we learned | SpringerLink""
""citation_online_date"",""2019/03/11""
""dc.source"",""EURASIP Journal on Information Security 2019 2019:1""
""dc.type"",""OriginalPaper""
""dc.copyright"",""2019 The Author(s)""
""dc.creator"",""Fabian Knirsch"",""Andreas Unterweger"",""Dominik Engel""
""citation_fulltext_html_url"",""https://link.springer.com/articles/10.1186/s13635-019-0085-3""
""prism.publicationDate"",""2019-03-11""
""Content-Type"",""text/html; charset=UTF-8""
""journal_id"",""13635""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""dc.description"",""Blockchains are proposed for many application domains apart from financial transactions. While there are generic blockchains that can be molded for specific use cases, they often lack a lightweight and easy-to-customize implementation. In this paper, we introduce the core concepts of blockchain technology and investigate a real-world use case from the energy domain, where customers trade portions of their photovoltaic power plant via a blockchain. This does not only involve blockchain technology, but also requires user interaction. Therefore, a fully custom, private, and permissioned blockchain is implemented from scratch. We evaluate and motivate the need for blockchain technology within this use case, as well as the desired properties of the system. We then describe the implementation and the insights from our implementation in detail, serving as a guide for others and to show potential opportunities and pitfalls when implementing a blockchain from scratch.""
""og:type"",""article""
""citation_article_type"",""Research""
""citation_abstract"",""Blockchains are proposed for many application domains apart from financial transactions. While there are generic blockchains that can be molded for specific use cases, they often lack a lightweight and easy-to-customize implementation. In this paper, we introduce the core concepts of blockchain technology and investigate a real-world use case from the energy domain, where customers trade portions of their photovoltaic power plant via a blockchain. This does not only involve blockchain technology, but also requires user interaction. Therefore, a fully custom, private, and permissioned blockchain is implemented from scratch. We evaluate and motivate the need for blockchain technology within this use case, as well as the desired properties of the system. We then describe the implementation and the insights from our implementation in detail, serving as a guide for others and to show potential opportunities and pitfalls when implementing a blockchain from scratch.""
""og:title"",""Implementing a blockchain from scratch: why, how, and what we learned""
""prism.doi"",""doi:10.1186/s13635-019-0085-3""
""X-UA-Compatible"",""IE=edge""
""citation_firstpage"",""1""
""prism.startingPage"",""1""
""viewport"",""width=device-width, initial-scale=1""
""dc.rightsAgent"",""reprints@biomedcentral.com""
""prism.section"",""OriginalPaper""
""dc.identifier"",""doi:10.1186/s13635-019-0085-3""
""dc.subject"",""Signal,Image and Speech Processing"",""Systems and Data Security"",""Communications Engineering, Networks"",""Security Science and Technology""
""og:url"",""https://link.springer.com/article/10.1186/s13635-019-0085-3""
""prism.copyright"",""2019 The Author(s)""
";https://scholar.google.com/scholar?start=560&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094597-896;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[PDF][PDF] Identity-based Multi-Recipient Public Key Encryption Scheme and Its Application in IoT;J Li, X Tang, Z Wei, Y Wang, W Chen, Y Tan ; Mobile Networks and …, 2019  Springer;;"… IoT. At present, the existing ID-MRPKE schemes can only achieve the security in the

random oracle model. To … maps. The security of the novel scheme can be proven in

the standard model, instead of the random oracle. Furthermore …";Cité 3 fois;;[PDF] springer.com;https://idp.springer.com/authorize/casa?redirect_uri=https://link.springer.com/content/pdf/10.1007/s11036-019-01490-6.pdf&casa_token=TglbqGxUBtMAAAAA:Nf1ncGYehNcx-CDJ_w6PU6un0n1qds_i47flVJ7t3MZzx04cha5eMBBTHGeaS9Wy1X_862d12FZOujA;;;https://scholar.google.com/scholar?start=710&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094558-725;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[HTML][HTML] Cryptographic primitives in blockchains;L Wang, X Shen, J Li, J Shao, Y Yang ; Journal of Network and Computer …, 2019  Elsevier;;"… decentralization, unforgeability, double-spending resistance and pseudonymity, this brand new

e-cash system has brought a remarkable culmination of cryptocurrency research and … This situation

does not match with the fact that the blockchain is a crypto-intensive technology …";Cité 88 fois;Les 2 versions;[HTML] sciencedirect.com;https://www.sciencedirect.com/science/article/pii/S108480451830362X;;;https://scholar.google.com/scholar?start=540&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094572-789;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Supply Chain—Gold Tokenization;D Mohanty ; R3 Corda for Architects and Developers, 2019  Springer;;"… 7. If users wish to give back the tokens and exchange them for fiat currency, they can always

do so with that day's exchange rate, again by using Oracle services … All stakeholders use

Blockchain technology to automate and digitize every step in the gold supply chain …";Cité 1 fois;;null;;;;https://scholar.google.com/scholar?start=600&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094637-1061;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;IoT Resource Access utilizing Blockchains and Trusted Execution Environments;VA Siris, D Dimopoulos, N Fotiou… ; 2019 Global IoT …, 2019  ieeexplore.ieee.org;;"… Another line of work proposes an overlay of oracles that utilizes TEEs for allowing blockchains

to interact with the real world [16 … Related work that utilizes TEEs and blockchain functionality,

such as transaction verification and decentralized consensus, essentially fusing TEE and …";Cité 2 fois;Les 7 versions;[PDF] aueb.gr;https://acropolis.aueb.gr/~spyros/www/papers/2019-GIoTS.pdf;;"""date"",""2019-06-24T16:06:48Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2019-06-24T16:06:48Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is MiKTeX-pdfTeX 2.9.6642 (1.40.19)""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2019-06-24T16:06:48Z""
""created"",""2019-06-24T16:06:48Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-06-24T16:06:48Z""
""resourceName"",""2019-GIoTS.pdf""
""Author"",""""
""producer"",""pdfTeX-1.40.19""
""pdf:docinfo:producer"",""pdfTeX-1.40.19""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2019-06-24T16:06:48Z""
""Last-Modified"",""2019-06-24T16:06:48Z""
""dcterms:modified"",""2019-06-24T16:06:48Z""
""title"",""""
""Last-Save-Date"",""2019-06-24T16:06:48Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2019-06-24T16:06:48Z""
""meta:save-date"",""2019-06-24T16:06:48Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is MiKTeX-pdfTeX 2.9.6642 (1.40.19)""
""Content-Length"",""517489""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""6""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""4768"",""4980"",""4630"",""3865"",""5104"",""6431""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-06-24T16:06:48Z""
";https://scholar.google.com/scholar?start=880&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094630-1034;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[HTML][HTML] Blockchain authentication of network applications: Taxonomy, classification, capabilities, open challenges, motivations, recommendations and future …;AH Mohsin, AA Zaidan, BB Zaidan, OS Albahri… ; Computer Standards & …, 2019  Elsevier;;"… Blockchain 1.0, Corresponds with the original cryptocurrency uses … against existing forgery on

adaptively selected message and ID attack under the random oracle model. Polyzos and Fotiou

[18] designed a blockchain which supports the data distribution system to enhance the …";Cité 51 fois;Les 3 versions;[HTML] sciencedirect.com;https://www.sciencedirect.com/science/article/pii/S0920548918303477?casa_token=FE4YR1sR6f4AAAAA:MGGhzeimbYubB9CsbJt0ILZQs0Qc8Pheo0D7vH158Nzfg3bjwpmDGfw77PiOF_P60OD2yF4G;;;https://scholar.google.com/scholar?start=850&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094565-755;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Private Communication Based on Hierarchical Identity-Based Cryptography;D Kalyani, R Sridevi ; Emerging Technologies in Data Mining and …, 2019  Springer;;"… Springer (2005)Google Scholar. 11. Boyen, X., Waters, B.: Anonymous hierarchical identity based

encryption (without random oracles). In: CRYPTO 2006, vol. 4117, pp. 290–307. Springer

(2006)Google Scholar. 12. Sahai, A., Waters, B.: Fuzzy identity-based encryption …";Autres articles;;null;;;;https://scholar.google.com/scholar?start=570&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094656-1142;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[PDF][PDF] A FULLY DECENTRALIZED FRAMEWORK FOR SECURELY SHARING DIGITAL CONTENT;AS DEM?R ;2019 etd.lib.metu.edu.tr;;"… September 2019, 97 pages Blockchain is a secure, immutable, and distributed public ledger

that stores transactional data … Besides finance, blockchain technology has the potential to change

several industries, through smart contracts and decentralized applications …";Autres articles;Version HTML;[PDF] metu.edu.tr;http://etd.lib.metu.edu.tr/upload/12624332/index.pdf;;"""date"",""2019-10-03T11:19:08Z""
""pdf:PDFVersion"",""1.7""
""xmp:CreatorTool"",""Office 365 için MicrosoftŽ Word""
""pdf:docinfo:title"",""A FULLY DECENTRALIZED FRAMEWORK FOR SECURELY SHARING DIGITAL CONTENT""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""language"",""en""
""dc:format"",""application/pdf; version=1.7""
""pdf:docinfo:creator_tool"",""Office 365 için MicrosoftŽ Word""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""A FULLY DECENTRALIZED FRAMEWORK FOR SECURELY SHARING DIGITAL CONTENT""
""xmp:CreateDate"",""2019-10-03T04:19:08Z""
""modified"",""2019-10-03T11:19:08Z""
""pdf:hasMarkedContent"",""true""
""xmp:ModifyDate"",""2019-10-03T04:19:08Z""
""pdf:docinfo:creator"",""ASD""
""meta:author"",""ASD""
""meta:creation-date"",""2019-10-03T11:19:08Z""
""created"",""2019-10-03T11:19:08Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-10-03T11:19:08Z""
""resourceName"",""index.pdf""
""Author"",""ASD""
""producer"",""Office 365 için MicrosoftŽ Word""
""pdf:docinfo:producer"",""Office 365 için MicrosoftŽ Word""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""access_permission:modify_annotations"",""true""
""dc:creator"",""ASD""
""dcterms:created"",""2019-10-03T11:19:08Z""
""Last-Modified"",""2019-10-03T11:19:08Z""
""dcterms:modified"",""2019-10-03T11:19:08Z""
""title"",""A FULLY DECENTRALIZED FRAMEWORK FOR SECURELY SHARING DIGITAL CONTENT""
""xmpMM:DocumentID"",""uuid:C1151171-61DB-4D61-AE1D-816A9640A6FE""
""Last-Save-Date"",""2019-10-03T11:19:08Z""
""pdf:docinfo:modified"",""2019-10-03T11:19:08Z""
""meta:save-date"",""2019-10-03T11:19:08Z""
""Content-Length"",""3455733""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""ASD""
""dc:language"",""en-US""
""pdf:producer"",""Office 365 için MicrosoftŽ Word""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""114""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""343"",""3"",""847"",""1"",""409"",""2096"",""2164"",""41"",""659"",""3229"",""3844"",""1630"",""985"",""2809"",""694"",""6"",""2483"",""3352"",""3200"",""2848"",""2226"",""883"",""2375"",""3530"",""3451"",""1726"",""2286"",""2072"",""2362"",""3107"",""3211"",""3420"",""3085"",""2922"",""2718"",""2915"",""1738"",""2341"",""2362"",""3293"",""2173"",""3280"",""2586"",""3207"",""1813"",""1981"",""1813"",""1901"",""3254"",""179"",""2758"",""1896"",""1817"",""985"",""3390"",""2886"",""2811"",""3024"",""3497"",""3583"",""3383"",""1833"",""35"",""478"",""1743"",""846"",""3413"",""1992"",""1909"",""1131"",""1059"",""1768"",""1987"",""2045"",""2254"",""1372"",""217"",""1340"",""747"",""467"",""1000"",""99"",""1852"",""2857"",""3429"",""2850"",""2629"",""3042"",""2873"",""2808"",""2107"",""3074"",""2358"",""2979"",""3045"",""2826"",""1171"",""6"",""1951"",""2696"",""2568"",""2509"",""2411"",""2468"",""2479"",""2384"",""2539"",""789"",""1231"",""1372"",""1060"",""1026"",""1246"",""2446""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-10-03T11:19:08Z""
";https://scholar.google.com/scholar?start=960&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094647-1107;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[PDF][PDF] Forgery Attack on mixFeed in the Nonce-Misuse Scenario.;M Khairallah ; IACR Cryptol. ePrint Arch., 2019  csrc.nist.gov;;"… From: Mustafa Khairallah <khairallah@ieee.org> Sent: Monday, May 06, 2019 3:32 AM To:

lightweight-crypto Cc: lwc-forum Subject: OFFICIAL COMMENT … 3. Send the following query to

the encryption oracle: (N,A,M), storing the ciphertex- t/tag pair (C, T), where C consists of 4 …";Cité 3 fois;Les 3 versions;[PDF] nist.gov;https://csrc.nist.gov/CSRC/media/Projects/Lightweight-Cryptography/documents/round-1/official-comments/mixFeed-official-comment.pdf;;"""date"",""2019-08-06T15:54:05Z""
""pdf:PDFVersion"",""1.7""
""xmp:CreatorTool"",""PScript5.dll Version 5.2.2""
""pdf:docinfo:title"",""Official Comments - mixFeed""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""Lightweight Cryptography Standardization Official Comments
""
""language"",""en""
""dc:format"",""application/pdf; version=1.7""
""pdf:docinfo:creator_tool"",""PScript5.dll Version 5.2.2""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""Official Comments - mixFeed""
""xmp:CreateDate"",""2019-05-06T09:09:36Z""
""modified"",""2019-08-06T15:54:05Z""
""cp:subject"",""Lightweight Cryptography Standardization Official Comments
""
""pdf:docinfo:subject"",""Lightweight Cryptography Standardization Official Comments
""
""pdf:hasMarkedContent"",""true""
""xmp:ModifyDate"",""2019-08-06T11:54:05Z""
""pdf:docinfo:creator"",""Various comments from the lightweight cryptography community""
""meta:author"",""Various comments from the lightweight cryptography community""
""meta:creation-date"",""2019-05-06T13:09:36Z""
""created"",""2019-05-06T13:09:36Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-05-06T13:09:36Z""
""resourceName"",""mixFeed-official-comment.pdf""
""Author"",""Various comments from the lightweight cryptography community""
""producer"",""Acrobat Distiller 15.0 (Windows)""
""pdf:docinfo:producer"",""Acrobat Distiller 15.0 (Windows)""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""5"",""18"",""8"",""0"",""0"",""0"",""0"",""0""
""dc:description"",""Lightweight Cryptography Standardization Official Comments
""
""Keywords"",""lightweight cryptography; LWC; standardization; NIST; official comment"",""lightweight cryptography; LWC; standardization; NIST; official comment""
""access_permission:modify_annotations"",""true""
""dc:creator"",""Various comments from the lightweight cryptography community""
""description"",""Lightweight Cryptography Standardization Official Comments
""
""dcterms:created"",""2019-05-06T13:09:36Z""
""Last-Modified"",""2019-08-06T15:54:05Z""
""dcterms:modified"",""2019-08-06T15:54:05Z""
""title"",""Official Comments - mixFeed""
""xmpMM:DocumentID"",""uuid:edfb415a-9890-45c2-bb81-6300f5c5e1c0""
""Last-Save-Date"",""2019-08-06T15:54:05Z""
""pdf:docinfo:keywords"",""lightweight cryptography; LWC; standardization; NIST; official comment""
""pdf:docinfo:modified"",""2019-08-06T15:54:05Z""
""meta:save-date"",""2019-08-06T15:54:05Z""
""Content-Length"",""1852054""
""Content-Type"",""application/pdf""
""xmp:MetadataDate"",""2019-08-06T11:54:05Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Various comments from the lightweight cryptography community""
""dc:language"",""en""
""pdf:producer"",""Acrobat Distiller 15.0 (Windows)""
""dc:subject"",""lightweight cryptography; LWC; standardization; NIST; official comment"",""lightweight cryptography; LWC; standardization; NIST; official comment""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""9""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""1039"",""2079"",""1492"",""1246"",""1260"",""1812"",""973"",""2531"",""3328""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""meta:keyword"",""lightweight cryptography; LWC; standardization; NIST; official comment"",""lightweight cryptography; LWC; standardization; NIST; official comment""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-05-06T13:09:36Z""
";https://scholar.google.com/scholar?start=920&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094551-698;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Panel I: Blockchain and the Law;CL Reyes, NM Rosario, RM Cannon… ; The John Marshall Journal …, 2019  HeinOnline;;"… In addition, he teaches a class called ""Blockchain, Cryptocurrency + Law"" at the Illinois Tech

Chicago-Kent College of Law … My friends and I joke that once you learn about blockchain

technology and crypto, it's so interesting that it sort of just takes over your life, and …";Cité 1 fois;;null;;;;https://scholar.google.com/scholar?start=510&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094579-817;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;The emerging role of blockchain technology applications in routine disease surveillance systems to strengthen global health security;VK Chattu, A Nanda, SK Chattu, SM Kadri… ; Big Data and Cognitive …, 2019  mdpi.com;;"… Of the various available applications of blockchain technology, Bitcoin is the most popular example

that uses this technology for cryptocurrency [6]. Other areas or industries where this technology

is used are bank payments, money transfers, leasing, car sales, cybersecurity …";Cité 17 fois;Les 2 versions;[PDF] mdpi.com;https://www.mdpi.com/2504-2289/3/2/25/pdf;;;https://scholar.google.com/scholar?start=630&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094623-1004;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[CITATION][C] ????????? ??????? ?????????? ??????-????????????????? ??????? Ť????????????? ?????????????? ???????ť;?? ????????, ?? ??????? ; bi.hse.ru;;"… ???????? blockchain.???? ??????. ????? ?????????? blockchain.????? ? ??????

??????????. ????????????? ?????????? ? ?????????????? ???????? … 16. ??????????????

??????? Oracle EBS: ?????????? ?????????? ?????????????. 17 …";Autres articles;Version HTML;null;;;;https://scholar.google.com/scholar?start=820&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094534-626;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[PDF][PDF] A PROSPECTIVE STUDY ON FASTER AND MORE SECURE DOCUMENT TRAFFIC FOR INTERNATIONAL TRADE WITH BLOCKCHAIN TECHNOLOGY;H TEKLER, M ZHU ; academia.edu;;"… A blockchain/DLT 13 transaction can involve any type of asset – digital (eg cryptocurrency, digital

painting), tangible (eg a transfer of property or funds, or an exchange of documents such as a

customs declaration or certificates of origin), or intangible (eg provision of a service …";Autres articles;Version HTML;[PDF] academia.edu;https://www.academia.edu/download/60876629/A_PROSPECTIVE_STUDY_ON_FASTER_AND_MORE_SECURE_DOCUMENT_TRAFFIC_FOR_INTERNATIONAL_TRADE_WITH_BLOCKCHAIN_TECHNOLOGY20191012-106957-1nrh4sj.pdf;;;https://scholar.google.com/scholar?start=440&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094565-753;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Blockchain a Challenge for the New Future Mobile Economy.;V Mazilescu ; Annals of the University Dunarea de Jos of …, 2019  search.ebscohost.com;;"… Major technology developers, such as IBM, Oracle and Amazon, have been involved in blockchain

services … but you have to pay for the computational power consumed with crypto Ethereum …

978-3-319-67816- 0_22 2. Bhardwaj, S., Kaushik, M. (2018): Blockchain—technology to …";Autres articles;;null;;;;https://scholar.google.com/scholar?start=570&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094649-1117;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;A Blueprint for Interoperable Blockchains;TTA Dinh, A Datta, BC Ooi ; arXiv preprint arXiv:1910.00985, 2019  arxiv.org;;"… https://interledger.org. [7] Medilot: transforming healthcare for all. https://medilot.com. [8] The

provable blockchain oracle for modern dapps. http://provable.xyz. [9] A transparent, highly scalable

and cryptographically verifiable data store. https://github.com/google/trillian …";Cité 1 fois;Les 2 versions;[PDF] arxiv.org;https://arxiv.org/pdf/1910.00985;;"""date"",""2019-10-23T00:34:54Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2019-10-23T00:34:54Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016) kpathsea version 6.2.2""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2019-10-23T00:34:54Z""
""created"",""2019-10-23T00:34:54Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-10-23T00:34:54Z""
""resourceName"",""1910.00985""
""Author"",""""
""producer"",""pdfTeX-1.40.17""
""pdf:docinfo:producer"",""pdfTeX-1.40.17""
""pdf:unmappedUnicodeCharsPerPage"",""1"",""0"",""0"",""0"",""0"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2019-10-23T00:34:54Z""
""Last-Modified"",""2019-10-23T00:34:54Z""
""dcterms:modified"",""2019-10-23T00:34:54Z""
""title"",""""
""Last-Save-Date"",""2019-10-23T00:34:54Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2019-10-23T00:34:54Z""
""meta:save-date"",""2019-10-23T00:34:54Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016) kpathsea version 6.2.2""
""Content-Length"",""363894""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""7""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""4062"",""5244"",""5653"",""5970"",""4190"",""6462"",""11""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-10-23T00:34:54Z""
";https://scholar.google.com/scholar?start=930&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094541-653;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;A Study on User's Acceptance of Blockchain-based Copyright Distribution Platforms and Its Usage;YH Yoo, HS Park ; The Journal of Industrial Distribution & …, 2019  koreascience.or.kr;;"… 59 1. ?? ?????(Internet of Things), ????(Bigdata), ???? (Artificial Intelligence)?

??? ????(Blockchain) ??? 4 * First Author, Doctoral Candidate, Dept … A Study on User's

Acceptance of Blockchain-based Copyright Distribution Platforms and Its Usage …";Cité 3 fois;Les 3 versions;[PDF] koreascience.or.kr;https://www.koreascience.or.kr/article/JAKO201915658233627.pdf;;"""date"",""2020-05-29T06:26:50Z""
""pdf:PDFVersion"",""1.6""
""xmp:CreatorTool"",""PScript5.dll Version 5.2.2""
""pdf:docinfo:title"",""IJIDB_10-3_6ě°¨.hwp""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""language"",""en""
""dc:format"",""application/pdf; version=1.6""
""pdf:docinfo:creator_tool"",""PScript5.dll Version 5.2.2""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""IJIDB_10-3_6ě°¨.hwp""
""xmp:CreateDate"",""2019-03-28T09:50:46Z""
""modified"",""2020-05-29T06:26:50Z""
""pdf:hasMarkedContent"",""false""
""xmp:ModifyDate"",""2020-05-29T15:26:50Z""
""pdf:docinfo:creator"",""Administrator""
""meta:author"",""Administrator""
""meta:creation-date"",""2019-03-28T00:50:46Z""
""created"",""2019-03-28T00:50:46Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-03-28T00:50:46Z""
""resourceName"",""JAKO201915658233627.pdf""
""Author"",""Administrator""
""producer"",""Acrobat Distiller 10.1.16 (Windows)""
""pdf:docinfo:producer"",""Acrobat Distiller 10.1.16 (Windows)""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""access_permission:modify_annotations"",""true""
""dc:creator"",""Administrator""
""dcterms:created"",""2019-03-28T00:50:46Z""
""Last-Modified"",""2020-05-29T06:26:50Z""
""dcterms:modified"",""2020-05-29T06:26:50Z""
""title"",""IJIDB_10-3_6ě°¨.hwp""
""xmpMM:DocumentID"",""uuid:656129ef-2a96-4e9e-bd9a-b6e6f615f114""
""Last-Save-Date"",""2020-05-29T06:26:50Z""
""pdf:docinfo:modified"",""2020-05-29T06:26:50Z""
""meta:save-date"",""2020-05-29T06:26:50Z""
""Content-Length"",""436621""
""Content-Type"",""application/pdf""
""xmp:MetadataDate"",""2020-05-29T15:26:50Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Administrator""
""pdf:producer"",""Acrobat Distiller 10.1.16 (Windows)""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""14""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""3788"",""3581"",""4142"",""3750"",""2681"",""3396"",""3215"",""2919"",""1629"",""2824"",""2969"",""3359"",""5208"",""4047""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-03-28T00:50:46Z""
";https://scholar.google.com/scholar?start=470&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094539-644;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[PDF][PDF] Locality-Preserving Blockchain Implementation;M Sierro ;2019 epfl.ch;;"… It is constructed in the following way : 1. The approximate distance oracles technique [3] is used

to generate networks that have latencies bounded by their diameter … In this context, there is not

a single blockchain but multiple ones, each corresponding to a region …";Autres articles;;[PDF] epfl.ch;https://www.epfl.ch/labs/dedis/wp-content/uploads/2020/01/report-2019-1-Maxime-Sierro.pdf;;"""date"",""2019-06-07T18:05:58Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""3"",""1"",""0"",""0""
""pdf:PDFVersion"",""1.5""
""xmp:CreatorTool"",""TeX""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dcterms:created"",""2019-06-07T18:05:58Z""
""language"",""en""
""Last-Modified"",""2019-06-07T18:05:58Z""
""dcterms:modified"",""2019-06-07T18:05:58Z""
""dc:format"",""application/pdf; version=1.5""
""Last-Save-Date"",""2019-06-07T18:05:58Z""
""pdf:docinfo:creator_tool"",""TeX""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2019-06-07T18:05:58Z""
""meta:save-date"",""2019-06-07T18:05:58Z""
""pdf:encrypted"",""false""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.20 (TeX Live 2019) kpathsea version 6.3.1""
""modified"",""2019-06-07T18:05:58Z""
""Content-Length"",""761002""
""pdf:hasMarkedContent"",""false""
""Content-Type"",""application/pdf""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.20 (TeX Live 2019) kpathsea version 6.3.1""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""trapped"",""False""
""meta:creation-date"",""2019-06-07T18:05:58Z""
""created"",""2019-06-07T18:05:58Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""17""
""Creation-Date"",""2019-06-07T18:05:58Z""
""resourceName"",""report-2019-1-Maxime-Sierro.pdf""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""245"",""731"",""1072"",""1344"",""1332"",""156"",""365"",""2116"",""2155"",""2266"",""2290"",""2363"",""1372"",""1724"",""959"",""2093"",""611""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""producer"",""pdfTeX-1.40.20""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""pdfTeX-1.40.20""
""pdf:docinfo:created"",""2019-06-07T18:05:58Z""
";https://scholar.google.com/scholar?start=460&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094616-975;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[CITATION][C] Perspectives on Blockchain for humanitarian aid;L Taylor, AK Martin ;2019;;null;Autres articles;;null;;;;https://scholar.google.com/scholar?start=790&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094609-941;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Applying Blockchain Technology to Develop Cross-Domain Digital Talent;YC Chen, HJ Wu, CP Wang, CH Yeh… ; 2019 IEEE 11th …, 2019  ieeexplore.ieee.org;;"… “5 Ways Blockchain Is Revolutionizing Higher Education.” The Wall Street Journal.

[Online]. Available: https://partners.wsj.com/oracle/5-ways-blockchain-revolutionizing-

higher-education/ [14] Durant, E., & Trachy, A. (2017) …";Cité 1 fois;;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/8972660/8994820/08994934.pdf?casa_token=tuH_Hw0YV08AAAAA:Pfi4XsPgXzHsinO6azTQFP6E6x9kayRJ0ynjGpHW5WKVdBha1CRd3UkNyFuHSClS2FnDDfIof8o;;"""og:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""twitter:title"",""Applying Blockchain Technology to Develop Cross-Domain Digital Talent""
""twitter:card"",""summary""
""Description"",""To decrease the talent shortage in the digital economy industry and fill the gap between academics and industry, this study establishes an innovative model to c""
""og:title"",""Applying Blockchain Technology to Develop Cross-Domain Digital Talent""
""resourceName"",""08994934.pdf""
""language"",""en""
""title"",""Applying Blockchain Technology to Develop Cross-Domain Digital Talent | IEEE Conference Publication | IEEE Xplore""
""og:description"",""To decrease the talent shortage in the digital economy industry and fill the gap between academics and industry, this study establishes an innovative model to cultivate interdisciplinary talent that links the resources in the academic and industrial fields. To monitor and manage the learning performance and training history throughout the process, this study creates a Talent Management System (TMS), which uses blockchain technology to record 698 interns' data on their online learning history, project outcomes, and certification of completion. With TMS, research institutions, schools, and corporations can access the digital resumes of interns more efficiently, thus reducing the cost of management and recruiting and ensuring the authentication of resumes.""
""twitter:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-UA-Compatible"",""IE=Edge""
""viewport"",""width=device-width, initial-scale=1.0""
""dc:title"",""Applying Blockchain Technology to Develop Cross-Domain Digital Talent | IEEE Conference Publication | IEEE Xplore""
""twitter:description"",""To decrease the talent shortage in the digital economy industry and fill the gap between academics and industry, this study establishes an innovative model to cultivate interdisciplinary talent that links the resources in the academic and industrial fields. To monitor and manage the learning performance and training history throughout the process, this study creates a Talent Management System (TMS), which uses blockchain technology to record 698 interns' data on their online learning history, project outcomes, and certification of completion. With TMS, research institutions, schools, and corporations can access the digital resumes of interns more efficiently, thus reducing the cost of management and recruiting and ensuring the authentication of resumes.""
""Content-Encoding"",""UTF-8""
""Content-Type-Hint"",""text/html; charset=utf-8""
""Content-Length"",""40530""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=760&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094626-1013;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;MProve: A proof of reserves protocol for Monero exchanges;A Dutta, S Vijayakumaran ; 2019 IEEE European Symposium …, 2019  ieeexplore.ieee.org;;"… and Peter Todd [5]. But this ap- proach revealed the total amount of assets held by an exchange

and the cryptocurrency addresses storing … 1) Proof of reserves: The exchange chooses a set P

of unspent addresses with known public keys from the Bitcoin blockchain such that it …";Cité 4 fois;Les 4 versions;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/8790672/8802376/08802437.pdf?casa_token=hwiEVz3HhPcAAAAA:DTHv-ynQd3POxPCbH964ef9HwnU9RmvedIpgpELA_xcSuEfeD6MmVOgOkzvdHSQOCD4pz7Arntk;;"""og:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""twitter:title"",""MProve: A Proof of Reserves Protocol for Monero Exchanges""
""twitter:card"",""summary""
""Description"",""Theft from cryptocurrency exchanges due to cyberattacks or internal fraud is a major problem. Exchanges can partially alleviate customer concerns by providing p""
""og:title"",""MProve: A Proof of Reserves Protocol for Monero Exchanges""
""resourceName"",""08802437.pdf""
""language"",""en""
""title"",""MProve: A Proof of Reserves Protocol for Monero Exchanges | IEEE Conference Publication | IEEE Xplore""
""og:description"",""Theft from cryptocurrency exchanges due to cyberattacks or internal fraud is a major problem. Exchanges can partially alleviate customer concerns by providing periodic proofs of solvency. We describe MProve, a proof of reserves protocol for Monero exchanges which can be combined with a known proof of liabilities protocol to provide a proof of solvency. It is the first protocol for Monero which provides address privacy by allowing an exchange to hide its own addresses within a larger anonymity set. MProve also provides a simple proof of non-collusion between exchanges.""
""twitter:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-UA-Compatible"",""IE=Edge""
""viewport"",""width=device-width, initial-scale=1.0""
""dc:title"",""MProve: A Proof of Reserves Protocol for Monero Exchanges | IEEE Conference Publication | IEEE Xplore""
""twitter:description"",""Theft from cryptocurrency exchanges due to cyberattacks or internal fraud is a major problem. Exchanges can partially alleviate customer concerns by providing periodic proofs of solvency. We describe MProve, a proof of reserves protocol for Monero exchanges which can be combined with a known proof of liabilities protocol to provide a proof of solvency. It is the first protocol for Monero which provides address privacy by allowing an exchange to hide its own addresses within a larger anonymity set. MProve also provides a simple proof of non-collusion between exchanges.""
""Content-Encoding"",""UTF-8""
""Content-Type-Hint"",""text/html; charset=utf-8""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=830&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094593-876;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[HTML][HTML] Tortoise, not the hare: Digital transformation of supply chain business processes;JL Hartley, WJ Sawaya ; Business Horizons, 2019  Elsevier;;"… In addition, routine transactions can be automated with blockchain using smart contracts (Min,

2019). Large technology companies (eg, IBM, SAP, Oracle, Microsoft) as well as many technology

startups have developed blockchain applications for supply chain management …";Cité 22 fois;Les 5 versions;[HTML] sciencedirect.com;https://www.sciencedirect.com/science/article/pii/S0007681319300977?casa_token=S5FFOlmvLmIAAAAA:v147uD2ltTlRDAa5-rQO6HfdnJ3NggrfKH8fzC15gl9zk_x93_A_jeSLZvN5zrArgdthYuqb;;;https://scholar.google.com/scholar?start=690&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094537-638;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Electronic health record sharing scheme with searchable attribute-based encryption on blockchain;S Niu, L Chen, J Wang, F Yu ; IEEE Access, 2019  ieeexplore.ieee.org;;"… privacy, a polynomial equation is used to achieve an arbitrary connection of keywords, and then

blockchain technology is combined. In addition, the proposed scheme has keyword-

indistinguishability against adaptive chosen keyword attacks under the random oracle model …";Cité 12 fois;;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/6287639/8948470/08931605.pdf;;"""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""dc:title"",""IEEE Xplore Full-Text PDF:""
""Content-Encoding"",""UTF-8""
""resourceName"",""08931605.pdf""
""language"",""es""
""Content-Length"",""2565""
""title"",""IEEE Xplore Full-Text PDF:""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=450&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094541-652;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Research on Missile Data Security Based on Blockchain;Y Wang, L Cong, Y Fang, J Deng… ; Journal of Physics …, 2019  iopscience.iop.org;;"… [14] Boneh D, Boyen X. Efficient Selective Identity-based Encryption without Random

Oracles[J]. Journal of Cryptology, 2011(04):659-693. [15] Song TY, Zhao ZL Comparison of

Blockchain Consensus Algorithm[J]. Computer Applications and Software, 2018(08):1-8.";Autres articles;;[PDF] iop.org;https://iopscience.iop.org/article/10.1088/1742-6596/1237/2/022139/pdf;;"""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""viewport"",""width=device-width, initial-scale=1""
""dc:title"",""ShieldSquare Captcha""
""Content-Encoding"",""UTF-8""
""resourceName"",""pdf""
""language"",""en""
""Content-Length"",""2754""
""title"",""ShieldSquare Captcha""
""Content-Language"",""en""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=470&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094548-684;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[CITATION][C] Beyond the hype: A study of the applicability of blockchain-based smart contracts in the industry-Towards a proof of concept;C Gonzalez ;2019 matheo.uliege.be;;"… Oracle, Alibaba, Facebook, IBM, Amazon, Ford, Siemens, Toyota, Nestlé, Walmart, Carrefour,

ABInBev, all these giants have already invested millions of dollars … And yet… More than one year

after the celebration of its tenth birthday, blockchain technology has still not given birth …";;;null;;;;https://scholar.google.com/scholar?start=500&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094574-793;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[LIVRE][B] Les blockchains en 50 questions: Comprendre le fonctionnement et les enjeux de cette technologie;JG Dumas, P Lafourcade, A Tichit, S Varrette ;2019 books.google.com;;"… 3 2 Qu'est-ce qu'une blockchain … 163 36 Qu'est-ce qu'une preuve d'espace

(Spacemint) ? . . . 175 37 Que sont IOTA et la structure de données Tangle ? . . . .

179 38 Peut-on faire une blockchain sans bloc …";Cité 7 fois;Les 14 versions;null;;;;https://scholar.google.com/scholar?start=610&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094623-1009;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Characterizing Collision and Second-Preimage Resistance in Linicrypt;I McQuoid, T Swope, M Rosulek ; Theory of Cryptography Conference, 2019  Springer;;"… Part of the Lecture Notes in Computer Science book series (LNCS, volume 11891). Abstract.

Linicrypt (Carmer & Rosulek, Crypto 2016) refers to the class of algorithms that make calls to

a random oracle and otherwise manipulate values via fixed linear operations …";Cité 1 fois;Les 2 versions;[PDF] iacr.org;https://eprint.iacr.org/2018/458.pdf;;"""date"",""2020-07-24T18:17:57Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2020-07-24T18:17:57Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017) kpathsea version 6.2.3""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2020-07-24T18:17:57Z""
""created"",""2020-07-24T18:17:57Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-07-24T18:17:57Z""
""resourceName"",""458.pdf""
""Author"",""""
""producer"",""pdfTeX-1.40.18""
""pdf:docinfo:producer"",""pdfTeX-1.40.18""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""1"",""9"",""18"",""38"",""34"",""20"",""20"",""7"",""20"",""28"",""34"",""25"",""6"",""14"",""2"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2020-07-24T18:17:57Z""
""Last-Modified"",""2020-07-24T18:17:57Z""
""dcterms:modified"",""2020-07-24T18:17:57Z""
""title"",""""
""Last-Save-Date"",""2020-07-24T18:17:57Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2020-07-24T18:17:57Z""
""meta:save-date"",""2020-07-24T18:17:57Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017) kpathsea version 6.2.3""
""Content-Length"",""389668""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""18""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""2398"",""2743"",""2721"",""1962"",""2026"",""2235"",""2491"",""1847"",""2015"",""1933"",""2471"",""2386"",""2374"",""1486"",""1645"",""2429"",""2814"",""2070""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-07-24T18:17:57Z""
";https://scholar.google.com/scholar?start=820&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094537-639;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Blockchain 2019;F Zola, M Eguimendia, J Lukas, E Nyaletey, RM Parizi… ; computer.org;;"… and Cliff C. Zou, (University of Central Florida),C2P2: A Collective Cryptocurrency Up/Down … of

Technology), and Zhenguang Liu (Zhejiang Gongshang University),From Oracles to Trustworthy …

Jacob Eberhardt (TU Berlin), and Stefan, Tai (TU Berlin),Blockchain-Based Charging …";Les 2 versions;;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/8938397/8946120/08946274.pdf;;"""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""dc:title"",""IEEE Xplore Full-Text PDF:""
""Content-Encoding"",""UTF-8""
""resourceName"",""08946274.pdf""
""language"",""es""
""Content-Length"",""2565""
""title"",""IEEE Xplore Full-Text PDF:""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=450&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094572-781;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[HTML][HTML] De la tecnología blockchain a la economía del token;MN Pacheco Jiménez ; Derecho PUCP, 2019  scielo.org.pe;;"… Así las cosas, la plataforma Crypto Birds (startup creada con la finalidad de servir de punto de

encuentro de las ICO y proyectos blockchain con inversores 25 ) realizó a primeros de abril de

2019 una de las primeras emisiones de criptomonedas en Espańa, pero sin requerir la …";Autres articles;;[HTML] scielo.org.pe;http://www.scielo.org.pe/scielo.php?pid=S0251-34202019000200003&script=sci_arttext&tlng=pt;;"""citation_title"",""De la tecnologĂ­a blockchain a la economĂ­a del token""
""citation_author_institution"",""Universidad de Castilla-La Mancha, EspaĂąa""
""citation_publisher"",""Pontificia Universidad CatĂłlica del PerĂş""
""citation_journal_title"",""Derecho PUCP""
""citation_id"",""10.18800/derechopucp.201902.003""
""language"",""es""
""citation_date"",""00/2019""
""title"",""De la tecnologĂ­a blockchain a la economĂ­a del token""
""citation_issn"",""0251-3420""
""dc:title"",""De la tecnologĂ­a blockchain a la economĂ­a del token""
""citation_fulltext_html_url"",""http://www.scielo.org.pe/scielo.php?script=sci_arttext&pid=S0251-34202019000200003&lng=es&nrm=iso&tlng=pt""
""Content-Encoding"",""UTF-8""
""Content-Type-Hint"",""text/html; charset=UTF-8""
""citation_pdf_url"",""http://www.scielo.org.pe/pdf/derecho/n83/a03n83.pdf""
""citation_lastpage"",""87""
""Content-Type"",""text/html; charset=UTF-8""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""citation_author"",""Pacheco JimĂŠnez, MarĂ­a Nieves""
""resourceName"",""scielo.php""
""Pragma"",""no-cache""
""citation_abstract_html_url"",""http://www.scielo.org.pe/scielo.php?script=sci_abstract&pid=S0251-34202019000200003&lng=es&nrm=iso&tlng=pt""
""citation_issue"",""83""
""citation_firstpage"",""61""
""citation_doi"",""10.18800/derechopucp.201902.003""
""citation_journal_title_abbrev"",""Derecho""
""Expires"",""Mon, 06 Jan 1990 00:00:01 GMT""
""citation_volume"",""""
";https://scholar.google.com/scholar?start=600&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094586-847;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[CITATION][C] 18 Observations on the Impact of Technology on Contract Law;B Pasa, LA DiMatteo ; Law and Critique;;null;Autres articles;;null;;;;https://scholar.google.com/scholar?start=660&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094644-1098;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Blockchain as the database engine in the accounting system;BS Tan, KY Low ; Australian Accounting Review, 2019  Wiley Online Library;;"… design for AIS, ranging from standalone AIS (eg, Quickbook) to accounting modules of an

Enterprise Resource Planning system (eg, financial module of the Oracle ERP … Crossref. Lennart

Ante, A place next to Satoshi: foundations of blockchain and cryptocurrency research in …";Cité 30 fois;Les 4 versions;[PDF] wiley.com;https://onlinelibrary.wiley.com/doi/pdf/10.1111/auar.12278?casa_token=IFbwxqDCFUwAAAAA:lijlJ3z-Uo4etnrI5QUGT_ePDATT04U_UyJj3ePOkbK5QlU3fH3uaCNqXoTC3IU577kWnBYyiu8kRg;;;https://scholar.google.com/scholar?start=910&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094668-1185;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[PDF][PDF] Proof of Provision: Improving Blockchain Technology by Cloud Computing.;M Pohl, A Nahhas, S Bosse, K Turowski ; CLOSER, 2019  scitepress.org;;"… Furthermore, it is possible to link the transactions to conditions that are checked by so-called

oracles (eg data feeds … Ouroboros: A Provably Secure Proof-of- Stake Blockchain Protocol. In

Katz, J. and Shacham, H., editors, Advances in Cryptology – Crypto 2017, volume 10401 …";Cité 1 fois;;[PDF] scitepress.org;https://www.scitepress.org/Papers/2019/77656/77656.pdf;;"""date"",""2019-05-24T19:25:40Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2019-05-24T19:25:40Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is MiKTeX-pdfTeX 2.9.6870 (1.40.19)""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2019-05-24T19:25:40Z""
""created"",""2019-05-24T19:25:40Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-05-24T19:25:40Z""
""resourceName"",""77656.pdf""
""Author"",""""
""producer"",""pdfTeX-1.40.19""
""pdf:docinfo:producer"",""pdfTeX-1.40.19""
""pdf:unmappedUnicodeCharsPerPage"",""1"",""0"",""0"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2019-05-24T19:25:40Z""
""Last-Modified"",""2019-05-24T19:25:40Z""
""dcterms:modified"",""2019-05-24T19:25:40Z""
""title"",""""
""Last-Save-Date"",""2019-05-24T19:25:40Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2019-05-24T19:25:40Z""
""meta:save-date"",""2019-05-24T19:25:40Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is MiKTeX-pdfTeX 2.9.6870 (1.40.19)""
""Content-Length"",""274675""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""5""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""3684"",""4077"",""4279"",""4129"",""2057""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-05-24T19:25:40Z""
";https://scholar.google.com/scholar?start=410&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094574-796;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Cocks' Identity-Based Encryption in the Standard Model, via Obfuscation Techniques (Short Paper);X Wang, S Li, R Xue ; International Workshop on Security, 2019  Springer;;"… 4. The adversary queries the key extraction oracle a polynomial number of times on \(\mathsf

{id}\ne \mathsf {id … 978-3-540-24676-3_14CrossRefGoogle Scholar. 4. Boneh, D., Boyen, X.: Secure

identity based encryption without random oracles. In: Franklin, M. (ed.) CRYPTO 2004 …";Autres articles;;null;;;;https://scholar.google.com/scholar?start=610&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094595-884;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[HTML][HTML] ????????? ? ??????????? ???????? ????? ??????? ?? ?????????? ?????????????? ????;?? ??????, ?? ?????????? ; ??????? ???????? ??????, 2019  cyberleninka.ru;;"… https: blog.etereum.org / 2014/07/22 / etereum and oracles. 2. Nakamoto, S. Bitcoin: A

Peer-to-Peer electronic cash system (24 May 2009) htpps: / / bitcoin.org/en/ bitcoin-paper. 3.

Vińa, P. The truth machine. Blockchain and the future of mankind / Vina P., Casey M. // [trans …";Cité 3 fois;Les 2 versions;[HTML] cyberleninka.ru;https://cyberleninka.ru/article/n/sostoyanie-i-perspektivy-razvitiya-sfery-turizma-na-territorii-krasnodarskogo-kraya;;"""citation_keywords"",""ТУРИЗМ, САНАТОРНО-КУРОРТНЫЙ КОМПЛЕКС, ТУРИСТИЧЕСКИЙ КОМПЛЕКС, ТУРИСТИЧЕСКИЙ РЫНОК, TOURISM, SANATORIUM COMPLEX, TOURIST COMPLEX, TOURIST MARKET""
""og:image"",""https://cyberleninka.ru/article/n/sostoyanie-i-perspektivy-razvitiya-sfery-turizma-na-territorii-krasnodarskogo-kraya/og""
""og:image:width"",""1074""
""twitter:card"",""summary_large_image""
""eprints.ispublished"",""pub""
""og:site_name"",""КиберЛенинка""
""keywords"",""научная статья бесплатно на тему Состояние и перспективы развития сферы туризма на территории Краснодарского края текст научной работы по экономике и бизнесу из научного журнала Вестник Академии знаний. ТУРИЗМ, САНАТОРНО-КУРОРТНЫЙ КОМПЛЕКС, ТУРИСТИЧЕСКИЙ КОМПЛЕКС, ТУРИСТИЧЕСКИЙ РЫНОК, TOURISM, SANATORIUM COMPLEX, TOURIST COMPLEX, TOURIST MARKET""
""eprints.pagerange"",""12-16""
""citation_journal_title"",""Вестник Академии знаний""
""eprints.publication"",""Вестник Академии знаний""
""language"",""ru""
""og:description"",""На современном этапе развития экономики страны значительное внимание уделяется государственной политике в сфере внутреннего и въездного туризма на территории Российской Федерации, при этом туризм рассматривается как существенная составляющая инновационного развития нашей страны. Краснодарский край является одним из значимых туристических регионов России. В данной статье авторами рассмотрены и кратко описаны специфические свойства сферы туризма, особенности туристического рынка. Сформулированы и наглядно представлены основные положения Концепции развития санаторно-курортного и туристского комплекса Краснодарского края на период до 2030 года, перечислены механизмы реализации данной Концепции. Авторами приведены некоторые результаты работы Министерства курортов, туризма и олимпийского наследия Краснодарского края по расширению предложений на рынке туристических услуг, повышению конкурентоспособности курортов региона, направленные на выполнение основных положений Концепции. Отмечено, что туристическая система региона зависит от ряда факторов экономического, социального, политического и иного характера.""
""eprints.full_text_status"",""public""
""citation_issn"",""2304-6139""
""dc:title"",""Состояние и перспективы развития сферы туризма на территории Краснодарского края – тема научной статьи по экономике и бизнесу читайте бесплатно текст научно-исследовательской работы в электронной библиотеке КиберЛенинка""
""eprints.place_of_pub"",""Россия, Краснодар""
""Content-Encoding"",""UTF-8""
""citation_pdf_url"",""https://cyberleninka.ru/article/n/sostoyanie-i-perspektivy-razvitiya-sfery-turizma-na-territorii-krasnodarskogo-kraya/pdf""
""robots"",""NOODP"",""noyaca""
""eprints.volume"",""""
""eprints.citation"",""Абазян А.Г., Хорольская Т.Е. Состояние и перспективы развития сферы туризма на территории Краснодарского края // Вестник Академии знаний. 2019. Выпуск номер 1 (30), С.12-16""
""eprints.number"",""1 (30)""
""citation_author"",""Абазян А.Г."",""Хорольская Т.Е.""
""resourceName"",""sostoyanie-i-perspektivy-razvitiya-sfery-turizma-na-territorii-krasnodarskogo-kraya""
""citation_abstract_html_url"",""https://cyberleninka.ru/article/n/sostoyanie-i-perspektivy-razvitiya-sfery-turizma-na-territorii-krasnodarskogo-kraya""
""citation_issue"",""1 (30)""
""eprints.abstract"",""At the present stage of development of the country's economy, considerable attention is paid to state policy in the sphere of domestic and inbound tourism in the territory of the Russian Federation, while tourism is considered as an essential component of the innovative development of our country. Krasnodar region is one of the most significant tourist regions of Russia. In this article, the authors reviewed and briefly described the specific properties of the tourism industry, especially the tourism market. The basic provisions of the Concept for the development of the sanatorium and resort and tourist complex of the Krasnodar Territory for the period up to 2030 are formulated and clearly presented, the mechanisms for the implementation of this Concept are listed. The authors present some results of the work of the Ministry of Resorts, Tourism and the Olympic Heritage of Krasnodar Territory in expanding offers in the tourist services market, increasing the competitiveness of resorts in the region, aimed at implementing the main provisions of the Concept. It is noted that the tourist system of the region depends on a number of economic, social, political and other factors."",""На современном этапе развития экономики страны значительное внимание уделяется государственной политике в сфере внутреннего и въездного туризма на территории Российской Федерации, при этом туризм рассматривается как существенная составляющая инновационного развития нашей страны. Краснодарский край является одним из значимых туристических регионов России. В данной статье авторами рассмотрены и кратко описаны специфические свойства сферы туризма, особенности туристического рынка. Сформулированы и наглядно представлены основные положения Концепции развития санаторно-курортного и туристского комплекса Краснодарского края на период до 2030 года, перечислены механизмы реализации данной Концепции. Авторами приведены некоторые результаты работы Министерства курортов, туризма и олимпийского наследия Краснодарского края по расширению предложений на рынке туристических услуг, повышению конкурентоспособности курортов региона, направленные на выполнение основных положений Концепции. Отмечено, что туристическая система региона зависит от ряда факторов экономического, социального, политического и иного характера.""
""eprints.eissn"",""2687-0983""
""citation_volume"",""""
""format-detection"",""telephone=no""
""citation_publication_date"",""2019""
""citation_title"",""Состояние и перспективы развития сферы туризма на территории Краснодарского края""
""eprints.date"",""2019""
""citation_publisher"",""Общество с ограниченной ответственностью «Академия знаний»""
""eprints.type"",""article""
""description"",""На современном этапе развития экономики страны значительное внимание уделяется государственной политике в сфере внутреннего и въездного туризма на территории Российской Федерации, при этом туризм рассматривается как существенная составляющая инновационного развития нашей страны. Краснодарский край является одним из значимых туристических регионов России. В данной статье авторами рассмотрены и кратко описаны специфические свойства сферы туризма, особенности туристического рынка. Сформулированы и наглядно представлены основные положения Концепции развития санаторно-курортного и туристского комплекса Краснодарского края на период до 2030 года, перечислены механизмы реализации данной Концепции. Авторами приведены некоторые результаты работы Министерства курортов, туризма и олимпийского наследия Краснодарского края по расширению предложений на рынке туристических услуг, повышению конкурентоспособности курортов региона, направленные на выполнение основных положений Концепции. Отмечено, что туристическая система региона зависит от ряда факторов экономического, социального, политического и иного характера.""
""title"",""Состояние и перспективы развития сферы туризма на территории Краснодарского края – тема научной статьи по экономике и бизнесу читайте бесплатно текст научно-исследовательской работы в электронной библиотеке КиберЛенинка""
""eprints.document_url"",""https://cyberleninka.ru/article/n/sostoyanie-i-perspektivy-razvitiya-sfery-turizma-na-territorii-krasnodarskogo-kraya""
""twitter:site"",""@CyberLeninka""
""citation_fulltext_html_url"",""https://cyberleninka.ru/article/n/sostoyanie-i-perspektivy-razvitiya-sfery-turizma-na-territorii-krasnodarskogo-kraya""
""eprints.keywords"",""ТУРИЗМ, САНАТОРНО-КУРОРТНЫЙ КОМПЛЕКС, ТУРИСТИЧЕСКИЙ КОМПЛЕКС, ТУРИСТИЧЕСКИЙ РЫНОК, TOURISM, SANATORIUM COMPLEX, TOURIST COMPLEX, TOURIST MARKET""
""Content-Type-Hint"",""text/html; charset=utf-8""
""eprints.publisher"",""Общество с ограниченной ответственностью «Академия знаний»""
""Content-Type"",""text/html; charset=UTF-8""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""og:type"",""article""
""eprints.title"",""Состояние и перспективы развития сферы туризма на территории Краснодарского края""
""og:title"",""Состояние и перспективы развития сферы туризма на территории Краснодарского края""
""og:image:height"",""480""
""eprints.creators_name"",""Абазян А.Г."",""Хорольская Т.Е.""
""eprints.date_type"",""published""
""viewport"",""width=device-width, initial-scale=1""
""apple-mobile-web-app-capable"",""yes""
""og:url"",""https://cyberleninka.ru/article/n/sostoyanie-i-perspektivy-razvitiya-sfery-turizma-na-territorii-krasnodarskogo-kraya""
""citation_eissn"",""2687-0983""
""eprints.metadata_visibility"",""show""
""eprints.refereed"",""TRUE""
""eprints.issn"",""2304-6139""
";https://scholar.google.com/scholar?start=700&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094630-1035;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[PDF][PDF] Democracy Through the Blocks: Towards the Era of Law Engineering.;B Distefano ; JURIX (Doctoral Consortium), 2019  pdfs.semanticscholar.org;;"… it is to be handled by a central authority that would serve as an Oracle, while some … won't be solved,

cross-protocol services will have to rely on off-chain Oracles — again, betraying … Wright, A., De

Filippi, P.: Decentralized Blockchain Technology and the Rise of Lex Cryptographia …";Autres articles;;[PDF] semanticscholar.org;https://pdfs.semanticscholar.org/e092/c0d8f560531d502713f56f6560da244fa215.pdf;;"""citation_publication_date"",""2019""
""og:image"",""https://www.semanticscholar.org/img/semantic_scholar_og.png""
""citation_title"",""Democracy Through the Blocks: Towards the Era of Law Engineering""
""og:image:width"",""1110""
""twitter:card"",""summary_large_image""
""msapplication-square70x70logo"",""https://cdn.semanticscholar.org/86e6c2539915adc9/img/mstile-70x70.png""
""citation_journal_title"",""undefined""
""description"",""As we enter the age of decentralization, technological and political tensions stress the fabric of modern Democracies. Understanding the theoretical and practical challenges that we will be forced to face is the focus of this project. From the technological choices and their implementations, passing through their political and philosophical consequences, a new path needs to be drawn in order to understand whether DLTs will fundamentally change the very concepts of eDemocracy and governance, or improve existing models.""
""msapplication-wide310x150logo"",""https://cdn.semanticscholar.org/86e6c2539915adc9/img/mstile-310x150.png""
""language"",""en""
""title"",""[PDF] Democracy Through the Blocks: Towards the Era of Law Engineering | Semantic Scholar""
""og:description"",""As we enter the age of decentralization, technological and political tensions stress the fabric of modern Democracies. Understanding the theoretical and practical challenges that we will be forced to face is the focus of this project. From the technological choices and their implementations, passing through their political and philosophical consequences, a new path needs to be drawn in order to understand whether DLTs will fundamentally change the very concepts of eDemocracy and governance, or improve existing models.""
""og:image:secure_url"",""https://www.semanticscholar.org/img/semantic_scholar_og.png"",""https://www.semanticscholar.org/img/semantic_scholar_og.png""
""twitter:image"",""https://www.semanticscholar.org/img/semantic_scholar_og.png"",""https://www.semanticscholar.org/img/semantic_scholar_og.png""
""twitter:site"",""@allenai_org""
""msapplication-square310x310logo"",""https://cdn.semanticscholar.org/86e6c2539915adc9/img/mstile-310x310.png""
""dc:title"",""[PDF] Democracy Through the Blocks: Towards the Era of Law Engineering | Semantic Scholar""
""Content-Encoding"",""UTF-8""
""citation_pdf_url"",""http://ceur-ws.org/Vol-2598/paper-02.pdf""
""robots"",""noarchive,noindex""
""Content-Type"",""text/html; charset=UTF-8""
""s2-ui-version"",""2cfb8f55a25a62a824f97b333bd41eb95e1e3822""
""application-name"","" ""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""twitter:title"",""[PDF] Democracy Through the Blocks: Towards the Era of Law Engineering | Semantic Scholar""
""og:type"",""website""
""og:title"",""[PDF] Democracy Through the Blocks: Towards the Era of Law Engineering | Semantic Scholar""
""citation_author"",""Biagio Distefano""
""og:image:height"",""582""
""resourceName"",""c0d8f560531d502713f56f6560da244fa215.pdf""
""msapplication-square150x150logo"",""https://cdn.semanticscholar.org/86e6c2539915adc9/img/mstile-150x150.png""
""msapplication-TileColor"",""#FFFFFF""
""viewport"",""width=device-width,initial-scale=1""
""twitter:description"",""As we enter the age of decentralization, technological and political tensions stress the fabric of modern Democracies. Understanding the theoretical and practical challenges that we will be forced to face is the focus of this project. From the technological choices and their implementations, passing through their political and philosophical consequences, a new path needs to be drawn in order to understand whether DLTs will fundamentally change the very concepts of eDemocracy and governance, or improve existing models.""
""og:locale"",""en_US"",""en_US""
""Content-Language"",""en""
""msapplication-TileImage"",""https://cdn.semanticscholar.org/86e6c2539915adc9/img/mstile-144x144.png""
";https://scholar.google.com/scholar?start=850&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094597-897;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Application of blockchain in collaborative Internet-of-Things services;L Da Xu, W Viriyasitavat ; IEEE Transactions on Computational …, 2019  ieeexplore.ieee.org;;"… It consists of three tasks that involve one Blockchain- based IoT system and sensors that

provide Oracle information about weather conditions, and one public cryptocurrency for

making payment. The process begins with check weather condition …";Cité 43 fois;;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/6570650/6780646/08718260.pdf?casa_token=K2mmhDA51hIAAAAA:gLlTMk0UWBAiPfZK3D5SpzMCiiYMMs_O8OM7vS5AvDpg8dl9Jf320-vv96pmsf4RVl51-f_Dfnw;;"""og:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""twitter:title"",""Application of Blockchain in Collaborative Internet-of-Things Services""
""twitter:card"",""summary""
""Description"",""Innovating business processes involves cutting-edge technologies where the Internet of Things (IoT) and Blockchain are technological breakthroughs. IoT is envis""
""og:title"",""Application of Blockchain in Collaborative Internet-of-Things Services""
""resourceName"",""08718260.pdf""
""language"",""en""
""title"",""Application of Blockchain in Collaborative Internet-of-Things Services | IEEE Journals & Magazine | IEEE Xplore""
""og:description"",""Innovating business processes involves cutting-edge technologies where the Internet of Things (IoT) and Blockchain are technological breakthroughs. IoT is envisioned as a global network infrastructure consisting of numerous connected devices over the Internet. Many attempts have been made to improve and adapt business workflows for best utilizing IoT services. One possible solution is to digitize and automate internal processes using IoT services, in which Blockchain smart contract is a viable solution to establish the trust of process executions without intermediaries. Modern business processes are composed of disparate services; many of them tend to be delivered based on IoT. Interoperating with such services poses major challenges: 1) time for finality settlement of transactions is unpredictable and usually experiencing delay; 2) several implementations of permissioned Blockchain pose a major concern of trust regarding nodes that perform consensus; and 3) trust of process executions and IoT information is the major factor to the success of modern business processes, which require the composition of distributed IoT services. Traditional business processes are mostly managed by a single entity, which induces the problem of trust of process executions. In this paper, a smart contract for establishing the trust of process executions that fits into the IoT environment is presented. A consensus approach with selected validators extended from Practical Byzantine Fault Tolerance (PBFT) is introduced to address time and prejudice challenges.""
""twitter:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-UA-Compatible"",""IE=Edge""
""viewport"",""width=device-width, initial-scale=1.0""
""dc:title"",""Application of Blockchain in Collaborative Internet-of-Things Services | IEEE Journals & Magazine | IEEE Xplore""
""twitter:description"",""Innovating business processes involves cutting-edge technologies where the Internet of Things (IoT) and Blockchain are technological breakthroughs. IoT is envisioned as a global network infrastructure consisting of numerous connected devices over the Internet. Many attempts have been made to improve and adapt business workflows for best utilizing IoT services. One possible solution is to digitize and automate internal processes using IoT services, in which Blockchain smart contract is a viable solution to establish the trust of process executions without intermediaries. Modern business processes are composed of disparate services; many of them tend to be delivered based on IoT. Interoperating with such services poses major challenges: 1) time for finality settlement of transactions is unpredictable and usually experiencing delay; 2) several implementations of permissioned Blockchain pose a major concern of trust regarding nodes that perform consensus; and 3) trust of process executions and IoT information is the major factor to the success of modern business processes, which require the composition of distributed IoT services. Traditional business processes are mostly managed by a single entity, which induces the problem of trust of process executions. In this paper, a smart contract for establishing the trust of process executions that fits into the IoT environment is presented. A consensus approach with selected validators extended from Practical Byzantine Fault Tolerance (PBFT) is introduced to address time and prejudice challenges.""
""Content-Encoding"",""UTF-8""
""Content-Type-Hint"",""text/html; charset=utf-8""
""Content-Length"",""43900""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=710&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094581-823;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[CITATION][C] An Adaptive Authentication Based on Blockchain for Bigdata Hadoop Framework;M Kankal, P Patil;;;null;Autres articles;;null;;;;https://scholar.google.com/scholar?start=640&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094628-1025;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[HTML][HTML] LAAP: Lightweight anonymous authentication protocol for D2D-Aided fog computing paradigm;P Gope ; computers & security, 2019  Elsevier;;"JavaScript is disabled on your browser. Please enable JavaScript to use all

the features on this page. Skip to main content Skip to article …";Cité 21 fois;Les 3 versions;[HTML] sciencedirect.com;https://www.sciencedirect.com/science/article/pii/S016740481831160X?casa_token=B6khVZImZ0EAAAAA:eEha7IdeA2Ibel8NOHOWuW_dNzRY0ZveLOjOG7l70vo18MoVI5aOsIhpBjwl7MvDlgBY1oND;;;https://scholar.google.com/scholar?start=840&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094614-970;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;One CPA's Journey from Auditor to Consultant and Fintech Entrepreneur;D Abdekalimi ; The CPA Journal, 2019  search.proquest.com;;"… There are some critics of blockchain technology, primarily as it relates to cryptocurrencies, but

I think it is important to be at the forefront of emerging technologies and … Despite their differences,

they were all transitioning to a new operating system (eg, Oracle, PeopleSoft, Workday …";;null;null;;;;https://scholar.google.com/scholar?start=780&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094565-760;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Greedy but cautious: Conditions for miner convergence to resource allocation equilibrium;G Bissias, BN Levine, D Thibodeau ; arXiv preprint arXiv:1907.09883, 2019  arxiv.org;;"… In some ways, cryptocurrency economics is a prosaic application of classic economic theory … the

allocation equilibrium in the real world, including: a trustless price-ratio oracle, increasing security …

and measuring the cost to miners who provide security to a blockchain beyond the …";Cité 7 fois;Les 3 versions;[PDF] arxiv.org;https://arxiv.org/pdf/1907.09883;;"""date"",""2019-08-27T01:04:59Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2019-08-27T01:04:59Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016) kpathsea version 6.2.2""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2019-08-27T01:04:59Z""
""created"",""2019-08-27T01:04:59Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-08-27T01:04:59Z""
""resourceName"",""1907.09883""
""Author"",""""
""producer"",""pdfTeX-1.40.17""
""pdf:docinfo:producer"",""pdfTeX-1.40.17""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""1"",""13"",""9"",""11"",""11"",""0"",""0"",""0"",""9"",""0"",""15"",""13"",""10"",""7"",""37"",""26"",""1"",""0"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2019-08-27T01:04:59Z""
""Last-Modified"",""2019-08-27T01:04:59Z""
""dcterms:modified"",""2019-08-27T01:04:59Z""
""title"",""""
""Last-Save-Date"",""2019-08-27T01:04:59Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2019-08-27T01:04:59Z""
""meta:save-date"",""2019-08-27T01:04:59Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016) kpathsea version 6.2.2""
""Content-Length"",""1005536""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""24""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""2006"",""2363"",""2855"",""2631"",""2202"",""1876"",""1710"",""2168"",""1958"",""2639"",""1658"",""2556"",""1334"",""2285"",""2359"",""1724"",""1908"",""1952"",""1573"",""2028"",""2759"",""1957"",""2521"",""201""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-08-27T01:04:59Z""
";https://scholar.google.com/scholar?start=570&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094597-894;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Prihodnost in inovacije celovitih informacijskih rešitev;S Matoh ;2019 dk.um.si;;"… ERP sisteme definirali, potem predstavili zgodovino razvoja in trenutnega stanja na trgu ERP

sistemov ter tri najbolj poznane ponudnike: SAP, Microsoft in Oracle … v Oblaku in v obliki

programske opreme kot storitve, kaj je to Dvo-Tirni ERP sistem ter kaj je Blockchain in kako se …";Autres articles;En cache;null;;;;https://scholar.google.com/scholar?start=710&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094605-930;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;SO-CCA secure PKE in the quantum random oracle model or the quantum ideal cipher model;S Sato, J Shikata ; IMA International Conference on Cryptography and …, 2019  Springer;;"… On the other hand, we consider the model where adversaries can submit quantum

superposition queries (ie, quantum queries) to oracles. In particular, secure cryptosystems

in the quantum random oracle model (QROM) have been intensively studied …";Cité 1 fois;;null;;;;https://scholar.google.com/scholar?start=740&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094590-865;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;A review of blockchain architecture and consensus protocols: Use cases, challenges, and solutions;L Ismail, H Materwala ; Symmetry, 2019  mdpi.com;;"… 3. Blockchain: An Architecture Perspective. In this section, we describe a layered

overview of blockchain and explain how a transaction data is processed. We …

blockchains. 4. Evolution and Taxonomy of Blockchain Architectures …";Cité 33 fois;Les 8 versions;[PDF] mdpi.com;https://www.mdpi.com/2073-8994/11/10/1198/pdf;;;https://scholar.google.com/scholar?start=680&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094642-1085;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Privacy-preserving tax-case processing;EK Lund, M Nowostawski, A Satybaldy… ; … on Privacy, Security …, 2019  ieeexplore.ieee.org;;"… Then we have two plausible design choices: – Use an oracle to fetch data outside the

walled garden a blockchain impose. Where an oracle is a smart contract, which have

implemented the required func- tions to pull content off the Internet …";Autres articles;;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/8937293/8949011/08949072.pdf?casa_token=V0yLES2LoRMAAAAA:JgUkrX1o-5_Ob-O9Q3sU-CT28j-CKnBg3mF1IxCoJHvJ5kEqPUgq6o1nu-Nhwhe-EIXKW_OwkZ4;;"""og:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""twitter:title"",""Privacy-preserving tax-case processing""
""twitter:card"",""summary""
""Description"",""Tax-case processing is based on a classification of common taxable conditions, e.g. retirement benefits, social security benefits, income brackets. Based on tho""
""og:title"",""Privacy-preserving tax-case processing""
""resourceName"",""08949072.pdf""
""language"",""en""
""title"",""Privacy-preserving tax-case processing | IEEE Conference Publication | IEEE Xplore""
""og:description"",""Tax-case processing is based on a classification of common taxable conditions, e.g. retirement benefits, social security benefits, income brackets. Based on those, groups of people fall under certain categorizations and should be treated equally. However, to maintain privacy, people from the same group might be handled anonymously by different case handlers. Consequently, tax-case processing for different individuals from the same group categorization may end up with different results, depending on the region in which the case is dealt with and which case manager treats the given case. This situation maintain privacy but violates fairness. On the other hand, some of the tax calculation is personal since there is no isolation between the taxable conditions data and the individual data. Often, taxable data provides personally identifiable queues. Furthermore, tax processing cannot take advantage of previous tax-case processing that has been already conducted; thus, reducing the system's overall efficiency for cases that has been already processed. To improve efficiency and transparency of the taxation process, we have investigated and explored architectural designs for privacy-preserving tax-case processing prototypes with the use of blockchain technology. In this article, we provide an overview of the available technologies, classify the architecture, and discuss a proof-of-concept implementation that can facilitate those goals. Based on the findings, a number of frameworks is considered and a proof-of-concept is made to showcase the design intent. We established, that in some cases it is possible to use blockchain technology for tax-case processing to enhance the privacy and improving the transparency at the same time.""
""twitter:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-UA-Compatible"",""IE=Edge""
""viewport"",""width=device-width, initial-scale=1.0""
""dc:title"",""Privacy-preserving tax-case processing | IEEE Conference Publication | IEEE Xplore""
""twitter:description"",""Tax-case processing is based on a classification of common taxable conditions, e.g. retirement benefits, social security benefits, income brackets. Based on those, groups of people fall under certain categorizations and should be treated equally. However, to maintain privacy, people from the same group might be handled anonymously by different case handlers. Consequently, tax-case processing for different individuals from the same group categorization may end up with different results, depending on the region in which the case is dealt with and which case manager treats the given case. This situation maintain privacy but violates fairness. On the other hand, some of the tax calculation is personal since there is no isolation between the taxable conditions data and the individual data. Often, taxable data provides personally identifiable queues. Furthermore, tax processing cannot take advantage of previous tax-case processing that has been already conducted; thus, reducing the system's overall efficiency for cases that has been already processed. To improve efficiency and transparency of the taxation process, we have investigated and explored architectural designs for privacy-preserving tax-case processing prototypes with the use of blockchain technology. In this article, we provide an overview of the available technologies, classify the architecture, and discuss a proof-of-concept implementation that can facilitate those goals. Based on the findings, a number of frameworks is considered and a proof-of-concept is made to showcase the design intent. We established, that in some cases it is possible to use blockchain technology for tax-case processing to enhance the privacy and improving the transparency at the same time.""
""Content-Encoding"",""UTF-8""
""Content-Type-Hint"",""text/html; charset=utf-8""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=900&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094647-1104;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[PDF][PDF] Quantum Threats to Blockchain Based On A Review of Simulations;L Westfall, J Koller, W Klingensmith, F Russo… ; csis.pace.edu;;"… The completion of any block is rewarded with percentages of cryptocurrency units (ie, a percentage …

Work (dPoW) is when notarizing smart contracts are created in the blocks on the blockchain … Such

a function utilizes the same iterative approach as an oracle function, which is so …";Autres articles;Version HTML;[PDF] pace.edu;http://csis.pace.edu/~ctappert/srd2020/a9.pdf;;"""date"",""2020-05-08T03:43:22Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""7"",""16"",""1"",""0"",""0""
""pdf:PDFVersion"",""1.5""
""xmp:CreatorTool"",""TeX""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dcterms:created"",""2019-12-06T04:09:28Z""
""language"",""en""
""Last-Modified"",""2020-05-08T03:43:22Z""
""dcterms:modified"",""2020-05-08T03:43:22Z""
""dc:format"",""application/pdf; version=1.5""
""xmpMM:DocumentID"",""uuid:758252fb-31b5-4d58-bdd7-ba8ba4a936a5""
""Last-Save-Date"",""2020-05-08T03:43:22Z""
""pdf:docinfo:creator_tool"",""TeX""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2020-05-08T03:43:22Z""
""meta:save-date"",""2020-05-08T03:43:22Z""
""pdf:encrypted"",""false""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017) kpathsea version 6.2.3""
""xmp:CreateDate"",""2019-12-06T04:09:28Z""
""modified"",""2020-05-08T03:43:22Z""
""Content-Length"",""339876""
""pdf:hasMarkedContent"",""false""
""Content-Type"",""application/pdf""
""xmp:ModifyDate"",""2020-05-07T23:43:22Z""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017) kpathsea version 6.2.3""
""xmp:MetadataDate"",""2020-05-07T23:43:22Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""pdf:producer"",""pdfTeX-1.40.18""
""trapped"",""False""
""meta:creation-date"",""2019-12-06T04:09:28Z""
""created"",""2019-12-06T04:09:28Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""7""
""Creation-Date"",""2019-12-06T04:09:28Z""
""resourceName"",""a9.pdf""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""4614"",""4415"",""4885"",""3677"",""3026"",""5228"",""394""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""producer"",""pdfTeX-1.40.18""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""pdfTeX-1.40.18""
""pdf:docinfo:created"",""2019-12-06T04:09:28Z""
";https://scholar.google.com/scholar?start=920&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094581-821;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;How smart can a contract be?;B Carron, V Botteron ; Blockchains, Smart Contracts …, 2019  elgaronline.com;;"… information, such as the occurrence of an event, which is triggered by circumstances outside

the blockchain. That is the purpose of the so-called oracles, which are sensors in the physical …

Example: In order to illustrate the role of an oracle, consider the previous example and …";Cité 7 fois;Les 3 versions;[PDF] researchgate.net;https://www.researchgate.net/profile/Blaise_Carron/publication/337905936_5_How_smart_can_a_contract_be/links/5df1ecdb92851c836475f7f4/5-How-smart-can-a-contract-be.pdf;;;https://scholar.google.com/scholar?start=640&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094548-683;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[PDF][PDF] From the blockchain technology to the token economy;MN Pacheco Jimenez ; Derecho PUCP, 2019  HeinOnline;;"… una inversión de dinero, pudiendo emitirse por un acto de Ťmineríať o como una recompensa

por haber participado en tecnología blockchain, por lo … un sitio web que funciona como un asistente

de test de Howey para tokens y proyectos criptográficos (https:lhowey.oracles.org …";Cité 1 fois;;[PDF] heinonline.org;https://heinonline.org/hol-cgi-bin/get_pdf.cgi?handle=hein.journals/derecho83&section=6&casa_token=k4kha_10xCIAAAAA:OWAdBq1reh18Ch7ALABfVr8k0erpY-kdlgKf-sRV1J-R8EPGKZWqgN2YRqrX6WRWGpDmctg;;"""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""REFRESH"",""1; url=https://heinonline.org/HOL/Page?handle=hein.journals/derecho83&div=6&g_sent=1&casa_token=k4kha_10xCIAAAAA:OWAdBq1reh18Ch7ALABfVr8k0erpY-kdlgKf-sRV1J-R8EPGKZWqgN2YRqrX6WRWGpDmctg""
""Content-Encoding"",""UTF-8""
""resourceName"",""get_pdf.cgi""
""language"",""""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=500&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094574-792;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[CITATION][C] Fully regulatable privacy-preserving blockchains against malicious regulators;LC Wulu Li, X Lai, X Zhang, J Xin;;;null;Autres articles;;null;;;;https://scholar.google.com/scholar?start=610&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094539-643;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;FSCBlock: Designing financial smart contracts on permissioned and public blockchains;M Vinayak ;2019 mspace.lib.umanitoba.ca;;"… it to the smart contracts when requested. Oraclize Oraclize is one of the oracles that provides

data to different Blockchain platforms including Ethereum. oracles An oracle is a service through

which the external world data can be fetched into the contract …";Autres articles;Version HTML;[PDF] umanitoba.ca;https://mspace.lib.umanitoba.ca/bitstream/handle/1993/33825/Vinayak_Muskan.pdf?sequence=1;;"""date"",""2019-04-01T22:56:46Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""FSCBlock: Designing Financial Smart Contracts on Permissioned and Public Blockchains""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""FSCBlock: Designing Financial Smart Contracts on Permissioned and Public Blockchains""
""modified"",""2019-04-01T22:56:46Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""Muskan Vinayak""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017) kpathsea version 6.2.3""
""meta:author"",""Muskan Vinayak""
""trapped"",""False""
""meta:creation-date"",""2019-04-01T22:56:46Z""
""created"",""2019-04-01T22:56:46Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-04-01T22:56:46Z""
""resourceName"",""Vinayak_Muskan.pdf""
""Author"",""Muskan Vinayak""
""producer"",""pdfTeX-1.40.18""
""pdf:docinfo:producer"",""pdfTeX-1.40.18""
""pdf:unmappedUnicodeCharsPerPage"",""1"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""Muskan Vinayak""
""dcterms:created"",""2019-04-01T22:56:46Z""
""Last-Modified"",""2019-04-01T22:56:46Z""
""dcterms:modified"",""2019-04-01T22:56:46Z""
""title"",""FSCBlock: Designing Financial Smart Contracts on Permissioned and Public Blockchains""
""Last-Save-Date"",""2019-04-01T22:56:46Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2019-04-01T22:56:46Z""
""meta:save-date"",""2019-04-01T22:56:46Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017) kpathsea version 6.2.3""
""Content-Length"",""2803047""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Muskan Vinayak""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""86""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""339"",""1087"",""1276"",""429"",""1291"",""72"",""1418"",""289"",""82"",""0"",""760"",""834"",""221"",""1011"",""1592"",""1493"",""1551"",""1610"",""1232"",""1501"",""771"",""1260"",""1311"",""1417"",""1324"",""1124"",""1400"",""1453"",""1498"",""1331"",""1502"",""1595"",""1353"",""1325"",""1443"",""1538"",""1395"",""1598"",""1291"",""1441"",""1297"",""1428"",""1281"",""880"",""1659"",""1492"",""218"",""629"",""1606"",""882"",""713"",""648"",""422"",""1285"",""1586"",""472"",""1417"",""1070"",""77"",""608"",""1176"",""345"",""444"",""263"",""233"",""396"",""1359"",""927"",""418"",""732"",""660"",""552"",""307"",""908"",""1282"",""954"",""366"",""830"",""1161"",""1203"",""1284"",""1086"",""1089"",""1249"",""1109"",""1037""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-04-01T22:56:46Z""
";https://scholar.google.com/scholar?start=460&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094623-1007;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[PDF][PDF] Comparative Study of Block Chain and Artificial Intelligence Metrics to Provide Security and Privacy for the Growth of Organizations;RV Lakshmi ;2019 academia.edu;;"… one of the largest crowd-funding groups with 150 million of a crypto currency called … Our literature

review shows that adopting AI for blockchain applications is still in its early … and tackled in areas

related to privacy, smart contract security, trusted oracles, scalability, standardization …";Autres articles;;[PDF] academia.edu;https://www.academia.edu/download/61630030/V8I1220190320191229-79511-ufu2n7.pdf;;;https://scholar.google.com/scholar?start=820&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094614-962;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Bootstrapping a stable computation token;J Teutsch, S Mäkelä, S Bakshi ; arXiv preprint arXiv:1908.02946, 2019  arxiv.org;;"… for TRU and CPU tokens neither appeal to external price oracles nor exchanges … the development

team chooses relevant tokens XYZ on the same blockchain as Truebit … We enumerate the DAO

token's crypto-idiosyncratic features which resemble the independent, concurrent …";Cité 1 fois;Les 7 versions;[PDF] arxiv.org;https://arxiv.org/pdf/1908.02946;;"""date"",""2019-08-09T03:04:11Z""
""pdf:PDFVersion"",""1.4""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.4""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""xmp:CreateDate"",""2019-08-08T23:04:11Z""
""modified"",""2019-08-09T03:04:11Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""xmp:ModifyDate"",""2019-08-08T23:04:11Z""
""pdf:docinfo:creator"",""""
""meta:author"",""""
""meta:creation-date"",""2019-08-09T03:04:11Z""
""created"",""2019-08-09T03:04:11Z""
""xmp:About"",""uuid:e90de0ce-f26e-11f4-0000-d09679a14486""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-08-09T03:04:11Z""
""resourceName"",""1908.02946""
""Author"",""""
""producer"",""dvips + GPL Ghostscript GIT PRERELEASE 9.22""
""pdf:docinfo:producer"",""dvips + GPL Ghostscript GIT PRERELEASE 9.22""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""3"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2019-08-09T03:04:11Z""
""Last-Modified"",""2019-08-09T03:04:11Z""
""dcterms:modified"",""2019-08-09T03:04:11Z""
""title"",""""
""xmpMM:DocumentID"",""uuid:e90de0ce-f26e-11f4-0000-d09679a14486""
""Last-Save-Date"",""2019-08-09T03:04:11Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2019-08-09T03:04:11Z""
""meta:save-date"",""2019-08-09T03:04:11Z""
""Content-Length"",""191834""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""20""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""1400"",""2468"",""2207"",""1096"",""2209"",""1799"",""2008"",""2047"",""2160"",""1559"",""1952"",""2099"",""1964"",""604"",""1672"",""1929"",""2016"",""1694"",""1652"",""1205""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-08-09T03:04:11Z""
";https://scholar.google.com/scholar?start=780&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094665-1181;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Emerging Solutions for the Improvement of Food Traceability in the EU: Examining the Use of Blockchain Technology for Tracing Extra Virgin Olive Oil (EVOO);OA BUTTAFOCO ;2019 divaportal.org;;"… point focused on the Bitcoin cryptocurrency, whereas less than 20% addressed other

blockchain applications.26 Though most authors continue to classify blockchain

literature according to a 'financial/non- financial' division27 …";Autres articles;Version HTML;[PDF] diva-portal.org;https://www.diva-portal.org/smash/get/diva2:1347063/FULLTEXT01.pdf;;"""date"",""2019-08-29T20:33:35Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.3""
""pdf:docinfo:title"",""Microsoft Word - MA_THESIS_OB_FINAL.docx""
""xmp:CreatorTool"",""Word""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dcterms:created"",""2019-08-29T20:33:35Z""
""language"",""en""
""Last-Modified"",""2019-08-29T20:33:35Z""
""dcterms:modified"",""2019-08-29T20:33:35Z""
""dc:format"",""application/pdf; version=1.3""
""title"",""Microsoft Word - MA_THESIS_OB_FINAL.docx""
""Last-Save-Date"",""2019-08-29T20:33:35Z""
""pdf:docinfo:creator_tool"",""Word""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2019-08-29T20:33:35Z""
""meta:save-date"",""2019-08-29T20:33:35Z""
""pdf:encrypted"",""false""
""dc:title"",""Microsoft Word - MA_THESIS_OB_FINAL.docx""
""modified"",""2019-08-29T20:33:35Z""
""Content-Length"",""1983416""
""pdf:hasMarkedContent"",""false""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""meta:creation-date"",""2019-08-29T20:33:35Z""
""created"",""2019-08-29T20:33:35Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""94""
""Creation-Date"",""2019-08-29T20:33:35Z""
""resourceName"",""FULLTEXT01.pdf""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""710"",""1097"",""2417"",""5244"",""2739"",""3433"",""3213"",""2836"",""3187"",""3600"",""2168"",""3005"",""1437"",""3122"",""2645"",""2744"",""3135"",""2585"",""3474"",""2535"",""2000"",""3499"",""2994"",""2093"",""860"",""2325"",""3007"",""3211"",""3136"",""2673"",""2835"",""2653"",""2910"",""2283"",""3243"",""3054"",""2908"",""2981"",""1334"",""2356"",""2671"",""3058"",""3420"",""3054"",""2879"",""1628"",""2165"",""2344"",""3192"",""3398"",""2392"",""1995"",""2418"",""2971"",""3092"",""3413"",""2491"",""2662"",""3200"",""2836"",""3044"",""1636"",""3181"",""3335"",""3252"",""3226"",""3695"",""3210"",""2838"",""3019"",""3218"",""1880"",""337"",""958"",""3071"",""2889"",""2991"",""2556"",""3220"",""662"",""2599"",""2791"",""2651"",""2751"",""2793"",""2732"",""2698"",""2587"",""2481"",""2690"",""2487"",""2471"",""2165"",""494""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""producer"",""Mac OS X 10.10.5 Quartz PDFContext""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""Mac OS X 10.10.5 Quartz PDFContext""
""pdf:docinfo:created"",""2019-08-29T20:33:35Z""
";https://scholar.google.com/scholar?start=420&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094616-976;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;PDFS: practical data feed service for smart contracts;J Guarnizo, P Szalachowski ; European Symposium on Research in …, 2019  Springer;;"… the Intel's Software Guard Extensions (SGX) [15] framework, which allows proving attestation

of the code executed by the oracles … PDFS, a practical data feed service for smart contracts that

aims to fill the gap between oracle solutions and … 2.1 Blockchain and Smart Contracts …";Cité 15 fois;Les 3 versions;[PDF] arxiv.org;https://arxiv.org/pdf/1808.06641;;"""date"",""2019-06-28T03:05:41Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2019-06-28T03:05:41Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016) kpathsea version 6.2.2""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2019-06-28T03:05:41Z""
""created"",""2019-06-28T03:05:41Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-06-28T03:05:41Z""
""resourceName"",""1808.06641""
""Author"",""""
""producer"",""pdfTeX-1.40.17""
""pdf:docinfo:producer"",""pdfTeX-1.40.17""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""1"",""0"",""0"",""0"",""0"",""4"",""0"",""0"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2019-06-28T03:05:41Z""
""Last-Modified"",""2019-06-28T03:05:41Z""
""dcterms:modified"",""2019-06-28T03:05:41Z""
""title"",""""
""Last-Save-Date"",""2019-06-28T03:05:41Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2019-06-28T03:05:41Z""
""meta:save-date"",""2019-06-28T03:05:41Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016) kpathsea version 6.2.2""
""Content-Length"",""807803""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""20""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""2412"",""2976"",""2852"",""2846"",""2671"",""3050"",""2709"",""2828"",""2714"",""2351"",""2454"",""2950"",""2755"",""2699"",""3079"",""2935"",""2797"",""2830"",""2918"",""2263""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-06-28T03:05:41Z""
";https://scholar.google.com/scholar?start=790&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094595-888;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Are smart contracts and blockchains suitable for decentralized railway control?;M Kuperberg, D Kindler, S Jeschke ; arXiv preprint arXiv:1901.06236, 2019  arxiv.org;;"… Note that for our architecture, there is no need for separate “oracles” that supply externally … and

on the contents of such M2M communication; strictly speaking, the blockchain and its … This is

encouraged by the native (crypto-) currency capabilities and token concepts of the …";Cité 6 fois;Les 7 versions;[PDF] arxiv.org;https://arxiv.org/pdf/1901.06236;;"""date"",""2019-01-17T16:04:29Z""
""pdf:PDFVersion"",""1.7""
""xmp:CreatorTool"",""MicrosoftÂŽ Word 2019""
""pdf:docinfo:title"",""Are Smart Contracts and Blockchains Suitable for Decentralized Railway Control?""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""Blockchain-based railway control;DLT;Stellwerk;Interlocking"",""Blockchain-based railway control;DLT;Stellwerk;Interlocking""
""pdfa:PDFVersion"",""A-3b""
""language"",""en""
""dc:format"",""application/pdf; version=""""A-3b"""""",""application/pdf; version=1.7""
""pdf:docinfo:creator_tool"",""MicrosoftÂŽ Word 2019""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""Are Smart Contracts and Blockchains Suitable for Decentralized Railway Control?""
""xmp:CreateDate"",""2019-01-17T17:04:29Z""
""modified"",""2019-01-17T16:04:29Z""
""pdf:hasMarkedContent"",""true""
""xmp:ModifyDate"",""2019-01-17T17:04:29Z""
""pdf:docinfo:creator"",""Michael.Kuperberg@deutschebahn.com""
""meta:author"",""Michael.Kuperberg@deutschebahn.com""
""meta:creation-date"",""2019-01-17T16:04:29Z""
""created"",""2019-01-17T16:04:29Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-01-17T16:04:29Z""
""resourceName"",""1901.06236""
""pdfaid:part"",""3""
""Author"",""Michael.Kuperberg@deutschebahn.com""
""producer"",""MicrosoftÂŽ Word 2019""
""pdf:docinfo:producer"",""MicrosoftÂŽ Word 2019""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""Keywords"",""Blockchain-based railway control;DLT;Stellwerk;Interlocking"",""Blockchain-based railway control;DLT;Stellwerk;Interlocking""
""access_permission:modify_annotations"",""true""
""dc:creator"",""Michael.Kuperberg@deutschebahn.com""
""dcterms:created"",""2019-01-17T16:04:29Z""
""Last-Modified"",""2019-01-17T16:04:29Z""
""dcterms:modified"",""2019-01-17T16:04:29Z""
""title"",""Are Smart Contracts and Blockchains Suitable for Decentralized Railway Control?""
""xmpMM:DocumentID"",""uuid:14AF1AB8-3C91-4AF1-897C-8C0B85AB0258""
""Last-Save-Date"",""2019-01-17T16:04:29Z""
""pdf:docinfo:keywords"",""Blockchain-based railway control;DLT;Stellwerk;Interlocking""
""pdf:docinfo:modified"",""2019-01-17T16:04:29Z""
""meta:save-date"",""2019-01-17T16:04:29Z""
""Content-Length"",""906431""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Michael.Kuperberg@deutschebahn.com""
""pdfaid:conformance"",""B""
""dc:language"",""en-US""
""pdf:producer"",""MicrosoftÂŽ Word 2019""
""dc:subject"",""Blockchain-based railway control;DLT;Stellwerk;Interlocking"",""Blockchain-based railway control;DLT;Stellwerk;Interlocking""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""16""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""3178"",""3767"",""2062"",""3569"",""2516"",""2353"",""3425"",""1893"",""3429"",""1304"",""3553"",""3881"",""3517"",""2586"",""2708"",""2009""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""meta:keyword"",""Blockchain-based railway control;DLT;Stellwerk;Interlocking"",""Blockchain-based railway control;DLT;Stellwerk;Interlocking""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-01-17T16:04:29Z""
";https://scholar.google.com/scholar?start=700&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094560-731;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Dependable data sharing in dynamic IoT-systems: subject-oriented process design, complex event processing, and blockchains;A Fleischmann, C Stary ; … of the 11th International Conference on …, 2019  dl.acm.org;;"… In hyper ledger fabric (including Ethereum), this problem is solved by so called oracles.

We suggest using the blockchain patterns Oracle and Reverse Oracle as described in

[23]. For flexibility reasons we prefer off chain oracles – see Figure 9 …";Cité 2 fois;Les 2 versions;[PDF] acm.org;https://dl.acm.org/doi/pdf/10.1145/3329007.3329009?casa_token=pMSADmZwxWMAAAAA:vlh5XKD_16ZLlU3XWUf23jQW7kC2DenWNb-wxcjc2cW7KvfzVPcPs04E0Jaj8_i74oSZsVi_3k4;;;https://scholar.google.com/scholar?start=550&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094640-1079;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Secure communication channel establishment: TLS 1.3 (over TCP fast open) vs. QUIC;S Chen, S Jero, M Jagielski, A Boldyreva… ; … on Research in …, 2019  Springer;;"… packet integrity, secure channel header integrity, and reset authentication, which capture a range

of practical threats not usually taken into account by existing security models that focus mainly

on the crypto cores of … client) oracle if and only if both session oracles observe the …";Cité 11 fois;Les 6 versions;[PDF] iacr.org;https://eprint.iacr.org/2019/433.pdf;;"""date"",""2020-11-27T16:14:38Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2020-11-27T16:14:38Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.16 (TeX Live 2015) kpathsea version 6.2.1""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2020-11-27T16:14:38Z""
""created"",""2020-11-27T16:14:38Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-11-27T16:14:38Z""
""resourceName"",""433.pdf""
""Author"",""""
""producer"",""pdfTeX-1.40.16""
""pdf:docinfo:producer"",""pdfTeX-1.40.16""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""27"",""0"",""0"",""0"",""0"",""0"",""15"",""2"",""0"",""0"",""5"",""8"",""2"",""1"",""1"",""27"",""4"",""7"",""0"",""0"",""7"",""6"",""1"",""0"",""0"",""0"",""0"",""3"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2020-11-27T16:14:38Z""
""Last-Modified"",""2020-11-27T16:14:38Z""
""dcterms:modified"",""2020-11-27T16:14:38Z""
""title"",""""
""Last-Save-Date"",""2020-11-27T16:14:38Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2020-11-27T16:14:38Z""
""meta:save-date"",""2020-11-27T16:14:38Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.16 (TeX Live 2015) kpathsea version 6.2.1""
""Content-Length"",""625285""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""33""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""2705"",""3856"",""3461"",""3302"",""3120"",""2616"",""4009"",""3330"",""2679"",""2845"",""3419"",""3584"",""3546"",""3760"",""3015"",""3412"",""3259"",""3152"",""2735"",""2803"",""3639"",""3588"",""3781"",""3436"",""3768"",""3563"",""2816"",""3510"",""3367"",""3073"",""2948"",""4099"",""666""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-11-27T16:14:38Z""
";https://scholar.google.com/scholar?start=890&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094647-1109;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Algorithms for a Smart Construction Environment;P Kochovski, V Stankovski ; … Symposium on Algorithmic Aspects of Cloud …, 2019  Springer;;"… A Smart Oracle is a mechanism that can provide tamper-proof off-blockchain data to Smart

Contracts, which can … 8. Kochovski, P., Gec, S., Stankovski, V., Bajec, M., Drobintsev, PD: Trust

management in a blockchain based fog computing platform with trustless smart oracles …";Autres articles;;null;;;;https://scholar.google.com/scholar?start=920&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094633-1044;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;The Cryptoeconomics of Cities, Data and Space;DWE Allen, C Berg, K Jowett, M Novak… ; Allen, DWE, Berg, C …, 2019  papers.ssrn.com;;"… These oracles can also enable dynamic adjustment of shipping routes and prioritisation based

on … Proof-of-location protocols provide data (or oracle) services to prove in a digital … Together with

blockchain technology for the recording of information, proof-of- location protocols …";Autres articles;;null;;;;https://scholar.google.com/scholar?start=860&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094642-1084;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[PDF][PDF] On the Power of Security Reduction in the Quantum-accessible Random Oracle Model;J Lee, K Kim ; … on Cryptography and Information Security (SCIS …, 2019  caislab.kaist.ac.kr;;"… of R, then the distribution of any quantum algorithm that makes q queries to a random oracle

has distance at most 8 3 q4?2 from the distribution generated when SC?,y is used instead. Using

the above technique regarding indistinguishabil- ity of oracles against quantum …";Autres articles;;[PDF] kaist.ac.kr;http://caislab.kaist.ac.kr/publication/paper_files/2019/SCIS%202019%20JU%20final.pdf;;"""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""dc:title"",""301 Moved Permanently""
""Content-Encoding"",""ISO-8859-1""
""resourceName"",""SCIS%202019%20JU%20final.pdf""
""language"",""en""
""Content-Length"",""293""
""title"",""301 Moved Permanently""
""Content-Type"",""text/html; charset=ISO-8859-1""
";https://scholar.google.com/scholar?start=900&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094609-943;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[PDF][PDF] Secure Smart Contract Generation based on Petri Nets;M Sauer ; researchgate.net;;"… In particular, we see that in many blockchain use cases we need external information and this

can be provided into the Petri Nets model via Oracle places; in … We explain in detail about how

we use oracles, transitions extended with guarded commands and other Petri Nets …";Autres articles;Version HTML;[PDF] researchgate.net;https://www.researchgate.net/profile/Prabhakaran_Kasinathan/publication/338358356_Secure_Smart_Contract_Generation_Based_on_Petri_Nets/links/5e941058a6fdcca78911b458/Secure-Smart-Contract-Generation-Based-on-Petri-Nets.pdf;;;https://scholar.google.com/scholar?start=760&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094651-1121;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Proofs of replicated storage without timing assumptions;I Damgĺrd, C Ganesh, C Orlandi ; Annual International Cryptology …, 2019  Springer;;"… 803096 (SPEC); Concordium Blockchain Research Center, Aarhus University, Denmark … a

14-round Feistel network where the round functions are independent random oracles is

indifferentiable … a Feistel network appears like a plausible way of instantiating the oracle we need …";Cité 10 fois;Les 3 versions;[PDF] iacr.org;https://eprint.iacr.org/2018/654.pdf;;"""date"",""2019-06-29T17:15:13Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2019-06-29T17:15:13Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017) kpathsea version 6.2.3""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2019-06-29T17:15:13Z""
""created"",""2019-06-29T17:15:13Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-06-29T17:15:13Z""
""resourceName"",""654.pdf""
""Author"",""""
""producer"",""pdfTeX-1.40.18""
""pdf:docinfo:producer"",""pdfTeX-1.40.18""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""1"",""0"",""0"",""8"",""7"",""1"",""1"",""8"",""4"",""0"",""3"",""9"",""1"",""2"",""16"",""3"",""1"",""0"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2019-06-29T17:15:13Z""
""Last-Modified"",""2019-06-29T17:15:13Z""
""dcterms:modified"",""2019-06-29T17:15:13Z""
""title"",""""
""Last-Save-Date"",""2019-06-29T17:15:13Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2019-06-29T17:15:13Z""
""meta:save-date"",""2019-06-29T17:15:13Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017) kpathsea version 6.2.3""
""Content-Length"",""363515""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""24""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""2494"",""3226"",""2996"",""3236"",""3031"",""2394"",""2078"",""2188"",""1509"",""1344"",""2595"",""2115"",""1990"",""3101"",""880"",""2767"",""1784"",""2195"",""2334"",""1921"",""3156"",""2415"",""2317"",""1386""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-06-29T17:15:13Z""
";https://scholar.google.com/scholar?start=940&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094665-1177;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[CITATION][C] Digital transformation: blockchain and land titles;G Eder ; Proceedings of the OECD Global AntiCorruption & …, 2019;;null;Cité 18 fois;;null;;;;https://scholar.google.com/scholar?start=420&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094560-740;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;"???????? ????????-???????"" ??????"" ? ?????????????? ???????????? ? ?????-?????????? ? ???????????????? ??????? ?? ??????? ??????????? …";?? ???????, ?? ???????? ; ????????? ? ??????????: ???????? …, 2019  elibrary.ru;;"… THE DEVELOPMENT OF BLOCKCHAIN-PROJECT ""DIAMONDS"" WITH CRYPTOCURRENCY

AND SMART CONTRACTS IN THE … virtual and real layers of the system, the choice of crypto

currency, the … smart contract, the efficiency of application of the studied blockchain system …";Cité 2 fois;;null;;;;https://scholar.google.com/scholar?start=550&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094593-877;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Acceptable Privacy for XAND Blockchain;DR Chawdhuri, J Kramer… ; 2019 Sixth International …, 2019  ieeexplore.ieee.org;;"… Acceptable Privacy for XAND Blockchain … Note that XAND is a fiat-backed crypto-currency, so

it already has got some level of centralization … ?u, Pr[(m, S,?) ? P (S1,S2, ..., Su,?1,?2, ..., ?u);

S /? {S1,S2, ..., Su} ? V(?, m, S) = true] = ? where P calls the random oracle Q times …";Autres articles;;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/8924808/8939160/08939262.pdf?casa_token=qQWiQ5IUktgAAAAA:FnQFvDzcv8yWTRzFPgUK1FBNRMQK2f2YWBj6cYxXl2eQFQy4bVBtTI1zCPj6t0z7_9UqqXSamgI;;"""og:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""twitter:title"",""Acceptable Privacy for XAND Blockchain""
""twitter:card"",""summary""
""Description"",""Recently, the privacy of blockchain transactions has taken center stage. Privacy is an essential feature of crypto-transactions. We have seen privacy-preserving""
""og:title"",""Acceptable Privacy for XAND Blockchain""
""resourceName"",""08939262.pdf""
""language"",""en""
""title"",""Acceptable Privacy for XAND Blockchain | IEEE Conference Publication | IEEE Xplore""
""og:description"",""Recently, the privacy of blockchain transactions has taken center stage. Privacy is an essential feature of crypto-transactions. We have seen privacy-preserving cryptocurrencies like Monero with Cryptonote protocol and Zerocash with Zk-SNARKs. However, the privacy of transactions comes at the cost of the transactions not being visible at all to any regulatory bodies. In most developed or developing countries, the Government is democratic, and it is generally a good idea for the Government to be able to prevent illicit activities like foreign exchange frauds, black markets, criminal funding, and drug trafficking. The XAND blockchain aims to resolve this problem by allowing some authorized participants to view the transactions, while at the same time maintaining the privacy of the transactions from other regular users, including the validators.""
""twitter:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-UA-Compatible"",""IE=Edge""
""viewport"",""width=device-width, initial-scale=1.0""
""dc:title"",""Acceptable Privacy for XAND Blockchain | IEEE Conference Publication | IEEE Xplore""
""twitter:description"",""Recently, the privacy of blockchain transactions has taken center stage. Privacy is an essential feature of crypto-transactions. We have seen privacy-preserving cryptocurrencies like Monero with Cryptonote protocol and Zerocash with Zk-SNARKs. However, the privacy of transactions comes at the cost of the transactions not being visible at all to any regulatory bodies. In most developed or developing countries, the Government is democratic, and it is generally a good idea for the Government to be able to prevent illicit activities like foreign exchange frauds, black markets, criminal funding, and drug trafficking. The XAND blockchain aims to resolve this problem by allowing some authorized participants to view the transactions, while at the same time maintaining the privacy of the transactions from other regular users, including the validators.""
""Content-Encoding"",""UTF-8""
""Content-Type-Hint"",""text/html; charset=utf-8""
""Content-Length"",""40253""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=690&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094609-947;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Threshold ECDSA from ECDSA assumptions: the multiparty case;J Doerner, Y Kondi, E Lee… ; 2019 IEEE Symposium on …, 2019  ieeexplore.ieee.org;;"… Abstract—Cryptocurrency applications have spurred a resur- gence of interest in the computation

of ECDSA signatures using threshold protocols—that … to one party less than the threshold under

only the Computational Diffie-Hellman assumption in the Random Oracle model, an …";Cité 31 fois;Les 4 versions;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/8826229/8835208/08835354.pdf?casa_token=S4IsoCBmrncAAAAA:TtorV4LFN1pGj1kQtUXmsBBrMJjs6JHQfkMScchrbhp8opNnGrv6YqFht1cNB8qlm_6LA3iGl3Q;;"""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""dc:title"",""IEEE Xplore Full-Text PDF:""
""Content-Encoding"",""UTF-8""
""resourceName"",""08835354.pdf""
""language"",""es""
""Content-Length"",""2533""
""title"",""IEEE Xplore Full-Text PDF:""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=760&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094560-737;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Development of Blockchain Platform for Smart Mines and Underground Structures in Industry 4.0 Revolution;RMA Khan ;2019 repository.hanyang.ac.kr;;"… an ecosystem (system-of-systems) connecting conventional underground structures informatics

systems (sub-networks) using structure query language from Oracle … who voluntarily either i)

confirms the quality of the mined product, ii) carry out computation (blockchain-mining), iii …";Cité 1 fois;Les 2 versions;null;;;;https://scholar.google.com/scholar?start=550&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094607-938;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;?????? ???????????? ????????????? ?????????? ??????????????? ??????? ??? ????????? ????????????? ???????????????? ???????? ?????????? …;A Zubarev, K Shilov, M Suleymanova… ; Available at SSRN …, 2019  papers.ssrn.com;;"… Bitcoin Blockchain ???????????? ????????? ???????? Bitcoin ? Blockchain Electronic copy

available at: https://ssrn.com/abstract=3360990 Page 7. 7 … ??????????????? ?????????? Oracle

(Oracle Database), IBM (IBM DB2) ? Microsoft (Microsoft SQL Server) …";Autres articles;;[PDF] ranepa.ru;ftp://w82.ranepa.ru/rnp/wpaper/031942.pdf;;"""date"",""2019-03-26T14:28:02Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.5""
""xmp:CreatorTool"",""MicrosoftÂŽ Word 2016""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dc:creator"",""Шилов Кирилл Дмитриевич""
""language"",""ru""
""dcterms:created"",""2019-03-26T14:28:02Z""
""Last-Modified"",""2019-03-26T14:28:02Z""
""dcterms:modified"",""2019-03-26T14:28:02Z""
""dc:format"",""application/pdf; version=1.5""
""Last-Save-Date"",""2019-03-26T14:28:02Z""
""pdf:docinfo:creator_tool"",""MicrosoftÂŽ Word 2016""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2019-03-26T14:28:02Z""
""meta:save-date"",""2019-03-26T14:28:02Z""
""pdf:encrypted"",""false""
""modified"",""2019-03-26T14:28:02Z""
""Content-Length"",""1872366""
""pdf:hasMarkedContent"",""true""
""Content-Type"",""application/pdf""
""pdf:docinfo:creator"",""Шилов Кирилл Дмитриевич""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Шилов Кирилл Дмитриевич""
""dc:language"",""ru-RU""
""meta:author"",""Шилов Кирилл Дмитриевич""
""meta:creation-date"",""2019-03-26T14:28:02Z""
""created"",""2019-03-26T14:28:02Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""70""
""Creation-Date"",""2019-03-26T14:28:02Z""
""resourceName"",""031942.pdf""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""454"",""2828"",""2306"",""1245"",""2176"",""1113"",""2351"",""621"",""1362"",""2156"",""1045"",""153"",""936"",""2254"",""1306"",""1028"",""2146"",""2255"",""1235"",""2224"",""2069"",""2185"",""1668"",""2308"",""2300"",""2109"",""1906"",""814"",""2154"",""2282"",""2348"",""2221"",""1243"",""274"",""2089"",""2058"",""2339"",""2176"",""841"",""288"",""1404"",""2311"",""632"",""1715"",""875"",""2062"",""905"",""908"",""876"",""1468"",""2006"",""1894"",""274"",""2086"",""2162"",""1277"",""189"",""2162"",""2315"",""2341"",""818"",""1995"",""715"",""2022"",""2239"",""1195"",""1910"",""1756"",""1967"",""409""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""Author"",""Шилов Кирилл Дмитриевич""
""producer"",""MicrosoftÂŽ Word 2016""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""MicrosoftÂŽ Word 2016""
""pdf:docinfo:created"",""2019-03-26T14:28:02Z""
";https://scholar.google.com/scholar?start=750&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094560-732;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Digital-physical parity for food fraud detection;SK Lo, X Xu, C Wang, I Weber, P Rimba, Q Lu… ; … on Blockchain, 2019  Springer;;"… With cryptocurrency, blockchain can also provide a trading infrastructure that enables contingent

payment implemented as a smart contract for trading … Hence, the interoperability between the

off-chain components and blockchain can be achieved with the use of an oracle …";Cité 3 fois;P Rimba;[PDF] researchgate.net;https://www.researchgate.net/profile/Sin_Kuang_Lo/publication/333859990_Digital-Physical_Parity_for_Food_Fraud_Detection/links/5d282bbe92851cf4407b0530/Digital-Physical-Parity-for-Food-Fraud-Detection.pdf;;;https://scholar.google.com/scholar?start=550&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094553-707;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Group signatures without NIZK: from lattices in the standard model;S Katsumata, S Yamada ; Annual international conference on the theory …, 2019  Springer;;"… anonymity to hold only when the signing keys of the two members in question are not exposed

and it has access to an open oracle … In particular, regardless of what the security notion we

consider for anonymity, all prior lattice-based constructions required random oracles …";Cité 11 fois;Les 2 versions;[PDF] iacr.org;https://eprint.iacr.org/2019/221.pdf;;"""date"",""2019-04-25T05:24:53Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2019-04-25T05:24:53Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017/W32TeX) kpathsea version 6.2.3""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2019-04-25T05:24:53Z""
""created"",""2019-04-25T05:24:53Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-04-25T05:24:53Z""
""resourceName"",""221.pdf""
""Author"",""""
""producer"",""pdfTeX-1.40.18""
""pdf:docinfo:producer"",""pdfTeX-1.40.18""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""5"",""29"",""10"",""0"",""6"",""28"",""32"",""3"",""14"",""77"",""39"",""105"",""24"",""12"",""54"",""76"",""84"",""54"",""54"",""67"",""65"",""39"",""39"",""32"",""56"",""0"",""1"",""2"",""0"",""0"",""0"",""0"",""0"",""6"",""11"",""27"",""11"",""36"",""32"",""51"",""74"",""61"",""56"",""20"",""26"",""11"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2019-04-25T05:24:53Z""
""Last-Modified"",""2019-04-25T05:24:53Z""
""dcterms:modified"",""2019-04-25T05:24:53Z""
""title"",""""
""Last-Save-Date"",""2019-04-25T05:24:53Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2019-04-25T05:24:53Z""
""meta:save-date"",""2019-04-25T05:24:53Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017/W32TeX) kpathsea version 6.2.3""
""Content-Length"",""594277""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""53""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""2177"",""3351"",""3464"",""3383"",""3558"",""3163"",""3546"",""3461"",""3473"",""3299"",""2333"",""2167"",""2274"",""2461"",""2479"",""2594"",""2094"",""2737"",""1968"",""2354"",""2425"",""2237"",""2954"",""2707"",""2647"",""2348"",""2502"",""2149"",""1983"",""2253"",""2280"",""3395"",""3250"",""2713"",""2193"",""2005"",""2109"",""2220"",""2145"",""1841"",""2384"",""2163"",""2068"",""2423"",""2475"",""2713"",""2498"",""2439"",""1769"",""2331"",""2384"",""3091"",""1563""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-04-25T05:24:53Z""
";https://scholar.google.com/scholar?start=520&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094635-1054;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[HTML][HTML] Public key encryption with equality test from generic assumptions in the random oracle model;HT Lee, S Ling, JH Seo, H Wang ; Information Sciences, 2019  Elsevier;;"… hash function. In reality, random oracles do not exist and it was reported that some

of cryptographic constructions which were proven secure in the random oracle model

are vulnerable in practice [9], [13], [23]. However, since …";Cité 6 fois;Les 5 versions;[HTML] sciencedirect.com;https://www.sciencedirect.com/science/article/pii/S002002551930430X?casa_token=3qn-hpH6zRYAAAAA:rrjejLACvgWnffSPxWBjSomB-0JmwLHrZjEAqWTctJJHS-qARSZYKM4efFdNkySfwWMgq2M5;;;https://scholar.google.com/scholar?start=870&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094640-1073;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Certificateless sequential aggregate signature scheme on NTRU Lattice;XIE Jia, HU Yupu, GAO Juntao, M JIANG ; Chinese Journal of Electronics, 2019  IET;;"… And the CL- AggVerify(?i?1)=1. Queries A1 can adaptively query all the oracles shown

next: 1) H-Oracle query. The simulator C keeps a list LH-list={idi,di,si,1 + si,2 ? h}. Taking

an identity idi ? {0, 1}? as input, C looks up it in LH-list …";Cité 2 fois;Les 5 versions;[PDF] ejournal.org.cn;http://www.ejournal.org.cn/Jweb_cje/EN/article/downloadArticleFile.do?attachType=PDF&id=11274;;;https://scholar.google.com/scholar?start=890&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094661-1161;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[LIVRE][B] Smart Contracts: Grundlagen, Anwendungsfelder und rechtliche Aspekte;R Wilkens, R Falk ;2019 books.google.com;;"… Oracle) erfassen. Soll etwa eine Transaktion ausgeführt werden, wenn eine physische Ware

übergeben wurde, benötigt der Smart Contract zunächst diese Information. Mittels eines Oracles

für eingehende Daten können Datenfeeds über außerhalb der Blockchain ein- tretende …";Cité 3 fois;Les 3 versions;null;;;;https://scholar.google.com/scholar?start=980&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094567-763;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Coalition-safe equilibria with virtual payoffs;A Kiayias, AP Stouka ; arXiv preprint arXiv:2001.00047, 2019  arxiv.org;;"… that certain operations of the protocol are abstracted as oracles and calling such oracles incurs

a … aggregates the expenditure that is incurred during the execution based on the oracle queries

posed … For example in the case of a proof-of-work blockchain protocol this may amount …";Cité 1 fois;Les 3 versions;[PDF] arxiv.org;https://arxiv.org/pdf/2001.00047;;"""date"",""2020-01-03T02:28:42Z""
""pdf:PDFVersion"",""1.4""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.4""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""xmp:CreateDate"",""2020-01-02T21:28:42Z""
""modified"",""2020-01-03T02:28:42Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""xmp:ModifyDate"",""2020-01-02T21:28:42Z""
""pdf:docinfo:creator"",""""
""meta:author"",""""
""meta:creation-date"",""2020-01-03T02:28:42Z""
""created"",""2020-01-03T02:28:42Z""
""xmp:About"",""uuid:4ecd7259-65ed-11f5-0000-30f31042accb""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-01-03T02:28:42Z""
""resourceName"",""2001.00047""
""Author"",""""
""producer"",""dvips + GPL Ghostscript GIT PRERELEASE 9.22""
""pdf:docinfo:producer"",""dvips + GPL Ghostscript GIT PRERELEASE 9.22""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""1"",""7"",""0"",""0"",""0"",""0"",""10"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""2"",""0"",""0"",""1"",""1"",""3"",""2"",""3"",""0"",""7"",""8"",""0"",""5"",""0"",""24"",""1""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2020-01-03T02:28:42Z""
""Last-Modified"",""2020-01-03T02:28:42Z""
""dcterms:modified"",""2020-01-03T02:28:42Z""
""title"",""""
""xmpMM:DocumentID"",""uuid:4ecd7259-65ed-11f5-0000-30f31042accb""
""Last-Save-Date"",""2020-01-03T02:28:42Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2020-01-03T02:28:42Z""
""meta:save-date"",""2020-01-03T02:28:42Z""
""Content-Length"",""431188""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""36""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""2496"",""3724"",""3507"",""3107"",""3850"",""3616"",""3440"",""2687"",""3132"",""3044"",""3386"",""2778"",""2765"",""3669"",""3054"",""2684"",""2553"",""2755"",""2913"",""2620"",""2873"",""3104"",""2737"",""2712"",""1941"",""1053"",""1975"",""1359"",""2601"",""2162"",""1749"",""1829"",""1873"",""2025"",""1892"",""2161""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-01-03T02:28:42Z""
";https://scholar.google.com/scholar?start=580&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094605-924;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[CITATION][C] Consensus on Clock in Universally Composable Timing Model.;HK Alper ; IACR Cryptol. ePrint Arch., 2019;;null;Cité 1 fois;;null;;;;https://scholar.google.com/scholar?start=740&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094623-1002;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[PDF][PDF] On Contractual Money;A Chepurnoy, A Saxena ;2019 wwww.easychair.org;;"… a trusted oracle whose only job is to periodically emit and publish on the blockchain the exchange …

whose job is to define the system parameters such as the pricing oracle's id, etc … appropriate

number of crypto tokens determined using the most recently emit- ted rate by the oracle …";Autres articles;;[PDF] easychair.org;https://wwww.easychair.org/publications/preprint_download/NZcf;;;https://scholar.google.com/scholar?start=820&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094647-1108;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[PDF][PDF] Smart Contracts;S Baloch ;2019 researchgate.net;;"… Bitcoin uses the SHA-256 hash function to crypto- graphically secure the transactions … Since smart

contracts become the part of a blockchain network, so they don't support the input of … As a solution,

we have Oracles which takes the data from external sensors and Sends the data …";Cité 1 fois;;[PDF] researchgate.net;https://www.researchgate.net/profile/Sajid_Baloch3/publication/339458071_Smart_Contracts/links/5e53eab9299bf18082de6932/Smart-Contracts.pdf;;;https://scholar.google.com/scholar?start=920&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094551-691;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Quantum bitcoin: an anonymous, distributed, and secure currency secured by the no-cloning theorem of quantum mechanics;J Jogenfors ; … Conference on Blockchain and Cryptocurrency  …, 2019  ieeexplore.ieee.org;;"… Again, we remind the reader that the above definitions are abstract random oracles, however

explicit … generates unique quantum states every time it is called, similarly to a random oracle … a

malicious miner could generate a quantum bitcoin, append it to the blockchain, and then …";Cité 38 fois;Les 8 versions;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/8744142/8751228/08751473.pdf?casa_token=_evTF_zZLUsAAAAA:TohuoQ8v_CGx3smjgPq8O69TQJW7d6bjxvUYq_XS-AXUAZHFyDwGATQm8op4GBD-3TNbw0c2v-Q;;"""og:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""twitter:title"",""Quantum Bitcoin: An Anonymous, Distributed, and Secure Currency Secured by the No-Cloning Theorem of Quantum Mechanics""
""twitter:card"",""summary""
""Description"",""The digital currency Bitcoin has had remarkable growth since it was first proposed in 2008. Its distributed nature allows currency transactions without a centra""
""og:title"",""Quantum Bitcoin: An Anonymous, Distributed, and Secure Currency Secured by the No-Cloning Theorem of Quantum Mechanics""
""resourceName"",""08751473.pdf""
""language"",""en""
""title"",""Quantum Bitcoin: An Anonymous, Distributed, and Secure Currency Secured by the No-Cloning Theorem of Quantum Mechanics | IEEE Conference Publication | IEEE Xplore""
""og:description"",""The digital currency Bitcoin has had remarkable growth since it was first proposed in 2008. Its distributed nature allows currency transactions without a central authority by using cryptographic methods and a data structure called the blockchain. Imagine that you could run the Bitcoin protocol on a quantum computer. What advantages can be had over classical Bitcoin? This is the question we answer here by introducing Quantum Bitcoin which, among other features, has immediate local verification of transactions. This is a major improvement over classical Bitcoin since we no longer need the computationally-intensive and time-consuming method of recording all transactions in the blockchain. Quantum Bitcoin is the first distributed quantum currency, and this paper introduces the necessary tools including a novel two-stage quantum mining process. In addition, we have counterfeiting resistance, fully anonymous and free transactions, and a smaller footprint than classical Bitcoin.""
""twitter:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-UA-Compatible"",""IE=Edge""
""viewport"",""width=device-width, initial-scale=1.0""
""dc:title"",""Quantum Bitcoin: An Anonymous, Distributed, and Secure Currency Secured by the No-Cloning Theorem of Quantum Mechanics | IEEE Conference Publication | IEEE Xplore""
""twitter:description"",""The digital currency Bitcoin has had remarkable growth since it was first proposed in 2008. Its distributed nature allows currency transactions without a central authority by using cryptographic methods and a data structure called the blockchain. Imagine that you could run the Bitcoin protocol on a quantum computer. What advantages can be had over classical Bitcoin? This is the question we answer here by introducing Quantum Bitcoin which, among other features, has immediate local verification of transactions. This is a major improvement over classical Bitcoin since we no longer need the computationally-intensive and time-consuming method of recording all transactions in the blockchain. Quantum Bitcoin is the first distributed quantum currency, and this paper introduces the necessary tools including a novel two-stage quantum mining process. In addition, we have counterfeiting resistance, fully anonymous and free transactions, and a smaller footprint than classical Bitcoin.""
""Content-Encoding"",""UTF-8""
""Content-Type-Hint"",""text/html; charset=utf-8""
""Content-Length"",""40737""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=510&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094602-914;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Design of trusted B2B market platforms using permissioned blockchains and game theory;S Narang, M Byali, P Dayama, V Pandit… ; … and Cryptocurrency  …, 2019  ieeexplore.ieee.org;;"… novel ways of stringing together game theoretic modeling, blockchain technology, and crypto-

graphic techniques … Regulation Protocol on Blockchain: We show how to employ a permissioned

blockchain network to securely and privately mimic a centralized oracle's solution to …";Cité 2 fois;;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/8744142/8751228/08751472.pdf?casa_token=W75eIqZkPp8AAAAA:9nzxBwQ6s5Pqpq9uPQP0k8wLPK_DkIbH-eqwgHAAlyLYCBpf4TH70UFmpc-20fsuZQOIquxtqMQ;;"""og:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""twitter:title"",""Design of Trusted B2B Market Platforms using Permissioned Blockchains and Game Theory""
""twitter:card"",""summary""
""Description"",""Trusted collaboration satisfying the requirements of (a) adequate transparency and (b) preservation of privacy of business sensitive information is a key factor""
""og:title"",""Design of Trusted B2B Market Platforms using Permissioned Blockchains and Game Theory""
""resourceName"",""08751472.pdf""
""language"",""en""
""title"",""Design of Trusted B2B Market Platforms using Permissioned Blockchains and Game Theory | IEEE Conference Publication | IEEE Xplore""
""og:description"",""Trusted collaboration satisfying the requirements of (a) adequate transparency and (b) preservation of privacy of business sensitive information is a key factor to ensure the success and adoption of online business-to-business (B2B) collaboration platforms. Our work proposes novel ways of stringing together game theoretic modeling, blockchain technology, and cryptographic techniques to build such a platform for B2B collaboration involving enterprise buyers and sellers who may be strategic. The B2B platform builds upon three ideas. The first is to use a permissioned blockchain with smart contracts as the technical infrastructure for building the platform. Second, the above smart contracts implement deep business logic which is derived using a rigorous analysis of a repeated game model of the strategic interactions between buyers and sellers to devise strategies to induce honest behavior from buyers and sellers. Third, we present a formal framework that captures the essential requirements for secure and private B2B collaboration, and, in this direction, we develop cryptographic regulation protocols that, in conjunction with the blockchain, help implement such a framework. We believe our work is an important first step in the direction of building a platform that enables B2B collaboration among strategic and competitive agents while maximizing social welfare and addressing the privacy concerns of the agents.""
""twitter:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-UA-Compatible"",""IE=Edge""
""viewport"",""width=device-width, initial-scale=1.0""
""dc:title"",""Design of Trusted B2B Market Platforms using Permissioned Blockchains and Game Theory | IEEE Conference Publication | IEEE Xplore""
""twitter:description"",""Trusted collaboration satisfying the requirements of (a) adequate transparency and (b) preservation of privacy of business sensitive information is a key factor to ensure the success and adoption of online business-to-business (B2B) collaboration platforms. Our work proposes novel ways of stringing together game theoretic modeling, blockchain technology, and cryptographic techniques to build such a platform for B2B collaboration involving enterprise buyers and sellers who may be strategic. The B2B platform builds upon three ideas. The first is to use a permissioned blockchain with smart contracts as the technical infrastructure for building the platform. Second, the above smart contracts implement deep business logic which is derived using a rigorous analysis of a repeated game model of the strategic interactions between buyers and sellers to devise strategies to induce honest behavior from buyers and sellers. Third, we present a formal framework that captures the essential requirements for secure and private B2B collaboration, and, in this direction, we develop cryptographic regulation protocols that, in conjunction with the blockchain, help implement such a framework. We believe our work is an important first step in the direction of building a platform that enables B2B collaboration among strategic and competitive agents while maximizing social welfare and addressing the privacy concerns of the agents.""
""Content-Encoding"",""UTF-8""
""Content-Type-Hint"",""text/html; charset=utf-8""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=730&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094658-1154;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;A Note on the Invisibility and Anonymity of Undeniable Signature Schemes;SH Heng, SY Tan, K Kurosawa ; International Workshop on Information …, 2019  Springer;;"… can have success probability more than \(\varepsilon \) in its game with at most q queries to its

accessible oracles in time t … covered in the adversaries' own challenges, such as \(\hat{m}\) is

not allowed to query for confirmation/disavowal oracle … In: Kilian, J. (ed.) CRYPTO 2001 …";Autres articles;;null;;;;https://scholar.google.com/scholar?start=970&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094647-1101;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Blockchain Technology–Prospects, Challenges and Opportunities;MFK Sial ;2019 blockchain.ieee.org;;"… Applications: This technology not only benefits crypto-currencies but also many different industries …

platforms are being developed by IT vendors like IBM, Microsoft, Oracle, SAP etc … These companies

are developing horizontal Blockchain platform based on the three open source …";Cité 1 fois;Les 2 versions;null;;;;https://scholar.google.com/scholar?start=920&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094602-919;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Performance analysis of the symmetric proxy re-encryption scheme;RP Meiliasari, A Syalim, S Yazid ; 2019 International Workshop …, 2019  ieeexplore.ieee.org;;"… [7] Java Oracle, ""javax.crypto (Java Platform SE 7 )"", Docs.oracle.com, 2019. Available:

https://docs.oracle.com/javase/7/docs/api/javax/crypto/package- summary.html. [Accessed: 28-

May- 2019]. [8] IntelŽ, ""IntelŽ AES-NI Performance Testing on Linux*/Java* Stack"", 2012 …";Cité 1 fois;Les 2 versions;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/8932634/8935669/08935670.pdf?casa_token=-EP35e4MOBEAAAAA:qiNuiJJ3io76PFXPP101r_gMNdtEowkgq_3dRa660WtF66LbGkEYFTff73hJj8CMiPU_IqPrgSM;;"""og:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""twitter:title"",""Performance Analysis of the Symmetric Proxy Re-encryption Scheme""
""twitter:card"",""summary""
""Description"",""The use of cloud system's storage service has been increasing in recent years. A way to secure the stored data is to use cryptographic techniques. One of the te""
""og:title"",""Performance Analysis of the Symmetric Proxy Re-encryption Scheme""
""resourceName"",""08935670.pdf""
""language"",""en""
""title"",""Performance Analysis of the Symmetric Proxy Re-encryption Scheme | IEEE Conference Publication | IEEE Xplore""
""og:description"",""The use of cloud system's storage service has been increasing in recent years. A way to secure the stored data is to use cryptographic techniques. One of the techniques that can be used when sharing data accesses with other users, is proxy reencryption, which means converting data from its unreadable form (ciphertext) corresponding to one key into another ciphertext of a different key. Many proxy re-encryption schemes often only use asymmetric key cryptography, and not symmetric key. In this paper we analyze the performance of a symmetric proxy re-encryption scheme's implementation. In measuring the performance of the re-encryption function, the authors compare the running time of the program with that of AES CBC's reencryption's running time, to compare a naĂŻve re-encryption with the selected schemes. We also propose some improvement to the implementation of the proxy re-encryption algorithm.""
""twitter:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-UA-Compatible"",""IE=Edge""
""viewport"",""width=device-width, initial-scale=1.0""
""dc:title"",""Performance Analysis of the Symmetric Proxy Re-encryption Scheme | IEEE Conference Publication | IEEE Xplore""
""twitter:description"",""The use of cloud system's storage service has been increasing in recent years. A way to secure the stored data is to use cryptographic techniques. One of the techniques that can be used when sharing data accesses with other users, is proxy reencryption, which means converting data from its unreadable form (ciphertext) corresponding to one key into another ciphertext of a different key. Many proxy re-encryption schemes often only use asymmetric key cryptography, and not symmetric key. In this paper we analyze the performance of a symmetric proxy re-encryption scheme's implementation. In measuring the performance of the re-encryption function, the authors compare the running time of the program with that of AES CBC's reencryption's running time, to compare a naĂŻve re-encryption with the selected schemes. We also propose some improvement to the implementation of the proxy re-encryption algorithm.""
""Content-Encoding"",""UTF-8""
""Content-Type-Hint"",""text/html; charset=utf-8""
""Content-Length"",""40462""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=730&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094588-857;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[CITATION][C] Padrőes de Desenho para Contratos Inteligentes em Ethereum;JMR Costa ;2019;;null;Autres articles;;[PDF] ipp.pt;https://recipp.ipp.pt/bitstream/10400.22/15609/1/DM_JoaoCosta_2019_MEI.pdf;;"""date"",""2019-10-13T19:34:46Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.4""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dcterms:created"",""2019-10-13T19:34:46Z""
""language"",""en""
""Last-Modified"",""2019-10-13T19:34:46Z""
""dcterms:modified"",""2019-10-13T19:34:46Z""
""dc:format"",""application/pdf; version=1.4""
""Last-Save-Date"",""2019-10-13T19:34:46Z""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2019-10-13T19:34:46Z""
""meta:save-date"",""2019-10-13T19:34:46Z""
""pdf:encrypted"",""false""
""modified"",""2019-10-13T19:34:46Z""
""Content-Length"",""4530183""
""pdf:hasMarkedContent"",""false""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""meta:creation-date"",""2019-10-13T19:34:46Z""
""created"",""2019-10-13T19:34:46Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""128""
""Creation-Date"",""2019-10-13T19:34:46Z""
""resourceName"",""DM_JoaoCosta_2019_MEI.pdf""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""100"",""240"",""0"",""2229"",""0"",""1582"",""0"",""1718"",""2316"",""2315"",""1737"",""1542"",""0"",""1061"",""0"",""1919"",""1916"",""1593"",""1813"",""1840"",""1661"",""1872"",""1190"",""2025"",""1610"",""2218"",""2409"",""2403"",""1635"",""2248"",""1410"",""1527"",""1928"",""2508"",""829"",""2065"",""2786"",""1719"",""851"",""722"",""2506"",""1237"",""1851"",""1225"",""1303"",""96"",""0"",""1268"",""1534"",""1392"",""1593"",""941"",""1534"",""1263"",""786"",""1204"",""1700"",""502"",""1158"",""805"",""1159"",""959"",""623"",""1568"",""932"",""1725"",""1208"",""1673"",""1121"",""671"",""1678"",""1301"",""1086"",""1680"",""1184"",""1412"",""1249"",""1194"",""0"",""569"",""80"",""1443"",""2014"",""886"",""850"",""434"",""841"",""1503"",""1871"",""1829"",""1612"",""1116"",""956"",""529"",""0"",""1212"",""2277"",""171"",""0"",""2553"",""3123"",""2930"",""2968"",""2819"",""2469"",""739"",""926"",""1432"",""1587"",""1221"",""1816"",""1242"",""1707"",""1122"",""48"",""1160"",""1213"",""1358"",""1542"",""1095"",""1238"",""1448"",""1386"",""1562"",""1344"",""1900"",""1689"",""1006""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""producer"",""iTextSharp 4.1.6 by 1T3XT""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""iTextSharp 4.1.6 by 1T3XT""
""pdf:docinfo:created"",""2019-10-13T19:34:46Z""
";https://scholar.google.com/scholar?start=670&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094534-621;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[PDF][PDF] Applying Blockchain to product compliance and assurance in the construction industry;N Allison, M Warren ; Building Research Levy, External Research …, 2019  branz.co.nz;;"… Bitcoin Bitcoin is a well-known cryptocurrency, based on the proof-of-work Blockchain … Scalability

concerns must be effectively addressed before Blockchain can be adopted more widely outside

of cryptocurrency transactions that exchange very limited amounts of information …";Cité 3 fois;Les 2 versions;[PDF] branz.co.nz;https://www.branz.co.nz/documents/61/ER42_Applying_Blockchain_to_product_compliance_and_assurance_in_the_constructi.pdf;;"""date"",""2020-03-09T02:58:46Z""
""pdf:PDFVersion"",""1.6""
""xmp:CreatorTool"",""Adobe InDesign 14.0 (Macintosh)""
""pdf:docinfo:title"",""ER42 Applying Blockchain to product compliance and assurance in the construction industry""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""Improving the flow of products and enabling more sustainable and transparent supply chains are goals for many organisations today, where blockchain might help. In New Zealand, the construction industry has a critical need to ensure that the products that flow through their supply chains are fit for purpose and adhere to regulations. ""
""language"",""en""
""dc:format"",""application/pdf; version=1.6""
""pdf:docinfo:creator_tool"",""Adobe InDesign 14.0 (Macintosh)""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""ER42 Applying Blockchain to product compliance and assurance in the construction industry""
""xmp:CreateDate"",""2019-08-16T11:28:10Z""
""modified"",""2020-03-09T02:58:46Z""
""cp:subject"",""Improving the flow of products and enabling more sustainable and transparent supply chains are goals for many organisations today, where blockchain might help. In New Zealand, the construction industry has a critical need to ensure that the products that flow through their supply chains are fit for purpose and adhere to regulations. ""
""pdf:docinfo:subject"",""Improving the flow of products and enabling more sustainable and transparent supply chains are goals for many organisations today, where blockchain might help. In New Zealand, the construction industry has a critical need to ensure that the products that flow through their supply chains are fit for purpose and adhere to regulations. ""
""pdf:hasMarkedContent"",""true""
""xmp:ModifyDate"",""2020-03-09T15:58:46Z""
""pdf:docinfo:creator"",""Nick Allison and Michael Warren""
""meta:author"",""Nick Allison and Michael Warren""
""trapped"",""False""
""meta:creation-date"",""2019-08-15T23:28:10Z""
""created"",""2019-08-15T23:28:10Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-08-15T23:28:10Z""
""resourceName"",""ER42_Applying_Blockchain_to_product_compliance_and_assurance_in_the_constructi.pdf""
""xmpMM:DerivedFrom:DocumentID"",""xmp.did:19653ccf-193a-45f2-9d84-4647253efbfa""
""Author"",""Nick Allison and Michael Warren""
""producer"",""Adobe PDF Library 15.0""
""pdf:docinfo:producer"",""Adobe PDF Library 15.0""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""dc:description"",""Improving the flow of products and enabling more sustainable and transparent supply chains are goals for many organisations today, where blockchain might help. In New Zealand, the construction industry has a critical need to ensure that the products that flow through their supply chains are fit for purpose and adhere to regulations. ""
""Keywords"",""LR10476
Blockchain
compliance
product
assurance
GS1
construction "",""LR10476
Blockchain
compliance
product
assurance
GS1
construction ""
""access_permission:modify_annotations"",""true""
""dc:creator"",""Nick Allison and Michael Warren""
""description"",""Improving the flow of products and enabling more sustainable and transparent supply chains are goals for many organisations today, where blockchain might help. In New Zealand, the construction industry has a critical need to ensure that the products that flow through their supply chains are fit for purpose and adhere to regulations. ""
""dcterms:created"",""2019-08-15T23:28:10Z""
""Last-Modified"",""2020-03-09T02:58:46Z""
""dcterms:modified"",""2020-03-09T02:58:46Z""
""title"",""ER42 Applying Blockchain to product compliance and assurance in the construction industry""
""xmpMM:DocumentID"",""xmp.id:3d4e1197-3cb3-4183-af75-2504dc326a36""
""Last-Save-Date"",""2020-03-09T02:58:46Z""
""pdf:docinfo:keywords"",""LR10476
Blockchain
compliance
product
assurance
GS1
construction ""
""pdf:docinfo:modified"",""2020-03-09T02:58:46Z""
""meta:save-date"",""2020-03-09T02:58:46Z""
""pdf:docinfo:custom:PublicationDate"",""2019""
""Content-Length"",""2449852""
""Content-Type"",""application/pdf""
""xmp:MetadataDate"",""2020-03-09T15:58:46Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Nick Allison and Michael Warren""
""dc:language"",""en-US""
""PublicationDate"",""2019""
""pdf:producer"",""Adobe PDF Library 15.0""
""dc:subject"",""LR10476
Blockchain
compliance
product
assurance
GS1
construction "",""LR10476
Blockchain
compliance
product
assurance
GS1
construction ""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""96""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""226"",""0"",""2661"",""0"",""3234"",""3509"",""1786"",""3818"",""4426"",""2"",""1609"",""2811"",""2817"",""1878"",""3005"",""2"",""1366"",""2123"",""1703"",""688"",""1561"",""1181"",""1573"",""1183"",""1502"",""1063"",""161"",""1443"",""1661"",""2997"",""1801"",""1753"",""552"",""1350"",""2885"",""2242"",""342"",""2"",""1406"",""2930"",""2810"",""3080"",""2930"",""1119"",""2147"",""2772"",""2969"",""3092"",""1713"",""2"",""1491"",""3193"",""3438"",""2201"",""3180"",""2479"",""1023"",""1995"",""927"",""1273"",""631"",""2165"",""3044"",""2533"",""2789"",""2"",""1342"",""2246"",""2770"",""2770"",""3250"",""2687"",""3152"",""2662"",""2470"",""2528"",""1477"",""2504"",""3071"",""1523"",""87"",""2"",""2501"",""2783"",""2928"",""2786"",""2727"",""154"",""1090"",""3517"",""1146"",""1941"",""2380"",""2"",""87"",""113""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""LR10476
Blockchain
compliance
product
assurance
GS1
construction "",""LR10476
Blockchain
compliance
product
assurance
GS1
construction ""
""xmpMM:DerivedFrom:InstanceID"",""xmp.iid:db9de700-5d6e-4372-a732-b270ea891cfa""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-08-15T23:28:10Z""
";https://scholar.google.com/scholar?start=440&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094612-956;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Identity—Based Encryption;T Gautam, A Thakkar, N Pathak ; Emerging Security Algorithms …, 2019  books.google.com;;"… This BLS scheme is secure against existential forgery under a chosen-message attack (random

oracle model), with taking assumption that the CDHP … Secure identity based encryption without

random oracles. In Matthew Franklin, editor, Advances in Cryptology—CRYPTO 2004 …";Autres articles;;null;;;;https://scholar.google.com/scholar?start=770&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094562-749;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Towards contractual agreements for revocation of online data;T Schnitzler, M Dürmuth, C Pöpper ; … on ICT Systems Security and Privacy …, 2019  Springer;;"… Mahmoody, M., Moran, T., Vadhan, S.: Time-lock puzzles in the random oracle model. In: Rogaway,

P. (ed.) CRYPTO 2011. LNCS, vol … https://signal.org/. Accessed 28 Feb 2019. 22. Oraclize Ltd.:

Oraclize - Blockchain Oracle Service, Enabling Data-Rich Smart Contracts (2017) …";Cité 2 fois;Les 6 versions;[PDF] ruhr-uni-bochum.de;https://www.infsec.ruhr-uni-bochum.de/media/infsec/veroeffentlichungen/2019/03/07/penalty-contracts.pdf;;"""date"",""2019-03-05T15:39:04Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.5""
""xmp:CreatorTool"",""TeX""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dcterms:created"",""2019-03-05T15:39:04Z""
""language"",""en""
""Last-Modified"",""2019-03-05T15:39:04Z""
""dcterms:modified"",""2019-03-05T15:39:04Z""
""dc:format"",""application/pdf; version=1.5""
""Last-Save-Date"",""2019-03-05T15:39:04Z""
""pdf:docinfo:creator_tool"",""TeX""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2019-03-05T15:39:04Z""
""meta:save-date"",""2019-03-05T15:39:04Z""
""pdf:encrypted"",""false""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is MiKTeX-pdfTeX 2.9.6211 (1.40.17)""
""modified"",""2019-03-05T15:39:04Z""
""Content-Length"",""315426""
""pdf:hasMarkedContent"",""false""
""Content-Type"",""application/pdf""
""PTEX.Fullbanner"",""This is MiKTeX-pdfTeX 2.9.6211 (1.40.17)""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""trapped"",""False""
""meta:creation-date"",""2019-03-05T15:39:04Z""
""created"",""2019-03-05T15:39:04Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""14""
""Creation-Date"",""2019-03-05T15:39:04Z""
""resourceName"",""penalty-contracts.pdf""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""2284"",""2470"",""2182"",""2331"",""1965"",""2387"",""2676"",""2561"",""2452"",""1994"",""2780"",""2524"",""2434"",""2200""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""producer"",""MiKTeX pdfTeX-1.40.17""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""MiKTeX pdfTeX-1.40.17""
""pdf:docinfo:created"",""2019-03-05T15:39:04Z""
";https://scholar.google.com/scholar?start=560&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094654-1136;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Security-mediated certificateless undeniable signature scheme;TH Yuen, SH Heng ; Third International Congress on Information and …, 2019  Springer;;"… We provided a formal security proof for our scheme in the random oracle model so as to … In:

Brassard G (ed) Advances in cryptology-CRYPTO, vol 435 … Scholar. 7. Huang Q, Wong DS (2013)

Short and efficient convertible undeniable signature schemes without random oracles …";Cité 1 fois;Les 3 versions;null;;;;https://scholar.google.com/scholar?start=950&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094593-874;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Supersingular Isogeny Diffie–Hellman Authenticated Key Exchange;K Yoneyama ; Information Security and Cryptology–ICISC 2018: 21st …, 2019  Springer;;"… 2. Outline of SIDH protocol (crypto-friendly description) … Hence, a quantum algorithm B can simulate

quantum random oracles in a polynomial-time … On the other hand, the other problem on security

proofs in the quantum random oracle model is how to insert intended random …";Autres articles;;null;;;;https://scholar.google.com/scholar?start=690&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094588-852;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Detecting robotic anomalies using robotchain;V Lopes, LA Alexandre ; 2019 IEEE International Conference …, 2019  ieeexplore.ieee.org;;"… smart-contracts to acquire information about a robot and by having an oracle computing this … with

such a modular system, innovative methods for different purposes can be added by using oracles …

J. Kang, R. Yu, D. Ye, Q. Deng, and Y. Zhang, “Consortium blockchain for secure …";Cité 12 fois;Les 4 versions;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/8726225/8733605/08733618.pdf?casa_token=ePcZDzVALMYAAAAA:6qTrTnNv2XhToR0G60kIR5yEwk3x4MijBg731SDuhgeI50xRyYguZsLa8xDYwSXjatqEKODYK34;;"""og:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""twitter:title"",""Detecting Robotic Anomalies using RobotChain""
""twitter:card"",""summary""
""Description"",""Robotic events can provide notable amounts of information regarding a robot's status, which can be extrapolated to detect productivity, anomalies, malfunctions ""
""og:title"",""Detecting Robotic Anomalies using RobotChain""
""resourceName"",""08733618.pdf""
""language"",""en""
""title"",""Detecting Robotic Anomalies using RobotChain | IEEE Conference Publication | IEEE Xplore""
""og:description"",""Robotic events can provide notable amounts of information regarding a robot's status, which can be extrapolated to detect productivity, anomalies, malfunctions and used for monitorization. However, when problems occur in sensitive environments like a factory, the logs of a machine may be discarded because they are susceptible to chances and malicious intents. In this paper we propose to use RobotChain for anomaly detection. RobotChain is a method to securely register robotic events, using a blockchain, which ensures that once an event gets registered on it, it's secured and cannot be tampered with. We show how this system can be leveraged with the module for anomaly detection, that uses the information contained on the blockchain to detect anomalies on a UR3 robot.""
""twitter:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-UA-Compatible"",""IE=Edge""
""viewport"",""width=device-width, initial-scale=1.0""
""dc:title"",""Detecting Robotic Anomalies using RobotChain | IEEE Conference Publication | IEEE Xplore""
""twitter:description"",""Robotic events can provide notable amounts of information regarding a robot's status, which can be extrapolated to detect productivity, anomalies, malfunctions and used for monitorization. However, when problems occur in sensitive environments like a factory, the logs of a machine may be discarded because they are susceptible to chances and malicious intents. In this paper we propose to use RobotChain for anomaly detection. RobotChain is a method to securely register robotic events, using a blockchain, which ensures that once an event gets registered on it, it's secured and cannot be tampered with. We show how this system can be leveraged with the module for anomaly detection, that uses the information contained on the blockchain to detect anomalies on a UR3 robot.""
""Content-Encoding"",""UTF-8""
""Content-Type-Hint"",""text/html; charset=utf-8""
""Content-Length"",""39661""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=670&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094665-1180;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;Publicly verifiable proofs from blockchains;A Scafuro, L Siniscalchi, I Visconti ; IACR International Workshop on …, 2019  Springer;;"… Above all, Bitcoin [45] was the first cryptocurrency and the first decentralized blockchain, and

recently has celebrated 10 years of … Our goal is to compute c in a verifiable manner, without relying

on the random oracle, but simply leveraging the properties of any blockchain …";Cité 8 fois;Les 3 versions;[PDF] nsf.gov;https://par.nsf.gov/servlets/purl/10098719;;"""date"",""2019-04-02T14:22:54Z""
""pdf:PDFVersion"",""1.6""
""xmp:CreatorTool"",""Springer""
""pdf:docinfo:title"",""Publicly Verifiable Proofs from Blockchains""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""Public-Key Cryptography – PKC 2019, doi:10.1007/978-3-030-17253-4_13""
""pdfa:PDFVersion"",""A-2b""
""xmpMM:History:Action"",""converted"",""converted""
""language"",""en""
""dc:format"",""application/pdf; version=""""A-2b"""""",""application/pdf; version=1.6""
""pdf:docinfo:custom:robots"",""noindex""
""pdf:docinfo:creator_tool"",""Springer""
""access_permission:fill_in_form"",""true""
""xmpMM:History:When"",""2019-04-02T19:52:07Z"",""2019-04-02T19:52:54Z""
""pdf:encrypted"",""false""
""dc:title"",""Publicly Verifiable Proofs from Blockchains""
""xmp:CreateDate"",""2019-04-02T19:49:59Z""
""modified"",""2019-04-02T14:22:54Z""
""cp:subject"",""Public-Key Cryptography – PKC 2019, doi:10.1007/978-3-030-17253-4_13""
""xmpMM:History:SoftwareAgent"",""pdfToolbox"",""pdfToolbox""
""pdf:docinfo:custom:CrossMarkDomains[1]"",""springer.com""
""robots"",""noindex""
""pdf:docinfo:subject"",""Public-Key Cryptography – PKC 2019, doi:10.1007/978-3-030-17253-4_13""
""pdf:hasMarkedContent"",""false""
""xmpMM:History:InstanceID"",""uuid:207a7486-2790-4be5-b767-f334d40f9c2c"",""uuid:bc0ba2ef-7964-4925-b0da-231c84f64c94""
""xmp:ModifyDate"",""2019-04-02T19:52:54Z""
""pdf:docinfo:creator"",""Alessandra Scafuro ""
""meta:author"",""Alessandra Scafuro "",""Luisa Siniscalchi "",""Ivan Visconti ""
""meta:creation-date"",""2019-04-02T14:19:59Z""
""pdf:docinfo:custom:CrossmarkMajorVersionDate"",""2010-04-23""
""created"",""2019-04-02T14:19:59Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-04-02T14:19:59Z""
""resourceName"",""10098719""
""pdfaid:part"",""2""
""pdf:docinfo:custom:CrossMarkDomains[2]"",""springerlink.com""
""pdf:docinfo:custom:doi"",""10.1007/978-3-030-17253-4_13""
""pdf:docinfo:custom:CrossmarkDomainExclusive"",""true""
""Author"",""Alessandra Scafuro "",""Luisa Siniscalchi "",""Ivan Visconti ""
""CrossmarkDomainExclusive"",""true""
""doi"",""10.1007/978-3-030-17253-4_13""
""pdf:unmappedUnicodeCharsPerPage"",""1"",""0"",""0"",""0"",""0"",""8"",""0"",""10"",""1"",""4"",""9"",""4"",""4"",""12"",""4"",""13"",""12"",""9"",""16"",""2"",""1"",""8"",""21"",""12"",""4"",""0"",""0"",""0""
""dc:description"",""Public-Key Cryptography – PKC 2019, doi:10.1007/978-3-030-17253-4_13""
""access_permission:modify_annotations"",""true""
""dc:creator"",""Alessandra Scafuro "",""Luisa Siniscalchi "",""Ivan Visconti ""
""description"",""Public-Key Cryptography – PKC 2019, doi:10.1007/978-3-030-17253-4_13""
""dcterms:created"",""2019-04-02T14:19:59Z""
""Last-Modified"",""2019-04-02T14:22:54Z""
""dcterms:modified"",""2019-04-02T14:22:54Z""
""title"",""Publicly Verifiable Proofs from Blockchains""
""xmpMM:DocumentID"",""uuid:b718c9f7-c197-4371-8856-ffc3c977850f""
""Last-Save-Date"",""2019-04-02T14:22:54Z""
""CrossMarkDomains[1]"",""springer.com""
""pdf:docinfo:modified"",""2019-04-02T14:22:54Z""
""meta:save-date"",""2019-04-02T14:22:54Z""
""Content-Length"",""497719""
""Content-Type"",""application/pdf""
""xmp:MetadataDate"",""2019-04-02T19:52:54Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Alessandra Scafuro "",""Luisa Siniscalchi "",""Ivan Visconti ""
""pdfaid:conformance"",""B""
""dc:language"",""EN""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""28""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""2202"",""2802"",""2462"",""2600"",""2946"",""2620"",""2700"",""2440"",""2484"",""2637"",""1692"",""1804"",""1441"",""1959"",""2247"",""2376"",""2353"",""2429"",""2102"",""2356"",""2887"",""2127"",""2037"",""2244"",""2161"",""2932"",""3069"",""1197""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""CrossMarkDomains[2]"",""springerlink.com""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-04-02T14:19:59Z""
""CrossmarkMajorVersionDate"",""2010-04-23""
";https://scholar.google.com/scholar?start=420&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094642-1087;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;[PDF][PDF] A Practical Method to Recover Exact Superpoly in Cube Attack.;SP Wang, B Hu, J Guan, K Zhang, TR Shi ; IACR Cryptol. ePrint Arch., 2019  eprint.iacr.org;;"… The time complexity of recovering the reminding ANF coefficients is very large, because it has

to query the encryption oracle and sum over the … To be specific, the time complexity of recovering

the superpoly of 832-round Trivium at CRYPTO 2017 is reduced from 277 to practical …";Cité 7 fois;;[PDF] iacr.org;https://eprint.iacr.org/2019/259.pdf;;"""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""1"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.4""
""xmp:CreatorTool"","" TeX output 2019.03.01:1626""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dcterms:created"",""2019-03-01T08:26:40Z""
""language"",""en""
""dc:format"",""application/pdf; version=1.4""
""pdf:docinfo:creator_tool"","" TeX output 2019.03.01:1626""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""Content-Length"",""189652""
""pdf:hasMarkedContent"",""false""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""meta:creation-date"",""2019-03-01T08:26:40Z""
""created"",""2019-03-01T08:26:40Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""20""
""Creation-Date"",""2019-03-01T08:26:40Z""
""resourceName"",""259.pdf""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""2784"",""3531"",""2930"",""2079"",""2277"",""2033"",""2085"",""2671"",""1859"",""2229"",""2655"",""2308"",""1830"",""2650"",""1907"",""2021"",""2010"",""1804"",""2583"",""2641""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""producer"",""MiKTeX-dvipdfmx (20110311)""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""MiKTeX-dvipdfmx (20110311)""
""pdf:docinfo:created"",""2019-03-01T08:26:40Z""
";https://scholar.google.com/scholar?start=900&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619094621-993;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019;The mechanism of concluding the Smart contracts and it's role in consolidating the property rights;M Mozafari, M Naser ; Journal of Law Research, 2019  lawresearchmagazine.sbu.ac.ir;;"… 2 student. 10.22034/jlr.2019.122103.1142. Abstract. The e-commerce industry has embraced

a new generation of electronic contracts since 2017, called Smart Contracts. These contracts

have a broad role in consolidating the ownership rights of individuals in the blockchain …";;;null;;;;https://scholar.google.com/scholar?start=810&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093455-193;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;[HTML][HTML] Blockchain and the built environment: Potentials and limitations;NO Nawari, S Ravindran ; Journal of Building Engineering, 2019  Elsevier;;"… in Hyperledger, Role as blockchain connector and coordination of software, business applications,

EVM, Oracles, Hyperledger features … are executed and shared among the participants in the

network [1]. Blockchain was first used in Bitcoin, the first cryptocurrency to achieve …";Cité 38 fois;Les 2 versions;[HTML] sciencedirect.com;https://www.sciencedirect.com/science/article/pii/S2352710218312294?casa_token=mQkkNJ5B3TkAAAAA:viPSnd8QeMc9B2ta3QtZ0VkjDEylVs2bMh-90FfSFD6cXpBmSfUu_YZnwJs0OGHqx5_4F2XS;;;https://scholar.google.com/scholar?start=30&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093506-417;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;From byzantine consensus to blockchain consensus;M Correia ; Essentials of Blockchain Technology, 2019  books.google.com;;"… single Byzantine algorithm of this kind, BFT-CUP, is based on an oracle called participant … 15,

16, 21, 22, 30, 59, 87] Add time assumptions Add oracles Hybrid model … 52? Essentials of

Blockchain Technology replicas in that context) mean more hardware, more software licences …";Cité 6 fois;;null;;;;https://scholar.google.com/scholar?start=250&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093471-263;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;[PDF][PDF] Blockchain challenges traditional contract law: Just how smart are smart contracts;MN Temte ; Wyo. L. Rev., 2019  HeinOnline;;"… Cryptocurrency 'Utility Tokens'As New Asset Class, FoRBEs (Mar 13, 2018), https://www.forbes.

com/sites/rachelwolfson/2018/03/13/us- state-of-wyoming-defines-cryptocurrency-utility-tokens-

as … 82 Smart contracts use oracles to col- lect facts outside of the blockchain to help …";Cité 17 fois;Les 2 versions;[PDF] heinonline.org;https://heinonline.org/hol-cgi-bin/get_pdf.cgi?handle=hein.journals/wylr19&section=7&casa_token=HSFVK-t2eskAAAAA:7D5TdZOpdRfSDse8umtgAq9J8lJG_qn5ZL92eH6TCnkhcj2St93sGwGIvTFZqp3QqyRJBR4;;"""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""REFRESH"",""1; url=https://heinonline.org/HOL/Page?handle=hein.journals/wylr19&div=7&g_sent=1&casa_token=HSFVK-t2eskAAAAA:7D5TdZOpdRfSDse8umtgAq9J8lJG_qn5ZL92eH6TCnkhcj2St93sGwGIvTFZqp3QqyRJBR4""
""Content-Encoding"",""UTF-8""
""resourceName"",""get_pdf.cgi""
""language"",""""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=100&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093525-495;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Corda architecture;D Mohanty ; R3 Corda for Architects and Developers, 2019  Springer;;"… Consensus. In Corda, only related parties as well as notaries participate in the transaction, and

hence there is no need of consensus from other nodes like most of the Blockchain platforms …

Oracles … For that, we use Oracle services. GDPR, the Blockchain Killer …";Cité 4 fois;;null;;;;https://scholar.google.com/scholar?start=330&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093464-237;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;DeliveryCoin: An IDS and blockchain-based delivery framework for drone-delivered services;MA Ferrag, L Maglaras ; Computers, 2019  mdpi.com;;"… To achieve privacy-preservation, the proposed scheme employs hash functions and short

signatures without random oracles and the … connected objects and then running targeted DDoS

attacks, in order to mine the cryptocurrency used by the blockchain-based delivery …";Cité 18 fois;Les 6 versions;[PDF] mdpi.com;https://www.mdpi.com/2073-431X/8/3/58/pdf;;;https://scholar.google.com/scholar?start=70&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093497-380;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Governance challenges of blockchain and decentralized autonomous organizations;O Rikken, M Janssen, Z Kwee ; Information Polity, 2019  content.iospress.com;;"… programmed the deployment can be triggered manually, by sending the code to blockchain in

a … DAOs first described as Decentralized Autonomous Companies (DAC) in 2013; a cryptocurrency

as shares in a … based on objective input, votes of the users or use of oracles, being a …";Cité 14 fois;Les 3 versions;[PDF] researchgate.net;https://www.researchgate.net/profile/Zenlin-Kwee/publication/337239592_Governance_challenges_of_blockchain_and_decentralized_autonomous_organizations/links/6040cec64585154e8c758d50/Governance-challenges-of-blockchain-and-decentralized-autonomous-organizations.pdf;;;https://scholar.google.com/scholar?start=210&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093462-224;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;A review on blockchain technologies for an advanced and cyber-resilient automotive industry;P Fraga;Lamas, TM FernándezCaramés  IEEE Access, 2019  ieeexplore.ieee.org;;"… Although smart contracts are stored on the blockchain, they received data from external services

called oracles that collect information from … For instance, an oracle can monitor the status of an

item in order to determine if it has arrived and write such a status on the blockchain …";Cité 95 fois;Les 2 versions;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/6287639/6514899/08626103.pdf;;"""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""dc:title"",""IEEE Xplore Full-Text PDF:""
""Content-Encoding"",""UTF-8""
""resourceName"",""08626103.pdf""
""language"",""es""
""Content-Length"",""2565""
""title"",""IEEE Xplore Full-Text PDF:""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=60&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093478-292;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Multi-agent based simulation of a smart insurance using Blockchain technology;FZ Meskini, R Aboulaich ; 2019 Third International Conference …, 2019  ieeexplore.ieee.org;;"… The entity that carries out this mission is called oracle. More explanations are given in the guide

[5]. B. What is Takaful … Rapidity: Automatic reimbursement based on smart contracts (oracles,

sensors) and instant … Reimbursement period: For Blockchain-based insurance …";Cité 2 fois;;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/8937389/8942231/08942270.pdf?casa_token=a1t_ZU5atKAAAAAA:1sr5CA7kTeJoyLCf76OTxlho_BbipNILiNfEWwJGyuKTR93M3zwC0HBTSmv38QfTJ-lMc0pSfxY;;"""og:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""twitter:title"",""Multi-agent based simulation of a smart insurance using Blockchain technology""
""twitter:card"",""summary""
""Description"",""In this project, a smart insurance model based on mutual aid, sharing and full transparency is suggested. To develop this model, financial technologies can help""
""og:title"",""Multi-agent based simulation of a smart insurance using Blockchain technology""
""resourceName"",""08942270.pdf""
""language"",""en""
""title"",""Multi-agent based simulation of a smart insurance using Blockchain technology | IEEE Conference Publication | IEEE Xplore""
""og:description"",""In this project, a smart insurance model based on mutual aid, sharing and full transparency is suggested. To develop this model, financial technologies can help. Actually, Blockchain, which is a new technology of data transmission, transparent and secure, has a great potential able to create an enormous progress in the financial sector, particularly for insurance companies. Combining this technology with smart contracts will surely enable them to save time, reduce costs and thus, give a better Customer Service. In this paper, we suggest as example of insurance, a model based on Takaful. For this purpose, we study the suggested model by analyzing the improvements given by blockchain and smart contracts technologies. Then, we analyze model performance to evaluate its impact in the context of different customers and insurance companies, through the software of complex systems simulation “Netlogo”.""
""twitter:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-UA-Compatible"",""IE=Edge""
""viewport"",""width=device-width, initial-scale=1.0""
""dc:title"",""Multi-agent based simulation of a smart insurance using Blockchain technology | IEEE Conference Publication | IEEE Xplore""
""twitter:description"",""In this project, a smart insurance model based on mutual aid, sharing and full transparency is suggested. To develop this model, financial technologies can help. Actually, Blockchain, which is a new technology of data transmission, transparent and secure, has a great potential able to create an enormous progress in the financial sector, particularly for insurance companies. Combining this technology with smart contracts will surely enable them to save time, reduce costs and thus, give a better Customer Service. In this paper, we suggest as example of insurance, a model based on Takaful. For this purpose, we study the suggested model by analyzing the improvements given by blockchain and smart contracts technologies. Then, we analyze model performance to evaluate its impact in the context of different customers and insurance companies, through the software of complex systems simulation “Netlogo”.""
""Content-Encoding"",""UTF-8""
""Content-Type-Hint"",""text/html; charset=utf-8""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=130&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093543-571;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Themis: Towards decentralized escrow of cryptocurrencies without trusted third parties;H Meng, E Bian, C Tang ; 2019 Sixth International Conference …, 2019  ieeexplore.ieee.org;;"… A. Transactions Between Different Digital Currencies Traditionally, transactions between digital

currencies are executed on cryptocurrency exchanges … Jiang Zhang, Yu Chen, Zhenfeng Zhang,

CRYPTO 2016 … [11] Astraea: A Decentralized Blockchain Oracle, Ryan Berryhill and …";Cité 2 fois;;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/8764267/8768486/08768704.pdf?casa_token=rqzGCrqUB1oAAAAA:nxLuiFGVMsNmEuUo9uiLTiJp0ubhQQ2ZGpiklvrym7Ndb3FnQAR8Lkm4OX6dua_0rdHA0QGiwmA;;"""og:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""twitter:title"",""Themis: Towards Decentralized Escrow of Cryptocurrencies without Trusted Third Parties""
""twitter:card"",""summary""
""Description"",""We introduce an improvement fair exchange method called Themis, which does not require Trusted Third Parties. Themis system is implemented based on blockchain, ""
""og:title"",""Themis: Towards Decentralized Escrow of Cryptocurrencies without Trusted Third Parties""
""resourceName"",""08768704.pdf""
""language"",""en""
""title"",""Themis: Towards Decentralized Escrow of Cryptocurrencies without Trusted Third Parties | IEEE Conference Publication | IEEE Xplore""
""og:description"",""We introduce an improvement fair exchange method called Themis, which does not require Trusted Third Parties. Themis system is implemented based on blockchain, and can provide escrow services for secure exchanging between cryptocurrencies and physical goods. We propose many application scenarios for Themis, such as peer-to-peer escrow payments, exchanges among digital currencies. We implement a test-net for Themis and the experimental results shows that Themis protocol is practical in real-world distributed environment.""
""twitter:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-UA-Compatible"",""IE=Edge""
""viewport"",""width=device-width, initial-scale=1.0""
""dc:title"",""Themis: Towards Decentralized Escrow of Cryptocurrencies without Trusted Third Parties | IEEE Conference Publication | IEEE Xplore""
""twitter:description"",""We introduce an improvement fair exchange method called Themis, which does not require Trusted Third Parties. Themis system is implemented based on blockchain, and can provide escrow services for secure exchanging between cryptocurrencies and physical goods. We propose many application scenarios for Themis, such as peer-to-peer escrow payments, exchanges among digital currencies. We implement a test-net for Themis and the experimental results shows that Themis protocol is practical in real-world distributed environment.""
""Content-Encoding"",""UTF-8""
""Content-Type-Hint"",""text/html; charset=utf-8""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=410&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093525-492;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Intelligent health care data management using blockchain: current limitation and future research agenda;A Dubovitskaya, P Novotny, S Thiebes… ; … , and Analytics for …, 2019  Springer;;"… To establish the truthfulness, multiple independent oracles, or verifiers, can be involved (ie, the

data are considered genuine only after being approved by multiple … In: ONC/NIST use of Blockchain

for healthcare and research workshop … Balagurusamy, V., et al.: Crypto anchors …";Cité 4 fois;Les 5 versions;[PDF] researchgate.net;https://www.researchgate.net/profile/Scott_Thiebes/publication/335161045_Intelligent_Healthcare_Data_Management_using_Blockchain_Current_Limitation_and_Future_Research_Agenda/links/5d6a4de4a6fdcc547d6d60be/Intelligent-Healthcare-Data-Management-using-Blockchain-Current-Limitation-and-Future-Research-Agenda.pdf;;;https://scholar.google.com/scholar?start=330&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093464-231;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;[HTML][HTML] A systematic literature review of blockchain-based applications: current status, classification and open issues;F Casino, TK Dasaklis, C Patsakis ; Telematics and informatics, 2019  Elsevier;;null;Cité 575 fois;Les 8 versions;[HTML] sciencedirect.com;https://www.sciencedirect.com/science/article/pii/S0736585318306324;;;https://scholar.google.com/scholar?start=70&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093485-328;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;[HTML][HTML] Blockchain meets vanet: An architecture for identity and location privacy protection in vanet;H Li, L Pei, D Liao, G Sun, D Xu ; PeertoPeer Networking and …, 2019  Springer;United States of America;"… These cryptodigital currencies mainly be used in small payments, foreign exchange, gambling

and money laundering; Blockchain 2.0 focuses on the registration, validation, and transfer of

smart contract. Smart contracts rely on oracles prediction and are mainly used in the …";Cité 19 fois;Les 3 versions;[HTML] springer.com;https://idp.springer.com/authorize/casa?redirect_uri=https://link.springer.com/article/10.1007/s12083-019-00786-4&casa_token=jPEu5BdgvD8AAAAA:PE5s_cpnjFKL2u4Q491-rl6Rdr_Aaqrm0fwR8WM3F6gqe6LFWzD8y75eqKlDUxUINrnyT9PfAhHFA0c;;"""dc.publisher"",""Springer""
""og:image"",""https://media.springernature.com/w200/springer-static/cover/journal/12083.jpg""
""twitter:card"",""summary""
""og:site_name"",""Peer-to-Peer Networking and Applications""
""citation_reference"",""Vehicle/5G, available on https://http://www. sohu. com/a/229846324_114835, accessed on Apr. 28, 2018"",""Dvir E, Strasser G (2018) Does Marketing Widen Borders? Cross-Country Price Dispersion in the European Car Market. Journal of International Economics, 134–149"",""Rasheed H, Donghyun K, Junggab S et al. (2018) Secure and Privacy-Aware Incentives-Based Witness Service in Social Internet of Vehicles Clouds, IEEE Internet of Things Journal, 2441–2448"",""Jie C, Jing Z, Hong Z et al. (2018) An efficient certificateless aggregate signature without pairings for vehicular ad hoc networks, Information Sciences, 1–15"",""Sun G, Yu M, Liao D et al. (2018) Analytical Exploration of Energy Savings for Parked Vehicles to Enhance VANET Connectivity. IEEE Transactions on Intelligent Transportation Systems, DOI:                      https://doi.org/10.1109/TITS.2018                                        . 2834569"",""Sun G, Zhang Y, Liao D et al. (2018) Bus Trajectory-Based Street-Centric Routing for Message Delivery in Urban Vehicular Ad hoc Networks. IEEE Transactions on Vehicular Technology, 7550–7563"",""Nzouonta J, Rajgure N, Wang G et al. (2009) VANET Routing on City Roads Using Real-Time Vehicular Traffic Information. IEEE Transactions on Vehicular Technology, 3609–3626"",""Li H Liao D, Sun G et al. (2017) Towards Location and Trajectory Privacy Preservation in 5G Vehicular Social Network. IEEE International Conference on Computational Science and Engineering (CSE) and IEEE International Conference on Embedded and Ubiquitous Computing (EUC), 63–69"",""Liao D, Li H, Sun G et al. (2018) Location and Trajectory Privacy Preservation in 5G-Enabled Vehicle Social Network Services. Journal of Network and Computer Applications, 108–118"",""Li H, Liao D, Sun G et al. (2018) Two-stage Privacy-preserving Mechanism for a Crowdsensing -based VSN. IEEE Access, 40682–40695"",""Liao D, Li H, Sun G et al. (2015) Protecting User Trajectory in Location-Based Services, IEEE GLOBECOM, 1–6"",""Liao D, Li H, Anand V et al. (2016) Using Location-labeling for Privacy Protection in Location-Based Services. International Conference on Internet of Things and Big Data, 299–306"",""Sun G, Liao D, Li H et al. (2017) L2P2: A location-label based approach for privacy preserving in LBS. Future Generation Computer Systems, 375–384"",""Liao D, Sun G, Li H et al. (2017) The Framework and Algorithm for Preserving User Trajectory while using Location-Based Services in IoT-Cloud Systems. Cluster Computing, 2283–2297"",""Novo O (2018) Blockchain Meets IoT: An Architecture for Scalable Access Management in IoT. IEEE Internet of Things Journal, 1184–115"",""Sun G, Chang V, Ramachandran M et al. (2017) Efficient Location Privacy Algorithm for Internet of Things (IoT) Services and Applications. Journal of Network and Computer Applications, 3–13"",""Sun G, Xie Y, Liao D et al. (2017) User-Defined Privacy Location-Sharing System in Mobile Online Social Networks. Journal of Network and Computer Applications, 34–45"",""Tyagi A, Sreenath N (2015) Location privacy preserving techniques for location based services over road networks. International Conference on Communications and Signal Processing (ICCSP), 1319–1326"",""Ullah I, Wahid A, Shah M et al. (2017) VBPC: Velocity based pseudonym changing strategy to protect location privacy of Vehicles in VANET. International Conference on Communication Technologies, 132–137"",""Au M, Liu J, Fang J et al. (2014) A New Payment System for Enhancing Location Privacy of Electric Vehicles. IEEE Transactions on Vehicular Technology, 3–18"",""Ying B, Makrakis D, Mouftah H (2013) Dynamic Mix-Zone for Location Privacy in Vehicular Networks. IEEE Communications Letters, 1524–1527"",""Kang J, Yu R, Huang X et al. (2018) Privacy-Preserved Pseudonym Scheme for Fog Computing Supported Internet of Vehicles. IEEE Transactions on Intelligent Transportation, 2627–2637"",""Zhang S, Wang G, Liu Q et al. (2018) A trajectory privacy-preserving scheme based on query exchange in mobile social networks. Soft Computing, 6121–6133"",""Zhu L, Xie H, Liu Y et al. (2018) PTPP: Preference-Aware Trajectory Privacy-Preserving over Location-Based Social Networks. Journal of Information Science and Engineering, 803–820"",""Memon I, Chen L, Arain Q et al. (2018) Pseudonym changing strategy with multiple mix zones for trajectory privacy protection in road networks. International Journal of Communication Systems. 1–18"",""Cui J, Xu W, Zhong H (2018) et al. Privacy-Preserving Authentication Using a Double Pseudonym for Internet of Vehicles. Sensors, 1–15"",""Afifi M, Zhou K, Ren J (2018) Privacy Characterization and Quantification in Data Publishing. IEEE Transactions on Knowledge and Data Engineering, 1756–1769"",""Takabi H, Joshi J, Karimi H (2009) A collaborative k-anonymity approach for location privacy in location-based services, International Conference on Collaborative Computing, 1–9"",""Niu B, Li Q, Zhu X et al. (2014) Achieving k-anonymity in privacy aware location-based services. IEEE INFOCOM, 754–762"",""Islam S, Obaidat M, Vijayakumar P (2018) et al. A robust and efficient password-based conditional privacy preserving authentication and group-key agreement protocol for VANETs. Future Generation Computer Systems, 217–227"",""Cui J, Zhang J, Zhong H et al. (2018) An efficient certificateless aggregate signature without pairings for vehicular ad hoc networks. Information Sciences, 1–15"",""Peters D, Wetzlich J, Thiel F et al. (2018) Blockchain applications for legal metrology. IEEE International Instrumentation and Measurement Technology Conference (I2MTC), 1–6"",""Joy J, Cusack M (2017) Internet of Vehicles and Autonomous Connected Car-Privacy and Security Issues. IEEE International Conference on Computer Communication and Networks, 1–9"",""Joy J, Cusack G, Gerla M (2017) Poster: Time Analysis of the Feasibility of Vehicular Blocktrees. ACM 3rd Workshop on Experiences with the Design and Implementation of Smart Objects, 25–26"",""Dorri A, Kanhere S, Jurdak R (2017) Towards an Optimized BlockChain for IoT. ACM 2nd International Conference on Internet-of-Things Design and Implementation, 173–178"",""citation_journal_title=J Inf Process Syst; citation_title=Block-VN: A Distributed Blockchain Based Vehicular Network Architecture in Smart City; citation_author=P Sharma, S Moon, J Park; citation_volume=13; citation_issue=1; citation_publication_date=2017; citation_pages=184-195; citation_id=CR36"",""Lei A, Cruickshank H, Cao Y et al. (2017) Blockchain-Based Dynamic Key Management for Heterogeneous Intelligent Transportation Systems. IEEE Internet of Things Journal, 1832–1843"",""Amoretti M, Brambilla G, Medioli F et al. (2018) Blockchain-Based Proof of Location. IEEE International Conference on Software Quality, Reliability and Security, 146–153"",""Herzberg A, Jarecki S, Krawczyk H et al. (1995) Proactive Secret Sharing Or: How to Copy with Perpetual Leakage. Proc of Crypto, 339–352"",""Alphand O, Amoretti M, Claeys T et al. (2018) IoTChain: A Blockchain Security Architecture for the Internet of Things. IEEE Wireless Communications and Networking Conference (WCNC), 1–6"",""A. Said, M. Marot, A. Ibrahim, et al. (2016) Modeling interactive real-time applications in VANETs with performance evaluation. Computer Networks, 66–78"",""G. Wood. Ethereum: A Secure Decentralised Generalised Transaction Ledger. Available:                      https://www.ethereum.org/                                                                 ""
""citation_journal_title"",""Peer-to-Peer Networking and Applications""
""language"",""en""
""citation_cover_date"",""2019/09/01""
""og:description"",""With the breakthroughs in sensor technology and internet of things, Vehicular Ad Hoc Network (VANET) is developing into a new generation. The technical challenges of current VANET are decentralized architecture deployment and privacy protection. Since the blockchain owns the characteristics of being decentralized, distributed, collective maintenance and non-tampering, this paper designs a novel decentralized architecture using blockchain technology, which is called blockchain-based VANET. The blockchain-based VANET involves four major stages: blockchain set-up, registration of vehicles, SBMs upload, and blockchain record. It can effectively address the problems of centralization and mutual distrust between entities in current VANET. For protecting identity and location privacy, we propose UGG, IPP and LPP algorithms with the way of dynamic threshold encryption and k-anonymity unity in the stage of SBMs upload of blockchain-based VANET. To quantify the availability of k-anonymity unity, we propose two indicators: connectivity and average distance. Extensive simulations have been conducted to validate the effectiveness of blockchain-based VANET. We analyze the simulation results from four aspects: system time, average distance, connectivity, and privacy leakage. The simulation results show that our proposed architecture performs better in terms of processing time than current architectures. Furthermore, our proposed architecture shows its superior in the aspect of protecting identity and location privacy.""
""prism.issn"",""1936-6450""
""citation_author_email"",""huier.uestc@uestc.edu.cn"",""peilisher@gmail.com"",""dliao.uestc@gmail.com"",""gangsun@uestc.edu.cn"",""xudu@uestc.edu.cn""
""twitter:image:alt"",""Content cover image""
""prism.number"",""5""
""citation_issn"",""1936-6450""
""citation_language"",""en""
""dc:title"",""Blockchain Meets VANET: An Architecture for Identity and Location Privacy Protection in VANET | SpringerLink""
""Content-Encoding"",""UTF-8""
""citation_pdf_url"",""https://link.springer.com/content/pdf/10.1007/s12083-019-00786-4.pdf""
""citation_lastpage"",""1193""
""DOI"",""10.1007/s12083-019-00786-4""
""citation_journal_abbrev"",""Peer-to-Peer Netw. Appl.""
""prism.rightsAgent"",""journalpermissions@springernature.com""
""citation_author"",""Hui Li"",""Lishuang Pei"",""Dan Liao"",""Gang Sun"",""Du Xu""
""resourceName"",""casa""
""dc.date"",""2019-07-20""
""citation_springer_api_url"",""http://api.springer.com/metadata/pam?q=doi:10.1007/s12083-019-00786-4&api_key=""
""citation_issue"",""5""
""prism.volume"",""12""
""prism.publicationName"",""Peer-to-Peer Networking and Applications""
""citation_doi"",""10.1007/s12083-019-00786-4""
""dc.title"",""Blockchain Meets VANET: An Architecture for Identity and Location Privacy Protection in VANET""
""prism.url"",""https://link.springer.com/article/10.1007/s12083-019-00786-4""
""citation_volume"",""12""
""dc.language"",""En""
""Content-Language"",""en""
""format-detection"",""telephone=no""
""citation_publication_date"",""2019/09""
""prism.endingPage"",""1193""
""citation_title"",""Blockchain Meets VANET: An Architecture for Identity and Location Privacy Protection in VANET""
""citation_author_institution"",""Key Lab of Optical Fiber Sensing and Communications (Ministry of Education), University of Electronic Science and Technology of China, Chengdu, China"",""Chengdu Research Institute, University of Electronic Science and Technology of China, Chengdu, China"",""Key Lab of Optical Fiber Sensing and Communications (Ministry of Education), University of Electronic Science and Technology of China, Chengdu, China"",""Key Lab of Optical Fiber Sensing and Communications (Ministry of Education), University of Electronic Science and Technology of China, Chengdu, China"",""Chengdu Research Institute, University of Electronic Science and Technology of China, Chengdu, China"",""Key Lab of Optical Fiber Sensing and Communications (Ministry of Education), University of Electronic Science and Technology of China, Chengdu, China"",""Center for Cyber Security, University of Electronic Science and Technology of China, Chengdu, China"",""Key Lab of Optical Fiber Sensing and Communications (Ministry of Education), University of Electronic Science and Technology of China, Chengdu, China""
""access"",""No""
""citation_publisher"",""Springer US""
""applicable-device"",""pc,mobile""
""dc.format"",""text/html""
""description"",""With the breakthroughs in sensor technology and internet of things, Vehicular Ad Hoc Network (VANET) is developing into a new generation. The technical cha""
""title"",""Blockchain Meets VANET: An Architecture for Identity and Location Privacy Protection in VANET | SpringerLink""
""citation_online_date"",""2019/07/20""
""twitter:site"",""@SpringerLink""
""dc.source"",""Peer-to-Peer Networking and Applications 2019 12:5""
""dc.type"",""OriginalPaper""
""dc.copyright"",""2019 Springer Science+Business Media, LLC, part of Springer Nature""
""dc.creator"",""Hui Li"",""Lishuang Pei"",""Dan Liao"",""Gang Sun"",""Du Xu""
""citation_fulltext_html_url"",""https://link.springer.com/article/10.1007/s12083-019-00786-4""
""prism.publicationDate"",""2019-07-20""
""Content-Type"",""text/html; charset=UTF-8""
""journal_id"",""12083""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""dc.description"",""With the breakthroughs in sensor technology and internet of things, Vehicular Ad Hoc Network (VANET) is developing into a new generation. The technical challenges of current VANET are decentralized architecture deployment and privacy protection. Since the blockchain owns the characteristics of being decentralized, distributed, collective maintenance and non-tampering, this paper designs a novel decentralized architecture using blockchain technology, which is called blockchain-based VANET. The blockchain-based VANET involves four major stages: blockchain set-up, registration of vehicles, SBMs upload, and blockchain record. It can effectively address the problems of centralization and mutual distrust between entities in current VANET. For protecting identity and location privacy, we propose UGG, IPP and LPP algorithms with the way of dynamic threshold encryption and k-anonymity unity in the stage of SBMs upload of blockchain-based VANET. To quantify the availability of k-anonymity unity, we propose two indicators: connectivity and average distance. Extensive simulations have been conducted to validate the effectiveness of blockchain-based VANET. We analyze the simulation results from four aspects: system time, average distance, connectivity, and privacy leakage. The simulation results show that our proposed architecture performs better in terms of processing time than current architectures. Furthermore, our proposed architecture shows its superior in the aspect of protecting identity and location privacy.""
""og:type"",""article""
""citation_article_type"",""Article""
""og:title"",""Blockchain Meets VANET: An Architecture for Identity and Location Privacy Protection in VANET""
""prism.doi"",""doi:10.1007/s12083-019-00786-4""
""X-UA-Compatible"",""IE=edge""
""citation_firstpage"",""1178""
""prism.startingPage"",""1178""
""viewport"",""width=device-width, initial-scale=1""
""dc.rightsAgent"",""journalpermissions@springernature.com""
""prism.section"",""OriginalPaper""
""dc.identifier"",""doi:10.1007/s12083-019-00786-4""
""dc.subject"",""Communications Engineering, Networks"",""Information Systems and Communication Service"",""Computer Communication Networks"",""Signal,Image and Speech Processing""
""og:url"",""https://link.springer.com/article/10.1007/s12083-019-00786-4""
""prism.copyright"",""2019 Springer Science+Business Media, LLC, part of Springer Nature""
";https://scholar.google.com/scholar?start=160&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093541-563;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;[PDF][PDF] The Promise of Blockchain and its Impact on Relationships between Actors in the Supply Chain: A Theory-Based Research Framework.;R Moulding ; Leeds University Business School [Master …, 2019  palfreymanventures.net;;"Page 1. The Promise of Blockchain and its Impact on Relationships between Actors in the Supply

Chain: A Theory-Based Research Framework. By Robbie Moulding Month and Year of Submission:

September 2019 … Figure 4 - ""Triple 'T' Framework"". Blockchain Trust Traceability …";Cité 3 fois;;[PDF] palfreymanventures.net;https://palfreymanventures.net/robert_locke-moulding-block.pdf;;"""date"",""2019-12-01T17:06:26Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.7""
""xmp:CreatorTool"",""Microsoft Word""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dc:creator"",""Adrian Gibson""
""language"",""en""
""dcterms:created"",""2019-09-02T09:42:28Z""
""Last-Modified"",""2019-12-01T17:06:26Z""
""dcterms:modified"",""2019-12-01T17:06:26Z""
""dc:format"",""application/pdf; version=1.7""
""xmpMM:DocumentID"",""uuid:0F9280EA-07F4-4CD0-92C3-3387DB0F689E""
""Last-Save-Date"",""2019-12-01T17:06:26Z""
""pdf:docinfo:creator_tool"",""Microsoft Word""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2019-12-01T17:06:26Z""
""meta:save-date"",""2019-12-01T17:06:26Z""
""pdf:encrypted"",""false""
""xmp:CreateDate"",""2019-09-02T09:42:28Z""
""modified"",""2019-12-01T17:06:26Z""
""Content-Length"",""1686490""
""pdf:hasMarkedContent"",""true""
""Content-Type"",""application/pdf""
""xmp:ModifyDate"",""2019-09-02T09:42:28Z""
""pdf:docinfo:creator"",""Adrian Gibson""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Adrian Gibson""
""dc:language"",""en-US""
""meta:author"",""Adrian Gibson""
""meta:creation-date"",""2019-09-02T09:42:28Z""
""created"",""2019-09-02T09:42:28Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""76""
""Creation-Date"",""2019-09-02T09:42:28Z""
""resourceName"",""robert_locke-moulding-block.pdf""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""410"",""539"",""869"",""812"",""656"",""2341"",""1152"",""537"",""1372"",""1808"",""1141"",""1269"",""1988"",""2471"",""676"",""2533"",""2489"",""2465"",""2495"",""2463"",""834"",""726"",""2086"",""1925"",""2223"",""1059"",""1192"",""2096"",""532"",""804"",""38"",""1789"",""1988"",""2088"",""2007"",""1945"",""1939"",""2038"",""1976"",""589"",""31"",""2374"",""2227"",""2680"",""2608"",""2527"",""1609"",""1927"",""2556"",""2381"",""2491"",""2583"",""2481"",""2751"",""2460"",""2406"",""1839"",""1234"",""1450"",""235"",""3598"",""3926"",""4182"",""3979"",""3453"",""4019"",""4048"",""3429"",""1783"",""907"",""1009"",""1471"",""1923"",""2190"",""1625"",""1943""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""Author"",""Adrian Gibson""
""producer"",""macOS Version 10.15.1 (Build 19B88) Quartz PDFContext, AppendMode 1.1""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""macOS Version 10.15.1 (Build 19B88) Quartz PDFContext, AppendMode 1.1""
""pdf:docinfo:created"",""2019-09-02T09:42:28Z""
";https://scholar.google.com/scholar?start=400&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093457-208;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Towards a blockchain deployment at uae university: Performance evaluation and blockchain taxonomy;L Ismail, H Hameed, M AlShamsi… ; … on Blockchain …, 2019  dl.acm.org;;"… IBM Blockchain platform [56] ? PBFT Private and Consortium Go, JavaScript, Python Oracle

Blockchain [57] ? PBFT Public Go Finance, general and smart contracts Azure Blockchain [58] ?

Ethereum proof of authority Private and Public Java, Python, C++,Ruby, Solidity 33 …";Cité 21 fois;Les 2 versions;[PDF] acm.org;https://dl.acm.org/doi/pdf/10.1145/3320154.3320156?casa_token=VCbunmv8rKYAAAAA:DLB41J_hMWg2RR-IWsbQvXMxF_fJ5whT-JPQJUvn16E3AT6LQP-ZvTlYXTwCsRkPa0iunsUbz24;;;https://scholar.google.com/scholar?start=40&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093499-382;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;A cross-chain solution to integrating multiple blockchains for IoT data management;Y Jiang, C Wang, Y Wang, L Gao ; Sensors, 2019  mdpi.com;;"… IOTA is a crypto token specially designed and optimized for the Internet-of-Things … In our

implementation, we do not consider the reattachment of transactions. We also use the Oracle

service when one blockchain needs to read data from another blockchain …";Cité 26 fois;Les 10 versions;[PDF] mdpi.com;https://www.mdpi.com/1424-8220/19/9/2042/pdf;;;https://scholar.google.com/scholar?start=220&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093485-325;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Blockchain and contract theory: modeling smart contracts using insurance markets;A Sheth, H Subramanian ; Managerial Finance, 2019  emerald.com;;"… trigger contracts via application programming interfaces (APIs), which are called “oracles”

(Karpischek and … insurance policy, smart contract functions and the third-party data “oracle” (ie

Flightstats … Since launching the application in 2016 on the Ethereum blockchain, it has issued …";Cité 13 fois;Les 5 versions;null;;;;https://scholar.google.com/scholar?start=160&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093448-169;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Infochain: A decentralized, trustless and transparent oracle on blockchain;N Goel, C van Schreven, A Filos;Ratsikas…  arXiv preprint arXiv …, 2019  arxiv.org;;"Blockchain based systems allow various kinds of financial transactions to be executed in a 
decentralized manner. However, these systems often rely on a trusted third party (oracle) to 
get correct information about the real-world events, which trigger the financial transactions …";Cité 2 fois;Les 4 versions;[PDF] arxiv.org;https://arxiv.org/pdf/1908.10258;;"""date"",""2020-07-28T01:54:03Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2020-07-28T01:54:03Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016) kpathsea version 6.2.2""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2020-07-28T01:54:03Z""
""created"",""2020-07-28T01:54:03Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-07-28T01:54:03Z""
""resourceName"",""1908.10258""
""Author"",""""
""producer"",""pdfTeX-1.40.17""
""pdf:docinfo:producer"",""pdfTeX-1.40.17""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""12"",""0"",""8"",""5"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2020-07-28T01:54:03Z""
""Last-Modified"",""2020-07-28T01:54:03Z""
""dcterms:modified"",""2020-07-28T01:54:03Z""
""title"",""""
""Last-Save-Date"",""2020-07-28T01:54:03Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2020-07-28T01:54:03Z""
""meta:save-date"",""2020-07-28T01:54:03Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016) kpathsea version 6.2.2""
""Content-Length"",""548924""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""7""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""4379"",""5077"",""3775"",""3942"",""5426"",""4665"",""4512""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-07-28T01:54:03Z""
";
1619093471-268;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;[LIVRE][B] Le droit des obligations face aux Ťcontrats intelligentsť: Blockchain, Smart Contracts et contrats de droit suisse;B Carron, V Botteron ; researchgate.net;;"… C'est le but des Ť oracles ť, qui sont des capteurs situés dans le monde physique, qui … 24. Exemple :

Pour illustrer le rôle d'un oracle, considérez l'exemple précédent et imaginez que la … ainsi que

le transfert d'une certaine quantité de crypto-monnaie échangée sur la blockchain …";Cité 1 fois;;[PDF] researchgate.net;https://www.researchgate.net/profile/Blaise_Carron/publication/331832053_Le_droit_des_obligations_face_aux_contrat_intelligents_Blockchain_Smart_Contracts_et_contrats_de_droit_suisse_in_Blaise_CarronChristoph_Muller_edit_3e_Journee_des_droits_de_la_consommation_et_de_la_di/links/5ca1bc5692851cf0aea57383/Le-droit-des-obligations-face-aux-contrat-intelligents-Blockchain-Smart-Contracts-et-contrats-de-droit-suisse-in-Blaise-Carron-Christoph-Mueller-edit-3e-Journee-des-droits-de-la-consommation-et.pdf;;;https://scholar.google.com/scholar?start=100&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093539-552;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Blockchain Technology Facing Socioeconomic Challenges. Promise versus Probability;B Lopez, D García, A Alcaide ;2019 essuir.sumdu.edu.ua;;"… We talk about devices or people who function as oracles capable of building and feeling things

in the … from: https://www.reuters.com/article/us-gold-cryptocurrency-royal-mint/wary-of-

crypto-uk-government … CME Group, UK's Royal Mint test blockchain-based gold trading platform …";Cité 5 fois;;[PDF] sumdu.edu.ua;https://essuir.sumdu.edu.ua/bitstream/123456789/76500/1/Lopez_Blockchain_Technology_Facing.pdf;;"""date"",""2020-01-13T21:23:16Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.7""
""xmp:CreatorTool"",""Microsoft® Word для Office 365""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dc:creator"",""Администратор""
""dcterms:created"",""2020-01-13T21:23:16Z""
""language"",""en""
""Last-Modified"",""2020-01-13T21:23:16Z""
""dcterms:modified"",""2020-01-13T21:23:16Z""
""dc:format"",""application/pdf; version=1.7""
""Last-Save-Date"",""2020-01-13T21:23:16Z""
""pdf:docinfo:creator_tool"",""Microsoft® Word для Office 365""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2020-01-13T21:23:16Z""
""meta:save-date"",""2020-01-13T21:23:16Z""
""pdf:encrypted"",""false""
""modified"",""2020-01-13T21:23:16Z""
""Content-Length"",""462133""
""pdf:hasMarkedContent"",""false""
""Content-Type"",""application/pdf""
""pdf:docinfo:creator"",""Администратор""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Администратор""
""meta:author"",""Администратор""
""meta:creation-date"",""2020-01-13T21:23:16Z""
""created"",""2020-01-13T21:23:16Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""12""
""Creation-Date"",""2020-01-13T21:23:16Z""
""resourceName"",""Lopez_Blockchain_Technology_Facing.pdf""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""3748"",""4794"",""4533"",""4437"",""2034"",""4795"",""4805"",""4938"",""3566"",""4797"",""4524"",""4127""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""Author"",""Администратор""
""producer"",""PDF Candy""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""PDF Candy""
""pdf:docinfo:created"",""2020-01-13T21:23:16Z""
";https://scholar.google.com/scholar?start=390&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093502-396;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;[LIVRE][B] Blockchain Technology and the Law: Opportunities and Risks;M Kianieff ;2019 books.google.com;;"… of the recent euphoria that has surrounded some of the new launches of crypto currencies and …

Blockchain and the trust problem As mentioned in Chapter 1, the origins of Blockchain can be …

efforts lies in its ability to move beyond attempts to create a 'cryptocurrency' by resolving …";Cité 2 fois;;null;;;;https://scholar.google.com/scholar?start=230&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093546-583;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Can blockchain solve the hold-up problem for shared databases?;C Barrera, S Hurder ; Prysm White Paper May, 2019  papers.ssrn.com;;"Page 1. Can Blockchain Solve the Hold-Up Problem for Shared Databases? Dr. Cathy Barrera?

Dr. Stephanie Hurder … tion partners. Blockchain can provide the economic structure for

organizations to enter shared databases without fear of being victim to the hold-up problem …";Cité 3 fois;;null;;;;https://scholar.google.com/scholar?start=420&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093530-518;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Audita: A Blockchain-based Auditing Framework for Off-chain Storage;D Francati, G Ateniese, A Faye, AM Milazzo… ; arXiv preprint arXiv …, 2019  arxiv.org;;"… The type of reward in our system can be quite arbitrary and can range from

cryptocurrency-based rewards in a public blockchain to contractual agreements in a

permissioned blockchain. B. Organization The paper is organized as follows …";Cité 4 fois;Les 3 versions;[PDF] arxiv.org;https://arxiv.org/pdf/1911.08515;;"""date"",""2020-07-06T01:59:59Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2020-07-06T01:59:59Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016) kpathsea version 6.2.2""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2020-07-06T01:59:59Z""
""created"",""2020-07-06T01:59:59Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-07-06T01:59:59Z""
""resourceName"",""1911.08515""
""Author"",""""
""producer"",""pdfTeX-1.40.17""
""pdf:docinfo:producer"",""pdfTeX-1.40.17""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""6"",""43"",""5"",""0"",""2"",""4"",""2"",""23"",""24"",""7"",""2"",""17"",""26"",""43""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2020-07-06T01:59:59Z""
""Last-Modified"",""2020-07-06T01:59:59Z""
""dcterms:modified"",""2020-07-06T01:59:59Z""
""title"",""""
""Last-Save-Date"",""2020-07-06T01:59:59Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2020-07-06T01:59:59Z""
""meta:save-date"",""2020-07-06T01:59:59Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016) kpathsea version 6.2.2""
""Content-Length"",""763639""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""15""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""4624"",""5273"",""5050"",""5572"",""5179"",""5240"",""4335"",""4945"",""4624"",""5573"",""4817"",""4462"",""5860"",""5058"",""1816""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-07-06T01:59:59Z""
";https://scholar.google.com/scholar?start=350&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093499-388;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Exploiting computation power of blockchain for biomedical image segmentation;B Li, C Chenli, X Xu, T Jung… ; Proceedings of the IEEE …, 2019  openaccess.thecvf.com;;"… After a training task is selected and performed by the miners, the corresponding publisher will

pay certain amount of reward to the miner presenting the best image segmentation model in

the form of the cryptocurrency that is maintained by the blockchain …";Cité 8 fois;Les 7 versions;[PDF] thecvf.com;http://openaccess.thecvf.com/content_CVPRW_2019/papers/BCMCVAI/Li_Exploiting_Computation_Power_of_Blockchain_for_Biomedical_Image_Segmentation_CVPRW_2019_paper.pdf;;"""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""dc:title"",""302 Found""
""Content-Encoding"",""ISO-8859-1""
""resourceName"",""Li_Exploiting_Computation_Power_of_Blockchain_for_Biomedical_Image_Segmentation_CVPRW_2019_paper.pdf""
""language"",""en""
""Content-Length"",""435""
""title"",""302 Found""
""Content-Type"",""text/html; charset=ISO-8859-1""
";https://scholar.google.com/scholar?start=220&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093536-546;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;PRICHAIN: A Partially Decentralized Implementation of UbiPri Middleware Using Blockchain;I Sestrem Ochôa, LA Silva, G de Mello, B Alves da Silva… ; Sensors, 2019  mdpi.com;;"… In 2008, Nakamoto described the blockchain concept through the Bitcoin cryptocurrency

[7]. Blockchain is a decentralized technology that ensures the integrity of transactions

performed on the platform without the need for validation by a third party …";Cité 1 fois;Les 8 versions;[PDF] mdpi.com;https://www.mdpi.com/1424-8220/19/20/4483/pdf;;;https://scholar.google.com/scholar?start=380&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093504-402;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Keynote 3: Blockchain–IoT–AI Trust Nexus.;D Svetinovic ; 2019 Sixth International Conference on Internet …, 2019  ieeexplore.ieee.org;;"… integration. We present some directions for achieving more trustworthy and explainable

blockchain – AI – IoT system integration by leveraging features of blockchain, smart

contracts, trusted oracles, and decentralized storage. We …";Les 2 versions;;null;;;;https://scholar.google.com/scholar?start=240&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093502-391;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Decentralized Hierarchical Authorized Payment with Online Wallet for Blockchain;Q Wei, S Li, W Li, H Li, M Wang ; International Conference on Wireless …, 2019  Springer;;"… A scheme is (q, p) secure if after times q query to oracle, the adversary's … S., Yan, J.: Overview

of business innovations and research opportunities in blockchain and introduction … Bellare, M.,

Rogaway, P.: Random oracles are practical-a paradigm for designing efficient protocols …";Cité 1 fois;Les 2 versions;null;;;;https://scholar.google.com/scholar?start=230&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093541-567;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;An Efficient, Secure and Reliable Search Scheme for Dynamic Updates with Blockchain;H Li, C Gu, Y Chen, W Li ; Proceedings of the 2019 the 9th International …, 2019  dl.acm.org;;"… when given ?, our scheme can still be secure against non-adaptive attacks by using random

oracle … Operations on the blockchain are completed by smart contract which is deployed on a

test network testRTC [19 … We implement PRF and random oracles by using HMAC-SHA256 …";Cité 1 fois;;[PDF] acm.org;https://dl.acm.org/doi/pdf/10.1145/3371676.3371684?casa_token=O2Jy2nUOdZsAAAAA:imozjdsllvw9byIW4vVhMCljgdaItp80DfMbSP5xVPuMft4TOs-jEZzATyefnG6_Ob24ON321ec;;;https://scholar.google.com/scholar?start=400&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093459-214;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Key encapsulation mechanism with explicit rejection in the quantum random oracle model;H Jiang, Z Zhang, Z Ma ; IACR International Workshop on Public Key …, 2019  Springer;;"… and use it to extend the proof techniques for KEM constructions with implicit rejection (Crypto

2018, Eurocrypt … Let \(\mathcal {O}_1\), \(mathcal {O}_2\) be oracles with domain X and codomain

Y such … Let \(A^{\mathcal {O}_1}(z)\) be an oracle algorithm with query number d. Let \(B …";Cité 17 fois;Les 2 versions;[PDF] iacr.org;https://eprint.iacr.org/2019/052.pdf;;"""date"",""2019-01-18T07:24:22Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""7"",""4"",""23"",""8"",""14"",""0"",""4"",""29"",""10"",""22"",""10"",""26"",""33"",""36"",""58"",""60"",""12"",""18"",""23"",""26"",""63"",""26"",""0"",""21"",""34"",""11"",""14""
""pdf:PDFVersion"",""1.5""
""xmp:CreatorTool"",""TeX""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dcterms:created"",""2019-01-18T07:24:22Z""
""language"",""en""
""Last-Modified"",""2019-01-18T07:24:22Z""
""dcterms:modified"",""2019-01-18T07:24:22Z""
""dc:format"",""application/pdf; version=1.5""
""Last-Save-Date"",""2019-01-18T07:24:22Z""
""pdf:docinfo:creator_tool"",""TeX""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2019-01-18T07:24:22Z""
""meta:save-date"",""2019-01-18T07:24:22Z""
""pdf:encrypted"",""false""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is MiKTeX-pdfTeX 2.9.4307 (1.40.12)""
""modified"",""2019-01-18T07:24:22Z""
""Content-Length"",""498117""
""pdf:hasMarkedContent"",""false""
""Content-Type"",""application/pdf""
""PTEX.Fullbanner"",""This is MiKTeX-pdfTeX 2.9.4307 (1.40.12)""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""trapped"",""False""
""meta:creation-date"",""2019-01-18T07:24:22Z""
""created"",""2019-01-18T07:24:22Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""28""
""Creation-Date"",""2019-01-18T07:24:22Z""
""resourceName"",""052.pdf""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""2289"",""2662"",""2431"",""1836"",""2650"",""2567"",""2300"",""1950"",""1968"",""1550"",""1466"",""1529"",""1128"",""1958"",""1274"",""1609"",""1854"",""1719"",""1031"",""2067"",""1684"",""1441"",""2082"",""2865"",""1688"",""953"",""1236"",""1170""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""producer"",""MiKTeX pdfTeX-1.40.12""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""MiKTeX pdfTeX-1.40.12""
""pdf:docinfo:created"",""2019-01-18T07:24:22Z""
";https://scholar.google.com/scholar?start=50&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093523-482;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;New instant confirmation mechanism based on interactive incontestable signature in consortium blockchain;Y Zhu, K Riad, R Guo, G Gan, R Feng ; Frontiers of Computer Science, 2019  Springer;;"… This ledger is nec- essary to prevent double-spending, which is a key technical challenge

in designing any cryptocurrency system. The basic structure of a blockchain, which consists

of a series of blocks connected in a hash chain, is shown in Fig …";Cité 3 fois;Les 5 versions;[PDF] springer.com;https://idp.springer.com/authorize/casa?redirect_uri=https://link.springer.com/content/pdf/10.1007/s11704-017-6338-8.pdf&casa_token=OJHuqxZ_pRQAAAAA:ugHRKVrv5VhKijO5yUmRDEkE7Crkyczq0KUDdHUNmikjmuopML3V1lraJGT-Lpp7HPCllqkJDlUNRjg;;;https://scholar.google.com/scholar?start=320&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093516-454;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;[HTML][HTML] The Middleman is Dead, Long Live the Middleman: The “trust factor” and the psycho-social implications of blockchain;A Gaggioli, S Eskandari, P Cipresso… ; Frontiers in Blockchain, 2019  frontiersin.org;Switzerland;"… their preferred policy and pays the premium to the smart contract, when the flight lands, the smart

contract gets the flight information from the airline website using Oracles (ie, third-party agents

that retrieves real-world occurrences and submit the information to a blockchain to be …";Cité 3 fois;Les 3 versions;[HTML] frontiersin.org;https://www.frontiersin.org/articles/10.3389/fbloc.2019.00020/full;;"""citation_keywords"",""Trust; Blockchain; Smart contract; Psychology; User Experience""
""og:image"",""https://www.frontiersin.org/files/MyHome%20Article%20Library/471232/471232_Thumb_400.jpg""
""citation_publication_date"",""2019/11/15""
""citation_title"",""The Middleman Is Dead, Long Live the Middleman: The “Trust Factor” and the Psycho-Social Implications of Blockchain""
""citation_author_institution"",""Department of Psychology, UniversitĂĄ Cattolica del Sacro Cuore, Italy"",""Applied Technology for Neuro-Psychology Lab, IRCCS Istituto Auxologico Italiano, Italy"",""Gina Cody School of Engineering and Computer Science, Concordia Institute for Information Systems Engineering, Concordia University, Canada"",""Department of Psychology, UniversitĂĄ Cattolica del Sacro Cuore, Italy"",""Applied Technology for Neuro-Psychology Lab, IRCCS Istituto Auxologico Italiano, Italy"",""Department of Psychology, UniversitĂĄ Cattolica del Sacro Cuore, Italy""
""Description"",""Blockchain is widely regarded as a breakthrough innovation that may have a profound impact on the economy and society, of a magnitude comparable to the effects of the introduction of the Internet itself. In essence, a blockchain is a decentralized peer-to-peer network with no central authority figure, which adds information to the distributed database by collectively validating the accuracy of data. Since each node of the network participates in the review and confirmation of the new information before being accepted, the need for a trustworthy intermediary is eliminated. However, as trust plays an essential role in affecting decisions when transacting with one another, it is important to understand which implications the decentralized nature of blockchain may have on individuals' sense of trust. In this contribution, we argue that the adoption of blockchain is not only a technological, but foremostly a psychological challenge, which crucially depends on the possibility of creating a trust management approach that matches the underlying distributed communication system. We first describe the decentralization technologies and possibilities they hold for the near future. Next, we discuss the psycho-social implications of the introduction of decentralized processes of trust, examining some potential scenarios, and outline a research agenda.""
""Keywords"",""Trust, Blockchain, Smart contract, Psychology, User Experience""
""citation_publisher"",""Frontiers""
""citation_journal_title"",""Frontiers in Blockchain""
""description"",""Blockchain is widely regarded as a breakthrough innovation that may have a profound impact on the economy and society, of a magnitude comparable to the effects of the introduction of the Internet itself. In essence, a blockchain is a decentralized peer-to-peer network with no central authority figure, which adds information to the distributed database by collectively validating the accuracy of data. Since each node of the network participates in the review and confirmation of the new information before being accepted, the need for a trustworthy intermediary is eliminated. However, as trust plays an essential role in affecting decisions when transacting with one another, it is important to understand which implications the decentralized nature of blockchain may have on individuals' sense of trust. In this contribution, we argue that the adoption of blockchain is not only a technological, but foremostly a psychological challenge, which crucially depends on the possibility of creating a trust management approach that matches the underlying distributed communication system. We first describe the decentralization technologies and possibilities they hold for the near future. Next, we discuss the psycho-social implications of the introduction of decentralized processes of trust, examining some potential scenarios, and outline a research agenda.""
""language"",""en""
""citation_date"",""2019""
""title"",""Frontiers | The Middleman Is Dead, Long Live the Middleman: The “Trust Factor” and the Psycho-Social Implications of Blockchain | Blockchain""
""citation_online_date"",""2019/10/30""
""citation_author_email"","""","""","""",""""
""citation_issn"",""2624-7852""
""dc:title"",""Frontiers | The Middleman Is Dead, Long Live the Middleman: The “Trust Factor” and the Psycho-Social Implications of Blockchain | Blockchain""
""citation_language"",""English""
""Content-Encoding"",""UTF-8""
""citation_pdf_url"",""https://www.frontiersin.org/articles/10.3389/fbloc.2019.00020/pdf""
""Content-Length"",""160867""
""Content-Type"",""text/html; charset=UTF-8""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""og:type"",""article""
""citation_journal_abbrev"",""Front. Blockchain""
""citation_abstract"",""Blockchain is widely regarded as a breakthrough innovation that may have a profound impact on the economy and society, of a magnitude comparable to the effects of the introduction of the Internet itself. In essence, a blockchain is a decentralized peer-to-peer network with no central authority figure, which adds information to the distributed database by collectively validating the accuracy of data. Since each node of the network participates in the review and confirmation of the new information before being accepted, the need for a trustworthy intermediary is eliminated. However, as trust plays an essential role in affecting decisions when transacting with one another, it is important to understand which implications the decentralized nature of blockchain may have on individuals' sense of trust. In this contribution, we argue that the adoption of blockchain is not only a technological, but foremostly a psychological challenge, which crucially depends on the possibility of creating a trust management approach that matches the underlying distributed communication system. We first describe the decentralization technologies and possibilities they hold for the near future. Next, we discuss the psycho-social implications of the introduction of decentralized processes of trust, examining some potential scenarios, and outline a research agenda.""
""citation_author"",""Gaggioli, Andrea"",""Eskandari, Shayan"",""Cipresso, Pietro"",""Lozza, Edoardo""
""Title"",""The Middleman Is Dead, Long Live the Middleman: The “Trust Factor” and the Psycho-Social Implications of Blockchain""
""resourceName"",""full""
""citation_pages"",""20""
""url"",""https://www.frontiersin.org/article/10.3389/fbloc.2019.00020/full""
""site_name"",""Frontiers""
""X-UA-Compatible"",""IE=edge""
""frontiers:type"",""Article""
""viewport"",""width=device-width, initial-scale=1, maximum-scale=1""
""citation_doi"",""10.3389/fbloc.2019.00020""
""dc.identifier"",""doi:10.3389/fbloc.2019.00020""
""citation_volume"",""2""
""Content-Language"",""en""
";https://scholar.google.com/scholar?start=290&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093478-299;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Exploring the attack surface of blockchain: A systematic overview;M Saad, J Spaulding, L Njilla, C Kamhoua… ; arXiv preprint arXiv …, 2019  arxiv.org;;"… of-trust [23]. For instance, Bitcoin (a popular cryptocurrency using Blockchain technology)

takes advantage of the aforementioned properties, making it easy to verify the history

of financial transactions [24], [25]. Despite the functional …";Cité 64 fois;Les 6 versions;[PDF] arxiv.org;https://arxiv.org/pdf/1904.03487;;"""date"",""2019-04-09T02:55:08Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2019-04-09T02:55:08Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016) kpathsea version 6.2.2""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2019-04-09T02:55:08Z""
""created"",""2019-04-09T02:55:08Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-04-09T02:55:08Z""
""resourceName"",""1904.03487""
""Author"",""""
""producer"",""pdfTeX-1.40.17""
""pdf:docinfo:producer"",""pdfTeX-1.40.17""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""55"",""44"",""0"",""0"",""0"",""2"",""0"",""0"",""0"",""1"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""31"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2019-04-09T02:55:08Z""
""Last-Modified"",""2019-04-09T02:55:08Z""
""dcterms:modified"",""2019-04-09T02:55:08Z""
""title"",""""
""Last-Save-Date"",""2019-04-09T02:55:08Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2019-04-09T02:55:08Z""
""meta:save-date"",""2019-04-09T02:55:08Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016) kpathsea version 6.2.2""
""Content-Length"",""2806614""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""30""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""5280"",""4160"",""4078"",""4892"",""5033"",""3899"",""5085"",""4649"",""3769"",""5145"",""4687"",""4299"",""4673"",""4083"",""5693"",""5114"",""5767"",""5478"",""4517"",""4339"",""5253"",""5207"",""3821"",""4873"",""5702"",""7825"",""8432"",""8419"",""8354"",""7469""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-04-09T02:55:08Z""
";https://scholar.google.com/scholar?start=130&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093516-457;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Blockchains and smart contracts: a threat for the legal industry?;B Waltl, C Sillaber, U Gallersdörfer… ; … through Blockchain, 2019  Springer;;"… if a good is placed or represented on the blockchain by a token, an oracle has to … At the moment,

there are different approaches to create better oracles … Token implementation (Vogelsteller and

Vitalik 2016) allows for the creation of tradable tokens on the Ethereum blockchain …";Cité 7 fois;Les 3 versions;null;;;;https://scholar.google.com/scholar?start=290&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093455-192;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Analysis of data management in blockchain-based systems: From architecture to governance;HY Paik, X Xu, HMND Bandara, SU Lee, SK Lo ; Ieee Access, 2019  ieeexplore.ieee.org;;"… An oracle is a data feeder that connects an external system (or data source) to the blockchain

network. Oracles typically have both on-chain and off-chain components. Either a human or a

server could play the role of an oracle and submit data (from an external …";Cité 26 fois;SK Lo;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/6287639/8600701/08938787.pdf;;"""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""dc:title"",""IEEE Xplore Full-Text PDF:""
""Content-Encoding"",""UTF-8""
""resourceName"",""08938787.pdf""
""language"",""es""
""Content-Length"",""2565""
""title"",""IEEE Xplore Full-Text PDF:""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=30&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093525-496;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;CacheCash: A Cryptocurrency-based Decentralized Content Delivery Network;G Almashaqbeh ;2019 academiccommons.columbia.edu;;"… Cryptocurrencies and blockchain technologies offer a fully distributed, and trustless, way to reward

peers for the expended resources … P2P networks. In this dissertation, we propose and implement

CacheCash, a fully distributed, cryptocurrency-based, bandwidth market …";Cité 4 fois;Les 4 versions;[PDF] columbia.edu;https://academiccommons.columbia.edu/doi/10.7916/d8-q2xj-8507/download;;"""date"",""2019-06-05T14:03:08Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:custom:PTEX.FullBanner"",""This is LuaTeX, Version 1.0.4 (TeX Live 2017)""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2019-06-05T14:03:08Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2019-06-05T14:03:08Z""
""PTEX.FullBanner"",""This is LuaTeX, Version 1.0.4 (TeX Live 2017)""
""created"",""2019-06-05T14:03:08Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-06-05T14:03:08Z""
""resourceName"",""download""
""Author"",""""
""producer"",""LuaTeX-1.0.4""
""pdf:docinfo:producer"",""LuaTeX-1.0.4""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""36"",""0"",""0"",""2"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""4"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""2"",""0"",""0"",""0"",""0"",""0"",""2"",""0"",""0"",""8"",""2"",""1"",""0"",""0"",""0"",""0"",""0"",""6"",""4"",""0"",""0"",""2"",""0"",""16"",""2"",""1"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""2"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""10"",""8"",""9"",""16"",""0"",""0"",""2"",""0"",""12"",""9"",""10"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""6"",""0"",""4"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2019-06-05T14:03:08Z""
""Last-Modified"",""2019-06-05T14:03:08Z""
""dcterms:modified"",""2019-06-05T14:03:08Z""
""title"",""""
""Last-Save-Date"",""2019-06-05T14:03:08Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2019-06-05T14:03:08Z""
""meta:save-date"",""2019-06-05T14:03:08Z""
""Content-Length"",""3137584""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""187""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""217"",""38"",""1778"",""801"",""925"",""1374"",""1433"",""451"",""1297"",""546"",""921"",""1468"",""99"",""23"",""1514"",""1776"",""2014"",""1966"",""1831"",""1927"",""1417"",""1792"",""1808"",""1723"",""1009"",""1400"",""1977"",""1675"",""1754"",""1833"",""1871"",""1893"",""2003"",""1880"",""1669"",""1782"",""1901"",""1790"",""1428"",""1919"",""1345"",""1294"",""1464"",""1280"",""1903"",""1295"",""1535"",""1653"",""1924"",""1787"",""1785"",""162"",""1293"",""1834"",""2044"",""1662"",""1905"",""1766"",""1856"",""1676"",""1533"",""1317"",""1848"",""1496"",""1830"",""1461"",""1994"",""1891"",""1884"",""1962"",""1501"",""1811"",""1021"",""1066"",""1818"",""133"",""1333"",""1999"",""1742"",""1881"",""1996"",""1604"",""1822"",""1619"",""1652"",""1643"",""1517"",""1605"",""1636"",""1583"",""1719"",""1685"",""1332"",""1644"",""1486"",""1582"",""1862"",""1468"",""1808"",""1540"",""1568"",""1578"",""1884"",""1894"",""1632"",""2048"",""1500"",""1758"",""1356"",""1831"",""1793"",""1557"",""1825"",""1490"",""1828"",""1555"",""1797"",""1344"",""2034"",""1789"",""1712"",""1356"",""1917"",""2030"",""1472"",""1507"",""1656"",""1756"",""1757"",""1439"",""1010"",""1654"",""1740"",""1832"",""1257"",""1611"",""1569"",""1272"",""2060"",""1874"",""1266"",""1565"",""1714"",""1448"",""1719"",""1609"",""1704"",""1983"",""1738"",""1819"",""1543"",""1223"",""1466"",""1517"",""1387"",""1910"",""1506"",""1530"",""1787"",""1020"",""1705"",""2022"",""1824"",""1478"",""1669"",""1477"",""1816"",""1748"",""1133"",""1029"",""1483"",""1239"",""1366"",""1697"",""1744"",""1525"",""1569"",""1578"",""1532"",""1053"",""1397"",""1481"",""1687"",""1604"",""1063"",""1615"",""707""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-06-05T14:03:08Z""
";https://scholar.google.com/scholar?start=330&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093534-534;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;[LIVRE][B] Introduction to Blockchain Technology: The many faces of blockchain technology in the 21st century;T Laurence ;2019 books.google.com;;"… 10 Blockchain 9.6 oracles for IoT 9.7 IP and trusted authorship 9.8 Intellectual … Introduction 1 to

Blockchain Technology Blockchain has become an omnipresent term that … Originally proposed

as a solution for Bitcoin's cryptocurrency record keeping system, blockchains are now …";Cité 5 fois;;null;;;;https://scholar.google.com/scholar?start=370&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093539-557;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Blockchain technology for collaborative information systems (dagstuhl seminar 18332);M Dumas, R Hull, J Mendling, I Weber ; Dagstuhl Reports, 2019  drops.dagstuhl.de;;"Page 1. Report from Dagstuhl Seminar 18332 Blockchain Technology for Collaborative Information

Systems … Abstract Blockchain technology enables an evolving set of parties to maintain a safe,

permanent, and tamper-proof ledger of transactions without a central authority …";Cité 8 fois;Les 5 versions;[PDF] dagstuhl.de;https://drops.dagstuhl.de/opus/volltexte/2019/10236/pdf/dagrep_v008_i008_p067_18332.pdf;;"""date"",""2019-02-12T10:17:21Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2019-02-12T10:17:21Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.19 (TeX Live 2018) kpathsea version 6.3.0""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2019-02-12T10:17:21Z""
""created"",""2019-02-12T10:17:21Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-02-12T10:17:21Z""
""resourceName"",""dagrep_v008_i008_p067_18332.pdf""
""Author"",""""
""producer"",""pdfTeX-1.40.19""
""pdf:docinfo:producer"",""pdfTeX-1.40.19""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""3"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2019-02-12T10:17:21Z""
""Last-Modified"",""2019-02-12T10:17:21Z""
""dcterms:modified"",""2019-02-12T10:17:21Z""
""title"",""""
""Last-Save-Date"",""2019-02-12T10:17:21Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2019-02-12T10:17:21Z""
""meta:save-date"",""2019-02-12T10:17:21Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.19 (TeX Live 2018) kpathsea version 6.3.0""
""Content-Length"",""8950873""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""63""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""2700"",""855"",""2020"",""1242"",""2653"",""2540"",""3463"",""2679"",""3096"",""2646"",""2540"",""2454"",""2213"",""3270"",""2366"",""2803"",""2547"",""1894"",""1741"",""2072"",""2941"",""2868"",""3237"",""2900"",""1909"",""2448"",""2376"",""2440"",""2624"",""1937"",""1582"",""2007"",""1442"",""1332"",""1471"",""1677"",""2134"",""1078"",""859"",""1972"",""3206"",""3256"",""3546"",""1761"",""3154"",""3245"",""3394"",""2995"",""2783"",""3078"",""2273"",""3182"",""3534"",""2986"",""3115"",""3374"",""3277"",""3127"",""2898"",""3265"",""3079"",""2041"",""1077""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-02-12T10:17:21Z""
";https://scholar.google.com/scholar?start=390&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093480-301;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;RobotChain: Artificial Intelligence on a Blockchain using Tezos Technology;VF Lopes ;2019 ubibliorum.ubi.pt;;"… The second method goes beyond registering events to also register information about external

sensors, like a camera, and by using smart-contracts to allow Oracles to interact with the

blockchain, it was possible to leverage image analysis algorithms that can detect the …";Autres articles;Version HTML;[PDF] ubi.pt;https://ubibliorum.ubi.pt/bitstream/10400.6/10053/1/6994_14822.pdf;;"""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.5""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dcterms:created"",""2019-06-11T09:49:23Z""
""language"",""pt""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""Content-Length"",""8021376""
""pdf:hasMarkedContent"",""false""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""meta:creation-date"",""2019-06-11T09:49:23Z""
""created"",""2019-06-11T09:49:23Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""104""
""Creation-Date"",""2019-06-11T09:49:23Z""
""resourceName"",""6994_14822.pdf""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""275"",""68"",""2183"",""68"",""3482"",""1755"",""3124"",""3480"",""3545"",""2977"",""3473"",""986"",""2044"",""262"",""2622"",""590"",""1070"",""71"",""736"",""68"",""3042"",""2897"",""2350"",""67"",""2540"",""2968"",""2997"",""3703"",""3155"",""3301"",""3312"",""3361"",""3316"",""3566"",""3273"",""3301"",""3016"",""3036"",""3234"",""2961"",""2806"",""68"",""2859"",""3197"",""1882"",""2740"",""3199"",""2083"",""3605"",""2991"",""1737"",""1591"",""683"",""68"",""2466"",""1244"",""2547"",""1601"",""1489"",""600"",""2835"",""2199"",""2120"",""1803"",""1572"",""1599"",""1237"",""2683"",""3155"",""184"",""2962"",""2580"",""1714"",""3012"",""1444"",""2823"",""1388"",""68"",""2665"",""1451"",""2445"",""2759"",""2747"",""1469"",""2541"",""2938"",""1223"",""68"",""2895"",""3349"",""935"",""68"",""2390"",""2548"",""2441"",""2525"",""2552"",""2745"",""2680"",""2245"",""2719"",""2186"",""1854"",""903""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""producer"",""XeTeX 0.99998""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""XeTeX 0.99998""
""pdf:docinfo:created"",""2019-06-11T09:49:23Z""
";https://scholar.google.com/scholar?start=140&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093487-340;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Extracting event logs for process mining from data stored on the blockchain;R Mühlberger, S Bachhofner, C Di Ciccio… ; … Conference on Business …, 2019  Springer;;"… to a price expressed in terms of gas, exchanged at a variable rate with the Ether cryptocurrency …

Blockchain BPMSs that adopt other architectural patterns than the factory one could make our

assumption … should be retrieved from certified sources such as the so-called oracles [34 …";Cité 13 fois;Les 13 versions;[PDF] easychair.org;https://easychair.org/publications/preprint_download/cW8l;;"""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""3"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.5""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""13""
""resourceName"",""cW8l""
""language"",""en""
""pdf:hasXMP"",""false""
""dc:format"",""application/pdf; version=1.5""
""pdf:charsPerPage"",""305"",""2470"",""3210"",""2680"",""2466"",""2663"",""2694"",""2894"",""2746"",""1038"",""2990"",""3161"",""3226""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""Content-Length"",""645295""
""access_permission:can_modify"",""true""
""pdf:hasMarkedContent"",""false""
""Content-Type"",""application/pdf""
";https://scholar.google.com/scholar?start=170&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093534-533;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;BoR: Toward High-Performance Permissioned Blockchain in RDMA-Enabled Network;B Huang, L Jin, ZH Lu, X Zhou, J Wu… ; IEEE Transactions …, 2019  ieeexplore.ieee.org;;"… etc. Many cloud platforms like AWS, Azure, Oracle and IBM cloud currently provide

blockchain as a service, in which tenants can quickly build permissioned blockchain

and run smart contract based applications. However, the …";Cité 2 fois;Les 3 versions;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/4629386/4629387/08877753.pdf?casa_token=rhijtawSRNAAAAAA:j92dkWZqAf2ivG22WEZ2JSQnQtjpQu1hjBo9L9GRNIIs5Wc6KYyPX6yWHtDaZCjmqOMf3633WvU;;"""og:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""twitter:title"",""BoR: Toward High-Performance Permissioned Blockchain in RDMA-Enabled Network""
""twitter:card"",""summary""
""Description"",""Known as a distributed ledger, blockchain is becoming prevalent due to its decentralization, traceability and tamper resistance. Particularly, permissioned bloc""
""og:title"",""BoR: Toward High-Performance Permissioned Blockchain in RDMA-Enabled Network""
""resourceName"",""08877753.pdf""
""language"",""en""
""title"",""BoR: Toward High-Performance Permissioned Blockchain in RDMA-Enabled Network | IEEE Journals & Magazine | IEEE Xplore""
""og:description"",""Known as a distributed ledger, blockchain is becoming prevalent due to its decentralization, traceability and tamper resistance. Particularly, permissioned blockchain such as Hyperledger Fabric shows great application prospects as the infrastructure of IoT security, credit management, etc. Many cloud platforms like AWS, Azure, Oracle and IBM cloud currently provide blockchain as a service, in which tenants can quickly build permissioned blockchain and run smart contract based applications. However, the transactions throughput and scalability in the permissioned blockchain are not ideal, despite many optimization efforts in consensus protocol and parallel chain. Existing solutions still reveals some limitations like excessive CPU scheduling, inefficient block broadcast and high latency of initial blocks synchronization when new nodes join blockchain network. Inspired by the emerging RDMA (Remote Direct Memory Access) network, we propose BoR, an RDMA-based permissioned blockchain framework. By offloading the block transfer transaction into RDMA NICs, it can increase block broadcast speed and reduce block sync delay. We exploit the RDMA primitives to redesign the block synchronization protocol and accelerate DPoS (Delegated Proof of Stake) consensus process for higher throughput and lower latency in kernel-bypass manner. As demonstrated in our evaluation with different workloads, BoR with lower CPU utilization significantly outperforms the state-of-the-art EoS blockchain.""
""twitter:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-UA-Compatible"",""IE=Edge""
""viewport"",""width=device-width, initial-scale=1.0""
""dc:title"",""BoR: Toward High-Performance Permissioned Blockchain in RDMA-Enabled Network | IEEE Journals & Magazine | IEEE Xplore""
""twitter:description"",""Known as a distributed ledger, blockchain is becoming prevalent due to its decentralization, traceability and tamper resistance. Particularly, permissioned blockchain such as Hyperledger Fabric shows great application prospects as the infrastructure of IoT security, credit management, etc. Many cloud platforms like AWS, Azure, Oracle and IBM cloud currently provide blockchain as a service, in which tenants can quickly build permissioned blockchain and run smart contract based applications. However, the transactions throughput and scalability in the permissioned blockchain are not ideal, despite many optimization efforts in consensus protocol and parallel chain. Existing solutions still reveals some limitations like excessive CPU scheduling, inefficient block broadcast and high latency of initial blocks synchronization when new nodes join blockchain network. Inspired by the emerging RDMA (Remote Direct Memory Access) network, we propose BoR, an RDMA-based permissioned blockchain framework. By offloading the block transfer transaction into RDMA NICs, it can increase block broadcast speed and reduce block sync delay. We exploit the RDMA primitives to redesign the block synchronization protocol and accelerate DPoS (Delegated Proof of Stake) consensus process for higher throughput and lower latency in kernel-bypass manner. As demonstrated in our evaluation with different workloads, BoR with lower CPU utilization significantly outperforms the state-of-the-art EoS blockchain.""
""Content-Encoding"",""UTF-8""
""Content-Type-Hint"",""text/html; charset=utf-8""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=370&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093506-411;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;[PDF][PDF] Blockchain technology as a regulatory technology;P De Filippi, S Hassan ; From Code is Law to Law is Code, URL …, 2019  escola.mpu.mp.br;;"… generally) interact with the physical world through interfaces or sensors (so-called Oracles) that

record … eg by transferring the cryptographic title to a smart car), the blockchain alone is … will always

and necessarily have to rely on a trusted intermediary (or 'oracle') whenever they …";Cité 4 fois;;[PDF] mpu.mp.br;http://escola.mpu.mp.br/servicos-academicos/plano-de-atividades/inovaescola/curadoria/4-ciclo-de-debates/blockchain-perspectivas-no-brasil-e-no-mundo/blockchain-technology-as-a-regulatory-technology.pdf;;"""date"",""2020-09-25T20:37:44Z""
""pdf:docinfo:custom:AAPL:Keywords"",""""
""pdf:PDFVersion"",""1.3""
""pdf:docinfo:title"",""Sem tĂ­tulo""
""xmp:CreatorTool"",""Safari""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.3""
""pdf:docinfo:creator_tool"",""Safari""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""Sem tĂ­tulo""
""modified"",""2020-09-25T20:37:44Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""Ligia""
""meta:author"",""Ligia""
""meta:creation-date"",""2020-09-25T20:37:44Z""
""created"",""2020-09-25T20:37:44Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-09-25T20:37:44Z""
""resourceName"",""blockchain-technology-as-a-regulatory-technology.pdf""
""Author"",""Ligia""
""producer"",""Mac OS X 10.13.6 Quartz PDFContext""
""pdf:docinfo:producer"",""Mac OS X 10.13.6 Quartz PDFContext""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""AAPL:Keywords"",""""
""dc:creator"",""Ligia""
""dcterms:created"",""2020-09-25T20:37:44Z""
""Last-Modified"",""2020-09-25T20:37:44Z""
""dcterms:modified"",""2020-09-25T20:37:44Z""
""title"",""Sem tĂ­tulo""
""Last-Save-Date"",""2020-09-25T20:37:44Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2020-09-25T20:37:44Z""
""meta:save-date"",""2020-09-25T20:37:44Z""
""Content-Length"",""323373""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Ligia""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""23""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""2789"",""3243"",""2999"",""3125"",""2896"",""3231"",""3448"",""3490"",""3535"",""3371"",""3151"",""3269"",""3608"",""3349"",""3612"",""3624"",""3345"",""3090"",""2987"",""2359"",""2509"",""2535"",""959""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-09-25T20:37:44Z""
";https://scholar.google.com/scholar?start=250&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093487-334;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Blockchain-based anti-key-leakage key aggregation searchable encryption for IoT;J Niu, X Li, J Gao, Y Han ; IEEE Internet of Things Journal, 2019  ieeexplore.ieee.org;;"… Later, we establish a data-sharing system based on blockchain and the BAI-KASE scheme in …

1) Hash-Query: A1 is allowed to issue all hash oracles and can obtain the corresponding … 7)

Signature-Query: The adversary A1 could adaptively query the sign oracle for tag of the …";Cité 7 fois;;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/6488907/6702522/08915860.pdf?casa_token=85w4uE-ZR4YAAAAA:HTgvtt0gBYjZfObGmnUJXsUVVwbUMvpCKo1LbQX_P0Q3C9ayi_lTuAVxhNGUgZpgjEkPnd7rXAc;;"""og:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""twitter:title"",""Blockchain-Based Anti-Key-Leakage Key Aggregation Searchable Encryption for IoT""
""twitter:card"",""summary""
""Description"",""The Internet of Things (IoT) makes our life more intelligent. Its combination with the cloud server can solve big data processing problems to meet users' needs ""
""og:title"",""Blockchain-Based Anti-Key-Leakage Key Aggregation Searchable Encryption for IoT""
""resourceName"",""08915860.pdf""
""language"",""en""
""title"",""Blockchain-Based Anti-Key-Leakage Key Aggregation Searchable Encryption for IoT | IEEE Journals & Magazine | IEEE Xplore""
""og:description"",""The Internet of Things (IoT) makes our life more intelligent. Its combination with the cloud server can solve big data processing problems to meet users' needs and bring us great convenience. However, there are two challenges we need to face: data sharing and key leakage. To solve the above challenges, attribute-based encryption (ABE) is used to achieve data sharing combined with searchable encryption (SE). Most of the existing attribute-based searchable encryption (SE) schemes are inefficient and not suitable for IoT devices because of the large amount of attributes and keys. The key-leakage problem is serious in practice which very little literature focused on it. In order to address both problems, in this article, we propose a key aggregation searchable encryption (KASE) scheme based on the blockchain with auxiliary input (AI), which is capable of achieving secure data sharing on the encrypted data. Our scheme is presented through a novel chosen plaintext attack (CPA) secure scheme. We prove our scheme is chosen ciphertext attack (CCA) secure against key leakage under the decisional Diffie-Hellman assumption and Goldreich-Leivin theorem. Moreover, we adopt the proposed scheme to establish a data-sharing system based on blockchain, which improves search efficiency and connects the global ecology. In addition, extensive performance evaluations are conducted, and the results indicate our scheme is really efficient in cloud-computing-enhanced IoT.""
""twitter:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-UA-Compatible"",""IE=Edge""
""viewport"",""width=device-width, initial-scale=1.0""
""dc:title"",""Blockchain-Based Anti-Key-Leakage Key Aggregation Searchable Encryption for IoT | IEEE Journals & Magazine | IEEE Xplore""
""twitter:description"",""The Internet of Things (IoT) makes our life more intelligent. Its combination with the cloud server can solve big data processing problems to meet users' needs and bring us great convenience. However, there are two challenges we need to face: data sharing and key leakage. To solve the above challenges, attribute-based encryption (ABE) is used to achieve data sharing combined with searchable encryption (SE). Most of the existing attribute-based searchable encryption (SE) schemes are inefficient and not suitable for IoT devices because of the large amount of attributes and keys. The key-leakage problem is serious in practice which very little literature focused on it. In order to address both problems, in this article, we propose a key aggregation searchable encryption (KASE) scheme based on the blockchain with auxiliary input (AI), which is capable of achieving secure data sharing on the encrypted data. Our scheme is presented through a novel chosen plaintext attack (CPA) secure scheme. We prove our scheme is chosen ciphertext attack (CCA) secure against key leakage under the decisional Diffie-Hellman assumption and Goldreich-Leivin theorem. Moreover, we adopt the proposed scheme to establish a data-sharing system based on blockchain, which improves search efficiency and connects the global ecology. In addition, extensive performance evaluations are conducted, and the results indicate our scheme is really efficient in cloud-computing-enhanced IoT.""
""Content-Encoding"",""UTF-8""
""Content-Type-Hint"",""text/html; charset=utf-8""
""Content-Length"",""44104""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=170&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093483-317;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;[PDF][PDF] Ontology Aided Smart Contract Execution for Unexpected Situations.;F Mohsin, X Zhao, Z Hong, G de Mel, L Xia… ; BlockSW/CKG …, 2019  ceurws.org;;"… A smart contract executes completely deterministic transactions and then up- date the blockchain

in an … Oracles solve this problem by providing a trusted system for information transfer. While an

oracle may seem like a centralized component, a mutable ontology-based oracle for …";Cité 1 fois;Les 4 versions;[PDF] ceur-ws.org;http://ceur-ws.org/Vol-2599/paper1.pdf;;"""date"",""2019-09-18T20:05:16Z""
""pdf:unmappedUnicodeCharsPerPage"",""1"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.5""
""xmp:CreatorTool"",""TeX""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dcterms:created"",""2019-09-18T20:05:16Z""
""language"",""en""
""Last-Modified"",""2019-09-18T20:05:16Z""
""dcterms:modified"",""2019-09-18T20:05:16Z""
""dc:format"",""application/pdf; version=1.5""
""Last-Save-Date"",""2019-09-18T20:05:16Z""
""pdf:docinfo:creator_tool"",""TeX""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2019-09-18T20:05:16Z""
""meta:save-date"",""2019-09-18T20:05:16Z""
""pdf:encrypted"",""false""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016/Debian) kpathsea version 6.2.2""
""modified"",""2019-09-18T20:05:16Z""
""Content-Length"",""543406""
""pdf:hasMarkedContent"",""false""
""Content-Type"",""application/pdf""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016/Debian) kpathsea version 6.2.2""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""meta:creation-date"",""2019-09-18T20:05:16Z""
""created"",""2019-09-18T20:05:16Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""7""
""Creation-Date"",""2019-09-18T20:05:16Z""
""resourceName"",""paper1.pdf""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""2031"",""2190"",""1763"",""1055"",""2280"",""1483"",""549""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""producer"",""pdfTeX-1.40.17""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""pdfTeX-1.40.17""
""pdf:docinfo:created"",""2019-09-18T20:05:16Z""
";https://scholar.google.com/scholar?start=150&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093483-320;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;[HTML][HTML] Blockchain technology enabling the Physical Internet: A synergetic application framework;T Meyer, M Kuhn, E Hartmann ; Computers & Industrial Engineering, 2019  Elsevier;;"… Computers & Industrial Engineering. Volume 136, October 2019, Pages 5-17. Computers &

Industrial Engineering. Blockchain technology enabling the Physical Internet: A synergetic

application framework … A permissioned Blockchain set-up solves Physical Internet obstacles. • …";Cité 24 fois;Les 2 versions;[HTML] sciencedirect.com;https://www.sciencedirect.com/science/article/pii/S0360835219303973?casa_token=kc6fVWYeY7kAAAAA:QgEwikeqzxCCIG-177oSabOvTeBvjRvxJT7Nl6SYgfsefLZkLedJQ-brMjr5BlY2UU2DZ5I-;;;https://scholar.google.com/scholar?start=150&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093494-366;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Morning Tutorial 2: Blockchain and Storage;M Ault ;2019 usenix.org;;"… In 2009, Mike joined TMS as their Oracle and FlashSystem (Ramsan) evangelist. When IBM

Purchased TMS in 2012, Mike came along and has been working with FlashSystem at IBM ever

since, first with Oracle, then financial systems and now with Blockchain …";;;null;;;;https://scholar.google.com/scholar?start=200&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093494-370;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Quantum random oracle model with auxiliary input;M Hhan, K Xagawa, T Yamakawa ; … on the Theory and Application of …, 2019  Springer;;"… The random oracle model (ROM) is an idealized model where hash functions are modeled as

random functions that are only accessible as oracles … 11) proposed using the quantum ROM

(QROM) to argue post-quantum security, and Unruh (CRYPTO'07) proposed the …";Cité 5 fois;Les 2 versions;[PDF] iacr.org;https://eprint.iacr.org/2019/1093.pdf;;"""date"",""2019-10-22T01:02:14Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2019-10-22T01:02:14Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017) kpathsea version 6.2.3""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2019-10-22T01:02:14Z""
""created"",""2019-10-22T01:02:14Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-10-22T01:02:14Z""
""resourceName"",""1093.pdf""
""Author"",""""
""producer"",""pdfTeX-1.40.18""
""pdf:docinfo:producer"",""pdfTeX-1.40.18""
""pdf:unmappedUnicodeCharsPerPage"",""3"",""0"",""33"",""2"",""4"",""0"",""5"",""33"",""5"",""23"",""45"",""33"",""39"",""39"",""33"",""44"",""49"",""59"",""28"",""23"",""55"",""37"",""30"",""0"",""2"",""11"",""64"",""36"",""28"",""21"",""8"",""23"",""10"",""20"",""14"",""22"",""37"",""13"",""46""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2019-10-22T01:02:14Z""
""Last-Modified"",""2019-10-22T01:02:14Z""
""dcterms:modified"",""2019-10-22T01:02:14Z""
""title"",""""
""Last-Save-Date"",""2019-10-22T01:02:14Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2019-10-22T01:02:14Z""
""meta:save-date"",""2019-10-22T01:02:14Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017) kpathsea version 6.2.3""
""Content-Length"",""577027""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""39""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""3311"",""3946"",""3349"",""3818"",""4171"",""3802"",""3598"",""2795"",""2824"",""2862"",""2218"",""2052"",""2620"",""2150"",""2112"",""2093"",""1815"",""2013"",""1931"",""2440"",""2352"",""1869"",""3150"",""3891"",""2893"",""1528"",""1985"",""1968"",""1547"",""1596"",""2213"",""1384"",""1626"",""2287"",""1415"",""1969"",""1741"",""2168"",""1463""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-10-22T01:02:14Z""
";https://scholar.google.com/scholar?start=200&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093452-188;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Blockchain technology for intelligent environments;S Voulgaris, N Fotiou, VA Siris, GC Polyzos, M Jaatinen… ; Future Internet, 2019  mdpi.com;;"… These, so-called, oracles are discussed further in Section 4. Input from the ledger itself: A … contract,

which, in turn, would get its input from an externally trusted IoT system (an oracle) … are generated

by the smart contracts and are propagated to all nodes of the blockchain network …";Cité 11 fois;Les 5 versions;[PDF] mdpi.com;https://www.mdpi.com/1999-5903/11/10/213/pdf;;;https://scholar.google.com/scholar?start=20&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093509-429;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;[HTML][HTML] Distributed database on blockchain technology for new era of electricity transactions;SV Oprea, A Bâra ;" Scientific Bulletin"" Mircea cel Batran"" Naval …, 2019  search.proquest.com";;"… The blockchain technology is a trading solution that increases the market competition and

encourages peer-to-peer transactions … 3. Oracle Database Distribution Techniques Oracle

Database uses the following distribution techniques: - Links between local BD (database link …";Cité 1 fois;;[HTML] proquest.com;https://search.proquest.com/openview/1e1b7b115b718e3f2903cb12c2a3ca77/1?pq-origsite=gscholar&cbl=2036237&casa_token=uyh8R9cTzE0AAAAA:G9siIrhnitZdPlilBJ75ZdRe4u7Eod3QPFvIRrKUkJTUsVsTTC4_Dui5gg6v2AJlFmLgmDGm;;;https://scholar.google.com/scholar?start=260&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093520-480;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;[PDF][PDF] Blockchain for food: making sense of technology and the impact on biofortified seeds;M De Ruyter de Wildt, M Van Ginkel, K Coppoolse… ;2019 repository.cimmyt.org;;"Page 1. Community of Practice on Socio-economic Data Report CoP_SED-2019-003 Blockchain

For Food Making Sense of Technology and the Impact … Page 3. Community of Practice on

Socio-economic Data Report CoP_SED-2019-003 Blockchain For Food: Making Sense of …";Cité 2 fois;Les 3 versions;[PDF] cimmyt.org;https://repository.cimmyt.org/bitstream/handle/10883/20683/61328.pdf?sequence=1;;"""date"",""2020-01-17T16:12:59Z""
""pdf:PDFVersion"",""1.5""
""xmp:CreatorTool"",""MicrosoftÂŽ Word 2016""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""MicrosoftÂŽ Word 2016""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""xmp:CreateDate"",""2020-01-14T13:47:22Z""
""modified"",""2020-01-17T16:12:59Z""
""pdf:hasMarkedContent"",""false""
""xmp:ModifyDate"",""2020-01-17T11:12:59Z""
""pdf:docinfo:creator"",""Gutierrez, Daniel (CIAT)""
""meta:author"",""Gutierrez, Daniel (CIAT)""
""meta:creation-date"",""2020-01-14T19:47:22Z""
""created"",""2020-01-14T19:47:22Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-01-14T19:47:22Z""
""resourceName"",""61328.pdf""
""Author"",""Gutierrez, Daniel (CIAT)""
""producer"",""MicrosoftÂŽ Word 2016""
""pdf:docinfo:producer"",""MicrosoftÂŽ Word 2016""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""access_permission:modify_annotations"",""true""
""dc:creator"",""Gutierrez, Daniel (CIAT)""
""dcterms:created"",""2020-01-14T19:47:22Z""
""Last-Modified"",""2020-01-17T16:12:59Z""
""dcterms:modified"",""2020-01-17T16:12:59Z""
""xmpMM:DocumentID"",""uuid:aedb8661-75da-48ab-966f-644f28072d76""
""Last-Save-Date"",""2020-01-17T16:12:59Z""
""pdf:docinfo:modified"",""2020-01-17T16:12:59Z""
""meta:save-date"",""2020-01-17T16:12:59Z""
""Content-Length"",""1609452""
""Content-Type"",""application/pdf""
""xmp:MetadataDate"",""2020-01-17T11:12:59Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Gutierrez, Daniel (CIAT)""
""dc:language"",""en-US""
""pdf:producer"",""MicrosoftÂŽ Word 2016""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""49""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""283"",""5"",""284"",""329"",""2091"",""1265"",""1152"",""3882"",""3167"",""3588"",""227"",""2847"",""552"",""2395"",""3187"",""2633"",""1285"",""1721"",""2926"",""2106"",""2163"",""2581"",""1631"",""2095"",""2322"",""2762"",""3091"",""1647"",""2238"",""1296"",""1427"",""1813"",""149"",""2097"",""1405"",""2700"",""2276"",""1641"",""1398"",""1636"",""1111"",""1968"",""1231"",""2607"",""2070"",""1082"",""499"",""395"",""320""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-01-14T19:47:22Z""
";https://scholar.google.com/scholar?start=310&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093546-581;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Trust factors and insider threats in permissioned distributed ledgers;B Putz, G Pernul ; Transactions on LargeScale Dataand Knowledge …, 2019  Springer;;"… be hard to discover, since the oracle service is not transparent to all operators. Alternative

proposals that avoid relying on a centralized provider include secure hardware architectures

such as Town Crier [53], and cryptocurrency-based decentralized blockchain oracles such as …";Cité 6 fois;Les 6 versions;[PDF] uni-regensburg.de;https://epub.uni-regensburg.de/40762/1/Manuscript.pdf;;"""date"",""2019-09-06T08:45:22Z""
""pdf:PDFVersion"",""1.7""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.7""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2019-09-06T08:45:22Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is MiKTeX-pdfTeX 2.9.6870 (1.40.19)""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2019-09-06T08:45:22Z""
""created"",""2019-09-06T08:45:22Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-09-06T08:45:22Z""
""resourceName"",""Manuscript.pdf""
""Author"",""""
""producer"",""pdfTeX-1.40.19""
""pdf:docinfo:producer"",""pdfTeX-1.40.19""
""pdf:unmappedUnicodeCharsPerPage"",""3"",""1"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2019-09-06T08:45:22Z""
""Last-Modified"",""2019-09-06T08:45:22Z""
""dcterms:modified"",""2019-09-06T08:45:22Z""
""title"",""""
""Last-Save-Date"",""2019-09-06T08:45:22Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2019-09-06T08:45:22Z""
""meta:save-date"",""2019-09-06T08:45:22Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is MiKTeX-pdfTeX 2.9.6870 (1.40.19)""
""Content-Length"",""821235""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""26""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""2048"",""2738"",""2248"",""1477"",""1918"",""2614"",""2728"",""2431"",""2117"",""2619"",""2623"",""1992"",""2068"",""2396"",""1100"",""2593"",""2830"",""1975"",""2444"",""2463"",""2601"",""2701"",""2904"",""3020"",""2986"",""2573""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-09-06T08:45:22Z""
";https://scholar.google.com/scholar?start=420&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093459-218;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;A Critical Examination of the Application of Blockchain Technology to Intellectual Property Management;K Ito, M O'Dair ; Business transformation through blockchain, 2019  Springer;;"… While most of the implemented oracles adopt a centralised solution relying on a TTP (typically

information … Although it is not explicitly mentioned in the original paper, Augur's Oracle is often

called … Blockchain and the Economics of Crypto-Tokens and Initial Coin Offerings …";Cité 20 fois;Les 7 versions;null;;;;https://scholar.google.com/scholar?start=50&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093546-587;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Publicly verifiable proofs from blockchains;A Scafuro, L Siniscalchi, I Visconti ; IACR International Workshop on …, 2019  Springer;;"… Above all, Bitcoin [45] was the first cryptocurrency and the first decentralized blockchain, and

recently has celebrated 10 years of … Our goal is to compute c in a verifiable manner, without relying

on the random oracle, but simply leveraging the properties of any blockchain …";Cité 8 fois;Les 3 versions;[PDF] nsf.gov;https://par.nsf.gov/servlets/purl/10098719;;"""date"",""2019-04-02T14:22:54Z""
""pdf:PDFVersion"",""1.6""
""xmp:CreatorTool"",""Springer""
""pdf:docinfo:title"",""Publicly Verifiable Proofs from Blockchains""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""Public-Key Cryptography – PKC 2019, doi:10.1007/978-3-030-17253-4_13""
""pdfa:PDFVersion"",""A-2b""
""xmpMM:History:Action"",""converted"",""converted""
""language"",""en""
""dc:format"",""application/pdf; version=""""A-2b"""""",""application/pdf; version=1.6""
""pdf:docinfo:custom:robots"",""noindex""
""pdf:docinfo:creator_tool"",""Springer""
""access_permission:fill_in_form"",""true""
""xmpMM:History:When"",""2019-04-02T19:52:07Z"",""2019-04-02T19:52:54Z""
""pdf:encrypted"",""false""
""dc:title"",""Publicly Verifiable Proofs from Blockchains""
""xmp:CreateDate"",""2019-04-02T19:49:59Z""
""modified"",""2019-04-02T14:22:54Z""
""cp:subject"",""Public-Key Cryptography – PKC 2019, doi:10.1007/978-3-030-17253-4_13""
""xmpMM:History:SoftwareAgent"",""pdfToolbox"",""pdfToolbox""
""pdf:docinfo:custom:CrossMarkDomains[1]"",""springer.com""
""robots"",""noindex""
""pdf:docinfo:subject"",""Public-Key Cryptography – PKC 2019, doi:10.1007/978-3-030-17253-4_13""
""pdf:hasMarkedContent"",""false""
""xmpMM:History:InstanceID"",""uuid:207a7486-2790-4be5-b767-f334d40f9c2c"",""uuid:bc0ba2ef-7964-4925-b0da-231c84f64c94""
""xmp:ModifyDate"",""2019-04-02T19:52:54Z""
""pdf:docinfo:creator"",""Alessandra Scafuro ""
""meta:author"",""Alessandra Scafuro "",""Luisa Siniscalchi "",""Ivan Visconti ""
""meta:creation-date"",""2019-04-02T14:19:59Z""
""pdf:docinfo:custom:CrossmarkMajorVersionDate"",""2010-04-23""
""created"",""2019-04-02T14:19:59Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-04-02T14:19:59Z""
""resourceName"",""10098719""
""pdfaid:part"",""2""
""pdf:docinfo:custom:CrossMarkDomains[2]"",""springerlink.com""
""pdf:docinfo:custom:doi"",""10.1007/978-3-030-17253-4_13""
""pdf:docinfo:custom:CrossmarkDomainExclusive"",""true""
""Author"",""Alessandra Scafuro "",""Luisa Siniscalchi "",""Ivan Visconti ""
""CrossmarkDomainExclusive"",""true""
""doi"",""10.1007/978-3-030-17253-4_13""
""pdf:unmappedUnicodeCharsPerPage"",""1"",""0"",""0"",""0"",""0"",""8"",""0"",""10"",""1"",""4"",""9"",""4"",""4"",""12"",""4"",""13"",""12"",""9"",""16"",""2"",""1"",""8"",""21"",""12"",""4"",""0"",""0"",""0""
""dc:description"",""Public-Key Cryptography – PKC 2019, doi:10.1007/978-3-030-17253-4_13""
""access_permission:modify_annotations"",""true""
""dc:creator"",""Alessandra Scafuro "",""Luisa Siniscalchi "",""Ivan Visconti ""
""description"",""Public-Key Cryptography – PKC 2019, doi:10.1007/978-3-030-17253-4_13""
""dcterms:created"",""2019-04-02T14:19:59Z""
""Last-Modified"",""2019-04-02T14:22:54Z""
""dcterms:modified"",""2019-04-02T14:22:54Z""
""title"",""Publicly Verifiable Proofs from Blockchains""
""xmpMM:DocumentID"",""uuid:b718c9f7-c197-4371-8856-ffc3c977850f""
""Last-Save-Date"",""2019-04-02T14:22:54Z""
""CrossMarkDomains[1]"",""springer.com""
""pdf:docinfo:modified"",""2019-04-02T14:22:54Z""
""meta:save-date"",""2019-04-02T14:22:54Z""
""Content-Length"",""497719""
""Content-Type"",""application/pdf""
""xmp:MetadataDate"",""2019-04-02T19:52:54Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Alessandra Scafuro "",""Luisa Siniscalchi "",""Ivan Visconti ""
""pdfaid:conformance"",""B""
""dc:language"",""EN""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""28""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""2202"",""2802"",""2462"",""2600"",""2946"",""2620"",""2700"",""2440"",""2484"",""2637"",""1692"",""1804"",""1441"",""1959"",""2247"",""2376"",""2353"",""2429"",""2102"",""2356"",""2887"",""2127"",""2037"",""2244"",""2161"",""2932"",""3069"",""1197""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""CrossMarkDomains[2]"",""springerlink.com""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-04-02T14:19:59Z""
""CrossmarkMajorVersionDate"",""2010-04-23""
";https://scholar.google.com/scholar?start=420&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093509-428;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;[PDF][PDF] JusticeChain: Using Blockchain To Protect Justice Data;R Belchior ;2019 researchgate.net;;"… JusticeChain receives log entries from a set of oracles, processes them at the Log

Manager com … Ethereum. Ethereum aims to be a decentralized peer-to-peer

cryptocurrency and to support blockchain applications other than financial …";Autres articles;;[PDF] researchgate.net;https://www.researchgate.net/profile/Rafael_Belchior/publication/342735438_JusticeChain_Using_Blockchain_To_Protect_Justice_Data/links/5f042f6d92851c52d61dd7cb/JusticeChain-Using-Blockchain-To-Protect-Justice-Data.pdf;;;https://scholar.google.com/scholar?start=260&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093452-182;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;[HTML][HTML] Elastic and cost-effective data carrier architecture for smart contract in blockchain;X Liu, K Muhammad, J Lloret, YW Chen… ; Future Generation …, 2019  Elsevier;;"… In 2014, Ripple Labs [28] published a white paper of Smart Oracles and implemented a system

of smart oracles, called Codius [29], in which rules can be written in any programming … Recently,

the leading Oracle service for smart contracts and blockchain applications is …";Cité 16 fois;Les 5 versions;[HTML] sciencedirect.com;https://www.sciencedirect.com/science/article/pii/S0167739X18328334?casa_token=pSngZaw9YcQAAAAA:nlYP0S1bCjwzHmHicTyZpdWuO7H8rmHsahWH2cFmix2tNiRfuI94NS0I2xJWDenGALPBtq4Z;;;https://scholar.google.com/scholar?start=20&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093543-578;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;[PDF][PDF] Blockchain Architecture to Higher Education Systems;K Palanivel ; International Journal of Latest Technology in …, 2019  academia.edu;;"… Transactions - A transaction represents a transfer of the cryptocurrency between blockchain

network users. Each block in a blockchain can contain zero or more transactions. A

blockchain network user sends information to the blockchain network …";Cité 4 fois;Les 2 versions;[PDF] academia.edu;https://www.academia.edu/download/58597592/Blockchain_Architecture_to_Higher_Education_Systems.pdf;;;https://scholar.google.com/scholar?start=410&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093471-262;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;[PDF][PDF] Design and Development of a Blockchain Interoperability API;T Hegnauer ;2019 files.ifi.uzh.ch;;"… Atomic swaps are often used in the context of decentralized exchanges [47]. 2.3.3

Cross-chain oracles An oracle provides a blockchain with outside data. In the special case

of a cross-chain oracle, the data originates from another blockchain …";Cité 5 fois;;[PDF] uzh.ch;https://files.ifi.uzh.ch/CSG/staff/scheid/extern/theses/MA-T-Hegnauer.pdf;;"""date"",""2019-02-20T09:11:29Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2019-02-20T09:11:29Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017) kpathsea version 6.2.3""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2019-02-20T09:11:29Z""
""created"",""2019-02-20T09:11:29Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-02-20T09:11:29Z""
""resourceName"",""MA-T-Hegnauer.pdf""
""Author"",""""
""producer"",""pdfTeX-1.40.18""
""pdf:docinfo:producer"",""pdfTeX-1.40.18""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2019-02-20T09:11:29Z""
""Last-Modified"",""2019-02-20T09:11:29Z""
""dcterms:modified"",""2019-02-20T09:11:29Z""
""title"",""""
""Last-Save-Date"",""2019-02-20T09:11:29Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2019-02-20T09:11:29Z""
""meta:save-date"",""2019-02-20T09:11:29Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017) kpathsea version 6.2.3""
""Content-Length"",""546699""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""63""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""325"",""158"",""1690"",""2"",""248"",""2"",""867"",""1401"",""820"",""355"",""2182"",""2662"",""609"",""22"",""1367"",""2208"",""2069"",""2524"",""2616"",""2173"",""2080"",""1917"",""2051"",""1411"",""1411"",""2273"",""2065"",""245"",""1369"",""1742"",""2092"",""2179"",""1635"",""22"",""1820"",""1735"",""1868"",""1726"",""1928"",""1440"",""1455"",""1255"",""2255"",""1390"",""1882"",""658"",""2037"",""2787"",""2623"",""2728"",""2555"",""14"",""418"",""14"",""1271"",""10"",""124"",""15"",""296"",""14"",""453"",""1000"",""567""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-02-20T09:11:29Z""
";https://scholar.google.com/scholar?start=100&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093541-566;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;[PDF][PDF] Terra money: Stability and adoption;E Kereiakes, MDM Do Kwon, N Platias ;2019 res.tuoluocaijing.cn;;"… 2.2 Measuring stability with miner oracles Since the price of Terra currencies in secondary

markets is exogenous to the blockchain, the sys- tem must rely on a decentralized price

oracle to estimate the true exchange rate. We define the …";Cité 5 fois;Les 9 versions;[PDF] tuoluocaijing.cn;https://res.tuoluocaijing.cn/20190705164535-yagq.pdf;;"""date"",""2019-04-18T12:24:28Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.3""
""pdf:docinfo:title"",""terra-v1.1.pdf""
""xmp:CreatorTool"",""Preview""
""Keywords"",""""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""dcterms:created"",""2019-04-18T12:24:28Z""
""language"",""en""
""Last-Modified"",""2019-04-18T12:24:28Z""
""dcterms:modified"",""2019-04-18T12:24:28Z""
""dc:format"",""application/pdf; version=1.3""
""title"",""terra-v1.1.pdf""
""Last-Save-Date"",""2019-04-18T12:24:28Z""
""pdf:docinfo:creator_tool"",""Preview""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2019-04-18T12:24:28Z""
""meta:save-date"",""2019-04-18T12:24:28Z""
""pdf:encrypted"",""false""
""dc:title"",""terra-v1.1.pdf""
""modified"",""2019-04-18T12:24:28Z""
""Content-Length"",""659947""
""pdf:hasMarkedContent"",""false""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""dc:subject"",""""
""meta:creation-date"",""2019-04-18T12:24:28Z""
""created"",""2019-04-18T12:24:28Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""16""
""Creation-Date"",""2019-04-18T12:24:28Z""
""resourceName"",""20190705164535-yagq.pdf""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""820"",""2296"",""1802"",""1923"",""1888"",""1867"",""2025"",""1718"",""1875"",""1"",""2188"",""2108"",""1915"",""1966"",""890"",""615""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""meta:keyword"",""""
""producer"",""macOS Version 10.14.2 (Build 18C54) Quartz PDFContext""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""macOS Version 10.14.2 (Build 18C54) Quartz PDFContext""
""pdf:docinfo:created"",""2019-04-18T12:24:28Z""
";https://scholar.google.com/scholar?start=400&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093539-560;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;An Efficient Traceable and Anonymous Authentication Scheme for Permissioned Blockchain;Q Su, R Zhang, R Xue, Y Sun ; International Conference on Web Services, 2019  Springer;;"… The experimental results show that the proposed scheme is more efficient than exist schemes

and can be easily deployed in the permissioned blockchain … M,\delta _0, c, \delta _1)\) with

non-negligible probability, then there exists a replay with a different oracle, which can …";Cité 1 fois;Les 3 versions;null;;;;https://scholar.google.com/scholar?start=390&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093523-483;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Can Blockchain Really Help the Poor?;I So, WIT To ;2019 igiglobal.com;;"… of DApps that automate global risk sharing • DAO Governance and crypto-economics • Last … The

Blockchain: Flying Carpet connects data scientists who compete to create world-leading … analytics

from models while (DAO) smart contracts can access model analytics via oracles …";Autres articles;;null;;;;https://scholar.google.com/scholar?start=320&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093532-523;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Transwarp Conduit: Interoperable Blockchain Application Framework;S Hejazi;Sepehr, R Kitsis, A Sharif  arXiv preprint arXiv:1906.03256, 2019  arxiv.org;;"… cases include payment-versus-delivery, payment-versus-payment, cross-chain-oracles and other …

applications, a dependency relationship may be sufficiently expressive (eg an oracle publishing

the … the TWC presents a starting point for generic inter-blockchain message passing …";Cité 4 fois;Les 2 versions;[PDF] arxiv.org;https://arxiv.org/pdf/1906.03256;;"""date"",""2019-06-10T00:48:21Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2019-06-10T00:48:21Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016) kpathsea version 6.2.2""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2019-06-10T00:48:21Z""
""created"",""2019-06-10T00:48:21Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-06-10T00:48:21Z""
""resourceName"",""1906.03256""
""Author"",""""
""producer"",""pdfTeX-1.40.17""
""pdf:docinfo:producer"",""pdfTeX-1.40.17""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2019-06-10T00:48:21Z""
""Last-Modified"",""2019-06-10T00:48:21Z""
""dcterms:modified"",""2019-06-10T00:48:21Z""
""title"",""""
""Last-Save-Date"",""2019-06-10T00:48:21Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2019-06-10T00:48:21Z""
""meta:save-date"",""2019-06-10T00:48:21Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016) kpathsea version 6.2.2""
""Content-Length"",""341236""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""19""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""2798"",""2926"",""2355"",""3144"",""2767"",""1523"",""2801"",""2801"",""1968"",""3115"",""3391"",""4079"",""3566"",""1329"",""2613"",""943"",""2363"",""863"",""217""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-06-10T00:48:21Z""
";https://scholar.google.com/scholar?start=360&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093523-484;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;[PDF][PDF] Blockchain in the Energy Industry–Comprehensive Analysis of Potential Use Cases;M Hinterstocker, A Bogensperger… ; … Challenges for the …, 2019  iaee2019ljubljana.oyco.eu;;"… In this case, an oracle is applied to integrate the metered consumption in order to determine the

amount payable … The supplier transmits the corresponding time series to the blockchain via smart

contract oracles, which connect the blockchain to the outside world …";Cité 1 fois;Les 6 versions;[PDF] oyco.eu;https://iaee2019ljubljana.oyco.eu/download/contribution/fullpaper/209/209_fullpaper_20190823_131516.pdf;;"""date"",""2019-08-23T13:10:02Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.5""
""xmp:CreatorTool"",""MicrosoftÂŽ Word 2016""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""language"",""en""
""dcterms:created"",""2019-08-23T13:10:02Z""
""Last-Modified"",""2019-08-23T13:10:02Z""
""dcterms:modified"",""2019-08-23T13:10:02Z""
""dc:format"",""application/pdf; version=1.5""
""Last-Save-Date"",""2019-08-23T13:10:02Z""
""pdf:docinfo:creator_tool"",""MicrosoftÂŽ Word 2016""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2019-08-23T13:10:02Z""
""meta:save-date"",""2019-08-23T13:10:02Z""
""pdf:encrypted"",""false""
""modified"",""2019-08-23T13:10:02Z""
""Content-Length"",""973787""
""pdf:hasMarkedContent"",""false""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""dc:language"",""de-DE""
""meta:creation-date"",""2019-08-23T13:10:02Z""
""created"",""2019-08-23T13:10:02Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""12""
""Creation-Date"",""2019-08-23T13:10:02Z""
""resourceName"",""209_fullpaper_20190823_131516.pdf""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""4855"",""2312"",""6410"",""3495"",""2901"",""3405"",""3429"",""3058"",""6503"",""6601"",""5987"",""6966""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""producer"",""MicrosoftÂŽ Word 2016""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""MicrosoftÂŽ Word 2016""
""pdf:docinfo:created"",""2019-08-23T13:10:02Z""
";https://scholar.google.com/scholar?start=320&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093466-245;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Founding secure computation on blockchains;AR Choudhuri, V Goyal, A Jain ; … on the Theory and Applications of …, 2019  Springer;;"… round ZK arguments are impossible wrt black-box simulation in the blockchain-hybrid model …

Recall that black-box simulators can only query the adversarial verifier as an Oracle … several copies

of the adversary state (and hence, increasing the number of available Oracles) …";Cité 9 fois;Les 5 versions;[PDF] nsf.gov;https://par.nsf.gov/servlets/purl/10121103;;"""date"",""2019-04-05T11:55:23Z""
""pdf:PDFVersion"",""1.6""
""xmp:CreatorTool"",""Springer""
""pdf:docinfo:title"",""Founding Secure Computation on Blockchains""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""Advances in Cryptology – EUROCRYPT 2019, doi:10.1007/978-3-030-17656-3_13""
""pdfa:PDFVersion"",""A-2b""
""xmpMM:History:Action"",""converted"",""converted""
""language"",""en""
""dc:format"",""application/pdf; version=""""A-2b"""""",""application/pdf; version=1.6""
""pdf:docinfo:custom:robots"",""noindex""
""pdf:docinfo:creator_tool"",""Springer""
""access_permission:fill_in_form"",""true""
""xmpMM:History:When"",""2019-04-05T17:24:16Z"",""2019-04-05T17:25:23Z""
""pdf:encrypted"",""false""
""dc:title"",""Founding Secure Computation on Blockchains""
""xmp:CreateDate"",""2019-04-05T17:23:45Z""
""modified"",""2019-04-05T11:55:23Z""
""cp:subject"",""Advances in Cryptology – EUROCRYPT 2019, doi:10.1007/978-3-030-17656-3_13""
""xmpMM:History:SoftwareAgent"",""pdfToolbox"",""pdfToolbox""
""pdf:docinfo:custom:CrossMarkDomains[1]"",""springer.com""
""robots"",""noindex""
""pdf:docinfo:subject"",""Advances in Cryptology – EUROCRYPT 2019, doi:10.1007/978-3-030-17656-3_13""
""pdf:hasMarkedContent"",""false""
""xmpMM:History:InstanceID"",""uuid:a89d8117-a5ac-44cb-ac87-5d63626af1a8"",""uuid:b7214036-be83-43ce-a1b3-355a23f9845a""
""xmp:ModifyDate"",""2019-04-05T17:25:23Z""
""pdf:docinfo:creator"",""Arka Rai Choudhuri ""
""meta:author"",""Arka Rai Choudhuri "",""Vipul Goyal "",""Abhishek Jain ""
""meta:creation-date"",""2019-04-05T11:53:45Z""
""pdf:docinfo:custom:CrossmarkMajorVersionDate"",""2010-04-23""
""created"",""2019-04-05T11:53:45Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-04-05T11:53:45Z""
""resourceName"",""10121103""
""pdfaid:part"",""2""
""pdf:docinfo:custom:CrossMarkDomains[2]"",""springerlink.com""
""pdf:docinfo:custom:doi"",""10.1007/978-3-030-17656-3_13""
""pdf:docinfo:custom:CrossmarkDomainExclusive"",""true""
""Author"",""Arka Rai Choudhuri "",""Vipul Goyal "",""Abhishek Jain ""
""CrossmarkDomainExclusive"",""true""
""doi"",""10.1007/978-3-030-17656-3_13""
""pdf:unmappedUnicodeCharsPerPage"",""1"",""0"",""0"",""0"",""0"",""0"",""0"",""3"",""0"",""0"",""0"",""12"",""20"",""0"",""0"",""8"",""63"",""14"",""0"",""13"",""14"",""5"",""16"",""54"",""50"",""12"",""0"",""0"",""0"",""0""
""dc:description"",""Advances in Cryptology – EUROCRYPT 2019, doi:10.1007/978-3-030-17656-3_13""
""access_permission:modify_annotations"",""true""
""dc:creator"",""Arka Rai Choudhuri "",""Vipul Goyal "",""Abhishek Jain ""
""description"",""Advances in Cryptology – EUROCRYPT 2019, doi:10.1007/978-3-030-17656-3_13""
""dcterms:created"",""2019-04-05T11:53:45Z""
""Last-Modified"",""2019-04-05T11:55:23Z""
""dcterms:modified"",""2019-04-05T11:55:23Z""
""title"",""Founding Secure Computation on Blockchains""
""xmpMM:DocumentID"",""uuid:c42b5b10-7a57-4eec-82b1-c601807d4756""
""Last-Save-Date"",""2019-04-05T11:55:23Z""
""CrossMarkDomains[1]"",""springer.com""
""pdf:docinfo:modified"",""2019-04-05T11:55:23Z""
""meta:save-date"",""2019-04-05T11:55:23Z""
""Content-Length"",""595871""
""Content-Type"",""application/pdf""
""xmp:MetadataDate"",""2019-04-05T17:25:23Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Arka Rai Choudhuri "",""Vipul Goyal "",""Abhishek Jain ""
""pdfaid:conformance"",""B""
""dc:language"",""EN""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""30""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""2107"",""2585"",""2274"",""2594"",""2834"",""2887"",""2706"",""2791"",""2756"",""2257"",""2556"",""2032"",""1902"",""2483"",""2872"",""1823"",""2644"",""2431"",""2547"",""2242"",""2121"",""2331"",""2709"",""2281"",""2112"",""2426"",""2972"",""2891"",""3009"",""2440""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""CrossMarkDomains[2]"",""springerlink.com""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-04-05T11:53:45Z""
""CrossmarkMajorVersionDate"",""2010-04-23""
";https://scholar.google.com/scholar?start=80&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093536-549;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;[LIVRE][B] Advances in Cryptology–CRYPTO 2019: 39th Annual International Cryptology Conference, Santa Barbara, CA, USA, August 18–22, 2019, Proceedings, Part …;A Boldyreva, D Micciancio ;2019 books.google.com;;"… Preface The 39th International Cryptology Conference (Crypto 2019) was held at the University

of California, Santa Barbara, California, USA … a Workshop on Attacks in Cryptography organized

by Juraj Somor- ovsky (Ruhr University Bochum); a Blockchain Workshop organized …";Cité 3 fois;Les 4 versions;null;;;;https://scholar.google.com/scholar?start=380&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093530-516;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;[PDF][PDF] Overview of Blockchain Technology and Survey of Security Issues, Challenges, and Solutions in IoT;AKMB Haque ; researchgate.net;;"… Later in 2008, a group of anonymous people known by the name Satoshi Nakamoto [1], invented

the first Blockchain based cryptocurrency known as Bitcoin for digital transactions [2]. A blockchain

is a distributed digital ledger which consists of an ordered series of blocks for …";Autres articles;Version HTML;[PDF] researchgate.net;https://www.researchgate.net/profile/A_K_M_Bahalul_Haque/publication/340942811_Overview_of_Blockchain_Technology_and_Solution_of_IoT_Security_Issues_from_Blockchain_Perspective/links/5f5b5804a6fdcc1164095752/Overview-of-Blockchain-Technology-and-Solution-of-IoT-Security-Issues-from-Blockchain-Perspective.pdf;;;https://scholar.google.com/scholar?start=350&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093462-226;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Data quality control in blockchain applications;C Cappiello, M Comuzzi, F Daniel, G Meroni ; International Conference on …, 2019  Springer;;"… In order to obtain data from the outside world, so-called oracle smart contracts (short “oracles”)

can be used, which enable external data sources to push data into the blockchain, eg, upon

explicit solicitation or periodically – however, using standard transactions that …";Cité 10 fois;Les 5 versions;[PDF] floriandaniel.it;http://www.floriandaniel.it/papers/CappielloBCForum2019.pdf;;"""date"",""2019-07-08T14:34:20Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2019-07-08T14:34:20Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017) kpathsea version 6.2.3""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2019-07-08T14:34:20Z""
""created"",""2019-07-08T14:34:20Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-07-08T14:34:20Z""
""resourceName"",""CappielloBCForum2019.pdf""
""Author"",""""
""producer"",""pdfTeX-1.40.18""
""pdf:docinfo:producer"",""pdfTeX-1.40.18""
""pdf:unmappedUnicodeCharsPerPage"",""2"",""0"",""0"",""2"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2019-07-08T14:34:20Z""
""Last-Modified"",""2019-07-08T14:34:20Z""
""dcterms:modified"",""2019-07-08T14:34:20Z""
""title"",""""
""Last-Save-Date"",""2019-07-08T14:34:20Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2019-07-08T14:34:20Z""
""meta:save-date"",""2019-07-08T14:34:20Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017) kpathsea version 6.2.3""
""Content-Length"",""512328""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""15""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""2288"",""2966"",""2610"",""2881"",""2170"",""2537"",""2199"",""2643"",""2085"",""2071"",""2213"",""2458"",""2666"",""2603"",""2750""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-07-08T14:34:20Z""
";https://scholar.google.com/scholar?start=60&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093511-435;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;[PDF][PDF] Second International Symposium on Foundations and Applications of Blockchain;S Barahmand, S Ghandeharizadeh, B Krishnamachari… ;2019 curis.ku.dk;;"… all participants and guarantees a consistent view of all user transactions by all participants in

the cryptocurrency system … Sarabjeet (Jay) Singh Senior Director of Products at Oracle … You hear

about blockchain, IoT, and artificial intelligence at every turn, but how much is hype and …";Autres articles;;[PDF] ku.dk;https://curis.ku.dk/portal/files/240007509/FAB2019Proceedings_1.pdf;;"""date"",""2020-04-24T08:24:04Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""1"",""0"",""10"",""8"",""0"",""0"",""0"",""0"",""1"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.7""
""xmp:CreatorTool"",""PDF Architect 5""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dc:creator"",""sumitab""
""dcterms:created"",""2019-04-04T16:16:24Z""
""language"",""en""
""Last-Modified"",""2020-04-24T08:24:04Z""
""dcterms:modified"",""2020-04-24T08:24:04Z""
""dc:format"",""application/pdf; version=1.7""
""xmpMM:DocumentID"",""uuid:39058b7a-b1e8-4813-bebb-a2e93d9fbfed""
""Last-Save-Date"",""2020-04-24T08:24:04Z""
""pdf:docinfo:creator_tool"",""PDF Architect 5""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2020-04-24T08:24:04Z""
""meta:save-date"",""2020-04-24T08:24:04Z""
""pdf:encrypted"",""false""
""xmp:CreateDate"",""2019-04-04T09:16:24Z""
""modified"",""2020-04-24T08:24:04Z""
""pdf:hasMarkedContent"",""false""
""Content-Type"",""application/pdf""
""xmp:ModifyDate"",""2020-04-24T10:24:04Z""
""pdf:docinfo:creator"",""sumitab""
""xmp:MetadataDate"",""2020-04-24T10:24:04Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""sumitab""
""meta:author"",""sumitab""
""pdf:producer"",""PDF Architect 5""
""meta:creation-date"",""2019-04-04T16:16:24Z""
""created"",""2019-04-04T16:16:24Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""55""
""Creation-Date"",""2019-04-04T16:16:24Z""
""resourceName"",""FAB2019Proceedings_1.pdf""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""785"",""258"",""1516"",""2858"",""838"",""1425"",""247"",""106"",""2609"",""1190"",""1303"",""1828"",""1922"",""1635"",""1463"",""4197"",""1933"",""3734"",""4106"",""3887"",""3583"",""3234"",""3982"",""2564"",""3244"",""1934"",""2490"",""4082"",""1834"",""3786"",""5646"",""4469"",""3882"",""3006"",""4368"",""4872"",""5244"",""5489"",""5120"",""3651"",""5669"",""1747"",""4824"",""6006"",""5908"",""5682"",""6075"",""2581"",""5173"",""5867"",""4455"",""1253"",""3509"",""1184"",""44""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""Author"",""sumitab""
""producer"",""PDF Architect 5""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""PDF Architect 5""
""pdf:docinfo:created"",""2019-04-04T16:16:24Z""
";https://scholar.google.com/scholar?start=270&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093450-180;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;A primer for information technology general control considerations on a private and permissioned blockchain audit;MD Sheldon ; Current Issues in Auditing, 2019  meridian.allenpress.com;;"… Changes to smart contracts and Dapps occur through transactions loaded to the blockchain.

The figure also shows a smart contract linked to an oracle, which highlights that auditors must

also consider the appropriateness of changes to smart contract oracles …";Cité 30 fois;Les 2 versions;null;;;;https://scholar.google.com/scholar?start=10&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093471-266;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;MatRiCT: Efficient, scalable and post-quantum blockchain confidential transactions protocol;MF Esgin, RK Zhao, R Steinfeld, JK Liu… ; Proceedings of the 2019 …, 2019  dl.acm.org;;"… a security proof in the quantum random oracle model (even if random oracle model is … A RingCT

protocol allows users to create confidential transac- tions on blockchain so that the … Monero

cryptocurrency is currently the most prominent appli- cation that heavily relies on RingCT …";Cité 23 fois;Les 3 versions;[PDF] acm.org;https://dl.acm.org/doi/pdf/10.1145/3319535.3354200?casa_token=6roDqDQllSwAAAAA:sMTPEMpAynE_YkM8fwuDJ9WmhBmkTjvl4--AgR9Czd7Pg_v0ICEwqpcLGLMv-mLA7rvRQKhNY7U;;;https://scholar.google.com/scholar?start=100&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093497-376;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;[PDF][PDF] A cybersecurity control framework for blockchain ecosystems;J Canelón, E Huerta, J Incera, T Ryan ; The International Journal of …, 2019  core.ac.uk;;"… More recently, in May 2017, the WannaCry crypto-ransomware, which infected around 230,000 …

On the other hand, the other components of a blockchain ecosystem (oracles, arbitrators, wallets …

can append a block to the chain depends on the implementation of the blockchain …";Cité 2 fois;Les 4 versions;[PDF] core.ac.uk;https://core.ac.uk/download/pdf/286077261.pdf;;"""date"",""2019-12-02T11:00:56Z""
""pdf:PDFVersion"",""1.5""
""xmp:CreatorTool"",""Acrobat PDFMaker 11 para Word""
""pdf:docinfo:title"",""""
""Company"",""""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""Acrobat PDFMaker 11 para Word""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""xmp:CreateDate"",""2019-11-27T15:11:33Z""
""modified"",""2019-12-02T11:00:56Z""
""pdf:docinfo:custom:SourceModified"",""D:20191127141101""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""true""
""xmp:ModifyDate"",""2019-12-02T12:00:56Z""
""pdf:docinfo:creator"",""LF""
""meta:author"",""LF""
""meta:creation-date"",""2019-11-27T14:11:33Z""
""created"",""2019-11-27T14:11:33Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-11-27T14:11:33Z""
""resourceName"",""286077261.pdf""
""pdf:docinfo:custom:Comments"",""""
""Author"",""LF""
""producer"",""Adobe PDF Library 11.0""
""pdf:docinfo:producer"",""Adobe PDF Library 11.0""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""LF""
""dcterms:created"",""2019-11-27T14:11:33Z""
""Last-Modified"",""2019-12-02T11:00:56Z""
""dcterms:modified"",""2019-12-02T11:00:56Z""
""title"",""""
""xmpMM:DocumentID"",""uuid:2c869be2-241f-4320-af12-da7ae65959fe""
""Last-Save-Date"",""2019-12-02T11:00:56Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2019-12-02T11:00:56Z""
""meta:save-date"",""2019-12-02T11:00:56Z""
""Content-Length"",""417829""
""Content-Type"",""application/pdf""
""xmp:MetadataDate"",""2019-12-02T12:00:56Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""LF""
""pdf:producer"",""Adobe PDF Library 11.0""
""dc:subject"",""""
""Comments"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""42""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""1506"",""2709"",""2589"",""2435"",""1326"",""2012"",""2559"",""1684"",""2412"",""2516"",""2538"",""2685"",""1150"",""2448"",""2470"",""2507"",""2564"",""2475"",""2802"",""2688"",""2698"",""2525"",""2451"",""2422"",""1055"",""1616"",""1328"",""2261"",""2638"",""2278"",""1885"",""2233"",""2158"",""2302"",""1741"",""1494"",""368"",""1286"",""1428"",""1403"",""1342"",""1307""
""access_permission:extract_content"",""true""
""pdf:docinfo:custom:Company"",""""
""access_permission:can_print"",""true""
""SourceModified"",""D:20191127141101""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-11-27T14:11:33Z""
";https://scholar.google.com/scholar?start=210&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093487-335;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;[PDF][PDF] Identity-based public auditing for cloud storage systems against malicious auditors via blockchain;J Xue, C Xu, J Zhao, J Ma ; Science China Information Sciences, 2019  Springer;;"… (2) We show that IBPA is secure under the random oracle model, and that this security is based

on the computational Diffie-Hellman problem, while maintaining good efficiency … This design

1) The cryptocurrency for payments based on blockchain technology …";Cité 30 fois;Les 5 versions;[PDF] springer.com;https://idp.springer.com/authorize/casa?redirect_uri=https://link.springer.com/content/pdf/10.1007/s11432-018-9462-0.pdf&casa_token=V4dkZTJy1eQAAAAA:3rERgfJbilCxVOVS3UncqciB6P9RMFgP2CL6XLT9gsSz_vzngmrFDQAr5IxVtHSZG_L94kshgkJvor8;;;https://scholar.google.com/scholar?start=170&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093497-379;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Hyperservice: Interoperability and programmability across heterogeneous blockchains;Z Liu, Y Xiang, J Shi, P Gao, H Wang, X Xiao… ; Proceedings of the …, 2019  dl.acm.org;;"… Existing oracles [13, 62] require a smart contract on the blockchain to serve as the front-end to

interact with … cannot simply deploy an oracle smart contract on each individual blockchain since

synchronizing the execution of those oracle contracts requires … Session 3B: Blockchain I …";Cité 15 fois;X Xiao;[PDF] acm.org;https://dl.acm.org/doi/pdf/10.1145/3319535.3355503?casa_token=Kn9FaS9HyDYAAAAA:OA0xWDxfo1j7CZBKzScmqADxEFyQ0lKeLS9OSTSFGcRJP72cuzcsaMjPeAWTwkzZF52oYxAYhBI;;;https://scholar.google.com/scholar?start=210&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093494-368;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;[HTML][HTML] A review of edge computing reference architectures and a new global edge proposal;I Sittón;Candanedo, RS Alonso, JM Corchado…  Future Generation …, 2019  Elsevier;;"… this entails. Even though blockchain has originally been created as a tool for

cryptocurrencies, the use of a BC in decentralised applications does not necessarily

have to involve the development of a cryptocurrency. As its name …";Cité 88 fois;Les 4 versions;[HTML] sciencedirect.com;https://www.sciencedirect.com/science/article/pii/S0167739X1930264X?casa_token=Bu9mQVCu8lQAAAAA:_avD-AlubH8b5YCq9gUwx2ye4klWxUiCZmwPTHhKlVypZFJBB7Dg1q18hSVQEmwDDNCPEU6V;;;https://scholar.google.com/scholar?start=200&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093448-165;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;From oracles to trustworthy data on-chaining systems;J Heiss, J Eberhardt, S Tai ; … on Blockchain (Blockchain), 2019  ieeexplore.ieee.org;;"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 …";Cité 25 fois;Les 7 versions;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/8938397/8946120/08946220.pdf?casa_token=EQzclIk7ep4AAAAA:ToIYmk6R9qJ0wIYEeiT4CjA9ogHgcSBardGe3Ifh1PBkmskYUl7a3xb1onpih7KDLi5Cp1_Fa9E;;"""og:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""twitter:title"",""From Oracles to Trustworthy Data On-Chaining Systems""
""twitter:card"",""summary""
""Description"",""Many blockchain transactions require blockchain-external data sources to provide data. Oracle systems have been proposed as a link between blockchains and block""
""og:title"",""From Oracles to Trustworthy Data On-Chaining Systems""
""resourceName"",""08946220.pdf""
""language"",""en""
""title"",""From Oracles to Trustworthy Data On-Chaining Systems | IEEE Conference Publication | IEEE Xplore""
""og:description"",""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.""
""twitter:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-UA-Compatible"",""IE=Edge""
""viewport"",""width=device-width, initial-scale=1.0""
""dc:title"",""From Oracles to Trustworthy Data On-Chaining Systems | IEEE Conference Publication | IEEE Xplore""
""twitter:description"",""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.""
""Content-Encoding"",""UTF-8""
""Content-Type-Hint"",""text/html; charset=utf-8""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";
1619093478-297;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;[HTML][HTML] Blockchain-based platforms: Decentralized infrastructures and its boundary conditions;J Pereira, MM Tavalaei, H Ozalp ; Technological Forecasting and Social …, 2019  Elsevier;;"… the physical world, which necessities the existence of some trustable parties (which are called

oracles), without which … outweigh the losses from increased technology cost of verification and

storage, the blockchain-based platforms … Community involvement and crypto-incentives …";Cité 30 fois;Les 11 versions;[HTML] sciencedirect.com;https://www.sciencedirect.com/science/article/pii/S0040162518319693?casa_token=nte_LanZxr0AAAAA:1tK0lh6sSoVuMx04oNyRwDz7hRtz3qoPEgo3yI0PTlTUNzPJU7g5r4I3iHt5WaLyFLwe4tpE;;;https://scholar.google.com/scholar?start=130&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093539-551;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Blockchain's fame reaches the execution of personalized touristic itineraries;A Brahem, N Messai, Y Sam, S Bhiri… ; 2019 IEEE 28th …, 2019  ieeexplore.ieee.org;;"… This data is already stored in the blockchain … In more details, oracles forward a request from

external application to the smart contract via a Solidity event and … Consequently for each generated

choreography smart contract, an oracle is also generated to deal with external data …";Cité 1 fois;Les 7 versions;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/8790376/8795366/08795436.pdf?casa_token=9yF0aaElAmQAAAAA:fq5thl_tNvX4WX-YkUCyfydISKkS8KmTw-EEaZWBISTmA1QIq_clyF_zXWRctPzJ1cUQeElJ_04;;"""og:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""twitter:title"",""Blockchain's Fame Reaches the Execution of Personalized Touristic Itineraries""
""twitter:card"",""summary""
""Description"",""Blockchain trends cover more and more tech domains making it one of the most used technologies in the last few years. This is due to two essential aspects. Firs""
""og:title"",""Blockchain's Fame Reaches the Execution of Personalized Touristic Itineraries""
""resourceName"",""08795436.pdf""
""language"",""en""
""title"",""Blockchain's Fame Reaches the Execution of Personalized Touristic Itineraries | IEEE Conference Publication | IEEE Xplore""
""og:description"",""Blockchain trends cover more and more tech domains making it one of the most used technologies in the last few years. This is due to two essential aspects. First, it is a distributed peer-to-peer network where there is no need for third part to execute operations between peers. Second, blockchain implements mechanisms to make the most data sensitive operations executed in a trusted way. Regarding these attractive aspects, we intend in this work to use the blockchain technology for the implementation of touristic itineraries. We consider the latter as process choreographies involving different participants. We intend to model and execute the touristic itineraries generated from a personalized trip planner called CART in raw XML format in a way that respects this collaborative aspect and resolves the problem of trust. We will propose a pattern and its transformation rules to reconstruct the itineraries presented in declarative annotations such as XML to smart contracts written in some smart contract-specific programming language called Solidity. Experimental results show promising perspectives of the deployment of the proposed solution to execute touristic plans.""
""twitter:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-UA-Compatible"",""IE=Edge""
""viewport"",""width=device-width, initial-scale=1.0""
""dc:title"",""Blockchain's Fame Reaches the Execution of Personalized Touristic Itineraries | IEEE Conference Publication | IEEE Xplore""
""twitter:description"",""Blockchain trends cover more and more tech domains making it one of the most used technologies in the last few years. This is due to two essential aspects. First, it is a distributed peer-to-peer network where there is no need for third part to execute operations between peers. Second, blockchain implements mechanisms to make the most data sensitive operations executed in a trusted way. Regarding these attractive aspects, we intend in this work to use the blockchain technology for the implementation of touristic itineraries. We consider the latter as process choreographies involving different participants. We intend to model and execute the touristic itineraries generated from a personalized trip planner called CART in raw XML format in a way that respects this collaborative aspect and resolves the problem of trust. We will propose a pattern and its transformation rules to reconstruct the itineraries presented in declarative annotations such as XML to smart contracts written in some smart contract-specific programming language called Solidity. Experimental results show promising perspectives of the deployment of the proposed solution to execute touristic plans.""
""Content-Encoding"",""UTF-8""
""Content-Type-Hint"",""text/html; charset=utf-8""
""Content-Length"",""42143""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=390&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093483-318;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Blockchain 3.0 smart contracts in E-government 3.0 applications;S Terzi, K Votis, D Tzovaras, I Stamelos… ; arXiv preprint arXiv …, 2019  arxiv.org;;"… An exception is made through oracles to write data on the BC that represents the … Oracle-based

SCs inform citizens how their energy dispatching can be more profitable and provide …

it/wiki/Proof_of_work [12] K. Wüst and A. Gervais, ""Do you Need a Blockchain?,"" 2018 Crypto …";Cité 3 fois;Les 2 versions;[PDF] arxiv.org;https://arxiv.org/pdf/1910.06092;;"""date"",""2019-10-11T07:03:19Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.5""
""xmp:CreatorTool"",""MicrosoftÂŽ Word 2016""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dc:creator"",""IEEE""
""language"",""en""
""dcterms:created"",""2019-10-11T07:03:19Z""
""Last-Modified"",""2019-10-11T07:03:19Z""
""dcterms:modified"",""2019-10-11T07:03:19Z""
""dc:format"",""application/pdf; version=1.5""
""Last-Save-Date"",""2019-10-11T07:03:19Z""
""pdf:docinfo:creator_tool"",""MicrosoftÂŽ Word 2016""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2019-10-11T07:03:19Z""
""meta:save-date"",""2019-10-11T07:03:19Z""
""pdf:encrypted"",""false""
""modified"",""2019-10-11T07:03:19Z""
""Content-Length"",""516118""
""pdf:hasMarkedContent"",""true""
""Content-Type"",""application/pdf""
""pdf:docinfo:creator"",""IEEE""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""IEEE""
""dc:language"",""en-US""
""meta:author"",""IEEE""
""meta:creation-date"",""2019-10-11T07:03:19Z""
""created"",""2019-10-11T07:03:19Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""6""
""Creation-Date"",""2019-10-11T07:03:19Z""
""resourceName"",""1910.06092""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""4909"",""6394"",""4972"",""5729"",""6637"",""3856""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""Author"",""IEEE""
""producer"",""MicrosoftÂŽ Word 2016""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""MicrosoftÂŽ Word 2016""
""pdf:docinfo:created"",""2019-10-11T07:03:19Z""
";https://scholar.google.com/scholar?start=150&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093518-462;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;[LIVRE][B] Blockchain and cryptocurrencies technologies and network structures: applications, implications and beyond;L Morhaim ;2019 books.google.com;;"… Marmoz[380], Berg et al.[69], see also Ostbye[441] on liability issue if a public cryptocurrency

protocol fails … smart contracts react to information coming from external sources (sensors, human

interfaces, other applications), often called oracles in the blockchain jargon, which …";Cité 3 fois;Les 4 versions;[PDF] archives-ouvertes.fr;https://hal.archives-ouvertes.fr/hal-02280279/document;;"""date"",""2019-09-04T23:12:13Z""
""pdf:PDFVersion"",""1.4""
""pdf:docinfo:title"",""Blockchain and cryptocurrencies technologies and network structures: applications, implications and beyond""
""xmp:CreatorTool"",""HAL""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""Mathematics [math]/Optimization and Control [math.OC]""
""language"",""en""
""dc:format"",""application/pdf; version=1.4""
""pdf:docinfo:creator_tool"",""HAL""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""Blockchain and cryptocurrencies technologies and network structures: applications, implications and beyond""
""modified"",""2019-09-04T23:12:13Z""
""cp:subject"",""Mathematics [math]/Optimization and Control [math.OC]""
""pdf:docinfo:subject"",""Mathematics [math]/Optimization and Control [math.OC]""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""Lisa Morhaim""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.1415926-2.5-1.40.14 (TeX Live 2013) kpathsea version 6.1.1""
""meta:author"",""Lisa Morhaim""
""trapped"",""False""
""meta:creation-date"",""2021-04-06T22:02:25Z""
""created"",""2021-04-06T22:02:25Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2021-04-06T22:02:25Z""
""resourceName"",""document""
""Author"",""Lisa Morhaim""
""producer"",""PDFLaTeX""
""pdf:docinfo:producer"",""PDFLaTeX""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""4"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""Keywords"",""Blockchain, Cryptocurrency, Technologies, Network structures, Applications, Implications, Eco- nomics, Law, Geography, Humanities, Interdisciplinary research *""
""access_permission:modify_annotations"",""true""
""dc:creator"",""Lisa Morhaim""
""dcterms:created"",""2021-04-06T22:02:25Z""
""Last-Modified"",""2019-09-04T23:12:13Z""
""dcterms:modified"",""2019-09-04T23:12:13Z""
""title"",""Blockchain and cryptocurrencies technologies and network structures: applications, implications and beyond""
""Last-Save-Date"",""2019-09-04T23:12:13Z""
""pdf:docinfo:keywords"",""Blockchain, Cryptocurrency, Technologies, Network structures, Applications, Implications, Eco- nomics, Law, Geography, Humanities, Interdisciplinary research *""
""pdf:docinfo:modified"",""2019-09-04T23:12:13Z""
""meta:save-date"",""2019-09-04T23:12:13Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.1415926-2.5-1.40.14 (TeX Live 2013) kpathsea version 6.1.1""
""Content-Length"",""566609""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Lisa Morhaim""
""dc:subject"",""Blockchain, Cryptocurrency, Technologies, Network structures, Applications, Implications, Eco- nomics, Law, Geography, Humanities, Interdisciplinary research *""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""60""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""806"",""1102"",""2521"",""3842"",""4201"",""3703"",""3920"",""3713"",""3267"",""3537"",""2946"",""3956"",""3566"",""3120"",""3594"",""3758"",""3653"",""4093"",""3196"",""3477"",""3560"",""3367"",""3885"",""3355"",""2558"",""2532"",""2878"",""2434"",""2259"",""2551"",""2574"",""2428"",""2771"",""2649"",""2538"",""2430"",""2336"",""2528"",""2441"",""2427"",""2411"",""2463"",""2333"",""2263"",""2585"",""2632"",""2641"",""2406"",""2586"",""2476"",""2687"",""2529"",""2396"",""2299"",""2532"",""2658"",""2639"",""2464"",""2482"",""2627""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""Blockchain, Cryptocurrency, Technologies, Network structures, Applications, Implications, Eco- nomics, Law, Geography, Humanities, Interdisciplinary research *""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2021-04-06T22:02:25Z""
";https://scholar.google.com/scholar?start=300&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093450-177;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Justicechain: Using blockchain to protect justice logs;R Belchior, M Correia, A Vasconcelos ; … On the Move to Meaningful Internet …, 2019  Springer;;"… An oracle in the context of our problem is a component that retrieves applicational logs from an …

JusticeChain Log Manager (Log Manager): is connected to one or more oracles … After that, the

Log Manager submits a transaction to the blockchain, on the correspondent Logger's …";Cité 9 fois;Les 6 versions;[PDF] qualichain-project.eu;https://qualichain-project.eu/quali-data/uploads/2019/10/Paper_JusticeChain_CoopIS_2019.pdf;;;https://scholar.google.com/scholar?start=10&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093450-176;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Blockchain for 5G: opportunities and challenges;A Chaer, K Salah, C Lima, PP Ray… ; 2019 IEEE Globecom …, 2019  ieeexplore.ieee.org;;"… [13] Z. Li, J. Kang, R. Yu, D. Ye, Q. Deng, and Y. Zhang, “Consortium blockchain for secure

energy trading in industrial internet of things,” [14] Brian Curran, “What are Oracles? Smart

Contracts, Chainlink and 'The Oracle Problem.'” [Online] …";Cité 28 fois;Les 2 versions;null;;;;https://scholar.google.com/scholar?start=10&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093513-442;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Blockchain bringing Paradigm Shift in Indian Governmental Society Functioning;S Kesharwani, MP Sarkar ; CYBERNOMICS, 2019  cybernomics.in;;"… furthermore, Oracle IoT provides functionality to track vital information like chemical ingredients

of the drug or maintenance of temperature control in case of life saving drugs … Philanthropy, Aid

And Donors Crypto-philanthropy refers to the utilization of blockchain technology to …";Autres articles;;[PDF] cybernomics.in;http://www.cybernomics.in/index.php/cnm/article/download/49/37;;"""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""dc:title"",""302 Found""
""Content-Encoding"",""ISO-8859-1""
""resourceName"",""37""
""language"",""en""
""Content-Length"",""247""
""title"",""302 Found""
""Content-Type"",""text/html; charset=ISO-8859-1""
";https://scholar.google.com/scholar?start=280&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093539-558;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;[PDF][PDF] Beyond the Hype of Blockchain–A Scenario-Based Analysis of the Potential Applications in the Music Industry;A Gidron, M Kessels ; Louvain School of Management, Universit項, 2019  dial.uclouvain.be;;"… [Downloaded 2020/10/29 at 08:14:52 ] ""Beyond the Hype of Blockchain - A Scenario-Based

Analysis of the Potential Applications in the Music Industry"" Gidron, Aviv … Page 2. Louvain School

of Management Beyond the Hype of Blockchain – A Scenario-Based Analysis of the …";Cité 2 fois;Les 2 versions;[PDF] uclouvain.be;https://dial.uclouvain.be/downloader/downloader.php?pid=thesis%3A20817&datastream=PDF_01;;"""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""dc:title"",""DIAL : download document""
""Content-Encoding"",""UTF-8""
""resourceName"",""downloader.php""
""language"",""fr""
""title"",""DIAL : download document""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=390&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093464-238;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;[PDF][PDF] Towards mechanising probabilistic properties of a blockchain;K Gopinathan, I Sergey ;2019 gopiandcode.uk;;"… Oracles are a standard way of representing non- determinism within Coq [8]; we utilise an oracle

to capture the … on worlds would prevent a probabilistic analysis of the random values returned

by the oracle, we must … Towards Mechanising Probabilistic Properties of a Blockchain …";Cité 7 fois;Les 4 versions;[PDF] gopiandcode.uk;https://gopiandcode.uk/pdfs/probchain-coqpl19.pdf;;"""date"",""2018-11-22T18:06:23Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""Towards Mechanising Probabilistic Properties of a Blockchain""
""xmp:CreatorTool"",""LaTeX with acmart 2018/04/14 v1.53 Typesetting articles for the Association for Computing Machinery and hyperref 2017/03/14 v6.85a Hypertext links for LaTeX""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with acmart 2018/04/14 v1.53 Typesetting articles for the Association for Computing Machinery and hyperref 2017/03/14 v6.85a Hypertext links for LaTeX""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""Towards Mechanising Probabilistic Properties of a Blockchain""
""modified"",""2018-11-22T18:06:23Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""Kiran Gopinathan and Ilya Sergey""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017) kpathsea version 6.2.3""
""meta:author"",""Kiran Gopinathan and Ilya Sergey""
""trapped"",""False""
""meta:creation-date"",""2018-11-22T18:06:23Z""
""created"",""2018-11-22T18:06:23Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2018-11-22T18:06:23Z""
""resourceName"",""probchain-coqpl19.pdf""
""Author"",""Kiran Gopinathan and Ilya Sergey""
""producer"",""pdfTeX-1.40.18""
""pdf:docinfo:producer"",""pdfTeX-1.40.18""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""4"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""Kiran Gopinathan and Ilya Sergey""
""dcterms:created"",""2018-11-22T18:06:23Z""
""Last-Modified"",""2018-11-22T18:06:23Z""
""dcterms:modified"",""2018-11-22T18:06:23Z""
""title"",""Towards Mechanising Probabilistic Properties of a Blockchain""
""Last-Save-Date"",""2018-11-22T18:06:23Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2018-11-22T18:06:23Z""
""meta:save-date"",""2018-11-22T18:06:23Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017) kpathsea version 6.2.3""
""Content-Length"",""597335""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Kiran Gopinathan and Ilya Sergey""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""3""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""5396"",""5110"",""1181""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2018-11-22T18:06:23Z""
";https://scholar.google.com/scholar?start=70&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093466-248;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Blockchain analytics and artificial intelligence;DN Dillenberger, P Novotny, Q Zhang… ; IBM Journal of …, 2019  ieeexplore.ieee.org;;"… intelligence Page | 1 Blockchain analytics and artificial intelligence … Sarpatwar Blockchain

records track information about financial payments, movements of products through supply

chains, identity verification information, and many other assets …";Cité 25 fois;Les 4 versions;[PDF] researchgate.net;https://www.researchgate.net/profile/Qi-Zhang-126/publication/331241223_Blockchain_Analytics_and_Artificial_Intelligence/links/5c79ee12299bf1268d30af9e/Blockchain-Analytics-and-Artificial-Intelligence.pdf;;;https://scholar.google.com/scholar?start=80&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093455-197;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Contracting in the smart era: The implications of blockchain and decentralized autonomous organizations for contracting and corporate governance;A Murray, S Kuban, M Josefy… ; Academy of Management …, 2019  journals.aom.org;;"… blockchain to automatically carry out a range of actions such as executing financial transactions

or sending commands to smart devices … It is important to note that oracles, while more automated

and potentially devoid of … We discuss this oracle problem further in a later section …";Cité 24 fois;Les 4 versions;[PDF] researchgate.net;https://www.researchgate.net/profile/Matt_Josefy/publication/332472143_Contracting_in_the_Smart_Era_The_Implications_of_Blockchain_and_Decentralized_Autonomous_Organizations_for_Contracting_and_Corporate_Governance/links/5cb8e35c299bf120976f8eec/Contracting-in-the-Smart-Era-The-Implications-of-Blockchain-and-Decentralized-Autonomous-Organizations-for-Contracting-and-Corporate-Governance.pdf;;;https://scholar.google.com/scholar?start=30&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093497-371;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Blockchain?based security aspects in heterogeneous Internet?of?Things networks: A survey;FH Pohrmen, RK Das, G Saha ; Transactions on Emerging …, 2019  Wiley Online Library;;"… Table 1. Classification of consensus protocols and blockchain platforms Consensus

Protocol, Cryptocurrency, Platform, Private, Public, Permissioned. PoW4, Bitcoin, Litecoin,

PoW20 (Ethash), Ethereum, Ethereum21, PoS20, Peercoin,";Cité 23 fois;Les 2 versions;[PDF] wiley.com;https://onlinelibrary.wiley.com/doi/pdf/10.1002/ett.3741?casa_token=hkqmvCtx42QAAAAA:RtmKuEWZCvYAcYonnU8vFUaK4g2bwQRUrV_eMglR322e1DfV-b__RiEH4IqdUO40dDtVEs1ZUQsOnQ;;;https://scholar.google.com/scholar?start=210&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093471-269;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Monetary stabilization in cryptocurrencies–design approaches and open questions;IGA Pernice, S Henningsen… ; … on Blockchain …, 2019  ieeexplore.ieee.org;;"… This assumption is problematic, as existing research [4]–[6] does not solve the decentralized

oracle problem for arbitrary values and a general solution might be impossible due to the lack

of strong … 2019 Crypto Valley Conference on Blockchain Technology (CVCBT) …";Cité 25 fois;Les 11 versions;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/8782665/8787545/08787560.pdf?casa_token=54nJpR1Z4x0AAAAA:FgoHOXo8pI50Cgo97jQH_clncdrMIKMm9LTcLI9aX4BgF3vVCB6O_hvI4N8Yo3yJ6rX4kkN-ZII;;"""og:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""twitter:title"",""Monetary Stabilization in Cryptocurrencies – Design Approaches and Open Questions""
""twitter:card"",""summary""
""Description"",""The price volatility of cryptocurrencies is often cited as a major hindrance to their wide-scale adoption. Consequently, during the last two years, multiple so ""
""og:title"",""Monetary Stabilization in Cryptocurrencies – Design Approaches and Open Questions""
""resourceName"",""08787560.pdf""
""language"",""en""
""title"",""Monetary Stabilization in Cryptocurrencies – Design Approaches and Open Questions | IEEE Conference Publication | IEEE Xplore""
""og:description"",""The price volatility of cryptocurrencies is often cited as a major hindrance to their wide-scale adoption. Consequently, during the last two years, multiple so called stablecoins have surfaced-cryptocurrencies focused on maintaining stable exchange rates. In this paper, we systematically explore and analyze the stablecoin landscape. Based on a survey of 24 specific stablecoin projects, we go beyond individual coins for extracting general concepts and approaches. We combine our findings with learnings from classical monetary policy, resulting in a comprehensive taxonomy of cryptocurrency stabilization. We use our taxonomy to highlight the current state of development from different perspectives and show blank spots. For instance, while over 91% of projects promote 1-to-1 stabilization targets to external assets, monetary policy literature suggests that the smoothing of short term volatility is often a more sustainable alternative. Our taxonomy bridges computer science and economics, fostering the transfer of expertise. For example, we find that 38% of the reviewed projects use a combination of exchange rate targeting and specific stabilization techniques that can render them vulnerable to speculative economic attacks-an avoidable design flaw.""
""twitter:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-UA-Compatible"",""IE=Edge""
""viewport"",""width=device-width, initial-scale=1.0""
""dc:title"",""Monetary Stabilization in Cryptocurrencies – Design Approaches and Open Questions | IEEE Conference Publication | IEEE Xplore""
""twitter:description"",""The price volatility of cryptocurrencies is often cited as a major hindrance to their wide-scale adoption. Consequently, during the last two years, multiple so called stablecoins have surfaced-cryptocurrencies focused on maintaining stable exchange rates. In this paper, we systematically explore and analyze the stablecoin landscape. Based on a survey of 24 specific stablecoin projects, we go beyond individual coins for extracting general concepts and approaches. We combine our findings with learnings from classical monetary policy, resulting in a comprehensive taxonomy of cryptocurrency stabilization. We use our taxonomy to highlight the current state of development from different perspectives and show blank spots. For instance, while over 91% of projects promote 1-to-1 stabilization targets to external assets, monetary policy literature suggests that the smoothing of short term volatility is often a more sustainable alternative. Our taxonomy bridges computer science and economics, fostering the transfer of expertise. For example, we find that 38% of the reviewed projects use a combination of exchange rate targeting and specific stabilization techniques that can render them vulnerable to speculative economic attacks-an avoidable design flaw.""
""Content-Encoding"",""UTF-8""
""Content-Type-Hint"",""text/html; charset=utf-8""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=100&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093497-372;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Mbpa: A MediBchain-based privacy-preserving mutual authentication in TMIS for mobile medical cloud architecture;X Liu, W Ma, H Cao ; IEEE Access, 2019  ieeexplore.ieee.org;;"… Fortunately, blockchain technology leverages decentralized or distributed process to ensure

data security … MBPA scheme is proven safely against passive and active attacks under elliptic

curve computational Diffie-Hellman problem (ECDHP) assumption in random oracle model …";Cité 7 fois;;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/6287639/8600701/08868071.pdf;;"""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""dc:title"",""IEEE Xplore Full-Text PDF:""
""Content-Encoding"",""UTF-8""
""resourceName"",""08868071.pdf""
""language"",""es""
""Content-Length"",""2565""
""title"",""IEEE Xplore Full-Text PDF:""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=210&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093525-494;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;[PDF][PDF] A SECURED BLOCKCHAIN TECHNOLOGY BY USING BLOWFISH ALGORITHM FOR NEW BROADCAST PROXY PROVISIONAL RE-ENCRYPTION & ITS …;R Vasantha, RS Prasad ; researchgate.net;;"… 4. Now, Files has been stored in the Blockchain network … Wong, and C. Tang, “A CCA-secureidentity-

based conditional proxy re-encryption withoutrandom oracles,” in Proc … Fang, W. Susilo, and J.

Wang, “Anonymous conditional proxyre-encryption without random oracle,” in Proc …";Autres articles;Version HTML;[PDF] researchgate.net;https://www.researchgate.net/profile/Vasantha_Rudramalla/publication/333995825_A_SECURED_BLOCKCHAIN_TECHNOLOGY_BY_USING_BLOWFISH_ALGORITHM_FOR_NEW_BROADCAST_PROXY_PROVISIONAL_RE-ENCRYPTION_ITS_APPLICATION_TO_CLOUD_E-MAIL_ABSTRACT/links/5d11e734299bf1547c7c8e09/A-SECURED-BLOCKCHAIN-TECHNOLOGY-BY-USING-BLOWFISH-ALGORITHM-FOR-NEW-BROADCAST-PROXY-PROVISIONAL-RE-ENCRYPTION-ITS-APPLICATION-TO-CLOUD-E-MAIL-ABSTRACT.pdf;;;https://scholar.google.com/scholar?start=330&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093525-498;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Blockchain based Data Access Control using Smart Contracts;A Kiran, S Dharanikota, A Basava ; TENCON 20192019 IEEE …, 2019  ieeexplore.ieee.org;;"… In this scenario, oracles may have to be used in order to obtain the off-chain data into the

smart contract environment … 2337 Page 4. • Instead of the contract, the oracle service that

fetches the data can encrypt the data before it reaches the blockchain …";Cité 2 fois;Les 3 versions;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/8910516/8929228/08929451.pdf?casa_token=WnMzXvQcm7IAAAAA:QJYWL1klYIRdcmpQ3xuHp4KhS9g4X4pgERruAm3I_JpniclFjaKyasz95UYM1NWEZPFVbe3wIYM;;"""og:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""twitter:title"",""Blockchain based Data Access Control using Smart Contracts""
""twitter:card"",""summary""
""Description"",""The keystone of information security has been access control. Very often, User data is misused and users are oblivious to the use of their data by unauthorized ""
""og:title"",""Blockchain based Data Access Control using Smart Contracts""
""resourceName"",""08929451.pdf""
""language"",""en""
""title"",""Blockchain based Data Access Control using Smart Contracts | IEEE Conference Publication | IEEE Xplore""
""og:description"",""The keystone of information security has been access control. Very often, User data is misused and users are oblivious to the use of their data by unauthorized parties. Current strategies to provide storage for confidential data and subsequent authentication involve relying on a trusted third party for the same, which could be victims of Denial of Service (DoS) attacks or technical failures. This paper examines a strategy where the underlying framework for providing Access Control is the blockchain, hence decentralizing the mechanism of providing access control. Further in this paper, we demonstrate and model the User Data access on the Ethereum framework. Personal Information of the user by a website or an application is retrieved on a need-to-know basis from the off-blockchain, as determined by the user, the true owner of the data. Personal data is highly protected and the different permissions to different websites or applications are determined by the Smart Contract.""
""twitter:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-UA-Compatible"",""IE=Edge""
""viewport"",""width=device-width, initial-scale=1.0""
""dc:title"",""Blockchain based Data Access Control using Smart Contracts | IEEE Conference Publication | IEEE Xplore""
""twitter:description"",""The keystone of information security has been access control. Very often, User data is misused and users are oblivious to the use of their data by unauthorized parties. Current strategies to provide storage for confidential data and subsequent authentication involve relying on a trusted third party for the same, which could be victims of Denial of Service (DoS) attacks or technical failures. This paper examines a strategy where the underlying framework for providing Access Control is the blockchain, hence decentralizing the mechanism of providing access control. Further in this paper, we demonstrate and model the User Data access on the Ethereum framework. Personal Information of the user by a website or an application is retrieved on a need-to-know basis from the off-blockchain, as determined by the user, the true owner of the data. Personal data is highly protected and the different permissions to different websites or applications are determined by the Smart Contract.""
""Content-Encoding"",""UTF-8""
""Content-Type-Hint"",""text/html; charset=utf-8""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=330&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093457-203;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Blockchain technology overview;D Yaga, P Mell, N Roby, K Scarfone ; arXiv preprint arXiv:1906.11078, 2019  arxiv.org;;"… blockchain; consensus model; cryptocurrency; cryptographic hash … distributed ledger; distributed

consensus algorithm; proof of work; proof of stake; round robin; proof of authority; proof of identity;

proof of elapsed time; soft fork, hard fork; smart contracts; data oracle …";Cité 382 fois;Les 31 versions;[PDF] arxiv.org;https://arxiv.org/pdf/1906.11078;;"""date"",""2018-10-02T14:49:39Z""
""pdf:PDFVersion"",""1.6""
""xmp:CreatorTool"",""Acrobat PDFMaker 17 for Word""
""pdf:docinfo:title"",""Blockchain Technology Overview""
""Company"",""Information Technology Laboratory, NIST""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""Blockchains are tamper evident and tamper resistant digital ledgers implemented in a distributed fashion (i.e., without a central repository) and usually without a central authority (i.e., a bank, company, or government). At their basic level, they enable a community of users to record transactions in a shared ledger within that community, such that under normal operation of the blockchain network no transaction can be changed once published. This document provides a high-level technical overview of blockchain technology. The purpose is to help readers understand how blockchain technology works.""
""ContentTypeId"",""0x010100540B6CC63ADA754E9853F37802A1DD6E""
""language"",""en""
""dc:format"",""application/pdf; version=1.6""
""Manager"",""""
""pdf:docinfo:custom:ShortTitleLine1"",""Blockchain Technology Overview""
""pdf:docinfo:custom:ShortTitleLine2"","" ""
""pdf:docinfo:creator_tool"",""Acrobat PDFMaker 17 for Word""
""access_permission:fill_in_form"",""true""
""ShortTitleLine2"","" ""
""pdf:encrypted"",""false""
""dc:title"",""Blockchain Technology Overview""
""ShortTitleLine1"",""Blockchain Technology Overview""
""xmp:CreateDate"",""2018-10-01T11:07:14Z""
""modified"",""2018-10-02T14:49:39Z""
""pdf:docinfo:custom:SourceModified"",""D:20181001150534""
""cp:subject"",""Blockchains are tamper evident and tamper resistant digital ledgers implemented in a distributed fashion (i.e., without a central repository) and usually without a central authority (i.e., a bank, company, or government). At their basic level, they enable a community of users to record transactions in a shared ledger within that community, such that under normal operation of the blockchain network no transaction can be changed once published. This document provides a high-level technical overview of blockchain technology. The purpose is to help readers understand how blockchain technology works.""
""DOI Value"",""NIST.IR.8202""
""pdf:docinfo:subject"",""Blockchains are tamper evident and tamper resistant digital ledgers implemented in a distributed fashion (i.e., without a central repository) and usually without a central authority (i.e., a bank, company, or government). At their basic level, they enable a community of users to record transactions in a shared ledger within that community, such that under normal operation of the blockchain network no transaction can be changed once published. This document provides a high-level technical overview of blockchain technology. The purpose is to help readers understand how blockchain technology works.""
""pdf:hasMarkedContent"",""true""
""pdf:docinfo:custom:Manager"",""""
""xmp:ModifyDate"",""2018-10-02T10:49:39Z""
""pdf:docinfo:creator"",""Dylan Yaga""
""meta:author"",""Dylan Yaga"",""Peter Mell"",""Nik Roby"",""Karen Scarfone""
""meta:creation-date"",""2018-10-01T15:07:14Z""
""created"",""2018-10-01T15:07:14Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2018-10-01T15:07:14Z""
""resourceName"",""1906.11078""
""pdf:docinfo:custom:Category"",""""
""pdf:docinfo:custom:PageHeaderPubNum"",""8202""
""pdf:docinfo:custom:ContentTypeId"",""0x010100540B6CC63ADA754E9853F37802A1DD6E""
""pdf:docinfo:custom:Comments"",""""
""Author"",""Dylan Yaga"",""Peter Mell"",""Nik Roby"",""Karen Scarfone""
""producer"",""Adobe PDF Library 15.0""
""pdf:docinfo:producer"",""Adobe PDF Library 15.0""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""dc:description"",""Blockchains are tamper evident and tamper resistant digital ledgers implemented in a distributed fashion (i.e., without a central repository) and usually without a central authority (i.e., a bank, company, or government). At their basic level, they enable a community of users to record transactions in a shared ledger within that community, such that under normal operation of the blockchain network no transaction can be changed once published. This document provides a high-level technical overview of blockchain technology. The purpose is to help readers understand how blockchain technology works.""
""Keywords"",""""""blockchain; consensus model; cryptocurrency; cryptographic hash function; asymmetric-key cryptography; distributed ledger; distributed consensus algorithm; proof of work; proof of stake; round robin; proof of authority; proof of identity; proof of elapsed time; soft fork, hard fork; smart contracts; data oracle"""""",""""""blockchain; consensus model; cryptocurrency; cryptographic hash function; asymmetric-key cryptography; distributed ledger; distributed consensus algorithm; proof of work; proof of stake; round robin; proof of authority; proof of identity; proof of elapsed time; soft fork, hard fork; smart contracts; data oracle""""""
""Category"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""Dylan Yaga"",""Peter Mell"",""Nik Roby"",""Karen Scarfone""
""description"",""Blockchains are tamper evident and tamper resistant digital ledgers implemented in a distributed fashion (i.e., without a central repository) and usually without a central authority (i.e., a bank, company, or government). At their basic level, they enable a community of users to record transactions in a shared ledger within that community, such that under normal operation of the blockchain network no transaction can be changed once published. This document provides a high-level technical overview of blockchain technology. The purpose is to help readers understand how blockchain technology works.""
""dcterms:created"",""2018-10-01T15:07:14Z""
""Last-Modified"",""2018-10-02T14:49:39Z""
""dcterms:modified"",""2018-10-02T14:49:39Z""
""title"",""Blockchain Technology Overview""
""xmpMM:DocumentID"",""uuid:8cfafebd-d8cc-4de7-870f-b455c1e5905e""
""Last-Save-Date"",""2018-10-02T14:49:39Z""
""pdf:docinfo:custom:DOI Value"",""NIST.IR.8202""
""pdf:docinfo:keywords"",""""""blockchain; consensus model; cryptocurrency; cryptographic hash function; asymmetric-key cryptography; distributed ledger; distributed consensus algorithm; proof of work; proof of stake; round robin; proof of authority; proof of identity; proof of elapsed time; soft fork, hard fork; smart contracts; data oracle""""""
""pdf:docinfo:modified"",""2018-10-02T14:49:39Z""
""meta:save-date"",""2018-10-02T14:49:39Z""
""pdf:docinfo:custom:PublicationDate"",""October 2018""
""Content-Length"",""772424""
""Content-Type"",""application/pdf""
""PageHeaderPubNum"",""8202""
""xmp:MetadataDate"",""2018-10-02T10:49:39Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Dylan Yaga"",""Peter Mell"",""Nik Roby"",""Karen Scarfone""
""dc:language"",""EN-US""
""PublicationDate"",""October 2018""
""pdf:producer"",""Adobe PDF Library 15.0""
""dc:subject"",""""""blockchain; consensus model; cryptocurrency; cryptographic hash function; asymmetric-key cryptography; distributed ledger; distributed consensus algorithm; proof of work; proof of stake; round robin; proof of authority; proof of identity; proof of elapsed time; soft fork, hard fork; smart contracts; data oracle"""""",""""""blockchain; consensus model; cryptocurrency; cryptographic hash function; asymmetric-key cryptography; distributed ledger; distributed consensus algorithm; proof of work; proof of stake; round robin; proof of authority; proof of identity; proof of elapsed time; soft fork, hard fork; smart contracts; data oracle""""""
""Comments"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""68""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""189"",""530"",""1732"",""1798"",""1041"",""3777"",""3191"",""525"",""3718"",""2502"",""1189"",""2981"",""3590"",""2896"",""2200"",""3659"",""2258"",""3224"",""2919"",""3011"",""2055"",""3238"",""2161"",""3535"",""3033"",""3218"",""575"",""647"",""3266"",""3580"",""2723"",""3239"",""3649"",""3583"",""1036"",""1984"",""1540"",""2293"",""1600"",""2963"",""3615"",""1185"",""3671"",""815"",""3725"",""3736"",""3250"",""3622"",""3236"",""3470"",""810"",""2228"",""200"",""3792"",""3313"",""2748"",""2652"",""983"",""799"",""1984"",""2232"",""1943"",""2286"",""2004"",""2092"",""2516"",""2638"",""1403""
""access_permission:extract_content"",""true""
""pdf:docinfo:custom:Company"",""Information Technology Laboratory, NIST""
""access_permission:can_print"",""true""
""SourceModified"",""D:20181001150534""
""meta:keyword"",""""""blockchain; consensus model; cryptocurrency; cryptographic hash function; asymmetric-key cryptography; distributed ledger; distributed consensus algorithm; proof of work; proof of stake; round robin; proof of authority; proof of identity; proof of elapsed time; soft fork, hard fork; smart contracts; data oracle"""""",""""""blockchain; consensus model; cryptocurrency; cryptographic hash function; asymmetric-key cryptography; distributed ledger; distributed consensus algorithm; proof of work; proof of stake; round robin; proof of authority; proof of identity; proof of elapsed time; soft fork, hard fork; smart contracts; data oracle""""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2018-10-01T15:07:14Z""
";https://scholar.google.com/scholar?start=40&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093492-355;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;A blockchain-based searchable public-key encryption with forward and backward privacy for cloud-assisted vehicular social networks;B Chen, L Wu, H Wang, L Zhou… ; IEEE Transactions on …, 2019  ieeexplore.ieee.org;;"… AdvDBDH A (?) ? negl(?) C. Blockchain and Smart Contract Blockchain: Blockchain as a growing

distributed ledger is the core technology of cryptocurrency systems. Its security is guaranteed

by a cryptographic hash chain of blocks and consen- sus mechanism …";Cité 9 fois;Les 2 versions;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/25/4356907/08931643.pdf?casa_token=WhdAsd99zVAAAAAA:Aqz5kbA6qaNTsIYQxe5u3EOGNvgd_FnfYR26rUxYvrBHyqaJ2KtYN98tKddOeXD2XgRmSK95RSU;;"""og:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""twitter:title"",""A Blockchain-Based Searchable Public-Key Encryption With Forward and Backward Privacy for Cloud-Assisted Vehicular Social Networks""
""twitter:card"",""summary""
""Description"",""As the integration of the Internet of Vehicles and social networks, vehicular social networks (VSN) not only improves the efficiency and reliability of vehicula""
""og:title"",""A Blockchain-Based Searchable Public-Key Encryption With Forward and Backward Privacy for Cloud-Assisted Vehicular Social Networks""
""resourceName"",""08931643.pdf""
""language"",""en""
""title"",""A Blockchain-Based Searchable Public-Key Encryption With Forward and Backward Privacy for Cloud-Assisted Vehicular Social Networks | IEEE Journals & Magazine | IEEE Xplore""
""og:description"",""As the integration of the Internet of Vehicles and social networks, vehicular social networks (VSN) not only improves the efficiency and reliability of vehicular communication environment, but also provide more comprehensive social services for users. However, with the emergence of advanced communication and computing technologies, more and more data can be fast and conveniently collected from heterogeneous devices, and VSN has to meet new security challenges such as data security and privacy protection. Searchable encryption (SE) as a promising cryptographic primitive is devoted to data confidentiality without sacrificing data searchability. However, most existing schemes are vulnerable to the adaptive leakage-exploiting attacks or can not meet the efficiency requirements of practical applications, especially the searchable public-key encryption schemes (SPE). To achieve secure and efficient keyword search in VSN, we design a new blockchain-based searchable public-key encryption scheme with forward and backward privacy (BSPEFB). BSPEFB is a decentralized searchable public-key encryption scheme since the central search cloud server is replaced by the smart contract. Meanwhile, BSPEFB supports forward and backward privacy to achieve privacy protection. Finally, we implement a prototype of our basic construction and demonstrate the practicability of the proposed scheme in applications.""
""twitter:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-UA-Compatible"",""IE=Edge""
""viewport"",""width=device-width, initial-scale=1.0""
""dc:title"",""A Blockchain-Based Searchable Public-Key Encryption With Forward and Backward Privacy for Cloud-Assisted Vehicular Social Networks | IEEE Journals & Magazine | IEEE Xplore""
""twitter:description"",""As the integration of the Internet of Vehicles and social networks, vehicular social networks (VSN) not only improves the efficiency and reliability of vehicular communication environment, but also provide more comprehensive social services for users. However, with the emergence of advanced communication and computing technologies, more and more data can be fast and conveniently collected from heterogeneous devices, and VSN has to meet new security challenges such as data security and privacy protection. Searchable encryption (SE) as a promising cryptographic primitive is devoted to data confidentiality without sacrificing data searchability. However, most existing schemes are vulnerable to the adaptive leakage-exploiting attacks or can not meet the efficiency requirements of practical applications, especially the searchable public-key encryption schemes (SPE). To achieve secure and efficient keyword search in VSN, we design a new blockchain-based searchable public-key encryption scheme with forward and backward privacy (BSPEFB). BSPEFB is a decentralized searchable public-key encryption scheme since the central search cloud server is replaced by the smart contract. Meanwhile, BSPEFB supports forward and backward privacy to achieve privacy protection. Finally, we implement a prototype of our basic construction and demonstrate the practicability of the proposed scheme in applications.""
""Content-Encoding"",""UTF-8""
""Content-Type-Hint"",""text/html; charset=utf-8""
""Content-Length"",""46482""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=190&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093490-345;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;[HTML][HTML] Efficient and privacy-preserving traceable attribute-based encryption in blockchain;A Wu, Y Zhang, X Zheng, R Guo, Q Zhao… ; Annals of …, 2019  Springer;;"… Search SpringerLink Search. Efficient and privacy-preserving traceable attribute-based encryption

in blockchain. Download … Reading and writing of files on blockchain. Blockchain is a distributed

storage system, which can guarantee the integrity and non-repudiation of the data …";Cité 24 fois;;[HTML] springer.com;https://idp.springer.com/authorize/casa?redirect_uri=https://link.springer.com/article/10.1007/s12243-018-00699-y&casa_token=eVKL8I3Jo-IAAAAA:UUCiCz_cTY2FOvziDfhrlwTRlCquFtKdkBwmYZBcHy1fh_sH_PL-6WQPfQ2UxWWuBVtVLKmuVFY66EA;;"""dc.publisher"",""Springer""
""og:image"",""https://media.springernature.com/w200/springer-static/cover/journal/12243.jpg""
""twitter:card"",""summary""
""og:site_name"",""Annals of Telecommunications""
""citation_reference"",""Sahai A, Waters B (2005) Fuzzy identity-based encryption. In: International conference on theory and applications of cryptographic techniques, pp 457–473"",""citation_journal_title=Computing and Informatics; citation_title=Fine-grained access control systems suitable for resource-constrained users in cloud computing; citation_author=Y Zhang, D Zheng, R Guo, Q Zhao; citation_volume=37; citation_issue=2; citation_publication_date=2018; citation_pages=327-348; citation_doi=10.4149/cai_2018_2_327; citation_id=CR2"",""citation_journal_title=J Ambient Intell Humaniz Comput; citation_title=Efficient and privacy-aware attribute-based data sharing in mobile cloud computing; citation_author=Y Zhang, A Wu, D Zheng; citation_volume=9; citation_issue=4; citation_publication_date=2018; citation_pages=1039-1048; citation_doi=10.1007/s12652-017-0509-1; citation_id=CR3"",""citation_journal_title=IEEE Access; citation_title=Efficient and privacy-preserving medical data sharing in internet of things with limited computing power; citation_author=D Zheng, A Wu, Y Zhang, Q Zhao; citation_volume=6; citation_publication_date=2018; citation_pages=28019-28027; citation_doi=10.1109/ACCESS.2018.2840504; citation_id=CR4"",""citation_journal_title=Sensors(Basel, Switzerland); citation_title=Hidden policy attribute-based data sharing with direct revocation and keyword search in cloud computing; citation_author=A Wu, D Zheng, Y Zhang, M Yang; citation_volume=18; citation_issue=7; citation_publication_date=2018; citation_pages=1-17; citation_id=CR5"",""Gaetani E, Aniello L, Baldoni R, Lombardi F, Margheri A, Sassone V (2017) Blockchain-based database to ensure data integrity in cloud computing environments. In: Italian conference on cybersecurity"",""Hari A, Lakshman TV (2016) The internet blockchain: a distributed, tamper-resistant transaction framework for the internet. In: ACM workshop on hot topics in networks, pp 204–210"",""Ostrovsky R, Sahai A, Waters B (2007) Attribute-based encryption with non-monotonic access structures. In: CCS 07 ACM conference on computer & communications security, pp 195–203"",""citation_journal_title=J Netw Comput Appl; citation_title=Multi-authority fine-grained access control with accountability and its application in cloud; citation_author=J Li, X Chen, SSM Chow, Q Huang, DS Wong, Z Liu; citation_volume=112; citation_publication_date=2018; citation_pages=89-96; citation_doi=10.1016/j.jnca.2018.03.006; citation_id=CR9"",""citation_journal_title=IEEE Internet Things J; citation_title=Security and privacy in smart health: efficient policy-hiding attribute-based access control; citation_author=Y Zhang, D Zheng, RH Deng; citation_volume=5; citation_issue=3; citation_publication_date=2018; citation_pages=2130-2145; citation_doi=10.1109/JIOT.2018.2825289; citation_id=CR10"",""Goyal V, Pandey O, Sahai A, Waters B (2006) Attribute-based encryption for fine-grained access control of encrypted data. In: ACM conference on computer and communications security, pp 89–98"",""citation_journal_title=Usenix Conference on Security; citation_title=Outsourcing the decryption of ABE ciphertexts; citation_author=M Green, S Hohenberger, B Waters; citation_volume=2011; citation_issue=3; citation_publication_date=2011; citation_pages=1-16; citation_id=CR12"",""citation_journal_title=IEEE Trans Parallel Distrib Syst; citation_title=Securely outsourcing attribute-based encryption with checkability; citation_author=J Li, X Huang, J Li, X Chen, Y Xiang; citation_volume=25; citation_issue=8; citation_publication_date=2014; citation_pages=2201-2210; citation_doi=10.1109/TPDS.2013.271; citation_id=CR13"",""citation_journal_title=J Cryptol; citation_title=Online/offline digital signatures; citation_author=S Even, O Goldreich, S Micali; citation_volume=9; citation_issue=1; citation_publication_date=1996; citation_pages=35-67; citation_doi=10.1007/BF02254791; citation_id=CR14"",""Hohenberger S, Waters B (2014) Online/Offline attribute-based encryption. In: International workshop on public key cryptography, pp 293–310"",""citation_journal_title=J Netw Comput Appl; citation_title=Privacy-preserving communication and power injection over vehicle networks and 5G smart grid slice; citation_author=Y Zhang, J Li, D Zheng, P Li, Y Tian; citation_volume=122; citation_publication_date=2018; citation_pages=50-60; citation_doi=10.1016/j.jnca.2018.07.017; citation_id=CR16"",""Zhang Y, Shu J, Liu X, Li J, Zheng D (2018) Security analysis of a large-scale concurrent data anonymous batch verification scheme for mobile healthcare crowd sensing. IEEE Internet of Things Journal.                      https://doi.org/10.1109/JIOT.2018.2862381                                                                 "",""Wang X, Zhang Y, Zhu H, Jiang L (2018) An identity-based signcryption on lattice without trapdoor. Journal of Universal Computer Science"",""Li T, Chen W, Tang Y, Yan H (2018) A homomorphic network coding signature scheme for multiple sources and its application in IoT. Security and Communication Networks, 2018.                      https://doi.org/10.1155/2018/9641273                                                                 "",""citation_journal_title=Soft Comput; citation_title=Efficient and secure big data storage system with leakage resilience in cloud computing; citation_author=Y Zhang, M Yang, D Zheng, P Lang, A Wu, C Chen; citation_volume=22; citation_issue=23; citation_publication_date=2018; citation_pages=7763-7772; citation_doi=10.1007/s00500-018-3435-z; citation_id=CR20"",""citation_journal_title=IEEE Trans Comput; citation_title=Identity-based encryption with outsourced revocation in cloud computing; citation_author=J Li, J Li, X Chen, C Jia, W Lou; citation_volume=64; citation_issue=2; citation_publication_date=2015; citation_pages=425-437; citation_doi=10.1109/TC.2013.208; citation_id=CR21"",""citation_journal_title=IEEE Trans Parallel Distrib Syst; citation_title=Secure deduplication with efficient and reliable convergent key management; citation_author=J Li, X Chen, M Li, J Li, PPC Lee, W Lou; citation_volume=25; citation_issue=6; citation_publication_date=2014; citation_pages=1615-1625; citation_doi=10.1109/TPDS.2013.284; citation_id=CR22"",""Gao C, Lv S, Wei Y, Wang Z, Liu Z, Cheng X (2018) M-SSE: an effective searchable symmetric encryption with enhanced security for mobile devices, vol 6"",""citation_journal_title=IEEE Access; citation_title=TKSE: Trustworthy keyword search over encrypted data with two-side verifiability via blockchain; citation_author=Y Zhang, RH Deng, J Shu, K Yang, D Zheng; citation_volume=6; citation_publication_date=2018; citation_pages=31077-31087; citation_doi=10.1109/ACCESS.2018.2844400; citation_id=CR24"",""Nishide T, Yoneyama K, Ohta K (2008) Attribute-based encryption with partially hidden encryptor-specified access structures. In: International conference on applied cryptography and network security, pp 111–129"",""Lai J, Deng RH, Li Y (2011) Fully secure cipertext-policy hiding CP-ABE. In: International conference on information security practice and experience, pp 24–39"",""citation_journal_title=Inf Sci; citation_title=Ensuring attribute privacy protection and fast decryption for outsourced data security in mobile cloud computing; citation_author=Y Zhang, X Chen, J Li, DS Wong, H Li, I You; citation_volume=379; citation_publication_date=2017; citation_pages=42-61; citation_doi=10.1016/j.ins.2016.04.015; citation_id=CR27"",""citation_journal_title=Clust Comput; citation_title=New directly revocable attribute-based encryption scheme and its application in cloud storage environment; citation_author=H Wang, Z Zheng, L Wu, P Li; citation_volume=20; citation_issue=3; citation_publication_date=2017; citation_pages=2385-2392; citation_doi=10.1007/s10586-016-0701-7; citation_id=CR28"",""citation_journal_title=Pers Ubiquit Comput; citation_title=Towards privacy protection and malicious behavior traceability in smart health; citation_author=Y Zhang, J Li, D Zheng, X Chen, H Li; citation_volume=21; citation_issue=5; citation_publication_date=2017; citation_pages=815-830; citation_doi=10.1007/s00779-017-1047-8; citation_id=CR29"",""citation_journal_title=IACR Cryptology ePrint Archive; citation_title=A2BE: accountable attribute-based encryption for abuse free access control; citation_author=J Li, K Ren, K Kim; citation_volume=2009; citation_publication_date=2009; citation_pages=118; citation_id=CR30"",""citation_journal_title=IEEE Trans Inf Forensics Secur; citation_title=White-Box traceable ciphertext-policy attribute-based encryption supporting any monotone access structures; citation_author=Z Liu, Z Cao, DS Wong; citation_volume=8; citation_issue=1; citation_publication_date=2013; citation_pages=76-88; citation_doi=10.1109/TIFS.2012.2223683; citation_id=CR31"",""Li J, Huang Q, Chen X, Chow SSM, Wong DS, Xie D (2011) Multi-authority ciphertext-policy attribute-based encryption with accountability. In: ACM symposium on information, computer and communications security, ASIACCS 2011, Hong Kong, China, March, pp 386–390"",""Yu G, Cao Z, Zeng G, Han W (2016) Accountable ciphertext-policy attribute-based encryption scheme supporting public verifiability and nonrepudiation. In: International conference on provable security, pp 3–18"",""Chen X, Li J, Weng J, Ma J, Lou W (2014) Verifiable computation over large database with incremental updates. In: European symposium on research in computer security, pp 148–162"",""citation_journal_title=IEEE Trans Dependable Secure Comput; citation_title=New publicly verifiable databases with efficient updates; citation_author=X Chen, J Li, X Huang, J Ma, W Lou; citation_volume=12; citation_issue=5; citation_publication_date=2015; citation_pages=546-556; citation_doi=10.1109/TDSC.2014.2366471; citation_id=CR35"",""citation_journal_title=IEEE Access; citation_title=When intrusion detection meets blockchain technology: a review; citation_author=W Meng, EW Tischhauser, Q Wang, Y Wang, J Han; citation_volume=6; citation_issue=99; citation_publication_date=2018; citation_pages=10179-10188; citation_doi=10.1109/ACCESS.2018.2799854; citation_id=CR36"",""Zhang Y, Deng Rh, Liu X, Zheng D (2018) Outsourcing service fair payment based on blockchain and its applications in cloud computing. IEEE Transactions on Services Computing.                      https://doi.org/10.1109/TSC.2018.2864191                                                                 "",""citation_journal_title=Inf Sci; citation_title=Blockchain based efficient and robust fair payment for outsourcing services in cloud computing; citation_author=Y Zhang, Rh Deng, X Liu, D Zheng; citation_volume=462; citation_publication_date=2018; citation_pages=262-277; citation_doi=10.1016/j.ins.2018.06.018; citation_id=CR38"",""citation_journal_title=Commun ACM; citation_title=Space/time trade-offs in hash coding with allowable errors; citation_author=BH Bloom; citation_volume=13; citation_issue=7; citation_publication_date=1970; citation_pages=422-426; citation_doi=10.1145/362686.362692; citation_id=CR39"",""citation_journal_title=IEEE Internet Things J; citation_title=An efficient and fine-grained big data access control scheme with privacy-preserving policy; citation_author=K Yang, Q Han, H Li, K Zheng, Z Su, X Shen; citation_volume=4; citation_issue=2; citation_publication_date=2017; citation_pages=563-571; citation_doi=10.1109/JIOT.2016.2571718; citation_id=CR40"",""Dong C, Chen L, Wen Z (2013) When private set intersection meets big data: an efficient and scalable protocol. In: ACM SIGSAC conference on computer & communications security, pp 789–800"",""citation_journal_title=IACR Cryptology ePrint Archive; citation_title=Short signatures from diffie-hellman, revisited: sublinear public key, CMA security, and tighter reduction; citation_author=JH Seo; citation_volume=138; citation_publication_date=2014; citation_pages=2014; citation_id=CR42"",""Yuan C, Xu M, Si X, Li B (2017) Blockchain with accountable CP-ABE: how to effectively protect the electronic documents. In: 2017 IEEE 23rd international conference on parallel and distributed systems (ICPADS), pp 800–803.                      https://doi.org/10.1109/ICPADS.2017.00111                                                                 ""
""citation_journal_title"",""Annals of Telecommunications""
""language"",""en""
""citation_cover_date"",""2019/08/01""
""og:description"",""Attribute-based encryption, especially ciphertext-policy attribute-based encryption, plays an important role in the data sharing. In the process of data sharing, the secret key does not contain the specific information of users, who may share his secret key with other users for benefits without being discovered. In addition, the attribute authority can generate the secret key from any attribute set. If the secret key is abused, it is difficult to judge whether the abused private key comes from users or the attribute authority. Besides, the access control structure usually leaks sensitive information in a distributed network, and the efficiency of attribute-based encryption is a bottleneck of its applications. Fortunately, blockchain technology can guarantee the integrity and non-repudiation of data. In view of the above issues, an efficient and privacy-preserving traceable attribute-based encryption scheme is proposed. In the proposed scheme, blockchain technologies are used to guarantee both integrity and non-repudiation of data, and the ciphertext can be quickly generated by using the pre-encryption technology. Moreover, attributes are hidden in anonymous access control structures by using the attribute bloom filter. When a secret key is abused, the source of the abused secret key can be audited. Security and performance analysis show that the proposed scheme is secure and efficient.""
""prism.issn"",""1958-9395""
""citation_author_email"",""waxinsec@163.com"",""yhzhaang@163.com"",""xiaokzheng@163.com"",""guorui@xupt.edu.cn"",""zhaoqinglan@foxmail.com"",""zhengdong_xupt@sina.com""
""twitter:image:alt"",""Content cover image""
""prism.number"",""7""
""citation_issn"",""1958-9395""
""citation_language"",""en""
""dc:title"",""Efficient and privacy-preserving traceable attribute-based encryption in blockchain | SpringerLink""
""Content-Encoding"",""UTF-8""
""citation_pdf_url"",""https://link.springer.com/content/pdf/10.1007/s12243-018-00699-y.pdf""
""citation_lastpage"",""411""
""DOI"",""10.1007/s12243-018-00699-y""
""citation_journal_abbrev"",""Ann. Telecommun.""
""prism.rightsAgent"",""journalpermissions@springernature.com""
""citation_author"",""Axin Wu"",""Yinghui Zhang"",""Xiaokun Zheng"",""Rui Guo"",""Qinglan Zhao"",""Dong Zheng""
""resourceName"",""casa""
""dc.date"",""2019-01-03""
""citation_springer_api_url"",""http://api.springer.com/metadata/pam?q=doi:10.1007/s12243-018-00699-y&api_key=""
""citation_issue"",""7""
""prism.volume"",""74""
""prism.publicationName"",""Annals of Telecommunications""
""citation_doi"",""10.1007/s12243-018-00699-y""
""dc.title"",""Efficient and privacy-preserving traceable attribute-based encryption in blockchain""
""prism.url"",""https://link.springer.com/article/10.1007/s12243-018-00699-y""
""citation_volume"",""74""
""dc.language"",""En""
""Content-Language"",""en""
""format-detection"",""telephone=no""
""citation_publication_date"",""2019/08""
""prism.endingPage"",""411""
""citation_title"",""Efficient and privacy-preserving traceable attribute-based encryption in blockchain""
""citation_author_institution"",""National Engineering Laboratory for Wireless Security, Xi’an University of Posts and Telecommunications, Xi’an, People’s Republic of China"",""Westone Cryptologic Research Center, Beijing, China"",""National Engineering Laboratory for Wireless Security, Xi’an University of Posts and Telecommunications, Xi’an, People’s Republic of China"",""Westone Cryptologic Research Center, Beijing, China"",""National Engineering Laboratory for Wireless Security, Xi’an University of Posts and Telecommunications, Xi’an, People’s Republic of China"",""Westone Cryptologic Research Center, Beijing, China"",""National Engineering Laboratory for Wireless Security, Xi’an University of Posts and Telecommunications, Xi’an, People’s Republic of China"",""Westone Cryptologic Research Center, Beijing, China"",""National Engineering Laboratory for Wireless Security, Xi’an University of Posts and Telecommunications, Xi’an, People’s Republic of China"",""Westone Cryptologic Research Center, Beijing, China"",""National Engineering Laboratory for Wireless Security, Xi’an University of Posts and Telecommunications, Xi’an, People’s Republic of China"",""Westone Cryptologic Research Center, Beijing, China""
""access"",""No""
""citation_publisher"",""Springer International Publishing""
""applicable-device"",""pc,mobile""
""dc.format"",""text/html""
""description"",""Attribute-based encryption, especially ciphertext-policy attribute-based encryption, plays an important role in the data sharing. In the process of data sh""
""title"",""Efficient and privacy-preserving traceable attribute-based encryption in blockchain | SpringerLink""
""citation_online_date"",""2019/01/03""
""twitter:site"",""@SpringerLink""
""dc.source"",""Annals of Telecommunications 2019 74:7""
""dc.type"",""BriefCommunication""
""dc.copyright"",""2019 Institut Mines-TĂŠlĂŠcom and Springer Nature Switzerland AG""
""dc.creator"",""Axin Wu"",""Yinghui Zhang"",""Xiaokun Zheng"",""Rui Guo"",""Qinglan Zhao"",""Dong Zheng""
""citation_fulltext_html_url"",""https://link.springer.com/article/10.1007/s12243-018-00699-y""
""prism.publicationDate"",""2019-01-03""
""Content-Type"",""text/html; charset=UTF-8""
""journal_id"",""12243""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""dc.description"",""Attribute-based encryption, especially ciphertext-policy attribute-based encryption, plays an important role in the data sharing. In the process of data sharing, the secret key does not contain the specific information of users, who may share his secret key with other users for benefits without being discovered. In addition, the attribute authority can generate the secret key from any attribute set. If the secret key is abused, it is difficult to judge whether the abused private key comes from users or the attribute authority. Besides, the access control structure usually leaks sensitive information in a distributed network, and the efficiency of attribute-based encryption is a bottleneck of its applications. Fortunately, blockchain technology can guarantee the integrity and non-repudiation of data. In view of the above issues, an efficient and privacy-preserving traceable attribute-based encryption scheme is proposed. In the proposed scheme, blockchain technologies are used to guarantee both integrity and non-repudiation of data, and the ciphertext can be quickly generated by using the pre-encryption technology. Moreover, attributes are hidden in anonymous access control structures by using the attribute bloom filter. When a secret key is abused, the source of the abused secret key can be audited. Security and performance analysis show that the proposed scheme is secure and efficient.""
""og:type"",""article""
""citation_article_type"",""Article""
""og:title"",""Efficient and privacy-preserving traceable attribute-based encryption in blockchain""
""prism.doi"",""doi:10.1007/s12243-018-00699-y""
""X-UA-Compatible"",""IE=edge""
""citation_firstpage"",""401""
""prism.startingPage"",""401""
""viewport"",""width=device-width, initial-scale=1""
""dc.rightsAgent"",""journalpermissions@springernature.com""
""prism.section"",""BriefCommunication""
""dc.identifier"",""doi:10.1007/s12243-018-00699-y""
""dc.subject"",""Communications Engineering, Networks"",""Information Systems and Communication Service"",""Signal,Image and Speech Processing"",""Computer Communication Networks"",""Information and Communication, Circuits"",""R & D/Technology Policy""
""og:url"",""https://link.springer.com/article/10.1007/s12243-018-00699-y""
""prism.copyright"",""2019 Institut Mines-TĂŠlĂŠcom and Springer Nature Switzerland AG""
";https://scholar.google.com/scholar?start=180&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093530-513;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;An investigation on the adoption of blockchain technology in supply chain;C RATTI ;2019 politesi.polimi.it;;"… Scuola di Ingegneria Industriale e dell'Informazione Master of Science in Management

Engineering An investigation on the adoption of Blockchain Technology in Supply Chain

Supervisor: Prof … 52 1.1.7 What is the matter with Blockchain? 56 2. Blockchain Technology 59 …";Autres articles;Version HTML;[PDF] polimi.it;https://www.politesi.polimi.it/bitstream/10589/151067/3/2019_Ratti.pdf;;"""date"",""2019-12-02T19:04:08Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.7""
""xmp:CreatorTool"",""MicrosoftÂŽ Word per Office 365""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dc:creator"",""Claudio Ratti""
""language"",""en""
""dcterms:created"",""2019-12-02T19:04:08Z""
""Last-Modified"",""2019-12-02T19:04:08Z""
""dcterms:modified"",""2019-12-02T19:04:08Z""
""dc:format"",""application/pdf; version=1.7""
""xmpMM:DocumentID"",""uuid:A43DDA79-050D-4689-9F24-A04CA0591BCC""
""Last-Save-Date"",""2019-12-02T19:04:08Z""
""pdf:docinfo:creator_tool"",""MicrosoftÂŽ Word per Office 365""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2019-12-02T19:04:08Z""
""meta:save-date"",""2019-12-02T19:04:08Z""
""pdf:encrypted"",""false""
""xmp:CreateDate"",""2019-12-02T20:04:08Z""
""modified"",""2019-12-02T19:04:08Z""
""pdf:hasMarkedContent"",""true""
""Content-Type"",""application/pdf""
""xmp:ModifyDate"",""2019-12-02T20:04:08Z""
""pdf:docinfo:creator"",""Claudio Ratti""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Claudio Ratti""
""dc:language"",""it-IT""
""meta:author"",""Claudio Ratti""
""pdf:producer"",""MicrosoftÂŽ Word per Office 365""
""meta:creation-date"",""2019-12-02T19:04:08Z""
""created"",""2019-12-02T19:04:08Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""265""
""Creation-Date"",""2019-12-02T19:04:08Z""
""resourceName"",""2019_Ratti.pdf""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""344"",""19"",""499"",""1012"",""1355"",""305"",""2097"",""1057"",""866"",""885"",""300"",""2157"",""181"",""2202"",""375"",""1832"",""2146"",""2254"",""1311"",""2122"",""1368"",""1752"",""1320"",""1020"",""2070"",""741"",""2468"",""1201"",""1280"",""2284"",""2128"",""1788"",""1651"",""1860"",""1911"",""1138"",""2285"",""274"",""1993"",""2279"",""2206"",""2175"",""1407"",""2307"",""2090"",""2099"",""2221"",""2412"",""2299"",""1175"",""669"",""2353"",""2189"",""1241"",""936"",""2184"",""2022"",""2442"",""2218"",""2343"",""2118"",""1627"",""2119"",""1486"",""1839"",""1243"",""2264"",""1888"",""2425"",""1778"",""2334"",""1493"",""2020"",""1923"",""2011"",""2285"",""2073"",""1896"",""1725"",""551"",""2183"",""2139"",""2301"",""1622"",""2129"",""2336"",""2326"",""2205"",""2408"",""2235"",""2244"",""2208"",""1788"",""574"",""2287"",""1980"",""2027"",""2289"",""2314"",""2094"",""2309"",""1983"",""1278"",""2105"",""1842"",""2354"",""2118"",""2182"",""2087"",""2538"",""2258"",""2241"",""2150"",""2185"",""2304"",""2352"",""2444"",""1337"",""2141"",""2254"",""2089"",""2079"",""1869"",""1938"",""803"",""823"",""989"",""1784"",""1893"",""1501"",""1424"",""1716"",""1734"",""1901"",""1740"",""1921"",""1696"",""2412"",""1682"",""519"",""447"",""1754"",""2227"",""2103"",""2330"",""2304"",""1860"",""1195"",""2160"",""481"",""1977"",""2106"",""245"",""1554"",""1150"",""1547"",""1519"",""2286"",""2077"",""2404"",""2178"",""2369"",""2391"",""1226"",""974"",""57"",""1693"",""2406"",""945"",""88"",""2361"",""2482"",""2396"",""2436"",""2558"",""2342"",""2450"",""2584"",""2306"",""2084"",""2171"",""2083"",""2259"",""2359"",""2346"",""2393"",""2425"",""2346"",""2182"",""2547"",""2382"",""1968"",""2428"",""2745"",""2805"",""3080"",""2823"",""1467"",""2172"",""1964"",""2013"",""1296"",""2404"",""2225"",""2157"",""1951"",""2227"",""2410"",""645"",""1909"",""1849"",""1140"",""2071"",""2223"",""2323"",""1637"",""1410"",""2192"",""3135"",""2583"",""5238"",""3759"",""3409"",""2904"",""3664"",""3675"",""3691"",""1318"",""1979"",""1534"",""2134"",""1362"",""2104"",""1403"",""2178"",""1338"",""2016"",""1525"",""2069"",""1546"",""1882"",""1583"",""1804"",""1418"",""1161"",""1490"",""1413"",""1619"",""1248"",""1577"",""1924"",""1885"",""1482"",""2300"",""207"",""8"",""2130"",""2339"",""2350"",""2247"",""2144"",""2235"",""2321"",""2300"",""2024""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""Author"",""Claudio Ratti""
""producer"",""MicrosoftÂŽ Word per Office 365""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""MicrosoftÂŽ Word per Office 365""
""pdf:docinfo:created"",""2019-12-02T19:04:08Z""
";https://scholar.google.com/scholar?start=350&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093546-586;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Blockchain kompakt;HG Fill, A Meier ; Springer;;"Page 1. Blockchain kompakt Hans-Georg Fill Andreas Meier Grundlagen, Anwendungsoptionen …

Weitere Bände in der Reihe http://www.springer.com/series/8297 Page 4. Hans-Georg Fill ˇ

Andreas Meier Blockchain kompakt Grundlagen, Anwendungsoptionen und …";Cité 1 fois;;null;;;;https://scholar.google.com/scholar?start=420&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093455-196;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Blockchain?based trusted data sharing among trusted stakeholders in IoT;P Shi, H Wang, S Yang, C Chen… ; Software: Practice and …, 2019  Wiley Online Library;;"… In this architecture, data injection is supervised by an oracle.8 A blockchain is a closed

environment in the … To address this limitation, the oracle is used to validate the data when the

data from the physical world … There are three kinds of oracles: software, hardware, and consensus …";Cité 11 fois;;[PDF] wiley.com;https://onlinelibrary.wiley.com/doi/pdf/10.1002/spe.2739;;;https://scholar.google.com/scholar?start=30&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093476-286;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Anonymous multi-hop locks for blockchain scalability and interoperability;G Malavolta, P Moreno;Sanchez…  26th Annual Network …, 2019  par.nsf.gov;;"… This approach reduces the space required for cryptographic operations in the script, saving thus

invaluable bytes on the blockchain. Moreover, it improves upon the fungibility of the cryptocurrency

as transactions from payment channels no longer require a script different from …";Cité 83 fois;Les 6 versions;[PDF] nsf.gov;https://par.nsf.gov/servlets/purl/10168773;;"""date"",""2020-07-06T21:36:27Z""
""pdf:PDFVersion"",""1.4""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:docinfo:title"",""""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""pdfa:PDFVersion"",""A-1a""
""language"",""en""
""dc:format"",""application/pdf; version=""""A-1a"""""",""application/pdf; version=1.4""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""xmp:CreateDate"",""2018-12-14T18:24:06Z""
""modified"",""2020-07-06T21:36:27Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""xmp:ModifyDate"",""2020-07-06T17:36:27Z""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.19 (TeX Live 2018) kpathsea version 6.3.0""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2018-12-14T17:24:06Z""
""created"",""2018-12-14T17:24:06Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2018-12-14T17:24:06Z""
""resourceName"",""10168773""
""pdfaid:part"",""1""
""Author"",""""
""producer"",""pdfTeX-1.40.19""
""pdf:docinfo:producer"",""pdfTeX-1.40.19""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""5"",""2"",""17"",""0"",""6"",""11"",""11"",""44"",""7"",""3"",""0"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2018-12-14T17:24:06Z""
""Last-Modified"",""2020-07-06T21:36:27Z""
""dcterms:modified"",""2020-07-06T21:36:27Z""
""title"",""""
""Last-Save-Date"",""2020-07-06T21:36:27Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2020-07-06T21:36:27Z""
""meta:save-date"",""2020-07-06T21:36:27Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.19 (TeX Live 2018) kpathsea version 6.3.0""
""Content-Length"",""688878""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""pdfaid:conformance"",""A""
""pdf:producer"",""pdfTeX-1.40.19""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""15""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""4131"",""4596"",""4475"",""4616"",""4238"",""3820"",""3285"",""4460"",""3768"",""2765"",""4084"",""4316"",""4562"",""4574"",""5506""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2018-12-14T17:24:06Z""
";https://scholar.google.com/scholar?start=120&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093502-397;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;SoK: communication across distributed ledgers.;A Zamyatin, M Al;Bassam, D Zindros, E KokorisKogias… 2019 spiral.imperial.ac.uk;;"… a state transition on X. As such, we do not consider (oracle) protocols which … X). Collateralization

of Consensus Custodians is best handled on another blockchain, ie, where … partic- ipants and

leveraging locking mechanisms which harvest security from crypto- graphic hardness …";Cité 37 fois;Les 3 versions;[PDF] imperial.ac.uk;https://spiral.imperial.ac.uk/bitstream/10044/1/75810/6/2019-1128.pdf;;"""date"",""2020-10-09T14:06:09Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""2"",""14"",""4"",""4"",""1"",""1"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""88"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""2"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.5""
""xmp:CreatorTool"",""TeX""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dcterms:created"",""2020-10-09T14:06:09Z""
""language"",""en""
""Last-Modified"",""2020-10-09T14:06:09Z""
""dcterms:modified"",""2020-10-09T14:06:09Z""
""dc:format"",""application/pdf; version=1.5""
""Last-Save-Date"",""2020-10-09T14:06:09Z""
""pdf:docinfo:creator_tool"",""TeX""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2020-10-09T14:06:09Z""
""meta:save-date"",""2020-10-09T14:06:09Z""
""pdf:encrypted"",""false""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.20 (TeX Live 2019) kpathsea version 6.3.1""
""modified"",""2020-10-09T14:06:09Z""
""Content-Length"",""486650""
""pdf:hasMarkedContent"",""false""
""Content-Type"",""application/pdf""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.20 (TeX Live 2019) kpathsea version 6.3.1""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""trapped"",""False""
""meta:creation-date"",""2020-10-09T14:06:09Z""
""created"",""2020-10-09T14:06:09Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""35""
""Creation-Date"",""2020-10-09T14:06:09Z""
""resourceName"",""2019-1128.pdf""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""1950"",""2544"",""2753"",""2587"",""2355"",""2599"",""1687"",""2603"",""2556"",""2546"",""2797"",""2897"",""2702"",""2627"",""2498"",""1997"",""2887"",""2645"",""3003"",""2919"",""2490"",""2791"",""2917"",""2811"",""2835"",""2982"",""2843"",""2822"",""2460"",""1702"",""932"",""2180"",""2863"",""2677"",""1250""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""producer"",""pdfTeX-1.40.20""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""pdfTeX-1.40.20""
""pdf:docinfo:created"",""2020-10-09T14:06:09Z""
";https://scholar.google.com/scholar?start=230&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093494-367;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Patient privacy and ownership of electronic health records on a blockchain;DR Chawdhuri ; International Conference on Blockchain, 2019  Springer;;"… valid encryption without being able to compute the plaintext is negligible, and hence decryption

oracles do not … _{i=1}^n d_i\) is also fixed and cannot match the output of the random oracle … adds

the encrypted content and adds the record to the chain with a blockchain transaction …";Cité 2 fois;Les 4 versions;[PDF] academia.edu;https://www.academia.edu/download/61078226/paper20191031-64276-3t02ws.pdf;;;https://scholar.google.com/scholar?start=200&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093448-166;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;[PDF][PDF] Blockchain Oracles;K Mammadzada ;2019 core.ac.uk;;"Blockchain technology has emerged as a potential disruptor of multiple industries and 
became an enabler for separate entities to trans-act in a secure and decentralized manner. 
Nevertheless, the blockchain technology in itself does not directly interact with the external …";Cité 1 fois;;[PDF] core.ac.uk;https://core.ac.uk/download/pdf/237085000.pdf;;"""date"",""2019-08-15T09:31:45Z""
""pdf:PDFVersion"",""1.7""
""xmp:CreatorTool"",""MicrosoftÂŽ Word for Office 365""
""pdf:docinfo:title"",""Blockchain Oracles""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""Master’s Thesis (20 ECTS)""
""language"",""en""
""dc:format"",""application/pdf; version=1.7""
""pdf:docinfo:creator_tool"",""MicrosoftÂŽ Word for Office 365""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""Blockchain Oracles""
""xmp:CreateDate"",""2019-08-15T11:31:45Z""
""modified"",""2019-08-15T09:31:45Z""
""cp:subject"",""Master’s Thesis (20 ECTS)""
""pdf:docinfo:subject"",""Master’s Thesis (20 ECTS)""
""pdf:hasMarkedContent"",""true""
""xmp:ModifyDate"",""2019-08-15T11:31:45Z""
""pdf:docinfo:creator"",""Kamran Mammadzada""
""meta:author"",""Kamran Mammadzada""
""meta:creation-date"",""2019-08-15T09:31:45Z""
""created"",""2019-08-15T09:31:45Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-08-15T09:31:45Z""
""resourceName"",""237085000.pdf""
""Author"",""Kamran Mammadzada""
""producer"",""MicrosoftÂŽ Word for Office 365""
""pdf:docinfo:producer"",""MicrosoftÂŽ Word for Office 365""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""dc:description"",""Master’s Thesis (20 ECTS)""
""Keywords"",""Blockchain, blockchain oracle"",""Blockchain, blockchain oracle""
""access_permission:modify_annotations"",""true""
""dc:creator"",""Kamran Mammadzada""
""description"",""Master’s Thesis (20 ECTS)""
""dcterms:created"",""2019-08-15T09:31:45Z""
""Last-Modified"",""2019-08-15T09:31:45Z""
""dcterms:modified"",""2019-08-15T09:31:45Z""
""title"",""Blockchain Oracles""
""xmpMM:DocumentID"",""uuid:9F933B08-0B1C-47B2-AE5F-900716EF4777""
""Last-Save-Date"",""2019-08-15T09:31:45Z""
""pdf:docinfo:keywords"",""Blockchain, blockchain oracle""
""pdf:docinfo:modified"",""2019-08-15T09:31:45Z""
""meta:save-date"",""2019-08-15T09:31:45Z""
""Content-Length"",""1059991""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Kamran Mammadzada""
""dc:language"",""en-US""
""pdf:producer"",""MicrosoftÂŽ Word for Office 365""
""dc:subject"",""Blockchain, blockchain oracle"",""Blockchain, blockchain oracle""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""45""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""238"",""4338"",""3799"",""4196"",""3043"",""4215"",""4418"",""1978"",""3352"",""2778"",""2130"",""2449"",""2409"",""1772"",""648"",""3780"",""3075"",""3426"",""3400"",""3032"",""2877"",""2688"",""2867"",""2432"",""3607"",""3022"",""3008"",""2398"",""2372"",""2453"",""2228"",""2999"",""1570"",""4389"",""1527"",""1636"",""1666"",""1156"",""4845"",""2322"",""3005"",""3291"",""3322"",""1147"",""1716""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""meta:keyword"",""Blockchain, blockchain oracle"",""Blockchain, blockchain oracle""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-08-15T09:31:45Z""
";
1619093499-385;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Cryptoliquidity: the blockchain and monetary stability;JL Caton ; Journal of Entrepreneurship and Public Policy, 2019  emerald.com;;"… It even enables the creation of cryptocurrency other than ether … for a third party to intermediate

the transfer of funds or ownership claims entailed in the contract, although exchange of goods

not native to the blockchain may require offchain mechanisms known as Oracles …";Cité 10 fois;Les 8 versions;[PDF] emerald.com;https://www.emerald.com/insight/content/doi/10.1108/JEPP-03-2019-0011/full/pdf?casa_token=rN_8fmSJJa8AAAAA:J7x1Lkl_LuBEN5kiDxDl884k6l5ZF_q-7Ybyc-BLc-9yP1nCQdRlLNEidM3xDmvqWRumfm9N039GGb6fiJonz0Ioe_E4DbNhu9G6Rd-pHVAhgRG-Xw;;"""keywords"",""Liquidity,Blockchain,Disequilibrium,Cryptocurrency,Endogenous money,E02,E41,E44,E51""
""dc.Title"",""Cryptoliquidity: the blockchain and monetary stability""
""citation_journal_title"",""Journal of Entrepreneurship and Public Policy""
""description"",""Cryptoliquidity: the blockchain and monetary stability - Author: James Lee Caton""
""language"",""en""
""title"",""Cryptoliquidity: the blockchain and monetary stability
 |  Emerald Insight""
""dc.Identifier"",""10.1108/JEPP-03-2019-0011"",""2045-2101""
""dc.Publisher"",""Emerald Publishing Limited""
""dc.Format"",""text/html""
""dc:title"",""Cryptoliquidity: the blockchain and monetary stability
 |  Emerald Insight""
""csrf-token"",""k1NLxeVjqt8Kt1DDiIn4TCUNitJcF5qpC4ZEQByr""
""Content-Encoding"",""UTF-8""
""dc.Date"",""2019-10-24T00:00:00Z""
""citation_xml_url"",""https://www.emerald.com/insight/content/doi/10.1108/JEPP-03-2019-0011/full/xml""
""dc.Subject"",""Liquidity,Blockchain,Disequilibrium,Cryptocurrency,Endogenous money,E02,E41,E44,E51""
""Content-Type"",""text/html; charset=UTF-8""
""dc.Contributor"",""James Lee Caton""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""dc.Type"",""article""
""resourceName"",""pdf""
""X-UA-Compatible"",""IE=edge""
""dc.Language"",""en""
""dc.Description"",""The development of blockchain and cryptocurrency may alleviate the economic strain associated with recession. Economic recessions tend to be aggregate-demand driven, meaning that they are caused by fluctuations in the supply of or demand for money. Holding monetary policy as solution assumes that stability must arise from outside of the economic system. Under a policy regime that allows innovations in blockchain to develop, blockchain technology may promote a money supply that is responsive to changes in demand to hold money. The purpose of this paper is to suggest that cryptocurrencies present an opportunity to profitably implement rules that promote macroeconomic stability. In particular, cryptocurrency that is asset-backed may provide a means for cheaply attaining liquidity during a crisis.,The role of cryptocurrency in promoting macroeconomic equilibrium is approached through the lens of monetary theory. Moves away from macroeconomic equilibrium necessitate either a change in the average price of money or a change in the quantity of money, or a change in portfolio demand for money. Cryptocurrency promotes an increase, however this requires the alignment of policy regulating the use of cryptocurrency, reduction in taxes placed on the use of cryptocurrency and cryptocurrency protocol.,Cryptocurrency is unlikely to become legal tender, but it may alleviate macroeconomic fluctuations as a near money that provides liquidity and whose supply is sensitive to changes in demand to hold money and money-like substitutes. This role might be inhibited if policy stifles the development of cryptocurrencies and blockchain technology.,New financial innovations like cryptocurrencies can be analyzed applying the equation of exchange in light of the mechanics of money creation under conditions of disequilibrium. Monetary disequilibrium may be promoted by policy that causes bottlenecks in financial markets.,Theory of monetary disequilibrium has broad implications for the development and regulation of financial markets. This theory has not been applied to the development of cryptocurrency markets.""
""viewport"",""width=device-width, initial-scale=1""
""DCTERMS.bibliographicCitation"",""&ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Ajournal&rft.spage=227&rft.epage=252&rft.volume=9&rft.issue=2""
""dc.Coverage"",""world""
""Content-Language"",""en""
""format-detection"",""telephone=no""
";https://scholar.google.com/scholar?start=220&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093509-425;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;[CITATION][C] Decentralized Oracles in the Presence of Lying Incentives;N Goel, A Filos;Ratsikas, B Faltings;;null;Autres articles;;null;;;;https://scholar.google.com/scholar?start=260&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093452-187;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;[HTML][HTML] The rise of blockchain technology in agriculture and food supply chains;A Kamilaris, A Fonts, FX Prenafeta;Bold?  Trends in Food Science & …, 2019  Elsevier;;"… Since 2014 it has increasingly been realized that blockchain can be used for much more than

cryptocurrency and financial transactions, so that several new applications are being explored

(Tayeb & Lago, 2018): handling and storing administrative records, digital authentication …";Cité 204 fois;Les 15 versions;[HTML] sciencedirect.com;https://www.sciencedirect.com/science/article/pii/S0924224418303686?casa_token=6mHAVvb74gcAAAAA:Sli7weck_FJLi6i5mf78hAphcJTod--Wor6TbpwItPou8nOdgCT8B9VfzTRguINEq3oJKAwU;;;https://scholar.google.com/scholar?start=20&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093539-556;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Construct a three-stage analysis model of integrated main path analysis and patent family-exploring the development of blockchain;FP Su, SJ Chen, YH Chang, KK Lai ; Proceedings of the 2019 3rd …, 2019  dl.acm.org;;"… Oracle Corp., as a leading database company, five patents out of 22 make itself the company

with most patents in the main path of blockchain technology knowledge development. These

five patents were originally owned by Siebel Systems Inc …";Cité 2 fois;;[PDF] acm.org;https://dl.acm.org/doi/pdf/10.1145/3374549.3374583?casa_token=bYbK_f_AkD0AAAAA:zHNuQIyRrn530olst-GqQu9d5ZzqZsuxGmP74jR7XfkT_uqQi5FTOCTzz0WwJ-SPAfZdIAPm_8E;;;https://scholar.google.com/scholar?start=390&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093513-448;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;A blockchain-based privacy-preserving medical insurance storage system;S Luong ;2019 unbscholar.lib.unb.ca;;"Page 1. A Blockchain-based Privacy-preserving Medical Insurance Storage System by Son Luong …

and proposes our future research work. 19 Page 32. Chapter 2 Technical Background of

Blockchain The blockchain can be thought of as a distributed ledger. The ledger is typ …";Cité 1 fois;Les 2 versions;[PDF] unb.ca;https://unbscholar.lib.unb.ca/islandora/object/unbscholar%3A9830/datastream/PDF/view;;"""date"",""2019-05-08T18:38:10Z""
""pdf:unmappedUnicodeCharsPerPage"",""1"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""1"",""4"",""24"",""3"",""3"",""0"",""2"",""2"",""43"",""14"",""0"",""0"",""21"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""9"",""6"",""0"",""0"",""6"",""0"",""2"",""8"",""0"",""9"",""0"",""0"",""0"",""6"",""9"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""2"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""3"",""4"",""1"",""8"",""4"",""7"",""2"",""0"",""8"",""2"",""1"",""0"",""3"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.5""
""xmp:CreatorTool"",""TeX""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dcterms:created"",""2019-05-07T18:42:22Z""
""language"",""en""
""Last-Modified"",""2019-05-08T18:38:10Z""
""dcterms:modified"",""2019-05-08T18:38:10Z""
""dc:format"",""application/pdf; version=1.5""
""xmpMM:DocumentID"",""uuid:4e0495f0-07ce-41a0-bcea-559aec3e87d2""
""Last-Save-Date"",""2019-05-08T18:38:10Z""
""pdf:docinfo:creator_tool"",""TeX""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2019-05-08T18:38:10Z""
""meta:save-date"",""2019-05-08T18:38:10Z""
""pdf:encrypted"",""false""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017) kpathsea version 6.2.3""
""xmp:CreateDate"",""2019-05-07T18:42:22Z""
""modified"",""2019-05-08T18:38:10Z""
""Content-Length"",""1172976""
""pdf:hasMarkedContent"",""false""
""Content-Type"",""application/pdf""
""xmp:ModifyDate"",""2019-05-08T15:38:10Z""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017) kpathsea version 6.2.3""
""xmp:MetadataDate"",""2019-05-08T15:38:10Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""pdf:producer"",""pdfTeX-1.40.18""
""trapped"",""False""
""meta:creation-date"",""2019-05-07T18:42:22Z""
""created"",""2019-05-07T18:42:22Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""133""
""Creation-Date"",""2019-05-07T18:42:22Z""
""resourceName"",""view""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""577"",""1013"",""186"",""345"",""418"",""908"",""942"",""919"",""222"",""420"",""758"",""109"",""763"",""1019"",""1221"",""653"",""1328"",""971"",""1004"",""961"",""981"",""1044"",""1186"",""1049"",""1147"",""939"",""1055"",""1255"",""858"",""957"",""434"",""569"",""1179"",""835"",""1262"",""956"",""839"",""1433"",""783"",""1337"",""1130"",""1119"",""1146"",""1247"",""1210"",""1129"",""1111"",""956"",""1136"",""1217"",""1187"",""1421"",""689"",""574"",""961"",""809"",""703"",""798"",""714"",""979"",""884"",""1119"",""770"",""1081"",""981"",""952"",""681"",""281"",""532"",""1072"",""1242"",""1154"",""1001"",""564"",""526"",""1018"",""898"",""809"",""1040"",""889"",""936"",""791"",""818"",""622"",""862"",""709"",""721"",""354"",""475"",""1255"",""1258"",""1169"",""936"",""972"",""709"",""1202"",""532"",""693"",""1121"",""115"",""609"",""897"",""680"",""1133"",""1066"",""1118"",""1157"",""869"",""961"",""1032"",""950"",""1083"",""289"",""268"",""560"",""616"",""838"",""568"",""1035"",""916"",""1074"",""677"",""693"",""941"",""563"",""685"",""916"",""614"",""637"",""587"",""700"",""291"",""327""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""producer"",""pdfTeX-1.40.18""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""pdfTeX-1.40.18""
""pdf:docinfo:created"",""2019-05-07T18:42:22Z""
";https://scholar.google.com/scholar?start=280&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093462-222;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Blockchain and internet of things for modern business process in digital economy—the state of the art;W Viriyasitavat, L Da Xu, Z Bi… ; IEEE Transactions on …, 2019  ieeexplore.ieee.org;;"… on developers and technical topics in emerging area especially IoT and Blockchain [75], and

2018 Crypto Valley Conference … 88], a project collecting and verifying real-world occurrences

and submitting this infor- mation to Blockchain to be … This information is known as Oracle …";Cité 30 fois;;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/6570650/6780646/08744245.pdf?casa_token=zP5pXh4WFVIAAAAA:hIJ6D4UA5ouaQvGqH1W7cBIIJ_3lMRZCMd0wGU8dLXI_dq8S9QO_BrGFG8fkfycs7oKTslcC9K0;;"""og:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""twitter:title"",""Blockchain and Internet of Things for Modern Business Process in Digital Economy—the State of the Art""
""twitter:card"",""summary""
""Description"",""In addition to functionalities, business process management (BPM) involves several key indicators such as openness, security, flexibility, and scalability. Opti""
""og:title"",""Blockchain and Internet of Things for Modern Business Process in Digital Economy—the State of the Art""
""resourceName"",""08744245.pdf""
""language"",""en""
""title"",""Blockchain and Internet of Things for Modern Business Process in Digital Economy—the State of the Art | IEEE Journals & Magazine | IEEE Xplore""
""og:description"",""In addition to functionalities, business process management (BPM) involves several key indicators such as openness, security, flexibility, and scalability. Optimizing system performance is becoming a great challenge for an ever-increasing large-scale distributed application system in the digital economy on the Internet of Things (IoT) era. In a centralized BPM, many indicators, such as security and openness, or cost and flexibility, are conflicting with each other. For example, inviting new partners across enterprises, domains, and regions to form a service workflow exposes new risks and needs additional security mechanisms for scrutiny; enhancing the flexibility of business workflow compositions increases the cost of security assurance. Blockchain technology (BCT) has thrown the light on the development of vital solutions to various BPM problems. BCT has to be integrated with other BPM system components that often involve IoT devices to implement specified functionalities related to the application. Currently, the potentials of using BCT have been explored although still at an early stage. In this paper, the states of the art are presented to identify emerging research topics, challenges, and promising applications in integrating BCT into the development of BPM.""
""twitter:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-UA-Compatible"",""IE=Edge""
""viewport"",""width=device-width, initial-scale=1.0""
""dc:title"",""Blockchain and Internet of Things for Modern Business Process in Digital Economy—the State of the Art | IEEE Journals & Magazine | IEEE Xplore""
""twitter:description"",""In addition to functionalities, business process management (BPM) involves several key indicators such as openness, security, flexibility, and scalability. Optimizing system performance is becoming a great challenge for an ever-increasing large-scale distributed application system in the digital economy on the Internet of Things (IoT) era. In a centralized BPM, many indicators, such as security and openness, or cost and flexibility, are conflicting with each other. For example, inviting new partners across enterprises, domains, and regions to form a service workflow exposes new risks and needs additional security mechanisms for scrutiny; enhancing the flexibility of business workflow compositions increases the cost of security assurance. Blockchain technology (BCT) has thrown the light on the development of vital solutions to various BPM problems. BCT has to be integrated with other BPM system components that often involve IoT devices to implement specified functionalities related to the application. Currently, the potentials of using BCT have been explored although still at an early stage. In this paper, the states of the art are presented to identify emerging research topics, challenges, and promising applications in integrating BCT into the development of BPM.""
""Content-Encoding"",""UTF-8""
""Content-Type-Hint"",""text/html; charset=utf-8""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=60&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093485-322;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;MeshDapp–Blockchain-Enabled Sustainable Business Models for Networks;E Dimogerontakis, L Navarro, M Selimi… ; … Conference on the …, 2019  Springer;;"… a permissioned blockchain that provides desirable properties such as trusted data feeds (oracles)

about traffic … Solidity smart contracts under an Ethereum PoA permissioned and local blockchain

1 , and … We find the system, smart contract architecture, and the oracle to feed them …";Cité 2 fois;Les 6 versions;[PDF] researchgate.net;https://www.researchgate.net/profile/Mennan_Selimi/publication/337478981_MeshDapp_-_Blockchain-Enabled_Sustainable_Business_Models_for_Networks/links/5edaacfd45851529453becb8/MeshDapp-Blockchain-Enabled-Sustainable-Business-Models-for-Networks.pdf;;;https://scholar.google.com/scholar?start=160&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093541-562;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;FireLedger: a high throughput blockchain consensus protocol;Y Buchnik, R Friedman ; arXiv preprint arXiv:1901.03279, 2019  arxiv.org;;"… an environment, there is no trust between nodes and in fact, with crypto-currencies, participants …

with the synchrony assumptions about the environment in which the blockchain is implemented …

eg, partial synchrony [38, 41], or with unreliable failure detector oracles [32], benign …";Cité 4 fois;Les 4 versions;[PDF] arxiv.org;https://arxiv.org/pdf/1901.03279;;"""date"",""2019-11-04T01:34:35Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2019-11-04T01:34:35Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016) kpathsea version 6.2.2""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2019-11-04T01:34:35Z""
""created"",""2019-11-04T01:34:35Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-11-04T01:34:35Z""
""resourceName"",""1901.03279""
""Author"",""""
""producer"",""pdfTeX-1.40.17""
""pdf:docinfo:producer"",""pdfTeX-1.40.17""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""3"",""4"",""9"",""0"",""1"",""2"",""3"",""13"",""1"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""2"",""0"",""2"",""2"",""0"",""0"",""0"",""0"",""13"",""13"",""6""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2019-11-04T01:34:35Z""
""Last-Modified"",""2019-11-04T01:34:35Z""
""dcterms:modified"",""2019-11-04T01:34:35Z""
""title"",""""
""Last-Save-Date"",""2019-11-04T01:34:35Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2019-11-04T01:34:35Z""
""meta:save-date"",""2019-11-04T01:34:35Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016) kpathsea version 6.2.2""
""Content-Length"",""1277057""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""34""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""3008"",""4222"",""3908"",""3558"",""2758"",""2822"",""2760"",""2295"",""2934"",""1643"",""2408"",""1795"",""3321"",""2501"",""2249"",""3636"",""888"",""1790"",""2303"",""1699"",""1253"",""1556"",""1418"",""1604"",""1525"",""169"",""73"",""2407"",""2783"",""2689"",""2006"",""2173"",""2103"",""1187""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-11-04T01:34:35Z""
";https://scholar.google.com/scholar?start=400&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093466-247;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;[HTML][HTML] A survey on privacy protection in blockchain system;Q Feng, D He, S Zeadally, MK Khan… ; Journal of Network and …, 2019  Elsevier;;"… Previous article in issue; Next article in issue. Keywords. Privacy. Anonymity. Blockchain.

Cryptography. Cryptocurrency. 1. Introduction. Marking the new dawn of a new era, blockchain

is a ground-breaking innovation in decentralized information technology …";Cité 235 fois;Les 2 versions;[HTML] sciencedirect.com;https://www.sciencedirect.com/science/article/pii/S1084804518303485?casa_token=9ar0VK59c_EAAAAA:OzNwSw1tzqb8aOs-CXGzFCOoP7ahtgrSqPN_xL3po3E6dW0g80n4HnXCZY2ABV03JLdRmd4w;;;https://scholar.google.com/scholar?start=80&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093525-491;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Atomic appends: Selling cars and coordinating armies with multiple distributed ledgers;A Fernández Anta, C Georgiou, N Nicolaou ;2019 eprints.networks.imdea.org;;"… In this case, two or more users want to exchange assets (usually cryptocurrency) in 69 multiple

blockchains … The weakest aspect of blockchain oracles is trust, since the outcome 108 or actions

of a smart contract will be as reliable as the data provided by the oracle …";Cité 5 fois;Les 7 versions;[PDF] imdea.org;https://eprints.networks.imdea.org/1991/1/Tokenomics2019.pdf;;"""date"",""2019-04-05T15:06:20Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""Atomic Appends: Selling Cars and Coordinating Armies with Multiple Distributed Ledgers""
""xmp:CreatorTool"",""LaTeX with oasics-v2019.cls and hyperref.sty""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""OASIcs, Vol.71, Tokenomics 2019; Copyright (C), Antonio FernĂĄndez Anta, Chryssis Georgiou and Nicolas Nicolaou; licensed under Creative Commons License CC-BY""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with oasics-v2019.cls and hyperref.sty""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""Atomic Appends: Selling Cars and Coordinating Armies with Multiple Distributed Ledgers""
""modified"",""2019-04-05T15:06:20Z""
""cp:subject"",""OASIcs, Vol.71, Tokenomics 2019; Copyright (C), Antonio FernĂĄndez Anta, Chryssis Georgiou and Nicolas Nicolaou; licensed under Creative Commons License CC-BY""
""pdf:docinfo:subject"",""OASIcs, Vol.71, Tokenomics 2019; Copyright (C), Antonio FernĂĄndez Anta, Chryssis Georgiou and Nicolas Nicolaou; licensed under Creative Commons License CC-BY""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""Antonio FernĂĄndez Anta, Chryssis Georgiou, Nicolas Nicolaou""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.16 (TeX Live 2015) kpathsea version 6.2.1""
""meta:author"",""Antonio FernĂĄndez Anta, Chryssis Georgiou, Nicolas Nicolaou""
""trapped"",""False""
""meta:creation-date"",""2019-04-05T15:06:20Z""
""created"",""2019-04-05T15:06:20Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-04-05T15:06:20Z""
""resourceName"",""Tokenomics2019.pdf""
""Author"",""Antonio FernĂĄndez Anta, Chryssis Georgiou, Nicolas Nicolaou""
""producer"",""pdfTeX-1.40.16""
""pdf:docinfo:producer"",""pdfTeX-1.40.16""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""6"",""8"",""0"",""0"",""4"",""6"",""2"",""4"",""3"",""12"",""0""
""Keywords"",""DLO, Interoperability, Atomic Appends, Rational Clients, Fault-tolerance""
""access_permission:modify_annotations"",""true""
""dc:creator"",""Antonio FernĂĄndez Anta, Chryssis Georgiou, Nicolas Nicolaou""
""dcterms:created"",""2019-04-05T15:06:20Z""
""Last-Modified"",""2019-04-05T15:06:20Z""
""dcterms:modified"",""2019-04-05T15:06:20Z""
""title"",""Atomic Appends: Selling Cars and Coordinating Armies with Multiple Distributed Ledgers""
""Last-Save-Date"",""2019-04-05T15:06:20Z""
""pdf:docinfo:keywords"",""DLO, Interoperability, Atomic Appends, Rational Clients, Fault-tolerance""
""pdf:docinfo:modified"",""2019-04-05T15:06:20Z""
""meta:save-date"",""2019-04-05T15:06:20Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.16 (TeX Live 2015) kpathsea version 6.2.1""
""Content-Length"",""559853""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Antonio FernĂĄndez Anta, Chryssis Georgiou, Nicolas Nicolaou""
""dc:subject"",""DLO, Interoperability, Atomic Appends, Rational Clients, Fault-tolerance""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""15""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""3203"",""3425"",""3594"",""3535"",""3142"",""2872"",""2997"",""2858"",""2954"",""3172"",""2438"",""2542"",""2907"",""2941"",""3238""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""DLO, Interoperability, Atomic Appends, Rational Clients, Fault-tolerance""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-04-05T15:06:20Z""
";https://scholar.google.com/scholar?start=330&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093543-579;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Opportunities and Challenges of DLT (Blockchain) in Mobility and Logistics;G Fridgen, N Guggenberger, T Hoeren, W Prinz… ;2019 orbilu.uni.lu;;"… application for DLT debuted in 2009 in the form of a blockchain for the Bitcoin cryptocurrency …

In the EU, 21 member states have joined in the European Blockchain Partnership to promote

the … into the DLT system, or pro- vide smart contracts for this process (so-called ""oracles"") …";Autres articles;;[PDF] uni.lu;https://orbilu.uni.lu/bitstream/10993/44503/1/Opportunities%20and%20Challenges.pdf;;"""date"",""2020-04-08T10:03:26Z""
""pdf:PDFVersion"",""1.6""
""xmp:CreatorTool"",""Adobe InDesign CS5 (7.0.4)""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""xmpMM:History:Action"",""created"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved""
""language"",""en""
""dc:format"",""application/pdf; version=1.6""
""pdf:docinfo:creator_tool"",""Adobe InDesign CS5 (7.0.4)""
""access_permission:fill_in_form"",""true""
""xmpMM:History:When"",""2019-05-14T11:25:01Z"",""2019-05-14T11:25:40Z"",""2019-05-14T11:25:40Z"",""2019-05-14T11:26:36Z"",""2019-05-14T11:28:01Z"",""2019-05-14T11:28:58Z"",""2019-05-14T11:29:45Z"",""2019-05-14T11:30:59Z"",""2020-03-06T14:57:34Z"",""2020-03-06T14:57:34Z"",""2020-03-06T15:15:34Z"",""2020-03-06T15:21:11Z"",""2020-03-06T15:26:41Z"",""2020-04-08T12:02:28Z""
""pdf:encrypted"",""false""
""xmp:CreateDate"",""2020-04-08T12:02:43Z""
""modified"",""2020-04-08T10:03:26Z""
""xmpMM:History:SoftwareAgent"",""Adobe InDesign 7.0"",""Adobe InDesign 7.0"",""Adobe InDesign 7.0"",""Adobe InDesign 7.0"",""Adobe InDesign 7.0"",""Adobe InDesign 7.0"",""Adobe InDesign 7.0"",""Adobe InDesign 7.0"",""Adobe InDesign 7.0"",""Adobe InDesign 7.0"",""Adobe InDesign 7.0"",""Adobe InDesign 7.0"",""Adobe InDesign 7.0"",""Adobe InDesign 7.0""
""pdf:hasMarkedContent"",""true""
""xmpMM:History:InstanceID"",""xmp.iid:FFE1AF672676E9118E77BFBE344FB3F9"",""xmp.iid:00E2AF672676E9118E77BFBE344FB3F9"",""xmp.iid:01E2AF672676E9118E77BFBE344FB3F9"",""xmp.iid:21A0FD5C2A76E91187E3EB093D99E7D4"",""xmp.iid:22A0FD5C2A76E91187E3EB093D99E7D4"",""xmp.iid:25A0FD5C2A76E91187E3EB093D99E7D4"",""xmp.iid:AB45D2CF2A76E91187E3EB093D99E7D4"",""xmp.iid:AE45D2CF2A76E91187E3EB093D99E7D4"",""xmp.iid:B9CB4B9AB05FEA119FD7C3FE0073FCC0"",""xmp.iid:BCCB4B9AB05FEA119FD7C3FE0073FCC0"",""xmp.iid:BFCB4B9AB05FEA119FD7C3FE0073FCC0"",""xmp.iid:2EF67BBAB55FEA119FD7C3FE0073FCC0"",""xmp.iid:31F67BBAB55FEA119FD7C3FE0073FCC0"",""xmp.iid:12FE92717F79EA119F4EE8DC2119EAEB""
""xmp:ModifyDate"",""2020-04-08T12:03:26Z""
""trapped"",""False""
""meta:creation-date"",""2020-04-08T10:02:43Z""
""created"",""2020-04-08T10:02:43Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-04-08T10:02:43Z""
""resourceName"",""Opportunities%20and%20Challenges.pdf""
""xmpMM:DerivedFrom:DocumentID"",""xmp.did:FFE1AF672676E9118E77BFBE344FB3F9""
""producer"",""Adobe PDF Library 9.9""
""pdf:docinfo:producer"",""Adobe PDF Library 9.9""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""access_permission:modify_annotations"",""true""
""dcterms:created"",""2020-04-08T10:02:43Z""
""Last-Modified"",""2020-04-08T10:03:26Z""
""dcterms:modified"",""2020-04-08T10:03:26Z""
""xmpMM:DocumentID"",""xmp.did:BCCB4B9AB05FEA119FD7C3FE0073FCC0""
""Last-Save-Date"",""2020-04-08T10:03:26Z""
""pdf:docinfo:modified"",""2020-04-08T10:03:26Z""
""meta:save-date"",""2020-04-08T10:03:26Z""
""Content-Length"",""5618881""
""Content-Type"",""application/pdf""
""xmp:MetadataDate"",""2020-04-08T12:03:26Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""pdf:producer"",""Adobe PDF Library 9.9""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""244""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""74"",""0"",""732"",""0"",""7512"",""8042"",""8152"",""7294"",""2958"",""3592"",""3771"",""3455"",""3687"",""3815"",""3237"",""3459"",""3767"",""4066"",""3669"",""3519"",""2176"",""3472"",""3867"",""3835"",""2295"",""1989"",""2644"",""2387"",""3087"",""3469"",""2258"",""3280"",""2579"",""2652"",""3275"",""3584"",""2398"",""1551"",""2536"",""2827"",""2564"",""2825"",""2701"",""3594"",""900"",""2200"",""3809"",""3163"",""3575"",""3704"",""3787"",""3697"",""2685"",""2579"",""2547"",""2562"",""3390"",""2132"",""3393"",""3366"",""3426"",""3594"",""2246"",""2173"",""2908"",""2116"",""3435"",""3540"",""3647"",""3584"",""3560"",""2688"",""2571"",""3495"",""3649"",""3468"",""2877"",""3534"",""3721"",""3354"",""2110"",""3595"",""3853"",""2637"",""2980"",""1455"",""3258"",""2414"",""3453"",""2518"",""3282"",""3250"",""3018"",""3497"",""3182"",""2821"",""3212"",""2519"",""3692"",""2282"",""237"",""2181"",""3873"",""3787"",""2696"",""2978"",""2896"",""3365"",""3549"",""3992"",""3612"",""3468"",""3548"",""3684"",""3397"",""3623"",""3996"",""4089"",""3576"",""3313"",""3185"",""2854"",""3277"",""3273"",""3233"",""3345"",""3473"",""3164"",""2889"",""3400"",""3566"",""3665"",""3347"",""3403"",""3226"",""3205"",""3375"",""3343"",""3311"",""3689"",""3409"",""3364"",""3444"",""3710"",""3563"",""3464"",""1884"",""2912"",""1555"",""2249"",""3565"",""3621"",""3531"",""3625"",""3354"",""1735"",""2766"",""2588"",""3505"",""3241"",""3536"",""3419"",""3258"",""2987"",""3153"",""3063"",""3423"",""3146"",""1387"",""2812"",""2440"",""3152"",""2418"",""2728"",""3615"",""2741"",""2284"",""1295"",""3370"",""2537"",""3031"",""2911"",""1726"",""2320"",""2457"",""3695"",""3170"",""3177"",""1395"",""3373"",""3375"",""3086"",""2223"",""3376"",""3432"",""3115"",""2846"",""3461"",""2495"",""3318"",""797"",""2839"",""2439"",""3600"",""3481"",""3536"",""3519"",""2571"",""3050"",""3163"",""2532"",""3204"",""3233"",""2897"",""3276"",""3525"",""2894"",""3126"",""3421"",""1687"",""3789"",""3926"",""1453"",""2018"",""2469"",""2357"",""2450"",""2484"",""2362"",""2442"",""2405"",""2199"",""2334"",""2334"",""2405"",""2367"",""2458"",""2550"",""2401"",""2312"",""2036"",""7"",""429"",""11""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""xmpMM:DerivedFrom:InstanceID"",""xmp.iid:B9CB4B9AB05FEA119FD7C3FE0073FCC0""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-04-08T10:02:43Z""
";https://scholar.google.com/scholar?start=410&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093459-217;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;A blockchain based witness model for trustworthy cloud service level agreement enforcement;H Zhou, X Ouyang, Z Ren, J Su… ; IEEE INFOCOM 2019 …, 2019  ieeexplore.ieee.org;;"… Oraclize2 is a trusted company acting as the third party, offering the service as an oracle.

But it exists single-point of failure and deviates from the decentralization idea of blockchain.

To cope with this, ChainLink [15] works on distributed oracles …";Cité 22 fois;Les 6 versions;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/8732929/8737365/08737580.pdf?casa_token=n05lQgkVNpoAAAAA:oacPmmtM_GBdNzDeQ9NXfZRgTqwrBWIRN7X4HFVJtEiMU4c32uIhVOg-lkJJd6ZPqnaPiPE3_QQ;;"""og:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""twitter:title"",""A Blockchain based Witness Model for Trustworthy Cloud Service Level Agreement Enforcement""
""twitter:card"",""summary""
""Description"",""Traditional cloud Service Level Agreement (SLA) suffers from lacking a trustworthy platform for automatic enforcement. The emerging blockchain technique brings ""
""og:title"",""A Blockchain based Witness Model for Trustworthy Cloud Service Level Agreement Enforcement""
""resourceName"",""08737580.pdf""
""language"",""en""
""title"",""A Blockchain based Witness Model for Trustworthy Cloud Service Level Agreement Enforcement | IEEE Conference Publication | IEEE Xplore""
""og:description"",""Traditional cloud Service Level Agreement (SLA) suffers from lacking a trustworthy platform for automatic enforcement. The emerging blockchain technique brings in an immutable solution for tracking transactions among business partners. However, it is still very challenging to prove the credibility of possible violations in the SLA before recording them onto the blockchain. To tackle this challenge, we propose a witness model using game theory and the smart contract techniques. The proposed model extends the existing service model with a new role called “witness” for detecting and reporting service violations. Witnesses gain revenue as an incentive for performing these duties, and the payoff function is carefully designed in a way that trustworthiness is guaranteed: in order to get the maximum profit, the witness has to always tell the truth. This is analyzed and proved through game theory using the Nash equilibrium principle. In addition, an unbiased sortition algorithm is proposed to ensure the randomness of the independent witnesses selection from the decentralized witness pool, to avoid possible unfairness or collusion. An auditing mechanism is also introduced in the paper to detect potential irrational or malicious witnesses. We have prototyped the system leveraging the smart contracts of Ethereum blockchain. Experimental results demonstrate the feasibility of the proposed model and indicate good performance in accordance with the design expectations.""
""twitter:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-UA-Compatible"",""IE=Edge""
""viewport"",""width=device-width, initial-scale=1.0""
""dc:title"",""A Blockchain based Witness Model for Trustworthy Cloud Service Level Agreement Enforcement | IEEE Conference Publication | IEEE Xplore""
""twitter:description"",""Traditional cloud Service Level Agreement (SLA) suffers from lacking a trustworthy platform for automatic enforcement. The emerging blockchain technique brings in an immutable solution for tracking transactions among business partners. However, it is still very challenging to prove the credibility of possible violations in the SLA before recording them onto the blockchain. To tackle this challenge, we propose a witness model using game theory and the smart contract techniques. The proposed model extends the existing service model with a new role called “witness” for detecting and reporting service violations. Witnesses gain revenue as an incentive for performing these duties, and the payoff function is carefully designed in a way that trustworthiness is guaranteed: in order to get the maximum profit, the witness has to always tell the truth. This is analyzed and proved through game theory using the Nash equilibrium principle. In addition, an unbiased sortition algorithm is proposed to ensure the randomness of the independent witnesses selection from the decentralized witness pool, to avoid possible unfairness or collusion. An auditing mechanism is also introduced in the paper to detect potential irrational or malicious witnesses. We have prototyped the system leveraging the smart contracts of Ethereum blockchain. Experimental results demonstrate the feasibility of the proposed model and indicate good performance in accordance with the design expectations.""
""Content-Encoding"",""UTF-8""
""Content-Type-Hint"",""text/html; charset=utf-8""
""Content-Length"",""42900""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=50&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093473-280;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Introduction to the tezos blockchain;V Allombert, M Bourgoin… ; … Conference on High …, 2019  ieeexplore.ieee.org;;"… Some smart contracts, being fed with off-chain information, serve as Oracles selling trusted

information … contracts can be used in many applications such as financial contracts, developing

new currencies on top of the basic crypto-currency of the blockchain, voting systems …";Cité 7 fois;Les 8 versions;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/9183768/9188050/09188227.pdf?casa_token=kWXG4YkDgd8AAAAA:fJwO6l8tveXYMuOfwch5lKeyZQA7s8IOXLjY5dafejUI8aDb5Upi6yK2E8enb5WlrQHh_3qHSsI;;"""og:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""twitter:title"",""Introduction to the Tezos Blockchain""
""twitter:card"",""summary""
""Description"",""Tezos is an innovative blockchain that improves on several aspects compared to more established blockchains. It offers an original proof-of-stake consensus algo""
""og:title"",""Introduction to the Tezos Blockchain""
""resourceName"",""09188227.pdf""
""language"",""en""
""title"",""Introduction to the Tezos Blockchain | IEEE Conference Publication | IEEE Xplore""
""og:description"",""Tezos is an innovative blockchain that improves on several aspects compared to more established blockchains. It offers an original proof-of-stake consensus algorithm and can be used as a decentralized smart contract platform. It has the capacity to amend its own economic protocol through a voting mechanism and focuses on formal methods to improve safety.""
""twitter:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-UA-Compatible"",""IE=Edge""
""viewport"",""width=device-width, initial-scale=1.0""
""dc:title"",""Introduction to the Tezos Blockchain | IEEE Conference Publication | IEEE Xplore""
""twitter:description"",""Tezos is an innovative blockchain that improves on several aspects compared to more established blockchains. It offers an original proof-of-stake consensus algorithm and can be used as a decentralized smart contract platform. It has the capacity to amend its own economic protocol through a voting mechanism and focuses on formal methods to improve safety.""
""Content-Encoding"",""UTF-8""
""Content-Type-Hint"",""text/html; charset=utf-8""
""Content-Length"",""38542""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=110&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093487-337;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;[HTML][HTML] A secure versatile light payment system based on blockchain;L Zhong, Q Wu, J Xie, J Li, B Qin ; Future Generation Computer Systems, 2019  Elsevier;;"… multiple blockchains. Users could access to new and innovative cryptocurrency

systems using the assets they already own. Built on the Bitcoin blockchain, Discoin

and Seidel [22] proposed a PeerCensus system. The system …";Cité 18 fois;Les 2 versions;[HTML] sciencedirect.com;https://www.sciencedirect.com/science/article/pii/S0167739X18302656?casa_token=THiFJBoBHgMAAAAA:IEYB6SIqA4UQ1IVCwjOUhwRD487J6FgShMLp-uthMMXJO8D7MVBHegHuVNxmVdToy6db09w2;;;https://scholar.google.com/scholar?start=170&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093494-369;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Decentralized distribution of PCP mappings over blockchain for end-to-end secure direct communications;EF Kfoury, J Gomez, J Crichigno, E Bou;Harb…  IEEE …, 2019  ieeexplore.ieee.org;;"… renders the whole system vulnerable. As a pre-condition for PCP DevID i verification,

we assume that the oracle service is not tampering with the data retrieved from outside

the Blockchain. Although this might bring central- ization …";Cité 3 fois;Les 2 versions;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/6287639/8600701/08792050.pdf;;"""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""dc:title"",""IEEE Xplore Full-Text PDF:""
""Content-Encoding"",""UTF-8""
""resourceName"",""08792050.pdf""
""language"",""es""
""Content-Length"",""2565""
""title"",""IEEE Xplore Full-Text PDF:""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=200&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093506-415;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Batching techniques for accumulators with applications to iops and stateless blockchains;D Boneh, B Bünz, B Fisch ; Annual International Cryptology Conference, 2019  Springer;;"… While the stateless blockchain design reduces the storage burden of node performing transaction

validation, it … This technique has been generalized to the broader class of interactive oracle proofs

(IOPs) [BCS16]. In an IOP the prover sends multiple proof oracles to a verifier …";Cité 80 fois;Les 4 versions;[PDF] iacr.org;https://eprint.iacr.org/2018/1188.pdf;;"""date"",""2019-05-20T14:30:08Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2019-05-20T14:30:08Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.19 (TeX Live 2018) kpathsea version 6.3.0""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2019-05-20T14:30:08Z""
""created"",""2019-05-20T14:30:08Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-05-20T14:30:08Z""
""resourceName"",""1188.pdf""
""Author"",""""
""producer"",""pdfTeX-1.40.19""
""pdf:docinfo:producer"",""pdfTeX-1.40.19""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""3"",""24"",""10"",""27"",""20"",""15"",""13"",""1"",""11"",""8"",""4"",""31"",""6"",""32"",""6"",""10"",""0"",""0"",""0"",""3"",""0"",""0"",""0"",""0"",""0"",""0"",""22"",""20"",""37"",""16"",""14"",""6"",""45"",""32"",""38"",""39"",""80"",""44"",""56"",""32"",""47"",""16""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2019-05-20T14:30:08Z""
""Last-Modified"",""2019-05-20T14:30:08Z""
""dcterms:modified"",""2019-05-20T14:30:08Z""
""title"",""""
""Last-Save-Date"",""2019-05-20T14:30:08Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2019-05-20T14:30:08Z""
""meta:save-date"",""2019-05-20T14:30:08Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.19 (TeX Live 2018) kpathsea version 6.3.0""
""Content-Length"",""682314""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""46""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""2912"",""3648"",""3681"",""3375"",""2334"",""2576"",""2896"",""2734"",""2707"",""2669"",""2522"",""3019"",""2484"",""2348"",""3102"",""2376"",""2944"",""2860"",""2177"",""2768"",""2662"",""3387"",""3421"",""3325"",""3153"",""2533"",""2607"",""2437"",""2562"",""993"",""2310"",""2386"",""2705"",""2881"",""2302"",""2767"",""3179"",""3181"",""2540"",""2641"",""2973"",""2596"",""3645"",""2783"",""1473"",""293""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-05-20T14:30:08Z""
";https://scholar.google.com/scholar?start=250&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093509-427;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Efficient publicly verifiable 2pc over a blockchain with applications to financially-secure computations;R Zhu, C Ding, Y Huang ; Proceedings of the 2019 ACM SIGSAC …, 2019  dl.acm.org;;"… When its ledger is used to record balances of accounts, a blockchain essentially realizes a

cryptocurrency … In practice, garbling schemes can be efficiently implemented using

hardware-accelerated assembly instructions either in the ran- dom oracle model [10, 41] or …";Cité 4 fois;Les 3 versions;[PDF] acm.org;https://dl.acm.org/doi/pdf/10.1145/3319535.3363215?casa_token=Gc0n0DD0eb0AAAAA:s5hSh_tc02FWRLN9esmbOOG6cxwe560eK7ZZ5cwu5Hh2x7V-pdCbGktPiYhdxjglimX6lCXkiUk;;;https://scholar.google.com/scholar?start=260&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093518-469;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Inter blockchain communication: A survey;IA Qasse, M Abu Talib, Q Nasir ; … of the ArabWIC 6th Annual International …, 2019  dl.acm.org;;"… Cross-chain oracles use case … Metronome [27] is a project that aims to create a better

cryptocurrency solution by enhancing current crypto systems … Along with enhancing the throughput,

Metronome enables cross- blockchain transfer, where a user can transfer its token from one …";Cité 6 fois;Les 2 versions;[PDF] acm.org;https://dl.acm.org/doi/pdf/10.1145/3333165.3333167?casa_token=R4nXCidTEA8AAAAA:r9ynMbV5jcwtfHRE1AM8bb87vjPyzD0NnO12uZDUBwPx0Hk0XGJbD7iwMIDMQgSsXOsEQgGGcP0;;;https://scholar.google.com/scholar?start=300&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093485-327;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;A Risk Redistribution Standard for Practical Cryptocurrency Payment;YC Hu, TT Lee, C Lam ; 2019 IEEE International Conference …, 2019  ieeexplore.ieee.org;;"… The entire logic within the blockchain space can collapse due to an incorrect input of information

from … the system can choose to rely on multiple sources of information, particularly, multi- ple Oracle

contracts … It reduces the chance for a majority of the Oracles to act faulty, but at the …";Cité 1 fois;Les 3 versions;null;;;;https://scholar.google.com/scholar?start=160&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093506-413;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Blockchain Economic Theory: Digital Asset Contracting reduces Debt and Risk;M Swan ; Blockchain Economics. London: World Scientific …, 2019  World Scientific;;"… Resets are orchestrated digitally at present, and could be further automated with greater

transparency with blockchain-based lookup processes using oracles (independent data providers) …

The Truth About Blockchain. Harvard Business Review. IBM … (2018a). Crypto Token …";Cité 5 fois;Les 6 versions;[PDF] pbworks.com;http://openthoughtspace.pbworks.com/w/file/fetch/128952627/1_Swan.pdf;;"""date"",""2018-08-27T00:46:17Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.7""
""pdf:docinfo:title"",""Microsoft Word - 1_Swan.docx""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dc:creator"",""plus""
""dcterms:created"",""2018-08-27T00:46:17Z""
""language"",""en""
""Last-Modified"",""2018-08-27T00:46:17Z""
""dcterms:modified"",""2018-08-27T00:46:17Z""
""dc:format"",""application/pdf; version=1.7""
""title"",""Microsoft Word - 1_Swan.docx""
""Last-Save-Date"",""2018-08-27T00:46:17Z""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2018-08-27T00:46:17Z""
""meta:save-date"",""2018-08-27T00:46:17Z""
""pdf:encrypted"",""false""
""dc:title"",""Microsoft Word - 1_Swan.docx""
""modified"",""2018-08-27T00:46:17Z""
""Content-Length"",""578762""
""pdf:hasMarkedContent"",""false""
""Content-Type"",""application/pdf""
""pdf:docinfo:creator"",""plus""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""plus""
""meta:author"",""plus""
""meta:creation-date"",""2018-08-27T00:46:17Z""
""created"",""2018-08-27T00:46:17Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""21""
""Creation-Date"",""2018-08-27T00:46:17Z""
""resourceName"",""1_Swan.pdf""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""1236"",""1472"",""2236"",""2173"",""2336"",""1785"",""2248"",""2513"",""2289"",""2181"",""2416"",""2193"",""2549"",""2329"",""2525"",""2085"",""2246"",""2080"",""2321"",""2195"",""1686""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""Author"",""plus""
""producer"",""Microsoft: Print To PDF""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""Microsoft: Print To PDF""
""pdf:docinfo:created"",""2018-08-27T00:46:17Z""
";https://scholar.google.com/scholar?start=250&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093492-360;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Distributed community detection over blockchain networks based on structural entropy;Y Chen, J Liu ; … the 2019 ACM International Symposium on Blockchain …, 2019  dl.acm.org;;"… Beyond cryptocurrency and financial-related applications, the generalised blockchain has

demonstrated … Based on the P2P network architecture, the generalised blockchain can be …

coordination (through transactions, smart con- tracts, and validation oracles) and facilitation …";Cité 6 fois;Les 3 versions;[PDF] acm.org;https://dl.acm.org/doi/pdf/10.1145/3327960.3332381?casa_token=HlYG_Y_J0f8AAAAA:FV7w9LxTDXA_8Kke120XGpgeIeHkJ14YsWFKASek3oCM35U6XBUSP9xET4vM3niooqZNeVqJKPg;;;https://scholar.google.com/scholar?start=190&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093504-410;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;[LIVRE][B] Les ŤSmart Contractsť en droit des obligations suisse;C Müller ; unine.ch;;"… 20 Cf. https://www.ethereum-france.com/les-oracles-lien-entre-la-blockchain-et-le- monde

(derničre consultation le 11.09.2018). 21 CHOULI/GOUJON/LEPORCHER (n. 12), p. 162 s. ;

SCHULZ (n. 12), p. 111 ; HECKMANN/KAULARTZ (n. 10), p. 139. Page 9 …";Cité 1 fois;Les 2 versions;[PDF] unine.ch;http://www.unine.ch/files/live/sites/christoph.mueller/files/Publications/Les%20smart%20contracts%20en%20droit%20des%20obligations%20suisse.pdf;;"""date"",""2019-01-08T09:38:01Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.6""
""xmp:CreatorTool"",""MicrosoftÂŽ Word 2016""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dc:creator"",""Anne-Sylvie Dupont""
""dcterms:created"",""2019-01-08T09:37:26Z""
""language"",""fr""
""Last-Modified"",""2019-01-08T09:38:01Z""
""dcterms:modified"",""2019-01-08T09:38:01Z""
""dc:format"",""application/pdf; version=1.6""
""xmpMM:DocumentID"",""uuid:3315f35c-6217-4da3-beaf-07271e2914c5""
""Last-Save-Date"",""2019-01-08T09:38:01Z""
""pdf:docinfo:creator_tool"",""MicrosoftÂŽ Word 2016""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2019-01-08T09:38:01Z""
""meta:save-date"",""2019-01-08T09:38:01Z""
""pdf:encrypted"",""false""
""xmp:CreateDate"",""2019-01-08T10:37:26Z""
""modified"",""2019-01-08T09:38:01Z""
""Content-Length"",""672919""
""pdf:hasMarkedContent"",""true""
""Content-Type"",""application/pdf""
""xmp:ModifyDate"",""2019-01-08T10:38:01Z""
""pdf:docinfo:creator"",""Anne-Sylvie Dupont""
""xmp:MetadataDate"",""2019-01-08T10:38:01Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Anne-Sylvie Dupont""
""meta:author"",""Anne-Sylvie Dupont""
""pdf:producer"",""MicrosoftÂŽ Word 2016""
""meta:creation-date"",""2019-01-08T09:37:26Z""
""created"",""2019-01-08T09:37:26Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""64""
""Creation-Date"",""2019-01-08T09:37:26Z""
""resourceName"",""Les%20smart%20contracts%20en%20droit%20des%20obligations%20suisse.pdf""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""2271"",""1776"",""2297"",""2216"",""2638"",""2453"",""2584"",""2395"",""2468"",""2337"",""2693"",""2314"",""2271"",""2185"",""2493"",""2214"",""2115"",""2035"",""2211"",""2457"",""2298"",""2317"",""2458"",""2382"",""2014"",""1413"",""2565"",""2186"",""2291"",""2115"",""2440"",""2393"",""2369"",""2115"",""2452"",""2430"",""3592"",""2705"",""2280"",""1980"",""2196"",""2205"",""2237"",""1938"",""2466"",""2385"",""2628"",""2049"",""2252"",""2412"",""2525"",""2423"",""2378"",""2225"",""2116"",""2248"",""1622"",""1741"",""1675"",""1739"",""1754"",""1574"",""1777"",""417""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""Author"",""Anne-Sylvie Dupont""
""producer"",""MicrosoftÂŽ Word 2016""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""MicrosoftÂŽ Word 2016""
""pdf:docinfo:created"",""2019-01-08T09:37:26Z""
";https://scholar.google.com/scholar?start=240&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093462-228;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;A service-oriented perspective on blockchain smart contracts;F Daniel, L Guida ; IEEE Internet Computing, 2019  ieeexplore.ieee.org;;"… DISCUSSION AND OUTLOOK By now, there is a general consensus that the impact of blockchain

will go far beyond crypto- currencies, possibly with … Bitcoin Ethereum Hyperledger Fabric Corda

Contract type Contracts, oracles Contracts, libraries, data contracts, oracles …";Cité 25 fois;Les 10 versions;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/4236/8662787/08598947.pdf?casa_token=pU4iiCCWdoIAAAAA:C6y8520YCDRcIfwn1CGATc9TcFZe6-pjDDS37Mn6WlXItW6q1EmFxZ1llD5a1qF4aIGaT3pwbXU;;"""og:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""twitter:title"",""A Service-Oriented Perspective on Blockchain Smart Contracts""
""twitter:card"",""summary""
""Description"",""Smart contracts turn blockchains into distributed computing platforms. This paper studies whether smart contracts as implemented by a state-of-the-art blockchai""
""og:title"",""A Service-Oriented Perspective on Blockchain Smart Contracts""
""resourceName"",""08598947.pdf""
""language"",""en""
""title"",""A Service-Oriented Perspective on Blockchain Smart Contracts | IEEE Journals & Magazine | IEEE Xplore""
""og:description"",""Smart contracts turn blockchains into distributed computing platforms. This paper studies whether smart contracts as implemented by a state-of-the-art blockchain technology may serve as a component technology for a computing paradigm like service-oriented computing in the blockchain, in order to foster reuse and increase cost-effectiveness.""
""twitter:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-UA-Compatible"",""IE=Edge""
""viewport"",""width=device-width, initial-scale=1.0""
""dc:title"",""A Service-Oriented Perspective on Blockchain Smart Contracts | IEEE Journals & Magazine | IEEE Xplore""
""twitter:description"",""Smart contracts turn blockchains into distributed computing platforms. This paper studies whether smart contracts as implemented by a state-of-the-art blockchain technology may serve as a component technology for a computing paradigm like service-oriented computing in the blockchain, in order to foster reuse and increase cost-effectiveness.""
""Content-Encoding"",""UTF-8""
""Content-Type-Hint"",""text/html; charset=utf-8""
""Content-Length"",""38684""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=60&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093543-576;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;[CITATION][C] 10 Regulating Smart Contracts and Digital Platforms;J Wang, L Chen;;;null;;null;null;;;;https://scholar.google.com/scholar?start=410&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093504-409;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;How Sentiment Impacts the Success of Blockchain Startups–An Analysis of Social Media Data and Initial Coin Offerings;S Albrecht, B Lutz, D Neumann ;2019 aisel.aisnet.org;;"… Virtual Machine, that can, for instance, be triggered by external data sources (oracles) … the smart

contract updates these balances (transactions can contain the cryptocurrency Ether, data or … While

it may appear that many blockchain startups are developing or operating their own …";Cité 13 fois;Les 5 versions;[PDF] hawaii.edu;https://scholarspace.manoa.hawaii.edu/bitstream/10125/59892/1/0452.pdf;;"""date"",""2018-09-15T17:35:12Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""1"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.5""
""xmp:CreatorTool"",""TeX""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dcterms:created"",""2018-09-15T17:35:12Z""
""language"",""en""
""Last-Modified"",""2018-09-15T17:35:12Z""
""dcterms:modified"",""2018-09-15T17:35:12Z""
""dc:format"",""application/pdf; version=1.5""
""Last-Save-Date"",""2018-09-15T17:35:12Z""
""pdf:docinfo:creator_tool"",""TeX""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2018-09-15T17:35:12Z""
""meta:save-date"",""2018-09-15T17:35:12Z""
""pdf:encrypted"",""false""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.16 (TeX Live 2015/Debian) kpathsea version 6.2.1""
""modified"",""2018-09-15T17:35:12Z""
""Content-Length"",""303880""
""pdf:hasMarkedContent"",""false""
""Content-Type"",""application/pdf""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.16 (TeX Live 2015/Debian) kpathsea version 6.2.1""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""trapped"",""False""
""meta:creation-date"",""2018-09-15T17:35:12Z""
""created"",""2018-09-15T17:35:12Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""10""
""Creation-Date"",""2018-09-15T17:35:12Z""
""resourceName"",""0452.pdf""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""3913"",""4325"",""3449"",""4400"",""4219"",""3828"",""4095"",""2841"",""4493"",""4636""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""producer"",""pdfTeX-1.40.16""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""pdfTeX-1.40.16""
""pdf:docinfo:created"",""2018-09-15T17:35:12Z""
";https://scholar.google.com/scholar?start=240&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093492-358;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Competitive compliance with blockchain;S Wohlgemuth, K Umezawa, Y Mishina… ; 2019 IEEE …, 2019  ieeexplore.ieee.org;;"… CL) signature and verifiable Camenisch-Shoup (CS) encryption scheme proven under the random

oracle model [32] … We introduce with SK4SC a probabilistic proof system with blockchain for

cybersecurity … [10] M. Bellare and P. Rogaway, “Random Oracles are Practical: A …";Cité 4 fois;Les 2 versions;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/8718765/8730567/08730684.pdf?casa_token=egyVxLVodX8AAAAA:RqM6SGfL_-QY_b3kXw2mdNOxHgaLE4mQea1HHLzvXJjolTg-zqT07_JSG3xcrETujqbyVci-3O4;;"""og:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""twitter:title"",""Competitive Compliance with Blockchain""
""twitter:card"",""summary""
""Description"",""Authentication is essential for sharing information in IoT and its secondary use with AI-capable machines. The aim is to support humans in optimizing risk of su""
""og:title"",""Competitive Compliance with Blockchain""
""resourceName"",""08730684.pdf""
""language"",""en""
""title"",""Competitive Compliance with Blockchain | IEEE Conference Publication | IEEE Xplore""
""og:description"",""Authentication is essential for sharing information in IoT and its secondary use with AI-capable machines. The aim is to support humans in optimizing risk of supply chains for industrial manufacturing and service provisioning in a timely manner. The ultimate aim is sustainability. The problem for deciding on authentication is probably imperfect information on compliance. Its asymmetric implications of the meaning of contracts for secure information sharing may cause vulnerability of data breach and misuse. A traditional way to avoid harm of that asymmetry requires authentic and consistent sharing of audit information on violation of a certification policy to a centralized audit intelligence. This information sharing is, however, subject to the problem of single point of failure of the centralized audit intelligence. With our work on Security by Design, we show a non-central approach of clarifying accountability to reduce the risk caused by asymmetric implications of the meaning of contracts on authentication. Our signaling and screening scheme SK4SC provides personal digital evidences on compliance to multilateral policies on using information or in other words on trustworthiness. Blockchains are used to realize their symmetric distribution while users share risk on accountability with competition on incentives in a privacy-enhancing manner. Customer relationship management with royalty points, e.g., for eGovernment with taxation, is an example for using SK4SC as digital platform.""
""twitter:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-UA-Compatible"",""IE=Edge""
""viewport"",""width=device-width, initial-scale=1.0""
""dc:title"",""Competitive Compliance with Blockchain | IEEE Conference Publication | IEEE Xplore""
""twitter:description"",""Authentication is essential for sharing information in IoT and its secondary use with AI-capable machines. The aim is to support humans in optimizing risk of supply chains for industrial manufacturing and service provisioning in a timely manner. The ultimate aim is sustainability. The problem for deciding on authentication is probably imperfect information on compliance. Its asymmetric implications of the meaning of contracts for secure information sharing may cause vulnerability of data breach and misuse. A traditional way to avoid harm of that asymmetry requires authentic and consistent sharing of audit information on violation of a certification policy to a centralized audit intelligence. This information sharing is, however, subject to the problem of single point of failure of the centralized audit intelligence. With our work on Security by Design, we show a non-central approach of clarifying accountability to reduce the risk caused by asymmetric implications of the meaning of contracts on authentication. Our signaling and screening scheme SK4SC provides personal digital evidences on compliance to multilateral policies on using information or in other words on trustworthiness. Blockchains are used to realize their symmetric distribution while users share risk on accountability with competition on incentives in a privacy-enhancing manner. Customer relationship management with royalty points, e.g., for eGovernment with taxation, is an example for using SK4SC as digital platform.""
""Content-Encoding"",""UTF-8""
""Content-Type-Hint"",""text/html; charset=utf-8""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=190&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093464-234;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;[HTML][HTML] Blockchain paradigm and Internet of Things;V Rakovic, J Karamachoski, V Atanasovski… ; Wireless Personal …, 2019  Springer;Kingdom of the Netherlands;"… However, Blockchain is a stand-alone technology that can be applied to many distributed

scenarios and can operate without the cryptocurrency aspects. Blockchain can be perceived

as a log digital stream of records that are concatenated into timestamped blocks …";Cité 10 fois;Les 7 versions;[HTML] springer.com;https://idp.springer.com/authorize/casa?redirect_uri=https://link.springer.com/article/10.1007/s11277-019-06270-9&casa_token=RTUhjI8KTccAAAAA:zE4O3Dcaz8ZXgsSXopRepMkJuuqkbh4xQ1S70F-ZTTYBQK6Br8q1dxap91tKk9bcdPzAwQA84e2tLyI;;"""dc.publisher"",""Springer""
""og:image"",""https://media.springernature.com/w200/springer-static/cover/journal/11277.jpg""
""twitter:card"",""summary""
""og:site_name"",""Wireless Personal Communications""
""citation_reference"",""citation_journal_title=IEEE Communications Surveys Tutorials; citation_title=A survey of iot-enabled cyberattacks: Assessing attack paths to critical infrastructures and services; citation_author=I Stellios, P Kotzanikolaou, M Psarakis, C Alcaraz, J Lopez; citation_volume=20; citation_publication_date=2018; citation_pages=3453-3495; citation_doi=10.1109/COMST.2018.2855563; citation_id=CR1"",""citation_journal_title=IEEE Transactions on Smart Grid; citation_title=Distributed blockchain-based data protection framework for modern power systems against cyber attacks; citation_author=G Liang, SR Weller, F Luo, J Zhao, ZY Dong; citation_publication_date=2018; citation_id=CR2"",""Karamachoski, J., Gavrilovska, L., & Sefidanoski, A. (2018). The fusion between blockchain and iot for healthcare systems. In ETAI Conference, ETAI ’18 (pp. 1–6)."",""citation_journal_title=IEEE Internet of Things Journal; citation_title=Analytical model for sybil attack phases in internet of things; citation_author=AK Mishra, AK Tripathy, D Puthal, LT Yang; citation_volume=6; citation_publication_date=2018; citation_pages=379-387; citation_doi=10.1109/JIOT.2018.2843769; citation_id=CR4"",""Singh, A., Ngan, T., Druschel, P., & Wallach, D. S. (2006). Eclipse attacks on overlay networks: Threats and defenses. In Proceedings IEEE INFOCOM 2006. 25th IEEE international conference on computer communications (pp. 1–12).                      https://doi.org/10.1109/INFOCOM.2006.231                                        ."",""Natoli, C., & Gramoli, V. (2016). The balance attack against proof-of-work blockchains: The R3 testbed as an example.                      arXiv:abs/1612.09426                                        ."",""citation_journal_title=IEEE Communications Surveys Tutorials; citation_title=A survey on security and privacy issues of bitcoin; citation_author=M Conti, ES Kumar, C Lal, S Ruj; citation_volume=20; citation_publication_date=2018; citation_pages=3416-3452; citation_doi=10.1109/COMST.2018.2842460; citation_id=CR7"",""Gervais, A., Karame, G. O., Wüst, K., Glykantzis, V., Ritzdorf, H., & Capkun, S. (2016). On the security and performance of proof of work blockchains. In: Proceedings of the 2016 ACM SIGSAC conference on computer and communications security, CCS ’16 (pp. 3–16). New York, NY: ACM.                      https://doi.org/10.1145/2976749.2978341                                        ."",""Duong, T., Chepurnoy, A., Fan, L., & Zhou, H. S. (2018). Twinscoin: A cryptocurrency via proof-of-work and proof-of-stake. In Proceedings of the 2Nd ACM workshop on blockchains, cryptocurrencies, and contracts, BCC ’18 (pp. 1–13). New York, NY: ACM.                      https://doi.org/10.1145/3205230.3205233                                        ."",""citation_journal_title=IEEE Access; citation_title=Blockchains and smart contracts for the internet of things; citation_author=K Christidis, M Devetsikiotis; citation_volume=4; citation_publication_date=2016; citation_pages=2292-2303; citation_doi=10.1109/ACCESS.2016.2566339; citation_id=CR10"",""citation_journal_title=IEEE Wireless Communications Letters; citation_title=Incentivizing consensus propagation in proof-of-stake based consortium blockchain networks; citation_author=J Kang, Z Xiong, D Niyato, P Wang, D Ye, DI Kim; citation_volume=8; citation_publication_date=2018; citation_pages=157-160; citation_doi=10.1109/LWC.2018.2864758; citation_id=CR11"",""citation_journal_title=IEEE Communications Surveys Tutorials; citation_title=Bitcoin and beyond: A technical survey on decentralized digital currencies; citation_author=F Tschorsch, B Scheuermann; citation_volume=18; citation_issue=3; citation_publication_date=2016; citation_pages=2084-2123; citation_doi=10.1109/COMST.2016.2535718; citation_id=CR12"",""Sousa, J., Bessani, A., & Vukolic, M. (2018). A byzantine fault-tolerant ordering service for the hyperledger fabric blockchain platform. In 2018 48th annual IEEE/IFIP international conference on dependable systems and networks (DSN) (pp. 51–58).                      https://doi.org/10.1109/DSN.2018.00018                                        ."",""Cachin, C., & Vukolic, M. (2017). Blockchain consensus protocols in the wild.                      arXiv:abs/1707.01873                                        ."",""Zheng, Z., Xie, S., Dai, H., Chen, X., & Wang, H. (2017). An overview of blockchain technology: Architecture, consensus, and future trends. In 2017 IEEE international congress on big data (bigdata congress) (pp. 557–564).                      https://doi.org/10.1109/BigDataCongress.2017.85                                        ."",""citation_title=Ripple: Overview and outlook; citation_inbook_title=Trust and Trustworthy Computing; citation_publication_date=2015; citation_pages=163-180; citation_id=CR16; citation_author=F Armknecht; citation_author=GO Karame; citation_author=A Mandal; citation_author=F Youssef; citation_author=E Zenner; citation_publisher=Springer"",""Sedgewick, P. E., & de Lemos, R. (2018). Self-adaptation made easy with blockchains. In: Proceedings of the 13th international conference on software engineering for adaptive and self-managing systems, SEAMS ’18 (pp. 192–193). New York, NY: ACM.                      https://doi.org/10.1145/3194133.3194150                                        ."",""citation_title=Decentralized autonomous organizations = Blockchain + AI + IoT; citation_publication_date=2018; citation_id=CR18; citation_author=S Mohanty; citation_author=S Vyas; citation_publisher=Apress"",""Pahl, C., El Ioini, N., & Helmer, S. (2018). A decision framework for blockchain platforms for IoT and edge computing. In IoTBDS (pp. 105–113)."",""citation_journal_title=IEEE Access; citation_title=Decentralized consensus for edge-centric internet of things: A review, taxonomy, and research issues; citation_author=K Yeow, A Gani, RW Ahmad, JJPC Rodrigues, K Ko; citation_volume=6; citation_publication_date=2018; citation_pages=1513-1524; citation_doi=10.1109/ACCESS.2017.2779263; citation_id=CR20"",""Liao, C., Bao, S., Cheng, C., & Chen, K. (2017). On design issues and architectural styles for blockchain-driven iot services. In 2017 IEEE international conference on consumer electronics-Taiwan (ICCE-TW) (pp. 351–352).                      https://doi.org/10.1109/ICCE-China.2017.7991140                                        ."",""citation_journal_title=Future Generation Computer Systems; citation_title=Blockchain based hybrid network architecture for the smart city; citation_author=P Sharma; citation_volume=86; citation_publication_date=2018; citation_pages=650-655; citation_doi=10.1016/j.future.2018.04.060; citation_id=CR22"",""Vo, H. T., Kundu, A., & Mohania, M. K. (2018). Research directions in blockchain data management and analytics. In EDBT (pp. 445–448)."",""Yu, X. L., Xu, X., & Liu, B. (2017). EthDrive: A peer-to-peer data storage with provenance. In CAiSE-Forum-DC (pp. 25–32)."",""citation_title=A blockchain-based storage system for data analytics in the internet of things; citation_publication_date=2018; citation_id=CR25; citation_author=Q Xu; citation_author=KMM Aung; citation_author=Y Zhu; citation_author=KL Yong; citation_publisher=Springer"",""citation_title=Secure wireless automotive software updates using blockchains: A proof of concept; citation_inbook_title=Advanced Microsystems for Automotive Applications 2017; citation_publication_date=2018; citation_pages=137-149; citation_id=CR26; citation_author=M Steger; citation_author=A Dorri; citation_author=SS Kanhere; citation_author=K Römer; citation_author=R Jurdak; citation_author=M Karner; citation_publisher=Springer"",""Alvarenga, I. D., Rebello, G. A. F., & Duarte, O. C. M. B. (2018). Securing configuration management and migration of virtual network functions using blockchain. In NOMS 2018–2018 IEEE/IFIP network operations and management symposium (pp. 1–9).                      https://doi.org/10.1109/NOMS.2018.8406249                                        ."",""citation_journal_title=Sensors; citation_title=Patch transporter: Incentivized, decentralized software patch system for WSN and IoT environments; citation_author=J Lee; citation_volume=18; citation_issue=2; citation_publication_date=2018; citation_pages=574; citation_doi=10.3390/s18020574; citation_id=CR28"",""Leiba, O., Yitzchak, Y., Bitton, R., Nadler, A., & Shabtai, A. (2018). Incentivized delivery network of iot software updates based on trustless proof-of-distribution. In 2018 IEEE European symposium on security and privacy workshops (EuroSPW) (pp. 29–39)."",""Azzar, A., & Mottola, L. (2015). Virtual resources for the internet of things. In 2015 IEEE 2nd world forum on internet of things (WF-IoT) (pp. 245–250).                      https://doi.org/10.1109/WF-IoT.2015.7389060                                        ."",""citation_journal_title=IEEE Communications Magazine; citation_title=When mobile blockchain meets edge computing; citation_author=Z Xiong, Y Zhang, D Niyato, P Wang, Z Han; citation_volume=56; citation_issue=8; citation_publication_date=2018; citation_pages=33-39; citation_doi=10.1109/MCOM.2018.1701095; citation_id=CR31"",""Samaniego, M., & Deters, R. (2017). Internet of smart things-iost: Using blockchain and clips to make things autonomous. In 2017 IEEE international conference on cognitive computing (ICCC) (pp. 9–16).                      https://doi.org/10.1109/IEEE.ICCC.2017.9                                        ."",""citation_journal_title=Cognitive Hyperconnected Digital Transformation: Internet of Things Intelligence Evolution; citation_title=Internet of robotic things: Converging sensing/actuating, hypoconnectivity, artificial intelligence and iot platforms; citation_author=O Vermesan, A Bröring, E Tragos, M Serrano, D Bacciu, S Chessa; citation_volume=1; citation_publication_date=2017; citation_pages=1-35; citation_id=CR33"",""Ferrer, E. C. (2016). The blockchain: A new framework for robotic swarm systems.                      arXiv:abs/1608.00695                                        ."",""Golomb, T., Mirsky, Y., & Elovici, Y. (2018). Ciota: Collaborative iot anomaly detection via blockchain.                      arXiv:abs/1803.03807                                        ."",""Hashemi, S. H., Faghri, F., & Campbell, R. H. (2017). Decentralized user-centric access control using pubsub over blockchain.                      arXiv:abs/1710.00110                                        ."",""citation_journal_title=IEEE Internet of Things Journal; citation_title=Blockchain meets iot: An architecture for scalable access management in iot; citation_author=O Novo; citation_volume=5; citation_issue=2; citation_publication_date=2018; citation_pages=1184-1195; citation_doi=10.1109/JIOT.2018.2812239; citation_id=CR37"",""Zhang, Y., Kasahara, S., Shen, Y., Jiang, X., & Wan, J. (2018). Smart contract-based access control for the internet of things.                      arXiv:abs/1802.04410                                        ."",""Xu, R., Chen, Y., Blasch, E., & Chen, G. (2018). Blendcac: A blockchain-enabled decentralized capability-based access control for iots.                      arXiv:abs/1804.09267                                        ."",""Dukkipati, C., Zhang, Y., & Cheng, L. C. (2018). Decentralized, blockchain based access control framework for the heterogeneous internet of things. In Proceedings of the third ACM workshop on attribute-based access control, ABAC’18 (pp. 61–69). New York, NY: ACM.                      https://doi.org/10.1145/3180457.3180458                                        ."",""Atlam, H. F., Alenezi, A., Walters, R. J., Wills, G. B., & Daniel, J. (2017). Developing an adaptive risk-based access control model for the internet of things. In 2017 IEEE international conference on internet of things (iThings) and IEEE green computing and communications (GreenCom) and IEEE cyber, physical and social computing (CPSCom) and ieee smart data (SmartData) (pp. 655–661).                      https://doi.org/10.1109/iThings-GreenCom-CPSCom-SmartData.2017.103                                        ."",""citation_journal_title=International Journal of Advanced Computer Science and Applications; citation_title=Dynamic access control policy based on blockchain and machine learning for the internet of things; citation_author=A Outchakoucht, H ES-Samaali, J Philippe; citation_volume=8; citation_publication_date=2017; citation_pages=417-424; citation_doi=10.14569/IJACSA.2017.080757; citation_id=CR42"",""citation_journal_title=Future Generation Computer Systems; citation_title=Iot security: Review, blockchain solutions, and open challenges; citation_author=MA Khan, K Salah; citation_volume=82; citation_publication_date=2018; citation_pages=395-411; citation_doi=10.1016/j.future.2017.11.022; citation_id=CR43"",""citation_journal_title=IEEE Communications Magazine; citation_title=Distblocknet: A distributed blockchains-based secure sdn architecture for iot networks; citation_author=PK Sharma, S Singh, Y Jeong, JH Park; citation_volume=55; citation_issue=9; citation_publication_date=2017; citation_pages=78-85; citation_doi=10.1109/MCOM.2017.1700041; citation_id=CR44"",""citation_journal_title=Security and Communication Networks; citation_title=A survey of how to use blockchain to secure internet of things and the stalker attack; citation_author=E Ferreira Jesus, RLV Chicarino, C Albuquerque, A Rocha; citation_volume=2018; citation_publication_date=2018; citation_pages=1-27; citation_doi=10.1155/2018/9675050; citation_id=CR45"",""Xia, Q., Sifah, E. B., Smahi, A., Amofa, S., & Zhang, X. (2017). Bbds: Blockchain-based data sharing for electronic medical records in cloud environments. Information, 8(2).                      https://doi.org/10.3390/info8020044                                        .                      http://www.mdpi.com/2078-2489/8/2/44                                        ."",""citation_title=Medibchain: A blockchain based privacy preserving platform for healthcare data; citation_inbook_title=Security, Privacy, and Anonymity in Computation, Communication, and Storage; citation_publication_date=2017; citation_pages=534-543; citation_id=CR47; citation_author=A Al Omar; citation_author=MS Rahman; citation_author=A Basu; citation_author=S Kiyomoto; citation_publisher=Springer"",""Angeletti, F., Chatzigiannakis, I., & Vitaletti, A. (2017). Privacy preserving data management in recruiting participants for digital clinical trials (pp. 7–12)."",""Dorri, A., Kanhere, S. S., Jurdak, R., & Gauravaram, P. (2017). Blockchain for iot security and privacy: The case study of a smart home. In 2017 IEEE international conference on pervasive computing and communications workshops (PerCom workshops) (pp. 618–623).                      https://doi.org/10.1109/PERCOMW.2017.7917634                                        ."",""citation_title=Ghost-safe-guarding home iot environments with personalised real-time risk control; citation_inbook_title=Security in Computer and Information Sciences; citation_publication_date=2018; citation_pages=68-78; citation_id=CR50; citation_author=A Collen; citation_author=NA Nijdam; citation_author=J Augusto-Gonzalez; citation_author=SK Katsikas; citation_author=KM Giannoutakis; citation_author=G Spathoulas; citation_author=E Gelenbe; citation_author=K Votis; citation_author=D Tzovaras; citation_author=N Ghavami; citation_author=M Volkamer; citation_author=P Haller; citation_author=A Sánchez; citation_author=M Dimas; citation_publisher=Springer"",""citation_journal_title=IEEE Network; citation_title=A blockchain-based privacy-preserving payment mechanism for vehicle-to-grid networks; citation_author=F Gao, L Zhu, M Shen, K Sharif, Z Wan, K Ren; citation_volume=99; citation_publication_date=2018; citation_pages=1-9; citation_id=CR51"",""citation_journal_title=IEEE Communications Magazine; citation_title=Blockchain: A distributed solution to automotive security and privacy; citation_author=A Dorri, M Steger, SS Kanhere, R Jurdak; citation_volume=55; citation_issue=12; citation_publication_date=2017; citation_pages=119-125; citation_doi=10.1109/MCOM.2017.1700879; citation_id=CR52"",""Mylrea, M., & Gourisetti, S. N. G. (2017). Blockchain for smart grid resilience: Exchanging distributed energy at speed, scale and security. In 2017 resilience week (RWS) (pp. 18–23).                      https://doi.org/10.1109/RWEEK.2017.8088642                                        ."",""SDxCentral: Oracle builds a blockchain cloud service based on hyperledger. (2018).                      https://www.sdxcentral.com/articles/news/oracle-blockchain-cloud-service-goes-public/2018/07/?utm_source=SDxCentral.com+Mailing+List&utm_campaign=8c5232b1c3-EMAIL_CAMPAIGN_2018_07_16&utm_medium=email&utm_term=0_c2b6e504a2-8c5232b1c3-81947645                                        . Accessed on 16 October 2018."",""TechTarget: Cisco eyes blockchain messaging for better security. (2018).                      https://searchunifiedcommunications.techtarget.com/news/252439024/Cisco-eyes-blockchain-messaging-for-better-security?track=NL-1817&ad=920345&src=920345&asrc=EM_NLN_93606076&utm_medium=EM&utm_source=NLN&utm_campaign=20180416_Cisco%20looks%20at%20blockchain%20to%20secure%20group%20messaging                                        . Accessed on 16 October 2018."",""SDxCentral: Verizon to use ksi blockchain technology developed for estonia. (2018).                      https://www.sdxcentral.com/articles/news/verizon-use-ksi-blockchain-technology-developed-estonia/2018/02/?utm_source=SDxCentral.com+Mailing+List&utm_campaign=e04f4588f7-SDxCentral+Newsletter+2018-02-13&utm_medium=email&utm_term=0_c2b6e504a2-e04f4588f7-81947645                                        . Accessed on 16 October 2018."",""SDxCentral: Google is working on blockchain technology, too. (2018).                      https://www.sdxcentral.com/articles/news/google-working-blockchain-technology/2018/03/?utm_source=SDxCentral.com+Mailing+List&utm_campaign=ab57972ecd-SDxCentral+Newsletter+2018-03-23&utm_medium=email&utm_term=0_c2b6e504a2-ab57972ecd-81947645                                        . Accessed on 16 October 2018."",""Drops, I.                      https://icodrops.com                                        . Accessed on 5 December 2018.""
""citation_journal_title"",""Wireless Personal Communications""
""language"",""en""
""citation_cover_date"",""2019/05/01""
""og:description"",""Blockchain (BC) represents a distributed ledger technology that has been utilized for providing security and privacy in distributed networks. This makes it applicable to the distributed nature of IoT, which still suffers from privacy and security vulnerabilities. However, the core BC technology is computationally expensive and commonly involves high bandwidth overhead and delays not suitable for IoT related scenarios. In order to foster the synergy between BC and IoT, recent research advancements have specifically focused on developing novel BC approaches that are tailored to the requirements and needs of the specific IoT use cases. The paper elaborates the BC–IoT related issues and provides a comprehensive survey of the current literature and relevant initiated deployments. The paper also identifies the key research and development challenges and discusses the possible aspects for future research.""
""prism.issn"",""1572-834X""
""citation_author_email"",""valentin@feit.ukim.edu.mk"",""jovankaramac@yahoo.com"",""vladimir@feit.ukim.edu.mk"",""liljana@feit.ukim.edu.mk""
""twitter:image:alt"",""Content cover image""
""prism.number"",""1""
""citation_issn"",""1572-834X""
""citation_language"",""en""
""dc:title"",""Blockchain Paradigm and Internet of Things | SpringerLink""
""Content-Encoding"",""UTF-8""
""citation_pdf_url"",""https://link.springer.com/content/pdf/10.1007/s11277-019-06270-9.pdf""
""citation_lastpage"",""235""
""DOI"",""10.1007/s11277-019-06270-9""
""citation_journal_abbrev"",""Wireless Pers Commun""
""prism.rightsAgent"",""journalpermissions@springernature.com""
""citation_author"",""Valentin Rakovic"",""Jovan Karamachoski"",""Vladimir Atanasovski"",""Liljana Gavrilovska""
""resourceName"",""casa""
""dc.date"",""2019-03-21""
""citation_springer_api_url"",""http://api.springer.com/metadata/pam?q=doi:10.1007/s11277-019-06270-9&api_key=""
""citation_issue"",""1""
""prism.volume"",""106""
""prism.publicationName"",""Wireless Personal Communications""
""citation_doi"",""10.1007/s11277-019-06270-9""
""dc.title"",""Blockchain Paradigm and Internet of Things""
""prism.url"",""https://link.springer.com/article/10.1007/s11277-019-06270-9""
""citation_volume"",""106""
""dc.language"",""En""
""Content-Language"",""en""
""format-detection"",""telephone=no""
""citation_publication_date"",""2019/05""
""prism.endingPage"",""235""
""citation_title"",""Blockchain Paradigm and Internet of Things""
""citation_author_institution"",""Faculty of Electrical Engineering and Information Technologies, Ss Cyril and Methodius University in Skopje, Skopje, Macedonia"",""Faculty of Machine Intelligence and Robotics, University for Information Science and Technology - St. Paul the Apostle, Ohrid, Macedonia"",""Faculty of Electrical Engineering and Information Technologies, Ss Cyril and Methodius University in Skopje, Skopje, Macedonia"",""Faculty of Electrical Engineering and Information Technologies, Ss Cyril and Methodius University in Skopje, Skopje, Macedonia""
""access"",""No""
""citation_publisher"",""Springer US""
""applicable-device"",""pc,mobile""
""dc.format"",""text/html""
""description"",""Blockchain (BC) represents a distributed ledger technology that has been utilized for providing security and privacy in distributed networks. This makes it""
""title"",""Blockchain Paradigm and Internet of Things | SpringerLink""
""citation_online_date"",""2019/03/21""
""twitter:site"",""@SpringerLink""
""dc.source"",""Wireless Personal Communications 2019 106:1""
""dc.type"",""OriginalPaper""
""dc.copyright"",""2019 Springer Science+Business Media, LLC, part of Springer Nature""
""dc.creator"",""Valentin Rakovic"",""Jovan Karamachoski"",""Vladimir Atanasovski"",""Liljana Gavrilovska""
""citation_fulltext_html_url"",""https://link.springer.com/article/10.1007/s11277-019-06270-9""
""prism.publicationDate"",""2019-03-21""
""Content-Type"",""text/html; charset=UTF-8""
""journal_id"",""11277""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""dc.description"",""Blockchain (BC) represents a distributed ledger technology that has been utilized for providing security and privacy in distributed networks. This makes it applicable to the distributed nature of IoT, which still suffers from privacy and security vulnerabilities. However, the core BC technology is computationally expensive and commonly involves high bandwidth overhead and delays not suitable for IoT related scenarios. In order to foster the synergy between BC and IoT, recent research advancements have specifically focused on developing novel BC approaches that are tailored to the requirements and needs of the specific IoT use cases. The paper elaborates the BC–IoT related issues and provides a comprehensive survey of the current literature and relevant initiated deployments. The paper also identifies the key research and development challenges and discusses the possible aspects for future research.""
""og:type"",""article""
""citation_article_type"",""Article""
""og:title"",""Blockchain Paradigm and Internet of Things""
""prism.doi"",""doi:10.1007/s11277-019-06270-9""
""X-UA-Compatible"",""IE=edge""
""citation_firstpage"",""219""
""prism.startingPage"",""219""
""viewport"",""width=device-width, initial-scale=1""
""dc.rightsAgent"",""journalpermissions@springernature.com""
""prism.section"",""OriginalPaper""
""dc.identifier"",""doi:10.1007/s11277-019-06270-9""
""dc.subject"",""Communications Engineering, Networks"",""Signal,Image and Speech Processing"",""Computer Communication Networks""
""og:url"",""https://link.springer.com/article/10.1007/s11277-019-06270-9""
""prism.copyright"",""2019 Springer Science+Business Media, LLC, part of Springer Nature""
";https://scholar.google.com/scholar?start=70&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093448-168;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Challenges beyond blockchain: scaling, oracles and privacy preserving;S Kruglik, K Nazirkhanova… ; 2019 XVI International …, 2019  ieeexplore.ieee.org;;"The blockchain technology is one of the most actively investigated areas in applied 
cryptography, but its widespread adoption is being held back by some technical drawbacks. 
In this paper, we make a review of the most significant issues and possible approaches to …";Cité 3 fois;Les 2 versions;null;;;;
1619093506-412;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;A Collaborative DDoS Defense Platform Based on Blockchain Technology;LY Yeh, JL Huang, TY Yen… ; 2019 Twelfth International …, 2019  ieeexplore.ieee.org;;"… Oracle: A special node on blockchain that listens to events which are emitted from smart contract

and is used to encrypt and decrypt data as well … The tamper-proof log for the decryption keys

selected by Oracle for the duplicated files are also recorded in blockchain …";Cité 2 fois;Les 4 versions;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/9036732/9049507/09049590.pdf?casa_token=3PGiX6ghKv0AAAAA:UWquG8PL4g-l4TuwDp72iG-Vp_uBfYr_sP1KwZNdwhvJYlbe-NhV6I-hp7e54eUKYmocj0zjODM;;"""og:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""twitter:title"",""A Collaborative DDoS Defense Platform Based on Blockchain Technology""
""twitter:card"",""summary""
""Description"",""In this paper, we propose a consortium blockchainbased system sharing malicious IP to prevent further attacks happening among other hosts. In our scheme, every ""
""og:title"",""A Collaborative DDoS Defense Platform Based on Blockchain Technology""
""resourceName"",""09049590.pdf""
""language"",""en""
""title"",""A Collaborative DDoS Defense Platform Based on Blockchain Technology | IEEE Conference Publication | IEEE Xplore""
""og:description"",""In this paper, we propose a consortium blockchainbased system sharing malicious IP to prevent further attacks happening among other hosts. In our scheme, every security operation center (SOC) serving as a blockchain-node uploads some suspicious IPs to find the potential attackers' IPs. A smart contract is responsible for comparing the loaded IPs and the existing ones without human interference. If IPs in different lists are matched with certain degree, this system will respond by giving the whole list of malicious IP. By means of these steps, shares of IP lists are achieved and attacks are prevented in advance. Besides, when uploading and sharing, we utilize elliptic curve cryptography to ensure data confidentiality and integrity.""
""twitter:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-UA-Compatible"",""IE=Edge""
""viewport"",""width=device-width, initial-scale=1.0""
""dc:title"",""A Collaborative DDoS Defense Platform Based on Blockchain Technology | IEEE Conference Publication | IEEE Xplore""
""twitter:description"",""In this paper, we propose a consortium blockchainbased system sharing malicious IP to prevent further attacks happening among other hosts. In our scheme, every security operation center (SOC) serving as a blockchain-node uploads some suspicious IPs to find the potential attackers' IPs. A smart contract is responsible for comparing the loaded IPs and the existing ones without human interference. If IPs in different lists are matched with certain degree, this system will respond by giving the whole list of malicious IP. By means of these steps, shares of IP lists are achieved and attacks are prevented in advance. Besides, when uploading and sharing, we utilize elliptic curve cryptography to ensure data confidentiality and integrity.""
""Content-Encoding"",""UTF-8""
""Content-Type-Hint"",""text/html; charset=utf-8""
""Content-Length"",""40105""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=250&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093534-532;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;[LIVRE][B] Live from Crypto Valley;M Lewrick, C Giorgio ;2019 books.google.com;;"… Page 10. XI The most important icons Assessment Bitcoin (cryptocurrency) Blockchain Business

Ecosystem (design) Community DLT (decentralized system) Law/Regulation Internet (centralized

system) Interview Investment & Value Concept & Idea Crypto Roadmap Page 11 …";Cité 6 fois;Les 3 versions;null;;;;https://scholar.google.com/scholar?start=370&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093506-418;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Blockchain jako moderní informa?ní technologie;S Teslenko ;2019 dk.upce.cz;;"… 34 4.1.2 The danger for smart contacts – The Oracle Protocol … that just

a few years ago was unimaginable. A cryptocurrency is the first application

of the Blockchain technology, that was invented and …";;;[PDF] upce.cz;https://dk.upce.cz/bitstream/handle/10195/73454/TeslenkoS_BlockchainTechnology_MI_2019.pdf?sequence=1&isAllowed=y;;"""date"",""2019-04-30T21:33:19Z""
""pdf:PDFVersion"",""1.6""
""xmp:CreatorTool"",""Acrobat PDFMaker 19 для Word""
""pdf:docinfo:title"",""Blockchain as modern information technology""
""Company"",""FES UPa""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""závěrečné práce""
""language"",""en""
""dc:format"",""application/pdf; version=1.6""
""pdf:docinfo:creator_tool"",""Acrobat PDFMaker 19 для Word""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""Blockchain as modern information technology""
""xmp:CreateDate"",""2019-04-30T23:30:13Z""
""modified"",""2019-04-30T21:33:19Z""
""pdf:docinfo:custom:SourceModified"",""D:20190430212938""
""cp:subject"",""závěrečné práce""
""pdf:docinfo:subject"",""závěrečné práce""
""pdf:hasMarkedContent"",""true""
""xmp:ModifyDate"",""2019-04-30T23:33:19Z""
""pdf:docinfo:creator"",""Teslenko Serhii""
""meta:author"",""Teslenko Serhii""
""meta:creation-date"",""2019-04-30T21:30:13Z""
""created"",""2019-04-30T21:30:13Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-04-30T21:30:13Z""
""resourceName"",""TeslenkoS_BlockchainTechnology_MI_2019.pdf""
""pdf:docinfo:custom:Comments"",""""
""Author"",""Teslenko Serhii""
""producer"",""Adobe PDF Library 19.10.131""
""pdf:docinfo:producer"",""Adobe PDF Library 19.10.131""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""dc:description"",""závěrečné práce""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""Teslenko Serhii""
""description"",""závěrečné práce""
""dcterms:created"",""2019-04-30T21:30:13Z""
""Last-Modified"",""2019-04-30T21:33:19Z""
""dcterms:modified"",""2019-04-30T21:33:19Z""
""title"",""Blockchain as modern information technology""
""xmpMM:DocumentID"",""uuid:77ee9cdf-e326-458a-acba-951ce2586fd1""
""Last-Save-Date"",""2019-04-30T21:33:19Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2019-04-30T21:33:19Z""
""meta:save-date"",""2019-04-30T21:33:19Z""
""Content-Length"",""2343873""
""Content-Type"",""application/pdf""
""xmp:MetadataDate"",""2019-04-30T23:33:19Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Teslenko Serhii""
""dc:language"",""EN-US""
""pdf:producer"",""Adobe PDF Library 19.10.131""
""dc:subject"",""""
""Comments"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""52""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""179"",""3"",""5"",""1134"",""342"",""1036"",""6496"",""2103"",""584"",""2717"",""608"",""1606"",""1639"",""2524"",""2754"",""2200"",""1824"",""2343"",""2281"",""531"",""2917"",""1132"",""2570"",""2346"",""2569"",""2617"",""1549"",""1445"",""2390"",""2460"",""635"",""2334"",""940"",""2613"",""2611"",""2876"",""847"",""2328"",""413"",""2117"",""2219"",""2353"",""1741"",""1201"",""722"",""1703"",""881"",""1045"",""1889"",""2980"",""2646"",""1710""
""access_permission:extract_content"",""true""
""pdf:docinfo:custom:Company"",""FES UPa""
""access_permission:can_print"",""true""
""SourceModified"",""D:20190430212938""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-04-30T21:30:13Z""
";https://scholar.google.com/scholar?start=250&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093452-185;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Performance analytical comparison of blockchain-as-a-service (baas) platforms;MMH Onik, MH Miraz ; International Conference for Emerging …, 2019  Springer;;"… analytical comparison of Blockchain-as-a-Service (BaaS) platforms- Mainly those provided by

Microsoft, Amazon, Hewlett Packard (HP), Oracle and SAP … In fact, blockchain technology was

first introduced in 2008 as a core technology for a cryptocurrency (ie Bitcoin) [1 …";Cité 9 fois;Les 8 versions;[PDF] arxiv.org;https://arxiv.org/pdf/1909.10593;;"""date"",""2019-09-02T03:48:59Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.5""
""xmp:CreatorTool"",""MicrosoftÂŽ Word 2016""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dc:creator"",""Markus Richter""
""language"",""en""
""dcterms:created"",""2019-09-02T03:48:59Z""
""Last-Modified"",""2019-09-02T03:48:59Z""
""dcterms:modified"",""2019-09-02T03:48:59Z""
""dc:format"",""application/pdf; version=1.5""
""Last-Save-Date"",""2019-09-02T03:48:59Z""
""pdf:docinfo:creator_tool"",""MicrosoftÂŽ Word 2016""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2019-09-02T03:48:59Z""
""meta:save-date"",""2019-09-02T03:48:59Z""
""pdf:encrypted"",""false""
""modified"",""2019-09-02T03:48:59Z""
""Content-Length"",""589159""
""pdf:hasMarkedContent"",""true""
""Content-Type"",""application/pdf""
""pdf:docinfo:creator"",""Markus Richter""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Markus Richter""
""dc:language"",""en-GB""
""meta:author"",""Markus Richter""
""meta:creation-date"",""2019-09-02T03:48:59Z""
""created"",""2019-09-02T03:48:59Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""17""
""Creation-Date"",""2019-09-02T03:48:59Z""
""resourceName"",""1909.10593""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""2816"",""3285"",""3197"",""922"",""1393"",""3021"",""2029"",""919"",""1970"",""1776"",""843"",""1653"",""3171"",""3136"",""3406"",""3631"",""2239""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""Author"",""Markus Richter""
""producer"",""MicrosoftÂŽ Word 2016""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""MicrosoftÂŽ Word 2016""
""pdf:docinfo:created"",""2019-09-02T03:48:59Z""
";https://scholar.google.com/scholar?start=20&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093494-363;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;STRENGTHENING THE LINKS: HOW BLOCKCHAIN CAN HELP MANAGE SUPPLY CHAIN RISK;J Hintze ; Risk Management, 2019  search.proquest.com;;"… Food producer Certified Origins, for exam- ple, has implemented Oracle's blockchain solution

to ensure that counterfeit olive oil is not introduced into a supply chain that stretches from the

farmers growing the olives to companies distributing the bottled oil …";;null;null;;;;https://scholar.google.com/scholar?start=200&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093513-443;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;New instant confirmation mechanism based on interactive incontestable signature in consortium blockchain;Y Zhu, K Riad, R Guo, G Gan, R Feng ; Frontiers of Computer Science, 2019  Springer;;"… This ledger is nec- essary to prevent double-spending, which is a key technical challenge

in designing any cryptocurrency system. The basic structure of a blockchain, which consists

of a series of blocks connected in a hash chain, is shown in Fig …";Cité 3 fois;Les 5 versions;[PDF] springer.com;https://idp.springer.com/authorize/casa?redirect_uri=https://link.springer.com/content/pdf/10.1007/s11704-017-6338-8.pdf&casa_token=FzIdrKCmiD8AAAAA:6uLng4IePWT3iF95GYAXSHLhC9qG8ZMZcwRUA1xjYOXbOEr279u6DcNY4dwGYoh3dNPWWlyF0QY5yNg;;;https://scholar.google.com/scholar?start=280&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093532-524;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Cdag: A serialized blockdag for permissioned blockchain;H Gupta, D Janakiram ; arXiv preprint arXiv:1910.08547, 2019  arxiv.org;;"… as an easy to understand and maintain structure, with more straightforward conflict resolution

technique, which makes it desirable for blockchain systems … Such nodes lacking behind need

to poll the trusted oracles present in the network to reinitialize the state of their barrier …";Cité 1 fois;Les 3 versions;[PDF] arxiv.org;https://arxiv.org/pdf/1910.08547;;"""date"",""2019-10-25T00:48:44Z""
""pdf:PDFVersion"",""1.4""
""pdf:docinfo:title"",""CDAG: A Serialized blockDAG for Permissioned Blockchain""
""xmp:CreatorTool"",""LaTeX with acmart 2018/12/16 v1.57 Typesetting articles for the Association for Computing Machinery and hyperref 2016/06/24 v6.83q Hypertext links for LaTeX""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.4""
""pdf:docinfo:creator_tool"",""LaTeX with acmart 2018/12/16 v1.57 Typesetting articles for the Association for Computing Machinery and hyperref 2016/06/24 v6.83q Hypertext links for LaTeX""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""CDAG: A Serialized blockDAG for Permissioned Blockchain""
""xmp:CreateDate"",""2019-10-24T20:48:44Z""
""modified"",""2019-10-25T00:48:44Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""xmp:ModifyDate"",""2019-10-24T20:48:44Z""
""pdf:docinfo:creator"",""Himanshu Gupta and Dharanipragada Janakiram""
""meta:author"",""""
""meta:creation-date"",""2019-10-25T00:48:44Z""
""created"",""2019-10-25T00:48:44Z""
""xmp:About"",""uuid:becbdadd-2edd-11f5-0000-cff1a536a6fb""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-10-25T00:48:44Z""
""resourceName"",""1910.08547""
""Author"",""""
""producer"",""dvips + GPL Ghostscript GIT PRERELEASE 9.22""
""pdf:docinfo:producer"",""dvips + GPL Ghostscript GIT PRERELEASE 9.22""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""2"",""0"",""0"",""0"",""0"",""12"",""3""
""Keywords"",""CDAG, blockchain, blockDAG, distributed time barrier, bucketing of transactions""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2019-10-25T00:48:44Z""
""Last-Modified"",""2019-10-25T00:48:44Z""
""dcterms:modified"",""2019-10-25T00:48:44Z""
""title"",""CDAG: A Serialized blockDAG for Permissioned Blockchain""
""xmpMM:DocumentID"",""uuid:becbdadd-2edd-11f5-0000-cff1a536a6fb""
""Last-Save-Date"",""2019-10-25T00:48:44Z""
""pdf:docinfo:keywords"",""CDAG, blockchain, blockDAG, distributed time barrier, bucketing of transactions""
""pdf:docinfo:modified"",""2019-10-25T00:48:44Z""
""meta:save-date"",""2019-10-25T00:48:44Z""
""Content-Length"",""599265""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:language"",""en""
""dc:subject"",""CDAG, blockchain, blockDAG, distributed time barrier, bucketing of transactions""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""13""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""4271"",""4802"",""4790"",""4166"",""4005"",""3845"",""4659"",""4785"",""4499"",""2352"",""4632"",""4574"",""849""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""meta:keyword"",""CDAG, blockchain, blockDAG, distributed time barrier, bucketing of transactions""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-10-25T00:48:44Z""
";https://scholar.google.com/scholar?start=360&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093543-574;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;[CITATION][C] (Draft) A Taxonomic Approach to Understanding Emerging Blockchain Identity Management Systems;L Lesavre ;2019;;null;Autres articles;;null;;;;https://scholar.google.com/scholar?start=410&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093518-470;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;[HTML][HTML] Toward privacy-preserving shared storage in untrusted blockchain P2P networks;S Rahmadika, KH Rhee ; Wireless Communications and Mobile …, 2019  hindawi.com;;"… In the decentralized healthcare system model, the patient and the providers are on the same

blockchain network … 3.3. Ring Confidential Transaction of PHI. Ring confidential transaction

(RingCT) is used in Monero cryptocurrency [16] in order to improve the privacy of the users …";Cité 13 fois;Les 6 versions;[HTML] hindawi.com;https://www.hindawi.com/journals/wcmc/2019/6219868/abs/;;"""dc.publisher"",""Hindawi""
""og:image"",""https://images.hindawi.com/journals/wcmc/wcmc.banner.jpg""
""og:image:width"",""600""
""twitter:card"",""summary_large_image""
""citation_journal_title"",""Wireless Communications and Mobile Computing""
""language"",""en""
""og:description"",""The shared storage is essential in the decentralized system. A straightforward storage model with guaranteed privacy protection on the peer-to-peer network is a challenge in the blockchain technology. The decentralized storage system should provide the privacy for the parties since it contains numerous data that are sensitive and dangerous if misused by maliciously. In this paper, we present a model for shared storage on a blockchain network which allows the authorized parties to access the data on storage without having to reveal their identity. Ring signatures combined with several protocols are implemented to disguise the signer identity thereby the observer is unlikely to determine the identity of the parties. We apply our proposed scheme in the healthcare domain, namely, decentralized personal health information (PHI). In addition, we present a dilemma to improve performance in a decentralized system.""
""prism.issn"",""1530-8669""
""citation_issn"",""1530-8669""
""dc:title"",""Toward Privacy-Preserving Shared Storage in Untrusted Blockchain P2P Networks""
""Content-Encoding"",""UTF-8""
""citation_pdf_url"",""https://downloads.hindawi.com/journals/wcmc/2019/6219868.pdf""
""robots"",""index""
""google-site-verification"",""AxEuDsL7vXGOxRe53-uFhOk2ODN0bbXMeuBy6Pfq4ww""
""citation_author"",""Rahmadika, Sandi"",""Rhee, Kyung-Hyune""
""dc.date"",""2019/05/16""
""prism.volume"",""2019""
""citation_doi"",""https://doi.org/10.1155/2019/6219868""
""prism.publicationName"",""Wireless Communications and Mobile Computing""
""dc.title"",""Toward Privacy-Preserving Shared Storage in Untrusted Blockchain P2P Networks""
""Author"",""Hindawi""
""citation_volume"",""2019""
""dc.language"",""en""
""Content-Language"",""en""
""authors"",""Sandi Rahmadika | Kyung-Hyune Rhee""
""citation_title"",""Toward Privacy-Preserving Shared Storage in Untrusted Blockchain P2P Networks""
""citation_year"",""2019""
""citation_publisher"",""Hindawi""
""dc.format"",""text/html""
""description"",""The shared storage is essential in the decentralized system. A straightforward storage model with guaranteed privacy protection on the peer-to-peer network is a challenge in the blockchain technology. The decentralized storage system should provide the privacy for the parties since it contains numerous data that are sensitive and dangerous if misused by maliciously. In this paper, we present a model for shared storage on a blockchain network which allows the authorized parties to access the data on storage without having to reveal their identity. Ring signatures combined with several protocols are implemented to disguise the signer identity thereby the observer is unlikely to determine the identity of the parties. We apply our proposed scheme in the healthcare domain, namely, decentralized personal health information (PHI). In addition, we present a dilemma to improve performance in a decentralized system.""
""og:image:type"",""image/jpeg""
""citation_date"",""2019/05/16""
""title"",""Toward Privacy-Preserving Shared Storage in Untrusted Blockchain P2P Networks"",""Toward Privacy-Preserving Shared Storage in Untrusted Blockchain P2P Networks""
""twitter:image"",""https://images.hindawi.com/journals/wcmc/wcmc.banner.jpg""
""citation_online_date"",""2019/05/16""
""twitter:site"",""website""
""dc.type"",""Research Article""
""dc.source"",""Wireless Communications and Mobile Computing""
""dc.creator"",""Rahmadika, Sandi"",""Rhee, Kyung-Hyune""
""citation_fulltext_html_url"",""https://www.hindawi.com/journals/wcmc/2019/6219868/""
""prism.publicationDate"",""2019/05/16""
""Content-Length"",""1692881""
""citation_xml_url"",""https://downloads.hindawi.com/journals/wcmc/2019/6219868.xml""
""Content-Type"",""text/html; charset=UTF-8""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""og:type"",""website""
""twitter:title"",""Toward Privacy-Preserving Shared Storage in Untrusted Blockchain P2P Networks""
""dc.description"",""The shared storage is essential in the decentralized system. A straightforward storage model with guaranteed privacy protection on the peer-to-peer network is a challenge in the blockchain technology. The decentralized storage system should provide the privacy for the parties since it contains numerous data that are sensitive and dangerous if misused by maliciously. In this paper, we present a model for shared storage on a blockchain network which allows the authorized parties to access the data on storage without having to reveal their identity. Ring signatures combined with several protocols are implemented to disguise the signer identity thereby the observer is unlikely to determine the identity of the parties. We apply our proposed scheme in the healthcare domain, namely, decentralized personal health information (PHI). In addition, we present a dilemma to improve performance in a decentralized system.""
""og:title"",""Toward Privacy-Preserving Shared Storage in Untrusted Blockchain P2P Networks""
""citation_abstract"",""The shared storage is essential in the decentralized system. A straightforward storage model with guaranteed privacy protection on the peer-to-peer network is a challenge in the blockchain technology. The decentralized storage system should provide the privacy for the parties since it contains numerous data that are sensitive and dangerous if misused by maliciously. In this paper, we present a model for shared storage on a blockchain network which allows the authorized parties to access the data on storage without having to reveal their identity. Ring signatures combined with several protocols are implemented to disguise the signer identity thereby the observer is unlikely to determine the identity of the parties. We apply our proposed scheme in the healthcare domain, namely, decentralized personal health information (PHI). In addition, we present a dilemma to improve performance in a decentralized system.""
""og:image:height"",""315""
""prism.doi"",""https://doi.org/10.1155/2019/6219868""
""dcterms.issued"",""2019/05/16""
""viewport"",""width=device-width, initial-scale=1""
""twitter:description"",""The shared storage is essential in the decentralized system. A straightforward storage model with guaranteed privacy protection on the peer-to-peer network is a challenge in the blockchain technology. The decentralized storage system should provide the privacy for the parties since it contains numerous data that are sensitive and dangerous if misused by maliciously. In this paper, we present a model for shared storage on a blockchain network which allows the authorized parties to access the data on storage without having to reveal their identity. Ring signatures combined with several protocols are implemented to disguise the signer identity thereby the observer is unlikely to determine the identity of the parties. We apply our proposed scheme in the healthcare domain, namely, decentralized personal health information (PHI). In addition, we present a dilemma to improve performance in a decentralized system.""
""dc.identifier"",""https://doi.org/10.1155/2019/6219868""
""prism.section"",""Research Article""
""og:url"",""https://www.hindawi.com/journals/wcmc/2019/6219868/""
";https://scholar.google.com/scholar?start=300&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093450-173;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Blockchain abstract data type;E Anceaume, A Del Pozzo, R Ludinard… ; The 31st ACM …, 2019  dl.acm.org;;"… 4.3 BT-ADT augmented with ? Oracles We augment the BT-ADT with ? oracles and we analyze …

we define a refinement of the append(b?) operation of the BT-ADT with the oracle operations

as … block is consumed ie block b? tknh is appended to the block h in the blockchain f (bt …";Cité 17 fois;Les 13 versions;[PDF] acm.org;https://dl.acm.org/doi/pdf/10.1145/3323165.3323183?casa_token=4ri2VeaFB90AAAAA:tQorpAbRwfA9iIWaIzsMGlsa6gQkWayDCjLCxn_rp2ji_MhKR2hPer6zqKU95__1aZEG_MAOV78;;;https://scholar.google.com/scholar?start=10&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093476-285;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Traceable monero: Anonymous cryptocurrency with enhanced accountability;Y Li, G Yang, W Susilo, Y Yu, MH Au… ; IEEE Transactions on …, 2019  ieeexplore.ieee.org;;"… The blockchain is a continuously growing database, which consists of blocks and records the

valid transactions in the P2P network … negl(?) where all oracles are defined as before, Asi ? A

and Asi ? G for i ? {0, 1} and Trace oracle is defined as follows. • Trace(tx, ?)12 …";Cité 14 fois;MH Au;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/8858/4358699/08685178.pdf?casa_token=2vsr84mZLZ4AAAAA:dEkMhEFjiZNV7-ddNN23qIW0QqcRubQgq3c7Olyjhaf6UxuU5O0XwT1C6Yl7WkhWAXjl5xfA5-8;;"""og:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""twitter:title"",""Traceable Monero: Anonymous Cryptocurrency with Enhanced Accountability""
""twitter:card"",""summary""
""Description"",""Monero provides a high level of anonymity for both users and their transactions. However, many criminal activities might be committed with the protection of ano""
""og:title"",""Traceable Monero: Anonymous Cryptocurrency with Enhanced Accountability""
""resourceName"",""08685178.pdf""
""language"",""en""
""title"",""Traceable Monero: Anonymous Cryptocurrency with Enhanced Accountability | IEEE Journals & Magazine | IEEE Xplore""
""og:description"",""Monero provides a high level of anonymity for both users and their transactions. However, many criminal activities might be committed with the protection of anonymity in cryptocurrency transactions. Thus, user accountability (or traceability) is also important in Monero transactions, which is unfortunately lacking in the current literature. In this paper, we fill this gap by introducing a new cryptocurrency named  <italic xmlns:mml=""""http://www.w3.org/1998/Math/MathML"""" xmlns:xlink=""""http://www.w3.org/1999/xlink"""">Traceable Monero</italic>  to balance the user anonymity and accountability. Our framework relies on a tracing authority, but is optimistic, in that it is only involved when investigations in certain transactions are required. We formalize the system model and security model of Traceable Monero. We present a detailed construction of Traceable Monero by overlaying Monero with two types of tracing mechanisms, tracing the one-time addresses with money flows and tracing the long-term addresses. We prove the security of Traceable Monero and implement a prototype of the system, which demonstrates that Traceable Monero incurs merely a very small overhead in generating and verifying a transaction compared to Monero transactions.""
""twitter:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-UA-Compatible"",""IE=Edge""
""viewport"",""width=device-width, initial-scale=1.0""
""dc:title"",""Traceable Monero: Anonymous Cryptocurrency with Enhanced Accountability | IEEE Journals & Magazine | IEEE Xplore""
""twitter:description"",""Monero provides a high level of anonymity for both users and their transactions. However, many criminal activities might be committed with the protection of anonymity in cryptocurrency transactions. Thus, user accountability (or traceability) is also important in Monero transactions, which is unfortunately lacking in the current literature. In this paper, we fill this gap by introducing a new cryptocurrency named  <italic xmlns:mml=""""http://www.w3.org/1998/Math/MathML"""" xmlns:xlink=""""http://www.w3.org/1999/xlink"""">Traceable Monero</italic>  to balance the user anonymity and accountability. Our framework relies on a tracing authority, but is optimistic, in that it is only involved when investigations in certain transactions are required. We formalize the system model and security model of Traceable Monero. We present a detailed construction of Traceable Monero by overlaying Monero with two types of tracing mechanisms, tracing the one-time addresses with money flows and tracing the long-term addresses. We prove the security of Traceable Monero and implement a prototype of the system, which demonstrates that Traceable Monero incurs merely a very small overhead in generating and verifying a transaction compared to Monero transactions.""
""Content-Encoding"",""UTF-8""
""Content-Type-Hint"",""text/html; charset=utf-8""
""Content-Length"",""44540""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=120&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093543-575;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;… of blockchain technologies in manufacturing. Study of applicability of blockchain technology in manufacturing: blockchain typologies, manufacturing scenarios …;S VACCA TORELLI ;2019 politesi.polimi.it;;"… its paper (Nakamoto, 2009) the Blockchain structure, taking inspiration from the Hash- Chain.

Nakamoto proposed this block-based design as a core component of the crypto- currency

Bitcoin which was deployed the following year. Page 27. 26 …";Autres articles;Version HTML;[PDF] polimi.it;https://www.politesi.polimi.it/bitstream/10589/150965/1/2019_12_Vacca_Torelli.pdf;;"""date"",""2019-12-05T10:14:08Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.7""
""xmp:CreatorTool"",""MicrosoftÂŽ Word for Office 365""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dc:creator"",""Simone Vacca Torelli""
""language"",""en""
""dcterms:created"",""2019-12-05T10:14:08Z""
""Last-Modified"",""2019-12-05T10:14:08Z""
""dcterms:modified"",""2019-12-05T10:14:08Z""
""dc:format"",""application/pdf; version=1.7""
""xmpMM:DocumentID"",""uuid:09B4814D-4F64-408A-BF25-D486C84CBEB4""
""Last-Save-Date"",""2019-12-05T10:14:08Z""
""pdf:docinfo:creator_tool"",""MicrosoftÂŽ Word for Office 365""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2019-12-05T10:14:08Z""
""meta:save-date"",""2019-12-05T10:14:08Z""
""pdf:encrypted"",""false""
""xmp:CreateDate"",""2019-12-05T11:14:08Z""
""modified"",""2019-12-05T10:14:08Z""
""pdf:hasMarkedContent"",""true""
""Content-Type"",""application/pdf""
""xmp:ModifyDate"",""2019-12-05T11:14:08Z""
""pdf:docinfo:creator"",""Simone Vacca Torelli""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Simone Vacca Torelli""
""dc:language"",""en-US""
""meta:author"",""Simone Vacca Torelli""
""pdf:producer"",""MicrosoftÂŽ Word for Office 365""
""meta:creation-date"",""2019-12-05T10:14:08Z""
""created"",""2019-12-05T10:14:08Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""211""
""Creation-Date"",""2019-12-05T10:14:08Z""
""resourceName"",""2019_12_Vacca_Torelli.pdf""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""476"",""44"",""176"",""44"",""908"",""44"",""1298"",""44"",""1336"",""44"",""4442"",""4373"",""4241"",""338"",""4095"",""4004"",""655"",""46"",""4002"",""593"",""1046"",""459"",""2512"",""931"",""1863"",""2173"",""2140"",""2460"",""2721"",""2145"",""1821"",""2919"",""2652"",""1711"",""1736"",""820"",""868"",""574"",""1581"",""1375"",""1477"",""651"",""2098"",""1980"",""1101"",""1728"",""623"",""2090"",""1641"",""1649"",""1814"",""2732"",""2707"",""2195"",""1779"",""1668"",""2941"",""2674"",""2883"",""2224"",""2738"",""2809"",""2934"",""3011"",""3021"",""2817"",""2643"",""2606"",""1462"",""2584"",""2505"",""2507"",""2043"",""2907"",""2031"",""1790"",""2133"",""2628"",""1825"",""2833"",""2065"",""774"",""2673"",""923"",""1542"",""2368"",""1989"",""1491"",""2137"",""1058"",""1823"",""2517"",""2420"",""530"",""2197"",""2367"",""2002"",""2657"",""2039"",""2857"",""1692"",""2602"",""1473"",""2923"",""2814"",""2696"",""690"",""2388"",""2690"",""2849"",""2442"",""2931"",""2869"",""2698"",""2391"",""1642"",""2981"",""2849"",""2749"",""2347"",""2580"",""3501"",""1129"",""2782"",""1237"",""2919"",""2482"",""2547"",""2707"",""2373"",""2923"",""2767"",""586"",""2790"",""1820"",""3032"",""3834"",""2418"",""2823"",""2877"",""1164"",""1069"",""2786"",""2769"",""2805"",""2792"",""2771"",""207"",""2244"",""2733"",""2305"",""169"",""2273"",""2980"",""107"",""110"",""2297"",""3122"",""3029"",""2964"",""3117"",""2841"",""2889"",""2590"",""3137"",""3227"",""2913"",""2908"",""2884"",""2543"",""2810"",""103"",""119"",""139"",""2502"",""2688"",""2671"",""2574"",""2651"",""2981"",""2779"",""949"",""2390"",""2758"",""2221"",""2354"",""1899"",""1964"",""2679"",""1055"",""941"",""2196"",""2133"",""2256"",""2206"",""2422"",""2248"",""2141"",""2185"",""2329"",""2237"",""2312"",""2075"",""2160"",""2205"",""2136"",""2313"",""2240"",""2314"",""2452"",""1394""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""Author"",""Simone Vacca Torelli""
""producer"",""MicrosoftÂŽ Word for Office 365""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""MicrosoftÂŽ Word for Office 365""
""pdf:docinfo:created"",""2019-12-05T10:14:08Z""
";https://scholar.google.com/scholar?start=410&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093473-272;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;MUSCLE: authenticated external data retrieval from multiple sources for smart contracts;B van der Laan, O Ersoy, Z Erkin ; Proceedings of the 34th ACM/SIGAPP …, 2019  dl.acm.org;;"… In other words, the oracle server can inspect the blockchain, but oracle contract

cannot examine entities on the Internet. The primary requirement in designing oracles

is that the au- thenticity of data must be publicly verifiable …";Cité 3 fois;;[PDF] acm.org;https://dl.acm.org/doi/pdf/10.1145/3297280.3297320?casa_token=iI9EcGa5-PAAAAAA:FlsthTbk4TVuDphA_haQf9ZLu4CaLb2NJ7GEFUj2waXkCjYRdghvMjyVaRK_rPQfr5H8Dj99GOc;;;https://scholar.google.com/scholar?start=110&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093452-186;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Legal aspects and emerging risks in the use of smart contracts based on blockchain;Y Mezquita, D Valdeolmillos… ; International Conference …, 2019  Springer;;"… 29]. Regarding on how an oracle interacts with the Smart Contracts of a blockchain,

there can be classified in [4]: Software Oracles: The oracles of this kind gather the

information from sources like web sites or public databases …";Cité 11 fois;;null;;;;https://scholar.google.com/scholar?start=20&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093523-481;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Blockchain Access Management with Global Combat Support System-Marine Corps;BR Schofield, B Snelgrove ;2019 apps.dtic.mil;;"… BLOCKCHAIN RESEARCH AND THE DOD .....6 C. GLOBAL COMBAT

SUPPORT SYSTEM – MARINE CORPS .....7 D. ORACLE ACCESS

MANAGEMENT .....10 E. CRYPTOGRAPHY AND BLOCKCHAIN .....16 F …";Autres articles;;[PDF] dtic.mil;https://apps.dtic.mil/sti/pdfs/AD1080396.pdf;;"""date"",""2019-07-24T19:30:22Z""
""pdf:PDFVersion"",""1.6""
""xmp:CreatorTool"",""Acrobat PDFMaker 17 for Word""
""pdf:docinfo:title"",""""
""Company"",""""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.6""
""pdf:docinfo:creator_tool"",""Acrobat PDFMaker 17 for Word""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""xmp:CreateDate"",""2019-05-28T11:56:07Z""
""modified"",""2019-07-24T19:30:22Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""true""
""xmp:ModifyDate"",""2019-07-24T12:30:22Z""
""pdf:docinfo:creator"",""Aileen B. Houston""
""meta:author"",""Aileen B. Houston""
""meta:creation-date"",""2019-05-28T18:56:00Z""
""created"",""2019-05-28T18:56:00Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-05-28T18:56:00Z""
""resourceName"",""AD1080396.pdf""
""pdf:docinfo:custom:Comments"",""""
""Author"",""Aileen B. Houston""
""producer"",""Adobe PDF Library 15.0""
""pdf:docinfo:producer"",""Adobe PDF Library 15.0""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""access_permission:modify_annotations"",""true""
""dc:creator"",""Aileen B. Houston""
""dcterms:created"",""2019-05-28T18:56:00Z""
""Last-Modified"",""2019-07-24T19:30:22Z""
""dcterms:modified"",""2019-07-24T19:30:22Z""
""title"",""""
""xmpMM:DocumentID"",""uuid:cc754b4e-413c-4103-9ed4-c485327bdefb""
""Last-Save-Date"",""2019-07-24T19:30:22Z""
""pdf:docinfo:modified"",""2019-07-24T19:30:22Z""
""meta:save-date"",""2019-07-24T19:30:22Z""
""Content-Length"",""2101453""
""Content-Type"",""application/pdf""
""xmp:MetadataDate"",""2019-07-24T12:30:22Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Aileen B. Houston""
""pdf:producer"",""Adobe PDF Library 15.0""
""Comments"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""107""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""332"",""35"",""3549"",""38"",""845"",""38"",""1432"",""38"",""3194"",""3283"",""1586"",""37"",""2584"",""39"",""722"",""39"",""954"",""822"",""671"",""42"",""2223"",""2297"",""2195"",""1550"",""2162"",""2352"",""2436"",""2469"",""840"",""1600"",""986"",""1824"",""835"",""1419"",""2345"",""2470"",""1507"",""1507"",""1264"",""2553"",""1721"",""1833"",""1137"",""2459"",""2637"",""2194"",""1998"",""2019"",""1941"",""2243"",""1839"",""1493"",""2205"",""2512"",""2289"",""1371"",""1325"",""2421"",""882"",""1374"",""1454"",""1473"",""950"",""992"",""1955"",""1145"",""1148"",""976"",""720"",""656"",""2200"",""1045"",""588"",""1109"",""1004"",""1369"",""2323"",""2092"",""2291"",""2317"",""1867"",""2406"",""2531"",""2401"",""465"",""40"",""1996"",""2352"",""1904"",""1807"",""1664"",""799"",""2191"",""1873"",""1456"",""929"",""1749"",""1726"",""1763"",""1572"",""1812"",""1026"",""2169"",""2141"",""2225"",""407"",""165""
""access_permission:extract_content"",""true""
""pdf:docinfo:custom:Company"",""""
""access_permission:can_print"",""true""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-05-28T18:56:00Z""
";https://scholar.google.com/scholar?start=320&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093509-424;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;[LIVRE][B] Conceptual Modeling: 38th International Conference, ER 2019, Salvador, Brazil, November 4–7, 2019, Proceedings;AHF Laender, B Pernici, EP Lim, JPM De Oliveira ;2019 books.google.com;;"… oracle. com/en/cloud/paas/blockchain-cloud/user/using-oracle- blockchain-platform … In: Crypto

Assets: Legal and Monetary Perspectives January 2019.(to appear) … com/abstract= 3326244 Wang,

S., et al.: An efficient storage engine for blockchain and forkable appli- cations …";Cité 1 fois;Les 5 versions;null;;;;https://scholar.google.com/scholar?start=260&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093448-167;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;ASTRAEA: A decentralized blockchain oracle;R Berryhill, A Veneris ; IEEE Blockchain Technical Briefs, 2019  blockchain.ieee.org;;"The idea of a public blockchain was first conceived to prevent double-spending while 
processing monetary transactions in a peer-to-peer network [1]. In its original application, it 
allows a set of quasi-anonymous and mutually-distrusting parties to reach consensus on the …";Cité 3 fois;;null;;;;
1619093450-175;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;On decentralized oracles for data availability;J Teutsch ; arXiv preprint arXiv:1910.10694, 2019  arxiv.org;;"… 2 Warm-up: fiat-crypto exchange rates Verifying an Ethereum transaction amounts to checking

signatures, logical conditions, and self-evident mathematical truths … Astraea: A decentralized

blockchain oracle … On public decentralized ledger oracles via a paired-question protocol …";Cité 7 fois;Les 4 versions;[PDF] arxiv.org;https://arxiv.org/pdf/1910.10694;;"""date"",""2019-10-24T01:37:53Z""
""pdf:PDFVersion"",""1.4""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.4""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""xmp:CreateDate"",""2019-10-23T21:37:53Z""
""modified"",""2019-10-24T01:37:53Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""xmp:ModifyDate"",""2019-10-23T21:37:53Z""
""pdf:docinfo:creator"",""""
""meta:author"",""""
""meta:creation-date"",""2019-10-24T01:37:53Z""
""created"",""2019-10-24T01:37:53Z""
""xmp:About"",""uuid:721fc81a-2e1b-11f5-0000-3be47c257800""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-10-24T01:37:53Z""
""resourceName"",""1910.10694""
""Author"",""""
""producer"",""dvips + GPL Ghostscript GIT PRERELEASE 9.22""
""pdf:docinfo:producer"",""dvips + GPL Ghostscript GIT PRERELEASE 9.22""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2019-10-24T01:37:53Z""
""Last-Modified"",""2019-10-24T01:37:53Z""
""dcterms:modified"",""2019-10-24T01:37:53Z""
""title"",""""
""xmpMM:DocumentID"",""uuid:721fc81a-2e1b-11f5-0000-3be47c257800""
""Last-Save-Date"",""2019-10-24T01:37:53Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2019-10-24T01:37:53Z""
""meta:save-date"",""2019-10-24T01:37:53Z""
""Content-Length"",""121966""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""11""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""1500"",""2366"",""2081"",""1753"",""1876"",""1720"",""1665"",""1958"",""2126"",""1216"",""1422""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-10-24T01:37:53Z""
";https://scholar.google.com/scholar?start=10&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093452-189;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;[LIVRE][B] Oracle Blockchain Quick Start Guide: A practical approach to implementing blockchain in your enterprise;V Acharya, AE Yerrapati, N Prakash ;2019 books.google.com;;"Get up and running with Oracle's premium cloud blockchain services and build distributed 
blockchain apps with ease Key Features Discover Hyperledger Fabric and its components, 
features, qualifiers, and architecture Get familiar with the Oracle Blockchain Platform and its …";Cité 7 fois;Les 2 versions;null;;;;https://scholar.google.com/scholar?start=20&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093536-541;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Blockchain-based secure and searchable EHR sharing scheme;Y Xiaodong, LI Ting, LIU Rui… ; 2019 4th International …, 2019  ieeexplore.ieee.org;;"Page 1. Blockchain-based secure and searchable EHR sharing scheme Xiaodong

YANG … environment. This paper stores the EHR data ciphertext on the cloud, and stores

the keyword index of the EHR data on the blockchain. The …";Cité 5 fois;Les 2 versions;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/8961322/8969078/08969247.pdf?casa_token=b57ImJH8W7YAAAAA:64fn-xRBjfNLj0BkK25_Rth8UXqK_m34lEUmtcR0Nm_j5WZhkM6XYCbaudQzqXMzs3WUqYzLvGA;;"""og:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""twitter:title"",""Blockchain-Based Secure and Searchable EHR Sharing Scheme""
""twitter:card"",""summary""
""Description"",""Electronic Health Record (EHR) not only contains great value, but also implies a large amount of personal privacy. Aiming at the security problems such as data ""
""og:title"",""Blockchain-Based Secure and Searchable EHR Sharing Scheme""
""resourceName"",""08969247.pdf""
""language"",""en""
""title"",""Blockchain-Based Secure and Searchable EHR Sharing Scheme | IEEE Conference Publication | IEEE Xplore""
""og:description"",""Electronic Health Record (EHR) not only contains great value, but also implies a large amount of personal privacy. Aiming at the security problems such as data forgery and tampering in EHR data sharing process, this paper proposes a blockchain-based EHR data searchable scheme to realize the calculation and application of EHR data in the decentralized network environment. This paper stores the EHR data ciphertext on the cloud, and stores the keyword index of the EHR data on the blockchain. The data visitor's search result on the blockchain is only the blind value of the data identifier, and is generated after blinding. The token for downloading ciphertext data in the cloud not only improves storage efficiency of the system, but also ensures the integrity, immutability and traceability of the EHR data index. Based on the attribute encryption mechanism, the fine-grained access control of cloud data is realized, and the attribute signature technology is used to verify the authenticity of the EHR data source. Finally, experiments show that the encryption and search time of this scheme is constant, regardless of the number of attributes.""
""twitter:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-UA-Compatible"",""IE=Edge""
""viewport"",""width=device-width, initial-scale=1.0""
""dc:title"",""Blockchain-Based Secure and Searchable EHR Sharing Scheme | IEEE Conference Publication | IEEE Xplore""
""twitter:description"",""Electronic Health Record (EHR) not only contains great value, but also implies a large amount of personal privacy. Aiming at the security problems such as data forgery and tampering in EHR data sharing process, this paper proposes a blockchain-based EHR data searchable scheme to realize the calculation and application of EHR data in the decentralized network environment. This paper stores the EHR data ciphertext on the cloud, and stores the keyword index of the EHR data on the blockchain. The data visitor's search result on the blockchain is only the blind value of the data identifier, and is generated after blinding. The token for downloading ciphertext data in the cloud not only improves storage efficiency of the system, but also ensures the integrity, immutability and traceability of the EHR data index. Based on the attribute encryption mechanism, the fine-grained access control of cloud data is realized, and the attribute signature technology is used to verify the authenticity of the EHR data source. Finally, experiments show that the encryption and search time of this scheme is constant, regardless of the number of attributes.""
""Content-Encoding"",""UTF-8""
""Content-Type-Hint"",""text/html; charset=utf-8""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=380&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093459-212;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;State of public and private blockchains: Myths and reality;C Mohan ; Proceedings of the 2019 International Conference on …, 2019  dl.acm.org;;"… Ethereum also introduced its own cryptocurrency called Ether and another entity called Gas for

charging for resources consumed while … released Blockchain-as-a-Service (BaaS) offerings based

on Fabric – eg, IBM Blockchain Platform (IBP) [43], Oracle Blockchain Platform [60 …";Cité 15 fois;Les 4 versions;[PDF] acm.org;https://dl.acm.org/doi/pdf/10.1145/3299869.3314116?casa_token=FNyk581AK2wAAAAA:IMX7GbxSGHgSxRyuYJkqUWG-y9vQ63RTTTGHBQyXKdr0q0GjwiBnJXtBEoK47S35WPaESQ6Rrmw;;;https://scholar.google.com/scholar?start=50&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093469-258;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;POSTER: Blockchain Abstract Data Type;E Anceaume, A Del Pozzo… ; … on Principles and …, 2019  hal.archivesouvertes.fr;;"… Future work will focus on several open issues, such as the solvability of Even- tual Prefix

in message-passing, the synchronization power of other oracle models, and fairness

properties for oracles … 2017. The Blockchain Consensus Layer and BFT …";Autres articles;;[PDF] archives-ouvertes.fr;https://hal.archives-ouvertes.fr/hal-01988364/document;;"""date"",""2019-01-04T10:46:14Z""
""pdf:PDFVersion"",""1.4""
""pdf:docinfo:title"",""POSTER: Blockchain Abstract Data Type""
""xmp:CreatorTool"",""HAL""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""Computer Science [cs], Computer Science [cs]/Data Structures and Algorithms [cs.DS], Computer Science [cs]/Distributed, Parallel, and Cluster Computing [cs.DC]""
""language"",""en""
""dc:format"",""application/pdf; version=1.4""
""pdf:docinfo:creator_tool"",""HAL""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""POSTER: Blockchain Abstract Data Type""
""modified"",""2019-01-04T10:46:14Z""
""cp:subject"",""Computer Science [cs], Computer Science [cs]/Data Structures and Algorithms [cs.DS], Computer Science [cs]/Distributed, Parallel, and Cluster Computing [cs.DC]""
""pdf:docinfo:subject"",""Computer Science [cs], Computer Science [cs]/Data Structures and Algorithms [cs.DS], Computer Science [cs]/Distributed, Parallel, and Cluster Computing [cs.DC]""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""Emmanuelle Anceaume, Antonella del Pozzo, Romaric Ludinard, Maria Potop-Butucaru, Sara Tucci-Piergiovanni""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017/Debian) kpathsea version 6.2.3""
""meta:author"",""Emmanuelle Anceaume, Antonella del Pozzo, Romaric Ludinard, Maria Potop-Butucaru, Sara Tucci-Piergiovanni""
""trapped"",""False""
""meta:creation-date"",""2021-04-12T00:50:40Z""
""created"",""2021-04-12T00:50:40Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2021-04-12T00:50:40Z""
""resourceName"",""document""
""Author"",""Emmanuelle Anceaume, Antonella del Pozzo, Romaric Ludinard, Maria Potop-Butucaru, Sara Tucci-Piergiovanni""
""producer"",""PDFLaTeX""
""pdf:docinfo:producer"",""PDFLaTeX""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0""
""Keywords"",""Consistency Criteria, Distributed computing models, Blockchain, Abstract Data Type""
""access_permission:modify_annotations"",""true""
""dc:creator"",""Emmanuelle Anceaume, Antonella del Pozzo, Romaric Ludinard, Maria Potop-Butucaru, Sara Tucci-Piergiovanni""
""dcterms:created"",""2021-04-12T00:50:40Z""
""Last-Modified"",""2019-01-04T10:46:14Z""
""dcterms:modified"",""2019-01-04T10:46:14Z""
""title"",""POSTER: Blockchain Abstract Data Type""
""Last-Save-Date"",""2019-01-04T10:46:14Z""
""pdf:docinfo:keywords"",""Consistency Criteria, Distributed computing models, Blockchain, Abstract Data Type""
""pdf:docinfo:modified"",""2019-01-04T10:46:14Z""
""meta:save-date"",""2019-01-04T10:46:14Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017/Debian) kpathsea version 6.2.3""
""Content-Length"",""541898""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Emmanuelle Anceaume, Antonella del Pozzo, Romaric Ludinard, Maria Potop-Butucaru, Sara Tucci-Piergiovanni""
""dc:subject"",""Consistency Criteria, Distributed computing models, Blockchain, Abstract Data Type""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""3""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""1067"",""4169"",""5141""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""Consistency Criteria, Distributed computing models, Blockchain, Abstract Data Type""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2021-04-12T00:50:40Z""
";https://scholar.google.com/scholar?start=90&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093464-232;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;[PDF][PDF] Trustable oracles towards trustable blockchains;PD da Costa ;2019 repositorioaberto.up.pt;;"… Then the author describes a self-hosted approach with an- other two architectures: Single-Party

Self Hosted Oracle and Multi-Party Self Hosted Oracle. This way, the author creates a guide that

can support those creating blockchain oracles in thinking about the many limitations …";Autres articles;;[PDF] up.pt;https://repositorio-aberto.up.pt/bitstream/10216/122219/3/351086.1.pdf;;"""date"",""2019-07-23T13:49:20Z""
""pdf:PDFVersion"",""1.4""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.4""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2019-07-23T13:49:20Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.20 (TeX Live 2019/W32TeX) kpathsea version 6.3.1""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2019-07-23T13:45:12Z""
""created"",""2019-07-23T13:45:12Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-07-23T13:45:12Z""
""resourceName"",""351086.1.pdf""
""Author"",""""
""producer"",""3-Heights(TM) PDF Security Shell 4.8.25.2 (http://www.pdf-tools.com) / pdcat (www.pdf-tools.com)""
""pdf:docinfo:producer"",""3-Heights(TM) PDF Security Shell 4.8.25.2 (http://www.pdf-tools.com) / pdcat (www.pdf-tools.com)""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""1"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""4"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""1"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2019-07-23T13:45:12Z""
""Last-Modified"",""2019-07-23T13:49:20Z""
""dcterms:modified"",""2019-07-23T13:49:20Z""
""title"",""""
""Last-Save-Date"",""2019-07-23T13:49:20Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2019-07-23T13:49:20Z""
""meta:save-date"",""2019-07-23T13:49:20Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.20 (TeX Live 2019/W32TeX) kpathsea version 6.3.1""
""Content-Length"",""2143005""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""132""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""254"",""0"",""123"",""0"",""2795"",""2"",""2654"",""2"",""617"",""2"",""71"",""4"",""1589"",""2392"",""553"",""11"",""1054"",""16"",""309"",""15"",""332"",""0"",""1832"",""2072"",""1262"",""1849"",""1081"",""1302"",""1373"",""987"",""1626"",""1101"",""1149"",""1366"",""2566"",""2399"",""2571"",""1306"",""1722"",""2385"",""1742"",""2188"",""2285"",""2352"",""904"",""2122"",""1193"",""20"",""1746"",""2376"",""1341"",""18"",""1987"",""2112"",""936"",""2502"",""689"",""2210"",""1968"",""782"",""1012"",""2472"",""642"",""18"",""1697"",""1114"",""1456"",""1768"",""1937"",""2734"",""654"",""33"",""1315"",""2649"",""2111"",""2195"",""2499"",""1380"",""1324"",""2381"",""436"",""26"",""1944"",""1943"",""29"",""1261"",""1212"",""1283"",""1190"",""1181"",""1083"",""1329"",""1164"",""1092"",""1151"",""1293"",""1082"",""1159"",""335"",""20"",""899"",""1130"",""692"",""20"",""567"",""118"",""707"",""730"",""37"",""2274"",""2590"",""2258"",""740"",""1445"",""1522"",""2683"",""2540"",""2701"",""2930"",""1485"",""30"",""1531"",""1477"",""1550"",""1383"",""1329"",""1332"",""1316"",""1367"",""1439"",""1445"",""1117""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-07-23T13:45:12Z""
";https://scholar.google.com/scholar?start=70&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093490-341;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Deductive proof of ethereum smart contracts using why3;Z Nehai, F Bobot ; arXiv preprint arXiv:1904.11281, 2019  arxiv.org;;"… Accordingly, the oracle provides a service responsible for entering external data into

the blockchain, having the role of a trusted third party. However, questions arise about

the reliability of such oracles and accuracy of information …";Cité 12 fois;Les 6 versions;[PDF] arxiv.org;https://arxiv.org/pdf/1904.11281;;"""date"",""2019-08-30T18:50:03Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2019-08-30T18:50:03Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016) kpathsea version 6.2.2""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2019-08-30T18:50:03Z""
""created"",""2019-08-30T18:50:03Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-08-30T18:50:03Z""
""resourceName"",""1904.11281""
""Author"",""""
""producer"",""pdfTeX-1.40.17""
""pdf:docinfo:producer"",""pdfTeX-1.40.17""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""2"",""0"",""0"",""0"",""2"",""1"",""1"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2019-08-30T18:50:03Z""
""Last-Modified"",""2019-08-30T18:50:03Z""
""dcterms:modified"",""2019-08-30T18:50:03Z""
""title"",""""
""Last-Save-Date"",""2019-08-30T18:50:03Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2019-08-30T18:50:03Z""
""meta:save-date"",""2019-08-30T18:50:03Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016) kpathsea version 6.2.2""
""Content-Length"",""727032""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""38""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""2116"",""2165"",""2243"",""2926"",""2201"",""2440"",""2335"",""2510"",""2391"",""2389"",""2532"",""2763"",""971"",""1298"",""1360"",""1417"",""1233"",""1563"",""1828"",""1857"",""1603"",""1529"",""1769"",""1381"",""1390"",""1471"",""1239"",""1042"",""1462"",""1200"",""1162"",""1219"",""1467"",""1852"",""1370"",""1339"",""1614"",""779""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-08-30T18:50:03Z""
";https://scholar.google.com/scholar?start=180&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093464-233;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;At Your Service: How Can Blockchain Be Used to Address Societal Challenges?;N Faber, J Jonker ; Business Transformation through Blockchain, 2019  Springer;;"… An Oracle is an agent that finds and verifies real occurrences and submits this information to

a … In this respect, Oracles provide predefined conditions encapsulating delivery data, such as water

temperature, successful payment, price … BlockChain Technology: Beyond Bitcoin …";Cité 7 fois;Les 4 versions;null;;;;https://scholar.google.com/scholar?start=70&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093523-487;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;[PDF][PDF] Generic Constructions of RIBE via Subset Difference Method.;X Ma, D Lin ; IACR Cryptol. ePrint Arch., 2019  eprint.iacr.org;;"… Boneh and Franklin (Crypto'01) presented the first generic construction of RIBE, however, their

scheme is not scalable where the size of key updates … The first IBE scheme was proposed by Boneh

and Franklin [9] in the random oracle model [4]. Since then, there are many follow …";Cité 3 fois;;[PDF] iacr.org;https://eprint.iacr.org/2019/1376.pdf;;"""date"",""2019-12-17T08:07:23Z""
""pdf:unmappedUnicodeCharsPerPage"",""3"",""10"",""7"",""25"",""17"",""21"",""19"",""17"",""11"",""23"",""28"",""18"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.5""
""xmp:CreatorTool"",""TeX""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dcterms:created"",""2019-12-17T08:07:23Z""
""language"",""en""
""Last-Modified"",""2019-12-17T08:07:23Z""
""dcterms:modified"",""2019-12-17T08:07:23Z""
""dc:format"",""application/pdf; version=1.5""
""Last-Save-Date"",""2019-12-17T08:07:23Z""
""pdf:docinfo:creator_tool"",""TeX""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2019-12-17T08:07:23Z""
""meta:save-date"",""2019-12-17T08:07:23Z""
""pdf:encrypted"",""false""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is MiKTeX-pdfTeX 2.9.7029 (1.40.20)""
""modified"",""2019-12-17T08:07:23Z""
""Content-Length"",""414257""
""pdf:hasMarkedContent"",""false""
""Content-Type"",""application/pdf""
""PTEX.Fullbanner"",""This is MiKTeX-pdfTeX 2.9.7029 (1.40.20)""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""trapped"",""False""
""meta:creation-date"",""2019-12-17T08:07:23Z""
""created"",""2019-12-17T08:07:23Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""15""
""Creation-Date"",""2019-12-17T08:07:23Z""
""resourceName"",""1376.pdf""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""3429"",""3674"",""3701"",""2234"",""2773"",""2263"",""2726"",""1494"",""2843"",""2791"",""3568"",""3499"",""3837"",""4253"",""1467""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""producer"",""MiKTeX pdfTeX-1.40.20""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""MiKTeX pdfTeX-1.40.20""
""pdf:docinfo:created"",""2019-12-17T08:07:23Z""
";https://scholar.google.com/scholar?start=320&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093513-445;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;[PDF][PDF] Blockchain for food: making sense of technology and the impact on biofortified seeds;M De Ruyter de Wildt, M Van Ginkel, K Coppoolse… ;2019 repository.cimmyt.org;;"Page 1. Community of Practice on Socio-economic Data Report CoP_SED-2019-003 Blockchain

For Food Making Sense of Technology and the Impact … Page 3. Community of Practice on

Socio-economic Data Report CoP_SED-2019-003 Blockchain For Food: Making Sense of …";Cité 2 fois;Les 3 versions;[PDF] cimmyt.org;https://repository.cimmyt.org/bitstream/handle/10883/20683/61328.pdf?sequence=1;;"""date"",""2020-01-17T16:12:59Z""
""pdf:PDFVersion"",""1.5""
""xmp:CreatorTool"",""MicrosoftÂŽ Word 2016""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""MicrosoftÂŽ Word 2016""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""xmp:CreateDate"",""2020-01-14T13:47:22Z""
""modified"",""2020-01-17T16:12:59Z""
""pdf:hasMarkedContent"",""false""
""xmp:ModifyDate"",""2020-01-17T11:12:59Z""
""pdf:docinfo:creator"",""Gutierrez, Daniel (CIAT)""
""meta:author"",""Gutierrez, Daniel (CIAT)""
""meta:creation-date"",""2020-01-14T19:47:22Z""
""created"",""2020-01-14T19:47:22Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-01-14T19:47:22Z""
""resourceName"",""61328.pdf""
""Author"",""Gutierrez, Daniel (CIAT)""
""producer"",""MicrosoftÂŽ Word 2016""
""pdf:docinfo:producer"",""MicrosoftÂŽ Word 2016""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""access_permission:modify_annotations"",""true""
""dc:creator"",""Gutierrez, Daniel (CIAT)""
""dcterms:created"",""2020-01-14T19:47:22Z""
""Last-Modified"",""2020-01-17T16:12:59Z""
""dcterms:modified"",""2020-01-17T16:12:59Z""
""xmpMM:DocumentID"",""uuid:aedb8661-75da-48ab-966f-644f28072d76""
""Last-Save-Date"",""2020-01-17T16:12:59Z""
""pdf:docinfo:modified"",""2020-01-17T16:12:59Z""
""meta:save-date"",""2020-01-17T16:12:59Z""
""Content-Length"",""1609452""
""Content-Type"",""application/pdf""
""xmp:MetadataDate"",""2020-01-17T11:12:59Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Gutierrez, Daniel (CIAT)""
""dc:language"",""en-US""
""pdf:producer"",""MicrosoftÂŽ Word 2016""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""49""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""283"",""5"",""284"",""329"",""2091"",""1265"",""1152"",""3882"",""3167"",""3588"",""227"",""2847"",""552"",""2395"",""3187"",""2633"",""1285"",""1721"",""2926"",""2106"",""2163"",""2581"",""1631"",""2095"",""2322"",""2762"",""3091"",""1647"",""2238"",""1296"",""1427"",""1813"",""149"",""2097"",""1405"",""2700"",""2276"",""1641"",""1398"",""1636"",""1111"",""1968"",""1231"",""2607"",""2070"",""1082"",""499"",""395"",""320""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-01-14T19:47:22Z""
";https://scholar.google.com/scholar?start=280&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093539-555;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Integrated Application of Blockchain in the Electric Information Management System;C Xu, Y Fang, Y Ma ; Procedia Computer Science, 2019  Elsevier;;"… Real-name registration module transformation, information interaction with the blockchain

component, the user identity information in Oracle is migrated to the blockchain node, and

the user identity information is stored and acquired in the blockchain …";Cité 1 fois;;[PDF] sciencedirect.com;https://www.sciencedirect.com/science/article/pii/S187705091931974X/pdf?md5=9f4a1824768b56c33b8476b4ccae0a47&pid=1-s2.0-S187705091931974X-main.pdf;;;https://scholar.google.com/scholar?start=390&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093480-308;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;[PDF][PDF] A primer for blockchain;LJ Trautman, MJ Molesky ; UMKC L. Rev., 2019  HeinOnline;;"… Oracles can enable this injection, but require a strong reputation system or governance … See Nihat

Yuva & ismail Kirba§, Directed Acyclic Graph Based on Crypto Currency Application … MICHAEL

J. CASEY & PAUL VIGNA, THE TRUTH MACHINE: THE BLOCKCHAIN AND THE …";Cité 26 fois;Les 7 versions;[PDF] heinonline.org;https://heinonline.org/hol-cgi-bin/get_pdf.cgi?handle=hein.journals/umkc88&section=15&casa_token=IKGWiqYkV2YAAAAA:umSwjF72stE9XnAWl23v8YGk9aGzEsl-ARIevZPn0SrdJ1jqaNMEK9OMd0fOM6Bgvl_VBfI;;"""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""REFRESH"",""1; url=https://heinonline.org/HOL/Page?handle=hein.journals/umkc88&div=15&g_sent=1&casa_token=IKGWiqYkV2YAAAAA:umSwjF72stE9XnAWl23v8YGk9aGzEsl-ARIevZPn0SrdJ1jqaNMEK9OMd0fOM6Bgvl_VBfI""
""Content-Encoding"",""UTF-8""
""resourceName"",""get_pdf.cgi""
""language"",""""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=140&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093469-255;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;A Time-Segmented Consortium Blockchain for Robotic Event Registration;M Fernandes, LA Alexandre ; arXiv preprint arXiv:1904.04306, 2019  arxiv.org;;"… blockchain and Oracles are external entities that interact with the blockchain through smart

contracts. One Cold Storage will also serve as the Genesis Node (see main text for details). 3.

The RobotChain 3.1. Previous Work Goodman[7] presents a self-amending crypto-ledger …";Cité 3 fois;Les 2 versions;[PDF] arxiv.org;https://arxiv.org/pdf/1904.04306;;"""date"",""2019-05-15T02:02:48Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""A Time-Segmented Consortium Blockchain for Robotic Event Registration""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""A Time-Segmented Consortium Blockchain for Robotic Event Registration""
""modified"",""2019-05-15T02:02:48Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""Miguel Fernandes; LuĂ­s A. Alexandre; ""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016) kpathsea version 6.2.2""
""meta:author"",""Miguel Fernandes; LuĂ­s A. Alexandre; ""
""trapped"",""False""
""meta:creation-date"",""2019-05-15T02:02:48Z""
""created"",""2019-05-15T02:02:48Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-05-15T02:02:48Z""
""resourceName"",""1904.04306""
""Author"",""Miguel Fernandes; LuĂ­s A. Alexandre; ""
""producer"",""pdfTeX-1.40.17""
""pdf:docinfo:producer"",""pdfTeX-1.40.17""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""Miguel Fernandes; LuĂ­s A. Alexandre; ""
""dcterms:created"",""2019-05-15T02:02:48Z""
""Last-Modified"",""2019-05-15T02:02:48Z""
""dcterms:modified"",""2019-05-15T02:02:48Z""
""title"",""A Time-Segmented Consortium Blockchain for Robotic Event Registration""
""Last-Save-Date"",""2019-05-15T02:02:48Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2019-05-15T02:02:48Z""
""meta:save-date"",""2019-05-15T02:02:48Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016) kpathsea version 6.2.2""
""Content-Length"",""320856""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Miguel Fernandes; LuĂ­s A. Alexandre; ""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""14""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""1489"",""1966"",""2158"",""1564"",""2269"",""2190"",""2186"",""1609"",""2194"",""1968"",""1773"",""1883"",""1792"",""1330""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-05-15T02:02:48Z""
";https://scholar.google.com/scholar?start=90&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093506-414;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Collaborative Blockchain-based detection of distributed denial of service attacks based on internet of things botnets;G Spathoulas, N Giachoudis, GP Damiris… ; Future Internet, 2019  mdpi.com;;"Next Article in Journal IoT Based Smart City Bus Stops. Previous Article in Journal FaDe:

A Blockchain-Based Fair Data Exchange Scheme for Big Data Sharing. Previous Article …

2.2. Blockchain and DDoS Detection. Blockchain technology …";Cité 8 fois;Les 4 versions;[PDF] mdpi.com;https://www.mdpi.com/1999-5903/11/11/226/pdf;;;https://scholar.google.com/scholar?start=250&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093473-275;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;[HTML][HTML] uBaaS: A unified blockchain as a service platform;Q Lu, X Xu, Y Liu, I Weber, L Zhu, W Zhang ; Future Generation Computer …, 2019  Elsevier;;"… The oracles supply information about the external world to theblockchain, usually by … contracts

and divided them into several categories: token, authorization, oracle, randomness, poll … However,

the summarized design patterns for blockchain-based applications are mostly at …";Cité 32 fois;W Zhang;[HTML] sciencedirect.com;https://www.sciencedirect.com/science/article/pii/S0167739X18319873?casa_token=7_3b9wUm_0oAAAAA:Z6LOkXi6w2AQ7ALXSFplUEwSbQ85Ew0T5tl2bplrdLYkVlrpowu1fhDqAM2XlP8d0SVoy2pJ;;;https://scholar.google.com/scholar?start=110&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093476-288;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Policy-driven blockchain and its applications for transport systems;Y Mu, F Rezaeibagha, K Huang ; IEEE Transactions on …, 2019  ieeexplore.ieee.org;;"… Although this kind of blockchains have shown many applications, especially for crypto currencies,

there … 3) Our PDS scheme is provably secure in the standard security model (without random oracle) …

3.1 Overview of Blockchain The notion of blockchain was introduced in 2008 [1 …";Cité 3 fois;Les 4 versions;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/4629386/4629387/08871202.pdf?casa_token=18ZsHwYB1PAAAAAA:TZ1gU2iocN677XV9cnJvQJ24CtY7JSOi0tD5iSKOPWybDKX0Dx2a7i4dIcfSK2d7lyrLt3SpiqI;;"""og:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""twitter:title"",""Policy-Driven Blockchain and Its Applications for Transport Systems""
""twitter:card"",""summary""
""Description"",""Blockchains offer opportunities for developing advanced digital services. While current research on this topic is still growing, various security concerns have ""
""og:title"",""Policy-Driven Blockchain and Its Applications for Transport Systems""
""resourceName"",""08871202.pdf""
""language"",""en""
""title"",""Policy-Driven Blockchain and Its Applications for Transport Systems | IEEE Journals & Magazine | IEEE Xplore""
""og:description"",""Blockchains offer opportunities for developing advanced digital services. While current research on this topic is still growing, various security concerns have been raised and the security of blockchains has been becoming the most important issue which must be well addressed. Blockchain transactions are based on digital signatures, where the public key is associated with the ownership of the digital coin. User management of public or permissionless blockchain is ad hoc, i.e., any user can join and leave the blockchain network and participate in the Proof of Work (PoW). However, in a private blockchain and a permissioned blockchain, there are usually some constraints for users. In this paper, we investigate a scenario which provides a blockchain network with a set of policies where every user's signing key is associated with a policy set. It is particularly interesting while users are working in different sectors. We call our scheme as “policy-driven”, since policies in our scheme restrict users' rights. Our system is featured with a novel and lightweight policy-driven signature (PDS) scheme whose security has been proven formally. To justify our scenario, we provide experimental results and an example for the railway management services.""
""twitter:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-UA-Compatible"",""IE=Edge""
""viewport"",""width=device-width, initial-scale=1.0""
""dc:title"",""Policy-Driven Blockchain and Its Applications for Transport Systems | IEEE Journals & Magazine | IEEE Xplore""
""twitter:description"",""Blockchains offer opportunities for developing advanced digital services. While current research on this topic is still growing, various security concerns have been raised and the security of blockchains has been becoming the most important issue which must be well addressed. Blockchain transactions are based on digital signatures, where the public key is associated with the ownership of the digital coin. User management of public or permissionless blockchain is ad hoc, i.e., any user can join and leave the blockchain network and participate in the Proof of Work (PoW). However, in a private blockchain and a permissioned blockchain, there are usually some constraints for users. In this paper, we investigate a scenario which provides a blockchain network with a set of policies where every user's signing key is associated with a policy set. It is particularly interesting while users are working in different sectors. We call our scheme as “policy-driven”, since policies in our scheme restrict users' rights. Our system is featured with a novel and lightweight policy-driven signature (PDS) scheme whose security has been proven formally. To justify our scenario, we provide experimental results and an example for the railway management services.""
""Content-Encoding"",""UTF-8""
""Content-Type-Hint"",""text/html; charset=utf-8""
""Content-Length"",""43796""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=120&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093534-535;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Chancen und Herausforderungen von DLT (Blockchain) in Mobilität und Logistik;G Fridgen, N Guggenberger, T Hoeren, W Prinz… ;2019 orbilu.uni.lu;;"Page 1. Chancen und Herausforderungen von DLT (Blockchain) in Mobilität und Logistik …

CHANCEN UND HERAUSFORDERUNGEN VON DLT (BLOCKCHAIN) IN MOBILITÄT UND

LOGISTIK FRAUNHOFER-INSTITUT FÜR ANGEWANDTE INFORMATIONSTECHNIK FIT …";Cité 9 fois;Les 2 versions;[PDF] uni.lu;https://orbilu.uni.lu/bitstream/10993/44505/1/Chancen%20und%20Herausforderungen.pdf;;"""date"",""2019-05-14T09:32:20Z""
""pdf:PDFVersion"",""1.6""
""xmp:CreatorTool"",""Adobe InDesign CS5 (7.0)""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""xmpMM:History:Action"",""created"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved""
""language"",""de""
""dc:format"",""application/pdf; version=1.6""
""pdf:docinfo:creator_tool"",""Adobe InDesign CS5 (7.0)""
""access_permission:fill_in_form"",""true""
""xmpMM:History:When"",""2019-05-14T11:25:01Z"",""2019-05-14T11:25:40Z"",""2019-05-14T11:25:40Z"",""2019-05-14T11:26:36Z"",""2019-05-14T11:28:01Z"",""2019-05-14T11:28:58Z"",""2019-05-14T11:29:45Z""
""pdf:encrypted"",""false""
""xmp:CreateDate"",""2019-05-14T11:30:39Z""
""modified"",""2019-05-14T09:32:20Z""
""xmpMM:History:SoftwareAgent"",""Adobe InDesign 7.0"",""Adobe InDesign 7.0"",""Adobe InDesign 7.0"",""Adobe InDesign 7.0"",""Adobe InDesign 7.0"",""Adobe InDesign 7.0"",""Adobe InDesign 7.0""
""pdf:hasMarkedContent"",""false""
""xmpMM:History:InstanceID"",""xmp.iid:FFE1AF672676E9118E77BFBE344FB3F9"",""xmp.iid:00E2AF672676E9118E77BFBE344FB3F9"",""xmp.iid:01E2AF672676E9118E77BFBE344FB3F9"",""xmp.iid:21A0FD5C2A76E91187E3EB093D99E7D4"",""xmp.iid:22A0FD5C2A76E91187E3EB093D99E7D4"",""xmp.iid:25A0FD5C2A76E91187E3EB093D99E7D4"",""xmp.iid:AB45D2CF2A76E91187E3EB093D99E7D4""
""xmp:ModifyDate"",""2019-05-14T11:32:20Z""
""trapped"",""False""
""meta:creation-date"",""2019-05-14T09:30:39Z""
""created"",""2019-05-14T09:30:39Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-05-14T09:30:39Z""
""resourceName"",""Chancen%20und%20Herausforderungen.pdf""
""producer"",""Adobe PDF Library 9.9""
""pdf:docinfo:producer"",""Adobe PDF Library 9.9""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""access_permission:modify_annotations"",""true""
""dcterms:created"",""2019-05-14T09:30:39Z""
""Last-Modified"",""2019-05-14T09:32:20Z""
""dcterms:modified"",""2019-05-14T09:32:20Z""
""xmpMM:DocumentID"",""xmp.did:FFE1AF672676E9118E77BFBE344FB3F9""
""Last-Save-Date"",""2019-05-14T09:32:20Z""
""pdf:docinfo:modified"",""2019-05-14T09:32:20Z""
""meta:save-date"",""2019-05-14T09:32:20Z""
""Content-Length"",""2783519""
""Content-Type"",""application/pdf""
""xmp:MetadataDate"",""2019-05-14T11:32:20Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""pdf:producer"",""Adobe PDF Library 9.9""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""258""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""75"",""0"",""725"",""6"",""7326"",""8124"",""8090"",""7686"",""5251"",""6"",""3807"",""3920"",""4109"",""4247"",""3998"",""2110"",""3596"",""3914"",""4206"",""4036"",""4140"",""3981"",""2584"",""4157"",""4152"",""4241"",""4070"",""3018"",""3811"",""3912"",""4363"",""4180"",""4389"",""2718"",""3941"",""4272"",""4230"",""492"",""3461"",""2638"",""2843"",""3177"",""3491"",""4037"",""2760"",""3821"",""3272"",""2951"",""3637"",""3748"",""3166"",""1961"",""2861"",""3180"",""3270"",""3099"",""3222"",""3878"",""737"",""3173"",""3872"",""3778"",""3884"",""3886"",""4023"",""4383"",""3614"",""2992"",""2853"",""2943"",""3475"",""2554"",""3660"",""2458"",""3809"",""4093"",""3793"",""3485"",""3517"",""2641"",""2444"",""3567"",""4134"",""3897"",""4093"",""3297"",""4217"",""3211"",""4310"",""4014"",""1597"",""3850"",""4026"",""4170"",""3855"",""2958"",""4298"",""3988"",""3181"",""2075"",""3173"",""3165"",""3296"",""3784"",""3025"",""3323"",""3832"",""3730"",""3725"",""3199"",""4163"",""3652"",""3508"",""3779"",""2578"",""2373"",""3836"",""4316"",""4290"",""3401"",""2914"",""3444"",""3824"",""3304"",""3983"",""3691"",""3877"",""3750"",""3631"",""3362"",""3625"",""3332"",""4140"",""3683"",""3571"",""3387"",""3330"",""3370"",""3604"",""3577"",""3896"",""3844"",""3487"",""3836"",""3852"",""3924"",""3784"",""4013"",""3787"",""3936"",""3276"",""3472"",""3664"",""3815"",""4018"",""3725"",""3807"",""3758"",""4305"",""3005"",""3204"",""2706"",""3008"",""1684"",""2890"",""3738"",""3971"",""3970"",""3943"",""4066"",""2036"",""3381"",""3063"",""3835"",""3584"",""3554"",""3473"",""3359"",""3025"",""3341"",""3267"",""3411"",""3764"",""1165"",""2860"",""2971"",""3573"",""3405"",""3568"",""3832"",""3281"",""2491"",""1440"",""3934"",""3120"",""3694"",""3187"",""2037"",""2816"",""3421"",""3515"",""3664"",""3595"",""856"",""3620"",""3589"",""3070"",""4134"",""3595"",""3618"",""3311"",""3208"",""4414"",""3495"",""3566"",""2016"",""3233"",""2889"",""3476"",""3627"",""4148"",""4012"",""3617"",""3417"",""3636"",""3094"",""3284"",""3503"",""3158"",""3720"",""3603"",""3583"",""3511"",""3590"",""588"",""4090"",""4224"",""1974"",""2374"",""2531"",""2424"",""2521"",""2589"",""2478"",""2507"",""2462"",""2364"",""2529"",""2475"",""2389"",""2399"",""2485"",""2552"",""2472"",""2425"",""1129"",""514"",""11""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-05-14T09:30:39Z""
";https://scholar.google.com/scholar?start=370&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093494-361;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;A security reference architecture for blockchains;I Homoliak, S Venugopalan, Q Hum… ; … on Blockchain  …, 2019  ieeexplore.ieee.org;;"… B. Oracles Oracles are trusted entities that provide data reflecting the state of the world beyond

the blockchain … Dedicated data feeds [35], [22] build on existing blockchain platforms or create

dedicated oracle networks (eg, ChainLink, Witnet) that internally run consensus …";Cité 17 fois;Les 6 versions;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/8938397/8946120/08946197.pdf?casa_token=FtcWROSMoicAAAAA:__RnpNSYPWXEfTrBmLrF7OLbzVGVEp-qhJqlz0rmzc3nPGG7kvqyzYYKwIDSLCi6ifXP47on9iI;;"""og:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""twitter:title"",""A Security Reference Architecture for Blockchains""
""twitter:card"",""summary""
""Description"",""Due to their specific features, blockchains have become popular in recent years. Blockchains are layered systems where security is a critical factor for their s""
""og:title"",""A Security Reference Architecture for Blockchains""
""resourceName"",""08946197.pdf""
""language"",""en""
""title"",""A Security Reference Architecture for Blockchains | IEEE Conference Publication | IEEE Xplore""
""og:description"",""Due to their specific features, blockchains have become popular in recent years. Blockchains are layered systems where security is a critical factor for their success. The main focus of this work is to systematize knowledge about security and privacy issues of blockchains. To this end, we propose a security reference architecture based on models that demonstrate the stacked hierarchy of various threats as well as threat-risk assessment using ISO/IEC 15408. In contrast to the previous surveys [23], [88], [11], we focus on the categorization of security vulnerabilities based on their origins and using the proposed architecture we present existing prevention and mitigation techniques. The scope of our work mainly covers aspects related to the nature of blockchains, while we mention operational security issues and countermeasures only tangentially.""
""twitter:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-UA-Compatible"",""IE=Edge""
""viewport"",""width=device-width, initial-scale=1.0""
""dc:title"",""A Security Reference Architecture for Blockchains | IEEE Conference Publication | IEEE Xplore""
""twitter:description"",""Due to their specific features, blockchains have become popular in recent years. Blockchains are layered systems where security is a critical factor for their success. The main focus of this work is to systematize knowledge about security and privacy issues of blockchains. To this end, we propose a security reference architecture based on models that demonstrate the stacked hierarchy of various threats as well as threat-risk assessment using ISO/IEC 15408. In contrast to the previous surveys [23], [88], [11], we focus on the categorization of security vulnerabilities based on their origins and using the proposed architecture we present existing prevention and mitigation techniques. The scope of our work mainly covers aspects related to the nature of blockchains, while we mention operational security issues and countermeasures only tangentially.""
""Content-Encoding"",""UTF-8""
""Content-Type-Hint"",""text/html; charset=utf-8""
""Content-Length"",""40129""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=200&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093452-183;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Blockchain in Software Architecture;X Xu, I Weber, M Staples ; Architecture for Blockchain Applications, 2019  Springer;;"… Some blockchain platforms provide direct support for oracles, while in other

blockchain platforms, an oracle is an independent external service that

interacts with the blockchain through normal transactions …";Cité 6 fois;;null;;;;https://scholar.google.com/scholar?start=20&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093502-400;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Blockchain-enabled decentralized trust management and secure usage control of iot big data;M Zhaofeng, W Lingyun, W Xiaochang… ; IEEE Internet of …, 2019  ieeexplore.ieee.org;;"… ZHAOFENG et al.: BLOCKCHAIN-ENABLED DECENTRALIZED TRUST MANAGEMENT AND

SECURE USAGE CONTROL OF IoT BIG DATA … based encryp- tion from the Weil pairing [37] and

proved security in the IND-ID-CPA condition under the random oracle model (ROM …";Cité 7 fois;;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/6488907/6702522/08936349.pdf?casa_token=ij8dtxWC9OQAAAAA:0-yAzkyp71OMKKFj6RboYQ3h08f_IIUy93X_CEamseGpRBw7PYcxZYZdlm_PmAPmLP30kUNGo28;;"""og:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""twitter:title"",""Blockchain-Enabled Decentralized Trust Management and Secure Usage Control of IoT Big Data""
""twitter:card"",""summary""
""Description"",""With the fast development of Internet-of-Things (IoT) technologies, IoT big data and its applications are getting more and more useful. However, traditional IoT""
""og:title"",""Blockchain-Enabled Decentralized Trust Management and Secure Usage Control of IoT Big Data""
""resourceName"",""08936349.pdf""
""language"",""en""
""title"",""Blockchain-Enabled Decentralized Trust Management and Secure Usage Control of IoT Big Data | IEEE Journals & Magazine | IEEE Xplore""
""og:description"",""With the fast development of Internet-of-Things (IoT) technologies, IoT big data and its applications are getting more and more useful. However, traditional IoT data management is fragile and vulnerable. Once the gathered data are untrusted or the stored data are tampered with deliberately from the internal users or attacked by an external hacker, then the tampered data have a serious problem to be utilized. To solve the problems of trust and security of IoT big data management, in this article, we propose a permissioned blockchain-based decentralized trust management and secure usage control scheme of IoT big data (called BlockBDM), upon which all the data operations and management, such as data gathering, invoking, transfer, storage, and usage, are processed over the blockchain smart contract. To encourage the IoT client to supply high-quality content, in our scheme, we design public-blockchain-based tokens reward mechanism for the high-quality data supply contribution. All the data processing and usage procedure can be recorded in a cryptography-signed and Merkle tree-based transaction(s) and block(s) with high-level security in a global and distributed ledger with tamper resistance. For data utilization and consumption, we propose secure usage control for digital rights management and token-based data consumption approach of high-value data from being violated or spread without any limitation. We implemented the BlockBDM scheme based on public and permissioned blockchain for IoT big data management. Finally, a large amount of evaluation manifests that the proposed BlockBDM scheme is feasible, secure, and scalable for decentralized trust management of IoT big data.""
""twitter:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-UA-Compatible"",""IE=Edge""
""viewport"",""width=device-width, initial-scale=1.0""
""dc:title"",""Blockchain-Enabled Decentralized Trust Management and Secure Usage Control of IoT Big Data | IEEE Journals & Magazine | IEEE Xplore""
""twitter:description"",""With the fast development of Internet-of-Things (IoT) technologies, IoT big data and its applications are getting more and more useful. However, traditional IoT data management is fragile and vulnerable. Once the gathered data are untrusted or the stored data are tampered with deliberately from the internal users or attacked by an external hacker, then the tampered data have a serious problem to be utilized. To solve the problems of trust and security of IoT big data management, in this article, we propose a permissioned blockchain-based decentralized trust management and secure usage control scheme of IoT big data (called BlockBDM), upon which all the data operations and management, such as data gathering, invoking, transfer, storage, and usage, are processed over the blockchain smart contract. To encourage the IoT client to supply high-quality content, in our scheme, we design public-blockchain-based tokens reward mechanism for the high-quality data supply contribution. All the data processing and usage procedure can be recorded in a cryptography-signed and Merkle tree-based transaction(s) and block(s) with high-level security in a global and distributed ledger with tamper resistance. For data utilization and consumption, we propose secure usage control for digital rights management and token-based data consumption approach of high-value data from being violated or spread without any limitation. We implemented the BlockBDM scheme based on public and permissioned blockchain for IoT big data management. Finally, a large amount of evaluation manifests that the proposed BlockBDM scheme is feasible, secure, and scalable for decentralized trust management of IoT big data.""
""Content-Encoding"",""UTF-8""
""Content-Type-Hint"",""text/html; charset=utf-8""
""Content-Length"",""45970""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=230&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093502-393;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;[CITATION][C] Uma data verification mechanism: Adding economic guarantees to blockchain oracles;H Lambur, A Lu, R Cai ; Risk Labs, Inc., Tech. Rep., Jul, 2019;;null;Cité 3 fois;;null;;;;https://scholar.google.com/scholar?start=230&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093511-437;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Blendsm-ddm: Blockchain-enabled secure microservices for decentralized data marketplaces;R Xu, GS Ramachandran, Y Chen… ; 2019 IEEE …, 2019  ieeexplore.ieee.org;;"… revocation occurs when an entity explicitly launches a leaving request or the oracle implicitly

rule … 1. Data Pub-sub Payment: The seller and buyer use their blockchain addresses as … The

cryptocurrency based micro- payments protocol is designed to collect data in exchange for …";Cité 7 fois;Les 5 versions;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/9055888/9071638/09071766.pdf?casa_token=c8ztZ5cGowoAAAAA:JzvE6a6ch7jsaClGcglkbsdGbsiEi0-RZqHpmUcfqsR3iHBflCAzNdU9eLIvQrdzkR8kAis-mic;;"""og:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""twitter:title"",""BlendSM-DDM: BLockchain-ENabled Secure Microservices for Decentralized Data Marketplaces""
""twitter:card"",""summary""
""Description"",""To promote the benefits of the Internet of Things (IoT) in smart communities and smart cities, a real-time data marketplace middleware platform, called the Inte""
""og:title"",""BlendSM-DDM: BLockchain-ENabled Secure Microservices for Decentralized Data Marketplaces""
""resourceName"",""09071766.pdf""
""language"",""en""
""title"",""BlendSM-DDM: BLockchain-ENabled Secure Microservices for Decentralized Data Marketplaces | IEEE Conference Publication | IEEE Xplore""
""og:description"",""To promote the benefits of the Internet of Things (IoT) in smart communities and smart cities, a real-time data marketplace middleware platform, called the Intelligent IoT Integrator (I3), has been recently proposed. While facilitating the easy exchanges of real-time IoT data streams between device owners and third-party applications through the marketplace, I3 is presently a monolithic, centralized platform for a single community. Although the service oriented architecture (SOA) has been widely adopted in the IoT and cyber-physical systems (CPS), it is difficult for a monolithic architecture to provide scalable, inter-operable and extensible services for large numbers of distributed IoT devices and different application vendors. Traditional security solutions rely on a centralized authority, which can be a performance bottleneck or susceptible to a single point of failure. Inspired by containerized microservices and blockchain technology, this paper proposed a BLockchain-ENabled Secure Microservices for Decentralized Data Marketplaces (BlendSM-DDM). Within a permissioned blockchain network, a microservices based security mechanism is introduced to secure data exchange and payment among participants in the marketplace. BlendSM-DDM is able to offer a decentralized, scalable and auditable data exchanges for the data marketplace.""
""twitter:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-UA-Compatible"",""IE=Edge""
""viewport"",""width=device-width, initial-scale=1.0""
""dc:title"",""BlendSM-DDM: BLockchain-ENabled Secure Microservices for Decentralized Data Marketplaces | IEEE Conference Publication | IEEE Xplore""
""twitter:description"",""To promote the benefits of the Internet of Things (IoT) in smart communities and smart cities, a real-time data marketplace middleware platform, called the Intelligent IoT Integrator (I3), has been recently proposed. While facilitating the easy exchanges of real-time IoT data streams between device owners and third-party applications through the marketplace, I3 is presently a monolithic, centralized platform for a single community. Although the service oriented architecture (SOA) has been widely adopted in the IoT and cyber-physical systems (CPS), it is difficult for a monolithic architecture to provide scalable, inter-operable and extensible services for large numbers of distributed IoT devices and different application vendors. Traditional security solutions rely on a centralized authority, which can be a performance bottleneck or susceptible to a single point of failure. Inspired by containerized microservices and blockchain technology, this paper proposed a BLockchain-ENabled Secure Microservices for Decentralized Data Marketplaces (BlendSM-DDM). Within a permissioned blockchain network, a microservices based security mechanism is introduced to secure data exchange and payment among participants in the marketplace. BlendSM-DDM is able to offer a decentralized, scalable and auditable data exchanges for the data marketplace.""
""Content-Encoding"",""UTF-8""
""Content-Type-Hint"",""text/html; charset=utf-8""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=270&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093502-394;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;On Refining Design Patterns for Smart Contracts;M Zecchini, A Bracciali, I Chatzigiannakis… ; European Conference on …, 2019  Springer;;"… can reduce the centralization requiring the same information to n independent oracles, but even …

Accessed June 2019. 3. The provabletm blockchain oracle for modern DAPPS (2019) … Dannen,

C.: Introducing Ethereum and Solidity: Foundations of Cryptocurrency and Blockchain …";Autres articles;;[PDF] stir.ac.uk;http://dspace.stir.ac.uk/bitstream/1893/30356/1/main.pdf;;"""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""dc:title"",""302 Found""
""Content-Encoding"",""ISO-8859-1""
""resourceName"",""main.pdf""
""language"",""en""
""Content-Length"",""324""
""title"",""302 Found""
""Content-Type"",""text/html; charset=ISO-8859-1""
";https://scholar.google.com/scholar?start=230&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093490-343;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;The Art of Tokenization: Blockchain Affordances and the Invention of Future Milieus;L Lotti ; Media Theory, 2019  journalcontent.mediatheoryjournal …;;"… woodlands) through a combination of smart contracts, sensors, open-data oracles … which

is captured by an image processing software and transmitted to an oracle, which then submits

this information to the Ethereum blockchain. The project, which …";Cité 1 fois;Les 3 versions;[PDF] mediatheoryjournal.org;http://journalcontent.mediatheoryjournal.org/index.php/mt/article/download/90/80;;"""date"",""2019-08-23T12:43:38Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.7""
""xmp:CreatorTool"",""MicrosoftÂŽ Word 2016""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dc:creator"",""Scott McQuire""
""language"",""en""
""dcterms:created"",""2019-08-23T12:43:38Z""
""Last-Modified"",""2019-08-23T12:43:38Z""
""dcterms:modified"",""2019-08-23T12:43:38Z""
""dc:format"",""application/pdf; version=1.7""
""xmpMM:DocumentID"",""uuid:1DDDED7A-C5D5-4917-9495-08314263D7AF""
""Last-Save-Date"",""2019-08-23T12:43:38Z""
""pdf:docinfo:creator_tool"",""MicrosoftÂŽ Word 2016""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2019-08-23T12:43:38Z""
""meta:save-date"",""2019-08-23T12:43:38Z""
""pdf:encrypted"",""false""
""xmp:CreateDate"",""2019-08-23T14:43:38Z""
""modified"",""2019-08-23T12:43:38Z""
""Content-Length"",""407914""
""pdf:hasMarkedContent"",""true""
""Content-Type"",""application/pdf""
""xmp:ModifyDate"",""2019-08-23T14:43:38Z""
""pdf:docinfo:creator"",""Scott McQuire""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Scott McQuire""
""dc:language"",""fr-FR""
""meta:author"",""Scott McQuire""
""pdf:producer"",""MicrosoftÂŽ Word 2016""
""meta:creation-date"",""2019-08-23T12:43:38Z""
""created"",""2019-08-23T12:43:38Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""34""
""Creation-Date"",""2019-08-23T12:43:38Z""
""resourceName"",""80""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""1979"",""2585"",""2529"",""2686"",""2583"",""2552"",""2509"",""2538"",""2501"",""2693"",""2545"",""2429"",""2603"",""2699"",""2613"",""2715"",""2502"",""2518"",""2532"",""2364"",""2456"",""2603"",""2551"",""2122"",""2088"",""2121"",""2097"",""1979"",""2138"",""3544"",""5092"",""5365"",""3752"",""109""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""Author"",""Scott McQuire""
""producer"",""MicrosoftÂŽ Word 2016""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""MicrosoftÂŽ Word 2016""
""pdf:docinfo:created"",""2019-08-23T12:43:38Z""
";https://scholar.google.com/scholar?start=180&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093497-374;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Design process for applications on blockchain;X Xu, I Weber, M Staples ; Architecture for Blockchain Applications, 2019  Springer;;"… software, the incentive or contractual mechanisms driving the behaviour of processing nodes

that operate the blockchain system, and the trusted third-parties that act as 'oracles' which record …

In a public blockchain, nodes validate that cryptocurrency transfers are from …";Cité 9 fois;;null;;;;https://scholar.google.com/scholar?start=210&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093527-506;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;An Overview on Technical Characteristics of Blockchain Platforms;Z Moezkarimi, R Nourmohammadi, S Zamani… ; … Congress on High …, 2019  Springer;;"… Then, “crypto 3.0” is appeared based on approaches to move around the existing limitation to

mainstream adoption such as … Thus, the need for using external data should be addressed in the

early steps of blockchain design, or the possibility of using Oracles should be …";Autres articles;;null;;;;https://scholar.google.com/scholar?start=340&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093539-553;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Building Own Blockchain;A Mujagi?, M Gheorghe, E Džini? ; Proceedings of the 20th International …, 2019  dl.acm.org;;"… The interconnection and data movement between the two blockchains is performed by oracles

[5] (see also eg … Ouroboros: A provably secure proof-of-stake blockchain protocol. In J. Katz and

H. Shacham, editors, Advances in Cryptology – CRYPTO 2017, pages 357–388, Cham …";Autres articles;;[PDF] acm.org;https://dl.acm.org/doi/pdf/10.1145/3366626.3368126?casa_token=Z1RlCw6WvuUAAAAA:RFMMgKZXX3euKoJQxYxlvkw84lZF4ky3CU_tsP9YM5tiN_u470usqMdiEWMCcNfmoZFC8Y24wMg;;;https://scholar.google.com/scholar?start=390&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093490-350;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Blockchain-based scalable and tamper-evident solution for registering energy data;C Pop, M Antal, T Cioara, I Anghel, D Sera, I Salomie… ; Sensors, 2019  mdpi.com;;"… As seen in Table 1, the blockchain databases, such as BigchainDB, seem to be the most suitable

solution because they allow for … providing smart contracts capabilities must be considered that

can fetch data from BigchainDB through different mechanisms (eg, Oracles [49]) and …";Cité 19 fois;I Salomie;[PDF] mdpi.com;https://www.mdpi.com/1424-8220/19/14/3033/pdf;;;https://scholar.google.com/scholar?start=180&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093466-250;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;[PDF][PDF] 3e JOURNEE DES DROITS DE LA CONSOMMATION ET DE LA DISTRIBUTION BLOCKCHAIN ET SMART CONTRACTS–DEFIS JURIDIQUES;CET DE LA DISTRIBUTION ; unine.ch;;"… 20 Cf. https://www.ethereum-france.com/les-oracles-lien-entre-la-blockchain-et-le- monde

(derničre consultation le 11.09.2018). 21 CHOULI/GOUJON/LEPORCHER (n. 12), p. 162 s. ;

SCHULZ (n. 12), p. 111 ; HECKMANN/KAULARTZ (n. 10), p. 139. Page 20 …";Autres articles;;[PDF] unine.ch;https://www.unine.ch/files/live/sites/christoph.mueller/files/2018_Mu%CC%88ller_Les-Smart-Contracts-en-droit-des-obligations-suisse_PagesTitre.pdf;;"""date"",""2019-09-06T08:13:48Z""
""pdf:PDFVersion"",""1.6""
""xmp:CreatorTool"",""MicrosoftÂŽ Word 2016""
""pdf:docinfo:title"",""""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""language"",""fr""
""dc:format"",""application/pdf; version=1.6""
""pdf:docinfo:creator_tool"",""MicrosoftÂŽ Word 2016""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""xmp:CreateDate"",""2019-03-25T15:38:09Z""
""modified"",""2019-09-06T08:13:48Z""
""pdf:hasMarkedContent"",""true""
""xmp:ModifyDate"",""2019-09-06T10:13:48Z""
""pdf:docinfo:creator"",""Anne-Sylvie Dupont""
""meta:author"",""Anne-Sylvie Dupont""
""meta:creation-date"",""2019-03-25T14:38:09Z""
""created"",""2019-03-25T14:38:09Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-03-25T14:38:09Z""
""resourceName"",""2018_Mu%CC%88ller_Les-Smart-Contracts-en-droit-des-obligations-suisse_PagesTitre.pdf""
""Author"",""Anne-Sylvie Dupont""
""producer"",""MicrosoftÂŽ Word 2016""
""pdf:docinfo:producer"",""MicrosoftÂŽ Word 2016""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""access_permission:modify_annotations"",""true""
""dc:creator"",""Anne-Sylvie Dupont""
""dcterms:created"",""2019-03-25T14:38:09Z""
""Last-Modified"",""2019-09-06T08:13:48Z""
""dcterms:modified"",""2019-09-06T08:13:48Z""
""title"",""""
""xmpMM:DocumentID"",""uuid:8c15edec-8eee-4571-aef6-7a12b1845bda""
""Last-Save-Date"",""2019-09-06T08:13:48Z""
""pdf:docinfo:modified"",""2019-09-06T08:13:48Z""
""meta:save-date"",""2019-09-06T08:13:48Z""
""Content-Length"",""779493""
""Content-Type"",""application/pdf""
""xmp:MetadataDate"",""2019-09-06T10:13:48Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Anne-Sylvie Dupont""
""pdf:producer"",""MicrosoftÂŽ Word 2016""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""75""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""137"",""0"",""258"",""657"",""1358"",""0"",""396"",""0"",""867"",""803"",""251"",""2271"",""1776"",""2297"",""2216"",""2638"",""2453"",""2584"",""2395"",""2468"",""2337"",""2693"",""2314"",""2271"",""2185"",""2493"",""2214"",""2115"",""2035"",""2211"",""2457"",""2298"",""2317"",""2458"",""2382"",""2014"",""1413"",""2565"",""2186"",""2291"",""2115"",""2440"",""2393"",""2369"",""2115"",""2452"",""2430"",""3592"",""2705"",""2280"",""1980"",""2196"",""2205"",""2237"",""1938"",""2466"",""2385"",""2628"",""2049"",""2252"",""2412"",""2525"",""2423"",""2378"",""2225"",""2116"",""2248"",""1622"",""1741"",""1675"",""1739"",""1754"",""1574"",""1777"",""417""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-03-25T14:38:09Z""
";https://scholar.google.com/scholar?start=80&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093532-528;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;[PDF][PDF] Asset Logging–transparent documentation of asset data using a decentralized platform;A Zeiselmair, M Hinterstocker, A Bogensperger… ; 8th DACH Conference on …, 2019  ffe.de;;"… The integrity of the data is either ensured by trusted sources (ie certified smart meters) or by the

utilization of smart contract oracles. While data on the blockchain is tamper-resilient, querying

outside sources could potentially cause inconsistent states due to minor differences in la …";Cité 1 fois;;[PDF] ffe.de;https://www.ffe.de/attachments/article/970/Paper_Asset_Logging_Energyinformatics_AZeiselmair.pdf;;"""date"",""2019-07-09T07:29:05Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""Poster Abstract: Asset Logging – transparent documentation of asset data using a decentralized platform""
""xmp:CreatorTool"",""LaTeX with hyperref""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""Poster Abstract: Asset Logging – transparent documentation of asset data using a decentralized platform""
""modified"",""2019-07-09T07:29:05Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"","" Andreas Zeiselmair, Michael Hinterstocker, Alexander Bogensperger, Serafin von Roon""
""PTEX.Fullbanner"",""This is MiKTeX-pdfTeX 2.9.7029 (1.40.20)""
""meta:author"","" Andreas Zeiselmair, Michael Hinterstocker, Alexander Bogensperger, Serafin von Roon""
""trapped"",""False""
""meta:creation-date"",""2019-07-09T07:29:05Z""
""created"",""2019-07-09T07:29:05Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-07-09T07:29:05Z""
""resourceName"",""Paper_Asset_Logging_Energyinformatics_AZeiselmair.pdf""
""Author"","" Andreas Zeiselmair, Michael Hinterstocker, Alexander Bogensperger, Serafin von Roon""
""producer"",""pdfTeX-1.40.20""
""pdf:docinfo:producer"",""pdfTeX-1.40.20""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0""
""Keywords"",""asset logging, blockchain, asset management, documentation""
""access_permission:modify_annotations"",""true""
""dc:creator"","" Andreas Zeiselmair, Michael Hinterstocker, Alexander Bogensperger, Serafin von Roon""
""dcterms:created"",""2019-07-09T07:29:05Z""
""Last-Modified"",""2019-07-09T07:29:05Z""
""dcterms:modified"",""2019-07-09T07:29:05Z""
""title"",""Poster Abstract: Asset Logging – transparent documentation of asset data using a decentralized platform""
""Last-Save-Date"",""2019-07-09T07:29:05Z""
""pdf:docinfo:keywords"",""asset logging, blockchain, asset management, documentation""
""pdf:docinfo:modified"",""2019-07-09T07:29:05Z""
""meta:save-date"",""2019-07-09T07:29:05Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is MiKTeX-pdfTeX 2.9.7029 (1.40.20)""
""Content-Length"",""351196""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"","" Andreas Zeiselmair, Michael Hinterstocker, Alexander Bogensperger, Serafin von Roon""
""dc:subject"",""asset logging, blockchain, asset management, documentation""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""4""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""2299"",""1807"",""1940"",""3829""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""asset logging, blockchain, asset management, documentation""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-07-09T07:29:05Z""
";https://scholar.google.com/scholar?start=360&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093518-466;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;An analysis of blockchain consistency in asynchronous networks: Deriving a neat bound;J Zhao, J Tang, L Zengxiang, H Wang, KY Lam… ; arXiv preprint arXiv …, 2019  arxiv.org;;"… Each honest player has a current view of the blockchain and aims to build blocks at the end of …

players have access to a random function H : {0, 1}? ? {0, 1}? through the following two oracles.

First, H(x) simply outputs H(x). Second, the verification oracle H.ver(x, y) outputs 1 if …";Cité 3 fois;Les 3 versions;[PDF] arxiv.org;https://arxiv.org/pdf/1909.06587;;"""date"",""2020-03-16T00:34:08Z""
""pdf:PDFVersion"",""1.4""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.4""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""xmp:CreateDate"",""2020-03-15T20:34:08Z""
""modified"",""2020-03-16T00:34:08Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""xmp:ModifyDate"",""2020-03-15T20:34:08Z""
""pdf:docinfo:creator"",""""
""meta:author"",""""
""meta:creation-date"",""2020-03-16T00:34:08Z""
""created"",""2020-03-16T00:34:08Z""
""xmp:About"",""uuid:65bcff74-9f3a-11f5-0000-351573811714""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-03-16T00:34:08Z""
""resourceName"",""1909.06587""
""Author"",""""
""producer"",""dvips + GPL Ghostscript GIT PRERELEASE 9.22""
""pdf:docinfo:producer"",""dvips + GPL Ghostscript GIT PRERELEASE 9.22""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""10"",""54"",""44"",""23"",""11"",""20"",""3"",""35"",""72"",""45"",""91"",""70"",""28""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2020-03-16T00:34:08Z""
""Last-Modified"",""2020-03-16T00:34:08Z""
""dcterms:modified"",""2020-03-16T00:34:08Z""
""title"",""""
""xmpMM:DocumentID"",""uuid:65bcff74-9f3a-11f5-0000-351573811714""
""Last-Save-Date"",""2020-03-16T00:34:08Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2020-03-16T00:34:08Z""
""meta:save-date"",""2020-03-16T00:34:08Z""
""Content-Length"",""1516055""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""17""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""5069"",""3957"",""5261"",""4568"",""4430"",""4288"",""4109"",""4397"",""4243"",""5058"",""6327"",""3843"",""2810"",""3248"",""2698"",""2995"",""1184""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-03-16T00:34:08Z""
";https://scholar.google.com/scholar?start=300&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093520-474;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;[PDF][PDF] IMMUTABILITY, FRIEND OR FOE: AN ANALYSIS OF SMART CONTRACTS AGAINST THE FUNDAMENTALS OF CONTRACT LAW;C Walker ;2019 researchgate.net;;"… Page 10. 9 } }”31 A more complicated smart contract may contain elements such as oracles. In

simple terms, an oracle is an 'off-chain' external third party which provides verification of

information to the blockchain which then influences the way in which the transactions …";Autres articles;Version HTML;[PDF] researchgate.net;https://www.researchgate.net/profile/Cat_Walker/project/Smart-Contracts-6/attachment/5de52e20cfe4a777d4f6a412/AS:831685318942723@1575300640471/download/Walker_Final+Draft.pdf?context=ProjectUpdatesLog;;;https://scholar.google.com/scholar?start=310&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093492-352;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;The role of blockchain technologies in construction engineering project management;V Hargaden, N Papakostas, A Newell… ; … and Innovation (ICE …, 2019  ieeexplore.ieee.org;;"… records of digital property, timestamping acts or transactions, multi-signature transactions, smart

contracts and smart oracles [30] … These blockchains can be registered on a 'global' blockchain,

meaning that the contracts can be collateralised using cryptocurrency [36] …";Cité 14 fois;;null;;;;https://scholar.google.com/scholar?start=190&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093476-290;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Blockchain technologies for smart energy systems: Fundamentals, challenges, and solutions;NU Hassan, C Yuen, D Niyato ; IEEE Industrial Electronics …, 2019  ieeexplore.ieee.org;;"… port for nondeterministic smart con- tracts (T2) through oracles is not yet available. Tendermint

Tendermint is another application-ori- ented framework that can be used to set up a public,

consortium, or private TABLE 2 – A REVIEW OF THE BLOCKCHAIN PLATFORMS USED …";Cité 33 fois;Les 4 versions;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/4154573/8939274/08939186.pdf?casa_token=oLdtuzAr4sEAAAAA:KJgr3EffyxG_Xt0GHjzkRAWAji8qQYLIv5dA87GxmKtPBTrnoKmlDTDUf2_vr2eNZq7JVlY-NFo;;"""og:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""twitter:title"",""Blockchain Technologies for Smart Energy Systems: Fundamentals, Challenges, and Solutions""
""twitter:card"",""summary""
""Description"",""In this article, we discuss the integration of the blockchain into smart energy systems. We present various blockchain technology solutions, review important bl""
""og:title"",""Blockchain Technologies for Smart Energy Systems: Fundamentals, Challenges, and Solutions""
""resourceName"",""08939186.pdf""
""language"",""en""
""title"",""Blockchain Technologies for Smart Energy Systems: Fundamentals, Challenges, and Solutions | IEEE Journals & Magazine | IEEE Xplore""
""og:description"",""In this article, we discuss the integration of the blockchain into smart energy systems. We present various blockchain technology solutions, review important blockchain platforms, and describe several blockchain -based smart energy projects in different domains. The majority of blockchain platforms with embedded combination of blockchain technology solutions are computing- and resource -intensive and, hence, are not entirely suitable for smart energy applications. We consider the requirements of smart energy systems and accordingly identify appropriate blockchain technology solutions for smart energy applications. Our analysis can help in the development of flexible blockchain platforms for smart energy systems.""
""twitter:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-UA-Compatible"",""IE=Edge""
""viewport"",""width=device-width, initial-scale=1.0""
""dc:title"",""Blockchain Technologies for Smart Energy Systems: Fundamentals, Challenges, and Solutions | IEEE Journals & Magazine | IEEE Xplore""
""twitter:description"",""In this article, we discuss the integration of the blockchain into smart energy systems. We present various blockchain technology solutions, review important blockchain platforms, and describe several blockchain -based smart energy projects in different domains. The majority of blockchain platforms with embedded combination of blockchain technology solutions are computing- and resource -intensive and, hence, are not entirely suitable for smart energy applications. We consider the requirements of smart energy systems and accordingly identify appropriate blockchain technology solutions for smart energy applications. Our analysis can help in the development of flexible blockchain platforms for smart energy systems.""
""Content-Encoding"",""UTF-8""
""Content-Type-Hint"",""text/html; charset=utf-8""
""Content-Length"",""41701""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=120&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093450-174;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Controlling robots using artificial intelligence and a consortium blockchain;V Lopes, LA Alexandre, N Pereira ; arXiv preprint arXiv:1903.00660, 2019  arxiv.org;;"… where ImageAnalysis() is the information that the trusted Oracle (trusted in the sense that only

it can … a modular architecture, it is possible to insert new modules that can either serve as Oracles

and do … An overview of blockchain integration with robotics and artificial intelligence …";Cité 15 fois;Les 4 versions;[PDF] arxiv.org;https://arxiv.org/pdf/1903.00660;;"""date"",""2019-03-05T02:56:11Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2019-03-05T02:56:11Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016) kpathsea version 6.2.2""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2019-03-05T02:56:11Z""
""created"",""2019-03-05T02:56:11Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-03-05T02:56:11Z""
""resourceName"",""1903.00660""
""Author"",""""
""producer"",""pdfTeX-1.40.17""
""pdf:docinfo:producer"",""pdfTeX-1.40.17""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""2"",""0"",""0"",""0"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2019-03-05T02:56:11Z""
""Last-Modified"",""2019-03-05T02:56:11Z""
""dcterms:modified"",""2019-03-05T02:56:11Z""
""title"",""""
""Last-Save-Date"",""2019-03-05T02:56:11Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2019-03-05T02:56:11Z""
""meta:save-date"",""2019-03-05T02:56:11Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016) kpathsea version 6.2.2""
""Content-Length"",""1091790""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""15""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""1883"",""2584"",""2086"",""2457"",""1643"",""2540"",""275"",""1271"",""2349"",""2188"",""1762"",""2049"",""1815"",""1614"",""1639""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-03-05T02:56:11Z""
";https://scholar.google.com/scholar?start=10&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093490-348;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Towards A Unified Programming Model for Blockchain Smart Contract dApp Systems;J Ellul, G Pace ; 2019 38th International Symposium on …, 2019  ieeexplore.ieee.org;;"… application based systems typically involves writing code for various plat- forms, from the smart

contract code residing on the underlying distributed ledger technology implementation to back

end oracles and front end … Keywords-Blockchain, Smart Contracts, Programming …";Autres articles;;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/8936051/8939707/08939852.pdf?casa_token=tasvWFfg-x0AAAAA:AuUY6Y8X2cQ7iNHffJhnwYADopXP4t1acRIakXIYCY9YYJEepHuD46dZelkvRrxEdNRoSlNVxsQ;;"""og:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""twitter:title"",""Towards A Unified Programming Model for Blockchain Smart Contract dApp Systems""
""twitter:card"",""summary""
""Description"",""Developing smart contract decentralised application based systems typically involves writing code for various platforms, from the smart contract code residing o""
""og:title"",""Towards A Unified Programming Model for Blockchain Smart Contract dApp Systems""
""resourceName"",""08939852.pdf""
""language"",""en""
""title"",""Towards A Unified Programming Model for Blockchain Smart Contract dApp Systems | IEEE Conference Publication | IEEE Xplore""
""og:description"",""Developing smart contract decentralised application based systems typically involves writing code for various platforms, from the smart contract code residing on the underlying distributed ledger technology implementation to back end oracles and front end websites or mobile apps. In addition to the different technologies used for the different parts, the programmer is also burdened with implementing communication channels between the various parts. In this paper we propose a unified programming model allowing for developers to build such systems through a single code artifact, using a macroprogramming approach.""
""twitter:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-UA-Compatible"",""IE=Edge""
""viewport"",""width=device-width, initial-scale=1.0""
""dc:title"",""Towards A Unified Programming Model for Blockchain Smart Contract dApp Systems | IEEE Conference Publication | IEEE Xplore""
""twitter:description"",""Developing smart contract decentralised application based systems typically involves writing code for various platforms, from the smart contract code residing on the underlying distributed ledger technology implementation to back end oracles and front end websites or mobile apps. In addition to the different technologies used for the different parts, the programmer is also burdened with implementing communication channels between the various parts. In this paper we propose a unified programming model allowing for developers to build such systems through a single code artifact, using a macroprogramming approach.""
""Content-Encoding"",""UTF-8""
""Content-Type-Hint"",""text/html; charset=utf-8""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=180&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093534-538;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;[PDF][PDF] Blockchain technology & recordkeeping;VL Lemieux, D Hofman, D Batista… ; ARMA International …, 2019  armaedfoundation.org;;"… transferring a unit of cryptocurrency or ownership of a piece of property to someone else,

they … secure means to access capabilities outside a blockchain system, such as trusted

data sources, like oracles, or functions, such as data storage.53 …";Cité 8 fois;Les 3 versions;[PDF] armaedfoundation.org;http://armaedfoundation.org/wp-content/uploads/2019/06/AIEF-Research-Paper-Blockchain-Technology-Recordkeeping.pdf;;"""date"",""2019-06-03T16:41:56Z""
""pdf:PDFVersion"",""1.5""
""xmp:CreatorTool"",""Acrobat PDFMaker 17 for Word""
""pdf:docinfo:title"",""""
""Company"",""""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""ZOTERO_PREF_1"",""<data data-version=""""3"""" zotero-version=""""5.0.64""""><session id=""""NU4QloPP""""/><style id=""""http://www.zotero.org/styles/chicago-fullnote-bibliography"""" locale=""""en-US"""" hasBibliography=""""1"""" bibliographyStyleHasBeenSet=""""1""""/><prefs><pref name=""""fieldType"""" value=""""Field""""/>""
""language"",""en""
""ZOTERO_PREF_2"",""<pref name=""""automaticJournalAbbreviations"""" value=""""true""""/><pref name=""""noteType"""" value=""""2""""/></prefs></data>""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""Acrobat PDFMaker 17 for Word""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""xmp:CreateDate"",""2019-06-03T10:41:21Z""
""modified"",""2019-06-03T16:41:56Z""
""pdf:docinfo:custom:SourceModified"",""D:20190603163943""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""true""
""xmp:ModifyDate"",""2019-06-03T10:41:56Z""
""pdf:docinfo:creator"",""Microsoft Office User""
""meta:author"",""Microsoft Office User""
""meta:creation-date"",""2019-06-03T16:41:21Z""
""created"",""2019-06-03T16:41:21Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-06-03T16:41:21Z""
""resourceName"",""AIEF-Research-Paper-Blockchain-Technology-Recordkeeping.pdf""
""pdf:docinfo:custom:Comments"",""""
""Author"",""Microsoft Office User""
""producer"",""Adobe PDF Library 15.0""
""pdf:docinfo:producer"",""Adobe PDF Library 15.0""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""pdf:docinfo:custom:ZOTERO_PREF_2"",""<pref name=""""automaticJournalAbbreviations"""" value=""""true""""/><pref name=""""noteType"""" value=""""2""""/></prefs></data>""
""pdf:docinfo:custom:ZOTERO_PREF_1"",""<data data-version=""""3"""" zotero-version=""""5.0.64""""><session id=""""NU4QloPP""""/><style id=""""http://www.zotero.org/styles/chicago-fullnote-bibliography"""" locale=""""en-US"""" hasBibliography=""""1"""" bibliographyStyleHasBeenSet=""""1""""/><prefs><pref name=""""fieldType"""" value=""""Field""""/>""
""dc:creator"",""Microsoft Office User""
""dcterms:created"",""2019-06-03T16:41:21Z""
""Last-Modified"",""2019-06-03T16:41:56Z""
""dcterms:modified"",""2019-06-03T16:41:56Z""
""title"",""""
""xmpMM:DocumentID"",""uuid:419e478f-da28-406d-bf0b-1e3b951c2f29""
""Last-Save-Date"",""2019-06-03T16:41:56Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2019-06-03T16:41:56Z""
""meta:save-date"",""2019-06-03T16:41:56Z""
""Content-Length"",""2030383""
""Content-Type"",""application/pdf""
""xmp:MetadataDate"",""2019-06-03T10:41:56Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Microsoft Office User""
""dc:language"",""EN-US""
""pdf:producer"",""Adobe PDF Library 15.0""
""dc:subject"",""""
""Comments"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""139""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""299"",""1734"",""20"",""2225"",""1295"",""1750"",""2825"",""1666"",""1990"",""2152"",""1836"",""1497"",""2841"",""2797"",""2678"",""2785"",""2619"",""1015"",""604"",""1756"",""2758"",""2489"",""2595"",""2635"",""2410"",""1308"",""1282"",""1119"",""2745"",""2334"",""2706"",""841"",""2458"",""1494"",""1114"",""2716"",""1846"",""2631"",""2613"",""2762"",""1104"",""2589"",""2737"",""2585"",""2112"",""2184"",""2589"",""1576"",""528"",""2526"",""2641"",""2606"",""2644"",""2628"",""2644"",""1460"",""1966"",""2417"",""2457"",""2617"",""2589"",""261"",""1291"",""1715"",""1118"",""2019"",""1531"",""2737"",""2767"",""2798"",""2074"",""1977"",""2028"",""1545"",""2462"",""2758"",""2844"",""2848"",""2874"",""2735"",""2007"",""2699"",""2596"",""1507"",""2547"",""2513"",""2584"",""2820"",""2792"",""2359"",""2525"",""2580"",""2435"",""913"",""2043"",""2643"",""2760"",""2758"",""2864"",""2723"",""158"",""1462"",""2255"",""2038"",""2357"",""2424"",""2569"",""1977"",""1463"",""3106"",""3224"",""3102"",""3080"",""3078"",""3158"",""2997"",""3322"",""3869"",""3312"",""2642"",""3203"",""3205"",""1130"",""2894"",""3267"",""3173"",""3102"",""3056"",""3229"",""2516"",""1477"",""2240"",""2635"",""3110"",""2192"",""1324"",""547"",""2656"",""797""
""access_permission:extract_content"",""true""
""pdf:docinfo:custom:Company"",""""
""access_permission:can_print"",""true""
""SourceModified"",""D:20190603163943""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-06-03T16:41:21Z""
";https://scholar.google.com/scholar?start=370&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093480-307;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Identity management and access control based on blockchain under edge computing for the industrial internet of things;Y Ren, F Zhu, J Qi, J Wang, AK Sangaiah ; Applied Sciences, 2019  mdpi.com;;"… To solve the problem, in this paper, blockchain-based identity management combining access

control mechanism is designed under edge computing … 4. Identity Management and Access

Control Based on Blockchain under Edge Computing for IIoT …";Cité 25 fois;Les 5 versions;[PDF] mdpi.com;https://www.mdpi.com/2076-3417/9/10/2058/pdf;;;https://scholar.google.com/scholar?start=140&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093520-472;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;A tree structure-based blockchain;T Lin, M Dong, C Jing ; Proceedings of the 2019 4th International …, 2019  dl.acm.org;;"… 8, no. 1, pp. 32–37, Jan. 2019. [10] H. Albreiki, L. Alqassem, K. Salah, MH Rehman,

and D. Svetinovi c. (2019). “Decentralized Access Control for IoT Using Blockchain and

Trusted Oracles.” [Online]. Available: https://www.researchgate …";Autres articles;;[PDF] acm.org;https://dl.acm.org/doi/pdf/10.1145/3378065.3378136?casa_token=KUTJV-mLcPIAAAAA:nvidEgprwfLDlp8hEK7y7sPpZQ9gnZ9jfxtiTlctWj-XmmdXZ6d1_RL1Zerj-sKexyzbOdh0LvQ;;;https://scholar.google.com/scholar?start=310&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093518-463;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;[CITATION][C] A new anti-quantum proxy blind signature for blockchain-enabled Internet of Things;C Li, G Xu, Y Chen, H Ahmad, J Li ; Comput. Mater. Continua, 2019;;null;Cité 10 fois;;null;;;;https://scholar.google.com/scholar?start=300&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093520-471;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;[PDF][PDF] Fully auditable privacy-preserving cryptocurrency against malicious auditors;W Li, Y Wang, L Chen, X Lai, X Zhang, J Xin ;2019 pdfs.semanticscholar.org;;"… There are also privacy-preserving blockchain systems such as Qiusqius[15], Zether[6] with different

commitments and range proofs … breaking the security of the schemes, in fact, the adversaries

are allowed to query the four oracles below: ? c ? RO(a). Random oracle, on input …";Cité 1 fois;Les 2 versions;[PDF] semanticscholar.org;https://pdfs.semanticscholar.org/4c2e/dec88cc00769d11e4059a2a8da9282312fd4.pdf;;"""citation_publication_date"",""2020""
""og:image"",""https://www.semanticscholar.org/img/semantic_scholar_og.png""
""citation_title"",""Fully Auditable Privacy-preserving Cryptocurrency Against Malicious Auditors""
""og:image:width"",""1110""
""twitter:card"",""summary_large_image""
""msapplication-square70x70logo"",""https://cdn.semanticscholar.org/86e6c2539915adc9/img/mstile-70x70.png""
""citation_journal_title"",""""
""description"",""Privacy protection techniques have been thoroughly studied in the current blockchain research field with the famous representatives such as Monero and Zerocash, which have realized fully anonymous and confidential transactions. However, lack of audit can lead to abuse of privacy, and can help bad guys to conduct illegal activities, such as money laundering, transfer of illegal assets, illegal transactions, etc. Therefore, it is crucial to study the privacy-preserving cryptocurrency with full auditability. In this paper, under the framework similar to Monero, we propose FAPC, a fully auditable privacy-preserving cryptocurrency with security against malicious auditors. FAPC mainly consists of three schemes: a traceable and linkable ring signature scheme (TLRS), a traceable range proof (TRP), and a tracing scheme for long-term address (TSLA). In FAPC, the identities of UTXOs, transaction amounts and the corresponding long-term addresses can be traced by the auditor with maintaining anonymous and confidential to others. The constructions of TLRS and TRP are simple and modular, which only use standard ring signature as component, without any additional one-time signatures or zero-knowledge proofs. The TSLA is constructed by usage of standard ring signature and ElGamal encryption to realize traceability of long-term addresses in transactions. Moreover, all the schemes are secure against malicious auditors to realize a closer approach towards decentralization. We also give the security proofs and implementations of our schemes, as well as the performance results.""
""msapplication-wide310x150logo"",""https://cdn.semanticscholar.org/86e6c2539915adc9/img/mstile-310x150.png""
""language"",""en""
""title"",""[PDF] Fully Auditable Privacy-preserving Cryptocurrency Against Malicious Auditors | Semantic Scholar""
""og:description"",""Privacy protection techniques have been thoroughly studied in the current blockchain research field with the famous representatives such as Monero and Zerocash, which have realized fully anonymous and confidential transactions. However, lack of audit can lead to abuse of privacy, and can help bad guys to conduct illegal activities, such as money laundering, transfer of illegal assets, illegal transactions, etc. Therefore, it is crucial to study the privacy-preserving cryptocurrency with full auditability. In this paper, under the framework similar to Monero, we propose FAPC, a fully auditable privacy-preserving cryptocurrency with security against malicious auditors. FAPC mainly consists of three schemes: a traceable and linkable ring signature scheme (TLRS), a traceable range proof (TRP), and a tracing scheme for long-term address (TSLA). In FAPC, the identities of UTXOs, transaction amounts and the corresponding long-term addresses can be traced by the auditor with maintaining anonymous and confidential to others. The constructions of TLRS and TRP are simple and modular, which only use standard ring signature as component, without any additional one-time signatures or zero-knowledge proofs. The TSLA is constructed by usage of standard ring signature and ElGamal encryption to realize traceability of long-term addresses in transactions. Moreover, all the schemes are secure against malicious auditors to realize a closer approach towards decentralization. We also give the security proofs and implementations of our schemes, as well as the performance results.""
""og:image:secure_url"",""https://www.semanticscholar.org/img/semantic_scholar_og.png"",""https://www.semanticscholar.org/img/semantic_scholar_og.png""
""twitter:image"",""https://www.semanticscholar.org/img/semantic_scholar_og.png"",""https://www.semanticscholar.org/img/semantic_scholar_og.png""
""twitter:site"",""@allenai_org""
""msapplication-square310x310logo"",""https://cdn.semanticscholar.org/86e6c2539915adc9/img/mstile-310x310.png""
""dc:title"",""[PDF] Fully Auditable Privacy-preserving Cryptocurrency Against Malicious Auditors | Semantic Scholar""
""Content-Encoding"",""UTF-8""
""robots"",""noarchive,noindex""
""Content-Type"",""text/html; charset=UTF-8""
""s2-ui-version"",""2cfb8f55a25a62a824f97b333bd41eb95e1e3822""
""application-name"","" ""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""twitter:title"",""[PDF] Fully Auditable Privacy-preserving Cryptocurrency Against Malicious Auditors | Semantic Scholar""
""og:type"",""website""
""og:title"",""[PDF] Fully Auditable Privacy-preserving Cryptocurrency Against Malicious Auditors | Semantic Scholar""
""citation_author"",""W. Li"",""Yongcan Wang"",""Lei Chen"",""Xin Lai"",""X. Zhang"",""J. Xin""
""og:image:height"",""582""
""resourceName"",""dec88cc00769d11e4059a2a8da9282312fd4.pdf""
""msapplication-square150x150logo"",""https://cdn.semanticscholar.org/86e6c2539915adc9/img/mstile-150x150.png""
""msapplication-TileColor"",""#FFFFFF""
""viewport"",""width=device-width,initial-scale=1""
""twitter:description"",""Privacy protection techniques have been thoroughly studied in the current blockchain research field with the famous representatives such as Monero and Zerocash, which have realized fully anonymous and confidential transactions. However, lack of audit can lead to abuse of privacy, and can help bad guys to conduct illegal activities, such as money laundering, transfer of illegal assets, illegal transactions, etc. Therefore, it is crucial to study the privacy-preserving cryptocurrency with full auditability. In this paper, under the framework similar to Monero, we propose FAPC, a fully auditable privacy-preserving cryptocurrency with security against malicious auditors. FAPC mainly consists of three schemes: a traceable and linkable ring signature scheme (TLRS), a traceable range proof (TRP), and a tracing scheme for long-term address (TSLA). In FAPC, the identities of UTXOs, transaction amounts and the corresponding long-term addresses can be traced by the auditor with maintaining anonymous and confidential to others. The constructions of TLRS and TRP are simple and modular, which only use standard ring signature as component, without any additional one-time signatures or zero-knowledge proofs. The TSLA is constructed by usage of standard ring signature and ElGamal encryption to realize traceability of long-term addresses in transactions. Moreover, all the schemes are secure against malicious auditors to realize a closer approach towards decentralization. We also give the security proofs and implementations of our schemes, as well as the performance results.""
""og:locale"",""en_US"",""en_US""
""Content-Language"",""en""
""msapplication-TileImage"",""https://cdn.semanticscholar.org/86e6c2539915adc9/img/mstile-144x144.png""
";https://scholar.google.com/scholar?start=310&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093466-244;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Security Analysis of Auctionity: a blockchain based e-auction;P Lafourcade, M Nopere, J Picot, D Pizzuti… ; … on Foundations and …, 2019  Springer;;"… Unlike blockchain, Oracle is not decentralized … 3.4 Validity. Auctionity is based in

two blockchain networks: ACNET and ELNET. They do not have a direct

communication channel and use the Oracle to exchange information …";Cité 4 fois;Les 9 versions;[PDF] archives-ouvertes.fr;https://hal.archives-ouvertes.fr/hal-02412800/document;;"""date"",""2019-08-01T20:43:15Z""
""pdf:PDFVersion"",""1.4""
""xmp:CreatorTool"",""LaTeX with hyperref""
""pdf:docinfo:title"",""Security Analysis of Auctionity: a blockchain based e-auction""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""Computer Science [cs]/Cryptography and Security [cs.CR]""
""language"",""en""
""dc:format"",""application/pdf; version=1.4""
""pdf:docinfo:creator_tool"",""HAL""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""Security Analysis of Auctionity: a blockchain based e-auction""
""xmp:CreateDate"",""2019-08-01T22:43:15Z""
""modified"",""2019-08-01T20:43:15Z""
""cp:subject"",""Computer Science [cs]/Cryptography and Security [cs.CR]""
""pdf:docinfo:subject"",""Computer Science [cs]/Cryptography and Security [cs.CR]""
""pdf:hasMarkedContent"",""false""
""xmp:ModifyDate"",""2019-08-01T22:43:15Z""
""pdf:docinfo:creator"",""Pascal Lafourcade, Mike Nopere, JĂŠrĂŠmy Picot, Daniela Pizzuti, Etienne Roudeix""
""meta:author"",""""
""meta:creation-date"",""2021-04-17T18:53:59Z""
""created"",""2021-04-17T18:53:59Z""
""xmp:About"",""uuid:88ecb449-ecb9-11f4-0000-21551c47d2a2""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2021-04-17T18:53:59Z""
""resourceName"",""document""
""Author"",""""
""producer"",""PDFLaTeX""
""pdf:docinfo:producer"",""PDFLaTeX""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""1"",""6"",""7"",""12"",""8"",""12"",""0"",""2"",""2"",""0"",""2"",""0"",""0""
""Keywords"",""Blockchain, Security, E-auction, ProVerif""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2021-04-17T18:53:59Z""
""Last-Modified"",""2019-08-01T20:43:15Z""
""dcterms:modified"",""2019-08-01T20:43:15Z""
""title"",""Security Analysis of Auctionity: a blockchain based e-auction""
""xmpMM:DocumentID"",""uuid:88ecb449-ecb9-11f4-0000-21551c47d2a2""
""Last-Save-Date"",""2019-08-01T20:43:15Z""
""pdf:docinfo:keywords"",""Blockchain, Security, E-auction, ProVerif""
""pdf:docinfo:modified"",""2019-08-01T20:43:15Z""
""meta:save-date"",""2019-08-01T20:43:15Z""
""Content-Length"",""350190""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""pdf:producer"",""dvips + GPL Ghostscript 9.27""
""dc:subject"",""Blockchain, Security, E-auction, ProVerif""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""17""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""910"",""2282"",""2843"",""2510"",""1487"",""2562"",""2190"",""1941"",""1988"",""1802"",""2565"",""2314"",""2210"",""2363"",""1521"",""2127"",""2470""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""meta:keyword"",""Blockchain, Security, E-auction, ProVerif""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2021-04-17T18:53:59Z""
";https://scholar.google.com/scholar?start=80&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093457-209;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Blockchain-based architecture: a MAS proposal for efficient agri-food supply chains;Y Mezquita, A González;Briones…  … Symposium on Ambient …, 2019  Springer;;"… Prieto, J., De la Prieta, F., Corchado, JM: How blockchain improves the supply chain: case study

alimentary supply chain. Procedia Comput. Sci. 134, 393–398 (2018)CrossRefGoogle Scholar.

23. Curran, B.: What are Oracles? Smart Contracts, Chainlink & “The Oracle Problem” …";Cité 15 fois;;null;;;;https://scholar.google.com/scholar?start=40&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093462-223;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Blockchain patterns;X Xu, I Weber, M Staples ; Architecture for Blockchain Applications, 2019  Springer;;"… policies can also specify M-of-N validation constraints, to act as platform-supported distributed

oracles … can change the ownership of physical assets without any associated transaction being

recorded on the blockchain. Related Patterns Reverse oracle (Section 7.1.2) …";Cité 3 fois;;null;;;;https://scholar.google.com/scholar?start=60&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093494-362;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;[PDF][PDF] BLOCKCHAIN SOLUTIONS FOR PEER-TO-PEER ELECTRICITY TRANSACTIONS;SV OPREA, AI ANDREESCU, A BELCIU ; researchgate.net;;"… References [1] V. Buterin, “On Public and Private Blockchains. Ethereum Blog”, Crypto

Renaissance Salon … [10] Oracle Blockchain Platform Resources. Internet: https://www.oracle.

com/ro/cloud/blockchain/resources.html#videos [Mar. 1, 2019] …";Autres articles;;[PDF] researchgate.net;https://www.researchgate.net/profile/Simona_Oprea2/publication/335380719_BLOCKCHAIN_SOLUTIONS_FOR_PEER-TO-PEER_ELECTRICITY_TRANSACTION/links/5dadabd692851c577eb9562b/BLOCKCHAIN-SOLUTIONS-FOR-PEER-TO-PEER-ELECTRICITY-TRANSACTION.pdf;;;https://scholar.google.com/scholar?start=200&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093457-205;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Blockchain technology: a review of the current challenges of cryptocurrency;D Valdeolmillos, Y Mezquita… ; … Congress on Blockchain …, 2019  Springer;;"… ACM, November 2018Google Scholar. 19. Casado-Vara, R., Prieto, J., De la Prieta, F., Corchado,

JM: How blockchain improves the supply chain: Case study alimentary supply chain. Proc … Curran,

B.: What are Oracles? Smart Contracts, Chainlink & “The Oracle Problem” …";Cité 30 fois;Les 3 versions;null;;;;https://scholar.google.com/scholar?start=40&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093506-419;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Anforderungsanalyse für eine Kollaborationsplattform in Blockchain-basierten Wertschöpfungsnetzwerken;LV Herm, C Janiesch ;2019 opus.bibliothek.uniwuerzburg.de;;"… eine Kollaborationsplattform in Blockchain-basierten Wertschöpfungsnetzwerken … of the Institute

of Citation / Zitation dieser Publikation: Herm, L.-V.; Janiesch, C. (2019): Anforderungsanalyse

für eine Kollaborationsplattform in Blockchain-basierten Wertschöpfungsnetzwerken …";Cité 1 fois;Les 2 versions;[PDF] uni-wuerzburg.de;https://opus.bibliothek.uni-wuerzburg.de/files/18886/WPS_BWL_Heft7_Herm_Janiesch.pdf;;"""date"",""2019-10-22T13:19:31Z""
""pdf:PDFVersion"",""1.7""
""xmp:CreatorTool"",""MicrosoftÂŽ Word 2016""
""pdf:docinfo:title"",""Anforderungsanalyse fĂźr eine Kollaborationsplattform in Blockchain-basierten WertschĂśpfungsnetzwerken""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""Requirements analysis for a collaborative platform in blockchain-based supply chain networks""
""pdfa:PDFVersion"",""A-3b""
""xmpMM:History:Action"",""converted""
""language"",""de""
""dc:format"",""application/pdf; version=""""A-3b"""""",""application/pdf; version=1.7""
""pdf:docinfo:creator_tool"",""MicrosoftÂŽ Word 2016""
""access_permission:fill_in_form"",""true""
""xmpMM:History:When"",""2019-10-22T15:19:31Z""
""pdf:encrypted"",""false""
""dc:title"",""Anforderungsanalyse fĂźr eine Kollaborationsplattform in Blockchain-basierten WertschĂśpfungsnetzwerken""
""xmp:CreateDate"",""2019-10-21T14:48:53Z""
""modified"",""2019-10-22T13:19:31Z""
""cp:subject"",""Requirements analysis for a collaborative platform in blockchain-based supply chain networks""
""xmpMM:History:SoftwareAgent"",""Preflight""
""pdf:docinfo:subject"",""Requirements analysis for a collaborative platform in blockchain-based supply chain networks""
""pdf:hasMarkedContent"",""true""
""xmpMM:History:InstanceID"",""uuid:07cb616c-3e1b-4d26-a550-f7093dce9cc5""
""xmp:ModifyDate"",""2019-10-22T15:19:31Z""
""pdf:docinfo:creator"",""Lukas-Valentin Herm""
""meta:author"",""Lukas-Valentin Herm"",""Christian Janiesch""
""meta:creation-date"",""2019-10-21T12:48:53Z""
""created"",""2019-10-21T12:48:53Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-10-21T12:48:53Z""
""resourceName"",""WPS_BWL_Heft7_Herm_Janiesch.pdf""
""pdfaid:part"",""3""
""Author"",""Lukas-Valentin Herm"",""Christian Janiesch""
""producer"",""MicrosoftÂŽ Word 2016""
""pdf:docinfo:producer"",""MicrosoftÂŽ Word 2016""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""dc:description"",""Requirements analysis for a collaborative platform in blockchain-based supply chain networks""
""Keywords"",""Blockchain; Supply Chain Management; WertschĂśpfungsnetzwerke; Plattform"",""Blockchain; Supply Chain Management; WertschĂśpfungsnetzwerke; Plattform""
""access_permission:modify_annotations"",""true""
""dc:creator"",""Lukas-Valentin Herm"",""Christian Janiesch""
""description"",""Requirements analysis for a collaborative platform in blockchain-based supply chain networks""
""dcterms:created"",""2019-10-21T12:48:53Z""
""Last-Modified"",""2019-10-22T13:19:31Z""
""dcterms:modified"",""2019-10-22T13:19:31Z""
""title"",""Anforderungsanalyse fĂźr eine Kollaborationsplattform in Blockchain-basierten WertschĂśpfungsnetzwerken""
""xmpMM:DocumentID"",""uuid:3ea555f7-2651-49ad-98d3-35a8ec8180b2""
""Last-Save-Date"",""2019-10-22T13:19:31Z""
""pdf:docinfo:keywords"",""Blockchain; Supply Chain Management; WertschĂśpfungsnetzwerke; Plattform""
""pdf:docinfo:modified"",""2019-10-22T13:19:31Z""
""meta:save-date"",""2019-10-22T13:19:31Z""
""Content-Length"",""7333747""
""Content-Type"",""application/pdf""
""xmp:MetadataDate"",""2019-10-22T15:19:31Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Lukas-Valentin Herm"",""Christian Janiesch""
""pdfaid:conformance"",""B""
""dc:language"",""de-DE""
""pdf:producer"",""MicrosoftÂŽ Word 2016""
""dc:subject"",""Blockchain; Supply Chain Management; WertschĂśpfungsnetzwerke; Plattform"",""Blockchain; Supply Chain Management; WertschĂśpfungsnetzwerke; Plattform""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""170""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""258"",""1444"",""3760"",""470"",""2992"",""1552"",""2490"",""1094"",""2686"",""2871"",""1875"",""2630"",""2802"",""2171"",""2618"",""2583"",""1806"",""3217"",""3064"",""2426"",""2865"",""2479"",""1985"",""2889"",""3078"",""3367"",""2946"",""2377"",""3308"",""3129"",""3301"",""3058"",""2309"",""2488"",""2235"",""2776"",""1557"",""3209"",""2361"",""2418"",""1978"",""1848"",""1986"",""2852"",""2933"",""3283"",""2598"",""3261"",""3315"",""2943"",""3201"",""966"",""2619"",""2170"",""2090"",""1321"",""2677"",""2937"",""2982"",""3140"",""3055"",""803"",""2728"",""2428"",""3325"",""3130"",""3103"",""3211"",""3049"",""3118"",""3013"",""2880"",""2957"",""3030"",""3050"",""3026"",""3361"",""3339"",""3140"",""2965"",""2959"",""2294"",""2006"",""2267"",""2844"",""2776"",""2746"",""2711"",""2504"",""2411"",""2615"",""2546"",""2507"",""2160"",""1886"",""1355"",""2443"",""1887"",""2397"",""2577"",""1203"",""1556"",""3228"",""2705"",""1447"",""2669"",""3173"",""2904"",""2083"",""3225"",""2409"",""3144"",""3218"",""1637"",""2407"",""2465"",""2393"",""2440"",""2403"",""2426"",""2354"",""2413"",""2473"",""2449"",""2466"",""2458"",""2347"",""2483"",""2575"",""2307"",""2427"",""2665"",""1657"",""3507"",""1703"",""3719"",""1303"",""1225"",""888"",""140"",""111"",""111"",""111"",""111"",""111"",""111"",""111"",""111"",""111"",""111"",""111"",""111"",""111"",""111"",""111"",""111"",""110"",""184"",""111"",""111"",""111"",""111"",""111"",""111"",""111"",""111"",""111"",""111"",""111"",""109""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""meta:keyword"",""Blockchain; Supply Chain Management; WertschĂśpfungsnetzwerke; Plattform"",""Blockchain; Supply Chain Management; WertschĂśpfungsnetzwerke; Plattform""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-10-21T12:48:53Z""
";https://scholar.google.com/scholar?start=250&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093448-164;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;A novel blockchain oracle implementation scheme based on application specific knowledge engines;S Wang, H Lu, X Sun, Y Yuan… ; 2019 IEEE International …, 2019  ieeexplore.ieee.org;;"In blockchain ecosystems, an Oracle is a service tool which provides real-world data for 
smart contracts and other blockchain applications. At present, there are several Oracle 
implementation schemes, eg centralized Oracles, decentralized Oracles, and hardware …";Cité 4 fois;Les 2 versions;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/8945268/8954999/08955107.pdf?casa_token=B5MlG6zwuwMAAAAA:eVtLUap1xyMrwNrUe1TdXhojTNIRyKc7bpbp0sO1ZcPUA2bc9pVX6l5mHHYA6hnQXTZmM6rnZ70;;"""og:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""twitter:title"",""A Novel Blockchain Oracle Implementation Scheme Based on Application Specific Knowledge Engines""
""twitter:card"",""summary""
""Description"",""In blockchain ecosystems, an Oracle is a service tool which provides real-world data for smart contracts and other blockchain applications. At present, there ar""
""og:title"",""A Novel Blockchain Oracle Implementation Scheme Based on Application Specific Knowledge Engines""
""resourceName"",""08955107.pdf""
""language"",""en""
""title"",""A Novel Blockchain Oracle Implementation Scheme Based on Application Specific Knowledge Engines | IEEE Conference Publication | IEEE Xplore""
""og:description"",""In blockchain ecosystems, an Oracle is a service tool which provides real-world data for smart contracts and other blockchain applications. At present, there are several Oracle implementation schemes, e.g. centralized Oracles, decentralized Oracles, and hardware Oracles. However, these schemes typically suffer from single source of data and low scalability. Application Specific Knowledge Engine (ASKE) is an integrated topic/application-centered knowledge portal that supports effective information retrieval and analysis. Inspired by ASKE, in this paper, we propose a novel Oracle implementation scheme. The proposed scheme can realize multi-source data extraction and analysis, then working prototypes are demonstrated to show the validity of the scheme.""
""twitter:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-UA-Compatible"",""IE=Edge""
""viewport"",""width=device-width, initial-scale=1.0""
""dc:title"",""A Novel Blockchain Oracle Implementation Scheme Based on Application Specific Knowledge Engines | IEEE Conference Publication | IEEE Xplore""
""twitter:description"",""In blockchain ecosystems, an Oracle is a service tool which provides real-world data for smart contracts and other blockchain applications. At present, there are several Oracle implementation schemes, e.g. centralized Oracles, decentralized Oracles, and hardware Oracles. However, these schemes typically suffer from single source of data and low scalability. Application Specific Knowledge Engine (ASKE) is an integrated topic/application-centered knowledge portal that supports effective information retrieval and analysis. Inspired by ASKE, in this paper, we propose a novel Oracle implementation scheme. The proposed scheme can realize multi-source data extraction and analysis, then working prototypes are demonstrated to show the validity of the scheme.""
""Content-Encoding"",""UTF-8""
""Content-Type-Hint"",""text/html; charset=utf-8""
""Content-Length"",""40871""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";
1619093471-270;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Achieving intelligent trust-layer for Internet-of-Things via self-redactable blockchain;K Huang, X Zhang, Y Mu… ; IEEE Transactions …, 2019  ieeexplore.ieee.org;;"… on SRB without any helps or breaking the consis- tency of hash in the blockchain … RCH

(paramRCH,ych,t) Here, oracle Oetd RCH is as previously defined; oracle OHash&Forge on …

RCH(xch,ˇˇˇ ) paramRCH,ych,t) where H1 and Oetd RCH are random oracles and corresponding …";Cité 7 fois;Les 2 versions;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/9424/4389054/08848417.pdf?casa_token=8VySrDf-UD8AAAAA:JoKztgPvxGYpeVWfgrjp-cQRu4kHRgtsy-fv04cUcN3u0oeRfsdqx6l1L2kJsuxaq0PfBxy1XiE;;"""og:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""twitter:title"",""Achieving Intelligent Trust-Layer for Internet-of-Things via Self-Redactable Blockchain""
""twitter:card"",""summary""
""Description"",""The advances of artificial intelligence (AI) propels big data processing and transmission for Internet of Things (IoT), by capturing and structuring big data pr""
""og:title"",""Achieving Intelligent Trust-Layer for Internet-of-Things via Self-Redactable Blockchain""
""resourceName"",""08848417.pdf""
""language"",""en""
""title"",""Achieving Intelligent Trust-Layer for Internet-of-Things via Self-Redactable Blockchain | IEEE Journals & Magazine | IEEE Xplore""
""og:description"",""The advances of artificial intelligence (AI) propels big data processing and transmission for Internet of Things (IoT), by capturing and structuring big data produced by heterogeneous devices. While applying blockchain to manage IoT devices and associated big data, the blockchain itself suffers from abuse of decentralization from anonymous users. Specifically, it has been utilized to facilitate black market trades and illegal activities. Ateniese et al. proposed using the chameleon hash (CH) to derive redactable blockchain (EuroS&P), which works by embedding a trapdoor in the basic hash function so that block content can be rewritten without causing major hard forks. In short, the redacted block hash remains unchanged. However, there is lacking intelligent design where any mistakes observed in the chain can be corrected universally and automatically. This creates disincentives to use redactable blockchain (RB) for managing big data or any data-driven business mainly due to ineffective chain redaction. To solve this problem, in this article, we propose the notion of the self-redactable blockchain (SRB) to support intelligent execution of chain redaction. Specifically, we propose the first revocable chameleon hash (RCH) to power RB. It enables an ephemeral trapdoor for finding collision without any co-operation. Periodical expiration is applied to committed hash and an ephemeral trapdoor to prevent any abuses of redaction power. We instantiate how to use our RCH to build SRB as an intelligent trust-layer for IoT. We also give a rigorous analysis as well as comprehensive experiments to validate our proposals. The evidence showed that our proposal is secure and acceptably efficient for IoT devices.""
""twitter:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-UA-Compatible"",""IE=Edge""
""viewport"",""width=device-width, initial-scale=1.0""
""dc:title"",""Achieving Intelligent Trust-Layer for Internet-of-Things via Self-Redactable Blockchain | IEEE Journals & Magazine | IEEE Xplore""
""twitter:description"",""The advances of artificial intelligence (AI) propels big data processing and transmission for Internet of Things (IoT), by capturing and structuring big data produced by heterogeneous devices. While applying blockchain to manage IoT devices and associated big data, the blockchain itself suffers from abuse of decentralization from anonymous users. Specifically, it has been utilized to facilitate black market trades and illegal activities. Ateniese et al. proposed using the chameleon hash (CH) to derive redactable blockchain (EuroS&P), which works by embedding a trapdoor in the basic hash function so that block content can be rewritten without causing major hard forks. In short, the redacted block hash remains unchanged. However, there is lacking intelligent design where any mistakes observed in the chain can be corrected universally and automatically. This creates disincentives to use redactable blockchain (RB) for managing big data or any data-driven business mainly due to ineffective chain redaction. To solve this problem, in this article, we propose the notion of the self-redactable blockchain (SRB) to support intelligent execution of chain redaction. Specifically, we propose the first revocable chameleon hash (RCH) to power RB. It enables an ephemeral trapdoor for finding collision without any co-operation. Periodical expiration is applied to committed hash and an ephemeral trapdoor to prevent any abuses of redaction power. We instantiate how to use our RCH to build SRB as an intelligent trust-layer for IoT. We also give a rigorous analysis as well as comprehensive experiments to validate our proposals. The evidence showed that our proposal is secure and acceptably efficient for IoT devices.""
""Content-Encoding"",""UTF-8""
""Content-Type-Hint"",""text/html; charset=utf-8""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=100&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093466-243;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Multi-agent architecture for peer-to-peer electricity trading based on blockchain technology;Y Mezquita, AS Gazafroudi… ; 2019 XXVII …, 2019  ieeexplore.ieee.org;;"… The elements of the platform which insert data from the real world into the blockchain are

called oracles. In this platform, the ESP32 modules are the ones with that role, storing the

data the sensors associated to them are reading from the real world …";Cité 10 fois;Les 2 versions;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/8932650/8938684/08938926.pdf?casa_token=L7lkoO7S58kAAAAA:3AzsvBBi-HNQ7q34O0naxaU7b0W9LiBZ4IHseAPVQOrrz-eu2B77GXgQ-mFm-g-AebkVBCFB9r4;;"""og:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""twitter:title"",""Multi-Agent Architecture for Peer-to-Peer Electricity Trading based on Blockchain Technology""
""twitter:card"",""summary""
""Description"",""The security of smart grids is put at risk due to their automation and remote access features. Blockchain technology can be used as a distributed ledger where d""
""og:title"",""Multi-Agent Architecture for Peer-to-Peer Electricity Trading based on Blockchain Technology""
""resourceName"",""08938926.pdf""
""language"",""en""
""title"",""Multi-Agent Architecture for Peer-to-Peer Electricity Trading based on Blockchain Technology | IEEE Conference Publication | IEEE Xplore""
""og:description"",""The security of smart grids is put at risk due to their automation and remote access features. Blockchain technology can be used as a distributed ledger where data is stored and all the data transactions between the different entities of a smart grid are signed to protect them from such attacks. This paper proposes a multi-agent system (MAS) that combines smart contracts and blockchain to enable Peer-to-Peer electricity trading in a MicroGrid (MG) scenario, without the need for human intervention. The use of blockchain technology helps reduce transaction costs and allows to make micro transactions in the proposed market. Blockchain also improves the security of the platform because all the involved actors can be certain about the authorship of the information produced in the system. Finally, the use of a MAS and the possibility of negotiating between the agents helps obtain an optimal state in the system in which the costs of energy are minimal and the local production of energy is profitable.""
""twitter:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-UA-Compatible"",""IE=Edge""
""viewport"",""width=device-width, initial-scale=1.0""
""dc:title"",""Multi-Agent Architecture for Peer-to-Peer Electricity Trading based on Blockchain Technology | IEEE Conference Publication | IEEE Xplore""
""twitter:description"",""The security of smart grids is put at risk due to their automation and remote access features. Blockchain technology can be used as a distributed ledger where data is stored and all the data transactions between the different entities of a smart grid are signed to protect them from such attacks. This paper proposes a multi-agent system (MAS) that combines smart contracts and blockchain to enable Peer-to-Peer electricity trading in a MicroGrid (MG) scenario, without the need for human intervention. The use of blockchain technology helps reduce transaction costs and allows to make micro transactions in the proposed market. Blockchain also improves the security of the platform because all the involved actors can be certain about the authorship of the information produced in the system. Finally, the use of a MAS and the possibility of negotiating between the agents helps obtain an optimal state in the system in which the costs of energy are minimal and the local production of energy is profitable.""
""Content-Encoding"",""UTF-8""
""Content-Type-Hint"",""text/html; charset=utf-8""
""Content-Length"",""42059""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=80&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093534-539;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;[PDF][PDF] 1st Blockchain International Scientific Conference 12 March 2019, London;S Dyson ; jbba.scholasticahq.com;;"… Themes: blockchain, financial intermediation, monitoring the monitor, oracles, information

asymmetry, adverse selection … The benefits of Blockchain technologies in finance are widely

acknowledged but there … In this space, crypto-assets are new financial innovation and have only …";;;[PDF] scholasticahq.com;https://jbba.scholasticahq.com/article/8445.pdf;;"""date"",""2019-06-02T22:05:57Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.4""
""xmp:CreatorTool"",""Adobe InDesign CS6 (Windows)""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dcterms:created"",""2019-05-28T12:30:41Z""
""language"",""en""
""Last-Modified"",""2019-06-02T22:05:57Z""
""dcterms:modified"",""2019-06-02T22:05:57Z""
""dc:format"",""application/pdf; version=1.4""
""xmpMM:DocumentID"",""xmp.id:50E3002A3581E9118D2AA4C9CC0BF276""
""Last-Save-Date"",""2019-06-02T22:05:57Z""
""pdf:docinfo:creator_tool"",""Adobe InDesign CS6 (Windows)""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2019-06-02T22:05:57Z""
""meta:save-date"",""2019-06-02T22:05:57Z""
""pdf:encrypted"",""false""
""xmp:CreateDate"",""2019-05-28T13:30:41Z""
""modified"",""2019-06-02T22:05:57Z""
""pdf:hasMarkedContent"",""true""
""Content-Type"",""application/pdf""
""xmp:ModifyDate"",""2019-06-02T23:05:57Z""
""xmp:MetadataDate"",""2019-06-02T23:05:57Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""pdf:producer"",""Adobe PDF Library 10.0.1""
""trapped"",""False""
""meta:creation-date"",""2019-05-28T12:30:41Z""
""created"",""2019-05-28T12:30:41Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""6""
""Creation-Date"",""2019-05-28T12:30:41Z""
""resourceName"",""8445.pdf""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""3158"",""3737"",""3713"",""3864"",""3834"",""2829""
""access_permission:extract_content"",""true""
""xmpMM:DerivedFrom:DocumentID"",""xmp.did:B40B901251E4E811AF05CFC698326604""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""xmpMM:DerivedFrom:InstanceID"",""xmp.iid:298BB47B1465E911B1DC8699AEA4FD81""
""producer"",""Adobe PDF Library 10.0.1""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""Adobe PDF Library 10.0.1""
""pdf:docinfo:created"",""2019-05-28T12:30:41Z""
";https://scholar.google.com/scholar?start=370&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093532-521;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;[CITATION][C] Iterated Search Problems and Blockchain Security under Falsifiable Assumptions.;JA Garay, A Kiayias, G Panagiotakos ; IACR Cryptol. ePrint Arch., 2019;;null;Cité 3 fois;;null;;;;https://scholar.google.com/scholar?start=360&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093459-220;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Blockchain with IOT: Applications and use cases for a new paradigm of supply chain driving efficiency and cost;A Banerjee ; Advances in Computers, 2019  Elsevier;;"… Some examples of private blockchain networks are Oracle Blockchain Cloud Services developed

on Hyperledger Fabric. 4.1.3. Consortium blockchain network … For example, Oracle Blockchain

Platform Cloud Service is available on per transaction basis [18] …";Cité 14 fois;Les 3 versions;null;;;;https://scholar.google.com/scholar?start=50&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093518-467;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;The 9 Lives of Bleichenbacher's CAT: New Cache ATtacks on TLS Implementations;E Ronen, R Gillham, D Genkin, A Shamir… ; … IEEE Symposium on …, 2019  ieeexplore.ieee.org;;"… Abstract—At CRYPTO'98, Bleichenbacher published his sem- inal paper which described a

padding oracle attack against RSA implementations that follow the PKCS #1 v1.5 standard … One

of the oracles considered in that work is the interval oracle, that indicates if the …";Cité 31 fois;Les 12 versions;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/8826229/8835208/08835216.pdf?casa_token=axVg1yrMMfoAAAAA:BJ7UYygUWMaqf-ixyN_iG90jFbHU99jB6MMYETm6m47smOtlsP6objrZJFGPdkuGGTP4gIiWaF4;;"""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""dc:title"",""IEEE Xplore Full-Text PDF:""
""Content-Encoding"",""UTF-8""
""resourceName"",""08835216.pdf""
""language"",""es""
""Content-Length"",""2533""
""title"",""IEEE Xplore Full-Text PDF:""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=300&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093513-450;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;[LIVRE][B] Blockchain Technologies;A Singh ;2019 books.google.com;;"… Topics include decentralization, mining, the politics of Bitcoin, altcoins and the cryptocurrency

ecosystem, the future of Bitcoin, and more … Well, lets take a crypto valuta like Bitcoin (for more

information on Bitcoin see subsection 3.1.1). The crypto valuta is built on blockchain so it …";Autres articles;;null;;;;https://scholar.google.com/scholar?start=280&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093485-323;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Blockchain and building information modeling (BIM): Review and applications in post-disaster recovery;NO Nawari, S Ravindran ; Buildings, 2019  mdpi.com;;"… In general, three generations of BCT can be distinguished: blockchain 1.0, which covers

applications enabling digital cryptocurrency transactions; blockchain 2.0, which expands

blockchain 1.0 by introduction Smart contracts and a set of applications beyond cryptocurrency …";Cité 28 fois;Les 6 versions;[PDF] mdpi.com;https://www.mdpi.com/2075-5309/9/6/149/pdf;;;https://scholar.google.com/scholar?start=160&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093513-449;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Blockchain Technologies in E-commerce: Social Shopping and Loyalty Program Applications;YH Lim, H Hashim, N Poo, DCC Poo… ; … Conference on Human …, 2019  Springer;;"… Aeternity. Aeternity was established by Yanislav Malahov in 2016 as a scalable blockchain

platform [9]. It enables high bandwidth transactions, smart contracts with built-in oracles. The

state channel and oracle system ensure a high degree of flexibility …";Cité 1 fois;Les 2 versions;[PDF] researchgate.net;https://www.researchgate.net/profile/Hoang_Nguyen228/publication/332977375_Blockchain_Technologies_in_E-commerce_Social_Shopping_and_Loyalty_Program_Applications/links/5cd4e522a6fdccc9dd9c611d/Blockchain-Technologies-in-E-commerce-Social-Shopping-and-Loyalty-Program-Applications.pdf;;;https://scholar.google.com/scholar?start=280&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093511-439;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;[PDF][PDF] Applications of blockchain in procurement;C Martínez Martínez ;2019 core.ac.uk;;"… SAP, GEP, Oracle and Coupa are the most significant and known software. The new trends are

reflecting a new way of managing procurement, through the technologies of industry 4.0 such

as the Internet of Things, Artificial Intelligence, Big Data and Blockchain technology, on …";Cité 1 fois;Les 2 versions;[PDF] core.ac.uk;https://core.ac.uk/download/pdf/232122484.pdf;;"""date"",""2019-08-27T15:15:29Z""
""pdf:PDFVersion"",""1.7""
""xmp:CreatorTool"",""MicrosoftÂŽ Word para Office 365""
""pdf:docinfo:title"",""LICATIONS OF BLOCKCHAIN IN PROCUREMENT""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""language"",""en""
""dc:format"",""application/pdf; version=1.7""
""pdf:docinfo:creator_tool"",""MicrosoftÂŽ Word para Office 365""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""LICATIONS OF BLOCKCHAIN IN PROCUREMENT""
""xmp:CreateDate"",""2019-08-27T17:15:29Z""
""modified"",""2019-08-27T15:15:29Z""
""pdf:hasMarkedContent"",""true""
""xmp:ModifyDate"",""2019-08-27T17:15:29Z""
""pdf:docinfo:creator"",""cristina martinez martinez""
""meta:author"",""cristina martinez martinez""
""meta:creation-date"",""2019-08-27T15:15:29Z""
""created"",""2019-08-27T15:15:29Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-08-27T15:15:29Z""
""resourceName"",""232122484.pdf""
""Author"",""cristina martinez martinez""
""producer"",""MicrosoftÂŽ Word para Office 365""
""pdf:docinfo:producer"",""MicrosoftÂŽ Word para Office 365""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""access_permission:modify_annotations"",""true""
""dc:creator"",""cristina martinez martinez""
""dcterms:created"",""2019-08-27T15:15:29Z""
""Last-Modified"",""2019-08-27T15:15:29Z""
""dcterms:modified"",""2019-08-27T15:15:29Z""
""title"",""LICATIONS OF BLOCKCHAIN IN PROCUREMENT""
""xmpMM:DocumentID"",""uuid:4C097369-AFA8-4B2A-9CD7-AF5D61B57CFB""
""Last-Save-Date"",""2019-08-27T15:15:29Z""
""pdf:docinfo:modified"",""2019-08-27T15:15:29Z""
""meta:save-date"",""2019-08-27T15:15:29Z""
""Content-Length"",""1098765""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""cristina martinez martinez""
""dc:language"",""es-ES""
""pdf:producer"",""MicrosoftÂŽ Word para Office 365""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""68""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""291"",""217"",""1187"",""1180"",""5"",""425"",""1439"",""4"",""3075"",""2298"",""1884"",""382"",""1875"",""1880"",""2121"",""1459"",""1458"",""2656"",""2013"",""2295"",""1473"",""1463"",""1813"",""2000"",""961"",""1602"",""2359"",""1552"",""1548"",""1263"",""1591"",""2645"",""2187"",""2149"",""2247"",""416"",""2218"",""2669"",""1730"",""2539"",""2661"",""1290"",""2125"",""2271"",""2188"",""2239"",""1645"",""1076"",""2574"",""2343"",""2232"",""2359"",""2601"",""2426"",""1777"",""2153"",""1163"",""0"",""1718"",""1894"",""1929"",""1934"",""1949"",""2018"",""2004"",""211"",""1919"",""876""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-08-27T15:15:29Z""
";https://scholar.google.com/scholar?start=270&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093459-219;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;A review on the application of blockchain to the next generation of cybersecure industry 4.0 smart factories;TM Fernandez;Carames, P FragaLamas  Ieee Access, 2019  ieeexplore.ieee.org;;"… Such services are referred to as oracles. For example, an oracle could inspect records to

identify whether an asset has arrived and it could write the arrival information on the

blockchain. Then, VOLUME 2, 2019 5 Page 6. 2169-3536 (c) 2018 IEEE …";Cité 103 fois;Les 6 versions;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/6287639/6514899/08678753.pdf;;"""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""dc:title"",""IEEE Xplore Full-Text PDF:""
""Content-Encoding"",""UTF-8""
""resourceName"",""08678753.pdf""
""language"",""es""
""Content-Length"",""2565""
""title"",""IEEE Xplore Full-Text PDF:""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=50&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093459-211;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Blockchain research in information systems: Current trends and an inclusive future research agenda;M Rossi, C Mueller;Bloch, JB Thatcher…  Journal of the …, 2019  aisel.aisnet.org;;"… 2.1). Agents with a high degree of decision-making power in the consensus protocol

could attack the blockchain by double-spending cryptocurrency, effectively spending

more than they own (Gervais et al., 2016). However, attacks …";Cité 45 fois;Les 12 versions;[PDF] core.ac.uk;https://core.ac.uk/download/pdf/301383052.pdf;;"""date"",""2019-10-19T07:20:09Z""
""pdf:PDFVersion"",""1.7""
""xmp:CreatorTool"",""Appligent pdfHarmony 2.0""
""pdf:docinfo:title"",""Blockchain Research in Information Systems:  Current Trends and an Inclusive Future Research Agenda""
""Appligent"",""pdfHarmony 2.0 Linux Kernel 2.6 64bit Mar 13 2012 Library 9.0.1""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""language"",""en""
""dc:format"",""application/pdf; version=1.7""
""pdf:docinfo:creator_tool"",""Appligent pdfHarmony 2.0""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""Blockchain Research in Information Systems:  Current Trends and an Inclusive Future Research Agenda""
""xmp:CreateDate"",""2019-10-19T00:55:59Z""
""modified"",""2019-10-19T07:20:09Z""
""pdf:hasMarkedContent"",""true""
""xmp:ModifyDate"",""2019-10-19T00:20:09Z""
""pdf:docinfo:creator"",""Matti Rossi, Christoph Mueller-Bloch, Jason Bennett Thatcher, and Roman Beck""
""meta:author"",""Matti Rossi, Christoph Mueller-Bloch, Jason Bennett Thatcher, and Roman Beck""
""meta:creation-date"",""2019-10-19T06:55:59Z""
""created"",""2019-10-19T06:55:59Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-10-19T06:55:59Z""
""resourceName"",""301383052.pdf""
""Author"",""Matti Rossi, Christoph Mueller-Bloch, Jason Bennett Thatcher, and Roman Beck""
""producer"",""MicrosoftÂŽ Word for Office 365""
""pdf:docinfo:producer"",""MicrosoftÂŽ Word for Office 365""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""access_permission:modify_annotations"",""true""
""dc:creator"",""Matti Rossi, Christoph Mueller-Bloch, Jason Bennett Thatcher, and Roman Beck""
""dcterms:created"",""2019-10-19T06:55:59Z""
""Last-Modified"",""2019-10-19T07:20:09Z""
""dcterms:modified"",""2019-10-19T07:20:09Z""
""pdf:docinfo:custom:Appligent"",""pdfHarmony 2.0 Linux Kernel 2.6 64bit Mar 13 2012 Library 9.0.1""
""title"",""Blockchain Research in Information Systems:  Current Trends and an Inclusive Future Research Agenda""
""xmpMM:DocumentID"",""uuid:6333D569-6F71-4E14-BC25-8586E2F226D2""
""Last-Save-Date"",""2019-10-19T07:20:09Z""
""pdf:docinfo:modified"",""2019-10-19T07:20:09Z""
""meta:save-date"",""2019-10-19T07:20:09Z""
""Content-Length"",""343783""
""Content-Type"",""application/pdf""
""xmp:MetadataDate"",""2019-10-19T00:20:09Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Matti Rossi, Christoph Mueller-Bloch, Jason Bennett Thatcher, and Roman Beck""
""dc:language"",""en-US""
""pdf:producer"",""MicrosoftÂŽ Word for Office 365""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""16""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""3116"",""5107"",""5234"",""2696"",""5295"",""5256"",""4862"",""4250"",""4291"",""4908"",""4463"",""2426"",""4160"",""4240"",""3645"",""4332""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-10-19T06:55:59Z""
";https://scholar.google.com/scholar?start=50&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093455-198;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;[HTML][HTML] Parkchain: a blockchain powered parking solution for smart cities;HS Jennath, S Adarsh, NV Chandran… ; … in Blockchain, 2019  frontiersin.org;Switzerland;"… made. 6. Blockchain: Only the important details such as parking data are sent

from the database through an Oracle to the Blockchain. Oracles connect the

traditional database with the Blockchain system. Blockchain …";Cité 8 fois;Les 2 versions;[HTML] frontiersin.org;https://www.frontiersin.org/articles/10.3389/fbloc.2019.00006/full;;"""citation_keywords"",""Blockchain; IoT; Smart city; Land leasing; Ethereum blockchain; Smart contract""
""og:image"",""https://www.frontiersin.org/files/MyHome%20Article%20Library/460168/460168_Thumb_400.jpg""
""citation_publication_date"",""2019/08/28""
""citation_title"",""Parkchain: A Blockchain Powered Parking Solution for Smart Cities""
""citation_author_institution"",""Faculty of Technology, Indian Institute of Information Technology and Management-Kerala, India"",""Faculty of Technology, Cochin University of Science and Technology, India"",""Faculty of Technology, Indian Institute of Information Technology and Management-Kerala, India"",""Faculty of Technology, Cochin University of Science and Technology, India"",""Faculty of Technology, Indian Institute of Information Technology and Management-Kerala, India"",""Faculty of Technology, Cochin University of Science and Technology, India"",""Faculty of Technology, Indian Institute of Information Technology and Management-Kerala, India"",""Faculty of Technology, Cochin University of Science and Technology, India"",""Faculty of Technology, Indian Institute of Information Technology and Management-Kerala, India"",""Faculty of Technology, Cochin University of Science and Technology, India"",""Faculty of Technology, Indian Institute of Information Technology and Management-Kerala, India"",""Faculty of Technology, Cochin University of Science and Technology, India""
""Description"",""With the advances happening in the area of urbanization, with increased demand for dwellings and an increased number of vehicles on road, finding a parking spot has become one of the major pain points for the citizens. This is mainly due to the limited parking spaces available and difficulty in finding a vacant lot during busy hours. To overcome this limitation, one solution is to create smart parking spaces which are rather easier to find and use. In this work, we propose a Blockchain based solution where parking pools can be created by developing a transparent platform where individuals can rent out their unused land for a stipulated amount of time. A non-fungible token system representing unique parking lots will be created for transparency of the entire system. This also has the added advantage of generating revenue from their otherwise unused property. Smart contracts over Blockchain enforce the contractual agreement between the participants ensuring financial transparency in the proposed system.""
""Keywords"",""Blockchain, IoT, Smart city, Land leasing, Ethereum blockchain, Smart contract""
""citation_publisher"",""Frontiers""
""citation_journal_title"",""Frontiers in Blockchain""
""description"",""With the advances happening in the area of urbanization, with increased demand for dwellings and ever growing number of vehicles on road, finding a parking spot has become one of the major pain points for the citizens. This is mainly due to the limited parking spaces in the urban areas. To overcome this limitation, one solution is to create more parking spaces. In this work we propose a Blockchain based solution, where parking pools can be created by developing a transparent platform where individuals can rent out their unused land for a stipulated amount of time with little or no legal hassles. A non-fungible token system representing unique parking lots will be created for transparency of the entire system. This also has the added advantage of generating revenue from their otherwise unused property. Smart contracts over Blockchain enforces the contractual agreement between the participants ensuring financial transparency in the proposed system.""
""language"",""en""
""citation_date"",""2019""
""title"",""Frontiers | Parkchain: A Blockchain Powered Parking Solution for Smart Cities | Blockchain""
""citation_online_date"",""2019/07/08""
""citation_author_email"","""","""","""","""","""",""""
""citation_issn"",""2624-7852""
""dc:title"",""Frontiers | Parkchain: A Blockchain Powered Parking Solution for Smart Cities | Blockchain""
""citation_language"",""English""
""Content-Encoding"",""UTF-8""
""citation_pdf_url"",""https://www.frontiersin.org/articles/10.3389/fbloc.2019.00006/pdf""
""Content-Length"",""154523""
""Content-Type"",""text/html; charset=UTF-8""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""og:type"",""article""
""citation_journal_abbrev"",""Front. Blockchain""
""citation_abstract"",""With the advances happening in the area of urbanization, with increased demand for dwellings and ever growing number of vehicles on road, finding a parking spot has become one of the major pain points for the citizens. This is mainly due to the limited parking spaces in the urban areas. To overcome this limitation, one solution is to create more parking spaces. In this work we propose a Blockchain based solution, where parking pools can be created by developing a transparent platform where individuals can rent out their unused land for a stipulated amount of time with little or no legal hassles. A non-fungible token system representing unique parking lots will be created for transparency of the entire system. This also has the added advantage of generating revenue from their otherwise unused property. Smart contracts over Blockchain enforces the contractual agreement between the participants ensuring financial transparency in the proposed system.""
""citation_author"",""Jennath, H. S."",""Adarsh, S."",""Chandran, Nikhil V."",""Ananthan, R."",""Sabir, A."",""Asharaf, S.""
""Title"",""Parkchain: A Blockchain Powered Parking Solution for Smart Cities""
""resourceName"",""full""
""citation_pages"",""6""
""url"",""https://www.frontiersin.org/article/10.3389/fbloc.2019.00006/full""
""site_name"",""Frontiers""
""X-UA-Compatible"",""IE=edge""
""frontiers:type"",""Article""
""viewport"",""width=device-width, initial-scale=1, maximum-scale=1""
""citation_doi"",""10.3389/fbloc.2019.00006""
""dc.identifier"",""doi:10.3389/fbloc.2019.00006""
""citation_volume"",""2""
""Content-Language"",""en""
";https://scholar.google.com/scholar?start=30&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093525-493;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Trusted artifact-driven process monitoring of multi-party business processes with blockchain;G Meroni, P Plebani, F Vona ; International Conference on Business …, 2019  Springer;;"… also used to evaluate issues related to the cost of public blockchains in terms of cryptocurrency …

to determine the state of the smart objects cannot be formally validated by the blockchain. To

improve this situation, future work will investigate the adoption of oracles to ensure the …";Cité 8 fois;Les 6 versions;[PDF] polimi.it;http://meroni.faculty.polimi.it/wp-content/uploads/BPM-BC-Forum-2019-Presentation.pdf;;"""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""dc:title"",""302 Found""
""Content-Encoding"",""ISO-8859-1""
""resourceName"",""BPM-BC-Forum-2019-Presentation.pdf""
""language"",""en""
""Content-Length"",""270""
""title"",""302 Found""
""Content-Type"",""text/html; charset=ISO-8859-1""
";https://scholar.google.com/scholar?start=330&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093476-284;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;PAChain: Private, Authenticated and Auditable Consortium Blockchain;TH Yuen ; International Conference on Cryptology and Network …, 2019  Springer;;"… PRCash [15] is a centrally-issued cryptocurrency with privacy and auditability … balance if the

discrete logarithm (DL) assumption holds in \(\mathbb {G}_1\) in the random oracle model … In

blockchain, the user address is the hash of his public key, and hence it represents his identity …";Cité 3 fois;Les 2 versions;null;;;;https://scholar.google.com/scholar?start=120&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093532-527;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;??? ?????? ???????? ???????? ?? ? ??? ??;????? ?????? ??? ??? ; Business Review Journal, 2019  so01.tcithaijo.org;;"… technology onto cloud ERP respectively. Keywords: Cloud Computing, ERP, Cloud ERP,

Cloud Migration, Blockchain in Cloud ERP ??? ? … (Chen, Liang and Hsu, 2015, Oracle,

2019) ???????????????????????????????????????????????????? …";Autres articles;Version HTML;[PDF] tci-thaijo.org;https://so01.tci-thaijo.org/index.php/bahcuojs/article/download/198413/138171;;"""date"",""2019-07-02T02:57:58Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.5""
""xmp:CreatorTool"",""Adobe InDesign CS6 (Macintosh)""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dcterms:created"",""2019-07-02T02:57:54Z""
""language"",""th""
""Last-Modified"",""2019-07-02T02:57:58Z""
""dcterms:modified"",""2019-07-02T02:57:58Z""
""dc:format"",""application/pdf; version=1.5""
""xmpMM:DocumentID"",""xmp.id:E7F300AC09206811822AA4535A38A53F""
""Last-Save-Date"",""2019-07-02T02:57:58Z""
""pdf:docinfo:creator_tool"",""Adobe InDesign CS6 (Macintosh)""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2019-07-02T02:57:58Z""
""meta:save-date"",""2019-07-02T02:57:58Z""
""pdf:encrypted"",""false""
""xmp:CreateDate"",""2019-07-02T09:57:54Z""
""modified"",""2019-07-02T02:57:58Z""
""Content-Length"",""588512""
""pdf:hasMarkedContent"",""false""
""Content-Type"",""application/pdf""
""xmp:ModifyDate"",""2019-07-02T09:57:58Z""
""xmp:MetadataDate"",""2019-07-02T09:57:58Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""pdf:producer"",""Adobe PDF Library 10.0.1""
""trapped"",""False""
""meta:creation-date"",""2019-07-02T02:57:54Z""
""created"",""2019-07-02T02:57:54Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""19""
""Creation-Date"",""2019-07-02T02:57:54Z""
""resourceName"",""138171""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""1825"",""2380"",""2189"",""2054"",""2161"",""1607"",""2251"",""2215"",""2141"",""1262"",""2324"",""2039"",""2242"",""2222"",""2030"",""2259"",""1680"",""2238"",""1877""
""access_permission:extract_content"",""true""
""xmpMM:DerivedFrom:DocumentID"",""xmp.did:56971599182068118083E02D22263464""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""xmpMM:DerivedFrom:InstanceID"",""xmp.iid:8E2CD08507206811822AA4535A38A53F""
""producer"",""Adobe PDF Library 10.0.1""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""Adobe PDF Library 10.0.1""
""pdf:docinfo:created"",""2019-07-02T02:57:54Z""
";https://scholar.google.com/scholar?start=360&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093541-569;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Ause case of blockchain technology in the real estate industry for the rental agreement and accessory charge settlement processes;L Wetzel ; Immobilienwirtschaft aktuell 2019, 2019  books.google.com;;"… Participants in the Ethereum blockchain are rewarded with IEther"", a type of crypto toNen that

fuels … that is, an agent enabled to access external information and feed it into the blockchain. The

oracle receives its input from data providers such as NeoVac, Rapp, techem or others …";Autres articles;;[PDF] uzh.ch;https://www.curem.uzh.ch/dam/jcr:945bb1c8-dacf-4e48-8499-da9b9b155b80/Wetzel_Livia_AbAr_Lg17-18.pdf;;"""pdf:docinfo:custom:Mendeley Recent Style Name 1_1"",""American Political Science Association""
""xmp:CreatorTool"",""Acrobat PDFMaker 11 for Word""
""pdf:docinfo:title"",""""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""pdf:docinfo:custom:Mendeley Recent Style Name 5_1"",""Cite Them Right 10th edition - Harvard""
""pdf:docinfo:custom:Mendeley Unique User Id_1"",""34d72432-fc9b-334c-83f5-63ec579da6a5""
""Mendeley Recent Style Name 7_1"",""Modern Humanities Research Association 3rd edition (note with bibliography)""
""dc:format"",""application/pdf; version=1.5""
""Mendeley Citation Style_1"",""http://www.zotero.org/styles/apa""
""pdf:docinfo:creator_tool"",""Acrobat PDFMaker 11 for Word""
""access_permission:fill_in_form"",""true""
""dc:title"",""""
""Mendeley Recent Style Name 3_1"",""American Sociological Association""
""xmp:CreateDate"",""2018-09-04T08:57:40Z""
""Mendeley Recent Style Id 3_1"",""http://www.zotero.org/styles/american-sociological-association""
""pdf:docinfo:custom:SourceModified"",""D:20180904065716""
""cp:subject"",""""
""xmp:ModifyDate"",""2018-09-04T08:58:35Z""
""pdf:docinfo:creator"",""Simone Strebel""
""pdf:docinfo:custom:Mendeley Document_1"",""True""
""meta:creation-date"",""2018-09-04T06:57:40Z""
""Mendeley Recent Style Id 7_1"",""http://www.zotero.org/styles/modern-humanities-research-association""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2018-09-04T06:57:40Z""
""pdf:docinfo:custom:Mendeley Recent Style Id 6_1"",""http://www.zotero.org/styles/ieee""
""pdf:docinfo:custom:Mendeley Recent Style Id 2_1"",""http://www.zotero.org/styles/apa""
""Author"",""Simone Strebel""
""pdf:docinfo:custom:Mendeley Recent Style Name 9_1"",""Nature""
""pdf:docinfo:custom:Mendeley Recent Style Name 2_1"",""American Psychological Association 6th edition""
""access_permission:modify_annotations"",""true""
""pdf:docinfo:custom:Mendeley Recent Style Name 6_1"",""IEEE""
""dc:creator"",""Simone Strebel""
""Mendeley Recent Style Name 8_1"",""Modern Language Association 8th edition""
""Last-Modified"",""2018-09-04T06:58:35Z""
""Mendeley Recent Style Name 0_1"",""American Medical Association""
""Mendeley Recent Style Name 4_1"",""Chicago Manual of Style 17th edition (author-date)""
""Mendeley Recent Style Id 2_1"",""http://www.zotero.org/styles/apa""
""xmp:MetadataDate"",""2018-09-04T08:58:35Z""
""creator"",""Simone Strebel""
""Mendeley Recent Style Id 6_1"",""http://www.zotero.org/styles/ieee""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""74""
""pdf:docinfo:custom:Mendeley Recent Style Id 5_1"",""http://www.zotero.org/styles/harvard-cite-them-right""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""356"",""3130"",""3056"",""1037"",""524"",""1974"",""644"",""2542"",""2747"",""2682"",""2250"",""2398"",""587"",""2675"",""2062"",""2933"",""2579"",""2541"",""2588"",""2324"",""2596"",""3034"",""2629"",""2233"",""1385"",""2283"",""1780"",""2717"",""2670"",""2751"",""2312"",""2028"",""2721"",""2431"",""1538"",""1551"",""1110"",""1675"",""2954"",""1505"",""2927"",""1198"",""2945"",""1857"",""1874"",""207"",""1656"",""192"",""1157"",""2784"",""2549"",""1697"",""2595"",""2165"",""1904"",""2588"",""2275"",""2339"",""2350"",""2826"",""2762"",""2761"",""2541"",""1509"",""1785"",""1834"",""1959"",""1978"",""1849"",""912"",""1576"",""1668"",""257"",""743""
""pdf:docinfo:custom:Mendeley Recent Style Id 1_1"",""http://www.zotero.org/styles/american-political-science-association""
""SourceModified"",""D:20180904065716""
""pdf:docinfo:custom:Mendeley Recent Style Id 9_1"",""http://www.zotero.org/styles/nature""
""access_permission:can_modify"",""true""
""date"",""2018-09-04T06:58:35Z""
""pdf:PDFVersion"",""1.5""
""Company"",""CUREM""
""pdf:docinfo:custom:Mendeley Recent Style Name 3_1"",""American Sociological Association""
""subject"",""""
""pdf:docinfo:custom:Mendeley Recent Style Name 7_1"",""Modern Humanities Research Association 3rd edition (note with bibliography)""
""Mendeley Recent Style Name 9_1"",""Nature""
""language"",""en""
""Mendeley Recent Style Name 1_1"",""American Political Science Association""
""Mendeley Recent Style Name 5_1"",""Cite Them Right 10th edition - Harvard""
""pdf:encrypted"",""false""
""modified"",""2018-09-04T06:58:35Z""
""Mendeley Recent Style Id 5_1"",""http://www.zotero.org/styles/harvard-cite-them-right""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""true""
""Mendeley Recent Style Id 1_1"",""http://www.zotero.org/styles/american-political-science-association""
""pdf:docinfo:custom:Mendeley Recent Style Id 0_1"",""http://www.zotero.org/styles/american-medical-association""
""meta:author"",""Simone Strebel""
""created"",""2018-09-04T06:57:40Z""
""Mendeley Recent Style Id 9_1"",""http://www.zotero.org/styles/nature""
""pdf:docinfo:custom:Mendeley Recent Style Id 8_1"",""http://www.zotero.org/styles/modern-language-association""
""resourceName"",""Wetzel_Livia_AbAr_Lg17-18.pdf""
""pdf:docinfo:custom:Mendeley Recent Style Id 4_1"",""http://www.zotero.org/styles/chicago-author-date""
""producer"",""Adobe PDF Library 11.0""
""pdf:docinfo:producer"",""Adobe PDF Library 11.0""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""Mendeley Document_1"",""True""
""pdf:docinfo:custom:Mendeley Recent Style Name 4_1"",""Chicago Manual of Style 17th edition (author-date)""
""Keywords"",""""
""pdf:docinfo:custom:Mendeley Recent Style Name 8_1"",""Modern Language Association 8th edition""
""dcterms:created"",""2018-09-04T06:57:40Z""
""Mendeley Recent Style Name 6_1"",""IEEE""
""dcterms:modified"",""2018-09-04T06:58:35Z""
""title"",""""
""xmpMM:DocumentID"",""uuid:4e6d82b6-5cb6-4906-b4b0-6e57ea714110""
""Last-Save-Date"",""2018-09-04T06:58:35Z""
""pdf:docinfo:custom:Mendeley Recent Style Name 0_1"",""American Medical Association""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2018-09-04T06:58:35Z""
""meta:save-date"",""2018-09-04T06:58:35Z""
""Mendeley Recent Style Name 2_1"",""American Psychological Association 6th edition""
""Mendeley Recent Style Id 4_1"",""http://www.zotero.org/styles/chicago-author-date""
""Content-Length"",""1636208""
""Mendeley Recent Style Id 0_1"",""http://www.zotero.org/styles/american-medical-association""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""pdf:producer"",""Adobe PDF Library 11.0""
""dc:subject"",""""
""Mendeley Recent Style Id 8_1"",""http://www.zotero.org/styles/modern-language-association""
""pdf:docinfo:custom:Mendeley Recent Style Id 7_1"",""http://www.zotero.org/styles/modern-humanities-research-association""
""access_permission:extract_content"",""true""
""pdf:docinfo:custom:Company"",""CUREM""
""pdf:docinfo:custom:Mendeley Recent Style Id 3_1"",""http://www.zotero.org/styles/american-sociological-association""
""access_permission:can_print"",""true""
""Mendeley Unique User Id_1"",""34d72432-fc9b-334c-83f5-63ec579da6a5""
""meta:keyword"",""""
""pdf:docinfo:custom:Mendeley Citation Style_1"",""http://www.zotero.org/styles/apa""
""pdf:docinfo:created"",""2018-09-04T06:57:40Z""
";https://scholar.google.com/scholar?start=400&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093520-478;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Legal regulation of smart contracts in France;DV Chub ; Actual Problems of Russian Law, 2019  aprp.msal.ru;;"… The importance of the oracle for the implementation of the smart contract and the

features of its legal status under French law are disclosed … 2019. — ? 1. — S.

23—30. 2. Cohen-Hadria Y. Blockchain: révolutionou évolution …";Cité 1 fois;;null;;;;https://scholar.google.com/scholar?start=310&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093457-206;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Blockchain-enabled smart contracts: architecture, applications, and future trends;S Wang, L Ouyang, Y Yuan, X Ni… ; IEEE Transactions on …, 2019  ieeexplore.ieee.org;;"… Oraclize11 is an Oracle service for smart contracts and blockchain applications, which … In addition,

some prediction market platforms, such as Augur12 and Gnosis13 can also serve as Oracles,

as they can pro- vide external information for smart contracts, such as the results …";Cité 250 fois;Les 3 versions;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/6221021/6376248/08643084.pdf?casa_token=_eXbovFY9cEAAAAA:MhNlPCRqvrBQmbk45EHLydPcgIn7N5vTMuUTnEHN7u7MktpUEFANXeyE5VBkJlRPbcZRyVWNXw4;;"""og:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""twitter:title"",""Blockchain-Enabled Smart Contracts: Architecture, Applications, and Future Trends""
""twitter:card"",""summary""
""Description"",""In recent years, the rapid development of cryptocurrencies and their underlying blockchain technology has revived Szabo's original idea of smart contracts, i.e.""
""og:title"",""Blockchain-Enabled Smart Contracts: Architecture, Applications, and Future Trends""
""resourceName"",""08643084.pdf""
""language"",""en""
""title"",""Blockchain-Enabled Smart Contracts: Architecture, Applications, and Future Trends | IEEE Journals & Magazine | IEEE Xplore""
""og:description"",""In recent years, the rapid development of cryptocurrencies and their underlying blockchain technology has revived Szabo's original idea of smart contracts, i.e., computer protocols that are designed to automatically facilitate, verify, and enforce the negotiation and implementation of digital contracts without central authorities. Smart contracts can find a wide spectrum of potential application scenarios in the digital economy and intelligent industries, including financial services, management, healthcare, and Internet of Things, among others, and also have been integrated into the mainstream blockchain-based development platforms, such as Ethereum and Hyperledger. However, smart contracts are still far from mature, and major technical challenges such as security and privacy issues are still awaiting further research efforts. For instance, the most notorious case might be “The DAO Attack” in June 2016, which led to more than $50 million Ether transferred into an adversary's account. In this paper, we strive to present a systematic and comprehensive overview of blockchain-enabled smart contracts, aiming at stimulating further research toward this emerging research area. We first introduced the operating mechanism and mainstream platforms of blockchain-enabled smart contracts, and proposed a research framework for smart contracts based on a novel six-layer architecture. Second, both the technical and legal challenges, as well as the recent research progresses, are listed. Third, we presented several typical application scenarios. Toward the end, we discussed the future development trends of smart contracts. This paper is aimed at providing helpful guidance and reference for future research efforts.""
""twitter:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-UA-Compatible"",""IE=Edge""
""viewport"",""width=device-width, initial-scale=1.0""
""dc:title"",""Blockchain-Enabled Smart Contracts: Architecture, Applications, and Future Trends | IEEE Journals & Magazine | IEEE Xplore""
""twitter:description"",""In recent years, the rapid development of cryptocurrencies and their underlying blockchain technology has revived Szabo's original idea of smart contracts, i.e., computer protocols that are designed to automatically facilitate, verify, and enforce the negotiation and implementation of digital contracts without central authorities. Smart contracts can find a wide spectrum of potential application scenarios in the digital economy and intelligent industries, including financial services, management, healthcare, and Internet of Things, among others, and also have been integrated into the mainstream blockchain-based development platforms, such as Ethereum and Hyperledger. However, smart contracts are still far from mature, and major technical challenges such as security and privacy issues are still awaiting further research efforts. For instance, the most notorious case might be “The DAO Attack” in June 2016, which led to more than $50 million Ether transferred into an adversary's account. In this paper, we strive to present a systematic and comprehensive overview of blockchain-enabled smart contracts, aiming at stimulating further research toward this emerging research area. We first introduced the operating mechanism and mainstream platforms of blockchain-enabled smart contracts, and proposed a research framework for smart contracts based on a novel six-layer architecture. Second, both the technical and legal challenges, as well as the recent research progresses, are listed. Third, we presented several typical application scenarios. Toward the end, we discussed the future development trends of smart contracts. This paper is aimed at providing helpful guidance and reference for future research efforts.""
""Content-Encoding"",""UTF-8""
""Content-Type-Hint"",""text/html; charset=utf-8""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=40&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093452-190;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;An efficient authentication scheme for blockchain-based electronic health records;F Tang, S Ma, Y Xiang, C Lin ; IEEE access, 2019  ieeexplore.ieee.org;;"… Furthermore, our scheme is provably secure in the random oracle model and has more efficient

signing and … Authentication is very important for blockchain-based EHRs. It is different from the

case of cryptocurrency which is anonymous and thus there is no authentication mecha …";Cité 28 fois;Les 3 versions;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/6287639/6514899/08666709.pdf;;"""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""dc:title"",""IEEE Xplore Full-Text PDF:""
""Content-Encoding"",""UTF-8""
""resourceName"",""08666709.pdf""
""language"",""es""
""Content-Length"",""2565""
""title"",""IEEE Xplore Full-Text PDF:""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=20&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093530-511;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Digital platforms: The insurers of the twenty-first century?;A Trescases ; Revue internationale de droit economique, 2019  cairnint.info;;"… However, the trust revolution of blockchain technology may allow the insurer to return to the

forefront, taking on the role of oracle. insurance; trusted third party; distribution; digitalization,

marketplace; co-innovation; regulation; blockchain; oracle. Author …";Les 2 versions;En cache;null;;;;https://scholar.google.com/scholar?start=350&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093523-485;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;[PDF][PDF] Blockchain Technology Potential in the Chemical Industry;PKP SCHUURMANS ; research.tue.nl;;"… 2.4.1 Oracles … Oracle An information arbiter accessed by the smart contract,

providing the information necessary for eventual contract … Off-chain Data Data

that is stored outside of the blockchain with a hash …";Autres articles;;[PDF] tue.nl;https://research.tue.nl/files/129034858/Master_Thesis_Pieter_Schuurmans.pdf;;"""date"",""2019-04-23T21:49:03Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.5""
""xmp:CreatorTool"",""MicrosoftÂŽ Word 2013""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dc:creator"",""Schuurmans, Pieter Karel (P)""
""language"",""en""
""dcterms:created"",""2019-04-23T21:49:03Z""
""Last-Modified"",""2019-04-23T21:49:03Z""
""dcterms:modified"",""2019-04-23T21:49:03Z""
""dc:format"",""application/pdf; version=1.5""
""Last-Save-Date"",""2019-04-23T21:49:03Z""
""pdf:docinfo:creator_tool"",""MicrosoftÂŽ Word 2013""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2019-04-23T21:49:03Z""
""meta:save-date"",""2019-04-23T21:49:03Z""
""pdf:encrypted"",""false""
""modified"",""2019-04-23T21:49:03Z""
""pdf:hasMarkedContent"",""true""
""Content-Type"",""application/pdf""
""pdf:docinfo:creator"",""Schuurmans, Pieter Karel (P)""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Schuurmans, Pieter Karel (P)""
""dc:language"",""nl-NL""
""meta:author"",""Schuurmans, Pieter Karel (P)""
""meta:creation-date"",""2019-04-23T21:49:03Z""
""created"",""2019-04-23T21:49:03Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""144""
""Creation-Date"",""2019-04-23T21:49:03Z""
""resourceName"",""Master_Thesis_Pieter_Schuurmans.pdf""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""1282"",""534"",""329"",""2877"",""4838"",""5143"",""5110"",""4890"",""4757"",""4973"",""2553"",""1450"",""672"",""1479"",""640"",""6058"",""3835"",""2843"",""1692"",""2615"",""2417"",""3373"",""3273"",""3870"",""3292"",""2865"",""2551"",""2247"",""2840"",""3052"",""3919"",""1881"",""2110"",""2118"",""2981"",""3247"",""2681"",""1509"",""4287"",""3003"",""3377"",""3539"",""2975"",""3359"",""3518"",""3010"",""3825"",""2888"",""1860"",""2289"",""2353"",""3682"",""2886"",""3121"",""1797"",""3428"",""3257"",""3689"",""2800"",""3518"",""2519"",""3855"",""3798"",""4068"",""3057"",""3629"",""3586"",""3758"",""3382"",""3640"",""3523"",""3497"",""3359"",""3720"",""3356"",""3451"",""3472"",""3238"",""3371"",""2948"",""3329"",""3443"",""3301"",""3615"",""3802"",""3874"",""3539"",""4130"",""3931"",""3515"",""2980"",""2665"",""2778"",""2848"",""2774"",""2800"",""2935"",""2822"",""2911"",""2769"",""2241"",""3443"",""3562"",""2802"",""650"",""3596"",""3722"",""3316"",""3620"",""3943"",""2885"",""2116"",""1916"",""2270"",""2089"",""2427"",""2154"",""1981"",""2359"",""1920"",""2206"",""2305"",""2042"",""2422"",""1911"",""2424"",""2927"",""1979"",""1771"",""2138"",""1888"",""2221"",""2169"",""2396"",""2133"",""895"",""2350"",""2995"",""2824"",""3285"",""3573"",""3599"",""3686"",""1011""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""Author"",""Schuurmans, Pieter Karel (P)""
""producer"",""MicrosoftÂŽ Word 2013""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""MicrosoftÂŽ Word 2013""
""pdf:docinfo:created"",""2019-04-23T21:49:03Z""
";https://scholar.google.com/scholar?start=320&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093520-477;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Blinker: A blockchain-enabled framework for software provenance;RPJC Bose, KK Phokela, V Kaulgud… ; 2019 26th AsiaPacific …, 2019  ieeexplore.ieee.org;;"… Furthermore, the data services also contain 'oracles' that facilitate communication between smart

contracts and the external world … blockchain applications for data intensive applications as storage

of data on some blockchain platforms like Ethereum cost cryptocurrency …";Cité 3 fois;Les 2 versions;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/8938656/8945519/08945702.pdf?casa_token=H5ptMQvwWTkAAAAA:W72ZlwyWfxJBAJ30op4fbZr2iqV1s6LGAla86WGviDvuTAV-TDWCyiOApH4mStAOA5CPxKX8z90;;"""og:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""twitter:title"",""BLINKER: A Blockchain-Enabled Framework for Software Provenance""
""twitter:card"",""summary""
""Description"",""There has been a considerable shift in the way how software is built and delivered today. Most deployed software systems in modern times are created by (autonom""
""og:title"",""BLINKER: A Blockchain-Enabled Framework for Software Provenance""
""resourceName"",""08945702.pdf""
""language"",""en""
""title"",""BLINKER: A Blockchain-Enabled Framework for Software Provenance | IEEE Conference Publication | IEEE Xplore""
""og:description"",""There has been a considerable shift in the way how software is built and delivered today. Most deployed software systems in modern times are created by (autonomous) distributed teams in heterogeneous environments making use of many artifacts, such as externally developed libraries, drawn from a variety of disparate sources. Stakeholders such as developers, managers, and clients across the software delivery value chain are interested in gaining insights such as how and why an artifact came to where it is, what other artifacts are related to it, and who else is using this. Software provenance encompasses the origins of artifacts, their evolution, and usage and is critical for comprehending, managing, decision-making, and analyzing software quality, processes, people, issues etc. In this paper, we propose an extensible framework based on standard provenance model specifications and blockchain technology for capturing, storing, exploring, and analyzing software provenance data. Our framework (i) enhances trustworthiness of provenance data (ii) uncovers non-trivial insights through inferences and reasoning, and (iii) enables interactive visualization of provenance insights. We demonstrate the utility of the proposed framework using open source project data.""
""twitter:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-UA-Compatible"",""IE=Edge""
""viewport"",""width=device-width, initial-scale=1.0""
""dc:title"",""BLINKER: A Blockchain-Enabled Framework for Software Provenance | IEEE Conference Publication | IEEE Xplore""
""twitter:description"",""There has been a considerable shift in the way how software is built and delivered today. Most deployed software systems in modern times are created by (autonomous) distributed teams in heterogeneous environments making use of many artifacts, such as externally developed libraries, drawn from a variety of disparate sources. Stakeholders such as developers, managers, and clients across the software delivery value chain are interested in gaining insights such as how and why an artifact came to where it is, what other artifacts are related to it, and who else is using this. Software provenance encompasses the origins of artifacts, their evolution, and usage and is critical for comprehending, managing, decision-making, and analyzing software quality, processes, people, issues etc. In this paper, we propose an extensible framework based on standard provenance model specifications and blockchain technology for capturing, storing, exploring, and analyzing software provenance data. Our framework (i) enhances trustworthiness of provenance data (ii) uncovers non-trivial insights through inferences and reasoning, and (iii) enables interactive visualization of provenance insights. We demonstrate the utility of the proposed framework using open source project data.""
""Content-Encoding"",""UTF-8""
""Content-Type-Hint"",""text/html; charset=utf-8""
""Content-Length"",""41869""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=310&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093536-545;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;College fees transaction using hash functions of blockchain model;R Aswini, K Kiruba ; 2019 IEEE International Conference on …, 2019  ieeexplore.ieee.org;;"… It needs the information oracles to access the external information and by owns, it can validate

the connections with the organization, people and assets … [1] Mahdi H. Miraz, Maaruf Ali

“Applications of Blockchain Technology Beyond Cryptocurrency”, Annals of …";Cité 2 fois;;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/8870340/8878677/08878769.pdf?casa_token=NAFQ37UfJcgAAAAA:EgUX1XTS4nNxu2ktEvoKR5AaWrlpdII-ZNqKSyNH-viXxIj-hfQBX1D9ggp2uJrlckA7vHtVsNc;;"""og:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""twitter:title"",""College Fees Transaction Using Hash Functions of Blockchain Model""
""twitter:card"",""summary""
""Description"",""In recent existences, the cryptocurrency has provided great opportunities and challenges for the modern financial industry. Nowadays people to pay the college f""
""og:title"",""College Fees Transaction Using Hash Functions of Blockchain Model""
""resourceName"",""08878769.pdf""
""language"",""en""
""title"",""College Fees Transaction Using Hash Functions of Blockchain Model | IEEE Conference Publication | IEEE Xplore""
""og:description"",""In recent existences, the cryptocurrency has provided great opportunities and challenges for the modern financial industry. Nowadays people to pay the college fees in different ways, such as credit card, cheque, demand draft, and, direct cash. These types of transactions need an intermediate to transfer amount from the merchant to the beneficiary and the intermediate charge a transaction fee to transfer the money. In this hypothesis, we propose a decentration college fee transaction methods using blockchain technology. A blockchain is fundamentally a distributed ledger of the transcript of all transactions that has been accomplished and shared among contributing parties and it does not require any intermediate to transfer the money. Each transaction in the public ledger is confirmable by the participator in the system. Essentially, it's a disseminated database which manages an endlessly mounting proof of blocks it grips lots of transactions. Thus the concluded blocks are added into the networks in chronological order and each block contains an index, timestamp, data, and previous hash which indicate the previous block.""
""twitter:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-UA-Compatible"",""IE=Edge""
""viewport"",""width=device-width, initial-scale=1.0""
""dc:title"",""College Fees Transaction Using Hash Functions of Blockchain Model | IEEE Conference Publication | IEEE Xplore""
""twitter:description"",""In recent existences, the cryptocurrency has provided great opportunities and challenges for the modern financial industry. Nowadays people to pay the college fees in different ways, such as credit card, cheque, demand draft, and, direct cash. These types of transactions need an intermediate to transfer amount from the merchant to the beneficiary and the intermediate charge a transaction fee to transfer the money. In this hypothesis, we propose a decentration college fee transaction methods using blockchain technology. A blockchain is fundamentally a distributed ledger of the transcript of all transactions that has been accomplished and shared among contributing parties and it does not require any intermediate to transfer the money. Each transaction in the public ledger is confirmable by the participator in the system. Essentially, it's a disseminated database which manages an endlessly mounting proof of blocks it grips lots of transactions. Thus the concluded blocks are added into the networks in chronological order and each block contains an index, timestamp, data, and previous hash which indicate the previous block.""
""Content-Encoding"",""UTF-8""
""Content-Type-Hint"",""text/html; charset=utf-8""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=380&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093480-306;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;NEO Smart Contract for Drought-Based Insurance;TQ Nguyen, AK Das, LT Tran ; 2019 IEEE Canadian …, 2019  ieeexplore.ieee.org;;"… To solve these problems, a blockchain-based smart contract linking with oracle services to ensure

asymmetric information is proposed to reduce the evaluation costs and lengthy process of

evaluating compensation is a. Currently, building smart contract that oracles can push …";Cité 2 fois;;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/8852749/8861512/08861573.pdf?casa_token=V4FHuNi0_ioAAAAA:OrbchuHxTX8NX871V2e-L8epDqCGFmYmhujZMNwBg-oW-PXykv1eRSdn0HlR25HZpK5AuAW6eSo;;"""og:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""twitter:title"",""NEO Smart Contract for Drought-Based Insurance""
""twitter:card"",""summary""
""Description"",""Agriculture insurance has developed across emerging economies in South East Asia (SEA). New products are introduced to farmers to lessen financial losses of cro""
""og:title"",""NEO Smart Contract for Drought-Based Insurance""
""resourceName"",""08861573.pdf""
""language"",""en""
""title"",""NEO Smart Contract for Drought-Based Insurance | IEEE Conference Publication | IEEE Xplore""
""og:description"",""Agriculture insurance has developed across emerging economies in South East Asia (SEA). New products are introduced to farmers to lessen financial losses of crops with low commercialised. Drought-based crop insurance has launched in some SEA countries to protect farmers from extreme weather events. The evaluation process for insurance value coverage is costly and lengthy. Farmer participation in crop insurance schemes, hence, remains low. Additionally, while dealing with extreme events, stated-owned irrigation water companies with complex bureaucratic systems delay decisions. This adds a heavy toll on farmers' shoulders when facing drought. To solve these problems, a blockchain-based smart contract linking with oracle services to ensure asymmetric information is proposed to reduce the evaluation costs and lengthy process of evaluating compensation is a. Currently, building smart contract that oracles can push required information to is not used in the case of agricultural insurance. Hence, we proposed a blockchain-based smart contract framework that applies to weather-based index insurance. We selected NEO for our experiment due to its easy access tokens. While developing a smart contract on NEO, we designed 5 functions that can be triggered if certain conditions are met and built a virtual oracles server. This initial experiment promised a scalable and trusted platform that can lessen farmers' potential damages and reduce their vulnerability.""
""twitter:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-UA-Compatible"",""IE=Edge""
""viewport"",""width=device-width, initial-scale=1.0""
""dc:title"",""NEO Smart Contract for Drought-Based Insurance | IEEE Conference Publication | IEEE Xplore""
""twitter:description"",""Agriculture insurance has developed across emerging economies in South East Asia (SEA). New products are introduced to farmers to lessen financial losses of crops with low commercialised. Drought-based crop insurance has launched in some SEA countries to protect farmers from extreme weather events. The evaluation process for insurance value coverage is costly and lengthy. Farmer participation in crop insurance schemes, hence, remains low. Additionally, while dealing with extreme events, stated-owned irrigation water companies with complex bureaucratic systems delay decisions. This adds a heavy toll on farmers' shoulders when facing drought. To solve these problems, a blockchain-based smart contract linking with oracle services to ensure asymmetric information is proposed to reduce the evaluation costs and lengthy process of evaluating compensation is a. Currently, building smart contract that oracles can push required information to is not used in the case of agricultural insurance. Hence, we proposed a blockchain-based smart contract framework that applies to weather-based index insurance. We selected NEO for our experiment due to its easy access tokens. While developing a smart contract on NEO, we designed 5 functions that can be triggered if certain conditions are met and built a virtual oracles server. This initial experiment promised a scalable and trusted platform that can lessen farmers' potential damages and reduce their vulnerability.""
""Content-Encoding"",""UTF-8""
""Content-Type-Hint"",""text/html; charset=utf-8""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=140&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093530-520;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Blockchain and Geographical Indications: A Natural Fit?;S Aronzon ; King's College London Law School Graduate Student …, 2019  papers.ssrn.com;;"… Page 11. 11 at 5:00 PM ESD, then Company A delivers $10,000 USD to Company B.” The

blockchain can then be linked to sources known as “oracles.” An oracle is an outside source

that provides information to the blockchain smart contract …";Autres articles;;null;;;;https://scholar.google.com/scholar?start=350&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093511-436;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;[PDF][PDF] Smart contract development, adoption and challenges: the powered blockchain;H Sheikh, RM Azmathullah… ; … Research Journal of …, 2019  researchgate.net;;"… oracles so that it can extract external information. They are immutable, auto-executing and possess

self-validating features. iii. Benefits of Smart Contract The benefits of smart contracts works

together with blockchain, • Fast and Precise: Smart contracts are easily processing a …";Cité 6 fois;Les 2 versions;[PDF] researchgate.net;https://www.researchgate.net/profile/Husneara-Sheikh/publication/335826741_Smart_Contract_Development_Adoption_and_Challenges_The_Powered_Blockchain/links/5d7de6a4299bf1d5a97f1e2e/Smart-Contract-Development-Adoption-and-Challenges-The-Powered-Blockchain.pdf;;;https://scholar.google.com/scholar?start=270&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093476-289;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Blockchain-based public integrity verification for cloud storage against procrastinating auditors;Y Zhang, C Xu, X Lin, XS Shen ; IEEE Transactions on Cloud …, 2019  ieeexplore.ieee.org;;"… 1 Blockchain-Based Public Integrity Verification for Cloud Storage against Procrastinating

Auditors … In this paper, we propose the first certificateless public verification scheme against

procrastinating auditors (CPVPA) by using blockchain technology …";Cité 72 fois;Les 3 versions;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/6245519/6562694/08676357.pdf?casa_token=AX2Dgct2PGcAAAAA:XAY7MJEJa755Bij4JzL6JfdB3hm9336eYRqYCUcm9NSYfRO5gqoPJU5FeyeWqcsfaa_8ac11Eoc;;"""og:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""twitter:title"",""Blockchain-Based Public Integrity Verification for Cloud Storage against Procrastinating Auditors""
""twitter:card"",""summary""
""Description"",""The deployment of cloud storage services has significant benefits in managing data for users. However, it also causes many security concerns, and one of them is""
""og:title"",""Blockchain-Based Public Integrity Verification for Cloud Storage against Procrastinating Auditors""
""resourceName"",""08676357.pdf""
""language"",""en""
""title"",""Blockchain-Based Public Integrity Verification for Cloud Storage against Procrastinating Auditors | IEEE Journals & Magazine | IEEE Xplore""
""og:description"",""The deployment of cloud storage services has significant benefits in managing data for users. However, it also causes many security concerns, and one of them is data integrity. Public verification techniques can enable a user to employ a third-party auditor to verify the data integrity on behalf of her/him, whereas existing public verification schemes are vulnerable to procrastinating auditors who may not perform verifications on time. Furthermore, most of public verification schemes are constructed on the public key infrastructure (PKI), and thereby suffer from certificate management problem. In this paper, we propose the first certificateless public verification scheme against procrastinating auditors (CPVPA) by using blockchain technology. The key idea is to require auditors to record each verification result into a blockchain as a transaction. Since transactions on the blockchain are time-sensitive, the verification can be time-stamped after the corresponding transaction is recorded into the blockchain, which enables users to check whether auditors perform the verifications at the prescribed time. Moreover, CPVPA is built on certificateless cryptography, and is free from the certificate management problem. We present rigorous security proofs to demonstrate the security of CPVPA, and conduct a comprehensive performance evaluation to show that CPVPA is efficient.""
""twitter:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-UA-Compatible"",""IE=Edge""
""viewport"",""width=device-width, initial-scale=1.0""
""dc:title"",""Blockchain-Based Public Integrity Verification for Cloud Storage against Procrastinating Auditors | IEEE Journals & Magazine | IEEE Xplore""
""twitter:description"",""The deployment of cloud storage services has significant benefits in managing data for users. However, it also causes many security concerns, and one of them is data integrity. Public verification techniques can enable a user to employ a third-party auditor to verify the data integrity on behalf of her/him, whereas existing public verification schemes are vulnerable to procrastinating auditors who may not perform verifications on time. Furthermore, most of public verification schemes are constructed on the public key infrastructure (PKI), and thereby suffer from certificate management problem. In this paper, we propose the first certificateless public verification scheme against procrastinating auditors (CPVPA) by using blockchain technology. The key idea is to require auditors to record each verification result into a blockchain as a transaction. Since transactions on the blockchain are time-sensitive, the verification can be time-stamped after the corresponding transaction is recorded into the blockchain, which enables users to check whether auditors perform the verifications at the prescribed time. Moreover, CPVPA is built on certificateless cryptography, and is free from the certificate management problem. We present rigorous security proofs to demonstrate the security of CPVPA, and conduct a comprehensive performance evaluation to show that CPVPA is efficient.""
""Content-Encoding"",""UTF-8""
""Content-Type-Hint"",""text/html; charset=utf-8""
""Content-Length"",""42035""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=120&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093478-293;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;In search for stability in crypto-assets: are stablecoins the solution?;D Bullmann, J Klemm, A Pinna ; ECB Occasional Paper, 2019  papers.ssrn.com;;"… platforms engaging in wash trading (ie market manipulation in which an investor simultaneously

sells and buys), thus artificially increasing the volumes of traded crypto-assets … The USD Tether

(USDT) is recorded on the Bitcoin blockchain through the Omni layered protocol …";Cité 65 fois;Les 5 versions;[PDF] econstor.eu;https://www.econstor.eu/bitstream/10419/207616/1/1676933492.pdf;;"""date"",""2021-04-28T10:10:02Z""
""pdf:docinfo:custom:DOI (pdf)"",""10.2866/969389""
""pdf:PDFVersion"",""1.5""
""xmp:CreatorTool"",""Acrobat PDFMaker 15 for Word""
""pdf:docinfo:title"",""In search for stability in crypto-assets: are stablecoins the solution?""
""Company"",""European Central Bank""
""Issue"",""No 230 / August 2019""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""pdf:docinfo:custom:ISSN (pdf)"",""1725-6534""
""subject"",""Stablecoins claim to stabilise the value of major currencies in the volatile crypto-asset market. This paper describes the often complex functioning of different types of stablecoins and proposes a taxonomy of stablecoin initiatives. To this end it relies on a novel framework for their classification, based on the key dimensions that matter for crypto-assets, namely: (i) accountability of issuer, (ii) decentralisation of responsibilities, and (iii) what underpins the value of the asset. The analysis of different types of stablecoins shows a trade-off between the novelty of the stabilisation mechanism used in an initiative (from mirroring the traditional electronic money approach to the alleged introduction of an “algorithmic central bank”) and its capacity to maintain a stable market value. While relatively less innovative stablecoins could provide a solution to users seeking a stable store of value, especially if legitimised by the adherence to standards that are typical of payment services, the jury is still out on the potential future role of more innovative stablecoins outside their core user base.""
""ISSN (pdf)"",""1725-6534""
""Series name"",""Occasional Paper Series""
""pdf:docinfo:custom:Series name"",""Occasional Paper Series""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""Acrobat PDFMaker 15 for Word""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""In search for stability in crypto-assets: are stablecoins the solution?""
""xmp:CreateDate"",""2019-08-28T10:20:23Z""
""modified"",""2021-04-28T10:10:02Z""
""pdf:docinfo:custom:SourceModified"",""D:20190828081956""
""cp:subject"",""Stablecoins claim to stabilise the value of major currencies in the volatile crypto-asset market. This paper describes the often complex functioning of different types of stablecoins and proposes a taxonomy of stablecoin initiatives. To this end it relies on a novel framework for their classification, based on the key dimensions that matter for crypto-assets, namely: (i) accountability of issuer, (ii) decentralisation of responsibilities, and (iii) what underpins the value of the asset. The analysis of different types of stablecoins shows a trade-off between the novelty of the stabilisation mechanism used in an initiative (from mirroring the traditional electronic money approach to the alleged introduction of an “algorithmic central bank”) and its capacity to maintain a stable market value. While relatively less innovative stablecoins could provide a solution to users seeking a stable store of value, especially if legitimised by the adherence to standards that are typical of payment services, the jury is still out on the potential future role of more innovative stablecoins outside their core user base.""
""pdf:docinfo:subject"",""Stablecoins claim to stabilise the value of major currencies in the volatile crypto-asset market. This paper describes the often complex functioning of different types of stablecoins and proposes a taxonomy of stablecoin initiatives. To this end it relies on a novel framework for their classification, based on the key dimensions that matter for crypto-assets, namely: (i) accountability of issuer, (ii) decentralisation of responsibilities, and (iii) what underpins the value of the asset. The analysis of different types of stablecoins shows a trade-off between the novelty of the stabilisation mechanism used in an initiative (from mirroring the traditional electronic money approach to the alleged introduction of an “algorithmic central bank”) and its capacity to maintain a stable market value. While relatively less innovative stablecoins could provide a solution to users seeking a stable store of value, especially if legitimised by the adherence to standards that are typical of payment services, the jury is still out on the potential future role of more innovative stablecoins outside their core user base.""
""pdf:hasMarkedContent"",""true""
""xmp:ModifyDate"",""2021-04-28T12:10:02Z""
""pdf:docinfo:creator"",""Dirk Bullmann, Jonas Klemm, Andrea Pinna""
""JEL codes"",""E42, L17, O33""
""meta:author"",""Dirk Bullmann, Jonas Klemm, Andrea Pinna""
""meta:creation-date"",""2019-08-28T08:20:23Z""
""created"",""2019-08-28T08:20:23Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-08-28T08:20:23Z""
""resourceName"",""1676933492.pdf""
""ISBN (pdf)"",""978-92-899-3871-6""
""pdf:docinfo:custom:JEL codes"",""E42, L17, O33""
""Author"",""Dirk Bullmann, Jonas Klemm, Andrea Pinna""
""producer"",""Adobe PDF Library 15.0; modified using iTextŽ 5.1.3 Š2000-2011 1T3XT BVBA""
""pdf:docinfo:custom:Issue"",""No 230 / August 2019""
""pdf:docinfo:producer"",""Adobe PDF Library 15.0; modified using iTextŽ 5.1.3 Š2000-2011 1T3XT BVBA""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""dc:description"",""Stablecoins claim to stabilise the value of major currencies in the volatile crypto-asset market. This paper describes the often complex functioning of different types of stablecoins and proposes a taxonomy of stablecoin initiatives. To this end it relies on a novel framework for their classification, based on the key dimensions that matter for crypto-assets, namely: (i) accountability of issuer, (ii) decentralisation of responsibilities, and (iii) what underpins the value of the asset. The analysis of different types of stablecoins shows a trade-off between the novelty of the stabilisation mechanism used in an initiative (from mirroring the traditional electronic money approach to the alleged introduction of an “algorithmic central bank”) and its capacity to maintain a stable market value. While relatively less innovative stablecoins could provide a solution to users seeking a stable store of value, especially if legitimised by the adherence to standards that are typical of payment services, the jury is still out on the potential future role of more innovative stablecoins outside their core user base.""
""Keywords"",""""""stablecoins, crypto-assets, distributed ledger technology, electronic money"""""",""""""stablecoins, crypto-assets, distributed ledger technology, electronic money""""""
""access_permission:modify_annotations"",""true""
""EU catalogue No (pdf)"",""QB-AQ-19-013-EN-N""
""dc:creator"",""Dirk Bullmann, Jonas Klemm, Andrea Pinna""
""description"",""Stablecoins claim to stabilise the value of major currencies in the volatile crypto-asset market. This paper describes the often complex functioning of different types of stablecoins and proposes a taxonomy of stablecoin initiatives. To this end it relies on a novel framework for their classification, based on the key dimensions that matter for crypto-assets, namely: (i) accountability of issuer, (ii) decentralisation of responsibilities, and (iii) what underpins the value of the asset. The analysis of different types of stablecoins shows a trade-off between the novelty of the stabilisation mechanism used in an initiative (from mirroring the traditional electronic money approach to the alleged introduction of an “algorithmic central bank”) and its capacity to maintain a stable market value. While relatively less innovative stablecoins could provide a solution to users seeking a stable store of value, especially if legitimised by the adherence to standards that are typical of payment services, the jury is still out on the potential future role of more innovative stablecoins outside their core user base.""
""DOI (pdf)"",""10.2866/969389""
""dcterms:created"",""2019-08-28T08:20:23Z""
""Last-Modified"",""2021-04-28T10:10:02Z""
""dcterms:modified"",""2021-04-28T10:10:02Z""
""title"",""In search for stability in crypto-assets: are stablecoins the solution?""
""xmpMM:DocumentID"",""uuid:073af958-c1d4-40b5-b4e6-a545f6720db6""
""Last-Save-Date"",""2021-04-28T10:10:02Z""
""pdf:docinfo:keywords"",""""""stablecoins, crypto-assets, distributed ledger technology, electronic money""""""
""pdf:docinfo:modified"",""2021-04-28T10:10:02Z""
""meta:save-date"",""2021-04-28T10:10:02Z""
""pdf:docinfo:custom:EU catalogue No (pdf)"",""QB-AQ-19-013-EN-N""
""Content-Length"",""1162857""
""Content-Type"",""application/pdf""
""xmp:MetadataDate"",""2021-04-28T12:10:02Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Dirk Bullmann, Jonas Klemm, Andrea Pinna""
""pdf:docinfo:custom:ISBN (pdf)"",""978-92-899-3871-6""
""dc:language"",""EN-GB""
""pdf:producer"",""Adobe PDF Library 15.0; modified using iTextŽ 5.1.3 Š2000-2011 1T3XT BVBA""
""dc:subject"",""""""stablecoins, crypto-assets, distributed ledger technology, electronic money"""""",""""""stablecoins, crypto-assets, distributed ledger technology, electronic money""""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""56""
""pdf:hasXMP"",""true""
""Publisher"",""European Central Bank""
""pdf:charsPerPage"",""1746"",""367"",""918"",""1293"",""2855"",""3169"",""830"",""3420"",""1673"",""2782"",""1710"",""1602"",""2152"",""3749"",""1271"",""144"",""2928"",""2587"",""3405"",""2259"",""521"",""3830"",""1905"",""56"",""993"",""3011"",""2624"",""3206"",""2177"",""1479"",""2517"",""3173"",""3095"",""3095"",""1432"",""2640"",""1099"",""1976"",""3425"",""2817"",""3669"",""3870"",""3978"",""2977"",""3404"",""3486"",""2931"",""3628"",""2496"",""3416"",""2235"",""1942"",""1312"",""2276"",""819"",""1236""
""access_permission:extract_content"",""true""
""pdf:docinfo:custom:Company"",""European Central Bank""
""access_permission:can_print"",""true""
""SourceModified"",""D:20190828081956""
""meta:keyword"",""""""stablecoins, crypto-assets, distributed ledger technology, electronic money"""""",""""""stablecoins, crypto-assets, distributed ledger technology, electronic money""""""
""pdf:docinfo:custom:Publisher"",""European Central Bank""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-08-28T08:20:23Z""
";https://scholar.google.com/scholar?start=130&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093448-161;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;[HTML][HTML] Trust management in a blockchain based fog computing platform with trustless smart oracles;P Kochovski, S Gec, V Stankovski, M Bajec… ; Future Generation …, 2019  Elsevier;;"Trust is a crucial aspect when cyber-physical systems have to rely on resources and 
services under ownership of various entities, such as in the case of Edge, Fog and Cloud 
computing. The DECENTER's Fog Computing Platform is developed to support Big Data …";Cité 43 fois;Les 3 versions;[HTML] sciencedirect.com;https://www.sciencedirect.com/science/article/pii/S0167739X19301281?casa_token=siw6ep7W7csAAAAA:uvHEiEdLNJfpH8ZrnHut3fVUH1mXC8Kn3JPL4LKswLR7FfL4Nl_ukzBDh_PbWX6zLNCGPCRv;;;
1619093527-509;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Eine kurze Geschichte der Blockchain;V Skwarek ; Informatik Spektrum, 2019  Springer;;"… Die Quellen solcher Echtweltinformationen werden Oracles genannt. Definition Oracle. Dienst,

der Echtweltdaten der Blockchain zur Verfügung stellt … In: Proceedings of Crypto 82, New York,

pp 199–203 8. Dutch Blockchain Coalition (n. Y.) Blockchain …";Autres articles;;[PDF] springer.com;https://idp.springer.com/authorize/casa?redirect_uri=https://link.springer.com/content/pdf/10.1007/s00287-019-01175-0.pdf&casa_token=Ub2Ho9s4dDgAAAAA:-uEwW_l8TiH_8CMI2aMjS3lhQMwqMeZ0j1CwglVihRoAS_LN_7RCL8NgjNje0hZ6G0U71kbzkIJdZkc;;;https://scholar.google.com/scholar?start=340&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093455-200;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Introducing trust in service-oriented distributed systems through blockchain;M Autili, F Gallo, P Inverardi… ; … on Software Reliability …, 2019  ieeexplore.ieee.org;;"… The software oracle extracts the needed information and pushes it into the smart contract …

Outbound Oracles, provide smart contracts with the ability to send data to the outside world … be

a smart lock in the physical world, which receives a payment on its blockchain address and …";Cité 2 fois;Les 2 versions;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/8970146/8990183/08990201.pdf?casa_token=IUw_AzSFhc0AAAAA:O_vuziHNstjORpOgNE_ksbPoY5k5dPcIO8wRR6NtdjEHAXsTF5xna-j67pXsRU9WgyVUa_im6No;;"""og:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""twitter:title"",""Introducing Trust in Service-Oriented Distributed Systems through Blockchain""
""twitter:card"",""summary""
""Description"",""Business process management is concerned with the design execution, improvement, and monitoring of business processes. Systems that support the enactment and ex""
""og:title"",""Introducing Trust in Service-Oriented Distributed Systems through Blockchain""
""resourceName"",""08990201.pdf""
""language"",""en""
""title"",""Introducing Trust in Service-Oriented Distributed Systems through Blockchain | IEEE Conference Publication | IEEE Xplore""
""og:description"",""Business process management is concerned with the design execution, improvement, and monitoring of business processes. Systems that support the enactment and execution of processes have extensively been used by companies to streamline and automate intra-organizational processes. However, today's business enterprises must deal with global competition, heterogeneity, and rapidly develop new services and products. To address these requirements, the services reuse-based approach allowed enterprises to reconsider and optimize the way they do business, and change their information systems and applications to support collaborative business processes. Service choreographies support the reuse-based service-oriented philosophy in that they represent a powerful and flexible approach to realize systems by (possibly) reusing services and composing them in a fully distributed way. Nevertheless, for inter-organizational processes, challenges of collaborative design and lack of mutual trust have hampered a broader uptake. In this paper, we show an early stage approach to address the problem of trust in services choreography by using Blockchain technologies, in order to support the decentralized and peer-to-peer collaboration in a trustworthy manner, even in a network without any mutual trust between nodes.""
""twitter:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-UA-Compatible"",""IE=Edge""
""viewport"",""width=device-width, initial-scale=1.0""
""dc:title"",""Introducing Trust in Service-Oriented Distributed Systems through Blockchain | IEEE Conference Publication | IEEE Xplore""
""twitter:description"",""Business process management is concerned with the design execution, improvement, and monitoring of business processes. Systems that support the enactment and execution of processes have extensively been used by companies to streamline and automate intra-organizational processes. However, today's business enterprises must deal with global competition, heterogeneity, and rapidly develop new services and products. To address these requirements, the services reuse-based approach allowed enterprises to reconsider and optimize the way they do business, and change their information systems and applications to support collaborative business processes. Service choreographies support the reuse-based service-oriented philosophy in that they represent a powerful and flexible approach to realize systems by (possibly) reusing services and composing them in a fully distributed way. Nevertheless, for inter-organizational processes, challenges of collaborative design and lack of mutual trust have hampered a broader uptake. In this paper, we show an early stage approach to address the problem of trust in services choreography by using Blockchain technologies, in order to support the decentralized and peer-to-peer collaboration in a trustworthy manner, even in a network without any mutual trust between nodes.""
""Content-Encoding"",""UTF-8""
""Content-Type-Hint"",""text/html; charset=utf-8""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=30&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093480-309;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;DeepCoin: A novel deep learning and blockchain-based energy exchange framework for smart grids;MA Ferrag, L Maglaras ; IEEE Transactions on Engineering …, 2019  ieeexplore.ieee.org;;"… 67, NO. 4, NOVEMBER 2020 1285 DeepCoin: A Novel Deep Learning and Blockchain-Based

Energy Exchange Framework for Smart Grids … Abstract—In this paper, we propose a novel deep

learning and blockchain-based energy framework for smart grids, entitled Deep- Coin …";Cité 55 fois;Les 2 versions;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/17/9226631/08758147.pdf?casa_token=GwgZV0pD_wYAAAAA:A8kWiGsjcV02liU-I1eKacH6MYcE8WI3SKDtQff_sk3bJ5frdRlLdVOJZfcif0sLysR8UZhSd5k;;"""og:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""twitter:title"",""DeepCoin: A Novel Deep Learning and Blockchain-Based Energy Exchange Framework for Smart Grids""
""twitter:card"",""summary""
""Description"",""In this paper, we propose a novel deep learning and blockchain-based energy framework for smart grids, entitled DeepCoin. The DeepCoin framework uses two scheme""
""og:title"",""DeepCoin: A Novel Deep Learning and Blockchain-Based Energy Exchange Framework for Smart Grids""
""resourceName"",""08758147.pdf""
""language"",""en""
""title"",""DeepCoin: A Novel Deep Learning and Blockchain-Based Energy Exchange Framework for Smart Grids | IEEE Journals & Magazine | IEEE Xplore""
""og:description"",""In this paper, we propose a novel deep learning and blockchain-based energy framework for smart grids, entitled DeepCoin. The DeepCoin framework uses two schemes, a blockchain-based scheme and a deep learning-based scheme. The blockchain-based scheme consists of five phases: setup phase, agreement phase, creating a block phase and consensus-making phase, and view change phase. It incorporates a novel reliable peer-to-peer energy system that is based on the practical Byzantine fault tolerance algorithm and it achieves high throughput. In order to prevent smart grid attacks, the proposed framework makes the generation of blocks using short signatures and hash functions. The proposed deep learning-based scheme is an intrusion detection system (IDS), which employs recurrent neural networks for detecting network attacks and fraudulent transactions in the blockchain-based energy network. We study the performance of the proposed IDS on three different sources the CICIDS2017 dataset, a power system dataset, and a web robot (Bot)-Internet of Things (IoT) dataset.""
""twitter:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-UA-Compatible"",""IE=Edge""
""viewport"",""width=device-width, initial-scale=1.0""
""dc:title"",""DeepCoin: A Novel Deep Learning and Blockchain-Based Energy Exchange Framework for Smart Grids | IEEE Journals & Magazine | IEEE Xplore""
""twitter:description"",""In this paper, we propose a novel deep learning and blockchain-based energy framework for smart grids, entitled DeepCoin. The DeepCoin framework uses two schemes, a blockchain-based scheme and a deep learning-based scheme. The blockchain-based scheme consists of five phases: setup phase, agreement phase, creating a block phase and consensus-making phase, and view change phase. It incorporates a novel reliable peer-to-peer energy system that is based on the practical Byzantine fault tolerance algorithm and it achieves high throughput. In order to prevent smart grid attacks, the proposed framework makes the generation of blocks using short signatures and hash functions. The proposed deep learning-based scheme is an intrusion detection system (IDS), which employs recurrent neural networks for detecting network attacks and fraudulent transactions in the blockchain-based energy network. We study the performance of the proposed IDS on three different sources the CICIDS2017 dataset, a power system dataset, and a web robot (Bot)-Internet of Things (IoT) dataset.""
""Content-Encoding"",""UTF-8""
""Content-Type-Hint"",""text/html; charset=utf-8""
""Content-Length"",""43694""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=140&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093487-331;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Blockchain-based anonymous reporting scheme with anonymous rewarding;H Wang, D He, Z Liu, R Guo ; IEEE Transactions on …, 2019  ieeexplore.ieee.org;;"… In 2008, bitcoin was invented by S. Nakamoto [4]. As the first cryptocurrency, bitcoin is constructed …

Then, it can also use the rewards to create the other transactions on the blockchain … C generates

the corresponding value and sends it to A as the response (Random oracle model …";Cité 6 fois;;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/17/4429834/08704256.pdf?casa_token=jmJdBXYpnjMAAAAA:pz5IJCldrpWGUgmP70Xeo3wYG2vXgU7CYYbCsahBlqrCFTG7EmQBgwN7A_IOybp4N1e0WxAc0Ns;;"""og:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""twitter:title"",""Blockchain-Based Anonymous Reporting Scheme With Anonymous Rewarding""
""twitter:card"",""summary""
""Description"",""Since the ancient times, there exist all kinds of criminals in the world. In order to punish them, most authorities usually encourage the people to provide the ""
""og:title"",""Blockchain-Based Anonymous Reporting Scheme With Anonymous Rewarding""
""resourceName"",""08704256.pdf""
""language"",""en""
""title"",""Blockchain-Based Anonymous Reporting Scheme With Anonymous Rewarding | IEEE Journals & Magazine | IEEE Xplore""
""og:description"",""Since the ancient times, there exist all kinds of criminals in the world. In order to punish them, most authorities usually encourage the people to provide the evidence of a crime. To avoid the revenges from the criminals, it is necessary to study the anonymous reporting scheme with anonymous rewarding. In this paper, for the first time, we propose the novel concept of blockchain-based anonymous reporting scheme with anonymous rewarding (BB2AR). Our BB2AR scheme solves the open problem: how to realize the anonymous reporting and the anonymous rewarding simultaneously? First, we formalize the system model, definition, and security model of BB2AR. Second, we propose a concrete BB2AR scheme based on the elliptic curve public key cryptography. Our formal proof shows that our BB2AR scheme satisfies the anonymous reporting and the anonymous rewarding simultaneously. Finally, we analyze its efficiency and provide its prototype implementation. From the comparison, our BB2AR scheme is more efficient and practical.""
""twitter:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-UA-Compatible"",""IE=Edge""
""viewport"",""width=device-width, initial-scale=1.0""
""dc:title"",""Blockchain-Based Anonymous Reporting Scheme With Anonymous Rewarding | IEEE Journals & Magazine | IEEE Xplore""
""twitter:description"",""Since the ancient times, there exist all kinds of criminals in the world. In order to punish them, most authorities usually encourage the people to provide the evidence of a crime. To avoid the revenges from the criminals, it is necessary to study the anonymous reporting scheme with anonymous rewarding. In this paper, for the first time, we propose the novel concept of blockchain-based anonymous reporting scheme with anonymous rewarding (BB2AR). Our BB2AR scheme solves the open problem: how to realize the anonymous reporting and the anonymous rewarding simultaneously? First, we formalize the system model, definition, and security model of BB2AR. Second, we propose a concrete BB2AR scheme based on the elliptic curve public key cryptography. Our formal proof shows that our BB2AR scheme satisfies the anonymous reporting and the anonymous rewarding simultaneously. Finally, we analyze its efficiency and provide its prototype implementation. From the comparison, our BB2AR scheme is more efficient and practical.""
""Content-Encoding"",""UTF-8""
""Content-Type-Hint"",""text/html; charset=utf-8""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=170&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093506-420;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Leveraging Blockchain Technology in AEC Industry during Design Development Phase;S Singh, B Ashuri ; Computing in Civil Engineering 2019 …, 2019  ascelibrary.org;;"… transaction of digital information, and revolutionizing different industries like banking, crypto

exchanges, insurance … timestamping acts or transactions, multi-signature Transactions, and Smart

Oracles which are … The use of blockchain is identified in supply-chain and logistics of …";Cité 6 fois;;null;;;;https://scholar.google.com/scholar?start=250&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093455-191;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Confidential discovery of iot devices through blockchain;C Rondanini, B Carminati… ; 2019 IEEE International …, 2019  ieeexplore.ieee.org;;"… A further concern arises from the need of an Oracle to handle interactions of blockchain with

external entities [3]. Although Oracles allow the blockchain to be more flexible, they introduce

the presence of a mediator between the smart contract and external …";Cité 1 fois;Les 4 versions;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/8805197/8815648/08815655.pdf?casa_token=W7z_zdmYc4UAAAAA:x-rgRfG1qiVWVxnYOzyqUrqA-CUAteMreOzYfIKamHY-teStvfCVU-zuAQsY6a2eTSdPOL8IfGk;;"""og:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""twitter:title"",""Confidential Discovery of IoT Devices through Blockchain""
""twitter:card"",""summary""
""Description"",""Selection criteria regulating IoT device discovery involve confidentiality issue on the information the constraints convey. A promising approach to cope with th""
""og:title"",""Confidential Discovery of IoT Devices through Blockchain""
""resourceName"",""08815655.pdf""
""language"",""en""
""title"",""Confidential Discovery of IoT Devices through Blockchain | IEEE Conference Publication | IEEE Xplore""
""og:description"",""Selection criteria regulating IoT device discovery involve confidentiality issue on the information the constraints convey. A promising approach to cope with this issue is leveraging on blockchain technology and smart contracts to implement the overall discovery process deployment. However, due to the blockchain design, data within the blockchain is public and smart contracts cannot access data outside the blockchain, unless through the exploitation of Oracles. On the one hand, this brings benefits of trust decentralization, transparency, and accountability of the discovery process. On the other hand, it carries serious consequences on confidentiality and privacy as well as on Oracles trustworthiness. For these reasons, in this paper, we investigate how to ensure data confidentiality during the discovery process of IoT devices on blockchain even in the presence of an untrusted Oracle.""
""twitter:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-UA-Compatible"",""IE=Edge""
""viewport"",""width=device-width, initial-scale=1.0""
""dc:title"",""Confidential Discovery of IoT Devices through Blockchain | IEEE Conference Publication | IEEE Xplore""
""twitter:description"",""Selection criteria regulating IoT device discovery involve confidentiality issue on the information the constraints convey. A promising approach to cope with this issue is leveraging on blockchain technology and smart contracts to implement the overall discovery process deployment. However, due to the blockchain design, data within the blockchain is public and smart contracts cannot access data outside the blockchain, unless through the exploitation of Oracles. On the one hand, this brings benefits of trust decentralization, transparency, and accountability of the discovery process. On the other hand, it carries serious consequences on confidentiality and privacy as well as on Oracles trustworthiness. For these reasons, in this paper, we investigate how to ensure data confidentiality during the discovery process of IoT devices on blockchain even in the presence of an untrusted Oracle.""
""Content-Encoding"",""UTF-8""
""Content-Type-Hint"",""text/html; charset=utf-8""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=30&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093546-582;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;[PDF][PDF] La blockchain revolucionarŕ la comunicació de l'empresa;RJ Maestre ; Comunicació: revista de recerca i d'anŕlisi, 2019  raco.cat;;"… Contractes intelˇligents: Són la clau en la tecnologia blockchain. Els contrac- tes intelˇligents

programaran el nostre món i reemplaçaran algunes de les funcions que, en aquest moment,

s'executen a través d'intermediaris que són lents i costosos. — Oracles intelˇligents: Són …";Cité 1 fois;Les 6 versions;[PDF] raco.cat;https://www.raco.cat/index.php/Comunicacio/article/download/103390/447915;;"""date"",""2019-06-05T14:05:50Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.6""
""xmp:CreatorTool"",""Adobe InDesign CS6 (Macintosh)""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dcterms:created"",""2019-06-05T14:05:43Z""
""language"",""ca""
""Last-Modified"",""2019-06-05T14:05:50Z""
""dcterms:modified"",""2019-06-05T14:05:50Z""
""dc:format"",""application/pdf; version=1.6""
""xmpMM:DocumentID"",""uuid:898b4b7d-1807-485d-83e9-7c4736d9d101""
""Last-Save-Date"",""2019-06-05T14:05:50Z""
""pdf:docinfo:creator_tool"",""Adobe InDesign CS6 (Macintosh)""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2019-06-05T14:05:50Z""
""meta:save-date"",""2019-06-05T14:05:50Z""
""pdf:encrypted"",""false""
""xmp:CreateDate"",""2019-06-05T16:05:43Z""
""modified"",""2019-06-05T14:05:50Z""
""Content-Length"",""408317""
""pdf:hasMarkedContent"",""true""
""Content-Type"",""application/pdf""
""xmp:ModifyDate"",""2019-06-05T16:05:50Z""
""xmp:MetadataDate"",""2019-06-05T16:05:50Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""pdf:producer"",""Adobe PDF Library 10.0.1""
""meta:creation-date"",""2019-06-05T14:05:43Z""
""created"",""2019-06-05T14:05:43Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""22""
""Creation-Date"",""2019-06-05T14:05:43Z""
""resourceName"",""447915""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""573"",""2345"",""3137"",""1992"",""3205"",""1313"",""2940"",""2628"",""2886"",""2838"",""3028"",""3081"",""2767"",""2777"",""3432"",""2892"",""1797"",""2817"",""2787"",""3392"",""2258"",""2446""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""producer"",""Adobe PDF Library 10.0.1""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""Adobe PDF Library 10.0.1""
""pdf:docinfo:created"",""2019-06-05T14:05:43Z""
";https://scholar.google.com/scholar?start=420&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093502-398;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Decentralized Access Control Encryption in Public Blockchain;Z Yao, H Pan, X Si, W Zhu ; International Conference on Blockchain and …, 2019  Springer;;"… mathcal {A}\) that totalizes of at most q queries to the oracles performing the … to be deployed in

such a fully decentralized environment, for example in the public blockchain … DACE with constant

ciphertext size and decentralized sanitizers secure without random oracle and under …";Cité 1 fois;Les 2 versions;null;;;;https://scholar.google.com/scholar?start=230&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093455-194;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Blockchain for AI: Review and open research challenges;K Salah, MHU Rehman, N Nizamuddin… ; IEEE …, 2019  ieeexplore.ieee.org;;"… disruptive technologies. Blockchain technology has the ability to automate payment

in cryptocurrency and to provide access to a shared ledger of data, transactions, and

logs in a decentralized, secure, and trusted manner. Also with …";Cité 295 fois;Les 4 versions;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/6287639/6514899/08598784.pdf;;"""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""dc:title"",""IEEE Xplore Full-Text PDF:""
""Content-Encoding"",""UTF-8""
""resourceName"",""08598784.pdf""
""language"",""es""
""Content-Length"",""2565""
""title"",""IEEE Xplore Full-Text PDF:""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=30&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093541-561;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;[PDF][PDF] Cryptocurrency: Collateral for Secured Transactions?;XF Menard ; Banking & Finance Law Review, 2019  academia.edu;;"… Blockchain technology, and especially cryptocurrency, provides many advantages that make

it valuable … This article does not go into details about securities held through a blockchain system

with or without intermediation, also called ''crypto-securities”, and strictly concerns …";Cité 1 fois;Les 2 versions;[PDF] academia.edu;https://www.academia.edu/download/62837293/Cryptocurrency_Collateral_for_Secured_Transactions_BFLR_version20200405-80548-1ncuwl9.pdf;;;https://scholar.google.com/scholar?start=400&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093513-444;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;[PDF][PDF] Tokenization of physical assets and the impact of IoT and AI;T Weingärtner ; Lucerne University of Applied Sciences & …, 2019  blockchain.pwias.ubc.ca;;"… Mod18], ie the manipulation of the interface to the Blockchain, the properties “distribution”,

“redundancy” and “transparency” of the Blockchain can be used. A common approach is not to

rely on one Oracle, but to use a consensus-based Oracle, ie to connect several Oracles …";Cité 10 fois;Les 2 versions;[PDF] ubc.ca;https://blockchain.pwias.ubc.ca/sites/blockchain.pwias.ubc.ca/files/report-files/Weingaertner_Tokenization_IoT_AI%20(1).pdf;;"""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.5""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""15""
""resourceName"",""Weingaertner_Tokenization_IoT_AI%20(1).pdf""
""language"",""en""
""pdf:hasXMP"",""false""
""dc:format"",""application/pdf; version=1.5""
""pdf:charsPerPage"",""759"",""2566"",""2753"",""2973"",""3059"",""2541"",""2508"",""1931"",""2360"",""2510"",""1860"",""2844"",""2330"",""2340"",""1615""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""producer"",""Skia/PDF m75""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""Skia/PDF m75""
""pdf:hasMarkedContent"",""false""
""Content-Type"",""application/pdf""
";https://scholar.google.com/scholar?start=280&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093499-384;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Crypto-Wills: Transferring Digital Assets by Maintaining Wills on the Blockchain;JC Shah, M Bhagwat, D Patel, M Conti ; International Conference on …, 2019  Springer;;"… Currently, the proposed solution, Crypto-Wills, enables the users to transfer their assets using

any blockchain-based platform capable of executing smart contracts … 10. Egberts, A.: The Oracle

Problem an Analysis of How Blockchain Oracles Undermine the Advantages …";Autres articles;;null;;;;https://scholar.google.com/scholar?start=220&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093516-459;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Towards Blockchain Interoperability;M Borkowski ; … Forum: BPM 2019 Blockchain and CEE Forum …, 2019  books.google.com;;"… of the earliest contributions in the field of blockchain interoperability is the idea of a trustless

cryptocurrency exchange realized in … that the tokens were actually destroyed on the source block-

chain, or (b) the target blockchain relies on information provided by oracles [16], to …";Autres articles;;null;;;;https://scholar.google.com/scholar?start=290&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093464-235;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;[LIVRE][B] Blockchain: L'avčnement de la désintermédiation;M Quiniou ;2019 books.google.com;;"… 37 1.3.4. Oracles et décentralisation … 133 Page 10. Introduction La visibilité

actuelle de la blockchain tient ŕ l'intensité du mouvement spéculatif sur les

crypto-actifs depuis quelques années et particuličrement depuis 2017 …";Autres articles;;null;;;;https://scholar.google.com/scholar?start=70&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093527-503;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;"Trading securities on the Blockchain; design and implementation of a prototypical system to trade securities utilizing smart contracts";J Brottrager ;2019 repositum.tuwien.at;;"… 242 Oracles … to illustrate their respective applications, which can be analyzed to find gaps in

their application fields: Firstly, Harbor [14] with their “R-Token” standard, which aims to create

a system to transfer “crypto-securities” that are already persisted in the blockchain …";;;[PDF] tuwien.at;https://repositum.tuwien.at/bitstream/20.500.12708/6540/2/Trading%20securities%20on%20the%20Blockchain%20design%20and%20implementation%20of%20a%20prototypical%20system%20to%20trade%20securities%20utilizing%20smart%20contracts.pdf;;;https://scholar.google.com/scholar?start=340&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093457-201;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;HomeChain: a blockchain-based secure mutual authentication system for smart homes;C Lin, D He, N Kumar, X Huang… ; IEEE Internet of …, 2019  ieeexplore.ieee.org;;"… 7, NO. 2, FEBRUARY 2020 HomeChain: A Blockchain-Based Secure Mutual … While

blockchain-based solutions may mitigate these issues, they still face some critical challenges

(eg, providing regulation of behaviors and privacy protection of access policy) …";Cité 30 fois;;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/6488907/6702522/08852713.pdf?casa_token=7M-MUAdQSQQAAAAA:f_EVTwVLGJQEZW8zRRe01hBFfmuYa3sDnpguHgZf-bB67CCek1J3z4ARgaCTEPSvBbY5SyxFtBc;;"""og:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""twitter:title"",""HomeChain: A Blockchain-Based Secure Mutual Authentication System for Smart Homes""
""twitter:card"",""summary""
""Description"",""Increasingly, governments around the world, particularly in technologically advanced countries, are exploring or implementing smart homes, or the related smart ""
""og:title"",""HomeChain: A Blockchain-Based Secure Mutual Authentication System for Smart Homes""
""resourceName"",""08852713.pdf""
""language"",""en""
""title"",""HomeChain: A Blockchain-Based Secure Mutual Authentication System for Smart Homes | IEEE Journals & Magazine | IEEE Xplore""
""og:description"",""Increasingly, governments around the world, particularly in technologically advanced countries, are exploring or implementing smart homes, or the related smart facilities for the benefits of the society. The capability to remotely access and control Internet of Things (IoT) devices (e.g., capturing of images, audios, and other information) is convenient but risky, as vulnerable devices can be exploited to conduct surveillance or perform other nefarious activities on the users and organizations. This highlights the necessity of designing a secure and efficient remote user authentication solution. Most of the existing solutions for this problem are generally based on a single-server architecture, which has limitations in terms of privacy and anonymity (leading to users' daily activities being predicted), and integrity and confidentiality (resulting in an unreliable behavior auditing). While blockchain-based solutions may mitigate these issues, they still face some critical challenges (e.g., providing regulation of behaviors and privacy protection of access policy). Motivated by these facts, in this article, we construct a novel secure mutual authentication system, which can be applied in smart homes and other applications. Specifically, the proposed approach integrates blockchain, group signature, and message authentication code to provide reliable auditing of users' access history, anonymously authenticate group members, and efficiently authenticate home gateway, respectively. We also prove the security and privacy requirements, including anonymity, traceability, and confidentiality, that the proposed system satisfies, with an implementation and evaluation to demonstrate its practicality.""
""twitter:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-UA-Compatible"",""IE=Edge""
""viewport"",""width=device-width, initial-scale=1.0""
""dc:title"",""HomeChain: A Blockchain-Based Secure Mutual Authentication System for Smart Homes | IEEE Journals & Magazine | IEEE Xplore""
""twitter:description"",""Increasingly, governments around the world, particularly in technologically advanced countries, are exploring or implementing smart homes, or the related smart facilities for the benefits of the society. The capability to remotely access and control Internet of Things (IoT) devices (e.g., capturing of images, audios, and other information) is convenient but risky, as vulnerable devices can be exploited to conduct surveillance or perform other nefarious activities on the users and organizations. This highlights the necessity of designing a secure and efficient remote user authentication solution. Most of the existing solutions for this problem are generally based on a single-server architecture, which has limitations in terms of privacy and anonymity (leading to users' daily activities being predicted), and integrity and confidentiality (resulting in an unreliable behavior auditing). While blockchain-based solutions may mitigate these issues, they still face some critical challenges (e.g., providing regulation of behaviors and privacy protection of access policy). Motivated by these facts, in this article, we construct a novel secure mutual authentication system, which can be applied in smart homes and other applications. Specifically, the proposed approach integrates blockchain, group signature, and message authentication code to provide reliable auditing of users' access history, anonymously authenticate group members, and efficiently authenticate home gateway, respectively. We also prove the security and privacy requirements, including anonymity, traceability, and confidentiality, that the proposed system satisfies, with an implementation and evaluation to demonstrate its practicality.""
""Content-Encoding"",""UTF-8""
""Content-Type-Hint"",""text/html; charset=utf-8""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=40&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093492-359;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;On the application of blockchains to spectrum management;MBH Weiss, K Werbach, DC Sicker… ; IEEE Transactions on …, 2019  ieeexplore.ieee.org;;"… Similarly, El Gamal and El Gamal show that a cryptocurrency can incentivize users to share their …

Smart contracts can reference information outside the blockchain in two ways. They can

incorporate oracles, which are automated systems that verify information (such as a stock …";Cité 57 fois;Les 9 versions;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/6687307/7294639/08703084.pdf?casa_token=5h7QxasGfCwAAAAA:NXqugWJ4VNiHECKvdwCB_OdsXW9Rk40z-RWnfpApAmJJsLPW5XcXTmS9c2mLAC12jeT592fX6HM;;"""og:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""twitter:title"",""On the Application of Blockchains to Spectrum Management""
""twitter:card"",""summary""
""Description"",""Spectrum sharing mechanisms have evolved to meet different needs related to increasing spectrum use efficiency. At first, decentralized and opportunistic cognit""
""og:title"",""On the Application of Blockchains to Spectrum Management""
""resourceName"",""08703084.pdf""
""language"",""en""
""title"",""On the Application of Blockchains to Spectrum Management | IEEE Journals & Magazine | IEEE Xplore""
""og:description"",""Spectrum sharing mechanisms have evolved to meet different needs related to increasing spectrum use efficiency. At first, decentralized and opportunistic cognitive radios (and cognitive radio networks) were the primary focus of research for these mechanisms. This gradually transitioned toward the development of cooperative sharing methods based on databases, typified by TV white spaces databases. Spectrum sharing is now the basis for the dynamic and fine-grained spectrum rights regime for the citizen's band radio service (CBRS) as well as for license shared access (LSA). The emergence of the cryptocurrency Bitcoin has stimulated interest in applying its underlying technology, blockchain, to other applications as well, such as securities trading and supply chain management. This paper explores the application of blockchain to radio spectrum management. While blockchains could underlie radio spectrum management more broadly, we will focus on dynamic spectrum sharing applications. Like the cooperative approaches currently in use, blockchain is a database technology. However, a blockchain is a decentralized database in which the owner of the data maintains control. We consider the benefits and limitations of blockchain solutions in general, and then examine their potential application to four major categories of spectrum sharing.""
""twitter:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-UA-Compatible"",""IE=Edge""
""viewport"",""width=device-width, initial-scale=1.0""
""dc:title"",""On the Application of Blockchains to Spectrum Management | IEEE Journals & Magazine | IEEE Xplore""
""twitter:description"",""Spectrum sharing mechanisms have evolved to meet different needs related to increasing spectrum use efficiency. At first, decentralized and opportunistic cognitive radios (and cognitive radio networks) were the primary focus of research for these mechanisms. This gradually transitioned toward the development of cooperative sharing methods based on databases, typified by TV white spaces databases. Spectrum sharing is now the basis for the dynamic and fine-grained spectrum rights regime for the citizen's band radio service (CBRS) as well as for license shared access (LSA). The emergence of the cryptocurrency Bitcoin has stimulated interest in applying its underlying technology, blockchain, to other applications as well, such as securities trading and supply chain management. This paper explores the application of blockchain to radio spectrum management. While blockchains could underlie radio spectrum management more broadly, we will focus on dynamic spectrum sharing applications. Like the cooperative approaches currently in use, blockchain is a database technology. However, a blockchain is a decentralized database in which the owner of the data maintains control. We consider the benefits and limitations of blockchain solutions in general, and then examine their potential application to four major categories of spectrum sharing.""
""Content-Encoding"",""UTF-8""
""Content-Type-Hint"",""text/html; charset=utf-8""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=190&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093539-554;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Practical Deployability of Permissioned Blockchains;L Maddali, H Narumanchi ; … , Berlin, Germany, July 18–20, 2018 …, 2019  books.google.com;;"… Another important challenge is confidentiality and privacy of oracle queries. Some solutions like

Town Crier [14], Oraclize [15] explore oracles in context of decentralized applications …

org/10.1007/978-3-662-48000-729 4. Wüst, K., Gervais, A.: Do you need a Blockchain …";Autres articles;;[PDF] researchgate.net;https://www.researchgate.net/profile/Nitesh-Emmadi/publication/325966342_Practical_Deployability_of_Permissioned_Blockchains/links/5c627a0992851c48a9cd6759/Practical-Deployability-of-Permissioned-Blockchains.pdf;;;https://scholar.google.com/scholar?start=390&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093462-225;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Caterpillar: A business process execution engine on the Ethereum blockchain;O López?Pintado, L García?Bańuelos… ; Software: Practice …, 2019  Wiley Online Library;;"… evaluation of the Caterpillar engine, which demonstrates the tradeoffs between efficiency

(specifically consumption of the cryptocurrency Ether) and … sort of push?oriented interaction with

external applications and to forward requests to so?called blockchain oracles, as discussed …";Cité 69 fois;Les 4 versions;[PDF] wiley.com;https://onlinelibrary.wiley.com/doi/pdf/10.1002/spe.2702?casa_token=kiz7_yDwRsgAAAAA:PUD5WRDHCazVEMEJ_cI-ISBe7cm1h3E2IY4yBgHV1I0yjk_zsVeqGvs_CIJUlyujaqDU89kQkta_Lw;;;https://scholar.google.com/scholar?start=60&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093504-408;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Decentralizing the Issuance and the Exchange of Tokenized Securities on the Ethereum Blockchain;M Hoffmann ;2019 aaltodoc.aalto.fi;;"… Furthermore, we use so-called oracles to bridge blockchain-based logic with

regulatory definitions, eg investment limits in Euro. We compare our proposal to

existing implementations and extensively discuss design decisions …";;;null;;;;https://scholar.google.com/scholar?start=240&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093509-421;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;[PDF][PDF] A Valid Blockchain-based Data Trading Ecosystem.;T Li, D Li ; IACR Cryptol. ePrint Arch., 2019  eprint.iacr.org;;"Page 1. A Valid Blockchain-based Data Trading Ecosystem Taotao Li, Dequan Li No Institute

Given Abstract … Third, data trading platform is the single-point-failure. In this paper, we resolve

these challenges by pre- senting a valid blockchain-based data trading ecosystem …";Autres articles;Version HTML;[PDF] iacr.org;https://eprint.iacr.org/2019/1306.pdf;;"""date"",""2019-11-11T11:43:24Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""2"",""0"",""0"",""0"",""0"",""0"",""0"",""2"",""2"",""2"",""8"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.5""
""xmp:CreatorTool"",""TeX""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dcterms:created"",""2019-11-11T11:43:24Z""
""language"",""en""
""Last-Modified"",""2019-11-11T11:43:24Z""
""dcterms:modified"",""2019-11-11T11:43:24Z""
""dc:format"",""application/pdf; version=1.5""
""Last-Save-Date"",""2019-11-11T11:43:24Z""
""pdf:docinfo:creator_tool"",""TeX""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2019-11-11T11:43:24Z""
""meta:save-date"",""2019-11-11T11:43:24Z""
""pdf:encrypted"",""false""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.19 (TeX Live 2018) kpathsea version 6.3.0""
""modified"",""2019-11-11T11:43:24Z""
""Content-Length"",""559885""
""pdf:hasMarkedContent"",""false""
""Content-Type"",""application/pdf""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.19 (TeX Live 2018) kpathsea version 6.3.0""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""trapped"",""False""
""meta:creation-date"",""2019-11-11T11:43:24Z""
""created"",""2019-11-11T11:43:24Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""23""
""Creation-Date"",""2019-11-11T11:43:24Z""
""resourceName"",""1306.pdf""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""2133"",""2172"",""2435"",""2250"",""2464"",""1640"",""2020"",""2010"",""991"",""2121"",""1622"",""1642"",""1434"",""2502"",""2783"",""2575"",""583"",""628"",""1123"",""2270"",""2444"",""2477"",""1044""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""producer"",""pdfTeX-1.40.19""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""pdfTeX-1.40.19""
""pdf:docinfo:created"",""2019-11-11T11:43:24Z""
";https://scholar.google.com/scholar?start=260&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093504-405;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Non-intrusive deployment of blockchain in establishing cyber-infrastructure for smart city;AA Malik, DK Tosh, U Ghosh ; 2019 16th Annual IEEE …, 2019  ieeexplore.ieee.org;;"… To simulate the nodes and network, we are using Oracle's VirtualBox [19] … [16] X. Liang, S. Shetty,

and D. Tosh, “Exploring the attack surfaces in blockchain enabled smart cities,” in 2018 IEEE

International Smart Cities Conference (ISC2), pp … [19] Oracles VirtualBox, 2018 …";Cité 7 fois;Les 2 versions;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/8822235/8824788/08824921.pdf?casa_token=bXajwqksbS4AAAAA:qKyo4JnNT0t7hmr6-0iN0sRyyEjR3dOFeG6WIsVfmlYR28VqsrJpaGGrLSUqFbf1l0vnXCGBMZo;;"""og:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""twitter:title"",""Non-Intrusive Deployment of Blockchain in Establishing Cyber-Infrastructure for Smart City""
""twitter:card"",""summary""
""Description"",""Internet-of-Things has emerged to develop smart communities so that real time sensing and decision can improve operational efficiency and quality of lives. Howe""
""og:title"",""Non-Intrusive Deployment of Blockchain in Establishing Cyber-Infrastructure for Smart City""
""resourceName"",""08824921.pdf""
""language"",""en""
""title"",""Non-Intrusive Deployment of Blockchain in Establishing Cyber-Infrastructure for Smart City | IEEE Conference Publication | IEEE Xplore""
""og:description"",""Internet-of-Things has emerged to develop smart communities so that real time sensing and decision can improve operational efficiency and quality of lives. However, establishing such infrastructure can be exceptionally intricate due to the vast variety of devices and the implemented technologies. Also, it poses several unique challenges, such as heterogeneity of the infrastructure, type, and scale of deployment, security, privacy, and inter-operability. One primary concern in a smart city environment is the capabilities of typically end-IoT devices which are vulnerable to security threats and prone to confidentiality and integrity breach of data. Blockchain can potentially address these security challenges due to the distributed ledger's inherent properties. In this paper, we propose a decentralized architecture using the Blockchain to provide a secure and resilient smart city infrastructure that can run the ledger service over a distributed network. We consider a permissioned Blockchain, Hyperledger Sawtooth, and to automate and to overcome the infrastructural challenges concerning the smart city deployment, and we provide a systematic methodology that automates the deployment process and saves a significant amount of time. We simulate and deploy a Blockchain-integrated smart city environment using the proposed seamless deployment strategy using our automation module. With the proposed deployment scheme, we improve the Blockchain-based infrastructure development time by 82% compared to the traditional deployment approach.""
""twitter:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-UA-Compatible"",""IE=Edge""
""viewport"",""width=device-width, initial-scale=1.0""
""dc:title"",""Non-Intrusive Deployment of Blockchain in Establishing Cyber-Infrastructure for Smart City | IEEE Conference Publication | IEEE Xplore""
""twitter:description"",""Internet-of-Things has emerged to develop smart communities so that real time sensing and decision can improve operational efficiency and quality of lives. However, establishing such infrastructure can be exceptionally intricate due to the vast variety of devices and the implemented technologies. Also, it poses several unique challenges, such as heterogeneity of the infrastructure, type, and scale of deployment, security, privacy, and inter-operability. One primary concern in a smart city environment is the capabilities of typically end-IoT devices which are vulnerable to security threats and prone to confidentiality and integrity breach of data. Blockchain can potentially address these security challenges due to the distributed ledger's inherent properties. In this paper, we propose a decentralized architecture using the Blockchain to provide a secure and resilient smart city infrastructure that can run the ledger service over a distributed network. We consider a permissioned Blockchain, Hyperledger Sawtooth, and to automate and to overcome the infrastructural challenges concerning the smart city deployment, and we provide a systematic methodology that automates the deployment process and saves a significant amount of time. We simulate and deploy a Blockchain-integrated smart city environment using the proposed seamless deployment strategy using our automation module. With the proposed deployment scheme, we improve the Blockchain-based infrastructure development time by 82% compared to the traditional deployment approach.""
""Content-Encoding"",""UTF-8""
""Content-Type-Hint"",""text/html; charset=utf-8""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=240&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093487-339;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;A new proof of work for blockchain based on random multivariate quadratic equations;J Ding ; International Conference on Applied Cryptography and …, 2019  Springer;;"… to the usage of hash functions, which can be viewed as a random oracle, to produce …

arXiv:1710.10377 (2017). 2. Bellare, M., Rogaway, P.: Random oracles are practical: a paradigm

for … V., Gorbunov, S., Mosca, M., Munson, B.: Quantum-proofing the blockchain, November 2017 …";Cité 4 fois;Les 2 versions;null;;;;https://scholar.google.com/scholar?start=170&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093494-365;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Collusion by blockchain and smart contracts;T Schrepel ; Harvard Journal of Law and Technology, 2019  papers.ssrn.com;;"… Some simply make a distinction between blockchain as crypto-currencies and block- chain as

applications … which each player shares the same dominant strategy: to denounce the

agreement.42 Blockchain can help … See Michael Abramowicz, Cryptocurrency-Based Law, 58 …";Cité 20 fois;Les 5 versions;[PDF] harvard.edu;https://jolt.law.harvard.edu/assets/articlePDFs/v33/03-Schrepel.pdf;;"""date"",""2020-02-07T02:14:38Z""
""pdf:PDFVersion"",""1.4""
""xmp:CreatorTool"",""MicrosoftÂŽ Word 2016""
""pdf:docinfo:title"",""Collusion by Blockchain and Smart Contracts""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""pdfa:PDFVersion"",""A-1a""
""language"",""en""
""dc:format"",""application/pdf; version=""""A-1a"""""",""application/pdf; version=1.4""
""pdf:docinfo:creator_tool"",""MicrosoftÂŽ Word 2016""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""Collusion by Blockchain and Smart Contracts""
""xmp:CreateDate"",""2020-02-06T21:14:38Z""
""modified"",""2020-02-07T02:14:38Z""
""pdf:hasMarkedContent"",""true""
""xmp:ModifyDate"",""2020-02-06T21:14:38Z""
""pdf:docinfo:creator"",""Dr. Thibault Schrepel""
""meta:author"",""Dr. Thibault Schrepel""
""meta:creation-date"",""2020-02-07T02:14:38Z""
""created"",""2020-02-07T02:14:38Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-02-07T02:14:38Z""
""resourceName"",""03-Schrepel.pdf""
""pdfaid:part"",""1""
""Author"",""Dr. Thibault Schrepel""
""producer"",""MicrosoftÂŽ Word 2016""
""pdf:docinfo:producer"",""MicrosoftÂŽ Word 2016""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""access_permission:modify_annotations"",""true""
""dc:creator"",""Dr. Thibault Schrepel""
""dcterms:created"",""2020-02-07T02:14:38Z""
""Last-Modified"",""2020-02-07T02:14:38Z""
""dcterms:modified"",""2020-02-07T02:14:38Z""
""title"",""Collusion by Blockchain and Smart Contracts""
""xmpMM:DocumentID"",""uuid:0E499ACE-0F5A-4172-BD4F-8BF6AA6CEB7E""
""Last-Save-Date"",""2020-02-07T02:14:38Z""
""pdf:docinfo:modified"",""2020-02-07T02:14:38Z""
""meta:save-date"",""2020-02-07T02:14:38Z""
""Content-Length"",""1238072""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Dr. Thibault Schrepel""
""pdfaid:conformance"",""A""
""dc:language"",""en-US""
""pdf:producer"",""MicrosoftÂŽ Word 2016""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""50""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""3052"",""2775"",""3394"",""3825"",""3896"",""3521"",""3340"",""3497"",""3470"",""3337"",""3304"",""2568"",""3050"",""2899"",""3352"",""3834"",""3221"",""3418"",""3143"",""3375"",""3309"",""3399"",""3132"",""3288"",""3175"",""3067"",""2976"",""2912"",""3409"",""3904"",""3029"",""3135"",""3022"",""3254"",""3265"",""3154"",""3106"",""2420"",""3116"",""3192"",""3709"",""2845"",""3213"",""3063"",""3185"",""3228"",""2842"",""3340"",""3888"",""1429""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-02-07T02:14:38Z""
";https://scholar.google.com/scholar?start=200&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093464-240;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;The limits of smart contracts;J Frankenreiter ; Journal of Institutional and Theoretical …, 2019  search.proquest.com;;"… Besides, absent legal rules protecting against such behavior, contracting parties could manipulate

oracles or smart devices in order to … a party looking for a way not to comply with a smart contract

might pres- sure an oracle into confirming on the blockchain that the …";Cité 9 fois;Les 5 versions;null;;;;https://scholar.google.com/scholar?start=70&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093464-236;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;[HTML][HTML] Cloud health resource sharing based on consensus-oriented blockchain technology: Case study on a breast tumor diagnosis service;X Zhu, J Shi, C Lu ; Journal of medical Internet research, 2019  jmir.org;Germany;"… The Oracle mechanism also guarantees the safety of external data blockchain data. Value sharing

is the core concept of the proposed model. The model employs a cryptocurrency system, the

cloud health coin system, and the cryptocurrency is called cloud health coin (CHC) …";Cité 12 fois;Les 9 versions;[HTML] jmir.org;https://www.jmir.org/2019/7/e13767;;"""og:image"",""https://asset.jmir.pub/assets/508b286ff1e861b23107ce00ad7d01cd.png""
""twitter:card"",""summary_large_image""
""og:site_name"",""Journal of Medical Internet Research""
""keywords"",""blockchain; cloud health; breast tumor diagnosis; k-nearest neighbors (KNN); Proof of Authority (PoA); consensus-oriented""
""citation_journal_title"",""Journal of Medical Internet Research""
""language"",""en""
""dc:title"",""Journal of Medical Internet Research - Cloud Health Resource Sharing Based on Consensus-Oriented Blockchain Technology: Case Study on a Breast Tumor Diagnosis Service""
""Content-Encoding"",""UTF-8""
""DC.Identifier"",""doi:10.2196/13767""
""DC.Rights"",""""
""resourceName"",""e13767""
""citation_abstract_html_url"",""https://www.jmir.org/2019/7/e13767""
""citation_issue"",""7""
""citation_abstract_pdf_url"",""https://www.jmir.org/2019/7/e13767/PDF""
""citation_doi"",""10.2196/13767""
""DC.Relation"",""World""
""citation_volume"",""21""
""Content-Language"",""en""
""msapplication-TileImage"",""https://asset.jmir.pub/assets/static/images/mstile-144x144.png""
""citation_title"",""Cloud Health Resource Sharing Based on Consensus-Oriented Blockchain Technology: Case Study on a Breast Tumor Diagnosis Service""
""DC.Type"",""Text.Serial.Journal""
""citation_publisher"",""JMIR Publications Inc., Toronto, Canada""
""description"",""Background: In recent years, researchers have made significant efforts in advancing blockchain technology. This technology, with distinct features of decentralization and security, can be applied to many fields. In areas of health data and resource sharing, applications of blockchain technology are also emerging. Objective: In this study, we propose a cloud health resource-sharing model based on consensus-oriented blockchain technology and have developed a simulation study on breast tumor diagnosis. Methods: The proposed platform is built on a consortium or federated blockchain that possesses features of both centralization and decentralization. The consensus mechanisms generate operating standards for the proposed model. Open source Ethereum code is employed to provide the blockchain environment. Proof of Authority is selected as the consensus algorithm of block generation. Results: Based on the proposed model, a simulation case study for breast tumor classification is constructed. The simulation includes 9893 service requests from 100 users; 22 service providers are equipped with 22 different classification methods. Each request is fulfilled by a service provider recommended by the weighted k-nearest neighbors (KNN) algorithm. The majority of service requests are handled by 9 providers, and provider service evaluation scores tend to stabilize. Also, user priority on KNN weights significantly affects the system operation outcome. Conclusions: The proposed model is feasible based on the simulation case study for the cloud service of breast tumor diagnosis and has the potential to be applied to other applications. ""
""citation_date"",""2019-07-23""
""title"",""Journal of Medical Internet Research - Cloud Health Resource Sharing Based on Consensus-Oriented Blockchain Technology: Case Study on a Breast Tumor Diagnosis Service""
""twitter:image"",""https://asset.jmir.pub/assets/508b286ff1e861b23107ce00ad7d01cd.png""
""DC.Description"",""Background: In recent years, researchers have made significant efforts in advancing blockchain technology. This technology, with distinct features of decentralization and security, can be applied to many fields. In areas of health data and resource sharing, applications of blockchain technology are also emerging. Objective: In this study, we propose a cloud health resource-sharing model based on consensus-oriented blockchain technology and have developed a simulation study on breast tumor diagnosis. Methods: The proposed platform is built on a consortium or federated blockchain that possesses features of both centralization and decentralization. The consensus mechanisms generate operating standards for the proposed model. Open source Ethereum code is employed to provide the blockchain environment. Proof of Authority is selected as the consensus algorithm of block generation. Results: Based on the proposed model, a simulation case study for breast tumor classification is constructed. The simulation includes 9893 service requests from 100 users; 22 service providers are equipped with 22 different classification methods. Each request is fulfilled by a service provider recommended by the weighted k-nearest neighbors (KNN) algorithm. The majority of service requests are handled by 9 providers, and provider service evaluation scores tend to stabilize. Also, user priority on KNN weights significantly affects the system operation outcome. Conclusions: The proposed model is feasible based on the simulation case study for the cloud service of breast tumor diagnosis and has the potential to be applied to other applications. ""
""twitter:site"",""@jmirpub""
""DC.Publisher.Address"",""JMIR Publications // 130 Queens Quay East, Unit 1100 // Toronto, ON, M5A 0P6""
""DC.Subject"",""blockchain; cloud health; breast tumor diagnosis; k-nearest neighbors (KNN); Proof of Authority (PoA); consensus-oriented""
""DC.Publisher"",""Journal of Medical Internet Research""
""DC.Format"",""text/xml""
""Content-Length"",""510196""
""DC.Contributor"",""Xiaobao Zhu"",""Jing Shi"",""Cuiyuan Lu""
""Content-Type"",""text/html; charset=UTF-8""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""og:type"",""article""
""twitter:title"",""Cloud Health Resource Sharing Based on Consensus-Oriented Blockchain Technology: Case Study on a Breast Tumor Diagnosis Service""
""og:title"",""Cloud Health Resource Sharing Based on Consensus-Oriented Blockchain Technology: Case Study on a Breast Tumor Diagnosis Service""
""DC.Title"",""Cloud Health Resource Sharing Based on Consensus-Oriented Blockchain Technology: Case Study on a Breast Tumor Diagnosis Service""
""citation_authors"",""Xiaobao Zhu"",""Jing Shi"",""Cuiyuan Lu""
""msapplication-TileColor"",""#247CB3""
""citation_firstpage"",""e13767""
""viewport"",""width=device-width, initial-scale=1""
""DC.Creator"",""Xiaobao Zhu""
""DC.Language"",""EN""
""twitter:description"",""Background: In recent years, researchers have made significant efforts in advancing blockchain technology. This technology, with distinct features of decentralization and security, can be applied to many fields. In areas of health data and resource sharing, applications of blockchain technology are also emerging. Objective: In this study, we propose a cloud health resource-sharing model based on consensus-oriented blockchain technology and have developed a simulation study on breast tumor diagnosis. Methods: The proposed platform is built on a consortium or federated blockchain that possesses features of both centralization and decentralization. The consensus mechanisms generate operating standards for the proposed model. Open source Ethereum code is employed to provide the blockchain environment. Proof of Authority is selected as the consensus algorithm of block generation. Results: Based on the proposed model, a simulation case study for breast tumor classification is constructed. The simulation includes 9893 service requests from 100 users; 22 service providers are equipped with 22 different classification methods. Each request is fulfilled by a service provider recommended by the weighted k-nearest neighbors (KNN) algorithm. The majority of service requests are handled by 9 providers, and provider service evaluation scores tend to stabilize. Also, user priority on KNN weights significantly affects the system operation outcome. Conclusions: The proposed model is feasible based on the simulation case study for the cloud service of breast tumor diagnosis and has the potential to be applied to other applications. ""
""DC.Date"",""2019-07-23""
""DC.Source"",""J Med Internet Res 2019;21(7):e13767 https://www.jmir.org/2019/7/e13767""
""og:url"",""https://www.jmir.org/2019/7/e13767""
";https://scholar.google.com/scholar?start=70&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093487-333;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Insurance under the blockchain paradigm;P Tasca ; Business Transformation through Blockchain, 2019  Springer;;"… Smart contracts are probably the most important aspects of blockchain applying to insurance …

Oracles are digital or phisical agents that live outside smart contracts but are linked to them as …

In order to protect the policyholder, the oracle can certify that exactly on that day, time and …";Cité 7 fois;Les 3 versions;null;;;;https://scholar.google.com/scholar?start=170&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093473-274;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Blockchain Valuation: Internet of Value, digital networks and smart transactions;R Moro Visconti ; … Networks and Smart Transactions (February 9 …, 2019  papers.ssrn.com;;"… piece of code; smart contracts evaluate incoming data from an oracle and initiate a … not limited

to: • Software oracles; • Hardware oracles; • Inbound oracles; • Outbound oracles; • Consensus

based oracles … and may share the services and information that the blockchain offers or …";Cité 2 fois;Les 3 versions;[PDF] researchgate.net;https://www.researchgate.net/profile/Roberto_Moro_Visconti2/publication/329916782_Blockchain_Valuation_Internet_of_Value_digital_networks_and_smart_transactions/links/5c360d4e458515a4c718e088/Blockchain-Valuation-Internet-of-Value-digital-networks-and-smart-transactions.pdf;;;https://scholar.google.com/scholar?start=110&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093516-452;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;[PDF][PDF] Secured email data based on blowfish with blockchain technology;R Vasantha, RS Prasad, A Guntur ; Sci. Technol. Dev, 2019  journalstd.com;;"… Z. Liu, X. Tan, DS Wong, and C. Tang, “A CCA-secureidentity-based conditional proxy

re-encryption withoutrandom oracles,” in Proc … [15] L. Fang, W. Susilo, and J. Wang, “Anonymous

conditional proxyre-encryption without random oracle,” in Proc … Do you need a blockchain …";Cité 1 fois;;[PDF] journalstd.com;http://journalstd.com/gallery/49-nov2019.pdf;;"""date"",""2019-12-10T08:54:57Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.4""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dcterms:created"",""2019-12-10T08:54:57Z""
""language"",""en""
""Last-Modified"",""2019-12-10T08:54:57Z""
""dcterms:modified"",""2019-12-10T08:54:57Z""
""dc:format"",""application/pdf; version=1.4""
""Last-Save-Date"",""2019-12-10T08:54:57Z""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2019-12-10T08:54:57Z""
""meta:save-date"",""2019-12-10T08:54:57Z""
""pdf:encrypted"",""false""
""modified"",""2019-12-10T08:54:57Z""
""Content-Length"",""317075""
""pdf:hasMarkedContent"",""false""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""meta:creation-date"",""2019-12-10T08:54:57Z""
""created"",""2019-12-10T08:54:57Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""9""
""Creation-Date"",""2019-12-10T08:54:57Z""
""resourceName"",""49-nov2019.pdf""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""6280"",""6414"",""5148"",""2562"",""1799"",""277"",""265"",""4538"",""1842""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""producer"",""PlotSoft PDFill 12.0""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""PlotSoft PDFill 12.0""
""pdf:docinfo:created"",""2019-12-10T08:54:57Z""
";https://scholar.google.com/scholar?start=290&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093469-257;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;A taxonomic approach to understanding emerging blockchain identity management systems;L Lesavre, P Varin, P Mell, M Davidson… ; arXiv preprint arXiv …, 2019  arxiv.org;;"… […] Smart contracts must be deterministic, in that given an input, they will always produce

the same output based on that input.” Furthermore, a source of data from outside a blockchain

that serves as input for a smart contract is referred to as an oracle …";Cité 21 fois;Les 8 versions;[PDF] arxiv.org;https://arxiv.org/pdf/1908.00929;;"""date"",""2020-01-14T14:11:41Z""
""pdf:PDFVersion"",""1.6""
""xmp:CreatorTool"",""Acrobat PDFMaker 17 for Word""
""pdf:docinfo:title"",""A Taxonomic Approach to Understanding Emerging Blockchain Identity Management Systems""
""Company"",""Computer Security Division, ITL, NIST""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""Identity management systems (IDMSs) are widely used to provision user identities while managing authentication, authorization, and data sharing within organizations and on the web. Traditional identity systems typically suffer from single points of failure, lack of interoperability, and privacy issues, such as enabling mass data collection and user tracking. Blockchain technology has the potential to alleviate these concerns: it can support the ability for users to control the custody of their own identifiers and credentials, enabling novel data ownership and governance models with built-in control and consent mechanisms. Hence, blockchain-based IDMSs, which could benefit both users and businesses, are beginning to proliferate. This work categorizes these systems into a taxonomy based on differences in blockchain architectures, governance models, and other salient features. Context is provided for the taxonomy through the description of related terms, emerging standards, and use cases while highlighting relevant security and privacy considerations.""
""ContentTypeId"",""0x010100A19A607E1995BE4F837ED9551D1A24F9""
""language"",""en""
""dc:format"",""application/pdf; version=1.6""
""pdf:docinfo:custom:ShortTitleLine1"",""Blockchain Identity Management Approaches""
""pdf:docinfo:custom:ShortTitleLine2"",""text""
""pdf:docinfo:creator_tool"",""Acrobat PDFMaker 17 for Word""
""access_permission:fill_in_form"",""true""
""Publication Date"",""July 9, 2019""
""ShortTitleLine2"",""text""
""pdf:encrypted"",""false""
""dc:title"",""A Taxonomic Approach to Understanding Emerging Blockchain Identity Management Systems""
""ShortTitleLine1"",""Blockchain Identity Management Approaches""
""xmp:CreateDate"",""2020-01-14T08:43:48Z""
""modified"",""2020-01-14T14:11:41Z""
""pdf:docinfo:custom:SourceModified"",""""
""cp:subject"",""Identity management systems (IDMSs) are widely used to provision user identities while managing authentication, authorization, and data sharing within organizations and on the web. Traditional identity systems typically suffer from single points of failure, lack of interoperability, and privacy issues, such as enabling mass data collection and user tracking. Blockchain technology has the potential to alleviate these concerns: it can support the ability for users to control the custody of their own identifiers and credentials, enabling novel data ownership and governance models with built-in control and consent mechanisms. Hence, blockchain-based IDMSs, which could benefit both users and businesses, are beginning to proliferate. This work categorizes these systems into a taxonomy based on differences in blockchain architectures, governance models, and other salient features. Context is provided for the taxonomy through the description of related terms, emerging standards, and use cases while highlighting relevant security and privacy considerations.""
""pdf:docinfo:subject"",""Identity management systems (IDMSs) are widely used to provision user identities while managing authentication, authorization, and data sharing within organizations and on the web. Traditional identity systems typically suffer from single points of failure, lack of interoperability, and privacy issues, such as enabling mass data collection and user tracking. Blockchain technology has the potential to alleviate these concerns: it can support the ability for users to control the custody of their own identifiers and credentials, enabling novel data ownership and governance models with built-in control and consent mechanisms. Hence, blockchain-based IDMSs, which could benefit both users and businesses, are beginning to proliferate. This work categorizes these systems into a taxonomy based on differences in blockchain architectures, governance models, and other salient features. Context is provided for the taxonomy through the description of related terms, emerging standards, and use cases while highlighting relevant security and privacy considerations.""
""pdf:hasMarkedContent"",""true""
""xmp:ModifyDate"",""2020-01-14T09:11:41Z""
""pdf:docinfo:creator"",""LoĂŻc Lesavre""
""pdf:docinfo:custom:Publication Date"",""July 9, 2019""
""meta:author"",""LoĂŻc Lesavre"",""Priam Varin"",""Peter Mell"",""Michael Davidson"",""James Shook""
""meta:creation-date"",""2020-01-14T13:43:48Z""
""created"",""2020-01-14T13:43:48Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-01-14T13:43:48Z""
""resourceName"",""1908.00929""
""pdf:docinfo:custom:ContentTypeId"",""0x010100A19A607E1995BE4F837ED9551D1A24F9""
""Author"",""LoĂŻc Lesavre"",""Priam Varin"",""Peter Mell"",""Michael Davidson"",""James Shook""
""producer"",""Adobe PDF Library 15.0""
""pdf:docinfo:producer"",""Adobe PDF Library 15.0""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""dc:description"",""Identity management systems (IDMSs) are widely used to provision user identities while managing authentication, authorization, and data sharing within organizations and on the web. Traditional identity systems typically suffer from single points of failure, lack of interoperability, and privacy issues, such as enabling mass data collection and user tracking. Blockchain technology has the potential to alleviate these concerns: it can support the ability for users to control the custody of their own identifiers and credentials, enabling novel data ownership and governance models with built-in control and consent mechanisms. Hence, blockchain-based IDMSs, which could benefit both users and businesses, are beginning to proliferate. This work categorizes these systems into a taxonomy based on differences in blockchain architectures, governance models, and other salient features. Context is provided for the taxonomy through the description of related terms, emerging standards, and use cases while highlighting relevant security and privacy considerations.""
""Keywords"",""""""blockchain; credential; data ownership; decentralized identifier; distributed ledger; identity management; public key infrastructure; self-sovereign identity; smart contract; user-controlled identity wallet; zero-knowledge proof"""""",""""""blockchain; credential; data ownership; decentralized identifier; distributed ledger; identity management; public key infrastructure; self-sovereign identity; smart contract; user-controlled identity wallet; zero-knowledge proof""""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""LoĂŻc Lesavre"",""Priam Varin"",""Peter Mell"",""Michael Davidson"",""James Shook""
""description"",""Identity management systems (IDMSs) are widely used to provision user identities while managing authentication, authorization, and data sharing within organizations and on the web. Traditional identity systems typically suffer from single points of failure, lack of interoperability, and privacy issues, such as enabling mass data collection and user tracking. Blockchain technology has the potential to alleviate these concerns: it can support the ability for users to control the custody of their own identifiers and credentials, enabling novel data ownership and governance models with built-in control and consent mechanisms. Hence, blockchain-based IDMSs, which could benefit both users and businesses, are beginning to proliferate. This work categorizes these systems into a taxonomy based on differences in blockchain architectures, governance models, and other salient features. Context is provided for the taxonomy through the description of related terms, emerging standards, and use cases while highlighting relevant security and privacy considerations.""
""dcterms:created"",""2020-01-14T13:43:48Z""
""Last-Modified"",""2020-01-14T14:11:41Z""
""dcterms:modified"",""2020-01-14T14:11:41Z""
""title"",""A Taxonomic Approach to Understanding Emerging Blockchain Identity Management Systems""
""xmpMM:DocumentID"",""uuid:1c93fd8e-2e98-480e-9321-2c8d29eec495""
""Last-Save-Date"",""2020-01-14T14:11:41Z""
""pdf:docinfo:keywords"",""""""blockchain; credential; data ownership; decentralized identifier; distributed ledger; identity management; public key infrastructure; self-sovereign identity; smart contract; user-controlled identity wallet; zero-knowledge proof""""""
""pdf:docinfo:modified"",""2020-01-14T14:11:41Z""
""meta:save-date"",""2020-01-14T14:11:41Z""
""Content-Length"",""935712""
""Content-Type"",""application/pdf""
""xmp:MetadataDate"",""2020-01-14T09:11:41Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""LoĂŻc Lesavre"",""Priam Varin"",""Peter Mell"",""Michael Davidson"",""James Shook""
""dc:language"",""EN-US""
""pdf:producer"",""Adobe PDF Library 15.0""
""dc:subject"",""""""blockchain; credential; data ownership; decentralized identifier; distributed ledger; identity management; public key infrastructure; self-sovereign identity; smart contract; user-controlled identity wallet; zero-knowledge proof"""""",""""""blockchain; credential; data ownership; decentralized identifier; distributed ledger; identity management; public key infrastructure; self-sovereign identity; smart contract; user-controlled identity wallet; zero-knowledge proof""""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""62""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""375"",""2349"",""977"",""3314"",""3280"",""1352"",""1775"",""2342"",""2930"",""2300"",""3885"",""1915"",""1427"",""2302"",""2389"",""2334"",""2986"",""2710"",""2892"",""2186"",""2493"",""2339"",""3313"",""2613"",""1784"",""3257"",""2972"",""3363"",""3584"",""3253"",""3411"",""3165"",""2916"",""2895"",""3391"",""2958"",""1214"",""3123"",""3246"",""1580"",""2779"",""2850"",""2667"",""2776"",""3677"",""1141"",""2677"",""2669"",""1228"",""1591"",""2680"",""2583"",""2532"",""2335"",""2602"",""2363"",""1161"",""855"",""2209"",""2113"",""2108"",""1122""
""access_permission:extract_content"",""true""
""pdf:docinfo:custom:Company"",""Computer Security Division, ITL, NIST""
""access_permission:can_print"",""true""
""pdf:docinfo:custom:DOI value"",""NIST.CSWP.07092019-draft""
""SourceModified"",""""
""DOI value"",""NIST.CSWP.07092019-draft""
""meta:keyword"",""""""blockchain; credential; data ownership; decentralized identifier; distributed ledger; identity management; public key infrastructure; self-sovereign identity; smart contract; user-controlled identity wallet; zero-knowledge proof"""""",""""""blockchain; credential; data ownership; decentralized identifier; distributed ledger; identity management; public key infrastructure; self-sovereign identity; smart contract; user-controlled identity wallet; zero-knowledge proof""""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-01-14T13:43:48Z""
";https://scholar.google.com/scholar?start=90&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093536-548;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Blockchain and Public Procurement;R Carvalho ; European Journal of Comparative Law and …, 2019  brill.com;;"Jump to Content Jump to Main Navigation. English; ??; français; Deutsch. Access

via: Google Googlebot - Web Crawler SEO. Login to my Brill account Create Brill

Account. Publications. Subjects. African Studies American Studies …";Cité 3 fois;Les 2 versions;null;;;;https://scholar.google.com/scholar?start=380&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093480-304;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Internet of things and blockchain integration: Use cases and implementation challenges;G Kelechi, CM Akujuobi, MNO Sadiku… ; … , Seville, Spain, June …, 2019  books.google.com;;"… Data from oracles should therefore be properly authenticated using appropriate methods. Finally,

a smart contract should be developed following … oracle. com/us/solutions/cloud/tt-technologie

s-white-paper-4498079 … com Kiktenko, EO, et al.: Quantum-secured blockchain …";Cité 2 fois;;null;;;;https://scholar.google.com/scholar?start=140&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093530-517;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Modeling Reliable Intelligent Blockchain with Architectural Pattern;SB Ho, NA Ahmad, I Chai, CH Tan… ; International Conference of …, 2019  Springer;;"… categories, ie randomness, time constraint, token, math, termination, authorization, poll, oracle,

and fork … It usually covers data feeds, off-chain computing, oracles, wallets, digital assets … Unlike

Bitcoin, Ethereum is both a cryptocurrency and programmable blockchain for building a …";Autres articles;;null;;;;https://scholar.google.com/scholar?start=350&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093450-179;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;A blockchain-based model for cloud service quality monitoring;M Taghavi, J Bentahar, H Otrok… ; IEEE Transactions on …, 2019  ieeexplore.ieee.org;;"… To address the quality monitoring issue, we propose to employ oracles tailed to smart contracts

within an innovative multiagent decentralized model. A smart contract is a piece of code deployed

and executed on blockchain. Oracle in the blockchain context is a fully-trusted third …";Cité 6 fois;Les 3 versions;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/4629386/4629387/08873576.pdf?casa_token=JV9fHa3fVG0AAAAA:ROxteF5uGEhswFAurNqaSewf9c4sIRTbUSH1sC2jjW5-tXx45kpvCKeh6ki6ExAh3Cnn3xhEicY;;"""og:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""twitter:title"",""A Blockchain-Based Model for Cloud Service Quality Monitoring""
""twitter:card"",""summary""
""Description"",""This paper introduces a novel blockchain-based decentralized federation model that embodies quality verification for cloud providers who lease computing resourc""
""og:title"",""A Blockchain-Based Model for Cloud Service Quality Monitoring""
""resourceName"",""08873576.pdf""
""language"",""en""
""title"",""A Blockchain-Based Model for Cloud Service Quality Monitoring | IEEE Journals & Magazine | IEEE Xplore""
""og:description"",""This paper introduces a novel blockchain-based decentralized federation model that embodies quality verification for cloud providers who lease computing resources from each other. The blockchain structure removes the barriers of a traditional centralized federation and offers a fully distributed and transparent administration by enforcing the involved agents to maintain consensus on the data. For a blockchain-based federation, it is vital to avoid blind-trust on the claimed SLA guarantees and monitor the quality of service which is highly desirable considering the multi-tenancy characteristic of cloud services. Due to the fact that the blockchain network is unable to access the outside world, it cannot handle, by its own, providers misbehavior in terms of SLA violations. Thus, we introduce oracle as a verifier agent to monitor the quality of the service and report to the smart contract agents deployed on the blockchain. Oracle is a trusted third-party agent who can communicate with the outside world of the blockchain network. The interaction between cloud service providers (either providing a service or requesting it from another provider) and the oracle through smart contracts comprises a system of autonomous and utility maximizer agents. Cloud requesters seek to receive high quality services with constant monitoring at cheap prices or even with no charge, while cloud providers aim to have a balanced work-load with less preserved capacity, and the oracle tends to charge higher for their monitoring services. Therefore, to model this conflicting situation, we formulate a dynamic Stackelberg differential game to optimize the cost of using the oracle and maximize the profit of the agents with the role of provider agent as a leader, and the requester and verifier agents as followers. Our designed Stackelberg differential game can seize the dynamicity of users' demand and resource provisioning in a competitive cloud market. We implemented our proposed decentralized model using the Solidity language in the remix IDE on the Ethereum network. We further evaluated the optimal controls and agents' profit with real-world data simulated for three concrete cloud providers. The results revealed that the requester agent initiates most of the quality verification requests at the beginning to the middle time of the contract. Thus, the provider agent could reserve less computing resources considering the fact that it could share the workload among other customers' computing resources during the peak-time. Moreover, imposing a higher penalty on the provider agent increased the capacity and decreased the number of requests for quality verification at the equilibrium. The evaluation also disclosed that the impact of timing in the dynamic pricing strategy of the verifier agent is very minimal, and the provisioning capacity of the provider is strongly correlated with the monitoring price.""
""twitter:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-UA-Compatible"",""IE=Edge""
""viewport"",""width=device-width, initial-scale=1.0""
""dc:title"",""A Blockchain-Based Model for Cloud Service Quality Monitoring | IEEE Journals & Magazine | IEEE Xplore""
""twitter:description"",""This paper introduces a novel blockchain-based decentralized federation model that embodies quality verification for cloud providers who lease computing resources from each other. The blockchain structure removes the barriers of a traditional centralized federation and offers a fully distributed and transparent administration by enforcing the involved agents to maintain consensus on the data. For a blockchain-based federation, it is vital to avoid blind-trust on the claimed SLA guarantees and monitor the quality of service which is highly desirable considering the multi-tenancy characteristic of cloud services. Due to the fact that the blockchain network is unable to access the outside world, it cannot handle, by its own, providers misbehavior in terms of SLA violations. Thus, we introduce oracle as a verifier agent to monitor the quality of the service and report to the smart contract agents deployed on the blockchain. Oracle is a trusted third-party agent who can communicate with the outside world of the blockchain network. The interaction between cloud service providers (either providing a service or requesting it from another provider) and the oracle through smart contracts comprises a system of autonomous and utility maximizer agents. Cloud requesters seek to receive high quality services with constant monitoring at cheap prices or even with no charge, while cloud providers aim to have a balanced work-load with less preserved capacity, and the oracle tends to charge higher for their monitoring services. Therefore, to model this conflicting situation, we formulate a dynamic Stackelberg differential game to optimize the cost of using the oracle and maximize the profit of the agents with the role of provider agent as a leader, and the requester and verifier agents as followers. Our designed Stackelberg differential game can seize the dynamicity of users' demand and resource provisioning in a competitive cloud market. We implemented our proposed decentralized model using the Solidity language in the remix IDE on the Ethereum network. We further evaluated the optimal controls and agents' profit with real-world data simulated for three concrete cloud providers. The results revealed that the requester agent initiates most of the quality verification requests at the beginning to the middle time of the contract. Thus, the provider agent could reserve less computing resources considering the fact that it could share the workload among other customers' computing resources during the peak-time. Moreover, imposing a higher penalty on the provider agent increased the capacity and decreased the number of requests for quality verification at the equilibrium. The evaluation also disclosed that the impact of timing in the dynamic pricing strategy of the verifier agent is very minimal, and the provisioning capacity of the provider is strongly correlated with the monitoring price.""
""Content-Encoding"",""UTF-8""
""Content-Type-Hint"",""text/html; charset=utf-8""
""Content-Length"",""49166""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=10&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093523-486;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;[PDF][PDF] Modelling Business Processes on a Blockchain Eco-System (BPMN);M Markovska ; core.ac.uk;;"… its architecture, typology, existing applications, challenges and limitations as well as smart

contracts, oracles and hyperledger … Smart contracts are enabled and run on blockchain technology …

sources due to their architecture logic, a third-party technology called oracle fulfills this …";Autres articles;;[PDF] core.ac.uk;https://core.ac.uk/download/pdf/237084993.pdf;;"""pdf:docinfo:custom:Mendeley Recent Style Name 1_1"",""American Political Science Association""
""xmp:CreatorTool"",""Acrobat PDFMaker 10.0 для Word""
""pdf:docinfo:title"",""Modelling Business Processes on a Blockchain Eco-System (BPMN)""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""pdf:docinfo:custom:Mendeley Recent Style Name 5_1"",""Cite Them Right 10th edition - Harvard""
""pdf:docinfo:custom:Mendeley Unique User Id_1"",""f17aabe4-f0d7-310b-b8c3-6f5ab107d093""
""Mendeley Recent Style Name 7_1"",""Modern Humanities Research Association 3rd edition (note with bibliography)""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""Acrobat PDFMaker 10.0 для Word""
""access_permission:fill_in_form"",""true""
""dc:title"",""Modelling Business Processes on a Blockchain Eco-System (BPMN)""
""Mendeley Recent Style Name 3_1"",""American Sociological Association""
""xmp:CreateDate"",""2019-08-13T22:30:51Z""
""Mendeley Recent Style Id 3_1"",""http://www.zotero.org/styles/american-sociological-association""
""pdf:docinfo:custom:SourceModified"",""D:20190813193012""
""cp:subject"",""""
""xmp:ModifyDate"",""2019-08-13T22:31:13Z""
""pdf:docinfo:creator"",""Mariia Markovska""
""pdf:docinfo:custom:Mendeley Document_1"",""True""
""meta:creation-date"",""2019-08-13T19:30:51Z""
""Mendeley Recent Style Id 7_1"",""http://www.zotero.org/styles/modern-humanities-research-association""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-08-13T19:30:51Z""
""pdf:docinfo:custom:Mendeley Recent Style Id 6_1"",""http://www.zotero.org/styles/ieee""
""pdf:docinfo:custom:Mendeley Recent Style Id 2_1"",""http://www.zotero.org/styles/apa""
""Author"",""Mariia Markovska""
""pdf:docinfo:custom:Mendeley Recent Style Name 9_1"",""Nature""
""pdf:docinfo:custom:Mendeley Recent Style Name 2_1"",""American Psychological Association 6th edition""
""access_permission:modify_annotations"",""true""
""pdf:docinfo:custom:Mendeley Recent Style Name 6_1"",""IEEE""
""dc:creator"",""Mariia Markovska""
""Mendeley Recent Style Name 8_1"",""Modern Language Association 8th edition""
""Last-Modified"",""2019-08-13T19:31:13Z""
""Mendeley Recent Style Name 0_1"",""American Medical Association""
""Mendeley Recent Style Name 4_1"",""Chicago Manual of Style 17th edition (author-date)""
""Mendeley Recent Style Id 2_1"",""http://www.zotero.org/styles/apa""
""xmp:MetadataDate"",""2019-08-13T22:31:13Z""
""creator"",""Mariia Markovska""
""Mendeley Recent Style Id 6_1"",""http://www.zotero.org/styles/ieee""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""37""
""pdf:docinfo:custom:Mendeley Recent Style Id 5_1"",""http://www.zotero.org/styles/harvard-cite-them-right""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""281"",""2539"",""3018"",""3977"",""3742"",""2199"",""4314"",""4316"",""4190"",""4180"",""1833"",""4198"",""2264"",""4011"",""3635"",""4030"",""3746"",""3291"",""2947"",""69"",""774"",""2533"",""2296"",""102"",""3713"",""3586"",""1185"",""3352"",""3850"",""2847"",""3443"",""3585"",""4396"",""1486"",""3516"",""2780"",""1304""
""pdf:docinfo:custom:Mendeley Recent Style Id 1_1"",""http://www.zotero.org/styles/american-political-science-association""
""SourceModified"",""D:20190813193012""
""pdf:docinfo:custom:Mendeley Recent Style Id 9_1"",""http://www.zotero.org/styles/nature""
""access_permission:can_modify"",""true""
""date"",""2019-08-13T19:31:13Z""
""pdf:PDFVersion"",""1.5""
""Company"",""SPecialiST RePack""
""pdf:docinfo:custom:Mendeley Recent Style Name 3_1"",""American Sociological Association""
""subject"",""""
""pdf:docinfo:custom:Mendeley Recent Style Name 7_1"",""Modern Humanities Research Association 3rd edition (note with bibliography)""
""Mendeley Recent Style Name 9_1"",""Nature""
""language"",""en""
""Mendeley Recent Style Name 1_1"",""American Political Science Association""
""Mendeley Recent Style Name 5_1"",""Cite Them Right 10th edition - Harvard""
""pdf:encrypted"",""false""
""modified"",""2019-08-13T19:31:13Z""
""Mendeley Recent Style Id 5_1"",""http://www.zotero.org/styles/harvard-cite-them-right""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""true""
""Mendeley Recent Style Id 1_1"",""http://www.zotero.org/styles/american-political-science-association""
""pdf:docinfo:custom:Mendeley Recent Style Id 0_1"",""http://www.zotero.org/styles/american-medical-association""
""meta:author"",""Mariia Markovska""
""created"",""2019-08-13T19:30:51Z""
""Mendeley Recent Style Id 9_1"",""http://www.zotero.org/styles/nature""
""pdf:docinfo:custom:Mendeley Recent Style Id 8_1"",""http://www.zotero.org/styles/modern-language-association""
""resourceName"",""237084993.pdf""
""pdf:docinfo:custom:Mendeley Recent Style Id 4_1"",""http://www.zotero.org/styles/chicago-author-date""
""pdf:docinfo:custom:Comments"",""Äriprotsesside modelleerimine on plokiahela ökosüsteem""
""producer"",""Adobe PDF Library 10.0""
""pdf:docinfo:producer"",""Adobe PDF Library 10.0""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""Mendeley Document_1"",""True""
""pdf:docinfo:custom:Mendeley Recent Style Name 4_1"",""Chicago Manual of Style 17th edition (author-date)""
""Keywords"",""Blockchain, Smart Contracts, BPMN, Business Process Models."",""Blockchain, Smart Contracts, BPMN, Business Process Models.""
""pdf:docinfo:custom:Mendeley Recent Style Name 8_1"",""Modern Language Association 8th edition""
""dcterms:created"",""2019-08-13T19:30:51Z""
""Mendeley Recent Style Name 6_1"",""IEEE""
""dcterms:modified"",""2019-08-13T19:31:13Z""
""title"",""Modelling Business Processes on a Blockchain Eco-System (BPMN)""
""xmpMM:DocumentID"",""uuid:2f7e8823-66dd-4a04-9cf4-682a4329be85""
""Last-Save-Date"",""2019-08-13T19:31:13Z""
""pdf:docinfo:custom:Mendeley Recent Style Name 0_1"",""American Medical Association""
""pdf:docinfo:keywords"",""Blockchain, Smart Contracts, BPMN, Business Process Models.""
""pdf:docinfo:modified"",""2019-08-13T19:31:13Z""
""meta:save-date"",""2019-08-13T19:31:13Z""
""Mendeley Recent Style Name 2_1"",""American Psychological Association 6th edition""
""Mendeley Recent Style Id 4_1"",""http://www.zotero.org/styles/chicago-author-date""
""Content-Length"",""626972""
""Mendeley Recent Style Id 0_1"",""http://www.zotero.org/styles/american-medical-association""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""pdf:producer"",""Adobe PDF Library 10.0""
""dc:subject"",""Blockchain, Smart Contracts, BPMN, Business Process Models."",""Blockchain, Smart Contracts, BPMN, Business Process Models.""
""Comments"",""Äriprotsesside modelleerimine on plokiahela ökosüsteem""
""Mendeley Recent Style Id 8_1"",""http://www.zotero.org/styles/modern-language-association""
""pdf:docinfo:custom:Mendeley Recent Style Id 7_1"",""http://www.zotero.org/styles/modern-humanities-research-association""
""access_permission:extract_content"",""true""
""pdf:docinfo:custom:Company"",""SPecialiST RePack""
""pdf:docinfo:custom:Mendeley Recent Style Id 3_1"",""http://www.zotero.org/styles/american-sociological-association""
""access_permission:can_print"",""true""
""Mendeley Unique User Id_1"",""f17aabe4-f0d7-310b-b8c3-6f5ab107d093""
""meta:keyword"",""Blockchain, Smart Contracts, BPMN, Business Process Models."",""Blockchain, Smart Contracts, BPMN, Business Process Models.""
""pdf:docinfo:created"",""2019-08-13T19:30:51Z""
";https://scholar.google.com/scholar?start=320&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093527-505;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;MeshDapp–Blockchain-Enabled Sustainable Business Models for Networks;S Mosquera, F Freitag ; … of Grids, Clouds, Systems, and Services …, 2019  books.google.com;;"… blockchain that pro- vides desirable properties such as trusted data feeds (oracles) about traffic …

In the next section we sketch how a blockchain using smart contracts can implement the … 4

Conclusions We find the system, smart contract architecture, and the oracle to feed them …";Autres articles;;null;;;;https://scholar.google.com/scholar?start=340&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093492-354;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;[LIVRE][B] Cryptodemocracy: How Blockchain Can Radically Expand Democratic Choice;DWE Allen, C Berg, AM Lane ;2019 books.google.com;;"… 51 percent attack would not allow that entity to rewrite the history of the block- chain, it would

allow it to “double spend” Bitcoin—effectively the crypto- currency version of … Introduction 7 (either

an event internal to the blockchain, or external using an “oracle” to trigger the …";Cité 14 fois;;null;;;;https://scholar.google.com/scholar?start=190&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093543-580;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Enabling Data Democracy in Supply Chain using Blockchain and IoT;D Sachdev ; Journal of Management, 2019  papers.ssrn.com;;"… ENABLING DATA DEMOCRACY IN SUPPLY CHAIN USING BLOCKCHAIN AND IOT Deepika

Sachdev Vice President Delivery, Knowesis UPES, Dehradun … It examines Use Cases and

benefits of current IoT and Blockchain integrated frameworks for SCM …";Cité 4 fois;Les 3 versions;[PDF] academia.edu;https://www.academia.edu/download/58563500/JOM_06_01_008.pdf;;;https://scholar.google.com/scholar?start=410&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093462-230;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Blendmas: A blockchain-enabled decentralized microservices architecture for smart public safety;R Xu, SY Nikouei, Y Chen, E Blasch… ; … Blockchain (Blockchain …, 2019  ieeexplore.ieee.org;;"… C. Blockchain and Smart Contract As a fundamental technology of Bitcoin [19], blockchain initially

was used to promote a new cryptocurrency that performs … In this prototype, the laptop acts as a

cloud computing server, which takes role of oracle to manage blockchain network …";Cité 22 fois;Les 4 versions;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/8938397/8946120/08946177.pdf?casa_token=sHUL-u46v00AAAAA:ydJDqUGRhstI5I5XFFkjy4cQkKZ_ewk6QG2koK5xSloXQQTnh_07v_DjVjG5uMl-ywt0R9pjvBo;;"""og:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""twitter:title"",""BlendMAS: A Blockchain-Enabled Decentralized Microservices Architecture for Smart Public Safety""
""twitter:card"",""summary""
""Description"",""Thanks to rapid technological advances in the Internet of Things (IoT), a smart public safety (SPS) system has become feasible by integrating heterogeneous comp""
""og:title"",""BlendMAS: A Blockchain-Enabled Decentralized Microservices Architecture for Smart Public Safety""
""resourceName"",""08946177.pdf""
""language"",""en""
""title"",""BlendMAS: A Blockchain-Enabled Decentralized Microservices Architecture for Smart Public Safety | IEEE Conference Publication | IEEE Xplore""
""og:description"",""Thanks to rapid technological advances in the Internet of Things (IoT), a smart public safety (SPS) system has become feasible by integrating heterogeneous computing devices to collaboratively provide public protection services. While service-oriented architecture (SOA) has been adopted by IoT and cyber-physical systems (CPS), it is difficult for a monolithic architecture to provide scalable and extensible services for a distributed IoT based SPS system. Furthermore, traditional security solutions rely on a centralized authority, which can be a performance bottleneck or single point failure. Inspired by microservices architecture and blockchain technology, this paper proposes a BLockchain-ENabled Decentralized Microservices Architecture for Smart public safety (BlendMAS). Within a permissioned blockchain network, a microservices based security mechanism is introduced to secure data access control in an SPS system. The functionality of security services is decoupled into separate containerized microservices that are built using a smart contract and deployed on edge and fog computing nodes. An extensive experimental study verified that the proposed BlendMAS is able to offer a decentralized, scalable and secured data sharing and access control to distributed IoT based SPS system.""
""twitter:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-UA-Compatible"",""IE=Edge""
""viewport"",""width=device-width, initial-scale=1.0""
""dc:title"",""BlendMAS: A Blockchain-Enabled Decentralized Microservices Architecture for Smart Public Safety | IEEE Conference Publication | IEEE Xplore""
""twitter:description"",""Thanks to rapid technological advances in the Internet of Things (IoT), a smart public safety (SPS) system has become feasible by integrating heterogeneous computing devices to collaboratively provide public protection services. While service-oriented architecture (SOA) has been adopted by IoT and cyber-physical systems (CPS), it is difficult for a monolithic architecture to provide scalable and extensible services for a distributed IoT based SPS system. Furthermore, traditional security solutions rely on a centralized authority, which can be a performance bottleneck or single point failure. Inspired by microservices architecture and blockchain technology, this paper proposes a BLockchain-ENabled Decentralized Microservices Architecture for Smart public safety (BlendMAS). Within a permissioned blockchain network, a microservices based security mechanism is introduced to secure data access control in an SPS system. The functionality of security services is decoupled into separate containerized microservices that are built using a smart contract and deployed on edge and fog computing nodes. An extensive experimental study verified that the proposed BlendMAS is able to offer a decentralized, scalable and secured data sharing and access control to distributed IoT based SPS system.""
""Content-Encoding"",""UTF-8""
""Content-Type-Hint"",""text/html; charset=utf-8""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=60&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093492-351;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Embedded supervision: how to build regulation into blockchain finance;R Auer ;2019 papers.ssrn.com;;"… 2018) and HM Treasury-Financial Conduct Authority-Bank of England Crypto-assets Taskforce …

obligations, as well as links to relevant external information sources (oracles) and a … Market

participants transact on the blockchain, which records their transactions and obligations in …";Cité 20 fois;Les 14 versions;[PDF] bis.org;https://www.bis.org/publ/work811.pdf;;"""date"",""2019-09-16T06:55:35Z""
""pdf:PDFVersion"",""1.6""
""xmp:CreatorTool"",""Acrobat PDFMaker 17 for Word""
""pdf:docinfo:title"",""Embedded supervision: how to build regulation into blockchain finance""
""Company"",""Bank for International Settlements""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""BIS Working Papers No 811, September 2019""
""ContentTypeId"",""0x01010066E6577C753B40CABFD9C9409CB523E50074F00283ABEC80468AECD6D4A4A281F4""
""language"",""en""
""dc:format"",""application/pdf; version=1.6""
""pdf:docinfo:creator_tool"",""Acrobat PDFMaker 17 for Word""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""Embedded supervision: how to build regulation into blockchain finance""
""xmp:CreateDate"",""2019-09-15T22:02:13Z""
""modified"",""2019-09-16T06:55:35Z""
""pdf:docinfo:custom:SourceModified"",""D:20190915192523""
""cp:subject"",""BIS Working Papers No 811, September 2019""
""pdf:docinfo:custom:BisInstitution"",""""
""pdf:docinfo:subject"",""BIS Working Papers No 811, September 2019""
""pdf:hasMarkedContent"",""true""
""TaxKeyword"",""625;#Working Paper|34001c14-58c7-47f2-97eb-3d32f105d52f""
""xmp:ModifyDate"",""2019-09-16T08:55:35Z""
""pdf:docinfo:creator"",""Raphael Auer""
""pdf:docinfo:custom:TaxKeyword"",""625;#Working Paper|34001c14-58c7-47f2-97eb-3d32f105d52f""
""meta:author"",""Raphael Auer""
""meta:creation-date"",""2019-09-15T20:02:13Z""
""created"",""2019-09-15T20:02:13Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-09-15T20:02:13Z""
""pdf:docinfo:custom:BisAuthors"",""""
""resourceName"",""work811.pdf""
""pdf:docinfo:custom:_dlc_DocIdItemGuid"",""d1771302-02f3-42fa-b13f-63e417de27cb""
""pdf:docinfo:custom:ContentTypeId"",""0x01010066E6577C753B40CABFD9C9409CB523E50074F00283ABEC80468AECD6D4A4A281F4""
""pdf:docinfo:custom:Comments"",""Quick parts support on even and odd footer and headers/tables/boxes and graphs
Autotext functionalities deleted""
""Author"",""Raphael Auer""
""producer"",""Adobe PDF Library 15.0""
""pdf:docinfo:producer"",""Adobe PDF Library 15.0""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""dc:description"",""BIS Working Papers No 811, September 2019""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""Raphael Auer""
""description"",""BIS Working Papers No 811, September 2019""
""dcterms:created"",""2019-09-15T20:02:13Z""
""Last-Modified"",""2019-09-16T06:55:35Z""
""dcterms:modified"",""2019-09-16T06:55:35Z""
""title"",""Embedded supervision: how to build regulation into blockchain finance""
""xmpMM:DocumentID"",""uuid:98de91bb-e451-4b6b-935b-616819a8697a""
""Last-Save-Date"",""2019-09-16T06:55:35Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2019-09-16T06:55:35Z""
""pdf:docinfo:custom:BisRecipients"",""""
""meta:save-date"",""2019-09-16T06:55:35Z""
""Content-Length"",""1036027""
""Content-Type"",""application/pdf""
""BisDocumentType"",""479;#Working Paper|34001c14-58c7-47f2-97eb-3d32f105d52f""
""BisInstitution"",""""
""xmp:MetadataDate"",""2019-09-16T08:55:35Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Raphael Auer""
""dc:language"",""EN-GB""
""pdf:producer"",""Adobe PDF Library 15.0""
""dc:subject"",""""
""Comments"",""Quick parts support on even and odd footer and headers/tables/boxes and graphs
Autotext functionalities deleted""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""33""
""_dlc_DocIdItemGuid"",""d1771302-02f3-42fa-b13f-63e417de27cb""
""pdf:hasXMP"",""true""
""BisAuthors"",""""
""pdf:charsPerPage"",""663"",""658"",""2925"",""1464"",""3741"",""3457"",""3663"",""2935"",""2951"",""2515"",""3584"",""3838"",""2756"",""2111"",""3172"",""3654"",""3390"",""3692"",""3357"",""2839"",""3622"",""2578"",""2669"",""3620"",""3717"",""2634"",""3040"",""2601"",""2689"",""2826"",""1025"",""1945"",""2213""
""access_permission:extract_content"",""true""
""pdf:docinfo:custom:Company"",""Bank for International Settlements""
""access_permission:can_print"",""true""
""pdf:docinfo:custom:BisDocumentType"",""479;#Working Paper|34001c14-58c7-47f2-97eb-3d32f105d52f""
""SourceModified"",""D:20190915192523""
""meta:keyword"",""""
""BisRecipients"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-09-15T20:02:13Z""
";https://scholar.google.com/scholar?start=190&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093473-278;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;[HTML][HTML] Blockchain for Environmental Governance: Can Smart Contracts Reinforce Payments for Ecosystem Services in Namibia?;D Oberhauser ; Frontiers in Blockchain, 2019  frontiersin.org;Switzerland;"… The Ethereum smart contract uses an oracle to retrieve data from the off-chain world … If they do

not, a trusted intermediary is required which undermines the core concept of blockchain … in a fiat

currency like USD would first need to be converted to ETH using crypto-exchanges …";Cité 2 fois;Les 2 versions;[HTML] frontiersin.org;https://www.frontiersin.org/articles/10.3389/fbloc.2019.00021/full;;"""citation_keywords"",""community-based natural resource management (CBNRM); Payments for Ecosystem Services (PES); Blockchain; Smart contract; Land cover classfication""
""og:image"",""https://www.frontiersin.org/files/MyHome%20Article%20Library/463035/463035_Thumb_400.jpg""
""citation_publication_date"",""2019/11/21""
""citation_title"",""Blockchain for Environmental Governance: Can Smart Contracts Reinforce Payments for Ecosystem Services in Namibia?""
""citation_author_institution"",""School of Geography and the Environment, University of Oxford, United Kingdom""
""Description"",""The Global South harbors some of the planet's most precious natural resources and is hence key in addressing the pressing environmental challenges of the Anthropocene. Here, payments for ecosystem services (PES) have recently gained importance as a means of environmental governance, increasingly complementing conventional command-and-control approaches. For instance, climate change is now mitigated through carbon offset payments and biodiversity loss is addressed through wildlife conservation performance payments. However, such payment schemes in the Global South face numerous challenges as identified by a large body of literature. This paper investigates if blockchain technology can help address some of the challenges by reinforcing PES programs with tamper-proof blockchain smart contracts. To this end, the paper presents a proof-of-concept of a blockchain-based wildlife conservation performance payments scheme in Namibia: the habitat integrity of an elephant corridor is assessed by remote sensing algorithms, which in turn trigger fictitious blockchain smart contract payments to surrounding communities. The application allows to practically discuss the potential of blockchain technology regarding three key aspects of PES: (i) effectiveness (conditionality) of environmental monitoring (ii) efficiency and transaction costs, as well as (iii) equity and benefit distribution. The case presented here is an example for linking the digital Blockchain sphere to practical challenge...""
""Keywords"",""community-based natural resource management (CBNRM), Payments for Ecosystem Services (PES), Blockchain, Smart contract, Land cover classfication""
""citation_publisher"",""Frontiers""
""citation_journal_title"",""Frontiers in Blockchain""
""description"",""The Global South harbors some of the planet’s most precious natural resources and is hence key in addressing the pressing environmental challenges of the Anthropocene. Here, payments for ecosystem services (PES) have recently gained importance as a means of environmental governance, increasingly complementing conventional command-and-control approaches. For instance, climate change is now mitigated through carbon offset payments and biodiversity loss is addressed through wildlife conservation performance payments. However, such payment schemes in the Global South face numerous challenges as identified by a large body of literature. This paper investigates if blockchain technology can help address some of the challenges by reinforcing PES programs with tamper-proof blockchain smart contracts. To this end, the paper presents a proof-of-concept of a blockchain-based wildlife conservation performance payments scheme in Namibia: the habitat integrity of an elephant corridor is assessed by remote sensing algorithms, which in turn trigger fictitious blockchain smart contract payments to surrounding communities. The application allows to practically discuss the potential of blockchain technology regarding three key aspects of PES: (i) effectiveness (conditionality) of environmental monitoring (ii) efficiency and transaction costs, as well as (iii) equity and benefit distribution. The case presented here is an example for linking the digital Blockchain sphere to practical challenges of natural resource management in the physical world. As such, it illustrates some potentials of the technology, but also shows how Blockchain technology is unlikely to provide transformative solutions in geographies with complex environmental governance.""
""language"",""en""
""citation_date"",""2019""
""title"",""Frontiers | Blockchain for Environmental Governance: Can Smart Contracts Reinforce Payments for Ecosystem Services in Namibia? | Blockchain""
""citation_online_date"",""2019/11/06""
""citation_author_email"",""""
""citation_issn"",""2624-7852""
""dc:title"",""Frontiers | Blockchain for Environmental Governance: Can Smart Contracts Reinforce Payments for Ecosystem Services in Namibia? | Blockchain""
""citation_language"",""English""
""Content-Encoding"",""UTF-8""
""citation_pdf_url"",""https://www.frontiersin.org/articles/10.3389/fbloc.2019.00021/pdf""
""Content-Length"",""273290""
""Content-Type"",""text/html; charset=UTF-8""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""og:type"",""article""
""citation_journal_abbrev"",""Front. Blockchain""
""citation_abstract"",""The Global South harbors some of the planet’s most precious natural resources and is hence key in addressing the pressing environmental challenges of the Anthropocene. Here, payments for ecosystem services (PES) have recently gained importance as a means of environmental governance, increasingly complementing conventional command-and-control approaches. For instance, climate change is now mitigated through carbon offset payments and biodiversity loss is addressed through wildlife conservation performance payments. However, such payment schemes in the Global South face numerous challenges as identified by a large body of literature. This paper investigates if blockchain technology can help address some of the challenges by reinforcing PES programs with tamper-proof blockchain smart contracts. To this end, the paper presents a proof-of-concept of a blockchain-based wildlife conservation performance payments scheme in Namibia: the habitat integrity of an elephant corridor is assessed by remote sensing algorithms, which in turn trigger fictitious blockchain smart contract payments to surrounding communities. The application allows to practically discuss the potential of blockchain technology regarding three key aspects of PES: (i) effectiveness (conditionality) of environmental monitoring (ii) efficiency and transaction costs, as well as (iii) equity and benefit distribution. The case presented here is an example for linking the digital Blockchain sphere to practical challenges of natural resource management in the physical world. As such, it illustrates some potentials of the technology, but also shows how Blockchain technology is unlikely to provide transformative solutions in geographies with complex environmental governance.""
""citation_author"",""Oberhauser, Daniel""
""Title"",""Blockchain for Environmental Governance: Can Smart Contracts Reinforce Payments for Ecosystem Services in Namibia?""
""resourceName"",""full""
""citation_pages"",""21""
""url"",""https://www.frontiersin.org/article/10.3389/fbloc.2019.00021/full""
""site_name"",""Frontiers""
""X-UA-Compatible"",""IE=edge""
""frontiers:type"",""Article""
""viewport"",""width=device-width, initial-scale=1, maximum-scale=1""
""citation_doi"",""10.3389/fbloc.2019.00021""
""dc.identifier"",""doi:10.3389/fbloc.2019.00021""
""citation_volume"",""2""
""Content-Language"",""en""
";https://scholar.google.com/scholar?start=110&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093483-312;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Building redactable consortium blockchain for industrial Internet-of-Things;K Huang, X Zhang, Y Mu, X Wang… ; IEEE Transactions …, 2019  ieeexplore.ieee.org;;"… Authorized sensors (aka sanitizers or receivers): k sensors which are authorized to write and

redact blockchain by collab- oration … identity CID, no ad- versary can efficiently find a collision

for a given TCH.Hash(CID,m,r) even if the adversary can query random oracle TCH.Hash …";Cité 20 fois;Les 2 versions;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/9424/8736410/08649750.pdf?casa_token=2v5vRHYXyk4AAAAA:Sj0yAsfGcstVjDMR1dp8mHWB5RR9bEGhjxfPNnycJvumhF8Qozrck2nMYL0IWkn-_NS2LFlaHmo;;"""og:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""twitter:title"",""Building Redactable Consortium Blockchain for Industrial Internet-of-Things""
""twitter:card"",""summary""
""Description"",""Applying consortium blockchain as a trust layer for heterogeneous industrial Internet-of-Things devices is cost-effective. However, with an increase in computin""
""og:title"",""Building Redactable Consortium Blockchain for Industrial Internet-of-Things""
""resourceName"",""08649750.pdf""
""language"",""en""
""title"",""Building Redactable Consortium Blockchain for Industrial Internet-of-Things | IEEE Journals & Magazine | IEEE Xplore""
""og:description"",""Applying consortium blockchain as a trust layer for heterogeneous industrial Internet-of-Things devices is cost-effective. However, with an increase in computing power, some powerful attacks (e.g., the 51% attack) are inevitable and will cause severe consequences. Recent studies also confirm that anonymity and immutability of blockchain have been abused to facilitate black market trades, etc. To operate controllable blockchain for IIoT devices, it is necessary to rewrite blockchain history back to a normal state once the chain is breached. Ateniese et al. proposed redactable blockchain by using chameleon hash (CH) to replace traditional hash function, it allows blockchain history to be written when needed (EuroS&P 2017). However, we cannot apply this idea directly to IIoT without solving the following problems: (1) achieve a decentralized design of CH; (2) update the signatures accordingly to authenticate the redacted contents; (3) satisfy the low-computing need of the individual IIoT device. In this paper, we overcome the above issues by proposing the first threshold chameleon hash (TCH) and accountable-and-sanitizable chameleon signature (ASCS) schemes. Based on them, we build a redactable consortium blockchain which is efficient for IIoT devices to operate. It allows a group of authorized sensors to write and rewrite blockchain without causing any hard forks. Basically, TCH is the first TCH and ASCS is a public-key signature supporting file-level and block-level modifications of signatures without impairing authentications. Additionally, ASCS achieves accountability to avoid abuse of redaction. While security analysis validates our proposals, the simulation results show that redaction is acceptably efficient if it is executed at a small scale or if we adopt a coarse-grained redaction while sacrificing some securities.""
""twitter:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-UA-Compatible"",""IE=Edge""
""viewport"",""width=device-width, initial-scale=1.0""
""dc:title"",""Building Redactable Consortium Blockchain for Industrial Internet-of-Things | IEEE Journals & Magazine | IEEE Xplore""
""twitter:description"",""Applying consortium blockchain as a trust layer for heterogeneous industrial Internet-of-Things devices is cost-effective. However, with an increase in computing power, some powerful attacks (e.g., the 51% attack) are inevitable and will cause severe consequences. Recent studies also confirm that anonymity and immutability of blockchain have been abused to facilitate black market trades, etc. To operate controllable blockchain for IIoT devices, it is necessary to rewrite blockchain history back to a normal state once the chain is breached. Ateniese et al. proposed redactable blockchain by using chameleon hash (CH) to replace traditional hash function, it allows blockchain history to be written when needed (EuroS&P 2017). However, we cannot apply this idea directly to IIoT without solving the following problems: (1) achieve a decentralized design of CH; (2) update the signatures accordingly to authenticate the redacted contents; (3) satisfy the low-computing need of the individual IIoT device. In this paper, we overcome the above issues by proposing the first threshold chameleon hash (TCH) and accountable-and-sanitizable chameleon signature (ASCS) schemes. Based on them, we build a redactable consortium blockchain which is efficient for IIoT devices to operate. It allows a group of authorized sensors to write and rewrite blockchain without causing any hard forks. Basically, TCH is the first TCH and ASCS is a public-key signature supporting file-level and block-level modifications of signatures without impairing authentications. Additionally, ASCS achieves accountability to avoid abuse of redaction. While security analysis validates our proposals, the simulation results show that redaction is acceptably efficient if it is executed at a small scale or if we adopt a coarse-grained redaction while sacrificing some securities.""
""Content-Encoding"",""UTF-8""
""Content-Type-Hint"",""text/html; charset=utf-8""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=150&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093534-536;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Die Blockchain-Technologie;S Schacht ; Blockchain und maschinelles Lernen, 2019  Springer;;"… Blockchain und maschinelles Lernen pp 3-87 | Cite as. Die Blockchain-Technologie.

Authors; Authors and affiliations. Sigurd … zehn Jahren zu erwarten ist. 2.2 Blockchain

und Distributed-Ledger-Technologie: Eine kurze Einführung …";Autres articles;;null;;;;https://scholar.google.com/scholar?start=370&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093448-170;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Probabilistic smart contracts: Secure randomness on the blockchain;K Chatterjee, AK Goharshady… ; … and Cryptocurrency  …, 2019  ieeexplore.ieee.org;;"… due to potential tampering by the miners. Oracles [58]. Another approach is to use

an Oracle [55, 59]. By design, smart contracts can only access data that is written

on the blockchain [12]. Oracles are third-party services that …";Cité 25 fois;Les 10 versions;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/8744142/8751228/08751326.pdf?casa_token=S-U0lIP8SRIAAAAA:hm39mRs8vIa4zIG2HrlumK5wj6XGN5z_motNhommKFQAKEfACrOpbLGuKvB8y5cUSru7KLJm9BQ;;"""og:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""twitter:title"",""Probabilistic Smart Contracts: Secure Randomness on the Blockchain""
""twitter:card"",""summary""
""Description"",""In today's programmable blockchains, smart contracts are limited to being deterministic and non-probabilistic. This lack of randomness is a consequential limita""
""og:title"",""Probabilistic Smart Contracts: Secure Randomness on the Blockchain""
""resourceName"",""08751326.pdf""
""language"",""en""
""title"",""Probabilistic Smart Contracts: Secure Randomness on the Blockchain | IEEE Conference Publication | IEEE Xplore""
""og:description"",""In today's programmable blockchains, smart contracts are limited to being deterministic and non-probabilistic. This lack of randomness is a consequential limitation, given that a wide variety of real-world financial contracts, such as casino games and lotteries, depend entirely on randomness. As a result, several ad-hoc random number generation approaches have been developed to be used in smart contracts. These include ideas such as using an oracle or relying on the block hash. However, these approaches are manipulatable, i.e. their output can be tampered with by parties who might not be neutral, such as the owner of the oracle or the miners.We propose a novel game-theoretic approach for generating provably unmanipulatable pseudorandom numbers on the blockchain. Our approach allows smart contracts to access a trustworthy source of randomness that does not rely on potentially compromised miners or oracles, hence enabling the creation of a new generation of smart contracts that are not limited to being non-probabilistic and can be drawn from the much more general class of probabilistic programs.""
""twitter:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-UA-Compatible"",""IE=Edge""
""viewport"",""width=device-width, initial-scale=1.0""
""dc:title"",""Probabilistic Smart Contracts: Secure Randomness on the Blockchain | IEEE Conference Publication | IEEE Xplore""
""twitter:description"",""In today's programmable blockchains, smart contracts are limited to being deterministic and non-probabilistic. This lack of randomness is a consequential limitation, given that a wide variety of real-world financial contracts, such as casino games and lotteries, depend entirely on randomness. As a result, several ad-hoc random number generation approaches have been developed to be used in smart contracts. These include ideas such as using an oracle or relying on the block hash. However, these approaches are manipulatable, i.e. their output can be tampered with by parties who might not be neutral, such as the owner of the oracle or the miners.We propose a novel game-theoretic approach for generating provably unmanipulatable pseudorandom numbers on the blockchain. Our approach allows smart contracts to access a trustworthy source of randomness that does not rely on potentially compromised miners or oracles, hence enabling the creation of a new generation of smart contracts that are not limited to being non-probabilistic and can be drawn from the much more general class of probabilistic programs.""
""Content-Encoding"",""UTF-8""
""Content-Type-Hint"",""text/html; charset=utf-8""
""Content-Length"",""41156""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";
1619093520-473;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;[PDF][PDF] The implications of blockchain technology on supply chain management and the potential benefits and barriers to its utilization in procurement;Y Kleinman ;2019 minds.wisconsin.edu;;"… So, after the great and mighty Amazon has declared their intentions, Oracle has responded

with an investment in blockchain (Wood, 2018) … relied upon for validation. IV. Crypto logically

secure – Any legitimate blockchain system must utilize a form of …";Cité 1 fois;Les 2 versions;[PDF] wisconsin.edu;https://minds.wisconsin.edu/bitstream/handle/1793/79330/Kleinman,%20Yehuda.pdf?sequence=1;;"""date"",""2019-05-29T16:32:47Z""
""pdf:PDFVersion"",""1.6""
""xmp:CreatorTool"",""Aspose Ltd.""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""language"",""en""
""dc:format"",""application/pdf; version=1.6""
""pdf:docinfo:creator_tool"",""Aspose Ltd.""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""xmp:CreateDate"",""2019-05-06T02:06:00Z""
""modified"",""2019-05-29T16:32:47Z""
""pdf:hasMarkedContent"",""false""
""xmp:ModifyDate"",""2019-05-29T11:32:47Z""
""pdf:docinfo:creator"",""Alex Kleinman""
""meta:author"",""Alex Kleinman""
""meta:creation-date"",""2019-05-06T02:06:00Z""
""created"",""2019-05-06T02:06:00Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-05-06T02:06:00Z""
""resourceName"",""Kleinman,%20Yehuda.pdf""
""Author"",""Alex Kleinman""
""producer"",""Aspose.PDF for Java 18.3""
""pdf:docinfo:producer"",""Aspose.PDF for Java 18.3""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""access_permission:modify_annotations"",""true""
""dc:creator"",""Alex Kleinman""
""dcterms:created"",""2019-05-06T02:06:00Z""
""Last-Modified"",""2019-05-29T16:32:47Z""
""dcterms:modified"",""2019-05-29T16:32:47Z""
""xmpMM:DocumentID"",""uuid:bbec07a5-1f84-4dcc-a576-3e75686efb0b""
""Last-Save-Date"",""2019-05-29T16:32:47Z""
""pdf:docinfo:modified"",""2019-05-29T16:32:47Z""
""meta:save-date"",""2019-05-29T16:32:47Z""
""Content-Length"",""568622""
""Content-Type"",""application/pdf""
""xmp:MetadataDate"",""2019-05-29T11:32:47Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Alex Kleinman""
""dc:language"",""en-US""
""pdf:producer"",""Aspose.PDF for Java 18.3""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""42""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""773"",""422"",""1938"",""1889"",""2112"",""1290"",""2120"",""2125"",""1665"",""1378"",""1776"",""1833"",""1605"",""659"",""1568"",""1654"",""1837"",""885"",""1495"",""1330"",""1503"",""1535"",""1518"",""1514"",""1232"",""2133"",""2059"",""1860"",""1603"",""1809"",""844"",""1660"",""1972"",""2091"",""1850"",""1856"",""1717"",""638"",""1311"",""1340"",""1151"",""801""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-05-06T02:06:00Z""
";https://scholar.google.com/scholar?start=310&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093480-303;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;How to regulate bitcoin? Decentralized regulation for a decentralized cryptocurrency;H Nabilou ; International Journal of Law and Information …, 2019  academic.oup.com;;"… 68 Not only can the reliance on the oracles reduce the level of trustlessness of transaction on

the blockchain—long advocated by cryptocurrency enthusiasts—but also they become choke

points for the purposes of regulation, where the law can target blockchain transactions …";Cité 17 fois;Les 10 versions;[PDF] oup.com;https://academic.oup.com/ijlit/article-pdf/27/3/266/30251307/eaz008.pdf?casa_token=kC_me_nIhNoAAAAA:7W9C8qOH_zjYTf35ZRwfovxmKQYIFb7oBQsQuX6ABsfqr0sGZMKsyaB1im2-egk-RhzRBQ_NqP4;;"""msapplication-config"",""//oup.silverchair-cdn.com/UI/app/img/v-637520497125602725/browserconfig.xml""
""og:image"",""https://oup.silverchair-cdn.com/oup/backfile/Content_public/Journal/ijlit/Issue/27/3/1/m_inttec_27_3cover.png?Expires=1681895738&Signature=nMMeD6DuS-5zuw~VhtZJR2CPmLYNxXoFJnWLnTCIkzy1NtFLPrlPMKLh3TXXQVrevaORlUjn-lYY50cPqxFYmqRiltcUtV9dYIeaLwxHb3p4EkdfKhGoGhk~nCkV3ZsvuPTAENtts2FOVHGzcnP39Tgh4dhwHJ33uZqtFz6pvslwrhq-P1yvhevrdz5u-4Uc4gOHP9Qflbs~9mum4K3zPr3RzuVHlaFB2v48sTSKwBnD6xgSWnv96kumXJ1CJ-mMUurShiJ7Cw8Q-USu4Ed3JRKIUS1Pv14ueK3T9179I6B9XeHR7a4HVsrQ09XOLbHFy4KC67XZ~B9BZCDQ5Ds1ig__&Key-Pair-Id=APKAIE5G5CRDK6RD3PGA""
""citation_publication_date"",""2019/09/01""
""theme-color"",""#002f65""
""citation_author_institution"",""Postdoctoral Researcher in Banking and Financial Law, Faculty of Law, Economics and Finance, University of Luxembourg"",""Research Associate, Amsterdam Centre for Law and Economics (ACLE), and University College London Center for Blockchain Technologies (UCL CBT)""
""citation_title"",""How to regulate bitcoin? Decentralized regulation for a decentralized cryptocurrency""
""og:site_name"",""OUP Academic""
""citation_publisher"",""Oxford Academic""
""citation_journal_title"",""International Journal of Law and Information Technology""
""description"",""Abstract. Bitcoin is a distributed system. The dilemma it poses to the legal systems is that it is hardly possible to regulate a distributed network in a centra""
""language"",""en""
""title"",""How to regulate bitcoin? Decentralized regulation for a decentralized cryptocurrency | International Journal of Law and Information Technology | Oxford Academic""
""og:description"",""Abstract. Bitcoin is a distributed system. The dilemma it poses to the legal systems is that it is hardly possible to regulate a distributed network in a centra""
""citation_issn"",""0967-0769""
""dc:title"",""How to regulate bitcoin? Decentralized regulation for a decentralized cryptocurrency | International Journal of Law and Information Technology | Oxford Academic""
""Content-Encoding"",""UTF-8""
""Content-Type-Hint"",""text/html; charset=utf-8""
""citation_pdf_url"",""https://academic.oup.com/ijlit/article-pdf/27/3/266/30251307/eaz008.pdf""
""Content-Length"",""84612""
""citation_xml_url"",""https://academic.oup.com/ijlit/article-xml/27/3/266/5566421""
""citation_lastpage"",""291""
""Content-Type"",""text/html; charset=UTF-8""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""og:type"",""article""
""citation_journal_abbrev"",""Int J Law Info Tech""
""og:title"",""How to regulate bitcoin? Decentralized regulation for a decentralized cryptocurrency""
""citation_author"",""Nabilou, Hossein""
""resourceName"",""eaz008.pdf""
""og:updated_time"",""2019-09-09""
""citation_issue"",""3""
""X-UA-Compatible"",""IE=Edge""
""citation_firstpage"",""266""
""viewport"",""width=device-width, initial-scale=1, maximum-scale=1""
""citation_doi"",""10.1093/ijlit/eaz008""
""citation_volume"",""27""
""og:url"",""https://academic.oup.com/ijlit/article/27/3/266/5566421""
""Content-Language"",""en""
""format-detection"",""telephone=no""
";https://scholar.google.com/scholar?start=140&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093492-353;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Overview of attack surfaces in Blockchain;M Saad, J Spaulding, L Njilla… ; Blockchain for …, 2019  books.google.com;;"… Apostolaki et al.[44] stud- ied routing attacks on cryptocurrency and analyzed the hijacking of

Bor … 3 M. Bellare and P. Rogaway,“Random oracles are practical: A paradigm for designing efficient

protocols … 13 14 15 16 17 18 19 20 3 Overview of Attack Surfaces in Blockchain 63 JA …";Cité 9 fois;Les 3 versions;null;;;;https://scholar.google.com/scholar?start=190&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093480-310;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;[PDF][PDF] Blockchain and Insurance: Disproportionate Hope or New Era?;A Derbali, MB Chenguel, L Jamel, M Jouirou… ; International …, 2019  researchgate.net;;"… to a smart contract, the blockchain manages the contract, and the ""oracle"" triggers compensation …

the fraud in the declaration of the incident (the connected objects acting as ""oracles"") … The

blockchain also allows the acquisition of cryptocurrency assets mainly in presence of the …";Autres articles;Version HTML;[PDF] researchgate.net;https://www.researchgate.net/profile/Mohamed_Chenguel/publication/344630802_Blockchain_and_Insurance_Disproportionate_Hope_or_New_Era/links/5f85a0cd92851c14bcc3b5b3/Blockchain-and-Insurance-Disproportionate-Hope-or-New-Era.pdf;;;https://scholar.google.com/scholar?start=140&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093473-277;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;[PDF][PDF] Blockchain technology and BIM process: review and potential applications.;NO Nawari, S Ravindran ; ITcon, 2019  researchgate.net;;"… Blockchain was first used in Bitcoin, the first cryptocurrency to achieve widespread

circulation and mainstream appeal … Blockchain 2.0 is an umbrella term denoting these new

developments and widening the uses of DLT beyond cryptocurrency …";Cité 30 fois;Les 3 versions;[PDF] researchgate.net;https://www.researchgate.net/profile/Shriraam_Ravindran/publication/333369406_Blockchain_technology_and_BIM_process_review_and_potential_applications/links/5ce8aeb792851c4eabbc4f46/Blockchain-technology-and-BIM-process-review-and-potential-applications.pdf;;;https://scholar.google.com/scholar?start=110&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093478-291;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Blockchain-based personal data management: From fiction to solution;NB Truong, K Sun, Y Guo ; 2019 IEEE 18th International …, 2019  ieeexplore.ieee.org;;"… II. BACKGROUND AND RELATED WORK A. Blockchain Technology BC technology comprises

of diversified … Currently, there is no solution tackling the Oracle problem on personal data … Moreover,

with the existing solution approaches, such Oracles have to handle bursts of …";Cité 4 fois;Les 6 versions;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/8930311/8935004/08935049.pdf?casa_token=9SwDBayTVFcAAAAA:XTKLT0OtOZKSlyfdjzQ9D-QbvglF4SYLulyHgx4iucnEsOjEYsNphzIhbgr-cRYJgEBz32itFx4;;"""og:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""twitter:title"",""Blockchain-based Personal Data Management: From Fiction to Solution""
""twitter:card"",""summary""
""Description"",""The emerging blockchain technology has enabled various decentralised applications in a trustless environment without relying on a trusted intermediary. It is ex""
""og:title"",""Blockchain-based Personal Data Management: From Fiction to Solution""
""resourceName"",""08935049.pdf""
""language"",""en""
""title"",""Blockchain-based Personal Data Management: From Fiction to Solution | IEEE Conference Publication | IEEE Xplore""
""og:description"",""The emerging blockchain technology has enabled various decentralised applications in a trustless environment without relying on a trusted intermediary. It is expected as a promising solution to tackle sophisticated challenges on personal data management, thanks to its advanced features such as immutability, decentralisation and transparency. Although certain approaches have been proposed to address technical difficulties in personal data management; most of them only provided preliminary methodological exploration. Alarmingly, when utilising Blockchain for developing a personal data management system, fictions have occurred in existing approaches and been promulgated in the literature. Such fictions are theoretically doable; however, by thoroughly breaking down consensus protocols and transaction validation processes, we clarify that such existing approaches are either impractical or highly inefficient due to the natural limitations of the blockchain and Smart Contracts technologies. This encourages us to propose a feasible solution in which such fictions are reduced by designing a novel system architecture with a blockchain-based “proof of permission” protocol. We demonstrate the feasibility and efficiency of the proposed models by implementing a clinical data sharing service built on top of a public blockchain platform. We believe that our research resolves existing ambiguity and take a step further on providing a practically feasible solution for decentralised personal data management.""
""twitter:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-UA-Compatible"",""IE=Edge""
""viewport"",""width=device-width, initial-scale=1.0""
""dc:title"",""Blockchain-based Personal Data Management: From Fiction to Solution | IEEE Conference Publication | IEEE Xplore""
""twitter:description"",""The emerging blockchain technology has enabled various decentralised applications in a trustless environment without relying on a trusted intermediary. It is expected as a promising solution to tackle sophisticated challenges on personal data management, thanks to its advanced features such as immutability, decentralisation and transparency. Although certain approaches have been proposed to address technical difficulties in personal data management; most of them only provided preliminary methodological exploration. Alarmingly, when utilising Blockchain for developing a personal data management system, fictions have occurred in existing approaches and been promulgated in the literature. Such fictions are theoretically doable; however, by thoroughly breaking down consensus protocols and transaction validation processes, we clarify that such existing approaches are either impractical or highly inefficient due to the natural limitations of the blockchain and Smart Contracts technologies. This encourages us to propose a feasible solution in which such fictions are reduced by designing a novel system architecture with a blockchain-based “proof of permission” protocol. We demonstrate the feasibility and efficiency of the proposed models by implementing a clinical data sharing service built on top of a public blockchain platform. We believe that our research resolves existing ambiguity and take a step further on providing a practically feasible solution for decentralised personal data management.""
""Content-Encoding"",""UTF-8""
""Content-Type-Hint"",""text/html; charset=utf-8""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=130&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093473-271;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;EverSSDI: blockchain-based framework for verification, authorisation and recovery of self-sovereign identity using smart contracts;T Zhou, X Li, H Zhao ; International Journal of Computer …, 2019  inderscienceonline.com;;"… In addition, two novel methods are proposed for identity recovery, one of which is based on Social

Networking Services (SNS) authorisation and the other Ethereum Oracles … Blockchain, as the core

technology of cryptocurrency such as Bitcoin (Nakamoto, 2008), is a …";Cité 7 fois;Les 3 versions;null;;;;https://scholar.google.com/scholar?start=110&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093511-433;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Splitting and Aggregating Signatures in Cryptocurrency Protocols;SSD Selvi, A Paul, CP Rangan… ; 2019 IEEE …, 2019  ieeexplore.ieee.org;;"… of the most computationally intense and most frequently used cryptographic primitives in

blockchain technology is … Training Phase : During this phase, F is given access to the following

oracles provided by … When F queries the oracle H with a message m ? {0, 1}lm and public …";Autres articles;;[PDF] iitm.ac.in;https://www.cse.iitm.ac.in/~arinjita/papers/dappcon3.pdf;;"""date"",""2019-06-03T19:31:25Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""2"",""5"",""13"",""28"",""34"",""15"",""0"",""0""
""pdf:PDFVersion"",""1.5""
""xmp:CreatorTool"",""TeX""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dcterms:created"",""2019-06-03T19:31:25Z""
""language"",""en""
""Last-Modified"",""2019-06-03T19:31:25Z""
""dcterms:modified"",""2019-06-03T19:31:25Z""
""dc:format"",""application/pdf; version=1.5""
""Last-Save-Date"",""2019-06-03T19:31:25Z""
""pdf:docinfo:creator_tool"",""TeX""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2019-06-03T19:31:25Z""
""meta:save-date"",""2019-06-03T19:31:25Z""
""pdf:encrypted"",""false""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017) kpathsea version 6.2.3""
""modified"",""2019-06-03T19:31:25Z""
""Content-Length"",""276759""
""pdf:hasMarkedContent"",""false""
""Content-Type"",""application/pdf""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017) kpathsea version 6.2.3""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""trapped"",""False""
""meta:creation-date"",""2019-06-03T19:31:25Z""
""created"",""2019-06-03T19:31:25Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""9""
""Creation-Date"",""2019-06-03T19:31:25Z""
""resourceName"",""dappcon3.pdf""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""4259"",""4409"",""4338"",""3372"",""3734"",""3497"",""3737"",""3072"",""1755""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""producer"",""pdfTeX-1.40.18""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""pdfTeX-1.40.18""
""pdf:docinfo:created"",""2019-06-03T19:31:25Z""
";https://scholar.google.com/scholar?start=270&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093494-364;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Blockchain Technology and the Theory of Economic Development;DWE Allen, C Berg, J Potts ; Available at SSRN 3333568, 2019  papers.ssrn.com;;"… A second challenge is oracles. Oracles are mechanisms to provide information to smart contracts

exogenous of the blockchain itself. An example might be a contract that is triggered when a stock

market index reaches a certain value. The oracle in this case—a device …";Cité 1 fois;;null;;;;https://scholar.google.com/scholar?start=200&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093536-547;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;[CITATION][C] Ari Juels? Lorenz Breidenbach? Alex Coventry Sergey Nazarov Steve Ellis Brendan Magauran v1. 0 3 September 2019;S Nazarov ;2019;;null;Autres articles;;null;;;;https://scholar.google.com/scholar?start=380&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093504-407;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;[LIVRE][B] Advanced Blockchain Development: Build highly secure, decentralized applications and conduct secure transactions;I Bashir, N Prusty ;2019 books.google.com;;"… Payment and state channels 79 Proof-of-stake and casper Sharding Summary 79 80 80 Chapter

4: Smart Contracts History 81 81 Definition Ricardian contracts Smart contract templates 82 85

89 Oracles 90 Smart Oracles 93 Deploying smart contracts on a blockchain 93 The …";Cité 4 fois;;null;;;;https://scholar.google.com/scholar?start=240&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093527-501;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;[CITATION][C] DUALCHAIN WHITEPAPER;A Lightman, E Gu, K Huang, C Hao ; mvsdna.com;;"… outside knowledge of. This is where Oracles providers like KrawlCat Generalized

Oracle come in. Oracles bring off- chain data, some of which we've described above,

onto the blockchain. We could think of this as migration of …";Cité 1 fois;;null;;;;https://scholar.google.com/scholar?start=340&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093455-199;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Reliable decentralized oracle with mechanisms for verification and disputation;L Ma, K Kaneko, S Sharma… ; … Symposium on Computing …, 2019  ieeexplore.ieee.org;;"… Owing to the fact that getting real profits requires a high level of reputation, one of the incentives

to be a verifier is to earn reputation, ultimately become a reporter for most requests to get real

benefits (cryptocurrency) … Astraea: A decentralized blockchain oracle …";Cité 3 fois;Les 3 versions;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/8945148/8951516/08951647.pdf?casa_token=ChcUVWwCRvgAAAAA:UFCOisdMvm-V_rSNmrYmhBgfdnF2MFGXg-yait6sWz80Ugd3s7wUJhlza3i0l9PDfgboNu1XWEY;;"""og:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""twitter:title"",""Reliable Decentralized Oracle with Mechanisms for Verification and Disputation""
""twitter:card"",""summary""
""Description"",""Smart contract using Blockchain technology provides a mechanism to automatically exchange """"cash"""" and """"service"""" according to programmed conditions without requir""
""og:title"",""Reliable Decentralized Oracle with Mechanisms for Verification and Disputation""
""resourceName"",""08951647.pdf""
""language"",""en""
""title"",""Reliable Decentralized Oracle with Mechanisms for Verification and Disputation | IEEE Conference Publication | IEEE Xplore""
""og:description"",""Smart contract using Blockchain technology provides a mechanism to automatically exchange """"cash"""" and """"service"""" according to programmed conditions without requiring reliable third-party intervention. This results in reduction of time and cost for complex contract execution. Some contract execution require external information outside Blockchain as a trigger to execute the code specifying process for a certain contract. However, because Blockchain technology itself does not provide a function to directly access such external information, these applications require a proxy system called """"oracle"""". Oracle is in charge accessing external information, to verify it, and to write it on Blockchain. To avoid security incidents such as oracle writing malicious information on Blockchain, reliability of oracle must be required. This paper introduces a decentralized oracle equipping with verification and disputation mechanisms. To evaluate reliability of the proposed mechanisms, a simulation-based experiment was conducted. The experimental results showed that our solution could effectively suppress the interference of malicious participants and obtained reliable consensus results even if relatively many malicious participants joined in the consensus process on the proposed decentralized oracle.""
""twitter:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-UA-Compatible"",""IE=Edge""
""viewport"",""width=device-width, initial-scale=1.0""
""dc:title"",""Reliable Decentralized Oracle with Mechanisms for Verification and Disputation | IEEE Conference Publication | IEEE Xplore""
""twitter:description"",""Smart contract using Blockchain technology provides a mechanism to automatically exchange """"cash"""" and """"service"""" according to programmed conditions without requiring reliable third-party intervention. This results in reduction of time and cost for complex contract execution. Some contract execution require external information outside Blockchain as a trigger to execute the code specifying process for a certain contract. However, because Blockchain technology itself does not provide a function to directly access such external information, these applications require a proxy system called """"oracle"""". Oracle is in charge accessing external information, to verify it, and to write it on Blockchain. To avoid security incidents such as oracle writing malicious information on Blockchain, reliability of oracle must be required. This paper introduces a decentralized oracle equipping with verification and disputation mechanisms. To evaluate reliability of the proposed mechanisms, a simulation-based experiment was conducted. The experimental results showed that our solution could effectively suppress the interference of malicious participants and obtained reliable consensus results even if relatively many malicious participants joined in the consensus process on the proposed decentralized oracle.""
""Content-Encoding"",""UTF-8""
""Content-Type-Hint"",""text/html; charset=utf-8""
""Content-Length"",""41851""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=30&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093452-181;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Robot Workspace Monitoring using a Blockchain-based 3D Vision Approach;V Lopes, N Pereira… ; Proceedings of the IEEE …, 2019  openaccess.thecvf.com;;"… It is essential that the address of the Oracle(s) is defined on the smart-contract logic. This en-

forces that only allowed parties can update the information on the blockchain. In the proposed

method, there are three separated Oracles performing computation on data (from the …";Cité 9 fois;Les 8 versions;[PDF] thecvf.com;http://openaccess.thecvf.com/content_CVPRW_2019/papers/BCMCVAI/Lopes_Robot_Workspace_Monitoring_Using_a_Blockchain-Based_3D_Vision_Approach_CVPRW_2019_paper.pdf;;"""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""dc:title"",""302 Found""
""Content-Encoding"",""ISO-8859-1""
""resourceName"",""Lopes_Robot_Workspace_Monitoring_Using_a_Blockchain-Based_3D_Vision_Approach_CVPRW_2019_paper.pdf""
""language"",""en""
""Content-Length"",""432""
""title"",""302 Found""
""Content-Type"",""text/html; charset=ISO-8859-1""
";https://scholar.google.com/scholar?start=20&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093539-559;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Cryptocurrency: Collateral for Secured Transactions?;X Foccroulle Menard ;2019 papers.ssrn.com;;"… Blockchain technology, and especially cryptocurrency, provides many advantages that make

it valuable … This article does not go into details about securities held through a blockchain system

with or without intermediation, also called ''crypto-securities”, and strictly concerns …";Autres articles;;null;;;;https://scholar.google.com/scholar?start=390&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093518-461;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;[PDF][PDF] Blockchain Smart Contracts For International Trade: A Transaction Cost Analysis;PW Hřjlund, LS Nielsen ;2019 research.cbs.dk;;"… to the external world, a highly trustworthy oracle is necessary to preserve the trustworthiness

of a well-engineered blockchain (Ibid.). As for bugs, Chainlink allows for … Page 18. 17 mitigated

by Chainlink making a new set of supporting oracles available for a new contract (Ibid.) …";Autres articles;Version HTML;[PDF] cbs.dk;https://research.cbs.dk/files/59796577/681108_MSc_Thesis_Philip_and_Lasse.pdf;;"""date"",""2019-05-14T11:12:28Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.3""
""pdf:docinfo:title"",""Microsoft Word - MSc Thesis, Philip and Lasse, Student Number.docx""
""xmp:CreatorTool"",""Word""
""Keywords"",""""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""dcterms:created"",""2019-05-14T11:12:28Z""
""language"",""en""
""Last-Modified"",""2019-05-14T11:12:28Z""
""dcterms:modified"",""2019-05-14T11:12:28Z""
""dc:format"",""application/pdf; version=1.3""
""title"",""Microsoft Word - MSc Thesis, Philip and Lasse, Student Number.docx""
""Last-Save-Date"",""2019-05-14T11:12:28Z""
""pdf:docinfo:creator_tool"",""Word""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2019-05-14T11:12:28Z""
""meta:save-date"",""2019-05-14T11:12:28Z""
""pdf:encrypted"",""false""
""dc:title"",""Microsoft Word - MSc Thesis, Philip and Lasse, Student Number.docx""
""modified"",""2019-05-14T11:12:28Z""
""pdf:hasMarkedContent"",""false""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""dc:subject"",""""
""meta:creation-date"",""2019-05-14T11:12:28Z""
""created"",""2019-05-14T11:12:28Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""93""
""Creation-Date"",""2019-05-14T11:12:28Z""
""resourceName"",""681108_MSc_Thesis_Philip_and_Lasse.pdf""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""1645"",""2280"",""2511"",""1112"",""2695"",""2228"",""2743"",""2401"",""2299"",""2617"",""2403"",""2719"",""2395"",""2602"",""2666"",""2645"",""2551"",""2333"",""2557"",""2363"",""2541"",""2552"",""2694"",""2742"",""2557"",""2264"",""2467"",""2466"",""2385"",""2421"",""2492"",""2474"",""2544"",""3077"",""2328"",""2724"",""2685"",""2577"",""2363"",""2426"",""2221"",""2362"",""1826"",""2534"",""2211"",""2954"",""2381"",""2335"",""2183"",""2495"",""2653"",""2689"",""2612"",""1432"",""2587"",""2603"",""2657"",""2633"",""1263"",""2571"",""2614"",""1386"",""2617"",""2463"",""2523"",""2469"",""2544"",""2526"",""2737"",""2352"",""2478"",""2128"",""1634"",""2262"",""2509"",""2683"",""2576"",""2516"",""2601"",""2465"",""2632"",""2517"",""2678"",""349"",""2418"",""2599"",""2566"",""2468"",""2601"",""2599"",""2474"",""2573"",""934""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""meta:keyword"",""""
""producer"",""Mac OS X 10.13.6 Quartz PDFContext""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""Mac OS X 10.13.6 Quartz PDFContext""
""pdf:docinfo:created"",""2019-05-14T11:12:28Z""
";https://scholar.google.com/scholar?start=300&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093504-404;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Formal verification of blockchain Byzantine fault tolerance;P Tholoniat, V Gramoli ; arXiv preprint arXiv:1909.07453, 2019  arxiv.org;;"Page 1. Formal Verification of Blockchain Byzantine Fault Tolerance … To implement a blockchain,

the trend is now to in- tegrate a non-trivial Byzantine fault tolerant consen- sus algorithm instead

of the seminal idea of wait- ing to receive blocks to decide upon the longest branch …";Cité 8 fois;Les 5 versions;[PDF] arxiv.org;https://arxiv.org/pdf/1909.07453;;"""date"",""2019-10-16T00:36:09Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2019-10-16T00:36:09Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016) kpathsea version 6.2.2""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2019-10-16T00:36:09Z""
""created"",""2019-10-16T00:36:09Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-10-16T00:36:09Z""
""resourceName"",""1909.07453""
""Author"",""""
""producer"",""pdfTeX-1.40.17""
""pdf:docinfo:producer"",""pdfTeX-1.40.17""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""6"",""9"",""0"",""22"",""0"",""9"",""0"",""0"",""0"",""0"",""0"",""0"",""22"",""0"",""0"",""0"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2019-10-16T00:36:09Z""
""Last-Modified"",""2019-10-16T00:36:09Z""
""dcterms:modified"",""2019-10-16T00:36:09Z""
""title"",""""
""Last-Save-Date"",""2019-10-16T00:36:09Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2019-10-16T00:36:09Z""
""meta:save-date"",""2019-10-16T00:36:09Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016) kpathsea version 6.2.2""
""Content-Length"",""566406""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""22""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""2826"",""3878"",""3206"",""2777"",""3216"",""3521"",""3436"",""3083"",""2035"",""3032"",""2458"",""3646"",""2287"",""2722"",""2659"",""2998"",""1898"",""1574"",""1178"",""1346"",""849"",""55""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-10-16T00:36:09Z""
";https://scholar.google.com/scholar?start=240&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093511-432;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Elasticoin: Low-Volatility Cryptocurrency with Proofs of Sequential Work;Y Dong, R Boutaba ; … on Blockchain and Cryptocurrency (ICBC), 2019  ieeexplore.ieee.org;;"… rates with an off- chain asset: Dai, for example, has a pool of oracles posting the … voting based

on the game- theoretic concept of Schelling points [14] to replace this oracle tend to … Suggestions

of systems that measure the “economic activity” of a blockchain to drive an algorithm …";Cité 3 fois;Les 5 versions;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/8744142/8751228/08751402.pdf?casa_token=3WbdAj31o-wAAAAA:kQdxkYmz-OpXwzkbpoa61M-sLKNYyNDgWd529ZhPkJNwqtDLO8k9d4zptQTa-Kfn2O8BOQRyX6o;;"""og:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""twitter:title"",""Elasticoin: Low-Volatility Cryptocurrency with Proofs of Sequential Work""
""twitter:card"",""summary""
""Description"",""Blockchain-based cryptocurrencies have gained increasing adoption in recent years, and many hope that they may usher in a new era of decentralized electronic mo""
""og:title"",""Elasticoin: Low-Volatility Cryptocurrency with Proofs of Sequential Work""
""resourceName"",""08751402.pdf""
""language"",""en""
""title"",""Elasticoin: Low-Volatility Cryptocurrency with Proofs of Sequential Work | IEEE Conference Publication | IEEE Xplore""
""og:description"",""Blockchain-based cryptocurrencies have gained increasing adoption in recent years, and many hope that they may usher in a new era of decentralized electronic money. Unfortunately, they perform the core functions of money quite poorly due to their extremely volatile market value. On the other hand, blockchain “stablecoins” aiming to reduce this volatility, usually through a peg to an external currency like the US dollar, tend to greatly sacrifice decentralization of the money supply that make cryptocurrencies so attractive in the first place. Elasticoin is a novel currency issuance algorithm which greatly reduces price volatility by using the cryptographic puzzle of proofs of sequential work to fix the cost of minting a coin to sequential computation time. This causes coin supply to be highly elastic, quickly responding to demand for new coins and greatly dampening price swings. We argue that Elasticoin's fixed-minting-cost approach to low volatility has significant advantages over using pegs or explicit measurement of demand to adjust supply.""
""twitter:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-UA-Compatible"",""IE=Edge""
""viewport"",""width=device-width, initial-scale=1.0""
""dc:title"",""Elasticoin: Low-Volatility Cryptocurrency with Proofs of Sequential Work | IEEE Conference Publication | IEEE Xplore""
""twitter:description"",""Blockchain-based cryptocurrencies have gained increasing adoption in recent years, and many hope that they may usher in a new era of decentralized electronic money. Unfortunately, they perform the core functions of money quite poorly due to their extremely volatile market value. On the other hand, blockchain “stablecoins” aiming to reduce this volatility, usually through a peg to an external currency like the US dollar, tend to greatly sacrifice decentralization of the money supply that make cryptocurrencies so attractive in the first place. Elasticoin is a novel currency issuance algorithm which greatly reduces price volatility by using the cryptographic puzzle of proofs of sequential work to fix the cost of minting a coin to sequential computation time. This causes coin supply to be highly elastic, quickly responding to demand for new coins and greatly dampening price swings. We argue that Elasticoin's fixed-minting-cost approach to low volatility has significant advantages over using pegs or explicit measurement of demand to adjust supply.""
""Content-Encoding"",""UTF-8""
""Content-Type-Hint"",""text/html; charset=utf-8""
""Content-Length"",""40659""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=270&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093471-265;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Technologie Du Blockchain (Ou De La Chaîne De Blocs) En Tant Que Technologie De Réglementation: Du Code Est La Loi A La Loi Est Le Code;R DUNCA ; Curentul Juridic, 2019  ceeol.com;;"… Les DAO (et les contrats intelligents plus généralement) interagissent avec le monde

physique via des interfaces ou des capteurs (appelés Oracles) qui enregistrent les

informations du monde extérieur dans la blockchain. Celles …";Cité 1 fois;Les 6 versions;[PDF] revcurentjur.ro;http://revcurentjur.ro/old/arhiva/attachments_201901/recjurid191_6F.pdf;;"""date"",""2019-03-29T07:08:12Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.5""
""xmp:CreatorTool"",""MicrosoftÂŽ Word 2016""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dc:creator"",""Rebecca Dunca""
""language"",""fr""
""dcterms:created"",""2019-03-29T07:08:12Z""
""Last-Modified"",""2019-03-29T07:08:12Z""
""dcterms:modified"",""2019-03-29T07:08:12Z""
""dc:format"",""application/pdf; version=1.5""
""Last-Save-Date"",""2019-03-29T07:08:12Z""
""pdf:docinfo:creator_tool"",""MicrosoftÂŽ Word 2016""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2019-03-29T07:08:12Z""
""meta:save-date"",""2019-03-29T07:08:12Z""
""pdf:encrypted"",""false""
""modified"",""2019-03-29T07:08:12Z""
""Content-Length"",""514151""
""pdf:hasMarkedContent"",""true""
""Content-Type"",""application/pdf""
""pdf:docinfo:creator"",""Rebecca Dunca""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Rebecca Dunca""
""dc:language"",""ro-RO""
""meta:author"",""Rebecca Dunca""
""meta:creation-date"",""2019-03-29T07:08:12Z""
""created"",""2019-03-29T07:08:12Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""22""
""Creation-Date"",""2019-03-29T07:08:12Z""
""resourceName"",""recjurid191_6F.pdf""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""2102"",""3936"",""3751"",""3659"",""3863"",""4022"",""3960"",""4148"",""4021"",""3861"",""3815"",""4044"",""4118"",""3917"",""3977"",""3912"",""3614"",""4026"",""3396"",""3375"",""3057"",""2434""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""Author"",""Rebecca Dunca""
""producer"",""MicrosoftÂŽ Word 2016""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""MicrosoftÂŽ Word 2016""
""pdf:docinfo:created"",""2019-03-29T07:08:12Z""
";https://scholar.google.com/scholar?start=100&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093536-544;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;[PDF][PDF] Revolutionising AEC financial system within project delivery stages: A permissioned blockchain digitalised framework;S Abrishami, F Elghaish ; 36th CIB W, 2019  researchgate.net;;"… VAN MÖLKEN, R. 2018. Blockchain across Oracle: Understand the details and implications of

the Blockchain for Oracle developers and customers, Packt Publishing Ltd … Do you need a

Blockchain? In: 2018 Crypto Valley Conference on Blockchain Technology (CVCBT), 2018 …";Cité 3 fois;Les 4 versions;[PDF] researchgate.net;https://www.researchgate.net/profile/Faris-Elghaish/publication/335892493_Revolutionising_AEC_financial_system_within_project_delivery_stages_A_permissioned_blockchain_digitalised_framework/links/5d8765a2299bf1996f926493/Revolutionising-AEC-financial-system-within-project-delivery-stages-A-permissioned-blockchain-digitalised-framework.pdf;;;https://scholar.google.com/scholar?start=380&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093499-386;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;A Critical Analysis on the Capacity of Blockchain-Based Parametric Insurance in Tackling the Financial Impact of Climatic Disasters;C Sandland, D Schilling, A Marke ; … Disaster Resilience in Small …, 2019  books.google.com;;"… Although the first major use-case was the cryptocurrency, Bitcoin, the blockchain technology

that underpins it extends beyond currencies … As 'smart contracts' are deterministic in nature, they

rely on oracles to bring this external data into the blockchain.'Oracles' are third-party …";Cité 1 fois;;null;;;;https://scholar.google.com/scholar?start=220&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093520-476;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Administrations publiques: la chaîne de blocs, une avenue ŕ explorer;F Gosselin ; Gestion, 2019  cairn.info;;"… avril 2018. Woods, J., Ť Blockchain : Public Sector Use Cases ť, Crypto Oracle

(plateforme de blogues en ligne), 2 octobre 2018. Killmeyer, J., White, M., et Chew,

B., Ť Will Blockchain Transform the Public Sector ? Blockchain …";Autres articles;;null;;;;https://scholar.google.com/scholar?start=310&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093530-519;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;[HTML][HTML] Secure smart contract-enabled control of battery energy storage systems against cyber-attacks;N Mhaisen, N Fetais, A Massoud ; Alexandria Engineering Journal, 2019  Elsevier;;"… Sensing devices of each node are modeled as “oracles” of the blockchain. A blockchain

oracle is a system independent from the blockchain network that provides information from

the real world necessary for the smart contracts to execute [30] …";Cité 8 fois;Les 5 versions;[HTML] sciencedirect.com;https://www.sciencedirect.com/science/article/pii/S111001681930122X;;;https://scholar.google.com/scholar?start=350&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093462-227;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;On the Characterization of Blockchain Consensus Under Incentives;S Tucci;Piergiovanni  International Symposium on Stabilizing, Safety, and …, 2019  Springer;;"… also in the case the Byzantine sends the same valid value, but the oracle loses the … Even if oracles

defined in [7] are deterministic, probabilistic versions can be easily derived by … A., Russell, A.:

Ouroboros praos: an adaptively-secure, semi-synchronous proof-of-stake blockchain …";Autres articles;;null;;;;https://scholar.google.com/scholar?start=60&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093525-500;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;[CITATION][C] 3 Technology of Smart Contracts;V Gatteschi, F Lamberti, C Demartini;;;null;Autres articles;;null;;;;https://scholar.google.com/scholar?start=330&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093509-422;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Blockchain and beyond, integration of IoT devices with the distributed ledger technology;M ULLOA, A ANDRËS ;2019 politesi.polimi.it;;"… 52 4.6 Oracles: A point of failure … Figure 6-1 The behavior of an ideal oracle … The

technology behind this cryptocurrency is the blockchain, and ten years later, the main

companies of the world of diverse areas are exploring its implementation …";Autres articles;Version HTML;[PDF] polimi.it;https://www.politesi.polimi.it/bitstream/10589/149650/5/2019_10_Martinez.pdf;;"""date"",""2019-09-19T16:10:17Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""2"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""4"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.7""
""pdf:docinfo:title"",""Microsoft Word - Tesis in progress4""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dc:creator"",""Antonio""
""dcterms:created"",""2019-09-19T16:10:17Z""
""language"",""en""
""Last-Modified"",""2019-09-19T16:10:17Z""
""dcterms:modified"",""2019-09-19T16:10:17Z""
""dc:format"",""application/pdf; version=1.7""
""title"",""Microsoft Word - Tesis in progress4""
""Last-Save-Date"",""2019-09-19T16:10:17Z""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2019-09-19T16:10:17Z""
""meta:save-date"",""2019-09-19T16:10:17Z""
""pdf:encrypted"",""false""
""dc:title"",""Microsoft Word - Tesis in progress4""
""modified"",""2019-09-19T16:10:17Z""
""pdf:hasMarkedContent"",""false""
""Content-Type"",""application/pdf""
""pdf:docinfo:creator"",""Antonio""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Antonio""
""meta:author"",""Antonio""
""meta:creation-date"",""2019-09-19T16:10:17Z""
""created"",""2019-09-19T16:10:17Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""85""
""Creation-Date"",""2019-09-19T16:10:17Z""
""resourceName"",""2019_10_Martinez.pdf""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""408"",""21"",""2667"",""2509"",""2902"",""2929"",""2734"",""2223"",""3241"",""2984"",""3590"",""2642"",""2773"",""1328"",""85"",""2045"",""2476"",""2275"",""2741"",""1590"",""1848"",""2432"",""2935"",""2343"",""2729"",""1897"",""2371"",""1836"",""924"",""2876"",""106"",""2616"",""2705"",""1610"",""2811"",""1671"",""1756"",""1574"",""1809"",""3113"",""1667"",""2591"",""2763"",""2594"",""2898"",""2464"",""2713"",""3053"",""2565"",""1996"",""2623"",""2351"",""1394"",""1802"",""2782"",""2936"",""2451"",""1487"",""2251"",""2908"",""2259"",""1786"",""1618"",""2786"",""2696"",""2711"",""2440"",""2574"",""2764"",""2069"",""1959"",""3231"",""1912"",""2211"",""2718"",""3005"",""2988"",""710"",""2152"",""2334"",""2410"",""2115"",""2187"",""2263"",""2203""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""Author"",""Antonio""
""producer"",""Microsoft: Print To PDF""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""Microsoft: Print To PDF""
""pdf:docinfo:created"",""2019-09-19T16:10:17Z""
";https://scholar.google.com/scholar?start=260&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093523-490;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Publisher Subscriber Services Security and Blockchain Technology;N Rathore, I Salaudin, A Aggarwal ; International Conference on …, 2019  papers.ssrn.com;;"… during this paper a brand new theme while not the random oracle model, associate degree … January

29, 2018, ' Secure Pub-Sub: Blockchain-Based Fair Payment With Reputation For Reliable … Y,

Yang B, Sun Y, et al., ”Identity based signcryption scheme without random oracles” …";Autres articles;;[PDF] academia.edu;https://www.academia.edu/download/62301568/Publisher_Subscriber_Services_Security_and_Blockchain_Technology20200307-101043-2zysk3.pdf;;;https://scholar.google.com/scholar?start=320&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093492-357;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;[PDF][PDF] Decentralized Oracles via Peer-Prediction in the Presence of Lying Incentives;N Goel, A Filos;Ratsikas, B Faltings 2019 arisfilosratsikas.com;;"… prone to several problems, such as the trustworthiness or the accuracy of the oracles, or the … the

fundamental idea behind the prediction-market applications that run on the Ethereum blockchain,

such as … to ensure that the de- centralized platform can be used as an oracle, in the …";Cité 3 fois;Les 3 versions;[PDF] arisfilosratsikas.com;http://arisfilosratsikas.com/papers/decentralized_oracles.pdf;;"""date"",""2018-12-14T11:19:37Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""Decentralized Oracles via Peer-Prediction in the Presence of Lying Incentives""
""xmp:CreatorTool"",""TeX""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""TeX""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""Decentralized Oracles via Peer-Prediction in the Presence of Lying Incentives""
""modified"",""2018-12-14T11:19:37Z""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""Naman Goel, Aris Filos-Ratsikas, Boi Faltings""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017) kpathsea version 6.2.3""
""meta:author"",""Naman Goel, Aris Filos-Ratsikas, Boi Faltings""
""trapped"",""False""
""meta:creation-date"",""2018-12-14T11:19:37Z""
""created"",""2018-12-14T11:19:37Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2018-12-14T11:19:37Z""
""resourceName"",""decentralized_oracles.pdf""
""Author"",""Naman Goel, Aris Filos-Ratsikas, Boi Faltings""
""producer"",""pdfTeX-1.40.18""
""pdf:docinfo:producer"",""pdfTeX-1.40.18""
""pdf:unmappedUnicodeCharsPerPage"",""1"",""0"",""0"",""13"",""6"",""11"",""0"",""6"",""0""
""access_permission:modify_annotations"",""true""
""dc:creator"",""Naman Goel, Aris Filos-Ratsikas, Boi Faltings""
""dcterms:created"",""2018-12-14T11:19:37Z""
""Last-Modified"",""2018-12-14T11:19:37Z""
""dcterms:modified"",""2018-12-14T11:19:37Z""
""title"",""Decentralized Oracles via Peer-Prediction in the Presence of Lying Incentives""
""Last-Save-Date"",""2018-12-14T11:19:37Z""
""pdf:docinfo:modified"",""2018-12-14T11:19:37Z""
""meta:save-date"",""2018-12-14T11:19:37Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017) kpathsea version 6.2.3""
""Content-Length"",""316297""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Naman Goel, Aris Filos-Ratsikas, Boi Faltings""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""9""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""4344"",""5397"",""5386"",""5120"",""5198"",""4595"",""5435"",""4115"",""4494""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2018-12-14T11:19:37Z""
";https://scholar.google.com/scholar?start=190&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093478-295;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Blockchain technology and the governance of foreign aid;B Reinsberg ; Journal of Institutional Economics, 2019  eprints.gla.ac.uk;;"… 1 As I show later, central authorities will not be completely redundant because they are crucial

for administering the blockchain-based aid system as a permissioned blockchain and for validating

actor behavior unless other oracles are available for that purpose. Page 6. 5 …";Cité 23 fois;Les 10 versions;[PDF] gla.ac.uk;https://eprints.gla.ac.uk/189627/1/189627.pdf;;"""date"",""2019-07-04T14:06:54Z""
""pdf:PDFVersion"",""1.7""
""xmp:CreatorTool"",""MicrosoftÂŽ Word 2016""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""language"",""en""
""dc:format"",""application/pdf; version=1.7""
""pdf:docinfo:creator_tool"",""MicrosoftÂŽ Word 2016""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""xmp:CreateDate"",""2018-10-18T14:25:31Z""
""modified"",""2019-07-04T14:06:54Z""
""pdf:hasMarkedContent"",""true""
""xmp:ModifyDate"",""2019-07-04T15:06:54Z""
""pdf:docinfo:creator"",""reinsberg""
""meta:author"",""reinsberg""
""meta:creation-date"",""2018-10-18T13:25:31Z""
""created"",""2018-10-18T13:25:31Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2018-10-18T13:25:31Z""
""resourceName"",""189627.pdf""
""Author"",""reinsberg""
""producer"",""MicrosoftÂŽ Word 2016""
""pdf:docinfo:producer"",""MicrosoftÂŽ Word 2016""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""access_permission:modify_annotations"",""true""
""dc:creator"",""reinsberg""
""dcterms:created"",""2018-10-18T13:25:31Z""
""Last-Modified"",""2019-07-04T14:06:54Z""
""dcterms:modified"",""2019-07-04T14:06:54Z""
""xmpMM:DocumentID"",""uuid:AA2B07A9-F7B5-4E0E-99ED-BE138B5EA9DE""
""Last-Save-Date"",""2019-07-04T14:06:54Z""
""pdf:docinfo:modified"",""2019-07-04T14:06:54Z""
""meta:save-date"",""2019-07-04T14:06:54Z""
""Content-Length"",""670894""
""Content-Type"",""application/pdf""
""xmp:MetadataDate"",""2019-07-04T15:06:54Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""reinsberg""
""dc:language"",""en-GB""
""pdf:producer"",""MicrosoftÂŽ Word 2016""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""24""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""572"",""3150"",""3762"",""3590"",""3410"",""3402"",""3636"",""3722"",""3671"",""2516"",""2111"",""3505"",""3454"",""3446"",""3853"",""3680"",""3363"",""3789"",""1920"",""3012"",""3385"",""3082"",""3136"",""2029""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2018-10-18T13:25:31Z""
";https://scholar.google.com/scholar?start=130&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093452-184;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;On public decentralized ledger oracles via a paired-question protocol;M Merlini, N Veira, R Berryhill… ; … and Cryptocurrency  …, 2019  ieeexplore.ieee.org;;"Blockchain technology enables the operation of fully decentralized applications without the 
need for a central authority to manage the execution of the underlying process. However, a 
critical limitation in the technology today is the inability for such applications to query …";Cité 6 fois;Les 4 versions;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/8744142/8751228/08751484.pdf?casa_token=UasSEtPcKTAAAAAA:ckUFZ42Il6XGPfqARBpZHOMi947zifc3h4ialVv8c3HFgx7d2kw4enDXQNLH5tTLEx874t6xDoQ;;"""og:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""twitter:title"",""On Public Decentralized Ledger Oracles via a Paired-Question Protocol""
""twitter:card"",""summary""
""Description"",""Blockchain technology enables the operation of fully decentralized applications without the need for a central authority to manage the execution of the underlyi""
""og:title"",""On Public Decentralized Ledger Oracles via a Paired-Question Protocol""
""resourceName"",""08751484.pdf""
""language"",""en""
""title"",""On Public Decentralized Ledger Oracles via a Paired-Question Protocol | IEEE Conference Publication | IEEE Xplore""
""og:description"",""Blockchain technology enables the operation of fully decentralized applications without the need for a central authority to manage the execution of the underlying process. However, a critical limitation in the technology today is the inability for such applications to query information external to the blockchain. Applications must make use of a decentralized oracle, i.e. a trusted source of external information. In this work we propose the paired-question decentralized oracle protocol, designed to extract true answers from the public. When querying the oracle, a user submits pairs of antithetic questions and voting users answer them for the chance to receive rewards. This new protocol lends itself to a simple formal analysis, and it is shown to strongly incentivize a Nash equilibrium of truthful reporting. This paper also discusses a number of extensions to the base protocol to improve its cost-effectiveness, security, and applicability.""
""twitter:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-UA-Compatible"",""IE=Edge""
""viewport"",""width=device-width, initial-scale=1.0""
""dc:title"",""On Public Decentralized Ledger Oracles via a Paired-Question Protocol | IEEE Conference Publication | IEEE Xplore""
""twitter:description"",""Blockchain technology enables the operation of fully decentralized applications without the need for a central authority to manage the execution of the underlying process. However, a critical limitation in the technology today is the inability for such applications to query information external to the blockchain. Applications must make use of a decentralized oracle, i.e. a trusted source of external information. In this work we propose the paired-question decentralized oracle protocol, designed to extract true answers from the public. When querying the oracle, a user submits pairs of antithetic questions and voting users answer them for the chance to receive rewards. This new protocol lends itself to a simple formal analysis, and it is shown to strongly incentivize a Nash equilibrium of truthful reporting. This paper also discusses a number of extensions to the base protocol to improve its cost-effectiveness, security, and applicability.""
""Content-Encoding"",""UTF-8""
""Content-Type-Hint"",""text/html; charset=utf-8""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=20&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093499-389;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;[PDF][PDF] The Bitcoin Backbone Protocol Against Quantum Adversaries.;A Cojocaru, JA Garay, A Kiayias, F Song… ; IACR Cryptol. ePrint …, 2019  eprint.iacr.org;;"… adversary, we should be confident that the adversary cannot create a large fork in the blockchain …

are not correlated, therefore the probability to find a PoW for each oracle, is bounded … It depends

on the queries allocated to other oracles (bounded total number of queries), but …";Cité 4 fois;Les 5 versions;[PDF] iacr.org;https://eprint.iacr.org/2019/1150.pdf;;"""date"",""2020-02-19T18:06:40Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2020-02-19T18:06:40Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017) kpathsea version 6.2.3""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2020-02-19T18:06:40Z""
""created"",""2020-02-19T18:06:40Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-02-19T18:06:40Z""
""resourceName"",""1150.pdf""
""Author"",""""
""producer"",""pdfTeX-1.40.18""
""pdf:docinfo:producer"",""pdfTeX-1.40.18""
""pdf:unmappedUnicodeCharsPerPage"",""12"",""0"",""0"",""4"",""2"",""0"",""17"",""4"",""8"",""0"",""22"",""31"",""6"",""1"",""5"",""7"",""7"",""0"",""19"",""4"",""33"",""24"",""17"",""5"",""25"",""29"",""1"",""0"",""0"",""0"",""15"",""43"",""41"",""25"",""43"",""22"",""30"",""24"",""33"",""9"",""16"",""21"",""15"",""25"",""2""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2020-02-19T18:06:40Z""
""Last-Modified"",""2020-02-19T18:06:40Z""
""dcterms:modified"",""2020-02-19T18:06:40Z""
""title"",""""
""Last-Save-Date"",""2020-02-19T18:06:40Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2020-02-19T18:06:40Z""
""meta:save-date"",""2020-02-19T18:06:40Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017) kpathsea version 6.2.3""
""Content-Length"",""584156""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""45""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""2208"",""2850"",""2809"",""2571"",""2816"",""2584"",""2697"",""2249"",""2449"",""1999"",""2314"",""2090"",""2551"",""2371"",""2070"",""1433"",""2043"",""2594"",""1673"",""1957"",""1588"",""1544"",""1815"",""1975"",""1583"",""1622"",""2880"",""2625"",""2857"",""2261"",""1082"",""1177"",""1079"",""1475"",""991"",""975"",""833"",""1444"",""1554"",""1861"",""1854"",""1886"",""1799"",""1491"",""317""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-02-19T18:06:40Z""
";https://scholar.google.com/scholar?start=220&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093464-239;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;[PDF][PDF] On the non-tightness of measurement-based reductions for key encapsulation mechanism in the quantum random oracle model.;H Jiang, Z Zhang, Z Ma ; IACR Cryptol. ePrint Arch., 2019  csrc.nist.gov;;"… In particular, all currently known security reductions in (TCC 2017 and Crypto 2018) are of this

type, and our results suggest … oracles, and the adversaries are given quantum access to these

random oracles and classical access to all other oracles (eg, decapsulation oracle) …";Cité 7 fois;Les 2 versions;[PDF] nist.gov;https://csrc.nist.gov/CSRC/media/Events/Second-PQC-Standardization-Conference/documents/accepted-papers/zhang-On%20non-tightness%20of%20security%20reductions%20for%20KEM%20in%20the%20QROM.pdf;;"""date"",""2019-07-18T11:07:12Z""
""pdf:PDFVersion"",""1.6""
""xmp:CreatorTool"",""TeX""
""pdf:docinfo:title"",""On the non-tightness of measurement-based reductions for key encapsulation mechanism in the quantum random oracle model""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""Paper Submission to the NIST Second PQC Standardization Conference; August 22-24, 2019; University of California, Santa Barbara
""
""language"",""en""
""dc:format"",""application/pdf; version=1.6""
""pdf:docinfo:creator_tool"",""TeX""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""On the non-tightness of measurement-based reductions for key encapsulation mechanism in the quantum random oracle model""
""xmp:CreateDate"",""2019-07-17T10:57:04Z""
""modified"",""2019-07-18T11:07:12Z""
""cp:subject"",""Paper Submission to the NIST Second PQC Standardization Conference; August 22-24, 2019; University of California, Santa Barbara
""
""pdf:docinfo:subject"",""Paper Submission to the NIST Second PQC Standardization Conference; August 22-24, 2019; University of California, Santa Barbara
""
""pdf:hasMarkedContent"",""true""
""xmp:ModifyDate"",""2019-07-18T07:07:12Z""
""pdf:docinfo:creator"",""Haodong Jiang""
""PTEX.Fullbanner"",""This is MiKTeX-pdfTeX 2.9.4307 (1.40.12)""
""meta:author"",""Haodong Jiang"",""Zhenfeng Zhang and Zhi Ma""
""trapped"",""False""
""meta:creation-date"",""2019-07-17T02:57:04Z""
""created"",""2019-07-17T02:57:04Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-07-17T02:57:04Z""
""resourceName"",""zhang-On%20non-tightness%20of%20security%20reductions%20for%20KEM%20in%20the%20QROM.pdf""
""Author"",""Haodong Jiang"",""Zhenfeng Zhang and Zhi Ma""
""producer"",""MiKTeX pdfTeX-1.40.12""
""pdf:docinfo:producer"",""MiKTeX pdfTeX-1.40.12""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""dc:description"",""Paper Submission to the NIST Second PQC Standardization Conference; August 22-24, 2019; University of California, Santa Barbara
""
""Keywords"",""post-quantum cryptography; PQC; standardization, NIST, conference"",""post-quantum cryptography; PQC; standardization, NIST, conference""
""access_permission:modify_annotations"",""true""
""dc:creator"",""Haodong Jiang"",""Zhenfeng Zhang and Zhi Ma""
""description"",""Paper Submission to the NIST Second PQC Standardization Conference; August 22-24, 2019; University of California, Santa Barbara
""
""dcterms:created"",""2019-07-17T02:57:04Z""
""Last-Modified"",""2019-07-18T11:07:12Z""
""dcterms:modified"",""2019-07-18T11:07:12Z""
""title"",""On the non-tightness of measurement-based reductions for key encapsulation mechanism in the quantum random oracle model""
""xmpMM:DocumentID"",""uuid:27cafe26-dfcc-4846-a8d9-00abe699ddec""
""Last-Save-Date"",""2019-07-18T11:07:12Z""
""pdf:docinfo:keywords"",""post-quantum cryptography; PQC; standardization, NIST, conference""
""pdf:docinfo:modified"",""2019-07-18T11:07:12Z""
""meta:save-date"",""2019-07-18T11:07:12Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is MiKTeX-pdfTeX 2.9.4307 (1.40.12)""
""Content-Length"",""660557""
""Content-Type"",""application/pdf""
""xmp:MetadataDate"",""2019-07-18T07:07:12Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Haodong Jiang"",""Zhenfeng Zhang and Zhi Ma""
""dc:language"",""en""
""pdf:producer"",""MiKTeX pdfTeX-1.40.12""
""dc:subject"",""post-quantum cryptography; PQC; standardization, NIST, conference"",""post-quantum cryptography; PQC; standardization, NIST, conference""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""19""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""4012"",""5038"",""4107"",""3776"",""4499"",""3024"",""3037"",""3442"",""2791"",""2110"",""3449"",""2300"",""3145"",""3441"",""2702"",""2221"",""2776"",""5027"",""4679""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""post-quantum cryptography; PQC; standardization, NIST, conference"",""post-quantum cryptography; PQC; standardization, NIST, conference""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-07-17T02:57:04Z""
";https://scholar.google.com/scholar?start=70&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093473-279;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;[HTML][HTML] Blockchain in the built environment and construction industry: A systematic review, conceptual models and practical use cases;J Li, D Greenwood, M Kassem ; Automation in Construction, 2019  Elsevier;;"… Blockchain was developed as the underpinning technology for the world's first cryptocurrency,

Bitcoin, introduced in 2008 as a verification tool for its transactions [18]. The term “blockchain”

has now become synonymous with the concept of DLT and is used interchangeably …";Cité 106 fois;Les 7 versions;[HTML] sciencedirect.com;https://www.sciencedirect.com/science/article/pii/S0926580518308537?casa_token=UiB9bovV5jAAAAAA:lJcisSN1BkmGlSI0vkF39zNfwYSxls-gbExy7stoUwmJwV_3FS46fpsxqo6kM6cXyh1qHNjz;;;https://scholar.google.com/scholar?start=110&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093546-590;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Statement voting;B Zhang, HS Zhou ; … Conference on Financial Cryptography and Data …, 2019  Springer;;"… the tally phase, the voter's ballots will be decrypted, and their statements will define their final

votes based on the latest information provided by News oracles on the blockchain … Common

Reference String (CRS) and Random Oracle (RO) are two popular choices in practice …";Cité 5 fois;Les 12 versions;[PDF] lancs.ac.uk;https://eprints.lancs.ac.uk/id/eprint/130298/1/mainStatement.pdf;;"""date"",""2018-12-29T13:25:10Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2018-12-29T13:25:10Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.19 (TeX Live 2018) kpathsea version 6.3.0""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2018-12-29T13:25:10Z""
""created"",""2018-12-29T13:25:10Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2018-12-29T13:25:10Z""
""resourceName"",""mainStatement.pdf""
""Author"",""""
""producer"",""pdfTeX-1.40.19""
""pdf:docinfo:producer"",""pdfTeX-1.40.19""
""pdf:unmappedUnicodeCharsPerPage"",""7"",""0"",""13"",""20"",""14"",""6"",""21"",""19"",""4"",""13"",""7"",""17"",""27"",""27"",""6"",""20"",""9"",""25"",""24"",""9"",""30"",""26"",""83"",""66"",""71"",""5"",""4"",""3"",""2"",""8"",""8"",""7"",""11"",""23"",""43"",""28"",""14"",""25"",""6"",""9"",""0"",""5"",""43"",""25"",""21"",""16"",""21"",""20"",""19""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2018-12-29T13:25:10Z""
""Last-Modified"",""2018-12-29T13:25:10Z""
""dcterms:modified"",""2018-12-29T13:25:10Z""
""title"",""""
""Last-Save-Date"",""2018-12-29T13:25:10Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2018-12-29T13:25:10Z""
""meta:save-date"",""2018-12-29T13:25:10Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.19 (TeX Live 2018) kpathsea version 6.3.0""
""Content-Length"",""919136""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""49""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""1065"",""1775"",""3765"",""4145"",""4060"",""3301"",""2586"",""2205"",""1580"",""2840"",""2472"",""2343"",""2252"",""1621"",""2740"",""1966"",""2182"",""1362"",""2816"",""2284"",""2106"",""2811"",""1963"",""2286"",""1662"",""2801"",""2702"",""2780"",""1813"",""2245"",""2630"",""2529"",""1945"",""2280"",""2326"",""1414"",""1236"",""2676"",""2456"",""2541"",""874"",""2165"",""2736"",""2720"",""2518"",""2237"",""2350"",""2154"",""1399""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2018-12-29T13:25:10Z""
";https://scholar.google.com/scholar?start=420&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093499-387;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Blockchain based variability management solutions for fog native open source software;B Holste, V Stankovski, P Kochovski… ; 2019 XXVII …, 2019  computer.org;;"… 100%,improved utility of existing ,repositories.,Edge-Fog cloud bursting ,mechanisms via the

use of trustful,and trustless Smart Oracles, ,automated Smart Contract templates,and Blockchain

supported ,execution for trust and dependability.,Automated,resource,acquisition …";Cité 1 fois;Les 2 versions;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/8932650/8938684/08938888.pdf?casa_token=ZPa89-2yMvwAAAAA:fW5U99llgmLQ1QdUhZyq17Mv3SRnAINseqestHkUCnHm03jcdQ9dDbVy48BnLucKfxE-5RJM5ZM;;"""og:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""twitter:title"",""Blockchain Based Variability Management Solutions for Fog Native Open Source Software""
""twitter:card"",""summary""
""Description"",""The following topics are dealt with: power engineering computing; optimisation; feature extraction; peer-to-peer computing; distribution networks; load flow; di""
""og:title"",""Blockchain Based Variability Management Solutions for Fog Native Open Source Software""
""resourceName"",""08938888.pdf""
""language"",""en""
""title"",""Blockchain Based Variability Management Solutions for Fog Native Open Source Software | IEEE Conference Publication | IEEE Xplore""
""og:description"",""The following topics are dealt with: power engineering computing; optimisation; feature extraction; peer-to-peer computing; distribution networks; load flow; distributed power generation; search problems; microcontrollers; genetic algorithms.""
""twitter:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-UA-Compatible"",""IE=Edge""
""viewport"",""width=device-width, initial-scale=1.0""
""dc:title"",""Blockchain Based Variability Management Solutions for Fog Native Open Source Software | IEEE Conference Publication | IEEE Xplore""
""twitter:description"",""The following topics are dealt with: power engineering computing; optimisation; feature extraction; peer-to-peer computing; distribution networks; load flow; distributed power generation; search problems; microcontrollers; genetic algorithms.""
""Content-Encoding"",""UTF-8""
""Content-Type-Hint"",""text/html; charset=utf-8""
""Content-Length"",""39567""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=220&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093546-589;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;A distributed autonomous organization for internet address management;S Angieri, A García;Martínez, B Liu…  IEEE Transactions …, 2019  ieeexplore.ieee.org;;"… a set of blockchain's smart contracts in Ethereum, and it imple- ments all the functions needed

for the management of a global pool of addresses without any human intervention. Any entity

may re- quest an allocation of addresses to the InBlock registry by perform- ing a (crypto) …";Cité 8 fois;;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/17/4429834/08798684.pdf?casa_token=Y77oVd6g2eIAAAAA:c4QDeTlbrnmHdqOLrctBMRgASEzdR588q1V_uXgcVxga51tBB_5Qm0yJnIuFmefUR0yNG48nyb4;;"""og:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""twitter:title"",""A Distributed Autonomous Organization for Internet Address Management""
""twitter:card"",""summary""
""Description"",""The current system to manage the global pool of IP addresses is centralized in five transnational organizations, known as regional internet registries (RIRs). E""
""og:title"",""A Distributed Autonomous Organization for Internet Address Management""
""resourceName"",""08798684.pdf""
""language"",""en""
""title"",""A Distributed Autonomous Organization for Internet Address Management | IEEE Journals & Magazine | IEEE Xplore""
""og:description"",""The current system to manage the global pool of IP addresses is centralized in five transnational organizations, known as regional internet registries (RIRs). Each of them manages the address pool for many countries. In this paper, we present InBlock, a distributed autonomous organization that provides the decentralized management of IP addresses. The InBlock also fulfills the same objectives as those fulfilled by the current IP address allocation organizations, i.e., uniqueness, fairness, conservation, aggregation, registration, and minimized overhead. The InBlock is implemented as a set of blockchain's smart contracts in Ethereum, and it implements all the functions needed for the management of a global pool of addresses without any human intervention. Any entity may request an allocation of addresses to the InBlock registry by performing a (crypto)currency transfer to the InBlock. The fee required, along with the annual renewal fee, serves as a mechanism to deter stockpiling and other wasteful practices. As with any novel technology, there are many open questions about the usage of blockchains to build an IP address registry. For this reason, we believe that practical experimentation is required in order to have hands-on experience, so we propose to conduct an experiment on the InBlock as a starting point to inform about the future directions in this space.""
""twitter:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-UA-Compatible"",""IE=Edge""
""viewport"",""width=device-width, initial-scale=1.0""
""dc:title"",""A Distributed Autonomous Organization for Internet Address Management | IEEE Journals & Magazine | IEEE Xplore""
""twitter:description"",""The current system to manage the global pool of IP addresses is centralized in five transnational organizations, known as regional internet registries (RIRs). Each of them manages the address pool for many countries. In this paper, we present InBlock, a distributed autonomous organization that provides the decentralized management of IP addresses. The InBlock also fulfills the same objectives as those fulfilled by the current IP address allocation organizations, i.e., uniqueness, fairness, conservation, aggregation, registration, and minimized overhead. The InBlock is implemented as a set of blockchain's smart contracts in Ethereum, and it implements all the functions needed for the management of a global pool of addresses without any human intervention. Any entity may request an allocation of addresses to the InBlock registry by performing a (crypto)currency transfer to the InBlock. The fee required, along with the annual renewal fee, serves as a mechanism to deter stockpiling and other wasteful practices. As with any novel technology, there are many open questions about the usage of blockchains to build an IP address registry. For this reason, we believe that practical experimentation is required in order to have hands-on experience, so we propose to conduct an experiment on the InBlock as a starting point to inform about the future directions in this space.""
""Content-Encoding"",""UTF-8""
""Content-Type-Hint"",""text/html; charset=utf-8""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=420&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093513-447;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;[HTML][HTML] Toward privacy-preserving shared storage in untrusted blockchain P2P networks;S Rahmadika, KH Rhee ; Wireless Communications and Mobile …, 2019  hindawi.com;;"… In the decentralized healthcare system model, the patient and the providers are on the same

blockchain network … 3.3. Ring Confidential Transaction of PHI. Ring confidential transaction

(RingCT) is used in Monero cryptocurrency [16] in order to improve the privacy of the users …";Cité 13 fois;Les 6 versions;[HTML] hindawi.com;https://www.hindawi.com/journals/wcmc/2019/6219868/abs/;;"""dc.publisher"",""Hindawi""
""og:image"",""https://images.hindawi.com/journals/wcmc/wcmc.banner.jpg""
""og:image:width"",""600""
""twitter:card"",""summary_large_image""
""citation_journal_title"",""Wireless Communications and Mobile Computing""
""language"",""en""
""og:description"",""The shared storage is essential in the decentralized system. A straightforward storage model with guaranteed privacy protection on the peer-to-peer network is a challenge in the blockchain technology. The decentralized storage system should provide the privacy for the parties since it contains numerous data that are sensitive and dangerous if misused by maliciously. In this paper, we present a model for shared storage on a blockchain network which allows the authorized parties to access the data on storage without having to reveal their identity. Ring signatures combined with several protocols are implemented to disguise the signer identity thereby the observer is unlikely to determine the identity of the parties. We apply our proposed scheme in the healthcare domain, namely, decentralized personal health information (PHI). In addition, we present a dilemma to improve performance in a decentralized system.""
""prism.issn"",""1530-8669""
""citation_issn"",""1530-8669""
""dc:title"",""Toward Privacy-Preserving Shared Storage in Untrusted Blockchain P2P Networks""
""Content-Encoding"",""UTF-8""
""citation_pdf_url"",""https://downloads.hindawi.com/journals/wcmc/2019/6219868.pdf""
""robots"",""index""
""google-site-verification"",""AxEuDsL7vXGOxRe53-uFhOk2ODN0bbXMeuBy6Pfq4ww""
""citation_author"",""Rahmadika, Sandi"",""Rhee, Kyung-Hyune""
""dc.date"",""2019/05/16""
""prism.volume"",""2019""
""citation_doi"",""https://doi.org/10.1155/2019/6219868""
""prism.publicationName"",""Wireless Communications and Mobile Computing""
""dc.title"",""Toward Privacy-Preserving Shared Storage in Untrusted Blockchain P2P Networks""
""Author"",""Hindawi""
""citation_volume"",""2019""
""dc.language"",""en""
""Content-Language"",""en""
""authors"",""Sandi Rahmadika | Kyung-Hyune Rhee""
""citation_title"",""Toward Privacy-Preserving Shared Storage in Untrusted Blockchain P2P Networks""
""citation_year"",""2019""
""citation_publisher"",""Hindawi""
""dc.format"",""text/html""
""description"",""The shared storage is essential in the decentralized system. A straightforward storage model with guaranteed privacy protection on the peer-to-peer network is a challenge in the blockchain technology. The decentralized storage system should provide the privacy for the parties since it contains numerous data that are sensitive and dangerous if misused by maliciously. In this paper, we present a model for shared storage on a blockchain network which allows the authorized parties to access the data on storage without having to reveal their identity. Ring signatures combined with several protocols are implemented to disguise the signer identity thereby the observer is unlikely to determine the identity of the parties. We apply our proposed scheme in the healthcare domain, namely, decentralized personal health information (PHI). In addition, we present a dilemma to improve performance in a decentralized system.""
""og:image:type"",""image/jpeg""
""citation_date"",""2019/05/16""
""title"",""Toward Privacy-Preserving Shared Storage in Untrusted Blockchain P2P Networks"",""Toward Privacy-Preserving Shared Storage in Untrusted Blockchain P2P Networks""
""twitter:image"",""https://images.hindawi.com/journals/wcmc/wcmc.banner.jpg""
""citation_online_date"",""2019/05/16""
""twitter:site"",""website""
""dc.type"",""Research Article""
""dc.source"",""Wireless Communications and Mobile Computing""
""dc.creator"",""Rahmadika, Sandi"",""Rhee, Kyung-Hyune""
""citation_fulltext_html_url"",""https://www.hindawi.com/journals/wcmc/2019/6219868/""
""prism.publicationDate"",""2019/05/16""
""Content-Length"",""1692881""
""citation_xml_url"",""https://downloads.hindawi.com/journals/wcmc/2019/6219868.xml""
""Content-Type"",""text/html; charset=UTF-8""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""og:type"",""website""
""twitter:title"",""Toward Privacy-Preserving Shared Storage in Untrusted Blockchain P2P Networks""
""dc.description"",""The shared storage is essential in the decentralized system. A straightforward storage model with guaranteed privacy protection on the peer-to-peer network is a challenge in the blockchain technology. The decentralized storage system should provide the privacy for the parties since it contains numerous data that are sensitive and dangerous if misused by maliciously. In this paper, we present a model for shared storage on a blockchain network which allows the authorized parties to access the data on storage without having to reveal their identity. Ring signatures combined with several protocols are implemented to disguise the signer identity thereby the observer is unlikely to determine the identity of the parties. We apply our proposed scheme in the healthcare domain, namely, decentralized personal health information (PHI). In addition, we present a dilemma to improve performance in a decentralized system.""
""og:title"",""Toward Privacy-Preserving Shared Storage in Untrusted Blockchain P2P Networks""
""citation_abstract"",""The shared storage is essential in the decentralized system. A straightforward storage model with guaranteed privacy protection on the peer-to-peer network is a challenge in the blockchain technology. The decentralized storage system should provide the privacy for the parties since it contains numerous data that are sensitive and dangerous if misused by maliciously. In this paper, we present a model for shared storage on a blockchain network which allows the authorized parties to access the data on storage without having to reveal their identity. Ring signatures combined with several protocols are implemented to disguise the signer identity thereby the observer is unlikely to determine the identity of the parties. We apply our proposed scheme in the healthcare domain, namely, decentralized personal health information (PHI). In addition, we present a dilemma to improve performance in a decentralized system.""
""og:image:height"",""315""
""prism.doi"",""https://doi.org/10.1155/2019/6219868""
""dcterms.issued"",""2019/05/16""
""viewport"",""width=device-width, initial-scale=1""
""twitter:description"",""The shared storage is essential in the decentralized system. A straightforward storage model with guaranteed privacy protection on the peer-to-peer network is a challenge in the blockchain technology. The decentralized storage system should provide the privacy for the parties since it contains numerous data that are sensitive and dangerous if misused by maliciously. In this paper, we present a model for shared storage on a blockchain network which allows the authorized parties to access the data on storage without having to reveal their identity. Ring signatures combined with several protocols are implemented to disguise the signer identity thereby the observer is unlikely to determine the identity of the parties. We apply our proposed scheme in the healthcare domain, namely, decentralized personal health information (PHI). In addition, we present a dilemma to improve performance in a decentralized system.""
""dc.identifier"",""https://doi.org/10.1155/2019/6219868""
""prism.section"",""Research Article""
""og:url"",""https://www.hindawi.com/journals/wcmc/2019/6219868/""
";https://scholar.google.com/scholar?start=280&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093530-515;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;[PDF][PDF] Search and Tracking of 3D Product Manufacturing Data Using Deep Learning and Blockchain.;A Angrish ;2019 repository.lib.ncsu.edu;;"Page 1. ABSTRACT ANGRISH, ATIN. Search and Tracking of 3D Product Manufacturing Data

Using Deep Learning and Blockchain. (Under the direction of Dr. Binil Starly) … technology which

may be used in conjunction with blockchain. Blockchain technology has …";Autres articles;;[PDF] ncsu.edu;https://repository.lib.ncsu.edu/bitstream/handle/1840.20/37079/etd.pdf?sequence=1;;"""date"",""2019-11-14T20:53:30Z""
""pdf:PDFVersion"",""1.5""
""xmp:CreatorTool"",""Acrobat PDFMaker 18 for Word""
""pdf:docinfo:title"",""ABSTRACT""
""Company"",""Network and Client Services""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""Acrobat PDFMaker 18 for Word""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""ABSTRACT""
""xmp:CreateDate"",""2019-11-14T15:52:58Z""
""modified"",""2019-11-14T20:53:30Z""
""pdf:docinfo:custom:SourceModified"",""D:20191114205248""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""true""
""xmp:ModifyDate"",""2019-11-14T15:53:30Z""
""pdf:docinfo:creator"",""Skyler Bunn""
""meta:author"",""Skyler Bunn""
""meta:creation-date"",""2019-11-14T20:52:58Z""
""created"",""2019-11-14T20:52:58Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-11-14T20:52:58Z""
""resourceName"",""etd.pdf""
""Author"",""Skyler Bunn""
""producer"",""Adobe PDF Library 15.0""
""pdf:docinfo:producer"",""Adobe PDF Library 15.0""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""Skyler Bunn""
""dcterms:created"",""2019-11-14T20:52:58Z""
""Last-Modified"",""2019-11-14T20:53:30Z""
""dcterms:modified"",""2019-11-14T20:53:30Z""
""title"",""ABSTRACT""
""xmpMM:DocumentID"",""uuid:fab69277-62c6-478e-a20d-6e299c3b5053""
""Last-Save-Date"",""2019-11-14T20:53:30Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2019-11-14T20:53:30Z""
""meta:save-date"",""2019-11-14T20:53:30Z""
""Content-Length"",""4880493""
""Content-Type"",""application/pdf""
""xmp:MetadataDate"",""2019-11-14T15:53:30Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Skyler Bunn""
""dc:language"",""EN-US""
""pdf:producer"",""Adobe PDF Library 15.0""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""187""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""2079"",""1466"",""71"",""669"",""232"",""387"",""1394"",""4012"",""4133"",""1839"",""2350"",""2309"",""2309"",""376"",""2311"",""1956"",""2007"",""1893"",""1980"",""1889"",""1817"",""924"",""1860"",""926"",""1850"",""1977"",""1550"",""1475"",""1285"",""442"",""1915"",""2012"",""1959"",""1956"",""1967"",""2061"",""1527"",""1281"",""1958"",""1357"",""1486"",""1755"",""300"",""339"",""470"",""458"",""1053"",""1433"",""973"",""1696"",""1013"",""300"",""65"",""1612"",""1357"",""1159"",""1946"",""2007"",""1968"",""199"",""1565"",""1504"",""1561"",""1588"",""1506"",""1791"",""2009"",""1971"",""1817"",""2007"",""1951"",""2065"",""1982"",""1978"",""2004"",""695"",""397"",""236"",""1208"",""1182"",""515"",""1621"",""1941"",""768"",""1023"",""1698"",""937"",""1351"",""567"",""1484"",""1885"",""1301"",""1675"",""1593"",""1611"",""1548"",""1147"",""1772"",""2089"",""1932"",""2059"",""602"",""2004"",""1779"",""1389"",""2085"",""1914"",""1763"",""1207"",""566"",""1129"",""603"",""962"",""1678"",""1640"",""934"",""1626"",""2018"",""958"",""1737"",""1995"",""1445"",""662"",""680"",""1537"",""1845"",""1987"",""1998"",""2017"",""1447"",""240"",""1436"",""1388"",""1060"",""1945"",""2098"",""959"",""2008"",""2028"",""2034"",""1718"",""1359"",""2045"",""1885"",""896"",""942"",""1781"",""1908"",""518"",""1129"",""774"",""782"",""1011"",""544"",""1050"",""1967"",""899"",""1912"",""1863"",""1955"",""1310"",""508"",""1113"",""367"",""1902"",""2104"",""2039"",""1945"",""1021"",""1315"",""1481"",""1400"",""1386"",""1415"",""1353"",""1509"",""485"",""1936"",""2073"",""1970"",""1826"",""1287"",""1231"",""1954"",""332"",""1605"",""1447""
""access_permission:extract_content"",""true""
""pdf:docinfo:custom:Company"",""Network and Client Services""
""access_permission:can_print"",""true""
""SourceModified"",""D:20191114205248""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-11-14T20:52:58Z""
";https://scholar.google.com/scholar?start=350&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093523-489;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;[CITATION][C] Blockchain abstract data type-full version;E Anceaume, AD Pozzo, R Ludinard… ;2019 CNRSIRISA;;null;Cité 1 fois;;null;;;;https://scholar.google.com/scholar?start=320&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093473-273;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;[PDF][PDF] Providing Trusted Datafeeds to the Blockchain;B Grooteman ; research.tue.nl;;"… IV. RELATED WORK The need for external data on the blockchain and in smart contracts

gave rise to several academic publications. Here we present the existing oracle solutions.

Software oracles: Provable establishes trust by using TLSNotary [10] …";Autres articles;;[PDF] tue.nl;https://research.tue.nl/files/145685273/Thesis_Bram_Grooteman.pdf;;"""date"",""2019-11-26T09:51:11Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2019-11-26T09:51:11Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017/Debian) kpathsea version 6.2.3""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2019-11-26T09:51:11Z""
""created"",""2019-11-26T09:51:11Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-11-26T09:51:11Z""
""resourceName"",""Thesis_Bram_Grooteman.pdf""
""Author"",""""
""producer"",""pdfTeX-1.40.18""
""pdf:docinfo:producer"",""pdfTeX-1.40.18""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""2"",""0"",""1"",""8"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""6"",""41"",""41"",""15"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2019-11-26T09:51:11Z""
""Last-Modified"",""2019-11-26T09:51:11Z""
""dcterms:modified"",""2019-11-26T09:51:11Z""
""title"",""""
""Last-Save-Date"",""2019-11-26T09:51:11Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2019-11-26T09:51:11Z""
""meta:save-date"",""2019-11-26T09:51:11Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017/Debian) kpathsea version 6.2.3""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""20""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""1140"",""4300"",""4559"",""4012"",""4624"",""3556"",""4198"",""4214"",""4168"",""3707"",""4956"",""3906"",""4012"",""3434"",""1316"",""1309"",""1253"",""1335"",""33"",""2""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-11-26T09:51:11Z""
";https://scholar.google.com/scholar?start=110&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093483-311;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;[LIVRE][B] Blockchain: the advent of disintermediation;M Quiniou ;2019 Wiley Online Library;;"… 29 1.3.3. Non-centralization and game theory . . . . . 29 1.3.4. Oracles and decentralization . . . . .

32 … In a debate on the CNBC channel on August 14, 2018, the former President of PayPal,

Bill Harris, described the blockchain and all crypto-currencies as …";Cité 4 fois;Les 3 versions;null;;;;https://scholar.google.com/scholar?start=150&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093448-162;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Decentralized access control for iot data using blockchain and trusted oracles;H Al Breiki, L Al Qassem, K Salah… ; … on Industrial Internet …, 2019  ieeexplore.ieee.org;;"The Internet of Things (IoT) is a network of connected electromechanical devices that have 
limited computational, networking, and storage capabilities. IoT is now widely used in 
healthcare, smart cars, smart grids, smart homes, smart manufacturing, and smart cities. IoT …";Cité 14 fois;Les 3 versions;[PDF] researchgate.net;https://www.researchgate.net/profile/Muhammad_Habib_Ur_Rehman/publication/335258940_Decentralized_Access_Control_for_IoT_Data_Using_Blockchain_and_Trusted_Oracles/links/5dc84890458515143500699a/Decentralized-Access-Control-for-IoT-Data-Using-Blockchain-and-Trusted-Oracles.pdf;;;
1619093516-460;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;[PDF][PDF] Blockchain-based securities offerings;WA Kaal, S Evans ; UC Davis Bus. LJ, 2019  HeinOnline;;"… In December of 2015 the S-3 was declared effective for the crypto-security, a … eliminated by use

of immutable ledger technology or greatly reduced by the availability of oracles. Transaction costs

can be eliminated by blockchain because each token or tokenized piece of property …";Cité 3 fois;Les 3 versions;[PDF] heinonline.org;https://heinonline.org/hol-cgi-bin/get_pdf.cgi?handle=hein.journals/ucdbulj20&section=7&casa_token=qcE6IzM5NgwAAAAA:Kd0R-EPV_llRJgLPxKBT6ifsQtAzhj8_tgfI-ZsLiWHGPCvFwq8X5U5_95QJehann8S946Q;;"""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""REFRESH"",""1; url=https://heinonline.org/HOL/Page?handle=hein.journals/ucdbulj20&div=7&g_sent=1&casa_token=qcE6IzM5NgwAAAAA:Kd0R-EPV_llRJgLPxKBT6ifsQtAzhj8_tgfI-ZsLiWHGPCvFwq8X5U5_95QJehann8S946Q""
""Content-Encoding"",""UTF-8""
""resourceName"",""get_pdf.cgi""
""language"",""""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=290&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093483-314;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Modeling and enforcing blockchain-based choreographies;J Ladleif, M Weske, I Weber ; International Conference on Business …, 2019  Springer;;"… alone. For example, external oracles could be introduced using this technique …

blockchains. As blockchain-based choreographies are realized using smart

contracts, they could technically hold cryptocurrency as well. As …";Cité 17 fois;Les 5 versions;[PDF] researchgate.net;https://www.researchgate.net/profile/Jan_Ladleif/publication/341381526_Modeling_and_Enforcing_Blockchain-Based_Choreographies/links/5ebd72dea6fdcc90d6753e92/Modeling-and-Enforcing-Blockchain-Based-Choreographies.pdf;;;https://scholar.google.com/scholar?start=150&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093532-526;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;How to make undeniable evidence on Secret handshakes;S PANJA, S DUTTA, K SAKURAI ; ??????? 81 ?????, 2019  ipsj.ixsq.nii.ac.jp;;"… 10. Pass, R., “On Deniability in the Common Reference String and Random Oracle Model”,

CRYPTO 2003: 316- 337 (2003). 11 … 14. Yung, M. and Zhao, Y., “Interactive Zero-Knowledge

with Restricted Random Oracles”, In TCC 2006: 21-40 (2006). 15 …";Autres articles;Version HTML;[PDF] nii.ac.jp;https://ipsj.ixsq.nii.ac.jp/ej/?action=repository_action_common_download&item_id=196227&item_no=1&attribute_id=1&file_no=1;;"""date"",""2019-05-23T06:08:35Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0""
""pdf:PDFVersion"",""1.6""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""false""
""access_permission:can_print_degraded"",""true""
""dcterms:created"",""2019-01-23T10:08:05Z""
""language"",""en""
""Last-Modified"",""2019-05-23T06:08:35Z""
""dcterms:modified"",""2019-05-23T06:08:35Z""
""dc:format"",""application/pdf; version=1.6""
""xmpMM:DocumentID"",""uuid:cc2b5c00-8581-4a10-9446-a0ce35dff292""
""Last-Save-Date"",""2019-05-23T06:08:35Z""
""access_permission:fill_in_form"",""false""
""pdf:docinfo:modified"",""2019-05-23T06:08:35Z""
""meta:save-date"",""2019-05-23T06:08:35Z""
""pdf:encrypted"",""true""
""xmp:CreateDate"",""2019-01-23T19:08:05Z""
""modified"",""2019-05-23T06:08:35Z""
""Content-Length"",""254527""
""pdf:hasMarkedContent"",""false""
""Content-Type"",""application/pdf""
""xmp:ModifyDate"",""2019-05-23T15:08:35Z""
""xmp:MetadataDate"",""2019-05-23T15:08:35Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""pdf:producer"",""itext-paulo-153 (itextpdf.sf.net-lowagie.com)""
""meta:creation-date"",""2019-01-23T10:08:05Z""
""created"",""2019-01-23T10:08:05Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""false""
""xmpTPg:NPages"",""2""
""Creation-Date"",""2019-01-23T10:08:05Z""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""5194"",""5306""
""access_permission:extract_content"",""false""
""access_permission:can_print"",""true""
""producer"",""itext-paulo-153 (itextpdf.sf.net-lowagie.com)""
""access_permission:can_modify"",""false""
""pdf:docinfo:producer"",""itext-paulo-153 (itextpdf.sf.net-lowagie.com)""
""pdf:docinfo:created"",""2019-01-23T10:08:05Z""
";https://scholar.google.com/scholar?start=360&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093462-221;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;[LIVRE][B] BLOCKCHAIN KOMPAKT: grundlagen, anwendungsoptionen und kritische bewertung;HG Fill, A Meier ;2019 books.google.com;;"… 60 4.3.4 Oracles zur Integration externer Daten … In: Proceedings Advances in Cryptology –

CRYPTO ‚87, Santa Barbara, California, USA, 369–378 16–20 … 3 Aufbau und Funktion der

Blockchain Zusammenfassung Dieses Kapitel beschreibt den Aufbau von Blockchains (Kette";Cité 13 fois;Les 3 versions;null;;;;https://scholar.google.com/scholar?start=60&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093527-502;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Design and Implementation of an IDPS for the Blockchain Network;IM Ali ;2019 search.proquest.com;;"… Given the public key and access to the signing oracle, an adversary cannot compromise the

private key nor forge a valid … interpretation and execution of transactions by which the blockchain

state transition is achieved … lets, oracles and blockchain browsers …";Autres articles;;null;;;;https://scholar.google.com/scholar?start=340&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093466-242;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Randomblocks: A transparent, verifiable blockchain-based system for random numbers;P Christodoulou, GC Sirakoulis, SA Chatzichristofis… ;2019 hephaestus.nup.ac.cy;;"… blocks, blockhash, diffi- culty etc.), enhanced with external sources of entropy (eg, crypto-currency

prices … evidence of its usage, and thus it goes against the whole blockchain philosophy … in an

immutable ledger to provide publicly available data to any external oracle that requires …";Cité 6 fois;Les 6 versions;[PDF] nup.ac.cy;https://hephaestus.nup.ac.cy/bitstream/handle/11728/11737/Random%20Blocks_Christodoulou_2019.pdf?sequence=1;;;https://scholar.google.com/scholar?start=80&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093543-577;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Who is Causally Responsible for a Cryptocurrency?;P Řstbye ; Available at SSRN 3339537, 2019  papers.ssrn.com;;"… (2017) for a survey of possible attacks on the Bitcoin blockchain … For many cryptocurrencies,

interacting with the outside world is necessary; the cryptocurrency op- erations need … Such

information can be provided by oracles, and the information provided by oracles must be …";Autres articles;;null;;;;https://scholar.google.com/scholar?start=410&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093511-438;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Blockchain bringing Paradigm Shift in Indian Governmental Society Functioning;S Kesharwani, MP Sarkar ; CYBERNOMICS, 2019  cybernomics.in;;"… furthermore, Oracle IoT provides functionality to track vital information like chemical ingredients

of the drug or maintenance of temperature control in case of life saving drugs … Philanthropy, Aid

And Donors Crypto-philanthropy refers to the utilization of blockchain technology to …";Autres articles;;[PDF] cybernomics.in;http://www.cybernomics.in/index.php/cnm/article/download/49/37;;"""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""dc:title"",""302 Found""
""Content-Encoding"",""ISO-8859-1""
""resourceName"",""37""
""language"",""en""
""Content-Length"",""247""
""title"",""302 Found""
""Content-Type"",""text/html; charset=ISO-8859-1""
";https://scholar.google.com/scholar?start=270&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093502-392;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;A New Multisignature Scheme with Public Key Aggregation for Blockchain;DP Le, G Yang, A Ghorbani ; 2019 17th International …, 2019  ieeexplore.ieee.org;;"… The public keys of all co-signers also should be recorded on the blockchain for the purpose of …

params, a chal- lenging public key pk ? corresponding to the honest signer and signing and

hash oracles … scheme is said to be (t, qS,qH,N,?)-secure in the random oracle model if …";Cité 4 fois;Les 3 versions;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/8937293/8949011/08949046.pdf?casa_token=81WQ3pNkRpEAAAAA:503wVCMl32XbcDRdwQAbYB-zG7IF26ppzEF4V80XMHY7lVt6S7MFnGW6iahvfe8-52oXVQSepNs;;"""og:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""twitter:title"",""A New Multisignature Scheme with Public Key Aggregation for Blockchain""
""twitter:card"",""summary""
""Description"",""A multi signature scheme allows a group of signers to produce a joint signature on a common message, which is more compact than a collection of distinct signatu""
""og:title"",""A New Multisignature Scheme with Public Key Aggregation for Blockchain""
""resourceName"",""08949046.pdf""
""language"",""en""
""title"",""A New Multisignature Scheme with Public Key Aggregation for Blockchain | IEEE Conference Publication | IEEE Xplore""
""og:description"",""A multi signature scheme allows a group of signers to produce a joint signature on a common message, which is more compact than a collection of distinct signatures from all signers. Given this signature and the list of signers' public keys, a verifier is able to check if every signer in the group participated in signing. Recently, a multisignature scheme with public key aggregation has drawn a lot of attention due to their applications into the blockchain technology. Such multisignatures provide not only a compact signature, but also a compact aggregated public key, that is both the signature size and the public key size used to verify the correctness of the signature are independent from the number of signers. This is useful for a blockchain because of its duplication over a distributed network, and thus it is required to be as compact as possible. In this paper, we introduce a new multisignature scheme with such a feature. Our scheme is proven secure under the Decisional Diffie-Hellman assumption. In addition, in the presence of rogue key attacks, the security of our scheme is proven in the plain public key model.""
""twitter:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-UA-Compatible"",""IE=Edge""
""viewport"",""width=device-width, initial-scale=1.0""
""dc:title"",""A New Multisignature Scheme with Public Key Aggregation for Blockchain | IEEE Conference Publication | IEEE Xplore""
""twitter:description"",""A multi signature scheme allows a group of signers to produce a joint signature on a common message, which is more compact than a collection of distinct signatures from all signers. Given this signature and the list of signers' public keys, a verifier is able to check if every signer in the group participated in signing. Recently, a multisignature scheme with public key aggregation has drawn a lot of attention due to their applications into the blockchain technology. Such multisignatures provide not only a compact signature, but also a compact aggregated public key, that is both the signature size and the public key size used to verify the correctness of the signature are independent from the number of signers. This is useful for a blockchain because of its duplication over a distributed network, and thus it is required to be as compact as possible. In this paper, we introduce a new multisignature scheme with such a feature. Our scheme is proven secure under the Decisional Diffie-Hellman assumption. In addition, in the presence of rogue key attacks, the security of our scheme is proven in the plain public key model.""
""Content-Encoding"",""UTF-8""
""Content-Type-Hint"",""text/html; charset=utf-8""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=230&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093492-356;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Pre-feasibility study of a blockchain-based platform for P2P energy exchange and self-enforcing payments;D Menegaldo ;2019 webthesis.biblio.polito.it;;"… based energy system management. The project exploits the Tezos blockchain: smart

contracts are connected with oracles that represent smart meters and allow the audit

of energy parameters. The algorithms implemented in …";Les 2 versions;En cache;null;;;;https://scholar.google.com/scholar?start=190&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093487-332;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;The influence factors on ethereum transaction fees;GA Pierro, H Rocha ; … in Software Engineering for Blockchain  …, 2019  ieeexplore.ieee.org;;"… that explains the dynamics of bitcoin prices and models the interconnections among different

crypto and classic … the majority of the nodes reaches a consensus, the block is added to the

blockchain. C. Gas Price Oracle The Etherchain Gas Price Oracle7 is a tool that provides a …";Cité 18 fois;Les 6 versions;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/8820951/8823878/08823908.pdf?casa_token=yzdgWcJwRaAAAAAA:bnKxxDjOhAHo-gYtTncwoAdVRXXKdOabL9DpLcU2MiSLEf2fwOOmmP5rl_oAxtnzZgpSiuaz6R4;;"""og:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""twitter:title"",""The Influence Factors on Ethereum Transaction Fees""
""twitter:card"",""summary""
""Description"",""In Ethereum blockchain, the user needs to set a Gas price to get a transaction processed and approved by Miners. To have the transaction executed, the Gas price""
""og:title"",""The Influence Factors on Ethereum Transaction Fees""
""resourceName"",""08823908.pdf""
""language"",""en""
""title"",""The Influence Factors on Ethereum Transaction Fees | IEEE Conference Publication | IEEE Xplore""
""og:description"",""In Ethereum blockchain, the user needs to set a Gas price to get a transaction processed and approved by Miners. To have the transaction executed, the Gas price has to be greater than or equal to the lowest Ethereum transaction fees. This paper presents a set of data sampled every 15 seconds, from 1 December 2018 to 15 December 2018, coming from different blockchain web APIs. The aim of the paper is to investigate whether and to what extent different variables - such as the number of pending transactions, the value of the USD/Ether pair, average electricity prices around the world, and the number of miners - influence the Ethereum transaction fees. This study is relevant from an economic perspective because more and more companies in different economic fields are adopting Ethereum blockchain. From historical data analysis, we found that only some of these variables do have an influence. For example, the number of pending transactions and the number of miners have a major influence on Ethereum transaction fees when compared to the other variables.""
""twitter:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-UA-Compatible"",""IE=Edge""
""viewport"",""width=device-width, initial-scale=1.0""
""dc:title"",""The Influence Factors on Ethereum Transaction Fees | IEEE Conference Publication | IEEE Xplore""
""twitter:description"",""In Ethereum blockchain, the user needs to set a Gas price to get a transaction processed and approved by Miners. To have the transaction executed, the Gas price has to be greater than or equal to the lowest Ethereum transaction fees. This paper presents a set of data sampled every 15 seconds, from 1 December 2018 to 15 December 2018, coming from different blockchain web APIs. The aim of the paper is to investigate whether and to what extent different variables - such as the number of pending transactions, the value of the USD/Ether pair, average electricity prices around the world, and the number of miners - influence the Ethereum transaction fees. This study is relevant from an economic perspective because more and more companies in different economic fields are adopting Ethereum blockchain. From historical data analysis, we found that only some of these variables do have an influence. For example, the number of pending transactions and the number of miners have a major influence on Ethereum transaction fees when compared to the other variables.""
""Content-Encoding"",""UTF-8""
""Content-Type-Hint"",""text/html; charset=utf-8""
""Content-Length"",""40676""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=170&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093457-202;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;[LIVRE][B] Architecture for blockchain applications;X Xu, I Weber, M Staples ;2019 Springer;;"… the introduction of Bitcoin in 2009 can be considered the birth of blockchain. Since we are now

a decade into its life, the 15-year estimate for widespread adoption seems to be proving out. As

detailed in this book, preliminary applications are emerging beyond cryptocurrency …";Cité 108 fois;Les 3 versions;null;;;;https://scholar.google.com/scholar?start=40&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093543-573;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Multiple channel with crash fault tolerant consensus blockchain network: a case study of vegetables supplier supply chain;H Yusuf, I Surjandari, AMM Rus ; 2019 16th International …, 2019  ieeexplore.ieee.org;;"… challenges and cybercrime, increasing privacy such as determining the details of which

transactions and increasing transaction speeds (real time) [5][7]. In fact, ERP companies such

as SAP and Oracle also want to implement the blockchain in their ERP because of this.[8] …";Cité 5 fois;;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/8876028/8887596/08887678.pdf?casa_token=m0CJL_GMV2EAAAAA:uKUiIqHXSG9OZ7yhi_ZckdWZuJ7iL2KcuEb8XH4H1tPQ3ZHgNMZRUJsZ2gYPaA3BItvGpcCBhk8;;"""og:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""twitter:title"",""Multiple Channel with Crash Fault Tolerant Consensus Blockchain Network: A Case Study of Vegetables Supplier Supply Chain""
""twitter:card"",""summary""
""Description"",""Blockchain has become one of important technologies because of its capabilities such as transparency and privacy. Many enterprises see these capabilities as a b""
""og:title"",""Multiple Channel with Crash Fault Tolerant Consensus Blockchain Network: A Case Study of Vegetables Supplier Supply Chain""
""resourceName"",""08887678.pdf""
""language"",""en""
""title"",""Multiple Channel with Crash Fault Tolerant Consensus Blockchain Network: A Case Study of Vegetables Supplier Supply Chain | IEEE Conference Publication | IEEE Xplore""
""og:description"",""Blockchain has become one of important technologies because of its capabilities such as transparency and privacy. Many enterprises see these capabilities as a breakthrough to many cases, such as supply chain. This paper discusses a case of a vegetables supplier's problems in term of ledger. Generally, the company need one day to finish the ledger and sometimes there are some information distortion between supplier and client. This paper use hyperledger fabric to build blockchain network that is compatible with the supplier problems. The Blockchain network created with nine channels and crash fault tolerant by using kafka. This blockchain network is tested with two iterations which each iteration consists of 40 rounds and each round contains 3000 transactions. The first iteration throughput average is 27.9 tps with the highest throughput is in round 1 with a throughput of 34.1 tps and the lowest is in round 37 with a throughput of 25.3 tps. The second iteration throughput average is 28.1 tps with the highest throughput is in round 1 with a throughput of 32.8 tps and the lowest is in round 40 with a throughput of 21.3 tps. This performance indicates that multiple channel blockchain network could help the vegetables supplier to improve their ledger capabilities to be less than one day.""
""twitter:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-UA-Compatible"",""IE=Edge""
""viewport"",""width=device-width, initial-scale=1.0""
""dc:title"",""Multiple Channel with Crash Fault Tolerant Consensus Blockchain Network: A Case Study of Vegetables Supplier Supply Chain | IEEE Conference Publication | IEEE Xplore""
""twitter:description"",""Blockchain has become one of important technologies because of its capabilities such as transparency and privacy. Many enterprises see these capabilities as a breakthrough to many cases, such as supply chain. This paper discusses a case of a vegetables supplier's problems in term of ledger. Generally, the company need one day to finish the ledger and sometimes there are some information distortion between supplier and client. This paper use hyperledger fabric to build blockchain network that is compatible with the supplier problems. The Blockchain network created with nine channels and crash fault tolerant by using kafka. This blockchain network is tested with two iterations which each iteration consists of 40 rounds and each round contains 3000 transactions. The first iteration throughput average is 27.9 tps with the highest throughput is in round 1 with a throughput of 34.1 tps and the lowest is in round 37 with a throughput of 25.3 tps. The second iteration throughput average is 28.1 tps with the highest throughput is in round 1 with a throughput of 32.8 tps and the lowest is in round 40 with a throughput of 21.3 tps. This performance indicates that multiple channel blockchain network could help the vegetables supplier to improve their ledger capabilities to be less than one day.""
""Content-Encoding"",""UTF-8""
""Content-Type-Hint"",""text/html; charset=utf-8""
""Content-Length"",""42408""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=410&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093541-568;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;A fuzz testing service for assuring smart contracts;X Mei, I Ashraf, B Jiang… ; 2019 IEEE 19th …, 2019  ieeexplore.ieee.org;;"… of a set of smart contracts as a whole and the design of precise test oracles for several … the

submission, the testing service decrypts the code and deploys the decrypted code on its

blockchain in a … If there is any error with respect to the built-in test oracle of the fuzzer is found …";Cité 3 fois;Les 5 versions;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/8848633/8859367/08859497.pdf?casa_token=hjfr8bDchoIAAAAA:ZcNYZMSF3Vh2k3h5Ubi1MoybkH7wRfZmgO96XNvZHw_NsICo_Z6xKzOGXGR0dyVu2DVwIdYDYQg;;"""og:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""twitter:title"",""A Fuzz Testing Service for Assuring Smart Contracts""
""twitter:card"",""summary""
""Description"",""Smart contracts are code to keep agreements in the form of data or smart contracts residing in a blockchain system. Making data corruptions to these data record""
""og:title"",""A Fuzz Testing Service for Assuring Smart Contracts""
""resourceName"",""08859497.pdf""
""language"",""en""
""title"",""A Fuzz Testing Service for Assuring Smart Contracts | IEEE Conference Publication | IEEE Xplore""
""og:description"",""Smart contracts are code to keep agreements in the form of data or smart contracts residing in a blockchain system. Making data corruptions to these data records may lead to insert unwanted agreements, corrupt an existing one, or remove the latter ones mistakenly. This paper reports the progress of our progress in developing a fuzz testing service with client side support. It will present the overall approach of the testing services followed by a discussion on the road ahead.""
""twitter:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-UA-Compatible"",""IE=Edge""
""viewport"",""width=device-width, initial-scale=1.0""
""dc:title"",""A Fuzz Testing Service for Assuring Smart Contracts | IEEE Conference Publication | IEEE Xplore""
""twitter:description"",""Smart contracts are code to keep agreements in the form of data or smart contracts residing in a blockchain system. Making data corruptions to these data records may lead to insert unwanted agreements, corrupt an existing one, or remove the latter ones mistakenly. This paper reports the progress of our progress in developing a fuzz testing service with client side support. It will present the overall approach of the testing services followed by a discussion on the road ahead.""
""Content-Encoding"",""UTF-8""
""Content-Type-Hint"",""text/html; charset=utf-8""
""Content-Length"",""39179""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=400&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093530-512;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;[PDF][PDF] The Blockchain as Enabling Technology for Energy Communities.;F CRESPI ; foroeuropa.it;;"… 35 4.2 Oracles ..... 37 … gathered into blocks and added to the Blockchain. The

nodes that take part in this process are known as miners … Verify that the

transactions are valid - for example, in the case of crypto …";Autres articles;Version HTML;[PDF] foroeuropa.it;http://www.foroeuropa.it/documenti/rivista/TesiFrancescoMariaFranza.pdf;;"""date"",""2019-11-22T13:08:00Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.7""
""xmp:CreatorTool"",""MicrosoftÂŽ Word per Office 365""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dc:creator"",""francesco maria franza""
""language"",""en""
""dcterms:created"",""2019-11-22T13:08:00Z""
""Last-Modified"",""2019-11-22T13:08:00Z""
""dcterms:modified"",""2019-11-22T13:08:00Z""
""dc:format"",""application/pdf; version=1.7""
""xmpMM:DocumentID"",""uuid:17714F34-547F-4883-9D5D-2C0E1438C63F""
""Last-Save-Date"",""2019-11-22T13:08:00Z""
""pdf:docinfo:creator_tool"",""MicrosoftÂŽ Word per Office 365""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2019-11-22T13:08:00Z""
""meta:save-date"",""2019-11-22T13:08:00Z""
""pdf:encrypted"",""false""
""xmp:CreateDate"",""2019-11-22T14:08:00Z""
""modified"",""2019-11-22T13:08:00Z""
""Content-Length"",""975348""
""pdf:hasMarkedContent"",""true""
""Content-Type"",""application/pdf""
""xmp:ModifyDate"",""2019-11-22T14:08:00Z""
""pdf:docinfo:creator"",""francesco maria franza""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""francesco maria franza""
""dc:language"",""it-IT""
""meta:author"",""francesco maria franza""
""pdf:producer"",""MicrosoftÂŽ Word per Office 365""
""meta:creation-date"",""2019-11-22T13:08:00Z""
""created"",""2019-11-22T13:08:00Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""108""
""Creation-Date"",""2019-11-22T13:08:00Z""
""resourceName"",""TesiFrancescoMariaFranza.pdf""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""549"",""5"",""2726"",""3024"",""686"",""1685"",""726"",""1621"",""1193"",""681"",""1961"",""1369"",""296"",""858"",""1163"",""764"",""614"",""1617"",""573"",""1109"",""1049"",""1266"",""763"",""495"",""1221"",""1325"",""1131"",""1545"",""1241"",""1105"",""726"",""794"",""894"",""1602"",""1194"",""1608"",""1321"",""215"",""1435"",""798"",""1216"",""1752"",""440"",""1268"",""1209"",""1097"",""1404"",""1406"",""970"",""1318"",""1139"",""1222"",""909"",""1203"",""508"",""1192"",""1526"",""1706"",""2209"",""1596"",""1181"",""1763"",""1138"",""1678"",""1443"",""247"",""1300"",""1705"",""1722"",""201"",""1580"",""755"",""1236"",""1481"",""711"",""1495"",""739"",""518"",""1044"",""259"",""1095"",""1227"",""1317"",""1432"",""1069"",""1448"",""1562"",""1577"",""1388"",""1435"",""1298"",""1823"",""1338"",""1007"",""1419"",""1482"",""397"",""1055"",""1385"",""1511"",""905"",""1173"",""1362"",""1310"",""1605"",""1490"",""440"",""6""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""Author"",""francesco maria franza""
""producer"",""MicrosoftÂŽ Word per Office 365""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""MicrosoftÂŽ Word per Office 365""
""pdf:docinfo:created"",""2019-11-22T13:08:00Z""
";https://scholar.google.com/scholar?start=350&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093518-468;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;[PDF][PDF] Modeling Business Processes on a Blockchain Ecosystem using CMMN;S Filipova ; core.ac.uk;;"… Section 2 introduces some background on blockchain technology including concepts of smart

contract, token, and oracles … It includes blockchain technology with necessary notion such

as smart contracts, token, oracle and different types of blockchain …";Autres articles;Version HTML;[PDF] core.ac.uk;https://core.ac.uk/download/pdf/237085273.pdf;;"""date"",""2019-08-14T07:39:19Z""
""pdf:PDFVersion"",""1.7""
""xmp:CreatorTool"",""Microsoft® Word для Office 365""
""pdf:docinfo:title"",""Modeling Business Processes on a Blockchain Ecosystem using CMMN""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""Master’s Thesis (20 ECTS)""
""language"",""en""
""dc:format"",""application/pdf; version=1.7""
""pdf:docinfo:creator_tool"",""Microsoft® Word для Office 365""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""Modeling Business Processes on a Blockchain Ecosystem using CMMN""
""xmp:CreateDate"",""2019-08-14T10:39:19Z""
""modified"",""2019-08-14T07:39:19Z""
""cp:subject"",""Master’s Thesis (20 ECTS)""
""pdf:docinfo:subject"",""Master’s Thesis (20 ECTS)""
""pdf:hasMarkedContent"",""true""
""xmp:ModifyDate"",""2019-08-14T10:39:19Z""
""pdf:docinfo:creator"",""Svitlana Filipova""
""meta:author"",""Svitlana Filipova""
""meta:creation-date"",""2019-08-14T07:39:19Z""
""created"",""2019-08-14T07:39:19Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-08-14T07:39:19Z""
""resourceName"",""237085273.pdf""
""Author"",""Svitlana Filipova""
""producer"",""Microsoft® Word для Office 365""
""pdf:docinfo:producer"",""Microsoft® Word для Office 365""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""dc:description"",""Master’s Thesis (20 ECTS)""
""Keywords"",""Blockchain, CMMN, Business Process Models"",""Blockchain, CMMN, Business Process Models""
""access_permission:modify_annotations"",""true""
""dc:creator"",""Svitlana Filipova""
""description"",""Master’s Thesis (20 ECTS)""
""dcterms:created"",""2019-08-14T07:39:19Z""
""Last-Modified"",""2019-08-14T07:39:19Z""
""dcterms:modified"",""2019-08-14T07:39:19Z""
""title"",""Modeling Business Processes on a Blockchain Ecosystem using CMMN""
""xmpMM:DocumentID"",""uuid:FD975038-7712-40EE-96E0-796C503C9940""
""Last-Save-Date"",""2019-08-14T07:39:19Z""
""pdf:docinfo:keywords"",""Blockchain, CMMN, Business Process Models""
""pdf:docinfo:modified"",""2019-08-14T07:39:19Z""
""meta:save-date"",""2019-08-14T07:39:19Z""
""Content-Length"",""1434696""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Svitlana Filipova""
""dc:language"",""ru-RU""
""pdf:producer"",""Microsoft® Word для Office 365""
""dc:subject"",""Blockchain, CMMN, Business Process Models"",""Blockchain, CMMN, Business Process Models""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""43""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""376"",""3763"",""4390"",""3945"",""2723"",""3493"",""3902"",""3936"",""3299"",""1800"",""913"",""3364"",""2718"",""3616"",""3537"",""3349"",""2337"",""37"",""40"",""3866"",""1488"",""43"",""41"",""3306"",""3139"",""2484"",""2028"",""1761"",""2771"",""3644"",""2621"",""4047"",""1789"",""2258"",""3731"",""2954"",""1181"",""1794"",""3203"",""3546"",""3607"",""325"",""1271""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""meta:keyword"",""Blockchain, CMMN, Business Process Models"",""Blockchain, CMMN, Business Process Models""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-08-14T07:39:19Z""
";https://scholar.google.com/scholar?start=300&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093466-249;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;AUDABLOK: Engaging Citizens in Open Data Refinement through Blockchain;M Emaldi, K Zabaleta, D López;deIpińa  … Digital Publishing Institute …, 2019  mdpi.com;;"… The blockchain protocol integration module acts as a smart oracle, which is blockchain network

agnostic and pluggable to … Blockchain: The Next Innovation To Make Our Cities Smarter; PWC:

London, UK, 2018 … Liu, A. Smart Oracles: Building Business Logic with Smart Contracts …";Cité 1 fois;;[PDF] mdpi.com;https://www.mdpi.com/2504-3900/31/1/52/pdf;;;https://scholar.google.com/scholar?start=80&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093485-321;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Read-uncommitted transactions for smart contract performance;V Cook, Z Painter, C Peterson… ; 2019 IEEE 39th …, 2019  ieeexplore.ieee.org;;"… D. Runtime Argument Augmentation Blockchain oracles provide a secure and verifiable medium

for smart … our implementation of HMS it became clear that a traditional oracle would not … To overcome

the limita- tions of oracles, we propose Runtime Argument Augmentation (RAA …";Cité 10 fois;Les 4 versions;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/8867821/8884790/08884987.pdf?casa_token=StdLrr3t4cgAAAAA:sIIR3HoDUsle4q1-i2Hol6yL__0nhzCgID9r4Rgoo1GNDkJzfFBk0mZRh-9rvqx9DeWfg5A1r6A;;"""og:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""twitter:title"",""Read-Uncommitted Transactions for Smart Contract Performance""
""twitter:card"",""summary""
""Description"",""Smart contract transactions demonstrate issues of performance and correctness that application programmers must work around. Although the blockchain consensus m""
""og:title"",""Read-Uncommitted Transactions for Smart Contract Performance""
""resourceName"",""08884987.pdf""
""language"",""en""
""title"",""Read-Uncommitted Transactions for Smart Contract Performance | IEEE Conference Publication | IEEE Xplore""
""og:description"",""Smart contract transactions demonstrate issues of performance and correctness that application programmers must work around. Although the blockchain consensus mechanism approaches ACID compliance, use cases that rely on frequent state changes are impractical due to the block publishing interval of O(10^1) seconds. The effective isolation level is Read-Committed, only revealing state transitions at the end of the block interval. Values read may be stale and not match program order, causing many transactions to fail when a block is committed. This paper perceives the blockchain as a transactional data structure, using this analogy in the development of a new algorithm, Hash-Mark-Set (HMS), that improves transaction throughput by providing a Read-Uncommitted view of state variables. HMS creates a directed acyclic graph (DAG) from the pending transaction pool. The transaction order derived from the DAG is used to provide a Read-Uncommitted view of the data for new transactions, which enter the DAG as they are received. An implementation of HMS is provided, interoperable with Ethereum and ready for use in smart contracts. Over a wide range of transaction mixes, HMS is demonstrated to improve throughput. A side product of the implementation is a new technique, Runtime Argument Augmentation (RAA), that allows smart contracts to communicate with external data services before submitting a transaction. RAA has use cases beyond HMS and can serve as a lightweight replacement for blockchain oracles.""
""twitter:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-UA-Compatible"",""IE=Edge""
""viewport"",""width=device-width, initial-scale=1.0""
""dc:title"",""Read-Uncommitted Transactions for Smart Contract Performance | IEEE Conference Publication | IEEE Xplore""
""twitter:description"",""Smart contract transactions demonstrate issues of performance and correctness that application programmers must work around. Although the blockchain consensus mechanism approaches ACID compliance, use cases that rely on frequent state changes are impractical due to the block publishing interval of O(10^1) seconds. The effective isolation level is Read-Committed, only revealing state transitions at the end of the block interval. Values read may be stale and not match program order, causing many transactions to fail when a block is committed. This paper perceives the blockchain as a transactional data structure, using this analogy in the development of a new algorithm, Hash-Mark-Set (HMS), that improves transaction throughput by providing a Read-Uncommitted view of state variables. HMS creates a directed acyclic graph (DAG) from the pending transaction pool. The transaction order derived from the DAG is used to provide a Read-Uncommitted view of the data for new transactions, which enter the DAG as they are received. An implementation of HMS is provided, interoperable with Ethereum and ready for use in smart contracts. Over a wide range of transaction mixes, HMS is demonstrated to improve throughput. A side product of the implementation is a new technique, Runtime Argument Augmentation (RAA), that allows smart contracts to communicate with external data services before submitting a transaction. RAA has use cases beyond HMS and can serve as a lightweight replacement for blockchain oracles.""
""Content-Encoding"",""UTF-8""
""Content-Type-Hint"",""text/html; charset=utf-8""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=160&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093471-261;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;[PDF][PDF] Towards a Framework for Evaluation of Blockchain Implementations.;O Labazova ; ICIS, 2019  core.ac.uk;;"… In some scenarios, involved processors can operate as black boxes and do not reveal the way

they came to specific results (eg, Oracles): the operations … For example, confidentiality issues in

Bitcoin blockchain led to the development of Zcash, a cryptocurrency that encrypts …";Cité 14 fois;Les 4 versions;[PDF] core.ac.uk;https://core.ac.uk/download/pdf/301384314.pdf;;"""date"",""2020-05-28T19:04:00Z""
""pdf:PDFVersion"",""1.7""
""xmp:CreatorTool"",""Appligent pdfHarmony 2.0""
""pdf:docinfo:title"",""Towards a Framework for Evaluation of Blockchain Implementations""
""Appligent"",""pdfHarmony 2.0 Linux Kernel 2.6 64bit Mar 13 2012 Library 9.0.1""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""language"",""en""
""dc:format"",""application/pdf; version=1.7""
""pdf:docinfo:creator_tool"",""Appligent pdfHarmony 2.0""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""Towards a Framework for Evaluation of Blockchain Implementations""
""xmp:CreateDate"",""2020-05-28T12:04:00Z""
""modified"",""2020-05-28T19:04:00Z""
""pdf:hasMarkedContent"",""true""
""xmp:ModifyDate"",""2020-05-28T12:04:07Z""
""pdf:docinfo:creator"",""Olga Labazova""
""meta:author"",""Olga Labazova""
""meta:creation-date"",""2020-05-28T19:04:00Z""
""created"",""2020-05-28T19:04:00Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-05-28T19:04:00Z""
""resourceName"",""301384314.pdf""
""Author"",""Olga Labazova""
""producer"",""Prince 12.5 (www.princexml.com)""
""pdf:docinfo:producer"",""Prince 12.5 (www.princexml.com)""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""access_permission:modify_annotations"",""true""
""dc:creator"",""Olga Labazova""
""dcterms:created"",""2020-05-28T19:04:00Z""
""Last-Modified"",""2020-05-28T19:04:00Z""
""dcterms:modified"",""2020-05-28T19:04:00Z""
""pdf:docinfo:custom:Appligent"",""pdfHarmony 2.0 Linux Kernel 2.6 64bit Mar 13 2012 Library 9.0.1""
""title"",""Towards a Framework for Evaluation of Blockchain Implementations""
""xmpMM:DocumentID"",""uuid:467bc130-ae7e-11b2-0a00-a06e04010000""
""Last-Save-Date"",""2020-05-28T19:04:00Z""
""pdf:docinfo:modified"",""2020-05-28T19:04:00Z""
""meta:save-date"",""2020-05-28T19:04:00Z""
""Content-Length"",""1136731""
""Content-Type"",""application/pdf""
""xmp:MetadataDate"",""2020-05-28T12:04:07Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Olga Labazova""
""dc:language"",""en""
""pdf:producer"",""Prince 12.5 (www.princexml.com)""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""17""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""953"",""3533"",""4945"",""4332"",""4219"",""5135"",""2833"",""5183"",""5320"",""5166"",""4968"",""5284"",""4632"",""4856"",""4798"",""2344"",""2101""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-05-28T19:04:00Z""
";https://scholar.google.com/scholar?start=100&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093497-378;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;vchain: Enabling verifiable boolean range queries over blockchain databases;C Xu, C Zhang, J Xu ; Proceedings of the 2019 international conference …, 2019  dl.acm.org;;"… In a blockchain-based patent manage- ment system, users can use Boolean operators to search

for combinations of keywords, such as “Blockchain”?(“Query”? “Search”), in the patents' abstracts

[9]. Whereas many com- panies, including database giants IBM, Oracle, and SAP …";Cité 44 fois;Les 7 versions;[PDF] acm.org;https://dl.acm.org/doi/pdf/10.1145/3299869.3300083?casa_token=cXPXGXDGU7kAAAAA:kSvPdKOfblUNj_qrfO_ZF296Sd7uIEl4iEskZYTZpg45zKaWYsJEW4eumk5NaY3hFPd0dqDVcRM;;;https://scholar.google.com/scholar?start=210&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093487-338;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;On the convergence of blockchain and internet of things (iot) technologies;M Maroufi, R Abdolee, BM Tazekand ; arXiv preprint arXiv:1904.01936, 2019  arxiv.org;;"… The people who hold the particular cryptocurrency will be able to make votes by their token …

Blockchain suggests a high level of security to each individual user as it eliminates using … It provides

an address and associated crypto-assets through a combination of public and private …";Cité 23 fois;Les 5 versions;[PDF] arxiv.org;https://arxiv.org/pdf/1904.01936;;"""date"",""2019-04-04T01:22:53Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2019-04-04T01:22:53Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016) kpathsea version 6.2.2""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2019-04-04T01:22:53Z""
""created"",""2019-04-04T01:22:53Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-04-04T01:22:53Z""
""resourceName"",""1904.01936""
""Author"",""""
""producer"",""pdfTeX-1.40.17""
""pdf:docinfo:producer"",""pdfTeX-1.40.17""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2019-04-04T01:22:53Z""
""Last-Modified"",""2019-04-04T01:22:53Z""
""dcterms:modified"",""2019-04-04T01:22:53Z""
""title"",""""
""Last-Save-Date"",""2019-04-04T01:22:53Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2019-04-04T01:22:53Z""
""meta:save-date"",""2019-04-04T01:22:53Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016) kpathsea version 6.2.2""
""Content-Length"",""902914""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""11""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""5163"",""5048"",""5075"",""5192"",""5846"",""5203"",""3630"",""4723"",""4417"",""5876"",""5825""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-04-04T01:22:53Z""
";https://scholar.google.com/scholar?start=170&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093457-204;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Public immunization against complete subversion without random oracles;G Ateniese, D Francati, B Magri, D Venturi ; International Conference on …, 2019  Springer;;"… B. Magri—The author was supported by the Concordium Blockchain Research Center, Aarhus

University, Denmark … All their results are in the random oracle model (ROM) of Bellare and

Rogaway … can be instantiated in the standard model (ie, without random oracles) assuming a …";Cité 7 fois;Les 3 versions;null;;;;https://scholar.google.com/scholar?start=40&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093516-453;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;[PDF][PDF] An Empirical Analysis of Blockchain Cybersecurity Incidents;MJ Morshed, PA Watters ; researchgate.net;;"… Providers of external data feeds are called Oracles … Furthermore, the trustworthiness of an oracle

and source verification properties of the blockchain is difficult … to-peer electronic cash system,

(2008) [7] Yaga, D., P. Mell, N. Roby, and K. Scarfone: Blockchain technology overview …";Autres articles;Version HTML;[PDF] researchgate.net;https://www.researchgate.net/profile/Alex_Ng14/publication/337647279_An_Empirical_Analysis_of_Blockchain_Cybersecurity_Incidents/links/5e087691a6fdcc2837460279/An-Empirical-Analysis-of-Blockchain-Cybersecurity-Incidents.pdf;;;https://scholar.google.com/scholar?start=290&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093541-565;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Contratos Inteligentes sobre registros confiables de polución: una propuesta usando dispositivos IoT, entornos de ejecución seguro y oráculos blockchain;Á Algovia García ;2019 eprints.ucm.es;;"… A proposal using Iot devices, Trusted Execution Environments and Blockchain Oracles Contratos

Inteligentes sobre registros confiables de polución … KEY WORDS Blockchain, Smart Contract,

Oracle, Trusted Execution Environment, Trusted Internet of Things Devices. Page 14 …";Autres articles;;[PDF] ucm.es;https://eprints.ucm.es/id/eprint/57090/1/AngelAlgoviaGarcia.pdf;;"""date"",""2019-07-11T16:58:19Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.4""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""language"",""es""
""Last-Modified"",""2019-07-11T16:58:19Z""
""dcterms:modified"",""2019-07-11T16:58:19Z""
""dc:format"",""application/pdf; version=1.4""
""Last-Save-Date"",""2019-07-11T16:58:19Z""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2019-07-11T16:58:19Z""
""meta:save-date"",""2019-07-11T16:58:19Z""
""pdf:encrypted"",""false""
""modified"",""2019-07-11T16:58:19Z""
""Content-Length"",""1367660""
""pdf:hasMarkedContent"",""false""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""dc:language"",""es-ES""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""68""
""resourceName"",""AngelAlgoviaGarcia.pdf""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""520"",""146"",""583"",""946"",""928"",""62"",""203"",""64"",""743"",""62"",""1915"",""62"",""1689"",""62"",""4552"",""2646"",""973"",""63"",""928"",""63"",""2682"",""2147"",""1535"",""1783"",""753"",""1650"",""1758"",""543"",""1783"",""1484"",""494"",""1998"",""1851"",""2251"",""537"",""63"",""1775"",""3135"",""387"",""1412"",""1591"",""1626"",""2312"",""1161"",""2145"",""2057"",""1430"",""247"",""2160"",""2138"",""1909"",""167"",""1524"",""1702"",""485"",""1399"",""884"",""484"",""1079"",""811"",""1842"",""1844"",""3325"",""1780"",""2781"",""1507"",""1034"",""63""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""producer"",""www.ilovepdf.com""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""www.ilovepdf.com""
";https://scholar.google.com/scholar?start=400&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093469-252;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Practical aggregate signature from general elliptic curves, and applications to blockchain;Y Zhao ; Proceedings of the 2019 ACM Asia Conference on …, 2019  dl.acm.org;;"… ?-signature in signa- ture aggregation, which is particularly crucial for applications to blockchain

and cryptocurrency … wayness in [70] is to mitigate the depen- dency of provable security on random

oracles … and He used for ?-signature, only Hd is assumed to be a random oracle …";Cité 5 fois;;[PDF] acm.org;https://dl.acm.org/doi/pdf/10.1145/3321705.3329826?casa_token=E_KoHoI9abcAAAAA:HUUGFQwEekwbo97KUEK4cgvFeZmWEmO3vS8MNEW_E-5fxBAM4nJafeWhBitXGGmL2uKclSN7svU;;;https://scholar.google.com/scholar?start=90&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093509-430;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;[PDF][PDF] Crypto Assets and Insider Trading Law's Domain;A Verstein ; Iowa L. Rev., 2019  HeinOnline;;"… 6o. Not all virtual currencies involve the distinctive technological features of cryptocurrency …

computers verify that the transaction genuinely took place and then record the transaction in the

blockchain … they are compensated by fees, often in the form of the relevant crypto assets …";Cité 8 fois;Les 6 versions;[PDF] heinonline.org;https://heinonline.org/hol-cgi-bin/get_pdf.cgi?handle=hein.journals/ilr105&section=5&casa_token=8Lsw8Stu5sgAAAAA:7Uwz3bHiqingnGrobqM1KPLo9_9_SsiaMsP1RLZ59pasuUcWvh4AOcVQVYs8l-j-ocYl3NA;;"""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""REFRESH"",""1; url=https://heinonline.org/HOL/Page?handle=hein.journals/ilr105&div=5&g_sent=1&casa_token=8Lsw8Stu5sgAAAAA:7Uwz3bHiqingnGrobqM1KPLo9_9_SsiaMsP1RLZ59pasuUcWvh4AOcVQVYs8l-j-ocYl3NA""
""Content-Encoding"",""UTF-8""
""resourceName"",""get_pdf.cgi""
""language"",""""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=260&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093459-215;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Tighter security proofs for generic key encapsulation mechanism in the quantum random oracle model;H Jiang, Z Zhang, Z Ma ; International Conference on PostQuantum …, 2019  Springer;;"… The security of these generic constructions in the quantum random oracle model (QROM) has

been analyzed by Hofheinz, Hövelmanns and Kiltz (TCC … (Crypto 2018) … is q and the degree of

security loss is 2, where q is the total number of adversarial queries to various oracles …";Cité 27 fois;Les 4 versions;[PDF] iacr.org;https://eprint.iacr.org/2019/134.pdf;;"""date"",""2019-02-14T03:39:36Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""30"",""22"",""88"",""8"",""18"",""24"",""29"",""33"",""20"",""24"",""9"",""40"",""3"",""0"",""15"",""14"",""21"",""25"",""12"",""55"",""22"",""30"",""25"",""22"",""26"",""27"",""17"",""21"",""32"",""23"",""15"",""3"",""23"",""38"",""5""
""pdf:PDFVersion"",""1.5""
""xmp:CreatorTool"",""TeX""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dcterms:created"",""2019-02-14T03:39:36Z""
""language"",""en""
""Last-Modified"",""2019-02-14T03:39:36Z""
""dcterms:modified"",""2019-02-14T03:39:36Z""
""dc:format"",""application/pdf; version=1.5""
""Last-Save-Date"",""2019-02-14T03:39:36Z""
""pdf:docinfo:creator_tool"",""TeX""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2019-02-14T03:39:36Z""
""meta:save-date"",""2019-02-14T03:39:36Z""
""pdf:encrypted"",""false""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is MiKTeX-pdfTeX 2.9.4307 (1.40.12)""
""modified"",""2019-02-14T03:39:36Z""
""Content-Length"",""551033""
""pdf:hasMarkedContent"",""false""
""Content-Type"",""application/pdf""
""PTEX.Fullbanner"",""This is MiKTeX-pdfTeX 2.9.4307 (1.40.12)""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""trapped"",""False""
""meta:creation-date"",""2019-02-14T03:39:36Z""
""created"",""2019-02-14T03:39:36Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""36""
""Creation-Date"",""2019-02-14T03:39:36Z""
""resourceName"",""134.pdf""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""1985"",""2758"",""1870"",""1728"",""2404"",""2304"",""2029"",""1773"",""2269"",""973"",""2219"",""1532"",""1493"",""2434"",""3032"",""1763"",""1414"",""1245"",""1699"",""978"",""2006"",""1724"",""1274"",""1395"",""1174"",""1274"",""1383"",""1158"",""956"",""1779"",""1303"",""1314"",""1124"",""1438"",""1482"",""388""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""producer"",""MiKTeX pdfTeX-1.40.12""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""MiKTeX pdfTeX-1.40.12""
""pdf:docinfo:created"",""2019-02-14T03:39:36Z""
";https://scholar.google.com/scholar?start=50&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093520-479;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Blockchain technology and complex flow systems as opportunities for water governance innovation;R Paiva Sobrinho, JR Garcia, AG Maia… ; Revista brasileira …, 2019  repositorio.unicamp.br;;"… Oracles are reliable sources of information and data that serve as inputs for smart contracts … the

temperature measurement service of a government institution could use an oracle to provide …

However, blockchain technology can also be used as a tool for solving several problems …";Cité 2 fois;Les 3 versions;[PDF] unicamp.br;http://repositorio.unicamp.br/bitstream/REPOSIP/343387/2/8654757.pdf;;"""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.3""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""21""
""resourceName"",""8654757.pdf""
""language"",""en""
""pdf:hasXMP"",""false""
""dc:format"",""application/pdf; version=1.3""
""pdf:charsPerPage"",""654"",""2024"",""1665"",""2671"",""3040"",""2640"",""2446"",""2730"",""2585"",""2855"",""2702"",""2714"",""3325"",""2687"",""2814"",""2859"",""2240"",""2261"",""2301"",""2132"",""479""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""producer"",""PyPDF2""
""Content-Length"",""283396""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""PyPDF2""
""pdf:hasMarkedContent"",""false""
""Content-Type"",""application/pdf""
";https://scholar.google.com/scholar?start=310&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093497-375;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Dependable Industrial Crypto Computing;A Kancharla, J Seol, N Park, I Park… ; 2019 IEEE 28th …, 2019  ieeexplore.ieee.org;;"… paper. Fig. 3. Secutiryeffective vs qcheck?secure at various values of qrollback

and crypto - rate IV. THE … not deterministic. Hence, the work of accessing data outside

the blockchain network is done by Oracles. Oracles are …";Cité 3 fois;;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/8767359/8781085/08781245.pdf?casa_token=rCVtj_PPwjAAAAAA:lNAQ1RVxrJBHj6phYhqb3NU7DKTB_bU9-LvupvzM28idEfDHNU-FJIzxGCnsZZlP_RXBhCPbvLc;;"""og:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""twitter:title"",""Dependable Industrial Crypto Computing""
""twitter:card"",""summary""
""Description"",""This paper presents a work on how to assure the dependability of a crypto system built across on and off the blockchain by using the proposed adaptive checkpoin""
""og:title"",""Dependable Industrial Crypto Computing""
""resourceName"",""08781245.pdf""
""language"",""en""
""title"",""Dependable Industrial Crypto Computing | IEEE Conference Publication | IEEE Xplore""
""og:description"",""This paper presents a work on how to assure the dependability of a crypto system built across on and off the blockchain by using the proposed adaptive checkpoint and rollback algorithm, and a prototype is developed for demonstration purpose.The theoretical background of the proposed checkpoint and rollback algorithm is studied to characterize the variables affecting the dependability such as security, authenticity and reliability with respect to the rates of hit by any events of those issues, the rates to detect and diagnose, and then the rate to vote for a consensus whether to trigger a rollback or not. Based on the variables characterization in a stochastic manner, then steady state probabilities and state transition probabilities are derived in order to assure the ultimate effective dependability of each individual dependability variable (i.e., security, authenticity and reliability), then finally to assure the dependability in a compound manner with each variable assigned a weight depending on the nature of the systems specifications.Based on the theoretical study, a protype of a crypto system is built to demonstrated the underlying architecture and operations and to justify the need for such system to take synergistic advantages from both on- and off-chain blockchains, with an experimental result of a benefit in gas fee which is the most exigently addressed issue today in blockchain systems especially in Ethereum network of blockchains. An astonishing gas fee saving results are demonstrated. It is observed that the crypto system benefits more if more computationally intensive transactions are executed off-chain while vice versa.""
""twitter:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-UA-Compatible"",""IE=Edge""
""viewport"",""width=device-width, initial-scale=1.0""
""dc:title"",""Dependable Industrial Crypto Computing | IEEE Conference Publication | IEEE Xplore""
""twitter:description"",""This paper presents a work on how to assure the dependability of a crypto system built across on and off the blockchain by using the proposed adaptive checkpoint and rollback algorithm, and a prototype is developed for demonstration purpose.The theoretical background of the proposed checkpoint and rollback algorithm is studied to characterize the variables affecting the dependability such as security, authenticity and reliability with respect to the rates of hit by any events of those issues, the rates to detect and diagnose, and then the rate to vote for a consensus whether to trigger a rollback or not. Based on the variables characterization in a stochastic manner, then steady state probabilities and state transition probabilities are derived in order to assure the ultimate effective dependability of each individual dependability variable (i.e., security, authenticity and reliability), then finally to assure the dependability in a compound manner with each variable assigned a weight depending on the nature of the systems specifications.Based on the theoretical study, a protype of a crypto system is built to demonstrated the underlying architecture and operations and to justify the need for such system to take synergistic advantages from both on- and off-chain blockchains, with an experimental result of a benefit in gas fee which is the most exigently addressed issue today in blockchain systems especially in Ethereum network of blockchains. An astonishing gas fee saving results are demonstrated. It is observed that the crypto system benefits more if more computationally intensive transactions are executed off-chain while vice versa.""
""Content-Encoding"",""UTF-8""
""Content-Type-Hint"",""text/html; charset=utf-8""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=210&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093480-305;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;[PDF][PDF] The Implementation of Decentralised Ledger Technologies for Public Procurement: Blockchain Based Smart Public Contracts;SN Sánchez ; Eur. Procurement & Pub. Private Partnership L. Rev., 2019  HeinOnline;;"… 3. Blockchain-based Network On the heels of Bitcoin, different platforms were cre ated to add

new functionalities which, in turn, al lowed for the implementation of blockchain technol ogy

to a wide range of fields rather than just to the cryptocurrency's world …";Cité 6 fois;Les 4 versions;[PDF] heinonline.org;https://heinonline.org/hol-cgi-bin/get_pdf.cgi?handle=hein.journals/epppl2019&section=29&casa_token=jZKVHN3k7v4AAAAA:FsbI7g1rcN6mi8zn18QZP5G8M23QKMyZvtY3x8yFbT5rUgL6EhDVxkFmUtIZatHKOWRf4_c;;"""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""REFRESH"",""1; url=https://heinonline.org/HOL/Page?handle=hein.journals/epppl2019&div=29&g_sent=1&casa_token=jZKVHN3k7v4AAAAA:FsbI7g1rcN6mi8zn18QZP5G8M23QKMyZvtY3x8yFbT5rUgL6EhDVxkFmUtIZatHKOWRf4_c""
""Content-Encoding"",""UTF-8""
""resourceName"",""get_pdf.cgi""
""language"",""""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=140&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093504-401;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Deductive Proof of Industrial Smart Contracts Using Why3;Z Nehaď, F Bobot ; International Symposium on Formal Methods, 2019  Springer;;"… Oracle Notions. Developing smart contracts often relies on the concept of Oracles [1]. An

oracle can be seen as the link between the blockchain and the “real world”. Some smart

contracts functions have arguments that are external to the blockchain …";Cité 1 fois;;null;;;;https://scholar.google.com/scholar?start=240&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093511-431;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;[PDF][PDF] Deploying Real World Blockchain Systems;WC Chun, B Eber, S Saiph ; Cyberspace studies, 2019  par.nsf.gov;;"… Beyond cryptocurrency, blockchain technology can be used in other financial services, such as

foreign exchange, insurance, and loan … For the oracle problem, researchers can integrate the

blockchain with IoT (Internet of Thing) to provide the truth data, or probe into the …";Autres articles;Version HTML;[PDF] nsf.gov;https://par.nsf.gov/servlets/purl/10139959;;"""date"",""2020-03-17T13:20:24Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.5""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""pdfa:PDFVersion"",""A-2b""
""xmpMM:History:Action"",""converted""
""dcterms:created"",""2020-03-17T13:20:18Z""
""language"",""en""
""dc:format"",""application/pdf; version=""""A-2b"""""",""application/pdf; version=1.5""
""Last-Modified"",""2020-03-17T13:20:24Z""
""dcterms:modified"",""2020-03-17T13:20:24Z""
""xmpMM:DocumentID"",""uuid:d73a203e-e3e9-4d3a-943d-c311c19a021a""
""Last-Save-Date"",""2020-03-17T13:20:24Z""
""access_permission:fill_in_form"",""true""
""xmpMM:History:When"",""2020-03-17T09:20:24Z""
""pdf:docinfo:modified"",""2020-03-17T13:20:24Z""
""meta:save-date"",""2020-03-17T13:20:24Z""
""pdf:encrypted"",""false""
""xmp:CreateDate"",""2020-03-17T09:20:18Z""
""modified"",""2020-03-17T13:20:24Z""
""xmpMM:History:SoftwareAgent"",""Preflight""
""Content-Length"",""126725""
""pdf:hasMarkedContent"",""false""
""xmpMM:History:InstanceID"",""uuid:a80c772f-cc48-49d3-9f54-684f4cef5efe""
""Content-Type"",""application/pdf""
""xmp:ModifyDate"",""2020-03-17T09:20:24Z""
""xmp:MetadataDate"",""2020-03-17T09:20:24Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""pdfaid:conformance"",""B""
""pdf:producer"",""Skia/PDF m82""
""meta:creation-date"",""2020-03-17T13:20:18Z""
""created"",""2020-03-17T13:20:18Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""7""
""Creation-Date"",""2020-03-17T13:20:18Z""
""resourceName"",""10139959""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""2277"",""2488"",""2857"",""2433"",""2978"",""3181"",""3566""
""access_permission:extract_content"",""true""
""pdfaid:part"",""2""
""access_permission:can_print"",""true""
""producer"",""Skia/PDF m82""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""Skia/PDF m82""
""pdf:docinfo:created"",""2020-03-17T13:20:18Z""
";https://scholar.google.com/scholar?start=270&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093532-522;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Blockchain projects ecosystem: A review of current technical and legal challenges;J Lopes, JL Pereira ; World Conference on Information Systems and …, 2019  Springer;;"… This category is divided into Smart Contracts, Scaling, Oracles, Security, Legal, Interoperability,

Privacy and … Equally, the unique transparency of transactions on the Blockchain is not easily

compatible with the privacy needs of the banking sector: the use of crypto-addresses for …";Cité 3 fois;;null;;;;https://scholar.google.com/scholar?start=360&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093483-316;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Exploiting the laws of order in smart contracts;A Kolluri, I Nikolic, I Sergey, A Hobor… ; Proceedings of the 28th …, 2019  dl.acm.org;;"… The replies from these services can be asynchro- nous, leading to a nondeterministic ordering

on the blockchain … These further wagers will initiate further oracle queries, and depending on

the behavior of the off-chain oracles, their corresponding callbacks may not be …";Cité 46 fois;Les 10 versions;[PDF] acm.org;https://dl.acm.org/doi/pdf/10.1145/3293882.3330560?casa_token=zL_XLxgacKEAAAAA:yXmGVMR42T_LcyusPteAxxWmmqTXZRxhk6u80NgFGW0LNWTC5-8V41IBGoa-YopAKpzpGk_9C48;;;https://scholar.google.com/scholar?start=150&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093527-504;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Blockchain Technologies in E-commerce: Social Shopping and Loyalty Program Applications;YH Lim, H Hashim, N Poo, DCC Poo… ; … Conference on Human …, 2019  Springer;;"… Aeternity. Aeternity was established by Yanislav Malahov in 2016 as a scalable blockchain

platform [9]. It enables high bandwidth transactions, smart contracts with built-in oracles. The

state channel and oracle system ensure a high degree of flexibility …";Cité 1 fois;Les 2 versions;[PDF] researchgate.net;https://www.researchgate.net/profile/Hoang_Nguyen228/publication/332977375_Blockchain_Technologies_in_E-commerce_Social_Shopping_and_Loyalty_Program_Applications/links/5cd4e522a6fdccc9dd9c611d/Blockchain-Technologies-in-E-commerce-Social-Shopping-and-Loyalty-Program-Applications.pdf;;;https://scholar.google.com/scholar?start=340&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093506-416;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;[PDF][PDF] All smart contracts are ambiguous;J Grimmelmann ; JL & Innovation, 2019  HeinOnline;;"… A. Oracles How does a smart contract observe the world … The car is a real thing in the

real world, not a virtual thing defined by the blockchain VM. The smart contract cannot

directly observe it. The standard solution is to rely on an oracle to";Cité 19 fois;Les 8 versions;[PDF] heinonline.org;https://heinonline.org/hol-cgi-bin/get_pdf.cgi?handle=hein.journals/jlinno2&section=4&casa_token=o2dDQ8qch6UAAAAA:-ejIlTPvOyWKNRAPFcpgJsH3taN4-VLBZspRqiNe0tigobRL29l-Y7MmsF90yMQFlXRFjtw;;"""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""REFRESH"",""1; url=https://heinonline.org/HOL/Page?handle=hein.journals/jlinno2&div=4&g_sent=1&casa_token=o2dDQ8qch6UAAAAA:-ejIlTPvOyWKNRAPFcpgJsH3taN4-VLBZspRqiNe0tigobRL29l-Y7MmsF90yMQFlXRFjtw""
""Content-Encoding"",""UTF-8""
""resourceName"",""get_pdf.cgi""
""language"",""""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=250&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093527-508;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;[PDF][PDF] Using Service Design to Foster Consumer Bargaining Power and Decentralised Supply Chain Operations Through a Blockchain-Based Marketplace;LFS Amaral ;2019 repositorioaberto.up.pt;;"… Similar to Bitcoin, Ethereum is a public blockchain network where users can transfer data using

a cryptocurrency named Ether … Since inputs from the real world are needed, oracles are often

invoked to bring external state into the smart contracts on the blockchain …";;;[PDF] up.pt;https://repositorio-aberto.up.pt/bitstream/10216/123010/2/359626.pdf;;"""date"",""2019-09-24T22:39:02Z""
""pdf:PDFVersion"",""1.7""
""xmp:CreatorTool"",""MicrosoftÂŽ Word para Office 365""
""pdf:docinfo:title"",""Using service design to foster consumer bargaining power and decentralised supply chain operations through a blockchain-based marketplace""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""language"",""en""
""dc:format"",""application/pdf; version=1.7""
""pdf:docinfo:creator_tool"",""MicrosoftÂŽ Word para Office 365""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""Using service design to foster consumer bargaining power and decentralised supply chain operations through a blockchain-based marketplace""
""xmp:CreateDate"",""2019-09-24T23:39:02Z""
""modified"",""2019-09-24T22:39:02Z""
""pdf:hasMarkedContent"",""true""
""xmp:ModifyDate"",""2019-09-24T23:39:02Z""
""pdf:docinfo:creator"",""Luis Amaral""
""meta:author"",""Luis Amaral""
""meta:creation-date"",""2019-09-24T22:39:02Z""
""created"",""2019-09-24T22:39:02Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-09-24T22:39:02Z""
""resourceName"",""359626.pdf""
""Author"",""Luis Amaral""
""producer"",""MicrosoftÂŽ Word para Office 365""
""pdf:docinfo:producer"",""MicrosoftÂŽ Word para Office 365""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""access_permission:modify_annotations"",""true""
""dc:creator"",""Luis Amaral""
""dcterms:created"",""2019-09-24T22:39:02Z""
""Last-Modified"",""2019-09-24T22:39:02Z""
""dcterms:modified"",""2019-09-24T22:39:02Z""
""title"",""Using service design to foster consumer bargaining power and decentralised supply chain operations through a blockchain-based marketplace""
""xmpMM:DocumentID"",""uuid:430E53C6-19E6-451B-AEF6-0A07EFA14EEF""
""Last-Save-Date"",""2019-09-24T22:39:02Z""
""pdf:docinfo:modified"",""2019-09-24T22:39:02Z""
""meta:save-date"",""2019-09-24T22:39:02Z""
""Content-Length"",""1783395""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Luis Amaral""
""dc:language"",""en-GB""
""pdf:producer"",""MicrosoftÂŽ Word para Office 365""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""48""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""254"",""108"",""1839"",""948"",""3603"",""99"",""447"",""348"",""3311"",""2332"",""3260"",""1215"",""1799"",""3919"",""3023"",""1763"",""2755"",""3842"",""1401"",""3547"",""1650"",""1305"",""776"",""3589"",""1855"",""593"",""2823"",""2833"",""2009"",""1126"",""2176"",""803"",""2470"",""1358"",""667"",""3715"",""1551"",""1865"",""1782"",""2032"",""1999"",""1930"",""558"",""76"",""41"",""96"",""41"",""878""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-09-24T22:39:02Z""
";https://scholar.google.com/scholar?start=340&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093536-550;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;[CITATION][C] Mastering Blockchain Programming with Solidity: Write production-ready smart contracts for Ethereum blockchain with Solidity;J Chittoda ;2019 Packt Publishing;;null;Cité 2 fois;;null;;;;https://scholar.google.com/scholar?start=380&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093525-499;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;[PDF][PDF] MaaS meets blockchain an exploratory study on the promises of blockchain technologies for enabling a MaaS platform;TJ de Wilde ; pure.tue.nl;;"… MASTER MaaS meets blockchain an exploratory study on the promises of blockchain technologies

for enabling a MaaS platform de Wilde, TJ Award date: 2019 … The proposed technologies are:

5G networks, autonomous vehicle technology and Blockchain technology …";Cité 1 fois;Les 3 versions;[PDF] tue.nl;https://pure.tue.nl/ws/portalfiles/portal/117656445/Wilde_de_Thesis_Mobility_as_a_servi%09e_blockchain_Final.pdf;;"""date"",""2019-01-18T08:55:58Z""
""pdf:PDFVersion"",""1.6""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:docinfo:title"",""""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.6""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""xmp:CreateDate"",""2019-01-18T08:52:55Z""
""modified"",""2019-01-18T08:55:58Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""true""
""xmp:ModifyDate"",""2019-01-18T09:55:58Z""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017) kpathsea version 6.2.3""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2019-01-18T08:52:55Z""
""created"",""2019-01-18T08:52:55Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-01-18T08:52:55Z""
""resourceName"",""Wilde_de_Thesis_Mobility_as_a_servi%09e_blockchain_Final.pdf""
""Author"",""""
""producer"",""pdfTeX-1.40.18""
""pdf:docinfo:producer"",""pdfTeX-1.40.18""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2019-01-18T08:52:55Z""
""Last-Modified"",""2019-01-18T08:55:58Z""
""dcterms:modified"",""2019-01-18T08:55:58Z""
""title"",""""
""xmpMM:DocumentID"",""uuid:1a1abf02-d0c5-4bea-a2be-521dab9aa9e4""
""Last-Save-Date"",""2019-01-18T08:55:58Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2019-01-18T08:55:58Z""
""meta:save-date"",""2019-01-18T08:55:58Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017) kpathsea version 6.2.3""
""Content-Type"",""application/pdf""
""xmp:MetadataDate"",""2019-01-18T09:55:58Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""pdf:producer"",""pdfTeX-1.40.18""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""110""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""1207"",""1"",""2334"",""2756"",""2303"",""1137"",""532"",""1380"",""1979"",""1437"",""1129"",""395"",""1373"",""1954"",""3269"",""2952"",""2909"",""1889"",""2264"",""1572"",""2550"",""2729"",""2710"",""2594"",""2154"",""2439"",""2412"",""50"",""1365"",""2357"",""2013"",""2009"",""2364"",""2699"",""1651"",""3197"",""1366"",""1728"",""2771"",""111"",""1748"",""1413"",""2894"",""2593"",""1972"",""2225"",""1060"",""1676"",""2256"",""30"",""1248"",""2735"",""2254"",""2789"",""2714"",""2612"",""2749"",""2611"",""3104"",""2550"",""2628"",""2849"",""2692"",""1148"",""27"",""1534"",""1716"",""3106"",""2509"",""2362"",""2053"",""2872"",""2558"",""2233"",""2963"",""2265"",""2995"",""2754"",""2663"",""2963"",""2391"",""2477"",""1829"",""3067"",""3003"",""2941"",""2830"",""3036"",""3178"",""2574"",""1133"",""2809"",""2484"",""3004"",""2284"",""1461"",""2978"",""2571"",""2092"",""133"",""13"",""3213"",""1476"",""1577"",""2063"",""2137"",""1898"",""2175"",""2280"",""696""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-01-18T08:52:55Z""
";https://scholar.google.com/scholar?start=330&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093546-585;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Ouroboros crypsinous: Privacy-preserving proof-of-stake;T Kerber, A Kiayias, M Kohlweiss… ; 2019 IEEE Symposium …, 2019  ieeexplore.ieee.org;;"… THE MODEL Following the recent line of works proving composable security of blockchain ledgers

[2], [1] we provide our protocol and security proof in Canetti's universal composition (UC)

framework [8]. In this … A global random oracle GRO for abstracting hash function queries …";Cité 35 fois;Les 14 versions;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/8826229/8835208/08835272.pdf?casa_token=ldmZ_miJ0l4AAAAA:0gZ5yBhnEgM0Lzb5vMDE6MaCygCa1sO8c5WfDMZOXWQML_bnDo_dU9EkWPq4ThPSItHgrT9R4zI;;"""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""dc:title"",""IEEE Xplore Full-Text PDF:""
""Content-Encoding"",""UTF-8""
""resourceName"",""08835272.pdf""
""language"",""es""
""Content-Length"",""2533""
""title"",""IEEE Xplore Full-Text PDF:""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=420&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093469-251;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;A blockchain-based solution to fake check-ins in location-based social networks;S Migliorini, M Gambini, A Belussi ; … on Analytics for Local Events and …, 2019  dl.acm.org;;"… In principle, it can be built by means of oracles and used during a smart contract … In the following,

we assume the existence of an oracle implemented as a decentralized network of … 1, it takes advan-

tages of the blockchain technology for both certifying the location of users and …";Cité 1 fois;Les 3 versions;[PDF] acm.org;https://dl.acm.org/doi/pdf/10.1145/3356473.3365191?casa_token=43bLT9bS3zEAAAAA:pqX_7R8LqIriDTYy8o8JtngkogJE5SjctdELbvyLsdIHT4TYwwLhIgkDqAFHazM8ddR6LtdX64o;;;https://scholar.google.com/scholar?start=90&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093499-390;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;[PDF][PDF] Trust Me: Combining Online Dispute Resolution, Law and Blockchain Technology;T van der Linden ; Indian JL & Tech., 2019  HeinOnline;;"… Several approaches have been proposed to make Oracles more reliable, such as combining

different kinds of Oracles, using Oracles which aggregate information from a variety of sources,

or implementing the Oracle on its own consensus-based blockchain. 9 …";Les 2 versions;;[PDF] heinonline.org;https://heinonline.org/hol-cgi-bin/get_pdf.cgi?handle=hein.journals/indiajoula15&section=15&casa_token=aZE_yXqN_UUAAAAA:YlAWKArRvko6_aV7yjLNeN1Ytz0BdQcRAlP3y1WwbFuXy0jQ2c_tc1iQWPv1Uyt0kdf5WXE;;"""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""REFRESH"",""1; url=https://heinonline.org/HOL/Page?handle=hein.journals/indiajoula15&div=15&g_sent=1&casa_token=aZE_yXqN_UUAAAAA:YlAWKArRvko6_aV7yjLNeN1Ytz0BdQcRAlP3y1WwbFuXy0jQ2c_tc1iQWPv1Uyt0kdf5WXE""
""Content-Encoding"",""UTF-8""
""resourceName"",""get_pdf.cgi""
""language"",""""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=220&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093466-246;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Re-thinking untraceability in the cryptonote-style blockchain;J Yu, MHA Au… ; 2019 IEEE 32nd Computer …, 2019  ieeexplore.ieee.org;;"… as in Game-1. This game simulates a strong adversary that not only sees the entire blockchain

transactions, but also with the following two oracles empowered respectively … The first oracle is

a corruption oracle that allows an adversary to learn the corresponding secret of a …";Cité 6 fois;Les 7 versions;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/8804915/8823657/08823713.pdf?casa_token=f5q7ZYc-uycAAAAA:m0en6pQnQSvdAVxL2r80zbeNd-nheL9kXCcwVhNMXXDPBt6QcNYJUnQ7OVt3Hz-8oENIJH-Sg64;;"""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""dc:title"",""IEEE Xplore Full-Text PDF:""
""Content-Encoding"",""UTF-8""
""resourceName"",""08823713.pdf""
""language"",""es""
""Content-Length"",""2533""
""title"",""IEEE Xplore Full-Text PDF:""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=80&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093466-241;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Towards blockchain interoperability;S Schulte, M Sigwart, P Frauenthaler… ; … Conference on Business …, 2019  Springer;;"… the earliest contributions in the field of blockchain interoperability is the idea of a trustless

cryptocurrency exchange realized … prove that the tokens were actually destroyed on the source

blockchain, or (b) the target blockchain relies on information provided by oracles [16], to …";Cité 19 fois;Les 6 versions;[PDF] tuwien.ac.at;https://www.dsg.tuwien.ac.at/team/sschulte/paper/2019_SSFB19_BPM_BF.pdf;;"""date"",""2019-07-12T10:10:18Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.5""
""xmp:CreatorTool"",""TeX""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dcterms:created"",""2019-07-12T10:10:18Z""
""language"",""en""
""Last-Modified"",""2019-07-12T10:10:18Z""
""dcterms:modified"",""2019-07-12T10:10:18Z""
""dc:format"",""application/pdf; version=1.5""
""Last-Save-Date"",""2019-07-12T10:10:18Z""
""pdf:docinfo:creator_tool"",""TeX""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2019-07-12T10:10:18Z""
""meta:save-date"",""2019-07-12T10:10:18Z""
""pdf:encrypted"",""false""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.20 (TeX Live 2019/W32TeX) kpathsea version 6.3.1""
""modified"",""2019-07-12T10:10:18Z""
""Content-Length"",""155808""
""pdf:hasMarkedContent"",""false""
""Content-Type"",""application/pdf""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.20 (TeX Live 2019/W32TeX) kpathsea version 6.3.1""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""trapped"",""False""
""meta:creation-date"",""2019-07-12T10:10:18Z""
""created"",""2019-07-12T10:10:18Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""8""
""Creation-Date"",""2019-07-12T10:10:18Z""
""resourceName"",""2019_SSFB19_BPM_BF.pdf""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""2147"",""2523"",""2827"",""2922"",""2614"",""2775"",""2203"",""2479""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""producer"",""pdfTeX-1.40.20""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""pdfTeX-1.40.20""
""pdf:docinfo:created"",""2019-07-12T10:10:18Z""
";https://scholar.google.com/scholar?start=80&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093499-383;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;[PDF][PDF] The impact of smart contracts on traditional concepts of contract law;MK Woebbeking ; J. Intell. Prop. Info. Tech. & Elec. Com. L., 2019  HeinOnline;;"… is a need to use ambiguous clauses in a smart contract, it is likely that interpretational difficulties

will be resolved by assigning them to a human-based oracle.""* This assignment to a human-based

oracle naturally also … 48 Cardozo Blockchain Project (n 19) 6; Oracles can in …";Cité 16 fois;;[PDF] heinonline.org;https://heinonline.org/hol-cgi-bin/get_pdf.cgi?handle=hein.journals/jipitec10&section=12&casa_token=dOatO6deXMcAAAAA:RMNbu1LTo4HXPiXgtGRiMGWwQzGkUwNrjSkEWdUqSL8QdqlRrx10K1sjy1GSL8J2wYQt51o;;"""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""REFRESH"",""1; url=https://heinonline.org/HOL/Page?handle=hein.journals/jipitec10&div=12&g_sent=1&casa_token=dOatO6deXMcAAAAA:RMNbu1LTo4HXPiXgtGRiMGWwQzGkUwNrjSkEWdUqSL8QdqlRrx10K1sjy1GSL8J2wYQt51o""
""Content-Encoding"",""UTF-8""
""resourceName"",""get_pdf.cgi""
""language"",""""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=220&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093532-529;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;[PDF][PDF] The current landscape of blockchain-based, crowdsourced arbitration;J Metzger ; Macquarie LJ, 2019  HeinOnline;;"… 17 See Wulf Kaal and Craig Calcaterra, 'Crypto Transaction Dispute Resolution' (2017) 73(1)

Business Lawyer lo9, 114 … real-world events can be imported into the contract code through the

use of 'oracles', or external … BLOCKCHAIN-BASED CROWDSOURCED ARBITRATION …";Cité 6 fois;Les 6 versions;[PDF] heinonline.org;https://heinonline.org/hol-cgi-bin/get_pdf.cgi?handle=hein.journals/macq19&section=8&casa_token=X4MYonIk3qAAAAAA:_GWB8eHjwPClA6vpQtU4ruE-HWOFxbh71dopCYxH2-LzY4RGCnoRpCXVtlRzr0hzBE10uEY;;"""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""REFRESH"",""1; url=https://heinonline.org/HOL/Page?handle=hein.journals/macq19&div=8&g_sent=1&casa_token=X4MYonIk3qAAAAAA:_GWB8eHjwPClA6vpQtU4ruE-HWOFxbh71dopCYxH2-LzY4RGCnoRpCXVtlRzr0hzBE10uEY""
""Content-Encoding"",""UTF-8""
""resourceName"",""get_pdf.cgi""
""language"",""""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=360&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093509-426;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Revisiting practical byzantine fault tolerance through blockchain technologies;N Stifter, A Judmayer, E Weippl ; Security and Quality in CyberPhysical …, 2019  Springer;;"… Random oracles in constantinople: Practical asynchronous byzantine agreement using

cryptography … 3, pp. 317–326). Piscataway, NJ: IEEE.Google Scholar. King, S., & Nadal, S. (2012).

Ppcoin: Peer-to-peer crypto-currency with proof-of-stake … Blockchain based access control …";Cité 3 fois;Les 3 versions;null;;;;https://scholar.google.com/scholar?start=260&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093483-315;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;VULTRON: catching vulnerable smart contracts once and for all;H Wang, Y Li, SW Lin, L Ma… ; 2019 IEEE/ACM 41st …, 2019  ieeexplore.ieee.org;;"… 2), are deployed on the blockchain … are important dynamic techniques for detecting security

vulnerabilities, both of which require a test oracle to determine if … Coming up with such oracles

and properties for general purpose computer programs can be cumbersome and requires …";Cité 20 fois;Les 5 versions;[PDF] ntu.edu.sg;https://personal.ntu.edu.sg/yi_li/files/Wang2019VUL.pdf;;"""date"",""2019-03-27T01:10:56Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""10"",""2"",""18""
""pdf:PDFVersion"",""1.5""
""xmp:CreatorTool"",""TeX""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dcterms:created"",""2019-03-27T01:10:56Z""
""language"",""en""
""Last-Modified"",""2019-03-27T01:10:56Z""
""dcterms:modified"",""2019-03-27T01:10:56Z""
""dc:format"",""application/pdf; version=1.5""
""Last-Save-Date"",""2019-03-27T01:10:56Z""
""pdf:docinfo:creator_tool"",""TeX""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2019-03-27T01:10:56Z""
""meta:save-date"",""2019-03-27T01:10:56Z""
""pdf:encrypted"",""false""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.19 (TeX Live 2018) kpathsea version 6.3.0""
""modified"",""2019-03-27T01:10:56Z""
""Content-Length"",""182443""
""pdf:hasMarkedContent"",""false""
""Content-Type"",""application/pdf""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.19 (TeX Live 2018) kpathsea version 6.3.0""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""trapped"",""False""
""meta:creation-date"",""2019-03-27T01:10:56Z""
""created"",""2019-03-27T01:10:56Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""4""
""Creation-Date"",""2019-03-27T01:10:56Z""
""resourceName"",""Wang2019VUL.pdf""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""4878"",""5312"",""4888"",""5491""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""producer"",""pdfTeX-1.40.19""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""pdfTeX-1.40.19""
""pdf:docinfo:created"",""2019-03-27T01:10:56Z""
";https://scholar.google.com/scholar?start=150&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093516-456;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Quantum security proofs using semi-classical oracles;A Ambainis, M Hamburg, D Unruh ; Annual International Cryptology …, 2019  Springer;;"… CRYPTO 2019: Advances in Cryptology – CRYPTO 2019 pp 269-295 | Cite as. Quantum Security

Proofs Using Semi-classical Oracles … Non-uniform random oracles. The random oracle that is

reprogrammed does not have to be a uniformly random function …";Cité 47 fois;Les 5 versions;[PDF] iacr.org;https://eprint.iacr.org/2018/904.pdf;;"""date"",""2019-02-18T14:04:11Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2019-02-18T14:04:11Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017/Debian) kpathsea version 6.2.3""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2019-02-18T14:04:11Z""
""created"",""2019-02-18T14:04:11Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-02-18T14:04:11Z""
""resourceName"",""904.pdf""
""Author"",""""
""producer"",""pdfTeX-1.40.18""
""pdf:docinfo:producer"",""pdfTeX-1.40.18""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""6"",""0"",""1"",""4"",""27"",""12"",""16"",""0"",""21"",""17"",""46"",""27"",""81"",""34"",""70"",""179"",""87"",""48"",""16"",""146"",""53"",""157"",""49"",""28"",""9"",""9"",""15"",""35"",""43"",""16"",""47"",""44"",""27"",""52"",""16"",""21"",""0"",""0"",""0"",""0"",""7""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2019-02-18T14:04:11Z""
""Last-Modified"",""2019-02-18T14:04:11Z""
""dcterms:modified"",""2019-02-18T14:04:11Z""
""title"",""""
""Last-Save-Date"",""2019-02-18T14:04:11Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2019-02-18T14:04:11Z""
""meta:save-date"",""2019-02-18T14:04:11Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017/Debian) kpathsea version 6.2.3""
""Content-Length"",""587582""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""45""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""1287"",""2604"",""2491"",""2326"",""3034"",""2544"",""2679"",""2719"",""2329"",""1681"",""1525"",""1902"",""2153"",""1936"",""1539"",""1625"",""1230"",""1456"",""1532"",""1414"",""1278"",""1529"",""1316"",""1453"",""1420"",""1715"",""1486"",""1712"",""1434"",""1560"",""1750"",""1488"",""1473"",""1568"",""2052"",""2211"",""1882"",""1887"",""2308"",""1843"",""2024"",""2248"",""2084"",""2153"",""714""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-02-18T14:04:11Z""
";https://scholar.google.com/scholar?start=290&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093459-216;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Blockchain-Based Trusted Cross-organizational Deliveries of Sensor-Equipped Parcels;M Müller, SR Garzon ; European Conference on Parallel Processing, 2019  Springer;;"… Smart IoT devices can act as oracles in blockchain networks. An Oracle serves

as the sources of information, which is present off-chain, but needs to be available

on-chain in order to execute certain business processes …";Cité 1 fois;Les 3 versions;[PDF] researchgate.net;https://www.researchgate.net/profile/Marcel_Mueller35/publication/335994841_Blockchain-based_Trusted_Cross-organizational_Deliveries_of_Sensor-equipped_Parcels/links/5d8a0fc092851ceb793b2584/Blockchain-based-Trusted-Cross-organizational-Deliveries-of-Sensor-equipped-Parcels.pdf;;;https://scholar.google.com/scholar?start=50&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093527-510;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;A blockchain-based privacy-preserving medical insurance storage system;S Luong ;2019 unbscholar.lib.unb.ca;;"Page 1. A Blockchain-based Privacy-preserving Medical Insurance Storage System by Son Luong …

and proposes our future research work. 19 Page 32. Chapter 2 Technical Background of

Blockchain The blockchain can be thought of as a distributed ledger. The ledger is typ …";Cité 1 fois;Les 2 versions;[PDF] unb.ca;https://unbscholar.lib.unb.ca/islandora/object/unbscholar%3A9830/datastream/PDF/view;;"""date"",""2019-05-08T18:38:10Z""
""pdf:unmappedUnicodeCharsPerPage"",""1"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""1"",""4"",""24"",""3"",""3"",""0"",""2"",""2"",""43"",""14"",""0"",""0"",""21"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""9"",""6"",""0"",""0"",""6"",""0"",""2"",""8"",""0"",""9"",""0"",""0"",""0"",""6"",""9"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""2"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""3"",""4"",""1"",""8"",""4"",""7"",""2"",""0"",""8"",""2"",""1"",""0"",""3"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.5""
""xmp:CreatorTool"",""TeX""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dcterms:created"",""2019-05-07T18:42:22Z""
""language"",""en""
""Last-Modified"",""2019-05-08T18:38:10Z""
""dcterms:modified"",""2019-05-08T18:38:10Z""
""dc:format"",""application/pdf; version=1.5""
""xmpMM:DocumentID"",""uuid:4e0495f0-07ce-41a0-bcea-559aec3e87d2""
""Last-Save-Date"",""2019-05-08T18:38:10Z""
""pdf:docinfo:creator_tool"",""TeX""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2019-05-08T18:38:10Z""
""meta:save-date"",""2019-05-08T18:38:10Z""
""pdf:encrypted"",""false""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017) kpathsea version 6.2.3""
""xmp:CreateDate"",""2019-05-07T18:42:22Z""
""modified"",""2019-05-08T18:38:10Z""
""Content-Length"",""1172976""
""pdf:hasMarkedContent"",""false""
""Content-Type"",""application/pdf""
""xmp:ModifyDate"",""2019-05-08T15:38:10Z""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017) kpathsea version 6.2.3""
""xmp:MetadataDate"",""2019-05-08T15:38:10Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""pdf:producer"",""pdfTeX-1.40.18""
""trapped"",""False""
""meta:creation-date"",""2019-05-07T18:42:22Z""
""created"",""2019-05-07T18:42:22Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""133""
""Creation-Date"",""2019-05-07T18:42:22Z""
""resourceName"",""view""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""577"",""1013"",""186"",""345"",""418"",""908"",""942"",""919"",""222"",""420"",""758"",""109"",""763"",""1019"",""1221"",""653"",""1328"",""971"",""1004"",""961"",""981"",""1044"",""1186"",""1049"",""1147"",""939"",""1055"",""1255"",""858"",""957"",""434"",""569"",""1179"",""835"",""1262"",""956"",""839"",""1433"",""783"",""1337"",""1130"",""1119"",""1146"",""1247"",""1210"",""1129"",""1111"",""956"",""1136"",""1217"",""1187"",""1421"",""689"",""574"",""961"",""809"",""703"",""798"",""714"",""979"",""884"",""1119"",""770"",""1081"",""981"",""952"",""681"",""281"",""532"",""1072"",""1242"",""1154"",""1001"",""564"",""526"",""1018"",""898"",""809"",""1040"",""889"",""936"",""791"",""818"",""622"",""862"",""709"",""721"",""354"",""475"",""1255"",""1258"",""1169"",""936"",""972"",""709"",""1202"",""532"",""693"",""1121"",""115"",""609"",""897"",""680"",""1133"",""1066"",""1118"",""1157"",""869"",""961"",""1032"",""950"",""1083"",""289"",""268"",""560"",""616"",""838"",""568"",""1035"",""916"",""1074"",""677"",""693"",""941"",""563"",""685"",""916"",""614"",""637"",""587"",""700"",""291"",""327""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""producer"",""pdfTeX-1.40.18""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""pdfTeX-1.40.18""
""pdf:docinfo:created"",""2019-05-07T18:42:22Z""
";https://scholar.google.com/scholar?start=340&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093534-540;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;[HTML][HTML] Hierarchical Byzantine fault-tolerance protocol for permissioned blockchain systems;QT Thai, JC Yim, TW Yoo, HK Yoo, JY Kwak… ; The Journal of …, 2019  Springer;United States of America;"… Bitcoin has existed and has shown its resilience against all kinds of attack for more than

10 years. The emerging of crypto-currency and its underlying blockchain technology

have drawn much attention from industry and academic [37, 38] …";Cité 4 fois;Les 2 versions;[HTML] springer.com;https://idp.springer.com/authorize/casa?redirect_uri=https://link.springer.com/article/10.1007/s11227-019-02939-x&casa_token=ABmc_yKDNNMAAAAA:4hy8tLA_44FGWZqbr_ZRvaCWOtNCgZQBNR9y4-wdxhneFNsA1ou7L-zs0aqPcD0neEgy08iMJZ-_feY;;"""dc.publisher"",""Springer""
""og:image"",""https://media.springernature.com/w200/springer-static/cover/journal/11227.jpg""
""twitter:card"",""summary""
""og:site_name"",""The Journal of Supercomputing""
""citation_reference"",""citation_journal_title=ACM SIGOPS Oper Syst Rev; citation_title=Fault-scalable Byzantine fault-tolerant services; citation_author=M Abd-El-Malek, GR Ganger, GR Goodson, MK Reiter, JJ Wylie; citation_volume=39; citation_publication_date=2005; citation_pages=59-74; citation_doi=10.1145/1095809.1095817; citation_id=CR1"",""citation_journal_title=IEEE Trans Dependable Secure Comput; citation_title=Steward: Scaling Byzantine fault-tolerant replication to wide area networks; citation_author=Y Amir, C Danilov, D Dolev, J Kirsch, J Lane, C Nita-Rotaru, J Olsen, D Zage; citation_volume=7; citation_issue=1; citation_publication_date=2010; citation_pages=80-93; citation_doi=10.1109/TDSC.2008.53; citation_id=CR2"",""Androulaki E, Barger A, Bortnikov V, Cachin C, Christidis K, De Caro A, Enyeart D, Ferris C, Laventman G, Manevich, Y et al (2018) Hyperledger fabric: a distributed operating system for permissioned blockchains. In: Proceedings of the Thirteenth EuroSys Conference. ACM, p 30"",""Baker J, Bond C, Corbett JC, Furman JJ, Khorlin A, Larson J, Leon J-M, Li Y, Lloyd A, Yushprakh V (2011) Megastore: Providing scalable, highly available storage for interactive services. In: Proceedings of the Conference on Innovative Data system Research (CIDR), pp 223–234"",""Behl J, Distler T, Kapitza R (2017) Hybrids on steroids: SGX-based high performance BFT. In: Proceedings of the Twelfth European Conference on Computer Systems, pp 222–237. ACM"",""Ben-Or M (1983) Another advantage of free choice (extended abstract): Completely asynchronous agreement protocols. In: Proceedings of the second annual ACM symposium on principles of distributed computing. ACM, pp 27–30"",""Bracha G (1984) An asynchronous [(n-1)/3]-resilient consensus protocol. In: Proceedings of the third annual ACM symposium on Principles of distributed computing. ACM, pp 154–162"",""Buchman E (2016) Tendermint: Byzantine fault tolerance in the age of blockchains. Ph.D. thesis"",""Burrows M (2006) The chubby lock service for loosely-coupled distributed systems. In: Proceedings of the 7th symposium on operating systems design and implementation. USENIX Association, pp 335–350"",""citation_journal_title=J Cryptol; citation_title=Random oracles in constantinople: practical asynchronous byzantine agreement using cryptography; citation_author=C Cachin, K Kursawe, V Shoup; citation_volume=18; citation_issue=3; citation_publication_date=2005; citation_pages=219-246; citation_doi=10.1007/s00145-005-0318-0; citation_id=CR10"",""citation_journal_title=OSDI; citation_title=Practical Byzantine fault tolerance; citation_author=M Castro, B Liskov; citation_volume=99; citation_publication_date=1999; citation_pages=173-186; citation_id=CR11"",""citation_journal_title=ACM SIGOPS Oper Syst Rev; citation_title=Attested append-only memory: making adversaries stick to their word; citation_author=B-G Chun, P Maniatis, S Shenker, J Kubiatowicz; citation_volume=41; citation_publication_date=2007; citation_pages=189-204; citation_doi=10.1145/1323293.1294280; citation_id=CR12"",""citation_journal_title=ACM Trans Computer Syst (TOCS); citation_title=Spanner: Google’s globally distributed database; citation_author=JC Corbett, J Dean, M Epstein, A Fikes, C Frost, JJ Furman, S Ghemawat, A Gubarev, C Heiser, P Hochschild; citation_volume=31; citation_issue=3; citation_publication_date=2013; citation_pages=8; citation_doi=10.1145/2518037.2491245; citation_id=CR13"",""citation_journal_title=Distrib Comput; citation_title=Low complexity Byzantine-resilient consensus; citation_author=M Correia, N Ferreira Neves, LC Lung, P Veríssimo; citation_volume=17; citation_issue=3; citation_publication_date=2005; citation_pages=237-249; citation_doi=10.1007/s00446-004-0110-7; citation_id=CR14"",""Cowling J, Myers D, Liskov B, Rodrigues R, Shrira L (2006) HQ replication: a hybrid quorum protocol for Byzantine fault tolerance. In: Proceedings of the 7th symposium on Operating systems design and implementation. USENIX Association, pp 177–190"",""citation_journal_title=IEEE Trans Dependable Secure Comput; citation_title=hbft:speculative byzantine fault tolerance with minimum cost; citation_author=S Duan, S Peisert, KN Levitt; citation_volume=12; citation_issue=1; citation_publication_date=2014; citation_pages=58-70; citation_doi=10.1109/TDSC.2014.2312331; citation_id=CR16"",""citation_journal_title=J ACM (JACM); citation_title=Consensus in the presence of partial synchrony; citation_author=C Dwork, N Lynch, L Stockmeyer; citation_volume=35; citation_issue=2; citation_publication_date=1988; citation_pages=288-323; citation_doi=10.1145/42282.42283; citation_id=CR17"",""Ethereum Foundation. Go ethreum (2018).  https://github.com/ethereum/go-ethereum  . Accessed 15 Oct 2018"",""citation_journal_title=J ACM (JACM); citation_title=Impossibility of distributed consensus with one faulty process; citation_author=MJ Fischer, NA Lynch, MS Paterson; citation_volume=32; citation_issue=2; citation_publication_date=1985; citation_pages=374-382; citation_doi=10.1145/3149.214121; citation_id=CR19"",""Hunt P, Konar M, Junqueira FP, Reed B (2010) Zookeeper: Wait-free coordination for internet-scale systems. In USENIX Annual Technical Conference, vol 8. Boston, MA, USA, p 9"",""citation_journal_title=Int J Inf Secur; citation_title=The elliptic curve digital signature algorithm (ECDSA); citation_author=D Johnson, A Menezes, S Vanstone; citation_volume=1; citation_issue=1; citation_publication_date=2001; citation_pages=36-63; citation_doi=10.1007/s102070100002; citation_id=CR21"",""citation_journal_title=ACM SIGOPS Oper Syst Rev; citation_title=Zyzzyva: speculative Byzantine fault tolerance; citation_author=R Kotla, L Alvisi, M Dahlin, A Clement, E Wong; citation_volume=41; citation_publication_date=2007; citation_pages=45-58; citation_doi=10.1145/1323293.1294267; citation_id=CR22"",""citation_journal_title=ACM Trans Comput Syst (TOCS); citation_title=The part-time parliament; citation_author=L Lamport; citation_volume=16; citation_issue=2; citation_publication_date=1998; citation_pages=133-169; citation_doi=10.1145/279227.279229; citation_id=CR23"",""citation_journal_title=ACM Sigact News; citation_title=Paxos made simple; citation_author=L Lamport; citation_volume=32; citation_issue=4; citation_publication_date=2001; citation_pages=18-25; citation_id=CR24"",""citation_journal_title=ACM Trans Program Lang Syst (TOPLAS); citation_title=The Byzantine generals problem; citation_author=L Lamport, R Shostak, M Pease; citation_volume=4; citation_issue=3; citation_publication_date=1982; citation_pages=382-401; citation_doi=10.1145/357172.357176; citation_id=CR25"",""citation_journal_title=NSDI; citation_title=TrInc: Small trusted hardware for large distributed systems; citation_author=D Levin, JR Douceur, JR Lorch, T Moscibroda; citation_volume=9; citation_publication_date=2009; citation_pages=1-14; citation_id=CR26"",""citation_journal_title=Distrib Comput; citation_title=Byzantine quorum systems; citation_author=D Malkhi, M Reiter; citation_volume=11; citation_issue=4; citation_publication_date=1998; citation_pages=203-213; citation_doi=10.1007/s004460050050; citation_id=CR27"",""Mao Y, Junqueira FP, Marzullo K (2008) Mencius: building efficient replicated state machines for WANs. In: Proceedings of OSDI’08, USENIX Conference on Operating Systems Design and Implementation, USENIX, pp 369–384"",""Miller A, Xia Y, Croman K, Shi E, Song D (2016) The honey badger of BFT protocols. In: Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security. ACM, pp 31–42"",""Nakamoto S (2008) Bitcoin: a peer-to-peer electronic cash system. Technical report"",""Oki BM, Liskov BH (1988) Viewstamped replication: a new primary copy method to support highly-available distributed systems. In: Proceedings of the seventh annual ACM symposium on principles of distributed computing. ACM, pp 8–17"",""Ongaro D, Ousterhout JK (2014) In search of an understandable consensus algorithm. In: USENIX Annual Technical Conference, pp 305–319"",""Rabin MO (1983) Randomized Byzantine generals. In: 24th annual symposium on foundations of computer science (SFCS 1983). IEEE, pp 403–409"",""citation_journal_title=ACM Comput Surv (CSUR); citation_title=Implementing fault-tolerant services using the state machine approach: a tutorial; citation_author=FB Schneider; citation_volume=22; citation_issue=4; citation_publication_date=1990; citation_pages=299-319; citation_doi=10.1145/98163.98167; citation_id=CR34"",""citation_journal_title=Commun ACM; citation_title=How to share a secret; citation_author=A Shamir; citation_volume=22; citation_issue=11; citation_publication_date=1979; citation_pages=612-613; citation_doi=10.1145/359168.359176; citation_id=CR35"",""Shoup V (2000) Practical threshold signatures. In: Advances in cryptology—EUROCRYPT 2000. Springer, pp 207–220"",""citation_journal_title=IEEE Commun Surv Tutor; citation_title=Bitcoin and beyond: a technical survey on decentralized digital currencies; citation_author=F Tschorsch, B Scheuermann; citation_volume=18; citation_issue=3; citation_publication_date=2016; citation_pages=2084-2123; citation_doi=10.1109/COMST.2016.2535718; citation_id=CR37"",""citation_journal_title=Commun ACM; citation_title=Blockchain beyond bitcoin; citation_author=S Underwood; citation_volume=59; citation_issue=11; citation_publication_date=2016; citation_pages=15-17; citation_doi=10.1145/2994581; citation_id=CR38"",""Veronese GS, Correia M, Bessani AN, Lung LC 2009) Spin one’s wheels? byzantine fault tolerance with a spinning primary. In: 2009 28th IEEE International Symposium on Reliable Distributed Systems. IEEE, pp 135–144"",""Veronese GS, Correia M, Bessani AN, Lung LC (2010) EBAWA: efficient byzantine agreement for wide-area networks. In: 2010 IEEE 12th international symposium on high assurance systems engineering. IEEE, pp 10–19"",""citation_journal_title=IEEE Trans Comput; citation_title=Efficient byzantine fault-tolerance; citation_author=GS Veronese, M Correia, AN Bessani, LC Lung, P Verissimo; citation_volume=62; citation_issue=1; citation_publication_date=2013; citation_pages=16-30; citation_doi=10.1109/TC.2011.221; citation_id=CR41"",""Vukolić M (2015) The quest for scalable blockchain fabric: Proof-of-work vs. BFT replication. In: International Workshop on Open Problems in Network Security. Springer, pp 112–125"",""Vukolić M (2017) Rethinking permissioned blockchains. In: Proceedings of the ACM Workshop on Blockchain, Cryptocurrencies and Contracts. ACM, pp 3–7"",""Wood G (2014) ETHEREUM: a secure decentralised generalised transaction ledger, Technical Report.  http://gavwood.com/Paper.pdf   "",""citation_journal_title=ACM SIGOPS Oper Syst Rev; citation_title=Separating agreement from execution for byzantine fault tolerant services; citation_author=J Yin, J-P Martin, A Venkataramani, L Alvisi, M Dahlin; citation_volume=37; citation_issue=5; citation_publication_date=2003; citation_pages=253-267; citation_doi=10.1145/1165389.945470; citation_id=CR45""
""citation_journal_title"",""The Journal of Supercomputing""
""language"",""en""
""citation_cover_date"",""2019/11/01""
""og:description"",""Emerging blockchain technology has introduced a new challenge to the distributed system research: Can Byzantine fault-tolerance protocols scale up to, for example, hundreds of nodes? In this work, we introduce HiBFT, a hierarchical Byzantine fault-tolerance protocol to address the problem. The core idea is to divide replicas into groups and exchange consensus messages among groups, thus avoiding the necessity of message broadcasting. The motivation for such approach bases on the hierarchical property of network architecture in permissioned block chains, our target deployments. HiBFT works very much in the same way as the classical Practical Byzantine Fault-Tolerance protocol. However, it replaces the concept of physical replica with a logical one that represents a replica group. As such, protocol message complexity can be reduced from $$O(N^2)$$ O(N2) to $$O(s^2)$$ O(s2) where N and s are the total number of replicas and the number of groups. Additionally, using threshold signature scheme for representing a logical group results in two important improvements: The cost of signature verification is significantly reduced at each replica; blocks can be secured more effectively in terms of signature size. Our protocol guarantees safety and liveness under partially synchronous assumption with a correctness proof. Our experiment results show that the protocol can scale up to hundred of nodes.""
""prism.issn"",""1573-0484""
""citation_author_email"",""tqtung@gmail.com"",""hektor@etri.re.kr"",""twyoo@etri.re.kr"",""hkyoo@etri.re.kr"",""jiyoung@etri.re.kr"",""kimsunme@etri.re.kr""
""twitter:image:alt"",""Content cover image""
""prism.number"",""11""
""citation_issn"",""1573-0484""
""citation_language"",""en""
""dc:title"",""Hierarchical Byzantine fault-tolerance protocol for permissioned blockchain systems | SpringerLink""
""Content-Encoding"",""UTF-8""
""citation_pdf_url"",""https://link.springer.com/content/pdf/10.1007/s11227-019-02939-x.pdf""
""citation_lastpage"",""7365""
""DOI"",""10.1007/s11227-019-02939-x""
""citation_journal_abbrev"",""J Supercomput""
""prism.rightsAgent"",""journalpermissions@springernature.com""
""citation_author"",""Quang Tung Thai"",""Jong-Chul Yim"",""Tae-Whan Yoo"",""Hyun-Kyung Yoo"",""Ji-Young Kwak"",""Sun-Me Kim""
""resourceName"",""casa""
""dc.date"",""2019-06-29""
""citation_springer_api_url"",""http://api.springer.com/metadata/pam?q=doi:10.1007/s11227-019-02939-x&api_key=""
""citation_issue"",""11""
""prism.volume"",""75""
""prism.publicationName"",""The Journal of Supercomputing""
""citation_doi"",""10.1007/s11227-019-02939-x""
""dc.title"",""Hierarchical Byzantine fault-tolerance protocol for permissioned blockchain systems""
""prism.url"",""https://link.springer.com/article/10.1007/s11227-019-02939-x""
""citation_volume"",""75""
""dc.language"",""En""
""Content-Language"",""en""
""format-detection"",""telephone=no""
""citation_publication_date"",""2019/11""
""prism.endingPage"",""7365""
""citation_title"",""Hierarchical Byzantine fault-tolerance protocol for permissioned blockchain systems""
""citation_author_institution"",""Electronics and Telecommunications Research Institute, Daejeon, South Korea"",""Electronics and Telecommunications Research Institute, Daejeon, South Korea"",""Electronics and Telecommunications Research Institute, Daejeon, South Korea"",""Electronics and Telecommunications Research Institute, Daejeon, South Korea"",""Electronics and Telecommunications Research Institute, Daejeon, South Korea"",""Electronics and Telecommunications Research Institute, Daejeon, South Korea""
""access"",""No""
""citation_publisher"",""Springer US""
""applicable-device"",""pc,mobile""
""dc.format"",""text/html""
""description"",""Emerging blockchain technology has introduced a new challenge to the distributed system research: Can Byzantine fault-tolerance protocols scale up to, for ""
""title"",""Hierarchical Byzantine fault-tolerance protocol for permissioned blockchain systems | SpringerLink""
""citation_online_date"",""2019/06/29""
""twitter:site"",""@SpringerLink""
""dc.source"",""The Journal of Supercomputing 2019 75:11""
""dc.type"",""OriginalPaper""
""dc.copyright"",""2019 Springer Science+Business Media, LLC, part of Springer Nature""
""dc.creator"",""Quang Tung Thai"",""Jong-Chul Yim"",""Tae-Whan Yoo"",""Hyun-Kyung Yoo"",""Ji-Young Kwak"",""Sun-Me Kim""
""citation_fulltext_html_url"",""https://link.springer.com/article/10.1007/s11227-019-02939-x""
""prism.publicationDate"",""2019-06-29""
""Content-Type"",""text/html; charset=UTF-8""
""journal_id"",""11227""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""dc.description"",""Emerging blockchain technology has introduced a new challenge to the distributed system research: Can Byzantine fault-tolerance protocols scale up to, for example, hundreds of nodes? In this work, we introduce HiBFT, a hierarchical Byzantine fault-tolerance protocol to address the problem. The core idea is to divide replicas into groups and exchange consensus messages among groups, thus avoiding the necessity of message broadcasting. The motivation for such approach bases on the hierarchical property of network architecture in permissioned block chains, our target deployments. HiBFT works very much in the same way as the classical Practical Byzantine Fault-Tolerance protocol. However, it replaces the concept of physical replica with a logical one that represents a replica group. As such, protocol message complexity can be reduced from $$O(N^2)$$ to $$O(s^2)$$ where N and s are the total number of replicas and the number of groups. Additionally, using threshold signature scheme for representing a logical group results in two important improvements: The cost of signature verification is significantly reduced at each replica; blocks can be secured more effectively in terms of signature size. Our protocol guarantees safety and liveness under partially synchronous assumption with a correctness proof. Our experiment results show that the protocol can scale up to hundred of nodes.""
""og:type"",""article""
""citation_article_type"",""Article""
""og:title"",""Hierarchical Byzantine fault-tolerance protocol for permissioned blockchain systems""
""prism.doi"",""doi:10.1007/s11227-019-02939-x""
""X-UA-Compatible"",""IE=edge""
""citation_firstpage"",""7337""
""prism.startingPage"",""7337""
""viewport"",""width=device-width, initial-scale=1""
""dc.rightsAgent"",""journalpermissions@springernature.com""
""prism.section"",""OriginalPaper""
""dc.identifier"",""doi:10.1007/s11227-019-02939-x""
""dc.subject"",""Programming Languages, Compilers, Interpreters"",""Processor Architectures"",""Computer Science, general""
""og:url"",""https://link.springer.com/article/10.1007/s11227-019-02939-x""
""prism.copyright"",""2019 Springer Science+Business Media, LLC, part of Springer Nature""
";https://scholar.google.com/scholar?start=370&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
;;;;;Kingdom of the Netherlands;;;;;;;;
1619093469-256;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;(In) Stability for the Blockchain: Deleveraging Spirals and Stablecoin Attacks;A Klages;Mundt, A Minca  arXiv preprint arXiv:1906.02152, 2019  arxiv.org;;"… We further remark on oracle/governance manipulation in Section 6 … Most crypto-fiat pairs are

through Bitcoin or Ether, which act as a gateway to other cryptoassets … moving assets between

a number of exchanges and can take considerable time to confirm on the blockchain …";Cité 7 fois;Les 5 versions;[PDF] arxiv.org;https://arxiv.org/pdf/1906.02152;;"""date"",""2021-03-03T02:28:23Z""
""pdf:PDFVersion"",""1.5""
""xmp:CreatorTool"",""LaTeX with acmart 2020/11/15 v1.75 Typesetting articles for the Association for Computing Machinery and hyperref 2020-05-15 v7.00e Hypertext links for LaTeX""
""pdf:docinfo:title"",""(In)Stability for the Blockchain: Deleveraging Spirals and Stablecoin Attacks""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with acmart 2020/11/15 v1.75 Typesetting articles for the Association for Computing Machinery and hyperref 2020-05-15 v7.00e Hypertext links for LaTeX""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""(In)Stability for the Blockchain: Deleveraging Spirals and Stablecoin Attacks""
""xmp:CreateDate"",""2021-03-03T02:28:23Z""
""modified"",""2021-03-03T02:28:23Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""xmp:ModifyDate"",""2021-03-03T02:28:23Z""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.21 (TeX Live 2020) kpathsea version 6.3.2""
""meta:author"",""Ariah Klages-Mundt"",""Andreea Minca""
""trapped"",""False""
""meta:creation-date"",""2021-03-03T02:28:23Z""
""created"",""2021-03-03T02:28:23Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2021-03-03T02:28:23Z""
""resourceName"",""1906.02152""
""Author"",""Ariah Klages-Mundt"",""Andreea Minca""
""producer"",""pdfTeX, Version 3.14159265-2.6-1.40.21 (TeX Live 2020) kpathsea version 6.3.2""
""pdf:docinfo:producer"",""pdfTeX, Version 3.14159265-2.6-1.40.21 (TeX Live 2020) kpathsea version 6.3.2""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""7"",""2"",""25"",""14"",""5"",""5"",""0"",""2"",""19"",""0"",""1"",""3"",""2"",""7"",""0"",""0"",""0"",""0"",""5"",""6"",""17"",""32"",""12""
""access_permission:modify_annotations"",""true""
""dc:creator"",""Ariah Klages-Mundt"",""Andreea Minca""
""dcterms:created"",""2021-03-03T02:28:23Z""
""Last-Modified"",""2021-03-03T02:28:23Z""
""dcterms:modified"",""2021-03-03T02:28:23Z""
""title"",""(In)Stability for the Blockchain: Deleveraging Spirals and Stablecoin Attacks""
""xmpMM:DocumentID"",""uuid:b133ef7a-39b6-47fd-9820-aea8d7595f7a""
""Last-Save-Date"",""2021-03-03T02:28:23Z""
""pdf:docinfo:modified"",""2021-03-03T02:28:23Z""
""meta:save-date"",""2021-03-03T02:28:23Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.21 (TeX Live 2020) kpathsea version 6.3.2""
""Content-Length"",""1644222""
""Content-Type"",""application/pdf""
""xmp:MetadataDate"",""2021-03-03T02:28:23Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Ariah Klages-Mundt"",""Andreea Minca""
""dc:language"",""en""
""pdf:producer"",""pdfTeX, Version 3.14159265-2.6-1.40.21 (TeX Live 2020) kpathsea version 6.3.2""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""30""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""3347"",""3299"",""3139"",""2926"",""3739"",""3053"",""2873"",""2246"",""3313"",""2788"",""2330"",""1671"",""2823"",""2979"",""1192"",""2470"",""2830"",""2894"",""2265"",""1723"",""2691"",""3408"",""3526"",""3452"",""3326"",""3527"",""1881"",""1188"",""1076"",""495""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2021-03-03T02:28:23Z""
";https://scholar.google.com/scholar?start=90&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093541-570;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;"?????????? ?????????? ?????????????? ?????????? ? ????????? ????? ? ????????-???????"" ??????"" ??????? ????? (? ?????????????? ???????????? ? …";?? ???????, ?? ???????? ; ????????? ? ??????????: ???????? …, 2019  elibrary.ru;;"… BLOCKCHAIN SYSTEM OF THE SECOND STAGE (USING CRYPTOCURRENCY AND SMART …

The article examines the possibility of reducing vulnerabilities blockchain project ""Diamonds""

of the … direction of ""intellectualization"" of network nodes and oracles, the implementation …";Cité 1 fois;;null;;;;https://scholar.google.com/scholar?start=400&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093457-210;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Blockchain abstract data type: poster;E Anceaume, AD Pozzo, R Ludinard… ; Proceedings of the 24th …, 2019  dl.acm.org;;"… Future work will focus on several open issues, such as the solvability of Even- tual Prefix

in message-passing, the synchronization power of other oracle models, and fairness

properties for oracles … 2017. The Blockchain Consensus Layer and BFT …";Autres articles;;[PDF] acm.org;https://dl.acm.org/doi/pdf/10.1145/3293883.3303705?casa_token=m6iUBZ9GScgAAAAA:smW-WmbTCjt6bzw0CBevwCKrw0kYYywgcTFKH_Cl0Z4dJrRpVOkwxzM1I8h_dyDMrUXePyxwqTI;;;https://scholar.google.com/scholar?start=40&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093497-373;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;[PDF][PDF] Augur: a Decentralized Oracle and Prediction Market Platform (v2. 0);J Peterson, J Krug, M Zoltu, AK Williams… ; … , https://augur. net …, 2019  coinpare.io;;"… The Augur oracle al- lows information to be migrated from the real world to a blockchain without

relying on a trusted intermediary … 19This is true of all public oracles, even centralized ones. 3.

Minimum Cost of a Successful Attack Next, consider the cost of attacking the oracle …";Cité 7 fois;Les 7 versions;[PDF] coinpare.io;https://coinpare.io/whitepaper/augur.pdf;;"""date"",""2020-04-22T08:21:35Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2020-04-22T08:21:35Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.19 (TeX Live 2018) kpathsea version 6.3.0""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2019-11-01T21:56:03Z""
""created"",""2019-11-01T21:56:03Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-11-01T21:56:03Z""
""resourceName"",""augur.pdf""
""Author"",""""
""producer"",""www.ilovepdf.com""
""pdf:docinfo:producer"",""www.ilovepdf.com""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""3"",""4"",""0"",""0"",""0"",""6"",""0"",""5"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2019-11-01T21:56:03Z""
""Last-Modified"",""2020-04-22T08:21:35Z""
""dcterms:modified"",""2020-04-22T08:21:35Z""
""title"",""""
""Last-Save-Date"",""2020-04-22T08:21:35Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2020-04-22T08:21:35Z""
""meta:save-date"",""2020-04-22T08:21:35Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.19 (TeX Live 2018) kpathsea version 6.3.0""
""Content-Length"",""211342""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""16""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""4583"",""4157"",""3318"",""1359"",""4621"",""4557"",""4085"",""4061"",""3951"",""4294"",""4044"",""832"",""4040"",""3082"",""3292"",""545""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-11-01T21:56:03Z""
";https://scholar.google.com/scholar?start=210&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093520-475;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;[PDF][PDF] Wombat: one more Bleichenbacher attack toolkit;AT Rasoamanana, O Levillain ;2019 pdfs.semanticscholar.org;;"… However, some oracles also make additional checks ? the padding contains at least 8 bytes ?

the … The article, published at CRYPTO 2012, improved the original algorithms (CRYPTO 1998)

Oracle Average nb of requests type Original algo Improved algo FFF - 18 040 221 FFT …";Autres articles;;[PDF] semanticscholar.org;https://pdfs.semanticscholar.org/ac0b/264546ed296476d72edfc12d314dac6fb72d.pdf;;"""date"",""2019-11-14T19:16:20Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""Wombat: one more Bleichenbacher attack toolkit""
""xmp:CreatorTool"",""LaTeX with Beamer class""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with Beamer class""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""Wombat: one more Bleichenbacher attack toolkit""
""modified"",""2019-11-14T19:16:20Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""Olivier Levillain, Aina Toky Rasoamanana""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.19 (TeX Live 2019/dev/Debian) kpathsea version 6.3.1/dev""
""meta:author"",""Olivier Levillain, Aina Toky Rasoamanana""
""trapped"",""False""
""meta:creation-date"",""2019-11-14T19:16:20Z""
""created"",""2019-11-14T19:16:20Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-11-14T19:16:20Z""
""resourceName"",""264546ed296476d72edfc12d314dac6fb72d.pdf""
""Author"",""Olivier Levillain, Aina Toky Rasoamanana""
""producer"",""pdfTeX-1.40.19""
""pdf:docinfo:producer"",""pdfTeX-1.40.19""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""8"",""8"",""8"",""2"",""2"",""6"",""0"",""4"",""4"",""8"",""8"",""3"",""3"",""3"",""3"",""0"",""0"",""7"",""7"",""7"",""7"",""6"",""6"",""0"",""0"",""0"",""0"",""6"",""0"",""0"",""0"",""0"",""0"",""5"",""5"",""5"",""3"",""3"",""3"",""7"",""7"",""7"",""0"",""7"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""Olivier Levillain, Aina Toky Rasoamanana""
""dcterms:created"",""2019-11-14T19:16:20Z""
""Last-Modified"",""2019-11-14T19:16:20Z""
""dcterms:modified"",""2019-11-14T19:16:20Z""
""title"",""Wombat: one more Bleichenbacher attack toolkit""
""Last-Save-Date"",""2019-11-14T19:16:20Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2019-11-14T19:16:20Z""
""meta:save-date"",""2019-11-14T19:16:20Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.19 (TeX Live 2019/dev/Debian) kpathsea version 6.3.1/dev""
""Content-Length"",""301646""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Olivier Levillain, Aina Toky Rasoamanana""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""48""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""147"",""173"",""200"",""287"",""287"",""287"",""424"",""424"",""399"",""212"",""392"",""392"",""487"",""487"",""396"",""396"",""403"",""403"",""285"",""209"",""418"",""418"",""530"",""530"",""350"",""350"",""201"",""220"",""220"",""220"",""466"",""407"",""407"",""386"",""386"",""386"",""499"",""499"",""499"",""162"",""162"",""170"",""449"",""449"",""449"",""184"",""351"",""102""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-11-14T19:16:20Z""
";https://scholar.google.com/scholar?start=310&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093462-229;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;[HTML][HTML] Survey on blockchain for Internet of Things;X Wang, X Zha, W Ni, RP Liu, YJ Guo, X Niu… ; Computer …, 2019  Elsevier;;"… Survey on blockchain for Internet of Things … Blockchain, a distributed and

tamper-resistant ledger, maintains consistent records of data at different locations,

and has the potential to address the data security concern in IoT networks …";Cité 169 fois;Les 4 versions;[HTML] sciencedirect.com;https://www.sciencedirect.com/science/article/pii/S0140366418306881?casa_token=w6SxfV7CQf0AAAAA:slaB0v2I6Pg-PwdDzV2hRbfFOirXIhC5XY9c-QeJsc_F1H_72OWojJVGuLSJu60K6VcXFdEr;;;https://scholar.google.com/scholar?start=60&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093523-488;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Blockchain-based system for multiparty electronic registered delivery services;MM Payeras;Capellŕ, M MutPuigserver…  IEEE …, 2019  ieeexplore.ieee.org;;"… payment. In [14], Hasan et al. propose a non- repudiation protocol using the

blockchain technology and the Ethereum smart contracts. This solution is applied

to a trade exchange between crypto-tokens and digital assets. The …";Cité 6 fois;Les 2 versions;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/6287639/8600701/08764454.pdf;;"""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""dc:title"",""IEEE Xplore Full-Text PDF:""
""Content-Encoding"",""UTF-8""
""resourceName"",""08764454.pdf""
""language"",""es""
""Content-Length"",""2565""
""title"",""IEEE Xplore Full-Text PDF:""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=320&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093457-207;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;[PDF][PDF] Blockchain: l'exemple des smart contracts Entre innovation et précaution;M Mekki ;2019 mustaphamekki.openum.ca;;"… établi, information interne ŕ la blockchain ou extérieure et dans ce cas entrée par un Oracle,

ce qui … Imaginons sur une blockchain un ensemble d'œuvres musicales enregistrées … 10 secondes,

une minute ou la totalité de la chanson…) avec un paiement en crypto-monnaie ou …";Cité 4 fois;Les 4 versions;[PDF] openum.ca;https://mustaphamekki.openum.ca/files/sites/37/2018/05/Smart-contracts-6.pdf;;"""date"",""2018-05-17T05:49:10Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.3""
""pdf:docinfo:title"",""Microsoft Word - Smart contracts.docx""
""xmp:CreatorTool"",""Word""
""Keywords"",""""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""dcterms:created"",""2018-05-17T05:49:10Z""
""language"",""fr""
""Last-Modified"",""2018-05-17T05:49:10Z""
""dcterms:modified"",""2018-05-17T05:49:10Z""
""dc:format"",""application/pdf; version=1.3""
""title"",""Microsoft Word - Smart contracts.docx""
""Last-Save-Date"",""2018-05-17T05:49:10Z""
""pdf:docinfo:creator_tool"",""Word""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2018-05-17T05:49:10Z""
""meta:save-date"",""2018-05-17T05:49:10Z""
""pdf:encrypted"",""false""
""dc:title"",""Microsoft Word - Smart contracts.docx""
""modified"",""2018-05-17T05:49:10Z""
""Content-Length"",""298121""
""pdf:hasMarkedContent"",""false""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""dc:subject"",""""
""meta:creation-date"",""2018-05-17T05:49:10Z""
""created"",""2018-05-17T05:49:10Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""18""
""Creation-Date"",""2018-05-17T05:49:10Z""
""resourceName"",""Smart-contracts-6.pdf""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""4623"",""4485"",""4006"",""4388"",""3478"",""4271"",""4261"",""4136"",""3860"",""4113"",""4055"",""4003"",""4088"",""3688"",""3983"",""4348"",""4356"",""463""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""meta:keyword"",""""
""producer"",""Mac OS X 10.9.5 Quartz PDFContext""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""Mac OS X 10.9.5 Quartz PDFContext""
""pdf:docinfo:created"",""2018-05-17T05:49:10Z""
";https://scholar.google.com/scholar?start=40&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093534-537;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Logical methods for smart contract development;AG Galieva, DE Palchunov ; 2019 International Multi …, 2019  ieeexplore.ieee.org;;"… 22]; 4. Estimated knowledge – probabilistic, fuzzy knowledge, taken from external sources

(supplied by oracles) or generated … construction of an adequate structure of the blockchain – a

network of nodes with … to which the occurrence of a certain event causes an oracle or triggers …";Cité 5 fois;Les 3 versions;null;;;;https://scholar.google.com/scholar?start=370&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093518-465;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;RLWE Commitment-Based Linkable Ring Signature Scheme and Its Application in Blockchain;Q Ye, W Wang, Y Tang, X Yan, J Zhang, Z Zhao… ; … on Blockchain and …, 2019  Springer;;"… of the proposed scheme is simpler; (3) Combine the proposed LRS scheme with blockchain to

give … the definitions of unforgeability, anonymity and linkability, we consider the following oracles

which simulate … ( (vk_{i} ,sk_{i} ) \leftarrow KO(pp,r_{i} ) \). The KeyGen Oracle, on the …";Autres articles;;null;;;;https://scholar.google.com/scholar?start=300&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093448-163;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;An IoT blockchain architecture using oracles and smart contracts: The use-case of a food supply chain;H Moudoud, S Cherkaoui… ; 2019 IEEE 30th Annual …, 2019  ieeexplore.ieee.org;;"The blockchain is a distributed technology which allows establishing trust among unreliable 
users who interact and perform transactions with each other. While blockchain technology 
has been mainly used for crypto-currency, it has emerged as an enabling technology for …";Cité 8 fois;Les 4 versions;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/8894566/8903626/08904404.pdf?casa_token=NQ45VQvRY9IAAAAA:TkRn6s0fquHwrQOTynZ3V_7WdOerbiZw9sSlm_fbNhq2PXITJ6BQ5OhIjjcWcvCqtEVz40AoOM8;;"""og:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""twitter:title"",""An IoT Blockchain Architecture Using Oracles and Smart Contracts: the Use-Case of a Food Supply Chain""
""twitter:card"",""summary""
""Description"",""The blockchain is a distributed technology which allows establishing trust among unreliable users who interact and perform transactions with each other. While b""
""og:title"",""An IoT Blockchain Architecture Using Oracles and Smart Contracts: the Use-Case of a Food Supply Chain""
""resourceName"",""08904404.pdf""
""language"",""en""
""title"",""An IoT Blockchain Architecture Using Oracles and Smart Contracts: the Use-Case of a Food Supply Chain | IEEE Conference Publication | IEEE Xplore""
""og:description"",""The blockchain is a distributed technology which allows establishing trust among unreliable users who interact and perform transactions with each other. While blockchain technology has been mainly used for crypto-currency, it has emerged as an enabling technology for establishing trust in the realm of the Internet of Things (IoT). Nevertheless, a naive usage of the blockchain for IoT leads to high delays and extensive computational power. In this paper, we propose a blockchain architecture dedicated to being used in a supply chain which comprises different distributed IoT entities. We propose a lightweight consensus for this architecture, called LC4IoT. The consensus is evaluated through extensive simulations. The results show that the proposed consensus uses low computational power, storage capability and latency.""
""twitter:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-UA-Compatible"",""IE=Edge""
""viewport"",""width=device-width, initial-scale=1.0""
""dc:title"",""An IoT Blockchain Architecture Using Oracles and Smart Contracts: the Use-Case of a Food Supply Chain | IEEE Conference Publication | IEEE Xplore""
""twitter:description"",""The blockchain is a distributed technology which allows establishing trust among unreliable users who interact and perform transactions with each other. While blockchain technology has been mainly used for crypto-currency, it has emerged as an enabling technology for establishing trust in the realm of the Internet of Things (IoT). Nevertheless, a naive usage of the blockchain for IoT leads to high delays and extensive computational power. In this paper, we propose a blockchain architecture dedicated to being used in a supply chain which comprises different distributed IoT entities. We propose a lightweight consensus for this architecture, called LC4IoT. The consensus is evaluated through extensive simulations. The results show that the proposed consensus uses low computational power, storage capability and latency.""
""Content-Encoding"",""UTF-8""
""Content-Type-Hint"",""text/html; charset=utf-8""
""Content-Length"",""40543""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";
1619093509-423;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;An Empirical Analysis of Blockchain Cybersecurity Incidents;A Alkhalifah, A Ng, MJM Chowdhury… ; 2019 IEEE Asia …, 2019  ieeexplore.ieee.org;;"… Providers of external data feeds are called Oracles … Furthermore, the trustworthiness of an oracle

and source verification properties of the blockchain is difficult. VI … electronic cash system, (2008)

[7] Yaga, D., P. Mell, N. Roby, and K. Scarfone: Blockchain technology overview …";Cité 1 fois;Les 2 versions;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/9153550/9162346/09162381.pdf?casa_token=0gnaTdBbTtcAAAAA:0X27VDuHRSXzJ2zGsePHzaYCnYmauKJy8uFlEM0wocrseaG83I_kNi9Wzj2TI5f9x8aMXgofh9k;;"""og:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""twitter:title"",""An Empirical Analysis of Blockchain Cybersecurity Incidents""
""twitter:card"",""summary""
""Description"",""The establishment of Bitcoin in 2008 has introduced Blockchain technology to become the predominant new ways in digital transactions in many fields, such as ene""
""og:title"",""An Empirical Analysis of Blockchain Cybersecurity Incidents""
""resourceName"",""09162381.pdf""
""language"",""en""
""title"",""An Empirical Analysis of Blockchain Cybersecurity Incidents | IEEE Conference Publication | IEEE Xplore""
""og:description"",""The establishment of Bitcoin in 2008 has introduced Blockchain technology to become the predominant new ways in digital transactions in many fields, such as energy, healthcare, and financial services. Although blockchain technology promised many advantages, it has suffered from various attacks with significant financial loses. We analyse 65 cybersecurity incidents that have been happening on the blockchain networks between 2011 and the first half-year of 2019. We categorize those incidents against the key cybersecurity vulnerabilities in blockchain technology, which showed an upward trend of an increasing number of attacks which dues to lack of security controls in the digital currency exchange and vulnerability in smart contracts. This result of this research highlights the needs in a major overhaul of the blockchain technology.""
""twitter:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-UA-Compatible"",""IE=Edge""
""viewport"",""width=device-width, initial-scale=1.0""
""dc:title"",""An Empirical Analysis of Blockchain Cybersecurity Incidents | IEEE Conference Publication | IEEE Xplore""
""twitter:description"",""The establishment of Bitcoin in 2008 has introduced Blockchain technology to become the predominant new ways in digital transactions in many fields, such as energy, healthcare, and financial services. Although blockchain technology promised many advantages, it has suffered from various attacks with significant financial loses. We analyse 65 cybersecurity incidents that have been happening on the blockchain networks between 2011 and the first half-year of 2019. We categorize those incidents against the key cybersecurity vulnerabilities in blockchain technology, which showed an upward trend of an increasing number of attacks which dues to lack of security controls in the digital currency exchange and vulnerability in smart contracts. This result of this research highlights the needs in a major overhaul of the blockchain technology.""
""Content-Encoding"",""UTF-8""
""Content-Type-Hint"",""text/html; charset=utf-8""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=260&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093471-267;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Blockchain development platform comparison;V Clincy, H Shahriar ; 2019 IEEE 43rd Annual Computer …, 2019  ieeexplore.ieee.org;;"… COMPARISON Below we compare the platforms on a number of common features including

cryptocurrency support, type of permission, application areas, to name a few (see Table 1 … Retrieved

from https://medium.com/crypto- oracle/enterprise- blockchain-has-arrived …";Cité 5 fois;Les 3 versions;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/8746989/8753824/08754499.pdf?casa_token=4tqygIWDI3AAAAAA:wB2qCp8l9gIGQmhFRlO5RZIki36ZzynUCbpI1VORKGcuCJB4JlkBMVq3DTAYhkWLoIdoVqprI0U;;"""og:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""twitter:title"",""Blockchain Development Platform Comparison""
""twitter:card"",""summary""
""Description"",""One of the current challenges that faces individual organizations that are attempting to utilize blockchain in making more secure and transparent transaction be""
""og:title"",""Blockchain Development Platform Comparison""
""resourceName"",""08754499.pdf""
""language"",""en""
""title"",""Blockchain Development Platform Comparison | IEEE Conference Publication | IEEE Xplore""
""og:description"",""One of the current challenges that faces individual organizations that are attempting to utilize blockchain in making more secure and transparent transaction between organizations are standards. Not all platforms, however, are suitable. In this paper, we provide a comparison of blockchain development platforms for developers to choose the best platform based on their need.""
""twitter:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-UA-Compatible"",""IE=Edge""
""viewport"",""width=device-width, initial-scale=1.0""
""dc:title"",""Blockchain Development Platform Comparison | IEEE Conference Publication | IEEE Xplore""
""twitter:description"",""One of the current challenges that faces individual organizations that are attempting to utilize blockchain in making more secure and transparent transaction between organizations are standards. Not all platforms, however, are suitable. In this paper, we provide a comparison of blockchain development platforms for developers to choose the best platform based on their need.""
""Content-Encoding"",""UTF-8""
""Content-Type-Hint"",""text/html; charset=utf-8""
""Content-Length"",""38416""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=100&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093499-381;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;[PDF][PDF] Blockchain Technology: What Is It Good for? Industry's dreams and fears for this new technology;S Ruoti, B Kaiser, A Yerukhimovich, J Clark… ; Queue, 2019  dl.acm.org;;"… While such information can be provided by off-chain oracles, these are trusted entities

that are difficult to audit … 18 of 28 Page 19. acmqueue | september-october 2019

19 blockchain categories of cryptocurrency use is China …";Cité 3 fois;Les 5 versions;[PDF] acm.org;https://dl.acm.org/doi/pdf/10.1145/3371595.3376896;;;https://scholar.google.com/scholar?start=220&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093480-302;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Sok: Sharding on blockchain;G Wang, ZJ Shi, M Nixon, S Han ; … of the 1st ACM Conference on …, 2019  dl.acm.org;;"… They are typically maintained by independent parties without a central authority, for example,

in systems like SUNDR [95], SPORC [66], and Tamper-Evident Logging [53]. The blockchain

became popular because of its success in crypto-currencies, eg, Bitcoin [107] …";Cité 45 fois;Les 7 versions;[PDF] acm.org;https://dl.acm.org/doi/pdf/10.1145/3318041.3355457?casa_token=10yqnDxJWLoAAAAA:IRp710NiuI2JrUpPa1TdcIrsXENEmdBgXNe6d34Io7K9fWahB5nagMYr2fJSjrUk02DF3hMyqJ0;;;https://scholar.google.com/scholar?start=140&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093469-259;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;A Data Retailer Based Decentralized Oracle Design for Smart Contracts in Blockchain;??? ;2019 sspace.snu.ac.kr;;"Smart contracts, a program that enables the automated execution of terms from the pre-
defined condition establishment, became a core component of distributed applications 
(Dapps) leveraging the decentralized blockchain technology. Although many researchers …";Autres articles;Version HTML;[PDF] snu.ac.kr;https://s-space.snu.ac.kr/bitstream/10371/150787/1/000000155550.pdf;;;https://scholar.google.com/scholar?start=90&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093471-264;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;SoK: Blockchain technology and its potential use cases;S Ruoti, B Kaiser, A Yerukhimovich, J Clark… ; arXiv preprint arXiv …, 2019  arxiv.org;;"… the composition of these properties into a single system was a meaningful contribution [6] which

led the cryptocurrency to become … Nevertheless, there remains significant interest in the question

of whether the technology underlying Bitcoin—known as Blockchain technology or …";Cité 5 fois;Les 3 versions;[PDF] arxiv.org;https://arxiv.org/pdf/1909.12454;;"""date"",""2019-09-30T00:35:36Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""Title""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""Title""
""modified"",""2019-09-30T00:35:36Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""Anonymous""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016) kpathsea version 6.2.2""
""meta:author"",""Anonymous""
""trapped"",""False""
""meta:creation-date"",""2019-09-30T00:35:36Z""
""created"",""2019-09-30T00:35:36Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-09-30T00:35:36Z""
""resourceName"",""1909.12454""
""Author"",""Anonymous""
""producer"",""pdfTeX-1.40.17""
""pdf:docinfo:producer"",""pdfTeX-1.40.17""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""Anonymous""
""dcterms:created"",""2019-09-30T00:35:36Z""
""Last-Modified"",""2019-09-30T00:35:36Z""
""dcterms:modified"",""2019-09-30T00:35:36Z""
""title"",""Title""
""Last-Save-Date"",""2019-09-30T00:35:36Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2019-09-30T00:35:36Z""
""meta:save-date"",""2019-09-30T00:35:36Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016) kpathsea version 6.2.2""
""Content-Length"",""882719""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Anonymous""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""20""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""4326"",""4758"",""4569"",""4801"",""5078"",""3117"",""5136"",""2699"",""4876"",""4946"",""5157"",""4878"",""3003"",""3784"",""5064"",""4904"",""4420"",""5050"",""4488"",""875""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-09-30T00:35:36Z""
";https://scholar.google.com/scholar?start=100&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093504-406;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;CoRide: A Privacy-Preserving Collaborative-Ride Hailing Service Using Blockchain-Assisted Vehicular Fog Computing;M Li, L Zhu, X Lin ; International Conference on Security and Privacy in …, 2019  Springer;;"… indistinguishability experiment \(\textsf {L}\)-\textsf {IND}\), challenger \(\mathcal {C}\) samples

a random bit b, initializes two \(\Pi ^{DAP}\) oracles \(\mathcal {O … The stakeholders, ie, RSUs, must

be invited or permitted by SPs to join the blockchain network and create new blocks …";Cité 9 fois;;null;;;;https://scholar.google.com/scholar?start=240&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093485-326;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Who is Liable if a Cryptocurrency Protocol Fails?;P Řstbye ; Available at SSRN 3423681, 2019  papers.ssrn.com;;"… Such information can be provided by oracles, and the information provided by oracles must be

subject to incentive mechanisms … 48See Blockchain Luxemburg (2018 … a second native coin in

MakerDAO called MKR, which has a floating value similar to a traditional cryptocurrency …";Cité 7 fois;;null;;;;https://scholar.google.com/scholar?start=160&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093513-446;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Towards Blockchain Interoperability;M Borkowski ; … Forum: BPM 2019 Blockchain and CEE Forum …, 2019  books.google.com;;"… of the earliest contributions in the field of blockchain interoperability is the idea of a trustless

cryptocurrency exchange realized in … that the tokens were actually destroyed on the source block-

chain, or (b) the target blockchain relies on information provided by oracles [16], to …";Autres articles;;null;;;;https://scholar.google.com/scholar?start=280&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093490-349;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Leveraging blockchain for open mobility-as-a-service ecosystems;E Bothos, B Magoutas, K Arnaoutaki… ; IEEE/WIC/ACM …, 2019  dl.acm.org;;"… 2.1 Blockchain Blockchain technology gained visibility due to the advent of Bitcoin [5], a

cryptocurrency which has been created in order to carry value between members of a payment …

Oracles are data feeds that enable transactions on the blockchain including data …";Cité 4 fois;;[PDF] acm.org;https://dl.acm.org/doi/pdf/10.1145/3358695.3361844?casa_token=vF_IFHgQNXcAAAAA:i8o1rMyeSJUEfDZSxsNQDSxhDbiFtsKhHqwdHUWLRmzjSBfTr56bLlOew93zHm1gOWX-NSsJbCQ;;;https://scholar.google.com/scholar?start=180&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093450-172;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Proposing a blockchain-based open data platform and its decentralized oracle;A Fujihara ; International Conference on Intelligent Networking and …, 2019  Springer;;"Bitcoin has been attracted attention to issue digital currency and also to manage 
transactions in a decentralized and trustless way without assuming any reliable third-party 
organization. To enhance the potential of Bitcoin, blockchain technologies have been …";Cité 4 fois;;null;;;;https://scholar.google.com/scholar?start=10&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093546-584;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;[CITATION][C] Digital transformation: blockchain and land titles;G Eder ; Proceedings of the OECD Global AntiCorruption & …, 2019;;null;Cité 18 fois;;null;;;;https://scholar.google.com/scholar?start=420&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093476-281;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;[HTML][HTML] Blockchain technology: what is it good for?;S Ruoti, B Kaiser, A Yerukhimovich, J Clark… ; Communications of the …, 2019  dl.acm.org;;"… As with insurance and futures, oracles and counterparty risk are key challenges … a driver's license,

owns a specific cryptographic key), can be maintained on a blockchain system … Alternatively, the

data can be encrypted using advanced crypto- graphic techniques that allow miners …";Cité 14 fois;Les 3 versions;[HTML] acm.org;https://dl.acm.org/doi/fullHtml/10.1145/3369752?casa_token=m69gShHllBUAAAAA:NdSWhW5CuwhXIVCepEM8uZXNXO8_hvX7vZAVMMB39UmCa_yIz-ITXOj6qpP_xe-pRHxLHj6EJ1c;;;https://scholar.google.com/scholar?start=120&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093469-260;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Internet of things and blockchain integration: use cases and implementation challenges;KG Eze, CM Akujuobi, MNO Sadiku… ; … Conference on Business …, 2019  Springer;;"… Data from oracles should therefore be properly authenticated using appropriate methods …

http://www.oracle.com/us/solutions/cloud/tt-technologies-white-paper-4498079.pdf. 19. Cachin,

C., et al.: Blockchain … Kiktenko, EO, et al.: Quantum-secured blockchain. Quantum Sci …";Cité 3 fois;;null;;;;https://scholar.google.com/scholar?start=90&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093516-451;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;[PDF][PDF] Blockchain: A World Without Middlemen;J Maupin, J Kahlert, T Honsel ; … . Bonn. Available online at: www. giz. de …, 2019  dnb.info;;"… public registry have shown that blockchain is more than just the cryptocurrency Bitcoin … the majority

of DLT applications are still centered around speculative crypto-investments … The scope of

blockchain applications under consideration ranges from simple timestamping tools for …";Cité 4 fois;;[PDF] d-nb.info;https://d-nb.info/1192142756/34;;"""date"",""2019-04-01T10:50:01Z""
""pdf:PDFVersion"",""1.5""
""xmp:CreatorTool"",""Adobe InDesign CC 14.0 (Macintosh)""
""pdf:docinfo:title"",""Assessing development impacts: lessons from a case study in  Ghana""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""Assessing development impacts: lessons from a case study in  Ghana""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""Adobe InDesign CC 14.0 (Macintosh)""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""Assessing development impacts: lessons from a case study in  Ghana""
""xmp:CreateDate"",""2019-04-01T12:49:41Z""
""modified"",""2019-04-01T10:50:01Z""
""cp:subject"",""Assessing development impacts: lessons from a case study in  Ghana""
""pdf:docinfo:subject"",""Assessing development impacts: lessons from a case study in  Ghana""
""pdf:hasMarkedContent"",""false""
""xmp:ModifyDate"",""2019-04-01T12:50:01Z""
""pdf:docinfo:creator"",""GIZ""
""meta:author"",""GIZ"",""des Designs: Ira Olaleye""
""trapped"",""False""
""meta:creation-date"",""2019-04-01T10:49:41Z""
""created"",""2019-04-01T10:49:41Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-04-01T10:49:41Z""
""resourceName"",""34""
""xmpMM:DerivedFrom:DocumentID"",""xmp.did:0752967d-6a35-4562-80f3-1fc014470ade""
""Author"",""GIZ"",""des Designs: Ira Olaleye""
""producer"",""Adobe PDF Library 15.0""
""pdf:docinfo:producer"",""Adobe PDF Library 15.0""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""dc:description"",""Assessing development impacts: lessons from a case study in  Ghana""
""access_permission:modify_annotations"",""true""
""dc:creator"",""GIZ"",""des Designs: Ira Olaleye""
""description"",""Assessing development impacts: lessons from a case study in  Ghana""
""dcterms:created"",""2019-04-01T10:49:41Z""
""Last-Modified"",""2019-04-01T10:50:01Z""
""dcterms:modified"",""2019-04-01T10:50:01Z""
""title"",""Assessing development impacts: lessons from a case study in  Ghana""
""xmpMM:DocumentID"",""xmp.id:904ff311-932d-403c-9a40-5ef39605949e""
""Last-Save-Date"",""2019-04-01T10:50:01Z""
""pdf:docinfo:modified"",""2019-04-01T10:50:01Z""
""meta:save-date"",""2019-04-01T10:50:01Z""
""Content-Length"",""10226114""
""Content-Type"",""application/pdf""
""xmp:MetadataDate"",""2019-04-01T12:50:01Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""GIZ"",""des Designs: Ira Olaleye""
""dc:language"",""de-DE""
""pdf:producer"",""Adobe PDF Library 15.0""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""92""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""227"",""472"",""1256"",""1659"",""1549"",""2120"",""1726"",""1586"",""1308"",""27"",""1903"",""2554"",""381"",""2142"",""1190"",""40"",""1302"",""1937"",""2141"",""1571"",""2215"",""2285"",""2086"",""2087"",""2107"",""1986"",""2042"",""2082"",""504"",""70"",""1531"",""1866"",""1375"",""2676"",""2307"",""2293"",""1821"",""2492"",""1505"",""2648"",""2345"",""2354"",""2351"",""1981"",""1385"",""2429"",""2505"",""2365"",""2018"",""1968"",""1411"",""2438"",""2251"",""1686"",""1503"",""2375"",""2579"",""1659"",""70"",""78"",""921"",""2081"",""1613"",""2071"",""1751"",""2233"",""2169"",""1887"",""1995"",""2546"",""2267"",""2752"",""2655"",""1979"",""1663"",""1720"",""1961"",""2137"",""2307"",""701"",""78"",""28"",""1883"",""2228"",""1934"",""1825"",""297"",""23"",""1968"",""2650"",""596"",""298""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""xmpMM:DerivedFrom:InstanceID"",""xmp.iid:19ca7949-78a0-4c88-a8ed-5afb392deadb""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-04-01T10:49:41Z""
";https://scholar.google.com/scholar?start=290&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093476-282;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;[HTML][HTML] Exploring blockchain technology in international trade;SE Chang, YC Chen, TC Wu ; Industrial Management & Data Systems, 2019  emerald.com;;"… sharing and status update, alongside the freight tracking from shipper's database via oracle … Smart

contracts are programmed protocols deployed on blockchain platform (ie Ethereum in … be accessed

from needed databases (managed by various trade participants) via oracles …";Cité 21 fois;Les 3 versions;[HTML] emerald.com;https://www.emerald.com/insight/content/doi/10.1108/IMDS-12-2018-0568/full/html?casa_token=rMdSXDQOMmEAAAAA:wNKrXGFO3mXAwyqBgW739tewSq4nYXIzAViHbHdDF9rqGHN46oyft1dBmFx5MYdV8IYlzsZf4Uebfj1K73G67Bcrxj1ashRj5z_cPkFxZLujUJKKPQ;;"""keywords"",""International trade,Blockchain,Letter of credit,Smart contract,Distributed ledger technology,Business process re-engineering""
""dc.Title"",""Exploring blockchain technology in international trade: Business process re-engineering for letter of credit""
""citation_journal_title"",""Industrial Management &amp; Data Systems""
""description"",""Exploring blockchain technology in international trade: Business process re-engineering for letter of credit - Author: Shuchih Ernest Chang, Yi-Chian Chen, Tzu-Ching Wu""
""language"",""en""
""title"",""Exploring blockchain technology in international trade: Business process re-engineering for letter of credit
 |  Emerald Insight""
""dc.Identifier"",""10.1108/IMDS-12-2018-0568"",""0263-5577""
""dc.Publisher"",""Emerald Publishing Limited""
""dc.Format"",""text/html""
""dc:title"",""Exploring blockchain technology in international trade: Business process re-engineering for letter of credit
 |  Emerald Insight""
""csrf-token"",""39HRlEdK5yzyRGvvmYvQhIsmJdTs3m5WGTcH9PAH""
""Content-Encoding"",""UTF-8""
""dc.Date"",""2019-08-19T00:00:00Z""
""citation_xml_url"",""https://www.emerald.com/insight/content/doi/10.1108/IMDS-12-2018-0568/full/xml""
""dc.Subject"",""International trade,Blockchain,Letter of credit,Smart contract,Distributed ledger technology,Business process re-engineering""
""Content-Type"",""text/html; charset=UTF-8""
""dc.Contributor"",""Shuchih Ernest Chang"",""Yi-Chian Chen"",""Tzu-Ching Wu""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""dc.Type"",""article""
""resourceName"",""html""
""X-UA-Compatible"",""IE=edge""
""dc.Language"",""en""
""dc.Description"",""The purpose of this paper is to explore the applicability of blockchain technology in international trade process from a perspective of letter of credit payment.,A blockchain-based re-engineering process is designed by employing the blockchain and its affiliated smart contract technology to harvest the benefits of distributed ledger and distributed business workflow automation.,Comparative analysis and feasibility study were conducted to identify and validate the prospects, in terms of facilitating process flow and enhancing overall trade performance, of the proposed blockchain-based international trade process model.,Traditional trade processes suffer from a great number of issues about intermediaries, information latency and trust, which, in turn, hinder overall process efficiency. The emerging blockchain technology may have potentials to mitigate those issues by revolutionizing business processes across enterprise borders in various industries.,This study contributes to the conceptual design of a blockchain- and smart-contract-based process along with a provision of practical case in business process re-engineering. Further endeavors devoted to blockchain research and application across different sectors are suggested to reach better performance of business process operations.""
""viewport"",""width=device-width, initial-scale=1""
""DCTERMS.bibliographicCitation"",""&ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Ajournal&rft.spage=1712&rft.epage=1733&rft.volume=119&rft.issue=8""
""dc.Coverage"",""world""
""Content-Language"",""en""
""format-detection"",""telephone=no""
";https://scholar.google.com/scholar?start=120&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093487-336;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Blockchain and the law: A critical evaluation;J Quintais, B Bodó, A Giannopoulou… ; … Blockchain and the Law …, 2019  papers.ssrn.com;;"… The technology was born in the crypto-anarchist underground of the Internet … trading of derivatives;

however, since these instruments rely on future events, they would necessitate third parties (such

as oracles) to adjust … 8 STANFORD JOURNAL OF BLOCKCHAIN LAW & POLICY …";Cité 8 fois;Les 5 versions;[PDF] pubpub.org;https://assets.pubpub.org/lmtqgprc/41573938876287.pdf;;;https://scholar.google.com/scholar?start=170&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093541-564;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Security and privacy risks in the blockchain ecosystem;I Bartoletti, S Planti酠; Cyber Security: A Peer …, 2019  ingentaconnect.com;;"… Enterprise grade crypto-processors can be used that can securely generate, protect and store …

Therefore, organisations will need to consider multiple oracles and put additional controls in … More

practically, the reliance on private keys intrinsic to blockchain increases the risk of a …";Autres articles;;[PDF] gemserv.com;https://gemserv.com/wp-content/uploads/2020/04/Security-Privacy-Ricks-in-the-Blockchain-Ecosystem-Journal-Article.pdf;;"""date"",""2020-04-06T23:47:10Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.4""
""xmp:CreatorTool"",""Adobe InDesign 14.0 (Macintosh)""
""pdf:docinfo:title"",""Bartoletti.indd""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dcterms:created"",""2020-04-06T23:47:10Z""
""language"",""en""
""Last-Modified"",""2020-04-06T23:47:10Z""
""dcterms:modified"",""2020-04-06T23:47:10Z""
""dc:format"",""application/pdf; version=1.4""
""title"",""Bartoletti.indd""
""xmpMM:DocumentID"",""uuid:7b2b1c98-b07d-11f5-0000-9ffa993defbc""
""Last-Save-Date"",""2020-04-06T23:47:10Z""
""pdf:docinfo:creator_tool"",""Adobe InDesign 14.0 (Macintosh)""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2020-04-06T23:47:10Z""
""meta:save-date"",""2020-04-06T23:47:10Z""
""pdf:encrypted"",""false""
""dc:title"",""Bartoletti.indd""
""xmp:CreateDate"",""2020-04-06T23:47:10Z""
""modified"",""2020-04-06T23:47:10Z""
""Content-Length"",""382287""
""pdf:hasMarkedContent"",""false""
""Content-Type"",""application/pdf""
""xmp:ModifyDate"",""2020-04-06T23:47:10Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""pdf:producer"",""GPL Ghostscript 9.26""
""meta:creation-date"",""2020-04-06T23:47:10Z""
""created"",""2020-04-06T23:47:10Z""
""xmp:About"",""uuid:7b2b1c98-b07d-11f5-0000-9ffa993defbc""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""13""
""Creation-Date"",""2020-04-06T23:47:10Z""
""resourceName"",""Security-Privacy-Ricks-in-the-Blockchain-Ecosystem-Journal-Article.pdf""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""3541"",""2699"",""1926"",""3679"",""3635"",""3509"",""3712"",""2178"",""3700"",""3674"",""3666"",""4799"",""1521""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""producer"",""GPL Ghostscript 9.26""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""GPL Ghostscript 9.26""
""pdf:docinfo:created"",""2020-04-06T23:47:10Z""
";https://scholar.google.com/scholar?start=400&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093478-294;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;[PDF][PDF] Generic analysis of e-voting protocols by simplified blockchain;S Baek, N Lee, K Kim ; 2019 Symposium on Cryptography and …, 2019  caislab.kaist.ac.kr;;"… public bul- letin board based e-voting protocol using a simplified blockchain-based protocol

invoking read and append oracles … is simple; one may establish a pub- lic bulletin board and

replace read and append oracle invocations into … Simplified Blockchain with Smart Contract …";Cité 1 fois;Les 3 versions;[PDF] kaist.ac.kr;http://caislab.kaist.ac.kr/publication/paper_files/2019/SCIS%202019%20SG_NB%20final.pdf;;"""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""dc:title"",""301 Moved Permanently""
""Content-Encoding"",""ISO-8859-1""
""resourceName"",""SCIS%202019%20SG_NB%20final.pdf""
""language"",""en""
""Content-Length"",""296""
""title"",""301 Moved Permanently""
""Content-Type"",""text/html; charset=ISO-8859-1""
";https://scholar.google.com/scholar?start=130&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093536-542;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Using blockchain in the follow?up of emergency situations related to events;A Rivero?García, I Santos?González… ; Software: Practice …, 2019  Wiley Online Library;;"… Many of the latest implementation proposals for smart contracts are based on Ethereum. This

option operates on a distributed computing platform based on a public blockchain using a

cryptocurrency called ether. Solidity is the language used in Ethereum …";Autres articles;;[PDF] wiley.com;https://onlinelibrary.wiley.com/doi/pdf/10.1002/spe.2779?casa_token=mPoq6dTPle0AAAAA:uZfB50lzDIBhS8_IG5ITOZTcOFqhdqs9aoIeSpqdFdHUVYls-xqj7rrJS39VALJa9ffvMgaWpY1Wew;;;https://scholar.google.com/scholar?start=380&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093502-399;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Towards automated testing of blockchain-based decentralized applications;J Gao, H Liu, Y Li, C Liu, Z Yang, Q Li… ; 2019 IEEE/ACM 27th …, 2019  ieeexplore.ieee.org;;"… [15] Etherscan, “Ethereum (eth) blockchain explorer,” https://etherscan.io. [16] Ethereum, “Remix:

Solidity ide,” http://remix.ethereum.org … Springer, 2012, pp. 238–252. [21] S. Mirshokraie, A. Mesbah,

and K. Pattabiraman, “Pythia: Generating test cases with oracles for javascript …";Cité 10 fois;Les 3 versions;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/8797605/8813248/08813282.pdf?casa_token=iVzqhLO22UcAAAAA:2r1prXOaVCyuKEMq9qKmJVbeEDJfvXPvOQoiSRTiLW6jF8AoGPhvSKibDohOvBZKRVejZA46OtQ;;"""og:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""twitter:title"",""Towards Automated Testing of Blockchain-Based Decentralized Applications""
""twitter:card"",""summary""
""Description"",""Blockchain-based decentralized applications (DApp) have been widely adopted in different areas and trusted by more and more users due to the fact that the back ""
""og:title"",""Towards Automated Testing of Blockchain-Based Decentralized Applications""
""resourceName"",""08813282.pdf""
""language"",""en""
""title"",""Towards Automated Testing of Blockchain-Based Decentralized Applications | IEEE Conference Publication | IEEE Xplore""
""og:description"",""Blockchain-based decentralized applications (DApp) have been widely adopted in different areas and trusted by more and more users due to the fact that the back end code of a DApp is publicly run on the blockchain and cannot be modified implicitly. However, there are few effective methods and tools for testing DApps and bugs can be easily introduced by inexperienced developers. The existing testing techniques either focus on testing front-end programs or back-end code but ignore the interaction between them, which makes it difficult to apply the techniques directly on DApp. In this paper, we present an automated testing technique for DApps which works in a two-phase manner. First, we employ random events to infer an abstract relation between browser-side events and blockchain-side contracts. Second, our technique generates a set of test cases under the guidance of inferred relations and orders the test cases based on a read-write graph. We also use taint analysis to track data flow of the smart contract and feed it to the generation procedure for following test cases. We have developed a tool called Sungari to implement our approach, and evaluated it on representative real-world DApps. The preliminary evaluation results demonstrated the potential of Sungari in achieving a significant optimization compared to random testing approaches.""
""twitter:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-UA-Compatible"",""IE=Edge""
""viewport"",""width=device-width, initial-scale=1.0""
""dc:title"",""Towards Automated Testing of Blockchain-Based Decentralized Applications | IEEE Conference Publication | IEEE Xplore""
""twitter:description"",""Blockchain-based decentralized applications (DApp) have been widely adopted in different areas and trusted by more and more users due to the fact that the back end code of a DApp is publicly run on the blockchain and cannot be modified implicitly. However, there are few effective methods and tools for testing DApps and bugs can be easily introduced by inexperienced developers. The existing testing techniques either focus on testing front-end programs or back-end code but ignore the interaction between them, which makes it difficult to apply the techniques directly on DApp. In this paper, we present an automated testing technique for DApps which works in a two-phase manner. First, we employ random events to infer an abstract relation between browser-side events and blockchain-side contracts. Second, our technique generates a set of test cases under the guidance of inferred relations and orders the test cases based on a read-write graph. We also use taint analysis to track data flow of the smart contract and feed it to the generation procedure for following test cases. We have developed a tool called Sungari to implement our approach, and evaluated it on representative real-world DApps. The preliminary evaluation results demonstrated the potential of Sungari in achieving a significant optimization compared to random testing approaches.""
""Content-Encoding"",""UTF-8""
""Content-Type-Hint"",""text/html; charset=utf-8""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=230&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093478-300;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Decentralized Common Knowledge Oracles;AK Williams, J Peterson ; arXiv preprint arXiv:1912.01215, 2019  arxiv.org;;"… being incentive compatible in isolation, one must also consider the trustworthiness of oracles

in the … betting platform increases the gross incentive to make the platform's oracle lie … Many existing

blockchain oracle designs do not explicitly con- sider the incentives introduced by the …";Autres articles;;[PDF] arxiv.org;https://arxiv.org/pdf/1912.01215;;"""date"",""2019-12-04T01:32:05Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2019-12-04T01:32:05Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016) kpathsea version 6.2.2""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2019-12-04T01:32:05Z""
""created"",""2019-12-04T01:32:05Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-12-04T01:32:05Z""
""resourceName"",""1912.01215""
""Author"",""""
""producer"",""pdfTeX-1.40.17""
""pdf:docinfo:producer"",""pdfTeX-1.40.17""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""4"",""0"",""8"",""0"",""0"",""1"",""0"",""8"",""0"",""0"",""0"",""7"",""2"",""0"",""0"",""1"",""8"",""0"",""1"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2019-12-04T01:32:05Z""
""Last-Modified"",""2019-12-04T01:32:05Z""
""dcterms:modified"",""2019-12-04T01:32:05Z""
""title"",""""
""Last-Save-Date"",""2019-12-04T01:32:05Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2019-12-04T01:32:05Z""
""meta:save-date"",""2019-12-04T01:32:05Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016) kpathsea version 6.2.2""
""Content-Length"",""957408""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""22""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""4497"",""4415"",""3760"",""3309"",""4345"",""2130"",""3402"",""4907"",""4719"",""4037"",""3054"",""1911"",""2290"",""3518"",""3543"",""3637"",""4054"",""1833"",""2815"",""2714"",""3015"",""2098""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-12-04T01:32:05Z""
";https://scholar.google.com/scholar?start=130&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093516-458;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;[HTML][HTML] Afternoon Tutorial 2: Caches in the Modern Memory Hierarchy with Persistent Memory and Flash;I Ahmad, Y Vigfusson ;2019 usenix.org;;"… In 2009, Mike joined TMS as their Oracle and FlashSystem (Ramsan) evangelist. When IBM

Purchased TMS in 2012, Mike came along and has been working with FlashSystem at IBM ever

since, first with Oracle, then financial systems and now with Blockchain …";Les 2 versions;En cache;[HTML] usenix.org;https://www.usenix.org/conference/fast19/training-program;;"""citation_publication_date"",""2019""
""og:image"",""https://www.usenix.org/sites/default/files/fast19_banner_social-media_1200x630.png""
""citation_title"",""Afternoon Tutorial 2: Caches in the Modern Memory Hierarchy with Persistent Memory and Flash""
""citation_author_institution"",""CachePhysics"",""Emory University""
""article:published_time"",""2019-02-19T13:35:22-08:00""
""og:site_name"",""USENIX""
""rating"",""general""
""generator"",""Drupal 7 (http://drupal.org)""
""og:image:type"",""image/png""
""language"",""en""
""title"",""FAST '19 Training Program | USENIX""
""og:image:secure_url"",""https://www.usenix.org/sites/default/files/fast19_banner_social-media_1200x630.png""
""citation_author_email"",""mr.irfan@gmail.com"",""ymir@mathcs.emory.edu""
""article:modified_time"",""2019-02-19T15:26:34-08:00""
""dc:title"",""FAST '19 Training Program | USENIX""
""Content-Encoding"",""UTF-8""
""Content-Type"",""text/html; charset=UTF-8""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""og:type"",""article""
""og:image:url"",""https://www.usenix.org/sites/default/files/fast19_banner_social-media_1200x630.png""
""og:title"",""FAST '19 Training Program""
""citation_author"",""Irfan Ahmad"",""Ymir Vigfusson""
""resourceName"",""training-program""
""og:updated_time"",""2019-02-19T15:26:34-08:00""
""viewport"",""width=device-width, initial-scale=1""
""og:url"",""https://www.usenix.org/conference/fast19/training-program""
""Content-Language"",""en""
";https://scholar.google.com/scholar?start=290&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093469-254;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;A blockchain-based framework for collaborative production in distributed and social manufacturing;L Ouyang, Y Yuan, FY Wang ; 2019 IEEE International …, 2019  ieeexplore.ieee.org;;"… Among them, the blockchain in- frastructure mainly refers to the off-chain and cross-chain facilities,

including oracles, off-chain management and off- chain certification … In addition, the oracle is the

external trusted data feeds of blockchain and the off-chain management …";Cité 10 fois;Les 3 versions;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/8945268/8954999/08955075.pdf?casa_token=eSFCZAR3-h0AAAAA:m4WLSTVDJ8qZHr4qD5NtV9xp4B0iBK9BvFcIj_l632EoSbZSHhXIB29FtBoG0ZGsFMmmtBHB0j8;;"""og:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""twitter:title"",""A Blockchain-based Framework for Collaborative Production in Distributed and Social Manufacturing""
""twitter:card"",""summary""
""Description"",""In recent years, novel collaborative production paradigms, such as (re-)distributed manufacturing and social manufacturing, have attracted intensive attention d""
""og:title"",""A Blockchain-based Framework for Collaborative Production in Distributed and Social Manufacturing""
""resourceName"",""08955075.pdf""
""language"",""en""
""title"",""A Blockchain-based Framework for Collaborative Production in Distributed and Social Manufacturing | IEEE Conference Publication | IEEE Xplore""
""og:description"",""In recent years, novel collaborative production paradigms, such as (re-)distributed manufacturing and social manufacturing, have attracted intensive attention due to their potential of further changing the existing manufacturing modes and industrial structures. Blockchain, as a new distributed computing architecture, is expected to be successfully used in manufacturing, and help solve issues related to interoperability and collaboration, security and supervision, marketization and protocol, democratic organization and global value chain governance, and so on. In this paper, a blockchain-based framework for collaborative production is proposed, aiming at providing novel ideas for the design, implementation and optimization of collaborative production, and also inspiring the upgrading and transformation of manufacturing industries.""
""twitter:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-UA-Compatible"",""IE=Edge""
""viewport"",""width=device-width, initial-scale=1.0""
""dc:title"",""A Blockchain-based Framework for Collaborative Production in Distributed and Social Manufacturing | IEEE Conference Publication | IEEE Xplore""
""twitter:description"",""In recent years, novel collaborative production paradigms, such as (re-)distributed manufacturing and social manufacturing, have attracted intensive attention due to their potential of further changing the existing manufacturing modes and industrial structures. Blockchain, as a new distributed computing architecture, is expected to be successfully used in manufacturing, and help solve issues related to interoperability and collaboration, security and supervision, marketization and protocol, democratic organization and global value chain governance, and so on. In this paper, a blockchain-based framework for collaborative production is proposed, aiming at providing novel ideas for the design, implementation and optimization of collaborative production, and also inspiring the upgrading and transformation of manufacturing industries.""
""Content-Encoding"",""UTF-8""
""Content-Type-Hint"",""text/html; charset=utf-8""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=90&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093473-276;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;A blockchain-based privacy-awareness authentication scheme with efficient revocation for multi-server architectures;L Xiong, F Li, S Zeng, T Peng, Z Liu ; IEEE Access, 2019  ieeexplore.ieee.org;;"… In this work, we apply the idea of blockchain technology to construct a privacy-awareness

authentication scheme for the multi-server environment, which can achieve … The security of the

proposed scheme is proved by rigorous formal proof using the random oracle model …";Cité 10 fois;;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/6287639/8600701/08824125.pdf;;"""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""dc:title"",""IEEE Xplore Full-Text PDF:""
""Content-Encoding"",""UTF-8""
""resourceName"",""08824125.pdf""
""language"",""es""
""Content-Length"",""2565""
""title"",""IEEE Xplore Full-Text PDF:""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=110&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093534-531;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;An Overview of Blockchain Technology Based on a Study of Public Awareness;M Kramer ; Global Journal of Business Research, 2019  papers.ssrn.com;;"… Software: Oracle Corporation announced that they had launched Enterprise-Grade Blockchain

Cloud Service to their customers … pwc.com, Accessed October 27, 2017 at https://www.pwc.com/

us/en/industries/financial-services/fintech/bitcoin-blockchain-cryptocurrency.html …";Cité 3 fois;Les 6 versions;[PDF] researchgate.net;https://www.researchgate.net/profile/Mitch_Kramer/publication/332786209_AN_OVERVIEW_OF_BLOCKCHAIN_TECHNOLOGY_BASED_ON_A_STUDY_OF_PUBLIC_AWARENESS/links/5cc9b3cd4585156cd7c18ef7/AN-OVERVIEW-OF-BLOCKCHAIN-TECHNOLOGY-BASED-ON-A-STUDY-OF-PUBLIC-AWARENESS.pdf;;;https://scholar.google.com/scholar?start=370&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093497-377;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Estimating service quality in industrial internet-of-things monitoring applications with blockchain;A Maiti, ALI Raza, BH Kang, L Hardy ; IEEE Access, 2019  ieeexplore.ieee.org;;"… A. BLOCKCHAIN AND DATABASE: ASSET VS INFORMATION As the origin of

blockchain lies in crypto currency, blockchain primarily deals with assets such as

coins. An asset, such as a coin or similar product in the current …";Cité 8 fois;Les 5 versions;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/6287639/8600701/08876654.pdf;;"""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""dc:title"",""IEEE Xplore Full-Text PDF:""
""Content-Encoding"",""UTF-8""
""resourceName"",""08876654.pdf""
""language"",""es""
""Content-Length"",""2565""
""title"",""IEEE Xplore Full-Text PDF:""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=210&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093485-329;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;[PDF][PDF] Lelantus: Towards Confidentiality and Anonymity of Blockchain Transactions from Standard Assumptions.;A Jivanyan ; IACR Cryptol. ePrint Arch., 2019  lelantus.io;;"… protocol that is secure and special honest-verifier zero-knowledge in the random oracle model

using … redeems a previously minted coin to transfer the shielded value back to the base

cryptocurrency … Lelantus can be integrated with any blockchain-based currency, such as Bitcoin …";Cité 14 fois;Les 3 versions;[PDF] lelantus.io;https://lelantus.io/lelantus.pdf;;"""date"",""2019-06-03T08:22:46Z""
""pdf:unmappedUnicodeCharsPerPage"",""2"",""0"",""1"",""6"",""0"",""0"",""0"",""2"",""2"",""10"",""15"",""16"",""4"",""14"",""16"",""17"",""0"",""0"",""0"",""42"",""25"",""25"",""17""
""pdf:PDFVersion"",""1.5""
""xmp:CreatorTool"",""TeX""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dcterms:created"",""2019-06-03T08:22:46Z""
""language"",""en""
""Last-Modified"",""2019-06-03T08:22:46Z""
""dcterms:modified"",""2019-06-03T08:22:46Z""
""dc:format"",""application/pdf; version=1.5""
""Last-Save-Date"",""2019-06-03T08:22:46Z""
""pdf:docinfo:creator_tool"",""TeX""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2019-06-03T08:22:46Z""
""meta:save-date"",""2019-06-03T08:22:46Z""
""pdf:encrypted"",""false""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is MiKTeX-pdfTeX 2.9.6839 (1.40.19)""
""modified"",""2019-06-03T08:22:46Z""
""Content-Length"",""445261""
""pdf:hasMarkedContent"",""false""
""Content-Type"",""application/pdf""
""PTEX.Fullbanner"",""This is MiKTeX-pdfTeX 2.9.6839 (1.40.19)""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""trapped"",""False""
""meta:creation-date"",""2019-06-03T08:22:46Z""
""created"",""2019-06-03T08:22:46Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""23""
""Creation-Date"",""2019-06-03T08:22:46Z""
""resourceName"",""lelantus.pdf""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""2543"",""2432"",""2372"",""2661"",""1634"",""2487"",""2827"",""3015"",""2022"",""2247"",""1937"",""2036"",""1708"",""1712"",""1813"",""1700"",""2513"",""2262"",""3254"",""1946"",""1814"",""1683"",""2656""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""producer"",""MiKTeX pdfTeX-1.40.19""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""MiKTeX pdfTeX-1.40.19""
""pdf:docinfo:created"",""2019-06-03T08:22:46Z""
";https://scholar.google.com/scholar?start=160&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093476-287;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Aggregating crowd wisdom via blockchain: A private, correct, and robust realization;H Duan, Y Zheng, Y Du, A Zhou… ; 2019 IEEE …, 2019  ieeexplore.ieee.org;;"Page 1. Aggregating Crowd Wisdom via Blockchain: A Private, Correct, and Robust

Realization … We therefore explore an alternative design space of building crowdsensing

systems atop the emerging decentralized blockchain technology …";Cité 20 fois;Les 5 versions;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/8765204/8767360/08767412.pdf?casa_token=dFEFC4MfZIoAAAAA:DYwSDqSvPPxE2Kp6GJbBc2CPI20jHJo7JaIzLl8sWCqOtqiW7Bew-a5paZwE0cAxVFvGxSMcMcI;;"""og:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""twitter:title"",""Aggregating Crowd Wisdom via Blockchain: A Private, Correct, and Robust Realization""
""twitter:card"",""summary""
""Description"",""Crowdsensing, driven by the proliferation of sensor-rich mobile devices, has emerged as a promising data sensing and aggregation paradigm. Despite useful, tradi""
""og:title"",""Aggregating Crowd Wisdom via Blockchain: A Private, Correct, and Robust Realization""
""resourceName"",""08767412.pdf""
""language"",""en""
""title"",""Aggregating Crowd Wisdom via Blockchain: A Private, Correct, and Robust Realization | IEEE Conference Publication | IEEE Xplore""
""og:description"",""Crowdsensing, driven by the proliferation of sensor-rich mobile devices, has emerged as a promising data sensing and aggregation paradigm. Despite useful, traditional crowdsensing systems typically rely on a centralized third-party platform for data collection and processing, which leads to concerns like single point of failure and lack of operation transparency. Such centralization hinders the wide adoption of crowdsensing by wary participants. We therefore explore an alternative design space of building crowdsensing systems atop the emerging decentralized blockchain technology. While enjoying the benefits brought by the public blockchain, we endeavor to achieve a consolidated set of desirable security properties with a proper choreography of latest techniques and our customized designs. We allow data providers to safely contribute data to the transparent blockchain with the confidentiality guarantee on individual data and differential privacy on the aggregation result. Meanwhile, we ensure the service correctness of data aggregation and sanitization by delicately employing hardware-assisted transparent enclave. Furthermore, we maintain the robustness of our system against faulty data providers that submit invalid data, with a customized zero-knowledge range proof scheme. The experiment results demonstrate the high efficiency of our designs on both mobile client and SGX-enabled server, as well as reasonable on-chain monetary cost of running our task contract on Ethereum.""
""twitter:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-UA-Compatible"",""IE=Edge""
""viewport"",""width=device-width, initial-scale=1.0""
""dc:title"",""Aggregating Crowd Wisdom via Blockchain: A Private, Correct, and Robust Realization | IEEE Conference Publication | IEEE Xplore""
""twitter:description"",""Crowdsensing, driven by the proliferation of sensor-rich mobile devices, has emerged as a promising data sensing and aggregation paradigm. Despite useful, traditional crowdsensing systems typically rely on a centralized third-party platform for data collection and processing, which leads to concerns like single point of failure and lack of operation transparency. Such centralization hinders the wide adoption of crowdsensing by wary participants. We therefore explore an alternative design space of building crowdsensing systems atop the emerging decentralized blockchain technology. While enjoying the benefits brought by the public blockchain, we endeavor to achieve a consolidated set of desirable security properties with a proper choreography of latest techniques and our customized designs. We allow data providers to safely contribute data to the transparent blockchain with the confidentiality guarantee on individual data and differential privacy on the aggregation result. Meanwhile, we ensure the service correctness of data aggregation and sanitization by delicately employing hardware-assisted transparent enclave. Furthermore, we maintain the robustness of our system against faulty data providers that submit invalid data, with a customized zero-knowledge range proof scheme. The experiment results demonstrate the high efficiency of our designs on both mobile client and SGX-enabled server, as well as reasonable on-chain monetary cost of running our task contract on Ethereum.""
""Content-Encoding"",""UTF-8""
""Content-Type-Hint"",""text/html; charset=utf-8""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=120&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093490-346;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;[PDF][PDF] Blockchain as a project management platform;T Hewavitharana, S Nanayakkara… ; Proceedings of the 8th …, 2019  academia.edu;;"… For these types of contracts, the trusted third party from outside the blockchain needs

to be brought to execute the contracts, and they are called as “Oracles”. However,

these parties needed to be approved by contractual parties …";Cité 9 fois;Les 6 versions;[PDF] academia.edu;https://www.academia.edu/download/61261710/WCS2019_14_-_Blockchain_as_a_project_management_platform20191118-97387-39zxt5.pdf;;;https://scholar.google.com/scholar?start=180&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093532-530;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;[LIVRE][B] Blockchain Technologies;A Singh ;2019 books.google.com;;"… Topics include decentralization, mining, the politics of Bitcoin, altcoins and the cryptocurrency

ecosystem, the future of Bitcoin, and more … Well, lets take a crypto valuta like Bitcoin (for more

information on Bitcoin see subsection 3.1.1). The crypto valuta is built on blockchain so it …";Autres articles;;null;;;;https://scholar.google.com/scholar?start=360&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093546-588;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Emerging Solutions for the Improvement of Food Traceability in the EU: Examining the Use of Blockchain Technology for Tracing Extra Virgin Olive Oil (EVOO);OA BUTTAFOCO ;2019 divaportal.org;;"… point focused on the Bitcoin cryptocurrency, whereas less than 20% addressed other

blockchain applications.26 Though most authors continue to classify blockchain

literature according to a 'financial/non- financial' division27 …";Autres articles;Version HTML;[PDF] diva-portal.org;https://www.diva-portal.org/smash/get/diva2:1347063/FULLTEXT01.pdf;;"""date"",""2019-08-29T20:33:35Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.3""
""pdf:docinfo:title"",""Microsoft Word - MA_THESIS_OB_FINAL.docx""
""xmp:CreatorTool"",""Word""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dcterms:created"",""2019-08-29T20:33:35Z""
""language"",""en""
""Last-Modified"",""2019-08-29T20:33:35Z""
""dcterms:modified"",""2019-08-29T20:33:35Z""
""dc:format"",""application/pdf; version=1.3""
""title"",""Microsoft Word - MA_THESIS_OB_FINAL.docx""
""Last-Save-Date"",""2019-08-29T20:33:35Z""
""pdf:docinfo:creator_tool"",""Word""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2019-08-29T20:33:35Z""
""meta:save-date"",""2019-08-29T20:33:35Z""
""pdf:encrypted"",""false""
""dc:title"",""Microsoft Word - MA_THESIS_OB_FINAL.docx""
""modified"",""2019-08-29T20:33:35Z""
""Content-Length"",""1983416""
""pdf:hasMarkedContent"",""false""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""meta:creation-date"",""2019-08-29T20:33:35Z""
""created"",""2019-08-29T20:33:35Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""94""
""Creation-Date"",""2019-08-29T20:33:35Z""
""resourceName"",""FULLTEXT01.pdf""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""710"",""1097"",""2417"",""5244"",""2739"",""3433"",""3213"",""2836"",""3187"",""3600"",""2168"",""3005"",""1437"",""3122"",""2645"",""2744"",""3135"",""2585"",""3474"",""2535"",""2000"",""3499"",""2994"",""2093"",""860"",""2325"",""3007"",""3211"",""3136"",""2673"",""2835"",""2653"",""2910"",""2283"",""3243"",""3054"",""2908"",""2981"",""1334"",""2356"",""2671"",""3058"",""3420"",""3054"",""2879"",""1628"",""2165"",""2344"",""3192"",""3398"",""2392"",""1995"",""2418"",""2971"",""3092"",""3413"",""2491"",""2662"",""3200"",""2836"",""3044"",""1636"",""3181"",""3335"",""3252"",""3226"",""3695"",""3210"",""2838"",""3019"",""3218"",""1880"",""337"",""958"",""3071"",""2889"",""2991"",""2556"",""3220"",""662"",""2599"",""2791"",""2651"",""2751"",""2793"",""2732"",""2698"",""2587"",""2481"",""2690"",""2487"",""2471"",""2165"",""494""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""producer"",""Mac OS X 10.10.5 Quartz PDFContext""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""Mac OS X 10.10.5 Quartz PDFContext""
""pdf:docinfo:created"",""2019-08-29T20:33:35Z""
";https://scholar.google.com/scholar?start=420&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093483-319;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;[PDF][PDF] Tokenization of physical assets and the impact of IoT and AI;T Weingärtner ; Lucerne University of Applied Sciences & …, 2019  blockchain.pwias.ubc.ca;;"… Mod18], ie the manipulation of the interface to the Blockchain, the properties “distribution”,

“redundancy” and “transparency” of the Blockchain can be used. A common approach is not to

rely on one Oracle, but to use a consensus-based Oracle, ie to connect several Oracles …";Cité 10 fois;Les 2 versions;[PDF] ubc.ca;https://blockchain.pwias.ubc.ca/sites/blockchain.pwias.ubc.ca/files/report-files/Weingaertner_Tokenization_IoT_AI%20(1).pdf;;"""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.5""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""15""
""resourceName"",""Weingaertner_Tokenization_IoT_AI%20(1).pdf""
""language"",""en""
""pdf:hasXMP"",""false""
""dc:format"",""application/pdf; version=1.5""
""pdf:charsPerPage"",""759"",""2566"",""2753"",""2973"",""3059"",""2541"",""2508"",""1931"",""2360"",""2510"",""1860"",""2844"",""2330"",""2340"",""1615""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""producer"",""Skia/PDF m75""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""Skia/PDF m75""
""pdf:hasMarkedContent"",""false""
""Content-Type"",""application/pdf""
";https://scholar.google.com/scholar?start=150&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093525-497;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Who is Liable for an Attack on Cryptocurrency Consensus?;P Řstbye ; Available at SSRN 3442597, 2019  papers.ssrn.com;;"… by outside gains from impeding the perceived immutability of the blockchain to destroy … many

cryptocurrencies, interacting with the outside world is necessary; the cryptocurrency op- erations …

Such information can be provided by oracles, and the information provided by oracles …";Cité 3 fois;;null;;;;https://scholar.google.com/scholar?start=330&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093478-298;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Blockchain-based charging coordination mechanism for smart grid energy storage units;M Baza, M Nabil, M Ismail, M Mahmoud… ; … on Blockchain  …, 2019  ieeexplore.ieee.org;;"Page 1. Blockchain-based Charging Coordination Mechanism for Smart Grid Energy Storage

Units … In this paper, we leverage the blockchain and smart contracts to build a decentralized

charging coordi- nation mechanism without the need for a centralized charging coordinator …";Cité 42 fois;Les 5 versions;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/8938397/8946120/08946265.pdf?casa_token=Jf8WcRm9HRsAAAAA:18ljQkhNcH1KicH2ml8uDl-QVs-FGwmnXFcl6BhOIgbGx-BbEctam7ibXG3L6so0ksDiP0HWjhQ;;"""og:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""twitter:title"",""Blockchain-Based Charging Coordination Mechanism for Smart Grid Energy Storage Units""
""twitter:card"",""summary""
""Description"",""Energy storage units (ESUs) enable several attractive features of modern smart grids such as enhanced grid resilience, effective demand response, and reduced bi""
""og:title"",""Blockchain-Based Charging Coordination Mechanism for Smart Grid Energy Storage Units""
""resourceName"",""08946265.pdf""
""language"",""en""
""title"",""Blockchain-Based Charging Coordination Mechanism for Smart Grid Energy Storage Units | IEEE Conference Publication | IEEE Xplore""
""og:description"",""Energy storage units (ESUs) enable several attractive features of modern smart grids such as enhanced grid resilience, effective demand response, and reduced bills. However, uncoordinated charging of ESUs stresses the power system and can lead to a blackout. In this paper, we leverage the blockchain and smart contracts to build a decentralized charging coordination mechanism without the need for a centralized charging coordinator. First ESUs should use tokens for anonymously authenticate themselves to the blockchain. Then each ESU sends a charging request that contains its State-of-Charge (SoC), Time-to-complete-charge (TCC) and amount of required charging to the smart contract address on the blockchain. The smart contract will then run the charging coordination mechanism in a self-executed manner such that ESUs with the highest priorities are charged in the present time slot while charging requests of lower priority ESUs are deferred to future time slots. In this way, each ESU can make sure that charging schedules are computed correctly. Finally, we have implemented the proposed mechanism on the Ethereum test-bed blockchain, and our analysis shows that execution cost can be acceptable in terms of gas consumption while enabling decentralized charging coordination with increased transparency, reliability, and privacy preserving.""
""twitter:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-UA-Compatible"",""IE=Edge""
""viewport"",""width=device-width, initial-scale=1.0""
""dc:title"",""Blockchain-Based Charging Coordination Mechanism for Smart Grid Energy Storage Units | IEEE Conference Publication | IEEE Xplore""
""twitter:description"",""Energy storage units (ESUs) enable several attractive features of modern smart grids such as enhanced grid resilience, effective demand response, and reduced bills. However, uncoordinated charging of ESUs stresses the power system and can lead to a blackout. In this paper, we leverage the blockchain and smart contracts to build a decentralized charging coordination mechanism without the need for a centralized charging coordinator. First ESUs should use tokens for anonymously authenticate themselves to the blockchain. Then each ESU sends a charging request that contains its State-of-Charge (SoC), Time-to-complete-charge (TCC) and amount of required charging to the smart contract address on the blockchain. The smart contract will then run the charging coordination mechanism in a self-executed manner such that ESUs with the highest priorities are charged in the present time slot while charging requests of lower priority ESUs are deferred to future time slots. In this way, each ESU can make sure that charging schedules are computed correctly. Finally, we have implemented the proposed mechanism on the Ethereum test-bed blockchain, and our analysis shows that execution cost can be acceptable in terms of gas consumption while enabling decentralized charging coordination with increased transparency, reliability, and privacy preserving.""
""Content-Encoding"",""UTF-8""
""Content-Type-Hint"",""text/html; charset=utf-8""
""Content-Length"",""42780""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=130&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093518-464;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Blockchain-enabled smart contracts for enhancing distributor-to-consumer transactions;Q Wang, RYK Lau, X Mao ; IEEE Consumer Electronics …, 2019  ieeexplore.ieee.org;;"… Meanwhile, the oracles in smart contract monitor external data sources … The consumer can find

the smart contract through the corresponding blockchain mechanism … After that, a sales agreement

and crypto- currency payment are automatically enforced by Smart Contract 4. Finally …";Cité 6 fois;Les 3 versions;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/5962380/8889525/08889545.pdf?casa_token=YzQyffw1WLsAAAAA:FoqYCjqnDRcE5XIVp-68h5X8awb4tS56YvudKkgdq8ZSXnmynkVsZfyBoUUwNFbWRQPA88cD0yc;;"""og:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""twitter:title"",""Blockchain-Enabled Smart Contracts for Enhancing Distributor-to-Consumer Transactions""
""twitter:card"",""summary""
""Description"",""This article examines options to improve efficiency and prevent counterfeits related to distributor-to-consumer (D2C) transaction processing in the consumer ele""
""og:title"",""Blockchain-Enabled Smart Contracts for Enhancing Distributor-to-Consumer Transactions""
""resourceName"",""08889545.pdf""
""language"",""en""
""title"",""Blockchain-Enabled Smart Contracts for Enhancing Distributor-to-Consumer Transactions | IEEE Journals & Magazine | IEEE Xplore""
""og:description"",""This article examines options to improve efficiency and prevent counterfeits related to distributor-to-consumer (D2C) transaction processing in the consumer electronics (CE) industry. Particularly, we propose a smart contract enabled D2C model that provides a blueprint for the smart integration of CE transactions. To the best of our knowledge, the proposed CE-specific D2C model is among the very few attempts of leveraging smart contracts to enhance the efficiency and efficacy of CE applications.""
""twitter:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-UA-Compatible"",""IE=Edge""
""viewport"",""width=device-width, initial-scale=1.0""
""dc:title"",""Blockchain-Enabled Smart Contracts for Enhancing Distributor-to-Consumer Transactions | IEEE Journals & Magazine | IEEE Xplore""
""twitter:description"",""This article examines options to improve efficiency and prevent counterfeits related to distributor-to-consumer (D2C) transaction processing in the consumer electronics (CE) industry. Particularly, we propose a smart contract enabled D2C model that provides a blueprint for the smart integration of CE transactions. To the best of our knowledge, the proposed CE-specific D2C model is among the very few attempts of leveraging smart contracts to enhance the efficiency and efficacy of CE applications.""
""Content-Encoding"",""UTF-8""
""Content-Type-Hint"",""text/html; charset=utf-8""
""Content-Length"",""39919""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=300&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093511-440;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Key-insulated and privacy-preserving signature scheme with publicly derived public key;Z Liu, G Yang, DS Wong, K Nguyen… ; 2019 IEEE European …, 2019  ieeexplore.ieee.org;;"… has been undergoing a quick and explosive development, with thousands of different crypto-

coins available … algorithm and similar variants have been widely adopted by the cryptocurrency

community to … construction, and prove its security and privacy in the random oracle model …";Cité 2 fois;Les 4 versions;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/8790377/8806708/08806749.pdf?casa_token=mVSwX83h6-cAAAAA:8b9n2eD92wd9k0NMnB86hSVR7B-HKyn7XLkoUSG5aNYbFmzNXSzlaKBLYc2Frpt8ZHsdtLAVyQ0;;"""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""dc:title"",""IEEE Xplore Full-Text PDF:""
""Content-Encoding"",""UTF-8""
""resourceName"",""08806749.pdf""
""language"",""es""
""Content-Length"",""2533""
""title"",""IEEE Xplore Full-Text PDF:""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=270&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093527-507;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;[PDF][PDF] RobotChain: a Blockchain for Registering;MIF Fernandes ;2019 di.ubi.pt;;"… the basis for the Kambria Platform”. The developers are given an incentive with the

integration of blockchain and crypto-economics, since it provides economic incentives

to contribute to the platform. There is also the intent to …";Autres articles;;[PDF] ubi.pt;http://di.ubi.pt/~lfbaa/robotchain/miguel_thesis.pdf;;"""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.5""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dcterms:created"",""2019-06-20T15:22:33Z""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""Content-Length"",""727424""
""pdf:hasMarkedContent"",""false""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""meta:creation-date"",""2019-06-20T15:22:33Z""
""created"",""2019-06-20T15:22:33Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""56""
""Creation-Date"",""2019-06-20T15:22:33Z""
""resourceName"",""miguel_thesis.pdf""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""264"",""69"",""502"",""69"",""1575"",""69"",""1005"",""71"",""1968"",""1162"",""2664"",""70"",""1806"",""70"",""2224"",""720"",""2734"",""3057"",""2983"",""3348"",""1595"",""68"",""1879"",""1838"",""2307"",""1572"",""1347"",""2346"",""2328"",""1626"",""1869"",""2567"",""3278"",""2698"",""2323"",""2269"",""2495"",""2501"",""3255"",""2200"",""2095"",""1633"",""2462"",""2075"",""2741"",""2654"",""592"",""69"",""2581"",""259"",""2300"",""1963"",""1706"",""1520"",""639"",""69""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""producer"",""XeTeX 0.99996""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""XeTeX 0.99996""
""pdf:docinfo:created"",""2019-06-20T15:22:33Z""
";https://scholar.google.com/scholar?start=340&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093511-434;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Applying Blockchain Technology in the Sphere of Payments and Financial Services;V Nikiforova, Y Putikhin, A Nikiforov… ; … in Logistics and …, 2019  atlantispress.com;;"… When the completion date arrives, the program code is sent to the oracles to receive … step in the

process of legalizing the use of cryptocurrency based on blockchain technology, we … parks or

clusters, introducing a decentralized system for organizing the circulation of crypto assets …";Cité 1 fois;Les 3 versions;[PDF] atlantis-press.com;https://download.atlantis-press.com/article/125918560.pdf;;"""date"",""2019-09-27T13:31:52Z""
""pdf:PDFVersion"",""1.6""
""xmp:CreatorTool"",""MicrosoftÂŽ Word 2013""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""language"",""en""
""dc:format"",""application/pdf; version=1.6""
""pdf:docinfo:creator_tool"",""MicrosoftÂŽ Word 2013""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""xmp:CreateDate"",""2019-09-22T22:45:08Z""
""modified"",""2019-09-27T13:31:52Z""
""pdf:hasMarkedContent"",""true""
""xmp:ModifyDate"",""2019-09-27T15:31:52Z""
""pdf:docinfo:creator"",""User""
""meta:author"",""User""
""meta:creation-date"",""2019-09-22T19:45:08Z""
""created"",""2019-09-22T19:45:08Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-09-22T19:45:08Z""
""resourceName"",""125918560.pdf""
""Author"",""User""
""producer"",""MicrosoftÂŽ Word 2013""
""pdf:docinfo:producer"",""MicrosoftÂŽ Word 2013""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0""
""access_permission:modify_annotations"",""true""
""dc:creator"",""User""
""dcterms:created"",""2019-09-22T19:45:08Z""
""Last-Modified"",""2019-09-27T13:31:52Z""
""dcterms:modified"",""2019-09-27T13:31:52Z""
""xmpMM:DocumentID"",""uuid:4940ef5f-bc67-4a8c-8d39-68ba3b5fea55""
""Last-Save-Date"",""2019-09-27T13:31:52Z""
""pdf:docinfo:modified"",""2019-09-27T13:31:52Z""
""meta:save-date"",""2019-09-27T13:31:52Z""
""Content-Length"",""2253462""
""Content-Type"",""application/pdf""
""xmp:MetadataDate"",""2019-09-27T15:31:52Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""User""
""dc:language"",""en-US""
""pdf:producer"",""MicrosoftÂŽ Word 2013""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""4""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""5782"",""7027"",""7178"",""4387""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-09-22T19:45:08Z""
";https://scholar.google.com/scholar?start=270&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093455-195;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;[PDF][PDF] The governance of blockchain dispute resolution;DWE Allen, AM Lane, M Poblet ; Harv. Negot. L. Rev., 2019  HeinOnline;;"… Fall 2019] Governance of Blockchain Dispute Resolution … the output of the dispute could feed

back into the smart contract as an ""oracle."" For such … contracts relying on territorial judgements

and enforcement, smart contacts could use territorial judgments as ""oracles,"" enabling the …";Cité 24 fois;Les 6 versions;[PDF] heinonline.org;https://heinonline.org/hol-cgi-bin/get_pdf.cgi?handle=hein.journals/haneg25&section=5&casa_token=s4X1RAyllTMAAAAA:yQKByx7gydsl1LLoA1JnPeKMrBh2aPYSQGzE-lyvLXb-o1_ndCkB5s0ym3T3mFBlc1U6o60;;"""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""REFRESH"",""1; url=https://heinonline.org/HOL/Page?handle=hein.journals/haneg25&div=5&g_sent=1&casa_token=s4X1RAyllTMAAAAA:yQKByx7gydsl1LLoA1JnPeKMrBh2aPYSQGzE-lyvLXb-o1_ndCkB5s0ym3T3mFBlc1U6o60""
""Content-Encoding"",""UTF-8""
""resourceName"",""get_pdf.cgi""
""language"",""""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=30&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093504-403;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;[PDF][PDF] The Ongoing Speculation about Smart Contracts: Smart Enough to Replace Third Party Arbitrators, Or Is' Smart'Just a Misnomer?;R Kalantarova ; Cardozo J. Conflict Resol., 2019  HeinOnline;;"… outside of the smart contract itself.66 This can be done with the help of oracles, which are ""trusted

data feeds … to go into effect, the trigger event has to be the death of the individual.69 The oracle

agent has to verify this real-world occurrence outside of the blockchain, find out …";Autres articles;;[PDF] heinonline.org;https://heinonline.org/hol-cgi-bin/get_pdf.cgi?handle=hein.journals/cardcore21&section=25&casa_token=PD_NJkhgWaoAAAAA:iTiFD8AL4RXjWGHhnDFNO68Sef4U_z1xA2fnqCHYJQOnh3jWLJ1nG0PJ1WcbWNpBURAfdVs;;"""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""REFRESH"",""1; url=https://heinonline.org/HOL/Page?handle=hein.journals/cardcore21&div=25&g_sent=1&casa_token=PD_NJkhgWaoAAAAA:iTiFD8AL4RXjWGHhnDFNO68Sef4U_z1xA2fnqCHYJQOnh3jWLJ1nG0PJ1WcbWNpBURAfdVs""
""Content-Encoding"",""UTF-8""
""resourceName"",""get_pdf.cgi""
""language"",""""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=240&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093502-395;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Initial Crypto-asset Offerings (ICOs), tokenization and corporate governance;S Blémus, D Guégan ; arXiv preprint arXiv:1905.03340, 2019  arxiv.org;;"… Crypto-assets issued during an ICO are initially transferred to investors through smart contracts'

computer code, in exchange of a pre-existing cryptocurrency or against a fiat … 13 About the definition

of smart contracts, see also: S. Blemus, “Law and Blockchain: A Legal …";Cité 15 fois;Les 13 versions;[PDF] arxiv.org;https://arxiv.org/pdf/1905.03340;;"""date"",""2019-03-06T15:57:36Z""
""pdf:PDFVersion"",""1.7""
""xmp:CreatorTool"",""Acrobat 11.0.23""
""pdf:docinfo:title"",""19004.pdf""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""ICO; Crypto-asset; Blockchain; Governance; Tokens; Fair value; Illiquid market; Kalman filter; Mark to model"",""ICO; Crypto-asset; Blockchain; Governance; Tokens; Fair value; Illiquid market; Kalman filter; Mark to model""
""language"",""en""
""dc:format"",""application/pdf; version=1.7""
""pdf:docinfo:creator_tool"",""Acrobat 11.0.23""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""19004.pdf""
""xmp:CreateDate"",""2019-03-06T16:53:55Z""
""modified"",""2019-03-06T15:57:36Z""
""pdf:hasMarkedContent"",""true""
""xmp:ModifyDate"",""2019-03-06T16:57:36Z""
""pdf:docinfo:creator"",""StĂŠphane Blemus""
""meta:author"",""StĂŠphane Blemus"",""Dominique GuĂŠgan""
""meta:creation-date"",""2019-03-06T15:53:55Z""
""created"",""2019-03-06T15:53:55Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-03-06T15:53:55Z""
""resourceName"",""1905.03340""
""Author"",""StĂŠphane Blemus"",""Dominique GuĂŠgan""
""producer"",""Acrobat 11.0.23""
""pdf:docinfo:producer"",""Acrobat 11.0.23""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""Keywords"",""ICO; Crypto-asset; Blockchain; Governance; Tokens; Fair value; Illiquid market; Kalman filter; Mark to model"",""ICO; Crypto-asset; Blockchain; Governance; Tokens; Fair value; Illiquid market; Kalman filter; Mark to model""
""access_permission:modify_annotations"",""true""
""dc:creator"",""StĂŠphane Blemus"",""Dominique GuĂŠgan""
""dcterms:created"",""2019-03-06T15:53:55Z""
""Last-Modified"",""2019-03-06T15:57:36Z""
""dcterms:modified"",""2019-03-06T15:57:36Z""
""title"",""19004.pdf""
""xmpMM:DocumentID"",""uuid:2570f570-4a28-2248-ba85-4939e82e15ab""
""Last-Save-Date"",""2019-03-06T15:57:36Z""
""pdf:docinfo:keywords"",""ICO; Crypto-asset; Blockchain; Governance; Tokens; Fair value; Illiquid market; Kalman filter; Mark to model""
""pdf:docinfo:modified"",""2019-03-06T15:57:36Z""
""meta:save-date"",""2019-03-06T15:57:36Z""
""Content-Length"",""815774""
""Content-Type"",""application/pdf""
""xmp:MetadataDate"",""2019-03-06T16:57:36Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""StĂŠphane Blemus"",""Dominique GuĂŠgan""
""pdf:producer"",""Acrobat 11.0.23""
""dc:subject"",""ICO; Crypto-asset; Blockchain; Governance; Tokens; Fair value; Illiquid market; Kalman filter; Mark to model"",""ICO; Crypto-asset; Blockchain; Governance; Tokens; Fair value; Illiquid market; Kalman filter; Mark to model""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""32""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""378"",""3206"",""4137"",""1624"",""3181"",""3318"",""3626"",""4395"",""4459"",""4508"",""4052"",""3911"",""4069"",""4474"",""4312"",""4470"",""4704"",""5074"",""5284"",""4837"",""4777"",""3650"",""3780"",""3914"",""4614"",""3955"",""4451"",""4470"",""4943"",""4440"",""3917"",""1548""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""meta:keyword"",""ICO; Crypto-asset; Blockchain; Governance; Tokens; Fair value; Illiquid market; Kalman filter; Mark to model"",""ICO; Crypto-asset; Blockchain; Governance; Tokens; Fair value; Illiquid market; Kalman filter; Mark to model""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-03-06T15:53:55Z""
";https://scholar.google.com/scholar?start=230&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093450-178;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;[HTML][HTML] Blockchain for business;RP George, BL Peterson, O Yaros, DL Beam… ; Journal of Investment …, 2019  emerald.com;United Kingdom;"… Each node may participate in the process of creating consensus and recording information to

the blockchain. Thus, it is not clear which countries have jurisdiction or which law(s) govern …

Oracles. There is a risk that the oracle is incorrect, inaccurate, or ambiguous …";Cité 15 fois;Les 3 versions;[HTML] emerald.com;https://www.emerald.com/insight/content/doi/10.1108/joic-01-2019-0001/full/html?casa_token=eJ7DKaJc0D4AAAAA:W4ixB0TYTFY6dIOPUhRAkhtMHkoppiz1glahlt8VqhXp0FUmtzx1qc4XTNp5n48wqA11hZ50SgwJ4IgvboH20Fp3aQt09m35qL-o01FmCxlcFBIAAA;;"""keywords"",""Technology,Supply chain,Payments,Blockchain,Transactions,Digital ledger""
""dc.Title"",""Blockchain for business""
""citation_journal_title"",""Journal of Investment Compliance""
""description"",""Blockchain for business - Author: Rohith P. George, Brad L. Peterson, Oliver Yaros, David L. Beam, Julian M. Dibbell, Riley C. Moore""
""language"",""en""
""title"",""Blockchain for business
 |  Emerald Insight""
""dc.Identifier"",""10.1108/JOIC-01-2019-0001"",""1528-5812"",""JOIC-01-2019-0001.pdf""
""dc.Publisher"",""Emerald Publishing Limited""
""dc.Format"",""text/html""
""dc:title"",""Blockchain for business
 |  Emerald Insight""
""csrf-token"",""srD1d2wvV4ioPSIET06FwgIa4gSoiM76z7WbtaZu""
""Content-Encoding"",""UTF-8""
""dc.Date"",""2019-03-11T00:00:00Z""
""citation_xml_url"",""https://www.emerald.com/insight/content/doi/10.1108/JOIC-01-2019-0001/full/xml""
""dc.Subject"",""Technology,Supply chain,Payments,Blockchain,Transactions,Digital ledger""
""Content-Type"",""text/html; charset=UTF-8""
""dc.Contributor"",""Rohith P. George"",""Brad L. Peterson"",""Oliver Yaros"",""David L. Beam"",""Julian M. Dibbell"",""Riley C. Moore""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""dc.Type"",""article""
""resourceName"",""html""
""X-UA-Compatible"",""IE=edge""
""dc.Language"",""en""
""dc.Description"",""To introduce blockchain in simple terms for business lawyers to be able to spot the right issues and ask the right questions.,This article provides an overview of blockchain, identifies two example use cases, and highlights some of the most pressing legal issues, including issues to address in on-chain programming, off-chain agreements and other issues when determining whether to implement a blockchain solution.,This article concludes that there has been a significant growth in investment and interest in blockchain. Numerous companies across different sectors have developed blockchain proof-of-concepts, with some heading towards production deployments. At this point, commercial blockchain is largely in the pilot or proof-of-concept stage across a wide range of use cases, with payments and supply chain being two of the most promising use cases. This article also identifies possible legal issues associated with blockchain.,Despite the growing interest in blockchain, it is still a novel topic to many business lawyers. It is very important that lawyers are able to identify the right issues and ask the right questions.,Practical guidance from experienced lawyers in the Technology Transactions and Financial Services Regulatory &amp; Enforcement practices.""
""viewport"",""width=device-width, initial-scale=1""
""DCTERMS.bibliographicCitation"",""&ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Ajournal&rft.spage=17&rft.epage=21&rft.volume=20&rft.issue=1""
""dc.Coverage"",""world""
""Content-Language"",""en""
""format-detection"",""telephone=no""
";https://scholar.google.com/scholar?start=10&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093513-441;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;[PDF][PDF] Towards Cross-Blockchain Transaction Verifications;M Sigwart, P Frauenthaler, T Hukkinen, S Schulte ;2019 dsg.tuwien.ac.at;;"… 1]. Therefore, a solution is necessary that supplies enough information to the destination

blockchain so that it can be certain that the transferred amount of tokens has actually been

destroyed on the source blockchain. This information transfer can be done either via oracles …";Cité 1 fois;Les 3 versions;[PDF] tuwien.ac.at;https://www.dsg.tuwien.ac.at/projects/tast/pub/tast-white-paper-6.pdf;;"""date"",""2019-08-31T13:39:34Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2019-08-31T13:39:34Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.19 (TeX Live 2018) kpathsea version 6.3.0""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2019-08-31T13:39:34Z""
""created"",""2019-08-31T13:39:34Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-08-31T13:39:34Z""
""resourceName"",""tast-white-paper-6.pdf""
""Author"",""""
""producer"",""pdfTeX-1.40.19""
""pdf:docinfo:producer"",""pdfTeX-1.40.19""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2019-08-31T13:39:34Z""
""Last-Modified"",""2019-08-31T13:39:34Z""
""dcterms:modified"",""2019-08-31T13:39:34Z""
""title"",""""
""Last-Save-Date"",""2019-08-31T13:39:34Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2019-08-31T13:39:34Z""
""meta:save-date"",""2019-08-31T13:39:34Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.19 (TeX Live 2018) kpathsea version 6.3.0""
""Content-Length"",""342754""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""6""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""3769"",""5098"",""3298"",""513"",""5057"",""711""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-08-31T13:39:34Z""
";https://scholar.google.com/scholar?start=280&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093490-347;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;[PDF][PDF] Blockchain Competition;I Lianos ; … & S. Eich, Regulating Blockchain: Political and Legal …, 2019  ucl.ac.uk;;"… the frenzy of crypto-currencies, initial coin offerings ('ICOs') and other crypto-assets that took … An

Optimistic and a Pessimistic View of the Implications of Blockchain Technology” (2018 … Paper;

Peder Řstbye, “The Adequacy of Competition Policy for Cryptocurrency Markets”, (2017 …";Cité 6 fois;Les 2 versions;[PDF] ucl.ac.uk;https://www.ucl.ac.uk/cles/sites/cles/files/cles_8-2018.pdf;;"""date"",""2018-10-11T08:54:54Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.5""
""xmp:CreatorTool"",""MicrosoftÂŽ Word 2016""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dc:creator"",""Ioannis Lianos""
""language"",""en""
""dcterms:created"",""2018-10-11T08:54:54Z""
""Last-Modified"",""2018-10-11T08:54:54Z""
""dcterms:modified"",""2018-10-11T08:54:54Z""
""dc:format"",""application/pdf; version=1.5""
""Last-Save-Date"",""2018-10-11T08:54:54Z""
""pdf:docinfo:creator_tool"",""MicrosoftÂŽ Word 2016""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2018-10-11T08:54:54Z""
""meta:save-date"",""2018-10-11T08:54:54Z""
""pdf:encrypted"",""false""
""modified"",""2018-10-11T08:54:54Z""
""Content-Length"",""1732905""
""pdf:hasMarkedContent"",""true""
""Content-Type"",""application/pdf""
""pdf:docinfo:creator"",""Ioannis Lianos""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Ioannis Lianos""
""dc:language"",""en-GB""
""meta:author"",""Ioannis Lianos""
""meta:creation-date"",""2018-10-11T08:54:54Z""
""created"",""2018-10-11T08:54:54Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""93""
""Creation-Date"",""2018-10-11T08:54:54Z""
""resourceName"",""cles_8-2018.pdf""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""193"",""460"",""651"",""2831"",""3533"",""4071"",""4124"",""3740"",""3908"",""4240"",""3621"",""3867"",""3804"",""3830"",""3839"",""3904"",""3834"",""3573"",""4041"",""3694"",""3881"",""3411"",""4149"",""3447"",""3677"",""3890"",""3888"",""3346"",""4256"",""4007"",""774"",""2153"",""4007"",""3843"",""3722"",""3675"",""3293"",""2304"",""3218"",""3677"",""3791"",""3698"",""3440"",""3948"",""3843"",""3766"",""3320"",""3764"",""4012"",""3487"",""4008"",""3030"",""2459"",""3804"",""3758"",""3503"",""3651"",""3841"",""3787"",""3717"",""3916"",""3914"",""3615"",""3908"",""3884"",""3306"",""3718"",""3779"",""4634"",""3635"",""4209"",""3690"",""4019"",""3542"",""3506"",""4162"",""3545"",""3175"",""3957"",""4091"",""4559"",""3633"",""3818"",""3992"",""4370"",""3518"",""4075"",""4140"",""3413"",""4364"",""3700"",""3490"",""3246""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""Author"",""Ioannis Lianos""
""producer"",""MicrosoftÂŽ Word 2016""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""MicrosoftÂŽ Word 2016""
""pdf:docinfo:created"",""2018-10-11T08:54:54Z""
";https://scholar.google.com/scholar?start=180&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093469-253;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Blockchain disruption and smart contracts;LW Cong, Z He ; The Review of Financial Studies, 2019  academic.oup.com;United States of America;"… Blockchain, a distributed ledger technology typically managed in a decentralized manner, was

first popularized as the technology behind the cryptocurrency Bitcoin. It has since emerged in

various other forms, often with the ability to store and execute computer programs …";Cité 489 fois;Les 34 versions;[PDF] oup.com;https://academic.oup.com/rfs/article-pdf/32/5/1754/28275179/hhz007.pdf?casa_token=3Aeu_OSQTR0AAAAA:bc4fvTsKGtDg7_a7itw4JnugysiHXLInfzNfAlrajmOXdKk0UqhcFL1EwAedzRLw6xatH8r2U3s;;"""msapplication-config"",""//oup.silverchair-cdn.com/UI/app/img/v-637520497125602725/browserconfig.xml""
""og:image"",""https://oup.silverchair-cdn.com/oup/backfile/Content_public/Journal/rfs/Issue/32/5/5/m_revfin_32_5cover.png?Expires=1681883150&Signature=THt1HxwIxkpfPvv50o1rJskEFjD-vid65ZEOsjALk5i-oXUQvvibW3kopxNtS2RZY5yf5Dageujp9gXBQ2xOXoFo~YGgfkM2VLZ8eqkcCy5ht6fab64PhAoIWrQYp7VMQprgSgRBVgpn9-pV-2ELy0vwvsl8eXqoaDfvKX~T3-6mVaKOLgkZweebsMUwXnIycQd43B-Jo0wbglVTznJ9fI1eskM3vQxB0s6BLKXtnHieji08Ih9isQetReImdXYkdTPCUVFiDO5xmxwlFVNzyF64-cvZO9FY7Wv6I~H0zkk~-DW49i8GREpYK4tMCp97PC1hAVKZrCNFnxAzTaIvWg__&Key-Pair-Id=APKAIE5G5CRDK6RD3PGA""
""citation_publication_date"",""2019/05/01""
""theme-color"",""#002f65""
""citation_author_institution"",""Booth School of Business, University of Chicago"",""Booth School of Business, University of Chicago Booth School and NBER""
""citation_title"",""Blockchain Disruption and Smart Contracts""
""og:site_name"",""OUP Academic""
""citation_reference"",""citation_title=Blockchain economics; citation_author=Abadi,  J.; citation_author=Brunnermeier  M.;  citation_year=2018; "",""citation_title=Maersk and IBM want 10 million shipping containers on the global supply blockchain by year-end; citation_author=Allison,  I.;  citation_journal_title=International Business Times;  citation_year=2017; "",""citation_title=Optimal collusion with private information; citation_author=Athey,  S.; citation_author=Bagwell  K.;  citation_journal_title=RAND Journal of Economics;  citation_year=2001;  citation_volume=32;  citation_pages=428-65; "",""citation_title=Footprints on the Blockchain: Trading and Information Leakage in Distributed Ledgers; citation_author=Aune,  R. T.; citation_author=O’Hara  M.; citation_author=Slama  O.;  citation_journal_title=Journal of Trading;  citation_year=2017;  citation_volume=12;  citation_pages=5-13; "",""citation_title=Regulating a monopolist with unknown costs; citation_author=Baron,  D. P.; citation_author=Myerson  R. B.;  citation_journal_title=Econometrica;  citation_year=1982;  citation_volume=50;  citation_pages=911-30; "",""citation_title=An empirical analysis of smart contracts: Platforms, applications, and design patterns; citation_author=Bartoletti,  M.; citation_author=Pompianu  L.; citation_author=Brenner,  M.; citation_author=Rohloff,  K.; citation_author=Bonneau,  J.; citation_author=Miller,  A.; citation_author=Ryan,  P. Y.; citation_author=Teague,  V.; citation_author=Bracciali,  A.; citation_author=Sala,  M.; citation_author=Pintore,  F.; citation_author=Jakobsson,  M.; citation_publisher=Springer International Publishing, Cham, UK;  citation_title=Financial cryptography and data security;  citation_year=2017;  citation_pages=494-509; "",""citation_title=Markets transparency and the corporate bond market; citation_author=Bessembinder,  H.; citation_author=Maxwell  W.;  citation_journal_title=Journal of Economic Perspectives;  citation_year=2008;  citation_volume=22;  citation_pages=217-34; "",""citation_title=The blockchain folk theorem; citation_author=Biais,  B.; citation_author=Bisière  C.; citation_author=Bouvard  M.; citation_author=Casamatta  C.;  citation_journal_title=Review of Financial Studies;  citation_year=2019;  citation_volume=32;  citation_pages=1662-715; "",""citation_title=UPS-backed blockchain consortium seeks to disrupt the freight and logistics industry; citation_author=BlockchainNews;  citation_journal_title=CCN;  citation_year=2017; "",""citation_title=Market transparency: who wins and who loses?; citation_author=Bloomfield,  R.; citation_author=O’Hara  M.;  citation_journal_title=Review of Financial Studies;  citation_year=1999;  citation_volume=12;  citation_pages=5-35; "",""citation_title=Bitcoin: Economics, technology, and governance; citation_author=Böhme,  R.; citation_author=Christin  N.; citation_author=Edelman  B.; citation_author=Moore  T.;  citation_journal_title=Journal of Economic Perspectives;  citation_year=2015;  citation_volume=29;  citation_pages=213-38; "",""citation_title=Naughty firms, noisy disclosure; citation_author=Bourveau,  T.; citation_author=She  G.; citation_author=Zaldokas  A.;  citation_year=2017; "",""citation_title=Ethereum: A next-generation smart contract and decentralized application platform; citation_author=Buterin,  V.;  citation_year=2014; "",""citation_title=Auditing and blockchains: Pricing, misstatements, and regulation; citation_author=Cao,  S.; citation_author=Cong  L. W.; citation_author=Yang  B.;  citation_year=2018; "",""citation_title=Project Jasper: Are distributed wholesale payment systems feasible yet; citation_author=Chapman,  J.; citation_author=Garratt  R.; citation_author=Hendry  S.; citation_author=McCormack  A.; citation_author=McMahon  W.;  citation_year=2017; "",""citation_title=Blockchain-based settlement for asset trading; citation_author=Chiu,  J.; citation_author=Koeppl  T.;  citation_journal_title=Review of Financial Studies;  citation_year=2019;  citation_volume=32;  citation_pages=1716-53; "",""citation_title=Auctions of real options; citation_author=Cong,  L. W.;  citation_year=2017; "",""citation_title=Decentralized mining in centralized pools; citation_author=Cong,  L. W.; citation_author=He  Z.; citation_author=Li  J.;  citation_year=2018a; "",""citation_author=Cong,  L. W.; citation_author=Li  Y.; citation_author=Wang  N.; citation_publisher=Dynamic adoption and valuation, Tokenomics;  citation_year=2018b; "",""citation_title=Token-based corporate finance; citation_author=Cong,  L. W.; citation_author=Li  Y.; citation_author=Wang  N.;  citation_year=2018c; "",""citation_title=Distributed ledger technical research in Central Bank of Brazil; citation_author=de Vilaca Burgos,  A.; citation_author=de Oliveira Filho  J. D.; citation_author=Suares  M. V. C.; citation_author=de Almeida  R. S.;  citation_year=2017; "",""citation_title=A liquidity-based model of security design; citation_author=DeMarzo,  P.; citation_author=Duffie  D.;  citation_journal_title=Econometrica;  citation_year=1999;  citation_volume=67;  citation_pages=65-99; "",""citation_title=Bidding with Securities: Auctions and Security Design; citation_author=DeMarzo,  P.; citation_author=Kremer  I.; citation_author=Skrzypacz  A.;  citation_journal_title=American Economic Review;  citation_year=2005;  citation_volume=95;  citation_pages=936-59; "",""citation_title=From mining to markets: The evolution of bitcoin transaction fees; citation_author=Easley,  D.; citation_author=O’Hara  M.; citation_author=Basu  S.;  citation_year=2017; "",""citation_title=The trust machine;  citation_year=2015; "",""citation_title=A yen for plastic;  citation_year=2017; "",""citation_title=Majority is not enough: Bitcoin mining is vulnerable; citation_author=Eyal,  I.; citation_author=Sirer  E. G.; citation_publisher=Springer, New York;  citation_title=International Conference on Financial Cryptography and Data Security;  citation_year=2014;  citation_pages=436-54; "",""citation_title=The folk theorem in repeated games with discounting or with incomplete information; citation_author=Fudenberg,  D.; citation_author=Maskin  E.;  citation_journal_title=Econometrica;  citation_year=1986;  citation_volume=54;  citation_pages=533-54; "",""citation_title=Marc Andreessen: In 20 years, well talk about Bitcoin like we talk about the Internet today; citation_author=Fung,  B.;  citation_journal_title=Washington Post,;  citation_year=2014; "",""citation_title=‘Not there yet’: Bank of Canada experiments with blockchain wholesale payment system; citation_author=Gillis,  M.; citation_author=Trusca  A.;  citation_journal_title=CyberLex,;  citation_year=2017; "",""citation_title=Transparency and liquidity: A controlled experiment on corporate bonds; citation_author=Goldstein,  M. A.; citation_author=Hotchkiss  E. S.; citation_author=Sirri  E. R.;  citation_journal_title=Review of Financial Studies;  citation_year=2006;  citation_volume=20;  citation_pages=235-73; "",""citation_title=Noncooperative collusion under imperfect price information; citation_author=Green,  E. J.; citation_author=Porter  R. H.;  citation_journal_title=Econometrica;  citation_year=1984;  citation_volume=56;  citation_pages=87-100; "",""citation_title=How to time-stamp a digital document; citation_author=Haber,  S.; citation_author=Stornetta  W. S.; citation_publisher=Springer, New York;  citation_title=Conference on the Theory and Application of Cryptography;  citation_year=1990;  citation_pages=437-55; "",""citation_title=Maersk and Microsoft tested a blockchain for shipping insurance; citation_author=Hackett,  R.;  citation_journal_title=Fortune Finance,;  citation_year=2017; "",""citation_author=Hart,  O.; citation_publisher=Clarendon Press, London;  citation_title=Firms, contracts, and financial structure;  citation_year=1995; "",""citation_title=Incomplete contracts and renegotiation; citation_author=Hart,  O.; citation_author=Moore  J.;  citation_journal_title=Econometrica;  citation_year=1988;  citation_volume=56;  citation_pages=755-85; "",""citation_title=Debt and seniority: An analysis of the role of hard claims in constraining management; citation_author=Hart,  O.; citation_author=Moore  J.;  citation_journal_title=American Economic Review;  citation_year=1995;  citation_volume=85;  citation_pages=567-85; "",""citation_title=Cryptofinance; citation_author=Harvey,  C. R.; citation_publisher=Working Paper, ;  citation_year=2016; "",""citation_title=Maersk and IBM introduce TradeLens blockchain shipping solution; citation_author=Haswell,  H.;  citation_journal_title=IBM News Room,;  citation_year=2018; "",""citation_title=IBM unveils blockchain platform for oil trade finance; citation_author=Higgins,  S.;  citation_journal_title=Coindesk,;  citation_year=2017a; "",""citation_title=Walmart, JD.com back blockchain food tracking effort in China; citation_author=Higgins,  S.;  citation_journal_title=CoinDesk,;  citation_year=2017b; "",""citation_title=Monopoly without a monopolist: An economic analysis of the bitcoin payment system; citation_author=Huberman,  G.; citation_author=Leshno  J. D.; citation_author=Moallemi  C. C.;  citation_year=2017; "",""citation_title=Limited liability and incentive contracting with ex-ante action choices; citation_author=Innes,  R. D.;  citation_journal_title=Journal of Economic Theory;  citation_year=1990;  citation_volume=52;  citation_pages=45-67; "",""citation_title=Blockchain is meaningless; citation_author=Jeffries,  A.;  citation_journal_title=Verge,;  citation_year=2018; "",""citation_title=Exposing the ‘if we call it a blockchain, perhaps it won’t be deemed a cartel?’ tactic; citation_author=Kaminska,  I.;  citation_journal_title=Financial Times,;  citation_year=2015; "",""citation_title=How fast should trades settle; citation_author=Khapko,  M.; citation_author=Zoican  M.;  citation_year=2018; "",""citation_author=Krishna,  V.; citation_publisher=Academic Press, Hoboken, NJ;  citation_title=Auction theory;  citation_year=2009; "",""citation_title=The economics of Bitcoin mining, or Bitcoin in the presence of adversaries; citation_author=Kroll,  J. A.; citation_author=Davey  I. C.; citation_author=Felten  E. W.;  citation_journal_title=Proceedings of WEIS;  citation_year=2013;  citation_volume=2013; "",""citation_title=Smart Contracts–How will blockchain technology affect contractual practices? Technical Report, The Research Institute of the Finnish Economy; citation_author=Lauslahti,  K.; citation_author=Mattila,  J.; citation_author=Seppälä,  T.;  citation_year=2016; "",""citation_title=Market Design for Trading with Blockchain Technology; citation_author=Malinova,  K.; citation_author=Park  A.;  citation_year=2018; "",""citation_title=Robust collusion with private information; citation_author=Miller,  D. A.;  citation_journal_title=Review of Economic Studies;  citation_year=2011;  citation_volume=79;  citation_pages=778-811; "",""citation_title=Bitcoin: A peer-to-peer electronic cash system; citation_author=Nakamoto,  S.;  citation_year=2008; "",""citation_author=Narayanan,  A.; citation_author=Bonneau  J.; citation_author=Felten  E.; citation_author=Miller  A.; citation_author=Goldfeder  S.; citation_publisher=Princeton University Press, Princeton, NJ;  citation_title=Bitcoin and cryptocurrency technologies;  citation_year=2016; "",""citation_title=Bitcoin’s academic pedigree; citation_author=Narayanan,  A.; citation_author=Clark  J.;  citation_journal_title=Communications of the ACM;  citation_year=2017;  citation_volume=60;  citation_pages=36-45; "",""citation_title=Stubborn mining: Generalizing selfish mining and combining with an eclipse attack; citation_author=Nayak,  K.; citation_author=Kumar  S.; citation_author=Miller  A.; citation_author=Shi  E.; citation_publisher=IEEE, Piscataway, NJ;  citation_title=Security and Privacy (EuroS&P), 2016 IEEE European Symposium;  citation_year=2016;  citation_pages=305-20; "",""citation_title=R3 pilots blockchain trade finance platform with global banks; citation_author=Palmer,  D.;  citation_journal_title=Coindesk,;  citation_year=2018; "",""citation_title=Optimal cartel trigger price strategies; citation_author=Porter,  R. H.;  citation_journal_title=Journal of Economic Theory;  citation_year=1983;  citation_volume=29;  citation_pages=313-38; "",""citation_title=Why Nasdaq is even more optimistic about blockchain than it was 3 years ago; citation_author=Shin,  L.;  citation_journal_title=Forbes,;  citation_year=2017; "",""citation_title=Ten years in, nobody has come up with a use for blockchain; citation_author=Stinchcombe,  K.;  citation_journal_title=Hackernoon,;  citation_year=2017; "",""citation_title=Formalizing and securing relationships on public networks; citation_author=Szabo,  N.;  citation_journal_title=First Monday;  citation_year=1997;  citation_pages=2"",""citation_title=Secure property titles with owner authority; citation_author=Szabo,  N.;  citation_year=1998; "",""citation_author=Tapscott,  D.; citation_author=Tapscott  A.; citation_publisher=Penguin, New York;  citation_title=Blockchain revolution: How the technology behind Bitcoin is changing money, business, and the world;  citation_year=2016; "",""citation_title=Ornua involved in groundbreaking blockchain transaction; citation_author=Taylor,  C.;  citation_journal_title=Irish Times,;  citation_year=2016; "",""citation_title=Credit Suisse-led blockchain solution makes progress; citation_author=Terekhova,  M.;  citation_journal_title=Business Insider,;  citation_year=2017; "",""citation_title=Blockchain and the future of optimal financing contracts; citation_author=Tinn,  K.;  citation_year=2018; "",""citation_author=Tirole,  J.; citation_publisher=MIT Press, Cambridge;  citation_title=The theory of industrial organization;  citation_year=1988; "",""citation_title=Incomplete contracts: Where do we stand?; citation_author=Tirole,  J.;  citation_journal_title=Econometrica;  citation_year=1999;  citation_volume=67;  citation_pages=741-81; "",""citation_title=On computable numbers, with an application to the Entscheidungsproblem; citation_author=Turing,  A. M.;  citation_journal_title=Proceedings of the London Mathematical Society;  citation_year=1937;  citation_volume=2;  citation_pages=230-65; "",""citation_title=Bitfury: Blockchain for government; citation_author=Weiss,  M.; citation_author=Corsi  E.;  citation_journal_title=HBS Case Study;  citation_year=2017;  citation_volume=12;  citation_pages=818-031; "",""citation_title=Corporate governance and blockchains; citation_author=Yermack,  D.;  citation_journal_title=Review of Finance;  citation_year=2017;  citation_volume=21;  citation_pages=7-31; "",""citation_title=Keepers—Workers that maintain blockchain networks; citation_author=Zurrer,  R.;  citation_journal_title=Medium,;  citation_year=2017; ""
""citation_publisher"",""Oxford Academic""
""citation_journal_title"",""The Review of Financial Studies""
""description"",""Abstract. Blockchain technology provides decentralized consensus and potentially enlarges the contracting space through smart contracts. Meanwhile, generating d""
""language"",""en""
""title"",""Blockchain Disruption and Smart Contracts | The Review of Financial Studies | Oxford Academic""
""og:description"",""Abstract. Blockchain technology provides decentralized consensus and potentially enlarges the contracting space through smart contracts. Meanwhile, generating d""
""citation_issn"",""0893-9454""
""dc:title"",""Blockchain Disruption and Smart Contracts | The Review of Financial Studies | Oxford Academic""
""Content-Encoding"",""UTF-8""
""Content-Type-Hint"",""text/html; charset=utf-8""
""citation_pdf_url"",""https://academic.oup.com/rfs/article-pdf/32/5/1754/28275179/hhz007.pdf""
""Content-Length"",""121633""
""citation_xml_url"",""https://academic.oup.com/rfs/article-xml/32/5/1754/5427778""
""citation_lastpage"",""1797""
""Content-Type"",""text/html; charset=UTF-8""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""og:type"",""article""
""citation_journal_abbrev"",""Rev Financ Stud""
""og:title"",""Blockchain Disruption and Smart Contracts""
""citation_author"",""Cong, Lin William"",""He, Zhiguo""
""resourceName"",""hhz007.pdf""
""og:updated_time"",""2019-04-04""
""citation_issue"",""5""
""X-UA-Compatible"",""IE=Edge""
""citation_firstpage"",""1754""
""viewport"",""width=device-width, initial-scale=1, maximum-scale=1""
""citation_doi"",""10.1093/rfs/hhz007""
""citation_volume"",""32""
""og:url"",""https://academic.oup.com/rfs/article/32/5/1754/5427778""
""Content-Language"",""en""
""format-detection"",""telephone=no""
";https://scholar.google.com/scholar?start=90&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093516-455;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;[PDF][PDF] Blockchain and Trade Finance: A Smart Contract-Based Solution;A Blum ; wwz.unibas.ch;;"… 29 4.3 Oracles … The successful miner who adds a block to the blockchain

network obtains a reward, usually cryptocurrency or a transaction fees, de-

pending on the blockchain protocol. 2.1 Ethereum Blockchain …";Autres articles;Version HTML;[PDF] unibas.ch;https://wwz.unibas.ch/fileadmin/user_upload/wwz/00_Professuren/Schaer_DLTFintech/Lehre/Blum_2019.pdf;;;https://scholar.google.com/scholar?start=290&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093536-543;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Who is Liable for Collusion in Cryptocurrency Protocol Development?;P Řstbye ; Available at SSRN 3354868, 2019  papers.ssrn.com;;"… Such information can be provided by oracles, and the information provided by oracles must be

subject to incentive … 48See Blockchain Luxemburg (2018). 8 … An example is MakerDAO, with the

native cryptocurrency Dai pegged to US dollar and backed with Ether.50Algorithmic …";Cité 1 fois;;null;;;;https://scholar.google.com/scholar?start=380&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093485-324;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;The impact of blockchain technologies and smart contracts on dispute resolution: arbitration and court litigation at the crossroads;P Ortolani ; Uniform law review, 2019  academic.oup.com;;"… The mechanism of oracles can be readily applied to arbitration; a smart contract can defer to

the decision … the smart contract (on the basis of the information provided by the anti-competitive

award oracle) be paid … Tokens are, in essence, digital assets registered on a blockchain …";Cité 12 fois;Les 6 versions;[PDF] oup.com;https://academic.oup.com/ulr/article-pdf/24/2/430/32905092/unz017.pdf;;"""date"",""2021-04-28T10:16:18Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.3""
""xmp:CreatorTool"",""3B2 Total Publishing System 8.07r/W""
""pdf:docinfo:title"",""OP-UNIF190020 430..448""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dcterms:created"",""2020-03-11T13:06:35Z""
""language"",""en""
""Last-Modified"",""2021-04-28T10:16:18Z""
""dcterms:modified"",""2021-04-28T10:16:18Z""
""dc:format"",""application/pdf; version=1.3""
""title"",""OP-UNIF190020 430..448""
""xmpMM:DocumentID"",""uuid:f170f05a-7463-4446-943c-02dc6392c7e0""
""Last-Save-Date"",""2021-04-28T10:16:18Z""
""pdf:docinfo:creator_tool"",""3B2 Total Publishing System 8.07r/W""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2021-04-28T10:16:18Z""
""meta:save-date"",""2021-04-28T10:16:18Z""
""pdf:encrypted"",""false""
""dc:title"",""OP-UNIF190020 430..448""
""xmp:CreateDate"",""2020-03-11T18:36:35Z""
""modified"",""2021-04-28T10:16:18Z""
""Content-Length"",""228778""
""pdf:hasMarkedContent"",""false""
""Content-Type"",""application/pdf""
""xmp:ModifyDate"",""2021-04-28T10:16:18Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""pdf:producer"",""Acrobat Distiller 8.0.0 (Windows); modified using iTextSharp 4.1.6 by 1T3XT""
""meta:creation-date"",""2020-03-11T13:06:35Z""
""created"",""2020-03-11T13:06:35Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""19""
""Creation-Date"",""2020-03-11T13:06:35Z""
""resourceName"",""unz017.pdf""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""2483"",""2979"",""3503"",""3797"",""2717"",""2992"",""3545"",""3188"",""3132"",""3276"",""2997"",""3443"",""2725"",""3022"",""2544"",""3129"",""3033"",""2700"",""3018""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""producer"",""Acrobat Distiller 8.0.0 (Windows); modified using iTextSharp 4.1.6 by 1T3XT""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""Acrobat Distiller 8.0.0 (Windows); modified using iTextSharp 4.1.6 by 1T3XT""
""pdf:docinfo:created"",""2020-03-11T13:06:35Z""
";https://scholar.google.com/scholar?start=160&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093490-342;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;New blockchain-based architecture for service interoperations in internet of things;W Viriyasitavat, L Da Xu, Z Bi… ; IEEE Transactions on …, 2019  ieeexplore.ieee.org;;"… BCT in artificial intelligence were privacy, smart contract security, trusts oracles, scalability,

interoperability … A. Definition A blockchain consists of distributed shared ledgers that chain data

blocks into specific data structures [9]. The most successful BCT is cryptocurrency that has …";Cité 40 fois;Les 2 versions;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/6570650/8792216/08764459.pdf?casa_token=gr-COO27Uu0AAAAA:G6UNJ5PXY4N4Ez0o3T3tXdeeXGw-y3c2HfDLkdxAqqygOtpUyVW3KDgU89PVO5C8KPIhSV2YbRE;;"""og:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""twitter:title"",""New Blockchain-Based Architecture for Service Interoperations in Internet of Things""
""twitter:card"",""summary""
""Description"",""Internet of Things (IoT) is able to integrate the computation and physical processes as services in the social world. The number of services at the edge of IoT ""
""og:title"",""New Blockchain-Based Architecture for Service Interoperations in Internet of Things""
""resourceName"",""08764459.pdf""
""language"",""en""
""title"",""New Blockchain-Based Architecture for Service Interoperations in Internet of Things | IEEE Journals & Magazine | IEEE Xplore""
""og:description"",""Internet of Things (IoT) is able to integrate the computation and physical processes as services in the social world. The number of services at the edge of IoT is rising rapidly due to the prevalent uses of smart devices and cyber-physical systems (CPSs). To explore the promising applications of IoT services, one of the challenges is to enable the interoperability of the services in a decentralized environment. The blockchain technology (BCT) has been proven as a promising solution to establish the trust of data and call for executions; theoretically, it can be used to support the interoperability of services. BCT verifies data or a process and stores it as a transaction in a distributed ledger. Similar to the topology to IoT, applying BCT at the edges of the network exhibits the distributed characteristic. However, currently, BCT is still facing the challenges for interoperability due to a number of factors such as consensus protocols, block sizes, and interval of blocks. Prominent protocols such as proof-of-work (PoW) may cause excessive delays in finality settlement. One promising protocol Practical Byzantine Fault Tolerant offers a fast finality settlement and uses hyperledger to support the scalability; however, the trust might also be a concern if the validators are chosen improperly. This paper discusses the interoperability of IoT services and the challenges and proposes an architecture solution by integrating BCT, service-oriented architecture (SoA), and enablers of key performance indicators (KPIs) and service selections. The proposed architecture aims to solve both interoperability and trust issues for IoT services. The feasibility of the proposed method is validated by the examples of smart contract implementations.""
""twitter:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-UA-Compatible"",""IE=Edge""
""viewport"",""width=device-width, initial-scale=1.0""
""dc:title"",""New Blockchain-Based Architecture for Service Interoperations in Internet of Things | IEEE Journals & Magazine | IEEE Xplore""
""twitter:description"",""Internet of Things (IoT) is able to integrate the computation and physical processes as services in the social world. The number of services at the edge of IoT is rising rapidly due to the prevalent uses of smart devices and cyber-physical systems (CPSs). To explore the promising applications of IoT services, one of the challenges is to enable the interoperability of the services in a decentralized environment. The blockchain technology (BCT) has been proven as a promising solution to establish the trust of data and call for executions; theoretically, it can be used to support the interoperability of services. BCT verifies data or a process and stores it as a transaction in a distributed ledger. Similar to the topology to IoT, applying BCT at the edges of the network exhibits the distributed characteristic. However, currently, BCT is still facing the challenges for interoperability due to a number of factors such as consensus protocols, block sizes, and interval of blocks. Prominent protocols such as proof-of-work (PoW) may cause excessive delays in finality settlement. One promising protocol Practical Byzantine Fault Tolerant offers a fast finality settlement and uses hyperledger to support the scalability; however, the trust might also be a concern if the validators are chosen improperly. This paper discusses the interoperability of IoT services and the challenges and proposes an architecture solution by integrating BCT, service-oriented architecture (SoA), and enablers of key performance indicators (KPIs) and service selections. The proposed architecture aims to solve both interoperability and trust issues for IoT services. The feasibility of the proposed method is validated by the examples of smart contract implementations.""
""Content-Encoding"",""UTF-8""
""Content-Type-Hint"",""text/html; charset=utf-8""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=180&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093483-313;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Consortium blockchain based data aggregation and regulation mechanism for smart grid;M Fan, X Zhang ; IEEE Access, 2019  ieeexplore.ieee.org;;"… Consortium Blockchain Based Data Aggregation and Regulation Mechanism for Smart Grid … In

the process of regulation, the control center, the grid operator, and the equipment supplier receive

fixed-height blocks from the blockchain and obtain plaintext from the decryption …";Cité 32 fois;;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/6287639/8600701/08667824.pdf;;"""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""dc:title"",""IEEE Xplore Full-Text PDF:""
""Content-Encoding"",""UTF-8""
""resourceName"",""08667824.pdf""
""language"",""es""
""Content-Length"",""2565""
""title"",""IEEE Xplore Full-Text PDF:""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=150&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093478-296;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Blockchain support for collaborative business processes;C Di Ciccio, A Cecconi, M Dumas… ; Informatik …, 2019  Springer;;"… the first “killer application” of the blockchain, starting with fungible assets like cryptocurrency

(Bitcoin, Ether … Therefore, up- dates on their status should be notified within the blockchain space,

and commands … To that extent, the role of in-bound and out-bound oracles seem promi …";Cité 32 fois;Les 14 versions;[PDF] springer.com;https://link.springer.com/content/pdf/10.1007/s00287-019-01178-x.pdf;;;https://scholar.google.com/scholar?start=130&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093530-514;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;Atomic loans: Cryptocurrency debt instruments;M Black, TW Liu, T Cai ; arXiv preprint arXiv:1901.05117, 2019  arxiv.org;;"… bitcoin.org/bitcoin.pdf [2] Blockchain and Consensus from Proofs of Work without Random Oracles

(2017, Aug 9 … from https://www.ccn.com/ the-dangerous-threat-of-centralization-that-exists-in-the-

blockchain-ecosystem/ [4 … Crypto Derivatives, Lending, and a touch of Stablecoin …";Cité 4 fois;Les 2 versions;[PDF] arxiv.org;https://arxiv.org/pdf/1901.05117;;"""date"",""2019-01-17T02:00:35Z""
""pdf:PDFVersion"",""1.4""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.4""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""xmp:CreateDate"",""2019-01-16T21:00:35Z""
""modified"",""2019-01-17T02:00:35Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""xmp:ModifyDate"",""2019-01-16T21:00:35Z""
""pdf:docinfo:creator"",""""
""meta:author"",""""
""meta:creation-date"",""2019-01-17T02:00:35Z""
""created"",""2019-01-17T02:00:35Z""
""xmp:About"",""uuid:3a42cc28-5218-11f4-0000-38d3c3f89961""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-01-17T02:00:35Z""
""resourceName"",""1901.05117""
""Author"",""""
""producer"",""dvips + GPL Ghostscript GIT PRERELEASE 9.22""
""pdf:docinfo:producer"",""dvips + GPL Ghostscript GIT PRERELEASE 9.22""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2019-01-17T02:00:35Z""
""Last-Modified"",""2019-01-17T02:00:35Z""
""dcterms:modified"",""2019-01-17T02:00:35Z""
""title"",""""
""xmpMM:DocumentID"",""uuid:3a42cc28-5218-11f4-0000-38d3c3f89961""
""Last-Save-Date"",""2019-01-17T02:00:35Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2019-01-17T02:00:35Z""
""meta:save-date"",""2019-01-17T02:00:35Z""
""Content-Length"",""791735""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""13""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""2280"",""2392"",""2114"",""2380"",""2466"",""2720"",""1485"",""2242"",""1510"",""2142"",""36"",""22"",""32""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-01-17T02:00:35Z""
";https://scholar.google.com/scholar?start=350&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093476-283;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;[PDF][PDF] Honeycomb: An ecosystem hub for decentralized oracle networks;B Benligiray, D Connor, A Tate, H Vänttinen ;2019 raw.githubusercontent.com;;"… Once all nodes agree to the job, the finalized service level agreement gets pushed to the

blockchain … 14 Page 16. Honeycomb: An Ecosystem Hub for Decentralized Oracle Networks CLC

Group will run a listing service for Nodarized oracles that serve Honeycomb APIs for free …";Cité 1 fois;;[PDF] githubusercontent.com;https://raw.githubusercontent.com/clc-group/honeycomb-whitepaper/master/honeycomb%20whitepaper.pdf;;"""X-Parsed-By"",""org.apache.tika.parser.EmptyParser""
""resourceName"",""honeycomb%20whitepaper.pdf""
""language"",""""
""Content-Length"",""914516""
""Content-Type"",""application/octet-stream""
";https://scholar.google.com/scholar?start=120&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093485-330;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;A survey on blockchain cybersecurity vulnerabilities and possible countermeasures;H Hasanova, U Baek, M Shin, K Cho… ; International Journal of …, 2019  Wiley Online Library;;"… In contrast, the PoS architecture allows users to buy cryptocurrency as a stake in the blockchain

system proportional to their investment, allowing them to participate in block formation as a certifier.

The PoS architecture selects certifiers in a random manner when creating blocks …";Cité 34 fois;Les 6 versions;[PDF] wiley.com;https://onlinelibrary.wiley.com/doi/pdf/10.1002/nem.2060?casa_token=Fe8StNiLeWQAAAAA:yKLTYEUVn4UipqiTJpd573VJ2MbPyHUpIKYMgMlOux5tVZom-Mk4mcJVzj2EFnnff52MH4inLMlA3g;;;https://scholar.google.com/scholar?start=160&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093459-213;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;[HTML][HTML] A blockchain-based certificateless public key signature scheme for vehicle-to-infrastructure communication in VANETs;I Ali, M Gervais, E Ahene, F Li ; Journal of Systems Architecture, 2019  Elsevier;;"… provable security under the random oracle model. 3. An overview on blockchain technology.

The blockchain technology was first introduced by Satoshi Nakamoto as the primary technology

behind bitcoin protocol [41]. Bitcoin is called a first digital currency or crypto-currency or …";Cité 27 fois;Les 2 versions;[HTML] sciencedirect.com;https://www.sciencedirect.com/science/article/pii/S1383762119302103?casa_token=7va4ZtPm05cAAAAA:Mg0ux-0bqUS59ZAYMsXDkWpiHkk8VPWoT_sDlOG7Qar-GcV1DJNMQUkiJP6gNF6W2z7A9O-u;;;https://scholar.google.com/scholar?start=50&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093450-171;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;[PDF][PDF] Integration of a Secure Physical Element as a Trusted Oracle in a Hyperledger Blockchain.;A Schaad, T Reski, O Winzenried ; ICETE (2), 2019  researchgate.net;;"Blockchain frameworks enable the immutable storage of data. A still open practical question 
is the so called “oracle” problem, ie the way how real world data is actually transferred into 
and out of a blockchain while preserving its integrity. We present a case study that …";Cité 7 fois;Les 3 versions;[PDF] researchgate.net;https://www.researchgate.net/profile/Tobias_Reski2/publication/335167358_Integration_of_a_Secure_Physical_Element_as_a_Trusted_Oracle_in_a_Hyperledger_Blockchain/links/5d569ce5299bf151bad77066/Integration-of-a-Secure-Physical-Element-as-a-Trusted-Oracle-in-a-Hyperledger-Blockchain.pdf;;;https://scholar.google.com/scholar?start=10&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093532-525;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;[PDF][PDF] Towards Cross-Blockchain Transaction Verifications;M Sigwart, P Frauenthaler, T Hukkinen, S Schulte ;2019 dsg.tuwien.ac.at;;"… 1]. Therefore, a solution is necessary that supplies enough information to the destination

blockchain so that it can be certain that the transferred amount of tokens has actually been

destroyed on the source blockchain. This information transfer can be done either via oracles …";Cité 1 fois;Les 3 versions;[PDF] tuwien.ac.at;https://www.dsg.tuwien.ac.at/projects/tast/pub/tast-white-paper-6.pdf;;"""date"",""2019-08-31T13:39:34Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2019-08-31T13:39:34Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.19 (TeX Live 2018) kpathsea version 6.3.0""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2019-08-31T13:39:34Z""
""created"",""2019-08-31T13:39:34Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-08-31T13:39:34Z""
""resourceName"",""tast-white-paper-6.pdf""
""Author"",""""
""producer"",""pdfTeX-1.40.19""
""pdf:docinfo:producer"",""pdfTeX-1.40.19""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2019-08-31T13:39:34Z""
""Last-Modified"",""2019-08-31T13:39:34Z""
""dcterms:modified"",""2019-08-31T13:39:34Z""
""title"",""""
""Last-Save-Date"",""2019-08-31T13:39:34Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2019-08-31T13:39:34Z""
""meta:save-date"",""2019-08-31T13:39:34Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.19 (TeX Live 2018) kpathsea version 6.3.0""
""Content-Length"",""342754""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""6""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""3769"",""5098"",""3298"",""513"",""5057"",""711""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-08-31T13:39:34Z""
";https://scholar.google.com/scholar?start=360&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619093543-572;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2019&as_yhi=2019;[PDF][PDF] Proof of Provision: Improving Blockchain Technology by Cloud Computing.;M Pohl, A Nahhas, S Bosse, K Turowski ; CLOSER, 2019  scitepress.org;;"… Furthermore, it is possible to link the transactions to conditions that are checked by so-called

oracles (eg data feeds … Ouroboros: A Provably Secure Proof-of- Stake Blockchain Protocol. In

Katz, J. and Shacham, H., editors, Advances in Cryptology – Crypto 2017, volume 10401 …";Cité 1 fois;;[PDF] scitepress.org;https://www.scitepress.org/Papers/2019/77656/77656.pdf;;"""date"",""2019-05-24T19:25:40Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2019-05-24T19:25:40Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is MiKTeX-pdfTeX 2.9.6870 (1.40.19)""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2019-05-24T19:25:40Z""
""created"",""2019-05-24T19:25:40Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-05-24T19:25:40Z""
""resourceName"",""77656.pdf""
""Author"",""""
""producer"",""pdfTeX-1.40.19""
""pdf:docinfo:producer"",""pdfTeX-1.40.19""
""pdf:unmappedUnicodeCharsPerPage"",""1"",""0"",""0"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2019-05-24T19:25:40Z""
""Last-Modified"",""2019-05-24T19:25:40Z""
""dcterms:modified"",""2019-05-24T19:25:40Z""
""title"",""""
""Last-Save-Date"",""2019-05-24T19:25:40Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2019-05-24T19:25:40Z""
""meta:save-date"",""2019-05-24T19:25:40Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is MiKTeX-pdfTeX 2.9.6870 (1.40.19)""
""Content-Length"",""274675""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""5""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""3684"",""4077"",""4279"",""4129"",""2057""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-05-24T19:25:40Z""
";https://scholar.google.com/scholar?start=410&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2019&as_yhi=2019
1619095283-1195;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;A study of blockchain oracles;A Beniiche ; arXiv preprint arXiv:2004.07140, 2020  arxiv.org;;"The limitation with smart contracts is that they cannot access external data which might be 
required to control the execution of business logic. Oracles can be used to provide external 
data to smart contracts. An oracle is an interface that delivers data from external data outside …";Cité 9 fois;Les 3 versions;[PDF] arxiv.org;https://arxiv.org/pdf/2004.07140;;"""date"",""2020-07-16T00:28:23Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2020-07-16T00:28:23Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016) kpathsea version 6.2.2""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2020-07-16T00:28:23Z""
""created"",""2020-07-16T00:28:23Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-07-16T00:28:23Z""
""resourceName"",""2004.07140""
""Author"",""""
""producer"",""pdfTeX-1.40.17""
""pdf:docinfo:producer"",""pdfTeX-1.40.17""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2020-07-16T00:28:23Z""
""Last-Modified"",""2020-07-16T00:28:23Z""
""dcterms:modified"",""2020-07-16T00:28:23Z""
""title"",""""
""Last-Save-Date"",""2020-07-16T00:28:23Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2020-07-16T00:28:23Z""
""meta:save-date"",""2020-07-16T00:28:23Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016) kpathsea version 6.2.2""
""Content-Length"",""535046""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""9""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""4392"",""4760"",""5008"",""5353"",""5142"",""3375"",""5190"",""1616"",""4632""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-07-16T00:28:23Z""
";
1619095299-1271;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;The internet of things, artificial intelligence, and blockchain: implementation perspectives;AM Saghiri, KG HamlAbadi, M Vahdati ; … applications of blockchain …, 2020  Springer;;"… Oracle Digital Assistant. Oracle Big Data. Oracle Business Analytics. 4.2 Microsoft Azure … It should

be noted that the codes of smart contracts are stored by the blockchain unit in a blockchain [52] …

Goal. Bitcoin. A well-known cryptocurrency. It is a peer-to-peer electronic cash system …";Cité 2 fois;Les 3 versions;null;;;;https://scholar.google.com/scholar?start=70&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095402-1705;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Revamping real estate document storage with blockchain;AK Anandan, PM Dighe, AD Gaikwad… ; … of Blockchains and …, 2020  inderscienceonline.com;;"… the current situation satisfies the triggering conditions based on the feedback of trusted data feeds

(oracles) and device … has active users with a vast set of miners processing the trades and earning

their crypto reward … Revamping real estate document storage with blockchain …";Les 2 versions;;null;;;;https://scholar.google.com/scholar?start=510&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095302-1275;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;SuSy: a blockchain-agnostic cross-chain asset transfer gateway protocol based on Gravity;A Pupyshev, E Dzhafarov, I Sapranidi… ; arXiv preprint arXiv …, 2020  arxiv.org;;"… solution proposed in this paper. Keywords?: oracles, cross-chain, interoperability,

interchain transfers, gravity protocol Page 2. Introduction Gravity is a blockchain-

agnostic oracle system that supports communication of blockchains …";Les 2 versions;Version HTML;[PDF] arxiv.org;https://arxiv.org/pdf/2008.13515;;"""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.5""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""11""
""resourceName"",""2008.13515""
""language"",""en""
""pdf:hasXMP"",""false""
""dc:format"",""application/pdf; version=1.5""
""pdf:charsPerPage"",""1155"",""2102"",""974"",""1988"",""2019"",""1471"",""1855"",""1511"",""1413"",""1861"",""101""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""producer"",""Skia/PDF m87""
""Content-Length"",""267312""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""Skia/PDF m87""
""pdf:hasMarkedContent"",""false""
""Content-Type"",""application/pdf""
";https://scholar.google.com/scholar?start=80&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095344-1454;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;[PDF][PDF] ENHANCING BUSINESS OPERATIONS USING BLOCKCHAIN TECHNOLOGY IN A TRADE FINANCE DOMAIN;I Abdullahi, A Aliyu, M Muhammad ; researchgate.net;;"… Each of these operations utilize the web application, and the blockchain by providing it with oracles

(smart contract data). Figure 2: Bizledge Use-case diagram … [16] Blockchainhub, ""Blockchain-oracles,""

[Online]. Available: https://blockchainhub.net/blockchainoracles …";Autres articles;Version HTML;[PDF] researchgate.net;https://www.researchgate.net/profile/Musa_Muhammad6/publication/348116083_ENHANCING_BUSINESS_OPERATIONS_USING_BLOCKCHAIN_TECHNOLOGY_IN_A_TRADE_FINANCE_DOMAIN/links/5fef3e9892851c13fedb9006/ENHANCING-BUSINESS-OPERATIONS-USING-BLOCKCHAIN-TECHNOLOGY-IN-A-TRADE-FINANCE-DOMAIN.pdf;;;https://scholar.google.com/scholar?start=260&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095406-1730;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;[CITATION][C] Smart Contracts im Wertschöpfungsnetzwerk. Chancen und Risiken sowie Vor-und Nachteile;T Todd ;2020 GRIN Verlag;;null;Autres articles;;null;;;;https://scholar.google.com/scholar?start=530&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095349-1475;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Methods and Techniques for Privacy Preserving in Blockchain;B Sowmiya, E Poovammal ; 2020 3rd International Conference …, 2020  ieeexplore.ieee.org;;"… With the help of the third party the transaction from different users are mixed together [8]. For

example mixing Quara and BestMixer crypto currency. E. Attribute based signatures … Stanislav

Kruglik [8], Challenges beyond blockchain: scaling, oracles and privacy preserving …";;null;null;;;;https://scholar.google.com/scholar?start=280&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095369-1565;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;[PDF][PDF] THE INTEGRATION OF ERP AND BLOCKCHAIN: DIFFERENCES BETWEEN E-LEDGER AND DISTRIBUTED LEDGER;B? ALKAN ; SOCIAL, HUMAN AND ADMINISTRATIVE SCIENCES …  gecekitapligi.com;;"… infosys. com/oracle/whitepapers/documents/ integrating-blockchain-erp. pdf Banerjee, A.(2018).

Blockchain Technology: Supply Chain Insights from ERP, Advances in Computer, Elsevier.

Doi: 10.1016/ bs. adcom. 2018.03. 007 Bendovschi, AC (2015) …";Autres articles;;[PDF] gecekitapligi.com;https://www.gecekitapligi.com/Webkontrol/uploads/Fck/Social1yayin_1.pdf#page=45;;"""date"",""2020-06-25T11:31:23Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.4""
""xmp:CreatorTool"",""Adobe InDesign 15.0 (Windows)""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""language"",""en""
""dcterms:created"",""2020-06-25T11:31:08Z""
""Last-Modified"",""2020-06-25T11:31:23Z""
""dcterms:modified"",""2020-06-25T11:31:23Z""
""dc:format"",""application/pdf; version=1.4""
""xmpMM:DocumentID"",""xmp.id:1045e7a1-2b24-494c-af34-b9f4345faf86""
""Last-Save-Date"",""2020-06-25T11:31:23Z""
""pdf:docinfo:creator_tool"",""Adobe InDesign 15.0 (Windows)""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2020-06-25T11:31:23Z""
""meta:save-date"",""2020-06-25T11:31:23Z""
""pdf:encrypted"",""false""
""xmp:CreateDate"",""2020-06-25T14:31:08Z""
""modified"",""2020-06-25T11:31:23Z""
""Content-Length"",""6521618""
""pdf:hasMarkedContent"",""false""
""Content-Type"",""application/pdf""
""xmp:ModifyDate"",""2020-06-25T14:31:23Z""
""xmp:MetadataDate"",""2020-06-25T14:31:23Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""dc:language"",""tr""
""pdf:producer"",""Adobe PDF Library 15.0""
""trapped"",""False""
""meta:creation-date"",""2020-06-25T11:31:08Z""
""created"",""2020-06-25T11:31:08Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""403""
""Creation-Date"",""2020-06-25T11:31:08Z""
""resourceName"",""Social1yayin_1.pdf""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""0"",""857"",""113"",""0"",""1396"",""1704"",""581"",""0"",""251"",""0"",""2945"",""2050"",""2672"",""1140"",""2093"",""2029"",""1507"",""2330"",""2710"",""2519"",""2580"",""2614"",""2489"",""2503"",""2513"",""1686"",""237"",""0"",""2910"",""2932"",""2714"",""1642"",""1185"",""1542"",""1655"",""1621"",""2468"",""2601"",""2554"",""2615"",""2414"",""2482"",""2669"",""1732"",""280"",""0"",""2897"",""2256"",""2402"",""1807"",""1647"",""2732"",""2835"",""2737"",""3085"",""1542"",""2949"",""2451"",""1214"",""0"",""443"",""0"",""2965"",""2817"",""3036"",""2944"",""2785"",""2930"",""2195"",""856"",""1194"",""2391"",""203"",""167"",""2819"",""2352"",""2590"",""1503"",""1038"",""1148"",""539"",""0"",""2959"",""2112"",""1853"",""1614"",""2085"",""2207"",""2476"",""694"",""374"",""0"",""2613"",""2699"",""2610"",""2417"",""1844"",""1798"",""1291"",""2274"",""3044"",""2079"",""2194"",""2378"",""1462"",""0"",""192"",""0"",""1878"",""1404"",""2445"",""1850"",""1687"",""2216"",""1969"",""1250"",""2687"",""2659"",""2705"",""2529"",""1914"",""1635"",""2556"",""1236"",""1757"",""1528"",""2334"",""2416"",""2609"",""2445"",""2487"",""2441"",""2591"",""361"",""227"",""0"",""3001"",""2974"",""3084"",""2608"",""3073"",""2823"",""3116"",""2736"",""3032"",""2678"",""1509"",""2081"",""2984"",""1182"",""3093"",""2299"",""1388"",""2378"",""2444"",""2159"",""3065"",""2722"",""2343"",""2428"",""2460"",""966"",""140"",""0"",""2799"",""2680"",""1847"",""2453"",""2007"",""1679"",""2639"",""2482"",""2382"",""2105"",""2462"",""2782"",""2808"",""2863"",""2851"",""2383"",""2490"",""2476"",""646"",""0"",""161"",""0"",""2707"",""2935"",""2967"",""2791"",""2900"",""3010"",""2962"",""2915"",""2968"",""2872"",""2408"",""2324"",""2560"",""342"",""174"",""0"",""2896"",""3020"",""3007"",""3049"",""3037"",""2605"",""2237"",""1926"",""2322"",""2600"",""2875"",""2157"",""2587"",""1"",""240"",""0"",""2937"",""1872"",""1788"",""1745"",""3092"",""787"",""3076"",""1416"",""2004"",""2308"",""2302"",""2300"",""2968"",""2177"",""2370"",""1824"",""3096"",""3060"",""3095"",""2668"",""1913"",""2930"",""3091"",""2293"",""2787"",""1962"",""3022"",""2823"",""2750"",""2444"",""2712"",""2345"",""2551"",""2361"",""1932"",""0"",""200"",""0"",""2845"",""2723"",""3017"",""2633"",""1456"",""2697"",""2570"",""2922"",""2780"",""2298"",""1514"",""1573"",""2735"",""2811"",""2106"",""158"",""353"",""0"",""2745"",""3102"",""765"",""2939"",""2235"",""1912"",""2397"",""2803"",""1483"",""1721"",""1893"",""2398"",""2374"",""1479"",""203"",""0"",""3224"",""3082"",""3011"",""2892"",""3166"",""2769"",""2722"",""2393"",""1458"",""1002"",""913"",""1543"",""2137"",""2352"",""3224"",""3079"",""3010"",""2491"",""2646"",""2677"",""2626"",""2549"",""2591"",""2480"",""2617"",""2527"",""2503"",""1303"",""416"",""0"",""3021"",""2976"",""3022"",""1382"",""1607"",""1736"",""1643"",""1564"",""2210"",""2431"",""2174"",""0"",""370"",""0"",""2696"",""2271"",""3104"",""2222"",""1472"",""526"",""1270"",""1313"",""1949"",""2980"",""1893"",""319"",""1410"",""1238"",""1770"",""2266"",""2186"",""0"",""268"",""0"",""2901"",""2833"",""2725"",""2702"",""1637"",""2548"",""2014"",""1086"",""1343"",""1480"",""2998"",""3189"",""3140"",""3201"",""2893"",""2163"",""2321"",""1788"",""1912"",""2755"",""2681"",""2473"",""2486"",""2158"",""436"",""0"",""3203"",""2816"",""2669"",""2679"",""1991"",""2633"",""2887"",""3112"",""2713"",""3163"",""2015"",""2268"",""1937"",""854"",""1547"",""1689"",""2516"",""2608"",""2557"",""2265"",""2534"",""2363"",""761""
""access_permission:extract_content"",""true""
""xmpMM:DerivedFrom:DocumentID"",""xmp.did:90209ebb-04a9-e54d-a130-d7f2287d4f10""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""xmpMM:DerivedFrom:InstanceID"",""xmp.iid:fea4ecc3-6734-8947-a202-9cf3f153c2b6""
""producer"",""Adobe PDF Library 15.0""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""Adobe PDF Library 15.0""
""pdf:docinfo:created"",""2020-06-25T11:31:08Z""
";https://scholar.google.com/scholar?start=370&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095397-1688;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Categories and Functions of Crypto-Tokens;LW Cong, Y Xiao ; Available at SSRN 3814499, 2020  papers.ssrn.com;;"… that one needs oracles and the Internet of Things (IoTs) to feed signals onto blockchains. The …

permissioned blockchain could achieve greater decentralization once we consider the … Further

empirical studies of crypto assets may go beyond merely documenting stylized …";;null;null;;;;https://scholar.google.com/scholar?start=490&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095381-1621;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Leveraging Federated Learning & Blockchain to counter Adversarial Attacks in Incremental Learning;V R. Kebande, S Alawadi, J Bugeja… ; … Conference on the …, 2020  dl.acm.org;;"… This, guarantees efficient preservation of privacy at the local nodes and the security of data

leveraging blockchain at the same time … Additionally, active learning is tasked with periodically

or randomly allowing the oracle (human) agent at user nodes to query data samples …";Cité 1 fois;;null;;;;https://scholar.google.com/scholar?start=420&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095378-1604;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Blockchain-Based Trusted Achievement Record System Design;B Awaji, E Solaiman, L Marshall ; … of the 5th International Conference on …, 2020  dl.acm.org;;"… While a deterministic contract does not require information from parties external to the

blockchain in order to run, a non-deterministic contract differs in that it depends on information

(called oracles or data feeds) which derives from external sources …";Cité 2 fois;Les 5 versions;[PDF] arxiv.org;https://arxiv.org/pdf/2007.02161;;"""date"",""2020-07-04T18:14:20Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.3""
""pdf:docinfo:title"",""Microsoft Word - Blockchain-Based Trusted Achievement Record System Design.docx""
""xmp:CreatorTool"",""Word""
""Keywords"",""""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""dcterms:created"",""2020-07-04T18:14:20Z""
""language"",""en""
""Last-Modified"",""2020-07-04T18:14:20Z""
""dcterms:modified"",""2020-07-04T18:14:20Z""
""dc:format"",""application/pdf; version=1.3""
""title"",""Microsoft Word - Blockchain-Based Trusted Achievement Record System Design.docx""
""Last-Save-Date"",""2020-07-04T18:14:20Z""
""pdf:docinfo:creator_tool"",""Word""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2020-07-04T18:14:20Z""
""meta:save-date"",""2020-07-04T18:14:20Z""
""pdf:encrypted"",""false""
""dc:title"",""Microsoft Word - Blockchain-Based Trusted Achievement Record System Design.docx""
""modified"",""2020-07-04T18:14:20Z""
""Content-Length"",""535322""
""pdf:hasMarkedContent"",""false""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""dc:subject"",""""
""meta:creation-date"",""2020-07-04T18:14:20Z""
""created"",""2020-07-04T18:14:20Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""6""
""Creation-Date"",""2020-07-04T18:14:20Z""
""resourceName"",""2007.02161""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""5300"",""6896"",""5074"",""2514"",""4604"",""5072""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""meta:keyword"",""""
""producer"",""Mac OS X 10.13.6 Quartz PDFContext""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""Mac OS X 10.13.6 Quartz PDFContext""
""pdf:docinfo:created"",""2020-07-04T18:14:20Z""
";https://scholar.google.com/scholar?start=410&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095311-1317;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;[HTML][HTML] A survey of blockchain consensus algorithms performance evaluation criteria;SMH Bamakan, A Motavali, AB Bondarti ; Expert Systems with Applications, 2020  Elsevier;;"… enlightening future. Although the first application of blockchain technology was Bitcoin

as a cryptocurrency, other applications of this technology have also gained attention

from governmental and industrial sectors. According to …";Cité 27 fois;Les 2 versions;[HTML] sciencedirect.com;https://www.sciencedirect.com/science/article/pii/S0957417420302098?casa_token=9LA0P3hvSKwAAAAA:qCyxqOdOdosRKxlKMjEuNURTfmH_TcF5mx-tdxWj8v2QoE9pzStKgbhnQKGFtLrbmdAQ9yqD;;;https://scholar.google.com/scholar?start=120&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095330-1396;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;[PDF][PDF] SEBF: A Single-Chain based Extension Model of Blockchain for Fintech;Y Ji, W Gu, F Chen, X Xiao, J Sun, S Liu, J He… ; … Ninth International Joint …, 2020  ijcai.org;;"… User Financial terminal Blockchain Node Oracle Machine … P . Processing of Data Returned

by the Oracle Group with the Blockchain Node After receiving o Package , the blockchain

node first verifies the signature of the oracle machine …";Autres articles;;[PDF] ijcai.org;https://www.ijcai.org/Proceedings/2020/0620.pdf;;"""date"",""2020-07-20T10:04:11Z""
""pdf:PDFVersion"",""1.7""
""pdf:docinfo:title"",""SEBF: A Single-Chain based Extension Model of Blockchain for Fintech""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""Proceedings of the Twenty-Ninth International Joint Conference on Artificial Intelligence""
""pdfa:PDFVersion"",""A-2b""
""xmpMM:History:Action"",""converted""
""language"",""en""
""dc:format"",""application/pdf; version=""""A-2b"""""",""application/pdf; version=1.7""
""access_permission:fill_in_form"",""true""
""xmpMM:History:When"",""2020-07-20T10:04:11Z""
""pdf:encrypted"",""false""
""dc:title"",""SEBF: A Single-Chain based Extension Model of Blockchain for Fintech""
""xmp:CreateDate"",""2020-07-20T10:04:09Z""
""modified"",""2020-07-20T10:04:11Z""
""cp:subject"",""Proceedings of the Twenty-Ninth International Joint Conference on Artificial Intelligence""
""xmpMM:History:SoftwareAgent"",""Preflight""
""pdf:docinfo:subject"",""Proceedings of the Twenty-Ninth International Joint Conference on Artificial Intelligence""
""pdf:hasMarkedContent"",""true""
""xmpMM:History:InstanceID"",""uuid:1d8fd6c8-84a3-4b0d-8409-3c57a5b40e90""
""xmp:ModifyDate"",""2020-07-20T10:04:11Z""
""pdf:docinfo:creator"",""Yimu Ji, Weiheng Gu, Fei Chen, Xiaoying Xiao, Jing Sun, Shangdong Liu, Jing He, Yunyao Li, Kaixiang Zhang, Fen Mei, Fei Wu""
""meta:author"",""Yimu Ji"",""Weiheng Gu"",""Fei Chen"",""Xiaoying Xiao"",""Jing Sun"",""Shangdong Liu"",""Jing He"",""Yunyao Li"",""Kaixiang Zhang"",""Fen Mei"",""Fei Wu""
""meta:creation-date"",""2020-07-20T10:04:09Z""
""created"",""2020-07-20T10:04:09Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-07-20T10:04:09Z""
""resourceName"",""0620.pdf""
""pdfaid:part"",""2""
""Author"",""Yimu Ji"",""Weiheng Gu"",""Fei Chen"",""Xiaoying Xiao"",""Jing Sun"",""Shangdong Liu"",""Jing He"",""Yunyao Li"",""Kaixiang Zhang"",""Fen Mei"",""Fei Wu""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""dc:description"",""Paper accepted and presented at IJCAI-PRICAI-2020""
""Keywords"",""AI for lending: AI for blockchain; AI for banking: General"",""AI for lending: AI for blockchain, AI for banking: General""
""access_permission:modify_annotations"",""true""
""dc:creator"",""Yimu Ji"",""Weiheng Gu"",""Fei Chen"",""Xiaoying Xiao"",""Jing Sun"",""Shangdong Liu"",""Jing He"",""Yunyao Li"",""Kaixiang Zhang"",""Fen Mei"",""Fei Wu""
""description"",""Paper accepted and presented at IJCAI-PRICAI-2020""
""dcterms:created"",""2020-07-20T10:04:09Z""
""Last-Modified"",""2020-07-20T10:04:11Z""
""dcterms:modified"",""2020-07-20T10:04:11Z""
""title"",""SEBF: A Single-Chain based Extension Model of Blockchain for Fintech""
""xmpMM:DocumentID"",""uuid:1d8fd6c8-84a3-4b0d-8409-3c57a5b40e90""
""Last-Save-Date"",""2020-07-20T10:04:11Z""
""pdf:docinfo:keywords"",""AI for lending: AI for blockchain, AI for banking: General""
""pdf:docinfo:modified"",""2020-07-20T10:04:11Z""
""meta:save-date"",""2020-07-20T10:04:11Z""
""Content-Length"",""571450""
""Content-Type"",""application/pdf""
""xmp:MetadataDate"",""2020-07-20T10:04:11Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Yimu Ji"",""Weiheng Gu"",""Fei Chen"",""Xiaoying Xiao"",""Jing Sun"",""Shangdong Liu"",""Jing He"",""Yunyao Li"",""Kaixiang Zhang"",""Fen Mei"",""Fei Wu""
""pdfaid:conformance"",""B""
""dc:language"",""EN""
""dc:subject"",""AI for lending: AI for blockchain; AI for banking: General"",""AI for lending: AI for blockchain, AI for banking: General""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""9""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""4331"",""3658"",""3707"",""6103"",""5199"",""4711"",""5991"",""4426"",""4556""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""meta:keyword"",""AI for lending: AI for blockchain; AI for banking: General"",""AI for lending: AI for blockchain, AI for banking: General""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-07-20T10:04:09Z""
";https://scholar.google.com/scholar?start=200&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095351-1492;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Understanding blockchain for insurance use cases;D Popovic, C Avis, M Byrne, C Cheung… ; British Actuarial …, 2020  cambridge.org;;"… Oracles ore often data silos operating in a centralised fashion, creating a single point of … This

introduces a new challenge widely known as the “Oracle Problem”, whereby the execution of …

is one of the major obstacles hindering the mainstream adoption of blockchain and smart …";Autres articles;;[PDF] cambridge.org;https://www.cambridge.org/core/services/aop-cambridge-core/content/view/3F0FBE7A633CE3EAC2CEA0DD98A63286/S1357321720000148a.pdf/div-class-title-understanding-blockchain-for-insurance-use-cases-div.pdf;;"""date"",""2021-04-28T10:17:07Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.3""
""dc:description"",""Downloaded from  https://www.cambridge.org/core. IP address: 83.76.85.89, on 28 Apr 2021 at 10:17:07, subject to the Cambridge Core terms of use, available at https://www.cambridge.org/core/terms.""
""xmp:CreatorTool"",""Arbortext Advanced Print Publisher 9.1.405/W Unicode""
""pdf:docinfo:title"",""Understanding blockchain for insurance use cases""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""description"",""Downloaded from  https://www.cambridge.org/core. IP address: 83.76.85.89, on 28 Apr 2021 at 10:17:07, subject to the Cambridge Core terms of use, available at https://www.cambridge.org/core/terms.""
""dcterms:created"",""2020-06-11T18:46:57Z""
""language"",""en""
""Last-Modified"",""2021-04-28T10:17:07Z""
""dcterms:modified"",""2021-04-28T10:17:07Z""
""dc:format"",""application/pdf; version=1.3""
""title"",""Understanding blockchain for insurance use cases""
""xmpMM:DocumentID"",""uuid:ffab91a3-da2d-4d1d-a709-fc8487a735e3""
""Last-Save-Date"",""2021-04-28T10:17:07Z""
""pdf:docinfo:creator_tool"",""Arbortext Advanced Print Publisher 9.1.405/W Unicode""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2021-04-28T10:17:07Z""
""meta:save-date"",""2021-04-28T10:17:07Z""
""pdf:encrypted"",""false""
""dc:title"",""Understanding blockchain for insurance use cases""
""xmp:CreateDate"",""2020-06-11T14:46:57Z""
""modified"",""2021-04-28T10:17:07Z""
""pdf:hasMarkedContent"",""false""
""Content-Type"",""application/pdf""
""xmp:ModifyDate"",""2021-04-28T10:17:07Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""pdf:producer"",""Acrobat Distiller 10.1.16 (Windows)""
""meta:creation-date"",""2020-06-11T18:46:57Z""
""created"",""2020-06-11T18:46:57Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""23""
""Creation-Date"",""2020-06-11T18:46:57Z""
""resourceName"",""div-class-title-understanding-blockchain-for-insurance-use-cases-div.pdf""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""2947"",""2631"",""2824"",""1973"",""1807"",""1541"",""2803"",""1680"",""2834"",""2803"",""2628"",""3010"",""2840"",""2844"",""2212"",""1487"",""3239"",""3311"",""4025"",""2545"",""3266"",""3149"",""1660""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""producer"",""Acrobat Distiller 10.1.16 (Windows)""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""Acrobat Distiller 10.1.16 (Windows)""
""pdf:docinfo:created"",""2020-06-11T18:46:57Z""
";https://scholar.google.com/scholar?start=290&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095388-1647;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;[PDF][PDF] A PEER-TO-PEER (P2P) AGRICULTURAL INSURANCE APPROACH BASED ON SMART CONTRACTS IN BLOCKCHAIN ETHEREUM;C KEVORCHIAN, C GAVRILESCU, G HURDUZEU ; ipe.ro;;"… An alternative would be that the team can agree on a rule for limiting the payment of the premium

to a given percentage of the volume of cryptocurrency in each member's … Through ChainLink

solutions, as a decentralized Oracles service, external blockchain data services …";Autres articles;Version HTML;[PDF] ipe.ro;ftp://www.ipe.ro/RePEc/iag/iag_pdf/AERD2001_29-45.pdf;;"""date"",""2020-11-12T00:58:04Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""AGRICULTURAL ECONOMICS AND RURAL DEVELOPMENT""
""xmp:CreatorTool"",""MicrosoftÂŽ Word 2010""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""MicrosoftÂŽ Word 2010""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""AGRICULTURAL ECONOMICS AND RURAL DEVELOPMENT""
""xmp:CreateDate"",""2020-11-12T02:57:18Z""
""modified"",""2020-11-12T00:58:04Z""
""pdf:hasMarkedContent"",""true""
""xmp:ModifyDate"",""2020-11-12T02:58:04Z""
""pdf:docinfo:creator"",""***""
""meta:author"",""***""
""meta:creation-date"",""2020-11-12T00:57:18Z""
""created"",""2020-11-12T00:57:18Z""
""xmp:About"",""uuid:2fa4d7c6-1304-45d0-9556-33dfbd0a0a21""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-11-12T00:57:18Z""
""resourceName"",""AERD2001_29-45.pdf""
""Author"",""***""
""producer"",""MicrosoftÂŽ Word 2010""
""pdf:docinfo:producer"",""MicrosoftÂŽ Word 2010""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""access_permission:modify_annotations"",""true""
""dc:creator"",""***""
""dcterms:created"",""2020-11-12T00:57:18Z""
""Last-Modified"",""2020-11-12T00:58:04Z""
""dcterms:modified"",""2020-11-12T00:58:04Z""
""title"",""AGRICULTURAL ECONOMICS AND RURAL DEVELOPMENT""
""xmpMM:DocumentID"",""uuid:2f0beafa-076e-4209-9507-8f65f710c2a3""
""Last-Save-Date"",""2020-11-12T00:58:04Z""
""pdf:docinfo:modified"",""2020-11-12T00:58:04Z""
""meta:save-date"",""2020-11-12T00:58:04Z""
""Content-Length"",""660301""
""Content-Type"",""application/pdf""
""xmp:MetadataDate"",""2020-11-12T02:58:04Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""***""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""17""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""2434"",""3248"",""3328"",""3153"",""2990"",""3410"",""2582"",""2976"",""3461"",""2707"",""3018"",""2253"",""1321"",""2696"",""2163"",""3281"",""2368""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-11-12T00:57:18Z""
";https://scholar.google.com/scholar?start=450&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095376-1599;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Data structures meet cryptography: 3SUM with preprocessing;A Golovnev, S Guo, T Horel, S Park… ; Proceedings of the …, 2020  dl.acm.org;;"… First, we apply Fiat–Naor inversion, a technique with crypto- graphic origins, to obtain a data … For

this reason, [16] considers the problem of combining two random oracles (with two independent …

Instead, we look at the case of a single random oracle but add a restriction on the …";Cité 2 fois;Les 5 versions;[PDF] arxiv.org;https://arxiv.org/pdf/1907.08355;;"""date"",""2019-11-12T01:50:01Z""
""pdf:PDFVersion"",""1.4""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.4""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""xmp:CreateDate"",""2019-11-11T20:50:01Z""
""modified"",""2019-11-12T01:50:01Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""xmp:ModifyDate"",""2019-11-11T20:50:01Z""
""pdf:docinfo:creator"",""""
""meta:author"",""""
""meta:creation-date"",""2019-11-12T01:50:01Z""
""created"",""2019-11-12T01:50:01Z""
""xmp:About"",""uuid:49e54442-3d0b-11f5-0000-ff28cf728d37""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-11-12T01:50:01Z""
""resourceName"",""1907.08355""
""Author"",""""
""producer"",""dvips + GPL Ghostscript GIT PRERELEASE 9.22""
""pdf:docinfo:producer"",""dvips + GPL Ghostscript GIT PRERELEASE 9.22""
""pdf:unmappedUnicodeCharsPerPage"",""1"",""0"",""2"",""10"",""2"",""1"",""0"",""0"",""3"",""3"",""8"",""20"",""7"",""20"",""22"",""8"",""5"",""9"",""14"",""12"",""113"",""48"",""8"",""6"",""6"",""4"",""0"",""0"",""0"",""0"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2019-11-12T01:50:01Z""
""Last-Modified"",""2019-11-12T01:50:01Z""
""dcterms:modified"",""2019-11-12T01:50:01Z""
""title"",""""
""xmpMM:DocumentID"",""uuid:49e54442-3d0b-11f5-0000-ff28cf728d37""
""Last-Save-Date"",""2019-11-12T01:50:01Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2019-11-12T01:50:01Z""
""meta:save-date"",""2019-11-12T01:50:01Z""
""Content-Length"",""434266""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""32""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""1880"",""961"",""3223"",""2665"",""3067"",""3327"",""3208"",""3187"",""2796"",""3018"",""2621"",""2499"",""2929"",""2383"",""1708"",""2010"",""2930"",""2887"",""2669"",""3091"",""1413"",""1660"",""2643"",""2291"",""2699"",""2158"",""2534"",""2273"",""2206"",""2123"",""2088"",""1676""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-11-12T01:50:01Z""
";https://scholar.google.com/scholar?start=400&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095297-1255;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Fully-automated liberalism? Blockchain technology and international cooperation in an anarchic world;B Reinsberg ; International Theory, 2020  cambridge.org;;"… as for example for cryptocurrency transfers, they depend on external information feeds – so-called

'oracles' – to bring the relevant information on the blockchain … smart devices are becoming

increasingly important technical ora- cles.42 Another kind of oracle, facilitated by …";Cité 3 fois;Les 4 versions;[PDF] cambridge.org;https://www.cambridge.org/core/services/aop-cambridge-core/content/view/836EA52CCF5662EF1DDA0422528FB6BA/S1752971920000305a.pdf/fullyautomated_liberalism_blockchain_technology_and_international_cooperation_in_an_anarchic_world.pdf;;"""date"",""2021-04-28T10:17:18Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.3""
""dc:description"",""Downloaded from  https://www.cambridge.org/core. IP address: 83.76.85.89, on 28 Apr 2021 at 10:17:18, subject to the Cambridge Core terms of use, available at https://www.cambridge.org/core/terms.""
""xmp:CreatorTool"",""Arbortext Advanced Print Publisher 10.0.1465/W Unicode""
""pdf:docinfo:title"",""S1752971920000305jra 1..27""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""description"",""Downloaded from  https://www.cambridge.org/core. IP address: 83.76.85.89, on 28 Apr 2021 at 10:17:18, subject to the Cambridge Core terms of use, available at https://www.cambridge.org/core/terms.""
""dcterms:created"",""2020-06-29T09:43:43Z""
""language"",""en""
""Last-Modified"",""2021-04-28T10:17:18Z""
""dcterms:modified"",""2021-04-28T10:17:18Z""
""dc:format"",""application/pdf; version=1.3""
""title"",""S1752971920000305jra 1..27""
""xmpMM:DocumentID"",""uuid:1e4fbbc0-7187-4d02-9b75-f3ce4f13c9cb""
""Last-Save-Date"",""2021-04-28T10:17:18Z""
""pdf:docinfo:creator_tool"",""Arbortext Advanced Print Publisher 10.0.1465/W Unicode""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2021-04-28T10:17:18Z""
""meta:save-date"",""2021-04-28T10:17:18Z""
""pdf:encrypted"",""false""
""dc:title"",""S1752971920000305jra 1..27""
""xmp:CreateDate"",""2020-06-29T15:13:43Z""
""modified"",""2021-04-28T10:17:18Z""
""pdf:hasMarkedContent"",""false""
""Content-Type"",""application/pdf""
""xmp:ModifyDate"",""2021-04-28T10:17:18Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""pdf:producer"",""Acrobat Distiller 8.1.0 (Windows)""
""meta:creation-date"",""2020-06-29T09:43:43Z""
""created"",""2020-06-29T09:43:43Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""27""
""Creation-Date"",""2020-06-29T09:43:43Z""
""resourceName"",""fullyautomated_liberalism_blockchain_technology_and_international_cooperation_in_an_anarchic_world.pdf""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""2781"",""3224"",""3188"",""3088"",""3111"",""3076"",""3619"",""3230"",""3194"",""2856"",""3493"",""2911"",""3248"",""3196"",""3284"",""3501"",""2963"",""3286"",""3164"",""2950"",""3380"",""3184"",""3439"",""4114"",""3909"",""4062"",""2560""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""producer"",""Acrobat Distiller 8.1.0 (Windows)""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""Acrobat Distiller 8.1.0 (Windows)""
""pdf:docinfo:created"",""2020-06-29T09:43:43Z""
";https://scholar.google.com/scholar?start=60&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095397-1684;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Development of a Risk-Based Information Security Standard for Adaption of Blockchain-Enabled Systems;A Biswas, A Adhikary, PK Dutta… ; … Conference on Mobile …, 2020  Springer;;"… A blockchain may have multiple crypto-assets, which need to be validated for assurance …

Blockchain and Currency Valuation. For any kind of currency valuation, external real-world data

will be required, and oracles are an important factor, and hence, enhanced risks and controls …";Autres articles;;[PDF] researchgate.net;https://www.researchgate.net/profile/Disha-Wankhede/publication/347256873_ANALYSIS_AND_PREDICTION_OF_SOIL_NUTRIENTS_PHNPK_FOR_CROP_USING_MACHINE_LEARNING_CLASSIFIER_A_REVIEW/links/5ff881f1a6fdccdcb83ec5ca/ANALYSIS-AND-PREDICTION-OF-SOIL-NUTRIENTS-PHNPK-FOR-CROP-USING-MACHINE-LEARNING-CLASSIFIER-A-REVIEW.pdf#page=607;;;https://scholar.google.com/scholar?start=490&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095378-1605;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Comparison Study of Blockchain Technology and IOTA Technology;LT Khrais ; 2020 Fourth International Conference on ISMAC …, 2020  ieeexplore.ieee.org;;"… The crypto network valued this innovation done by Tangle because this might revolve rapidly …

Features such as smart contracts and Oracles are in the development plan, and these … Tangle

entanglement technology"" in IOTA is more superior as compared to blockchain technology …";Autres articles;;null;;;;https://scholar.google.com/scholar?start=410&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095334-1417;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Decision problems in blockchain governance: Old wine in new bottles or walking in someone else's shoes?;R Ziolkowski, G Miscione… ; Journal of Management …, 2020  Taylor & Francis;;"… cryptocurrencies, which does not pre-exist this phenomenon: the growth of crypto fostered

interactions … There are several ways of increasing data quality in blockchain systems: One

possibility … as observed in our studied cases, (3) assured through so-called oracles [110], which …";Cité 7 fois;Les 2 versions;null;;;;https://scholar.google.com/scholar?start=220&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095292-1237;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Towards Valid Use Cases: Requirements and Supporting Characteristics of Proper Blockchain Applications;U Gallersdörfer, F Matthes ; 2020 Seventh International …, 2020  ieeexplore.ieee.org;;"… system. Also, the user which propose the agree- ment/Smart Contract is a user.

In this use case, we require oracles: If new goods are minded, an oracle has to

create a digital-twin token on the Blockchain. Additionally …";Autres articles;;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/9139910/9143872/09143999.pdf?casa_token=VvDxKI7WnBkAAAAA:gPA_i7WjcRS1HjeUhkDGeuigMBF2T3HK3Vm9UnbdL7GY2rW63PMrM9uAxkz8wQ0fUnrqFFk4XNI;;"""og:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""twitter:title"",""Towards Valid Use Cases: Requirements and Supporting Characteristics of Proper Blockchain Applications""
""twitter:card"",""summary""
""Description"",""Practitioners from various fields discuss potential applications for Blockchain, often, without a clear understanding which class of use cases qualify for this ""
""og:title"",""Towards Valid Use Cases: Requirements and Supporting Characteristics of Proper Blockchain Applications""
""resourceName"",""09143999.pdf""
""language"",""en""
""title"",""Towards Valid Use Cases: Requirements and Supporting Characteristics of Proper Blockchain Applications | IEEE Conference Publication | IEEE Xplore""
""og:description"",""Practitioners from various fields discuss potential applications for Blockchain, often, without a clear understanding which class of use cases qualify for this technology. In this paper, we build a framework for classifying suitable Blockchain use cases. We present requirements (mandatory features of all Blockchain use cases) and supporting characteristics (features which make using Blockchain technology recommendable, if requirements are fulfilled) of possible applications, which we group in the stakeholders and objects “users of the system”, “oracles and information”, “agreement”, and “goods”. We justify our framework by applying it to four use cases from different fields: Proof of Publication, Cryptocurrencies, Lotteries, and Provenance Tracking. Our model can explain why those use cases are a good fit for implementation with Blockchain technology.""
""twitter:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-UA-Compatible"",""IE=Edge""
""viewport"",""width=device-width, initial-scale=1.0""
""dc:title"",""Towards Valid Use Cases: Requirements and Supporting Characteristics of Proper Blockchain Applications | IEEE Conference Publication | IEEE Xplore""
""twitter:description"",""Practitioners from various fields discuss potential applications for Blockchain, often, without a clear understanding which class of use cases qualify for this technology. In this paper, we build a framework for classifying suitable Blockchain use cases. We present requirements (mandatory features of all Blockchain use cases) and supporting characteristics (features which make using Blockchain technology recommendable, if requirements are fulfilled) of possible applications, which we group in the stakeholders and objects “users of the system”, “oracles and information”, “agreement”, and “goods”. We justify our framework by applying it to four use cases from different fields: Proof of Publication, Cryptocurrencies, Lotteries, and Provenance Tracking. Our model can explain why those use cases are a good fit for implementation with Blockchain technology.""
""Content-Encoding"",""UTF-8""
""Content-Type-Hint"",""text/html; charset=utf-8""
""Content-Length"",""40242""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=40&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095320-1360;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;COST: A Consensus-based Oracle Protocol for the Secure Trade of Digital Goods;M Müller, SR Garzon, A Kupper ; 2020 IEEE International …, 2020  ieeexplore.ieee.org;;"… This circumstance illustrates the general problem of having business logic depending on

information, which lives outside the limits of the blockchain. This is described as the oracle problem

[7]. Oracles in the context of distributed ledgers have been studied before [8]. For …";Autres articles;;[PDF] researchgate.net;https://www.researchgate.net/profile/Marcel_Mueller35/publication/342077775_COST_A_Consensus-based_Oracle_Protocol_for_the_Secure_Trade_of_Digital_Goods/links/5ee0e18e92851cf1386f6ae4/COST-A-Consensus-based-Oracle-Protocol-for-the-Secure-Trade-of-Digital-Goods.pdf;;;https://scholar.google.com/scholar?start=160&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095386-1638;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;[PDF][PDF] Cryptocurrency and the African economy;EI Agbo, EO Nwadialor ; … of Cryptocurrency and block chain, 2020  researchgate.net;;"… Consequently, this study urges for greater international cooperation on the adoption of

cryptocurrency, as it reduces the effectiveness of monetary policy at the … Keywords:

Cryptocurrencies, Bitcoin, blockchain, decentralized systems, crypto technologies, Africa …";Cité 1 fois;;[PDF] researchgate.net;https://www.researchgate.net/profile/Agbo_Igwebuike/publication/342927327_CRYPTOCURRENCY_AND_THE_AFRICAN_ECONOMY/links/5f0e2011a6fdcc3ed70805bf/CRYPTOCURRENCY-AND-THE-AFRICAN-ECONOMY.pdf;;;https://scholar.google.com/scholar?start=440&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095297-1261;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Business Process Redesign Heuristics for Blockchain Solutions;F Milani, L García;Bańuelos, HA Reijers…  2020 IEEE 24th …, 2020  ieeexplore.ieee.org;;"… Therefore, trusted parties can be adapted for blockchain-based solutions to consider using

oracles as trusted sources of external data. However, some oracle cannot be fully trusted and

it can be necessary to ensure that the data is complete and correct …";Cité 1 fois;Les 3 versions;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/9233042/9233113/09233248.pdf?casa_token=ROHM-N9OPLUAAAAA:cINpvgxU33i32GZ0Wu-h1FFfojN-cEypPvNXY6zEG4nFQrpdY3FwrZA7v-xWRT-GupSJ0kE6ACc;;"""og:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""twitter:title"",""Business Process Redesign Heuristics for Blockchain Solutions""
""twitter:card"",""summary""
""Description"",""Blockchain has emerged as one of the most promising and revolutionary technologies in the past years. Companies are exploring use cases in the hope of reaping b""
""og:title"",""Business Process Redesign Heuristics for Blockchain Solutions""
""resourceName"",""09233248.pdf""
""language"",""en""
""title"",""Business Process Redesign Heuristics for Blockchain Solutions | IEEE Conference Publication | IEEE Xplore""
""og:description"",""Blockchain has emerged as one of the most promising and revolutionary technologies in the past years. Companies are exploring use cases in the hope of reaping benefits from this technology. However, to achieve the desired impact, it is not sufficient to merely replace existing technologies. Current business processes must be redesigned to realize benefits. This paper shows how a number of best practices for Business Process Redesign can be applied to leverage blockchain technology. Specifically, we adapt these best practices for redesigning processes intended to execute on blockchain. We further explore their applicability using a case study. The major elements of process redesign for blockchain are: (1) changing the view from intra- to inter-organizational processes by using the shared data ledger of blockchain, (2) using smart contracts performers of tasks and connectors of processes, (3) using blockchain as means for data communication, and (4) using tokens to manage digitally represented assets.""
""twitter:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-UA-Compatible"",""IE=Edge""
""viewport"",""width=device-width, initial-scale=1.0""
""dc:title"",""Business Process Redesign Heuristics for Blockchain Solutions | IEEE Conference Publication | IEEE Xplore""
""twitter:description"",""Blockchain has emerged as one of the most promising and revolutionary technologies in the past years. Companies are exploring use cases in the hope of reaping benefits from this technology. However, to achieve the desired impact, it is not sufficient to merely replace existing technologies. Current business processes must be redesigned to realize benefits. This paper shows how a number of best practices for Business Process Redesign can be applied to leverage blockchain technology. Specifically, we adapt these best practices for redesigning processes intended to execute on blockchain. We further explore their applicability using a case study. The major elements of process redesign for blockchain are: (1) changing the view from intra- to inter-organizational processes by using the shared data ledger of blockchain, (2) using smart contracts performers of tasks and connectors of processes, (3) using blockchain as means for data communication, and (4) using tokens to manage digitally represented assets.""
""Content-Encoding"",""UTF-8""
""Content-Type-Hint"",""text/html; charset=utf-8""
""Content-Length"",""41058""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=60&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095288-1217;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;[HTML][HTML] To chain or not to chain: A reinforcement learning approach for blockchain-enabled IoT monitoring applications;N Mhaisen, N Fetais, A Erbad, A Mohamed… ; Future Generation …, 2020  Elsevier;;"… Each node on the decentralized oracle system has the ability to submit a state … For example, oracles

submit their reading individually to the contract, which groups them based on … Based on this price,

and the specific blockchain computation billing mechanism (eg, “Gas”-based …";Cité 6 fois;Les 3 versions;[HTML] sciencedirect.com;https://www.sciencedirect.com/science/article/pii/S0167739X19334399?casa_token=Agwi9a-VnGMAAAAA:C7RaAqra7-hKvvnHPW-htbr5rWT7FU_GAzAW0eMFAr2tUzkEvTnq4U8etlliuCdiOq43f-Ha;;;https://scholar.google.com/scholar?start=20&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095395-1679;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;[PDF][PDF] Designing for Trust in Blockchain Platforms: from Exploring to Making it Real;L Zavolokina ;2020 researchgate.net;;"… The popularity of blockchain technology emerged from the famous cryptocurrency Bitcoin.

At present, cryptocurrencies have a negative connotation due to speculation, related

scandals and darknet activities, and extreme power consumption …";Autres articles;;[PDF] researchgate.net;https://www.researchgate.net/profile/Liudmila_Zavolokina/publication/344037394_Designing_for_trust_in_blockchain_platforms_from_exploring_to_making_it_real_-_The_case_of_the_Swiss_market_of_lemons/links/5f6efd3f92851c14bc97352f/Designing-for-trust-in-blockchain-platforms-from-exploring-to-making-it-real-The-case-of-the-Swiss-market-of-lemons.pdf;;;https://scholar.google.com/scholar?start=480&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095341-1446;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;An Application Model that Leverages Microservice and Blockchain Technologies;Y Tomov ; 2020 III International Conference on High …, 2020  ieeexplore.ieee.org;;"… This model can be used to create any application according to the developed template.

Keywords?blockchain, microservices, smart contracts … Fig. 1. Microservices Architecture(https://

docs.oracle.com) Fig. 2. Proposed architecture … Oracles should be used if necessary …";;null;null;;;;https://scholar.google.com/scholar?start=250&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095285-1210;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Blockchain for explainable and trustworthy artificial intelligence;M Nassar, K Salah, MH ur Rehman… ; … Reviews: Data Mining …, 2020  Wiley Online Library;;"… Explainable AI (XAI) is a new trend of AI algorithms that provide explanations of their AI decisions.

In this paper, we propose a framework for achieving a more trustworthy and XAI by leveraging

features of blockchain, smart contracts, trusted oracles, and decentralized storage …";Cité 17 fois;Les 3 versions;[PDF] wiley.com;https://onlinelibrary.wiley.com/doi/pdf/10.1002/widm.1340?casa_token=D6glV-TG5d8AAAAA:-HaDEldDN6GlA0ifAYEF-AJ3Z8MxPl3CIvVjCTSysgz0LqUuNALwOzjAK-OcX-4hgi3Jo0mlBOKldA;;;https://scholar.google.com/scholar?start=10&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095341-1452;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Interactive Oracle Proofs of Proximity to Algebraic Geometry Codes;S Bordage, J Nardi ; arXiv preprint arXiv:2011.04295, 2020  arxiv.org;;"… Interactive Oracle Proofs of Proximity to Algebraic Geometry Codes … We aim to fill this gap. We

construct an Interactive Oracle Proof of Proximity (IOPP) for some families of AG codes by

generalizing an IOPP for Reed-Solomon codes, known as the FRI protocol [BBHR18] …";Cité 1 fois;Les 2 versions;[PDF] arxiv.org;https://arxiv.org/pdf/2011.04295;;"""date"",""2021-02-17T03:51:47Z""
""pdf:PDFVersion"",""1.4""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.4""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""xmp:CreateDate"",""2021-02-16T22:51:47Z""
""modified"",""2021-02-17T03:51:47Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""xmp:ModifyDate"",""2021-02-16T22:51:47Z""
""pdf:docinfo:creator"",""""
""meta:author"",""""
""meta:creation-date"",""2021-02-17T03:51:47Z""
""created"",""2021-02-17T03:51:47Z""
""xmp:About"",""uuid:01e4c02b-a8f0-11f6-0000-bc868249f9fa""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2021-02-17T03:51:47Z""
""resourceName"",""2011.04295""
""Author"",""""
""producer"",""dvips + GPL Ghostscript GIT PRERELEASE 9.22""
""pdf:docinfo:producer"",""dvips + GPL Ghostscript GIT PRERELEASE 9.22""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""2"",""4"",""0"",""14"",""2"",""5"",""0"",""13"",""5"",""34"",""3"",""3"",""17"",""7"",""29"",""0"",""14"",""44"",""12"",""13"",""6"",""23"",""2"",""13"",""19"",""10"",""17"",""25"",""7"",""42"",""0"",""0"",""0"",""0"",""9"",""12""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2021-02-17T03:51:47Z""
""Last-Modified"",""2021-02-17T03:51:47Z""
""dcterms:modified"",""2021-02-17T03:51:47Z""
""title"",""""
""xmpMM:DocumentID"",""uuid:01e4c02b-a8f0-11f6-0000-bc868249f9fa""
""Last-Save-Date"",""2021-02-17T03:51:47Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2021-02-17T03:51:47Z""
""meta:save-date"",""2021-02-17T03:51:47Z""
""Content-Length"",""452953""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""38""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""1734"",""3649"",""3311"",""2503"",""2348"",""2384"",""2842"",""2922"",""3006"",""1832"",""2181"",""1897"",""2121"",""2049"",""1894"",""1514"",""1963"",""2265"",""2163"",""1553"",""1861"",""1711"",""1988"",""2141"",""993"",""1395"",""2533"",""1729"",""1518"",""1208"",""2095"",""1624"",""2470"",""2623"",""2465"",""2352"",""1261"",""1176""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2021-02-17T03:51:47Z""
";https://scholar.google.com/scholar?start=250&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095316-1335;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;A Blockchain-based Traceable Self-tallying E-voting Protocol in AI Era;H Li, Y Li, Y Yu, B Wang, K Chen ; IEEE Transactions on …, 2020  ieeexplore.ieee.org;;"… The International Association of Crypto- logic Research (IACR) used Helios3, a web-based

e-voting system … 3.3.1 Anonymity Anonymity of a blockchain-based traceable self-tallying e- voting

protocol ? is … challenger C. In this game, A is given access to a register oracle, Oreg(ESK …";Cité 1 fois;Les 2 versions;null;;;;https://scholar.google.com/scholar?start=140&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095362-1535;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Proof of Concept of Blockchain Integration in P2P Lending for Developing Countries;S Ouya ; eInfrastructure and eServices for Developing …, 2020  books.google.com;;"… POC of Blockchain Integration in P2P Lending for Developing Countries 67 The Interest: Using

a … design pattern Useful design pattern Solution In the study context Oracles Oracles are contracts …

In practice, contract queries an oracle instead of querying an external service; and …";;null;null;;;;https://scholar.google.com/scholar?start=340&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095318-1345;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Can Verifiable Delay Functions be Based on Random Oracles?;M Mahmoody, C Smith, DJ Wu ; 47th International Colloquium on …, 2020  drops.dagstuhl.de;;"… Boneh, Bonneau, Bünz, and Fisch (CRYPTO 2018) recently introduced the notion of a verifiable

delay … Indeed, [1] uses random oracles together with the sloth function from [20] to construct their

permutation VDF, and thus it was left open whether random oracle would suffice for …";Autres articles;;[PDF] dagstuhl.de;https://drops.dagstuhl.de/opus/volltexte/2020/12490/pdf/LIPIcs-ICALP-2020-83.pdf;;"""date"",""2020-06-26T09:12:15Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""Can Verifiable Delay Functions Be Based on Random Oracles?""
""xmp:CreatorTool"",""LaTeX with lipics-v2019.cls and hyperref.sty""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""LIPIcs, Vol.168, ICALP 2020; Copyright (C) Mohammad Mahmoody, Caleb Smith, and David J. Wu; licensed under Creative Commons License CC-BY""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with lipics-v2019.cls and hyperref.sty""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""Can Verifiable Delay Functions Be Based on Random Oracles?""
""modified"",""2020-06-26T09:12:15Z""
""cp:subject"",""LIPIcs, Vol.168, ICALP 2020; Copyright (C) Mohammad Mahmoody, Caleb Smith, and David J. Wu; licensed under Creative Commons License CC-BY""
""pdf:docinfo:subject"",""LIPIcs, Vol.168, ICALP 2020; Copyright (C) Mohammad Mahmoody, Caleb Smith, and David J. Wu; licensed under Creative Commons License CC-BY""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""Mohammad Mahmoody, Caleb Smith, David J. Wu""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.20 (TeX Live 2019) kpathsea version 6.3.1""
""meta:author"",""Mohammad Mahmoody, Caleb Smith, David J. Wu""
""trapped"",""False""
""meta:creation-date"",""2020-06-26T09:12:15Z""
""created"",""2020-06-26T09:12:15Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-06-26T09:12:15Z""
""resourceName"",""LIPIcs-ICALP-2020-83.pdf""
""Author"",""Mohammad Mahmoody, Caleb Smith, David J. Wu""
""producer"",""pdfTeX-1.40.20""
""pdf:docinfo:producer"",""pdfTeX-1.40.20""
""pdf:unmappedUnicodeCharsPerPage"",""6"",""10"",""5"",""1"",""1"",""13"",""4"",""2"",""4"",""18"",""3"",""11"",""3"",""7"",""0"",""0"",""0""
""Keywords"",""verifiable delay function, lower bound, random oracle model""
""access_permission:modify_annotations"",""true""
""dc:creator"",""Mohammad Mahmoody, Caleb Smith, David J. Wu""
""dcterms:created"",""2020-06-26T09:12:15Z""
""Last-Modified"",""2020-06-26T09:12:15Z""
""dcterms:modified"",""2020-06-26T09:12:15Z""
""title"",""Can Verifiable Delay Functions Be Based on Random Oracles?""
""Last-Save-Date"",""2020-06-26T09:12:15Z""
""pdf:docinfo:keywords"",""verifiable delay function, lower bound, random oracle model""
""pdf:docinfo:modified"",""2020-06-26T09:12:15Z""
""meta:save-date"",""2020-06-26T09:12:15Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.20 (TeX Live 2019) kpathsea version 6.3.1""
""Content-Length"",""535037""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Mohammad Mahmoody, Caleb Smith, David J. Wu""
""dc:subject"",""verifiable delay function, lower bound, random oracle model""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""17""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""2773"",""3063"",""3447"",""3402"",""2728"",""2109"",""2744"",""2950"",""2709"",""2873"",""2572"",""2594"",""2893"",""2175"",""2762"",""3132"",""908""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""verifiable delay function, lower bound, random oracle model""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-06-26T09:12:15Z""
";https://scholar.google.com/scholar?start=150&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095344-1459;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Analyzing smart contract interactions and contract level state consensus;YC Hu, TT Lee, D Chatzopoulos… ; … : Practice and Experience, 2020  Wiley Online Library;;"… Because of the fact that smart contracts are locked in the blockchain without an access to the

external … but the problem is that the architecture will be in ruin if the only oracle turns out … There

seemed to be no easier way but only to use several oracles simultaneously, whereas it is …";Cité 7 fois;Les 2 versions;null;;;;https://scholar.google.com/scholar?start=260&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095378-1613;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Designing for Good: Blockchain Technology and Human Rights;M Busstra ; Intergovernmental Org. Inhouse Couns. J., 2020  HeinOnline;;"… For a much more elaborate exploration of potential financial applications of blockchain technology,

see Scott, How can cryptocurrency and Blockchain Technology Play a Role in … This involves, for

instance, making sensible use of oracles in the blockchain process, which can …";;null;null;;;;https://scholar.google.com/scholar?start=410&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095325-1377;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Blockchain technology in maritime industry;I Peronja, K Lenac, R Glavinovi? ; Pomorstvo, 2020  hrcak.srce.hr;;"… Maritime Research 34 (2020) 178-184 tain properties, or may depend on external services, called

oracles, that take data from the real world and store them into the blockchain. An oracle could,

for example, monitor for the arrival of a package and record the information on …";Cité 4 fois;Les 7 versions;[PDF] srce.hr;https://hrcak.srce.hr/file/347159;;"""date"",""2020-06-14T17:56:31Z""
""pdf:PDFVersion"",""1.4""
""xmp:CreatorTool"",""Adobe InDesign CS4 (6.0)""
""pdf:docinfo:title"",""Blockchain technology in maritime industry""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""xmpMM:History:Action"",""created"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved""
""language"",""en""
""dc:format"",""application/pdf; version=1.4""
""pdf:docinfo:creator_tool"",""Adobe InDesign CS4 (6.0)""
""access_permission:fill_in_form"",""true""
""xmpMM:History:When"",""2010-05-18T09:53:05Z"",""2010-05-18T10:47:51Z"",""2010-05-18T10:47:51Z"",""2010-05-18T10:56:35Z"",""2010-05-18T12:50:10Z"",""2010-06-14T14:43:53Z"",""2010-06-14T14:43:53Z"",""2010-06-14T15:14:19Z"",""2010-06-14T15:48:56Z"",""2010-06-16T12:00:28Z"",""2010-06-16T12:34:56Z"",""2010-06-16T14:18:47Z"",""2010-06-16T14:20:36Z"",""2010-06-16T14:55:46Z"",""2010-06-16T15:06:20Z"",""2010-06-17T12:32:44Z"",""2010-06-18T09:44:50Z"",""2010-06-28T09:06:37Z"",""2010-06-28T09:51:37Z"",""2010-06-28T09:53:35Z"",""2010-06-28T10:24:46Z"",""2010-06-28T11:55:59Z"",""2010-06-28T11:59:13Z"",""2010-06-28T12:10:15Z"",""2010-06-30T09:22:26Z"",""2010-06-30T09:24:47Z"",""2010-12-15T20:11:06Z"",""2010-12-15T20:11:11Z"",""2010-12-15T23:36:40Z"",""2010-12-15T23:44:59Z"",""2010-12-15T23:46:49Z"",""2010-12-15T23:48:11Z"",""2010-12-16T19:01:57Z"",""2010-12-17T11:50:17Z"",""2010-12-17T11:50:25Z"",""2010-12-26T23:59:29Z"",""2010-12-27T00:02:06Z"",""2010-12-27T00:19:10Z"",""2010-12-27T01:03:45Z"",""2010-12-27T01:07:10Z"",""2010-12-28T09:56:28Z"",""2010-12-28T10:43:49Z"",""2010-12-28T10:51:00Z"",""2010-12-28T10:52:24Z"",""2010-12-29T11:38:28Z"",""2010-12-29T13:10:03Z"",""2010-12-29T23:22:44Z"",""2010-12-29T23:34:17Z"",""2010-12-29T23:47:53Z"",""2010-12-29T23:49:33Z"",""2010-12-29T23:51:06Z"",""2010-12-29T23:57:09Z"",""2011-06-08T14:20:43Z"",""2011-06-08T14:20:43Z"",""2011-06-08T14:21:09Z"",""2011-06-08T17:09:38Z"",""2011-06-08T17:19:02Z"",""2011-06-08T18:05:59Z"",""2011-06-08T18:46:31Z"",""2011-06-08T19:52:51Z"",""2011-06-13T08:16:39Z"",""2011-06-15T10:49:58Z"",""2011-06-15T11:02:06Z"",""2011-06-27T02:20:23Z"",""2011-06-27T03:26:50Z"",""2011-06-27T03:26:50Z"",""2011-06-27T03:45:09Z"",""2011-06-27T03:58:16Z"",""2011-06-27T04:03:15Z"",""2011-06-27T04:04:03Z"",""2011-06-27T05:48:21Z"",""2011-12-04T11:22:31Z"",""2011-12-04T11:22:31Z"",""2011-12-04T11:22:53Z"",""2011-12-04T14:44:21Z"",""2011-12-04T14:46:09Z"",""2011-12-04T16:01:57Z"",""2011-12-04T16:55:31Z"",""2011-12-04T20:08:14Z"",""2011-12-04T21:44:06Z"",""2011-12-07T21:09:02Z"",""2011-12-21T12:01:02Z"",""2011-12-21T12:02:22Z"",""2011-12-21T12:02:34Z"",""2011-12-21T12:02:51Z"",""2011-12-21T12:03:02Z"",""2011-12-21T12:03:56Z"",""2011-12-21T12:04:10Z"",""2011-12-21T12:04:19Z"",""2011-12-21T14:44:24Z"",""2011-12-21T14:44:24Z"",""2011-12-21T15:04:25Z"",""2011-12-22T12:24:40Z"",""2011-12-22T13:35:38Z"",""2011-12-22T14:25:07Z"",""2011-12-27T15:10:57Z"",""2011-12-27T15:17:40Z"",""2012-06-07T07:56:51Z"",""2012-06-07T07:56:51Z"",""2012-06-07T07:57:03Z"",""2012-06-07T08:23:49Z"",""2012-06-07T08:59:16Z"",""2012-06-07T09:41:25Z"",""2012-06-07T09:51:26Z"",""2012-06-10T21:49:35Z"",""2012-06-19T05:23:03Z"",""2012-06-19T05:24:58Z"",""2012-06-19T10:57:46Z"",""2012-06-19T11:09:07Z"",""2012-06-19T11:09:44Z"",""2012-06-19T11:11:10Z"",""2012-06-19T11:11:53Z"",""2012-06-19T11:12:44Z"",""2012-06-19T11:32:37Z"",""2012-06-19T11:33:01Z"",""2012-06-19T17:19:28Z"",""2012-06-19T18:11:26Z"",""2012-06-19T21:10:31Z"",""2012-06-19T21:10:31Z"",""2012-06-20T15:34:03Z"",""2012-06-25T19:10:19Z"",""2012-06-26T09:33:12Z"",""2012-12-02T13:39:31Z"",""2012-12-02T13:40:34Z"",""2012-12-02T13:40:34Z"",""2012-12-02T13:40:56Z"",""2012-12-02T13:41:20Z"",""2012-12-02T13:41:20Z"",""2012-12-02T13:41:32Z"",""2012-12-02T13:43:02Z"",""2012-12-02T13:47:48Z"",""2012-12-02T14:01:21Z"",""2012-12-03T21:49:17Z"",""2012-12-03T22:29:59Z"",""2012-12-03T22:30:57Z"",""2012-12-12T00:15:47Z"",""2012-12-12T10:13:01Z"",""2012-12-12T11:10:22Z"",""2012-12-12T17:23:44Z"",""2012-12-12T21:51:36Z"",""2012-12-14T13:56:50Z"",""2012-12-14T15:09:06Z"",""2012-12-14T15:12:25Z"",""2012-12-14T15:17:54Z"",""2012-12-14T15:17:54Z"",""2012-12-16T11:34:40Z"",""2012-12-18T12:16:49Z"",""2013-05-22T10:26:10Z"",""2013-05-22T10:26:10Z"",""2013-05-22T10:27:23Z"",""2013-05-22T10:28:06Z"",""2013-05-22T10:28:06Z"",""2013-05-22T10:28:33Z"",""2013-05-22T10:29:24Z"",""2013-05-22T10:29:24Z"",""2013-05-22T10:29:40Z"",""2013-05-22T10:30:27Z"",""2013-05-22T10:30:27Z"",""2013-05-22T10:30:41Z"",""2013-05-22T10:35:13Z"",""2013-05-22T10:35:13Z"",""2013-05-22T10:38:12Z"",""2013-05-22T11:34:25Z"",""2013-05-22T12:20:08Z"",""2013-05-23T00:15:58Z"",""2013-06-03T18:59:54Z"",""2013-06-03T18:59:54Z"",""2013-06-03T19:00:19Z"",""2013-06-03T19:02:00Z"",""2013-06-03T19:02:00Z"",""2013-06-03T19:02:14Z"",""2013-06-03T19:03:24Z"",""2013-06-03T19:03:24Z"",""2013-06-03T19:18:45Z"",""2013-06-03T19:20:23Z"",""2013-06-08T17:32:35Z"",""2013-06-08T17:32:35Z"",""2013-06-08T17:32:48Z"",""2013-06-08T17:33:35Z"",""2013-06-08T17:33:35Z"",""2013-06-08T17:33:46Z"",""2013-06-08T17:57:35Z"",""2013-06-08T20:45:26Z"",""2013-06-08T20:46:09Z"",""2013-06-08T20:47:52Z"",""2013-06-08T20:48:06Z"",""2013-06-14T21:47:25Z"",""2013-06-16T09:28:27Z"",""2013-06-17T11:34:30Z"",""2013-06-17T11:34:51Z"",""2013-06-17T11:35:39Z"",""2013-06-17T11:58:41Z"",""2013-06-19T19:46:06Z"",""2013-06-25T21:00:13Z"",""2013-06-25T21:07:19Z"",""2013-06-25T21:09:56Z"",""2013-06-25T21:57:54Z"",""2013-06-25T22:17:02Z"",""2013-06-25T22:19:56Z"",""2013-06-25T22:34:42Z"",""2013-06-25T22:48:00Z"",""2013-06-25T23:04:37Z"",""2013-06-25T23:18:15Z"",""2013-06-26T10:22:34Z"",""2013-06-26T10:28:30Z"",""2013-06-26T13:41:53Z"",""2013-06-26T13:41:53Z"",""2013-06-26T14:25:07Z"",""2013-06-26T14:26:20Z"",""2013-06-26T14:26:38Z"",""2013-06-26T14:27:42Z"",""2013-06-26T14:42:56Z"",""2013-06-26T15:16:14Z"",""2013-06-26T15:42:55Z"",""2013-06-26T15:43:12Z"",""2013-06-26T15:55:08Z"",""2013-06-27T09:00:42Z"",""2013-12-06T11:20:10Z"",""2013-12-06T11:20:10Z"",""2013-12-06T17:46:30Z"",""2013-12-06T19:40:59Z"",""2013-12-06T19:53:15Z"",""2013-12-06T21:05:00Z"",""2013-12-06T21:13:31Z"",""2013-12-07T11:47:15Z"",""2013-12-07T11:52:48Z"",""2013-12-07T12:02:52Z"",""2013-12-07T18:15:20Z"",""2013-12-07T19:19:58Z"",""2013-12-07T20:27:05Z"",""2013-12-07T20:33:15Z"",""2013-12-07T20:33:41Z"",""2013-12-10T20:21:37Z"",""2013-12-12T11:55:11Z"",""2013-12-18T11:14:04Z"",""2013-12-18T11:29:26Z"",""2013-12-23T19:45:51Z"",""2013-12-23T20:31:53Z"",""2013-12-23T20:53:01Z"",""2013-12-23T20:56:39Z"",""2014-01-08T22:22:51Z"",""2014-01-08T22:25:17Z"",""2014-01-09T00:01:31Z"",""2014-01-09T00:11:51Z"",""2014-06-01T17:31:14Z"",""2014-06-01T17:31:14Z"",""2014-06-01T18:16:37Z"",""2014-06-01T18:26:13Z"",""2014-06-01T18:31:40Z"",""2014-06-01T18:40:44Z"",""2014-06-01T18:48:38Z"",""2014-06-01T19:04:56Z"",""2014-06-01T19:13:23Z"",""2014-06-01T19:23:43Z"",""2014-06-02T07:58:37Z"",""2014-06-02T08:00:05Z"",""2014-06-02T08:01:36Z"",""2014-06-02T08:01:54Z"",""2014-06-02T08:14:14Z"",""2014-06-02T08:15:20Z"",""2014-06-02T15:21:53Z"",""2014-06-02T16:33:01Z"",""2014-06-02T17:19:21Z"",""2014-06-03T13:14:58Z"",""2014-06-03T13:47:42Z"",""2014-06-03T13:48:42Z"",""2014-06-03T13:56:30Z"",""2014-06-11T18:30:07Z"",""2014-06-11T18:30:07Z"",""2014-06-11T20:03:07Z"",""2014-06-11T21:16:26Z"",""2014-06-11T21:35:03Z"",""2014-06-11T21:51:55Z"",""2014-06-11T21:57:05Z"",""2014-06-11T22:01:01Z"",""2014-06-11T23:30:20Z"",""2014-06-11T23:43:44Z"",""2014-06-11T23:47:57Z"",""2014-06-12T00:03:59Z"",""2014-06-12T00:25:08Z"",""2014-06-12T00:25:22Z"",""2014-06-12T00:34:44Z"",""2014-06-12T10:17:30Z"",""2014-06-12T10:18:40Z"",""2014-06-12T10:30:06Z"",""2014-06-12T11:17:44Z"",""2014-06-12T11:27:50Z"",""2014-06-12T11:52:26Z"",""2014-06-12T13:02:24Z"",""2014-06-12T13:02:38Z"",""2014-06-12T13:15:47Z"",""2014-06-12T13:43:12Z"",""2014-06-12T15:07:44Z"",""2014-06-12T19:36:12Z"",""2014-06-12T19:44:59Z"",""2014-06-13T01:36:44Z"",""2014-06-13T10:58:03Z"",""2014-06-13T12:00:23Z"",""2014-06-13T12:53:04Z"",""2014-06-13T15:14:09Z"",""2014-06-13T18:51:17Z"",""2014-06-13T19:27:34Z"",""2014-06-13T20:22:39Z"",""2014-06-13T20:25:01Z"",""2014-06-13T20:25:51Z"",""2014-06-13T20:57:04Z"",""2014-06-13T21:00:19Z"",""2014-06-13T21:02:49Z"",""2014-06-16T12:02:16Z"",""2014-06-16T12:03:13Z"",""2014-06-16T13:28:58Z"",""2014-06-16T13:32:14Z"",""2014-06-16T14:36:13Z"",""2014-06-16T21:16:59Z"",""2014-06-16T21:17:16Z"",""2014-06-16T21:18:25Z"",""2014-06-16T23:33:47Z"",""2014-06-16T23:35:42Z"",""2014-06-16T23:48:12Z"",""2014-06-17T00:12:57Z"",""2014-06-17T00:50:18Z"",""2014-06-17T00:52:06Z"",""2014-06-17T00:58:42Z"",""2014-06-17T00:59:21Z"",""2014-06-17T01:06:20Z"",""2014-06-17T01:25:44Z"",""2014-06-17T01:35:39Z"",""2014-06-17T02:34:06Z"",""2014-06-17T02:35:40Z"",""2014-06-17T02:39:50Z"",""2014-06-17T11:10:34Z"",""2014-06-17T11:19:53Z"",""2014-06-17T11:35:11Z"",""2014-06-17T11:58:46Z"",""2014-06-17T12:00:54Z"",""2014-06-17T12:56:26Z"",""2014-06-17T13:29:53Z"",""2014-06-17T13:44:27Z"",""2014-06-17T15:17:57Z"",""2014-06-17T15:39:05Z"",""2014-06-18T20:26:06Z"",""2014-06-23T18:04:30Z"",""2014-06-23T18:07:01Z"",""2014-06-23T18:26:18Z"",""2014-06-30T14:25:56Z"",""2014-06-30T14:25:56Z"",""2014-07-01T11:51:16Z"",""2014-07-01T12:34:34Z"",""2014-07-01T12:35:51Z"",""2014-07-01T12:41:10Z"",""2014-07-01T12:43:11Z"",""2014-07-01T12:44:02Z"",""2014-07-01T12:45:57Z"",""2014-07-01T12:46:41Z"",""2014-07-02T14:03:31Z"",""2014-07-02T14:05:26Z"",""2014-12-15T09:40:21Z"",""2014-12-15T10:26:14Z"",""2014-12-15T19:37:54Z"",""2014-12-15T19:40:00Z"",""2014-12-15T21:10:02Z"",""2014-12-15T21:12:43Z"",""2014-12-15T21:15:20Z"",""2014-12-15T21:20:27Z"",""2014-12-20T18:15:01Z"",""2014-12-20T19:15:52Z"",""2014-12-20T19:44:58Z"",""2014-12-20T20:10:43Z"",""2014-12-20T20:59:43Z"",""2014-12-20T21:08:35Z"",""2014-12-20T22:09:24Z"",""2014-12-20T23:05:21Z"",""2014-12-20T23:37:23Z"",""2014-12-21T10:36:45Z"",""2014-12-21T16:23:27Z"",""2014-12-23T08:43:47Z"",""2014-12-23T08:56:18Z"",""2014-12-23T08:56:33Z"",""2014-12-23T09:20:12Z"",""2014-12-23T09:21:36Z"",""2014-12-23T09:22:30Z"",""2014-12-23T09:39:49Z"",""2014-12-23T10:45:41Z"",""2014-12-23T10:46:58Z"",""2014-12-23T10:47:33Z"",""2014-12-23T10:48:00Z"",""2014-12-23T10:50:19Z"",""2014-12-23T10:52:10Z"",""2014-12-24T13:39:28Z"",""2014-12-24T13:40:35Z"",""2014-12-24T13:47:39Z"",""2014-12-29T11:27:31Z"",""2014-12-29T11:28:04Z"",""2014-12-29T11:28:37Z"",""2014-12-29T11:30:50Z"",""2014-12-29T15:05:43Z"",""2014-12-29T15:12:54Z"",""2014-12-29T15:16:05Z"",""2014-12-30T10:01:37Z"",""2015-01-21T15:34:20Z"",""2015-01-21T15:34:21Z"",""2015-01-21T15:49:44Z"",""2015-01-21T16:10:33Z"",""2015-01-22T11:08:08Z"",""2015-01-25T18:29:05Z"",""2015-01-26T09:40:33Z"",""2015-01-26T10:02:05Z"",""2015-01-26T10:02:45Z"",""2015-01-26T10:06:15Z"",""2015-01-26T10:07:08Z"",""2015-01-30T09:12:18Z"",""2015-01-30T09:53:14Z"",""2015-01-30T09:55:02Z"",""2015-01-30T10:00:04Z"",""2015-01-30T10:06:40Z"",""2015-01-30T10:07:38Z"",""2015-12-09T10:00:23Z"",""2015-12-09T10:05:56Z"",""2015-12-09T11:30:36Z"",""2015-12-09T11:50:05Z"",""2015-12-09T13:11:34Z"",""2015-12-09T13:11:56Z"",""2015-12-09T13:57:09Z"",""2015-12-09T14:56:28Z"",""2015-12-09T15:29:06Z"",""2015-12-09T15:36:32Z"",""2015-12-09T16:02:40Z"",""2015-12-09T19:14:42Z"",""2015-12-09T20:05:38Z"",""2015-12-09T20:39:32Z"",""2015-12-09T20:46:48Z"",""2015-12-09T22:15:53Z"",""2015-12-09T22:24:23Z"",""2015-12-09T22:25:32Z"",""2015-12-09T22:28:59Z"",""2015-12-09T22:51:59Z"",""2015-12-09T22:52:50Z"",""2015-12-09T22:54:36Z"",""2015-12-09T23:27:05Z"",""2015-12-09T23:27:27Z"",""2015-12-09T23:49:30Z"",""2015-12-10T00:06:02Z"",""2015-12-10T00:29:12Z"",""2015-12-10T00:52:33Z"",""2015-12-10T00:54:14Z"",""2015-12-10T01:07:50Z"",""2015-12-10T01:08:00Z"",""2015-12-10T20:06:55Z"",""2015-12-10T20:38:06Z"",""2015-12-10T20:44:52Z"",""2015-12-10T21:51:24Z"",""2015-12-11T09:52:40Z"",""2015-12-13T23:30:48Z"",""2015-12-13T23:31:44Z"",""2015-12-13T23:34:13Z"",""2015-12-13T23:34:30Z"",""2015-12-14T20:03:21Z"",""2015-12-14T20:05:41Z"",""2015-12-14T20:06:22Z"",""2015-12-14T21:11:47Z"",""2015-12-15T10:58:07Z"",""2015-12-15T11:01:57Z"",""2015-12-15T11:26:40Z"",""2015-12-15T18:48:05Z"",""2015-12-15T18:52:33Z"",""2015-12-16T13:54:22Z"",""2015-12-16T14:18:46Z"",""2015-12-16T14:19:45Z"",""2015-12-16T14:21:42Z"",""2015-12-16T14:24:01Z"",""2015-12-16T15:52:58Z"",""2015-12-17T11:02:55Z"",""2015-12-17T11:17:06Z"",""2015-12-17T11:25:48Z"",""2015-12-17T11:26:25Z"",""2015-12-23T14:19:17Z"",""2015-12-23T14:23:04Z"",""2015-12-23T14:28:16Z"",""2015-12-23T14:29:07Z"",""2015-12-23T14:30:06Z"",""2015-12-23T15:35:58Z"",""2015-12-23T15:38:50Z"",""2015-12-28T08:48:09Z"",""2015-12-28T19:56:31Z"",""2015-12-28T20:27:54Z"",""2015-12-28T20:33:31Z"",""2015-12-28T20:54:28Z"",""2015-12-28T21:04:34Z"",""2015-12-28T21:33:42Z"",""2015-12-28T21:45:38Z"",""2015-12-28T21:55:07Z"",""2015-12-28T22:00:30Z"",""2015-12-28T22:20:57Z"",""2015-12-29T12:22:11Z"",""2015-12-29T12:34:23Z"",""2015-12-29T12:50:57Z"",""2015-12-30T10:36:28Z"",""2016-07-18T09:49:43Z"",""2016-12-13T15:10:42Z"",""2016-12-13T15:10:43Z"",""2016-12-13T15:26:10Z"",""2016-12-13T18:21:45Z"",""2016-12-19T07:23:31Z"",""2016-12-19T07:58:20Z"",""2016-12-19T09:04:16Z"",""2016-12-19T09:06:03Z"",""2016-12-19T09:09:50Z"",""2016-12-19T09:11:38Z"",""2016-12-19T09:18:53Z"",""2016-12-19T09:25:58Z"",""2016-12-19T10:52:35Z"",""2016-12-19T11:16:04Z"",""2016-12-19T11:32:59Z"",""2016-12-19T11:58:43Z"",""2016-12-19T12:35:36Z"",""2016-12-19T13:03:48Z"",""2016-12-19T13:48:10Z"",""2016-12-19T14:41:16Z"",""2016-12-19T14:43:15Z"",""2016-12-19T14:58:29Z"",""2016-12-19T15:39:31Z"",""2016-12-19T15:42:33Z"",""2016-12-19T15:42:36Z"",""2016-12-19T15:53:52Z"",""2016-12-19T15:57:34Z"",""2016-12-19T20:17:57Z"",""2016-12-19T21:20:31Z"",""2016-12-19T21:55:11Z"",""2016-12-21T14:00:11Z"",""2016-12-21T15:08:24Z"",""2016-12-21T16:07:25Z"",""2016-12-21T16:15:21Z"",""2016-12-21T18:19:25Z"",""2016-12-21T18:30:08Z"",""2016-12-21T18:46:15Z"",""2016-12-21T18:47:10Z"",""2016-12-21T19:04:48Z"",""2016-12-21T19:14:23Z"",""2016-12-21T19:15:02Z"",""2016-12-21T19:43:24Z"",""2016-12-21T21:57:23Z"",""2016-12-22T11:20:16Z"",""2016-12-22T11:22:27Z"",""2016-12-22T11:55:56Z"",""2016-12-23T07:45:17Z"",""2016-12-23T07:45:17Z"",""2016-12-26T10:20:55Z"",""2016-12-26T10:42:19Z"",""2016-12-26T11:07:16Z"",""2016-12-26T11:18:36Z"",""2016-12-26T11:27:33Z"",""2016-12-26T11:47:28Z"",""2016-12-26T12:15:08Z"",""2016-12-26T12:35:38Z"",""2016-12-26T13:06:22Z"",""2016-12-28T15:09:12Z"",""2016-12-28T17:32:36Z"",""2016-12-28T23:30:51Z"",""2016-12-28T23:51:59Z"",""2017-06-05T09:26:59Z"",""2017-06-05T12:09:36Z"",""2017-06-05T12:11:26Z"",""2017-06-05T21:19:34Z"",""2017-06-05T21:50:10Z"",""2017-06-05T21:57:18Z"",""2017-06-05T22:07:18Z"",""2017-06-05T22:33:05Z"",""2017-06-05T23:05:46Z"",""2017-06-05T23:26:29Z"",""2017-06-05T23:27:15Z"",""2017-06-06T08:12:12Z"",""2017-06-06T09:10:48Z"",""2017-06-06T09:18:43Z"",""2017-06-06T09:26:37Z"",""2017-06-06T09:28:02Z"",""2017-06-07T12:46:03Z"",""2017-06-07T12:54:19Z"",""2017-06-07T12:59:12Z"",""2017-06-07T13:00:08Z"",""2017-06-07T13:02:11Z"",""2017-06-07T13:42:47Z"",""2017-06-18T16:39:44Z"",""2017-06-18T17:11:53Z"",""2017-06-18T17:31:29Z"",""2017-06-18T17:38:03Z"",""2017-06-25T16:39:16Z"",""2017-06-25T17:24:47Z"",""2017-06-25T17:26:29Z"",""2017-06-25T20:44:25Z"",""2017-06-25T20:46:08Z"",""2017-06-25T20:50:31Z"",""2017-06-25T20:59:05Z"",""2017-06-25T21:00:07Z"",""2017-06-25T21:01:25Z"",""2017-06-25T21:46:12Z"",""2017-06-26T00:00:21Z"",""2017-06-26T00:06:50Z"",""2017-06-26T00:49:23Z"",""2017-06-26T00:54:46Z"",""2017-06-26T09:14:50Z"",""2017-06-26T09:32:11Z"",""2017-06-26T09:33:56Z"",""2017-06-26T15:13:50Z"",""2017-06-26T19:22:00Z"",""2017-06-26T19:25:14Z"",""2017-06-26T20:26:12Z"",""2017-06-26T20:30:56Z"",""2017-06-26T20:37:32Z"",""2017-06-26T20:38:39Z"",""2017-06-27T10:03:52Z"",""2017-06-27T11:39:14Z"",""2017-06-27T11:41:56Z"",""2017-06-27T13:22:08Z"",""2017-06-27T14:47:10Z"",""2017-06-28T11:58:26Z"",""2017-06-29T13:59:25Z"",""2017-06-29T14:25:48Z"",""2017-06-29T14:26:38Z"",""2017-06-30T13:29:19Z"",""2017-06-30T13:30:16Z"",""2017-06-30T13:36:11Z"",""2017-06-30T13:37:02Z"",""2017-07-03T09:03:20Z"",""2017-07-03T09:07:57Z"",""2017-07-03T09:11:34Z"",""2017-07-04T08:55:50Z"",""2017-07-04T08:56:29Z"",""2017-07-04T10:36:45Z"",""2017-07-04T10:37:30Z"",""2017-07-04T10:38:04Z"",""2017-07-04T10:38:32Z"",""2017-07-04T10:46:12Z"",""2017-12-13T07:58:55Z"",""2017-12-13T07:58:55Z"",""2017-12-13T11:46:47Z"",""2017-12-13T11:48:52Z"",""2017-12-13T11:52:54Z"",""2017-12-17T12:51:36Z"",""2017-12-17T12:52:16Z"",""2017-12-17T13:10:41Z"",""2017-12-17T13:44:44Z"",""2017-12-17T14:02:09Z"",""2017-12-17T19:13:03Z"",""2017-12-17T19:14:57Z"",""2017-12-17T19:51:35Z"",""2017-12-17T20:03:03Z"",""2017-12-17T20:12:22Z"",""2017-12-17T20:17:07Z"",""2017-12-17T20:50:18Z"",""2017-12-17T20:54:22Z"",""2017-12-17T21:29:11Z"",""2017-12-17T21:38:39Z"",""2017-12-17T23:33:42Z"",""2017-12-17T23:52:12Z"",""2017-12-17T23:56:30Z"",""2017-12-18T00:23:36Z"",""2017-12-20T11:43:19Z"",""2017-12-20T11:49:50Z"",""2017-12-20T11:55:54Z"",""2017-12-20T12:02:35Z"",""2017-12-20T12:34:52Z"",""2017-12-20T13:26:26Z"",""2017-12-20T13:29:38Z"",""2017-12-20T13:31:02Z"",""2017-12-20T14:11:51Z"",""2017-12-20T15:34:30Z"",""2017-12-20T15:52:14Z"",""2017-12-20T16:15:30Z"",""2017-12-20T17:40:22Z"",""2017-12-20T17:40:50Z"",""2017-12-20T18:47:17Z"",""2017-12-20T18:54:16Z"",""2017-12-20T18:55:15Z"",""2017-12-20T19:10:40Z"",""2017-12-20T19:13:01Z"",""2017-12-21T09:10:01Z"",""2017-12-21T11:52:57Z"",""2017-12-21T11:55:11Z"",""2017-12-21T12:13:44Z"",""2017-12-21T16:39:54Z"",""2017-12-21T16:41:44Z"",""2017-12-21T16:43:32Z"",""2017-12-21T16:51:57Z"",""2017-12-21T16:57:39Z"",""2017-12-21T16:58:19Z"",""2017-12-21T17:09:46Z"",""2017-12-21T19:03:03Z"",""2017-12-21T19:12:37Z"",""2017-12-21T19:27:25Z"",""2017-12-21T19:32:14Z"",""2017-12-21T19:39:58Z"",""2017-12-21T19:52:48Z"",""2017-12-22T12:01:31Z"",""2017-12-22T12:07:50Z"",""2017-12-22T12:08:33Z"",""2017-12-22T12:10:23Z"",""2017-12-22T12:54:19Z"",""2017-12-22T12:54:57Z"",""2017-12-22T13:14:10Z"",""2017-12-22T14:51:04Z"",""2018-01-10T10:57:03Z"",""2018-01-10T12:07:05Z"",""2018-01-10T12:13:58Z"",""2018-01-10T12:17:21Z"",""2018-01-10T13:20:44Z"",""2018-01-10T13:22:26Z"",""2018-01-10T13:33:34Z"",""2018-01-10T13:34:24Z"",""2018-01-10T13:36:26Z"",""2018-01-10T13:37:03Z"",""2018-01-12T13:41:35Z"",""2018-01-12T13:42:47Z"",""2018-01-12T13:43:32Z"",""2018-01-12T13:51:48Z"",""2018-01-12T13:52:37Z"",""2018-05-21T20:11:27Z"",""2018-05-21T20:20:58Z"",""2018-05-21T20:21:13Z"",""2018-05-21T20:35:06Z"",""2018-05-21T21:16:41Z"",""2018-05-21T21:17:11Z"",""2018-05-21T21:57:41Z"",""2018-05-21T22:02:28Z"",""2018-05-28T15:12:35Z"",""2018-05-28T15:20:23Z"",""2018-05-28T15:47:40Z"",""2018-05-28T15:59:27Z"",""2018-05-28T16:01:01Z"",""2018-05-28T16:01:46Z"",""2018-05-28T16:02:04Z"",""2018-05-28T16:02:25Z"",""2018-05-28T17:22:07Z"",""2018-05-28T17:51:00Z"",""2018-05-28T17:54:26Z"",""2018-05-28T17:59:16Z"",""2018-05-28T18:04:03Z"",""2018-05-28T21:02:29Z"",""2018-05-28T21:19:49Z"",""2018-05-28T21:33:08Z"",""2018-05-28T21:42:10Z"",""2018-05-28T22:26:15Z"",""2018-05-28T22:27:23Z"",""2018-05-28T22:29:20Z"",""2018-06-05T07:26:04Z"",""2018-06-05T07:28:33Z"",""2018-06-05T07:37:59Z"",""2018-06-05T08:21:05Z"",""2018-06-05T08:22:53Z"",""2018-06-05T08:24:37Z"",""2018-06-05T09:00:27Z"",""2018-06-05T09:06:02Z"",""2018-06-05T10:15:27Z"",""2018-06-05T12:30:39Z"",""2018-06-05T12:33:01Z"",""2018-06-05T12:33:45Z"",""2018-06-05T12:36:45Z"",""2018-06-05T13:03:30Z"",""2018-06-05T13:23:56Z"",""2018-06-05T15:06:03Z"",""2018-06-05T15:06:32Z"",""2018-06-05T15:09:50Z"",""2018-06-05T15:10:28Z"",""2018-06-05T15:11:58Z"",""2018-06-06T12:23:27Z"",""2018-06-06T12:25:07Z"",""2018-06-06T13:43:06Z"",""2018-06-06T13:47:28Z"",""2018-06-06T16:35:41Z"",""2018-06-07T16:50:51Z"",""2018-06-07T16:53:32Z"",""2018-06-07T16:57:53Z"",""2018-06-07T16:59:37Z"",""2018-06-07T18:45:24Z"",""2018-06-07T18:51:14Z"",""2018-06-07T18:59:36Z"",""2018-06-07T21:32:15Z"",""2018-06-07T22:02:42Z"",""2018-06-07T22:17:36Z"",""2018-06-07T22:25:56Z"",""2018-06-09T09:04:20Z"",""2018-06-11T09:10:00Z"",""2018-06-12T23:32:29Z"",""2018-06-12T23:34:24Z"",""2018-06-13T00:00:25Z"",""2018-06-13T10:03:38Z"",""2018-06-13T14:17:35Z"",""2018-06-13T20:47:13Z"",""2018-06-13T20:53:02Z"",""2018-06-13T21:32:08Z"",""2018-06-13T21:42:26Z"",""2018-06-13T21:43:56Z"",""2018-06-13T22:47:37Z"",""2018-06-14T16:10:41Z"",""2018-06-17T15:29:24Z"",""2018-06-17T15:55:47Z"",""2018-06-17T16:08:56Z"",""2018-06-17T16:24:25Z"",""2018-06-17T16:32:54Z"",""2018-06-17T16:34:38Z"",""2018-06-17T16:37:37Z"",""2018-06-17T16:39:04Z"",""2018-06-18T11:58:54Z"",""2018-06-19T13:36:46Z"",""2018-06-19T13:37:55Z"",""2018-06-19T13:45:14Z"",""2018-06-19T13:46:19Z"",""2018-06-19T13:47:31Z"",""2018-06-19T14:39:41Z"",""2018-06-25T15:00:08Z"",""2018-06-25T16:57:16Z"",""2018-06-25T17:05:21Z"",""2018-06-25T17:07:21Z"",""2018-06-25T21:17:17Z"",""2018-06-25T22:01:15Z"",""2018-06-25T22:02:50Z"",""2018-06-25T22:11:16Z"",""2018-06-25T22:12:24Z"",""2018-06-25T22:20:20Z"",""2018-06-25T22:21:11Z"",""2018-12-11T16:50:00Z"",""2018-12-11T16:50:00Z"",""2018-12-11T22:44:31Z"",""2018-12-11T22:49:10Z"",""2018-12-11T23:01:44Z"",""2018-12-11T23:04:14Z"",""2018-12-11T23:07:01Z"",""2018-12-12T11:42:16Z"",""2018-12-12T11:54:38Z"",""2018-12-12T12:26:13Z"",""2018-12-12T12:27:13Z"",""2018-12-12T12:31:22Z"",""2018-12-12T13:11:33Z"",""2018-12-12T13:16:21Z"",""2018-12-12T13:17:29Z"",""2018-12-12T13:17:38Z"",""2018-12-12T13:43:36Z"",""2018-12-12T13:52:38Z"",""2018-12-12T14:11:51Z"",""2018-12-12T14:36:38Z"",""2018-12-12T20:35:42Z"",""2018-12-12T20:50:38Z"",""2018-12-12T20:52:28Z"",""2018-12-12T21:52:40Z"",""2018-12-12T22:04:18Z"",""2018-12-12T22:08:26Z"",""2018-12-12T22:08:35Z"",""2018-12-12T22:09:56Z"",""2018-12-12T22:12:02Z"",""2018-12-12T22:13:28Z"",""2018-12-12T22:45:19Z"",""2018-12-12T23:10:55Z"",""2018-12-12T23:21:07Z"",""2018-12-12T23:22:04Z"",""2018-12-13T00:47:43Z"",""2018-12-13T01:00:39Z"",""2018-12-13T08:58:45Z"",""2018-12-13T09:26:01Z"",""2018-12-13T09:27:57Z"",""2018-12-13T09:30:05Z"",""2018-12-13T09:30:13Z"",""2018-12-13T09:32:05Z"",""2018-12-13T09:32:14Z"",""2018-12-13T12:56:11Z"",""2018-12-13T13:04:59Z"",""2018-12-13T13:05:58Z"",""2018-12-13T13:07:46Z"",""2018-12-13T13:09:30Z"",""2018-12-13T13:11:23Z"",""2018-12-13T13:48:15Z"",""2018-12-13T13:50:00Z"",""2018-12-13T13:51:33Z"",""2018-12-13T13:52:32Z"",""2018-12-13T13:57:56Z"",""2018-12-13T15:06:23Z"",""2018-12-13T16:08:46Z"",""2018-12-13T16:38:19Z"",""2018-12-13T22:51:12Z"",""2018-12-13T23:36:14Z"",""2018-12-13T23:36:50Z"",""2018-12-13T23:38:21Z"",""2018-12-14T08:30:35Z"",""2018-12-14T08:31:13Z"",""2018-12-14T10:59:12Z"",""2018-12-14T11:04:29Z"",""2018-12-14T11:20:52Z"",""2018-12-14T12:08:36Z"",""2018-12-14T12:42:52Z"",""2018-12-14T12:43:29Z"",""2018-12-14T12:45:33Z"",""2018-12-17T08:33:22Z"",""2018-12-17T08:37:48Z"",""2018-12-17T08:46:56Z"",""2018-12-17T08:47:23Z"",""2018-12-17T08:51:01Z"",""2018-12-17T09:11:47Z"",""2018-12-17T09:14:45Z"",""2018-12-17T09:23:40Z"",""2018-12-17T09:26:22Z"",""2018-12-17T09:27:51Z"",""2018-12-17T09:34:40Z"",""2018-12-17T09:36:19Z"",""2018-12-17T09:54:08Z"",""2018-12-17T09:57:09Z"",""2018-12-17T10:01:54Z"",""2018-12-17T10:02:11Z"",""2018-12-17T11:56:27Z"",""2018-12-17T12:07:22Z"",""2018-12-17T13:29:17Z"",""2018-12-17T13:31:36Z"",""2018-12-17T13:33:44Z"",""2018-12-17T16:45:02Z"",""2018-12-18T08:40:08Z"",""2018-12-18T09:00:31Z"",""2018-12-18T09:01:32Z"",""2018-12-18T09:02:44Z"",""2018-12-18T12:38:34Z"",""2018-12-18T12:47:29Z"",""2018-12-18T12:48:40Z"",""2018-12-18T17:58:04Z"",""2018-12-18T17:59:27Z"",""2018-12-18T18:01:17Z"",""2018-12-18T19:27:53Z"",""2018-12-18T20:27:40Z"",""2018-12-18T20:51:15Z"",""2018-12-18T20:52:10Z"",""2018-12-18T21:32:57Z"",""2018-12-18T21:33:06Z"",""2018-12-18T21:39:45Z"",""2018-12-18T21:40:00Z"",""2018-12-19T10:27:07Z"",""2018-12-19T10:27:30Z"",""2018-12-19T16:01:55Z"",""2018-12-19T16:03:32Z"",""2018-12-20T08:30:02Z"",""2018-12-20T08:42:18Z"",""2018-12-20T09:35:58Z"",""2018-12-24T13:28:23Z"",""2019-01-09T11:35:40Z"",""2019-01-09T11:35:40Z"",""2019-01-09T11:36:44Z"",""2019-01-09T12:29:26Z"",""2019-01-09T12:30:28Z"",""2019-01-09T12:33:57Z"",""2019-01-09T12:34:34Z"",""2019-01-10T11:48:39Z"",""2019-01-10T11:55:04Z"",""2019-01-10T13:13:02Z"",""2019-01-13T20:05:15Z"",""2019-01-13T21:22:11Z"",""2019-01-13T21:55:49Z"",""2019-01-13T21:57:57Z"",""2019-01-13T21:59:16Z"",""2019-01-13T22:08:12Z"",""2019-01-13T22:11:43Z"",""2019-01-13T22:15:32Z"",""2019-01-13T22:17:17Z"",""2019-01-13T22:25:25Z"",""2019-01-13T22:26:21Z"",""2019-01-13T22:33:09Z"",""2019-01-13T22:34:57Z"",""2019-01-14T08:20:22Z"",""2019-01-14T08:22:02Z"",""2019-02-20T13:17:22Z"",""2019-06-06T11:47:55Z"",""2019-06-06T11:47:56Z"",""2019-06-06T12:09:13Z"",""2019-06-06T12:14:20Z"",""2019-06-06T13:05:51Z"",""2019-06-06T13:06:52Z"",""2019-06-06T13:17:37Z"",""2019-06-06T13:21:56Z"",""2019-06-06T13:56:31Z"",""2019-06-06T15:18:20Z"",""2019-06-06T15:21:02Z"",""2019-06-06T15:22:00Z"",""2019-06-08T10:01:19Z"",""2019-06-08T10:27:10Z"",""2019-06-08T10:50:05Z"",""2019-06-08T12:15:43Z"",""2019-06-08T12:16:48Z"",""2019-06-08T12:22:19Z"",""2019-06-08T14:19:57Z"",""2019-06-08T14:24:33Z"",""2019-06-08T15:10:45Z"",""2019-06-08T15:30:35Z"",""2019-06-08T15:31:05Z"",""2019-06-09T11:27:38Z"",""2019-06-09T11:33:56Z"",""2019-06-09T13:27:38Z"",""2019-06-09T13:28:09Z"",""2019-06-09T14:37:51Z"",""2019-06-09T14:57:20Z"",""2019-06-09T15:01:45Z"",""2019-06-09T17:18:15Z"",""2019-06-09T17:38:00Z"",""2019-06-09T17:39:29Z"",""2019-06-10T09:17:43Z"",""2019-06-18T11:36:45Z"",""2019-06-18T12:28:26Z"",""2019-06-21T10:57:37Z"",""2019-06-21T11:52:53Z"",""2019-06-21T12:14:33Z"",""2019-06-21T13:04:59Z"",""2019-06-21T13:07:53Z"",""2019-06-21T13:42:37Z"",""2019-06-21T14:02:51Z"",""2019-06-21T14:08:45Z"",""2019-06-25T09:45:46Z"",""2019-06-25T10:15:22Z"",""2019-06-25T10:24:19Z"",""2019-06-25T11:39:26Z"",""2019-06-25T11:57:23Z"",""2019-06-25T12:46:19Z"",""2019-06-26T14:46:42Z"",""2019-06-26T15:42:59Z"",""2019-06-28T09:21:11Z"",""2019-07-03T09:20:36Z"",""2019-07-03T09:27:14Z"",""2019-07-03T09:33:02Z"",""2019-07-03T09:35:31Z"",""2019-07-03T09:40:25Z"",""2019-07-03T09:41:17Z"",""2019-11-22T10:38:07Z"",""2019-11-22T10:38:07Z""
""pdf:encrypted"",""false""
""dc:title"",""Blockchain technology in maritime industry""
""xmp:CreateDate"",""2020-06-14T19:56:30Z""
""modified"",""2020-06-14T17:56:31Z""
""xmpMM:History:SoftwareAgent"",""Adobe InDesign 6.0"",""Adobe InDesign 6.0"",""Adobe InDesign 6.0"",""Adobe InDesign 6.0"",""Adobe InDesign 6.0"",""Adobe InDesign 6.0"",""Adobe InDesign 6.0"",""Adobe InDesign 6.0"",""Adobe InDesign 6.0"",""Adobe InDesign 6.0"",""Adobe InDesign 6.0"",""Adobe InDesign 6.0"",""Adobe InDesign 6.0"",""Adobe InDesign 6.0"",""Adobe InDesign 6.0"",""Adobe InDesign 6.0"",""Adobe InDesign 6.0"",""Adobe InDesign 6.0"",""Adobe InDesign 6.0"",""Adobe InDe";https://scholar.google.com/scholar?start=180&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095376-1600;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Cryptocurrency as the currency of the future: a case study among Algebra University College students;A Kneževi?, T Babi?, Z Musa ; 2020 43rd International Convention on …  ieeexplore.ieee.org;;"… One crypto token that hasn?t made the top 10 list yet, but created a lot of attention over … to bridge

the gap between smart contracts on the blockchain and realYworld applications of the blockchain.

It uses oracles, which find and verify realY world data and bring it onYchain to be …";Autres articles;;[PDF] mipro-proceedings.com;http://docs.mipro-proceedings.com/ce/45_CE_6099.pdf;;"""date"",""2020-09-20T21:07:31Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.7""
""xmp:CreatorTool"",""Acrobat Pro DC 20.12.20043""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dc:creator"",""IEEE""
""dcterms:created"",""2020-09-20T21:07:31Z""
""language"",""en""
""Last-Modified"",""2020-09-20T21:07:31Z""
""dcterms:modified"",""2020-09-20T21:07:31Z""
""dc:format"",""application/pdf; version=1.7""
""xmpMM:DocumentID"",""uuid:81ab806f-749d-1a4c-803a-18971ad3dbe5""
""Last-Save-Date"",""2020-09-20T21:07:31Z""
""pdf:docinfo:creator_tool"",""Acrobat Pro DC 20.12.20043""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2020-09-20T21:07:31Z""
""meta:save-date"",""2020-09-20T21:07:31Z""
""pdf:encrypted"",""false""
""xmp:CreateDate"",""2020-09-20T23:07:31Z""
""modified"",""2020-09-20T21:07:31Z""
""Content-Length"",""1022150""
""pdf:hasMarkedContent"",""true""
""Content-Type"",""application/pdf""
""xmp:ModifyDate"",""2020-09-20T23:07:31Z""
""pdf:docinfo:creator"",""IEEE""
""xmp:MetadataDate"",""2020-09-20T23:07:31Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""IEEE""
""meta:author"",""IEEE""
""pdf:producer"",""Acrobat Pro DC 20.12.20043""
""meta:creation-date"",""2020-09-20T21:07:31Z""
""created"",""2020-09-20T21:07:31Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""6""
""Creation-Date"",""2020-09-20T21:07:31Z""
""resourceName"",""45_CE_6099.pdf""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""5019"",""6309"",""5004"",""5137"",""4293"",""5312""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""Author"",""IEEE""
""producer"",""Acrobat Pro DC 20.12.20043""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""Acrobat Pro DC 20.12.20043""
""pdf:docinfo:created"",""2020-09-20T21:07:31Z""
";https://scholar.google.com/scholar?start=400&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095302-1280;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;[HTML][HTML] Integrated project delivery with blockchain: An automated financial system;F Elghaish, S Abrishami, MR Hosseini ; Automation in Construction, 2020  Elsevier;;"… applications to be built, as well as smart contracts to be deployed; and (3) uses a cryptocurrency

called Ether and … of permissioned blockchain platforms, several commercial packages are available,

for example, the IBMŽ Blockchain Cloud, the Oracle Blockchain platform and …";Cité 26 fois;Les 3 versions;[HTML] sciencedirect.com;https://www.sciencedirect.com/science/article/pii/S0926580519312142?casa_token=VLawiERZPg8AAAAA:9eykp6YgvaWWgWkw0zBAI0feoBgIrvvsXb8VEcjqDnGUj83RwSrzc8_d8b5XY7-HoeAC45QD;;;https://scholar.google.com/scholar?start=80&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095302-1282;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;[HTML][HTML] PAChain: Private, authenticated & auditable consortium blockchain and its implementation;TH Yuen ; Future Generation Computer Systems, 2020  Elsevier;;"… Public blockchain. Monero is a cryptocurrency providing privacy by linkable ring signature, stealth

address and ring confidential transactions [6]. The major disadvantage of Monero is the size of

the linkable ring signature, which is proportional to the size of the ring (related to the …";Cité 2 fois;Les 3 versions;[HTML] sciencedirect.com;https://www.sciencedirect.com/science/article/pii/S0167739X19328547?casa_token=HvmlAQZCJ0IAAAAA:hzwDr1GU6nGql-px0w7-j0-gO7wKLFNt2eog0swxyDUEJ73CINOUsQBOEQaml6n-EYGhxdwL;;;https://scholar.google.com/scholar?start=80&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095409-1741;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Hashing Out Agreements: An Overview of “Smart” Contracts under Canadian Common Law;F Martin;Bariteau, M Pontello  Available at SSRN, 2020  papers.ssrn.com;;"… This problem has been solved through the use of a blockchain middleware called an “oracle.”

Oracles bridge smart … 13 Aaron Wright & David Roon, “Bridging the Fiat-Crypto Divide” (11

September 2018), online: Consensys https://media.consensys.net/bridging-the-fiat …";Autres articles;;null;;;;https://scholar.google.com/scholar?start=540&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095392-1665;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;???????? ??????????? Blockchain ??? ???????? ??? ??? ??????????? ???????;? ??????????? ;2020 hellanicus.lib.aegean.gr;;"Page 1. 1 ???????????? ??????? ????? ????????? ????????? ????? ????????? ???

??????????????? ????????? Ť???????? ??????????? Blockchain ??? ???????? ??? ???

??????????? ???????ť … Page 9. 9 ???????? 1o: ???????? ???? ?????????? Blockchain …";;;[PDF] aegean.gr;https://hellanicus.lib.aegean.gr/bitstream/handle/11610/20966/%CE%94%CE%99%CE%A0%CE%9B%CE%A9%CE%9C%CE%91%CE%A4%CE%99%CE%9A%CE%97%20%CE%9A%CE%9F%CE%A5%CE%A4%CE%A3%CE%9F%CE%A5%CE%A1%CE%91%CE%94%CE%97%20BLOCKCHAIN.pdf?sequence=2&isAllowed=y;;"""date"",""2020-06-06T12:07:48Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.7""
""xmp:CreatorTool"",""MicrosoftÂŽ Word for Microsoft 365""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""language"",""el""
""dcterms:created"",""2020-06-06T12:07:48Z""
""Last-Modified"",""2020-06-06T12:07:48Z""
""dcterms:modified"",""2020-06-06T12:07:48Z""
""dc:format"",""application/pdf; version=1.7""
""xmpMM:DocumentID"",""uuid:A57E50DB-5CD0-48CF-91A7-51E6F025FF74""
""Last-Save-Date"",""2020-06-06T12:07:48Z""
""pdf:docinfo:creator_tool"",""MicrosoftÂŽ Word for Microsoft 365""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2020-06-06T12:07:48Z""
""meta:save-date"",""2020-06-06T12:07:48Z""
""pdf:encrypted"",""false""
""xmp:CreateDate"",""2020-06-06T12:07:48Z""
""modified"",""2020-06-06T12:07:48Z""
""Content-Length"",""1194809""
""pdf:hasMarkedContent"",""true""
""Content-Type"",""application/pdf""
""xmp:ModifyDate"",""2020-06-06T12:07:48Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""dc:language"",""en-US""
""pdf:producer"",""MicrosoftÂŽ Word for Microsoft 365""
""meta:creation-date"",""2020-06-06T12:07:48Z""
""created"",""2020-06-06T12:07:48Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""97""
""Creation-Date"",""2020-06-06T12:07:48Z""
""resourceName"",""%CE%94%CE%99%CE%A0%CE%9B%CE%A9%CE%9C%CE%91%CE%A4%CE%99%CE%9A%CE%97%20%CE%9A%CE%9F%CE%A5%CE%A4%CE%A3%CE%9F%CE%A5%CE%A1%CE%91%CE%94%CE%97%20BLOCKCHAIN.pdf""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""348"",""370"",""1339"",""2288"",""1061"",""3743"",""3054"",""473"",""1145"",""2192"",""2339"",""2325"",""2311"",""1979"",""2015"",""1475"",""2246"",""1293"",""1982"",""2230"",""2032"",""2228"",""1255"",""2154"",""2001"",""2080"",""1984"",""90"",""1755"",""1715"",""1990"",""1485"",""2188"",""2117"",""1882"",""2293"",""2022"",""1071"",""1232"",""2276"",""2154"",""1446"",""2152"",""1984"",""1465"",""2285"",""2075"",""2168"",""2258"",""2403"",""2129"",""2276"",""2378"",""2232"",""2101"",""2476"",""2259"",""2039"",""2299"",""2221"",""2129"",""2115"",""2379"",""1093"",""1891"",""2069"",""2041"",""2077"",""1842"",""1815"",""2324"",""2287"",""2226"",""2312"",""2211"",""2236"",""2068"",""2151"",""2073"",""1969"",""2232"",""2205"",""1867"",""2253"",""472"",""2096"",""2134"",""2131"",""1645"",""1655"",""1931"",""133"",""1809"",""1920"",""1637"",""957"",""331""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""producer"",""MicrosoftÂŽ Word for Microsoft 365""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""MicrosoftÂŽ Word for Microsoft 365""
""pdf:docinfo:created"",""2020-06-06T12:07:48Z""
";https://scholar.google.com/scholar?start=470&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095355-1504;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;[HTML][HTML] Demystifying Stablecoins: Cryptography meets monetary policy;J Clark, D Demirag, S Moosavi ; Queue, 2020  dl.acm.org;;"… Because a blockchain has no inherent knowledge of exchange rates, this mechanism

still requires one trustworthy entity called an oracle to write the exchange rate into the

blockchain (or consensus can be taken across a set of oracles) …";Cité 5 fois;Les 5 versions;[HTML] acm.org;https://dl.acm.org/doi/fullHtml/10.1145/3387945.3388781;;;https://scholar.google.com/scholar?start=310&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095371-1580;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Blockchain Platforms: A Look at the Underbelly of Distributed Platforms;S Van Hijfte ; … Lectures on Information Concepts, Retrieval, and …, 2020  morganclaypool.com;;"… Accessed May 17, 2020. 2 Wat is de geschiedenis van blockchain? https://btcdirect.eu/nl-nl/

geschiedenis-blockchain. Accessed June 3, 2019 … 7 The “mint” refers to the analogy between

creating a cost token, or cryptocurrency, and actually minting physical money. left";Autres articles;;null;;;;https://scholar.google.com/scholar?start=380&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095334-1422;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Supply chain management in agriculture using blockchain and IoT;MD Borah, VB Naik, R Patgiri, A Bhargav… ; … of Blockchain …, 2020  Springer;;"… Through oracles or interchain communications protocols, A BigchainDB network can be

connected to other blockchain networks … Use crypto-conditions to generate a condition which

locks the transaction, thus; Protecting it from an unauthorized user; …";Cité 12 fois;Les 4 versions;[PDF] researchgate.net;https://www.researchgate.net/profile/Ripon_Patgiri/publication/336071540_Supply_Chain_Management_in_Agriculture_Using_Blockchain_and_IoT/links/5ee0f48d299bf1d20bdedec7/Supply-Chain-Management-in-Agriculture-Using-Blockchain-and-IoT.pdf;;;https://scholar.google.com/scholar?start=220&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095369-1571;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;A Blacklisting Smart Contract;B Kruger, WS Leung ; International Conference on Business Information …, 2020  Springer;;"… However, oracles need to exist and operate in a decentralized nature [17] … transactions and it

is this type of concept that can successfully serve as an oracle given that … philosophy is well

established and respected by the nodes supporting the most popular blockchain (the Bitcoin …";Autres articles;;null;;;;https://scholar.google.com/scholar?start=370&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095402-1709;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;[PDF][PDF] A Formal Analysis of Blockchain Consensus;C Laneve, A Veschetti ;2020 cs.unibo.it;;"… by using oracles that drive the behaviours of actors. Then, combining the probabilistic behaviours

and assuming possible distributions, one computes expected values. In contrast with the above

works, in [25], Pirlea and Sergey propose a formalization of blockchain consensus …";Cité 1 fois;Les 5 versions;[PDF] unibo.it;http://www.cs.unibo.it/~laneve/papers/AFABC.pdf;;"""date"",""2019-07-05T12:05:41Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""1"",""0"",""1"",""6"",""123"",""51"",""38"",""21"",""13"",""19"",""0"",""0"",""20"",""3"",""20"",""0"",""0"",""0"",""52"",""73"",""10"",""1"",""27"",""46"",""4""
""pdf:PDFVersion"",""1.5""
""xmp:CreatorTool"",""TeX""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dcterms:created"",""2019-07-05T12:05:41Z""
""language"",""en""
""Last-Modified"",""2019-07-05T12:05:41Z""
""dcterms:modified"",""2019-07-05T12:05:41Z""
""dc:format"",""application/pdf; version=1.5""
""Last-Save-Date"",""2019-07-05T12:05:41Z""
""pdf:docinfo:creator_tool"",""TeX""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2019-07-05T12:05:41Z""
""meta:save-date"",""2019-07-05T12:05:41Z""
""pdf:encrypted"",""false""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016) kpathsea version 6.2.2""
""modified"",""2019-07-05T12:05:41Z""
""Content-Length"",""994469""
""pdf:hasMarkedContent"",""false""
""Content-Type"",""application/pdf""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016) kpathsea version 6.2.2""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""trapped"",""False""
""meta:creation-date"",""2019-07-05T12:05:41Z""
""created"",""2019-07-05T12:05:41Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""26""
""Creation-Date"",""2019-07-05T12:05:41Z""
""resourceName"",""AFABC.pdf""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""2271"",""2857"",""2739"",""14344"",""2428"",""1877"",""2111"",""1777"",""2127"",""2116"",""1974"",""1166"",""1764"",""2199"",""1349"",""1671"",""2430"",""2550"",""780"",""1415"",""843"",""1283"",""1003"",""1380"",""688"",""92""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""producer"",""pdfTeX-1.40.17""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""pdfTeX-1.40.17""
""pdf:docinfo:created"",""2019-07-05T12:05:41Z""
";https://scholar.google.com/scholar?start=510&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095334-1415;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Consortium blockchain?enabled access control mechanism in edge computing based generic Internet of Things environment;S Saha, D Chattaraj, B Bera… ; Transactions on …, 2020  Wiley Online Library;;"… which potentially consists of information. In recent years, apart from bitcoin and

cryptocurrency applications, blockchain is being applied in many applications ranging

from military to civilian applications. 10, 11 For instance, the …";Cité 5 fois;;null;;;;https://scholar.google.com/scholar?start=220&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095285-1211;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;A Truth-Inducing Sybil Resistant Decentralized Blockchain Oracle;Y Cai, G Fragkos, EE Tsiropoulou… ; … on Blockchain …, 2020  ieeexplore.ieee.org;;"Many blockchain applications use decentralized oracles to trustlessly retrieve external 
information as those platforms are agnostic to real-world information. Some existing 
decentralized oracle protocols make use of majority-voting schemes to determine the …";Cité 2 fois;Les 4 versions;[PDF] unm.edu;https://ece-research.unm.edu/tsiropoulou/files/BRAINS2020.pdf;;"""date"",""2020-05-28T21:27:44Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""2"",""18"",""14"",""10"",""0"",""0""
""pdf:PDFVersion"",""1.5""
""xmp:CreatorTool"",""TeX""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dcterms:created"",""2020-05-28T21:27:44Z""
""language"",""en""
""Last-Modified"",""2020-05-28T21:27:44Z""
""dcterms:modified"",""2020-05-28T21:27:44Z""
""dc:format"",""application/pdf; version=1.5""
""Last-Save-Date"",""2020-05-28T21:27:44Z""
""pdf:docinfo:creator_tool"",""TeX""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2020-05-28T21:27:44Z""
""meta:save-date"",""2020-05-28T21:27:44Z""
""pdf:encrypted"",""false""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.20 (TeX Live 2019) kpathsea version 6.3.1""
""modified"",""2020-05-28T21:27:44Z""
""Content-Length"",""719772""
""pdf:hasMarkedContent"",""false""
""Content-Type"",""application/pdf""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.20 (TeX Live 2019) kpathsea version 6.3.1""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""trapped"",""False""
""meta:creation-date"",""2020-05-28T21:27:44Z""
""created"",""2020-05-28T21:27:44Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""8""
""Creation-Date"",""2020-05-28T21:27:44Z""
""resourceName"",""BRAINS2020.pdf""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""5193"",""5090"",""4787"",""4654"",""4397"",""4365"",""3554"",""6558""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""producer"",""pdfTeX-1.40.20""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""pdfTeX-1.40.20""
""pdf:docinfo:created"",""2020-05-28T21:27:44Z""
";https://scholar.google.com/scholar?start=10&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095376-1597;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Fully Decentralized Multi-Party Consent Management for Secure Sharing of Patient Health Records;M Madine, K Salah, R Jayaraman, I Yaqoob… ; IEEE …, 2020  ieeexplore.ieee.org;;"… In order to use oracles without forgoing the desired characteristics of blockchain, our smart …

on-chain, the smart contract will accept the response of the quickest oracle, otherwise, the … A

reputation system is a technique that helps to distinguish the truthful and untruthful oracles …";Autres articles;;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/6287639/8948470/09294064.pdf;;"""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""dc:title"",""IEEE Xplore Full-Text PDF:""
""Content-Encoding"",""UTF-8""
""resourceName"",""09294064.pdf""
""language"",""es""
""Content-Length"",""2565""
""title"",""IEEE Xplore Full-Text PDF:""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=400&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095299-1269;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;ARCT: An Efficient Aggregating Ring Confidential Transaction Protocol in Blockchain;J Duan, L Gu, S Zheng ; IEEE Access, 2020  ieeexplore.ieee.org;;"… ARCT build on the techniques of inner product optimization algorithm and cryptographic

accumulators. We show that our underlying algorithm satisfies the security under the random

oracle model. INDEX TERMS Blockchain, cryptocurrency, data privacy, ringCT …";Autres articles;;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/6287639/8948470/09241853.pdf;;"""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""dc:title"",""IEEE Xplore Full-Text PDF:""
""Content-Encoding"",""UTF-8""
""resourceName"",""09241853.pdf""
""language"",""es""
""Content-Length"",""2565""
""title"",""IEEE Xplore Full-Text PDF:""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=70&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095292-1238;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;[HTML][HTML] A semantic differential transaction approach to minimizing information redundancy for BIM and blockchain integration;F Xue, W Lu ; Automation in Construction, 2020  Elsevier;;"… 6. Each blockchain node has the base model in its local cache, a reserved memory space, and

monitors the local … The Python native hashing function is used as the software oracle to represent

an IFC instance's semantic “signature” if no other oracles are identified …";Cité 12 fois;Les 5 versions;[HTML] sciencedirect.com;https://www.sciencedirect.com/science/article/pii/S0926580520302041?casa_token=7gRfiqupdLMAAAAA:DfFMu0EorxorfK09_15F_5lcS1ZTiY5UpkIT67l-obYz1h5B6v0yKT8KoiVTDU4wW_5l8W4_;;;https://scholar.google.com/scholar?start=40&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095299-1272;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Blockchain adoption is inevitable—Barriers and risks remain;KW Prewett, GL Prescott… ; Journal of Corporate …, 2020  Wiley Online Library;;"… the power and benefits of blockchain, more and more data are entering the chain via independent

devices called oracles … In addition, like any computer hardware or software, the oracle can be

hacked and its data manipulated or destroyed … Blockchain integration; Legal services …";Cité 15 fois;;[PDF] wiley.com;https://onlinelibrary.wiley.com/doi/pdf/10.1002/jcaf.22415?casa_token=Yn1_ASXpJl4AAAAA:gMmEYMFNQRLDFMXWVk3fHHFEqU5FIojXepoyNTiMLAiGh4hKIVWXMlWQqbfVIogcEuljsuvgjTvZ1g;;;https://scholar.google.com/scholar?start=70&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095309-1312;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;BitFlow: Enabling real?time cash?flow evaluations through blockchain;L Herskind, A Giaretta, M De Donno… ; Concurrency and …, 2020  Wiley Online Library;;"… which allows data to flow from the outside world into the blockchain.9 Oracles, essential to … as

a smart contract and connected to an oracle, which links DKK transfers to the blockchain itself …

Through this setup, once a certain amount of DKK is transferred to the oracle, the treasury …";Cité 2 fois;Les 3 versions;[PDF] wiley.com;https://onlinelibrary.wiley.com/doi/pdf/10.1002/cpe.5333?casa_token=qtzg7_iHa4IAAAAA:NzJwhwmH9xBsyVI77dOg-rGeTDHksuqLdxAHavYo2G8r-pouT_tfWWC-sBzlynGj8LwnrjQoSwIjJw;;;https://scholar.google.com/scholar?start=110&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095353-1494;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Islanded microgrid management based on blockchain communication;AS Gazafroudi, Y Mezquita, M Shafie;khah…  Blockchainbased Smart …, 2020  Elsevier;;"… Oracle agents are in charge of providing information about the energy offers in the

blockchain-based MG. If there is an unbalance in the MG, the surplus/demand energy is

transacted with an MG operator agent, to trade energy with the upstream grid …";;null;null;;;;https://scholar.google.com/scholar?start=300&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095332-1407;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;[PDF][PDF] Blockchain: Research and Applications;J Ducrée ; researchgate.net;;"… tationally very demanding cryptographic puzzles (“hash rate” in “Proof- of-Work”), as, for instance,

in Bitcoin [1], or by vouching (crypto-)assets (“Proof … [4] Band protocol - Secure, Scalable

blockchain-agnostic decentralized oracle, Accessed: 17 … 5] Blockchain oracles, Accessed: 24 …";Autres articles;Version HTML;[PDF] researchgate.net;https://www.researchgate.net/profile/Jens_Ducree/publication/348048966_Research_-A_blockchain_of_knowledge/links/5fedbfab92851c13fed86c34/Research-A-blockchain-of-knowledge.pdf;;;https://scholar.google.com/scholar?start=210&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095374-1588;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;PrivateEx: privacy preserving exchange of crypto-assets on blockchain;L Xu, L Chen, Z Gao, K Kasichainula… ; Proceedings of the 35th …, 2020  dl.acm.org;;"Page 1. PrivateEx: Privacy Preserving Exchange of Crypto-assets on Blockchain … Weidong Shi

University of Houston wshi3@central.uh.edu ABSTRACT Bitcoin introduces a new type of

cryptocurrency that does not rely on a central system to maintain transactions …";Autres articles;;[PDF] utrgv.edu;https://scholarworks.utrgv.edu/cgi/viewcontent.cgi?article=1036&context=cs_fac;;"""date"",""2020-10-21T13:26:45Z""
""pdf:PDFVersion"",""1.7""
""xmp:CreatorTool"",""Appligent AppendPDF Pro 6.3""
""pdf:docinfo:title"",""PrivateEx: Privacy Preserving Exchange of Crypto-assets on Blockchain""
""Appligent"",""AppendPDF Pro 6.3 Linux 64 bit Aug 30 2019 Library 15.0.4""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""language"",""en""
""dc:format"",""application/pdf; version=1.7""
""pdf:docinfo:creator_tool"",""Appligent AppendPDF Pro 6.3""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""PrivateEx: Privacy Preserving Exchange of Crypto-assets on Blockchain""
""xmp:CreateDate"",""2020-10-21T06:26:45Z""
""modified"",""2020-10-21T13:26:45Z""
""pdf:hasMarkedContent"",""true""
""xmp:ModifyDate"",""2020-10-21T06:26:45Z""
""pdf:docinfo:creator"",""Lei Xu, Lin Chen, Zhimin Gao, Keshav Kasichainula, Miguel Fernandez, Bogdan Carbunar, and Weidong Shi""
""meta:author"",""Lei Xu, Lin Chen, Zhimin Gao, Keshav Kasichainula, Miguel Fernandez, Bogdan Carbunar, and Weidong Shi""
""meta:creation-date"",""2020-10-21T13:26:45Z""
""created"",""2020-10-21T13:26:45Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-10-21T13:26:45Z""
""resourceName"",""viewcontent.cgi""
""Author"",""Lei Xu, Lin Chen, Zhimin Gao, Keshav Kasichainula, Miguel Fernandez, Bogdan Carbunar, and Weidong Shi""
""producer"",""Prince 12.5 (www.princexml.com)""
""pdf:docinfo:producer"",""Prince 12.5 (www.princexml.com)""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""2"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""access_permission:modify_annotations"",""true""
""dc:creator"",""Lei Xu, Lin Chen, Zhimin Gao, Keshav Kasichainula, Miguel Fernandez, Bogdan Carbunar, and Weidong Shi""
""dcterms:created"",""2020-10-21T13:26:45Z""
""Last-Modified"",""2020-10-21T13:26:45Z""
""dcterms:modified"",""2020-10-21T13:26:45Z""
""pdf:docinfo:custom:Appligent"",""AppendPDF Pro 6.3 Linux 64 bit Aug 30 2019 Library 15.0.4""
""title"",""PrivateEx: Privacy Preserving Exchange of Crypto-assets on Blockchain""
""xmpMM:DocumentID"",""uuid:818dcfaa-afa3-11b2-0a00-10a4b8020000""
""Last-Save-Date"",""2020-10-21T13:26:45Z""
""pdf:docinfo:modified"",""2020-10-21T13:26:45Z""
""meta:save-date"",""2020-10-21T13:26:45Z""
""Content-Length"",""691744""
""Content-Type"",""application/pdf""
""xmp:MetadataDate"",""2020-10-21T06:26:45Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Lei Xu, Lin Chen, Zhimin Gao, Keshav Kasichainula, Miguel Fernandez, Bogdan Carbunar, and Weidong Shi""
""dc:language"",""en""
""pdf:producer"",""Prince 12.5 (www.princexml.com)""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""11""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""1502"",""224"",""3319"",""5078"",""4657"",""3933"",""4580"",""4364"",""5233"",""3898"",""4733""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-10-21T13:26:45Z""
";https://scholar.google.com/scholar?start=390&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095318-1353;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;OraclesLink: An architecture for secure oracle usage;B Berger, S Huber, S Pfeifhofer ; … Conference on Blockchain …, 2020  ieeexplore.ieee.org;;"Smart contracts encode critical application logic for realizing digital agreements in a tamper-
proof form. Blockchains guarantee that smart contracts cannot be altered after the first 
deployment and that the execution is strictly followed. Smart contracts can only operate on …";Autres articles;;[PDF] dlteam.io;https://dlteam.io/OraclesLink.pdf;;"""date"",""2020-10-30T18:21:15Z""
""pdf:PDFVersion"",""1.5""
""xmp:CreatorTool"",""'Certified by IEEE PDFeXpress at 09/20/2020 10:58:11 AM'""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""'Certified by IEEE PDFeXpress at 09/20/2020 10:58:11 AM'""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""xmp:CreateDate"",""2020-09-20T17:57:19Z""
""modified"",""2020-10-30T18:21:15Z""
""pdf:hasMarkedContent"",""false""
""xmp:ModifyDate"",""2020-10-30T22:21:15Z""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.20 (TeX Live 2019) kpathsea version 6.3.1""
""trapped"",""False""
""meta:creation-date"",""2020-09-20T17:57:19Z""
""created"",""2020-09-20T17:57:19Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-09-20T17:57:19Z""
""resourceName"",""OraclesLink.pdf""
""producer"",""pdfTeX-1.40.20""
""pdf:docinfo:producer"",""pdfTeX-1.40.20""
""Application"",""'Certified by IEEE PDFeXpress at 09/20/2020 10:58:11 AM'""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""access_permission:modify_annotations"",""true""
""dcterms:created"",""2020-09-20T17:57:19Z""
""Last-Modified"",""2020-10-30T18:21:15Z""
""dcterms:modified"",""2020-10-30T18:21:15Z""
""xmpMM:DocumentID"",""uuid:4aa59ddb-9dd2-4ee1-b42e-7321f0a657f3""
""Last-Save-Date"",""2020-10-30T18:21:15Z""
""pdf:docinfo:modified"",""2020-10-30T18:21:15Z""
""meta:save-date"",""2020-10-30T18:21:15Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.20 (TeX Live 2019) kpathsea version 6.3.1""
""Content-Length"",""2068273""
""pdf:docinfo:custom:Application"",""'Certified by IEEE PDFeXpress at 09/20/2020 10:58:11 AM'""
""Content-Type"",""application/pdf""
""xmp:MetadataDate"",""2020-10-30T22:21:15Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""pdf:producer"",""pdfTeX-1.40.20""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""7""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""4609"",""4393"",""5300"",""2267"",""2828"",""5244"",""5458""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-09-20T17:57:19Z""
";https://scholar.google.com/scholar?start=150&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095288-1214;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Empirical measurements on pricing oracles and decentralized governance for stablecoins;WC Gu, A Raghuvanshi, D Boneh ; Available at SSRN 3611231, 2020  papers.ssrn.com;;"… few recommendations for improvements. 2. A REVIEW OF PRICING ORACLES

An oracle is a mechanism to aggregate and broadcast data from external

off-chain sources onto the blockchain. For a stablecoin, the …";Cité 5 fois;Les 2 versions;[PDF] pubpub.org;https://assets.pubpub.org/vnkw477p/51581338545992.pdf;;;https://scholar.google.com/scholar?start=20&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095295-1248;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;A Lattice-Based Provably Secure Multisignature Scheme in Quantum Random Oracle Model;M Fukumitsu, S Hasegawa ; International Conference on Provable …, 2020  Springer;;"… This property is suitable for IoT devices, and the multisignature schemes are recently employed

in the blockchain to realize a transaction by a multi-user … The concept of compressed oracles

was introduced to simulate the random oracle as in the case of the classical ROM …";Cité 1 fois;Les 2 versions;null;;;;https://scholar.google.com/scholar?start=50&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095316-1340;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Towards a Blockchain Contract-for-Difference Financial Instrument for Hedging Renewable Electricity Transactions;O Alao, P Cuffe ; 2020 6th IEEE International Energy …, 2020  ieeexplore.ieee.org;;"… While transactions alter the state of the blockchain and incur gas, calls allow state reading

and are free … Oracles require trust [7], [24], and in this paper, we assume that a Market

Operator has been delegated to serve as an Oracle in bed …";Cité 2 fois;Les 4 versions;[PDF] ucd.ie;https://researchrepository.ucd.ie/bitstream/10197/11728/2/Towards%20a%20Blockchain%20Contract-for-Difference%20Financial%20Instrument%20for%20Hedging%20Renewable%20Electricity%20Transact.pdf;;"""pdf:unmappedUnicodeCharsPerPage"",""0"",""12"",""0"",""8"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.4""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""7""
""resourceName"",""Towards%20a%20Blockchain%20Contract-for-Difference%20Financial%20Instrument%20for%20Hedging%20Renewable%20Electricity%20Transact.pdf""
""language"",""en""
""pdf:hasXMP"",""false""
""dc:format"",""application/pdf; version=1.4""
""pdf:charsPerPage"",""1349"",""4527"",""5819"",""5121"",""2557"",""3621"",""5508""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""Content-Length"",""406292""
""access_permission:can_modify"",""true""
""pdf:hasMarkedContent"",""false""
""Content-Type"",""application/pdf""
";https://scholar.google.com/scholar?start=140&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095290-1227;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Deco: Liberating web data using decentralized oracles for tls;F Zhang, D Maram, H Malvai, S Goldfeder… ; Proceedings of the 2020 …, 2020  dl.acm.org;;"… Figure 1: The oracle functionality. deployed in a decentralized oracle network similar to [39],

where a set of independently operated oracles are available for smart con- tracts to use. Note

that oracles running DECO are trusted only for integrity, not for privacy …";Cité 17 fois;Les 4 versions;[PDF] acm.org;https://dl.acm.org/doi/pdf/10.1145/3372297.3417239?casa_token=ctsQDPuRoZgAAAAA:Kdrn8co_EaxwA5e-sSOT0VZ3uDsLIfgup7x_qqFUSUfpq5JnvXCNKBOFE6Ku6WEFEUzPNlzwWU0;;;https://scholar.google.com/scholar?start=30&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095302-1276;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Plateforme de trading décentralisée basée sur une Blockchain;S Abouseda ;2020 doc.rero.ch;;"… 11 3.1.2.3 Le problčme des oracles ..... 11 … nécessite un consensus de la

majorité du réseau. La technologie Blockchain a été inventée pour régir Bitcoin,

la premičre et la plus répandue des crypto-monnaies …";Autres articles;Version HTML;[PDF] rero.ch;https://doc.rero.ch/record/329744/files/SamyAbouseda_TravailDeBachelor_2020.pdf;;"""date"",""2020-05-31T16:59:18Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.3""
""pdf:docinfo:title"",""SamyAbouseda_TB_2019--original""
""xmp:CreatorTool"",""Word""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dc:creator"",""Samy Abouseda""
""dcterms:created"",""2020-05-31T16:59:18Z""
""language"",""fr""
""Last-Modified"",""2020-05-31T16:59:18Z""
""dcterms:modified"",""2020-05-31T16:59:18Z""
""dc:format"",""application/pdf; version=1.3""
""title"",""SamyAbouseda_TB_2019--original""
""Last-Save-Date"",""2020-05-31T16:59:18Z""
""pdf:docinfo:creator_tool"",""Word""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2020-05-31T16:59:18Z""
""meta:save-date"",""2020-05-31T16:59:18Z""
""pdf:encrypted"",""false""
""dc:title"",""SamyAbouseda_TB_2019--original""
""modified"",""2020-05-31T16:59:18Z""
""Content-Length"",""3900624""
""pdf:hasMarkedContent"",""false""
""Content-Type"",""application/pdf""
""pdf:docinfo:creator"",""Samy Abouseda""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Samy Abouseda""
""meta:author"",""Samy Abouseda""
""meta:creation-date"",""2020-05-31T16:59:18Z""
""created"",""2020-05-31T16:59:18Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""91""
""Creation-Date"",""2020-05-31T16:59:18Z""
""resourceName"",""SamyAbouseda_TravailDeBachelor_2020.pdf""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""320"",""1018"",""624"",""1174"",""4550"",""5173"",""3628"",""3506"",""2607"",""1381"",""2573"",""2730"",""2586"",""2735"",""2157"",""128"",""2748"",""2422"",""2645"",""2478"",""2963"",""1626"",""2590"",""2481"",""1596"",""2924"",""2748"",""2839"",""869"",""2266"",""2913"",""728"",""1891"",""2519"",""239"",""2771"",""2081"",""1444"",""1126"",""2546"",""2027"",""2729"",""1601"",""2699"",""2514"",""2391"",""1869"",""658"",""641"",""1664"",""637"",""1274"",""538"",""1443"",""2709"",""1451"",""1743"",""1107"",""1794"",""688"",""1571"",""1977"",""1527"",""2158"",""710"",""609"",""911"",""1034"",""2694"",""812"",""2858"",""1948"",""2870"",""2478"",""2633"",""465"",""1738"",""2443"",""2465"",""419"",""1238"",""369"",""2402"",""863"",""433"",""332"",""3067"",""3482"",""3069"",""3217"",""11313""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""Author"",""Samy Abouseda""
""producer"",""macOS Version 10.15.4 (Build 19E266) Quartz PDFContext""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""macOS Version 10.15.4 (Build 19E266) Quartz PDFContext""
""pdf:docinfo:created"",""2020-05-31T16:59:18Z""
";https://scholar.google.com/scholar?start=80&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095292-1242;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Application of Blockchain Technology in Dynamic Resource Management of Next Generation Networks;M Xevgenis, DG Kogias, P Karkazis, HC Leligou… ; Information, 2020  mdpi.com;;"… On the other hand, platforms like Hyperledger Fabric [36] that do not include a native

crypto currency are also rising, especially for commercial use where trusted parties

are involved, creating a private blockchain-based network …";Autres articles;;[PDF] mdpi.com;https://www.mdpi.com/2078-2489/11/12/570/pdf;;;https://scholar.google.com/scholar?start=40&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095360-1527;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Quality-aware transaction validation in blockchains;L BONELLI ;2020 politesi.polimi.it;;"… 22 3.4 Oracles … In this context, a record of the transaction is written on the

blockchain as a permanent and immutable information and the cryptocurrency

balance of the two addresses is updated accordingly. 2 Page 11 …";Autres articles;Version HTML;[PDF] polimi.it;https://www.politesi.polimi.it/bitstream/10589/154490/3/Bonelli_Lorenzo_Maria_876070.pdf;;"""date"",""2020-05-21T08:41:37Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.3""
""xmp:CreatorTool"",""TeX""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dcterms:created"",""2020-05-21T08:41:37Z""
""language"",""en""
""Last-Modified"",""2020-05-21T08:41:37Z""
""dcterms:modified"",""2020-05-21T08:41:37Z""
""dc:format"",""application/pdf; version=1.3""
""Last-Save-Date"",""2020-05-21T08:41:37Z""
""pdf:docinfo:creator_tool"",""TeX""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2020-05-21T08:41:37Z""
""meta:save-date"",""2020-05-21T08:41:37Z""
""pdf:encrypted"",""false""
""modified"",""2020-05-21T08:41:37Z""
""pdf:hasMarkedContent"",""false""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""meta:creation-date"",""2020-05-21T08:41:37Z""
""created"",""2020-05-21T08:41:37Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""75""
""Creation-Date"",""2020-05-21T08:41:37Z""
""resourceName"",""Bonelli_Lorenzo_Maria_876070.pdf""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""310"",""0"",""1925"",""0"",""2277"",""0"",""945"",""1148"",""1364"",""2112"",""1888"",""1490"",""1291"",""2303"",""1620"",""497"",""1393"",""2245"",""1255"",""2132"",""1083"",""2131"",""1854"",""935"",""2018"",""983"",""1359"",""1844"",""2078"",""1132"",""2085"",""1682"",""1862"",""49"",""1111"",""1779"",""1115"",""1762"",""1983"",""1337"",""2070"",""572"",""1303"",""2073"",""895"",""1146"",""691"",""562"",""1206"",""2049"",""1212"",""1358"",""1930"",""1482"",""1460"",""1973"",""2009"",""2241"",""1204"",""1892"",""2137"",""1256"",""1829"",""1956"",""1184"",""1275"",""1415"",""1578"",""1268"",""2"",""1251"",""1593"",""1656"",""473"",""90""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""producer"",""macOS Versione 10.15.4 (Build 19E287) Quartz PDFContext""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""macOS Versione 10.15.4 (Build 19E287) Quartz PDFContext""
""pdf:docinfo:created"",""2020-05-21T08:41:37Z""
";https://scholar.google.com/scholar?start=330&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095297-1263;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Tracking tangible asset ownership and provenance with blockchain;M Sheldon ; Available at SSRN 3669326, 2020  papers.ssrn.com;;"… Sheldon (2020) examines risks to the reliability of the blockchain ledger when smart contracts

depend on oracles to provide information from outside the blockchain. The study highlights that

an oracle “collects, stores, transforms, and transmits information to smart …";Cité 2 fois;;null;;;;https://scholar.google.com/scholar?start=60&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095383-1632;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;An Anonymous Trust-Marking Scheme on Blockchain Systems;T Sato, K Emura, T Fujitani, K Omote ; arXiv preprint arXiv:2010.00206, 2020  arxiv.org;;"… In this paper, we propose an anonymous trust-marking scheme on blockchain systems that is

universally applicable to any cryptocurrency. In our scheme, entities called token admitters are

allowed to generate tokens adding trustworthiness or untrustworthiness to addresses …";Autres articles;;[PDF] arxiv.org;https://arxiv.org/pdf/2010.00206;;"""date"",""2021-02-26T04:00:18Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2021-02-26T04:00:18Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.21 (TeX Live 2020) kpathsea version 6.3.2""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2021-02-26T04:00:18Z""
""created"",""2021-02-26T04:00:18Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2021-02-26T04:00:18Z""
""resourceName"",""2010.00206""
""Author"",""""
""producer"",""pdfTeX-1.40.21""
""pdf:docinfo:producer"",""pdfTeX-1.40.21""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""7"",""1"",""2"",""7"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2021-02-26T04:00:18Z""
""Last-Modified"",""2021-02-26T04:00:18Z""
""dcterms:modified"",""2021-02-26T04:00:18Z""
""title"",""""
""Last-Save-Date"",""2021-02-26T04:00:18Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2021-02-26T04:00:18Z""
""meta:save-date"",""2021-02-26T04:00:18Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.21 (TeX Live 2020) kpathsea version 6.3.2""
""Content-Length"",""357785""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""9""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""4176"",""5296"",""5417"",""5217"",""4619"",""2342"",""4542"",""6005"",""4521""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2021-02-26T04:00:18Z""
";https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095392-1667;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;[LIVRE][B] Build Your Own Blockchain;D Hellwig, G Karlic, A Huchzermeier ;2020 Springer;;"… 1.7.2 Environment Setup ..... 20 1.7.3 Build Your Own Blockchain .....

21 References … 84 4.4.3 Oracles and Security ..... 84 4.4.4 Types of

Oracles ..... 85 4.4.5 Oracle Contract Example ..... 85 …";Cité 1 fois;Les 6 versions;null;;;;https://scholar.google.com/scholar?start=470&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095374-1584;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Blockchain Based Data Storage Mechanism in Cyber Physical System;J Wang, W Chen, Y Ren, O Alfarraj… ; Journal of Internet …, 2020  jit.ndhu.edu.tw;;"… Figure 1. Cyber-physical system 2.2 Blockchain Technology Blockchain is mostly known

as the technology underlying the cryptocurrency Bitcoin [18-19]. The core idea of a

blockchain is decentralization. This means that blockchain …";Autres articles;Version HTML;[PDF] ndhu.edu.tw;https://jit.ndhu.edu.tw/article/download/2401/2416;;"""date"",""2020-11-30T02:42:33Z""
""pdf:PDFVersion"",""1.4""
""xmp:CreatorTool"",""PScript5.dll Version 5.2.2""
""pdf:docinfo:title"",""Microsoft Word - z-vc695-10""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""language"",""en""
""dc:format"",""application/pdf; version=1.4""
""pdf:docinfo:creator_tool"",""PScript5.dll Version 5.2.2""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""Microsoft Word - z-vc695-10""
""xmp:CreateDate"",""2020-11-30T10:42:33Z""
""modified"",""2020-11-30T02:42:33Z""
""pdf:hasMarkedContent"",""false""
""xmp:ModifyDate"",""2020-11-30T10:42:33Z""
""pdf:docinfo:creator"",""EA""
""meta:author"",""EA""
""meta:creation-date"",""2020-11-30T02:42:33Z""
""created"",""2020-11-30T02:42:33Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-11-30T02:42:33Z""
""resourceName"",""2416""
""Author"",""EA""
""producer"",""Acrobat Distiller 10.1.1 (Windows)""
""pdf:docinfo:producer"",""Acrobat Distiller 10.1.1 (Windows)""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""10"",""1"",""0"",""0"",""0""
""access_permission:modify_annotations"",""true""
""dc:creator"",""EA""
""dcterms:created"",""2020-11-30T02:42:33Z""
""Last-Modified"",""2020-11-30T02:42:33Z""
""dcterms:modified"",""2020-11-30T02:42:33Z""
""title"",""Microsoft Word - z-vc695-10""
""xmpMM:DocumentID"",""uuid:9064d69c-8800-4a61-9d66-96c8d482121d""
""Last-Save-Date"",""2020-11-30T02:42:33Z""
""pdf:docinfo:modified"",""2020-11-30T02:42:33Z""
""meta:save-date"",""2020-11-30T02:42:33Z""
""Content-Length"",""2285114""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""EA""
""pdf:producer"",""Acrobat Distiller 10.1.1 (Windows)""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""10""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""4662"",""4929"",""4410"",""4987"",""4020"",""4353"",""5129"",""5957"",""2122"",""59""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-11-30T02:42:33Z""
";https://scholar.google.com/scholar?start=390&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095402-1704;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;[PDF][PDF] 2020 in Crypto–A Review of the Most Important Events in the Market and Trends to follow for 2021;D Ramos, G Zanko ; mobileyourlife.com;;"… like market making (Uniswap), options for liquidity farming (Compound), smart asset management

(YFI), data oracles (ChainLink) and … (2020) “Crypto Theses for … 2020) “A Review of Decentralized

Finance as an Application of Increasing Importance of Blockchain Technology” …";Autres articles;;[PDF] mobileyourlife.com;https://www.mobileyourlife.com/s/Sci_RecapTrends.pdf;;"""date"",""2020-12-31T15:50:09Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.7""
""xmp:CreatorTool"",""MicrosoftÂŽ Word para Microsoft 365""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dc:creator"",""Daniel JosĂŠ Ramos Tirado""
""language"",""en""
""dcterms:created"",""2020-12-31T15:50:09Z""
""Last-Modified"",""2020-12-31T15:50:09Z""
""dcterms:modified"",""2020-12-31T15:50:09Z""
""dc:format"",""application/pdf; version=1.7""
""xmpMM:DocumentID"",""uuid:4F90307F-1A4C-416B-B8FF-BE95FF4E06A4""
""Last-Save-Date"",""2020-12-31T15:50:09Z""
""pdf:docinfo:creator_tool"",""MicrosoftÂŽ Word para Microsoft 365""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2020-12-31T15:50:09Z""
""meta:save-date"",""2020-12-31T15:50:09Z""
""pdf:encrypted"",""false""
""xmp:CreateDate"",""2020-12-31T10:50:09Z""
""modified"",""2020-12-31T15:50:09Z""
""Content-Length"",""524999""
""pdf:hasMarkedContent"",""true""
""Content-Type"",""application/pdf""
""xmp:ModifyDate"",""2020-12-31T10:50:09Z""
""pdf:docinfo:creator"",""Daniel JosĂŠ Ramos Tirado""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Daniel JosĂŠ Ramos Tirado""
""dc:language"",""en-US""
""meta:author"",""Daniel JosĂŠ Ramos Tirado""
""pdf:producer"",""MicrosoftÂŽ Word para Microsoft 365""
""meta:creation-date"",""2020-12-31T15:50:09Z""
""created"",""2020-12-31T15:50:09Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""6""
""Creation-Date"",""2020-12-31T15:50:09Z""
""resourceName"",""Sci_RecapTrends.pdf""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""3676"",""3173"",""4054"",""2566"",""3268"",""1916""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""Author"",""Daniel JosĂŠ Ramos Tirado""
""producer"",""MicrosoftÂŽ Word para Microsoft 365""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""MicrosoftÂŽ Word para Microsoft 365""
""pdf:docinfo:created"",""2020-12-31T15:50:09Z""
";https://scholar.google.com/scholar?start=510&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095283-1196;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Blockchain Oracles: A Framework for Blockchain-Based Applications;K Mammadzada, M Iqbal, F Milani… ; … Conference on Business …, 2020  Springer;;"Oracles support the access, validation, and transmission of data from external sources to 
blockchain systems. They are important components of blockchain-based architectures. 
However, there exists no guidance on how oracles could be used when designing …";Cité 3 fois;Les 4 versions;[PDF] researchgate.net;https://www.researchgate.net/profile/Mubashar_Iqbal7/publication/344079826_Blockchain_Oracles_A_Framework_for_Blockchain-Based_Applications/links/5f53cef992851c250b967e95/Blockchain-Oracles-A-Framework-for-Blockchain-Based-Applications.pdf;;;
1619095374-1586;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Smart Contract Development Model and the Future of Blockchain Technology;R Richard, H Prabowo, A Trisetyarso… ; … on Blockchain …, 2020  dl.acm.org;;"… The activity is including library construction, resource management, user-centered test, modeling

tools, interaction model, interconnection channel, data feed (oracles), release management, and …

IEEE International Conference on Blockchain and Cryptocurrency, ICBC 2020 …";;null;null;;;;https://scholar.google.com/scholar?start=390&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095404-1719;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;[CITATION][C] Supply Chain Finance Innovation Using Blockchain.................... M. Du, Q. Chen, J. Xiao, H. Yang, and X. Ma 1045 Electronic Regulation of Data Sharing …;M Guerar, A Merlo, M Migliardi, F Palmieri… ; ieeexplore.ieee.org;;"… S. Schneider, M. Leyer, and M. Tate 1184 Trust in Blockchain Cryptocurrency Ecosystem …

C. Patsonakis, K. Samari, A. Kiayias, and M. Roussopoulos 1425 On Public Crowdsource-

Based Mechanisms for a Decentralized Blockchain Oracle …";;null;null;;;;https://scholar.google.com/scholar?start=520&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095365-1544;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Permissioned blockchains for real world applications;A Ismail ;2020 knowledgecommons.lakeheadu.ca;;"… In the concept, nested Merkle trees are used to “tear-off” any parts of the transaction

that an oracle or a notary does not need to … technology. But cryptocurrency and

blockchain technology has far advanced beyond bitcoin …";Autres articles;;[PDF] lakeheadu.ca;https://knowledgecommons.lakeheadu.ca/jspui/bitstream/2453/4641/1/IsmailA2020m-1a.pdf;;"""date"",""2020-05-15T19:40:07Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.6""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""pdfa:PDFVersion"",""A-2b""
""xmpMM:History:Action"",""converted""
""dcterms:created"",""2020-05-15T19:40:00Z""
""language"",""en""
""dc:format"",""application/pdf; version=""""A-2b"""""",""application/pdf; version=1.6""
""Last-Modified"",""2020-05-15T19:40:07Z""
""dcterms:modified"",""2020-05-15T19:40:07Z""
""xmpMM:DocumentID"",""uuid:987da4ad-2b11-43c0-9c2e-8cd134a2594d""
""Last-Save-Date"",""2020-05-15T19:40:07Z""
""access_permission:fill_in_form"",""true""
""xmpMM:History:When"",""2020-05-15T15:40:06Z""
""pdf:docinfo:modified"",""2020-05-15T19:40:07Z""
""meta:save-date"",""2020-05-15T19:40:07Z""
""pdf:encrypted"",""false""
""xmp:CreateDate"",""2020-05-15T15:40:00Z""
""modified"",""2020-05-15T19:40:07Z""
""xmpMM:History:SoftwareAgent"",""Preflight""
""Content-Length"",""637538""
""pdf:hasMarkedContent"",""false""
""xmpMM:History:InstanceID"",""uuid:2203579e-98a2-4e28-895e-6343149cbeab""
""Content-Type"",""application/pdf""
""xmp:ModifyDate"",""2020-05-15T15:40:07Z""
""xmp:MetadataDate"",""2020-05-15T15:40:07Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""pdfaid:conformance"",""B""
""pdf:producer"",""Skia/PDF m84""
""meta:creation-date"",""2020-05-15T19:40:00Z""
""created"",""2020-05-15T19:40:00Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""62""
""Creation-Date"",""2020-05-15T19:40:00Z""
""resourceName"",""IsmailA2020m-1a.pdf""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""353"",""1601"",""488"",""926"",""501"",""1940"",""2095"",""1929"",""1635"",""1768"",""1751"",""1546"",""1964"",""2051"",""2141"",""2082"",""1884"",""550"",""2190"",""1781"",""2148"",""1834"",""2107"",""2138"",""1966"",""2215"",""2022"",""1837"",""2183"",""1682"",""2001"",""1884"",""2082"",""2145"",""2140"",""2005"",""2180"",""1883"",""2024"",""611"",""1921"",""914"",""2059"",""407"",""1484"",""1612"",""1430"",""2067"",""283"",""1734"",""2006"",""2059"",""1839"",""1533"",""1797"",""907"",""1916"",""360"",""1963"",""1854"",""2150"",""1818""
""access_permission:extract_content"",""true""
""pdfaid:part"",""2""
""access_permission:can_print"",""true""
""producer"",""Skia/PDF m84""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""Skia/PDF m84""
""pdf:docinfo:created"",""2020-05-15T19:40:00Z""
";https://scholar.google.com/scholar?start=350&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095334-1420;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;APPLICATION OF BLOCKCHAIN TECHNOLOGY IN SMALL AND LARGE BUSINESSES;EI Bych, NS Moskvicheva, VA Svadkovski ; ?????????? ???????? ? …, 2020  elibrary.ru;;"… A smart contract is written to blockchain, and all logic is placed in the program element of the

blockchain … eg Ethereum) in which smart contracts are recorded and which supports the entry

and exit of oracles (this is a third party, you communicate with the oracle when you need …";Autres articles;;null;;;;https://scholar.google.com/scholar?start=220&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095371-1575;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Revocable identity-based encryption with server-aided ciphertext evolution;Y Sun, Y Mu, W Susilo, F Zhang, A Fu ; Theoretical Computer Science, 2020  Elsevier;;"… Then, A may make queries to the oracles of Private key, Time key, Revocation and Ciphertext

evolution (CE) that are controlled by the challenger. The query-answers between A and C are

described in the following table. The revocation oracle maintains a list RL …";Cité 3 fois;Les 4 versions;null;;;;https://scholar.google.com/scholar?start=380&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095386-1643;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;[LIVRE][B] Rechtshandbuch Kryptowerte: Blockchain, Tokenisierung, Initial Coin Offerings;M Foerster, C Gschnaidtner, L Haffke, B Handke… ;2020 books.google.com;;"Page 1. Maume ˇ Maute Rechtshandbuch Kryptowerte Blockchain ˇ Tokenisierung Initial

Coin Offerings Vahlen Page 2 … Page 3. Page 4. Rechtshandbuch Kryptowerte Blockchain ˇ

Tokenisierung ˇ Initial Coin Offerings Herausgegeben von Prof …";Autres articles;;null;;;;https://scholar.google.com/scholar?start=440&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095346-1466;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Blockchain-based fair payment smart contract for public cloud storage auditing;H Wang, H Qin, M Zhao, X Wei, H Shen, W Susilo ; Information Sciences, 2020  Elsevier;;"… Construct an efficient NI-PPDP scheme, and give formal proof in the random oracle model; • … By

combining decentralized consensus technique and append-only data structure, a type of

cryptocurrency without the … The framework used by bitcoin is generally called blockchain …";Cité 25 fois;Les 3 versions;null;;;;https://scholar.google.com/scholar?start=270&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095311-1314;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;[HTML][HTML] Searchain: Blockchain-based private keyword search in decentralized storage;P Jiang, F Guo, K Liang, J Lai, Q Wen ; Future Generation Computer …, 2020  Elsevier;;"… The cryptocurrency system builds on top of a novel technology named blockchain [16], which

is … aggregate signed data based on uncertified claw-free permutations in the random oracle model,

to … includes transaction nodes with a peer-to-peer structure and a blockchain with all …";Cité 60 fois;Les 6 versions;[HTML] sciencedirect.com;https://www.sciencedirect.com/science/article/pii/S0167739X17318630?casa_token=5inJDiV9ymQAAAAA:isGp9fVi8KGCvzZe1BEVdZOBJgE8YLh-yFjyjTdCVQD-MVm2hPmcPHdVEfy4EHxFmYoQVH--;;;https://scholar.google.com/scholar?start=120&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095355-1513;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;[PDF][PDF] THE LEGAL PRACTICALITIES OF THE USE OF BLOCKCHAIN AS A FORM OF ONLINE DISPUTE RESOLUTION;T Koroye ; academia.edu;;"… US Courts, in determining issues relating to cryptocurrency and blockchain, held inter alia that …

105 Supra 9 106 Kelvin FK Low and Eliza Mik, 'Pause The Blockchain Legal Revolution', (2020)

69 ICLQ 135 107 Chris Skinner, 'The Wild West of Crypto', (The Finanser …";Autres articles;;[PDF] academia.edu;https://www.academia.edu/download/64104282/THE%20LEGAL%20PRACTICALITIES%20OF%20THE%20USE%20OF%20BLOCKCHAIN%20AS%20A%20FORM%20OF%20ONLINE%20DISPUTE%20RESOLUTION.pdf;;;https://scholar.google.com/scholar?start=310&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095349-1478;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;[PDF][PDF] Blockchain Technology and Maritime Shipping: A Primer;EH Green, EW Carr, JJ Winebrake, JJ Corbett ;2020 maritime.dot.gov;;"… or function as an intermediary. Smart contracts inherit the properties of blockchain (ie immutability,

traceability, transparency), yet offer more flexibility than standard blockchain. The use of smart

contracts requires “oracles”, which provide necessary data on real world events and …";Cité 1 fois;;[PDF] dot.gov;https://www.maritime.dot.gov/sites/marad.dot.gov/files/2020-07/MARAD%20Blockchain%20Final%20Primer%20%2820200622%29.pdf;;"""date"",""2020-07-22T13:15:19Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.4""
""xmp:CreatorTool"",""Word""
""pdf:docinfo:title"",""Microsoft Word - MARAD Blockchain Final Primer 20200608.docx""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dcterms:created"",""2020-06-09T18:56:17Z""
""language"",""en""
""Last-Modified"",""2020-07-22T13:15:19Z""
""dcterms:modified"",""2020-07-22T13:15:19Z""
""dc:format"",""application/pdf; version=1.4""
""title"",""Microsoft Word - MARAD Blockchain Final Primer 20200608.docx""
""xmpMM:DocumentID"",""uuid:c541951a-af25-4569-a9ec-39dc37cdd6b2""
""Last-Save-Date"",""2020-07-22T13:15:19Z""
""pdf:docinfo:creator_tool"",""Word""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2020-07-22T13:15:19Z""
""meta:save-date"",""2020-07-22T13:15:19Z""
""pdf:encrypted"",""false""
""dc:title"",""Microsoft Word - MARAD Blockchain Final Primer 20200608.docx""
""xmp:CreateDate"",""2020-06-09T18:56:17Z""
""modified"",""2020-07-22T13:15:19Z""
""Content-Length"",""541076""
""pdf:hasMarkedContent"",""false""
""Content-Type"",""application/pdf""
""xmp:ModifyDate"",""2020-07-22T09:15:19Z""
""xmp:MetadataDate"",""2020-07-22T09:15:19Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""pdf:producer"",""macOS Version 10.15.4 (Build 19E287) Quartz PDFContext""
""meta:creation-date"",""2020-06-09T18:56:17Z""
""created"",""2020-06-09T18:56:17Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""46""
""Creation-Date"",""2020-06-09T18:56:17Z""
""resourceName"",""MARAD%20Blockchain%20Final%20Primer%20%2820200622%29.pdf""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""235"",""4706"",""4391"",""510"",""1461"",""914"",""2293"",""2135"",""1949"",""2349"",""2402"",""2248"",""2506"",""2502"",""2341"",""2528"",""2108"",""2462"",""2403"",""2414"",""2406"",""2616"",""2496"",""2559"",""2547"",""2179"",""2490"",""2137"",""2429"",""2351"",""2099"",""2369"",""2682"",""2629"",""2711"",""2633"",""2555"",""2468"",""2492"",""1067"",""2180"",""2276"",""2264"",""2234"",""2433"",""553""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""producer"",""macOS Version 10.15.4 (Build 19E287) Quartz PDFContext""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""macOS Version 10.15.4 (Build 19E287) Quartz PDFContext""
""pdf:docinfo:created"",""2020-06-09T18:56:17Z""
";https://scholar.google.com/scholar?start=280&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095323-1373;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Design of platforms based on blockchain technology applied to different use cases;Y Mezquita Martín ;2020 gredos.usal.es;;"… consensus, deciding the solution of a task in a decentralized way: – The oracles provide a … a result

given is not between acceptable and previously defined margins, the oracle in question … of IoT

system, control and configuration of IoT devices can be made through a blockchain …";Autres articles;Version HTML;[PDF] usal.es;https://gredos.usal.es/bitstream/handle/10366/144154/BISITE_MezquitaY_Designofplatforms.pdf?sequence=1&isAllowed=y;;"""date"",""2020-11-19T12:44:48Z""
""pdf:PDFVersion"",""1.7""
""xmp:CreatorTool"",""Adobe InDesign CC 2015 (Macintosh)""
""pdf:docinfo:title"",""The role of Artificial Intelligence and distributed computing in IoT applications""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""Aquilafuente; 287, 148 p.""
""language"",""en""
""dc:format"",""application/pdf; version=1.7""
""pdf:docinfo:creator_tool"",""Adobe InDesign CC 2015 (Macintosh)""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""The role of Artificial Intelligence and distributed computing in IoT applications""
""xmp:CreateDate"",""2020-08-04T08:25:35Z""
""modified"",""2020-11-19T12:44:48Z""
""cp:subject"",""Aquilafuente; 287, 148 p.""
""pdf:docinfo:subject"",""Aquilafuente; 287, 148 p.""
""pdf:hasMarkedContent"",""false""
""xmp:ModifyDate"",""2020-11-19T13:44:48Z""
""pdf:docinfo:creator"",""Sara RodrĂ­guez GonzĂĄlez""
""meta:author"",""Sara RodrĂ­guez GonzĂĄlez"",""Fernando de la Prieta Pintado"",""JosĂŠ Alberto GarcĂ­a Coria"",""Roberto Casado Vara""
""trapped"",""False""
""meta:creation-date"",""2020-08-04T06:25:35Z""
""created"",""2020-08-04T06:25:35Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-08-04T06:25:35Z""
""resourceName"",""BISITE_MezquitaY_Designofplatforms.pdf""
""xmpMM:DerivedFrom:DocumentID"",""xmp.did:d6a52dde-ecb2-4592-9032-df3bbdaa69fd""
""GTS_PDFXVersion"",""PDF/X-4""
""Author"",""Sara RodrĂ­guez GonzĂĄlez"",""Fernando de la Prieta Pintado"",""JosĂŠ Alberto GarcĂ­a Coria"",""Roberto Casado Vara""
""producer"",""Adobe PDF Library 15.0""
""pdf:docinfo:producer"",""Adobe PDF Library 15.0""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""dc:description"",""Aquilafuente; 287, 148 p.""
""pdf:docinfo:custom:GTS_PDFXVersion"",""PDF/X-4""
""Keywords"",""Computer Science; Ciencias de la computaciĂłn"",""Computer Science; Ciencias de la computaciĂłn""
""access_permission:modify_annotations"",""true""
""dc:creator"",""Sara RodrĂ­guez GonzĂĄlez"",""Fernando de la Prieta Pintado"",""JosĂŠ Alberto GarcĂ­a Coria"",""Roberto Casado Vara""
""description"",""Aquilafuente; 287, 148 p.""
""dcterms:created"",""2020-08-04T06:25:35Z""
""Last-Modified"",""2020-11-19T12:44:48Z""
""dcterms:modified"",""2020-11-19T12:44:48Z""
""title"",""The role of Artificial Intelligence and distributed computing in IoT applications""
""xmpMM:DocumentID"",""xmp.id:4d49a27e-7a9d-4713-b3e7-0d509b0722d1""
""Last-Save-Date"",""2020-11-19T12:44:48Z""
""pdf:docinfo:keywords"",""Computer Science; Ciencias de la computaciĂłn""
""pdf:docinfo:modified"",""2020-11-19T12:44:48Z""
""meta:save-date"",""2020-11-19T12:44:48Z""
""Content-Length"",""104592""
""Content-Type"",""application/pdf""
""xmp:MetadataDate"",""2020-11-19T13:44:48Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Sara RodrĂ­guez GonzĂĄlez"",""Fernando de la Prieta Pintado"",""JosĂŠ Alberto GarcĂ­a Coria"",""Roberto Casado Vara""
""pdf:producer"",""Adobe PDF Library 15.0""
""dc:subject"",""Computer Science; Ciencias de la computaciĂłn"",""Computer Science; Ciencias de la computaciĂłn""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""15""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""1670"",""2378"",""2529"",""2433"",""2536"",""2215"",""2469"",""2368"",""2384"",""2326"",""2619"",""2586"",""2828"",""2925"",""1437""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""Computer Science; Ciencias de la computaciĂłn"",""Computer Science; Ciencias de la computaciĂłn""
""xmpMM:DerivedFrom:InstanceID"",""xmp.iid:a9c01674-282c-4a52-8ec9-870eb2119372""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-08-04T06:25:35Z""
";https://scholar.google.com/scholar?start=170&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095395-1681;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Blockchain Applications and Company Law;F Möslein ; Legal Technology Transformation in Practice, 2020  papers.ssrn.com;;"… Thomale, 'Crypto-Securities Regulation: ICOs, Token Sales and Cryptocurrencies under EU

Financial Law' (2018) 15 … 6 In a third step, blockchain technology can be used to not only enforce

regulations … as stock market prices or turnover figures) by using so-called ""oracles"" as an …";Autres articles;;null;;;;https://scholar.google.com/scholar?start=480&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095399-1695;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Blockchain Applications and Future Opportunities in Transportation;N Subramanian, A Chaudhuri, Y Kay?kc? ; Blockchain and Supply Chain …, 2020  Springer;;"… Since the perception of blockchain was mostly related to the activities in cryptocurrency ecosystem

due to early applications, and was not as a decentralized, distributed asset exchange technology

for sharing data with partners … Blockchain across Oracle: Understand the …";Cité 1 fois;;null;;;;https://scholar.google.com/scholar?start=500&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095309-1304;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;[PDF][PDF] The law of blockchain;G Dimitropoulos ; Wash. L. Rev., 2020  HeinOnline;;"… 14, 2015), https://firstmonday.org/ojs/index.php/fm/article/view/6198/5163 [https://perma.cc/6QDW-

M4ZC]; Michael Abramowicz, Cryptocurrency-Based Law, 58 ARIZ … See generally Jason Brett,

Congress Has Now Introduced 32 Crypto and Blockchain Bills, FORBES (Apr …";Cité 1 fois;Les 8 versions;[PDF] heinonline.org;https://heinonline.org/hol-cgi-bin/get_pdf.cgi?handle=hein.journals/washlr95&section=28&casa_token=YuYd9uaQBjoAAAAA:HXdfdEhYHTcB0yzpvsS9whOkllr58IC-tF7otjfIreZjHbn5wG6BMXQR6GjwOWn0Qk2KVjs;;"""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""REFRESH"",""1; url=https://heinonline.org/HOL/Page?handle=hein.journals/washlr95&div=28&g_sent=1&casa_token=YuYd9uaQBjoAAAAA:HXdfdEhYHTcB0yzpvsS9whOkllr58IC-tF7otjfIreZjHbn5wG6BMXQR6GjwOWn0Qk2KVjs""
""Content-Encoding"",""UTF-8""
""resourceName"",""get_pdf.cgi""
""language"",""""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=110&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095332-1413;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Policy-based Chameleon Hash for Blockchain Rewriting with Black-box Accountability;Y Tian, N Li, Y Li, P Szalachowski, J Zhou ; Annual Computer Security …, 2020  dl.acm.org;;"… In the permisssioned blockchain, the transaction owner is an honest party … We define a formal

experiment between an adversary A and a simulator S in Figure 2. The security experiment allows

A to access a left-or- right HashOrAdapt oracle, which ensures that the randomness …";Autres articles;;null;;;;https://scholar.google.com/scholar?start=210&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095330-1397;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Diffusion of blockchain in insurance industry: An analysis through the review of academic and trade literature;AK Kar, L Navin ; Telematics and Informatics, 2020  Elsevier;;"… Apart from bitcoin, the most popular cryptocurrency, almost around 600 cryptocurrencies were

created, and these … Smart contracts are pieces of codes embedded in the blockchain that behaves

in a certain … This is done using the help of Oracles, which are the services that take …";Autres articles;;null;;;;https://scholar.google.com/scholar?start=200&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095292-1243;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;A Blockchain-based Method for Decentralizing the ACME Protocol to Enhance Trust in PKI;EF Kfoury, D Khoury, A AlSabeh… ; 2020 43rd …, 2020  ieeexplore.ieee.org;;"… Smart Contract Oracle Contract Blockchain Network Internet Device Web server Verify Domain

Ownership Register Domain Challenge Response Oracle Service Attestators Intel SGX TLSNotary

SafetyNet Qualcomm Nano Leger … The main challenge with oracles is trust …";Autres articles;;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/9158468/9163396/09163555.pdf?casa_token=J4EJ4WvfTS4AAAAA:ZphxN-ezOGBRan0Ad49VhvhbJB6JWwiGhfWeHJWUzl5FqCTfqSmwX01npDTWC_Q3JvqXVKg1L08;;"""og:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""twitter:title"",""A Blockchain-based Method for Decentralizing the ACME Protocol to Enhance Trust in PKI""
""twitter:card"",""summary""
""Description"",""Blockchain technology is the cornerstone of digital trust and systems' decentralization. The necessity of eliminating trust in computing systems has triggered r""
""og:title"",""A Blockchain-based Method for Decentralizing the ACME Protocol to Enhance Trust in PKI""
""resourceName"",""09163555.pdf""
""language"",""en""
""title"",""A Blockchain-based Method for Decentralizing the ACME Protocol to Enhance Trust in PKI | IEEE Conference Publication | IEEE Xplore""
""og:description"",""Blockchain technology is the cornerstone of digital trust and systems' decentralization. The necessity of eliminating trust in computing systems has triggered researchers to investigate the applicability of Blockchain to decentralize the conventional security models. Specifically, researchers continuously aim at minimizing trust in the well-known Public Key Infrastructure (PKI) model which currently requires a trusted Certificate Authority (CA) to sign digital certificates. Recently, the Automated Certificate Management Environment (ACME) was standardized as a certificate issuance automation protocol. It minimizes the human interaction by enabling certificates to be automatically requested, verified, and installed on servers. ACME only solved the automation issue, but the trust concerns remain as a trusted CA is required. In this paper we propose decentralizing the ACME protocol by using the Blockchain technology to enhance the current trust issues of the existing PKI model and to eliminate the need for a trusted CA. The system was implemented and tested on Ethereum Blockchain, and the results showed that the system is feasible in terms of cost, speed, and applicability on a wide range of devices including Internet of Things (IoT) devices.""
""twitter:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-UA-Compatible"",""IE=Edge""
""viewport"",""width=device-width, initial-scale=1.0""
""dc:title"",""A Blockchain-based Method for Decentralizing the ACME Protocol to Enhance Trust in PKI | IEEE Conference Publication | IEEE Xplore""
""twitter:description"",""Blockchain technology is the cornerstone of digital trust and systems' decentralization. The necessity of eliminating trust in computing systems has triggered researchers to investigate the applicability of Blockchain to decentralize the conventional security models. Specifically, researchers continuously aim at minimizing trust in the well-known Public Key Infrastructure (PKI) model which currently requires a trusted Certificate Authority (CA) to sign digital certificates. Recently, the Automated Certificate Management Environment (ACME) was standardized as a certificate issuance automation protocol. It minimizes the human interaction by enabling certificates to be automatically requested, verified, and installed on servers. ACME only solved the automation issue, but the trust concerns remain as a trusted CA is required. In this paper we propose decentralizing the ACME protocol by using the Blockchain technology to enhance the current trust issues of the existing PKI model and to eliminate the need for a trusted CA. The system was implemented and tested on Ethereum Blockchain, and the results showed that the system is feasible in terms of cost, speed, and applicability on a wide range of devices including Internet of Things (IoT) devices.""
""Content-Encoding"",""UTF-8""
""Content-Type-Hint"",""text/html; charset=utf-8""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=40&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095378-1612;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Silver Bullet for All Trust Issues? Blockchain-Based Trust Patterns for Collaborative Business Processes;M Müller, N Ostern, M Rosemann ; International Conference on Business …, 2020  Springer;;"… Injecting outside data has been studied as the blockchain's oracle problem before [25] … As a

software connector [24], the blockchain technology can be used as an interface for … Further,

crypto-economic mechanisms can be used to incentivize collaborators for correct behavior …";Cité 3 fois;Les 4 versions;[PDF] qut.edu.au;https://eprints.qut.edu.au/205038/1/68709947.pdf;;"""date"",""2021-04-27T18:40:33Z""
""pdf:unmappedUnicodeCharsPerPage"",""1"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.5""
""xmp:CreatorTool"",""pdftk 2.02 - www.pdftk.com""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dcterms:created"",""2021-04-27T18:40:33Z""
""language"",""en""
""Last-Modified"",""2021-04-27T18:40:33Z""
""dcterms:modified"",""2021-04-27T18:40:33Z""
""dc:format"",""application/pdf; version=1.5""
""Last-Save-Date"",""2021-04-27T18:40:33Z""
""pdf:docinfo:creator_tool"",""pdftk 2.02 - www.pdftk.com""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2021-04-27T18:40:33Z""
""meta:save-date"",""2021-04-27T18:40:33Z""
""pdf:encrypted"",""false""
""modified"",""2021-04-27T18:40:33Z""
""Content-Length"",""442937""
""pdf:hasMarkedContent"",""false""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""meta:creation-date"",""2021-04-27T18:40:33Z""
""created"",""2021-04-27T18:40:33Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""16""
""Creation-Date"",""2021-04-27T18:40:33Z""
""resourceName"",""68709947.pdf""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""1515"",""2253"",""2704"",""2154"",""2458"",""2565"",""2217"",""1868"",""2729"",""2555"",""2583"",""2611"",""2739"",""2362"",""2569"",""2723""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""producer"",""itext-paulo-155 (itextpdf.sf.net-lowagie.com)""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""itext-paulo-155 (itextpdf.sf.net-lowagie.com)""
""pdf:docinfo:created"",""2021-04-27T18:40:33Z""
";https://scholar.google.com/scholar?start=410&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095346-1472;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;[HTML][HTML] Some simple economics of the blockchain;C Catalini, JS Gans ; Communications of the ACM, 2020  dl.acm.org;;"… list to Bitcoin, a peer-to-peer electronic cash system “based on crypto graphic proof … Trusted,

independent oracles can also be incorporated to ensure that such financial contracts can … of the

audit capability of a third party as surveillance or monitoring, blockchain technology can …";Cité 19 fois;;[HTML] acm.org;https://dl.acm.org/doi/fullHtml/10.1145/3359552;;;https://scholar.google.com/scholar?start=270&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095388-1644;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;[PDF][PDF] In search of lost security. A systematic literature review on how blockchain can save the IoT revolution;R Occa, Y Borbon;Galvez, F Strozzi  liucbs.it;;"… perspectives of these technologies, identifying the perceptions of the economic actors concerned,

or the use of the first cryptocurrency systems developed … 2019) 'Trust management in a blockchain

based fog computing platform with trustless smart oracles', Future Generation …";Autres articles;Version HTML;[PDF] liucbs.it;http://www.liucbs.it/wp-content/uploads/ID-51.pdf;;;https://scholar.google.com/scholar?start=450&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095344-1455;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;[HTML][HTML] Blockchain and Smart Contracts. Approach to their Legal Problems and Challenges;JA Padilla Sanchez ; Revista de Derecho Privado, 2020  scielo.org.co;;"… 24 ""And so, in laymen's terms, the blockchain can be described as a decentralised,

peer-validated crypto-ledger that provides a publicly visible, chronological and

permanent record of all prior transactions. It resembles a spreadsheet …";Cité 1 fois;Les 2 versions;[HTML] scielo.org.co;http://www.scielo.org.co/scielo.php?script=sci_arttext&pid=S0123-43662020000200175;;"""citation_title"",""Blockchain y contratos inteligentes: aproximaciĂłn a sus problemĂĄticas y retos jurĂ­dicos""
""citation_author_institution"",""Universidad Externado de Colombia, BogotĂĄ, Colombia"",""Universidad Externado de Colombia, BogotĂĄ, Colombia"",""Universidad Externado de Colombia, BogotĂĄ, Colombia"",""Universidad Externado de Colombia, BogotĂĄ, Colombia""
""citation_publisher"",""Universidad Externado de Colombia""
""citation_journal_title"",""Revista de Derecho Privado""
""citation_id"",""10.18601/01234366.n39.08""
""language"",""es""
""citation_date"",""12/2020""
""title"",""Blockchain y contratos inteligentes: aproximaciĂłn a sus problemĂĄticas y retos jurĂ­dicos""
""citation_issn"",""0123-4366""
""dc:title"",""Blockchain y contratos inteligentes: aproximaciĂłn a sus problemĂĄticas y retos jurĂ­dicos""
""citation_language"",""es""
""citation_fulltext_html_url"",""http://www.scielo.org.co/scielo.php?script=sci_arttext&pid=S0123-43662020000200175&lng=en&nrm=iso&tlng=es""
""Content-Encoding"",""UTF-8""
""Content-Type-Hint"",""text/html; charset=UTF-8""
""citation_pdf_url"",""http://www.scielo.org.co/pdf/rdp/n39/0123-4366-rdp-39-175.pdf""
""citation_lastpage"",""201""
""Content-Type"",""text/html; charset=UTF-8""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""citation_author"",""PADILLA SÁNCHEZ, JORGE ALBERTO"",""PADILLA SÁNCHEZ, JORGE ALBERTO""
""resourceName"",""scielo.php""
""Pragma"",""no-cache""
""citation_abstract_html_url"",""http://www.scielo.org.co/scielo.php?script=sci_abstract&pid=S0123-43662020000200175&lng=en&nrm=iso&tlng=es""
""citation_issue"",""39""
""citation_firstpage"",""175""
""citation_doi"",""10.18601/01234366.n39.08""
""citation_journal_title_abbrev"",""Rev. Derecho Privado""
""Expires"",""Mon, 06 Jan 1990 00:00:01 GMT""
""citation_volume"",""""
";https://scholar.google.com/scholar?start=260&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095306-1300;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Blockchain for organising effective grass-roots actions on a global commons: saving the planet;J Ducrée, M Etzrodt, B Gordijn, M Gravitt… ; … in Blockchain, 2020  ueaeprints.uea.ac.uk;;"… Within smart contracts, so-called “oracles” (Blockchain Oracles, 2020) enact automatic decision

making … Stablecoins are available to tackle the volatility of crypto- against fiat currencies … and a

huge community advances technologies to widen the blockchain-innate bottlenecks …";Cité 6 fois;Les 3 versions;[PDF] uea.ac.uk;https://ueaeprints.uea.ac.uk/id/eprint/75923/7/Published_Version.pdf;;"""date"",""2020-10-02T15:53:46Z""
""pdf:PDFVersion"",""1.5""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:docinfo:title"",""Blockchain for Organizing Effective Grass-Roots Actions on a Global Commons: Saving the Planet""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""An overwhelming majority of experts has been flagging for decades that """"Saving the Planet"""" requires immediate, persistent and drastic action to curb a variety of catastrophic risks over the 21st century.""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""Blockchain for Organizing Effective Grass-Roots Actions on a Global Commons: Saving the Planet""
""xmp:CreateDate"",""2020-10-02T11:45:54Z""
""modified"",""2020-10-02T15:53:46Z""
""cp:subject"",""An overwhelming majority of experts has been flagging for decades that """"Saving the Planet"""" requires immediate, persistent and drastic action to curb a variety of catastrophic risks over the 21st century.""
""pdf:docinfo:subject"",""An overwhelming majority of experts has been flagging for decades that """"Saving the Planet"""" requires immediate, persistent and drastic action to curb a variety of catastrophic risks over the 21st century.""
""pdf:hasMarkedContent"",""false""
""xmp:ModifyDate"",""2020-10-02T21:23:46Z""
""pdf:docinfo:creator"",""Jens DucrĂŠe""
""meta:author"",""Jens DucrĂŠe""
""meta:creation-date"",""2020-10-02T06:15:54Z""
""created"",""2020-10-02T06:15:54Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-10-02T06:15:54Z""
""resourceName"",""Published_Version.pdf""
""Author"",""Jens DucrĂŠe""
""producer"",""pdfTeX-1.40.15""
""pdf:docinfo:producer"",""pdfTeX-1.40.15""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""dc:description"",""An overwhelming majority of experts has been flagging for decades that """"Saving the Planet"""" requires immediate, persistent and drastic action to curb a variety of catastrophic risks over the 21st century.""
""Keywords"",""wisdom of the crowds, trust, truth finding, staking, reputation, competitive parallelisation, prediction markets, decentralised autonomous organisation (DAO)"",""wisdom of the crowds, trust, truth finding, staking, reputation, competitive parallelisation, prediction markets, decentralised autonomous organisation (DAO)""
""access_permission:modify_annotations"",""true""
""PDFVersion"",""1.5""
""dc:creator"",""Jens DucrĂŠe""
""description"",""An overwhelming majority of experts has been flagging for decades that """"Saving the Planet"""" requires immediate, persistent and drastic action to curb a variety of catastrophic risks over the 21st century.""
""dcterms:created"",""2020-10-02T06:15:54Z""
""Last-Modified"",""2020-10-02T15:53:46Z""
""dcterms:modified"",""2020-10-02T15:53:46Z""
""title"",""Blockchain for Organizing Effective Grass-Roots Actions on a Global Commons: Saving the Planet""
""xmpMM:DocumentID"",""uuid:f267a8d7-ae46-4c90-85f2-00ae4620ae41""
""Last-Save-Date"",""2020-10-02T15:53:46Z""
""pdf:docinfo:keywords"",""wisdom of the crowds, trust, truth finding, staking, reputation, competitive parallelisation, prediction markets, decentralised autonomous organisation (DAO)""
""pdf:docinfo:modified"",""2020-10-02T15:53:46Z""
""meta:save-date"",""2020-10-02T15:53:46Z""
""pdf:docinfo:custom:PDFVersion"",""1.5""
""Content-Length"",""896438""
""Content-Type"",""application/pdf""
""xmp:MetadataDate"",""2020-10-02T21:23:46Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Jens DucrĂŠe""
""pdf:producer"",""pdfTeX-1.40.15""
""dc:subject"",""wisdom of the crowds, trust, truth finding, staking, reputation, competitive parallelisation, prediction markets, decentralised autonomous organisation (DAO)"",""wisdom of the crowds, trust, truth finding, staking, reputation, competitive parallelisation, prediction markets, decentralised autonomous organisation (DAO)""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""11""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""3590"",""5735"",""3741"",""5491"",""5456"",""5651"",""3231"",""5381"",""7693"",""7697"",""5083""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""meta:keyword"",""wisdom of the crowds, trust, truth finding, staking, reputation, competitive parallelisation, prediction markets, decentralised autonomous organisation (DAO)"",""wisdom of the crowds, trust, truth finding, staking, reputation, competitive parallelisation, prediction markets, decentralised autonomous organisation (DAO)""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-10-02T06:15:54Z""
";https://scholar.google.com/scholar?start=100&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095404-1722;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Teaching Applications and Implications of Blockchain via Project-Based Learning: A Case Study;K Mentzer, M Frydenberg, DJ Yates ;2020 digitalcommons.bryant.edu;;"… 3. CCRD used the concept of 'oracles' to build the most informative property information website

in … What emerged was the Crypto Ice Cream Shop (see Appendix F, Figure 9). The intent … Appendix

F, Figure 10) and see the transaction on the Ropsten test blockchain along with …";Autres articles;;[PDF] bryant.edu;https://digitalcommons.bryant.edu/cgi/viewcontent.cgi?article=1038&context=cisjou;;"""date"",""2021-04-09T16:47:33Z""
""pdf:PDFVersion"",""1.7""
""xmp:CreatorTool"",""Appligent pdfHarmony 2.0""
""pdf:docinfo:title"",""Teaching Applications and Implications of Blockchain via Project-Based Learning: A Case Study""
""Appligent"",""pdfHarmony 2.0 Linux Kernel 2.6 64bit Mar 13 2012 Library 9.0.1""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""Computer science""
""language"",""en""
""dc:format"",""application/pdf; version=1.7""
""pdf:docinfo:creator_tool"",""Appligent pdfHarmony 2.0""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""Teaching Applications and Implications of Blockchain via Project-Based Learning: A Case Study""
""xmp:CreateDate"",""2021-04-09T09:47:33Z""
""modified"",""2021-04-09T16:47:33Z""
""cp:subject"",""Computer science""
""pdf:docinfo:subject"",""Computer science""
""pdf:hasMarkedContent"",""true""
""xmp:ModifyDate"",""2021-04-09T09:47:33Z""
""pdf:docinfo:creator"",""Kevin Mentzer, Mark Frydenberg, and David J. Yates""
""meta:author"",""Kevin Mentzer, Mark Frydenberg, and David J. Yates""
""meta:creation-date"",""2021-04-09T16:47:33Z""
""created"",""2021-04-09T16:47:33Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2021-04-09T16:47:33Z""
""resourceName"",""viewcontent.cgi""
""Author"",""Kevin Mentzer, Mark Frydenberg, and David J. Yates""
""producer"",""Prince 12.5 (www.princexml.com)""
""pdf:docinfo:producer"",""Prince 12.5 (www.princexml.com)""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""dc:description"",""Computer science""
""Keywords"",""blockchain; distributed ledger; emerging technologies; project-based learning; self-regulated learning; peer learning"",""blockchain; distributed ledger; emerging technologies; project-based learning; self-regulated learning; peer learning""
""access_permission:modify_annotations"",""true""
""dc:creator"",""Kevin Mentzer, Mark Frydenberg, and David J. Yates""
""description"",""Computer science""
""dcterms:created"",""2021-04-09T16:47:33Z""
""Last-Modified"",""2021-04-09T16:47:33Z""
""dcterms:modified"",""2021-04-09T16:47:33Z""
""pdf:docinfo:custom:Appligent"",""pdfHarmony 2.0 Linux Kernel 2.6 64bit Mar 13 2012 Library 9.0.1""
""title"",""Teaching Applications and Implications of Blockchain via Project-Based Learning: A Case Study""
""xmpMM:DocumentID"",""uuid:c4aafa02-b0f9-11b2-0a00-a0fe87020000""
""Last-Save-Date"",""2021-04-09T16:47:33Z""
""pdf:docinfo:keywords"",""blockchain; distributed ledger; emerging technologies; project-based learning; self-regulated learning; peer learning""
""pdf:docinfo:modified"",""2021-04-09T16:47:33Z""
""meta:save-date"",""2021-04-09T16:47:33Z""
""Content-Length"",""1323764""
""Content-Type"",""application/pdf""
""xmp:MetadataDate"",""2021-04-09T09:47:33Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Kevin Mentzer, Mark Frydenberg, and David J. Yates""
""dc:language"",""en""
""pdf:producer"",""Prince 12.5 (www.princexml.com)""
""dc:subject"",""blockchain; distributed ledger; emerging technologies; project-based learning; self-regulated learning; peer learning"",""blockchain; distributed ledger; emerging technologies; project-based learning; self-regulated learning; peer learning""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""30""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""1385"",""2427"",""4323"",""5052"",""3938"",""3389"",""4540"",""4989"",""4628"",""4437"",""3853"",""3799"",""1438"",""438"",""3887"",""4550"",""2975"",""2982"",""4581"",""4621"",""3074"",""2655"",""2121"",""1671"",""360"",""398"",""369"",""471"",""393"",""316""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""meta:keyword"",""blockchain; distributed ledger; emerging technologies; project-based learning; self-regulated learning; peer learning"",""blockchain; distributed ledger; emerging technologies; project-based learning; self-regulated learning; peer learning""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2021-04-09T16:47:33Z""
";https://scholar.google.com/scholar?start=520&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095332-1405;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Application of Blockchain in Academic Credit Bank System;N Yan ; International Conference on Technology in Education, 2020  Springer;;"… Virtual Machine to process peer-to-peer contracts through its dedicated cryptocurrency Ether

(Buterin … and corresponding courses/certificates catalogs into smart contracts and publish them

on the blockchain. The Oracle can read some data that the student can prove his/her …";Autres articles;;null;;;;https://scholar.google.com/scholar?start=210&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095399-1698;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;[PDF][PDF] Towards Cross-Blockchain Smart Contracts;M Sigwart, P Frauenthaler, C Spanring, S Schulte ; dsg.tuwien.ac.at;;"… URL: https://arxiv.org/abs/2002.12837. [8] J. Heiss et al. “From oracles to trustworthy data

on-chaining systems” … [11] M. Sigwart et al. Decentralized Cross-Blockchain Asset Trans- fers …

[12] A. Zamyatin et al. “XCLAIM: Trustless, Interoperable, Cryptocurrency-Backed Assets” …";Autres articles;;[PDF] tuwien.ac.at;https://dsg.tuwien.ac.at/projects/tast/pub/tast-white-paper-10.pdf;;"""date"",""2020-09-03T08:40:47Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2020-09-03T08:40:47Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.19 (TeX Live 2018) kpathsea version 6.3.0""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2020-09-03T08:40:47Z""
""created"",""2020-09-03T08:40:47Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-09-03T08:40:47Z""
""resourceName"",""tast-white-paper-10.pdf""
""Author"",""""
""producer"",""pdfTeX-1.40.19""
""pdf:docinfo:producer"",""pdfTeX-1.40.19""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2020-09-03T08:40:47Z""
""Last-Modified"",""2020-09-03T08:40:47Z""
""dcterms:modified"",""2020-09-03T08:40:47Z""
""title"",""""
""Last-Save-Date"",""2020-09-03T08:40:47Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2020-09-03T08:40:47Z""
""meta:save-date"",""2020-09-03T08:40:47Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.19 (TeX Live 2018) kpathsea version 6.3.0""
""Content-Length"",""142092""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""5""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""3849"",""3612"",""5180"",""3795"",""3316""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-09-03T08:40:47Z""
";https://scholar.google.com/scholar?start=500&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095341-1444;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Data money: The socio-technical infrastructure of cryptocurrency blockchains;K Caliskan ; Economy and Society, 2020  Taylor & Francis;;"… chain world events to trigger the realization of 'in-chain contracts', or making 'oracles', as coders …

blockchains operate as a 'digital' or 'virtual world', sometimes referred to as 'crypto-world' and …

and physical world (in 4), referring to anything that is located outside of the blockchain …";Cité 12 fois;Les 3 versions;null;;;;https://scholar.google.com/scholar?start=250&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095367-1562;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;A novel blockchain-based privacy-preserving framework for online social networks;S Zhang, T Yao, VK Arthur Sandor, TH Weng… ; Connection …, 2020  Taylor & Francis;;"… blockchain, which served as the public transaction ledger of the Bitcoin cryptocurrency (Nakamoto,

2008 … H1,H2 The identifier collection of queried results, and two random oracles Pubui ,Priui … network

users, blockchain and cloud server (ie online social network services provider …";Cité 1 fois;;null;;;;https://scholar.google.com/scholar?start=360&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095283-1199;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Foundational Oracle Patterns: Connecting Blockchain to the Off-chain World;R Mühlberger, S Bachhofner, EC Ferrer… ; … Conference on Business …, 2020  Springer;;"Blockchain has evolved into a platform for decentralized applications, with beneficial 
properties like high integrity, transparency, and resilience against censorship and 
tampering. However, blockchains are closed-world systems which do not have access to …";Cité 3 fois;Les 9 versions;[PDF] arxiv.org;https://arxiv.org/pdf/2007.14946;;"""date"",""2020-07-30T00:51:21Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2020-07-30T00:51:21Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016) kpathsea version 6.2.2""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2020-07-30T00:51:21Z""
""created"",""2020-07-30T00:51:21Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-07-30T00:51:21Z""
""resourceName"",""2007.14946""
""Author"",""""
""producer"",""pdfTeX-1.40.17""
""pdf:docinfo:producer"",""pdfTeX-1.40.17""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2020-07-30T00:51:21Z""
""Last-Modified"",""2020-07-30T00:51:21Z""
""dcterms:modified"",""2020-07-30T00:51:21Z""
""title"",""""
""Last-Save-Date"",""2020-07-30T00:51:21Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2020-07-30T00:51:21Z""
""meta:save-date"",""2020-07-30T00:51:21Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016) kpathsea version 6.2.2""
""Content-Length"",""1297578""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""15""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""2399"",""3038"",""3261"",""3137"",""1781"",""2007"",""2715"",""2311"",""2732"",""2210"",""2941"",""2785"",""2484"",""2827"",""3368""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-07-30T00:51:21Z""
";
1619095302-1278;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;A survey on blockchain interoperability: Past, present, and future trends;R Belchior, A Vasconcelos, S Guerreiro… ; arXiv preprint arXiv …, 2020  arxiv.org;;"… For example, Steemit1 is a social blogging dApp that rewards content-creators with cryptocurrency …

To facilitate communication among blockchains, one can rely on decentralized blockchain

registries, that can identify and address oracles, blockchains, and their …";Cité 21 fois;Les 3 versions;[PDF] arxiv.org;https://arxiv.org/pdf/2005.14282.pdf?ref=hackernoon.com;;"""date"",""2021-03-23T01:09:17Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""A Survey on Blockchain Interoperability: Past, Present, and Future Trends""
""xmp:CreatorTool"",""LaTeX with acmart 2019/12/18 v1.66 Typesetting articles for the Association for Computing Machinery and hyperref 2020-05-15 v7.00e Hypertext links for LaTeX""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""-  Computer systems organization  ->  Dependable and fault-tolerant systems and networks.Peer-to-peer architectures.""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with acmart 2019/12/18 v1.66 Typesetting articles for the Association for Computing Machinery and hyperref 2020-05-15 v7.00e Hypertext links for LaTeX""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""A Survey on Blockchain Interoperability: Past, Present, and Future Trends""
""modified"",""2021-03-23T01:09:17Z""
""cp:subject"",""-  Computer systems organization  ->  Dependable and fault-tolerant systems and networks.Peer-to-peer architectures.""
""pdf:docinfo:subject"",""-  Computer systems organization  ->  Dependable and fault-tolerant systems and networks.Peer-to-peer architectures.""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""Rafael Belchior, AndrĂŠ Vasconcelos, SĂŠrgio Guerreiro, and Miguel Correia""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.21 (TeX Live 2020) kpathsea version 6.3.2""
""meta:author"",""Rafael Belchior, AndrĂŠ Vasconcelos, SĂŠrgio Guerreiro, and Miguel Correia""
""trapped"",""False""
""meta:creation-date"",""2021-03-23T01:09:17Z""
""created"",""2021-03-23T01:09:17Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2021-03-23T01:09:17Z""
""resourceName"",""2005.14282.pdf""
""Author"",""Rafael Belchior, AndrĂŠ Vasconcelos, SĂŠrgio Guerreiro, and Miguel Correia""
""producer"",""pdfTeX-1.40.21""
""pdf:docinfo:producer"",""pdfTeX-1.40.21""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""10"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""Keywords"",""survey, blockchain interoperability, standards, interconnected blockchains, cross-chain transactions, cross-blockchain communication""
""access_permission:modify_annotations"",""true""
""dc:creator"",""Rafael Belchior, AndrĂŠ Vasconcelos, SĂŠrgio Guerreiro, and Miguel Correia""
""dcterms:created"",""2021-03-23T01:09:17Z""
""Last-Modified"",""2021-03-23T01:09:17Z""
""dcterms:modified"",""2021-03-23T01:09:17Z""
""title"",""A Survey on Blockchain Interoperability: Past, Present, and Future Trends""
""Last-Save-Date"",""2021-03-23T01:09:17Z""
""pdf:docinfo:keywords"",""survey, blockchain interoperability, standards, interconnected blockchains, cross-chain transactions, cross-blockchain communication""
""pdf:docinfo:modified"",""2021-03-23T01:09:17Z""
""meta:save-date"",""2021-03-23T01:09:17Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.21 (TeX Live 2020) kpathsea version 6.3.2""
""Content-Length"",""7453841""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Rafael Belchior, AndrĂŠ Vasconcelos, SĂŠrgio Guerreiro, and Miguel Correia""
""dc:language"",""en""
""dc:subject"",""survey, blockchain interoperability, standards, interconnected blockchains, cross-chain transactions, cross-blockchain communication""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""63""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""3698"",""3622"",""3343"",""3533"",""2929"",""3865"",""3901"",""2834"",""2851"",""3837"",""3493"",""2905"",""2363"",""3190"",""3566"",""3899"",""3780"",""3665"",""3938"",""3963"",""3636"",""3417"",""3995"",""3544"",""3742"",""3564"",""3736"",""3472"",""3469"",""3087"",""2660"",""4107"",""5513"",""5279"",""5417"",""5478"",""5622"",""5425"",""5350"",""3790"",""3420"",""3363"",""682"",""2098"",""3953"",""1362"",""2985"",""3534"",""2269"",""2606"",""3691"",""3740"",""3561"",""1377"",""1749"",""3438"",""2793"",""3381"",""1933"",""3269"",""3226"",""2939"",""360""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""survey, blockchain interoperability, standards, interconnected blockchains, cross-chain transactions, cross-blockchain communication""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2021-03-23T01:09:17Z""
";https://scholar.google.com/scholar?start=80&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095351-1486;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Satellite-Aided Consensus Protocol for Scalable Blockchains;X Ling, Z Gao, Y Le, L You, J Wang, Z Ding, X Gao ; Sensors, 2020  mdpi.com;;"… In this case, the satellite even do not realize that they participate in generating oracles and

maintaining a blockchain, and it is thus unnecessary to purchase any satellite services. However,

in this manner, the oracle randomness may be affected and the oracles are more likely to …";Cité 1 fois;Les 6 versions;[PDF] mdpi.com;https://www.mdpi.com/1424-8220/20/19/5616/pdf;;;https://scholar.google.com/scholar?start=290&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095358-1519;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;How Are Cryptocurrency Systems Represented and Who is Liable for Misrepresentation?;P Řstbye ; Available at SSRN 3675083, 2020  papers.ssrn.com;;"… supposed to facilitate a stable value.65 While most stablecoins need some oracle to feed … stability

target, there are also proposals for stablecoins that avoid such oracles by choosing a … It is, for

instance, not uncommon to see cryptocurrencies and blockchain being represented as …";Cité 3 fois;;null;;;;https://scholar.google.com/scholar?start=320&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095304-1291;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Blockchain-Based Lightweight Certificate Authority for Efficient Privacy-Preserving Location-Based Service in Vehicular Social Networks;H Shen, J Zhou, Z Cao, X Dong… ; IEEE Internet of Things …, 2020  ieeexplore.ieee.org;;"… Page 6. SHEN et al.: BLOCKCHAIN-BASED LIGHTWEIGHT CA FOR EFFICIENT

PRIVACY-PRESERVING LBS IN VSNs 6615 corruption, let … where O1 denotes the

certificate generation oracle and hash oracles, Pr[ˇ] denotes the probability …";Cité 5 fois;;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/6488907/6702522/09003271.pdf?casa_token=TZj6URmkcysAAAAA:FXdzdCkPfeSyVWAsfp6mBU1V3QiJJRnj1Bke5bNLJ7ANgrIzLHEVOcqDqaGVQF25uC3C1TuCZ7E;;"""og:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""twitter:title"",""Blockchain-Based Lightweight Certificate Authority for Efficient Privacy-Preserving Location-Based Service in Vehicular Social Networks""
""twitter:card"",""summary""
""Description"",""Blockchain can be utilized to enhance both security and efficiency for location-based service (LBS) in vehicular social networks (VSNs), due to its inherent dec""
""og:title"",""Blockchain-Based Lightweight Certificate Authority for Efficient Privacy-Preserving Location-Based Service in Vehicular Social Networks""
""resourceName"",""09003271.pdf""
""language"",""en""
""title"",""Blockchain-Based Lightweight Certificate Authority for Efficient Privacy-Preserving Location-Based Service in Vehicular Social Networks | IEEE Journals & Magazine | IEEE Xplore""
""og:description"",""Blockchain can be utilized to enhance both security and efficiency for location-based service (LBS) in vehicular social networks (VSNs), due to its inherent decentralization, anonymity, and trust properties. Unfortunately, the existing approaches either lack effective authentication, which is vulnerable to the man-in-the-middle attack, or require an online certificate authority (CA) where frequent interactions with resource-constrained vehicles are required. To address these challenging issues, in this article, a lightweight threshold CA for consortium blockchain along with a privacy-preserving LBS protocol in blockchain enforced VSNs is proposed. First, a lightweight threshold CA framework LTCA is proposed by devising a threshold proxy signature, where the proxy signing key is issued by a coalition of threshold number of CAs playing the roles of authorized nodes in the consortium blockchain. Without the intervene of an online CA, each vehicle in the online phase can authenticate its identity by itself each time its blockchain address (i.e., account address) is updated. Then, based on the proposed LTCA, an efficient privacy-preserving LBS protocol PPVC is contrived to protect each vehicle's conditional identity privacy with a moderate cost. Finally, both security analysis and performance evaluation demonstrate the effectiveness and efficiency of our proposed LTCA and PPVC in blockchain enforced VSNs.""
""twitter:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-UA-Compatible"",""IE=Edge""
""viewport"",""width=device-width, initial-scale=1.0""
""dc:title"",""Blockchain-Based Lightweight Certificate Authority for Efficient Privacy-Preserving Location-Based Service in Vehicular Social Networks | IEEE Journals & Magazine | IEEE Xplore""
""twitter:description"",""Blockchain can be utilized to enhance both security and efficiency for location-based service (LBS) in vehicular social networks (VSNs), due to its inherent decentralization, anonymity, and trust properties. Unfortunately, the existing approaches either lack effective authentication, which is vulnerable to the man-in-the-middle attack, or require an online certificate authority (CA) where frequent interactions with resource-constrained vehicles are required. To address these challenging issues, in this article, a lightweight threshold CA for consortium blockchain along with a privacy-preserving LBS protocol in blockchain enforced VSNs is proposed. First, a lightweight threshold CA framework LTCA is proposed by devising a threshold proxy signature, where the proxy signing key is issued by a coalition of threshold number of CAs playing the roles of authorized nodes in the consortium blockchain. Without the intervene of an online CA, each vehicle in the online phase can authenticate its identity by itself each time its blockchain address (i.e., account address) is updated. Then, based on the proposed LTCA, an efficient privacy-preserving LBS protocol PPVC is contrived to protect each vehicle's conditional identity privacy with a moderate cost. Finally, both security analysis and performance evaluation demonstrate the effectiveness and efficiency of our proposed LTCA and PPVC in blockchain enforced VSNs.""
""Content-Encoding"",""UTF-8""
""Content-Type-Hint"",""text/html; charset=utf-8""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=90&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095290-1229;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;[HTML][HTML] Smart Contracts on the Blockchain–A Bibliometric Analysis and Review;L Ante ; Telematics and Informatics, 2020  Elsevier;;null;Cité 13 fois;Les 4 versions;[HTML] sciencedirect.com;https://www.sciencedirect.com/science/article/pii/S0736585320301787?casa_token=XbuyYwblhvkAAAAA:0ifM9yU6g-cY4_5x7EcPoM-D6w89RbdW8XwbUbfHWyyUYee0C3LB1YH_FIYA8IUlwiGvshD2;;;https://scholar.google.com/scholar?start=30&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095288-1223;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Gravity: a blockchain-agnostic cross-chain communication and data oracles protocol;A Pupyshev, D Gubanov, E Dzhafarov… ; arXiv preprint arXiv …, 2020  arxiv.org;;"This paper intends to propose the architecture of a blockchain-agnostic protocol designed 
for communication of blockchains amongst each other (ie cross-chain), and for blockchains 
with the outside world (ie data oracles). The expansive growth of cutting-edge technology in …";Autres articles;;[PDF] arxiv.org;https://arxiv.org/pdf/2007.00966;;"""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.5""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""21""
""resourceName"",""2007.00966""
""language"",""en""
""pdf:hasXMP"",""false""
""dc:format"",""application/pdf; version=1.5""
""pdf:charsPerPage"",""1753"",""3319"",""2333"",""2598"",""2658"",""2664"",""2354"",""2395"",""2419"",""2323"",""2102"",""2086"",""2944"",""2110"",""1592"",""2167"",""2766"",""2458"",""2635"",""2354"",""2242""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""producer"",""Skia/PDF m87""
""Content-Length"",""676822""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""Skia/PDF m87""
""pdf:hasMarkedContent"",""false""
""Content-Type"",""application/pdf""
";https://scholar.google.com/scholar?start=20&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095330-1399;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Blockchain-mediated Licensing: Legal Engineering for Artist Empowerment;C Adjovu, E Fabian ; Available at SSRN, 2020  papers.ssrn.com;;"… 5.1 Blockchain . . . . . 67 5.2 Smart Contracts … 71 5.4 Application Programming Interface (API)

and Data Oracles . . . . . 71 5.5 Decentralized Applications (DApps) …";Cité 1 fois;Les 8 versions;[PDF] osf.io;https://osf.io/preprints/lawarxiv/kfjxa/download;;"""X-Parsed-By"",""org.apache.tika.parser.EmptyParser""
""resourceName"",""download""
""language"",""""
""Content-Length"",""2958378""
""Content-Type"",""application/octet-stream""
";https://scholar.google.com/scholar?start=200&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095327-1391;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Secure and Efficient Multi-Signature Schemes for Fabric: An Enterprise Blockchain Platform;Y Xiao, P Zhang, Y Liu ; IEEE Transactions on Information …, 2020  ieeexplore.ieee.org;;"… scheme which relies on the RSA assumption in the random oracle model … et al.: SECURE AND

EFFICIENT MULTI-SIGNATURE SCHEMES FOR FABRIC: AN ENTERPRISE BLOCKCHAIN

PLATFORM … hash functions: H0 : {0, 1} ? ? Zq that is modelled as random oracles and H1 …";Autres articles;;null;;;;https://scholar.google.com/scholar?start=190&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095355-1510;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Diamond Accountability Model for Blockchain-enabled Cyber-Physical Systems;A Kanak, N Ugur, S Ergun ; 2020 IEEE International …, 2020  ieeexplore.ieee.org;;"… For instance, data required by a smart contract should be first inserted in the blockchain

by oracles … Since it brings a great transparency, the blockchain, especially

crypto-currencies might be used for financial crime and money laundering …";Autres articles;;null;;;;https://scholar.google.com/scholar?start=310&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095409-1743;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;[PDF][PDF] Towards Model-Driven Smart Contract Systems–Code Generation and Improving Expressivity of Smart Contract Modeling;M Skotnica, J Klicpera, R Pergl ;2020 ceurws.org;;"… is currently the decentralized finance (DeFi) that is used for decentralized exchanges and crypto

loans … First, the mortgage is paid in a cryptocurrency, which is a very volatile asset … the token to

property and mapping to a real cadastre record using a blockchain oracle solution such …";;;[PDF] ceur-ws.org;http://ceur-ws.org/Vol-2825/paper1.pdf;;"""date"",""2020-11-30T21:02:49Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.5""
""xmp:CreatorTool"",""LaTeX with hyperref""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dcterms:created"",""2020-11-30T21:02:49Z""
""language"",""en""
""Last-Modified"",""2020-11-30T21:02:49Z""
""dcterms:modified"",""2020-11-30T21:02:49Z""
""dc:format"",""application/pdf; version=1.5""
""Last-Save-Date"",""2020-11-30T21:02:49Z""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2020-11-30T21:02:49Z""
""meta:save-date"",""2020-11-30T21:02:49Z""
""pdf:encrypted"",""false""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.20 (TeX Live 2019) kpathsea version 6.3.1""
""modified"",""2020-11-30T21:02:49Z""
""Content-Length"",""783616""
""pdf:hasMarkedContent"",""false""
""Content-Type"",""application/pdf""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.20 (TeX Live 2019) kpathsea version 6.3.1""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""meta:creation-date"",""2020-11-30T21:02:49Z""
""created"",""2020-11-30T21:02:49Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""15""
""Creation-Date"",""2020-11-30T21:02:49Z""
""resourceName"",""paper1.pdf""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""2156"",""2549"",""1918"",""2396"",""2004"",""1711"",""2253"",""1292"",""1902"",""2352"",""1360"",""2829"",""2450"",""2729"",""2680""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""producer"",""pdfTeX-1.40.20""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""pdfTeX-1.40.20""
""pdf:docinfo:created"",""2020-11-30T21:02:49Z""
";https://scholar.google.com/scholar?start=540&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095318-1344;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Pause the blockchain legal revolution;KFK Low, E Mik ; International & Comparative Law Quarterly, 2020  cambridge.org;;"… Senate Committee on Banking, Housing, and Urban Affairs on 'Exploring the Cryptocurrency

and Blockchain … the massive crash in 2018, see P Vigna, 'Bearish on Bitcoin: Crypto Markets Take …

9 C Metz, 'Tech and Banking Giants Ditch Bitcoin for Their Own Blockchain' Wired (17 …";Cité 16 fois;Les 8 versions;null;;;;https://scholar.google.com/scholar?start=150&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095334-1421;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Blockchain and smart contract for access control in healthcare: A survey, issues and challenges, and open issues;M Sookhak, MR Jabbarpour, NS Safa, FR Yu ; Journal of Network and …, 2020  Elsevier;;null;Cité 2 fois;Les 3 versions;null;;;;https://scholar.google.com/scholar?start=220&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095299-1265;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;[HTML][HTML] Public and private blockchain in construction business process and information integration;R Yang, R Wakefield, S Lyu, S Jayasuriya, F Han… ; Automation in …, 2020  Elsevier;;"… As a general-purpose blockchain platform, Ethereum can enable users for executing smart

contracts and developing cryptocurrency-related applications … Albreiki et al. [75] use blockchain

concept with trusted oracles to create a decentralized access control system allowing …";Cité 22 fois;Les 2 versions;[HTML] sciencedirect.com;https://www.sciencedirect.com/science/article/pii/S0926580520301886?casa_token=ZM73N6mlC_QAAAAA:l7DtQU0RdphojSE-9pwhCMoeKsTrX0d-VhlmmE806-VVU_UcWizjKBD06vW1mofhhggWNogw;;;https://scholar.google.com/scholar?start=70&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095283-1202;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;On public crowdsource-based mechanisms for a decentralized blockchain oracle;K Nelaturu, J Adler, M Merlini, R Berryhill… ; IEEE Transactions …, 2020  ieeexplore.ieee.org;;"Blockchain technology has created an excitement that was last seen two decades ago when 
the Internet was entering the mainstream. An appealing feature of blockchain technology is 
smart contracts. A smart contract is an executable code. It runs on top of the blockchain  …";Cité 1 fois;Les 4 versions;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/17/4429834/09113449.pdf?casa_token=AtimMM0egbsAAAAA:SVYjrKtBpnVUf_fcbvf31s6pR7Xm-ByStry8k2sLX0EZYz51oN08TaA7dIPT8DwcqSOLidujlKE;;"""og:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""twitter:title"",""On Public Crowdsource-Based Mechanisms for a Decentralized Blockchain Oracle""
""twitter:card"",""summary""
""Description"",""Blockchain technology has created an excitement that was last seen two decades ago when the Internet was entering the mainstream. An appealing feature of blockc""
""og:title"",""On Public Crowdsource-Based Mechanisms for a Decentralized Blockchain Oracle""
""resourceName"",""09113449.pdf""
""language"",""en""
""title"",""On Public Crowdsource-Based Mechanisms for a Decentralized Blockchain Oracle | IEEE Journals & Magazine | IEEE Xplore""
""og:description"",""Blockchain technology has created an excitement that was last seen two decades ago when the Internet was entering the mainstream. An appealing feature of blockchain technology is smart contracts. A smart contract is an executable code. It runs on top of the blockchain facilitating an agreement between untrusted parties. These smart contracts have a major limitation, namely they cannot operate on information external to the blockchain. The inability to query such information has paved the need for trusted entities called “oracles.” These oracles attest to facts without the robust security guarantees that blockchains generally provide. This can potentially harm the integrity of the network and lead to centralized points-of-failure. To address this concern, this article proposes a decentralized oracle which is based on a voting-based game that decides the truth or falsity of queries. In the context of this article, we are only interested in binary markets, i.e., queries which can be True, False, or Unknown. When requesting facts from an oracle, a user submits binary queries. Reporters (or certifiers) respond to the queries by placing monetary stake. A formal analysis of the system parameters is presented, which shows that the proposed platform incentivizes a Nash equilibrium for truthful reporting. An extension to the base protocol is also described and profiled against the original framework. Finally, we discuss a prototype architecture, along with additional features to be considered during implementation.""
""twitter:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-UA-Compatible"",""IE=Edge""
""viewport"",""width=device-width, initial-scale=1.0""
""dc:title"",""On Public Crowdsource-Based Mechanisms for a Decentralized Blockchain Oracle | IEEE Journals & Magazine | IEEE Xplore""
""twitter:description"",""Blockchain technology has created an excitement that was last seen two decades ago when the Internet was entering the mainstream. An appealing feature of blockchain technology is smart contracts. A smart contract is an executable code. It runs on top of the blockchain facilitating an agreement between untrusted parties. These smart contracts have a major limitation, namely they cannot operate on information external to the blockchain. The inability to query such information has paved the need for trusted entities called “oracles.” These oracles attest to facts without the robust security guarantees that blockchains generally provide. This can potentially harm the integrity of the network and lead to centralized points-of-failure. To address this concern, this article proposes a decentralized oracle which is based on a voting-based game that decides the truth or falsity of queries. In the context of this article, we are only interested in binary markets, i.e., queries which can be True, False, or Unknown. When requesting facts from an oracle, a user submits binary queries. Reporters (or certifiers) respond to the queries by placing monetary stake. A formal analysis of the system parameters is presented, which shows that the proposed platform incentivizes a Nash equilibrium for truthful reporting. An extension to the base protocol is also described and profiled against the original framework. Finally, we discuss a prototype architecture, along with additional features to be considered during implementation.""
""Content-Encoding"",""UTF-8""
""Content-Type-Hint"",""text/html; charset=utf-8""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";
1619095304-1292;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Smart Grid Management using Blockchain: Future Scenarios and Challenges;T Cioara, C Pop, R Zanc, I Anghel, M Antal… ; arXiv preprint arXiv …, 2020  arxiv.org;;"… Pricing mechanisms are introduced within market operations via Oracles based integration of

external … context prosumers and assets segmentation in flexibility bands via Oracle based

integration … multi-objectives by using energy records stored and blockchain transactions and …";Autres articles;;[PDF] arxiv.org;https://arxiv.org/pdf/2012.06256;;"""date"",""2020-12-11T11:40:51Z""
""pdf:PDFVersion"",""1.7""
""xmp:CreatorTool"",""MicrosoftÂŽ Word for Office 365""
""pdf:docinfo:title"",""Paper Title (use style: paper title)""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""language"",""en""
""dc:format"",""application/pdf; version=1.7""
""pdf:docinfo:creator_tool"",""MicrosoftÂŽ Word for Office 365""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""Paper Title (use style: paper title)""
""xmp:CreateDate"",""2020-12-11T13:40:51Z""
""modified"",""2020-12-11T11:40:51Z""
""pdf:hasMarkedContent"",""true""
""xmp:ModifyDate"",""2020-12-11T13:40:51Z""
""pdf:docinfo:creator"",""IEEE""
""meta:author"",""IEEE""
""meta:creation-date"",""2020-12-11T11:40:51Z""
""created"",""2020-12-11T11:40:51Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-12-11T11:40:51Z""
""resourceName"",""2012.06256""
""Author"",""IEEE""
""producer"",""MicrosoftÂŽ Word for Office 365""
""pdf:docinfo:producer"",""MicrosoftÂŽ Word for Office 365""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0""
""access_permission:modify_annotations"",""true""
""dc:creator"",""IEEE""
""dcterms:created"",""2020-12-11T11:40:51Z""
""Last-Modified"",""2020-12-11T11:40:51Z""
""dcterms:modified"",""2020-12-11T11:40:51Z""
""title"",""Paper Title (use style: paper title)""
""xmpMM:DocumentID"",""uuid:0E3D722D-F105-4E97-B39B-F561399BA402""
""Last-Save-Date"",""2020-12-11T11:40:51Z""
""pdf:docinfo:modified"",""2020-12-11T11:40:51Z""
""meta:save-date"",""2020-12-11T11:40:51Z""
""Content-Length"",""373276""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""IEEE""
""dc:language"",""en-US""
""pdf:producer"",""MicrosoftÂŽ Word for Office 365""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""6""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""5019"",""5317"",""6256"",""5600"",""7031"",""499""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-12-11T11:40:51Z""
";https://scholar.google.com/scholar?start=90&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095344-1457;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Modern Software Lifecycle Management leveraging the power of Blockchain;B Tsvetkov, J Jeliazkov… ; 2020 Algebraic and …, 2020  ieeexplore.ieee.org;;"… Finally, any data from customers' systems is collected by the Track Data smart contract either by

manual operations or by established oracles running at customer's site … All needed interaction

with the blockchain in regards to software catalog are done via O1 oracle …";;null;null;;;;https://scholar.google.com/scholar?start=260&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095399-1696;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;[CITATION][C] Lex Cryptographia–The role of a principles-based approach in Blockchain/DLT Regulation Master Thesis Law & Technology, Tilburg University;S Subramanyam, E Partiti;;;null;Autres articles;;null;;;;https://scholar.google.com/scholar?start=500&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095288-1215;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Blockchain-based Multi-Party Authorization for Accessing IPFS Encrypted Data;AA Battah, MM Madine, H Alzaabi, I Yaqoob… ; IEEE …, 2020  ieeexplore.ieee.org;;"… In [15], a blockchain and trusted oracles based decentralized access control solution for the IoT

data has been … reputation before generating an access token for the end-user to access the IoT

device through that oracle … Moreover, it is expensive as it requires multiple oracles …";Cité 3 fois;Les 5 versions;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/6287639/8948470/09240966.pdf;;"""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""dc:title"",""IEEE Xplore Full-Text PDF:""
""Content-Encoding"",""UTF-8""
""resourceName"",""09240966.pdf""
""language"",""es""
""Content-Length"",""2565""
""title"",""IEEE Xplore Full-Text PDF:""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=20&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095395-1677;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Blockchain smart contract. Un primo inquadramento;G Remotti ; Osservatorio del diritto civile e commerciale, 2020  rivisteweb.it;;"… 2020, 43 ss.; e v. anche Gitti, Maugeri, Ferrari, Offerte iniziali e scambi di crypto-attivitŕ, in …

l'avveramento della condizione che determina l'esecuzione dell'operazione gli vengono fornite

dagli oracoli (oracles), vale a dire software indipendenti dalla blockchain che hanno la …";;null;null;;;;https://scholar.google.com/scholar?start=480&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095320-1355;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Is Blockchain a Suitable Technology for Ensuring the Integrity of Data Shared by Lighting and Other Building Systemsƒ;A Vlachokostas, M Poplawski… ; 2020 Resilience Week …, 2020  ieeexplore.ieee.org;;"… However, the use of oracles poses a trust issue between a blockchain network and its oracles,

as it is at least theoretically possible to perform “man in the middle” attacks standing between

the contracts and the oracles. Securing an oracle is currently a challenge for smart …";Autres articles;;[PDF] researchgate.net;https://www.researchgate.net/profile/Alex_Vlachokostas/publication/345792454_Is_Blockchain_a_Suitable_Technology_for_Ensuring_the_Integrity_of_Data_Shared_by_Lighting_and_Other_Building_Systems/links/5fae0d024585150781136f1b/Is-Blockchain-a-Suitable-Technology-for-Ensuring-the-Integrity-of-Data-Shared-by-Lighting-and-Other-Building-Systems.pdf;;;https://scholar.google.com/scholar?start=160&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095318-1352;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;The (non-) application of blockchain technology in the Greek shipping industry;A Papathanasiou, R Cole, P Murray ; European Management Journal, 2020  Elsevier;;"… considering the shipping industry specifically. 2. Blockchain technology. The first

discussion of BCT originated in the field of cryptocurrency (Nakamoto, 2008, pp.

5–6) but for an OSCM context, Queiroz et al. (2020) define BCT as …";Cité 4 fois;Les 3 versions;null;;;;https://scholar.google.com/scholar?start=150&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095337-1433;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;On the Security of Proofs of Sequential Work in a Post-Quantum World;J Blocki, S Lee, S Zhou ; arXiv preprint arXiv:2006.10972, 2020  arxiv.org;;"… Proofs of se- quential work have many applications including time-stamping, blockchain design,

and universally verifiable CPU benchmarks … 9 D = {} is empty, it is equivalent to viewing the random

oracle as being in superposition of all possible random oracles …";Autres articles;;[PDF] arxiv.org;https://arxiv.org/pdf/2006.10972;;"""date"",""2020-12-16T01:50:00Z""
""pdf:PDFVersion"",""1.4""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.4""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""xmp:CreateDate"",""2020-12-15T20:50:00Z""
""modified"",""2020-12-16T01:50:00Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""xmp:ModifyDate"",""2020-12-15T20:50:00Z""
""pdf:docinfo:creator"",""""
""meta:author"",""""
""meta:creation-date"",""2020-12-16T01:50:00Z""
""created"",""2020-12-16T01:50:00Z""
""xmp:About"",""uuid:8e8df3c2-775d-11f6-0000-c32f8469d38a""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-12-16T01:50:00Z""
""resourceName"",""2006.10972""
""Author"",""""
""producer"",""dvips + GPL Ghostscript GIT PRERELEASE 9.22""
""pdf:docinfo:producer"",""dvips + GPL Ghostscript GIT PRERELEASE 9.22""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""4"",""4"",""1"",""0"",""1"",""28"",""29"",""19"",""27"",""20"",""12"",""4"",""44"",""11"",""43"",""66"",""57"",""20"",""2"",""1"",""0"",""4"",""5"",""17"",""66"",""65"",""2"",""0"",""0"",""2"",""10"",""17"",""15"",""30"",""1"",""3"",""1"",""31"",""62"",""47"",""51"",""32"",""70""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2020-12-16T01:50:00Z""
""Last-Modified"",""2020-12-16T01:50:00Z""
""dcterms:modified"",""2020-12-16T01:50:00Z""
""title"",""""
""xmpMM:DocumentID"",""uuid:8e8df3c2-775d-11f6-0000-c32f8469d38a""
""Last-Save-Date"",""2020-12-16T01:50:00Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2020-12-16T01:50:00Z""
""meta:save-date"",""2020-12-16T01:50:00Z""
""Content-Length"",""541538""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""44""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""2235"",""2822"",""2510"",""2593"",""2249"",""2621"",""2245"",""2489"",""2469"",""1739"",""2777"",""2283"",""1528"",""2530"",""1961"",""2210"",""2060"",""2024"",""1687"",""2105"",""1946"",""2520"",""1812"",""1819"",""1676"",""2079"",""1632"",""2249"",""2685"",""2627"",""2227"",""1446"",""1955"",""1971"",""1711"",""225"",""1331"",""990"",""1733"",""1396"",""1335"",""1211"",""2040"",""1816""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-12-16T01:50:00Z""
";https://scholar.google.com/scholar?start=230&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095283-1200;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;[HTML][HTML] From Athens to the Blockchain: Oracles for Digital Democracy;M Poblet, DWE Allen, O Konashevych… ; … in Blockchain, 2020  frontiersin.org;Switzerland;"Oracles were trusted sources of knowledge for public deliberation in classical Athens. Very 
much like expert and technical knowledge, divine advice was embedded in the deliberation 
and decision-making process of the democratic Assembly. While the idea of religious …";Autres articles;;[HTML] frontiersin.org;https://www.frontiersin.org/articles/10.3389/fbloc.2020.575662/full?utm_source=FRN&utm_medium=EMAIL_IRIS&utm_campaign=EMI_FRN_ARTICLEPUBLISHED_FOLLOWERS&utm_content=ARTICLE_TITLE;;"""citation_keywords"",""Democracy; digital democracy; Blockchain; cryptography; oracles; Distributed networks; deliberation; Decision Making""
""og:image"",""https://www.frontiersin.org/files/MyHome%20Article%20Library/575662/575662_Thumb_400.jpg""
""citation_publication_date"",""2020/09/17""
""citation_title"",""From Athens to the Blockchain: Oracles for Digital Democracy""
""citation_author_institution"",""Graduate School of Business and Law and RMIT Blockchain Innovation Hub, RMIT University, Australia"",""RMIT Blockchain Innovation Hub, RMIT University, Australia"",""Erasmus Mundus Joint International Doctoral Fellow in Law, Science and Technology and RMIT Blockchain Innovation Hub, RMIT University, Australia"",""Graduate School of Business and Law and RMIT Blockchain Innovation Hub, RMIT University, Australia"",""Graduate School of Business and Law, RMIT University, Australia""
""Description"",""Oracles were trusted sources of knowledge for public deliberation in classical Athens. Very much like expert and technical knowledge, divine advice was embedded in the deliberation and decision-making process of the democratic Assembly. While the idea of religious divination is completely out of place in our contemporary democracies, oracles made a technological comeback with modern computer science and cryptography and, more recently, the emergence of the blockchain as a “trust machine.” This paper reviews the role of oracles in Athenian democracy and, stemming from the renewed use of the term in computer sciences and cryptography, analyses the case of oracles in the nascent blockchain ecosystem. The paper also proposes a sociotechnical approach to the use of distributed oracles as informational devices to assist deliberative processes in digital democracy settings and considers the limits that such an approach may face.""
""Keywords"",""Democracy, digital democracy, Blockchain, cryptography, oracles, Distributed networks, deliberation, Decision Making""
""citation_publisher"",""Frontiers""
""citation_journal_title"",""Frontiers in Blockchain""
""description"",""Oracles were trusted sources of knowledge for public deliberation in classical Athens. Very much like expert and technical knowledge, divine advice was embedded in the deliberation and decision-making process of the democratic Assembly. While the idea of religious divination is completely out of place in our contemporary democracies, oracles made a technological comeback with modern computer science and cryptography and, more recently, the emergence of the blockchain as a “trust machine”. This paper reviews the role of oracles in Athenian democracy and, stemming from the renewed use of the term in computer sciences and cryptography, analyses the case of oracles in the nascent blockchain ecosystem. The paper also proposes a sociotechnical approach to the use of distributed oracles as informational devices to assist deliberative processes in digital democracy settings, and considers the limits that such an approach may face.""
""language"",""en""
""citation_date"",""2020""
""title"",""Frontiers | From Athens to the Blockchain: Oracles for Digital Democracy | Blockchain""
""citation_online_date"",""2020/08/18""
""citation_author_email"","""","""","""","""",""""
""citation_issn"",""2624-7852""
""dc:title"",""Frontiers | From Athens to the Blockchain: Oracles for Digital Democracy | Blockchain""
""citation_language"",""English""
""Content-Encoding"",""UTF-8""
""citation_pdf_url"",""https://www.frontiersin.org/articles/10.3389/fbloc.2020.575662/pdf""
""Content-Length"",""200036""
""Content-Type"",""text/html; charset=UTF-8""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""og:type"",""article""
""citation_journal_abbrev"",""Front. Blockchain""
""citation_abstract"",""Oracles were trusted sources of knowledge for public deliberation in classical Athens. Very much like expert and technical knowledge, divine advice was embedded in the deliberation and decision-making process of the democratic Assembly. While the idea of religious divination is completely out of place in our contemporary democracies, oracles made a technological comeback with modern computer science and cryptography and, more recently, the emergence of the blockchain as a “trust machine”. This paper reviews the role of oracles in Athenian democracy and, stemming from the renewed use of the term in computer sciences and cryptography, analyses the case of oracles in the nascent blockchain ecosystem. The paper also proposes a sociotechnical approach to the use of distributed oracles as informational devices to assist deliberative processes in digital democracy settings, and considers the limits that such an approach may face.""
""citation_author"",""Poblet, Marta"",""Allen, Darcy W. E."",""Konashevych, Oleksii"",""Lane, Aaron M."",""Diaz Valdivia, Carlos Andres""
""Title"",""From Athens to the Blockchain: Oracles for Digital Democracy""
""resourceName"",""full""
""citation_pages"",""41""
""url"",""https://www.frontiersin.org/article/10.3389/fbloc.2020.575662/full""
""site_name"",""Frontiers""
""X-UA-Compatible"",""IE=edge""
""frontiers:type"",""Article""
""viewport"",""width=device-width, initial-scale=1, maximum-scale=1""
""citation_doi"",""10.3389/fbloc.2020.575662""
""dc.identifier"",""doi:10.3389/fbloc.2020.575662""
""citation_volume"",""3""
""Content-Language"",""en""
";
1619095367-1555;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Post-Quantum Security of the Bitcoin Backbone and Quantum Multi-Solution Bernoulli Search;A Cojocaru, J Garay, A Kiayias, F Song… ; arXiv preprint arXiv …, 2020  arxiv.org;;"… We analyze the quantum query complexity of a Chain-of-Proofs-of-Work search problem, problem

that is at the core of the blockchain protocol, which in turn is related to the complexity of a multi …

17 5.1.1 Bernoulli oracles … 17 5.1.2 Relating search to evolution of the oracle …";Cité 1 fois;Les 2 versions;[PDF] arxiv.org;https://arxiv.org/pdf/2012.15254;;"""date"",""2021-03-09T03:50:44Z""
""pdf:PDFVersion"",""1.4""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.4""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""xmp:CreateDate"",""2021-03-08T22:50:44Z""
""modified"",""2021-03-09T03:50:44Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""xmp:ModifyDate"",""2021-03-08T22:50:44Z""
""pdf:docinfo:creator"",""""
""meta:author"",""""
""meta:creation-date"",""2021-03-09T03:50:44Z""
""created"",""2021-03-09T03:50:44Z""
""xmp:About"",""uuid:2c9afa2a-b8a7-11f6-0000-91c476847c5d""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2021-03-09T03:50:44Z""
""resourceName"",""2012.15254""
""Author"",""""
""producer"",""dvips + GPL Ghostscript GIT PRERELEASE 9.22""
""pdf:docinfo:producer"",""dvips + GPL Ghostscript GIT PRERELEASE 9.22""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""4"",""0"",""8"",""0"",""9"",""3"",""0"",""37"",""10"",""9"",""30"",""26"",""17"",""71"",""101"",""135"",""132"",""41"",""4"",""2"",""0"",""2"",""4"",""4"",""0"",""0"",""0"",""32"",""4"",""14"",""4""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2021-03-09T03:50:44Z""
""Last-Modified"",""2021-03-09T03:50:44Z""
""dcterms:modified"",""2021-03-09T03:50:44Z""
""title"",""""
""xmpMM:DocumentID"",""uuid:2c9afa2a-b8a7-11f6-0000-91c476847c5d""
""Last-Save-Date"",""2021-03-09T03:50:44Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2021-03-09T03:50:44Z""
""meta:save-date"",""2021-03-09T03:50:44Z""
""Content-Length"",""412156""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""34""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""2274"",""2696"",""2313"",""2580"",""2715"",""2435"",""2485"",""2812"",""2088"",""2475"",""2515"",""1797"",""2228"",""2009"",""1545"",""2080"",""1686"",""837"",""1125"",""1291"",""1608"",""1980"",""2335"",""1745"",""2219"",""1592"",""2018"",""2813"",""2673"",""1356"",""992"",""1561"",""1961"",""629""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2021-03-09T03:50:44Z""
";https://scholar.google.com/scholar?start=360&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095346-1473;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;[PDF][PDF] Overview and impact of blockchain on auditing;D Bonyuet ; Int. J. Digit. Account. Res, 2020  pdfs.semanticscholar.org;;"… In March 2019, EY launched Crypto-Asset Accounting and Tax (CAAT) software to assist US

firms to report their crypto asset transaction when filing their tax … 1. Auditor of Smart Contracts and

Oracles: As smart contracts can be embedded in a blockchain to automate …";Cité 5 fois;Les 3 versions;[PDF] semanticscholar.org;https://pdfs.semanticscholar.org/9a02/67c50ba1cfe839df6288d134934a2863f4c5.pdf;;"""citation_publication_date"",""2020""
""og:image"",""https://www.semanticscholar.org/img/semantic_scholar_og.png""
""citation_title"",""Overview and Impact of Blockchain on Auditing""
""og:image:width"",""1110""
""twitter:card"",""summary_large_image""
""msapplication-square70x70logo"",""https://cdn.semanticscholar.org/86e6c2539915adc9/img/mstile-70x70.png""
""citation_journal_title"",""undefined""
""description"",""Blockchain has become very popular as the underlying technology powering Bitcoin. However, the benefits behind this technology further surpass just supporting cryptocurrencies. Blockchain can be defined as a digital ledger that allows to capture transactions conducted among several parties on real-time and serves as a decentralized database where each participant keeps an identical copy of the ledger. The appeal behind blockchain resides on its peer-to-peer network infrastructure along cryptographic capabilities. This combination enables users to conduct transactions without a trusted third-party intermediary. Benefits in accounting are even more promising as blockchain will provide a triple entry accounting system where all transactions are immutable and have been time stamped, recorded on real-time and encrypted (Alarcon & Ng, 2018). The purpose of this paper is to review extant research on this technology and assess the impact of blockchain in the audit profession, including new risks, change in procedures and additional opportunities.""
""msapplication-wide310x150logo"",""https://cdn.semanticscholar.org/86e6c2539915adc9/img/mstile-310x150.png""
""language"",""en""
""title"",""[PDF] Overview and Impact of Blockchain on Auditing | Semantic Scholar""
""og:description"",""Blockchain has become very popular as the underlying technology powering Bitcoin. However, the benefits behind this technology further surpass just supporting cryptocurrencies. Blockchain can be defined as a digital ledger that allows to capture transactions conducted among several parties on real-time and serves as a decentralized database where each participant keeps an identical copy of the ledger. The appeal behind blockchain resides on its peer-to-peer network infrastructure along cryptographic capabilities. This combination enables users to conduct transactions without a trusted third-party intermediary. Benefits in accounting are even more promising as blockchain will provide a triple entry accounting system where all transactions are immutable and have been time stamped, recorded on real-time and encrypted (Alarcon & Ng, 2018). The purpose of this paper is to review extant research on this technology and assess the impact of blockchain in the audit profession, including new risks, change in procedures and additional opportunities.""
""og:image:secure_url"",""https://www.semanticscholar.org/img/semantic_scholar_og.png"",""https://www.semanticscholar.org/img/semantic_scholar_og.png""
""twitter:image"",""https://www.semanticscholar.org/img/semantic_scholar_og.png"",""https://www.semanticscholar.org/img/semantic_scholar_og.png""
""twitter:site"",""@allenai_org""
""msapplication-square310x310logo"",""https://cdn.semanticscholar.org/86e6c2539915adc9/img/mstile-310x310.png""
""dc:title"",""[PDF] Overview and Impact of Blockchain on Auditing | Semantic Scholar""
""Content-Encoding"",""UTF-8""
""citation_pdf_url"",""https://doi.org/10.4192/1577-8517-v20_2""
""robots"",""noarchive,noindex""
""Content-Type"",""text/html; charset=UTF-8""
""s2-ui-version"",""2cfb8f55a25a62a824f97b333bd41eb95e1e3822""
""application-name"","" ""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""twitter:title"",""[PDF] Overview and Impact of Blockchain on Auditing | Semantic Scholar""
""og:type"",""website""
""og:title"",""[PDF] Overview and Impact of Blockchain on Auditing | Semantic Scholar""
""citation_author"",""D. Bonyuet""
""og:image:height"",""582""
""resourceName"",""67c50ba1cfe839df6288d134934a2863f4c5.pdf""
""msapplication-square150x150logo"",""https://cdn.semanticscholar.org/86e6c2539915adc9/img/mstile-150x150.png""
""msapplication-TileColor"",""#FFFFFF""
""viewport"",""width=device-width,initial-scale=1""
""twitter:description"",""Blockchain has become very popular as the underlying technology powering Bitcoin. However, the benefits behind this technology further surpass just supporting cryptocurrencies. Blockchain can be defined as a digital ledger that allows to capture transactions conducted among several parties on real-time and serves as a decentralized database where each participant keeps an identical copy of the ledger. The appeal behind blockchain resides on its peer-to-peer network infrastructure along cryptographic capabilities. This combination enables users to conduct transactions without a trusted third-party intermediary. Benefits in accounting are even more promising as blockchain will provide a triple entry accounting system where all transactions are immutable and have been time stamped, recorded on real-time and encrypted (Alarcon & Ng, 2018). The purpose of this paper is to review extant research on this technology and assess the impact of blockchain in the audit profession, including new risks, change in procedures and additional opportunities.""
""og:locale"",""en_US"",""en_US""
""Content-Language"",""en""
""msapplication-TileImage"",""https://cdn.semanticscholar.org/86e6c2539915adc9/img/mstile-144x144.png""
";https://scholar.google.com/scholar?start=270&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095353-1503;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Blockchain and Smart Contracts: Legal Issues and Regulatory Responses Between Public and Private Economic Law;D Caria ;2020 iris.unito.it;;"… of view, unless one puts in place a hard fork, which would compromise the underlying assumption

of immutability of the blockchain, it is … notary's refusal to record in the commercial register a

resolution to increase capital employing the contribution in kind of a crypto-currency unit …";Autres articles;;[PDF] unito.it;https://iris.unito.it/bitstream/2318/1765388/1/363%20DE%20CARIA.pdf;;"""date"",""2020-07-30T06:26:53Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.7""
""pdf:docinfo:title"",""Microsoft Word - 6 ItaLJ 1 (2020)""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dc:creator"",""emanu""
""dcterms:created"",""2020-07-30T06:26:53Z""
""language"",""en""
""Last-Modified"",""2020-07-30T06:26:53Z""
""dcterms:modified"",""2020-07-30T06:26:53Z""
""dc:format"",""application/pdf; version=1.7""
""title"",""Microsoft Word - 6 ItaLJ 1 (2020)""
""Last-Save-Date"",""2020-07-30T06:26:53Z""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2020-07-30T06:26:53Z""
""meta:save-date"",""2020-07-30T06:26:53Z""
""pdf:encrypted"",""false""
""dc:title"",""Microsoft Word - 6 ItaLJ 1 (2020)""
""modified"",""2020-07-30T06:26:53Z""
""Content-Length"",""428320""
""pdf:hasMarkedContent"",""false""
""Content-Type"",""application/pdf""
""pdf:docinfo:creator"",""emanu""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""emanu""
""meta:author"",""emanu""
""meta:creation-date"",""2020-07-30T06:26:53Z""
""created"",""2020-07-30T06:26:53Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""17""
""Creation-Date"",""2020-07-30T06:26:53Z""
""resourceName"",""363%20DE%20CARIA.pdf""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""2506"",""3704"",""3433"",""3261"",""3630"",""3801"",""3393"",""3215"",""3555"",""3878"",""3558"",""3466"",""3336"",""3455"",""4144"",""3333"",""3640""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""Author"",""emanu""
""producer"",""Microsoft: Print To PDF""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""Microsoft: Print To PDF""
""pdf:docinfo:created"",""2020-07-30T06:26:53Z""
";https://scholar.google.com/scholar?start=300&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095390-1662;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Blockchain, artificial intelligence and knowledge graphs: What does it mean for the business?;M Bennett ; Journal of Securities Operations & Custody, 2020  ingentaconnect.com;;"… Distributed ledgers are not ledgers. There are things called oracles that are not from Oracle.

Some things that get called block chains are not even chains of blocks. And that is a good thing …

Blockchain, artificial intelligence and knowledge graphs Page 360 …";Autres articles;;null;;;;https://scholar.google.com/scholar?start=460&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095306-1303;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;[HTML][HTML] Consensus-oriented cloud manufacturing based on blockchain technology: An exploratory study;X Zhu, J Shi, S Huang, B Zhang ; Pervasive and Mobile Computing, 2020  Elsevier;;"… Easy payment. The crypto-system provides a convenient uniform method of payment for the global

users … Traditional, Blockchain-based. Data storage, Internet-based traditional service, Blockchain,

Oracle … Payment, E-payment, Traditional payment, Uniform cryptocurrency …";Cité 8 fois;Les 3 versions;[HTML] sciencedirect.com;https://www.sciencedirect.com/science/article/pii/S1574119220300018?casa_token=2mVVGr98P6EAAAAA:mxXVbw2kIv05KGAt1agPOhEli6IoB1Z724-vuZ0JWDErexGDZervl_cLsGhGXN27YF1MVqiq;;;https://scholar.google.com/scholar?start=100&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095311-1323;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Lightweight End-to-End Blockchain for IoT Applications;S Lee, J Lee, S Hong, JH Kim ; KSII Transactions on Internet and …, 2020  koreascience.or.kr;;"… However, this topic will need more attention, as secure oracles are a bottleneck for data integrity …

An end-to-end blockchain network, as in Fig. 2, fundamentally solves the oracle problem … If the

change is accepted, it is included in the blockchain and baselined …";Cité 1 fois;Les 4 versions;[PDF] koreascience.or.kr;https://www.koreascience.or.kr/article/JAKO202026061057934.pdf;;"""date"",""2020-09-10T01:22:24Z""
""pdf:PDFVersion"",""1.5""
""xmp:CreatorTool"","" Word용 Acrobat PDFMaker 11""
""pdf:docinfo:title"",""Original file was jvis_final.tex""
""Company"",""""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"","" Word용 Acrobat PDFMaker 11""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""Original file was jvis_final.tex""
""xmp:CreateDate"",""2020-08-30T22:19:58Z""
""modified"",""2020-09-10T01:22:24Z""
""pdf:docinfo:custom:SourceModified"",""D:20200829051508""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""true""
""xmp:ModifyDate"",""2020-09-10T10:22:24Z""
""pdf:docinfo:creator"",""I.A.""
""meta:author"",""I.A.""
""meta:creation-date"",""2020-08-30T13:19:58Z""
""created"",""2020-08-30T13:19:58Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-08-30T13:19:58Z""
""resourceName"",""JAKO202026061057934.pdf""
""pdf:docinfo:custom:Comments"",""Created using latex2rtf 1.9.19a on Wed May 21 12:55:05 2008""
""Author"",""I.A.""
""producer"",""Adobe PDF Library 11.0""
""pdf:docinfo:producer"",""Adobe PDF Library 11.0""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""I.A.""
""dcterms:created"",""2020-08-30T13:19:58Z""
""Last-Modified"",""2020-09-10T01:22:24Z""
""dcterms:modified"",""2020-09-10T01:22:24Z""
""title"",""Original file was jvis_final.tex""
""xmpMM:DocumentID"",""uuid:fc83beca-a987-4e25-a461-8a5bda97ffec""
""Last-Save-Date"",""2020-09-10T01:22:24Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2020-09-10T01:22:24Z""
""meta:save-date"",""2020-09-10T01:22:24Z""
""Content-Length"",""2112972""
""Content-Type"",""application/pdf""
""xmp:MetadataDate"",""2020-09-10T10:22:24Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""I.A.""
""pdf:producer"",""Adobe PDF Library 11.0""
""dc:subject"",""""
""Comments"",""Created using latex2rtf 1.9.19a on Wed May 21 12:55:05 2008""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""19""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""2446"",""3751"",""1753"",""3559"",""3067"",""2674"",""1667"",""1815"",""1732"",""2364"",""1647"",""1965"",""1082"",""1549"",""2392"",""1863"",""2226"",""3717"",""2116""
""access_permission:extract_content"",""true""
""pdf:docinfo:custom:Company"",""""
""access_permission:can_print"",""true""
""SourceModified"",""D:20200829051508""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-08-30T13:19:58Z""
";https://scholar.google.com/scholar?start=120&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095299-1266;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;[HTML][HTML] Certificateless authenticated key agreement for blockchain-based WBANs;G Mwitende, Y Ye, I Ali, F Li ; Journal of Systems Architecture, 2020  Elsevier;;"… The bitcoin is a well known successful cryptocurrency with its huge capital market [7]. Bitcoin

is called the first digital currency or peer-to-peer e-cash system [8]. The core technology to design

bitcoin is blockchain in a special data storage structure and transactions happen …";Cité 12 fois;Les 2 versions;[HTML] sciencedirect.com;https://www.sciencedirect.com/science/article/pii/S1383762120300710?casa_token=5Fj4n1FP9FQAAAAA:noliqPF12mTVa04wToDMxdO7JLD22iWfVUSYo9v53eRalG_KYz0rdMimUCas34uP_EEuTuu4;;;https://scholar.google.com/scholar?start=70&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095330-1394;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;A New Cooperative Insurance Based On Blockchain Technology: Six Simulations To Evaluate The Model.;FZ Meskini, R Aboulaich ; 2020 International Conference on …, 2020  ieeexplore.ieee.org;;"… The entity that carries out this mission is called oracle … Rapidity: Automatic reimbursement based

on smart contracts (oracles, sensors) and … b) Rapidity For Blockchain-based insurance, especially

while using cryptocurrency, the delay is much shorter than the usual insurance …";Autres articles;;null;;;;https://scholar.google.com/scholar?start=200&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095378-1609;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;[HTML][HTML] A Blockchain-based Decentralized Electronic Marketplace for Computing Resources;M Nardini, S Helmer, N El Ioini, C Pahl ; SN Computer Science, 2020  Springer;Singapore;"… Search SpringerLink Search. A Blockchain-based Decentralized Electronic Marketplace for

Computing Resources. Download PDF. Download PDF. Original Research; Open Access; … A

Blockchain-based Decentralized Electronic Marketplace for Computing Resources …";Autres articles;;[HTML] springer.com;https://link.springer.com/article/10.1007/s42979-020-00243-7;;"""dc.publisher"",""Springer""
""og:image"",""https://media.springernature.com/w200/springer-static/cover/journal/42979.jpg""
""twitter:card"",""summary""
""og:site_name"",""SN Computer Science""
""citation_reference"",""citation_title=The Business of Sharing: Making It in the New Sharing Economy; citation_publication_date=2015; citation_id=CR1; citation_author=A Stephany; citation_publisher=Palgrave Macmillan"",""Giana M, Eckhardt FB. The Sharing Economy Isn’t About Sharing at All. Harvard Business Review, 2015-01-28,                    https://hbr.org/2015/01/the-sharing-economy-isnt-about-sharing-at-all                                    . [Online; accessed July 2018] 2015"",""citation_journal_title=Comm. of the ACM; citation_title=Decentralized blockchain-based electronic marketplaces; citation_author=H Subramanian; citation_volume=61; citation_issue=1; citation_publication_date=2018; citation_pages=78-84; citation_doi=10.1145/3158333; citation_id=CR3"",""citation_journal_title=The American Economic Review; citation_title=A price theory of multi-sided platforms; citation_author=EG Weyl; citation_volume=100; citation_issue=4; citation_publication_date=2009; citation_pages=1642-1672; citation_doi=10.1257/aer.100.4.1642; citation_id=CR4"",""Anderson DP. BOINC: a system for public-resource computing and storage. In: 5th IEEE/ACM Int. Workshop on Grid Computing, 2004; 4–10"",""Wikipedia: Berkeley Open Infrastructure for Network Computing.                    https://en.wikipedia.org/wiki/Berkeley_Open_Infrastructure_for_Network _Computing                                    . [Online; accessed July 2018] 2018"",""Wikipedia: Tianhe-2.                    https://en.wikipedia.org/wiki/Tianhe-2                                    . [Online; accessed August 2018] 2018"",""Golem Network. Online White paper,                    https://golem.network/doc/Golemwhitepaper.pdf                                    . [Online; accessed May 2019] 2016"",""iExec. Online White paper,                    https://iex.ec/wp-content/uploads/pdf/iExec-WPv3.0-English.pdf                                    . [Online; accessed May 2019] 2018"",""SONM. Online White paper,                    https://whitepaper.io/document/326/sonm-whitepaper                                    . [Online; accessed May 2019] 2017"",""citation_journal_title=Sensors; citation_title=A capillary computing architecture for dynamic internet of things: Orchestration of microservices from edge devices to fog and cloud providers; citation_author=S Taherizadeh, V Stankovski, M Grobelnik; citation_volume=18; citation_publication_date=2018; citation_pages=2938; citation_doi=10.3390/s18092938; citation_id=CR11"",""citation_journal_title=J. Netw. Comput. Appl.; citation_title=Review: Volunteer computing: Requirements, challenges, and solutions; citation_author=M Nouman Durrani, JA Shamsi; citation_volume=39; citation_publication_date=2014; citation_pages=369-380; citation_doi=10.1016/j.jnca.2013.07.006; citation_id=CR12"",""Heien EM, Fujimoto N, Hagihara K. Computing low latency batches with unreliable workers in volunteer computing environments. In: IEEE Int. Symposium on Parallel and Distributed Processing, 2008; 1–8"",""Watanabe K, Fukushi M. Generalized spot-checking for sabotage-tolerance in volunteer computing systems. In: 10th IEEE/ACM Int. Conf. on Cluster, Cloud and Grid Computing, 2010; 655–660"",""citation_journal_title=Journal of Information Processing; citation_title=Adaptive group-based job scheduling for high performance and reliable volunteer computing; citation_author=K Watanabe, M Fukushi, M Kameyama; citation_volume=19; citation_publication_date=2011; citation_pages=39-51; citation_doi=10.2197/ipsjjip.19.39; citation_id=CR15"",""citation_journal_title=IEEE Trans. on Cloud Computing; citation_title=Co-operative resource allocation: Building an open cloud market using shared infrastructure; citation_author=K Chard, K Bubendorfer; citation_volume=7; citation_issue=1; citation_publication_date=2019; citation_pages=183-195; citation_doi=10.1109/TCC.2016.2594174; citation_id=CR16"",""citation_title=Dependable Computing and Fault-Tolerant Systems Vol. 1: The Evolution of Fault-Tolerant Computing; citation_publication_date=1987; citation_id=CR17; citation_author=A Avizienis; citation_publisher=Springer"",""Holt RM. MOS processor for the F14A CADC. Technical Report No. 71-7266, Garrett AiResearch Corp 1971"",""Briere D, Traverse P. AIRBUS A320/A330/A340 electrical flight controls: A family of fault-tolerant systems. In: 23rd Int. Symposium on Fault-Tolerant Computing (FTCS’93) 1993"",""Sarmenta LFG. Sabotage-tolerance mechanisms for volunteer computing systems. Future Gener. Comput. Syst. 2002; 18(4)"",""Dong C, Wang Y, Aldweesh A, McCorry P, van Moorsel A. Betrayal, distrust, and rationality: Smart counter-collusion contracts for verifiable cloud computing. In: ACM SIGSAC Conference on Computer and Communications Security (CCS’17), 2017; 211–227"",""Arora S, Lund C, Motwani R, Sudan M, Szegedy M. Proof verification and hardness of approximation problems. In: 33rd Annual Symposium on Foundations of Computer Science (FOCS’92), Pittsburgh, Pennsylvania, 1992; 14–23"",""Arora S, Safra S. Probabilistic checking of proofs; A new characterization of NP. In: 33rd Annual Symposium on Foundations of Computer Science (FOCS’92), Pittsburgh, Pennsylvania, 1992; 2–13"",""Arora S, Lund C, Motwani R, Sudan M, Szegedy M. Proof verification and the hardness of approximation problems. J. ACM 1998; 45(3)"",""citation_journal_title=J. ACM; citation_title=Probabilistic checking of proofs: A new characterization of NP; citation_author=S Arora, S Safra; citation_volume=45; citation_issue=1; citation_publication_date=1998; citation_pages=70-122; citation_doi=10.1145/273865.273901; citation_id=CR25"",""citation_journal_title=J. ACM; citation_title=Delegating computation: Interactive proofs for muggles; citation_author=S Goldwasser, YT Kalai, GN Rothblum; citation_volume=62; citation_issue=4; citation_publication_date=2015; citation_pages=27-12764; citation_doi=10.1145/2699436; citation_id=CR26"",""Gennaro R, Gentry C, Parno B. Non-interactive verifiable computing: Outsourcing computation to untrusted workers. In: Rabin, T. (ed.) Advances in Cryptology (CRYPTO’10) 2010"",""citation_journal_title=Commun. ACM; citation_title=Verifying computations without reexecuting them; citation_author=M Walfish, AJ Blumberg; citation_volume=58; citation_issue=2; citation_publication_date=2015; citation_pages=74-84; citation_doi=10.1145/2641562; citation_id=CR28"",""Teutsch J, Reitwies̈sner C. A scalable verification solution for blockchains. CoRR                    arXiv:1908.04756                                     2019"",""Luu L, Teutsch J, Kulkarni R, Saxena P. Demystifying incentives in the consensus computer. In: Proc. of the 22nd ACM SIGSAC Conf. on Computer and Communications Security (CCS’15), 2015; 706–719"",""Sadeghi A-R, Schneider T, Winandy M. Token-based cloud computing. In: Trust and Trustworthy Computing, 2010; 17–429"",""Resnick P, Zeckhauser R. In: Baye, M.R. (ed.) Trust among strangers in internet transactions: Empirical analysis of eBay’ s reputation system, vol. 11, pp. 127–157. Emerald Group Publishing Limited, Bingley, United Kingdom 2002"",""Post A, Shah V, Mislove A. Bazaar: Strengthening user reputations in online marketplaces. In: 8th USENIX Conf. on Networked Systems Design and Implementation (NSDI’11), 2011; 183–196"",""Soska K, Kwon A, Christin N, Devadas S. Beaver: A decentralized anonymous marketplace with secure reputation. Technical Report 2016/464, IACR Cryptology ePrint Archive 2016"",""citation_journal_title=Commun. ACM; citation_title=Deception, identity, and security: The game theory of sybil attacks; citation_author=W Casey, A Kellner, P Memarmoshrefi, JA Morales, B Mishra; citation_volume=62; citation_issue=1; citation_publication_date=2018; citation_pages=85-93; citation_doi=10.1145/3190836; citation_id=CR35"",""Casey W, Memarmoshrefi P, Kellner A, Morales JA, Mishra B. Identity deception and game deterrence via signaling games. In: Proc. of the 9th EAI Int. Conf. on Bio-inspired Information and Communications Technologies (BICT’15), New York City, New York, 2016; 73–82"",""Falcarin P, Scandariato R, Baldi M, Ofek Y. Integrity checking in remote computation. Technical report, Politecnico di Torino (January 2005)"",""Khan SM, Hamlen KW. Computation certification as a service in the cloud. In: 2013 13th IEEE/ACM International Symposium on Cluster, Cloud, and Grid Computing, 2013; 434–441                    https://doi.org/10.1109/CCGrid.2013.75                                    "",""Premnath SN, Haas ZJ. A practical, secure, and verifiable cloud computing for mobile systems. CoRR.                    arxiv: 1410.1389                                     2014"",""Klems M, Eberhardt J, Tai S, Härtlein S, Buchholz S, Tidjani A. Trustless intermediation in blockchain-based decentralized service marketplaces. In: Service-Oriented Computing, 2017; 731–739"",""Jakobsson M. Ripping coins for a fair exchange. In: Advances in Cryptology (EUROCRYPT’95), 1995; 220–230"",""Asokan N, Schunter M, Waidner M. Optimistic protocols for fair exchange. In: 4th ACM Conf. on Computer and Communications Security(CSS’97), 1997; 7–17"",""Bao F, Deng RH, Mao W. Efficient and practical fair exchange protocols with off-line TTP. In: 1998 IEEE Symposium on Security and Privacy, 1998; 77–85"",""Even S, Goldreich O, Lempel A. A randomized protocol for signing contracts. In: Advances in Cryptology, 1983; 205–210"",""Okamoto T, Ohta K. How to simultaneously exchange secrets by general assumptions. In: 2nd ACM Conference on Computer and Communications Security(CSS’94). CCS ’94, 1994;184–192"",""Even S, Yacobi Y. Relations among public key signature systems. Technical Report 175, Technion 1990"",""Pagnia H, Gärtner FC. On the impossibility of fair exchange without a trusted third party. Technical Report TUD-BS-1992-02, Darmstadt University of Technology 1999"",""Garbinato B, Rickebusch I. Impossibility results on fair exchange. In: 10th Int. Conf. on Innovative Internet Community Systems (I2CS’10), 2010; 507–518"",""Cachin C, Camenisch J. Optimistic fair secure computation. In: Advances in Cryptology (CRYPTO’00), 2000; 93–111"",""Micali S. Simple and fast optimistic protocols for fair electronic exchange. In: 22nd Annual Symposium on Principles of Distributed Computing (PODC’03), 2003; 12–19"",""citation_journal_title=Comput. Netw.; citation_title=Usable optimistic fair exchange; citation_author=A Küpçü, A Lysyanskaya; citation_volume=56; citation_issue=1; citation_publication_date=2012; citation_pages=50-63; citation_doi=10.1016/j.comnet.2011.08.005; citation_id=CR51"",""citation_title=Bitcoin and Cryptocurrency Technologies: A Comprehensive Introduction; citation_publication_date=2016; citation_id=CR52; citation_author=A Narayanan; citation_author=J Bonneau; citation_author=E Felten; citation_author=A Miller; citation_author=S Goldfeder; citation_publisher=Princeton University Press"",""citation_journal_title=Commun. ACM; citation_title=Bitcoin’s underlying incentives; citation_author=Y Sompolinsky, A Zohar; citation_volume=61; citation_issue=3; citation_publication_date=2018; citation_pages=46-53; citation_doi=10.1145/3152481; citation_id=CR53"",""citation_journal_title=Commun. ACM; citation_title=Bitcoin’s academic pedigree; citation_author=A Narayanan, J Clark; citation_volume=60; citation_issue=12; citation_publication_date=2017; citation_pages=36-45; citation_doi=10.1145/3132259; citation_id=CR54"",""citation_title=Introducing Ethereum and Solidity; citation_publication_date=2017; citation_id=CR55; citation_author=C Dannen; citation_publisher=Springer"",""Merkel D. Docker: Lightweight linux containers for consistent development and deployment. Linux J. 2014; 2014(239)"",""citation_title=Applied Cryptography - Protocols, Algorithms, and Source Code in C; citation_publication_date=1996; citation_id=CR57; citation_author=B Schneier; citation_publisher=Wiley"",""Jayasinghe D, Markantonakis K, Mayes K. Optimistic fair-exchange with anonymity for bitcoin users. In: 11th Int. Conf. on e-Business Engineering, 2014; 44–51"",""Goldfeder S, Bonneau J, Gennaro R, Narayanan A. Escrow protocols for cryptocurrencies: How to buy physical goods using bitcoin. In: Financial Cryptography and Data Security, 2017; 321–339"",""citation_journal_title=IEEE Security Privacy; citation_title=Toward fairness of cryptocurrency payments; citation_author=J Liu, W Li, GO Karame, N Asokan; citation_volume=16; citation_issue=3; citation_publication_date=2018; citation_pages=81-89; citation_doi=10.1109/MSP.2018.2701163; citation_id=CR60"",""Zhao S, Lo V, GauthierDickey C. Result verification and trust-based scheduling in peer-to-peer grids. In: Proc. of the 5th IEEE Int. Conf. on Peer-to-Peer Computing (P2P’05), 2005; 31–38"",""citation_title=Uncheatable distributed computations; citation_inbook_title=Topics in Cryptology (CT-RSA’01); citation_publication_date=2001; citation_pages=425-440; citation_id=CR62; citation_author=P Golle; citation_author=I Mironov; citation_publisher=CA"",""Bendahmane A, Bennasar H, Essaaidi M. An efficient approach to improve security for mapreduce computation in cloud system. In: Proc. of the Int. Conf. on Learning and Optimization Algorithms: Theory and Applications (LOPAL’18) 2018"",""FreedomLab: Where the blockchain meets the real world. No. 224, Theme 01, Week 48,                    http://freedomlab.org/where-the-blockchain-meets-the-real-world/                                    . [Online; accessed March 2020] 2019"",""citation_journal_title=Future Generation Computer Systems; citation_title=An overview on smart contracts: Challenges, advances and platforms; citation_author=Z Zheng, S Xie, H-N Dai, W Chen, X Chen, J Weng, M Imran; citation_volume=105; citation_publication_date=2020; citation_pages=475-491; citation_doi=10.1016/j.future.2019.12.019; citation_id=CR65"",""Zhang F, Cecchetti E, Croman K, Juels A, Shi E. Town crier: An authenticated data feed for smart contracts. In: Proc. of the 2016 ACM SIGSAC Conf. on Computer and Communications Security (CCS’16), 2016; 270–282"",""Ellis S, Juels A, Nazarov S. Chainlink: a decentralized oracle network.                    https://chain.link/                                    . [Online; accessed March 2020] 2017"",""Trón V. Announcing Swarm Proof-of-Concept Release 3. Ethereum Blog,                    https://blog.ethereum.org/2018/06/21/announcing-swarm-proof-of-concept-release-3/                                    . [Online; accessed March 2020] 2018"",""Yang R, Murray T, Rimba P, Parampalli U. Empirically analyzing Ethereum’s gas mechanism. CoRR                    arxiv: abs/1905.00553                                     2019"",""Docker Inc: Docker - Build, Ship, and Run Any App, Anywhere.                    https://www.docker.com/                                     Accessed 2018-06-20"",""Vaughan-Nichols, S.J.: What Is Docker and Why Is It so Darn Popular?                    https://www.zdnet.com/article/what-is-docker-and-why-is-it-so-darn-popular/                                     Accessed 2018-10-30"",""von Leon D, Miori L, Sanin J, Ioini NE, Helmer S, Pahl C. A performance exploration of architectural options for a middleware for decentralised lightweight edge cloud architectures. In: 3rd Int. Conf. on Internet of Things, Big Data and Security (IoTBDS’18), Funchal, Madeira, 2018; 73–84"",""Pahl C, Helmer S, Miori L, Sanin J, Lee B. A container-based edge cloud paas architecture based on raspberry pi clusters. In: 4th Int. Conf. on Future Internet of Things and Cloud Workshops (FiCloud’16), Vienna, Austria, 2016; 117–124"",""Naik N. Docker container-based big data processing system in multiple clouds for everyone. In: IEEE Int. Systems Engineering Symposium (ISSE’17), 2017; 1–7"",""Wu C, Buyya R, Ramamohanarao K. Cloud pricing models: Taxonomy, survey, and interdisciplinary challenges. ACM Comput. Surv. 2019; 52(6)"",""Portella G, Rodrigues GN, Nakano E, Melo ACMA. Statistical analysis of amazon ec2 cloud pricing models. Concurrency and Computation: Practice and Experience. 2019;31(18)"",""Bano S, Sonnino A, Al-Bassam M, Azouvi S, McCorry P, Meiklejohn S, Danezis G. Consensus in the age of blockchains. CoRR                    arxiv: abs/1711.03936                                     2017"",""CoinDesk: Ethereum’s Big Switch: The New Roadmap to Proof-of-Stake.                    https://www.coindesk.com/ethereums-big-switch-the-new-roadmap-to-proof-of-stake/                                    . [Online; accessed October 2017] 2017"",""Docker: Docker security. Docker Docs,                    https://docs.docker.com/engine/security/security/                                    . [Online; accessed March 2019] 2019"",""citation_journal_title=Commun. ACM; citation_title=Research for practice: Security for the modern age; citation_author=J Frazelle; citation_volume=62; citation_issue=1; citation_publication_date=2019; citation_pages=43-45; citation_doi=10.1145/3287295; citation_id=CR80"",""Barham P, Dragovic B, Fraser K, Hand S, Harris T, Ho A, Neugebauer R, Pratt I, Warfield A. Xen and the art of virtualization. In: Proc. of the 19th ACM Symposium on Operating Systems Principles SOSP’03, Bolton Landing, New York, 2003; 164–177"",""Manco F, Lupu C, Schmidt F, Mendes J, Kuenzer S, Sati S, Yasukata K, Raiciu C, Huici F. My VM is lighter (and safer) than your container. In: Proc. of the 26th Symposium on Operating Systems Principles (SOSP’17), Shanghai, China, 2017; 218–233"",""Williams D, Koller R, Lucina M, Prakash N. Unikernels as processes. In: Proc. of the ACM Symposium on Cloud Computing (SoCC’18), Carlsbad, California, pp. 2018; 199–211"",""Edge J. A seccomp overview. LWN,                    https://lwn.net/Articles/656307/                                    . [Online; accessed March 2019] 2015"",""Kerrisk M. Using seccomp to limit the kernel attack surface. In: Linux Plumbers Conference (LPC’15), Seattle, Washington 2015"",""Docker: Seccomp security profiles for Docker. Docker Docs,                    https://docs.docker.com/engine/security/seccomp/                                    . [Online; accessed March 2019] 2019"",""Witt M, Jansen C, Krefting D, Streit A. Fine-grained supervision and restriction of biomedical applications in linux containers. In: 17th IEEE/ACM Int. Symposium on Cluster, Cloud and Grid Computing (CCGRID’17), 2017; 813–822"",""Witt M, Jansen C, Krefting D, Streit A. Sandboxing of biomedical applications in linux containers based on system call evaluation. Concurrency and Computation: Practice and Experience. 2018;30(12):"",""Babcock C. Google: Docker Does Containers Right. InformationWeek,                    https://www.informationweek.com/cloud/infrastructure-as-a-service/google-docker-does-containers-right/d/d-id/1319146                                    . [Online; accessed March 2019] 2015"",""citation_journal_title=Queue; citation_title=Unikernels: Rise of the virtual library operating system; citation_author=A Madhavapeddy, DJ Scott; citation_volume=11; citation_issue=11; citation_publication_date=2013; citation_pages=30-44; citation_doi=10.1145/2557963.2566628; citation_id=CR90"",""Asokan N. Fairness in electronic commerce. PhD thesis, University of Waterloo, Waterloo, Canada 1998"",""citation_journal_title=SCRIPTed - A Journal of Law, Technology & Society; citation_title=Blockchains and online dispute resolution: Smart contracts as an alternative to enforcement; citation_author=R Koulu; citation_volume=13; citation_issue=1; citation_publication_date=2016; citation_pages=40-69; citation_id=CR92"",""citation_journal_title=Lex Electronica; citation_title=Three quests for the justification in the ODR era: Sovereignty, contract and quality standards; citation_author=R Koulu; citation_volume=19; citation_issue=1; citation_publication_date=2014; citation_pages=43-71; citation_id=CR93"",""citation_title=Online Dispute Resolution: Challenges for Contemporary Justice; citation_publication_date=2004; citation_id=CR94; citation_author=G Kaufmann-Kohler; citation_author=T Schultz; citation_publisher=International Arbitration Law Library Series Set. Kluwer Law International"",""citation_journal_title=Harvard Law Review; citation_title=The role of substantive law and procedure in the legal process; citation_author=TW Arnold; citation_volume=45; citation_issue=4; citation_publication_date=1932; citation_pages=617-647; citation_doi=10.2307/1331381; citation_id=CR95"",""Zamani M, Movahedi M, Raykova M. Rapidchain: Scaling blockchain via full sharding. In: Proc. of the ACM SIGSAC Conf. on Computer and Communications Security (CCS’18), 2018; 931–948""
""citation_journal_title"",""SN Computer Science""
""language"",""en""
""citation_cover_date"",""2020/09/01""
""og:description"",""We propose a framework for building a decentralized electronic marketplace for computing resources. The idea is that anyone with spare capacities can offer them on this marketplace, opening up the cloud computing market to smaller players, thus creating a more competitive environment compared to today’s market consisting of a few large providers. Trust is a crucial component in making an anonymized decentralized marketplace a reality. We develop protocols that enable participants to interact with each other in a fair way and show how these protocols can be implemented using smart contracts and blockchains. We discuss and evaluate our framework not only from a technical point of view, but also look at the wider context in terms of fair interactions and legal implications.""
""prism.issn"",""2661-8907""
""citation_author_email"",""matteo.shalen@gmail.com"",""helmer@ifi.uzh.ch"",""Nabil.ElIoini@unibz.it"",""Claus.Pahl@unibz.it""
""twitter:image:alt"",""Content cover image""
""prism.number"",""5""
""citation_issn"",""2661-8907""
""citation_language"",""en""
""dc:title"",""A Blockchain-based Decentralized Electronic Marketplace for Computing Resources | SpringerLink""
""Content-Encoding"",""UTF-8""
""citation_pdf_url"",""https://link.springer.com/content/pdf/10.1007/s42979-020-00243-7.pdf""
""citation_lastpage"",""24""
""DOI"",""10.1007/s42979-020-00243-7""
""citation_fulltext_world_readable"",""""
""citation_journal_abbrev"",""SN COMPUT. SCI.""
""prism.rightsAgent"",""journalpermissions@springernature.com""
""citation_author"",""Matteo Nardini"",""Sven Helmer"",""Nabil El Ioini"",""Claus Pahl""
""resourceName"",""s42979-020-00243-7""
""dc.date"",""2020-08-06""
""citation_springer_api_url"",""http://api.springer.com/metadata/pam?q=doi:10.1007/s42979-020-00243-7&api_key=""
""citation_issue"",""5""
""prism.volume"",""1""
""prism.publicationName"",""SN Computer Science""
""citation_doi"",""10.1007/s42979-020-00243-7""
""dc.title"",""A Blockchain-based Decentralized Electronic Marketplace for Computing Resources""
""prism.url"",""https://link.springer.com/article/10.1007/s42979-020-00243-7""
""citation_volume"",""1""
""dc.language"",""En""
""Content-Language"",""en""
""format-detection"",""telephone=no""
""citation_publication_date"",""2020/09""
""prism.endingPage"",""24""
""citation_title"",""A Blockchain-based Decentralized Electronic Marketplace for Computing Resources""
""citation_author_institution"",""Faculty of Computer Science, Free University of Bozen-Bolzano, Bolzano, Italy"",""Department of Informatics, University of Zurich, Zurich, Switzerland"",""Faculty of Computer Science, Free University of Bozen-Bolzano, Bolzano, Italy"",""Faculty of Computer Science, Free University of Bozen-Bolzano, Bolzano, Italy""
""access"",""Yes""
""citation_publisher"",""Springer Singapore""
""applicable-device"",""pc,mobile""
""dc.format"",""text/html""
""description"",""We propose a framework for building a decentralized electronic marketplace for computing resources. The idea is that anyone with spare capacities can offer""
""title"",""A Blockchain-based Decentralized Electronic Marketplace for Computing Resources | SpringerLink""
""citation_online_date"",""2020/08/06""
""twitter:site"",""@SpringerLink""
""dc.source"",""SN Computer Science 2020 1:5""
""dc.type"",""OriginalPaper""
""dc.copyright"",""2020 The Author(s)""
""dc.creator"",""Matteo Nardini"",""Sven Helmer"",""Nabil El Ioini"",""Claus Pahl""
""citation_fulltext_html_url"",""https://link.springer.com/article/10.1007/s42979-020-00243-7""
""prism.publicationDate"",""2020-08-06""
""Content-Type"",""text/html; charset=UTF-8""
""journal_id"",""42979""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""dc.description"",""We propose a framework for building a decentralized electronic marketplace for computing resources. The idea is that anyone with spare capacities can offer them on this marketplace, opening up the cloud computing market to smaller players, thus creating a more competitive environment compared to today’s market consisting of a few large providers. Trust is a crucial component in making an anonymized decentralized marketplace a reality. We develop protocols that enable participants to interact with each other in a fair way and show how these protocols can be implemented using smart contracts and blockchains. We discuss and evaluate our framework not only from a technical point of view, but also look at the wider context in terms of fair interactions and legal implications.""
""og:type"",""article""
""citation_article_type"",""Original Research""
""og:title"",""A Blockchain-based Decentralized Electronic Marketplace for Computing Resources""
""prism.doi"",""doi:10.1007/s42979-020-00243-7""
""X-UA-Compatible"",""IE=edge""
""citation_firstpage"",""1""
""prism.startingPage"",""1""
""viewport"",""width=device-width, initial-scale=1""
""dc.rightsAgent"",""journalpermissions@springernature.com""
""prism.section"",""OriginalPaper""
""dc.identifier"",""doi:10.1007/s42979-020-00243-7""
""dc.subject"",""Computer Science, general"",""Computer Systems Organization and Communication Networks"",""Software Engineering/Programming and Operating Systems"",""Data Structures and Information Theory"",""Information Systems and Communication Service"",""Computer Imaging, Vision, Pattern Recognition and Graphics""
""og:url"",""https://link.springer.com/article/10.1007/s42979-020-00243-7""
""prism.copyright"",""2020 The Author(s)""
";https://scholar.google.com/scholar?start=410&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095306-1301;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Blockchain application in seafood value chains;F Blaha, K Katafono ; FAO Fisheries and Aquaculture Circular, 2020  search.proquest.com;;"… cannot access data from outside its system and, thus, data to make the blockchain are supplied …

An oracle can be hardware-based, software- based or consensus-based. Examples of hardware

oracles are sensors, IoT and weather stations, while software examples are a New …";Cité 4 fois;;null;;;;https://scholar.google.com/scholar?start=100&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095311-1318;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Step on the gas? a better approach for recommending the ethereum gas price;SM Werner, PJ Pritz, D Perez ; Mathematical Research for Blockchain …, 2020  Springer;;"… 6.2 Gas Price Oracles … 8. Dannen, C. (2017). Introducing ethereum and solidity: Foundations of

cryptocurrency and blockchain programming for beginners (1st ed.). Berkely, CA, USA:

Apress.Google Scholar … Gas price oracle. https://www.etherchain.org/tools/gasPriceOracle …";Cité 6 fois;Les 7 versions;[PDF] arxiv.org;https://arxiv.org/pdf/2003.03479;;"""date"",""2021-01-21T03:31:09Z""
""pdf:unmappedUnicodeCharsPerPage"",""6"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""3"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.5""
""xmp:CreatorTool"",""TeX""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dcterms:created"",""2021-01-21T03:31:09Z""
""language"",""en""
""Last-Modified"",""2021-01-21T03:31:09Z""
""dcterms:modified"",""2021-01-21T03:31:09Z""
""dc:format"",""application/pdf; version=1.5""
""Last-Save-Date"",""2021-01-21T03:31:09Z""
""pdf:docinfo:creator_tool"",""TeX""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2021-01-21T03:31:09Z""
""meta:save-date"",""2021-01-21T03:31:09Z""
""pdf:encrypted"",""false""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.21 (TeX Live 2020) kpathsea version 6.3.2""
""modified"",""2021-01-21T03:31:09Z""
""Content-Length"",""451314""
""pdf:hasMarkedContent"",""false""
""Content-Type"",""application/pdf""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.21 (TeX Live 2020) kpathsea version 6.3.2""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""trapped"",""False""
""meta:creation-date"",""2021-01-21T03:31:09Z""
""created"",""2021-01-21T03:31:09Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""16""
""Creation-Date"",""2021-01-21T03:31:09Z""
""resourceName"",""2003.03479""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""2029"",""2367"",""2518"",""2232"",""1164"",""533"",""2057"",""2358"",""1307"",""2259"",""516"",""2041"",""1396"",""2455"",""2514"",""2291""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""producer"",""pdfTeX-1.40.21""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""pdfTeX-1.40.21""
""pdf:docinfo:created"",""2021-01-21T03:31:09Z""
";https://scholar.google.com/scholar?start=120&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095325-1380;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;SoK: Layer-two blockchain protocols;L Gudgeon, P Moreno;Sanchez, S Roos…  … Conference on Financial …, 2020  Springer;;"… Keywords. Applied cryptography Blockchain applications Layer-two blockchain protocols

Blockchain scaling Cryptocurrency adoption. The full version of this paper available at

https://eprint.iacr.org/2019/360.pdf. Download conference paper PDF. 1 Introductions …";Cité 26 fois;Les 5 versions;[PDF] ifca.ai;http://fc20.ifca.ai/preproceedings/150.pdf;;"""date"",""2020-01-25T17:32:22Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""7"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""10"",""30""
""pdf:PDFVersion"",""1.5""
""xmp:CreatorTool"",""TeX""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dcterms:created"",""2020-01-25T17:32:22Z""
""language"",""en""
""Last-Modified"",""2020-01-25T17:32:22Z""
""dcterms:modified"",""2020-01-25T17:32:22Z""
""dc:format"",""application/pdf; version=1.5""
""Last-Save-Date"",""2020-01-25T17:32:22Z""
""pdf:docinfo:creator_tool"",""TeX""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2020-01-25T17:32:22Z""
""meta:save-date"",""2020-01-25T17:32:22Z""
""pdf:encrypted"",""false""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017) kpathsea version 6.2.3""
""modified"",""2020-01-25T17:32:22Z""
""Content-Length"",""1101762""
""pdf:hasMarkedContent"",""false""
""Content-Type"",""application/pdf""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017) kpathsea version 6.2.3""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""trapped"",""False""
""meta:creation-date"",""2020-01-25T17:32:22Z""
""created"",""2020-01-25T17:32:22Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""44""
""Creation-Date"",""2020-01-25T17:32:22Z""
""resourceName"",""150.pdf""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""2195"",""2809"",""2060"",""2660"",""2240"",""2353"",""2575"",""2672"",""2718"",""2647"",""2572"",""2499"",""2178"",""2343"",""2590"",""2547"",""2344"",""2561"",""2414"",""2553"",""2649"",""2818"",""2899"",""2935"",""2868"",""2890"",""2835"",""2840"",""2580"",""2797"",""2260"",""1553"",""2638"",""2680"",""2737"",""2779"",""2686"",""2572"",""2828"",""2576"",""1333"",""2121"",""547"",""1207""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""producer"",""pdfTeX-1.40.18""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""pdfTeX-1.40.18""
""pdf:docinfo:created"",""2020-01-25T17:32:22Z""
";https://scholar.google.com/scholar?start=180&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095376-1601;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Towards a Secure Signature Scheme Based on Multimodal Biometric Technology: Application for IOT Blockchain Network;OA Hassen, AA Abdulhussein, SM Darwish… ; Symmetry, 2020  mdpi.com;;"… Towards a Secure Signature Scheme Based on Multimodal Biometric Technology:

Application for IOT Blockchain Network … In a traditional blockchain, users or membership

servers handle private keys or store them at wallets to maintain security …";Cité 1 fois;Les 4 versions;[PDF] mdpi.com;https://www.mdpi.com/2073-8994/12/10/1699/pdf;;;https://scholar.google.com/scholar?start=400&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095327-1385;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Moving from shareholder to stakeholder value: an investigation into blockchain and its ability to govern common pool resources and incentivize collaborative behavior;JM Stavinoha ; Master Thesis Series in Environmental Studies and …, 2020  lup.lub.lu.se;;"… with a set of predefined options in the form of transactions, Ethereum, along with oracles,

provide a … within the function of a smart contract and an oracle in the EVM, which provides

determinism in … If a blockchain such as Ethereum acts …";Autres articles;;[PDF] lu.se;https://lup.lub.lu.se/student-papers/record/9012433/file/9012459.pdf;;"""date"",""2020-06-02T08:33:54Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.5""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""language"",""en""
""Last-Modified"",""2020-06-02T08:33:54Z""
""dcterms:modified"",""2020-06-02T08:33:54Z""
""dc:format"",""application/pdf; version=1.5""
""Last-Save-Date"",""2020-06-02T08:33:54Z""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2020-06-02T08:33:54Z""
""meta:save-date"",""2020-06-02T08:33:54Z""
""pdf:encrypted"",""false""
""modified"",""2020-06-02T08:33:54Z""
""Content-Length"",""792334""
""pdf:hasMarkedContent"",""false""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""49""
""resourceName"",""9012459.pdf""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""517"",""465"",""70"",""3424"",""1499"",""1144"",""2453"",""2890"",""1971"",""2580"",""2681"",""3138"",""2782"",""2425"",""2424"",""2349"",""2181"",""2506"",""3063"",""2573"",""2160"",""2971"",""2670"",""2896"",""2717"",""3163"",""2892"",""2395"",""3299"",""2516"",""833"",""2482"",""2932"",""2987"",""2885"",""2744"",""1961"",""8"",""2384"",""2068"",""2426"",""2190"",""2162"",""2087"",""2346"",""1271"",""1867"",""2583"",""565""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""producer"",""macOS Version 10.15.3 (Build 19D76) Quartz PDFContext, AppendMode 1.1""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""macOS Version 10.15.3 (Build 19D76) Quartz PDFContext, AppendMode 1.1""
";https://scholar.google.com/scholar?start=190&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095316-1336;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;[PDF][PDF] Formal Security Analysis for Blockchain-based Software Architecture;N Chondamrongkul, J Sun, I Warren ; … International Conference on …, 2020  ksiresearch.org;;"… However, when the oracle component feeds data to the blockchain, the data are

assumed to be trusted by all participants. If the oracle … scenario. In our example system,

the Blockchain Integrator serves as an oracle component. If the …";Cité 1 fois;Version HTML;[PDF] ksiresearch.org;https://ksiresearch.org/seke/seke20paper/paper024.pdf;;"""date"",""2020-04-27T00:01:56Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""14"",""2"",""0""
""pdf:PDFVersion"",""1.5""
""xmp:CreatorTool"",""TeX""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dcterms:created"",""2020-04-27T00:01:56Z""
""language"",""en""
""Last-Modified"",""2020-04-27T00:01:56Z""
""dcterms:modified"",""2020-04-27T00:01:56Z""
""dc:format"",""application/pdf; version=1.5""
""Last-Save-Date"",""2020-04-27T00:01:56Z""
""pdf:docinfo:creator_tool"",""TeX""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2020-04-27T00:01:56Z""
""meta:save-date"",""2020-04-27T00:01:56Z""
""pdf:encrypted"",""false""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is MiKTeX-pdfTeX 2.9.6642 (1.40.19)""
""modified"",""2020-04-27T00:01:56Z""
""Content-Length"",""286658""
""pdf:hasMarkedContent"",""false""
""Content-Type"",""application/pdf""
""PTEX.Fullbanner"",""This is MiKTeX-pdfTeX 2.9.6642 (1.40.19)""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""trapped"",""False""
""meta:creation-date"",""2020-04-27T00:01:56Z""
""created"",""2020-04-27T00:01:56Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""6""
""Creation-Date"",""2020-04-27T00:01:56Z""
""resourceName"",""paper024.pdf""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""4530"",""4741"",""4566"",""5073"",""4868"",""5589""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""producer"",""MiKTeX pdfTeX-1.40.19""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""MiKTeX pdfTeX-1.40.19""
""pdf:docinfo:created"",""2020-04-27T00:01:56Z""
";https://scholar.google.com/scholar?start=140&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095351-1487;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Deterministic Blockchain BFT Protocol XP for Complete Asynchronous Networks;Y Wang ; arXiv preprint arXiv:2005.04309, 2020  arxiv.org;;"… This kind of blockchain properties do not hold for general BFT application scenarios … In order to

address this challenge, Ethereum community provides three “safety oracles” (see [16]) to … The

first “adversary oracle” simulates some protocol execution to see whether the current …";Autres articles;;[PDF] arxiv.org;https://arxiv.org/pdf/2005.04309;;"""date"",""2020-12-11T03:35:42Z""
""pdf:PDFVersion"",""1.4""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.4""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""xmp:CreateDate"",""2020-12-10T22:35:42Z""
""modified"",""2020-12-11T03:35:42Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""xmp:ModifyDate"",""2020-12-10T22:35:42Z""
""pdf:docinfo:creator"",""""
""meta:author"",""""
""meta:creation-date"",""2020-12-11T03:35:42Z""
""created"",""2020-12-11T03:35:42Z""
""xmp:About"",""uuid:7e9d8a21-737e-11f6-0000-1e8efe4d3dc1""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-12-11T03:35:42Z""
""resourceName"",""2005.04309""
""Author"",""""
""producer"",""dvips + GPL Ghostscript GIT PRERELEASE 9.22""
""pdf:docinfo:producer"",""dvips + GPL Ghostscript GIT PRERELEASE 9.22""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""9"",""9"",""7"",""0"",""18"",""4""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2020-12-11T03:35:42Z""
""Last-Modified"",""2020-12-11T03:35:42Z""
""dcterms:modified"",""2020-12-11T03:35:42Z""
""title"",""""
""xmpMM:DocumentID"",""uuid:7e9d8a21-737e-11f6-0000-1e8efe4d3dc1""
""Last-Save-Date"",""2020-12-11T03:35:42Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2020-12-11T03:35:42Z""
""meta:save-date"",""2020-12-11T03:35:42Z""
""Content-Length"",""141893""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""8""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""3725"",""3847"",""2279"",""3600"",""3306"",""2958"",""2035"",""1318""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-12-11T03:35:42Z""
";https://scholar.google.com/scholar?start=290&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095295-1250;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Blockchain for giving patients control over their medical records;MM Madine, AA Battah, I Yaqoob, K Salah… ; IEEE …, 2020  ieeexplore.ieee.org;;"… At every interaction of the patient or the doctor with the trusted oracles, there is a possibility that

some oracle nodes will … Therefore, on top of ensuring that a majority of the oracle nodes have

a … MM Madine et al.: Blockchain for Giving Patients Control Over Their Medical Records …";Cité 5 fois;Les 6 versions;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/6287639/8948470/09233462.pdf;;"""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""dc:title"",""IEEE Xplore Full-Text PDF:""
""Content-Encoding"",""UTF-8""
""resourceName"",""09233462.pdf""
""language"",""es""
""Content-Length"",""2565""
""title"",""IEEE Xplore Full-Text PDF:""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=50&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095392-1668;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;[LIVRE][B] Algorithms, Blockchain & Cryptocurrency: Implications for the Future of the Workplace;G Brown, R Whittle ;2020 books.google.com;;"… this new world from the per- spective of the worker, we overweight our analysis based on

cryptocurrency, we consider … In this future, algorithms decide what work is needed, blockchain

provides the security to the organisation and the worker and crypto facilitates payment …";Cité 2 fois;Les 4 versions;null;;;;https://scholar.google.com/scholar?start=470&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095392-1672;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Wie funktioniert die Blockchain?;HG Fill, F Härer, A Meier ; Blockchain, 2020  Springer;;"… Oracles in speziellen Smart Contracts zur Verfügung gestellt werden. 1.5 Limitationen und aktuelle

Entwicklungen … In: Kaufmann M, Meier A (Hrsg) Blockchain. HMD Zeitschrift der 

Wirtschaftsinformatik, Jhrg … In: Proceedings advances in cryptology – CRYPTO '87 …";Autres articles;;null;;;;https://scholar.google.com/scholar?start=470&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095323-1369;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Sharing of Encrypted Files in Blockchain Made Simpler;SSD Selvi, A Paul, S Dirisala, S Basu… ; … Research for Blockchain …, 2020  Springer;;"… By facilitating the associated transactions on the blockchain, this scheme provides end-to-end

transparency and … Phase-1: \(\mathcal {A}\) can adaptively issue queries to the following oracles:

Self-encrypt (\(m, t_w\)) Oracle: \(\mathcal {C}\) runs the Self-encrypt (m, \(t_w\), SK, PK …";Cité 1 fois;Les 5 versions;[PDF] iacr.org;https://eprint.iacr.org/2019/418.pdf;;"""date"",""2019-04-14T14:48:58Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2019-04-14T14:48:58Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.1415926-2.5-1.40.14 (TeX Live 2013/Debian) kpathsea version 6.1.1""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2019-04-14T14:48:58Z""
""created"",""2019-04-14T14:48:58Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-04-14T14:48:58Z""
""resourceName"",""418.pdf""
""Author"",""""
""producer"",""pdfTeX-1.40.14""
""pdf:docinfo:producer"",""pdfTeX-1.40.14""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""2"",""4"",""10"",""19"",""10"",""10"",""7"",""19"",""32"",""28"",""19"",""5"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2019-04-14T14:48:58Z""
""Last-Modified"",""2019-04-14T14:48:58Z""
""dcterms:modified"",""2019-04-14T14:48:58Z""
""title"",""""
""Last-Save-Date"",""2019-04-14T14:48:58Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2019-04-14T14:48:58Z""
""meta:save-date"",""2019-04-14T14:48:58Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.1415926-2.5-1.40.14 (TeX Live 2013/Debian) kpathsea version 6.1.1""
""Content-Length"",""274011""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""16""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""3326"",""2786"",""2790"",""2576"",""2314"",""1478"",""2366"",""1914"",""1429"",""1724"",""2282"",""2246"",""1656"",""2192"",""2635"",""3164""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-04-14T14:48:58Z""
";https://scholar.google.com/scholar?start=170&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095404-1714;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Custom Tokens und Smart Contracts zur Projektsteuerung;J Lehner, P Schützeneder, J Sametinger ; Blockchain, 2020  Springer;;"… Im Idealfall werden relevante Zustände eines Projektes über Smart Contracts und Tokens in der

Blockchain abgebildet. In diesem Fall zieht sich die Projektleitung oder auch eine

Steuerungsgruppe auf die Rolle eines „Oracles“ zurück. Das Oracle stellt die Schnittstelle …";Autres articles;;null;;;;https://scholar.google.com/scholar?start=520&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095395-1683;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Encryption schemes using random oracles: from classical to post-quantum security;J Krämer, P Struck ; International Conference on PostQuantum …, 2020  Springer;;"… In our proofs we also consider reprogrammed random oracles. For a random oracle

\({\mathsf {H}}\), we denote the random oracle which is reprogrammed on input \(

x \) to \( y \) by \({\mathsf {H}} _{ x \rightarrow y }\), ie, $$\begin …";Cité 3 fois;Les 3 versions;[PDF] iacr.org;https://eprint.iacr.org/2020/129.pdf;;"""date"",""2021-03-10T08:11:33Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2021-03-10T08:11:33Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is MiKTeX-pdfTeX 2.9.7338 (1.40.21)""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2021-03-10T08:11:33Z""
""created"",""2021-03-10T08:11:33Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2021-03-10T08:11:33Z""
""resourceName"",""129.pdf""
""Author"",""""
""producer"",""MiKTeX pdfTeX-1.40.21""
""pdf:docinfo:producer"",""MiKTeX pdfTeX-1.40.21""
""pdf:unmappedUnicodeCharsPerPage"",""3"",""0"",""0"",""1"",""18"",""10"",""6"",""0"",""6"",""8"",""27"",""4"",""0"",""4"",""2"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2021-03-10T08:11:33Z""
""Last-Modified"",""2021-03-10T08:11:33Z""
""dcterms:modified"",""2021-03-10T08:11:33Z""
""title"",""""
""Last-Save-Date"",""2021-03-10T08:11:33Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2021-03-10T08:11:33Z""
""meta:save-date"",""2021-03-10T08:11:33Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is MiKTeX-pdfTeX 2.9.7338 (1.40.21)""
""Content-Length"",""472940""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""17""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""2086"",""2668"",""2641"",""2383"",""2028"",""2307"",""1678"",""1837"",""1758"",""1989"",""2298"",""2169"",""1656"",""1701"",""2083"",""2920"",""2457""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2021-03-10T08:11:33Z""
";https://scholar.google.com/scholar?start=480&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095327-1389;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Security-Enhanced Timed-Release Encryption in the Random Oracle Model;Z Li, C Jia ; Security and Privacy in Social Networks and Big Data …, 2020  books.google.com;;"… Rivest, RL, Shamir, A., Wagner, DA: Time-lock puzzles and timed-release crypto … Page 62.

Security-Enhanced Timed-Release Encryption in the Random Oracle Model 51 25 … Wei-Jr, L.,

Chih-Wen, H., Ja-Ling, W.: A fully decentralized time-lock encryption system on blockchain …";Autres articles;;null;;;;https://scholar.google.com/scholar?start=190&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095386-1640;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Blockchain for Education Records: An interpretive research on university students' perceptions;A Herkommer, J Kaletka ;2020 divaportal.org;;"… Furthermore, the blockchain cryptocurrency was able to avoid the problem of double spending

(Mougayar, 2016) that describes an issue of digital currencies in which money is maliciously

copied and spend multiple times, while third parties are included to avoid this from …";Autres articles;Version HTML;[PDF] diva-portal.org;https://www.diva-portal.org/smash/get/diva2:1427411/FULLTEXT01.pdf;;;https://scholar.google.com/scholar?start=440&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095406-1724;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;"[PDF][PDF] "" Beyond the Hype of Blockchain–A Scenario-Based Analysis of the Potential Applications in the Music Industry.";M Kessels, A Gidron, P Belleflamme ; dial.uclouvain.be;;"… [Downloaded 2020/12/15 at 09:06:45 ] ""Beyond the Hype of Blockchain – A Scenario-Based

Analysis of the Potential Applications in the Music Industry."" … Page 2. Louvain School of

Management Beyond the Hype of Blockchain – A Scenario-Based Analysis of the …";Autres articles;;[PDF] uclouvain.be;https://dial.uclouvain.be/downloader/downloader.php?pid=thesis%3A20836&datastream=PDF_01;;"""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""dc:title"",""DIAL : download document""
""Content-Encoding"",""UTF-8""
""resourceName"",""downloader.php""
""language"",""fr""
""title"",""DIAL : download document""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=530&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095327-1390;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;[PDF][PDF] Analysis and Implementation of Verifiable Computation Techniques for Energy Blockchain Applications;B Steinkopf ;2020 wwwmatthes.in.tum.de;;"… Blockchain oracles [2] aim to mitigate this problem by on-chaining the data in a way that can

be reconciled by the consensus algorithm. All oracle implementations must contain at least one

dedicated smart contract, so that they can interact with the blockchain …";Les 2 versions;Version HTML;[PDF] tum.de;https://wwwmatthes.in.tum.de/file/1cixq4yheftur/Sebis-Public-Website/-/Master-s-Thesis-Bernd-Steinkopf/steinkopf_bernd_masters_thesis.pdf;;"""date"",""2020-12-14T09:19:12Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2020-12-14T09:19:12Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.20 (TeX Live 2019) kpathsea version 6.3.1""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2020-12-14T09:19:12Z""
""created"",""2020-12-14T09:19:12Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-12-14T09:19:12Z""
""resourceName"",""steinkopf_bernd_masters_thesis.pdf""
""Author"",""""
""producer"",""pdfTeX-1.40.20""
""pdf:docinfo:producer"",""pdfTeX-1.40.20""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""1"",""0"",""16"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""2"",""0"",""7"",""19"",""88"",""16"",""16"",""36"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2020-12-14T09:19:12Z""
""Last-Modified"",""2020-12-14T09:19:12Z""
""dcterms:modified"",""2020-12-14T09:19:12Z""
""title"",""""
""Last-Save-Date"",""2020-12-14T09:19:12Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2020-12-14T09:19:12Z""
""meta:save-date"",""2020-12-14T09:19:12Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.20 (TeX Live 2019) kpathsea version 6.3.1""
""Content-Length"",""1361285""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""117""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""182"",""398"",""135"",""497"",""1784"",""940"",""1552"",""641"",""1105"",""726"",""19"",""2554"",""1192"",""2367"",""911"",""22"",""2376"",""1020"",""2180"",""2684"",""2740"",""1648"",""3055"",""3349"",""169"",""2056"",""2625"",""2660"",""2064"",""1448"",""2574"",""2680"",""2559"",""1587"",""2909"",""2915"",""2739"",""683"",""30"",""1896"",""474"",""1896"",""2674"",""3029"",""2421"",""1050"",""2027"",""2622"",""1267"",""2535"",""2543"",""2444"",""1507"",""2697"",""37"",""1765"",""2235"",""2652"",""2389"",""1895"",""2317"",""2635"",""2277"",""1207"",""2334"",""2981"",""2992"",""2844"",""1961"",""1318"",""18"",""1825"",""2179"",""2934"",""2541"",""3287"",""2394"",""2804"",""3064"",""807"",""2620"",""2697"",""1386"",""23"",""2564"",""2888"",""417"",""2494"",""2865"",""2610"",""2933"",""2720"",""1068"",""2400"",""1669"",""1826"",""1932"",""734"",""2633"",""10"",""1113"",""1434"",""1176"",""1617"",""1310"",""1725"",""1508"",""130"",""2093"",""2292"",""2295"",""2233"",""2366"",""2295"",""2139"",""2354"",""1530""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-12-14T09:19:12Z""
";https://scholar.google.com/scholar?start=190&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095358-1520;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;LedgerDB: a centralized ledger database for universal audit and verification;X Yang, Y Zhang, S Wang, B Yu, F Li, Y Li… ; Proceedings of the VLDB …, 2020  dl.acm.org;;"… For ex- ample, AWS discloses QLDB [7, 13] that leverages an im- mutable and verifiable ledger;

Oracle announces its blockcha- in table … Many blockchain users wish to clean up obsolete records

for storage savings, since it will other- wise become unaffordable as data volume …";Autres articles;;[PDF] vldb.org;http://www.vldb.org/pvldb/vol13/p3138-yang.pdf;;"""date"",""2020-08-27T07:11:26Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""37"",""0"",""0"",""0"",""1"",""1"",""0"",""1"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.5""
""xmp:CreatorTool"",""TeX""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dcterms:created"",""2020-08-13T08:01:29Z""
""language"",""en""
""Last-Modified"",""2020-08-27T07:11:26Z""
""dcterms:modified"",""2020-08-27T07:11:26Z""
""dc:format"",""application/pdf; version=1.5""
""Last-Save-Date"",""2020-08-27T07:11:26Z""
""pdf:docinfo:creator_tool"",""TeX""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2020-08-27T07:11:26Z""
""meta:save-date"",""2020-08-27T07:11:26Z""
""pdf:encrypted"",""false""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.20 (TeX Live 2019) kpathsea version 6.3.1""
""modified"",""2020-08-27T07:11:26Z""
""Content-Length"",""950760""
""pdf:hasMarkedContent"",""false""
""Content-Type"",""application/pdf""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.20 (TeX Live 2019) kpathsea version 6.3.1""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""trapped"",""False""
""meta:creation-date"",""2020-08-13T08:01:29Z""
""created"",""2020-08-13T08:01:29Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""14""
""Creation-Date"",""2020-08-13T08:01:29Z""
""resourceName"",""p3138-yang.pdf""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""4759"",""5353"",""5794"",""5251"",""5710"",""3809"",""5314"",""4932"",""4903"",""5571"",""4617"",""4905"",""4611"",""1126""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""producer"",""pdfTeX-1.40.20; modified using iTextŽ 5.5.6 Š2000-2015 iText Group NV (AGPL-version)""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""pdfTeX-1.40.20; modified using iTextŽ 5.5.6 Š2000-2015 iText Group NV (AGPL-version)""
""pdf:docinfo:created"",""2020-08-13T08:01:29Z""
";https://scholar.google.com/scholar?start=320&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095290-1226;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;A Quality of Service Compliance System Empowered by Smart Contracts and Oracles;JP de Brito Gonçalves, RL Gomes… ; … on Blockchain  …, 2020  ieeexplore.ieee.org;;"Service Level Agreements (SLAs) are used in contracts between two parts, which can be, as 
an example, between service providers or between customers and service providers. SLA 
clauses represent key aspects in the relationship between them. In order to enforce service …";Autres articles;;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/9284404/9284406/09284773.pdf?casa_token=as7yQ8oXQQsAAAAA:nRemKuWSd0G2gGybrinknBsZuSjUJHrqVcJF5wZdWx9OdgYFqd8MfSx-MTn9C3-dQ1gQBF-U3vo;;"""og:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""twitter:title"",""A Quality of Service Compliance System Empowered by Smart Contracts and Oracles""
""twitter:card"",""summary""
""Description"",""Service Level Agreements (SLAs) are used in contracts between two parts, which can be, as an example, between service providers or between customers and service""
""og:title"",""A Quality of Service Compliance System Empowered by Smart Contracts and Oracles""
""resourceName"",""09284773.pdf""
""language"",""en""
""title"",""A Quality of Service Compliance System Empowered by Smart Contracts and Oracles | IEEE Conference Publication | IEEE Xplore""
""og:description"",""Service Level Agreements (SLAs) are used in contracts between two parts, which can be, as an example, between service providers or between customers and service providers. SLA clauses represent key aspects in the relationship between them. In order to enforce service reliability and SLA compliance, a continuous monitoring of Quality of Service metrics is required. Since policy breach is usually subject to expensive penalties, using external entities acting as trustful references is a common practice in order to avoid frequent legal disputes, external entities are usually required to verify it. However, coordination between different actors to agree in one transaction is difficult, because it can open up possibilities for multiple fraud attempts. We argue that this can be done more efficiently using Smart Contracts, programs that are executed in a blockchain. Such data is stored in a distributed structure without the need of an external entity to ensure data integrity and reliability. Smart contracts can also makes easy the charging or possibly compensating SLA violations. In this paper we propose a solution empowered by smart contracts in order to simplify, and to automate the process of SLA validation, i.e, verify if the contract is being respected. We perform some experiments and evaluate a proof of concept using data from a real network infrastructure in Brazil.""
""twitter:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-UA-Compatible"",""IE=Edge""
""viewport"",""width=device-width, initial-scale=1.0""
""dc:title"",""A Quality of Service Compliance System Empowered by Smart Contracts and Oracles | IEEE Conference Publication | IEEE Xplore""
""twitter:description"",""Service Level Agreements (SLAs) are used in contracts between two parts, which can be, as an example, between service providers or between customers and service providers. SLA clauses represent key aspects in the relationship between them. In order to enforce service reliability and SLA compliance, a continuous monitoring of Quality of Service metrics is required. Since policy breach is usually subject to expensive penalties, using external entities acting as trustful references is a common practice in order to avoid frequent legal disputes, external entities are usually required to verify it. However, coordination between different actors to agree in one transaction is difficult, because it can open up possibilities for multiple fraud attempts. We argue that this can be done more efficiently using Smart Contracts, programs that are executed in a blockchain. Such data is stored in a distributed structure without the need of an external entity to ensure data integrity and reliability. Smart contracts can also makes easy the charging or possibly compensating SLA violations. In this paper we propose a solution empowered by smart contracts in order to simplify, and to automate the process of SLA validation, i.e, verify if the contract is being respected. We perform some experiments and evaluate a proof of concept using data from a real network infrastructure in Brazil.""
""Content-Encoding"",""UTF-8""
""Content-Type-Hint"",""text/html; charset=utf-8""
""Content-Length"",""42333""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=30&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095313-1329;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;[HTML][HTML] Blockchain-based two-party fair contract signing scheme;L Zhang, H Zhang, J Yu, H Xian ; Information Sciences, 2020  Elsevier;;"… Share. Export. Advanced. Elsevier. Information Sciences. Volume 535, October 2020,

Pages 142-155. Information Sciences. Blockchain-based two-party fair contract signing

scheme … 2.1. Blockchain technology and Ethereum smart contract …";Cité 3 fois;Les 2 versions;[HTML] sciencedirect.com;https://www.sciencedirect.com/science/article/pii/S0020025520304631?casa_token=gK6YZ5uN0j0AAAAA:xfd23ako02JPFP5M7RELglGlDhckSkyT65Dwmj5XaJDvuZlv_Bwv3WZigrrdZ19j5yVsIQkg;;;https://scholar.google.com/scholar?start=130&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095316-1334;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;On the Security of NTS-KEM in the Quantum Random Oracle Model;V Maram ; CodeBased Cryptography Workshop, 2020  Springer;;"… (Crypto 2018) and Saito et al … Then for any unbounded adversary \(\mathcal {C}\) that issues at

most \(q\) quantum queries to its oracle, we have Open image in … 3 Let oracles \(\mathcal {O}_1(.),

\mathcal {O}_2(.),\ input parameter \(inp\) and \(x\) be sampled from a joint distribution …";Cité 2 fois;Les 3 versions;[PDF] ethz.ch;https://www.research-collection.ethz.ch/bitstream/handle/20.500.11850/424557/1/nts-kem_qrom.pdf;;"""date"",""2020-05-23T13:15:21Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""9"",""10"",""9"",""20"",""11"",""5"",""17"",""21"",""11"",""14"",""31"",""38"",""31"",""12"",""18"",""5"",""0"",""0""
""pdf:PDFVersion"",""1.4""
""xmp:CreatorTool"",""TeX""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dcterms:created"",""2020-05-23T13:15:21Z""
""language"",""en""
""Last-Modified"",""2020-05-23T13:15:21Z""
""dcterms:modified"",""2020-05-23T13:15:21Z""
""dc:format"",""application/pdf; version=1.4""
""Last-Save-Date"",""2020-05-23T13:15:21Z""
""pdf:docinfo:creator_tool"",""TeX""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2020-05-23T13:15:21Z""
""meta:save-date"",""2020-05-23T13:15:21Z""
""pdf:encrypted"",""false""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is MiKTeX-pdfTeX 2.9.7029 (1.40.20)""
""modified"",""2020-05-23T13:15:21Z""
""Content-Length"",""1059620""
""pdf:hasMarkedContent"",""false""
""Content-Type"",""application/pdf""
""PTEX.Fullbanner"",""This is MiKTeX-pdfTeX 2.9.7029 (1.40.20)""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""trapped"",""False""
""meta:creation-date"",""2020-05-23T13:15:21Z""
""created"",""2020-05-23T13:15:21Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""20""
""Creation-Date"",""2020-05-23T13:15:21Z""
""resourceName"",""nts-kem_qrom.pdf""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""527"",""2033"",""2304"",""2547"",""2379"",""2222"",""1919"",""1881"",""2246"",""2351"",""2392"",""1837"",""915"",""2241"",""2296"",""2452"",""1556"",""2028"",""2905"",""2681""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""producer"",""MiKTeX pdfTeX-1.40.20""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""MiKTeX pdfTeX-1.40.20""
""pdf:docinfo:created"",""2020-05-23T13:15:21Z""
";https://scholar.google.com/scholar?start=140&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095409-1734;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Signatures from sequential-OR proofs;M Fischlin, P Harasser, C Janson ; … on the Theory and Applications of …, 2020  Springer;;"… to build OR-proofs is based on an approach introduced by Cramer, Damgĺrd, and Schoenmakers

(CRYPTO'94), where the … We stress, however, that protocols designed in the global random oracle

model are not necessarily secure for non-programmable random oracles …";Cité 8 fois;Les 2 versions;[PDF] iacr.org;https://eprint.iacr.org/2020/271.pdf;;"""date"",""2020-02-29T11:06:46Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2020-02-29T11:06:46Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016) kpathsea version 6.2.2""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2020-02-29T11:06:46Z""
""created"",""2020-02-29T11:06:46Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-02-29T11:06:46Z""
""resourceName"",""271.pdf""
""Author"",""""
""producer"",""pdfTeX-1.40.17""
""pdf:docinfo:producer"",""pdfTeX-1.40.17""
""pdf:unmappedUnicodeCharsPerPage"",""1"",""0"",""0"",""1"",""0"",""0"",""0"",""14"",""19"",""26"",""56"",""46"",""29"",""6"",""11"",""3"",""7"",""4"",""4"",""2"",""2"",""5"",""6"",""1"",""2"",""0"",""16"",""6"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""2"",""5"",""5"",""64"",""74"",""30"",""88"",""9"",""34"",""69"",""6"",""4"",""40"",""32"",""4"",""4"",""14"",""2"",""8"",""8"",""1""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2020-02-29T11:06:46Z""
""Last-Modified"",""2020-02-29T11:06:46Z""
""dcterms:modified"",""2020-02-29T11:06:46Z""
""title"",""""
""Last-Save-Date"",""2020-02-29T11:06:46Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2020-02-29T11:06:46Z""
""meta:save-date"",""2020-02-29T11:06:46Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016) kpathsea version 6.2.2""
""Content-Length"",""806138""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""56""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""1562"",""1748"",""3237"",""2988"",""2736"",""3586"",""3401"",""3191"",""2899"",""2508"",""2352"",""2070"",""2308"",""2308"",""2186"",""2898"",""2562"",""2123"",""2923"",""3745"",""3224"",""3349"",""3249"",""2689"",""3421"",""3779"",""3100"",""2878"",""2992"",""2889"",""2958"",""2938"",""2834"",""2706"",""1599"",""2983"",""679"",""2180"",""1802"",""2700"",""2401"",""1712"",""2872"",""1285"",""2067"",""2355"",""1217"",""1781"",""1547"",""2010"",""2636"",""2968"",""2486"",""2498"",""3059"",""821""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-02-29T11:06:46Z""
";https://scholar.google.com/scholar?start=540&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095390-1657;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Niektóre cywilnoprawne aspekty technologii blockchain-przyk?ad kryptowalut i smart kontraktów;A Kulasza ;2020 ruj.uj.edu.pl;;"… Keywords: cryptosystem, blockchain, chain of blocks, consensus, proof-of-work, asymmetric

cryptography, hash, DLT, distributed ledgers, virtual currency, cryptocurrency, Bitcoin, Ethereum,

subjective right, smart contract, declaration of intent, oracle, lex cryptographia …";;;null;;;;https://scholar.google.com/scholar?start=460&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095327-1386;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Blockchain Reference System Architecture Description for the ISA95 Compliant Traditional and Smart Manufacturing Systems;E Yalcinkaya, A Maffei, M Onori ; Sensors, 2020  mdpi.com;;"… Use-case 4, ledger-to-external data sources (Oracles) communication: Smart-contract

and blockchain applications may sometimes need information not available on-chain.

External data sources, Oracles, become handy to fetch …";Cité 1 fois;Les 9 versions;[PDF] mdpi.com;https://www.mdpi.com/1424-8220/20/22/6456/pdf;;;https://scholar.google.com/scholar?start=190&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095376-1596;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;SoK: A classification framework for stablecoin designs;A Moin, K Sekniqi, EG Sirer ; … on Financial Cryptography and Data Security, 2020  Springer;;"… Alternately, Schelling point mechanisms [16], aka crowd oracles, can also be used to set the price …

Others require an oracle but not for the stablecoin or any other cryptoassets … of 2017; NASDAQ

lists several blockchain companies and is exploring uses for blockchain technology …";Cité 11 fois;Les 4 versions;[PDF] ifca.ai;http://fc20.ifca.ai/preproceedings/119.pdf;;"""date"",""2020-01-16T23:09:36Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.5""
""xmp:CreatorTool"",""TeX""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dcterms:created"",""2020-01-16T23:09:36Z""
""language"",""en""
""Last-Modified"",""2020-01-16T23:09:36Z""
""dcterms:modified"",""2020-01-16T23:09:36Z""
""dc:format"",""application/pdf; version=1.5""
""Last-Save-Date"",""2020-01-16T23:09:36Z""
""pdf:docinfo:creator_tool"",""TeX""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2020-01-16T23:09:36Z""
""meta:save-date"",""2020-01-16T23:09:36Z""
""pdf:encrypted"",""false""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016/Debian) kpathsea version 6.2.2""
""modified"",""2020-01-16T23:09:36Z""
""Content-Length"",""472409""
""pdf:hasMarkedContent"",""false""
""Content-Type"",""application/pdf""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016/Debian) kpathsea version 6.2.2""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""trapped"",""False""
""meta:creation-date"",""2020-01-16T23:09:36Z""
""created"",""2020-01-16T23:09:36Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""23""
""Creation-Date"",""2020-01-16T23:09:36Z""
""resourceName"",""119.pdf""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""2051"",""1614"",""3173"",""3074"",""1910"",""2834"",""3077"",""3176"",""3182"",""3163"",""1977"",""3123"",""3072"",""3134"",""2754"",""2679"",""2876"",""2474"",""449"",""912"",""1509"",""1620"",""1176""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""producer"",""pdfTeX-1.40.17""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""pdfTeX-1.40.17""
""pdf:docinfo:created"",""2020-01-16T23:09:36Z""
";https://scholar.google.com/scholar?start=400&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095309-1306;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;The quality traceability system for prefabricated buildings using blockchain: An integrated framework;Z Zhang, Z Yuan, G Ni, H Lin, Y Lu ; Frontiers of Engineering Management, 2020  Springer;;"… The quality traceability system for prefabricated buildings using blockchain: An integrated

framework … Blockchain technology provides an effective solution to change the centralized storage

mode of traditional traceability system and its related disadvan- tages …";Cité 8 fois;Les 3 versions;[PDF] researchgate.net;https://www.researchgate.net/profile/Han_Lin11/publication/343306607_The_quality_traceability_system_for_prefabricated_buildings_using_blockchain_An_integrated_framework/links/5f2c0c95458515b7290730aa/The-quality-traceability-system-for-prefabricated-buildings-using-blockchain-An-integrated-framework.pdf;;;https://scholar.google.com/scholar?start=110&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095320-1356;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Blockchain technology in international commodity trading;P Lakkakula, D Bullock, W Wilson ;2020 ageconsearch.umn.edu;;"… at present, most parties would not agree to a payment settlement in cryptocurrency due to high …

and logistics companies, financial institutions such as the buyer's and seller's banks, oracles

(more on … 4 A blockchain oracle is a trusted third party that provides off-chain data to the …";Cité 4 fois;Les 9 versions;[PDF] umn.edu;https://ageconsearch.umn.edu/record/303613/files/2020_Journal_of_Private_Enterprise_Vol_35_No_2_Summer_parte2.pdf;;"""date"",""2020-05-13T18:12:59Z""
""pdf:PDFVersion"",""1.7""
""pdf:docinfo:title"",""2020 Journal of Private Enterprise Vol 35 No 2 Summer for printers""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""language"",""en""
""dc:format"",""application/pdf; version=1.7""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""2020 Journal of Private Enterprise Vol 35 No 2 Summer for printers""
""xmp:CreateDate"",""2020-05-08T09:55:04Z""
""modified"",""2020-05-13T18:12:59Z""
""pdf:hasMarkedContent"",""false""
""xmp:ModifyDate"",""2020-05-13T13:12:59Z""
""pdf:docinfo:creator"",""APEE""
""meta:author"",""APEE""
""meta:creation-date"",""2020-05-08T15:55:04Z""
""created"",""2020-05-08T15:55:04Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-05-08T15:55:04Z""
""resourceName"",""2020_Journal_of_Private_Enterprise_Vol_35_No_2_Summer_parte2.pdf""
""Author"",""APEE""
""producer"",""Microsoft: Print To PDF""
""pdf:docinfo:producer"",""Microsoft: Print To PDF""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""7"",""0"",""0"",""0"",""0"",""0"",""0""
""access_permission:modify_annotations"",""true""
""dc:creator"",""APEE""
""dcterms:created"",""2020-05-08T15:55:04Z""
""Last-Modified"",""2020-05-13T18:12:59Z""
""dcterms:modified"",""2020-05-13T18:12:59Z""
""title"",""2020 Journal of Private Enterprise Vol 35 No 2 Summer for printers""
""xmpMM:DocumentID"",""uuid:bb030288-416e-4bab-b8e3-87a3be91ee56""
""Last-Save-Date"",""2020-05-13T18:12:59Z""
""pdf:docinfo:modified"",""2020-05-13T18:12:59Z""
""meta:save-date"",""2020-05-13T18:12:59Z""
""Content-Length"",""1676758""
""Content-Type"",""application/pdf""
""xmp:MetadataDate"",""2020-05-13T13:12:59Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""APEE""
""pdf:producer"",""Microsoft: Print To PDF""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""24""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""1908"",""2639"",""2611"",""2011"",""1116"",""2383"",""1394"",""2600"",""2641"",""2711"",""1875"",""1208"",""2693"",""2676"",""2530"",""1483"",""1732"",""1323"",""1748"",""2310"",""2635"",""2598"",""2663"",""2073""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-05-08T15:55:04Z""
";https://scholar.google.com/scholar?start=160&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095392-1664;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Blockchain and geographical indications: a natural fit?;SM Aronzon ; Journal of Intellectual Property Law & Practice, 2020  academic.oup.com;;"… and 'permissioned' blockchains to address several challenges that blockchain applications face

outside of cryptocurrency … limit the opportunity for human error or manipulation of inputs to the

blockchain … comes from Proof of Trust, which focuses on the 'oracles' which translate …";Autres articles;;[PDF] digilabs.global;https://www.digilabs.global/s/Blockchain-and-Geographical-Indications.pdf;;"""date"",""2019-11-03T21:48:11Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.3""
""pdf:docinfo:title"",""FINAL 9.2.19""
""xmp:CreatorTool"",""Word""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dcterms:created"",""2019-11-03T21:48:11Z""
""language"",""en""
""Last-Modified"",""2019-11-03T21:48:11Z""
""dcterms:modified"",""2019-11-03T21:48:11Z""
""dc:format"",""application/pdf; version=1.3""
""title"",""FINAL 9.2.19""
""Last-Save-Date"",""2019-11-03T21:48:11Z""
""pdf:docinfo:creator_tool"",""Word""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2019-11-03T21:48:11Z""
""meta:save-date"",""2019-11-03T21:48:11Z""
""pdf:encrypted"",""false""
""dc:title"",""FINAL 9.2.19""
""modified"",""2019-11-03T21:48:11Z""
""Content-Length"",""615298""
""pdf:hasMarkedContent"",""false""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""meta:creation-date"",""2019-11-03T21:48:11Z""
""created"",""2019-11-03T21:48:11Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""52""
""Creation-Date"",""2019-11-03T21:48:11Z""
""resourceName"",""Blockchain-and-Geographical-Indications.pdf""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""325"",""1888"",""3761"",""514"",""2936"",""2973"",""2642"",""2297"",""2654"",""2636"",""2600"",""2914"",""3204"",""2835"",""2861"",""2525"",""3408"",""2554"",""2498"",""3020"",""2579"",""2810"",""2448"",""3138"",""1956"",""2655"",""2780"",""2564"",""2373"",""2540"",""2793"",""3335"",""2815"",""3274"",""2857"",""3144"",""2740"",""2243"",""2456"",""2301"",""2802"",""2620"",""957"",""521"",""2516"",""2249"",""2230"",""2291"",""2266"",""2342"",""2396"",""1499""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""producer"",""Mac OS X 10.13.6 Quartz PDFContext""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""Mac OS X 10.13.6 Quartz PDFContext""
""pdf:docinfo:created"",""2019-11-03T21:48:11Z""
";https://scholar.google.com/scholar?start=470&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095299-1267;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Gamified service exchange platform on blockchain for IoT business agility;S Gheitanchi ; … Conference on Blockchain and Cryptocurrency  …, 2020  ieeexplore.ieee.org;;"… Oracles of the entities provide connectivity to blockchain and invoke smart contacts to exchange

services … Page 2. Figure 2: Service exchange platform overview. The business layer provides

the oracle with pricing, reward, legal requirements and duration of service …";Cité 2 fois;;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/9165689/9169389/09169420.pdf?casa_token=X1Yz7_js7M4AAAAA:bXzOocWQnBm6JoxR-I0o5UHaGlmA6095kwaC44e_U53DSjbGybjLlH8dlaZCroWVSUVH5E49Bvw;;"""og:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""twitter:title"",""Gamified service exchange platform on blockchain for IoT business agility""
""twitter:card"",""summary""
""Description"",""In order to enable IoT solution providers to quickly adapt to market dynamics and improve business agility, in this paper we introduce the concept of a decentra""
""og:title"",""Gamified service exchange platform on blockchain for IoT business agility""
""resourceName"",""09169420.pdf""
""language"",""en""
""title"",""Gamified service exchange platform on blockchain for IoT business agility | IEEE Conference Publication | IEEE Xplore""
""og:description"",""In order to enable IoT solution providers to quickly adapt to market dynamics and improve business agility, in this paper we introduce the concept of a decentralized gamified service exchange platform where the solution providers can dynamically offer and request services in an autonomous peer-to-peer fashion. Cost and decision to exchange services are set during operation time based on gamification policies according to business goals. The proposed concept is based on blockchain technology to provide a tokenized economy where the IoT solution providers can implement gamification techniques using smart contracts to maximize profits during service offering and requesting.""
""twitter:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-UA-Compatible"",""IE=Edge""
""viewport"",""width=device-width, initial-scale=1.0""
""dc:title"",""Gamified service exchange platform on blockchain for IoT business agility | IEEE Conference Publication | IEEE Xplore""
""twitter:description"",""In order to enable IoT solution providers to quickly adapt to market dynamics and improve business agility, in this paper we introduce the concept of a decentralized gamified service exchange platform where the solution providers can dynamically offer and request services in an autonomous peer-to-peer fashion. Cost and decision to exchange services are set during operation time based on gamification policies according to business goals. The proposed concept is based on blockchain technology to provide a tokenized economy where the IoT solution providers can implement gamification techniques using smart contracts to maximize profits during service offering and requesting.""
""Content-Encoding"",""UTF-8""
""Content-Type-Hint"",""text/html; charset=utf-8""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=70&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095349-1483;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;[PDF][PDF] BLOCKCHAIN: AN EMPIRICAL REVIEW OF FORTUNE 500 WEBSITE POSTINGS AND USAGE;CJ Case, DL King, JA Case ; JOURNAL OF BUSINESS AND BEHAVIORAL …  asbbs.org;;"… The New Yorker, October 10, https://www. newyorker. com/magazine/2011/10/10/the-crypto-

currency Fortune (2019). Fortune 500 2019. fortune … Results for “blockchain.” oracle. com,

https://www. oracle. com/index. html Pawczuk, LL, Massey, R., and Holdowsky, J.(2019) …";Autres articles;Version HTML;[PDF] asbbs.org;http://asbbs.org/files/2020/JBBS_Vol_32.2_Fall_2020.pdf#page=42;;;https://scholar.google.com/scholar?start=280&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095365-1546;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Blockchain 2020;M Imamura, S Chan, Y Cheng ; computer.org;;"… INDIA), Sai Koti Reddy Danda (IBM Research, India), Ken Kumar (Oracle IDC, India … Multi-factor

Authentication for Users of Non-Internet Based Applications of Blockchain-Based Platforms 525 …

A Quality of Service Compliance System Empowered by Smart Contracts and Oracles …";;null;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/9284404/9284406/09284808.pdf;;"""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""dc:title"",""IEEE Xplore Full-Text PDF:""
""Content-Encoding"",""UTF-8""
""resourceName"",""09284808.pdf""
""language"",""es""
""Content-Length"",""2565""
""title"",""IEEE Xplore Full-Text PDF:""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=350&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095341-1449;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Tunnelling Trust into the Blockchain: a Merkle Based Proof System for Structured Documents;F Bruschi, V Rana, A Pagani, D Sciuto ; IEEE Access, 2020  ieeexplore.ieee.org;;"Skip to Main Content. Tunnelling Trust into the Blockchain: a Merkle Based Proof System for

Structured Documents. Abstract: The idea of Smart contracts foresees the possibility of automating

contractual clauses using hardware and software tools and devices …";Autres articles;;null;;;;https://scholar.google.com/scholar?start=250&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095353-1499;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;On the foundations of proof-of-work based blockchain protocols;G Panagiotakos ;2020 era.ed.ac.uk;;"… cess to a hash function modeled in the Random Oracle Model (ROM) [BR93]. The analysis

includes the formulation of fundamental properties of the underly- ing blockchain data

structure, which parties maintain and try to extend by generating …";Autres articles;Version HTML;[PDF] ed.ac.uk;https://era.ed.ac.uk/bitstream/handle/1842/37474/Panagiotakos2020.pdf?sequence=1&isAllowed=y;;"""date"",""2021-01-05T12:16:08Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""4"",""0"",""4"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""3"",""0"",""0"",""2"",""0"",""6"",""2"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""14"",""0"",""23"",""5"",""31"",""17"",""13"",""5"",""5"",""0"",""1"",""2"",""0"",""0"",""3"",""36"",""23"",""13"",""13"",""24"",""41"",""49"",""18"",""18"",""77"",""46"",""23"",""4"",""24"",""1"",""2"",""8"",""6"",""16"",""2"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""2"",""5"",""8"",""2"",""3"",""0"",""2"",""13"",""11"",""11"",""4"",""5"",""28"",""8"",""14"",""11"",""8"",""12"",""2"",""22"",""23"",""4"",""4"",""7"",""5"",""1"",""6"",""16"",""0"",""6"",""0"",""2"",""16"",""49"",""24"",""4"",""4"",""15"",""9"",""0"",""0"",""1"",""0"",""0"",""0"",""0"",""1"",""3"",""8"",""3"",""20"",""17"",""34"",""0"",""0"",""1"",""25"",""2"",""2"",""2"",""4"",""27"",""36"",""10"",""8"",""13"",""13"",""59"",""10"",""16"",""6"",""9"",""6"",""0"",""14"",""4"",""22"",""8"",""0"",""0"",""0"",""0"",""0"",""5"",""2"",""14"",""24"",""1"",""2"",""9"",""7"",""22"",""8"",""18"",""6"",""29"",""1"",""2"",""0"",""0"",""0"",""0"",""1"",""4"",""5"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.5""
""xmp:CreatorTool"",""PDFsam Basic v4.0.5""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""language"",""en""
""Last-Modified"",""2021-01-05T12:16:08Z""
""dcterms:modified"",""2021-01-05T12:16:08Z""
""dc:format"",""application/pdf; version=1.5""
""Last-Save-Date"",""2021-01-05T12:16:08Z""
""pdf:docinfo:creator_tool"",""PDFsam Basic v4.0.5""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2021-01-05T12:16:08Z""
""meta:save-date"",""2021-01-05T12:16:08Z""
""pdf:encrypted"",""false""
""modified"",""2021-01-05T12:16:08Z""
""Content-Length"",""1329032""
""pdf:hasMarkedContent"",""false""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""203""
""resourceName"",""Panagiotakos2020.pdf""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""875"",""202"",""1950"",""31"",""998"",""978"",""1556"",""99"",""1429"",""658"",""644"",""1581"",""1829"",""2187"",""2334"",""2247"",""2321"",""2204"",""1371"",""1393"",""2032"",""2381"",""2327"",""2194"",""1960"",""1951"",""2295"",""700"",""1526"",""2510"",""1975"",""2412"",""2527"",""2096"",""2352"",""1995"",""805"",""1279"",""1523"",""1352"",""963"",""1442"",""862"",""1639"",""1726"",""1690"",""1696"",""1400"",""1753"",""2187"",""2123"",""1894"",""2033"",""1684"",""1760"",""2081"",""1801"",""1194"",""1105"",""2341"",""1905"",""2092"",""1959"",""1658"",""2305"",""1870"",""2186"",""2110"",""1908"",""1799"",""2414"",""978"",""1661"",""2431"",""2471"",""2394"",""2332"",""1946"",""2424"",""2354"",""2207"",""1952"",""1905"",""2365"",""1868"",""1797"",""1789"",""2147"",""2024"",""1824"",""1759"",""1595"",""1565"",""2099"",""1712"",""1915"",""1893"",""1665"",""1778"",""2031"",""2259"",""2079"",""1357"",""2172"",""1880"",""1835"",""1961"",""1852"",""2288"",""1593"",""2030"",""2159"",""2212"",""1057"",""2183"",""2226"",""1637"",""1754"",""1727"",""1910"",""892"",""1402"",""2470"",""2401"",""2400"",""2376"",""2065"",""1982"",""2150"",""1814"",""2259"",""2031"",""2180"",""2412"",""1848"",""2162"",""2176"",""2207"",""1791"",""1811"",""2212"",""2286"",""2246"",""1559"",""1733"",""2252"",""1613"",""1833"",""2248"",""1935"",""1999"",""2109"",""2163"",""2161"",""1782"",""1915"",""2199"",""2288"",""2223"",""1528"",""1460"",""2427"",""2335"",""2223"",""2000"",""1482"",""1628"",""1259"",""1589"",""1685"",""1690"",""1243"",""2114"",""2123"",""2011"",""2233"",""1905"",""2327"",""2162"",""2143"",""796"",""1637"",""1031"",""728"",""655"",""1126"",""1701"",""1301"",""1722"",""1780"",""1717"",""1634"",""1671"",""1576"",""1549"",""1770"",""1650"",""1624"",""1609"",""1605"",""1606"",""1677"",""774""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""producer"",""SAMBox 1.1.55 (www.sejda.org)""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""SAMBox 1.1.55 (www.sejda.org)""
";https://scholar.google.com/scholar?start=300&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095360-1525;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;[PDF][PDF] Authentication or Multiple Authorities proceeding verifies signature to the Assertion of Blockchain in Medical Records;MA Achilles, A Hemlathadhevi ; arivjournal.com;;"… oracle model. Page 2. ARIV - International Journal of Technology Vol 1 Issue 2 2020

Page | 66 Index Terms: Verifies Signature (VS), Blockchain, electronic, Medical

records, multiple authorities, preserve privacy. Introduction …";Autres articles;Version HTML;[PDF] arivjournal.com;https://arivjournal.com/technology/wp-content/uploads/2020/08/AIJT12042020.pdf;;"""date"",""2020-08-17T15:15:11Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.7""
""xmp:CreatorTool"",""MicrosoftÂŽ Word for Office 365""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dc:creator"",""Dr.MUSU""
""language"",""en""
""dcterms:created"",""2020-08-17T15:15:11Z""
""Last-Modified"",""2020-08-17T15:15:11Z""
""dcterms:modified"",""2020-08-17T15:15:11Z""
""dc:format"",""application/pdf; version=1.7""
""xmpMM:DocumentID"",""uuid:DDCC85A9-CE73-4291-B067-282E5B50DB3F""
""Last-Save-Date"",""2020-08-17T15:15:11Z""
""pdf:docinfo:creator_tool"",""MicrosoftÂŽ Word for Office 365""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2020-08-17T15:15:11Z""
""meta:save-date"",""2020-08-17T15:15:11Z""
""pdf:encrypted"",""false""
""xmp:CreateDate"",""2020-08-17T19:15:11Z""
""modified"",""2020-08-17T15:15:11Z""
""Content-Length"",""539344""
""pdf:hasMarkedContent"",""true""
""Content-Type"",""application/pdf""
""xmp:ModifyDate"",""2020-08-17T19:15:11Z""
""pdf:docinfo:creator"",""Dr.MUSU""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Dr.MUSU""
""dc:language"",""en-US""
""meta:author"",""Dr.MUSU""
""pdf:producer"",""MicrosoftÂŽ Word for Office 365""
""meta:creation-date"",""2020-08-17T15:15:11Z""
""created"",""2020-08-17T15:15:11Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""10""
""Creation-Date"",""2020-08-17T15:15:11Z""
""resourceName"",""AIJT12042020.pdf""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""2061"",""2623"",""1032"",""2270"",""1242"",""2374"",""2279"",""1316"",""771"",""2195""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""Author"",""Dr.MUSU""
""producer"",""MicrosoftÂŽ Word for Office 365""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""MicrosoftÂŽ Word for Office 365""
""pdf:docinfo:created"",""2020-08-17T15:15:11Z""
";https://scholar.google.com/scholar?start=330&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095316-1341;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;A Pattern Adherence Analysis to a Blockchain Web Application;AW Abreu, EF Coutinho ; 2020 IEEE International Conference …, 2020  ieeexplore.ieee.org;;"… Fig. 6. Cryptocurrency system scheme with smart contracts [20] … A. Pattern 1 - oracle From a

software architecture perspective, the Educ-Dapp application adheres to the oracle pattern as

it uses blockchain as a distributed database integrated with an external web application …";Autres articles;;null;;;;https://scholar.google.com/scholar?start=140&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095371-1576;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;WorkerRep: Immutable Reputation System For Crowdsourcing Platform Based on Blockchain;GK Bhatia, S Gupta, A Dubey… ; arXiv preprint arXiv …, 2020  arxiv.org;;"Page 1. WorkerRep: Immutable Reputation System For Crowdsourcing Platform Based on

Blockchain Gurpriya Kaur Bhatia Indraprastha Institute of Information Technology, Delhi

gurpriya16021@iiitd.ac.in … KEYWORDS Crowdsourcing, Blockchain, Reputation …";Autres articles;;[PDF] arxiv.org;https://arxiv.org/pdf/2006.14782;;"""date"",""2020-06-29T00:42:17Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""WorkerRep: Immutable Reputation System For Crowdsourcing Platform Based on Blockchain""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""WorkerRep: Immutable Reputation System For Crowdsourcing Platform Based on Blockchain""
""modified"",""2020-06-29T00:42:17Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""Gurpriya Kaur Bhatia, Shubham Gupta, Alpana Dubey, and Ponnurangam Kumaraguru""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016) kpathsea version 6.2.2""
""meta:author"",""Gurpriya Kaur Bhatia, Shubham Gupta, Alpana Dubey, and Ponnurangam Kumaraguru""
""trapped"",""False""
""meta:creation-date"",""2020-06-29T00:42:17Z""
""created"",""2020-06-29T00:42:17Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-06-29T00:42:17Z""
""resourceName"",""2006.14782""
""Author"",""Gurpriya Kaur Bhatia, Shubham Gupta, Alpana Dubey, and Ponnurangam Kumaraguru""
""producer"",""pdfTeX-1.40.17""
""pdf:docinfo:producer"",""pdfTeX-1.40.17""
""pdf:unmappedUnicodeCharsPerPage"",""24"",""29"",""23"",""37"",""33"",""35"",""26"",""52"",""11""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""Gurpriya Kaur Bhatia, Shubham Gupta, Alpana Dubey, and Ponnurangam Kumaraguru""
""dcterms:created"",""2020-06-29T00:42:17Z""
""Last-Modified"",""2020-06-29T00:42:17Z""
""dcterms:modified"",""2020-06-29T00:42:17Z""
""title"",""WorkerRep: Immutable Reputation System For Crowdsourcing Platform Based on Blockchain""
""Last-Save-Date"",""2020-06-29T00:42:17Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2020-06-29T00:42:17Z""
""meta:save-date"",""2020-06-29T00:42:17Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016) kpathsea version 6.2.2""
""Content-Length"",""606076""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Gurpriya Kaur Bhatia, Shubham Gupta, Alpana Dubey, and Ponnurangam Kumaraguru""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""9""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""4744"",""4610"",""4590"",""5539"",""5650"",""4320"",""4645"",""6818"",""4236""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-06-29T00:42:17Z""
";https://scholar.google.com/scholar?start=380&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095325-1378;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Exploiting Corporate Governance to Evaluate Blockchain Applications: A Comprehensive Framework;G Caldarelli ; International Journal of Economics & Business …, 2020  ideas.repec.org;;"… company. The present analysis supports the view that although the blockchain

revolution aims to reduce the intermediaries, the blockchain oracles' limits will still

grant a predominant role to human interaction. Practical Implications …";Cité 1 fois;;[PDF] researchgate.net;https://www.researchgate.net/profile/Giulio-Caldarelli-2/publication/346496142_Exploiting_Corporate_Governance_to_Evaluate_Blockchain_Applications_A_Comprehensive_Framework/links/5fdcc757299bf1408822752c/Exploiting-Corporate-Governance-to-Evaluate-Blockchain-Applications-A-Comprehensive-Framework.pdf;;;https://scholar.google.com/scholar?start=180&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095390-1655;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;[PDF][PDF] Reimagining Higher Education in India leveraging Blockchain Technology: A study to categorize challenges and opportunities;S Gaidhani, A Saxena, OP Nautiyal, G Gaidhani ; researchgate.net;;"… conventional currencies ruling the world well known as Bitcoin, invented by a person with a

fictitious name Satoshi Nakamoto who envisioned a peer to peer digital currency system using

a cryptocurrency [3]. This peer to … 8. Oracle, ""5 Ways Blockchain Is Revolutionizing …";;;[PDF] researchgate.net;https://www.researchgate.net/profile/Prof_Abhay_Saxena/publication/348430667_Reimagining_Higher_Education_in_India_leveraging_Blockchain_Technology_A_study_to_categorize_challenges_and_opportunities/links/5ffea97c45851553a03db932/Reimagining-Higher-Education-in-India-leveraging-Blockchain-Technology-A-study-to-categorize-challenges-and-opportunities.pdf;;;https://scholar.google.com/scholar?start=460&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095404-1718;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Blockchain-Inspired Architectures for Attribute-Based Access Control and Zero Knowledge Proof-Based Data Privacy;H Guo ;2020 search.proquest.com;;"… Bitcoin is the first public cryptocurrency which aims to solve the double- spending problem without

the need of a central authority. On September 11, 2019, one Bitcoin worths 9,953.53 United States

Dollar. As shown in Fig. 1.1, a blockchain consists of a series of blocks, and …";Autres articles;;[PDF] udel.edu;https://udspace.udel.edu/bitstream/handle/19716/28800/Guo_udel_0060D_14287.pdf?sequence=1&isAllowed=y;;"""date"",""2020-07-14T00:05:50Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""Blockchain-inspired Architectures for Attribute-based Access Control and Zero Knowledge Proof-based Data Privacy""
""xmp:CreatorTool"",""LaTeX2e, UDThesis class, hyperref package""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""Subject""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX2e, UDThesis class, hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""Blockchain-inspired Architectures for Attribute-based Access Control and Zero Knowledge Proof-based Data Privacy""
""modified"",""2020-07-14T00:05:50Z""
""cp:subject"",""Subject""
""pdf:docinfo:subject"",""Subject""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017) kpathsea version 6.2.3""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2020-07-14T00:05:50Z""
""created"",""2020-07-14T00:05:50Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-07-14T00:05:50Z""
""resourceName"",""Guo_udel_0060D_14287.pdf""
""Author"",""""
""producer"",""pdfTeX-1.40.18""
""pdf:docinfo:producer"",""pdfTeX-1.40.18""
""pdf:unmappedUnicodeCharsPerPage"",""1"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""2"",""0"",""2"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""3"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""1"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""4""
""Keywords"",""Keyord,Keyword,Keyword""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2020-07-14T00:05:50Z""
""Last-Modified"",""2020-07-14T00:05:50Z""
""dcterms:modified"",""2020-07-14T00:05:50Z""
""title"",""Blockchain-inspired Architectures for Attribute-based Access Control and Zero Knowledge Proof-based Data Privacy""
""Last-Save-Date"",""2020-07-14T00:05:50Z""
""pdf:docinfo:keywords"",""Keyord,Keyword,Keyword""
""pdf:docinfo:modified"",""2020-07-14T00:05:50Z""
""meta:save-date"",""2020-07-14T00:05:50Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017) kpathsea version 6.2.3""
""Content-Length"",""3851042""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""Keyord,Keyword,Keyword""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""123""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""292"",""356"",""890"",""1253"",""1141"",""1300"",""1373"",""1372"",""578"",""164"",""1106"",""1237"",""483"",""1703"",""1539"",""1453"",""1455"",""2012"",""1644"",""1692"",""1837"",""1925"",""1927"",""1492"",""1909"",""1921"",""1198"",""1456"",""1319"",""1296"",""1772"",""1325"",""1250"",""1169"",""1730"",""1362"",""756"",""1095"",""451"",""852"",""997"",""754"",""1508"",""1915"",""1771"",""285"",""1427"",""2034"",""1670"",""1061"",""1068"",""1714"",""1236"",""1575"",""1061"",""500"",""521"",""1158"",""1336"",""1902"",""1876"",""222"",""1585"",""1936"",""1675"",""1179"",""683"",""1275"",""1881"",""1878"",""1446"",""1057"",""894"",""1425"",""795"",""720"",""987"",""941"",""1113"",""1347"",""1277"",""1188"",""227"",""1475"",""1950"",""1042"",""826"",""1140"",""737"",""1475"",""2009"",""1967"",""1936"",""1618"",""1242"",""1620"",""1560"",""1435"",""1311"",""1222"",""1469"",""429"",""1224"",""862"",""809"",""996"",""1103"",""1978"",""2081"",""890"",""1579"",""2025"",""196"",""1346"",""2105"",""2144"",""2103"",""2091"",""1968"",""2003"",""1803"",""1697"",""1425""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""Keyord,Keyword,Keyword""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-07-14T00:05:50Z""
";https://scholar.google.com/scholar?start=520&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095295-1247;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Smart Contract Data Feed Framework for Privacy-Preserving Oracle System on Blockchain. Computers 2021, 10, 7;J Park, H Kim, G Kim, J Ryou ;2020 search.proquest.com;;"As blockchain-based applications and research such as cryptocurrency increase, an oracle 
problem to bring external data in the blockchain is emerging. Among the methods to solve 
the oracle problem, a method of configuring oracle based on TLS, an existing internet …";Autres articles;;null;;;;https://scholar.google.com/scholar?start=50&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095386-1641;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Lightweight fog based solution for privacy-preserving in IoT using blockchain;AH Alkhazaali, ATA O?uz ; 2020 International Congress on …, 2020  ieeexplore.ieee.org;;"… Nowadays, blockchain is not only a cryptocurrency … 100, pp. 569–578, nov 2019. [32] P. Kochovski,

S. Gec, V. Stankovski, M. Bajec, and PD Drobintsev, “Trust management in a blockchain based

fog computing platform with trustless smart oracles,” Futur. Gener. Comput …";Cité 1 fois;;null;;;;https://scholar.google.com/scholar?start=440&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095353-1498;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;[PDF][PDF] Amethis Amethis;T Young, A Mashan, C Lang ;2020 gateway.pinata.cloud;;"… Confidentiality is another desirable property for oracles. As USER-SC sends Req

to ORACLE in the clear on the blockchain, Req is public. There are many situations

in which Req is sensitive and its publication could be harmful …";Autres articles;Version HTML;[PDF] pinata.cloud;https://gateway.pinata.cloud/ipfs/QmZQ7UuPEW792JfRzAPygKX8sm2MQAAv5zjt8PfFjYW9TV/files/Amethis.pdf;;"""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""5"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""2"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.5""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""38""
""resourceName"",""Amethis.pdf""
""language"",""en""
""pdf:hasXMP"",""false""
""dc:format"",""application/pdf; version=1.5""
""pdf:charsPerPage"",""1616"",""1027"",""2444"",""2099"",""2525"",""2350"",""2035"",""1939"",""1493"",""2445"",""1968"",""1392"",""2414"",""2166"",""1389"",""2258"",""2437"",""1947"",""2488"",""2469"",""2134"",""2533"",""2434"",""1707"",""1921"",""2410"",""2242"",""1754"",""1975"",""1884"",""517"",""1750"",""2339"",""1095"",""771"",""1711"",""1978"",""2022""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""Content-Length"",""849586""
""access_permission:can_modify"",""true""
""pdf:hasMarkedContent"",""false""
""Content-Type"",""application/pdf""
";https://scholar.google.com/scholar?start=300&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095390-1660;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;The Role of Collaborative Governance in Blockchain-Enabled Supply Chains: A Proposed Framework;D McCurdy ;2020 scholarworks.gsu.edu;;"… Spring 5-4-2020 The Role of Collaborative Governance in Blockchain-Enabled … Recommended

Citation McCurdy, Denise, ""The Role of Collaborative Governance in Blockchain-Enabled Supply

Chains: A Proposed Framework."" Thesis, Georgia State University, 2020 …";Autres articles;;[PDF] gsu.edu;https://scholarworks.gsu.edu/cgi/viewcontent.cgi?article=1142&context=bus_admin_diss;;"""date"",""2020-05-04T15:41:43Z""
""pdf:PDFVersion"",""1.7""
""xmp:CreatorTool"",""Appligent AppendPDF Pro 6.3""
""pdf:docinfo:title"",""The Role of Collaborative Governance in Blockchain-Enabled Supply Chains: A Proposed Framework""
""Appligent"",""AppendPDF Pro 6.3 Linux 64 bit Aug 30 2019 Library 15.0.4""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""language"",""en""
""dc:format"",""application/pdf; version=1.7""
""pdf:docinfo:creator_tool"",""Appligent AppendPDF Pro 6.3""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""The Role of Collaborative Governance in Blockchain-Enabled Supply Chains: A Proposed Framework""
""xmp:CreateDate"",""2020-05-04T08:41:43Z""
""modified"",""2020-05-04T15:41:43Z""
""pdf:hasMarkedContent"",""true""
""xmp:ModifyDate"",""2020-05-04T08:41:43Z""
""pdf:docinfo:creator"",""Denise McCurdy""
""meta:author"",""Denise McCurdy""
""meta:creation-date"",""2020-05-04T15:41:43Z""
""created"",""2020-05-04T15:41:43Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-05-04T15:41:43Z""
""resourceName"",""viewcontent.cgi""
""Author"",""Denise McCurdy""
""producer"",""Prince 12.5 (www.princexml.com)""
""pdf:docinfo:producer"",""Prince 12.5 (www.princexml.com)""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""access_permission:modify_annotations"",""true""
""dc:creator"",""Denise McCurdy""
""dcterms:created"",""2020-05-04T15:41:43Z""
""Last-Modified"",""2020-05-04T15:41:43Z""
""dcterms:modified"",""2020-05-04T15:41:43Z""
""pdf:docinfo:custom:Appligent"",""AppendPDF Pro 6.3 Linux 64 bit Aug 30 2019 Library 15.0.4""
""title"",""The Role of Collaborative Governance in Blockchain-Enabled Supply Chains: A Proposed Framework""
""xmpMM:DocumentID"",""uuid:b685b814-ae4d-11b2-0a00-a0d180010000""
""Last-Save-Date"",""2020-05-04T15:41:43Z""
""pdf:docinfo:modified"",""2020-05-04T15:41:43Z""
""meta:save-date"",""2020-05-04T15:41:43Z""
""Content-Length"",""5876733""
""Content-Type"",""application/pdf""
""xmp:MetadataDate"",""2020-05-04T08:41:43Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Denise McCurdy""
""dc:language"",""en""
""pdf:producer"",""Prince 12.5 (www.princexml.com)""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""155""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""1103"",""885"",""440"",""391"",""65"",""518"",""406"",""792"",""2414"",""2420"",""1211"",""2365"",""1427"",""1402"",""2031"",""2099"",""2050"",""1826"",""1929"",""1809"",""1912"",""1972"",""2123"",""1948"",""99"",""1750"",""2087"",""862"",""2044"",""1985"",""1154"",""1289"",""1926"",""1064"",""2003"",""2508"",""3073"",""1267"",""1673"",""52"",""531"",""1987"",""2075"",""1985"",""1976"",""849"",""3131"",""2508"",""1908"",""2226"",""948"",""494"",""610"",""948"",""1424"",""1996"",""1644"",""1625"",""1699"",""1538"",""1692"",""1552"",""1843"",""1651"",""1900"",""1823"",""1692"",""1908"",""1946"",""1595"",""1607"",""1812"",""1758"",""1684"",""1643"",""1863"",""1738"",""1777"",""1596"",""1821"",""1556"",""1635"",""1943"",""1563"",""1747"",""1937"",""1848"",""987"",""1678"",""2045"",""1143"",""1356"",""154"",""696"",""779"",""3037"",""3093"",""3032"",""1469"",""2148"",""2067"",""1925"",""1088"",""2057"",""107"",""1006"",""1988"",""1905"",""1984"",""858"",""1057"",""2323"",""3353"",""1346"",""2163"",""1065"",""1669"",""1921"",""1989"",""1856"",""1120"",""2009"",""2128"",""119"",""1749"",""1481"",""67"",""93"",""716"",""1059"",""1278"",""1282"",""1294"",""1379"",""1099"",""1782"",""1560"",""1247"",""1671"",""1403"",""951"",""2385"",""2544"",""2576"",""1376"",""2668"",""2605"",""857"",""2686"",""2673"",""2553"",""2802"",""2612"",""735"",""2110""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-05-04T15:41:43Z""
";https://scholar.google.com/scholar?start=460&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095353-1502;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Context-aware and dynamic role-based access control using blockchain;MU Rahman, B Guidi, F Baiardi, L Ricci ; International Conference on …, 2020  Springer;;"… bitcoin.pdf. 6. Delmolino, K., Arnett, M., Kosba, A., Miller, A., Shi, E.: Step by step towards creating

a safe smart contract: lessons and insights from a cryptocurrency lab … Adler, J., Berryhill, R., Veneris,

A., Poulos, Z., Veira, N., Kastania, A.: Astraea: a decentralized blockchain oracle …";Cité 6 fois;Les 3 versions;null;;;;https://scholar.google.com/scholar?start=300&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095349-1482;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;An organization-friendly blockchain system;H Zheng, Q Wu, J Xie, Z Guan, B Qin, Z Gu ; Computers & Security, 2020  Elsevier;;"… It can be applied to blockchain to achieve the balance of privacy and supervision. 2. Preliminaries.

2.1. Group signature … d ? A O p e n ( G S K , ˇ ) ( g u e s s , S t , ? ). If A did not query Open oracle

with m, ? in the guess stage, return d, else return 0. Exp GS , A f u l l ? t r a c e ( k ) …";Cité 3 fois;;null;;;;https://scholar.google.com/scholar?start=280&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095358-1517;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;[PDF][PDF] Blockchain, Incomplete Contracts, and Mechanisms for Increased Contractibility in the Context of the Theory of the Firm;T Eibinger ; unipub.unigraz.at;;"… is being developed on the Ethereum blockchain. The following discussion of this mechanism

is based … Nodes can lock some of their native cryptocurrency in exchange for the right to vote on

the next block that gets integrated into the network … crypto-assets put at stake …";Autres articles;Version HTML;[PDF] uni-graz.at;https://unipub.uni-graz.at/obvugrhs/content/titleinfo/4795335/full.pdf;;"""date"",""2020-02-12T13:39:27Z""
""pdf:PDFVersion"",""1.7""
""xmp:CreatorTool"",""MicrosoftÂŽ Word 2019""
""pdf:docinfo:title"",""Blockchain, Incomplete Contracts, and Mechanisms for Increased Contractibility in the Context of the Theory of the Firm""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""pdfa:PDFVersion"",""A-3b""
""language"",""en""
""dc:format"",""application/pdf; version=""""A-3b"""""",""application/pdf; version=1.7""
""pdf:docinfo:creator_tool"",""MicrosoftÂŽ Word 2019""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""Blockchain, Incomplete Contracts, and Mechanisms for Increased Contractibility in the Context of the Theory of the Firm""
""xmp:CreateDate"",""2020-02-12T14:39:27Z""
""modified"",""2020-02-12T13:39:27Z""
""pdf:hasMarkedContent"",""true""
""xmp:ModifyDate"",""2020-02-12T14:39:27Z""
""pdf:docinfo:creator"",""Eibinger, Tobias (1211xxx)""
""meta:author"",""Eibinger, Tobias (1211xxx)""
""meta:creation-date"",""2020-02-12T13:39:27Z""
""created"",""2020-02-12T13:39:27Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-02-12T13:39:27Z""
""resourceName"",""full.pdf""
""pdfaid:part"",""3""
""Author"",""Eibinger, Tobias (1211xxx)""
""producer"",""MicrosoftÂŽ Word 2019""
""pdf:docinfo:producer"",""MicrosoftÂŽ Word 2019""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""access_permission:modify_annotations"",""true""
""dc:creator"",""Eibinger, Tobias (1211xxx)""
""dcterms:created"",""2020-02-12T13:39:27Z""
""Last-Modified"",""2020-02-12T13:39:27Z""
""dcterms:modified"",""2020-02-12T13:39:27Z""
""title"",""Blockchain, Incomplete Contracts, and Mechanisms for Increased Contractibility in the Context of the Theory of the Firm""
""xmpMM:DocumentID"",""uuid:3A6D3A73-E5A2-4424-9E37-5A8A66C958F8""
""Last-Save-Date"",""2020-02-12T13:39:27Z""
""pdf:docinfo:modified"",""2020-02-12T13:39:27Z""
""meta:save-date"",""2020-02-12T13:39:27Z""
""Content-Length"",""601225""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Eibinger, Tobias (1211xxx)""
""pdfaid:conformance"",""B""
""dc:language"",""de-AT""
""pdf:producer"",""MicrosoftÂŽ Word 2019""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""43""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""422"",""1758"",""3148"",""3097"",""3220"",""2992"",""3106"",""3248"",""3186"",""3218"",""3104"",""2686"",""3312"",""2914"",""3074"",""3322"",""3277"",""3099"",""3141"",""3078"",""3449"",""3120"",""3219"",""3177"",""3065"",""317"",""3040"",""2755"",""1416"",""2097"",""2444"",""1670"",""2666"",""2101"",""2095"",""1933"",""3100"",""2863"",""1444"",""1921"",""1619"",""1742"",""194""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-02-12T13:39:27Z""
";https://scholar.google.com/scholar?start=320&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095369-1564;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Weitere Elemente im Blockchain-System;K Adam ; BlockchainTechnologie für Unternehmensprozesse, 2020  Springer;;"… Oracles unterstützen Blockchain-Datenbanken in der Datenpflege, um zusammengehörende

Transaktionen nachvollziehbar zu … Oracle-Dienste bieten ihre Dienste on-chain und off-chain

an … dass die angefragten Daten in der entsprechenden Blockchain gespeichert werden …";Autres articles;;null;;;;https://scholar.google.com/scholar?start=370&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095395-1680;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;[PDF][PDF] Das Potenzial von Smart Contracts an einem Beispiel aus der Finanzbranche–Smart Rating;V Furrer, KG Deck ; Digitale Transformation und …, 2020  library.oapen.org;;"… 3 Blockchain Oracle Smart Contracts sind vielfach auf Informationen über die reale Welt

angewiesen … Da eine Blockchain ein in sich geschlossenes System bildet und somit kein direkter …

auf externe Daten möglich ist, werden diese durch sogenannte Oracles verfügbar gemacht …";Autres articles;;[PDF] oapen.org;https://library.oapen.org/bitstream/handle/20.500.12657/23145/1007009.pdf?sequence=1#page=295;;"""date"",""2019-10-31T17:35:21Z""
""pdf:PDFVersion"",""1.4""
""xmp:CreatorTool"",""Adobe InDesign CC 13.1 (Windows)""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""pdfa:PDFVersion"",""A-2b""
""xmpMM:History:Action"",""converted"",""converted""
""language"",""de""
""dc:format"",""application/pdf; version=""""A-2b"""""",""application/pdf; version=1.4""
""pdf:docinfo:creator_tool"",""Adobe InDesign CC 13.1 (Windows)""
""access_permission:fill_in_form"",""true""
""xmpMM:History:When"",""2019-10-31T23:01:12Z"",""2019-10-31T23:03:16Z""
""pdf:encrypted"",""false""
""xmp:CreateDate"",""2019-10-31T18:25:00Z""
""modified"",""2019-10-31T17:35:21Z""
""xmpMM:History:SoftwareAgent"",""pdfToolbox"",""pdfToolbox""
""pdf:hasMarkedContent"",""false""
""xmpMM:History:InstanceID"",""uuid:2f43c78d-25a1-4360-99ab-21be32caea4f"",""uuid:35efaec2-7078-4c52-9931-c72a3b19211d""
""xmp:ModifyDate"",""2019-10-31T23:05:21Z""
""trapped"",""False""
""meta:creation-date"",""2019-10-31T12:55:00Z""
""created"",""2019-10-31T12:55:00Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-10-31T12:55:00Z""
""resourceName"",""1007009.pdf""
""xmpMM:DerivedFrom:DocumentID"",""xmp.did:db7aa24d-b069-3d4f-ab06-7024881867fa""
""pdfaid:part"",""2""
""producer"",""Adobe PDF Library 15.0""
""pdf:docinfo:producer"",""Adobe PDF Library 15.0""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""access_permission:modify_annotations"",""true""
""dcterms:created"",""2019-10-31T12:55:00Z""
""Last-Modified"",""2019-10-31T17:35:21Z""
""dcterms:modified"",""2019-10-31T17:35:21Z""
""xmpMM:DocumentID"",""xmp.id:eaca98b3-de00-dd45-a221-d0d43bb86ad3""
""Last-Save-Date"",""2019-10-31T17:35:21Z""
""pdf:docinfo:modified"",""2019-10-31T17:35:21Z""
""meta:save-date"",""2019-10-31T17:35:21Z""
""Content-Length"",""8515046""
""Content-Type"",""application/pdf""
""xmp:MetadataDate"",""2019-10-31T23:05:21Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""pdfaid:conformance"",""B""
""dc:language"",""DE""
""pdf:producer"",""Adobe PDF Library 15.0""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""441""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""147"",""48"",""156"",""2609"",""2473"",""3352"",""1298"",""2534"",""1575"",""1403"",""701"",""1503"",""1153"",""222"",""1755"",""3508"",""3294"",""3380"",""3512"",""3444"",""3423"",""3238"",""2730"",""1546"",""1708"",""3192"",""1089"",""3091"",""3120"",""2995"",""3140"",""96"",""1663"",""3247"",""2623"",""3137"",""3220"",""3205"",""3639"",""3553"",""1568"",""1563"",""2920"",""3376"",""2480"",""2507"",""2998"",""3343"",""2501"",""2835"",""3205"",""3294"",""3346"",""3013"",""2896"",""3213"",""3194"",""2334"",""1251"",""2821"",""3069"",""3095"",""2577"",""3513"",""3182"",""2254"",""1623"",""2454"",""2465"",""2989"",""2805"",""2895"",""2844"",""2991"",""3097"",""2000"",""2780"",""2020"",""1236"",""2342"",""3120"",""2400"",""3130"",""2733"",""2389"",""3482"",""3471"",""2405"",""3429"",""3093"",""3145"",""3178"",""2064"",""1373"",""3297"",""2755"",""536"",""2832"",""3047"",""2957"",""3051"",""1513"",""2595"",""2866"",""2737"",""1951"",""3205"",""3061"",""2690"",""2907"",""2856"",""3018"",""3577"",""3728"",""2284"",""1692"",""2992"",""3463"",""2864"",""3338"",""3538"",""3154"",""2717"",""3143"",""2773"",""2486"",""2837"",""2885"",""2698"",""2782"",""2751"",""3100"",""2737"",""2630"",""2517"",""3095"",""2797"",""3000"",""3250"",""2773"",""3159"",""2738"",""2691"",""2651"",""3112"",""3056"",""3024"",""2859"",""2633"",""3254"",""3296"",""3286"",""3862"",""2928"",""978"",""1550"",""2769"",""2607"",""3153"",""2925"",""2946"",""2695"",""2819"",""3207"",""2907"",""3507"",""3296"",""3227"",""3042"",""3479"",""3047"",""3216"",""1763"",""3033"",""739"",""3006"",""3280"",""3559"",""3391"",""3511"",""3340"",""3482"",""3321"",""3335"",""3316"",""3530"",""3116"",""3063"",""3383"",""3480"",""2736"",""996"",""1768"",""2551"",""2959"",""3462"",""3428"",""1222"",""3439"",""3359"",""2759"",""2231"",""2929"",""2920"",""2848"",""3080"",""3234"",""3300"",""1912"",""2636"",""3180"",""2717"",""1360"",""3140"",""3282"",""3260"",""3282"",""3289"",""3454"",""3203"",""3169"",""3461"",""3375"",""1989"",""2512"",""2439"",""3124"",""3182"",""3341"",""3685"",""3481"",""1576"",""1918"",""3351"",""2434"",""3195"",""1951"",""2307"",""2681"",""1226"",""1947"",""2743"",""1422"",""2438"",""2170"",""1556"",""779"",""2375"",""1324"",""1579"",""1469"",""1447"",""2844"",""2923"",""3459"",""3713"",""3465"",""2302"",""1619"",""3395"",""2647"",""1914"",""1458"",""3289"",""3072"",""2061"",""2279"",""2965"",""172"",""2528"",""3291"",""3235"",""3493"",""3142"",""3339"",""3375"",""3316"",""3182"",""3097"",""3587"",""3370"",""3328"",""3035"",""1825"",""2202"",""2805"",""2889"",""2649"",""2250"",""3024"",""3522"",""3687"",""3843"",""1894"",""1591"",""2917"",""2961"",""2797"",""2267"",""2560"",""2271"",""2863"",""2788"",""2314"",""2527"",""2181"",""118"",""78"",""2645"",""3013"",""3200"",""3189"",""3340"",""968"",""1499"",""3134"",""2922"",""3145"",""3148"",""3069"",""2693"",""686"",""2859"",""2732"",""2630"",""2106"",""3108"",""2230"",""2982"",""2408"",""3156"",""3023"",""3171"",""3155"",""1849"",""2673"",""2765"",""2046"",""3046"",""3130"",""2868"",""3091"",""3203"",""3323"",""3039"",""3101"",""3218"",""3185"",""2888"",""2632"",""2915"",""2345"",""2437"",""2337"",""2750"",""3141"",""3259"",""3086"",""3135"",""3815"",""3541"",""1631"",""1010"",""1436"",""2777"",""2377"",""2819"",""3151"",""2815"",""2918"",""2747"",""3235"",""2683"",""2148"",""2077"",""3134"",""3421"",""3070"",""3522"",""3283"",""2154"",""2943"",""3075"",""2974"",""3052"",""3002"",""3123"",""3300"",""3384"",""1821"",""1809"",""2875"",""2738"",""2904"",""2363"",""2841"",""2792"",""2900"",""1481"",""1057"",""2174"",""2844"",""2459"",""2587"",""3137"",""2997"",""3058"",""2252"",""1428"",""2961"",""3142"",""3339"",""976"",""2000"",""3251"",""2030"",""2787"",""3258"",""2571"",""2532"",""2941"",""2728"",""2578"",""2448"",""2196"",""2076"",""2970"",""3056"",""2674"",""2267"",""2824"",""2446"",""3132"",""3167"",""3472"",""3378"",""3271"",""3080"",""3268"",""3040"",""974""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""xmpMM:DerivedFrom:InstanceID"",""xmp.iid:19e63477-bbe3-014c-a210-de218e28784f""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-10-31T12:55:00Z""
";https://scholar.google.com/scholar?start=480&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095346-1465;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Txchain: Efficient cryptocurrency light clients via contingent transaction aggregation;A Zamyatin, Z Avarikioti, D Perez… ; … and Blockchain …, 2020  Springer;;"… Another are the growing number of cross-cryptocurrency applications [1, 11, 12] … Blockchain

Notation … Due to the nature of Proof-of-Work (and specifically hash functions modeled as random

oracles), the appearance of such blocks is considered random …";Cité 4 fois;Les 7 versions;[PDF] ethz.ch;https://tik-old.ee.ethz.ch/file/1f815d825df4374fcafb1b5f155c88ed/txchain.pdf;;"""date"",""2020-05-18T20:23:52Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2020-05-18T20:23:52Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016/Debian) kpathsea version 6.2.2""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2020-05-18T20:23:52Z""
""created"",""2020-05-18T20:23:52Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-05-18T20:23:52Z""
""resourceName"",""txchain.pdf""
""Author"",""""
""producer"",""pdfTeX-1.40.17""
""pdf:docinfo:producer"",""pdfTeX-1.40.17""
""pdf:unmappedUnicodeCharsPerPage"",""2"",""0"",""4"",""0"",""0"",""0"",""0"",""15"",""0"",""2"",""2"",""10"",""2"",""0"",""0"",""0"",""0"",""0"",""0"",""9"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2020-05-18T20:23:52Z""
""Last-Modified"",""2020-05-18T20:23:52Z""
""dcterms:modified"",""2020-05-18T20:23:52Z""
""title"",""""
""Last-Save-Date"",""2020-05-18T20:23:52Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2020-05-18T20:23:52Z""
""meta:save-date"",""2020-05-18T20:23:52Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016/Debian) kpathsea version 6.2.2""
""Content-Length"",""398578""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""21""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""2357"",""3163"",""2962"",""2785"",""2501"",""2548"",""2924"",""1718"",""2452"",""2148"",""2525"",""2287"",""1789"",""2786"",""2726"",""2769"",""2349"",""2738"",""3348"",""1784"",""2146""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-05-18T20:23:52Z""
";https://scholar.google.com/scholar?start=270&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095367-1557;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;On the Need for Data Quality Assessment in Blockchains;M Comuzzi, C Cappiello, G Meroni ; IEEE Internet Computing, 2020  ieeexplore.ieee.org;;"… of on-chain data and, if necessary, use also data from external services through oracles … and HLF

These checks can be implemented with smart contracts or with an oracle … In particular, these

controls should be autonomously triggered by the blockchain, for instance through self …";Autres articles;;null;;;;https://scholar.google.com/scholar?start=360&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095332-1410;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;[PDF][PDF] A Value Token Transfer Protocol (VTTP) for Decentralized Finance;A Bahga, VK Madisetti ; Journal of Software Engineering and Applications, 2020  scirp.org;;"… 62818798. [4] Kumar, M. and Nikhil, RS (2020) Decentralising Finance Using Decentralised

Block- chain Oracles … https://doi.org/10.1109/INCET49848.2020.9154123 [5] Band

Protocol—Secure, Scalable Blockchain—Agnostic Decentralized Oracle …";Autres articles;Version HTML;[PDF] scirp.org;https://www.scirp.org/pdf/jsea_2020112511032907.pdf;;"""date"",""2020-11-24T15:19:45Z""
""pdf:PDFVersion"",""1.7""
""xmp:CreatorTool"",""Acrobat PDFMaker 11 Word 版""
""pdf:docinfo:title"",""A Value Token Transfer Protocol (VTTP) for Decentralized Finance""
""Company"",""""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""We present Value Token Transfer Protocol (VTTP), a decentralized finance protocol for exchange of value or tokens within and between participating blockchain networks, fiat bank accounts and fiat wallets. The protocol allows intra-chain or inter-chain transfers of cryptocurrencies or tokens. VTTP works in both client-server and peer-to-peer models. The protocol comprises receiving from a client a transfer request to transfer value in a form of a cryptocurrency or a token, determining if the transfer request is intra-chain or inter- chain, transmitting to the client a response to the transfer request, the response comprising a raw transaction, receiving from the client a response to the raw transaction wherein a private key of a user is used to sign the raw transaction, defining a signed transaction, verifying a signature of the signed transaction and broadcasting the signed transaction to the sending and receiving blockchain networks.""
""language"",""en""
""dc:format"",""application/pdf; version=1.7""
""pdf:docinfo:creator_tool"",""Acrobat PDFMaker 11 Word 版""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""A Value Token Transfer Protocol (VTTP) for Decentralized Finance""
""xmp:CreateDate"",""2020-11-24T23:15:13Z""
""modified"",""2020-11-24T15:19:45Z""
""pdf:docinfo:custom:SourceModified"",""D:20201124151448""
""cp:subject"",""We present Value Token Transfer Protocol (VTTP), a decentralized finance protocol for exchange of value or tokens within and between participating blockchain networks, fiat bank accounts and fiat wallets. The protocol allows intra-chain or inter-chain transfers of cryptocurrencies or tokens. VTTP works in both client-server and peer-to-peer models. The protocol comprises receiving from a client a transfer request to transfer value in a form of a cryptocurrency or a token, determining if the transfer request is intra-chain or inter- chain, transmitting to the client a response to the transfer request, the response comprising a raw transaction, receiving from the client a response to the raw transaction wherein a private key of a user is used to sign the raw transaction, defining a signed transaction, verifying a signature of the signed transaction and broadcasting the signed transaction to the sending and receiving blockchain networks.""
""pdf:docinfo:subject"",""We present Value Token Transfer Protocol (VTTP), a decentralized finance protocol for exchange of value or tokens within and between participating blockchain networks, fiat bank accounts and fiat wallets. The protocol allows intra-chain or inter-chain transfers of cryptocurrencies or tokens. VTTP works in both client-server and peer-to-peer models. The protocol comprises receiving from a client a transfer request to transfer value in a form of a cryptocurrency or a token, determining if the transfer request is intra-chain or inter- chain, transmitting to the client a response to the transfer request, the response comprising a raw transaction, receiving from the client a response to the raw transaction wherein a private key of a user is used to sign the raw transaction, defining a signed transaction, verifying a signature of the signed transaction and broadcasting the signed transaction to the sending and receiving blockchain networks.""
""pdf:hasMarkedContent"",""false""
""xmp:ModifyDate"",""2020-11-24T23:19:45Z""
""pdf:docinfo:creator"",""Arshdeep Bahga, Vijay K. Madisetti""
""meta:author"",""Arshdeep Bahga, Vijay K. Madisetti""
""meta:creation-date"",""2020-11-24T15:15:13Z""
""created"",""2020-11-24T15:15:13Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-11-24T15:15:13Z""
""resourceName"",""jsea_2020112511032907.pdf""
""Author"",""Arshdeep Bahga, Vijay K. Madisetti""
""producer"",""Adobe PDF Library 11.0""
""pdf:docinfo:producer"",""Adobe PDF Library 11.0""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""dc:description"",""We present Value Token Transfer Protocol (VTTP), a decentralized finance protocol for exchange of value or tokens within and between participating blockchain networks, fiat bank accounts and fiat wallets. The protocol allows intra-chain or inter-chain transfers of cryptocurrencies or tokens. VTTP works in both client-server and peer-to-peer models. The protocol comprises receiving from a client a transfer request to transfer value in a form of a cryptocurrency or a token, determining if the transfer request is intra-chain or inter- chain, transmitting to the client a response to the transfer request, the response comprising a raw transaction, receiving from the client a response to the raw transaction wherein a private key of a user is used to sign the raw transaction, defining a signed transaction, verifying a signature of the signed transaction and broadcasting the signed transaction to the sending and receiving blockchain networks.""
""Keywords"",""Blockchain, Decentralized Finance, Open Finance"",""Blockchain, Decentralized Finance, Open Finance""
""access_permission:modify_annotations"",""true""
""dc:creator"",""Arshdeep Bahga, Vijay K. Madisetti""
""description"",""We present Value Token Transfer Protocol (VTTP), a decentralized finance protocol for exchange of value or tokens within and between participating blockchain networks, fiat bank accounts and fiat wallets. The protocol allows intra-chain or inter-chain transfers of cryptocurrencies or tokens. VTTP works in both client-server and peer-to-peer models. The protocol comprises receiving from a client a transfer request to transfer value in a form of a cryptocurrency or a token, determining if the transfer request is intra-chain or inter- chain, transmitting to the client a response to the transfer request, the response comprising a raw transaction, receiving from the client a response to the raw transaction wherein a private key of a user is used to sign the raw transaction, defining a signed transaction, verifying a signature of the signed transaction and broadcasting the signed transaction to the sending and receiving blockchain networks.""
""dcterms:created"",""2020-11-24T15:15:13Z""
""Last-Modified"",""2020-11-24T15:19:45Z""
""dcterms:modified"",""2020-11-24T15:19:45Z""
""title"",""A Value Token Transfer Protocol (VTTP) for Decentralized Finance""
""xmpMM:DocumentID"",""uuid:a1873018-ecc7-48c4-9a3b-9e469983c632""
""Last-Save-Date"",""2020-11-24T15:19:45Z""
""pdf:docinfo:keywords"",""Blockchain, Decentralized Finance, Open Finance""
""pdf:docinfo:modified"",""2020-11-24T15:19:45Z""
""meta:save-date"",""2020-11-24T15:19:45Z""
""Content-Length"",""1422656""
""Content-Type"",""application/pdf""
""xmp:MetadataDate"",""2020-11-24T23:19:45Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Arshdeep Bahga, Vijay K. Madisetti""
""pdf:producer"",""Adobe PDF Library 11.0""
""dc:subject"",""Blockchain, Decentralized Finance, Open Finance"",""Blockchain, Decentralized Finance, Open Finance""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""9""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""2642"",""2821"",""1908"",""1796"",""1928"",""2305"",""1135"",""2163"",""2768""
""access_permission:extract_content"",""true""
""pdf:docinfo:custom:Company"",""""
""access_permission:can_print"",""true""
""SourceModified"",""D:20201124151448""
""meta:keyword"",""Blockchain, Decentralized Finance, Open Finance"",""Blockchain, Decentralized Finance, Open Finance""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-11-24T15:15:13Z""
";https://scholar.google.com/scholar?start=210&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095327-1392;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;ScholarChain: The Scholarship Management Platform with Blockchain and Smart Contracts Technology;U TEKGUC, A ADALIER, K YURTKAN ; The Eurasia Proceedings of …  dergipark.org.tr;;"… Data feeds or Oracles are needed to bring external data into the blockchain. Oracles are external

data providers. Related Works Rashid et al … Astraea: A decentralized blockchain oracle. In 2018

IEEE International Conference on Internet of Things (iThings) and IEEE Page 5 …";Autres articles;;[PDF] dergipark.org.tr;https://dergipark.org.tr/en/download/article-file/1425854;;"""date"",""2020-12-02T08:59:07Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""ISRES""
""xmp:CreatorTool"",""MicrosoftÂŽ Word 2010""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""ISRES""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""MicrosoftÂŽ Word 2010""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""ISRES""
""modified"",""2020-12-02T08:59:07Z""
""cp:subject"",""ISRES""
""pdf:docinfo:subject"",""ISRES""
""pdf:hasMarkedContent"",""true""
""pdf:docinfo:creator"",""ISRES""
""meta:author"",""ISRES""
""meta:creation-date"",""2020-12-02T08:59:07Z""
""created"",""2020-12-02T08:59:07Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-12-02T08:59:07Z""
""resourceName"",""1425854""
""Author"",""ISRES""
""producer"",""MicrosoftÂŽ Word 2010""
""pdf:docinfo:producer"",""MicrosoftÂŽ Word 2010""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0""
""Keywords"",""ISRES""
""access_permission:modify_annotations"",""true""
""dc:creator"",""ISRES""
""dcterms:created"",""2020-12-02T08:59:07Z""
""Last-Modified"",""2020-12-02T08:59:07Z""
""dcterms:modified"",""2020-12-02T08:59:07Z""
""title"",""ISRES""
""Last-Save-Date"",""2020-12-02T08:59:07Z""
""pdf:docinfo:keywords"",""ISRES""
""pdf:docinfo:modified"",""2020-12-02T08:59:07Z""
""meta:save-date"",""2020-12-02T08:59:07Z""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""ISRES""
""dc:language"",""tr-TR""
""dc:subject"",""ISRES""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""6""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""4068"",""3137"",""3348"",""383"",""5017"",""1363""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""meta:keyword"",""ISRES""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-12-02T08:59:07Z""
";https://scholar.google.com/scholar?start=190&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095397-1689;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Strengthening security structure of open Blockchain platform to enhance privacy protection of DApp users;S Hwang, DH Ko, T Bahk, Y Choi ; Journal of Internet Computing …, 2020  koreascience.or.kr;;"… Blockchain nodes: ??? ???? ??? ???? ???? ???? … ""Ring

signatures: Stronger definitions, and constructions without random oracles."" Theory

of Cryptography Conference. Springer, Berlin, Heidelberg, 2006 …";Autres articles;Version HTML;[PDF] koreascience.or.kr;https://www.koreascience.or.kr/article/JAKO202019962560351.pdf;;"""date"",""2020-07-09T00:23:25Z""
""pdf:PDFVersion"",""1.5""
""xmp:CreatorTool"",""PScript5.dll Version 5.2.2""
""pdf:docinfo:title"",""<30312DC8B2BCB1C1F82E687770>""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""PScript5.dll Version 5.2.2""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""<30312DC8B2BCB1C1F82E687770>""
""xmp:CreateDate"",""2020-06-19T17:31:29Z""
""modified"",""2020-07-09T00:23:25Z""
""pdf:hasMarkedContent"",""false""
""xmp:ModifyDate"",""2020-07-09T09:23:25Z""
""pdf:docinfo:creator"",""a""
""meta:author"",""a""
""meta:creation-date"",""2020-06-19T08:31:29Z""
""created"",""2020-06-19T08:31:29Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-06-19T08:31:29Z""
""resourceName"",""JAKO202019962560351.pdf""
""Author"",""a""
""producer"",""Acrobat Distiller 9.0.0 (Windows)""
""pdf:docinfo:producer"",""Acrobat Distiller 9.0.0 (Windows)""
""pdf:unmappedUnicodeCharsPerPage"",""42"",""50"",""69"",""51"",""42"",""64"",""33"",""3"",""5""
""access_permission:modify_annotations"",""true""
""dc:creator"",""a""
""dcterms:created"",""2020-06-19T08:31:29Z""
""Last-Modified"",""2020-07-09T00:23:25Z""
""dcterms:modified"",""2020-07-09T00:23:25Z""
""title"",""<30312DC8B2BCB1C1F82E687770>""
""xmpMM:DocumentID"",""uuid:ec3cd478-dad3-463f-9362-3bf6800786cb""
""Last-Save-Date"",""2020-07-09T00:23:25Z""
""pdf:docinfo:modified"",""2020-07-09T00:23:25Z""
""meta:save-date"",""2020-07-09T00:23:25Z""
""Content-Length"",""886252""
""Content-Type"",""application/pdf""
""xmp:MetadataDate"",""2020-07-09T09:23:25Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""a""
""pdf:producer"",""Acrobat Distiller 9.0.0 (Windows)""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""9""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""3071"",""1580"",""2016"",""1633"",""2258"",""2307"",""1539"",""3291"",""759""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-06-19T08:31:29Z""
";https://scholar.google.com/scholar?start=490&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095397-1691;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;[PDF][PDF] Post-Quantum Adaptor Signature for Privacy-Preserving Off-Chain Payments;E Tairi, P Moreno;Sanchez, M Maffei 2020 eprint.iacr.org;;"… The blockchain community has also shown interest in migrating towards post-quantum secure

alternatives … R, random oracle H and security parameter ? (in the random oracle model) if … Adaptor

signatures have been introduced by the cryptocurrency community to tie together the …";Cité 3 fois;;[PDF] iacr.org;https://eprint.iacr.org/2020/1345.pdf;;"""date"",""2021-03-23T15:31:44Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2021-03-23T15:31:44Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.21 (TeX Live 2020) kpathsea version 6.3.2""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2021-03-23T15:31:44Z""
""created"",""2021-03-23T15:31:44Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2021-03-23T15:31:44Z""
""resourceName"",""1345.pdf""
""Author"",""""
""producer"",""pdfTeX-1.40.21""
""pdf:docinfo:producer"",""pdfTeX-1.40.21""
""pdf:unmappedUnicodeCharsPerPage"",""2"",""1"",""2"",""6"",""3"",""2"",""12"",""5"",""7"",""7"",""19"",""33"",""19"",""11"",""41"",""0"",""2"",""0"",""1"",""5"",""15"",""0"",""0"",""0"",""34"",""16"",""5"",""5"",""20"",""27"",""28"",""27"",""7"",""18"",""18"",""32"",""30"",""37"",""30"",""8"",""6""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2021-03-23T15:31:44Z""
""Last-Modified"",""2021-03-23T15:31:44Z""
""dcterms:modified"",""2021-03-23T15:31:44Z""
""title"",""""
""Last-Save-Date"",""2021-03-23T15:31:44Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2021-03-23T15:31:44Z""
""meta:save-date"",""2021-03-23T15:31:44Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.21 (TeX Live 2020) kpathsea version 6.3.2""
""Content-Length"",""572021""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""41""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""2138"",""2976"",""2905"",""2122"",""1710"",""1961"",""2143"",""1711"",""2622"",""2282"",""2269"",""2045"",""2807"",""2612"",""2011"",""2628"",""2720"",""2602"",""2783"",""2796"",""1640"",""2678"",""2761"",""1207"",""1657"",""2387"",""832"",""1641"",""1138"",""1407"",""1392"",""1438"",""2061"",""2203"",""914"",""1454"",""1106"",""1356"",""1371"",""2032"",""1442""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2021-03-23T15:31:44Z""
";https://scholar.google.com/scholar?start=490&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095383-1633;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;????????????????;S Chien ; ????????????????, 2020  airitilibrary.com;;"… In this thesis, a bill of quantity framework based on blockchain was created, and as a proof of

concept, an oracle that can provide external data to the on-chain bill of quantity was successfully

developed … ????( 44 ) ?TOP?. Academy, B. (2020). Blockchain Oracles Explained …";Autres articles;;null;;;;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095325-1376;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Quel est le rôle de la technologie blockchain dans la logistique et la supply chain?: le cas d'une entreprise de logistique ŕ Genčve;P Oviedo ;2020 doc.rero.ch;;"… d'Oracles, les plus fréquents sont les suivants : Page 13. Quel est le rôle de la technologie de

la Blockchain dans la Logistique et la Supply Chain ? : Le cas d'une entreprise de logistique

ŕ Genčve. OVIEDO Paola 6 Oracle hardware : il peut s'agir de dispositifs par exemple un …";;;[PDF] rero.ch;https://doc.rero.ch/record/329994/files/OVIEDO-PAOLA-RENDU-JUL20.pdf;;"""date"",""2020-07-16T11:57:48Z""
""pdf:PDFVersion"",""1.6""
""xmp:CreatorTool"",""Acrobat PDFMaker 20 pour Word""
""pdf:docinfo:title"",""""
""Company"",""HEGGE""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""ZOTERO_PREF_1"",""<data data-version=""""3"""" zotero-version=""""5.0.82""""><session id=""""hjzaTect""""/><style id=""""http://www.zotero.org/styles/iso690-author-date-fr-no-abstract"""" hasBibliography=""""1"""" bibliographyStyleHasBeenSet=""""0""""/><prefs><pref name=""""fieldType"""" value=""""Field""""/><pref name=""
""language"",""fr""
""ZOTERO_PREF_2"",""""""automaticJournalAbbreviations"""" value=""""true""""/></prefs></data>""
""dc:format"",""application/pdf; version=1.6""
""pdf:docinfo:creator_tool"",""Acrobat PDFMaker 20 pour Word""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""xmp:CreateDate"",""2020-07-16T13:57:26Z""
""modified"",""2020-07-16T11:57:48Z""
""pdf:docinfo:custom:SourceModified"",""D:20200716114428""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""true""
""xmp:ModifyDate"",""2020-07-16T13:57:48Z""
""pdf:docinfo:creator"",""Desjacques Corinne (HES)""
""meta:author"",""Desjacques Corinne (HES)""
""meta:creation-date"",""2020-07-16T11:57:26Z""
""created"",""2020-07-16T11:57:26Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-07-16T11:57:26Z""
""resourceName"",""OVIEDO-PAOLA-RENDU-JUL20.pdf""
""Author"",""Desjacques Corinne (HES)""
""producer"",""Adobe PDF Library 20.9.95""
""pdf:docinfo:producer"",""Adobe PDF Library 20.9.95""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""pdf:docinfo:custom:ZOTERO_PREF_2"",""""""automaticJournalAbbreviations"""" value=""""true""""/></prefs></data>""
""pdf:docinfo:custom:ZOTERO_PREF_1"",""<data data-version=""""3"""" zotero-version=""""5.0.82""""><session id=""""hjzaTect""""/><style id=""""http://www.zotero.org/styles/iso690-author-date-fr-no-abstract"""" hasBibliography=""""1"""" bibliographyStyleHasBeenSet=""""0""""/><prefs><pref name=""""fieldType"""" value=""""Field""""/><pref name=""
""dc:creator"",""Desjacques Corinne (HES)""
""dcterms:created"",""2020-07-16T11:57:26Z""
""Last-Modified"",""2020-07-16T11:57:48Z""
""dcterms:modified"",""2020-07-16T11:57:48Z""
""title"",""""
""xmpMM:DocumentID"",""uuid:13571b35-2ab7-4065-916d-4d0728b3ef51""
""Last-Save-Date"",""2020-07-16T11:57:48Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2020-07-16T11:57:48Z""
""meta:save-date"",""2020-07-16T11:57:48Z""
""Content-Length"",""1598785""
""Content-Type"",""application/pdf""
""xmp:MetadataDate"",""2020-07-16T13:57:48Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Desjacques Corinne (HES)""
""dc:language"",""FR-CH""
""pdf:producer"",""Adobe PDF Library 20.9.95""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""63""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""538"",""1076"",""973"",""1642"",""4490"",""2675"",""1589"",""1954"",""2760"",""2124"",""2664"",""2618"",""987"",""1208"",""2623"",""1575"",""2841"",""2671"",""2650"",""1452"",""1628"",""1991"",""1587"",""1942"",""2587"",""2804"",""2731"",""1771"",""2709"",""1572"",""1603"",""2100"",""2805"",""1490"",""2222"",""2683"",""2736"",""2498"",""2828"",""2635"",""1872"",""1311"",""1815"",""1735"",""2543"",""314"",""1460"",""2545"",""303"",""2362"",""2645"",""2640"",""2866"",""2572"",""467"",""223"",""290"",""211"",""200"",""226"",""207"",""1991"",""528""
""access_permission:extract_content"",""true""
""pdf:docinfo:custom:Company"",""HEGGE""
""access_permission:can_print"",""true""
""SourceModified"",""D:20200716114428""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-07-16T11:57:26Z""
";https://scholar.google.com/scholar?start=180&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095339-1437;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Smart Contracts;D Hellwig, G Karlic, A Huchzermeier ; Build Your Own Blockchain, 2020  Springer;;"… Of course, it is also possible to apply scores to individual Oracles such that a source carries more

weight if it appears to be more reliable than other sources … 4.8. Fig. 4.8 Oracle for the USD-EUR

exchange rate … All data is stored and cryptographically secured in a blockchain …";Autres articles;;null;;;;https://scholar.google.com/scholar?start=240&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095330-1400;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Simulation-sound arguments for LWE and applications to KDM-CCA2 security;B Libert, K Nguyen, A Passelčgue, R Titiu ; International Conference on …, 2020  Springer;;"… instantiate it under the sole Learning-With-Errors (\(\mathsf {LWE}\)) assumption without relying

on random oracles … (STOC'19) and Peikert-Shiehian (Crypto'19) provide … method for instantiating

Naor-Yung under the \(\mathsf {LWE}\) assumption outside the random oracle model …";Cité 3 fois;Les 5 versions;[PDF] inria.fr;https://hal.inria.fr/hal-02993617/document;;"""date"",""2020-09-02T16:08:53Z""
""pdf:PDFVersion"",""1.4""
""pdf:docinfo:title"",""Simulation-Sound Arguments for LWE and Applications to KDM-CCA2 Security""
""xmp:CreatorTool"",""HAL""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""Computer Science [cs]/Cryptography and Security [cs.CR]""
""language"",""en""
""dc:format"",""application/pdf; version=1.4""
""pdf:docinfo:creator_tool"",""HAL""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""Simulation-Sound Arguments for LWE and Applications to KDM-CCA2 Security""
""modified"",""2020-09-02T16:08:53Z""
""cp:subject"",""Computer Science [cs]/Cryptography and Security [cs.CR]""
""pdf:docinfo:subject"",""Computer Science [cs]/Cryptography and Security [cs.CR]""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""BenoÎt Libert, Khoa Nguyen, Alain Passelègue, Radu Titiu""
""PTEX.Fullbanner"",""This is MiKTeX-pdfTeX 2.9.6839 (1.40.19)""
""meta:author"",""BenoÎt Libert, Khoa Nguyen, Alain Passelègue, Radu Titiu""
""trapped"",""False""
""meta:creation-date"",""2021-04-12T07:26:53Z""
""created"",""2021-04-12T07:26:53Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2021-04-12T07:26:53Z""
""resourceName"",""document""
""Author"",""BenoÎt Libert, Khoa Nguyen, Alain Passelègue, Radu Titiu""
""producer"",""PDFLaTeX""
""pdf:docinfo:producer"",""PDFLaTeX""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""13"",""0"",""4"",""10"",""0"",""0"",""26"",""14"",""15"",""5"",""7"",""13"",""20"",""45"",""41"",""36"",""42"",""40"",""35"",""36"",""6"",""102"",""16"",""29"",""27"",""48"",""37"",""45"",""4"",""0"",""0"",""0"",""5"",""7"",""5"",""19"",""35"",""61"",""39"",""45"",""46"",""34"",""34"",""20"",""105"",""28"",""35"",""36"",""32"",""47"",""16"",""8"",""43"",""0"",""34"",""43"",""44"",""18"",""20"",""91"",""48"",""49"",""41"",""51""
""Keywords"",""LWE, standard model, Naor-Yung, NIZK arguments, simulation- soundness, KDM-CCA2 security, tight security""
""access_permission:modify_annotations"",""true""
""dc:creator"",""BenoÎt Libert, Khoa Nguyen, Alain Passelègue, Radu Titiu""
""dcterms:created"",""2021-04-12T07:26:53Z""
""Last-Modified"",""2020-09-02T16:08:53Z""
""dcterms:modified"",""2020-09-02T16:08:53Z""
""title"",""Simulation-Sound Arguments for LWE and Applications to KDM-CCA2 Security""
""Last-Save-Date"",""2020-09-02T16:08:53Z""
""pdf:docinfo:keywords"",""LWE, standard model, Naor-Yung, NIZK arguments, simulation- soundness, KDM-CCA2 security, tight security""
""pdf:docinfo:modified"",""2020-09-02T16:08:53Z""
""meta:save-date"",""2020-09-02T16:08:53Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is MiKTeX-pdfTeX 2.9.6839 (1.40.19)""
""Content-Length"",""1271124""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""BenoÎt Libert, Khoa Nguyen, Alain Passelègue, Radu Titiu""
""dc:subject"",""LWE, standard model, Naor-Yung, NIZK arguments, simulation- soundness, KDM-CCA2 security, tight security""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""68""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""935"",""2136"",""2826"",""2888"",""2782"",""2910"",""2887"",""2720"",""2870"",""2740"",""1968"",""1961"",""2251"",""2463"",""2421"",""1974"",""1820"",""1592"",""1756"",""2129"",""1928"",""2287"",""2382"",""2597"",""2319"",""2063"",""1818"",""1796"",""1979"",""2298"",""1340"",""1779"",""2068"",""2671"",""2753"",""2491"",""2186"",""2219"",""2220"",""2103"",""2226"",""2095"",""2092"",""1715"",""1736"",""2077"",""2378"",""2378"",""1931"",""1554"",""1588"",""2058"",""1553"",""1589"",""1862"",""2108"",""1339"",""2560"",""2448"",""2556"",""2745"",""2482"",""2078"",""1612"",""2084"",""2354"",""1684"",""2137""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""LWE, standard model, Naor-Yung, NIZK arguments, simulation- soundness, KDM-CCA2 security, tight security""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2021-04-12T07:26:53Z""
";https://scholar.google.com/scholar?start=200&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095388-1649;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Hashing Out Agreements: An Overview of “Smart” Contracts under Canadian Common Law;F Martin;Bariteau, M Pontello  Available at SSRN, 2020  papers.ssrn.com;;"… This problem has been solved through the use of a blockchain middleware called an “oracle.”

Oracles bridge smart … 13 Aaron Wright & David Roon, “Bridging the Fiat-Crypto Divide” (11

September 2018), online: Consensys https://media.consensys.net/bridging-the-fiat …";Autres articles;;null;;;;https://scholar.google.com/scholar?start=450&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095295-1252;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;[HTML][HTML] Research–A blockchain of knowledge?;J Ducrée ; Blockchain: Research and Applications, 2020  Elsevier;;"… as, for instance, in Bitcoin [1], or by vouching (crypto-)assets (“Proof … Paper (2014). Google Scholar.

[4] Band protocol - SecureScalable blockchain-agnostic decentralized oracle … 08/2020; Available

on. https://bandprotocol.com/. Google Scholar. [5] Blockchain oracles. Accessed: 24 …";Cité 1 fois;;[HTML] sciencedirect.com;https://www.sciencedirect.com/science/article/pii/S2096720920300051;;;https://scholar.google.com/scholar?start=50&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095316-1343;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;PBT: A new privacy-preserving payment protocol for blockchain transactions;Y Jia, S Sun, Y Zhang, Q Zhang, N Ding… ; … on Dependable and …, 2020  ieeexplore.ieee.org;;"… Whenever receiving this transaction from the P2P blockchain network, the miners check the validity

of the transaction … where all oracles AddGen, ActGen, Spend and Corrupt are defined as below …

The oracle also uses aski to determine the serial number si of acti and adds it to …";Cité 1 fois;Les 2 versions;null;;;;https://scholar.google.com/scholar?start=140&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095378-1611;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Initial Coin Offerings: Análisis de Blockchain y estrategia de financiación basada en emisión de tokens;WA Espinoza Vargas ;2020 repositorio.unican.es;;"… Los Oracles proveen diferentes tipos de datos e información externa a la Blockchain, lo que … la

asignación de esta tarea a una entidad externa o usar un servicio Oracle descentralizado. Ejemplo

de esto último es Oraclize, una red Blockchain que media entre Smart Contracts y …";;;[PDF] unican.es;https://repositorio.unican.es/xmlui/bitstream/handle/10902/20967/ESPINOZAVARGASWALTERALEJANDRO.pdf?sequence=1;;"""date"",""2020-12-02T16:22:33Z""
""pdf:PDFVersion"",""1.7""
""xmp:CreatorTool"",""MicrosoftÂŽ Word para Microsoft 365""
""pdf:docinfo:title"",""Walter Alejandro Espinoza Vargas""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""language"",""es""
""dc:format"",""application/pdf; version=1.7""
""pdf:docinfo:creator_tool"",""MicrosoftÂŽ Word para Microsoft 365""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""Walter Alejandro Espinoza Vargas""
""xmp:CreateDate"",""2020-12-02T17:22:33Z""
""modified"",""2020-12-02T16:22:33Z""
""pdf:hasMarkedContent"",""true""
""xmp:ModifyDate"",""2020-12-02T17:22:33Z""
""pdf:docinfo:creator"",""Biblioteca Universitaria""
""meta:author"",""Biblioteca Universitaria""
""meta:creation-date"",""2020-12-02T16:22:33Z""
""created"",""2020-12-02T16:22:33Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-12-02T16:22:33Z""
""resourceName"",""ESPINOZAVARGASWALTERALEJANDRO.pdf""
""Author"",""Biblioteca Universitaria""
""producer"",""MicrosoftÂŽ Word para Microsoft 365""
""pdf:docinfo:producer"",""MicrosoftÂŽ Word para Microsoft 365""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""access_permission:modify_annotations"",""true""
""dc:creator"",""Biblioteca Universitaria""
""dcterms:created"",""2020-12-02T16:22:33Z""
""Last-Modified"",""2020-12-02T16:22:33Z""
""dcterms:modified"",""2020-12-02T16:22:33Z""
""title"",""Walter Alejandro Espinoza Vargas""
""xmpMM:DocumentID"",""uuid:9592F4B0-C7AB-4837-9E0B-F87DBCC33D34""
""Last-Save-Date"",""2020-12-02T16:22:33Z""
""pdf:docinfo:modified"",""2020-12-02T16:22:33Z""
""meta:save-date"",""2020-12-02T16:22:33Z""
""Content-Length"",""770478""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Biblioteca Universitaria""
""dc:language"",""es-ES""
""pdf:producer"",""MicrosoftÂŽ Word para Microsoft 365""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""33""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""436"",""135"",""3842"",""532"",""3901"",""245"",""349"",""133"",""3030"",""2856"",""2842"",""3474"",""2687"",""2225"",""3629"",""2954"",""3390"",""2144"",""2752"",""2043"",""2917"",""2340"",""3144"",""3655"",""3984"",""3564"",""2389"",""2418"",""3122"",""153"",""3147"",""3336"",""1572""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-12-02T16:22:33Z""
";https://scholar.google.com/scholar?start=410&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095388-1645;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;??? ????? ??? ????? ???? ???;??? ; ???????, 2020  earticle.net;;"… ?? ?? Home. ??? ????? ??? ????? ???? ??? Blockchain

Oracle for Random Number Generator using Irregular Big Data. ???? SNS ??.

???? ???????? ????; ??? ??????? …";;;null;;;;https://scholar.google.com/scholar?start=450&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095376-1595;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Blockchain y contratos inteligentes: aproximación a sus problemáticas y retos jurídicos;JA PADILLA SÁNCHEZ ; Revista de Derecho Privado, 2020  scielo.org.co;;"… 24 “And so, in laymen's terms, the blockchain can be described as a decentralised,

peer-validated crypto-ledger that provides a publicly visible, chronological and

permanent record of all prior trans- actions. It resembles a spreadsheet …";Cité 3 fois;Les 5 versions;[PDF] scielo.org.co;http://www.scielo.org.co/pdf/rdp/n39/0123-4366-rdp-39-175.pdf;;"""date"",""2020-06-28T17:28:16Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.6""
""xmp:CreatorTool"",""Adobe InDesign CC 2017 (Macintosh)""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dcterms:created"",""2020-06-28T17:28:04Z""
""language"",""es""
""Last-Modified"",""2020-06-28T17:28:16Z""
""dcterms:modified"",""2020-06-28T17:28:16Z""
""dc:format"",""application/pdf; version=1.6""
""xmpMM:DocumentID"",""uuid:f60af950-295b-4924-a5d8-92338c13bcc2""
""Last-Save-Date"",""2020-06-28T17:28:16Z""
""pdf:docinfo:creator_tool"",""Adobe InDesign CC 2017 (Macintosh)""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2020-06-28T17:28:16Z""
""meta:save-date"",""2020-06-28T17:28:16Z""
""pdf:encrypted"",""false""
""xmp:CreateDate"",""2020-06-28T12:28:04Z""
""modified"",""2020-06-28T17:28:16Z""
""Content-Length"",""489389""
""pdf:hasMarkedContent"",""true""
""Content-Type"",""application/pdf""
""xmp:ModifyDate"",""2020-06-28T12:28:16Z""
""xmp:MetadataDate"",""2020-06-28T12:28:16Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""pdf:producer"",""Adobe PDF Library 15.0""
""meta:creation-date"",""2020-06-28T17:28:04Z""
""created"",""2020-06-28T17:28:04Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""27""
""Creation-Date"",""2020-06-28T17:28:04Z""
""resourceName"",""0123-4366-rdp-39-175.pdf""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""1873"",""2876"",""4004"",""3692"",""4000"",""3844"",""3902"",""3378"",""4283"",""3774"",""4133"",""4223"",""3724"",""3661"",""3808"",""3305"",""3586"",""4414"",""3622"",""3615"",""3727"",""3731"",""3634"",""3168"",""2259"",""2006"",""779""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""producer"",""Adobe PDF Library 15.0""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""Adobe PDF Library 15.0""
""pdf:docinfo:created"",""2020-06-28T17:28:04Z""
";https://scholar.google.com/scholar?start=400&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095318-1346;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Exploring the attack surface of blockchain: A comprehensive survey;M Saad, J Spaulding, L Njilla… ; … Surveys & Tutorials, 2020  ieeexplore.ieee.org;;"… For instance, with Bitcoin, such attacks can cause devaluation of the cryptocurrency, loss of mining

rewards, or even closure of cryptocurrency exchanges [30]. Bitcoin's Blockchain is also targeted

with dust or spam transactions to delay the processing of legitimate transactions …";Cité 22 fois;Les 2 versions;[PDF] researchgate.net;https://www.researchgate.net/profile/David_Mohaisen/publication/339634933_Exploring_the_Attack_Surface_of_Blockchain_A_Comprehensive_Survey/links/5ff35aaaa6fdccdcb82e71b5/Exploring-the-Attack-Surface-of-Blockchain-A-Comprehensive-Survey.pdf;;;https://scholar.google.com/scholar?start=150&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095290-1228;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;SOChain: A privacy-preserving DDoS data exchange service over soc consortium blockchain;LY Yeh, PJ Lu, SH Huang… ; IEEE Transactions on …, 2020  ieeexplore.ieee.org;;"… Generally, several oracles share the same private key PROra?sev of our decentralized oracle

service; moreover, each oracle retains its own private key PROra for … For important param- eters,

the selected oracle submits the hash of these parameters to the blockchain as a …";Cité 5 fois;Les 3 versions;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/17/4429834/09040569.pdf?casa_token=Jz3rlSJfba8AAAAA:MpibxEHMtc8TDnN_l7NJt1_TaZiQuJUPbSJi0nqZnFYkAGG3AlfrpVopY2haYTrzF0zW97g6Jok;;"""og:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""twitter:title"",""SOChain: A Privacy-Preserving DDoS Data Exchange Service Over SOC Consortium Blockchain""
""twitter:card"",""summary""
""Description"",""IoT devices provide a significant medium for distributed denial-of-service (DDoS) attacks. In 2016, a large-scale DDoS attack, named Dyn, caused massive damage ""
""og:title"",""SOChain: A Privacy-Preserving DDoS Data Exchange Service Over SOC Consortium Blockchain""
""resourceName"",""09040569.pdf""
""language"",""en""
""title"",""SOChain: A Privacy-Preserving DDoS Data Exchange Service Over SOC Consortium Blockchain | IEEE Journals & Magazine | IEEE Xplore""
""og:description"",""IoT devices provide a significant medium for distributed denial-of-service (DDoS) attacks. In 2016, a large-scale DDoS attack, named Dyn, caused massive damage to several well-known companies. One effective countermeasure is observing previous network traffic information or abnormal behavior determined by the host machines and determining the latest DDoS-attack IP addresses. Because of the lack of a fair exchange mechanism, most security operation centers (SOCs) are unwilling to share their real-time DDoS data. In this article, we propose a decentralized DDoS data exchange platform, namely SOChain, using blockchain technology to overcome the trust and fairness issues. The platform incentivizes SOCs through the DDoS_coin token. The more DDoS information an SOC contributes, the more coins it earns. To confirm the validity of uploaded information, we enlist a content verifier to examine uploaded abnormal IP addresses. Moreover, the verifier is incentivized by the DDoS_coin. To decrease the management effort, the entire flow is automatically executed in smart contract deployed onto the blockchain system. To address the issue of privacy in smart contracts, we devise a novel dual-level Bloom filter to enable efficient searches with privacy protection. Herein, a verifiable method is designed without revealing the information to public.""
""twitter:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-UA-Compatible"",""IE=Edge""
""viewport"",""width=device-width, initial-scale=1.0""
""dc:title"",""SOChain: A Privacy-Preserving DDoS Data Exchange Service Over SOC Consortium Blockchain | IEEE Journals & Magazine | IEEE Xplore""
""twitter:description"",""IoT devices provide a significant medium for distributed denial-of-service (DDoS) attacks. In 2016, a large-scale DDoS attack, named Dyn, caused massive damage to several well-known companies. One effective countermeasure is observing previous network traffic information or abnormal behavior determined by the host machines and determining the latest DDoS-attack IP addresses. Because of the lack of a fair exchange mechanism, most security operation centers (SOCs) are unwilling to share their real-time DDoS data. In this article, we propose a decentralized DDoS data exchange platform, namely SOChain, using blockchain technology to overcome the trust and fairness issues. The platform incentivizes SOCs through the DDoS_coin token. The more DDoS information an SOC contributes, the more coins it earns. To confirm the validity of uploaded information, we enlist a content verifier to examine uploaded abnormal IP addresses. Moreover, the verifier is incentivized by the DDoS_coin. To decrease the management effort, the entire flow is automatically executed in smart contract deployed onto the blockchain system. To address the issue of privacy in smart contracts, we devise a novel dual-level Bloom filter to enable efficient searches with privacy protection. Herein, a verifiable method is designed without revealing the information to public.""
""Content-Encoding"",""UTF-8""
""Content-Type-Hint"",""text/html; charset=utf-8""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=30&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095339-1439;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;A post-quantum end-to-end encryption over smart contract-based blockchain for defeating man-in-the-middle and interception attacks;AH Karbasi, S Shahpasand ; PeertoPeer Networking and Applications, 2020  Springer;;"… this paper can be abridged as follows: • We propose an IPFS-blockchain-based arrangement …

Specifically, PAKEs with provable security in the random oracle model and formal models are …

ongoing proposals are promising [31–33] which depend on random oracles and standard …";Cité 3 fois;;null;;;;https://scholar.google.com/scholar?start=240&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095367-1558;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;BIM, Blockchain & Smart Contracts;N Greenwald ; Construction Lawyer, 2020  HeinOnline;;"… The delivery and the payment would be events recorded in the blockchain … contract is veri- fication

that the triggering event occurred, which is where something called an ""oracle"" fits in … to the

contractual agreement, in the form of elec- tronic data, also referred to as oracles.27 …";Les 2 versions;;[PDF] construction.org;https://www.construction.org/uploads/1/3/0/0/130077408/greenwald_bim_blockchain_and_smart_contracts_article_1.13.2021.pdf;;"""date"",""2021-01-13T17:15:40Z""
""pdf:PDFVersion"",""1.7""
""xmp:CreatorTool"",""MicrosoftÂŽ Word for Office 365""
""pdf:docinfo:title"",""Newsletter""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""language"",""en""
""dc:format"",""application/pdf; version=1.7""
""pdf:docinfo:creator_tool"",""MicrosoftÂŽ Word for Office 365""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""Newsletter""
""xmp:CreateDate"",""2021-01-13T12:15:40Z""
""modified"",""2021-01-13T17:15:40Z""
""pdf:hasMarkedContent"",""true""
""xmp:ModifyDate"",""2021-01-13T12:15:40Z""
""pdf:docinfo:creator"",""nancy greenwald""
""meta:author"",""nancy greenwald""
""meta:creation-date"",""2021-01-13T17:15:40Z""
""created"",""2021-01-13T17:15:40Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2021-01-13T17:15:40Z""
""resourceName"",""greenwald_bim_blockchain_and_smart_contracts_article_1.13.2021.pdf""
""Author"",""nancy greenwald""
""producer"",""MicrosoftÂŽ Word for Office 365""
""pdf:docinfo:producer"",""MicrosoftÂŽ Word for Office 365""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""access_permission:modify_annotations"",""true""
""dc:creator"",""nancy greenwald""
""dcterms:created"",""2021-01-13T17:15:40Z""
""Last-Modified"",""2021-01-13T17:15:40Z""
""dcterms:modified"",""2021-01-13T17:15:40Z""
""title"",""Newsletter""
""xmpMM:DocumentID"",""uuid:0B8DD3EF-43E5-4ED7-902E-8C9679AB7EA0""
""Last-Save-Date"",""2021-01-13T17:15:40Z""
""pdf:docinfo:modified"",""2021-01-13T17:15:40Z""
""meta:save-date"",""2021-01-13T17:15:40Z""
""Content-Length"",""247997""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""nancy greenwald""
""dc:language"",""en-US""
""pdf:producer"",""MicrosoftÂŽ Word for Office 365""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""9""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""4059"",""4805"",""4490"",""4417"",""4746"",""4661"",""4718"",""4892"",""5193""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2021-01-13T17:15:40Z""
";https://scholar.google.com/scholar?start=360&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095371-1581;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Verifiable Blockchain-Based Searchable Encryption with forward and backward privacy;R Du, Y Wang ; 2020 16th International Conference on Mobility …, 2020  ieeexplore.ieee.org;;"… wi,c) and Q={Twi,c,KfK m},uses PKuser to encrypt the authorization information CT=PKuser(Q)

and send to the blockchain using R … function is |Pr[Gi=1]=Pr[G2=1]| In game Gi, we model all the

hash functions as random oracles and maintain a list for each oracle to store …";Les 2 versions;;null;;;;https://scholar.google.com/scholar?start=380&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095365-1550;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;What can blockchain do and Cannot do?;Z Xu, C Zou ; China Economic Journal, 2020  Taylor & Francis;;"… But there is no decentralized Oracle mechanism to write such information into blockchain in a

reliable … possibility to fast cash out tokens impairs the alignment of interests between blockchain

projects and … the contrary, it is much easier for tokens to be listed on crypto exchanges …";Cité 1 fois;;null;;;;https://scholar.google.com/scholar?start=350&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095320-1357;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Kirti: A blockchain-based credit recommender system for financial institutions;SB Patel, P Bhattacharya, S Tanwar… ; IEEE Transactions on …, 2020  ieeexplore.ieee.org;;"… For ex- ample, Wang et al. [5] presented traceable transactions over Hyperledger fabric using

digital signature and random oracles for data privacy. Authors in [6] proposed a blockchain-based

credit analysis scheme using binary classifiers that operates in 2D space to reduce …";Cité 5 fois;;null;;;;https://scholar.google.com/scholar?start=160&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095362-1543;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;[PDF][PDF] An Empirical Review on Blockchain Smart Contracts: Application and Challenges in Implementation;J Mandloi, P Bansal ; ijcna.org;;"… adopt the Blockchain smart contracts for the real world applications other than the cryptocurrency,

require privacy … are required, it increases performance and security issues of the system called

Oracle problem [43 … Security Challenges in Implementing Blockchain Smart Contract …";Autres articles;;[PDF] ijcna.org;https://www.ijcna.org/Manuscripts/IJCNA-2020-O-05.pdf;;"""date"",""2020-04-30T11:08:14Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.5""
""xmp:CreatorTool"",""MicrosoftÂŽ Word 2013""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dc:creator"",""EverScience Publications""
""language"",""en""
""dcterms:created"",""2020-04-30T11:08:14Z""
""Last-Modified"",""2020-04-30T11:08:14Z""
""dcterms:modified"",""2020-04-30T11:08:14Z""
""dc:format"",""application/pdf; version=1.5""
""Last-Save-Date"",""2020-04-30T11:08:14Z""
""pdf:docinfo:creator_tool"",""MicrosoftÂŽ Word 2013""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2020-04-30T11:08:14Z""
""meta:save-date"",""2020-04-30T11:08:14Z""
""pdf:encrypted"",""false""
""modified"",""2020-04-30T11:08:14Z""
""Content-Length"",""977895""
""pdf:hasMarkedContent"",""true""
""Content-Type"",""application/pdf""
""pdf:docinfo:creator"",""EverScience Publications""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""EverScience Publications""
""dc:language"",""en-US""
""meta:author"",""EverScience Publications""
""meta:creation-date"",""2020-04-30T11:08:14Z""
""created"",""2020-04-30T11:08:14Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""19""
""Creation-Date"",""2020-04-30T11:08:14Z""
""resourceName"",""IJCNA-2020-O-05.pdf""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""4449"",""4977"",""4351"",""3103"",""3372"",""6079"",""5896"",""6422"",""6182"",""5138"",""6425"",""5850"",""5512"",""3778"",""6131"",""5668"",""7726"",""8054"",""3179""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""Author"",""EverScience Publications""
""producer"",""MicrosoftÂŽ Word 2013""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""MicrosoftÂŽ Word 2013""
""pdf:docinfo:created"",""2020-04-30T11:08:14Z""
";https://scholar.google.com/scholar?start=340&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095388-1653;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Is Blockchain Technology the Future of Land Registry Digitalization?;J Desic, K Lenac ; Zb. Prav. Fak. Sveuc. Rij., 2020  HeinOnline;;"… 7 Narayanan i dr., Bitcoin and cryptocurrency technologies, 27-38 8 Narayanan i dr., Bitcoin and

cryptocurrency technologies, 27-3 8 9 Jacques Vos, Blockchain-based land registry: Panacea …

oracles) koji analiziraju podatke vanjskog svijeta i pohranjuju ih u blockchain …";Autres articles;;null;;;;https://scholar.google.com/scholar?start=450&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095323-1371;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Regulatory Trends in Blockchain Technologies;O Konashevych ; Available at SSRN 3749708, 2020  papers.ssrn.com;;"… A noticeable example of legalization through novel regulation is Japan, where they adopted

a statute law for crypto assets (Arora, 2020) … Cryptocurrency, as we concluded, is the blood

of a blockchain system, blockchain cannot exist without cryptocurrency …";;null;null;;;;https://scholar.google.com/scholar?start=170&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095369-1567;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Deniably authenticated searchable encryption scheme based on Blockchain for medical image data sharing;Y Zhang, L Wen, Y Zhang, C Wang ; Multimedia Tools and Applications, 2020  Springer;;"… (4) We prove that DASES has the ability to resist IKGA in random oracle model … After receiving

?, blockchain can verify whether equation e(sig, Q r ) = ? holds … Lemma 1 we assume that

adversary A ? exists, and A ? has ability to query H, H 1 oracles for most \( {q}_H,{q}_{H_1} \) …";Cité 1 fois;;null;;;;https://scholar.google.com/scholar?start=370&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095367-1560;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;[HTML][HTML] Mapping the potentials of blockchain in improving supply chain performance;LP Mahyuni, R Adrian, GS Darma… ; Cogent Business & …, 2020  cogentoa.com;;"… 2. Overview of technical terms. 2. Overview of technical terms. 2.1. Blockchain.

Blockchain is a novel technology rooted in cryptography which was first applied to

develop a cryptocurrency (bitcoin) (Nakamoto, 2008). Blockchain …";Cité 7 fois;Les 3 versions;[HTML] cogentoa.com;https://www.cogentoa.com/article/10.1080/23311975.2020.1788329;;;https://scholar.google.com/scholar?start=360&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095355-1512;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Towards Trusted Data on Decentralized IoT Applications: Integrating Blockchain in Constrained Devices;M Pincheira, M Vecchio ; 2020 IEEE International Conference …, 2020  ieeexplore.ieee.org;;"… providing a “root of trust” for the sense data. Moreover, a trusted source of information

not only benefits IoT systems but also other types of blockchain- based applications,

with sensing IoT devices acting as trusted oracles [13]. III …";Autres articles;;null;;;;https://scholar.google.com/scholar?start=310&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095362-1537;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;A review of quantum and hybrid quantum/classical blockchain protocols;M Edwards, A Mashatan, S Ghose ; Quantum Information Processing, 2020  Springer;;"… Coins are one of the primitive data structures required to formulate a cryptocurrency blockchain …

so some hash function-based commitment schemes are collapsing in the random oracle model …

This is an important issue specifically in the context of blockchain, since the intention …";Cité 2 fois;Les 4 versions;[PDF] arxiv.org;https://arxiv.org/pdf/1912.09280;;"""date"",""2019-12-20T01:37:41Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2019-12-20T01:37:41Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016) kpathsea version 6.2.2""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2019-12-20T01:37:41Z""
""created"",""2019-12-20T01:37:41Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-12-20T01:37:41Z""
""resourceName"",""1912.09280""
""Author"",""""
""producer"",""pdfTeX-1.40.17""
""pdf:docinfo:producer"",""pdfTeX-1.40.17""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""4"",""10"",""15"",""0"",""3"",""1"",""10"",""12"",""4"",""0"",""1"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2019-12-20T01:37:41Z""
""Last-Modified"",""2019-12-20T01:37:41Z""
""dcterms:modified"",""2019-12-20T01:37:41Z""
""title"",""""
""Last-Save-Date"",""2019-12-20T01:37:41Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2019-12-20T01:37:41Z""
""meta:save-date"",""2019-12-20T01:37:41Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016) kpathsea version 6.2.2""
""Content-Length"",""353336""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""27""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""419"",""2514"",""1703"",""2452"",""2502"",""2352"",""2068"",""1348"",""1737"",""1451"",""1357"",""1404"",""1940"",""1372"",""1258"",""1188"",""1973"",""1697"",""1115"",""2038"",""1749"",""2866"",""2889"",""494"",""2072"",""1887"",""1315""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-12-20T01:37:41Z""
";https://scholar.google.com/scholar?start=340&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095367-1561;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Blockchain-Based Corporate Governance;WA Kaal ; Stan. J. Blockchain L. & Pol'y, 2020  HeinOnline;;"… Well-designed DAOs can create oracles that allow the blockchain to interact with unvalidated …

40 Craig Calcaterra et al., Blockchain Infrastructure for Measuring Domain Specific Reputation

in Autonomous … 18-11), https://ssrn.com/abstract=3125822 (""An oracle for a blockchain is …";;null;null;;;;https://scholar.google.com/scholar?start=360&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095339-1442;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Blockchain-Enabled Cyber-Physical Systems: A Review;W Zhao, C Jiang, H Gao, S Yang… ; IEEE Internet of Things …, 2020  ieeexplore.ieee.org;;"… protection offered by blockchain also goes beyond the confidentiality property, which can be

guaranteed by encrypting the data in the transaction if one chooses to do so. Blockchains,

especially those platforms that use the UTXO model for cryptocurrency balance tracking such …";Cité 2 fois;;null;;;;https://scholar.google.com/scholar?start=240&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095285-1205;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Understanding the Blockchain Oracle Problem: A Call for Action;G Caldarelli ; Information, 2020  mdpi.com;;"Scarce and niche in the literature just a few years ago, the blockchain topic is now the main 
subject in conference papers and books. However, the hype generated by the technology 
and its potential implications for real-world applications is flawed by many misconceptions …";Cité 5 fois;Les 4 versions;[PDF] mdpi.com;https://www.mdpi.com/2078-2489/11/11/509/pdf;;;https://scholar.google.com/scholar?start=10&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095302-1277;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Performance Overhead of Atomic Crosschain Transactions;P Robinson ; 2020 IEEE Symposium on Computers and …, 2020  ieeexplore.ieee.org;;"… those used in traditional Ethereum transactions [1]. The addi- tional fields provide cross blockchain

context and … EXPERIMENTAL SETUP The performance of Hyperledger Besu version 1.4.4 with

native crypto enabled, with … Oracle Originating Transaction with Subordinate View …";Cité 1 fois;Les 6 versions;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/9213178/9219543/09219738.pdf?casa_token=C3zCyChasSQAAAAA:exEOHwJlCN-DjNjjxJWUxOVv3t116dt4QGm3f-YlI86DLwBbQC05FO5AFx8miy8-Y72p-vKpQP0;;"""og:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""twitter:title"",""Performance Overhead of Atomic Crosschain Transactions""
""twitter:card"",""summary""
""Description"",""Atomic Crosschain Transaction technology allows composable programming across permissioned Ethereum blockchains. It allows for inter-contract and inter-blockcha""
""og:title"",""Performance Overhead of Atomic Crosschain Transactions""
""resourceName"",""09219738.pdf""
""language"",""en""
""title"",""Performance Overhead of Atomic Crosschain Transactions | IEEE Conference Publication | IEEE Xplore""
""og:description"",""Atomic Crosschain Transaction technology allows composable programming across permissioned Ethereum blockchains. It allows for inter-contract and inter-blockchain function calls that are both synchronous and atomic: if one part fails, the whole call graph of function calls is rolled back. This paper analyses the processing overhead of using this technique compared to using multiple standard non-atomic single blockchain transactions. The additional processing is analysed for three scenarios involving multiple blockchains: the Hotel - Train problem, Supply Chain with Provenance, and an Oracle. The technology is shown to reduce the performance of Hyperledger Besu from 375 tps to 39.5 tps if all transactions are instigated on one node, or approaching 65.2 tps if the transactions are instigated on a variety of nodes, for the Hotel-Train scenario.""
""twitter:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-UA-Compatible"",""IE=Edge""
""viewport"",""width=device-width, initial-scale=1.0""
""dc:title"",""Performance Overhead of Atomic Crosschain Transactions | IEEE Conference Publication | IEEE Xplore""
""twitter:description"",""Atomic Crosschain Transaction technology allows composable programming across permissioned Ethereum blockchains. It allows for inter-contract and inter-blockchain function calls that are both synchronous and atomic: if one part fails, the whole call graph of function calls is rolled back. This paper analyses the processing overhead of using this technique compared to using multiple standard non-atomic single blockchain transactions. The additional processing is analysed for three scenarios involving multiple blockchains: the Hotel - Train problem, Supply Chain with Provenance, and an Oracle. The technology is shown to reduce the performance of Hyperledger Besu from 375 tps to 39.5 tps if all transactions are instigated on one node, or approaching 65.2 tps if the transactions are instigated on a variety of nodes, for the Hotel-Train scenario.""
""Content-Encoding"",""UTF-8""
""Content-Type-Hint"",""text/html; charset=utf-8""
""Content-Length"",""40058""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=80&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095399-1701;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;[PDF][PDF] Blockchain: Research and Applications;X Luo, Z Wang, W Cai, X Li, VCM Leung ; mypage.cuhk.edu.cn;;"… 1.3. Payment channel A payment channel is the technique designed to allow users

to make a series of off-chain payments. So, it can facilitate multiple cryptocurrency trades

without committing each of them to blockchain one by one …";;;[PDF] cuhk.edu.cn;https://mypage.cuhk.edu.cn/academics/caiwei/paper/papers/LuoCWLL2020.pdf;;"""date"",""2020-12-31T05:33:24Z""
""pdf:PDFVersion"",""1.7""
""xmp:CreatorTool"",""Elsevier""
""pdf:docinfo:title"",""Application and evaluation of payment channel in hybrid decentralized ethereum token exchange""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""Blockchain: Research and Applications, 1 (2020) 100001. doi:10.1016/j.bcra.2020.100001""
""language"",""en""
""dc:format"",""application/pdf; version=1.7""
""pdf:docinfo:custom:robots"",""noindex""
""pdf:docinfo:creator_tool"",""Elsevier""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""Application and evaluation of payment channel in hybrid decentralized ethereum token exchange""
""xmp:CreateDate"",""2020-12-31T11:02:35Z""
""modified"",""2020-12-31T05:33:24Z""
""cp:subject"",""Blockchain: Research and Applications, 1 (2020) 100001. doi:10.1016/j.bcra.2020.100001""
""robots"",""noindex""
""pdf:docinfo:custom:CrossMarkDomains[1]"",""sciencedirect.com""
""pdf:docinfo:subject"",""Blockchain: Research and Applications, 1 (2020) 100001. doi:10.1016/j.bcra.2020.100001""
""pdf:hasMarkedContent"",""true""
""xmp:ModifyDate"",""2020-12-31T11:03:24Z""
""pdf:docinfo:creator"",""Xuan Luo""
""meta:author"",""Xuan Luo"",""Zehua Wang"",""Wei Cai"",""Xiuhua Li"",""Victor C.M. Leung""
""meta:creation-date"",""2020-12-31T05:32:35Z""
""pdf:docinfo:custom:CrossmarkMajorVersionDate"",""2010-04-23""
""created"",""2020-12-31T05:32:35Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-12-31T05:32:35Z""
""resourceName"",""LuoCWLL2020.pdf""
""pdf:docinfo:custom:CrossMarkDomains[2]"",""elsevier.com""
""ElsevierWebPDFSpecifications"",""7.0""
""pdf:docinfo:custom:doi"",""10.1016/j.bcra.2020.100001""
""pdf:docinfo:custom:CrossmarkDomainExclusive"",""true""
""Author"",""Xuan Luo"",""Zehua Wang"",""Wei Cai"",""Xiuhua Li"",""Victor C.M. Leung""
""producer"",""Acrobat Distiller 8.1.0 (Windows)""
""CrossmarkDomainExclusive"",""true""
""pdf:docinfo:producer"",""Acrobat Distiller 8.1.0 (Windows)""
""doi"",""10.1016/j.bcra.2020.100001""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""6"",""0"",""10"",""1"",""5"",""4"",""13"",""80"",""16"",""10"",""3"",""3"",""0"",""0"",""7"",""0""
""dc:description"",""Blockchain: Research and Applications, 1 (2020) 100001. doi:10.1016/j.bcra.2020.100001""
""access_permission:modify_annotations"",""true""
""dc:creator"",""Xuan Luo"",""Zehua Wang"",""Wei Cai"",""Xiuhua Li"",""Victor C.M. Leung""
""description"",""Blockchain: Research and Applications, 1 (2020) 100001. doi:10.1016/j.bcra.2020.100001""
""dcterms:created"",""2020-12-31T05:32:35Z""
""Last-Modified"",""2020-12-31T05:33:24Z""
""dcterms:modified"",""2020-12-31T05:33:24Z""
""title"",""Application and evaluation of payment channel in hybrid decentralized ethereum token exchange""
""xmpMM:DocumentID"",""uuid:01a0f67e-16fc-409b-80e0-8cbc2f6305ef""
""Last-Save-Date"",""2020-12-31T05:33:24Z""
""CrossMarkDomains[1]"",""sciencedirect.com""
""pdf:docinfo:modified"",""2020-12-31T05:33:24Z""
""meta:save-date"",""2020-12-31T05:33:24Z""
""Content-Length"",""3910299""
""Content-Type"",""application/pdf""
""xmp:MetadataDate"",""2020-12-31T11:03:24Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Xuan Luo"",""Zehua Wang"",""Wei Cai"",""Xiuhua Li"",""Victor C.M. Leung""
""dc:language"",""en""
""pdf:producer"",""Acrobat Distiller 8.1.0 (Windows)""
""pdf:docinfo:custom:ElsevierWebPDFSpecifications"",""7.0""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""17""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""3665"",""6626"",""5067"",""5056"",""2827"",""5063"",""2250"",""5992"",""5126"",""5544"",""1934"",""4351"",""4354"",""2717"",""2690"",""5974"",""3176""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""CrossMarkDomains[2]"",""elsevier.com""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-12-31T05:32:35Z""
""CrossmarkMajorVersionDate"",""2010-04-23""
";https://scholar.google.com/scholar?start=500&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095369-1569;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Decentralized Incentive Mechanism for Cooperative Content Dissemination in Vehicular Networks;J Hu, C Chen, L Cai, L Liu ; GLOBECOM 20202020 IEEE …, 2020  ieeexplore.ieee.org;;"… Oracles provide a solution to obtain extrinsic information (ie, ”real- world” or off-chain) onto

the blockchain platform for smart contracts to execute [18]. Noted that Oracle can be regarded

as a useful tool but its details will not be described in this paper …";;null;null;;;;https://scholar.google.com/scholar?start=370&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095388-1651;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Cryptocurrency Constellations across the Three-Dimensional Space: Governance Decentralization, Security, and Scalability;P Febrero, J Pereira ; IEEE Transactions on Engineering …, 2020  ieeexplore.ieee.org;;"… 1.We ignore other technology dimensions such as communications protocols (Whisper), oracles,

like Chainlink and peer-to-peer version … can deploy dApps or decentralized applications over

the Ethereum protocol by paying a fee in its native blockchain cryptocurrency, Ether [13 …";Autres articles;;[PDF] whiterose.ac.uk;https://eprints.whiterose.ac.uk/166443/1/Febrero%20and%20Pereira%2C%202020%20-%20open%20source%20doc.pdf;;"""date"",""2020-12-12T09:32:25Z""
""pdf:PDFVersion"",""1.7""
""xmp:CreatorTool"",""MicrosoftÂŽ Word 2016""
""pdf:docinfo:title"",""Cryptocurrency Constellations across the Three-Dimensional Space: Governance Decentralization, Security, and Scalability""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""Blockchain technology, cryptocurrency protocols, decentralized governance, scalability, security"",""Blockchain technology, cryptocurrency protocols, decentralized governance, scalability, security""
""language"",""en""
""dc:format"",""application/pdf; version=1.7""
""pdf:docinfo:creator_tool"",""MicrosoftÂŽ Word 2016""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""Cryptocurrency Constellations across the Three-Dimensional Space: Governance Decentralization, Security, and Scalability""
""xmp:CreateDate"",""2020-12-12T09:32:25Z""
""modified"",""2020-12-12T09:32:25Z""
""pdf:hasMarkedContent"",""false""
""xmp:ModifyDate"",""2020-12-12T09:32:25Z""
""pdf:docinfo:creator"",""Febrero, P and Pereira, J""
""meta:author"",""Febrero, P and Pereira, J""
""meta:creation-date"",""2020-12-12T09:32:25Z""
""created"",""2020-12-12T09:32:25Z""
""xmp:About"",""uuid:7e35edd7-7479-11f6-0000-6acf3a45e07a""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-12-12T09:32:25Z""
""resourceName"",""Febrero%20and%20Pereira%2C%202020%20-%20open%20source%20doc.pdf""
""Author"",""Febrero, P and Pereira, J""
""producer"",""GPL Ghostscript 9.25""
""pdf:docinfo:producer"",""GPL Ghostscript 9.25""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""Keywords"",""Blockchain technology, cryptocurrency protocols, decentralized governance, scalability, security"",""Blockchain technology, cryptocurrency protocols, decentralized governance, scalability, security""
""access_permission:modify_annotations"",""true""
""dc:creator"",""Febrero, P and Pereira, J""
""dcterms:created"",""2020-12-12T09:32:25Z""
""Last-Modified"",""2020-12-12T09:32:25Z""
""dcterms:modified"",""2020-12-12T09:32:25Z""
""title"",""Cryptocurrency Constellations across the Three-Dimensional Space: Governance Decentralization, Security, and Scalability""
""xmpMM:DocumentID"",""uuid:7e35edd7-7479-11f6-0000-6acf3a45e07a""
""Last-Save-Date"",""2020-12-12T09:32:25Z""
""pdf:docinfo:keywords"",""Blockchain technology, cryptocurrency protocols, decentralized governance, scalability, security""
""pdf:docinfo:modified"",""2020-12-12T09:32:25Z""
""meta:save-date"",""2020-12-12T09:32:25Z""
""Content-Length"",""405519""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Febrero, P and Pereira, J""
""pdf:producer"",""GPL Ghostscript 9.25""
""dc:subject"",""Blockchain technology, cryptocurrency protocols, decentralized governance, scalability, security"",""Blockchain technology, cryptocurrency protocols, decentralized governance, scalability, security""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""40""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""1660"",""1210"",""2065"",""2139"",""2107"",""2198"",""1483"",""2128"",""2116"",""2224"",""2107"",""2087"",""2261"",""2272"",""2234"",""2215"",""2206"",""2194"",""2029"",""2127"",""2250"",""2296"",""1012"",""1760"",""2168"",""2246"",""2067"",""2038"",""2032"",""2123"",""2199"",""2110"",""2279"",""2172"",""2325"",""2789"",""2743"",""2733"",""2937"",""103""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""meta:keyword"",""Blockchain technology, cryptocurrency protocols, decentralized governance, scalability, security"",""Blockchain technology, cryptocurrency protocols, decentralized governance, scalability, security""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-12-12T09:32:25Z""
";https://scholar.google.com/scholar?start=450&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095381-1620;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Privacy-Preserving Blockchain-Based Data Sharing Platform for Decentralized Storage Systems;VH Hoang, E Lehtihet… ; 2020 IFIP Networking …, 2020  ieeexplore.ieee.org;;"… [17]. This scheme has been proven computationally efficient and secure in the random oracle

model. Second, this scheme is based on Discrete Logarithm (DL) assumption, making it

compatible with the current cryptosystem in the Ethereum blockchain and removing the need …";Cité 4 fois;Les 2 versions;[PDF] ifip.org;http://dl.ifip.org/db/conf/networking/networking2020/1570619958.pdf;;"""date"",""2020-07-06T23:28:46Z""
""pdf:PDFVersion"",""1.6""
""xmp:CreatorTool"",""Appligent StampPDF Batch 6.5""
""pdf:docinfo:title"",""Privacy-Preserving Blockchain-Based Data Sharing Platform for Decentralized Storage Systems""
""Appligent"",""StampPDF Batch 6.5 Linux 64 bit Jan 16 2017 Library APDFL10.1.0a""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""Xiaoming Fu, Silvia Giordano, Christian Jacquenet: 19th International IFIP TC6 Networking Conference, Networking 2020, Paris, France, June 22-25, 2020. IFIP Open Digital Library, IEEE Xplore""
""language"",""en""
""dc:format"",""application/pdf; version=1.6""
""pdf:docinfo:creator_tool"",""Appligent StampPDF Batch 6.5""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""Privacy-Preserving Blockchain-Based Data Sharing Platform for Decentralized Storage Systems""
""xmp:CreateDate"",""2020-04-30T15:57:46Z""
""modified"",""2020-07-06T23:28:46Z""
""cp:subject"",""Xiaoming Fu, Silvia Giordano, Christian Jacquenet: 19th International IFIP TC6 Networking Conference, Networking 2020, Paris, France, June 22-25, 2020. IFIP Open Digital Library, IEEE Xplore""
""pdf:docinfo:subject"",""Xiaoming Fu, Silvia Giordano, Christian Jacquenet: 19th International IFIP TC6 Networking Conference, Networking 2020, Paris, France, June 22-25, 2020. IFIP Open Digital Library, IEEE Xplore""
""pdf:hasMarkedContent"",""false""
""xmp:ModifyDate"",""2020-07-06T23:28:46Z""
""pdf:docinfo:creator"",""Van Hoan Hoang, Elyes Lehtihet, Yacine Ghamri-Doudane""
""PTEX.Fullbanner"",""This is MiKTeX-pdfTeX 2.9.6642 (1.40.19)""
""meta:author"",""Van Hoan Hoang, Elyes Lehtihet, Yacine Ghamri-Doudane""
""trapped"",""False""
""meta:creation-date"",""2020-04-30T13:57:46Z""
""created"",""2020-04-30T13:57:46Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-04-30T13:57:46Z""
""resourceName"",""1570619958.pdf""
""Author"",""Van Hoan Hoang, Elyes Lehtihet, Yacine Ghamri-Doudane""
""producer"",""MiKTeX pdfTeX-1.40.19""
""pdf:docinfo:producer"",""MiKTeX pdfTeX-1.40.19""
""Application"",""'Certified by IEEE PDFeXpress at 04/30/2020 7:00:02 AM'""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""2"",""12"",""4"",""0"",""0"",""0""
""access_permission:modify_annotations"",""true""
""dc:creator"",""Van Hoan Hoang, Elyes Lehtihet, Yacine Ghamri-Doudane""
""dcterms:created"",""2020-04-30T13:57:46Z""
""Last-Modified"",""2020-07-06T23:28:46Z""
""dcterms:modified"",""2020-07-06T23:28:46Z""
""pdf:docinfo:custom:Appligent"",""StampPDF Batch 6.5 Linux 64 bit Jan 16 2017 Library APDFL10.1.0a""
""title"",""Privacy-Preserving Blockchain-Based Data Sharing Platform for Decentralized Storage Systems""
""xmpMM:DocumentID"",""uuid:3ee138f2-c7ef-407c-94d3-8265fea77850""
""Last-Save-Date"",""2020-07-06T23:28:46Z""
""pdf:docinfo:modified"",""2020-07-06T23:28:46Z""
""meta:save-date"",""2020-07-06T23:28:46Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is MiKTeX-pdfTeX 2.9.6642 (1.40.19)""
""Content-Length"",""639290""
""pdf:docinfo:custom:Application"",""'Certified by IEEE PDFeXpress at 04/30/2020 7:00:02 AM'""
""Content-Type"",""application/pdf""
""xmp:MetadataDate"",""2020-07-06T23:28:46Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Van Hoan Hoang, Elyes Lehtihet, Yacine Ghamri-Doudane""
""pdf:producer"",""MiKTeX pdfTeX-1.40.19""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""9""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""4778"",""4802"",""4715"",""4859"",""4095"",""4548"",""4628"",""4573"",""5765""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-04-30T13:57:46Z""
";https://scholar.google.com/scholar?start=420&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095285-1209;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Real-world blockchain applications under the lens of the oracle problem. A systematic literature review;G Caldarelli ; 2020 IEEE International Conference on …, 2020  ieeexplore.ieee.org;;"As they have become leading topics of meetings, events and conferences, real-world 
blockchain applications have turned niche literature into a vast and complex plethora of 
books, articles and papers. Unlike digital payments, however, real-world applications are …";Cité 1 fois;;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/9380294/9380578/09380598.pdf?casa_token=ldxhRTWQtTcAAAAA:01Y-8vACLtZM2dUCrhjiQddEx7s0DYq49NW7EBiejcfD0GFj-iQagqN-q3IPqWMMizgzzcdmZAg;;"""og:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""twitter:title"",""Real-world blockchain applications under the lens of the oracle problem. A systematic literature review""
""twitter:card"",""summary""
""Description"",""As they have become leading topics of meetings, events and conferences, real-world blockchain applications have turned niche literature into a vast and complex ""
""og:title"",""Real-world blockchain applications under the lens of the oracle problem. A systematic literature review""
""resourceName"",""09380598.pdf""
""language"",""en""
""title"",""Real-world blockchain applications under the lens of the oracle problem. A systematic literature review | IEEE Conference Publication | IEEE Xplore""
""og:description"",""As they have become leading topics of meetings, events and conferences, real-world blockchain applications have turned niche literature into a vast and complex plethora of books, articles and papers. Unlike digital payments, however, real-world applications are dependent on oracles, whose roles and implications are often neglected in the literature. The presence of oracles negatively affects decentralization and trustless consensus, generating faulty thinking or overly positive expectations. This paper aims to enlighten the state of the art of real-world blockchain applications through a systematic literature review, exploiting the oracle problem as a lens of analysis. The results support the view that almost 90% of the inspected literature is biased or incomplete.""
""twitter:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-UA-Compatible"",""IE=Edge""
""viewport"",""width=device-width, initial-scale=1.0""
""dc:title"",""Real-world blockchain applications under the lens of the oracle problem. A systematic literature review | IEEE Conference Publication | IEEE Xplore""
""twitter:description"",""As they have become leading topics of meetings, events and conferences, real-world blockchain applications have turned niche literature into a vast and complex plethora of books, articles and papers. Unlike digital payments, however, real-world applications are dependent on oracles, whose roles and implications are often neglected in the literature. The presence of oracles negatively affects decentralization and trustless consensus, generating faulty thinking or overly positive expectations. This paper aims to enlighten the state of the art of real-world blockchain applications through a systematic literature review, exploiting the oracle problem as a lens of analysis. The results support the view that almost 90% of the inspected literature is biased or incomplete.""
""Content-Encoding"",""UTF-8""
""Content-Type-Hint"",""text/html; charset=utf-8""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=10&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095383-1630;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;[PDF][PDF] Deterministic Wallets in a Quantum World;NA Alkadri, P Das, A Erwig, S Faust, J Krämer, S Riahi… ; eprint.iacr.org;;"… Blockchain initiatives such as the ""Bitcoin Post-Quantum"" [Bit] and QRL [QRL] replace ECDSA

with hash … Unr15] is an important tool for security proofs in the quantum random oracle model …

different random oracles when the adversary is allowed to query them in superposition …";Autres articles;Version HTML;[PDF] iacr.org;https://eprint.iacr.org/2020/1149.pdf;;"""date"",""2020-09-21T12:53:01Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""Deterministic Wallets in a Quantum World""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""Deterministic Wallets in a Quantum World""
""modified"",""2020-09-21T12:53:01Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""Nabil Alkeilani Alkadri""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016/Debian) kpathsea version 6.2.2""
""meta:author"",""Nabil Alkeilani Alkadri""
""trapped"",""False""
""meta:creation-date"",""2020-09-21T12:53:01Z""
""created"",""2020-09-21T12:53:01Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-09-21T12:53:01Z""
""resourceName"",""1149.pdf""
""Author"",""Nabil Alkeilani Alkadri""
""producer"",""pdfTeX-1.40.17""
""pdf:docinfo:producer"",""pdfTeX-1.40.17""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""2"",""2"",""3"",""0"",""26"",""16"",""34"",""7"",""13"",""13"",""4"",""5"",""1"",""2"",""23"",""14"",""11"",""17"",""22"",""38"",""31"",""13"",""3"",""0"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""Nabil Alkeilani Alkadri""
""dcterms:created"",""2020-09-21T12:53:01Z""
""Last-Modified"",""2020-09-21T12:53:01Z""
""dcterms:modified"",""2020-09-21T12:53:01Z""
""title"",""Deterministic Wallets in a Quantum World""
""Last-Save-Date"",""2020-09-21T12:53:01Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2020-09-21T12:53:01Z""
""meta:save-date"",""2020-09-21T12:53:01Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016/Debian) kpathsea version 6.2.2""
""Content-Length"",""731740""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Nabil Alkeilani Alkadri""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""27""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""2907"",""3969"",""3013"",""3794"",""3816"",""3010"",""2295"",""2230"",""2564"",""2592"",""2770"",""2329"",""2479"",""2683"",""3347"",""3032"",""3303"",""3067"",""2266"",""2630"",""2216"",""2181"",""3429"",""3139"",""3170"",""3726"",""3890""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-09-21T12:53:01Z""
";https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095330-1395;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;[PDF][PDF] Blockchain for Aerospace and Defense: Opportunities and Open Research Challenges;RW Ahmada, H Hasana, I Yaqooba, K Salaha… ; researchgate.net;;"… blockchain. Hardware oracles directly interact with hardware devices, such as RFID

chips and IoT sensors to supply verified data points to the blockchain. An inbound

oracle provides external world data to a smart contract. For …";Autres articles;Version HTML;[PDF] researchgate.net;https://www.researchgate.net/profile/Raja_Jayaraman/publication/345830528_Blockchain_for_Aerospace_and_Defense_Opportunities_and_Open_Research_Challenges/links/5fafcd9792851cf24cce2ac0/Blockchain-for-Aerospace-and-Defense-Opportunities-and-Open-Research-Challenges.pdf;;;https://scholar.google.com/scholar?start=200&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095381-1622;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;LOKI Vote: A Blockchain-Based Coercion Resistant E-Voting Protocol;M Chaieb, S Yousfi ; … , Mediterranean, and Middle Eastern Conference on …, 2020  Springer;;"… EMCIS 2020: Information Systems pp 151-168 | Cite as. LOKI Vote: A Blockchain-Based

Coercion Resistant E-Voting Protocol … Our paper fills the gap and proposes an

end-to-end verifiable e-voting protocol based on Blockchain technology …";Autres articles;;[PDF] researchgate.net;https://www.researchgate.net/profile/Chaieb_Marwa/publication/348716403_LOKI_Vote_A_Blockchain-based_Coercion_Resistant_E-voting_Protocol/links/600c70b9a6fdccdcb877154b/LOKI-Vote-A-Blockchain-based-Coercion-Resistant-E-voting-Protocol.pdf;;;https://scholar.google.com/scholar?start=420&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095351-1490;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Towards a Contract Service Provider Model for Virtual Assets and VASPs;T Hardjono, A Lipton, A Pentland ; arXiv preprint arXiv:2009.07413, 2020  arxiv.org;;"… (c) Node diversity principle: A contract service blockchain network must employ a diverse

node-technology implementations and be owned/operated by a diverse set of providers. (d)

Mediated oracle principle: Any representation of value that originates from outside the contract …";Cité 2 fois;Les 2 versions;[PDF] arxiv.org;https://arxiv.org/pdf/2009.07413;;"""date"",""2020-12-08T04:25:46Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""A Contract Service Provider Model for Virtual Assets""
""xmp:CreatorTool"",""LaTeX with acmart 2020/04/30 v1.71 Typesetting articles for the Association for Computing Machinery and hyperref 2020-05-15 v7.00e Hypertext links for LaTeX""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with acmart 2020/04/30 v1.71 Typesetting articles for the Association for Computing Machinery and hyperref 2020-05-15 v7.00e Hypertext links for LaTeX""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""A Contract Service Provider Model for Virtual Assets""
""modified"",""2020-12-08T04:25:46Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""Thomas Hardjono, Alexander Lipton, and Alex Pentland""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.21 (TeX Live 2020) kpathsea version 6.3.2""
""meta:author"",""Thomas Hardjono, Alexander Lipton, and Alex Pentland""
""trapped"",""False""
""meta:creation-date"",""2020-12-08T04:25:46Z""
""created"",""2020-12-08T04:25:46Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-12-08T04:25:46Z""
""resourceName"",""2009.07413""
""Author"",""Thomas Hardjono, Alexander Lipton, and Alex Pentland""
""producer"",""pdfTeX-1.40.21""
""pdf:docinfo:producer"",""pdfTeX-1.40.21""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""Keywords"",""Blockchains, FaaS, smart contracts, virtual assets, contract service providers, contract domains""
""access_permission:modify_annotations"",""true""
""dc:creator"",""Thomas Hardjono, Alexander Lipton, and Alex Pentland""
""dcterms:created"",""2020-12-08T04:25:46Z""
""Last-Modified"",""2020-12-08T04:25:46Z""
""dcterms:modified"",""2020-12-08T04:25:46Z""
""title"",""A Contract Service Provider Model for Virtual Assets""
""Last-Save-Date"",""2020-12-08T04:25:46Z""
""pdf:docinfo:keywords"",""Blockchains, FaaS, smart contracts, virtual assets, contract service providers, contract domains""
""pdf:docinfo:modified"",""2020-12-08T04:25:46Z""
""meta:save-date"",""2020-12-08T04:25:46Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.21 (TeX Live 2020) kpathsea version 6.3.2""
""Content-Length"",""1175914""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Thomas Hardjono, Alexander Lipton, and Alex Pentland""
""dc:language"",""en""
""dc:subject"",""Blockchains, FaaS, smart contracts, virtual assets, contract service providers, contract domains""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""13""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""3315"",""1960"",""3080"",""3409"",""2121"",""3406"",""2083"",""1812"",""3314"",""3410"",""2024"",""4324"",""1498""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""Blockchains, FaaS, smart contracts, virtual assets, contract service providers, contract domains""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-12-08T04:25:46Z""
";https://scholar.google.com/scholar?start=290&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095362-1536;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;The Theory of Hash Functions and Random Oracles;A Mittelbach, M Fischlin ; Springer;;"… techniques used with random oracles, random oracle constructions as well as examples of

real-world random oracle schemes but also limitations of random oracles and a discussion of

the random oracle controversy, the fact that uninstantiable schemes exist which are provably …";;null;null;;;;https://scholar.google.com/scholar?start=340&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095353-1496;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;[LIVRE][B] Blockchain Consortiums-A Comprehensive Handbook;V Singhi, M Chitlur, S Mahankali ;2020 books.google.com;;"… Prior to his MBA, he worked as a technology professional, primarily implementing Oracle's suite

of products mainly ERP software and Relational database technologies … Most people who have

heard of Blockchain associate it with the Bitcoin cryptocurrency …";Autres articles;;null;;;;https://scholar.google.com/scholar?start=300&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095351-1485;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;[HTML][HTML] Trust Execution Environment and Multi-party Computation for Blockchain e-Health Systems;F Yahmed, M Abid ; International Conference on Smart Homes and Health …, 2020  Springer;;"… The first cryptocurrency based on a Blockchain was Bitcoin in 2008 [7], however the Blockchain

has evolved to meet and serve a variety of purposes … Moudoud, H., Cherkaoui, S., Khoukhi, L.:

An IoT blockchain architecture using oracles and smart contracts: the use …";Autres articles;;[HTML] springer.com;https://link.springer.com/chapter/10.1007/978-3-030-51517-1_24;;;https://scholar.google.com/scholar?start=290&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095367-1556;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;[PDF][PDF] Reputation Driven Dynamic Access Control Framework for IoT atop PoA Ethereum Blockchain;AH Lonea, R Naaza ; eprint.iacr.org;;"… PoA is the specific type of PoS, in which individual's identity is at stake rather

than cryptocurrency … Authors in [28] proposed a decentralized access control

mechanism for IoT data using blockchain and trusted oracles …";Autres articles;Version HTML;[PDF] iacr.org;https://eprint.iacr.org/2020/566.pdf;;"""date"",""2021-02-21T06:20:13Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""3"",""0"",""1"",""0"",""0"",""0"",""0"",""0"",""2"",""3"",""8"",""5"",""11"",""4"",""5"",""6"",""2"",""4"",""2"",""13"",""2"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.5""
""xmp:CreatorTool"",""TeX""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dcterms:created"",""2021-02-21T06:20:13Z""
""language"",""en""
""Last-Modified"",""2021-02-21T06:20:13Z""
""dcterms:modified"",""2021-02-21T06:20:13Z""
""dc:format"",""application/pdf; version=1.5""
""Last-Save-Date"",""2021-02-21T06:20:13Z""
""pdf:docinfo:creator_tool"",""TeX""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2021-02-21T06:20:13Z""
""meta:save-date"",""2021-02-21T06:20:13Z""
""pdf:encrypted"",""false""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is MiKTeX-pdfTeX 4.0.1 (1.40.21)""
""modified"",""2021-02-21T06:20:13Z""
""Content-Length"",""2276671""
""pdf:hasMarkedContent"",""false""
""Content-Type"",""application/pdf""
""PTEX.Fullbanner"",""This is MiKTeX-pdfTeX 4.0.1 (1.40.21)""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""trapped"",""False""
""meta:creation-date"",""2021-02-21T06:20:13Z""
""created"",""2021-02-21T06:20:13Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""38""
""Creation-Date"",""2021-02-21T06:20:13Z""
""resourceName"",""566.pdf""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""1702"",""1927"",""1846"",""2097"",""2304"",""2000"",""1920"",""1910"",""2429"",""1970"",""39"",""1876"",""1709"",""1128"",""1145"",""1421"",""1511"",""1652"",""1707"",""1656"",""1117"",""1466"",""1710"",""1555"",""46"",""32"",""934"",""1289"",""1408"",""554"",""1880"",""2061"",""689"",""784"",""1579"",""1640"",""1700"",""998""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""producer"",""MiKTeX pdfTeX-1.40.21""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""MiKTeX pdfTeX-1.40.21""
""pdf:docinfo:created"",""2021-02-21T06:20:13Z""
";https://scholar.google.com/scholar?start=360&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095330-1403;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Is code law? Current legal and technical adoption issues and remedies for blockchain-enabled smart contracts;D Drummer, D Neumann ; Journal of Information Technology, 2020  journals.sagepub.com;;"… Download article citation data for: Is code law? Current legal and technical adoption issues and

remedies for blockchain-enabled smart contracts. Daniel Drummer and Dirk Neumann. Journal

of Information Technology 0 10.1177/0268396220924669. Download Citation …";Cité 4 fois;;null;;;;https://scholar.google.com/scholar?start=200&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095325-1375;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Long-term verification of signatures based on a blockchain;T Hyla, J Peja? ; Computers & Electrical Engineering, 2020  Elsevier;;"… Transaction Validity, Tamper Evidence, Finality). Alternatively, the scheme can be

used with permissionless blockchain (cryptocurrency), but it will provide lower overall

security level. Instead of Finality property the Probabilistic …";Cité 6 fois;Les 2 versions;null;;;;https://scholar.google.com/scholar?start=180&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095402-1710;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Blockchain Application in Information Systems Research;O Labazova ;2020 kups.ub.unikoeln.de;;"Page 1. BLOCKCHAIN APPLICATION IN INFORMATION SYSTEMS RESEARCH

Inauguraldissertation zur Erlangung des Doktorgrades der … Tag der Promotion: June 3rd, 2020

Page 3. Blockchain Application in Information Systems Research 3 ACKNOWLEDGEMENTS …";Les 2 versions;Version HTML;[PDF] uni-koeln.de;https://kups.ub.uni-koeln.de/30072/1/dissertation_labazova.pdf;;;https://scholar.google.com/scholar?start=510&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095323-1372;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Detecting Blockchain Security Threats;B Putz, G Pernul ; … Conference on Blockchain (Blockchain), 2020  ieeexplore.ieee.org;;"… Periodic API requests to a node on the anchoring target blockchain can provide the required

data. • Oracles: Oracles provide external data to smart contracts. If an oracle is manipulated or

compromised the conse- quences can be severe for the relying contract …";Cité 1 fois;Les 4 versions;[PDF] uni-regensburg.de;https://epub.uni-regensburg.de/43942/1/AcceptedManuscript.pdf;;"""date"",""2020-10-01T12:29:25Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.5""
""xmp:CreatorTool"",""TeX""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dcterms:created"",""2020-10-01T12:29:25Z""
""language"",""en""
""Last-Modified"",""2020-10-01T12:29:25Z""
""dcterms:modified"",""2020-10-01T12:29:25Z""
""dc:format"",""application/pdf; version=1.5""
""Last-Save-Date"",""2020-10-01T12:29:25Z""
""pdf:docinfo:creator_tool"",""TeX""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2020-10-01T12:29:25Z""
""meta:save-date"",""2020-10-01T12:29:25Z""
""pdf:encrypted"",""false""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is MiKTeX-pdfTeX 4.0.1 (1.40.21)""
""modified"",""2020-10-01T12:29:25Z""
""Content-Length"",""255866""
""pdf:hasMarkedContent"",""false""
""Content-Type"",""application/pdf""
""PTEX.Fullbanner"",""This is MiKTeX-pdfTeX 4.0.1 (1.40.21)""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""trapped"",""False""
""meta:creation-date"",""2020-10-01T12:29:25Z""
""created"",""2020-10-01T12:29:25Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""8""
""Creation-Date"",""2020-10-01T12:29:25Z""
""resourceName"",""AcceptedManuscript.pdf""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""3962"",""3923"",""5259"",""4256"",""4255"",""4591"",""4555"",""6292""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""producer"",""MiKTeX pdfTeX-1.40.21""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""MiKTeX pdfTeX-1.40.21""
""pdf:docinfo:created"",""2020-10-01T12:29:25Z""
";https://scholar.google.com/scholar?start=170&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095341-1445;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Smart Contracts in the Automotive Industry;O Hornyák, GF Alkhoury ; Vehicle and Automotive Engineering, 2020  Springer;;"… The software oracle obtains the required information automatically by API calls and inserts the

data into the … Using oracles – as discussed earlier … Mondragon, AEC, Mondragon, CEC, Coronado,

ES: Exploring the applicability of blockchain technology to enhance manufacturing …";Autres articles;;null;;;;https://scholar.google.com/scholar?start=250&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095358-1523;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;[PDF][PDF] Discreet Log Contracts Channels and Integration in the Lightning Network;I Kuwahara, T Le Guilly, T Nakagawa ; cointhinktank.com;;"… While putting a minimum amount of trust into oracles is unavoidable (assuming that they … trust

each others to establish financial contracts directly on the Bitcoin blockchain without requiring …

indirect interaction increases the privacy of the contracting parties as the oracle need not …";Autres articles;Version HTML;[PDF] cointhinktank.com;https://cointhinktank.com/upload/offchaindlc.pdf;;"""date"",""2020-04-27T04:22:51Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2020-04-27T04:22:51Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.20 (TeX Live 2019) kpathsea version 6.3.1""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2020-04-27T04:22:51Z""
""created"",""2020-04-27T04:22:51Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-04-27T04:22:51Z""
""resourceName"",""offchaindlc.pdf""
""Author"",""""
""producer"",""pdfTeX-1.40.20""
""pdf:docinfo:producer"",""pdfTeX-1.40.20""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2020-04-27T04:22:51Z""
""Last-Modified"",""2020-04-27T04:22:51Z""
""dcterms:modified"",""2020-04-27T04:22:51Z""
""title"",""""
""Last-Save-Date"",""2020-04-27T04:22:51Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2020-04-27T04:22:51Z""
""meta:save-date"",""2020-04-27T04:22:51Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.20 (TeX Live 2019) kpathsea version 6.3.1""
""Content-Length"",""231145""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""9""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""4276"",""4650"",""4467"",""4646"",""1756"",""4792"",""2355"",""3415"",""158""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-04-27T04:22:51Z""
";https://scholar.google.com/scholar?start=320&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095390-1661;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Hybrid-Trusted Party Contract Agrees on Clients Input;A Alruwaili, D Kruger ; 2020 IEEE 3rd 5G World Forum (5GWF), 2020  ieeexplore.ieee.org;;"… Wang, H. Lu, X. Sun, Y. Yuan and F. Wang, ""A Novel Blockchain Oracle Implementation Scheme

Based on Application Specific Knowledge Engines,"" 2019 IEEE International Conference on

Service Operations and Logistics, and Informatics (SOLI), Zhengzhou, China, 2019, pp …";Autres articles;;null;;;;https://scholar.google.com/scholar?start=460&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095311-1320;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;[HTML][HTML] A secure blockchain-based e-health records storage and sharing scheme;S Shamshad, K Mahmood, S Kumari… ; Journal of Information …, 2020  Elsevier;;"… Highlights. • A blockchain based eHealth records storing and sharing scheme for

telemedicine environment. • … The robustness of the designed protocol is verified

and validated through real or random oracle model. Abstract …";Cité 7 fois;Les 2 versions;[HTML] sciencedirect.com;https://www.sciencedirect.com/science/article/pii/S2214212620307596?casa_token=XGyko2Mz2aMAAAAA:mPtaAcsmh5eYaENFY-SIHZ1SiA24f9-E2JuAe5h30eMVTRJF4oSigxSrY8qHDzRS5chRa9mo;;;https://scholar.google.com/scholar?start=120&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095313-1331;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Blockchain Interoperability with Cross-chain Stablecoin Payments;RB Pandhi ;2020 repository.lib.fit.edu;;"… that are native to the stellar chain [23]. Taking the case of retail stablecoins, perhaps the most

prominent crypto news … faced by blockchain [41]. The research towards a blockchain-interoperable …

asset portability [38], cross-chain oracles [39], and atomic swap [38] …";Cité 1 fois;Les 2 versions;[PDF] fit.edu;https://repository.lib.fit.edu/bitstream/handle/11141/3124/PANDHI-THESIS-2020.pdf;;"""date"",""2020-04-28T14:01:35Z""
""pdf:PDFVersion"",""1.7""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""pdfa:PDFVersion"",""A-2b""
""language"",""en""
""dc:format"",""application/pdf; version=""""A-2b"""""",""application/pdf; version=1.7""
""pdf:docinfo:creator_tool"",""""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""xmp:CreateDate"",""2020-04-28T14:01:35Z""
""modified"",""2020-04-28T14:01:35Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""xmp:ModifyDate"",""2020-04-28T14:01:35Z""
""pdf:docinfo:creator"",""""
""meta:author"",""""
""meta:creation-date"",""2020-04-28T14:01:35Z""
""created"",""2020-04-28T14:01:35Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-04-28T14:01:35Z""
""resourceName"",""PANDHI-THESIS-2020.pdf""
""pdfaid:part"",""2""
""Author"",""""
""producer"",""Skia/PDF m84""
""pdf:docinfo:producer"",""Skia/PDF m84""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2020-04-28T14:01:35Z""
""Last-Modified"",""2020-04-28T14:01:35Z""
""dcterms:modified"",""2020-04-28T14:01:35Z""
""title"",""""
""Last-Save-Date"",""2020-04-28T14:01:35Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2020-04-28T14:01:35Z""
""meta:save-date"",""2020-04-28T14:01:35Z""
""Content-Length"",""1182784""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""pdfaid:conformance"",""B""
""pdf:producer"",""Skia/PDF m84""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""65""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""333"",""736"",""1334"",""1122"",""1149"",""764"",""1622"",""2004"",""1470"",""724"",""863"",""511"",""1422"",""1743"",""1921"",""951"",""1819"",""1736"",""1682"",""1345"",""1436"",""1404"",""1871"",""1655"",""1333"",""1317"",""1695"",""203"",""1258"",""1116"",""1582"",""1488"",""1105"",""1461"",""624"",""1850"",""1739"",""343"",""1482"",""1756"",""1005"",""914"",""204"",""740"",""1038"",""679"",""1531"",""1447"",""1328"",""816"",""887"",""895"",""400"",""457"",""814"",""719"",""1266"",""1392"",""1469"",""1456"",""1639"",""1791"",""1545"",""1386"",""182""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-04-28T14:01:35Z""
";https://scholar.google.com/scholar?start=130&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095395-1678;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;?????? ?? ????????? ?????????????? ?? ??????????????? ???????? ?????????? BLOCKCHAIN;S Obushnyi, R Kravchenko… ; ???????????? …, 2020  journal.eae.com.ua;;"… Oracle ledger, contain decentralized data, secure, shared … permanently added as a new “block”

at the end of the “chain” [39] The original Blockchain is open … source technology which offers an

alternative to the traditional intermediary for transfers of the crypto- currency Bitcoin [38 …";;;[PDF] eae.com.ua;https://journal.eae.com.ua/index.php/journal/article/download/92/83;;"""date"",""2021-01-26T21:15:17Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.5""
""xmp:CreatorTool"",""MicrosoftÂŽ Word 2016""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dc:creator"",""User""
""language"",""en""
""dcterms:created"",""2021-01-26T21:15:17Z""
""Last-Modified"",""2021-01-26T21:15:17Z""
""dcterms:modified"",""2021-01-26T21:15:17Z""
""dc:format"",""application/pdf; version=1.5""
""Last-Save-Date"",""2021-01-26T21:15:17Z""
""pdf:docinfo:creator_tool"",""MicrosoftÂŽ Word 2016""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2021-01-26T21:15:17Z""
""meta:save-date"",""2021-01-26T21:15:17Z""
""pdf:encrypted"",""false""
""modified"",""2021-01-26T21:15:17Z""
""Content-Length"",""1012019""
""pdf:hasMarkedContent"",""true""
""Content-Type"",""application/pdf""
""pdf:docinfo:creator"",""User""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""User""
""dc:language"",""en-US""
""meta:author"",""User""
""meta:creation-date"",""2021-01-26T21:15:17Z""
""created"",""2021-01-26T21:15:17Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""23""
""Creation-Date"",""2021-01-26T21:15:17Z""
""resourceName"",""83""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""2912"",""3612"",""3403"",""3713"",""1818"",""1719"",""1963"",""1833"",""1833"",""1892"",""1755"",""2982"",""3898"",""2342"",""1939"",""2014"",""3187"",""4142"",""4679"",""4962"",""2356"",""2740"",""889""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""Author"",""User""
""producer"",""www.ilovepdf.com""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""www.ilovepdf.com""
""pdf:docinfo:created"",""2021-01-26T21:15:17Z""
";https://scholar.google.com/scholar?start=480&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095292-1236;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Auditing the Blockchain Oracle ProblemAuditing the Blockchain Oracle Problem;MD Sheldon ; Journal of Information Systems  meridian.allenpress.com;;"Blockchain brought about the potential for improved data reliability, but only when that data 
is the result of transactions that happen completely within a blockchain. The reliability 
ofblockchain data is threatened when information is introduced from the outside world, such …";Autres articles;;null;;;;https://scholar.google.com/scholar?start=40&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095371-1579;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Towards a New Generation of Permissioned Blockchain Systems;C Gorenflo ;2020 uwspace.uwaterloo.ca;;"… While Bitcoin has been designed for the sole purpose of handling cryptocurrency, trans- ferring

digital coin from one owner to another, Ethereum introduced smart contracts [117]. With the help

of these replicated multi-purpose computations, blockchain technology can truly be …";Cité 2 fois;;[PDF] uwaterloo.ca;https://uwspace.uwaterloo.ca/bitstream/handle/10012/15860/Gorenflo_Christian.pdf?sequence=3;;"""date"",""2020-05-14T20:04:33Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""Towards a New Generation of Permissioned Blockchain Systems""
""xmp:CreatorTool"",""LaTeX with hyperref""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""Permissioned blockchain systems""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""Towards a New Generation of Permissioned Blockchain Systems""
""modified"",""2020-05-14T20:04:33Z""
""cp:subject"",""Permissioned blockchain systems""
""pdf:docinfo:subject"",""Permissioned blockchain systems""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""Christian Gorenflo""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.19 (TeX Live 2018) kpathsea version 6.3.0""
""meta:author"",""Christian Gorenflo""
""trapped"",""False""
""meta:creation-date"",""2020-05-14T20:04:33Z""
""created"",""2020-05-14T20:04:33Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-05-14T20:04:33Z""
""resourceName"",""Gorenflo_Christian.pdf""
""Author"",""Christian Gorenflo""
""producer"",""pdfTeX-1.40.19""
""pdf:docinfo:producer"",""pdfTeX-1.40.19""
""pdf:unmappedUnicodeCharsPerPage"",""1"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""3"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""2"",""0"",""0"",""0"",""0"",""0"",""0"",""2"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""5"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""2"",""0"",""0"",""0"",""0"",""1"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""1"",""0"",""1"",""3"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""5"",""6"",""0"",""0"",""6"",""0"",""0"",""0"",""8"",""2"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""Christian Gorenflo""
""dcterms:created"",""2020-05-14T20:04:33Z""
""Last-Modified"",""2020-05-14T20:04:33Z""
""dcterms:modified"",""2020-05-14T20:04:33Z""
""title"",""Towards a New Generation of Permissioned Blockchain Systems""
""Last-Save-Date"",""2020-05-14T20:04:33Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2020-05-14T20:04:33Z""
""meta:save-date"",""2020-05-14T20:04:33Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.19 (TeX Live 2018) kpathsea version 6.3.0""
""Content-Length"",""2954432""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Christian Gorenflo""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""164""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""244"",""646"",""221"",""2536"",""2236"",""799"",""1407"",""1241"",""1420"",""673"",""1231"",""2022"",""1430"",""371"",""1788"",""2638"",""1963"",""2149"",""2224"",""2233"",""2165"",""2163"",""2480"",""2082"",""2401"",""703"",""781"",""1846"",""1376"",""2204"",""2254"",""2181"",""2267"",""2552"",""1818"",""1271"",""1113"",""1397"",""2392"",""2251"",""271"",""1928"",""1239"",""2308"",""2141"",""2373"",""2082"",""2017"",""1014"",""2612"",""985"",""2142"",""1806"",""2069"",""1108"",""2147"",""1368"",""2119"",""2297"",""2766"",""1587"",""1829"",""483"",""1804"",""998"",""1007"",""958"",""2192"",""763"",""906"",""1628"",""1081"",""798"",""977"",""1027"",""1278"",""1652"",""1175"",""2386"",""101"",""2287"",""2451"",""333"",""1116"",""1544"",""2189"",""1881"",""1643"",""218"",""1723"",""2240"",""2123"",""2473"",""708"",""1102"",""2343"",""1125"",""2341"",""2204"",""1591"",""1123"",""2529"",""2708"",""1003"",""2168"",""2411"",""2326"",""2041"",""2288"",""1890"",""2281"",""2523"",""2328"",""2665"",""1773"",""1482"",""1491"",""1228"",""2422"",""1776"",""1553"",""1708"",""2635"",""1964"",""1198"",""2286"",""2282"",""2209"",""1050"",""667"",""1533"",""2261"",""2271"",""325"",""1675"",""2005"",""1850"",""1650"",""2352"",""1168"",""2482"",""387"",""2350"",""2056"",""2113"",""2457"",""2680"",""1963"",""2003"",""647"",""1388"",""2424"",""2057"",""1437"",""1922"",""2060"",""1961"",""1687"",""2119"",""1876"",""2058"",""1862"",""2047"",""1429""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-05-14T20:04:33Z""
";https://scholar.google.com/scholar?start=380&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095406-1725;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Designated-verifier proof of assets for bitcoin exchange using elliptic curve cryptography;H Wang, D He, Y Ji ; Future Generation Computer Systems, 2020  Elsevier;;"… keys s i and public keys P u b i where the corresponding address A d d r i belongs to S , ie, A

d d r i ? S . For the bitcoin, the address is the hash value of the corresponding public key on

the blockchain … C answers these queries on behalf of the different oracles … Hash-oracle …";Cité 41 fois;Les 3 versions;null;;;;https://scholar.google.com/scholar?start=530&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095374-1592;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Machine Learning with Blockchain for Secure E-voting System;MA Cheema, N Ashraf, A Aftab… ; … Conference of Smart …, 2020  ieeexplore.ieee.org;;"… 161, p. 105976, 2020. [Online]. Available: http://www.sciencedirect.com/science/article/

pii/S0020019020300636 [14] SK Lo, X. Xu, M. Staples, and L. Yao, “Reliability analysis for

blockchain oracles,” Computers and Electrical Engineering, vol. 83, p. 106582, 2020. [Online] …";Autres articles;;null;;;;https://scholar.google.com/scholar?start=390&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095406-1733;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;[PDF][PDF] Digitales Immobiliendossier auf der Blockchain im Kontext der technischen und ökonomischen Herausforderungen der Schweizer Assekuranz;WR Günter, R Iten, C Pugnetti, L Stricker, H Weber ;2020 srvclst301;;"… Sicherheit) sind diese Oracles von besonderer Relevanz für den Dezentralitätsgedanken

von Blockchain-basierten Smart Contracts. Die oben-beschriebenen Konzepte zu P2P,

Spieltheorie und Kryptographie schaffen konsequent Dezentralität …";Autres articles;;[PDF] zhaw.ch;https://srv-clst-301-data66.zhaw.ch/bitstream/11475/20572/3/2020_Guenter-etal_Digitales-Immobiliendossier-Blockchain.pdf;;"""date"",""2020-10-08T07:02:44Z""
""pdf:PDFVersion"",""1.6""
""xmp:CreatorTool"",""Acrobat PDFMaker 20 fĂźr Word""
""pdf:docinfo:title"",""Digitales Immobiliendossier auf der Blockchain im Kontext der technischen und Ăśkonomischen Herausforderungen der Schweizer Assekuranz""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""pdfa:PDFVersion"",""A-2b""
""xmpMM:History:Action"",""converted""
""language"",""de""
""dc:format"",""application/pdf; version=""""A-2b"""""",""application/pdf; version=1.6""
""pdf:docinfo:creator_tool"",""Acrobat PDFMaker 20 fĂźr Word""
""access_permission:fill_in_form"",""true""
""xmpMM:History:When"",""2020-10-08T09:02:44Z""
""pdf:encrypted"",""false""
""dc:title"",""Digitales Immobiliendossier auf der Blockchain im Kontext der technischen und Ăśkonomischen Herausforderungen der Schweizer Assekuranz""
""xmp:CreateDate"",""2020-09-28T20:53:07Z""
""modified"",""2020-10-08T07:02:44Z""
""xmpMM:History:SoftwareAgent"",""Preflight""
""pdf:hasMarkedContent"",""true""
""xmpMM:History:InstanceID"",""uuid:c59e2936-f6ef-46b4-bd6c-1692db5e34ce""
""xmp:ModifyDate"",""2020-10-08T09:02:44Z""
""pdf:docinfo:creator"",""Rolf W. GĂźnter, Raphael Iten, Carlo Pugnetti, Lukas Stricker, Hanspeter Weber""
""meta:author"",""Rolf W. GĂźnter, Raphael Iten, Carlo Pugnetti, Lukas Stricker, Hanspeter Weber""
""meta:creation-date"",""2020-09-28T18:53:07Z""
""created"",""2020-09-28T18:53:07Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-09-28T18:53:07Z""
""resourceName"",""2020_Guenter-etal_Digitales-Immobiliendossier-Blockchain.pdf""
""pdfaid:part"",""2""
""Author"",""Rolf W. GĂźnter, Raphael Iten, Carlo Pugnetti, Lukas Stricker, Hanspeter Weber""
""producer"",""Adobe PDF Library 20.12.80""
""pdf:docinfo:producer"",""Adobe PDF Library 20.12.80""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""access_permission:modify_annotations"",""true""
""dc:creator"",""Rolf W. GĂźnter, Raphael Iten, Carlo Pugnetti, Lukas Stricker, Hanspeter Weber""
""dcterms:created"",""2020-09-28T18:53:07Z""
""Last-Modified"",""2020-10-08T07:02:44Z""
""dcterms:modified"",""2020-10-08T07:02:44Z""
""title"",""Digitales Immobiliendossier auf der Blockchain im Kontext der technischen und Ăśkonomischen Herausforderungen der Schweizer Assekuranz""
""xmpMM:DocumentID"",""uuid:9d28bb7b-ad7b-42e4-bbee-04b99b967414""
""Last-Save-Date"",""2020-10-08T07:02:44Z""
""pdf:docinfo:modified"",""2020-10-08T07:02:44Z""
""meta:save-date"",""2020-10-08T07:02:44Z""
""Content-Length"",""750288""
""Content-Type"",""application/pdf""
""xmp:MetadataDate"",""2020-10-08T09:02:44Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Rolf W. GĂźnter, Raphael Iten, Carlo Pugnetti, Lukas Stricker, Hanspeter Weber""
""pdfaid:conformance"",""B""
""dc:language"",""DE-CH""
""pdf:producer"",""Adobe PDF Library 20.12.80""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""30""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""340"",""505"",""1214"",""757"",""2688"",""3532"",""1320"",""2190"",""2962"",""3000"",""3764"",""2072"",""3582"",""3702"",""3235"",""3786"",""3802"",""3564"",""4155"",""864"",""3483"",""4734"",""2411"",""1782"",""2263"",""2321"",""2279"",""2093"",""334"",""107""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-09-28T18:53:07Z""
";https://scholar.google.com/scholar?start=530&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095406-1727;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;[LIVRE][B] Blockchain Technology in Healthcare;G Thirumurugan ;2020 books.google.com;;"… For example, Coinbase, the world's largest cryptocurrency exchange, defines blockchain as

“a distributed, public ledger that contains the history of every bitcoin transaction” [4]. As an

application-specific definition, this characterization does not account for the fact that …";Autres articles;;null;;;;https://scholar.google.com/scholar?start=530&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095339-1435;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Rethinking IoT security: a protocol based on blockchain smart contracts for secure and automated IoT deployments;J Wickström, M Westerlund, G Pulkkis ; arXiv preprint arXiv:2007.02652, 2020  arxiv.org;;"… special tasks or fetch information that is not inherently avail- able to the blockchain validator … can

via a function call to the smart contracts under which the oracle operates, ask … Although oracles

may introduce certain logic ambiguity and a centralized point of failure, we will further …";Cité 1 fois;Les 2 versions;[PDF] arxiv.org;https://arxiv.org/pdf/2007.02652;;"""date"",""2020-07-07T01:22:03Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2020-07-07T01:22:03Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016) kpathsea version 6.2.2""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2020-07-07T01:22:03Z""
""created"",""2020-07-07T01:22:03Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-07-07T01:22:03Z""
""resourceName"",""2007.02652""
""Author"",""""
""producer"",""pdfTeX-1.40.17""
""pdf:docinfo:producer"",""pdfTeX-1.40.17""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2020-07-07T01:22:03Z""
""Last-Modified"",""2020-07-07T01:22:03Z""
""dcterms:modified"",""2020-07-07T01:22:03Z""
""title"",""""
""Last-Save-Date"",""2020-07-07T01:22:03Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2020-07-07T01:22:03Z""
""meta:save-date"",""2020-07-07T01:22:03Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016) kpathsea version 6.2.2""
""Content-Length"",""197990""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""8""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""4311"",""5392"",""5436"",""3119"",""3217"",""4133"",""4864"",""6684""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-07-07T01:22:03Z""
";https://scholar.google.com/scholar?start=240&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095351-1493;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;[CITATION][C] Formal Verification of Anti-cheating Protocols in Cryptoeconomic Systems;SJ Lewis ;2020;;null;Autres articles;;null;;;;https://scholar.google.com/scholar?start=290&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095376-1602;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;PPM: a provenance-provided data sharing model for open banking via blockchain;Z Xu, Q Wang, Z Wang, D Liu, Y Xiang… ; Proceedings of the …, 2020  dl.acm.org;;"… Connected with smart contract: – Step1: The user sends a registered query to the smart con-

tract. The contract is run inside blockchain oracle as a state transition. When received the query,

it will first check whether the user existed in the list. If not, add it into the list …";Cité 2 fois;Les 3 versions;[PDF] researchgate.net;https://www.researchgate.net/profile/Qin_Wang37/publication/338928027_PPM_A_Provenance-Provided_Data_Sharing_Model_for_Open_Banking_via_Blockchain/links/5e5a85de92851cefa1d1cda7/PPM-A-Provenance-Provided-Data-Sharing-Model-for-Open-Banking-via-Blockchain.pdf;;;https://scholar.google.com/scholar?start=400&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095406-1731;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;[PDF][PDF] BLOCKCHAIN POTENTIALS IN ENHANCING CONSTRUCTION STAKEHOLDERS COLLABORATION;KC Goh, TYTHH Goh, K Bilal, CS Chai ; … RESEARCH JOURNAL (MCRJ)  cream.my;;"… Reduced users' privacy Autonomous code is “candy for hackers” Need to rely to external oracles

No intermediary to contact in case of loss of users' credentials Volatility of cryptocurrencies

Requires mastering technical skills like programming and blockchain concepts External …";Cité 1 fois;Les 4 versions;[PDF] cream.my;https://www.cream.my/my/media/com_eshop/attachments/MCRJ%20SI%20Vol%207%20No.2%202019.pdf#page=190;;"""date"",""2020-01-09T02:48:13Z""
""pdf:PDFVersion"",""1.7""
""xmp:CreatorTool"",""MicrosoftÂŽ Word for Office 365""
""pdf:docinfo:title"",""CONSTRUCTION RESEARCH INSTITUTE OF MALAYSIA (CREAM)""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""language"",""en""
""dc:format"",""application/pdf; version=1.7""
""pdf:docinfo:creator_tool"",""MicrosoftÂŽ Word for Office 365""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""CONSTRUCTION RESEARCH INSTITUTE OF MALAYSIA (CREAM)""
""xmp:CreateDate"",""2020-01-09T10:48:13Z""
""modified"",""2020-01-09T02:48:13Z""
""pdf:hasMarkedContent"",""true""
""xmp:ModifyDate"",""2020-01-09T10:48:13Z""
""pdf:docinfo:creator"",""CREAM""
""meta:author"",""CREAM""
""meta:creation-date"",""2020-01-09T02:48:13Z""
""created"",""2020-01-09T02:48:13Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-01-09T02:48:13Z""
""resourceName"",""MCRJ%20SI%20Vol%207%20No.2%202019.pdf""
""Author"",""CREAM""
""producer"",""MicrosoftÂŽ Word for Office 365""
""pdf:docinfo:producer"",""MicrosoftÂŽ Word for Office 365""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""access_permission:modify_annotations"",""true""
""dc:creator"",""CREAM""
""dcterms:created"",""2020-01-09T02:48:13Z""
""Last-Modified"",""2020-01-09T02:48:13Z""
""dcterms:modified"",""2020-01-09T02:48:13Z""
""title"",""CONSTRUCTION RESEARCH INSTITUTE OF MALAYSIA (CREAM)""
""xmpMM:DocumentID"",""uuid:DA228A74-C165-4BDC-A00A-9821122B5A69""
""Last-Save-Date"",""2020-01-09T02:48:13Z""
""pdf:docinfo:modified"",""2020-01-09T02:48:13Z""
""meta:save-date"",""2020-01-09T02:48:13Z""
""Content-Length"",""3530269""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""CREAM""
""dc:language"",""en-US""
""pdf:producer"",""MicrosoftÂŽ Word for Office 365""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""207""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""5"",""372"",""1611"",""1896"",""1724"",""2318"",""3372"",""3866"",""3800"",""3965"",""4014"",""4127"",""1924"",""3535"",""3844"",""2655"",""3069"",""3260"",""2923"",""3537"",""3572"",""3751"",""3792"",""3589"",""1002"",""3254"",""415"",""3455"",""3196"",""2919"",""2380"",""3109"",""3764"",""3294"",""2992"",""3396"",""3476"",""3542"",""3509"",""3277"",""3102"",""3527"",""718"",""3879"",""3342"",""3471"",""3199"",""3642"",""1141"",""2604"",""2366"",""3104"",""3106"",""3555"",""3257"",""3058"",""3303"",""1093"",""3432"",""2886"",""3276"",""2052"",""2660"",""2232"",""2586"",""1674"",""2827"",""3066"",""3275"",""1656"",""3564"",""3293"",""3173"",""1940"",""3307"",""3546"",""2531"",""2899"",""3764"",""3677"",""3344"",""2764"",""2978"",""3399"",""3027"",""842"",""3388"",""3477"",""3699"",""3556"",""2007"",""2557"",""2509"",""3707"",""3770"",""1965"",""2230"",""2545"",""2390"",""2118"",""3548"",""2356"",""2621"",""3889"",""2278"",""2164"",""3292"",""3413"",""3511"",""3701"",""1499"",""1993"",""1807"",""3146"",""3053"",""606"",""3485"",""3690"",""2236"",""2072"",""2570"",""2267"",""2635"",""2272"",""2072"",""1363"",""2986"",""1937"",""1457"",""3141"",""2868"",""3216"",""3003"",""3474"",""3387"",""497"",""3294"",""3625"",""3446"",""3846"",""4007"",""3409"",""2321"",""2088"",""3461"",""3202"",""3369"",""3867"",""1964"",""3662"",""3870"",""3727"",""3547"",""1623"",""1804"",""3444"",""2791"",""3477"",""3768"",""3590"",""2366"",""1034"",""1831"",""3124"",""1536"",""3551"",""2832"",""2865"",""2686"",""2742"",""3331"",""2740"",""2011"",""2859"",""2712"",""2749"",""3380"",""898"",""3734"",""3669"",""3702"",""4045"",""3177"",""3417"",""1550"",""3030"",""3425"",""3574"",""1542"",""3715"",""3933"",""3392"",""3855"",""3410"",""3087"",""2992"",""2090"",""2294"",""2885"",""3447"",""3359"",""1093"",""3138"",""2702"",""3274"",""2929"",""53""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-01-09T02:48:13Z""
";https://scholar.google.com/scholar?start=530&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095285-1208;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;A distributed oracle using intel SGX for blockchain-based IoT applications;S Woo, J Song, S Park ; Sensors, 2020  mdpi.com;;"A blockchain oracle problem is a problem that defines a mechanism for how to safely bring 
external data to the blockchain. Although there have been various research efforts to solve 
this problem, existing solutions are limited in that they do not support either data availability …";Cité 4 fois;Les 8 versions;[PDF] mdpi.com;https://www.mdpi.com/1424-8220/20/9/2725/pdf;;;https://scholar.google.com/scholar?start=10&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095360-1529;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Deterministic Wallets in a Quantum World;N Alkeilani Alkadri, P Das, A Erwig, S Faust… ; Proceedings of the …, 2020  dl.acm.org;;"… that sent money to the same wallet are unlinkable despite being publicly available on the

blockchain … x,y??? |x,y ? H(x)?. In our proofs we will also consider reprogrammed random

oracles. For a random oracle H we write Hx?y for the random oracle that is reprogrammed on …";Autres articles;;null;;;;https://scholar.google.com/scholar?start=330&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095309-1307;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Open Platform Concept for Blockchain-Enabled Crowdsourcing of Technology Development and Supply Chains;J Ducrée, M Gravitt, R Walshe, S Bartling… ; … in Blockchain, 2020  ueaeprints.uea.ac.uk;;"… Having its origin in the first popular cryptocurrency Bitcoin launched by the famous white … Opinions

of investors on the solidity and prospects of “crypto” tend to largely diverge … A broad range of

commercial projects on advancing blockchain technologies are driven by companies …";Cité 2 fois;Les 5 versions;[PDF] uea.ac.uk;https://ueaeprints.uea.ac.uk/id/eprint/77010/7/Published_Version.pdf;;"""date"",""2020-11-13T07:23:20Z""
""pdf:PDFVersion"",""1.6""
""xmp:CreatorTool"",""LaTeX with hyperref package + hypdvips""
""pdf:docinfo:title"",""Open Platform Concept for Blockchain-Enabled Crowdsourcing of Technology Development and Supply Chains""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""We outline the concept of an open technology platform that builds upon a publicly accessible library of fluidic designs, manufacturing processes, and experimental characterization, as well as virtualization by a ``digital twin'' based on modeling, simulation, and cloud computing.""
""language"",""en""
""dc:format"",""application/pdf; version=1.6""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package + hypdvips""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""Open Platform Concept for Blockchain-Enabled Crowdsourcing of Technology Development and Supply Chains""
""xmp:CreateDate"",""2020-11-13T11:29:54Z""
""modified"",""2020-11-13T07:23:20Z""
""cp:subject"",""We outline the concept of an open technology platform that builds upon a publicly accessible library of fluidic designs, manufacturing processes, and experimental characterization, as well as virtualization by a ``digital twin'' based on modeling, simulation, and cloud computing.""
""pdf:docinfo:subject"",""We outline the concept of an open technology platform that builds upon a publicly accessible library of fluidic designs, manufacturing processes, and experimental characterization, as well as virtualization by a ``digital twin'' based on modeling, simulation, and cloud computing.""
""pdf:hasMarkedContent"",""false""
""xmp:ModifyDate"",""2020-11-13T12:53:20Z""
""pdf:docinfo:creator"",""Jens Ducrée""
""meta:author"",""Jens Ducrée""
""meta:creation-date"",""2020-11-13T05:59:54Z""
""created"",""2020-11-13T05:59:54Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-11-13T05:59:54Z""
""resourceName"",""Published_Version.pdf""
""Author"",""Jens Ducrée""
""producer"",""dvips + MiKTeX GPL Ghostscript  9.0""
""pdf:docinfo:producer"",""dvips + MiKTeX GPL Ghostscript  9.0""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""dc:description"",""We outline the concept of an open technology platform that builds upon a publicly accessible library of fluidic designs, manufacturing processes, and experimental characterization, as well as virtualization by a ``digital twin'' based on modeling, simulation, and cloud computing.""
""Keywords"",""technology platform, supply chain, value creation, crowdsourcing, competitive parallelisation, microfluidics, validation"",""technology platform, supply chain, value creation, crowdsourcing, competitive parallelisation, microfluidics, validation""
""access_permission:modify_annotations"",""true""
""dc:creator"",""Jens Ducrée""
""description"",""We outline the concept of an open technology platform that builds upon a publicly accessible library of fluidic designs, manufacturing processes, and experimental characterization, as well as virtualization by a ``digital twin'' based on modeling, simulation, and cloud computing.""
""dcterms:created"",""2020-11-13T05:59:54Z""
""Last-Modified"",""2020-11-13T07:23:20Z""
""dcterms:modified"",""2020-11-13T07:23:20Z""
""title"",""Open Platform Concept for Blockchain-Enabled Crowdsourcing of Technology Development and Supply Chains""
""xmpMM:DocumentID"",""uuid:18f31951-bbb7-45d0-bec3-ef6b1a7cb561""
""Last-Save-Date"",""2020-11-13T07:23:20Z""
""pdf:docinfo:keywords"",""technology platform, supply chain, value creation, crowdsourcing, competitive parallelisation, microfluidics, validation""
""pdf:docinfo:modified"",""2020-11-13T07:23:20Z""
""meta:save-date"",""2020-11-13T07:23:20Z""
""Content-Length"",""1504579""
""Content-Type"",""application/pdf""
""xmp:MetadataDate"",""2020-11-13T12:53:20Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Jens Ducrée""
""dc:language"",""en""
""pdf:producer"",""dvips + MiKTeX GPL Ghostscript  9.0""
""dc:subject"",""technology platform, supply chain, value creation, crowdsourcing, competitive parallelisation, microfluidics, validation"",""technology platform, supply chain, value creation, crowdsourcing, competitive parallelisation, microfluidics, validation""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""13""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""3570"",""5828"",""5562"",""3978"",""3758"",""5670"",""3016"",""4332"",""2906"",""5872"",""6247"",""7807"",""6665""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""meta:keyword"",""technology platform, supply chain, value creation, crowdsourcing, competitive parallelisation, microfluidics, validation"",""technology platform, supply chain, value creation, crowdsourcing, competitive parallelisation, microfluidics, validation""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-11-13T05:59:54Z""
";https://scholar.google.com/scholar?start=110&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095288-1219;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Are the gas prices oracle reliable? a case study using the ethgasstation;GA Pierro, H Rocha, R Tonelli… ; … Workshop on Blockchain …, 2020  ieeexplore.ieee.org;;"The Ethereum Blockchain is a distributed database that records all transactions and smart-
contracts created on the platform. In Ethereum blockchain, the user needs to set a Gas price 
to get a transaction recorded. To have the transaction recorded, the Gas price has to be …";Cité 5 fois;Les 3 versions;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/9040368/9050160/09050186.pdf?casa_token=URTlOgLr6zQAAAAA:iIu03af7C1sMS23AFuRSttajZB6GJV9_Un4qbg71-VHQkzN8uQYvIuA73y4w4F4qKOsAlNrwXWk;;"""og:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""twitter:title"",""Are the Gas Prices Oracle Reliable? A Case Study using the EthGasStation""
""twitter:card"",""summary""
""Description"",""The Ethereum Blockchain is a distributed database that records all transactions and smart-contracts created on the platform. In Ethereum blockchain, the user ne""
""og:title"",""Are the Gas Prices Oracle Reliable? A Case Study using the EthGasStation""
""resourceName"",""09050186.pdf""
""language"",""en""
""title"",""Are the Gas Prices Oracle Reliable? A Case Study using the EthGasStation | IEEE Conference Publication | IEEE Xplore""
""og:description"",""The Ethereum Blockchain is a distributed database that records all transactions and smart-contracts created on the platform. In Ethereum blockchain, the user needs to set a Gas price to get a transaction recorded. To have the transaction recorded, the Gas price has to be greater than or equal to the lowest Ethereum transaction fees. To help the users and smart contracts to set the right Gas price, the Gas Oracle categorizes the gas price into categories based on the interval of time the user might be willing to wait and for each of them suggests a gas price to set. The paper aims to verify the hypothesis that the predictions made by the EtherGasStation Oracle have a margin of error greater than the margin of error declared by it (2 %). We collected data in two-months time from the EthGasStation Oracle which predict the Gas Price every time that 100 blocks are added to the Ethereum Blockchain. In the same time frame, two-months, we also collected over 10 million transactions from a Transaction Pool. By cross-checking the data collected by the Transaction Pool and the Gas Oracle, the study revealed that the Gas Oracle fails more often than it advertises.""
""twitter:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-UA-Compatible"",""IE=Edge""
""viewport"",""width=device-width, initial-scale=1.0""
""dc:title"",""Are the Gas Prices Oracle Reliable? A Case Study using the EthGasStation | IEEE Conference Publication | IEEE Xplore""
""twitter:description"",""The Ethereum Blockchain is a distributed database that records all transactions and smart-contracts created on the platform. In Ethereum blockchain, the user needs to set a Gas price to get a transaction recorded. To have the transaction recorded, the Gas price has to be greater than or equal to the lowest Ethereum transaction fees. To help the users and smart contracts to set the right Gas price, the Gas Oracle categorizes the gas price into categories based on the interval of time the user might be willing to wait and for each of them suggests a gas price to set. The paper aims to verify the hypothesis that the predictions made by the EtherGasStation Oracle have a margin of error greater than the margin of error declared by it (2 %). We collected data in two-months time from the EthGasStation Oracle which predict the Gas Price every time that 100 blocks are added to the Ethereum Blockchain. In the same time frame, two-months, we also collected over 10 million transactions from a Transaction Pool. By cross-checking the data collected by the Transaction Pool and the Gas Oracle, the study revealed that the Gas Oracle fails more often than it advertises.""
""Content-Encoding"",""UTF-8""
""Content-Type-Hint"",""text/html; charset=utf-8""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=20&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095395-1676;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Modeling and Analysis of Market Blockchain-based Data Trading in NB-IoT Networks;LD Nguyen, I Leyva;Mayorga, AN Lewis…  arXiv preprint arXiv …, 2020  arxiv.org;;"… In [12], Missier et al. propose another marketplace, where streams of IoT data are the main

assets traded utilizing Oracles for the off-chain queries. Xiong et al … The efficiency of a

Blockchain-based data trading protocol is a major concern for data traders …";Autres articles;;[PDF] arxiv.org;https://arxiv.org/pdf/2010.06003;;"""date"",""2020-12-22T04:12:19Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2020-12-22T04:12:19Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.21 (TeX Live 2020) kpathsea version 6.3.2""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2020-12-22T04:12:19Z""
""created"",""2020-12-22T04:12:19Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-12-22T04:12:19Z""
""resourceName"",""2010.06003""
""Author"",""""
""producer"",""pdfTeX-1.40.21""
""pdf:docinfo:producer"",""pdfTeX-1.40.21""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""6"",""5"",""6"",""2"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2020-12-22T04:12:19Z""
""Last-Modified"",""2020-12-22T04:12:19Z""
""dcterms:modified"",""2020-12-22T04:12:19Z""
""title"",""""
""Last-Save-Date"",""2020-12-22T04:12:19Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2020-12-22T04:12:19Z""
""meta:save-date"",""2020-12-22T04:12:19Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.21 (TeX Live 2020) kpathsea version 6.3.2""
""Content-Length"",""1798941""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""10""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""5128"",""5510"",""4438"",""4801"",""3650"",""4413"",""3718"",""3285"",""3740"",""4970""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-12-22T04:12:19Z""
";https://scholar.google.com/scholar?start=480&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095395-1682;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;[PDF][PDF] A Survey on Electronic Health Records using Blockchain with Attribute-based Signature Scheme;NM Chhodvadiya, KM Rakholiya, VB Bhuvani… ;2020 academia.edu;;"… System for Secure Data Storage with Private Keyword Search”[9] In this paper, introduces a system

that uses Blockchain technology to … n?) threshold predicate and provides a flexible

threshold-ABS scheme that realizes this approach and secure with the help of random oracles …";Autres articles;;[PDF] academia.edu;https://www.academia.edu/download/64556026/IRJET-V7I5198.pdf;;;https://scholar.google.com/scholar?start=480&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095376-1594;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Implications of blockchain distributed ledger technology for records management and information governance programs;PC Franks ; Records Management Journal, 2020  emerald.com;;"… If the information necessary to trigger the contract is located outside the blockchain network (ie

off-chain), an oracle as shown in Figure 3 can be … Medicalchain is the first medical practice in the

UK to use blockchain technology and to accept cryptocurrency (MedTokens) as …";Cité 3 fois;Les 2 versions;[PDF] researchgate.net;https://www.researchgate.net/profile/Patricia_Franks/publication/339391344_Implications_of_blockchain_distributed_ledger_technology_for_records_management_and_information_governance_programs/links/5efcb23c92851c52d60cc88a/Implications-of-blockchain-distributed-ledger-technology-for-records-management-and-information-governance-programs.pdf;;;https://scholar.google.com/scholar?start=400&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095406-1729;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Research on consensus mechanism optimization for IoT blockchain;S Qijie, C Tieming, C Yuan, MA Dongjie… ; Telecommunications …  infocommjournal.com;;"… Key words: blockchain, IoT, consensus mechanism, DAG, intelligent enhancement,

lightweight password … Ouroboros[21] 2017 ? ? <1/2 ???? ? Cardno PoA[22](Proof

of Activity) 2014 ? ? <1/2 ???? ? ?????? Oracles Network …";Autres articles;Version HTML;[PDF] infocomm-journal.com;http://www.infocomm-journal.com/dxkx/EN/article/downloadArticleFile.do?attachType=PDF&id=170244;;;https://scholar.google.com/scholar?start=530&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095304-1289;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Research on Trusted Identification of Blockchain Uploaded Data;S Wang, X Yu ; 2020 IEEE International Conference on Artificial …, 2020  ieeexplore.ieee.org;;"… oracle the network has a majority voting decision to ensure that the blockchain introduces external …

Dynamic evaluation proposes a new oracle network and a decision of majority voting. The number

of voting assets for constructing oracles must exceed 55%, and the number of …";Autres articles;;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/9169742/9181849/09181948.pdf?casa_token=baqo4HCu7WcAAAAA:fqVByeJsOdoWW8SHnaArhbntCv6lpX0n3gBBt2ccDsk8eV6XlBr9WsywsGks28wouoit03yeJOI;;"""og:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""twitter:title"",""Research on Trusted Identification of Blockchain Uploaded Data""
""twitter:card"",""summary""
""Description"",""Due to its decentralized feature, blockchain system makes it difficult to connect blockchain with the Internet, which makes the application environment of block""
""og:title"",""Research on Trusted Identification of Blockchain Uploaded Data""
""resourceName"",""09181948.pdf""
""language"",""en""
""title"",""Research on Trusted Identification of Blockchain Uploaded Data | IEEE Conference Publication | IEEE Xplore""
""og:description"",""Due to its decentralized feature, blockchain system makes it difficult to connect blockchain with the Internet, which makes the application environment of blockchain limited, especially when the smart contract requires external data trigger. Among the existing solutions, many of them do not consider the security and credibility of the Blockchain upload data. This is contrary to the original intention of the blockchain system. To solve this problem, this paper proposes a trusted data recognition scheme based on machine learning model. This makes the data on the chain more secure and reliable.""
""twitter:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-UA-Compatible"",""IE=Edge""
""viewport"",""width=device-width, initial-scale=1.0""
""dc:title"",""Research on Trusted Identification of Blockchain Uploaded Data | IEEE Conference Publication | IEEE Xplore""
""twitter:description"",""Due to its decentralized feature, blockchain system makes it difficult to connect blockchain with the Internet, which makes the application environment of blockchain limited, especially when the smart contract requires external data trigger. Among the existing solutions, many of them do not consider the security and credibility of the Blockchain upload data. This is contrary to the original intention of the blockchain system. To solve this problem, this paper proposes a trusted data recognition scheme based on machine learning model. This makes the data on the chain more secure and reliable.""
""Content-Encoding"",""UTF-8""
""Content-Type-Hint"",""text/html; charset=utf-8""
""Content-Length"",""39512""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=90&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095288-1221;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;No Trade in a Blockchain;S Galanis ; Available at SSRN, 2020  papers.ssrn.com;;"… However, because users of the blockchain are anonymous, nothing stops oracles from

participating in the trade … What matters is whether oracles learn the value of the security before

or after the trade is … An insider could play the role of the oracle, thus facilitating the trade, but also …";Autres articles;;null;;;;https://scholar.google.com/scholar?start=20&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095320-1363;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Graviton: interchain swaps and wrapped tokens liquidity incentivisation solution;A Pupyshev, I Sapranidi, E Dzhafarov… ; arXiv preprint arXiv …, 2020  arxiv.org;;"… decentralized trustless gateways, as well as gateways based on oracle networks and threshold

signatures … Interoperability between different blockchain platforms is an important goal, and its

achievement can create and sustain a major network effect on the entire crypto …";Cité 1 fois;Les 2 versions;[PDF] arxiv.org;https://arxiv.org/pdf/2009.05540;;"""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.5""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""8""
""resourceName"",""2009.05540""
""language"",""en""
""pdf:hasXMP"",""false""
""dc:format"",""application/pdf; version=1.5""
""pdf:charsPerPage"",""1178"",""2606"",""2233"",""1959"",""1325"",""2377"",""1761"",""715""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""producer"",""Skia/PDF m87""
""Content-Length"",""148035""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""Skia/PDF m87""
""pdf:hasMarkedContent"",""false""
""Content-Type"",""application/pdf""
";https://scholar.google.com/scholar?start=160&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095378-1606;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Blockchain Technology for Food Security? Resilience Potential and Risk Identification for the Multilateral System of the International Treaty on Plant Genetic …;T Gils, C Frison ; Resilience Potential and Risk Identification for the …, 2020  papers.ssrn.com;;"… global-cryptocurrency-benchmarking-study.pdf> accessed 31 July 2020. Page 3. 3 … Consequently,

one still needs sources that produce authentic data (so-called 'oracles').54 In other words, even

with blockchain, parties will still need to trust certain institutions …";Les 2 versions;;null;;;;https://scholar.google.com/scholar?start=410&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095346-1470;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Autenticaçăo de Oráculos em um Blockchain usando Contexto Físico como Segundo Fator de Autenticaçăo;WSM Junior, LFR da Costa Carmo ; … do III Workshop em Blockchain …, 2020  sol.sbc.org.br;;"… takes advantage of in- formation from the physical world to identify an oracle based on … Our re-

sults demonstrate that our proposal makes oracles' authentication more robust, since it … entidades

que proveem informaç˜ao do mundo externo para smart contracts em um blockchain …";Autres articles;;[PDF] sbc.org.br;https://sol.sbc.org.br/index.php/wblockchain/article/download/12431/12296;;"""date"",""2020-05-25T19:47:53Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""4"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.5""
""xmp:CreatorTool"",""TeX""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dcterms:created"",""2020-05-25T19:47:53Z""
""language"",""pt""
""Last-Modified"",""2020-05-25T19:47:53Z""
""dcterms:modified"",""2020-05-25T19:47:53Z""
""dc:format"",""application/pdf; version=1.5""
""Last-Save-Date"",""2020-05-25T19:47:53Z""
""pdf:docinfo:creator_tool"",""TeX""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2020-05-25T19:47:53Z""
""meta:save-date"",""2020-05-25T19:47:53Z""
""pdf:encrypted"",""false""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017) kpathsea version 6.2.3""
""modified"",""2020-05-25T19:47:53Z""
""Content-Length"",""465831""
""pdf:hasMarkedContent"",""false""
""Content-Type"",""application/pdf""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017) kpathsea version 6.2.3""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""trapped"",""False""
""meta:creation-date"",""2020-05-25T19:47:53Z""
""created"",""2020-05-25T19:47:53Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""14""
""Creation-Date"",""2020-05-25T19:47:53Z""
""resourceName"",""12296""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""2566"",""3293"",""2946"",""3010"",""2768"",""2160"",""2968"",""2058"",""3126"",""2820"",""1426"",""2455"",""2510"",""2063""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""producer"",""pdfTeX-1.40.18""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""pdfTeX-1.40.18""
""pdf:docinfo:created"",""2020-05-25T19:47:53Z""
";https://scholar.google.com/scholar?start=270&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095330-1398;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Blockchain: Technology and Emerging Use Cases;R Dahal ;2020 theseus.fi;;"… The re- search will look at the other implementation like decentralized applications, oracle network …

from the data provider website and through the use of blockchain explorer … more at its challenges

and advantages compared to the traditional single source oracles. Page 6. 3 …";Autres articles;;[PDF] theseus.fi;https://www.theseus.fi/bitstream/handle/10024/334523/Thesis_Rashik_Dahal_Final.pdf?sequence=2;;"""date"",""2020-02-18T02:18:56Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.7""
""xmp:CreatorTool"",""MicrosoftÂŽ Word for Office 365""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dc:creator"",""OpinnäytetyÜohjeryhmä""
""language"",""en""
""dcterms:created"",""2020-02-18T02:18:56Z""
""Last-Modified"",""2020-02-18T02:18:56Z""
""dcterms:modified"",""2020-02-18T02:18:56Z""
""dc:format"",""application/pdf; version=1.7""
""xmpMM:DocumentID"",""uuid:0C30B94B-2034-40AE-BC31-B7E41319ED5C""
""Last-Save-Date"",""2020-02-18T02:18:56Z""
""pdf:docinfo:creator_tool"",""MicrosoftÂŽ Word for Office 365""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2020-02-18T02:18:56Z""
""meta:save-date"",""2020-02-18T02:18:56Z""
""pdf:encrypted"",""false""
""xmp:CreateDate"",""2020-02-18T04:18:56Z""
""modified"",""2020-02-18T02:18:56Z""
""Content-Length"",""1019491""
""pdf:hasMarkedContent"",""true""
""Content-Type"",""application/pdf""
""xmp:ModifyDate"",""2020-02-18T04:18:56Z""
""pdf:docinfo:creator"",""OpinnäytetyÜohjeryhmä""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""OpinnäytetyÜohjeryhmä""
""dc:language"",""en-GB""
""meta:author"",""OpinnäytetyÜohjeryhmä""
""pdf:producer"",""MicrosoftÂŽ Word for Office 365""
""meta:creation-date"",""2020-02-18T02:18:56Z""
""created"",""2020-02-18T02:18:56Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""41""
""Creation-Date"",""2020-02-18T02:18:56Z""
""resourceName"",""Thesis_Rashik_Dahal_Final.pdf""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""183"",""1919"",""4246"",""2327"",""2012"",""2731"",""2971"",""2109"",""2004"",""1703"",""1182"",""1808"",""2201"",""1900"",""2576"",""1416"",""2076"",""2270"",""2203"",""2442"",""1876"",""1833"",""840"",""984"",""1041"",""890"",""1283"",""1309"",""846"",""2739"",""3023"",""2454"",""3045"",""2476"",""2235"",""2404"",""2032"",""1676"",""2004"",""141"",""9""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""Author"",""OpinnäytetyÜohjeryhmä""
""producer"",""MicrosoftÂŽ Word for Office 365""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""MicrosoftÂŽ Word for Office 365""
""pdf:docinfo:created"",""2020-02-18T02:18:56Z""
";https://scholar.google.com/scholar?start=200&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095313-1324;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;[HTML][HTML] The current state of research, challenges, and future research directions of blockchain technology in patient care: Systematic review;P Durneva, K Cousins, M Chen ; Journal of medical Internet research, 2020  jmir.org;Germany;"… and permissioned blockchains [4]. The permissionless blockchain is open to the public, allows

anyone to join the blockchain without approval, and usually provides an economic incentive for

participating in the blockchain. Most known cryptocurrency blockchains are public …";Cité 6 fois;Les 7 versions;[HTML] jmir.org;https://www.jmir.org/2020/7/e18619;;"""og:image"",""https://asset.jmir.pub/assets/d79a8bd3de22e8912cc51363688ccb9a.png""
""twitter:card"",""summary_large_image""
""og:site_name"",""Journal of Medical Internet Research""
""keywords"",""blockchain;health information technology;systematic review;security;privacy;interoperability;health outcomes""
""citation_journal_title"",""Journal of Medical Internet Research""
""language"",""en""
""dc:title"",""Journal of Medical Internet Research - The Current State of Research, Challenges, and Future Research Directions of Blockchain Technology in Patient Care: Systematic Review""
""Content-Encoding"",""UTF-8""
""DC.Identifier"",""doi:10.2196/18619""
""DC.Rights"",""""
""resourceName"",""e18619""
""citation_abstract_html_url"",""https://www.jmir.org/2020/7/e18619""
""citation_issue"",""7""
""citation_abstract_pdf_url"",""https://www.jmir.org/2020/7/e18619/PDF""
""citation_doi"",""10.2196/18619""
""DC.Relation"",""World""
""citation_volume"",""22""
""Content-Language"",""en""
""msapplication-TileImage"",""https://asset.jmir.pub/assets/static/images/mstile-144x144.png""
""citation_title"",""The Current State of Research, Challenges, and Future Research Directions of Blockchain Technology in Patient Care: Systematic Review""
""DC.Type"",""Text.Serial.Journal""
""citation_publisher"",""JMIR Publications Inc., Toronto, Canada""
""description"",""Background: Blockchain offers a promising new distributed technology to address the challenges of data standardization, system interoperability, security, privacy, and accessibility of medical records. Objective: The purpose of this review is to assess the research on the use of blockchain technology for patient care and the associated challenges and to provide a research agenda for future research. Methods: This review followed the Preferred Reporting Items for Systematic Reviews and Meta-Analysis guidelines. We queried the Cumulative Index of Nursing and Allied Health Literature (CINAHL), PubMed, Excerpta Medica dataBASE (EMBASE), and Web of Science databases for peer-reviewed research articles published up to December 2019 that examined the implementation of blockchain technology in health care settings. We identified 800 articles from which we selected 70 empirical research articles for a detailed review. Results: Blockchain-based patient care applications include medical information systems, personal health records, mobile health and telemedicine, data preservation systems and social networks, health information exchanges and remote monitoring systems, and medical research systems. These blockchain-based health care applications may improve patient engagement and empowerment, improve health care provider access to information, and enhance the use of health care information for medical research. Conclusions: Blockchain health information technology (HIT) provides benefits such as ensuring data privacy and security of health data, facilitating interoperability of heterogeneous HIT systems, and improving the quality of health care outcomes. However, barriers to using blockchain technology to build HIT include security and privacy vulnerabilities, user resistance, high computing power requirements and implementation costs, inefficient consensus algorithms, and challenges of integrating blockchain with existing HIT. With 51% of the research focused on medical information systems such as electronic health record and electronic medical record, and 53% of the research focused on data security and privacy issues, this review shows that HIT research is primarily focused on the use of blockchain technologies to address the current challenges HIT faces. Although Blockchain presents significant potential for disrupting health care, most ideas are in their infancy. ""
""citation_date"",""2020-07-20""
""title"",""Journal of Medical Internet Research - The Current State of Research, Challenges, and Future Research Directions of Blockchain Technology in Patient Care: Systematic Review""
""twitter:image"",""https://asset.jmir.pub/assets/d79a8bd3de22e8912cc51363688ccb9a.png""
""DC.Description"",""Background: Blockchain offers a promising new distributed technology to address the challenges of data standardization, system interoperability, security, privacy, and accessibility of medical records. Objective: The purpose of this review is to assess the research on the use of blockchain technology for patient care and the associated challenges and to provide a research agenda for future research. Methods: This review followed the Preferred Reporting Items for Systematic Reviews and Meta-Analysis guidelines. We queried the Cumulative Index of Nursing and Allied Health Literature (CINAHL), PubMed, Excerpta Medica dataBASE (EMBASE), and Web of Science databases for peer-reviewed research articles published up to December 2019 that examined the implementation of blockchain technology in health care settings. We identified 800 articles from which we selected 70 empirical research articles for a detailed review. Results: Blockchain-based patient care applications include medical information systems, personal health records, mobile health and telemedicine, data preservation systems and social networks, health information exchanges and remote monitoring systems, and medical research systems. These blockchain-based health care applications may improve patient engagement and empowerment, improve health care provider access to information, and enhance the use of health care information for medical research. Conclusions: Blockchain health information technology (HIT) provides benefits such as ensuring data privacy and security of health data, facilitating interoperability of heterogeneous HIT systems, and improving the quality of health care outcomes. However, barriers to using blockchain technology to build HIT include security and privacy vulnerabilities, user resistance, high computing power requirements and implementation costs, inefficient consensus algorithms, and challenges of integrating blockchain with existing HIT. With 51% of the research focused on medical information systems such as electronic health record and electronic medical record, and 53% of the research focused on data security and privacy issues, this review shows that HIT research is primarily focused on the use of blockchain technologies to address the current challenges HIT faces. Although Blockchain presents significant potential for disrupting health care, most ideas are in their infancy. ""
""twitter:site"",""@jmirpub""
""DC.Publisher.Address"",""JMIR Publications // 130 Queens Quay East, Unit 1100 // Toronto, ON, M5A 0P6""
""DC.Subject"",""blockchain;health information technology;systematic review;security;privacy;interoperability;health outcomes""
""DC.Publisher"",""Journal of Medical Internet Research""
""DC.Format"",""text/xml""
""Content-Length"",""634650""
""DC.Contributor"",""Polina Durneva"",""Karlene Cousins"",""Min Chen""
""Content-Type"",""text/html; charset=UTF-8""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""og:type"",""article""
""twitter:title"",""The Current State of Research, Challenges, and Future Research Directions of Blockchain Technology in Patient Care: Systematic Review""
""og:title"",""The Current State of Research, Challenges, and Future Research Directions of Blockchain Technology in Patient Care: Systematic Review""
""DC.Title"",""The Current State of Research, Challenges, and Future Research Directions of Blockchain Technology in Patient Care: Systematic Review""
""citation_authors"",""Polina Durneva"",""Karlene Cousins"",""Min Chen""
""msapplication-TileColor"",""#247CB3""
""citation_firstpage"",""e18619""
""viewport"",""width=device-width, initial-scale=1""
""DC.Creator"",""Polina Durneva""
""DC.Language"",""EN""
""twitter:description"",""Background: Blockchain offers a promising new distributed technology to address the challenges of data standardization, system interoperability, security, privacy, and accessibility of medical records. Objective: The purpose of this review is to assess the research on the use of blockchain technology for patient care and the associated challenges and to provide a research agenda for future research. Methods: This review followed the Preferred Reporting Items for Systematic Reviews and Meta-Analysis guidelines. We queried the Cumulative Index of Nursing and Allied Health Literature (CINAHL), PubMed, Excerpta Medica dataBASE (EMBASE), and Web of Science databases for peer-reviewed research articles published up to December 2019 that examined the implementation of blockchain technology in health care settings. We identified 800 articles from which we selected 70 empirical research articles for a detailed review. Results: Blockchain-based patient care applications include medical information systems, personal health records, mobile health and telemedicine, data preservation systems and social networks, health information exchanges and remote monitoring systems, and medical research systems. These blockchain-based health care applications may improve patient engagement and empowerment, improve health care provider access to information, and enhance the use of health care information for medical research. Conclusions: Blockchain health information technology (HIT) provides benefits such as ensuring data privacy and security of health data, facilitating interoperability of heterogeneous HIT systems, and improving the quality of health care outcomes. However, barriers to using blockchain technology to build HIT include security and privacy vulnerabilities, user resistance, high computing power requirements and implementation costs, inefficient consensus algorithms, and challenges of integrating blockchain with existing HIT. With 51% of the research focused on medical information systems such as electronic health record and electronic medical record, and 53% of the research focused on data security and privacy issues, this review shows that HIT research is primarily focused on the use of blockchain technologies to address the current challenges HIT faces. Although Blockchain presents significant potential for disrupting health care, most ideas are in their infancy. ""
""DC.Date"",""2020-07-20""
""DC.Source"",""J Med Internet Res 2020;22(7):e18619 https://www.jmir.org/2020/7/e18619""
""og:url"",""https://www.jmir.org/2020/7/e18619""
";https://scholar.google.com/scholar?start=130&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095344-1461;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Blockchain and economic transactions;D Adachi, J Aoyagi ; Cryptocurrency and Blockchain Technology, 2020  books.google.com;;"… Interested readers may refer to, for example, Harvey (2016) for general crypto- graphy-based

finance and to Antonopoulos (2014) for more detailed explanation on the cryptography used

in the Bitcoin … 2.5. 2 Oracle problem Oracle in the blockchain refers to sending data …";Autres articles;;null;;;;https://scholar.google.com/scholar?start=260&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095297-1256;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;[HTML][HTML] Risk identification and modeling for blockchain-enabled container shipping;S Nguyen, PSL Chen, Y Du ; International Journal of Physical …, 2020  emerald.com;;"… Advanced search. Risk identification and modeling for blockchain-enabled container

shipping. Son Nguyen (National … 2. Blockchain and its application in container shipping.

2.1 Blockchain technology. According to the Commonwealth Scientific …";Cité 4 fois;Les 3 versions;[HTML] emerald.com;https://www.emerald.com/insight/content/doi/10.1108/IJPDLM-01-2020-0036/full/html?casa_token=KQ1x_-ocUfQAAAAA:L7KSgYl1w9ry1F0pKFmqjRXVaNFiDDlWlK9H1F7woLK8ZYKztIBNL644bjsPtLi_-vOPkHrrHYTvBUm-5NVzXZshDnNWSRGrFp8ESwvxohN2OR-Lqw;;"""keywords"",""Container shipping,Blockchain,Operational risk,Risk identification,Directed acyclic graph,Network analysis""
""dc.Title"",""Risk identification and modeling for blockchain-enabled container shipping""
""citation_journal_title"",""International Journal of Physical Distribution &amp; Logistics Management""
""description"",""Risk identification and modeling for blockchain-enabled container shipping - Author: Son Nguyen, Peggy Shu-Ling Chen, Yuquan Du""
""language"",""en""
""title"",""Risk identification and modeling for blockchain-enabled container shipping
 |  Emerald Insight""
""dc.Identifier"",""10.1108/IJPDLM-01-2020-0036"",""0960-0035""
""dc.Publisher"",""Emerald Publishing Limited""
""dc.Format"",""text/html""
""dc:title"",""Risk identification and modeling for blockchain-enabled container shipping
 |  Emerald Insight""
""csrf-token"",""WUZyAwbc84erSUAkM4NqklxBgKJB74hfyyyLwIBd""
""Content-Encoding"",""UTF-8""
""dc.Date"",""2020-08-22T00:00:00Z""
""Content-Length"",""75341""
""citation_xml_url"",""https://www.emerald.com/insight/content/doi/10.1108/IJPDLM-01-2020-0036/full/xml""
""dc.Subject"",""Container shipping,Blockchain,Operational risk,Risk identification,Directed acyclic graph,Network analysis""
""Content-Type"",""text/html; charset=UTF-8""
""dc.Contributor"",""Son Nguyen"",""Peggy Shu-Ling Chen"",""Yuquan Du""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""dc.Type"",""article""
""resourceName"",""html""
""X-UA-Compatible"",""IE=edge""
""dc.Language"",""en""
""dc.Description"",""Although being considered for adoption by stakeholders in container shipping, application of blockchain is hindered by different factors. This paper investigates the potential operational risks of blockchain-integrated container shipping systems as one of such barriers.,Literature review is employed as the method of risk identification. Scientific articles, special institutional reports and publications of blockchain solution providers were included in an inclusive qualitative analysis. A directed acyclic graph (DAG) was constructed and analyzed based on network topological metrics.,Twenty-eight potential risks and 47 connections were identified in three groups of initiative, transitional and sequel. The DAG analysis results reflect a relatively well-connected network of identified hazardous events (HEs), suggesting the pervasiveness of information risks and various multiple-event risk scenarios. The criticality of the connected systems' security and information accuracy are also indicated.,This paper indicates the changes of container shipping operational risk in the process of blockchain integration by using updated data. It creates awareness of the emerging risks, provides their insights and establishes the basis for further research.""
""viewport"",""width=device-width, initial-scale=1""
""DCTERMS.bibliographicCitation"",""&ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Ajournal&rft.spage=126&rft.epage=148&rft.volume=51&rft.issue=2""
""dc.Coverage"",""world""
""Content-Language"",""en""
""format-detection"",""telephone=no""
";https://scholar.google.com/scholar?start=60&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095311-1315;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Blockchain for IoT Access Control, Security and Privacy: A Review;P Patil, M Sangeetha, V Bhaskar ; Wireless Personal Communications, 2020  Springer;;"… Permission authorization method for IoT data by means of trusted oracles and blockchain

is presented by Albreiki, H. et al. [14]. Oracles are used as gateways which act as an

interface between blockchain, service providers, and remote clients …";Autres articles;;null;;;;https://scholar.google.com/scholar?start=120&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095341-1453;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Open-Pub: A Transparent yet Privacy-Preserving Academic Publication System based on Blockchain;Y Zhou, Z Wan, Z Guan ; arXiv preprint arXiv:2007.03915, 2020  arxiv.org;;"… It will increase the storage space for the entire blockchain records. Monero is an untraceable

digital currency, with transaction details completely invisible to the public. Another widely used

privacy-preserving cryptocurrency is Zerocash [13], an anonymous cryptocurrency based …";Cité 1 fois;Les 2 versions;[PDF] arxiv.org;https://arxiv.org/pdf/2007.03915;;"""date"",""2021-02-18T01:25:33Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2021-02-18T01:25:33Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.21 (TeX Live 2020) kpathsea version 6.3.2""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2021-02-18T01:25:33Z""
""created"",""2021-02-18T01:25:33Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2021-02-18T01:25:33Z""
""resourceName"",""2007.03915""
""Author"",""""
""producer"",""pdfTeX-1.40.21""
""pdf:docinfo:producer"",""pdfTeX-1.40.21""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""4"",""9"",""9"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2021-02-18T01:25:33Z""
""Last-Modified"",""2021-02-18T01:25:33Z""
""dcterms:modified"",""2021-02-18T01:25:33Z""
""title"",""""
""Last-Save-Date"",""2021-02-18T01:25:33Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2021-02-18T01:25:33Z""
""meta:save-date"",""2021-02-18T01:25:33Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.21 (TeX Live 2020) kpathsea version 6.3.2""
""Content-Length"",""780136""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""14""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""4724"",""5085"",""4573"",""4459"",""4410"",""5101"",""4655"",""5328"",""4388"",""4055"",""3895"",""3524"",""4719"",""2759""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2021-02-18T01:25:33Z""
";https://scholar.google.com/scholar?start=250&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095362-1542;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;[CITATION][C] Post-Quantum Blockchain over Lattice;X Zhang, F Wu, W Yao, W Wang, Z Zheng ; Computers, Materials & Continua, 2020;;null;Cité 1 fois;;null;;;;https://scholar.google.com/scholar?start=340&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095295-1245;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;ACeD: Scalable Data Availability Oracle;P Sheng, B Xue, S Kannan, P Viswanath ; arXiv preprint arXiv:2011.00102, 2020  arxiv.org;;"… Table 1: Performance metrics for different data availability oracles (N: number of oracle nodes,

b: block size) … Definition 1. A data availability oracle for a trusted blockchain accepts blocks from

clients and writes commitments into the trusted blockchain with the following …";Autres articles;;[PDF] arxiv.org;https://arxiv.org/pdf/2011.00102;;"""date"",""2021-03-05T04:04:00Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2021-03-05T04:04:00Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.21 (TeX Live 2020) kpathsea version 6.3.2""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2021-03-05T04:04:00Z""
""created"",""2021-03-05T04:04:00Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2021-03-05T04:04:00Z""
""resourceName"",""2011.00102""
""Author"",""""
""producer"",""pdfTeX-1.40.21""
""pdf:docinfo:producer"",""pdfTeX-1.40.21""
""pdf:unmappedUnicodeCharsPerPage"",""3"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""9"",""13"",""1"",""0"",""1"",""12"",""5"",""1"",""0"",""0"",""0"",""0"",""0"",""0"",""4"",""11"",""12"",""0"",""0"",""1"",""0"",""0"",""0"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2021-03-05T04:04:00Z""
""Last-Modified"",""2021-03-05T04:04:00Z""
""dcterms:modified"",""2021-03-05T04:04:00Z""
""title"",""""
""Last-Save-Date"",""2021-03-05T04:04:00Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2021-03-05T04:04:00Z""
""meta:save-date"",""2021-03-05T04:04:00Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.21 (TeX Live 2020) kpathsea version 6.3.2""
""Content-Length"",""1654716""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""33""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""2344"",""3159"",""2965"",""1902"",""2783"",""2849"",""2274"",""2282"",""1371"",""2191"",""2571"",""2396"",""1588"",""2336"",""1968"",""2756"",""2835"",""1851"",""2617"",""2434"",""1477"",""2673"",""2139"",""1997"",""1734"",""2750"",""2175"",""1932"",""2299"",""2591"",""2862"",""2769"",""1550""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2021-03-05T04:04:00Z""
";https://scholar.google.com/scholar?start=50&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095337-1428;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Food supply chain in the era of Industry 4.0: blockchain technology implementation opportunities and impediments from the perspective of people, process …;Y Kayikci, N Subramanian, M Dora… ; Production Planning & …, 2020  Taylor & Francis;;"… Blockchain technology integrated with other artificial intelligence (AI) technologies can potentially

mitigate issues … The cryptocurrency technology is also used by different applications, such as

VeChain, for … has one of the most impressive partnership lists in the crypto industry …";Cité 11 fois;Les 4 versions;null;;;;https://scholar.google.com/scholar?start=230&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095292-1241;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;OM Forum—Distributed ledgers and operations: What operations management researchers should know about blockchain technology;V Babich, G Hilary ; Manufacturing & Service Operations …, 2020  pubsonline.informs.org;;"… Re- cently, ChainLink became perhaps the first decentralized oracle service that communicates

with off-chain sys- tems. If ChainLink is successfully developed, it will also make oracles Byzantine

fault tolerant. 2.2 … rights to an asset into a digital token on a blockchain …";Cité 126 fois;Les 7 versions;[PDF] archives-ouvertes.fr;https://hal.archives-ouvertes.fr/hal-02005158/file/DLTMSOM.pdf;;"""date"",""2019-02-03T16:43:30Z""
""pdf:PDFVersion"",""1.4""
""xmp:CreatorTool"",""TeX""
""pdf:docinfo:title"",""Distributed Ledgers and Operations: What Operations Management Researchers Should Know about Blockchain Technology""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""Engineering Sciences [physics], Humanities and Social Sciences, Quantitative Finance [q-fin]""
""language"",""en""
""dc:format"",""application/pdf; version=1.4""
""pdf:docinfo:creator_tool"",""HAL""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""Distributed Ledgers and Operations: What Operations Management Researchers Should Know about Blockchain Technology""
""xmp:CreateDate"",""2018-08-27T13:29:14Z""
""modified"",""2019-02-03T16:43:30Z""
""cp:subject"",""Engineering Sciences [physics], Humanities and Social Sciences, Quantitative Finance [q-fin]""
""pdf:docinfo:subject"",""Engineering Sciences [physics], Humanities and Social Sciences, Quantitative Finance [q-fin]""
""pdf:hasMarkedContent"",""false""
""xmp:ModifyDate"",""2019-02-03T11:43:30Z""
""pdf:docinfo:creator"",""Volodymyr Babich, Gilles Hilary""
""PTEX.Fullbanner"",""This is MiKTeX-pdfTeX 2.9.6362 (1.40.18)""
""meta:author"",""Volodymyr Babich, Gilles Hilary""
""trapped"",""False""
""meta:creation-date"",""2021-04-04T11:44:19Z""
""created"",""2021-04-04T11:44:19Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2021-04-04T11:44:19Z""
""resourceName"",""DLTMSOM.pdf""
""Author"",""Volodymyr Babich, Gilles Hilary""
""producer"",""PDFLaTeX""
""pdf:docinfo:producer"",""PDFLaTeX""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""Keywords"",""Smart contracts, Digital Assets, Resiliency, Validation, Visibility, Information aggregation""
""access_permission:modify_annotations"",""true""
""dc:creator"",""Volodymyr Babich, Gilles Hilary""
""dcterms:created"",""2021-04-04T11:44:19Z""
""Last-Modified"",""2019-02-03T16:43:30Z""
""dcterms:modified"",""2019-02-03T16:43:30Z""
""title"",""Distributed Ledgers and Operations: What Operations Management Researchers Should Know about Blockchain Technology""
""xmpMM:DocumentID"",""uuid:a1c6d6e8-e64d-4cce-8ed9-2f1f34f09a8f""
""Last-Save-Date"",""2019-02-03T16:43:30Z""
""pdf:docinfo:keywords"",""Smart contracts, Digital Assets, Resiliency, Validation, Visibility, Information aggregation""
""pdf:docinfo:modified"",""2019-02-03T16:43:30Z""
""meta:save-date"",""2019-02-03T16:43:30Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is MiKTeX-pdfTeX 2.9.6362 (1.40.18)""
""Content-Length"",""995929""
""Content-Type"",""application/pdf""
""xmp:MetadataDate"",""2019-02-03T11:43:30Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Volodymyr Babich, Gilles Hilary""
""pdf:producer"",""MiKTeX pdfTeX-1.40.18""
""dc:subject"",""Smart contracts, Digital Assets, Resiliency, Validation, Visibility, Information aggregation""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""39""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""900"",""2181"",""2365"",""2775"",""2049"",""2800"",""2631"",""2544"",""2760"",""2483"",""2801"",""2601"",""2629"",""2801"",""2605"",""2787"",""2712"",""2634"",""2152"",""2690"",""2800"",""2674"",""2707"",""2672"",""1856"",""2673"",""2747"",""2629"",""2409"",""2329"",""2176"",""2408"",""855"",""3068"",""2035"",""3045"",""3233"",""1574"",""1770""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""Smart contracts, Digital Assets, Resiliency, Validation, Visibility, Information aggregation""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2021-04-04T11:44:19Z""
";https://scholar.google.com/scholar?start=40&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095337-1427;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;[PDF][PDF] SYSTEME DES CREDITS BANCAIRE BASE SUR LA TECHNOLOGIE BLOCKCHAIN;BELK GHOGGALI ; archives.univbiskra.dz;;"… Keywords : Blockchain, Cryptocurrency, Bitcoin,Ethereum ,Transaction . 3 Page 4. Remerciements …

Blockchain 1.6 La blockchain aujourd'hui 1.6.1 Crypto-monnaies La Blockchain fonctionne

aujourd'hui dans la grande majorité des cas avec une crypto- monnaie associée …";;;[PDF] univ-biskra.dz;http://archives.univ-biskra.dz/bitstream/123456789/15778/1/GHOGGALI_BRAHIM_EL_KHALIL.pdf;;"""date"",""2020-09-23T07:37:25Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""fr""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2020-09-23T07:37:25Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is MiKTeX-pdfTeX 4.0.1 (1.40.21)""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2020-09-23T07:37:25Z""
""created"",""2020-09-23T07:37:25Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-09-23T07:37:25Z""
""resourceName"",""GHOGGALI_BRAHIM_EL_KHALIL.pdf""
""Author"",""""
""producer"",""MiKTeX pdfTeX-1.40.21""
""pdf:docinfo:producer"",""MiKTeX pdfTeX-1.40.21""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""1"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2020-09-23T07:37:25Z""
""Last-Modified"",""2020-09-23T07:37:25Z""
""dcterms:modified"",""2020-09-23T07:37:25Z""
""title"",""""
""Last-Save-Date"",""2020-09-23T07:37:25Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2020-09-23T07:37:25Z""
""meta:save-date"",""2020-09-23T07:37:25Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is MiKTeX-pdfTeX 4.0.1 (1.40.21)""
""Content-Length"",""2113383""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""71""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""473"",""1255"",""1060"",""804"",""1220"",""1592"",""2116"",""509"",""2015"",""244"",""13"",""2370"",""1358"",""1419"",""1352"",""2213"",""2305"",""2289"",""550"",""2177"",""2160"",""2301"",""1460"",""28"",""1894"",""427"",""1100"",""1232"",""1081"",""1279"",""850"",""1133"",""2091"",""1259"",""1174"",""1545"",""874"",""1166"",""746"",""544"",""22"",""1269"",""1425"",""1145"",""427"",""270"",""1413"",""513"",""534"",""503"",""549"",""889"",""1938"",""1447"",""418"",""15"",""1153"",""1294"",""1298"",""2028"",""479"",""232"",""242"",""346"",""1077"",""321"",""1641"",""2115"",""2017"",""1847"",""337""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-09-23T07:37:25Z""
";https://scholar.google.com/scholar?start=230&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095318-1349;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Incentives in Blockchain Design and Applications;C Harwick ; Available at SSRN, 2020  papers.ssrn.com;;"… oracles allow trusted information to be fed into smart contracts as part of their decision rules …

Two points, however, bear noting: (1) oracle-provided information compromises the trustless

and pseudonymous qualities of blockchain interactions – perhaps …";Cité 1 fois;;null;;;;https://scholar.google.com/scholar?start=150&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095288-1220;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Converging Artificial Intelligence and Blockchain Technology using Oracle Contract in Ethereum Blockchain Platform;MM Surya, AC Wibowo ; 2020 Fifth International Conference …, 2020  ieeexplore.ieee.org;;"Artificial Intelligence (AI) and blockchain are two emerging concepts that explored 
exponentially in recent years. In software development, artificial Intelligence offers a 
sophisticated enhancement on the programming logic, while blockchain technology …";Autres articles;;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/9288361/9288512/09288611.pdf?casa_token=JJxO2bK1Cq4AAAAA:QttxbfYrFThqGNSnvEP4bdZXjNfDG_8y5lZsrt-q2wZFPEvuW6ne6asXtPkllRm5O05EFIoTwr0;;"""og:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""twitter:title"",""Converging Artificial Intelligence and Blockchain Technology using Oracle Contract in Ethereum Blockchain Platform""
""twitter:card"",""summary""
""Description"",""Artificial Intelligence (AI) and blockchain are two emerging concepts that explored exponentially in recent years. In software development, artificial Intellige""
""og:title"",""Converging Artificial Intelligence and Blockchain Technology using Oracle Contract in Ethereum Blockchain Platform""
""resourceName"",""09288611.pdf""
""language"",""en""
""title"",""Converging Artificial Intelligence and Blockchain Technology using Oracle Contract in Ethereum Blockchain Platform | IEEE Conference Publication | IEEE Xplore""
""og:description"",""Artificial Intelligence (AI) and blockchain are two emerging concepts that explored exponentially in recent years. In software development, artificial Intelligence offers a sophisticated enhancement on the programming logic, while blockchain technology provides transparency and relief the obligation to trust in a central party. Both are two different technologies but considered a disruptive technology in recent years. Artificial Intelligence faces several issues related to the validity of data, algorithms, and policies, while blockchain is called so “friendly” with transparency, trust, and immutability. Both technologies are still in the early stages of their development age. Always, the opportunity for both technologies to converge in some ways would be an exciting area to be explored. This research elaborates on the technical possibilities of application development on the blockchain platform that communicate with AI to do prediction task. Oracle contract allows the data inside Ethereum blockchain to interact with the external data source.""
""twitter:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-UA-Compatible"",""IE=Edge""
""viewport"",""width=device-width, initial-scale=1.0""
""dc:title"",""Converging Artificial Intelligence and Blockchain Technology using Oracle Contract in Ethereum Blockchain Platform | IEEE Conference Publication | IEEE Xplore""
""twitter:description"",""Artificial Intelligence (AI) and blockchain are two emerging concepts that explored exponentially in recent years. In software development, artificial Intelligence offers a sophisticated enhancement on the programming logic, while blockchain technology provides transparency and relief the obligation to trust in a central party. Both are two different technologies but considered a disruptive technology in recent years. Artificial Intelligence faces several issues related to the validity of data, algorithms, and policies, while blockchain is called so “friendly” with transparency, trust, and immutability. Both technologies are still in the early stages of their development age. Always, the opportunity for both technologies to converge in some ways would be an exciting area to be explored. This research elaborates on the technical possibilities of application development on the blockchain platform that communicate with AI to do prediction task. Oracle contract allows the data inside Ethereum blockchain to interact with the external data source.""
""Content-Encoding"",""UTF-8""
""Content-Type-Hint"",""text/html; charset=utf-8""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=20&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095346-1469;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Blockchain based PKI and Certificates Management in Mobile Networks;J Yan, X Hang, B Yang, L Su… ; 2020 IEEE 19th …, 2020  ieeexplore.ieee.org;;"… [12] J. Adler, R. Berryhill, A. Veneris, Z. Poulos, N. Veira and A. Kastania, ""Astraea: A Decentralized

Blockchain Oracle,"" 2018 IEEE International … 1145-1152. [13] H. Al-Breiki, M. Rehman, K. Salah

and D. Svetinovic, ""Trustworthy Blockchain Oracles: Review, Comparison, and …";Les 2 versions;;null;;;;https://scholar.google.com/scholar?start=270&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095292-1235;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Efficient Data Interaction of Blockchain Smart Contract with Oracle Mechanism;Y Wang, H Liu, J Wang, S Wang ; 2020 IEEE 9th Joint …, 2020  ieeexplore.ieee.org;;"Blcokchain smart contract enables the execution of on-chain contracts automatically and 
definitized. But sometimes it would be triggered by out-chain data. With the help of Oracle 
Mechanism, which is an independent third party, we can extend the basic smart contract to a …";;null;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/9338731/9338465/09338784.pdf?casa_token=RNdXAaxOONsAAAAA:axJ7B4-7ElOusL-_YOosntqdu_b0S2RkMbMgwQXNdvzxQOqY9FEgy2-y8J8d75IPnGxCPZH9GcI;;"""og:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""twitter:title"",""Efficient Data Interaction of Blockchain Smart Contract with Oracle Mechanism""
""twitter:card"",""summary""
""Description"",""Blcokchain smart contract enables the execution of on-chain contracts automatically and definitized. But sometimes it would be triggered by out-chain data. With""
""og:title"",""Efficient Data Interaction of Blockchain Smart Contract with Oracle Mechanism""
""resourceName"",""09338784.pdf""
""language"",""en""
""title"",""Efficient Data Interaction of Blockchain Smart Contract with Oracle Mechanism | IEEE Conference Publication | IEEE Xplore""
""og:description"",""Blcokchain smart contract enables the execution of on-chain contracts automatically and definitized. But sometimes it would be triggered by out-chain data. With the help of Oracle Mechanism, which is an independent third party, we can extend the basic smart contract to a systemic and holonomic architecture. The extended system consist of smart contract on-chain and oracle mechanism out-chain. After making data request to oracle mechanism, oracle mechanism collects data from nodes, and make aggregation for the data, then response back to blockchain. In oracle mechanism, an incentive strategy is necessary to keep the nodes' motivation to provide authentic and accurate data. The extended system could bring efficient data interaction between blockchain and internet, which may drive blockchain be used more widely in various areas.""
""twitter:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-UA-Compatible"",""IE=Edge""
""viewport"",""width=device-width, initial-scale=1.0""
""dc:title"",""Efficient Data Interaction of Blockchain Smart Contract with Oracle Mechanism | IEEE Conference Publication | IEEE Xplore""
""twitter:description"",""Blcokchain smart contract enables the execution of on-chain contracts automatically and definitized. But sometimes it would be triggered by out-chain data. With the help of Oracle Mechanism, which is an independent third party, we can extend the basic smart contract to a systemic and holonomic architecture. The extended system consist of smart contract on-chain and oracle mechanism out-chain. After making data request to oracle mechanism, oracle mechanism collects data from nodes, and make aggregation for the data, then response back to blockchain. In oracle mechanism, an incentive strategy is necessary to keep the nodes' motivation to provide authentic and accurate data. The extended system could bring efficient data interaction between blockchain and internet, which may drive blockchain be used more widely in various areas.""
""Content-Encoding"",""UTF-8""
""Content-Type-Hint"",""text/html; charset=utf-8""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=40&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095290-1231;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Blockchain technology use cases;V Gatteschi, F Lamberti, C Demartini ; … Applications of Blockchain …, 2020  Springer;;"… More sophisticated solutions aim at exploiting blockchain and smart contracts to reduce the

workload of notaries and let people automatically define agreements among parties … An oracle

(or a set of oracles, for increased security) would then be used to retrieve data from …";Cité 7 fois;Les 3 versions;null;;;;https://scholar.google.com/scholar?start=30&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095374-1591;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Code, and Other Laws of Blockchain;M Zou ; Oxford Journal of Legal Studies, 2020  academic.oup.com;;"… are required (for example, in derivatives trading), external sources known as 'oracles' can help …

First, distributed trust is designed within blockchain, where it is not necessary to trust … Secondly,

crypto-economic incentives are structured to 'make honesty the winning strategy' 47 …";Autres articles;;null;;;;https://scholar.google.com/scholar?start=390&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095304-1285;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Legal challenges and opportunities of blockchain technology in the real estate sector;RM Garcia;Teruel  Journal of Property, Planning and Environmental …, 2020  emerald.com;;"… an official ID would prevent other potential legal problems caused by the loss of the private key

for the wallet and thus the denial of access to the cryptocurrency it contains … Oracles are external

agents who verify real-world events and submit the information to blockchain …";Cité 9 fois;Les 4 versions;[PDF] emerald.com;https://www.emerald.com/insight/content/doi/10.1108/JPPEL-07-2019-0039/full/pdf;;"""date"",""2020-07-17T16:05:07Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""1"",""3"",""1"",""0"",""0"",""4"",""0"",""0"",""2"",""0"",""2"",""0"",""1"",""3"",""3""
""pdf:PDFVersion"",""1.4""
""xmp:CreatorTool"",""Arbortext Advanced Print Publisher 11.0.3352/W Unicode""
""pdf:docinfo:title"",""EM-JPPE190036 129..145""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dcterms:created"",""2020-07-17T16:05:07Z""
""language"",""en""
""Last-Modified"",""2020-07-17T16:05:07Z""
""dcterms:modified"",""2020-07-17T16:05:07Z""
""dc:format"",""application/pdf; version=1.4""
""title"",""EM-JPPE190036 129..145""
""Last-Save-Date"",""2020-07-17T16:05:07Z""
""pdf:docinfo:creator_tool"",""Arbortext Advanced Print Publisher 11.0.3352/W Unicode""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2020-07-17T16:05:07Z""
""meta:save-date"",""2020-07-17T16:05:07Z""
""pdf:encrypted"",""false""
""dc:title"",""EM-JPPE190036 129..145""
""xmp:CreateDate"",""2020-07-17T21:35:07Z""
""modified"",""2020-07-17T16:05:07Z""
""pdf:hasMarkedContent"",""false""
""Content-Type"",""application/pdf""
""xmp:ModifyDate"",""2020-07-17T21:35:07Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""pdf:producer"",""Adobe LiveCycle PDFG ES""
""meta:creation-date"",""2020-07-17T16:05:07Z""
""created"",""2020-07-17T16:05:07Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""17""
""Creation-Date"",""2020-07-17T16:05:07Z""
""resourceName"",""pdf""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""3177"",""3631"",""3208"",""3171"",""2489"",""3426"",""3551"",""3133"",""3444"",""3538"",""3387"",""3295"",""2993"",""2709"",""3018"",""2746"",""2945""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""producer"",""Adobe LiveCycle PDFG ES""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""Adobe LiveCycle PDFG ES""
""pdf:docinfo:created"",""2020-07-17T16:05:07Z""
";https://scholar.google.com/scholar?start=90&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095409-1738;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Blockchain Ecosystem—Technological and Management Opportunities and Challenges;KKR Choo, S Ozcan, A Dehghantanha… ; IEEE Transactions on …, 2020  ieeexplore.ieee.org;;"… 2020. [29] MH Ur Rehman, K. Salah, E. Damiani, and D. Svetinovic, “Trust in blockchain

cryptocurrency ecosystem,” IEEE Trans. Eng … 299–321. [50] K. Nelaturu et al., “On public

crowdsource-based mechanisms for a decentralized blockchain oracle,” IEEE Trans. Eng …";Cité 2 fois;Les 4 versions;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/17/9226631/09226671.pdf;;"""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""dc:title"",""IEEE Xplore Full-Text PDF:""
""Content-Encoding"",""UTF-8""
""resourceName"",""09226671.pdf""
""language"",""es""
""Content-Length"",""2560""
""title"",""IEEE Xplore Full-Text PDF:""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=540&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095360-1533;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Who is Liable for Cryptocurrency Consensus Mechanism (Mis) Representations?;P Řstbye ; Available at SSRN 3548203, 2020  papers.ssrn.com;;"… can be provided by oracles, and the information provided by oracles must be … the specified desired

functionality is used as a representation for a cryptocurrency consensus mechanism … It is, for

instance, not uncommon to see cryptocurrencies and blockchain being represented as …";Cité 4 fois;;null;;;;https://scholar.google.com/scholar?start=330&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095353-1497;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;[PDF][PDF] Balancing Privacy and Accountability in Blockchain Identity Management;I Damgard, C Ganesh, H Khoshakhlagh, C Orlandi… ;2020 eprint.iacr.org;;"… can work on top of the consensus mechanism of a permissionless blockchain, ie, any blockchain

that can … robust: using the PRF assumption, we can replace the output of the PRF oracle with

random … x? and key K? that are compatible with one of the output of the oracles, we can …";Cité 2 fois;;[PDF] iacr.org;https://eprint.iacr.org/2020/1511.pdf;;"""date"",""2021-03-11T13:34:14Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2021-03-11T13:34:14Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is MiKTeX-pdfTeX 2.9.7029 (1.40.20)""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2021-03-11T13:34:14Z""
""created"",""2021-03-11T13:34:14Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2021-03-11T13:34:14Z""
""resourceName"",""1511.pdf""
""Author"",""""
""producer"",""MiKTeX pdfTeX-1.40.20""
""pdf:docinfo:producer"",""MiKTeX pdfTeX-1.40.20""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""10"",""0"",""5"",""1"",""2"",""0"",""0"",""4"",""0"",""6"",""5"",""2"",""6"",""0"",""0"",""7"",""1"",""3"",""0"",""0"",""0"",""0"",""0"",""5"",""22"",""18"",""12"",""19"",""10"",""15"",""8"",""2"",""12"",""2"",""6"",""18"",""5"",""21"",""0"",""10"",""27"",""15"",""1"",""0"",""1"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2021-03-11T13:34:14Z""
""Last-Modified"",""2021-03-11T13:34:14Z""
""dcterms:modified"",""2021-03-11T13:34:14Z""
""title"",""""
""Last-Save-Date"",""2021-03-11T13:34:14Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2021-03-11T13:34:14Z""
""meta:save-date"",""2021-03-11T13:34:14Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is MiKTeX-pdfTeX 2.9.7029 (1.40.20)""
""Content-Length"",""869141""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""52""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""1890"",""2047"",""2455"",""3237"",""3409"",""3439"",""2091"",""2178"",""2224"",""2013"",""2471"",""2915"",""3196"",""1681"",""1997"",""1567"",""1583"",""2492"",""2531"",""3072"",""2793"",""2051"",""2862"",""3205"",""3029"",""2199"",""2361"",""2406"",""2305"",""1807"",""2108"",""1309"",""2441"",""1198"",""1925"",""1695"",""2766"",""1389"",""1687"",""1727"",""1716"",""1594"",""2169"",""1955"",""269"",""2116"",""2407"",""1608"",""1307"",""1149"",""1355"",""494""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2021-03-11T13:34:14Z""
";https://scholar.google.com/scholar?start=300&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095397-1692;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Crypto and Blockchain Fundamentals;M Lacity ; Ark. L. Rev., 2020  HeinOnline;;"… Henry S. Zaytoun, Cyber Pickpockets: Blockchain, Cryptocurrency, and the Law of Theft, 97 NC

L. REV … See generally Carol Goforth, The Case for Preempting State Money Transmission Laws

for Crypto-Based Businesses, 73 … Figure 2: Timeline of Notable Blockchain Innovations …";Autres articles;;[PDF] uark.edu;https://scholarworks.uark.edu/cgi/viewcontent.cgi?article=1094&context=alr;;"""date"",""2020-08-17T21:07:08Z""
""pdf:PDFVersion"",""1.7""
""xmp:CreatorTool"",""Appligent AppendPDF Pro 6.3""
""pdf:docinfo:title"",""Crypto and Blockchain Fundamentals""
""Appligent"",""AppendPDF Pro 6.3 Linux 64 bit Aug 30 2019 Library 15.0.4""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""language"",""en""
""dc:format"",""application/pdf; version=1.7""
""pdf:docinfo:creator_tool"",""Appligent AppendPDF Pro 6.3""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""Crypto and Blockchain Fundamentals""
""xmp:CreateDate"",""2020-08-17T14:07:08Z""
""modified"",""2020-08-17T21:07:08Z""
""pdf:hasMarkedContent"",""true""
""xmp:ModifyDate"",""2020-08-17T14:07:08Z""
""pdf:docinfo:creator"",""Mary C. Lacity""
""meta:author"",""Mary C. Lacity""
""meta:creation-date"",""2020-08-17T21:07:08Z""
""created"",""2020-08-17T21:07:08Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-08-17T21:07:08Z""
""resourceName"",""viewcontent.cgi""
""Author"",""Mary C. Lacity""
""producer"",""Prince 12.5 (www.princexml.com)""
""pdf:docinfo:producer"",""Prince 12.5 (www.princexml.com)""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""access_permission:modify_annotations"",""true""
""dc:creator"",""Mary C. Lacity""
""dcterms:created"",""2020-08-17T21:07:08Z""
""Last-Modified"",""2020-08-17T21:07:08Z""
""dcterms:modified"",""2020-08-17T21:07:08Z""
""pdf:docinfo:custom:Appligent"",""AppendPDF Pro 6.3 Linux 64 bit Aug 30 2019 Library 15.0.4""
""title"",""Crypto and Blockchain Fundamentals""
""xmpMM:DocumentID"",""uuid:643b4a34-af21-11b2-0a00-0006f3010000""
""Last-Save-Date"",""2020-08-17T21:07:08Z""
""pdf:docinfo:modified"",""2020-08-17T21:07:08Z""
""meta:save-date"",""2020-08-17T21:07:08Z""
""Content-Length"",""4364735""
""Content-Type"",""application/pdf""
""xmp:MetadataDate"",""2020-08-17T14:07:08Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Mary C. Lacity""
""dc:language"",""en""
""pdf:producer"",""Prince 12.5 (www.princexml.com)""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""34""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""826"",""2464"",""2362"",""2660"",""2198"",""2287"",""2648"",""3075"",""2373"",""2064"",""2577"",""2267"",""2675"",""1998"",""526"",""846"",""3300"",""2478"",""2545"",""2703"",""2497"",""3060"",""2626"",""2713"",""2138"",""2425"",""3011"",""1972"",""2524"",""2332"",""1440"",""1111"",""3258"",""1116""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-08-17T21:07:08Z""
";https://scholar.google.com/scholar?start=490&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095304-1293;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;[HTML][HTML] Social media marketing of IT service companies: analysis using a concept-linking mining approach;C Shen, T Luong, J Ho, I Djailani ; Industrial Marketing Management, 2020  Elsevier;;"JavaScript is disabled on your browser. Please enable JavaScript to use all

the features on this page. Skip to main content Skip to article …";Cité 18 fois;Les 2 versions;[HTML] sciencedirect.com;https://www.sciencedirect.com/science/article/pii/S0019850118307466?casa_token=7YUdak6B0l0AAAAA:ErGKLfou34y2V1Kijmnlfa40Awd-c_vuwpDRSs-KmiCUtsM9hR5E7DoUnc4FhDr_GRX1zrMD;;;https://scholar.google.com/scholar?start=90&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095392-1666;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;The Too-Big-To-Fail Problem and the Blockchain Solution;M Schillig ; Available at SSRN 3680759, 2020  papers.ssrn.com;;"… 12 But see M Haentjens, T de Graaf and I Kokorin, 'The Failed Hopes of Disintermediation:

Crypto-custodian Insolvency, Legal Risks and How to Avoid Them … 14 JP Morgan, JP Morgan

Perspectives: Blockchain, digital currency and cryptocurrency: Moving into the …";Autres articles;;null;;;;https://scholar.google.com/scholar?start=470&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095313-1325;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;[PDF][PDF] A note on separating classical and quantum random oracles;T Yamakawa, M Zhandry ;2020 eprint.iacr.org;;"… Random oracles are practical: A paradigm for designing efficient protocols … Security of the

Fiat-Shamir transformation in the quantum random- oracle model … In Alexandra Boldyreva and

Daniele Micciancio, ed- itors, CRYPTO 2019, Part II, volume 11693 of LNCS, pages 356– 383 …";Cité 2 fois;;[PDF] iacr.org;https://eprint.iacr.org/2020/787.pdf;;"""date"",""2020-06-24T19:46:55Z""
""pdf:PDFVersion"",""1.5""
""xmp:CreatorTool"",""LaTeX with hyperref""
""pdf:docinfo:title"",""""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""xmp:CreateDate"",""2020-06-24T19:46:49Z""
""modified"",""2020-06-24T19:46:55Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""xmp:ModifyDate"",""2020-06-24T15:46:55Z""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.20 (TeX Live 2019) kpathsea version 6.3.1""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2020-06-24T19:46:49Z""
""created"",""2020-06-24T19:46:49Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-06-24T19:46:49Z""
""resourceName"",""787.pdf""
""Author"",""""
""producer"",""pdfTeX-1.40.20""
""pdf:docinfo:producer"",""pdfTeX-1.40.20""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""11"",""7"",""28"",""14"",""24"",""13"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2020-06-24T19:46:49Z""
""Last-Modified"",""2020-06-24T19:46:55Z""
""dcterms:modified"",""2020-06-24T19:46:55Z""
""title"",""""
""xmpMM:DocumentID"",""uuid:f7c57005-8d47-46f7-935e-c4251ef2a427""
""Last-Save-Date"",""2020-06-24T19:46:55Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2020-06-24T19:46:55Z""
""meta:save-date"",""2020-06-24T19:46:55Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.20 (TeX Live 2019) kpathsea version 6.3.1""
""Content-Length"",""311808""
""Content-Type"",""application/pdf""
""xmp:MetadataDate"",""2020-06-24T15:46:55Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""pdf:producer"",""pdfTeX-1.40.20""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""10""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""1580"",""2522"",""1738"",""1680"",""1359"",""1805"",""1913"",""1999"",""2006"",""1864""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-06-24T19:46:49Z""
";https://scholar.google.com/scholar?start=130&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095290-1224;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;[HTML][HTML] Integrating advanced technologies to uphold security of payment: Data flow diagram;HY Chong, A Diamantopoulos ; Automation in Construction, 2020  Elsevier;;"… However, there is a lack of literature identifying the practical use-case of hardware oracles … Although

the practical use-cases of blockchain technology, smart contracts, smart sensors, oracle and BIM

that may be applicable in addressing SOP issues, each of these …";Cité 11 fois;Les 4 versions;[HTML] sciencedirect.com;https://www.sciencedirect.com/science/article/pii/S0926580519313573?casa_token=9S__5ufheRcAAAAA:n2U_Mvsnz-qJz2ldTGHALEGtj5_O-DHJk2GF7JGyW7RdZwKk3BmrxvCE5ZPU8UuvYOnGTy-m;;;https://scholar.google.com/scholar?start=30&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095306-1294;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Proof-of-burn;K Karantias, A Kiayias, D Zindros ; International Conference on Financial …, 2020  Springer;;"… We prove our scheme is secure in the Random Oracle model. We explore the application of

destroying value in a legacy cryptocurrency to bootstrap a new one. The user burns coins in the

source blockchain and subsequently creates a proof-of-burn, a short string proving that …";Cité 22 fois;Les 3 versions;[PDF] ifca.ai;http://fc20.ifca.ai/preproceedings/105.pdf;;"""date"",""2020-01-07T21:21:51Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2020-01-07T21:21:51Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.20 (TeX Live 2019) kpathsea version 6.3.1""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2020-01-07T21:21:51Z""
""created"",""2020-01-07T21:21:51Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-01-07T21:21:51Z""
""resourceName"",""105.pdf""
""Author"",""""
""producer"",""pdfTeX-1.40.20""
""pdf:docinfo:producer"",""pdfTeX-1.40.20""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""2"",""0"",""4"",""0"",""7"",""0"",""2"",""6"",""2"",""0"",""0"",""2"",""5"",""0"",""0"",""5"",""8"",""6"",""13"",""32"",""3"",""0"",""1"",""0"",""1"",""7"",""12"",""1""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2020-01-07T21:21:51Z""
""Last-Modified"",""2020-01-07T21:21:51Z""
""dcterms:modified"",""2020-01-07T21:21:51Z""
""title"",""""
""Last-Save-Date"",""2020-01-07T21:21:51Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2020-01-07T21:21:51Z""
""meta:save-date"",""2020-01-07T21:21:51Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.20 (TeX Live 2019) kpathsea version 6.3.1""
""Content-Length"",""610775""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""30""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""2122"",""2292"",""1852"",""1671"",""1695"",""1843"",""1261"",""1859"",""1653"",""1477"",""1887"",""2167"",""1804"",""2112"",""1430"",""2803"",""1934"",""1699"",""1740"",""1388"",""930"",""1519"",""1260"",""1600"",""1574"",""1337"",""1808"",""1359"",""1344"",""1865""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-01-07T21:21:51Z""
";https://scholar.google.com/scholar?start=100&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095399-1700;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Blockchain Scalability through Secure Optimistic Protocols;L Eckey ;2020 tuprints.ulb.tudarmstadt.de;;"… 34 3.3.3 Scaling Through Off-Chain Protocols . . . . . 36 3.4 Formal Treatment of the Blockchain . . . . .

41 3.4.1 Security Provided by the Public Ledger … 114 5.2.3 Global Random Oracle …";Autres articles;;[PDF] tu-darmstadt.de;https://tuprints.ulb.tu-darmstadt.de/14041/7/lisa_eckey_dissertation.pdf;;"""date"",""2020-12-17T01:47:23Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""6"",""0"",""0"",""0"",""6"",""2"",""0"",""21"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""10"",""0"",""2"",""4"",""2"",""0"",""0"",""0"",""0"",""0"",""0"",""3"",""0"",""0"",""4"",""6"",""3"",""0"",""10"",""0"",""5"",""0"",""10"",""0"",""11"",""4"",""0"",""35"",""17"",""11"",""0"",""0"",""4"",""12"",""1"",""18"",""12"",""5"",""6"",""0"",""0"",""27"",""13"",""22"",""0"",""10"",""5"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""1"",""1"",""0"",""0"",""3"",""0"",""0"",""0"",""0"",""4"",""1"",""4"",""0"",""5"",""0"",""10"",""5"",""3"",""6"",""4"",""1"",""2"",""2"",""10"",""21"",""27"",""0"",""0"",""2"",""0"",""3"",""0"",""4"",""0"",""2"",""0"",""0"",""0"",""4"",""0"",""0"",""0"",""0"",""0"",""0"",""1"",""1"",""1"",""1"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""9"",""4"",""2"",""5"",""0"",""0"",""0"",""19"",""0"",""1"",""2"",""2"",""0"",""2"",""0"",""0"",""1"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.5""
""xmp:CreatorTool"",""pdftk 2.01 - www.pdftk.com""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dcterms:created"",""2020-12-17T01:47:23Z""
""language"",""en""
""Last-Modified"",""2020-12-17T01:47:23Z""
""dcterms:modified"",""2020-12-17T01:47:23Z""
""dc:format"",""application/pdf; version=1.5""
""Last-Save-Date"",""2020-12-17T01:47:23Z""
""pdf:docinfo:creator_tool"",""pdftk 2.01 - www.pdftk.com""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2020-12-17T01:47:23Z""
""meta:save-date"",""2020-12-17T01:47:23Z""
""pdf:encrypted"",""false""
""modified"",""2020-12-17T01:47:23Z""
""Content-Length"",""2652158""
""pdf:hasMarkedContent"",""false""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""meta:creation-date"",""2020-12-17T01:47:23Z""
""created"",""2020-12-17T01:47:23Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""237""
""Creation-Date"",""2020-12-17T01:47:23Z""
""resourceName"",""lisa_eckey_dissertation.pdf""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""304"",""351"",""525"",""858"",""2"",""1354"",""2"",""1982"",""4"",""1954"",""311"",""1926"",""3"",""2035"",""399"",""1275"",""1680"",""1780"",""145"",""1989"",""2215"",""2363"",""2353"",""2262"",""2197"",""2362"",""2446"",""2231"",""1146"",""1508"",""1805"",""2212"",""2113"",""1992"",""2044"",""1998"",""1638"",""2073"",""2274"",""197"",""29"",""1956"",""2076"",""1915"",""1618"",""2257"",""1736"",""1833"",""1998"",""2038"",""2245"",""2145"",""2077"",""2138"",""2147"",""2418"",""2213"",""2345"",""2360"",""1950"",""2039"",""2352"",""1018"",""2011"",""2428"",""2234"",""2180"",""2091"",""1472"",""2118"",""1545"",""1894"",""1917"",""2049"",""2109"",""2184"",""2359"",""2133"",""1795"",""1830"",""1762"",""1341"",""1864"",""1839"",""1754"",""2085"",""1919"",""2401"",""2330"",""2246"",""1650"",""1837"",""1626"",""1693"",""1705"",""1868"",""1786"",""2095"",""2202"",""1981"",""2274"",""1970"",""2008"",""1757"",""2073"",""1544"",""2471"",""1551"",""1530"",""1859"",""1458"",""1645"",""1668"",""1605"",""2014"",""1977"",""2100"",""2198"",""2166"",""2064"",""227"",""1830"",""1503"",""2072"",""1922"",""1970"",""1880"",""2050"",""2223"",""2377"",""2522"",""2082"",""1879"",""2091"",""2494"",""1584"",""1975"",""1759"",""1416"",""1975"",""1351"",""1959"",""1841"",""1490"",""2122"",""1867"",""1579"",""1766"",""1455"",""1775"",""1862"",""1764"",""2032"",""1346"",""2405"",""1898"",""1979"",""1194"",""2223"",""1686"",""2154"",""1290"",""2102"",""1924"",""1873"",""1861"",""1836"",""1873"",""2058"",""1425"",""2121"",""1950"",""1275"",""2168"",""2107"",""1541"",""2333"",""2055"",""144"",""1701"",""2461"",""2309"",""1811"",""2167"",""2426"",""2143"",""2424"",""2393"",""2316"",""1700"",""1995"",""2043"",""1942"",""2308"",""2119"",""1370"",""1367"",""1913"",""2202"",""2041"",""1693"",""2168"",""2234"",""1836"",""2097"",""1968"",""2095"",""2017"",""2078"",""2100"",""1432"",""1903"",""2369"",""2389"",""1635"",""1500"",""16"",""729"",""15"",""594"",""22"",""1682"",""2118"",""2072"",""2093"",""2025"",""2050"",""2086"",""1975"",""2056"",""1905"",""2078"",""2085"",""2056"",""1921"",""2030"",""1029""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""producer"",""itext-paulo-155 (itextpdf.sf.net-lowagie.com)""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""itext-paulo-155 (itextpdf.sf.net-lowagie.com)""
""pdf:docinfo:created"",""2020-12-17T01:47:23Z""
";https://scholar.google.com/scholar?start=500&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095388-1652;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;School of block–Review of blockchain for the radiologists;S Abdullah, S Rothenberg, E Siegel, W Kim ; Academic radiology, 2020  Elsevier;;"… This was most infamously demonstrated in a “hack” of an early Ethereum project dubbed “The

Dao,” in which a flaw in the code of the project was exploited and allowed hackers to steal millions

of dollars worth of cryptocurrency. Finally, although blockchain encryption is thought …";Cité 10 fois;Les 5 versions;[HTML] academicradiology.org;https://www.academicradiology.org/article/S1076-6332(19)30445-3/fulltext;;;https://scholar.google.com/scholar?start=450&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095409-1737;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Inclusăo digital e blockchain como instrumentos para o desenvolvimento econômico: Digital inclusion and blockchain as instruments for economic development;DB Friedrich, JHM Philippi ; International Journal of Digital …, 2020  journal.nuped.com.br;;"… International Journal of Digital Law, Belo Horizonte, ano 1, n. 1, p. 97-115, jan./abr. 2020 97

Inclusăo digital e blockchain como instrumentos para o desenvolvimento econômico Digital

inclusion and blockchain as instruments for economic development …";Cité 2 fois;;[PDF] nuped.com.br;https://journal.nuped.com.br/index.php/revista/article/download/7/6;;"""date"",""2020-11-23T18:01:06Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.3""
""xmp:CreatorTool"",""Adobe InDesign 16.0 (Windows)""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dcterms:created"",""2020-11-23T17:47:45Z""
""language"",""pt""
""Last-Modified"",""2020-11-23T18:01:06Z""
""dcterms:modified"",""2020-11-23T18:01:06Z""
""dc:format"",""application/pdf; version=1.3""
""xmpMM:DocumentID"",""xmp.id:2179bb28-52ba-3345-96d9-09311353a35e""
""Last-Save-Date"",""2020-11-23T18:01:06Z""
""pdf:docinfo:creator_tool"",""Adobe InDesign 16.0 (Windows)""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2020-11-23T18:01:06Z""
""meta:save-date"",""2020-11-23T18:01:06Z""
""pdf:encrypted"",""false""
""xmp:CreateDate"",""2020-11-20T14:44:51Z""
""modified"",""2020-11-23T18:01:06Z""
""Content-Length"",""620068""
""pdf:hasMarkedContent"",""true""
""Content-Type"",""application/pdf""
""xmp:ModifyDate"",""2020-11-20T14:45:03Z""
""xmp:MetadataDate"",""2020-11-20T14:45:03Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""pdf:producer"",""Adobe PDF Library 15.0""
""meta:creation-date"",""2020-11-23T17:47:45Z""
""created"",""2020-11-23T17:47:45Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""28""
""Creation-Date"",""2020-11-23T17:47:45Z""
""resourceName"",""6""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""198"",""3059"",""2460"",""3771"",""2727"",""3060"",""3029"",""3267"",""3096"",""2831"",""3245"",""3113"",""3195"",""2725"",""3504"",""3008"",""2613"",""2893"",""3493"",""3515"",""2286"",""3522"",""3439"",""1911"",""2658"",""1022"",""2779"",""606""
""access_permission:extract_content"",""true""
""xmpMM:DerivedFrom:DocumentID"",""xmp.did:ce9dc56b-f775-2e4b-9f21-d6a166df081c""
""access_permission:can_print"",""true""
""xmpMM:DerivedFrom:InstanceID"",""xmp.iid:7524e484-ccbb-f148-8238-30cca8b7120c""
""producer"",""macOS Versão 11.0.1 (Compilação 20B29) Quartz PDFContext, AppendMode 1.1""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""macOS Versão 11.0.1 (Compilação 20B29) Quartz PDFContext, AppendMode 1.1""
""pdf:docinfo:created"",""2020-11-23T17:47:45Z""
";https://scholar.google.com/scholar?start=540&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095332-1409;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Blockchain and tourism;H Treiblmaier ; Handbook of eTourism, 2020  Springer;;"… Page 12. 12 H. Treiblmaier experimented with cryptocurrency payments for residents and tourists

to gain a competitive edge … Page 14. 14 H. Treiblmaier oracles, trusted data sources that sense

and verify external information and submit it to the blockchain …";Cité 7 fois;Les 4 versions;[PDF] researchgate.net;https://www.researchgate.net/profile/Horst_Treiblmaier/publication/342179655_Blockchain_and_Tourism/links/5ee79d5a458515814a5ebf93/Blockchain-and-Tourism.pdf;;;https://scholar.google.com/scholar?start=210&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095383-1628;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;ModCon: a model-based testing platform for smart contracts;Y Liu, Y Li, SW Lin, Q Yan ; Proceedings of the 28th ACM Joint Meeting …, 2020  dl.acm.org;;"… All cases were evaluated on the FISCO BCOS blockchain … users to define test oracles in the

generated test driver … We insert this specification as a test oracle into the test driver and

discovered violations against it in the original implementation of CMA …";Cité 3 fois;Les 2 versions;[PDF] ntu.edu.sg;https://personal.ntu.edu.sg/yi_li/files/Liu2020MAM.pdf;;"""date"",""2020-10-15T13:16:19Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""ModCon: A Model-Based Testing Platform for Smart Contracts""
""xmp:CreatorTool"",""LaTeX with acmart 2020/04/30 v1.71 Typesetting articles for the Association for Computing Machinery and hyperref 2020-05-15 v7.00e Hypertext links for LaTeX""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""-  Software and its engineering  ->  Software testing and debugging.""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with acmart 2020/04/30 v1.71 Typesetting articles for the Association for Computing Machinery and hyperref 2020-05-15 v7.00e Hypertext links for LaTeX""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""ModCon: A Model-Based Testing Platform for Smart Contracts""
""modified"",""2020-10-15T13:16:19Z""
""cp:subject"",""-  Software and its engineering  ->  Software testing and debugging.""
""pdf:docinfo:subject"",""-  Software and its engineering  ->  Software testing and debugging.""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""Ye Liu, Yi Li, Shang-Wei Lin, and Qiang Yan""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.21 (TeX Live 2020) kpathsea version 6.3.2""
""meta:author"",""Ye Liu, Yi Li, Shang-Wei Lin, and Qiang Yan""
""trapped"",""False""
""meta:creation-date"",""2020-10-15T13:16:19Z""
""created"",""2020-10-15T13:16:19Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-10-15T13:16:19Z""
""resourceName"",""Liu2020MAM.pdf""
""Author"",""Ye Liu, Yi Li, Shang-Wei Lin, and Qiang Yan""
""producer"",""pdfTeX-1.40.21""
""pdf:docinfo:producer"",""pdfTeX-1.40.21""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""1"",""0"",""0"",""0"",""0"",""0"",""0""
""Keywords"",""Smart contract, blockchain, model-based testing""
""access_permission:modify_annotations"",""true""
""dc:creator"",""Ye Liu, Yi Li, Shang-Wei Lin, and Qiang Yan""
""dcterms:created"",""2020-10-15T13:16:19Z""
""Last-Modified"",""2020-10-15T13:16:19Z""
""dcterms:modified"",""2020-10-15T13:16:19Z""
""title"",""ModCon: A Model-Based Testing Platform for Smart Contracts""
""Last-Save-Date"",""2020-10-15T13:16:19Z""
""pdf:docinfo:keywords"",""Smart contract, blockchain, model-based testing""
""pdf:docinfo:modified"",""2020-10-15T13:16:19Z""
""meta:save-date"",""2020-10-15T13:16:19Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.21 (TeX Live 2020) kpathsea version 6.3.2""
""Content-Length"",""2854968""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Ye Liu, Yi Li, Shang-Wei Lin, and Qiang Yan""
""dc:language"",""en""
""dc:subject"",""Smart contract, blockchain, model-based testing""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""9""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""4691"",""5351"",""4464"",""5401"",""3678"",""1293"",""988"",""595"",""791""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""Smart contract, blockchain, model-based testing""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-10-15T13:16:19Z""
";https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095283-1197;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Trustworthy blockchain oracles: review, comparison, and open research challenges;H Al;Breiki, MHU Rehman, K Salah…  IEEE Access, 2020  ieeexplore.ieee.org;;"The essence of blockchain smart contracts lies in the execution of business logic code in a 
decentralized architecture in which the execution outcomes are trusted and agreed upon by 
all the executing nodes. Despite the decentralized and trustless architectures of the …";Cité 20 fois;Les 2 versions;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/6287639/8948470/09086815.pdf;;"""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""dc:title"",""IEEE Xplore Full-Text PDF:""
""Content-Encoding"",""UTF-8""
""resourceName"",""09086815.pdf""
""language"",""es""
""Content-Length"",""2565""
""title"",""IEEE Xplore Full-Text PDF:""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";
1619095360-1528;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Supply-Chain Management System for Plastic Pipes Market Based on Open Blockchain Framework;S Kudryashov, S Kruglik, I Maslov… ; 2020 IEEE 21st …, 2020  ieeexplore.ieee.org;;"… 225 – 253. [2] S. Kruglik, K. Nazirkhanova, and Y. Yanovich, “Challenges beyond blockchain:

scaling, oracles and privacy preserving,” in 2019 XVI Inter- national Symposium Problems of

Redundancy in Information and Control Systems (REDUNDANCY), Oct. 2019, pp …";Autres articles;;null;;;;https://scholar.google.com/scholar?start=330&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095360-1526;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Accounting Implications of Blockchain-A Hyperledger Composer Use Case for Intangible AssetsA Hyperledger Composer Use Case for Intangible Assets;KS Church, S Stein Smith… ; Journal of Emerging …, 2020  meridian.allenpress.com;;"… Gatteschi, Lamberti, Demartini, Prandteda, and Santamaria 2018). However, third

party oracles are still Page 17. 15 … necessary. 4. Blockchain arbitration. Blockchains,

smart contracts, and crypto-assets are emerging technologies …";Autres articles;;null;;;;https://scholar.google.com/scholar?start=330&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095409-1739;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;What's in the Box? Combating Counterfeit Medications in Pharmaceutical Supply Chains;T Clohessy, S Clohessy ; Blockchain and Distributed Ledger …, 2020  books.google.com;;"… Blockchain, the technology underpinning the Bitcoin cryptocurrency, has been touted as a … of

elimination (eg removal of duplicates, companies focusing solely on crypto services, brokers … and

secured manner by all supply chain ecosystem partners, Oracle's blockchain cloud IoT …";Autres articles;;null;;;;https://scholar.google.com/scholar?start=540&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095371-1574;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Proof-of-Reputation Blockchain with Nakamoto Fallback;L Kleinrock, R Ostrovsky, V Zikas ; International Conference on Cryptology …, 2020  Springer;;"… the dynamic participation of [2, 20]. As is common in the blockchain literature, our

statements are in the random oracle model, where a hash function is assumed to

behave as a random function. As a setup, we assume that all …";Autres articles;;[PDF] iacr.org;https://eprint.iacr.org/2020/381.pdf;;"""date"",""2020-10-29T05:53:14Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2020-10-29T05:53:14Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.19 (TeX Live 2018) kpathsea version 6.3.0""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2020-10-29T05:53:14Z""
""created"",""2020-10-29T05:53:14Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-10-29T05:53:14Z""
""resourceName"",""381.pdf""
""Author"",""""
""producer"",""pdfTeX-1.40.19""
""pdf:docinfo:producer"",""pdfTeX-1.40.19""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""1"",""2"",""2"",""7"",""13"",""17"",""34"",""24"",""6"",""5"",""2"",""0"",""0"",""9"",""7"",""9"",""6"",""5"",""19"",""34"",""57"",""46"",""14"",""13"",""2"",""8"",""0"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2020-10-29T05:53:14Z""
""Last-Modified"",""2020-10-29T05:53:14Z""
""dcterms:modified"",""2020-10-29T05:53:14Z""
""title"",""""
""Last-Save-Date"",""2020-10-29T05:53:14Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2020-10-29T05:53:14Z""
""meta:save-date"",""2020-10-29T05:53:14Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.19 (TeX Live 2018) kpathsea version 6.3.0""
""Content-Length"",""553866""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""32""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""3508"",""4680"",""4394"",""4585"",""3896"",""3967"",""3666"",""3075"",""3407"",""1609"",""3270"",""3990"",""4380"",""3605"",""4565"",""2489"",""2401"",""1030"",""2517"",""4102"",""4152"",""2133"",""1293"",""3316"",""2359"",""2762"",""3326"",""4114"",""3627"",""3878"",""4048"",""216""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-10-29T05:53:14Z""
";https://scholar.google.com/scholar?start=380&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095341-1447;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;[LIVRE][B] Blockchain in action;B Ramamurthy ;2020 books.google.com;;"… Securing it with cryptocurrency 305 12.11 Accessing off-chain data (Oracles) 306 12.12 From

foundations to practical systems 307 12.13 Looking ahead 309 12.14 Best practices 310 12.15

Retrospective 310 12.16 Summary 311 appendix A UML blockchain design models 313 …";Cité 4 fois;;null;;;;https://scholar.google.com/scholar?start=250&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095374-1593;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;"[CITATION][C] Master thesis:"" The 4th Industrial Revolution Industry 4.0. The blockchain technology and business innovation.""";E Lamçaj ;2020 matheo.uliege.be;;"… Smart contracts are autonomous and immutable when deployed on the blockchain; they

can help save costs, increase efficiency, or execute with more accuracy any standard

process by intaking information from the web thanks to oracles …";;;null;;;;https://scholar.google.com/scholar?start=390&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095402-1711;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;[PDF][PDF] Towards Model-Driven Smart Contract Systems–Code Generation and Improving Expressivity of Smart Contract Modeling;M Skotnica, J Klicpera, R Pergl ;2020 ceurws.org;;"… is currently the decentralized finance (DeFi) that is used for decentralized exchanges and crypto

loans … First, the mortgage is paid in a cryptocurrency, which is a very volatile asset … the token to

property and mapping to a real cadastre record using a blockchain oracle solution such …";;;[PDF] ceur-ws.org;http://ceur-ws.org/Vol-2825/paper1.pdf;;"""date"",""2020-11-30T21:02:49Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.5""
""xmp:CreatorTool"",""LaTeX with hyperref""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dcterms:created"",""2020-11-30T21:02:49Z""
""language"",""en""
""Last-Modified"",""2020-11-30T21:02:49Z""
""dcterms:modified"",""2020-11-30T21:02:49Z""
""dc:format"",""application/pdf; version=1.5""
""Last-Save-Date"",""2020-11-30T21:02:49Z""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2020-11-30T21:02:49Z""
""meta:save-date"",""2020-11-30T21:02:49Z""
""pdf:encrypted"",""false""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.20 (TeX Live 2019) kpathsea version 6.3.1""
""modified"",""2020-11-30T21:02:49Z""
""Content-Length"",""783616""
""pdf:hasMarkedContent"",""false""
""Content-Type"",""application/pdf""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.20 (TeX Live 2019) kpathsea version 6.3.1""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""meta:creation-date"",""2020-11-30T21:02:49Z""
""created"",""2020-11-30T21:02:49Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""15""
""Creation-Date"",""2020-11-30T21:02:49Z""
""resourceName"",""paper1.pdf""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""2156"",""2549"",""1918"",""2396"",""2004"",""1711"",""2253"",""1292"",""1902"",""2352"",""1360"",""2829"",""2450"",""2729"",""2680""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""producer"",""pdfTeX-1.40.20""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""pdfTeX-1.40.20""
""pdf:docinfo:created"",""2020-11-30T21:02:49Z""
";https://scholar.google.com/scholar?start=510&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095404-1723;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Blockchain, Bitcoin, and the Internet of Things: Overview;JMOY CHATTERJEE, PS KUMAR… ; Blockchain …, 2020  books.google.com;;"… External data must be incorporated via trusted “oracles.” A new type of BC platform supporting

the volume of devices involved in an IoT deployment is needed, with capabilities that extend

beyond today's common … Blockchain innovation utilizes crypto- graphic methods to …";Autres articles;;null;;;;https://scholar.google.com/scholar?start=520&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095295-1249;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;An Oracle-Based On-Chain Privacy;YJ Chen, JL Wu, YC Hsieh, CW Hsueh ; Computers, 2020  mdpi.com;;"… security measures yet, hackers and inner-circle scammers can steal information and tokens of

the outside world through the bridging of the Oracles. A proper security and privacy protection

mechanism is a must for building effective blockchain-Oracle based applications …";Autres articles;;[PDF] mdpi.com;https://www.mdpi.com/2073-431X/9/3/69/pdf;;;https://scholar.google.com/scholar?start=50&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095360-1531;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;A systematic literature review of blockchain and smart contract development: Techniques, tools, and open challenges;A Vacca, A Di Sorbo, CA Visaggio, G Canfora ; Journal of Systems and …, 2020  Elsevier;;"… Journal of Systems and Software. A systematic literature review of blockchain and smart

contract development: Techniques, tools, and open challenges? … Highlights. • Exploration

of the literature concerning blockchain-oriented software engineering. • …";Cité 2 fois;Les 3 versions;null;;;;https://scholar.google.com/scholar?start=330&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095334-1419;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Design Principles for Blockchain-Enabled Point Exchange Systems: An Action Design Research on a Polycentric Collaborative Network for Loyalty Programs;J Chen, W Ying, Y Chen, Z Wang ; Working Conference on Virtual …, 2020  Springer;;"… BIE cycle. In next steps, we will improve and refine the design principles and the

system architecture design, and then intervene in development of a prototype of

the system based on Oracle blockchain cloud. According to the …";Autres articles;;null;;;;https://scholar.google.com/scholar?start=220&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095283-1201;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;A first look into defi oracles;B Liu, P Szalachowski ; arXiv preprint arXiv:2005.04377, 2020  arxiv.org;;"… Figure 1: Oracle hierarchy of MakerDAO platform … Consequently, in such a decentralized

governance mechanism, the oracles could be manipulable by MKR holders … 2.2 Compound

Compound is a blockchain-based borrowing and lending platform where participants can lend …";Cité 11 fois;Les 2 versions;[PDF] arxiv.org;https://arxiv.org/pdf/2005.04377.pdf?ref=hackernoon.com;;"""date"",""2020-12-14T01:47:31Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""A First Look into DeFi Oracles""
""xmp:CreatorTool"",""LaTeX with acmart 2019/04/22 v1.60 Typesetting articles for the Association for Computing Machinery and hyperref 2020-05-15 v7.00e Hypertext links for LaTeX""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""-  Security and privacy  ->  Distributed systems security.""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with acmart 2019/04/22 v1.60 Typesetting articles for the Association for Computing Machinery and hyperref 2020-05-15 v7.00e Hypertext links for LaTeX""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""A First Look into DeFi Oracles""
""modified"",""2020-12-14T01:47:31Z""
""cp:subject"",""-  Security and privacy  ->  Distributed systems security.""
""pdf:docinfo:subject"",""-  Security and privacy  ->  Distributed systems security.""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""Bowen Liu, Pawel Szalachowski, and Jianying Zhou""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.21 (TeX Live 2020) kpathsea version 6.3.2""
""meta:author"",""Bowen Liu, Pawel Szalachowski, and Jianying Zhou""
""trapped"",""False""
""meta:creation-date"",""2020-12-14T01:47:31Z""
""created"",""2020-12-14T01:47:31Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-12-14T01:47:31Z""
""resourceName"",""2005.04377.pdf""
""Author"",""Bowen Liu, Pawel Szalachowski, and Jianying Zhou""
""producer"",""pdfTeX-1.40.21""
""pdf:docinfo:producer"",""pdfTeX-1.40.21""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""1"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""Keywords"",""Blockchain; DeFi Platforms; Price Oracles; Decentralization""
""access_permission:modify_annotations"",""true""
""dc:creator"",""Bowen Liu, Pawel Szalachowski, and Jianying Zhou""
""dcterms:created"",""2020-12-14T01:47:31Z""
""Last-Modified"",""2020-12-14T01:47:31Z""
""dcterms:modified"",""2020-12-14T01:47:31Z""
""title"",""A First Look into DeFi Oracles""
""Last-Save-Date"",""2020-12-14T01:47:31Z""
""pdf:docinfo:keywords"",""Blockchain; DeFi Platforms; Price Oracles; Decentralization""
""pdf:docinfo:modified"",""2020-12-14T01:47:31Z""
""meta:save-date"",""2020-12-14T01:47:31Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.21 (TeX Live 2020) kpathsea version 6.3.2""
""Content-Length"",""2618143""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Bowen Liu, Pawel Szalachowski, and Jianying Zhou""
""dc:language"",""en""
""dc:subject"",""Blockchain; DeFi Platforms; Price Oracles; Decentralization""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""13""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""4291"",""4769"",""3602"",""3242"",""4323"",""1637"",""3019"",""3675"",""2995"",""4191"",""4225"",""4031"",""2571""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""Blockchain; DeFi Platforms; Price Oracles; Decentralization""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-12-14T01:47:31Z""
";
1619095313-1333;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Blockchain Regulations and Decentralized Applications: Panel Report from AMCIS 2018;H Subramanian, K Cousins, LB Bouyad… ; … of the Association for …, 2020  aisel.aisnet.org;;"… In this scenario, the oracle sources data from sources such as flight trackers, weather databases,

KYC data, and … permission-less public blockchain design and anyone can access the smart contract

on the Ethereum blockchain and observe … Nevertheless, oracles, which Etherisc …";Autres articles;;[PDF] researchgate.net;https://www.researchgate.net/profile/H_Subramanian/publication/340815540_Blockchain_Regulations_and_Decentralized_Applications/links/5e9efb0c4585150839f0014e/Blockchain-Regulations-and-Decentralized-Applications.pdf;;;https://scholar.google.com/scholar?start=130&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095306-1297;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Ohie: Blockchain scaling made simple;H Yu, I Nikoli?, R Hou, P Saxena ; 2020 IEEE Symposium on …, 2020  ieeexplore.ieee.org;;"… functions as random oracles, and assume that some random genesis blocks are available from

an … 4. Similarly, any “conflicting” state updates by smart contracts running on the blockchain can

be … 6Under our random oracle assumption, any log2 k bits of the hash (other that the …";Cité 34 fois;Les 6 versions;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/9144328/9152199/09152798.pdf?casa_token=VU3Vl8Krx0gAAAAA:zkikJO8Hqlv07n1QpfYaiuRyY5nL70NOlqdYtHE4rB2wkxW-idCWtxKX4GhgcONulDXyZM0krLQ;;"""og:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""twitter:title"",""OHIE: Blockchain Scaling Made Simple""
""twitter:card"",""summary""
""Description"",""Many blockchain consensus protocols have been proposed recently to scale the throughput of a blockchain with available bandwidth. However, these protocols are b""
""og:title"",""OHIE: Blockchain Scaling Made Simple""
""resourceName"",""09152798.pdf""
""language"",""en""
""title"",""OHIE: Blockchain Scaling Made Simple | IEEE Conference Publication | IEEE Xplore""
""og:description"",""Many blockchain consensus protocols have been proposed recently to scale the throughput of a blockchain with available bandwidth. However, these protocols are becoming increasingly complex, making it more and more difficult to produce proofs of their security guarantees. We propose a novel permissionless blockchain protocol OHIE which explicitly aims for simplicity. OHIE composes as many parallel instances of Bitcoin's original (and simple) backbone protocol as needed to achieve excellent throughput. We formally prove the safety and liveness properties of OHIE. We demonstrate its performance with a prototype implementation and large-scale experiments with up to 50,000 nodes. In our experiments, OHIE achieves linear scaling with available bandwidth, providing about 4-10Mbps transaction throughput (under 8-20Mbps per-node available bandwidth configurations) and at least about 20x better decentralization over prior works.""
""twitter:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-UA-Compatible"",""IE=Edge""
""viewport"",""width=device-width, initial-scale=1.0""
""dc:title"",""OHIE: Blockchain Scaling Made Simple | IEEE Conference Publication | IEEE Xplore""
""twitter:description"",""Many blockchain consensus protocols have been proposed recently to scale the throughput of a blockchain with available bandwidth. However, these protocols are becoming increasingly complex, making it more and more difficult to produce proofs of their security guarantees. We propose a novel permissionless blockchain protocol OHIE which explicitly aims for simplicity. OHIE composes as many parallel instances of Bitcoin's original (and simple) backbone protocol as needed to achieve excellent throughput. We formally prove the safety and liveness properties of OHIE. We demonstrate its performance with a prototype implementation and large-scale experiments with up to 50,000 nodes. In our experiments, OHIE achieves linear scaling with available bandwidth, providing about 4-10Mbps transaction throughput (under 8-20Mbps per-node available bandwidth configurations) and at least about 20x better decentralization over prior works.""
""Content-Encoding"",""UTF-8""
""Content-Type-Hint"",""text/html; charset=utf-8""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=100&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095313-1326;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Pametni ugovori pomo?u blockchain tehnologije;F Ma?ek ;2020 repozitorij.unizg.hr;;"… processed this location data. Klju?ne rije?i, pamateni ugovor: Pretraži sli?ne. Chainlink:

Pretraži sli?ne. decentralizirana Oracle mreža: Pretraži sli?ne. Kovan Ethereum

blockchain: Pretraži sli?ne. Klju?ne rije?i (engleski), smart contracts …";Les 6 versions;En cache;null;;;;https://scholar.google.com/scholar?start=130&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095383-1627;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;[CITATION][C] QAN-An energy-efficient quantum-resistant blockchain platform;ES Abraham, J Polecsak ;2020;;null;Autres articles;;null;;;;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095355-1505;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;[PDF][PDF] Compact Simulation-Sound NIZK Arguments of Composite Residuosity and Applications to Logarithmic-Size Ring Signatures;B Libert, K Nguyen, T Peters, M Yung ; eprint.iacr.org;;"… (STOC'19) and Peikert-Shiehian (Crypto'19) showed … Since its introduction, it enabled a wide range

of applications in the random oracle model (ROM) although it … relation intractable (CI) hash

functions [14], which can sometimes emulate the properties of random oracles in the …";Autres articles;Version HTML;[PDF] iacr.org;https://eprint.iacr.org/2020/1334.pdf;;"""date"",""2021-02-24T17:23:59Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2021-02-24T17:23:59Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is MiKTeX-pdfTeX 2.9.6839 (1.40.19)""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2021-02-24T17:23:59Z""
""created"",""2021-02-24T17:23:59Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2021-02-24T17:23:59Z""
""resourceName"",""1334.pdf""
""Author"",""""
""producer"",""pdfTeX-1.40.19""
""pdf:docinfo:producer"",""pdfTeX-1.40.19""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""1"",""1"",""1"",""0"",""32"",""0"",""1"",""15"",""11"",""3"",""16"",""9"",""32"",""18"",""31"",""16"",""27"",""16"",""20"",""9"",""17"",""7"",""23"",""13"",""29"",""41"",""38"",""33"",""28"",""24"",""37"",""31"",""36"",""22"",""63"",""33"",""0"",""0"",""0"",""4"",""3"",""21"",""40"",""25"",""38"",""42"",""65"",""11"",""2"",""0"",""8"",""13"",""27"",""73"",""49"",""22"",""4""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2021-02-24T17:23:59Z""
""Last-Modified"",""2021-02-24T17:23:59Z""
""dcterms:modified"",""2021-02-24T17:23:59Z""
""title"",""""
""Last-Save-Date"",""2021-02-24T17:23:59Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2021-02-24T17:23:59Z""
""meta:save-date"",""2021-02-24T17:23:59Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is MiKTeX-pdfTeX 2.9.6839 (1.40.19)""
""Content-Length"",""820450""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""58""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""2204"",""2932"",""2875"",""2860"",""2919"",""2939"",""2918"",""2556"",""2092"",""2349"",""2392"",""2293"",""2387"",""2257"",""1822"",""1387"",""1750"",""1875"",""1576"",""1743"",""2435"",""2297"",""2210"",""1788"",""2018"",""2119"",""1355"",""1982"",""1564"",""2015"",""2359"",""2773"",""2006"",""2458"",""2294"",""2705"",""1948"",""2672"",""2798"",""1340"",""1628"",""2495"",""2136"",""2067"",""2345"",""2572"",""2325"",""1505"",""2132"",""2473"",""2394"",""2034"",""1324"",""2365"",""2608"",""2285"",""2603"",""1962""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2021-02-24T17:23:59Z""
";https://scholar.google.com/scholar?start=310&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095332-1411;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Multi-Keyword Certificateless Searchable Public Key Authenticated Encryption Scheme Based on Blockchain;X Yang, G Chen, M Wang, T Li, C Wang ; IEEE Access, 2020  ieeexplore.ieee.org;;"… The scheme could resist guessing keyword attacks in the random oracle model, but it only

supported single … sufficient balance to pay the maximum fee, the transac- tion is successfully

packaged and submitted to blockchain … A1 can adaptively ask queries to the following oracles …";Cité 4 fois;;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/6287639/8948470/09183912.pdf;;"""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""dc:title"",""IEEE Xplore Full-Text PDF:""
""Content-Encoding"",""UTF-8""
""resourceName"",""09183912.pdf""
""language"",""es""
""Content-Length"",""2565""
""title"",""IEEE Xplore Full-Text PDF:""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=210&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095337-1432;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;[PDF][PDF] Blockchain for Supply Chain: From Promise to Practice;E Strehle ; blockchainresearchlab.org;;"… Egberts, A. (2017). The oracle problem: An analysis of how blockchain oracles undermine the

advantages of decentralized ledger systems … Retrieved May 27, 2020, from https://www.bsi.bund.

de/SharedDocs/Downloads/EN/BSI/ Crypto/Secure_Blockchain.html. Flan";Autres articles;;[PDF] blockchainresearchlab.org;https://www.blockchainresearchlab.org/wp-content/uploads/2020/05/BRL-Working-Paper-No-12-Blockchain-for-Supply-Chain.pdf;;"""date"",""2020-06-15T16:53:36Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2020-06-15T16:53:36Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.20 (TeX Live 2019/W32TeX) kpathsea version 6.3.1""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2020-06-15T16:53:36Z""
""created"",""2020-06-15T16:53:36Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-06-15T16:53:36Z""
""resourceName"",""BRL-Working-Paper-No-12-Blockchain-for-Supply-Chain.pdf""
""Author"",""""
""producer"",""pdfTeX-1.40.20""
""pdf:docinfo:producer"",""pdfTeX-1.40.20""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2020-06-15T16:53:36Z""
""Last-Modified"",""2020-06-15T16:53:36Z""
""dcterms:modified"",""2020-06-15T16:53:36Z""
""title"",""""
""Last-Save-Date"",""2020-06-15T16:53:36Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2020-06-15T16:53:36Z""
""meta:save-date"",""2020-06-15T16:53:36Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.20 (TeX Live 2019/W32TeX) kpathsea version 6.3.1""
""Content-Length"",""1018841""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""17""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""2651"",""3631"",""2920"",""1732"",""2955"",""2581"",""2319"",""3564"",""3306"",""3364"",""2565"",""3339"",""3271"",""3229"",""3058"",""736"",""694""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-06-15T16:53:36Z""
";https://scholar.google.com/scholar?start=230&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095283-1194;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;[HTML][HTML] Reliability analysis for blockchain oracles;SK Lo, X Xu, M Staples, L Yao ; Computers & Electrical Engineering, 2020  Elsevier;;"Blockchain is an emerging technology that is increasingly supporting economic-ally-critical 
systems. The execution environment of blockchain is isolated from the external world and 
thus requires “blockchain oracles”: agents that fetch information from the external world …";Cité 11 fois;Les 4 versions;[HTML] sciencedirect.com;https://www.sciencedirect.com/science/article/pii/S0045790619316179?casa_token=B-Lx1bpT9Y0AAAAA:2MJ8nT0cJKuLv4bPjpkhZ37hQeDdqm5VGEC0NfCw31NEh2RgMsGzvcU4Ct0DtTJX6FAiyfld;;;
1619095358-1514;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Will Blockchain Technology, Smart Contracts & IoT be the new Lifeblood of Commerce?”;S Zoumpoulidis ; ?????????? ??????? ????????????, 2020  ejournals.lib.auth.gr;;"… 10 Bibb v. Allen [1893] 149 US 481 11 Quiniou M, Blockchain, The Advent of Disintermediation

(ISTE Ltd and John Wiley & Sons, Inc.2019) p.37 12 Liu A, 'Smart Oracles: Building Business

Logic with Smart Contracts' <https://ripple.com/insights/smart-oracles-building-business …";;;[PDF] auth.gr;https://ejournals.lib.auth.gr/infolawj/article/viewFile/7863/7617;;;https://scholar.google.com/scholar?start=320&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095365-1545;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Comparative study of selected cryptocurrency;O Nakov, D Gotseva, Y Tomov ; IOP Conference Series …, 2020  iopscience.iop.org;;"… The solution to this problem is the idea of oracles offered by ChainLink … pp 127–38 [9] Namiot

D, Pokusaev O, Kupriyanovsky V and Akimov A 2017 Blockchain applications for … thetatoken.org/

[14] Ellis S, Juels A, Nazarov S 2017 ChainLink A Decentralized Oracle Network https …";Autres articles;;[PDF] iop.org;https://iopscience.iop.org/article/10.1088/1757-899X/1002/1/012020/pdf;;"""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""viewport"",""width=device-width, initial-scale=1""
""dc:title"",""ShieldSquare Captcha""
""Content-Encoding"",""UTF-8""
""resourceName"",""pdf""
""language"",""en""
""Content-Length"",""2754""
""title"",""ShieldSquare Captcha""
""Content-Language"",""en""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=350&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095395-1675;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;[PDF][PDF] Oraclised Data Schemas: Improving contractual Certainty in uncertain Times;N Roche, AP Moore ;2020 hal.archivesouvertes.fr;;"… 12 4.1 Oracles … This paper presents details of our implementation of an oricalised data

schema and discusses future developments of the system. Keywords: Blockchain oracle, smart

legal contracts, adaptive legal agreements 1 Page 9. 2. Introduction …";;;[PDF] archives-ouvertes.fr;https://hal.archives-ouvertes.fr/hal-03163012/document;;"""date"",""2020-07-21T18:48:56Z""
""pdf:PDFVersion"",""1.4""
""xmp:CreatorTool"",""Adobe Acrobat Pro DC 20.9.20074""
""pdf:docinfo:title"",""Oraclised Data Schemas: Improving contractual Certainty in uncertain Times""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""Computer Science [cs]/Artificial Intelligence [cs.AI], Computer Science [cs]/Distributed, Parallel, and Cluster Computing [cs.DC]""
""language"",""en""
""dc:format"",""application/pdf; version=1.4""
""pdf:docinfo:creator_tool"",""HAL""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""Oraclised Data Schemas: Improving contractual Certainty in uncertain Times""
""xmp:CreateDate"",""2020-07-20T15:14:01Z""
""modified"",""2020-07-21T18:48:56Z""
""cp:subject"",""Computer Science [cs]/Artificial Intelligence [cs.AI], Computer Science [cs]/Distributed, Parallel, and Cluster Computing [cs.DC]""
""pdf:docinfo:subject"",""Computer Science [cs]/Artificial Intelligence [cs.AI], Computer Science [cs]/Distributed, Parallel, and Cluster Computing [cs.DC]""
""pdf:hasMarkedContent"",""true""
""xmp:ModifyDate"",""2020-07-21T19:48:56Z""
""pdf:docinfo:creator"",""Niall Roche, Alastair P Moore""
""meta:author"",""Anna Gorbatchev""
""meta:creation-date"",""2021-04-17T05:30:54Z""
""created"",""2021-04-17T05:30:54Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2021-04-17T05:30:54Z""
""resourceName"",""document""
""Author"",""Anna Gorbatchev""
""producer"",""PDFLaTeX""
""pdf:docinfo:producer"",""PDFLaTeX""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""access_permission:modify_annotations"",""true""
""dc:creator"",""Anna Gorbatchev""
""dcterms:created"",""2021-04-17T05:30:54Z""
""Last-Modified"",""2020-07-21T18:48:56Z""
""dcterms:modified"",""2020-07-21T18:48:56Z""
""title"",""Oraclised Data Schemas: Improving contractual Certainty in uncertain Times""
""xmpMM:DocumentID"",""uuid:460f0cb2-2625-4042-8f13-f70e2f76773a""
""Last-Save-Date"",""2020-07-21T18:48:56Z""
""pdf:docinfo:modified"",""2020-07-21T18:48:56Z""
""meta:save-date"",""2020-07-21T18:48:56Z""
""Content-Length"",""1665402""
""Content-Type"",""application/pdf""
""xmp:MetadataDate"",""2020-07-21T19:48:56Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Anna Gorbatchev""
""pdf:producer"",""Adobe Acrobat Pro DC 20.9.20074""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""48""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""834"",""92"",""1723"",""146"",""344"",""555"",""429"",""1741"",""1916"",""1733"",""1410"",""2222"",""1970"",""1467"",""1296"",""1112"",""2117"",""1929"",""1594"",""1354"",""1590"",""1262"",""2074"",""1892"",""2182"",""176"",""1142"",""1316"",""621"",""38"",""1783"",""2314"",""394"",""1495"",""1710"",""1646"",""1620"",""420"",""388"",""468"",""628"",""973"",""513"",""326"",""37"",""43"",""3054"",""960""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2021-04-17T05:30:54Z""
";https://scholar.google.com/scholar?start=480&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095362-1540;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;A novel blockchain-based surveillance and early-warning technology for infectious diseases;L OUYANG, Y Yong, X ZHENG… ; CHINESE …, 2020  infocommjournal.com;;"… Key words: blockchain, smart contract, artificial intelligence, infectious diseases surveillance,

distributed collaboration … ?? ?????????????????????? ???????Oracles??

??????????? ?????????????????????? …";Cité 2 fois;Les 2 versions;[PDF] infocomm-journal.com;http://www.infocomm-journal.com/znkx/EN/article/downloadArticleFile.do?attachType=PDF&id=170391;;;https://scholar.google.com/scholar?start=340&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095399-1703;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Smart Contracts and the Limits of Computerized Commerce;ED Chason ; Neb. L. Rev., 2020  HeinOnline;;"… to incorporate this information using third party ""oracles."" While oracles allow for … on-why-bitcoin-

is-still- the-only-flavor-of-crypto-for-him … 41. See BLOCKCHAIN, https://blockchain.info/tx/

cca7507897abc89628f45Oe8bleOc6fca 4ec3f7b34cccf55f3f531c659ff4d79?format=hex[https …";Les 3 versions;;[PDF] unl.edu;https://digitalcommons.unl.edu/cgi/viewcontent.cgi?article=3282&context=nlr;;"""date"",""2021-01-14T05:35:06Z""
""pdf:PDFVersion"",""1.7""
""xmp:CreatorTool"",""Appligent pdfHarmony 2.0""
""pdf:docinfo:title"",""Smart Contracts and the Limits of Computerized Commerce""
""Appligent"",""pdfHarmony 2.0 Linux Kernel 2.6 64bit Mar 13 2012 Library 9.0.1""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""language"",""en""
""dc:format"",""application/pdf; version=1.7""
""pdf:docinfo:creator_tool"",""Appligent pdfHarmony 2.0""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""Smart Contracts and the Limits of Computerized Commerce""
""xmp:CreateDate"",""2021-01-13T21:35:05Z""
""modified"",""2021-01-14T05:35:06Z""
""pdf:hasMarkedContent"",""true""
""xmp:ModifyDate"",""2021-01-13T21:35:06Z""
""pdf:docinfo:creator"",""Eric D. Chason""
""meta:author"",""Eric D. Chason""
""meta:creation-date"",""2021-01-14T05:35:05Z""
""created"",""2021-01-14T05:35:05Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2021-01-14T05:35:05Z""
""resourceName"",""viewcontent.cgi""
""Author"",""Eric D. Chason""
""producer"",""Prince 12.5 (www.princexml.com)""
""pdf:docinfo:producer"",""Prince 12.5 (www.princexml.com)""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""access_permission:modify_annotations"",""true""
""dc:creator"",""Eric D. Chason""
""dcterms:created"",""2021-01-14T05:35:05Z""
""Last-Modified"",""2021-01-14T05:35:06Z""
""dcterms:modified"",""2021-01-14T05:35:06Z""
""pdf:docinfo:custom:Appligent"",""pdfHarmony 2.0 Linux Kernel 2.6 64bit Mar 13 2012 Library 9.0.1""
""title"",""Smart Contracts and the Limits of Computerized Commerce""
""xmpMM:DocumentID"",""uuid:d687694a-b04d-11b2-0a00-904efa000000""
""Last-Save-Date"",""2021-01-14T05:35:06Z""
""pdf:docinfo:modified"",""2021-01-14T05:35:06Z""
""meta:save-date"",""2021-01-14T05:35:06Z""
""Content-Length"",""175955""
""Content-Type"",""application/pdf""
""xmp:MetadataDate"",""2021-01-13T21:35:06Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Eric D. Chason""
""dc:language"",""en""
""pdf:producer"",""Prince 12.5 (www.princexml.com)""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""46""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""773"",""1904"",""2938"",""3199"",""2486"",""2796"",""2493"",""2945"",""2745"",""2665"",""2911"",""2921"",""2831"",""2683"",""2809"",""2934"",""2931"",""2884"",""2604"",""2643"",""2682"",""2769"",""2818"",""2791"",""2875"",""2691"",""3171"",""2761"",""3155"",""3145"",""2490"",""3005"",""2678"",""2989"",""2733"",""2920"",""2746"",""3238"",""2307"",""2850"",""2817"",""2655"",""2716"",""2940"",""2745"",""490""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2021-01-14T05:35:05Z""
";https://scholar.google.com/scholar?start=500&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095327-1384;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Security-Enhanced Timed-Release Encryption in the Random Oracle Model;K Yuan, Y Wang, Y Zeng, W Ouyang, Z Li… ; … Symposium on Security …, 2020  Springer;;"… ACM (2016)Google Scholar. 2. Cao, H., Yuan, K., Wang, Y., Yan, Y., Zhou, L., Chai, X.: Bidding

model based on timed-release encryption and blockchain … May, T.: Timed-release crypto …

Mahmoody, M., Moran, T., Vadhan, S.: Time-lock puzzles in the random oracle model …";Autres articles;;null;;;;https://scholar.google.com/scholar?start=190&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095406-1726;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;BPCEX: Towards Blockchain-based Privacy-preserving Currency Exchange;W Li, L Chen, X Lai, X Zhang… ; … and Cryptocurrency (ICBC), 2020  ieeexplore.ieee.org;;"… I. INTRODUCTION Since the introduction of Bitcoin [1] by Nakamoto in 2008,

blockchain-based cryptocurrency has been developed rapidly with more applications

and more advanced techniques. Thou- sands of altcoins are …";Autres articles;;null;;;;https://scholar.google.com/scholar?start=530&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095369-1572;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;SodsBC: Stream of distributed secrets for quantum-safe blockchain;S Dolev, Z Wang ; … Conference on Blockchain (Blockchain), 2020  ieeexplore.ieee.org;;"Page 1. SodsBC: Stream of Distributed Secrets for Quantum-safe Blockchain …

Abstract—SodsBC is the first asynchronous blockchain con- sensus utilizing the concurrent

preprocessing model to achieve high performance and quantum-safety …";Cité 1 fois;Les 2 versions;[PDF] iacr.org;https://eprint.iacr.org/2020/205.pdf;;"""date"",""2020-07-23T06:28:50Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""SodsBC: Stream of Distributed Secretsfor Quantum-safe Blockchain""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""SodsBC: Stream of Distributed Secretsfor Quantum-safe Blockchain""
""modified"",""2020-07-23T06:28:50Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""Shlomi Dolev and Ziyu Wang""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017/W32TeX) kpathsea version 6.2.3""
""meta:author"",""Shlomi Dolev and Ziyu Wang""
""trapped"",""False""
""meta:creation-date"",""2020-07-23T06:28:50Z""
""created"",""2020-07-23T06:28:50Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-07-23T06:28:50Z""
""resourceName"",""205.pdf""
""Author"",""Shlomi Dolev and Ziyu Wang""
""producer"",""pdfTeX-1.40.18""
""pdf:docinfo:producer"",""pdfTeX-1.40.18""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""7"",""0"",""4"",""0"",""0"",""0"",""0"",""0"",""0"",""3"",""7"",""0"",""0""
""Keywords"",""-  Security and privacy  ->  Cryptography; Distributed systems security; ""
""access_permission:modify_annotations"",""true""
""dc:creator"",""Shlomi Dolev and Ziyu Wang""
""dcterms:created"",""2020-07-23T06:28:50Z""
""Last-Modified"",""2020-07-23T06:28:50Z""
""dcterms:modified"",""2020-07-23T06:28:50Z""
""title"",""SodsBC: Stream of Distributed Secretsfor Quantum-safe Blockchain""
""Last-Save-Date"",""2020-07-23T06:28:50Z""
""pdf:docinfo:keywords"",""-  Security and privacy  ->  Cryptography; Distributed systems security; ""
""pdf:docinfo:modified"",""2020-07-23T06:28:50Z""
""meta:save-date"",""2020-07-23T06:28:50Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017/W32TeX) kpathsea version 6.2.3""
""Content-Length"",""1355184""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Shlomi Dolev and Ziyu Wang""
""dc:subject"",""-  Security and privacy  ->  Cryptography; Distributed systems security; ""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""18""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""4455"",""5972"",""5905"",""5130"",""4082"",""5400"",""5497"",""5410"",""4731"",""4659"",""5408"",""5113"",""4488"",""6583"",""4719"",""4569"",""3534"",""2549""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""-  Security and privacy  ->  Cryptography; Distributed systems security; ""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-07-23T06:28:50Z""
";https://scholar.google.com/scholar?start=370&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095334-1416;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;BioUAV: blockchain-envisioned framework for digital identification to secure access in next-generation UAVs;SB Patel, HA Kheruwala, M Alazab, N Patel… ; Proceedings of the 2nd …, 2020  dl.acm.org;;"… user identity registration to UAVs are done in BC through input random oracles, that generates …

BioUAV: Blockchain-envisioned framework for digital identi- fication to secure access in

next-generation UAVs … BC [6]. A random token is generated to be used as input oracle for user …";Autres articles;;null;;;;https://scholar.google.com/scholar?start=220&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095320-1361;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;The people's smart city dashboard (PSCD): Delivering on community-led governance with blockchain;ML Marsal;Llacuna  Technological Forecasting and Social Change, 2020  Elsevier;;"… Another anonymous blockchain is Zcash, which uses zk-SNARK and ring signatures technology

based … The system can call oracles if external data inputs are required to inform Actions. Also,

crypto functionalities are included to reward nodes performing the PoA mining as well …";Cité 2 fois;Les 5 versions;null;;;;https://scholar.google.com/scholar?start=160&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095290-1233;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Towards defeating backdoored random oracles: Indifferentiability with bounded adaptivity;Y Dodis, P Farshim, S Mazaheri, S Tessaro ; Theory of Cryptography …, 2020  Springer;;"… Bauer, Farshim, and Mazaheri (BFM) [3] at Crypto 2018 formulated a new model for the … we do

not replace the dense (intuitively, unpredictable) part of the distribution of random oracles with

uniform: backdoor functions “see” the entire table of the random oracle and this …";Cité 1 fois;Les 3 versions;[PDF] iacr.org;https://eprint.iacr.org/2020/1199.pdf;;"""date"",""2020-11-13T09:33:19Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2020-11-13T09:33:19Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017/Debian) kpathsea version 6.2.3""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2020-11-13T09:33:19Z""
""created"",""2020-11-13T09:33:19Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-11-13T09:33:19Z""
""resourceName"",""1199.pdf""
""Author"",""""
""producer"",""pdfTeX-1.40.18""
""pdf:docinfo:producer"",""pdfTeX-1.40.18""
""pdf:unmappedUnicodeCharsPerPage"",""1"",""0"",""0"",""2"",""2"",""0"",""12"",""3"",""0"",""8"",""7"",""13"",""13"",""9"",""0"",""11"",""2"",""8"",""0"",""14"",""10"",""4"",""2"",""15"",""0"",""0"",""4"",""0"",""9"",""30"",""25"",""43"",""19"",""0"",""0"",""4"",""1"",""5"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2020-11-13T09:33:19Z""
""Last-Modified"",""2020-11-13T09:33:19Z""
""dcterms:modified"",""2020-11-13T09:33:19Z""
""title"",""""
""Last-Save-Date"",""2020-11-13T09:33:19Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2020-11-13T09:33:19Z""
""meta:save-date"",""2020-11-13T09:33:19Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017/Debian) kpathsea version 6.2.3""
""Content-Length"",""666746""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""40""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""2270"",""2349"",""2397"",""2715"",""2752"",""2866"",""2253"",""1801"",""2768"",""2263"",""1554"",""1530"",""2118"",""2334"",""1065"",""2258"",""1519"",""1640"",""1224"",""1897"",""1779"",""1237"",""2551"",""2329"",""1905"",""1118"",""1662"",""1210"",""2043"",""1668"",""1831"",""1093"",""1558"",""2251"",""2230"",""1829"",""1434"",""2457"",""2342"",""2105""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-11-13T09:33:19Z""
";https://scholar.google.com/scholar?start=30&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095313-1327;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;A survey on blockchain-fog integration approaches;H Baniata, A Kertesz ; IEEE Access, 2020  ieeexplore.ieee.org;;"… BC), on the other hand, is the base technology behind crypto-currencies, yet … Real-Time

applications, such as weather updates systems, and Delay-Tolerant Blockchain applications

(DTB … Smart Contracts for validating requests, Trustful and Trust-less Smart Oracles for controlling …";Cité 8 fois;Les 4 versions;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/6287639/8948470/09104970.pdf;;"""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""dc:title"",""IEEE Xplore Full-Text PDF:""
""Content-Encoding"",""UTF-8""
""resourceName"",""09104970.pdf""
""language"",""es""
""Content-Length"",""2565""
""title"",""IEEE Xplore Full-Text PDF:""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=130&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095344-1458;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;[HTML][HTML] Supply chain finance through a blockchain lens;A Pandharkar ;2020 open.library.ubc.ca;;"Learning, knowledge, research, insight: welcome to the world of UBC Library,

the second-largest academic research library in Canada.";Les 2 versions;En cache;[HTML] ubc.ca;https://open.library.ubc.ca/collections/ubctheses/24/items/1.0394745;;"""citation_publication_date"",""2020""
""citation_title"",""Supply chain finance through a blockchain lens""
""citation_publisher"",""University of British Columbia""
""Content-Location"",""/""
""DC.issued"",""2020""
""description"",""Learning, knowledge, research, insight: welcome to the world of UBC Library, the second-largest academic research library in Canada."",""T""
""language"",""en""
""title"",""Supply chain finance through a blockchain lens - UBC Library Open Collections""
""DC.title"",""Supply chain finance through a blockchain lens""
""og:description"",""The world experienced unprecedented growth in international trade in the past few decades. In this resulting environment of global competition, several new companies have spawned and are spawning. Sellers are often under immense pressure by the market players to accept open-account trade terms, shipping goods before receiving payment, leaving them exposed to increased risk. This creates working capital challenges for firms, especially small and medium enterprises. To mitigate this supply chain risk, several supplier-led and buyer-led supply chain finance solutions are facilitated by banks and financial technology companies. However, because of the new Basel III regulation framework for banks and several other Supply Chain Finance (SCF) adoption barriers, like fraudulent activities, many firms are unable to reap SCF’s full benefits. This study explains various SCF instruments, the key drivers in their growth and their adoption barriers.  This study then focuses on the novel blockchain technology and smart contracts by delving deep into their history, components, limitations, risks and use cases. Using the knowledge gathered in the process, a proof-of-concept blockchain and smart contract is developed using the Ethereum platform, which can facilitate normal business, purchase order finance, reverse factoring and reverse securitization. To test the smart contract, four use cases for each SCF instrument mentioned are demonstrated. A JavaScript-based unit test is done to test the smart contract’s correct deployment and onboarding of actors along with their business and financing interactions – access controls to business documents, reverting malicious transactions and correct fund transfer.  As a result of various assumptions taken in the development process, the smart contract works only as a basic proof-of-concept and lacks robustness on the ground of scalability and security. As a result, a future model is laid out which will use various software and hardware oracles for autonomous operations while using a complex system of a storage contract, a permanent contract which stores all the data, and logic contract, upgradable contract which can be changed any number of times, with a proxy contract making delegated “function” calls to logic contract to reduce the gas usage due to external function calls.""
""DC.publisher"",""University of British Columbia""
""DC.creator"",""Pandharkar, Anadi""
""DC.identifier"",""https://open.library.ubc.ca/media/download/pdf/24/1.0394745/4""
""dc:title"",""Supply chain finance through a blockchain lens - UBC Library Open Collections""
""citation_language"",""eng""
""Content-Encoding"",""UTF-8""
""Content-Type-Hint"",""text/html; charset=UTF-8""
""citation_pdf_url"",""https://open.library.ubc.ca/media/download/pdf/24/1.0394745/4""
""Content-Type"",""text/html; charset=UTF-8""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""author"",""""
""og:title"",""Supply chain finance through a blockchain lens""
""citation_author"",""Pandharkar, Anadi""
""resourceName"",""1.0394745""
""url"",""https://open.library.ubc.ca/cIRcle/collections/ubctheses/24/items/1.0394745""
""citation_dissertation_institution"",""University of British Columbia""
""viewport"",""width=device-width""
""citation_doi"",""10.14288/1.0394745""
""twitter:description"",""The world experienced unprecedented growth in international trade in the past few decades. In this resulting environment of global competition, several new companies have spawned and are spawning. Sellers are often under immense pressure by the market players to accept open-account trade terms, shipping goods before receiving payment, leaving them exposed to increased risk. This creates working capital challenges for firms, especially small and medium enterprises. To mitigate this supply chain risk, several supplier-led and buyer-led supply chain finance solutions are facilitated by banks and financial technology companies. However, because of the new Basel III regulation framework for banks and several other Supply Chain Finance (SCF) adoption barriers, like fraudulent activities, many firms are unable to reap SCF’s full benefits. This study explains various SCF instruments, the key drivers in their growth and their adoption barriers.  This study then focuses on the novel blockchain technology and smart contracts by delving deep into their history, components, limitations, risks and use cases. Using the knowledge gathered in the process, a proof-of-concept blockchain and smart contract is developed using the Ethereum platform, which can facilitate normal business, purchase order finance, reverse factoring and reverse securitization. To test the smart contract, four use cases for each SCF instrument mentioned are demonstrated. A JavaScript-based unit test is done to test the smart contract’s correct deployment and onboarding of actors along with their business and financing interactions – access controls to business documents, reverting malicious transactions and correct fund transfer.  As a result of various assumptions taken in the development process, the smart contract works only as a basic proof-of-concept and lacks robustness on the ground of scalability and security. As a result, a future model is laid out which will use various software and hardware oracles for autonomous operations while using a complex system of a storage contract, a permanent contract which stores all the data, and logic contract, upgradable contract which can be changed any number of times, with a proxy contract making delegated “function” calls to logic contract to reduce the gas usage due to external function calls.""
""position"",""1"",""2""
""og:url"",""https://open.library.ubc.ca/cIRcle/collections/ubctheses/24/items/1.0394745""
""Content-Language"",""en""
";https://scholar.google.com/scholar?start=260&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095313-1332;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;[HTML][HTML] Exploring blockchain for the energy transition: Opportunities and challenges based on a case study in Japan;A Ahl, M Yarime, M Goto, SS Chopra, NM Kumar… ; … and Sustainable Energy …, 2020  Elsevier;;"… other blockchain platforms including in the energy sector [6]. However, PoW involves high energy

intensity [40,41], and latency [6]. Initially, PoW was mainly carried out using central processing

units (CPU). However, due to their higher efficiencies for PoW and cryptocurrency …";Cité 34 fois;Les 7 versions;[HTML] sciencedirect.com;https://www.sciencedirect.com/science/article/pii/S1364032119306963?casa_token=t9690XprBlUAAAAA:ly0mKp25Lf4g4jHUykotOUN1E1OHpHmP280Zhj8v4lUiaZpJgDiiDtJT6cuVQTBi62Tz2SDA;;;https://scholar.google.com/scholar?start=130&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095320-1359;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;[PDF][PDF] Emerging Design Patterns for Blockchain Applications;V Rajasekar, S Sondhi, S Saad, S Mohammed ;2020 scitepress.org;;"… Technologies 246 Page 6. industry today. Part of its popularity lies in the fact

that companies and individuals began implementing oracles as a distributed

application ie the oracle itself was built on a blockchain. This …";Autres articles;Version HTML;[PDF] scitepress.org;https://www.scitepress.org/Papers/2020/98927/98927.pdf;;"""date"",""2020-07-31T02:18:58Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2020-07-31T02:18:58Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is MiKTeX-pdfTeX 2.9.6870 (1.40.19)""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2020-07-31T02:18:58Z""
""created"",""2020-07-31T02:18:58Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-07-31T02:18:58Z""
""resourceName"",""98927.pdf""
""Author"",""""
""producer"",""pdfTeX-1.40.19""
""pdf:docinfo:producer"",""pdfTeX-1.40.19""
""pdf:unmappedUnicodeCharsPerPage"",""1"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2020-07-31T02:18:58Z""
""Last-Modified"",""2020-07-31T02:18:58Z""
""dcterms:modified"",""2020-07-31T02:18:58Z""
""title"",""""
""Last-Save-Date"",""2020-07-31T02:18:58Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2020-07-31T02:18:58Z""
""meta:save-date"",""2020-07-31T02:18:58Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is MiKTeX-pdfTeX 2.9.6870 (1.40.19)""
""Content-Length"",""299781""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""8""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""3759"",""4325"",""4537"",""3757"",""4104"",""4720"",""4352"",""1601""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-07-31T02:18:58Z""
";https://scholar.google.com/scholar?start=160&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095339-1440;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Permissioned Blockchain-based Anonymous and Traceable Aggregate Signature Scheme for Industrial Internet of Things;T Li, H Wang, D He, J Yu ; IEEE Internet of Things Journal, 2020  ieeexplore.ieee.org;;"… 5 Fig. 3. Structure of permissioned blockchain in PBATAS … Before giving the definition of security,

we list the following Oracles to help adversary A break the security of our PBATAS scheme. •

Random Oracle (RO). By input a number to RO, a random number is answered …";Cité 1 fois;;null;;;;https://scholar.google.com/scholar?start=240&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095327-1387;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;[PDF][PDF] A Blockchain and Smart Contract-Based Framework to Increase Traceability of Built Assets;J Li, M Kassem, R Watson ; … (CIB W78). Available at: https://www …, 2020  researchgate.net;;"… some products (particularly building services components and systems) through their use as

oracles … behaviour and requirement for the CCO to act as an oracle providing proof … K. (2020)

Blockchain Hurricane: Origins, Applications and Future of Blockchain and Cryptocurrency …";Cité 5 fois;Les 6 versions;[PDF] researchgate.net;https://www.researchgate.net/profile/Jennifer_Li16/publication/343723164_A_Blockchain_and_Smart_Contract-Based_Framework_to_Inrease_Traceability_of_Built_Assets/links/5f438e7d458515b72949981f/A-Blockchain-and-Smart-Contract-Based-Framework-to-Inrease-Traceability-of-Built-Assets.pdf;;;https://scholar.google.com/scholar?start=190&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095339-1438;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;General Purpose Atomic Crosschain Transactions;P Robinson, R Ramesh ; arXiv preprint arXiv:2011.12783, 2020  arxiv.org;;"… The shipment function calls the getPrice function on the Oracle contract on the Price Oracle

blockchain to determine the price that should be paid for the goods, then calls the transfer function

on the Balances contract on the Finance blockchain to affect the payment, and finally …";Cité 1 fois;Les 3 versions;[PDF] arxiv.org;https://arxiv.org/pdf/2011.12783;;"""date"",""2021-03-09T02:45:07Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2021-03-09T02:45:07Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.21 (TeX Live 2020) kpathsea version 6.3.2""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2021-03-09T02:45:07Z""
""created"",""2021-03-09T02:45:07Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2021-03-09T02:45:07Z""
""resourceName"",""2011.12783""
""Author"",""""
""producer"",""pdfTeX-1.40.21""
""pdf:docinfo:producer"",""pdfTeX-1.40.21""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2021-03-09T02:45:07Z""
""Last-Modified"",""2021-03-09T02:45:07Z""
""dcterms:modified"",""2021-03-09T02:45:07Z""
""title"",""""
""Last-Save-Date"",""2021-03-09T02:45:07Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2021-03-09T02:45:07Z""
""meta:save-date"",""2021-03-09T02:45:07Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.21 (TeX Live 2020) kpathsea version 6.3.2""
""Content-Length"",""721068""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""9""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""3978"",""5092"",""4950"",""2890"",""3567"",""4520"",""4448"",""4779"",""4733""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2021-03-09T02:45:07Z""
";https://scholar.google.com/scholar?start=240&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095351-1489;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Inteligencia Artificial GPT-3, Pretoria y Oráculos Algorítmicos en el Derecho: GPT-3 Artificial Intelligence, Pretoria, and Algorithmic Oracles in Law;JG Corvalán ; International Journal of Digital Law, 2020  journal.nuped.com.br;;"… In the end, he affirms that the training task modulates and conditions the exercise of human

skills complemented with algorithmic oracles and digital assistance. Keywords: Artificial

intelligence. GPT-3. Oracle algorithms. Deep learning. Big data …";Cité 4 fois;;[PDF] nuped.com.br;https://journal.nuped.com.br/index.php/revista/article/download/2/1;;"""date"",""2020-11-23T17:59:33Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.3""
""xmp:CreatorTool"",""Adobe InDesign 16.0 (Windows)""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dcterms:created"",""2020-11-23T17:59:33Z""
""language"",""es""
""Last-Modified"",""2020-11-23T17:59:33Z""
""dcterms:modified"",""2020-11-23T17:59:33Z""
""dc:format"",""application/pdf; version=1.3""
""xmpMM:DocumentID"",""xmp.id:2179bb28-52ba-3345-96d9-09311353a35e""
""Last-Save-Date"",""2020-11-23T17:59:33Z""
""pdf:docinfo:creator_tool"",""Adobe InDesign 16.0 (Windows)""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2020-11-23T17:59:33Z""
""meta:save-date"",""2020-11-23T17:59:33Z""
""pdf:encrypted"",""false""
""xmp:CreateDate"",""2020-11-20T14:44:51Z""
""modified"",""2020-11-23T17:59:33Z""
""Content-Length"",""1290072""
""pdf:hasMarkedContent"",""true""
""Content-Type"",""application/pdf""
""xmp:ModifyDate"",""2020-11-20T14:45:03Z""
""xmp:MetadataDate"",""2020-11-20T14:45:03Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""pdf:producer"",""Adobe PDF Library 15.0""
""meta:creation-date"",""2020-11-23T17:59:33Z""
""created"",""2020-11-23T17:59:33Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""51""
""Creation-Date"",""2020-11-23T17:59:33Z""
""resourceName"",""1""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""198"",""3059"",""3148"",""3663"",""3660"",""3035"",""3259"",""3670"",""1191"",""1759"",""3077"",""3375"",""3543"",""3127"",""3212"",""3211"",""3789"",""3787"",""3254"",""3831"",""2520"",""2628"",""3427"",""2986"",""3249"",""3213"",""3552"",""3785"",""3916"",""2835"",""4067"",""3082"",""3258"",""3148"",""3035"",""3263"",""3275"",""2992"",""3725"",""3280"",""3458"",""3240"",""3029"",""1797"",""3522"",""3439"",""1911"",""2658"",""1022"",""2779"",""606""
""access_permission:extract_content"",""true""
""xmpMM:DerivedFrom:DocumentID"",""xmp.did:ce9dc56b-f775-2e4b-9f21-d6a166df081c""
""access_permission:can_print"",""true""
""xmpMM:DerivedFrom:InstanceID"",""xmp.iid:7524e484-ccbb-f148-8238-30cca8b7120c""
""producer"",""macOS Versão 11.0.1 (Compilação 20B29) Quartz PDFContext""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""macOS Versão 11.0.1 (Compilação 20B29) Quartz PDFContext""
""pdf:docinfo:created"",""2020-11-23T17:59:33Z""
";https://scholar.google.com/scholar?start=290&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095292-1239;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Oracle-supported dynamic exploit generation for smart contracts;H Wang, Y Liu, Y Li, SW Lin, C Artho… ; IEEE Transactions on …, 2020  ieeexplore.ieee.org;;"… 3), are deployed on the blockchain … 4) is independent from the test oracles and thus can also

be to extended with other user-defined invariants to detect … 4 ORACLE-SUPPORTED FUZZING

Figure 6 shows the overview of ContraMaster, which is driven by a grey-box fuzzing loop …";Cité 7 fois;C Artho;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/8858/4358699/09256983.pdf?casa_token=Rs_iyCHwgLIAAAAA:CDKy8_qIfbZjRpgvMqC7uZdzFYgpfznAXRzc0E4JanT-DHfuGNWM7SX6x8lHLpJuLLjUApPnl5U;;"""og:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""twitter:title"",""Oracle-Supported Dynamic Exploit Generation for Smart Contracts""
""twitter:card"",""summary""
""Description"",""Despite the high stakes involved in smart contracts, they are often developed in an undisciplined manner, leaving the security and reliability of blockchain tra""
""og:title"",""Oracle-Supported Dynamic Exploit Generation for Smart Contracts""
""resourceName"",""09256983.pdf""
""language"",""en""
""title"",""Oracle-Supported Dynamic Exploit Generation for Smart Contracts | IEEE Journals & Magazine | IEEE Xplore""
""og:description"",""Despite the high stakes involved in smart contracts, they are often developed in an undisciplined manner, leaving the security and reliability of blockchain transactions at risk. In this paper, we introduce ContraMaster an oracle-supported dynamic exploit generation framework for smart contracts. Existing approaches mutate only single transactions; ContraMaster exceeds these by mutating the transaction sequences. ContraMaster uses data-flow, control-flow, and the dynamic contract state to guide its mutations. It then monitors the executions of target contract programs, and validates the results against a general-purpose semantic test oracle to discover vulnerabilities. Being a dynamic technique, it guarantees that each discovered vulnerability is a violation of the test oracle and is able to generate the attack script to exploit this vulnerability. In contrast to rule-based approaches, ContraMaster has not shown any false positives, and it easily generalizes to unknown types of vulnerabilities (e.g., logic errors). We evaluate ContraMaster on 218 vulnerable smart contracts. The experimental results confirm its practical applicability and advantages over the state-of-the-art techniques, and also reveal three new types of attacks.""
""twitter:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-UA-Compatible"",""IE=Edge""
""viewport"",""width=device-width, initial-scale=1.0""
""dc:title"",""Oracle-Supported Dynamic Exploit Generation for Smart Contracts | IEEE Journals & Magazine | IEEE Xplore""
""twitter:description"",""Despite the high stakes involved in smart contracts, they are often developed in an undisciplined manner, leaving the security and reliability of blockchain transactions at risk. In this paper, we introduce ContraMaster an oracle-supported dynamic exploit generation framework for smart contracts. Existing approaches mutate only single transactions; ContraMaster exceeds these by mutating the transaction sequences. ContraMaster uses data-flow, control-flow, and the dynamic contract state to guide its mutations. It then monitors the executions of target contract programs, and validates the results against a general-purpose semantic test oracle to discover vulnerabilities. Being a dynamic technique, it guarantees that each discovered vulnerability is a violation of the test oracle and is able to generate the attack script to exploit this vulnerability. In contrast to rule-based approaches, ContraMaster has not shown any false positives, and it easily generalizes to unknown types of vulnerabilities (e.g., logic errors). We evaluate ContraMaster on 218 vulnerable smart contracts. The experimental results confirm its practical applicability and advantages over the state-of-the-art techniques, and also reveal three new types of attacks.""
""Content-Encoding"",""UTF-8""
""Content-Type-Hint"",""text/html; charset=utf-8""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=40&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095392-1669;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Blockchain enabled secure healthcare Systems;MS Swetha, SK Pushpa… ; … and Applied Network …, 2020  ieeexplore.ieee.org;;"… 6. Based on the Oracles (ie, trusted data feeds) and also stat … In such cases blockchain will be

very useful to make faster claims and also reduce the overhead and costs. As we have discussed

above cryptocurrency is a very fast, efficient and secure way to transfer funds which …";;null;null;;;;https://scholar.google.com/scholar?start=470&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095397-1687;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;[PDF][PDF] SECURE AND EFFICIENT TRACEABLE AUTHORIZATION MULTIKEYWORD SEARCH SYSTEM FOR CLOUD STORAGE USING BLOCKCHAIN …;MGB Biradar, A Lomte ; International Journal, 2020  ijasret.com;;"… STORAGE USING BLOCKCHAIN TECHNOLOGY Miss … “Anonymous hierarchical identity-based

encryption (without random oracles)” We show a character based cryptosystem that highlights

absolutely cloud figure writings and distinctive leveled key task …";Cité 1 fois;Les 3 versions;[PDF] ijasret.com;http://www.ijasret.com/VolumeArticles/FullTextPDF/463_9.SECURE_AND_EFFICIENT_TRACEABLE_AUTHORIZATION.pdf;;"""date"",""2020-06-24T03:29:58Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.5""
""xmp:CreatorTool"",""MicrosoftÂŽ Word 2013""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dc:creator"",""COMP""
""language"",""en""
""dcterms:created"",""2020-06-24T03:29:58Z""
""Last-Modified"",""2020-06-24T03:29:58Z""
""dcterms:modified"",""2020-06-24T03:29:58Z""
""dc:format"",""application/pdf; version=1.5""
""Last-Save-Date"",""2020-06-24T03:29:58Z""
""pdf:docinfo:creator_tool"",""MicrosoftÂŽ Word 2013""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2020-06-24T03:29:58Z""
""meta:save-date"",""2020-06-24T03:29:58Z""
""pdf:encrypted"",""false""
""modified"",""2020-06-24T03:29:58Z""
""Content-Length"",""672734""
""pdf:hasMarkedContent"",""true""
""Content-Type"",""application/pdf""
""pdf:docinfo:creator"",""COMP""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""COMP""
""dc:language"",""en-US""
""meta:author"",""COMP""
""meta:creation-date"",""2020-06-24T03:29:58Z""
""created"",""2020-06-24T03:29:58Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""5""
""Creation-Date"",""2020-06-24T03:29:58Z""
""resourceName"",""463_9.SECURE_AND_EFFICIENT_TRACEABLE_AUTHORIZATION.pdf""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""5577"",""6045"",""4493"",""3354"",""3999""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""Author"",""COMP""
""producer"",""MicrosoftÂŽ Word 2013""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""MicrosoftÂŽ Word 2013""
""pdf:docinfo:created"",""2020-06-24T03:29:58Z""
";https://scholar.google.com/scholar?start=490&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095399-1699;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;CONTRATOS INTELIGENTES: USO DO BLOCKCHAIN PARA FORMULAÇĂO DE CONTRATOS.;HC BUENO ; Intertem@ s ISSN 16771281, 2020  intertemas.toledoprudente.edu.br;;"… CURSO DE DIREITO CONTRATOS INTELIGENTES: USO DO BLOCKCHAIN PARA

FORMULAÇĂO DE CONTRATOS … CURSO DE DIREITO CONTRATOS INTELIGENTES: USO

DO BLOCKCHAIN PARA FORMULAÇĂO DE CONTRATOS. Hugo Carvalho Bueno …";;;[PDF] toledoprudente.edu.br;http://intertemas.toledoprudente.edu.br/index.php/Direito/article/viewFile/8949/67650503;;"""date"",""2021-01-11T13:29:03Z""
""pdf:PDFVersion"",""1.7""
""xmp:CreatorTool"",""MicrosoftÂŽ Word para Microsoft 365""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""language"",""pt""
""dc:format"",""application/pdf; version=1.7""
""pdf:docinfo:creator_tool"",""MicrosoftÂŽ Word para Microsoft 365""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""xmp:CreateDate"",""2020-12-24T16:03:20Z""
""modified"",""2021-01-11T13:29:03Z""
""pdf:hasMarkedContent"",""true""
""xmp:ModifyDate"",""2021-01-11T10:29:03Z""
""pdf:docinfo:creator"",""USUARIO""
""meta:author"",""USUARIO""
""meta:creation-date"",""2020-12-24T19:03:20Z""
""created"",""2020-12-24T19:03:20Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-12-24T19:03:20Z""
""resourceName"",""67650503""
""Author"",""USUARIO""
""producer"",""MicrosoftÂŽ Word para Microsoft 365""
""pdf:docinfo:producer"",""MicrosoftÂŽ Word para Microsoft 365""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""access_permission:modify_annotations"",""true""
""dc:creator"",""USUARIO""
""dcterms:created"",""2020-12-24T19:03:20Z""
""Last-Modified"",""2021-01-11T13:29:03Z""
""dcterms:modified"",""2021-01-11T13:29:03Z""
""xmpMM:DocumentID"",""uuid:95EAE899-82E7-4A69-9B83-26551BEC6EB9""
""Last-Save-Date"",""2021-01-11T13:29:03Z""
""pdf:docinfo:modified"",""2021-01-11T13:29:03Z""
""meta:save-date"",""2021-01-11T13:29:03Z""
""Content-Length"",""480399""
""Content-Type"",""application/pdf""
""xmp:MetadataDate"",""2021-01-11T10:29:03Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""USUARIO""
""dc:language"",""pt-BR""
""pdf:producer"",""MicrosoftÂŽ Word para Microsoft 365""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""46""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""238"",""416"",""486"",""664"",""1448"",""1420"",""453"",""3401"",""2343"",""1198"",""1945"",""1967"",""1489"",""2410"",""1403"",""2153"",""2083"",""1994"",""904"",""2084"",""1353"",""1724"",""2102"",""2178"",""2062"",""1987"",""2185"",""2095"",""2512"",""2483"",""388"",""1971"",""2552"",""3843"",""2297"",""1994"",""2178"",""2251"",""2303"",""2048"",""2355"",""2211"",""201"",""2213"",""2372"",""1613""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-12-24T19:03:20Z""
";https://scholar.google.com/scholar?start=500&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095337-1431;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Blockchain in the cloud: a primer on data security for Blockchain as a Service (BaaS);T Crepax, SP Rao ; Available at SSRN, 2020  papers.ssrn.com;;"… and Trace, Oracle Warranty Usage and Tracking), prod- uct authenticity (Oracle Product Lineage …

that cryptography is es- sential —rather than optional— to the workings of the blockchain … is very

obvious to associate security properties with terminologies like crypto- graphic keys …";Les 2 versions;;null;;;;https://scholar.google.com/scholar?start=230&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095327-1393;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Etude qualitative du profil, des caractéristiques et de l'organisation de l'offre de technologie blockchain en Wallonie.;O Marchal ;2020 matheo.uliege.be;;"… Etude qualitative du profil, des caractéristiques et de l'organisation de l'offre de technologie

blockchain en Wallonie … ÉTUDE QUALITATIVE DU PROFIL, DES CARACTÉRISTIQUES ET DE

L'ORGANISATION DE L'OFFRE DE TECHNOLOGIE BLOCKCHAIN EN WALLONIE …";Autres articles;Version HTML;[PDF] uliege.be;https://matheo.uliege.be/bitstream/2268.2/10273/8/MARCHAL_Olivier_s182302_M%C3%A9moire.pdf;;"""date"",""2020-09-12T02:03:21Z""
""pdf:PDFVersion"",""1.4""
""pdf:docinfo:title"",""Etude qualitative du profil, des caractĂŠristiques et de l'organisation de l'offre de technologie blockchain en Wallonie.""
""xmp:CreatorTool"",""MatheO - Master Thesis Online""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""Ces dernières années, la blockchain a souvent été citée parmi les nouvelles technologies à la mode. Il y a eu beaucoup d’émulation autour de son potentiel. Ses applications variées auraient la capacité de transformer les relations entre individus et de mener de nouvelles communautés vers une nouvelle ère de confiance. Qu’en est-t ’il concrètement sur le terrain ? 
Ce mémoire se concentre sur les fournisseurs de technologie blockchain en Wallonie. L’objectif principal est d’identifier leurs profils, caractéristiques et modes d’organisation en menant une étude qualitative orientée sur trois axes : le potentiel, les opportunités business et les modes d’adoption de la technologie. La conclusion principale de cette étude est un haut niveau de maturité et d’expertise des acteurs wallons avec une incapacité pour ceux-ci d’étendre leurs activités sur le marché local principalement à cause du manque de cas concrets d’application découlant d’une incompréhension de la technologie. Par rapport à cette problématique, le rôle des institutions et pouvoirs publics est discuté. Pour finir, nous proposons quelques recommandations afin d’éviter un déclin global de la maîtrise de la technologie en Wallonie.""
""language"",""fr""
""dc:format"",""application/pdf; version=1.4""
""pdf:docinfo:creator_tool"",""MatheO - Master Thesis Online""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""Etude qualitative du profil, des caractĂŠristiques et de l'organisation de l'offre de technologie blockchain en Wallonie.""
""modified"",""2020-09-12T02:03:21Z""
""cp:subject"",""Ces dernières années, la blockchain a souvent été citée parmi les nouvelles technologies à la mode. Il y a eu beaucoup d’émulation autour de son potentiel. Ses applications variées auraient la capacité de transformer les relations entre individus et de mener de nouvelles communautés vers une nouvelle ère de confiance. Qu’en est-t ’il concrètement sur le terrain ? 
Ce mémoire se concentre sur les fournisseurs de technologie blockchain en Wallonie. L’objectif principal est d’identifier leurs profils, caractéristiques et modes d’organisation en menant une étude qualitative orientée sur trois axes : le potentiel, les opportunités business et les modes d’adoption de la technologie. La conclusion principale de cette étude est un haut niveau de maturité et d’expertise des acteurs wallons avec une incapacité pour ceux-ci d’étendre leurs activités sur le marché local principalement à cause du manque de cas concrets d’application découlant d’une incompréhension de la technologie. Par rapport à cette problématique, le rôle des institutions et pouvoirs publics est discuté. Pour finir, nous proposons quelques recommandations afin d’éviter un déclin global de la maîtrise de la technologie en Wallonie.""
""pdf:docinfo:subject"",""Ces dernières années, la blockchain a souvent été citée parmi les nouvelles technologies à la mode. Il y a eu beaucoup d’émulation autour de son potentiel. Ses applications variées auraient la capacité de transformer les relations entre individus et de mener de nouvelles communautés vers une nouvelle ère de confiance. Qu’en est-t ’il concrètement sur le terrain ? 
Ce mémoire se concentre sur les fournisseurs de technologie blockchain en Wallonie. L’objectif principal est d’identifier leurs profils, caractéristiques et modes d’organisation en menant une étude qualitative orientée sur trois axes : le potentiel, les opportunités business et les modes d’adoption de la technologie. La conclusion principale de cette étude est un haut niveau de maturité et d’expertise des acteurs wallons avec une incapacité pour ceux-ci d’étendre leurs activités sur le marché local principalement à cause du manque de cas concrets d’application découlant d’une incompréhension de la technologie. Par rapport à cette problématique, le rôle des institutions et pouvoirs publics est discuté. Pour finir, nous proposons quelques recommandations afin d’éviter un déclin global de la maîtrise de la technologie en Wallonie.""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""Marchal, O.""
""meta:author"",""Marchal, O.""
""meta:creation-date"",""2020-09-12T02:03:21Z""
""created"",""2020-09-12T02:03:21Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-09-12T02:03:21Z""
""resourceName"",""MARCHAL_Olivier_s182302_M%C3%A9moire.pdf""
""Author"",""Marchal, O.""
""producer"",""Apache PDFBox""
""pdf:docinfo:producer"",""Apache PDFBox""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""Keywords"",""blockchain, wallonie, Gestion des systèmes d'information""
""access_permission:modify_annotations"",""true""
""dc:creator"",""Marchal, O.""
""dcterms:created"",""2020-09-12T02:03:21Z""
""Last-Modified"",""2020-09-12T02:03:21Z""
""dcterms:modified"",""2020-09-12T02:03:21Z""
""title"",""Etude qualitative du profil, des caractĂŠristiques et de l'organisation de l'offre de technologie blockchain en Wallonie.""
""Last-Save-Date"",""2020-09-12T02:03:21Z""
""pdf:docinfo:keywords"",""blockchain, wallonie, Gestion des systèmes d'information""
""pdf:docinfo:modified"",""2020-09-12T02:03:21Z""
""meta:save-date"",""2020-09-12T02:03:21Z""
""Content-Length"",""2792333""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Marchal, O.""
""dc:subject"",""blockchain, wallonie, Gestion des systèmes d'information""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""84""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""1678"",""399"",""757"",""1049"",""871"",""688"",""2869"",""2096"",""2210"",""2730"",""3113"",""2513"",""2766"",""2709"",""2584"",""2627"",""2825"",""2665"",""1441"",""2699"",""3026"",""2191"",""2367"",""2623"",""1532"",""2527"",""1341"",""2938"",""2825"",""2697"",""1172"",""1039"",""498"",""2772"",""1416"",""2552"",""2799"",""616"",""2133"",""2665"",""2756"",""2516"",""2940"",""3010"",""3100"",""2717"",""2621"",""2683"",""2915"",""2872"",""3010"",""2705"",""2817"",""2925"",""3023"",""2817"",""3159"",""2508"",""2576"",""2725"",""2751"",""3005"",""299"",""2521"",""1601"",""1688"",""2838"",""2312"",""584"",""2644"",""2856"",""2794"",""2843"",""2679"",""1866"",""2741"",""800"",""1836"",""2020"",""1867"",""897"",""50"",""528"",""2287""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""meta:keyword"",""blockchain, wallonie, Gestion des systèmes d'information""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-09-12T02:03:21Z""
";https://scholar.google.com/scholar?start=190&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095378-1607;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;From Agents to Blockchain: Stairway to Integration;G Ciatto, S Mariani, A Omicini, F Zambonelli ; Applied Sciences, 2020  mdpi.com;;"… the recent literature about smart contracts [18], such issues can be tackled through oracles, which

are … On the other side, we argue that the oracle-based approach is just a … this paper is twofold: We

present and discuss the dimensions of agent–blockchain integration (computation …";Cité 1 fois;Les 3 versions;[PDF] mdpi.com;https://www.mdpi.com/2076-3417/10/21/7460/pdf;;;https://scholar.google.com/scholar?start=410&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095397-1686;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;[PDF][PDF] Practical I-Voting on Stellar Blockchain;H Mora ; researchgate.net;;"… Whitepaper [10]. Initially, it offered one simple application––a ledger for transferring

Bitcoin cryptocurrency. Blockchain technology provides two vital properties that are

highly desirable in applications like i-voting. Immutability …";Autres articles;Version HTML;[PDF] researchgate.net;https://www.researchgate.net/profile/Stanislaw_Baranski/publication/344953640_Practical_I-Voting_on_Stellar_Blockchain/links/5f9ae29992851c14bcf0d276/Practical-I-Voting-on-Stellar-Blockchain.pdf;;;https://scholar.google.com/scholar?start=490&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095355-1506;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Black-box use of one-way functions is useless for optimal fair coin-tossing;HK Maji, M Wang ; Annual International Cryptology Conference, 2020  Springer;;"… CRYPTO 2020: Advances in Cryptology – CRYPTO 2020 pp 593-617 | Cite as … less functionalities,

lift the hardness of computation results in the information-theoretic plain model against

semi-honest adversaries to the random oracle model, ie, random oracles are useless …";Cité 5 fois;Les 4 versions;[PDF] iacr.org;https://eprint.iacr.org/2020/253.pdf;;"""date"",""2020-07-10T13:18:07Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2020-07-10T13:18:07Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.20 (TeX Live 2019) kpathsea version 6.3.1""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2020-07-10T13:18:07Z""
""created"",""2020-07-10T13:18:07Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-07-10T13:18:07Z""
""resourceName"",""253.pdf""
""Author"",""""
""producer"",""pdfTeX-1.40.20""
""pdf:docinfo:producer"",""pdfTeX-1.40.20""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""2"",""0"",""0"",""12"",""3"",""0"",""1"",""1"",""3"",""50"",""11"",""30"",""23"",""33"",""32"",""138"",""88"",""103"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2020-07-10T13:18:07Z""
""Last-Modified"",""2020-07-10T13:18:07Z""
""dcterms:modified"",""2020-07-10T13:18:07Z""
""title"",""""
""Last-Save-Date"",""2020-07-10T13:18:07Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2020-07-10T13:18:07Z""
""meta:save-date"",""2020-07-10T13:18:07Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.20 (TeX Live 2019) kpathsea version 6.3.1""
""Content-Length"",""610202""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""32""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""2949"",""903"",""3266"",""3374"",""2921"",""3461"",""3311"",""3489"",""3217"",""2135"",""2273"",""2015"",""3084"",""2532"",""2979"",""3121"",""2888"",""2652"",""1949"",""1385"",""1790"",""1738"",""3104"",""3247"",""3128"",""3300"",""3205"",""3142"",""2951"",""3153"",""3161"",""2208""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-07-10T13:18:07Z""
";https://scholar.google.com/scholar?start=310&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095283-1203;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Overcoming the blockchain oracle problem in the traceability of non-fungible products;G Caldarelli, C Rossignoli, A Zardini ; Sustainability, 2020  mdpi.com;;"Blockchain implications within the sustainability domain are rapidly arousing the interest of 
researchers and institutions. However, despite the avalanche of articles, papers, and 
recently published books, innovation in the blockchain domain is still heavily influenced by …";Cité 9 fois;Les 8 versions;[PDF] mdpi.com;https://www.mdpi.com/2071-1050/12/6/2391/pdf;;;
1619095285-1213;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;PRVB: Achieving Privacy-Preserving and Reliable Vehicular Crowdsensing via Blockchain Oracle;C Zhang, L Zhu, C Xu, K Sharif ; IEEE Transactions on …, 2020  ieeexplore.ieee.org;;"Vehicular crowdsensing is attracting more and more attention because of its wide sensing 
coverage and diverse usage in smart cities. However, privacy issues that stem from 
traditional vehicular crowdsensing scenarios, violate the participant's privacy. Although …";Autres articles;;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/25/4356907/09310698.pdf?casa_token=ERll-aEGjLYAAAAA:2x40EblkvciONHPIwcp5eUHcQzip9TsMbI_jIf9h1TudoD6dUWCLFpNrlOrwGqvemOwFSYQS8cU;;"""og:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""twitter:title"",""PRVB: Achieving Privacy-Preserving and Reliable Vehicular Crowdsensing via Blockchain Oracle""
""twitter:card"",""summary""
""Description"",""Vehicular crowdsensing is attracting more and more attention because of its wide sensing coverage and diverse usage in smart cities. However, privacy issues tha""
""og:title"",""PRVB: Achieving Privacy-Preserving and Reliable Vehicular Crowdsensing via Blockchain Oracle""
""resourceName"",""09310698.pdf""
""language"",""en""
""title"",""PRVB: Achieving Privacy-Preserving and Reliable Vehicular Crowdsensing via Blockchain Oracle | IEEE Journals & Magazine | IEEE Xplore""
""og:description"",""Vehicular crowdsensing is attracting more and more attention because of its wide sensing coverage and diverse usage in smart cities. However, privacy issues that stem from traditional vehicular crowdsensing scenarios, violate the participant's privacy. Although some privacy-preserving schemes have been designed that aim to protect the sensitive information of sensed data, the reliability cannot be guaranteed because of the system's centralized structure. The introduction of blockchain in crowdsensing applications provides reliable data storage, however, the reliability of data sources remains an open challenge. Under these circumstances, the crowdsourcing service requester may not be able to obtain quality data. To solve these problems, we propose a novel Privacy-preserving and Reliable Vehicular crowdsensing via Blockchain oracle, called PRVB. More specifically, a privacy-preserving vehicular data aggregation scheme is presented to protect the data privacy and unlinkability between participant vehicles and sensed data. Besides, two protocols are designed to protect data privacy and to achieve fair rewards for data providers. Thorough theoretical analysis and experimental evaluations have proved that the proposed PRVB achieves privacy protection, reliability, and fairness with significant computation & communication efficiency.""
""twitter:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-UA-Compatible"",""IE=Edge""
""viewport"",""width=device-width, initial-scale=1.0""
""dc:title"",""PRVB: Achieving Privacy-Preserving and Reliable Vehicular Crowdsensing via Blockchain Oracle | IEEE Journals & Magazine | IEEE Xplore""
""twitter:description"",""Vehicular crowdsensing is attracting more and more attention because of its wide sensing coverage and diverse usage in smart cities. However, privacy issues that stem from traditional vehicular crowdsensing scenarios, violate the participant's privacy. Although some privacy-preserving schemes have been designed that aim to protect the sensitive information of sensed data, the reliability cannot be guaranteed because of the system's centralized structure. The introduction of blockchain in crowdsensing applications provides reliable data storage, however, the reliability of data sources remains an open challenge. Under these circumstances, the crowdsourcing service requester may not be able to obtain quality data. To solve these problems, we propose a novel Privacy-preserving and Reliable Vehicular crowdsensing via Blockchain oracle, called PRVB. More specifically, a privacy-preserving vehicular data aggregation scheme is presented to protect the data privacy and unlinkability between participant vehicles and sensed data. Besides, two protocols are designed to protect data privacy and to achieve fair rewards for data providers. Thorough theoretical analysis and experimental evaluations have proved that the proposed PRVB achieves privacy protection, reliability, and fairness with significant computation & communication efficiency.""
""Content-Encoding"",""UTF-8""
""Content-Type-Hint"",""text/html; charset=utf-8""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=10&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095349-1479;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Smart contract derivatives;K Karantias, A Kiayias, D Zindros ; Mathematical Research for Blockchain …, 2020  Springer;;"… Previous work. Granting smart contracts access to data external to their blockchain environment

has been studied in the context of oracles in which additional trust assumptions are made by

the introduction of a trusted third party or committee [17] or in the form of an oracle [18] …";Cité 3 fois;Les 4 versions;[PDF] iacr.org;https://eprint.iacr.org/2020/138.pdf;;"""date"",""2020-02-09T01:52:42Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2020-02-09T01:52:42Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.19 (TeX Live 2018) kpathsea version 6.3.0""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2020-02-09T01:52:42Z""
""created"",""2020-02-09T01:52:42Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-02-09T01:52:42Z""
""resourceName"",""138.pdf""
""Author"",""""
""producer"",""pdfTeX-1.40.19""
""pdf:docinfo:producer"",""pdfTeX-1.40.19""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""1"",""0"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2020-02-09T01:52:42Z""
""Last-Modified"",""2020-02-09T01:52:42Z""
""dcterms:modified"",""2020-02-09T01:52:42Z""
""title"",""""
""Last-Save-Date"",""2020-02-09T01:52:42Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2020-02-09T01:52:42Z""
""meta:save-date"",""2020-02-09T01:52:42Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.19 (TeX Live 2018) kpathsea version 6.3.0""
""Content-Length"",""422034""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""8""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""1942"",""2009"",""2058"",""2130"",""1669"",""2274"",""2298"",""2601""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-02-09T01:52:42Z""
";https://scholar.google.com/scholar?start=280&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095397-1690;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;[HTML][HTML] BNRDT: When Data Transmission Meets Blockchain;H Jin, X Chen, X Lan, H Guo, H Zhang… ; Security and …, 2020  hindawi.com;United Kingdom;"Data transmission exists in almost all the Internet-based applications, while few of them consider

the property of nonrepudiation as part of data security. If a data transmission scheme is performed

without the endorsement of a trusted third party (TTP) or a central server, it is easy to …";Autres articles;;[HTML] hindawi.com;https://www.hindawi.com/journals/scn/2020/8828984/;;"""dc.publisher"",""Hindawi""
""og:image"",""https://images.hindawi.com/journals/scn/scn.banner.jpg""
""og:image:width"",""600""
""twitter:card"",""summary_large_image""
""citation_journal_title"",""Security and Communication Networks""
""language"",""en""
""og:description"",""Data transmission exists in almost all the Internet-based applications, while few of them consider the property of nonrepudiation as part of data security. If a data transmission scheme is performed without the endorsement of a trusted third party (TTP) or a central server, it is easy to raise disputes while transmitting valuable data, especially digital goods, because a dishonest participant can deny the fact of particular data transmission instance. The above problem can be solved by signing and encrypting. However, digital signature schemes usually assume public key infrastructure (PKI), increasing the burden on certificate management and are not suitable for distributed networks without TTP such as blockchain. To solve the above problems, we propose two new schemes for nonrepudiation data transmission based on blockchain (we call it BNRDT): one for short message transmission and the other for large file transmission. In BNRDT schemes, nonrepudiation evidence of data transmission is generated and stored on the blockchain to satisfy both the properties of nonrepudiation (including nonrepudiation of origin and nonrepudiation of receipt) and data confidentiality. We implement and test the schemes on Hyperledger Fabric. The experimental results show that the proposed schemes can provide appealing performance.""
""prism.issn"",""1939-0114""
""citation_issn"",""1939-0114""
""dc:title"",""BNRDT: When Data Transmission Meets Blockchain""
""Content-Encoding"",""UTF-8""
""citation_pdf_url"",""https://downloads.hindawi.com/journals/scn/2020/8828984.pdf""
""robots"",""index""
""google-site-verification"",""AxEuDsL7vXGOxRe53-uFhOk2ODN0bbXMeuBy6Pfq4ww""
""citation_author"",""Jin, Hongjian"",""Chen, Xingshu"",""Lan, Xiao"",""Guo, Hui"",""Zhang, Hongxia"",""Cao, Qi""
""dc.date"",""2020/11/18""
""prism.volume"",""2020""
""citation_doi"",""https://doi.org/10.1155/2020/8828984""
""prism.publicationName"",""Security and Communication Networks""
""dc.title"",""BNRDT: When Data Transmission Meets Blockchain""
""Author"",""Hindawi""
""citation_volume"",""2020""
""dc.language"",""en""
""Content-Language"",""en""
""authors"",""Hongjian Jin | Xingshu Chen | ... | Qi Cao""
""citation_title"",""BNRDT: When Data Transmission Meets Blockchain""
""citation_year"",""2020""
""citation_publisher"",""Hindawi""
""dc.format"",""text/html""
""description"",""Data transmission exists in almost all the Internet-based applications, while few of them consider the property of nonrepudiation as part of data security. If a data transmission scheme is performed without the endorsement of a trusted third party (TTP) or a central server, it is easy to raise disputes while transmitting valuable data, especially digital goods, because a dishonest participant can deny the fact of particular data transmission instance. The above problem can be solved by signing and encrypting. However, digital signature schemes usually assume public key infrastructure (PKI), increasing the burden on certificate management and are not suitable for distributed networks without TTP such as blockchain. To solve the above problems, we propose two new schemes for nonrepudiation data transmission based on blockchain (we call it BNRDT): one for short message transmission and the other for large file transmission. In BNRDT schemes, nonrepudiation evidence of data transmission is generated and stored on the blockchain to satisfy both the properties of nonrepudiation (including nonrepudiation of origin and nonrepudiation of receipt) and data confidentiality. We implement and test the schemes on Hyperledger Fabric. The experimental results show that the proposed schemes can provide appealing performance.""
""og:image:type"",""image/jpeg""
""citation_date"",""2020/11/18""
""title"",""BNRDT: When Data Transmission Meets Blockchain"",""BNRDT: When Data Transmission Meets Blockchain""
""twitter:image"",""https://images.hindawi.com/journals/scn/scn.banner.jpg""
""citation_online_date"",""2020/11/18""
""twitter:site"",""website""
""dc.type"",""Research Article""
""dc.source"",""Security and Communication Networks""
""dc.creator"",""Jin, Hongjian"",""Chen, Xingshu"",""Lan, Xiao"",""Guo, Hui"",""Zhang, Hongxia"",""Cao, Qi""
""citation_fulltext_html_url"",""https://www.hindawi.com/journals/scn/2020/8828984/""
""prism.publicationDate"",""2020/11/18""
""Content-Length"",""845545""
""citation_xml_url"",""https://downloads.hindawi.com/journals/scn/2020/8828984.xml""
""Content-Type"",""text/html; charset=UTF-8""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""og:type"",""website""
""twitter:title"",""BNRDT: When Data Transmission Meets Blockchain""
""dc.description"",""Data transmission exists in almost all the Internet-based applications, while few of them consider the property of nonrepudiation as part of data security. If a data transmission scheme is performed without the endorsement of a trusted third party (TTP) or a central server, it is easy to raise disputes while transmitting valuable data, especially digital goods, because a dishonest participant can deny the fact of particular data transmission instance. The above problem can be solved by signing and encrypting. However, digital signature schemes usually assume public key infrastructure (PKI), increasing the burden on certificate management and are not suitable for distributed networks without TTP such as blockchain. To solve the above problems, we propose two new schemes for nonrepudiation data transmission based on blockchain (we call it BNRDT): one for short message transmission and the other for large file transmission. In BNRDT schemes, nonrepudiation evidence of data transmission is generated and stored on the blockchain to satisfy both the properties of nonrepudiation (including nonrepudiation of origin and nonrepudiation of receipt) and data confidentiality. We implement and test the schemes on Hyperledger Fabric. The experimental results show that the proposed schemes can provide appealing performance.""
""og:title"",""BNRDT: When Data Transmission Meets Blockchain""
""citation_abstract"",""Data transmission exists in almost all the Internet-based applications, while few of them consider the property of nonrepudiation as part of data security. If a data transmission scheme is performed without the endorsement of a trusted third party (TTP) or a central server, it is easy to raise disputes while transmitting valuable data, especially digital goods, because a dishonest participant can deny the fact of particular data transmission instance. The above problem can be solved by signing and encrypting. However, digital signature schemes usually assume public key infrastructure (PKI), increasing the burden on certificate management and are not suitable for distributed networks without TTP such as blockchain. To solve the above problems, we propose two new schemes for nonrepudiation data transmission based on blockchain (we call it BNRDT): one for short message transmission and the other for large file transmission. In BNRDT schemes, nonrepudiation evidence of data transmission is generated and stored on the blockchain to satisfy both the properties of nonrepudiation (including nonrepudiation of origin and nonrepudiation of receipt) and data confidentiality. We implement and test the schemes on Hyperledger Fabric. The experimental results show that the proposed schemes can provide appealing performance.""
""og:image:height"",""315""
""prism.doi"",""https://doi.org/10.1155/2020/8828984""
""dcterms.issued"",""2020/11/18""
""viewport"",""width=device-width, initial-scale=1""
""twitter:description"",""Data transmission exists in almost all the Internet-based applications, while few of them consider the property of nonrepudiation as part of data security. If a data transmission scheme is performed without the endorsement of a trusted third party (TTP) or a central server, it is easy to raise disputes while transmitting valuable data, especially digital goods, because a dishonest participant can deny the fact of particular data transmission instance. The above problem can be solved by signing and encrypting. However, digital signature schemes usually assume public key infrastructure (PKI), increasing the burden on certificate management and are not suitable for distributed networks without TTP such as blockchain. To solve the above problems, we propose two new schemes for nonrepudiation data transmission based on blockchain (we call it BNRDT): one for short message transmission and the other for large file transmission. In BNRDT schemes, nonrepudiation evidence of data transmission is generated and stored on the blockchain to satisfy both the properties of nonrepudiation (including nonrepudiation of origin and nonrepudiation of receipt) and data confidentiality. We implement and test the schemes on Hyperledger Fabric. The experimental results show that the proposed schemes can provide appealing performance.""
""dc.identifier"",""https://doi.org/10.1155/2020/8828984""
""prism.section"",""Research Article""
""og:url"",""https://www.hindawi.com/journals/scn/2020/8828984/""
";https://scholar.google.com/scholar?start=490&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095386-1637;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Practical I-Voting on Stellar Blockchain;S Bara?ski, J Szyma?ski, A Sobecki, D Gil, H Mora ; Applied Sciences, 2020  mdpi.com;;"… Whitepaper [10]. Initially, it offered one simple application––a ledger for transferring

Bitcoin cryptocurrency. Blockchain technology provides two vital properties that are

highly desirable in applications like i-voting. Immutability …";Autres articles;;[PDF] mdpi.com;https://www.mdpi.com/2076-3417/10/21/7606/pdf;;;https://scholar.google.com/scholar?start=440&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095288-1218;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;[HTML][HTML] Blockchain for COVID-19: Review, Opportunities, and a Trusted Tracking System;D Marbouh, T Abbasi, F Maasmi, IA Omar… ; Arabian Journal for …, 2020  Springer;;"… We propose, implement, and evaluate a blockchain-based system using Ethereum

smart contracts and oracles to track reported data related to the number of new cases,

deaths, and recovered cases obtained from trusted sources …";Cité 20 fois;Les 13 versions;[HTML] springer.com;https://link.springer.com/article/10.1007/s13369-020-04950-4;;"""dc.publisher"",""Springer""
""og:image"",""https://media.springernature.com/w200/springer-static/cover/journal/13369.jpg""
""twitter:card"",""summary""
""og:site_name"",""Arabian Journal for Science and Engineering""
""citation_reference"",""WHO. Rolling updates on coronavirus disease (COVID-19). World Health Organization.  https://www.who.int/emergencies/diseases/novel-coronavirus-2019/events-as-they-happen  . Accessed 25 May 2020"",""Ramsay, G.: Japanese PM and IOC chief agree to postpone 2020 Olympics until 2021. CNN, 24 March 2020.  https://edition.cnn.com/2020/03/24/sport/olympics-postponement-tokyo-2020-spt-intl/index.html  . Accessed 25 May 2020"",""BIE Member States confirm one-year postponement for Expo 2020. Expo 2020 Dubai UAE.  https://www.expo2020dubai.com/en/whats-new/expo-stories/bie-announcement  . Accessed 25 May 2020"",""Houston, L.; Probst Y.; Humphries, A.: Measuring data quality through a source data verification audit in a clinical research setting. Stud Health Technol Inform (2015)"",""Bischoff, P.: COVID-19 App Tracker: Is privacy being sacrificed in a bid to combat the virus?. CompariTech, 20 April 2020.  https://www.comparitech.com/blog/vpn-privacy/coronavirus-apps/  . Accessed 25 May 2020"",""Warner, K.; Nowais, S.A.: Coronavirus: Doctors urge public to help track COVID-19 cases with tracing app. The National, 28 April 2020.  https://www.thenational.ae/uae/health/coronavirus-doctors-urge-public-to-help-track-covid-19-cases-with-tracing-app-1.1012267  . Accessed 25 May 2020"",""Tangermann, V.: Hackers are using coronavirus maps to spread malware. World Economic Forum, 14 March 2020.  https://www.weforum.org/agenda/2020/03/hackers-are-using-coronavirus-maps-to-spread-malware?fbclid=IwAR06Xux96s2GTy_-Ttew1Cuy96YV4ng9Z4eGd0kFVa-a_QbapumxgFO6DmU  . Accessed 25 May 2020"",""Villas-Boas, A.: A fake coronavirus tracking app is actually ransomware that threatens to leak social media accounts and delete a phone’s storage unless a victim pays $100 in bitcoin. Business Insider, 16 March 2020.  https://www.businessinsider.com/coronavirus-fake-app-ransomware-malware-bitcoin-android-demands-ransom-domaintools-2020-3  . Accessed 25 May 2020"",""Tesini, B.L.: MSD Manual. May 2020.  https://www.msdmanuals.com/professional/infectious-diseases/respiratory-viruses/coronaviruses-and-acute-respiratory-syndromes-covid-19,-mers,-and-sars#v47572273  . Accessed 3 June 2020"",""Readfearn, G.: How did coronavirus start and where did it come from? Was it really Wuhan’s animal market?. The Guardian, 28 April 2020.  https://www.theguardian.com/world/2020/apr/28/how-did-the-coronavirus-start-where-did-it-come-from-how-did-it-spread-humans-was-it-really-bats-pangolins-wuhan-animal-market  . Accessed 3 June 2020"",""Cennimo, D.J.: Coronavirus Disease 2019 (COVID-19). MedScape, 1 June 2020.  https://emedicine.medscape.com/article/2500114-overview#a9  . Accessed 3 June 2020"",""Coronavirus disease 2019 (COVID-19). MayoClinic, 22 May 2020.  https://www.mayoclinic.org/diseases-conditions/coronavirus/symptoms-causes/syc-20479963  . Accessed 3 June 2020"",""COVID-19 Dashboard by the Center for Systems Science and Engineering (CSSE). Johns Hopkins University, 2020.  https://gisanddata.maps.arcgis.com/apps/opsdashboard/index.html#/bda7594740fd40299423467b48e9ecf6  . Accessed 3 June 2020"",""Coronavirus Disease 2019 (COVID-19). CDC Center for Disease Control and Prevention, May 2020.  https://www.cdc.gov/coronavirus/2019-ncov/symptoms-testing/symptoms.html  . Accessed June 2020"",""Coronavirus disease (COVID-19): Prevention and risks. Government of Canada, 29 May 2020.  https://www.canada.ca/en/public-health/services/diseases/2019-novel-coronavirus-infection/prevention-risks.html  . Accessed 3 June 2020"",""How to Protect Yourself & Others. CDC Center of Disease Control and Prevention, 24 April 2020.  https://www.cdc.gov/coronavirus/2019-ncov/prevent-getting-sick/prevention.html  . Accessed 4 June 2020"",""Sandford, A.: Coronavirus: Half of humanity now on lockdown as 90 countries call for confinement. Euronews, 3 April 2020.  https://www.euronews.com/2020/04/02/coronavirus-in-europe-spain-s-death-toll-hits-10-000-after-record-950-new-deaths-in-24-hou  . Accessed 4 June 2020"",""Wright, R.: The world’s largest coronavirus lockdown is having a dramatic impact on pollution in India. CNN, 1 April 2020.  https://edition.cnn.com/2020/03/31/asia/coronavirus-lockdown-impact-pollution-india-intl-hnk/index.html  . Accessed 4 June 2020"",""Chico Harlan, S.P.: Italy extends coronavirus lockdown to entire country, imposing restrictions on 60 million people. Washington Post, 10 March 2020. Chico Harlan and [Accessed 4 June 2020"",""Carmen, R.S.; Reinhart, M.: How can we prevent a COVID-19 food crisis? World Economic Forum, May 2020.  https://www.weforum.org/agenda/2020/05/preventing-a-covid-19-food-crisis/  . Accessed 4 June 2020"",""A. F. et al.: Simulating SARS-CoV-2 epidemics by region-specific variables and modeling contact tracing App containment. MedRxiv (2020)"",""M. I.,. M. B.,. S. D.,. L. F. R. F. Chiara Farronato, “Harvard Business Review,” 15 July 2020. Chiara Farronato, Marco Iansiti, Marcin Bartosiak, Stefano Denicolai, Luca Ferretti and Roberto Fontana"",""MoHAP: Ministry of Health and Prevention. 25 April 2020.  https://www.mohap.gov.ae/en/MediaCenter/News/Pages/2385.aspx  "",""National Disinfection Programme and testing for COVID-19. UAE Government, 1 June 2020.  https://u.ae/en/information-and-services/justice-safety-and-the-law/handling-the-covid-19-outbreak/disinfection-and-testing-for-covid-19  . Accessed 4 June 2020"",""Khalid, T: UAE’s latest measures to contain the spread of the coronavirus: All the facts. Al Arabiya English, 21 March 2020.  https://english.alarabiya.net/en/News/gulf/2020/03/21/UAE-s-latest-measures-to-contain-the-spread-of-the-coronavirus-All-the-facts  . Accessed 4 June 2020"",""Zheng, Z.; Xie, S.; Dai, H.; Chen, X.; Wang, H.: An overview of blockchain technology: architecture, consensus, and future trends. In: IEEE 6th International Congress on Big Data, Honolulu (2017)"",""Rao, R.; Jain, H.: Improving Integrated Clinical Trial Management Systems through Blockchain. Genetic Engineering & Biotechnology News, Nov. 2019.  https://www.genengnews.com/insights/improving-integrated-clinical-trial-management-systems-through-blockchain/  . Accessed 27 May 2020"",""Glover, D.G.; Hermans, J.: Improving the Traceability of the Clinical Trial Supply Chain. Applied Clinical Trials, pp. 36–38, Nov./Dec. 2017"",""citation_journal_title=F1000Research; citation_title=Improving data transparency in clinical trials using blockchain smart contracts; citation_author=T Nugent, D Upton, M Cimpoesu; citation_volume=5; citation_publication_date=2017; citation_pages=1-4; citation_id=CR29"",""citation_journal_title=BioMed Central; citation_title=Blockchain technology for improving clinical research quality; citation_author=M Benchoufi, P Ravaud; citation_volume=18; citation_publication_date=2017; citation_pages=1-5; citation_id=CR30"",""Wright, T.: Blockchain App Used to Track COVID-19 Cases in Latin America. Coin Telegraph: The future of money, 6 April 2020.  https://cointelegraph.com/news/blockchain-app-used-to-track-covid-19-cases-in-latin-america  . Accessed 29 May 2020"",""Dragov, R.; Croce, C.L.; Hefny, M.: How Blockchain Can Help in the COVID-19 Crisis and Recovery. IDC-Analyze the Future, 4 May 2020.  https://blog-idcuk.com/blockchain-help-in-the-covid-19-and-recovery/  . Accessed 27 May 2020"",""Blockchain And Crypto Firm VeChain Utilized to Confirm Authenticity of Coronavirus KN95 Masks. Blockchain Magazine, 20 April 2020.  https://www.blockchainmagazine.net/blockchain-and-crypto-firm-vechain-utilized-to-confirm-authenticity-of-coronavirus-kn95-masks/  . Accessed 27 May 2020"",""Singh, G.; Levi, J.: MiPasa project and IBM Blockchain team on open data platform to support Covid-19 response. IBM, 27 March 2020.  https://www.ibm.com/blogs/blockchain/2020/03/mipasa-project-and-ibm-blockchain-team-on-open-data-platform-to-support-covid-19-response/  . Accessed 27 May 2020"",""Coalition: Help stop the spread.  https://www.coalitionnetwork.org/  . Accessed 27 May 2020"",""Joshi, M.: PHBC announces blockchain monitor to track virus-free zones. Cryptopolitan, 19 March 2020.  https://www.cryptopolitan.com/phbc-blockchain-monitor-for-virus-free-zones/  . Accessed 27 May 2020"",""citation_journal_title=J. Med. Syst.; citation_title=How can blockchain help people in the event of pandemics such as the COVID-19?; citation_author=MC Chang, D Park; citation_volume=44; citation_issue=102; citation_publication_date=2020; citation_pages=2020; citation_id=CR37"",""Zhang, J.: Chinese startup launches blockchain platform to improve donation efficiency,” Tech in Asia, 14 Feb. 2020.  https://www.techinasia.com/china-blockchain-platform-donation  . Accessed 27 May 2020"",""Acoer. Providing daily tracking and visualizations of the pandemic. Coronavirus (COVID-19) Tracker.  https://www.acoer.com/coronavirus  . Accessed 27 May 2020"",""Buterin, V.: Ethereum: A Next-Generation Smart Contract and Decentralized Application Platform. White Paper, 2013.  http://blockchainlab.com/pdf/Ethereum_white_paper-a_next_generation_smart_contract_and_decentralized_application_platform-vitalik-buterin.pdf  . Accessed 19 Jan. 2020"",""Hasan, H.; Salah, K.: Blockchain-based solution for proof of delivery of physical assets. In: Proceedings of the 2018 International Conference on Blockchain (ICBC 2018). Springer LNCS, Seattle, USA, June 25–June 30, 2018"",""Optimizing your Solidity contract’s gas usage. Medium, 5 April 2018.  https://medium.com/coinmonks/optimizing-your-solidity-contracts-gas-usage-9d65334db6c7  . Accessed 9 March 2020"",""Eth Gas Station.  https://ethgasstation.info/calculatorTxV.php  . Accessed 10 April 2020"",""Piscini, E.; Dalton, D.; Kehoe, L.: Blockchain & Cybersecurity Point of View. Deloitte, 2017.  https://www2.deloitte.com/content/dam/Deloitte/ie/Documents/Technology/IE_C_BlockchainandCyberPOV_0417.pdf  . Accessed 2 June 2020"",""citation_journal_title=Sensors; citation_title=Chaotic image encryption using hopfield and hindmarsh-rose neurons implemented on FPGA; citation_author=E Tlelo-Cuautle, J Díaz-Muñoz, A González-Zapata, R Li, W León-Salas, F Fernández, O Guillén-Fernández, I Cruz-Vega; citation_volume=20; citation_issue=5; citation_publication_date=2020; citation_pages=1326; citation_doi=10.3390/s20051326; citation_id=CR45"",""citation_journal_title=IEEE Access; citation_title=Blockchain-based soybean traceability in agricultural supply chain; citation_author=K Salah, N Nizamuddin, R Jayaraman, M Omar; citation_volume=7; citation_issue=1; citation_publication_date=2019; citation_pages=73295-73305; citation_doi=10.1109/ACCESS.2019.2918000; citation_id=CR46"",""I. d. Marco. 3 ways organizations are dealing with the blockchain developer shortage. Venture Beat, 28 Jan 2018.  https://venturebeat.com/2018/01/28/3-ways-organizations-are-dealing-with-the-blockchain-developer-shortage/  . Accessed 1 June 2020"",""van den Hooff, J.; Kaashoek, M.F.; Zeldovich, N.: VerSum: verifiable computations over large public logs. In: Proceedings of the 2014 ACM SIGSAC Conference on Computer and Communications Security, New York (2014)"",""Solat, S.; Potop-Butucaru, M.: ZeroBlock: Timestamp-Free Prevention of Block-Withholding Attack in Bitcoin. May 2016""
""citation_journal_title"",""Arabian Journal for Science and Engineering""
""language"",""en""
""citation_cover_date"",""2020/12/01""
""og:description"",""The sudden development of the COVID-19 pandemic has exposed the limitations in modern healthcare systems to handle public health emergencies. It is evident that adopting innovative technologies such as blockchain can help in effective planning operations and resource deployments. Blockchain technology can play an important role in the healthcare sector, such as improved clinical trial data management by reducing delays in regulatory approvals, and streamline the communication between diverse stakeholders of the supply chain, etc. Moreover, the spread of misinformation has intensely increased during the outbreak, and existing platforms lack the ability to validate the authenticity of data, leading to public panic and irrational behavior. Thus, developing a blockchain-based tracking system is important to ensure that the information received by the public and government agencies is reliable and trustworthy. In this paper, we review various blockchain applications and opportunities in combating the COVID-19 pandemic and develop a tracking system for the COVID-19 data collected from various external sources. We propose, implement, and evaluate a blockchain-based system using Ethereum smart contracts and oracles to track reported data related to the number of new cases, deaths, and recovered cases obtained from trusted sources. We present detailed algorithms that capture the interactions between stakeholders in the network. We present security analysis and the cost incurred by the stakeholders, and we highlight the challenges and future directions of our work. Our work demonstrates that the proposed solution is economically feasible and ensures data integrity, security, transparency, data traceability among stakeholders.""
""prism.issn"",""2191-4281""
""citation_author_email"",""khaled.salah@ku.ac.ae""
""twitter:image:alt"",""Content cover image""
""prism.number"",""12""
""citation_issn"",""2191-4281""
""citation_language"",""en""
""dc:title"",""Blockchain for COVID-19: Review, Opportunities, and a Trusted Tracking System | SpringerLink""
""Content-Encoding"",""UTF-8""
""citation_pdf_url"",""https://link.springer.com/content/pdf/10.1007/s13369-020-04950-4.pdf""
""citation_lastpage"",""9911""
""DOI"",""10.1007/s13369-020-04950-4""
""citation_fulltext_world_readable"",""""
""citation_journal_abbrev"",""Arab J Sci Eng""
""prism.rightsAgent"",""journalpermissions@springernature.com""
""citation_author"",""Dounia Marbouh"",""Tayaba Abbasi"",""Fatema Maasmi"",""Ilhaam A. Omar"",""Mazin S. Debe"",""Khaled Salah"",""Raja Jayaraman"",""Samer Ellahham""
""resourceName"",""s13369-020-04950-4""
""dc.date"",""2020-10-12""
""citation_springer_api_url"",""http://api.springer.com/metadata/pam?q=doi:10.1007/s13369-020-04950-4&api_key=""
""citation_issue"",""12""
""prism.volume"",""45""
""prism.publicationName"",""Arabian Journal for Science and Engineering""
""citation_doi"",""10.1007/s13369-020-04950-4""
""dc.title"",""Blockchain for COVID-19: Review, Opportunities, and a Trusted Tracking System""
""prism.url"",""https://link.springer.com/article/10.1007/s13369-020-04950-4""
""citation_volume"",""45""
""dc.language"",""En""
""Content-Language"",""en""
""format-detection"",""telephone=no""
""citation_publication_date"",""2020/12""
""prism.endingPage"",""9911""
""citation_title"",""Blockchain for COVID-19: Review, Opportunities, and a Trusted Tracking System""
""citation_author_institution"",""Department of Industrial and Systems Engineering, Khalifa University, Abu Dhabi, United Arab Emirates"",""Department of Electrical and Computer Engineering, Khalifa University, Abu Dhabi, United Arab Emirates"",""Department of Electrical and Computer Engineering, Khalifa University, Abu Dhabi, United Arab Emirates"",""Department of Industrial and Systems Engineering, Khalifa University, Abu Dhabi, United Arab Emirates"",""Department of Electrical and Computer Engineering, Khalifa University, Abu Dhabi, United Arab Emirates"",""Department of Electrical and Computer Engineering, Khalifa University, Abu Dhabi, United Arab Emirates"",""Department of Industrial and Systems Engineering, Khalifa University, Abu Dhabi, United Arab Emirates"",""Heart and Vascular Institute, Cleveland Clinic Abu Dhabi, Abu Dhabi, United Arab Emirates""
""access"",""Yes""
""citation_publisher"",""Springer Berlin Heidelberg""
""applicable-device"",""pc,mobile""
""dc.format"",""text/html""
""description"",""The sudden development of the COVID-19 pandemic has exposed the limitations in modern healthcare systems to handle public health emergencies. It is evident""
""title"",""Blockchain for COVID-19: Review, Opportunities, and a Trusted Tracking System | SpringerLink""
""citation_online_date"",""2020/10/12""
""twitter:site"",""@SpringerLink""
""dc.source"",""Arabian Journal for Science and Engineering 2020 45:12""
""dc.type"",""ReviewPaper""
""dc.copyright"",""2020 King Fahd University of Petroleum & Minerals""
""dc.creator"",""Dounia Marbouh"",""Tayaba Abbasi"",""Fatema Maasmi"",""Ilhaam A. Omar"",""Mazin S. Debe"",""Khaled Salah"",""Raja Jayaraman"",""Samer Ellahham""
""citation_fulltext_html_url"",""https://link.springer.com/article/10.1007/s13369-020-04950-4""
""prism.publicationDate"",""2020-10-12""
""Content-Type"",""text/html; charset=UTF-8""
""journal_id"",""13369""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""dc.description"",""The sudden development of the COVID-19 pandemic has exposed the limitations in modern healthcare systems to handle public health emergencies. It is evident that adopting innovative technologies such as blockchain can help in effective planning operations and resource deployments. Blockchain technology can play an important role in the healthcare sector, such as improved clinical trial data management by reducing delays in regulatory approvals, and streamline the communication between diverse stakeholders of the supply chain, etc. Moreover, the spread of misinformation has intensely increased during the outbreak, and existing platforms lack the ability to validate the authenticity of data, leading to public panic and irrational behavior. Thus, developing a blockchain-based tracking system is important to ensure that the information received by the public and government agencies is reliable and trustworthy. In this paper, we review various blockchain applications and opportunities in combating the COVID-19 pandemic and develop a tracking system for the COVID-19 data collected from various external sources. We propose, implement, and evaluate a blockchain-based system using Ethereum smart contracts and oracles to track reported data related to the number of new cases, deaths, and recovered cases obtained from trusted sources. We present detailed algorithms that capture the interactions between stakeholders in the network. We present security analysis and the cost incurred by the stakeholders, and we highlight the challenges and future directions of our work. Our work demonstrates that the proposed solution is economically feasible and ensures data integrity, security, transparency, data traceability among stakeholders.""
""og:type"",""article""
""citation_article_type"",""Review--Computer Engineering and Computer Science ""
""og:title"",""Blockchain for COVID-19: Review, Opportunities, and a Trusted Tracking System""
""prism.doi"",""doi:10.1007/s13369-020-04950-4""
""X-UA-Compatible"",""IE=edge""
""citation_firstpage"",""9895""
""prism.startingPage"",""9895""
""viewport"",""width=device-width, initial-scale=1""
""dc.rightsAgent"",""journalpermissions@springernature.com""
""prism.section"",""ReviewPaper""
""dc.identifier"",""doi:10.1007/s13369-020-04950-4""
""dc.subject"",""Engineering, general"",""Science, Humanities and Social Sciences, multidisciplinary""
""og:url"",""https://link.springer.com/article/10.1007/s13369-020-04950-4""
""prism.copyright"",""2020 King Fahd University of Petroleum & Minerals""
";https://scholar.google.com/scholar?start=20&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095313-1328;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;BC-SABE: Blockchain-Aided Searchable Attribute-Based Encryption for Cloud-IoT;S Liu, J Yu, Y Xiao, Z Wan, S Wang… ; IEEE Internet of Things …, 2020  ieeexplore.ieee.org;;"… st, {?i,?i}i?Ac ) to A. 2) Query Phase I: A queries the following oracles adaptively … PKUID) in the

list L. Finally, it returns SKUID to A. b) PubDecKey Oracle: A submits … LIU et al.: BC-SABE:

BLOCKCHAIN-AIDED SEARCHABLE ATTRIBUTE-BASED ENCRYPTION FOR CLOUD-IoT …";Cité 4 fois;;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/6488907/6702522/09090206.pdf?casa_token=R-wJVtONXJkAAAAA:9S_QpFdNjrQZOxVJKbbZI4ygv9CFSiuh77f5mBhcu5jcIOU5QPoxQme1Mmju62wHaUv7SmwS8u4;;"""og:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""twitter:title"",""BC-SABE: Blockchain-Aided Searchable Attribute-Based Encryption for Cloud-IoT""
""twitter:card"",""summary""
""Description"",""The Internet of Things (IoT) changed our lives with huge amounts of data production. Due to source-limited IoT devices, one of the best ways to process the data""
""og:title"",""BC-SABE: Blockchain-Aided Searchable Attribute-Based Encryption for Cloud-IoT""
""resourceName"",""09090206.pdf""
""language"",""en""
""title"",""BC-SABE: Blockchain-Aided Searchable Attribute-Based Encryption for Cloud-IoT | IEEE Journals & Magazine | IEEE Xplore""
""og:description"",""The Internet of Things (IoT) changed our lives with huge amounts of data production. Due to source-limited IoT devices, one of the best ways to process the data is cloud storage. However, a series of security and privacy issues arise, such as illegal data access, data tampering, and privacy leak. Though symmetric encryption can guarantee data confidentiality, it cannot realize fine-grained data sharing and searching. The keyword-based searchable attribute-based encryption (KSABE) can achieve data confidentiality and fine-grained access control. More importantly, it realizes a keyword-based search for data users. However, the heavy decryption computation burden and the management of massive user keys appear when implementing attribute-based encryption schemes to IoT. Therefore, this article proposes a blockchain-aided searchable attribute-based encryption (BC-SABE) with efficient revocation and decryption, where the traditional centralized server is replaced with a decentralized blockchain system being in charge of the threshold parameter generation, key management, and user revocation. All revocation tasks are done by the blockchain and it is on longer necessary for ciphertext reencryption and key update. Moreover, users utilize the coalition blockchain to generate partial tokens. Besides, the cloud server contained in our scheme not only stores the massive encrypted data but also performs search and predecryption for users who only require one exponentiation in the group G to decrypt fully. Security analyses prove that our scheme realizes the security under the chosen plaintext attack and the chosen keyword attack. Simulations show that the decryption and token generation cost of our scheme are preferable.""
""twitter:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-UA-Compatible"",""IE=Edge""
""viewport"",""width=device-width, initial-scale=1.0""
""dc:title"",""BC-SABE: Blockchain-Aided Searchable Attribute-Based Encryption for Cloud-IoT | IEEE Journals & Magazine | IEEE Xplore""
""twitter:description"",""The Internet of Things (IoT) changed our lives with huge amounts of data production. Due to source-limited IoT devices, one of the best ways to process the data is cloud storage. However, a series of security and privacy issues arise, such as illegal data access, data tampering, and privacy leak. Though symmetric encryption can guarantee data confidentiality, it cannot realize fine-grained data sharing and searching. The keyword-based searchable attribute-based encryption (KSABE) can achieve data confidentiality and fine-grained access control. More importantly, it realizes a keyword-based search for data users. However, the heavy decryption computation burden and the management of massive user keys appear when implementing attribute-based encryption schemes to IoT. Therefore, this article proposes a blockchain-aided searchable attribute-based encryption (BC-SABE) with efficient revocation and decryption, where the traditional centralized server is replaced with a decentralized blockchain system being in charge of the threshold parameter generation, key management, and user revocation. All revocation tasks are done by the blockchain and it is on longer necessary for ciphertext reencryption and key update. Moreover, users utilize the coalition blockchain to generate partial tokens. Besides, the cloud server contained in our scheme not only stores the massive encrypted data but also performs search and predecryption for users who only require one exponentiation in the group G to decrypt fully. Security analyses prove that our scheme realizes the security under the chosen plaintext attack and the chosen keyword attack. Simulations show that the decryption and token generation cost of our scheme are preferable.""
""Content-Encoding"",""UTF-8""
""Content-Type-Hint"",""text/html; charset=utf-8""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=130&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095304-1287;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Sok: A consensus taxonomy in the blockchain era;J Garay, A Kiayias ; Cryptographers' Track at the RSA Conference, 2020  Springer;;"… to blockchain protocols, including amortization resistance, sampleability, fast verification, hardness

against tampering and message attacks, and almost k-wise independence [71]. Some variants

of PoWs have been shown to imply one-way functions [22]. The Random Oracle …";Cité 73 fois;Les 5 versions;[PDF] allquantor.at;https://allquantor.at/blockchainbib/pdf/garay2018sok.pdf;;"""date"",""2019-12-09T00:47:57Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2019-12-09T00:47:57Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016) kpathsea version 6.2.2""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2019-12-09T00:47:57Z""
""created"",""2019-12-09T00:47:57Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-12-09T00:47:57Z""
""resourceName"",""garay2018sok.pdf""
""Author"",""""
""producer"",""pdfTeX-1.40.17""
""pdf:docinfo:producer"",""pdfTeX-1.40.17""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""1"",""0"",""0"",""2"",""0"",""0"",""0"",""0"",""0"",""4"",""0"",""0"",""0"",""0"",""16"",""1"",""6"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""3""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2019-12-09T00:47:57Z""
""Last-Modified"",""2019-12-09T00:47:57Z""
""dcterms:modified"",""2019-12-09T00:47:57Z""
""title"",""""
""Last-Save-Date"",""2019-12-09T00:47:57Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2019-12-09T00:47:57Z""
""meta:save-date"",""2019-12-09T00:47:57Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016) kpathsea version 6.2.2""
""Content-Length"",""881971""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""31""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""2521"",""3502"",""3762"",""3270"",""3143"",""3437"",""3254"",""3602"",""2954"",""2944"",""1081"",""3850"",""3836"",""3718"",""3805"",""3823"",""3809"",""3573"",""3183"",""3626"",""2020"",""3804"",""3098"",""3188"",""3251"",""2937"",""3225"",""3312"",""3341"",""1943"",""1944""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-12-09T00:47:57Z""
";https://scholar.google.com/scholar?start=90&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095302-1283;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Medical data sharing scheme based on attribute cryptosystem and blockchain technology;X Yang, T Li, X Pei, L Wen, C Wang ; IEEE Access, 2020  ieeexplore.ieee.org;;"… medical data are stored in the cloud, and the storage address and medical-related information

are written into the blockchain, which can … results of the analysis show that our scheme satisfies

the requirements for confidentiality and unforgeability in the random oracle model, and …";Cité 8 fois;;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/6287639/8948470/09016179.pdf;;"""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""dc:title"",""IEEE Xplore Full-Text PDF:""
""Content-Encoding"",""UTF-8""
""resourceName"",""09016179.pdf""
""language"",""es""
""Content-Length"",""2565""
""title"",""IEEE Xplore Full-Text PDF:""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=80&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095316-1339;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Mediating data trustworthiness by using trusted hardware between iot devices and blockchain;B Enkhtaivan, A Inoue ; … Conference on Smart Internet of Things …, 2020  ieeexplore.ieee.org;;"… 7] “Blockchain oracles, explained,” https://cointelegraph.com/explained/ blockchain-oracles-

explained, accessed: 2019-12-02. [8] J. Adler, R. Berryhill, AG Veneris, Z. Poulos, N. Veira, and

A. Kas- tania, “Astraea: A decentralized blockchain oracle,” 2018 IEEE Inter- national …";Cité 1 fois;Les 2 versions;null;;;;https://scholar.google.com/scholar?start=140&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095346-1471;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Blockchain IoT for smart electric vehicles battery management;BC Florea, DD Taralunga ; Sustainability, 2020  mdpi.com;;"… The first blockchain application was introduced in [10], where the cryptocurrency

Bitcoin was introduced, with the goal to replace the trust provided by a 3rd party with

proof. The term blockchain suggests that the network consists …";Cité 6 fois;Les 6 versions;[PDF] mdpi.com;https://www.mdpi.com/2071-1050/12/10/3984/pdf;;;https://scholar.google.com/scholar?start=270&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095355-1509;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;An Anti-Quantum Signature Scheme over Ideal Lattice in Blockchain;J Di, T Xie, S Fan, W Jia, S Fu ; 2020 International Symposium …, 2020  ieeexplore.ieee.org;;"… To ensure the security of transactions in blockchain based on our signature scheme in

quantum age, we reduce our scheme to the hardness assumption of the ISIS problem.

The properties of random oracle play an important role in our proof …";Les 2 versions;;null;;;;https://scholar.google.com/scholar?start=310&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095339-1443;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Pay as you decrypt: Decryption outsourcing for functional encryption using blockchain;H Cui, Z Wan, X Wei, S Nepal… ; IEEE Transactions on …, 2020  ieeexplore.ieee.org;;"… FEPOD) schemes. The payment in an FEPOD scheme is achieved through a

blockchain-based cryptocurrency, which enables the user to pay a third party when

it correctly completes the outsourced decryption. We define the …";Cité 4 fois;Les 2 versions;[PDF] researchgate.net;https://www.researchgate.net/profile/Hui-Cui-4/publication/339248714_Pay_as_You_Decrypt_Decryption_Oursoucing_for_Functional_Encryption_Using_Blockchain/links/60482995a6fdcc9c782530a3/Pay-as-You-Decrypt-Decryption-Oursoucing-for-Functional-Encryption-Using-Blockchain.pdf;;;https://scholar.google.com/scholar?start=240&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095309-1309;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;[PDF][PDF] Melmint: trustless stable cryptocurrency;Y Dong, R Boutaba ; Cryptoeconomic Systems, 2020  rboutaba.cs.uwaterloo.ca;;"… do exist, measuring facts external to the cryptoeconomic mechanism — the “oracle problem” —

is … Attempts at making decentralized oracles, such as SchellingCoin, typically fall to clever game …

We conclude pegging to blockchain-external currencies is probably not the right path …";Cité 4 fois;Les 3 versions;[PDF] uwaterloo.ca;http://rboutaba.cs.uwaterloo.ca/Papers/Conferences/2020/DongCRYPTOECONSYS20.pdf;;"""date"",""2020-01-31T16:25:20Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2020-01-31T16:25:20Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.19 (TeX Live 2019/dev/Debian) kpathsea version 6.3.1/dev""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2020-01-31T16:25:20Z""
""created"",""2020-01-31T16:25:20Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-01-31T16:25:20Z""
""resourceName"",""DongCRYPTOECONSYS20.pdf""
""Author"",""""
""producer"",""pdfTeX-1.40.19""
""pdf:docinfo:producer"",""pdfTeX-1.40.19""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""2"",""2"",""0"",""0"",""0"",""0"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2020-01-31T16:25:20Z""
""Last-Modified"",""2020-01-31T16:25:20Z""
""dcterms:modified"",""2020-01-31T16:25:20Z""
""title"",""""
""Last-Save-Date"",""2020-01-31T16:25:20Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2020-01-31T16:25:20Z""
""meta:save-date"",""2020-01-31T16:25:20Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.19 (TeX Live 2019/dev/Debian) kpathsea version 6.3.1/dev""
""Content-Length"",""433455""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""11""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""3705"",""4434"",""4482"",""4351"",""4750"",""3828"",""4367"",""4329"",""4753"",""3996"",""1104""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-01-31T16:25:20Z""
";https://scholar.google.com/scholar?start=110&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095397-1693;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Cryptocurrency: permanent money substitute or another temporary trend;?? ???????????, ?? ?????????… ; ??????? …, 2020  elibrary.ru;;"… It might be the turning point that takes Bitcoin from a specialty, unsteady resource to a standard

frame of payment” (Oracles, 2019) … Besides, there is the possibility that crypto will be drifted on

the Nasdaq, which would further add credibility to blockchain and its uses as an …";;null;null;;;;https://scholar.google.com/scholar?start=490&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095297-1262;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;HCloud: A trusted JointCloud serverless platform for IoT systems with blockchain;Z Huang, Z Mi, Z Hua ; China Communications, 2020  ieeexplore.ieee.org;;"… Oracle is a kind of data feed ser- vice transferring data from external world to blockchain in a

verifiable way. Existing oracle solutions mainly consists of centralized ora- cles (eg, Oraclize

[9], Town Crier [10]) and decentralized oracles(eg, Chainlink [11]). III. SYSTEM DESIGN …";Autres articles;;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/6245522/9205968/09205972.pdf?casa_token=7n1AVLE5zgoAAAAA:tWqnz7YBsg1j-rLvodABunxy0-NOnj36I9dI1Y5_U12QRJkKuXK8C8KXpmJs1PlSkMotRfLz87A;;"""og:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""twitter:title"",""HCloud: A trusted JointCloud serverless platform for IoT systems with blockchain""
""twitter:card"",""summary""
""Description"",""Cloud computing has been exploited in managing large-scale IoT systems. IoT cloud servers usually handle a large number of requests from various IoT devices. Du""
""og:title"",""HCloud: A trusted JointCloud serverless platform for IoT systems with blockchain""
""resourceName"",""09205972.pdf""
""language"",""en""
""title"",""HCloud: A trusted JointCloud serverless platform for IoT systems with blockchain | IEEE Journals & Magazine | IEEE Xplore""
""og:description"",""Cloud computing has been exploited in managing large-scale IoT systems. IoT cloud servers usually handle a large number of requests from various IoT devices. Due to the fluctuant and heavy workload, the servers require the cloud to provide high scalability, stable performance, low price and necessary functionalities. However, traditional clouds usually offer computing service with the abstraction of virtual machine (VM), which can hardly meet these requirements. Meanwhile, different cloud vendors provide different performance stabilities and price models, which fluctuate according to the dynamic workload. A single cloud cannot satisfy all the requirements of the IoT scenario well. The JointCloud computing model empowers the cooperation among multiple public clouds. However, it is still difficult to dynamically schedule the workload on different clouds based on the VM abstraction. This paper introduces HCloud, a trusted JointCloud platform for IoT systems using serverless computing model. HCloud allows an IoT server to be implemented with multiple serverless functions and schedules these functions on different clouds based on a schedule policy. The policy is specified by the client and includes the required functionalities, execution resources, latency, price and so on. HCloud collects the status of each cloud and dispatches serverless functions to the most suitable cloud based on the schedule policy. By leveraging the blockchain technology, we further enforce that our system can neither fake the cloud status nor wrongly dispatch the target functions. We have implemented a prototype of HCloud and evaluated it by simulating multiple cloud providers. The evaluation results show that HCloud can greatly improve the performance of serverless workloads with negligible costs.""
""twitter:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-UA-Compatible"",""IE=Edge""
""viewport"",""width=device-width, initial-scale=1.0""
""dc:title"",""HCloud: A trusted JointCloud serverless platform for IoT systems with blockchain | IEEE Journals & Magazine | IEEE Xplore""
""twitter:description"",""Cloud computing has been exploited in managing large-scale IoT systems. IoT cloud servers usually handle a large number of requests from various IoT devices. Due to the fluctuant and heavy workload, the servers require the cloud to provide high scalability, stable performance, low price and necessary functionalities. However, traditional clouds usually offer computing service with the abstraction of virtual machine (VM), which can hardly meet these requirements. Meanwhile, different cloud vendors provide different performance stabilities and price models, which fluctuate according to the dynamic workload. A single cloud cannot satisfy all the requirements of the IoT scenario well. The JointCloud computing model empowers the cooperation among multiple public clouds. However, it is still difficult to dynamically schedule the workload on different clouds based on the VM abstraction. This paper introduces HCloud, a trusted JointCloud platform for IoT systems using serverless computing model. HCloud allows an IoT server to be implemented with multiple serverless functions and schedules these functions on different clouds based on a schedule policy. The policy is specified by the client and includes the required functionalities, execution resources, latency, price and so on. HCloud collects the status of each cloud and dispatches serverless functions to the most suitable cloud based on the schedule policy. By leveraging the blockchain technology, we further enforce that our system can neither fake the cloud status nor wrongly dispatch the target functions. We have implemented a prototype of HCloud and evaluated it by simulating multiple cloud providers. The evaluation results show that HCloud can greatly improve the performance of serverless workloads with negligible costs.""
""Content-Encoding"",""UTF-8""
""Content-Type-Hint"",""text/html; charset=utf-8""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=60&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095297-1259;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;[HTML][HTML] Proof of witness presence: blockchain consensus for augmented democracy in smart cities;E Pournaras ; Journal of Parallel and Distributed Computing, 2020  Elsevier;;"… Volume 145, November 2020, Pages 160-175. Journal of Parallel and Distributed Computing.

Proof of witness presence: Blockchain consensus for augmented democracy in smart cities … An

augmented democracy paradigm for Smart Cities using blockchain consensus. • …";Cité 8 fois;Les 7 versions;[HTML] sciencedirect.com;https://www.sciencedirect.com/science/article/pii/S0743731520303282?casa_token=GRPqulOX86cAAAAA:MGi2zxqIysDEn3c0fjDnGEfL602KWqH3d9K8HpbAu4M_g6rBLF80vxwSiRen8OXw29tXVkj9;;;https://scholar.google.com/scholar?start=60&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095381-1618;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;[HTML][HTML] Finanzwirtschaftliche Anwendungen der Blockchain-Technologie;P Schuster, E Theissen, M Uhrig;Homburg  Schmalenbachs Zeitschrift für …, 2020  Springer;;"… Abstract. The blockchain technology was first implemented in 2009 as the basis of the

cryptocurrency Bitcoin … Einschränkend ist zu beachten, dass sämtliche Vertragsinformationen

in der Blockchain vorhanden oder über Oracles eingebunden werden müssen …";Autres articles;;[HTML] springer.com;https://link.springer.com/article/10.1007/s41471-020-00090-5;;"""dc.publisher"",""Springer""
""og:image"",""https://media.springernature.com/w200/springer-static/cover/journal/41471.jpg""
""twitter:card"",""summary""
""og:site_name"",""Schmalenbach Journal of Business Research""
""citation_reference"",""citation_journal_title=Purakala; citation_title=Blockchain technology in banking and finance sector: Its effects and challenges; citation_author=AD Amin; citation_volume=31; citation_issue=13; citation_publication_date=2020; citation_pages=349-358; citation_id=CR1"",""citation_title=The economics of distributed ledger technology for securities settlement; citation_publication_date=2017; citation_id=CR2; citation_author=E Benos; citation_author=R Garratt; citation_author=P Gurrola-Perez"",""citation_title=Bitcoin, Blockchain und Kryptoassets; citation_publication_date=2017; citation_id=CR3; citation_author=A Berentsen; citation_author=F Schär; citation_publisher=Books on Demand"",""citation_journal_title=Review of Finance; citation_title=Stealth trading and trade reporting by corporate insiders; citation_author=A Betzer, J Gider, D Metzger, E Theissen; citation_volume=19; citation_publication_date=2015; citation_pages=865-905; citation_doi=10.1093/rof/rfu007; citation_id=CR4"",""citation_title=Bitcoin exchange rates: How integrated are markets?; citation_publication_date=2019; citation_id=CR5; citation_author=A Brauneis; citation_author=R Mestel; citation_author=R Riordan; citation_author=E Theissen"",""citation_journal_title=Cambridge Journal of Economics; citation_title=The transaction costs and benefits of the incomplete employment contract; citation_author=K Cartier; citation_volume=18; citation_publication_date=1994; citation_pages=181-196; citation_id=CR6"",""citation_journal_title=Journal of Business Venturing Insights; citation_title=Blockchain disruption and decentralized finance: The rise of decentralized business models; citation_author=Y Chen, C Bellavitis; citation_volume=13; citation_publication_date=2020; citation_pages=e00151; citation_doi=10.1016/j.jbvi.2019.e00151; citation_id=CR7"",""citation_journal_title=Review of Financial Studies; citation_title=Blockchain-based settlement for asset trading; citation_author=J Chiu, T Koeppl; citation_volume=32; citation_publication_date=2019; citation_pages=1716-1753; citation_doi=10.1093/rfs/hhy122; citation_id=CR8"",""citation_title=A history of bitcoin; citation_publication_date=2017; citation_id=CR9; citation_author=U Chohan"",""citation_journal_title=The Review of Financial Studies; citation_title=Blockchain disruption and smart contracts; citation_author=LW Cong, Z He; citation_volume=32; citation_publication_date=2019; citation_pages=1754-1797; citation_doi=10.1093/rfs/hhz007; citation_id=CR10"",""citation_title=Tokenomics: Dynamic adoption and valuation; citation_publication_date=2019; citation_id=CR11; citation_author=LW Cong; citation_author=Y Li; citation_author=N Wang"",""citation_title=Initial Coin Offering (ICO) – Unternehmensfinanzierung auf Basis der Blockchain-Technologie; citation_publication_date=2018; citation_id=CR12; citation_author=C Hahn; citation_author=A Wons; citation_publisher=Gabler"",""citation_journal_title=Review of Economic Studies; citation_title=Foundations of incomplete contracts; citation_author=O Hart, J Moore; citation_volume=66; citation_publication_date=1999; citation_pages=115-138; citation_doi=10.1111/1467-937X.00080; citation_id=CR13"",""citation_journal_title=Theory Culture & Society; citation_title=The socio-technological lives of bitcoin; citation_author=A Hayes; citation_volume=36; citation_publication_date=2019; citation_pages=49-72; citation_doi=10.1177/0263276419826218; citation_id=CR14"",""citation_title=Blockchain-based corporate governance; citation_publication_date=2019; citation_id=CR15; citation_author=W Kaal"",""citation_journal_title=UC Davis Business Law Journal; citation_title=Blockchain-based securities offerings; citation_author=W Kaal, S Evans; citation_volume=20; citation_publication_date=2019; citation_pages=89-109; citation_id=CR16"",""citation_journal_title=Journal of Economic Theory; citation_title=Money is memory; citation_author=NR Kocherlakota; citation_volume=81; citation_publication_date=1998; citation_pages=232-251; citation_doi=10.1006/jeth.1997.2357; citation_id=CR17"",""citation_title=From hype to reality: A taxonomy of blockchain application; citation_publication_date=2019; citation_id=CR18; citation_author=O Labazova; citation_author=T Dehling; citation_author=A Sunyaev"",""citation_title=Blockchain technology for corporate governance and shareholder activism; citation_publication_date=2018; citation_id=CR19; citation_author=A Lafarre; citation_author=C Elst"",""citation_title=The wisdom of crowds in fintech: Evidence from initial coin offerings; citation_publication_date=2019; citation_id=CR20; citation_author=J Lee; citation_author=T Li; citation_author=D Shin"",""citation_title=Initial coin offerings and platform building; citation_publication_date=2018; citation_id=CR21; citation_author=J Li; citation_author=W Mann"",""citation_journal_title=Management Science; citation_title=On the timing of CEO stock option awards; citation_author=E Lie; citation_volume=51; citation_issue=5; citation_publication_date=2005; citation_pages=802-812; citation_doi=10.1287/mnsc.1050.0365; citation_id=CR22"",""citation_title=Market design with Blockchain technology; citation_publication_date=2017; citation_id=CR23; citation_author=K Malinova; citation_author=A Park"",""citation_title=Grundsätze der Volkswirthschaftslehre; citation_publication_date=1871; citation_id=CR24; citation_author=C Menger; citation_publisher=Braumüller"",""Nakamoto, S. 2008. Bitcoin: A peer-to-peer electronic cash system.  https://bitcoin.org/bitcoin.pdf  . Zugegriffen: 18.6.2020."",""citation_title=Bitcoin and cryptocurrency technologies: A comprehensive introduction; citation_publication_date=2016; citation_id=CR26; citation_author=A Narayanan; citation_author=J Bonneau; citation_author=E Felten; citation_author=A Miller; citation_author=S Goldfeder; citation_publisher=Princeton Univers. Press"",""citation_title=Finding the greedy, prodigal, and suicidal contracts at scale; citation_publication_date=2018; citation_id=CR27; citation_author=I Nikolić; citation_author=A Kolluri; citation_author=I Sergey; citation_author=P Saxena; citation_author=A Hobor"",""citation_title=Financial markets, insurance and private pensions: Digitalisation and finance; citation_publication_date=2018; citation_id=CR28"",""Pinna, A., und W. Ruttenberg. 2016. Distributed ledger technologies in securities post-trading. ECB occasional paper 172.  https://ssrn.com/abstract=2770340  . Zugegriffen:  16.6.2020."",""citation_journal_title=Journal of Applied Corporate Finance; citation_title=Will blockchain be a big deal? Reasons for caution; citation_author=C Pirrong; citation_volume=31; citation_issue=4; citation_publication_date=2019; citation_pages=98-104; citation_doi=10.1111/jacf.12379; citation_id=CR30"",""citation_title=What is Libra? Understanding Facebook’s currency; citation_publication_date=2019; citation_id=CR31; citation_author=M Schmeling"",""Securities and Exchange Commission. 2017. Report of investigation pursuant to section 21(a) of the securities exchange act of 1934: the DAO. wwwBitcoinOrg.  https://www.sec.gov/litigation/investreport/34-81207.pdf  . Zugegriffen:  18.6.2020."",""citation_journal_title=Review of Economic Studies; citation_title=Complexity and renegotiation: A foundation for incomplete contracts; citation_author=I Segal; citation_volume=66; citation_publication_date=1999; citation_pages=57-82; citation_doi=10.1111/1467-937X.00078; citation_id=CR33"",""citation_title=Blockchain, securities markets and central banking; citation_publication_date=2017; citation_id=CR34; citation_author=A Seretakis"",""citation_title=A model of cryptocurrencies; citation_publication_date=2018; citation_id=CR35; citation_author=M Sockin; citation_author=W Xiong"",""citation_title=Initial coin offerings – eine strategische perspektive. Juni 2018 Edition; citation_publication_date=2018; citation_id=CR36"",""citation_journal_title=Harvard Business Review; citation_title=How blockchain is changing finance; citation_author=A Tapscott, D Tapscott; citation_volume=1; citation_issue=9; citation_publication_date=2017; citation_pages=2-5; citation_id=CR37"",""citation_title=Token economy: How blockchains and smart contracts revolutionize the economy; citation_publication_date=2019; citation_id=CR38; citation_author=S Voshmgir; citation_publisher=BlockchainHub"",""citation_journal_title=Review of Finance; citation_title=Corporate governance and blockchains; citation_author=D Yermack; citation_volume=21; citation_issue=1; citation_publication_date=2017; citation_pages=7-31; citation_id=CR39""
""citation_journal_title"",""Schmalenbachs Zeitschrift fĂźr betriebswirtschaftliche Forschung""
""language"",""de""
""citation_cover_date"",""2020/06/01""
""og:description"",""The blockchain technology was first implemented in 2009 as the basis of the cryptocurrency Bitcoin. The technology is said to be a disruptive technology that has the potential to significantly affect many areas of the economy. In this paper we provide a survey of the blockchain technology and its applications in finance. We focus on cryptocurrencies, smart contracts, initial coin offerings, the clearing and settlement of transactions in financial markets, and implications for the governance of exchange-listed firms.""
""prism.issn"",""2366-6153""
""citation_author_email"",""philipp.schuster@kit.edu"",""theissen@uni-mannheim.de"",""uhrig@kit.edu""
""twitter:image:alt"",""Content cover image""
""prism.number"",""2""
""citation_issn"",""2366-6153""
""citation_language"",""de""
""dc:title"",""Finanzwirtschaftliche Anwendungen der Blockchain-Technologie | SpringerLink""
""Content-Encoding"",""UTF-8""
""citation_pdf_url"",""https://link.springer.com/content/pdf/10.1007/s41471-020-00090-5.pdf""
""citation_lastpage"",""147""
""DOI"",""10.1007/s41471-020-00090-5""
""citation_fulltext_world_readable"",""""
""citation_journal_abbrev"",""Schmalenbachs Z betriebswirtsch Forsch""
""prism.rightsAgent"",""journalpermissions@springernature.com""
""citation_author"",""Philipp Schuster"",""Erik Theissen"",""Marliese Uhrig-Homburg""
""resourceName"",""s41471-020-00090-5""
""dc.date"",""2020-06-19""
""citation_springer_api_url"",""http://api.springer.com/metadata/pam?q=doi:10.1007/s41471-020-00090-5&api_key=""
""citation_issue"",""2""
""prism.volume"",""72""
""prism.publicationName"",""Schmalenbachs Zeitschrift fĂźr betriebswirtschaftliche Forschung""
""citation_doi"",""10.1007/s41471-020-00090-5""
""dc.title"",""Finanzwirtschaftliche Anwendungen der Blockchain-Technologie""
""prism.url"",""https://link.springer.com/article/10.1007/s41471-020-00090-5""
""citation_volume"",""72""
""dc.language"",""De""
""Content-Language"",""en""
""format-detection"",""telephone=no""
""citation_publication_date"",""2020/06""
""prism.endingPage"",""147""
""citation_title"",""Finanzwirtschaftliche Anwendungen der Blockchain-Technologie""
""citation_author_institution"",""Lehrstuhl fßr Financial Engineering und Derivate, Karlsruher Institut fßr Technologie, Karlsruhe, Deutschland"",""Finance Area, Universität Mannheim, Mannheim, Deutschland"",""Centre for Financial Research, KÜln, Deutschland"",""Lehrstuhl fßr Financial Engineering und Derivate, Karlsruher Institut fßr Technologie, Karlsruhe, Deutschland""
""access"",""Yes""
""citation_publisher"",""Springer Fachmedien Wiesbaden""
""applicable-device"",""pc,mobile""
""dc.format"",""text/html""
""description"",""Die Blockchain-Technologie wurde 2009 als technologische Basis der Kryptowährung Bitcoin erstmals implementiert. Ihr wird das Potential nachgesagt, ei""
""title"",""Finanzwirtschaftliche Anwendungen der Blockchain-Technologie | SpringerLink""
""citation_online_date"",""2020/06/19""
""twitter:site"",""@SpringerLink""
""dc.source"",""Schmalenbachs Zeitschrift fĂźr betriebswirtschaftliche Forschung 2020 72:2""
""dc.type"",""OriginalPaper""
""dc.copyright"",""2020 The Author(s)""
""dc.creator"",""Philipp Schuster"",""Erik Theissen"",""Marliese Uhrig-Homburg""
""citation_fulltext_html_url"",""https://link.springer.com/article/10.1007/s41471-020-00090-5""
""prism.publicationDate"",""2020-06-19""
""Content-Type"",""text/html; charset=UTF-8""
""journal_id"",""41471""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""dc.description"",""Die Blockchain-Technologie wurde 2009 als technologische Basis der Kryptowährung Bitcoin erstmals implementiert. Ihr wird das Potential nachgesagt, eine disruptive Technologie zu sein, die zu nachhaltigen Veränderungen in vielen Bereichen des Wirtschaftslebens führen kann. In diesem Beitrag geben wir einen Überblick über die Technologie selbst sowie ihre finanzwirtschaftlichen Anwendungen. Dabei gehen wir insbesondere auf Kryptowährungen, auf das Potential sogenannter Smart Contracts, auf Initial Coin Offerings, die Abwicklung von Wertpapiergeschäften und mögliche Auswirkungen auf die Corporate Governance börsennotierter Unternehmen ein.""
""og:type"",""article""
""citation_article_type"",""Originalartikel""
""og:title"",""Finanzwirtschaftliche Anwendungen der Blockchain-Technologie""
""prism.doi"",""doi:10.1007/s41471-020-00090-5""
""X-UA-Compatible"",""IE=edge""
""citation_firstpage"",""125""
""prism.startingPage"",""125""
""viewport"",""width=device-width, initial-scale=1""
""dc.rightsAgent"",""journalpermissions@springernature.com""
""prism.section"",""OriginalPaper""
""dc.identifier"",""doi:10.1007/s41471-020-00090-5""
""dc.subject"",""Business and Management, general"",""Marketing"",""Production"",""Accounting/Auditing"",""Management"",""Finance, general""
""og:url"",""https://link.springer.com/article/10.1007/s41471-020-00090-5""
""prism.copyright"",""2020 The Author(s)""
";https://scholar.google.com/scholar?start=420&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095341-1450;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Construction Payment Automation Using Blockchain-Enabled Smart Contracts and Reality Capture Technologies;H Hamledari, M Fischer ; arXiv preprint arXiv:2010.15232, 2020  arxiv.org;;"… 1. It addresses a major challenge associated with blockchain applications: the gap between the

on- and off-chain realities (solutions bridging this gap are known as 'oracles'). This disconnect

makes it impossible to condition the blockchain state transitions on real-world events …";Cité 1 fois;Les 3 versions;[PDF] arxiv.org;https://arxiv.org/pdf/2010.15232;;"""date"",""2021-03-02T17:17:11Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.5""
""xmp:CreatorTool"",""PDFsam Basic v4.1.4""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""language"",""en""
""Last-Modified"",""2021-03-02T17:17:11Z""
""dcterms:modified"",""2021-03-02T17:17:11Z""
""dc:format"",""application/pdf; version=1.5""
""Last-Save-Date"",""2021-03-02T17:17:11Z""
""pdf:docinfo:creator_tool"",""PDFsam Basic v4.1.4""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2021-03-02T17:17:11Z""
""meta:save-date"",""2021-03-02T17:17:11Z""
""pdf:encrypted"",""false""
""modified"",""2021-03-02T17:17:11Z""
""Content-Length"",""1450233""
""pdf:hasMarkedContent"",""false""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""30""
""resourceName"",""2010.15232""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""226"",""1566"",""2948"",""2963"",""3002"",""3097"",""3043"",""1803"",""2952"",""3139"",""831"",""2948"",""1567"",""3114"",""1368"",""2069"",""1679"",""2472"",""2160"",""1361"",""2452"",""3032"",""2999"",""1217"",""3477"",""3827"",""3869"",""3768"",""3576"",""2943""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""producer"",""SAMBox 2.1.16""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""SAMBox 2.1.16""
";https://scholar.google.com/scholar?start=250&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095285-1212;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Improved price oracles: Constant function market makers;G Angeris, T Chitra ; Proceedings of the 2nd ACM Conference on …, 2020  dl.acm.org;;"… to manipulate the query response to say that the temperature is less than 25?C. In the

cryptocurrency community, the problem of providing external data to a blockchain is known as

the oracle problem, as an homage to oracles queried in theoretical computer science [24] …";Cité 17 fois;Les 9 versions;[PDF] acm.org;https://dl.acm.org/doi/pdf/10.1145/3419614.3423251?casa_token=Z6KITZELz3UAAAAA:Rst7lcZK0SxGi4zQJFyqLs-y9igXowvdxfHfdqlk-ZIN5HPPjktW_AhSR59OE5Y0l2CJ-aIlx0c;;;https://scholar.google.com/scholar?start=10&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095285-1206;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Decentralising Finance using Decentralised Blockchain Oracles;M Kumar, N Nikhil, R Singh ; 2020 International Conference for …, 2020  ieeexplore.ieee.org;;"The recent spread of COVID-19, stressed economies and government pumping money into 
the market has once again ignited the discussion on the need to have decentralised 
economies, the role of regulatory authorities and if bitcoin represents a true store of value. In …";Cité 2 fois;;null;;;;https://scholar.google.com/scholar?start=10&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095283-1198;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;External Data Monitoring Using Oracles in Blockchain-Based Process Execution;J Ladleif, I Weber, M Weske ; International Conference on Business …, 2020  Springer;;"In blockchain-based process execution, operational aspects of business processes are 
encoded in smart contracts on blockchains, enabling powerful auditing and compliance 
capabilities due to the platforms' trust and integrity guarantees. However, smart contracts are …";Cité 2 fois;Les 2 versions;[PDF] researchgate.net;https://www.researchgate.net/profile/Jan_Ladleif/publication/343007157_External_Data_Monitoring_Using_Oracles_in_Blockchain-Based_Process_Execution/links/5f115aea299bf1e548bd4ac8/External-Data-Monitoring-Using-Oracles-in-Blockchain-Based-Process-Execution.pdf;;;
1619095323-1367;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;An efficient blockchain-based privacy preserving scheme for vehicular social networks;Y Pu, T Xiang, C Hu, A Alrawais, H Yan ; Information Sciences, 2020  Elsevier;;"… Volume 540, November 2020, Pages 308-324. Information Sciences. An efficient

blockchain-based privacy preserving scheme for vehicular social networks … Besides, blockchain

technology and consensus mechanism are employed to protect vehicles' credit information. • …";Cité 15 fois;Les 2 versions;null;;;;https://scholar.google.com/scholar?start=170&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095386-1642;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;SoK: Layer-Two Blockchain Protocols;P McCorry, A Gervais ; … Kota Kinabalu, Malaysia, February 10–14 …, 2020  books.google.com;;"… work. Keywords: Layer-two blockchain Applied cryptography protocolsˇ Blockchainˇ

Blockchain scaling applicationsˇ Cryptocurrencyˇ adoption The full version of this

paper available at https://eprint. iacr. org/2019/360. pdf. cO …";Autres articles;;null;;;;https://scholar.google.com/scholar?start=440&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095402-1712;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;[PDF][PDF] Models and Simulation of Blockchain Systems;M Alharby ;2020 research.spec.org;;"Page 1. Models and Simulation of Blockchain Systems Maher Alharby … in Section 2.9. 2.1

Blockchain Technology Transactions between parties in current systems are usually conducted

in a centralised form, which requires the involvement of a trusted third party (eg, a bank) …";;;[PDF] spec.org;https://research.spec.org/fileadmin/user_upload/dissertationaward/Maher_Alharby_Dissertation.pdf;;"""date"",""2020-11-24T22:01:28Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2020-11-24T22:01:28Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.20 (TeX Live 2019) kpathsea version 6.3.1""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2020-11-24T22:01:28Z""
""created"",""2020-11-24T22:01:28Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-11-24T22:01:28Z""
""resourceName"",""Maher_Alharby_Dissertation.pdf""
""Author"",""""
""producer"",""pdfTeX-1.40.20""
""pdf:docinfo:producer"",""pdfTeX-1.40.20""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""1"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""77"",""0"",""1"",""267"",""0"",""0"",""21"",""0"",""0"",""0"",""200"",""213"",""219"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""2"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2020-11-24T22:01:28Z""
""Last-Modified"",""2020-11-24T22:01:28Z""
""dcterms:modified"",""2020-11-24T22:01:28Z""
""title"",""""
""Last-Save-Date"",""2020-11-24T22:01:28Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2020-11-24T22:01:28Z""
""meta:save-date"",""2020-11-24T22:01:28Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.20 (TeX Live 2019) kpathsea version 6.3.1""
""Content-Length"",""3039783""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""173""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""146"",""0"",""507"",""1074"",""3"",""1757"",""1"",""1210"",""1601"",""1823"",""1326"",""1474"",""1553"",""1471"",""580"",""0"",""1546"",""2314"",""2326"",""2006"",""1880"",""1626"",""1804"",""614"",""1409"",""2266"",""2070"",""2130"",""2359"",""2251"",""1727"",""1842"",""2144"",""2272"",""1568"",""1508"",""2250"",""1423"",""1789"",""1706"",""2284"",""2055"",""1483"",""2015"",""2189"",""1859"",""250"",""2162"",""2141"",""2329"",""2317"",""2316"",""1655"",""1167"",""2077"",""1561"",""1634"",""1715"",""1243"",""1257"",""2255"",""2233"",""2045"",""1967"",""2215"",""1113"",""1170"",""2302"",""1769"",""1067"",""2252"",""1388"",""2038"",""2148"",""2012"",""2089"",""1282"",""1853"",""1911"",""2223"",""2042"",""2187"",""2086"",""1761"",""1955"",""984"",""1148"",""1314"",""2245"",""2206"",""2209"",""1697"",""2204"",""1357"",""1364"",""2365"",""2176"",""1531"",""2368"",""1329"",""1390"",""1568"",""1805"",""1179"",""2166"",""1104"",""1887"",""1993"",""2051"",""1989"",""1373"",""1313"",""1320"",""350"",""1237"",""2399"",""2076"",""2341"",""1999"",""1955"",""1876"",""2029"",""1907"",""2237"",""1260"",""1583"",""1058"",""1457"",""2159"",""2137"",""2164"",""1261"",""1277"",""2376"",""2014"",""2295"",""1837"",""1328"",""1715"",""1479"",""1794"",""2022"",""1379"",""2662"",""1677"",""2282"",""1578"",""1760"",""1403"",""1961"",""1971"",""1974"",""1413"",""1819"",""2130"",""2081"",""2191"",""2041"",""2022"",""2179"",""542"",""1410"",""1768"",""1591"",""1650"",""1737"",""1674"",""1702"",""1748"",""1764"",""1664"",""1761"",""161""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-11-24T22:01:28Z""
";https://scholar.google.com/scholar?start=510&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095323-1366;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Oracle's Application in Finance;L Bai ; International conference on Big Data Analytics for …, 2020  Springer;;"… Secondly, it briefly introduces the application of virtual machine or Oracle in the financial field

of blockchain world … Kochovski, P., Gec, S.,Stankovski, V., Bajec, M., Drobintsev, PD: Trust

management in a blockchain based fog computing platform with trustless smart oracles …";Autres articles;;null;;;;https://scholar.google.com/scholar?start=170&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095355-1507;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Design of Enterprise Information System Architecture with Oracle Architecture Development Process (OADP) Case Study in Vocational High Schools;MPAQ Saleh, S Dewi ; International Journal of …, 2020  journal.rescollacomm.com;;"… Perencanaan Arsitektur Enterprise Perguruan Tinggi Menggunakan Oracle Framework …

OriginalMy: Blockchain technology and business defying a 20th- century regulation … Automatic

Generation of Test Oracles from Component Based Software Architectures …";Autres articles;Version HTML;[PDF] rescollacomm.com;https://journal.rescollacomm.com/index.php/ijqrm/article/download/80/81;;"""date"",""2020-12-25T00:50:33Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""Article""
""xmp:CreatorTool"",""MicrosoftÂŽ Word 2010""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dc:creator"",""yaog""
""language"",""en""
""dcterms:created"",""2020-12-25T00:50:33Z""
""Last-Modified"",""2020-12-25T00:50:33Z""
""dcterms:modified"",""2020-12-25T00:50:33Z""
""dc:format"",""application/pdf; version=1.5""
""title"",""Article""
""Last-Save-Date"",""2020-12-25T00:50:33Z""
""pdf:docinfo:creator_tool"",""MicrosoftÂŽ Word 2010""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2020-12-25T00:50:33Z""
""meta:save-date"",""2020-12-25T00:50:33Z""
""pdf:encrypted"",""false""
""dc:title"",""Article""
""modified"",""2020-12-25T00:50:33Z""
""Content-Length"",""635212""
""pdf:hasMarkedContent"",""true""
""Content-Type"",""application/pdf""
""pdf:docinfo:creator"",""yaog""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""yaog""
""dc:language"",""id-ID""
""meta:author"",""yaog""
""meta:creation-date"",""2020-12-25T00:50:33Z""
""created"",""2020-12-25T00:50:33Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""12""
""Creation-Date"",""2020-12-25T00:50:33Z""
""resourceName"",""81""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""2740"",""3327"",""1506"",""1905"",""1628"",""1996"",""1869"",""595"",""1760"",""2984"",""2913"",""252""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""Author"",""yaog""
""producer"",""MicrosoftÂŽ Word 2010""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""MicrosoftÂŽ Word 2010""
""pdf:docinfo:created"",""2020-12-25T00:50:33Z""
";https://scholar.google.com/scholar?start=310&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095353-1500;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;[PDF][PDF] Decentralized Application for E-Commerce Using Blockchain and Trusted Compute;JCO Lago ;2020 repositorioaberto.up.pt;;"… KEYWORDS: E-commerce. Blockchain. Bitcoin. Distributed systems. Smart

contracts. Cryp- tocurrencies. Decentralization ii Page 5. Acknowledgments …

5 2.3 TrustedComputeFramework . . . . . 9 2.4 Oracles …";Autres articles;Version HTML;[PDF] up.pt;https://repositorio-aberto.up.pt/bitstream/10216/128577/2/412428.pdf;;"""date"",""2020-07-28T14:23:09Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2020-07-28T14:23:09Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.20 (TeX Live 2019) kpathsea version 6.3.1""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2020-07-28T14:23:09Z""
""created"",""2020-07-28T14:23:09Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-07-28T14:23:09Z""
""resourceName"",""412428.pdf""
""Author"",""""
""producer"",""pdfTeX-1.40.20""
""pdf:docinfo:producer"",""pdfTeX-1.40.20""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2020-07-28T14:23:09Z""
""Last-Modified"",""2020-07-28T14:23:09Z""
""dcterms:modified"",""2020-07-28T14:23:09Z""
""title"",""""
""Last-Save-Date"",""2020-07-28T14:23:09Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2020-07-28T14:23:09Z""
""meta:save-date"",""2020-07-28T14:23:09Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.20 (TeX Live 2019) kpathsea version 6.3.1""
""Content-Length"",""1904255""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""97""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""208"",""145"",""2218"",""1873"",""300"",""99"",""1711"",""1148"",""2016"",""309"",""1415"",""423"",""598"",""1361"",""922"",""1787"",""2958"",""2742"",""2951"",""3121"",""1924"",""2657"",""2824"",""2817"",""2709"",""2406"",""2536"",""2854"",""1959"",""2218"",""2363"",""2356"",""1968"",""2046"",""2301"",""282"",""1632"",""309"",""2693"",""2210"",""696"",""1628"",""1529"",""2051"",""1536"",""1392"",""1622"",""2426"",""854"",""1762"",""1742"",""1936"",""1705"",""1306"",""1421"",""1265"",""1894"",""905"",""1082"",""1829"",""1653"",""1291"",""2251"",""1853"",""2269"",""2943"",""2470"",""1955"",""1781"",""1793"",""1963"",""2478"",""1413"",""2439"",""1620"",""1308"",""1246"",""1994"",""2444"",""993"",""842"",""1532"",""2343"",""2220"",""998"",""1398"",""1375"",""2891"",""2189"",""1578"",""1565"",""1821"",""1605"",""562"",""1729"",""1985"",""2085""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-07-28T14:23:09Z""
";https://scholar.google.com/scholar?start=300&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095330-1401;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Can a Public Blockchain Keep a Secret?;F Benhamouda, C Gentry, S Gorbunov, S Halevi… ; Theory of Cryptography …, 2020  Springer;;"… channels, such channels may make the problem of keeping a secret on the blockchain much

easier … For \(\mathcal {E}_1\) we may use random-oracle-based hybrid constructions, but for

\(\mathcal … E}_2\) we need efficient NIZK proofs and hence prefer not to use random oracles …";Cité 5 fois;Les 2 versions;[PDF] iacr.org;https://eprint.iacr.org/2020/464.pdf;;"""date"",""2020-09-28T21:53:20Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2020-09-28T21:53:20Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is MiKTeX-pdfTeX 4.0.1 (1.40.21)""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2020-09-28T21:53:20Z""
""created"",""2020-09-28T21:53:20Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-09-28T21:53:20Z""
""resourceName"",""464.pdf""
""Author"",""""
""producer"",""MiKTeX pdfTeX-1.40.21""
""pdf:docinfo:producer"",""MiKTeX pdfTeX-1.40.21""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""3"",""3"",""0"",""0"",""0"",""2"",""0"",""0"",""4"",""8"",""20"",""2"",""0"",""2"",""16"",""10"",""25"",""35"",""5"",""0"",""3"",""0"",""0"",""11"",""35"",""46"",""18"",""1"",""26"",""0"",""0"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2020-09-28T21:53:20Z""
""Last-Modified"",""2020-09-28T21:53:20Z""
""dcterms:modified"",""2020-09-28T21:53:20Z""
""title"",""""
""Last-Save-Date"",""2020-09-28T21:53:20Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2020-09-28T21:53:20Z""
""meta:save-date"",""2020-09-28T21:53:20Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is MiKTeX-pdfTeX 4.0.1 (1.40.21)""
""Content-Length"",""683244""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""35""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""2014"",""3212"",""2887"",""2412"",""2979"",""3241"",""2796"",""2541"",""2663"",""3104"",""2356"",""2292"",""1666"",""2761"",""2276"",""2157"",""2181"",""2519"",""2138"",""1957"",""2118"",""2712"",""3215"",""3173"",""2858"",""2653"",""1048"",""2113"",""2039"",""2931"",""2670"",""2304"",""2063"",""2202"",""1797""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-09-28T21:53:20Z""
";https://scholar.google.com/scholar?start=200&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095325-1382;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;A Practical NIZK Argument for Confidential Transactions over Account-Model Blockchain;S Ma, Y Deng, M Bai, D He, J Zhang, X Xie ; International Conference on …, 2020  Springer;;"… protocol can be transformed into a NIZK under the RO model, via obtaining the challenge e from

a random oracle which takes a as input. 2.3 Smart Contracts for Payment over Blockchains.

Assume in a payment system deployed in a account-model blockchain, user A wants to …";Autres articles;;null;;;;https://scholar.google.com/scholar?start=180&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095318-1350;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;A Framework for Decentralized Private Random State Generation and Maintenance for Multiplayer Gaming Over Blockchain;R Harkanson, C Chiu, Y Kim… ; 2020 IEEE 44th Annual …, 2020  ieeexplore.ieee.org;;"… The first cryptocurrency to accommodate Turing-complete smart contracts was Ethereum [8]. As

such, Ethereum became a … Oracles are web services which enable an on-chain smart contract

access to external information … 21] introduce a decentralized blockchain oracle they term …";Autres articles;;null;;;;https://scholar.google.com/scholar?start=150&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095381-1614;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;[PDF][PDF] Transformation of the Transaction Cost and the Agency Cost in an Organization and the Applicability of Blockchain—A Case Study of Peer-to-Peer Insurance;RT Sun, A Garimella, W Han… ; Front. Blockchain 3 …, 2020  pdfs.semanticscholar.org;;"… Here, the appraiser functions as an “oracle.” Since the data on the common ledger triggers the

execution of smart contracts, the collection of the data relies on “oracles” to transfer the information

from the real-world to the blockchain data registry2. The agent's role shifts away …";Cité 1 fois;;[PDF] semanticscholar.org;https://pdfs.semanticscholar.org/faa8/121c3fa40528fca12f1c7a81b3d700d490ee.pdf;;"""citation_publication_date"",""2020""
""og:image"",""https://www.semanticscholar.org/img/semantic_scholar_og.png""
""citation_title"",""Transformation of the Transaction Cost and the Agency Cost in an Organization and the Applicability of Blockchain—A Case Study of Peer-to-Peer Insurance""
""og:image:width"",""1110""
""twitter:card"",""summary_large_image""
""msapplication-square70x70logo"",""https://cdn.semanticscholar.org/86e6c2539915adc9/img/mstile-70x70.png""
""citation_journal_title"",""undefined""
""description"",""Blockchain supports a variety of decentralized applications enabled by its immutable, decentralized, and trustless properties. However, there are no unifying criteria for blockchain architecture across the organizations and business models. This variance has created complex and diverse blockchain products. Costs in every economic exchange with partners are associated with two metrics: transaction costs due to market imperfections and agency costs due to conflict of interest and information asymmetry in an organization. To understand the effectiveness of economic activities by blockchain intervention and facilitate strategic alignment, we use transaction cost and agency cost as theoretical lenses to explore the impacts of blockchain, discuss the transformation of those costs, and support our arguments using a case study. Our study proposes that blockchain technology brings two more benefits, trust and transparency, to the existing Internet-based business services, and helps improve corporate governance. Smart contracts improve the execution time of transactions significantly and increase transaction volume rapidly. As the internet shifts hierarchies toward electronic markets, lack of trust between peers inhibits exchanges. Blockchain applications provide a framework for building trust between peers through its consent mechanism, which allows organizations to construct trust and operate in a more decentralized manner. Thus, by including blockchain in the current Internet infrastructure, the decision boundary of organization forms would extend outward. Finally, the transformation of costs in different stages of the blockchain transition, as described in our study, has important managerial implications for the organization structure and the role of third parties. Blockchain does not assume away transaction and agency costs but pushes the transformation of the two, forming a more efficient economic entity. This study contributes to the academia and the industry. We first add to the understanding of blockchain from the perspective of exchange technology. Second, we contribute to the prediction of organization boundaries. Third, the shift in the role of third parties supports the transaction cost theory in terms of controlling opportunism. Lastly, this study facilitates the development of blockchain business models and contributes to the practice.""
""msapplication-wide310x150logo"",""https://cdn.semanticscholar.org/86e6c2539915adc9/img/mstile-310x150.png""
""language"",""en""
""title"",""Transformation of the Transaction Cost and the Agency Cost in an Organization and the Applicability of Blockchain—A Case Study of Peer-to-Peer Insurance | Semantic Scholar""
""og:description"",""Blockchain supports a variety of decentralized applications enabled by its immutable, decentralized, and trustless properties. However, there are no unifying criteria for blockchain architecture across the organizations and business models. This variance has created complex and diverse blockchain products. Costs in every economic exchange with partners are associated with two metrics: transaction costs due to market imperfections and agency costs due to conflict of interest and information asymmetry in an organization. To understand the effectiveness of economic activities by blockchain intervention and facilitate strategic alignment, we use transaction cost and agency cost as theoretical lenses to explore the impacts of blockchain, discuss the transformation of those costs, and support our arguments using a case study. Our study proposes that blockchain technology brings two more benefits, trust and transparency, to the existing Internet-based business services, and helps improve corporate governance. Smart contracts improve the execution time of transactions significantly and increase transaction volume rapidly. As the internet shifts hierarchies toward electronic markets, lack of trust between peers inhibits exchanges. Blockchain applications provide a framework for building trust between peers through its consent mechanism, which allows organizations to construct trust and operate in a more decentralized manner. Thus, by including blockchain in the current Internet infrastructure, the decision boundary of organization forms would extend outward. Finally, the transformation of costs in different stages of the blockchain transition, as described in our study, has important managerial implications for the organization structure and the role of third parties. Blockchain does not assume away transaction and agency costs but pushes the transformation of the two, forming a more efficient economic entity. This study contributes to the academia and the industry. We first add to the understanding of blockchain from the perspective of exchange technology. Second, we contribute to the prediction of organization boundaries. Third, the shift in the role of third parties supports the transaction cost theory in terms of controlling opportunism. Lastly, this study facilitates the development of blockchain business models and contributes to the practice.""
""og:image:secure_url"",""https://www.semanticscholar.org/img/semantic_scholar_og.png"",""https://www.semanticscholar.org/img/semantic_scholar_og.png""
""twitter:image"",""https://www.semanticscholar.org/img/semantic_scholar_og.png"",""https://www.semanticscholar.org/img/semantic_scholar_og.png""
""twitter:site"",""@allenai_org""
""msapplication-square310x310logo"",""https://cdn.semanticscholar.org/86e6c2539915adc9/img/mstile-310x310.png""
""dc:title"",""Transformation of the Transaction Cost and the Agency Cost in an Organization and the Applicability of Blockchain—A Case Study of Peer-to-Peer Insurance | Semantic Scholar""
""Content-Encoding"",""UTF-8""
""citation_pdf_url"",""https://doi.org/10.3389/fbloc.2020.00024""
""robots"",""noarchive,noindex""
""Content-Type"",""text/html; charset=UTF-8""
""s2-ui-version"",""2cfb8f55a25a62a824f97b333bd41eb95e1e3822""
""application-name"","" ""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""twitter:title"",""Transformation of the Transaction Cost and the Agency Cost in an Organization and the Applicability of Blockchain—A Case Study of Peer-to-Peer Insurance | Semantic Scholar""
""og:type"",""website""
""og:title"",""Transformation of the Transaction Cost and the Agency Cost in an Organization and the Applicability of Blockchain—A Case Study of Peer-to-Peer Insurance | Semantic Scholar""
""citation_author"",""R. Sun"",""Aravinda Garimella"",""Wencui Han"",""Hsin-Lu Chang"",""M. Shaw""
""og:image:height"",""582""
""resourceName"",""121c3fa40528fca12f1c7a81b3d700d490ee.pdf""
""msapplication-square150x150logo"",""https://cdn.semanticscholar.org/86e6c2539915adc9/img/mstile-150x150.png""
""msapplication-TileColor"",""#FFFFFF""
""viewport"",""width=device-width,initial-scale=1""
""twitter:description"",""Blockchain supports a variety of decentralized applications enabled by its immutable, decentralized, and trustless properties. However, there are no unifying criteria for blockchain architecture across the organizations and business models. This variance has created complex and diverse blockchain products. Costs in every economic exchange with partners are associated with two metrics: transaction costs due to market imperfections and agency costs due to conflict of interest and information asymmetry in an organization. To understand the effectiveness of economic activities by blockchain intervention and facilitate strategic alignment, we use transaction cost and agency cost as theoretical lenses to explore the impacts of blockchain, discuss the transformation of those costs, and support our arguments using a case study. Our study proposes that blockchain technology brings two more benefits, trust and transparency, to the existing Internet-based business services, and helps improve corporate governance. Smart contracts improve the execution time of transactions significantly and increase transaction volume rapidly. As the internet shifts hierarchies toward electronic markets, lack of trust between peers inhibits exchanges. Blockchain applications provide a framework for building trust between peers through its consent mechanism, which allows organizations to construct trust and operate in a more decentralized manner. Thus, by including blockchain in the current Internet infrastructure, the decision boundary of organization forms would extend outward. Finally, the transformation of costs in different stages of the blockchain transition, as described in our study, has important managerial implications for the organization structure and the role of third parties. Blockchain does not assume away transaction and agency costs but pushes the transformation of the two, forming a more efficient economic entity. This study contributes to the academia and the industry. We first add to the understanding of blockchain from the perspective of exchange technology. Second, we contribute to the prediction of organization boundaries. Third, the shift in the role of third parties supports the transaction cost theory in terms of controlling opportunism. Lastly, this study facilitates the development of blockchain business models and contributes to the practice.""
""og:locale"",""en_US"",""en_US""
""Content-Language"",""en""
""msapplication-TileImage"",""https://cdn.semanticscholar.org/86e6c2539915adc9/img/mstile-144x144.png""
";https://scholar.google.com/scholar?start=420&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095381-1617;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Internet of beer: A review on smart technologies from mash to pint;S Violino, S Figorilli, C Costa, F Pallottino ; Foods, 2020  mdpi.com;;"… levels. Keywords: IoT internet of things; microcontrollers; blockchain; craft beer; AI

artificial intelligence; big data IoT internet of things; microcontrollers; blockchain; craft

beer; AI artificial intelligence; big data. 1. Introduction. Beer …";Cité 2 fois;Les 8 versions;[PDF] mdpi.com;https://www.mdpi.com/2304-8158/9/7/950/pdf;;;https://scholar.google.com/scholar?start=420&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095349-1480;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Blockchain Frameworks;MT Quasim, MA Khan, F Algarni, A Alharthy… ; Decentralised Internet of …, 2020  Springer;;"… The use of oracles (people) to confirm the authenticity of documents and information reduces

the legitimacy of … The DEX has fast transactions, low fees and secure settlements on the blockchain.

If we want to issue our own crypto coin then you need minimum one Wave token …";Cité 5 fois;Les 5 versions;[PDF] researchgate.net;https://www.researchgate.net/profile/Mohammad_Quasim2/publication/336848217_Blockchain_Frameworks/links/5db7e44ea6fdcc2128e8730d/Blockchain-Frameworks.pdf;;;https://scholar.google.com/scholar?start=280&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095383-1625;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;[PDF][PDF] Blockchain for Education Records;J Kaletka, A Herkommer ; divaportal.org;;"… Furthermore, the blockchain cryptocurrency was able to avoid the problem of double spending

(Mougayar, 2016) that describes an issue of digital currencies in which money is maliciously

copied and spend multiple times, while third parties are included to avoid this from …";Autres articles;;[PDF] diva-portal.org;https://www.diva-portal.org/smash/get/diva2:1427411/FULLTEXT02.pdf;;"""date"",""2020-05-17T15:11:40Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.3""
""pdf:docinfo:title"",""Microsoft Word - Herkommer, Kaletka Blockchain.docx""
""xmp:CreatorTool"",""Word""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dcterms:created"",""2020-05-17T15:11:40Z""
""language"",""en""
""Last-Modified"",""2020-05-17T15:11:40Z""
""dcterms:modified"",""2020-05-17T15:11:40Z""
""dc:format"",""application/pdf; version=1.3""
""title"",""Microsoft Word - Herkommer, Kaletka Blockchain.docx""
""Last-Save-Date"",""2020-05-17T15:11:40Z""
""pdf:docinfo:creator_tool"",""Word""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2020-05-17T15:11:40Z""
""meta:save-date"",""2020-05-17T15:11:40Z""
""pdf:encrypted"",""false""
""dc:title"",""Microsoft Word - Herkommer, Kaletka Blockchain.docx""
""modified"",""2020-05-17T15:11:40Z""
""Content-Length"",""2844103""
""pdf:hasMarkedContent"",""false""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""meta:creation-date"",""2020-05-17T15:11:40Z""
""created"",""2020-05-17T15:11:40Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""79""
""Creation-Date"",""2020-05-17T15:11:40Z""
""resourceName"",""FULLTEXT02.pdf""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""322"",""6"",""2509"",""1859"",""1457"",""1122"",""1868"",""3029"",""3146"",""2780"",""3145"",""2991"",""2877"",""2766"",""736"",""1863"",""2785"",""2726"",""2263"",""2376"",""1483"",""2444"",""3020"",""2756"",""2919"",""2813"",""2964"",""2890"",""3028"",""2360"",""1450"",""2621"",""2887"",""2856"",""2363"",""2237"",""2969"",""2960"",""2470"",""2484"",""2690"",""2532"",""2044"",""2662"",""1898"",""2001"",""2117"",""2139"",""2160"",""762"",""2630"",""3166"",""3232"",""3076"",""2749"",""2428"",""2625"",""3041"",""2721"",""1056"",""2158"",""2409"",""2386"",""2404"",""2193"",""2349"",""2252"",""53"",""2009"",""1381"",""42"",""5"",""5"",""5"",""5"",""5"",""5"",""7"",""123""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""producer"",""macOS Version 10.15.4 (Build 19E287) Quartz PDFContext""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""macOS Version 10.15.4 (Build 19E287) Quartz PDFContext""
""pdf:docinfo:created"",""2020-05-17T15:11:40Z""
";https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095358-1522;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Blockchain, Disintermediation and the Future of the Legal Professions;P Heudebert, C Leveneur ; Cardozo Int'l & Comp. L. Rev., 2020  HeinOnline;;"… these ""fiat"" currencies into ""crypto assets,"" it is necessary to use an intermediary who will keep

the ""fiat"" sums in a dedicated account and allow users to gain access to the cryptocurrency

exchange service. 4 8 The same applies for all services based on blockchain protocols that …";Les 2 versions;;null;;;;https://scholar.google.com/scholar?start=320&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095339-1436;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Security Analysis of Auctionity: A Blockchain Based E-Auction;E Roudeix ; Foundations and Practice of Security: 12th International …, 2020  Springer;;"… Table 1. Notations, where u is a user. –Oracle (O) is the Auctionity server that transfers

information between ELNET and ACNET. Unlike blockchain, Oracle is not decentralized. How-

ever it does not compromise the security properties we want for Auctionity …";Autres articles;;null;;;;https://scholar.google.com/scholar?start=240&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095337-1429;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Towards airbnb-like privacy-enhanced private parking spot sharing based on blockchain;L Wang, X Lin, E Zima, C Ma ; IEEE Transactions on Vehicular …, 2020  ieeexplore.ieee.org;;"… Parking Spot Sharing Based on Blockchain Lingling Wang, Member, IEEE, Xiaodong

Lin, Fellow, IEEE, Eugene Zima, Chunguang Ma … Index Terms—Private parking spot

sharing, Privacy, Market design, Blockchain, Anonymous payment …";Cité 7 fois;Les 2 versions;null;;;;https://scholar.google.com/scholar?start=230&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095390-1663;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;[CITATION][C] The Disruptive Effect of Distributed Ledger Technology and Blockchain in the over the counter derivatives market;A Paolini ; Global Jurist, 2020  De Gruyter;;null;Autres articles;;null;;;;https://scholar.google.com/scholar?start=460&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095404-1720;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;A Blockchain Tokenizer for Industrial IOT trustless applications;D Mazzei, G Baldi, G Fantoni, G Montelisciani… ; Future Generation …, 2020  Elsevier;;"… of cloud services and truly trusted setups, favouring the adoption of Blockchain solutions built

by the more significant IT and cloud vendors, for example: AWS [43], Microsoft [44], IBM [45] and

Oracle [46] … The Blockchain layer communicates with the external crypto chip where …";Cité 28 fois;Les 4 versions;[PDF] researchgate.net;https://www.researchgate.net/profile/Daniele_Mazzei/publication/337946412_A_Blockchain_Tokenizer_for_Industrial_IOT_Trustless_Applications/links/5df752f3299bf10bc35f1448/A-Blockchain-Tokenizer-for-Industrial-IOT-Trustless-Applications.pdf;;;https://scholar.google.com/scholar?start=520&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095306-1302;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Towards post-quantum blockchain: A review on blockchain cryptography resistant to quantum computing attacks;TM Fernández;Caramés, P FragaLamas  IEEE Access, 2020  ieeexplore.ieee.org;;"… can be executed autonomously. Smart contracts can be used to automate cer- tain

tasks depending on the state of the blockchain and in other external data sources

called oracles [22]. The previously introduced concepts have …";Cité 37 fois;Les 3 versions;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/6287639/8948470/08967098.pdf;;"""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""dc:title"",""IEEE Xplore Full-Text PDF:""
""Content-Encoding"",""UTF-8""
""resourceName"",""08967098.pdf""
""language"",""es""
""Content-Length"",""2565""
""title"",""IEEE Xplore Full-Text PDF:""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=100&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095292-1240;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Decentralized Runtime Monitoring Approach Relying on the Ethereum Blockchain Infrastructure;A Taha, A Zakaria, D Kim, N Suri ; 2020 IEEE International …, 2020  ieeexplore.ieee.org;;"… Hence, the oracle plays the role of an intermediary between the outside world and

the blockchain. Oracles can utilize the web3 API in order to be able to interact with

the smart contracts deployed on the blockchain [17]. III …";Autres articles;;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/9094050/9096260/09096480.pdf?casa_token=RxqR5y7sawIAAAAA:LqZxPdOjUbD7Y8R96UuaGsprfOaVc0lQ-z_vS6RJuv-KYP-iVJYFbO7rQ7WOMnWBSJYVWYeJzrE;;"""og:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""twitter:title"",""Decentralized Runtime Monitoring Approach Relying on the Ethereum Blockchain Infrastructure""
""twitter:card"",""summary""
""Description"",""Cloud computing offers a model where resources (storage, applications, etc.) are abstracted and provided “as-aservice” in a remotely accessible manner. Although""
""og:title"",""Decentralized Runtime Monitoring Approach Relying on the Ethereum Blockchain Infrastructure""
""resourceName"",""09096480.pdf""
""language"",""en""
""title"",""Decentralized Runtime Monitoring Approach Relying on the Ethereum Blockchain Infrastructure | IEEE Conference Publication | IEEE Xplore""
""og:description"",""Cloud computing offers a model where resources (storage, applications, etc.) are abstracted and provided “as-aservice” in a remotely accessible manner. Although there are numerous claimed benefits of the Cloud to ensure confidentiality, integrity, and availability of the stored data, the number of security breaches is still on the rise. The lack of security assurance and transparency prevented customers/enterprises from trusting the Cloud Service Providers (CSPs). Unless the customer's security requirements are identified and documented by the CSPs, customers can not be assured that the CSPs will satisfy their requirements. Furthermore, the customer's compensation upon a violation is a manual time intensive process.In this paper we address the aforementioned challenges by proposing a decentralized customer-based monitoring approach running over Ethereum blockchain. The proposed approach allows the customer(s) to validate the compliance of CSP(s) to the contracted services in the Service Level Agreements (SLAs) and “autonomsly” compensate customers in case of security breaches. At the same time, the proposed approach prevents customers from misreporting for financial gain. The approach builds upon the Ethereum blockchain infrastructure in order to securely store monitoring logs and incorporate SLAs as smart contracts. The compliance validation framework is implemented and its functionality is evaluated on Amazon EC2 and Ethereum Blockchain.""
""twitter:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-UA-Compatible"",""IE=Edge""
""viewport"",""width=device-width, initial-scale=1.0""
""dc:title"",""Decentralized Runtime Monitoring Approach Relying on the Ethereum Blockchain Infrastructure | IEEE Conference Publication | IEEE Xplore""
""twitter:description"",""Cloud computing offers a model where resources (storage, applications, etc.) are abstracted and provided “as-aservice” in a remotely accessible manner. Although there are numerous claimed benefits of the Cloud to ensure confidentiality, integrity, and availability of the stored data, the number of security breaches is still on the rise. The lack of security assurance and transparency prevented customers/enterprises from trusting the Cloud Service Providers (CSPs). Unless the customer's security requirements are identified and documented by the CSPs, customers can not be assured that the CSPs will satisfy their requirements. Furthermore, the customer's compensation upon a violation is a manual time intensive process.In this paper we address the aforementioned challenges by proposing a decentralized customer-based monitoring approach running over Ethereum blockchain. The proposed approach allows the customer(s) to validate the compliance of CSP(s) to the contracted services in the Service Level Agreements (SLAs) and “autonomsly” compensate customers in case of security breaches. At the same time, the proposed approach prevents customers from misreporting for financial gain. The approach builds upon the Ethereum blockchain infrastructure in order to securely store monitoring logs and incorporate SLAs as smart contracts. The compliance validation framework is implemented and its functionality is evaluated on Amazon EC2 and Ethereum Blockchain.""
""Content-Encoding"",""UTF-8""
""Content-Type-Hint"",""text/html; charset=utf-8""
""Content-Length"",""42391""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=40&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095374-1585;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;[HTML][HTML] A double design-science perspective of entrepreneurship–the example of smart contracts in the insurance market;CH Hoffmann ; Journal of WorkApplied Management, 2020  emerald.com;;"… For such insurances an application of blockchain is not possible since no oracle can assess the

damage automatically … The final expense policy however can be constructed to rely on oracles

which monitor specific sources of information about individual deaths …";Autres articles;;[HTML] emerald.com;https://www.emerald.com/insight/content/doi/10.1108/JWAM-08-2020-0037/full/html;;"""keywords"",""Design-science perspective of entrepreneurship,Education,Blockchain,Smart contracts,Insurtech""
""dc.Title"",""A double design-science perspective of entrepreneurship – the example of smart contracts in the insurance market""
""citation_journal_title"",""Journal of Work-Applied Management""
""description"",""A double design-science perspective of entrepreneurship – the example of smart contracts in the insurance market - Author: Christian Hugo Hoffmann""
""language"",""en""
""title"",""A double design-science perspective of entrepreneurship – the example of smart contracts in the insurance market
 |  Emerald Insight""
""dc.Identifier"",""10.1108/JWAM-08-2020-0037"",""2205-2062"",""JWAM-08-2020-0037.pdf""
""dc.Publisher"",""Emerald Publishing Limited""
""dc.Format"",""text/html""
""dc:title"",""A double design-science perspective of entrepreneurship – the example of smart contracts in the insurance market
 |  Emerald Insight""
""csrf-token"",""IvN49RiQK7l3pbx20na8HJJvSOa2rkyZX8F7ROvP""
""Content-Encoding"",""UTF-8""
""dc.Date"",""2020-12-24T00:00:00Z""
""citation_xml_url"",""https://www.emerald.com/insight/content/doi/10.1108/JWAM-08-2020-0037/full/xml""
""dc.Subject"",""Design-science perspective of entrepreneurship,Education,Blockchain,Smart contracts,Insurtech""
""Content-Type"",""text/html; charset=UTF-8""
""dc.Contributor"",""Christian Hugo Hoffmann""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""dc.Type"",""article""
""resourceName"",""html""
""X-UA-Compatible"",""IE=edge""
""dc.Language"",""en""
""dc.Description"",""Following the call for strengthening the third pillar of knowledge in entrepreneurship as well as work-applied management contexts constituted by pragmatic design principles, we present a case study on an insurtech for insurance firms specialized in smart contract insurance solutions such as flight delay or ski resort insurance.,Design science.,This not only serves as a pointer for how insurances may master their digital transformation while remaining competitive. But moreover, on the meta level, we find that the adoption of entrepreneurial design principles by the students, whose experiential project represents our case study, does not necessarily require continuous support or foundational knowledge to be delivered beforehand. However, for a deeper or more holistic assessment of the case sketched in their project, it makes sense to introduce them to newer developments such as the simple, practical framework of the Entrepreneur's Question Index.,Innovative teaching method on innovative topics.""
""viewport"",""width=device-width, initial-scale=1""
""DCTERMS.bibliographicCitation"",""&ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Ajournal&rft.spage=69&rft.epage=87&rft.volume=13&rft.issue=1""
""dc.Coverage"",""world""
""Content-Language"",""en""
""format-detection"",""telephone=no""
";https://scholar.google.com/scholar?start=390&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095378-1608;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;[PDF][PDF] On the Security Notions for Encryption in a Quantum World.;C Chevalier, E Ebrahimi, QH Vu ; IACR Cryptol. ePrint Arch., 2020  eprint.iacr.org;;"… To remedy these problems, from the recent groundbreaking compressed oracle technique

introduced by Zhandry (CRYPTO'19), we … of quantum superposition attacks for different classical

cryptographic constructions such as random oracles, pseudorandom functions …";Cité 8 fois;Les 3 versions;[PDF] iacr.org;https://eprint.iacr.org/2020/237.pdf;;"""date"",""2020-04-15T22:31:11Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2020-04-15T22:31:11Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.20 (TeX Live 2019) kpathsea version 6.3.1""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2020-04-15T22:31:11Z""
""created"",""2020-04-15T22:31:11Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-04-15T22:31:11Z""
""resourceName"",""237.pdf""
""Author"",""""
""producer"",""pdfTeX-1.40.20""
""pdf:docinfo:producer"",""pdfTeX-1.40.20""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""15"",""10"",""0"",""2"",""5"",""3"",""7"",""18"",""8"",""23"",""40"",""25"",""31"",""17"",""33"",""25"",""20"",""16"",""37"",""18"",""32"",""34"",""11"",""16"",""21"",""8"",""13"",""0"",""0"",""0"",""20"",""18"",""19"",""52"",""54"",""63"",""67"",""93"",""29"",""21"",""10"",""19"",""35"",""22"",""30"",""14"",""17"",""28"",""38"",""53"",""34"",""7""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2020-04-15T22:31:11Z""
""Last-Modified"",""2020-04-15T22:31:11Z""
""dcterms:modified"",""2020-04-15T22:31:11Z""
""title"",""""
""Last-Save-Date"",""2020-04-15T22:31:11Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2020-04-15T22:31:11Z""
""meta:save-date"",""2020-04-15T22:31:11Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.20 (TeX Live 2019) kpathsea version 6.3.1""
""Content-Length"",""823397""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""55""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""2244"",""2723"",""2726"",""2781"",""2777"",""2672"",""2725"",""2527"",""2753"",""2882"",""1895"",""2029"",""2482"",""1741"",""2346"",""1784"",""2041"",""1933"",""2505"",""2127"",""1517"",""1275"",""1856"",""1831"",""2490"",""2140"",""2208"",""1697"",""2002"",""1900"",""2757"",""2830"",""554"",""1681"",""1543"",""1580"",""1421"",""1288"",""1716"",""1574"",""1010"",""1366"",""1617"",""1893"",""2038"",""1645"",""2132"",""1792"",""2437"",""1580"",""1743"",""1083"",""995"",""2028"",""1705""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-04-15T22:31:11Z""
";https://scholar.google.com/scholar?start=410&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095332-1408;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;On the Serverless Nature of Blockchains and Smart Contracts;V Yussupov, G Falazi, U Breitenbücher… ; arXiv preprint arXiv …, 2020  arxiv.org;;"… To invoke a smart contract, a client application formulates a crypto- graphically signed request …

can take several minutes to be confirmed in case the involved blockchain system utilizes …

Considering recent pricing for the Ether cryptocurrency, the difference has now risen to about …";Autres articles;;[PDF] arxiv.org;https://arxiv.org/pdf/2011.12729.pdf?utm_campaign=ConsenSys%20Diligence&utm_source=hs_email&utm_medium=email&_hsenc=p2ANqtz--wQeQie_BCg9LUcK0-BKnUrvYnrk4uGXjx2ApswW6WVloobsXKzODVGKvlJF0WZHbKzL_z;;"""date"",""2020-11-26T02:18:51Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""On the Serverless Nature of Blockchains and Smart Contracts""
""xmp:CreatorTool"",""LaTeX with hyperref""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""On the Serverless Nature of Blockchains and Smart Contracts""
""modified"",""2020-11-26T02:18:51Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""Vladimir Yussupov; Ghareeb Falazi; Uwe BreitenbĂźcher; Frank Leymann; ""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.21 (TeX Live 2020) kpathsea version 6.3.2""
""meta:author"",""Vladimir Yussupov; Ghareeb Falazi; Uwe BreitenbĂźcher; Frank Leymann; ""
""trapped"",""False""
""meta:creation-date"",""2020-11-26T02:18:51Z""
""created"",""2020-11-26T02:18:51Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-11-26T02:18:51Z""
""resourceName"",""2011.12729.pdf""
""Author"",""Vladimir Yussupov; Ghareeb Falazi; Uwe BreitenbĂźcher; Frank Leymann; ""
""producer"",""pdfTeX-1.40.21""
""pdf:docinfo:producer"",""pdfTeX-1.40.21""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""46"",""2"",""0"",""0"",""0"",""29"",""0"",""0"",""0"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""Vladimir Yussupov; Ghareeb Falazi; Uwe BreitenbĂźcher; Frank Leymann; ""
""dcterms:created"",""2020-11-26T02:18:51Z""
""Last-Modified"",""2020-11-26T02:18:51Z""
""dcterms:modified"",""2020-11-26T02:18:51Z""
""title"",""On the Serverless Nature of Blockchains and Smart Contracts""
""Last-Save-Date"",""2020-11-26T02:18:51Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2020-11-26T02:18:51Z""
""meta:save-date"",""2020-11-26T02:18:51Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.21 (TeX Live 2020) kpathsea version 6.3.2""
""Content-Length"",""1779257""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Vladimir Yussupov; Ghareeb Falazi; Uwe BreitenbĂźcher; Frank Leymann; ""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""22""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""4456"",""5101"",""5332"",""4954"",""4746"",""4551"",""3725"",""5164"",""4811"",""4582"",""4494"",""3637"",""5058"",""5124"",""5173"",""5301"",""3378"",""5269"",""5186"",""5408"",""6512"",""4657""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-11-26T02:18:51Z""
";https://scholar.google.com/scholar?start=210&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095369-1570;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;[PDF][PDF] PayPlace: Secure and Flexible Operator-Mediated Payments in Blockchain Marketplaces at Scale;M Harishankar, DG Akestoridis, SV Iyer, A Laszka… ; arXiv e …, 2020  researchgate.net;;"… There is also increasing interest in en- abling well-established two-sided marketplaces like

Amazon and Uber on blockchains [4], [5], which requires a scalable mechanism for consumers

to make cryptocurrency payments to merchants. Since blockchain transactions are known …";Autres articles;;[PDF] researchgate.net;https://www.researchgate.net/profile/Madhumitha_Harishankar/publication/339946354_PayPlace_Secure_and_Flexible_Operator-Mediated_Payments_in_Blockchain_Marketplaces_at_Scale/links/5fd6719245851553a0b555fb/PayPlace-Secure-and-Flexible-Operator-Mediated-Payments-in-Blockchain-Marketplaces-at-Scale.pdf;;;https://scholar.google.com/scholar?start=370&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095299-1270;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Oracle Blockchain-Gestión de derechos digitales (DRM) en elementos multimedia.;FÁ Martínez Muela ;2020 ruidera.uclm.es;;"En la actualidad, estamos rodeados de información, normalmente suele ser información 
digital, la cual, al igual que la información no digital, posee unos derechos de explotación 
que deben ser asegurados, con objeto de evitar un uso no autorizado o inadecuado. La …";;;null;;;;https://scholar.google.com/scholar?start=70&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095309-1313;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;[PDF][PDF] CYBER RISK MITIGATION IN CLOUD COMPUTING ENVIRONMENTS USING BLOCKCHAIN TECHNOLOGY;H Sengar, S Joshi ; PalArch's Journal of Archaeology of Egypt …, 2020  archives.palarch.nl;;"… 4.4 Use Case 4: Oracle Blockchain Blockcahin as a Service (BaaS) on Oracle Cloud is based

on Hyperledger Fabric … Oracle Blockchain platform assists the businesses to provide agility in

transactions and increasing trust across the whole business network …";Autres articles;;[PDF] palarch.nl;https://archives.palarch.nl/index.php/jae/article/download/1713/1707;;"""date"",""2020-12-05T09:34:44Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.5""
""xmp:CreatorTool"",""MicrosoftÂŽ Word 2013""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dc:creator"",""Sddam rateb darawseheh""
""language"",""en""
""dcterms:created"",""2020-12-05T09:34:44Z""
""Last-Modified"",""2020-12-05T09:34:44Z""
""dcterms:modified"",""2020-12-05T09:34:44Z""
""dc:format"",""application/pdf; version=1.5""
""Last-Save-Date"",""2020-12-05T09:34:44Z""
""pdf:docinfo:creator_tool"",""MicrosoftÂŽ Word 2013""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2020-12-05T09:34:44Z""
""meta:save-date"",""2020-12-05T09:34:44Z""
""pdf:encrypted"",""false""
""modified"",""2020-12-05T09:34:44Z""
""Content-Length"",""318821""
""pdf:hasMarkedContent"",""true""
""Content-Type"",""application/pdf""
""pdf:docinfo:creator"",""Sddam rateb darawseheh""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Sddam rateb darawseheh""
""dc:language"",""en-IN""
""meta:author"",""Sddam rateb darawseheh""
""meta:creation-date"",""2020-12-05T09:34:44Z""
""created"",""2020-12-05T09:34:44Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""8""
""Creation-Date"",""2020-12-05T09:34:44Z""
""resourceName"",""1707""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""1760"",""3194"",""3244"",""2443"",""2808"",""2630"",""2682"",""1321""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""Author"",""Sddam rateb darawseheh""
""producer"",""MicrosoftÂŽ Word 2013""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""MicrosoftÂŽ Word 2013""
""pdf:docinfo:created"",""2020-12-05T09:34:44Z""
";https://scholar.google.com/scholar?start=110&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095313-1330;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;[HTML][HTML] Do you need a blockchain in construction? Use case categories and decision framework for DLT design options;JJ Hunhevicz, DM Hall ; Advanced Engineering Informatics, 2020  Elsevier;;"… DLT is blockchain, which has its origin in the peer-to-peer cryptocurrency Bitcoin [1 … Proof-of-work

was the first blockchain consensus mechanism and the greatest innovation behind Bitcoin … types

of consensus mechanisms in public DLT are enabled by a crypto-economic design …";Cité 26 fois;Les 6 versions;[HTML] sciencedirect.com;https://www.sciencedirect.com/science/article/pii/S147403462030063X?casa_token=mIHdfvn4i4YAAAAA:nlnkDH6Ts9UNhIs4WSAG75S1E6Im2k3BVp579PEFlHG7LTP4U0nIE-yJJqfQU_PviB5WufeE;;;https://scholar.google.com/scholar?start=130&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095311-1322;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;A blockchain-based pattern for confidential and pseudo-anonymous contract enforcement;N Six, CN Ribalta, N Herbaut… ; 2020 IEEE 19th …, 2020  ieeexplore.ieee.org;;"… Oracles - in blockchain, an oracle is a system entitled to bring information

on-chain, as smart contracts cannot actively retrieve information [13]. Here,

oracles will provide data to serve contract enforcement …";Les 5 versions;;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/9342897/9342964/09343150.pdf?casa_token=1MyAdLPCm58AAAAA:5wQ9zEUMFb1AtRKCQYb_9OQg6YP0S2sFiOzkx3TaLVyk7M71fVHN_84dOurnQHVX_bJ-ZZF8QWc;;"""og:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""twitter:title"",""A Blockchain-Based Pattern for Confidential and Pseudo-Anonymous Contract Enforcement""
""twitter:card"",""summary""
""Description"",""Blockchain has been praised for its capacity to hold data in a decentralized and tamper-proof way. It also supports the execution of code through blockchain's s""
""og:title"",""A Blockchain-Based Pattern for Confidential and Pseudo-Anonymous Contract Enforcement""
""resourceName"",""09343150.pdf""
""language"",""en""
""title"",""A Blockchain-Based Pattern for Confidential and Pseudo-Anonymous Contract Enforcement | IEEE Conference Publication | IEEE Xplore""
""og:description"",""Blockchain has been praised for its capacity to hold data in a decentralized and tamper-proof way. It also supports the execution of code through blockchain's smart contracts, adding automation of actions to the network with high trustability. However, as smart contracts are visible by anybody on the network, the business data and logic may be at risk, thus companies could be reluctant to use such technology. This paper aims to propose a pattern that allows the execution of automatable legal contract clauses, where its execution states are stored in an on-chain smart-contract and the logic needed to enforce it wraps it off-chain. An engine completes this pattern by running a business process that corresponds to the legal contract. We then propose a pattern-based solution based on a real-life use case: transportation of refrigerated goods. We argue that this pattern guarantees companies pseudonymity and data confidentiality while ensuring that an audit trail can be reconstituted through the blockchain smart-contract to identify misbehavior or errors. This paper paves the way for a future possible implementation of the solution described, as well as its evaluation.""
""twitter:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-UA-Compatible"",""IE=Edge""
""viewport"",""width=device-width, initial-scale=1.0""
""dc:title"",""A Blockchain-Based Pattern for Confidential and Pseudo-Anonymous Contract Enforcement | IEEE Conference Publication | IEEE Xplore""
""twitter:description"",""Blockchain has been praised for its capacity to hold data in a decentralized and tamper-proof way. It also supports the execution of code through blockchain's smart contracts, adding automation of actions to the network with high trustability. However, as smart contracts are visible by anybody on the network, the business data and logic may be at risk, thus companies could be reluctant to use such technology. This paper aims to propose a pattern that allows the execution of automatable legal contract clauses, where its execution states are stored in an on-chain smart-contract and the logic needed to enforce it wraps it off-chain. An engine completes this pattern by running a business process that corresponds to the legal contract. We then propose a pattern-based solution based on a real-life use case: transportation of refrigerated goods. We argue that this pattern guarantees companies pseudonymity and data confidentiality while ensuring that an audit trail can be reconstituted through the blockchain smart-contract to identify misbehavior or errors. This paper paves the way for a future possible implementation of the solution described, as well as its evaluation.""
""Content-Encoding"",""UTF-8""
""Content-Type-Hint"",""text/html; charset=utf-8""
""Content-Length"",""42224""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=120&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095369-1566;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Towards a Blockchain-based Identity and Trust Management Framework for the IoV Ecosystem;A Theodouli, K Moschou, K Votis… ; 2020 Global Internet …, 2020  ieeexplore.ieee.org;;"… 68, no. 3, pp. 2906–2920, 2019. [8] B. Curran and J. Richards, “What are oracles,” Smart

Contracts, Chainlink & “The Oracle Problem”. Accessed, vol. 15, 2019. [9] A. Kosba, A. Miller,

E. Shi, Z. Wen, and C. Papamanthou, “Hawk: The blockchain model of …";Autres articles;;null;;;;https://scholar.google.com/scholar?start=370&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095325-1374;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;A Survey on Blockchain Consensus with a Performance Comparison of PoW, PoS and Pure PoS;C Lepore, M Ceria, A Visconti, UP Rao, KA Shah… ; Mathematics, 2020  mdpi.com;;"… Previous Article in Special Issue Resilient Custody of Crypto-Assets, and Threshold

Multisignatures … A Survey on Blockchain Consensus with a Performance Comparison of PoW,

PoS and Pure PoS … (This article belongs to the Special Issue The Cryptography of Cryptocurrency …";Cité 3 fois;Les 3 versions;[PDF] mdpi.com;https://www.mdpi.com/2227-7390/8/10/1782/pdf;;;https://scholar.google.com/scholar?start=180&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095360-1532;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Smart Contracts for Service-Level Agreements in Edge-to-Cloud Computing;P Kochovski, V Stankovski, S Gec, F Faticanti… ; Journal of Grid …, 2020  Springer;;"… The Smart Oracles are trusted third-party services that pro- vide means for SCs to communicate

with reg- istered APIs from the external services … In order to estimate an optimal deployment option,

this layer queries a Smart Oracle from the Blockchain Layer to retrieve …";Cité 3 fois;;null;;;;https://scholar.google.com/scholar?start=330&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095334-1423;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;[PDF][PDF] SkyEye: A Traceable Scheme for Blockchain.;T Ma, H Xu, P Li ; IACR Cryptol. ePrint Arch., 2020  eprint.iacr.org;;"… CipherTrace's sec- ond quarter 2019 cryptocurrency anti-money laundering report shows that

the total … identity proofs, associated with the users' private information, to the blockchain data.

SkyEye is designed by using some crypto- graphic primitives (including chameleon hash …";Cité 2 fois;;[PDF] iacr.org;https://eprint.iacr.org/2020/034.pdf;;"""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""14"",""65"",""2"",""0"",""5"",""0"",""78"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""SkyEye: A Traceable Scheme for Blockchain""
""xmp:CreatorTool"",""LaTeX with acmart 2020/04/30 v1.71 Typesetting articles for the Association for Computing Machinery and hyperref 2020-05-15 v7.00e Hypertext links for LaTeX""
""Keywords"",""traceable scheme, blockchain, chameleon hash, zero knowledge""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""subject"",""traceable scheme, blockchain, chameleon hash, zero knowledge""
""dc:creator"",""Tianjun Ma, Haixia Xu, and Peili Li""
""language"",""en""
""dcterms:created"",""2021-01-14T12:20:09Z""
""dc:format"",""application/pdf; version=1.5""
""title"",""SkyEye: A Traceable Scheme for Blockchain""
""pdf:docinfo:creator_tool"",""LaTeX with acmart 2020/04/30 v1.71 Typesetting articles for the Association for Computing Machinery and hyperref 2020-05-15 v7.00e Hypertext links for LaTeX""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:keywords"",""traceable scheme, blockchain, chameleon hash, zero knowledge""
""pdf:encrypted"",""false""
""dc:title"",""SkyEye: A Traceable Scheme for Blockchain""
""Content-Length"",""583908""
""pdf:hasMarkedContent"",""false""
""Content-Type"",""application/pdf""
""pdf:docinfo:creator"",""Tianjun Ma, Haixia Xu, and Peili Li""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Tianjun Ma, Haixia Xu, and Peili Li""
""dc:language"",""en""
""meta:author"",""Tianjun Ma, Haixia Xu, and Peili Li""
""dc:subject"",""traceable scheme, blockchain, chameleon hash, zero knowledge""
""meta:creation-date"",""2021-01-14T12:20:09Z""
""created"",""2021-01-14T12:20:09Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""13""
""Creation-Date"",""2021-01-14T12:20:09Z""
""resourceName"",""034.pdf""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""4620"",""5214"",""4649"",""4262"",""5387"",""2325"",""5294"",""2198"",""4393"",""6576"",""8319"",""4545"",""3446""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""meta:keyword"",""traceable scheme, blockchain, chameleon hash, zero knowledge""
""Author"",""Tianjun Ma, Haixia Xu, and Peili Li""
""producer"",""MiKTeX-dvipdfmx (20200315)""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""MiKTeX-dvipdfmx (20200315)""
""pdf:docinfo:created"",""2021-01-14T12:20:09Z""
";https://scholar.google.com/scholar?start=220&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095334-1414;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;[HTML][HTML] A blockchain-based framework for electronic medical records sharing with fine-grained access control;J Sun, L Ren, S Wang, X Yao ; Plos one, 2020  journals.plos.org;United States of America;"… proposed the concept of blockchain [6], it is called Bitcoin as the underline technology behind

the cryptocurrency, which helps … code (contract) that triggers execution when the two parties make

a transaction transfer on the blockchain asset … Phase1: can repeatedly ask the oracle …";Cité 2 fois;Les 12 versions;[HTML] plos.org;https://journals.plos.org/plosone/article?id=10.1371/journal.pone.0239946;;"""og:image"",""https://journals.plos.org/plosone/article/figure/image?id=10.1371/journal.pone.0239946.g006&size=inline""
""citation_author_institution"",""School of Science, Xi’an University of Technology, Xi’an, Shaanxi, China"",""School of Science, Xi’an University of Technology, Xi’an, Shaanxi, China"",""School of Science, Xi’an University of Technology, Xi’an, Shaanxi, China"",""School of Science, Xi’an University of Technology, Xi’an, Shaanxi, China""
""citation_title"",""A blockchain-based framework for electronic medical records sharing with fine-grained access control""
""twitter:card"",""summary""
""keywords"",""Cryptography,Physicians,Encryption,Electronic medical records,Insurance,Algorithms,Medicine and health sciences,Cloud computing""
""citation_reference"",""citation_title=Secure multiparty data sharing in the cloud using hardware-based TPM devices;citation_author=T Danan;citation_author=C Shiping;citation_author=N Surya;citation_first_page=224;citation_last_page=231;citation_publication_date=2014;"",""citation_title=BSS: Block-based sharing scheme for secure data storage services in mobile cloud environment;citation_author=K A Nasir;citation_author=L M Miss;citation_author=A Mazhar;citation_author=M Sajjad;citation_journal_title=J. Supercomput.;citation_volume=70;citation_number=70;citation_issue=2;citation_first_page=946;citation_last_page=976;citation_publication_date=2014;"",""citation_title=Achieving an effective, scalable and privacy-preserving data sharing service in cloud computing;citation_author=D Xin;citation_author=Y Jiadi;citation_author=L Yuan;citation_author=C Ying;citation_author=X Guang;citation_author=L Ming;citation_journal_title=Comput. Secur.;citation_volume=42;citation_number=42;citation_first_page=151;citation_last_page=164;citation_publication_date=2014;"",""citation_title=A hybrid solution for privacy preserving medical data sharing in the cloud environment in Future Generat;citation_author=J J Yang;citation_author=J Q Li;citation_author=Y Niu;citation_journal_title=Comput. Syst.;citation_volume=43–44;citation_number=43;citation_first_page=74;citation_last_page=86;citation_publication_date=2015;"",""citation_title=A general framework for secure sharing of personal health records in cloud system[J];citation_author=M H Au;citation_author=T H Yuen;citation_author=J K Liu;citation_journal_title=Journal of Computer and System Sciences;citation_first_page=S0022000017300296;citation_publication_date=2017;"",""citation_title=Bitcoin: A peer-to-peer electronic cash system;citation_author=S Nakamoto;citation_journal_title=Bitcoin: A peer-to-peer electronic cash system;citation_publication_date=2008;"",""citation_title=Decentralizing privacy: Using blockchain to protect personal data;citation_author=Z Guy;citation_author=N Oz;citation_author=S P Alex;citation_journal_title=Decentralizing privacy: Using blockchain to protect personal data;citation_first_page=180;citation_last_page=184;citation_publication_date=2015;"",""citation_title=A blockchainbased approach to health information exchange networks;citation_author=K Peterson;citation_author=R Deeduvanu;citation_author=P Kanjamala;citation_author=K Boles;citation_journal_title=A blockchainbased approach to health information exchange networks;citation_first_page=1;citation_last_page=10;citation_publication_date=2016;"",""citation_title=Blockchain: Opportunities for health care;citation_author=J Krawiec R;citation_journal_title=Blockchain: Opportunities for health care;citation_first_page=1;citation_last_page=16;citation_publication_date=2016;"",""citation_title=MeDShare: Trust-less Medical Data Sharing Among Cloud Service Providers Via Blockchain;citation_author=X Qi;citation_author=BS Emmanuel;citation_author=A Kwame O;citation_author=J Gao;citation_author=X Du;citation_author=G Mohsen;citation_journal_title=MeDShare: Trust-less Medical Data Sharing Among Cloud Service Providers Via Blockchain;citation_volume=5;citation_number=5;citation_first_page=14757;citation_last_page=14767;citation_publication_date=2017;"",""citation_title=Towards Secure and Privacy-Preserving Data Sharing in e-Health Systems via Consortium Blockchain;citation_author=A Zhang;citation_author=X Lin;citation_journal_title=Towards Secure and Privacy-Preserving Data Sharing in e-Health Systems via Consortium Blockchain;citation_volume=42;citation_number=42;citation_issue=8;citation_first_page=140;"",""citation_title=Conjunctive Keyword Search with Designated Tester and Timing Enabled Proxy Re-encryption Function for E-health Clouds[J];citation_author=Y Yang;citation_author=M Ma;citation_journal_title=IEEE Transactions on Information Forensics and Security;citation_first_page=746;citation_last_page=759;citation_publication_date=2016;"",""Blockchain for Financial Services. Accessed: Mar. 25, 2018. [Online]. Available:  https://www.ibm.com/blockchain/financial-services "",""Blockchain for Supply Chain. Accessed: Mar. 25, 2018. [Online]. Available:  https://www.ibm.com/blockchain/supply-chain "",""A Decentralized Network for Internet of Things. Accessed: Mar. 25, 2018. [Online]. Available:  https://iotex.io "",""citation_title=; A review on the use of blockchain for the internet of things; IEEE Access;citation_author=T M Fernández-Caramés;citation_author=P Fraga-Lamas;citation_journal_title=; A review on the use of blockchain for the internet of things; IEEE Access;citation_publication_date=2018;"",""citation_title=The idea of smart contracts; Nick SzaboâA ˘Zs Papers and ´ Concise Tutorials;citation_author=S Nick;citation_journal_title=The idea of smart contracts; Nick SzaboâA ˘Zs Papers and ´ Concise Tutorials;citation_volume=6;citation_number=6;citation_publication_date=1997;"",""citation_title=Secure Management of Personal Health Records by Applying Attribute-Based Encryption;citation_author=L Ibraimi;citation_author=M Asim;citation_journal_title=Secure Management of Personal Health Records by Applying Attribute-Based Encryption;citation_publication_date=2009;"",""citation_title=Scalable and Secure Sharing of Personal Health Records in Cloud Computing Using Attribute-Based Encryption[J];citation_author=M Li;citation_author=S Yu;citation_author=Y Zheng;citation_journal_title=IEEE Transactions on Parallel and Distributed Systems;citation_volume=24;citation_number=24;citation_issue=1;citation_first_page=131;citation_last_page=143;citation_publication_date=2013;"",""citation_title=Designing cloud-based electronic health record system with attribute-based encryption;citation_author=X Fatos;citation_author=J Li;citation_author=G Zhao;citation_author=X Chen;citation_author=D S Wong;citation_volume=74;citation_number=74;citation_issue=10;citation_first_page=3441;citation_last_page=3458;citation_publication_date=2015;"",""citation_title=A simple approach to share users&apos; own healthcare data with a mobile phone;citation_author=H Kim;citation_author=H Song;citation_author=S Lee;citation_publication_date=2016;citation_publisher=IEEE"",""citation_title=BBDS: Blockchain-Based data sharing for electronic medical records in cloud environments;citation_author=X Qi;citation_author=B SIFAHE;citation_author=A Amofa;citation_volume=8;citation_number=8;citation_issue=44;citation_first_page=1;citation_last_page=16;citation_publication_date=2017;"",""citation_title=Secure and efficient data accessibility in blockchain based healthcare systems;citation_author=V Ramani;citation_author=T Kumar;citation_author=A Bracken;citation_author=M Liyanage;citation_author=M Ylianttila;citation_journal_title=GLOBECOM;citation_first_page=206;citation_last_page=212;citation_publication_date=2018;"",""citation_title=A searchable personal health records framework with fine-grained access control in cloud-fog computing;citation_author=J Sun;citation_author=X Wang;citation_author=S Wang;citation_author=L Ren;citation_journal_title=PLoS ONE;citation_volume=13;citation_number=13;citation_issue=11;citation_first_page=e0207543;citation_publication_date=2018;"",""citation_title=FHIRChain: Applying Blockchain to Securely and Scalably Share Clinical Data;citation_author=P Zhang;citation_author=J White;citation_author=C Schmidt D;citation_author=L Gunther;citation_author=S T Rosenbloom;citation_journal_title=FHIRChain: Applying Blockchain to Securely and Scalably Share Clinical Data;citation_volume=16;citation_number=16;citation_first_page=267;citation_last_page=278;citation_publication_date=2018;"",""citation_title=Emerging Blockchain Technology Solutions for Modern Healthcare Infrastructure;citation_author=K Yaeger;citation_journal_title=Emerging Blockchain Technology Solutions for Modern Healthcare Infrastructure;citation_volume=2;citation_number=2;citation_issue=1;citation_publication_date=2019;"",""citation_title=Blockchain for Secure EHRs Sharing of Mobile Cloud Based E-Health Systems;citation_author=C Nguyen D;citation_author=N Pathirana P;citation_author=M Ding;citation_author=A Seneviratne;citation_journal_title=IEEE Access;citation_first_page=66792;citation_last_page=66806;citation_publication_date=2019;"",""citation_title=IPFS-content addressed, versioned, P2P file system;citation_author=B Juan;citation_publication_date=2014;"",""citation_title=Fuzzy identity-based encryption.;citation_author=S Amit;citation_author=W Brent;citation_first_page=457;citation_last_page=473;citation_publication_date=2005;citation_publisher=Springer"",""citation_title=Identity-based cryptosystems and signature schemes;citation_author=S Adi;citation_first_page=47;citation_last_page=53;citation_publication_date=1985;citation_publisher=Springer"",""citation_title=Attribute-based encryption for fine-grained access control of encrypted data;citation_author=V Goyal;citation_author=O Pandey;citation_author=S Amit;citation_author=W Brent;citation_first_page=89;citation_last_page=98;citation_publication_date=2006;citation_publisher=ACM"",""citation_title=A Searchable Symmetric Encryption Scheme using BlockChain;citation_author=H Li;citation_author=F Zhang;citation_author=J He;citation_author=H Tian;citation_journal_title=A Searchable Symmetric Encryption Scheme using BlockChain;citation_publication_date=2017;"",""citation_title=Verifiable keyword search over encrypted cloud data in smart city;citation_author=Y Miao;citation_author=J Ma;citation_author=Q Jiang;citation_author=X Li;citation_journal_title=Computers & Electrical Engineering;citation_volume=65;citation_number=65;citation_first_page=1;citation_last_page=12;citation_publication_date=2017;"",""citation_title=Fast probabilistic algorithms for verification of polynomial identities in Journal of the ACM (JACM);citation_author=T S Jacob;citation_journal_title=Fast probabilistic algorithms for verification of polynomial identities in Journal of the ACM (JACM);citation_volume=27;citation_number=27;citation_issue=4;citation_first_page=701;citation_last_page=717;citation_publication_date=1980;"",""citation_title=Pairing-based cryptography;citation_author=S Duquesne;citation_author=T Lange;citation_volume=22;citation_number=22;citation_first_page=573;citation_last_page=590;citation_publication_date=2005;"",""Solidity. Accessed: Jun. 10, 2017. [Online]. Available:  http://solidity.readthedocs.io/en/latest ""
""citation_publisher"",""Public Library of Science""
""citation_journal_title"",""PLOS ONE""
""description"",""In the medical system, the verification, preservation and synchronization of electronic medical records has always been a difficult problem, and the random dissemination of patient records will bring various risks to patient privacy. Therefore, how to achieve secure data sharing on the basis of ensuring users’ personal privacy becomes the key. In recent years, blockchain has been proposed to be a promising solution to achieve data sharing with security and privacy preservation due to its advantages of immutability. So, a distributed electronic medical records searchable scheme was proposed by leveraging blockchain and smart contract technology. Firstly, we perform a hash calculation on the electronic medical data and store the corresponding value on the blockchain to ensure its integrity and authenticity. Then, we encrypt the electronic medical data and store it in the interplanetary file system which is a distributed storage protocol. These operations not only can solve centralized data store of servers of several medical institutions, but also be good at lowering stress from data store and high-frequency access to blockchain. Secondly, the encrypted keyword index information of electronic medical records was stored on the Ethereum blockchain, meanwhile a smart contract deployed in the Ethereum blockchain is used to realize keyword search instead of depending on a centralized third party. Furthermore, we use attribute-based encryption scheme to ensure that only the attributes meeting the access policy can decrypt the encrypted electronic medical records. Finally, our performance analysis and security analysis show that the scheme is secure and efficient.""
""language"",""en""
""citation_date"",""Oct 6, 2020""
""title"",""A blockchain-based framework for electronic medical records sharing with fine-grained access control""
""og:description"",""In the medical system, the verification, preservation and synchronization of electronic medical records has always been a difficult problem, and the random dissemination of patient records will bring various risks to patient privacy. Therefore, how to achieve secure data sharing on the basis of ensuring users’ personal privacy becomes the key. In recent years, blockchain has been proposed to be a promising solution to achieve data sharing with security and privacy preservation due to its advantages of immutability. So, a distributed electronic medical records searchable scheme was proposed by leveraging blockchain and smart contract technology. Firstly, we perform a hash calculation on the electronic medical data and store the corresponding value on the blockchain to ensure its integrity and authenticity. Then, we encrypt the electronic medical data and store it in the interplanetary file system which is a distributed storage protocol. These operations not only can solve centralized data store of servers of several medical institutions, but also be good at lowering stress from data store and high-frequency access to blockchain. Secondly, the encrypted keyword index information of electronic medical records was stored on the Ethereum blockchain, meanwhile a smart contract deployed in the Ethereum blockchain is used to realize keyword search instead of depending on a centralized third party. Furthermore, we use attribute-based encryption scheme to ensure that only the attributes meeting the access policy can decrypt the encrypted electronic medical records. Finally, our performance analysis and security analysis show that the scheme is secure and efficient.""
""twitter:image"",""https://journals.plos.org/plosone/article/figure/image?id=10.1371/journal.pone.0239946.g006&size=inline""
""citation_issn"",""1932-6203""
""twitter:site"",""@plosone""
""dc:title"",""A blockchain-based framework for electronic medical records sharing with fine-grained access control""
""Content-Encoding"",""UTF-8""
""Content-Type-Hint"",""text/html; charset=utf-8""
""citation_pdf_url"",""https://journals.plos.org/plosone/article/file?id=10.1371/journal.pone.0239946&type=printable""
""Content-Type"",""text/html; charset=UTF-8""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""twitter:title"",""A blockchain-based framework for electronic medical records sharing with fine-grained access control""
""og:type"",""article""
""citation_journal_abbrev"",""PLOS ONE""
""citation_article_type"",""Research Article""
""citation_abstract"",""In the medical system, the verification, preservation and synchronization of electronic medical records has always been a difficult problem, and the random dissemination of patient records will bring various risks to patient privacy. Therefore, how to achieve secure data sharing on the basis of ensuring users’ personal privacy becomes the key. In recent years, blockchain has been proposed to be a promising solution to achieve data sharing with security and privacy preservation due to its advantages of immutability. So, a distributed electronic medical records searchable scheme was proposed by leveraging blockchain and smart contract technology. Firstly, we perform a hash calculation on the electronic medical data and store the corresponding value on the blockchain to ensure its integrity and authenticity. Then, we encrypt the electronic medical data and store it in the interplanetary file system which is a distributed storage protocol. These operations not only can solve centralized data store of servers of several medical institutions, but also be good at lowering stress from data store and high-frequency access to blockchain. Secondly, the encrypted keyword index information of electronic medical records was stored on the Ethereum blockchain, meanwhile a smart contract deployed in the Ethereum blockchain is used to realize keyword search instead of depending on a centralized third party. Furthermore, we use attribute-based encryption scheme to ensure that only the attributes meeting the access policy can decrypt the encrypted electronic medical records. Finally, our performance analysis and security analysis show that the scheme is secure and efficient.""
""og:title"",""A blockchain-based framework for electronic medical records sharing with fine-grained access control""
""citation_author"",""Jin Sun"",""Lili Ren"",""Shangping Wang"",""Xiaomin Yao""
""resourceName"",""article""
""citation_issue"",""10""
""citation_firstpage"",""e0239946""
""citation_doi"",""10.1371/journal.pone.0239946""
""twitter:description"",""In the medical system, the verification, preservation and synchronization of electronic medical records has always been a difficult problem, and the random dissemination of patient records will bring various risks to patient privacy. Therefore, how to achieve secure data sharing on the basis of ensuring users’ personal privacy becomes the key. In recent years, blockchain has been proposed to be a promising solution to achieve data sharing with security and privacy preservation due to its advantages of immutability. So, a distributed electronic medical records searchable scheme was proposed by leveraging blockchain and smart contract technology. Firstly, we perform a hash calculation on the electronic medical data and store the corresponding value on the blockchain to ensure its integrity and authenticity. Then, we encrypt the electronic medical data and store it in the interplanetary file system which is a distributed storage protocol. These operations not only can solve centralized data store of servers of several medical institutions, but also be good at lowering stress from data store and high-frequency access to blockchain. Secondly, the encrypted keyword index information of electronic medical records was stored on the Ethereum blockchain, meanwhile a smart contract deployed in the Ethereum blockchain is used to realize keyword search instead of depending on a centralized third party. Furthermore, we use attribute-based encryption scheme to ensure that only the attributes meeting the access policy can decrypt the encrypted electronic medical records. Finally, our performance analysis and security analysis show that the scheme is secure and efficient.""
""dc.identifier"",""10.1371/journal.pone.0239946""
""citation_volume"",""15""
""og:url"",""https://journals.plos.org/plosone/article?id=10.1371/journal.pone.0239946""
""Content-Language"",""en""
";https://scholar.google.com/scholar?start=220&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095318-1347;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;[PDF][PDF] Post-Quantum Linkable Ring Signature Enabling Distributed Authorised Ring Confidential Transactions in Blockchain;WA Torres, R Steinfeld, A Sakzad, V Kuchta ;2020 eprint.iacr.org;;"… Similarly, blockchain technology, particularly cryptocurrencies [27], incorporates TS schemes

to provide an extra, more restric … the challenger C and an existential adversary A who has access

to the oracles in Section … Setup(1?) and gives it to A. – A queries the KO oracle Qk times …";Cité 1 fois;Les 2 versions;[PDF] iacr.org;https://eprint.iacr.org/2020/1121.pdf;;"""date"",""2020-09-16T04:28:12Z""
""pdf:unmappedUnicodeCharsPerPage"",""1"",""0"",""0"",""12"",""31"",""10"",""4"",""5"",""20"",""78"",""75"",""41"",""88"",""31"",""7"",""0"",""0"",""0"",""25"",""13"",""73"",""83"",""18"",""17"",""79"",""38"",""77"",""75"",""31"",""23"",""52"",""75"",""43"",""31"",""75"",""68"",""35"",""23"",""49"",""79"",""28"",""17"",""78"",""51"",""9""
""pdf:PDFVersion"",""1.5""
""xmp:CreatorTool"",""TeX""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dcterms:created"",""2020-09-16T04:28:12Z""
""language"",""en""
""Last-Modified"",""2020-09-16T04:28:12Z""
""dcterms:modified"",""2020-09-16T04:28:12Z""
""dc:format"",""application/pdf; version=1.5""
""Last-Save-Date"",""2020-09-16T04:28:12Z""
""pdf:docinfo:creator_tool"",""TeX""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2020-09-16T04:28:12Z""
""meta:save-date"",""2020-09-16T04:28:12Z""
""pdf:encrypted"",""false""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.20 (TeX Live 2019) kpathsea version 6.3.1""
""modified"",""2020-09-16T04:28:12Z""
""Content-Length"",""631997""
""pdf:hasMarkedContent"",""false""
""Content-Type"",""application/pdf""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.20 (TeX Live 2019) kpathsea version 6.3.1""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""trapped"",""False""
""meta:creation-date"",""2020-09-16T04:28:12Z""
""created"",""2020-09-16T04:28:12Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""45""
""Creation-Date"",""2020-09-16T04:28:12Z""
""resourceName"",""1121.pdf""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""2023"",""2918"",""2934"",""2285"",""2148"",""2369"",""2313"",""1897"",""1746"",""1943"",""2159"",""1931"",""2103"",""1557"",""2293"",""778"",""2772"",""2744"",""2415"",""612"",""922"",""949"",""1645"",""1668"",""1956"",""1361"",""1952"",""1886"",""1986"",""1850"",""1535"",""1871"",""1580"",""2042"",""1856"",""1797"",""1561"",""1836"",""1640"",""1949"",""1765"",""1677"",""1569"",""1477"",""552""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""producer"",""pdfTeX-1.40.20""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""pdfTeX-1.40.20""
""pdf:docinfo:created"",""2020-09-16T04:28:12Z""
";https://scholar.google.com/scholar?start=150&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095399-1697;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;An Extended CTRT for AES-256;A Kunii, J Oketani, S Kunii… ; … Conference, WISA 2019 …, 2020  books.google.com;;"… At CRYPTO 2000, Desai [6] suggested a new security definition for AONTs regarding key privacy

and a new … FK? 1 (y). In the ideal cipher model, we assume that we have an oracle access to

(F … However, since we allow them to access the oracles (F, F? 1), they may use the ideal …";Autres articles;;null;;;;https://scholar.google.com/scholar?start=500&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095332-1412;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;[PDF][PDF] PF-BVM: A Privacy-aware Fog-enhanced Blockchain Validation Mechanism.;H Baniata, A Kertész ; CLOSER, 2020  researchgate.net;;"… Abstract: Blockchain technology has been successfully implemented in cryptocurrency

industries, yet it is in the re- search phase for other applications … Trust management in a

blockchain based fog computing platform with trust- less smart oracles …";Cité 2 fois;Les 4 versions;[PDF] researchgate.net;https://www.researchgate.net/profile/Attila_Kertesz/publication/341482783_PF-BVM_A_Privacy-aware_Fog-enhanced_Blockchain_Validation_Mechanism/links/5ec791fb458515626cbf4ec5/PF-BVM-A-Privacy-aware-Fog-enhanced-Blockchain-Validation-Mechanism.pdf;;;https://scholar.google.com/scholar?start=210&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095295-1246;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Cross-chain Oracle Based Data Migration Mechanism in Heterogeneous Blockchains;Z Gao, H Li, K Xiao, Q Wang ; 2020 IEEE 40th International …, 2020  ieeexplore.ieee.org;;"… Uniquely identifying a blockchain and clarifying how oracles connect with blockchain should

be … We discuss the proposal of interactive blockchain architecture between two heterogeneous

blockchains … chain data migration architecture based on data migration oracle, which can …";Les 2 versions;;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/9355572/9355578/09355678.pdf?casa_token=0kq_CyVkWhsAAAAA:g-TSVm3YC83mCfBqnPFx2cZTXAcZ4gHtvYZKxz3rLccjK7a5b0UoYGsf0HLCJo_HWMzHaRU67_U;;"""og:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""twitter:title"",""Cross-chain Oracle Based Data Migration Mechanism in Heterogeneous Blockchains""
""twitter:card"",""summary""
""Description"",""As things currently stand, the blockchain industry is siloed among many different platforms and protocols resulting in various islands of blockchains. Restricti""
""og:title"",""Cross-chain Oracle Based Data Migration Mechanism in Heterogeneous Blockchains""
""resourceName"",""09355678.pdf""
""language"",""en""
""title"",""Cross-chain Oracle Based Data Migration Mechanism in Heterogeneous Blockchains | IEEE Conference Publication | IEEE Xplore""
""og:description"",""As things currently stand, the blockchain industry is siloed among many different platforms and protocols resulting in various islands of blockchains. Restrictions regarding assets transfers and data migration between different blockchains reduce the usability and comfort of users, and hinder novel developments within the blockchain ecosystem. Interoperability will be the main topics of next-generation blockchain technologies. In this paper, we focus on how to enable interoperability between two heterogeneous blockchains in the context of data migration. We first build an cross-chain data migration architecture based on data migration oracle. Second, we design a data migration mechanism based on former architecture. By employing the proposed data migration architecture, it is equivalent to opening a secure channel between two heterogeneous blockchains allowing secure data migration. By applying data migration mechanism, the confidentiality, integrity and security of migrated data can be well guaranteed.""
""twitter:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-UA-Compatible"",""IE=Edge""
""viewport"",""width=device-width, initial-scale=1.0""
""dc:title"",""Cross-chain Oracle Based Data Migration Mechanism in Heterogeneous Blockchains | IEEE Conference Publication | IEEE Xplore""
""twitter:description"",""As things currently stand, the blockchain industry is siloed among many different platforms and protocols resulting in various islands of blockchains. Restrictions regarding assets transfers and data migration between different blockchains reduce the usability and comfort of users, and hinder novel developments within the blockchain ecosystem. Interoperability will be the main topics of next-generation blockchain technologies. In this paper, we focus on how to enable interoperability between two heterogeneous blockchains in the context of data migration. We first build an cross-chain data migration architecture based on data migration oracle. Second, we design a data migration mechanism based on former architecture. By employing the proposed data migration architecture, it is equivalent to opening a secure channel between two heterogeneous blockchains allowing secure data migration. By applying data migration mechanism, the confidentiality, integrity and security of migrated data can be well guaranteed.""
""Content-Encoding"",""UTF-8""
""Content-Type-Hint"",""text/html; charset=utf-8""
""Content-Length"",""41486""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=50&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095351-1491;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Blockchain and Cryptocurrencies;S Van Hijfte ; Decoding Blockchain for Business, 2020  Springer;;"… 58 Aleksandr Bulkin cites the example of blockchain oracles, which do work in his opinion opposite

to … The reason is that oracles require people to bet on (easily) publicly observable information

in … The key components of the oracle is that there is objective information that can …";;null;[HTML] nih.gov;https://www.ncbi.nlm.nih.gov/pmc/articles/pmc7989927/;;;https://scholar.google.com/scholar?start=290&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095374-1587;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Online Voting System for Indian Electoral Process (Using Blockchain Concept);S Sehgal, P Thakral ;2020 ir.juit.ac.in;;"… It has slow transaction time ie 10 minutes. Its focus is on crypto currency. 1.6.12 … Data on a

blockchain only exists on the blockchain so it must receive outsider data elsewhere. This outsider

data is provided by Oracles to the blockchain from external sources. Data is …";;;[PDF] juit.ac.in;http://www.ir.juit.ac.in:8080/jspui/bitstream/123456789/24108/1/Online%20Voting%20System%20for%20Indian%20Electoral%20Process%20%20using%20Blockchain%20Concept.pdf;;"""date"",""2020-07-17T10:49:39Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.7""
""xmp:CreatorTool"",""Adobe Acrobat Pro 2017 17.11.30171""
""pdf:docinfo:title"",""""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dcterms:created"",""2020-07-17T10:49:39Z""
""language"",""en""
""Last-Modified"",""2020-07-17T10:49:39Z""
""dcterms:modified"",""2020-07-17T10:49:39Z""
""dc:format"",""application/pdf; version=1.7""
""title"",""""
""xmpMM:DocumentID"",""uuid:bfaa7f7d-0036-475a-a384-fcf5cb9a5469""
""Last-Save-Date"",""2020-07-17T10:49:39Z""
""pdf:docinfo:creator_tool"",""Adobe Acrobat Pro 2017 17.11.30171""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2020-07-17T10:49:39Z""
""meta:save-date"",""2020-07-17T10:49:39Z""
""pdf:encrypted"",""false""
""dc:title"",""""
""xmp:CreateDate"",""2020-07-17T16:19:39Z""
""modified"",""2020-07-17T10:49:39Z""
""Content-Length"",""2739349""
""pdf:hasMarkedContent"",""true""
""Content-Type"",""application/pdf""
""xmp:ModifyDate"",""2020-07-17T16:19:39Z""
""xmp:MetadataDate"",""2020-07-17T16:19:39Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""pdf:producer"",""Adobe Acrobat Pro 2017 17.11.30171""
""meta:creation-date"",""2020-07-17T10:49:39Z""
""created"",""2020-07-17T10:49:39Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""63""
""Creation-Date"",""2020-07-17T10:49:39Z""
""resourceName"",""Online%20Voting%20System%20for%20Indian%20Electoral%20Process%20%20using%20Blockchain%20Concept.pdf""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""461"",""1162"",""1178"",""1642"",""1117"",""372"",""683"",""1302"",""421"",""1662"",""1597"",""1428"",""1021"",""1926"",""1928"",""1229"",""854"",""2070"",""2020"",""2038"",""2265"",""2275"",""1999"",""854"",""2162"",""2203"",""1629"",""2087"",""1910"",""1931"",""2071"",""1816"",""1692"",""1668"",""758"",""825"",""2204"",""1251"",""1017"",""778"",""884"",""877"",""759"",""251"",""438"",""908"",""427"",""521"",""393"",""155"",""227"",""371"",""189"",""69"",""80"",""2256"",""1565"",""1759"",""686"",""480"",""584"",""2408"",""2422""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""producer"",""Adobe Acrobat Pro 2017 17.11.30171""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""Adobe Acrobat Pro 2017 17.11.30171""
""pdf:docinfo:created"",""2020-07-17T10:49:39Z""
";https://scholar.google.com/scholar?start=390&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095351-1488;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;The Need to Use a Hash Function to Build a Crypto Algorithm for Blockchain;T Wi?ckowski ; … Computer Systems: Proceedings of the Fifteenth …, 2020  books.google.com;;"… There is no formula or algorithm for calculating h (x). There is only one way to find out Page 76.

The Need to Use a Hash Function to Build a Crypto Algorithm for Blockchain 59 h (x)-go to the

oracle. ROM is an atomic or monolithic entity that cannot be broken apart …";Autres articles;;null;;;;https://scholar.google.com/scholar?start=290&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095392-1673;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;[PDF][PDF] Achieving privacy and accountability in traceable digital currency;A Barki, A Gouget ;2020 eprint.iacr.org;;"… properties of transferable electronic cash (eCash) that are not based on blockchain technology

have … We model A's capabilities by giving it access to several oracles defined as follows … The oracle

OSKeyGen(PCA) creates a certification authority by generating a signature key pair …";Cité 1 fois;;[PDF] iacr.org;https://eprint.iacr.org/2020/1565.pdf;;"""date"",""2020-12-15T06:08:10Z""
""pdf:unmappedUnicodeCharsPerPage"",""6"",""0"",""0"",""0"",""0"",""1"",""0"",""0"",""6"",""6"",""19"",""0"",""2"",""0"",""0"",""0"",""42"",""14"",""0"",""0"",""17"",""3""
""pdf:PDFVersion"",""1.5""
""xmp:CreatorTool"",""TeX""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dcterms:created"",""2020-12-15T06:08:10Z""
""language"",""en""
""Last-Modified"",""2020-12-15T06:08:10Z""
""dcterms:modified"",""2020-12-15T06:08:10Z""
""dc:format"",""application/pdf; version=1.5""
""Last-Save-Date"",""2020-12-15T06:08:10Z""
""pdf:docinfo:creator_tool"",""TeX""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2020-12-15T06:08:10Z""
""meta:save-date"",""2020-12-15T06:08:10Z""
""pdf:encrypted"",""false""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is MiKTeX-pdfTeX 4.0.1 (1.40.21)""
""modified"",""2020-12-15T06:08:10Z""
""Content-Length"",""453554""
""pdf:hasMarkedContent"",""false""
""Content-Type"",""application/pdf""
""PTEX.Fullbanner"",""This is MiKTeX-pdfTeX 4.0.1 (1.40.21)""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""trapped"",""False""
""meta:creation-date"",""2020-12-15T06:08:10Z""
""created"",""2020-12-15T06:08:10Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""22""
""Creation-Date"",""2020-12-15T06:08:10Z""
""resourceName"",""1565.pdf""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""2124"",""2899"",""2549"",""2207"",""2581"",""2372"",""2231"",""2542"",""2368"",""1918"",""2534"",""2139"",""2482"",""2670"",""2197"",""2764"",""1764"",""2075"",""2237"",""2396"",""2565"",""1086""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""producer"",""MiKTeX pdfTeX-1.40.21""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""MiKTeX pdfTeX-1.40.21""
""pdf:docinfo:created"",""2020-12-15T06:08:10Z""
";https://scholar.google.com/scholar?start=470&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095365-1549;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;An autonomous loyalty program based on blockchains for IoT solution providers;S Gheitanchi ; 2020 IEEE Global Conference on Artificial …, 2020  ieeexplore.ieee.org;;"… B. Oracles In this layer, the DVM low-level instructions are encapsulated in form of APIs and

are accessible via each blockchain node. Tables II shows oracle introduction sets for the

exchange platform operations. TABLE II. ORACLE API COMMANDS …";;null;null;;;;https://scholar.google.com/scholar?start=350&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095378-1610;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;[PDF][PDF] The Velvet Path to Superlight Blockchain Clients;A Kiayias, A Polydouri, D Zindros ;2020 eprint.iacr.org;;"… As long as the blockchain property is maintained, we freely use the set operators ?, ? and ?

to denote operations between chains, implying that the appropriate blocks are selected and then …

Each party is given q queries to the random oracle which it uses in attempting to mine …";Autres articles;Version HTML;[PDF] iacr.org;https://eprint.iacr.org/2020/1122.pdf;;"""date"",""2020-08-05T16:14:45Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2020-08-05T16:14:45Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.19 (TeX Live 2018) kpathsea version 6.3.0""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2020-08-05T16:14:45Z""
""created"",""2020-08-05T16:14:45Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-08-05T16:14:45Z""
""resourceName"",""1122.pdf""
""Author"",""""
""producer"",""pdfTeX-1.40.19""
""pdf:docinfo:producer"",""pdfTeX-1.40.19""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""3"",""2"",""1"",""8"",""1"",""0"",""0"",""5"",""2"",""1"",""0"",""4"",""4"",""2"",""23"",""42"",""12"",""1"",""6"",""0"",""0"",""0"",""0"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2020-08-05T16:14:45Z""
""Last-Modified"",""2020-08-05T16:14:45Z""
""dcterms:modified"",""2020-08-05T16:14:45Z""
""title"",""""
""Last-Save-Date"",""2020-08-05T16:14:45Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2020-08-05T16:14:45Z""
""meta:save-date"",""2020-08-05T16:14:45Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.19 (TeX Live 2018) kpathsea version 6.3.0""
""Content-Length"",""785024""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""28""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""2521"",""3226"",""3080"",""2963"",""3053"",""1669"",""2642"",""2714"",""3115"",""842"",""2425"",""2530"",""2764"",""1621"",""1408"",""1886"",""2284"",""2234"",""1603"",""2406"",""1078"",""2475"",""1998"",""134"",""1465"",""599"",""3485"",""1757""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-08-05T16:14:45Z""
";https://scholar.google.com/scholar?start=410&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095404-1716;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Signatures with Tight Multi-user Security from Search Assumptions;J Pan, M Ringerud ; European Symposium on Research in Computer …, 2020  Springer;;"… 3. The reduction \(\mathcal {B}\) gets oracle access to \(\textsc {Initialize}_{\mathsf {U}},\textsc

{Sign}_{\mathsf {U}},\) and \(\textsc {Finalize}_{\mathsf {U}}\) and random oracles \(\textsc

{Hash}_1\) and \(\textsc {Hash}_2\) (for hash function \(H_1\) and \(H_2\) in \(\mathsf {OF_{CDH …";Autres articles;;[PDF] ntnu.no;https://ntnuopen.ntnu.no/ntnu-xmlui/bitstream/handle/11250/2726753/main.pdf?sequence=1;;"""date"",""2021-01-14T16:05:21Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""Signatures with Tight Multi-User Security from Search Assumptions ""
""xmp:CreatorTool"",""LaTeX with hyperref""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""Signatures with Tight Multi-User Security from Search Assumptions ""
""modified"",""2021-01-14T16:05:21Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""Jiaxin PanMagnus Ringerud""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.20 (TeX Live 2019) kpathsea version 6.3.1""
""meta:author"",""Jiaxin PanMagnus Ringerud""
""trapped"",""False""
""meta:creation-date"",""2021-01-14T16:05:21Z""
""created"",""2021-01-14T16:05:21Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2021-01-14T16:05:21Z""
""resourceName"",""main.pdf""
""Author"",""Jiaxin PanMagnus Ringerud""
""producer"",""pdfTeX-1.40.20""
""pdf:docinfo:producer"",""pdfTeX-1.40.20""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""2"",""3"",""1"",""38"",""4"",""7"",""4"",""14"",""6"",""33"",""13"",""10"",""27"",""30"",""22"",""5"",""0"",""0"",""2""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""Jiaxin PanMagnus Ringerud""
""dcterms:created"",""2021-01-14T16:05:21Z""
""Last-Modified"",""2021-01-14T16:05:21Z""
""dcterms:modified"",""2021-01-14T16:05:21Z""
""title"",""Signatures with Tight Multi-User Security from Search Assumptions ""
""Last-Save-Date"",""2021-01-14T16:05:21Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2021-01-14T16:05:21Z""
""meta:save-date"",""2021-01-14T16:05:21Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.20 (TeX Live 2019) kpathsea version 6.3.1""
""Content-Length"",""574608""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Jiaxin PanMagnus Ringerud""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""20""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""1845"",""2827"",""2810"",""2673"",""2257"",""2036"",""2763"",""2185"",""1541"",""1632"",""1719"",""1786"",""1931"",""1378"",""1766"",""2111"",""2365"",""2987"",""2815"",""808""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2021-01-14T16:05:21Z""
";https://scholar.google.com/scholar?start=520&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095337-1430;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Blockchain Technology: Applications and Research Challenges;S Bansod, L Ragha ; 2020 International Conference for …, 2020  ieeexplore.ieee.org;;"… Testing of blockchain application is one of the specific challenges. Software testing one of the

components is trusted oracle … Smart contract provides the functionality of trusted oracles which

easily integrate with applications and also verifies validation of these external entities …";Autres articles;;null;;;;https://scholar.google.com/scholar?start=230&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095290-1225;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Issuing and Verifying University Certificates on Blockchain;D Patel, B Rajan, Y Mangnaik, J Jain, V Mistry, P Patel ; ICBCT 2019, 2020  Springer;;"… Oracle allows smart contracts to interact with the outside world using APIs.

Oracalize.it [6] is a service and library for Solidity which provides Oracle services. Oracles

attest for the proof of incoming information from outside a blockchain …";Autres articles;;null;;;;https://scholar.google.com/scholar?start=30&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095399-1702;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Security checklists for Ethereum smart contract development: patterns and best practices;L Marchesi, M Marchesi, L Pompianu… ; arXiv preprint arXiv …, 2020  arxiv.org;;"… November 2017, where the (apparently inci- dental) use of a self-destruct function by a user who

took ownership of the library frozen all Parity multisig wallets and all the cryptocurrency kept in …

An example of pattern specific of the blockchain context is the Oracle pattern, which …";Autres articles;;[PDF] arxiv.org;https://arxiv.org/pdf/2008.04761;;"""date"",""2020-08-12T01:06:39Z""
""pdf:PDFVersion"",""1.4""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.4""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""xmp:CreateDate"",""2020-08-11T21:06:39Z""
""modified"",""2020-08-12T01:06:39Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""xmp:ModifyDate"",""2020-08-11T21:06:39Z""
""pdf:docinfo:creator"",""""
""meta:author"",""""
""meta:creation-date"",""2020-08-12T01:06:39Z""
""created"",""2020-08-12T01:06:39Z""
""xmp:About"",""uuid:a02eafe7-1454-11f6-0000-3a73b44182d6""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-08-12T01:06:39Z""
""resourceName"",""2008.04761""
""Author"",""""
""producer"",""dvips + GPL Ghostscript GIT PRERELEASE 9.22""
""pdf:docinfo:producer"",""dvips + GPL Ghostscript GIT PRERELEASE 9.22""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2020-08-12T01:06:39Z""
""Last-Modified"",""2020-08-12T01:06:39Z""
""dcterms:modified"",""2020-08-12T01:06:39Z""
""title"",""""
""xmpMM:DocumentID"",""uuid:a02eafe7-1454-11f6-0000-3a73b44182d6""
""Last-Save-Date"",""2020-08-12T01:06:39Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2020-08-12T01:06:39Z""
""meta:save-date"",""2020-08-12T01:06:39Z""
""Content-Length"",""191049""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""13""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""4535"",""5493"",""5136"",""5140"",""5155"",""256"",""2495"",""2045"",""2893"",""2012"",""1141"",""1356"",""7141""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-08-12T01:06:39Z""
";https://scholar.google.com/scholar?start=500&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095386-1636;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Blockchain on the Farm: A Systematic Literature Review;J Kasten ; Journal of Strategic Innovation and Sustainability, 2020  search.proquest.com;;"… Page 2. by a discussion and conclusion including the limitations of the study and directions for

additional research. BLOCKCHAIN OVERVIEW Blockchain was introduced as the data-organizing

mechanism built into the Bitcoin system of cryptocurrency (Nakamoto, 2008) …";Autres articles;;null;;;;https://scholar.google.com/scholar?start=440&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095374-1589;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Fog Computing and Blockchain for Massive IoT Deployment;A Baouya, S Chehida, S Bensalem… ; 2020 9th …, 2020  ieeexplore.ieee.org;;"… 94, p. 101933, 2019. [10] P. Kochovski, S. Gec, V. Stankovski, M. Bajec, and PD Drobintsev,

“Trust management in a blockchain based fog computing platform with trustless smart oracles,”

Future Generation Computer Systems, vol. 101, pp. 747 – 759, 2019 …";Cité 1 fois;Les 4 versions;[PDF] meconet.me;http://programme.meconet.me/documents/PAPERS/CPSIoT_2020_paper_21.pdf;;"""date"",""2020-05-05T23:01:32Z""
""pdf:PDFVersion"",""1.6""
""xmp:CreatorTool"",""TeX""
""pdf:docinfo:title"",""CPSIoT_2020_paper_21.pdf""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""language"",""en""
""dc:format"",""application/pdf; version=1.6""
""pdf:docinfo:creator_tool"",""TeX""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""CPSIoT_2020_paper_21.pdf""
""xmp:CreateDate"",""2020-05-06T01:01:32Z""
""modified"",""2020-05-05T23:01:32Z""
""pdf:hasMarkedContent"",""false""
""xmp:ModifyDate"",""2020-05-06T01:01:32Z""
""pdf:docinfo:creator"",""budo""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017/Debian) kpathsea version 6.2.3""
""meta:author"",""budo""
""trapped"",""False""
""meta:creation-date"",""2020-05-05T23:01:32Z""
""created"",""2020-05-05T23:01:32Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-05-05T23:01:32Z""
""resourceName"",""CPSIoT_2020_paper_21.pdf""
""Author"",""budo""
""producer"",""Acrobat Distiller 20.0 (Windows)""
""pdf:docinfo:producer"",""Acrobat Distiller 20.0 (Windows)""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0""
""access_permission:modify_annotations"",""true""
""dc:creator"",""budo""
""dcterms:created"",""2020-05-05T23:01:32Z""
""Last-Modified"",""2020-05-05T23:01:32Z""
""dcterms:modified"",""2020-05-05T23:01:32Z""
""title"",""CPSIoT_2020_paper_21.pdf""
""xmpMM:DocumentID"",""uuid:9e930944-ad2b-4566-8c1c-d21ea617aa88""
""Last-Save-Date"",""2020-05-05T23:01:32Z""
""pdf:docinfo:modified"",""2020-05-05T23:01:32Z""
""meta:save-date"",""2020-05-05T23:01:32Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017/Debian) kpathsea version 6.2.3""
""Content-Length"",""458130""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""budo""
""pdf:producer"",""Acrobat Distiller 20.0 (Windows)""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""4""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""4638"",""3267"",""3034"",""5133""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-05-05T23:01:32Z""
";https://scholar.google.com/scholar?start=390&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095304-1286;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;[HTML][HTML] Blockiotintelligence: A blockchain-enabled intelligent IoT architecture with artificial intelligence;SK Singh, S Rathore, JH Park ; Future Generation Computer Systems, 2020  Elsevier;;"… Share. Export. Advanced. Elsevier. Future Generation Computer Systems. Volume 110, September

2020, Pages 721-743. Future Generation Computer Systems. BlockIoTIntelligence: A

Blockchain-enabled Intelligent IoT Architecture with Artificial Intelligence … 2.1. Blockchain …";Cité 86 fois;Les 2 versions;[HTML] sciencedirect.com;https://www.sciencedirect.com/science/article/pii/S0167739X19316474?casa_token=c9vZSdBxyR4AAAAA:PkxTw9dTEh8-s5ltHnztmRmixnMhEqm_cUaJLD58PLFRItoCwseaBw04RRzFKy5TZkd1iPm7;;;https://scholar.google.com/scholar?start=90&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095381-1619;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Blockchain;T Gayvoronskaya, C Meinel, M Schnjakin ; Springer;;"… 18 (Figs. 2.1 and 2.2). The cryptocurrency wallets analyze the blockchain and then,

to give the user a better overview, display the user's incoming and outgoing

transactions and current supply of money. The Bitcoin currency …";Autres articles;;null;;;;https://scholar.google.com/scholar?start=420&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095362-1534;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;[CITATION][C] Prospects of blockchain in contract and property;B Arruńada ; European Property Law Journal, 2020  De Gruyter;;null;Cité 1 fois;Les 13 versions;[PDF] upf.edu;https://repositori.upf.edu/bitstream/handle/10230/44761/1696.pdf?sequence=1&isAllowed=y;;"""date"",""2020-02-20T11:03:37Z""
""pdf:PDFVersion"",""1.6""
""xmp:CreatorTool"",""PScript5.dll Version 5.2.2""
""pdf:docinfo:title"",""Microsoft Word - ARRUÑADA 2019 Blockchain in Contract & Property Dec 27""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""language"",""en""
""dc:format"",""application/pdf; version=1.6""
""pdf:docinfo:creator_tool"",""PScript5.dll Version 5.2.2""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""Microsoft Word - ARRUÑADA 2019 Blockchain in Contract & Property Dec 27""
""xmp:CreateDate"",""2020-01-03T18:54:24Z""
""modified"",""2020-02-20T11:03:37Z""
""pdf:hasMarkedContent"",""true""
""xmp:ModifyDate"",""2020-02-20T12:03:37Z""
""pdf:docinfo:creator"",""Benito ArruĂąada""
""meta:author"",""Benito ArruĂąada""
""meta:creation-date"",""2020-01-03T17:54:24Z""
""created"",""2020-01-03T17:54:24Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-01-03T17:54:24Z""
""resourceName"",""1696.pdf""
""Author"",""Benito ArruĂąada""
""producer"",""Acrobat Distiller 11.0 (Windows)""
""pdf:docinfo:producer"",""Acrobat Distiller 11.0 (Windows)""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""access_permission:modify_annotations"",""true""
""dc:creator"",""Benito ArruĂąada""
""dcterms:created"",""2020-01-03T17:54:24Z""
""Last-Modified"",""2020-02-20T11:03:37Z""
""dcterms:modified"",""2020-02-20T11:03:37Z""
""title"",""Microsoft Word - ARRUÑADA 2019 Blockchain in Contract & Property Dec 27""
""xmpMM:DocumentID"",""uuid:29ad32a8-e6c3-471b-a32c-c39b6983d256""
""Last-Save-Date"",""2020-02-20T11:03:37Z""
""pdf:docinfo:modified"",""2020-02-20T11:03:37Z""
""meta:save-date"",""2020-02-20T11:03:37Z""
""Content-Length"",""201705""
""Content-Type"",""application/pdf""
""xmp:MetadataDate"",""2020-02-20T12:03:37Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Benito ArruĂąada""
""pdf:producer"",""Acrobat Distiller 11.0 (Windows)""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""28""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""153"",""1774"",""3244"",""4003"",""3371"",""3790"",""3321"",""3791"",""2984"",""3709"",""3322"",""4008"",""3842"",""3082"",""3584"",""3663"",""3815"",""3440"",""3543"",""3705"",""3201"",""2444"",""2849"",""2629"",""2603"",""2549"",""1306"",""799""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-01-03T17:54:24Z""
";https://scholar.google.com/scholar?start=340&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095358-1518;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;[PDF][PDF] A Subscription Service for Automated Communication and Fair Cost Distribution in Collaborative Blockchain-based Business Processes;M Schindelmann, P Klinger, F Bodendorf ; library.gito.de;;"… Apart from related work in the context of process execution, the Subscription Service can also

be associated with oracle services. The common purpose of oracles is to bring off-chain data

onto the Blockchain to enable processing of real-world information [25] …";Autres articles;Version HTML;[PDF] gito.de;https://library.gito.de/open-access-pdf/R13Schindelmann-A_Subscription_Service_for_Automated_Communication_and_Fair_Cost_Distribution-506_c.pdf;;"""date"",""2020-03-03T18:37:39Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.4""
""xmp:CreatorTool"",""Online2PDF.com""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dcterms:created"",""2020-02-18T15:03:38Z""
""language"",""en""
""Last-Modified"",""2020-03-03T18:37:39Z""
""dcterms:modified"",""2020-03-03T18:37:39Z""
""dc:format"",""application/pdf; version=1.4""
""xmpMM:DocumentID"",""uuid:f98572c9-de35-ba46-84f5-041a31321de3""
""Last-Save-Date"",""2020-03-03T18:37:39Z""
""pdf:docinfo:creator_tool"",""Online2PDF.com""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2020-03-03T18:37:39Z""
""meta:save-date"",""2020-03-03T18:37:39Z""
""pdf:encrypted"",""false""
""xmp:CreateDate"",""2020-02-18T15:03:38Z""
""modified"",""2020-03-03T18:37:39Z""
""Content-Length"",""1076354""
""pdf:hasMarkedContent"",""false""
""Content-Type"",""application/pdf""
""xmp:ModifyDate"",""2020-03-03T19:37:39Z""
""xmp:MetadataDate"",""2020-03-03T19:37:39Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""pdf:producer"",""Online2PDF.com""
""meta:creation-date"",""2020-02-18T15:03:38Z""
""created"",""2020-02-18T15:03:38Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""13""
""Creation-Date"",""2020-02-18T15:03:38Z""
""resourceName"",""R13Schindelmann-A_Subscription_Service_for_Automated_Communication_and_Fair_Cost_Distribution-506_c.pdf""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""2657"",""3272"",""3192"",""2308"",""2516"",""2392"",""1796"",""3043"",""2021"",""1753"",""3122"",""3180"",""2787""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""producer"",""Online2PDF.com""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""Online2PDF.com""
""pdf:docinfo:created"",""2020-02-18T15:03:38Z""
";https://scholar.google.com/scholar?start=320&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095360-1530;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;[PDF][PDF] Decentralized APIs for Web 3.0;B Benligiray, S Milic, H Vänttinen ; static.coinpaprika.com;;"… Barriers to API providers operating oracles … two years, we communicated with API providers

extensively and observed the following barriers to oracle onboarding and … 1. Traditional API

providers are typically not more familiar with blockchain tech- nologies than the general public …";Autres articles;;[PDF] coinpaprika.com;https://static.coinpaprika.com/storage/cdn/whitepapers/10618239.pdf;;"""date"",""2020-09-28T13:51:12Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2020-09-28T13:51:12Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017/Debian) kpathsea version 6.2.3""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2020-09-28T13:51:12Z""
""created"",""2020-09-28T13:51:12Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-09-28T13:51:12Z""
""resourceName"",""10618239.pdf""
""Author"",""""
""producer"",""pdfTeX-1.40.18""
""pdf:docinfo:producer"",""pdfTeX-1.40.18""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2020-09-28T13:51:12Z""
""Last-Modified"",""2020-09-28T13:51:12Z""
""dcterms:modified"",""2020-09-28T13:51:12Z""
""title"",""""
""Last-Save-Date"",""2020-09-28T13:51:12Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2020-09-28T13:51:12Z""
""meta:save-date"",""2020-09-28T13:51:12Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017/Debian) kpathsea version 6.2.3""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""40""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""1242"",""959"",""639"",""2244"",""1312"",""2323"",""2457"",""2099"",""1699"",""2052"",""1506"",""1238"",""2354"",""2203"",""2105"",""1394"",""2218"",""2360"",""2369"",""2299"",""2302"",""2264"",""1284"",""1272"",""2154"",""1937"",""1097"",""2424"",""1647"",""1938"",""2081"",""2503"",""2081"",""1032"",""2363"",""2151"",""1906"",""2256"",""1710"",""1652""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-09-28T13:51:12Z""
";https://scholar.google.com/scholar?start=330&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095309-1311;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;[HTML][HTML] Blockchain platforms in supply chains;M Vivaldini ; Journal of Enterprise Information Management, 2020  emerald.com;United Kingdom;Blockchain platforms in supply chains - Author: Mauro Vivaldini.;Cité 2 fois;Les 2 versions;[HTML] emerald.com;https://www.emerald.com/insight/content/doi/10.1108/JEIM-12-2019-0416/full/html?casa_token=C3PgNNnHQc8AAAAA:uY2jmj2vz_PUc7bFUNX37zWmjfLhOIIvwH_NtgkYYjkyWRdgqSp5FVmFLRd4LrzlPnLjE36hyBgpOYkuKHj_0n3weI-Is48IshpfapgR8UtNfxc6yQ;;"""keywords"",""Supply chains,Blockchain platforms,Technology,Logistics,Software developers""
""dc.Title"",""Blockchain platforms in supply chains""
""citation_journal_title"",""Journal of Enterprise Information Management""
""description"",""Blockchain platforms in supply chains - Author: Mauro Vivaldini""
""language"",""en""
""title"",""Blockchain platforms in supply chains
 |  Emerald Insight""
""dc.Identifier"",""10.1108/JEIM-12-2019-0416"",""1741-0398""
""dc.Publisher"",""Emerald Publishing Limited""
""dc.Format"",""text/html""
""dc:title"",""Blockchain platforms in supply chains
 |  Emerald Insight""
""csrf-token"",""Tfw0pvTCpZO4ldlbizuJIRnJEWHA5jBikaSsBbWP""
""Content-Encoding"",""UTF-8""
""dc.Date"",""2020-12-02Z""
""Content-Length"",""67371""
""citation_xml_url"",""https://www.emerald.com/insight/content/doi/10.1108/JEIM-12-2019-0416/full/xml""
""dc.Subject"",""Supply chains,Blockchain platforms,Technology,Logistics,Software developers""
""Content-Type"",""text/html; charset=UTF-8""
""dc.Contributor"",""Mauro Vivaldini""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""dc.Type"",""earlycite article""
""resourceName"",""html""
""X-UA-Compatible"",""IE=edge""
""dc.Language"",""en""
""viewport"",""width=device-width, initial-scale=1""
""DCTERMS.bibliographicCitation"",""&ctx_ver=Z39.88-2004&rft.spage=&rft.epage=&rft.volume=ahead-of-print&rft.issue=ahead-of-print""
""dc.Coverage"",""world""
""Content-Language"",""en""
""format-detection"",""telephone=no""
";https://scholar.google.com/scholar?start=110&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095392-1670;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;[PDF][PDF] The Yield Protocol: On-Chain Lending With Interest Rate Discovery;D Robinson, A Niemerg ; URl: https://yield. is/Yield. pdf, 2020  yield.is;;"… setprotocol.com/pdf/set_protocol_whitepaper.pdf. [15] UMA Data Verification Mechanism: Adding

Economic Guarantees to Blockchain Oracles. July 2019. URl: https://github.com/UMAprotocol/

whitepaper/ blob/master/UMA-DVM-oracle-whitepaper.pdf. [16] Summa …";Cité 1 fois;;[PDF] yield.is;https://yield.is/Yield.pdf;;"""date"",""2020-10-10T19:16:56Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2020-10-10T19:16:56Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.21 (TeX Live 2020) kpathsea version 6.3.2""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2020-10-10T19:16:56Z""
""created"",""2020-10-10T19:16:56Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-10-10T19:16:56Z""
""resourceName"",""Yield.pdf""
""Author"",""""
""producer"",""pdfTeX-1.40.21""
""pdf:docinfo:producer"",""pdfTeX-1.40.21""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2020-10-10T19:16:56Z""
""Last-Modified"",""2020-10-10T19:16:56Z""
""dcterms:modified"",""2020-10-10T19:16:56Z""
""title"",""""
""Last-Save-Date"",""2020-10-10T19:16:56Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2020-10-10T19:16:56Z""
""meta:save-date"",""2020-10-10T19:16:56Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.21 (TeX Live 2020) kpathsea version 6.3.2""
""Content-Length"",""283923""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""15""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""1621"",""2624"",""2297"",""2360"",""2544"",""2299"",""2292"",""2476"",""2252"",""1197"",""2269"",""2096"",""2088"",""1794"",""1249""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-10-10T19:16:56Z""
";https://scholar.google.com/scholar?start=470&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095288-1216;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Time in Blockchain-Based Process Execution;J Ladleif, M Weske ; 2020 IEEE 24th International Enterprise …, 2020  ieeexplore.ieee.org;;"… in practice is OrFeed1, which provides cryptocurrency exchange rates on Ethereum using a similar

mechanism. Alternatively, data may be asynchronously requested from within the blockchain

using request-response oracles (see Fig. 2b). Here, the oracle provider operates a …";Cité 2 fois;Les 5 versions;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/9233042/9233113/09233183.pdf?casa_token=CN9OjVHQ0swAAAAA:IT2pQ-kkvpcxnVdM9SzCdHYyNxP7pA7VRt3RXwmvt03okvdhW-gz3zDj7f1rc7XZdWkTcFHTa5U;;"""og:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""twitter:title"",""Time in Blockchain-Based Process Execution""
""twitter:card"",""summary""
""Description"",""The traceable execution of business processes and choreographies using smart contracts is one prominent application of blockchain technology in Business Process""
""og:title"",""Time in Blockchain-Based Process Execution""
""resourceName"",""09233183.pdf""
""language"",""en""
""title"",""Time in Blockchain-Based Process Execution | IEEE Conference Publication | IEEE Xplore""
""og:description"",""The traceable execution of business processes and choreographies using smart contracts is one prominent application of blockchain technology in Business Process Management (BPM). Existing approaches support a large set of patterns, modeling languages, and blockchain architectures, which cover a wide range of practical scenarios. However, they largely neglect the important aspect of time, a crucial part of process and choreography models manifested in deadlines, delays, and other temporal constraints. We argue that this deficit is due to inherent limitations of smart contracts-in particular the absence of a natural notion of measuring time-on popular blockchain platforms used in research and practice. We introduce a set of time measures available on blockchain platforms to alleviate these issues, and systematically compare their properties. We also give hints as to their suitability for facilitating various temporal constraints commonly found in process models.""
""twitter:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-UA-Compatible"",""IE=Edge""
""viewport"",""width=device-width, initial-scale=1.0""
""dc:title"",""Time in Blockchain-Based Process Execution | IEEE Conference Publication | IEEE Xplore""
""twitter:description"",""The traceable execution of business processes and choreographies using smart contracts is one prominent application of blockchain technology in Business Process Management (BPM). Existing approaches support a large set of patterns, modeling languages, and blockchain architectures, which cover a wide range of practical scenarios. However, they largely neglect the important aspect of time, a crucial part of process and choreography models manifested in deadlines, delays, and other temporal constraints. We argue that this deficit is due to inherent limitations of smart contracts-in particular the absence of a natural notion of measuring time-on popular blockchain platforms used in research and practice. We introduce a set of time measures available on blockchain platforms to alleviate these issues, and systematically compare their properties. We also give hints as to their suitability for facilitating various temporal constraints commonly found in process models.""
""Content-Encoding"",""UTF-8""
""Content-Type-Hint"",""text/html; charset=utf-8""
""Content-Length"",""40342""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=20&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095346-1467;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Legally binding anonymous multiparty commitments on a blockchain;DR Chawdhuri ; 2020 Crypto Valley Conference on Blockchain …, 2020  ieeexplore.ieee.org;;"… 43 2020 Crypto Valley Conference on Blockchain Technology (CVCBT … We propose a blockchain

smart contract … unforgeability: Existential unforgeability guarantees that an adversary cannot

produce a signature without a private key when provided with a signing oracle, with the …";Autres articles;;[PDF] academia.edu;https://www.academia.edu/download/64499110/Legally%20Binding%20Anonymous%20Multiparty%20Commitments%20on%20a%20Blockchain.pdf;;;https://scholar.google.com/scholar?start=270&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095306-1299;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Designing blockchain-based access control protocol in iot-enabled smart-grid system;B Bera, S Saha, AK Das, AV Vasilakos ; IEEE Internet of Things …, 2020  divaportal.org;;"… In our work, the blockchain is considered as private because the data collected from the

consumers of the smart meters are private and confidential. By the formal security analysis under

the random oracle model, non-mathematical security analysis and software-based formal …";Cité 7 fois;Les 2 versions;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/6488907/6702522/09222155.pdf?casa_token=vJvEVe_s-xIAAAAA:oaS-M0CrPm4e-xArTYJnCRIU4ZKHJ2k-74P-7XZ1wxN0SK9Fhy2tLFPIKnDmld6q2UvCRIDMpBM;;"""og:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""twitter:title"",""Designing Blockchain-Based Access Control Protocol in IoT-Enabled Smart-Grid System""
""twitter:card"",""summary""
""Description"",""We design a new blockchain-based access control protocol in IoT-enabled smart-grid system, called DBACP-IoTSG. Through the proposed DBACP-IoTSG, the data is sec""
""og:title"",""Designing Blockchain-Based Access Control Protocol in IoT-Enabled Smart-Grid System""
""resourceName"",""09222155.pdf""
""language"",""en""
""title"",""Designing Blockchain-Based Access Control Protocol in IoT-Enabled Smart-Grid System | IEEE Journals & Magazine | IEEE Xplore""
""og:description"",""We design a new blockchain-based access control protocol in IoT-enabled smart-grid system, called DBACP-IoTSG. Through the proposed DBACP-IoTSG, the data is securely brought to the service providers from their respective smart meters (SMs). The peer-to-peer (P2P) network is formed by the participating service providers, where the peer nodes are responsible for creating the blocks from the gathered data securely from their corresponding SMs and adding them into the blockchain after validation of the blocks using the voting-based consensus algorithm. In our work, the blockchain is considered as private because the data collected from the consumers of the SMs are private and confidential. By the formal security analysis under the random oracle model, nonmathematical security analysis and software-based formal security verification, DBACP-IoTSG is shown to be resistant against various attacks. We carry out the experimental results of various cryptographic primitives that are needed for comparative analysis using the widely used multiprecision integer and rational arithmetic cryptographic library (MIRACL). A detailed comparative study reveals that DBACP-IoTSG supports more functionality features and provides better security apart from its low communication and computation costs as compared to recently proposed relevant schemes. In addition, the blockchain implementation of DBACP-IoTSG has been performed to measure computational time needed for the varied number of blocks addition and also the varied number of transactions per block in the blockchain.""
""twitter:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-UA-Compatible"",""IE=Edge""
""viewport"",""width=device-width, initial-scale=1.0""
""dc:title"",""Designing Blockchain-Based Access Control Protocol in IoT-Enabled Smart-Grid System | IEEE Journals & Magazine | IEEE Xplore""
""twitter:description"",""We design a new blockchain-based access control protocol in IoT-enabled smart-grid system, called DBACP-IoTSG. Through the proposed DBACP-IoTSG, the data is securely brought to the service providers from their respective smart meters (SMs). The peer-to-peer (P2P) network is formed by the participating service providers, where the peer nodes are responsible for creating the blocks from the gathered data securely from their corresponding SMs and adding them into the blockchain after validation of the blocks using the voting-based consensus algorithm. In our work, the blockchain is considered as private because the data collected from the consumers of the SMs are private and confidential. By the formal security analysis under the random oracle model, nonmathematical security analysis and software-based formal security verification, DBACP-IoTSG is shown to be resistant against various attacks. We carry out the experimental results of various cryptographic primitives that are needed for comparative analysis using the widely used multiprecision integer and rational arithmetic cryptographic library (MIRACL). A detailed comparative study reveals that DBACP-IoTSG supports more functionality features and provides better security apart from its low communication and computation costs as compared to recently proposed relevant schemes. In addition, the blockchain implementation of DBACP-IoTSG has been performed to measure computational time needed for the varied number of blocks addition and also the varied number of transactions per block in the blockchain.""
""Content-Encoding"",""UTF-8""
""Content-Type-Hint"",""text/html; charset=utf-8""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=100&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095337-1424;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Fake news, disinformation, and deepfakes: Leveraging distributed ledger technologies and blockchain to combat digital deception and counterfeit reality;P Fraga;Lamas, TM FernándezCaramés  IT Professional, 2020  ieeexplore.ieee.org;;"… Figure 1), together with the use of smart contracts enabled by oracles, can play … can perform secure

P2P transactions without third-party intermediaries through crypto- graphically signed … gov- ernance

by encoding operational and managerial rules on a blockchain through smart …";Cité 12 fois;Les 5 versions;[PDF] arxiv.org;https://arxiv.org/pdf/1904.05386;;"""date"",""2019-10-22T00:35:07Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2019-10-22T00:35:07Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016) kpathsea version 6.2.2""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2019-10-22T00:35:07Z""
""created"",""2019-10-22T00:35:07Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-10-22T00:35:07Z""
""resourceName"",""1904.05386""
""Author"",""""
""producer"",""pdfTeX-1.40.17""
""pdf:docinfo:producer"",""pdfTeX-1.40.17""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2019-10-22T00:35:07Z""
""Last-Modified"",""2019-10-22T00:35:07Z""
""dcterms:modified"",""2019-10-22T00:35:07Z""
""title"",""""
""Last-Save-Date"",""2019-10-22T00:35:07Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2019-10-22T00:35:07Z""
""meta:save-date"",""2019-10-22T00:35:07Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016) kpathsea version 6.2.2""
""Content-Length"",""657769""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""5""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""4432"",""4443"",""4618"",""5359"",""5222""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-10-22T00:35:07Z""
";https://scholar.google.com/scholar?start=230&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095392-1671;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Health Management for Next-gen Blockchain: Smart Construction, Dynamic Evolution and Stochastic Transformation;L Kuan, D Chenglie, L Zhenguo… ; … , Information System and …, 2020  ieeexplore.ieee.org;;"… scalability and economy, contributing new ledger structures, consensus algorithms, off-chain

expansions, incentive mecha- nisms, smart contract platform, or oracles … C. Parallel Blockchain

Yuan and Wang proposed concept, methods and tech- niques of Parallel BlocNchain …";Autres articles;;null;;;;https://scholar.google.com/scholar?start=470&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095402-1706;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;[LIVRE][B] ???????, ???????? ? ??? ?????????? ?? ?????????????;? ???????????? ;2020 books.google.com;;"… ? ??????? 2017 ???? Oracle ???????????? ?????? ?????? ????????????? Oracle Blockchain

Cloud Service, ???????????? ???????? ????????? ?????????? ???????????? ??????????

(???????? ????????? ??????, ???????????? ??? ?????????? ????????? …";Cité 12 fois;;null;;;;https://scholar.google.com/scholar?start=510&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095376-1603;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Blockchain Functionality: How Smart Contracts Can Save Small Farms;J Frank ; Available at SSRN 3662648, 2020  papers.ssrn.com;;"… Inventions?, COINTELEGRAPH (July 14, 2018), https://cointelegraph.com/news/crypto-and-

blockchain … LISK, https://lisk.io/academy/blockchain-basics/how-does-blockchain-work/digital … 20

Arvind Narayanan et al., Bitcoin and Cryptocurrency Technologies: A Comprehensive …";Autres articles;;null;;;;https://scholar.google.com/scholar?start=400&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095325-1383;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Arithmetization for Probabilistically Checkable and Interactive Oracle Proofs;Y Horesh, E Ben;Sasson, Y Ishai 2020 cs.technion.ac.il;;"… 32 4.3 Prover running time and total size of all oracles generated by its … output to that reported

by P, as a customer might inspect a restaurant bill, or as a new Bitcoin node will verify its

blockchain [Nak09 … 2) Common access to a random function6 (the “random oracle model” [FS86 …";;;[PDF] technion.ac.il;http://www.cs.technion.ac.il/users/wwwb/cgi-bin/tr-get.cgi/2020/MSC/MSC-2020-19.pdf;;"""date"",""2020-05-28T11:49:35Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""15"",""16"",""0"",""0"",""0"",""0"",""0"",""2"",""16"",""10"",""1"",""6"",""1"",""3"",""0"",""0"",""7"",""4"",""1"",""1"",""0"",""0"",""1"",""5"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.5""
""xmp:CreatorTool"",""TeX""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dcterms:created"",""2020-05-28T11:49:35Z""
""language"",""en""
""Last-Modified"",""2020-05-28T11:49:35Z""
""dcterms:modified"",""2020-05-28T11:49:35Z""
""dc:format"",""application/pdf; version=1.5""
""Last-Save-Date"",""2020-05-28T11:49:35Z""
""pdf:docinfo:creator_tool"",""TeX""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2020-05-28T11:49:35Z""
""meta:save-date"",""2020-05-28T11:49:35Z""
""pdf:encrypted"",""false""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017) kpathsea version 6.2.3""
""modified"",""2020-05-28T11:49:35Z""
""Content-Length"",""635119""
""pdf:hasMarkedContent"",""false""
""Content-Type"",""application/pdf""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017) kpathsea version 6.2.3""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""trapped"",""False""
""meta:creation-date"",""2020-05-28T11:49:35Z""
""created"",""2020-05-28T11:49:35Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""62""
""Creation-Date"",""2020-05-28T11:49:35Z""
""resourceName"",""MSC-2020-19.pdf""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""154"",""73"",""342"",""73"",""1650"",""73"",""1555"",""301"",""1368"",""73"",""2148"",""74"",""2322"",""3468"",""3171"",""947"",""2057"",""2836"",""2720"",""2639"",""2428"",""75"",""1872"",""2886"",""1951"",""2602"",""2313"",""2357"",""2083"",""2612"",""1714"",""853"",""880"",""1514"",""1513"",""573"",""457"",""75"",""1668"",""2314"",""2321"",""1227"",""2403"",""2485"",""1983"",""75"",""1833"",""2377"",""2291"",""2077"",""1351"",""73"",""1027"",""2378"",""1919"",""79"",""73"",""1306"",""73"",""270"",""73"",""151""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""producer"",""pdfTeX-1.40.18""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""pdfTeX-1.40.18""
""pdf:docinfo:created"",""2020-05-28T11:49:35Z""
";https://scholar.google.com/scholar?start=180&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095409-1740;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Projekte und Einsatzbereiche der Blockchain-Technologie;C Meinel, T Gayvoronskaya ; Blockchain, 2020  Springer;;"… Ein dezentrales Teilnehmernetzwerk, Smart Contracts sowie Oracles können viele

Zwischenhändler ablösen … IBM und Maersk 31 präsentierten am 9. August 2018 ihre

Blockchain-basierte 32 Lösung für die Schifffahrts- und Logistikindustrie …";Autres articles;;null;;;;https://scholar.google.com/scholar?start=540&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095365-1548;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Blockchain's Function in Protecting Copyright;A Eslamitabar, M Naser ; Private Law Research, 2020  jplr.atu.ac.ir;;"… https://cointelegraph.com/explained/blockchain-oracles-explained(Updated 2017). - JP Barlow,

A Declaration of the Independence of … UJOMusic, a blockchain platform has … a few music albums,

Including Imogen Heap's Tiny Human for sale for the Ethereum cryptocurrency …";Autres articles;En cache;null;;;;https://scholar.google.com/scholar?start=350&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095355-1508;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Blockchain for Multi-Robot Collaboration to Combat COVID-19 and Future Pandemics;SH Alsamhi, B Lee ; arXiv preprint arXiv:2010.02137, 2020  arxiv.org;;"… RobotChain [54] a decentralized ledger for recording robot events; the smart contract was

managing multi-robot with processing data by Oracle. The advantages of blockchain for managing

a multi-robot system should fulfill decentralization, scalability, consensus, trust …";Cité 5 fois;Les 3 versions;[PDF] arxiv.org;https://arxiv.org/pdf/2010.02137;;"""date"",""2020-10-05T16:24:29Z""
""pdf:PDFVersion"",""1.7""
""xmp:CreatorTool"",""MicrosoftÂŽ Word 2019""
""pdf:docinfo:title"",""Date of publication xxxx 00, 0000, date of current version xxxx 00, 0000""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""language"",""en""
""dc:format"",""application/pdf; version=1.7""
""pdf:docinfo:creator_tool"",""MicrosoftÂŽ Word 2019""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""Date of publication xxxx 00, 0000, date of current version xxxx 00, 0000""
""xmp:CreateDate"",""2020-09-25T15:12:59Z""
""modified"",""2020-10-05T16:24:29Z""
""pdf:hasMarkedContent"",""true""
""xmp:ModifyDate"",""2020-10-05T09:24:29Z""
""pdf:docinfo:creator"",""lds2""
""meta:author"",""lds2""
""meta:creation-date"",""2020-09-25T22:12:59Z""
""created"",""2020-09-25T22:12:59Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-09-25T22:12:59Z""
""resourceName"",""2010.02137""
""Author"",""lds2""
""producer"",""MicrosoftÂŽ Word 2019""
""pdf:docinfo:producer"",""MicrosoftÂŽ Word 2019""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""access_permission:modify_annotations"",""true""
""dc:creator"",""lds2""
""dcterms:created"",""2020-09-25T22:12:59Z""
""Last-Modified"",""2020-10-05T16:24:29Z""
""dcterms:modified"",""2020-10-05T16:24:29Z""
""title"",""Date of publication xxxx 00, 0000, date of current version xxxx 00, 0000""
""xmpMM:DocumentID"",""uuid:8EB9E9DE-5608-4DAD-878D-893F335B3611""
""Last-Save-Date"",""2020-10-05T16:24:29Z""
""pdf:docinfo:modified"",""2020-10-05T16:24:29Z""
""meta:save-date"",""2020-10-05T16:24:29Z""
""Content-Length"",""1631388""
""Content-Type"",""application/pdf""
""xmp:MetadataDate"",""2020-10-05T09:24:29Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""lds2""
""dc:language"",""en-US""
""pdf:producer"",""MicrosoftÂŽ Word 2019""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""25""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""4369"",""6192"",""4903"",""5689"",""6252"",""4038"",""6260"",""2777"",""4180"",""5254"",""2851"",""3649"",""2909"",""6157"",""2308"",""5205"",""2105"",""3029"",""2552"",""3336"",""2862"",""6607"",""7824"",""7776"",""371""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-09-25T22:12:59Z""
";https://scholar.google.com/scholar?start=310&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095299-1273;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;An efficient NIZK scheme for privacy-preserving transactions over account-model blockchain;S Ma, Y Deng, D He, J Zhang… ; IEEE Transactions on …, 2020  ieeexplore.ieee.org;;"… on hiding the transaction accounts via several cryptographic techniques (eg, crypto- graphic

commitment … that our proposed scheme is provably secure under the random oracle model …

cryptograph- ic techniques around the privacy protection in the blockchain, however which …";Cité 24 fois;Les 4 versions;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/8858/4358699/08968397.pdf?casa_token=OSiJQN77Jz8AAAAA:O4rXC7B6lwj2nzG7CoVZdkqyLum0tRSBiQFdlKbog5y0PEbi-7qYWmxmvBXM5oic-A-2XKXcDzc;;"""og:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""twitter:title"",""An Efficient NIZK Scheme for Privacy-Preserving Transactions Over Account-Model Blockchain""
""twitter:card"",""summary""
""Description"",""We introduce the abstract framework of decentralized smart contracts system with balance and transaction amount hiding property over account-model blockchain. T""
""og:title"",""An Efficient NIZK Scheme for Privacy-Preserving Transactions Over Account-Model Blockchain""
""resourceName"",""08968397.pdf""
""language"",""en""
""title"",""An Efficient NIZK Scheme for Privacy-Preserving Transactions Over Account-Model Blockchain | IEEE Journals & Magazine | IEEE Xplore""
""og:description"",""We introduce the abstract framework of decentralized smart contracts system with balance and transaction amount hiding property over account-model blockchain. To build a concrete system with such properties, we utilize a homomorphic public-key encryption scheme and construct a highly efficient non-interactive zero knowledge (NIZK) argument based upon the encryption scheme to ensure the validity of the transactions. Our NIZK scheme is perfect zero knowledge in the common reference string model, while its soundness holds in the random oracle model. Compared to previous similar constructions, our proposed NIZK argument dramatically improves the time efficiency in generating a proof, at the cost of relatively longer proof size.""
""twitter:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-UA-Compatible"",""IE=Edge""
""viewport"",""width=device-width, initial-scale=1.0""
""dc:title"",""An Efficient NIZK Scheme for Privacy-Preserving Transactions Over Account-Model Blockchain | IEEE Journals & Magazine | IEEE Xplore""
""twitter:description"",""We introduce the abstract framework of decentralized smart contracts system with balance and transaction amount hiding property over account-model blockchain. To build a concrete system with such properties, we utilize a homomorphic public-key encryption scheme and construct a highly efficient non-interactive zero knowledge (NIZK) argument based upon the encryption scheme to ensure the validity of the transactions. Our NIZK scheme is perfect zero knowledge in the common reference string model, while its soundness holds in the random oracle model. Compared to previous similar constructions, our proposed NIZK argument dramatically improves the time efficiency in generating a proof, at the cost of relatively longer proof size.""
""Content-Encoding"",""UTF-8""
""Content-Type-Hint"",""text/html; charset=utf-8""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=70&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095344-1456;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Smart Donations: Event-Driven Conditional Donations Using Smart Contracts On The Blockchain;L Trotter, M Harding, P Shaw, N Davies, C Elsden… ;2020 eprints.lancs.ac.uk;;"… off-chain scheduling module that regularly pushes the current date and time to the blockchain …

escrows are only able to store digital assets like cryptocurrencies or crypto tokens … However,

volatility in the cryptocurrency market presents a significant obstacle for NGOs in adopting …";Autres articles;;[PDF] lancs.ac.uk;https://eprints.lancs.ac.uk/id/eprint/149961/1/OZCHI_reformatting_9_.pdf;;"""date"",""2020-10-30T12:29:10Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""Smart Donations: Event-Driven Conditional Donations Using Smart Contracts On The Blockchain""
""xmp:CreatorTool"",""LaTeX with acmart 2020/04/30 v1.71 Typesetting articles for the Association for Computing Machinery and hyperref 2019/11/10 v7.00c Hypertext links for LaTeX""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""-  Social and professional topics  ->  Socio-technical systems.-  Human-centered computing  ->  Mobile computing.-  Information systems  ->  Collaborative and social computing systems and tools.""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with acmart 2020/04/30 v1.71 Typesetting articles for the Association for Computing Machinery and hyperref 2019/11/10 v7.00c Hypertext links for LaTeX""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""Smart Donations: Event-Driven Conditional Donations Using Smart Contracts On The Blockchain""
""modified"",""2020-10-30T12:29:10Z""
""cp:subject"",""-  Social and professional topics  ->  Socio-technical systems.-  Human-centered computing  ->  Mobile computing.-  Information systems  ->  Collaborative and social computing systems and tools.""
""pdf:docinfo:subject"",""-  Social and professional topics  ->  Socio-technical systems.-  Human-centered computing  ->  Mobile computing.-  Information systems  ->  Collaborative and social computing systems and tools.""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""Ludwig Trotter, Mike Harding, Peter Shaw, Nigel Davies, Chris Elsden, Chris Speed, John Vines, Aydin Abadi, and Josh Hallwright""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.20 (TeX Live 2019) kpathsea version 6.3.1""
""meta:author"",""Ludwig Trotter, Mike Harding, Peter Shaw, Nigel Davies, Chris Elsden, Chris Speed, John Vines, Aydin Abadi, and Josh Hallwright""
""trapped"",""False""
""meta:creation-date"",""2020-10-30T12:29:10Z""
""created"",""2020-10-30T12:29:10Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-10-30T12:29:10Z""
""resourceName"",""OZCHI_reformatting_9_.pdf""
""Author"",""Ludwig Trotter, Mike Harding, Peter Shaw, Nigel Davies, Chris Elsden, Chris Speed, John Vines, Aydin Abadi, and Josh Hallwright""
""producer"",""pdfTeX-1.40.20""
""pdf:docinfo:producer"",""pdfTeX-1.40.20""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""Keywords"",""Blockchain, charitable giving, even-driven computing, conditionality""
""access_permission:modify_annotations"",""true""
""dc:creator"",""Ludwig Trotter, Mike Harding, Peter Shaw, Nigel Davies, Chris Elsden, Chris Speed, John Vines, Aydin Abadi, and Josh Hallwright""
""dcterms:created"",""2020-10-30T12:29:10Z""
""Last-Modified"",""2020-10-30T12:29:10Z""
""dcterms:modified"",""2020-10-30T12:29:10Z""
""title"",""Smart Donations: Event-Driven Conditional Donations Using Smart Contracts On The Blockchain""
""Last-Save-Date"",""2020-10-30T12:29:10Z""
""pdf:docinfo:keywords"",""Blockchain, charitable giving, even-driven computing, conditionality""
""pdf:docinfo:modified"",""2020-10-30T12:29:10Z""
""meta:save-date"",""2020-10-30T12:29:10Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.20 (TeX Live 2019) kpathsea version 6.3.1""
""Content-Length"",""927827""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Ludwig Trotter, Mike Harding, Peter Shaw, Nigel Davies, Chris Elsden, Chris Speed, John Vines, Aydin Abadi, and Josh Hallwright""
""dc:language"",""en""
""dc:subject"",""Blockchain, charitable giving, even-driven computing, conditionality""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""19""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""3296"",""3626"",""3974"",""3623"",""3496"",""3606"",""3933"",""3712"",""3514"",""2305"",""3599"",""1832"",""3694"",""3364"",""3573"",""3704"",""3697"",""5101"",""3198""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""Blockchain, charitable giving, even-driven computing, conditionality""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-10-30T12:29:10Z""
";https://scholar.google.com/scholar?start=260&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095290-1232;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;[HTML][HTML] Understanding manager resistance to blockchain systems;C Walsh, P O'Reilly, R Gleasure, J McAvoy… ; European Management …, 2020  Elsevier;;"… 2016). Over time, blockchain has slowly moved away from its origins as being based

in cryptocurrency, to one where it is used in a variety of technologies and applications

(Beck, Müller-Bloch, & King, 2018; Kewell & Ward, 2017) …";Cité 2 fois;Les 3 versions;[HTML] sciencedirect.com;https://www.sciencedirect.com/science/article/pii/S0263237320301407;;;https://scholar.google.com/scholar?start=30&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095339-1434;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;[LIVRE][B] Handbook of Blockchain Law: A Guide to Understanding and Resolving the Legal Challenges of Blockchain Technology;M Artzt, T Richter ;2020 books.google.com;;"… He has particular knowledge on the regulatory aspects of blockchain and crypto assets and is

a … Ethereum Virtual Machine §1.11 Smart Contracts [A] Programming Smart Contracts [B] Oracles

[C] Decentralized Applications §1.12 Tokens on the Blockchain [A] The …";Autres articles;;null;;;;https://scholar.google.com/scholar?start=240&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095371-1578;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;CRYPTO 2020;D Micciancio, T Ristenpart ; Springer;;"… Advances in Cryptology – CRYPTO 2020 Page 2. Lecture Notes in Computer Science 12170 …

Advances in Cryptology – CRYPTO 2020 40th Annual International Cryptology Conference,

CRYPTO 2020 Santa Barbara, CA, USA, August 17–21, 2020 Proceedings, Part I 123 …";Autres articles;;null;;;;https://scholar.google.com/scholar?start=380&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095390-1659;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Blockkedjesystem för smarta elnät: En undersökning om befintliga blockkedjesystem där deras egenskaper analyseras, och kvantitativa mätningar gällande deras …;S Prestberg ;2020 divaportal.org;;"… OBP Oracle Blockchain Platform … 4.5 Oracle Oracle Blockchain Platform (OBP) [25], är en

platform-as-a-service (PaaS), plattform som nättjänst, som används för att bygga och driva smarta

kontrakt och för att upprätthĺlla en liggare som är säker mot manipulering …";Autres articles;Version HTML;[PDF] diva-portal.org;https://www.diva-portal.org/smash/get/diva2:1446551/FULLTEXT01.pdf;;"""date"",""2020-06-04T13:17:01Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.5""
""xmp:CreatorTool"",""MicrosoftÂŽ Word 2010""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dc:creator"",""Sara Prestberg""
""language"",""sv""
""dcterms:created"",""2020-06-04T13:17:01Z""
""Last-Modified"",""2020-06-04T13:17:01Z""
""dcterms:modified"",""2020-06-04T13:17:01Z""
""dc:format"",""application/pdf; version=1.5""
""Last-Save-Date"",""2020-06-04T13:17:01Z""
""pdf:docinfo:creator_tool"",""MicrosoftÂŽ Word 2010""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2020-06-04T13:17:01Z""
""meta:save-date"",""2020-06-04T13:17:01Z""
""pdf:encrypted"",""false""
""modified"",""2020-06-04T13:17:01Z""
""Content-Length"",""997601""
""pdf:hasMarkedContent"",""true""
""Content-Type"",""application/pdf""
""pdf:docinfo:creator"",""Sara Prestberg""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Sara Prestberg""
""dc:language"",""sv-SE""
""meta:author"",""Sara Prestberg""
""meta:creation-date"",""2020-06-04T13:17:01Z""
""created"",""2020-06-04T13:17:01Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""41""
""Creation-Date"",""2020-06-04T13:17:01Z""
""resourceName"",""FULLTEXT01.pdf""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""426"",""1766"",""1750"",""731"",""3501"",""1092"",""538"",""107"",""2163"",""980"",""1117"",""1517"",""1562"",""1635"",""1830"",""2378"",""2477"",""1279"",""2164"",""2133"",""1459"",""1246"",""872"",""1002"",""1755"",""896"",""96"",""812"",""746"",""592"",""1180"",""2405"",""2229"",""2436"",""576"",""1541"",""1464"",""1366"",""1449"",""532"",""210""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""Author"",""Sara Prestberg""
""producer"",""MicrosoftÂŽ Word 2010""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""MicrosoftÂŽ Word 2010""
""pdf:docinfo:created"",""2020-06-04T13:17:01Z""
";https://scholar.google.com/scholar?start=460&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095320-1362;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;A blockchain based decentralized data security mechanism for the Internet of Things;C Ge, Z Liu, L Fang ; Journal of Parallel and Distributed Computing, 2020  Elsevier;;"… anonymous credentials [36]. The accumulator is also used for zero coins, which is

an anonymous extension of the bitcoin cryptocurrency [30]. 3. Proposed

blockchain-based storage system. 3.1. System model. In this subsection …";Cité 11 fois;Les 2 versions;null;;;;https://scholar.google.com/scholar?start=160&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095388-1648;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Zero-knowledge proofs in blockchain applications;A Tani ;2020 helda.helsinki.fi;;"… Definition 5 Random oracle A random oracle (RO) is an idealized version of crypto- graphic hash

function: a truly random function … “A proof of security in the random-oracle model is significantly …

Bitcoin, in addition of giving a birth to a concept of blockchain, is the first successful …";Autres articles;Version HTML;[PDF] helsinki.fi;https://helda.helsinki.fi/bitstream/handle/10138/322492/Tani_Antti_thesis_2020.pdf?sequence=2;;"""date"",""2020-11-26T07:55:03Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2020-11-26T07:55:03Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""Antti Tani""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.20 (TeX Live 2019/W32TeX) kpathsea version 6.3.1""
""meta:author"",""Antti Tani""
""trapped"",""False""
""meta:creation-date"",""2020-11-26T07:55:03Z""
""created"",""2020-11-26T07:55:03Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-11-26T07:55:03Z""
""resourceName"",""Tani_Antti_thesis_2020.pdf""
""Author"",""Antti Tani""
""producer"",""pdfLaTeX""
""pdf:docinfo:producer"",""pdfLaTeX""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""1"",""0"",""0"",""3"",""1"",""0"",""0"",""4"",""3"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""2"",""0"",""0"",""7"",""1"",""0"",""0"",""0"",""0"",""1"",""0"",""4"",""0"",""0"",""0"",""3"",""0"",""2"",""0"",""3"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""4"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""Keywords"",""something something else""
""access_permission:modify_annotations"",""true""
""dc:creator"",""Antti Tani""
""dcterms:created"",""2020-11-26T07:55:03Z""
""Last-Modified"",""2020-11-26T07:55:03Z""
""dcterms:modified"",""2020-11-26T07:55:03Z""
""title"",""""
""Last-Save-Date"",""2020-11-26T07:55:03Z""
""pdf:docinfo:keywords"",""something something else""
""pdf:docinfo:modified"",""2020-11-26T07:55:03Z""
""meta:save-date"",""2020-11-26T07:55:03Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.20 (TeX Live 2019/W32TeX) kpathsea version 6.3.1""
""Content-Length"",""715532""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Antti Tani""
""dc:subject"",""something something else""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""84""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""133"",""182"",""1783"",""1946"",""1017"",""0"",""2042"",""2127"",""1733"",""1779"",""1879"",""1424"",""1829"",""1657"",""1775"",""1732"",""2191"",""2117"",""1015"",""1875"",""2123"",""1249"",""1301"",""2013"",""2003"",""2002"",""2149"",""2044"",""2169"",""2121"",""1763"",""1780"",""2212"",""1287"",""2150"",""1895"",""1816"",""1857"",""566"",""1921"",""1897"",""1936"",""2019"",""2375"",""1953"",""2016"",""1423"",""2231"",""1644"",""1898"",""1946"",""2153"",""1413"",""2353"",""1174"",""1807"",""1940"",""2131"",""2399"",""2122"",""2089"",""1939"",""2269"",""2190"",""2363"",""1921"",""2044"",""2229"",""2351"",""28"",""2137"",""1669"",""1545"",""2065"",""1860"",""2009"",""1881"",""1769"",""1940"",""1959"",""1819"",""1867"",""1921"",""1439""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""something something else""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-11-26T07:55:03Z""
";https://scholar.google.com/scholar?start=450&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095402-1708;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Blockchain, bitcoin and stigmergy: an explanation and a new perspective for regulation;S Capaccioli ; BioLaw Journal–Rivista di BioDiritto, 2020  papers.ssrn.com;;"… providers (desktop, mobile), provider of software and dAPP, Airdrop, Mixing services, Oracles,

are activities … they exist only in the cryptocurrency system and they obtain only crypto-assets … P.

PAECH, The governance of Blockchain financial networks, 2017, in Modern Law Review …";Autres articles;;null;;;;https://scholar.google.com/scholar?start=510&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095386-1639;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;[LIVRE][B] Securing Blockchain Networks like Ethereum and Hyperledger Fabric: Learn advanced security configurations and design principles to safeguard Blockchain …;A Parisi ;2020 books.google.com;;"… Smart contract requirements 138 Automating execution and enforcement 138 Secure and

unstoppable Bridging the gap between computers and people 139 139 Feeding data to smart

contracts through Oracles 140 Deploying smart contracts on a blockchain Creating secure …";Cité 1 fois;;null;;;;https://scholar.google.com/scholar?start=440&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095306-1295;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;[HTML][HTML] Business process monitoring on blockchains: Potentials and challenges;C Di Ciccio, G Meroni, P Plebani ; Enterprise, BusinessProcess and …, 2020  Springer;;"… It is also important to consider that those oracles are external to the blockchain by definition, hence

outside the chain of trust managed by the blockchain. For this reason, when designing a time

oracle, the situation in which the oracle experiences a failure or produces fake data …";Cité 4 fois;Les 6 versions;[HTML] springer.com;https://link.springer.com/chapter/10.1007/978-3-030-49418-6_3;;;https://scholar.google.com/scholar?start=100&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095381-1615;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;[LIVRE][B] Digital Assets and Blockchain Technology: US Law and Regulation;DT Stabile, KA Prior, AM Hinkes ;2020 books.google.com;;"… of integration into traditional contracts 6.4.3 Smart legal contracts 6.5 Oracles 6.6 When are … viii

DIGITAL ASSETS AND BLOCKCHAIN TECHNOLOGY 261 262 6.9.3 Forks 6.10 Use of … 333 Crypto

Asset Management, LP and Timothy Enneking, Respondents, In the Matter of, SEC …";Cité 1 fois;;null;;;;https://scholar.google.com/scholar?start=420&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095367-1559;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Blockchain and smart contract in future transactions—Case studies;O Bamasag, A Munshi, H Alharbi, O Aldairi… ; Decentralised Internet of …, 2020  Springer;;"… It is meant to be a venture capital fund for the crypto and decentralized space … According to the

input of trusted data feeds, ie Oracles, and the system state, the contract decides whether … The

new block is chained into the blockchain once the whole network agrees on a consensus …";Cité 2 fois;Les 3 versions;null;;;;https://scholar.google.com/scholar?start=360&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095362-1538;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;"[PDF][PDF] "" Impact of the Blockchain on the Sharing Economy";A Maistriaux, B Paque ; dial.uclouvain.be;;"… study on the right track toward delivering sound and meaningful conclusions. I also want to

express my gratitude toward the UCL Crypto Group for contributing in my understanding of

the technical aspects of Blockchain with their expertise as well as the …";Les 2 versions;Version HTML;[PDF] uclouvain.be;https://dial.uclouvain.be/downloader/downloader.php?pid=thesis%3A15522&datastream=PDF_01&cover=cover-mem;;"""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""dc:title"",""DIAL : download document""
""Content-Encoding"",""UTF-8""
""resourceName"",""downloader.php""
""language"",""fr""
""title"",""DIAL : download document""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=340&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095404-1721;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;CHAPTER TWO BLOCKCHAIN FOR INTERNET OF THINGS BIOZID BOSTAMI1 AND MOHIUDDIN AHMED2;B BOSTAMI, M AHMED ; Blockchain in Data Analytics, 2020  books.google.com;;"… was initially designed for high computational devices which can handle crypto currency with … Smart

contracts demand the use of special entities, known as oracles, for providing data … While integrating

IoT with blockchain, smart contracts need to address the heterogenic nature of …";Autres articles;;null;;;;https://scholar.google.com/scholar?start=520&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095316-1342;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Privacy-preserving peer-to-peer energy trading in blockchain-enabled smart grids using functional encryption;YB Son, JH Im, HY Kwon, SY Jeon, MK Lee ; Energies, 2020  mdpi.com;;"… Although the blockchain concept originated from Bitcoin [5], the script language for Bitcoin

is too limited to perform general transactions because it is designed mainly for a

single-purpose application (ie, exchanging Bitcoin cryptocurrency) …";Cité 13 fois;Les 6 versions;[PDF] mdpi.com;https://www.mdpi.com/1996-1073/13/6/1321/pdf;;;https://scholar.google.com/scholar?start=140&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095381-1623;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Nghięn c?u các ?ng d?ng c?a Blockchain cho bŕi toán thanh toán phí ti?n m?t trong các h? th?ng tŕi chính ngân hŕng;?D Nguy?n ;2020 demo.dspace.vn;;"… 11 2.3.8. Oracles Oracles trong Corda c?ng có ý ngh?a t??ng t? nh? Oracles trong các n?n t?ng

blockchain … Ghi chú Oracle JDK version 8u171 ho?c cao h?n … 3.2.2. Ki?n trúc h? th?ng H? th?ng

chuy?n ti?n lięn ngân hŕng qua Blockchain Corda R3 trong nghięn c?u nŕy ???c …";Les 5 versions;Version HTML;[PDF] dspace.vn;http://demo.dspace.vn/bitstream/11461/1755/1/TTLV%20Nguyen%20Duc%20Duy%202020.pdf;;"""date"",""2021-01-30T13:44:11Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.5""
""xmp:CreatorTool"",""MicrosoftÂŽ Word 2013""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dc:creator"",""Duy""
""language"",""vi""
""dcterms:created"",""2020-12-01T14:33:23Z""
""Last-Modified"",""2021-01-30T13:44:11Z""
""dcterms:modified"",""2021-01-30T13:44:11Z""
""dc:format"",""application/pdf; version=1.5""
""Last-Save-Date"",""2021-01-30T13:44:11Z""
""pdf:docinfo:creator_tool"",""MicrosoftÂŽ Word 2013""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2021-01-30T13:44:11Z""
""meta:save-date"",""2021-01-30T13:44:11Z""
""pdf:encrypted"",""false""
""modified"",""2021-01-30T13:44:11Z""
""Content-Length"",""482436""
""pdf:hasMarkedContent"",""true""
""Content-Type"",""application/pdf""
""pdf:docinfo:creator"",""Duy""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Duy""
""dc:language"",""en-US""
""meta:author"",""Duy""
""meta:creation-date"",""2020-12-01T14:33:23Z""
""created"",""2020-12-01T14:33:23Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""18""
""Creation-Date"",""2020-12-01T14:33:23Z""
""resourceName"",""TTLV%20Nguyen%20Duc%20Duy%202020.pdf""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""426"",""487"",""1432"",""1368"",""1986"",""2099"",""1813"",""2304"",""1387"",""1275"",""1180"",""1373"",""742"",""1100"",""585"",""220"",""897"",""1711""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""Author"",""Duy""
""producer"",""MicrosoftÂŽ Word 2013""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""MicrosoftÂŽ Word 2013""
""pdf:docinfo:created"",""2020-12-01T14:33:23Z""
";https://scholar.google.com/scholar?start=420&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095390-1658;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Removing the Trusted Third Party in a Confidential Multiparty Registered eDelivery Protocol Using Blockchain;M Mut;Puigserver, MA CabotNadal…  IEEE …, 2020  ieeexplore.ieee.org;;"… Next, we present the protocol, the description of the crypto- graphic operations used in it and

the implemented application with the smart contracts … when the smart contract does not know the

content of the delivered data and the plain message is not registered on the blockchain …";Cité 2 fois;Les 2 versions;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/6287639/8948470/09110560.pdf;;"""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""dc:title"",""IEEE Xplore Full-Text PDF:""
""Content-Encoding"",""UTF-8""
""resourceName"",""09110560.pdf""
""language"",""es""
""Content-Length"",""2565""
""title"",""IEEE Xplore Full-Text PDF:""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=460&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095304-1284;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;PharmaCrypt: Blockchain for critical pharmaceutical industry to counterfeit drugs;N Saxena, I Thomas, P Gope, P Burnap, N Kumar ; Computer, 2020  ieeexplore.ieee.org;;"… Oracle blockchain. Oracle is extremely similar to AWS because it is a blockchain-as-a-service

provider … 1 Q6: Are you aware of blockchain or cryptocurrency technology, that is, bitcoin?

A6: 1) Yes. ×7 2) No. ×4 3) Have heard of it but never used it. ×19 …";Cité 3 fois;Les 7 versions;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/2/9130391/09130418.pdf?casa_token=FA1daORKeucAAAAA:iaC8Hubasvol1drEMQZbQYCpLzfuKRAFgj5tVsi3U172_yLd8nn95R8I0c2VAA6XWK3hQbU1Nlw;;"""og:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""twitter:title"",""PharmaCrypt: Blockchain for Critical Pharmaceutical Industry to Counterfeit Drugs""
""twitter:card"",""summary""
""Description"",""This research analyzes the impact of counterfeit drugs on the health-care supply chain industry and evaluates the solutions currently in place to reduce the num""
""og:title"",""PharmaCrypt: Blockchain for Critical Pharmaceutical Industry to Counterfeit Drugs""
""resourceName"",""09130418.pdf""
""language"",""en""
""title"",""PharmaCrypt: Blockchain for Critical Pharmaceutical Industry to Counterfeit Drugs | IEEE Journals & Magazine | IEEE Xplore""
""og:description"",""This research analyzes the impact of counterfeit drugs on the health-care supply chain industry and evaluates the solutions currently in place to reduce the number of counterfeits coming to the market. Feedback information obtained from industry professionals is used to build requirements for PharmaCrypt, a new blockchain-driven tool.""
""twitter:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-UA-Compatible"",""IE=Edge""
""viewport"",""width=device-width, initial-scale=1.0""
""dc:title"",""PharmaCrypt: Blockchain for Critical Pharmaceutical Industry to Counterfeit Drugs | IEEE Journals & Magazine | IEEE Xplore""
""twitter:description"",""This research analyzes the impact of counterfeit drugs on the health-care supply chain industry and evaluates the solutions currently in place to reduce the number of counterfeits coming to the market. Feedback information obtained from industry professionals is used to build requirements for PharmaCrypt, a new blockchain-driven tool.""
""Content-Encoding"",""UTF-8""
""Content-Type-Hint"",""text/html; charset=utf-8""
""Content-Length"",""40149""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=90&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095311-1316;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Blockchain in Accounting Research and Practice: Current Trends and Future Opportunities;E Pimentel, E Boulianne ; Accounting Perspectives, 2020  Wiley Online Library;;"… A key distinction is whether a cryptoasset qualifies as a cryptocurrency or as a token … First, we

searched the databases of the leading academic accounting journals for articles related to the

keywords blockchain, distributed ledger and crypto and obtained zero results …";Autres articles;;[PDF] wiley.com;https://onlinelibrary.wiley.com/doi/pdf/10.1111/1911-3838.12239?casa_token=pA0EaQo6TMgAAAAA:4YbLQmskzSJmUdjSSFXi9yzMAyQlG8PPO3lnCOtgrflGX_xPgxTTr9PJc90oQ8lFO3RDbxV8MCKdbQ;;;https://scholar.google.com/scholar?start=120&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095302-1279;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;[LIVRE][B] Advanced applications of blockchain technology;S Kim, GC Deka ;2020 Springer;;"… Ltd. The registered company address is: 152 Beach Road,# 21-01/04 Gateway

East, Singapore 189721, Singapore Page 6. Preface The initial and the most popular

application of Blockchain was cryptocurrency. Blockchain …";Cité 11 fois;Les 3 versions;null;;;;https://scholar.google.com/scholar?start=80&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095365-1551;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;[PDF][PDF] Multi-Chain Architecture for Blockchain Networks;K Košt'ál ; Information Sciences & Technologies: Bulletin of …, 2020  acmbulletin.fiit.stuba.sk;;"… Yes Cross-chain oracles No Yes Yes Asset encumbrance No Yes (requires

long-term notary trust) Yes … In 2019 IEEE Int. Conf. on Blockchain and Cryptocurrency

(ICBC), pages 455–463. IEEE, 2019. [10] Y. Guo and C. Liang …";Autres articles;;[PDF] stuba.sk;http://acmbulletin.fiit.stuba.sk/vol12num2/kostal2020.pdf;;"""date"",""2020-09-24T07:12:48Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2020-09-24T07:12:48Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is MiKTeX-pdfTeX 2.9.5840 (1.40.16)""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2020-09-24T07:12:48Z""
""created"",""2020-09-24T07:12:48Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-09-24T07:12:48Z""
""resourceName"",""kostal2020.pdf""
""Author"",""""
""producer"",""pdfTeX-1.40.16""
""pdf:docinfo:producer"",""pdfTeX-1.40.16""
""pdf:unmappedUnicodeCharsPerPage"",""1"",""0"",""0"",""0"",""0"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2020-09-24T07:12:48Z""
""Last-Modified"",""2020-09-24T07:12:48Z""
""dcterms:modified"",""2020-09-24T07:12:48Z""
""title"",""""
""Last-Save-Date"",""2020-09-24T07:12:48Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2020-09-24T07:12:48Z""
""meta:save-date"",""2020-09-24T07:12:48Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is MiKTeX-pdfTeX 2.9.5840 (1.40.16)""
""Content-Length"",""470970""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""7""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""4731"",""5105"",""4424"",""4480"",""4726"",""4825"",""2404""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-09-24T07:12:48Z""
";https://scholar.google.com/scholar?start=350&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095285-1207;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Blockchain Oracles: A Framework for Blockchain-Based Applications (SLR Protocol and Results);K Mammadzada, M Iqbal, F Payman Milani… ;2020 datadoi.ee;;"Blockchain oracles support the access, validation, and transmission of data from external 
sources. They are important components of blockchain-based architectures, however, there 
exist no guidance on how oracles could be used when designing decentralised …";Cité 1 fois;;[PDF] datadoi.ee;https://datadoi.ee/bitstream/handle/33/147/Blockchain-Oracles-SLR.pdf?sequence=1&isAllowed=y;;"""date"",""2020-01-11T20:33:00Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.5""
""xmp:CreatorTool"",""MicrosoftÂŽ Word 2016""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dc:creator"",""FM""
""language"",""en""
""dcterms:created"",""2020-01-11T20:33:00Z""
""Last-Modified"",""2020-01-11T20:33:00Z""
""dcterms:modified"",""2020-01-11T20:33:00Z""
""dc:format"",""application/pdf; version=1.5""
""Last-Save-Date"",""2020-01-11T20:33:00Z""
""pdf:docinfo:creator_tool"",""MicrosoftÂŽ Word 2016""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2020-01-11T20:33:00Z""
""meta:save-date"",""2020-01-11T20:33:00Z""
""pdf:encrypted"",""false""
""modified"",""2020-01-11T20:33:00Z""
""Content-Length"",""1143265""
""pdf:hasMarkedContent"",""true""
""Content-Type"",""application/pdf""
""pdf:docinfo:creator"",""FM""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""FM""
""dc:language"",""en-US""
""meta:author"",""FM""
""meta:creation-date"",""2020-01-11T20:33:00Z""
""created"",""2020-01-11T20:33:00Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""15""
""Creation-Date"",""2020-01-11T20:33:00Z""
""resourceName"",""Blockchain-Oracles-SLR.pdf""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""2779"",""2711"",""2665"",""3297"",""1976"",""2227"",""488"",""1184"",""1727"",""2279"",""1473"",""1766"",""1570"",""3590"",""1667""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""Author"",""FM""
""producer"",""MicrosoftÂŽ Word 2016""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""MicrosoftÂŽ Word 2016""
""pdf:docinfo:created"",""2020-01-11T20:33:00Z""
";https://scholar.google.com/scholar?start=10&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095304-1288;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Blockchain and industry 4.0: overview, convergence, and analysis;TB da Silva, ES de Morais, LFF de Almeida… ; Blockchain Technology …, 2020  Springer;;"… The system responsible for integrating off-chain data into the network and to the smarts contracts

is given the name of oracle [46] … The challenge of the oracles in the Blockchain network is to bring

an acceptable level of trust to off-chain information, contradicting the very …";Cité 1 fois;Les 5 versions;[PDF] inatel.br;https://biblioteca.inatel.br/cict/acervo%20publico/sumarios/Ebooks/Springer%20Text%20books%20-%20Organizado%20por%20ano/2020_Blockchain%20and%20Industry%204.0_%20Overview%20-%20convergence%20-%20and%20Analysis.pdf#page=33;;"""date"",""2020-06-16T13:40:35Z""
""pdf:PDFVersion"",""1.6""
""xmp:CreatorTool"",""Adobe InDesign 14.0 (Windows)""
""pdf:docinfo:title"",""478482_1_En_Print.indd""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""false""
""xmpMM:History:Action"",""converted"",""converted""
""language"",""en""
""dc:format"",""application/pdf; version=1.6""
""pdf:docinfo:creator_tool"",""Adobe InDesign 14.0 (Windows)""
""access_permission:fill_in_form"",""false""
""xmpMM:History:When"",""2019-12-21T11:23:46Z"",""2019-12-21T11:24:34Z""
""pdf:encrypted"",""true""
""dc:title"",""478482_1_En_Print.indd""
""xmp:CreateDate"",""2019-12-21T09:36:17Z""
""modified"",""2020-06-16T13:40:35Z""
""xmpMM:History:SoftwareAgent"",""pdfToolbox"",""pdfToolbox""
""pdf:hasMarkedContent"",""false""
""xmpMM:History:InstanceID"",""uuid:87a523ae-eb9c-48b6-805f-9c8517f6a8a3"",""uuid:748acdb2-0479-4fb5-b7e4-9a1510daa3c4""
""xmp:ModifyDate"",""2020-06-16T10:40:35Z""
""pdf:docinfo:creator"",""Pagination_Cover""
""meta:author"",""Pagination_Cover""
""meta:creation-date"",""2019-12-21T04:06:17Z""
""created"",""2019-12-21T04:06:17Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-12-21T04:06:17Z""
""resourceName"",""2020_Blockchain%20and%20Industry%204.0_%20Overview%20-%20convergence%20-%20and%20Analysis.pdf""
""Author"",""Pagination_Cover""
""producer"",""Acrobat Distiller 10.0.0 (Windows)""
""pdf:docinfo:producer"",""Acrobat Distiller 10.0.0 (Windows)""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""1"",""2"",""0"",""0"",""0"",""1"",""0"",""0"",""13"",""13"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""access_permission:modify_annotations"",""false""
""dc:creator"",""Pagination_Cover""
""dcterms:created"",""2019-12-21T04:06:17Z""
""Last-Modified"",""2020-06-16T13:40:35Z""
""dcterms:modified"",""2020-06-16T13:40:35Z""
""title"",""478482_1_En_Print.indd""
""xmpMM:DocumentID"",""uuid:e8769ceb-5ae8-4277-844f-47ddad59dcc0""
""Last-Save-Date"",""2020-06-16T13:40:35Z""
""pdf:docinfo:modified"",""2020-06-16T13:40:35Z""
""meta:save-date"",""2020-06-16T13:40:35Z""
""Content-Length"",""5096506""
""Content-Type"",""application/pdf""
""xmp:MetadataDate"",""2020-06-16T10:40:35Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Pagination_Cover""
""dc:language"",""EN""
""pdf:producer"",""Acrobat Distiller 10.0.0 (Windows)""
""access_permission:assemble_document"",""false""
""xmpTPg:NPages"",""169""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""193"",""286"",""2405"",""160"",""1671"",""964"",""2076"",""1731"",""2773"",""2434"",""1806"",""1267"",""2845"",""1272"",""1390"",""1847"",""2651"",""2535"",""2936"",""1828"",""3173"",""1896"",""1155"",""1532"",""3092"",""1650"",""1736"",""1448"",""2642"",""2279"",""3370"",""2424"",""1601"",""2650"",""2376"",""1922"",""1495"",""1959"",""2773"",""3119"",""3234"",""2762"",""1423"",""2579"",""2955"",""2731"",""3039"",""2991"",""2952"",""2686"",""2742"",""3074"",""2951"",""3079"",""2824"",""3114"",""2502"",""2839"",""496"",""2225"",""2735"",""3195"",""3381"",""1327"",""1461"",""1130"",""1128"",""1242"",""1159"",""1447"",""907"",""333"",""1272"",""1725"",""1243"",""1264"",""1752"",""1688"",""1786"",""2487"",""2823"",""3066"",""2727"",""2463"",""1549"",""1996"",""2535"",""1700"",""1907"",""2893"",""1837"",""721"",""2640"",""2418"",""2262"",""1045"",""2907"",""2222"",""1604"",""1802"",""1808"",""3343"",""3514"",""220"",""1550"",""2519"",""2286"",""2312"",""2254"",""2462"",""1087"",""2902"",""2551"",""2748"",""2852"",""2613"",""2050"",""2582"",""2183"",""2815"",""3570"",""418"",""2044"",""1623"",""2482"",""2250"",""2521"",""1177"",""2837"",""3036"",""2732"",""3105"",""1723"",""2630"",""3318"",""946"",""1928"",""3172"",""958"",""1376"",""2376"",""1340"",""2578"",""2572"",""2266"",""1484"",""1307"",""2382"",""2253"",""2182"",""2437"",""3419"",""1873"",""2077"",""2408"",""1182"",""2795"",""2839"",""2146"",""2353"",""68"",""2693"",""1946"",""2567"",""2735"",""2815"",""2788"",""2941"",""2037""
""access_permission:extract_content"",""false""
""access_permission:can_print"",""false""
""access_permission:can_modify"",""false""
""pdf:docinfo:created"",""2019-12-21T04:06:17Z""
";https://scholar.google.com/scholar?start=90&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095371-1582;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;EC-ElGamal and Genetic Algorithm-Based Enhancement for Lightweight Scalable Blockchain in IoT Domain;J Guruprakash, S Koppu ; IEEE Access, 2020  ieeexplore.ieee.org;;"… Enhancement for Lightweight Scalable Blockchain in IoT Domain … ABSTRACT Security, data privacy

and decentralization are significant challenges in the Internet of Things (IoT) domain. These

challenges are inherited attribute of another emerging technology, Blockchain …";Cité 1 fois;;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/6287639/8948470/09153770.pdf;;"""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""dc:title"",""IEEE Xplore Full-Text PDF:""
""Content-Encoding"",""UTF-8""
""resourceName"",""09153770.pdf""
""language"",""es""
""Content-Length"",""2565""
""title"",""IEEE Xplore Full-Text PDF:""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=380&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095395-1674;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Public Financial Transaction Database: The Overview of Cryptocurrency;N Ishak ; International Journal of Advanced Research in …, 2020  myjms.mohe.gov.my;;"… Thus, during this case the oracles act as their go-between and hold each their assets … into a new

block and adding it to the global ledger known as blockchain (see Frankenfield … They also mention

that crypto-attacks do not appear to affect cryptocurrency returns during the highly …";Autres articles;Version HTML;[PDF] mohe.gov.my;http://myjms.mohe.gov.my/index.php/ijaref/article/download/8670/3854;;"""date"",""2020-05-05T09:06:49Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.5""
""xmp:CreatorTool"",""MicrosoftÂŽ Word 2010""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dc:creator"",""firdaus razab""
""language"",""en""
""dcterms:created"",""2020-05-05T09:06:49Z""
""Last-Modified"",""2020-05-05T09:06:49Z""
""dcterms:modified"",""2020-05-05T09:06:49Z""
""dc:format"",""application/pdf; version=1.5""
""Last-Save-Date"",""2020-05-05T09:06:49Z""
""pdf:docinfo:creator_tool"",""MicrosoftÂŽ Word 2010""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2020-05-05T09:06:49Z""
""meta:save-date"",""2020-05-05T09:06:49Z""
""pdf:encrypted"",""false""
""modified"",""2020-05-05T09:06:49Z""
""Content-Length"",""392602""
""pdf:hasMarkedContent"",""true""
""Content-Type"",""application/pdf""
""pdf:docinfo:creator"",""firdaus razab""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""firdaus razab""
""dc:language"",""en-US""
""meta:author"",""firdaus razab""
""meta:creation-date"",""2020-05-05T09:06:49Z""
""created"",""2020-05-05T09:06:49Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""10""
""Creation-Date"",""2020-05-05T09:06:49Z""
""resourceName"",""3854""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""3443"",""3037"",""1842"",""2704"",""4089"",""4471"",""3973"",""3866"",""3712"",""2804""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""Author"",""firdaus razab""
""producer"",""MicrosoftÂŽ Word 2010""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""MicrosoftÂŽ Word 2010""
""pdf:docinfo:created"",""2020-05-05T09:06:49Z""
";https://scholar.google.com/scholar?start=480&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095355-1511;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Truthful, Transparent and Fair Data Collection Mechanisms;N Goel ;2020 infoscience.epfl.ch;;"… Smart contracts often rely on a trusted third party (oracle) to get correct information about

real-world events. We show how peer-consistency mechanisms can be used to build

decentralized, trustless and transparent data oracles on blockchain …";Autres articles;Version HTML;[PDF] epfl.ch;https://infoscience.epfl.ch/record/280222/files/EPFL_TH7396.pdf;;"""date"",""2020-09-28T07:27:11Z""
""pdf:PDFVersion"",""1.6""
""pdf:docinfo:title"",""Truthful, Transparent and Fair Data Collection Mechanisms""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""fr""
""dc:format"",""application/pdf; version=1.6""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""Truthful, Transparent and Fair Data Collection Mechanisms""
""modified"",""2020-09-28T07:27:11Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""Goel, Naman""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017) kpathsea version 6.2.3""
""meta:author"",""Goel, Naman""
""trapped"",""False""
""meta:creation-date"",""2020-09-15T14:46:26Z""
""created"",""2020-09-15T14:46:26Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-09-15T14:46:26Z""
""resourceName"",""EPFL_TH7396.pdf""
""Author"",""Goel, Naman""
""producer"",""pdfTeX-1.40.18""
""pdf:docinfo:producer"",""pdfTeX-1.40.18""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""2"",""2"",""0"",""6"",""15"",""12"",""7"",""9"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""1"",""3"",""0"",""1"",""0"",""1"",""0"",""0"",""0"",""2"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""1"",""4"",""9"",""2"",""2"",""2"",""9"",""0"",""0"",""0"",""0"",""6"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""4"",""9"",""0"",""12"",""0"",""0"",""2"",""2"",""0"",""0"",""0"",""0"",""0"",""0"",""1"",""8"",""11"",""8"",""13"",""0"",""2"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""5"",""28"",""25"",""4"",""9"",""8"",""20"",""29"",""1"",""2"",""18"",""22"",""6"",""12"",""12"",""18"",""28"",""19"",""71"",""34"",""46"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""Goel, Naman""
""dcterms:created"",""2020-09-15T14:46:26Z""
""Last-Modified"",""2020-09-28T07:27:11Z""
""dcterms:modified"",""2020-09-28T07:27:11Z""
""title"",""Truthful, Transparent and Fair Data Collection Mechanisms""
""Last-Save-Date"",""2020-09-28T07:27:11Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2020-09-28T07:27:11Z""
""meta:save-date"",""2020-09-28T07:27:11Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017) kpathsea version 6.2.3""
""Content-Length"",""4267353""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Goel, Naman""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""154""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""477"",""0"",""85"",""0"",""1530"",""0"",""2480"",""387"",""2446"",""1068"",""1481"",""2340"",""2121"",""152"",""1807"",""494"",""528"",""0"",""1222"",""971"",""2803"",""2533"",""3267"",""2633"",""2213"",""376"",""1881"",""2848"",""2924"",""2120"",""2089"",""2121"",""2232"",""1864"",""2214"",""2472"",""2223"",""2717"",""2350"",""2209"",""1972"",""160"",""1807"",""1099"",""1813"",""2562"",""2967"",""2335"",""2490"",""1390"",""1332"",""2505"",""2438"",""2471"",""1472"",""1717"",""2264"",""1924"",""2192"",""2575"",""2432"",""2994"",""2738"",""1938"",""1780"",""2828"",""2069"",""2636"",""2501"",""2503"",""2349"",""2814"",""2756"",""2582"",""2400"",""2423"",""2337"",""2483"",""1358"",""2266"",""2216"",""2525"",""2253"",""893"",""2498"",""341"",""1889"",""2965"",""2797"",""1906"",""1853"",""1473"",""2703"",""2208"",""2381"",""2712"",""2356"",""2480"",""2479"",""1173"",""1372"",""0"",""1910"",""2845"",""2639"",""2364"",""2436"",""1654"",""1851"",""1800"",""1732"",""2494"",""2255"",""1332"",""1367"",""1645"",""2071"",""2836"",""2320"",""0"",""705"",""1307"",""1252"",""1148"",""854"",""1155"",""1238"",""1803"",""1785"",""1355"",""1310"",""1465"",""1338"",""1008"",""1184"",""1559"",""937"",""798"",""690"",""1291"",""775"",""0"",""1534"",""2130"",""2082"",""2127"",""2010"",""2238"",""2000"",""1983"",""2290"",""0"",""2016"",""1857""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-09-15T14:46:26Z""
";https://scholar.google.com/scholar?start=310&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095346-1464;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;An overview on smart contracts: Challenges, advances and platforms;Z Zheng, S Xie, HN Dai, W Chen, X Chen… ; Future Generation …, 2020  Elsevier;;"… The financial settlement from the buyer to the supplier is conducted via crypto currencies (eg,

Bitcoin or Ether … Therefore, all these three phases need to write data to the blockchain as shown

in Fig. 4 … Execution, 1) Trustworthy oracle, • Third-party involved [65] …";Cité 115 fois;Les 7 versions;[PDF] arxiv.org;https://arxiv.org/pdf/1912.10370;;"""date"",""2019-12-24T01:42:41Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2019-12-24T01:42:41Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016) kpathsea version 6.2.2""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2019-12-24T01:42:41Z""
""created"",""2019-12-24T01:42:41Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-12-24T01:42:41Z""
""resourceName"",""1912.10370""
""Author"",""""
""producer"",""pdfTeX-1.40.17""
""pdf:docinfo:producer"",""pdfTeX-1.40.17""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""42"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""18"",""0"",""0"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2019-12-24T01:42:41Z""
""Last-Modified"",""2019-12-24T01:42:41Z""
""dcterms:modified"",""2019-12-24T01:42:41Z""
""title"",""""
""Last-Save-Date"",""2019-12-24T01:42:41Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2019-12-24T01:42:41Z""
""meta:save-date"",""2019-12-24T01:42:41Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016) kpathsea version 6.2.2""
""Content-Length"",""1533581""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""19""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""3233"",""4746"",""4639"",""3311"",""4289"",""3232"",""5220"",""5083"",""4851"",""5544"",""4405"",""4087"",""2760"",""4894"",""4174"",""6363"",""8013"",""7675"",""963""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-12-24T01:42:41Z""
";https://scholar.google.com/scholar?start=270&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095309-1310;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Decentralized finance: On blockchain-and smart contract-based financial markets;F Schär ; Available at SSRN 3571335, 2020  papers.ssrn.com;;"… the borrower receives the funds, uses and repays them – all within the same Blockchain

transaction … Although the system is mostly decentralized, it is reliant on price oracles … They usually

require an oracle to track these variables and therefore introduce some dependencies and …";Cité 16 fois;Les 2 versions;[PDF] researchgate.net;https://www.researchgate.net/profile/Fabian_Schaer2/publication/340061422_Decentralized_Finance_On_Blockchain-_and_Smart_Contract-based_Financial_Markets/links/5e74be43a6fdcca24a3148e9/Decentralized-Finance-On-Blockchain-and-Smart-Contract-based-Financial-Markets.pdf;;;https://scholar.google.com/scholar?start=110&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095339-1441;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;How Blockchain Can Bring Trust and Transparency to the Payment of Crowd Forecasters;A Carvalho, M Karimi ;2020 aisel.aisnet.org;;"… Despite different modus operandi, it is nonetheless interesting to discuss how the above solutions

define oracles … “Augur: A Decentralized Oracle and Prediction … “Do You Need a Blockchain?” in

Proceedings of the 2018 Crypto Valley Conference on Blockchain Technology, Zug …";Autres articles;;[PDF] researchgate.net;https://www.researchgate.net/profile/Arthur_Carvalho4/publication/348065202_How_Blockchain_Can_Bring_Trust_and_Transparency_to_the_Payment_of_Crowd_Forecasters/links/5fee25a1299bf1408860f473/How-Blockchain-Can-Bring-Trust-and-Transparency-to-the-Payment-of-Crowd-Forecasters.pdf;;;https://scholar.google.com/scholar?start=240&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095332-1404;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;AI and Blockchain;E Hechler, M Oberhofer, T Schaeck ; Deploying AI in the Enterprise, 2020  Springer;;"… The consensus mechanism is substantially less resource intensive compared to cryptocurrency

blockchains. Transactions are immutable. 2 … https://blogs.oracle.com/blockchain/blockchain-tables-

in-oracle-database:-technology-convergence (accessed April 2020). [20] …";Autres articles;;null;;;;https://scholar.google.com/scholar?start=210&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095299-1268;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;[PDF][PDF] The Current Limitations of Blockchain Traceability: Challenges from Industry;N Sánchez;Gómez, MM Risoto, JM RamosCueli… 2020 scitepress.org;;"… Figure 5: Architecture for blockchain traceability solutions. The pillars of this puzzle are the

blockchain oracle and the external APIs … A study of blockchain oracles. arXiv preprint

arXiv:2004.07140. Buterin, V. et al. (2014) … A survey on the security of blockchain systems …";;;[PDF] scitepress.org;https://www.scitepress.org/Papers/2020/102135/102135.pdf;;"""date"",""2020-11-12T04:22:05Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2020-11-12T04:22:05Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is MiKTeX-pdfTeX 2.9.6870 (1.40.19)""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2020-11-12T04:22:05Z""
""created"",""2020-11-12T04:22:05Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-11-12T04:22:05Z""
""resourceName"",""102135.pdf""
""Author"",""""
""producer"",""pdfTeX-1.40.19""
""pdf:docinfo:producer"",""pdfTeX-1.40.19""
""pdf:unmappedUnicodeCharsPerPage"",""1"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2020-11-12T04:22:05Z""
""Last-Modified"",""2020-11-12T04:22:05Z""
""dcterms:modified"",""2020-11-12T04:22:05Z""
""title"",""""
""Last-Save-Date"",""2020-11-12T04:22:05Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2020-11-12T04:22:05Z""
""meta:save-date"",""2020-11-12T04:22:05Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is MiKTeX-pdfTeX 2.9.6870 (1.40.19)""
""Content-Length"",""1166212""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""8""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""3670"",""4373"",""4008"",""2138"",""4567"",""3133"",""3124"",""4871""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-11-12T04:22:05Z""
";https://scholar.google.com/scholar?start=70&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095409-1735;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Internet of beer: A review on smart technologies from mash to pint;S Violino, S Figorilli, C Costa, F Pallottino ; Foods, 2020  mdpi.com;;"… levels. Keywords: IoT internet of things; microcontrollers; blockchain; craft beer; AI

artificial intelligence; big data IoT internet of things; microcontrollers; blockchain; craft

beer; AI artificial intelligence; big data. 1. Introduction. Beer …";Cité 2 fois;Les 8 versions;[PDF] mdpi.com;https://www.mdpi.com/2304-8158/9/7/950/pdf;;;https://scholar.google.com/scholar?start=540&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095337-1425;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;TrustCA: Achieving Certificate Transparency Through Smart Contract in Blockchain Platforms;J Zhao, Z Lin, X Huang, Y Zhang… ; … Conference on High …, 2020  ieeexplore.ieee.org;;"… We propose a new system architecture easy to integrate the CA proxy with current CAs through

applying the blockchain oracle service … By using blockchain oracle services such as Oraclize

[4], traditional CAs can be easily integrated into new systems …";Autres articles;;null;;;;https://scholar.google.com/scholar?start=230&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095330-1402;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Quantum Attacks on HCTR and its Variants;M Rahman, G Paul ; IEEE Transactions on Quantum …, 2020  ieeexplore.ieee.org;;"… in Crypto 2016 … OUTPUT TRUNCATION OF QUANTUM ORACLES In the attack on 3-round Feistel

cipher, Kuwakado and Morii [4] use the right half of the output from the … In [14], it is mentioned that

the outputs of 3-round Feistel oracle in the left and the right halves are entangled …";Cité 1 fois;Les 2 versions;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/8924785/8943246/09273239.pdf;;"""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""dc:title"",""IEEE Xplore Full-Text PDF:""
""Content-Encoding"",""UTF-8""
""resourceName"",""09273239.pdf""
""language"",""es""
""Content-Length"",""2565""
""title"",""IEEE Xplore Full-Text PDF:""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=200&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095369-1573;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;A Secure Signature Scheme for IoT Blockchain Framework Based on Multimodal Biometrics;YA Lotfy, SM Darwish ; … Conference on Advanced Intelligent Systems and …, 2020  Springer;;"… Waters, B.: Efficient Identity-based encryption without random Oracles. Lecture Notes on Computer

Science, vol. 3494, pp … Cachin, C.: Architecture of the hyperledger blockchain fabric. In: Workshop

on Distributed Crypto-Currencies and Consensus Ledgers, Zurich. vol …";Cité 1 fois;;null;;;;https://scholar.google.com/scholar?start=370&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095297-1260;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;[HTML][HTML] Building trust and equity in marine conservation and fisheries supply chain management with blockchain;P Howson ; Marine Policy, 2020  Elsevier;;"… The challenges for these crypto-fixes are technical and political in nature … Blockchain technology

is enabling larger companies to cost effectively protect their brand images. However, unless

peripheral oracles are developed that are trust preserving, blockchain fixes for marine …";Cité 22 fois;Les 3 versions;[HTML] sciencedirect.com;https://www.sciencedirect.com/science/article/pii/S0308597X19307067?casa_token=Od79IWwRUFwAAAAA:tMUAgykBEhFuRjVBno05eSyrqudW6XUnb1x7gMz0oZsi7tHeszOUu6Yj4pKTRvpCR0sgmMOQ;;;https://scholar.google.com/scholar?start=60&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095362-1539;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Put Your Money Where Your Mouth Is–Towards Blockchain-based Consent Violation Detection;J Heiss, MR Ulbricht, J Eberhardt ; … and Cryptocurrency (ICBC), 2020  ieeexplore.ieee.org;;"… The Blockchain should allow for depositing the monetary reward in its native crypto-currency

and provide a trustworthy environment for executing smart contracts. This would guarantee

transparency, high availability, and censorship-resistance …";Cité 1 fois;Les 4 versions;[PDF] tu-berlin.de;https://www.ise.tu-berlin.de/fileadmin/fg308/publications/2020/preprint-icbc-heiss.pdf;;"""date"",""2020-02-20T17:22:17Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""2"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.5""
""xmp:CreatorTool"",""TeX""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dcterms:created"",""2020-02-20T17:22:17Z""
""language"",""en""
""Last-Modified"",""2020-02-20T17:22:17Z""
""dcterms:modified"",""2020-02-20T17:22:17Z""
""dc:format"",""application/pdf; version=1.5""
""Last-Save-Date"",""2020-02-20T17:22:17Z""
""pdf:docinfo:creator_tool"",""TeX""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2020-02-20T17:22:17Z""
""meta:save-date"",""2020-02-20T17:22:17Z""
""pdf:encrypted"",""false""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.20 (TeX Live 2019/W32TeX) kpathsea version 6.3.1""
""modified"",""2020-02-20T17:22:17Z""
""Content-Length"",""406931""
""pdf:hasMarkedContent"",""false""
""Content-Type"",""application/pdf""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.20 (TeX Live 2019/W32TeX) kpathsea version 6.3.1""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""trapped"",""False""
""meta:creation-date"",""2020-02-20T17:22:17Z""
""created"",""2020-02-20T17:22:17Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""9""
""Creation-Date"",""2020-02-20T17:22:17Z""
""resourceName"",""preprint-icbc-heiss.pdf""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""4469"",""4482"",""3851"",""4167"",""4798"",""2275"",""5085"",""4979"",""3132""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""producer"",""pdfTeX-1.40.20""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""pdfTeX-1.40.20""
""pdf:docinfo:created"",""2020-02-20T17:22:17Z""
";https://scholar.google.com/scholar?start=340&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095295-1244;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;[HTML][HTML] What's holding back blockchain finance? On the possibility of decentralized autonomous finance;C Harwick, J Caton ; The Quarterly Review of Economics and Finance, 2020  Elsevier;;"… We discuss both future institutional developments in the cryptocurrency space, and recent

technical developments … Second, oracles – a technology for introducing trusted data onto the

blockchain for use in DAOs – provide a plausible entry point for the minimal identity …";Cité 6 fois;Les 4 versions;[HTML] sciencedirect.com;https://www.sciencedirect.com/science/article/pii/S1062976920301162?casa_token=Q8LGpwi3c2MAAAAA:RIgU9mD8uhv-i2RgY4UHVpoyr0bjfhzBNVVigHsZR6LIw6-U7E55k3cgOiLsFk7jnfs_qLPS;;;https://scholar.google.com/scholar?start=50&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095371-1583;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Blockchain-Technologie für Unternehmensprozesse;K Adam ; Sinnvolle Anwendung der, 2020  Springer;;"Page 1. Katarina Adam Blockchain- Technologie für Unternehmensprozesse Sinnvolle

Anwendung der neuen Technologie in Unternehmen … Blockchain-Technologie für

Unternehmensprozesse Page 3. Katarina Adam Blockchain- Technologie für …";Cité 4 fois;Les 6 versions;null;;;;https://scholar.google.com/scholar?start=380&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095371-1577;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;A Decentralized Dynamic PKI based on Blockchain;M Toorani, C Gehrmann ; arXiv preprint arXiv:2012.15351, 2020  arxiv.org;;"… Table 1: Comparison between proposals for blockchain-based PKI 1 It can be replaced with more …

Adversary A can adaptively query O.Sign oracle to sign its chosen messages … ? and any stateful

PPT adversary A with black-box access to AccAdd and AccDel oracles which take …";Autres articles;;[PDF] arxiv.org;https://arxiv.org/pdf/2012.15351;;"""date"",""2021-01-01T01:51:09Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2021-01-01T01:51:09Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.21 (TeX Live 2020) kpathsea version 6.3.2""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2021-01-01T01:51:09Z""
""created"",""2021-01-01T01:51:09Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2021-01-01T01:51:09Z""
""resourceName"",""2012.15351""
""Author"",""""
""producer"",""pdfTeX-1.40.21""
""pdf:docinfo:producer"",""pdfTeX-1.40.21""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""2"",""0"",""0"",""0"",""7"",""2"",""5"",""0"",""0"",""0"",""4"",""0"",""0"",""4"",""0"",""0"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2021-01-01T01:51:09Z""
""Last-Modified"",""2021-01-01T01:51:09Z""
""dcterms:modified"",""2021-01-01T01:51:09Z""
""title"",""""
""Last-Save-Date"",""2021-01-01T01:51:09Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2021-01-01T01:51:09Z""
""meta:save-date"",""2021-01-01T01:51:09Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.21 (TeX Live 2020) kpathsea version 6.3.2""
""Content-Length"",""739908""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""19""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""2518"",""3818"",""3452"",""4237"",""2261"",""2173"",""1899"",""1786"",""2864"",""1960"",""2067"",""3426"",""3030"",""2327"",""1852"",""3173"",""3767"",""3571"",""1925""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2021-01-01T01:51:09Z""
";https://scholar.google.com/scholar?start=380&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095358-1515;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;[LIVRE][B] Blockchain Ecosystem. Driving mass adoption;N Attico ;2020 books.google.com;;"… on the blockchain Chapter 21 Browsers and Wallets Chapter 22 Oracles Chapter 23 … The crypto

market has experienced a collapse of the capitalization from 550 billion … Bitcoin —and the

technology supporting it, called blockchain— brings enormous promises and expectations …";Autres articles;;null;;;;https://scholar.google.com/scholar?start=320&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095316-1338;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;[PDF][PDF] Exploring Blockchain Technology to Improve Multi-party Relationship in Business Process Management Systems.;PHC Alves, R Paskin, I Frajhof, YR Miranda, JG Jardim… ; ICEIS (2), 2020  researchgate.net;;"… Page 3. tions, without the need of a central authority to en- force the agreed terms; oracles present

an impor- tant role in this case (Adler et al., 2018) … Adler, J., Berryhill, R., Veneris, A., Poulos, Z.,

Veira, N., and Kastania, A. (2018). Astraea: A decen- tralized blockchain oracle …";Cité 2 fois;;[PDF] researchgate.net;https://www.researchgate.net/profile/Paulo_Alves46/publication/340032919_Exploring_Blockchain_Technology_to_Improve_Multi-Party_Relationship_in_Business_Process_Management_Systems/links/5eb4319992851cbf7fafe097/Exploring-Blockchain-Technology-to-Improve-Multi-Party-Relationship-in-Business-Process-Management-Systems.pdf;;;https://scholar.google.com/scholar?start=140&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095311-1321;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;[HTML][HTML] Blockchain and smart contracts in supply chain management: A game theoretic model;P De Giovanni ; International Journal of Production Economics, 2020  Elsevier;;"… Blockchain and smart contracts in supply chain management: A game theoretic model … Smart

contracts guarantee better performance than the sole Blockchain. Abstract. This paper proposes

a supply chain game that is composed of two firms, one supplier and one retailer …";Cité 13 fois;Les 6 versions;[HTML] sciencedirect.com;https://www.sciencedirect.com/science/article/pii/S0925527320302188?casa_token=q8LxIadtFrkAAAAA:otmL_7yVGbPCeSNbO-_CtArgugEBGd2SqznVUN5uApFEumUJHMVQoBu2sAso5eBEeVvebfWk;;;https://scholar.google.com/scholar?start=120&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095390-1656;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;[PDF][PDF] Eine kurze Geschichte der Blockchain Ursprünge, Begriffe und aktuelle Entwicklungen;DS der richtigen Worte ; researchgate.net;;"… Die Quellen solcher Echtwelt-Informationen werden Oracles genannt. pragma solidity ^0.5.0; …

Definition Oracle: Dienst, der Echtwelt-Daten der Blockchain zur Verfügung stellt … 7. Dutch

Blockchain Coalition: Blockchain - Blockchain (en), https://dutchblockchaincoalition.org/en …";Autres articles;Version HTML;[PDF] researchgate.net;https://www.researchgate.net/profile/Volker_Skwarek/publication/333284577_Eine_kurze_Geschichte_der_Blockchain_Ursprunge_Begriffe_und_aktuelle_Entwicklungen/links/5eb3ab37299bf152d6a1d62e/Eine-kurze-Geschichte-der-Blockchain-Urspruenge-Begriffe-und-aktuelle-Entwicklungen.pdf;;;https://scholar.google.com/scholar?start=460&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095320-1358;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;A Blockchain-Based Proxy Re-Encryption with Equality Test for Vehicular Communication Systems;B Chen, D He, N Kumar, H Wang… ; IEEE Transactions on …, 2020  ieeexplore.ieee.org;;"… 6, NO. 1, JANUARY 2007 1 A Blockchain-Based Proxy Re-Encryption with Equality Test for

Vehicular Communication Systems … In this paper, we introduce a new cryptographic primitive,

namely: blockchain-based proxy re-encryption with equality test …";Cité 2 fois;Les 3 versions;[PDF] profsandhu.com;https://profsandhu.com/cspecc_publications/2020/A_Blockchain-Based_Proxy_Re-Encryption_w_Equality_Test_for_Vehicular_Communication_Systems.pdf;;"""date"",""2020-06-02T20:51:44Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""A Blockchain-Based Proxy Re-Encryption with Equality Test for Vehicular Communication Systems""
""xmp:CreatorTool"",""Appligent AppendPDF Pro 5.5""
""Appligent"",""AppendPDF Pro 5.5 Linux Kernel 2.6 64bit Oct  2 2014 Library 10.1.0""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""IEEE Transactions on Network Science and Engineering; ;PP;99;10.1109/TNSE.2020.2999551""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""Appligent AppendPDF Pro 5.5""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""A Blockchain-Based Proxy Re-Encryption with Equality Test for Vehicular Communication Systems""
""modified"",""2020-06-02T20:51:44Z""
""cp:subject"",""IEEE Transactions on Network Science and Engineering; ;PP;99;10.1109/TNSE.2020.2999551""
""pdf:docinfo:subject"",""IEEE Transactions on Network Science and Engineering; ;PP;99;10.1109/TNSE.2020.2999551""
""pdf:hasMarkedContent"",""false""
""xmp:ModifyDate"",""2020-06-02T16:51:44Z""
""meta:creation-date"",""2020-06-02T08:49:41Z""
""created"",""2020-06-02T08:49:41Z""
""pdf:docinfo:custom:IEEE Publication ID"",""6488902""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-06-02T08:49:41Z""
""resourceName"",""A_Blockchain-Based_Proxy_Re-Encryption_w_Equality_Test_for_Vehicular_Communication_Systems.pdf""
""producer"",""pdfTeX-1.40.20; modified using iTextŽ 5.5.6 Š2000-2015 iText Group NV (AGPL-version)""
""pdf:docinfo:producer"",""pdfTeX-1.40.20; modified using iTextŽ 5.5.6 Š2000-2015 iText Group NV (AGPL-version)""
""IEEE Publication ID"",""6488902""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""7"",""4"",""0"",""0"",""3"",""0"",""8"",""0"",""0"",""0"",""0""
""dc:description"",""IEEE Transactions on Network Science and Engineering; ;PP;99;10.1109/TNSE.2020.2999551""
""access_permission:modify_annotations"",""true""
""description"",""IEEE Transactions on Network Science and Engineering; ;PP;99;10.1109/TNSE.2020.2999551""
""dcterms:created"",""2020-06-02T08:49:41Z""
""Last-Modified"",""2020-06-02T20:51:44Z""
""dcterms:modified"",""2020-06-02T20:51:44Z""
""pdf:docinfo:custom:Appligent"",""AppendPDF Pro 5.5 Linux Kernel 2.6 64bit Oct  2 2014 Library 10.1.0""
""title"",""A Blockchain-Based Proxy Re-Encryption with Equality Test for Vehicular Communication Systems""
""Last-Save-Date"",""2020-06-02T20:51:44Z""
""IEEE Article ID"",""9106844""
""pdf:docinfo:modified"",""2020-06-02T20:51:44Z""
""meta:save-date"",""2020-06-02T20:51:44Z""
""pdf:docinfo:custom:IEEE Article ID"",""9106844""
""Content-Length"",""821319""
""pdf:docinfo:custom:IEEE Issue ID"",""6930788""
""Content-Type"",""application/pdf""
""xmp:MetadataDate"",""2020-06-02T16:51:44Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""pdf:producer"",""pdfTeX-1.40.20; modified using iTextŽ 5.5.6 Š2000-2015 iText Group NV (AGPL-version)""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""13""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""5244"",""6011"",""4117"",""5599"",""5046"",""3821"",""4057"",""5129"",""4807"",""2800"",""5215"",""10969"",""2501""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-06-02T08:49:41Z""
""IEEE Issue ID"",""6930788""
";https://scholar.google.com/scholar?start=160&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095290-1230;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;A smart contract oracle for approximating real-world, real number values;W George, C Lesaege ; International Conference on Blockchain …, 2020  drops.dagstuhl.de;;"A key challenge of smart contract systems is the fact that many useful contracts require 
access to information that does not natively live on the blockchain. While miners can verify 
the value of a hash or the validity of a digital signature, they cannot determine who won an …";Cité 2 fois;Les 3 versions;[PDF] dagstuhl.de;https://drops.dagstuhl.de/opus/volltexte/2020/11970/pdf/OASIcs-Tokenomics-2019-6.pdf;;"""date"",""2019-10-29T08:17:26Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""A Smart Contract Oracle for Approximating Real-World, Real Number Values""
""xmp:CreatorTool"",""LaTeX with oasics-v2019.cls and hyperref.sty""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""OASIcs, Vol.71, Tokenomics 2019; Copyright (C) William George and ClĂŠment Lesaege; licensed under Creative Commons License CC-BY""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with oasics-v2019.cls and hyperref.sty""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""A Smart Contract Oracle for Approximating Real-World, Real Number Values""
""modified"",""2019-10-29T08:17:26Z""
""cp:subject"",""OASIcs, Vol.71, Tokenomics 2019; Copyright (C) William George and ClĂŠment Lesaege; licensed under Creative Commons License CC-BY""
""pdf:docinfo:subject"",""OASIcs, Vol.71, Tokenomics 2019; Copyright (C) William George and ClĂŠment Lesaege; licensed under Creative Commons License CC-BY""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""William George, ClĂŠment Lesaege""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.20 (TeX Live 2019) kpathsea version 6.3.1""
""meta:author"",""William George, ClĂŠment Lesaege""
""trapped"",""False""
""meta:creation-date"",""2019-10-29T08:17:26Z""
""created"",""2019-10-29T08:17:26Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-10-29T08:17:26Z""
""resourceName"",""OASIcs-Tokenomics-2019-6.pdf""
""Author"",""William George, ClĂŠment Lesaege""
""producer"",""pdfTeX-1.40.20""
""pdf:docinfo:producer"",""pdfTeX-1.40.20""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""1"",""3"",""7"",""2"",""8"",""3"",""6"",""26"",""3"",""40"",""31"",""0""
""Keywords"",""price oracle, Ethereum, blockchain""
""access_permission:modify_annotations"",""true""
""dc:creator"",""William George, ClĂŠment Lesaege""
""dcterms:created"",""2019-10-29T08:17:26Z""
""Last-Modified"",""2019-10-29T08:17:26Z""
""dcterms:modified"",""2019-10-29T08:17:26Z""
""title"",""A Smart Contract Oracle for Approximating Real-World, Real Number Values""
""Last-Save-Date"",""2019-10-29T08:17:26Z""
""pdf:docinfo:keywords"",""price oracle, Ethereum, blockchain""
""pdf:docinfo:modified"",""2019-10-29T08:17:26Z""
""meta:save-date"",""2019-10-29T08:17:26Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.20 (TeX Live 2019) kpathsea version 6.3.1""
""Content-Length"",""537238""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""William George, ClĂŠment Lesaege""
""dc:subject"",""price oracle, Ethereum, blockchain""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""15""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""3029"",""3581"",""3182"",""3160"",""2852"",""1600"",""2124"",""2634"",""3058"",""2692"",""2448"",""2843"",""3174"",""2018"",""2648""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""price oracle, Ethereum, blockchain""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-10-29T08:17:26Z""
";https://scholar.google.com/scholar?start=30&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095332-1406;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Toward trust in Internet of Things ecosystems: Design principles for blockchain-based IoT applications;J Lockl, V Schlatt, A Schweizer… ; IEEE Transactions on …, 2020  ieeexplore.ieee.org;;"… B. Blockchain and Smart Contracts The concept of blockchain first emerged as the technology

behind the cryptocurrency Bitcoin in 2008 [15]. Various incum- bent organizations, as well as

emerging startups, are exploring blockchain in a multitude of use cases by now [39] …";Cité 9 fois;Les 5 versions;[PDF] researchgate.net;https://www.researchgate.net/profile/Jannik_Lockl/publication/340398234_Toward_Trust_in_Internet_of_Things_IoT_Ecosystems_Design_Principles_for_Blockchain-Based_IoT_Applications/links/5e8701ba299bf130797498ac/Toward-Trust-in-Internet-of-Things-IoT-Ecosystems-Design-Principles-for-Blockchain-Based-IoT-Applications.pdf;;;https://scholar.google.com/scholar?start=210&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095311-1319;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Blockchain and real estate: Dopo di Noi project;M Morena, T Truppi, AS Pavesi, G Cia… ; Property …, 2020  emerald.com;;"Page 1. Blockchain and real estate: Dopo di Noi project … Introduction Since the release of the

seminal Bitcoin white paper (Nakamoto, 2018), there has been a growing interest about the

blockchain technology, the layer which underlies cryptocurrencies …";Cité 3 fois;Les 3 versions;[PDF] emerald.com;https://www.emerald.com/insight/content/doi/10.1108/PM-01-2019-0005/full/pdf;;"""date"",""2021-01-13T03:10:30Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""3"",""0"",""0"",""1"",""3"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""1"",""0""
""pdf:PDFVersion"",""1.4""
""pdf:docinfo:title"",""PM-01-2019-0005_proof 273..295""
""xmp:CreatorTool"",""""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""language"",""en""
""dcterms:created"",""2021-01-13T03:10:30Z""
""Last-Modified"",""2021-01-13T03:10:30Z""
""dcterms:modified"",""2021-01-13T03:10:30Z""
""dc:format"",""application/pdf; version=1.4""
""title"",""PM-01-2019-0005_proof 273..295""
""xmpMM:DocumentID"",""uuid:1d686180-bab3-46e8-a025-08d707e54534""
""Last-Save-Date"",""2021-01-13T03:10:30Z""
""pdf:docinfo:creator_tool"",""""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2021-01-13T03:10:30Z""
""meta:save-date"",""2021-01-13T03:10:30Z""
""pdf:encrypted"",""false""
""dc:title"",""PM-01-2019-0005_proof 273..295""
""xmp:CreateDate"",""2021-01-13T08:40:30Z""
""modified"",""2021-01-13T03:10:30Z""
""pdf:hasMarkedContent"",""true""
""Content-Type"",""application/pdf""
""xmp:ModifyDate"",""2021-01-13T08:40:30Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""dc:language"",""en""
""pdf:producer"",""Acrobat Distiller 19.0 (Windows)""
""meta:creation-date"",""2021-01-13T03:10:30Z""
""created"",""2021-01-13T03:10:30Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""23""
""Creation-Date"",""2021-01-13T03:10:30Z""
""resourceName"",""pdf""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""3427"",""2359"",""2930"",""3202"",""2082"",""1878"",""436"",""2161"",""2965"",""2544"",""2673"",""3156"",""1894"",""2219"",""2180"",""695"",""2551"",""3445"",""633"",""1984"",""3125"",""3288"",""2708""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""producer"",""Acrobat Distiller 19.0 (Windows)""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""Acrobat Distiller 19.0 (Windows)""
""pdf:docinfo:created"",""2021-01-13T03:10:30Z""
";https://scholar.google.com/scholar?start=120&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095388-1646;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Review of Techniques for Privacy-Preserving Blockchain Systems;A Satybaldy, M Nowostawski ; … International Symposium on Blockchain …, 2020  dl.acm.org;;"… deal with these challenges, novel privacy-preserving solu- tions based on crypto-privacy

techniques … The use of ring signatures to conceal the origin of a blockchain transaction was … most

successful im- plementation of this approach to date is the cryptocurrency named Monero …";Cité 1 fois;;null;;;;https://scholar.google.com/scholar?start=450&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095353-1501;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;A Self-Evolving Design of Blockchain-based Open Source Community;A Qayum, A Razzaq ; 2020 3rd International Conference on …, 2020  ieeexplore.ieee.org;;"… Blockchains will be integrated with fully-trustless, truly-transparent and censorship-resistant VCSs

and oracles which will allow the integration of high volume of data (also with logic) to deal with

the scalability issue of Blockchains, without interrupting the Blockchain true spirit of …";Cité 1 fois;;null;;;;https://scholar.google.com/scholar?start=300&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095376-1598;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;[PDF][PDF] Blockchain: The India Strategy;N Aayog ;2020 14.139.58.147;;"… quite representative of the truly unique nature of blockchain or Distributed Ledger Technology

(DLT) based systems. Zooming out of the cryptocurrency lens, we can see how these fundamental

characteristics translate into generic features: Figure 2: Features of blockchains …";Cité 1 fois;Version HTML;[PDF] 14.139.58.147;http://14.139.58.147:8080/jspui/bitstream/123456789/1760/1/Blockchain_The_India_Strategy_Part_I.pdf;;"""date"",""2020-01-31T06:38:07Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.3""
""pdf:docinfo:title"",""Blockchain The India Strategy Part I""
""xmp:CreatorTool"",""Word""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dc:creator"",""Arnab Kumar""
""dcterms:created"",""2020-01-31T06:38:07Z""
""language"",""en""
""Last-Modified"",""2020-01-31T06:38:07Z""
""dcterms:modified"",""2020-01-31T06:38:07Z""
""dc:format"",""application/pdf; version=1.3""
""title"",""Blockchain The India Strategy Part I""
""Last-Save-Date"",""2020-01-31T06:38:07Z""
""pdf:docinfo:creator_tool"",""Word""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2020-01-31T06:38:07Z""
""meta:save-date"",""2020-01-31T06:38:07Z""
""pdf:encrypted"",""false""
""dc:title"",""Blockchain The India Strategy Part I""
""modified"",""2020-01-31T06:38:07Z""
""Content-Length"",""5106099""
""pdf:hasMarkedContent"",""false""
""Content-Type"",""application/pdf""
""pdf:docinfo:creator"",""Arnab Kumar""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Arnab Kumar""
""meta:author"",""Arnab Kumar""
""meta:creation-date"",""2020-01-31T06:38:07Z""
""created"",""2020-01-31T06:38:07Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""59""
""Creation-Date"",""2020-01-31T06:38:07Z""
""resourceName"",""Blockchain_The_India_Strategy_Part_I.pdf""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""1"",""129"",""454"",""291"",""2291"",""3025"",""305"",""3036"",""3118"",""3062"",""2700"",""1976"",""2400"",""3495"",""3093"",""3254"",""3019"",""2008"",""3134"",""1910"",""3198"",""2811"",""1446"",""2244"",""118"",""2926"",""3277"",""3115"",""3390"",""2978"",""2879"",""2836"",""1729"",""2726"",""2965"",""1388"",""2895"",""1840"",""1262"",""875"",""2670"",""1699"",""2970"",""2810"",""3025"",""2319"",""2567"",""2871"",""3021"",""2863"",""1825"",""1480"",""1722"",""2592"",""1874"",""2720"",""2373"",""1918"",""1288""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""Author"",""Arnab Kumar""
""producer"",""macOS Version 10.15.2 (Build 19C57) Quartz PDFContext""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""macOS Version 10.15.2 (Build 19C57) Quartz PDFContext""
""pdf:docinfo:created"",""2020-01-31T06:38:07Z""
";https://scholar.google.com/scholar?start=400&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095399-1694;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Blockchain in Aotearoa;K Jenkins ; Policy Quarterly, 2020  ojs.victoria.ac.nz;;"… for real-world money, leading him to focus on blockchain and cryptocurrency in almost … the Financial

Markets Authority) 'with a high degree of literacy about crypto-exchanges and a … The revolutionary

content attributed to blockchain technology, and exemplified by bitcoin, is that it …";Les 2 versions;Version HTML;[PDF] victoria.ac.nz;https://ojs.victoria.ac.nz/pq/article/download/6483/5631;"
Policy Quarterly – Volume 16, Issue 2 – May 2020 – Page 57

Abstract 
Blockchain technology has been moving beyond cryptocurrency 

into new areas internationally, with substantial investment from 

both the private sector and government, including private sector 

projects in Aotearoa. However, there is not yet clear evidence of 

successful use cases at scale. The technology offers important 

benefits through creating tamper-proof records of transactions, 

and major drawbacks of public networks like bitcoin, such as 

massive power consumption, do not seem to apply to regulatory 

uses based on private blockchain networks. But there is debate 

over whether the technology is as secure as its proponents claim. In 

exploring blockchain’s potential, regulatory designers will want to 

carefully consider more conventional alternatives such as distributed 

databases.

Keywords blockchain, distributed ledger, trust, regulatory design

Kevin Jenkins

Blockchain  
in Aotearoa  
are distributed ledgers  
the future for our regulators 
and policymakers?

Kevin Jenkins is a founder of professional services firm MartinJenkins. 

Blockchain technology – the best-
known type of ‘distributed ledger 
technology’, or DLT – is a complex 

and very fast-moving phenomenon 
that has seen large investments from 
government and industry around the 
world, including in Aotearoa. There is 
a mass of commentary and reporting, 
and frequent announcements of new 
blockchain projects or pilots.

This article presents the results of my 
efforts, as a layperson interested in the 
interface between technological innovation 
and regulation, to find my bearings in the 
blockchain landscape, to canvass some of 
the often wildly diverging views, and to 
identify relevant questions for regulatory 
designers to ask in evaluating the 
technology’s potential. 

Just cryptocurrency – or a whole world of 

potential uses?

The OECD has recently declared that 
‘Blockchain technology has evolved 
from a niche subject to the hottest tech 
disruption buzzword’ (Berryhill, Bourgery 



Page 58 – Policy Quarterly – Volume 16, Issue 2 – May 2020

and Hanson, 2018). But the debates and 
commentary in this area indicate that the 
blockchain industry is facing two possible 
futures. 

One future sees blockchain technology 
as entwined with bitcoin, the cryptocurrency 
it was designed to enable, and with which 
the technology was packaged when it was 
first released into the world. Saifedean 
Ammous, for example, a US economics 
professor, scoffs at the idea of blockchain 
offering much beyond bitcoin:

There is no reason, except for ignorance 
of its mechanics, to expect that it would 
be suited for other functions ... 
Blockchain is better understood as an 
integral cog in the machine that creates 
peer-to-peer electronic cash with 
predictable inflation. (Ammous, 2018, 
p.272)

The other camp sees cryptocurrency as 
simply the foundation use-case, with many 
more in play or shortly about to be. This 
camp says we are only scratching the 
surface of the benefits that blockchain 
technology can offer for business, 
government and citizens in general. For 
regulatory systems specifically, it is 
supposed to offer greater effectiveness in 
the form of better security and accuracy, 
and also greater efficiency and economy. 

So how is this going to play out, 
including in Aotearoa? A recent report 
published by the Callaghan Institute, by 
Joshua Vial of Enspiral, clearly takes the 
second, more expansive view. Vial argues 
that ‘Distributed ledgers and blockchains 

are emerging general purpose technologies 
that are likely to have a significant impact 
across all aspects of the economy’ (Vial, 
2018). He argues that in Aotearoa we need 
a more blockchain-friendly economic and 
regulatory environment.

Vial’s strong statement suggests that 
this projected blockchain revolution may 
be as exciting and comprehensive as, say, 
the personal computer revolution of the 
1980s, where, whatever you and your 
business or agency were doing, putting a 
computer on your desk was pretty much 
guaranteed to mean you’d be doing your 
work more quickly, more accurately or 
more cheaply, or all three, with significant 
gains in productivity. 

But there have been warnings out there 
that that great promise is still mostly just 
a promise. The McKinsey consulting firm 
wrote at the start of 2019:

A particular concern, given the amount 
of money and time spent, is that little 
of substance has been achieved. Of the 
many use cases, a large number are still 
at the idea stage, while others are in 
development but with no output. The 
bottom line is that despite billions of 
dollars of investment, and nearly as 
many headlines, evidence for a practical 
scalable use for blockchain is thin on 
the ground. (Higginson, Nadeau and 
Rajgopal, 2019)

Early moves beyond cryptocurrency: 

Ethereum’s ‘smart contracts’

Vitalik Buterin is the legendary founder of 
the blockchain-based platform Ethereum, 

usually second or third to bitcoin for 
cryptocurrency market cap. Some have 
suggested he’s part-robot, but he seemed 
like a super-bright, driven, but still very 
much human entrepreneurial geek when 
I saw him speak in Wellington in 2017. 

Ethereum is an early example of using 
blockchain technology for more than 
cryptocurrency. Descriptions can get pretty 
complicated quickly, but Blockchain 
Revolution, by father-and-son team Don 
and Alex Tapscott, and the biggest selling 
blockchain book so far, usefully explains 
the difference between the platform, the 
application and the currency (which is 
called Ether):

Ethereum is a platform technology, 
designed from the outset to enable 
distributed applications (DApps) … At 
the core of distributed applications are 
smart contracts, software that mimics 
the logic of a business agreement. … 
they minimize the need for 
intermediaries (banks, brokers, lawyers, 
courts … ). If Ethereum is the city grid, 
and the DApp is the car, then ether is 
the fuel. (Tapscott and Tapscott, 2016, 
pp.xxxii–iii)

Ethereum’s ‘smart contracts’ offer the 
prospect of extending the benefits of 
blockchain technology beyond 
cryptocurrency afficionados to cover a vast 
range of contractual transactions in 
everyday commercial and personal life. 
They are supposed to be self-executing and 
self-enforcing, so that, for example, 
payment is triggered automatically when 

Figure 1: Blockchain in the context of successive digital revolutions

Source: graphic by Lan Fu, MartinJenkins

Blockchain in Aotearoa: are distributed ledgers the future for our regulators and policymakers?



Policy Quarterly – Volume 16, Issue 2 – May 2020 – Page 59

certain conditions are met. A better name 
for them may, however, be ‘dumb contracts’, 
as they essentially just work their way 
through a series of binary yes–no options 
to reach a conclusion based on the relevant 
value at each option point. They have been 
criticised as too inflexible to handle the 
nuances and unforeseen circumstances that 
make up much of the real life of contractual 
arrangements and disputes (Notland, 
2019). But like bitcoin and other blockchain 
cryptocurrencies, they offer the benefit of 
a tamper-proof transaction record and 
eliminate the need for third parties and the 
costs that they entail. 

‘Blockchain 3.0’ – the next digital revolution?

Melanie Swan, discussing the pattern of 
the last half century of a digital revolution 
every decade, places blockchain and 
smart contracts in the ‘connected world’ 
revolution of the 2010s (Swan, 2015). She 
argues that blockchain represents a whole 
new layer of the internet that facilitates 
value transactions. 

Swan talks of three blockchain stages. 
Blockchain 1.0 has been bitcoin and other 
cryptocurrencies. Blockchain 2.0 has been 
the extension of blockchain into ‘smart 
contracts’ along Ethereum lines: for 
example, for transactions involving land 
title, shares and mortgages. What’s up next, 
she says, is Blockchain 3.0, involving the 
application of the technology to completely 
different sectors, such as government, 
health and art. 

As the title of their Blockchain 
Revolution gives away, the Tapscotts join 
Melanie Swan in the broad revolutionary 
camp, where blockchain steamrolls into 
new sectors. They call blockchain the 

‘Internet of Value’. In their eyes what we call 
the internet is really just the ‘Internet of 
Information’ because all it does is move 
information – copies of documents, photos, 
audio – from person to person. They see 
blockchain as revolutionary because it is 
disruptive of at least seven domains. 
Financial services is familiar, but they also 
cite the design of firms, business models, 
the Internet of Things, economic inclusion, 
government and democracy, and the 
creative industries. 

Putting those disruptions together, they 
are saying the world will be remarkably 
different – and better – in less than a 

generation because of blockchain. Key to 
these changes is radical decentralisation, 
and also a move to most transactions being 
between things (through the use of smart 
infrastructure and devices), not people. 

From Estonia to Uttar Pradesh,  

DLT projects abound 

There have been plenty of signs of 
movement into the Blockchain 3.0 zone, 
from both government and the private 
sector, often in partnership. 

Estonia has been an early leader in 
government adoption of distributed ledger 
technology, as it has in digital government 
generally, and began experimenting early 
on with a locally developed form of DLT 
called ‘keyless signature infrastructure’ (UK 
Government Chief Science Advisor, 2016). 
It has been making use of distributed ledger 
technology in a number of areas, including 
identity management and health records 
(Halim, 2019; Shen, 2016).  

Dubai is another governmental leader 
in the use of distributed ledgers. Its Dubai 
Blockchain Strategy set the bold target of 
making Dubai ‘the first city fully powered 
by Blockchain by 2020’. In January 2020 it 
reported it had succeeded in implementing 
24 applicable use cases, including 
establishing a shared platform that 
government agencies could use to 
implement use cases rather than having to 
invest in individual platforms (Smart 
Dubai Department, 2020). Fully 
implemented use cases include verification 
of property titles, the issuing of university 
certificates, the licensing of healthcare 

specialists, and requesting a certificate of 
loss of passport. 

It is difficult to keep up with the 
announcements of new blockchain or DLT 
projects internationally – which are, 
however, frequently only pilots and proof 
of concept exercises. Blockchain has been 
discussed as particularly well suited to the 
transactions of ‘prosumers’ in areas such 
as peer-to-peer home-generated solar 
power that is fed into electricity grids. At 
the end of 2019, a new pilot along those 

lines was announced for the Indian state 
of Uttar Pradesh, which, with just over 200 
million people, is the largest sub-country 
political entity in the world. The pilot 
involves two state-owned power utilities 
partnering with an Australian energy 
blockchain company, Power Ledger. This 
is Power Ledger’s second such pilot in India, 
adding to a project in New Delhi, but the 
new project is significant in that Uttar 
Pradesh would be the first Indian state to 
amend its regulatory framework to allow 
peer-to-peer energy trading (India Times, 
2019; Lewis, 2019).

… and on to Christchurch

Consistent with our membership of the D9 
group of advanced digital nations, which 
includes Estonia, the United Kingdom, 
South Korea, Israel and others, New Zealand 
has seen a lot of activity and investment in 
blockchain technology, though not yet any 
government applications. 

Centrality (https://centrality.ai/) is a 
marketplace for decentralised apps (dApps) 
for software developers that is incubating 

Consistent with our membership of the 
D9 group of advanced digital nations, 
which includes Estonia, the United 
Kingdom, South Korea, Israel and 
others, New Zealand has seen a lot of 
activity and investment in blockchain 
technology, though not yet any 
government applications. 



Page 60 – Policy Quarterly – Volume 16, Issue 2 – May 2020

blockchain companies. TrackBack, for 
example, completed a proof of concept to 
track mänuka honey from New Zealand to 
Shanghai. TrackBack worked with 
AsureQuality, New Zealand Post and a 
producer to tackle the fake mänuka honey 
trade. 

Techemy (https://techemy.co/) is a New 
Zealand-based community of blockchain 
companies that invests, owns and develops 
companies ‘at every stage of the blockchain 
value chain’. Joshua Vial’s New Zealand 
report tells how Amazon’s Alexa uses data 
supplied by Brave New Coin (https://
bravenewcoin.com/), launched by Techemy, 

to answer questions about the price of 
bitcoin. Another Techemy investment is 
Sphere Identity (www.sphereidentity.com), 
which is working to offer self-sovereign 
identity so we consumers can control our 
own personal data, while removing the 
painful issues around online forms and 
abandonment rates. Other  companies 
working on sovereign identity in New 
Zealand include SingleSource (www.
mysinglesource.io), which partnered with 
Auckland company Delta Insurance 
(https://deltainsurance.co.nz/) to provide 
a decentralised blockchain identity system.    

Joshua Vial cites other examples of 
blockchain start-ups in Aotearoa. Axia 
Labs is a global blockchain company 
founded in Christchurch in 2017 by 
political science and philosophy graduate 
James Waugh. In 2013 he learnt to use 
cryptocurrency to avoid PayPal charges 
when he sold in-game items for real-world 
money, leading him to focus on blockchain 
and cryptocurrency in almost all of his free 
time since. 

Axia Labs is focused on ‘building a 
more equitable economy’ and, in practice, 
they provide top-down advice and help 

leaders and innovators connect more 
deeply with the blockchain ecosystem. Axia 
has worked with a wide range of 
international clients, including institutional 
corporations, universities, enterprise 
companies and numerous tokenisation 
projects. Zeroing in on token economics, 
decentralised architecture and industry 
best practices, a large portion of Axia’s time 
has been spent in Silicon Valley and 
London, focusing on the global market.

We are attracting blockchain 
entrepreneurs from overseas too. Here’s 
Vial again:

They include the co-founder of 
Coinbase (the first billion dollar 
blockchain company), the co-founder 
of Augur (one of the first Ethereum 
initial coin offerings) and the head of 
innovation at UNICEF who has 
launched an impact-driven blockchain 
investment fund.

His report also talks about how 
Stronghold (https://stronghold.co), an 
exchange focused on the Stellar platform 
(www.stellar.org), was attracted to Aotearoa 
because we have a single regulator (the 
Financial Markets Authority) ‘with a high 
degree of literacy about crypto-exchanges 
and a willingness to engage’. 

Transacting securely without the need for 

trust: does the technology deliver on the 

promise?

The revolutionary content attributed to 
blockchain technology, and exemplified 
by bitcoin, is that it addresses the core 
problem of trust. For example, we can’t 
safely send money through the post, 
so instead we work through trusted 
intermediaries like payment companies, 

banks and governments. Blockchain 
allows value – either digital cash or other 
digital artefacts with monetary value – to 
be transmitted safely. 

Some call it ‘the trust machine’ 
(Berryhill, Bourgery and Hanson, 2018). 
But more accurately, as Saifedean Ammous 
explains, it takes the need for trust out of 
the equation altogether: that is, the code is 
transparent, and any change is also 
transparent and needs to be agreed by a 
majority of those involved (Ammous, 
2018). So it’s a trustless set-up, but in a 
completely benign way.

That said, there are some obvious limits 
to security without a trusted central 
authority. If you’re a bitcoin user-owner, 
no one can mess with your bitcoin because 
you have your own private digital key, but 
if you forget or lose your key then of course 
you can’t mess with your bitcoin either. 
With conventional banking, losing your 
bankcard or forgetting a password is likely 
to cost you only some time and 
inconvenience. But it’s different with 
bitcoin, as John Lanchester notes: 

the unforgiving power of the public 
address/private key combination has 
also seen 7500 bitcoin lost under a 
landfill outside Newport in Wales, 
when an IT worker chucked out an old 
hard drive on which he had stored the 
private keys from his 2009 bitcoin stash. 
Current value of loss: ÂŁ2.1 million. 
(Lanchester, 2016)

Kai Stinchcombe represents a fairly 
extreme view among blockchain detractors 
of the downsides of removing the security 
offered in the form of banks and other 
traditional trusted intermediaries. Phrases 
like ‘crap technology’ and ‘medieval 
hellhole’ give you a flavour of his polemic. 
He argues that our current trust-based 
systems more or less work, and that the 
trustless bitcoin system is just what banking 
looked like 800 years ago in Europe: 

with weak governments unable to 
enforce laws and trusted counterparties 
few, fragile and far between – theft was 
rampant, safe banking was a fantasy, 
and personal security was at the point 
of the sword. This is … what it looks 
like to transact on the blockchain in the 

If you’re a bitcoin user-owner, no one can 
mess with your bitcoin because you have 
your own private digital key, but if you 
forget or lose your key then of course you 
can’t mess with your bitcoin either.

Blockchain in Aotearoa: are distributed ledgers the future for our regulators and policymakers?



Policy Quarterly – Volume 16, Issue 2 – May 2020 – Page 61

ideal scenario. (Stinchcombe, 2018; 
emphasis in original) 

But can I trust the technology?

Worries about lost bitcoin keys aside, there 
may be a more fundamental, more ‘meta’, 
objection to the claim that blockchain 
technology provides security without any 
need for human trust. 

The blockchain evangelists argue that 
the beauty of the technology is that it 
provides security without the need to trust 
in the honesty or integrity of any humans 
or social institutions. But of course you do 
need to trust in the integrity of the 
technology itself. And so what if you can’t? 
Or more precisely – how do you know if 
you can or not? 

Saifedean Ammous has criticised the 
Ethereum platform because, he argues, it 
suffered a fork – a splitting of the single 
indisputable record into two versions. He 
says that, to solve their (alleged) fork 
problem, Ethereum developers had to 
create a new version of the record and 
carry on as if ‘this inconvenient mistake 
never occurred’. Ammous says: ‘This re-
injection of  subjective human 
management is at odds with the objective 
of making code into law, and questions 
the entire rationale of smart contracts.’ 
Bitcoin/blockchain expert Jimmy Song 
generally agrees. He claims Ethereum has 
suffered at least five forks, and that each 
time ‘They’ve bailed out bad decision 
making’ – that is, they’ve exercised central 
authority. ‘By any measure’, Song 
concludes, ‘Ethereum is centrally 
controlled’ (Song, 2018).

When I heard Ethereum’s Buterin speak 
in New Zealand in 2017, he denied it was 
a fork, and at that point the debate got too 
technical for me to follow. But reflecting 
on this later, I wondered if my inability to 
follow the blockchain story at this point 
was more than just a research problem and 
was in fact part of the story, with me as a 
representative of the non-expert billions. 

As a layperson, what am I to do when 
the experts disagree about whether one or 
other blockchain platform has suffered a 
fork, which is nothing less than a disastrous 
breakdown of the whole system? Which 
expert do I listen to on this? Do I ask which 
institution they might be attached to, and 
then ask about that institution’s reputation 

and credibility? In other words, which 
expert do I … trust? 

It’s interesting that in practice most 
bitcoin users access this market through 
intermediaries anyway – cryptocurrency 
exchanges – although perhaps more for 
convenience than security. Rather than 
working out how to download the platform 
software and establish themselves as a 
blockchain node (all quite doable, depending 
on your digital competence and access to a 
suitable computer, but of course most likely 
time-consuming), the typical bitcoin 
transactor chooses to go through an exchange 
and buy or sell bitcoin through them. 

Needless to say, one of your first questions 
in deciding to approach a cryptocurrency 
exchange will be which of these intermediaries 
you should trust. It’s not an unimportant 
question, as shown by the hack of the Japan-
based Mt Gox exchange in 2014. Mt Gox was, 
by 2013, the biggest and most well-known 
exchange handling bitcoin, dealing with 70% 
of all transactions. In early 2014 the exchange 
shut down after losing 850,000 bitcoin to 
hackers, a loss valued at US$450 million at 
the time, but at US$8.5 billion by 2019 
(Baydakova, 2019). 

Mt Gox is not an isolated story. 
According to Reuters, 

There have been at least three dozen 
heists of cryptocurrency exchanges 
since 2011; many of the hacked 
exchanges later shut down. More than 
980,000 bitcoins have been stolen, 
which today [September 2017] would 
be worth about $4 billion.

It described cryptocurrency exchanges 
as having become ‘magnets for fraud and 
mires of technological dysfunction’ 
(Stecklow et al., 2017).

So there seem to me to be questions 
about how successfully blockchain 
technology replaces trust with clever 
software. Put another way, and to refashion 
a story popularised by Stephen Hawking, 
do we really have a trustless pile of turtles 
all the way down, or do we inevitably find 
there’s an inter-human trust relationship 
at the bottom holding the whole edifice up?

As much electricity as a small country

Shift perspective now to that of a 
regulator or policymaker, rather than a 
cryptocurrency user. An early question I had 
about blockchain’s potential relevance for 

government was how the cryptocurrency 
network architecture would translate to 
the world of public sector regulation. The 
short answer appears to be that much of 
it does not, and doesn’t need to, including 
several negative features that might alarm 
regulatory designers. 

For one thing, the bitcoin system is very 
slow at processing transactions: about 
seven per second is the best it can do, 
whereas Visa, for example, handles more 
than 1,500 per second (Berryhill, Bourgery 
and Hanson, 2018, p.33). This is because 
of the time it takes to record transactions 
to a new block and then write the new 
block to the blockchain. So, as a platform 
like bitcoin gets more and more popular 
and the transactions increase, it faces 
problems scaling up.  

The bitcoin network also uses a truly 
horrendous amount of power – in 2018 
reportedly about as much as Ireland 
(Economist, 2018). So there’s an unsettling 
disconnect between bitcoin’s clean, digital 
vibe and all that very real-world energy 
going in to power the banks of bitcoin-
mining computers and the air-conditioning 
needed to stop them overheating. In this 
time of Greta Thunberg and potential global 

... the bitcoin system is very slow at 
processing transactions: about seven per 
second is the best it can do, whereas 
Visa, for example, handles more than 
1,500 per second ...



Page 62 – Policy Quarterly – Volume 16, Issue 2 – May 2020

catastrophe, you can’t help asking: can the 
way ahead – the fully unfolded fourth 
industrial revolution – really look like this?

The good news is that both those 
problems – slow processing and massive 
energy use – are inherent to bitcoin’s public, 
permissionless network model, but not 
inherent to blockchain applications 
generally. It’s all because the computing 
tasks involved in recording and storing the 
data in this open DLT system are deliberately 
made hard. Satoshi Nakamoto – the he, she, 
they or it who designed blockchain and 
bitcoin – set up the writing and storing of 
the blocks that way, using a ‘proof of work’ 
model where bitcoin ‘miners’ expend 
massive computing power to solve artificial 
computing tasks (see Box 1).

By contrast, in a private – or ‘permissioned’ 
.– blockchain network, access is controlled 
and permission to write transaction data to 
the blockchain depends not on proof of work, 
but simply on proof of authority. We can 
assume that all the public sector use cases that 
have been implemented or piloted 
internationally involve private, permissioned 
blockchain networks. Translated to regulatory 
use, writing data in a blockchain network 
established by a government agency would 
depend simply on permission from that 
agency. 

Here, of course, we’re back in the world 
of trusted central authorities underwriting 
the whole system, but still with the advantages 
of a distributed ledger – along with faster 
processing and much lower energy 

consumption. Using a proof of authority 
model, different levels of permission are 
possible, including, for example, permission 
to access and read the information, 
permission to enter data and transactions on 
the system, and top-level authority to edit 
and control access to the network. 

Most important, perhaps, government 
ownership of the network also effectively 
solves the ‘fork’ problem that can arise in 
public networks. The possibility of a fork 
exists precisely because of the open 
democracy of a system like bitcoin, where 
all nodes are equal. 

Blockchain in the public sector – what is it 

good for?

There are detractors, like Kai Stinchcombe, 

Blockchain cryptocurrency technology is a classic example 
of the coming together of several existing technologies to 

produce something revolutionary and disruptive: cryptography, 
online payment processes, game theory and software coding. 

It’s good to get it straight at the outset that ‘blockchain’ is the 
underlying technology and ‘bitcoin’ is a specific platform or use 
case. Blockchain is ‘a digital distributed ledger system that acts as 
an open, shared and trusted record of transactions among parties 
that is not stored by a central authority’ (Berryhill, Bourgery and 
Hanson, 2018). Blockchain is not the only type of distributed 
ledger technology, or DLT, but it’s the best known.

Distribution is key here. All the different users – or ‘nodes’ – 
on the network, such as bitcoin owners: 

hold identical ‘ledgers’ of transactions that are rapidly updated 
any time a new set of transactions is added. This enables a 
key feature of the Blockchain architecture: consensus models 
where nodes in the system confirm the validity of transactions 
that occur on the platform, and flag inappropriate dealings 
when necessary. (ibid.)

Joshua Vial of Enspiral puts it this way:

A distributed ledger is a set of data replicated across many 
networked computers. … [It] uses protocols so changes 
are consistently replicated to each computer and the data 
converges to an agreed known state. (Vial, 2018)

So it’s not that each node – each bitcoin user-owner – holds 
a copy of the ledger, with the accompanying uncertainty that 
a copy might be altered, deliberately or accidentally, and 
diverge from the original. Rather, they all hold the same ledger. 

Disintermediation
Bitcoin is a public distributed ledger system. A buzzword used to 
describe the effect of such a distributed ledger is ‘disintermediation’ 

– that is, the removal of the need for a central authority to act as a 
trusted intermediary and validator when thousands of individuals 
who don’t know each other and have no particular reason to trust 
each other want to transact with each other. Or, as Berryhill et 
al. put it, disintermediation refers to ‘The potential to reduce or 
eliminate the friction and costs of current intermediaries’ (Berryhill, 
Bourgery and Hanson, 2018). 

So there’s no central authority – some large, stable, possibly 
government-backed institution – at the core of the system. But 
it’s also more than merely decentralisation. The point is that 
everyone in the network, every node, is connected to every other 
node at the same time. 

That distinction between decentralisation and distribution was 
key to Paul Baran’s model – now more than half a century old – 
for communications networks, which was immensely influential 
in the design of the internet (see Figure 2).

Two steps: validation plus storage 
There are two critical steps to the bitcoin-blockchain system. First, 
transactions are validated, and here the distributed nature of the 
ledger is key. Validation depends on a majority of all users (or rather 
their automated software) agreeing that a bitcoin transaction is 
valid. (The potential for a nefarious 51% vote to agree to validate 
an invalid transaction is another story.)

It’s the next step – writing and storing the record of the 
validated transaction – where the blockchain itself is key. A ‘block’ 
is an encrypted and unique set of validated transactions. Blocks 
are linked in a ‘chain’ in a way that means the information is 
accessible but cannot be tampered with – that is, it’s essentially 

Box 1 Bitcoin and blockchain: how it works

Blockchain in Aotearoa: are distributed ledgers the future for our regulators and policymakers?



Policy Quarterly – Volume 16, Issue 2 – May 2020 – Page 63

who would presumably reply, ‘Absolutely 
nothing’ here. However, as we have seen 
from the international examples, a lot 
of respectable and presumably careful 
institutions are putting significant 
resources into exploring the potential in 
that ‘Blockchain 3.0’ space projected by 
Melanie Swan, where both private sector 
and governmental actors take blockchain’s 
benefits into completely new fields. 

So, using a proof of authority network 
model under government control, in 
principle what kind of specific regulatory 
uses does it seem blockchain technology 
would be best suited to? 

The OECD report emphasises that the 
technology is useful for validating and 
recording transactions, not for general data 

storage (Berryhill, Bourgery and Hanson, 
2018). This suggests a range of potential 
use cases, such as motor vehicle sales and 
records of land title. In line with that 
transaction focus, the OECD also suggests 
a potential use for smart contracts in 
providing an automated process for 
determining eligibility for government 
services, such as welfare benefits. 

A number of countries have in fact 
already established, or are establishing, 
new land title systems based on blockchain 
networks, including Bermuda, Brazil, the 
UK, Sweden, Russia, Georgia, Ghana and 
Rwanda. The absence of reliable records 
of land ownership is a particularly 
significant problem in developing 
countries (Kriticos, 2019; Kshetri, 2018). 

Fragile paper-based systems are often 
incomplete, and are particularly open to 
error, forgery and official corruption. This 
is a barrier to economic development, as 
without clear title it is difficult to obtain 
finance, and the risk of expropriation 
through fraud and corruption discourages 
owners from developing the land in any 
case. Blockchain solutions can provide 
certainty of title, protect against tampering 
by corrupt officials, and facilitate transfers 
and development, with lower transaction 
costs.

There are some significant barriers, 
however. First, digitising an old paper-
based system is a major undertaking, 
requiring significant investment. Further, 
there are some problems that a blockchain 

Figure 2: Centralised, decentralised and distributed networks 

a list of transactions to which information can only be added. 
That’s why it’s called a chain: the blocks are related to each other 
in a linear sequential order.  

Bitcoin mining: the ‘proof of work’ model
All of the nodes on the bitcoin network are involved in validating 
transactions, but only some of them – called ‘miner’ nodes – are 
involved in storing the transaction records in the ";"""date"",""2020-05-10T23:15:43Z""
""pdf:PDFVersion"",""1.4""
""xmp:CreatorTool"",""Adobe InDesign CS5.5 (7.5.3)""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""xmpMM:History:Action"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved"",""saved""
""language"",""en""
""dc:format"",""application/pdf; version=1.4""
""pdf:docinfo:creator_tool"",""Adobe InDesign CS5.5 (7.5.3)""
""access_permission:fill_in_form"",""true""
""xmpMM:History:When"",""2016-11-04T11:01:27Z"",""2016-11-04T11:01:27Z"",""2016-11-04T16:05:06Z"",""2016-11-11T12:18:01Z"",""2016-11-11T14:00:43Z"",""2016-11-11T15:45:56Z"",""2016-11-11T15:56:47Z"",""2016-11-11T17:15:12Z"",""2016-11-11T18:20:55Z"",""2016-11-11T19:17:24Z"",""2016-11-11T19:26:42Z"",""2016-11-11T20:26:31Z"",""2016-11-11T20:29:10Z"",""2016-11-11T20:30:37Z"",""2016-11-11T20:36:51Z"",""2016-11-11T20:38:15Z"",""2016-11-11T20:43:22Z"",""2016-11-12T00:22:26Z"",""2016-11-12T12:01:15Z"",""2016-11-12T12:07:31Z"",""2016-11-12T12:12:56Z"",""2016-11-12T15:18:54Z"",""2016-11-12T18:12:10Z"",""2016-11-12T20:32:01Z"",""2016-11-13T12:04:18Z"",""2016-11-13T16:41:14Z"",""2016-11-13T20:43:40Z"",""2016-11-13T20:45:41Z"",""2016-11-13T21:57:05Z"",""2016-11-13T21:58:58Z"",""2016-11-13T22:52:39Z"",""2016-11-13T23:39:23Z"",""2016-11-13T23:48:46Z"",""2016-11-14T12:15:27Z"",""2016-11-14T15:02:43Z"",""2016-11-14T15:04:48Z"",""2016-11-14T23:24:04Z"",""2016-11-15T11:53:20Z"",""2016-11-15T12:20:16Z"",""2016-11-15T14:46:26Z"",""2016-11-15T15:15:03Z"",""2016-11-15T18:20:37Z"",""2016-11-15T18:33:51Z"",""2016-11-15T18:45:40Z"",""2016-11-15T18:46:49Z"",""2016-11-15T19:20:21Z"",""2016-11-15T19:50:52Z"",""2016-11-15T20:00:32Z"",""2016-11-15T20:02:19Z"",""2016-11-15T20:05:04Z"",""2016-11-15T22:40:50Z"",""2016-11-15T22:46:36Z"",""2016-11-15T23:11:15Z"",""2016-11-15T23:14:05Z"",""2016-11-15T23:42:21Z"",""2016-11-16T09:56:05Z"",""2016-11-16T10:46:02Z"",""2016-11-16T14:44:48Z"",""2016-11-16T15:12:07Z"",""2016-11-16T19:26:05Z"",""2016-11-16T20:29:40Z"",""2016-11-16T20:40:29Z"",""2016-11-16T21:59:11Z"",""2016-11-16T22:15:56Z"",""2016-11-16T22:34:37Z"",""2016-11-16T22:40:45Z"",""2016-11-16T22:48:57Z"",""2016-11-17T00:24:42Z"",""2016-11-17T17:38:09Z"",""2016-11-17T19:30:09Z"",""2016-11-17T20:03:10Z"",""2016-11-17T20:14:18Z"",""2016-11-17T20:18:02Z"",""2016-11-17T21:33:01Z"",""2016-11-17T21:57:14Z"",""2016-11-17T22:33:15Z"",""2016-11-18T09:51:21Z"",""2016-11-18T09:53:01Z"",""2016-11-18T11:26:01Z"",""2016-11-18T14:16:40Z"",""2016-11-19T19:03:13Z"",""2016-11-19T19:10:26Z"",""2016-11-21T17:22:10Z"",""2016-11-22T15:11:09Z"",""2016-11-22T15:20:16Z"",""2016-11-22T19:56:17Z"",""2016-11-22T19:58:42Z"",""2016-11-22T20:06:01Z"",""2016-11-22T20:10:25Z"",""2016-11-22T22:00:54Z"",""2016-11-22T22:09:03Z"",""2016-11-22T23:32:11Z"",""2016-11-22T23:44:04Z"",""2016-11-23T15:04:51Z"",""2016-11-23T15:25:42Z"",""2016-11-23T19:04:06Z"",""2016-11-23T19:48:14Z"",""2016-11-23T19:54:20Z"",""2016-11-23T19:54:57Z"",""2016-11-23T19:55:32Z"",""2016-11-23T23:19:26Z"",""2016-11-24T09:45:45Z"",""2016-11-24T09:47:17Z"",""2016-11-24T10:20:27Z"",""2016-11-24T10:28:46Z"",""2016-11-24T10:41:06Z"",""2016-11-24T11:34:01Z"",""2016-11-24T11:42:22Z"",""2016-11-24T12:14:17Z"",""2016-11-24T12:32:02Z"",""2016-11-24T14:11:25Z"",""2016-11-24T14:12:16Z"",""2016-11-24T14:13:39Z"",""2016-11-24T16:32:27Z"",""2016-11-24T16:45:15Z"",""2016-11-24T16:47:05Z"",""2016-11-24T16:47:33Z"",""2016-11-24T17:18:34Z"",""2016-11-24T17:47:56Z"",""2016-11-24T19:23:06Z"",""2016-11-24T20:05:07Z"",""2016-11-24T23:43:54Z"",""2016-11-24T23:56:42Z"",""2016-11-25T00:23:02Z"",""2016-11-25T00:24:08Z"",""2016-11-25T00:34:51Z"",""2016-11-25T00:44:32Z"",""2016-11-25T09:05:15Z"",""2016-11-25T09:57:39Z"",""2016-11-25T10:02:35Z"",""2016-11-25T10:26:51Z"",""2016-11-25T10:44:37Z"",""2016-11-25T10:45:30Z"",""2016-11-25T12:33:01Z"",""2016-11-25T15:07:24Z"",""2016-11-25T15:25:47Z"",""2016-11-25T15:56:24Z"",""2016-11-29T12:22:06Z"",""2016-11-29T19:44:15Z"",""2016-11-29T22:58:47Z"",""2017-01-25T09:58:16Z"",""2017-01-25T09:58:16Z"",""2017-01-25T10:06:10Z"",""2017-01-25T11:15:54Z"",""2017-01-25T11:35:46Z"",""2017-01-25T11:37:30Z"",""2017-01-25T11:45:43Z"",""2017-01-25T12:10:01Z"",""2017-01-25T14:25:23Z"",""2017-01-25T15:01:28Z"",""2017-01-25T15:04:39Z"",""2017-01-25T18:28:21Z"",""2017-01-25T18:54:34Z"",""2017-01-25T18:56:05Z"",""2017-01-25T19:16:36Z"",""2017-01-25T20:52:59Z"",""2017-01-25T21:12:54Z"",""2017-01-26T01:22:48Z"",""2017-01-26T11:16:48Z"",""2017-01-26T11:18:41Z"",""2017-01-26T11:54:24Z"",""2017-01-26T12:26:09Z"",""2017-01-26T15:08:07Z"",""2017-01-26T18:18:48Z"",""2017-01-26T20:38:20Z"",""2017-01-26T22:11:08Z"",""2017-01-27T12:10:15Z"",""2017-01-27T14:31:06Z"",""2017-01-27T15:36:50Z"",""2017-01-27T18:36:55Z"",""2017-01-28T11:03:36Z"",""2017-01-28T11:52:06Z"",""2017-01-28T11:57:46Z"",""2017-01-29T11:41:21Z"",""2017-01-29T15:35:09Z"",""2017-01-29T17:20:13Z"",""2017-01-29T17:20:58Z"",""2017-01-29T17:34:13Z"",""2017-01-29T17:49:03Z"",""2017-01-29T18:41:49Z"",""2017-01-29T19:03:31Z"",""2017-01-29T19:03:53Z"",""2017-01-29T19:33:36Z"",""2017-01-29T19:35:10Z"",""2017-01-29T19:38:55Z"",""2017-01-29T19:41:12Z"",""2017-01-29T19:48:31Z"",""2017-01-29T19:50:50Z"",""2017-01-30T11:45:21Z"",""2017-01-30T11:45:21Z"",""2017-01-30T12:16:54Z"",""2017-01-30T17:58:28Z"",""2017-01-31T01:18:39Z"",""2017-01-31T10:50:48Z"",""2017-01-31T10:53:13Z"",""2017-01-31T10:58:43Z"",""2017-01-31T11:12:29Z"",""2017-01-31T11:37:22Z"",""2017-01-31T11:44:14Z"",""2017-01-31T12:08:21Z"",""2017-01-31T12:26:05Z"",""2017-01-31T12:26:41Z"",""2017-02-01T15:00:37Z"",""2017-02-02T16:27:52Z"",""2017-02-02T16:46:15Z"",""2017-02-02T16:51:32Z"",""2017-02-02T17:07:34Z"",""2017-02-02T18:57:21Z"",""2017-02-02T19:02:23Z"",""2017-02-02T19:23:22Z"",""2017-02-03T09:02:36Z"",""2017-02-03T09:55:48Z"",""2017-02-03T10:01:49Z"",""2017-02-03T10:10:16Z"",""2017-02-03T10:49:53Z"",""2017-02-03T11:20:22Z"",""2017-02-03T11:47:05Z"",""2017-02-03T11:53:13Z"",""2017-02-03T13:09:22Z"",""2017-02-03T14:50:14Z"",""2017-02-03T14:54:42Z"",""2017-02-03T19:40:50Z"",""2017-02-03T19:57:32Z"",""2017-02-03T19:58:56Z"",""2017-02-03T20:15:15Z"",""2017-02-03T20:55:54Z"",""2017-02-03T20:56:41Z"",""2017-02-03T22:36:07Z"",""2017-02-03T22:51:31Z"",""2017-02-06T10:21:07Z"",""2017-02-06T14:16:07Z"",""2017-02-06T14:23:14Z"",""2017-02-06T16:30:59Z"",""2017-02-06T16:44:43Z"",""2017-02-06T17:08:39Z"",""2017-02-07T09:52:59Z"",""2017-02-07T09:55:24Z"",""2017-02-07T10:27:46Z"",""2017-02-07T10:31:01Z"",""2017-02-07T10:46:44Z"",""2017-02-07T11:15:13Z"",""2017-02-07T11:19:39Z"",""2017-02-07T11:39:01Z"",""2017-02-07T12:08:14Z"",""2017-02-07T12:08:14Z"",""2017-04-13T12:17:23Z"",""2017-04-13T12:42:10Z"",""2017-04-13T18:06:38Z"",""2017-04-13T18:20:55Z"",""2017-04-13T19:55:36Z"",""2017-04-14T19:38:51Z"",""2017-04-14T19:43:01Z"",""2017-04-14T21:12:10Z"",""2017-04-15T11:36:22Z"",""2017-04-15T11:46:21Z"",""2017-04-15T12:08:50Z"",""2017-04-15T19:09:55Z"",""2017-04-15T23:07:59Z"",""2017-04-15T23:39:53Z"",""2017-04-16T13:06:47Z"",""2017-04-16T15:23:09Z"",""2017-04-16T15:29:15Z"",""2017-04-16T15:46:31Z"",""2017-04-16T17:33:57Z"",""2017-04-16T18:35:36Z"",""2017-04-16T19:12:37Z"",""2017-04-16T19:39:19Z"",""2017-04-16T19:53:46Z"",""2017-04-17T23:24:15Z"",""2017-04-18T11:20:07Z"",""2017-04-18T11:36:49Z"",""2017-04-18T12:21:26Z"",""2017-04-18T12:31:55Z"",""2017-04-18T12:36:11Z"",""2017-04-18T15:04:47Z"",""2017-04-18T17:42:22Z"",""2017-04-18T21:50:52Z"",""2017-04-18T22:14:42Z"",""2017-04-18T22:19:03Z"",""2017-04-18T22:39:51Z"",""2017-04-18T22:48:06Z"",""2017-04-18T22:52:49Z"",""2017-04-18T22:59:18Z"",""2017-04-19T10:27:13Z"",""2017-04-19T10:39:56Z"",""2017-04-19T10:55:41Z"",""2017-04-19T11:06:14Z"",""2017-04-19T13:20:33Z"",""2017-04-19T15:14:02Z"",""2017-04-19T21:20:51Z"",""2017-04-19T21:29:15Z"",""2017-04-19T21:37:32Z"",""2017-04-19T21:38:38Z"",""2017-04-19T21:41:05Z"",""2017-04-19T23:59:07Z"",""2017-04-20T00:01:42Z"",""2017-04-20T00:08:32Z"",""2017-04-20T15:22:36Z"",""2017-04-20T17:51:52Z"",""2017-04-20T18:16:59Z"",""2017-04-20T18:27:13Z"",""2017-04-20T18:50:44Z"",""2017-04-20T19:01:42Z"",""2017-04-20T19:08:44Z"",""2017-04-20T19:46:45Z"",""2017-04-20T19:56:52Z"",""2017-04-20T20:01:31Z"",""2017-04-20T20:53:25Z"",""2017-04-20T21:25:34Z"",""2017-04-20T21:31:21Z"",""2017-04-20T22:26:28Z"",""2017-04-20T23:26:07Z"",""2017-04-21T10:28:28Z"",""2017-04-21T11:02:47Z"",""2017-04-21T12:38:49Z"",""2017-04-21T13:40:22Z"",""2017-04-21T13:55:36Z"",""2017-04-21T14:39:39Z"",""2017-04-21T15:15:23Z"",""2017-04-21T15:16:01Z"",""2017-04-21T15:17:44Z"",""2017-04-21T15:21:49Z"",""2017-04-21T16:55:50Z"",""2017-04-23T21:08:44Z"",""2017-04-26T22:28:39Z"",""2017-04-26T23:15:57Z"",""2017-04-27T09:40:32Z"",""2017-04-27T10:41:15Z"",""2017-04-27T11:02:33Z"",""2017-04-27T11:06:35Z"",""2017-04-27T11:10:08Z"",""2017-04-27T11:22:03Z"",""2017-04-27T11:24:51Z"",""2017-04-27T11:34:29Z"",""2017-04-27T11:43:26Z"",""2017-04-27T11:47:47Z"",""2017-04-27T11:58:22Z"",""2017-04-27T12:02:49Z"",""2017-04-27T12:11:09Z"",""2017-04-27T12:20:29Z"",""2017-04-27T12:40:50Z"",""2017-04-27T13:01:30Z"",""2017-04-27T13:23:24Z"",""2017-04-27T15:11:11Z"",""2017-04-27T15:17:48Z"",""2017-04-27T16:58:15Z"",""2017-04-27T17:39:05Z"",""2017-04-27T19:06:31Z"",""2017-04-27T19:46:52Z"",""2017-04-27T19:50:58Z"",""2017-04-27T19:59:58Z"",""2017-04-27T20:05:06Z"",""2017-04-28T09:42:29Z"",""2017-04-28T11:31:32Z"",""2017-04-28T12:30:36Z"",""2017-04-28T12:37:35Z"",""2017-04-28T15:40:20Z"",""2017-04-28T15:45:39Z"",""2017-04-28T15:49:02Z"",""2017-04-28T15:51:26Z"",""2017-05-01T10:55:44Z"",""2017-05-01T11:01:04Z"",""2017-05-01T12:45:50Z"",""2017-05-01T12:53:01Z"",""2017-05-01T14:42:03Z"",""2017-05-01T14:54:17Z"",""2017-05-01T17:41:01Z"",""2017-05-01T18:13:36Z"",""2017-05-01T18:15:25Z"",""2017-05-01T18:20:39Z"",""2017-05-01T18:23:04Z"",""2017-05-01T19:31:41Z"",""2017-05-01T19:38:42Z"",""2017-05-01T22:20:11Z"",""2017-05-02T09:20:54Z"",""2017-05-02T09:24:56Z"",""2017-05-02T09:25:54Z"",""2017-05-05T11:54:25Z"",""2017-07-21T10:40:06Z"",""2017-07-21T11:23:45Z"",""2017-07-21T16:12:59Z"",""2017-07-21T17:40:10Z"",""2017-07-22T09:05:31Z"",""2017-07-22T09:44:31Z"",""2017-07-22T09:59:02Z"",""2017-07-22T10:11:19Z"",""2017-07-22T14:29:12Z"",""2017-07-23T14:38:23Z"",""2017-07-24T09:59:34Z"",""2017-07-24T10:04:41Z"",""2017-07-24T11:38:32Z"",""2017-07-24T11:55:38Z"",""2017-07-24T12:02:34Z"",""2017-07-24T12:29:59Z"",""2017-07-24T16:28:01Z"",""2017-07-24T16:37:59Z"",""2017-07-24T17:34:06Z"",""2017-07-24T17:39:58Z"",""2017-07-25T09:24:45Z"",""2017-07-25T09:50:58Z"",""2017-07-25T10:15:26Z"",""2017-07-25T10:25:27Z"",""2017-07-25T10:47:43Z"",""2017-07-25T11:12:54Z"",""2017-07-25T11:40:43Z"",""2017-07-25T11:42:02Z"",""2017-07-25T13:22:07Z"",""2017-07-25T13:34:15Z"",""2017-07-25T17:47:41Z"",""2017-07-25T17:53:11Z"",""2017-07-25T18:45:42Z"",""2017-07-25T18:56:12Z"",""2017-07-26T10:12:53Z"",""2017-07-26T11:27:17Z"",""2017-07-26T11:32:36Z"",""2017-07-26T11:50:43Z"",""2017-07-26T12:31:55Z"",""2017-07-26T16:26:51Z"",""2017-07-26T17:07:47Z"",""2017-07-26T18:41:29Z"",""2017-07-26T18:47:25Z"",""2017-07-26T18:50:46Z"",""2017-07-26T18:52:28Z"",""2017-07-26T18:56:31Z"",""2017-07-26T19:13:42Z"",""2017-07-26T19:25:23Z"",""2017-07-26T20:18:42Z"",""2017-07-26T20:36:40Z"",""2017-07-27T10:28:02Z"",""2017-07-27T10:28:02Z"",""2017-07-27T10:29:55Z"",""2017-07-27T10:53:12Z"",""2017-07-27T13:36:11Z"",""2017-07-27T13:44:06Z"",""2017-07-27T15:03:43Z"",""2017-07-27T15:13:32Z"",""2017-07-27T15:16:28Z"",""2017-07-27T15:45:02Z"",""2017-07-27T15:45:41Z"",""2017-07-27T15:48:29Z"",""2017-07-27T15:49:33Z"",""2017-07-27T18:49:42Z"",""2017-07-27T19:05:51Z"",""2017-07-27T19:06:44Z"",""2017-07-27T19:10:01Z"",""2017-07-27T19:24:47Z"",""2017-07-28T12:06:09Z"",""2017-07-31T10:59:39Z"",""2017-07-31T11:12:24Z"",""2017-07-31T11:14:55Z"",""2017-08-01T09:52:04Z"",""2017-08-02T00:08:59Z"",""2017-08-02T11:30:30Z"",""2017-08-02T15:08:53Z"",""2017-08-02T17:40:53Z"",""2017-08-02T19:03:07Z"",""2017-08-02T19:19:56Z"",""2017-08-03T09:50:38Z"",""2017-08-03T10:32:27Z"",""2017-08-03T10:40:01Z"",""2017-08-03T10:41:34Z"",""2017-08-03T12:27:36Z"",""2017-08-03T12:34:16Z"",""2017-08-03T12:34:39Z"",""2017-08-03T12:35:29Z"",""2017-08-03T12:39:47Z"",""2017-08-03T13:12:44Z"",""2017-08-03T13:13:40Z"",""2017-08-03T13:24:41Z"",""2017-08-03T15:06:23Z"",""2017-08-03T15:18:59Z"",""2017-08-03T17:37:01Z"",""2017-08-03T19:23:05Z"",""2017-08-03T20:31:13Z"",""2017-08-03T23:56:12Z"",""2017-08-04T09:22:01Z"",""2017-08-04T09:37:02Z"",""2017-08-04T10:24:37Z"",""2017-08-04T10:44:05Z"",""2017-08-04T11:24:20Z"",""2017-08-04T11:27:36Z"",""2017-08-04T11:56:39Z"",""2017-08-04T12:00:05Z"",""2017-08-04T12:01:06Z"",""2017-08-06T20:52:12Z"",""2017-08-06T21:15:54Z"",""2017-08-07T09:43:09Z"",""2017-08-07T09:45:07Z"",""2017-08-07T09:45:49Z"",""2017-08-07T09:45:49Z"",""2017-08-07T11:11:28Z"",""2017-08-07T11:18:19Z"",""2017-08-07T11:33:54Z"",""2017-08-07T11:34:44Z"",""2017-08-11T10:17:18Z"",""2017-08-11T10:34:28Z"",""2017-08-11T17:23:52Z"",""2017-10-21T15:29:37Z"",""2017-10-21T15:31:39Z"",""2017-10-22T18:20:27Z"",""2017-10-22T18:24:03Z"",""2017-10-22T18:46:35Z"",""2017-10-22T18:47:13Z"",""2017-10-22T18:53:15Z"",""2017-10-22T18:54:16Z"",""2017-10-22T19:00:34Z"",""2017-10-22T19:03:54Z"",""2017-10-22T19:05:40Z"",""2017-10-22T19:08:17Z"",""2017-10-22T19:10:42Z"",""2017-10-22T19:21:12Z"",""2017-10-22T19:34:47Z"",""2017-10-22T19:40:02Z"",""2017-10-22T20:10:32Z"",""2017-10-22T20:18:38Z"",""2017-10-22T21:13:38Z"",""2017-10-22T22:11:41Z"",""2017-10-22T22:22:19Z"",""2017-10-22T22:39:07Z"",""2017-10-22T22:45:01Z"",""2017-10-22T22:52:17Z"",""2017-10-22T23:00:12Z"",""2017-10-22T23:34:22Z"",""2017-10-23T10:29:11Z"",""2017-10-23T10:48:49Z"",""2017-10-23T11:55:27Z"",""2017-10-23T11:56:55Z"",""2017-10-23T11:58:51Z"",""2017-10-23T13:42:15Z"",""2017-10-23T13:55:46Z"",""2017-10-23T15:50:48Z"",""2017-10-23T16:09:49Z"",""2017-10-23T17:02:50Z"",""2017-10-23T17:09:02Z"",""2017-10-23T18:06:39Z"",""2017-10-23T18:08:44Z"",""2017-10-23T18:39:32Z"",""2017-10-23T18:57:19Z"",""2017-10-23T21:52:20Z"",""2017-10-23T22:03:59Z"",""2017-10-23T22:15:49Z"",""2017-10-23T22:16:11Z"",""2017-10-23T22:28:42Z"",""2017-10-23T22:40:13Z"",""2017-10-23T22:52:13Z"",""2017-10-23T22:56:15Z"",""2017-10-24T00:17:34Z"",""2017-10-24T00:40:48Z"",""2017-10-24T00:48:41Z"",""2017-10-24T00:59:51Z"",""2017-10-24T01:01:01Z"",""2017-10-24T01:04:46Z"",""2017-10-24T10:04:35Z"",""2017-10-24T10:59:51Z"",""2017-10-24T11:17:04Z"",""2017-10-24T11:20:05Z"",""2017-10-24T11:27:07Z"",""2017-10-24T11:32:36Z"",""2017-10-24T11:33:19Z"",""2017-10-24T12:28:22Z"",""2017-10-24T12:34:14Z"",""2017-10-24T13:28:01Z"",""2017-10-24T13:28:56Z"",""2017-10-24T13:32:27Z"",""2017-10-24T14:46:17Z"",""2017-10-24T14:47:18Z"",""2017-10-24T15:02:20Z"",""2017-10-24T19:24:17Z"",""2017-10-24T19:32:49Z"",""2017-10-24T22:00:29Z"",""2017-10-24T22:21:36Z"",""2017-10-24T22:29:26Z"",""2017-10-24T22:33:15Z"",""2017-10-24T23:26:01Z"",""2017-10-24T23:41:01Z"",""2017-10-24T23:44:27Z"",""2017-10-24T23:47:07Z"",""2017-10-25T10:07:08Z"",""2017-10-25T10:12:21Z"",""2017-10-25T10:13:39Z"",""2017-10-25T13:26:52Z"",""2017-10-25T13:38:11Z"",""2017-10-25T16:04:56Z"",""2017-10-25T16:22:55Z"",""2017-10-25T16:35:52Z"",""2017-10-25T16:39:53Z"",""2017-10-25T16:39:53Z"",""2017-10-25T16:44:09Z"",""2017-10-25T16:47:01Z"",""2017-10-25T16:48:25Z"",""2017-10-25T16:54:34Z"",""2017-10-25T17:00:54Z"",""2017-10-25T17:02:19Z"",""2017-10-25T17:06:34Z"",""2017-10-25T17:11:04Z"",""2017-10-27T18:24:47Z"",""2017-10-27T18:29:13Z"",""2017-10-27T18:32:42Z"",""2017-10-27T18:58:50Z"",""2017-10-27T19:02:02Z"",""2017-10-27T21:39:47Z"",""2017-10-30T09:34:06Z"",""2017-10-30T09:39:51Z"",""2017-10-30T10:00:09Z"",""2017-10-30T10:09:56Z"",""2017-10-30T10:37:58Z"",""2017-10-30T11:35:30Z"",""2017-10-30T11:41:30Z"",""2017-10-30T12:00:24Z"",""2017-10-30T12:08:01Z"",""2017-10-30T12:11:42Z"",""2017-10-30T12:58:44Z"",""2017-10-30T13:00:37Z"",""2017-10-30T13:16:33Z"",""2017-10-30T13:17:57Z"",""2017-10-30T13:18:59Z"",""2017-10-30T13:23:18Z"",""2017-10-30T15:16:26Z"",""2017-10-30T16:47:02Z"",""2017-10-30T16:54:08Z"",""2017-10-30T17:31:30Z"",""2017-10-30T17:44:15Z"",""2017-10-30T17:48:13Z"",""2017-10-30T18:06:58Z"",""2017-10-30T18:39:09Z"",""2017-10-30T18:49:39Z"",""2017-10-30T19:32:57Z"",""2017-10-30T20:06:35Z"",""2017-10-30T22:32:54Z"",""2017-11-01T09:16:51Z"",""2017-11-01T09:47:29Z"",""2017-11-01T10:01:44Z"",""2017-11-01T10:37:03Z"",""2017-11-01T10:37:42Z"",""2017-11-01T11:02:09Z"",""2017-11-01T11:10:41Z"",""2017-11-01T11:20:55Z"",""2017-11-01T17:21:59Z"",""2017-11-01T18:32:16Z"",""2017-11-01T18:43:59Z"",""2017-11-01T20:01:56Z"",""2017-11-01T20:08:17Z"",""2017-11-01T20:40:23Z"",""2017-11-02T09:40:11Z"",""2017-11-02T09:50:47Z"",""2017-11-02T11:33:41Z"",""2017-11-02T11:36:33Z"",""2017-11-02T11:40:12Z"",""2017-11-02T13:28:54Z"",""2017-11-02T13:29:40Z"",""2017-11-02T13:35:48Z"",""2017-11-03T09:47:06Z"",""2017-11-03T10:42:01Z"",""2017-11-03T10:49:39Z"",""2017-11-03T10:50:26Z"",""2017-11-03T10:50:26Z"",""2017-11-03T15:55:07Z"",""2017-11-10T16:41:12Z"",""2017-11-10T17:00:16Z"",""2018-01-19T11:29:40Z"",""2018-01-19T12:02:26Z"",""2018-01-19T18:16:46Z"",""2018-01-19T19:34:41Z"",""2018-01-20T11:06:30Z"",""2018-01-20T11:37:33Z"",""2018-01-20T11:42:04Z"",""2018-01-20T12:09:21Z"",""2018-01-20T12:16:04Z"",""2018-01-20T12:22:07Z"",""2018-01-20T16:53:43Z"",""2018-01-20T18:07:02Z"",""2018-01-20T18:14:22Z"",""2018-01-20T19:57:28Z"",""2018-01-20T20:05:12Z"",""2018-01-20T20:28:52Z"",""2018-01-20T21:21:15Z"",""2018-01-21T11:32:50Z"",""2018-01-21T11:45:38Z"",""2018-01-21T11:55:19Z"",""2018-01-21T14:53:42Z"",""2018-01-21T16:08:19Z"",""2018-01-21T16:08:54Z"",""2018-01-21T16:25:11Z"",""2018-01-21T16:33:33Z"",""2018-01-21T18:00:06Z"",""2018-01-21T18:26:41Z"",""2018-01-21T18:43:59Z"",""2018-01-21T19:27:08Z"",""2018-01-21T19:30:59Z"",""2018-01-21T19:33:22Z"",""2018-01-21T19:34:40Z"",""2018-01-21T19:40:34Z"",""2018-01-21T19:42:36Z"",""2018-01-21T19:44:32Z"",""2018-01-21T19:57:05Z"",""2018-01-21T20:03:51Z"",""2018-01-21T20:04:38Z"",""2018-01-21T20:05:57Z"",""2018-01-21T20:39:26Z"",""2018-01-21T20:59:46Z"",""2018-01-21T22:14:46Z"",""2018-01-21T22:15:18Z"",""2018-01-21T22:17:51Z"",""2018-01-21T22:19:43Z"",""2018-01-21T22:26:24Z"",""2018-01-21T22:29:02Z"",""2018-01-21T22:35:20Z"",""2018-01-21T22:51:30Z"",""2018-01-21T22:52:53Z"",""2018-01-22T11:29:50Z"",""2018-01-22T11:50:45Z"",""2018-01-22T11:59:57Z"",""2018-01-22T12:20:14Z"",""2018-01-22T12:23:29Z"",""2018-01-22T12:37:55Z"",""2018-01-22T15:02:48Z"",""2018-01-22T18:23:13Z"",""2018-01-22T19:28:12Z"",""2018-01-22T20:04:52Z"",""2018-01-22T20:07:15Z"",""2018-01-22T20:15:52Z"",""2018-01-22T20:52:47Z"",""2018-01-22T20:53:22Z"",""2018-01-22T22:27:34Z"",""2018-01-22T22:30:49Z"",""2018-01-22T22:34:33Z"",""2018-01-22T22:39:25Z"",""2018-01-22T22:46:12Z"",""2018-01-22T22:49:54Z"",""2018-01-22T22:55:24Z"",""2018-01-22T23:02:30Z"",""2018-01-23T10:00:24Z"",""2018-01-23T11:44:29Z"",""2018-01-23T12:21:17Z"",""2018-01-23T14:36:11Z"",""2018-01-23T14:42:52Z"",""2018-01-23T18:20:29Z"",""2018-01-23T18:22:19Z"",""2018-01-23T18:28:06Z"",""2018-01-23T18:46:14Z"",""2018-01-23T23:03:29Z"",""2018-01-23T23:21:14Z"",""2018-01-23T23:24:58Z"",""2018-01-24T08:40:23Z"",""2018-01-24T08:40:23Z"",""2018-01-24T09:46:11Z"",""2018-01-24T09:59:17Z"",""2018-01-24T10:09:11Z"",""2018-01-24T10:58:37Z"",""2018-01-24T21:00:39Z"",""2018-01-24T21:12:15Z"",""2018-01-24T21:24:01Z"",""2018-01-24T21:33:39Z"",""2018-01-24T23:16:19Z"",""2018-01-25T00:32:02Z"",""2018-01-25T10:09:18Z"",""2018-01-25T10:37:42Z"",""2018-01-25T11:26:19Z"",""2018-01-25T11:47:01Z"",""2018-01-25T11:51:34Z"",""2018-01-25T11:54:22Z"",""2018-01-25T12:12:07Z"",""2018-01-25T12:15:55Z"",""2018-01-25T12:17:25Z"",""2018-01-26T12:04:54Z"",""2018-01-29T09:39:21Z"",""2018-01-30T12:32:56Z"",""2018-01-31T18:27:18Z"",""2018-01-31T18:28:26Z"",""2018-01-31T18:29:15Z"",""2018-01-31T19:04:52Z"",""2018-01-31T19:11:08Z"",""2018-01-31T19:16:37Z"",""2018-01-31T19:29:33Z"",""2018-01-31T19:33:28Z"",""2018-02-01T09:26:35Z"",""2018-02-01T10:14:02Z"",""2018-02-01T10:37:42Z"",""2018-02-01T10:38:07Z"",""2018-02-01T10:48:38Z"",""2018-02-01T10:50:57Z"",""2018-02-01T11:03:57Z"",""2018-02-01T11:54:40Z"",""2018-02-01T12:02:10Z"",""2018-02-01T12:08:05Z"",""2018-02-01T12:31:07Z"",""2018-02-01T12:38:29Z"",""2018-02-01T12:39:22Z"",""2018-02-01T15:06:12Z"",""2018-02-01T15:21:53Z"",""2018-02-01T15:49:01Z"",""2018-02-01T15:54:58Z"",""2018-02-01T15:58:11Z"",""2018-02-01T16:28:45Z"",""2018-02-01T16:37:14Z"",""2018-02-01T16:51:21Z"",""2018-02-01T16:51:36Z"",""2018-02-01T16:52:42Z"",""2018-02-01T17:45:35Z"",""2018-02-01T17:59:22Z"",""2018-02-01T18:01:47Z"",""2018-02-01T18:09:54Z"",""2018-02-01T18:44:59Z"",""2018-02-01T18:48:01Z"",""2018-02-01T19:09:59Z"",""2018-02-01T19:19:31Z"",""2018-02-01T19:42:48Z"",""2018-02-01T19:46:03Z"",""2018-02-02T10:06:15Z"",""2018-02-02T11:07:14Z"",""2018-02-02T11:11:32Z"",""2018-02-02T11:25:43Z"",""2018-02-02T11:34:02Z"",""2018-02-02T11:38:14Z"",""2018-02-02T12:33:42Z"",""2018-02-02T12:34:23Z"",""2018-02-02T13:18:52Z"",""2018-02-02T13:53:11Z"",""2018-02-02T14:05:57Z"",""2018-02-02T14:07:46Z"",""2018-02-04T11:13:31Z"",""2018-02-04T11:13:50Z"",""2018-02-04T11:13:50Z"",""2018-02-04T16:43:51Z"",""2018-02-04T17:06:37Z"",""2018-02-04T17:12:43Z"",""2018-02-04T17:16:36Z"",""2018-02-04T17:33:01Z"",""2018-02-04T17:38:31Z"",""2018-02-04T18:16:48Z"",""2018-02-04T18:44:49Z"",""2018-02-04T18:48:09Z"",""2018-02-04T18:51:24Z"",""2018-02-04T18:54:45Z"",""2018-02-04T19:12:07Z"",""2018-02-04T19:18:17Z"",""2018-02-04T19:27:17Z"",""2018-02-04T19:44:43Z"",""2018-02-04T19:49:41Z"",""2018-02-04T21:01:16Z"",""2018-02-05T09:52:37Z"",""2018-02-05T09:57:10Z"",""2018-02-05T10:02:42Z"",""2018-02-05T12:57:34Z"",""2018-02-05T13:01:01Z"",""2018-02-05T15:05:44Z"",""2018-02-05T16:42:34Z"",""2018-02-09T09:17:51Z"",""2018-02-09T09:17:51Z"",""2018-02-09T10:10:40Z"",""2018-02-12T10:17:14Z"",""2018-03-15T18:01:01Z"",""2018-03-15T18:27:14Z"",""2018-03-15T18:29:29Z"",""2018-03-16T10:22:09Z"",""2018-03-19T12:37:32Z"",""2018-03-19T12:37:33Z"",""2018-03-19T23:02:04Z"",""2018-03-21T12:39:10Z"",""2018-03-22T09:40:16Z"",""2018-03-22T10:50:10Z"",""2018-03-22T15:42:13Z"",""2018-03-23T11:21:53Z"",""2018-03-23T11:23:58Z"",""2018-03-23T11:53:11Z"",""2018-04-18T12:09:30Z"",""2018-04-18T12:17:05Z"",""2018-04-18T14:42:15Z"",""2018-04-18T14:51:06Z"",""2018-04-19T10:00:18Z"",""2018-04-19T10:52:43Z"",""2018-04-19T11:06:37Z"",""2018-04-19T11:39:39Z"",""2018-04-19T11:46:59Z"",""2018-04-19T12:18:20Z"",""2018-04-19T13:23:36Z"",""2018-04-19T14:34:11Z"",""2018-04-19T14:39:03Z"",""2018-04-19T14:53:52Z"",""2018-04-19T17:12:33Z"",""2018-04-19T17:36:55Z"",""2018-04-19T17:38:43Z"",""2018-04-19T17:49:16Z"",""2018-04-19T19:02:11Z"",""2018-04-19T19:03:12Z"",""2018-04-19T19:04:49Z"",""2018-04-19T19:06:56Z"",""2018-04-19T21:27:15Z"",""2018-04-19T21:47:24Z"",""2018-04-19T22:04:52Z"",""2018-04-19T22:07:01Z"",""2018-04-19T22:11:33Z"",""2018-04-20T09:52:13Z"",""2018-04-20T10:17:53Z"",""2018-04-20T11:30:25Z"",""2018-04-20T11:45:17Z"",""2018-04-20T11:49:05Z"",""2018-04-20T12:33:13Z"",""2018-04-20T16:37:38Z"",""2018-04-20T17:16:25Z"",""2018-04-20T19:41:10Z"",""2018-04-20T19:45:28Z"",""2018-04-20T19:48:51Z"",""2018-04-20T19:55:20Z"",""2018-04-20T20:08:47Z"",""2018-04-20T20:13:26Z"",""2018-04-20T20:21:11Z"",""2018-04-20T20:24:10Z"",""2018-04-20T20:36:14Z"",""2018-04-20T21:19:48Z"",""2018-04-20T21:42:08Z"",""2018-04-20T22:25:48Z"",""2018-04-20T22:28:39Z"",""2018-04-22T16:30:22Z"",""2018-04-22T17:08:06Z"",""2018-04-22T17:48:43Z"",""2018-04-22T17:59:39Z"",""2018-04-22T18:04:24Z"",""2018-04-22T18:30:32Z"",""2018-04-22T20:42:21Z"",""2018-04-22T21:23:24Z"",""2018-04-23T11:45:12Z"",""2018-04-23T12:28:53Z"",""2018-04-23T15:00:56Z"",""2018-04-23T19:33:51Z"",""2018-04-23T19:50:55Z"",""2018-04-23T20:42:54Z"",""2018-04-23T21:00:19Z"",""2018-04-23T21:01:50Z"",""2018-04-24T09:55:14Z"",""2018-04-24T09:56:07Z"",""2018-04-24T10:12:02Z"",""2018-04-24T10:17:55Z"",""2018-04-24T11:02:37Z"",""2018-04-24T11:23:01Z"",""2018-04-24T12:13:05Z"",""2018-04-24T15:03:10Z"",""2018-04-24T17:06:13Z"",""2018-04-24T18:00:47Z"",""2018-04-24T18:12:01Z"",""2018-04-24T18:13:42Z"",""2018-04-24T18:25:27Z"",""2018-04-24T18:33:37Z"",""2018-04-24T20:08:02Z"",""2018-04-24T20:11:30Z"",""2018-04-24T20:16:22Z"",""2018-04-24T21:03:20Z"",""2018-04-24T21:20:01Z"",""2018-04-24T21:23:40Z"",""2018-04-24T21:24:41Z"",""2018-04-24T21:48:55Z"",""2018-04-24T21:53:27Z"",""2018-04-24T21:55:55Z"",""2018-04-25T09:48:10Z"",""2018-04-25T09:58:02Z"",""2018-04-25T10:34:43Z"",""2018-04-25T15:58:02Z"",""2018-04-25T16:18:14Z"",""2018-04-25T16:38:11Z"",""2018-04-25T17:00:05Z"",""2018-04-25T17:12:22Z"",""2018-04-26T09:59:20Z"",""2018-04-26T10:00:06Z"",""2018-04-26T11:12:01Z"",""2018-04-26T11:30:44Z"",""2018-04-26T11:58:39Z"",""2018-04-26T12:09:19Z"",""2018-04-26T12:18:54Z"",""2018-04-26T14:59:01Z"",""2018-04-26T14:59:43Z"",""2018-04-26T17:42:09Z"",""2018-04-26T18:00:48Z"",""2018-04-26T18:03:41Z"",""2018-04-26T18:09:35Z"",""2018-04-26T18:34:22Z"",""2018-04-26T19:07:58Z"",""2018-04-26T19:33:54Z"",""2018-04-26T19:38:13Z"",""2018-04-26T19:55:27Z"",""2018-04-26T20:16:57Z"",""2018-04-26T20:21:56Z"",""2018-04-26T21:21:56Z"",""2018-04-26T21:35:03Z"",""2018-04-26T22:03:32Z"",""2018-04-26T22:09:22Z"",""2018-04-26T23:27:51Z"",""2018-04-27T09:10:42Z"",""2018-04-27T11:53:37Z"",""2018-04-27T12:20:32Z"",""2018-04-27T12:23:17Z"",""2018-04-27T12:24:14Z"",""2018-04-27T14:00:36Z"",""2018-04-27T14:01:24Z"",""2018-04-27T17:41:15Z"",""2018-04-27T20:27:32Z"",""2018-04-30T10:00:04Z"",""2018-04-30T11:29:43Z"",""2018-04-30T11:49:51Z"",""2018-04-30T12:33:03Z"",""2018-04-30T13:14:32Z"",""2018-05-01T09:51:52Z"",""2018-05-01T11:26:36Z"",""2018-05-01T11:58:01Z"",""2018-05-01T12:40:46Z"",""2018-05-01T13:20:31Z"",""2018-05-01T14:54:36Z"",""2018-05-01T15:00:15Z"",""2018-05-01T15:00:54Z"",""2018-05-01T18:12:34Z"",""2018-05-01T18:25:26Z"",""2018-05-01T18:37:20Z"",""2018-05-01T19:02:28Z"",""2018-05-01T19:05:35Z"",""2018-05-01T19:26:16Z"",""2018-05-01T19:38:14Z"",""2018-05-01T19:41:27Z"",""2018-05-01T19:48:23Z"",""2018-05-01T20:47:32Z"",""2018-05-01T20:50:12Z"",""2018-05-01T20:54:12Z"",""2018-05-01T21:13:24Z"",""2018-05-01T21:15:01Z"",""2018-05-01T21:40:52Z"",""2018-05-01T23:52:52Z""
""pdf:encrypted"",""false""
""xmp:CreateDate"",""2020-05-11T11:15:41Z""
""modified"",""2020-05-10T23:15:43Z""
""xmpMM:History:SoftwareAgent"",""Adobe InDesign 7.5"",""Adobe InDesign 7.5"",""Adobe InDesign 7.5"",""Adobe InDesign 7.5"",""Adobe InDesign 7.5"",""Adobe InDesign 7.5"",""Adobe InDesign 7.5"",""Adobe InDesign 7.5"",""Adobe InDesign 7.5"",""Adobe InDesign 7.5"",""Adobe InDesign 7.5"",""Adobe InDesign 7.5"",""Adobe InDesign 7.5"",""Adobe InDesign 7.5"",""Adobe InDesign 7.5"",""Adobe InDesign 7.5"",""Adobe InDesign 7.5"",""Adobe InDesign 7.5"",""Adobe InDesign 7.5"",""Adobe InDesign 7.5"",""Adobe InDesign 7.5"",""Adobe InDesign 7.5"",""Adobe InDesign 7.5"",""Adobe InDesign 7.5"",""Adobe InDesign 7.5"",";https://scholar.google.com/scholar?start=500&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095285-1204;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;[HTML][HTML] Efficient digital signatures from RSA without random oracles;JH Seo ; Information Sciences, 2020  Elsevier;;"… digital signature schemes achieve a short signature size, many of them essentially rely on random

oracle heuristics. In 2009, Hohenberger and Water proposed an excellent approach to the design

of a short RSA-based signature scheme without random oracles (CRYPTO 2009 …";Cité 5 fois;Les 3 versions;[HTML] sciencedirect.com;https://www.sciencedirect.com/science/article/pii/S0020025519309478?casa_token=kw2sj8L10P4AAAAA:THBYewmdlU2dSzgKyrvYazrZZ_lTKXTzoblfHDyd0mNd-_TZy--w5rCST9HrdtMKRa_WNbEd;;;https://scholar.google.com/scholar?start=10&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095388-1650;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;[PDF][PDF] Blockchain-rendszer? megoldások a munkaviszonyokban;J Ferencz ; Erdélyi Jogélet, 2020  jogelet.ro;;"… sajtokozlemenyek/2014-evi-sajtokozlemenyek/az-mnb-koc- kazatosnak-tartja-a-fizetesre-

hasznalhato-virtualis-eszkozoket-peldaul-a-bitcoint 2. https://blockchainhub.net/blockchain-oracles/

3. https … html 7. Matthiews, Kayla: Why Employers Can't Pay You in Cryptocurrency …";Autres articles;;[PDF] jogelet.ro;https://www.jogelet.ro/index.php/eje/article/download/65/53;"
Blockchain-rendszerĹą megoldĂĄsok  a munkaviszonyokban

21 || 2020

FERENCZ JÁCINT

Blockchain-rendszerĹą megoldĂĄsok  
a munkaviszonyokban

Blockchain System Solutions in the Labour Relations

Abstract: The essence of the blockchain technology lies in that via connected IT devices such a base of information 
is formed which simultaneously, with making a thousand copies, is able to register data of transactions, automated 
transactions, without any external supervision and the possibility of retrospective one-sided modification. Many 
believe that the system of blockchain (and the digital general ledger system forming its base) will bring about such 
a change into our lives which the Internet brought when it started to spread in the 1990s.   
   The most successful examples of blockchains so far are financial tools. The Court of the European Union has already 
ruled in judgement no. C264/14 that bitcoin virtual currency is considered to be a contractual money, it is a direct 
money between economic actors who accept it.  
   It is a perpetual dilemma of the law and legal regulations that lawmakers react to the events of everyday life slower 
than the speed at which economic actors find new solutions to various problems. Do new possibilities provided by 
blockchains surpass risks, or is it just like an Internet article warns: are hackers becoming the new lawyers? What 
can a corporate lawyer say to the previous question − can salary be asked for in bitcoin?  
This presentation tries to answer the question of how much the blockchain system facilitates the conclusion of 
employment contracts or the fulfillment, the control, and the administration of employment relationships and whether 
the human element is indispensable in the operation of these systems.

Keywords: blockchain system, bitcoin, employment contract

Összefoglaló: A blockchain-technológia lényege, hogy összekapcsolt informatikai eszközök segítségével egy olyan 
információbázis jön létre, amely egyidejűleg akár több millió másolat készítésével, külső felügyelet nélkül képes 
tranzakciók adatainak nyilvántartására, automatizált ügyletkötésre a visszamenőleges egyoldalú módosítás lehető-
sége nélkül. Sokan úgy vélik, hogy a blokklánc-rendszer (illetve az alapját jelentő digitális főkönyvi rendszer) akkora 
vĂĄltozĂĄst fog hozni az ĂŠletĂźnkbe, mint amekkorĂĄt az internet elterjedĂŠse jelentett az 1990-es ĂŠvekben.   
   A blokklåncok legsikeresebb pÊldåi ez idåig a pÊnzßgyi eszkÜzÜk. Az Európai Unió Bírósåga a C264/14. sz. ítÊletÊben 
már megállapította, hogy a bitcoin virtuális deviza szerződéses fizetőeszköznek minősül, az azt elfogadó gazdasági 
szereplők közötti közvetlen fizetőeszköz.  
   A jog Ês a jogi szabålyozås ÜrÜk dilemmåja, hogy a jogalkotó lassabban reagål a mindennapi Êlet esemÊnyeire, mint 
amilyen gyorsan a gazdasági szereplők új és új megoldásokat találnak ki egy adott problémára. A blokkláncok által 
nyújtott új lehetőségek vajon felülmúlják-e a kockázatokat, vagy ahogyan egy internetes cikk fenyeget: a hackerek 
lesznek az új ügyvédek? Mit válaszolhat az előző bekezdésben felvetett kérdésre − kérhető-e a munkabér bitcoinban 
− a vállalati jogtanácsos?   

DOI: 10.47745/ERJOG.2020.04.02



ERDÉLYI JOGÉLET

| 22 04 |

   Jelen tanulmány arra keresi a választ, hogy vajon mennyire könnyíti meg a blockchain-rendszer a munkaszerződések 
megkötését, a munkaviszonyok teljesítését, ellenőrzését és adminisztrációját, illetve nélkülözhető-e a humán elem 
e rendszerek mĹąkĂśdtetĂŠsĂŠben.

Kulcsszavak: blockchain, munkajog, munkaviszony létesítése, munkaszerződés, okosszerződés

Hacsak nem egy kĂśzel lakatlan szigeten ĂŠlĂźnk (a boldog informĂĄciĂłhiĂĄny ĂĄllapotĂĄban), 
találkoznunk kellett a 21. század legkomolyabbnak tűnő vívmányával, az úgynevezett 
blockchain- vagy blokklánc-rendszerrel. Bár meggyőződésem, hogy a pontos működésével 
egyelőre kevesen vannak tisztában, a jelentősége tagadhatatlan. A technológia lényege, 
hogy Ăśsszekapcsolt informatikai eszkĂśzĂśk segĂ­tsĂŠgĂŠvel egy olyan informĂĄciĂłbĂĄzis jĂśn lĂŠtre, 
amely egyidejűleg akár több millió másolat készítésével, külső felügyelet nélkül képes 
tranzakciók adatainak nyilvántartására, automatizált ügyletkötésre a visszamenőleges 
egyoldalú módosítás lehetősége nélkül.1 Sokan úgy vélik, hogy a blokklánc-rendszer (illetve 
az alapját jelentő digitális főkönyvi rendszer) akkora változást fog hozni az életünkbe, mint 
amekkorĂĄt az internet elterjedĂŠse jelentett az 1990-es ĂŠvekben. 

TudomĂĄnyos berkeken belĂźl mĂŠg Ăłvatosan kĂśzelĂ­tĂźnk a tĂŠmĂĄhoz: az MTMT adat-
bázisa 2018. június 4-én mindössze 7 bejegyzést eredményezett a „blockchain” kereső-
szĂłra, ĂŠs 4 bejegyzĂŠst a blokklĂĄnc kifejezĂŠsre, ami feltĂŠtlenĂźl kevĂŠsnek tĹąnik ahhoz 
kĂŠpest, hogy az amazon.co.uk oldal tĂśbb mint 4000 kĂśnyvet ajĂĄnlott fel a tĂŠmĂĄban angolul 
(blockchain szóra keresve a könyvek között). A nagy tudományos gyűjtőportálok közül 
a Social Science Reseach Network rendszerĂŠben 229 cikk foglalkozott mĂĄr a cĂ­mĂŠben is 
valamilyen módon a blokkláncokkal, döntő többségük 2015 utáni megjelenésű munka. 
A jogi aspektusokkal ugyanakkor meglepően kevés szerző foglalkozik. 2015-ben Aaron 
Wright és Primavera de Filippi használták tudományos közleményben a „Lex Cryptogra-
phia” kifejezést,2 kifejtve, hogy a most tapasztalt jelenség a lex mercatoriához viszonyítva 
fontos hasonlĂłsĂĄgokat mutat: a nemzetkĂśzi ĂĄru- ĂŠs informĂĄciĂłcsere piaci szabĂĄlyozĂĄsa 
tĂśrtĂŠnik, nem hagyomĂĄnyos jogi struktĂşrĂĄkban, hanem ĂśnszabĂĄlyozĂĄs keretĂŠben. Max 
Raskin egy ĂŠrdekes pĂŠldĂĄt emlĂ­t a szabĂĄlyozĂĄs kĂśrĂŠben: az ĂŠtelautomatĂĄkba bedobott 
pénz – amennyiben az automata üzemszerűen működik – létrehozza az adásvételi ügy-
letet, és az eredmény pedig két elégedett üzletfél. Ez is egyfajta okosszerződés, és min-
denki megelĂŠgedĂŠsĂŠre szolgĂĄl, amĂ­g az automatikus mĹąkĂśdĂŠs tĂĄrgyiasult eredmĂŠnye 
egy üveg ásványvíz. És ha a gépből egy adag heroin is ugyanígy hozzáférhető? Be kell-e 
tiltani, kell-e szigorĂşan szabĂĄlyozni az automatĂĄkat pusztĂĄn azĂŠrt, mert illegĂĄlis tevĂŠ-
kenysÊg folytatåsåra is alkalmasak?3 A jogi munkåk kÜzßl kiemelkedik Primavera De 
Filippi ĂŠs Aaron Wright 2018-as munkĂĄja, amely a tĂŠma feldolgozĂĄsĂĄhoz alapmĹąkĂŠnt 

1 A blokklånc-technológiåhoz kapcsolódó egyes fogalmakról ld. pÊldåul: GlavaNits Judit, kiråly 
Péter Bálint: A blockchain-technológia alkalmazásának jogi előkérdései: a fogalmi keretek pontosítá-
sának szükségessége, Jog-Állam-Politika, 2018/3, 173–183.
2 Aaron WriGHt, Primavera De FiliPPi: Decentralized Blockchain Technology and the Rise of Lex Cry-
ptographia (March 10, 2015), https://ssrn.com/abstract=2580664 or http://dx.doi.org/10.2139/
ssrn.2580664 
3 Max raskiN: The Law and the Legality of Smart Contracts, Georgetown Law Technology Review, 
Vol. 1:2, 306.



Blockchain-rendszerĹą megoldĂĄsok a munkaviszonyokban 

23 || 2020

szolgál jogászok számára.4 A szerzők széles körben térképezik fel a blokkláncokban 
rejlő szabályozási kihívásokat, ugyanakkor felhívják a figyelmet az alkalmazhatóság 
szĂŠles skĂĄlĂĄjĂĄra is.

A blokklåncok legsikeresebb pÊldåi ez idåig a pÊnzßgyi eszkÜzÜk. Az Európai Unió 
BĂ­rĂłsĂĄga a C-264/14. sz. Ă­tĂŠletĂŠben mĂĄr megĂĄllapĂ­totta, hogy a bitcoin5 virtuĂĄlis deviza 
szerződéses fizetőeszköznek minősül, az azt elfogadó gazdasági szereplők közötti köz-
vetlen fizetőeszköz. Hazánkban az MNB 2014. február 19-én sajtóközleményt adott ki, 
amelyben kifejezetten felhívja a fogyasztók figyelmét a virtuális fizetőeszközökben rejlő 
veszĂŠlyekre.6 Pfeffer Zsolt szintĂŠn kiemeli (mĂĄr 2017-ben), hogy nem hagyhatĂł figyelmen 
kĂ­vĂźl a jogi bizonytalansĂĄg, hiszen a Bitcoin megkĂśnnyĂ­ti az adĂłelkerĂźlĂŠst, a pĂŠnzmosĂĄst 
ĂŠs az illegĂĄlis kereskedelmet (pĂŠldĂĄul drogĂźgyletek lebonyolĂ­tĂĄsĂĄt), Ă­gy a vele szemben 
kilĂĄtĂĄsba helyezett kormĂĄnyzati fellĂŠpĂŠsek is kockĂĄzatossĂĄ teszik a felhasznĂĄlĂĄsĂĄt.7 
A fentiek ellenére a virtuális fizetőeszközöket használók száma folyamatosan növekszik. 
A Cambridge Center for Alternative Finance kutatåsi jelentÊse alapjån azon gazdasågi 
tĂĄrsasĂĄgok, akik maguk is hasznĂĄlnak blokklĂĄnc-alapĂş pĂŠnztĂĄrcĂĄt, 69 szĂĄzalĂŠkban 

4 Primavera De FiliPPi, Aaron WriGHt: Blockchain and the Law. The Rule of Code, Harvard University 
Press, London, 2018, 74. 
5  A bitcoin egy nyílt forráskódú digitális fizetőeszköz, amelyet 2009. január 3-án egy ismeretlen 
(internetes nevĂŠn Satoshi Nakamoto) bocsĂĄtott ki, kĂśzvetlenĂźl a 2008-as amerikai bankvĂĄlsĂĄg 
kirobbanása után. Az elnevezés vonatkozik a fizetőeszközt kezelő nyílt forráskódú szoftverre, 
ĂŠs az azzal lĂŠtrehozott elosztott hĂĄlĂłzatra is.
6 MNB: Az MNB kockĂĄzatosnak tartja a fizetĂŠsre hasznĂĄlhatĂł virtuĂĄlis eszkĂśzĂśket, pĂŠldĂĄ-
ul a bitcoint. Elérhetőség: http://www.mnb.hu/sajtoszoba/sajtokozlemenyek/2014-evi-
sajtokozlemenyek/az-mnb-kockazatosnak-tartja-a-fizetesre-hasznalhato-virtualis-eszkozoket-
peldaul-a-bitcoint (letĂśltĂŠs ideje: 2018. 04. 04.)
7 PFeFFer Zsolt: A fizetÊsre hasznålható virtuålis eszkÜzÜk, Kodifikåció Ês KÜzigazgatås, 2017, 20. 

ForrĂĄs: www.statista.com (2018. jĂşnius 4.)

1. åbra. A blokklånc-pÊnztårcåt hasznålók szåmånak alakulåsa



ERDÉLYI JOGÉLET

| 24 04 |

kis- vagy mikrovállalkozások, és főként az USA-ban és Európában rendelkeznek szék-
hellyel.8 Nemsokára eljöhet az az idő, amikor a munkavállalók vagy érdekképviseleteik 
felvetik azt a kĂŠrdĂŠst, hogy a munkabĂŠrt kaphatjĂĄk-e kriptovalutĂĄban.9 

A jog Ês a jogi szabålyozås ÜrÜk dilemmåja, hogy a jogalkotó lassabban reagål a 
mindennapi élet eseményeire,10 mint amilyen gyorsan a gazdasági szereplők új és új 
megoldåsokat talålnak ki egy adott problÊmåra.11 A blokklåncok åltal nyújtott új lehe-
tőségek vajon felülmúlják-e a kockázatokat, vagy ahogyan egy internetes cikk fenyeget: 
a hackerek lesznek az új ügyvédek?12 Mit válaszolhat az előző bekezdésben feltett kérdés-
re – kérhető-e a munkabér bitcoinban – a vállalati jogtanácsos? A kérdés felvetése nem 
lenne ĂşjszerĹą, hiszen 2017 decemberĂŠben egy japĂĄn vĂĄllalat mĂĄr felajĂĄnlotta dolgozĂłi-
nak, hogy 2018 mĂĄrciusĂĄtĂłl fizetĂŠsĂźk egy rĂŠszĂŠt kĂŠrhetik bitcoinban.13 Ugyanakkor az 
Egyesült Államokban több szerző is felhívta a figyelmet arra, hogy (a kézirat lezárásakor) 
ennek az USA-ban nincsen meg a jogi lehetősége.14

A kÊrdÊs megvålaszolåsåhoz nemcsak munkajogi, hanem pÊnzßgyi jogi aspektuso-
kat is figyelembe kell venni, így a bitcoin (vagy bármely más virtuális fizetőeszköz, más 
nĂŠven kriptovaluta) konvertibilitĂĄsĂĄt, ĂĄllami elfogadĂĄsĂĄt.15 Ezen egyĂŠb aspektusokkal a 
következőkben csak érintőlegesen foglalkozom, amennyiben az befolyásolja a munkajogi 
megĂ­tĂŠlĂŠsĂŠt, vagy egyes kĂŠrdĂŠsek eldĂśntĂŠsĂŠben segĂ­tsĂŠget nyĂşjt. 

1.  Az okosszerződések és a digitális főkönyvi technológia 
A blokklánccal egy újfajta társadalmi kontrollviszony alapvető infrastrukturális 

eleme született meg.16 Az okosszerződések (smart contracts) alatt egy olyan blokkláncra 

8 Garrick HilemaN, Michel raucH: Global Cryptocurrency Benchmarking Study. Cambridge Center for 
Alternative Finance, University of Cambridge, Judge Business School, 2017, 48–50.
9 E körben érdekes kérdés lehet a munkajogi kártérítést illetően az, hogy a munkáltató kárté-
rítési felelőssége esetén van-e mód arra, hogy a kriptovalutában rendszeresen elért vagyoni 
juttatást – mint lehetséges vagyoni kárt – figyelembe vegyük. E körben látunk némi hasonló-
ságot a jogsértő módon nem adózó, ún. „fekete jövedelem” figyelembe vehetőségére vonatkozó 
gyakorlattal. A kérdésről lásd bővebben: treNyisáN Máté: A munkáltató kártérítési felelőssége a 
magĂĄnmunkajogban (kismonogrĂĄfia), Nemzeti KĂśzszolgĂĄlati Egyetem, Budapest, 2018, 86.
10 G. karácsoNy Gergely: Okoseszközök – okos jog?, Ludovika Egyetemi Kiadó, Budapest, 2020, 75–77.
11 G. karåcsoNy Gergely: A mestersÊges intelligenciåk szabålyozåsånak kÜzjogi kÊrdÊsei = A gazdasågi 
jogalkotĂĄs aktuĂĄlis kĂŠrdĂŠsei, szerk. GlavaNits Judit, DialĂłg Campus KiadĂł, Budapest, 2019, 56.
12 https://www.bitcoinbazis.hu/okosszerzodes-ugyved-vagy-hacker/ (letĂśltĂŠs ideje: 2020. 11. 03.)
13 https://www.inc.com/eric-mack/meet-publicly-traded-company-paying-employees-in-
bitcoin.html (letĂśltĂŠs ideje: 2020. 11. 03.)
14 Lásd például: Kayla mattHieWs: Why Employers Can’t Pay You in Cryptocurrency. https://
cointelegraph.com/news/why-employers-cant-pay-you-in-cryptocurrency (letĂśltĂŠs ideje: 2018. 
jĂşlius 13.)
15 A blokkláncon alapuló technológiák állami felhasználásának lehetőségeiről ld. még: 
GlavaNits Judit: Sustainable Public Spending Through Blockchain, European Journal of Sustainable 
Developement, 2020/4, 317–327.
16  Z. karvalics LĂĄszlĂł, NaGy GĂĄbor DĂĄniel: ProkrusztĂŠsz nĂŠlkĂźli vilĂĄg? BlokklĂĄnc ĂŠs tĂĄrsadalmi 
makroevolúció, Információs Társadalom, XVII. évf. (2017) 3. szám, 7–38.



Blockchain-rendszerĹą megoldĂĄsok a munkaviszonyokban 

25 || 2020

épülő alkalmazást, algoritmust értünk, amely bizonyos feltételek teljesülése esetén 
automatikusan végrehajt egy következményt. Az okosszerződés egy tranzakcióhoz kap-
csolĂłdĂłan leĂ­rja a megĂĄllapodĂĄst, az egyes felek tennivalĂłit, jogait ĂŠs kĂśtelezettsĂŠgeit, 
valamint annak vĂŠgrehajtĂĄsi rĂŠszleteit. Ezt ĂŠrtelmezhetjĂźk Ăşgy, mint a hagyomĂĄnyos 
szerződési feltételeket, azzal a különbséggel, hogy nem a megszokott szabad szöveges, 
jogĂĄszi megfogalmazĂĄsban Ă­rt ĂŠs ĂŠrtelmezett, hanem digitĂĄlisan kĂłdolt utasĂ­tĂĄsok for-
májában megjelenő rendszer.17 

Az okosszerződések nyilvántartása a blokklánc-rendszerben, vagy általánosabban a 
digitális főkönyvi rendszerben történik. A DLT (digital ledger technology) egy olyan hálózat, 
amelyben az adatok a hĂĄlĂłzat tagjai kĂśzĂśtt szinkronizĂĄlt mĂłdon megosztĂĄsra kerĂźlnek. 
A rendszer mŹkÜdÊsÊhez kapcsolatot szßksÊges lÊtesíteni Ês fenntartani a hålózat min-
den tagja kĂśzĂśtt, tovĂĄbbĂĄ lĂŠtre kell hozni egy konszenzuson alapulĂł algoritmust, amely 
alapjĂĄn a hĂĄlĂłzat tagjai rĂŠszt vesznek a hĂĄlĂłzaton keresztĂźl folytatott tevĂŠkenysĂŠgekben. 
Az elosztott főkönyvi rendszer lehet egyaránt privát vagy publikus, tehát nem kizárt, 
hogy például egy vállalat létrehozza a saját belső DLT alapú vállalatirányítási rendszerét. 
Innentől pedig már csak egy ugrás a munkavállalók, illetve a foglalkoztatási jogviszony 
egészének bevonása a hálózatba. Ehhez szükséges megvizsgálni, hogy a munkaszerző-
dĂŠsek, a munkaviszonyok digitalizĂĄlhatĂłak-e, kĂłdolhatĂłak-e egyĂĄltalĂĄn? 

Megjegyzendő, hogy az automatizált, elektronikus szerződéskötésnek és a digitali-
zĂĄlt munkaĂźgyi folyamatoknak mĂĄra a magyarorszĂĄgi gyakorlata is kialakulĂłban van. 
BĂĄr szĂĄmossĂĄgĂĄt ĂŠs elterjedtsĂŠgĂŠt vĂŠlelmezni nem lehet, de egy, a kĂśzelmĂşltban megje-
lent, nagyvállalati tapasztalatokra építő beszámoló e folyamatok tényleges gyakorlatát 
ĂŠs jogi feltĂŠteleit rĂŠszletesen mutatta be.18

A bitcoin tömeges elterjedése óta élő a kérdés: vajon a szerződések teljes egészében 
kódolhatóak-e? Első ránézésre a hagyományos és az okosszerződések nem különböz-
nek: mindkét esetben a felek először megegyeznek a szerződéses feltételekben, közös, 
egybehangzó akaratnyilatkozatot tesznek. Okosszerződések esetében a szöveges írás-
ba foglalĂĄs helyett a felek egy kĂłdba rĂśgzĂ­tve tĂĄroljĂĄk a megegyezĂŠsĂźket, amelyet egy 
blokklĂĄnc-rendszer mĹąkĂśdtet. Vita esetĂŠn a felek akĂĄr Ăşjra is tĂĄrgyalhatjĂĄk a megĂĄlla-
podĂĄsukat, vagy fordulhatnak jogvitĂĄjuk rendezĂŠse ĂŠrdekĂŠben bĂ­rĂłsĂĄghoz. Az eltĂŠrĂŠs 
főként a „szövegezésben” rejlik: az okosszerződések esetén nem a hagyományos jogi 
formulĂĄk ĂŠs fordulatok kerĂźlnek rĂśgzĂ­tĂŠsre, hanem valamely programnyelv kĂśzvetĂ­tĂŠ-
sĂŠnek parancssorokkĂĄ formĂĄlĂłdik a megegyezĂŠs (pĂŠldĂĄul az Ethereum blokklĂĄnc Soli-
dity-programnyelvét sokan használják okosszerződések rögzítésére)19. A szerződések 
ilyen módon automatizáltak lesznek, így nehezebb őket módosítani, illetve a megbeszélt 
teljesítéstől eltérni, mint egy hagyományos szerződés esetében, sőt, magának az automa-
tizĂĄlt teljesĂ­tĂŠsi folyamatnak az egyoldalĂş megĂĄllĂ­tĂĄsĂĄra sincsen mĂłdja a feleknek, csak 

17 A kifejezés első használója Nick Szabó jogász-informatikus, aki 1994-ben megjelent cik-
kében írta le először a ma ismert és használt okosszerződések működésének alapelveit. Nick 
szaBo: Smart Contracts, 1994, http://www.fon.hum.uva.nl/rob/ Courses/InformationInSpeech/
CDROM/Literature/LOTwinterschool2006/szabo.best.vwh.net/smart.contracts.html (letĂśltĂŠs 
ideje: 2019. 10. 24.)
18 czirók Andrea, NyerGes Éva: Digitalizáció a munkajogban: Elektronikus munkaügyi folyamatok a 
„most” generációja számára, Munkajog, 2018/2, 33–38.
19 De FiliPPi, WriGHt: Blockchain…, i. m., 74. 



ERDÉLYI JOGÉLET

| 26 04 |

ha ebben közösen állapodnak meg, és maga az eredeti kód is tartalmazott lehetőséget 
a módosításra. Az okosszerződések lehetővé teszik a harmadik felekkel való hatékony, 
dinamikus kapcsolatteremtést is (ilyenképpen lehetővé válik tőzsdei adatok, bankszám-
la-információk vagy akár időjárási adatok bekapcsolása a rendszerbe), így a szerződés 
képes külső hatásokra reagálni a felek jogviszonyán belül.20 

2.  A digitális munkaszerződés létrehozása és működése
Az interneten bruttó 63 Ft-ért lehet ma munkaszerződésre vonatkozó mintát vá-

sárolni, éppúgy, mint egy kiló kenyeret.21 A Munka törvénykönyvéről szóló 2012. évi 
I. tv. (Mt.) 45. §-a meghatározza a munkaszerződésben rögzítendő kötelező adattartalmat, 
amely értelmében a munkaszerződésben a feleknek meg kell állapodniuk a munkavál-
lalĂł alapbĂŠrĂŠben ĂŠs munkakĂśrĂŠben, ĂŠs adott esetben a munkaviszony tartamĂĄban ĂŠs a 
munkavĂŠgzĂŠs helyĂŠben, bĂĄr a kĂŠt utĂłbbi nĂŠlkĂźl is ĂŠrvĂŠnyesen lĂŠtrejĂśn a munkaviszony 
[Mt. 45. § (2) Ês (3) bekezdÊsek].22 Csupån a fentiek alapjån úgy tŹnhet, hogy munkaszer-
ződést kötni nem is olyan bonyolult dolog, már csak a kötelező tartalom kódolására van 
szĂźksĂŠg az elektronikus megkĂśtĂŠshez23 ĂŠs automatikus vĂŠgrehajtĂĄshoz. Ha ez Ă­gy lenne, 
akkor a blokklánc-technológiát először ebben a szektorban vezették volna be, hiszen a 
munkaszerződés a világ egyik leggyakoribb szerződéstípusa. 

A valósåg azonban egy kicsit årnyaltabb. Az Mt. 46. § (1) bekezdÊs tovåbbi tåjÊkozta-
tási kötelezettséget ír elő a munkáltató számára: írásban kell tájékoztatni a munkavállalót 
a további fontos foglalkoztatási feltételekről, így a napi munkaidőről, az alapbéren túli 
munkabérről és egyéb juttatásokról, a munkabérről való elszámolás módjáról, a mun-
kabĂŠrfizetĂŠs gyakorisĂĄgĂĄrĂłl, a kifizetĂŠs napjĂĄrĂłl, a munkakĂśrbe tartozĂł feladatokrĂłl, a 
szabadság mértékéről, számítási módjáról és kiadásának, valamint a munkáltatóra és a 
munkavállalóra irányadó felmondási idő megállapításának szabályairól, továbbá arról, 
hogy a munkáltató kollektív szerződés hatálya alá tartozik-e, valamint a munkáltatói 
jogkĂśr gyakorlĂłjĂĄrĂłl.24 Ha a fenti pontokat megvizsgĂĄljuk abbĂłl a szempontbĂłl, hogy 

20  ld: https://blockchainhub.net/blockchain-oracles/ (letĂśltĂŠs ideje: 2020. 11. 03.)
21 Elérhetőség: https://www.alter.hu/munkaszerzodes-a-3-3-lapos-uj_58546  (letöltés ideje: 
2020. 11. 03.)
22 A munkaszerződés tartalmi elemeiről, a munkajogviszony létesítéséről részletesen lásd: 
BaNkó Zoltån: A munkajogviszony lÊtesítÊse Ês kezdete = kiss GyÜrgy (szerk.): Munkajog, Dialóg 
Campus, Budapest, 2020, 163–185., illetve FereNcz Jácint, FoDor t. Gábor, kuN Attila, mészáros 
Katalin Éva: A munkaviszony létesítése, Wolters Kluwer, Budapest, 2016.
23 Ezzel párhuzamosan felvetődhetnek az írásba foglaláshoz kötött munkajogi jognyilatkozatok 
elektronikus dokumentumba foglalĂĄsĂĄval kapcsolatos dilemmĂĄk is (ld. a problĂŠmĂĄrĂłl az Mt. 
vonatkozĂĄsĂĄban: Petrovics ZoltĂĄn: Az elektronikus dokumentum kĂśrĂźli dilemmĂĄk a munkajogban, 
HR & Munkajog, 2016/10, 9–13.
24 A munkáltató tájékoztatási kötelezettségéről lásd bővebben: siPka Péter, zaccaria Márton Leó: 
Megújuló tájékoztatási kötelezettség a munkajogi viszonyokban és azokon túl, Munkajog, 2019/3, 1–8. 
és HuNGler Sára: A munkáltatói kártérítési felelősség, mint a szociális integráció akadálya: Az autonóm 
szociĂĄlis pĂĄrbeszĂŠd ĂştjĂĄn szĂźletett keretmegĂĄllapodĂĄsok ĂĄtĂźltetĂŠsi nehĂŠzsĂŠgei a magyar munkajogba, 
Gazdaság és Jog, 2020/3, 5–11.



Blockchain-rendszerĹą megoldĂĄsok a munkaviszonyokban 

27 || 2020

elektronikusan rögzíthetőek, illetőleg kódolhatóak-e, akkor egyértelműen igen a válasz. 
Ugyanakkor kĂŠrdĂŠs, hogy ha a munkavĂĄllalĂłval ezt egy kĂłd formĂĄjĂĄban kĂśzĂśljĂźk, az 
maradÊktalanul kielÊgíti-e a tåjÊkoztatåsi kÜtelezettsÊget? Állåspontom szerint semmi-
képpen, így a tájékoztatási kötelezettség bizonyos értelemben az okosszerződések egyik 
megoldandĂł problĂŠmĂĄja lehet, hiszen az adminisztrĂĄciĂłs kĂśtelezettsĂŠgek megszegĂŠse 
felveti a munkáltató kártérítési felelősségét is.25 Ha a gazdasági társaságok a blockchain 
(vagy DLT) rendszerekben rejlő tagadhatatlan előnyöket (automatizált szerződés-vég-
rehajtás, visszamenőleg közel módosíthatatlan tartalom, tömeges alkalmazhatóság) a 
gazdasĂĄgi ĂŠlet tĂśbb terĂźletĂŠn is sikerrel alkalmazzĂĄk, felmerĂźl a kĂŠrdĂŠs, hogy a mun-
kaviszonyok világában is megjeleníthetőek-e ezen előnyök. Könnyű elképzelni, hogy 
a munkaviszonyok egyes elemei automatizĂĄlhatĂłak lehetnĂŠnek a fenti definĂ­ciĂł ĂŠs a 
már ismertetett szerződéskötési alapszabályok alapján: ha egy munkavállaló blokkol 
reggel és délután, a feladatait (elektronikusan) ellenőrizhetően teljesíti, akkor a hónap 
végén a munkabérét a rendszer automatikusan számfejt(het)i. A munkaidő-nyilvántartás 
meglévő problémái, vagy azok egy része a digitális nyomon követés révén orvosolha-
tĂłak lehetnek, a digitĂĄlis nomĂĄdsĂĄg mint munkavĂŠgzĂŠsi forma tĂśbb terĂźleten is teret 
hódíthatna, költséget megtakarítva a munkáltatónak. Sőt, felmerülhet egyes munkavi-
szonyok vagy még inkább feladatkörök esetében a munkaszerződések okosszerződéssé 
valĂł alakĂ­tĂĄsĂĄnak kĂŠrdĂŠse is, amely viszont mĂĄr munkajogi alapelvi kĂŠrdĂŠseket vet 
fel. A nagyvållalatoknål tÜmegesen alkalmazott, hasonló munkakÜrben foglalkoztatott 
munkavállalók (például gyártósoron dolgozó összeszerelők, operátorok) esetében a 
gyakorlatban nagy hasonlóság fedezhető fel a munkaszerződések tartalmában: a mun-
kaidő, a munkavégzés helye, a bérezés módja (sőt talán a munkabér is), a munkáltatói 
jogok gyakorlĂłja, a felek jogai ĂŠs kĂśtelezettsĂŠgei tekintetĂŠben mutatkozĂł Ăśsszhang felveti 
a munkajogi ÁSZF-ek kÊrdÊsÊt. Mårpedig ha a munkajogban felfedezni vÊlnÊnk ilyen 
jellegű szerződéseket, azok könnyen átalakíthatóak lennének okosszerződésekké, és így 
a blockchain- (vagy DLT-) rendszerhez valĂł csatlakoztatĂĄsuk csupĂĄn technikai kĂŠrdĂŠssĂŠ 
egyszerĹąsĂśdhetne. 

IrodalomjegyzĂŠk
1. BaNkó Zoltån: A munkajogviszony lÊtesítÊse Ês kezdete = Munkajog, szerk. kiss GyÜrgy, Dialóg 

Campus, Budapest, 2020.
2. czirĂłk aNDrea, NyerGes ĂŠva: DigitalizĂĄciĂł a munkajogban: Elektronikus munkaĂźgyi folyamatok 

a „most” generációja számára, Munkajog, 2018/2. 
3. De FiliPPi, Primavera, WriGHt, Aaron: Blockchain and the Law. The Rule of Code, Harvard Uni-

versity Press, London, 2018.
4. FereNcz Jácint, FoDor t. Gábor, kuN Attila, mészáros Katalin Éva: A munkaviszony létesítése, 

Wolters Kluwer, Budapest, 2016.

25 siPka Péter: A munkáltatói kárfelelősség alakulása a bírói gyakorlat tükrében, HVG-ORAC, Bu-
dapest, 2015, 155.



ERDÉLYI JOGÉLET

| 28 04 |

5. G. karåcsoNy Gergely: A mestersÊges intelligenciåk szabålyozåsånak kÜzjogi kÊrdÊsei = A gazdasågi 
jogalkotĂĄs aktuĂĄlis kĂŠrdĂŠsei, szerk. GlavaNits Judit, DialĂłg Campus KiadĂł, Budapest, 2019.

6. G. karácsoNy Gergely: Okoseszközök – okos jog?, Ludovika Egyetemi Kiadó, Budapest, 2020.
7. GlavaNits Judit, király Péter Bálint: A blockchain-technológia alkalmazásának jogi előkérdései: 

a fogalmi keretek pontosításának szükségessége, Jog – Állam – Politika, 2018/3. 
8. GlavaNits Judit: Sustainable Public Spending Through Blockchain, European Journal of Sus-

tainable Developement, 2020/4. 
9. HilemaN, Garrick, raucH, Michel: Global Cryptocurrency Benchmarking Study. Cambridge Center 

for Alternative Finance, University of Cambridge, Judge Business School, 2017. 
10. HuNGler Sára: A munkáltatói kártérítési felelősség, mint a szociális integráció akadálya: Az au-

tonĂłm szociĂĄlis pĂĄrbeszĂŠd ĂştjĂĄn szĂźletett keretmegĂĄllapodĂĄsok ĂĄtĂźltetĂŠsi nehĂŠzsĂŠgei a magyar 
munkajogba, GazdasĂĄg ĂŠs Jog, 2020/3.

11. Petrovics ZoltĂĄn: Az elektronikus dokumentum kĂśrĂźli dilemmĂĄk a munkajogban, HR & Munka-
jog, 2016/10.

12. PFeFFer Zsolt: A fizetÊsre hasznålható virtuålis eszkÜzÜk, Kodifikåció Ês KÜzigazgatås, 2017. 
13. raskiN, Max: The Law and the Legality of Smart Contracts, Georgetown Law Technology Review, 

Vol. 1:2. 
14. siPka Péter: A munkáltatói kárfelelősség alakulása a bírói gyakorlat tükrében, HVG-ORAC Lap- 

ĂŠs KĂśnyvkiadĂł Kft., Budapest, 2015.
15. siPka PĂŠter, zaccaria MĂĄrton LeĂł: MegĂşjulĂł tĂĄjĂŠkoztatĂĄsi kĂśtelezettsĂŠg a munkajogi viszonyokban 

ĂŠs azokon tĂşl, Munkajog, 2019/3. 
16. treNyisáN Máté: A munkáltató kártérítési felelőssége a magánmunkajogban (kismonográfia), 

Nemzeti KĂśzszolgĂĄlati Egyetem, Budapest, 2018.
17. WriGHt, Aaron, De FiliPPi, Primavera: Decentralized Blockchain Technology and the Rise of Lex 

Cryptographia (March 10, 2015), SSRN: https://ssrn.com/abstract=2580664 or http://dx.doi.
org/10.2139/ssrn.2580664 

18. Z. Karvalics LĂĄszlĂł, Nagy GĂĄbor DĂĄniel: ProkrusztĂŠsz nĂŠlkĂźli vilĂĄg? BlokklĂĄnc ĂŠs tĂĄrsa-
dalmi makroevolĂşciĂł, InformĂĄciĂłs TĂĄrsadalom, XVII. ĂŠvf., 2017/3.

EgyĂŠb hivatkozĂĄsok
1. http://www.mnb.hu/sajtoszoba/sajtokozlemenyek/2014-evi-sajtokozlemenyek/az-mnb-koc-

kazatosnak-tartja-a-fizetesre-hasznalhato-virtualis-eszkozoket-peldaul-a-bitcoint 
2. https://blockchainhub.net/blockchain-oracles/ 
3. https://www.alter.hu/munkaszerzodes-a-3-3-lapos-uj_58546
4. https://www.bitcoinbazis.hu/okosszerzodes-ugyved-vagy-hacker/ 
5. https://www.inc.com/eric-mack/meet-publicly-traded-company-paying-employees-in-bit-

coin.html
6. szaBo Nick: Smart Contracts, 1994, http://www.fon.hum.uva.nl/rob/ Courses/Informatio-

nInSpeech/CDROM/Literature/LOTwinterschool2006/szabo.best.vwh.net/smart.contracts.
html

7. Matthiews, Kayla: Why Employers Can’t Pay You in Cryptocurrency. https://cointelegraph.
com/news/why-employers-cant-pay-you-in-cryptocurrency 


";"""date"",""2021-01-21T06:38:44Z""
""pdf:PDFVersion"",""1.6""
""xmp:CreatorTool"",""Adobe InDesign 15.0 (Windows)""
""pdf:docinfo:title"",""ErdelyiJogelet-SAP2020-4.indd""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""language"",""hu""
""dc:format"",""application/pdf; version=1.6""
""pdf:docinfo:creator_tool"",""Adobe InDesign 15.0 (Windows)""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""ErdelyiJogelet-SAP2020-4.indd""
""xmp:CreateDate"",""2021-01-20T13:50:45Z""
""modified"",""2021-01-21T06:38:44Z""
""pdf:hasMarkedContent"",""true""
""xmp:ModifyDate"",""2021-01-21T08:38:44Z""
""trapped"",""False""
""meta:creation-date"",""2021-01-20T11:50:45Z""
""created"",""2021-01-20T11:50:45Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2021-01-20T11:50:45Z""
""resourceName"",""53""
""xmpMM:DerivedFrom:DocumentID"",""xmp.did:6f2accc8-8fc2-1047-8602-4bcd9123c7db""
""GTS_PDFXVersion"",""PDF/X-4""
""producer"",""Adobe PDF Library 15.0""
""pdf:docinfo:producer"",""Adobe PDF Library 15.0""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:docinfo:custom:GTS_PDFXVersion"",""PDF/X-4""
""access_permission:modify_annotations"",""true""
""dcterms:created"",""2021-01-20T11:50:45Z""
""Last-Modified"",""2021-01-21T06:38:44Z""
""dcterms:modified"",""2021-01-21T06:38:44Z""
""title"",""ErdelyiJogelet-SAP2020-4.indd""
""xmpMM:DocumentID"",""xmp.id:b86a6ba1-4aec-4047-a3a3-6289255c4ce1""
""Last-Save-Date"",""2021-01-21T06:38:44Z""
""pdf:docinfo:modified"",""2021-01-21T06:38:44Z""
""meta:save-date"",""2021-01-21T06:38:44Z""
""Content-Length"",""594588""
""Content-Type"",""application/pdf""
""xmp:MetadataDate"",""2021-01-21T08:38:44Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""pdf:producer"",""Adobe PDF Library 15.0""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""8""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""3162"",""3463"",""2236"",""3518"",""3672"",""3429"",""2993"",""2857""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""xmpMM:DerivedFrom:InstanceID"",""xmp.iid:91512ed7-7f9e-5b4f-ad1a-6cfdb3f9f187""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2021-01-20T11:50:45Z""
";https://scholar.google.com/scholar?start=450&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095341-1451;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;A General Framework for the Security Analysis of Blockchain Protocols;A Lewis;Pye, T Roughgarden  arXiv preprint arXiv:2009.09480, 2020  arxiv.org;;"… We suppose that each user is a deterministic computing device, which has amongst the actions

it can perform calls to certain oracles, as well as certain external … The permitter oracle need not

be implemented explicitly in the blockchain being modelled, and is a …";Cité 2 fois;Les 2 versions;[PDF] arxiv.org;https://arxiv.org/pdf/2009.09480.pdf?utm_campaign=ConsenSys%20Diligence&utm_source=hs_email&utm_medium=email&_hsenc=p2ANqtz-9syjEr6eOfKaTzHLqmYJYnNrQbNAA4bYsCZamlMBjA8f65_pfvV8c35FsfKbtbtwByA6Ko;"

 


[image: Cornell University]



We gratefully acknowledge support from
 the Simons Foundation and member institutions.





arXiv.org > cs.DC






Help | Advanced Search





All fields
Title
Author
Abstract
Comments
Journal reference
ACM classification
MSC classification
Report number
arXiv identifier
DOI
ORCID
arXiv author ID
Help pages
Full text






Search









PDF unavailable for
2009.09480...

The author has provided no source to generate PDF, and no PDF.

Link back to: arXiv, form interface, contact.




 
      
        
        
          
            
              	About
	Help


            

            
              	
                  





Click here to contact arXiv
                   Contact
                
                	
                  

Click here to subscribe
                   Subscribe
                
              
            
          
        
        
        
        
          
            
              	Copyright
	Privacy Policy


            

            
              	Web Accessibility Assistance
	
                  
                    arXiv Operational Status 

                    Get status notifications via
                    email
                    or slack
                  

                


            

          

        
 
        
      
    
";"""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""dc:title"",""No PDF for 2009.09480""
""Content-Encoding"",""UTF-8""
""resourceName"",""2009.09480.pdf""
""language"",""en""
""title"",""No PDF for 2009.09480""
""Content-Language"",""en""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=250&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095402-1713;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;[LIVRE][B] Information for Efficient Decision Making: Big Data, Blockchain and Relevance;KR Balachandran ;2020 books.google.com;;"… The chapter provides an overview of the con- cept of blockchain, the cryptocurrency, and their

relationships … The author describes this process in detail. Cryptoproducts such as cryptocurrency

form an essential part of blockchain technology implementation …";Autres articles;;null;;;;https://scholar.google.com/scholar?start=510&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095353-1495;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Signatures from sequential-OR proofs;M Fischlin, P Harasser, C Janson ; … on the Theory and Applications of …, 2020  Springer;;"… to build OR-proofs is based on an approach introduced by Cramer, Damgĺrd, and Schoenmakers

(CRYPTO'94), where the … We stress, however, that protocols designed in the global random oracle

model are not necessarily secure for non-programmable random oracles …";Cité 8 fois;Les 2 versions;[PDF] iacr.org;https://eprint.iacr.org/2020/271.pdf;"
A preliminary version of this paper appears in the proceedings of the 39th International Conference on the Theory
and Applications of Cryptographic Techniques (EUROCRYPT 2020), cŠ IACR 2020. This is the full version.

Signatures from Sequential-OR Proofs

Marc Fischlin Patrick Harasser Christian Janson

Cryptoplexity, Technische Universität Darmstadt, Germany
{marc.fischlin, patrick.harasser, christian.janson}@cryptoplexity.de

Saturday 29th February, 2020

Abstract. OR-proofs enable a prover to show that it knows the witness for one of many statements, or
that one out of many statements is true. OR-proofs are a remarkably versatile tool, used to strengthen
security properties, design group and ring signature schemes, and achieve tight security. The common
technique to build OR-proofs is based on an approach introduced by Cramer, DamgĂĽrd, and Schoen-
makers (CRYPTO’94), where the prover splits the verifier’s challenge into random shares and computes
proofs for each statement in parallel.

In this work we study a different, less investigated OR-proof technique, put forward by Abe, Ohkubo,
and Suzuki (ASIACRYPT’02). The difference is that the prover now computes the individual proofs
sequentially. We show that such sequential OR-proofs yield signature schemes which can be proved
secure in the non-programmable random oracle model. We complement this positive result with a
black-box impossibility proof, showing that the same is unlikely to be the case for signatures derived
from traditional OR-proofs. We finally argue that sequential-OR signature schemes can be proved secure
in the quantum random oracle model, albeit with very loose bounds and by programming the random
oracle.

Keywords. Sequential-OR proofs ¡ Zero-knowledge ¡ Signatures ¡ Non-programmable random oracle
model ¡ Quantum random oracle model

1



Contents
1 Introduction 3

1.1 OR-Proofs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Applications of OR-Proofs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3 Non-Programmable Random Oracles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.4 Sequential-OR Proofs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.5 Our Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.6 Further Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.7 Extension to the Quantum Random Oracle Model . . . . . . . . . . . . . . . . . . . . . . . 7

2 Preliminaries 7
2.1 Basic Notation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2 Random Oracle Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.3 Languages and Relations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.4 Interactive Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.5 3PC-Protocols and ÎŁ-Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3 Parallel-OR Proofs 14
3.1 Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.2 Parallel-OR Signatures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

4 Sequential-OR Proofs 17
4.1 Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.2 Sequential-OR Signatures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.3 Example: Post-Quantum Ring Signatures . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

5 Impossibility of parallel-OR Signatures in the Non-Programmable Random Oracle
Model 21

6 Security in the Quantum Random Oracle Model 27

A Additional Preliminaries 36
A.1 The Fiat-Shamir Heuristic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
A.2 Digital Signature Schemes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

B Proof of Theorem 4.1 38

C Proof of Theorem 4.2 46

D Sequential-OR Proofs: The 1-out-of-n case 50

E Example: Tight Signatures in the Non-Programmable Random Oracle Model 52

F Security Proof in the Quantum Random Oracle Model 53
F.1 Connecting Signature Forgeries and Measure-and-Reprogram . . . . . . . . . . . . . . . . . 53
F.2 Proving Sequential-OR Signatures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

2



1 Introduction
In a zero-knowledge ÎŁ-protocol between a prover P and a verifier V, the prover holds a statement x and
a witness w for x, and the verifier only x. Both parties engage in an interactive execution, resulting in
an initial commitment com sent by the prover, a verifier random challenge ch, and a final response resp
computed by the prover. With such a proof, P shows to V that x is true (in proof systems), or that it knows
a witness w for x (in proofs of knowledge). At the same time, the zero-knowledge property guarantees
that nothing beyond this fact is revealed.

1.1 OR-Proofs

Now assume that one has two interactive proof systems of the above form for two statements x0 and x1,
and a witness wb for xb, b ∈ {0, 1}. The goal is to combine them into a single protocol which proves the
logical OR of x0 and x1; that is, the prover should be able to convince a verifier that it holds a witness for
one of the two statements, ideally without revealing which one. The first instantiation of such general OR-
proofs, sometimes called CDS-OR proofs, was given by Cramer, DamgĂĽrd, and Schoenmakers [CDS94].
Their construction works under the assumption that the two protocols are special honest-verifier zero-
knowledge, meaning that a simulator S, given x and a random challenge ch at the outset, is able to
generate a verifier view (com, resp, ch) without knowing a witness for x, in such a way that this view is
indistinguishable from a genuine interaction between the real prover and an honest verifier using the given
challenge. The prover in the CDS-OR protocol from [CDS94] is described in Figure 1. For reasons that
will become apparent soon, we call such CDS-OR proofs also parallel-OR proofs.

An important observation is that the resulting protocol is witness indistinguishable, i.e., it does not
reveal for which statement the prover holds a witness. Moreover, since the resulting protocol is again
a ÎŁ-protocol, one can apply the Fiat-Shamir transform [FS87] to it and obtain a non-interactive version
or a signature scheme in the random oracle model. Also, the construction easily generalizes to the case
of 1-out-of-n proofs.

1.2 Applications of OR-Proofs

OR-proofs have turned out to be a very powerful tool in the design of efficient protocols. Early on they
have been identified as a means to thwart man-in-the-middle attacks [CD97] and, similarly in spirit, to
give designated-verifier proofs [JSI96]. The idea in both cases is to have the verifier send its public key
to the prover, who then shows that the statement x it originally wanted to prove is true or that it knows
the verifier’s secret key. This proof is still convincing for the verifier (who knows it is the only holder of
its secret key), but not transferable to other parties. Garay et al. [GMY03] apply the same idea to make
zero-knowledge proofs simulation-sound and non-malleable, by putting a verification key into a common
reference string (CRS). The prover then shows that the original statement x is true or that it knows the
secret to the verification key in the CRS.

The idea of giving a valid proof when knowing a witness for only one of several statements can also
be used in the context of group signatures [Cv91] and ring signatures [RST01]. Given a set of public
keys x1, . . . , xn, where the signer knows only one witness wi (their own secret key), an OR-proof allows to
sign anonymously on behalf of the entire group, and witness indistinguishability implies that the identity
of the signer remains hidden. This design strategy appears explicitly for example in the group signature
scheme of Camenisch [Cam97].

The OR-technique has also proved very useful in deriving tightly-secure schemes. This approach has
appeared in several works in the literature [HJ12, BHJ+15, GJ18]. The idea is to first derive tightly-
secure signature schemes from the OR-combination of some ÎŁ-protocols. These schemes are then used

3



Ppar-OR(1Îť; (x0, x1), (b, w)):

11: comb ←$ Pb(1λ;xb, w)
12: ch1−b ←$ {0, 1}`(λ)

13: (com1−b, resp1−b, ch1−b)←$ S1−b(1λ;x1−b, ch1−b)
14: return (com0, com1)

Ppar-OR(1Îť; (x0, x1), (b, w), (com0, com1), ch):

21: chb ← ch⊕ ch1−b

22: respb ←$ Pb(1λ;xb, w, comb, chb)
23: return (ch0, ch1, resp0, resp1)

Figure 1: Description of the prover algorithm Ppar-OR from the parallel-OR construction by Cramer et al. [CDS94] in the
standard model. On the left, generation of the first message com = (com0, com1). On the right, computation of the final
response resp = (ch0, ch1, resp0, resp1) answering the verifier challenge ch.

within higher-level solutions (like key exchange protocols), passing on the tight security guarantees to
these protocols.

1.3 Non-Programmable Random Oracles

Another important feature of the OR-technique is that it facilitates the design of schemes in the non-
programmable random oracle model. The general random oracle model comes with several remarkable
technical properties, rooted in the formalization of the hash function as a truly random, oracle-based
function. One of the most extraordinary consequences of this formalization is the programmability property
of the random oracle, saying that one can adaptively choose the answers to random oracle queries made
by the adversary. Indeed, the ability to change answers on the fly is a necessary feature of security proofs
of some signature schemes [FLR+10,FF13,ZCC+15,FH18]. In practice, however, hash functions are not
programmable and their values are fixed. Therefore, one would ideally prefer to forgo the programming of
random oracle replies.

The fact that the OR-technique can be used to bypass the programmability issues with the random
oracle model can already be observed in the early constructions of ÎŁ-protocols, namely, the Okamoto
variant [Oka93] of the Schnorr signature scheme [Sch91] and the Guillou-Quisquater variant [GQ88] of the
Fiat-Shamir signature protocol [FS87]. In these variants, based on number-theoretic specifics, one uses
“embedded” OR-proofs which allow to simulate signatures without having to program the random oracle,
as opposed to [Sch91, FS87] and explicitly carried out in [PS00]: One can then simply use the known
witness to generate signatures.

Unfortunately, the security proofs of the signature schemes in [Oka93,GQ88] still need programming
at another step. Namely, in order to show that the adversary cannot forge signatures, one rewinds the
execution and re-programs the random oracle in order to extract a witness (a technique called forking
in [PS00]). This also comes with a loose security bound. Abdalla et al. [AABN02] overcome the forking
technique by considering passively-secure identification schemes, where the adversary is allowed to see
transcripts of honest executions. Still, they program the random oracle when simulating signatures.

Later, Abdalla et al. [AFLT16] used the notion of lossy identification schemes to give non-forking
security proofs for signatures derived via the Fiat-Shamir heuristic. Lossiness here roughly means that
valid statements x are indistinguishable from so-called lossy ones, for which it is statistically impossible to
find convincing proofs. This idea has later been adopted by lattice-based and LWE-based signature schemes
such as [Lyu12,BG14] (in the classical random oracle model) or the TESLA signature scheme [ABB+17]
(in the quantum random oracle model [BDF+11]). Still, all approaches program the random oracle in
order to be able to simulate signatures.

4



Pseq-OR(1Îť; (x0, x1), (b, w)):

11: comb ←$ Pb(1λ;xb, w)
12: ch1−b ← H(b, x0, x1, comb)
13: (com1−b, resp1−b, ch1−b)←$ S1−b(1λ;x1−b, ch1−b)
14: chb ← H(1− b, x0, x1, com1−b)
15: respb ←$ Pb(1λ;xb, w, comb, chb)
16: return (com0, com1, resp0, resp1)

Figure 2: Description of the prover algorithm Pseq-OR from the sequential-OR construction by Abe et al. [AOS02] in the random
oracle model.

1.4 Sequential-OR Proofs

The above construction is the classical technique to combine ÎŁ-protocols and prove OR-statements, but
it is not the only possible solution. Indeed, there is at least one other way to prove the disjunction of two
or more statements in the random oracle model, which in its spirit already appears in a work by Rivest,
Shamir, and Tauman [RST01]. Here, we follow the exposition given by Abe, Ohkubo, and Suzuki [AOS02]
in the context of group signature schemes, and call this approach the sequential-OR technique.

In this construction, the non-interactive prover computes the individual proofs sequentially, starting
with the commitment comb for the statement xb for which it knows the witness wb. Next it derives the
challenge ch1−b for the proof of x1−b (with unknown witness) as the hash value of comb. This in turn allows
the OR-prover to simulate a view (com1−b, resp1−b, ch1−b) for x1−b with this predetermined challenge, as
done in parallel-OR proofs. The simulated commitment com1−b again yields the challenge chb for the first
proof through the hash function, which the prover now can answer with a valid response respb since it
knows the witness wb. The details of the prover in the sequential-OR protocol from [AOS02] are described
in Figure 2.

Note that this technique generalizes to the 1-out-of-n case (we provide all details in Appendix D). In
fact, Abe et al. [AOS02] and follow-up works like [LWW04,BLO18], use this more general version of the
sequential-OR technique to build group signature schemes, yet still programming the random oracle to fork
and extract. The paradigm proposed by Abe et al. has also been applied in the area of cryptocurrencies, in
particular Monero [vS13] and Mimblewimble [Jed16,Poe16]. There, in order to prevent overflow attacks,
it is necessary to prove that committed values fall within a specific range. One instance of such range
proofs uses a special type of ring signature, called borromean ring signature [MP15], which is based on
ideas presented in [AOS02]. Observe that, in the aforementioned range proofs, borromean signatures have
since been superseded by more efficient bulletproofs [BBB+18].

1.5 Our Results

At first glance, the sequential-OR technique does not seem to give any significant advantage over the
parallel version. Both protocols are based on the idea that one can easily give a proof for a statement for
which the witness is known, and simulate the proof for the other statement where the challenge is known
in advance. This, however, misses one important point if we combine these two approaches with the idea
of lossy statements as in the work by Abdalla et al. [AFLT16]: We show that signatures derived from
sequential-OR proofs are secure in the non-programmable random oracle model, whereas those originating
from parallel-OR proofs do not seem to have a security proof in this model.

5



The signature scheme in the sequential-OR case is based on two valid statements x0 and x1 (the public
keys), for which we know one of the two witnesses wb (one of the secret keys). A signature for a message m
is basically a sequential-OR proof, where m is included in the hash evaluations. In contrast to the proof
in [AOS02], which is based on forking, we can now reduce unforgeability to a decisional problem about
the languages. This allows us to avoid rewinding and re-programming the random oracle.

The idea of our proof in the sequential-OR case can be illustrated by looking at the honest signer
first. If one was able to observe the signer’s random oracle queries, then their order reveals which witness
the signer is using: The signer first queries the commitment comb of the instance xb for which it knows
the witness wb. We will use the same idea against the adversary, helping us to decide if some random
input x1−b is in the language or not. If x1−b is not in the language, and thus does not have a witness, the
special soundness of the ÎŁ-protocol guarantees that the adversary will never make the first query about
this part, since it will then not be able to answer the random challenge.1 Hence, by merely observing
the adversary’s queries, we can decide membership of x1−b. We use the other part xb in the key and its
witness wb to simulate signatures without programming the random oracle. But we need to make sure
that the adversary is not biased by our signatures. This follows from the witness indistinguishability of
the proofs (against an adversary who cannot observe random oracle queries).

We next argue that it is in general hard to show that the parallel-OR technique of Cramer et al. [CDS94]
yields a secure signature scheme in the non-programmable random oracle model. Our result assumes a
black-box reduction R transforming any (PPT or unbounded) adversary against the signature scheme into
a solver of some problem assumed to be hard, and makes a mild assumption about the zero-knowledge
simulators of the languages (namely, that they work independently of how the statements x are generated).
Remarkably, we do not make any stipulations about the reduction’s executions of the adversary instances:
The reduction can run an arbitrary (bounded) number of instances of the adversary, and there are no
restrictions on the inputs of these instances or their scheduling. However, the reduction R can only use
the external random oracle.

Our approach is based on the meta-reduction technique [GMR88,BV98,PV05]. That is, we start with
an unbounded adversary A, who breaks the signature scheme easily with its super-polynomial power by
computing a secret key and signing as the honest prover would. This means that the reduction R also
solves the underlying problem when interacting with A. Afterwards, we show how to simulate A efficiently,
resulting in an efficient algorithm solving the problem directly. This implies that there cannot exist such
a reduction R in the first place.

The crucial difference between the sequential and the parallel version of the OR-technique is that in
the latter case observing the random oracle queries of the adversary does not reveal which witness is being
used. By the zero-knowledge property one cannot distinguish real and simulated sub-proofs in the parallel
case. Indeed, our negative result relies exactly on this zero-knowledge property, taking advantage of the
fact that the random oracle is external to the reduction.

1.6 Further Related Work

The issue of non-programmability of random oracles also appears in recent works related to Canetti’s
universal composability (UC) framework [Can01]. In this model, random oracles can be cast as an ideal
functionality FRO, and protocols can be developed in the hybrid setting where FRO is present. A technical
consequence of this design choice is that the random oracle is programmable, and a compositional con-
sequence is that one would need a fresh random oracle for each protocol instance. Therefore, the global
random oracle model [CJS14], based on ideas of global set-ups [CDPW07,DSW08], defines a random oracle
functionality GsRO which can be used by all protocols, obliterating also the programmability of the random
oracle in this model.

1One can think of this as a very lossy mode.

6



We stress, however, that protocols designed in the global random oracle model are not necessarily secure
for non-programmable random oracles. The discrepancy lies in the distinction between the model and the
security proof: In the global random oracle model, one may no longer be able to program the random
oracle when devising a simulator in the model, but a reduction may still program the random oracle in the
security proof showing that the simulator is good. Indeed, this can be observed in the security reductions
in [CDG+18] proving that all signature schemes which have a stand-alone proof of unforgeability in the
“isolated” random oracle model, including schemes with a security reduction via programming, remain
secure in the strict global random oracle model GsRO.

The impossibility of proving the security of specific types of signatures derived via the Fiat-Shamir
transform in the non-programmable random oracle model has already been discussed in prior works, e.g.,
[FF13, FH16]. These works usually make some restrictions on the reduction being ruled out (like key
preservation or being single-instance), whereas we do not need any such condition. We remark here that
our impossibility result for parallel-OR signatures does likely not follow in a general way from these results,
since the same approach fails in the sequential-OR case.

In terms of OR-proofs, Ciampi et al. [CPS+16a], based on an earlier approach by Lindell [Lin15], use the
OR-technique to build non-interactive zero-knowledge proofs from ÎŁ-protocols in the non-programmable
random oracle model. For technical reasons they also need a common reference string, which is used to
form the OR-language. Note that this is orthogonal to our goal here, where we aim to build OR-proofs for
two languages in the non-programmable random oracle model. In another work, Ciampi et al. [CPS+16b]
consider extensions of parallel-OR proofs where (some of) the languages are not specified yet when the
execution starts. This includes the solution in the common reference string model in [CPS+16a].

1.7 Extension to the Quantum Random Oracle Model

The results discussed so far are in the classical random oracle model. In terms of the quantum random
oracle model (QROM), introduced by Boneh et al. [BDF+11], the situation regarding OR-proofs is less
scrutinized. Our approach in the (classical) sequential-OR case is based on the observability of queries to
the random oracle, a technique that usually does not carry over to the QROM because of superposition
queries. In the parallel-OR case, we have seen that observability may not even help in the classical setting.

Fortunately, there have been two recent results regarding the security of Fiat-Shamir protocols in the
QROM [LZ19,DFMS19], bypassing previous negative results concerning the Fiat-Shamir transform in this
model [DFG13,ARU14]. These works both yield a non-tight bound, but give an immediate solution for
the parallel-OR case in the QROM. There, one first combines the two interactive proofs via the parallel-
OR construction to get an interactive Fiat-Shamir proof, and then applies these techniques. We show
in Section 6 that one can also prove security of signatures derived from the sequential-OR construction
in the QROM via the measure-and-reprogram technique described in [DFMS19]. The price we pay is
that we inherit the loose security bound from the solution in [DFMS19] and we, like all currently known
constructions in the QROM, need to program the quantum random oracle.

2 Preliminaries

2.1 Basic Notation

We denote by N = Z≥0 the set of non-negative integers, and by λ ∈ N the security parameter (often written
in unary notation as 1λ). A function µ : N → R is called negligible if, for every constant c ∈ R>0, there
exists λc ∈ N such that, for every λ ∈ N with λ ≥ λc, we have µ(λ) ≤ λ−c. For a random variable X, we
write x←$ X to denote that x is a random variate of X. For a finite set S of size |S|, we use s←$ S as a
shorthand for s←$ US , where US is a random variable uniformly distributed over S. The arrow ← will be

7



used for assignment statements. We denote the length of a string x ∈ {0, 1}∗ by |x|, and we write ε for the
empty string. We consider an injective, efficiently computable, efficiently reversible, and length-increasing
encoding function ({0, 1}∗)∗ → {0, 1}∗. This allows us to represent sequences of strings again as strings,
and will be tacitly used throughout the paper.

In this work we use the computational model of probabilistic oracle Turing machines, also called
algorithms. We assume that they are equipped with a separate security parameter tape containing the
value 1Îť. The running time of algorithms, which is intended to be bounded by the worst case, is a function of
the security parameter input length only. A uniform algorithm is called probabilistic polynomial-time (PPT)
if its running time is bounded by a polynomial, whereas a non-uniform algorithm is PPT if it corresponds
to an infinite sequence of Turing machines, indexed by the security parameter Îť, whose description sizes
and running times are bounded by a polynomial in Îť. Queries to the oracles always count as one operation
each. For an algorithm A, we denote by AO(1Îť;x) the random variable representing the output of A when
run on security parameter λ and input x ∈ {0, 1}∗, with access to oracles O = (O1, . . . ,Ot).

We use ⊥ as a special symbol to denote rejection or an error, and we assume that ⊥ /∈ {0, 1}∗. Both
inputs and outputs of algorithms can be ⊥, and we convene that if any input to an algorithm is ⊥, then
its output is ⊥ as well. Double square brackets J·K enclosing boolean statements return the bit 1 if the
statement is true, and 0 otherwise.

2.2 Random Oracle Model

Let ` : N → N be a polynomial-time computable function. For a security parameter λ ∈ N, a random
oracle (RO) [BR93,CGH98] is an oracle H that implements a function randomly chosen from the space
of all functions {0, 1}∗ → {0, 1}`(λ), to which all parties have access. In other words, it is an oracle that
answers every query with a truly random response chosen from the range {0, 1}`(Îť). For every repeated
query the random oracle consistently returns the same output.

Constructions established and statements proved in the presence of a RO are said to hold in the random
oracle model (ROM). Throughout the paper, whenever a security game is set in the ROM, we assume that
at the beginning of the experiment a random oracle is sampled uniformly from the aforementioned function
space, and then used throughout the experiment. In this setting, it will sometimes be necessary to record
queries to the random oracle H, and we will do so via a set QH: If (i, x) ∈ QH, this means that the i-th
query to H was x.

We also define the “zero oracle” as a function Z : {0, 1}∗ → {0, 1}`(λ), x 7→ 0`(λ) for all x ∈ {0, 1}∗.
This allows us to state our definitions simultaneously in the standard model and in the ROM: Parties will
be given access to a generic oracle O, and it is understood that O := Z if the definition is formulated in
the standard model, and O := H if it is in the ROM.

The quantum analogue of the above is the so-called quantum random oracle model (QROM), introduced
by Boneh et al. [BDF+11]. Here, a quantum algorithm may query the random oracle H in superposition,
i.e., submit superposition queries of the form

∑
x αx|x〉|0〉 and obtain the output

∑
x αx|x〉|H(x)〉. We refer

to [NC11] for further background and conventions regarding quantum information.

2.3 Languages and Relations

A language is a subset L ⊆ {0, 1}∗. In this work, we assume that every language L is equipped with a
uniform PPT algorithm GL (called instance generator) which, on input (1Ν; b) with b ∈ {0, 1}, returns an
element x ∈ L if b = 1 (yes-instance), and an element x /∈ L if b = 0 (no-instance). Usually, the complexity
of x is closely related to the security parameter Îť, e.g., |x| = Îť, but we can allow for other (polynomial)
dependencies as well.

8



A binary relation is a subset R ⊆ {0, 1}∗ × {0, 1}∗ which is polynomially bounded, i.e., there exists
a polynomial p such that, for every (x,w) ∈ R, we have |w| ≤ p(|x|). If (x,w) ∈ R, we call x an R-
instance and w an R-witness of x. For every x ∈ {0, 1}∗, we denote the set of all R-witnesses of x by
WR(x) := {w | (x,w) ∈ R} (if x is not an R-instance, then WR(x) = ∅). Note that every binary relation R
defines a language LR := {x | ∃w : (x,w) ∈ R}. Just like before for languages, we also assume that every
binary relation R is equipped with a uniform PPT algorithm GR (called instance generator) which, on
input (1Ν; b) with b ∈ {0, 1}, returns a pair (x,w) ∈ R if b = 1 (yes-instance), and an element x /∈ LR
if b = 0 (no-instance). Observe that from an instance generator GR for a binary relation R we get an
instance generator GLR for LR by simply running GR and returning the first component only if b = 1.

An NP-relation is a binary relation that is polynomial-time recognizable, i.e., R ∈ P. Observe
that if R is an NP-relation, then LR ∈ NP, and vice-versa if L ∈ NP, then the set RL of all string
pairs (x,w) ∈ {0, 1}∗ × {0, 1}∗ with x ∈ L and w an NP-witness for x (w.r.t. a fixed polynomial and
Turing machine) is an NP-relation. In this situation, we have of course LRL = L and RLR ⊇ R.

We next define the OR-combination of two relations and its instance generator. Here and in the
following, we present all definitions and constructions with respect to the OR of two relations only, but
all results extend to the more general 1-out-of-n case. A yes-instance of the OR-relation is a pair of
values (x0, x1), each in its respective language, together with a witness w of either value. A no-instance of
the OR-relation is again a pair of values, where at least one is not in the corresponding language, while the
other may or may not belong to its language. The convention that a yes-instance has both inputs in their
respective languages corresponds to the setting of group signature schemes, where all parties choose their
public keys honestly; only in security reductions one may diverge from this. It is also in general necessary
to ensure completeness of the OR-protocol, since the simulator for x1−b is only guaranteed to output a
valid transcript for yes-instances.
Definition 2.1. Let R0 and R1 be two binary relations. Define the OR-relation of R0 and R1 as the
binary relation

ROR :=
{(

(x0, x1), (b, w)
) ∣∣∣ b ∈ {0, 1} ∧ (xb, w) ∈ Rb ∧ x1−b ∈ LR1−b

}
,

equipped with the instance generator GROR defined in Figure 3. We denote the corresponding OR-language
by LOR := LROR.

Observe that, for binary relations R0 and R1, the relation ROR is indeed a binary relation, and
that LOR = LR0 × LR1 .

We now recall two hardness notions a binary relation R may satisfy. Intuitively, R is decisionally hard
if no PPT distinguisher can decide if it is given an R-instance or a no-instance. It is computationally hard
if no PPT adversary can efficiently compute an R-witness w for a given R-instance x.
Definition 2.2. Let R be a binary relation. We say that R is:

1. Decisionally Hard if, for every PPT distinguisher D, there exists a negligible function µ : N→ R such
that, for every λ ∈ N and every z ∈ {0, 1}∗,∣∣∣Pr

[
ExpDHR,0

D,R (Îť, z) = 1
]
− Pr

[
ExpDHR,1

D,R (Îť, z) = 1
]∣∣∣ ≤ µ(λ),

where ExpDHR,0
D,R (Îť, z) and ExpDHR,1

D,R (Îť, z) are defined in Figure 3.

2. Computationally Hard if, for every PPT algorithm A, there exists a negligible function µ : N→ R
such that, for every λ ∈ N and every z ∈ {0, 1}∗,

Pr
[

ExpCHR
A,R (Îť, z) = 1

]
≤ µ(λ),

where ExpCHR
A,R (Îť, z) is defined in Figure 3.

9



GROR(1Îť; b):

11: if b = 0 then
12: b′, b′′ ←$ {0, 1}
13: xb′ ←$ GLb′ (1

Îť; 0)
14: x1−b′ ←$ GLR1−b′

(1λ; b′′)
15: return (x0, x1)
16: else
17: b′ ←$ {0, 1}
18: (x0, w0)←$ GR0(1λ; 1)
19: (x1, w1)←$ GR1(1λ; 1)
20: return ((x0, x1), (b′, wb′))

ExpDHR,b
D,R (Îť, z):

31: x←$ GR(1λ; 0)
32: if b = 1 then
33: (x,w)←$ GR(1λ; 1)
34: b′ ←$ DO(1λ;x, z)
35: return b′

ExpCHR
A,R (Îť, z):

41: (x,w)←$ GR(1λ; 1)
42: w∗ ←$ AO(1λ;x, z)
43: return J(x,w∗) ∈ RK

Figure 3: Definition of the instance generator GROR of the relation ROR, and of the experiments ExpDHR,b
D,R (Îť, z)

and ExpCHR
A,R (Îť, z) from Definition 2.2. Recall that O is either a random oracle or the trivial all-zero oracle.

It is readily verified that two binary relations R0 and R1 are computationally hard if and only if ROR
is computationally hard. Furthermore, if an NP-relation R is decisionally hard, it is also computationally
hard.

2.4 Interactive Protocols

An interactive protocol Π between two parties, called prover and verifier, is a pair of uniform algo-";"""date"",""2020-02-29T11:06:46Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2020-02-29T11:06:46Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016) kpathsea version 6.2.2""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2020-02-29T11:06:46Z""
""created"",""2020-02-29T11:06:46Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-02-29T11:06:46Z""
""resourceName"",""271.pdf""
""Author"",""""
""producer"",""pdfTeX-1.40.17""
""pdf:docinfo:producer"",""pdfTeX-1.40.17""
""pdf:unmappedUnicodeCharsPerPage"",""1"",""0"",""0"",""1"",""0"",""0"",""0"",""14"",""19"",""26"",""56"",""46"",""29"",""6"",""11"",""3"",""7"",""4"",""4"",""2"",""2"",""5"",""6"",""1"",""2"",""0"",""16"",""6"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""2"",""5"",""5"",""64"",""74"",""30"",""88"",""9"",""34"",""69"",""6"",""4"",""40"",""32"",""4"",""4"",""14"",""2"",""8"",""8"",""1""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2020-02-29T11:06:46Z""
""Last-Modified"",""2020-02-29T11:06:46Z""
""dcterms:modified"",""2020-02-29T11:06:46Z""
""title"",""""
""Last-Save-Date"",""2020-02-29T11:06:46Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2020-02-29T11:06:46Z""
""meta:save-date"",""2020-02-29T11:06:46Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016) kpathsea version 6.2.2""
""Content-Length"",""806138""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""56""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""1562"",""1748"",""3237"",""2988"",""2736"",""3586"",""3401"",""3191"",""2899"",""2508"",""2352"",""2070"",""2308"",""2308"",""2186"",""2898"",""2562"",""2123"",""2923"",""3745"",""3224"",""3349"",""3249"",""2689"",""3421"",""3779"",""3100"",""2878"",""2992"",""2889"",""2958"",""2938"",""2834"",""2706"",""1599"",""2983"",""679"",""2180"",""1802"",""2700"",""2401"",""1712"",""2872"",""1285"",""2067"",""2355"",""1217"",""1781"",""1547"",""2010"",""2636"",""2968"",""2486"",""2498"",""3059"",""821""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-02-29T11:06:46Z""
";https://scholar.google.com/scholar?start=300&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095344-1462;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;[PDF][PDF] Blockchain in a Construction Project;SS Kuah ;2020 research.tue.nl;;"… 70 7.2.4 The Oracle Problem … The payments will be made using crypto coins and will be sent

automatically from the smart contract to the subcontractor's digital wallet. A diagram has been

drawn up that describes the Blockchain solution step by step …";Autres articles;Version HTML;[PDF] tue.nl;https://research.tue.nl/files/165193843/Kuah_1035347.pdf;"
 Eindhoven University of Technology

MASTER

Blockchain in a construction project
a design science research towards reducing conflicts between contractor and subcontractor
using a Blockchain solution

Kuah, S.

Award date:
2020

Link to publication

Disclaimer
This document contains a student thesis (bachelor's or master's), as authored by a student at Eindhoven University of Technology. Student
theses are made available in the TU/e repository upon obtaining the required degree. The grade received is not published on the document
as presented in the repository. The required complexity or quality of research of student theses may vary by program, and the required
minimum study period may vary in duration.

General rights
Copyright and moral rights for the publications made accessible in the public portal are retained by the authors and/or other copyright owners
and it is a condition of accessing publications that users recognise and abide by the legal requirements associated with these rights.

            • Users may download and print one copy of any publication from the public portal for the purpose of private study or research.
            • You may not further distribute the material or use it for any profit-making activity or commercial gain

https://research.tue.nl/en/studentthesis/blockchain-in-a-construction-project(0a03fb14-f01b-49ff-81fe-6484f523cb53).html


i 

August 2020 

Department of the Built Environment (BE), 
Master Construction Management and Engineering 

 

Blockchain in a 

Construction Project 
Master Thesis 

 

S. (Samir) Kuah 

 

 

 

 

 

 

 



ii 
 

Colophon 
 

Title   

Blockchain in a construction project 

 

Under title 

A design science research towards reducing conflicts between contractor and 

subcontractor using a Blockchain solution 

 

Author 

S. (Samir) Kuah 

Master Construction Management and Engineering - Eindhoven University of 

Technology 

Student no°: 1035347 

Email: Samir_kuah123@hotmail.com 

 

Graduation Committee 

Prof. dr. ir. B. (Bauke) de Vries  

ir. B.J.A. (Bob) van Thiel 

Dr. R.J.G. (Raymond) Opdenakker  

 

External advisor 

Alex de Vries (Blockchain expert at PricewaterhouseCoopers) 

 

Date of final presentation 

August 19, 2020 

mailto:Samir_kuah123@hotmail.com


iii 
 

 

 

 

 

 

 

 

(This page intentionally left blank) 
 

 

 

 

 

 

 

 



iv 
 

 

 

 
‘‘Continuous improvement is better than delayed perfection’’ 

 

- Mark Twain -  

 

 

 

 

 

 



v 
 

Preface 
 

In front of you lies the thesis ""Blockchain in a construction project"". A Design Science Research 

(DSR) towards reducing conflicts between contractor and subcontractor using a Blockchain 

solution. This thesis has been written to fulfill the graduation requirements of the Construction 

Management & Engineering program at the Eindhoven University of Technology (TU/e). From 

November 2019 to July 2020, I have been researching and writing the thesis. 

In the fall of 2017, a hype started around Blockchain technology and crypto currencies. At the 

time, I watched the developments surrounding both phenomena with full interest. After 

completing my last courses, I started looking for a challenging thesis topic. I came across two 

previous theses from students about the application of Blockchain technology in the real estate 

sector and in a housing association. Based on the potentials of Blockchain technology, the 

challenge arose to investigate the application of Blockchain in a construction project. 

Several people took part in my research with enthusiasm and great interest. Without them, 

answering my main research question would have been almost an impossible task. In particular, 

I would like to thank my supervisors Bob van Thiel and Raymond Opdenakker for their guidance 

and support during this challenging process. I would also like to thank Alex de Vries of 

PricewaterhouseCoopers for answering all my questions when I got stuck. Further, I would like 

to thank all respondents and other people who contributed to this thesis for their cooperation 

and their time. 

I also want to thank my family and friends for their wise advice during the research. I have been 

able to discuss my research with a number of fellow students and I would also like to thank them 

for their input and advice. Finally, I would especially like to thank my parents who have 

motivated me throughout the process to successfully complete my thesis. 

I hope you enjoy your reading. 

Samir Kuah 

Almere, August 15, 2020 

 

 

 

 

 

 

 



vi 
 

Table of contents 

Colophon .............................................................................................................................................. ii 

Preface .................................................................................................................................................. v 

Management Summary ................................................................................................................... x 

Management Summary (Dutch) ............................................................................................... xii 

Abstract ............................................................................................................................................ xiv 

Abbreviations................................................................................................................................... xv 

List of Figures ................................................................................................................................. xvi 

List of Tables .................................................................................................................................. xvi 

 

I. Introduction ........................................................................................................................... 1 

1.1 Background .............................................................................................................................. 2 

1.2 Problem Definition ................................................................................................................... 5 

1.3 Research Question ................................................................................................................... 6 

1.4 Scientific Relevance ................................................................................................................. 7 

1.5 Practical Relevance .................................................................................................................. 7 

1.6 Reading Guide ......................................................................................................................... 8 

 

II. Subcontracting in Construction Industry ..................................................................... 9 

2.1 Background of subcontracting in construction industry ........................................................ 10 

2.2 Difference between contractor and subcontractor ............................................................... 11 

2.2.1 (Main) Contractor .......................................................................................................... 11 

2.2.2 Subcontractor ................................................................................................................ 11 

2.2.3 Selecting a Subcontractor .............................................................................................. 11 

2.3 Types of subcontractors......................................................................................................... 12 

2.3.1 Domestic subcontractors............................................................................................... 12 

2.3.2 Nominated subcontractors............................................................................................ 12 

2.3.3 Named subcontractors .................................................................................................. 12 

2.4 Subcontract between contractor and domestic subcontractor ............................................ 13 

2.5 Risks of Subcontracting ......................................................................................................... 14 

2.6 Contractual problems ............................................................................................................ 15 

2.6.1 Payment problems in the construction industry ........................................................... 15 



vii 
 

III. Research Methodology .................................................................................................... 17 

3.1 Design Science Methodology ................................................................................................. 18 

3.1.1 Design Science Research Strategy ................................................................................. 20 

3.2 Data Gathering ...................................................................................................................... 21 

3.2.1 Selecting a Data Collection method .............................................................................. 21 

3.2.2 In-depth Interviews ....................................................................................................... 22 

3.2.3 Coding ............................................................................................................................ 23 

3.3 Applying the findings ............................................................................................................. 24 

3.4 Reliability of the research ...................................................................................................... 25 

 

IV. Identifying bottleneck ...................................................................................................... 26 

4.1 Bottleneck .............................................................................................................................. 27 

4.2 Payment problems ................................................................................................................. 28 

4.2.1 Payment problems in the Dutch Construction Industry ................................................ 29 

4.3 Factors Causing Payment Problems ...................................................................................... 32 

4.4 Impacts of slow payments ..................................................................................................... 33 

4.5 The Benefits of Faster Payments ........................................................................................... 35 

4.6 Pay-When-Paid and Pay-if-paid clauses ................................................................................ 36 

4.7 Requirements ......................................................................................................................... 37 

 

V. Blockchain Technology .................................................................................................... 38 

5.1 What is Blockchain? .............................................................................................................. 39 

5.1.1 Benefits of a Blockchain for a Business ......................................................................... 40 

5.1.2 Blockchain Technology and Trust .................................................................................. 41 

5.2 How does a Blockchain work? ............................................................................................... 42 

5.2.1 Why is it called Blockchain? .......................................................................................... 42 

5.2.2 Key concepts of Blockchain ........................................................................................... 43 

5.3 Blockchain in Construction Industry ...................................................................................... 46 

5.4 Design Propositions ............................................................................................................... 46 

5.5 Project Bank Accounts ........................................................................................................... 47 

5.6 Traditional Database ............................................................................................................. 47 

5.6.1 Advantages of Traditional Database ............................................................................. 48 

5.6.2 Traditional Database vs. Blockchain .............................................................................. 49 



viii 
 

VI. Blockchain Solution .......................................................................................................... 50 

6.1 Current payment procedure .................................................................................................. 51 

6.1.1 Formation and Content of the subcontract .................................................................. 51 

6.1.2 Bank guarantees and Credit Insurance ......................................................................... 51 

6.1.3 Inspection and Approval ................................................................................................ 52 

6.1.4 Invoicing and payment .................................................................................................. 53 

6.1.5 Diagram Current payment procedure in a construction project................................... 54 

6.2 Payment through Blockchain................................................................................................. 56 

6.2.1 Lifecycle of a Smart Contract ......................................................................................... 56 

6.2.2 Proof-of-Existence (PoE) ................................................................................................ 58 

6.2.3 Creating a Smart Contract ............................................................................................. 59 

6.2.4 Transaction to a Smart Contract ................................................................................... 60 

6.2.5 Digital Signature ............................................................................................................ 60 

6.2.6 Oracle ............................................................................................................................ 61 

6.2.7 Privacy ........................................................................................................................... 62 

6.2.8 Diagram of a payment procedure through Blockchain in a construction project ......... 63 

 

VII. Validation ............................................................................................................................. 65 

7.1 Benefits of the Blockchain Solution ....................................................................................... 66 

7.1.1 Trust and Transparency ................................................................................................. 66 

7.1.2 Pre-financing.................................................................................................................. 67 

7.1.3 Tricks to delay payment ................................................................................................ 67 

7.1.4 Advantages from a contractor’s perspective ................................................................ 68 

7.2 Limitations of the Blockchain solution ................................................................................... 69 

7.2.1 Blockchain platform....................................................................................................... 69 

7.2.2 Legal status of a smart contract .................................................................................... 69 

7.2.3 Implementation effort ................................................................................................... 70 

7.2.4 The Oracle Problem ....................................................................................................... 70 

7.2.5 Crypto currency ............................................................................................................. 70 

7.3 Validation of the Blockchain Solution .................................................................................... 71 

 

 

 



ix 
 

VIII. Conclusion and Discussion ............................................................................................. 74 

8.1 Conclusion .............................................................................................................................. 75 

8.2 Limitation of the research ..................................................................................................... 80 

8.3 Recommendation for further research .................................................................................. 81 

8.4 Discussion .............................................................................................................................. 83 

Bibliography .................................................................................................................................... 84 

 

Appendix A: Transcript interview Chairman AFNL ........................................................... 92 

Appendix B: Transcript interview Subcontractor A .......................................................... 94 

Appendix C: Transcript interview Subcontractor B .......................................................... 99 

Appendix D: Validation 1 Blockchain Solution ................................................................. 102 

Appendix E: Validation 2 Blockchain Solution .................................................................. 104 

Appendix F: Validation 3 Blockchain Solution .................................................................. 106 

Appendix G: General purchasing and subcontracting conditions .............................. 109 

 

 

 

 

 

 

 

 

 

 

 

 

 

 



x 
 

Management Summary 
 

The construction industry is a significant contributor to the Dutch economy. In 2018 the 

construction industry employed over three hundred thousand people, contributed about 4, 5 per 

cent of Gross Domestic Product (GDP) and included a production of more than €70 billion Euro 

(CBS, 2019). However, the industry continues to be labeled as a serial productivity 

underperformer (PWC, 2013). Different studies address different factors that cause low 

productivity in the construction industry. However, these studies almost exclusively represent 

the perspective of governments, clients and main contractors, whereas the voice of 

subcontractors has been entirely missing from the construction productivity debate 

(Loosemore, 2014a). A major omission as the subcontractors performs almost all physical work 

on the construction site. 

The main research question in this study is; To what extent can the potential of Blockchain 

technology be applied to reduce the conflicts between contractor and subcontractor during 

construction projects? The research method used for this study is the Design Science 

Methodology (DSM). DSM is a relatively new approach to research (Reubens, 2016), with a goal 

to construct a new reality (i.e. solve problems) instead of explaining an existing reality, or 

helping to make sense of it (Iivari and Venable, 2009). Research, of course, aims to develop 

knowledge, but Design Science Research (DSR) is not driven by pure knowledge problems, but 

by field problems. A field problem can be defined as a situation in reality, which according to 

(some or all) stakeholders can or should be improved. Its key research product is a generic 

solution concept, i.e. a generic intervention or system that can be used in addressing the type of 

field problem in question (Van Aken, 2012). 

During construction projects, there are often various conflicts between contractor and 

subcontractor. The causes of these conflicts are diverse and in the worst cases leading to 

disputes. In case of disputes, the work is usually (temporarily) stopped. A temporary stop of 

work can again directly affect the delivery date, which can have an effect on the end users. Due 

to the high diversity of causes of conflict, this research focused on identifying one single 

bottleneck that causes conflicts. On the basis of an in-depth literature study, previous research 

reports and interviews with various stakeholders it was confirmed that payment problems are 

an important bottleneck that causes the many conflicts between contractor and subcontractors 

during construction projects. After that, requirements have been drawn up that a possible 

solution must meet to solve the payment problems and to reduce the conflicts between 

contractor and subcontractor.  

The most important requirement for the solution is that payment agreements must be 

irrefutably recorded and must be able to be executed automatically so that late payments, or in 

the worst case no payment at all, can no longer occur. In addition to establishing the agreements 

irrefutably, it must no longer be possible to adjust the agreements after both the contractor and 

the subcontractor have signed the contract. This will create trust and transparency between 

contractor and subcontractors. Moreover, the automatic execution of payment arrangements, 

after the work has been performed and approved by a contractor’s representative, will minimize 

the likelihood of default and ensures that subcontractors can receive their money on time. Over 



xi 
 

time, this will ensure that loans, bank guarantees and credit insurance become superfluous, so 

that in addition to reducing conflicts, higher returns can also be achieved. 

During this research, Blockchain technology was raised at an early stage as a possible solution to 

reduce the conflicts between contractor and subcontractor. After identifying payment problems 

as a bottleneck that causes conflicts between contractor and subcontractor, as the DSM 

guidelines indicate, another solution was also considered to solve the identified field problem. In 

addition to Blockchain technology, another possible solution that could meet the requirements 

was the use of a traditional database. Payment agreements can be recorded and automated both 

in a traditional database and on a Blockchain. Both solutions were investigated and compared 

with each other during this study. However, a traditional database will always be managed by a 

database administrator (DBA). Because of the DBA, the use of a traditional database means that 

the chance of fraud is always present. A DBA has the competence to adjust contractual 

agreements on a traditional database whereas agreements recorded on a Blockchain can no 

longer be modified by anybody after agreement.  As a result, a traditional database will never be 

able to provide the same trust that Blockchain technology could offer. Based on this, it was 

decided to apply Blockchain technology to work out a solution. 

A smart contract has formed the basis of the elaborated Blockchain solution. A smart contract is 

an automated transaction protocol that implements the terms of the contract. Contractual 

clauses in smart contracts are automatically enforced when a certain condition is met. 

Blockchain is not the same as a smart contract but makes smart contracts possible. In the new 

situation in which payments will be made via Blockchain, first of all, as in the current situation, a 

subcontracting agreement will be drawn up and signed by both contractor and subcontractor. 

This original subcontracting agreement will then be uploaded to a Blockchain using a Proof of 

Existence web application. With the help of this web application a digital ‘fingerprint’ will be 

generated automatically. Hereafter, the smart contract will be drawn up. In the smart contract, 

the reference to the original subcontracting agreement will be made based on the generated 

'fingerprint' and the contract conditions as drawn up in the original subcontracting agreement 

will be translated into smart contract code. Payments than will be linked to those conditions. 

After the work has been completed and approved by the contractor's representative, the smart 

contract will automatically make the payment. The payments will be made using crypto coins 

and will be sent automatically from the smart contract to the subcontractor's digital wallet. 

A diagram has been drawn up that describes the Blockchain solution step by step. Using this 

diagram, the Blockchain solution has been validated by an experienced subcontractor, the 

chairman of the Dutch Contractor’s Federation (in Dutch: AFNL) and by a Blockchain specialist. 

Based on the answered sub-questions and the validation, it could be confirmed that there is a 

great deal of potential to solve the payment problems in such a way that the number of conflicts 

between contractor and subcontractors decreases when using Blockchain technology. On the 

other hand, there are still enough challenges to actually implement the Blockchain solution. Such 

as convincing a contractor and adjusting a number of technical pitfalls of the Blockchain 

solution. By further developing the solution, it may in the future be a breakthrough for the many 

conflicts between contractor and subcontractors during construction projects. 



xii 
 

Management Summary (Dutch) 
 

De bouwsector levert een belangrijke bijdrage aan de Nederlandse economie. In 2018 had de 

bouwsector meer dan driehonderdduizend mensen in dienst, droeg de industrie voor ongeveer 

4,5 procent bij aan het bruto binnenlands product en omvatte de bouwindustrie een productie 

van meer dan € 70 miljard euro (CBS, 2019). Echter, de bouwindustrie wordt nog steeds 

bestempeld als de industrie met een lage productiviteit (PWC, 2013). Verschillende studies 

kaarten verschillende factoren aan die de lage productiviteit in de bouwindustrie veroorzaken.   

Deze studies vertegenwoordigen echter bijna uitsluitend het perspectief van overheden, 

opdrachtgevers en hoofdaannemers, terwijl de stem van onderaannemers volledig ontbreekt in 

het debat over bouwproductiviteit (Loosemore, 2014a). Een grote nalatigheid aangezien de 

onderaannemers hedendaags bijna alle fysieke werkzaamheden op de bouwplaats uitvoeren.  

De hoofdonderzoeksvraag in deze studie is in hoeverre kunnen de potenties van Blockchain 

technologie toegepast worden om de conflicten tussen aannemer en onderaannemer tijdens 

bouwprojecten te reduceren. De onderzoeksmethode toegepast voor dit onderzoek is de Design 

Science Methodology (DSM). DSM is een relatief nieuwe benadering van onderzoek (Reubens, 

2016) met als doel een nieuwe realiteit te construeren (d.w.z. problemen op te lossen) in plaats 

van een bestaande realiteit uit te leggen of te helpen een betekenis te geven (Iivari en Venable, 

2009). Met onderzoek wil men natuurlijk kennis ontwikkelen, maar DSM wordt niet gedreven 

door pure kennisproblemen, maar door veldproblemen. Een veldprobleem kan worden 

gedefinieerd als een realiteitsituatie die volgens (sommige of alle) belanghebbenden kan, of 

moet worden verbeterd. Het belangrijkste onderzoeksproduct is een generiek 

oplossingsconcept, d.w.z. een generieke interventie of systeem dat kan worden gebruikt om het 

type veldprobleem in kwestie aan te pakken (van Aken, 2012). 

Tijdens bouwprojecten vinden er vaak verschillende conflicten plaats tussen aannemer en 

onderaannemer. De oorzaken van deze conflicten zijn divers en lijden in het ergste geval tot 

geschillen. Bij geschillen wordt het werk doorgaans (tijdelijk) stilgelegd. Een tijdelijke stop van 

werkzaamheden kan weer direct invloed hebben op de opleverdatum, wat directe gevolgen kan 

voor de eindgebruikers. Door de hoge diversiteit van oorzaken van conflicten, focuste dit 

onderzoek zich op het identificeren van een knelpunt dat voor conflicten zorgt. Op basis van een 

verdiepend literatuuronderzoek, eerdere onderzoeksrapporten en interviews met verschillende 

belanghebbenden, kon bevestigd worden dat betalingsproblemen een belangrijk knelpunt 

vormen. Op basis hiervan zijn er eisen opgesteld waaraan een mogelijke oplossing zal moeten 

voldoen om de betalingsproblemen op te kunnen lossen.  

De belangrijkste eis voor de oplossing is dat de betalingsafspraken onomstotelijk vastgelegd en 

automatisch uitgevoerd moeten kunnen worden zodat te late betalingen, of in het slechtste geval 

helemaal geen betaling, niet meer voor kan komen. Naast het onomstotelijk vastleggen van de 

afspraken moet het na ondertekening van het contract door zowel aannemer als onderaannemer 

niet meer mogelijk zijn de afspraken aan te kunnen passen. Hiermee zal er vertrouwen en 

transparantie gecreĂŤerd kunnen worden tussen aannemer en onderaannemers. Daarbij zorgt de 

automatische uitvoering van betalingen, nadat de werkzaamheden zijn uitgevoerd en 

goedgekeurd door een vertegenwoordiger van de aannemer, ervoor dat de kans op wanbetaling 

nihil wordt. Met de tijd zal dat ervoor kunnen zorgen dat leningen, bankgaranties en 



xiii 
 

kredietverzekeringen overbodig worden waardoor er naast het reduceren van conflicten, ook 

hogere rendementen behaald kunnen worden. 

Blockchain technologie wordt tijdens dit onderzoek al in een vroeg stadium aangekaart als een 

mogelijke oplossing om de conflicten tussen aannemer en onderaannemer te reduceren. Na het 

identificeren van het knelpunt, betalingsproblemen, is er zoals een DSM richtlijn aangeeft ook 

een andere oplossing onderzocht dat het veldprobleem op zou kunnen lossen. Naast Blockchain 

technologie was een andere mogelijke oplossing de toepassing van een traditionele database. 

Zowel op een traditionele database als op een Blockchain kunnen betalingsafspraken vastgelegd 

en geautomatiseerd worden. Beide oplossingen zijn tijdens deze studie dan ook onderzocht en 

met elkaar vergeleken. Een traditionele database zal echter altijd gepaard gaan met een 

database beheerder. Door een database beheerder is bij het gebruik van een traditionele 

database de kans op fraude altijd aanwezig doordat een database beheerder de middelen heeft 

contractuele afspraken aan te passen terwijl afspraken vastgelegd op een Blockchain niet meer 

aangepast kunnen worden. Hierdoor zal een traditionele database nooit het vertrouwen kunnen 

bieden aan de onderaannemers die Blockchain technologie wel zou kunnen bieden. Op basis 

hiervan is besloten Blockchain technologie toe te passen om een oplossing uit te werken.  

Een slimme overeenkomst (smart contract), heeft de basis gevormd van de uitgewerkte 

Blockchain oplossing. Een smart contract is een geautomatiseerd transactieprotocol dat de 

voorwaarden van het contract implementeert. Contractuele clausules in smart contracts worden 

automatisch uitgevoerd wanneer aan een bepaalde voorwaarde is voldaan. Blockchain is niet 

hetzelfde als een smart contract, smart contracts worden uitgevoerd op een Blockchain. In de 

nieuwe situatie waarbij betalingen via Blockchain zullen verlopen, zal er allereerst net als in de 

huidige situatie een onderaannemingsovereenkomst opgesteld en ondertekend worden door 

zowel aannemer als onderaannemer. Deze originele onderaannemingsovereenkomst zal hierna 

geĂźpload worden op een Blockchain via de Proof of Existance webapplicatie. Met behulp van de 

webapplicatie zal er een digitale ‘fingerprint’ gegeneerd worden. Hierna kan het smart contract 

opgesteld worden. In het smart contract zal allereerst verwezen worden naar de originele 

onderaannemingsovereenkomst aan de hand van de digitale ‘fingerprint’ en zullen de 

contractvoorwaarden die daar in staan vertaald worden naar smart contract code. Aan die 

voorwaarden zullen dan betalingen gekoppeld worden zodat na het afronden van de 

werkzaamheden en goedkeuring van de vertegenwoordiger van de aannemer, er automatisch 

door het smart contract overgegaan kan worden tot betaling. De betaling zal plaatsvinden met 

cryptomunten en zal automatisch van het smart contract naar de digitale portemonnee van de 

onderaannemer toegestuurd worden.  

Van de Blockchain oplossing is een diagram opgesteld. Met behulp van dit diagram is de 

Blockchain oplossing gevalideerd door een ervaren onderaannemer, de voorzitter van 

Aann";"""date"",""2020-08-21T09:35:46Z""
""pdf:PDFVersion"",""1.4""
""xmp:CreatorTool"",""Adobe InDesign CC 2015 (Macintosh)""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""language"",""en""
""dc:format"",""application/pdf; version=1.4""
""pdf:docinfo:creator_tool"",""Adobe InDesign CC 2015 (Macintosh)""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""xmp:CreateDate"",""2020-08-21T11:35:46Z""
""modified"",""2020-08-21T09:35:46Z""
""pdf:hasMarkedContent"",""true""
""xmp:ModifyDate"",""2020-08-21T11:35:46Z""
""trapped"",""False""
""meta:creation-date"",""2020-08-21T09:35:46Z""
""created"",""2020-08-21T09:35:46Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-08-21T09:35:46Z""
""resourceName"",""Kuah_1035347.pdf""
""xmpMM:DerivedFrom:DocumentID"",""xmp.did:cbbc3ce9-75bb-43e3-9371-324287e7c58f""
""producer"",""3-Heights(TM) PDF Security Shell 4.8.25.2 (http://www.pdf-tools.com)""
""pdf:docinfo:producer"",""3-Heights(TM) PDF Security Shell 4.8.25.2 (http://www.pdf-tools.com)""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""access_permission:modify_annotations"",""true""
""PDFVersion"",""1.4""
""dcterms:created"",""2020-08-21T09:35:46Z""
""Last-Modified"",""2020-08-21T09:35:46Z""
""dcterms:modified"",""2020-08-21T09:35:46Z""
""xmpMM:DocumentID"",""xmp.id:81698ccf-6ff3-42d7-bb5e-5240e1c65b35""
""Last-Save-Date"",""2020-08-21T09:35:46Z""
""pdf:docinfo:modified"",""2020-08-21T09:35:46Z""
""meta:save-date"",""2020-08-21T09:35:46Z""
""pdf:docinfo:custom:PDFVersion"",""1.4""
""Content-Type"",""application/pdf""
""xmp:MetadataDate"",""2020-08-21T11:35:46Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""dc:language"",""nl-NL""
""pdf:producer"",""3-Heights(TM) PDF Security Shell 4.8.25.2 (http://www.pdf-tools.com)""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""132""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""1240"",""179"",""591"",""57"",""91"",""2014"",""3964"",""4086"",""3742"",""1624"",""3519"",""3780"",""3669"",""3884"",""2338"",""666"",""1682"",""29"",""2130"",""2651"",""1842"",""3902"",""2183"",""3219"",""1192"",""65"",""3793"",""3252"",""3080"",""3070"",""3132"",""3580"",""1298"",""47"",""3849"",""4028"",""2426"",""3017"",""3508"",""3157"",""2537"",""1472"",""48"",""3794"",""3518"",""3447"",""1732"",""1716"",""3354"",""3570"",""3035"",""3628"",""3517"",""2670"",""44"",""3778"",""2767"",""3210"",""2048"",""3349"",""2093"",""3608"",""3226"",""3307"",""3987"",""3221"",""45"",""3582"",""3882"",""1373"",""1067"",""83"",""3552"",""2022"",""2754"",""3010"",""3452"",""3552"",""3109"",""1262"",""65"",""43"",""2755"",""3191"",""3449"",""3495"",""3546"",""2872"",""3504"",""3051"",""51"",""3309"",""3579"",""3965"",""3974"",""4130"",""3822"",""3628"",""3811"",""3625"",""2641"",""3110"",""3119"",""3030"",""2993"",""3016"",""2945"",""1102"",""2385"",""843"",""2293"",""2893"",""2489"",""3227"",""1544"",""2406"",""2823"",""2688"",""3104"",""3144"",""3240"",""499"",""3484"",""3950"",""2554"",""68"",""28730"",""22175"",""23001"",""22130"",""21121"",""16520""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""xmpMM:DerivedFrom:InstanceID"",""xmp.iid:e708f1ec-34e9-4140-9e2c-275a217ea1b0""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-08-21T09:35:46Z""
";https://scholar.google.com/scholar?start=260&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095306-1296;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Self-organization of Network Communities via Blockchain Technology: Reputation Systems and Limits of Digital Democracy;DR Mukhametov ; 2020 Systems of Signal Synchronization …, 2020  ieeexplore.ieee.org;;"… up the incentives for interaction between users of the reputation system and oracles: one option

is to embed oracles in the blockchain and then … of the current rating on request of smart contracts

or users for a certain payment (similar digital services using oracle algorithms are …";Autres articles;;[PDF] academia.edu;https://www.academia.edu/download/64259425/Self-organization%20of%20networks%20communities%20via%20blockchain%20technology.pdf;;;https://scholar.google.com/scholar?start=100&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095365-1552;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Book Review: Blockchain and the Law: The Rule of Code;C Twigg;Flesner 2020 journals.sagepub.com;;"… Book Review: Blockchain and the Law: The Rule of Code. Christian Twigg-Flesner. Social &

Legal Studies 0 10.1177/0964663920906443 … Book Review: Blockchain and the Law: The Rule

of Code. Christian Twigg-Flesner. Social & Legal Studies 0 10.1177/0964663920906443 …";Autres articles;;null;;;;https://scholar.google.com/scholar?start=350&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095390-1654;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;[HTML][HTML] A Novel Blockchain Identity Authentication Scheme Implemented in Fog Computing;H Wang, Y Jiang ; Wireless Communications and Mobile Computing, 2020  hindawi.com;;"Journals; Publish with us; Publishing partnerships; About us; Blog. Wireless

Communications and Mobile Computing. +Journal Menu. PDF. Journal overview.

For authorsFor reviewersFor editorsTable of Contents Special Issues.";Cité 1 fois;Les 4 versions;[HTML] hindawi.com;https://www.hindawi.com/journals/wcmc/2020/8849363/;"[image: logo]
	Journals
	Publish with us
	Publishing partnerships
	About us
	Blog




Wireless Communications and Mobile Computing
+Journal Menu
[image:  ]PDF[image:  ] 
    
     Icons/Arrow Right White
     Created with Sketch.
     
         
    
     
         
             
                 
                     
                         
                             
                                 
                            
                             
                             
                                 
                            
                        
                    
                
            
        
    



Journal overview
For authorsFor reviewersFor editorsTable of ContentsSpecial Issues
[image:  ]         

Submit






Wireless Communications and Mobile Computing / 2020 / Article
Article SectionsOn this page
AbstractIntroductionConclusionData AvailabilityConflicts of InterestReferencesCopyright


Special IssueRecent Advances in Cloud-Aware Mobile Fog Computing 2020
View this Special Issue

Research Article | Open Access
Volume 2020 |Article ID 8849363 | https://doi.org/10.1155/2020/8849363
Huijuan Wang, Yong Jiang, ""A Novel Blockchain Identity Authentication Scheme Implemented in Fog Computing"", Wireless Communications and Mobile Computing, vol. 2020, Article ID 8849363, 7   pages, 2020. https://doi.org/10.1155/2020/8849363

Show citation
A Novel Blockchain Identity Authentication Scheme Implemented in Fog Computing


Huijuan Wang[image:  ]   .cls-1{fill:#a6ce39;}.cls-2{fill:#fff;}.cls-3{fill:none;} orchid     

1 and Yong Jiang11Information Security Department of the First Research Institute of the Ministry of Public Security of P.R.C., Beijing 100084, China

Show more
Academic Editor: Fuhong Lin
Received18 Apr 2020
Revised16 Jun 2020
Accepted09 Jul 2020
Published01 Aug 2020


Abstract
In a fog computing environment, lots of devices need to be authenticated in order to keep the platform being secured. To solve this problem, we turn to blockchain techniques. Unlike the identification cryptographic scheme based on elliptic curves, the proposed 2-adic ring identity authentication scheme inherits the high verification efficiency and high key distribution of sequence ciphers of 2-adic ring theory, and this algorithm adds identity hiding function and trading node supervision function by design. The main designed application scenario of this solution is applicable to the consortium blockchain, and the master nodes are mutually trusting cooperative relations. The node transaction verification and block generation consensus algorithm designed in this solution can be implemented in a set of algorithms, which has higher verification efficiency and easier to be deployed than other solutions. This scheme can be widely used in the fog computing environment.
1. Introduction
Security is very important in each network. The fog computing, which extends the function of cloud computing, has attracted lots of attention [1]. The main idea is pushing the centralized function to decentralized function. There are many varieties, such as edge computing and cloudlet [2–4]. The decentralized network means that there needs to be an identity authentication scheme to keep the environments being secured. The blockchain has built a new trusted large-scale assistance method based on the information Internet to solve the trust problem of the development of the digital economy. As a new technology, blockchain technology has the characteristics required by various application scenarios such as transparency and credibility, tamper resistance, traceability, and decentralization. Applications have been extended from the financial field to supply chain management, government services, energy copyright storage, Internet of Things [5], fog computing, and other fields. In a narrow sense, a blockchain is a type of chained data that combines data blocks in a chronological order in a sequential manner and uses cryptography to ensure a tamper-proof and unforgeable distributed ledger. Broadly speaking, blockchain technology uses blockchain data structure blocks to verify and store data, uses distributed node consensus algorithms to generate and update data, and uses cryptography to ensure the security of data transmission and access. A smart contract composed of script code turns into and operates a new distributed infrastructure and computing paradigm for data. Unlike the traditional centralized structure, the blockchain mechanism does not rely on a specific central node to process and store data, so information leakage caused by malicious centers or other reasons can be avoided. In the actual application scenarios of blockchain, hash functions and digital signature algorithms are widely used in blockchain to verify the correctness of blocks and transactions. The traditional PKI mechanism does not conform to the “decentralized” characteristics of the blockchain because the weight of the trusted center is too large, so certificateless encryption and signature schemes are mostly used in blockchain technology.
There are actually two functions in the blockchain that need to be appropriately adapted to the practical application. One is how to increase the supervision function in the decentralized architecture, and the other is how to ensure the privacy of user information under supervision. In 2012, Yu et al. [6] proposed a certificateless signature scheme that can be proved safe under the standard model. However, this scheme requires more than 5 bilinear pairing operations, and the calculation efficiency is low. In the same year, Gong and Li [7] proposed a certificateless password mechanism based on elliptic curves, but the resistance to participating node attacks was weak. In 2013, Miers and others [8] proposed an anonymous blockchain digital currency scheme based on Bitcoin. This scheme uses zero-knowledge proof cryptography technology to ensure the transaction by hiding the user address and cutting off the contact between the two parties. The nonrelevance of the system can achieve the untraceable effect, but the scheme needs to maintain the currency revocation list at the node to ensure the uniqueness of the transaction, which affects the efficiency of the transaction to a certain extent. In 2016, Shen and Adam proposed ring-based signatures. In 2016, Shen and Adam [9] proposed a ring-based signature secret transaction scheme. This scheme randomly selects irrelevant addresses and performs ring signatures together with the transaction initiator to achieve the purpose of confusing the identity of the transaction user. However, both the scheme and the zero-coin scheme have the problem of poor traceability due to the cutoff of the transaction association, which is difficult to be applied in actual scenarios, and the amount of single transaction information is too large. The anonymity of the scheme depends on the number of addresses participating in the ring signature. To reduce the amount of transaction information and reduce the number of addresses, you will also face the risk of deanonymization. The combination of blockchain and identification password can solve part of the problem of blockchain decentralization supervision. SM9 is an identification password, and there are a large number of blockchain identification password systems designed based on SM9 at home and abroad. Taking the consortium blockchain in the blockchain as the application environment, performing exponential operation and bilinear pairing operation can be the consortium blockchain. The application provides effective security and privacy protection support.
In this paper, we introduce an identification cryptographic scheme suitable for consortium blockchain based on the 2-adic ring algorithm. The 2-adic ring [10] is a finite ring that can correspond to any bit string in a finite field. When designing with this theoretical basis, it can inherit the recognition and verification efficiency of binary sequence ciphers in computer communication and can solve a large number of node verification of key distribution issues. Part of the security of passwords is based on the 2-adic ring theory. For an attacker, you need to be familiar with the 2-adic ring theory to recognize the algorithm and increase the difficulty of supply.
This article is mainly composed of the following parts. The second part introduces the basic preliminaries; this part introduces the blockchain and consortium blockchain and the identification password and introduces the basic knowledge of the 2-adic ring to facilitate the reader to understand the subsequent security proof; the third part describes the design of the main cryptographic scheme in this article, the blockchain identification authentication scheme based on the 2-adic ring algorithm, and introduces the node composition and transaction implementation process of the scheme in the consortium blockchain; the fourth part proves and analyzes the security of the scheme attack resistance and finally summarizes the applicable scenarios of the program and suggestions for improvement.
2. Preliminary Knowledge
2.1. Blockchain and Consortium Blockchain
Blockchain technology is built on the Internet. Using P2P, distributed storage, and distributed key ideas, a chronological sequence of data blocks is combined into a specific data structure in a chain. The chain structure of the blockchain uses cryptographic signatures to ensure that the chain connection of the data cannot be tampered with or forged. It can store a full amount of light time-series fingerprint data. The blockchain can be used as a data record database. The database is shared by network nodes. When nodes update data, they submit data records. Through the consensus mechanism, the data consistency between nodes is ensured. After the consistency is determined, the records like blockchain will never be changed or deleted.
The blockchain will also have different architectures due to different deployment environment models, such as public chain/consortium chain/private chain and side chain/crosschain. The encryption scheme in this article is mainly implemented in the consortium chain. In the consortium chain, the validity of the blockchain and the validity of the transaction are determined by a predetermined group of validators. This verification group forms a consortium chain. The consortium chain has the verification nodes and data changes initiated by the group of validators. The shared participating nodes are composed together.
2.2. Identification Password Algorithm
The identification cryptosystem means that the signer holds an identification and a corresponding private key. The private key is generated by the Key Generation Center (KGC) through the combination of the private key and the signer’s identification. The signer uses his own private key to generate a digital signature on the data, and the verifier uses the signer’s logo to generate his public key to verify the validity/authenticity/integrity and legal identity of the signature. SM9 logo ciphers generally involve the calculation of bilinear pairs on finite fields/elliptic curves/elliptic curves. The 2-adic ring algorithm logo ciphers designed in this paper involve knowledge of finite field 2-adic rings.
Identification password verification steps are as follows:
(i)Create a polynomial identification cryptographic algorithm to produce public and private keys(ii)Set up a management node and establish an interactive protocol with the user. Executing this protocol can generate the private key and member certificate of the management node and use the private key of the group member of the group administrator(iii)Using an identification password signature algorithm, after entering a message and a member private key, the signature of the message is output(iv)Verify the original message/message signature/public key(v)Confirm the legality of the signature
2.3. 2-Adic Integer and Arithmetic Crosscorrelation
Let binary strictly periodic sequence  have the least period , . A 2-adic integer is a formal power series , with . The set  of the 2-adic integers forms a ring under the operations of addition and multiplication with carry [11], the string  as merely, and the string  as 1, and define , the infinite string  is a base 2 expansion of a negative integer -1.
Specifically, the addition of  integers is given by

, are carry integers, such that , and for all .
Similarly, there are multiplications of  integers [11].
Let  be an odd integer, then the negative integer  is associated to the product

In , the formal power series  has a unique (multiplicative) inverse

Thus, the ring  contains every rational number  provided  is odd.
Proposition 1 (see [11]). There is a one-to-one correspondence between rational numbers  (where  is an odd number) and eventually periodic binary sequences , which associates to each rational number  and the bit sequence  of its 2-adic expansion. The sequence  is strictly periodic if and only if  and .
In this correspondence, we use the operations in  to introduce the arithmetic crosscorrelation.
Definition 2 (see [11]). Let  and  be two strictly binary periodic sequences with period , and let  and  be the  shift of . Denote  and  as the 2-adic integers corresponding to the sequences  and . Then, the corresponding sequence  of  is strictly periodic or eventually periodic, and its period divides . The shift arithmetic crosscorrelation  of  and  is the number of zeros minus the number of ones in one period of length  of .
3. Identity Authentication Scheme Based on 2-Adic Ring AC Algorithm
This paper proposes an information authentication scheme suitable for consortium blockchain technology. By broadcasting transaction information encrypted by user identity information in transaction information, multi-KGC signature calculation is performed to hide user identity and transaction continuity.
3.1. Node Composition
The nodes in this scheme are divided into a primary node and a secondary node. The primary node is responsible for initializing the parameters of the AC algorithm and KGC signature used in the blockchain, executing the consensus algorithm for generating new blocks in the blockchain, participating in the continuous generation of blocks, and managing the joining of secondary nodes and distribution of related key. There can be multiple KGCs in a system, and new KGCs can only be added after they are approved by other KGCs. Each KGC has its own specific ID number and at a fixed time interval randomly generates an ID-based ID based on an algorithm . In a fixed period of time, KGC generates a large prime  based on  according to the self-energy contract code. The secondary node  and  transaction information generates random numbers  and  and generates . Each KGC generates its own key . Secondary node  receives , and secondary node  receives .
Secondary nodes  and  generate  and  based on their ID numbers. Generate verification key pairs  and  according to contract algorithm. The secondary node holds its own signature key pair, and the secondary node is the user who signs the KGC. Conduct transactions between secondary nodes to complete the peer-to-peer transaction information transfer process. After the KGC negotiates the transaction, it will be broadcasted to the entire network, and the new block will write the transaction, which will be confirmed and effective by each KGC master node.
3.2. Transaction Process
The network transaction process is as follows.
3.2.1. Signature Generation
The secondary node  has to conduct transactions with the secondary node , and the transaction task is . The secondary nodes  and  broadcast to the primary node KGC, and the secondary nodes  and  generate verification keys  and  according to their unique ID numbers IDA and IDB. Secondary node  retains  and secondary node  retains . The main node KGC has its own characteristic ID number and generates an identification number identifier  during the time period of transaction , . The contract can generate a large prime number  based on the identification , and send  to each KGC,  to the secondary node , and  to the secondary node . The primary node KGC holds , the secondary node  holds , and the secondary node  holds .
3.2.2. Signature Verification
The secondary nodes  and  conduct transactions, the secondary node  generates a key sequence  based on , the secondary node  generates a key sequence  based on , and the secondary nodes  and  send  and  to each other. The secondary node verifies the legality of the other party, and the formula is  then the identity is legal. If , it means that the secondary nodes  and  have not obtained the identification key issued by KGC and are not in the transaction, or the transaction has expired.
Compared with the verification algorithm of the identification standard, considering that there can be multiple KGC functional requirements in the consortium blockchain, the main KGC functions of the multi-KGC mode in this paper are allocated to the master node. The master node jointly participates in parameter maintenance and key generation, which meets the requirements of partial decentralization of the consortium blockchain. After verifying the identity and transaction legitimacy of the secondary nodes  and , they are sent  to KGC. Each KGC is calculated according to the competition and broadcasted to the main node KGC of the entire network. Each KGC writes a block after verification and broadcasts the secondary to the entire network. The transactions of nodes  and  are successfully included in the blockchain, and each KGC stores transaction information. Each KGC calculates  according to the competition of  and broadcasts it to the main node KGC of the whole network. Each KGC writes the block after verification and broadcasts the transactions of the secondary nodes  and  to the whole network, storing transaction information.
In a blockchain transaction, when a node interacts with information, it needs to check the other party’s information. KGC can find the key to which user  belongs according to the user information IDA it holds and check whether it is revoked and changed to determine the time of the transaction and legality. When revoking the secondary node, record the “obsolete” mark in the ID number of the member information to be revoked. Second, when the system parameters need to be updated, KGC can regenerate the system parameters and update the user information while retaining the system coefficients that were used.
3.3. Blockchain Generation and Verification
This paper proposes an authentication scheme based on the 2-adic ring algorithm, which is mainly applicable to the design architecture of the consortium blockchain. The main node KGC is responsible for the generation of the blockchain. Since the designed scenario is a cooperative relationship of KGC for mutual trust, the consensus algorithm for block generation designed by this scheme does not have strong block generation rewards and competition. We use semicompetitive and semirandom blockchain accounting right allocation to complete block generation. Since the various KGCs do not trust and cooperate with each other, we rule out malicious forks of the blockchain.
When the secondary nodes  and  initiate the transaction , the number  to which the last associated transaction information belongs and the hash value  to which  belongs to in the last associated transaction need to be added. The master node KGC needs to publish whether transaction  is the last related transaction of  and confirm whether the transaction between nodes  and  is legal. The block record information  of  is generated after the transaction.
The new block needs to record the number and hash value of the previous block to ensure the continuity of the block. Each node needs to confirm the legality of generating the identity of the master node when receiving the heart block, and after the latest block is associated, the transaction information verification process is performed.
3.4. Specific Process
Based on the ID number of the secondary node in this solution, the identification authentication key  can be generated, which can protect the privacy information of the secondary node, and can be designed to add the identification information of KGC to the ID when generating , so that KGC can be authorized under certain conditions and it can identify the identity of secondary nodes and realize the supervision of individuals and transactions. In actual scenarios, it can be used for Internet transactions based on citizen ID numbers. Each KGC can include a supervisory unit that issues citizen ID numbers. Internet applications that require identification, banks, governments, communication companies, schools, and other departments, need to confirm their identities and business handling and transactions.
The specific process is as follows (Figure 1):
(i)The secondary nodes  and  initiate the creation of transaction , and the secondary nodes  and  each verify the legitimacy of . According to the last associated transaction , both parties send a transaction request  to the primary node, KGC, after authentication by both parties(ii)After receiving the transaction request , each KGC generates a time-stamped large prime number  at a time interval and generates a verification key ; each KGC generates its own key , sends  to the secondary node , and sends  to the secondary node (iii)The secondary nodes  and  generate  and  through the smart contract encryption algorithm according to their respective ID numbers, generate authentication keys  and , and send it to each other(iv)Secondary nodes  and  verify if each other’s identity is legal and send  to all KGC after authentication(v)After each KGC receives , it competes to calculate , obtain accounting power, and broadcast  to the entire network, and the transaction validation process ends
[image: ]


Figure 1 
The flowchart of 2-adic ring AC algorithm.


4. Solution Security Analysis
4.1. Proof of Correctness
We introduce the nature of the  sequence; for the detailed proof, please refer to the literature [12].
For each integer ,  is satisfied  on the Galois ring . There is a maximum period sequence ,  sequence  maximum period is . Ring  maximum sequence  composition of the sequence set is defined as . The sequence  generated by  is defined by the following:
where ; ; ; .
The sequences generated by the largest periodic sequence of integers  in the  form a binary periodic sequence set. The largest periodic sequences make up the set  and period is . Any two sequences ,  in set ,   satisfy  [12].
The key point of the 2-adic ring AC algorithm proves is the arithmetic correlation property of sequence S, it has been proven readers may refer to [12].
4.2. Solution Security Analysis
4.2.1. Unforgeability Analysis
Identification signature  of the secondary node : because the IDA number is generated based on identity , if the attacker forges identity  and forges the verification sequence password , it is necessary to verify whether it is legal. Because the attacker cannot get , so this scheme can resist identity forgery.
Forged identity signature on KGC attack on master node : due to the overall design of the scheme, each KGC does not participate in the transaction, but only serves as transaction authentication and block generation, and the generation of block accounting rights is semirandom and does not rely too much on computing power and rights. Therefore, the attacker attacks KGC to obtain its own possibility of accounting rights. During the attack, there is no valuable information interaction between the malicious primary node and the malicious secondary node. Therefore, as long as there is any credible KGC, this scheme can resist forged malicious attacks.
4.2.2. Forward and Backward Security
When the system parameters of the identification password scheme need to be updated, KGC needs to renegotiate a new random number, determine a new identification signature based on its ID number, and issue new transaction keys to participating nodes. The previous system parameters should still be retained, and the node can verify the signature before the update based on the parameters in effect at the time. As for the system parameters, since the random numbers are randomly selected, there is no connection between the two before and after the update, and the attacker cannot forge the key before the update based on the key at the current stage. If the attacker holds the key before the update, he cannot join the participating nodes to forge the signature at the current stage.
4.3. Solution Efficiency and Safety Analysis
This solution is based on the 2-adic arithmetic correlation algorithm design. The legality verification key between nodes is a binary sequence string, which inherits the efficiency of sequence verification in communication. And each KGC competes to generate blocks with a simple polynomial time complexity, so the overall design scheme has higher verification block efficiency. In order to illustrate the operational efficiency and safety of this solution, this article lists several typical solutions for comparison (Table 1);  represents exponential calculation time,  represents the dot multiplication operation time of the elements in the ring, and  represents the homomorphic mapping operation time. Performance comparison and analysis table is available.
		

	Program	Signature efficiency	Verification efficiency	Forgery attack	Transaction information
	

	SM9			Satisfy	25 KB
	CPKC [3]			Satisfy	15 KB
	CSS [13]			Satisfy	20 KB
	2-Adic ring arithmetic authentication scheme			Satisfy	5 KB-10 KB
	





Table 1 
Scheme efficiency and safety comparison.


5. Conclusion
This article turns to the basic design ideas of the identification password and the functions of the main nodes of the consortium blockchain as the entry point. Using 2-adic ring theory and arithmetic related algorithms, a new identification password authentication scheme applied in consortium blockchain is designed to serve the fog computing devices. Under the premise that the master node trusts each other, the scheme designs the master node to bear the relevant functions of KGC and bear the responsibility of block generation and accounting. Through security proof and efficiency analysis, this scheme has signatures that cannot be forged, transaction node anonymity, and forward security. Because the scheme is designed to be in a trusted environment, transaction authentication and consensus protocols can be implemented with a set of algorithm schemes, so the computational efficiency is greatly improved compared to classic identification passwords such as SM9. This solution can realize the identity verification between nodes in terms of computing time and security and protect the privacy of the nodes, which meets the functional requirements of consortium blockchain multicentralization and protection of node identity information. How to generate blocks between master nodes with competitive interests will be the next step of research work.
Data Availability
The mathematical formula data used to support the findings of this study are included within the article.
Conflicts of Interest
The authors declare that they have no conflicts of interest.

References
	X. An, X. Zhou, X. Lü, F. Lin, and L. Yang, “Sample selected extreme learning machine based intrusion detection in fog computing and MEC,” Wireless Communications and Mobile Computing, vol. 2018, Article ID 7472095, 2018. View at: Publisher Site | Google Scholar
	H. Hui, C. Zhou, S. Xu, and F. Lin, “A novel secure data transmission scheme in industrial Internet of things,” China Communications, vol. 17, no. 1, pp. 73–88, 2020. View at: Publisher Site | Google Scholar
	M. Anwesha, D. Debashis, and G. Deepsubhra, “A power and latency aware cloudlet selection strategy for multi-cloudlet environment,” IEEE Transactions on Cloud Computing, vol. 7, no. 1, pp. 141–154, 2019. View at: Publisher Site | Google Scholar
	F. Lin, Y. Zhou, X. An, I. You, and K.-K. R. Choo, “Fair resource allocation in an intrusion-detection system for edge computing: ensuring the security of Internet of things devices,” IEEE Consumer Electronics Magazine, vol. 7, no. 6, pp. 45–50, 2018. View at: Publisher Site | Google Scholar
	C. Gong, F. Lin, X. Gong, and Y. Lu, “Intelligent cooperative edge computing in the Internet of things,” IEEE Internet of Things Journal, 2020. View at: Publisher Site | Google Scholar
	Y. Yu, Y. Mu, G. Wang, Q. Xia, and B. Yang, “Improved certificateless signature scheme provably secure in the standard model,” IET Information Security, vol. 6, no. 2, pp. 102–110, 2012. View at: Publisher Site | Google Scholar
	P. Gong and P. Li, “Further improvement of a certificateless signature scheme without pairing,” International Journal of Communication Systems, vol. 27, no. 10, pp. 2083–2091, 2014. View at: Publisher Site | Google Scholar
	I. Miers, C. Garman, M. Green, and A. D. Rubin, “Zerocoin: anonymous distributed E-cash from Bitcoin,” in 2013 IEEE Symposium on Security and Privacy, Berkeley, CA, USA, 2013. View at: Publisher Site | Google Scholar
	N. Shen and M. Adam, “Ring confidential transactions,” Ledger, vol. 1, no. 1, pp. 1–18, 2016. View at: Publisher Site | Google Scholar
	M. Goresky and A. Klapper, “Arithmetic crosscorrelations of feedback with carry shift register sequences,” IEEE Transactions on Information Theory, vol. 43, no. 4, pp. 1342–1345, 1997. View at: Publisher Site | Google Scholar
	A. Klapper and M. Goresky, “Feedback shift registers, 2-adic span, and combiners with memory,” Journal of Cryptology, vol. 10, no. 2, pp. 111–147, 1997. View at: Publisher Site | Google Scholar
	H. J. Wang, Q. Y. Wen, and J. Zhang, “GLS: new class of generalized Legendre sequences with optimal arithmetic cross-correlation,” RAIRO - Theoretical Informatics and Applications, vol. 47, no. 4, pp. 371–388, 2013. View at: Publisher Site | Google Scholar
	Y. Q. Li, J. G. Li, and Y. C. Zhang, “Certificateless signature scheme without random oracles,” Journal on Communications, vol. 36, no. 4, pp. 185–194, 2015. View at: Google Scholar


Copyright
Copyright Š 2020 Huijuan Wang and Yong Jiang. This is an open access article distributed under the   Creative Commons Attribution License, which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited.






More related articles




[image:  ]PDF[image:  ]         

Download Citation[image:  ]         

Citation

[image:  ]         

Download other formatsMore
ePub
[image:  ] 
    
     chevron-down copy 3
     Created with Sketch.
     
         
    
     
         
             
                 
                     
                         
                             
                                 
                            
                             
                             
                                 
                            
                        
                    
                
            
        
    


XML
[image:  ] 
    
     chevron-down copy 3
     Created with Sketch.
     
         
    
     
         
             
                 
                     
                         
                             
                                 
                            
                             
                             
                                 
                            
                        
                    
                
            
        
    



[image:  ] 
    
     align-left
     Created with Sketch.
     
         
    
     
         
             
                 
                     
                         
                             
                                 
                            
                             
                             
                                 
                            
                        
                    
                
            
        
    


Order printed copiesOrderViews298
Downloads337

Citations


Share Post
	[image:  ] 
    
     Twitter_Social_Icon_Circle_Color
     Created with Sketch.
     
         
             
                 
            
             
                 
            
        
    



	[image:  ]
	[image:  ]
	[image:  ]    




	[image:  ]        






Related articles






Follow us:[image:  ]  

[image:  ]  

[image:  ]   

[image:  ]  


	About us
	Contact us
	Partnerships
	Blog

	Jou";"""dc.publisher"",""Hindawi""
""og:image"",""https://images.hindawi.com/journals/wcmc/wcmc.banner.jpg""
""og:image:width"",""600""
""twitter:card"",""summary_large_image""
""citation_journal_title"",""Wireless Communications and Mobile Computing""
""language"",""en""
""og:description"",""In a fog computing environment, lots of devices need to be authenticated in order to keep the platform being secured. To solve this problem, we turn to blockchain techniques. Unlike the identification cryptographic scheme based on elliptic curves, the proposed 2-adic ring identity authentication scheme inherits the high verification efficiency and high key distribution of sequence ciphers of 2-adic ring theory, and this algorithm adds identity hiding function and trading node supervision function by design. The main designed application scenario of this solution is applicable to the consortium blockchain, and the master nodes are mutually trusting cooperative relations. The node transaction verification and block generation consensus algorithm designed in this solution can be implemented in a set of algorithms, which has higher verification efficiency and easier to be deployed than other solutions. This scheme can be widely used in the fog computing environment.""
""prism.issn"",""1530-8669""
""citation_issn"",""1530-8669""
""dc:title"",""A Novel Blockchain Identity Authentication Scheme Implemented in Fog Computing""
""Content-Encoding"",""UTF-8""
""citation_pdf_url"",""https://downloads.hindawi.com/journals/wcmc/2020/8849363.pdf""
""robots"",""index""
""google-site-verification"",""AxEuDsL7vXGOxRe53-uFhOk2ODN0bbXMeuBy6Pfq4ww""
""citation_author"",""Wang, Huijuan"",""Jiang, Yong""
""dc.date"",""2020/08/01""
""prism.volume"",""2020""
""citation_doi"",""https://doi.org/10.1155/2020/8849363""
""prism.publicationName"",""Wireless Communications and Mobile Computing""
""dc.title"",""A Novel Blockchain Identity Authentication Scheme Implemented in Fog Computing""
""Author"",""Hindawi""
""citation_volume"",""2020""
""dc.language"",""en""
""Content-Language"",""en""
""authors"",""Huijuan Wang | Yong Jiang""
""citation_title"",""A Novel Blockchain Identity Authentication Scheme Implemented in Fog Computing""
""citation_year"",""2020""
""citation_publisher"",""Hindawi""
""dc.format"",""text/html""
""description"",""In a fog computing environment, lots of devices need to be authenticated in order to keep the platform being secured. To solve this problem, we turn to blockchain techniques. Unlike the identification cryptographic scheme based on elliptic curves, the proposed 2-adic ring identity authentication scheme inherits the high verification efficiency and high key distribution of sequence ciphers of 2-adic ring theory, and this algorithm adds identity hiding function and trading node supervision function by design. The main designed application scenario of this solution is applicable to the consortium blockchain, and the master nodes are mutually trusting cooperative relations. The node transaction verification and block generation consensus algorithm designed in this solution can be implemented in a set of algorithms, which has higher verification efficiency and easier to be deployed than other solutions. This scheme can be widely used in the fog computing environment.""
""og:image:type"",""image/jpeg""
""citation_date"",""2020/08/01""
""title"",""A Novel Blockchain Identity Authentication Scheme Implemented in Fog Computing"",""A Novel Blockchain Identity Authentication Scheme Implemented in Fog Computing""
""twitter:image"",""https://images.hindawi.com/journals/wcmc/wcmc.banner.jpg""
""citation_online_date"",""2020/08/01""
""twitter:site"",""website""
""dc.type"",""Research Article""
""dc.source"",""Wireless Communications and Mobile Computing""
""dc.creator"",""Wang, Huijuan"",""Jiang, Yong""
""citation_fulltext_html_url"",""https://www.hindawi.com/journals/wcmc/2020/8849363/""
""prism.publicationDate"",""2020/08/01""
""Content-Length"",""906398""
""citation_xml_url"",""https://downloads.hindawi.com/journals/wcmc/2020/8849363.xml""
""Content-Type"",""text/html; charset=UTF-8""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""og:type"",""website""
""twitter:title"",""A Novel Blockchain Identity Authentication Scheme Implemented in Fog Computing""
""dc.description"",""In a fog computing environment, lots of devices need to be authenticated in order to keep the platform being secured. To solve this problem, we turn to blockchain techniques. Unlike the identification cryptographic scheme based on elliptic curves, the proposed 2-adic ring identity authentication scheme inherits the high verification efficiency and high key distribution of sequence ciphers of 2-adic ring theory, and this algorithm adds identity hiding function and trading node supervision function by design. The main designed application scenario of this solution is applicable to the consortium blockchain, and the master nodes are mutually trusting cooperative relations. The node transaction verification and block generation consensus algorithm designed in this solution can be implemented in a set of algorithms, which has higher verification efficiency and easier to be deployed than other solutions. This scheme can be widely used in the fog computing environment.""
""og:title"",""A Novel Blockchain Identity Authentication Scheme Implemented in Fog Computing""
""citation_abstract"",""In a fog computing environment, lots of devices need to be authenticated in order to keep the platform being secured. To solve this problem, we turn to blockchain techniques. Unlike the identification cryptographic scheme based on elliptic curves, the proposed 2-adic ring identity authentication scheme inherits the high verification efficiency and high key distribution of sequence ciphers of 2-adic ring theory, and this algorithm adds identity hiding function and trading node supervision function by design. The main designed application scenario of this solution is applicable to the consortium blockchain, and the master nodes are mutually trusting cooperative relations. The node transaction verification and block generation consensus algorithm designed in this solution can be implemented in a set of algorithms, which has higher verification efficiency and easier to be deployed than other solutions. This scheme can be widely used in the fog computing environment.""
""og:image:height"",""315""
""prism.doi"",""https://doi.org/10.1155/2020/8849363""
""dcterms.issued"",""2020/08/01""
""viewport"",""width=device-width, initial-scale=1""
""twitter:description"",""In a fog computing environment, lots of devices need to be authenticated in order to keep the platform being secured. To solve this problem, we turn to blockchain techniques. Unlike the identification cryptographic scheme based on elliptic curves, the proposed 2-adic ring identity authentication scheme inherits the high verification efficiency and high key distribution of sequence ciphers of 2-adic ring theory, and this algorithm adds identity hiding function and trading node supervision function by design. The main designed application scenario of this solution is applicable to the consortium blockchain, and the master nodes are mutually trusting cooperative relations. The node transaction verification and block generation consensus algorithm designed in this solution can be implemented in a set of algorithms, which has higher verification efficiency and easier to be deployed than other solutions. This scheme can be widely used in the fog computing environment.""
""dc.identifier"",""https://doi.org/10.1155/2020/8849363""
""prism.section"",""Research Article""
""og:url"",""https://www.hindawi.com/journals/wcmc/2020/8849363/""
";https://scholar.google.com/scholar?start=460&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095295-1251;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;An effective yield estimation system based on blockchain technology;M Osmanoglu, B Tugrul, T Dogantuna… ; IEEE Transactions on …, 2020  ieeexplore.ieee.org;;"… and verifies the real-world events, and reports this information to the blockchain and smart

contracts. Since smart contracts are executed depending on the data provided by oracles, oracles

hold substantial power over smart contracts. Thus, designing a correct oracle is crucial …";Cité 1 fois;;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/17/4429834/09086435.pdf?casa_token=qbe7ya7-cC4AAAAA:yKPG8cZQvCVucavAtWqz8zFxfY2dBqTFgxO1FZEql8kRYO5TmyYBsA3RQ5e1qodvybqwavUAXXc;"
		Skip to Main Content


		
			
				
				

				

			

		


		
			
				
					
						








	
		
	

	







						

						





























	
	
		
	
	
		
			

		
	

	
	
	



						





	
	
		
			
				IEEE Account

					Change Username/Password
	Update Address


			

			
				Purchase Details

					Payment Options
	Order History
	View Purchased Documents


			

			
				Profile Information

					Communications Preferences
	Profession and Education
	Technical Interests


			

			
				Need Help?

					US & Canada: +1 800 678 4333
	Worldwide:  +1 732 981 0060

					
	Contact & Support


			

		

		
			
				
					
							About IEEE Xplore
	Contact Us
	Help
	Accessibility
	Terms of Use
	Nondiscrimination Policy
	Sitemap
	Privacy & Opting Out of Cookies


						
							A not-for-profit organization, IEEE is the world's largest technical professional organization dedicated to advancing technology for the benefit of humanity.
Š Copyright 2021 IEEE - All rights reserved. Use of this web site signifies your agreement to the terms and conditions.
						

					


					

				

				
			

		

	


	
	


						
						






		
		
		
		
		
		
		
		
		
		
		
		
		
			
				
			
			
			
			
		
		
		
		
		
		

			


			

			
			


		
 		
		
			 

						
						









































	

		
		

		
		
		

		
			
		
		
		

		

		
		


		

		
		
		
		
		
		
		
		
		
		
	
	


















		
		
			
				
					
					
								
					
								
			
				
					
					
								
					
								
			
				
					
						








 



					
					
								
			
				
					
					
								
			
				
					
					
								
					
								
			
				
					
					
								
					
								
			
				
					
					
								
					
								
			
				
					
					
								
					
								
			
				
					
					
								
					
								
			
				
					
					
								
					
								
			
		
	




























		
			
					
			
					
			
					
			
				
					








					
			
					
			
					
			
					
			
					
			
					
			
					
			
		
		
	





	
	
	
	
	
	
	


	
	
	

	

















					

				

			


			
				
			
		

	";"""og:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""twitter:title"",""An Effective Yield Estimation System Based on Blockchain Technology""
""twitter:card"",""summary""
""Description"",""Price fluctuation in agricultural products that adversely affects the actors of the market is a serious issue influenced by many factors. Uncertainty in yield e""
""og:title"",""An Effective Yield Estimation System Based on Blockchain Technology""
""resourceName"",""09086435.pdf""
""language"",""en""
""title"",""An Effective Yield Estimation System Based on Blockchain Technology | IEEE Journals & Magazine | IEEE Xplore""
""og:description"",""Price fluctuation in agricultural products that adversely affects the actors of the market is a serious issue influenced by many factors. Uncertainty in yield estimation of the products can be counted as one of the major factors. It is a fact that an effective yield estimation method may help decision-making actors to develop effective and stable production and price policies. There are traditional and remote sensing methods aimed at calculating the correct yield estimate. However, these methods produce outputs only after the sowing season of the products. In this case, decision makers do not have enough instruments in hand to ensure price stability. Generally, the existing yield estimation systems are designed in a centralized setting. However, effective tracking may not be possible due to problems in the data flow. In this article, we will propose a blockchain-based solution that carries out yield estimation of agricultural products. Our solution brings all participants interested in agriculture together and produces an early yield estimation. Thus, the necessary precautions for the excessive imbalances that may arise in agricultural products will be planned in advance.""
""twitter:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-UA-Compatible"",""IE=Edge""
""viewport"",""width=device-width, initial-scale=1.0""
""dc:title"",""An Effective Yield Estimation System Based on Blockchain Technology | IEEE Journals & Magazine | IEEE Xplore""
""twitter:description"",""Price fluctuation in agricultural products that adversely affects the actors of the market is a serious issue influenced by many factors. Uncertainty in yield estimation of the products can be counted as one of the major factors. It is a fact that an effective yield estimation method may help decision-making actors to develop effective and stable production and price policies. There are traditional and remote sensing methods aimed at calculating the correct yield estimate. However, these methods produce outputs only after the sowing season of the products. In this case, decision makers do not have enough instruments in hand to ensure price stability. Generally, the existing yield estimation systems are designed in a centralized setting. However, effective tracking may not be possible due to problems in the data flow. In this article, we will propose a blockchain-based solution that carries out yield estimation of agricultural products. Our solution brings all participants interested in agriculture together and produces an early yield estimation. Thus, the necessary precautions for the excessive imbalances that may arise in agricultural products will be planned in advance.""
""Content-Encoding"",""UTF-8""
""Content-Type-Hint"",""text/html; charset=utf-8""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=50&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095334-1418;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;When Is Blockchain Worth It? A Case Study of Carbon Trading;F Zhao, WKV Chan ; Energies, 2020  mdpi.com;;"… costs, verification costs, legal liability, insider trading, tokens as securities, and cryptocurrency

price volatility … GPS and satellites could be utilized as oracles for monitoring and inspecting projects …

Blockchain provides a traceable and auditable record of emission reduction projects …";Cité 3 fois;Les 5 versions;[HTML] mdpi.com;https://www.mdpi.com/1996-1073/13/8/1980/htm;;;https://scholar.google.com/scholar?start=220&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095360-1524;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;[HTML][HTML] Electronic Markets on blockchain markets;R Alt ;2020 Springer;United Kingdom;"… One motivation may address the repeated security breaches that occurred with the cryptocurrency

marketplaces and … decentralized price feeds (or other data obtained via connectors referred to

as “oracles”) could support the … (2019), the applicability of blockchain technology as …";Cité 2 fois;Les 7 versions;[HTML] springer.com;https://link.springer.com/article/10.1007/s12525-020-00428-1;"
    
    
    
        
            
            
                
            

            
        
    


    
        
        

        
            
                Advertisement

                    

            

        


    
        
            
                
    
        
            
            [image: SpringerLink]
        
        
        
    


            

            
                
    
        
            
                Search
                
                    
                
            
        
        
            	
                    Log in
                


        
    

    



            

        

    

    
        
            
                
                    
                        
    
        Search SpringerLink
        
            
            
                Search
                
                    
                
            
            
                
            
            
        

    




                    

                

            

        

    



        

    
        
            
                
                
                    
                        
                            Electronic Markets on blockchain markets
                        

                        
    
        
            
                Download PDF
                
            
        
    



                    

                

            

            
                
    
        
            
                Download PDF
                
            
        
    


            


            
                
    

            



            
                
                    
                        	Editorial
	
            Open Access
        
	Published: 30 June 2020



                        
                        Electronic Markets on blockchain markets

                        	Rainer Alt1 


                        
                            
    Electronic Markets

                            volume 30, pages181–188(2020)Cite this article
                        

                        
    

                        
                            
    
        	
                    1865 Accesses

                
	
                    2 Citations

                
	
                        5 Altmetric

                    
	
                Metrics details

            


    




                        

                            
    

    

                    
                


                
                    
                    
    


                    

                    

                    
                        
                            Dear readers,

This issue of Electronic Markets includes a special issue on the potential and the limits of blockchain technology for networked businesses. Since 2008, distributed storage and computing technologies have seen a steep rise and received much attention in academia and practice. Blockchain is now recognized as one of the paramount information technologies that are expected to transform many industries. For example, Warner and Wäger (2019, p. 327) state that “new digital technologies such as blockchain, cloud, and IoT platforms are changing the nature of dynamic capabilities because organizations can now scale up or scale down their operations at a speed, ease, and cost that was not possible only a decade ago”. Much of the transformational power of these technologies is based on their infrastructural qualities (e.g. Luo et al. 2018 for cloud computing, Meyer et al. 2019 for blockchain and Zhu et al. 2020 for IoT and blockchain) and their role as general purpose technologies (Kane 2017). It may be assumed that the availability of an integrated information infrastructure that links all value chain (or value network) participants changes the interplay with business processes and business models. As argued in a prior editorial (see Alt and Zimmermann 2015), this reasoning is based on the analogy to the intraorganizational environment where integrated information systems have created an infrastructure for cross-functional processes and organization structures. However, designing similar infrastructures in the interorganizational domain is challenging as soon as the notion of infrastructure also comprises the more complex and diverse business aspects.

This follows the assessment of Kubicek and Cimander (2009), wo found the business level to be the most challenging. They argued that the seamless integration (i.e. interoperability) between organizations needs to be addressed on four levels with solutions for technical and syntactical interoperability being “fully developed” and solutions for semantic and organizational interoperability being either “theoretically developed” or still “vague [...] with large scope of interpretation” (p. 5). Obviously, this assessment dates back one decade and clearly before the advent of the infrastructure technologies mentioned above. This leads to the question of whether and how blockchain technology contributes to the interoperability of organizations and which potentials this technology holds for electronic markets. In general, Kubicek and Cimander (2009, p. 2) distinguish three “basic strategies” for coordinating cross-organizational processes. These are the centralization of tasks, the standardization of processes and the installation of clearing houses. While all of them are feasible and examples exist, research in the intraorganizational domain suggests that a straight answer is difficult since the impact of information technology depends on many factors. For example, in their seminal work Gurbaxani and Whang (1991) argued that factors internal (e.g. strategy, culture) and external (e.g. competition) to the organization determine whether firms “use information systems to decentralize some decision rights and to centralize others” (Gurbaxani and Whang 1991, p. 71). The same may be observed in the interorganizational domain: as summarized in the last editorial (Alt 2020), digital platforms and ecosystems have created interorganizational infrastructures that allow a centralization of distributed activities as well as their coordination on a decentralized basis.

Five perspectives on blockchain markets
To discuss the impact of blockchain technology on (electronic) markets in more detail, the notion of blockchain markets will be used in the following. It serves to identify the market of blockchain applications, the application of blockchain (as well as the broader distributed ledger) technology for electronic markets and the application of electronic market mechanisms for blockchain technologies. This yields five perspectives where blockchain technologies generate value (see Table 1 for a summary).
Table 1 Values of five blockchain market perspectivesFull size table

First, blockchain technologies are a market in themselves. As per 25 May 2020, the price-tracking service for cryptoassets Coinmarketcap listed 5500 cryptocurrencies with an impressive total market capitalization of USD 258 bn for this newly created market segment (Coinmarketcap 2020a). Although Bitcoin dominates this market with a share of 66.5%, the increasing number of new currencies makes this market a universe that is difficult to oversee. As a common denominator, these cryptocurrencies use cryptology for accessing and storing data in distributed databases, which comprise procedures for synchronizing the distributed data in order to achieve consistency. The notion of currency implies that exchange objects exist for compensating the participating actors. Over the past years, the cryptocurrency market has seen a rising variety of schemes or frameworks, which enhance the spectrum of technological infrastructures for digital transformation. These frameworks may be described as specific configurations of a cryptocurrency’s front- and backend design parameters. Among their design parameters are the
	
role of the network nodes (e.g. miners, validators and master-nodes vs. regular nodes),


	
scope of data replication (e.g. full vs. lightweight nodes),


	
adopted consensus mechanism (e.g. proof-of-work vs. proof-of-stake and others),


	
degree of anonymity (e.g. transparent vs. obscure trail of transactions),


	
implemented data structure (e.g. sequential blocks vs. directed acyclic graphs),


	
size of the data segments (e.g. blocks of 1 MB vs. 32 MB),


	
location of data storage (e.g. on-chain vs. off-chain), and the


	
accessibility of the network (e.g. public vs. private blockchains).



The market of cryptocurrencies has become increasingly complex and diverse with newly developed as well as with enhanced frameworks (e.g. occuring in soft and/or hard forks). Some cryptocurrencies have deviated in important aspects from the blockchain concept (e.g. with non-chain data structures) that they are more appropriately referred to as distributed ledgers. In addition, cryptocurrencies are established on other cryptocurrencies. For example, Ethereum’s ERC-20 token is used by several cryptocurrencies (e.g. Eos, Tron, USD Chain) and TeleCoin is built on top of Dash and PIVX. To navigate the dynamic token market identification and classification initiatives such as ITIN, the international token identification number, and ITC, the International Token Classification, have been proposed in analogy to the international security identification number (ISIN) and now await adoption (ITSA 2020).
Second, blockchain-based cryptocurrencies are traded goods on electronic markets. In parallel with the evolution of cryptocurrencies many cryptocurrency exchanges have appeared. The respective listing available on Coinmarketcap lists 341 marketplaces per 25 May 2020 with Binance being the largest by trading volume followed by Huobi Global and Bilaxy (Coinmarketcap 2020b). These digital platforms for trading cryptocurrencies are classical electronic markets with a centralized topology. Similar to foreign exchange markets, these ""coin markets"" pursue different business models. Among them are order-book exchanges, which focus on matching buyers and sellers, trading platforms, which focus on trading cryptocurrencies and derivatives via multiple exchanges as well as custodial exchanges, which primarily store cryptocurrency funds (Hileman and Rauchs 2017, p. 27ff). Depending on this strategic orientation, fees differ between the individual providers. Among the examples are fees for trading (e.g. 0.10% of trading volume at Binance), for the margins obtained in trading (e.g. 0.01–0.02% per trade at Kraken), fees for being inactive (e.g. five USD after 12 months at eToro) and for depositing or withdrawing money (e.g. 5% for credit/debitcards at Coinmama). While most exchanges operate markets for some hundred cryptocurrencies (e.g. Binance, Bittrex), others (e.g. Bitpanda, Coinbase) are limited to currencies with substantial market capitalization such as Bitcoin and Tether. Some exchanges (e.g. Coinbase, Kraken) also include the exchange between fiat currencies (i.e. “classical” currencies backed by governments such as the US Dollar or the Euro) and allow deposits in fiat currencies. In this case, the exchange’s IT systems are also linked to payment networks, such as SEPA in Europe or ACH in the US. Overall, the cryptocurrencies allow new investment strategies for traders and established banks have already opened cryptoportfolios and cryptofunds. However, these strategies also involve risks. Cryptocurrencies are asset classes with uncertainties since forks might lead to cyptocurrencies being discontinued and since the markets are rather volatile. In addition, the electronic market places for cryptocurrencies are mostly implemented on centralized information systems. This implies that the specific advantages of blockchain technologies, i.e. the high security levels regarding data access, integrity and immutability are not applicable to most of these platforms. In fact, Feder et al. (2017, p. 138) state that by 2013 “45% of Bitcoin currency exchanges had closed, and that many are plagued by frequent outages and security breaches.” Their research mentions that the once leading cryptoexchange Mt. Gox experienced 34 Distributed Denial of Service attacks prior to shutting down their operations in 2014 and they list similar attacks on other cryptoexchanges. At Mt. Gox, the theft of private keys from the centralized platform led to the loss of all cryptocurrencies held by the exchange, which amounted to 850,000 Bitcoins (Wieczner 2018). In view of the implications on the monetary system, providers of cryptoexchanges have alerted regulators worldwide and many national legislations now demand a license for commercially trading cryptocurrencies.
Third, blockchain technologies may contribute electronic currencies in electronic markets. This perspective takes a broader view than the second perspective and recognizes cryptocurrencies as currencies in economic transactions. In general, currencies serve three functions: they are a medium of exchange, a unit of account and a store of value (Baur et al. 2018). While established (fiat) currencies such as the US Dollar or the Euro typically meet these requirements due to the stability goals of the supporting governments and central banks, the situation is often different in less developed countries and cryptocurrencies. With cryptocurrencies being typically governed by open (developer) communities or businesses and not by political bodies, many of them have primarily served speculation purposes. Even the widespread Bitcoin “is mainly used as a speculative investment despite or due to its high volatility and large returns” (Baur et al. 2018, p. 178). The volatility makes it a risky storage for value and the small number of outlets a rather limited medium of exchange. At the same time, the inefficiencies in interorganizational transactions and the decentralized and anonymous nature of cryptopayments might prove as strong arguments for the diffusion of cryptocurrencies. By creating an efficient and secure means of exchange, they might reduce the friction that still exists in many value chains and payment systems. Although this favors their diffusion, additional developments are required to contain volatility and to increase trust. Several approaches are already under way that aim at linking the high efficiency of a digital payment scheme with more stability. Among them are:
	
Cryptoexchange currencies that were initiated by the exchange providers themselves to establish a unit of account for the respective platform, for example the Binance Coin BNB, the Bitpanda Ecosystem Token BEST or the Huobi Token HT. It is the goal of these platform providers to also have the currencies accepted on other cryptoexchanges.


	
Central bank digital currencies (CBDC) that are discussed as cryptocurrencies being issued by central banks (Lannquist et al. 2020). Similar to existing fiat currencies, the CBDCs would be backed up by central banks and are either offered in transactions between retail and central banks or with regular (corporate or private) transacting parties.


	
Stable coins as an approach to attain stability by linking a cryptocurrency to the rates of established reference values, such as gold or stable fiat currencies like the US Dollar or the Euro. Examples of stable coins may be found in cryptocurrencies such as Paxos Standard (1:1 of PAX with the US Dollar) and the much debated Libra token (1:1 of LBA with different national currencies), which is announced as “Simple Global Payment System” (Libra 2020).



Fourth, blockchain technologies may serve as infrastructure technology for electronic markets. In principle, this applies to the question of whether electronic markets use blockchain technology for their own operations. As mentioned above, this will not appeal to most existing cryptocurrency exchanges, which pursue a centralized marketplace design and have the market functionality (e.g. a credit auction) implemented in centralized software. Obviously, the lack of distributed functionality in this topology limits the benefits of replacing the centralized database with a distributed database. One motivation may address the repeated security breaches that occurred with the cryptocurrency marketplaces and another the transparency of marketplace processes (see Lee 2019, p. 774). The latter goes back to the tasks of intermediaries like platform providers, which are to collect offerings and requests from various sources (e.g. via their APIs) and to match this data following certain rules. The steps involved in this data transformation (e.g. homogenization, classification) are often not transparent and the providers might use these tasks to strengthen their competitive position in the market (Kumar and van Dissel 1996). To reduce concerns of opportunistic behavior among the platform participants, platform providers may increase transparency by adopting blockchain technologies, which store data in a distributed database. Depending on the configuration and data protection rules (e.g. Finck 2018), some data (e.g. transactions) may be stored on-chain and other data (e.g. product specifications) may be stored off-chain in separate databases at the platform provider or in systems at the platform participants. Obviously, this leads to the question of whether platform providers are still necessary and paves the road towards completely decentralized blockchain-based electronic marketplaces or decentralized exchanges (DEX). Important benefits are conceivable for all main functionalities of electronic markets (Subramanian 2018, p. 80f): more up-to-date and unbiased product information when matching buyers and sellers, higher levels regarding the privacy of personal data when validating transactions (in particular in international settings) as well as lower transaction costs involved in the (re)negotiation and the enforcement of contracts. In addition, DEX contribute to bypassing intermediaries and to reducing the costs for mediating between buyers and sellers (Wigand 2020). Along the third perspective mentioned above, existing decentralized marketplaces, such as Particl (e-commerce platform), IOTA (data marketplace) or Lazooz (mobility platform) have introduced their own cryptocurrencies (e.g. PART, MIOTA and ZOOZ) to facilitate transactions, while other decentralized e-commerce platforms such as OpenBazaar or OpenSea use third party currencies (e.g. ZCash and (W)ETH). Overall, these examples and research on decentralized markets (e.g. Serban et al. 2008, Prasad et al. 2018, Kabi and Franqueira 2019) have shown the feasibility of implementing marketplace functionality in distributed settings. For the financial domain, the notion of decentralized finance (DeFi) has spread (e.g. Schär 2020), which is based on decentralized exchange protocols (e.g. 0x, (Air)Swap, Bancor, Kyber Network, Market, UniSwap) and allows a glimpse of a variety of new decentralized business models.
All of these initiatives highlight the possibility of replacing the separate organization for managing the organization gap in the interorganizational setting. Figure 1 shows this by mapping the functionalities of electronic marketplaces to the three general layers of application systems (presentation, function, data, see Evans 2004). In the centralized client-server architecture model, users access the platform functionalities and the market backend with the catalog, matching and settlement functionality as well as the database via (more or less comprehensive) frontends (e.g. Menychtas et al. 2012). In many cases, the marketplace application is linked with enterprise applications for marketing, accounting, HR and the like. In the decentralized scenario, each node would (more or less) comprise all three layers implemented in blockchain-based markets (e.g. Viswanathan et al. 2019). While price and product listings may be included in the frontend, much of the market functionality is implemented in specific decentralized applications (so-called DApps, such as Auctionity or MPX), which specify the steps in electronic trading (e.g. place and browse orders, auction mechanism). They could be complemented with decentralized community services, for example reputation services, which are described in more detail in an article of this issue (see Hesse and Teubner 2020). In addition, decentralized price feeds (or other data obtained via connectors referred to as “oracles”) could support the selection of offerings and price discovery by providing links to off-chain databases (e.g. via Arbitrum or Mixicles). The infrastructure becomes less complex if electronic markets do not include price discovery and the matching of buyers and sellers. As illustrated with the many use cases collected by Casino et al. (2019), the applicability of blockchain technology as a distributed system of records for sharing information end-to-end in (per se) distributed supply chains is meanwhile undisputed and reflects an isomorphism that has been recognized as co-evolution in another editorial (Alt 2018). For networked businesses, the blockchain infrastructure creates a common but distributed application system with homogeneous databases and processes. However, this homogeneity typically applies to a certain blockchain implementation and with the multitude of such implementations a new interorganizational heterogeneity arises. This calls for solutions that not only integrate blockchain systems to internal enterprise systems, but also to other blockchains. Diverse initiatives are already looming on the horizon that aim at providing solutions for this integration challenge (e.g. Blockchain Interoperability Alliance, Chainlink or Enterprise Ethereum Alliance).
Fig. 1[image: figure1]
Architecture of centralized and decentralized electronic markets


Full size image

Fifth, there is the possibility to use electronic markets in consensus mechanisms. This perspective would tap the large body of knowledge on (electronic) auction mechanisms for designing consensus (e.g. mining or validation) in blockchain systems. In fact, existing consensus mechanisms already mirror market principles, for example, proof-of-work may be conceived as a first price auction mechanism. If users decide to pay higher fees, their transactions will be processed with higher priority (i.e. faster) by the miners. Research has revealed that alternative mechanisms for determining this sequence could benefit users and miners alike. For example, Basu et al. (2019) replaced the first price auction with a second price auction for fees in the Bitcoin system and report “more stable, predictable fees in cryptocurrencies” by preventing users from bidding strategically (Basu et al. 2019, p. 3). As argued by the authors, transactions in blockchain systems will have to be prioritized regardless whether proof-of-work, proof-of-stake or another mechanism is implemented. This implies that insights from auction theory will be beneficial for discussing improvements of consensus mechanisms. In addition, research by Chan et al. (2020) has shown that a mining procedure based on bidding for blocks (“the miner with the closest bid will get the mining reward and will consolidate the block into [the] blockchain” Chan et al. 2020, p. 61) would also contribute to significantly reducing the amount of energy required for mining new blocks.


Special issue articles
In summary, the five perspectives suggest that contrary to the earlier statement of Kubicek and Cimander challenges still exist for distributed technologies on the technological level, in particular regarding performance, scalability and ecology. Many challenges also persist regarding the business aspects and, in particular, regarding the adoption in the business world. This means that much of the potential of blockchain technology as general purpose technology still needs to be unlocked. In this vein, Hughes et al. (2019, p. 115) report that “studies have highlighted that transformative applications are still not commercially available and few organisations have progressed their blockchain solutions beyond the feasibility or prototype stage.” (Hughes et al. 2019, p. 115). This need for research sets the stage for the present special issue, which is titled “Potential and limits of blockchain technology for networked businesses”. The guest editors Roger Bons, Johan Versendaal, Liudmila Zavolokina and Weidong Larry Shi have organized this special issue to explicitly consider blockchain technology as a facilitator for new coordination mechanisms and for new (i.e. decentralized) forms of electronic markets. Their goal was “not to promote a technology push, but rather to investigate the emerging technology’s potential impact on how organizations inter-operate through electronic markets” (Bons et al. 2020). By combining the open call for papers with a fast track of the “Blockchain Technology” mini-track at the Hawaii International Conference on System Sciences (HICSS) in 2019, the guest editors were successful in compiling eight papers in their special issue, which they will all introduce in their separate preface. They emphasize several of the five perspectives: new business models, new forms of collaboration and investments as well as more efficient trading.
An opinion from the business world complements the research papers of this special issue. This interview with an executive from the European Energy Exchange (EEX) shows how a worldwide leading electronic market provider assesses the impact of blockchain technology on their strategy and their operations. Overall, Tobias Paulun sees advantages of centralized as well as of decentralized markets. On the one hand, he sees the centralized electronic market platform as unrivaled in the segment of wholesale energy trading in terms of efficiency and trust. At present, the benefits of the existing exchange procedures remain superior to the more recent blockchain infrastructures, which generate little added value in this market segment. On the other hand, access to the centralized exchange systems is limited to certified participants and requires other market participants (e.g. companies as prosumers of energy) to participate in energy trading via brokers. Often, these participants have decided against the complexities and risks of energy trading, which leaves a large number of potential market participants that does not participate in energy trading today. Due to the decentralized nature of these participants, decentralized blockchain technologies may prove beneficial, but still face important challenges. Similar to the expectation of Bons et al. (2020), whereas “old and new technologies may very well complement one another”, Paulun also expects centralized platforms and blockchain markets to co-exist (Alt and Wende 2020).
In addition to the special issue section and the interview, three papers are part of this issue's general research section. The first supports the argumentation of this editorial, whereas blockchain technologies enable the decentralization of many activities. Maik Hesse and Timm Teubner show this with their exciting analysis in the area of reputation management titled “Reputation portability – quo vadis?” (Hesse and Teubner 2020). They recognize that while customer feedback embedded in reputation scores is important for building trust in digital platforms, these trust-building mechanisms are largely limited to the respective platforms. Based on a conceptual model that was developed in multiple steps, the authors analyze personal information management systems (PIMS) and discuss possible future decentralized scenarios. Both remaining general research papers are fast-tracked from the HICSS mini-track on “Social Information Systems” in 2019. The authors Niklas Kühl, Marius Mühlthaler and Marc Goutier show in their paper how customer needs may be automatically derived from social media platforms using the example of Twitter data in the e-mobility domain (Kühl et al. 2020). Based on this data, the design-oriented methodology led to the deployment of a web service that applies a supervised machine learning algorithm and may be used for constantly eliciting customer needs for potentially increasing customer satisfaction. The third and final paper of this issue presents research on the skills (or affordances) of chatbots, which the authors Emanuel Stoeckli, Christian Dremel, Falk Uebernickel and Walter Brenner observed in 17 organizations. These affordances were derived from generalized use cases and classified in lower-level and higher-level affordances and constraints. The findings contribute in discovering and exploiting the potentials when linking social information systems (i.e. the chatbots) with traditional enterprises systems, such as customer relationship management systems (Stoeckli et al. 2020).


Awards and board members
Last but not least, the second issue of each volume is also an opportunity to thank authors and reviewers alike for their contribution to Electronic Markets. One symbol are the annual awards for outstanding papers and best reviewers. The candidates were identified in an internal quantitative and qualitative screening of papers and reviews. For the outstanding paper award, citations and download figures were analyzed together with a qualitative pre-screening by the Editorial Team in a first step and a voting among Senior and Associate Editors in a second step. The best reviewers were determined based on the number of reviews and on how they contributed in providing elaborate constructive feedback. Based on this process the awardees are:
	
Outstanding papers: Henner Gimpel, Daniel Rau and Maximilian RĂśglinger for their research on FinTech start-ups (Gimpel et al. 2018) and Dominik Jung, Verena Dorner, Christof Weinhardt and Hakan Pusmaz for their design of a robo-advisor (Jung et al. 2018).


	
Best reviewers: Maria Madlberger from Webster Vienna Private University in Austria and Peter Gomber from Goethe University Frankfurt in Germany.



The entire team of Electronic Markets wishes to congratulate these colleagues for their achievement and thanks all colleagues who helped determine this year’s awardees. Another big thank-you goes to the guest editor team of the present special issue and all the authors, reviewers as well as editors, who were involved in the articles of this issue! Truly, people are the key resource of an academic journal, which also applies to the Advisory Board of Electronic Markets. We are grateful that Antje Stobbe, Veni Markovski, Raj Ramaraj and Frank Riemensperger were available for advice during the past six years and cordially welcome several esteemed colleagues to the Advisory Board. We are happy that Rahul Basole from GeogiaTech and Accenture, Harry Bouwman from Delft University, Eric Clemons from the University of Pennsylvania, Svenja Falk from Accenture, Ali F. Farhoomand from the University of Hong Kong, Eric Johnson from Vanderbilt University, Stefan Klein from the University of Münster, James Short from the University of California San Diego, Charles Steinfield from Michigan State University, Yao-Hua Tan from Delft University, Hannes Werthner from the Technical University of Vienna, Andrew Whinston from Texas University, Rolf Wigand from Arizona State University, Howard Williams from Strathclyde University and Jing Zhao from the China University of Geosciences have agreed to join the Advisory Board.
Thank you to all of them and we hope you enjoy reading this issue of Electronic Markets.
Your EM-team.



                        
                    

                    References
	Alt, R. (2018). Electronic Markets on current general research. Electronic Markets, 28(2), 123–128. https://doi.org/10.1007/s12525-018-0299-0.

	Alt, R. (2020). Evolution and perspectives of electronic markets. Electronic Markets, 30(1), 1–13. https://doi.org/10.1007/s12525-020-00413-8.
Article 
    
                    Google Scholar 
                

	Alt, R., & Wende, E. (2020). Blockchain technology in energy markets – An interview with the European Energy Exchange. Electronic Markets, 30(2). https://doi.org/10.1007/s12525-020-00423-6.

	Alt, R., & Zimmermann, H.-D. (2015). Editorial 25/3: Electronic Markets on ecosystems and tourism. Electronic Markets, 25(3), 169–174. https://doi.org/10.1007/s12525-015-0197-7.

	Basu, S., Easley, D., O'Haraz, M., & Sirer, E.G. (2019). Toward";"""dc.publisher"",""Springer""
""og:image"",""https://media.springernature.com/w200/springer-static/cover/journal/12525.jpg""
""twitter:card"",""summary""
""og:site_name"",""Electronic Markets""
""citation_reference"",""Alt, R. (2018). Electronic Markets on current general research. Electronic Markets, 28(2), 123–128.  https://doi.org/10.1007/s12525-018-0299-0  ."",""citation_journal_title=Electronic Markets; citation_title=Evolution and perspectives of electronic markets; citation_author=R Alt; citation_volume=30; citation_issue=1; citation_publication_date=2020; citation_pages=1-13; citation_doi=10.1007/s12525-020-00413-8; citation_id=CR2"",""Alt, R., & Wende, E. (2020). Blockchain technology in energy markets – An interview with the European Energy Exchange. Electronic Markets, 30(2).  https://doi.org/10.1007/s12525-020-00423-6  ."",""Alt, R., & Zimmermann, H.-D. (2015). Editorial 25/3: Electronic Markets on ecosystems and tourism. Electronic Markets, 25(3), 169–174.  https://doi.org/10.1007/s12525-015-0197-7  ."",""Basu, S., Easley, D., O'Haraz, M., & Sirer, E.G. (2019). Towards a functional fee market for cryptocurrencies. Working paper Cornell University, SSRN.  https://doi.org/10.2139/ssrn.3318327   ."",""Baur, D.G., Hong, K., & Lee, A.D. (2018). Bitcoin: Medium of exchange or speculative assets? Journal of International Financial Markets, Institutions and Money, 54, 177–189.  https://doi.org/10.1016/j.intfin.2017.12.004  ."",""Bons, R., Versendaal, J., Zavolokina, L., & Shi, W. L. (2020). Potential and limits of blockchain technology for networked businesses. Electronic Markets, 30(2).  https://doi.org/10.1007/s12525-020-00421-8  ."",""citation_journal_title=Telematics and Informatics; citation_title=A systematic literature review of blockchain-based applications: Current status, classification and open issues; citation_author=F Casino, TK Dasaklis, C Patsakis; citation_volume=36; citation_publication_date=2019; citation_pages=55-81; citation_doi=10.1016/j.tele.2018.11.006; citation_id=CR7"",""citation_title=Proof of bid as alternative to proof of work; citation_inbook_title=Advances in cyber security; citation_publication_date=2020; citation_pages=60-73; citation_id=CR8; citation_author=WK Chan; citation_author=JJ Chin; citation_author=VT Goh; citation_publisher=Springer"",""Coinmarketcap (2020a). All cryptocurrencies.  https://coinmarketcap.com/all/views/all/  , Accessed May 25, 2020."",""Coinmarketcap (2020b). Top cryptocurrency exchanges.  https://coinmarketcap.com/rankings/exchanges/  , Accessed May 25, 2020."",""citation_title=Domain-driven design: Tackling complexity in the heart of software; citation_publication_date=2004; citation_id=CR11; citation_author=EJ Evans; citation_publisher=Pearson"",""citation_journal_title=Journal of Cybersecurity; citation_title=The impact of DDoS and other security shocks on Bitcoin currency exchanges: Evidence from Mt. Gox; citation_author=A Feder, N Gandal, JT Hamrick, T Moore; citation_volume=3; citation_issue=2; citation_publication_date=2017; citation_pages=137-144; citation_doi=10.1093/cybsec/tyx012; citation_id=CR12"",""Finck, M. (2018). Blockchains and data protection in the European Union. European Data Protection Law Review, 4(1), 17–35.  https://doi.org/10.21552/edpl/2018/1/6  ."",""citation_journal_title=Electronic Markets; citation_title=Understanding FinTech start-ups – A taxonomy of consumer-oriented service offerings; citation_author=H Gimpel, D Rau, M Röglinger; citation_volume=28; citation_issue=3; citation_publication_date=2018; citation_pages=245-264; citation_doi=10.1007/s12525-017-0275-0; citation_id=CR13"",""citation_journal_title=Communications of the ACM; citation_title=The impact of information systems on organizations and markets; citation_author=V Gurbaxani, S Whang; citation_volume=34; citation_issue=1; citation_publication_date=1991; citation_pages=59-73; citation_doi=10.1145/99977.99990; citation_id=CR14"",""Hesse, M., & Teubner, T. (2020). Reputation portability – quo vadis? Electronic Markets, 30(2).  https://doi.org/10.1007/s12525-019-00367-6  ."",""citation_title=Global cryptocurrency benchmarking study; citation_publication_date=2017; citation_id=CR15; citation_author=G Hileman; citation_author=M Rauchs; citation_publisher=University of Cambridge"",""citation_journal_title=International Journal of Information Management; citation_title=Blockchain research, practice and policy: Applications, benefits, limitations, emerging research themes and research agenda; citation_author=L Hughes, YK Dwivedi, SK Misrab, NP Rana, V Raghavan, V Akella; citation_volume=49; citation_publication_date=2019; citation_pages=114-129; citation_doi=10.1016/j.ijinfomgt.2019.02.005; citation_id=CR16"",""ITSA (2020). What we do. International Token Standardization Association e.V., Berlin.  https://itsa.global/what-we-do/  , Accessed May 20, 2020."",""citation_journal_title=Electronic Markets; citation_title=Designing a robo-advisor for risk-averse, low-budget consumers; citation_author=D Jung, V Dorner, C Weinhardt, H Pusmaz; citation_volume=28; citation_issue=3; citation_publication_date=2018; citation_pages=367-380; citation_doi=10.1007/s12525-017-0279-9; citation_id=CR18"",""citation_title=Blockchain-based distributed marketplace; citation_inbook_title=Business information systems workshops. BIS 2018. Lecture notes in business information processing; citation_publication_date=2019; citation_pages=197-210; citation_id=CR19; citation_author=OR Kabi; citation_author=VNL Franqueira; citation_publisher=Springer"",""Kane, E. (2017). Is blockchain a general purpose technology?, available at SSRN:  https://ssrn.com/abstract=2932585   or  https://doi.org/10.2139/ssrn.2932585  ."",""Kubicek, H., & Cimander, R. (2009). Three dimensions of organizational interoperability - insights from recent studies for improving interoperability frame-works. European Journal of ePractice, (6),  http://www.dlorg.eu/uploads/External/Publications/6.1.pdf  , Accessed May 22, 2020."",""Kühl, N., Mühlthaler, M., & Goutier, M. (2020). Supporting customer-oriented marketing with artificial intelligence: Automatically quantifying customer needs from social media. Electronic Markets, 30(2).  https://doi.org/10.1007/s12525-019-00351-0  ."",""citation_journal_title=MIS Quarterly; citation_title=Sustainable collaboration: Managing conflict and cooperation in interorganizational systems; citation_author=K Kumar, HG Dissel; citation_volume=20; citation_issue=3; citation_publication_date=1996; citation_pages=279-300; citation_doi=10.2307/249657; citation_id=CR22"",""Lannquist, A. et al. (2020). Central bank digital currency policy-maker toolkit. Insight Report, World Economic Forum, Geneva."",""citation_journal_title=Business Horizons; citation_title=A decentralized token economy: How blockchain and cryptocurrency can revolutionize business; citation_author=JY Lee; citation_volume=62; citation_issue=6; citation_publication_date=2019; citation_pages=773-784; citation_doi=10.1016/j.bushor.2019.08.003; citation_id=CR24"",""Libra (2020). Welcome to the Libra project.  https://libra.org  , Accessed May 25, 2020."",""citation_journal_title=Information Systems Management; citation_title=Producing competitive advantage from an infrastructure technology: The case of cloud computing; citation_author=X Luo, W Zhang, R Bose; citation_volume=35; citation_issue=2; citation_publication_date=2018; citation_pages=147-160; citation_doi=10.1080/10580530.2018.1440732; citation_id=CR26"",""citation_title=A marketplace framework for trading cloud-based services; citation_inbook_title=Proceedings GECON 2011, Springer lecture notes in computer science no. 7150; citation_publication_date=2012; citation_pages=76-89; citation_id=CR27; citation_author=A Menychtas; citation_author=SG Gomez; citation_author=A Giessmann; citation_author=A Gatzioura; citation_author=K Stanoevska; citation_author=J Vogel; citation_author=V Moulos; citation_publisher=Springer"",""citation_journal_title=Computers & Industrial Engineering; citation_title=Blockchain technology enabling the physical internet: A synergetic application framework; citation_author=T Meyer, M Kuhn, E Hartmann; citation_volume=136; citation_publication_date=2019; citation_pages=5-17; citation_doi=10.1016/j.cie.2019.07.006; citation_id=CR28"",""Prasad, R.V., Dantu, R., Paul, A., Mears, P., & Morozov, K. (2018). A decentralized marketplace application on the Ethereum blockchain. Proceedings International Conference on Collaboration and Internet Computing (CIC), IEEE, pp. 90–97.  https://doi.org/10.1109/CIC.2018.00023  ."",""Schär, F. (2020). Decentralized finance: On blockchain- and smart contract-based financial markets. SSRN.  https://www.ssrn.com/abstract=3571335  , Accessed June, 2, 2020."",""citation_journal_title=Electronic Commerce Research; citation_title=The concept of decentralized and secure electronic marketplace; citation_author=C Serban, Y Chen, W Zhang, N Minsky; citation_volume=8; citation_issue=1–2; citation_publication_date=2008; citation_pages=79-101; citation_doi=10.1007/s10660-008-9014-0; citation_id=CR32"",""Stoeckli, E., Dremel, C., Uebernickel, F., & Brenner, W. (2020). How affordances of chatbots cross the chasm between social and traditional enterprise systems. Electronic Markets, 30(2).  https://doi.org/10.1007/s12525-019-00359-6  ."",""Subramanian, H. (2018). Decentralized blockchain-based electronic marketplaces. Communications of the ACM, 61(1), 78–84.  https://doi.org/10.1145/3158227  ."",""Viswanathan, R., Dasgupta, D., & Govindaswamy, S.R. (2019). Blockchain solution reference architecture (BSRA). IBM Journal of Research and Development, 63(2/3), 1:1–1:12.  https://doi.org/10.1147/JRD.2019.2913629  ."",""citation_journal_title=Long Range Planning; citation_title=Building dynamic capabilities for digital transformation: An ongoing process of strategic renewal; citation_author=KSR Warner, M Wäger; citation_volume=52; citation_issue=3; citation_publication_date=2019; citation_pages=326-349; citation_doi=10.1016/j.lrp.2018.12.001; citation_id=CR35"",""Wieczner, J. (2018). $1 billion Bitcoins lost in Mt. Gox hack to be returned to victims. Forbes, June 22.  https://fortune.com/2018/06/22/bitcoin-price-mt-gox-trustee/  , Access May 27, 2020."",""citation_journal_title=Electronic Markets; citation_title=Whatever happened to disintermediation?; citation_author=RT Wigand; citation_volume=30; citation_issue=1; citation_publication_date=2020; citation_pages=39-47; citation_doi=10.1007/s12525-019-00389-0; citation_id=CR37"",""Zhu, Q., Loke, S. W., Trujillo-Rasua, R., Jiang, F., & Xiang, Y. (2020). Applications of distributed ledger technologies to the internet of things: A survey. ACM computing surveys, 52(6), 120:1-120:34.  https://doi.org/10.1145/3359982  .""
""citation_journal_title"",""Electronic Markets""
""language"",""en""
""citation_cover_date"",""2020/06/01""
""prism.issn"",""1422-8890""
""citation_author_email"",""rainer.alt@uni-leipzig.de""
""twitter:image:alt"",""Content cover image""
""prism.number"",""2""
""citation_issn"",""1422-8890""
""citation_language"",""en""
""dc:title"",""Electronic Markets on blockchain markets | SpringerLink""
""Content-Encoding"",""UTF-8""
""citation_pdf_url"",""https://link.springer.com/content/pdf/10.1007/s12525-020-00428-1.pdf""
""citation_lastpage"",""188""
""DOI"",""10.1007/s12525-020-00428-1""
""citation_fulltext_world_readable"",""""
""citation_journal_abbrev"",""Electron Markets""
""prism.rightsAgent"",""journalpermissions@springernature.com""
""citation_author"",""Rainer Alt""
""resourceName"",""s12525-020-00428-1""
""dc.date"",""2020-06-30""
""citation_springer_api_url"",""http://api.springer.com/metadata/pam?q=doi:10.1007/s12525-020-00428-1&api_key=""
""citation_issue"",""2""
""prism.volume"",""30""
""prism.publicationName"",""Electronic Markets""
""citation_doi"",""10.1007/s12525-020-00428-1""
""dc.title"",""Electronic Markets on blockchain markets""
""prism.url"",""https://link.springer.com/article/10.1007/s12525-020-00428-1""
""citation_volume"",""30""
""dc.language"",""En""
""Content-Language"",""en""
""format-detection"",""telephone=no""
""citation_publication_date"",""2020/06""
""prism.endingPage"",""188""
""citation_title"",""Electronic Markets on blockchain markets""
""citation_author_institution"",""Information Systems Institute, Leipzig University, Leipzig, Germany""
""access"",""Yes""
""citation_publisher"",""Springer Berlin Heidelberg""
""applicable-device"",""pc,mobile""
""dc.format"",""text/html""
""description"",""""
""title"",""Electronic Markets on blockchain markets | SpringerLink""
""citation_online_date"",""2020/06/30""
""twitter:site"",""@SpringerLink""
""dc.source"",""Electronic Markets 2020 30:2""
""dc.type"",""EditorialNotes""
""dc.copyright"",""2020 The Author(s)""
""dc.creator"",""Rainer Alt""
""citation_fulltext_html_url"",""https://link.springer.com/article/10.1007/s12525-020-00428-1""
""prism.publicationDate"",""2020-06-30""
""Content-Type"",""text/html; charset=UTF-8""
""journal_id"",""12525""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""dc.description"",""""
""og:type"",""article""
""citation_article_type"",""Editorial""
""og:title"",""Electronic Markets on blockchain markets""
""prism.doi"",""doi:10.1007/s12525-020-00428-1""
""X-UA-Compatible"",""IE=edge""
""citation_firstpage"",""181""
""prism.startingPage"",""181""
""viewport"",""width=device-width, initial-scale=1""
""dc.rightsAgent"",""journalpermissions@springernature.com""
""prism.section"",""EditorialNotes""
""dc.identifier"",""doi:10.1007/s12525-020-00428-1""
""dc.subject"",""IT in Business"",""e-Commerce/e-business""
""og:url"",""https://link.springer.com/article/10.1007/s12525-020-00428-1""
""prism.copyright"",""2020 The Author(s)""
";https://scholar.google.com/scholar?start=330&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095288-1222;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Distributed service?level agreement management with smart contracts and blockchain;RB Uriarte, H Zhou, K Kritikos, Z Shi… ; Concurrency and …, 2020  Wiley Online Library;;"… agreed conditions hold. The permissioned blockchain is formed by a randomly

selected set of oracles, which perform service monitoring and provide objective

measurements and undisputed transactions. The outcome of these …";Cité 3 fois;;[PDF] wiley.com;https://onlinelibrary.wiley.com/doi/pdf/10.1002/cpe.5800;;;https://scholar.google.com/scholar?start=20&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095383-1629;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Spitz: a verifiable database system;M Zhang, Z Xie, C Yue, Z Zhong ; arXiv preprint arXiv:2008.09268, 2020  arxiv.org;;"… QLDB aims to provide the high performance of database systems with integrity guarantees

for data and historical data ver- sions. Similarly, Oracle Blockchain Table [13] offers append-

only verifiable tables by implementing a centralized ledger model …";Autres articles;;[PDF] arxiv.org;https://arxiv.org/pdf/2008.09268;"
Spitz: A Verifiable Database System

Meihui Zhang1 Zhongle Xie2 Cong Yue2 Ziyue Zhong1

1 Beijing Institute of Technology 2 National University of Singapore
meihui zhang@bit.edu.cn, zhongle@comp.nus.edu.sg, yuecong@comp.nus.edu.sg, ziyue zhong@bit.edu.cn

ABSTRACT
Databases in the past have helped businesses maintain and
extract insights from their data. Today, it is common for
a business to involve multiple independent, distrustful par-
ties. This trend towards decentralization introduces a new
and important requirement to databases: the integrity of the
data, the history, and the execution must be protected. In
other words, there is a need for a new class of database sys-
tems whose integrity can be verified (or verifiable databases).

In this paper, we identify the requirements and the design
challenges of verifiable databases. We observe that the main
challenges come from the need to balance data immutabil-
ity, tamper evidence, and performance. We first consider
approaches that extend existing OLTP and OLAP systems
with support for verification. We next examine a clean-slate
approach, by describing a new system, Spitz, specifically
designed for efficiently supporting immutable and tamper-
evident transaction management. We conduct a preliminary
performance study of both approaches against a baseline
system, and provide insights on their performance.

PVLDB Reference Format:
Meihui Zhang, Zhongle Xie, Cong Yue, Ziyue Zhong. Spitz: A
Verifiable Database System. PVLDB, 13(12): 3449-3460, 2020.
DOI: https://doi.org/10.14778/3415478.3415567

1. INTRODUCTION
Traditional database systems are indispensable for busi-

nesses.They excel at storing, processing, and performing an-
alytics over business transactions. Recent digital optimiza-
tion and transformation have enabled businesses to transact
directly with each other, without relying on a central party.
As a result, multiple parties can access a shared database.
Since the parties are mutually distrustful, the underlying
database must consider support for auditing, tamper evi-
dence, and dispute resolution in its design. For instance,
it must maintain a trusted data history and allow users to
verify the integrity of both current and historical data.

This work is licensed under the Creative Commons Attribution-
NonCommercial-NoDerivatives 4.0 International License. To view a copy
of this license, visit http://creativecommons.org/licenses/by-nc-nd/4.0/. For
any use beyond those covered by this license, obtain permission by emailing
info@vldb.org. Copyright is held by the owner/author(s). Publication rights
licensed to the VLDB Endowment.
Proceedings of the VLDB Endowment, Vol. 13, No. 12
ISSN 2150-8097.
DOI: https://doi.org/10.14778/3415478.3415567

Blockchains demonstrate one practical design for database
systems with strong integrity [21]. Public blockchain sys-
tems, such as Ethereum, support secure peer-to-peer ap-
plications through smart contracts. Private blockchains,
such as Hyperledger Fabric, target business settings and
achieve higher performance than public ones. Blockchains
have drawn interests from banks and regulators, with the
prospect of offering digital currency and digital banking.
Combined with recent advances in 5G, AI and IoT, block-
chains are expected to speed up the transformation and fur-
ther disrupt the e-commerce and financial industries.

To make a database that can be accessed by potentially
malicious parties trustworthy, it must be verifiable. A veri-
fiable database system protects integrity of the data, of its
provenance, and of its query execution. More specifically,
any tampering such as changing the data content, changing
a historical record, or modifying query results, can be de-
tected. We note that the demand for verification is on the
rise due to the requirements imposed by the regulators on
various business sectors, investment and banking in partic-
ular.

The first requirement in the design of a verifiable database
(VDB) is data immutability, which is necessary for main-
taining trusted provenance. Immutability means data is
only written once and never deleted. It is not a new con-
cept. It has been used in NoSQL systems such as HBase [4],
CouchDB [1] and RethinkDB [8] to achieve more efficient
concurrency, due to the fact that no synchronization of ac-
cesses is needed. It is also used in Resilient Distributed
Datasets (RDDs)[9] for lineage and fault tolerance. The
second requirement of a verifiable database is query verifi-
ability. It means the query results contain integrity proofs
for both the data and query execution. More specifically, a
user can detect if either the data or the query execution has
been tampered.

In this paper, we discuss four challenges in realizing the
design of verifiable databases. The first challenge is in stor-
age management, as data immutability requires managing
the ever-increasing volume of data. Consider a typical health-
care analytic application, in which health data needs to be
kept for the lifetime of a patient, and each diagnosis, lab test,
prescription, etc., is appended to the patient profile. Disease
and procedure coding standards evolve over time, e.g., from
ICD-9-CM to ICD-10 in recent years. Such changes in clas-
sification and coding standards require updates or mapping
onto the existing medical record. To ensure good data prove-
nance, the data must be immutable and a new version of the
database, i.e., a snapshot, is appended. The data volume is

ar
X

iv
:2

00
8.

09
26

8v
1 

 [
cs

.D
B

] 
 2

1 
A

ug
 2

02
0



 0

 200

 400

 600

 800

 1000

10 20 30 40 50 60

S
to

ra
g
e
 (

K
B

)

#Versions

Storage-ForkBase
Storage

Figure 1: Data storage improved by deduplication.

increasing with time, and therefore its management needs
to be efficient and reliable. Let us consider another exam-
ple where an immutable database stores 10 WIKI pages of
16 KB each initially. We create a new version when updat-
ing a page, while keeping the previous versions. Figure 1
shows the space utilized with an increasing number of ver-
sions. Clearly, the space utilization increases substantially
with the number of immutable versions, and the use of an
efficient multi-version storage engine such as ForkBase [51]
helps to reduce it. This highlights the importance of storage
efficiency for a database that is forever increasing in size.

The second challenge is to provide efficient access methods
for querying immutable data. While some existing database
systems archive historical data and support temporal query
processing, they have not been designed to support “perma-
nent” immutability. In VDB, data is never deleted; query
processing and frequent searching on older versions of the
data will be prohibitively expensive if efficient storage lay-
out and indexes are not supported. This may entail scan-
ning of a substantial portion of the database for answering
verification queries.

The third challenge is to minimize performance overhead
of verification. VDB must generate integrity proofs whose
cost can be significant. Blockchains, for example, have poor
transaction throughput due to their protocols for guaran-
teeing security in the Byzantine environment. The perfor-
mance gap between traditional databases and blockchains is
significant due to their different design focus. As a result, a
verifiable database must adopt a hybrid blockchain-database
approach in order to strike a better balance between perfor-
mance and security.

The fourth challenge is the need to support both OLTP
and OLAP workloads, as illustrated by the emergence of
HTAP database systems. The former requires serializabil-
ity which is important for applications such as e-commerce.
Most existing OLTP systems adopt optimistic concurrency
control (OCC), instead of pessimistic concurrency control,
because of its simplicity and high performance. In contrast,
analytic queries in OLAP do not require the strict ordering
provided by serializability. Existing OLAP systems adopt
multi-version concurrency control (MVCC) to achieve data
consistency with high performance. Most existing works on
verifiable queries focus on OLTP workloads. While general
OLAP queries can be made verifiable, for example by using
fully-homomorphic encryption, they involve complex cryp-
tographic operations and incur significant overhead [40, 47].

Financial
Transactions

Logistic
Orders

Medical
Records

Verification Digital Token
Transferring

Credit
Reports

Verifiable 
Database  System

Verifiable Data Structure

Multi-version StoreKey-Value Store Row Store Columnar Store

Version
Management

E-commerce
Events

Figure 2: Verifiable database system overview.

Therefore, it is challenging to support both verifiable OLTP
and OLAP queries with practical performance.

In addition to the four challenges above, we note that
VDB must also aim for deployability. It is often costly
to either add a new database system into an existing in-
frastructure, or to replace an existing database with a new
one. In particular, for a business with consolidated soft-
ware stacks, data conversion is necessary to move data to
the new database. Furthermore, users may find the system
difficult to use if the verifiable database adopts unfamiliar
programming models or interface.

In this paper, we discuss two approaches to realize an
efficient VDB. The first approach is to extend existing sys-
tems, and the second is to design a new system from scratch.
Figure 2 shows the second approach and how it fits with
existing business applications. The new system uses tamper-
evident structures for verification, and efficient version man-
agement for performance.

We make the following contributions in this paper:

• We identify the requirements and design challenges of
efficient verifiable databases.

• We discuss two approaches for realizing an efficient ver-
ifiable database: by extending existing systems, and a
new clean-slate design called Spitz.

• We perform an experimental study on Spitz and com-
pare it with a baseline. The results show that Spitz
can achieve good performance, despite overhead from
verification and additional data structures.



• We discuss various future research topics, including the
integration of learning methods onto VDB and version
management of the machine learning pipeline.

The rest of this paper is organized as follows. In Sec-
tion 2, we present existing works and systems that are re-
lated to VDB processing. In Section 3, we discuss the re-
search challenges and opportunities of VDB. We next de-
scribe the challenges in the approach of extending existing
OLTP and OLAP system to implement VDB in Section 4.
In Section 5, we present the system architecture of Spitz. We
then present an experimental study in Section 6, and com-
pare our systems against a baseline implementation based
on a commercial service. We discuss the promising synergy
between VDB and AI in Section 7, before concluding in Sec-
tion 8.

2. VERIFIABLE DATABASES
In this section, we survey existing works and systems with

verification features.

2.1 Verifiable Database
Data integrity is important in outsourced database as

third-party service providers can be malicious. In partic-
ular, applications running on top of an outsourced database
require the data and query results from the providers to be
verifiable, that is, tampering of data and query execution
can be securely detected. One way to achieve verifiabil-
ity is using verifiable computation techniques. Benabbas et
al. [16] present a delegation scheme on verifiable database
minimizing the resources required by the clients of verifiable
database. Guo et al. [25] improve the update efficiency using
a long polynomial for public keys and a short polynomial
for private keys. Miao et al. [36] enable efficient keyword
search for VDB using enhanced vector commitment while
HVDB [65] supports hierarchical verification by building a
vector commitment tree. SNARKs [40] can support arbi-
trary computation tasks, but requiring an expensive setup
phase, and incurring significant overhead. Ben-Sasson et
al. [15] improve upon SNARKs by bounding the complexity
of the setup phase to size of the database and the query com-
plexity. More recently, Zhang et al. [63] propose a system
called vSQL that uses an interactive protocol to support ver-
ifiable SQL queries. However, vSQL is limited to relational
databases with a fixed schema.

Another way to achieve verifiability is by using authenti-
cation data structures such as Merkle trees. Li et al. [29]
propose and evaluate authentication index structures com-
bining Merkle trees and B+-trees. Yang et al. [57] propose
integrity-protected MR-tree for spatial data. ServeDB [54]
proposes a Merkle tree index based on hierarchical cube en-
coding that supports efficient multi-dimensional queries. Se-
curity conscious applications enforce data integrity against
malicious modifications not only from external attackers,
but also from malicious insiders and cloud hosting opera-
tors. As a solution, SUNDR [30] cryptographically protects
all file system contents and proposes a fork consistency pro-
tocol to detect data tampering.

More recent systems, namely VeritasDB [49] and Con-
certo [14], leverage trusted hardware to speed up verifica-
tion. In particular, both store Merkle tree data inside SGX
enclaves. Veritas stores the roots of the trees, and Concerto

uses memory verification technique to avoid contention in-
side the enclaves.

2.2 Out-of Blockchain Database
Blockchains, which was originally designed for cryptocur-

rencies, is now being used as a general-purpose transac-
tional system. Being a distributed data processing system, a
blockchain system shares some similarities with a distributed
database system. However, its focus is security, whereas the
database’s focus is performance. The design space of both
systems can be viewed along four dimensions: replication,
concurrency, storage and sharding. A recent work [45] pro-
vides an extensive and in-depth comparison of blockchain
versus database. It shows that along the four design dimen-
sions, different choices lead to different performance. We are
seeing a trend of merging these two systems into a design
that is secure, efficient, and can be readily adopted by ap-
plications such as logistic, digital banking, and digital asset
management.

One step toward realizing a hybrid blockchain-database
is to support rich data queries on blockchains [22, 35, 43,
10]. A simple approach is to join the network as a full node
and then execute the query. However, running a full node
is expensive. vChain [56] addresses this problem by em-
bedding an aggregate and constant-size authentication data
structure, constructed with multiset accumulator, in each
block header. This allows users to run a light node to query
with integrity guarantee. TrustDBle [23] proposes a secure
and scalable OLTP engine that provides verifiable ACID-
compliant transactions on shared data using trusted hard-
ware.

BlockchainDB [22], Veritas [24], FalconDB [42], and Lin-
eageChain [44, 46] are recent systems that use blockchain as
a verifiable storage and add database features on top of it.
We now discuss these systems in more detail.

BlockchainDB adopts a simple key-value data model, and
exposes Put/Get/Verify operations to clients. It consists
of a database layer and a storage layer. The former con-
trols the consistency level of requests so that clients can
choose the balance of result staleness and performance. The
storage layer serves as the unified interface to the under-
lying blockchains. It translates requests from the database
layer into blockchain transactions and monitors the trans-
action status. When a client invokes Verify, a blockchain
node would contact other peers to check whether the corre-
sponding transaction is committed in the ledger. A node in
BlockchainDB does not hold the complete copy of the state.
Instead, the states are partitioned to multiple blockchains.

Veritas shares a similar goal and vision with BlockchainDB,
but differs in three aspects. First, it targets complex data
models, i.e., relational model. Second, it employs Trusted
Execution Environments (TEEs) such as Intel SGX as the
trustable verifiers that consume the database logs for the
transaction validation. The validation results, in the form
of verifiers’ votes, are persisted in the blockchain. As a re-
sult, when there is a dispute, any party can resolve it by
reconciling the database log with the votes on the ledger.
Third, Veritas does not support partitioning, as it does not
store all states on the blockchain.

Instead of checking the ledger for log validation, FalconDB
organizes database records into an authenticated data struc-
ture, such as a Merkle tree, which enables a succinct in-
tegrity proof on a database record. FalconDB employs an



incentive model allowing clients to selectively challenge the
transaction results from a suspicious server. If the server
cannot provide proof of correctness, it will be penalized.
FalconDB also supports authenticated queries on a tempo-
ral data model, so that users may access data snapshot with
respect to a particular block.

LineageChain [44, 46] is a fine-grained, secure, and effi-
cient provenance system built on top of ForkBase [51, 32]
and FabricSharp[3]. It provides provenance information to
smart contracts through simple interfaces to enable a new
class of blockchain applications whose execution logics de-
pend on provenance information at runtime. LineageChain
captures provenance during contract execution and stores it
in a Merkle tree implemented in ForkBase, and provides a
novel skip list index to support efficient provenance queries.

2.3 Ledger Database
Amazon offers Quantum Ledger Database (QLDB) [11],

a cloud service that provides data immutability and verifi-
ability. QLDB consists of blocks organized in a hash chain
called journal. Changes to the data, including insert, update
and delete, are collected into blocks and appended to the
journal. A Merkle tree is built upon the entire journal. To
support efficient query, the journal is materialized to user-
defined tables for the latest data and history data. QLDB
aims to provide the high performance of database systems
with integrity guarantees for data and historical data ver-
sions. Similarly, Oracle Blockchain Table [13] offers append-
only verifiable tables by implementing a centralized ledger
model. MongoDB [12] supports verifiable change history by
storing document collections in a hash chain.

Datomic [2] is a distributed immutable database system
designed to be ACID compliant, with datom as its database
building block. It is a form of key-value store, and Datoms
are collected to form an entity. It makes use of key-value
stores such as Amazon DynamoDB for managing the data,
and allows users to obtain a historic snapshot of the database
via its APIs and query language. Immudb [6] is a recently
released immutable tamper-evident open source database
system. Due to the demand for VDB, we foresee active
development in such kind of database systems. However,
with no deletion, the database size will grow over time, and
query processing efficiency and scalability could become ma-
jor concerns.

3. CHALLENGES AND OPPORTUNITIES
In this section, we discuss the research challenges in im-

plementing an efficient VDB. In particular, the requirements
of immutability and verifiability have implications on stor-
age and indexing, query verification, and concurrency con-
trol mechanisms. We discuss the methodologies from recent
works that provide building blocks for VDB.

3.1 Storage and Indexing
VDB requires an immutable and tamper-evident storage

engine. In particular, the storage must support integrity
proof generation, and have an efficient version management
mechanism.

ForkBase [51], a storage with Git-like version control and
branch management, and Merkle-based directed acyclic graph
(DAG) data structure, provides a good starting point. Fork-
Base supports collaborative analytics, and content-based data

deduplication mechanism that significantly reduces data vol-
ume in the physical storage. Furthermore, it supports effi-
cient version querying.

As in traditional databases, indexes are necessary for fast
retrieval and location of records. Recent Merkle tree-based
indexes, namely Merkle Patricia Trie (MPT) [53], Merkle
Bucket Tree (MBT) [5], and Pattern-Oriented-Split Tree
(POS-Tree) [51], support efficient queries on immutable data.
[59] contains a comprehensive analysis of these indices, show-
ing that MPT, MBT, and POS-Tree are different instances
of Structurally Invariant and Reusable Indexes (SIRI) [51],
and that POS-tree has better overall performance. In ad-
dition to these indices which are designed for query verifi-
ability, other indices are needed to further speed-up data
retrieval. Since versions can be modeled as temporal or his-
torical data, indexes such as the historical R-tree[37], and
rolling index Bx-tree [26] could be adapted to support the
multi-dimensional and single-dimensional queries. We envi-
sion that the need for fast querying of historical data will
lead to new, innovative indexes.

3.2 Verification
Query verifiability in VDB means that the user who sends

the query can verify the integrity of the result, that is the
data and execution have not been tampered with. We dis-
cuss here different approaches to achieve verifiability.

Client-side verification vs Server-side verification.
When the data is outsourced to a third party, the users
themselves must verify some proofs provided by the third
party. However, verification can be expensive for the users,
especially when running on low-power devices. Trusted hard-
ware, such as Intel SGX, can help mitigate this cost for user,
by supporting server-side verification. In particular, the
hardware performs verification securely at the servers, by
running verification inside trusted execution environments,
and output only succinct proofs that can be verified cheaply
by the user. However, the secure hardware has limited re-
sources that can lead to significant performance overhead.
Furthermore, existing secure hardware are vulnerable to side-
channel attacks that compromise their security.

Online verification vs Deferred verification. With
respect to the timing of the verification, there are two ap-
proaches: online, and deferred verification. In the former,
the data must be committed after the verification succeeds,
which is useful when recovery from malicious tampering is
costly. In the latter, verification is done over a batch of
transactions, therefore achieving higher throughput than the
former.

Verification via encryption. One way to protect data
integrity is by using authenticated encryption. Users can
encrypt data using private key and store the ciphertexts
on untrusted storage. Data tampering can be detected di-
rectly with the authentication tag. The limitation of this
approach is that it restricts computation (or queries) on the
ciphertexts. Encryption schemes with various support for
computation on ciphertexts exist, but they have trade-off in
security and computation. All of these schemes have signif-
icant performance overhead.

Verification via authentication data structure. Au-
thentication data structures, which are based on Merkle
trees, provide data integrity with low cost. In this struc-
ture, the leaf nodes contain cryptographic hashes of the data
blocks, while the non-leaf nodes contain the hashes of their



OLTP Service

OLAP Service

Ledger

Read/Write

ETL

Read/Write

Proof

Proof

Transaction

Transaction

Result + Proof

Result + Proof

Figure 3: Non-intrusive design.

child nodes. The hash of the root node is called the “digest”
of the data. The integrity proof consists of the hashes of the
nodes from the corresponding leaf to the root of the tree.
The new digest is recalculated recursively and equality is
checked with the previously saved digest.

3.3 Concurrency Control
Many outsourced or cloud databases are multi-tenant.

Applications running on top of a multi-tenant database may
require different ACID isolation levels. The database of-
ten has fixed the transaction isolation levels at the time of
deployment, therefore applications have to implement their
own levels for their needs, which increases the complexity of
the system. This problem can be mitigated by using per-
tenant database architecture, but this approach does not
scale well.

Consider as an example an e-commerce system with cus-
tomer credits. On the one hand, the purchases of the items
must occur in sequence to prevent double spending or ship-
ping out-of-stock items. In other words, the transaction
schedule needs to be serializable, which can be implemented
using optimistic concurrency control (OCC) or multi-version
concurrency control (MVCC) with abortion on read-write
conflicts. On the other hand, the analysis report or sta-
tus checking on the system may not require strict isolation.
Such queries are mostly processed as read-only workloads,
and many of them require near real-time responses. For
example, read committed isolation will be sufficient to ex-
ecute query “getting all items with stock-level lower than
50”. In this case, it is unnecessary to abort the query when
read-write conflicts occur.

A common approach to achieving high performance for
weak isolation is to fix the isolation to a weak level (e.g.,
read committed), and implement customized logic to han-
dle stricter level in the applications. Such design involves
locks, checking pre-images of data and sometimes reversions,
therefore complicating the application logic and incurring
large overhead. By providing flexible isolation levels in the

Read/Write + Proof

OLTP Service

OLAP Service

ETL

Read/Write + Proof

Ledger

Ledger

Transaction

Transaction

Result + Proof

Result + Proof

Figure 4: Intrusive design.

underlying database, it allows for performance optimization
and lets users focus more on the application logic.

4. EXTENDING OLTP/OLAP TO VDB
VDB can be implemented by adding a verifiable ledger

to an existing database system. The ledger supports im-
mutable data and verifiable queries. Here we discuss the
challenges of integrating such a ledger to OLTP and OLAP
systems.

There are two designs for integration, as shown in Fig-
ure 3 and Figure 4. The blue arrows, rectangles and cylin-
ders depict a typical data processing flow, where the data is
collected by OLTP and analyzed by OLAP systems.

Non-intrusive design. As shown in Figure 3, a ledger is
attached without modifying the architecture of the original
database systems. However, additional steps are added dur-
ing transaction processing. The OLTP and OLAP systems
generate integrity proofs from an independent ledger. On
the one hand, this design minimizes disruption to existing
systems, as it does not require changes to existing data. On
the other hand, it incurs considerable performance overhead,
due to the interaction with the ledger.

Intrusive design. Another design, as depicted in Fig-
ure 4, is to embed the ledger into an existing database sys-
tem. This eliminates communication with an outside ledger,
by generating the integrity proof inside the database. While
reducing performance overhead compared to the other de-
sign, it incurs significant cost in data migration. In particu-
lar, data must be moved to the new system, which may be
too costly for users with large amounts of data.

Another approach is to integrate the ledger with a hy-
brid transactional/analytical processing (HTAP) system. A
HTAP system is designed to unify efficient processing of op-
erational and analytical workloads in the same database. In
the HTAP system, no data migration from OLTP system to
OLAP system is necessary. Existing OLTP systems are be-
ing converted to HTAP by exploiting in-memory processing
[61] and both columnar and row storage structures. Some



A

AB AC

ACIJABC

ADI

B

BA

ForkBase

Cell Store Ledger

Storage
Layer

Control
Layer

Indexes

Request Handler

Auditor

Read Result + Proof

Get ProofProof

TM

Processor

…

Request Handler

Auditor

Write Result + Proof

Update LedgerProof

TM

Processor

Figure 5: System architecture.

recent NewSQL systems also adopt HTAP in their design
and implementation.

5. SYSTEM ARCHITECTURE
In this section, we discuss the system architecture of Spitz,

a distributed database designed from scratch that supports
both OLTP and OLAP workloads with verifiable ledgers.
As shown in Figure 5, the system consists of two layers: the
control layer, and the storage layer.

The control layer consists of multiple processor nodes that
accept and process requests from a global message queue1.
Each node has three main components: a request handler,
an auditor, and a transaction manager (TM). The request
handler accepts query requests and returns the results with
the corresponding proofs. The auditor communicates with
the ledger in the storage layer to keep track of data changes.
The transaction manager controls the execution of the queries
in the storage.

The storage layer features a distributed storage engine,
namely ForkBase. Built on top of ForkBase is a virtual
cell store, as opposed to row or column store in traditional
databases. The system maps each cell to a universal key
consisting of the column id, primary key, timestamp, and the
hash of its value. There are multiple index structures built
into the storage layer to support verifiable query processing.

1Similar to other distributed systems, the coordination, as
well as the resource management, is done by a master node.

Ledger. This structure consists of a sequence of hashed
blocks. Each block tracks the modification of the records,
query statements, metadata and the root node of the in-
dexes on the entire dataset. The block and the data can be
verified using the Merkle tree structure built on top of the
entire ledger. Section 5.3 discussed more details regarding
verification and proof generation.

Index. Spitz uses a B+-tree for query processing. The
input of the index is the requested keys, and the output is
the matched data cell. This structure is efficient for both
point and range queries.

Inverted Index. When processing analytical queries,
the system uses an inverted index to quickly locate the rows
to fetch data. Such an index uses the value recorded in each
cell as index key and the universal key of the correspond-
ing cell as value. The structure of the inverted list varies
according to the type of the data stored in the cell. For
instance, for numeric type, the system uses a skip list to
better support range query, whereas for string type, it uses
a radix tree to reduce space consumption.

5.1 Query Processing
The processor nodes handle both read, write, and mixed

workload. Spitz supports both SQL and a self-defined JSON
schema.

Write workload. There are four steps in handling a
write workload. (1) The request handler collects a transac-
tion from the message queue. (2) The auditor checks the
write operations and updates the ledger. The ledger records



the changes and returns a proof to the auditor. (3) The pro-
cessor traverses the B+-tree index and performs the write
operations to the cell store. (4) The processor collects the
results, combines them with the proof, and sends back to
the user through the request handler.

Read workload. The processing of read workload fol-
lows similar steps. (1) The request handler receives a trans-
action from the message queue. (2) The processor collects
the results by traversing corresponding inverted indexes and
retrieving the cell store. (3) The processor visits the ledger
via the auditor, getting the proofs of the results. The proof
generation is done by the ledger using the universal keys
and the internal nodes of inverted index. (4) The processor
combines the results and the proofs as responses and the
request handler returns them to the user.

Spitz uses a HTAP design to overcome the data movement
between OLTP and OLAP systems. Similar to the intrusive
design in Figure 4, it requires users to replace the underly-
ing database systems, which might be highly tangled with
their business. However, it should be highlighted that Spitz
can be used as an individual ledger by solely waking up the
auditor in the processor. Thus, the system can be applied
into a non-intrusive design shown in Figure 3 as a short-
term transition plan of integrating Spitz into the real-world
business. Ultimately, users should use Spitz as a standalone
and complete database system to cover and develop their
business.

5.2 Concurrency Control
Concurrency control in each proces";"""date"",""2020-08-24T01:01:52Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2020-08-24T01:01:52Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016) kpathsea version 6.2.2""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2020-08-24T01:01:52Z""
""created"",""2020-08-24T01:01:52Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-08-24T01:01:52Z""
""resourceName"",""2008.09268""
""Author"",""""
""producer"",""pdfTeX-1.40.17""
""pdf:docinfo:producer"",""pdfTeX-1.40.17""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2020-08-24T01:01:52Z""
""Last-Modified"",""2020-08-24T01:01:52Z""
""dcterms:modified"",""2020-08-24T01:01:52Z""
""title"",""""
""Last-Save-Date"",""2020-08-24T01:01:52Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2020-08-24T01:01:52Z""
""meta:save-date"",""2020-08-24T01:01:52Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016) kpathsea version 6.2.2""
""Content-Length"",""732919""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""12""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""4682"",""3851"",""5623"",""5632"",""3704"",""2618"",""5531"",""3512"",""4008"",""4213"",""4706"",""4700""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-08-24T01:01:52Z""
";https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095323-1364;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Secure data sharing and customized services for intelligent transportation based on a consortium blockchain;D Wang, X Zhang ; IEEE Access, 2020  ieeexplore.ieee.org;;"… To prevent the insecure problems caused by the random oracle model, Ge et al … were proposed

and proved against chosen-ciphertext attack secure in the adaptive model without random oracles …

In addition, some scholars have applied blockchain to intelligent trans- portation …";Cité 6 fois;;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/6287639/8948470/09042215.pdf;"
		
	";"""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""dc:title"",""IEEE Xplore Full-Text PDF:""
""Content-Encoding"",""UTF-8""
""resourceName"",""09042215.pdf""
""language"",""es""
""Content-Length"",""2565""
""title"",""IEEE Xplore Full-Text PDF:""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=170&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095341-1448;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Business Process Management;A Asatiani, JM García, N Helander, A Jiménez;Ramírez… 2020 Springer;;"… and Michael Rosemann Blockchain Oracles: A Framework for Blockchain-Based Applications.....

19 Kamran Mammadzada, Mubashar Iqbal, Fredrik Milani, Luciano García-Bańuelos, and

Raimundas Matulevi?ius Foundational Oracle Patterns: Connecting Blockchain to the Off …";Les 2 versions;;null;;;;https://scholar.google.com/scholar?start=250&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095302-1281;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Blockchain and other Distributed Ledger Technologies, an advanced primer;G Hilary ; Forthcoming, Innovative Technology at the interface of …, 2020  papers.ssrn.com;;"… Electronic copy available at: https://ssrn.com/abstract=3740067 Page 15. 15 or delayed).33

Decentralized oracle services such as ChainLink are currently developing systems … this

vulnerability.34 Oracles such as Augur, Gnosis or Polyswarm offer blockchain-based …";Cité 3 fois;;null;;;;https://scholar.google.com/scholar?start=80&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095358-1516;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Blockchain & Business Methods: How Business Method Patents May Be Redeemed by Furthering Blockchain Innovation;K Prange ; Colo. Tech. LJ, 2020  HeinOnline;;"… about 1,291 new applications in 2017. 33 There are exciting applications for

blockchain technology, beyond cryptocurrency, with the potential to greatly benefit

the public welfare. This Note discusses three such applications …";Autres articles;;[PDF] colorado.edu;https://ctlj.colorado.edu/wp-content/uploads/2020/04/6-Prange-03.10.20.pdf;"
6 PRANGE 03.10.20 (DO NOT DELETE) 4/8/2020 12:39 AM 

 

185 

BLOCKCHAIN & BUSINESS METHODS: 
HOW BUSINESS METHOD PATENTS 

MAY BE REDEEMED BY FURTHERING 
BLOCKCHAIN INNOVATION 

KURT PRANGE* 

Business methods remain a controversial area of innovation for 

which the United States Patent and Trademark Office (“USPTO”) 

grants patent protection. The USPTO frequently rejects business 

method patent applications for attempting to claim an “abstract 

idea,” only granting patents after the initial patent claims have been 

narrowed to improve a specific physical technology. Some argue that 

granting patent rights for business methods cannot be justified 

because the costs to society outweigh the benefits, concluding that 

business methods should always be excluded from consideration for 

patent protection. If these arguments are persuasive and successful, 

it could lead to the patent office neglecting useful innovations near 

the intersection of computing technology and business methods to 

the detriment of the public good. To show that business method 

patents can be more beneficial than costly to society, the USPTO 

must demonstrate that it is granting business method patents with 

unquestionable utility. 

 

* Kurt is a J.D. Class of 2019 graduate of the University of Colorado Law 

School, where he served as a member of the Colorado Technology Law Journal (the 

""CTLJ"") and a student attorney with the Entrepreneurial Law Clinic. Many thanks to 

all who helped along the way. First, I give special thanks to Professor Harry Surden (my 

Patent Law professor) and Molly Kocialski (Director of the Rocky Mountain Regional 

United States Patent and Trademark Office) for bringing the two sides of this business-

method-patent controversy to life for me during my 2L year. The coffee-stained pages of 

my Patent Law textbook trigger now fond memories of that magical semester when I 

started many a day reading for class on the 6 a.m. bus from Boulder to Denver en route 

to my USPTO externship. Second, I would like to thank Josephine Chang (Partner, 

Lewis Roca Rothgerber Christie). Her article, published during my 2L-summer 

clerkship, ""Blockchain: What is it and can I protect it via patents?"" inspired my approach 

to this Note. Third, I would like to thank Professor Amy Griffin for her insightful 

comments to my early draft. Fourth, I would like to thank the Colorado Intellectual 

Property American Inn of Court for assigning me to the ""Blockchain and the Law"" 

presentation team for November 15, 2018, at the USPTO. Finally, I would like to thank 

everyone involved with the CTLJ for their enthusiasm and encouragement. They pack a 

ton of hard work and learning into one credit hour. 
 



6 PRANGE 03.10.20 (DO NOT DELETE) 4/8/2020  12:39 AM 

186 COLO. TECH. L.J. Vol. 18.1 

Business method patents could be pivotal to furthering 

“blockchain” innovation. Blockchain—the technology behind 

cryptocurrencies like Bitcoin and Ethereum—is nascent and in need 

of innovation before it can be a realistic, sustainable solution for a 

wide variety of main-stream applications. Blockchain technology 

was designed to eliminate the need for trusted third-party 

intermediaries (e.g., banks and credit card companies) between 

transacting parties. Initially intended to support cryptocurrencies, 

blockchain technology may be useful in other areas where the 

immutability, reliability, and security of a database are essential. 

However, the computational power required to perpetuate and 

secure a blockchain, as designed by its creator, consumes 

tremendous electrical energy. Efficiency gains from hardware 

improvements alone cannot keep up with projected increases in 

demand. The business method patent could be a powerful tool for 

encouraging innovation that transforms blockchain from a fledgling 

technology with great potential to a technology that profoundly 

improves business transactions. 

 

INTRODUCTION................................................................................. 187 
I. HISTORY OF BUSINESS METHOD PATENTS—AS THE PENDULUM 

SWINGS .................................................................................. 193 
A. Hotel Security Checking: Advice Is Not Patentable ........ 194 
B. State Street: A Useful, Concrete, and Tangible Result ... 195 
C. Efforts to Curb Patent Trolling? ...................................... 195 

1. Bilski: The Machine or Transformation Test Is Not the 

Only Test...................................................................... 195 
2. Mayo & Alice: Abstract Ideas and Significantly  

 More  ............................................................................ 197 
D. Pathways to Patentability ................................................ 198 

1. Alice/Mayo Step One (USPTO Step 2A) ................... 199 
a. Enfish: Improvements in Computer  

 Functionality ......................................................... 199 
2. Alice/Mayo Step Two (USPTO Step 2B) ................... 200 

a. BASCOM: Non-Conventional and Non-Generic 

Combinations ........................................................ 200 
II. AN ARGUMENT AGAINST BUSINESS METHOD PATENTS .......... 200 

A. When Patent Rights Are Justified: A Taxonomy for 

Problematic Patents .......................................................... 201 
B.  A Comparison of Patent Types—Justifiable or 

Unjustifiable? .................................................................... 203 
1.   Pharmaceutical Patents Are Justifiable ................... 203 
2. Business Method Patents Are Problematic ............... 203 
3. Amazon’s “1-Click” Patent: A Real-World Business 

Method ......................................................................... 204 



6 PRANGE 03.10.20 (DO NOT DELETE) 4/8/2020  12:39 AM 

2020 BLOCKCHAIN & BUSINESS METHODS 187 

III. BLOCKCHAIN ............................................................................. 206 
A. What is Blockchain? ............................................................ 206 
B. The Big Concepts Behind How Blockchain Works.......... 207 

1. Distributed Ledger Technology: The Transaction 

Process ......................................................................... 208 
2. Incentive, Consensus, and Irreversibility Through 

Proof-of-Work............................................................... 209 
3. Smart Contracts and Decentralized Applications .... 211 
4. Proof-of-Work vs. Proof-of-Stake ................................ 212 

C. Would the Inventor of Blockchain Have Received a  

 Patent? ............................................................................... 213 
D. Blockchain-Related Invention Beyond Cryptocurrency .. 214 

1.  Product Tracking/Traceability ................................... 215 
2. Peer-to-Peer Energy Trading ..................................... 216 
3. Medical Record Coordination ..................................... 216 

E. Blockchain Limitations .................................................... 218 
1.   Burdensome Power Consumption ............................. 218 

a. Alternate Approaches to Proof-of-Work ................ 218 
b. Unanticipated Real-World Weaknesses ............... 219 

3. Extremely Limited Data Storage ............................... 220 
IV. AN ARGUMENT FOR BUSINESS METHOD PATENTS VIS-À-VIS 

BLOCKCHAIN ......................................................................... 220 
A.  Alice and Its Progeny Have Eliminated the Pure Business 

Method Patent ................................................................... 221 
B.  Blockchain Is Ripe for Alice-era Business Method 

Improvements .................................................................... 221 
C.  Alice-era Business Method Patents May Be More 

Justifiable Than Problematic .......................................... 222 
1.  Will Blockchain Inventions Be Expensive to Develop 

and Easy to Copy? ....................................................... 222 
2. Would Blockchain Inventions Be Produced Absent 

Exclusivity?.................................................................. 223 
3. Will Society Receive Something Valuable in  

 Exchange? .................................................................... 223 
4. Will Blockchain Patents Unduly Inhibit  

 Competitors? ................................................................ 223 
5. Is the 20-year Term Needed to Capture Value? ....... 224 

CONCLUSION .................................................................................... 224 
 

INTRODUCTION 

In 2014, Alice Corp. v. CLS Bank ushered in a shift in the 

requirements for patent eligibility in the areas of business method 



6 PRANGE 03.10.20 (DO NOT DELETE) 4/8/2020  12:39 AM 

188 COLO. TECH. L.J. Vol. 18.1 

and software patents.1 The Supreme Court put an end to the era of 

the “pure” business method patent by effectively requiring that 

such inventions yield technological improvements instead of merely 

a useful result.2 Alice sent shockwaves of uncertainty through the 

patent law community.3 The Supreme Court declared Alice Corp.’s 

business method patent claims invalid as patent-ineligible subject 

matter under 35 U.S.C. § 101.4 Applying a new two-prong test, the 

Court held that (1) Alice Corp.’s claims were “directed to”—i.e., 

claimed, at least in part—the “abstract idea” of intermediated 

settlement and (2) failed to add “significantly more” to that abstract 

idea; thus, the patent claims amounted to no more than a mere 

claim to the abstract idea itself.5  

Alice Corp.’s patent was for a method of mitigating settlement 

risk in financial transactions between two parties.6 Settlement risk 

is the risk that one party will not pay, but still receive the benefit 

of the exchange.7 Alice Corp.’s solution was to have a computer 

serve as a trusted third-party intermediary, which would monitor 

each party’s financial records and allow transactions only if both 

parties have the resources to meet their obligations.8 The Court 

reasoned that intermediated settlement is an abstract idea because 

it is a “fundamental economic practice,” and the method failed to 

add significantly more because the recited computer functions were 

“‘well-understood, routine, conventional activit[ies]’ previously 

known to the industry.”9 The Court suggested that the claims at 

issue would have been more likely to meet the requirements for 

patent eligibility if they had purported to improve the functioning 

of the computer technology itself.10 

Many had called for the Court to discourage patent trolling 

behavior by reigning in overbroad patent claims like those at issue 

 

 1. Alice Corp. Pty. Ltd. v. CLS Bank Int’l, 573 U.S. 208; see Donald S. Chisum, The 
Supreme Court’s Alice Decision on Patent Eligibility of Computer-Implemented 
Inventions: Finding an Oasis In the Desert, PATENTLYO (June 23, 2014), 
https://patentlyo.com/patent/2014/06/eligibility-implemented-inventions.html 
[ttps://perma.cc/D7LK-2Y5L]. 
 2. Chisum, supra note 1. 
 3. See Alice, supra note 1; Chisum, supra note 1. 
 4. See Alice, supra note 1, at 212, 
 5. See U.S. Patent No. 5,970,479 (filed May 28, 1993) (issued Oct. 19, 1999) 
(containing claim 33, which was cited by the Supreme Court in Alice); 35 U.S.C. § 101 
(2018); See Alice, supra note 1, at 212, 225. 
 6. See Alice, supra note 1, at 212. 
 7. Id. 
 8. Id. 
 9. Id. at 225 (quoting Mayo Collaborative Servs. v. Prometheus Labs., Inc., 566 
U.S. 66, 68 (2012)). 
 10. Id. 

 



6 PRANGE 03.10.20 (DO NOT DELETE) 4/8/2020  12:39 AM 

2020 BLOCKCHAIN & BUSINESS METHODS 189 

in Alice.11 Patent trolls are non-practicing entities that do not 

invent new technologies or make any products.12 Their primary 

business model is to buy the patent rights of others and make 

money by asserting patent claims against alleged infringing 

practicing entities.13 Some patent troll business models are 

indifferent to, and may even thrive off of, weak patents that the 

USPTO would likely invalidate upon review.14 Thus, patent trolls 

commonly thrive off of costly patents that provide no benefit to 

society.15  

Many patent system stakeholders see the Alice decision as a 

victory over patent trolls because it provides a check on patents of 

poor quality that threaten to preempt downstream innovation.16 

However, Alice’s two-step standard—originating in the biotech 

arena with Mayo v. Prometheus Labs and made applicable to the 

realm of business method and software patents by Alice—is far 

from a model of clarity.17 The standard is malleable and 

unpredictable. Patent drafters are often left guessing what a patent 

examiner, a Patent Trial and Appeal Board (PTAB) judge, or the 

courts will consider to be an “abstract idea” and when the claims 

may be deemed patent-eligible for adding “significantly more.”18 

The law in this area is constantly evolving. The USPTO 

publishes updated guidelines based on case law applying the 

Alice/Mayo standard, in an attempt to add clarity and consistency 

to its examination procedures.19 How the law develops and how it 

 

 11. Julie Samuels & Daniel Nazer, EFF Urges Supreme Court to Crack Down on 
Patent Trolls, ELEC. FRONTIER FOUND. (Mar. 3, 2014), 
https://www.eff.org/press/releases/eff-urges-supreme-court-crack-down-patent-trolls 
[https://perma.cc/K7GK-HP3A]. 
 12. Jim Kerstetter & Josh Lowensohn, Inside Intellectual Ventures, the Most Hated 
Company in Tech, CNET: TECH INDUSTRY (Aug. 21, 2012, 6:57 AM PDT), 
https://www.cnet.com/news/inside-intellectual-ventures-the-most-hated-company-in-
tech/ [https://perma.cc/9GG2-P4W2]. 
 13. Mark A. Lemley & A. Douglass Melamed, Missing the Forest for the Trolls, 113 

COLUM. L. REV. 2117, 2118–2128 (2013). 
 14. See id. at 2126 (comparing the business models of “bottom-feeder” trolls, “patent 
aggregators,” and “lottery-ticket” trolls). 
 15. Id. at 2124. 
 16. See Alice Decision Saves Crowdfunding From Patent Troll, ELEC. FRONTIER 

FOUND., https://www.eff.org/alice/alice-decision-saves-crowdfunding-patent-troll 
[https://perma.cc/YD4H-5UV2] (last visited Jan. 10, 2019). 
 17. See USPTO, 2014 INTERIM ELIGIBILITY GUIDANCE QUICK REFERENCE SHEET 
(2014), https://www.uspto.gov/sites/default/files/documents/2014_eligibility_qrs.pdf 
[https://perma.cc/ZU86-UUQT]; Mayo Collaborative Servs. v. Prometheus Labs., Inc., 566 
U.S. 66 (2012); Manny Schecter, Congress Needs to Act So Alice Doesn’t Live Here (in the 
Patent System) Anymore, IPWATCHDOG (Feb. 13, 2017), 
https://www.ipwatchdog.com/2017/02/13/congress-needs-to-act-so-alice-doesnt-live-
here-in-the-patent-system-anymore/id=78241/ [https://perma.cc/XM79-BGDY]. 
 18. Schecter, supra note 17. 
 19. USPTO, Subject Matter Eligibility, https://www.uspto.gov/patent/laws-and-
regulations/examination-policy/subject-matter-eligibility [https://perma.cc/HS7B-A58E] 
(last visited Feb. 23, 2019); see also Kevin A. Rieffel, Revised MPEP May Provide New 

 



6 PRANGE 03.10.20 (DO NOT DELETE) 4/8/2020  12:39 AM 

190 COLO. TECH. L.J. Vol. 18.1 

is applied moving forward will have long-term effects on the 

progress of new technologies near the intersection of computing 

technology and business methods.20 At one extreme, if the USPTO 

grants business method patents that are highly abstract, patent 

trolls could emerge victorious and stunt technological growth by 

creating an ever-expanding thicket of useless patents.21  

At the other extreme, if the USPTO categorically rejects all 

patent applications with anything resembling a business method 

without considering their merits, innovators may be more likely to 

keep their innovations secret. This extreme could slow 

technological progress because competitors would not be 

incentivized to find alternative approaches to the same problem by 

designing around the boundaries of existing patents.22 

“Blockchain”—the technology behind cryptocurrencies like 

Bitcoin and Ethereum—is nascent and in need of innovation before 

it can be a realistic, sustainable solution for a wide variety of main-

stream applications.23 Many blockchain innovations will involve 

patent claims near the intersection of computing technology and 

business methods because the technology incorporates software for 

the automation of business transactions.24 In 2008, blockchain was 

introduced, under the pseudonym Satoshi Nakamoto, as the 

technology behind Bitcoin, one of the world’s most valuable 

cryptocurrencies.25 Blockchain was developed to solve the problem 

 

Tools in Alice Rejections, IPWATCHDOG (Feb. 4, 2018), 
http://www.ipwatchdog.com/2018/02/04/revised-mpep-tools-alice-rejections/id=93305/ 
[https://perma.cc/28KG-TPVQ]. 
 20. See Mark Nowotarski, If You Want to Protect Your Business Method, Reframe It 
as a Technical Invention, IPWATCHDOG (Sept. 3, 2019), 
https://www.ipwatchdog.com/2019/09/03/want-protect-business-method-reframe-
technical-invention/id=112875/ [https://perma.cc/Y887-APKS]. 
 21. Dolly Krishnaswamy, Hacking Through Patent Thickets, IPWATCHDOG (Sept. 
29, 2013), https://www.ipwatchdog.com/2013/09/29/hacking-through-patent-
thickets/id=45429/ [https://perma.cc/6DBC-KATF]. 
 22. See Gene Quinn, The Theory of Patents and Why Strong Patents Benefit 
Consumers, IPWATCHDOG (Nov. 24, 2015), 
https://www.ipwatchdog.com/2015/11/24/theory-patents-strong-patents-benefit-
consumers/id=61341/ [https://perma.cc/Z7GM-LDND]. 
 23. Morgen E. Peck & Samuel K. Moore, The Blossoming of the Blockchain, IEEE 

SPECTRUM 28–25 (Oct. 2017), https://ieeexplore.ieee.org/document/8048835 
[https://perma.cc/8F84-HTYX]. 
 24. See Charles R. Macedo & Barry Brager, The Bitcoin Network, Blockchain 
Technology and Altcoin Futures, IPWATCHDOG (Sept. 12, 2017), 
https://www.ipwatchdog.com/2017/09/12/bitcoin-network-blockchain-technology-altcoin-
futures/id=87916/ [https://perma.cc/BWR4-XPZ8](explains the basics of bitcoin & 
blockchain tech). 
 25. Satoshi Nakamoto, Bitcoin’s Enigmatic Creator, THE ECONOMIST (Aug. 30, 
2018), https://www.economist.com/technology-quarterly/2018/09/01/satoshi-nakamoto-
bitcoins-enigmatic-creator [https://perma.cc/X9ZM-EC4B]; John Divine, The 10 Biggest 
Digital Currencies by Market Cap, U.S. NEWS & WORLD REPORT (Aug. 8, 2018), 
https://money.usnews.com/investing/cryptocurrency/slideshows/the-10-most-valuable-
cryptocurrencies-in-the-world?slide=11 [https://perma.cc/5A57-2YR8]. 

 



6 PRANGE 03.10.20 (DO NOT DELETE) 4/8/2020  12:39 AM 

2020 BLOCKCHAIN & BUSINESS METHODS 191 

of double-spending in providing a “purely peer-to-peer version of 

electronic cash.”26 In other words, blockchain provides a way to 

make secure electronic payments directly between transacting 

parties, in a way that is closer to paying with physical currency 

than paying with a credit card.27 Because blockchain is likely to 

provide fertile ground for an influx of business method patent 

applications at the USPTO, patent trolls will likely attempt to cash 

in on the blockchain patent race.28  

Nonetheless, in order to provide sustainable, mainstream 

business solutions, blockchain technology will require significant 

innovation. Thus, inventors are likely to come forth with patent 

applications disclosing valuable improvements to further 

blockchain innovation.29 This Note will argue that business method 

patents, appropriately constrained by the requirements of Alice and 

its progeny, are well-positioned to help blockchain technology ripen 

into a sustainable, mainstream solution by promoting disclosure 

over secrecy. 

This Note proceeds in four parts. Part I presents a history of 

business method patents. Some patent system stakeholders have 

argued that—like the already existing exceptions to patent 

eligibility for laws of nature, natural phenomena, and abstract 

ideas—there should be an explicit exception for business methods. 

This Note will counter such arguments by examining how the 

requirements of Alice have ushered in a new era of business method 

patents that will be more beneficial than harmful to society. And 

that this new era will differ from business method patents in prior 

eras. Throughout history, the Supreme Court and the Federal 

Circuit have affected changes in the relative ease of obtaining 

business method patents.  

Before Alice, the USPTO granted many business method 

patents for business ideas that yielded a useful result, but without 

 

 26. Satoshi Nakamoto, Bitcoin: A Peer-to-Peer Electronic Cash System, 
https://bitcoin.org/bitcoin.pdf [https://perma.cc/BK28-Z42T] (last visited Jan. 11, 2019). 
 27. Dan Blystone, Bitcoin Transactions Versus Credit Card Transactions: What’s the 
Difference?, INVESTOPEDIA, https://www.investopedia.com/articles/forex/042215/bitcoin-
transactions-vs-credit-card-transactions.asp [https://perma.cc/6TH2-K7D2] (last 
updated July 17, 2019). 
 28. Chris Skinner, BankThink Blockchain is Fintech’s Real Game-Changer, 
AMERICAN BANKER (Mar. 21, 2016, 9:30 AM), 
https://www.americanbanker.com/opinion/blockchain-is-fintechs-real-game-changer 
[https://perma.cc/87PA-WXGP]; see Malathi Nayak, Blockchain Patent Race Is On, But 
Hurdles Await, BLOOMBERG LAW (May 30, 2018), https://biglawbusiness.com/blockchain-
patent-race-is-on-but-hurdles-await/ [https://perma.cc/BUL4-VVDS]; Stephen O’Neal, Is 
Blockchain About to Become a Patent War Battleground?, COINTELEGRAPH (July 25, 
2018), https://cointelegraph.com/news/is-blockchain-about-to-become-a-patent-war-
battleground [https://perma.cc/36AJ-SRDE]. 
 29. See Peter Fairley, Feeding the Blockchain Beast, IEEE SPECTRUM 36, 37, 58–59 
(Oct. 2017) (explaining the problem of blockchain power consumption and the limited 
ability of hardware efficiency improvements to help). 



6 PRANGE 03.10.20 (DO NOT DELETE) 4/8/2020  12:39 AM 

192 COLO. TECH. L.J. Vol. 18.1 

any corresponding technological improvement—i.e., “pure” 

business method patents. After Alice, the courts have established 

that business methods must provide technological improvements, 

or else they will be rejected under the abstract-idea exception to 

patent eligibility. Nevertheless, business methods are still eligible 

for patenting and blockchain innovators should not overlook the 

value of patenting business methods that further the progress of 

blockchain technology. 

Part II presents a taxonomy developed by Professor Harry 

Surden for evaluating whether a particular technological arena 

afforded patent protection may be more problematic than 

justifiable. Professor Surden’s five justifications provide a useful 

framework for analyzing and articulating when policy change may 

be necessary to keep problematic patents in check. Professor 

Surden has applied the taxonomy to both pharmaceutical patents 

and business method patents to argue that business method 

patents, unlike pharmaceutical patents, are highly problematic. 

Further, this Note examines Judge Mayer’s dissent from In re 

Bilski, which argues the extreme position that business method 

patents should be excluded categorically from patent eligibility.30 

Arguments such as these are primarily attacks on “pure” business 

method patents in the abstract and are detached from an 

examination of specific business methods that purport to solve a 

technological problem. To counter these arguments, this Note will 

examine a new technology—blockchain—with tremendous 

potential, but serious shortcomings. This Note will explore how 

business methods may be useful, if not crucial, for furthering 

blockchain innovation. 

Part III explains the concepts behind how blockchain 

technology works to highlight both its tremendous potential and 

some of its major limitations, and to show how business methods 

may provide technological improvements. “Blockchain” has become 

a buzz word of epic proportions. In the Fall of 2018, IBM began 

advertising “IBM Blockchain, a smart way to track every step” to 

ensure your coffee beans “did indeed come from 6,000 feet above sea 

level and not a foot lower.”31 The world’s two most popular countries 

for blockchain-related patent applications—China and the United 

States—have seen dramatic increases in new filings each year since 

2014. Patent applications in the United States with the word 

“blockchain” in the title, abstract, or claims increased from one new 

 

 30. See In re Bilski, 545 F.3d 943, 998 (Fed. Cir. 2008). 
 31. IBM Blockchain TV Commercial, ‘Smart Supply Chain’, ISPOT.TV, 
https://www.ispot.tv/ad/doiE/ibm-blockchain-smart-supply-chain 
[https://perma.cc/Y93H-WTXS] (last visited Mar. 23, 2019). 

 



6 PRANGE 03.10.20 (DO NOT DELETE) 4/8/2020  12:39 AM 

2020 BLOCKCHAIN & BUSINESS METHODS 193 

application in 2014 to about 383 new applications in 2017.32 Similar 

blockchain patent applications in China increased even more 

dramatically from 21 new applications in 2014 to about 1,291 new 

applications in 2017.33 There are exciting applications for 

blockchain technology, beyond cryptocurrency, with the potential to 

greatly benefit the public welfare. This Note discusses three such 

applications—product tracking/traceability, peer-to-peer energy 

trading, and medical record coordination—to illustrate the real-

world benefits that may be enabled for mainstream use after 

further improvements to blockchain technology. 

Part IV applies the five justifications of Professor Surden’s 

taxonomy to the prospect of blockchain-related business method 

patents to analyze how the availability of such patents may prove 

to be more justifiable than problematic. 

I. HISTORY OF BUSINESS METHOD PATENTS—AS THE 

PENDULUM SWINGS 

While “patent law is technology-neutral in theory, it is 

technology-specific in application.”34 During the twentieth and 

twenty-first centuries, the Supreme Court and the Federal Circuit 

applied patent statutes to business methods in a different way than 

they applied the laws to other areas of invention.35 This was meant 

to calibrate the patent system to serve policy goals.36 The following 

history provides a look back at key cases from three eras of business 

method patents that have swung the patent-law pendulum on 

business method patent eligibility. 

During the first era, courts made it extremely difficult to obtain 

business method patents. Many perceived this to be an implied 

business method exception to patent eligibility.37 During the second 

era, the courts made it easy to obtain business method patents, 

 

 32. Search International and National Patent Collections, WIPO, 
https://patentscope.wipo.int/search/en/result.jsf [https://perma.cc/7MHD-SJW6] (last 
visited Mar. 24, 2019) (based on an advanced search for “(AB:blockchain or TI:blockchain 
or CL:blockchain) and AD:[01.01.2014 TO 31.12.2014]”). 
 33. Search International and National Patent Collections, WIPO, 
https://patentscope.wipo.int/search/en/result.jsf [ttps://perma.cc/A65W-83HG] (last 
visited Mar. 24, 2019) (based on an advanced search for “(AB:区块链 or TI:区块链 or CL:
区块链) and AD:[01.01.2014 TO 31.12.2014]”). The Chinese translation for “blockchain” 
is 区块链 (qū kuài liàn). 
 34. Dan L. Burk & Mark A. Lemley, Policy Levers in Patent Law, 89 VA. L. REV. 
1575, 1577 (2003). 
 35. See id. at 1618. 
 36. See id. 
 37. Id. 

 



6 PRANGE 03.10.20 (DO NOT DELETE) 4/8/2020  12:39 AM 

194 COLO. TECH. L.J. Vol. 18.1 

which led to the patent troll problem.38 Finally, in the current era, 

which this Note refers to as the Alice era, the courts have once again 

made it more difficult, but not impossible, to obtain a business 

method patent.39 The Court has made it clear that business 

methods are still patent-eligible, so long as the invention purports 

to make a technological improvement.40 

A. Hotel Security Checking: Advice Is Not Patentable 

Hotel Security Checking provides the background for the first 

era of business method patents, when many perceived an implied 

exception to patent eligibility for business methods.41 In 1893, the 

Hotel Security Checking Company successfully patented their 

business methods for preventing fraud and embezzlement from a 

restaurant’s wait staff.42 However, in 1908, the Second Circuit held 

that the patent claims were invalid.43 The court reasoned, in part, 

that the patent claimed a mere “system of transacting business 

disconnected from the means for carrying out the system.”44 

The claims involved a type of ledger verification system where 

each waiter used slips of paper, marked with the waiter’s 

identification number, to record each order.45 Each department—

e.g., kitchen, bar, or cigar stand—would be given a large sheet with 

columns for keeping track of each waiter’s orders.46 “At the close of 

business the sum of the slips of waiter No. 6[, for example,] in the 

hands of the cashier, . . . [could] easily be compared with the sum of 

the items charged to him by the departments collectively” to reveal 

any fraud or carelessness “and discover where the fault lies.”47 

The court reasoned that the claims were directed to a 

fundamental principle of bookkeeping and merely applied it to the 

hotel and restaurant context using an obvious means of 

implementation.48 The court explained that the claims were 

directed to business advice adding nothing of substance to the art 

 

 38. Neel Chatterjee, Patent ‘Gold Rush’to Blame for Patent Sharks, Patent Trolls, 
IP WATCHDOG (Aug. 13,2017), https://www.ipwatchdog.com/2017/08/13/patent-gold-
rush-patent-sharks-patent-trolls/id=86649/ [https://perma.cc/QZD3-ETXN]. 
 39. Chisum, supra note 1. 
 40. See id. 
 41. See State St. Bank & Tr. Co. v. Signature Fin. Grp., 149 F.3d 1368, 1375-77 
(Fed. Cir. 1998). 
 42. See Hotel Sec. Checking Co. v. Lorraine Co., 160 F. 467, 467 (2d Cir. 1908). 
 43. Id. at 472. 
 44. Id. at 469. 
 45. Id. at 467–68. 
 46. Id. 
 47. Id. at 468. 
 48. Id. at 469–70. 

 



6 PRANGE 03.10.20 (DO NOT DELETE) 4/8/2020  12:39 AM 

2020 BLOCKCHAIN & BUSINESS METHODS 195 

of bookkeeping, deeming the claimed invention to be a “mere 

abstraction” and declaring that “[a]dvice is not patentable.”49 

B. State Street: A Useful, Concrete, and Tangible Result 

State Street ushered in a second era of business method patents 

during which the USPTO granted many patents for “pure” business 

methods—i.e., business methods without a purported technological 

improvement. In 1998, the Federal Circuit held that Signature 

Financial Group’s patent claims—which were directed to a business 

method involving a “Hub and Spoke financial services 

configuration”—should not have been invalidated on summary 

judgment under 35 U.S.C. § 101 as patent-ineligible subject matter 

by the District of Massachusetts.50 The court reasoned that the 

claims were not merely directed to an abstract idea because they 

incorporated a computer for making mathematical calculations, 

which transformed data and produced a “‘useful, concrete, and 

tangible result.’”51 

The Federal Circuit criticized the District of Massachusetts’ 

reliance on a supposed business-method exception to patent 

eligibility to erroneously invalidate the “Hub-and-Spoke” patent 

claims.52 The court explained that, at least since the 1952 Patent 

Act, business method claims have been subject to the same 

patentability requirements as any other type of method claim.53 

As a result of State Street, the USPTO granted many 

problematic business method and software patents, which ended up 

providing fuel for patent trolls.54 

C. Efforts to Curb Patent Trolling? 

1. Bilski: The Machine or Transformation Test Is Not the 

Only Test 

The Federal Circuit’s 2008 In re Bilski decision and the 

Supreme Court’s 2010 Bilski v. Kappos decision turned the tide for 

business method patents, once again making them more difficult to 

obtain.55 

 

 49. See id. 
 50. State St. Bank & Tr. Co. v. Signature Fin. Grp., Inc, 149 F.3d 1368, 1370 (Fed. 
Cir. 1998), abrogated by In re Bilski, 545 F.3d 943 (Fed. Cir. 2008). 
 51. Id. at 1373. 
 52. Id. at 1375. 
 53. Id. 
 54. See Christopher W. Quinn, The 20 Year War On Patents: When Will It End?, 
QUINN IP LAW (Feb. 21, 2017), https://www.quinniplaw.com/20-year-war-on-patents/ 
[https://perma.cc/VXT9-5JN7]. 
 55. See In re Bilski, 545 F.3d 943 ";"""date"",""2020-04-08T06:39:16Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.7""
""xmp:CreatorTool"",""MicrosoftÂŽ Word for Office 365""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dc:creator"",""Vincent A Dimichele""
""language"",""en""
""dcterms:created"",""2020-04-08T06:39:16Z""
""Last-Modified"",""2020-04-08T06:39:16Z""
""dcterms:modified"",""2020-04-08T06:39:16Z""
""dc:format"",""application/pdf; version=1.7""
""xmpMM:DocumentID"",""uuid:028A359E-7B63-4AE9-87B2-F5A8E2A26065""
""Last-Save-Date"",""2020-04-08T06:39:16Z""
""pdf:docinfo:creator_tool"",""MicrosoftÂŽ Word for Office 365""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2020-04-08T06:39:16Z""
""meta:save-date"",""2020-04-08T06:39:16Z""
""pdf:encrypted"",""false""
""xmp:CreateDate"",""2020-04-08T00:39:16Z""
""modified"",""2020-04-08T06:39:16Z""
""Content-Length"",""457163""
""pdf:hasMarkedContent"",""true""
""Content-Type"",""application/pdf""
""xmp:ModifyDate"",""2020-04-08T00:39:16Z""
""pdf:docinfo:creator"",""Vincent A Dimichele""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Vincent A Dimichele""
""dc:language"",""en-US""
""meta:author"",""Vincent A Dimichele""
""pdf:producer"",""MicrosoftÂŽ Word for Office 365""
""meta:creation-date"",""2020-04-08T06:39:16Z""
""created"",""2020-04-08T06:39:16Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""42""
""Creation-Date"",""2020-04-08T06:39:16Z""
""resourceName"",""6-Prange-03.10.20.pdf""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""2664"",""2966"",""2889"",""2763"",""3375"",""3366"",""3266"",""2784"",""2602"",""2540"",""2336"",""2719"",""2729"",""2471"",""2239"",""2640"",""3355"",""2437"",""2251"",""2374"",""2887"",""3063"",""2698"",""2845"",""2332"",""2665"",""2830"",""2866"",""2868"",""2788"",""2735"",""3164"",""2868"",""2508"",""2740"",""2159"",""2676"",""2457"",""2329"",""2536"",""621"",""91""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""Author"",""Vincent A Dimichele""
""producer"",""MicrosoftÂŽ Word for Office 365""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""MicrosoftÂŽ Word for Office 365""
""pdf:docinfo:created"",""2020-04-08T06:39:16Z""
";https://scholar.google.com/scholar?start=320&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095386-1634;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;A Blockchain-Assisted Framework for Secure and Reliable Data Sharing in Distributed Systems;Y Guo, S Wang, J Huang ;2020 researchsquare.com;;"Page 1. Guo et al. RESEARCH A Blockchain-assisted Framework for Secure and Reliable

Data Sharing in Distributed Systems … In this paper, we propose a blockchain-assisted

framework that can support trust- worthy data sharing services …";Autres articles;;[PDF] researchsquare.com;https://www.researchsquare.com/article/rs-135690/latest.pdf;;;https://scholar.google.com/scholar?start=440&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095349-1474;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Digital Copyright Depository System Enhanced by Blockchain;W Yang, P He, Z Yang, X Yi… ; … Conference on Culture …, 2020  ieeexplore.ieee.org;;"… Digital work secure sharing and reliable trading are implemented with the help of

blockchain peer to peer network. Credible infringement evidence collection is realized

through the Oracle technology and trusted computation …";Autres articles;;null;;;;https://scholar.google.com/scholar?start=280&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095346-1468;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;HyBloSE: hybrid blockchain for secure-by-design smart environments;G Maselli, M Piva, F Restuccia ; Proceedings of the 3rd Workshop on …, 2020  dl.acm.org;;"… Secure Oracle. Low power nodes can not run a Blockchain node. In order to interact

with the moving blockchain Blockchain-Enable actuators act as gateways for low power

nodes … 2018. Astraea: A decentralized blockchain oracle …";Autres articles;;null;;;;https://scholar.google.com/scholar?start=270&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095323-1365;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Blockchain-based solution for COVID-19 digital medical passports and immunity certificates;HR Hasan, K Salah, R Jayaraman, J Arshad… ; IEEE …, 2020  ieeexplore.ieee.org;;"… 222097 Page 6. HR Hasan et al.: Blockchain-Based Solution for COVID-19 DMP and Immunity

Certificates … Furthermore, this also allows our solution to be distributed with the availability of

multiple trusted oracles. First, the data owner encrypts the content using a symmetric key …";Cité 9 fois;Les 6 versions;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/6287639/8948470/09286584.pdf;"
		
	";"""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""dc:title"",""IEEE Xplore Full-Text PDF:""
""Content-Encoding"",""UTF-8""
""resourceName"",""09286584.pdf""
""language"",""es""
""Content-Length"",""2565""
""title"",""IEEE Xplore Full-Text PDF:""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=170&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095297-1254;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;A note on the instantiability of the quantum random oracle;E Eaton, F Song ; International Conference on PostQuantum …, 2020  Springer;;"… Think of two correlated random oracles \(\mathcal {O}:\{0,1\}^* \rightarrow \{0,1\}^{\ell … non-interactive

zero-knowledge arguments that rise with the trending technology of blockchain and

cryptocurrencies … the fact that one can often prove security in the random oracle model which …";Cité 2 fois;Les 3 versions;[PDF] nsf.gov;https://par.nsf.gov/servlets/purl/10164364;"
A Note on the Instantiability of the Quantum
Random Oracle

Edward Eaton1 and Fang Song2

1 Cheriton School of Computer Science, University of Waterloo,
eeaton@uwaterloo.ca

2 Department of Computer Science and Engineering, Texas A&M University,
fang.song@tamu.edu

Abstract. In a highly influential paper from fifteen years ago [10],
Canetti, Goldreich, and Halevi showed a fundamental separation between
the Random Oracle Model (ROM) and the standard model. They con-
structed a signature scheme which can be proven secure in the ROM, but
is insecure when instantiated with any hash function (and thus insecure
in the standard model). In 2011, Boneh et al. defined the notion of the
Quantum Random Oracle Model (QROM), where queries to the ran-
dom oracle may be made in quantum superposition. Because the QROM
generalizes the ROM, a proof of security in the QROM is stronger than
one in the ROM. This leaves open the possibility that security in the
QROM could imply security in the standard model. In this work, we
show that this is not the case, and that security in the QROM cannot
imply standard-model security. We do this by showing that the original
schemes that show a separation between the standard model and the
ROM are also secure in the QROM. We consider two schemes that es-
tablish such a separation, one with length-restricted messages, and one
without, and show both to be secure in the QROM. Our results give
further understanding to the landscape of proofs in the ROM versus the
QROM or standard model, and point towards the QROM and ROM be-
ing much closer to each other than either is to standard model security.

1 Introduction

In this note, we show that there exist digital signature schemes that can be
proven secure against any poly-time quantum adversaries in the quantum random-
oracle model [7], but they can be broken by a classical poly-time adversary when
the random oracle is instantiated by any poly-time computable hash function
family. This extends to the quantum setting the impossibility of instantiating a
classical random oracle [3, 9, 10,18,26,28].

Given the classical result (e.g., [10]) that there exists a secure signature
scheme in the random oracle model but insecure under any efficient instanti-
ation, the first doubt to clear up is probably why it does not immediately follow
that a quantum random oracle cannot be instantiated as well. The reason is
that the signature scheme in the classical result may as well get broken in the



quantum random oracle model. In other words, all one needs to do is to prove
quantum security of these classical constructions in the quantum random oracle
model. This is exactly what this work does: we show that three examples in the
classical setting [9, 10, 26] can be proven secure in the quantum random oracle
model, and hence they demonstrate that the quantum random oracle model is
unsound in general.

We dive into an overview of the proofs right away, so that those who are
familiar with this subject can quickly digest the gist and walk away satisfied (or
disappointed). If you are a more patient reader, you can come back here after
enjoying the (more conventional) introduction.

Let us first review the classical examples [9, 10, 26] to be analyzed in the
quantum random oracle model, and we present them under a unified framework
which we hope will be easy to grasp. They all start with a secure signature
scheme Σ and a function F , and Σ is “punctured” so that the signing algorithm
would simply reveal the signing key when the function F is “non-random” (e.g.,
instantiated by a concrete hash function). To break it, an adversary just needs to
convince the signing algorithm that F is indeed non-random. Therefore, it boils
down to designing a proof system where a prover (adversary in the signature
setting) proves “non-randomness” of a given function to a verifier (signing algo-
rithm); whereas if the function is indeed random, no prover can fool the verifier
to accept. The natural approach to such a proof system is based off the intuition
that it is difficult to predict the output of a random oracle on an unknown input.
The three classical examples nurture this intuition in two variations: predicting
on a single input or multiple inputs.

1. The basic idea in [10] is to have the prover provide an input where the output
is predictable and can be efficiently verified by the verifier. For starters,
suppose we want to rule out a specific hash function H, then the prover
can pick an arbitrary x and the verifier just checks if F (x) = H(x). The
verifier always accepts when F is instantiated by H, but accepts only with
negligible probability if F is random. This immediately implies that for any
function family, in particular the family of poly-time computable functions
H = {HΝ = {Hs}s∈{0,1}Ν}3, we can construct a signature scheme following
the idea above, where a (random) member in H is chosen as implementation
of F , and the signing algorithm reveals the signing key whenever the “non-
randomness” verification passes. Note that, nonetheless, the construction
depends on the function family, which is weaker than the goal of establishing
a signature scheme that is secure in the random oracle model, but insecure
however when implement it from function family H.

Diagonalization comes in handy to reverse the quantifiers. The prover will
provide a description s of a function Hs, which purportedly describes the
function F . Then the verifier runs Hs on s and checks if it matches F (s).
Clearly, when F is implemented by a member Hs ∈ H, the description s

3 We assume a canonical encoding of functions into binary strings, under which s is
the description of a function. Complexity is measured under security parameter Îť.

2



is public (i.e., part of the verification key), and it is trivial for the prover
to convince the verifier. Nonetheless, if F is a random oracle O, the event
O(s) = Hs(s) occurs only with negligible probability for any s that a prover
might provide.
A technicality arises though due to the time complexity for computing Hs(s)
for all H. Loosely speaking, we need a universal machine for the family H
that on a description s computes Hs(¡). Such a machine exists, but would
require slightly super-polynomial time, which makes the verifier (i.e., sign-
ing algorithm) inefficient. This final piece of the puzzle is filled by CS-proofs
introduced by Micali [27]. A CS-proof allows verifying the computation of a
machine M , where the verifier spends significantly less time that the time
to run M directly. This naturally applies to the problem here. Instead of
running the universal machine to check Hs(s) = F (s) by the verifier, the
prover generates a CS-proof on the input 〈M, s〉F (relative to F ) certifying
the statement M(s) := Hs(s) = F (s), which the verifier can check in poly-
time. When F = O is a random oracle, 〈M, s〉O (relative to O) is almost
always a false statement, and the soundness of the CS-proof ensures that ver-
ifier will reject with high probability. Micali proved in general the soundness
of CS-proofs in the random oracle model (to avoid confusion, in CS-proofs
think of an random oracle independent of F ).

2. Another strategy for proving “non-randomness”, as employed in Maurer et
al. [26] and Canneti et al. [9], is to predict on multiple inputs. This offers a
direct information-theoretical analysis without relying on CS-proofs.
In essence, a prover provides a machine π that allegedly predicts the output
of F on sufficiently many inputs, and the verifier can run π and compare
with the answers from F . This is easy for the prover when F is instantiated
by F where the description s is given. On the other hand, by tuning the
parameters, a counting argument would show that the randomness in a ran-
dom oracle is overwhelming for any single machine (even inefficient ones!)
to predict. Specifically, the “predicting” machine π needs to match with F
on q = 2|π|+ λ inputs (i.e., the number of correct predictions has to be sig-
nificantly more than the length of the description of the machine). Suppose
that F is a random oracle O ← {f : {0, 1}∗ → {0, 1}} that outputs one
bit (for the sake of simplicity), then for any π the probability that it will
match O on q inputs is at most 2−(2|π|+λ). A union bound on all machines
of length n shows that pn, the probability that some length-n machine is
a good predictor, is at most 2n · 2−(2n+λ) = 2−n−k. Another union bound
shows that regardless of their length, no machine can be a good predictor,
since p :=

∑∞
n=1 pn = 2−λ

∑
n 2−n ≤ 2−λ−1 is negligible.

3. Both examples above suffer from an artifact. Namely the signature schemes
need to be able to sign long messages or otherwise maintain states of prior
signatures. This is rectified in [9], where a stateless scheme that signs only
messages of polylogarithmic length is proven secure in the random oracle
model but insecure under any instantiation.
At the core of this construction is an interactive counterpart of the non-
interactive proof system in part 2 above. It can be viewed as a memory

3



delegation protocol, where a verifier with limited (e.g., poly-logarithmic)
memory wants to check if the machine provided by the prover is a good pre-
dictor. Roughly speaking, it will execute the machine step by step and use
the prover to bookkeep intermediate configurations of the machine. However,
the configurations may be too long for the verifier to store and transit to the
prover. Instead, the verifier employs a Merkle tree and only communicates
an authentication path of the configuration with the prover. In particular,
the verifier will memorize only a secret authentication key in between sub-
sequent rounds. The security of the “punctured” signature scheme reduces
to essentially a stronger unforgeability of a valid authentication path in a
Merkle tree with respect to a random oracle, which is proven classically.

Proving security of separation examples in QRO. Once the constructions and
classical analysis are clearly laid out, proving their security in the quantum ran-
dom oracle model becomes more or less mechanic, given the techniques developed
for QRO so far [1, 2, 16,33,34].

1Q. (Example in [10] with CS-proofs.) Following the classical proof, we first show
that the quantum security reduces to one of three cases: 1) hardness of a
Grover-type search problem, which ensures that an adversary cannot feed the
CS-proof a true statement in the case of a random oracle; 2) security of the
original signature scheme; and 3) soundness of CS-proofs against quantum
adversaries. A precise query lower bound for the search problem follows by
standard techniques. And thanks to a recent work [11], CS-proofs are proven
sound against quantum adversaries.

2Q. (Example in [9, 26] based on information-theoretical analysis.) It is easy to
verify that the information-theoretical argument sketched above holds re-
gardless of the kind of adversaries, and as a result the “punctured” signature
scheme remains secure in the quantum random oracle model (and against
quantum adversaries).

3Q. (Example in [9] that only needs to sign short messages.) Our proof follows
the classical one, where we first carefully verify and lift the reduction to the
(stronger) unforgeability of Merkle tree against quantum adversaries, and
then prove this property in the quantum random oracle model.

Specifically, we can model the unforgeability game as follows. Think of two
correlated random oracles O : {0, 1}∗ → {0, 1}`(λ) and O′ := O(ak, ·) where
ak is a random authentication key kept secret. Given quantum access to
O and classical access to O′, the adversary needs to come up with an
authentication path (〈σ1, . . . , σd〉, 〈(v1,0, v1,1), . . . , (vd,0, vd,1)〉, t) where σi ∈
{0, 1}, t = O′(d,O(0, v1,0, v1,1)) and vi,σi = O(i, vi+1,0, vi+1,1) for every
i = 1, . . . , d − 1. We prove that this is infeasible by reductions from a ran-
domized decisional search problem and collision finding in random func-
tions [8, 21,35].

4



Background and motivation. The random oracle model, since its introduction [4],
has proven a popular methodology for designing cryptographic schemes4. Basi-
cally a construction is first described and analyzed in an idealized setting where
a random function is available as a black-box. To implement it in the real-
world, one substitutes a cryptographic hash function for the random oracle.
This methodology often leads to much more efficient schemes than alternatives.
Examples include digital signatures by the Fiat-Shamir transform [17], hybrid
public-key encryption following Fujisaki-Okamoto-type transforms [5], as well
as succinct non-interactive zero-knowledge arguments that rise with the trend-
ing technology of blockchain and cryptocurrencies [31]. Its popularity is also
attributed to the fact that one can often prove security in the random oracle
model which is otherwise much more challenging or simply unknown.

It is, however, exactly the latter advantage that stirred considerable debate.
What does a security proof in the random oracle model mean? To be pragmatic,
a random-oracle proof at least serves as a sanity check that rules out inherent
design flaws. Indeed, in practice most constructions that are instantiated from
ones proven secure in the random oracle model have stood up extensive crypt-
analysis. More formal pursuit, however, arrives at an irritating message. There
are separation examples which show secure constructions in the random oracle
model, but will be trivially broken whatever “nice” functions we use to instan-
tiate the random oracle. Namely, the methodology is unsound in general. This
does not mean all schemes following this approach are insecure. In fact, some
random-oracle scheme can be instantiated under strong but reasonable assump-
tions and achieve desirable security in the real-world [24]. To say the least, a
question mark lingers on schemes developed under this methodology.

Quantum computing adds another layer of complication to the issue here
(and the overall landscape of cryptography). Because of the threats to widely
deployed cryptosystems [32], a growing effort is undertaken to design and tran-
sition to so called post-quantum cryptography – a new set of cryptosystems that
hopefully resist quantum attacks. In particular, the random oracle model has
been re-examined in the presence of quantum adversaries. Since eventually a
scheme (designed in RO) will be realized via a cryptographic function, whose
specification is known in public, a quantum adversary can in principle construct
a coherent quantum circuit that evaluates the hash function in quantum su-
perposition. Consequently, when analyzing the scheme in the idealized setting,
it seems necessary to grant quantum superposition queries to the random or-
acle by a quantum adversary. This brings about the quantum random oracle
model [7]. The rationale is, very informally, good cryptographic functions are
lacking structures for a quantum computer to exploit (aside from generic speedup
due to quantum search), and hence realizing a scheme proven secure relative to
a quantum random oracle this way is a fine practice.

Formally analyzing security in the quantum random oracle model turns out
to be challenging. Many classical proof techniques, such as simulating and pro-

4 According to Google Scholar, [4] has a citation count at 5089 (November 2019), which
would be ranked top 20 at a (dated) list of most cited computer science papers [12].

5



gramming a random oracle on-the-fly or recording the queries, seem to fail due
to unique features of quantum information. Thanks to a lot of continued effort,
in recent years, researchers managed to develop various techniques for reasoning
about the quantum random oracle model, and restored the security of many
important constructions against quantum adversaries [2, 13, 14, 16, 20–22, 30, 33,
35, 36]. In fact, quantum random oracle model is becoming a booming research
topic. To get an idea, as of writing, there are 166 citations in total of [7] and
about 90 since 2018, of which about 60 came out since 2019. Also out of the 9
signature scheme submissions that made the second round of the post-quantum
cryptography standardization at NIST [29], 5 of them involve the quantum ran-
dom oracle. This just adds more at stake regarding “what does it mean that a
scheme is proven secure in the quantum random oracle model?”

How to interpret this result? Our work show that in general, security in the
quantum random oracle model could be vacuous in a real-world implementa-
tion. What is the real implication though? There seems a dilemma, probably
more puzzling than the classical situation. On the one hand, since a quantum
adversary is given more power (e.g., quantum computation and superposition
access), security in the quantum random oracle provides more justification that
the construction is solid. And this indeed explains the difficulty in establishing
security in the quantum random oracle. Putting it in the converse way, it might
occur that the classical separation examples will be broken in this model that is
more “generous” to potentially more powerful quantum adversaries. Our work
nonetheless shows otherwise, and it in fact reveals the other side of the dilemma.
Any bit of success in restoring proof techniques in the quantum random oracle
model just casts another bit of shadow on this methodology, since the seeming
stronger quantum security does not promise the security of real-world imple-
mentations, not even their security against classical adversaries only.

On the other hand, researchers have pointed out that the security of well-
designed schemes proven to be secure in the random oracle model have fared well
in retrospect [25]. The use of the random oracle model to get a proof can allow
for schemes that are simpler and more efficient than those in the standard model.
While proofs in the quantum random oracle model are naturally more difficult,
every year new techniques, more general and user-friendly, are developed to
establish quantum random oracle model security [14, 19, 21, 36]. This has lead
researchers to question what guarantees security in the quantum random oracle
provides versus the classical random oracle model. In this line, our results can
be taken as further justification that the difference between these models does
not appear to be a large one, as their relation to the standard model is the same.

2 Background

2.1 The (Quantum Random) Oracle Model

The random oracle model, originally devised in [4], replaces any a cryptographic
hash function with an entirely random oracle. The reduction algorithm is often

6



allowed to manage this oracle, and can perform operations like looking up the
queries that the adversary makes to it, or programming the oracle on inputs of
interest. Using the random oracle model can often greatly simplify a proof or
even enable a proof where otherwise not known or possible.

The intuitive idea behind the soundness of the random oracle methodology
is that an adversary interacting with a scheme is unlikely to take advantage of
the structure of the hash function. For most cryptographic schemes, even the
adversary is likely to treat the hash function as a ‘black box’, and so by treating
it as such, we can derive proofs for schemes that otherwise may not exist.

However, as pointed out in an influential paper by Boneh et al. [7], the ran-
dom oracle model makes a fundamentally classical assumption about how an
adversary interacts with the hash function (or random oracle). If we are con-
cerned about an adversary who has access to a quantum computer, than we can
assume that such an adversary is capable of instantiating the hash function on a
quantum computer and making queries to it in superposition. Such behaviour is
excluded by the random oracle model, and so when considering a quantum ad-
versary, a more cautious approach for proofs is to consider the quantum random
oracle model.

In the quantum random oracle model, the reduction algorithm still manages
the oracle, but now the adversary must be allowed to make a superposition
query to this oracle. For an oracle O : D → R, the reduction provides access to
a unitary UO which performs the action

UO :
∑

x∈D,y∈R
αx,y|x〉|y〉 7→

∑
x∈D,y∈R

αx,y|x〉|y ⊕O(x)〉,

where the input must be a valid quantum state, i.e., the sum of the square
amplitudes of the αx,y’s must be 1.

2.2 Notation

For clarity, we will denote a random oracle as O, while actual instantiations of
random oracles (e.g., typically hash functions) are denoted H. When describing
a scheme where a function may replaced with a random oracle in the proof, or
with a hash function in the real world, we will denote this function with F . The
security parameter of a scheme is denoted by Îť, while the output length of a
hash function is denoted n. While we separate these two values for generality
and expressiveness, throughout this work it is the case that Îť = n.

2.3 Computationally Sound Proofs

Computationally sound proofs [27] are a construction introduced by Micali in
2000. They are a proof system, allowing a prover to prove knowledge of a witness
for a language L in poly-logarithmic time. In our context, CS-proofs are useful
for showing the validity of a computation without having to run the computa-
tion. Imagine a description of an arbitrary function f , which may take super-
polynomial time to run on an input x, but will result in f(x) = y. A CS-proof

7



system allows us to generate a proof π that f(x) = y. Even though f may
take a super-polynomial amount of time to run, the CS-Proof verification sys-
tem allows a verifier, on input of f , x, y, and π to verify that f(x) = y in only
poly-logarithmic time.

The soundness of CS-proofs was originally shown in the random oracle model.
Until recently, the soundness of the construction in the quantum random oracle
model was an open question. In a breakthrough result by Chiesa et al. [11], the
soundness of CS-proofs in the quantum random oracle model was shown. The au-
thors did this by showing some innovations that extend ideas from Zhandry [36].

For our purposes, a CS-proof system consists of two algorithms: CSProve and
CSVerify. Both algorithms implicitly take a security parameter Îť. CSProve also
takes in a function f and an input x, and returns a value y and a proof π. The
CSVerify function takes in a function f , an input x, an output y, and a proof π.
It returns either accept or reject, based on the validity of the proof. Crucially,
the CSVerify function runs in time poly-log in the security parameter Îť, and not
in relation to the time it takes f to run.

The correctness property states that for an honestly generated proof π, the
CSVerify function will always accept. The soundness property ensures that if
f(x) 6= y, then it is computationally infeasible to find a proof π that will cause
CSVerify(f, x, y, π) to return accept.

3 Instantiating Quantum Random Oracles

In this section we define three signature schemes, ÎŁ1, ÎŁ2, and ÎŁ3, such that:

– Σ1 is secure in the quantum random oracle model, but insecure if that ran-
dom oracle is instantiated with some specific hash function H.

– Σ2 is secure in the QROM, but insecure when the random oracle is instan-
tiated with any of a pre-defined set of hash functions {H1, . . . ,Hm}.

– Σ3 is secure in the QROM, but insecure if the random oracle is ever instan-
tiated with any polynomial-time function.

These signature schemes lift the results in [10] to the quantum random oracle
model. In all cases, the only assumption we require is that we have a signature
scheme ÎŁ0 = (KeyGen0,Sign0,Vrfy0) which is existentially unforgeable in the
quantum random oracle model. Examples of schemes proven secure in the quan-
tum random oracle model with no additional assumptions include the stateful
LMS signatures [15] and the stateless SPHINCS+ framework [6] (both hash-
based signatures). If one is willing to accept a computational assumption such
as ring-LWE, many other signature schemes, including several of those under
consideration in the NIST standardization process serve as examples [23].

3.1 Warm up — schemes Σ1 and Σ2

The first step in considering the instantiation of a random oracle is to consider
instantiation with a single hash function, H. Then we can define the scheme ÎŁ1

as follows. Clearly this scheme satisfies the correctness property, as ÎŁ0 does.

8



Signature scheme ÎŁ1

– KeyGen1(1λ): Generate (pk, sk)← KeyGen0(1λ), and return.
– Sign1(sk,msg):
• Compute σ0 = Sign0(sk,msg).
• Check to see if F (msg) = H(msg). If so, return σ1 = σ0||sk.
• Otherwise, return σ1 = σ0||0.

– Vrfy1(pk,msg, σ1):
• Parse σ1 as σ0||x.
• Run Vrfy0(pk,msg, σ0).

This scheme is eu-acma secure in the (quantum) random oracle model, where
F is replaced with an oracle O. This is intuitively because in this case, the
security reduces to that of ÎŁ0 unless an adversary is able to find a msg such
that O(msg) = H(msg) (which occurs for every possible input with uniform and
independent probability 1/2n).

Furthermore, this scheme is insecure if it is instantiated with H replacing
the random oracle. Then the adversary is able to trivially break security, as the
condition H(msg) = H(msg) is always satisfied and σ1 = σ0||sk will be returned
for any message.

The next step is considering a finite collection of m hash functions, say H =
{H1, H2 . . . , Hm}.

Then we can define ÎŁ2 similarly to ÎŁ1, but change the condition to first
check if msg ∈ {1, . . . ,m} (in some encoding of the integers 1 through m) and if
so, further check if F (msg) = Hmsg(msg).

The analysis in the (quantum) random oracle model is again fairly straight-
forward. For any random oracle O, the probability that O(i) matches Hi(i) for
any of i = 1 to m is at most m ¡ 1

2n . When m is small (e.g., polynomially sized
in Îť), this is small enough that it is likely to not be possible that an adver-
sary can make a query that provides them with sk. Even for a large m, each
i ∈ {1, . . . ,m} will have the property that O and Hi match with probability
1/2n, and so an adversary must perform an unstructured search to find such
an i. Hence an adversary’s ability to break Σ2 in the (quantum) random oracle
model reduces to their ability to break ÎŁ0.

However, as before, if F is actually replaced by any one of the Hi’s, an
adversary can easily break the scheme by querying i to the signing oracle.

3.2 Signature scheme ÎŁ3

Schemes ÎŁ1 and ÎŁ2 are only to gain an intuition for the full result, ÎŁ3, which is
a signature scheme that is secure in the quantum random oracle model, but in-
secure when the oracle is instantiated with any polynomial-time function as the
hash function. Following the strategy for ÎŁ2, we would like to fix some enumera-
tion of all algorithms that one may use as a hash function, sayH = {H1, H2, . . . },
with Hi : {0, 1}∗ → {0, 1}n. Then as before, we would modify an eu-acma secure

9



scheme ÎŁ0 to introduce a check in the signing algorithm to interpret msg as
a non-negative integer, and check if F (msg) = Hmsg(msg). However, there are
several issues that must be resolved to make this fully rigorous. Such a set of
functions cannot simply be defined and used in the signature scheme, as the
signature scheme requires that on input i, hash function Hi is actually run.

To fix this, we start with an enumeration of all algorithms,A = {A1, A2, A3, . . . }.
We make no assumptions about this enumeration except that we can efficiently
swap between the index i and some standard description ofAi. Changing between
Ai and i should not be seen as a computational task to carry out, but rather a
reinterpretation of the same data. Algorithms are encoded, using some standard
encoding depending on the computational model, into bit strings, which can
then easily be interpreted as an integer. To think of a construction that achieves
this, it is helpful to think of quantum circuits. If we are working with l registers,
then we can interpret the index i as a value in {0, 1}∗ which specifies which gates
are applied to which registers in what order. From a description of a quantum
circuit, it is easy to convert this into a binary string, and then an index, and
vice versa. To be reversible and match the format of a hash function, we can
then consider all circuits that perform the mapping |x〉|y〉 7→ |x〉|y ⊕Ai(x)〉.

Note that not all of these algorithms necessarily run in polynomial-time in the
security parameter. It is of course impossible to tell which algorithms will even
terminate. We would like to assume that when a random oracle is instantiated,
the function it is instantiated with will run in polynomial time in the security
parameter. As well, these algorithms do not necessarily have the correct output
length of n bits.

To fix this, we modify each algorithm in the following way: For each algo-
rithm, stop after taking nlogn steps, and pad or truncate the output (in an
arbitrary way) so that each algorithm always outputs n bits. The value nlogn

is chosen so it bounds all polynomial-time algorithms. We enumerate our modi-
fied algorithms H = {H1, H2, . . . }. Notice that any algorithm that is polynomial
time, and outputs n bit binary strings is unmodified. So, any function that would
be used as a hash function is not affected by this.

We can then make a first attempt at defining ÎŁ3. Given an eu-acma (in
the quantum random oracle model) signature scheme ÎŁ0 and an enumeration of
hash functions H as described above, we define ÎŁ3 as follows.

There is a very noticeable problem in this scheme. We bounded the run time
of the Hi’s by nlogn, in order to make sure that we could leave every polynomial-
time algorithm unaffected. However, any algorithm Ai that runs in ≥ nlogn

steps will be modified to run in nlogn steps. If a message msg is signed which
corresponds to such an algorithm, the signer will have to evaluate Hmsg(msg).
This means that the signing algorithm does not run in polynomial time in the
security parameter, and so it does not fit a valid definition of a signing algorithm.

To resolve this issue, CS-proofs are employed.

Rather than directly checking to see if F (msg) = Hmsg(msg), we can in-
stead accept a CS-proof π that F (msg) = Hmsg(msg). This scheme is still trivial

10



Signature Scheme ÎŁ3, first attempt

– KeyGen3: The key generation algorithm remains the same as in the original
scheme ÎŁ. Run KeyGen0(1Îť) and return (pk, sk).

– Sign3: On input of a message msg, and the secret key sk, do the following:
• Compute σ0 ← Sign0(sk,msg).
• Interpret msg as a non-negative integer. Compute Hmsg(msg).
• Check to see if F (msg) = Hmsg(msg).
• If so, return signature σ3 = σ0||sk. Otherwise, return σ3 = σ0||0lsk .

– Vrfy3: On input of a message msg, a signature σ3 and a public key pk, we parse
σ3 as σ0||x, where x is a (possibly all zero) string of length lsk. Then compute
and return Vrfy0(pk,msg, σ0).

to break when F is instantiated, but we are now guaranteed that the signing
algorithm always runs in polynomial time, no matter what is queried.

Signature Scheme ÎŁ3, correct with CS-proofs

– KeyGen3: The key generation algorithm remains the same as in the original
scheme ÎŁ0. Run KeyGen0(1Îť) and return (pk, sk).

– Sign3: On input of a message msg, and the secret key sk, do the following:
• Compute σ0 ← Sign0(sk,msg).
• Using some standard parsing rule, parse msg as i||π, an index i and a string
π.

• Run CSVerify to check if π is a CS-proof that Hi(i) = F (i).
• If so, return signature σ3 = σ0||sk. Otherwise, return σ3 = σ0||0lsk .

– Vrfy3: On input of a message msg, a signature σ3 and a public key pk, we parse
σ3 as σ0||x, where x is a (possibly trivial) string of length lsk. Then compute
and return Vrfy0(pk,msg, σ0).

This allows us to state the main theorem of our paper.

Theorem 1 (Security of Σ3). Let g : {0, 1}∗ → {0, 1} be a random function
such that for each x, Pr[g(x) = 1] = 1

2n and all outputs of the function are
independent.

Let Q be a quantum adversary capable of breaking the existential-unforgeability
of ÎŁ3 with probability p in the quantum random oracle model. Then there exists
a reduction algorithm R that, in slightly super-polynomial time, is capable of ei-
ther breaking ÎŁ0, breaking the computational soundness of the CS-proof system,
or finding an x ∈ {0, 1}∗ such that g(x) = 1.

3.3 Proof of The";"""date"",""2019-12-18T21:32:29Z""
""pdf:PDFVersion"",""1.7""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:docinfo:title"",""""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""pdfa:PDFVersion"",""A-2b""
""language"",""en""
""dc:format"",""application/pdf; version=""""A-2b"""""",""application/pdf; version=1.7""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""xmp:CreateDate"",""2019-12-18T16:32:29Z""
""modified"",""2019-12-18T21:32:29Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""xmp:ModifyDate"",""2019-12-18T16:32:29Z""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016) kpathsea version 6.2.2""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2019-12-18T21:32:29Z""
""created"",""2019-12-18T21:32:29Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-12-18T21:32:29Z""
""resourceName"",""10164364""
""pdfaid:part"",""2""
""Author"",""""
""producer"",""pdfTeX-1.40.17""
""pdf:docinfo:producer"",""pdfTeX-1.40.17""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""6"",""8"",""0"",""0"",""7"",""1"",""0"",""5"",""0"",""3"",""0"",""0"",""0"",""7"",""1"",""3"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2019-12-18T21:32:29Z""
""Last-Modified"",""2019-12-18T21:32:29Z""
""dcterms:modified"",""2019-12-18T21:32:29Z""
""title"",""""
""Last-Save-Date"",""2019-12-18T21:32:29Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2019-12-18T21:32:29Z""
""meta:save-date"",""2019-12-18T21:32:29Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016) kpathsea version 6.2.2""
""Content-Length"",""782284""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""pdfaid:conformance"",""B""
""pdf:producer"",""pdfTeX-1.40.17""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""20""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""2061"",""2680"",""2717"",""2434"",""2944"",""2648"",""2319"",""2415"",""2018"",""2722"",""1798"",""1642"",""2530"",""2087"",""2692"",""2412"",""2544"",""1966"",""2881"",""2730""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-12-18T21:32:29Z""
";https://scholar.google.com/scholar?start=60&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095316-1337;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Cloud based security on outsourcing using blockchain in E-health systems;T Benil, J Jasper ; Computer Networks, 2020  Elsevier;;"… blockchain. The block generated by the doctor for the patient is now broadcasted to the

hospital's private blockchain. On … JPBC library. Proposed method, EC-ACS method, Random

Oracle model, BCDH, Yes, MATLAB R-2018 b. 3. Preliminaries …";Cité 6 fois;Les 2 versions;null;;;;https://scholar.google.com/scholar?start=140&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095318-1348;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;[PDF][PDF] Blockchain and institutional complexity: an extended institutional approach;D Frolov ; Journal of Institutional Economics, 2020  researchgate.net;;"… 1. Introduction Blockchain is a public or private distributed ledger or decentralized database

technology to create a non-centralized (without the need for a central entity or intermediating

party) crypto-secured peer-to-peer electronic transactions …";Cité 8 fois;Les 8 versions;[PDF] researchgate.net;https://www.researchgate.net/profile/Daniil_Frolov4/publication/342214738_Blockchain_and_institutional_complexity_an_extended_institutional_approach/links/5f2bc45192851cd302dfc016/Blockchain-and-institutional-complexity-an-extended-institutional-approach.pdf;;;https://scholar.google.com/scholar?start=150&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095292-1234;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Decentralized cross-blockchain asset transfers;M Sigwart, P Frauenthaler, C Spanring… ; arXiv preprint arXiv …, 2020  arxiv.org;;"… different kinds of oracles exist, one approach that can be leveraged for transaction inclusion

verifications are voting-based oracles. In a voting-based oracle, the smart contract on the

destination blockchain that wants to verify the inclusion of some transaction tx in the source …";Cité 2 fois;Les 3 versions;[PDF] arxiv.org;https://arxiv.org/pdf/2004.10488;"
Decentralized Cross-Blockchain Asset Transfers
Marten Sigwart

Distributed Systems Group, TU Wien, Vienna, Austria

m.sigwart@dsg.tuwien.ac.at

Philipp Frauenthaler

Distributed Systems Group, TU Wien, Vienna, Austria

p.frauenthaler@dsg.tuwien.ac.at

Christof Spanring

Pantos GmbH, Vienna, Austria

contact@pantos.io

Stefan Schulte

Distributed Systems Group, TU Wien, Vienna, Austria

s.schulte@dsg.tuwien.ac.at

ABSTRACT
Today, solutions for cross-blockchain asset transfers are either tai-

lored for specific assets, require certain means of cross-blockchain

communication, or neglect finality guarantees that prevent assets

from getting lost in transit.

In this paper, we present a cross-blockchain asset transfer proto-

col that supports arbitrary assets, is adaptable to different means

of cross-blockchain communication, and adheres to requirements

such as finality. The ability to freely transfer assets between block-

chains may increase transaction throughput and provide developers

with more flexibility by allowing them to design digital assets that

leverage the capacities and capabilities of multiple blockchains.

KEYWORDS
Cross-blockchain asset transfers, cross-blockchain communication,

blockchain interoperability

1 INTRODUCTION
With its ability to store data and perform computations in a de-

centralized and immutable manner, blockchain technology shows

potential in a wide range of application areas such as finance [26],

business process management [31], supply chain management [34],

or healthcare [25].

To address the diverse requirements of these areas, a variety of in-

dependent and unconnected blockchains has been developed [32].

As it is unlikely that a single blockchain emerges that caters to

the needs of all these different areas [38], there is a strong need

for interoperability. Especially in scenarios where assets—digital

representations of value—are managed on-chain, the lack of in-

teroperability leads to a vendor lock-in as assets cannot leave the

blockchain platform on which they were issued.

This vendor lock-in exposes projects to significant risks such as

limited scalability [8], the risk that the underlying blockchain sinks

into insignificance [6], and the inability to take advantage of new

features offered by novel blockchains [32].

Of course, a centralized entity can be deployed to migrate assets

from one blockchain to another. However, if asset holders have

to rely completely on that entity, this contradicts the demand for

decentralization being the reason for the adoption of blockchain

technology in the first place.

By enabling decentralized cross-blockchain asset transfers, these

problems can be averted without having to trust a centralized en-

tity [32]. The ability to transfer assets to arbitrary blockchains at

will would remove the need to commit to a particular blockchain

at launch. Rather, assets could be migrated to new blockchains

offering novel functionality or better security at any time [32]. An-

other potential use case of cross-blockchain asset transfers arises

in the context of sidechains [4, 30]. The idea is that an asset can

be transferred to and subsequently processed on multiple “side”

blockchains, thus reducing the workload of the original blockchain.

One way to exchange assets between independent blockchains

is via atomic swaps [17]. However, atomic swaps do not constitute

true cross-blockchain asset transfers as no asset is transferred from

one blockchain to the other but rather ownership of different assets

changes in an atomic fashion without the different assets leaving

their respective blockchains. True cross-blockchain asset transfers,

on the contrary, achieve that an asset actually moves from one

blockchain to the other, enabling users to hold different denomina-

tions of the same asset type on multiple blockchains, and to shift

these denominations freely between the involved blockchains.

While schemes for true cross-blockchain asset transfers have

been proposed before, most of these solutions are designed with spe-

cific means of cross-blockchain communication in mind and thus

put strong interdependence constraints on the participating block-

chains. Further, most solutions neglect important requirements for

cross-blockchain asset transfers, such as finality guarantees, that

prevent assets from getting lost in transit.

Thus, in this paper, we first derive a set of general requirements

that need to be fulfilled by cross-blockchain asset transfers, and

then propose a protocol that (a) is compliant with the defined re-

quirements and (b) does not impose interdependence constraints on

the involved blockchains. The proposed protocol abstracts means

of cross-blockchain communication and can thus be adapted to fit

different blockchains and use cases.

The contributions of this paper can be summed up as follows.

• We formally define functional requirements for cross-block-

chain asset transfers.

• We define protocol specifications for enabling cross-block-

chain asset transfers that are decentralized, secure and not-

reliant on specific means of cross-blockchain communica-

tion.

• We evaluate the proposed protocols on public Ethereum

test networks using a proof-of-concept implementation for

EVM
1
-based blockchains.

To this end, Section 2 introduces notations and definitions that

are used in Section 3 to formally define the requirements and pro-

tocols for cross-blockchain asset transfers. Section 4 evaluates the

1
Ethereum Virtual Machine

ar
X

iv
:2

00
4.

10
48

8v
1 

 [
cs

.C
R

] 
 2

2 
A

pr
 2

02
0



proposed protocols with regard to cost, duration, security, and fea-

tures using a proof-of-concept implementation. Section 5 provides

an overview of related work. Finally, Section 6 concludes the paper.

2 BACKGROUND
This section introduces some notations and definitions necessary

for describing the requirements and specification of the proposed

cross-blockchain asset transfer protocol.

As has been mentioned in Section 1, cross-blockchain asset trans-

fers ideally enable users to hold different denominations of the same

asset on multiple blockchains at the same time, i.e., users are free to

choose on which blockchain they want to hold their assets. An asset

can be seen as anything holding some value with a corresponding

representation on a blockchain.

Assets can generally be divided into fungible and non-fungible

assets [29]. Fungibility implies that two entities of the same as-

set can be used interchangeably. Cryptocurrencies like Bitcoin or

Ether are fungible assets. A further example for fungible assets are

Ethereum tokens following the ERC20 standard. On the other hand,

non-fungible assets are uniquely identifiable, i.e., one entity cannot

be simply substituted by another entity. For instance, Cryptokitties

are non-fungible assets.

One can further distinguish between native and user-defined

assets [29]. Native assets are inherently part of a particular block-

chain. One cannot exist without the other, e.g., the Bitcoin and

Ether cryptocurrencies and the Bitcoin and Ethereum blockchains,

respectively. However, certain blockchains provide the capability to

define almost arbitrary programs, so-called smart contracts. These

smart contracts are often used to implement use-case specific assets

with their own set of rules, e.g., ERC20 tokens [9]. Contrary to

native assets, user-defined assets are not bound to specific block-

chains, they could potentially be deployed on any blockchain with

the according scripting capabilities to express the asset’s rules.

This work concentrates on user-defined assets since the goal is to

provide an asset that allows users to hold different amounts of the

same asset on multiple blockchains at the same time. We formally

define an asset A as a set where the set’s members represent the

asset’s smallest indivisible entities (asset entities). For instance, the

smallest indivisible entity of a fungible asset like Bitcoin is a Satoshi

(i.e., 0.00000001 BTC). For a non-fungible asset like Cryptokitties,

the smallest indivisible entity is a single “cryptokitty”. Accordingly,

|A| represents the total supply of the asset.

We define the set of blockchains betweenwhich cross-blockchain

asset transfers can take place by the finite set B. Each blockchainb ∈
B can host multiple smart contracts. Out of these smart contracts,

one contract is responsible for managing asset A on b. We denote

this particular smart contract as c
b
for each b ∈ B.

We assume blockchains to roughly follow the model devised by

Satoshi Nakatomo [26]. The state of the blockchain is updated by

means of transactions. Transactions are cryptographically-signed

instructions that are created outside the blockchain and bundled

into new blocks. New blocks are broadcast to nodes in a peer-to-

peer network. Participating nodes validate each new block along

with its transactions and append the block to their local copy of the

blockchain only if they accept it as valid. If a new block is accepted

as valid by the majority of participants, the block defines the new

state of the blockchain.

Transactions can be used to transfer the native asset of the block-

chain, to store arbitrary data, or to trigger the execution of smart

contracts. In the latter case, the transaction’s payload contains pa-

rameters based on which the smart contracts may change their

associated state. For instance, a transaction payload containing a

sender, a recipient and an amount could trigger a smart contract

causing the transfer of some user-defined asset from the sender to

the recipient.

We specify transactions as a tuple containing the elements of

the payload which serve as parameters for the invoked contract. In

particular, we use tx B ⟨param1, . . . ,paramn⟩ to denote a transac-
tion tx with a payload containing n parameters. Further, we define

the function calledContract(tx) to return the address of the smart

contract that was triggered by transaction tx. The execution of

transactions may fail, for instance, if a user does not have enough

funds for a transfer or some condition is violated. For this, we de-

fine function isSuccessful(tx) to return true or false depending on

whether the transaction was executed successfully or not.

Every transaction is signed by some off-chain user u ∈ U before

submitted to the blockchain. submitter(tx) denotes the user that
signed tx. Users can be the owners of a subset of asset A on each

participating blockchain b ∈ B. Subsequently, the set Abu ⊆ A
defines the entities of asset A that are owned by a particular user

u ∈ U on blockchain b.
Finally, for two blockchains src, dest ∈ B and two users sender,

recipient ∈ U , we define a cross-blockchain asset transfer as transfer

of some X ⊆ A from user sender on source blockchain src to user

recipient on destination blockchain dest.

3 CROSS-BLOCKCHAIN ASSET TRANSFERS
In this section, we first define requirements for cross-blockchain

asset transfers and then use these requirements as the foundation

to define a decentralized cross-blockchain asset transfer protocol.

Fundamental to the protocol is the ability to communicate state in-

formation between blockchains. In particular, the protocol relies on

the ability to verify the inclusion of transactions across blockchains.

However, the protocol treats transaction inclusion verifications as a

blackbox, i.e., the protocol does not pose any restrictions on the con-

crete mechanism that is used for cross-blockchain communication.

Different solutions for cross-blockchain communication and how

these can be used to perform transaction inclusion verifications are

explained in Section 3.3.

3.1 Requirements
As defined in Section 2, a cross-blockchain asset transfer for an

asset A constitutes the transfer of ownership of some subset X ⊆ A
from some user sender on a source blockchain src to another user

recipient on a destination blockchain dest.

Before the transfer, X must only exist on blockchain src, and

after the transfer, the asset must only exist on blockchain dest.

At no point should X exist on both blockchains in parallel, since

the accidental duplication of asset entities can potentially lead to

a deflation of the asset’s value. Hence, a cross-blockchain asset

2



transfer should only be successful, i.e., X is created on dest, if X has

been priorly burned (i.e., destroyed) on src.

Therefore, before X can be recreated on dest, dest needs some

kind of evidence that X has already been burned on src. If we

assume that it is possible to provide such evidence guaranteeing

that X has been burned on src and that this evidence can be used to

recreate X on dest, two further requirements emerge. First, faking

the evidence needs to be prevented at all cost. Users should not be

able to counterfeit evidence certifying that X has been burned on

src without it actually having occurred. Second, if the evidence is

correct (i.e., it has not been faked), it should only be usable once to

recreate X on a different blockchain, i.e., on blockchain dest. Hence,

evidence of X having been burned on src cannot be used multiple

times to recreate X on other blockchains. Essentially, disregard of

any of these requirements would enable users to illegally create

new entities of asset A out of nothing—again potentially deflating

the value of the asset and decreasing trust in this particular asset.

A further requirement comes up when trying to prevent the

opposite, an accidental inflation of the asset’s value. Accidental

inflation could take place if X is burned on src without ever being

recreated on dest reducing the total supply of A. Hence, cross-
blockchain asset transfers need to be eventually finalized as not to

decrease the total supply ofA over time. That is, either the transfer is

executed completely or it fails with no intermediate state persisting.

Finally, it could be the case that the source blockchain src needs

to perform some action if and only if a certain cross-blockchain

asset transfer has been executed successfully (i.e., X has been suc-

cessfully recreated on destination blockchain dest). For instance,

imagine a business deal where some user buyer wants to buy as-

set entities Y ⊆ A′
, with A′ ∩ A = ∅, from another user seller.

While asset A′
lives exclusively on the source blockchain src, user

buyer aims to buy Y with cross-blockchain asset A, transferring
X from themselves on blockchain src to user seller on blockchain

dest. Therefore, ownership of Y can change on src if and only if it

is ensured that the transfer of X was successful, i.e., blockchain src

must retrieve a confirmation of the successful transfer.

To sum up, we define the general requirements for a cross-

blockchain asset transfer as follows.

Requirement 1: Ownership.
When a user sender wants to burn X on blockchain src, X should

only be burned if X ⊆ Asrc

sender
.

Requirement 2: No Claim Without Burn.
When transferring some X ⊆ A from the source blockchain src to

the destination blockchain dest, X should only be recreated on dest,

if it can be proven that X has already been burned on src. That is, it

should not be possible to counterfeit the burning of asset entities.

Requirement 3: Double Spend Prevention.
Double spending must be prevented at all times. That is, if X is

burned on one blockchain, X can only be recreated once on one

other blockchain.

Requirement 4: Decentralized Finality.
If X is burned on one blockchain, X is always recreated on another

blockchain within a certain time limit t . Further, finality should not
be dependent on a single actor (centralized), rather any participant

should be able to finalize transfers (decentralized).

1. Burn

2. Claim

User

Destination
Blockchain

Source
Blockchain

Figure 1: Base protocol for cross-blockchain asset transfers

1. Burn

2. Claim

User

Source
Blockchain 3. Confirm

Destination
Blockchain 

Figure 2: Protocol extension to provide transfer confirma-
tions

Requirement 5: Transfer Confirmation (optional).
After burningX on source blockchain src, src will eventually receive

a confirmation that X has been successfully recreated on another

blockchain. Analogous to decentralized finality, any user should be

able to submit confirmations.

In the next section, we define a cross-blockchain asset transfer

protocol that fulfils these requirements. To this end, we first define

a base protocol that fulfils Requirements 1 to 4. We then provide an

extension of the protocol in order to also account for Requirement 5.

3.2 Protocol
As mentioned above, a cross-blockchain asset transfer should only

be successful if the asset is first burned on the source blockchain and

then recreated on the destination blockchain (Requirement 2). This

requires at least two steps, one “burn” step on the source blockchain,

and one “claim” step on the destination blockchain (see Figure 1).

With this in mind, we can outline a minimal protocol for cross-

blockchain asset transfers.

3.2.1 Base Protocol.
A minimal protocol for cross-blockchain asset transfers consists of

a burn transaction txburn submitted to source blockchain src and a

claim transaction txclaim submitted to destination blockchain dest.

The specification is outlined in Protocol 1.

As a first step, some user sender creates transaction txburn. The

payload of txburn contains the user intended as recipient of the

transfer (recipient), an identifier representing the desired destina-

tion blockchain (dest), and the asset entities to be transferred (X ).

User sender then signs and submits txburn to the source block-

chain src invoking smart contract csrc which manages asset A
on blockchain src (Step 1.a). The smart contract then performs

the following steps. First, it verifies that the specified destination

blockchain dest is actually part of the cross-blockchain ecosys-

tem (Step 1.(b)i). Second, the contract makes sure that user sender

is actually the current owner of X on blockchain src (Step 1.(b)ii).

If both checks are successful, X is burned on src (Step 1.(b)iii).

Once txburn is included in blockchain src and confirmed by

enough succeeding blocks, any user u ∈ U can construct the claim

transaction txclaim. The payload of txclaim consists of transaction

3



Protocol 1 Base protocol for cross-blockchain asset transfers

Goal: For two blockchains src, dest ∈ B and two users sender, recipient ∈ U , transfer X ⊆ A from src to dest and change ownership of X from

sender to recipient.

1. Burn. User sender creates a new burn transaction txburn B ⟨recipient, dest,X ⟩.
(a) User sender signs and submits txburn to source blockchain src invoking contract csrc, i.e., the contract managing asset A on src .
(b) When being invoked, contract csrc performs the following operations.

(i) Verify dest ∈ B to make sure that the specified blockchain dest is part of the cross-blockchain ecosystem.

(ii) Verify X ⊆ Asrc

sender
to make sure that user sender owns the asset entities she wants to transfer on blockchain src.

(iii) When all checks are successful, the asset entities to be transferred are burned, i.e., Asrc

sender
= Asrc

sender
\ X .

2. Claim. Once txburn has been successfully executed on blockchain src, any user u ∈ U can construct the claim transaction

txclaim B ⟨txburn, prooftxburn ⟩. Variable prooftxburn contains data which can be used to prove the successful execution and inclusion of

txburn within blockchain src.

(a) User u signs and submits txclaim to some blockchain b ∈ B invoking contract c
b
, i.e., the contract managing asset A on b.

(b) When being invoked, contract c
b
performs the following steps.

(i) Verify b = dest to ensure that the executing blockchain b is the intended destination blockchain dest. Note that dest, recipient,

and X are available within c
b
as these variables are contained within the payload of txburn.

(ii) Verify txburn < Tburn where Tburn is the set of burn transactions that have already been used to claim entities of asset A on

dest. This ensures that burn transactions cannot be used multiple times for claiming.

(iii) Run verifyInclusion(txburn, prooftxburn , src) to verify that txburn has been included in blockchain src and is confirmed by

enough blocks. The details of transaction inclusion verifications are explained in Section 3.3.

(iv) Verify calledContract(txburn) = csrc to make sure that the contract that has been invoked by txburn is a contract authorized for

managing asset A on blockchain src.

(v) Verify that isSuccessful(txburn) returns true to ensure that the execution of csrc has been completed without any error.

(vi) If timeoutReached(txburn, prooftxburn , src) returns true, user recipient has not submitted txclaim in time. Hence, the user

u = submitter(txclaim) that submitted txclaim receives a transfer fee X
fee

⊆ X as reward for finalizing the transfer, i.e.,

Adest

u = Adest

u ∪ X
fee
. Otherwise, no fee will be payed to u (i.e., X

fee
= ∅) resulting in all asset entities being transferred to

recipient (see next step).

(vii) Assign ownership of the transferred asset entities to user recipient, i.e., Adest

recipient
= Adest

recipient
∪ (X \ X

fee
).

(viii) Add txburn to the set of already used burn transactions, i.e., Tburn = Tburn ∪ {txburn}.

txburn and some proof data that can be used to verify the inclusion

of txburn in blockchain src (proof
txburn

). Note that if only the sender

or only the recipient of the transfer were allowed to submit txclaim,

the finality of the transfer (Requirement 4) would be entirely de-

pendent on that particular user, e.g., the user could simply decide

not to submit txclaim.

User u then signs and submits txclaim to some blockchain b ∈ B
invoking the contract c

b
managing A on blockchain b (Step 2.a).

The contract then performs the following steps. First, it veri-

fies that b is the intended destination blockchain dest (Step 2.(b)i).

Second, it is verified that txburn has not been used to claim X
on b before (Step 2.(b)ii). Third, if both checks are successful, the

transaction inclusion verification is carried out.

As mentioned above, the protocol treats transaction inclusion

verifications as a blackbox. More precisely, the protocol requires a

smart contract on the destination blockchain dest that simply pro-

vides an answer to the question whether a certain transaction has

been included in the source blockchain src by returning either true

or false. We elaborate on approaches that can be used to implement

such a contract in Section 3.3. The transaction inclusion verification

is carried out by passing txburn and proof data proof
txburn

to the

smart contract capable of performing transaction inclusion verifica-

tions for blockchain src (Step 2.(b)iii). If this smart contract returns

true, it means that txburn is included and confirmed in src.

After verifying the inclusion of txburn in blockchain src, the

contract c
b
verifies that the contract that burned X on src is a valid

contract authorized for managing A on src (Step 2.(b)iv). If this is

the case, contract c
b
further checks that txburn was successful, i.e.,

the execution of contract csrc has been completed without any error,

e.g., constraint violations (Step 2.(b)v). This check covers the case

that in some blockchains transactions may be included even if the

triggered smart contract execution was not successful. While this is

the case for blockchains such as Ethereum, other blockchains may

not include such transactions at all.

The above checks guarantee that txclaim can only be executed

successfully with a corresponding successful txburn. However, an

additional mechanism is needed to account for Requirement 4,

transfer finality. In particular, it needs to be ensured that when

transaction txburn takes place on blockchain src, eventually also the

corresponding txclaim is submitted to destination blockchain dest.

Usually, the incentive for transfer finalization lies with the recip-

ient of the transfer since the recipient wants to receive the trans-

ferred asset entities. However, in case the recipient is indisposed

to submit txclaim for some reason, the protocol offers an incentive

in the form of a transfer fee to other users. That is, any user u that

successfully submits txclaim gets assigned a subset X
fee

⊆ X as

reward (Step 2.(b)vi). However, to provide user recipient with the

chance to receive all entities of X , other users are only eligible to

4



Protocol 2 Extension for transfer confirmations on the source blockchain

Goal: For two blockchains src, dest ∈ B and two users sender, recipient ∈ U , transfer X ⊆ A from src to dest and change ownership of X from

sender to recipient. Confirm finalization of transfer on src.

1. Burn. Similar to Protocol 1, user sender creates a new burn transaction txburn B ⟨recipient, dest,X ,Y ⟩. Contrary to Protocol 1, txburn

contains an additional variable Y ⊆ A representing the stake that will act as reward for users submitting a confirmation transaction to src

once the transfer has been completed on dest.

(a) User sender signs and submits txburn to source blockchain src invoking contract csrc.
(b) When being invoked, contract csrc performs the following steps.

(i) Perform all verification steps from Step 1.b of Protocol 1.

(ii) Verify Y ⊆ Asrc

sender
to make sure that user sender owns the asset entities she wants to use as stake on blockchain src.

(iii) Verify Y ∩ X = ∅, i.e., X and Y are disjoint, to ensure that the asset entities intended to be transferred are not used as stake and

vice versa.

(iv) When all checks are successful, the asset entities to be transferred are burned and the stake is locked, i.e.,

Asrc

sender
= Asrc

sender
\ (X ∪ Y ).

2. Claim. To claim the entities of asset A on destination blockchain dest, the same steps as for txclaim in Protocol 1 are performed.

3. Confirm. Once txclaim has been successfully executed on blockchain dest, any user u ∈ U can now construct a confirm transaction

txconfirm B ⟨txclaim, prooftxclaim ⟩. Variable prooftxclaim contains data which can be used to prove the successful execution and inclusion of

txclaim within blockchain dest.

(a) User u signs and submits txconfirm to the source blockchain src invoking contract csrc.
(b) When being invoked, contract csrc performs the following steps.

(i) Verify txclaim < Tclaim where Tclaim is the set of claim transactions that have already been used for confirming transfer

finalization on src . This ensures that claim transactions cannot be used multiple times.

(ii) Verify calledContract(txburn) = csrc to ensure that txconfirm invokes the same contract that has been invoked by txburn.

(iii) Run verifyInclusion(txclaim, prooftxclaim , dest) to verify that txclaim has been included in blockchain dest and is confirmed by

enough blocks. The details of transaction inclusion verifications are explained in Section 3.3.

(iv) Verify calledContract(txclaim) = cdest to make sure that the contract that has been invoked by txclaim is the contract managing

asset A on dest as intended by txburn.

(v) Verify that isSuccessful(txclaim) returns true to ensure that the execution of c
dest

has been completed without any error.

(vi) If all checks are successful, it is ensured that X has already been burned on src and claimed on dest. Hence, the

cross-blockchain asset transfer can be seen as confirmed.

(vii) Check if timeout for submitting tx
confirm

is reached. If so, user sender has not submitted txconfirm in time. Hence, the user

u = submitter(txconfirm) that submitted txconfirm receives the locked stake from txburn as reward for providing the

confirmation of the corresponding claim, i.e., Asrc

u = Asrc

u ∪ Y . If not, user sender gets back control of the locked stake, i.e.,

Asrc

sender
= Asrc

sender
∪ Y , regardless of which user submitted tx

confirm
.

(viii) Add txclaim to the set of already used claim transactions, i.e., Tclaim = Tclaim ∪ {txclaim}.

receive the fee if they submit txclaim after a certain time period t
has elapsed.

Time period t is defined by the number of blocks that succeed

the block containing txburn on source blockchain src. Hence, when

being invoked by tx
claim

, c
dest

additionally queries the smart con-

tract implementing the transaction inclusion verifications whether

the block containing txburn is confirmed by at least t succeeding
blocks. If this is the case, the time period t is considered elapsed,

the user that submitted txclaim receives the transfer fee X
fee
, and

user recipient receives the rest X \ X
fee
. If not, user recipient al-

ways receives the entire set X (i.e., X
fee
= ∅), even if another user

submitted txclaim (Step 2.(b)vii).

Finally, to ensure that txburn cannot be used to claim X on b
again, txburn is added to the set of already used burn transactions

Tburn (Step 2.(b)viii).

3.2.2 Protocol Extension for Transfer Confirmations.
Protocol 1 provides finality by incentivizing users to submit txclaim

for each txburn. However, only the destination blockchain dest

can be entirely certain that a cross-blockchain asset transfer was

completed successfully. Source blockchain src never actually learns

about the finalization of the transfer. To circumvent this, we can

augment Protocol 1 by adding a third kind of transaction (confirm)

which can be used to confirm the successful cross-blockchain asset

transfer back to src as displayed in Figure 2.

The extension of the protocol is specified in Protocol 2. At first,

transaction txburn is submitted to the source blockchain src. The

payload of txburn has remained largely the same except one ad-

ditional field Y . Y is a subset of asset A and represents a certain

amount of stake that will act as reward for users submitting a

confirm transaction to src.

When user sender submits txburn to src (Step 1.a), csrc first per-
forms the same verifications as in Protocol 1 (Step 1.(b)i). Addition-

ally, a couple of checks concerning the stake Y are performed. First,

it is verified that user sender is the owner of Y on blockchain src

5



(Step 1.(b)ii). Second, it is verified that the sets X and Y are dis-

joint (Step 1.(b)iii). That is, the asset entities intended to be trans-

ferred should not be used as stake and vice versa. If all verifications

are successful, X is burned on src and Y is locked (Step 1.(b)iv).

Once txburn is included in src, any user can create and submit

transaction txclaim containing txburn and a corresponding proof

data proof
txburn

to the destination blockchain dest . The steps per-
formed when the corresponding smart contract c

dest
is invoked are

identical to those in Protocol 1.

With txclaim being successfully executed and included in block-

chain dest, the successful transfer now needs to be reported back

to source blockchain src. For that, any user can submit a confirm

transaction txconfirm to src (Step 3.a).

When being invoked by txconfirm, contract csrc performs the

following steps. First, it is verified that txclaim has not already been

used for confirming transfer finalization (Step 3.(b)i). Second, it is

verified that contract csrc is the contract that has actually burned X,

i.e., whether csrc has been invoked by txburn (Step 3.(b)ii). This check
ensures that contract csrc is the intended receiver of the confirma-

tion. Third, it is verified that txclaim is included in dest by means of

transaction inclusion verification (Step 3.(b)iii). Fourth, csrc verifies
that the contract invoked by txclaim is the correct contract manag-

ing assetA on the intended destination blockchain dest (Step 3.(b)iv).

dest can be extracted from txburn which is included in the payload

of the provided txclaim. Fifth, contract csrc checks that txclaim was

successful, i.e., the execution of contract c
dest

has been completed

without any error (Step 3.(b)v).

If all checks are successful, contract csrc can be certain that not

only txburn has been successfully executed but that the correspond-

ing txclaim finalized the transfer on blockchain dest (Step 3.(b)vi).

To reward user u for submitting txconfirm to src, the locked stake Y
from txburn is assigned to u (Step 3.(b)vii). This provides an in-

centive for users to submit txconfirm to src for finalized cross-

blockchain asset transfers.

To provide the initiator of the transfer (i.e., user sender) the

opportunity to withdraw her locked sta";"""date"",""2020-04-23T01:00:51Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""Decentralized Cross-Blockchain Asset Transfers""
""xmp:CreatorTool"",""LaTeX with acmart 2020/02/22 v1.70 Typesetting articles for the Association for Computing Machinery and hyperref 2016/06/24 v6.83q Hypertext links for LaTeX""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with acmart 2020/02/22 v1.70 Typesetting articles for the Association for Computing Machinery and hyperref 2016/06/24 v6.83q Hypertext links for LaTeX""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""Decentralized Cross-Blockchain Asset Transfers""
""modified"",""2020-04-23T01:00:51Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""Marten Sigwart, Philipp Frauenthaler, Christof Spanring, and Stefan Schulte""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016) kpathsea version 6.2.2""
""meta:author"",""Marten Sigwart, Philipp Frauenthaler, Christof Spanring, and Stefan Schulte""
""trapped"",""False""
""meta:creation-date"",""2020-04-23T01:00:51Z""
""created"",""2020-04-23T01:00:51Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-04-23T01:00:51Z""
""resourceName"",""2004.10488""
""Author"",""Marten Sigwart, Philipp Frauenthaler, Christof Spanring, and Stefan Schulte""
""producer"",""pdfTeX-1.40.17""
""pdf:docinfo:producer"",""pdfTeX-1.40.17""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""1"",""0"",""3"",""3"",""0"",""0"",""1"",""0"",""0"",""0"",""0""
""Keywords"",""Cross-blockchain asset transfers, cross-blockchain communication, blockchain interoperability""
""access_permission:modify_annotations"",""true""
""dc:creator"",""Marten Sigwart, Philipp Frauenthaler, Christof Spanring, and Stefan Schulte""
""dcterms:created"",""2020-04-23T01:00:51Z""
""Last-Modified"",""2020-04-23T01:00:51Z""
""dcterms:modified"",""2020-04-23T01:00:51Z""
""title"",""Decentralized Cross-Blockchain Asset Transfers""
""Last-Save-Date"",""2020-04-23T01:00:51Z""
""pdf:docinfo:keywords"",""Cross-blockchain asset transfers, cross-blockchain communication, blockchain interoperability""
""pdf:docinfo:modified"",""2020-04-23T01:00:51Z""
""meta:save-date"",""2020-04-23T01:00:51Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016) kpathsea version 6.2.2""
""Content-Length"",""786023""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Marten Sigwart, Philipp Frauenthaler, Christof Spanring, and Stefan Schulte""
""dc:language"",""en""
""dc:subject"",""Cross-blockchain asset transfers, cross-blockchain communication, blockchain interoperability""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""12""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""4702"",""5586"",""4937"",""5088"",""4594"",""5317"",""5191"",""5625"",""5986"",""3666"",""5286"",""7296""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""Cross-blockchain asset transfers, cross-blockchain communication, blockchain interoperability""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-04-23T01:00:51Z""
";https://scholar.google.com/scholar?start=40&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095323-1368;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;[PDF][PDF] Blockchain Application in Energy Performance Contracting;AG Aoun ; researchgate.net;;"… CDD. In our case, three oracles are needed to obtain real-world data and log

it into the blockchain and smart contracts. The Energy Meter Oracle is responsible

for obtaining the chiller's daily energy consumption. The …";Autres articles;;[PDF] researchgate.net;https://www.researchgate.net/profile/Alain_Aoun4/publication/339927771_Blockchain_Application_in_Energy_Performance_Contracting/links/5e6cb882a6fdccf994c6951a/Blockchain-Application-in-Energy-Performance-Contracting.pdf;;;https://scholar.google.com/scholar?start=170&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095383-1626;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Integration of blockchain and cloud of things: Architecture, applications and challenges;DC Nguyen, PN Pathirana, M Ding… ; … Surveys & Tutorials, 2020  ieeexplore.ieee.org;;"… Cloud of Things 1) Blockchain: Blockchain is mostly known as the technol- ogy underlying the

virtual cryptocurrency Bitcoin which … cloud computing for blockchain is proven through recent suc-

cessful integration cloud-blockchain projects, such as Oracle blockchain (2017) and …";Cité 24 fois;Les 4 versions;[PDF] arxiv.org;https://arxiv.org/pdf/1908.09058;"
IEEE COMMUNICATIONS SURVEYS & TUTORIALS 1

Integration of Blockchain and Cloud of Things:
Architecture, Applications and Challenges

Dinh C. Nguyen, Student Member, IEEE, Pubudu N. Pathirana, Senior Member, IEEE,
Ming Ding, Senior Member, IEEE, and Aruna Seneviratne, Senior Member, IEEE

Abstract—The blockchain technology is taking the world by
storm. Blockchain with its decentralized, transparent and secure
nature has emerged as a disruptive technology for the next gener-
ation of numerous industrial applications. One of them is Cloud
of Things enabled by the combination of cloud computing and
Internet of Things. In this context, blockchain provides innovative
solutions to address challenges in Cloud of Things in terms
of decentralization, data privacy and network security, while
Cloud of Things offer elasticity and scalability functionalities
to improve the efficiency of blockchain operations. Therefore, a
novel paradigm of blockchain and Cloud of Things integration,
called BCoT, has been widely regarded as a promising enabler
for a wide range of application scenarios. In this paper, we
present a state-of-the-art review on the BCoT integration to
provide general readers with an overview of the BCoT in
various aspects, including background knowledge, motivation,
and integrated architecture. Particularly, we also provide an in-
depth survey of BCoT applications in different use-case domains
such as smart healthcare, smart city, smart transportation and
smart industry. Then, we review the recent BCoT developments
with the emerging blockchain and cloud platforms, services, and
research projects. Finally, some important research challenges
and future directions are highlighted to spur further research in
this promising area.

Index Terms—Blockchain, cloud computing, Internet of
Things, Cloud of Things, security, industrial applications.

I. INTRODUCTION

Recent years have witnessed the explosion of interest in
blockchain, across a wide span of applications from cryptocur-
rencies to industries [1], [2]. The rapid development in the
adoption of blockchain as a disruptive technology is paving the
way for the next generation of financial and industrial service
sectors. Indeed, new research activities on blockchain and its
applications take place every day, impacting many aspects of
our lives, such as finance [3], energy [4], and government
services [5].

From a technical perspective, blockchain is a distributed
ledger technology that was first used to serve as the public
digital ledger of cryptocurrency Bitcoin [6] for economic

*This work was supported in part by the CSIRO Data61, Australia.
Dinh C. Nguyen is with School of Engineering, Deakin University, Waurn

Ponds, VIC 3216, Australia, and also with the CSIRO Data61, Docklands,
Melbourne, Australia (e-mail: cdnguyen@deakin.edu.au).

Pubudu N. Pathirana is with School of Engineering, Deakin University,
Waurn Ponds, VIC 3216, Australia (email: pubudu.pathirana@deakin.edu.au).

Ming Ding is with the CSIRO Data61, Australia (email:
ming.ding@data61.csiro.au).

Aruna Seneviratne is with School of Electrical Engineering and Telecom-
munications, University of New South Wales (UNSW), NSW, Australia
(email: a.seneviratne@unsw.edu.au).

transactions. The blockchain is basically a decentralized, im-
mutable and public database. The concept of blockchain is
based on a peer-to-peer network architecture in which trans-
action information is not controlled by any single centralized
entity. Transactions stored in a chain of blocks are publicly
accessible to all blockchain network members in a trustworthy
manner. Blockchain uses consensus mechanisms and cryptog-
raphy to validate the legitimacy of data transactions, which
guarantees resistance of linked blocks against modifications
and alterations [7]. In particular, the blockchain technology
also boasts the desirable characteristics of decentralization,
accountability, and security which improve service efficiency
and save operational costs. Such exceptional properties pro-
mote the usage of applications built on blockchain in recent
years. Thus, it makes now the right time to pay attention to
this hot research topic.

On the other side, the revolution in the field of information
and communication has created a wealth of opportunities for
advanced technologies, especially Internet of Things (IoT)
and Cloud computing. IoT has reshaped and transformed our
lives with various new industrial, consumer, and commercial
services and applications [8], [9]. Typically, IoT is a system of
physical objects that can be monitored, controlled or interacted
with by ubiquitous electronic devices to enable ubiquitous
industrial services, e.g., smart cities, smart industries, etc. Due
to the limited resources of IoT devices, they always delegate
IoT application tasks to Cloud computing, which gives birth
to the Cloud of Things (CoT) paradigm [10], [11]. The
CoT provides a flexible, robust cloud computing environment
for processing and managing IoT services, showing great
potentials to improve the system performance and efficiency of
service delivery [12]. However, the conventional CoT infras-
tructures tend to be ineffective due to the following challenges.
First, the conventional CoT solutions have mainly relied on
centralized communication models, e.g., central cloud, for IoT
service operations which make it hard to scale when IoT net-
works become more widespread [13]. Moreover, most current
CoT systems mandate trusting a third party, e.g., a cloud
provider, for IoT data processing, which raises data privacy
concerns. Final, the centralized network infrastructure results
in higher communication latency and power consumption for
IoT devices due to long data transmission, which hinders the
large-scale deployments of CoT in practical scenarios [14].

In order to achieve a sustainable development of CoT,
building a more decentralized ecosystem has been regarded
as a future direction to replace centralized computing models
used in current applications, as illustrated in Fig. 1. It is

ar
X

iv
:1

90
8.

09
05

8v
2 

 [
cs

.C
R

] 
 2

8 
A

ug
 2

02
0



IEEE COMMUNICATIONS SURVEYS & TUTORIALS 2

Before 2005 Today 2025 and beyond

Closed data access with 

centralized computing 

Closed data access with 

decentralized computing
Open data access with 

decentralized computing

Open data access with 

centralized computing

Cloud 

servers

Edge 

servers

Fig. 1: Past, present and future Cloud of Things infrastructure.

strongly believed that blockchain will be a strong candidate
to realize the full decentralization of future CoT networks.
Particularly, the integration of blockchain and CoT leads to
a novel paradigm called as BCoT. The combination of these
emerging technologies brings great benefits to both worlds and
thus gains sustainable interest in academics and industries. In
fact, the blockchain and CoT have a number of complementary
connections for practical applications. In the context of cloud
computing, blockchain has been regarded as a service called
Blockchain as a Service (BaaS). By providing a decentralized
storage architecture using virtual storage nodes, blockchain
can enable completely new cloud storage functions which
are strongly resistant to data modifications. Instead of relying
on traditional cloud data centres, blockchain interconnects
computer nodes, including virtual machines on cloud and
external computers, to build a fully decentralized storage
system without requiring a central authority. Blockchain also
functions as network management services which are closely
related to smart contract-based applications. In such scenar-
ios, blockchain acts as a communication layer among cloud
servers, IoT devices, and end users. Specifically, the adoption
of blockchain can provide many potential benefits for CoT
systems as follows.

• Decentralization: Blockchain with its decentralized nature
is a promising methodology to effectively solve the bot-
tleneck and single-point failure issues by eliminating the
requirement for a trusted third party in the CoT network
[15]. Further, the peer-to-peer architecture of blockchain
allows all network participants to verify IoT data correct-
ness and ensure immutability with equal validation rights.

• Security and Privacy: The BCoT system can achieve a
trustworthy access control by using blockchain-enabled
smart contracts [16] which enable to authorize automati-
cally all operations of cloud providers and IoT devices
and prevent potential threats to cloud resources and
enhance fine-grained control on IoT data [17]. Moreover,
the blockchain enables users to track their transactions
over the network so as to maintain device and data
ownership for improving information privacy.

• Corporation: Blockchain enables a new cooperation
ecosystem among multiple entities with unlimited data
sharing capabilities without trusting each other. The re-
moval of the third party helps establish open environ-

ments where any IoT users and cloud providers interested
in the system can participate and collaborate to achieve
the common goals within the BCoT ecosystem [18].

On the other hand, CoT can support blockchain platforms with
the following key benefits:

• Scalable support for blockchain transactions: In large-
scale blockchain applications, the number of transactions
in blockchain networks can be enormous. Therefore, it
is highly necessary to provide powerful data process-
ing services to accelerate transaction execution in order
to enable scalable blockchain services. In this context,
the cloud can offer on-demand computing resources for
blockchain operations thanks to its elasticity and scalabil-
ity capability [19]. For example, public clouds can offer
a large-scale network of resources for blockchain service
operators in a federated cloud environment. Therefore,
the combination of cloud computing and blockchain can
achieve a high scalability of the integrated system.

• Fault tolerance: Cloud can help replicate blockchain
data across a network of computing servers which are
interconnected robustly by collaborative clouds [20]. This
will minimize the single-failure risks due to the disruption
of any cloud node and thus ensure uninterrupted ser-
vices. Further, the inter-cloud ecosystem can enable the
blockchain system to operate continuously in the event
of a certain cloud server being under attack.

Reviewing the state of the art in the field, we find that
BCoT attracts enormous interests of research communities
as shown in Fig. 2. Cloud computing and IoT have gained
popularity in the last five years with considerable research pub-
lications. Interestingly, blockchain is increasingly becoming a
hot research area in recent years with a fast-growing research
trend, showing a really promising topic for both academics
and industries in the future. The sustainable development of
CoT and blockchain will drive breakthrough innovations to
empower intelligent services and applications.

A. Related Works and Contributions of This Survey

Many studies in CoT, blockchain and related issues have
been investigated over the recent years in a wide range of
technical aspects. Many efforts have been made to provide
review articles on this research area in different scopes. The



IEEE COMMUNICATIONS SURVEYS & TUTORIALS 3

3405

5635

8082 8399
9398

19739

21937 21841

20091
21100

23 153
653

1891 1902

0

5000

10000

15000

20000

25000

2015 2016 2017 2018 2019

IoT Cloud computing Blockchain

Year

N
u

m
b

e
r
 o

f 
p

u
b

li
c
a
ti

o
n

s

Fig. 2: Research trends about IoT, Cloud and blockchain (Source: Web of
Science).

survey papers [21], [22], [23] presented the review of recent
efforts in the adoption of blockchain technology in various IoT
scenarios and applications. The authors in [24] also discussed
the integration of blockchain technology with IoT. The key
focus of this work is on the investigation of the potential of
blockchain for IoT applications, from smart manufacturing
to the Internet of vehicles, unmanned aerial vehicles, and
5G networks. The survey in [25] paid attention to analysis
on the technical aspects of blockchain, such as underlying
concepts, networking and consensus strategies. Meanwhile,
the authors in [26] discussed research issues, challenges and
opportunities of combination between blockchain and cloud
computing. The work [27] presented a survey on the use
of the blockchain technology to provide security services
and its technical properties to solve associated challenges in
various application domains, including IoT and Cloud com-
puting. More recently, the overview of the integrated model of
blockchain and edge computing, an extended cloud computing
concept, was discussed in the survey [28]. Table I summarizes
the main topics and contributions of the literature surveys
related to BCoT and our paper.

Although blockchain and CoT have been studied extensively
in the literature works, there is no existing work to provide a
comprehensive survey on the combination of these important
research areas, to our best knowledge. In comparison to the
above review works, in this paper, we provide an extensive
survey on the integration of blockchain and CoT with a com-
prehensive discussion on many aspects, ranging from concept
background, integrated architectures to application domains,
service platforms and research challenges. The main goal of
this survey is to provide readers with thorough knowledge
of the blockchain and CoT integration which is collected
from respective websites, technical reports, academic articles
and newspapers. The main contributions of this survey are
highlighted as follows.

1) We provide a state-of-the-art survey on the corporation
of blockchain and CoT with a comprehensive discussion
on different technical aspects, from BCoT background,
integration motivations to the conceptual BCoT integrated

TABLE I: Surveys on blockchain and Cloud, IoT technologies.

Paper Topic Main contributions
[23] Blockchain and

IoT
A survey of blockchain protocols for
IoT, research issues and challenges of
IoT-blockchain integration.

[24] Blockchain and
IoT

A comprehensive survey of underlying
blockchain concepts, architectures, ap-
plications for IoT.

[25] Blockchain and
IoT

A brief review on the usage of
blockchain for IoT.

[26] Blockchain and
IoT

The investigation of the potential of
blockchain for IoT applications.

[27] Blockchain and
IoT

Analysis on the technical aspects
of blockchain and potentials of
blockchain for IoT.

[28] Blockchain and
Cloud

A brief survey of blockchain in cloud
computing and its security solutions
for cloud-based applications.

[29] Blockchain and
Cloud

An introduction of blockchain for
cloud platforms with associated chal-
lenges opportunities.

[30] Blockchain and
edge computing

A systematic survey of the combina-
tion of blockchain and edge computing

This paper Blockchain and
CoT

A comprehensive review on the inte-
gration of blockchain and CoT with a
detailed discussion on concepts, archi-
tectures, BCoT applications and BCoT
platforms along with challenges and
future research directions.

architecture.
2) We present the updated review on the use of BCoT

models in various application domains. We analyse the
benefits of BCoT adoption and the important lessons
learnt in each use case are then summarized. Moreover,
the emerging BCoT platforms and services are also
presented and discussed.

3) From the extensive review on BCoT integrations, we
identify possible research challenges and open issues
in the field. Some future research directions are also
explored to extend the scope of BCoT in future services
and applications.

B. Structure of The Survey

The structure of this survey is organized as Fig. 3. Section II
describes the background knowledge of both blockchain and
CoT and presents the motivations of the BCoT integration.
The conceptual BCoT architecture is presented in Section
III. We review the recent developments of BCoT in Section
IV with extensive discussions on the roles of BCoT in a
wide range of application domains. Moreover, the emerging
BCoT platforms and services are also presented and discussed.
Section V discusses possible research challenges and open
issues in the BCoT integration, while future directions are
outlined in Section VI. Finally, Section VII concludes the
paper.

II. BLOCKCHAIN, COT, AND INTEGRATION MOTIVATION

In this section, we first introduce the background knowledge
of blockchain and CoT. Then, we present the motivations of
the integration of such two technologies.



IEEE COMMUNICATIONS SURVEYS & TUTORIALS 4

Smart 

healthcare
Smart city

Smart 

transportation

 BCoT Applications

Smart 

industry

Other BCoT 

applications

BaaS services for 

cloud IoTs

 BCoT Platforms and Services 

Cloud blockchain 

platforms

Related Works

Section III: The BCoT Architecture

The Conceptual BCoT Architecuture

Discussion

Section V: Research Challenges and Discussion

Research Challenges

Section IV: Research and Technology Development of BCoT

Motivations of the BCoT Integration

Section II: Background and Motivations of BCoT Integration

Background of Blockchain and CoT

Section VI: Future Directions

Machine learning 

with BCoT

 Improving blockchain 

performance for BCoT
Big data in BCoT

 BCoT in 5G 

networks

Section VII: Conclusions

Section I: Introduction

Blockchain and CoT Introduction Contribution

Fig. 3: Organization of the paper.

A. Blockchain and Cloud of Things

1) Blockchain: Blockchain is mostly known as the technol-
ogy underlying the virtual cryptocurrency Bitcoin which was
invented in 2008 by a person known as Satoshi Nakamoto [8].
In a nutshell, the blockchain is briefly explained as public,
trusted and shared ledger based on a peer-to-peer network.
This emerging technology has also recently become a hot topic
for researchers and been argued to innovate blockchain-based
applications beyond Bitcoin. The core idea of the blockchain
network is decentralization which means blockchain is dis-
tributed over a network of nodes. Each node has the possibility
of verifying the actions of other entities in the network, as
well as the capability to create, authenticate and validate
the new transaction to be recorded in the blockchain. This
decentralized architecture ensures robust and secure operations
on blockchain with the advantages of tamper resistance and
no single-point failure vulnerabilities. Basically, blockchain
can be classified into two main categories, including public
(or permission-less) and private (or permissioned) blockchain.
A public blockchain (e.g., Bitcoin platform) is an open net-
work which means it is accessible for everyone to join and
make transactions as well as participate in the consensus
process. Meanwhile, private blockchain is an invitation-only
network managed by a central entity and all participations in

blockchain for submitting or writing transactions have to be
permissioned by a validation mechanism. A general concept
on how blockchain operates is presented in Fig. 4 and the most
popular and promising blockchain platforms are summarized
in Table II.

A blockchain network is built from some key components,
including data block, distributed ledger, consensus, and smart
contracts. To be clear, each block contains a number of trans-
actions and is linked to its immediately-previous block through
a hash label. In this way, all blocks in the chain can be traced
back to the previous one, and no modification or alternation
to block data is possible [39]. A distributed ledger is a type
of database which is shared and replicated among the entities
of a peer-to-peer network. Moreover, blockchain consensus
is a process used to reach agreement on a single data block
among multiple unreliable nodes, aiming to ensure security in
a blockchain network. Final, smart contracts are programmable
applications that run on a blockchain network according to
predefined contractual conditions such as payment terms, liens,
confidentiality, and even enforcement [40].

Blockchain can provide high-security properties for its
applied scenarios, such as CoT. The most important fea-
ture is decentralization which means blockchain does not
rely on a central point of control to manage transactions.
This exceptional property brings promising benefits, including



IEEE COMMUNICATIONS SURVEYS & TUTORIALS 5

TABLE II: Popular blockchain platforms.

Platforms Consensus Operation Modes Smart contract
support?

Programming
language

Latest version Open source?

Bitcoin PoW Public Yes Ivy, RSK, BitML v0.18.0, May. 2019 Yes [29]
Ethereum PoW, PoS Public and permissioned Yes Solidity, Flint,

SCILLA
v1.8.27, Apr. 2019 Yes [30]

Hyperledger PBFT Permissioned Yes Go, Node.js,
Java

v2.0 Alpha, Apr. 2019 Yes [31]

IBM Blockchain PoW, PoS Permissioned Yes Go, Java v2.0, Jun. 2019 Yes [32]
Multichain PBFT Permissioned No C++, Go, Java,

Python, PHP
beta 2.0, Mar. 2016 Yes [33]

Hydrachain PoW, PoS Permissioned Yes Python hydrachain 0.3.2, 2018 Yes [34]
Ripple PoW Permissioned Yes C++ v1.2.4, Apr. 2018 Yes [35]

R3 Corda PoW, PoS Permissioned Yes Kotlin, Java V4.0, Feb. 2019 Yes [36]
BigChainDB BFT Public and permissioned Yes Java v2.0.0b9, Nov. 2018 Yes [37]
Openchain Partionned Permissioned Yes C++, Java v0.7.0, Nov. 2017 Yes [38]

 

 

 

 

An blockchain entity 

(i.e. a computer) 

requests a transaction.

The transaction is 

broadcast to all nodes 

in the P2P network.

P2P network of nodes

The network of nodes validates 

the transaction using public key 

cryptography.

Verified transaction 

(i.e. contract, record)

The verified transaction is 

linked to other transactions to 

create a new data block.

A new block is appended 

to the existing blockchain.The transaction 

is complete.

Old blocks New block

Fig. 4: The concept of blockchain operation.

eliminating single point failure risks due to the disruption
of central authority, saving operational costs and enhancing
trustworthiness. Further, blockchain is able to keep transaction
data immutable over time. The hashing process of a new block
always contains metadata of the hash value of the previous
block, which makes the chain strongly unalterable. In this
way, it is impossible to modify, change or delete data of the
block after it is validated and placed in the blockchain. Another
important feature is transparency which stems from the fact
that all information of transactions on blockchain is viewable
to all network participants. In other words, the same copy of
records of blockchain spreads across a large network for public
verifiability. As a result, all blockchain users can fully access,
verify and track transaction activities over the network with
equal rights.

In addition to these security benefits, blockchain remains
some problems that need to be considered to make it well
suitable for integrating with CoT. For example, how to achieve
energy efficiency for blockchain in BCoT applications is an
important issue. The decentralized consensus algorithms in
blockchains often require extensive processing power and
high computing energy to mine blocks and maintain the
blockchain network. This makes blockchain infeasible to
resource-constrained IoT devices in CoT applications. Al-
though we can perform energy-intensive blockchain mining
in a centralized cloud, this would essentially negate the
advantages of a distributed CoT system. Another issue is
the throughput of blockchain systems. In fact, blockchain
has much lower throughput in comparison to non-blockchain
applications. For example, Bitcoin is able to execute a max-
imum of only four transactions/second, and the throughput

of Ethereum achieved is about 20 transactions/second, while
Visa can process up to 1667 transactions/second [24]. Clearly,
the existing blockchain networks still remain scalability bot-
tlenecks in terms of the number of replicas and limited
throughput. Many current blockchain systems suffer from
high block generation time which in turn reduces the overall
blockchain throughput. Further, if all transactions are stored
in a chain, the blockchain size will become very large [41].
Considering real-world CoT scenarios, e.g., smart cities, the
IoT data volume is enormous and thus will result in a rapid
growth in the IoT blockchain size. These factors thus should
be taken into account in designing blockchain platforms for
sustainable BCoT applications.

2) Cloud of Things: Nowadays, IoT has constituted a
fundamental part of the future Internet and drawn increasing
attention from academics and industries thanks to its great
potentials to deliver exciting services across various appli-
cations. IoT seamlessly interconnects heterogeneous devices
and objects to create a physical environment where sensing,
processing and communication processes are implemented
automatically without human involvement. However, massive
volumes of data generated from a large number of devices
in current IoT systems become a bottleneck in guaranteeing
the desired Quality of Service (QoS) because of constrained
power and storage resources of IoT devices. Meanwhile, cloud
computing has unlimited resources in terms of storage and
computation power, which can provide on-demand, powerful
and efficient services for IoT use domains. Especially, the
convergence of cloud computing with IoT paves the way for
a new paradigm as CoT, which can empower both worlds.
Indeed, the wealth of resources available on the cloud is
highly beneficial to IoT systems, while cloud can gain more
popularity in real-life applications from integrating with IoT
platforms [61]. Moreover, CoT can transform current IoT
service provision models with minimal management effort,
high system performance and service availability. The general
concept of CoT is shown in Fig. 5 with a network architecture
of IoT devices, cloud computing, analytic services and appli-
cation layer. In this hierarchy, IoT devices are used to sense
and collect data from local environments. However, due to
their limited computing resources, IoT devices will transmit
recorded data to the cloud for data acquisition. Cloud com-
puting can provide a powerful capability of data processing



IEEE COMMUNICATIONS SURVEYS & TUTORIALS 6

Data sensing 
and collection 

protocols

Internet/Cloud 
network

IoT devices Services

Applications

Smart sensor

RFID reader

Smart meter

Smart camera

Cloud computing

Fig. 5: The general concept of CoT.

and storage. Analytic services can be provided to support IoT
systems, such as historic data monitoring, information storage
or statistical analysis. The results of cloud data processing are
used to serve end applications, aiming to facilitate IoT service
provisions and meet requirements of end users.

In general, the CoT platform can offer instant services to
users anywhere and anytime thanks to automatic resource pro-
vision capabilities of cloud computing. It enables autonomous
service delivery without the need for human engagement. With
unlimited virtual processing capabilities of cloud computing,
CoT open up new opportunities to enhance IoT computation
by enabling data offloading and executing data remotely. This
not only improves computation abilities of local devices, but
also addresses effectively issues of IoT systems in terms
of energy-saving and bandwidth preservation. Importantly,
CoT can offer simplified and automatic IT maintenance and
management solutions by exploiting cloud servers, virtual ma-
chines and resource infrastructure. IoT users can interact easily
with cloud computing to implement functionalities without
any requirement for software installation as well as human
involvement. Moreover, the provision of system management
models available on clouds also supports well boundless
communications and interconnections between IoT devices
together, between things and users to empower ubiquitous
applications, which would promote the comprehensive collab-
orations of multiple IoT ecosystems in the future Internet.

B. Motivation of the Integration of Blockchain and CoT

In this subsection, we highlight the motivation of the
integration which comes from the security challenges of CoT,
technical limitations of blockchain and the promising opportu-
nities brought by the incorporation of such two technologies.

1) Security Challenges in CoT: CoT support ubiquitous
computing services with large data storage and high system
performance, but still remains some critical challenges [42],
[43] as below.

Data availability: In the current cloud network architec-
tures, cloud services are provided and managed centrally
by the centralized authority. However, this configuration is
vulnerable to single-point failures, which bring threats to the
availability of cloud services for on-demand IoT access. A
centralized cloud IoT system does not guarantee seamless
provisions of IoT services when multiple users request simul-
taneously data or cloud servers are disrupted due to software
bugs or cyber-attacks.

Privacy management: Although the centralized cloud IoT
can provide convenient services, this paradigm raises critical
data privacy concerns, considering a large amount of IoT data
being collected, transferred, stored and used on the dynamic
cloud networks. In fact, IoT users often place their trust in
cloud providers managing the applications while knowing very
little about how data is transmitted and who is currently
using their information [44]. Even in the distributed cloud
IoT paradigms with multiple clouds, IoT data are not fully
distributed but stored in some cloud data centres at high
density [45]. In this context, IoT data may be leaked if one of
the cloud servers is attacked.

Data integrity: The storage and analysis of IoT data on
clouds may give rise to integrity concerns. Indeed, due to
having to place trust on the centralized cloud providers,
outsourced data is put at risks of being modified or deleted
by third parties without user consent. Moreover, adversaries
can tamper with cloud data resources for financial or polit-
ical purposes [46], all of which can breach data integrity.
For these reasons, many solutions using public verification
schemes based on a third-party auditor have been proposed,
but they potentially raise several issues, including irresponsible
verification to generate bias data integrity results or invalidated
verification due to malicious auditors. Therefore, developing
new solutions to solve efficiently data integrity challenges is
vitally necessary for CoT systems.

2) Technical Limitations of Blockchain: Although
blockchain has its unique promise to disrupt services
like CoT, it still remains several critical challenges in its
development in terms of complexity, and security flaw.

Complexity: In IoT networks, in order to implement valida-
tion on transactions, IoT devices act as blockchain participants
to run the consensus process to solve complex mathemati-
cal puzzles, which requires powerful computation hardware.
Unfortunately, this is challenging to meet such requirements
due to the constraints of IoT resources. Even in the case of
IoT devices with relatively high computing capacities, running
complex blockchain process may require intensive resources
involving electricity and human management. This would raise
concerns of users about high operational costs which would
hinder wide deployment of blockchain-based systems.

Security flaw: The final limitation of current blockchains
may be an unavoidable security flaw. If more than half of
computers working as blockchain nodes to control computing
power, attackers may modify consensus architectures and
prevent new transactions from obtaining confirmations for
malicious access. This is also called as 51% attack which is
highlighted in the Bitcoin concept. Without having a com-
prehensive transaction management, blockchain can be put at
risks of data breach and system damage.

In short, the decentralization of CoT lays the ground
for blockchain as data security and privacy solutions, and
blockchain can leverage the cloud resources in CoT for
intensive mining computations and reliable data storage.

3) The Opportunities of Integration of Blockchain and CoT:
Based on complementary roles of blockchain and CoT as
well as their potential advantages, the incorporation of such



IEEE COMMUNICATIONS SURVEYS & TUTORIALS 7

disruptive technologies opens up a wide range of BCoT
opportunities, as summarized in the following.

Decentralization management: Motivated by the fully de-
centralized nature of blockchain, it is possible to build a
decentralized BCoT management architecture under the dis-
tributed control of peer-to-peer network of cloud nodes and
IoT d";"""date"",""2020-08-31T00:24:34Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2020-08-31T00:24:34Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016) kpathsea version 6.2.2""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2020-08-31T00:24:34Z""
""created"",""2020-08-31T00:24:34Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-08-31T00:24:34Z""
""resourceName"",""1908.09058""
""Author"",""""
""producer"",""pdfTeX-1.40.17""
""pdf:docinfo:producer"",""pdfTeX-1.40.17""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2020-08-31T00:24:34Z""
""Last-Modified"",""2020-08-31T00:24:34Z""
""dcterms:modified"",""2020-08-31T00:24:34Z""
""title"",""""
""Last-Save-Date"",""2020-08-31T00:24:34Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2020-08-31T00:24:34Z""
""meta:save-date"",""2020-08-31T00:24:34Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016) kpathsea version 6.2.2""
""Content-Length"",""2221548""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""29""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""5210"",""4388"",""4438"",""3247"",""4995"",""5201"",""5599"",""5553"",""2577"",""5484"",""4567"",""5518"",""4797"",""5627"",""3803"",""5629"",""5484"",""4286"",""4659"",""5199"",""5209"",""5419"",""5668"",""6835"",""7704"",""7697"",""7901"",""7417"",""2148""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-08-31T00:24:34Z""
";https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095409-1736;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Smart Contracts for Service-Level Agreements in Edge-to-Cloud Computing;P Kochovski, V Stankovski, S Gec, F Faticanti… ; Journal of Grid …, 2020  Springer;;"… The Smart Oracles are trusted third-party services that pro- vide means for SCs to communicate

with reg- istered APIs from the external services … In order to estimate an optimal deployment option,

this layer queries a Smart Oracle from the Blockchain Layer to retrieve …";Cité 3 fois;;null;;;;https://scholar.google.com/scholar?start=540&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095397-1685;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;CHANGES IN THE PROFESSIONAL PROFILE OF AUDITORS IN THE LIGHT OF BLOCKCHAIN TECHNOLOGY;U Hayrettin, G KARABURUN ; European Journal of Digital Economy …, 2020  ejderhub.com;;"… that is secured and verified according to blockchain technology is automated (Smith, 2018, s.

132). However bugs or embedded codes can compromise the integrity of the data. Auditors want

to evaluate the client's procedures to determine this situation. Oracles are a third-party …";Cité 1 fois;Les 3 versions;[PDF] ejderhub.com;http://www.ejderhub.com/index.php/ejder/article/download/2/13;"
Original Paper European Journal of Digital Economy Research  
2020 Vol.1 Issue.1 pp.5-12 

 

5 

 

CHANGES IN THE PROFESSIONAL PROFILE OF AUDITORS IN THE LIGHT OF 
BLOCKCHAIN TECHNOLOGY  

 

 

Hayrettin USUL*, GĂśzde KARABURUN** 

*  Prof. Dr., İzmir Kâtip Çelebi University, Faculty of Economics and Administrative Sciences, Business Administration, 

hayrettin.usul@ikc.edu.tr, https://orcid.org/0000-0002-3930-0866. 

**  Corresponding Author, Ph.D. Candidate, İzmir Kâtip Çelebi University, Social Sciences Institute, gozdekaraburun@gmail.com, 
https://orcid.org/0000-0002-9443-4146. 

 

ABSTRACT 

Blockchain is a shared ledger technology. In other words, blockchain technology is a shared and immutable notebook. This 

technology is used to record transactions, track assets and build trust. All transactions are stored encrypted by all stakeholders 

in the blockchain network. Auditing of these transactions is the domain of the auditors. The dynamics of auditing are changing 

with the developing technology. As a reflection of blockchain technology, professional profiles of auditors are also changing. 

The purpose of this study is to discuss the change in professional profiles of auditors in the light of blockchain technology. 

Keywords: Blockchain Technology, Accounting, Auditing, Auditor. 

Jel Codes: M40, M41, M42. 

In this study, research was conducted on blockchain 

technology, audit and auditors. First, a literature 

review was conducted. Then, information about 

blockchain technology and blockchain control was 

given. Finally, the effect of blockchain technology 

on auditors was discussed and changes in profession 

profiles are discussed. 

1. INTRODUCTION 

All transactions performed in the blockchain are 

recorded by everyone on the network. Anyone on 

the blockchain network can view actions taken. 

However, during the transactions performed on the 

system, the identity of the person doing the 

transaction is hidden from those who can view the 

transaction. With this feature, blockchain 

technology enables to verify transactions without 

any brokerage house. 

Auditing is an accounting branch developed to 

reach an opinion about the accuracy of accounting 

documents, data and information. Data is obtained 

as a result of the operations performed with 

blockchain technology, too. Along with the 

developing technology, the dynamics of auditing 

are changing as well. Auditors performing the 

auditing profession are affected by this change. In 

particular, the approach to audit evidence has 

changed. In this case, auditors face many threats and 

opportunities. Considering the changing auditor and 

client’s relationship, the effects of blockchain 

technology on auditor profession become more of 

an issue. 

2. LITERATURE REVIEW 

Blockchain technology has been the subject of 

many articles in the national and international 

context. Some articles in the field of Social Science 

are given below in alphabetical order. 

In his study, Demirhan (2019) examined blockchain 

technology as a new approach in tax auditing. As a 

result of his research, he has reached that the 

blockchain will be highly effective in tax auditing 

in the future. Demirhan concluded that blockchain 

would take an active role in the tax collection and 

the fight against black economy. 

In their study, Doğan & Ertugay (2019) discussed 

blockchain and applications in the field of 

accounting. As a result, they stated that the financial 

data to be generated through blockchain will 

provide significant benefits to both businesses and 

other financial report users. 

In his study, Şat (2019) examined blockchain’s 

potential impact on public administration. As a 

result, Şat argued that the organizations should 

equip themselves with new visions, and they should 

train public administrators and civil servants who 

would create public value. 

In their study, Şen & Alnıaçık (2019) investigated 

the effects of blockchain technology on 

management processes. As a result, the expectations 

of the business world and the managetment area 

regarding blockchain technology have been 

determined. 

mailto:hayrettin.usul@ikc.edu.tr
https://orcid.org/0000-0002-3930-0866
https://orcid.org/0000-0002-9443-4146


USUL – KARABURUN 

6 

In their study, Şen & Ergin (2019) investigated the 

rise of cryptocurrencies, the blockchain network 

and bitcoin. As a result, they argued that even if 

there are no cryptocurrencies and bitcoin, 

blockchain has a wide range of uses. 

In her study, Tekin Bilbil (2019) examined local 

governments and blockchain technology. Tekin 

Bilbil also proposed a governance design / strategy 

at the same time. As a result, her study revealed that 

there is the lack of information regarding 

blockchain technology in local administrations. 

In their study, Uğur, Güler, Yıldırım, & Kurubacak 

(2018) examined the use of blockchain and strategic 

decision model for transhumanist learners in open 

and distance learning environments. As a result, 

they have demonstrated the importance of the 

strategical decision model in ensuring 

sustainability. 

In his study, YÄąldÄąrÄąm (2018) examined the 

relationship between blockchain technology and the 

potential of blockchain technology in literature. As 

a result, YÄąldÄąrÄąm expressed the importance of 

spreading the potential of blockchain technology to 

all areas. 

 

3. BLOCKCHAIN TECHNOLOGY AND 

AUDITING 

This section contains information about the 

definition and audit of the blockchain. It also 

includes the qualification of audit evidence, which 

plays an important role in blockchain auditing. 

Finally, the threats and opportunities of blockchain 

control are included. 

3.1. Definition of Blockchain 

Blockchain, which holds the power of changing and 

reshaping the accounting profession, is a technology 

that records, processes and stores financial 

transactions (Liu, Wu, & Xu, 2019, s. A19). 

Blockchain technology gives management 

professionals and auditors access to secure 

information in a real time (Smith, 2018, s. 131). 

Blockchain technology performs transactions 

within a work discipline. 

The blockchain working principle has five main 

characteristics. These are request, notification, 

verification, insertion and distribution. It all starts 

with the request of a user to add a transaction to the 

blockchain. This transaction is broadcast to all users 

via notification. The transactions are verified by 

users in the verification step. It is then bundled into 

blocks. The bundled blocks are added to the 

blockchain and become permanent. Finally, an 

updated copy of the blockchain is received by those 

on the network (Mahbod & Hinton, 2019, s. 23). 

Blockchain records are tamper-resistant thanks to 

the deployed cryptographic mechanisms. These 

code-protected records are irreversible. The hash of 

the record contains the digital signature of the user. 

Therefore, the originator of the recording can be 

determined (Rozario & Thomas, 2019, s. 24). 

Blockchain technology has different usage areas. 

An encrypted message is created by an individual 

who wants to transfer funds in the blockchain 

system. This message contains information about 

the recipient's network address. The validity of the 

message posted to the entire network is examined 

by other members. The message posted in the 

network compares to the latest balance recorded in 

the sender's blockchain by other members. 

Execution of the process depends on the verification 

of the message. After the message is verified, a new 

block is added to the end of the blockchain. This 

block contains the transaction (Liu, Wu, & Xu, 

2019, s. A20). 

3.2. Auditing the Blockchain 

There is uniformity in the blockchain. With 

uniformity, audit preparation activities and manual 

data extraction are eliminated (Mahbod & Hinton, 

2019, s. 26). 

Auditors ensure data reliability by designing and 

implementing audit tasks. The auditor obtains 

sufficient and appropriate evidence to determine 

whether there are material misstatements. 

(Appelbaum & Nehmer, 2017, s. 6). 

Reliable evidence is evidence that can be trusted and 

verified by the auditor. The audit team that collects 

and evaluates sufficient audit evidence arrives at an 

opinion. All the information on which the audit 

opinion is based by the auditor is evidence of audit. 

Evidence is obtained from both external and internal 

sources (Appelbaum & Nehmer, 2017, s. 6). 

Confirmations are an inseparable part of traditional 

auditing. This routine will not be needed for the 

information stored and examined on the blockchain 

(Smith, 2018, s. 128). The cleaning and 

classification of information that is secured and 

verified according to blockchain technology is 

automated (Smith, 2018, s. 132). However bugs or 

embedded codes can compromise the integrity of 

the data. Auditors want to evaluate the client's 

procedures to determine this situation. Oracles are a 

third-party information source. They should be 

properly linked (logically) to smart contracts. 



 Changes In The Professional Profile of Auditors In The Light of Blockchain Technology 

 

7 

Auditors should evaluate the physical control of 

Internet of Things devices. (Sheldon, 2019, s. A21). 

In case the initial entry or source of the chain is 

suspicious, the auditor will need to physically 

validate the originating event. This physical validate 

takes place through verification, observation and 

recalculations-reperformance (Appelbaum & 

Nehmer, 2017, s. 13). Notable items can be 

manually investigated by the auditor. In records that 

require further investigation, a follow-up smart 

audit procedure can be pre-programmed (Rozario & 

Thomas, 2019, s. 25). 

3.3. Audit Evidence in Auditing Blockchain 

Audit evidence is obtained and stored from a variety 

of sources. Auditors overcome the obligation to 

combine both financial and non-financial 

information with blockchain. Audit evidence is 

taken from the client’s blockchain by the auditor. 

This information is sent to the hash of smart audit 

procedures. Finally, the predefined audit test is 

performed by the smart audit procedure (Rozario & 

Thomas, 2019, s. 31). 

The transaction data from Blockchain is high-

quality audit evidence. Because it is confirmed that 

the transactions take place once. If the auditor wants 

to confirm accounts, they only need to get the 

relevant transaction data from the blockchain. They 

then perform analytical procedures (Wang & 

Kogan, 2018, s. 4). If block of transactions is 

completed and added to the end of the blockchain, 

it cannot be reversed. Thanks to cryptography and 

decentralization features, the auditor is provided 

with a tamper-resistant audit trail. These features 

help improve the integrity of internal and external 

data (Rozario & Thomas, 2019, s. 23). With the 

increase in the number of entities that adopt 

blockchain, the information to be obtained from the 

blockchain will become efficient (Mahbod & 

Hinton, 2019, s. 26). 

Schemes that guarantee data privacy are 

recommended. These schemes, managed by a 

trusted third-party auditor, have the ability to 

centralization. The downside of centralization is 

that it reduces the security of the auditing protocol. 

Instead, a scheme supporting decentralized auditing 

is proposed (Fan, Bao, Liu, Vasilakos, & Shi, 2019, 

s. 7). 

Evidence provided by a continuous real-time audit 

frees the auditor from the observation task. Auditors 

only need to observe the timestamp of transactions 

added to the block. They can also observe whether 

the lengths of blocks increase over time 

(Appelbaum & Nehmer, 2017, s. 9). Nevertheless, 

auditors who will develop procedures to obtain 

audit data directly should consider the risks. At the 

top of these risks is the risk that the information may 

be inaccurate due to error or fraud (Mahbod & 

Hinton, 2019, s. 26). 

3.4. Threats and Opportunities in Auditing 

Blockchain 

There are some threats and opportunities in 

blockchain auditing. A high degree of transparency 

is achieved as a result of digitization. So, auditors 

can encounter clients’ resistance (Tiberius & Hirth, 

2019, s. 5). Control of the blockchain of peer nodes 

operating on the same cloud can be attempted to be 

taken control or rewritten by fraudsters. The auditor 

should consider this added risk (Appelbaum & 

Nehmer, 2017, s. 11). 

Changes in the world of technology happen quickly. 

With the blockchain technology, customer risks also 

change. The ability to respond to these changes and 

risks is considered an opportunity for auditors 

(Rozario & Thomas, 2019, s. 21). The routines of 

audits and their close proximity to real time will 

provide auditors with opportunities. Focusing on 

risky and complex transactions can be counted from 

these opportunities (Mahbod & Hinton, 2019, s. 26). 

Confirmations, inventory counting, and data 

analysis are among the audit components. 

Confirmations before the blockchain were random. 

Confirmations after blockchain technology have 

become 100% and real-time. While inventory 

counting is done manually in the pre-blockchain, it 

is carried out continuously in the post-blockchain. 

Finally, data analysis is addressed. While sampling 

methodology is used in pre-blockchain, continuous 

and for 100% of information are used in post-

blockchain (Smith, 2018, s. 128). 

Using blockchain technology in business processes 

reduces the audit workload. It gives auditors a 

chance to focus on other operations (Karahan & 

TĂźfekci, 2019, s. 67). Ethereum is an operating 

system built on a neutral, open access infrastructure, 

stating that it is not controlled by any company or 

person (Ethereum, 2020). Ethereum has a consensus 

feature. Therefore, the auditing process is more 

secure and transparent than the traditional auditing 

protocol (Fan, Bao, Liu, Vasilakos, & Shi, 2019, s. 

7).  

Decentralization, immutability, and accountability 

are the most important features of blockchain. Due 

to the decentralization, fraud on the blockchain is 

unlikely to occur. Immutability is achieved by the 



USUL – KARABURUN 

8 

cryptographic mechanism being employed. 

Accountability is achieved by verifying the source 

of the transaction performed with the digital 

signature of the user by the auditor (Rozario & 

Thomas, 2019, s. 23). Although blockchain 

technology removes the need for current auditors, it 

can create new opportunities for the audit profession 

(Uçma Uysal & Kurt, 2018, s. 478). 

 

4. CHANGES IN THE PROFESSIONAL 

PROFILE OF AUDITORS  

This section discusses the effects of blockchain 

technology on the audit profession. Changing 

auditor and customer relationships are also included 

in this section. Finally, the phenomenon of 

blockchain controllers as a concept is discussed. 

4.1. Effects of Blockchain Technology on 

Auditing Profession 

People who carry out audit work and turn this 

function into a profession are called auditors. 

Auditors are examined in three parts in accounting 

audit application. These are external auditors, 

internal auditors and public auditors (Usul, 2015, s. 

25). Since external auditors and internal auditors are 

the subject of this study, they will be examined in 

detail. 

If we look at the technological developments, it is 

seen that the accounting profession is in the middle 

of a transformation (Smith, 2018, s. 118). Auditors 

can be more innovative and efficient with 

blockchain (Mar, 2018, s. 17). Intelligent audit 

procedures provide auditors with the opportunity to 

improve audit quality while automating audit tasks 

(Rozario & Thomas, 2019, s. 26). 

The high level of trust in the information obtained 

from blockchain technology is due to the fact that 

each transaction performed with this technology 

becomes as notarized on the level of authenticity. 

Auditors have an important and fundamental role. 

Auditors should determine the authenticity of the 

first transaction with the object under consideration. 

All subsequent transactions will be considered to be 

accomplished and reliable (Melnychenko & 

Hartinger, 2017, s. 33). 

Blockchain technology affects the audit profession 

and therefore the auditors. The effects of blockchain 

technology on the audit profession can be examined 

from the perspective of internal auditors and 

external auditors.  

 

4.2. Internal Auditors 

The focus of traditional accounting information 

systems is to increase security. This security covers 

the collection and reporting of financial 

information. The problem of not obtaining 

information on time is frequently mentioned by 

internal auditors, or in other words, information is 

not available on time. A large amount of energy is 

spent by internal accounting to verify and clear the 

data (Smith, 2018, s. 121). 

New risks and opportunities brought by blockchain 

technologies are the main points that internal 

auditors should focus on. Blockchain technology 

sets business objectives. As with any new 

technology, internal auditors should evaluate 

internal and external risks towards these business 

objectives. Internal auditors should examine 

whether appropriate measures are taken, such as 

timelines and staff, to reduce their clients’ risks. 

Blockchain technology has its own security 

measures. However, internal auditors should test the 

system. Millions of transactions are written 

simultaneously in the blockchain. In the meantime, 

fast and timely acquisition of data should be handled 

by internal auditors. Availability risks should not be 

ignored since the design stage. The security of 

authorizations granted to users in terms of 

confidentiality risks should be tested (Mar, 2018, s. 

17). 

Internal auditors are expected to be open to 

blockchain technology. They must understand the 

opportunities and threats that this new technology 

will bring. Auditors should be prepared for future 

destructive changes (Karahan & TĂźfekci, 2019, s. 

70). Internal audit professionals will want to take 

advantage of new methods and tools. Because they 

will need to verify the structure and viability of 

blockchain networks. They will also need to assess 

the appropriateness and effectiveness of risk 

mitigation efforts associated with blockchain 

transactions (Kloch & Little, 2019, s. 5). 

4.3. External Auditors 

The trusted third-party auditor is empowered by the 

public auditing authorizes to audit external data 

(Fan, Bao, Liu, Vasilakos, & Shi, 2019, s. 1). The 

auditors act independently in the client’s 

blockchain. They can access all the internal and 

external blockchain information that belongs to the 

client. The auditor is a node on the client’s 

blockchain. In this way, they can extract 

information about the audit and execute smart audit 

procedures autonomously (Rozario & Thomas, 

2019, s. 29). The possibilities of the external audit 



 Changes In The Professional Profile of Auditors In The Light of Blockchain Technology 

 

9 

blockchain can be listed as follows: improving the 

quality of the audit and minimizing the difference in 

expectations among stakeholders (Rozario & 

Thomas, 2019, s. 21). 

The auditing protocol is another important issue in 

the audit process of blockchain technologies. 

Decentralized auditing protocol becomes more 

reasonable due to the difficulty of finding an honest 

organization (Fan, Bao, Liu, Vasilakos, & Shi, 

2019, s. 2). 

External auditors face problems with data 

cleanliness and availability. It is one of the problems 

facing external auditors to not present the 

information in a convenient timeframe for the 

annual audit process. Lack of audit efficiency 

occurs as a result of all these problems. At the same 

time, lack of audit efficiency results from lag and 

lack of availability (Smith, 2018, s. 122). 

4.4. Changing Auditor and Client Relations 

Regardless of whether they pay for the audit service, 

shareholders, lenders, financial analysts and other 

stakeholders can be regarded as auditors’ actual 

clients (Tiberius & Hirth, 2019, s. 4).  

Evolving blockchain technologies create an 

ecosystem. Proactive audits are advantageous in this 

ecosystem. Because the auditor has the ability to 

view and extract reliable information from the 

client’s blockchain (Rozario & Thomas, 2019, s. 

27). 

Block chain is an evolving technology. There is a 

balance between a proven and mature technology 

solution and early blockchain adopter. In other 

words, blockchain is not the solution for every 

scenario. This situation should be reminded to the 

clients by the auditors (Sheldon, 2019, s. A27). 

The gap between information provided by auditors 

to investors and users of financial statements and the 

information they need needs to be explored 

(Rozario & Thomas, 2019, s. 23). Against the 

expectation gap, auditors should apply rigor when 

evaluating executives’ statements about future risks 

(Tiberius & Hirth, 2019, s. 4). 

4.5. New Type of Auditors: Blockchain Auditors 

Concept (The Future of Auditors: Blockchain 

Auditors) 

Auditors affect the systems of the audited 

institutions. As the needs of the business world 

change rapidly, auditors will have to be aware of 

and adopt blockchain technology (Mahbod & 

Hinton, 2019, s. 27). With the blockchain 

technology, the profile of the auditors will change. 

The potential effects of blockchain on the 

profession will be realized in two ways: forward 

looking and become more IT oriented (Brender, 

Gauthier, Morin, & Salihi, 2019, s. 35).  

It will be possible for auditors to focus more on 

issues that require judgment through digitalization 

(Tiberius & Hirth, 2019, s. 9). Audit process and 

auditors will change depending on the 

developments in blockchain technology. The data is 

embedded in the blockchain. Auditors will have the 

ability to export this data. They will also be able to 

understand this exported data. With the blockchain 

technology, the need for auditors in confirmation 

and verification will decrease. This will make it 

easier for auditors to focus on high-level duties  

(Smith, 2018, s. 134). 

Blockchain technology has brought transparency to 

the audit profession with an immutable ledger and 

real-time audit potential (Sheldon, 2019, s. A15). 

The adequacy of cryptography arrangements used 

to hide the database on the network has gained 

importance in the control of blockchain technology 

(Mar, 2018, s. 18). Auditors must be competent to 

supervise technological developments. 

Although the data in the blockchain is protected 

from tamper-proof, it is vulnerable to risks while 

outside the blockchain. Auditors and clients should 

work together to transfer data out of the blockchain. 

It should determine together that the data transfer 

will be realized in the most controlled and most 

convenient way (Sheldon, 2019, s. A20). 

According to the research from Germany, the 

auditors predict that the annual audit will progress 

towards a continuous audit approach. According to 

experts, new technology will not replace auditors. 

They believe that the new technology will provide 

them with more relief and support (Tiberius & 

Hirth, 2019, s. 1). 

Auditors will test the controls on the evidence. They 

will perform these tests to determine their 

authenticity and reliability (European Court of 

Auditors, 2020, s. 47). Even if the audit process 

becomes more continuous, auditors will need to 

apply professional judgment when examining other 

judgments made by management. Auditors will 

need to evaluate and test internal controls in 

automated areas (CPA & AICPA, 2017, s. 11). 

Some tests and tasks do not require specific 

technical skills. These will disappear in favor of 

analysis that requires expertise and experience 



USUL – KARABURUN 

10 

(Brender & Gauthier, Impacts of blockchain on the 

auditing profession, 2018, s. 30). 

When the blockchain is applied, the auditor will 

have more time to focus on high-level problems 

(ICAEW, 2018, s. 6). Auditors will be able to 

discover and visualize deviations that deserve closer 

scrutiny (European Court of Auditors, 2020, s. 69). 

The focus of the auditors will be to validity the 

digital representation of physical assets and 

codification of contracts in conjunction with 

accounting standards (EY, 2017, s. 4). 

With the widespread use of blockchain, auditors 

should provide more complex assurance services. 

They will need to make progress to support future 

digital transformations (Psaila, 2017, s. 3). With the 

use of blockchain, auditors who can access their 

clients' data in real time will analyze the data. In this 

way, the level of assurance and the quality of the 

audit will increase (Brender & Gauthier, Impacts of 

blockchain on the auditing profession, 2018, s. 30). 

The auditor who receives the data from the 

blockchain should evaluate whether the data is 

reliable. At the same time, auditors should consider 

audit procedures on management's estimates. They 

will need to perform audit procedures on 

management's estimates (CPA & AICPA, 2017, s. 

10). In addition, against the risk of fraud, auditors 

will need to determine whether internal controls 

operate effectively (Psaila, 2017, s. 3). According to 

the findings in the report of the European Court of 

Auditors, auditors will need to be more adaptable to 

change in future (European Court of Auditors, 2020, 

s. 24). 

According to the study conducted by Brender, 

Gauthier, Morin, & Salihi, auditors think that the 

audit activity will change in the med-term. They 

predicted that today's financial auditors will replace 

auditors with specific IT skills such as 

programming. Some even mentioned IT engineer 

auditors while others mentioned  blockchain 

auditors whose function will be to certify 

blockchain (Brender, Gauthier, Morin, & Salihi, 

2019, s. 15). 

When adopting blockchain technology, auditors 

will be able to use their professional judgment with 

more analytical methods. The levels of 

independence and professional judiciary will 

become even more important (Jackson, 2018, s. 34). 

Auditors will apply to blockchain technology to test 

the whole population of transactions within the 

period under observation. Thus, sample-based 

substantive test days are expected to be challenged 

(Psaila, 2017, s. 1). Auditors can develop software 

using the blockchain. In this way, more than one 

organization can be continuously audited (Mahbod 

& Hinton, 2019, s. 26). 

 

5. CONCLUSION 

Blockchain is seen as an important part of a huge 

wave of digital revolution. This wave of digital 

revolution also affects the audit process and 

auditors. Considering the effects of blockchain 

technology on auditing and auditors, the 

phenomenon of change is outstanding. Based on 

this change, changing professional profiles of 

auditors are discussed in the light of blockchain 

technology. 

As a result of the researches, it can be interpreted 

that the audit profession has changed, especially in 

the stage of collecting evidence and performing the 

audit. Thanks to blockchain, every transaction is 

recorded by everyone on the blockchain network 

and this data cannot be changed. This is also 

important for audit evidence. Auditors acting 

independently on the client's blockchain can access 

client's internal and external blockchain 

information. Auditors who obtain the evidence take 

this into account when evaluating the audit 

evidence. According to the audit evidence obtained 

in traditional ways, the data in blockchain is more 

reliable and transparent. However, although they 

are shared with everyone on the blockchain 

network, clients may not be willing to share this data 

with auditors. 

While performing the audit and in the relations with 

the clients, the auditors encounter differences 

compared to the traditional system. With the 

developing and changing technology, the 

professional profiles of the auditors are also 

changing. This may create a new competence area 

and title opportunity for the auditors. With this 

approach, auditors can be called blockchain 

auditors. As a result, these auditors, who will have 

an interdisciplinary understanding, are expected to 

have competence in both auditing and technology. 

 

REFERENCES 

 

1. APPELBAUM, D. & NEHMER, R. (2017). 

“Designing and Auditing Accounting Systems 

Based on Blockchain and Distributed Ledger 

Principles”, Feliciano School of Business, pp. 1-19. 



 Changes In The Professional Profile of Auditors In The Light of Blockchain Technology 

 

11 

2. BRENDER, N. & GAUTHIER, M. (2018). 

“Impacts of Blockchain on The Auditing 

Profession”, ISACA JOURNAL, 27-32. 

3. BRENDER, N., GAUTHIER, M., MORIN, J. & 

SALIHI, A. (2019). “The Potential Impact of 

Blockchain Technology on Audit Practice”, Journal 

of Strategic Innovation and Sustainability, pp. 35-

59. 

4. CPA & AICPA (2017). “Blockchain Technology 

and Its Potential Impact on The Audit and 

Assurance Profession”, Deloitte Development. 

5. DEMIRHAN, H. (2019). “Vergi Denetiminde 

Yeni Bir Yaklaşim Olarak Blok Zinciri 

Teknolojisi”, Bingöl Üniversitesi Sosyal Bilimler 

EnstitĂźsĂź Dergisi (BUSBED), pp. 857-875. 

6. DOĞAN, M. & ERTUGAY, E. (2019). 

“Blokzinciri ve Muhasebe Alanındaki 

Uygulamaları”, Üçüncü Sektör Sosyal Ekonomi 

Dergisi, pp. 1654-1670. 

7. ETHEREUM (2020, Mayıs 20). “Ethereum 

nedir?”, Retrieved from Ethereum Web sitesi: 

https://ethereum.org/tr/what-is-ethereum/. 

8. EUROPEAN COURT OF AUDITORS (2020). 

“BIG DATA and Digital Audit”, European Union. 

9. EY (2017). “Blockchain: How This Technology 

Could Impact The CFO”, Ernst & Young . 

10. FAN, K., BAO, Z., LIU, M., VASILAKOS, A. 

& SHI, W. (2019). “Dredas: Decentralized, Reliable 

and Efficient Remote Outsourced Data Auditing 

Scheme With Blockchain Smart Contract For 

Industrial IoT”, Future Generation Computer 

Systems, pp. 1-10. 

11. ICAEW (2018). “Blockchain and The Future of 

Accountancy”, Institute of Chartered Accountants 

in England and Wales . 

12. JACKSON, B. (2018). “Understanding The 

Implication of Blockchain Technology on The 

Audit Profession”, Retrieved from University of 

Central Florida's Showcase of Text, Archives, 

Research & Scholarship : 

https://stars.library.ucf.edu/cgi/viewcontent.cgi?art

icle=1441&context=honorstheses. 

13. KARAHAN, Ç. & TÜFEKCI, A. (2019). 

“Blokzincir Teknolojisinin Iç Denetim 

Faaliyetlerine Etkileri: Fırsatlar ve Tehditler”, 

Denetişim, pp. 55-72. 

14. KLOCH, R. & LITTLE, S. (2019). “Blockchain 

and Internal Audit”, Internal Audit Foundation. 

15. LIU, M., WU, K. & XU, J. (2019). “How Will 

Blockchain Technology Impact Auditing and 

Accounting: Permissionless versus Permissioned 

Blockchain”, Current Issues in Auditing, pp. A19–

A29. 

16. MAHBOD, R. & HINTON, D. (2019). 

“Blockchain: The Future of The Auditing and 

Assurance Profession”, Armed Forces Comptroller, 

23-27. 

17. MAR, S. (2018). “Auditing Blockchain”, IT 

Audit, 17-19. 

18. MELNYCHENKO, O. & HARTINGER, R. 

(2017). “Role of Blockchain Technology In 

Accounting and Auditing”, European Cooperation, 

pp. 27-34. 

19. PSAILA, S. (2017). “Blockchain: A Game 

Changer For Audit Processes”, Deloitte Malta 

Article, 1-4. 

20. ROZARIO, A. & THOMAS, C. (2019). 

“Reengineering The Audit With Blockchain and 

Smart Contracts”, Journal of Emerging 

Technologies in Accounting, pp. 21-35. 

21. SHELDON, M. (2019). “A Primer for 

Information Technology General Control 

Considerations on a Private and Permissioned 

Blockchain Audit”, Current Issues in Auditing, pp. 

A15-A29. 

22. SMITH, S. (2018). “Blockchain Augmented 

Audit–Benefits and Challenges For Accounting 

Professionals”, The Journal of Theoretical 

Accounting Research, pp. 117-137. 

23. ŞAT, N. (2019). “Blokzincir (Blockchain)'in 

Kamu Idaresine Olası Etkileri Üzerine”, Amme 

Idaresi Dergisi, pp. 117-147. 

24. ŞEN, E. & ALNIAÇIK, B. (2019). “Blokzincir 

Teknolojisinin YÜnetim Sßreçlerine OlasĹ Etkileri 

Üzerine Inceleme”, Akademik Sosyal Araştırmalar 

Dergi";"""date"",""2020-08-12T18:08:24Z""
""pdf:PDFVersion"",""1.4""
""xmp:CreatorTool"",""MicrosoftÂŽ Word 2016""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""pdfa:PDFVersion"",""A-1a""
""language"",""en""
""dc:format"",""application/pdf; version=""""A-1a"""""",""application/pdf; version=1.4""
""pdf:docinfo:creator_tool"",""MicrosoftÂŽ Word 2016""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""xmp:CreateDate"",""2020-08-12T21:08:24Z""
""modified"",""2020-08-12T18:08:24Z""
""pdf:hasMarkedContent"",""true""
""xmp:ModifyDate"",""2020-08-12T21:08:24Z""
""pdf:docinfo:creator"",""lenovo""
""meta:author"",""lenovo""
""meta:creation-date"",""2020-08-12T18:08:24Z""
""created"",""2020-08-12T18:08:24Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-08-12T18:08:24Z""
""resourceName"",""13""
""pdfaid:part"",""1""
""Author"",""lenovo""
""producer"",""MicrosoftÂŽ Word 2016""
""pdf:docinfo:producer"",""MicrosoftÂŽ Word 2016""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""access_permission:modify_annotations"",""true""
""dc:creator"",""lenovo""
""dcterms:created"",""2020-08-12T18:08:24Z""
""Last-Modified"",""2020-08-12T18:08:24Z""
""dcterms:modified"",""2020-08-12T18:08:24Z""
""xmpMM:DocumentID"",""uuid:8AE6478D-951D-4DA7-B1DD-8BD85D023F07""
""Last-Save-Date"",""2020-08-12T18:08:24Z""
""pdf:docinfo:modified"",""2020-08-12T18:08:24Z""
""meta:save-date"",""2020-08-12T18:08:24Z""
""Content-Length"",""610880""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""lenovo""
""pdfaid:conformance"",""A""
""dc:language"",""tr-TR""
""pdf:producer"",""MicrosoftÂŽ Word 2016""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""8""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""4023"",""4689"",""4945"",""4649"",""4755"",""4565"",""3883"",""1022""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-08-12T18:08:24Z""
";https://scholar.google.com/scholar?start=490&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095409-1742;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Hybrid-Trusted Party Contract Agrees on Clients Input;A Alruwaili, D Kruger ; 2020 IEEE 3rd 5G World Forum (5GWF), 2020  ieeexplore.ieee.org;;"… Wang, H. Lu, X. Sun, Y. Yuan and F. Wang, ""A Novel Blockchain Oracle Implementation Scheme

Based on Application Specific Knowledge Engines,"" 2019 IEEE International Conference on

Service Operations and Logistics, and Informatics (SOLI), Zhengzhou, China, 2019, pp …";Autres articles;;null;;;;https://scholar.google.com/scholar?start=540&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095309-1305;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;PPChain: A privacy-preserving permissioned blockchain architecture for cryptocurrency and other regulated applications;C Lin, D He, X Huang, X Xie… ; IEEE Systems Journal, 2020  ieeexplore.ieee.org;;"… are the main stakeholder group, who consume the services provided by PPChain such as

regulated cryptocurrency, food supply … It then broadcasts tx to blockchain network for being chained

by PNs … constraint (2) shown at the bottom of this page, where all the oracles (except the …";Cité 1 fois;;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/4267003/4357939/09199417.pdf?casa_token=mXYftSUGKtQAAAAA:4VTjiZ2sRVG5DjpjCGQxQypl-YD2s4YXPChjpNZUfKd9oKqn79XpZv-Fb1kOZBDMA9gCOcrN3DQ;"
		Skip to Main Content


		
			
				
				

				

			

		


		
			
				
					
						








	
		
	

	







						

						





























	
	
		
	
	
		
			

		
	

	
	
	



						





	
	
		
			
				IEEE Account

					Change Username/Password
	Update Address


			

			
				Purchase Details

					Payment Options
	Order History
	View Purchased Documents


			

			
				Profile Information

					Communications Preferences
	Profession and Education
	Technical Interests


			

			
				Need Help?

					US & Canada: +1 800 678 4333
	Worldwide:  +1 732 981 0060

					
	Contact & Support


			

		

		
			
				
					
							About IEEE Xplore
	Contact Us
	Help
	Accessibility
	Terms of Use
	Nondiscrimination Policy
	Sitemap
	Privacy & Opting Out of Cookies


						
							A not-for-profit organization, IEEE is the world's largest technical professional organization dedicated to advancing technology for the benefit of humanity.
Š Copyright 2021 IEEE - All rights reserved. Use of this web site signifies your agreement to the terms and conditions.
						

					


					

				

				
			

		

	


	
	


						
						






		
		
		
		
		
		
		
		
		
		
		
		
		
			
				
			
			
			
			
		
		
		
		
		
		

			


			

			
			


		
 		
		
			 

						
						









































	

		
		

		
		
		

		
			
		
		
		

		

		
		


		

		
		
		
		
		
		
		
		
		
		
	
	


















		
		
			
				
					
					
								
					
								
			
				
					
					
								
					
								
			
				
					
						








 



					
					
								
			
				
					
					
								
			
				
					
					
								
					
								
			
				
					
					
								
					
								
			
				
					
					
								
					
								
			
				
					
					
								
					
								
			
				
					
					
								
					
								
			
				
					
					
								
					
								
			
		
	




























		
			
					
			
					
			
					
			
				
					








					
			
					
			
					
			
					
			
					
			
					
			
					
			
		
		
	





	
	
	
	
	
	
	


	
	
	

	

















					

				

			


			
				
			
		

	";"""og:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""twitter:title"",""PPChain: A Privacy-Preserving Permissioned Blockchain Architecture for Cryptocurrency and Other Regulated Applications""
""twitter:card"",""summary""
""Description"",""Existing (popular) blockchain architectures, including the widely used Ethereum and Hyperledger, are generally not designed to achieve conflicting properties su""
""og:title"",""PPChain: A Privacy-Preserving Permissioned Blockchain Architecture for Cryptocurrency and Other Regulated Applications""
""resourceName"",""09199417.pdf""
""language"",""en""
""title"",""PPChain: A Privacy-Preserving Permissioned Blockchain Architecture for Cryptocurrency and Other Regulated Applications | IEEE Journals & Magazine | IEEE Xplore""
""og:description"",""Existing (popular) blockchain architectures, including the widely used Ethereum and Hyperledger, are generally not designed to achieve conflicting properties such as anonymity and regulation, and transparency and confidentiality. In this article, we propose a privacy-preserving permissioned blockchain architecture (PPChain) that permits one to also introduce regulation, where PPChain’s architecture is modified from that of Ethereum. Specifically, we integrate the cryptographic primitives (group signature and broadcast encryption), and adopt practical byzantine fault tolerance consensus protocol with a validate-record separation mechanism, as well as removing the transaction fee and mining reward. To show the utility of PPChain, we provide qualitative security and privacy analysis, and performance analysis. We also explain how PPChain can be deployed in regulation applications, using cryptocurrency, food supply chain, and sealed-bid auctions as examples.""
""twitter:image"",""https://ieeexplore.ieee.org/assets/img/ieee_logo_smedia_200X200.png""
""X-UA-Compatible"",""IE=Edge""
""viewport"",""width=device-width, initial-scale=1.0""
""dc:title"",""PPChain: A Privacy-Preserving Permissioned Blockchain Architecture for Cryptocurrency and Other Regulated Applications | IEEE Journals & Magazine | IEEE Xplore""
""twitter:description"",""Existing (popular) blockchain architectures, including the widely used Ethereum and Hyperledger, are generally not designed to achieve conflicting properties such as anonymity and regulation, and transparency and confidentiality. In this article, we propose a privacy-preserving permissioned blockchain architecture (PPChain) that permits one to also introduce regulation, where PPChain’s architecture is modified from that of Ethereum. Specifically, we integrate the cryptographic primitives (group signature and broadcast encryption), and adopt practical byzantine fault tolerance consensus protocol with a validate-record separation mechanism, as well as removing the transaction fee and mining reward. To show the utility of PPChain, we provide qualitative security and privacy analysis, and performance analysis. We also explain how PPChain can be deployed in regulation applications, using cryptocurrency, food supply chain, and sealed-bid auctions as examples.""
""Content-Encoding"",""UTF-8""
""Content-Type-Hint"",""text/html; charset=utf-8""
""Content-Length"",""41464""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.com/scholar?start=110&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095309-1308;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Authenticated key agreement for blockchain-based WBAN;G Mwitende, I Ali, N Eltayieb, B Wang, F Li ; Telecommunication Systems, 2020  Springer;;"… A session key can be computed between WBAN user PDA and blockchain node M.

Theoretical analysis is achieved and the protocol is secured in random oracle model

(ROM) with computation Diffie–Hellman (CDH) assumption …";Cité 3 fois;Les 5 versions;null;;;;https://scholar.google.com/scholar?start=110&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095374-1590;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;A Supervised Anonymous Issuance Scheme of Central Bank Digital Currency Based on Blockchain;W Dai, X Gu, Y Teng ; … Conference on Algorithms and Architectures for …, 2020  Springer;;"… We propose a special AMCLS scheme suitable for blockchain, through which we can realize

the … During the oracle, \(\mathcal {A}\) makes the input values and learns the resulting transaction …

between two ledgers \(L_0\) and \(L_1\) in using two SAI scheme oracles, when the …";Autres articles;;null;;;;https://scholar.google.com/scholar?start=390&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095349-1481;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Are constant product market oracles safe?;J Clark ; Available at SSRN, 2020  papers.ssrn.com;;"Page 1. Are constant product market oracles safe … Abstract We derive bounds for profitable

manipulation of a constant product market used as a reference provider (oracle) for a margin

position … on the elasticity of the underlying spot market. ?RMIT Blockchain Innovation Hub …";Cité 1 fois;;null;;;;https://scholar.google.com/scholar?start=280&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095362-1541;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Internet Killed the Video Store: Lessons from History Repeated in the Blockchain World?;G Brown, R Whittle ; … Blockchain & Cryptocurrency: Implications for the …, 2020  emerald.com;;"… For example, AXA Global recently developed an oracle to monitor global flight delays in real

time in … as sickness, maternity or lack of work be validated in such an automated blockchain system?

In full, or in part, by Oracles who can access other external systems to validate such …";Les 2 versions;;null;;;;https://scholar.google.com/scholar?start=340&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095381-1616;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;What's in the Box? Combating Counterfeit Medications in Pharmaceutical Supply Chains with Blockchain Vigilant Information Systems;T Clohessy, S Clohessy ; Blockchain and distributed ledger technology …, 2020  Springer;;"… Blockchain, the technology underpinning the Bitcoin cryptocurrency, has been touted as a … of

elimination (eg removal of duplicates, companies focusing solely on crypto services, brokers … and

secured manner by all supply chain ecosystem partners, Oracle's blockchain cloud IoT …";Cité 1 fois;Les 2 versions;null;;;;https://scholar.google.com/scholar?start=420&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095297-1258;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Is blockchain a silver bullet for supply chain management? Technical challenges and research opportunities;A Kumar, R Liu, Z Shan ; Decision Sciences, 2020  Wiley Online Library;;"… Is Blockchain a Silver Bullet for Supply Chain Management? Technical Challenges and Research

Opportunities. Akhil Kumar … FUNDAMENTALS OF BLOCKCHAIN TECHNOLOGY. Architecture

and Comparison with Interorganizational System Technologies …";Cité 46 fois;Les 2 versions;[PDF] wiley.com;https://onlinelibrary.wiley.com/doi/pdf/10.1111/deci.12396;;;https://scholar.google.com/scholar?start=60&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095367-1563;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;[PDF][PDF] INTEGRATED PROJECT DELIVERY WITH BLOCKCHAIN: AN;FAK Elghaish, S Abrishami, MR Hosseini ; researchgate.net;;"… 32] for details). 121 This is one of the blockchain features and its ability to transfer

cryptocurrency/data over 122 blockchain is a result of the evolving BCN throughout

the last decade [29]. Andoni et al. [23] 123 state that smart …";Autres articles;Version HTML;[PDF] researchgate.net;https://www.researchgate.net/profile/Faris-Elghaish/publication/340020046_Integrated_project_delivery_with_blockchain_An_automated_financial_system/links/5f560bc5458515e96d35dda1/Integrated-project-delivery-with-blockchain-An-automated-financial-system.pdf;;;https://scholar.google.com/scholar?start=360&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095306-1298;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;A Pattern Sequence for Designing Blockchain-Based Healthcare Information Technology Systems;P Zhang, DC Schmidt, J White ; arXiv preprint arXiv:2010.01172, 2020  arxiv.org;;"… nine common software patterns shared by the studied contracts, eg, using ""oracles"" to interface …

Meanwhile, the blockchain community also compiled a number of software patterns and

anti-patterns targeting Solidity programming around cryptocurrency transactions in …";Autres articles;;[PDF] arxiv.org;https://arxiv.org/pdf/2010.01172;"
A Pattern Sequence for Designing Blockchain-Based
Healthcare Information Technology Systems
Peng Zhang, Ph.D., Belmont University, Vanderbilt University
Douglas C. Schmidt, Ph.D., Vanderbilt University
Jules White, Ph.D., Vanderbilt University

Known for its decentralized and tamper-aware properties, blockchain is attractive to enhance the infrastructure of systems that have been
constrained by traditionally centralized and vendor-locked environments. Although blockchain has commonly been used as the operational
model behind cryptocurrency, it has far more foreseeable utilities in domains like healthcare, where efficient data flow is highly demanded.
Particularly, blockchain and related technologies have been touted as foundational technologies for addressing healthcare interoperability
challenges, such as promoting effective communications and securing data exchanges across various healthcare systems. Despite the in-
creasing interests in leveraging blockchain technology to improve healthcare infrastructures, a major gap in literature is the lack of available
recommendations for concrete architectural styles and design considerations for creating blockchain-based apps and systems with a health-
care focus.
This research provides two contributions to bridge the gap in existing research. First, we introduce a pattern sequence for designing
blockchain-based healthcare systems focused on secure and at-scale data exchange. Our approach adapts traditional software patterns
and proposes novel patterns that take into account both the technical requirements specific to healthcare systems and the implications of
these requirements on naive blockchain-based solutions. Second, we provide a pattern-oriented reference architecture using an example ap-
plication of the pattern sequence for guiding software developers to design interoperable (on the technical level) healthcare IT systems atop
blockchain-based infrastructures. The reference architecture focuses on minimizing storage requirements on-chain, preserving the privacy of
sensitive information, facilitating scalable communications, and maximizing evolvability of the system.

Categories and Subject Descriptors: D.2.7 [Software Engineering]: Distribution and Maintenance—Documentation

General Terms: Design, Documentation
Additional Key Words and Phrases: Blockchain Technology, Software Engineering, Design Patterns, Smart Contracts, Smart Contract
Security and Vulnerability , Healthcare, Data Sharing, Interoperability, Solidity

ACM Reference Format:

Zhang, P. Schmidt, D.C. and White, J. 2020. A Pattern Sequence for Designing Blockchain-Based Healthcare Information Technology Systems.
HILLSIDE Proc. of Conf. on Pattern Lang. of Prog. V (January YY), 22 pages.

1. INTRODUCTION

Blockchain technology has demonstrated its success in sustaining the secure and scalable exchanges of digital
assets through its first applications in cryptographic currency, such as Bitcoin and Ethereum [Nakamoto 2008;
Buterin et al. 2013]. In essence, blockchain is a decentralized architecture built upon existing concepts from

Author’s address: Zhang, Peng 1900 Belmont Blvd, Nashville, TN 37212; email: peng.zhang@vanderbilt.edu; Schmidt, Douglas C. Vanderbilt
University, PMB 351679, 2301 Vanderbilt Place, Nashville, TN 37235; email: d.schmidt@vanderbilt.edu; White, Jules Vanderbilt University,
PMB 351679, 2301 Vanderbilt Place, Nashville, TN 37235; email: jules.white@vanderbilt.edu

Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided
that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on
the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission. A
preliminary version of this paper was presented in a writers’ workshop at the 26th Conference on Pattern Languages of Programs
(PLoP). PLoP’19, OCTOBER 7-10, Ottawa, Ontario Canada. Copyright 2019 is held by the author(s). HILLSIDE 978-1-941652-14-5
PLoP’19, October 7–10, Ottawa, Ontario, Canada. Copyright 2019 is held by the author(s). HILLSIDE 978-1-941652-14-5

ar
X

iv
:2

01
0.

01
17

2v
1 

 [
cs

.C
R

] 
 2

 O
ct

 2
02

0



computer science and mathematics in a manner that differs from traditional infrastructures, which have placed
many restrictions on system services and capabilities due to centralization. To achieve decentralization, information
becomes transparent and immutable to a certain degree, which enabled the Bitcoin blockchain as a viable platform
for ""trustless"" exchanges [Blundell-Wignall 2014] that take place directly between any two parties without the
involvement of a trusted middleman or another third party. These revolutionary concepts underlying blockchain
have sparked a lot of interest in its application from technologists and domain experts across various industries,
such as finance, healthcare, transactive energy, and the food industry.

Another mainstream public blockchain platform, Ethereum, extended the capabilities of cryptocurrency-based
blockchains like Bitcoin to enable programmability and near Turing-complete computations via “smart contracts“ [Bu-
terin et al. 2013]. Smart contracts are similar to any software program in that they have states and some instructions
to directly control the states to facilitate the exchange and/or redistribution of digital assets between two or more
parties. The instructions or code define rules or agreements established between involved parties in advance to
produce deterministic outputs. Ethereum’s successful implementation of programmable smart contracts promoted
the development of decentralized apps (DApps) [Johnston et al. 2014], which are autonomously operated services
that interact with cryptography-protected data stored on the blockchain and persist the records of transactions also
on-chain. DApps are also a medium that allows end users to directly interact with the blockchain and relevant data
on-chain.

Blockchain and smart contracts have been explored as a foundational technologies to address healthcare
interoperability challenges [DeSalvo and Galvez 2015; Das 2017]. Interoperability is the ability for various informa-
tion technology systems and applications to communicate, exchange data, and effectively digest the exchanged
information [Geraci et al. 1991]. Healthcare authorities and experts have attempted to improve the interoperability in
healthcare for decades [Richesson and Nadkarni 2011] in order to provide more continuous and consistent medical
services, including but not limited to securely and reliably delivering patient data across different episodes of care
and care locations, effectively facilitating medical communications between providers, and accurately and promptly
connecting medical devices and medical alerts to the appropriate patients [Lesh et al. 2007]. However, despite the
growing interest in creating blockchain-based healthcare systems, little information exists in current literature on the
concrete design recommendations for applying blockchain technology to address healthcare-specific challenges.

This paper focuses on addressing this research gap by providing a basic software pattern sequence for designing
blockchain-based healthcare DApps that target healthcare-specific challenges. The target audience of this paper
are health information technology (IT) system architects and developers interested in applying blockchain and
related technologies in the system design. In software engineering practice, design patterns offer general and
reusable solutions to recurring problems. They allow software engineers to communicate using well-known and
well-understood names for interactions in the software [Shvets 2015]. By documenting a sequence of reoccurring
blockchain-specific patterns taking into account domain-specific requirements, this work can assist the target
audience to more quickly adapt to this technology and create robust solutions with it in the healthcare domain.

The remainder of this paper is organized as follows: Section 2 provides an overview of blockchain technology and
the Ethereum implementation; Section 3.1 summarizes existing research related to this work; Section 4 outlines
key challenges regarding healthcare interoperability faced by the direct applications of blockchain technology;
Section 5 presents our proposed pattern sequence in detail; and Section 6 concludes the paper and summarizes
future work on applying blockchain and related technologies in the healthcare domain.

2. KEY CONCEPTS OF BLOCKCHAIN TECHNOLOGY

This section gives a general overview of blockchain and the open-source Ethereum implementation that supports
smart contracts, which enable computation and facilitate the development of decentralized apps beyond cryptocur-
rencies. The overview is followed by a discussion of Solidity, which is a programming language for writing smart
contracts in Ethereum and the basis of our pattern sequence discussed in Section 5.

A Pattern Sequence for Designing Blockchain-Based Healthcare Information Technology Systems — Page 2



2.1 Blockchain Concepts

A blockchain is a decentralized, replicated, and continually reconciled data structure that maintains an append-only
list of ordered transactions grouped into blocks, as shown in Figure 1.

Fig. 1. Blockchain Structure: A Shared, Append-Only List of Ordered Transactions Grouped into Blocks

All transactions are recorded in the blockchain and available to all network nodes to provide transparency of the
exchanges of digital data, such as cryptocurrencies. Only one block may be added to the blockchain at a time
following a mathematical verification (based on cryptography) to ensure that it is in sequence from the previous
block and contain all valid transactions. The most famous and robust verification process is Proof of Work (PoW)
or “mining“ [Nakamoto 2008] that is introduced in the Bitcoin blockchain. In PoW, block-mining nodes compete
to have their block of transactions be the next one added to the blockchain by solving a hard puzzle whose
solution is trivial to verify. The first node to solve the puzzle announces the solution to the entire network, and if
the solution is correct, the winner receives a mining reward paid via cryptocurrency for their contribution. PoW is
based on cryptography, game theory, and incentive engineering to ensure decentralized consensus is reached
regarding the block and transaction sequence and to protect the transaction history against tampering. The mining
process provides blockchain with three key properties: transparency (for easily verifying that a specific transaction
occurred at a particular point in time), immutability (that prevents existing transaction history from being altered),
and decentralization (for providing resiliency to a single point of failure with replicated storage) [Hub 2017].

In Bitcoin, blockchain serves as a public ledger that facilitates the direct financial transactions between individual
users with cryptography to secure the exchange. However, the blockchain implemented by Bitcoin is limited
to only support Bitcoin transactions and not suitable for other types of more complex data exchange beyond
cryptocurrency. To provide a more flexible framework, Ethereum was created as an alternative blockchain that
enables computation, making it a more generalized trustless platform that can run smart contracts [Buterin et al.
2013].

Ethereum is a decentralized computing system that has a native cryptocurrency powering the network and an
extended programmable capability enabled by the use of the near Turing-complete Ethereum Virtual Machine
(EVM). In Ethereum blockchain, a smart contract can be created to store data of different structures and define
protocols that interact with the data. To ensure the same level of information consistency and consensus as its
Bitcoin predecessor, Ethereum enforces a payment policy in terms of “gas"" for creating and storing each smart

A Pattern Sequence for Designing Blockchain-Based Healthcare Information Technology Systems — Page 3



contract and any data operation. This policy serves two purposes: (1) it is used to pay for network nodes to verify
and execute valid transactions as an incentive and (2) it is also a financial disincentive against malicious attacks.
In addition, there is a global maximum gas limit defined by the Ethereum protocol and a sender-specified gas
limit that indicates the max gas amount that the sender is willing to pay for. If gas spent during the execution of
a transaction exceeds either of these two limits, computation will be stopped, and the sender still has to pay for
the performed computation. This protocol protects senders from completely running out of funds and also further
deters malicious attacks and abuse, such as distributed denial of service attacks in the network or hostile infinite
loops in smart contract code [Buterin et al. 2013].

2.2 Overview of Solidity

Ethereum smart contracts can be written in a Turing-complete programming language, called Solidity [Foundation
2015b], compiled by the EVM. Programmable smart contracts foster the development of DApps on the Ethereum
blockchain and are thus a feature we are exploring to potentially address certain healthcare interoperability
challenges. Solidity is an object-oriented language and is designed primarily for writing contracts in Ethereum.

A Solidity class is realized through a ""contract,"" which is an object prototype (some code template) stored
on-chain. Just like an object-oriented class can be instantiated into a concrete object at runtime, a contract may be
instantiated into a concrete “smart contract account“ (SCA) by a transaction or a function call from another contract.
At instantiation, a contract is assigned a unique address that is similar to a reference or pointer in C/C++-like
languages. The contract can be referred to and its functions revoked using the address. A smart contract can
also define state variables to store data and functions that interact with the data. Although one contract can be
instantiated into many SCAs, it should be treated as a singleton to avoid undesired behavior and storage overhead.
A common practice is to store the address of an instantiated contract in a static location, such as a configuration
file or database. The address can then be retrieved as a parameter to access the contract’s internal states and
invoke its functions [Dourlens 2017].

Solidity also supports multiple inheritance and polymorphism [Ethereum.io 2017]. When a contract inherits
from one or more other contracts, a new contract instance is created by copying all the base contracts code into
the child contract prototype. An abstract contract in Solidity can declare function headers but without concrete
implementations, which means that it cannot be compiled into an SCA but can be used as a base contract. In this
paper, we focus the pattern discussions based on the use of Solidity.

3. RELATED WORK

3.1 Overview

Although relatively few papers focus on realizing software patterns in blockchains, some relate to healthcare
blockchain solutions and design principles in this space. This section gives an overview of related research on (1)
the challenges of applying blockchain-based technology in the healthcare space and innovative implementations
of blockchain-based healthcare systems and (2) design principles and recommended practice for blockchain
application implementations.

3.1.1 Challenges of healthcare blockchain and proposed solutions.. Azaria et al. [Azaria et al. 2016] proposed
MedRec as an innovative, working healthcare blockchain implementation for handling EHRs, based on principles
of existing blockchains and Ethereum smart contracts. The MedRec system uses database ""Gatekeepers"" for
accessing a node’s local database governed by permissions stored on the MedRec blockchain. Peterson et
al. [Peterson et al. 2016] presented a healthcare blockchain with a single centralized source of trust for sharing
patient data, introducing Proof of Interoperability based on conformance to the FHIR protocol as a means to
ensure network consensus.

A Pattern Sequence for Designing Blockchain-Based Healthcare Information Technology Systems — Page 4



3.1.2 Prior efforts focused on software design practice for developing blockchain apps.. Porru et al. [Porru et al.
2017] highlighted evident challenges in state-of-the-art blockchain-oriented software development by analyzing
open-source software repositories and addressed future directions for developing blockchain-based software.
Their work focused on macro-level design principles such as improving collaboration, integrating effective testing,
and evaluations of adopting the most appropriate software architecture. Bartoletti et al. [Bartoletti and Pompianu
2017] surveyed the usage of smart contracts and identified nine common software patterns shared by the studied
contracts, e.g., using ""oracles"" to interface between contracts and external services and creating ""polls"" to vote on
some question. These patterns summarize the most frequent solutions to handle some repeated scenarios. A
number of attacks on Ethereum smart contracts have been reported, including the infamous DAO attack [Siegel
2016] where $50 million worth of Ether was stolen and the critical Parity wallet hack [Palladino 2017] that incurred
in $30 million worth of Ether being exploited. Atzei et al. surveyed existing attacks on Solidity smart contracts
with code snippets showing related vulnerabilities [Atzei et al. 2017]. Meanwhile, the blockchain community also
compiled a number of software patterns and anti-patterns targeting Solidity programming around cryptocurrency
transactions in order to maximize the security of Ethereum smart contract design [ConsenSys 2018]. More recently,
Moreno et al. proposed a security pattern focusing on the use of blockchain in big data systems [Moreno et al.
2019]. Relatedly, Ellervee et al. described a comprehensive reference model for blockchain-based systems using
software architecture concepts [Ellervee et al. 2017].

3.2 Gaps in Existing Research

Many research and engineering ideas have been proposed to apply blockchain technology in healthcare, and
implementation attempts are underway [Azaria et al. 2016; Peterson et al. 2016; Porru et al. 2017; Bartoletti and
Pompianu 2017]. Prior research efforts have provided a number of design recommendations for implementing
Solidity smart contracts involving cryptocurrency transactions. Few published studies, however, have addressed
software design considerations needed to implement blockchain-based healthcare apps effectively. While it is
crucial to understand the fundamental properties of blockchains and the smart contract programming language,
it is also important to apply them properly so that healthcare-specific challenges are addressed. Even though a
subset of principles from prior work may be relevant to the healthcare space, a systematic approach to document
appropriate design practice that specifically target technical challenges in healthcare is still essential.

4. HEALTHCARE INTEROPERABILITY CHALLENGES FACED BY BLOCKCHAIN-BASED APPS

The US Office of the National Coordination for Health Information Technology (ONC) has outlined basic technical
requirements for achieving interoperability [ONC 2014]. Based on these requirements, this section summarizes
key interoperability challenges faced by blockchain-based apps, focusing on four aspects: system evolvability,
blockchain storage, information privacy, scalability, and security.

4.1 Evolvability Challenge: Maintaining Evolvability While Minimizing Integration Complexity

Many traditionally centralized apps are written with the assumption that data is easy to change. This assumption
does not hold true for blockchain-based apps. Once stored on-chain, data is difficult to modify en masse. Not only
is code manipulating the data is immutable, but data change history also persists on-chain and can be replayed
due to the nature of blockchain. Healthcare data contains sensitive personal information protected by law [CDC
2003], which, if compromised, would create severe legal, financial, and also social consequences. The vulnerability
in smart contract code leading to the infamous DAO attack [Siegel 2016] must be avoided in a healthcare app.

At the same time, healthcare systems may be subject to updates or upgrades required by clinical workflow or
healthcare regulations. This need for potential system evolution creates a tension for a blockchain-based design.
As such, a critical design consideration when building blockchain apps for healthcare is to ensure that the data
written into blockchain via smart contracts are designed to facilitate evolution where mandated.

A Pattern Sequence for Designing Blockchain-Based Healthcare Information Technology Systems — Page 5



Although evolution must be supported, healthcare data must often be accessible from a variety of deployed
systems that cannot easily be changed over time. Apps should therefore be designed in a way that is loosely
coupled and minimizes the usability impact of evolution on the clients, i.e., user services that interact with data in
the blockchain. Sections 5.1, 5.3, and 5.2 shows how using LAYERED RING, CONTRACT MANAGER, and GUARDED

UPDATE patterns from the pattern sequence, respectively, can help avoid serious attacks like the DAO [Siegel
2016] and facilitate necessary system evolution, while minimizing the impact on dependent clients, focusing on the
separation of concerns between data and logic and a type of attack called reentrancy, which will be described
further in Section 5.2.

4.2 On-Chain Storage Challenge: Minimizing Data Storage Requirements on the Blockchain

Healthcare apps can serve thousands to millions of participants, which may incur enormous overhead when large
volumes of data are stored in a blockchain–particularly if data normalization and denormalization techniques are
not carefully considered. Considering storage scalability, not only is it costly to store data, but data modifications
and access operations may also fail if/when the cost of storage or execution exceeds the allowance in a blockchain,
e.g., gas limit defined for the Ethereum blockchain as discussed in Section 2.1. An important design consideration
for blockchain-based healthcare apps is thus to minimize data storage requirements in addition to provide sufficient
flexibility to manage individual health concerns. Sections 5.4 and 5.6 show how to design smart contracts with
DATABASE CONNECTOR and ENTITY REGISTRY patterns from the pattern sequence, respectively, to improve
interoperability by standardizing interfaces to storage access and maximizes on-chain scalability by capturing
common intrinsic data sharing across entities while still allowing extrinsic data to vary in specific entity contracts.

4.3 On-Chain Privacy Challenge: Balancing Data Storage with Privacy Concerns

Blockchains and smart contracts can offer trustless digital health asset sharing, audit trails of data access, and
decentralized and replicated storage, which are essential for improving healthcare interoperability by providing
ubiquitous data store. Although there are substantial potential benefits to the availability of information if data is
stored on-chain, there are also significant risks due to the transparency of blockchain. In particular, even when
encryption is applied to sensitive data on-chain, it is still possible that the current encryption techniques may
be broken in the future [Rich and Gellman 2014] or that vulnerabilities in the encryption implementations may
later be exploited, rendering private information potentially decryptable in the future. To protect health information
privacy, in Sections 5.5 and 5.7 we discuss how designing a blockchain-based app using the DATABASE PROXY

and TOKENIZED EXCHANGE patterns from the pattern sequence, respectively, can facilitate data sharing while
keeping sensitive patient data from being directly encoded in the blockchain.

4.4 Scalable Communication Challenge: Tracking Relevant Health Changes Scalably Across Large Patient
Populations

Communication gaps and information sharing challenges are serious impediments to healthcare innovation and
the quality of patient care. Providers, hospitals, insurance companies, and departments within health organizations
experience disconnectedness caused by delayed or lack of information flow. Patients are commonly cared for
by various sources, such as private clinics, regional urgent care centers, and enterprise hospitals. A provider
may have hundreds or more patients whose associated health data must be tracked. Section 5.8 shows how a
blockchain-based app design using the PUBLISHER-SUBSCRIBER pattern from our pattern sequence can be aid in
scalably detecting and communicating relevant health changes.

4.5 Security Challenge: Preventing Unintended Software Loopholes and Safeguarding On-Chain Data

Similar to information privacy that protects the identity of users and data holders, information and system security
is also paramount in healthcare systems to safeguard against unintended software loopholes or unauthorized
access that could lead to compromised data. Due to the decentralized nature of blockchain and related technology,

A Pattern Sequence for Designing Blockchain-Based Healthcare Information Technology Systems — Page 6



the security of information faces higher risks because it is exposed to a much wider, and sometimes uncontrolled,
audience and it is usually not immediately amendable. In recent years, software loopholes that existed in several
major blockchain-based crytocurrency services have been exploited by attackers, causing significant financial
losses to users and the service providers []. To prevent similar predicament from happening to healthcare services
hosted in blockchain-based infrastructures, security risks must be recognized in the early stage of system designs
in addition to the construction of a safeguarded system. Sections 5.2 and 5.8 are two examples of security
protection in a blockchain-based healthcare app.

5. A KEY PATTERN SEQUENCE FOR DESIGNING BLOCKCHAIN-BASED HEALTH APPS

This section presents a key pattern sequence for creating blockchain-based health system designs that address
the major challenges described earlier in Section 4. Our research approach that developed this sequence has
three folds. First, because the topic of design patterns focused on using blockchain technology for healthcare
has received limited attention in literature, we had extracted a subset of the patterns using commonality and
variability analysis [Coplien et al. 1998]. Specifically, we obtained a number of verified smart contract source
code from Etherscan.io [Etherescan nd] to capture common portions repeatedly used across various contracts
and/or supporting library contracts, which we codified into patterns of this sequence, such as LAYERED RING

and CONTRACT MANAGER Second, based on our experience from previous work on researching healthcare data
sharing solutions [Zhang et al. 2017b; Zhang et al. 2018] and our understanding of the healthcare domain and the
technical requirements for its systems [Zhang et al. 2017a; Zhang et al. 2018], we codified the design practice
we learned from prior research into several patterns in the key sequence, such as DATABASE CONNECTOR and
TOKENIZED EXCHANGE. Third, given the extensiveness and maturity of existing research on centralized and
distributed software engineering design practice, we have applied, wherever necessary for a blockchain-based
healthcare system, design principles widely accepted to our pattern sequence with blockchain-focused design
considerations, such as DATABASE PROXY, ENTITY REGISTRY, AND PUBLISHER-SUBSCRIBER. Additionally, due to
the growing popularity of Solidity (which is the primary programming language for creating smart contracts) and
attacks that have occurred to public smart contracts, the Ethereum community has captured a number of Solidity
code patterns for preventing similar attacks. Although those code patterns were almost exclusively targeting
cryptocurrency or other apps with financial incentives, we identified one code pattern that would be particularly
critical in a healthcare system, namely, GUARDED UPDATE.

The remainder of this section applies a pattern form variant to motivate and show how our pattern sequence
aids in designing blockchain-based healthcare apps. In particular, we present eight software patterns—LAYERED

RING, GUARDED UPDATE, CONTRACT MANAGER, DATABASE CONNECTOR, DATABASE PROXY, ENTITY REGISTRY,
TOKENIZED EXCHANGE, and PUBLISHER-SUBSCRIBER [Gamma et al. 1995; Buschmann et al. 2007]. We describe
key healthcare challenges that they resolve in the blockchain platform and detail their structure and composition. 1.

Table 5 provides an overview of the pattern sequence, showing how the patterns relate to healthcare-specific
challenges described previously in Section 4 and what specific sub-challenge each pattern aims to solve.

Each of the patterns in this sequence is discussed in depth below.

5.1 A Blockchain-Based Architecture for Health Data Sharing Systems

Design problem faced by blockchain-based apps. Healthcare data exists in siloed data warehouses across
different healthcare organizations, private practices, and, more recently, mobile health app providers [Ajami and
Bagheri-Tadi 2013; Zhang et al. 2018]. Despite the adoption of certified EHRs or other data exchange solutions that
can provide direct data exchange between providers within the same network (e.g., using an EHR system provided
by the same vendor), impediments for healthcare providers and researchers to access those heterogeneous data
silos still exist.

1Naturally, there are other patterns relevant in this domain, which can be the focus of future work.

A Pattern Sequence for Designing Blockchain-Based Healthcare Information Technology Systems — Page 7



Table I. Overview of Proposed Pattern Sequence for Designing Blockchain-Based Healthcare
Apps

Pattern Targeted Category Specific Challenge to Solve

Layered Ring Evolvability
Defining the data sharing system’s base
architecture

Guarded Update Evolvability & Security
Preventing unexpected reentrancy attacks
that occurred in the DAO

Contract Manager Evolvability
Separating data from logic to ensure data
availability via clean separation of concerns

Database Connector On-Chain Storage
Ensuring on-chain storage scalability and
interoperability via standardized and minimal
interfaces to off-chain storage

Database Proxy On-Chain Privacy
Providing an additional layer of security by
performing lightweight tasks before permitting
access to database connectors

Entity Registry On-Chain Storage
Managing healthcare entities on-chain and other
types of common data at scale

Tokenized Exchange On-Chain Privacy
Authorizing access to data storage and
maintaining verifiable access logs

Publisher-Subscriber
Scalable Communication
& Security

Providing user notifications when events of
interest occur across the decentralized network

Solution → Apply the LAYERED RING pattern to define the base architecture of the health data sharing
system. The emerging blockchain technology that supports decentralized data storage and executable code via
smart contracts, with Ethereum [Buterin et al. 2013] being the most popular, has presented itself as a potential
infrastructure to connect existing healthcare data silos [Peter B. Nichol 2016; Broderson et al. 2016; Dubovit-
skaya et al. 2017] with its success in maintaining tamper-proof cryptocurrency transactions between worldwide
Internet users [Nakamoto 2008; Cap nd] and managing verifiable collectibles or rewards from cryptogaming like
CryptoKitties [CryptoKitties nd].

At the architectural level, the healthcare data sharing problem is not too different from those successful use
cases of blockchain. Figure 2 compares the high-level architecture of data sharing in healthcare with that of
blockchain-based cryptocurrency exchange and cryptogaming. In this figure, the bottom level in both architectures
1 and 2 contains a number of heterogeneously represented objects, i.e., siloed healthcare data sources (e.g.,
low-frequency, high-fidelity clinical data, or LFQ, captured by trusted sources and high-frequency, low-fidelity data,
or HFQ, generated by patients or wearable and mobile devices) in Architecture 1 and geographically dispersed
Intern";"""date"",""2020-10-06T01:39:32Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2020-10-06T01:39:32Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.21 (TeX Live 2020) kpathsea version 6.3.2""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2020-10-06T01:39:32Z""
""created"",""2020-10-06T01:39:32Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-10-06T01:39:32Z""
""resourceName"",""2010.01172""
""Author"",""""
""producer"",""pdfTeX-1.40.21""
""pdf:docinfo:producer"",""pdfTeX-1.40.21""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2020-10-06T01:39:32Z""
""Last-Modified"",""2020-10-06T01:39:32Z""
""dcterms:modified"",""2020-10-06T01:39:32Z""
""title"",""""
""Last-Save-Date"",""2020-10-06T01:39:32Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2020-10-06T01:39:32Z""
""meta:save-date"",""2020-10-06T01:39:32Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.21 (TeX Live 2020) kpathsea version 6.3.2""
""Content-Length"",""723186""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""22""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""3697"",""4233"",""2541"",""3530"",""3993"",""3898"",""3910"",""3577"",""2321"",""2058"",""1714"",""2370"",""1541"",""2733"",""2216"",""2424"",""4193"",""2191"",""3793"",""1733"",""4170"",""2244""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-10-06T01:39:32Z""
";https://scholar.google.com/scholar?start=100&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095351-1484;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Puncturable Signatures and Applications in Proof-of-Stake Blockchain Protocols;X Li, J Xu, X Fan, Y Wang… ; IEEE Transactions on …, 2020  ieeexplore.ieee.org;;"… also has (one-time) oracle access to a featured Corruption oracle, by which the adversary … can

be determined in specific implementation (eg, the slot parameter in proof-of-stake blockchain) …

cryptographic hash functions, which we model as random oracles in the security proof …";Cité 1 fois;Les 5 versions;[PDF] arxiv.org;https://arxiv.org/pdf/1909.03955;"
ar
X

iv
:1

90
9.

03
95

5v
2 

 [
cs

.C
R

] 
 1

5 
O

ct
 2

01
9

1

Puncturable Signatures and Applications in
Proof-of-Stake Blockchain Protocol

Xin-Yu Li, Jing Xu, Xiong Fan, Yu-Chen Wang and Zhen-Feng Zhang

Abstract—Proof-of-stake blockchain protocols are becoming one of the most promising alternatives to the energy-consuming

proof-of-work protocols. However, one particularly critical threat in the PoS setting is the well-known long-range attacks caused by

secret key leakage (LRSL attack). Specifically, an adversary can attempt to control/compromise accounts possessing substantial stake

at some past moment such that double-spend or erase past transactions, violating the fundamental persistence property of blockchain.

Puncturable signatures provide a satisfying solution to construct practical proof-of-stake blockchain resilient to LRSL attack, despite of

the fact that existent constructions are not efficient enough for practical deployments.

In this paper, we provide an in-depth study of puncturable signatures and explore its applications in the proof-of-stake blockchain. We

formalize a security model that allows the adversary for adaptive signing and puncturing queries, and show a construction with efficient

puncturing operations based on the Bloom filter data structure and strong Diffie-Hellman assumption. The puncturing functionality we

desire is for a particular part of message, like prefix, instead of the whole message. Furthermore, we use puncturable signatures to

construct practical proof-of-stake blockchain protocols that are resilient to LRSL attack, while previously the forward-secure signature is

used to immunize this attack. We implement our scheme and provide experimental results showing that in comparison with the

forward-secure signature, our construction performs substantially better on signature size, signing and verification efficiency,

significantly on key update efficiency.

Index Terms—Puncturable signature, Bloom filter, Proof-of-Stake, Blockchain.

✦

1 INTRODUCTION

Proof-of-stake (PoS) protocols have been envisioned as a
more ecological alternative of the proof-of-work (PoW)
mechanism to maintain consensus, since PoS leverages the
virtual resources (e.g., the stake of a node) rather than con-
suming vast amounts of energy to solve the computational
puzzles in PoW. In a proof-of-stake blockchain protocol,
roughly speaking, participants randomly elect one party
to produce the next block by running a “leader election”
process with probability proportional to their current stake
held on blockchain.

In spite of high efficiency, proof-of-stake blockchains
only account for a tiny percentage of existing digital cur-
rencies market, mainly due to the fact that most existing
proof-of-stake protocols suffer from the well-known long-
range attacks [1] [2] [3](stemming from its weak subjectivity
and costless simulation) which degrades security in the
blockchain. A oft-cited long-range attack is caused by secret
key leakage (abbreviated as LRSL attack in this paper).
Specifically, an adversary can attempt to bribe/corrupt the
secret keys corresponding to accounts with a substantial
stake at some past moment (however, currently low-stake
or even no stake), and then construct a fork and alter the
history from the point in the past with the majority stake.
Moreover, the attack can be sustained due to the fact that the
adversary can continue to hold majority stake (e.g., by the

• X.-Y. Li, J. Xu, Y.-C Wang and Z.-F. Zhang are with Trusted
Computing and Information Assurance Laboratory, Institute of Soft-
ware, Chinese Academy of Sciences, Beijing, China. E-mails: {xujing,
xinyu2016}@iscas.ac.cn,{wangyuchen, zfzhang}@tca.iscas.ac.cn.

• X. Fan is with University of Maryland, College Park, MD, America. E-
mail: leofanxiong@gmail.com.

reward fees of generating or issuing blocks). Note that the
accounts with low-stake are highly vulnerable to the secret
key leakage since they might not be well protected com-
pared with other active accounts, which further aggravates
this attack.

Puncturable signature (PS), introduced by Bellare et
al. [4], provides a satisfying solution to construct practical
proof-of-stake blockchain protocols resilient to LRSL attack.
Generally speaking, a puncturable signature scheme pro-
vides a Puncture functionality that, given a secret signing
key and a particular message m, generates an updated
secret key which is able to sign all messages except for the
punctured message m. In this paper, we further generalize
the definition of the puncturable signature, particularly, the
strings associated with the punctured signing key can be
any part of signed messages (e.g. its prefix). In proof-of-
stake protocols, the leader U (elected for issuing block) signs
the block Bi with the puncturable signature by the secret
key skU at some time slot sli, where sli is the part of block
Bi, and then U performs puncturing operation on message
sli which results in an updated sk′U . More specifically, if
no empty block is allowed, the punctured message can be
H(Bi−1) instead of sli, where H(Bi−1) is the part of block
Bi and Bi−1 is the previous block of Bi. The security of
puncturable signature guarantees that anyone cannot sign
another data block B′

i with the same sli (or H(Bi−1))
even though sk′U is exposed, and thus LRSL attack can be
avoided.

A natural way to remedy LRSL attack in proof-of-stake
blockchain protocols is to use the forward secure signa-
ture [5], which guarantees that the previously issued sig-
natures remain valid even if the current secret signing key
is compromised. However, the computation performance

http://arxiv.org/abs/1909.03955v2


2

of forward secure signature depends on either the time
periods set in advance or the time periods elapsed so far
logarithmically (even linearly), which brings undesirable
consumption and becomes a fatal issue for blockchain ap-
plications. Moreover, most signers have no chance to do
any signing within one period but they have to update
the signing key as long as the current period ends, which
makes the update operation a vain effort in the proof-of-
stake blockchain. In fact, the forward secure signature can
be treated as one special kind of the puncturable signature
where the punctured message is the earlier period of time.

Puncturable signatures can also be used in many other
scenarios such as asynchronous transaction data signing
services. Transaction data signing is a process which guar-
antees the integrity and authenticity of the sensitive trans-
action data, such as payment instruction or transaction
information of buying a real estate offering. In many cases,
using ordinary digital signatures is not enough for these
applications, as they often fail to ensure the integrity of past
messages in the case when a user’s key is compromised.
This is particularly challenging in the non-interactive and
asynchronous message system, where users may not be
online simultaneously and messages may be delayed for
substantial periods due to delivery failures and connectivity
issues. Similar problem also exists in the theoretical part.
For instance, in non-interactive multiparty computation (NI-
MPC) [6], where a group of completely asynchronous par-
ties can evaluate a function (e.g. for the purpose of voting)
over their joint inputs by sending a signed message to an
evaluator who computes the output. The adversary would
control the final output if he can corrupt some parties within
a period of time. In these examples, the transaction session
ID can be used as a prefix, and after the honest user signs
the transaction data (or message), the prefix is punctured so
that no other signature exists for messages agreeing on the
same prefix. Therefore, the integrity of transaction data (or
message) is ensured by puncturable signatures.

1.1 Our Contributions

In this work, we provide an in-depth study of the punc-
turable signature and its applications in the proof-of-stake
blockchain protocols. Our overall goal is to design a punc-
turable signature that allows for fine-grained revocation of
signing capability with minimum computation cost, and
make it a suitable building block to construct secure and
practical proof-of-stake blockchain protocol. More specifi-
cally, our technical contributions are threefold.

Puncturable signature and its construction. We introduce
the notion of puncturable signature with extended punctur-
ing functionality where the secret key can be updated by
puncturing any particular part of message (for simplicity,
we use the prefix of message in this paper) instead of
puncturing the whole message. In the security model we
propose, in addition to making adaptive signing and punc-
turing queries, adversary also has (one-time) oracle access
to a featured Corruption oracle, by which the adversary
can obtain the current secret key if the challenging string
is in the puncturing set P . Then we show a construction
of puncturable signature based on the probabilistic Bloom
filter data structure [7] is secure under our security model.

Our PS construction is inspired by an elegant work [8],
where the authors show how to construct puncturable en-
cryption based on Bloom filter. However, different from the
expanded (k times) ciphertext size of underlying encryption
scheme in [8], in our construction, the signature size is
almost equal to that of the underlying signature scheme.

In comparison with two prior puncturable signature
schemes [4] [6], our construction achieves significant effi-
ciency improvement in both signing and puncturing oper-
ations. More specifically, the construction in [4] relies on
indistinguishability obfuscation, which incurs prohibitive
computational burden in practice, while the other one [6]
needs to update public key for every puncturing, which
has some theoretical merits but hard to implement in real
world deployment. On the contrary, in our construction,
a puncturing operation only involves a small number of
efficient computations (i.e., hashing), plus the deletion of
certain parts of the secret key, which outperforms previous
schemes by orders of magnitude. Indeed, the puncturable
signature is not a simple inverse operation of the punc-
turable encryption, which is also the reason for no effi-
cient puncturable signature scheme even though efficient
puncturable encryption constructions have been proposed
for a long time. The crucial difficulty in designing the
puncturable signature scheme is how to bind the private
key with punctured messages such that the updated private
key cannot sign for punctured messages.

Applications in Proof-of-stake blockchain protocols. We use
the puncturable signature to construct practical proof-of-
stake blockchain protocols that are resilient to LRSL attack.
Ouroboros Paros [9], a proof-of-stake blockchain protocol,
has a real-world implementation in Cardano platform. We
present an ideal functionality FPS of the puncturable signa-
ture scheme, and replace FKES of the forward secure signa-
ture scheme in Ouroboros Paros [9] protocol with FPS. Then
we show that the properties (common prefix, chain quality
and chain growth) of Ouroboros Paros protocol remain true
in the replaced setting. Finally, we prove our puncturable
signature scheme can securely realize FPS in the universal
composability (UC) security framework. Without loss of
generality, we also discuss how to apply our construction
to other proof-of-stake blockchain protocols to resist LRSL
attack.

Efficiency comparison with forward secure signatures. As
mentioned above, despite that forward secure signatures
can be used to resist LRSL attack, most of the existing
schemes have poor performance on key update as well as
other operations, often depending on the time period num-
ber linearly, which is unsuitable for blockchain application.
We conduct experiments evaluating the overhead of de-
ploying our puncturable signature construction and existing
forward security signature schemes [10] [11] at both 128-bit
and 192-bit security levels. Figure 1 illustrates the efficiency
comparison and the results show that our scheme performs
substantially better on signature size, signing and verifica-
tion efficiency, significantly on key update efficiency, which
reduces both communication and computation complexity.
In fact, we can replace the ordinary signature with our
puncturable signature construction in any other proof-of-
stake protocols such as Ouroboros [12] and Snow White [13]



3

10

1

(a) Sign time

10

1

(b) Verify time

10

1

(c) Update time

10

1

(d) Signature size

Figure 1: Efficiency Comparison

protocols. Due to the fact that our construction can retain
the efficiency of the underlying scheme on signing and ver-
ifying, with additional k hash computations, the improved
protocols can provide resilience to LRSL attack at almost no
additional computing cost.

1.2 Related Work

Puncturable signature. A puncturable signature scheme al-
lows to update its signing key sk for an arbitrary messagem
such that the resulting punctured signing key can produce
signatures for all messages except for m. It is introduced by
Bellare et al. [4] as a tool to provide several negative results
on differing-inputs obfuscation. However, their construc-
tion is based on indistinguishability obfuscation [14] and
one-way function, thus, does not yield practical schemes.
Moreover, it requires that the punctured signing key is
associated with the full signed message. In contrast our
construction is based on the τ -SDH assumption, and the
string associated with the punctured signing key can be any
particular part of the message to be signed (e.g. the prefix of
the message), which is more flexible and applicable. Halevi
et al. [6] also propose a puncturable signature scheme which
is puncturable at any prefix of the signed message. How-
ever, their puncturable operation needs to update public
keys repeatedly. In practice, it is inefficient to verify the
updated public keys continuously and it is also difficult to
let each user in the system maintain other users’ public keys
updated.

Delegation related signature. Policy-based signature, intro-
duced by Bellare et al. [15], allows a signer to only sign a
message satisfying some policy specified by an authority.
Another related primitive, called functional signature, is
introduced in the work [16]. In functional signature, only
the master signing key can be used to sign any message,
while the authority provides the secondary signing keys for
functions f that allow the signing of any message in the
range of f . Delegatable functional signature is introduced
in the work [17] and supports the delegation of signing
rights with a policy to the designated third party. Append-
only signatures (AOS) [18] is also a related primitive, in
particular, given an AOS signature on a message m, one can
only compute an AOS signature on any message m′ with m
as the prefix. Different from above primitives, puncturable
signature provides a puncture functionality that may repeat-
edly update the secret key to revoke the signing capability for
selected messages in a dynamic manning.

Forward secure signature. A forward secure signature
scheme guarantees the adversary with the compromised
secret key cannot forge signatures relative to previous time
periods. It is proposed by Anderson [19] and then formal-
ized by Bellare et al. [5]. Prior forward secure signatures
are constructed by either using arbitrary signature schemes
in a black-box manner [11] [20] or modifying the existing
signature schemes [5] [10] [21]. All these forward secure
schemes except for [11], the number of time periods T
(arbitrarily large) must be set in advance, such that the
performance depends on T logarithmically or even linearly.
Nevertheless, the performance in [11] still depends on the
time periods elapsed so far.

Proof-of-stake blockchain protocols. Proof-of-stake protocols
were first initiated in online forums and subsequently a
number of proof-of-stake protocols were proposed and im-
plemented by the academic community. In order to provide
forward security (and also achieve resilience against LRSL
attack and other long-range attacks), Ouroboros Paros [9]
and Ouroboros Genesis [22] formalize and realize in the uni-
versal composition setting a forward secure digital signature
scheme, Algorand [23] considers it as one of future work
and implements ephemeral key pairs in its updated full
version [24], whereas Snow White [13] and Ouroboros [12]
adopt a weak adaptive corruption model and cannot avoid
LRSL attack. In addition, several countermeasures have
been proposed, such as the trusted execution environ-
ments [1], checkpointing mechanism [25], and punishment
mechanism revealing the real identity [1], revealing the
signing key [26] or slashing the stake [27] of the malicious
stakeholder.

2 PRELIMINARIES

Notation. Let λ denote the security parameter, ⌊x⌋ denote the
greatest integer less than or equal to x, [n] denote the set of
the first n positive integers, and PPT denote probabilistic
polynomial time. For an array T ∈ {0, 1}n, we let T [i]
denote the i-th bit of the array, if i ≤ n.

We say a function negl(·) : N→ (0, 1) is negligible, if for
every constant c ∈ N, negl(n) < n−c for sufficiently large n.

2.1 Bloom Filter

A Bloom filter [7] is a probabilistic data structure designed
to solve the approximate set membership problem. Specifi-
cally, it can be used to test whether an element is a member



4

of the elements set S from a large universe U rapidly and
space-efficiently, where the false-positive error is allowed.
Put simply, for any s ∈ S the Bloom filter always outputs 1
(“yes”), and for any s /∈ S it outputs 1 only with some small
probability.

Definition 1 (Bloom Filter [8]). A Bloom filter BF for set U
consists of a tuple of PPT algorithms (Gen,Update,Check).

• Gen(ℓ, k): On input two integers ℓ, k ∈ N, the algo-
rithm first samples k universal hash functions H1, . . . , Hk

which generate a uniform distribution over the range
{1, ..., l}, then initializes the ℓ-bit array T = 0ℓ and sets
H = {Hi}i∈[k], and finally returns (H,T ).

• Update(H,T, u): To add an element u ∈ U to S, the
algorithm updates T [Hi(u)] = 1 for all i ∈ [k], leaves
other bits of T unchanged, and returns T .

• Check(H,T, u): To check whether an element u is in S,
the algorithm returns 1 (“yes”) if ∧i∈[k]T [Hi(u)] = 1,
otherwise returns 0 (“no”).

Properties of Bloom filter. The main properties of Bloom filter
used in this paper can be summarized as follows:

Correctness: A Bloom filter always outputs 1 for elements
that have already been added to the set S. More precisely,
if s ∈ U has been added to S and the array T has
been updated by running Update(H,T, s), then we have
Pr[Check(H,T, s) = 1] = 1.

False-positive errors: A Bloom filter may yield a false-
positive error, where an element s∗ is erroneously judged
to be in S by the Check algorithm even though s∗ has
not yet been added to the set S. More precisely, the error
probability is bounded by Pr[Check(H,T, s∗) = 1] ≈
(1− ekn/ℓ)k for any s∗ /∈ S.

Space advantages: The size of representation T is a con-
stant number (i.e., l bits) independent of the size of S.
However, as the size of S increases, false-positive proba-
bility of Bloom filter would increase.

Discussion on the choice of parameters. In bloom filter, assum-
ing the optimal number of hash function k to achieve the
smallest false-positive probability pr, we obtain a size of the
bloom filter given by ℓ = −n ln pr

(ln 2)2 , and the optimal k is given

by k = ⌈ ℓn ln 2⌉. For example, when pr = 10−3 and n = 220,
we have ℓ ≈ 2 MB and k = 10.

2.2 Bilinear Groups and τ -SDH Assumption

We say that G is a bilinear group generator if given
the security parameter Îť, it outputs a tuple params =
(p, e, ψ,G1,G2,GT , P1, P2), where G1, G2 and GT are three
groups having prime order p, Pi is the generator of Gi for
i ∈ {1, 2}, and e : G1 × G2 → GT is a non-degenerate map
satisfying:

• Bilinearity: For any (P,Q) ∈ G1 × G2 and a, b ∈ Z
∗
p,

e(aP, bQ) = e(P,Q)ab holds.
• Non-degeneracy: e(P,Q) = 1 for any Q ∈ G2 iff P = O.
• Computability: There exists an efficient algorithm to com-

pute e(P,Q) for any (P,Q) ∈ G1 × G2.
• There exists an publicly and efficiently computable iso-

morphism ψ : G2 → G1 such that ψ(P2) = P1.

The security of our scheme is based on τ -strong Diffie-
Hellman (τ -SDH) assumption, which was previously for-
malized in [28] and [29].

Definition 2 (τ -Strong Diffie-Hellman Assumption
(τ -SDH)). Let params = (p, e, ψ,G1,G2,GT , P1, P2) ←
G(1Îť) and (P1, P2, ÎąP2, Îą

2P2, ..., Îą
τP2) be a τ + 2

tuple for ι ∈ Z
∗
p. We say τ -SDH assumption

holds if for any PPT adversary A, Pr[(h, 1
h+αP1) ←

A(P1, P2, ÎąP2, Îą
2P2, ..., Îą

τP2)] ≤ negl(λ) with h ∈ Z
∗
p.

3 PUNCTURABLE SIGNATURES

In this section, we formalize the syntax and security def-
inition of puncturable signature, and then we propose a
puncturable signature scheme and prove its security under
the τ -SDH assumption.

3.1 Syntax and Security Definition

Let the message space be M. A puncturable signature
scheme ÎŁ consists of a tuple of PPT algorithms ÎŁ =
(Setup,Puncture, Sign,Verify) with descriptions as follows:

• Setup(1λ, ℓ, k): On input the security parameter λ, param-
eters ℓ and k for the Bloom filter, the setup algorithm
outputs the public key vk as well as the secret key sk.

• Puncture(sk, str): On input the secret key sk and a string
str ∈ M, the puncturing algorithm outputs the updated
secret key sk′ which is also called the punctured secret
key. We also say that str has been punctured.

• Sign(sk,m): On input the secret key sk and a message m,
it outputs a signature σ.

• Verify(vk,m, σ): On input the public key vk, a signature σ
and message m, the verification algorithm outputs 1 if σ
is a valid signature for m. Otherwise, it outputs 0.

Correctness of puncturable signatures. Intuitively, the cor-
rectness requires that (1) signing is always successful with
the initial, non-punctured secret key, (2) signing fails when
attempting to sign a message with a prefix that has been
punctured, and (3) the probability that signing fails is
bounded by some non-negligible function, if the prefix of
the message to be signed has not been punctured.

Definition 3 (Correctness). For any message m with prefix
m′, any (skinit, vk) ← Setup(1λ), and any sequence of
invocations of sk← Puncture(sk, .), we have

1) Verify(vk,m, Sign(skinit,m)) = 1, where skinit is the ini-
tial, non-punctured secret key.

2) If m′ has been punctured, then
Verify(vk,m, Sign(sk′,m)) = 0, where sk′ ←
Puncture(sk,m′).

3) Otherwise, it holds that Pr[Verify(vk,m, Sign(sk,m)) 6=
1] ≤ µ(ℓ, k), where µ(·) is a (possibly non-negligible)
bound.

Remark 1. We notice that the puncturing functionality defined
above is for message-prefix, whose length can be determined
in specific implementation (e.g., the slot parameter in proof-
of-stake blockchain). In specific applications, the message m
to be signed can be split into n (n ≥ 1) parts denoted by
m = m1||...||mi||...||mn, where different parts may have differ-
ent lengths and different semantics, for example, m1 denotes the



5

time stamp and the remaining denotes the message specifics. We
can extend the puncturing functionality by puncturing strings at
arbitrarily pre-defined position (even the whole message), e.g. i-th
part, which means the signing algorithm fails for message m =
m1‖...‖mi‖...‖mn if mi has been punctured. For simplicity, we
still use prefix-puncturing in this paper, but both the definitions
and our constructions can be easily extended to support the
general puncturing functionality.

Security Definition. Intuitively, the security definition of
puncturable signature scheme requires that the adversary
cannot forge signatures on messages having been punctured
even though the punctured secret key is compromised. For-
mally, for any PPT adversary A, we consider the experiment
Expt

ps
A(1Îť) between A and the challenger C:

1) Setup: C computes (vk, sk)← Setup(1λ) and sends vk to
the adversary A. C initializes two empty sets Qsig = ∅
and P = ∅.

2) Query Phase: Proceeding adaptively, the adversary A
can submit the following two kinds of queries:

• Signature query: On input a message m from the
adversaryA, C computes σ ← Sign(sk,m) and updates
Qsig = Qsig ∪ {m}. Then C sends back σ.

• Puncture query: On input a string str, C updates sk by
running Puncture(sk, str), and updates P=P ∪ {str}.

3) Challenge Phase: A sends the challenging string m′ to
C, and A can still submit signature and puncture queries
as described in the Query phase.

4) Corruption query: The challenger returns sk if m′ ∈ P
and ⊥ otherwise.

5) Forgery: A outputs a forgery pair (m,σ).

We say that adversary Awins the experiment Expt
ps
A(1Îť) if

m′ is the prefix of m and m /∈ Qsig ∧ Verify(vk,m, σ) = 1.

Definition 4 (Unforgeability with adaptive puncturing). We
say the puncturable signature scheme ps is unforgeable with
adaptive puncturing, if for any PPT adversary A, the prob-
ability of winning experiment Expt

ps
A(1Îť) is negl(Îť), where

the probability is over the randomness of the challenger and
adversary.

3.2 Our Construction

We present a puncturable signature construction based on
the Chinese IBS, an identity-based signature scheme stan-
dardized in ISO/IEC 14888-3 [30].

The key idea of our construction is to derive secret keys
for all Bloom filter bits i ∈ [l] using IBS schemes, and
then bind the prefix string m′ with k positions where the
secret keys are used to sign messages with prefix m′. In
addition, puncturing at m′ implies the deletion of keys in
the corresponding positions.

Let (p, e, ψ,G1,G2,GT , P1, P2) ← G(1λ), and BF =
(BF.Gen, BF.Update,BF.Check) be a Bloom filter. Choose
a random generator P2 ∈ G2, and set P1 = ψ(P2) ∈ G1.
Let h1 : N → Z

∗
p and h2 : {0, 1}∗ × GT → Z

∗
p be

cryptographic hash functions, which we model as random
oracles in the security proof. The public parameters are
params := (p, e, ψ,G1,G2,GT , P1, P2, h1, h2) and all the
algorithms described below implicitly take params as in-
put. The construction of the puncturable signature scheme
ps = (Setup,Puncture, Sign,Verify) is the following:

• Setup(1λ, ℓ, k): This algorithm first generates a Bloom
filter instance by running ({Hj}j∈[k], T ) ← BF.Gen(ℓ, k).

Then it chooses s
$
← Z

∗
p and outputs

sk = (T, {ski}i∈[ℓ]), vk = (Ppub, g, {Hj}j∈[k]),

where ski =
s

s+h1(i)
P1, Ppub = sP2, and g = e(P1, Ppub).

• Puncture(sk, str): Given a secret key sk = (T, {ski}i∈[ℓ])
where ski =

s
s+h1(i)

P1 or ⊥, this algorithm first computes

T ′ = BF.Update ({Hj}j∈[k], T , str). Then, for each i ∈ [ℓ]
define

sk′i =

{

ski, if T ′[i] = 0
⊥, otherwise

where T ′[i] denotes the i-th bit of T ′. Finally, the algo-
rithm returns sk′ = (T ′, {sk′i}i∈[ℓ]).

• Sign(sk,m): Given a secret key sk = (T, {ski}i∈[ℓ]) and a
message m with the prefix m′, the algorithm first checks
whether BF.Check ({Hj}j∈[k], T , m′) = 1 and outputs
⊥ in this case. Otherwise, note that BF.Check({Hj}j∈[k],
T , m′) = 0 means there exists at least one index ij ∈
{i1, · · · , ik} such that skij 6= ⊥, where ij = Hj(m

′)
for j ∈ [k]. Then it picks a random index ij∗ such that

skij∗ = s
s+h1(ij∗ )

P1. Choose x
$
← Z

∗
p and compute r = gx,

then set
h = h2(m, r), S = (x− h)skij∗ .

The output signature on m is σ = (h, S, ij∗).
• Verify(vk,m, σ): Given a public key vk =
(Ppub, g, {Hj}j∈[k]), a message m with the prefix
m′, and a signature σ = (h, S, ij∗), the algorithm checks
whether

ij∗ ∈ Sm′ ∧ h = h2
(

m, e(S, h1(ij∗)P2 + Ppub)g
h
)

,

where Sm′ = {Hj(m
′) : j ∈ [k]}. If it holds, the algorithm

outputs 1, and 0 otherwise.

Lemma 3.1. Our basic construction described above satisfies
correctness (c.f. Definition 3).

Proof. If the secret key is initial and non-punctured, we have

e(S, h1(ij∗)P2 + Ppub)g
h

= e((x− h).
s

h1(ij∗) + s
P1, (h1(ij∗) + s)P2).e(P1, P2)

hs

= e(P1, P2)
xs−hse(P1, P2)

hs = gx = r

and then h = h2
(

m, r) = h2(m, e(S, h1(ij∗)P2 + Ppub)g
h
)

.
Therefore, the first requirement of Definition 3 holds. If m′

is punctured, by the correctness of Bloom filter, we have
BF.Check(H,T,m′) = 1, which means all the secret keys
used to sign messages with m′ as the prefix have been
deleted. Therefore, the signing of the message m with the
prefix m′ fails and the second requirement of Definition 3
holds. If m′ is not punctured, the correctness error of our
construction occurs only when BF.Check(H,T,m′) = 1,
which is essentially identical to the false-positive probability
of the Bloom filter, and the third requirement of Definition 3
holds.

Remark 2. In this section, we assume that the false-positive
probability from Bloom filter is acceptable, which means the
number of puncturings supported by our construction is below



6

a pre-set parameter, depending on the application scenarios and
the upper bound n of the Bloom filter. In the security proof below,
we assume that the number of puncturing queries is also bounded
by the pre-set parameter.

Theorem 1. Assuming that an algorithm A wins in the
Expt

ps
A(1Îť) experiment (c.f. Definition 4) to our construc-

tion ps, with the advantage ǫ0 ≥ 10k(qS + 1)(qS +
qh2

)/
(

p(1 − (1 − 1/l)k)
)

within running time t0, τ -SDH
assumption can be broken for τ = qh1

within running time
t2 ≤ 120686qh2

t0/(ǫ0(1 − τ/p)), where qh1
, qh2

and qS are
the maximum query times of the hash function h1, h2 and
signing, respectively.

Proof. In order to prove the security of our scheme, we con-
sider a particular adversary B with a fixed position against
our signature scheme in a variant of the above experiment

Expt
ps
A(1Îť), denoted by Expt

fps
A (1Îť). Specifically, in the

Setup, the challenger returns system parameters together
with a fixed position i∗ ∈ [l]; the following Query Phase
remains unchanged and the Challenge Phase can be omit-
ted; in the Corruption query, the challenger only returns the
current secret key by excluding the key at position i∗. We

say B wins the experiment Expt
fps
A (1Îť), if B outputs the

message m together with a valid signature (h, S, i∗) on m.
We sketch the proof in two steps as in [31] [32]. First,

we prove there exists an algorithm B that wins in the

Expt
fps
A (1Îť) experiment with a non-negligible advantage,

if the adversary A has a non-negligible advantage against
our signature scheme ps in the Expt

ps
A(1

Îť) experiment (c.f.
Lemma 3.2). Then, assuming the existence of B, we can
construct an algorithm C that breaks the τ -SDH assumption
(c.f. Lemma 3.3).

Lemma 3.2. Assuming that an algorithm A wins in the
Expt

ps
A(1Îť) experiment (c.f. Definition 4) to our construc-

tion ps, with a probability ÇŤ0 within running time t0, there

exists an algorithm B that wins in the Expt
fps
A (1Îť) exper-

iment as described above to ps which has a probability
ǫ1 ≥ ǫ0(1− (1− 1/l)k)/k within running time t1 ≤ t0.

Proof. Suppose there exists such an adversary A, and we
construct a simulator B that simulates an attack environ-
ment and uses A’s forgery to win in its own Expt

fps
A (1Îť)

experiment. The simulator B can be described as follows:

• Invocation. B is invoked on a given position i∗ ∈ [l].
• Queries. B answers adaptive queries from A as follows:

– B makes the Setup query and forwards all the returned
parameters to A for A’s Setup query.

– BeforeA outputs the challenging string, B just forwards
the queries of A, including Sign, Puncture, h1 and h2,
to its experiment and returns the result to A.

– When A outputs the challenging string denoted by
m′ after the series of queries, B checks whether i∗ ∈
{Hj(m

′) : j ∈ [k]} and aborts if this does not hold.
Otherwise, B provides the simulation for A as follows.
For the queries h1, h2, Puncture and Sign, B just passes
them to its challenger and returns the result as before.
While for Corruption query, B firstly checks whether
m′ ∈ P and returns ∅ if this does not hold. Otherwise, B
makes Corruption query in its experiment, and returns
the response sk to A.

Eventually, A outputs a valid signature (m,σ =
(h, S, j∗)), where m′ is the prefix of m. If jâ";"""date"",""2019-10-16T00:49:11Z""
""pdf:PDFVersion"",""1.4""
""xmp:CreatorTool"",""Acrobat PDFMaker 15 Excel 版""
""pdf:docinfo:title"",""""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.4""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""4-eps-converted-to.pdf""
""xmp:CreateDate"",""2019-06-14T20:15:17Z""
""modified"",""2019-10-16T00:49:11Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""xmp:ModifyDate"",""2019-09-09T22:27:57Z""
""pdf:docinfo:creator"",""""
""meta:author"",""lixinyu""
""meta:creation-date"",""2019-10-16T00:49:11Z""
""created"",""2019-10-16T00:49:11Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-10-16T00:49:11Z""
""resourceName"",""1909.03955""
""Author"",""lixinyu""
""producer"",""dvips + GPL Ghostscript GIT PRERELEASE 9.22""
""pdf:docinfo:producer"",""dvips + GPL Ghostscript GIT PRERELEASE 9.22""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""271"",""1"",""10"",""11"",""13"",""1"",""0"",""4"",""0"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""lixinyu""
""dcterms:created"",""2019-10-16T00:49:11Z""
""Last-Modified"",""2019-10-16T00:49:11Z""
""dcterms:modified"",""2019-10-16T00:49:11Z""
""title"",""4-eps-converted-to.pdf""
""xmpMM:DocumentID"",""uuid:aa34f3c6-9625-48b6-b5fd-9d705821e4b4""
""Last-Save-Date"",""2019-10-16T00:49:11Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2019-10-16T00:49:11Z""
""meta:save-date"",""2019-10-16T00:49:11Z""
""Content-Length"",""375838""
""Content-Type"",""application/pdf""
""xmp:MetadataDate"",""2019-09-09T22:27:57Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""lixinyu""
""pdf:producer"",""Acrobat Distiller 9.0.0 (Windows)""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""13""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""4775"",""5756"",""4439"",""4587"",""4535"",""4976"",""4430"",""5360"",""4416"",""4561"",""5659"",""3722"",""5022""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-10-16T00:49:11Z""
";https://scholar.google.com/scholar?start=290&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095404-1717;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Availability of Smart Contracts that Rely on External Data;T Guo, D Han Herzegh ;2020 divaportal.org;;"… 41 5.2 Retrieving data using multiple oracles with one oracle contract . . . . .

42 … Since the creation of Bitcoin, multiple blockchains and blockchain networks

have been created, with varying degrees of adoption …";Autres articles;Version HTML;[PDF] diva-portal.org;https://www.diva-portal.org/smash/get/diva2:1466902/FULLTEXT01.pdf;"
Linköpings universitetSE–581 83 Linköping+46 13 28 10 00 , www.liu.se

LinkĂśping University | Department of Computer and Information Science
Master’s thesis, 30 ECTS | Computer Science

2020 | LIU-IDA/LITH-EX-A--20/054--SE

Availability of Smart Contractsthat Rely on External Data
Tillgänglighet av Smarta Kontrakt Beroende av Extern Data

Tjelvar Guo
Daniel Han Herzegh

Supervisor : Felipe BoeiraExaminer : Mikael Asplund

http://www.liu.se


Upphovsrätt

Detta dokument hålls tillgängligt på Internet - eller dess framtida ersättare - under 25 år från publicer-ingsdatum under förutsättning att inga extraordinära omständigheter uppstår.Tillgång till dokumentet innebär tillstånd för var och en att läsa, ladda ner, skriva ut enstaka ko-pior för enskilt bruk och att använda det oförändrat för ickekommersiell forskning och för undervis-ning. Överföring av upphovsrätten vid en senare tidpunkt kan inte upphäva detta tillstånd. All annananvändning av dokumentet kräver upphovsmannens medgivande. För att garantera äktheten, säker-heten och tillgängligheten finns lösningar av teknisk och administrativ art.Upphovsmannens ideella rätt innefattar rätt att bli nämnd som upphovsman i den omfattningsom god sed kräver vid användning av dokumentet på ovan beskrivna sätt samt skydd mot att dok-umentet ändras eller presenteras i sådan form eller i sådant sammanhang som är kränkande för up-phovsmannens litterära eller konstnärliga anseende eller egenart.För ytterligare information om Linköping University Electronic Press se förlagets hemsida
http://www.ep.liu.se/.

Copyright

The publishers will keep this document online on the Internet - or its possible replacement - for aperiod of 25 years starting from the date of publication barring exceptional circumstances.The online availability of the document implies permanent permission for anyone to read, to down-load, or to print out single copies for his/hers own use and to use it unchanged for non-commercialresearch and educational purpose. Subsequent transfers of copyright cannot revoke this permission.All other uses of the document are conditional upon the consent of the copyright owner. The publisherhas taken technical and administrative measures to assure authenticity, security and accessibility.According to intellectual property law the author has the right to bementionedwhen his/her workis accessed as described above and to be protected against infringement.For additional information about the LinkĂśping University Electronic Press and its proceduresfor publication and for assurance of document integrity, please refer to its www home page:
http://www.ep.liu.se/.

Š Tjelvar GuoDaniel Han Herzegh

http://www.ep.liu.se/
http://www.ep.liu.se/


Abstract

Smart contracts are digital agreements stored and executed on a blockchain. With smart
contracts, multiple parties can enter into an agreement whose correct execution is guaran-
teed by the underlying blockchain. However, there is no inherent way for smart contracts
to access data APIs external to the blockchain they reside on, which is needed in order
to expand their usefulness. This thesis investigates two approaches of feeding data to a
smart contract on the Ethereum blockchain, with regard to the performance metrics gas
cost, block delay, and network latency. The investigation is set in the context of train travel
where the time of arrival of a train at its destination is retrieved to the smart contract. Re-
ceiving and aggregating submissions from varying numbers of passengers is compared
to retrieving this data from the dedicated open API provided by Trafikverket using the
Chainlink framework. Through experiments, involving issuing transactions and monitor-
ing them, it was found that in the case of passenger submissions with aggregation the gas
costs had a linear relationship to the amount of passengers submitting data. Compared
to lower amounts, the block delay for passenger submissions started seeing an increase
at 100 to 300 submissions whereas it was more or less constant for aggregations. Further-
more, there was no noticeable trend for increase in network delay with increase of submis-
sions. Conclusively, with regard to all performance metrics, it was found that in all cases
involving more than five passengers it was cheaper to use Chainlink to fetch data from
Trafikverket.



Acknowledgments

Conducting a master thesis in the midst of a global pandemic has been a unique experience.
One which has tested our ability to work independently. However, like any other major
project it could not have been carried out without the help of others. First of all, we would
like to thank our supervisor Felipe Boeira and our examiner Mikael Asplund for taking us
on and assisting us during this project by giving us valuable feedback. In a similar vein, we
would like to extend our gratitude to our opponents Samuel Blomqvist and BjĂśrn Detterfelt
for helping us improving the thesis with their feedback.

We would also like to thank Kevin SĂśderberg at HiQ ACE for sharing his time and for
being available for discussions as well as for providing us with educational content on smart
contract development.

Appreciation is also extended to the various online communities in which we have par-
taken. We would like to thank two communities in particular; The Ethereum stack exchange
community for always being available for question answering and for all the interesting
discussions, and the Chainlink discord community and the Chainlink developer team for
being generous with their time and answering questions regarding the framework and how
it is used. Lastly, we would like to thank our friends and family for always being there and
checking up on us.

Tjelvar Guo
Daniel Han Herzegh
September 2020

iv



Contents

Abstract iii

Acknowledgments iv

Contents v

List of Figures vii

List of Tables viii

Acronyms 1

1 Introduction 2
1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 Aim . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3 Research Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.4 Method Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.5 Delimitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2 Theory 5
2.1 Blockchain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2 Transactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3 Proof-of-Work and Mining . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.4 Blockchain Forks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.5 Block Limits and Gas Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.6 Smart Contracts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.7 Oracles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.8 Development Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.9 SJ & The Swedish Transport Administration . . . . . . . . . . . . . . . . . . . . . 12
2.10 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3 Method 17
3.1 Building a Smart Contract System . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.2 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

4 Results 29
4.1 DeRail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.2 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

5 Discussion 38
5.1 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
5.2 Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
5.3 The Work in a Wider Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

v



6 Conclusion 48
6.1 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

Bibliography 51

A Appendix: Chainlink Node Configuration 55
A.1 Virtual Machine Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
A.2 Chainlink Set Up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

B Appendix: External Adapter 57

C Appendix: Merged Results 58

vi



List of Figures

2.1 The proof-of-work process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2 Chainlink flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3.1 Structural representation of the system with additional components used for the
evaluation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.2 Retrieving data from passengers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.3 Retrieving data from trafikverket . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

4.1 DeRail contract structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.2 Gas usage for submissions part of retrieving data from passengers . . . . . . . . . 34
4.3 Gas usage for aggregation part of retrieving data from passengers . . . . . . . . . . 34
4.4 Submission block delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.5 Submission network latency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.6 Aggregation block delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.7 Aggregation network latency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

5.1 Retrieving data using multiple oracles . . . . . . . . . . . . . . . . . . . . . . . . . . 41
5.2 Retrieving data using multiple oracles with one oracle contract . . . . . . . . . . . 42

C.1 Total gas usage for retrieving data from passengers . . . . . . . . . . . . . . . . . . 58
C.2 Total block delay for retrieving data from passengers . . . . . . . . . . . . . . . . . 59
C.3 Total Network latency for retrieving data from passengers . . . . . . . . . . . . . . 60
C.4 Network latency for submissions and aggregations combined . . . . . . . . . . . . 61

vii



List of Tables

4.1 Gas cost - frequency pairs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.2 Block delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.3 Network latency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

A.1 Machine configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
A.2 Boot disk settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
A.3 General firewall rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
A.4 Custom firewall rule settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

B.1 Cloud function settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

viii



Acronyms

EOA Externally Owned Account

EVM Ethereum Virtual Machine

TAL Time At Location

1



1 Introduction

This chapter introduces the concepts of smart contracts and blockchain technology. These
concepts serve as context leading into the presented problem and research questions of this
thesis.

1.1 Motivation

The term smart contract was coined by Nick Szabo in his 1994 essay Smart Contracts [37].
Szabo describes a smart contract as a “computerised transaction protocol that executes the
terms of a contract” in a way that ""minimises the need for trusted intermediaries"". In recent
years this concept has seen a rise in interest due to the invention of blockchain technology. A
blockchain is a form of distributed ledger technology and is essentially a digital, distributed
ledger whose contents are calculated and stored by multiple nodes in a network, where a
node is a server or computer running a specific program. To paraphrase, every node in the
network has its own local copy of the ledger. The agreed upon state of the blockchain is
determined by the majority of nodes reaching consensus through some mechanism. This
decentralisation is one of the key components which contributes to giving the blockchain the
properties of high tamper resistance and assurance of uptime by minimising trust needed for
any single node.

The first blockchain use case, Bitcoin, is used to store a shared record of transactions of
the native currency with the same name [31]. In 2014, the capabilities of a blockchain were
further explored by Vitalik Buterin with the introduction of the Ethereum blockchain [4, 42].
His proposition was a blockchain which allowed for storage and execution of programs writ-
ten in the native Turing complete programming language upon which the blockchain itself
is built. A program, whose design and execution is reliable, tamper resistant and minimises
the need for trusted intermediaries is essentially a smart contract as it was described by Nick
Szabo. Henceforth, in this paper, the term smart contract is used to describe such a program
which is stored and executed on a blockchain.

While the notion of a smart contract does sound like an attractive proposition, currently
available solutions are still not without their imperfections. For many of the potential use
cases there are still significant problems to consider and hurdles to overcome. A problem

2



1.1. Motivation

which has until recently garnered relatively little attention in the academic literature is the
validity and availability of decentralised data inputs.

Assuming code execution on a blockchain is trustworthy enough for certain use cases,
these use cases might still rely on the values of external data. For example, consider a smart
contract which depends on some input. If the value of the input is X it will execute A, and
if instead the value of the data is Y it will execute B. In such a case it does not matter how
secure the code executions of a smart contract are if the data it receives is faulty or if the data
is not received at all. If a lot of interest lies in the outcome of the smart contract execution, it is
important that the correct execution is guaranteed. Thus, it is important that the availability
and security of the data source and the data retrieval is sufficient enough to resist possible
malicious behaviour or other vulnerabilities which could otherwise cause the resulting data
to be unavailable or faulty.

In the academic literature, there are multiple proposals of how to securely relay data between
a data source and a smart contract [28, 33, 44]. Less consideration is given to the data
sources themselves within the context of smart contracts and decentralised systems. It is
not unreasonable to assume that the data source is treated as a trusted third party, even in a
decentralised context. On the other hand, it could be argued that having a single data source,
conflicts with the security logic of the blockchain and smart contract space where a major
component is to minimise trust needed for any single third party. However, in a lot of cases
there are few traditional sources, in some cases just one, which provide the desired data.
Nevertheless, a lack of traditional data sources does not necessarily imply a lack of potential
data sources. This is especially true in cases where there exist independent entities which
are able to report their own respective values. These entities create a new decentralised data
source of sorts which is comparable to the already established trusted data source. Thus, it
would be interesting to explore and investigate a case which is dependent on some piece of
data, where there is both an established single trusted data source accessible via an API and
an alternative, decentralised approach to obtain this data, and compare these.

While it can be discussed whether one data retrieval solution is better than the other for
ensuring the validity of external data, an equally important aspect is performance. The
component of decentralisation, which contributes to the security of the blockchain, also has
a drawback. Due to all operations being carried out by a network of nodes, a much larger
computational cost is generated in a blockchain environment compared to traditional sys-
tems. Therefore, a computationally expensive data retrieval method can result in the data
being unavailable for an extended period of time. In turn, this would affect the availability
of a smart contract system dependent on that data. Therefore, the dimension of measuring
the performance costs is crucial when evaluating and comparing two data retrieval methods.

In this thesis the investigation is set within the context of train travel and train ticket systems.
As per Swedish law the government-owned railway company, SJ, has a set of conditions,
using the time at location (TAL), for determining refunds in case of delays [24]. The TAL is
simply the time at which a train arrives at its destination. There are several reasons as to
why a train ticket system is suitably implemented as a smart contract that based on a TAL
automatically issues correct refunds. It could reduce the administrative time for passengers
and SJ spent on claiming and processing refunds, respectively. Passengers would not act-
ively need to apply for refunds and SJ would not need to handle them. A smart contract
on the Ethereum blockchain acts autonomously on a transparent platform which decreases
the amount of trust passengers need to place on SJ for correctly receiving refunds eligible to
them. In essence, the smart contract acts as an independent escrow between SJ and its paying
customers.

3



1.2. Aim

1.2 Aim

In order for a system, as described in Section 1.1, to function correctly it is reliant upon
receiving the correct TAL. Currently, the Swedish Transport Administration, Trafikverket,
is the only entity openly providing this data. However, the passengers carrying internet
connected mobile phones also have the ability to provide this information and thus act as a
decentralised data source.

The aim of this thesis is to investigate and compare two approaches of retrieving data to
a smart contract. In this case this entails retrieving the time, at which a train arrives at
its destination, to a smart contract system with regard to system design, availability and
performance costs. The first approach uses a trusted centralised data source to feed a smart
contract with data and the second approach uses a decentralised source in the form of direct
submissions of data from passengers of a trip to the smart contract.

1.3 Research Questions

This thesis is an empirical study utilising experiments to conduct exploratory research where
the following research question is investigated.

What are the differences in a smart contract system, in terms of performance costs,
between having the members of a decentralised data source individually submit data and
fetching data from a conventional data source?

1.4 Method Overview

In this study, a simplified train ticket system was implemented as a smart contract on the
Ethereum blockchain. Functionality was implemented in order to retrieve external data ac-
cording to the two approaches specified in the research question, where the external data is
the arrival time of a train at its destination. The first approach with the decentralised source
consisted of simulated passengers submitting this data which was then aggregated to a single
value by the contract. The other approach consisted of a system which fetched the data from
Trafikverket’s API. Using these implementations, multiple tests were run in which data was
retrieved to the smart contract. Based on the results of these tests, the two approaches were
then compared with regard to the performance metrics gas cost, block delay, and network
latency.

1.5 Delimitations

Due to monetary and time related constraints, delimitations have been made to the project.

• Research conducted within this thesis is constrained within the Ethereum ecosystem.

• Investigating the correlation between the user specified gas limit and the performance
of blockchain transactions is outside the scope of this project.

• Effects on perceived levels of trust between parties involved, as a consequence of im-
plementing the smart contract system, are not taken into account or measured.

• Considerations have mainly been taken with regard to the context area of the thesis i.e
train travel.

• The smart contract system built does not verify the legitimacy or validity of data re-
ceived regarding the TAL.

4



2 Theory

This chapter presents background theory about the context areas of blockchain, smart con-
tracts, external data retrieval, and train travel in Sweden. Furthermore, domain specific de-
velopment tools applied in this thesis are described. The last section consists of a presentation
of related work.

2.1 Blockchain

In 2008, the first blockchain was invented by one or several people using the pseudonym
Satoshi Nakamoto [31]. Its purpose was to serve as the public transaction ledger for the
cryptocurrency Bitcoin and its network of participating nodes. Since the creation of Bitcoin,
multiple blockchains and blockchain networks have been created, with varying degrees of
adoption. In this thesis, however, the majority of the focus lies on the public blockchain
Ethereum.

A blockchain can be thought of as a distributed, public ledger which stores all transac-
tions that have been conducted by participants in the network [39]. The name blockchain
originates from the design of this ledger, which can be viewed as a growing linked list of
blocks, where each block contains a group of permanently stored transactions. Identical
copies of the ledger are stored by participants in that blockchain network. Henceforth, these
participants will be referred to as nodes.

2.2 Transactions

A transaction can be thought of as an externally triggered event that changes the current state
of the blockchain. It is “externally triggered” in the sense that an entity “outside” the block-
chain, off-chain, must initiate it using an externally owned account (EOA) [14]. In many cases
transactions are about the movement of digital tokens between two accounts. For example,
consider that Lisa wants to send 2 ether, which is the native token of the Ethereum block-
chain [25], from her EOA to Michael’s EOA. An EOA can be thought of as a pair consisting
of a public key and a private key. For Michael to receive a transaction, Lisa has to know
what the public key to his account is (from which she can derive an address). In order for

5



2.3. Proof-of-Work and Mining

Lisa to submit the transaction she has to sign the transaction with her private key. She then
propagates this transaction to the nodes of the Ethereum network. Assuming that her sig-
nature shows that she has the valid private key, and that she possesses the amount of ether
which is to be moved, the nodes of the network further relay the valid transaction to other
nodes. It is, however, not stored on the blockchain yet as all nodes must first reach consensus
on the content and order of the blocks. When this is done, Michael receives the ether. In order
to ensure that all nodes store identical copies of the ledger a consensus mechanism is used.
In the cases of both Bitcoin and Ethereum, this is currently achieved through a process called
proof-of-work [23].

2.3 Proof-of-Work and Mining

While the work of most nodes in the Ethereum network consists of storing a copy of the
ledger, and to validate and relay newly created blocks to other nodes, there are some nodes
known as miners [15]. Miners are nodes that compete with each other in order to create
the next block of the blockchain. This is where the concept of proof-of-work comes into
play. Each block in the blockchain has an associated hash sum which has been computed
by the miner of that block, using the transactions in the block, the hash sum of the previous
block, and an arbitrary number, referred to as the nonce. Before a new block is created and
added to the blockchain, each miner groups pending valid transactions into a block. The
miner then computes a hash sum using the previously mentioned parameters. In order to
create an accepted block, the computed hash sum, which is interpreted as an integer, must
be smaller than some target value set by the underlying blockchain protocol. Most of the
mining process therefore consists of generating new hash sums by trying different nonces
until one miner eventually finds a valid hash sum. That miner signs the block and propagates
it to the network of nodes, which verifies the validity of the solution and the contents of the
block. If successful, the node adds the block to their copy of the ledger and relays it further
to other nodes [45]. The transactions included in the newly mined block that is part of the
blockchain, have thus received a block inclusion. The miner of the block receives a block reward,
in Ethereum these are newly created ether, as well as the transaction fees associated to the
transactions of the block.

The proof-of-work process is what makes the blockchain tamper resistant. Changing a
block in the past by, for example, altering the transactions within it will cause the hash sum
of that block to change. This will consequently cause all subsequent blocks after it to become
invalid since they store the hash of the previous block. The process is illustrated in Figure 2.1.

Figure 2.1: The proof-of-work process

2.4 Blockchain Forks

There are occasions when multiple miners each find a valid hash sum at the same time and
propagate their respective block to the network [25]. Depending on the positions of the
miners in the network their proposed blocks reach different nodes at different times, but

6



2.5. Block Limits and Gas Usage

since both blocks are valid they are temporarily accepted by all nodes. These blocks share
the same predecessor, or parent block, and thus the situation results in a blockchain fork. This
is a problem since the consensus and determinism of the blockchain is based on there being
one uniform chain, which all nodes agree upon. To account for and solve this problem, the
blockchain protocol has the rule that the longest blockchain prevails. This is where the no-
tion of block confirmations arise. In order to determine the main chain in the occurrence of a
fork, nodes simply wait a number of blocks before considering a block of transactions to be
valid. The more blocks added since the block in question, the more certain a node can be that
the block is part of the main chain. Accordingly, the fork which first becomes longer than
the other “wins” and becomes the main chain. The discarded blocks in the shorter chain are
called uncles. If the transactions in an uncle has not already been included in the main chain
the transactions are considered pending transactions, which are waiting to be included in the
main chain. This kind of forking is not a rare occurrence. At the time of writing this report,
the uncle rate, which is the rate at which uncles are produced, for the Ethereum mainnet is
between 6-7%1.

2.5 Block Limits and Gas Usage

Conducting operations on a blockchain network, which is what constitutes a transaction, is
both inefficient and resource expensive. This is the case since all nodes in the network must
compute the operations of the transaction and also store all transactions that have ever been
conducted on the blockchain. Thus, in order to avoid congesting the network and exceed
the storage capacities of nodes, there is both a target time interval at which new blocks are
generated as well as a set limit on the amount of operations that can be included into each
block. The target time interval, often referred to as block time, is 12 seconds [15, 40]. In or-
der to express the finite resource of available computations in each block, there exists a unit
called gas. For all operations there is a corresponding value of gas which represent the com-
putational cost to perform that operation. These values are set by the Ethereum developers.
The earlier mentioned transaction fee is the amount of ether the initiator is ready to pay per
unit of gas, gas price, which the transaction requires. The limit of computations that can be
included in each block is expressed as the block gas limit. The amount of gas a transaction
requires is referred to as gas cost or gas usage. Sometimes the total accumulated gas cost for
pending transactions, i.e. transactions that have not yet been included into the blockchain,
exceeds the block gas limit. In these cases it is up to the miner of the block to decide which
transactions are included. Since the miner gets rewarded with fees, they have an incentive to
choose transactions with the highest set gas prices. Thus, instead of being “first come, first
served”, the throughput of transactions on the blockchain can oftentimes be more reliant on
economic incentives at times of high traffic.

2.6 Smart Contracts

While many transactions consist of moving digital assets between two accounts, there are
multiple other types of operations which can constitute a transaction. Ethereum was the
first blockchain which allowed for Turing complete computing using the Ethereum Virtual
Machine (EVM) [42]. Programs (i.e smart contracts) are stored on the blockchain as EVM
bytecode [20] and then executed by nodes, using the EVM. To write smart contracts, it is most
common to use the programming language Solidity2, which is a high level language being
developed for this purpose. Similarly to an EOA, a smart contract has a contract account
which can receive, store and send digital tokens, such as ether. Transactions involving a
smart contract must be initiated by an EOA.

1https://ycharts.com/indicators/ethereum_uncle_rate (visited on 12/05/2020)
2https://solidity.readthedocs.io/

7

https://ycharts.com/indicators/ethereum_uncle_rate
https://solidity.readthedocs.io/


2.7. Oracles

2.7 Oracles

In order for all nodes to maintain consensus, the execution of the smart contract code in the
EVM “must be totally deterministic and based only on the shared context of the Ethereum
state and signed transactions” [1]. This property has a significant effect on the possibilities of
bringing external data on-chain. Among other things, it means that a smart contract cannot
make calls which request data from an external API. Consider what effects such a feature
would have on the network consensus. For two identical requests, the same API can at two
different times yield two different results. Thus two nodes, computing transactions in the
Ethereum network, run the risk of getting different results when executing the code retriev-
ing the data. Their end states will consequently differ from each other despite having run the
same code under the same on-chain context. This will cause an inability for the network to
reach consensus.

Since all nodes can agree on and reach consensus on the contents of transactions signed
by an EOA, external data can be introduced to the Ethereum blockchain in such a way. An
entity which uses this method to bring data to smart contracts can be considered an oracle [1].
Using this broad definition, oracles can be human, software, or hardware.

Within the blockchain space, a known issue is the oracle problem. Ideally, an oracle will
bring required data to a smart contract trustlessly, i.e. data should always be delivered on
time and be valid. There are several proposals in the literature as to how this can be achieved.
These are presented in Section 2.10.2.

2.8 Development Tools

In this section, domain specific development tools applied for the work conducted in this
thesis are presented.

2.8.1 Solidity

As mentioned in Section 2.6, smart contracts are stored as EVM bytecode. However, they are
seldom written directly as such, but rather they are written through the use of some high
level language. In this project the programming language called Solidity was chosen for this
task. While there are alternatives3, Solidity was chosen for multiple reasons. It is developed
by the core maintainers of Ethereum, it is the most mature language currently available, it
has a large community support, and is the only language that has a pinned repository in
the official Ethereum GitHub. At the time of writing the latest version of Solidity is v0.6.34.
However, du";"""date"",""2020-08-29T09:35:51Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2020-08-29T09:35:51Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""Tjelvar Guo, Daniel Han Herzegh""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.19 (TeX Live 2018) kpathsea version 6.3.0""
""meta:author"",""Tjelvar Guo, Daniel Han Herzegh""
""trapped"",""False""
""meta:creation-date"",""2020-08-29T09:35:51Z""
""created"",""2020-08-29T09:35:51Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-08-29T09:35:51Z""
""resourceName"",""FULLTEXT01.pdf""
""Author"",""Tjelvar Guo, Daniel Han Herzegh""
""producer"",""pdfTeX-1.40.19""
""pdf:docinfo:producer"",""pdfTeX-1.40.19""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""Tjelvar Guo, Daniel Han Herzegh""
""dcterms:created"",""2020-08-29T09:35:51Z""
""Last-Modified"",""2020-08-29T09:35:51Z""
""dcterms:modified"",""2020-08-29T09:35:51Z""
""title"",""""
""Last-Save-Date"",""2020-08-29T09:35:51Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2020-08-29T09:35:51Z""
""meta:save-date"",""2020-08-29T09:35:51Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.19 (TeX Live 2018) kpathsea version 6.3.0""
""Content-Length"",""1403588""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Tjelvar Guo, Daniel Han Herzegh""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""69""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""363"",""1918"",""1366"",""1180"",""1353"",""287"",""1238"",""491"",""76"",""1926"",""3556"",""2447"",""1699"",""2638"",""3403"",""2968"",""3128"",""2390"",""3041"",""2647"",""3783"",""3469"",""3433"",""170"",""2129"",""968"",""2950"",""2829"",""3197"",""2576"",""2870"",""2858"",""54"",""2599"",""1644"",""55"",""1805"",""45"",""3378"",""3391"",""2832"",""148"",""1434"",""599"",""150"",""1706"",""3249"",""3208"",""1938"",""2042"",""3041"",""2984"",""3112"",""3271"",""1315"",""1870"",""3347"",""673"",""1881"",""2900"",""2878"",""808"",""577"",""1361"",""284"",""175"",""58"",""62"",""1530""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-08-29T09:35:51Z""
";https://scholar.google.com/scholar?start=520&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095404-1715;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Blockchain and Distributed Ledger Technology Applications;AN Turi ; Technologies for Modern Digital Entrepreneurship, 2020  Springer;;"… The third solution in this regard is the off-chain oracles in which external entities … determining

optimal mechanism design that maximizes the social welfare function of the blockchain network …

Network effects with increased usage of a cryptocurrency result in the appreciation of the …";;null;null;;;;https://scholar.google.com/scholar?start=520&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095302-1274;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;[HTML][HTML] Designing secure blockchain-based access control scheme in IoT-enabled Internet of Drones deployment;B Bera, D Chattaraj, AK Das ; Computer Communications, 2020  Elsevier;;"… Once the blocks are added into the blockchain, the transactions containing in the blocks cannot

be altered, modified or even removed. We provide all sorts of security analysis including formal

security under the random oracle model, informal security and simulation-based …";Cité 30 fois;Les 2 versions;[HTML] sciencedirect.com;https://www.sciencedirect.com/science/article/pii/S0140366419318377?casa_token=SrkJbWjW1MIAAAAA:KhJahflwL5-Hzpx3TLwgfFEaXYcxAjpQV9JMCeGcb-At23u4Bqiww3UPYzXghWNIp7phBL0I;;;https://scholar.google.com/scholar?start=80&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095406-1728;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;?????????????;??? ; ????????????????, 2020  airitilibrary.com;;"… In addition to the blockchain, no additional sever is required to solve the Oracle problem.

Cryptographic Sortition generated based on Verifiable Random Function is used to con-stitute

a consensus algorithm to achieve a consensus on Oracle's authenticity …";Autres articles;;null;;;;https://scholar.google.com/scholar?start=530&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095349-1477;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Evaluation Blockchain Using COSOEvaluation Blockchain Using COSO;NE Vincent, R Barkhi ; Current Issues in Auditing  meridian.allenpress.com;;"… Retrieved from https://www2.deloitte.com/us/en/pages/technology/articles/deloitte-oracle-value-

driven- supply-chain-by-blockchain-iot.html … What impact will blockchain have on the existing …

consensus protocol, communication protocol, smart contracts, Dapps, and oracles …";;null;null;;;;https://scholar.google.com/scholar?start=280&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095299-1264;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Blockchain Oracle for Random Number Generator using Irregular Big Data;SW Jung ; Convergence Security Journal, 2020  koreascience.or.kr;;"Blockchain 2.0 supports programmable smart contract for the various distributed application. 
However, the environment of running smart contract is limited in the blockchain, so the smart 
contract only get the deterministic information, such as block height, block hash, and so on …";Autres articles;Version HTML;[PDF] koreascience.or.kr;https://www.koreascience.or.kr/article/JAKO202022762160514.pdf;"
https://doi.org/10.33778/kcsa.2020.20.2.069

비정형 빅데이터를 이용한 난수생성용 블록체인 오라클★

정 승 욱*

요 약

블록체인 2.0은 프로그래밍 가능한 스마트계약을 사용하여 다양한 DApp(Distributed Application) 개발을 지원한다. 하지만

스마트계약이 동작하는 환경은 블록 높이, 블록 해쉬, 트랜잭션 해쉬 등 결정된 데이터만 접근할 수 있어서 블록체인 기반 복

권, 배팅, 키 생성 등 난수를 필요로 하는 응용은 블록체인 외부에서 데이터를 가져 올 수 있는 오라클 서비스를 이용해야 한

다. 본 논문에서는 난수 생성 오라클 서비스를 개발하였다. 또한 난수 생성을 위해 비정형 빅데이터를 entropy source로 사용

하였다. 이렇게 생성된 난수를 NIST SP800-22 난수 테스트하여 난수로 사용할 수 있음을 확인하였다. 또한, 물리적 세계를

entropy source로 사용하는 기존의 진성난수 생성기에 비해서 비용측면에서 유리함을 설명한다.

Blockchain Oracle for Random Number Generator using Irregular Big Data

Seung Wook Jung*

ABSTRACT

Blockchain 2.0 supports programmable smart contract for the various distributed application. However, the environment

of running smart contract is limited in the blockchain, so the smart contract only get the deterministic information, such

as block height, block hash, and so on. Therefore, some applications, which requires random information, such as lottery

or batting, should use oracle service that supply the information outside of blockchain. This paper develops a random

number generator oracle service. The random number generator oracle service use irregular big data as entropy source.

This paper tests the randomness of bits sequence generated from oracle service using NIST SP800-22. This paper also

describes the advantages of irregular big data in our model in perspective of cost comparing hardware entropy source.

Key words : Blockchain, Random Number, Blockchain Oracle, Big Data
접수일(2020년 4월 23일), 1차 수정일(2020년 6월 16일),
게재확정일(2020년 6월 26일)

* 건양대학교/사이버보안공학과(corresponding author)

★ 본논문은 2020년도 정부(과학기술정보통신부)의 재원으로
정보통신기획평가원의 지원을 받아 수행된 연구임
(No.2019-0-00411, 블록체인의 개인 콘텐츠 추적과 완전소멸
수정을위한잊힐권리문제해결)



70 융합보안논문지 제20권 제2호 (2020. 06)

1. 서 론

퍼블릭 블록체인은 신뢰할 수 있는 제3자 (Trust

Third Party : TTP) 없이 네트워크에 참여한 사람들

에게 신뢰를 제공해주는 신뢰머신으로 많은 주목을

받고 있다. 따라서 다양한 분야[1][2][3]에서 블록체인

을 이용하고 있다.

이더리움 같은 블록체인 2.0은 각 노드가 동일한

상태, 즉 월드 상태(world state)를 가지는 프로그래

밍 가능한 월드 컴퓨터이다[4]. 블록체인 월드 컴퓨터

에서 동작하는 프로그램을 주로 스마트계약[5]이라고

부른다. 본 논문에서는 스마트계약을 법률적인 계약을

의미하지 않고 블록체인에서 동작하는 프로그램을 의

미한다.

하지만 이더리움의 경우 Ethereum Virtual

Machine (EVM)[4]에서 동작하는 스마트계약은 블

록의 높이, 블록 해쉬 등 결정된 정보 (Deterministic

Information)만 획득할 수 있어 비결정적인 정보

(Non-Deterministic information), 예를 들어, 난수

등을 사용하지 못하는 문제가 있다. 그 이유는 스마트

계약을 연산하는 블록체인 노드마다 서로 다른 난수

를 사용하게 되면 동일한 월드 상태를 가지지 않게 되

기 때문이다[6].

하지만 난수를 필요로 하는 경우도 있다. 예를 들

어, 블록체인 기반 복권[7]이나 배팅 등이 있을 수 있

다.

EVM과 블록체인 자체적으로 구할 수 없는 정보를

제공하는 서비스를 블록체인 오라클(Oracle)이라고

한다. 즉 블록체인 오라클 서비스를 통하여 블록체인

외부의 정보를 획득하는 것이다. 따라서, 난수도 블록

체인 오라클 서비스를 통하여 공급할 수 있게 된다.

난수생성용 블록체인 오라클 서비스는 온라인으로

난수를 제공해주는 서비스이다. 즉 로컬머신에서 난수

를 생성하는 것이 아니다. 따라서 난수 오라클 서비스

는 온라인에 있는 어떤 난수라도 사용할 수 있을 것이

다.

본 논문에서는 비정형 빅데이터를 entropy source,

즉 진성난수생성기(TRNG: True Random Number

Generator)로 사용하였다. 해당 진성난수가 bias되어

있을 수 있어 de-skewing[8]을 하여 보정한 값을 난

수로 사용하고자 한다. 좀 더 구체적으로 본 논문에서

인스타그램[9]을 entropy source로 이용한다. 인스타

그램의 이미지 중 임의의 위치에서 정보를 읽어서 이

를 de-skewing 한후에 난수 pool(random number

pool)을 넣고 요청이 들어오면 앞쪽에서부터 필요한

만큼 난수를 제공해준다.

이렇게 생성한 난수가 난수의 통계적 특성이 있는

지는 NIST SP800-22[10]의 난수 테스트 15개를 돌

려서 확인하였다. 본 논문은 블록체인 환경에서 비정

형 빅데이터를 난수의 entropy source로 쓸 수 있는

지 실용적 관점에서 살펴보는 것이다.

본 논문이 기여하는 첫 번째는 온라인상에 있는 빅

데이터를 entropy source, 즉 TRNG로 사용할 수 있

음을 보이는 것이다. 본 논문에서는 인스타그램에서

받은 사진 이미지의 임의의 위치에 있는 비트 열들을

받아서 난수성 테스트를 통하여 실용적 관점에서 진

성난수로 사용할 수 있음을 보인다. 따라서, 진성난수

생성기는 대기의 화이트 노이즈 등 물리적인 세계에

서 구한다는 관점, 즉 하드웨어적으로 구현해야 한다

는 관점을 뒤집어 소프트웨어적으로도 진성난수를 구

할 수 있음을 보인다. 따라서, 고가의 난수 생성 하드

웨어를 구매할 필요가 없다.

하드웨어 진성난수 생성기는 성능적으로는 문제가

없지만 고가의 장비를 설치하고 관리 운영해야 하는

비용 및 편리성 면에서 본 논문의 진성난수 생성기와

차이를 보인다.

기존의 소프트웨어적 난수 생성기는 1)시스템 시간

2)키 입력 간의 시간 간격 3) 입출력 버퍼의 내용 4)

사용자 입력 5) 운영체제의 여러 가지 값 등이 있다.

하지만 기존의 소프트웨어적 난수 생성기는 주로 로

컬에서 사용하며, 서비스로 제공하기에 충분한

entropy를 획득하기 어려운 성능상의 문제가 있다.

두 번째로는 블록체인을 비정형 빅데이터에 기반한

진성 난수 생성기의 응용으로 선택하고 진성난수 생

성용 블록체인 오라클 구조를 밝히고 실질적으로 구

현하여 해당 구조를 바탕으로 인스타그램 뿐 아니라

다양한 빅데이터를 entropy source로 사용하는 블록

체인 오라클 서비스구축을 위한 단초를 제공한다.

본 논문의 구성은 2장에서 전체 시스템 구조, 블록

체인 오라클 및 난수 생성 알고리즘을 설명하고 3장



비정형 빅데이터를 이용한 난수생성용 블록체인 오라클 71

에서는 난수 테스트 결과 및 보안 분석을 살펴보고 4

장에서 관련 연구를 살펴보고 5장에서 향후 계획을

포함한 논의를 한다. 마지막으로 6장에서 결언을 맺는다.

2. 블록체인을 위한 비정형 빅데이터

를 이용한 난수생성 오라클

2.1 전체 시스템 구성도 및 오라클

본 논문에서는 이더리움 기반으로 네 개의 node로

구성된 PoA(Proof-of-Authority)[11] 기반 private

network을 구성하였다.

난수를 생성하기 위한 기본적인 시스템 구성도는

Fig. 1과 같다.

EOA(Externally Owned Account)나 CA(Contract

Account)에서 난수를 요청하면 RNG(Random

Number Generator) Oracle Contract에 난수를 요

청한다.

본 논문에서는 간단히 난수생성을 테스트하기 위하

여 Oraclize[12]를 활용하였다. Oraclize가 특별한

이유는 스마트계약에 제공되는 모든 데이터에 대해

신뢰성을 입증하기 때문이다[13]. Oraclize 서비스는

TLSNotary[14]를 통하여 진위 증명을 하게 된다.

TLSNotary는 3개의 엔티티, 즉 감시대상(RNG

Oracle Contract), 감시자(아마존 가상 시스템 인스

턴스), 서버(Oraclize 서버)로 구성된다. 서버와 감시

대상은 TLS를 통하여 대칭키를 받게 되고 감시자와

서버는 메시지 인증을 위한 MAC 키를 가지게 된다.

감시대상은 MAC키를 가지고 있지 않아서 변조를 할

수 없으며 감시자는 MAC키를 가지고 있어서 변조

여부를 확인할 수 있다. 즉 Oraclize는 감시대상이 값

을 변경하지 않았다는 것을 확인할 수 있다. Oraclize

의 TLSNotary에 대해서 좀 더 상세한 설명은 [13]와

[14] 에 나와 있다.

Oraclize는 개발자가 쉽게 오라클을 만들 수 있도

록 정의된 Contract (usingOraclize contract)를 상

속 받으면 쉽게 오라클을 만들 수 있다.

본 논문에서 usingOraclize를 상속받아 RNG

Contract를 이더리움 공식 언어인 solidity 0.5.0 버전

으로 Fig. 2와 같이 만들었다.

Fig. 1 블록체인 오라클을 위한 난수생성기의 전체적 구조



72 융합보안논문지 제20권 제2호 (2020. 06)

Fig. 2에서 일반적인 내용은 생략하고 오라클 부분

만 설명을 한다. Private blockchain이나 자체 테스

트넷인 경우 Oraclize를 사용하기 위해서 Oraclize

Bridge[15]를 생성해야 한다. Fig. 1의 Oraclize

Bridge가 이에 해당한다. Fig. 2 의 코드에서 OAR

변수에 bridge 주소가 들어간다. Oraclize Bridge를

통하여 Oraclize Service에 접근한다. Oraclize

Service를 통하여 실질적으로 가져오는 난수는 RNG

Service에서 받아오며 해당 URL 주소는 Fig. 2의 코

드 중 getRand함수 내부에 있는 oraclize_query에

들어 있는 주소이다.

블록체인 오라클은 즉시 읽기, 게시-구독, 요청-응

답의 세 가지 방법으로 서비스할 수 있다. 본 논문에

서는 즉기 읽기 방식을 사용하였다. 즉시 읽기 방식은

즉각적으로 필요한 정보를 조회하고 그 결과를 요청

하는 스마트계약 저장소에 저장하는 방식이다. 예를들

어, 배팅이나 복권 같은 경우 누구나 결과를 확인할

필요가 있을 때 사용한다. 즉 본 논문의 난수생성용

블록체인 오라클에 난수를 요청한 노드와 다른 노드

에서 PoW(Proof of Work)나 PoS(Proof of Stack)

등으로 합의할 때 해당 스마트계약의 저장소에 난수

가 저장되어 있어 동일한 연산이 가능하여 어떤 노드

나 최종 연산 결과 동일한 EVM의 상태머신(State

Machine)을 가지게 되어 합의가 가능하게 된다. 또

한, 전술한 TLSNotary를 통하여 스마트계약의 저장

소에 저장된 해당 난수가 변경되어 않았음을 확인할

수 있게 된다.

또 다른 방식으로 게시-구독 형태가 있다. 이 경우

오라클은 정기적 혹은 작은 변화가 예상되는 데이터

를 브로드캐스트하는 방식이다. 마지막으로 요청-응

답은 데이터 공간이 너무 커서 스마트계약의 저장소

에 저장할 수 없으며, 사용자는 한 번에 전체 데이터

중 일부만 필요한 경우에 사용한다[6]. 난수를 암호학

적 키 값으로 사용하는 경우 요청-응답 방식을 사용

할 수 있다. 응용에 따라서 오라클 서비스 방법을 선

택하면 된다.

2.2 난수 생성 알고리즘

난수 생성 알고리즘의 의사코드는 Fig. 3과 같다.

본 논문에서는 5개의 계정 중에서 랜덤하게 선택하

여 인스타그램에 로그인한다. 인스타그램은 개인화된

페이지를 보여주기 때문에 계정이 다르면 보여지는

사진도 달라진다. 또한 같은 계정이라도 접속할 때마

다 새로 등록된 사진을 제공해 준다. 접속 시 제공되

는 그림은 24개이며 그 중 하나를 랜덤하게 선택한다.

인스타그램 계정은 본 논문의 난수생성용 블록체인

오라클 서비스가 가진 것으로 노드나 사용자가 인스

타그램 계정을 가지고 있을 필요가 없다. 즉 스마트계

약이 난수생성용 블록체인 오라클에 난수를 요청하여

받고, 스마트계약의 저장소에 난수가 저장되고, 다른

노드가 합의할 때는 저장된 난수를 이용하여 스마트

계약을 동작하게 되어 동일한 연산 결과를 가지고 동

일한 EVM 상태머신을 가지게 된다. 선택된 그림의

중간 위치(m)를 찾은 다음 랜덤하게 앞쪽 또는 뒤쪽

을 선택하고 1~1000까지 랜덤한 값 (x)을 구한다. 만

약 앞쪽이면 m-x 바이트부터 256 바이트를 읽고 만

약 뒤쪽이면 m+x 바이트부터 256 바이트를 읽는다.

pragma solidity ^0.5.0;

import ""github.com/oraclize/ethereum-api/oraclizeAPI.sol"";

contract RNGContract is usingOraclize {

string public resultCode;

constructor() public payable {

OAR=OraclizeAddrResolverI(0xF4de356135716Fbb066373ae

9EBcab91dfe614b5);

}

function __callback(bytes32 myid, string memory result) publi

c {

resultCode = result;

}

function getRand() public payable {

oraclize_query(""URL"",""json(http://14.63.199.16:18080/random).res

ultCode"");

}

}

Fig. 2 랜수생성 스마트계약

1. choose randomly account from account pool

2. login into Instagram

3. choose randomly a picture from pictures shown when login

4. choose randomly a position from middle of choosen picture

5. read 256 bits from the position

6. de-skewing the 256 byte using SHA-256

7. store the de-skewed random number into random pool

Fig. 3 난수생성 알고리즘



비정형 빅데이터를 이용한 난수생성용 블록체인 오라클 73

참고로 여기서 랜덤 값은 java의

java.SecureRandom 함수를 사용하여 얻었다. 비정

형 빅데이터로부터 읽어들인 값은 bias되어 있을 수

있다. 따라서 해당 값을 de-skewing한다.

de-skewing하는 다양한 방법[8]이 있지만 본 논문에

서는 SHA-256 해쉬함수[16]로 해시를 하여 얻어진

값을 난수로 저장한다. 이렇게 생성된 난수를

30MByte가 될 때까지 지속적으로 생성하여 난수

pool에 저장하고 난수 요청이 들어오면 난수 pool에

서 읽어서 제공해 준다.

트위터같은 텍스트 빅데이터 소스는 터미널문자만

을 포함하여 엔트로피가 낮을 수 밖에 없다. youtube

동영상의 경우 스트림으로 제공되어 임의의 위치에서

난수를 가져오기 위해서 상당시간을 대기해야 하여

성능적인 문제가 있다. 이러한 이유로 이미지를 제공

해주는 인스타그램을 빅데이터 소스로 선택하였다. 하

지만 다른 빅데이터 소스가 난수의 entropy source로

사용할 수 없다는 것을 의미하지는 않는다.

3. 실험 결과

3.1 통계적 난수성 테스트

난수 생성기로 생성된 난수들이 난수인지 확인이

필요하다. 생성된 난수가 가지는 통계적 테스트를 통

하여 난수 생성기가 맞는 지 확인하는 방법은 무한의

방법이 있을 수 있다. 본 논문에서는 NIST

SP800-22에 제시된 15가지 통계적 테스트를 통하여

본 논문에서 사용한 난수 생성기가 난수 생성을 하는

지 확인하였다. 난수 테스트는 python으로 NIST

SP800-22 구현 [17]을 이용하였다.

인스타그램에서 난수를 획득하면 한 줄에 하나씩

before_de-skewing 파일에 저장하고 저장한 난수를

de-skewing하고 한줄에 하나씩 de-skewing 난수를

after_de-skewing 파일에 저장하였다.

before_de-skewing 파일의 저장 위치와

after_de-skewing 파일의 저장 위치를 [17] 구현의

입력 파라미터로 넣으면 자동으로 난수성을 테스트한

다.

Table 1은 NIST SP800-22 난수 테스트 결과이

다. 보는 바와 같이 de-skewing 전에는 10개의 테스

트가 실패하였으며 de-skewing 후에는 모든 테스트

를 성공적으로 통과하였다. 이를 통하여 알 수 있는

것은 적어도 인스타그램에서 획득한 데이터를 바로

난수로 사용할 수 없고 de-skewing을 반드시 실시해

야 한다는 것을 알 수 있다.

SP800-22는 수학적으로 난수성을 분석하여 난수

인지 아닌지를 판별하는 것으로 각 15개의 테스트는

각각의 수학적 의미를 가진다. 각 난수테스트에서 나

Test Name

before

de-skewin

g

after

de-skewing(P valu

e)

1 monobit test fail
pass(0.44921577254

4)

2
frequency wit

hin block test
fail

pass(0.48539054649

6)

3 runs test fail
pass(0.26639244282

6)

4

longest run o

nes in a bloc

k test

pass
pass(0.85977020598

9)

5
binary matrix

rank test
pass

pass(0.94314629807

4)

6 dft test fail
pass(0.66897578285

9)

7

non overlappi

ng template

matching test

pass
pass(0.99998350161

1)

8

overlapping

template

matching test

fail
pass(0.71848490746

7)

9
maurers

universal test
pass

pass(0.99934258576

1)

10

linear

complexity te

st

pass
pass(0.18813879582

9)

11 serial test fail
pass(0.46869742959

6)

12
approximate

entropy test
fail

pass(0.46840157776

6)

13
cumulative s

ums test
fail

pass(0.36298161598

1)

14

random

excursion tes

t

pass pass(0.35931869258)

15

random

excursion

variant test

fail
pass(0.01307022050

7)

Table 1. NIST SP 800-22 난수성 테스트 결과



74 융합보안논문지 제20권 제2호 (2020. 06)

온 P값을 Table 1.의 괄호에 표시하였다. .

3.2 보안 분석

공격자는 인스타그램 계정을 모르고 따라서 자신이

인스타그램에 접속했을 때 보는 이미지와 RNG

Service가 보는 이미지가 다르다. 또한, 접속시 보이

는 이미지 중 랜덤하게 하나를 선택하고 또 랜덤하게

이미지의 임의의 위치를 선택하여 256 바이트를 읽어

서 SHA256 해시 후 난수 pool에 저장한다. 최종적으

로 특정 사용자가 특정 시점에 요청하여 응답으로 받

은 난수는 난수 pool에 들어간 시점(이미지, 이미지

위치)을 전혀 알 수 없기 때문에 공격자는 어떤 이미

지의 어떤 위치에서 데이터를 읽었는지 파악할 수 없

기 때문에 공격자는 어떤 난수를 사용자가 얻게 될지

전혀 예측할 수 없다. 즉, de-skewing 전의 데이터를

전혀 예측할 수 없기 때문에 de-skewing 후의 난수

도 예측할 수 없다.

3.2 성능 분석

인스타그램에 접속하고 entropy를 얻는 것은 시간

이 소요되는 작업이다. 1회당 30분간 entropy를 획득

하고 실험을 3회를 실시하여 초당 entropy의 획득 비

트 수를 얻었다. Table 2는 이를 보여 준다.

이더리움은 현재 20 TPS(Transaction Per

Second) 정도이다[18]. 2018년 3월 기준 이더리움 트

랜잭션의 60%가 송금이며 40%정도가 스마트계약 호

출 트랜잭션이다[19]. 또한, 대부분의 스마트계약 호출

트랙잭션(80%이상)이 소수의 스마트계약에 집중되어

있다[20]. 가장 많이 호출되는 이더리움 스마트계약는

ERC20 Token 관련이다[20]. 즉 토큰 획득, 전송 등

이다. 따라서, 배팅이나 복권과 같이 난수를 필요로 하

는 스마트계약의 트랜잭션은 미미할 것이다. 난수를

필요로 하는 트랜잭션을 10% (> 8% = 40% * 20%)

정도의 가정하면 초당 2번 정도의 난수 요청이 있을

것이다. 최저의 속도(600bits/sec)를 고려했을 때

256bits를 두 번은 제공할 수 있다. 따라서, 현재는 문

제가 없으나 이더리움이 PoS로 넘어가면 속도가 상당

히 빨라 질 것이다. 이를 대응하기 위해서는 더 많은

인스타그램 계정을 이용하던지 아니면 다른 빅데이터

소스 (youtube 등)도 추가해야 할 것이다. 또는

256bits를 제공하는 것이 아니라 32bits 정도의 seed

를 제공하는 것도 방법이다.

4. 관련 연구

블록체인의 난수에 관한 기존 연구는 주로 난수를

생성할 때 발생되는 fairness 문제를 중심으로 연구가

되어 있고 생성한 난수 그 자체가 얼마만큼 안전한 난

수인지에 대한 연구는 아직 없다. 본 논문에서 중요한

점은 안전한 난수를 생성하는 것이며 그 응용으로써

블록체인 오라클을 선택한 것이다. 따라서, 본 논문에

서 제안하는 비정형 데이터, 인스타그램을 이용한 안

전한 난수는 어떤 응용에서도 사용할 수 있다.

기존의 블록체인에서 난수를 얻는 방식은 1) block

hash나 타임스탬프를 활용하는 방식 2) 블록체인 오

라클을 이용하는 방식 3) 난수를 해쉬하여

commitment로 제출하고 이 후에 난수를 공개하는

방식 4)RANDAO[21] 방식으로 나뉜다 [22]. 전술한

바와 같이 [22] 논문에서는 각 방식의 장단점을

fairness 측면에서 분석하였으나, 생성된 난수 자체의

안전성을 검토한 것은 아니다. 블록체인 오라클을 이

용하는 방식에서는 오라클 서비스를 신뢰해야만 하는

것이 단점이라고 분석하고 있다. 하지만 2장 1절에서

밝힌 것처럼 Oraclize 서비스는 TLSNotary를 이용

하여 난수 생성 Oracle Contract가 마음대로 난수를

변경하거나 조작하지 못함을 설명하였다. [22] 논문에

서는 random.org[23]와 같은 난수 서비스를 이용할

수 있다고 밝히고 있다. random.org는 대기 중의 백

색 잡음을 이용한 진성 난수 생성 서비스이다. 즉

random.org는 물리적인 세계에서 난수를 만들어 사

용하는 방식이며 본 논문은 비정형 빅데이터에서 진

성 난수를 만드는 방식이 차이점이다. 두 방식 모두

NIST SP800-22를 통과할 것이므로 난수성 측면에

회 속도
1회 606bits/sec
2회 600bits/sec
3회 625bits/sec

Table 2. 인스타그램 난수획득 속도



비정형 빅데이터를 이용한 난수생성용 블록체인 오라클 75

서 우열을 가릴 수는 없다. 다만 random.org와 같은

물리적 세계에서 난수를 가져오려면 특별한 장치가

필요하며 이에는 비용이 발생할 것이다.

5. 향후 계획 및 토론

본 논문에서는 인스타그램을 entropy source로 이

용하였다. 인스타그램만 사용하는 경우 일정 시간 이

지나야 로그인되며 빠른 속도로 접근할 때 일시적으

로 차단되는 특성이 있었다. 따라서, 아주 빠르게 난수

를 생성할 수 없는 문제점이 있으며 만약 블록체인 오

라클에 매우 빠른 속도로 난수 요청이 들어오면 난수

pool이 소진될 문제점이 있다. 이 문제를 해결하기 위

해서 향후에는 페이스북, 유튜브 등 다양한 비정형 빅

데이터를 동시에 사용하여 좀 더 빠르게 난수를 획득

하는 방안을 적용 해 볼 계획이다.

6. 결 률

본 논문은 블록체인의 스마트계약이 직접 구할 수

없는 난수를 블록체인 오라클 서비스로 제공하는 난

수생성용 블록체인 오라클 서비스를 구축하였다. 또한

본 논문은 실용적으로 사용할 수 있는 비정형 빅데이

터를 entropy source로 사용하였다. 좀 더 구체적으

로는 인스타그램의 사진을 entropy source로 사용하

였다.

인스타그램의 개인화 맞춤 이미지 제공 특성에 따

라서 본 논문에서 구축한 오라클 서비스가 접근하는

이미지와 공격자가 접근한 이미지가 같은 시간에 접

근하여도 서로 다르다. 또한, 오라클 서비스가 획득한

이미지의 특정 부분을 de-skewing하여 난수 pool에

저장하고 있다가 난수 생성 요청이 들어오면 제공하

는 방식을 사용하여 사용자가 요청한 시점에 제공되

는 난수가 어떤 시간에 어떤 이미지의 어떤 위치의 값

을 de-skewing했는지 전혀 예측할 수 없다. 따라서,

비정형 빅데이터를 entropy source로 실용적으로 이

용할 수 있다는 것을 본 논문에서 보여 준다.

마지막으로 NIST SP800-22 통계적 난수 테스트

를 이용하여 온라인으로부터 획득한 비정형 빅데이터

를 바로 사용할 수 없고 de-skewing을 해야만 한다

는 사실도 본 논문은 보여준다.

참고문헌

[1] 신동진, 박창섭, ""Hyperledger Fabric을 이용한 중

첩형 무한 해시체인 기반의 클라이언트 인증기

법"", 융합보안논문지, 제18권제4호, pp. 3-10,

2018.

[2] 지승원, 이원기, 고태광, 박소희, 오구연, 김종민,

김동민, ""블록체인 기반의 SCADA 시스템 보안"",

융합보안논문지, 제19권제5호, pp. 55-61, 2019.

[3] 지승원, 이원기, 고태광, 박소희, 오구연, 김종민,

김동민, ""블록체인 기반의 SCADA 시스템 보안"",

융합보안논문지, 제19권제5호, pp. 55-61, 2019.

[4] G. Wood, “Ethereum: A secure decentralised gen-

eralised transaction ledger.Ethereum Project,”

Yellow Paper, 2014.

[5] N. Szabo, “Smart Contract,” http://www.fon.hum.uva.

nl/rob/Courses/InformationInSpeech/CDROM/Literat

ure/LOTwinterschool2006/szabo.best.vwh.net/smart.

contracts.html, 1994.

[6] A. M. Antonopoulos and G. Wood, “Mastering

Ethereum,” O’Reilly, Dec. 2018.

[7] Quanta, www.quanta.im

[8] Katz, J., Menezes, A. J., Van Oorschot, P. C., &

Vanstone, S. A. “Handbook of applied cryptog-

raphy,” CRC press, 1996.

[9] Instagram, https://www.instagram.com/

[10] R. Andrew, et al. “A statistical test suite for

random and pseudorandom number generators

for cryptographic applications,” Booz-Allen and

Hamilton Inc Mclean Va, 2001.

[11] POA, https://en.wikipedia.org/wiki/Proof_of_authority

[12] Oraclize, http://provable.xyz/

[13] Prusty, Narayan. “Building Blockchain Projects,”

Packt Publishing Ltd, 2017. pp203-208.

[14] TLSNotary, https://tlsnotary.org/TLSNotary.pdf

[15] Oraclize bridge, https://github.com/provable-things

/ethereum-bridge

http://www.fon.hum.uva.nl/rob/Courses/InformationInSpeech/CDROM/Literature/LOTwinterschool2006/szabo.best.vwh.net/smart.contracts.html
http://www.quanta.im
https://www.instagram.com/
https://en.wikipedia.org/wiki/Proof_of
http://provable.xyz/
https://tlsnotary.org/TLSNotary.pdf


76 융합보안논문지 제20권 제2호 (2020. 06)

[16] Pub, NIST FIPS. ""180-2."" Secure Hash Standard,

National Institute of Standards and Technology,

US Department of Commerce, 2004.

[17] A python implementation of the SP800-22 Rev

1a PRNG test suite https://github.com/dj-on-gi-

thub/sp800_22_tests

[18] Who Scales It Best? Blockchains' TPS Analysis,

https://hackernoon.com/who-scales-it-best-block-

chains-tps-analysis-pv39g25mg

[19] Ranking Ethereum Smart Contractshttps://me-

d i um . c om/@v i k a t i / r a n k i n g - e t h e r-

eum-smart-contracts-a27e6f622ac6

[20] Ethereum Smart-Contracts: Most of them are

rarely used !, https://hackernoon.com/ethereum-

smart-contracts-most-of-them-are-rarely-

used-f45749730d3e

[21] randao.org, “RANDAO : A DAO working as

RNG of Ethereum,” Feb. 2019, https://github.com/

randao/randao.

[22] Chatterjee, Krishnendu, Amir Kafshdar Goharshady,

and Arash Pourdamghani. ""Probabilistic Smart

Contracts: Secure Randomness on the Blockchain.""  

arXiv preprint arXiv:1902.07986 (2019).

[23] Randomness and Integrity Services, “True ran-

dom number services,” https://www.random.org

[저 자소개 ]

정승욱 (Seung Wook Jung)
2005년 12월 : University of Siegen,
전자정보공학박사
현재 : 건양대학교 사이버보안공학과
꾐수
관심분야 : 개인정보보호, 블록체인,
네트워크 보안, 암호학 등
email :swjung@konyang.ac.kr

https://hackernoon.com/who-scales-it-best-blockchains-tps-analysis-pv39g25mg
https://medium.com/@vikati/ranking-ethereum-smart-contracts-a27e6f622ac6
https://hackernoon.com/ethereum-smart-contracts-most-of-them-are-rarely-used-f45749730d3e
https://github.com/randao/randao
https://www.random.org

";"""date"",""2020-08-10T05:25:47Z""
""pdf:PDFVersion"",""1.6""
""xmp:CreatorTool"",""Hancom PDF 1.3.0.538""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""language"",""ko""
""dc:format"",""application/pdf; version=1.6""
""pdf:docinfo:creator_tool"",""Hancom PDF 1.3.0.538""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""xmp:CreateDate"",""2020-08-10T14:25:45Z""
""modified"",""2020-08-10T05:25:47Z""
""pdf:hasMarkedContent"",""true""
""xmp:ModifyDate"",""2020-08-10T14:25:47Z""
""pdf:docinfo:creator"",""박진호""
""meta:author"",""박진호""
""meta:creation-date"",""2020-08-10T05:25:45Z""
""created"",""2020-08-10T05:25:45Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-08-10T05:25:45Z""
""resourceName"",""JAKO202022762160514.pdf""
""Author"",""박진호""
""producer"",""Hancom PDF 1.3.0.538""
""pdf:docinfo:producer"",""Hancom PDF 1.3.0.538""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""access_permission:modify_annotations"",""true""
""PDFVersion"",""1.4""
""dc:creator"",""박진호""
""dcterms:created"",""2020-08-10T05:25:45Z""
""Last-Modified"",""2020-08-10T05:25:47Z""
""dcterms:modified"",""2020-08-10T05:25:47Z""
""xmpMM:DocumentID"",""uuid:7de8ee53-524f-42da-972e-1629cfe1ba04""
""Last-Save-Date"",""2020-08-10T05:25:47Z""
""pdf:docinfo:modified"",""2020-08-10T05:25:47Z""
""meta:save-date"",""2020-08-10T05:25:47Z""
""pdf:docinfo:custom:PDFVersion"",""1.4""
""Content-Length"",""476381""
""Content-Type"",""application/pdf""
""xmp:MetadataDate"",""2020-08-10T14:25:47Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""박진호""
""pdf:producer"",""Hancom PDF 1.3.0.538""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""8""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""1439"",""1733"",""911"",""1999"",""1783"",""1651"",""1988"",""1094""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-08-10T05:25:45Z""
";https://scholar.google.com/scholar?start=70&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095383-1624;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;A Blockchain Model for Trustworthiness in the Internet of Things (IoT)-Based Smart-Cities;R Ali, YA Qadri, YB Zikria, F Al;Turjman, BS Kim…  Trends in Cloudbased …, 2020  Springer;;"… However, they bring extra complexity because of trust provisioning in the oracles [34] … This

consensus protocol was introduced by NEM [44] blockchain … A new hybrid of PoW and PoS

protocol for cryptocurrency was proposed in [45], named as Proof of Activity (PoA) …";Autres articles;;null;;;;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095367-1554;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Blockchain in education: a comprehensive approach–utility, use cases, and implementation in a university;S Mahankali, S Chaudhary ; Blockchain Technology Applications in …, 2020  igiglobal.com;;"… One Microsoft solution that addresses the risks inherent in oracles is the use of “cryptlets.” Cryptlets

operate outside of the permissioned Blockchain network and are designed to provide a secure,

trustworthy way to serve as an oracle to a smart contract and reduce data …";Cité 3 fois;;null;;;;https://scholar.google.com/scholar?start=360&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095365-1547;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Theoretical and Legal Perspective of Civil Liability in Cryptocurrency Relations;I Arkhypchenko ;2020 vb.mruni.eu;;"… community: what is a cryptocurrency – money or commodity … which should be taken

into account when analyzing crypto relations and liability issues. 3. To analyze the

notion and the machinery of the DLT, ie the blockchain …";Autres articles;;[PDF] mruni.eu;https://vb.mruni.eu/object/elaba:64874799/64874799.pdf;"
TARAS SHEVCHENKO NATIONAL UNIVERSITY OF KYIV 
FACULTY OF LAW 

CIVIL LAW DEPARTMENT 

MYKOLAS ROMERIS UNIVERSITY 
MYKOLAS ROMERIS LAW SCHOOL 

INSTITUTE OF PRIVATE LAW 

IRYNA ARKHYPCHENKO 
Private Law 

THEORETICAL AND LEGAL PERSPECTIVE OF CIVIL LIABILITY IN 

CRYPTOCURRENCY RELATIONS 

Master thesis 

 

Supervisors: 

Simona Drukteinienė 
Doctor of Juridical Sciences, Professor  

of the Institute of Private Law at Mykolas Romeris Law School, 
Mykolas Romeris University 

Bogdan Voyevodin 
Candidate of Juridical Sciences (Ph.D.), Associate Professor 

 of the Civil Law Department of the Law Faculty of Taras 
Shevchenko National University of Kyiv 

 
 

Vilnius – Kyiv, 2020  



 2 

TABLE OF CONTENTS 

ABBREVIATIONS ...................................................................................................................................................... 3 
INTRODUCTION........................................................................................................................................................ 4 
1. THE NOTION OF CRYPTOCURRENCY AND BLOCKCHAIN .................................................................. 10 

1.1. GENESIS, NATURE, AND MEANINGFUL CONTENT OF CRYPTOCURRENCIES ...................................................... 10 
1.1.1. E-money .................................................................................................................................................... 10 
1.1.2. Virtual currency ....................................................................................................................................... 11 
1.1.3. Digital currency ....................................................................................................................................... 12 
1.1.4. Cryptocurrency ......................................................................................................................................... 14 
1.1.5. Cryptocurrency vs. Fiat money vs. Commodity money vs. Commodity ................................................... 17 

1.2. MACHINERY AND PHILOSOPHY OF CRYPTOCURRENCIES. BLOCKCHAIN TECHNOLOGY ..................................... 25 
1.3. EVOLUTION OF CRYPTOCURRENCIES ................................................................................................................ 27 
1.4. LEGAL STATUS OF CRYPTOCURRENCIES AROUND THE WORLD .......................................................................... 31 

2. CONTRACTUAL LIABILITY IN CRYPTOCURRENCY RELATIONS ..................................................... 33 
2.1. CONTRACTUAL RIGHTS AND OBLIGATIONS OF  CRYPTOCURRENCY PRIVATE LEGAL RELATIONS PARTICIPANTS 
AND THEIR LIABILITY ............................................................................................................................................... 33 

2.1.1. Mining Contractual relationships ............................................................................................................ 33 
2.1.2. Crypto exchanges, P2P decentralized trading platforms, and online crypto wallets .............................. 41 
2.1.3. Cryptocurrency users ............................................................................................................................... 47 

2.2. SMART CONTRACTS .......................................................................................................................................... 52 
2.2.1. Definition of smart contracts .................................................................................................................... 52 
2.2.2. Form ......................................................................................................................................................... 54 
2.2.3. Contracts formation and their content ..................................................................................................... 54 
2.2.4. Performance of the contract. Liability issues ........................................................................................... 56 

3. NON-CONTRACTUAL LIABILITY IN CRYPTOCURRENCY RELATIONS ........................................... 61 
3.1. NEGLIGENCE AND THE DUTY OF CARE .............................................................................................................. 61 

3.1.1. The tort of negligence in common law ..................................................................................................... 61 
3.1.2.Negligence in the continental law system.................................................................................................. 67 

3.2. BREACH OF STATUTORY DUTY .......................................................................................................................... 68 
CONCLUSIONS ........................................................................................................................................................ 76 
RECOMMENDATIONS ........................................................................................................................................... 78 
ANNEX 1: CORRELATION OF TERMS: MONEY, FIAT MONEY, E-MONEY, VIRTUAL, DIGITAL, 
AND CRYPTOCURRENCY .................................................................................................................................... 80 
ANNEX 2: COMPARISON OF E-MONEY, VIRTUAL CURRENCY, DIGITAL CURRENCY AND 
CRYPTOCURRENCY .............................................................................................................................................. 81 
ANNEX 3: LEGAL STATUS OF CRYPTOCURRENCY IN DIFFERENT JURISDICTIONS ...................... 82 
ANNEX 4: PARTICIPANTS OF CRYPTOCURRENCY PRIVATE LEGAL RELATIONSHIPS ................. 85 
LIST OF BIBLIOGRAPHY ..................................................................................................................................... 86 
ABSTRACT .............................................................................................................................................................. 102 
SUMMARY .............................................................................................................................................................. 103 
HONESTY DECALARATION .............................................................................................................................. 104 
  



 3 

ABBREVIATIONS 
CISG –  United Nations Convention on Contracts for the International Sale of Goods 

CPI –  Consumer Price Index 

DL –  distributed ledger 

DLT –  distributed ledger technology 

EBA –  European Banking Authority  

ECB –  European Central Bank 

FATF –  Financial Action Task Force on Money Laundering 

GDPR –  General Data Protection Regulation 

P2P –  peer-to-peer 

PECL –  Principles of European Contract Law 

PoS –  Proof of Stake 

PoW –  Proof of Work 

UPICC –  UNIDROIT Principles of International Commercial Contracts 

  



 4 

INTRODUCTION 
Problem of research. The issue of legal liability in cryptosphere is still full of grey areas 

due to the decentralized structure of the system and lack of legal regulation in most countries. 

Unlike tax law field, where obligations and liability of a person who gains cryptocurrency or profit 

out of a transaction with cryptocurrency are covered with certain regulations in many states, civil 

liability disputes in cryptocurrency relations are full of inconsistencies, unclarity, and confusion 

due to the novelty of cryptocurrency phenomenon. The importance and the machinery of civil 

liability regulations need more clarification for the actors of cryptocurrency relationships. 

Relevance of the final thesis. The development of cryptographic e-money has long 

historical roots originated the in early 1980s when the work of an American cryptographer David 

Chaum1 was published. After almost 30 years the first decentralized cryptocurrency Bitcoin 

emerged. This event became a trigger for the creation of over 6,000 altcoins (alternative variants 

of Bitcoin, or other cryptocurrencies). 

From the point of legal relevance of the thesis, policymakers have not yet developed 

cryptocurrency specific frameworks because governments were not prepared for such a rapid 

development of cryptocurrency. Due to the lack of regulations, state authorities and courts of 

different jurisdictions do not have consistent approaches towards cryptocurrency-related disputes 

and claims. 

For proper regulation of these relationships, it is essential to deal with the substance and 

peculiar nature of cryptocurrencies and the distributed ledger technology (hereinafter the DLT), 

like blockchain, that is decentralized control through which each cryptocurrency work. Different 

organizations and state authorities provide warnings for cryptocurrency users and publish their 

findings on cryptocurrency functionality and, at the same time, they manage to not provide clear 

answers on the most urgent questions cryptocurrency actors may have. The long-lasting status quo 

on account of cryptocurrency leads to financial losses of cryptocurrency investors and 

cryptocurrency companies. 

The courts of different jurisdictions receive unfamiliar to them cryptocurrency claims and 

judges without clear guidelines towards cryptocurrencies have to deal with gaps in law, therefore, 

cryptocurrency cases are characterized as long-lasting ones. 

From the point of the scientific relevance of the thesis, academic researches on 

cryptocurrency are fragmentary, one-sided or incomplete and most of them only outline the 

problems in the cryptocurrency domain without proper analysis of such problems or their 

solutions. 

 
1 Allen Taylor, “David Chaum: Godfather of Digital Currency,” Blockchain Times, Accessed 4 February 2020, 
https://blockchaintimes.news/2018/10/19/david-chaum-godfather-of-digital-currency/ 



 5 

The cryptocurrency field needs unambiguous, harmonized, and more importantly, 

universal rules that would prevent financial losses of cryptocurrency business and users. 

Cryptocurrency should be treated similarly in different jurisdictions just like governments treat 

currency in a like manner. In our view, cryptocurrency should be analyzed through financial, 

technological and legal perspectives collectively to provide comprehensive and unambiguous 

research. 

Scientific novelty and overview of the research on the selected topic. Different scholars, 

as well as international and regional organizations, in their reports looked into prospects and 

challenges related to cryptocurrencies and the blockchain technology. 

All researchers in their works refer to cryptocurrency history and functioning and just a 

few address legal issues.  In particular, the cryptocurrency phenomenon was explored by C. Rose2, 

I. Cvetkova3, Rico Shirakawa, U. Korwatanasaku,4 W. Srokosz, T. Kopyscianski,5 etc. 

A great insight into the topic was made in the book “FinTech Law and Regulation” – the 

result of 31 contributing authors6. The writers covered inter alia legal and regulatory changes in 

the area of payments, banking,  and fundraising that were driven by technology development, legal 

and regulatory challenges regarding cryptocurrency and the DLT, compliance problems in 

FinTech as well as the impact of technology change in the financial sector on the legal profession7. 

Alexander Savelyev,8 Jakub J. Szczerbowski9, Monica di Angelo, Alfred Soare, Gernot 

Salzer10, Lin William Cong and Zhiguo He11 analyzed smart contracts and application of standard 

 
2 Chris Rose, “The Evolution Of Digital Currencies: Bitcoin, A Cryptocurrency Causing  A Monetary Revolution,” 
International Business & Economics Research Journal (IBER), 14, 4 (2015), 
https://www.researchgate.net/publication/297750676_The_Evolution_Of_Digital_Currencies_Bitcoin_A_Cryptocur
rency_Causing_A_Monetary_Revolution 
3 Iryna Cvetkova, “Cryptocurrencies legal regulation,” BRICS Law Journal 5, 2 (2018), 
https://www.researchgate.net/publication/326195399_Cryptocurrencies_legal_regulation 
4 Rico Shirakawa, Jacinta Bernadette, and Upalat Korwatanasakul, “Cryptocurrency Regulations: Institutions and 
Financial Openness,” ADBI Working Paper 978 (Tokyo: Asian Development Bank Institute, 2019), 
https://www.adb.org/publications/cryptocurrency-regulations-institutions-financial-openness 
5 Witold Srokosz and Tomasz Kopyscianski, “Legal and Economic Analysis of the Cryptocurrencies Impact on the 
Financial System Stability,” Journal of Teaching and Education 5 (2015), 
http://www.universitypublications.net/jte/0402/pdf/F5N180.pdf 
6 Jelena Madir ed., FinTech Law and Regulation (Cheltenham: Edward Elgar Publishing Limited, 2019). 
7 Ibid. 
8 Alexandr Savelyev, “Contract law 2.0: “Smart”. Contracts as the beginning of the end of classic contract law,” 
Information & Communications Technology Law 26 (2017), 
https://www.tandfonline.com/doi/full/10.1080/13600834.2017.1301036 
9 Jakub J. Szczerbowski, “Place of smart contracts in civil law. A few comments on form and interpretation,” 
Proceedings of the 12th Annual International Scientific Conference NEW TRENDS 2017 (Znojmo: Private College 
of Economic Studies Znojmo, 2017),  https://ssrn.com/abstract=3095933 
10 Monica di Angelo, Alfred Soare, Gernot Salzer, “Smart Contracts in View of the Civil Code,” SAC ’19 (2019), 
https://publik.tuwien.ac.at/files/publik_278278.pdf 
11 Lin William Cong, Zhiguo He, “Blockchain Disruption and Smart Contracts,” The Review of Financial Studies 35, 
5 (2019), https://doi.org/10.1093/rfs/hhz007 

https://www.researchgate.net/publication/297750676_The_Evolution_Of_Digital_Currencies_Bitcoin_A_Cryptocurrency_Causing_A_Monetary_Revolution
https://www.researchgate.net/publication/297750676_The_Evolution_Of_Digital_Currencies_Bitcoin_A_Cryptocurrency_Causing_A_Monetary_Revolution
https://www.researchgate.net/publication/326195399_Cryptocurrencies_legal_regulation
https://www.adb.org/publications/cryptocurrency-regulations-institutions-financial-openness
http://www.universitypublications.net/jte/0402/pdf/F5N180.pdf
https://www.tandfonline.com/doi/full/10.1080/13600834.2017.1301036
https://ssrn.com/abstract=3095933
https://publik.tuwien.ac.at/files/publik_278278.pdf
https://doi.org/10.1093/rfs/hhz007


 6 

contract law provisions to such agreements. In particular, J. Szczerbowski proposed a new form of 

contracts – blockchain form. Monica di Angelo et al. tried to clarify how smart contracts 

correspond to the provisions of the Austrian Civil Code as well as shortcomings of automated 

agreements. 

Franziska Boehm and Paulina Pesch tried to analyze the Bitcoin nature and 

characteristics of contracts with the use of Bitcoin under German and US law.12 Miklós Király 

investigates the possible application of the Vienna Convention on International Sales of Goods 

(hereinafter the CISG) to contracts with Bitcoin. He also refers to the exchange rate fluctuation 

risk, change of circumstances in crypto contracts and late payment interest.13 

Darren J. Sandler explores the possibility for crypto mining contracts to be investment 

contracts in the United States and analyses relevant case law to prove that many companies 

publicly offer unregistered securities.14 

We did not find any relevant research that examines tortious liability in the 

cryptocurrency sphere. 

Significance of research. The deep analysis presented in the research defines ones and for 

all the status of cryptocurrency in the legal domain. It resolves the problem of ambiguity of 

approaches among different jurisdictions and/or state authorities inside one country and, hopefully, 

closes the academic discussion on this account. The findings will also help policymakers to 

determine the nature of cryptocurrency on the legal level. 

The research is significant for practice because it indicates pitfalls in contractual and non-

contractual relationships that should be taken into account by participants of cryptocurrency civil 

relations. The findings will provide solutions and comprehensive answers on previously 

unexplored questions in academic researches that will help to safeguard the interests of private 

actors and avoid potential civil liability issues. The analysis will also be relevant for the juridical 

interpretation of standard rules on civil liability in common law and in the continental system 

towards cryptocurrency relations. It possibly will help to develop a standardized approach in 

resolving cryptocurrency disputes in different jurisdictions. 

The aim of the research. The aim of the research is to bring light on the nature of 

cryptocurrency and analyze the applicability of existing rules on civil liability in cryptocurrency 

relations. The research, where suitable, will also draw the line between the application of standard 

 
12 Franziska Boehm and Paulina Pesch, “Bitcoin: A First Legal Analysis – with reference to German and US-American 
law” Financial Cryptography Workshops (2014), https://fc14.ifca.ai/bitcoin/papers/bitcoin14_submission_7.pdf 
13 Miklós Király, “The Vienna Convention on International Sales of Goods and the Bitcoin,” US-Chine Law Review 
16, 5 (2019),  https://www.davidpublisher.org/Public/uploads/Contribute/5d81db8d2160e.pdf 
14 Darren J. Sandler, “Citrus Groves in the Cloud: Is Cryptocurrency Cloud Mining a Security?” Santa Clara High 
Technology Law Journal 34, 3 (2018), 
https://digitalcommons.law.scu.edu/cgi/viewcontent.cgi?article=1628&context=chtlj 

https://fc14.ifca.ai/bitcoin/papers/bitcoin14_submission_7.pdf
https://www.davidpublisher.org/Public/uploads/Contribute/5d81db8d2160e.pdf
https://digitalcommons.law.scu.edu/cgi/viewcontent.cgi?article=1628&context=chtlj


 7 

rules on liability and circumstances when a new approach should be taken in civil liability disputes 

due to the specific nature of cryptocurrency and blockchain technology. 

The objectives of the research. 

1. To answer the controversial and sore question discussed in the cryptocurrency community: 

what is a cryptocurrency – money or commodity? 

2. Establish whether cryptocurrencies identical in their nature or they have differences which 

should be taken into account when analyzing crypto relations and liability issues. 

3. To analyze the notion and the machinery of the DLT, i.e. the blockchain. 

4. To indicate problems and risks that exist in cryptocurrency contractual and non-contractual 

relations which may raise potential liability issues. 

5. To analyze the court practices regarding disputes arising out of cryptocurrency relations and 

outline possible applications of judicial solutions and findings to future cryptocurrency 

claims. 

6. Relying on the legal analysis performed in the Thesis, to make proposals concerning the better 

use or more effective use of existing legislation  and adopting new rules that would be applied 

specifically to cryptocurrency legal liability issues. 

Research methodology. 

- Analysis of scientific literature on civil liability, FinTech and LegalTech development, 

cryptocurrency, blockchain technology, and smart contracts. Evaluation of the processes and 

literature that influenced the development of cryptocurrency through the historical and legal 

perspective. 

- Structural and functional methods in determining cryptocurrency nature. 

- Descriptive multivariate data analysis towards legal regulations of cryptocurrency and its 

status worldwide in order to find common patterns among policymakers approaches in 

different countries. 

- Causal analysis of statistical data regarding cryptocurrencies to determine variables that 

cause a rise in the number of cryptocurrency-related claims. 

- A comparative synthesis of civil liability provisions in the American, the UK’s, Singapore’s, 

German, and Ukrainian legislation to determine how they apply to cryptocurrency relations. 

- Comparative analysis of Terms of Use agreements provided by different cryptocurrency 

platforms in order to distill clauses that distort the balance of parties’ interests. 

- Comparative and predictive data analysis of Singaporean and the US court practice in the 

scope of cryptocurrency civil relations aiming to determine future tendencies in the 

cryptocurrency legal domain. In comparison to other states, the abovementioned countries 

have more developed case law regarding cryptocurrency issues. 



 8 

- Studying out the applicability of regional and international frameworks as well as lex 

mercatoria towards cryptocurrency relations such as the CISG, UNIDROIT Principles of 

International Commercial Contracts (hereinafter the UPICC), Principles of European Contract 

Law (hereinafter the PECL), and General Data Protection Regulation (hereinafter the GDPR). 

- Classification of cases regarding cryptocurrency issues that courts might deal with. 

Structure of the research. 

The general part of the research will be devoted to the exploration of  the genesis of the 

digital currencies in general. There will be also given an explanation of crucial terms, such as 

crypto assets, digital currency, virtual currency, and altcoins. The final and complete answer that 

determines whether cryptocurrencies are commodities or money is given. This part gives 

cryptocurrencies classification on the basis of several different factors. It also compares 

cryptocurrency and fiat money and explains the DLT that enables cryptocurrency existing.  The 

second part overviews the legal status of cryptocurrency in different jurisdictions throughout the 

world based on the data provided by the Global Legal Research Center of The Law Library of 

Congress.15 Also, actors of cryptorelations will be described. 

The next part will explore contractual liability in cryptocurrency relations. The smart 

contracts phenomenon and their basic machinery will be examined. There will be given a list of 

most frequent contracts concluded between actors of the cryptocurrency market and their basic 

features. The analysis of different Terms of Use agreements on account of unfair contractual terms 

as well as the case law concerning breaches of contracts relating to cryptocurrencies will be 

presented. 

In the finale, the research will present tortious liability in cryptocurrency relations.  It will 

explore the common obligations of cryptocurrency market actors failing to perform of which could 

bring damage to a party. The analysis of rare case law concerning tortious liability will be given. 

Defense statements. 

1. Nature of cryptocurrency. Cryptocurrencies are money, not a commodity, therefore: 

-  ‘cryptocurrency for goods’ contracts are standard contracts of sale, not of barter. 

- in transactions ‘cryptocurrency for fiat currency,’ the law concerning currency exchange and 

financial transactions should be applicable. 

2. Contractual liability issues in cryptocurrency relations: 

2.1. Default rules on liability should be applicable to contractual liability in cryptocurrency 

relations regardless of the uniqueness and novelty of the cryptocurrency phenomenon. 

 
15 Regulation of cryptocurrency around the world, (Washington, DC: The Law Library of Congress, Global Legal 
Research Center, 2018), https://www.loc.gov/law/help/cryptocurrency/cryptocurrency-world-survey.pdf 

https://www.loc.gov/law/help/cryptocurrency/cryptocurrency-world-survey.pdf


 9 

2.2. The unintended behavior of the program designed to create automated contracts does not 

make mistakenly concluded contracts void and it does not justify the breach of the other 

related contracts between involved parties. 

2.3.Neither party will be liable for damage produced by the error in smart contracts. Therefore, 

parties should provide relevant clauses to the contract which designated to solve 

performance liability issues. 

3. Non-contractual liability issues in cryptocurrency relations: 

3.1. Potential civil liability may be caused by either the tort of negligence or breach of statutory 

duty. 

3.2. Some contracts may be regarded as securities in common law system, thus their offerors 

are liable for the public offer of unregistered securities and/or false advertisement. 

3.3. A cyberattack on crypto-platform could be a cause of liability in the tort of negligence. 

3.4. Cryptocurrency related companies owe a duty of care to their platform users, thus are 

liable for the breach of such duty. 

3.5. Contrastingly, independent coders that contribute to the open-source software do not owe 

a duty of care to the software users, thus not liable for code errors in the tort of negligence. 

3.6. Breach of statutory duty resulting in civil liability may happen for breach of only three 

bodies of law designated for: investors’ protection, users’ protection, or users’ data 

protection.  



 10 

1. THE NOTION OF CRYPTOCURRENCY AND BLOCKCHAIN 

1.1. Genesis, Nature, and Meaningful Content of Cryptocurrencies 

Cryptocurrency has its predecessors – electronic money, virtual currency, and digital 

currency. There is a tendency to confuse terminology throughout scientists: use these terms 

interchangeably, define one term using the other one, or describe the correlation of terms 

improperly – e.g. C. Ross claims that digital currency is a form of virtual currency16, overlooking 

features of virtual and digital currencies, therefore confusing the correlation between the two 

terms. The mistake will be explained at the end of this paragraph. 

1.1.1. E-money 

Electronic money (hereinafter the e-money) means electronically, including 

magnetically, stored monetary value as represented by a claim on the issuer which is issued on 

receipt of funds for the purpose of making payment transactions, and which is accepted by a natural 

or legal person other than the e-money issuer 17. 

According to the European Central Bank (hereinafter the ECB), e-money is broadly 

defined as an electronic store of monetary value on a technical device that may be widely used for 

making payments to entities other than the e-money issuer. The device acts as a prepaid bearer 

instrument which does not necessarily involve bank accounts in transactions. E-money products 

can be hardware-based or software-based, depending on the technology used to store the monetary 

value18. 

E-money is an electronic (virtual) equivalent of cash since it shares various features of 

cash. The value is stored in a given currency. There is no currency conversion, therefore, no risk 

of exchange rate fluctuations. E-money requires an issuer – e-money institutions (definition is set 

out in Directive 2009/110/EC19) – who issue the e-money upon license and are bound to convert 

it back into real money of the same currency. 

 
16 Chris Rose, “The Evolution Of Digital Currencies: Bitcoin, A Cryptocurrency Causing A Monetary Revolution,” 
International Business & Economics Research Journal (IBER), 14, 4 (2015): 617, 
https://www.researchgate.net/publication/297750676_The_Evolution_Of_Digital_Currencies_Bitcoin_A_Cryptocur
rency_Causing_A_Monetary_Revolution 
17 “Directive 2009/110/EC of the European Parliament and of the Council of 16 September 2009 on the taking up, 
pursuit and prudential supervision of the business of electronic money institutions amending Directives 2005/60/EC 
and 2006/48/EC and repealing Directive 2000/46/EC (Text with EEA relevance),” EUR- Lex, Accessed 4 February 
2020, https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32009L0110 
18 “Electronic Money,” European Central Bank, Accessed 4 February 2020, 
https://www.ecb.europa.eu/stats/money_credit_banking/electronic_money/html/index.en.html 
19 “Directive 2009/110/EC of the European Parliament and of the Council of 16 September 2009 on the taking up, 
pursuit and prudential supervision of the business of electronic money institutions amending Directives 2005/60/EC 

https://www.researchgate.net/publication/297750676_The_Evolution_Of_Digital_Currencies_Bitcoin_A_Cryptocurrency_Causing_A_Monetary_Revolution
https://www.researchgate.net/publication/297750676_The_Evolution_Of_Digital_Currencies_Bitcoin_A_Cryptocurrency_Causing_A_Monetary_Revolution
https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32009L0110
https://www.ecb.europa.eu/stats/money_credit_banking/electronic_money/html/index.en.html


 11 

In other words, “e-money is a digital transfer mechanism for fiat currency — i.e. it 

electronically transfers value that has the legal tender status.”20 

1.1.2. Virtual currency 

Virtual currency is a digital representation of value that is neither issued by a central 

bank or public authority nor necessarily attached to a fiat (conventional) currency but is accepted 

by natural or legal persons as a means of exchange and can be transferred, stored or traded 

electronically according to the European Banking Authority (hereinafter the EBA).21 

Another definition provided by the Financial Action Task Force on Money Laundering 

(hereinafter the FATF): “a digital representation of value that can be digitally traded and functions 

as a medium of exchange; and/or a unit of account; and/or a store of value, but does not have legal 

tender status.” The key point is that “it is not issued nor guaranteed by any jurisdiction, and fulfills 

the above functions only by agreement within the community of users of the virtual currency.”22 

In 2012 the ECB defined virtual currency as “a type of unregulated, digital money, which 

is issued and usually controlled by its developers, and used and accepted among the members of a 

specific virtual community.”23 In a further analysis that came out in 2015, it modified the definition 

as follows: “it is a digital representation of value, not issued by a central bank, credit institution or 

e-money institution, which in some circumstances can be used as an alternative to money.”24 The 

ECB considers virtual currencies neither as full form of money described in economic literature 

nor as legal tender25. 

From these definitions we can conclude that virtual currencies have four main features: 

- they exist exclusively in the virtual form: they do not have physical form per se; 

- only valid within the specified community, e.g. currencies in multiplayer online role-

playing games in which a player can either earn or exchange fiat money for virtual 

 
and 2006/48/EC and repealing Directive 2000/46/EC (Text with EEA relevance),” EUR- Lex, Accessed 4 February 
2020, https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32009L0110 
20 “FAFT Report. Virtual Currencies Key Definitions and Potential AML/CFT Risks” (Paris: Financial Action Task 
Force, June 2014): 4, https://www.fatf-gafi.org/media/fatf/documents/reports/Virtual-currency-key-definitions-and-
potential-aml-cft-risks.pdf 
21 “EBA Opinion on ‘virtual currencies’” (Paris: European Banking Authority, July 2014): 5, 
https://eba.europa.eu/sites/default/documents/files/documents/10180/657547/81409b94-4222-45d7-ba3b-
7deb5863ab57/EBA-Op-2014-08%20Opinion%20on%20Virtual%20Currencies.pdf?retry=1 
22 “FAFT Report. Virtual Currencies Key Definitions and Potential AML/CFT Risks” (Paris: Financial Action Task 
Force, June 2014): 4, https://www.fatf-gafi.org/media/fatf/documents/reports/Virtual-currency-key-definitions-and-
potential-aml-cft-risks.pdf 
23 “Virtual Currency Schemes,” (Frankfurt am Main: European Central Bank, October 2012): 13,   
https://www.ecb.europa.eu/pub/pdf/other/virtualcurrencyschemes201210en.pdf 
24 “Virtual Currency Schemes – a further analysis,” (Frankfurt am Main: European Central Bank, February 2015): 4, 
https://www.ecb.europa.eu/pub/pdf/other/virtualcurrencyschemesen.pdf 
25 Ibid. 

https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32009L0110
https://www.fatf-gafi.org/media/fatf/documents/reports/Virtual-currency-key-definitions-and-potential-aml-cft-risks.pdf
https://www.fatf-gafi.org/media/fatf/documents/reports/Virtual-currency-key-definitions-and-potential-aml-cft-risks.pdf
https://eba.europa.eu/sites/default/documents/files/documents/10180/657547/81409b94-4222-45d7-ba3b-7deb5863ab57/EBA-Op-2014-08%20Opinion%20on%20Virtual%20Currencies.pdf?retry=1
https://eba.europa.eu/sites/default/documents/files/documents/10180/657547/81409b94-4222-45d7-ba3b-7deb5863ab57/EBA-Op-2014-08%20Opinion%20on%20Virtual%20Currencies.pdf?retry=1
https://www.fatf-gafi.org/media/fatf/";"""date"",""2020-05-13T09:43:35Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""3"",""1"",""0"",""1"",""1"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""26"",""22"",""3"",""3"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""8"",""0"",""0"",""0"",""0"",""0"",""0"",""2"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""13"",""0"",""0"",""9"",""61"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""26"",""56"",""0"",""0"",""0"",""1"",""0"",""8"",""0"",""1"",""9"",""0"",""0"",""10"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.3""
""xmp:CreatorTool"",""Microsoft Word""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dc:creator"",""Ирина Архипченко""
""dcterms:created"",""2020-05-13T09:43:35Z""
""language"",""en""
""Last-Modified"",""2020-05-13T09:43:35Z""
""dcterms:modified"",""2020-05-13T09:43:35Z""
""dc:format"",""application/pdf; version=1.3""
""xmpMM:DocumentID"",""uuid:3C4F6147-E2DB-485D-8E2A-9B0848878455""
""Last-Save-Date"",""2020-05-13T09:43:35Z""
""pdf:docinfo:creator_tool"",""Microsoft Word""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2020-05-13T09:43:35Z""
""meta:save-date"",""2020-05-13T09:43:35Z""
""pdf:encrypted"",""false""
""xmp:CreateDate"",""2020-04-27T12:30:27Z""
""modified"",""2020-05-13T09:43:35Z""
""pdf:hasMarkedContent"",""true""
""Content-Type"",""application/pdf""
""xmp:ModifyDate"",""2020-04-27T12:30:27Z""
""pdf:docinfo:creator"",""Ирина Архипченко""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Ирина Архипченко""
""meta:author"",""Ирина Архипченко""
""meta:creation-date"",""2020-05-13T09:43:35Z""
""created"",""2020-05-13T09:43:35Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""104""
""Creation-Date"",""2020-05-13T09:43:35Z""
""resourceName"",""64874799.pdf""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""649"",""5704"",""529"",""2882"",""3634"",""3170"",""2618"",""2848"",""1396"",""3017"",""3310"",""2726"",""2615"",""3606"",""2763"",""2527"",""2738"",""3419"",""3282"",""3263"",""3246"",""3045"",""3259"",""2903"",""2896"",""3389"",""3018"",""2781"",""2708"",""2676"",""3124"",""2643"",""2620"",""3012"",""2156"",""3191"",""3359"",""3362"",""2968"",""2826"",""3288"",""2774"",""2374"",""2355"",""2467"",""2990"",""2896"",""2954"",""3155"",""3260"",""3422"",""2461"",""3150"",""2803"",""3111"",""2765"",""3021"",""3153"",""3154"",""1828"",""2793"",""2888"",""2629"",""2724"",""3060"",""2767"",""2775"",""2760"",""3104"",""1776"",""3790"",""2737"",""1946"",""3189"",""257"",""3088"",""3193"",""3089"",""994"",""246"",""1689"",""1159"",""1241"",""941"",""3804"",""2342"",""2399"",""2396"",""2400"",""2032"",""2320"",""2511"",""2279"",""2530"",""2348"",""2480"",""2522"",""2420"",""2305"",""2387"",""867"",""1747"",""2420"",""977""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""Author"",""Ирина Архипченко""
""producer"",""macOS Версия 10.15.2 (Выпуск 19C57) Quartz PDFContext""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""macOS Версия 10.15.2 (Выпуск 19C57) Quartz PDFContext""
""pdf:docinfo:created"",""2020-05-13T09:43:35Z""
";https://scholar.google.com/scholar?start=350&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095320-1354;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Blockchain based Decentralized Applications: Technology Review and Development Guidelines;C Pop, T Cioara, I Anghel, M Antal, I Salomie ; arXiv preprint arXiv …, 2020  arxiv.org;;"Page 1. 1 Blockchain based Decentralized Applications: Technology Review and

Development Guidelines Claudia … capability. Finally, Federated Tier aggregates integrative

solutions across multiple blockchain applications deployments …";Cité 7 fois;I Salomie;[PDF] arxiv.org;https://arxiv.org/pdf/2003.07131;"
1 

Blockchain based Decentralized Applications: Technology Review and 
Development Guidelines 

Claudia Pop, Tudor Cioara, Ionut Anghel, Marcel Antal and Ioan Salomie 

Computer Science Department, Technical University of Cluj-Napoca; Memorandumului 28, 
400114 Cluj-Napoca, Romania  

claudia.pop@cs.utcluj.ro, tudor.cioara@cs.utcluj.ro, ionut.anghel@cs.utcluj.ro, 
marcel.antal@cs.utcluj.ro, ioan.salomie@cs.utcluj.ro 

 

Abstract: Blockchain or Distributed Ledger Technology is a disruptive technology that provides the 
infrastructure for developing decentralized applications enabling the implementation of novel 
business models even in traditionally centralized domains. In the last years it has drawn high interest 
from the academic community, technology developers and startups thus lots of solutions have been 
developed to address blockchain technology limitations and the requirements of applications software 
engineering. In this paper, we provide a comprehensive overview of DLT solutions analyzing the 
addressed challenges, provided solutions and their usage for developing decentralized applications. 
Our study reviews over 100 blockchain papers and startup initiatives from which we construct a 3-tier 
based architecture for decentralized applications and we use it to systematically classify the technology 
solutions. Protocol and Network Tier solutions address the digital assets registration, transactions, 
data structure, and privacy and business rules implementation and the creation of peer-to-peer 
networks, ledger replication, and consensus-based state validation. Scaling Tier solutions address the 
scalability problems in terms of storage size, transaction throughput, and computational capability. 
Finally, Federated Tier aggregates integrative solutions across multiple blockchain applications 
deployments. The paper closes with a discussion on challenges and opportunities for developing 
decentralized applications by providing a multi-step guideline for decentralizing the design of 
traditional systems and implementing decentralized applications.  

Keywords: Blockchain; decentralized applications development; distributed ledger technology; 
guideline for blockchain application implementation; blockchain application architecture. 

1. Introduction 

Distributed Ledger Technology (DLT) is a disruptive technology that provides the infrastructure for 
developing decentralized, secure, and reliable applications. By joining several computer sciences 
disciplines such as distributed systems, cryptography, data structures or consensus algorithms, it 
offers highly desirable features (decentralization, openness, immutability, transparency, traceability, 
security, availability, etc.). Gartner has included DLT in the technology in the hype cycle for the first 
time in 2016 at the phase of an innovation trigger [119]. During the next two years, a lot of research 
and development work has been committed to develop the mechanisms to accommodate the 
technology to the various requirements essential to decentralized applications implementation 
perspective and emerging business models. By 2018 the DLT has passed the peak of inflated 
expectations, assuming to reach a plateau of productivity in the next 5 to 10 years [120], while in 2019 
the innovation potential of the DLT is considered by Gartner to be driven non only by the technology 
expectations but also by the social ones [121]. 
 
In this sense, the development of Decentralized Autonomous Organizations and implementation of 
Decentralized Applications and the Decentralized Web are of high interest for the next 10 years. 
Anyway, building such decentralized applications with DLT is not a straightforward process since lots 
of technological solutions have emerged or have been significantly improved, offering new 
opportunities and challenges for the software development industry [1].  
 
Thus, in this paper we aim to provide a comprehensive overview of nowadays blockchain technology 
solutions and the specific challenges they aim to address and provide a guideline for applying the 
blockchain technology for decentralizing traditional systems and implementing new decentralized 
applications. 
 
To streamline and organize the DLT solutions review we have defined a 3-tier conceptual architecture 
(see Figure 1) that can be the used for implementing blockchain decentralized applications: 
 



2 

• The Protocol and Network Tier (PN-Tier) aggregates the core DLT elements and organizes them in 
two layers. The Protocol Layer contains technology solutions for digital assets registration, 
transactions, data structure and privacy and business rules implementation. The Network Layer 
contains technology solutions for creating a peer-to-peer network, ledger replication and 
consensus-based state validation.   

• The Scaling Tier (S-Tier) runs most of the time a parallel blockchain network and aggregates 
technological solutions for addressing the scalability issues raised by the PN-Tier (also known as 
off-chain components). We have further organized the state-of-the-art solutions according to the 
scalability problems that they address in storage scalability, transactions throughput and 
computational scalability. 

• The Federated Tier built on top of the previous two tiers addresses various integration solutions 
across multiple DLT applications and systems deployments. 

• For each architectural tier we identified the main technological challenges, existing solutions, and 
technologies to create a consistent overview over the current technological state of the art. 

 

 

Figure 1. 3-tier architecture for decentralized applications development 
 
The rest of the paper is structured as follows: Section 2 presents the main technological solutions for 
the PN-Tier, Section 3 reviews the mechanisms of S-Tier for improving the PN-Tier’s scalability in 
three directions: storage, transaction throughput, and computational, Section 4 describes the existing 
federated ledgers interoperation solutions, Section 5 discusses guidelines for developing decentralized 
applications, while Section 6 concludes the paper. 

2. Protocol and Network Tier 

Different solutions for PN-Tier have been proposed addressing specific challenges [1-6]. For this tier 
we have identified the technological components that are grouped at the protocol and at the network 
layers, while the security of the entire tier is ensured as a result of integrating the public-private key 
cryptography for locking and unlocking transactions, with the tamper-proof data structures that are 
enforced by strong consensus algorithms. 



3 

2.1. Protocol Layer 

The protocol layer represents the core of the technology runs on each full node in the peer-to-peer 
network. It is governed by rules that specifies what, when, how and by whom are the assets operated 
on the chain and features four type of technological components: asset representation, data structure, 
privacy and business rules enforcement. 

2.1.1. Type of asset and data structures 

The tokenization process refers to the possibility of modeling different goods in a DLT system as digital 
assets that can be issued and transferred according to a predefined set of rules. The common 
terminology for an asset representation in DLT systems is Token or Coin. We have identified two types 
of tokens that can be represented in the system (see Table 1): native tokens and tokens based on real 
assets (asset-based tokens). Native tokens are tokens defined in the blockchain system, completely 
independent of the real world, thus the rules governing the issuance and the transfer are completely 
defined in the blockchain system (through Initial Coin Offerings or mining reward schemes), and do 
not rely on any third trusted party. Bitcoin [1], Ether [2] or CryptoKitties [7] are examples of such 
tokens that are completely virtual and have economic value based on the supply and demand. 

Table 1. Type of digital assets modeled using blockchain   

Type  Token Example Fungibility Issuers 

Native 
tokens 

Bitcoin, Ether, CryptoKitties 
[1,2,7] 

Yes Mining Reward Schemes 

ERC20, ERC223, ERC-621 [8] Yes Initial Coin Offerings 
ERC721 [8] No Initial Coin Offerings 

Asset-
Based 

Tokens 

Real Estate [9] No Government Land Registries [10] 

Patents [11] No 
U.S. Patent & Trademark Office 

[12] 
Academic Records [13]  No The Registrar’s Office [14] 

Gold  Yes Royal Mint Gold [15] 

 
Real-life assets can also be represented through tokens in blockchain systems, offering the opportunity 
to represent, transfer and track them. By using asset-based tokens, the chain can keep track of 
different kinds of assets, both tangible (real estate, cars, money, art, etc.) and intangible (patents, 
trademarks, copyrights, etc.). The DLT systems representing real-life assets must rely on a trusted 
third party in order to issue each token with respect to the real object. Similarly, a transfer on-chain 
must be done under the governance of such a trusted party, since any issue regarding a wrongful 
transfer on the chain can be verified only by communicating with the external systems. 
 
In DLT systems the real-life flow of assets is represented in the network as transactions between peers. 
The DLT requires specialized data structures at its core that can ensure three properties over the 
stored transactions: provenance, asset ownership validation and immutability. Hash pointers have 
been frequently integrated with different data structures intended for DLT usages. Due to the hash 
functions’ collision-free, data concealing and data binding properties, the hash pointers are the best 
choice for adapting common data structures to the DLT requirements thus obtaining: linked list with 
hash pointers (e.g. blockchain), binary trees with hash pointers (e.g. Merkle Trees), graphs with hash 
pointers (e.g. Hash Graphs), etc. 
 
Two main state the art directions can be identified concerning distributed ledger data structures for 
representing peers’ transactions, namely block chain and direct acyclic graph. The block chain 
structure, as its name suggests, is a chain formed by linked back blocks, also known as Linked List 
using hash pointers (see Figure 2.a). Each block contains all the transactions that occurred in the 
system in a short period of time (e.g. ~10 minutes for Bitcoin, or ~12 seconds for Ethereum). All the 
transactions contained in the block are hashed together in a Merkle Tree data structure, where the 
root of the tree is referenced in the block header and acts as a digital fingerprint of the entire collection.  
 
Thus, blockchain becomes an append-only data structure that gathers all the benefits of the hashing 
and cryptographic functions and, with the integration of a consensus algorithm, ensures an immutable 
history log of the entire activity of the network. The blockchain structure is implemented in well-
known solutions such as Bitcoin [1], Ethereum [2], Litecoin [4], Hyperledger [16], CryptoNode [17], 
Ripple [18] and Zerocash [6]. 
 



4 

A less popular data structure is the directed acyclic graph (DAG) firstly mentioned in [19]. Since its 
proposal several platforms have been developing solutions based on DAG variations: Dagcoin [20], 
IOTA [3], HashGraph [21], Lydian [22], or hybrid systems like Holochain [23] and Flowchain [24]. 
Among the DAG-based systems, IOTA is the most used solution. It uses a DAG, called tangle, as a 
ledger for storing the transactions as depicted in Figure 2.b. The entire graph starts with a genesis 
transaction that is approved directly or indirectly by all the transactions in the graph. Whenever a new 
transaction is submitted, it must validate and confirm two previous transactions from the graph that 
were not yet approved (i.e. tips). The tips selection algorithm is based on the family of Markov Chain 
Monte Carlo algorithms and it considers the cumulative weights of sub-tangles. Whenever a situation 
of conflicting transactions appears, the higher the cumulative weight of the transaction is, the more 
secure it is. 

 

(a)                                                                                     (b) 

Figure 2. Data for representing peers’ transactions structures (a) block chain using linked lists and 
(b) Directed Acyclic Graphs 
 
While the most successful solutions and research directions are focused on blockchain-based DLT, 
the DAG solutions have yet to overcome considerable shortcomings in term of centralization and 
scaling in order to be considered suitable alternatives to blockchain-based DLTs [25]. 

2.1.2. Privacy of transacting parties and data 

Most of the popular DLT solutions preach the properties of transparency and openness to be major 
benefits brought by the technology. By providing open information about the transacting parties 
(pseudo-anonymous most of the times) and transacted assets, the systems offer clear history and audit 
advantages. However, in many use cases where the privacy of data is highly required [27] (e.g. medical 
use cases [27] [29]), many of the DLT solutions may prove to be unsuitable due to their transparency 
and openness. With the emerging General Data Protection Regulation (GDPR) restrictions, the 
privacy of data is one of the most controversial subjects in the DLT systems. In this direction, solutions 
have emerged that aim to hide the details regarding the transaction information, while at the same 
time keeping the reliability of the system by allowing consistency checks, validation, and audit with 
respect to the previous actions and history. 
 
In Bitcoin versions of the DLT, the value of the transacted asset is clearly stated, and the nodes can 
easily check the ownership over the asset by checking the history and identifying the unspent 
transaction outputs (UTXO). The biggest challenge is that by hiding the transaction data, the nodes in 
the system should still be able to validate the availability of the funds and the ownership of the sender 
over that asset. Coin Mixers have been developed over Bitcoin in order to hide information and prevent 
tracking and tracing of transacted assets. One of these approaches is CoinJoin [30] which aims to 
aggregate multiple users to agree upon several inputs and outputs and then sign the transactions. This 
makes it harder for the coins to be traced across the transactions since the group of inputs provided 
to a transaction will not belong to the actual sender. Similarly, Dash [31] aims to provide mixing 
services but instead of using a central point that is responsible for mixing inputs and outputs like 
CoinJoin, it provides a second layer of Master Nodes over Bitcoin.  
 
A private-public key cryptographic mechanism is proposed by Quorum [29] in order to hide the 
transacted value. The encrypted transactions are shared point-to-point only to the involved parties, 



5 

and a Private State is defined by the Quorum node, where these encrypted transactions are stored. The 
encryption keys are shared between the involved parties, to validate the transaction. However, the 
shared blockchain (public state) only contains the hash of the encrypted transaction. This leads to a 
shortcoming of the system since the network cannot verify the validity of the private transactions, this 
being done only by the involved parties. The shortcoming of Quorum is overcome by integrating Zero-
Knowledge proof mechanisms [32] with DLT systems. Zero-knowledge proofs have been added to 
digital currencies, such as Zerocoin [33, 6] to create anonymous Bitcoin transactions without the need 
of third parties such as CoinJoin and Dash. The Zero-Knowledge proof mechanisms, mainly succinct 
Non-Interactive Zero-Knowledge proofs (ZkSnarks) [34] are used to ensure the transactions’ 
validation without revealing actual information about the parties involved. The Zero-Knowledge 
proofs require that a Verifier could easily check that the Prover is in possession of a secret, without 
revealing the actual secret to the Verifier. Consider a simple scenario, where the network is in 
possession of a hash value H. An actor wants to prove to the network that he holds the secret s, that 
hashed offers the value of H. In the traditional system, the actor would need to reveal the secret to the 
network. ZkSnarks aim to enhance this model, by allowing the actor to prove ownership over the data 
without disclosing any information regarding the secret.  In this sense, ZkSnarks introduces a proving 
function, that can be used by the actor to issue a proof showing that the private secret is indeed 
corresponding to the public information H, and a verification function that can be executed by any 
participant in the network in order to validate whether the proof corresponds to the public information 
H. ZCash [6] implements a ZkSnarks mechanism as an improvement of the Bitcoin system that 
ensures the privacy of the transactions. It requires any transaction to be locked by a secret, called a 
commitment and unlocked by a participant that holds the secret and who can generate the relevant 
proof, called the nullifier. The commitment is issued off-chain by the sender of the transaction, having 
as secret information the value and the receiver’s public key. Similarly, the nullifier is computed off-
chain by the receiver, proving that he owns the necessary information to spend the locked value. The 
commitment and the nullifier are registered on-chain. The commitments are registered in the 
commitment tree, and each time a transfer is required, a nullifier for one of these commitments needs 
to be issued and then registered in the nullifier set as future proof for avoiding double-spending 
attacks. The verifiers of the nullifier are all mining nodes that need to validate the integrity of the 
transactions.  
 
Homomorphic encryption is another approach that aims to improve the privacy of blockchain solution 
in MimbleWimble [35], a system designed to provide an untraceable version of Bitcoin. It is a side 
chain that takes advantage of cryptographic properties to hide transacted values. In Bitcoin, each 
transaction is represented by an input amount that has an associated past UTXO that it unlocks, and 
an output amount locked by the receiver’s key. The restriction imposed by the Bitcoin system is that 
the output amount of a transaction should never exceed the input amount of it. MimbleWimble uses 
Elliptic Curve Cryptography and Homomorphic encryption, leveraging on the fact the computations 
applied on the cyphertexts offer the same results as if applied on the plaintext.  Therefore, in 
MimbleWimble the transacted amounts are blinded and by applying computations on the obtained 
cyphertexts they are further involved in mathematical operations proving that the input values of the 
transaction equal with the output values, obtaining the same results as they would have been 
performed directly in plaintext. 
 
Another commonly used strategy, that hides the transferred asset amount of a transaction and the 
parties involved, is the ring signature. CryptoNote [36] is one of the first protocols that proposes the 
use of ring signatures for issuing transfers by specifying a group of possible signers in order to avoid 
the possibility of discovering the exact sender of the money. Considering a group of N parties (sub-
group of network participants) involved in the ring, one of the parties can sign the message, resulting 
in a signature that can be verified by anyone in the network, but without the possibility of detecting 
the exact signing party. Furthermore, in Monero [5], the authors use Stealth addresses for the 
receiving parties. Each Monero account is composed of two private keys (view and spend key) and the 
public address. As their name suggests, the view key is used to track all the transactions that were 
published and are destined for that account. The spend key is used to send transactions and the public 
address is the one used by a sender to compute the one-time public key (stealth address), unique for 
each transaction. The stealth addresses offer non-linkable transactions, which means that the outputs 
are not associated with the addresses of the wallets. However, this solution does not provide complete 
privacy, since the sender can trace when the money is spent by the receiver. A completely private 
system would need to offer both non-linkable and non-traceable transactions. 
 



6 

Table 2 presents comparatively the main privacy preserving techniques identified for DLT and the 
privacy features they are offering. The coin mixers do not offer complete privacy, although they offer 
non-traceability mechanisms, the actual values transmitted are still visible. In terms of non-
traceability however, the Zero-Knowledge Proofs were not yet validated as completely untraceable, 
due to the complexity of the algorithms involved. ZCash aims to provide traceable capabilities for the 
system, in order to be able to detect malicious users, which leads to the conclusion the transactions 
may not be completely untraceable [37]. Private-Public Key cryptography and Coin mixers also have 
one main disadvantage, because they rely on central authorities in order to provide Key sharing 
services and mixing services respectively. Another important property is the advanced scripting 
capability, where Coin mixers and Homomorphic Encryption mechanisms prove not to be a good 
solution, while the Zero-Knowledge Proof solution although feasible, has the drawback of using high 
computational resources for applying the cryptographic algorithms. 

Table 2. DLT main privacy presenting techniques 

Features  
Private-

Public Key 
Encryption 

Zero-
Knowledge 

Proofs 

Ring 
signatures 

Homomorphic 
Encryption 

Coin 
mixers 

Hidden Data yes yes yes yes no 
Non-traceable yes n/a yes yes yes 
Non-linkable no yes yes no yes 
Decentralized no yes yes yes no 

Private Business 
Enforcement 

no yes no no no 

Transaction 
validation by network 

no yes yes yes yes 

2.1.3. Business rules enforcement over transactions 

The capability of a blockchain system to support business implementation that can be run in a 
decentralized way, and then be verified and audited by all the nodes in the system, is usually provided 
through smart contracts. Opposed to the concept suggested by their names, the smart contracts are 
not very smart and may not provide a contract in the legal sense, but rather they are pieces of code 
similar with the stored procedures that are executed and validated by the nodes in the system, 
whenever they are triggered. However, there are DLT systems such Bitcoin that are offering few 
possibilities for scripts to be implemented. Not being a Turing Complete language, the Bitcoin script 
language does not permit the implementation of complex business logic required for more advanced 
use cases. As a result, new DLT systems have emerged that allow customizing decentralized 
applications and enforcement of business logic in a decentralized way regarding when, how and by 
whom may an asset transfer be executed. 
 
In Table 3 a comparison of the main state of the art approaches for enforcing the business rules on 
DLT are presented. There are two types of approaches that allow smart functionality to be 
implemented and run across the nodes of the network: stateless and stateful [38]. The Stateless 
implementation or Transaction based functionalities are offering the possibility to implement custom 
logic at the level of transactions. This means that whenever a transaction is issued there is a set of rules 
that can be verified before rendering the transaction valid. The Stateful systems, on the other hand, 
offer Business-oriented functionalities, by focusing on the rules that govern the use case, and keeping 
the state of the business in tamper-proof structures (Patricia Merkle Trees, adapted from [39]) that 
are easily verifiable and audited by the entire distributed system. In the Stateful Systems, the 
transaction has the role of triggering changes and applying updates on the stored state. 

Table 3. Business rules enforcement on DLT  

Type  Implementation Platform  
Enforcement 

Flexibility 
Costs 

Exploitation 
Risks 

Stateless 
Transaction 

Oriented 

Transactional Rules 

Built-In 
Enforcement 

Bitcoin [1], 
Litecoin [4] 

Limited None Low 

Nxt [40] Templates None Low 
Piggy Backed 
Enforcement 

Counterparty 
[41] 

Turing 
Complete 

Fee per 
instruction 

High 

Stateful  State Storage 



7 

Business 
Oriented 

Smart Contracts & 
Merkle Patricia 

Tree 
Ethereum [2]  

Turing 
Complete 

Fee per 
instruction 

High 

Smart Contracts & 
NoSQL DB 

HyperLedger 
[16] 

Turing 
Complete 

None High 

 
In terms of functional complexity, there are systems that allow full computation capabilities by 
supporting Turing Complete languages for smart contract implementations or partial capabilities by 
offering a limited range of operations or fixed predefined templates. Both approaches have their 
advantages. On one hand, full capabilities are desired in order to be able to model and enforce any 
complex business system. Turing Completeness allows this, but it requires higher transactional costs, 
since on-chain computation demands for each node to execute possibly complex scripts, thus the costs 
are proportional with the number of instructions. Furthermore, a complex and flexible language 
makes the system susceptible to different kinds of attacks that can be caused by exploiting different 
language shortcomings or human errors during the business logic implementations [42] like call depth 
attack, race conditions, timestamp dependency, transaction ordering dependency, etc. On the other 
hand, by limiting the operations allowed or by providing predefined templates to be used, the risk of 
exploits is highly reduced.  

2.2. Network Layer 

The network layer technologies are related to the peer-to-peer network formed by the nodes that hold 
copies of the ledger (full nodes or light nodes) and participate as active players in the network. The 
main technological components identified at this layer are targeting the data propagation among the 
nodes, the peer’s registration and network permission, and the consensus among peers. 

2.2.1. Data propagation and replication  

In terms of transaction data propagation, the first generation of blockchain systems (Bitcoin [1], 
Litecoin [4], Ethereum [2], etc.) relied on full-discovery or global disclosure. This is one of the 
strongest features of blockchain systems since a complete replication of the data offers high availability 
and reliability in the system. However, there are specific use cases (e.g. banking, enterprise data) that 
impose restrictions regarding the group of actors that can have access to transaction information. In 
this sense, two categories of systems have been identified based on how the transactions are 
propagated in the system. Firstly, the global disclosure mechanism, implemented by the systems 
where all the full nodes have access to all the transactions published in the system, and secondly, the 
selective disclosure mechanism where nodes have access only to exclusive transactions that are 
targeting either specific businesses or only the involved parties. 
 
Most of the blockchain-based system adopts a global disclosure approach in order to offer high 
reliability in an open system where any node can join. The entire system is a peer-to-peer network, 
where all the nodes are equal. Whenever a new event is issued (a new transaction, a new block) the 
data is propagated through the entire network, and each node can verify and validate the integrity of 
the data. The redundancy in storage and computation makes it very difficult for a malicious node to 
influence the system to its advantage. In order to attempt an attack (e.g. double-spending attack) on 
a globally disclosed DLT system, an elaborate plan of attack must be conducted by the malicious node 
by analyzing the network topology (network segmentation) and issuing contradictory actions for each 
half of the network, with the purpose of convincing half of the network to agree with the malicious 
action taken by it.  
 
Having a global disclosure between all the peers in the network has obvious advantages since such a 
system benefits from the high replication and availability brought by the large number of nodes, as 
well as Byzantine Fault Tolerant consensus between these nodes regarding the data. However, there 
are clients/businesses that prefer having more privacy and control over their data. This property is 
especially desired in private and consortium chains (e.g. banking systems), where the transactions are 
required to be shared only between the transacting parties. Although such a paradigm shift may lead 
to lower reliability in the system, the risks are highly attenuated if these requirements are 
implemented in permissioned systems where each stakeholder has its identity known and can be held 
accountable for his actions. 
 
One of the selective disclosure approaches is presented in the Hyperledger Multichannel Architecture 
[43]. The system relies on third-party entities, called Orderers, which are required to order the 



8 

transactions and publish them according to the category (business specific) in a corresponding 
channel. A Byzantine fault-tolerant consensus protocol is implemented between the Orderers, to 
ensure consistency between the decisions. A channel is a business-specific queue that broadcasts all 
the transactions to the subscribed parties. All the subscribers (peers) will receive the transactions in 
the same order in cryptographically linked blocks. A peer can be subscribed to more than one chain, 
but the chains do not interact with each other and each block received will contain only transactions 
corresponding to the corresponding business. 
 
Quorum [29] is another approach that aims to improve security by keeping the exclusive transactions 
shared only between the involved parties. The system is a hybrid between the global and selective 
disclosure paradigms, by allowing public transactions to be fully replicated and exclusive transactions 
to be shared only across the parties. The Quorum’s privacy engine defines a private state tree which is 
updated with contracts and transactions that are sent point-to-point only to the interested parties. The 
private transaction contents are encrypted using Public Key cryptography, and only the users holding 
the private keys have access and can decrypt the actual content of the transaction. Proof of these events 
is also registered in the public chain, by hashing the encrypted private transaction. 
 
A similar permissioned implementation is also designed in Corda [44] where the network is formed 
of permission services, notary services and peers. The aim of the system is to provide redundancy 
while also keeping the transactions only known to the involving parts. Any transaction that occurs in 
the system must be signed and approved by both participants, and by the notary service responsible 
to validate transactions and prevent double-spending events. The notary service can be one entity or 
multiple entities that are coordinated by a consensus algorithm. 
 
In Table 4, the comparison between the Data propagation patterns found in the literature is presented. 
One of the biggest disadvantages of the current selective disclosure systems is their trust in different 
central authorities. The Quorum system requires some level of trust between the private parties, and 
the other systems rely on central authorities that are responsible either for forwarding the messages 
like in the case of Hyperledger MultiChannel system or on authorities responsible to validate the 
integrity of transactions like in the case of Corda or Plasma [45]. Consequently, the selective disclosure 
should be considered only in trusted environments, where the central authorities can be considered a 
source of truth, while for public environments, global disclosure should be considered such that any 
party involved in the network can validate the integrity of the transactions. 

Table 4. DLT data propagation patterns 

Type  Platform 
Trusted 
Parties 

Global Disclosed Selective Disclosed 

Data Structure Data Structure 

Public DLTs 
Ethereum 

[2], Bitcoin 
[1], etc. 

- 
All 

transactions 
Blockchain - - 

Business 
Specific 
Chains 

HyperLedger 
Multi-

channel [43] 
Orderer - - 

Exclusive 
transactions 

Queues, 
Blockchain 

Plasma [45] 

Central 
Authority, 

N 
delegates  

";"""date"",""2020-03-13T12:45:41Z""
""pdf:PDFVersion"",""1.7""
""xmp:CreatorTool"",""MicrosoftÂŽ Word for Office 365""
""pdf:docinfo:title"",""Author template for journal articles""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""language"",""en""
""dc:format"",""application/pdf; version=1.7""
""pdf:docinfo:creator_tool"",""MicrosoftÂŽ Word for Office 365""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""Author template for journal articles""
""xmp:CreateDate"",""2020-03-13T14:45:41Z""
""modified"",""2020-03-13T12:45:41Z""
""pdf:hasMarkedContent"",""true""
""xmp:ModifyDate"",""2020-03-13T14:45:41Z""
""pdf:docinfo:creator"",""DSRL-IONUT""
""meta:author"",""DSRL-IONUT""
""meta:creation-date"",""2020-03-13T12:45:41Z""
""created"",""2020-03-13T12:45:41Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-03-13T12:45:41Z""
""resourceName"",""2003.07131""
""Author"",""DSRL-IONUT""
""producer"",""MicrosoftÂŽ Word for Office 365""
""pdf:docinfo:producer"",""MicrosoftÂŽ Word for Office 365""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""access_permission:modify_annotations"",""true""
""dc:creator"",""DSRL-IONUT""
""dcterms:created"",""2020-03-13T12:45:41Z""
""Last-Modified"",""2020-03-13T12:45:41Z""
""dcterms:modified"",""2020-03-13T12:45:41Z""
""title"",""Author template for journal articles""
""xmpMM:DocumentID"",""uuid:8AFB843F-EE3F-48EF-9E11-70B664D63CC4""
""Last-Save-Date"",""2020-03-13T12:45:41Z""
""pdf:docinfo:modified"",""2020-03-13T12:45:41Z""
""meta:save-date"",""2020-03-13T12:45:41Z""
""Content-Length"",""742489""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""DSRL-IONUT""
""dc:language"",""en-GB""
""pdf:producer"",""MicrosoftÂŽ Word for Office 365""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""30""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""4356"",""2194"",""4353"",""3792"",""5519"",""3964"",""4671"",""3921"",""3014"",""5408"",""5536"",""4886"",""3423"",""5322"",""2477"",""3351"",""4738"",""2983"",""3010"",""5379"",""3540"",""2042"",""4683"",""5012"",""4039"",""4170"",""4063"",""4023"",""4051"",""2082""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-03-13T12:45:41Z""
";https://scholar.google.com/scholar?start=160&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095369-1568;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;[PDF][PDF] Blockchain and COVID-19 Pandemic: Applications and Challenges;RW Ahmad, K Salah, R Jayaraman, I Yaqoob… ;2020 researchgate.net;;"Page 1. See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/345019546 Blockchain and COVID-19 Pandemic: Applications and Challenges …

Page 2. 1 Blockchain and COVID-19 Pandemic: Applications and Challenges …";Cité 3 fois;Les 4 versions;[PDF] researchgate.net;https://www.researchgate.net/profile/Samer_Ellahham2/publication/346170823_Blockchain_and_COVID-19_Pandemic_Applications_and_Challenges/links/5fbca29b458515b797641bce/Blockchain-and-COVID-19-Pandemic-Applications-and-Challenges.pdf;;;https://scholar.google.com/scholar?start=370&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095344-1460;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Interoperability Solutions for Blockchain;R Bhatia ; … Conference on Smart Technologies in Computing …, 2020  ieeexplore.ieee.org;;"… Cross-Chain Oracles: A smart … It also enables blockchains to connect to off-chain APIs and oracle

services. Blocknet's utility token is BLOCK, and it is Proof- of-Stake based service blockchain.

It consists of three main components: - XRouter, XBridge, and XCloud …";Autres articles;;null;;;;https://scholar.google.com/scholar?start=260&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095327-1388;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;A Blockchain-based Architecture for Query and Registration of Student Degree Certificates;AWS Abreu, EF Coutinho, CIM Bezerra ; Proceedings of the 14th …, 2020  dl.acm.org;;"… the decentralizsed trust and to compensate, several oracles should be used; and (iii) Flexibility:

oracles are bound to smart contracts because a compromised oracle can not … stored, incorrect

data cannot be changed; (ii) Data size: the cost of the blockchain is proportional …";Autres articles;;null;;;;https://scholar.google.com/scholar?start=190&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095365-1553;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Cloud crypto land;E Schuster ; The Modern Law Review, 2020  Wiley Online Library;;"… Blockchain technology was first suggested and popularised in the context of the cryptocurrency

Bitcoin, but its use has since spread to many … The final section concludes that crypto assets and

smart contracts have no future … A LAWYER'S VIEW OF BLOCKCHAIN TECHNOLOGY …";Autres articles;;[PDF] systemicrisk.ac.uk;https://www.systemicrisk.ac.uk/sites/default/files/images/Schuster%20-%20Clouud%20Crypto%20-%20Future%20of%20Money.pdf;"
Cloud Crypto Land
Why Smart Contracts and Crypto Assets Won’t Change the World

ls e .ac.uk/ law

Edmund Schuster
London School of Economics



Motivation
Blockchain technology rais es  many intriguing legal 
ques tions
 When are cryptotokens securities / transferable f inancial 

instruments?
 Is it possible to create a GDPR-compliant blockchain?
 How should we characterise the legal relationship between a 

coder/node/initiator/etc and the users of cryptoassets/ 
cryptocurrencies

 Is a DAO a legal person? Should it be?
 Is it a crime to “steal”  from a poorly implemented brainwallet?

Krugman on Interstellar Trade?



Overview
The s tatus  quo
 Misleading promises of the blockchain
 What are  blockchains  to a lawyer?
 Categoris ing blockchain projects  – naked vs . non-naked 

tokens /coins
Legal obs tacles  for “s mart as s ets ” and “s mart contracts ”
 A s imple argument for why the law would have to adapt for making it all 

work
Will or s hould the law adapt to a  blockchain future?
 The promis e of cryptoas s ets and s mart contracts
 Checking agains t reality…
Can this  be extended to cryptocurrencies ?



The mythical powers of the Blockchain

“I don’t claim to be an expert on it but the mos t obvious  
technology is  blockchain”





The empty promise of the blockchain

Why do the promis es  s ound s o attractive?
 Cost of change and the right comparator
 We don’t do things the way we do because everyone is stupid
 Change is  hard – s tarting from scratch is  lazy

Important to keep trade-offs  in mind
 Dis tributed databases  with consensus  rules are  neces sarily 

inefficient
 May be a price  worth paying for decentralis ation!



Legal analogues of blockchains
The “phys ical world”
 Value embodied in physical objects (and control over these objects –

“pos ses s ion”)
 Peer- to-peer trans actions
 “No double s pending” enforced by the law of phys ics
 Correlation between possession and legal rights is (and has long been) reflected in 

legal rules

The world of intangibles  and regis tered rights
 Trans acting in intangibles :
1. P2P + (s ome) trus t – e.g. as s igning rights
2. Central ledger, and trus t only in the record-keeper – e.g. s ecurities , land regis ter
3. Now: Blockchains – solve the double-spending problem at the heart of 1. and 2.



A simple 
Blockchain
simulator



Legal analogues of blockchains

So in this  s ens e, blockchains  replicate features  of the 
phys ical world
Tokenizing as s ets  is , of cours e, nothing new
We have been here before
 Negotiable instruments and lex mercatoria
 Intrins ically worthles s  phys ical objects  as  representations  of 

valuable rights
 Es tablishing negotiability – early vers ion of “code is  law”?
 But les s  useful because you need to be online



Cryptoassets

My definition of “cryptoas s ets ”
 Distinguish “naked” blockchains from crypto- tokens  as  

representations  of legally rights  – “cryptoas sets ”
 Cryptocurrencies  are  “naked” in this  s ense
 Like merchants  deciding to care  about the  actual pieces  of paper, rather 

than anything they may represent
 But there  are  other examples  – (CryptoKitties !                 )

 Other tokens  s tand in for something – are meant to convey rights  
of some sort
 E.g. “s ecurity tokens”, putting as sets  on the  blockchains , e tc

 This  type of cryptoas s et mus t be tethered to legal reality 
to fulfil its  purpos e



“Smart contracts”
Terminological problems
 this is neither the “contract”  its elf nor “smart”
Potential benefits  of cryptoas s ets and s mart contracts
 How smart can smart contracts  be?
 Complexity and usefulnes s
 Lawyers  do not spend mos t of their time suing people  for breach 

of crys tal- clear obligations

Algorithms /computer code vs  natural legal language

As  long as  everything is  s elf-contained within the protocol, it 
can even be “s elf-executing”
 Small problem: it never is



“Smart contracts”

There is  no neces s ary link between s mart contracts  and 
the blockchain apart from “trus tles s nes s ”
 Small problem: this  has  never been a concern of anyone
 Also: Technology has  always  been available , but rarely used for 

entire  agreements
Another central ques tion: what are the inputs ?
 If no inputs  (or only pas sage of time), there’s  no need for a any of this
 (Lawyers  have long had solutions  for this )
 But if there  are  inputs , these also need to be “trus tles s” - or e ls e  

there’s  no point in doing any of this
Mas s ive computational overhead
 Solving this  means  centralis ing



Blockchains and the Law as a 
Synchronisation Problem
A s imple argument agains t the feas ibility of cryptoas s ets and s mart 
contracts :

1. To the extent that cryptoas sets represent legal rights , their 
enforcement depends  at leas t in part on the legal sys tem

2. The law places  limits  on what can be agreed, even between 
sophis ticated parties
 Capacity, fraud, dures s , ordre public, …

3. Legal rules  cannot fully be encoded in any formal algorithmic 
sys tem, so this  cannot be solved by and in code

 If you want to put anything that is  tethered to legal reality on the 
blockchain, you need a s ys tem of legal realignment:
The blockchain must sync with the law



Cryptoassets: Current Legal Obstacles

The alternative?
 State of the blockchain and “state of the real world” 

as  s een by the law slowly drift apart
 Cryptoas sets quickly lose their usefulnes s  as  

representations  of the real world



Cryptoassets: Current Legal Obstacles

Pos s ible approaches  to s ynchronis ation
a) Give the s tate  “write  permis s ion”! A super key valid 

for all trans fers
 State  (e .g. judges ) can rectify the  blockchain where 

appropriate

 But what you now have is simply a very slow and 
costly database!



Cryptoassets: Current Legal Obstacles

Pos s ible approaches  to s ynchronis ation
a) Give the s tate  “write  permis s ion”! A super key valid 

for all trans fers
 State  (e .g. judges ) can rectify the  blockchain where 

appropriate
b) Choice of law / contract?
c) Oracles?  
d) Adjudication on the blockchain

“garbage in – garbage out”; equivalent to a)!



Cryptoassets: Current Legal Obstacles

Choice between rock & hard place?
 Create a centralised blockchain sys tem – all the 

overhead, none of the advantages





Cryptoassets: Current Legal Obstacles

Choice between rock & hard place?
 Create a centralised blockchain sys tem – all the 

overhead, none of the advantages  OR
 Certainty that tokens  will not be treated as  real 

representations  of anything
Choos e one: pointles s nes s  or us eles s nes s
 No jus tification for inefficient des ign if feature that 

neces s itates  inefficiency no longer present



Cryptoassets: A Legal Fix?

Objections
 I know a guy…
 AI?
 IoT?
 It worked with paper
Law could embrace Blockchain technology
 In principle , “code is  law” (or something very close to this ) could 

be adopted by the/a re levant legis lator
 Problem: The endorsement would have to be (very nearly) 

absolute
 Smalles t exceptions  would hurt



Cutting Out the Boring, Really Efficient 
Middlemen?
Land regis ter E&W
 around £ 5.5 trillion in assets on a ledger
 Cos t to users? Around 0.006%, including profit to taxpayer 

and services

BNY Mellon
 $33.3 trillion in as sets  under cus tody
 Total revenue $11bn (0.03%)

Self-execution only really works  in a credit-free world



Cryptoassets: No Legal Fix in Sight

So could (s hould/will) the law “give in”?
 Cost/benefit
 His tory?
 Democracy?
 Turkeys  and Chris tmas?
What about naked blockchains (cryptocurrencies )?
 Fundamental objections  do not apply in full
 Law does  not render meaningful implementation impossible
 But: hard to s ee how they can be useful given the exis ting legal 

rules
 Admittedly somewhat weaker case on legal fix



Conclusion

A truly blockchain-bas ed economy is  incompatible with 
the current legal s ys tems  of virtually all countries
Giving the s tate s pecial privileges  renders  blockchain 
s olutions  entirely pointles s  and inefficient
Smart contracts  can only reflect rights  and obligations  
that do not in reality create s ignificant friction
Law will not adapt to the extent neces s ary, nor s hould it



Edmund Schuster
LSE Law Department

E.Schus ter@lse.ac.uk
@Edmund_Schus ter


	Slide Number 1
	Motivation
	Overview
	The mythical powers of the Blockchain
	Slide Number 5
	The empty promise of the blockchain
	Legal analogues of blockchains
	A simple Blockchain simulator
	Legal analogues of blockchains
	Cryptoassets
	“Smart contracts”
	“Smart contracts”
	Blockchains and the Law as a Synchronisation Problem
	Cryptoassets: Current Legal Obstacles
	Cryptoassets: Current Legal Obstacles
	Cryptoassets: Current Legal Obstacles
	Cryptoassets: Current Legal Obstacles
	+
	Cryptoassets: Current Legal Obstacles
	Cryptoassets: A Legal Fix?
	Cutting Out the Boring, Really Efficient Middlemen?
	Cryptoassets: No Legal Fix in Sight
	Conclusion
	Slide Number 24

";"""date"",""2019-01-15T16:18:34Z""
""pdf:PDFVersion"",""1.5""
""xmp:CreatorTool"",""Acrobat PDFMaker 11 for PowerPoint""
""pdf:docinfo:title"",""Cryptoassets  and the Law""
""Company"",""London School of Economics""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""Acrobat PDFMaker 11 for PowerPoint""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""Cryptoassets  and the Law""
""xmp:CreateDate"",""2019-01-15T16:18:23Z""
""modified"",""2019-01-15T16:18:34Z""
""pdf:hasMarkedContent"",""true""
""xmp:ModifyDate"",""2019-01-15T16:18:34Z""
""pdf:docinfo:creator"",""Schuster,E""
""meta:author"",""Schuster,E""
""meta:creation-date"",""2019-01-15T16:18:23Z""
""created"",""2019-01-15T16:18:23Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-01-15T16:18:23Z""
""resourceName"",""Schuster%20-%20Clouud%20Crypto%20-%20Future%20of%20Money.pdf""
""Author"",""Schuster,E""
""producer"",""Adobe PDF Library 11.0""
""pdf:docinfo:producer"",""Adobe PDF Library 11.0""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""access_permission:modify_annotations"",""true""
""dc:creator"",""Schuster,E""
""dcterms:created"",""2019-01-15T16:18:23Z""
""Last-Modified"",""2019-01-15T16:18:34Z""
""dcterms:modified"",""2019-01-15T16:18:34Z""
""title"",""Cryptoassets  and the Law""
""xmpMM:DocumentID"",""uuid:55ff8088-178a-4091-8967-606f3a766045""
""Last-Save-Date"",""2019-01-15T16:18:34Z""
""pdf:docinfo:modified"",""2019-01-15T16:18:34Z""
""meta:save-date"",""2019-01-15T16:18:34Z""
""Content-Length"",""3639033""
""Content-Type"",""application/pdf""
""xmp:MetadataDate"",""2019-01-15T16:18:34Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Schuster,E""
""dc:language"",""EN-GB""
""pdf:producer"",""Adobe PDF Library 11.0""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""24""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""131"",""460"",""459"",""120"",""0"",""377"",""587"",""28"",""394"",""578"",""464"",""580"",""636"",""224"",""275"",""325"",""150"",""0"",""372"",""323"",""316"",""395"",""378"",""69""
""access_permission:extract_content"",""true""
""pdf:docinfo:custom:Company"",""London School of Economics""
""access_permission:can_print"",""true""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-01-15T16:18:23Z""
";https://scholar.google.com/scholar?start=350&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095344-1463;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Background Concepts for Blockchain;SR Chakravarty, P Sarkar ; … , Algorithmic Trading and Blockchain, 2020  emerald.com;;"… The random oracle assumption on H is also often used to (heuristically) argue about the

distribution of the outputs of H. 16.1.3 Digital Signature Schemes … In the context of blockchain,

dissemination of data is more relevant … The ECDSA is used in the cryptocurrency Bitcoin …";;null;null;;;;https://scholar.google.com/scholar?start=260&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095402-1707;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;[PDF][PDF] Ethereum, Smart Contracts, DApps;W Metcalfe ; Blockchain and Crypt Currency, 2020  library.oapen.org;;"… A system that feeds real-world data into the blockchain for use by smart contracts is … a smart contract

system that depends on an oracle, you are implicitly trusting that oracle as a … If you allow many

oracles to provide data in a decentralized manner including incentives for telling …";Cité 9 fois;Les 7 versions;[PDF] oapen.org;https://library.oapen.org/bitstream/handle/20.500.12657/37713/2020_Book_BlockchainAndCryptCurrency.pdf?sequence=1#page=88;"
Economics, Law, and Institutions in Asia Pacific

Makoto Yano
Chris Dai
Kenichi Masuda
Yoshio Kishimoto   Editors

Blockchain 
and Crypt 
Currency
Building a High Quality Marketplace 
for Crypt Data



Economics, Law, and Institutions in Asia Pacific

Series Editor

Makoto Yano, Research Institute of Economy, Trade and Industry (RIETI), Tokyo,
Japan



The Asia Pacific region is expected to steadily enhance its economic and political
presence in the world during the twenty-first century. At the same time, many
serious economic and political issues remain unresolved in the region. To further
academic enquiry and enhance readers’ understanding about this vibrant region, the
present series, Economics, Law, and Institutions in Asia Pacific, aims to present
cutting-edge research on the Asia Pacific region and its relationship with the rest
of the world. For countries in this region to achieve robust economic growth, it is of
foremost importance that they improve the quality of their markets, as history shows
that healthy economic growth cannot be achieved without high-quality markets.
High-quality markets can be established and maintained only under a well-designed
set of rules and laws, without which competition will not flourish. Based on these
principles, this series places a special focus on economic, business, legal, and
institutional issues geared towards the healthy development of Asia Pacific markets.
The series considers book proposals for scientific research, either theoretical or
empirical, that is related to the theme of improving market quality and has policy
implications for the Asia Pacific region. The types of books that will be considered for
publication include research monographs as well as relevant proceedings. The
series show-cases work by Asia-Pacific based researchers but also encourages the
work of social scientists not limited to the Asia Pacific region. Each proposal and final
manuscript is subject to evaluation by the editorial board and experts in the field.

Editorial Board Members:

Aoki, Reiko (Commissioner, Japan Fair Trade Commission, Japan)
Chun, Youngsub (Professor of Economics, Seoul National University, Korea)
Dixit, Avinash K. (John J. F. Sherrerd ’52 University Professor of Economics,

Emeritus, Princeton University, USA)
Fujita, Masahisa (Fellow, The Japan Academy, Japan)
Kamihigashi, Takashi (Director and Professor, Center for Computational Social

Science (CCSS), Kobe University, Japan)
Kawai, Masahiro (Project Professor, Graduate School of Public Policy,

The University of Tokyo, Japan)
Lo, Chang-fa (Honourable Justice, The Constitutional Court, Taiwan)
Matsushita, Mitsuo (Professor Emeritus, The University of Tokyo, Japan)
Nishimura, Kazuo (Professor, Research Institute for Economics and Business

Administration (RIEB) and Interfaculty Initiative in the Social Sciences (IISS),
Kobe University, Japan; Fellow, The Japan Academy, Japan)

Yabushita, Shiro (Professor Emeritus, Waseda University, Japan)
Yoshino, Naoyuki (Dean, Asian Development Bank Institute, Japan; Professor

Emeritus, Keio University, Japan)

More information about this series at http://www.springer.com/series/13451

http://www.springer.com/series/13451


Makoto Yano • Chris Dai •

Kenichi Masuda • Yoshio Kishimoto
Editors

Blockchain and Crypt
Currency
Building a High Quality Marketplace
for Crypt Data



Editors
Makoto Yano
RIETI
Tokyo, Japan

Chris Dai
K.K Longhash
Tokyo, Japan

Kenichi Masuda
Anderson Mori & Tomotsune
Tokyo, Japan

Yoshio Kishimoto
Ministry of Economy, Trade and Industry
Tokyo, Japan

ISSN 2199-8620 ISSN 2199-8639 (electronic)
Economics, Law, and Institutions in Asia Pacific
ISBN 978-981-15-3375-4 ISBN 978-981-15-3376-1 (eBook)
https://doi.org/10.1007/978-981-15-3376-1

Š The Editor(s) (if applicable) and The Author(s) 2020. This book is an open access publication.
Open Access This book is licensed under the terms of the Creative Commons Attribution-
NonCommercial-NoDerivatives 4.0 International License (http://creativecommons.org/licenses/by-nc-
nd/4.0/), which permits any noncommercial use, sharing, distribution and reproduction in any medium or
format, as long as you give appropriate credit to the original author(s) and the source, provide a link to
the Creative Commons license and indicate if you modified the licensed material. You do not have
permission under this license to share adapted material derived from this book or parts of it.
The images or other third party material in this book are included in the book’s Creative Commons
license, unless indicated otherwise in a credit line to the material. If material is not included in the book’s
Creative Commons license and your intended use is not permitted by statutory regulation or exceeds the
permitted use, you will need to obtain permission directly from the copyright holder.
This work is subject to copyright. All commercial rights are reserved by the author(s), whether the whole
or part of the material is concerned, specifically the rights of translation, reprinting, reuse of illustrations,
recitation, broadcasting, reproduction on microfilms or in any other physical way, and transmission
or information storage and retrieval, electronic adaptation, computer software, or by similar or dissimilar
methodology now known or hereafter developed. Regarding these commercial rights a non-exclusive
license has been granted to the publisher.
The use of general descriptive names, registered names, trademarks, service marks, etc. in this publi-
cation does not imply, even in the absence of a specific statement, that such names are exempt from the
relevant protective laws and regulations and therefore free for general use.
The publisher, the authors and the editors are safe to assume that the advice and information in this
book are believed to be true and accurate at the date of publication. Neither the publisher nor the
authors or the editors give a warranty, expressed or implied, with respect to the material contained
herein or for any errors or omissions that may have been made. The publisher remains neutral with regard
to jurisdictional claims in published maps and institutional affiliations.

This Springer imprint is published by the registered company Springer Nature Singapore Pte Ltd.
The registered company address is: 152 Beach Road, #21-01/04 Gateway East, Singapore 189721,
Singapore

https://doi.org/10.1007/978-981-15-3376-1
http://creativecommons.org/licenses/by-nc-nd/4.0/
http://creativecommons.org/licenses/by-nc-nd/4.0/


Preface

Investment in virtual currency over the past few years appears to have somewhat
subsided recently. However, this does not imply that blockchain technology, which
underlies virtual currencies, has become less useful. To the contrary, a new gen-
eration of blockchains, and their applications, are being actively created and
deployed today. The primary purpose of this book is to explore the possibilities of
those new blockchains and their applications, to explain the current state of
blockchain technologies, and their future use for a wide range of scholars and
graduate students beyond their respective fields.

Nowadays, a body of information and communication technology (ICT) and its
supporting social system are often perceived as an ecosystem, or, more precisely, a
cyber ecosystem. With this term, many people recognize the importance of an
ecosystem in which technology and people can coexist in harmony. In this book,
we study the design of such a system supported by blockchain technology.

This book investigates the role that the new generation of blockchains may play
in the coming data-driven society. It is expected that data will become the third
major production factor next to labor and capital in the Internet era. Blockchain
technology opens a new way of owning, sharing, and using data.

A blockchain is often defined as a decentralized ledger. “Ledger” is an old term
that refers to a “book of a permanent record”. A blockchain is a ledger created in a
decentralized manner. In this process, many independent entities contribute to
creating a book of permanent data that is absolutely accurate and unfalsifiable.

Records that are absolutely accurate and unfalsifiable are valuable. A county
recorder’s office keeps the vital records that relate to ownership in real estate (land)
and to debts or liens upon it. Without these records, it would be practically
impossible to trade land and/or to lend and borrow money with land as security.
These records are economically valuable because everyone trusts that they are
absolutely accurate and unfalsifiable. This trust brings value to the record.

Blockchains have shown that such trusted records can be stored on the Internet
in a decentralized manner. The decentralization of the recording process, which has
traditionally been centralized and stewarded by the government, is expected to
significantly economize transaction costs (or the cost of creating and maintaining a

v



ledger). That is one reason why blockchain technology has been accepted enthu-
siastically by many.

By making a ledger of data, a blockchain makes it possible to designate the
owner of each piece of data, to trade data pieces, and to market them. This book
examines the formation of markets for various types of data from the theory of
market quality proposed and developed by Yano (for references, see Chap. 4).

Blockchain technology can create a ledger for any type of record. The original
Bitcoin blockchain records the transfers of funds between different accounts, thereby
providing the same function as deposit currencies that banks offer. If blockchain
technology economizes transaction costs significantly, the current monetary system
based on central banknotes and deposit currencies may be replaced by a blockchain.
Chapter 4 provides an economic analysis of such a possibility, whereas Chap. 5
explains the current state of virtual currency transactions.

Ethereum is a blockchain that is similar to operating systems for PCs and tablets.
Like an operating system, it can let independent application programs, called smart
contracts, be recorded and executed. On Ethereum, users can execute smart con-
tracts, and results of execution are also recorded securely on Ethereum. This makes
it possible for users to develop their own businesses based on smart contract pro-
grams and to raise funds for business projects. The possibilities of those businesses
and the design of laws and regulations for fundraising for smart-contract-based
businesses are discussed in Chaps. 6–8.

Blockchains are expected to give data itself a status of a new production factor.
Currently, people hold a great expectation on bigdata created through the Internet of
Things (IoT). If all data are shared in various production processes, analyzed by
artificial intelligence (AI), and if the results of data analysis are fed back to pro-
duction processes, productivity may improve drastically. However, data sharing
does not progress easily because of the fear of information leakage. Moreover, there
is growing concern over data monopoly and data misuse; much of the data created
through the Internet is accumulating in the hands of large Internet companies. By
bringing the ownership of data into the hands of data producers, blockchains are
expected to reduce the possibility of information leakage, enhance the sharing and
use of IoT data, and prevent data monopoly and misuse. For this purpose, the
current blockchain technology is not sufficiently advanced, and new technology is
being developed. Chapters 2 and 3 cover the economic issues on data ownership
and the current state of blockchain technology for IoT data.

In the ICT industry, the economic process through which a set of ICT tech-
nologies is born and accepted by users has been referred to as an ecosystem.
“Ecosystem” is a widely used term in biology, and describes a natural environment
in which various organisms live their own lives. There is a harmonious environment
consisting of land, rivers, and forests upon which the sun shines and living things
are born, grow, reproduce, and undergo evolutionary changes. It is thought that
such an environment (i.e., ecosystem) is essential for healthy development of
computer technology.

vi Preface



There is a rich cyberspace on the Internet in which many high-speed servers are
connected through optical cables. Many computer engineers develop new software
programs. Many people use and evaluate these programs, and only the most useful
programs are selected. There are also people who evaluate these processes and
invest in promising technologies and software applications. Through these pro-
cesses, existing technologies are improved, and new technologies are born, leading
to the next generation of technology. Such has been the harmonized environment in
which the ICT industry has developed.

To support this process of technological progress, we need an ecosystem that
harmonizes technology, people, and society as a whole. To that end, not only
computer scientists and engineers but also entrepreneurs and business people who
create and operate new businesses are indispensable. Experts who understand
money and finance are also essential. Even more important are the users of services
that the engineers and business people produce. All these people are organically
linked, sharing information and contributing to building the ICT infrastructure. To
build such infrastructure, the process also requires the involvement of legal and
economic experts and policymakers who understand the workings of markets and
can facilitate the formation of high-quality markets. A cyber ecosystem refers to this
whole picture. For the blockchain industry to develop further, it is necessary to
build a healthy cyber ecosystem, the design of which is addressed in this study.

This book is expected to contribute to the creation of such an ecosystem
encompassing both academia and business. After many intensive discussion ses-
sions, a group of various experts in computer science/engineering, economics, law,
policy, and business have assembled this book. While based on the final report
of the study group “Blockchain and Society 5.0—The Creation of a New
Marketplace based on Distributed Consensus” at the Research Institute of
Economy, Trade, and Industry (RIETI), for which Yano serves as the president, the
book is extensively rewritten so that it will appeal to scholars from different fields
and graduate students interested in interdisciplinary issues on blockchain and
related social and technological issues. Of course, the views expressed in this book
are those of the authors, not those of the RIETI.

In organizing the study group and putting together this book, we have received
extensive support from members of the RIETI, for which we are deeply indebted. In
particular, we are grateful to Chairman Atsushi Nakajima of the RIETI for initiating
the study group and for the warm and constant encouragement and to Mr. Masataka
Saburi, Ms. Kiriko Tanimoto, and Mr. Takehiro Watanabe of the International
Division for the promotion and dissemination of our research. Finally, we are
deeply indebted to the president’s secretary, Ms. Kyoko Nakamura, for supporting
the study group and for checking manuscripts at various stages, which has been a
great help while assembling this book.

In preparing this book, we have received very kind help from Springer staff. We
are particularly grateful to Ms. Juno Kawakami for her constant encouragement,
patience, and support to our project and Mr. Austin Schultz for excellent copy
editing.

Preface vii



Recently, blockchain currencies and businesses have been targeted by rather
wild speculative activities. Blockchain currencies have been used extensively for
money laundering and illegal drug trafficking. Because these activities have given
the blockchain industry an image of risky business, social perceptions of blockchain
are rather negative. However, if better technology is developed and a healthy
market infrastructure can be created to support the blockchain market, the industry
will have a bright future. It is our hope that this book will contribute to the creation
of a cyber ecosystem in which the blockchain industry will grow in a healthy and
prosperous manner.

Tokyo, Japan
January 2020

Makoto Yano
Chris Dai

Kenichi Masuda
Yoshio Kishimoto

viii Preface



Contents

1 Creation of Blockchain and a New Ecosystem . . . . . . . . . . . . . . . . . 1
Makoto Yano, Chris Dai, Kenichi Masuda and Yoshio Kishimoto

2 Market Quality Approach to IoT Data on Blockchain Big Data . . . . 21
Steven Pu and Makoto Yano

3 Industrial Applications of Blockchain to IoT Data . . . . . . . . . . . . . . 41
Steven Pu

4 Theory of Money: From Ancient Japanese Copper Coins
to Virtual Currencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Makoto Yano

5 Ethereum, Smart Contracts, DApps . . . . . . . . . . . . . . . . . . . . . . . . . 77
William Metcalfe

6 DEX: A DApp for the Decentralized Marketplace . . . . . . . . . . . . . . 95
Chris Dai

7 Blockchain Business and Its Regulation . . . . . . . . . . . . . . . . . . . . . . 107
Makoto Yano, Chris Dai, Kenichi Masuda and Yoshio Kishimoto

8 Bitcoin and Blockchain Technology . . . . . . . . . . . . . . . . . . . . . . . . . 129
Kazumasa Omote and Makoto Yano

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137

ix



Editors and Contributors

About the Editors

Makoto Yano is Chairman of the Research Institute of Economy, Trade and
Industry (RIETI); he is also a specially appointed professor at Kyoto University,
Jochi University, and Chubu University. He is an internationally known researcher
who has made a number of substantial contributions in international trade, market
theory, and especially on economic dynamics. His contributions in economic
dynamics, for example, are represented by articles in Econometrica in 1995 and the
Journal of Economic Theory in 1996, which explained the conditions under which
general economic equilibrium shows chaotic behavior. His 1998 Econometrica
article is recognized as the latest most important work on the characterization of
dynamic general equilibrium.

Besides those rather theoretical works, Prof. Yano has also provided influential
insights on contemporary real-world phenomena. Those include transfer problems
(American Economic Review, 1999), voluntary export restraints (International
Economic Review [IER], 1995), and trade conflicts (IER, 1998), on which there
have been a number of follow-up papers.

His recent research on “market quality” addresses various problems in modern
economies, including the financial market crisis since 2008 and the recent nuclear
accidents in Japan, from the point of view of market quality—a new economic
concept that Prof. Yano has developed and is applying to Japanese and international
markets. Concerning quality of competition, quality of information, and quality of
products, market quality is defined as an index jointly determined by the efficiency
of an allocation and the fairness of the prices that are achieved in a market.

Prof. Yano received a B.A. in economics from The University of Tokyo in 1971
and a Ph.D. in economics from The University of Rochester in 1981.

Chris Dai is the CEO and co-founder of Leland Capital, Recika Co., Ltd., and
CEO of LongHash Japan. He has a broad range of business management and
investment experience. He was formerly the COO/CIO of Yixing SCM (an

xi



international logistics provider), a consultant at Accenture, and a co-founder of
multiple ventures. Starting in 2013, Mr. Dai was one of the early investors in
Bitcoin and Ethereum. To promote the understanding of blockchain’s true value, he
joined the Research Institute of Economy, Trade and Industry’s blockchain research
team. He received a B.S. in management science and engineering from Stanford
University in 2004.

Kenichi Masuda has been a partner at the law firm of Anderson, Mori &
Tomotsune since 1997. He graduated from The University of Tokyo in 1986. After
completing work at the Judicial Research and Training Institute, he joined the law
firm in 1988. He graduated from The University of Chicago Law School in 1993
and became a member of the New York Bar Association.

Mr. Masuda has extensive experience in advising foreign clients and is familiar
with cross-border issues, in particular, mergers and acquisitions of listed and
unlisted businesses, joint ventures, and other cross-border investments, as well as
corporate restructuring. The scope of his experience also includes assisting and
representing venture companies and establishing venture capital or other private
equity funds. He regularly provides legal services on employment and labor union
relations (including representation of client companies in court and other
dispute-resolution forums), real property transactions, intellectual property issues,
and general corporate and commercial matters.

Mr. Masuda currently teaches at The University of Tokyo Law School as a
visiting professor.

Yoshio Kishimoto is director general of International Policy for Small and
Medium-Sized Enterprises (SMEs), Ministry of Economy, International Trade and
Industry. He was vice president of the Research Institute of Economy, International
Trade and Industry with Professor Yano.

He has held various positions in METI including head of the Environment and
Economy Office, Business Support Division of the SME Agency, and director
general of the Kyushu Bureau of METI. He received his M.A. in international
affairs from Columbia University in 1992 and a Bachelor of Law degree from The
University of Tokyo in 1985.

Contributors

Chris Dai Research Institute of Economy, Trade and Industry (RIETI), Tokyo,
Japan;
Recika Co., Ltd., Tokyo, Japan;
Leland Capital, Hong Kong, Hong Kong

Yoshio Kishimoto Research Institute of Economy, Trade and Industry (RIETI),
Tokyo, Japan

xii Editors and Contributors



Kenichi Masuda Research Institute of Economy, Trade and Industry (RIETI),
Tokyo, Japan

William Metcalfe Curvegrid, Tokyo, Japan

Kazumasa Omote University of Tsukuba, Tsukuba, Japan

Steven Pu Taraxa, San Jose, CA, USA

Makoto Yano Research Institute of Economy, Trade and Industry (RIETI),
Tokyo, Japan

Editors and Contributors xiii



Chapter 1
Creation of Blockchain and a New
Ecosystem

Makoto Yano, Chris Dai, Kenichi Masuda and Yoshio Kishimoto

The Japanese Ministry of Economy, Trade, and Industry regards the process of
incorporating new information technology, such as artificial intelligence (AI),
Internet of Things (IoT), and big data analysis into society as the Fourth Industrial
Revolution. This view is reflected in the Fifth Science and Technology Basic Plan.
The plan advocates Society 5.0, in which cyber space and physical space are
integrated to support an affluent and human-friendly society. Computer scientists
regard the interconnection of industry and society through information technologies,
with people creating and using such technologies, as a single ecosystem. They have
actively participated in the design and discussion of such an integrated ecosystem.
Blockchain is considered to be at the core of such a cyber ecosystem.

Terms like the Fourth Industrial Revolution, Society 5.0, and cyber ecosystems
seem colorful and might appear rather farfetched. However, when placed in the
context of the current states of the economy and technological development, one
realizes that the new concepts are rather persuasive. This is because the technological
innovation that is about to start is very unique in the long history of technological
advancement since the First Industrial Revolution.

Today,we arewitnessing the introduction of a new type of productive resource into
our economy—data. Data is a new productive resource that had no economic value in
the past. Until a few years ago, there was no way to gather large volumes of data that
could capture daily life accurately, nor were there any computing technologies that

The original version of this chapter is written as a part of our final report to the study group
“Blockchain andSociety 5.0—TheCreation of aNewMarketplace based onDistributedConsensus”
at the Research Institute of Economy, Trade, and Industry (RIETI). The authors are grateful to all
the participant in the study group; the first author gratefully acknowledges the financial support of
a Grant-in-Aid for Scientific Research (A) (#16H02015) from the Japan Society for the Promotion
of Science.

M. Yano (B) ¡ C. Dai ¡ K. Masuda ¡ Y. Kishimoto
Research Institute of Economy, Trade and Industry (RIETI), Tokyo, Japan
e-mail: yano-makoto@rieti.go.jp

Š The Author(s) 2020
M. Yano et al. (eds.), Blockchain and Crypt Currency,
Economics, Law, and Institutions in Asia Pacific,
https://doi.org/10.1007/978-981-15-3376-1_1

1

http://crossmark.crossref.org/dialog/?doi=10.1007/978-981-15-3376-1_1&domain=pdf
mailto:yano-makoto@rieti.go.jp
https://doi.org/10.1007/978-981-15-3376-1_1


2 M. Yano et al.

made it possible to analyze an extremely large volume of data to explain complicated
human interactions on both production and consumption sides of an economy. This
has changed all of a sudden.Manyproductive resources, such as coal andoil, suddenly
became valuable during past industrial revolutions. However, they merely replaced
already existing resources. Coal replaced firewood and charcoal; oil replaced coal.
Data, in contrast, does not replace any existing resources but is born as a completely
new type of productive resource.

In short, industrial revolution in the past meant destroying existing resources and
replacing them with new resources. Sitting in the middle of the Fourth Industrial
Revolution, in contrast, data does not replace any existing resources.

From an economic viewpoint, this difference between past industrial revolutions
and the Fourth Industrial Revolution is large. Previously, the ownership of oil was
assigned to the owner of the land containing the oil, just as the ownership of coal
was assigned before oil was utilized as a major energy source. In the case of data,
we have not established a clear agreement on who owns the data. As Nobel laureate
Ronald Coase (1910–2013) pointed out, the assignment of proper ownership rights
is a prerequisite for the formation of a market.

In these circumstances, blockchain technology opens important avenues to make
efficient and fair use of data. In a broader sense, this technology is also referred to
as a “decentralized ledger,” which can involve a large number of unspecified people
to contribute to the effective and fair use of data in a decentralized manner.

In summary, blockchain is expected to play an important role in connecting infor-
mation technology and technologies such asAI, IoT, and big datawith our lives. From
this point of view, this book investigates the roles that blockchain plays in a virtual
ecosystem from various angles, in particular, from the following three viewpoints:
(1) data ownership, (2) data transactions, and (3) data industry.

1 Data: A New Productive Resource

If you are a smart phone user, it must be impossible to think of a daywithout access to
the Internet. A mechanism to assign unique numbers to various things and integrate
them into the Internet is called the Internet of Things (IoT). Smartphones are all
recognized as IoT terminals, identified by their unique identifiers called telephone
numbers, and, now, play a central role in data storage on the Internet.

With the exception of the phone function, almost all the information acquired
through smartphones is provided through the Internet. At the same time, we have
become an important source of information. Buying goods through Amazon is like
offering part of your household account book. When using Facebook and the “like”
function is used, some sort of preference is expressed toward society. Sending emails
also implies providing information to society.

It is not only humans that can be connected with cyber space through IoT. Com-
puter sensors can be placed on livestock in pasture to keep track of their health and



1 Creation of Blockchain and a New Ecosystem 3

nutritional needs. If sensors are attached to trees and every square meter of farm-
land, the growth conditions of trees and vegetables in every square meter of the field
can be monitored. In this way, a new ecosystem of human beings and living things,
with information technology as infrastructure, can be created. Sensors on a car can
keep track of driving habits, which is useful to enhance driving safety. Similarly,
sensors in a hospital room can monitor and report the state of each patient and give
useful information to carers. In this way, we can create a new ecosystem based on
information and communication technology.

In the ecosystem, all information is digitized and recorded as numbers. This iswhy
the information exchanged in IoT is called data. With modern computer technology,
huge volumes of data can be collected and scientifically analyzed in detail to gain
insights into various phenomenamuch deeper and clearer than possible only 10 years
ago. Results from data analysis have started to profoundly influence our society.

This has transformed data into a new type of productive resource, by which we
can manage production processes in a much more precise manner. With data on
people’s medical histories, doctors will be able to diagnose a patient’s illness much
more accurately and give better or more appropriate treatments. With data on car
driving, insurance companies will evaluate driving risks much more accurately, thus
allowing them to reduce insurance fees where appropriate. With data on purchases
in stores, both manufacturers and retailers have increased ability to market attractive
products to customers. All these possibilities are brought about by the data-gathering
capability of the Internet and the data-processing capabilities of modern computers.

2 Blockchain Technology

Blockchain may still be a new term for many readers. It is, therefore, appropriate to
start with a discussion on the definition of blockchain.

A ledger is a book of permanent record. The record must be correct and tamper-
free. A blockchain is a ledger that is put together on the Internet in a decentralized
manner by an indefinite number of contributors.

Blockchain is a chain of files containing whatever needs to be permanently
recorded. A basic blockchain connects files to form a simple string of chain. A
more sophisticated blockchain connects files to form a net-like structure.

2.1 Blockchain and Data Ownership

A database is like an address book in which many data elements are stored system-
atically and organized for easy use. Blockchain is a new technology that allows us
to record data and sources and recipients of data exchanged on the Internet, thereby
creating an accurate, permanent, and very inexpensive database.



4 M. Yano et al.

The first application of blockchain technology was the virtual currency called
Bitcoin. Functionally, a virtual currency is much the same as a deposit currency that
is based on bank accounts. Each bank account records debits to and credits from
other accounts, which the bank keeps to be absolutely accurate and tamper-free.
Because the record shows who owes how much to whom, and because people trust
that the records are absolutely reliable, it can be used to transfer money through wire
transfers; debit cards are a major means of payment nowadays. A virtual currency
is a similar collection of accounts (called wallets) that record debits and credits.
The difference is that the virtual currency accounts are on the Internet. Blockchain
technology has made it possible to keep this record absolutely reliable by using
algorithm without relying on a central authority like a bank.

Blockchain accounts record digital data, which plays the role of money because
people trust that they are accurate and tamper-free. As this shows, blockchain can
assign the ownership of each data piece to an account holder. This is the innovation
that blockchain technology has brought to society.

2.2 Distributed Computing

Distributed computing is a revolutionary innovation in computer networks, which
allows many terminal computers to perform complicated tasks independently (Holo-
han and Garg 2005). One good example is a category of games called “massively
multiplayer online games” in which many different players participate and try to
achieve their respective goals, which may vary from car racing ";"""date"",""2020-04-10T14:11:43Z""
""pdf:PDFVersion"",""1.6""
""xmp:CreatorTool"",""Adobe InDesign 15.0 (Windows)""
""pdf:docinfo:title"",""489142_1_En_Print.indd""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""pdfa:PDFVersion"",""A-2b""
""xmpMM:History:Action"",""converted"",""converted"",""converted""
""language"",""en""
""dc:format"",""application/pdf; version=""""A-2b"""""",""application/pdf; version=1.6""
""pdf:docinfo:creator_tool"",""Adobe InDesign 15.0 (Windows)""
""access_permission:fill_in_form"",""true""
""xmpMM:History:When"",""2020-04-10T17:53:27Z"",""2020-04-10T17:53:35Z"",""2020-04-10T15:02:52Z""
""pdf:encrypted"",""false""
""dc:title"",""489142_1_En_Print.indd""
""xmp:CreateDate"",""2020-04-06T13:08:28Z""
""modified"",""2020-04-10T14:11:43Z""
""xmpMM:History:SoftwareAgent"",""pdfToolbox"",""pdfToolbox"",""pdfToolbox""
""pdf:hasMarkedContent"",""false""
""xmpMM:History:InstanceID"",""uuid:033d2504-4a97-469d-9565-54ab6adc2d94"",""uuid:45020678-8f9e-4629-82de-89003eaa68b4"",""uuid:c90ecd54-4ee6-4d0e-8b9c-1aebef6cd9e1""
""xmp:ModifyDate"",""2020-04-10T19:41:43Z""
""pdf:docinfo:creator"",""0015220""
""meta:author"",""0015220""
""meta:creation-date"",""2020-04-06T07:38:28Z""
""created"",""2020-04-06T07:38:28Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-04-06T07:38:28Z""
""resourceName"",""2020_Book_BlockchainAndCryptCurrency.pdf""
""pdfaid:part"",""2""
""Author"",""0015220""
""producer"",""Acrobat Distiller 10.1.16 (Windows)""
""pdf:docinfo:producer"",""Acrobat Distiller 10.1.16 (Windows)""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""12"",""0"",""1"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""access_permission:modify_annotations"",""true""
""dc:creator"",""0015220""
""dcterms:created"",""2020-04-06T07:38:28Z""
""Last-Modified"",""2020-04-10T14:11:43Z""
""dcterms:modified"",""2020-04-10T14:11:43Z""
""title"",""489142_1_En_Print.indd""
""xmpMM:DocumentID"",""uuid:c44c73cf-248f-4de0-95d5-eb4f4424c708""
""Last-Save-Date"",""2020-04-10T14:11:43Z""
""pdf:docinfo:modified"",""2020-04-10T14:11:43Z""
""meta:save-date"",""2020-04-10T14:11:43Z""
""Content-Length"",""2094843""
""Content-Type"",""application/pdf""
""xmp:MetadataDate"",""2020-04-10T19:41:43Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""0015220""
""pdfaid:conformance"",""B""
""dc:language"",""EN""
""pdf:producer"",""Acrobat Distiller 10.1.16 (Windows)""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""150""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""187"",""126"",""2407"",""125"",""2553"",""2062"",""2781"",""2830"",""654"",""767"",""1753"",""2095"",""284"",""2144"",""2621"",""2343"",""2582"",""2617"",""2383"",""2128"",""2441"",""2215"",""2016"",""2332"",""2494"",""1876"",""2594"",""2536"",""2452"",""2759"",""3585"",""890"",""1722"",""2783"",""2664"",""2940"",""2511"",""2593"",""2476"",""2352"",""2605"",""2965"",""2568"",""2371"",""2306"",""1840"",""2526"",""2406"",""2239"",""2823"",""3219"",""1142"",""1436"",""3050"",""2877"",""2253"",""2544"",""2412"",""2074"",""2221"",""2241"",""1803"",""2780"",""2740"",""1963"",""1912"",""2526"",""2527"",""3075"",""2099"",""1711"",""2179"",""2381"",""2254"",""2325"",""2790"",""1948"",""2625"",""1830"",""2119"",""1902"",""2425"",""2475"",""2413"",""1604"",""1767"",""2533"",""1700"",""2459"",""2595"",""2582"",""2043"",""2808"",""2215"",""2539"",""2169"",""2174"",""2608"",""1981"",""2442"",""2299"",""2659"",""2900"",""1217"",""1566"",""2926"",""1471"",""2758"",""2451"",""2803"",""2616"",""2366"",""1560"",""2645"",""2657"",""2394"",""1940"",""2579"",""1948"",""2096"",""2525"",""2510"",""2669"",""2375"",""2649"",""2345"",""2767"",""2399"",""2884"",""2888"",""2901"",""2329"",""2700"",""2506"",""2167"",""2973"",""2383"",""1611"",""2105"",""2340"",""2482"",""2966"",""2487"",""2456"",""2976"",""1670"",""2324"",""1995"",""2118"",""1350""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-04-06T07:38:28Z""
";https://scholar.google.com/scholar?start=510&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095304-1290;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Blockchain: The Facts and Fiction;R Ballard ; ITNOW, 2020  academic.oup.com;;"… platform securely extends your business processes and applications while enabling you to process

business transactions much faster.' — Oracle 'For the … The blockchain is … The term 'crypto' (with

or without a suffix) appears to serve only the purpose of sounding cool and high …";;null;[PDF] oup.com;https://academic.oup.com/itnow/article-pdf/62/2/22/33194291/bwaa039.pdf?casa_token=jD7YVw7TxdMAAAAA:jNg9Zlu5lRexPxVmVzLWGTjsNFxzDfksOBWLAniyP41_gtRJcwp-7hsZMd0tW6Ia325jH33_A4U;"
    
        
            
        

            Skip to Main Content

    








    
        
    
    
        
    
    
        
    

        Advertisement


 
    


    


    
        
            
                
                    [image: Oxford University Press]
                
            


            	
                    
                        Search Menu
                    
                
	
                        
                            Account Menu
                        
                
	
                    
                        Menu
                    
                
	
                        
Sign In                            
                        
                        
                            

                        

                
	Register



            
                

            

        

    

    

        
        
            
                    
                        
                            Navbar Search Filter
                            This issue
All  ITNOW
All  BCS Journals
All  Journals







                            Mobile Microsite Search Term
                            

                            Search

                        

                    
            

        

        
        
            	
                    
                        
Sign In                        
                    
                    	
                            

                        


                
	
                        Register
                    


        

        
        


    
    	
                Issues
                
            
	
                Submit
                    
    	
                Author Guidelines
                
            
	
                Open Access Options
                
            



            
	
                Purchase
                
            
	
                Alerts
                
            
	
                About
                    
    	
                About ITNOW
                
            
	
                About the BCS, The Chartered Institute for IT
                
            
	
                Editorial Board
                
            
	
                Advertising and Corporate Services
                
            
	
                Journals Career Network
                
            
	
                Policies
                
            
	
                Self-Archiving Policy
                
            
	
                Dispatch Dates
                
            
	
                Contact Us
                
            



            


        


    


    
        
                            
                    [image: ITNOW]
                

            
                    
                            
                                [image: BCS, The Chartered Institute for IT]
                            
                                            
            
 
        

    

    
        
            


    
    	
                Issues
                
            
	
                Submit
                    
    	
                Author Guidelines
                
            
	
                Open Access Options
                
            



            
	
                Purchase
                
            
	
                Alerts
                
            
	
                About
                    
    	
                About ITNOW
                
            
	
                About the BCS, The Chartered Institute for IT
                
            
	
                Editorial Board
                
            
	
                Advertising and Corporate Services
                
            
	
                Journals Career Network
                
            
	
                Policies
                
            
	
                Self-Archiving Policy
                
            
	
                Dispatch Dates
                
            
	
                Contact Us
                
            



            


            
                
                    Close
                        
                            
                                search filter
                                This issue
All  ITNOW
All  BCS Journals
All  Journals



                                search input
                                

                                Search

                            

                        
                    Advanced Search

                
                Search Menu

        

    



    
    
    
    
    
    
        
        
        
        
        
        
        
        
        
    
    
 
    




    
            
                
                    Skip Nav Destination
                    




    
        Article Navigation
    

    
        
            Close mobile search navigation
        
        Article Navigation

        
    
        


    
    
            [image: Issue Cover]
    

    
        

            
                        Volume 62

                        Issue 2


            

        

        
June 2020        

        
    



 
    


            

            

    
        	
            < Previous
        
	
            Next >
        

 
    


        

    






    
        
            
                Article Navigation
            
        

    

    
    
        

    

    
        
                        



    
                
                    Blockchain: The Facts and Fiction
                

                
                    
                                






                                    Ron Ballard

                                    

    
        
    Ron Ballard



    



    
        Search for other works by this author on:
    



    Oxford Academic



    
        Google Scholar
    


                                    
                                

                    

                



        
            ITNOW, Volume 62, Issue 2, June 2020, Pages 22–25, https://doi.org/10.1093/itnow/bwaa039

        

        
            
                Published:

                08 May 2020

            

        

    

    






 
    

    
         
    



        
            
                
                    	
                            
                                
                                
                                    Views

                                    
                                

                            
                            


                                
	
                                    Article contents
                                
	
                                    Figures & tables
                                
	
                                    Video
                                
	
                                    Audio
                                
	
                                    Supplementary Data
                                


                        
                        	
    
        Cite


    Cite

        
            Ron Ballard,  Blockchain: The Facts and Fiction, ITNOW, Volume 62, Issue 2, June 2020, Pages 22–25, https://doi.org/10.1093/itnow/bwaa039

        


    
        
            
            
            Select Format
            Select format
.ris (Mendeley, Papers, Zotero)
.enw (EndNote)
.bibtex (BibTex)
.txt (Medlars, RefWorks)


            Download citation
        

    


    Close


 
    


                        
	
    
            
        
            
                Permissions Icon
            
            Permissions
        
    

 
    


                        
	
                            
                                
                                
                                    Share

                                    
                                

                            
                            


                                
	Email
	Twitter
	Facebook
	More


                        
                    
                    
    
        


    

        
        
            
                    
                        
                            Navbar Search Filter
                            This issue
All  ITNOW
All  BCS Journals
All  Journals







                            Mobile Microsite Search Term
                            

                            Search

                        

                    
            

        

        
        
            	
                    
                        
Sign In                        
                    
                    	
                            

                        


                
	
                        Register
                    


        

        
        

        


    



    
        
            

            
                
                    Close
                        
                            
                                search filter
                                This issue
All  ITNOW
All  BCS Journals
All  Journals



                                search input
                                

                                Search

                            

                        
                    Advanced Search

                
                Search Menu

        

    



 
    


                    

                

            

            
    
        
    





                    Abstract

If you look at any indicator of what the data management world is interested in right now, blockchain will be at the top of the list, writes Ron Ballard, database consultant and author.
                        

        



        


        
Š 2020 The British Computer Society
This article is published and distributed under the terms of the Oxford University Press, Standard Journals Publication Model (https://academic.oup.com/journals/pages/open_access/funder_policies/chorus/standard_publication_model)



        

    




 
    

    
        
    
                
                    Issue Section:

                        OP-ED
                


    



 
    

    
        
 
    

    
        
 
    


                    
                        You do not currently have access to this article.
                    

                

                
                    Download all slides
                

                    
         
    


                
    
        

 
    

    
         
    


                

            

        


            
                


    Sign in

        
            
                Don't already have an Oxford Academic account? Register
            

        

    
            
    
            

        
            
                

            

        


        
            
                You could not be signed in. Please check your email address / username and password and try again.
            

        


        
            Oxford Academic account

            
                
                    Email address / Username
                    ?
                
                
            


            
                Password
                
            


            
                Sign In
                
                    Forgot password?
                

                
                    Don't have an account?
                

            


        



        
            HPC
        


        
        
    

    
        Email address / username
Most users should sign in with their email address. If you originally registered with a username please use that to sign in.

        Close
    

    

 
    


            

                    
                    

                    

                                    
                        Sign in via your Institution

                        Sign in

                    

            

    





    
            
        Purchase

        Subscription prices and ordering

            
                Short-term Access


                    
                        
                            To purchase short term access, please sign in to your Oxford Academic account above.
                        

                        
                            Don't already have an Oxford Academic account? Register
                        

                    


                Blockchain: The Facts and Fiction - 24 Hours access
                
                        
                            EUR €27.00
                        

                        
                            GBP ÂŁ20.00
                        

                        
                            USD $35.00
                        

                

                
            


    


    
        Rental

        
            
                [image: Read this now at DeepDyve]
            

            
                This article is also available for rental through DeepDyve.
            

        

    

 
    


                


            

    




    
        
    
    
        
    

        Advertisement


 
    

 

    

 

    

    
        



        

            

                
                        
                            220
                            Views
                        


                    
                        
0                        
                        Citations
                    

                    
                            
    
            
    

         
 
    


                            



                        

                    


                    
                        View Metrics
                    

            

                
                    
                        ×
                    

                

        

 
    

    
        
    
        Email alerts

                
                    Article activity alert
                

                
                    New issue alert
                

                    
                Receive exclusive offers and updates from Oxford Academic
            

        
            

            
                
            
        

    

 
    

    
         
    

    
        
    Citing articles via

    
                    
                Google Scholar
            

                    
                Crossref
            

    


 
    

    
            	
                
                    Latest
                

            
	
                
                    Most Read
                

            
	
                
                    Most Cited
                

            


        






    




            
                    


    

    



        
Introducing John Higgins    





        
            
        






    

    



        
How Covid-19 Changed The Future    





        
            
        






    

    



        
Why is it Governance so Important?    





        
            
        






    

    



        
The Future of Battery Tech    





        
            
        






    

    



        
AI and US: Engineering a Healthy Relationship    





        
            
        





                    

            





        
        
        
        
        
 
    


    




    



    
        
    
    
        
    

        Advertisement


 
    













                

            
    


        
        


        
            


    
            
    
        
    
    
        
    

        Advertisement


 
    


    



    



    	
    About ITNOW

	
    Editorial Board

	
    Policies

	
    Author Guidelines

	
    Contact Us


	
    Facebook

	
    Twitter

	
    Purchase

	
    Recommend to your Library

	
    Advertising and Corporate Services


	
    Journals Career Network







        
            

    [image: ITNOW]
                        


        
            	Online ISSN 1746-5710
	Print ISSN 1746-5702
	Copyright Š 2021 British Computer Society


        



    


 
    


    
        
    
        


	
    About Us
    
	
    Contact Us
    
	
    Careers
    
	
    Help
    
	
    Access & Purchase
	
    Rights & Permissions
    
	
    Open Access
    





Connect

	
    Join Our Mailing List
    
	
    OUPblog
    
	
    Twitter
    
	
    Facebook
    
	
    YouTube
    
	
    Tumblr
    





Resources

	Authors
	Librarians
	Societies
	Sponsors & Advertisers
	Press & Media
	Agents





Explore

	Shop OUP Academic
	Oxford Dictionaries
	Epigeum
	OUP Worldwide
	University of Oxford





Oxford University Press is a department of the University of Oxford. It furthers the University's objective of excellence in research, scholarship, and education by publishing worldwide

[image: Oxford University Press]






	Copyright Š 2021 Oxford University Press
	Cookie Policy
	Privacy Policy
	Legal Notice
	Site Map
	Accessibility







    
    
     
    


        

    

    

    


        








    



    
        
    

    Close




    
        This Feature Is Available To Subscribers Only

        Sign In or Create an Account

    

    Close




    This PDF is available to Subscribers Only

    View Article Abstract & Purchase Options
    
        For full access to this pdf, sign in to an existing account, or purchase an annual subscription.

    

    Close


 
    


    







    
    


    
    
    

    
    

    



    

    
    




    


    
        
        
            [image: Scholarly IQ]
        



    

    
         
    


    



";"""msapplication-config"",""//oup.silverchair-cdn.com/UI/app/img/v-637520497125602725/browserconfig.xml""
""og:image"",""https://oup.silverchair-cdn.com/oup/backfile/Content_public/Journal/itnow/Issue/62/2/1/m_combul_62_2cover.png?Expires=1681195923&Signature=Js8OD0ZyMj4uJ8Odfiq2Iv4EHmNv40Nd9khmHEW~BBBDgwrpkZDrjxoK~rdph-AFKqM11NKmpX-wEbaTAHFZA6qotyuNmrSUxVL5mLC3LGnchoSKefzUZpO6onJLGOKFVyRTGm8AmEbqWDkFxMH2q-nhkPgvUjehf5CBp~eXHaAwTy1cn-3skvGFsrlIKQBQZVBYkMfCLMxenf-isr5aAxy2MJF3j5g9sV1klbP6C11i7w43nB38ZoEQGh0bUXrPwwCVZr2Lxm3u1nKVq09W6ag7A3u32fw7lI9XAqhABKZ3Fuzw8xvdAbgy52H7tgwfyAMva8FoKQMgA5jfFfg2Ww__&Key-Pair-Id=APKAIE5G5CRDK6RD3PGA""
""citation_publication_date"",""2020/06/01""
""theme-color"",""#002f65""
""citation_title"",""Blockchain: The Facts and Fiction""
""og:site_name"",""OUP Academic""
""citation_publisher"",""Oxford Academic""
""citation_journal_title"",""ITNOW""
""description"",""Abstract. If you look at any indicator of what the data management world is interested in right now, blockchain will be at the top of the list, writes Ron Balla""
""language"",""en""
""title"",""Blockchain: The Facts and Fiction | ITNOW | Oxford Academic""
""og:description"",""Abstract. If you look at any indicator of what the data management world is interested in right now, blockchain will be at the top of the list, writes Ron Balla""
""citation_issn"",""1746-5702""
""dc:title"",""Blockchain: The Facts and Fiction | ITNOW | Oxford Academic""
""Content-Encoding"",""UTF-8""
""Content-Type-Hint"",""text/html; charset=utf-8""
""citation_pdf_url"",""https://academic.oup.com/itnow/article-pdf/62/2/22/33514185/bwaa039.pdf""
""Content-Length"",""83247""
""citation_xml_url"",""https://academic.oup.com/itnow/article-xml/62/2/22/5834695""
""citation_lastpage"",""25""
""Content-Type"",""text/html; charset=UTF-8""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""og:type"",""article""
""citation_journal_abbrev"",""ITNOW""
""og:title"",""Blockchain: The Facts and Fiction""
""citation_author"",""Ballard, Ron""
""resourceName"",""bwaa039.pdf""
""og:updated_time"",""2020-05-08""
""citation_issue"",""2""
""X-UA-Compatible"",""IE=Edge""
""citation_firstpage"",""22""
""viewport"",""width=device-width, initial-scale=1, maximum-scale=1""
""citation_doi"",""10.1093/itnow/bwaa039""
""citation_volume"",""62""
""og:url"",""https://academic.oup.com/itnow/article/62/2/22/5834695""
""Content-Language"",""en""
""format-detection"",""telephone=no""
";https://scholar.google.com/scholar?start=90&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095325-1381;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;XOX Fabric: A hybrid approach to blockchain transaction execution;C Gorenflo, L Golab, S Keshav ; … Blockchain and Cryptocurrency …, 2020  ieeexplore.ieee.org;;"… Compatibility with external oracles: To allow the use of external oracles in the deterministic second

execution phase, we gather and save oracle inputs in … II. BACKGROUND A. State machine

replication and invalid state transitions We can model blockchain systems as state …";Cité 3 fois;Les 3 versions;[PDF] arxiv.org;https://arxiv.org/pdf/1906.11229;"
ar
X

iv
:1

90
6.

11
22

9v
3 

 [
cs

.D
C

] 
 9

 M
ar

 2
02

0

XOX Fabric: A hybrid approach to blockchain

transaction execution

Christian Gorenflo

University of Waterloo

Waterloo, Canada

Email: cgorenflo@uwaterloo.ca

Lukasz Golab

University of Waterloo

Waterloo, Canada

Email: lgolab@uwaterloo.ca

Srinivasan Keshav

University of Cambridge

Cambridge, UK

Email: sk818@cam.ac.uk

Abstract—Performance and scalability are major concerns
for blockchains: permissionless systems are typically limited
by slow proof of X consensus algorithms and sequential post-
order transaction execution on every node of the network.
By introducing a small amount of trust in their participants,
permissioned blockchain systems such as Hyperledger Fabric can
benefit from more efficient consensus algorithms and make use
of parallel pre-order execution on a subset of network nodes.
Fabric, in particular, has been shown to handle tens of thousands
of transactions per second. However, this performance is only
achievable for contention-free transaction workloads. If many
transactions compete for a small set of hot keys in the world state,
the effective throughput drops drastically. We therefore propose
XOX: a novel two-pronged transaction execution approach that
both minimizes invalid transactions in the Fabric blockchain
and maximizes concurrent execution. Our approach additionally
prevents unintentional denial of service attacks by clients re-
submitting conflicting transactions. Even under fully contentious
workloads, XOX can handle more than 3000 transactions per
second, all of which would be discarded by regular Fabric.

I. INTRODUCTION

Blockchain systems have substantially evolved from their

beginnings as tamper-evident append-only logs. With the ad-

dition of smart contracts, complex computations based on the

blockchain’s state become possible. In fact, several permis-

sionless and permissioned systems such as Ethereum [14] and

Hyperledger Fabric [3] allow Turing-complete computations.

However, uncoordinated execution of smart contracts in a

decentralized network can result in inconsistent blockchains,

a fatal flaw. Fundamentally, blockchain systems have two

options to resolve such conflicts. They can either coordinate,

i.e., execute contracts after establishing consensus on a linear

ordering, or they can deterministically resolve inconsistencies

after parallel execution.

Most existing blockchain systems implement smart contract

execution after ordering transactions, giving this pattern the

name order-execute (OX). In these systems, smart contract

execution happens sequentially. This allows each execution

to act on the result of the previous execution, but restricts

the computation to a single thread, limiting performance.

Blockchains using this pattern must additionally guarantee

that the smart contract execution reaches the same result on

every node in the network that replicates the chain, typically

by requiring smart contracts to be written in a domain-

specific deterministic programming language. This restricts

programmability. Moreover, this makes the use of external data

sources, so-called oracles, difficult, because they cannot be

directly controlled and may deliver different data to different

nodes in the network.

Other blockchain systems, most notably Hyperledger Fabric,

use an execute-order (XO) pattern. Here, smart contracts re-

ferred to by transactions are executed in parallel in a container

before the ordering phase. Subsequently, only the results of

these computations are ordered and put into the blockchain.

Parallelized smart contract execution allows, among other

benefits, a nominal transaction throughput orders of magnitude

higher than that of other blockchains [5]. However, a model

that executes each transaction in parallel is inherently unable

to detect transaction conflicts1 during execution.

Prior work on contentious workloads in Fabric focuses on

detecting conflicting transactions during ordering and abort-

ing them early. However, this tightly couples architecturally

distinct parts of the Fabric network, breaking its modular

structure. Furthermore, early abort only treats a symptom and

not the cause in that it only filters out conflicting transactions

instead of preventing their execution in the first place. This

approach will not help if many transactions try to modify

a small number of ‘hot’ keys. For example, suppose the

system supports a throughput of 1000 transactions per second.

Additionally, suppose 20 transactions try to access the same

key in each block of 100 transactions. Then, only one of the

20 transactions will be valid and the rest must be aborted early.

Subsequently, all 19 aborted clients will attempt to re-execute

their transactions, adding to the 20 new conflicting transactions

in the next block. This leads to 38 aborted transactions

in the next round, and so on. Clearly, with cumulative re-

execution, the number of aborted transactions grows linearly

until it surpasses the throughput of the system. Thus, if clients

re-execute aborted transactions, their default behaviour, this

effectively becomes an unintentional denial of service attack

on the blockchain!

This inherent problem with the XO pattern greatly reduces

the performance of uncoordinated marketplaces or auctions.

For example, conflicting transactions cannot be avoided in use

cases such as payroll, where an employer transfers credits to

1Two transactions are said to conflict if either one reads or writes to a key
that is written to by the other.

http://arxiv.org/abs/1906.11229v3


a large number of employees periodically, or energy trading,

where a small number of producers offer fungible units of

energy to a large group of consumers.

We therefore propose XOX Fabric that essentially adds

a second deterministic re-execution phase to Fabric. This

phase executes ‘patch-up code’ that must be added to a smart

contract. We show that, in many cases, this eliminates the

need to re-submit and re-execute conflicting transactions. Our

approach can deal with highly skewed contentious workloads

with a handful of hot keys, while still retaining the decoupled,

modular structure of Fabric. Our contributions are as follows:

• Hybrid execution model: Our execute-order-

execute (XOX) model allows us to choose an optimal

trade-off between concurrent high-performance execution

and consistent linear execution, preventing the cumulative

re-execution problem.

• Compatibility with external oracles: To allow the use

of external oracles in the deterministic second execution

phase, we gather and save oracle inputs in the pre-order

execution step.

• Concurrent transaction processing: By computing a DAG

of transaction dependencies in the post-order phase, Fab-

ric peers can maximize parallel transaction processing.

Specifically, they not only parallelize transaction valida-

tion and commitment, making full use of modern multi-

core CPUs, but also re-execute transactions in parallel

as long as these transactions are not dependent on each

other. This alleviates the execution bottleneck of OX

blockchains.

We achieve these contributions while being fully legacy-

compatible and without affecting Fabric’s modularity. In fact,

XOX can replace an existing Fabric network setup by changing

only the Fabric binaries2.

II. BACKGROUND

A. State machine replication and invalid state transitions

We can model blockchain systems as state machine repli-

cation mechanisms [11]. Each node in the network stores a

replica of a state machine, with the genesis block as its START

state. Smart contracts then become state transition functions.

They take client requests (transactions) as input and compute

a state transition which can be subsequently committed to the

world state. This world state is either implicitly created by the

data on the blockchain or explicitly tracked in a data store,

most commonly a key-value store. Because of blockchain’s

inherently decentralized nature, keeping the world state con-

sistent on all nodes is not trivial. A node’s stale state, a client’s

incomplete information, parallel smart contract execution, or

malicious behaviour can produce conflicting state transitions.

Therefore, a blockchain’s execution model must prevent such

transactions from modifying the world state. There are two

possibilities to accomplish this, the OX and XO approaches,

that we have already outlines. In the next two subsections, we

explore some subtleties of each approach.

2Source code available at https://github.com/cgorenflo/fabric/tree/xox-1.4

B. The OX model

The order-execute (OX) approach guarantees consensus on

linearization of transactions in a block. However, it requires

certain restrictions on the execution engine to guarantee that

each node makes identical state transitions. First, the output of

the execution engine must be deterministic. This requires the

use of a deterministic contract language, such as Ethereum’s

Solidity, which must be learned by the application developer

community. It also means that external oracles cannot eas-

ily be incorporated because different nodes in the network

may receive different information from the oracle. Second,

depending on the complexity of smart contracts, there needs

to be a mechanism to deal with the halting problem, i.e., the

inherent a priori unknowability of contract execution duration.

A common solution to this problem is the inclusion of an

execution fee like Ethereum’s gas, which aborts long-running

contracts.

C. The XO model

The execute-order (XO) model approach allows transactions

to be executed in arbitrary order: the resulting state transitions

are then ordered and aggregated into blocks. This allows

transactions to be executed in parallel, increasing throughput.

However, the world state computed at the time of state

transition commitment is known to execution engines only

after some delay, and all transactions are inevitably executed

on a stale view of the world state. This makes it possible for

transactions to result in invalid state transitions even though

they were executed successfully before ordering. It necessitates

a validation step after ordering so transitions can be invalidated

deterministically based on detected conflicts. Consequently,

for a transaction workload with a set of frequently updated

keys, the effective throughput of an XO system can be

significantly lower than the nominal throughput (we formalize

this as the Hot Key Theorem below).

D. Hyperledger Fabric

Hyperledger Fabric has been described in detail by An-

droulaki et al [3]. Below, we describe those parts of the Fabric

architecture that are relevant to this work.

A Fabric network consists of peer nodes replicating the

blockchain and the world state, and a set of nodes called the

ordering service whose purpose is to order transactions into

blocks. The world state is a key-value view of the state created

by executing transactions. The nodes can belong to different

organizations collaborating on the same blockchain. Because

of the strict separation of concerns, Fabric’s blockchain model

is independent of the consensus algorithm in use. In fact,

release 1.4.1 supports three plug-in algorithms, solo, Kafka

and Raft, out of the box. As we will show in section V we

preserve Fabric’s modularity completely.

Apart from replication and ordering, Fabric needs a way

to execute its equivalent of smart contracts, called chaincode.

Endorsers, a subset of peers, fill this role. Each transaction

proposal received by an endorser is simulated in isolation. A

successful simulation of arbitrarily complex chaincode results

https://github.com/cgorenflo/fabric/tree/xox-1.4


in a read and write set (RW set) of {key, value, version}
tuples. They act as instructions for transitions of the world

state. The endorser then appends the RW set to the initial

proposal, signs the response, sends it back to the requesting

client, and discards the world state effect of the simulated

transaction before executing the next one.

To combat non-determinism and malicious behaviour during

chaincode execution, endorsement policies can be set up. For

example, a client may be required to collect identical responses

from three endorsers across two different organizations before

sending the transaction to the ordering service.

After transactions have been ordered into blocks, they are

disseminated to all peers in the network. These peers first

independently perform a syntactic validation of the blocks and

verify the endorsement policies. Lastly, they sequentially com-

pare each transaction’s RW set to the current view of the world

state. If the version number of any key in the set disagrees

with the world state, the transaction is discarded. Thus, any

RW set overlap across transactions in the same block leads to

an invalidation of all but the first conflicting transaction. As a

consequence of this execution model, Fabric’s blockchain also

contains invalid transactions, which every peer independently

flags as such during validation and ignores during commitment

to world state. In the worst case, all transactions in a block

might be invalid. This can drastically reduce the effective

transaction throughput of the system.

III. RELATED WORK

Performance is an important issue for blockchain systems

since they are still slower than traditional database systems [4],

[5]. While most research focuses on consensus algorithms, less

work has been done to optimize other aspects of the transaction

flow, especially transaction execution.

We base this work on FastFabric, our previous optimization

of Hyperledger Fabric [9]. We introduced efficient data struc-

tures, caching, and increased parallelization in the transaction

validation pipeline to increase Fabric’s throughput for conflict-

free transaction workloads by a factor six to seven. In this

paper, we address the issue of conflicting transactions.

To the best of our knowledge, a document from the Fabric

community [13] is the first to propose a secondary post-order

execution step for Fabric. However, the allowed commands

were restricted to addition, subtraction, and checking if a num-

ber is within a certain interval. Furthermore, this secondary

execution step is always triggered regardless of the workload,

and is not parallelized. This diminishes the value of retaining

the first pre-order execution step and introduces the same

bottleneck that OX models have to deal with.

Nasirifard et al [10] take this idea one step further. By

introducing conflict-free replicated data types (CRDTs), which

allow conflicting transactions to be merged during the valida-

tion step, they follow a similar path to our work. However,

their solution has several limitations. It can only process

transactions sequentially, one block at a time. When conflicts

are discovered, they use the inherent functionality of CRDTs to

resolve them. While this enables efficient computation, it also

restricts the kind of execution that can be done. For example,

it is not possible to check a condition like negative account

balance before merging two transaction results.

Amiri et al [2] introduce ParBlockchain using a similar ar-

chitecture to Fabric’s but with an OX model. Here, the ordering

service also generates a dependency graph of the transactions

in a block. Subsequently, transactions in the new block are

distributed to nodes in the network to be executed, taking the

dependencies into account. Only a subset of nodes executes

any given transaction and shares the result with the rest of

the network. This approach has two drawbacks. First, the

ordering service must determine the transaction dependencies

before they are executed. This requires the orderers to have

complete knowledge of all installed smart contracts, and, as a

result, restricts the complexity of allowed contracts. Even if a

single conditional statement relies on a state value, for example

Read the value of key k, where k is the value to be read

from key k′, reasoning about the result becomes impossible.

Second, depending on the workload, all nodes may have to

communicate the current world state after every transaction

execution to resolve execution deadlocks. This leads to a

significant networking overhead.

CAPER [1] extends ParBlockchain by modelling the

blockchain as a directed acyclic graph (DAG). This enables

sharding of transactions. Each shard maintains an internal

chain of transaction that is intertwined with a global cross-

shard chain. Both internal chains and the global chain are

totally ordered. This approach works well for scenarios with

tightly siloed data pockets that can easily be sharded and

where cross-shard transactions are rare. In this case, internal

transactions of different shards can be executed in parallel.

However, if the workload does not have clear boundaries to

separate the shards, then most transactions will use the global

chain, negating the benefit of CAPER.

Sharma et al [12] approach blockchains from a database

point of view and incorporate concepts such as early abort

and transaction reordering into Hyperledger Fabric. However,

they do not follow its modular design and closely couple the

different building blocks. For both early abort and transaction

reordering, the ordering service needs to understand transac-

tion contents to unpack and analyze RW sets. Furthermore,

transaction reordering only works in pathological cases. When-

ever a key appears both in the read and write set, which is

the case for any application that transfers any kind of asset,

reordering will not eliminate RW set conflicts. While early

transaction abort might increase overall throughput slightly,

it cannot solve the problem of hot keys and only skews the

transaction workload away from those keys.

Zhang et al [15] present a solution for a client-side early

abort mechanism for Fabric. They introduce a transaction

cache on the client that analyzes endorsed transactions to de-

tect RW set conflicts and only sends conflict-free transactions

to the ordering service. Transactions that have dependencies

are held in the cache until the conflict is resolved and then

they are sent back to the endorsers for re-execution. This

approach prevents invalid transactions from a single client, but



cannot deal with conflicts between multiple clients. Moreover,

it cannot deal with hot key workloads.

Lastly, Escobar et al [6] investigate parallel state machine

replication. They focus on efficient data structures to keep

track of parallelizable, i.e., independent state transitions. While

this might be interesting to incorporate into Fabric in the

future, we show in section VIII that the overhead of our

relatively simple implementation of a dependency tracker is

negligible compared to the transaction execution overhead.

IV. THE HOT KEY THEOREM

We now state and prove a theorem that limits the perfor-

mance of any XO system.

Hot Key Theorem. Let l be the average time between a

transaction’s execution and its state transition commitment.

Then the average effective throughput for all transactions

operating on the same key is at most 1

l
.

Proof. The proof is by induction. Let i denote the number of

changes to an arbitrary but fixed key k.

i = 0 (just before the first change):

For k to exist, there must be exactly one transaction tx0

which takes time l0 from execution to commitment and creates

k with version v1 at time t1.

i → i+ 1 (just before the i+ 1th change):

Let k’s current version be vi at time ti. Let txi be the

first transaction in a block which updates k to a new version

vi+1. The version of k during txi’s execution must have

been vi, otherwise Fabric would invalidate txi and prevent

commitment. Let txi be committed at time ti+1 and li be the

time between txi’s execution and commitment. Therefore,

ti ≤ ti+1 − li.

Likewise, no transaction tx′

i
which is ordered after txi can

commit an update vi → v′
i+1 because txi already changed the

state and tx′

i
would therefore be invalid. Consequently, txi

must be the only transaction able to update k from vi to a

newer version.

This means, N updates to k take tN time with

tN ≥

N−1∑

i=0

li.

A lower bound on the average update time is then given by

1

N
tN ≥

N−1∑

i=0

1

N
li = l,

so we get 1

l
as an upper bound on throughput being the inverse

of the update latency.

This theorem has a crucial consequence. For example,

FastFabric can achieve a nominal throughput of up to 20,000

transactions per second [9], yet even an unreasonably fast

transaction life cycle of 50ms from execution to commitment

would result in a maximum of 20 updates per second to the

same key, or once every ten blocks with a block size of 100

transactions. Worse yet, transactions are not only invalidated

if their RW set overlaps completely, but also if there is a

single key overlap with a previous transaction. This means that

workloads with hot keys can easily reduce effective throughput

by several orders of magnitude.

While early abort schemes can discard invalid transactions

before they become part of a block, they cannot break the

theorem. Assuming they result in blocks without invalid

transactions, they can only fill up the slots in a new block

with transactions using different key spaces. Thus, they skew

the processed transaction distribution. Furthermore, aborted

transactions need to be re-submitted and re-executed, flooding

the network with even more attempts to modify hot keys.

Eventually, endorsers will be completely saturated by clients

repeatedly trying to get their invalid transactions re-executed.

V. THE XOX HYBRID MODEL

To deal with the drawbacks of both the OX and XO patterns,

we now present the execute-order-execute (XOX) pattern which

adds a secondary post-order execution step to execute the

patch-up code added to smart contracts. XOX minimizes trans-

action conflicts while preserving concurrent block processing

and without the introduction of any centralized elements. In

this section, we first describe the necessary changes to the

endorsers’ pre-order execution step to allow the inclusion of

external oracles in the post-order execution step. Then, we

describe changes to the critical transaction flow path on the

peers after they receive blocks from the ordering service.

The details of the crucial steps we introduce are described

in sections VI and VII. Notably, our changes do not affect the

ordering service, preserving Fabric’s modular structure.

A. Pre-order endorser execution

The pre-order execution step leverages concurrent transac-

tion execution and uses general purpose programming lan-

guages like Go. Depending on the endorsement policy, clients

request multiple endorsers to execute their transaction and

the returned execution results must be identical. This makes

a deterministic execution environment unnecessary because

deviations are discarded and a unanimous result from all en-

dorsers becomes ground truth for the whole network. Notably,

this also allows external oracles like weather or financial data.

If these oracle data lead to non-deterministic RW sets, the

client will not receive identical endorser responses and the

transaction will never reach the Fabric network.

External oracles are a powerful tool. If they are supported

by the pre-order execution step, they must also be supported by

the post-order execution step. To achieve this, we must make

the oracle deterministic. We leverage the same mechanism

that ensures deterministic transaction results for pre-order

execution: We extend the transaction response by an additional

oracle set. Any external data are recorded in the form of key-

value pairs and are added to the response to the client. Now, if

the oracle sets for the same transaction executed by different

endorsers differ, the client has to discard the transaction.

Otherwise, the external data effectively becomes part of the



block verification

EP validation

dependency analyzer RW set validation re-execution

commitment

Fig. 1. The modified XOX Fabric validation and commitment pipeline. Stacks and branched paths show parallel execution.

deterministic world state so that it can be used without by

the post-order execution step. Analogous to existing calls to

GetState and PutState that record the read and write set

key-value pairs, respectively, we add a new call PutOracle

to the chaincode API.

B. Critical transaction flow path

Our previous work on FastFabric [9] showed how to im-

prove performance by pipelining the syntactic block verifica-

tion and endorsement policy validation (EP validation) so that

it can be done for multiple blocks at the same time. However,

the RW set validation to check for invalid state transitions

and the final commitment had to be done sequentially in a

single thread. While the the XOX model is an orthogonal

optimization, its second execution step needs to be placed

between RW set validation and commitment. Since this step

is relatively slow, we must expand our concurrency efforts

to pipelining RW set validation, post-order executions, and

commitment. Two vital pieces for this effort, a transaction de-

pendency analyzer and the executions step itself, are described

in later sections in detail, so we will only give a brief overview

here. This allows us to concentrate on the pipeline integration

in this section.

1) Dependency analyzer: For concurrent transaction pro-

cessing, we rely on the ability to isolate transactions from

each other. However, the sequential order of transactions in

a block matters when their RW sets are validated and they

are committed. A dependency exists when two transactions

overlap in some keys of their RW sets (read-only transactions

do not even enter the orderer). In that case, we cannot process

them independently. Therefore, we need to keep track of

dependencies between transactions so we know which subsets

of transactions can be processed concurrently.

2) Execution step: Transactions for which the dependency

analyzer has found a dependency on an earlier transaction

would be invalidated during Fabric’s RW set validation. We

introduce a step which re-executes transaction with such an

RW set conflict based on the most up-to-date world state. It

can resolve conflicts due to a lack of knowledge of concurrent

transactions during pre-order execution. However, it still inval-

idates transactions that attempt something the smart contract

does not allow, such as creating a negative account balance.

In FastFabric, peers receive blocks as fast as the ordering

service can deliver them. If the syntactic verification of a block

fails, the whole block is discarded. Thus, it is reasonable to

keep this as a first step in the pipeline. Next up is the EP

validation step. Each transaction can be validated in parallel

because the validations are independent of each other. The next

step is the intertwined RW set validation and commitment:

Each transaction is validated, and, if successful, added to an

update batch that is subsequently committed to the world state.

XOX Fabric separates RW set validation from the commit-

ment decision. Therefore, this step is no longer dependent on

the result of the EP validation and can be done in parallel.

However, in order to validate transactions concurrently, we

need to know their dependencies, so the dependency analyzer

goes first and releases transactions to the RW set validation as

their dependencies are resolved.

Subsequently, the results from the EP validation and RW set

validation are collected, and if they are marked as valid, they

can be committed concurrently. If a RW set conflict arises,

they need to be sent to the new execution step to be re-

executed based on the current world state. Finally, successfully

re-executed transactions are committed and all others are

discarded.

Our design allows dependency analysis to work in parallel

to endorsement policy validation and transactions can proceed

as soon as all previous dependencies are known. Specifically,

independent sets of transactions can pass through RW set

validation, post-order execution, and commitment steps con-

currently. The modified pipeline is shown in Fig. 1.

VI. DEPENDENCY ANALYZER

We now discuss the details of the dependency analyzer. Note

that the only way for a transaction to have a dependency on

another is an overlap in its RW set with a previous transaction.

More precisely, one of the conflicting transactions must write

to the overlapping key. Reads do not change the version nor

the value of a key, so they do not impede each other. However,

we must consider a write a blocking operation for that key.

If transaction a with a write is ordered before transaction b

with a read from the same key, then this must always happen

in this order lest we lose deterministic behaviour of the peer

because of the changing key value. The reverse case of read-

before-write has the same constraints. In the write-write case,

neither transaction actually relies on the version or the value

of that key. Nevertheless, they must remain in the same order,

otherwise transaction a’s value might win out, even though

transaction b should overwrite it.

To detect such conflicts, we keep track of read and write

accesses to all keys across transactions. For each key, we create

a doubly-linked skip list that acts as a dependency queue,

recording all transactions that need to access it. Entries in

this queue are sorted by the blockchain transaction order. As

described before, consecutive reads of the same key do not

affect each other and can be collapsed into a single node in



keyi−1

.

.

.

keyi

keyi+1

.

.

.

block:5 #tx:2

block:4 #tx:43

block:5 #tx:7

read

block:5 #tx:8

write

block:6 #tx:21

write

skip

¡ ¡ ¡

Fig. 2. Dependency analyzer data structure: Example of a state database key mapped to a doubly-linked skiplist of dependent transactions.

the linked list so they will be freed together. For faster traversal

during insertion, nodes can skip to the start of the next block

in the list. This data structure is illustrated in Fig. 2. After

the analysis of a transaction is complete, it will not continue

to the next step in the pipeline until all previous transactions

have also been analyzed, lest an existing dependency might

be missed.

Dependencies may change in two situations: when new

transactions are added or existing transactions have com-

pleted the commitment pipeline. In either case, we update

the dependency lists accordingly and check the first node

of lists that have been changed. If any of these transactions

have no dependency in any key anymore, they are released

into the validation pipeline. However, we can only remove

a transaction from the dependency lists once it is either

committed or discarded, lest dependent transactions get freed

up prematurely.

VII. POST-ORDER EXECUTION STEP

The post-order execution step executes additional patch-up

code added to a smart contract. We discuss it in more detail

in this section.

When the RW validation finds a conflict between a trans-

action’s RW set and the world state, that transaction will be

re-executed and possibly salvaged using the patch-up code.

However, the post-order execution stage needs to adhere to

some constraints. First, the new RW set must be a subset of the

original RW set so the dependency analyzer can reason prop-

erly. Without this restriction, new dependencies could emerge

and transactions scheduled for parallel processing would now

create an invalid world state. Second, the blockchain network

also needs consistency among peers. Therefore, the post-order

execution must be deterministic so there is no need for further

consensus between peers. Lastly, this new execution step is

part of the critical path and thus should be as fast as possible.

For easier adoption of smart contracts from other blockchain

systems, we use a modified version of Ethereum’s EVM [14]

as the re-execution engine for patch-up code3. Patch-up code

take a transaction’s read set and oracle set as input. The read

set is used to get the current key values from the latest version

of the world state. Based on this and the oracle set, the smart

contract then performs the necessary computations to generate

3We note that forays have been m";"""date"",""2020-03-11T00:33:55Z""
""pdf:PDFVersion"",""1.4""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.4""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""xmp:CreateDate"",""2020-03-10T20:33:55Z""
""modified"",""2020-03-11T00:33:55Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""xmp:ModifyDate"",""2020-03-10T20:33:55Z""
""pdf:docinfo:creator"",""""
""meta:author"",""""
""meta:creation-date"",""2020-03-11T00:33:55Z""
""created"",""2020-03-11T00:33:55Z""
""xmp:About"",""uuid:89ec8a14-9b4c-11f5-0000-353225a3f33a""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-03-11T00:33:55Z""
""resourceName"",""1906.11229""
""Author"",""""
""producer"",""dvips + GPL Ghostscript GIT PRERELEASE 9.22""
""pdf:docinfo:producer"",""dvips + GPL Ghostscript GIT PRERELEASE 9.22""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""2"",""0"",""0"",""2"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2020-03-11T00:33:55Z""
""Last-Modified"",""2020-03-11T00:33:55Z""
""dcterms:modified"",""2020-03-11T00:33:55Z""
""title"",""""
""xmpMM:DocumentID"",""uuid:89ec8a14-9b4c-11f5-0000-353225a3f33a""
""Last-Save-Date"",""2020-03-11T00:33:55Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2020-03-11T00:33:55Z""
""meta:save-date"",""2020-03-11T00:33:55Z""
""Content-Length"",""171426""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""9""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""4704"",""5115"",""5534"",""4648"",""4736"",""4525"",""4545"",""4136"",""2967""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-03-11T00:33:55Z""
";https://scholar.google.com/scholar?start=180&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095406-1732;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;[CITATION][C] BLOCKCHAIN: THE FUTURE OF TRADE FINANCE A LEGAL PERSPECTIVE;S REDZHEPOGLU, S READER, J MC CAHERY ;2020;;null;Autres articles;;null;;;;https://scholar.google.com/scholar?start=530&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095383-1631;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;[PDF][PDF] The Future of Cryptocurrency After the Pandemic;M Do?rul, C Korkut ; Reflections on the Pandemic  researchgate.net;;"… D'Alfonso, A., Langer, P., & Vandelis, Z.(2016). The Future of Cryptocurrency An Investor's

Comparison of Bitcoin and Ethereum … Evans, B.(2017). Microsoft, Oracle Jump Into Blockchain

On Same Day--And Microsoft Is Clear Leader. Forbes: https://www. forbes …";Autres articles;;[PDF] researchgate.net;https://www.researchgate.net/profile/Ahmet_Acar15/publication/345986716_Effects_of_Covid-19_Crisis_on_Employment_and_Working_Arrangements_Acar_A_C_Reflections_on_the_Pandemics_Muzaffer_SekerAli_OzerCem_Korkut_Editor_Turkiye_Bilimler_Akademisi_Ankara_ss463-488_2020/links/5fb71a09299bf104cf5f77f0/Effects-of-Covid-19-Crisis-on-Employment-and-Working-Arrangements-Acar-A-C-Reflections-on-the-Pandemics-Muzaffer-Seker-Ali-Oezer-Cem-Korkut-Editoer-Tuerkiye-Bilimler-Akademisi-Ankara-ss463-488-2.pdf#page=643;;;https://scholar.google.com/scholar?start=430&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095349-1476;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Time Portals, Love Machines, Land Oracles: Hybrid Geography and the Situated Digital;T Waterman ; Architectural Design, 2020  Wiley Online Library;;"… ORACLES … Paul Seidler, Paul Kolling and Max Hampshire, Terra0, 2016, shown in 'New World

Order', Furtherfield Gallery, London, 2017 Featured in an exhibition dedicated to exploring art

and the Blockchain, Terra0 is a prototype for a self-owning, self-exploiting forest which …";Autres articles;;null;;;;https://scholar.google.com/scholar?start=280&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095337-1426;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Distributed IoT Security using an Ethereum-based Blockchain Infrastructure;J Wickström ;2020 theseus.fi;;"… A distributed smart contract backend system designed for blockchain oracles. - An interpreter

that allows an IoT device to perform actions autonomously and to … Smart contracts:

https://github.com/wickstjo/oracle-manager IoT interpreter … 17 3.1 Blockchain Protocol 3.1.1 Ether …";Autres articles;Version HTML;[PDF] theseus.fi;https://www.theseus.fi/bitstream/handle/10024/354801/wickstjo-thesis-9.0.pdf?sequence=2;"
FĂśrnamn Efternamn 

 

Distributed IoT Security using an Ethereum-

based Blockchain Infrastructure 

  

John WickstrĂśm 

 

 

 

 

 

 

Degree Thesis 

Information Technology 

2020 



 

 

 
DEGREE THESIS 

Arcada  

 

Degree Programme:  Information Technology 

 

Identification number: 8065 

Author: John WickstrĂśm 

Title: Distributed IoT Security using an Ethereum-based Block-

chain Infrastructure 

Supervisor (Arcada): Magnus Westerlund, DSc 

 

Commissioned by:  

 

Abstract: 

  

 

The recent proliferation of Internet of Things (IoT) has emphasized a lack of security and 

privacy in the industry. Many of the vulnerabilities stem from irresponsible practices 

committed by manufacturers and consumers alike and require a drastic paradigm shift to 

correct. The focus of this thesis is to understand how the Ethereum platform and block-

chain technology can be utilized to bolster the security of the IoT sector. The proposed 

solution eliminates the need for trust by automating the workflow of devices through an 

interpreter that uses a distributed smart contract to determine its procedures. This form of 

indirect management allows a device to be hardened against internal threats by disallow-

ing all incoming connections which significantly reduces the number of attack vectors 

that can be used to undermine a device’s integrity. While this solution does intro-duce an 

unprecedented level of security to a technological sector that is in dire need of it, an in-

evitable consequence is an increased cost of use and latency. 

 

 

 

 

 

 

 

 

 

 

Keywords: Ethereum, Blockchain, Smart Contract, IoT, Internet of 

Things 

Number of pages: 44 

Language: English 

Date of acceptance:  

  



 

 

EXAMENSARBETE 

Arcada  

 

Utbildningsprogram:  Informationsteknik 

 

Identifikationsnummer: 8065 

FĂśrfattare: John WickstrĂśm 

Arbetets namn: Distribuerad IoT-säkerhet med en Ethereum-baserad infra-

struktur 

Handledare (Arcada): Magnus Westerlund, DSc 

 

Uppdragsgivare:  

 

Sammandrag:  

 

Den explosivt växande populariteten av sakernas internet (IoT) har framhävt en stor sä-

kerhetsbrist i teknologin. Büde konsumenter och tillverkare har i lünga tider använt sig 

av oansvarig praxis vilket tyder pü att mer drastiska ütgärder müste vidtas fÜr att korri-

gera det bakomliggande problemet. Syftet fÜr detta examensarbete är att fÜrstü hur Et-

hereum-plattformen och blockkedjeteknologi kunde tillämpas fÜr att fÜrstärka säkerhet-

en fĂśr IoT-sektorn. Ett resultat kan uppnĂĽs med automation av en apparats arbetsflĂśde 

via en mellanvara som styrs av ett distribuerat smart kontrakt. En sĂĽdan form av indirekt 

styrning tillüter ägaren att härda en apparat mot interna hot vilket drastiskt minskar pü 

mängden attackvektorer som kan användas fÜr att angripa apparaten. Medan den fÜr-

slagna lÜsningen definitivt kunde användas fÜr att infÜra en hÜg nivü av säkerhet till 

IoT-branschen sü är den dock ocksü dyrare och lüngsammare att driva. 

 

 

 

 

 

 

 

 

 

 

Nyckelord: Ethereum, Blockkedja, Smarta Kontrakt, IoT, Sakernas In-

ternet 

Sidantal: 44 

SprĂĽk: Engelska 

Datum fÜr godkännande:  

  



 

 

TABLE OF CONTENTS 

1 Introduction .......................................................................................................... 7 

1.1 Background ................................................................................................................... 7 

1.2 Objective ........................................................................................................................ 8 

1.3 Delimitation .................................................................................................................... 8 

2 General Concepts ................................................................................................ 9 

2.1 Transcoding ................................................................................................................... 9 

2.2 Hashing ......................................................................................................................... 9 

2.3 Encryption .................................................................................................................... 10 

2.3.1 Symmetric Encryption .......................................................................................... 10 

2.3.2 Asymmetric Encryption ........................................................................................ 10 

2.4 Network Governance ................................................................................................... 11 

2.5 Blockchain Technology ............................................................................................... 13 

2.5.1 Consensus Algorithms......................................................................................... 13 

2.5.2 Mining .................................................................................................................. 14 

2.5.3 Proof of Work ....................................................................................................... 14 

2.5.4 Proof of Stake ...................................................................................................... 15 

2.5.5 Forking ................................................................................................................. 15 

3 Ethereum ............................................................................................................ 16 

3.1 Blockchain Protocol ..................................................................................................... 17 

3.1.1 Ether .................................................................................................................... 17 

3.1.2 Accounts .............................................................................................................. 17 

3.1.3 Ethereum Virtual Machine ................................................................................... 18 

3.1.4 Smart Contracts ................................................................................................... 18 

3.1.5 Global Namespace .............................................................................................. 19 

3.1.6 Transactions and Gas Consumption ................................................................... 20 

3.1.7 Networks .............................................................................................................. 20 

3.1.8 Synchronization and Gateways ........................................................................... 21 

3.2 Whisper Protocol ......................................................................................................... 22 

3.2.1 Darkness ............................................................................................................. 22 

3.2.2 Time to Live ......................................................................................................... 23 

3.2.3 Denial-of-Service Attacks .................................................................................... 24 

4 Smart Contract Design Patterns ....................................................................... 24 

4.1 Oracles ........................................................................................................................ 25 

4.1.1 Event Loop .......................................................................................................... 25 

4.1.2 Vulnerabilities ...................................................................................................... 26 



 

 

4.2 Tokenization ................................................................................................................ 26 

4.2.1 ERC standards .................................................................................................... 27 

4.2.2 Initial coin offering ................................................................................................ 28 

5 Internet of Things .............................................................................................. 28 

5.1 Vulnerabilities .............................................................................................................. 28 

5.2 Device Hardening ........................................................................................................ 29 

5.3 Revenue Streams ........................................................................................................ 30 

5.4 Projected Future .......................................................................................................... 30 

6 Implementation .................................................................................................. 31 

6.1 Component Overview .................................................................................................. 32 

6.2 Development Tools...................................................................................................... 32 

6.2.1 NodeJS ................................................................................................................ 32 

6.2.2 Python.................................................................................................................. 33 

6.2.3 Geth ..................................................................................................................... 33 

6.3 Smart Contract Backend ............................................................................................. 33 

6.3.1 User Manager ...................................................................................................... 35 

6.3.2 Oracle Manager ................................................................................................... 35 

6.3.3 Task Manager ...................................................................................................... 37 

6.3.4 Token Manager ................................................................................................... 39 

6.4 Middleware .................................................................................................................. 40 

6.4.1 Configuration ....................................................................................................... 40 

6.4.2 Service Discovery ................................................................................................ 41 

6.4.3 Oracle Client ........................................................................................................ 41 

6.5 Frontend Application.................................................................................................... 43 

6.5.1 React Framework ................................................................................................ 43 

6.5.2 Distributed Applications ....................................................................................... 43 

7 Conclusion ......................................................................................................... 44 

References ................................................................................................................ 45 

Appendix 1 Swedish Summary ................................................................................ 49 

 

  



 

 

TABLE OF FIGURES 

Figure 1: Transcoding a JSON object with the base64 algorithm. ................................... 9 

Figure 2: Hashing a JSON object with the SHA256 algorithm. ....................................... 9 

Figure 3: Users A and B asymmetrically encrypt and decrypt a file. ............................. 11 

Figure 4: Centralized, decentralized, and distributed networks visualized. ................... 12 

Figure 5: A blockchain is forked to version 2.0 at block number 6. .............................. 16 

Figure 6: An Ethereum accounts mnemonic seed. ......................................................... 18 

Figure 7: An IoT device interacting with the blockchain via a gateway. ....................... 21 

Figure 8: A Whisper network with zero and complete darkness, respectively. ............. 23 

Figure 9: A smart contract oracle’s action sequence. ..................................................... 26 

Figure 10: The proof-of-concept project visualized. ...................................................... 31 

Figure 11: The variables and methods of the smart contract backend system. .............. 34 

Figure 12: The owner updates an oracle’s configuration. .............................................. 37 

Figure 13: The sequence of events when a user creates a new task. .............................. 38 

Figure 14: The incoming and outgoing dataflow of the oracle middleware. ................. 40 

Figure 15: A task’s complete life cycle. ......................................................................... 42 

 

  



7 

 

1 INTRODUCTION 

1.1 Background 

The conceptual idea of a fully electronic currency has existed since the 1990s, but all 

practical implementation attempts had very limited success and ended abruptly. Howev-

er, in 2008 a person (or more likely a group of people) who remains unidentified but 

went by the pseudonym Satoshi Nakamoto published a whitepaper that claimed to have 

solved the issue of trust in a trustless system via cryptography (Nakamoto, 2008). What 

the paper detailed was the mechanics of the Bitcoin blockchain that started rapidly gain-

ing traction. By the end of 2017, the price of one Bitcoin reached over 18000 USD after 

which the market suddenly crashed, and the price would drop by more than 500% with-

in the next six months. Many perceived this as irrefutable evidence that cryptocurren-

cies are inherently flawed, even though the causality for the crash was consumerism ra-

ther than an algorithmic failure in the underlying technology. 

 

Since Bitcoin’s inception, a multitude of different blockchains have emerged that intend 

to solve prominent issues like computation, storage, and direct messaging in a distribut-

ed environment by utilizing Nakamoto’s consensus model. A prime example of this is 

the Ethereum blockchain that allows snippets of code (later named smart contracts) to 

be run on a decentralized virtual machine (Buterin, 2014). Applications that exclusively 

use decentralized components are referred to as decentralized applications (dApps) and 

symbolize how the third incarnation of the web could function. 

 

The recent rise in popularity of Internet of Things (IoT) has been explosive and shows 

no signs of stagnation. Unfortunately, online services like Shodan (Shodan.io, 2013) 

that find vulnerable devices by scouring the Internet for open network ports prove that a 

shocking amount of IoT devices are insecure and can easily be tampered with. While 

some government-mandated standardization research has been started to mend this is-

sue, these cogs turn very slowly and the burden to resolve security and privacy flaws in 

the short-term falls on the shoulders of the consumer. 



8 

 

1.2 Objective 

The objective of this thesis is to explore the Ethereum platform and its protocols to un-

derstand how they can be leveraged to increase the security and privacy of the IoT sec-

tor. After a thorough exploration of key concepts, the discussed principles will be show-

cased in a practical setting by detailing the architecture of the following components: 

 

- A distributed smart contract backend system designed for blockchain oracles. 

- An interpreter that allows an IoT device to perform actions autonomously and to 

be managed indirectly through a smart contract. 

- A service discovery system for IoT devices that utilizes the Ethereum platform’s 

Whisper protocol. 

- A user-friendly client to customize a smart contract oracle’s objective. 

- A web-application that streamlines the usage of the smart contract backend. 

 

Each of these components are part of a larger system that will be discussed on a rela-

tively high level in section 6. The detailed source-code can be viewed from the respec-

tive components GitHub repository: 

 

Smart contracts: https://github.com/wickstjo/oracle-manager 

IoT interpreter: https://github.com/wickstjo/iot-manager 

Web-application: https://github.com/wickstjo/distributed-task-manager 

1.3 Delimitation 

This is first and foremost an exploration of the Ethereum platform and its protocols, so 

other platforms and blockchains, however similar, will not be explored. Because 

Ethereum’s 2.0 (Ethereum Foundation, 2020) version is in its very early stages, only 

features exclusive to the 1.x versions will be used. Smart contracts will be written in the 

Solidity programming language (docs.soliditylang.org, 2020) and utilized in a JavaS-

cript and Python environment. The IoT device that is used for the practical implementa-

tion is a Raspberry Pi 2B (Raspberry Pi Foundation, 2019) microcontroller. 

  

https://github.com/wickstjo/oracle-manager
https://github.com/wickstjo/iot-manager
https://github.com/wickstjo/distributed-task-manager


9 

 

2 GENERAL CONCEPTS 

2.1 Transcoding 

A transcoder is an algorithm that can convert one type of data into another without los-

ing its structural integrity. This technique is often used in complex applications that 

consist of multiple different codebases that pass incompatible data between modules. 

The transcoding process is often referred to as encoding, while the reversal of the effect 

is referred to as decoding. 

 

 

Figure 1: Transcoding a JSON object with the base64 algorithm. 

 

Generally transcoded data loses a small segment of the original content due to compres-

sion, but there are plenty of algorithms that allow for lossless transcoding at the cost of 

efficiency. In the implementation section of this thesis, we will be utilizing a base64 

transcoder to pass lossless JSON data between submodules and the blockchain as pre-

sented in Figure 1. 

2.2 Hashing 

Hashing refers to an action where an arbitrary amount of data is put through a specific 

algorithm to convert it to an indecipherable string of fixed length. Unless the hash algo-

rithm is cracked and reverse-engineered, there is no way (other than guessing) to recon-

struct the data that was used to generate a specific hash. 

 

 

Figure 2: Hashing a JSON object with the SHA256 algorithm. 

 



10 

 

This is an extremely powerful tool in programming because you can snapshot the con-

tent of anything from simple data structures to huge programs and condense them down 

to a virtual fingerprint. These fingerprints that are also known as checksums are only a 

few bytes long but can be fully relied upon to verify that the source material has not 

been tampered with in any way. In the implementation section of this thesis, both index-

ing and verification procedures use hashing as presented in Figure 2. 

2.3 Encryption 

Encryption, much like hashing, starts from data being sent into a specific algorithm to 

be turned into an undecipherable string. However, encrypted data has the unique capa-

bility of reverting itself to its original state if the correct key (or keys) are first provided. 

The two main types of encryption are symmetric and asymmetric. 

2.3.1 Symmetric Encryption 

For symmetric encryption, the same key is used to encrypt and decrypt a file. This is the 

preferred encryption type for files that are distributed to multiple users simultaneously 

but do not contain information that is sensitive enough to warrant the added complexity 

of asymmetric encryption. 

2.3.2 Asymmetric Encryption 

For asymmetric encryption, two different sets of public and private keypairs are used in 

conjunction to encrypt and decrypt a file. In the scenario that is depicted in Figure 3, 

user A uses their private key and user B’s public key to encrypt a file. After receiving 

the encrypted file, user B would use their private key and user A’s public key to decrypt 

and read the file. Note that under no circumstances should two users ever exchange pri-

vate keys. 



11 

 

 

Figure 3: Users A and B asymmetrically encrypt and decrypt a file. 

 

Depending on the asymmetric encryption algorithm, keypairs can either be generated 

for each subsequent encryption on the spot or fetched from a publicly available database 

like Pretty Good Privacy (Garfinkel, 1995) for continuous use of the same keypair. The 

first method provides a higher level of security because a compromised keypair can on-

ly be used to decrypt a single file, but requires users to manage a potentially infinite 

number of keypairs. The second method delegates keypair management to a third party, 

but a compromised keypair would mean that all the files associated with it can be de-

crypted. 

2.4 Network Governance 

There are typically considered to be three categories of network governance: central-

ized, decentralized, and distributed (see Figure 4). None of them are fundamentally su-

perior to the others because they promote and value entirely different things and there-

fore suit different scenarios. A system or network is not bound to only one type of gov-

ernance and often thrives by utilizing a combination of two or even three at once. (Ngu-

yen et al. 2016) 

 



12 

 

 

Figure 4: Centralized, decentralized, and distributed networks visualized. 

 

The key component of a centralized network is the central authority (a central point of 

failure) and a disproportionally large number of nodes connected to it. A prime example 

of this would be a typical internet service provider as the central authority with its clien-

tele as the connected nodes. 

 

In a distributed network, every node is interchangeable because they all either contain 

the same data or can collectively reconstruct the same data by borrowing missing blocks 

from neighboring nodes. It can be argued that this category of governance is the only 

one that can truly be called democratic because there is no central authority that controls 

any part of its content or mandates how it should be operated. 

 

A decentralized network is a subset of a distributed network where no single node has 

absolute authority over the others, but there is a significant disparity in node connectivi-

ty and size. In other words, it is a hybrid governance model that is used by large compa-

nies all over the world. It would be unimaginable, likely even impossible, for a compa-

ny like Amazon with clients and partners all over the world to be run in a fully central-

ized fashion. Instead, there are multiple servers that clients can connect to that all serve 

more or less the same content. If one of the servers were to fall, the clients would be 

forwarded to another server. Regardless, Amazon is still the central authority of the 

network and can control its content, hence the hybrid categorization. 



13 

 

2.5 Blockchain Technology 

A blockchain is a continuously growing database of transaction records that are stored 

in chronologically ordered blocks which are interlinked by cryptography. Every subse-

quent block post genesis contains at the very least: 

 

1. Its own subset of transactions. 

2. A unique hash (block hash) that is derived from its transactions. 

3. A block hash reference to its predecessor to establish an ordered hierarchy. 

 

Because of this, a blockchain is considered to be immutable because retroactive modifi-

cation of any block in the ordered hierarchy also requires the modification of every sub-

sequent block after it. The number of blocks grows linearly over time based on a static 

hash rate, which means that a blockchain becomes more robust and difficult to break 

with maturity. (Zheng et al. 2017) 

 

A blockchain is managed by a peer-to-peer network where every node has access to the 

entire transaction history and can therefore trace every unit of currency back to its in-

ception. This type of network is often referred to as a distributed ledger. One of the pri-

mary problems for such a network is to establish computational consensus among 

nodes, a rule of law if you will. Nakamoto (2008) proposed that this problem could be 

solved by a so-called consensus algorithm. 

2.5.1 Consensus Algorithms 

A consensus algorithm allows a blockchain to be managed by a distributed network of 

inherently untrustworthy peers by dictating their conduct. There are several different 

algorithms that build on fundamentally different principles and assumptions about hu-

man behavior, but since this thesis focuses on the Ethereum blockchain, only the Proof 

of Work (PoW) and Proof of Stake (PoS) algorithms which are relevant to it will be dis-

cussed. A blockchain cannot adhere to multiple consensus algorithms simultaneously 

but can transition from using one to another. 



14 

 

2.5.2 Mining 

Transactions are not arbitrarily appended to a block and must first be validated by a 

special type of network peer that is called a miner. The computation that is necessary for 

this validation process is referred to as mining and its methodology is dictated by the 

blockchains consensus algorithm. A majority of network nodes must approve the validi-

ty of a mined transaction. If the network nodes approve, the miner is rewarded with 

newly created cryptocurrency and the transaction will be appended to the next block. 

Mining is done completely voluntarily, so every node does not have to be a miner, but 

every miner has to be a node. 

2.5.3 Proof of Work 

When a blockchain is managed by a Proof of Work (PoW) consensus algorithm, the 

miners compete against each other to solve a computational puzzle to create new blocks. 

To solve the puzzle, a miner must first guess a pseudo-random number that is referred to 

as a “nonce”. The generated nonce and the blocks transactions are then simultaneously 

passed through a hash function to produce a “block hash”. This process is repeated until 

the block hash meets the blockchains PoW complexity requirement. (Gervais et al. 

2016) 

 

When a miner finds a nonce that can be used to produce a sufficiently complex block 

hash, they publish it to the network where the other nodes check its validity by hashing 

the block’s transactions with the provided nonce themselves. If the validating nodes ac-

cept the result, the miner is rewarded and a new block that contains these parameters 

will be appended to the chain. Note that to find a nonce that produces a sufficient block 

hash is the labor-intensive part of the problem, while the verification of it is trivial in 

comparison. 

 

According to Cambridge Centre for Alternative Finance (cbeci.org, 2020), the cumula-

tive energy consumption of every Bitcoin (PoW) miner is equivalent to a small country 

and only a fraction of the computation is truly necessary. PoW has been computational-

ly proven to be reliable which is why most of the highest valued blockchains use it, but 

the environmental consequences might lead to its eventual downfall. 



15 

 

2.5.4 Proof of Stake 

With a Proof of Stake (PoS) consensus algorithm, miners (called validators) are no 

longer required to solve a computational puzzle and instead only validate the transac-

tions of a block and stake currency as a guarantee of their validity. Validators are cho-

sen through a pseudorandom election process based on different factors and characteris-

tics. The reward for validating a block is equal to the fees of its containing transactions. 

(Li et al. 2017) 

 

For a node to become a validator, it must first stake a minimum amount of currency that 

the network seizes. When the PoS algorithm chooses a validator, it can take into consid-

eration the quantity, weight, and age of a node’s staked assets. An asset’s weight is de-

termined by how long the owner is willing to forfeit it for, while its age refers to how 

long it has been since the owner was last selected for validation. To prevent wealthy 

nodes from perpetually being selected, some randomized factors are also taken into con-

sideration by the algorithm. A node’s accumulated rewards are added to the initial stake 

and will remain seized by the network until the node wants to stop validating transac-

tions and the forfeit duration has expired. 

 

Validated blocks still have to be approved by the majority of the network’s nodes. If a 

validating node approves transactions that the rest of the network considers to be inva-

lid, then the node is immediately punished by destroying a part of its staked assets and 

disqualifying it from being chosen to become a validator again. For as long as a node’s 

staked assets are larger than the reward for a block, there is an incentive for the node to 

conduct itself truthfully. 

2.5.5 Forking 

A blockchain is an extremely complex ecosystem requiring updates and modifications 

from time to time. This can be due to an exploit being found that needs to be subse-

quently patched or because the development team has scheduled the implementation of 

a specific feature far into the future. However, because of the distributed nature of 

blockchains, not even the creators have the ability to force a change onto the existing 

node network. To deploy a change, an entirely new blockchain must be formed in a pro-



16 

 

cess called forking. A forked blockchain contains a carbon copy of the original’s trans-

action history, so any currency or content that existed on the former will also exist on 

the latter. Figure 5 shows a blockchain fork at block number six. 

 

 

Figure 5: A blockchain is forked to version 2.0 at block number 6. 

 

Forks can be categorized as soft or hard depending on their cross-compatibility with the 

original. A soft fork occurs when the included update is small, and users with different 

forks can still interact with each other. A hard fork occurs when a foundational modifi-

cation is included, and the two networks cannot be used interchangeably. Note that there 

is no forceful transitioning of nodes and anyone who wants to keep using an older fork 

is free to do so. The only thing that gives a blockchain any kind of market value is its 

users’ trust in the integrity of the system. 

3 ETHEREUM 

After a successful crowdfunding campaign, the Ethereum platform went live in July of 

2015. Initially, it only had the blockchain protocol (Buterin, 2014), but over time the 

Whisper and Swarm protocols have been added that intend to solve completely different 

problems in the distributed ecosystem and pave the way for the third incarnation of the 

web. The Whisper protocol (Ethereum Wiki, 2020) functions very similarly to the mes-

sage queuing telemetry transport protocol (Shinde et al. 2016) and is intended for short, 

encrypted peer-to-peer messaging. The Swarm protocol (TrĂłn et al. 2020) deals entirely 

with distributed storage and functions as a content delivery network (CDN) that is remi-

niscent of the BitTorrent protocol. (Pouwelse et al. 2005) 

 

Since the Swarm protocol is still in very early development on the Ropsten test network, 

this thesis will only discuss and utilize Ethereum’s blockchain and Whisper protocols. 



17 

 

3.1 Blockchain Protocol 

3.1.1 Ether 

The Ethereum blockchains cryptocurrency is called Ether and has seven different de-

nominations of which the smallest is called a Wei and represents 1e-18 Ether. This cur-

rency can be traded for traditional commerce and services, but also as payment for a 

special mining reward called gas that can be increased to prioritize a transaction’s in-

corporation to the next block. 

3.1.2 Accounts 

Reading data from the blockchain can be done anonymously, but to write new data or 

modify existing data through either conventional currency trading or a smart contract 

interaction requires an Ethereum account. This unique account consists of a pub-

lic/private keypair that is used to authorize transactions. A user’s public key will be at-

tached to every transaction they make and is safe to be shared with other users, but the 

private key should under no circumstances be shared with anyone else. 

 

Humans are notoriously bad at remembering long randomized alphanumeric strings like 

encryption keys, so to alleviate this problem, accounts are commonly created by using a 

mnemonic seed. A mnemonic seed, as depicted in Figure 6, is ";"""date"",""2020-12-17T13:36:37Z""
""pdf:PDFVersion"",""1.7""
""xmp:CreatorTool"",""MicrosoftÂŽ Word for Microsoft 365""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""Examensarbete / Degree Thesis""
""language"",""en""
""dc:format"",""application/pdf; version=1.7""
""pdf:docinfo:creator_tool"",""MicrosoftÂŽ Word for Microsoft 365""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""xmp:CreateDate"",""2020-12-17T15:36:37Z""
""modified"",""2020-12-17T13:36:37Z""
""cp:subject"",""Examensarbete / Degree Thesis""
""pdf:docinfo:subject"",""Examensarbete / Degree Thesis""
""pdf:hasMarkedContent"",""true""
""xmp:ModifyDate"",""2020-12-17T15:36:37Z""
""pdf:docinfo:creator"",""wickstjo""
""meta:author"",""wickstjo""
""meta:creation-date"",""2020-12-17T13:36:37Z""
""created"",""2020-12-17T13:36:37Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-12-17T13:36:37Z""
""resourceName"",""wickstjo-thesis-9.0.pdf""
""Author"",""wickstjo""
""producer"",""MicrosoftÂŽ Word for Microsoft 365""
""pdf:docinfo:producer"",""MicrosoftÂŽ Word for Microsoft 365""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""dc:description"",""Examensarbete / Degree Thesis""
""access_permission:modify_annotations"",""true""
""dc:creator"",""wickstjo""
""description"",""Examensarbete / Degree Thesis""
""dcterms:created"",""2020-12-17T13:36:37Z""
""Last-Modified"",""2020-12-17T13:36:37Z""
""dcterms:modified"",""2020-12-17T13:36:37Z""
""xmpMM:DocumentID"",""uuid:C0D2666B-2F7F-406C-8840-02C5F6CE76F1""
""Last-Save-Date"",""2020-12-17T13:36:37Z""
""pdf:docinfo:modified"",""2020-12-17T13:36:37Z""
""meta:save-date"",""2020-12-17T13:36:37Z""
""Content-Length"",""719880""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""wickstjo""
""dc:language"",""en-FI""
""pdf:producer"",""MicrosoftÂŽ Word for Microsoft 365""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""54""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""159"",""1464"",""1358"",""4435"",""3658"",""1550"",""2118"",""1842"",""1253"",""1659"",""1163"",""1578"",""1884"",""2146"",""2224"",""1836"",""1504"",""1662"",""2246"",""2244"",""1742"",""2191"",""1272"",""1851"",""1572"",""1270"",""2214"",""1949"",""2430"",""2319"",""1358"",""1761"",""1755"",""996"",""1984"",""1935"",""1339"",""1414"",""2149"",""1566"",""1959"",""1056"",""1958"",""2266"",""1688"",""1839"",""1782"",""129"",""2119"",""2478"",""2296"",""2443"",""1399"",""1283""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-12-17T13:36:37Z""
";https://scholar.google.com/scholar?start=230&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095297-1257;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;[HTML][HTML] Blockchain technology for agriculture: applications and rationale;H Xiong, T Dalhaus, P Wang, J Huang ; frontiers in Blockchain, 2020  frontiersin.org;Switzerland;"… by farm machinery, can be automatically integrated via a smart oracle improving basis … Smart

contracts that integrate external data using smart oracles have already been proven … to smallholder

farmers in Ghana, simulated the application of an Ethereum blockchain-based smart …";Cité 26 fois;Les 7 versions;[HTML] frontiersin.org;https://www.frontiersin.org/articles/10.3389/fbloc.2020.00007/full?utm_source=S-TWT&utm_medium=SNET&utm_campaign=ECO_FBLOC_XXXXXXXX_auto-dlvrit;"
    
    
        
    

    

        

        

    


    

    

    
        



            
            
                
                    Your research can change the world
More on impact ›

                

            

        

    
        	
                        
                            
                                Frontiers in Blockchain
                            
                        

                    	
                            
                                
                                    Blockchain for Good


                                
                            

                        




        
     





    
    
        
            
                
                    
                        
                        
                            Toggle navigation
                            
                                
                                
                                
                            
                            Section
                        
                        
                        
                            	
                                    (current)Section
                                
	
                                    About
                                
	
                                    Articles
                                
	
                                    Research topics
                                
	
                                    For authors 
                                    	Why submit?
	Fees
	Article types
	Author guidelines
	Review guidelines
	Submission checklist
	Contact editorial office
	Submit your manuscript


                                
	
                                    Editorial board
                                


                        

                        	
                                
                                    
                                
                            
	
                                
                                    
                                
                            
	
                                
                                    Article alerts
                                
                            



                    
                

            

        

    







    
        
            
                    
                        
                            
                                
                                    This article is part of the Research Topic
                                

                                
                                   
                                        Blockchain for Food and Agriculture
                                        
                                            View all

                                                    4
                                                
                                            Articles 
                                        

                                   
                                

                            

                        
                    

            

            
                
                     Articles
                
            
        

    






    
                
                    Edited by

                    
                        [image:  ]
                        Xiaonan Wang

                    
                    

                    National University of Singapore, Singapore

                
                
                     Reviewed by

                            
                                [image:  ]
                                Carlos Santiso

                            
                            

                        Inter-American Development Bank, United States

                            
                                [image:  ]
                                Jon Crowcroft

                            
                            

                        University of Cambridge, United Kingdom

                    The editor and reviewers' affiliations are the latest provided on their Loop research profiles and may not reflect their situation at the time of review.

                
    

    
            TABLE OF CONTENTS

            	
	Abstract
	Introduction
	Applications
	Limitations
	Author Contributions
	Conflict of Interest
	Footnotes
	References


                


    




    
            
                [image: ]


Suggest a Research Topic >

            

        

            

        
            
        
    
        
    
        
            	
                        
                            
                            Download Article
                        
                        	
                                    
                                        Download PDF
                                    
                                
	
                                    
                                        ReadCube
                                    
                                
	
                                    
                                        EPUB
                                    
                                
	
                                    
                                        XML (NLM)
                                    
                                
	

                                        
                                            Supplementary
                                            

                                            Material
                                        

                                


                    
	
                    
                        
                        Export citation
                    
                    	
                                
                                    EndNote
                                
                            
	
                                
                                    Reference Manager
                                
                            
	
                                
                                    Simple TEXT file
                                
                            
	
                                
                                    BibTex
                                
                            


                


        

            
            	
                    
                    total views
                
	
                    
                        

                    

                


                
                     View Article Impact
                
        

            
            [image: ]


Suggest a Research Topic >

        

    
        SHARE ON

        	
                
                    
                

                
            
	
                
                    
                

                
            
	
                
                    
                

                
            
	
                
                    
                

                
            


    




            

    
        
            
                
                
                    
                        
                        
                        [image: ]
                        
                            
                            
                        

                                       

                        
                                
                                    MINI REVIEW article
                                

                        

                
                    Front. Blockchain, 21 February 2020
                             | https://doi.org/10.3389/fbloc.2020.00007
                

                

                

[bookmark: h1]Blockchain Technology for Agriculture: Applications and Rationale


[image: ]Hang Xiong1*, [image: ]Tobias Dalhaus2, [image: ]Puqing Wang3 and [image: ]Jiajin Huang4,5

	1Macro Agriculture Research Institute, College of Economics and Management, Huazhong Agricultural University, Wuhan, China
	2Agricultural Economics and Policy Group, ETH ZĂźrich, Zurich, Switzerland
	3College of Economics and Management, Wuhan Polytechnic University, Wuhan, China
	4The Development Research Center of Shanghai Municipal People’s Government, Shanghai, China
	5School of Economics, Fudan University, Shanghai, China


The blockchain is a ledger of accounts and transactions that are written and stored by all participants. It promises a reliable source of truth about the state of farms, inventories and contracts in agriculture, where the collection of such information is often incredibly costly. The blockchain technology can track the provenance of food and thus helps create trustworthy food supply chains and build trust between producers and consumers. As a trusted way of storing data, it facilitates the use of data-driven technologies to make farming smarter. In addition, jointly used with smart contracts, it allows timely payments between stakeholders that can be triggered by data changes appearing in the blockchain This article examines the applications of blockchain technology in food supply chains, agricultural insurance, smart farming, transactions of agricultural products for both theoretical and practical perspectives. We also discuss the challenges of recording transactions made by smallholder farmers and creating the ecosystem for utilizing the blockchain technology in the food and agriculture sector.






[bookmark: h2]Introduction

The use of data and information becomes increasingly crucial for the agriculture sector to improve productivity and sustainability. Information and Communication Technology (ICT) substantially increases the effectiveness and efficiency of collecting, storing, analyzing and using data in agriculture (Walter et al., 2017). It allows agricultural practitioners and farming communities to easily obtain update-to-date information and thus make better decisions in their daily farming (Kaddu and Haumba, 2016). For example, remotely sensed data on soil conditions can support farmers’ crop management (Brown, 2015), mobile phones reduce information cost and thus promote farmers’ access to markets and financial support (Kaske et al., 2018), and the development of Global Positioning System (GPS) facilitates filed mapping and machinery guidance and crop scouting (Yousefi and Razdari, 2015).

From ICT to Blockchain

Information and Communication Technology does not avoid bias in the collection and use of data. Individuals operating ICT always are motivated to use data in a way that favors their own interest. For example, stakeholders’ preference in a multi-criteria decision is highly influenced by the organization they represent (Collier et al., 2014) and NGOs can have a disproportionate focus on the issues to address due to its interest (Ngo Monitor, 2015). An effective way of avoiding such bias is to make data manipulation difficult or even impossible by distributing the power of data management to a very large number of individuals.

A blockchain is a ledger in which agents take turns recording information on the process of generating, transacting and consuming a product or service. The ledger is collectively managed by all participating parties typically through a peer-to-peer network. A new record must be verified by the network before adding it to the blockchain. Any alteration to the recorded data should follow consensus decision-making protocol, meaning the majority of the parties involved should agree. In addition, an alteration to one record will lead to the alteration of all its subsequent records. It is, therefore, almost impossible to change in data recorded in a blockchain in practice. Blockchain is viewed as “an open, distributed ledger that can record transactions between two parties efficiently and in a verifiable and permanent way” (Iansiti and Lakhani, 2017). Blockchain is a transformative ICT that have the potential to revolutionized how data is used for agriculture.

Potential Blockchain Technology Benefits for Agriculture

The blockchain technology allows peer-to-peer transactions to take place transparently and without the need for an intermediary like a bank (such as for cryptocurrencies) or a middleman in the agriculture sector. By eliminating the need for a central authority, the technology changes the way that trust is granted – instead of trusting an authority, trust is placed in cryptography and peer-to-peer architecture. It thus helps restore the trust between producers and consumers, which can reduce the transaction costs in the agri-food market.

The blockchain technology offers a reliable approach of tracing transactions between anonymous participants. Fraud and malfunctions can thus be detected quickly. Moreover, problems can be reported in real-time by incorporating smart contracts (Haveson et al., 2017; Sylvester, 2019). This helps address the challenge of tracking products in the wide-reaching supply chain due to the complexity of the agri-food system. The technology thus provides solutions to issues of food quality and safety, which are highly concerned by consumers, government, etc.

The blockchain technology provides transparency among all involved parties and facilitates the collection of reliable data. Blockchain can record every step in a product’s value chain, ranging a product’s creation to its death. The reliable data of the farming process are highly valuable for developing data-driven facilities and insurance solutions for making farming smarter and less vulnerable.

This article reviews applications of the blockchain technology in the agriculture and food sector.

[bookmark: h3]Applications

In this section, we discuss four classes of applications in agricultural and food sectors: agricultural insurance, smart farming, food supply chain, and transactions of agricultural products.

Agricultural Insurance

Weather extremes threaten agricultural production, putting food security at risk (Lesk et al., 2016). Both, crop and livestock production are affected, and climate change is expected to further exacerbate weather extremes in the future (Lobell et al., 2011; Finger et al., 2018). Agricultural insurance schemes are traditionally a well-recognized tool to manage weather related risks. Here, farmers pay an insurance premium before the cropping cycle begins and receive an insurance payout whenever they experience a loss on their farm. Thus, the insurer bears all the insured risk and farmers are able to manage their financial exposure to weather extremes, i.e., financial losses caused by weather extremes. In addition, in case of weather threats that systemically affect all the insured farmers, the insurer can further hedge the systemic part of the risk with a reinsurance company (Miranda and Glauber, 1997).

Agricultural insurances differ with respect to how losses are assessed and consequently how payouts are triggered. Insurances that indemnify farmers based on a damage assessment that was made by an expert on the farm are denoted as indemnity-based insurances. Indemnity based insurances are able to precisely cover losses, however, they are prone to problems arising from asymmetric information problems (Just et al., 1999). More specifically, information on the riskiness of the agricultural production and production practices is asymmetrically distributed between farmer and insurer. Farmers are expected to be better informed about both which incentivizes adverse selection and moral hazard. The adverse selection indicates that farmers with a higher ex ante risk exposure are more likely to purchase insurance compared to farmers with lower risk. Moral hazard indicates that farmers shift to more risky production practices when being insured. Both phenomena lead to market failure of the insurance scheme if the insurer has insufficient information on the two cases. Thus, indemnity-based insurances are prone to costly damage assessment and need to implement measures to avoid problems arising from asymmetric information, such as deductibles. Moreover, productions that cannot be measured, e.g., grazed meadows, cannot be insured although leading to financial damage (Vroege et al., 2019).

Motivated by the drawbacks of indemnity-based insurances, the idea of index-based insurances was born either as an alternative or complement to the classical products (Turvey, 2001). Here the payout is not triggered by the loss itself but by a measurable index, such as rainfall at a nearby weather station (Barnett and Mahul, 2007; Barnett et al., 2008). If this weather station has sufficiently long historical weather records, both parties, the farmer and the insurer, have identical information about the insured value and moreover, farming practices have no impact on the insurance payout. Hence, adverse selection and moral hazard play no role and the technical procedure to trigger a payout became substantially simplified. Moreover, full insurance coverage without any deductibles is possible and payments can be made timely and automated just after an adverse weather event was measured. However, discrepancies between payout and on-farm loss can occur which is denoted as basis risk (Woodard and Garcia, 2008). Three sources of basis risk can occur. Spatial basis risk marks any differences between measured and on-farm weather, e.g., through spatial distance (Ritter et al., 2014; Dalhaus and Finger, 2016). Temporal basis risk indicates that an unprecise time window was chosen for index determination, e.g., whole year rainfall vs. growing season rainfall (Conradt et al., 2015; Dalhaus et al., 2018). Design basis risk summarizes all remaining sources, e.g., missing weather variables or biased technical implementation (Leblois et al., 2014).

Summarizing, index insurances are becoming an increasingly important risk management tool for farmers, while basis risk reduction is of central interest. Blockchain can contribute to improving index insurance in two dimensions. First, payments can be made timely and automated based on weather data that triggers the payout as defined in a smart contract. Second, weather information and other data sources, such as plant growth information or data collected by farm machinery, can be automatically integrated via a smart oracle improving basis risk reduction and making the index determination and payout process more efficient (Gatteschi et al., 2018). Smart contracts that integrate external data using smart oracles have already been proven useful in other crypto-economic applications (Harz et al., 2019).

First prototypes for smart index insurance contracts are already in preparation or launched. For instance, Etherisc1, a Swiss-based company, provides decentralized crop insurance based on blockchain technology that provides payouts based on weather data in DIP as native currency (DIP – Decentralized Insurance Protocol tokens). Furthermore, WorldCover2, an insurance provider based in New York City who provides index insurance contracts to smallholder farmers in Ghana, simulated the application of an Ethereum blockchain-based smart contract. Payouts would hence be made in the cryptocurrency Ether. Another smart crop insurance provider is Arbol3. At Arbol, a farmer can propose a contract that includes the premium payment, a payout and a weather event that triggers the payout. Afterward, an investor, serving as counterparty can agree to that proposed contract. Initial and final payments are made in Ether (Jha et al., 2018).

Besides the above advantages of decentralized insurances that are based on smart contracts making automated payouts, the usability of cryptocurrency payouts to compensate farmers needs to be proven in the field. Moreover, farmers, especially in the developing world, might not have access to the required infrastructure to participate in a decentralized blockchain-based insurance system. As a first solution, e.g., Etherisc proposes that third party organizations “[…] can offer payment gateways and integrations which remove the necessity to own cryptocurrency from the end customer” (Mussenbrock, 2017).

Smart Agriculture

Underlying the agri-food systems is the essential data and information on the natural resources that support all forms of farming. As shown in Figure 1, data and information flow while products flow from inputs to output through various value-adding stages as well as financial flow from output to inputs. Different actors and stakeholders generate and manage data and information as per their needs and capacities. Smart agriculture is featured by the utilization of ICT, internet of things (IoT), and various modern data collection and analysis technologies including unmanned aerial vehicles (UAV), sensors and machine learning. A key issue of establishing smart agriculture is developing a comprehensive security system that facilitates the use and management of data. Traditional ways manage data in a centralized fashion and are prone to inaccurate data, data distortion and misuse as well as cyber-attack. For example, environmental monitoring data is generally managed by centralized government entities that have their own interest. They can manipulate the decision-making related to data.



FIGURE 1


[bookmark: figure1]
[image: www.frontiersin.org]
Figure 1. Data and information flow along the food value chain.







The blockchain technology serves to store data and information that various actors and stakeholders generate throughout the entire value-added process, from seed to sale, of producing an agricultural product. It ensures that the data and information are transparent to the involved actors and stakeholders and all recorded data are immutable. Figure 1 shows how what type of blockchain (permissioned or permissionless) used on what kind of platform (Ethereum or Hyperledger) along with which consensus mechanism [Proof of Work/Proof of Stake and (Practical) Byzantine Fault Tolerance] might be suitable to collecting data and information at different stages in crop agri-food systems. The blockchain technology generates security through decentralization rather “security of obscurity” that traditional technologies rely on (Ibm Institute for Business Value, 2015). Distributing data to stakeholders’ computers all is less vulnerable to data loss and distortion than storing data in servers centrally managed by administrators. A blockchain is a database that contains timestamped batches of transactions and activities related to a product. Storing data in servers centrally managed by administrators are more vulnerable to loss and distortion than distributing them to servers on the Internet. The database is incredibly helpful for developing data-driven mobile applications that help optimize farming. Moreover, the blockchain addresses the challenge of creating a comprehensive secure infrastructure for IoT and integrating numerous technologies used in ICT e-agriculture.

Many smart farming models are proposed and implemented based on the joint application of IoT and blockchain technology. For example, Patil et al. (2017) propose “a lightweight blockchain-based architecture for smart greenhouse farms.” In the greenhouses, IoT sensors act as a private local blockchain that centrally managed by the owner. Lin et al. (2018) propose a blockchain and IoT based smart agriculture framework for general use. The core of the framework is a platform that helps establish trust among actors using blockchain. Agents related to products from its plantation to sale can access the data stored in the blockchain through smart mobile phones. Lin et al. (2017) propose a blockchain-based ICT e-agriculture model for the use at the local and regional scale, in which each actor has a piece of real-time water quality data stored in the blockchain. Many companies devote themselves to the blockchain application to smart agriculture. For example, the company Fliament provides devices for connecting physical objects and networks through smart farming technology. It developed penny-sized hardware that can handily be used with existing machines or devices through any connected USB port for securely transacting against a blockchain. Blockchain is also used by farm organizations to make their farming practice smarter. For example, farmland irrigation associations in Taiwan use blockchain to archive the data collectively and better interact with the public (Lin et al., 2017). Each association operates as a “public juridical person” and publish their own data and information about irrigation management to the blockchain that can be accessed by the public. The transparency evokes the public’s contribution to irrigation management and increases its efforts to improve water resource use. Over time, the longitudinal database created using blockchain can be used to inform decision-making on such as the construction and maintenance of irrigation canals.

Smart agriculture with blockchain does not lower, if not raise, the technological barrier for farmers to participate. Importantly, it is better motivated to collect trustworthy data from large farmers than from smallholders for uploading to the blockchain. Large farmers are more likely to be involved in blockchain-based smart agriculture and benefit from it. This thus can create or increase the discrepancy between large farmers and smallholders.

Food Supply Chain

With increased globalization and intense competition in the market, food supply chains have become longer and more complex than ever before. There are some common problems in food supply chains such as food traceability, food safety and quality, food trust and supply chain inefficiency, which add additional risks on the entire society, economy and the health of human.

From the producers’ perspective, the use of blockchain technology helps establish a trust relationship with consumers and build up the reputation of their products, by transparently providing individual product information in the blockchain. Enterprises can better achieve the value of their products and thus increase their competitiveness. This would make it difficult for suppliers of fraud and low-quality products to stay in markets and force all suppliers to improve the quality of products in the whole agricultural and food sectors. From the consumers’ perspective, the blockchain makes true and reliable information about how food is produced and transacted available. It helps address consumers’ concern about the safety, quality and environmental friendliness of food (Ge et al., 2017). The use of blockchain provides the possibility for consumers to interact with producers because consumers can understand the food production process more conveniently and in more detail. It supports consumers by removing obstacles in the exchange of goods to tighten their relationship, and thus strengthen consumer trust and confidence in food safety. From the regulatory agencies’ perspective, blockchain makes reliable and accurate information available for them to carry out informed and efficient regulations (Zhou et al., 2016; Chen, 2018).

Blockchain is capable of recording the information of a product from its provenance to the retail store. It provides a secure and immutable way of storing data collected at the start of the supply chain, e.g., DNA of livestock animals, pesticide residues of grain or vegetables. Such information can be checked and verified by any party involved in the supply chain of the product. Collecting such data for all products can be very costly, but it can be done on samples. The transparence of such information can help detect, e.g., the containment of undeclared meat like happened in the 2013 horse meat scandal in Europe (Kamath, 2018; Montecchi et al., 2019).

Many solutions facilitated by blockchain technology have been proposed to improve the traceability of agricultural products. Tian (2016) proposes an agricultural food supply chain traceability system using Radio Frequency Identification (RFID), a non-contact automatic identification communication technology. It can trace products with trusted information in the entire supply chain. The use of blockchain guarantees that the records of production, process, store and distribution in the system are reliable and genuine. Caro et al. (2018) proposed blockchain-based traceability system that is seamlessly linked with IoT devices, which provide digital data of production and consumption. The traceability is achieved using both Ethereum and Hyperledger Sawtooth blockchain platforms.

Many companies have committed to exploring the application of blockchain technology in food safety management and actively carrying out into practice. For example, Wal-Mart, Alibaba, and JD.com are actively implementing blockchain food traceability projects and using blockchain technology to track the entire process of food production, processing and sales. In October 2016, retail giant Wal-Mart, Tsinghua University and IBM applied the Hyperledger blockchain system to food supply chain management, exploring the Chinese pork supply chain and the United States mango supply chain as a pilot to explore the practical application methods and benefits of blockchain technology. In March 2017, Alibaba and Australia Post explored the blockchain to combat food adulteration. In August 2017, the world’s 10 largest food and fast-moving consumer goods (FMCG) suppliers, including Wal-Mart, Nestle, Dole, and Golden Food, reached a partnership with IBM integrating the blockchain into its supply chain so that food suppliers’ misconduct can be detected more quickly. In this collaboration, IBM’s blockchain platform is designed to help food companies improve the visibility and traceability of their supply chains and make food safer.

The current blockchain technology in the food supply chain is still in the early stages of development. At the same time, there are many immature and imperfect places in the process of blockchain technology implementation. Furthermore, the application of blockchain technology needs wide participation and collaboration of involving parties in the food supply chain, which is significant to play its full role. Due to its characteristics of transparency, security and decentralization, blockchain technology makes it possible to track the information of food quality in the entire supply chain. This helps prevent fraud in food transaction and reduce the costs of food supply chain management. All parties, including producers, consumers and government regulatory bodies, can thus be benefited.

E-Commerce of Agricultural Products

The e-commerce and trade of agricultural product face some crucial problems to solve. First, as Tiago et al. (2017) have demonstrated that consumer with high overall trust is more willing to purchase online, however, the basic information of agriculture products is not easy to be confirmed and trusted by consumers. Meanwhile, Cash on delivery and Logistics service are the most crucial challenges faced by e-commerce companies, especially in developing countries (Reddy and Divekar, 2014). Besides, e-commerce retailers also need to handle time-demanding small orders with diverse items (Boysen et al., 2019), which causes high operating costs for e-commerce companies.

Blockchain technology may provide proper solutions for many aspects of these problems: (1) information security. Blockchain technology provides private key encryption which is a powerful tool that provides the authentication requirements (Xu et al., 2016). It can thus link the data of all aspects of planting and harvesting of agricultural products safely and unchangeably. (2) Supply chain management. Blockchain technology could enable supply chain management more efficiently than traditional monitoring mechanisms by lowering signaling costs for each entity (Chod et al., 2019). Every link in the supply chain – the producer, the place of origin, the shipping company, the destination, the multimodal transport, the warehouse and the final last mile – represents a “block” of information, with the advantage of visibility, aggregation, validation, automation and resiliency (Babich and Hilary, 2018). (3) Payment methods. The blockchain provides a digital payment solution with zero rates. Furthermore, application of cryptocurrency in the transaction of agricultural products will reduce transaction ";"""citation_keywords"",""Blockchain technology; Food Supply chain; Agricultural insurance; smart agriculture; Smart contract""
""og:image"",""https://www.frontiersin.org/files/MyHome%20Article%20Library/462928/462928_Thumb_400.jpg""
""citation_publication_date"",""2020/02/21""
""citation_title"",""Blockchain Technology for Agriculture: Applications and Rationale""
""citation_author_institution"",""Macro Agriculture Research Institute, College of Economics and Management, Huazhong Agricultural University, China"",""Agricultural Economics and Policy Group, ETH Zürich, Switzerland"",""College of Economics and Management, Wuhan Polytechnic University, China"",""The Development Research Center of Shanghai Municipal People’s Government, China"",""School of Economics, Fudan University, China""
""Description"",""The blockchain is a ledger of accounts and transactions that are written and stored by all participants. It promises a reliable source of truth about the state of farms, inventories and contracts in agriculture, where the collection of such information is often incredibly costly. The blockchain technology can track the provenance of food and thus helps create trustworthy food supply chains and build trust between producers and consumers. As a trusted way of storing data, it facilitates the use of data-driven technologies to make farming smarter. In addition, jointly used with smart contracts, it allows timely payments between stakeholders that can be triggered by data changes appearing in the blockchain This article examines the applications of blockchain technology in food supply chains, agricultural insurance, smart farming, transactions of agricultural products for both theoretical and practical perspectives. We also discuss the challenges of recording transactions made by smallholder farmers and creating the ecosystem for utilizing the blockchain technology in the food and agriculture sector.""
""Keywords"",""Blockchain technology, Food Supply chain, Agricultural insurance, smart agriculture, Smart contract""
""citation_publisher"",""Frontiers""
""citation_journal_title"",""Frontiers in Blockchain""
""description"",""The blockchain is a ledger of accounts and transactions that are written and stored by all participants. It promises a reliable source of truth about the state of farms, inventories and contracts in agriculture, where the collection of such information is often incredibly costly. The blockchain technology can track the provenance of food and thus helps create trustworthy food supply chains and build trust between producers and consumers. As a trusted way of storing data, it facilitates the use of data-driven technologies to make farming smarter. In addition, jointly used with smart contracts, it allows timely payments between stakeholders that can be triggered by data changes appearing in the blockchain This article examines the applications of blockchain technology in food supply chains, agricultural insurance, smart farming, transactions of agricultural products for both theoretical and practical perspectives. We also discuss the challenges of recording transactions made by smallholder farmers and creating the ecosystem for utilizing the blockchain technology in the food and agriculture sector.""
""language"",""en""
""citation_date"",""2020""
""title"",""Frontiers | Blockchain Technology for Agriculture: Applications and Rationale | Blockchain""
""citation_online_date"",""2020/02/04""
""citation_author_email"","""","""","""",""""
""citation_issn"",""2624-7852""
""dc:title"",""Frontiers | Blockchain Technology for Agriculture: Applications and Rationale | Blockchain""
""citation_language"",""English""
""Content-Encoding"",""UTF-8""
""citation_pdf_url"",""https://www.frontiersin.org/articles/10.3389/fbloc.2020.00007/pdf""
""Content-Length"",""163992""
""Content-Type"",""text/html; charset=UTF-8""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""og:type"",""article""
""citation_journal_abbrev"",""Front. Blockchain""
""citation_abstract"",""The blockchain is a ledger of accounts and transactions that are written and stored by all participants. It promises a reliable source of truth about the state of farms, inventories and contracts in agriculture, where the collection of such information is often incredibly costly. The blockchain technology can track the provenance of food and thus helps create trustworthy food supply chains and build trust between producers and consumers. As a trusted way of storing data, it facilitates the use of data-driven technologies to make farming smarter. In addition, jointly used with smart contracts, it allows timely payments between stakeholders that can be triggered by data changes appearing in the blockchain This article examines the applications of blockchain technology in food supply chains, agricultural insurance, smart farming, transactions of agricultural products for both theoretical and practical perspectives. We also discuss the challenges of recording transactions made by smallholder farmers and creating the ecosystem for utilizing the blockchain technology in the food and agriculture sector.""
""citation_author"",""Xiong, Hang"",""Dalhaus, Tobias"",""Wang, Puqing"",""Huang, Jiajin""
""Title"",""Blockchain Technology for Agriculture: Applications and Rationale""
""resourceName"",""full""
""citation_pages"",""7""
""url"",""https://www.frontiersin.org/article/10.3389/fbloc.2020.00007/full""
""site_name"",""Frontiers""
""X-UA-Compatible"",""IE=edge""
""frontiers:type"",""Article""
""viewport"",""width=device-width, initial-scale=1, maximum-scale=1""
""citation_doi"",""10.3389/fbloc.2020.00007""
""dc.identifier"",""doi:10.3389/fbloc.2020.00007""
""citation_volume"",""3""
""Content-Language"",""en""
";https://scholar.google.com/scholar?start=60&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095358-1521;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;IoT Adaptive Dynamic Blockchain Networking Method Based on Discrete Heartbeat Signals;X Hu, Y Zheng, Y Su, R Guo ; Sensors, 2020  mdpi.com;;"… 2. Background and Related Work. 2.1. Important Definitions of Blockchain. To understand more

about blockchain, its underlying technology, and our research, here are some important definitions.

The following definitions refer to the Oracle blockchain platform [15] …";Cité 1 fois;Les 6 versions;[PDF] mdpi.com;https://www.mdpi.com/1424-8220/20/22/6503/pdf;;;https://scholar.google.com/scholar?start=320&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095325-1379;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;[PDF][PDF] Identifying Key Non-Financial Risks in Decentralised Finance on Ethereum Blockchain;X Meegan ;2020 researchgate.net;;"… The biggest component of scalability risk is how unpredictable it is to know when Ethereum

blockchain network will be congested from users sending more transac … congestion is high, in

particular if it has a reliance on oracles (more about this in the definition of oracle risk) …";Autres articles;Version HTML;[PDF] researchgate.net;https://www.researchgate.net/profile/Xavier_Meegan/publication/344689196_Identifying_Key_Non-Financial_Risks_in_Decentralised_Finance_on_Ethereum_Blockchain/links/5f8985c9458515b7cf8507e6/Identifying-Key-Non-Financial-Risks-in-Decentralised-Finance-on-Ethereum-Blockchain.pdf;;;https://scholar.google.com/scholar?start=180&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095318-1351;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Blockchain-envisioned secure data delivery and collection scheme for 5G-based IoT-enabled Internet of drones environment;B Bera, S Saha, AK Das, N Kumar… ; IEEE Transactions …, 2020  ieeexplore.ieee.org;;"… 69, NO. 8, AUGUST 2020 9097 Blockchain-Envisioned Secure Data Delivery and Collection

Scheme for 5G-Based IoT-Enabled … Index Terms—Internet of Drones (IoD), Internet of Things

(IoT), blockchain, data delivery, data collection, security. I. INTRODUCTION …";Cité 20 fois;Les 2 versions;null;;;;https://scholar.google.com/scholar?start=150&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095386-1635;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Mechanism Design with Blockchain Enforcement;H Matsushima, S Noda ; Available at SSRN, 2020  papers.ssrn.com;;"… Many blockchains allow users to write a computer protocol that directly accesses the account

balance and makes automated monetary (cryptocurrency) transfers … transfers. This problem

is called the oracle problem in the blockchain literature. This is the …";Cité 3 fois;Les 16 versions;[PDF] nii.ac.jp;https://tohoku.repo.nii.ac.jp/?action=repository_action_common_download&item_id=129975&item_no=1&attribute_id=18&file_no=1;"
Mechanism Design with Blockchain Enforcement

著者 Matsushima Hitoshi, Noda Shunya
journal or
publication title

DSSR Discussion Papers

number 111
page range 1-44
year 2020-03
URL http://hdl.handle.net/10097/00127370



 
 
 
 
 
 
 
 
 
 
 
 

 
Data Science and Service Research 

Discussion Paper  
 
 
 
 
 
 
 
 
 
 
 

Discussion Paper No. 111 
 

Mechanism Design with Blockchain Enforcement 

 
Hitoshi Matsushima and Shunya Noda 

March, 2020 

 

Center for Data Science and Service Research 
Graduate School of Economic and Management 

Tohoku University 
27-1 Kawauchi, Aobaku 

Sendai 980-8576, JAPAN 
 



Mechanism Design with Blockchain Enforcement∗

Hitoshi Matsushima† Shunya Noda‡

First Draft: March 14, 2020; Current Draft: March 17, 2020

Abstract
We study the design of self-enforcing mechanisms that rely on neither a trusted

third party (e.g., court, trusted mechanism designer) nor a long-term relationship.
Instead, we use a smart contract written on blockchains as a commitment device.
We design the digital court, a smart contract that identifies and punishes agents who
reneged on the agreement. The digital court substitutes the role of legal enforcement
in the traditional mechanism design paradigm. We show that, any agreement that
is implementable with legal enforcement can also be implemented with enforcement
by the digital court. To pursue a desirable design of the digital court, we study a
way to leverage truthful reports made by a small fraction of behavioral agents. Our
digital court has a unique equilibrium as long as there is a positive fraction of behavioral
agents, and it gives correct judgment in the equilibrium if honest agents are more likely
to exist than dishonest agents. The platform for smart contracts is already ready in
2020; thus, self-enforcing mechanisms proposed in this paper can be used practically,
even now. As our digital court can be used for implementing general agreements, it
does not leak the detailed information about the agreement even if it is deployed on a
public blockchain (e.g., Ethereum) as a smart contract.
JEL Codes: D47, D82, L86
Keywords: Implementation, Decentralized Mechanism, Smart Contract, Oracle
Problem, Self-Judgment

∗This paper supersedes Matsushima (2019), which demonstrated that smart contracts could substitute
one of the role of courts but enhance illegal cartelization. This paper further articulates the convenience
and social risk of blockchain enforcement by considering a general mechanism design framework and showing
the possibility of (i) unique implementation through behavioral mechanism design, (ii) prevention of false
charges, and (iii) privacy preservation. This study has been supported by a grant-in-aid for scientific research
(KAKENHI, grant numbers: 16H02009, 18K12742) from the Japan Society for the Promotion of Science
(JSPS) and the Ministry of Education, Culture, Sports, Science and Technology (MEXT) of the Japanese
government as well as by the Center of Advanced Research in Finance at the University of Tokyo and
Vancouver School of Economics at the University of British Columbia. We are grateful to Shumpei Goke,
Yoshinori Hashimoto, Wei Li, Kyohei Okumura, Daisuke Oyama, Sergei Severinov, Kyungchul (Kevin) Song,
and all the participants of the 15th Joint Economics Workshop of the University of Tokyo and Seoul National
University (Seoul) for helpful comments. All remaining errors are our own. Hitoshi Matsushima is appointed
as a visiting professor at Graduate School of Economics and Management at Tohoku University.

†Department of Economics, University of Tokyo, 7-3-1 Hongo, Bunkyo-ku, Tokyo 113-0033, Japan. E-
mail: hitoshi@e.u-tokyo.ac.jp.

‡Vancouver School of Economics, University of British Columbia, 6000 Iona Dr, Vancouver, BC V6T 1L4,
Canada. E-mail: shunya.noda@gmail.com

1



1 Introduction

In many contracts and mechanisms, parties are often tempted to renege ex post (e.g., buyers
may refuse to make payments after the delivery of the good). If each party is afraid of
ex post renege in later stages, the parties cannot make a viable agreement (McAfee and
McMillan 1987). In the traditional mechanism design paradigm, legal enforcement (contract
enforcement with court involvement) has been used to deter violations of the agreement.
However, legal enforcement is often slow and needs a high judicial cost. To run a mechanism
in a decentralized manner, parties can alternatively rely on the long-term relationship — if
parties can reward honest behaviors with future payoffs, reneging could be prevented (Athey
and Segal 2013; Hörner, Takahashi, and Vieille 2015). However, in many applications, agents
interact only once.

In this paper, we study a new approach for solving this problem. We construct a self-
enforcing mechanism that relies on neither legal enforcement nor a long-term relationship.
Instead, our mechanism utilizes a smart contract (Szabo 1994) deployed on a blockchain
(Nakamoto 2008) as a commitment device for preventing agents from reneging. The con-
struction of self-enforcing mechanisms with the use of smart contracts is a new mechanism
design problem raised by the emergence of blockchains. We design a smart contract named
“digital court,” which substitutes a court in the traditional mechanism paradigm. As in
the traditional paradigm, in our framework, all the communications and actions are taken
outside of the blockchain (hence, the whole mechanism need not be written as a smart con-
tract). After all the relevant actions are taken, each agent “self-judges” whether each of the
other parties followed the agreement, by sending a message to the digital court. Based on
agents’ reports, a digital court identifies those who reneged and punishes them by executing
some automated monetary transfers, leaving no opportunity for reneging again. Foreseeing
the punishment in the future, agents find it unprofitable to make any deviation that leaves
verifiable evidence. Just like legal enforcement can be used for any purpose, enforcement by
digital courts can be used for implementing any agreement.

This paper regards the smart contract as a contract written as a computer protocol
deployed on a blockchain. A blockchain is a distributed ledger that is managed in a decen-
tralized manner, without relying on trust in any party. Cryptocurrency is one of the leading
applications of the blockchain technology — by managing the data about the ownership
(account balance) of “currencies,” a blockchain performs as a peer-to-peer electronic cash
system. In contrast to fiat money, cryptocurrencies are programmable. Many blockchains
allow users to write a computer protocol that directly accesses the account balance and
makes automated monetary (cryptocurrency) transfers. Such computer protocols are called

2



smart contracts. After the first blockchain, Bitcoin, was created, a number of blockchains
that can be used as a platform for smart contracts have been launched. Thus, as of 2020,
parties are already able to use smart contracts as a tool of mechanism design.

Smart contracts automatically execute contingent transfers in accordance with the pre-
agreed protocol and inputs made afterward. As smart contracts can directly update the
account balance managed by the blockchain, using a smart contract, users can make a com-
mitment for contingent payments. Taking advantage of this commitment power, untrusted
parties may reach a viable agreement without relying on legal enforcement. Previous studies
have already proposed various smart contracts for specific applications, e.g., auctions (Galal
and Youssef 2019), bilateral trading (Asgaonkar and Krishnamachari 2019), sharing apps
(Bogner, Chanson, and Meeuw 2016), and boardroom voting (McCorry, Shahandashti, and
Hao 2017). In contrast to them, we study self-enforcement of general abstract mechanisms
by designing a smart contract that performs as a court.

Although a smart contract is a useful commitment device for enforcing monetary trans-
fers, it has a number of limitations. Cryptographers, computer scientists, and engineers are
actively debating possible technical solutions. However, our approach does not rely on them
— we only use the technology that is already incorporated into popular blockchain plat-
forms (such as Ethereum) as of 2020. Hence, all the mechanisms proposed in this paper can
be used in the real world right now. Instead of using new cryptographic technologies, our
digital-court approach overcomes the following fundamental limitations of smart contracts
through mechanism design.

Privacy If we use a public blockchain as a platform, the smart contract deployed on it
becomes publicly observable.1 Hence, if parties write a smart contract intended for a specific
purpose, the public can infer the detail of the agreement the parties reached. The versatility
of our approach helps parties to keep privacy. Since digital courts can be used for any
purpose, the agreement enforced by a digital court cannot be inferred from the structure of
the uploaded digital court.

Low Transaction Cost The users of smart contracts must pay commissions to record-
keepers every time they input new information and make an operation. As computations

1This is because public blockchains allow anyone to work as a record-keeper. Since record-keepers have
to check the validity of transaction requests, they must be able to observe the detail of transactions. The
cryptography literature has proposed various technical solutions for maintaining privacy (e.g., Zyskind,
Nathan, and Pentland 2015; Kosba, Miller, Shi, Wen, and Papamanthou 2016), but our approach does not
rely on them.

3



executed in a smart contract are expensive, the users want to minimize the use of it.2 Our
approach indeed minimizes commissions as we use a smart contract only for punishments.
Our result also articulates that punishments are the only part of transactions that must be
executed on blockchains.

Payment Only Smart contracts can only enforce transfers of digital assets whose own-
ership is managed by the relevant blockchain. If all allocations executed by the agreement
were completed in a blockchain, parties could make a mechanism self-enforcing by simply
writing the mechanism as a smart contract and deploying it on a blockchain. However, as of
2020, besides money (cryptocurrencies), only a very limited type of digital assets is managed
by blockchains. Hence, the commitment power of smart contracts is one-sided — although
smart contracts can enforce payments, they cannot directly enforce actions that are taken in
exchange for payments. This limitation does not matter to our approach. To deter reneging,
it suffices to fine deviators.3

Finite Message Spaces The size of the data that blockchains can store and process is
limited. Hence, a smart contract must not involve infinite message spaces. This techno-
logical limitation naturally rules out the use of unbounded mechanisms (e.g., the canonical
mechanism of Maskin 1999), which is often criticized in the literature (e.g., Jackson 1992;
Abreu and Matsushima 1992). Our construction of digital courts does not take advantage
of the unboundedness of the message space.

In our framework, a smart contract is used only for ex post punishments. As such,
all communications and actions but judgment are taken place outside of the blockchain.
The input of the outside data (who should be punished?) to the smart contract cannot be
automated; thus, participants of the mechanism must report the deviators to the digital court

2Antonopoulos and Wood (2018) state that “any computation executed in a smart contract is very ex-
pensive and so should be kept as minimal as possible. It is therefore important to identify which aspects of
the application need a trusted and decentralized execution platform” (Chapter 12). Our results indicate that
the aspect that needs a trusted execution platform is punishment for deviators. Huberman, Leshno, and
Moallemi (2017, 2019); Budish (2018) provide theoretical foundations for the expensiveness of transactions
in the long run.

3Hypothetically, the ownership of other financial assets, such as fiat money, stocks, and bonds, can also
be managed by blockchains. However, as of 2020, there is no blockchain with which parties can write a smart
contract that enforces transfers of such assets. Some emerging companies issue digital assets for fundraising,
where the ownership of the digital assets is managed by blockchains (initial coin offering). Compared with
the market of cryptocurrencies, the market size of other digital assets is negligibly small.

Note also that, many (non-digital) assets and services cannot be managed by blockchains even in the
future. For example, in a housing market, while the ownership of a house can (hypothetically) be managed
by a blockchain, the blockchain cannot directly enforce transfers of possession as it cannot evacuate the
residents. Hence, the limited scope problem will continue to exist even after blockchains are widely adopted.

4



by themselves. As we assume no party is trusted, agents may input incorrect information. If
so, the digital court misunderstands the state of the world and cannot execute the intended
transfers. This problem is called the oracle problem in the blockchain literature. This is the
fundamental design question of the digital court.

The oracle problem should be resolved by incentivizing agents to make correct inputs.
As in the traditional paradigm, we assume that reneges are verifiable (otherwise, deviations
cannot be prevented even when legal enforcement is available). Hence, (i) agents have
complete (verified) information about who is “guilty” (i.e., violated the agreement), and (ii)
the mechanism should incentivize agents to input truthful information, ideally in the unique
equilibrium. This is a new class of implementation problems (see Jackson 2001; Maskin and
Sjöström 2002 for comprehensive surveys).4

In this paper, we tackle three design questions of the digital court: (i) partial imple-
mentation, (ii) unique implementation, and (iii) the false charge problem. The false charge
problem is a new design problem that has not appeared in the traditional paradigm, whose
detail is explained later.

Partial implementation of blockchain enforcement requires to punish agents who violated
the agreement in one equilibrium. As we assume that agents are indifferent between whether
the other agents are punished or not, this goal is trivial. The digital court decides whether to
punish each agent, based on the other agents’ message profile. If the sentence is independent
of the defendant’s message, and each agent obtains no reward from inputting information,
then each agent has a weak incentive to make a truthful report to the digital court. Hence,
in an equilibrium, the digital court correctly punishes guilty agents. Note also that, even if
we strengthen the equilibrium concept to the strict Nash equilibrium, the goal is still trivial
— the digital court can incentivize agents to decide the sentence unanimously just by giving
penalties when reports are inconsistent (Design 1).

Partial implementation is unsatisfactory. Since agents do not directly care about whether
the judgment is fair or not, there are many equilibria in which the digital court misjudges.
Ideally, we want to punish guilty agents correctly in any equilibria. However, since we assume
that agents’ payoffs from the digital court are independent of the guiltiness of the defendant,
it is impossible to exclude unwanted equilibria.

To break down the impossibility result, we consider a way to take advantage of the behav-
ioral motivation that is influenced by the guiltiness of defendants. Specifically, we consider
intrinsic preferences for conveying honest and dishonest messages to the digital court. We

4In the blockchain literature, various systems that correctly input the truthful information about the mar-
ket has been invented (Peterson, Krug, Zoltu, Williams, and Alexander 2015; Ellis, Juels, and Nazarov 2017;
Adler, Berryhill, Veneris, Poulos, Veira, and Kastania 2018). However, no mechanism for helping a small
group of agents to input the truthful information about the local information was established in the literature.

5



keep assuming that most agents are rational and purely motivated by material payoffs. How-
ever, we also assume that some agents may be honest and have a psychological incentive
to make a truthful report, and other agents may be adversarial and have an incentive to
make an untruthful report. Since we focus on an environment in which agents interact only
once (i.e., there is no long-term relationship), each agent does not know whether each of the
other agents is truly honest or not. Hence, each agent has a belief about the other agents’
behavioral types. We show that, when agents believe that honest agents are more likely to
exist than adversarial agents, there is a mechanism that incentivizes all rational agents to
vote for correct judgment.

The design of the proposed digital court (Design 2) is simple. The sentence is determined
by a simple majority rule. In addition, similar to Design 1, jurors are punished when their
reports are mutually inconsistent. However, Design 2 allows agents to vote not only for
0 (acquittal) or 1 (conviction) but also any fractional value between 0 and 1. Thanks to
this feature, when honest agents are more likely to exist than adversarial agents, all the
rational agents are incentivized to report a “slightly more honest” message than the other
rational agents because rational agents also want to match their message with honest agents’.
Accordingly, from the perspective of rational agents, the only reporting strategy that survives
iterated elimination of strictly dominated strategies is voting for a correct decision (unique
implementation). This result is pervasive in the following sense. First, the fraction of
honest agents can be arbitrarily small. Second, the mechanism need not identify who is
honest. Design 2 performs well as long as agents believe that some of the other agents (may
probabilistically) prefer to be honest. Third, the structure of psychological cost functions
can be general. Fourth, Design 2 performs well even if there are adversarial agents, as long
as their ex ante fraction is smaller than honest agents’.

If we assume that agents have no intrinsic preference, Design 2 fails to implement correct
judgment, just as Design 1 fails to do so. However, once we assume the existence of a small
fraction of behavioral agents, the equilibria of Design 2 shrinks drastically. Consequently,
we can achieve unique implementation of enforcement. How a mechanism leverages the
possibility of the existence of behavioral agents is a new criterion for evaluating mechanisms,
and our Design 2 makes a difference here.5

If adversarial agents are absent, Design 2 makes correct judgment with probability one.
5The equilibrium analysis of the game under the presence of (a small fraction of) behavioral agents

and incomplete information itself has a long history. For example, Kreps, Milgrom, Roberts, and Wilson
(1982) study how the existence of behavioral agents changes the equilibria of finitely repeated games, and
Postlewaite and Vives (1987); Carlsson and Van Damme (1993); Morris and Shin (1998) study how incomplete
information shrinks the set of equilibria. These previous studies focus on the analysis of given games. In
contrast, our focus is on the design of mechanisms that fully take advantage of the existence of behavioral
agents and incomplete information.

6



However, under the presence of adversarial agents, Design 2 may make a false charge — if we
accidentally have many adversarial agents, the digital court would misunderstand the state
of the world. In other words, Design 2 sometimes punishes innocent agents accidentally.
Ideally, the mechanism should not fine innocent agents even if some agents prefer to make
incorrect inputs. To achieve this goal, we design Design 3, which is a hybrid of Design 1
and Design 2 that incentivizes adversarial agents to tell the truth. Design 3 imposes a large
fine when agents’ reports are mutually inconsistent, because its payment needs to offset
adversarial agents’ intrinsic incentives to tell a lie. To avoid fining agents who input truthful
information into the digital court, we further elaborate a mechanism. Our final design of the
digital court, Design 4, only imposes an arbitrarily small fine to agents who made a truthful
input, on the equilibrium path.

On one hand, our results indicate that smart contracts may improve social welfare. Law-
suits and compulsory execution are often costly and time-consuming. If a victim hesitates
to pay the judicial cost, lawsuits may become an empty threat and cannot prevent agents
from reneging. Even in such situations, punishments by smart contracts could be a credible
threat as its cost for enforcement could be significantly lower than that of legal enforcement.
Hence, smart contracts may resolve many real-world hold-up problems.

On the other hand, our findings indicate that blockchains and smart contracts may jeop-
ardize the real-world economy more seriously than the previous studies has expected. Unlike
real courts, digital courts do not examine the legality of the agreement to be enforced. There-
fore, smart contracts enable parties to write viable contracts intended for illegal purposes.
For example, Tirole (1992) discusses that side payments can be enforced through a long-term
relationship, and therefore, parties can implement an illegal agreement without relying on
legal enforcement if agents interact repeatedly. However, our result indicates that under
the presence of the smart-contract platform, parties can write a self-enforcing illegal con-
tract, even if their relationship is one-shot. Furthermore, if parties follow our digital-court
approach, regulators cannot detect the detail of the agreement by monitoring the smart
contract uploaded to a blockchain.6

The rest of this paper is organized as follows. Section 2 describes the framework of our de-
centralized mechanism design problem. Section 3 explains legal enforcement as a benchmark
method. Section 4 models smart contracts and digital courts, and explains how they work
as a new way to enforce agreements. Section 5 considers partial implementation. Section 6
introduces behavioral aspects of agents’ preferences and considers unique implementation.

6Although Cong and He (2019) suggest that blockchains may encourage greater collusion, they focus on
tacit collusion because “explicit form of collusion using smart contracts is easy to detect and can be forbidden
by antitrust law” (Cong and He 2019, pp.1729). However, if a cartel follows our approach, the agreement
enforced by a digital court cannot be detected from its appearance.

7



Section 7 presents two applications, auctions and bidding ring, and argues about regulatory
policies to prevent the use of digital court for illegal purposes. Section 8 considers the false
charge problem. Section 9 concludes.

2 Decentralized Mechanisms

We first introduce a framework of the decentralized mechanism design problem, where the
trusted mechanism designer is absent. There are n ≥ 2 agents I = {1, 2, . . . , n} that attempt
to implement a joint decision. Agents are willing to implement an agreement α : Ξ → A

that maps a message profile ξ ∈ Ξ to an action profile α(ξ) ∈ A :=
∏

i∈I Ai. Formally, the
game proceeds as follows.

Step 1: A type profile θ := (θi)i∈I ∈ Θ :=
∏

i∈I Θi is realized. Every agent i observes her
type, θi ∈ Θi.

Step 2: To figure out the state, θ, every agent i publicly announces a message, ξi ∈ Ξi,
simultaneously. The announced message profile ξ := (ξi)i∈I ∈ Ξ :=

∏
i∈I Ξi becomes public

information among agents. Since all agents observe Ξ, the agreed action profile ι(Ξ) becomes
common knowledge at this point.

Step 3: Each agent takes an action âi ∈ Ai, simultaneously (simultaneousness is for sim-
plicity and can easily be relaxed). Each agent verifies the action she took to the other agents.
Hence, the set of guilty agents (deviators), D(â, ξ) := {i ∈ I : âi �= αi(ξ)}, becomes common
knowledge and verifiable information. We denote agent i’s payoff that is finalized in Step 3
by ui : A×Θ → R. We assume that ui is bounded, quasi-linear, and risk-neutral.

For notational convenience, we represent the set of deviators by a n-dimensional vector,
ω := (ωi)i∈I ∈ Ω := {0, 1}n. For each i, ωi denotes agent i’s guiltiness: ωi = 0 if “agent i is
innocent,” i.e., i /∈ D(â, ξ), and ωi = 1 if “agent i is guilty,” i.e., i ∈ D(â, ξ).

Thus far, all the communications and actions are taken outside of the blockchain. Note
that, if agents are not willing to use legal enforcement, they need not prepare an explicitly-
written contract (or a smart contract) that specifies the agreement to be implemented. See
Section 7 for concrete examples of decentralized mechanisms.

If the game terminates in Step 3, the agreement Îą is just a recommendation. Hence,
ι is implementable only if agents voluntarily follow the recommendation; i.e., ι(θ) is a (ex
post) Nash equilibrium of the normal-form game in which each agent i’s utility is specified

8



by ui(·, θ) : A → R. This is a very stringent condition. For example, the agreement can
recommend no monetary transfer because no agent is willing to make a payment voluntarily.
This is why mechanisms need enforcement.

To prevent agents from reneging, we want to punish deviations. Let ti ∈ R+ be the fine
imposed on agent i ex post. Since we assume that utility functions are quasi-linear, agent
i’s total payoff is represented in the following form.

Ui(â, θ, ti) = ui(â, θ)− ti.

We discuss how to implement ex post punishment in detail from the next section.
We define

Ti := sup
ξ∈Ξ,θ∈Θ,âi∈Ai

{ui(âi, α−i(ξ), θ)− ui(α(ξ), θ)}+ ε,

where Îľ > 0 is an arbitrarily small number. When agent i is fined Ti if she is guilty and 0

otherwise, agent i has no incentive for reneging. To enforce the agreement Îą, it suffices to
find a way to fine Ti as a credible threat.

Note that we made three important assumptions on the actions. First, we assume that
all the actions ai ∈ Ai are taken outside of the blockchain, and therefore, actions cannot be
directly enforced by smart contracts. Note that actions may include transfers of fiat money.

Second, we assume that all the monetary transfers that happen on the equilibrium path
should be specified as a part of actions because we focus on mechanisms that use transfers
in cryptocurrencies only as ex post punishments. This is for keeping privacy: agents do
not want to disclose the detailed information about the agreement Îą, the reported message
profile ξ, and taken actions â through the smart contract written on a blockchain.

Third, we assume that actions are verifiable. If not, implementation is difficult even when
a court is present. The aim of this paper is to discuss how smart contracts may substitute
the role of courts in the traditional mechanism design paradigm. We exclude moral hazard
problems that are relevant even when legal enforcement is available, by assuming that actions
are verifiable.

Remark 1. In Step 2, agents are required to make public announcements. Once a public
announcement is made, the announced message immediately becomes common knowledge
among agents.7 Hence, once an agent verifies the fact that she followed the agreement, all
agents can immediately understand her innocence. Note that public announcements are
technically easy. Agents can achieve them by uploading messages to a tamper-proof ledger

7Messages need not be disclosed to the outside. To maintain privacy, for example, agents can encrypt all
the public announcements by using a common password.

9



(e.g., a version control system such as GitHub or a blockchain itself).8

Remark 2. In Step 2, agents announce messages simultaneously. Even if a trusted mechanism
designer is absent and moves are sequential by nature, agents can use a commitment scheme
to declare messages simultaneously. The commitment scheme is a standard application of
cryptography (see, for example, Goldreich 2007).

3 Benchmark: Legal Enforcement

Traditionally, human society has relied on legal enforcement for discouraging parties from
reneging. The law prohibits agents from violating the contract, and courts enforce agents to
keep the promise by punishing violators. Specifically, agents play the following Step 4 after
Step 3.

Step 4: Agents report (sue) the guiltiness vector ω to a court. The court investigates the
detail of the agreement and decides whether the defendant should be punished. If agent i is
identified to be guilty, she is fined Ti.9

Towards the implementation of the agreement, courts have two important roles. First, a
court must investigate the validity of agents’ claim, and judge whether agents who are claimed
to be guilty should be punished. Recall that the action profile is assumed to be verifiable.
Hence, agents cannot misreport the guiltiness to the court. Therefore, this procedure is
mathematically easy, as long as the court is non-strategic. For Step 4 to be a credible threat,
the court must be trusted in the sense that agents believe that the court will punish guilty
agents properly.

Second, a court must check whether the agreement is legal and help parties to implement
the agreement only when the agreement is made for a good purpose. This is for protecting
society from the threat of illegal activities. Thanks to this function, criminals have not been
able to use a mechanism that relies on legal enforcement.

8Akbarpour and Li (2019) study an auction design problem in which legal enforcement is available but a
trusted mechanism designer is absent. Their environment is crucially different from ours in that they exclude
public announcements by assumption (in their model, only private communications between each agent and
an untrusted mechanism designer are allowed). The middleman problem they study does not appear if public
announcements are available.

9In reality, when the court admits a violation of the contract, the court typically orders the defendant
to pay compensation to the plaintiff. From the mechanism design perspective, both compensation and
fine work as punishments for deterring contract violations. Hence, we do not strictly distinguish these two
terminologies.

10



Even if courts are trusted, legal enforcement is not almighty. First, lawsuits are costly.
The capacity of courts is always limited, and decision making is typically slow. If ex post
punishment becomes an empty threat for these reasons, then deviations cannot be prevented.
Second, under some circumstances, agents may not want to rely on courts. For example,
agents might be concerned about privacy. If they rely on a lawsuit, the relevant information
will be disclosed to the public.

4 Blockchain Enforcement

4.1 Smart Contract

First, we model smart contracts mathematically.

Definition 1 (Smart Contract). A smart contract (M, t̄, γ) is a triple of a message space
M := (Mi)i∈I , a deposit vector t̄ := (t̄i)i∈I ∈ R

n
+, and a transfer rule γ : M → ∏

i∈I(−∞, t̄i],
where the transfer rule Îł is weakly budget balanced; i.e.,

∑
i∈I γi(m) ≥ 0 for all m ∈ M .

The smart contract initially receives t̄i from agent i as a deposit. When message profile
m is input, the smart contract (re)pays t̄i − γi(m) to agent i. Hence, agent i’s net payment
is Îłi(m). The rest of the deposit,

∑
i∈I γi(m), is burned. Once a smart contract is deployed

on a blockchain and agents make a deposit, no agent can renege on it.

Here, we define the smart contract as a commitment device for input-contingent pay-
ments. This assumption is realistic. First, a smart contract can directly update the account
balances of participants, and no one can tamper the smart contract. Thus, through a smart
contract, agents can make a commitment to contingent cryptocurrency transfers. Second, as
of 2020, besides cryptocurrencies, there are few digital assets whose ownership is managed
by blockchains. Hence, the smart contract can hardly enforce transfers other than cryp-
tocurrencies. Third, cryptocurrencies are actively traded on the market as a kind of liquid
speculative assets; thus, it is easy to exchange popular cryptocurrencies (such as Bitcoin and
Ethereum) for fiat money.10 Hence, transfe";"""date"",""2020-03-26T04:38:42Z""
""pdf:PDFVersion"",""1.5""
""xmp:CreatorTool"",""Adobe Acrobat Pro 2017 17.11.30158""
""pdf:docinfo:title"",""TERG""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""Adobe Acrobat Pro 2017 17.11.30158""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""TERG""
""xmp:CreateDate"",""2020-03-25T09:58:37Z""
""modified"",""2020-03-26T04:38:42Z""
""pdf:hasMarkedContent"",""false""
""xmp:ModifyDate"",""2020-03-26T13:38:42Z""
""pdf:docinfo:creator"",""nancy""
""meta:author"",""nancy""
""meta:creation-date"",""2020-03-25T00:58:37Z""
""created"",""2020-03-25T00:58:37Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-03-25T00:58:37Z""
""Author"",""nancy""
""producer"",""Acrobat Distiller 17.0 (Windows)""
""pdf:docinfo:producer"",""Acrobat Distiller 17.0 (Windows)""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""1"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""4"",""2"",""0"",""3"",""3"",""6"",""4"",""4"",""0"",""6"",""10"",""7"",""8"",""30"",""20"",""7"",""8"",""0"",""0"",""2"",""1"",""0"",""0"",""13"",""17"",""0"",""1"",""18"",""16"",""0"",""10"",""8"",""0"",""0"",""0"",""0"",""0""
""access_permission:modify_annotations"",""true""
""dc:creator"",""nancy""
""dcterms:created"",""2020-03-25T00:58:37Z""
""Last-Modified"",""2020-03-26T04:38:42Z""
""dcterms:modified"",""2020-03-26T04:38:42Z""
""title"",""TERG""
""xmpMM:DocumentID"",""uuid:b78432ef-baf9-483e-bc2a-d4e16dca7e3e""
""Last-Save-Date"",""2020-03-26T04:38:42Z""
""pdf:docinfo:modified"",""2020-03-26T04:38:42Z""
""meta:save-date"",""2020-03-26T04:38:42Z""
""Content-Length"",""588882""
""Content-Type"",""application/pdf""
""xmp:MetadataDate"",""2020-03-26T13:38:42Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""nancy""
""pdf:producer"",""Acrobat Distiller 17.0 (Windows)""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""46""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""199"",""348"",""2726"",""2502"",""2415"",""2844"",""2735"",""2807"",""2759"",""1942"",""2104"",""2196"",""2143"",""1759"",""1917"",""1613"",""1401"",""2067"",""1753"",""1951"",""1440"",""1752"",""988"",""1925"",""1857"",""1187"",""1656"",""1900"",""1533"",""2277"",""2379"",""2385"",""1631"",""1301"",""1921"",""1897"",""951"",""1466"",""2500"",""1432"",""1543"",""2478"",""1758"",""1635"",""1447"",""934""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-03-25T00:58:37Z""
";https://scholar.google.com/scholar?start=440&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619095323-1370;https://scholar.google.com/scholar?q=Oracles+blockchain&hl=fr&as_sdt=0%2C5&as_ylo=2020&as_yhi=2020;Blockchain in operations management and manufacturing: Potential and barriers;J Lohmer, R Lasch ; Computers & Industrial Engineering, 2020  Elsevier;;"… Blockchain in operations management and manufacturing: Potential and barriers … Highlights. •

Qualitative empirical study on blockchain in OM and manufacturing with experts. • Detailed

analysis of identified potentials and barriers of blockchain technology. • …";Cité 11 fois;Les 2 versions;null;;;;https://scholar.google.com/scholar?start=170&q=Oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098822-238;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Formal Verification of Fair Exchange Based on Bitcoin Smart Contracts;C Shi, K Yoneyama ; International Conference on Cryptology in India, 2020  Springer;;"… On blockchain systems, a smart contract can be regarded as a system participant, responding

to the information received, receiving and … give formulations of seven fair exchange protocols using

smart contract on Bitcoin: oracle, escrow, intermediated payment, timed commitment …";Autres articles;;null;;;;https://scholar.google.ch/scholar?start=780&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098729-29;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;[PDF][PDF] Two-round n-out-of-n and multi-signatures and trapdoor commitment from lattices;I Damĺgrd, C Orlandi, A Takahashi, M Tibouchi ;2020 eprint.iacr.org;;"… In recent years, distributed signing protocols have been actively researched, motivated by many

new applications for instance in the blockchain domain … issue is not serious in a single-user scheme,

since the ?-protocol is made non- interactive in the random oracle model anyway …";Cité 5 fois;;[PDF] iacr.org;https://eprint.iacr.org/2020/1110.pdf;"
Two-round n-out-of-n and Multi-Signatures and
Trapdoor Commitment from Lattices?

Ivan Damg̊ard1, Claudio Orlandi1, Akira Takahashi1, and Mehdi Tibouchi2

1 Department of Computer Science and DIGIT, Aarhus University, Denmark
{ivan,orlandi,takahashi}@cs.au.dk

2 NTT Corporation, Japan
mehdi.tibouchi.br@hco.ntt.co.jp

March 4, 2021

Abstract. Although they have been studied for a long time, distributed signature protocols have
garnered renewed interest in recent years in view of novel applications to topics like blockchains.
Most recent works have focused on distributed versions of ECDSA or variants of Schnorr signatures,
however, and in particular, little attention has been given to constructions based on post-quantum
secure assumptions like the hardness of lattice problems. A few lattice-based threshold signature and
multi-signature schemes have been proposed in the literature, but they either rely on hash-and-sign
lattice signatures (which tend to be comparatively inefficient), use expensive generic transforma-
tions, or only come with incomplete security proofs.

In this paper, we construct several lattice-based distributed signing protocols with low round com-
plexity following the Fiat–Shamir with Aborts (FSwA) paradigm of Lyubashevsky (Asiacrypt 2009).
Our protocols can be seen as distributed variants of the fast Dilithium-G signature scheme and the
full security proof can be made assuming the hardness of module SIS and LWE problems. A key
step to achieving security (unexplained in some earlier papers) is to prevent the leakage that can
occur when parties abort after their first message—which can inevitably happen in the Fiat–Shamir
with Aborts setting. We manage to do so using homomorphic commitments.

Exploiting the similarities between FSwA and Schnorr-style signatures, our approach makes the
most of observations from recent advancements in the discrete log setting, such as Drijvers et
al.’s seminal work on two-round multi-signatures (S&P 2019). In particular, we observe that the
use of commitment not only resolves the subtle issue with aborts, but also makes it possible to
realize secure two-round n-out-of-n distributed signing and multi-signature in the plain public key
model, by equipping the commitment with a trapdoor feature. The construction of suitable trapdoor
commitment from lattices is a side contribution of this paper.

Keywords: threshold signatures, n-out-of-n distributed signatures, multi-signatures, lattice-based
cryptography, Fiat–Shamir with aborts, trapdoor commitments.

? An extended abstract appears at PKC 2021. This is the full paper.



Table of Contents

1 Introduction 3
1.1 Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2 Technical Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2 Preliminaries 8
2.1 Polynomial Rings and Discrete Gaussian Distribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2 Lattice Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.3 Fiat–Shamir with Aborts Framework and Dilithium-G . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.4 Trapdoor Homomorphic Commitment Scheme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.5 Security Notions for n-out-of-n Signature and Multi-Signature . . . . . . . . . . . . . . . . . . . . . . . . 12

3 DS2: Two-round n-out-of-n Signing from Module-LWE and Module-SIS 14
3.1 Protocol specification and overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.2 Asymptotic efficiency analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.3 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

4 Lattice-Based Commitments 18
4.1 Statistically Binding Commitment Scheme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.2 Trapdoor Commitment Scheme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

A Lattice-based Statistically Binding Commitment 25

B Additional Preliminaries 25
B.1 Additional Properties for Commitment Scheme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
B.2 General Forking Lemma . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

C Security Proof for DS2 26

D MS2: Two-round Multi-signature in the Plain Public Key Model 33

E Potential Wagner-like Attack on Naive Two-round Protocols 37

F DS3: Three-round Distributed Signature Protocol from Module-LWE 38
F.1 Protocol Specification and Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
F.2 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38



1 Introduction

In recent years, distributed signing protocols have been actively researched, motivated by many new
applications for instance in the blockchain domain. One of the main motivations to construct a distributed
signature is reducing the risk of compromising the secret key, which could occur in various ways, for
instance as a result of attacks on cryptographic devices. In this paper, we study two similar classes of
distributed signing protocols that can be constructed from standard lattice-based computational hardness
assumptions, namely n-out-of-n distributed signature schemes and multi-signature schemes.

n-out-of-n signature. An n-out-of-n signature is a special case of general t-out-of-n threshold sig-
nature. At a high level, the parties involved in n-out-of-n signature first invoke a key generation pro-
tocol in a way that each individual party Pj learns a share skj of the single signing key sk, but sk
is unknown to anyone, and then they interact with each other to sign the message of interest. The
required security property can be informally stated as follows: If all n parties agree to sign the mes-
sage then they always produce a single signature that can be verified with a single public key pk; if
at most n − 1 parties are corrupted, it is not possible for them to generate a valid signature. Several
recent works have studied threshold versions of ECDSA, arguably the most widely deployed signature
scheme, both in the 2-out-of-2 variant [Lin17, DKLs18, CCL+19] and in the more general t-out-of-n
case [GGN16,GG18,LN18,DKLs19,DKO+19,CCL+20,CMP20,GKSS20,DJN+20,GG20].
However it is well known that ECDSA does not withstand quantum attacks since it is based on dis-
crete log, and it is therefore important to study post-quantum alternatives which support threshold
signing. Despite this, very few works have considered n-out-of-n (or t-out-of-n) lattice-based signatures.
Bendlin et al. [BKP13] proposed a threshold protocol to generate Gentry–Peikert–Vaikuntanathan signa-
ture [GPV08]; Boneh et al. [BGG+18] developed a universal thresholdizer that turns any signature scheme
into a non-interactive threshold one, at the cost of using relatively heavy threshold fully homomorphic
encryption.

Fiat–Shamir with aborts. Neither of the above previous papers investigated signatures following the
Fiat–Shamir with Aborts (FSwA) paradigm due to Lyubashevsky [Lyu09,Lyu12], which was specifically
designed for lattice-based signatures and is nowadays one of the most efficient and popular approaches
to constructing such schemes. Recall that in standard Fiat-Shamir signatures, the scheme is based on an
underlying 3-move ÎŁ-protocol where transcripts are of form (w, c, z) and where c is a random challenge.
This interactive protocol is then turned into a non-interactive signature scheme by choosing the challenge
as the hash of the first message w and the message to be signed. The FSwA paradigm follows the same
approach, with the important difference that the signer (prover) is allowed to abort the protocol after
seeing the challenge. Only the non-aborting instances are used for signatures, and it turns out that this
allows the signer to reduce the size of the randomness used and hence reduces signature size. This comes
at the cost of marginally larger signing time because some (usually quite small) fraction of the protocol
executions are lost due to aborts.

Examples of single-user schemes based on FSwA include Dilithium [LDK+19] and qTESLA [BAA+19],
which are round-3 and round-2 candidates of the NIST Post-Quantum Cryptography Standardization
process. Cozzo and Smart [CS19] recently estimated the concrete communication and computational
costs required to build a distributed version of these schemes by computing Dilithium and qTESLA with
generic multi-party computation. They pointed out inherent performance issue with MPC due to the
mixture of both linear and non-linear operations within the FSwA framework.
Given all this, an obvious open question is to construct secure n-out-of-n protocols specifically tailored
to the FSwA, while also achieving small round complexity.

Multi-signature. A multi-signature protocol somewhat resembles n-out-of-n signature and allows a
group of n parties holding a signing key sk1, . . . , skn to collaboratively sign the same message to obtain a
single signature. However, multi-signature protocols differ from n-out-of-n signing in the following ways:
(1) there is no dedicated key generation protocol, and instead each party Pj locally generates its own
key pair (pkj , skj) and publish pkj before signing (so-called the plain public-key model [BN06]), (2) the
group of signing parties is usually not fixed, and each party can initiate the signing protocol with a
dynamically chosen set of parties associated with L = {pk1, . . . , pkn}, and (3) the verification algorithm
usually doesn’t take a single fixed public key, and instead takes a particular set of public keys L that
involved in the signing protocol. Hence, roughly speaking, multi-signatures have more flexibility than
n-out-of-n signatures in terms of the choice of co-signers, at the cost of larger joint public key size and
verification time (unless more advanced feature like key aggregation [MPSW19] is supported).

3



Schnorr vs FSwA. There is a long line of research that starts from Schnorr’s signature scheme [Sch90]
and follows the standard Fiat–Shamir paradigm to build distributed signatures [SS01, NKDM03, AF04,
GJKR07, KG20] and multi-signatures [MOR01, BN06, BCJ08, MWLD10, STV+16, MPSW19, NRSW20,
NRS20]. In particular, Drijvers et al. [DEF+19] recently discovered a flaw of the existing two-round
Schnorr-based multi-signatures, with a novel concurrent attack relying on the generalized birthday al-
gorithm of Wagner [Wag02]. They accordingly proposed mBCJ scheme, a provably secure variant of
Bagherzhandi et al.’s BCJ scheme [BCJ08].

Unlike distributed n-out-of-n signatures, several three or four-round multi-signatures based on FSwA
are already present in the literature. Bansarkhani and Sturm [BS16] extended Güneysu–Lyubashevsky–
Pöppelmann (GLP) [GLP12] signature and proposed the first multi-signature following the FSwA paradigm,
which was recently followed by multiple similar variants [MJ19, TLT19, TE19, FH19, FH20]. Relying on
the syntactic similarities between Schnorr and FSwA-style signatures, these protocols essentially borrow
the ideas of Schnorr-based counterparts; for instance, [BS16] can be considered as a direct adaptation of
Bellare and Neven’s three-round Schnorr-like multi-signature [BN06]. However, as explained below, the
security proofs of all these protocols are either incomplete or relying on a non-standard hardness assump-
tion, where the underlying problem only emerges in the Fiat–Shamir with aborts setting. Therefore, we
are also motivated to construct a provably secure multi-signature protocol within this paradigm, while
making the most of useful observations from the discrete log setting.

Issue with “aborts”. We first observe that there is an inherent issue when constructing distributed
FSwA signatures. Just like earlier constructions in the discrete log setting [BN06, NKDM03] previous
FSwA multi-signatures ask all parties to start doing what is essentially a single-user FSwA signature,
and always reveal the first “commit” message of the underlying Σ-protocol. Then all these messages are
added up and the sum is hashed, together with the message to be signed, in order to obtain the challenge.
This means that all executions are revealed, whether they abort or not. An important issue with the
FSwA approach is that, currently there is no known general way to prove the underlying ÎŁ-protocol
zero-knowledge in case of aborts [BCK+14, §3.2], [ESS+19, §4], [BBE+18, BBE+19], [Lyu19, p.26]. As
a result, the signer should not reveal any of the aborted executions since otherwise the scheme cannot
be proved secure. This issue is not serious in a single-user scheme, since the ÎŁ-protocol is made non-
interactive in the random oracle model anyway and there is no reason why the signer would reveal aborted
executions.

In an interactive setting, the standard approach to circumvent the issue is to send a commitment
to the first ÎŁ-protocol message and only reveal it if the rejection sampling is successful. However, the
previous FSwA multi-signatures skipped this subtle step. Thus the concurrent work by Fukumitsu and
Hasegawa [FH20] (who constructed a FSwA-style multi-signature proven secure in QROM) had to rely
on an additional non-standard assumption (which they call “rejected LWE”), while publicly available
security proofs of other similar constructions [BS16, FH19, TLT19, MJ19, TE19] do not explain how to
simulate the aborted executions. Despite the lack of such discussion in the proofs there are no known
concrete attacks against the existing schemes, and it may be that one could patch the problem by making
additional non-standard assumptions, or by carefully choosing the parameter such that the additional
assumptions hold unconditionally. Still, it is paramount to strive to find protocols which can be proven
secure relying on well-established computational hardness assumptions like LWE and SIS.

1.1 Contributions

FSwA-based distributed signatures with full security proof. In this paper we construct FSwA-
type n-out-of-n distributed and multi-signature protocols solely relying on the hardness of learning with
errors (LWE) and short integer solution (SIS) problems. Our constructions can be seen as distributed
variants of the fast Dilithium-G signature scheme [DLL+18]. As a first step, we circumvent the aborts
issue mentioned above by utilizing Baum et al.’s additively homomorphic commitment scheme [BDL+18],
which is currently the most efficient construction based on lattices and relies on the hardness of Module-
LWE and Module-SIS problems. This results in a provably secure (in the classical random oracle model),
three-round n-out-of-n signature protocol DS3

3.
3 It is still an open question whether the aborts issue can instead be resolved by careful parameter choice, allowing

to simulate the rejected transcripts without any additional assumptions. But we are aware of on-going work in
this direction. If the question is answered in the affirmative our three-round protocol could be proven secure
even without a commitment. However, the use of homomorphic commitment is crucial for constructing our new
two-round protocols, which is our main contribution.

4



First two-round protocols. Previous FSwA-based multi-signatures required at least three rounds of
interaction. On the other hand, as most recent discrete log-based solutions indicate [DEF+19, KG20,
NRSW20,NRS20], two rounds is a natural goal because this clearly seems to be minimal for a distributed
signature protocol based on the Fiat-Shamir paradigm: we first need to determine what should be hashed
in order to get the challenge in the underlying ÎŁ-protocol. This must (for security) include randomness
from several players and hence requires at least one round of interaction. After this we need to determine
the prover’s answer in the Σ-protocol. This cannot be computed until the challenge is known and must
(for security) require contributions from several players, and we therefore need at least one more round.

In this paper, we show that the application of homomorphic commitment not only resolves the issue
with aborts, but also makes it possible to reduce the round complexity to two rounds. We do this by
adding a trapdoor feature to the commitment scheme (a separate contribution that we discuss in more
detail below). This results in a two-round, n-out-of-n signature protocol DS2 presented in Section 3. With
a slight modification this n-out-of-n protocol can be also turned into a two-round multi-signature scheme
in the plain public key model. We describe a multi-signature variant MS2 in Appendix D.

Our main two-round result highlights several important similarities and differences which emerge when
translating a discrete log-based protocol to lattice-based one. The approaches taken in our two-round
protocols are highly inspired by mBCJ discrete log-based multi-signature by Drijvers et al. [DEF+19] In
particular, we observe that it is crucial for two-round protocols to use message-dependent commitment
keys (as in mBCJ) instead of a single fixed key for all signing attempts (as in the original BCJ [BCJ08]),
because otherwise the proof doesn’t go through. Drijvers et al. only presented a full security proof for
the protocol in the key verification model, in which each co-signer has to submit a zero-knowledge proof
of knowledge of the secret key. Our protocols confirm that a similar approach securely transfers to the
lattice setting even under different security models: distributed n-out-of-n signature with dedicated key
generation phase, and multi-signature in the plain public key model.

Lattice-based trapdoor commitment. As mentioned above, we turn Baum et al.’s scheme into a
trapdoor commitment in Section 4, so that the two-round protocols DS2 and MS2 are indeed instan-
tiable with only lattice-based assumptions. We make use of the lattice trapdoor by Micciancio and Peik-
ert [MP12] to generate a trapdoor commitment key in the ring setting. The only modification required
is that the committer now samples randomness from the discrete Gaussian distribution instead of the
uniform distribution. This way, the committer holding a trapdoor of the commitment key can equiv-
ocate a commitment to an arbitrary message by sampling a small randomness vector from the Gaus-
sian distribution. Such randomness is indeed indistinguishable from the actual randomness used in the
committing algorithm. Since only a limited number of lattice-based trapdoor commitment schemes are
known [GSW13,CHKP10,DM14,GVW15,LNTW19] our technique may be of independent interest.

1.2 Technical Overview

Our protocols are based on Dilithium signature scheme, which works over rings R = Z[X]/(f(X)) and
Rq = Zq[X]/(f(X)) defined with an appropriate irreducible polynomial f(X) (see preliminaries for more
formal details). Here we go over the core ideas of our construction by considering simple 2-out-of-2 signing
protocols. The protocols below can be generalized to an n-party setting in a straightforward manner. We
assume that each party Pj for j = 1, 2 owns a secret signing key share sj ∈ R`+k which has small
coefficients, and a public random matrix Ā = [A|I] ∈ R

k×(`+k)
q . The joint public verification key is

defined as pk = (A, t), where t = Ā(s1 +s2) mod q. In the actual protocols pk also needs to be generated
in a distributed way, but here we omit the key generation phase for brevity’s sake.

Naive approach. We first present a naive (insecure) way to construct a 2-party signing protocol from
FSwA. If the reader is familiar with CoSi Schnorr multi-signature [STV+16] this construction is essentially
its lattice-based, 2-out-of-2 variant. In this protocol the parties Pj for j = 1, 2 involved in signing the
message Âľ work as follows.
1. Pj samples a randomness yj from some distribution D`+k defined over R`+k (which is typically the

uniform distribution over a small range or discrete Gaussian), and then sends out the first message
of FSwA wj = Āyj mod q.

2. Pj locally derives a joint challenge c ← H(w1 + w2, µ, pk) and performs the rejection sampling
RejSamp(csj , zj) with zj = csj + yj ; if the result of RejSamp(csj , zj) is “reject” then Pj sets zj := ⊥.
After exchanging zj ’s if z1 = ⊥ or z2 = ⊥ (i.e., either of the parties aborts), then the protocol restarts
from the step 1.

5



DS3 executed by P2(s2, pk = (A, t), ck, Âľ)

y2 ←$D`+k; w2 ← Āy2

com2 ← Commitck(w2; r2)

h2 ← H(com2) h2

h1

com2

Check H(com1) = h1
com1

c← H(com1 + com2, µ, pk)
z2 ← cs2 + y2

If RejSamp(cs2, z2) = 0:
(z2, r2)← (⊥,⊥)

z2, r2

If z1 = ⊥ ∨ z2 = ⊥ : restart z1, r1

Output (com1 + com2, z1 + z2,

r1 + r2) as a signature

DS2 executed by P2(s2, pk = (A, t), Âľ)

y2 ←$D`+k; w2 ← Āy2

ck ← H(µ, pk)

com2 ← Commitck(w2; r2) com2

com1

c← H(com1 + com2, µ, pk)
z2 ← cs2 + y2

If RejSamp(cs2, z2) = 0:
(z2, r2)← (⊥,⊥)

z2, r2

If z1 = ⊥ ∨ z2 = ⊥ : restart z1, r1

Output (com1 + com2, z1 + z2,

r1 + r2) as a signature

Fig. 1. Comparison of different instantiations of FSwA-based 2-party signing protocols

3. Each party outputs (w, z) := (w1 + w2, z1 + z2) as a signature on Âľ.
Note that the rejection sampling step is needed to make the distribution of zj independent of a secret
sj . The verification algorithm checks that the norm of z is small, and that Āz− ct = w (mod q) holds,
where the challenge is recomputed as c← H(w, µ, pk). One can easily check that the signature generated
as above satisfies correctness, thanks to the linearity of the SIS function fĀ(x) = Āx mod q. However, we
observe that an attempt to give a security proof fails due to two problems. Suppose the first party P̃1 is
corrupt and let us try to simulate the values returned by honest P2, whenever queried by the adversary.

First, since the protocol reveals w2 whether P2 aborts or not, the joint distribution of rejected tran-
script (w2, c,⊥) has to be simulated. As mentioned earlier, there is no known way to simulate it; in
fact, the honest verifier zero knowledge (HVZK) of FSwA is only proven for “non-aborting” cases in
the original work by Lyubashevsky [Lyu09, Lyu12, Lyu19] and its successors. Note that the obvious fix
where players hash the initial messages and only reveal them if there is no abort will not work here: the
protocols need to add the initial messages together before obtaining the challenge c in order to reduce
signature size, only the sum is included in the signature. So with this approach the initial messages must
be known in the clear before the challenge can be generated.

The second problem is more generic and could also occur in the standard Fiat–Shamir-style two party
signing: if P2 sends out w2 first, then the simulator does not know w1. In FS-style constructions, the usual
strategy for signing oracle query simulation is to first sample a challenge c by itself, generate a simulated
transcript (w2, c, z2) by invoking a special HVZK simulator on c, and then program the random oracle
H such that its output is fixed to a predefined challenge c. In the two-party setting, however, derivation
of the joint challenge c = H(w1 + w2, ¾, pk) requires contribution from P̃1 and thus there is no way
for the simulator to program H in advance. Not only the proof doesn’t go through, but also this naive
construction is amenable to a concrete attack, which allows malicious P̃1 to create a valid forgery by
adaptively choosing w1 after seeing w2. In Appendix E we describe this attack relying on a variant of
Wagner’s generalized birthday problem [Wag02,HJ10].

Homomorphic commitment to simulate aborts. We now present an intermediate provably secure
protocol that circumvents the above issues. See DS3 in Fig. 1. To address the first issue with aborts, each
player Pj now commits to an initial ÎŁ-protocol message wj using an additively homomorphic commitment

6



comj . Thanks to the hiding property, each party leaks no useful information about wj until the rejection
sampling is successful, and thus it is now possible to simulate a rejected transcript (comj , c,⊥). Then Pj
broadcasts a hash based commitment to comj , to deal with the second issue. Once all parties have done
this, comj ’s are revealed in the next round and checked against the hashes. Once the comj ’s are known,
they can be added together in a meaningful way by the homomorphic property, and we then hash the
sum and the message to get the challenge. The verification now receives a signature consisting of three
elements (com, z, r) and simply checks that Āz− ct (mod q) and r form a correct opening to com, where
the challenge is recomputed as c← H(com, µ, pk).

We note that the extra round for hash commitment is a standard technique, previously used in
multiple three-round protocols, such as Nicolosi et al. [NKDM03] and Bellare and Neven [BN06] in the
discrete log setting, and Bansarkhani and Sturm [BS16] in their FSwA-based instantiation. This way, the
simulator for honest P2 can successfully extract corrupt P̃1’s share com1 by keeping track of incoming
queries to H (when modeled as a random oracle), and program H such that H(com1 + com2, Âľ, pk) := c
before revealing com2. For the completeness, in Appendix F we provide a formal security proof for DS3
by showing a reduction to Module-LWE without relying on the forking lemma [PS00,BN06]. This is made
possible by instantiating the construction with unconditionally binding commitment, which allows us to
avoid rewinding the adversary and apply the lossy identification technique by Abdalla et al. [AFLT16].

One efficiency issue is, that the protocol has to be restarted until all parties pass the rejection sampling
step simultaneously. All previous FSwA-based multi-signatures also had the same issues, but we can
mitigate by running sufficiently many parallel executions of the protocol at once, or by carefully choosing
the parameters for rejection sampling. To further reduce the number of aborts, we chose to instantiate
the protocol with Dilithium-“G” [DLL+18] instead of the one submitted to NIST competition [LDK+19].

Trapdoor commitment to avoid the extra round. Although DS3 is secure, the first round of
interaction may seem redundant, since the parties are essentially “committing to a commitment”. We
show that the extra hash commitment round can be indeed dropped by adding a trapdoor feature to the
commitment scheme, which allows the so-called straight-line simulation technique by Damg̊ard [Dam00].
We present our main two-round protocol DS2 in Fig. 1. This way, the simulation of honest P2 does not
require the knowledge of corrupt P̃1’s commitment share; instead, the simulator can now simply send
a commitment com2 (to some random value) and then later equivocate to an arbitrary value using the
known trapdoor td associated with a trapdoored commitment key tck. Concretely, the simulator need not
program the random oracle this time, and instead derives a challenge c← H(com1 + com2, µ, pk) as the
real honest party would do. Now the simulator invokes a (special) HVZK simulator with c as input, to
obtain a transcript (w2, c, z2). With some constant probability it equivocates com2 to w2, or otherwise
sends out ⊥ to simulate aborts. We also stress that the per-message commitment key ck ← H(µ, pk) is
crucial in the two-round protocol; if a single ck is used across all signing attempts, then a concurrent
attack similar to the one against the naive construction becomes applicable (see Appendix E). Unlike
the three-round protocol, we present a security proof relying on the forking lemma and we reduce the
security to both Module-SIS and Module-LWE assumptions; since a trapdoor commitment can at most
be computationally binding, we must extract from the adversary two different openings to the same
commitment in order to be able to reduce security to the binding property. We leave for future work a
tighter security proof, as well as a proof in the quantum random oracle model.

Two-round multi-signature. We can now convert to a two-round multi-signature scheme in the plain
public key model: following Bellare–Neven [BN06] the protocol now generates per-user challenges cj =
H(tj ,

∑
j comj , µ, L) for each user’s public key tj ∈ L, instead of interactively generating the fixed joint

public key t in advance. The verification algorithm is adjusted accordingly: given (com, z, r) and a list
of public keys L, the verifier checks that Āz −

∑
j cjtj (mod q) and r form a correct opening to com,

where cj ’s are recomputed as in the signing protocol. Appendix D formally describes our MS2 protocol
with security proof.

1.3 Related Work

The FSwA paradigm was first proposed by Lyubashevsky [Lyu09, Lyu12] and many efficient signa-
ture schemes following this framework have been devised, such as GLP [GLP12], BLISS [DDLL13],
Dilithium [LDK+19] and qTESLA [BAA+19]. Bansarkhani and Sturm [BS16] extended GLP signature
and proposed the first multi-signature following the FSwA paradigm. Since then several variants appeared
in the literature: four-round protocol with public key aggregation [MJ19], three-round protocol with tight
security proof [FH19] and proof in QROM [FH20], ID-based blind multi-signature [TLT19] and ID-based

7



proxy multi-signature [TE19]. However, as mentioned earlier the security proofs for all these multi-
signatures are either incomplete or rely on a non-standard heuristic assumption. Choi and Kim [CK16]
proposed a linearly homomorphic multi-signature from lattices trapdoors. Kansal and Dutta [KD20] con-
structed a single-round multi-signature scheme relying on the hardness of SIS, which was soon after
broken by Liu et al. [LTT20]. Several lattice-based threshold ring signatures exist in the literature, such
as Cayrel et al. [CLRS10], Bettaieb and Schrek [BS13], and Torres et al. [TSSK20]. Döroz et al. [DHSS20]
devised lattice-based aggregate signature schemes relying on rejection sampling. Very recently, Esgin et
al. [EEE20] developed FSwA-based adaptor signatures with application to blockchains.

Our two-round protocols rely on trapdoor commitment to enable the straight-line simulation of ZK.
The trick is originated in a concurrent ZK proof by Damg̊ard [Dam00] and similar ideas have been exten-
sively used in the ZK literature [BKLP15,CPS+16,COSV17b,COSV17a], to turn honest verifier ZK proof
into full-fledged ZK. Moreover, recent efficient lattice-based ZK proofs [dLS18,ESS+19,YAZ+19,BLS19,
ESLL19] also make use of Baum et al.’s additively homomorphic commitment. The issue of revealing the
first “commit” message in the FSwA framework has been also discussed by Barthe et al. [BBE+18] in the
context of masking countermeasure against side-channel attacks, and they used Baum et al.’s commitment
to circumvent the issue. The homomorphic lattice-based trapdoor commitment could also be instantiated
with GSW-FHE [GSW13], homomorphic trapdoor functions [GVW15], Chameleon hash [CHKP10,DM14]
or mercurial commitment [LNTW19].
Comparison with Bendlin et al. [BKP13] An entirely different approach to constructing threshold
signatures based on lattices relies not on the Fiat–Shamir with aborts paradigm, but on GPV hash-and-
sign signatures [GPV08]. This approach was introduced by Bendlin et al. in [BKP13], who described
how to implement Peikert’s hash-and-sign signatures [Pei10] in a multiparty setting. Compared to the
approach in this paper, it has the advantage of realizing the same distributed signature scheme (e.g., with
the same size bound for verification) independently of the number of parties, and in particular, signature
size does not grow with the number of parties. Moreover, it supports more general access structure than
the full threshold considered in this paper (although their protocol does not withstand ";"""date"",""2021-03-04T10:58:10Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2021-03-04T10:58:10Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.20 (TeX Live 2019/Debian) kpathsea version 6.3.1""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2021-03-04T10:58:10Z""
""created"",""2021-03-04T10:58:10Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2021-03-04T10:58:10Z""
""resourceName"",""1110.pdf""
""Author"",""""
""producer"",""pdfTeX-1.40.20""
""pdf:docinfo:producer"",""pdfTeX-1.40.20""
""pdf:unmappedUnicodeCharsPerPage"",""2"",""0"",""0"",""0"",""4"",""5"",""4"",""16"",""37"",""40"",""91"",""2"",""2"",""23"",""23"",""0"",""26"",""59"",""28"",""31"",""0"",""0"",""0"",""0"",""59"",""13"",""20"",""12"",""41"",""7"",""21"",""6"",""17"",""21"",""16"",""29"",""24"",""1"",""11"",""6"",""25"",""60"",""42"",""7""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2021-03-04T10:58:10Z""
""Last-Modified"",""2021-03-04T10:58:10Z""
""dcterms:modified"",""2021-03-04T10:58:10Z""
""title"",""""
""Last-Save-Date"",""2021-03-04T10:58:10Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2021-03-04T10:58:10Z""
""meta:save-date"",""2021-03-04T10:58:10Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.20 (TeX Live 2019/Debian) kpathsea version 6.3.1""
""Content-Length"",""868381""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""44""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""2234"",""1797"",""4460"",""4458"",""4285"",""2807"",""4447"",""4258"",""2378"",""2686"",""2568"",""3511"",""2706"",""2937"",""2408"",""4384"",""4083"",""3286"",""3426"",""2319"",""4302"",""4278"",""4563"",""1385"",""1952"",""1303"",""3225"",""2903"",""2913"",""2772"",""1875"",""1502"",""3719"",""1817"",""2238"",""2798"",""3296"",""3316"",""1482"",""3757"",""2964"",""1494"",""535"",""1854""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2021-03-04T10:58:10Z""
";https://scholar.google.ch/scholar?start=570&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098743-52;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Blockchains for the Governance of Common Goods;P Poux, P de Filippi, S Ramos ; … of the 1st International Workshop on …, 2020  dl.acm.org;;"… 5 The Role of Oracles While it can be used as a governance tool, a blockchain … ac- counted for

by a blockchain-based system after it has been recorded onto the blockchain. This is generally

achieved through the use of so-called ""oracle"" systems, specifically designed to provide …";Autres articles;;[PDF] archives-ouvertes.fr;https://hal.archives-ouvertes.fr/hal-03098598/document;"
HAL Id: hal-03098598
https://hal.archives-ouvertes.fr/hal-03098598

Submitted on 6 Jan 2021

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L’archive ouverte pluridisciplinaire HAL, est
destinĂŠe au dĂŠpĂ´t et Ă  la diffusion de documents
scientifiques de niveau recherche, publiĂŠs ou non,
émanant des établissements d’enseignement et de
recherche français ou Êtrangers, des laboratoires
publics ou privĂŠs.

Blockchain for the Governance of Common Good
PhilĂŠmon Poux, Primavera de Filippi, Simona Ramos

To cite this version:
PhilĂŠmon Poux, Primavera de Filippi, Simona Ramos. Blockchain for the Governance of Common
Good. Proceedings of 1st International Workshop on Distributed Infrastructure for Common Good
(DIGC ’20)., Dec 2020, Online, France. �hal-03098598�

https://hal.archives-ouvertes.fr/hal-03098598
https://hal.archives-ouvertes.fr


Blockchains for the Governance of
Common Goods

PhilĂŠmon Poux
philemon.poux@gmail.com

Universite Paris II, CERSA, CRED,ENPC France

Primavera de Filippi
CNRS, France;

Harvard University, Berkman-Klein Center, USA

Simona Ramos
Universitat Pompeu Fabra, Barcelona, Spain

Nokia Bell Labs France

Abstract
This paper analyses the use of blockchain technol-
ogy to support the governance of commons-pool re-
sources, as studied by Elinor Ostrom. It argues that
the technological guarantees of blockchain technol-
ogy —in terms of ex-ante automation and ex-post
verification— can replace the traditional require-
ments of monitoring and sanctioning. Despite its
own limitations and challenges, this novel approach
to governance could provide new opportunities for
experimentation in the context of commons-pool re-
sources.

1 Introduction
Although originally invented as the underlying in-
frastructure for the Bitcoin cryptocurrency [15],
blockchain technology has progressively evolved
into a general-purpose technology that can support
a large variety of applications other than monetary
transactions. As a distributed ledger operating on
top of a peer-to-peer network, a blockchain relies
on cryptographic primitives and a consensus pro-

tocol in order to maintain a database that is logi-
cally centralized, yet technically decentralized. With
the development of more sophisticated blockchains
with smart contracts capabilities, novel opportuni-
ties have emerged to coordinate agents in secure and
distributed manner. One particularly interesting af-
fordance of blockchain technology is the extent to
which it enables communities to govern themselves
through a series of predefined code-based rules in or-
der to reach mutual consensus without the interfer-
ence or the need for a central authority[12].

This paper investigates the use of blockchain tech-
nology for the governance of Common-Pool Re-
sources (CPRs). It shows that, while a distributed
system cannot easily address the challenges of mon-
itoring and sanctioning (which are often regarded
as key pillars for the proper governance of CPRs),
blockchain technology could largely bypass these
challenges by way of its technological guarantees.
As such, the technology could bring new perspec-
tives to the traditional analysis and practices of CPR
governance.

The paper is structured as follow: After present-
ing the core characteristics of blockchain technology

1

philemon.poux@gmail.com


(section 2), we introduce the traditional work of Os-
trom on the governance of Common-Pool Resources
(section 3) and subsequently analyse the extent to
which some of the components of CPR governance
could be simplified or even enhanced by means of a
blockchain-based infrastructure. The paper will fo-
cus in particular on the opportunities to move away
from the need of monitoring and sanctioning, with
the possibility to rely instead on a system of ex-ante
automation and ex-post verification (section 4). Fi-
nally, the paper will conclude by discussing the lim-
itations of a purely blockchain-based approach to
CPR governance, in light of the necessity to account
for real world events (section 5), as well as the chal-
lenges inherent to blockchain technology more gen-
erally (section 6).

2 Blockchains in a Nutshell

A blockchain is an append-only distributed ledger
that records transactions in a transparent, verifiable
and permanent manner by storing them into a se-
quence (or ""chain"") of blocks. The content of a
blockchain is secured through cryptographic primi-
tives (e.g. public-private key cryptography and hash-
ing functions) so that, once a transaction has been
recorded into a block, it cannot be tampered with
without such a violation being detected by all the net-
work nodes [26]. The tamper-resistant properties of a
blockchain are crucial to guarantee the integrity and
authenticity of all data stored into this decentralized
database.

While the first generation of blockchains were
mostly used for the exchange of cryptocurrencies
like Bitcoin, many blockchains today also make
it possible to engage into a series of more com-
plex transactions by incorporating pieces of code di-
rectly into the blockchain. These programs —which
are generally referred to as ""smart contracts""[25] or
DApps (Decentralized Applications)— are executed
in a distributed manner by all network nodes. The
benefit of smart contracts over traditional software
code is that their execution cannot be affected (e.g.
modified or terminated) by any single node. In fact,
all nodes involved in the verification of blockchain

transactions are also responsible for the proper ex-
ecution of smart contracts. These applications are
thus often described as ""trustless systems"" because
they create the possibility of establishing a trust
layer between parties that do not know or trust each
other[27].

However, considering that smart contracts oper-
ate on top of a blockchain-based network, their
execution is dictated by the rules of the underly-
ing blockchain protocol. Hence, the operations
of a smart contract could potentially be affected
by changes in the blockchain protocol itself. Al-
though theoretically immutable, the rules governing
a blockchain can be changed by consensus among all
network nodes. This is where the issue of blockchain
governance comes in.

Broadly speaking, blockchain governance is the
process by which changes to the blockchain proto-
col are decided upon and implemented. While the
process may vary from blockchain to blockchain, the
operations of a blockchain generally rely on a special
group of network nodes —the miners— that are re-
warded by the blockchain protocol for their contribu-
tion to the network[28]. These nodes are responsible
for creating new blocks of transaction, in accordance
with the protocol rule.

Yet, this is not to say that blockchains are gov-
erned only and exclusively by code. The major-
ity of blockchain-based networks are governed by
a combination of on-chain and off-chain rules. On-
chain rules are technical rules embedded directly in
the code or the protocol of a blockchain-based net-
work (e.g the economic incentives, consensus algo-
rithm, etc.) and are thus automatically enforced by
the underlying infrastructure. As noted by De Fil-
ippi&McMullen [5], on-chain rules are a form of
""governance by the infrastructure"". Off-chain rules
are social or institutional rules that a blockchain
community has put into place in order to elabo-
rate the rules that will subsequently be codified into
the technological infrastructure, as well as the pro-
cedures to change these rules. As such, off-chain
rules refer to the ""governance of the infrastruc-
ture"", including all the procedures and rules capa-
ble of influencing the operations and governance of a
blockchain-based system, even if that means infring-

2



ing the original protocol rules[23].

3 Institutional Analysis and De-
velopment Framework and
Common-Pool Resources Gov-
ernance

Ostrom dedicated her life to the study of CPRs.
Although she mostly focused on natural common-
pool resources, she also extended her work the gov-
ernance of information commons and in particular
open-source software [7].

Drawing from years of research by Ostrom and
other members of the Bloomington School on the
management of Common-Pool Resources (CPRs),
Rules, Games, and Common-Pool Resources[20]
has become a landmark contribution to the study
of commons-based governance. The book shows
—theoretically, experimentally and empirically—
that, without proper communication and coordina-
tion mechanisms, groups often end up with a sub-
optimal use of CPRs, mostly due to over-exploitation
or under-provision. Conversely, when given the
means to better coordinate, many groups demon-
strated a near optimal use of the CPRs. Crucial to
this outcome is the ability for a community to moni-
tor the behavior of all of its members, along with the
capacity to sanction the defectors.

Through this work, Ostrom and her colleagues
developed the Institutional Analysis and Develop-
ment (IAD) Framework [20] “to understand the
ways in which institutions operate and change over
time”[14]. It focuses on an action-situation which is
the “black box” where policy choices are made[14].
In other words, the action-situation is the system
studied by IAD analysts, it comprises the environ-
ment, the actors and all relationships (in)between ac-
tors and their environment. The purpose of the IAD
is to reveal and describe this “black box” mecha-
nisms by identifying all of its components (actors,
environment, rules, institutions. . . ).

They identified 8 design principles[16] which
could each contribute to a more sustainable man-
agement of CPRs (although none of them are not

Figure 1: IAD and Rules: depiction of an action-
situation. Adapted from Figure 7.1 from [18, p.189]

stricto sensu necessary). The following list of prin-
ciples has been refined by Cox et al. [2] (and en-
dorsed by Ostrom [19]): (DP1) User and resource
boundaries (DP2) Congruence with local conditions
(DP3) Appropriation and provision (DP4) Collec-
tive choice arrangement (DP5) Monitoring users and
the resource (DP6) Gradual sanctions (DP7) Conflict
resolution mechanisms (DP8) Nested enterprise

Ostrom has often insisted that the IAD frame-
work is an analytic framework that merely provides a
“Grammar of Institutions” [3] to help disentangle the
complexities of roles and interactions in any given
institutional arrangement.The IAD grammar is made
of 7 types of rules characterizing the relationships
between the different actors involved in a particular
action-situation. Each of these rules can be imple-
mented in multiple ways depending on the context
and contingencies. The rules and the action-situation
are summarized Figure 1. How blockchains can help
implement particular configurations of these rules is
discussed below.

Some authors have already been analysing the po-
tential of blockchain technology in light of this spe-
cific field of research . In particular, Rozas et al.
[24] have shown that many blockchains were com-
patible with the 8 design principles identified by Os-
trom for the governance of digital commons. They
identified 6 main affordances of blockchain technol-
ogy that make it particularly suitable for the gover-
nance of digital or immaterial commons-based peer-

3



production resources. Each of the design princi-
ples are then checked against the affordances show-
ing how they can be properly reproduced on a
blockchain.

In an Ostrom Workshop, Howell&Potgieter[8]
used the IAD framework to analyse blockchains
as commons-pool resources, using Bitcoin and
Ethereum as the two main case studies. They found
that the 8 design principles for CPR governance are
only partially met within these networks. Yet, their
conclusion is that these limitations are not intrinsic to
blockchain technology, but rather pertain to the spe-
cific implementations thereof.

And most importantly, Cila et al.[1] extensively
discuss the dilemmas that could result from a rely-
ing on a blockchain governance tool for a energy
commons in a fictional community. We here wish to
complement their forward planning work while ac-
knowledging the importance of their conclusions and
in particular that these dilemmas require political de-
cisions and offer no clear solutions.

This paper aims to move beyond a purely descrip-
tive, prospective or analytical analysis of blockchain
technology in the context of CPR governance. It
proposes a more normative approach, claiming that
some of the components of CPR governance could
be delegated to a blockchain, resulting a new set
of action-situations that rely less on monitoring and
sanctioning and more on ex-ante automation and ex-
post verification as a means to reduce the likelihood
of opportunistic behaviours.

4 From a “trust-based” to a
“proof-based” system

As previously discussed, Ostrom[17] argued that de-
centralized yet coordinated action may be difficult to
achieve without proper monitoring or enforcement.
Monitoring is necessary to ensure that all actors re-
main accountable to each other and continue to act
in accordance with the general system of rules they
have agreed to. In a centralized setting, this is gen-
erally referred to as ""surveillance"". Enforcement is
necessary to ensure that all actors who diverge from
these rules will be sanctioned, and potentially even

banned or excluded from the system. This is usually
referred to as ""policing"".

Blockchain technology provides a decentralized
solution to precisely both of these challenges. While
decentralized monitoring would be problematic as it
would require an excessive degree of transparency,
with an ensuing invasion of privacy for all of the par-
ticipants, the same benefits can be achieved in a de-
centralized setting by means of ex-post verifiability,
using blockchain technology to record (proofs of) in-
formation in an encrypted and tamper-resistant man-
ner —so that the information does not have to be
disclosed to the public, but the content and integrity
thereof can subsequently be verified by the relevant
third parties[24]. Enforcement — which is generally
done ex-post (i.e. after the fact)— can be achieved in
a decentralized setting by means of ex-ante automa-
tion, using a system of smart contracts for the trusted
execution of specific agreements, automatically exe-
cuted by the underlying technology[6].

Accordingly, the benefits of blockchain technol-
ogy for the governance of CPRs are essentially
twofold. Through ex-post verifiability, blockchain
technology could increase confidence in the institu-
tional arrangements established by the community
members managing and operating CPRs, restoring
the trust level conferred to these institutional ar-
rangements while simultaneously reducing the need
for global scrutiny and oversight. Through ex-ante
automation, the use of blockchain technology could
facilitate new forms of cooperation amongst these
community members, providing for a trusted and
coordinated mechanism of bottom-up collaboration
that does not rely on any centralized superpower
or other trusted authority. Hence, we argue that
blockchain technology could be a relevant tool for
the governance of CPRs, without the need to imple-
ment mechanisms of monitoring and sanctioning.

Yet, the creation of a common framework or
infrastructure on top of which such decentralized
mechanisms of ex-ante automation and ex-post veri-
fication can be built would require all relevant stake-
holders to agree upon a common set of rules gov-
erning their interactions with one another —a ""so-
cial contract"" of some sort[10]. Such an agreement
would have to be voluntarily adopted by all relevant

4



community members involved in the management of
the relevant CPRs.

While it is unlikely that the whole governance
structure of a particular CPR can be codified in its
entirety into a blockchain-based infrastructure, some
of its components could nonetheless be transposed
into a series of technological guarantees that would
provide a greater degree of confidence in the system.
Hence, by analysing the institutional arrangements
of a particular community managing CPRs through
the IAD framework, it might be possible to iden-
tify (a) the specific components or rules that could
be (partially) codified into a blockchain-based sys-
tem, in order to ensure full compliance with these
rules through ex-ante automation, and (b) the com-
ponents whose execution could be recorded onto a
blockchain, in order to provide for ex-post verifiabil-
ity.

Using the IAD framework to analyse the gov-
ernance of CPRs would help identify the different
types of rules constituting the action-situations at
play within a particular community. The community
governing these CPRs could then decide, to imple-
ment some aspects of their governance system into a
blockchain-based system. Such a decision could be
driven by a desire to enhance the transparency and
accountability of the system, or make it more effi-
cient by reducing the costs of monitoring and sanc-
tioning.

Examples of such governance components that
could be delegated to a blockchain include:

• ""boundaries"", ""position"" and ""choice"" rules
(e.g. the identity of the relevant stakeholders
and their respective functions and roles in the
management of CPRs)1

• ""governance"" rules governing the interactions
of community members (e.g. rules govern-
ing service provision, monitoring, and manage-
ment);

• ""scope"" rules that must be respected by commu-
nity members (e.g. administrative procedures
and its timing, maintenance protocols, etc.);

1Even if they do not add value in and of themselves, the es-
tablishment of these basic rules are necessary conditions for the
proper implementation of the other rules.

• ""dispute resolution"" rules (e.g. the procedures
for the resolution of disputes arising between
community members and the procedures for the
application of sanctions, if any)

The codification of these components of the IAD
framework into a blockchain-based system would
enable relevant community members to have a clear
insight into the institutional arrangements of the
community, as well as their respective roles and re-
sponsibilities. Most importantly, to the extent that
these rules would be automatically executed by the
underlying technology, the need for monitoring and
sanctioning would be lessened, given that relevant
parties would be unable to infringe these rules in the
first place.

With regard to the components that cannot be au-
tomated into code, it would still be possible to record
the proofs associated with particular operations into
a blockchain-based system (e.g. proof-of-process) in
order to ensure the ex-post verifiability of administra-
tive procedures by each responsible party. By record-
ing the fingerprint (or hash) of specific documents
or data sets onto a blockchain on an on-going basis,
one can create an immutable and certified audit trail
of relevant events, which can be verified at a later
stage. In case of a dispute, these proofs would en-
able the relevant stakeholders and/or government au-
thorities to verify whether the community rules have
been properly observed by the responsible parties by
simply comparing the hash of the presented docu-
ments or data sets, with those that have been previ-
ously recorded onto the blockchain. Such a solution
would contribute to creating more transparency and
accountability into the system, without unduly jeop-
ardizing the privacy or the confidentiality of sensitive
information.

For instance, Provenance is a blockchain-based
application that allows for the tracking of the ori-
gin and the subsequent chain of custody of materials,
from their source to their point of sale[21]. Prove-
nance has already been used in the context of CPRs
with a pilot using blockchain technology for tracing
yellowfin and skipjack tuna fish in Indonesia from
catch to consumer —thus contributing to guarantee-
ing the source of the fish and the sustainability of the
production and commercialisation cycle. A more ad-

5



vanced system could rely on a series of automated
code-based rules to govern the interactions between
the various actors involved in the supply chain, e.g.
by specifying the conditions for the delivery of ma-
terial and automating the rules that govern the corre-
sponding payment to each relevant actor.

In short, the governance of CPRs could be
achieved in a more decentralized manner by using a
blockchain-based system as a common framework or
infrastructure on top of which decentralized mecha-
nisms of ex-ante automation and ex-post verification
can be built. As such, blockchain technology could
contribute to the proper implementation of a commu-
nity’s governance rules in a more efficient and cost-
effective manner, while ensuring that such CPRs are
well-managed and protected against human error and
misconduct.

5 The Role of Oracles

While it can be used as a governance tool, a
blockchain-based system cannot be the sole driver
for the governance CPRs, it can only serve as a com-
plement to an existing governance structure. In par-
ticular, in the context natural CPRs, much of the in-
formation is external and can only be properly ac-
counted for by a blockchain-based system after it has
been recorded onto the blockchain. This is generally
achieved through the use of so-called ""oracle"" sys-
tems, specifically designed to provide real-world in-
formation to the relevant smart contracts.

As previously noted, a blockchain is a “confidence
machine” [4] that does not, however, completely
eliminate the need for trust. Using a blockchain-
based system for ex-ante automation or ex-post ver-
ifiability only makes sense provided that the data
recorded on the blockchain has been properly cer-
tified and authenticated by a trustworthy party This
is commonly referred to as the problem of garbage-
in/garbage-out, i.e. the reliability of a blockchain-
based system only goes as far as the accuracy of the
data it has been fed with.

One way to achieve a higher degree of accuracy
for external data would be to require multiple ora-
cles to provide the requested information and/or to

request trusted third-parties (e.g. certification author-
ities, or community members with a particular rep-
utation or authority) to validate the information pro-
vided via a multiple signatures (multisig) system2. In
this way, the oracles would not be able to lie or pro-
vide false information to the blockchain (without the
collusion of a majority of the oracles or verifiers).

Let us consider an example to illustrate this point.
In order to preserve the atmosphere from excessive
carbon emissions, the European Union (EU) has es-
tablished an Emission Trading Scheme (EU-ETS)
for exchanging CO2 emission rights in the EU. In
light of the high costs of monitoring and sanction-
ing in such an international arena, proposals have
been made to implement such a carbon credit mar-
ket onto a blockchain-based system [11], in order
to benefit from more transparency and traceability,
while automating the payment and transfer of deeds.
However, this can only work if participants are con-
fident that the permits they buy are legitimate and
recognized by the EU. Hence, there is a need for a
trusted authority (or oracle) responsible for issuing
and assigning the original permits to the relevant ac-
tors. While this would require the approval of all par-
ticipating countries, once such information has been
provably recorded onto a blockchain, the automation
and verification capabilities of the technology would
allow for a more transparent and seamless carbon
credits market.

6 Choice Levels and Implemen-
tation Challenges

Blockchains offer innovative solutions for the gov-
ernance of CPRs. However, it is important to
bear in mind that the use of blockchain technol-
ogy also comes along with a set of technical con-
straints and risks. First of all, although blockchains
are generally regarded as secure and tamper-proof
databases, there remain many theoretical challenges
to their resilience and integrity [13] Yet, in addi-

2A multi-sig system is one where multiple parties must sign
off a particular transaction ifor it to be regarded as effective. They
can be implemented on a variety of blockchains, with different
conditions and restrictions.

6



tion to these technical challenges, blockchain tech-
nology also face a series of important governance
challenges.

The IAD framework identifies three embedded
levels of rules: operational level rules that govern
day-to-day operations and decision-making proce-
dures; collective choice level rules that determine
how rules can be changed at the operational level,
and constitutional level rules that stipulate how rules
are made at the collective choice level[14].

The interplay between these different rules is an
essential component of any governance system. In
particular, Rahman et al.[22] note that most of the
failures in the management of natural common-pool
resources are often traced back to existing gaps in
these inter-levels relationships. If a blockchain-
based system were to be used for the governance
of CPR at any of these three level, one would need
to make sure that the system does not contribute to
widening these gaps.

When introducing a blockchain based tool in the
action-situation, it affects all three levels. Oper-
ational level rules could be codified into a smart
contract to facilitate the automation of many rou-
tine processes and daily tasks. Governance rules to
upgrade or modify the operations of a smart con-
tract would instead fall into the category of collec-
tive choice level rules. Howell&Potgieter [9] insist
that these must include cancellation and dispute res-
olution mechanisms in case of unforeseen problems.

Collective choice level rules are especially impor-
tant in the context of a blockchain-based system,
given that the codification of agreed-upon commu-
nity rules into a formal language may not always re-
flect accurately the original intentions of the parties.
Similarly, dispute resolution mechanisms could as-
sume a crucial role in guaranteeing the legitimacy of
such a blockchain-based system, in that they allow
for community members to express their views on
the interpretation of operational level rules, poten-
tially proposing amendments and ideally reaching an
agreement on a common interpretation of these rules.
In our case, the constitutional level rules are those en-
shrined directly into the protocol of the blockchain
network itself.

In the case of a widely used public blockchain

(such as Bitcoin or Ethereum) the rules of the pro-
tocol are extremely difficult (although not impossi-
ble) to change. The constitutional choice level thus
becomes much larger than the action-situation, leav-
ing community members with little to no leverage
on constitutional amendment. This stands in contrast
with two of the Ostrom’s 8 design principles, namely
that “individuals affected by a resource regime shall
be authorized to participate in making and modifying
its rules” (DP3) and that “governance activities shall
be organized in multiple nested layers” (DP8)[2].
Too big a discrepancy between the scales of the lay-
ers could cause the costs of relying on a blockchain
exceding its benefits.

It is our belief that, rather than relying on
a public blockchain, a consortium blockchain —
collectively maintained and governed by all relevant
stakeholders— could potentially serve as an ideal
framework for implementing the community ""social
contract"", while retaining the capacity to make mod-
ify the constitutional setting evolve in accordance
with the community needs.

7 Conclusion

Drawing from Ostrom’s Institutional Analysis and
Development Framework, this paper has investigated
the theoretical grounds for the use of blockchain-
based system for the governance and management
of CPRs.When it comes to guaranteeing compliance
with community rules, the adoption of blockchain
technology could let go of the traditional require-
ments of “monitoring and sanctioning” to embrace
a new paradigm of ex-ante automation and ex-post
verifiability. While this would not entirely eliminate
the need for trust in the system, it could contribute to
an enhanced governance of CPRs, by increasing the
degree of confidence in the management of these re-
sources, while simultaneously reducing the amount
of policing efforts involved in the process.

Ostrom has shown that there are several examples
of communities who have successfully managed to
govern and maintain CPRs over time. Hence, we do
not advocate for a systematic adoption of blockchain
technology in that field. Yet, we argue that, in cases

7



where monitoring and sanctioning is either too hard
or costly, and in cases where the lack of confidence
and trust in governance has led to the poor manage-
ment of CPRs, the adoption of a blockchain-based
solution could prove useful. However, given the lack
of empirical data on the matter, more research in
needed to delineate the most favorable uses cases for
experimentation and the best strategies for the imple-
mentations of such a solution.

References
[1] Nazli Cila, Gabriele Ferri, Martijn de Waal,

Inte Gloerich, and Tara Karpinski. 2020. The
Blockchain and the Commons: Dilemmas in
the Design of Local Platforms. In Proceedings
of the 2020 CHI Conference on Human Fac-
tors in Computing Systems. ACM, Honolulu
HI USA, 1–14. https://doi.org/10.
1145/3313831.3376660

[2] Michael Cox, Gwen Arnold, and Sergio Vil-
lamayor TomĂĄs. 2010. A Review of Design
Principles for Community-based Natural Re-
source Management. Ecology and Society 15,
4 (2010). https://doi.org/10.5751/
ES-03704-150438

[3] Sue E. S. Crawford and Elinor Ostrom. 1995.
A Grammar of Institutions. American Po-
litical Science Review 89, 3 (Sept. 1995),
582–600. https://doi.org/10.2307/
2082975 Publisher: Cambridge University
Press.

[4] Primavera De Filippi, Morshed Mannan, and
Wessel Reijers. 2020. Blockchain as a confi-
dence machine: The problem of trust & chal-
lenges of governance. Technology in Society 62
(Aug. 2020), 101284. https://doi.org/
10.1016/j.techsoc.2020.101284

[5] Primavera De Filippi and Greg McMullen.
2018. Governance of Blockchain Systems:
Governance of and by Distributed Infrastruc-
ture. COALA (June 2018), 40.

[6] Samer Hassan and Primavera De Filippi. 2017.
The Expansion of Algorithmic Governance:
From Code is Law to Law is Code. Field
Actions Science Reports. The journal of field
actions Special Issue 17 (Dec. 2017), 88–
90. http://journals.openedition.
org/factsreports/4518 Number: Spe-
cial Issue 17 Publisher: Institut Veolia.

[7] Charlotte Hess and Elinor Ostrom. 2011. Un-
derstanding knowledge as a commons: from
theory to practice (1st mit press pbk. ed
ed.). MIT Press, Cambridge, Mass. OCLC:
731904330.

[8] Bronwyn E Howell and Petrus H. Potgi-
eter. 2019. Governance of Blockchain and
Distributed Ledger Technology Projects: a
Common-Pool Resource View. (2019), 25.

[9] Bronwyn E. Howell and Petrus H. Potgi-
eter. 2019. Governance of Smart Contracts
in Blockchain Institutions. SSRN Electronic
Journal (2019). https://doi.org/10.
2139/ssrn.3423190

[10] Takashi Inoguchi. 2017. Theoretical Underpin-
nings of a Global Social Contract. In Oxford
Research Encyclopedia of Politics.

[11] Khamila Nurul Khaqqi, Janusz J. Sikorski,
Kunn Hadinoto, and Markus Kraft. 2018. In-
corporating seller/buyer reputation-based sys-
tem in blockchain-enabled emission trading ap-
plication. Applied Energy 209 (Jan. 2018),
8–19. https://doi.org/10.1016/j.
apenergy.2017.10.070

[12] Oleksii Konashevych. 2017. The Concept of
the Blockchain-Based Governing: Current Is-
sues and General Vision.

[13] Xiaoqi Li, Peng Jiang, Ting Chen, Xiapu Luo,
and Qiaoyan Wen. 2020. A survey on the secu-
rity of blockchain systems. Future Generation
Computer Systems 107 (2020), 841–853.

[14] Michael D. McGinnis. 2011. An Introduc-
tion to IAD and the Language of the Ostrom

8

https://doi.org/10.1145/3313831.3376660
https://doi.org/10.1145/3313831.3376660
https://doi.org/10.5751/ES-03704-150438
https://doi.org/10.5751/ES-03704-150438
https://doi.org/10.2307/2082975
https://doi.org/10.2307/2082975
https://doi.org/10.1016/j.techsoc.2020.101284
https://doi.org/10.1016/j.techsoc.2020.101284
http://journals.openedition.org/factsreports/4518
http://journals.openedition.org/factsreports/4518
https://doi.org/10.2139/ssrn.3423190
https://doi.org/10.2139/ssrn.3423190
https://d";"""date"",""2020-12-07T13:21:41Z""
""pdf:PDFVersion"",""1.4""
""pdf:docinfo:title"",""Blockchain for the Governance of Common Good""
""xmp:CreatorTool"",""HAL""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""Humanities and Social Sciences/Law""
""language"",""en""
""dc:format"",""application/pdf; version=1.4""
""pdf:docinfo:creator_tool"",""HAL""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""Blockchain for the Governance of Common Good""
""modified"",""2020-12-07T13:21:41Z""
""cp:subject"",""Humanities and Social Sciences/Law""
""pdf:docinfo:subject"",""Humanities and Social Sciences/Law""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""PhilĂŠmon Poux, Primavera de Filippi, Simona Ramos""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.20 (TeX Live 2019/Debian) kpathsea version 6.3.1""
""meta:author"",""PhilĂŠmon Poux, Primavera de Filippi, Simona Ramos""
""trapped"",""False""
""meta:creation-date"",""2021-04-09T00:56:10Z""
""created"",""2021-04-09T00:56:10Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2021-04-09T00:56:10Z""
""resourceName"",""document""
""Author"",""PhilĂŠmon Poux, Primavera de Filippi, Simona Ramos""
""producer"",""PDFLaTeX""
""pdf:docinfo:producer"",""PDFLaTeX""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""Keywords"",""Verifiability, Automation, Ostrom, Common-Pool Resources Governance, Blockchains""
""access_permission:modify_annotations"",""true""
""dc:creator"",""PhilĂŠmon Poux, Primavera de Filippi, Simona Ramos""
""dcterms:created"",""2021-04-09T00:56:10Z""
""Last-Modified"",""2020-12-07T13:21:41Z""
""dcterms:modified"",""2020-12-07T13:21:41Z""
""title"",""Blockchain for the Governance of Common Good""
""Last-Save-Date"",""2020-12-07T13:21:41Z""
""pdf:docinfo:keywords"",""Verifiability, Automation, Ostrom, Common-Pool Resources Governance, Blockchains""
""pdf:docinfo:modified"",""2020-12-07T13:21:41Z""
""meta:save-date"",""2020-12-07T13:21:41Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.20 (TeX Live 2019/Debian) kpathsea version 6.3.1""
""Content-Length"",""419335""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""PhilĂŠmon Poux, Primavera de Filippi, Simona Ramos""
""dc:subject"",""Verifiability, Automation, Ostrom, Common-Pool Resources Governance, Blockchains""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""10""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""851"",""2077"",""3688"",""2964"",""3691"",""3665"",""3568"",""3685"",""2795"",""2456""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""Verifiability, Automation, Ostrom, Common-Pool Resources Governance, Blockchains""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2021-04-09T00:56:10Z""
";https://scholar.google.ch/scholar?start=600&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098831-260;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;zkrelay: Facilitating sidechains using zksnark-based chain-relays;M Westerkamp, J Eberhardt ; 2020 IEEE European Symposium …, 2020  ieeexplore.ieee.org;;"… Such trusted intermediaries are commonly referred to as Oracles and multiple forms with different …

to light clients that participate in the source blockchain's network, the target blockchain validates

the … creating assets on a target ledger that are backed by a cryptocurrency that is …";Cité 5 fois;Les 6 versions;[PDF] iacr.org;https://eprint.iacr.org/2020/433.pdf;"
zkRelay: Facilitating Sidechains using zkSNARK-based Chain-Relays

Martin Westerkamp
Service-centric Networking

Technische Universität Berlin
Berlin, Germany

westerkamp@tu-berlin.de

Jacob Eberhardt
Information Systems Engineering

Technische Universität Berlin
Berlin, Germany

jacob.eberhardt@tu-berlin.de

Abstract—We facilitate trusted cross-blockchain state proofs
by implementing a chain-relay that validates block headers
from proof-of-work blockchains. While current approaches
require proof sizes linear to the amount of blocks the state
was built on, trusted intermediaries, or economic assump-
tions, we propose the utilization of off-chain computations
through zkSNARKs to provide a cryptographically secure
and highly scalable sidechain mechanism. Multiple block
headers are included in batches and verified off-chain, while
preserving light client support. Only the validity of the off-
chain computation is verified on-chain, creating a sidechain
mechanism that requires constant verification costs and
releases the target ledger from processing and storing every
single block header of the source blockchain. We provide a
prototypical implementation that facilitates the verification
of 504 Bitcoin headers in a single proof on Ethereum using
the ZoKrates framework. Hereby, the verification costs are
reduced by a factor of 187 compared to current approaches
such as BTC Relay.

Index Terms—DLTs, Blockchain interoperability, Sidechains,
Chain-Relays, Zero-Knowledge Proofs

1. Introduction

With the advent of blockchains, a plethora of de-
centralized applications (DApps) has evolved that require
different guarantees with regards to key properties like
security, throughput, and privacy. Consequently, multiple
new blockchain platforms and networks have emerged,
targeting application-specific needs.

Bitcoin, for example, pursues a conservative strat-
egy for attaining high-security financial transactions in
a distributed setting by restricting its instruction set [1],
whereas, Ethereum provides a Turing complete virtual ma-
chine executing (almost) arbitrarily complex transaction
logic [2]. Yet, these blockchains exist in isolation and
transactions are bound to a single ledger. For instance,
smart contracts in an Ethereum network interact with
each other for executing logic in libraries, retrieving state
information, or modifying their state, but never interact
with components outside the hosting ledger [3].

To enable this kind of interoperability, different ap-
proaches have been proposed [4]: The most simple ap-
proach is to introduce a trusted intermediary that facilitates
information exchange and mediates between blockchains.
Such trusted intermediaries are commonly referred to

as Oracles and multiple forms with different properties
have been proposed [5]. However, they usually rely on
strong economic assumptions or trusted entities. These
trust assumptions can be weakened for specific scenarios,
e.g., atomic cross-chain currency exchange through hash-
locks. Yet, such techniques are not capable of establishing
a generic link between blockchains.

As a third approach, which neither relies on trusted in-
termediaries nor use-case specific techniques, relays have
been proposed to incorporate another blockchain’s state
or events [6]. Here, the consensus rules of the source
blockchain are validated on the target ledger. Concretely,
a source chain’s block headers are submitted to the tar-
get blockchain, which independently verifies the header-
chain’s correctness. Due to this on-chain verification, ar-
bitrary parties can submit headers without requiring any
trust.

External users, as well as other smart contracts, can
utilize the thereby established header-chain to perform
Simplified Payment Verifications (SPVs), i.e., prove inclu-
sion of transactions in a block through Merkle-proofs [7].
Initially introduced as the foundation of light clients,
which only store block headers instead of maintaining all
past transactions [1], the concept is utilized to prove that a
transaction occurred in a source ledger to a target ledger.

Current implementations of chain relays such as BTC
relay [8] permit submitting single blocks of Proof-of-Work
(PoW) blockchains to a smart contract, which in turn
validates its compliance to the defined consensus rules
of the source chain.

BTC relay incentivizes participants to submit Bitcoin
headers to an Ethereum smart contract by permitting
them to set a fee that has to be paid every time proofs
are constructed from the submitted header. However, the
overhead for submitting an up-to-date block header grows
continuously with the gap to the latest submitted block, as
all intermediate blocks have to be submitted first to enable
header-chain verification. Due to this fact, the BTC relay
contract has stalled for more than one million blocks at
the time of writing, corresponding to more than 20 months
since the last block has been submitted. Catching up to the
head of the Bitcoin blockchain would require more than
one million transactions accounting to about 194,000 gas
each1, a burden economically rational participants are not

1. Exemplary transaction ID of a Bitcoin header submission in
BTC relay: 0xe21099d8fd1252281389fc888f23f98e60db22ecb5c149ad
6fda6dccdf110b50



willing to take.
We address this issue by proposing and implement-

ing a batch-aggregating zero-knowledge proof–based relay
system for PoW blockchains. Instead of having to verify
each header of a source ledger, our system allows a target
ledger to validate a chain of block-headers in batch. Cru-
cially, our design upholds the ability for SPV for blocks in
such batches. Only a single block header of a batch is per-
sisted on the target ledger, minimizing the storage costs.
As the consensus validation is performed completely off-
chain, only the verification of a zero-knowledge proof has
to be performed on the target ledger which leads to a
further cost reduction.

To demonstrate viability of our proposed system de-
sign, we provide and evaluate a prototypical implementa-
tion which establishes a bridge from Bitcoin to Ethereum.
We use the ZoKrates framework [9] to prove validity of
batches of Bitcoin block headers in an off-chain compu-
tation through zkSNARKs. An Ethereum smart contract
confirms the correctness of the resulting proof and stores
the target block header. Light clients can utilize SPV
on verified block-header batches. While the prototypical
implementation targets the realization of a bridge from
Bitcoin to Ethereum, our design is applicable to any
source blockchain that utilizes PoW consensus and any
target blockchain that supports zkSNARK verification.

2. Background

In this section, we first present the general princi-
pals of sidechains and their applications. Thereafter, the
concept of off-chain computations using zkSNARKs is
introduced, as it lays the foundation for zkRelay.

2.1. Sidechains

The term sidechain was first coined by Back et al. [6]
in 2014 and refers to the transfer of assets between distinct
distributed ledgers without requiring any trusted third
party, according to their definition. Today, the term is used
for various forms of interoperability between distributed
ledgers [10]. The most prominent technique to enable
sidechains is chain relays [4]. Here, the target ledger repli-
cates the consensus mechanism of the source blockchain
in order to incorporate events that took place on the
source ledger. Similar to light clients that participate in
the source blockchain’s network, the target blockchain
validates the adherence of submitted block headers to
consensus rules. Generally, this comprises the hash-chain
of block-headers and their timely order. In addition, proof-
of-work blockchains verify that the submitted block hash
fulfills an invariant that directly depends on the current
difficulty.

With XCLAIM [11], a mechanism for exchanging
assets based on chain-relays has been proposed. The
protocol permits creating assets on a target ledger that
are backed by a cryptocurrency that is hosted on another
ledger. XCLAIM utilizes an enhanced version of BTC Re-
lay. Yet, it does not provide any batching mechanisms and
therefore suffers from similar scalability and availability
issues like the original BTC Relay implementation. As the
underlying relay mechanism is exchangeable, the protocol
benefits from the concepts proposed in this paper.

Sidechain mechanisms do not only facilitate token
exchanges but permit accessing the state and events of
other blockchains. For instance, it enables the migration
of smart contracts in case a better-suited host blockchain
emerges for the given use case [3]. Chain-relays permit
proving the validity of migrated smart contracts by sub-
mitting a Merkle proof attesting the state’s validity.

2.2. Verifiable Off-chain Computations

Verifiable off-chain computations were introduced
in [12] as an approach to address blockchain’s scalability
and privacy limitations by executing computations on
blockchain-external resources and verifying that execu-
tion’s correctness on the blockchain in zero-knowledge.
Verifiable computation schemes [13]—and in particular
zero-knowledge succinct arguments of knowledge (zk-
SNARKs) [14]—are a particularly efficient and secure
option to implement this idea, but inherently complex in
their programming abstraction and application.

ZoKrates [9] addresses this problem by providing a
high-level programming language for off-chain computa-
tions and a set of tools for off-chain execution and on-
chain verification. When specifying a ZoKrates program,
the developer explicitly decides which inputs should later
become public or remain hidden. Hiding inputs becomes
possible due to the employed proving scheme’s zero-
knowledge property.

Figure 1 shows ZoKrates’ two core processes, initial-
ization and off-chain computation:

 

ZoKrates
Program

Setup

Execution
Trace

Run
Program

Proving & 
Verification Keys

Verification
Contract

Proof

1 2 3

1

2 3

Figure 1: ZoKrates Initialization and Off-chain Computa-
tion Processes.

2.2.1. Initialization. Before off-chain computations can
be executed, the initialization process needs to be com-
pleted. For a compiled ZoKrates program 1 , an initial
setup is performed to generate a program-specific key
pair, which consists of proving- and verification key 2 .
This process can either be executed by one trusted party
or as a multi-party computation (MPC) within a group
of mutually distrusting peers. The MPC-based approach
relaxes the trust assumption to the existence of at least one
honest participant [15]. In step 3 , a Verification Smart
Contract is derived from the verification key, which is
deployed to a blockchain.

2.2.2. Off-chain Computation. After the successful com-
pletion of the initialization, off-chain computations can be
run and verified: In a first step 1 , a compiled program



is executed for a given set of inputs, which generates an
execution trace, also referred to as witness. A proof that
attests the correct execution of the program for the given
set of inputs is generated in step 2 by combining the
witness with the proving key generated in the initialization
process. This proof is then submitted to the blockchain to
verify the off-chain computation’s correctness by checking
the proof in step 3 .

Due to the use of state-of-the-art zkSNARK schemes,
this proof is of small constant size. Its verification com-
plexity is independent of the complexity of the off-chain
program and linear in the number of public inputs and
outputs.

3. SNARK-based Chain-Relay

The objective of chain-relays is to enable the target
ledger (LT ) to interpret events that have occurred on
the source ledger (LS) in a verifiable manner without
requiring any intermediaries or strong trust assumptions.
Current solutions such as BTC Relay incur costs linear
in the number of blocks contained in LS . Implemented
incentive mechanisms have shown to be inadequate, as
the required investment for keeping the relay up-to-date
exceeded the expected profits.

We propose the utilization of off-chain computations
using zkSNARKs to facilitate the submission of validated
batches of block headers. As a result, the relay’s costs do
not grow linearly with the number of block headers but
are constant for any batch size.

In the following, we first present how off-chain com-
putations can be used to construct a zkSNARK-based
chain relay that permits submitting proofs for single block
headers. Thereafter, the concept is extended to permit
batching multiple block headers and submitting only a
subset of headers to LT . Then, we introduce a mecha-
nism to ensure that SPVs can be performed for all block
headers.

3.1. Single Block Header Validation

In order to decrease the on-chain complexity of val-
idating a block header’s correctness according to the
consensus rules of LS , we construct a provable off-chain
program that takes a block header as input and returns a
boolean value indicating its validity. Conceptually, zkRe-
lay acts as a light client; it does not validate transactions
included in blocks, but relies on the assumption, that
forging valid header-chains is economically infeasible [1].
Due to the probabilistic PoW consensus, zkRelay has to
cope with missing finality and fork handling. Furthermore,
each block header has to satisfy a PoW requirement,
which is defined through its computed target difficulty. In
the following, we tackle each of the tasks of a light client
through off-chain computations based on zkSNARKs.

zkRelay enables any user to perform off-chain vali-
dations of block headers without requiring any trust or
permissions.

At the beginning of the process, a LS client is queried
to retrieve the header chain up to the target header HX

S ,
where X corresponds to the header’s block height, as
illustrated in Figure 2. The off-chain validation program

Source
Ledger

zkRelay
Client ZoKrates Target

Ledger
getBlock

Headers()
Block Headers

validate()
Result

createProof()
Proof

submitProof()
Result

Off-Chain
Validation

Calculate
Proof

zkRelay
Contract

1

2

3

Figure 2: zkRelay Workflow.

checks the PoW of the header and returns a boolean value
that indicates the validity of the block header. Based on
the outcome, a proof is generated attesting the correctness
of the off-chain computation. The proof size is linear in
the number of public input parameters and outputs and
constant otherwise.

Fork handling. The generated proof is submitted to
a relay contract on LT that first validates the proof’s
correctness using the formerly computed verification key.
In addition, it verifies the correctness of the hash chain.
The relay contract stores the genesis block G of LS . Only
blocks that build on top of G sequentially are considered
valid. As valid blocks are not necessarily part of LS but
could depict a fork, block headers that build on top of
the most recent valid block header are accepted but may
be challenged. We underline that every accepted block
header is valid by the consensus rules of LS , as it has
been validated during the off-chain computation, which in
turn has been verified within the relay contract. However,
the currently accepted main chain can be challenged and
replaced in case there is a header chain that contains more
cumulative PoW in LS . Multiple challenging forks may
exist simultaneously, and a fork replaces the main chain
iff it contains more cumulative work than the current main
chain.

Difficulty adjustment. Most PoW-based blockchains
adjust the target difficulty after a fixed amount of blocks to
achieve relatively constant mining rates, depending on the
total hash power in the network. The hash value of a block
header has to be smaller than a target value that is inferred
from the calculated difficulty. An epoch E is defined
through the number of blocks L for which a calculated
difficulty is valid. While zkRelay validates the PoW of
headers within the off-chain program, the computation is
isolated and has no information about the difficulty that is
applied in its epoch. However, the target is encoded within
the block header in Proof-of-Work blockchains. The off-
chain-program extracts the target value and utilizes it
during the validation process. To prevent attackers from
submitting block headers that encode invalid target values
which cannot be detected within the off-chain compu-
tation, the relay contract verifies its correctness before
accepting a proof in step 3 , Figure 2. If HX

S lies within
the epoch (i.e. X mod L 6= 0), the target must be equal
to the encoded target in HX−1

S . Otherwise, it is calculated
from the former target and the time delta between the first
and the last block of the preceding epoch.



Finality. After a block header has been appended to
the stored main chain in the relay contract, it becomes the
basis for validation of successively submitted headers and
can also be used for SPVs. In order to prevent constructing
SPV-proofs from a fork of LS , we define a security
parameter n that indicates the amount of blocks that have
to be appended to a given block before it is considered
final. Only block headers considered final may be used
for SPVs. The parameter is defined by external smart
contracts that reference the relay contract and depends on
the balance between up-to-date cross-chain references and
security for the given use case. SPV-proofs are either vali-
dated on-chain within a smart contract that references HX

S
in the relay contract or by a zero-knowledge proof veri-
fying a Merkle-proof. While the latter provides constant
proof sizes for a given Merkle tree height, the tree size is
fixed, which stems from the fact that zkSNARKs require
constant input sizes. As the amount of transactions stored
in a block highly fluctuates, the corresponding Merkle
tree is adjusted accordingly. To cope with this limitation,
multiple distinct off-chain programs are required, each
validating a single Merkle tree depth.

3.2. Epoch-based Block Header Validation

Performing off-chain validations of single blockchain
headers is particularly helpful in case it requires instruc-
tions which are not natively supported by the target chain.
In case of Bitcoin, the SHA-256 hash function is applied
to the header twice to verify it contains sufficient PoW.
As the SHA-256 hash function is a native opcode in the
Ethereum Virtual Machine (EVM), it requires relatively
small amounts of gas to execute [16]. Nonetheless, other
PoW-based blockchains like Litecoin or Ethereum require
more complex operations to verify block headers and
therefore constitute candidates for future implementations
of a zkSNARK-based chain-relay.

As chain-relays mimic the same mechanisms as the
source blockchain, block headers have to reference a
formerly submitted block. As a result, potentially large
amounts of intermediary headers need to be verified and
stored on the target ledger before the intended header can
be submitted. In Ethereum, storing data is the second most
expensive operation (after creating accounts) within smart
contracts to prevent bloating the state [16]. Chain-relays—
and smart contracts in general—should therefore avoid
storing intermediary data that is not required on-chain.

Off-chain programs that are verifiable through zk-
SNARKs offer functions that provide public and private
parameters. Private parameters are only needed during
off-chain computations and remain invisible during the
proof validation process. While this characteristic poses
promising privacy-related opportunities, we utilize it to
hide complexity to the target ledger in the proof validation
process by submitting batches of headers. We differen-
tiate between block headers that are passed as public
parameters and private intermediary block headers. While
all block headers of a batch are validated off-chain to
ensure only valid hash chains that include sufficient PoW
are submitted, only the last block header of a batch is
stored in the relay contract, as illustrated in Figure 3. The
relay contract remains unaware of private intermediary
block headers and neither stores them, nor requires any

2016 2017 4030 4031 4032 4033…

Epoch

Relay
Contract

Verify
Headers

…

Calculate
Target

Difficulty Submit
Proof

Figure 3: The first block of an epoch is the last block of
a zkRelay batch (N = L = 2016). Block headers shaded
in dark grey are public and visible and passed to the relay
contract. The last block of an epoch is persisted in the
relay contract. Block headers shaded in light grey are
intermediary blocks and initially not stored on the target
ledger.

information about them to validate the correctness of a
batch.

We define a batch BN as an ordered list of N block
headers HX..(X+N−1)

S . For demonstration purposes, we
first choose a batch size equal to the epoch length (N = L)
and thereafter abstract to arbitrary sizes of N . This ensures
that all necessary information is available to compute
the target difficulty within the off-chain program. When
validating single block headers, the difficulty computation
is performed within the relay contract, as the required time
stamps and target values are encoded in the headers that
are stored in the contract. However, this is not the case
when batching block headers off-chain, as only the last
header of a batch is stored in the relay contract. Due to
this fact, the target calculation is shifted to the off-chain
program, providing information about the given epoch and
further reducing overhead in the relay contract.

Intuitively, one may assume that a batch contains
exactly those block headers that belong to one epoch in
case their size is equal. Yet, as the off-chain program per-
forms an isolated computation, such a composition does
not comprise sufficient information to calculate the target
difficulty of an epoch. The target difficulty is computed
from the time delta ∆t between the first and last block of
an epoch, the prior difficulty and the target mining time
θ:

targetn =
∆t

θ × L
× targetn−1

A naive construction of headers that lie within a batch
would, therefore, miss the timestamps required to calcu-
late ∆t. Shifting the batch with an offset of one block
to the epoch permits to construct a proof that holds all
required information to calculate the correct target diffi-
culty, as depicted in Figure 3. To do so, in addition to
the headers that need to be validated, the last block of the
previous batch is submitted publicly. As it is public, it is
utilized by the relay contract to ensure the batch builds on
top of the current main chain. Furthermore, the timestamp
is extracted and used for the calculation of ∆t during the
off-chain validation process. In contrast to the single block
header validation, not only the PoW is verified off-chain,
but also the correctness of the previous block-header hash
as well as a constant difficulty up until the last block of
the batch.



3.3. Simplified Payment Verification for Interme-
diary Headers

The aggregation of block headers into batches facil-
itates efficient off-chain validations to release LT from
storing every single header of LS in the relay contract.
While intermediary headers are initially not stored on
LS , users may intend to create SPVs from them to proof
the occurrence of transactions, states or events. zkRelay
enables users to submit intermediary blocks to the relay
contract retrospectively by utilizing a Merkle tree that is
built over all headers included in a batch. For this purpose,
the off-chain program does not only verify the correctness
of the headers within a batch but also includes them in a
unique Merkle tree. Each leaf node in the tree corresponds
to a block header’s hash. The root of the resulting Merkle
tree is returned by the off-chain program together with the
results from the header and difficulty validation and stored
in the corresponding relay contract. While the intermedi-
ary block headers of a batch are not stored in the relay
contract, the Merkle root enables participants to submit a
Merkle proof for any intermediary header of a batch. As
the header has already been validated off-chain and the
Merkle proof ensures its inclusion in a stored batch, no
further proofs or batch submissions are required to include
intermediary headers. We underline that the computed
Merkle tree is independent of any Merkle tree natively
used by LS or LT and only responsible for facilitating the
trusted submission of intermediary blocks from validated
batches.

Constructing a binary tree for N = 2016 results in
a tree height of dlog2 2016e = 11. Thus, a respective
Merkle proof requires eleven nodes in addition to the
target block header. In order to minimize the computa-
tional overhead on-chain, the proof is computed off-chain
within a dedicated ZoKrates program. The Merkle tree is
calculated based on Pedersen hashes that employ embed-
ded elliptic curves and can be proven efficiently within
ZoKrates programs. In contrast, the application of SHA-
256 is computationally expensive using zkSNARKs, as
modulus operations require a large number of constraints
in the underlying constraint system.

3.4. Flexible Batch Sizes for Block Header Vali-
dation

The header validation concept introduced in Sec-
tion 3.2 facilitates the submission of batches with equal
size to the epoch length of LS . After a batch has been
submitted, users are enabled to submit Merkle-proofs to
the relay contract in order to include intermediary blocks
from which SPVs can be performed. However, two im-
portant challenges remain:

• Large batch sizes prevent the submission of SPVs
from recent block headers. For instance, Bitcoin’s
current mining time of 10 minutes per block and
an epoch size of 2016 results in an epoch duration
of 14 days. Therefore, users would have to wait
for two weeks before being able to utilize zkRelay.

• Compiling an off-chain program, constructing a
witness, and particularly computing a respective

Submit
Proof

…
Submit
Proof

Val. preceeding
Block Hash

4 Block Batch
Relay Contract

2 Block Batch
Relay Contract

Epoch
Head

Figure 4: Different batch sizes require distinct verification
methods. Relay contracts verifying specific sizes may
reference relay contracts of higher order. Block headers
shaded in dark gray indicate public parameters.

proof requires large amounts of RAM, as demon-
strated in Section 5. Thus, the complexity of the
off-chain computation needs to be reduced to en-
sure practicality of zkRelay on end-user hardware.

To mitigate the obstacles introduced by large batch
sizes, we introduce a concept for flexible batch sizes in
addition to Merkle-proof submissions. The mechanisms
are interoperable and may thus be applied in conjunction.

As single off-chain programs are not capable of han-
dling variable batch sizes, we introduce multiple off-
chain programs, each handling a distinct batch size. The
ZoKrates setup phase is executed for each batch size,
resulting in distinct proving and verification keys for each
size. There are two options to verify the correctness of
batches of different size. (i) A distinct verification method
is embedded into a single contract for each batch size.
Hereby, the complexity is kept low, as all batches are
submitted to a single contract that handles references
between distinct batch sizes. This approach, however,
implies a fixed set of batch sizes that cannot be modified
once the relay contract has been deployed to the target
ledger. (ii) Deploying a single relay contract for each
batch size provides more flexibility to participants, as
novel contracts can be added retrospectively. Therefore,
we utilize the second approach in the following, enabling
users to utilize batch sizes according to their requirements,
as illustrated in Figure 4. Every relay contract maintains a
set of other relay contracts that may be referenced during a
batch submission. Assuming, for example, that a batch of
two block headers is submitted, it could build on top of a
batch four headers that is stored in a separate contract.
Hereby, the computational complexity is decreased for
smaller batch sizes, which facilitates cheap submission of
recent block headers.

However, applying smaller batch sizes prevents the
off-chain computation from calculating a correct tar-
get difficulty in case a new epoch is entered. There-
fore, the first block header of the corresponding epoch
(HX−(X mod N)

S ) is passed as a public parameter to the
off-chain program. Furthermore, an additional output vari-
able is introduced that indicates the validity of the en-
coded target difficulty. As short-circuit evaluation is not
supported in off-chain programs, the target value is com-
puted for every submitted batch. Thus, the target value is
computed even if the batch does not include a transition
between epochs. In this case, the value is invalid as the
elapsed time within an epoch is smaller than expected



in most cases. To tackle this issue, the relay contract first
calculates whether the submitted batch exceeds the current
epoch and only in that case utilizes the program’s corre-
sponding output. Each batch size should be constructed
in a form that satisfies the requirement of storing the first
block of an epoch as the last block of a batch. The relay
contract is verifies that the correct first block of an epoch
has been submitted to the off-chain program.

Every relay contract references relay contracts of
higher order to prevent offsets resulting in batch sub-
missions surpassing an epoch boundary. For example, a
participant may submit a batch of size four starting from
genesis block G. Based on this batch, any participant
could submit a batch of size N = L = 2016. As a
result, the latter batch would store H2020

S instead of the
required H2016

S that corresponds to the first block of the
subsequent epoch. Enforcing a top-down approach pre-
vents such threats while maintaining sufficient flexibility
to participants.

4. Implementation

The implementation of zkRelay is separated into three
components. While the off-chain program is implemented
using the ZoKrates framework, the relay contract is a So-
lidity smart contract that targets the Ethereum blockchain.
Lastly, a Python pipeline enables retrieving block headers
from a Bitcoin client, computing corresponding witnesses
and proofs using ZoKrates, and submitting proofs to the
relay contract. zkRelay is available on GitHub2 under an
open-source license.

Before submitting block headers to the off-chain pro-
gram, the raw input has to be preprocessed, as variables
in ZoKrates are restricted to a field size of 16 bytes [9].
Because the size of Bitcoin headers is 80 bytes [17], each
header is split into five 16 byte long integer values before
being passed as a parameter. The off-chain program ap-
plies two SHA-256 hashes to the header and compares the
result to the encoded target value. The target value must
remain constant within an epoch. Otherwise, the correct
calculation of the target value is validated by computing
it from the timestamps of the first and last block of an
epoch. Due to Bitcoin’s encoding of the target to four
bytes, some precision is lost in comparison to its former
32-byte value. In ZoKrates programs, floor functions that
permit compensating for imprecision are computationally
inefficient. Therefore, a target is considered valid if it is
equal up to the last digit of its encoded value. Furthermore,
the standard encoding for Bitcoin headers is little-endian.
Therefore, headers are passed in little-endian to calcu-
late valid hashes during PoW calculations, while static
functions convert header contents to big-endian for further
processing.

Based on the verification keys that are generated dur-
ing the setup-phase, ZoKrates generates a Solidity smart
contract that verifies the correct program execution for
submitted proofs. To maintain a clear separation between
zkSNARK verification and relay logic, a second smart
contract is implemented that stores all successfully sub-
mitted Bitcoin headers. Every time a batch of block head-
ers is submitted, the zkSNARK verification contract is

2. https://github.com/informartin/zkRelay

called. Only if the program execution is deemed valid, fur-
ther processing takes place in the relay contract. Regular
batch submissions have to build on top of the current main
chain stored in the contract. Any former submission can
be challenged by any participant. After a challenging fork
has been successfully submitted, either further batches are
submitted that build on top of the fork, or a settlement
function is called that compares the cumulative difficulty
of t";"""date"",""2020-04-15T10:47:16Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2020-04-15T10:47:16Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017) kpathsea version 6.2.3""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2020-04-15T10:47:16Z""
""created"",""2020-04-15T10:47:16Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-04-15T10:47:16Z""
""resourceName"",""433.pdf""
""Author"",""""
""producer"",""pdfTeX-1.40.18""
""pdf:docinfo:producer"",""pdfTeX-1.40.18""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""1"",""0"",""2"",""0"",""0"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2020-04-15T10:47:16Z""
""Last-Modified"",""2020-04-15T10:47:16Z""
""dcterms:modified"",""2020-04-15T10:47:16Z""
""title"",""""
""Last-Save-Date"",""2020-04-15T10:47:16Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2020-04-15T10:47:16Z""
""meta:save-date"",""2020-04-15T10:47:16Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017) kpathsea version 6.2.3""
""Content-Length"",""338095""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""9""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""4515"",""4737"",""4848"",""5147"",""5015"",""5350"",""3756"",""4753"",""3900""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-04-15T10:47:16Z""
";https://scholar.google.ch/scholar?start=800&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098897-403;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Tecnología Blockchain, Smart Contracts y Caso Swap. Descripción, Evolución, Aplicaciones y Tendencias;F Vilar Pagčs ;2020 diposit.ub.edu;;"… IV. TECNOLOGÍA BLOCKCHAIN: EVOLUCIÓN … DESCRIPCIÓN.....21 COMO FUNCIONAN LOS

SMART CONTRACTS .....23 ORACLE: LA PLATAFORMA CLOUD DISTRIBUIDA …";Cité 1 fois;;[PDF] ub.edu;http://diposit.ub.edu/dspace/bitstream/2445/169613/1/TFG_ADE_VILAR_FERRAN_JUL20.pdf;"
  

 
TRABAJO FIN DE GRADO 

ADMINISTRACIÓN Y DIRECCIÓN DE EMPRESAS 
 
 

 
 
 
TECNOLOGÍA BLOCKCHAIN, SMART CONTRACTS y CASO SWAP. 

 
 

DESCRIPCIÓN, EVOLUCIÓN, APLICACIONES y TENDENCIAS 
 
 
 
 
 
 

Autor 
 

Ferran Vilar Pagès 
 

Tutor 
 

Dr. Eudald Puig 
 

Departamento de OrganizaciĂłn i AdministraciĂłn de Empresas 
 
 
 
 
 
 
 
 
 
 
 

2019 - 2020 



  

 
 
 
 
 



 TecnologĂ­a Blockchain, Smart Contracts y Caso Swap. DescripciĂłn, EvoluciĂłn, Aplicaciones y Tendencias  
 
 
 

  
 

 
RESUMEN EJECUTIVO 
 
La tecnologĂ­a blockchain, descentralizada, inmutable, segura y anĂłnima, ha generado gran 
expectaciĂłn para con sus posibilidades de aplicaciĂłn en distintos sectores como el financiero, 
el turismo, el Internet de las cosas (IoT), la sociedad y los sectores pĂşblicos. Si bien existen 
estudios y trabajos que respaldan una reestructuraciĂłn de la economĂ­a tal y como la conocemos 
hoy en dĂ­a, es de opiniĂłn dispar las posibilidades y el rango de afectaciĂłn de la tecnologĂ­a en 
la realidad. Para intentar reducir esta discrepancia de posiciones con respecto a su futuro, se 
analizan sus bases desde su ejecuciĂłn por primera vez en 2009, junto al funcionamiento que 
sigue. SerĂĄ objeto de estudio su evoluciĂłn en el tiempo, la afectaciĂłn de esta a un servicio 
financiero, la aplicaciĂłn en distintos sectores y la exposiciĂłn de sus limitaciones en la 
actualidad. AsĂ­ mismo, este trabajo menciona alguna de las tendencias futuras de la tecnologĂ­a 
blockchain. 
 
 
 
 
EXECUTIVE SUMMARY. 
 
BLOCKCHAIN TECHNOLOGY, SMART CONTRACTS and SWAP CASE.  
Principals, Evolution, Applications and Future Trends 
 
The blockchain technology, decentralized, immutable, anonymous and secure, has generated 
great expectations for its potential application in various sectors such as finance, services, the 
Internet of Things (IoT), society and public sectors. Although there are studies and works that 
support a restructuring of the economy as we know it today, the possibilities and the range of 
impact of technology in reality is of different opinion. To try to reduce this discrepancy of 
positions regarding its future, we analyze its bases since its execution for the first time in 2009, 
its principals such as architecture of the chain, the different participants it can suit and the 
benefits they bring to the network as a whole, along with the functionality it follows. Its 
evolution over time, the way in which it has affected a financial service to exemplify the power 
to make inference in reality the new abilities have, the implications it has within real projects 
such as, supply chain management. Also, some other sectors will be mentioned as eligible to 
adopt a blockchain system in order to gain insights against the competence and the exposure of 
the current limitations will be studied. Furthermore, this work points out some future trends of 
the blockchain technology. 
 
 

PALABLRAS CLAVE: Blockchain, Minero, Hash, Token, Bitcoin, Smart Contract, 
DuraciĂłn, Ethereum, Desarrollador y PoW. 
 

KEY WORDS: Blockchain, Miner, Hash, Token, Bitcoin, Smart Contract, Duration, 
Ethereum, Developer and PoW. 
 



 TecnologĂ­a Blockchain, Smart Contracts y Caso Swap. DescripciĂłn, EvoluciĂłn, Aplicaciones y Tendencias 
 

INDICE 
 

 4 

 
INDICE 
 

I. INTRODUCCIÓN................................................................................................................................. 5 
II. ¿POR QUÉ TODO ESTE REVUELO? ................................................................................................ 7 
III. TECNOLOGÍA BLOCKCHAIN: DESCRIPCIÓN ............................................................................. 9 

 BLOCKCHAIN: ARQUITECTURA ........................................................................................................ 9 
 Bloque ......................................................................................................................................10 

 TRANSACCIONES Y FIRMA DIGITAL. ................................................................................................11 
 CARACTERÍSTICAS DE LA BLOCKCHAIN. .........................................................................................12 
 FUNCIONAMIENTO DEL SISTEMA BLOCKCHAIN. ...............................................................................14 
 EL ALGORITMO DE CONSENSO ........................................................................................................15 

IV. TECNOLOGÍA BLOCKCHAIN: EVOLUCIÓN. ..............................................................................18 
 DE TRANSACCIONES A SMART CONTRACTS. ....................................................................................18 
 APLICACIÓN FINANCIERA: SWAP DE TIPO DE INTERÉS ...................................................................19 
 SMART CONTRACTS. DESCRIPCIÓN .................................................................................................21 
 COMO FUNCIONAN LOS SMART CONTRACTS ...................................................................................23 
 ORACLE: LA PLATAFORMA CLOUD DISTRIBUIDA..............................................................................24 
 ETHEREUM. ...................................................................................................................................27 

 Ether ........................................................................................................................................28 
 Cuentas Ethereum ....................................................................................................................28 
 El precio del Gas o ETH ...........................................................................................................29 

 LAS DIFERENCIAS ENTRE BITCOIN Y ETHEREUM. .............................................................................30 
V. TECNOLOGÍA BLOCKCHAIN: APLICACIONES .........................................................................32 

 EL IMPACTO DE LOS SMART CONTRACTS. .......................................................................................32 
VI. LIMITACIONES DE LA TECNOLOGÍA BLOCKCHAIN...............................................................37 

 COMPARACIÓN Y EL TRILEMA DE SEGURIDAD-DESCENTRALIZACIÓN-ESCALABILIDAD .....................41 
VII. ¿CUÁL ES EL SIGUIENTE PASO? ..............................................................................................44 
VIII. CONCLUSIONES ...........................................................................................................................45 
IX. BIBLIOGRAFÍA ..................................................................................................................................47 
X. WEBGRAFÍA ......................................................................................................................................48 
XI. ANEXO ................................................................................................................................................49 

 
 



 TecnologĂ­a Blockchain, Smart Contracts y Caso Swap. DescripciĂłn, EvoluciĂłn, Aplicaciones y Tendencias 
 

INTRODUCCIÓN 

 

 5 
 
 

 

I. INTRODUCCIÓN 
 
“Commerce on the Internet has come to rely almost exclusively on financial institutions serving as trusted third 
parties to process electronic payments. While the system works well enough for the model transactions, it still 
suffers from inherent weakness of trust-based model. […] What is needed is an electronic payment based on 
cryptographic proof instead of trust, allowing any two willing parties to transact directly with each other without 
the need for a trusted third party.” 
 
(Nakamoto, 2008) 
 
El misterioso white paper bajo la autorĂ­a de Satoshi Nakamoto describĂ­a y sentaba las bases de 
un modelo de criptomoneda totalmente distribuido, basado en una cadena de bloques capaces 
de almacenar cualquier tipo de datos juntados por una cadena criptogrĂĄfica. No fue hasta 2010 
que este sistema se hizo realidad fomentando la carrera para escalar la cima del Bitcoin, vigente 
a dĂ­a de hoy. Doce aĂąos despuĂŠs de su puesta en escena, las innovaciones que este presentaba 
lideran el siguiente escenario de las conexiones digitales, abriendo puertas a un espacio 
compartido, descentralizado, confiable y de conformidad distribuida. 
 
La funcionalidad de la cadena de bloques criptogrĂĄfica, a partir de ahora blockchain, se explica 
con lo que a dĂ­a de hoy sigue siendo se principal activo, el Bitcoin1. Los conceptos usados para 
la explicaciĂłn y la puesta en marcha de la primera criptomoneda no eran innovadores como tal, 
si bien la idea y la forma de almacenar datos que plantea la tecnologĂ­a blockchain tiene 
antecedentes muy anteriores, en la dĂŠcada de los 70: las bases de SQL; vigente para 
instituciones centralizadas. Lo que sĂ­ fue rompedor eran las posibilidades que su interconexiĂłn 
producĂ­a que habilitaron un espacio para realizar transacciones entre individuos de forma 
anĂłnima y confiable. Introdujo lo que se conoce como trusted network. Por primera vez en la 
historia se hacĂ­a realidad un sistema que permitĂ­a hacer transacciones sin necesidad de la 
participaciĂłn de terceros agentes generadores de confianza permitiendo asĂ­ una relaciĂłn entre 
individuos. HacĂ­a con ello posible lo imposible. (Navarro, 2017) 
 
El concepto blockchain no es demasiado intuitivo, por lo que hace necesario un conocimiento 
extenso de las partes que engloba y como estas actĂşan de forma sinĂŠrgica. Esta dificultad de 
comprensiĂłn aflora disparidad de opiniones por lo que al futuro concierne, hay quienes creen 
que serĂĄ un punto de inflexiĂłn, no solo en las transacciones de dinero, sino como un modelo 
alternativo que suprimirĂĄ el poder monetario de los gobiernos centrales, conduciendo a una 
nueva era de libertad econĂłmica e independencia, y otros, son cautos, y no le ven mĂĄs 

                                                        
1 Bitcoin no es identidad de Blockchain. Son dos conceptos muy distintos y serĂ­a un error  
tratarlos por igual. La tecnologĂ­a Blockchain es condiciĂłn sine qua non de Bitcoin. 
 



 TecnologĂ­a Blockchain, Smart Contracts y Caso Swap. DescripciĂłn, EvoluciĂłn, Aplicaciones y Tendencias 
 

INTRODUCCIÓN 

 

 6 
 
 

posibilidades lejos de las transacciones de valor. Solo el tiempo y la innovaciĂłn tecnolĂłgica 
saben el rumbo que tomarĂĄ. (Nofer, 2017) 
 
Una cosa es clara, si las expectativas que se generan con esta nueva tecnologĂ­a devienen reales, 
estaremos ante una revoluciĂłn tecnolĂłgica. Se espera esta lleve consigo un cambio rĂĄpido de 
las tendencias y una repercusiĂłn al medio-largo plazo a gran escala. Ciertamente podrĂ­a ser esta 
la tecnologĂ­a del futuro, pero cabe la posibilidad que todas las expectativas fueran, en su 
mayorĂ­a solo eso en el dĂ­a de maĂąana.  (Mattila, 2016) (Navarro, 2017) 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 



 TecnologĂ­a Blockchain, Smart Contracts y Caso Swap. DescripciĂłn, EvoluciĂłn, Aplicaciones y Tendencias 
 

¿POR QUÉ TODO ESTE REVUELO? 

 

 7 
 
 

 

II. ¿POR QUÉ TODO ESTE REVUELO? 
 
Hoy en dĂ­a la transmisiĂłn de informaciĂłn de un lado a otro del planeta se puede llevar acabo 
gracias a la evoluciĂłn del ordenador y la introducciĂłn de internet como puente de contacto. De 
esta revoluciĂłn se deriva la problemĂĄtica de la fiabilidad de la informaciĂłn que se recibe y se 
comparte. ÂżCĂłmo se verifica que la informaciĂłn recibida es autĂŠntica y actualizada? La cuestiĂłn 
responde a una confianza necesaria entre partes. Aparecen asĂ­ las organizaciones centralizadas 
que actĂşan como terceros agentes entre las partes como mediadoras generando una confianza 
no necesariamente implĂ­cita entre actores. De esta forma soportan el riesgo derivado del 
acuerdo entre las partes a cambio de una contraprestaciĂłn econĂłmica por el servicio realizado. 
La actividad de los mediadores era necesaria para habilitar una relaciĂłn entre individuos. (p. ej. 
Banco como intermediario en una firma de pagarĂŠ entre dos empresas.) 
 
La tecnologĂ­a blockchain como agente disruptivo ha despertado tanto interĂŠs porque tiene la 
capacidad de facultar una confianza entre partes sin necesidad de terceros involucrados. 
Propone un sistema de almacenamiento de datos confiable y verificable en todo momento por 
cualquier usuario de la red. De este modo la participaciĂłn de un actor ajeno se ve sustituida por 
la funcionalidad de la misma red. 
 
Para saber que es exactamente lo que la tecnologĂ­a blockchain permite, uno ha de entender que 
la sociedad necesita la participaciĂłn de entidades centralizadas como mediadores en cualquier 
actividad por la confianza que esta transmite a todo el colectivo. Una confianza necesaria que 
ha desembocado en ciega. Por ejemplo, se confĂ­a en que un repartidor usarĂĄ tu direcciĂłn solo 
para la entrega de un pedido y que empresa de repartos la usarĂĄ solo con fines profesionales y 
en ningĂşn caso de forma fraudulenta. De alguna manera se espera que esa informaciĂłn sea 
usada solo en el contexto para lo que ha sido facilitada, cuando realmente lo que se permite es 
la cesiĂłn de datos personales de utilidad para las grandes corporaciones centralizadas, pero de 
incalculable valor para el individuo. La tecnologĂ­a blockchain cada individuo serĂ­a dueĂąo de su 
informaciĂłn y se darĂ­a acceso a ella dentro de un espacio de confianza que previera su mala 
praxis. (Navarro, 2017) 
 
En su conjunto, blockchain esta cambiando la sociedad desde distintos ĂĄngulos. Una de ellas es 
la construcciĂłn de una plataforma totalmente distribuida que genere confianza a los 
participantes por su condiciĂłn criptogrĂĄfica desincentivando asĂ­ la participaciĂłn de terceras 
partes en las relaciones entre individuos y la eliminaciĂłn de grandes corporaciones 
centralizadas empoderadas. Con ello blockchain introduce una nueva pregunta en la discusiĂłn 
econĂłmica: ÂżCĂłmo crean valor las cadenas blockchain y quien o cĂłmo se genera esta 
confianza? (Nofer, 2017) 



 TecnologĂ­a Blockchain, Smart Contracts y Caso Swap. DescripciĂłn, EvoluciĂłn, Aplicaciones y Tendencias 
 

¿POR QUÉ TODO ESTE REVUELO? 

 

 8 
 
 

 
Por otra parte, dentro de la economĂ­a industrial en la que se encuentra la sociedad desde su 
introducciĂłn, la tecnologĂ­a blockchain propone soluciones eficientes a lo que la necesidad de 
relaciĂłn entre entidades centralizadas se refiere. Si bien una industria o una empresa puede 
parecer desde fuera un engranaje que funciona de una manera Ăłptima, ve como la necesidad de 
acceder a datos o recursos de otras resulta en ineficiencias en forma de tiempo y dinero. Un 
ejemplo para poner en contexto esto serĂ­a el hacer un cambio de domiciliaciĂłn de la nomina de 
una entidad financiera a otra. Con el sistema tradicional se tardarĂ­an dĂ­as y serĂ­a costoso para 
el cliente, con una tecnologĂ­a blockchain se presume esta serĂ­a casi inmediata. 
 
Con este efecto doble, blockchain pretende llegar a toda la sociedad, romper con lo establecido 
dentro de un contexto industrial y que esto se traduzca en un mayor bienestar de toda la 
poblaciĂłn. Una cosa es clara, la tecnologĂ­a precisa de un proceso de adaptaciĂłn que, lejos de 
ser rĂĄpido, estĂĄ siendo sostenido y constante en el tiempo. Existen, por eso, limitaciones 
tecnolĂłgicas y de conocimiento con las que lidiar para poder avanzar hacia un nuevo futuro, y 
si bien las innovaciones presentadas son esperanzadoras, se ha de probar su impacto real y lo 
mĂĄs importante, se ha de producir una aceptaciĂłn del colectivo social en su totalidad. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 



 TecnologĂ­a Blockchain, Smart Contracts y Caso Swap. DescripciĂłn, EvoluciĂłn, Aplicaciones y Tendencias 
 

TECNOLOGÍA BLOCKCHAIN: DESCRIPCIÓN  
 

 9 
 
 

 

III. TECNOLOGÍA BLOCKCHAIN: DESCRIPCIÓN 
 
SegĂşn apunta Roger Wattenhofer, profesor en la Swiss Federal Intitute of Technology (ETH), 
“La tecnología Blockchain está formada por dos componentes esenciales, la Criptografía 
Asimétrica y las Distributed Ledgers”. Las últimas son la capacidad de interacción de manera 
distribuida entre participantes, que en su esencia son ordenadores.  
 
Para comprender el poder disruptivo de la tecnologĂ­a blockchain se procede a la exposiciĂłn y 
explicaciĂłn detallada de cada uno de sus componentes. Es importante destacar que el siguiente 
anĂĄlisis se basa en el primer modelo blockchain presentado por Satoshi Nakamoto en 2008. Se 
conoce como blockchain 1.0. 
 

 Blockchain: Arquitectura 
 
 
 
 
 
 
 
 
 
 
La cadena blockchain es una secuencia de bloques dotados de una serie de datos almacenados 
en ellos, actuando esta como una base de datos que recuerda a modelos ya existentes. En la 
figura 1 se presenta la estructura tĂ­pica de una blockchain. Los bloques estĂĄn unidos uno a otro 
de manera secuencial, por lo que un bloque depende de la informaciĂłn que hereda del anterior. 
Esta anatomĂ­a se repite sucesivamente hasta el Genesis Block que no le precede ningĂşn otro. 
La informaciĂłn heredada se encuentra criptogrĂĄficamente detallada en el block header. El valor 
que resulta del block header se denomina hash, un valor criptogrĂĄfico Ăşnico e irrepetible. Solo 
se aĂąadirĂĄn a la cadena los bloques que se identifiquen como los Ăşnicos capaces de relacionar 
su informaciĂłn con la del antecesor y representar la realidad. (Zheng Z. X., 2017) 

Figura 1: Cadena de bloques criptogrĂĄficamente unida. Fuente: Zheng, Z. X., 2017 



 TecnologĂ­a Blockchain, Smart Contracts y Caso Swap. DescripciĂłn, EvoluciĂłn, Aplicaciones y Tendencias 
 

TECNOLOGÍA BLOCKCHAIN: DESCRIPCIÓN  
 

 10 
 
 

 
 
 
 
 
 
 
 
 
 
 
 

 Bloque 
 
El bloque se constituye en esencia de dos partes: el block header y el block body. (figura 
2) 
 
El block header o nombre del bloque registra la siguiente informaciĂłn: 
 

• Block Version: Un código alfanumérico que indica las reglas a seguir para la 
validaciĂłn del bloque. 
 

• El Markle Tree Root Hash que referencie todas las transacciones cabidas en el 
bloque, un Time stamp referencia temporal del hallazgo del hash, nBits valor 
hash de forma compacta y el Nonce que incrementa a medida que se sucedan los 
cĂĄlculos del algoritmo hash. (figura 3)  

 
• Block Parent: Otro código alfanumérico que permitirá la unión de todos los 

bloques consecuentes a este. RecogerĂĄ de forma compacta los 256 valores del 
hash del bloque anterior.

Figura 2: InformaciĂłn contenida en un bloque criptogrĂĄfico. Fuente: Zheng, Z. X., 
2017 



 TecnologĂ­a Blockchain, Smart Contracts y Caso Swap. DescripciĂłn, EvoluciĂłn, Aplicaciones y Tendencias 
 

TECNOLOGÍA BLOCKCHAIN: DESCRIPCIÓN  
 

 11 
 
 

 
 
 
 
 

 
 
 
 
 
 
El block body estĂĄ compuesto por el nĂşmero de transacciones y el valor de las mismas. 
El nĂşmero de transacciones que puede registrar un bloque dependerĂĄ de las limitaciones 
que su red tenga. Para el caso de Bitcoin la limitaciĂłn se encuentra en el nĂşmero de 
transacciones, si bien existen otras, como se verĂĄ mĂĄs adelante donde la limitaciĂłn reside 
en la cantidad de criptomonedas a registrar en su totalidad. Para realizar el proceso de 
validaciĂłn de cada transacciĂłn, blockchain utiliza la criptografĂ­a asimĂŠtrica basada en 
una firma digital. Esto se usa en espacios donde no se genera confianza entre 
participantes. (Zheng Z. X., 2018) 

 
 Transacciones y Firma digital. 

 
Para que se produzcan las transacciones de activos en la red, ĂŠsta precisa de dos 
componentes, los usuarios y la encriptaciĂłn. Los primeros serĂĄn los encargados de 
realizar la transacciĂłn a la que se le asignarĂĄ un valor hash Ăşnico e irrepetible gracias al 
segundo actor, la encriptaciĂłn. Una vez validada la transacciĂłn serĂĄ aĂąadida al bloque 
en forma de informaciĂłn criptogrĂĄfica TX. La participaciĂłn de los nodos no termina 
aquĂ­, ya que cuando un bloque es validado y pasa a formar parte de la cadena de bloques, 
todos reciben una copia actualizada de la misma en su dispositivo para que sea auditable 
en todo momento.  

 
Cuando se decide ser partĂ­cipe de una red blockchain, como usuario se recibe una 
private key y una public key. Las llaves privadas se usan para firmar las transacciones y 
encriptar el valor hash de la misma de forma automĂĄtica una vez esta es emitida. Las 
transacciones son globalizadas dentro de la plataforma, por lo que cada usuario puede 
relacionarse con cualquier integrante de la misma. Cuando quiera efectuarse una 
transacciĂłn deberĂĄ constar a que llave pĂşblica se quiere enviar. A efectos de la 
blockchain de Bitcoin, la llave pĂşblica es la direcciĂłn de cartera de los usuarios.

Figura 3: Resultado hash ejemplo para un bloque. Fuente: Zheng Z. X., 2018 



 TecnologĂ­a Blockchain, Smart Contracts y Caso Swap. DescripciĂłn, EvoluciĂłn, Aplicaciones y Tendencias 
 

TECNOLOGÍA BLOCKCHAIN: DESCRIPCIÓN  
 

 12 
 
 

  
La transacciĂłn entre dos usuarios de la red consta de dos fases: La firma de la 
transacciĂłn y la validaciĂłn de la misma. (figura 4). Cuando un usuario emisor realiza 
una transacciĂłn, se le deriva un valor hash Ăşnico e irrepetible. Es con la llave privada 
que se encripta2 dicho valor y lo envĂ­a direcciĂłn a la cartera referenciada. El receptor 
usa su llave pĂşblica para desencriptar el documento obteniendo un valor hash, que a su 
vez ha de coincidir con el valor que encuentra el validador de la transacciĂłn para que 
esta sea reconocida por la red como real. Si no coincidieran los valores serĂ­a debido a 
que el contenido inicial de la misma ha sido modificado, por lo que no se validarĂ­a la 
operaciĂłn y quedarĂ­a nula de cualquier efecto. En este caso el emisor recuperarĂ­a su 
posiciĂłn o state inicial dado que se le devolverĂ­a la cantidad emitida, UTXO. 
 
 
 
 
 
 
 
 
 

 
 
 
La transacciĂłn una vez validada es almacenada en un Transaction Counter en el que se 
depositan todas las validadas. Gracias al sistema Markle Tree se relaciona de forma 
continuada parejas de valores hash de cada transacciĂłn validada, culminando en un Ăşnico 
valor, el Root Hash que contiene informaciĂłn de todas las subyacentes. Se idea un sistema 
eficiente y trazable para comprobar en todo momento cualquier aspecto de una transacciĂłn 
que se produjo. Dada la relevancia del Markle Tree, se recupera en el apartado del algoritmo 
de consenso. (Nakamoto, 2008) (Xiao, 2020) 

 
 CaracterĂ­sticas de la Blockchain. 

 
• Descentralización: Otorga significado a la creación de la red en si y las hace 

escalables y con relaciones peer-to-peer3. Permite la ausencia de confianza entre 
emisor y receptor, y la hace depositar en la tecnologĂ­a. Junto a la inmutabilidad 
de la red de bloques y la rĂŠplica masiva automatizada de la cadena una vez 

                                                        
2 Se ha de entender encriptaciĂłn como la firma que constata el origen de la transacciĂłn 
3 Peer-to-Peer: De un individuo a otro, sin intermediarios. 

Figura 4: Procesos a los que ese somete una transacciĂłn en la red Bitcoin. 
TransacciĂłn completadad 



 TecnologĂ­a Blockchain, Smart Contracts y Caso Swap. DescripciĂłn, EvoluciĂłn, Aplicaciones y Tendencias 
 

TECNOLOGÍA BLOCKCHAIN: DESCRIPCIÓN  
 

 13 

actualizada a todos los usuarios, blockchain elimina los riesgos de seguridad y 
manipulaciĂłn de datos que existen en las organizaciones centralizadas. (Zheng 
Z. X., 2018) 

 
En un sistema tradicional centralizado todas las operaciones son validadas por 
una Ăşnica organizaciĂłn de confianza para todos los usuarios (p. ej. Banco). Si 
bien cada organizaciĂłn, bancos para seguir con el ejemplo, son eficientes, su 
necesidad de relaciĂłn con otras industrias les hace incurrir en un proceso ocioso 
que genera costes en forma de tiempo y dinero a soportar por el cliente final. Es 
equiparable, para una mayor comprensiĂłn, a un sistema de engranajes donde por 
mucho que el sistema individual sea Ăłptimo, si la fuerza motriz que conecta una 
con otra es defectuosa, todo el conjunto lo serĂĄ. 
 
En cambio, una transacciĂłn en una red blockchain recibe la caracterĂ­stica peer-
to-peer porque obvia la necesidad de autentificaciĂłn por parte de ningĂşn tipo de 
organizaciĂłn o industria, descentralizando su ratio de acciĂłn. Esto se traduce en 
un ahorro econĂłmico y en eficiencias de tiempo para los usuarios. 
 

• Inmutabilidad: Se apuntaba junto a la descentralización de la red. Es 
estadĂ­sticamente muy poco probable cambiar lo que ya ha sido registrado en la 
cadena. Todo bloque aĂąadido se presume Ăşnico y representativo de la realidad 
para todas las transacciones que contiene, lo que resulta en una desincentivaciĂłn 
de actividades fraudulentas. (Zheng Z. X., 2018). Nakamoto lo ejemplifica como 
una distribuciĂłn de Poisson que pierde consistencia de forma geomĂŠtrica a 
medida que aumentan el nĂşmero de usuarios de la misma.  

 
• Anonimidad: Cada usuario es referido por la llave pública que posee, su 

direcciĂłn de cartera, no por su persona. Es mĂĄs, si algĂşn usuario quisiera reducir 
su exposiciĂłn a la red, podrĂ­a crear mĂĄs de una cuenta para usar distintas llaves 
pĂşblicas. blockchain no puede, por eso, garantizar una privacidad total debido a 
distintas limitaciones que de sus caracterĂ­sticas se derivan. (se explica con 
detalle en la secciĂłn VI).  

 
• Verificable: Toda transacción realizada es validada con un time stamp que indica 

el momento temporal en el que se produjo la validaciĂłn, quienes eran las partes 
involucradas y con el sistema Markle Tree todas ellas quedan relacionadas entre 
si. En la blockchain de Bitcoin, por ejemplo, aparece el saldo de cartera de ambas 
partes antes y despuĂŠs de la transacciĂłn y el enlace a las anteriores que verifican 



 TecnologĂ­a Blockchain, Smart Contracts y Caso Swap. DescripciĂłn, EvoluciĂłn, Aplicaciones y Tendencias 
 

TECNOLOGÍA BLOCKCHAIN: DESCRIPCIÓN  
 

 14 

la cuantĂ­a presentada. Por lo tanto, es un sistema de bĂşsqueda que resulta en la 
transparencia total de los datos que se almacenan. (Navarro, 2017)(Anexo 1) 

  
 Funcionamiento del sistema Blockchain. 

 
Los modelos actuales de cadenas blockchain se pueden dividir en dos grandes grupos: 
Las redes pĂşblicas permissionless y las privadas o permissioned. Cada una de ellas con 
distintas caracterĂ­sticas de funcionamiento que se detallan en el apartado VI. Para el 
caso que concierne, el sistema de criptomonedas Bitcoin que propone Satoshi Nakamoto 
es uno pĂşblico. Como tal, la confianza es depositada en la tecnologĂ­a detrĂĄs de la red 
blockchain, que ve incrementada su seguridad cuanto mayor sea el nĂşmero de usuarios 
participantes de la verificaciĂłn de las transacciones y los bloques. Son los denominados 
nodos mineros o miners. Para garantizar la seguridad dada la posible participaciĂłn de 
cualquier individuo que asĂ­ lo desee, las redes pĂşblicas precisan de un proceso de 
validaciĂłn llamado Proof of Work (PoW), que sin ir mĂĄs lejos culmina con un valor hash 
aceptado por la red. (Nakamoto, 2008). Garantizando asĂ­ la realidad de las operaciones 
y evitar manipulaciones para el beneficio de nodos malignos. Se considera a toda la red 
por igual, y para finalmente aĂąadir un bloque a la cadena una vez encontrado el Block 
Hash del mismo, ha de manifestar su aceptaciĂłn el 51% de la red, siendo este su modelo 
de consenso.  
 
Algunas veces el proceso de validaciĂłn de bloques, al ser simultaneo para toda la red, 
puede darse el caso de que mĂĄs de un minero encuentre el valor nonce apto para el valor 
hash al mismo tiempo. Como se ilustra en la figura 5, se registran todos los bloques 
encontrados formando asĂ­ la denominada fork, branches o horquillas. El sistema de 
validaciĂłn PoW, asume como valida la cadena mĂĄs larga de bloques, dado que es poco 
probable una asunciĂłn de bloques de forma continuada en el tiempo. (Zheng Z. X., 
2018) 
 

 
 
 
 
 
 

 
 

Supongamos dos horquillas generadas simultĂĄneamente y aĂąadidas a la red. Los nodos 
siguen trabajando y aĂąaden un nuevo bloque a la cadena (negros), haciendo que los 

Figura 5: Cadena de Bloques. Fuente: Navarro, 2017 



 TecnologĂ­a Blockchain, Smart Contracts y Caso Swap. DescripciĂłn, EvoluciĂłn, Aplicaciones y Tendencias 
 

TECNOLOGÍA BLOCKCHAIN: DESCRIPCIÓN  
 

 15 

nodos trabajando en la horquilla morada dejen de hacerlo para trabajar sobre la cadena 
mĂĄs larga dejando esta huĂŠrfana u orphan block. La probabilidad de que se siga 
generando una y otra vez el mismo bloque simultĂĄneamente es poco probable. Los 
bloques en la cadena de Bitcoin son generados cada 10 minutos. Si un bloque es 
generado, verificado y aĂąadido a la red en un menor tiempo, el mismo proceso para 
encontrar el siguiente se actualizarĂĄ para que sea mĂĄs laborioso de encontrar para asĂ­ 
siempre mantener los 10 minutos y no propiciar un auge de bloques no pertenecientes a 
la cadena principal. (Navarro, 2017) 

 
Todo el trabajo que realizan los nodos para mantener la veracidad y transparencia de la 
cadena es consecuencia directa de su trabajo computacional o CPU work, y tiene como 
Ăşnico objetivo el de mantener la fisionomĂ­a del sistema de seguridad y consenso ideado 
por Nakamoto ante posibles atacantes o potenciales fraudes dentro de la misma.  

 
 El algoritmo de Consenso 

 
Los mineros son los encargados de generar nuevos bloques para la cadena. Cada bloque 
permite llevar a cabo un registro pĂşblico de todas las transacciones que se han realizado 
en un periodo concreto, almacenadas de forma Markle Tree, en honor a su creador: 
Ralph Markle. (Nakamoto, 2008). El proceso para aĂąadir un bloque nuevo, y que este 
sea de aceptaciĂłn consensuada es el que sigue.  
 
Los mineros trabajan con la informaciĂłn criptogrĂĄfica del bloque anterior, el Parent 
Hash, el nBits que se indique por el algoritmo, el Markle Tree Hash Root que agrupa 
los valores hash de las transacciones validadas, culminado en el Root Hash, como se 
ilustra en la figura 6, y registrarlo con el fin de reducir el espacio ocupado por cada 
transacciĂłn emplazando asĂ­ muchas mĂĄs de las que se podrĂ­an si se almacenaran todas 
y cada una de ellas de forma individual. (Navarro, 2017). El Nonce ha de coincidir con 
ciertos aspectos relacionados con la dificultad de encontrar el valor hash del bloque y 
una marca Time stamp que indica cuando se encontrĂł el valor en cuestiĂłn sea este vĂĄlido 
o no. Este mĂŠtodo de prueba y error que realizan los nodos mineros de una red pĂşblica 
es el llamado SHA-256 por los 256 caracteres de los que se forma. (Zheng Z. X., 2017)



 TecnologĂ­a Blockchain, Smart Contracts y Caso Swap. DescripciĂłn, EvoluciĂłn, Aplicaciones y Tendencias 
 

TECNOLOGÍA BLOCKCHAIN: DESCRIPCIÓN  
 

 16 
 
 

 
 
 

 
 
 
 
 
 
 
 
 
 
Cuando un minero encuentra el hash, los demĂĄs han de validar dicho valor. Para llegar 
a validar un bloque la mayorĂ­a de representaciĂłn de la cadena, el >=51% de los mineros, 
ha de consensuar que este es la Ăşnica representaciĂłn de la realidad. Una vez probado 
que las transacciones son validas y que el target value es el autĂŠntico, se considera que 
hay consenso y se aĂąade el bloque a la red codificado por el valor hash encontrado. Por 
Ăşltimo, se distribuye la nueva cadena actualizada a todos los ordenadores participantes 
de la misma. (Zheng Z. X., 2017) 
 
La estrategia de consenso PoW precisa de complicados cĂĄlculos para encontrar valores 
hash tanto para transacciones como bloques. (Nakamoto, 2008) Para que todo el proceso 
sea rentable para los mineros, ya que en definitiva el POW se traduce en fuerza CPU y 
gasto de energĂ­a por su parte, Nakamoto propone un sistema de incentivos a aquellos 
que encuentren los valores autĂŠnticos. En la red Bitcoin el incentivo es una cierta 
cantidad de la misma criptomoneda o token, directamente ligada a la dificultad y, por lo 
tanto, requerimiento energĂŠtico que se deriva de encontrar el target value de un bloque. 
Para el proceso de validaciĂłn de transferencias se recompensa con un pequeĂąo monto 
de la misma, tambiĂŠn relacionada con la dificultad (Swanson, 2015). CuĂĄnto mayor sea 
el nĂşmero de mineros, mĂĄs probable es que estos sean honestos y menor es la 
probabilidad de que la red sufra un ataque. (Nakamoto, 2008) 

  
En esencia, la tecnologĂ­a blockchain 1.0 ofrece un sistema de base de datos distribuida que 
junto a la criptografĂ­a y la informĂĄtica permite generar confianza entre usuarios a travĂŠs de la 
tecnolo";"""date"",""2020-06-14T14:59:07Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""2"",""6""
""pdf:PDFVersion"",""1.3""
""pdf:docinfo:title"",""Microsoft Word - TFG first draft.docx""
""xmp:CreatorTool"",""Word""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dcterms:created"",""2020-06-14T14:59:07Z""
""language"",""es""
""Last-Modified"",""2020-06-14T14:59:07Z""
""dcterms:modified"",""2020-06-14T14:59:07Z""
""dc:format"",""application/pdf; version=1.3""
""title"",""Microsoft Word - TFG first draft.docx""
""Last-Save-Date"",""2020-06-14T14:59:07Z""
""pdf:docinfo:creator_tool"",""Word""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2020-06-14T14:59:07Z""
""meta:save-date"",""2020-06-14T14:59:07Z""
""pdf:encrypted"",""false""
""dc:title"",""Microsoft Word - TFG first draft.docx""
""modified"",""2020-06-14T14:59:07Z""
""Content-Length"",""1745783""
""pdf:hasMarkedContent"",""false""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""meta:creation-date"",""2020-06-14T14:59:07Z""
""created"",""2020-06-14T14:59:07Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""51""
""Creation-Date"",""2020-06-14T14:59:07Z""
""resourceName"",""TFG_ADE_VILAR_FERRAN_JUL20.pdf""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""310"",""7"",""2708"",""3913"",""3043"",""733"",""3014"",""1540"",""1787"",""979"",""2116"",""2249"",""2591"",""2304"",""2376"",""2069"",""735"",""2610"",""2774"",""1845"",""2356"",""2541"",""1528"",""1743"",""1229"",""2402"",""2967"",""2600"",""2294"",""2449"",""1428"",""2567"",""3284"",""2973"",""2616"",""891"",""2910"",""3160"",""1934"",""3199"",""2173"",""3151"",""957"",""2949"",""3282"",""1142"",""2046"",""551"",""1004"",""1492"",""1360""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""producer"",""macOS VersiĂłn 10.15.2 (CompilaciĂłn 19C57) Quartz PDFContext""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""macOS VersiĂłn 10.15.2 (CompilaciĂłn 19C57) Quartz PDFContext""
""pdf:docinfo:created"",""2020-06-14T14:59:07Z""
";https://scholar.google.ch/scholar?start=950&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098769-116;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Analysing the Evolution of Permissioned Blockchain in Financial Sector;SK Lee ;2020 norma.ncirl.ie;;"… environment, one virtual machine (VM) is setup in the Oracle Virtual Box version 6.1.8. The VM

has 1 CPU Intel PRO/1000 MT Desktop (NAT) and 2GB of RAM. All requirements and

dependencies are installed together with the Hyperledger Fabric blockchain framework in VM …";Les 2 versions;Version HTML;[PDF] ncirl.ie;http://norma.ncirl.ie/4571/1/seankhyelee.pdf;"
 
 

 
 
 
 
 
 
 
 
 
 

 

Analysing the Evolution of Permissioned 

Blockchain in Financial Sector 
 
 
 
 

 

MSc Research Project 
 

FinTech 
 
 

 

Sean Khye Lee  

Student ID: x19116888 
 
 
 

School of Computing 
 

National College of Ireland 
 
 
 
 
 
 
 
 
 
 
 

Supervisor: Victor Del Rosal 



 

 
National College of Ireland 

 

MSc Project Submission Sheet 

 

School of Computing 

 

Student 

Name: 

Sean Khye Lee 

……..…………………………………………………………………………………………………………… 

 

Student ID: 

X19116888 

……………………………………………………………………………………………………………..…… 

 

Programme: 

MSc in Fintech 

……………………………………………………………………… 

 

Year: 

2020 

………………………….. 

 

Module: 

Research Project 

………………………………………………………………………………………………………….……… 

 

Supervisor: 

Victor Del Rosal 

………………………………………………………………………………………………………….……… 

Submission 

Due Date: 

17th August 2020 

………………………………………………………………………………………………………….……… 

 

Project Title: 

Analysing the Evolution of Permissioned Blockchain in Financial Sector 

………………………………………………………………………………………………………….……… 

Word Count: 

6929 24 

……………………………………… Page Count…………………………………………….……. 

 

I hereby certify that the information contained in this (my submission) is information 

pertaining to research I conducted for this project.  All information other than my own 

contribution will be fully referenced and listed in the relevant bibliography section at the 

rear of the project. 

ALL internet material must be referenced in the bibliography section.  Students are 

required to use the Referencing Standard specified in the report template. To use other 

author's written or electronic work is illegal (plagiarism) and may result in disciplinary 

action. 

 

Signature: 

 

……………………………………………………………………………………………………………… 

 

Date: 

 

……………………………………………………………………………………………………………… 

 

PLEASE READ THE FOLLOWING INSTRUCTIONS AND CHECKLIST 

 

Attach a completed copy of this sheet to each project (including multiple 

copies) 

□ 

Attach a Moodle submission receipt of the online project 

submission, to each project (including multiple copies). 

□ 

You must ensure that you retain a HARD COPY of the project, 

both for your own reference and in case a project is lost or mislaid.  It is 

not sufficient to keep a copy on computer.   

□ 

 

Assignments that are submitted to the Programme Coordinator Office must be placed 

into the assignment box located outside the office. 

 

Office Use Only 

Signature:  

Date:  

Penalty Applied (if applicable):  



1 
 

 

 
 

Analysing the Evolution of Permissioned Blockchain 

in Financial Sector 
 

Sean Khye Lee 

X19116888 
 

 

Abstract 

Blockchain has become part of the Fintech development to disrupt finances, increase 

technology adoption and eventually provide the alternative solution for banking industry. 

Hyperledger, permissioned blockchain platform uses smart contracts to function as normal 

application without any intermediaries. The smart contract was extended to include the financial 

sector such as the bank. Various tasks related to blockchain technology in bank to enhance data 

security and regular interactions between customers had been implemented. A Multon Dapp for 

the Hyperledger Fabric has been proposed in financial sector using the Hyperledger Composer 

tool. Tools use are the Oracle Virtual Box, Sublime Text, Angular, GitHub, command line 

interface, Hyperledger Composer, Apache JMeter, and Tableau. Security and scalability in the 

application have been well evaluated. Results show that security is protected by the unique 

identity for Hyperledger Composer while the transaction in the application is secured by the 

transaction id and timestamp. Not only that, different experiments are conducted successfully in 

JMeter to compare the average response time with the different number of users. Finally, all the 

codes are executed in the design product is finalised in the GitHub repository. 

 

1 Introduction 
 

Fintech has influenced the traditional financial sector. After the financial crisis of 2008, the 

financial sector’s landscape shifted due to the increased financial supervision and development 

in financial technology. World Economic Forum (WEF) suspected in 2016 that blockchain 

technology could revolutionise banking services in the world by creating a network that 

directly links customers and businesses (Yoo, 2017) 1. Blockchain could bring significant value 

to a range of financial services activities ranging from commercial finance to payments, 

settlement of shares and adherence to regulations. So, they could contribute to overcoming 

certain traditional bank inefficiencies, such as the transfers of foreign exchange (FX), 

increasing existing business networks and growing discoverability and trust working with bank 

payment and messaging systems. The application of blockchain technology in commercial 

banking undermines traditional financial banking. 

The blockchain uses ‘Smart Contracts’ that automatically record and carry out a 

transaction that can dramatically reduce costs (Ahmed & Kumar, January 10-11, 2019). 

Blockchain’s benefits in automating finance processes are immense and can save costs and 

time to achieve every transaction. The explanation that blockchain technology fascinates the 

 
 
1 https://www.weforum.org/press/2016/08/blockchain-will-become-beating-heart-of-the-global-financial-system/ 

https://www.weforum.org/press/2016/08/blockchain-will-become-beating-heart-of-the-global-financial-system/


2 
 

 

financial industry is that blockchain features enable people to build confidence and 

accommodate to new banking technology. If blockchain is widely implemented, banks will 

need to build a framework to construct and operate on a genuine worldwide basis using 

frameworks based on this revolutionary invention, and to minimise costs and exceptions 

rapidly and accurately. Therefore, the use of blockchain in banking would definitely contribute 

to a better banking system. 

 

The figure 1 shows the adoption rate for FinTech worldwide in 2019. FinTech adoption has 

gained popularity across several nations such as China, India, Russia and South Africa. 

 

 

Figure 1: Worldwide Adoption Rate of Fintech (%) 2 

1.1 Motivation 

 

Commercial banks act as the critical value for the countries must comply with the privacy and 

security regulations such as GDPR. Being a special financial company, the commercial bank 

faces more financial risks than the traditional banking. Therefore, all bank requires to 

coordinate data security and track internal space limitations to protect against leakage of 

information. The geographical distribution of bank infrastructure in the modern world 

complicates this task: the existence of branches, cash distributors and other services through 

which the headquarters interacts through information (Popova & Butakova, January 28-31, 

2019). Geographically distributed systems should also be secured against internal failures 

leading to data loss and application disruption.  

Additional criteria for business-use applications include scalability, security, privacy, 

confidentiality and integrity (Ermyas Abebe, December 9-13, 2019). Such conditions led to the 

development of permissioned blockchain networks. Permissioned blockchains have emerged 

as an alternative to permissionless blockchains (in which anyone may participate, for example, 

Bitcoin and Ethereum) to tackle the need for operating blockchain technology among a variety 

 
 
2 https://eyfinancialservicesthoughtgallery.ie/wp-content/uploads/2019/09/ey-global-fintech-adoption-index.pdf 

87 87
82 82

76 75 73 72 71 71
67 67 67 67 66 64 64 64 64

58 56
51 50

46
42

35 34

0

10

20

30

40

50

60

70

80

90

100

C
h

in
a

In
d

ia

R
u

ss
ia

 S
o

u
th

 A
fr

ic
a

C
o

lu
m

b
ia

P
er

u

N
e

th
e

rl
an

d
s

M
ex

ic
o

Ir
el

an
d

U
K

A
rg

en
ti

n
a

H
o

n
g 

K
o

n
g

Si
n

ga
p

o
re

So
u

th
 K

o
re

a

C
h

ile

B
ra

zi
l

G
e

rm
an

y

Sw
ed

en

Sw
it

ze
rl

an
d

A
u

st
ra

lia

Sp
ai

n

It
al

y

C
an

ad
a

U
SA

B
el

 &
 L

u
x*

*

Fr
an

ce

Ja
p

an

Source: Adapted from EY Global Fintech Adoption Index 2019

https://eyfinancialservicesthoughtgallery.ie/wp-content/uploads/2019/09/ey-global-fintech-adoption-index.pdf


3 
 

 

of recognised and identifiable users who need special access to the blockchain network 

(Vukoli´c, April 2, 2017). This idea behind permissioned blockchains is particularly interested 

in the business applications of blockchain technology and distributed ledgers, in which 

participants need some ways to recognise each other without actually trusting each other 

entirely. There are today a broad variety of protocol and application choices for developing 

approved networks. The Hyperledger Project, a popular Linux Foundation3 open-source 

initiative dedicated to introducing blockchain technology to businesses with a strong emphasis 

on permissioned blockchains. 

1.2 Research Question 

 

“How can Hyperledger Fabric for Bank Dapps be implemented in private blockchain to 

achieve security and scalability for commercial banking applications?” 

1.3 Objective 

 

The literature uses to generate this project is: Journal or conference papers along with reports 

from existing international institutions. A reviewed of the literature allows us to identify 

contributions to the issue that contributed to the research question being proposed. While there 

have been abundant of literature discussed the security and scalability of blockchain technology 

but there has been only minimal work in connection with the blockchain technology in the 

banking sector. This study aims to show how the Hyperledger Fabric Multon Dapp with 

Hyperledger Composer is able to access security and scalability efficiency. 

 

This project is organised as follows. Section 2 discusses the related works regarding the 

blockchain in financial sector and comparison of blockchain platform. Section 3, 4, and 5 show 

the research methodology, design specification, and implementation of Multon Dapp 

respectively. Section 6 explains the result in detail about the performance of security and 

scalability. Last section defines the conclusion which outline the future work of the research. 

 

2 Related Work 
 

2.1 Why Blockchain in Financial Sector? 
 

One of these interviewees in (Chang, et al., 2020) said “The blockchain is decentralised, while 

the bank is a centralised system. If the underlying technology of the blockchain can be used to 

make a centralised system, I think the blockchain technology can be used in the banking 

industry.” Wu & Duan (June 21-23, 2019) explored the benefits of blockchain technology by 

commercial banks on the following aspects such as distributed ledger structure, consensus 

process, and asymmetric cryptography. The implementation of blockchain in commercial 

banks can effectively reduce transaction costs and increase banks’ operational efficiencies, 

 
 
3 https://www.hyperledger.org/about 

https://www.hyperledger.org/about


4 
 

 

particularly in billing, cross-border payment and asset securitisation. Lastly, blockchain 

technology will reduce transaction costs on both sides and improve the commercial bank's 

operational efficiency and management. Sakho, et al. (December 6-9, 2019) set up a private 

and secure blockchain to reduce transaction costs, trust problems and theft and falsification of 

banking details. This system implemented user transactions and then encrypted information for 

bank transactions on the blockchain. Blockchain will help banks to monitor and evaluate all 

banking system activities.  

Popova & Butakova (January 28-31, 2019) examined the using of blockchain 

technology without tokens to secure information on banking transactions, i.e. payments, card 

information, participant names etc. Thus, the blockchain is a tool that will alleviate the 

processes of maintenance of integrity and unique data on banking transactions when 

implemented in the banking system without mining and tokens and will allow its 

implementation through smart contract processes to reduce the number of participants in 

overseeing such transactions. Singh, et al. (September 28-29, 2018) presented the proposed 

Secure E-Wallet Architecture based on Digital Ledger Technology (DLT) from various banks 

and participating institutions that use blockchain for the India financial sector. The architecture 

of interoperability between e-wallets from different banks or organisations is also implemented 

by a swarm-based peer to peer network. The proposed solution would reduce the demand on 

the banks’ Core Banking Solution while reducing the burden on the servers at the data centres. 

Abdulkader, et al. (July 30-31, 2019) analysed the potential security risks and economic 

benefits of a National Central Bank (NCB), which seamlessly provides all private banks with 

the alteration of the Digital Fiat Currency (DFC) instead of paper money. Thus, adopting an 

Intelligent Blockchain-based Management System (IBMSDC) as a methodology for the design 

of a management system that handles, monitors, and protects digital currencies and 

transactions. The proposed model combined distributed and centralised functionality 

intelligently to provide consumers with more security and privacy. Big payments had forced 

financial institutions to adopt a more effective, reliable and secure Real Time Gross Settlement 

System (RTGS).  

2.2 What is Hyperledger Fabric-Composer? 

 

Hyperledger is one of the private networks developed by Linux Foundation which allowed to 

host a business network of all kinds. Researchers explained a brief insight into blockchain 

platforms and an examination of exactly the definition of Hyperledger Fabric and designed 

steps of the Hyperledger Composer tool (S, et al., May 15-17,2019). Hyperledger Composer is 

a series of blockchain modelling software (Košt’ál, et al., 2019). It provides a platform to speed 

up the creation of Hyperledger Fabric apps that run on top of the Hyperledger Fabric. 

Successfully a study on the Composer web browser has been performed to create a quick 

transaction in blockchain and the use of Hyperledger Composer certainly simplifies work and 

takes less time compare to Hyperledger Fabric. 

Adoption of a business network requires model file, JavaScript file, and access control 

rule file to archive as business network archive file and deployed as a Hyperledger Fabric in 

local or cloud distributed construction (Tanwar, et al., 2020). This JavaScript file on the 

business network blockchain is ideal for a private business application blockchain (Kim, et al., 



5 
 

 

2020). Before deployment in a Hyperledger Fabric, it is compatible with any other alteration 

but is purely secure and once transactions made are irreversible, cannot be modified or 

removed. 

2.3 Why using Hyperledger Fabric in Consumer Banking Application? 

 

Scalability is a commonly discussed issue for existing blockchain technology. Pongnumkul, et 

al. (July 31-Aug.3, 2017) performed a performance review of Hyperledger Fabric and 

Ethereum through private deployment blockchain systems for a variety of transactions. Based 

on various transactions, the experimental results showed that Hyperledger Fabric constantly 

exceeds Ethereum across all measurement methods such as time, latency and throughput. Hao, 

et al. (June 26-30, 2018) proposed a framework for evaluating the efficiency of consensus 

algorithms on Ethereum and Hyperledger Fabric’s private blockchains platforms. Through 

quantitative latency and throughput analysis, they obtained results from the performance 

evaluation of consensus algorithms with different transaction numbers. The Practical 

Byzantine Fault Tolerance (PBFT) of Hyperledger Fabric continuously exceeded the Proof of 

Work (PoW) of Ethereum in terms of latency and throughput at different workloads.  

Kuzlu, et al. (July 14-17, 2019) examined the impact of network workload on the 

throughput, latency and scalability of the Hyperledger Fabric Architecture. It had been shown 

that up to 100,000 participants in the selected AWS EC2 instance can be supported by the 

implementation of the Hyperledger Fabric platform. Wang, et al. (July 2-7, 2018) introduced 

an end-to-end RTGS prototype based on a Hyperledger Fabric blockchain platform. The 

prototype supported gross settlement, gridlock settlement and interbank payment 

reconciliation. This project had been shown to provide more efficient and secure payment 

service on blockchain networks in businesses. Lee, et al. (2020) presented a time bank system 

based on the Hyperledger Fabric framework, which is one of the permissioned networks of the 

blockchain. This research designed and created the time bank system which enables the 

blockchain to run and record all service-related processes. Developing the blockchain time 

bank network benefits the time credit transaction, which plays the role of digital currency on 

the network. In addition, the proposed time bank also maintains a grading system allowing its 

members to grade each other to reflect their satisfaction with the system’s results. The idea to 

use blockchain to implement grading and reputation had been demonstrated to increase mutual 

trust among networked members and to enhance the security of the system as a whole. 

 

Table 1 below show the different blockchain platform in metric which differentiate the public 

blockchains and permissioned blockchains. 

 

 

 

 

 

 

 

 

 



6 
 

 

Table 1: Comparison between different Blockchain Platform (Source: Chua, et al., April 2-4, 

2019; Ranjan, et al., August 8-10, 2019; Dinh, et al., May 14-19, 2017) 

 
 

3 Research Methodology 

3.1 Overview for Multon Bank Dapp 

 

Proposed bank decentralised application (Dapp) known as Multon is used in this project to test 

the scalability and security of this system with the integration of Hyperledger Fabric through 

the smart contract called chaincode. Operating with Hyperledger Composer creates the 

blockchain sample network displayed in this project. The Hyperledger Composer is built and 

then exported into three separate files as an archive file and ready for deployment. The 

environment contains tutorials, documentation, samples and a forum for community support to 

promote success in its use. We can also test and expose using Hyperledger Composer API: 

Applications call for communicating API transactions with the network of the business. Web 

browser is tested in composer playground(http:/composerplayground.mybluemix.net/) in our 

PC. Finally, Angular is used to build the front-end from the REST API network. 

3.2 Oracle Virtual Box 

 

In the development environment, one virtual machine (VM) is setup in the Oracle Virtual Box 

version 6.1.8. The VM has 1 CPU Intel PRO/1000 MT Desktop (NAT) and 2GB of RAM. All 

requirements and dependencies are installed together with the Hyperledger Fabric blockchain 

framework in VM. Prototype implementation is chosen to launch the Hyperledger Fabric 



7 
 

 

framework and accelerate the development using the Hyperledger Composer tool as an open 

development platform and system that will facilitate the development of Hyperledger Fabric 

blockchain applications. These elements are used on a single host and execute a Docker runtime 

environment as containers to run the chaincode. After the blockchain network is developed, 

the Multon business network is built and implemented into the blockchain network. 

3.3 Smart Contract for P2P Bank Dapp 

 

 
Figure 2: Proposed Multon Bank Dapp 

 

Figure 2 show the component of the proposed Multon Bank Dapp. The front-end decentralised 

application (Dapp) known as Multon can interact with smart contract with interface develop 

using Angular. REST API is used as medium to connect frontend with the implementation of 

Node JS. The analysis in this report develop the bank contract for P2P and the following 

subsections describe the sharing platform. P2P Bank network is regarded as business network 

which account as an asset. The business network consists of entities working together to 

accomplish a certain mission. There should be certain rules regulating their dealings with 

various people, including how and when transaction should be carried out, who should be 

involved and how payment should be handled. Through blockchain technology, rules 

governing a transaction are referred to as smart contract, a digital arrangement between the 

distributed parties. The design steps are as follows. (1) Register for customers (2) Create the 

smart contract in blockchain network (3) Managing access control prior block verification (4) 

Store transaction details in chaincode (5) Integrate the smart contract and Dapp in front-end. 

3.3.1 The role of entity in the smart contract network 

 

For the creation of smart contracts, the business service layer is necessary and involves creating 

transactions and sending messages. The internal process layer includes the network detection 

by new network members, details display, block verification and construction of the latest 



8 
 

 

transaction block to be applied to the blockchain network. Below are the terms used when 

building the smart contract. 

 

Define participants: There are three functions for customers to register their basic platform 

information, including the ‘customerId’, ‘firstname’, and ‘lastname’. 

 

Define assets: Data owned by customers like account Id, balance, message, and status. 

 

Define transactions: A unique account Id is used to identify different asset in order to track 

back the customer easily. Users can submit the four types of transaction such as transfer, 

deposit, withdraw, and message. 

 

Access Control: Limit the access control between owner and customers over the business 

network. For example, all customers can read resources and submit the transaction while owner 

has the full access to customer resources and assets. However, once the transaction was 

submitted, the result cannot be deleted or modified. 

 

Chaincode: Complying access control policies for viewing or modifying key value pairs or 

other information in the database. 

 

Blockchain: Blockchain is used as an application controller to monitor access control policies 

and maintain the integrity of the customer data. 

 

Front-end: A decentralised web application is implemented with the REST API which act as a 

support system. 

3.4 Performance Evaluation  

 

The evaluation of system performance in relation to scalability and security in data processing 

is another significant consideration.  

3.4.1 Security 

 

Chaincode is strictly defined and cannot be modified. When the chaincode is installed, the 

system will provide the computed hash of the chaincode for the name space of the chaincode. 

Thus, if another pair has different binary code and tries to use it, it won’t be executed by the 

pair. Furthermore, security of Multon Dapp can also be proved by Unique Id and timestamp 

for each transaction when customers transfer, deposit, withdraw, and message to other peer.  

 

 

 

 



9 
 

 

3.4.2 Scalability 

 

Five experiments are conducted in the result and evaluation section using Apache JMeter4 on 

the REST API, where thousands of users accessed the framework for transaction data already 

in the blockchain database.  Before the tests, the transaction data is loaded manually into the 

blockchain. Apache JMeter is setup to send GET requests to REST Server at 

http://localhost:3000/explorer/#/AccountTransfer. History of Account transfer is collected as 

it is the most common activity carried out by participants of the blockchain network. 

 

4 Design Specification 
 

In figure 3, Multon Dapp, blockchain-based decentralised website framework on the 

Hyperledger Fabric-Composer Network is introduced and used to test the access control 

mechanism.  

 

 
Figure 3: Client application back-end framework 

4.1 Business network archive file structure 

 

There are three files for the development of an application blockchain.  

 

• Assets, participants and transactions in Model File(.cto) 

 

 
 
4 https://jmeter.apache.org/ 

http://localhost:3000/explorer/#/AccountTransfer
https://jmeter.apache.org/


10 
 

 

• Transaction logics in JavaScript are written and stored in Script File (.js) 

 

• The Rules for access system are stated in Access Control File (.acl) 

 

All these files are then combined into business network archive file (.bna) and ready for 

deployment in a Hyperledger Fabric environment. 

 

 
Figure 4: Cto Model 

 

In this model, the asset is account, participants are customers, and transaction is transfer, 

deposit, or withdraw money for various customers require for the project as shown in figure 4. 

Initial total amount in which the project participants are free to withdraw, transfer or deposit 

amounts are made. Each participant has an asset (account). When ‘AccountTransaction’ is 

submitted the transaction processor function is called. The function is passed to the participant 

and the amount of money to be transferred, withdrawn or deposited. Not only that, customers 

can communicate each other using the message function. If all the constraints are met by the 

transaction parameters, the transaction will be reported in the registry. This transaction entry 

also includes a transaction ID with a time stamp upon submission of the transaction. When a 

transaction is submitted, the amount of money specifies will be withdrawn, transferred or 

deposited from the total amount. After submission, the registry of assets is updated so that the 

data is consistent. 

 

5 Implementation 

5.1 Hyperledger Composer Playground 

 

Hyperledger Composer Playground offers a user interface to plan, execute and check the 

business system. The mains of the playground allow customers to deal with business system 

with numerous blockchain systems of the organisation. It is displayed in the server 

(http://localhost:8080/login) as illustrated in figure 5. The playground homepage, where you 

can show each of the business network cards you have for your use. 



11 
 

 

 
Figure 5: Composer Playground Web Interface 

5.1.1 Define Tab 

 

In the define tab, the content of the program can be altered and you can render assets describe 

in the define section. You can also add or remove the file you like. The export button allows 

you to save your existing business network into your PC as .bna record. The define tab has the 

required model file as shown in figure 6. 

 

 
Figure 6: Model File Interface 

 

Here, a simple trade transaction is made. In order to make things simple, assets include 

attributes such as account Id, balance, messages, and status of the customer for each asset. 

Participants are identified and the transaction identity is created. Participants will have 

characteristics such as customer Id, first and last names. Participants are important because 

only participants are involved in transactions. After all the logics of the transaction are stated, 

the script file needs to be created as shown in figure 7. 



12 
 

 

 
Figure 7: Script File Interface 

 

Transaction involves the attributes like account transfer, deposit, withdraw, and 

message. In this script file, the Async function is defined to update the new customer 

immediately after the transaction is processed successfully. After that, the Access Control is 

defined in figure 8. 

 

 

Figure 8: Access Control Interface 

 

The access control file (.acl) for the business network characterises business network 

management and business access control for the specified users. The network access control 

uses the namespace multon.bc.bank to store all business network assets. Before transaction, 

new customers and new account are added to allow for transaction in the test tab. 



13 
 

 

5.1.2 Test Tab 

 

In the test tab, you can check the usability of the business network card by using the customer 

and account types that have been identified on the define tab. 

 

 
Figure 9: Customer Interface 

 

The detail of customer, account and registry are reported to the left of the test tab as 

shown in figure 9. When you click on customer, account or all transactions, a registry will open 

that displays every complex occasion of that kind. For example, when you click customer, it 

will display a registry displaying the list of all customers. If you open a test tab for the first 

time, the registries will soon be found empty after selection. In each registry, each customer 

can make transaction through deposit, withdraw, transfer, or message. You can see in the ‘All 

transactions Registry’, a record of any transaction that has taken place, including some 

transactions that have been performed. For example, you can transfer money from one 

customer to another and you can see the changes of transaction record by clicking ‘All 

Transactions’.  

When you select the new participant option at the right top corner, you can build new 

participants that can register new customers. Here, a new customer is created as shown in figure 

10. 

 

 
Figure 10: Create New Participant 



14 
 

 

The customer ID or ID creates by the system as a random number and then the 

customer’s first and last name is defined. Once the customer ID has been created, it is shown 

in the figure below. 

 

 
Figure 11: Customer Registry 

 

The establishment of two customers takes place where the customer’s identification is 

given as 0001 and 0002 respectively. The account details are added in the asset registry as 

illustrated in figure 12. The details like the account Id, the owner of the asset, balance of money, 

status of transaction, and message are defined accordingly.  

 

 
Figure 12: Create new account 

 

The assets will be registered together with the ID, which is unique to all assets in figure 

13 after the details of account is stated. 

 



15 
 

 

 
Figure 13: Account Registry 

 

As the assets are done, the transaction is the next step. To make a transaction, first press 

the ‘Submit Transaction’ button in the left-hand corner. Then account transfer details are 

opened as shown in figure 14. 

 

 
Figure 14: Submit Transaction 

 

The transaction takes place between two customers, in which the customer transfers 

his/her funds to another customer. There are two important items to consider. The first thing is 

that the account ID should be associated with the customer ID we seek to exchange. Secondly, 

the customer we want to deal with the asset. The account we are attempting to transfer in here 

is Account ID 2823, which should be labelled as account: “resource: 

multon.bc.bank.Account#2823” to the new customer, which is the account ID 7078. The term 

‘new customer’ should be defined as “resource: multon.bc.bank.Account#7078”. Amount 

transfer is 200 euro. After clicking the transaction submitted, the transaction between customer 

0001 and customer 0002 would be successful. 



16 
 

 

After the transaction has ended, we can see that the amount of account with ID 7078 

had changed from 800 euro to 1000 euro previously owned by Customer #0002 would has 

moved to the customer’s ownership from customer #0002 to customer #0001 as shown in the 

figure as below. 

 

 
Figure 15: Interface showing the asset update after a valid transaction 

 

Transactions can be seen at the transaction registry from";"""date"",""2020-09-21T19:56:40Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.7""
""xmp:CreatorTool"",""MicrosoftÂŽ Word for Office 365""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dc:creator"",""SK Lee""
""language"",""en""
""dcterms:created"",""2020-09-21T19:56:40Z""
""Last-Modified"",""2020-09-21T19:56:40Z""
""dcterms:modified"",""2020-09-21T19:56:40Z""
""dc:format"",""application/pdf; version=1.7""
""xmpMM:DocumentID"",""uuid:4659D777-DC0A-491A-A79E-F4F8A7FBF19F""
""Last-Save-Date"",""2020-09-21T19:56:40Z""
""pdf:docinfo:creator_tool"",""MicrosoftÂŽ Word for Office 365""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2020-09-21T19:56:40Z""
""meta:save-date"",""2020-09-21T19:56:40Z""
""pdf:encrypted"",""false""
""xmp:CreateDate"",""2020-09-21T20:56:40Z""
""modified"",""2020-09-21T19:56:40Z""
""Content-Length"",""1356959""
""pdf:hasMarkedContent"",""true""
""Content-Type"",""application/pdf""
""xmp:ModifyDate"",""2020-09-21T20:56:40Z""
""pdf:docinfo:creator"",""SK Lee""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""SK Lee""
""dc:language"",""en-US""
""meta:author"",""SK Lee""
""pdf:producer"",""MicrosoftÂŽ Word for Office 365""
""meta:creation-date"",""2020-09-21T19:56:40Z""
""created"",""2020-09-21T19:56:40Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""26""
""Creation-Date"",""2020-09-21T19:56:40Z""
""resourceName"",""seankhyelee.pdf""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""251"",""2046"",""2830"",""2391"",""2680"",""3571"",""2815"",""1499"",""2044"",""1940"",""1022"",""1847"",""955"",""714"",""1277"",""737"",""1032"",""1344"",""1212"",""1031"",""2408"",""2348"",""3294"",""2274"",""2491"",""2513""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""Author"",""SK Lee""
""producer"",""MicrosoftÂŽ Word for Office 365""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""MicrosoftÂŽ Word for Office 365""
""pdf:docinfo:created"",""2020-09-21T19:56:40Z""
";https://scholar.google.ch/scholar?start=660&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098848-291;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Diskussionsbericht zu den Referaten von Tizian Troxler und Jan Lieder;M Beck ; Vertrauensschutz im digitalen Zeitalter, 2020  nomoselibrary.de;;"… Welt vorkommenden. So nannte er das Beispiel, dass ein Beschluss zwar korrekt

gefasst, jedoch fehlerhaft über ein Oracle in die Blockchain eingespeist oder nicht

ordnungsgemäß verarbeitet werde. Durch die Verwendung …";;null;null;;;;https://scholar.google.ch/scholar?start=840&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098743-60;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Special Issue of INFORMS Journal on Applied Analytics—Blockchain Analytics;D Conway, K Garimella, P Mitra… ; … Journal on Applied …, 2020  pubsonline.informs.org;;"… on-chain analytics to identify. ? trends and abnormalities on how the chain is growing

and being utilized; ? patterns of off-chain communication and external oracle usage;

and. • blockchain analytics, including measuring and improving …";Les 4 versions;;null;;;;https://scholar.google.ch/scholar?start=600&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098857-314;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Blockchain technology and traceability in the agrifood industry;N Patelli, M Mandrioli ; Journal of Food Science, 2020  Wiley Online Library;;"… The BCTs (originally invented for the Bitcoin cryptocurrency and then used for other financial … Each

major BC provider (Amazon Web Service, Oracle, and Ethereum) developed at least a proof of …

a BC traceability project for coffee (https://www.rwaltz.com/blockchain-coffee-supply …";Cité 4 fois;Les 4 versions;[PDF] wiley.com;https://onlinelibrary.wiley.com/doi/pdf/10.1111/1750-3841.15477;;;https://scholar.google.ch/scholar?start=860&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098844-290;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;[PDF][PDF] NFT. finance Leveraging Non-Fungible Tokens;DI Musan, J William, A Gervais ;2020 imperial.ac.uk;;"… In this report we will also discuss Decentralized Finance applications which are a subset of

DApps that create new protocols for managing and trading blockchain assets. 2.1.12 Oracles

An oracle is external data, connected to the blockchain and impacting it …";Autres articles;Version HTML;[PDF] imperial.ac.uk;https://www.imperial.ac.uk/media/imperial-college/faculty-of-engineering/computing/public/1920-ug-projects/distinguished-projects/NFT.-finance-Leveraging-Non-Fungible-Tokens.pdf;"
MEng Individual Project

Imperial College London

Department of Computing

NFT.finance
Leveraging Non-Fungible Tokens

Author:
Dragos I. Musan

Supervisor:
Prof. William J.

Knottenbelt

Second Marker:
Dr. Arthur Gervais

June 15, 2020



Abstract

The impact of Blockchain solutions is more apparent everyday and it has enabled
new types of economies to be developed which rely on different and improved prin-
ciples in comparison to regular financial markets.

As new solutions are added, decentralized finance become more flexible and
powerful, attracting more users.

In this project we have focused on the available applications, as well as the
different types of token that exist, such as Fungible and Non-Fungible Tokens.

Initially, we had a broad scope of the project, namely to add Over-the-Counter
derivatives to the Ethereum ecosystem and bring useful additions to the decentral-
ized finance ecosystem.

In order to lay a strong foundation to our problem and to approach the develop-
ment of the project, we have used techniques of Human Centered Design research.
By doing so, we have improved the initial problem statement and guided the imple-
mentation of the project.

While researching the differences between decentralized finance and regular finan-
cial markets, we have identified a preliminary need of having financial instruments
for Non-Fungible Tokens.

Therefore, we have set two main features as the objectives for the project:

• Leasing: which enables owners of Non-Fungible Tokens to lease out their
assets to other users.

• Lending: which gives the ability to holders of Non-Fungible Tokens to get
access to liquidity by locking their assets as collateral for loans.

Additionally, Over-the-Counter derivatives are an extension to this novel type of
marketplace which would add more sophisticated financial instruments such as For-
ward Contracts.

To achieve a solution to our problem, we developed Ethereum Smart Contracts
that contain the logic of the features mentioned above. Additionally, we have created
a website to facilitate the interaction of the users with this new type of peer-to-peer
network for leveraging of Non-Fungible assets.

Overall, the project resulted in a working solution, available to use on a testing
network.



Acknowledgements

This project marks the end of my Computing degree and was an incredible oppor-
tunity to work on something I am passionate about.

This could have not been possible without all the encouragement and guidance
from the people involved and I would like to thank the following:

• My project supervisor, Professor William Knottenbelt, for his support and for
trusting me with this project.

• Dr. Arthur Gervais for his advice, as well as his course, Principles of Dis-
tributed Ledgers, which gave me a strong background in Blockchain technolo-
gies.

• My personal tutor, Dr. Mark Wheelhouse, for his guidance throughout my
Imperial education.



Contents

1 Introduction 5
1.1 Blockchain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3 Problem Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.4 Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2 Background 7
2.1 Blockchain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.1.1 Ethereum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1.2 Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1.3 Mining . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.1.4 Proof-Of-Work . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.1.5 Addresses, Keys and Wallets . . . . . . . . . . . . . . . . . . . 8
2.1.6 Transactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.1.7 Forks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.1.8 Proof-of-Stake . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.1.9 Smart Contracts . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.1.10 Ethereum Virtual Machine . . . . . . . . . . . . . . . . . . . . 10
2.1.11 Decentralized Applications (DApps) . . . . . . . . . . . . . . . 11
2.1.12 Oracles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.1.13 Decentralized Autonomous Organizations . . . . . . . . . . . . 12

2.2 Ethereum Tokens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2.1 ERC-20 standard . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2.2 Trading ERC-20 tokens . . . . . . . . . . . . . . . . . . . . . . 12
2.2.3 ERC-721 standard . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2.4 Trading ERC-721 tokens . . . . . . . . . . . . . . . . . . . . . 14
2.2.5 ERC-1155 tokens . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.3 Decentralized Finance (DeFi) . . . . . . . . . . . . . . . . . . . . . . 14
2.3.1 MakerDAO . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.3.2 Uniswap and AMMs . . . . . . . . . . . . . . . . . . . . . . . 15
2.3.3 Decentralized Lending Pools . . . . . . . . . . . . . . . . . . . 16
2.3.4 Composability and ""Money Lego"" . . . . . . . . . . . . . . . . 16
2.3.5 Flash Loans . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.3.6 Decentralized Financial Crisis . . . . . . . . . . . . . . . . . . 18

2.4 ISDA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.4.1 Derivatives . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.4.2 ISDA Master Agreement . . . . . . . . . . . . . . . . . . . . . 19
2.4.3 Schedule and Confirmation . . . . . . . . . . . . . . . . . . . . 20

2



2.4.4 Smart Derivatives Contracts . . . . . . . . . . . . . . . . . . . 21
2.4.5 OTC derivatives trade life-cycles . . . . . . . . . . . . . . . . 21
2.4.6 Central Counterparty Clearing House . . . . . . . . . . . . . . 22
2.4.7 Financial products Markup Language . . . . . . . . . . . . . . 22
2.4.8 ISDA CDM . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

2.5 Derivatives in the blockchain space . . . . . . . . . . . . . . . . . . . 25
2.5.1 Hedgy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.5.2 Vega protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.5.3 Synthetix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3 Design and Requirements 27
3.1 Human Centered Design Research . . . . . . . . . . . . . . . . . . . . 27
3.2 Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.3 Low-fidelity borrowing and derivatives prototype . . . . . . . . . . . . 30

3.3.1 High-fidelity borrowing prototype . . . . . . . . . . . . . . . . 32

4 Implementation 34
4.1 Smart Contracts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

4.1.1 ERC-721 standard and OpenZeppelin . . . . . . . . . . . . . . 35
4.1.2 Leasing smart contract . . . . . . . . . . . . . . . . . . . . . . 36
4.1.3 Loans smart contract . . . . . . . . . . . . . . . . . . . . . . . 39
4.1.4 Deployment and testing . . . . . . . . . . . . . . . . . . . . . 43
4.1.5 Alternative Implementations . . . . . . . . . . . . . . . . . . . 44

4.2 DApp client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.2.1 Technologies used . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.2.2 High-level structure of the React project . . . . . . . . . . . . 47
4.2.3 Redux store . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.2.4 OpenSea Services . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.2.5 Web3 services . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
4.2.6 Managing the state of the Application . . . . . . . . . . . . . 54
4.2.7 Components and Assets . . . . . . . . . . . . . . . . . . . . . 55

4.3 Final UI elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

5 Evaluation 62
5.1 Smart Contract Security . . . . . . . . . . . . . . . . . . . . . . . . . 62
5.2 Gas Prices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
5.3 Human Centered Design Process . . . . . . . . . . . . . . . . . . . . . 64

5.3.1 Final iteration . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
5.4 Risks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
5.5 Comparison with existing tools . . . . . . . . . . . . . . . . . . . . . 68

5.5.1 Rocket LP DAO . . . . . . . . . . . . . . . . . . . . . . . . . 69
5.5.2 Lend721 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
5.5.3 Native leasing solutions . . . . . . . . . . . . . . . . . . . . . . 69

5.6 Automated Market-Making for NFTs . . . . . . . . . . . . . . . . . . 69

6 Conclusion 71
6.1 Reflection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
6.2 Platform Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
6.3 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

3



A Appendix A 74

B Appendix B 76

4



Chapter 1

Introduction

1.1 Blockchain

In 2009 Satoshi Nakamoto published the Bitcoin white paper and introduced the
idea of an online payments system which facilitates transfer of funds from one party
to another without the need of having a centralised financial institution.[1]

To achieve this, it uses a peer-to-peer network which validates transactions based
on an agreed consensus algorithm known as Proof-of-Work and proposes an alter-
native to traditional payment systems.

In the following years other types of blockchains have been developed in or-
der to improve on or showcase a different implementation to Bitcoin. One project
that we will particularly focus on is Ethereum which introduced the idea of ""smart
contracts"".

In 2013 Vitalik Buterin published the Ethereum white paper which proposed
a blockchain with a built-in Turing-complete programming language that can be
used by anyone to program any asset stored on this peer-to-peer network. The code
that gets executed is called a ""smart contract"" and led to the development of many
decentralized applications. [2]

The DApp (decentralized application) space saw a boom in 2017 with many
companies launched an ICO (initial coin offering) to raise capital and sell ""shares""
in the form of Ethereum tokens. This was conceptually similar to an IPO (initial
public offering), albeit done in the early stages of the project, without having any
users or even a working prototype.

By overpromising the possible applications of blockchain at that time, many
ICOs failed to deliver on their promises or to attract users. Within a year nearly
half of the projects that raised money using an ICO were closed and the price of
cryptocurrencies dropped sharply. [3]

1.2 Motivation

One of the first types of useful projects to emerge from this crash were the DeFi
(decentralized finance) projects which are leveraging the opportunity to replicate
traditional banking ideas and solve its shortcomings using blockchain technology.
Derivatives, lending platforms, decentralized exchanges and more, have all been
part of the DeFi revolution. [4]

5



Being newly developed, there are many opportunities for improvement in the
DeFi space by using existing solutions or adapting the concepts to new markets.

We set out to investigate the current shortcomings of DeFi and develop a novel
implementation with applicability to Non-Fungible Tokens.

Since we are targeting such a wide applicability and vast scope, we had to follow a
through method for design research in order to set the requirements for the problem.
To achieve this we have used Human Centered Design Techniques with multiple
iterations.

1.3 Problem Statement
Throughout the iterations of the Human Centered Design process we have estab-
lished different goals and built different prototypes that will be discussed in this
report.

The final goal was to add DeFi capabilities to Non-Fungible Tokens and bring
novel use cases to unique tokens.

Even though Non-Fungible Tokens have market value, the owners of those assets
do not have access to solutions for leveraging.

This would enhance their ownership and we will explain how it could potentially
work.

1.4 Contributions
Our contribution was to come up with a novel and marketable product in the DeFi
space addressed to owners of Non-Fungible Tokens.

Using Human Centered Design techniques we have built a peer-to-peer platform
that proposes two new use cases:

• Lending: which releases a new stream of capital to owners of Non-Fungible
Tokens by locking their asset as collateral for receiving a loan.

• Leasing: which enables owners to lease out their tokens to other users on the
platform for a fee.

In this report we will motivate why we have chosen this approach, how it could
be used and how we have implemented it.

On each stage of the implementation we have evaluated feedback from mentors
and potential users that will be explained and laid out accordingly. We felt that
this has provided a well-structured guide to our implementation and created a set
of requirements that are more likely to have applicability on the market.

6



Chapter 2

Background

2.1 Blockchain

A blockchain is a decentralized network which keeps transaction records and acts as
a source of trust. The data stored on the blockchain is immutable and updated by
the peer-to-peer network.

The blockchain is made of ""blocks"", which hold transactions that have been
broadcasted and verified as being valid.

Public blockchains are available for everyone to join and contribute to, in com-
parison to private blockchains which require permission from a central authority to
become part of.

Public blockchains are pseudo-anonymous because all transactions are public,
however it may be hard to link them to an identity.

2.1.1 Ethereum

Ethereum is a blockchain that builds on the concepts introduced by Bitcoin, there-
fore it has no central entity to handle the transactions and instead all events are
recorded on a blockchain.

It is an open and decentralized network, secured using a consensus algorithm
called Proof-Of-Work. Everything recorded on the blockchain is available to the
public.

Ethereum tackles similar problems to Bitcoin, having Byzantine fault tolerance,
defining how coins are mined and reaching a network-wide consensus.

Moreover, Ethereum enables the use of ""smart contracts"" which represent code
executable on the blockchain in a decentralized manner by the Ethereum Virtual
Machine.

This enables users to build Ethereum token systems which are Ethereum sub-
currencies.

By combining smart contracts and tokens, Ethereum opened up the possibility
to build a wide array of possible decentralized projects.

2.1.2 Nodes

The nodes are the participants to the blockchain. They are all connected to each
other in the peer-to-peer network. They have access to the blockchain and can

7



verifiy incoming transactions.
Full nodes require a full copy of the blockchain to operate and need a lot of

storage space. A user needs to run a full node to become a miner and contribute
to the blockchain. On the other hand, a lightweight node stores only the hashes
of the blocks and receives additional information from full nodes, so it occupies
significantly less space.

2.1.3 Mining

Through mining new transactions are added to the blockchain.
Miners are incentivized to compete with each other because finding the right

solution guarantees a reward in newly minted coins and transaction fees.
In comparison to Bitcoin, Ethereum does not have a fixed amount of possible

Ether than can be mined.
Once a new block has been mined and verified by the network, miners start

competing for the next one.

2.1.4 Proof-Of-Work

The consensus algorithm introduced by Bitcoin, Proof-of-work is also used in Ethereum.
It is an algorithm that miners try to solve in order to find a good solution (a suitable
hash) for the next block.

The difficulty of this algorithm can be adjusted as more miners join the network
and increase the hash rate.

It is innovative because it enables the network to agree on a set of rules used to
update the blockchain and allows free entry for anyone who is running a full node.
Additionally it has Byzantive fault tolerance meaning that is can handle failures and
bad actors that participate in the network.

2.1.5 Addresses, Keys and Wallets

A fundamental concept to blockchain is asymmetric cryptography.
A user can generate a random private key and use it to derive a public key.

Using the public key, the address of the user can be generated. At this address the
amount of funds is stored and the user can sign transactions from his address using
his private key. Those transactions have to be verified by the network using the
public key to check the origin.

Losing the private key means losing access to funds.
Users also have wallets to manage their funds as well as keys and addresses. In

the case of Ethereum the wallet can also interact with smart contracts and implicitly
decentralized apps.

2.1.6 Transactions

Transactions are messages that are signed by the address that has triggered them
and can change the state of the network.

The algorithm used for Ethereum transactions is Elliptic Curve Digital Signature
and has three main uses as explained below.

8



• Proof of authorization: The signature proves that the owner of the private
key is the one who has authorized the transaction.

• Non-repudiation: The proof of authorization is undeniable.

• Immutability of transaction data: The data of the transaction is im-
mutable.

The structure of a transaction on the Ethereum network is the following.

• Nonce: The number of transactions sent from a given address.

• Gas Price: The price that initiator of the transaction is willing to pay for its
execution.

• Gas Limit: The maximum amount of Gas.

• Recipient: The destination address that the transaction is calling. This can
be a different payable address or a smart contract.

• Value: The value in Ether associated with the transaction.

• Data: Binary data payload.

• v, r, s: Value of the signature of the transaction.

2.1.7 Forks

A ""fork"" of a blockchain can happen naturally when a parent block has multiple
children blocks. It can be observed when blocks are mined by different miners at
almost the same time. This is usually easily resolved when one child becomes part
of the blockchain.

However, sometimes in order to change the specification of a blockchain, a fork
with the new specifications has to be introduced. This can be done using a soft-fork
or a hard-fork.

A soft-fork introduces specifications which are backwards-compatible with the
network, so nodes that have not updated their software can still process transactions
as long as they follow the new rules. On the other hand, hard-forks bring changes
by loosening the rules of the blockchain, so the newly mined blocks may not be
verifiable by old nodes.

If this creates a debate, the operating nodes may choose to follow a preferred
implementation and two separate blockchains are created.

2.1.8 Proof-of-Stake

An alternative approach to Proof-of-Work is Proof-of-Stake, which calculates the
""stake"" of a node in the network by the amount of cryptocurrency that they hold,
instead of their computing power.

Ethereum is planning a hard-fork to switch to Proof-of-Stake with the launch of
Ethereum 2.0 because of its benefits in securing the network, while making it more
efficient.

9



2.1.9 Smart Contracts

In 1994 Nick Szabo, defined smart contracts as [6] ""a computerized transaction
protocol that executes the terms of a contract"".

The first blockchain to implement this idea was Ethereum [2] and it led to the
development of many applications, especially in the finance sector.

In comparison to Bitcoin, which allows limited scripting, Ethereum is a blockchain
on which code written in a Turing-complete programming language can be executed.

Once the code is written in a high-level language, it is compiled to low-level
bytecode and can be deployed on the Ethereum network by sending it to the special
0x0 address.

Next the contract is assigned its own address which can be used to access the
features of the contract and call its functions.

There are multiples high-level languages for writing Ethereum code, however our
language of choice is Solidity.

2.1.10 Ethereum Virtual Machine

The Ethereum virtual Machine (EVM) is a virtual state machine on the blockchian
which modifies its state by running smart contract code. [7]

It is a quasi-Touring-complete state machine, because the computation is bounded
by the fee allocated for a transaction. This fee is called ""gas"" and it is necessary to
avoid network-overuse and to make sure the blockchain is efficient. Anyone wanting
to run code on Ethereum can purchase gas with Ether (the currency of Ethereum).

The architecture is stack-based and there are three main components of storage:
[7]

• Memory: volatile, cleared for each message call. Reading is limited to 256
bits and writing to 8 or 256 bits.

It can expand when accessing a different location, however this operation costs
gas.

• Storage: persistent between calls and is more expensive to initialise or modify.

• Stack: all computations are performed on the stack, which has the bytecode
of the smart contract loaded.

The EVM instruction set includes the following operations: [8]

• Arithmetic and bit-wise logic operations

• Execution context inquiries

• Memory, Storage and Stack access

• Control flow operations

• Logging, calling, and other operators

10



Figure 2.1: The Ethereum Virtual Machine (EVM) Architecture and Execution
Context. [8]

2.1.11 Decentralized Applications (DApps)

Decentralized Applications or DApps are smart contract enabled platforms that run
on distributed computing systems.

There are a wide range of DApps on Ethereum, which users can interact with.
In this report we will also discuss Decentralized Finance applications which are

a subset of DApps that create new protocols for managing and trading blockchain
assets.

2.1.12 Oracles

An oracle is external data, connected to the blockchain and impacting it. Oracles
can be used with smart contracts to create DApps that act upon input coming from
off-chain.

This approach is low-trust but it is up to the users to verify and find real-world
data that they can rely on.

11



2.1.13 Decentralized Autonomous Organizations

Decentralized Autonomous Organizations or DAOs are organizations controlled by
token holders, similarly to shareholders.

The tokens issued by the DAO enable their respective owners to vote on matters
about the development of the organization and make decisions. Therefore the deci-
sion taking process is automated and a consensus is reached among the participants.

The tokens are transferable and the governance of the DAO is decentralized.

2.2 Ethereum Tokens
There are various types of tokens that can be built on Ethereum, usually used in
DApps. Tokens can be understood as an asset that lives on the blockchain, which
can be stored or managed using Ethereum addresses and smart contracts.

2.2.1 ERC-20 standard

ERC-20 tokens can be defined as a group of identical tokens, all with the same
properties. They follow the ERC-20 standard which includes a common set of rules
for creating and managing fungible tokens.

The use of ERC-20 tokens enables the creation of small economies that have
liquid markets for different use cases.

2.2.2 Trading ERC-20 tokens

ERC-20 tokens can be traded on multiple types of platforms such as:

• Regular exchanges

• Decentralized exchanges

• Automated liquidity pool which can enable seamless token swaps using Au-
tomated Market Making algorithms to determine the price of buying ERC-20
tokens.

More about ERC-20 tokens will be discussed in the DeFi subsection.

2.2.3 ERC-721 standard

On the other hand, ERC-721 tokens are Non-Fungible Tokens (NFT). This implies
that each token has a unique set of properties and values associated with it. [32]

Being unique makes ownership more desirable especially in the case of highly-
sought after tokens.

The ERC-721 standard is an interface that each smart contract which creates
ERC-721 tokens has to implement. [32]

There are multiple functions that enable interaction with NFTs such as:

• Finding the owner adderss of an ERC-721 token

• Approving the transfer of an ERC-721 token. Each address that we want to
transfer to to be approved before initiating the transfer.

12



• Checking the approved addresses of an ERC-721 token.

• Transffering the ERC-721 token

ERC-721 tokens have found applicability in many domains of the Ethereum
space, the most relevant being the following:

• Gaming: gaming items can be expressed as ERC-721 tokens. Each having
a unique set of properties and potentially being a power-up, in-game user
customization or any other utility.

• VR real estate: is real estate in Virtual Reality simulations defined as ERC-
721 tokens.

This could be a subsection of gaming, however it has a unique following com-
posed of both gaming and non-gaming enthusiasts that own those assets to
speculate on their market price.

• Collectibles: due to their uniqueness they are a perfect fit for collectible
items. Examples can range from football cards to CryptoKitties, which are
virtual pets, able to breed and create other unique tokens.

• Utilities: ERC-721 tokens can enable their owners to access resources. An
example of this would be ENS names for managing multiple addresses into one
readable string.

Figure 2.2: Cryptovoxels VR simulation Welcome property represented by an ERC-
721 token.[9]

13



2.2.4 Trading ERC-721 tokens

Similarly to ERC-20 tokens, ERC-721 tokens can also exchange ownership and be
traded for other tokens or Ether.

However, the way this is done is different. Since all ERC-721 tokens have unique
properties, Automated Market Making algorithms are not feasible to be imple-
mented.

The accepted way to trade them at the moment is to auction or sell them on peer-
to-peer marketplaces specific to NFTs, the largest at the moment being OpenSea.

This creates new economies for digital collectibles with impressive statistics for
a new type of asset: [29]

• 7 day trading volume of the top 3 kinds of NFTs is over 1,000 Ether.

• Decentraland, another VR simulation has a total volume of 44,000 Ether split
amongst 3,662 owners. This gives an average ownership of LAND properties
of around 12 Ether.

• The most expensive NFT sold in 2019 has been an F1 gaming item worth
415.9 Ether. [11]

Figure 2.3: ENS name being sold on OpenSea marketplace.

2.2.5 ERC-1155 tokens

The ERC-1155 is a new token proposal standard aimed at creating both fungible
and non-fugible tokens in the same contract.

This could be particularly useful for games that want to create more complex
in-game economies.

2.3 Decentralized Finance (DeFi)

Decentralized Finance protocols are DApps that enable interoperable protocols for
leveraging and trading exclusively ERC-20 tokens.

Currently there is close to 1bn USD of capital locked in DeFi, as of June 2020,
with the largest protocol being Maker. [13]

14



Figure 2.4: Total value locked in DeFi, taken from DeFi Pulse. [12]

2.3.1 MakerDAO

Maker is a DAO that offers multiple products such as:

• Oasis: non-custodial platform to exchange tokens or borrow and earn interest
using DAI, a decentralized stablecoin, soft-pegged to 1 USD.

• Migrate and Upgrade: enables moving of DAI and Collateralized Debt
Positions to newer versions.

• Maker Ecosystem: a marketplace to explore apps or services that user
Maker protocols or DAI.

• Governance Portal: the governance of the DAO is done with MKR tokens.
Participants can use MKR to vote for changes on the platform.

The target price of DAI is 1:1 USD and smart contracts try to keep the price
stable. When DAI is created, Ether has to be deposited into a Collateralized Debt
Positions (CDP). In exchange DAI will be created.

When returning DAI for the locked Ether, a stability fee has to be paid which is
used to incentivize or make loans in DAI more expensive, which in turn can affect
the price of DAI, making it lower or higher, respectively.

The stability fee is voted upon by the DAO community using MKR tokens.
However, the DAI price can fluctuate in case of unexpected ""Black Swan"" events

such as the one that occurred on March 12-13, 2020. Due to the low price of Ether
to USD, the total valued in USD locked in Maker dropped by almost 50% in a day
and the CDPs for DAI have become under-collateralized.

2.3.2 Uniswap and AMMs

Uniswap is a smart contract based Automated Market Maker that dynamically
calculates and adjusts the exchange rate for trading ERC-20 tokens.

In comparison to other decentralized exchanges (DEXs) it does not use order
book mechanisms.

AMMs use liquidity providers who deposit assets in different pools and can create
trading pairs using algorithms such as a Constant Product, which keep the product
of a pair of assets constant at trading times.

15



Figure 2.5: DAI price with emphasis on the Market Collapse of March 12-13, 2020.
Screenshot taken from Coingecko [12]

If we have two trading pairs of tokens X and Y, with x and y being the number of
tokens, the market price is determined such that the ratio of their product remains
constant. [43]

2.3.3 Decentralized Lending Pools

Other popular DeFi solutions are Decentralized Lending Pools (DLPs).
DLPs enable lending that does not rely on peer-to-peer Order Matching. They

work with liquidity providers for each token market. All the identical ERC-20 tokens
are gathered in a pool, that borrowers can take advantage of and get liquidity from,
providing they have deposited collateral.

Lenders instantly earn interest by providing liquidity and borrowers also earn
interest in the collateral that they post.

Some of the features that make DLPs superior to P2P lending markets are the
following: [45]

• Instant deposits

• Instant borrowing

• Different types of ERC-20 tokens as collateral

• Instant switching between fixed or variable interest rates for the loans

Preceding DLPs, there were DeFi platforms which enabled peer-to-peer lending.
However, since DLPs are a vastly superior solution with liquid secondary markets

and lower risk, platform such as ETHLend (P2P loans) have evolved into DLP
solutions, namely Aave. [44]

2.3.4 Composability and ""Money Lego""

There are a multitude of DeFi solutions many able to interact with each other and
pieced together as ""Money Lego"".

16



Figure 2.6: Screenshot of top assets in Aave. [12]

By combining different protocols, new financial tools can be created. For example
you can place your Ether in Market DAO, mint DAI and then use DAI in other
protocols to receive loans or keep them in a non-custodial wallet.

2.3.5 Flash Loans

Flash Loans are a new type of loan, exclusive to Ethereum DeFi, which enable
instant borrowing, with no collateral, by anyone, as long as the principal amount is
returned in the same block.

In case the principal is not returned the transaction can be reverted as if it never
took place.

The novelties of flash loans are the following: [46]

• No risk of default: as explained above, if the transaction fails due to the
user defaulting on his loan, the flash loan is not granted.

• No required collateral: Since there is no risk for the lender, there is no
required collateral.

• High Loan Size: The loan size can be as high as the liquidity pool it is taken
from.

There are vast use cases for Flash Loans and taking advantage of the ""Money
Lego"" property of DeFi, can enable users to benefit from complex opportunities no
matter what their address balance or trading history is.

Some use cases of Flash Loans are the following: [46]

• Arbitrage: Users can borrow liquidity and benefit from arbitrage opporuni-
ties between DEXs, witout being exposed to any risk. If their trade is success-
ful, they pay back the principal amount of the loan and any required interest.

• Wash Trading: This is a type of trading aimed at manipulating trading
volumes of assets and artificially increasing them using fake automated trades.

Flash loans could be used for achieving this, without owning any of the assets
traded, making use of the Lego Money property of DeFi and exchanging assets
back and forth in one atomic transaction.

• Collateral Swapping: CDPs, as used in MakerDAO for minting DAI, require
locking collateral, in this case Ether, until the DAI is returned.

17



However, the locked collateral in a CDP is exposed to risk of currency fluctu-
ation.

Flash loans can be used to mitigate th";"""date"",""2020-06-15T12:57:47Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2020-06-15T12:57:47Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.19 (TeX Live 2018) kpathsea version 6.3.0""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2020-06-15T12:57:47Z""
""created"",""2020-06-15T12:57:47Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-06-15T12:57:47Z""
""resourceName"",""NFT.-finance-Leveraging-Non-Fungible-Tokens.pdf""
""Author"",""""
""producer"",""pdfTeX-1.40.19""
""pdf:docinfo:producer"",""pdfTeX-1.40.19""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2020-06-15T12:57:47Z""
""Last-Modified"",""2020-06-15T12:57:47Z""
""dcterms:modified"",""2020-06-15T12:57:47Z""
""title"",""""
""Last-Save-Date"",""2020-06-15T12:57:47Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2020-06-15T12:57:47Z""
""meta:save-date"",""2020-06-15T12:57:47Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.19 (TeX Live 2018) kpathsea version 6.3.0""
""Content-Length"",""5667878""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""85""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""197"",""1695"",""549"",""1691"",""2082"",""25"",""1763"",""1669"",""1464"",""1977"",""1784"",""1746"",""666"",""1765"",""954"",""1249"",""1547"",""1245"",""1607"",""2087"",""1896"",""815"",""2004"",""1924"",""1108"",""1635"",""1272"",""1513"",""1795"",""865"",""1919"",""1151"",""979"",""691"",""1434"",""1516"",""2535"",""1578"",""1818"",""2112"",""1754"",""1850"",""1760"",""1772"",""1394"",""939"",""1979"",""1814"",""1631"",""1055"",""1395"",""1532"",""1772"",""1678"",""1438"",""1468"",""1603"",""843"",""1077"",""1336"",""2228"",""1057"",""586"",""1376"",""1655"",""1995"",""2267"",""2157"",""2225"",""1789"",""2044"",""1151"",""1373"",""1901"",""536"",""54"",""36"",""997"",""482"",""58"",""1553"",""1966"",""1789"",""1796"",""319""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-06-15T12:57:47Z""
";https://scholar.google.ch/scholar?start=830&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098769-112;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;The benefits of deploying smart contracts on trusted third parties;C Molina;Jimenez, I Sfyrakis, L Song…  arXiv preprint arXiv …, 2020  arxiv.org;;"… originally conceived for mediating the execution of payment operations in BTCs (Bitcoin's

cryptocurrency) … they operate as TTPs themselves adding cen- tralisation to a decentralised

blockchain. Decentralised oracles have been suggested for ameliorating the situation but at the …";Cité 2 fois;Les 3 versions;[PDF] arxiv.org;https://arxiv.org/pdf/2010.12981;"
The Benefits of Deploying Smart Contracts on
Trusted Third Parties

Carlos Molina–Jimenez
Computer Laboratory

University of Cambridge, UK
carlos.molina@cl.cam.ac.uk

Ioannis Sfyrakis
School of Computing

Newcastle University, UK
ioannis.sfyrakis@ncl.ac.uk

Linmao Song
Independent researcher

linmao.song@gmail.com

Hazem Danny Al Nakib
Independent fintech and regtech expert

hazemdanny.nakib@gmail.com

Jon Crowcroft
Computer Laboratory

University of Cambridge, UK
jon.crowcroft@cl.cam.ac.uk

Abstract—The hype about Bitcoin has overrated the potential
of smart contracts deployed on–blockchains (on–chains) and
underrated the potential of smart contracts deployed on–Trusted
Third Parties (on–TTPs). As a result, current research and
development in this field is focused mainly on smart contract
applications that use on-chain smart contracts. We argue that
there is a large class of smart contract applications where on–
TTP smart contracts are a better alternative. The problem with
on–chain smart contracts is that the fully decentralised model
and indelible append–only data model followed by blockchains
introduces several engineering problems that are hard to solve.
In these situations, the inclusion of a TTP (assuming that
the application can tolerate its inconveniences) instead of a
blockchain to host the smart contract simplifies the problems and
offers pragmatic solutions. The intention and contribution of this
paper is to shed some light on this issue. We use a hypothetical
use case of a car insurance application to illustrate technical
problems that are easier to solve with on–TTP smart contracts
than with on–chain smart contracts1.

Index Terms—smart contracts, on–blockchain, off–blockchain,
contract compliance, contract enforcement, contractual rights
and obligations.

I. INTRODUCTION

The publication of the Bitcoin paper by [1] in 2008 has
motivated the exploration of blockchains and smart contracts
in the development of innovative applications. There is a global
consensus on the potential of smart contracts for building
innovative applications across various sectors of industry and
government [2]. We agree with this view and consider that
there are smart contract applications that are conveniently
implemented on the basis of smart contracts deployed on–
chain like those on the Ethereum [3], Hyperledger Fabric [4]
or Bitcoin [5] blockchains. However, we feel that the potential
of on–chain smart contracts has been overrated. There are
applications where the use of on-blockchain smart contracts
is overkill and others where they have a detrimental effect to

1This document is a copy of the one uploaded to Research Gate in April
2019, except for typo corrections and a few lines added to the end of Sections
D and VI.

the extent of rendering the application unpractical or unimple-
mentable [6], [7], [8]. In these situations, developers should
consider the use of smart contracts deployed on Trusted Third
Parties. It seems that the confusion is caused by the novelty
of the technology and lack of global consensus about what
smart contracts and blockchains are. Before continuing the
discussion we will present the definitions that will be followed
in subsequent sections of this paper.

A. Blockchains

To software developers, a blockchain is a piece of middle-
ware that includes built–in services that can be used for the
development of distributed applications without the involve-
ment of a component (for example, an authentication or a
database server) acting as a central control. The salient services
that blockchains can offer are indelible append–only storage,
public–key–based access control to the execution of opera-
tions, public auditability of records and, notably, consensus
services of some discipline (normally, eventual consensus).
A great variety of applications can be built on the basis of
blockchains; smart contracts are the best known but not the
only one. At an implementation level, a blockchain can be de-
fined as a distributed data structure (known also as the ledger)
composed of an ordered, back–linked list (chain) of blocks.
Blocks are added to the list following an append–only model,
and only when a set of nodes that hold local replicas of the
current state of the blockchain reach consensus about its next
global state. The blocks are normally used for storing records
of transactions executed by parties that do not necessarily trust
each other and underpin the peer–to–peer execution model
of the transactions. The transactions are operations aimed at
altering the current state of the blockchain and are not nec-
essarily bank transactions. The building and maintenance of a
blockchain requires the combination of several technologies,
consequently, different conceptual models have been suggested
for modelling blockchains. For instance, in [9] a blockchain
is regarded as a probabilistic state machine to emphasise the

ar
X

iv
:2

01
0.

12
98

1v
1 

 [
cs

.N
I]

  2
4 

O
ct

 2
02

0



probabilistic nature of the consensus algorithms that are used
in blockchains.

B. Smart contracts

Intuitively, a smart contract is aimed at being the digital
version of a conventional commercial contract that is written
in a human language, for example, English. By digital we
mean that the smart contract is a piece of computer code that
can be executed to monitor or enforce the clauses stipulated in
the conventional contract, programmatically at run–time. For
example, a financial contract for a loan agreement between
a borrower and lender might stipulate that at the request of
the borrower, the lender will advance GBP 100.00 to the
borrower within five days of receiving the request. Being
an executable program, a smart contract is expected to be
deployed on infrastructure that can provide it with a run–time
environment, including, library support, facilities for managing
the smart contract (initiate, stop, terminate, update, etc.) and
databases for storing records about the inputs sent to the smart
contracts and outputs produced by it. The main responsibilities
of the smart contract are i) to act as a contract monitor that
observes the interaction between the contracting parties; ii)
to determine whether each operation (for example, request
loan, honour loan request, decline loan request, etc.) that the
contracting parties execute is compliant or non-compliant with
the terms stipulated in the contract and in accordance with
the rights and obligations inherent in the contract and iii) to
produce a verdict. Notice that in some existing smart contract
applications, the declaration of the verdict is directly and
intricately associated with an action (e.g., collect payment) that
is executed when the verdict is contract compliant. However,
we believe that for the sake of modularity it makes sense
to separate the two acts and focus on the verdict—the most
fundamental operation that smart contracts need to perform.
We regard the action as an arbitrary reaction that can be
immediately or eventually executed by the smart contract
itself or by a different component implemented in a different
software layer. In many applications, the action consists of
allowing the execution of the contractual operation when it is
declared contract compliant or preventing its execution when
the operation is declared non–contract compliant by the smart
contract. In this approach, the smart contract acts as a contract
enforcer. The question that arises here is where to deploy the
smart contract.

C. On–blockchain smart contracts

Smart contracts can be deployed on–chain. The term smart
contract was coined by Szabo in 1997 [10] but it did not
attract commercial interest until 2008 with the commercial
success of Bitcoin as a cryptocurrency platform [1]. In Bit-
coin [11], smart contracts are implemented in an opcode
stack–based script non–Turing complete language [12] and
deployed on the Bitcoin blockchain. They were originally
conceived for mediating the execution of payment operations
in BTCs (Bitcoin’s cryptocurrency). Ethereum [13], currently
a leading blockchain platform, extends the idea of Bitcoin’s

smart contracts and implements a blockchain that supports
smart contracts written in Turing–complete languages, such
as Solidity [14]. As demonstrated by numerous Bitcoin and
Ethereum use cases, in several situations, smart contracts
can be conveniently deployed on–chain, but it is crucial to
appreciate that blockchains and smart contracts are two inde-
pendent technologies. The deployment of smart contracts on–
blockchain is only one out of several deployment alternatives.
To appreciate the point, it is worth taking into account that
smart contracts predate blockchains by several years. Research
on smart contracts was pioneered by Minsky in the mid–
80s [15] and followed by Marshall [16]. In early works, smart
contracts were referred to as electronic contracts, executable
contracts, digital contracts and other similar names. Since the
usage of the term smart contract is so widespread now, we
will follow it in the rest of this document.

D. On–Trusted Third Parties smart contracts

Smart contracts can be deployed on–Trusted Third Parties
(on–TTP). We define a TTP as an institution that in addition to
having the technical infrastructure for hosting smart contracts,
has earned trust, reputation and authority. E–commerce appli-
cations routinely make use of TTP services, examples include
payment gateways, certification authorities, time–stamping
services, custodian services, settlement services and various
brokerage services [17]. In smart contract applications, a TTP
is logically located between the two business partners and is
trusted to host and run a single instance of the smart contract.
The smart contract observes all the operations that the partners
execute and keeps undeniable records about them. Pioneering
work on smart contracts [15], [16] was mainly focused on
on–TTP deployment.

A strong assumption with a TTP–based deployment is that
the TTP is trusted not to alter the code of the contract or
abuse the sensitive data that the contractual parties expose
to it. This issue can be addressed with the assistance of
recently emerging trusted hardware technologies such as Intel
SGX [18] and ARM TrustZone [19]. With this approach, the
contract code can be deployed within the trusted environments
that trusted hardware offer (called enclaves in SGX and trusted
world in TrustZone). The trusted hardware precludes the TTP
from altering the integrity of the contract code and examining
sensitive data.

E. Contributions of this paper

Since the publication of the Bitcoin paper [1], smart con-
tracts have been discussed mainly within the context and
confine of blockchains to which they seem to be intrinsically
associated. As a result, the potential and practicality of smart
contracts deployed on Trusted Third Parties (on–TTP) have
been largely underrated. The intention and contribution of this
paper is to restore balance. In pursuit of this aim we discuss
the advantages and disadvantages of using on–blockchain and
on–TTP smart contracts. Our arguments are the results from
the following exercise. As developers we have been asked to

2



advise on the selection of a smart contract technology to im-
plement a car insurance application. To be able to offer a well
supported and defined recommendation we have conducted
exploratory implementations (as opposed to fully fledged)
using on–chain and on–TTP smart contracts. In this paper we
share our experience and give some insights into the technical
problems that we have faced. We have learnt that some of
them are easier to solve with on–TTP smart contracts than with
on–chain smart contracts. We acknowledge that a noticeable
disadvantage of an on–TTP smart contract is its dependence on
a single TTP—a design feature that is considered undesirable
and avoidable via the use of blockchains. However, we argue
that in applications where the inconveniences of a TTP can be
tolerated, on–TTP smart contracts might be a better alternative
than their on–chain equivalents.

The remain of this paper is organised as follows. To open
the discussion, Section II introduces the hypothetical use case
of a car insurance application that we have been asked to
implement as a smart contract application. Section III explains
that smart contracts can be implemented either following cen-
tralised and decentralised architectures. Section IV discusses
the experience we have gained from the implementation of
the car insurance application using an on–chain smart contract
implemented in Solidity language to be deployed on Ethereum.
In Section V we include complementary arguments gained
from the implementation of the example, using an on–TTP
smart contract. In Section VI, we express our personal views of
smart contracts and mention open research questions. To place
this article within a broader context, Section VII provides a
summary of pioneering articles on smart contracts and recent
publications that are related to this article. Consequently, we
draw conclusions in Section VIII.

II. MOTIVATING SCENARIO: CAR INSURANCE
APPLICATION

A high level view of the hypothetical use case car insurance
scenario is shown in Fig. 1. It involves three participants,
namely, a customer called Alice, a car insurance company
called insurance seller run by Bob and a claim validator
(Valia). The scenario assumes that Alice has rented a car
from a car rental company run by Charlie and that she is
now interested in purchasing an insurance policy. A more
comprehensive implementation would involve the car rental,
however, to simplify the task, we have left that out of the
current implementation.

The figure shows the execution of the six main operations:

1) Alice submits a Purchase Order (PO) request to Bob to
purchase her insurance policy.

a) The PO is a document that includes the payment to
cover insurance premium, car registration details,
Alice’s personal details and Alice’s preferences
regarding the storage of her personal details.

b) Bob stores Alice’s personal details in accordance
with Alice’s preferences, she is entitled to choose
from two alternatives:

customer  
(Alice) 

insurance  seller  
(Bob) 

car rental  
(Charlie) 

1) PO 
2) accept|decline 

3) claim 

6) pay|refuse 

4) validate 
5) valid|invalid 

validator  
(Valia) 

Fig. 1. Car insurance application.

customer  
(Alice) 

insurance  seller  
(Bob) 

1) PO 
2) accept|decline 

3) claim 

6) pay|refuse 

4) validate 

5) valid|invalid 

validator  
(Valia) 

smart	
contract	

1.  Alice	submits	a	PO	…	
2.  Bob	uses	his	discretion	to	accept	or	…	
3.  In	the	event	of	an	accident	…				
	

Contractual clauses that Bob is 
expected to honour 

conversion into 
a smart contract 

Fig. 2. Architecture of the car insurance application.

• delete: Bob’s insurance company is expected to
delete Alice’s personal details within one day of
declining to sell the insurance or one day after
the expiration of the insurance certificate.

• store: Alice grants permission to the insurance
company to store her details indefinitely unless
they are notified by Alice to delete them. In the
latter case, the insurance company is expected to
delete Alice’s details within 14 days of receiving
Alice’s request.

2) Bob uses his discretion (for example, on the basis of
the registration number) to accept or decline Alice’s PO,
within 10 min of submission of the PO.

a) if Bob accepts, he proceeds to collect Alice’s
payment and declare the insurance policy in force.

3) In the event of an accident, Alice submits an insurance
claim to Bob.

4) Bob consults with his validator (Valia) to ascertain the
legality of the claim (see validation operation).

5) Valia declares the claim either valid or invalid.
6) On the basis of Valia’s verdict, Bob proceeds to either

pay or refuse the claim within 24 hours of the submission
of the insurance claim.

An abstract view of a smart contract–centric architecture
that can be used for implementing the car insurance application
is shown in Fig. 2.

The smart contract box within the insurance seller is the
result of converting the legal clauses shown above into exe-
cutable code, for example, into Solidity or any other computer
language including Java and Python. The smart contract is in

3



control of the insurance process; as such, it is responsible for
executing the contractual operations when certain conditions
are met and the execution of the operation is triggered. For
example, if Alice stipulates that her personal details shall be
deleted within a day of failing to purchase an insurance policy,
the smart contract is responsible for deleting Alice’s personal
details within a day. Likewise, in the event of a successful
purchase followed by a valid claim, the smart contract is
responsible for triggering the execution of the pay operation
to pay the relevant determined compensation to Alice within
24 hours of the submission of the claim.

Let us assume that the smart contract support only the six
operations mentioned in the contractual clauses listed above:
PO, accept, decline, claim, etc. This level of detail is enough
to present our arguments. For the sake of simplicity, the smart
contract does not account for insurance cancellation and other
operations that a more realistic application would include and
which would be more complex.

Notice that the smart contract is responsible for managing
the entire insurance process which includes the relevant pro-
visions concerning Alice’s personal details. This comes into
force when Bob collects Alice’s personal details and completes
when Bob deletes Alice’s personal details from his records.

III. CENTRALISED AND DECENTRALISED SMART
CONTRACTS

The hypothetical example of smart contract of the mo-
tivating scenario is rather simple and can be modelled as
a conventional Finite State Machine (FSM) and converted
into executable code. Having decided to use a FSM model,
developer needs to make a crucial decision at this point: where
to deploy the smart contract, as explained in Section I-C.

In general, depending on the number of instances (replicas)
deployed of the smart contract and on who is in control of the
instances, we distinguish between two alternatives: centralised
and decentralised (see Fig. 3). A and B are business partners,
for example, Alice and the insurance company of our contract
example. SC is the corresponding smart contract. op stands
for operation executed against SC (for example, PO), rp is
the corresponding response (for example, PO approved). TTP
node is a node under the control of a TTP.

A. Centralised deployment

In a centralised deployment, we instantiate only a single
instance of the smart contract of a node controlled by a
TTP (see Fig. 3–a)). Since the TTP node is not part of the
blockchain, this deployment is referred to as an off–chain
deployment and as an on–TTP deployment to emphasise the
fact that the TTP plays the role of a central authority and is
in control of the application.

B. Decentralised deployment

In a decentralised deployment, we instantiate N ≥ 2
identical instances of the smart contract. Each of the N
instances keeps a local copy of the state of the contract,
consequently this deployment needs sophisticated middleware

A 

B 

op/rp 

op/rp 

TTP node 

A 

B 

op/rp 
CP 

CP 

C
P 

C
P 

N3 
N2 

N1 

N4 

op/rp 

a)  centralised smart contract 
deployed on-TTP. 

b) decentralised smart contract 
deployed on-blockchain. 

SC1 

SC4 

SC2 

SC3 
SC 

Fig. 3. Centralised (on–TTP) and decentralised (on–chain) smart contract.

support to synchronise the copies. The deployment shown
in Fig. 3–b) relies on the middleware support offered by a
conventional blockchain. In the figure, four identical replicas
of the smart contract (SC1, . . . , SC4) are deployed on a
blockchain. N1, . . . , N4 are untrusted nodes, each operated
by an independent owner and members of the blockchain
network, for example, Ethereum. This deployment is referred
to as on–chain; it is also referred to as decentralised to
emphasise its peer–to–peer model of interaction between the
parties and its distributed computing and the storage and
maintenance of complete copies of all transactions.

In this approach, A and B are free to place their operation
against any of the instances. The price that the decentralised
approach pays for getting rid of the TTP is that the untrusted
nodes must run a consensus protocol (represented by CP ) such
as Proof–of–work, to verify that a given operation has been
executed correctly, and to keep the states of SC1, . . . , SC4

identical.
It is important to note that decentralisation is a spectrum that

can range from partial decentralisation to full decentralisation
of a particular network. Furthermore, the level of decentralisa-
tion must also naturally take into account a variety of factors
including both soft and hard factors. Hard factors may include
the actual architecture of the network as well as the relevant
consensus mechanism algorithms for that blockchain, as well
as the concentration of nodes by node operators and computing
power of miners and mining pools. Soft factors on the other
hand include the way and manner with which upgrades and
changes to the software takes place, the relevant concentration
of developers, thought leadership of notable developers or
experts, and other potential factors that may influence the
trajectory of the network and its development, be it positive
or negative in pursuit of particular objectives.

It is also crucial to distinguish between distributed from
decentralised. Distributed refers primarily to the hardware and
software infrastructure. It determines where the computation
takes place (on a single or several computers) and how the
records of the transactions are stored (a single copy on a single
ledger or on several copies on several ledgers). On the other
hand, decentralisation refers to the ownership of the nodes of
the infrastructure: are the nodes under the control of a central
authority or run by independent owners? A blockchain may
be decentralised but not distributed and distributed but not

4



decentralised. For example, Fig. 3–b) would be a distributed
but centralised blockchain if N1, . . . , N4 were under the
control of a single authority. Depending on the degree of
control that a central authority exercises on the underlying
infrastructure, there are different levels of centralisation and
decentralisation. Fig. 3 illustrates the two ends of the spectrum.
The idea of fixed and rotating committee decentralisation is an
example of how decentralisation can be gradually relaxed [20].

As developers we have considered the two alternatives to
implement the car insurance application. In the following
sections we discuss our experience.

IV. ON–CHAIN IMPLEMENTATION

With this approach, the developer has the middleware
services offered by the blockchain (see Section I-A) at his
disposal. Unfortunately, along the benefits, the blockchain
brings several complexities and engineering problems that are
extremely hard to solve. To illustrate the point, let us take
Ethereum as the implementation blockchain platform with the
assumption that other blockchains that follow the conventional
blockchain model will bring similar advantages and technical
problems.

A. Implementation and code

We have published the Solidity code at Git [21]. The
core of the code is the contract CarInsurancePolicy{...}
smart contract. Essentially it implements a finite state
machine that keeps track of the set of states S =
{CREATED,APPROV ED,CLAIM MADE, . . . }
of the policy purchased by the customer or policy holder.
The finite state machine progresses from PolicyStatei to
PolicyStatei+1 in response to actions executed by the
customer (represented by Alice), underwriter (represented by
Bob the insurance seller) or validator (represented by Valia).

To enable the application to handle several insurance
policies instances simultaneously, we have implemented the
contract CarInsurancePolicyManager{...}. This is the smart
contract and is responsible for creating and managing policy
instances. The current implementation can handle only a single
underwriter and a single validator. A more realistic implemen-
tation would need to handle a list of several underwriters and
validators.

Alice interacts with the smart contract as follows:
1) Alice is assumed to have a GUI integrated with a

software capable of creating Ethereum Wallets such as
Metamask [22].

2) Alice uses her GUI to place insurance purchase orders
which include her personal details. The submission of
a purchase order causes the execution of the createPol-
icy(carReg, msg.sender, ...) function of the CarInsuran-
cePolicyManager smart contract. As a result, the smart
contract creates and registers a new policy instance.
The function notifies Alice’s GUI about the outcome
by means of the NEW POLICY event.

3) Alice uses her GUI to execute actions against her
policy. For example, when the state machine is in state
APPROVED, Alice is able to make a claim which would
result in the execution of function makeClaim( ... ) and
progresses from APPROV ED to CLAIM MADE
state.

The underwriter and validator interact with the CarInsuran-
cePolicyManager smart contract similarly.

There are several tools that a developer can use for deploy-
ing and visualising Ethereum smart contracts. In this occasion
we have opted for the following technologies:

1) We use the Truffle deployment framework which is
currently the de–facto standard. Truffle offers several
services, including, compilation of Solidity into EVM
code, linking, deployment of the contracts and binary
management [23].

2) We deploy the smart contract from a Parity Ethereum
client—a Rust [24] implementation of Ethereum client
protocol. There are several implementations such as geth
(a Go [25] implementation) that would have worked as
well [26]. The only requirement is that the client is
synchronised (in possession of the latest blocks) with the
Ethereum blockchain. Synchronisation might take hours,
depending on the current status of the client. Another
client alternative is infura [27] which is essentially geth
or Parity in the cloud.

3) We use one of our Ethereum accounts to deploy
the CarInsurancePolicyManager smart contract. It has
enough funds to cover the deployment fees (about 4.9
Milliether).

4) The account is used by Truffle to sign the Ethereum
deployment transaction before broadcasting it through
the Parity client (or geth client if geth is used).

5) As can be seen at Etherscan [28] the CarInsurancePol-
icyManager smart contract has been deployed at the
0xb3C66fA11af5b4975D74C654665A0b7E505b2bDe
address.

We will focus our attention now on the discussion of the
technical issues that we have faced in this implementation.

B. Encryption issues

As explained in Section II, a purchase order request includes
car’s registration number and personal details of the pur-
chaser, for example personal details of Alice. In the example,
this information is included, respectively, in the carReg and
msg.sender parameter passed to function CreatePolicy(...). The
function needs to store the actual documents or a hash of them
which references the actual documents, wherever stored.

The encryption/decryption of Alice’s documents is cumber-
some. For security reasons, it is sensible to keep documents
encrypted. The problem is that they need to be read–shared
by several parties under different access policies. For example,
the carReg needs to be accessed by both Bob and Valia. If the
documents are small, one can encrypt and store the actual doc-
uments on–chain. However, once a document is broadcast to

5



the public on a decentralised blockchain, revocation of access
rights becomes technically impossible. There is no systematic
model for controlling access to encrypted documents stored on
blockchains. Fully decentralised access control is impossible.
An alternative however, is key sharing but the immutability of
the document makes the task much more difficult. One could
make the argument that revocation of access rights is against
the principle of transparency in blockchains, yet in practical
applications access control policies are needed to protect both
the integrity of the data, and the personal data, for example in
this case that of Alice.

C. GDPR compliance issues

Compliance with GDPR requirements is problematic. The
indelible append–only model that underpins the blockchain
conflicts with EU General Data Protection Regulations
(GDPR) which came into force in the UK in May 2018 [29],
[30]. These regulations grant individual the right to request
deletion of their personal details under Article 17 through the
right of an individuals to be forgotten. It follows that Alice’s
request to delete her personal details after failing to buy her
insurance or at some point in the future is to be taken by
the insurance company as a legal requirement. Notice that
under this regulation hashes of personal would most likely
be regarded as personal data. There is no practical solution to
this problem in smart contracts deployed on–chains at present.
Furthermore, depending on the nature of the activity, transac-
tion or contract, compliance with other data privacy regime
may be required depending on the location of the parties to the
system, but also potentially engaging the restrictions related to
international personal data transfer under GDPR. Other GDPR
concerns include the possibility for a public key, which is
used to sign multiple different smart contracts, may lead to the
identification of a particular individual. In such an instance,
it is arguable that the public key would then be considered
personal data as it leads to the identification of the owner.
Moreover, assessing and identifying the relevant ”controller”
and ”processor” under GDPR regulations may serve to be
counterintuitive to the overall schema of using a decentralised
blockchain and on–chain smart contract. The reasoning behind
this is as follows, if personal data is entered into a block by
an individual or business, they may likely be categorised as
a ”controller” for the purposes of GDPR unless it is only
supporting the blockchain network, in which case it would
merely be a ”processor” and which raises the concern that
nodes and miners could each be considered ”processors” if a
public key, used to sign multiple smart contracts is considered
personal data due to the fact that it references information
which could lead to the identification of an individual. It is
important to highlight that even if code were law, GDPR
regulations would remain of crucial concern. Code currently is
not considered law, and therefore any given smart contract, or
code, is by definition referencing the relevant documentation
and contracts which stipulate and define the relevant rights,
duties, and obligations of the parties and are looking to mirror
the relevant provisions. Naturally, this is relatively cyclical in

the sense that in order for code to be considered law, the
law must recognise it as such in the form of legislation or
common law applied by the judges and the courts where smart
contracts, or code, are an accepted contractual agreement,
and which can be submitted as evidence, and from which
rights, duties, and obligations arise. Nevertheless, there are
instance in which code may likely satisfy the relevant tests
in different jurisdictions for being fully enforceable contracts,
given that in certain jurisdictions, a physical paper contract is
not required for a contract to be formed, and therefore there
are certainly instances where a smart contract alone would be a
contract. In which case, documentation would not necessarily
be referenced, but rather, the code would be the contract
itself. Yet, even if physical or digital documentation were not
required, there would still be required code stipulating the
relevant agreement between the parties and assigning rights
and duties to the parties, which would, at least in the present
context, require the identification of the parties to some degree,
and the inclusion of certain personal data which would lead
to the same data storage concerns and GDPR issues related
to an individuals right to be forgotten and data qualifying as
personal data due to it potentially leading to the identification
of an individual.

D. Off–blockchain storage issues

Storing and retrieving documents from off-chain st";"""date"",""2020-10-27T01:33:18Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2020-10-27T01:33:18Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.21 (TeX Live 2020) kpathsea version 6.3.2""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2020-10-27T01:33:18Z""
""created"",""2020-10-27T01:33:18Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-10-27T01:33:18Z""
""resourceName"",""2010.12981""
""Author"",""""
""producer"",""pdfTeX-1.40.21""
""pdf:docinfo:producer"",""pdfTeX-1.40.21""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2020-10-27T01:33:18Z""
""Last-Modified"",""2020-10-27T01:33:18Z""
""dcterms:modified"",""2020-10-27T01:33:18Z""
""title"",""""
""Last-Save-Date"",""2020-10-27T01:33:18Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2020-10-27T01:33:18Z""
""meta:save-date"",""2020-10-27T01:33:18Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.21 (TeX Live 2020) kpathsea version 6.3.2""
""Content-Length"",""442860""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""14""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""4205"",""5246"",""4304"",""4886"",""4693"",""5345"",""5382"",""5108"",""4696"",""5079"",""5487"",""4736"",""7310"",""2302""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-10-27T01:33:18Z""
";https://scholar.google.ch/scholar?start=660&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098769-115;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Ethploit: From fuzzing to efficient exploit generation against smart contracts;Q Zhang, Y Wang, J Li, S Ma ; 2020 IEEE 27th International …, 2020  ieeexplore.ieee.org;;"… Blockchain-based cryptocurrency systems gain great popu- larity in the past several years,

standing at an overall mar- ket capitalization of 170 billion dollars in April 2019 [1]. Ethereum

[2], for example, is the second-largest blockchain system and cryptocurrency after Bitcoin [3 …";Cité 6 fois;Les 8 versions;[PDF] sjtu.edu.cn;https://crypto.sjtu.edu.cn/~lognamor/publications/saner20b.pdf;"
ETHPLOIT: From Fuzzing to Efficient Exploit
Generation against Smart Contracts

Qingzhao Zhang∗‡, Yizhuo Wang∗‡, Juanru Li∗, Siqi Ma†(�)

∗Shanghai Jiao Tong University, China
{fszqz001, mr.wang-yz}@sjtu.edu.cn, roman@sjtusec.com

† Data 61, CSIRO, Australia
siqi.ma@csiro.au

Abstract—Smart contracts, programs running on blockchain
systems, leverage diverse decentralized applications (DApps).
Unfortunately, well-known smart contract platforms, Ethereum
for example, face serious security problems. Exploits to contracts
may cause enormous financial losses, which emphasize the
importance of smart contract testing. However, current exploit
generation tools have difficulty to solve hard constraints in
execution paths and cannot simulate the blockchain behaviors
very well. These problems cause a loss of coverage and accuracy
of exploit generation.

To overcome the problems, we design and implement ETH-
PLOIT, a smart contract exploit generator based on fuzzing.
ETHPLOIT adopts static taint analysis to generate exploit-
targeted transaction sequences, a dynamic seed strategy to pass
hard constraints and an instrumented Ethereum Virtual Machine
to simulate blockchain behaviors. We evaluate ETHPLOIT on
45,308 smart contracts and discovered 554 exploitable contracts.
ETHPLOIT automatically generated 644 exploits without any
false positive and 306 of them cannot be generated by previous
exploit generation tools.

Index Terms—smart contract, fuzzing, exploitation

I. INTRODUCTION

Blockchain-based cryptocurrency systems gain great popu-
larity in the past several years, standing at an overall mar-
ket capitalization of 170 billion dollars in April 2019 [1].
Ethereum [2], for example, is the second-largest blockchain
system and cryptocurrency after Bitcoin [3] by overall mar-
ket value [1]. Ethereum develops Bitcoin’s scripts, a piece
of stack-based code performing some simple checks before
currency transfer, to a Turing-complete on-chain programming
language called smart contract. As a result, more than cryp-
tocurrency, Ethereum serves as a platform for decentralized
applications (i.e., DApps) based on smart contracts, such
as tokens, gambling, auction, etc. The website State of the
DApps [4] records over 2,200 active DApps, over 85% of
which come from Ethereum. In fact, Ethereum had hosted over
one million smart contracts by the end of 2018 [5].

As the smart contract develops, security vulnerabilities of
Ethereum smart contracts become a serious problem. The
Turing-complete language makes smart contracts more error-
prone than Bitcoin’s scripts and several vulnerabilities have
been discovered [6]. Because of the nature of cryptocurrency,
smart contracts usually involve flows of ETH, the virtual

‡ These authors equally contribute to the paper.

currency in Ethereum which is also valuable in the real world.
Therefore, when attackers make use of vulnerabilities, the
currency is illegally manipulated. In fact, real-world attacks
such as DAO [7] and Parity Multisig Wallet [8] have caused
a tremendous crisis for Ethereum. What is worse, smart
contracts are unmodifiable after on-chain deployment and the
damage of attacks is almost irretrievable.

One major research goal for smart contracts vulnerability
is how to fulfill an accurate vulnerability detection. Existing
detection techniques [9]–[12] often suffer from both false
negative and false positive. To verify a detected vulnerability,
a typical method is to generate an exploit to test whether
the vulnerability can be actually triggered. Current exploit
generation for smart contracts generally applies symbolic
execution method [13], [14]. Teether [13], for instance, locates
potential dangerous operations and solves an execution path
triggering the operation using SMT solvers. However, such a
workflow of symbolic execution faces two challenges. The first
one is Unsolvable Constraints, which indicates the execution
of sensitive operations (e.g., currency transfer, self-destruction)
is restricted by conditions that are difficult for existing tools to
pass. Unsolvable Constraints is a major obstacle for symbolic
execution. A prominent case is the validity check of hash
value before currency transfer. For instance, teether tries to
jump over a hash instruction but cannot present value relation
between hash pre-image and hash value, which does not
help to pass cryptographic checks in many scenarios. Our
observation on 49,522 contracts collected from etherscan [5]
demonstrates that these complicated conditions are common
as 20% (9,694) contracts contain cryptographic functions. In
this situation, the corresponding exploit is not able to be
generated. Another challenge for current techniques is how to
handle Blockchain Effects. Blockchain properties (e.g., times-
tamp and block number) are variables used in the contracts,
which represent information about objects (e.g., block) in the
blockchain system. Current exploit generation tools regard
blockchain properties as normal global variables. However,
these properties have their meaning in the blockchain system
and their value has a specific range. If not handled properly,
it is also infeasible to generate an exploit successfully.

To respond to the above challenges, in this paper, we
utilize fuzzing to generate exploits. Compared with symbolic
execution, fuzzing does not need to mathematically solve

978-1-7281-5143-4/20 cŠ 2020 IEEE SANER 2020, London, ON, Canada
Research Papers

Accepted for publication by IEEE. cŠ 2020 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.

116



execution paths but generates input candidates to scan the
paths, therefore bypasses the dilemma of symbolic execution.
In addition, it is easier for a fuzzing framework to simulate
blockchain behaviors with runtime instrumentation. We im-
plement ETHPLOIT, a smart contract exploit generator, which
basically generates transaction sequences to test whether the
subject contract is exploitable. To address the problem of
Unsolvable Constraints, ETHPLOIT adopts a dynamic seed
strategy to make use of runtime values as feedback, so that
finds the solution of cryptographic functions from execution
histories. To simulate Blockchain Effects, ETHPLOIT leverages
an instrumented Ethereum Virtual Machine (EVM) to provide
custom configurations, such as setting timestamps and revert-
ing external calls. In addition, to minimize search space and
make the fuzzing process more efficient, ETHPLOIT deploys
a taint analysis to guide transaction sequence generation and
rules out invaluable test candidates in the first place.

We evaluate ETHPLOIT with 45,308 on-chain Ethereum
contracts, and discovered 554 contracts can be exploited
successfully. ETHPLOIT automatically generated 644 exploits
for those contracts without any false positive and toke less
than two seconds to generate each exploit on average.

In comparison, existing exploit generation tools (Teether
and MAIAN) only generate a subset (334) of exploits. Specif-
ically, ETHPLOIT generates 112 exploits against Exposed
Secret, a class of vulnerability involving hash functions and
thus the existing tools label them as “unexploitable”. The
results demonstrated that ETHPLOIT significantly improved
the exploit generation technique against smart contracts and
developers could leverage our tool to build more secure code.

In summary, we make the following contributions:
1) We summarized two major challenges, Unsolvable Con-

straints and Blockchain Effects, in smart contract exploit
generation, and proposed a corresponding solution (i.e.,
a fuzzing approach) to address them.

2) We design and implement ETHPLOIT to fulfill our
fuzzing guided exploit generation. ETHPLOIT makes
use of three key techniques (taint constraints, EVM
instrumentation, and dynamic seed strategy) and is able
to achieve a more effective exploit generation.

3) By utilizing ETHPLOIT, we discovered 544 vulnerable
contracts from Ethereum blockchain and generated 644
valid exploits for them, among which 306 exploits are
not discovered by previous tools.

II. SMART CONTRACT SECURITY ISSUES

In this section, we first define some important concepts used
in this paper. Then, we introduce the existing smart contract
exploits and the corresponding discovered vulnerabilities.

A. Definitions

Definition 1: Solidity variables. Solidity defines four types
of variables according to their purposes:
• Local variable. The variable declared in a function that

is destructed when the function returns.

• State variable. The variable declared globally that indi-
cates the state of the contract.

• Function argument. The variable declared as an input of a
function that is provided by the sender of the transaction.
Such variables are usually untrustworthy.

• Blockchain property. The variable representing properties
of blockchain system that contains three types of vari-
ables, message properties (e.g., msg.sender), transac-
tion properties (e.g., tx.origin), and block properties
(e.g., block.timestamp) [2].

Definition 2: Transaction refers to an Ethereum transaction
invoking the execution of a smart contract. Each transaction
consists of four elements: a sender, a receiver (i.e. the address
of the target contract), a value (i.e., amount of currency),
and a data section containing a called function with its
corresponding arguments.

Definition 3: Test case refers to a sequence of transactions.
Each transaction in the test case is executed sequentially in
positive order. If the test case identifies a vulnerability, itself
represents a valid exploit.

B. Exploitation of Smart Contract

Vulnerabilities of smart contract platforms could happen
at the blockchain level, EVM level, and contract level [12].
We focus the contract-level vulnerabilities. Through smart
contract vulnerabilities, attackers are able to exploit them
gaining control of assets or causing damages. According to
the cause of damages, we classify smart contract exploits into
three categories [13], [14]:

1) Balance Increment. Contracts send currency to arbitrary
accounts. Attackers conduct value transfer to gain profits
from contracts by controlling target contracts.

2) Self-destruction. Ethereum contracts implement a special
operation of destroying themselves. Such a dangerous
operation cannot be accessible by attackers.

3) Code Injection. There are operations importing codes
from external contracts. Then attackers are allowed to
inject arbitrary malicious code into the execution if they
have the control of such external contracts.

We observe that the three categories of exploits usually
cause an external call: currency transfer, self-destruction, and
execution of external code, respectively. To trigger a successful
exploit using a test case, two requirements should be followed:
1) a critical transaction, whose execution exploit contract
vulnerabilities, must have at least one execution path to trigger
one of the vulnerable external function calls; 2) a set of
transactions must be executed to modify states of the contract
before the critical transaction does.

C. Smart Contract Vulnerabilities

We introduce three types of vulnerability, where two types,
Unchecked Transfer Value, and Vulnerable Access Control,
are discovered by previous smart contract exploit generation
tools [13] [14]. Another type, Exposed Secret, is a newly iden-
tified vulnerability for which previous smart contract exploit
generation tools cannot generate valid exploits.

117



1 contract NewSmartPyramid {
2 function withdraw() notOnPause public {

3 if ( block.timestamp >= x.c(msg.sender
) + 10 minutes) {

4 uint _payout = (x.d(msg.sender).
mul(x.getInterest(msg.sender))
.div(10000)).mul(

block.timestamp .sub(x.c(msg.
sender))).div(1 days);

5 x.updateCheckpoint(msg.sender);
6 }
7 if (_payout > 0)
8 msg.sender.transfer(_payout);
9 }

10 }

Listing 1: A contract with block timestamp for investment.

1 contract HOTTO is ERC20 {

2 owner = msg.sender;
3 function HT() public {

4 owner = msg.sender;
5 distr(owner, totalDistributed);
6 }

7 function withdraw() onlyOwner public {

8 address myAddress = this;
9 uint256 etherBalance = myAddress.

balance;
10 owner.transfer(etherBalance);
11 }
12 }

Listing 2: A contract with Bad Access Control vulnerability

1) Unchecked Transfer Value: It describes the amount of
currency transfer without being constraint including two types
of implementations.

First, misuse of this.balance. It indicates that the total
transfer balance is not being checked by a contract, which
causes economic losses.

Second, unlimited profit. A large number of smart contracts
provide users with high-yield investments in the form of tokens
or games. It helps attackers to gain unlimited profits if they ma-
nipulate the calculation of rewards. For example in Listing 1,
since _payout is dependent on block.timestamp (Line
5) and it is allowed to be transferred without any constraints
(Line 10), an attacker can gain any profits as long as the
contract balance is not exceeded.

2) Vulnerable Access Control: It represents that an attacker
can bypass access control or grant privileges to conduct sensi-
tive operations, such as currency transfer and self-destruction.
Consider Listing 2 as an example, by executing public function
HT, which changes original owner to msg.sender with no
checks (Line 4), an attacker can bypass onlyOwner checking
(Line 7) to withdraw all currency in contract.

3) Exposed Secret: It represents that an attacker can pro-
vide a secret value, which should be private to attackers, to
access sensitive operations. Contracts with this vulnerability
usually work as an application of gambling, quiz, gift and so
on. Typical contracts of this type include two main functions:
One is Secret Setter. The function sets the secret value and
store the secret (or some transformation of the secret) in the
contract state variables. The other one is Secret Checker which

Fig. 1: A gaming contract with hash function.

accepts some proofs to verifies whether the sender knows the
secret and then execute sensitive operations such as currency
transfer or writing state variables.

Unluckily, because of the openness of blockchain, attackers
can inspect the secret by observing the data of previous
transactions and then break the secret checking. The Game
contract in Figure 1 is a typical example. The secret setter
StartGame stores the hash value of the secret value, which is
a common approach to handle passwords. However, the plain
text of the secret response is a transaction argument, which
is recorded publicly in the blockchain. Formally, if any secret
value appears in the contract execution as plain text, the secret
value can be conducted from past transactions and we regard
this contract is vulnerable for Exposed Secret.

III. MOTIVATION

In this section, we list challenges to exploit smart contract
vulnerabilities and propose our approaches to address the
corresponding challenges.

A. Challenges of Smart Contract Exploit Generation

By analyzing previous smart contract exploit generation
tools [13] [14], we summarized two challenges for exploit
generation, Unsolvable Constraints and Blockchain Effects.

1) Unsolvable Constraints: Sensitive operations in smart
contracts are commonly restricted by conditions such as va-
lidity check of a hash value. Thus, solving such constraints is
necessary for generating exploits. Previous tools (e.g., Teether,
Mythril) rely on SMT solvers to address path constraints.
However, SMT solvers cannot solve the constraint if it involves
complicated operation like hash (opcode SHA3). Although
some improvements are made in Teether (e.g., iterative con-
straint solving), path constraints cannot be solved completely.

Figure 1 demonstrates an example with a cryptographic
constraint (Line 7). Operation transfer (Line 8) is trig-
gered if the value of responseHash equals to the re-
turn value of the hash function keccak256. Variable
responseHash is assigned by hash function keccak256

118



in function StartGame (Line 13), which is unable to be
traced by previous tools.

2) Blockchain Effects: Blockchain effects of blockchain
system such as blockchain properties affect the execution
of smart contracts. An attacker may control the blockchain
effect and execute sensitive operations (e.g., transfer)
if they are dependent on the blockchain effect. To exploit
such vulnerability, the blockchain effect is required to be
implemented reasonably. For instance, the timestamp must be
represented as the current time or recent time, instead of an
exaggerated time. For example, the contract shown in Listing 1
demonstrates a transfer correlated to a blockchain effect, i.e.,
block.timestamp. Variable _payout is the amount of
transfer (Line 10) and it is assigned by a calculation, which
includes block.timestamp (Line 5). If selecting a proper
timestamp, attackers can gain profit from the contract. The
current exploit generation tool, Teether, generates an invalid
timestamp to exploit this vulnerability without considering the
syntax of the block.timestamp.

B. Approaches for Challenges

Fuzzing [15] is an automated software testing technique
which is commonly used to generate exploits for security-
critical programs. In order to fuzz smart contracts for exploit
generation, we apply a smart contract specific fuzzer which
targets on exploitation. To address the above challenges, we
leverage the following approaches to fuzzer:

Feedback of runtime values. We record the runtime values
of arguments and variables to solve the defect of Unsolvable
Constraints. Initially, we create a blank seed set for each
argument of each function. According to the execution of
previous transactions, we update the seed set of each func-
tion argument by adding runtime values, including previous
function arguments, state variables and so on. We then apply
the seeds as the feedback to generate arguments for the next
transaction to execute. In this way, the feedback indicates the
execution history and current state of the contract, which helps
to generate valuable exploits. With the hash input recorded in
the seed set, we can pass the validity check of the hash value,
which is the most challenging case of Unsolvable Constraints.

Manipulation of blockchain execution. We propose to
instrument the execution environment of smart contracts to
support configurable executions, which means we can freely
set the value of blockchain properties to solve Blockchain
Effects. For example, we can configure each transaction ex-
ecution by setting specific block timestamp which is realistic
while able to exploit vulnerabilities, therefore explore more
possibilities of contract execution.

IV. ETHPLOIT: SMART CONTRACT FUZZER

We design ETHPLOIT, a fuzzer for exploiting smart con-
tracts automatically. Figure 2 depicts the workflow of ETH-
PLOIT, which consists of five steps:

1) Static Analysis. Given Solidity code of smart contracts,
ETHPLOIT compiles the code to extract the Application

Solidity Compiler

Taint Analyzer

Exploit Detector

Test 
Case

Dependencies

ABI

Valuable Seeds

Function Reward

Test Case Generator
Taint Relation Graph

Instrumented EVM

Revert-call
Configuration

Block Property
Configuration

Critical Instruction 
Coverage

Feedback 
Construction

Fuzzing Iteration

Extended
Trace

Solidity

Function Selection

Argument Generation

Property Generation

Bytecode

Feedback Handler
Function Distribution

Dynamic Seed Set

1

Coverage Guider

2 3

4

5

Fig. 2: Workflow of ETHPLOIT: (1) Static analysis; (2) Test case
generation; (3) Test case execution; (4) Trace analysis; (5) Feedback
handling.

Binary Interface (ABI) and the bytecode. It also applies
taint analysis to extract dependencies among variables.

2) Test Case Generation. ETHPLOIT initially generates
a test case. Instead of providing any predefined code
patterns, ETHPLOIT conducts fuzzing to optimize the
test case. The test case is further updated based on the
static analysis results and feedback results generated by
the previous round of fuzz test.

3) Test Case Execution. ETHPLOIT instruments an EVM
to simulate blockchain effects. It further applies each
test case on the instrumented EVM and output execution
traces. The traces cover more execution probabilities
because of the instrumentation.

4) Trace Analysis. ETHPLOIT analyzes each execution
trace. If the exploit detector identifies an exploit, ETH-
PLOIT reports the current test case as a valid ex-
ploit. Meanwhile, coverage guider constructs feedback
for optimizing the test case. ETHPLOIT distinguishes
the feedback into two categories: function reward for
modifying function distribution and valuable seeds for
updating dynamic seed sets.

5) Feedback Handling. ETHPLOIT regards the function
reward as function distribution for test case generator
to select functions that are more likely to exploit vul-
nerabilities by the experience of past fuzzing iteration.
Feedback handler also adds valuable seeds into seed sets
which can be used to generate arguments able to address
some strict constraints.

ETHPLOIT executes Step (2) - Step (5) repeatedly until the
total amount of the generated test cases exceeds a threshold.

To implement the approaches stated in Section III-B, ETH-
PLOIT proposes three key techniques:

Dynamic Seed Strategy. The feedback of runtime values is
the seeds in ETHPLOIT, which guides argument generation for
each transaction. Under a dynamic seed scheduling assisted by
taint analysis, seeds are precisely fed into specific arguments.

EVM Instrumentation. To provide light-weight blockchain
manipulation, ETHPLOIT deploys an instrumented EVM envi-

119



ronment that works the same as the official EVM and leverages
instrumentation to simulate blockchain effects.

Taint Constraints of Test Case Generation. To minimize
the search space of fuzzing, we only generate valuable test
cases based on taint analysis. ETHPLOIT makes sure that the
functions of each test case have internal dependencies.

A. Static Analysis

Taking the source code of each contract (i.e., Solidity
program) as input, ETHPLOIT first compiles the source code
and applies taint analysis to learn the dependencies of variables
from the source code.

1) Solidity Compiler: ETHPLOIT uses the solidity com-
piler, solc [16], to extract its bytecode and ABI. The bytecode
is used for deploying the contract in test case execution. ABI
is taken as the input of test case generation.

2) Taint Analyzer: As each processed transaction may
modify states of the contract, ETHPLOIT applies static taint
analysis to discover dependencies of modifying contract states.

Our taint analyzer is built on top of Slither [17], which is
an open-source static analyzer for parsing the smart contract
source code. The taint analyzer proceeds the following steps
to extract dependencies in a smart contract.
Control Flow Graph Generation. The taint analyzer first
creates a Control Flow Graph (CFG) for each function, where
each node is a Solidity expression (e.g., assignments, function
calls, branch operations) and each edge connecting two nodes
that are executed sequentially. From each CFG node, we can
extract a set of read variables and a set of written variables.
First, the analyzer creates an ENTRY node and an EXIT node
to represent the beginning and the end points, respectively.
It then parses the function and extracts conditional branches
such as IF and FOR. For each conditional branch, the analyzer
follows its execution sequence of expressions to construct a
graph. Analyzer finally connects all graphs to generate a CFG.
Taint Source and Sink Labeling. Given the CFG of a
function, analyzer labels taint sources and sinks by analyzing
the expression of each node.

The analyzer labels state variables, function arguments, and
blockchain properties as taint sources. These variables are a
potential risk, as values of these variables are directly/indi-
rectly assigned by the sender of the transaction. It then marks
state variables and external calls (i.e., send, transfer, call,
callcode, delegatecall, selfdestruct) as taint sinks. Due to the
contract states stored in state variables are not destructed when
the function returns, it is essential to continue tracking the
states through state variables. Besides, external calls are the
only trigger to explore smart contract exploits. These taint
sources and sinks are used for further taint propagation.
Taint Propagation. According to the labeled taint sources and
sinks, the taint analyzer learns how tainted value propagates in
the function. Hence, the analyzer proceeds taint propagation
by analyzing the dependencies of variables. Since we only
consider the tainted value propagation, we extract variable-
level dependencies, which are defined below:

1) Variable-Data Dependency. A variable v1 is variable-
data dependent on a variable v2 if the value of v1 is
assigned by v2 such as v1 = v2 + 1.

2) Variable-Control Dependency. A variable v1 is variable-
control dependent on a variable v2 if the expression
with v1 is control dependent on the expression with v2.
Consider code if(v2! = 0){v1 = v1+1; } as an example,
v1 is variable-control dependent on v2.

Starting from the ENTRY node in the CFG, the taint analyzer
traverses the CFG iteratively and propagates taint on nodes.
The propagation takes three steps on each CFG node:

1) Initialize taint status. If the CFG node has no predeces-
sors, the analyzer initially creates a flow set for each taint
source, represented as Taint(src)← {src}. Otherwise,
the analyzer creates Taint of the current node by taking
the union of predecessors’ Taint. Taint indicates the
status of taint propagation at the current node.

2) Extract immediate dependencies. In the Solidity expres-
sion of the current node, written variables are variable-
data dependent on read variables. Also, the analyzer
locates CFG nodes that the current node is control
dependent on. Written variables of the current node are
variable-control dependent on read variables of these
control dependent nodes.

3) Update taint status. For each extracted dependency in
step 2, v1 is variable-dependent on v2 for example, the
analyzer inserts v1 to the flow set of sources that taints
v2, namely, for each src, Taint(src) ← Taint(src) ∪
{v1} iff v2 ∈ Taint(src).

After proceeding propagation on each CFG node, We get the
Taint of the EXIT node, denoted by TaintEXIT , as the taint
analysis result of current function. A source src taints a sink
sink if sink ∈ TaintEXIT (src).

B. Test Case Generation

Test case generator takes the results of ABI and depen-
dencies of variables as input, it then creates a test case to
exploit smart contract vulnerabilities. In order to prevent the
involvement of manual efforts, generator optimizes the test
case through fuzzing, instead of manually defined patterns.

A test case is generated in the format of I =
(tx1, tx2, . . . , txK), where txi is a transaction. We first in-
troduce a representation of Taint Relation Graph depicting
dependencies among variables in one test case. The gener-
ator then takes the following three steps to generate a test
case: Function Selection, Argument Generation, and Property
Generation. Details are introduced below.

1) Taint Relation Graph: The generator aims to optimize
the test case by analyzing how attackers’ inputs affect the
execution of exploits. First, since the test case is a sequence of
transactions, we need to learn dependencies among the func-
tion sequence more than in-function dependencies. Second, we
only focus on dependencies that are relevant to exploitation.
To achieve the above goals, for each test case, generator
constructs a Taint Relation Graph that helps function selection
(Section IV-B2) and dynamic seed feeding (Section IV-E).

120



Each node in the Taint Relation Graph is taint sources or
taint sinks. A directed edge represents a dependency from
one taint source to one taint sink. A state variable, which
is globally used in one contract, can be one node though
it is referred to in various functions. Rather than analyzing
all variable dependencies in the test case, the generator only
selects those that are related to external calls because external
calls are the only way to trigger exploits. Given a test case
and variables dependencies extracted from taint analysis, the
generator traverses the transaction sequence from txK to tx1

for constructing a Taint Relation Graph:
1) For txK , the generator finds all sources that taint exter-

nal calls. It adds edges from sources to calls. Among
these sources, the generator selects state variables and
puts them into a set called Target Sinks.

2) From txK−1 to tx1, for each transaction, generator finds
out all sources that taint any state variables in Target
Sinks. The generator further adds edges from the sources
to the sinks and updates Target Sinks by adding state
variables from these sources.

Given Taint Relation Graph of the test case, if there is a
path from a taint source to any external call in txK , we can
learn that the source (indirectly) taints the calls and is valuable
to fuzz for exploit discovery.

Taken the Figure 1 as an example, where solid arrows
denote the edges and dotted lines connect the same variables,
generator analyzes the test case (tx1, tx2) where tx1 calls
StartGame and tx2 calls Try. Generator first identifies an
external call transfer in function Try, which is variable-
control dependent on a state variable responseHash. Gen-
erator then regards responseHash as a sink and further
explores that it is directly variable-data dependent on a
function argument _response in function StartGame.
The Taint Relation Graph is updated as _response →
responseHash → transfer, which indicates that
_response in StartGame is valuable to fuzz.

2) Function Selection: To generate an executable test case,
the first step is to select K functions from the contract for the
K transactions, respectively.

Only non-static callable functions are suitable for transac-
tion generation. First, the function must be public and callable,
otherwise, it cannot be triggered by any transaction calls. Sec-
ond, the function must be non-static, which contains external
calls or operations to modify state variables, otherwise, it is
useless for exploitation.

After removing improper functions, generator selects func-
tions from txK to tx1. For each transaction txi (1 ≤ i ≤ K),
we take the following two steps to select txi’s function txi.f .

Candidate selection based on dependencies. While prepar-
ing to choose txi.f , generator takes the Taint Relation Graph
of txK to txi+1 and the corresponding Target Sinks as input.
If the graph can be extended by one function, the generator
adds the function to a set of candidates. More specifically,
if i = K, the function is the one with at least one external
function call. If i < K, the function is the one including inputs
which indirectly taint the external calls in txK−1.

Function selection based on probability distribution. The
generator then randomly selects a function from the candi-
dates with a probability distribution. Basically, the distribu-
tion mappings functions to positive numbers, whose value is
based on execution feedback. Given the distribution P and
function candidates F , a function f ∈ F has a probability of
P (f)/

∑
i∈F P (i) to be selected. Details of P is illustrated in

Section IV-D1. Finally, txi.f is the selected function.
3) Function Arguments Generation: After the function se-

lection, the generator fills in arguments and block properties of
each transaction to make it executable. In general, arguments
are generated from two sources: pseudo-random generator
and seeds. For the predefined probability p, it indicates that
each argument has a probability p to be generated randomly.
Besides, probability 1−p is to use the value of one seed from
the corresponding seed set.

Random generation is based on types of arguments, which
are divided into static-size (e.g., uint256 and bytes32)
and dynamic-size (e.g., arrays). For static-size arguments, the
pseudo-random generator produces random values within the
input domain. For example, range from 0 to 2256 − 1 for
uint256 type. For dynamic-size arguments, since elements
of them are static-size in Solidity version 0.4, the generator
first randomly selects";"""date"",""2020-01-21T08:10:55Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""EthPloit: From Fuzzing to Efficient Exploit Generation against Smart Contracts""
""xmp:CreatorTool"",""TeX""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""SANER 2020""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""TeX""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""EthPloit: From Fuzzing to Efficient Exploit Generation against Smart Contracts""
""modified"",""2020-01-21T08:10:55Z""
""cp:subject"",""SANER 2020""
""pdf:docinfo:subject"",""SANER 2020""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""Qingzhao Zhang, Yizhuo Wang, Juanru Li, and Siqi Ma""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.19 (TeX Live 2018) kpathsea version 6.3.0""
""meta:author"",""Qingzhao Zhang, Yizhuo Wang, Juanru Li, and Siqi Ma""
""trapped"",""False""
""meta:creation-date"",""2020-01-21T08:10:55Z""
""created"",""2020-01-21T08:10:55Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-01-21T08:10:55Z""
""resourceName"",""saner20b.pdf""
""Author"",""Qingzhao Zhang, Yizhuo Wang, Juanru Li, and Siqi Ma""
""producer"",""pdfTeX-1.40.19""
""pdf:docinfo:producer"",""pdfTeX-1.40.19""
""pdf:unmappedUnicodeCharsPerPage"",""3"",""0"",""0"",""0"",""0"",""1"",""0"",""0"",""0"",""0"",""0""
""Keywords"",""smart contract;  fuzzing;  exploitation""
""access_permission:modify_annotations"",""true""
""dc:creator"",""Qingzhao Zhang, Yizhuo Wang, Juanru Li, and Siqi Ma""
""dcterms:created"",""2020-01-21T08:10:55Z""
""Last-Modified"",""2020-01-21T08:10:55Z""
""dcterms:modified"",""2020-01-21T08:10:55Z""
""title"",""EthPloit: From Fuzzing to Efficient Exploit Generation against Smart Contracts""
""Last-Save-Date"",""2020-01-21T08:10:55Z""
""pdf:docinfo:keywords"",""smart contract;  fuzzing;  exploitation""
""pdf:docinfo:modified"",""2020-01-21T08:10:55Z""
""meta:save-date"",""2020-01-21T08:10:55Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.19 (TeX Live 2018) kpathsea version 6.3.0""
""Content-Length"",""1706803""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Qingzhao Zhang, Yizhuo Wang, Juanru Li, and Siqi Ma""
""dc:subject"",""smart contract;  fuzzing;  exploitation""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""11""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""5025"",""5020"",""3812"",""4799"",""5137"",""5312"",""5304"",""5130"",""4657"",""4466"",""6554""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""smart contract;  fuzzing;  exploitation""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-01-21T08:10:55Z""
";https://scholar.google.ch/scholar?start=660&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098809-210;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;[PDF][PDF] What is Stablecoin?: A Survey on Its Mechanism and Potential as Decentralized Payment Systems;M Mita, K Ito, S Ohsawa, H Tanaka ; iaiai.org;;"… In the context of blockchain, this is often referred to as the Oracle problem [60] … the details, the

USDX employs an original mechanism called the decentralized Schelling point Oracle system …

variable, as in models for protocol layers, in addition to using general oracles that obtain …";Autres articles;Version HTML;[PDF] iaiai.org;http://www.iaiai.org/journals/index.php/IJSKM/article/view/574/452;"
What is Stablecoin?: A Survey on Its Mechanism and
Potential as Decentralized Payment Systems

Makiko Mita *,  Kensuke Ito *, 
Shohei Ohsawa †,  Hideyuki Tanaka *

Abstract

Our study provides a survey on how existing stablecoins—cryptocurrencies aiming at price 
stabilization—peg their value to other assets, from the perspective of Decentralized Pay-
ment Systems (DPSs). This attempt is important because there has been no preceding sur-
veys focusing on the stablecoin as DPSs, i.e., the one aiming at not only price stabilization 
but also decentralization. For clarity, we first classified existing stablecoins into four types 
according to their collaterals (fiat, commodity, crypto, and non-collateralized) and pointed 
out the high potential of non-collateralized stablecoins as DPSs; then, we further classified 
existing non-collateralized stablecoins into two types according to their intervention layers 
(protocol, application) and confirmed details of their representative m echanisms. Utilizing 
concepts such as Quantity Theory of Money (QTM), Tobin tax, and speculative attack, our 
survey revealed the status quo where, despite the high potential of non-collateralized sta-
blecoins, they have no standard mechanism to achieve the stablecoin for practical DPSs.

Keywords: cryptocurrency, decentralized payment system, stablecoin, survey paper

1 Introduction

Since Nakamoto [1] first proposed their theoretical concept, a  large variety of cryptocur-
rencies1 have been issued and actively traded online. After hitting a high of almost $20,000 
for one bitcoin in December 2017 [5], the total market capitalization of cryptocurrencies 
reached $796 billion [6]—equivalent to second place in the world ranking of companies by 
market capitalization at that time, right after Apple Inc.’s $911 billion [7].

∗ The Graduate School of Interdisciplinary Information Studies, The University of Tokyo, Japan 
† Daisy, Inc., Tokyo, Japan

1The term cryptocurrency has a number of definitions, such as “any form of currency that only exists dig-
itally, that usually has no central issuing or regulating authority but instead uses a decentralized system to
record transactions and manage the issuance of new units, and that relies on cryptography to prevent counter-
feiting and fraudulent transactions” [2] and “A medium of exchange that functions like money (in that it can
be exchanged for goods and services) but, unlike traditional currency, is untethered to, and independent from,
national borders, central banks, sovereigns, or fiats” [3]. See Houben and Snyers [4] for other legal definitions.

International Journal of Service and Knowledge Management 
International Institute of Applied Informatics
2020, Vol. 4, No. 2, 71 - 86



Figure 1: A Classification Tree for Stablecoins

From the perspective of online payment systems, several studies [8][9] have focused on
the potential of cryptocurrencies as Decentralized Payment Systems (DPSs) that can pro-
vide various advantages, such as “(i) the diffusion of control among stakeholders; (ii) the
ability to engage in trusted commerce without a centralized intermediary; (iii) the potential
to disrupt the rents extracted by centralized intermediaries facilitating commerce; and (iv)
global consistency and transparency on a shared ledger” [8]2. Despite these advantages,
however, cryptocurrencies are now difficult to work as practical DPSs due to their high
price volatility3. The high price volatility undermines the three functions of money (i.e.,
Medium-of-Exchange, Store-of-Value, Unit-of-Account), which results in less demand to
own cryptocurrency for online payments. In fact, according to an online survey in 2018
[14], the awareness of cryptocurrency is 74% on average in the eight largest cryptocur-
rency markets (US, UK, Germany, Brazil, Japan, South Korea, China and India), while its
ownership remains 7% on average.

Stablecoin is an approach to address this problem of high price volatility, which is for
example defined as “a digital currency that is pegged to another stable asset like gold, or to
major fiat currencies like Euros, Pounds or the US dollar” [15]4. Reflecting the necessity
for cryptocurrencies as practical DPSs, the market for stablecoin continues to grow rapidly,
more than doubling from $1.4 billion to $3 billion between 2018 and 2019 [18].

Our study aims to provide a survey on how such stablecoins peg their value to other
assets, from the perspective of DPSs. This attempt is important because, to the best of our
knowledge, there has been no preceding surveys that focuses on the stablecoin as DPSs,
i.e., the one aiming at not only price stabilization but also decentralization. For clarity, as
Figure 1 depicts, we first classify existing stablecoins into four types according to their col-
laterals (fiat, commodity, crypto, and non-collateralized)5 and point out the high potential of
non-collateralized stablecoins as DPSs; then, we further classify existing non-collateralized
stablecoins into two types according to their intervention layers (protocol, application) and

2DPSs develop a variety of protocols to address more specific topics, such as micro payments [10][11] and
transparent monetary policy [12].

3For specific data on the high price volatility, see, for example, Cryptocurrency Index 30 [13].
4Note that there are many other definitions for stablecoin, such as “cryptocurrency that has price stable

characteristics” [16] and “a digital token that will have low price volatility as a result of being pegged to some
underlying fiat currency, thereby acting as a store of value, a medium of exchange and unit of accounting for
blockchain payments” [17].

5This classification is based on the two preceding studies: Zhang et al. [19] and Mancini-Griffoli [20].

Copyright cŠ by IIAI. Unauthorized reproduction of this article is prohibited.

M. Mita, K. Ito, S. Ohsawa, H. Tanaka72



M ¡V = P ¡Q, (1)

where M is the amount of money supply (in a given period), and V is the velocity of money;
P is the price level, and Q is an index of real expenditures on newly produced goods and
services. Namely, the left-hand side represents the scale of an economy through money in
circulation, while the right-hand side represents it through goods and services in circulation.
An implication of this equation is that we can adjust the price level P with M and V if their
change has no (or small) effect on Q (i.e., if money is neutral).

From the viewpoint of stablecoins, the QTM is important because it has been a basis
of the mechanisms for non-collateralized stablecoins. As we will confirm in Section 3, all
non-collateralized stablecoins attempt to stabilize its P by using some mechanism that au-
tomatically adjusts M or V in a decentralized manner6. Specifically, just as central banks
tighten monetary policy against inflation, the mechanism decreases M or V if P becomes too
high, and vice versa. Such mechanisms for automatic price adjustment have become more
feasible thanks to cryptocurrencies in which we can easily manage transaction records and
money supply; on the other hand, there are several related studies preceding cryptocurren-
cies, including the Tobin tax below.

6Note that this P denotes not the price of the stablecoin measured by other currency (e.g., USD) but the
price of goods and services measured by the stablecoin. Accordingly, the higher P means the lower value of
the stablecoin (i.e., inflation).

Copyright cŠ by IIAI. Unauthorized reproduction of this article is prohibited.

confirm details of their representative mechanisms. In addition, to evaluate a variety of
stablecoins, the above process leverages three concepts in economics—Quantity Theory of
Money (QTM), Tobin tax, and speculative attack. Our survey consequently highlights the
status quo where, despite the high potential of non-collateralized stablecoins, they have no
standard mechanism to achieve both price stabilization and decentralization.

The remaining part of this paper is organized as follows. Section 2 covers preliminaries,
which includes the introduction of the three useful concepts in economics and the four
collateral types to classify existing stablecoins. Section 3 provides an in-depth survey on
representative mechanisms in the non-collateralized stablecoin that would have the highest
potential as DPSs, by using the layer-based classification. Finally, Section 4 concludes our
survey with describing implications and our next steps.

2 Preliminaries

In this section, we first introduce three concepts in economics (QTM, Tobin tax, and spec-
ulative attack) which are all useful when considering price-stabilization mechanisms em-
ployed in stablecoins. Moreover, we here classify existing stablecoins into four types ac-
cording to their collateral (fiat, commodity, crypto, and non-collateralized) and point out
that the non-collateralized is the best way to implement stablecoins as DPSs.

2.1 Quantity Theory of Money

QTM is a theory of economics that attempts to explain the price level in terms of the amount
of money in circulation. A representative model in QTM is the equation of exchange which
was formulated by Fisher [21][22] as follows:

What is Stablecoin?: A Survey on Its Mechanism and Potential as Decentralized Payment Systems 73



9See also Diamond and Divig [33] which is the first study to model self-fulfillment in bank runs.

Copyright cŠ by IIAI. Unauthorized reproduction of this article is prohibited.

2.2 Tobin Tax

Tobin tax is a proposal by Tobin [23][24] in 1972, which aims to stabilize the currency
exchange rate by penalizing short-term speculative (noise) trading7; specifically, it is a small
amount (e.g., 0.5%) of tax imposed on international financial transactions to “throw some
sand in the wheels of our excessively efficient international money markets” [24]8.

A variety of studies have analyzed the Tobin tax. For example, McCulloch and Pacillo
[25] surveyed related literature and available empirical evidence, then concluded that the
Tobin tax can be a major source of revenue without causing market distortions while it may
not contribute to the stabilization of exchange rate. To cover its weak contribution to the
stabilization, Spahn [26] extended the Tobin tax to the two-tier rate structure (Spahn tax)
that imposes a higher tax when financial transactions are taken place outside a predeter-
mined range of exchange rate. Furthermore, Liuzzi et al. [27] leveraged an artificial market
to find the optimal rate of the Tobin tax. Their simulation derived the result close to Spahn
[26]: a non-negligible level of taxation for highly liquid markets and low (close to zero)
levels of taxation for low liquidity markets.

From the viewpoint of stablecoins, the Tobin tax is important because it has been one
of the common tools for existing non-collateralized stablecoins. As we will confirm in Sec-
tion 3, several non-collateralized stablecoins adopt the mechanisms which adjust M and V
by imposing some amount of fee on each transaction. Namely, non-collateralized stable-
coins inherit the concept of Tobin tax—“throw some sand in the wheels of our excessively
efficient international money markets” [24]. In addition, although there are few preceding
studies, the Tobin tax should also have implications for collateralized stablecoins, as they
have a risk of speculative attack which we will discuss below.

2.3 Speculative Attack

Speculative attack is an action that inactive speculators suddenly sell a large amount of
currency to deplete the government’s reserves, thereby making the pegged exchange rate
fail. Speculators have an incentive to do this attack because they can make big profits from
short selling, etc. when the (previously maintained) pegged exchange rate fails.

A variety of studies have analyzed how speculative attacks occur. For example, Krug-
man [28] was the first study to model the speculative attack targeting a government with
insufficient reserves in the foreign exchange market, by extending Salant and Henderson
[29]. On the other hand, subsequent studies, such as Obstfeld [30][31] and Chang and Ve-
lasco [32], pointed out that speculative attacks (resulting in currency crisis) may occur even
in a government with sufficient reserves, by taking into account self-fulfilling features in
which a speculator actually sells the currency if she predicts that other speculators may sell
the currency9.

From the viewpoint of stablecoins, the speculative attack is important because it has
been a main risk for existing stablecoins. Collateralized stablecoins would likely to be
subject to speculative attacks, as they have a similar structure to the pegged currencies
relying on government reserves. Despite this potential risk, to the best of our knowledge,
Routledge and Zetlin-Jones [34] is the only preceding study that addresses the speculative

7Tobin first proposed this idea at a lecture held in 1972, while the proceedings of which [23] were compiled
in later years.

8The Tobin tax and its extensions are often referred to as Currency Transaction Taxes (CTTs) or Financial
Transaction Taxes (FTTs).

M. Mita, K. Ito, S. Ohsawa, H. Tanaka74



attack in collateralized stablecoins. Non-collateralized stablecoins would also be subject to
the attack, as long as speculators can profit from their high price volatility or peg failures in
a similar way10. Thus, as stablecoins are (by definition) pegged to other stable assets, we
must prevent their mechanisms from speculative attacks.

2.4 Fiat-, Commodity-, Crypto-, and Non-Collateralized Stablecoins

Based on preceding studies [19][20], this section classifies existing stablecoins into four
types according to their collaterals (Figure 1). In addition, for each type, we briefly explain
its mechanism and problem as DPSs, which are summarized in Table 1 below.

The first type is a fiat-collateralized stablecoin which uses fiat money (e.g., the US dol-
lar) as collateral. To ensure the stability, it employs a simple and intuitive mechanism that
issues new stablecoin on condition that the asset to be pegged is collateralized and, like the
gold standard, commits to exchange the stablecoin for collateral at a fixed rate at any time.
A representative example of this type is Tether [36]—a stablecoin which is promised a one-
to-one exchange with the US dollar. Despite this simplicity, however, the fiat-collateralized
stablecoin has a problem of requiring a centralized custodian to manage deposited collateral
and issue new stablecoins. This is contrary to the aforementioned advantage of DPSs: “the
ability to engage in trusted commerce without a centralized intermediary” [8]. We therefore
cannot use the fiat-collateralized stablecoin as DPSs due to the lack of decentralization.

The second type is a commodity-collateralized stablecoin which uses commodity (e.g.,
gold, oil) as collateral. Although this type uses different collaterals, it actually employs
the same mechanism as the fiat-collateralized stablecoin and thus shares the problem, too.
Representative examples of this type are DigixDAO [37] and Petro [38]—the stablecoins
which are pegged to (and collateralized by) gold in the former and oil in the latter. Needless
to say, we cannot use the commodity-collateralized stablecoin as DPSs due to the same
problem: the lack of decentralization.

The third type is a crypto-collateralized stablecoin which uses cryptocurrency (e.g.,
bitcoin) as collateral. To address the lack of decentralization, it employs a mechanism that
uses cryptocurrency (with a decentralized consensus algorithm) for pegging the stablecoin
to another stable asset (e.g., the US dollar), which allows any anonymous participants to
become a custodian11. A representative example of this type is Dai stablecoin [43]—a sta-
blecoin pegged to the US dollar but collateralized by the cryptocurrency Ethereum [44][45].
On the other hand, the crypto-collateralized stablecoin has another problem that the mecha-
nism, consisting of at least three assets (stablecoin, cryptocurrency as collateral, the asset to
be pegged), is inevitably complicated. In particular, to prevent the speculative attack while
using cryptocurrencies with high price volatility, the mechanism needs much greater collat-
erals than the value of newly issued stablecoin, which is a well-known over-collateralized
problem12. Thus, we cannot use the crypto-collateralized stablecoin as DPSs unless we
develop some simpler mechanism without the over-collateralized problem13.

10The Bitcoin protocol has a similar risk, called goldfinger attack [35] in which miners, even though they
have received bitcoin as a reward, damage its value in order to make profits from short selling or holding
alternative assets.

11Recently, crypto-collateralized stablecoin develops another category referred to as multi-collateralized sta-
blecoin which uses a variety of assets simultaneously as collateral (e.g., using gold, bitcoin, and Japanese yen
for pegging the stablecoin to the US dollar). For example, see Libra [39][40] and Synthetix [41][42]

12For example, the issuance of new Dai stablecoin requires at least 150% collateral (by default).
13Although it is not the main scope of this paper, crypto-collateralized stablecoins have recently developed

new mechanisms to avoid the over-collateralized problem, such as Lien protocol [46].

Copyright cŠ by IIAI. Unauthorized reproduction of this article is prohibited.

What is Stablecoin?: A Survey on Its Mechanism and Potential as Decentralized Payment Systems 75



Table 1: Characteristics of the Four Collateral Types

Collateralized by Decentralization Simplicity

Fiat currency [36] 7

Commodity [37][38] 7

Cryptocurrency [43] 7

None [47][48] 7 7

The fourth type is a non-collateralized stablecoin which does not use anything as col-
lateral. As mentioned above, it employs the mechanism that aims to stabilize P by auto-
matically adjusting M and V in a decentralized manner. If such a simple and decentralized
mechanism were feasible, the non-collateralized stablecoin could obtain the highest po-
tential as DPSs among the four types. However, can we really design the mechanism of
automatic adjustment, even under a variety of risk including the speculative attack? To
confirm the feasibility, we in Section 3 provide an in-depth survey on non-collateralized
stablecoins, which includes the introduction of representative examples [47][48].

In this section, we have introduced the three concepts and the four collateral types as
preliminaries. To summarize, the former implies the importance of preceding discussions in
economics to consider price-stabilization mechanisms for exisitng stablecoins, and the latter
implies the high potential of non-collaterized stablecoins as DPSs. Table 1 represents char-
acteristics of the four collateral types, which reflects (i) fiat- and commodity-collateralized
stablecoins are not decentralized because they require some centralized custodian to manage
collaterals; (ii) crypto-collateralized stablecoin is not simple because it consists of at least
three assets (stablecoin, cryptocurrency as collateral, and the asset to be pegged). Based on
this result, Section 3 focuses on the survey of non-collateralized mechanisms.

3 Non-Collateralized Mechanisms: A Survey

This section provides an in-depth survey on non-collateralized mechanisms, by using the
classification according to their two intervention layers: protocol and application (Figure
1). We here assume that the protocol is a layer related to fundamental consensus-algorithms
for the blockchain (e.g., Proof-of-Work algorithm and Nakamoto consensus in the Bitcoin
protocol), while the application is a layer not related to the consensus-algorithm but for
various systems running on the protocol14. Such layer-based classification became popu-
lar, especially after the Ethereum—an alternative protocol subsequent to the Bitcoin pro-
tocol—enabled application development on blockchains15. To the best of our knowledge,
non-collateralized stablecoins need to intervene in either protocol or application layers.

14See also the following other definitions: ”Protocol layer: consists of the core software building blocks that
make up a distributed ledger” [49]; ”Application layer: consists of all applications that are built on existing
distributed ledger networks” [49]. ”The protocol layer lays the foundational structure of the blockchain. It
determines the computing language the blockchain will be coded in and any computational rules that will
be used on the blockchain” [50]; ”The application layer is where networks and protocol are used to build
applications that users interact with” [50].

15Applications developed on Ethereum are often referred to as Decentralized Applications (DApps) [51].

Copyright cŠ by IIAI. Unauthorized reproduction of this article is prohibited.

M. Mita, K. Ito, S. Ohsawa, H. Tanaka76



18Strictly speaking, while their proposal is based on the Bitcoin protocol, it scopes blockchain-based cryp-
tocurrencies in general.

19Regardless of the block-interval, the current Bitcoin protocol re-adjust the mining difficulty for every 2,016
blocks.

20Regardless of the scale of re-adjustment, the current Bitcoin protocol halves the amount of its mining
reward for every 210,000 blocks.

21Unlike transaction fees in the current Bitcoin protocol, all bitcoins collected as negative interests will be
burned.

22Tobin tax and this negative interest are different in that the former fixes its own rate while the latter varies
its rate depending on time. The ever-increasing negative interest would also have a positive effect on V because
it encourages us to change old coin to new one.

23Note that, prior to Saleh [54], Stewart [56] for the first time proposed the concept of Proof-of-Burn in 2012.

Copyright cŠ by IIAI. Unauthorized reproduction of this article is prohibited.

Furthermore, for protocol and application layers, we confirm their representative mech-
anisms from the perspective of both proposal and implementation, where the former is
based on academic articles and the latter is based on white papers for some project.

3.1 Stabilization by Protocol Layer

The survey for protocol layer first confirms two studies, Saito and Iwamura [52]16 and Saleh
[54], which both propose modified consensus-algorithms in order for the price stabilization
of cryptocurrencies17. Subsequently, as a representative implementation, we also confirm
the USDX project [47] which aims to issue stablecoins pegged with the US dollar.

3.1.1 Proposal

Studies on the protocol for price stabilization have mainly focused on the consensus al-
gorithm which underlies blockchain-based systems. For example, Saito and Iwamura [52]
proposes three modifications to Proof-of-Work algorithm in the current Bitcoin protocol18,
aiming for the stable price P through autonomous adjustment of the money supply M and
the velocity of money V . The first modification limits the re-adjustment of mining diffi-
culty (i.e., Proof-of-Work targets) only when the block-interval exceeds a certain threshold
value19. The second modification makes the amount of mining rewards variable according
to each scale of the aforementioned re-adjustment, instead of the existing halving rule20.
These two modifications are intended to adjust the growth rate of M (as mining reward) in
line with the fluctuating demand (as hash rate). The third modification imposes a negative
interest rate on all bitcoins, which increases in proportion to the time that elapses from the
bitcoin issuance just as assets are depreciated over time. This modification not only re-
strains the ever-increasing M but also intervenes in V because, like the Tobin tax, it collects
the negative interest for every transaction2122. Saito and Iwamura [52] tried to make the
Bitcoin protocol a practical DPS by the combination of these three modifications.

While Saito and Iwamura [52] proposed a modified Proof-of-Work algorithm, Saleh
[54] proposed an alternative algorithm for price stability. He first analyzed Proof-of-Work
by the overlapping-generations model [55]—a framework used in economics—and pointed
out that it can cause exceptional price volatility and welfare impairment. To solve the
problem, Saleh [54] recommends us to adopt Proof-of-Burn algorithm23 in which, to create
new blocks, miners need to send a certain amount of their coins to an unspendable (locked)

16See also Iwamura et al. [53].
17Note that these studies based on the Bitcoin protocol do not apply to stablecoin in the definition by Lund

[15], as they do not envision pegging their value to another asset. On the other hand, they are stablecoins
in the definition by Tomaino [16] which simply defines stablecoin as “cryptocurrency that has price stable
characteristics” [16].

What is Stablecoin?: A Survey on Its Mechanism and Potential as Decentralized Payment Systems 77



26Unlike the Proof-of-Burn, the locked USDY will back to the holders after the predetermined period.

Copyright cŠ by IIAI. Unauthorized reproduction of this article is prohibited.

address. Here, the Proof-of-Burn adjusts mining difficulty through the amount of coins that
should be burned; in other words, his proposal controls M by adjusting the amount of coins
burned as mining costs, against the amount of newly issued coins as mining rewards.

One of the problems with these protocols is that their price stabilization does not use
market price (e.g., BTC/USD) directly, but uses mining difficulty as a proxy variable. It is
still controversial whether the mining difficulty (or hash rate in the case of Bitcoin proto-
col) can be a proxy variable for market prices [57][58]; however, at least on a yearly basis,
there seems to be no explicit correlation between the two [59]. In any case, these protocols
can no longer stabilize prices under a chronic deviation between market prices and mining
difficulty (i.e., unstable proxy variable). Accordingly, in 3.1.2, we introduce an implemen-
tation of the non-collateralized and protocol-based stablecoin, which aims to peg their price
directly with the US dollar.

3.1.2 Implementation

Tiutiun et al. [47] proposed the USDX—a project for non-collateralized stablecoin based
on the protocol layer. This project has issued a stablecoin called USDY24, which aims to
maintain the same price with the US dollar through the following three mechanisms. The
first mechanism is variable block reward [47] to adjust the amount of mining rewards, just
as the second modification in Saito and Iwamura [52]. On the other hand, to adjust mining
rewards, the USDX leverages the USDY/USD price index25, rather than the mining diffi-
culty. That is, when USDY/USD > 1, the amount of mining rewards (USDY) increases
in order for the price reduction (by increasing the growth rate of M), and vice versa. The
second mechanism is lock-in mining [47] which is a kind of emergency measure, activated
only when the state of USDY/USD < 1 persists even if the variable block reward takes
the lowest value. To further reduce the money supply M, the lock-in mining allows users
to (stochastically) create a new block by temporary locking their own USDY for a prede-
termined period which varies according to the rigidity of USDY/USD < 126. When users
successfully create new blocks with the lock-in mining, they can receive mining rewards
(USDY) independent of the variable block reward. The third mechanism is variable trans-
action fee [47], which is the same with the third modification in Saito and Iwamura [52] in
that it burns circulating coin with a variable rate to control M and V . On the other hand, the
USDX also leverages the USDY/USD price index to determine the rate of transaction fee,
rather than the time from the coin issuance. That is, when USDY/USD > 1, the amount of
transaction fee decreases in order for the price reduction (by increasing both M and V ), and
vice versa. The USDX project aims to peg its stablecoin USDY with the US dollar by the
combination of the three mechanisms above.

The problem with the USDX is that its mechanism leads to the unstable purchasing
power (i.e., the amount of USDY × the current price of USDY) in each wallet. While
stablecoin, by definition, focuses on stabilizing its price against other assets, it needs to
stabilize the purchasing power of users as well in order to be a practical DPS satisfying
the store-of-value. In the case of USDX, the variable block reward and the lock-in mining

24This project contains two coins: USDX and USDY, where the former is a type of governance token and
the latter is stablecoin pegged to the US dollar.

25Here, we have another important problem: how to obtain data outside the blockchain (e.g., the USDY/USD
price index) in a decentralized manner while ensuring their reliability? In the context of blockchain, this is often
referred to as the Oracle problem [60]. Although we will spare you the details, the USDX employs an original
mechanism called the decentralized Schelling point Oracle system.

M. Mita, K. Ito, S. Ohsawa, H. Tanaka78



27It was named after the denationalization of money [64]—the concept proposed by Hayek.
28In response to the problem, Morini [62] suggests collecting a small amount of fee from Sav wallets to

decrease M, only if there are extremely few money in Inv wallets. However, needless to say, this is contrary to
the original purpose of stabilizing the purchasing power in Sav wallets.

Copyright cŠ by IIAI. Unauthorized reproduction of this article is prohibited.

intervene only in the purchasing power of miners who voluntarily join the mechanisms; on
the other hand, the variable transaction fee intervenes in that of individuals who do nothing
but hold USDY. Furthermore, although the Tobin tax and negative interest rate in Saito and
Iwamura [52] do the same type of intervention, the variable transaction fee in USDX would
be worse because its fee rate fluctuates unpredictably (according to USDY/USD). Thus,
to enable a constant purchasing power, we should controll M and V through mechanisms
based on some voluntary action (e.g., mining), and if it were inevitable to use transaction
fees, the rates should at least be predictable.

3.2 Stabilization by Application Layer

The survey for application layer, on the other hand, first confirms three studies, Ametrano
[61], Morini [62], and Sams [63]. Even though Ametrano [61] and Morini [62] assume
direct intervention in each wallet, Sams [63] inherits these studies and proposes another
mechanism—Seigniorage Share. Subsequently, we also confirm the detail of the Basis
project [48] as a representative implementation of the Seigniorage Share.

3.2.1 Proposal

Discussions on the application for price stabilization stem from Ametrano [61], which pro-
posed a non-collateralized stablecoin named Hayek Money27. The gist of the Hayek money
is its rebasement mechanism [61] that automatically adjusts M by modifying the amount
of money stocked in each wallet, according to the data on current price which is updated
whenever miners create new blocks. However, as with the USDX project, this simple (and
somewhat primitive) mechanism leads to the unstable purchasing power because the re-
basement directly modifies the amount of money in each wallet.

To address this problem, Morini [62] argued that the Hayek money should divide its
wallet into two types: Inv wallets for investment and Sav wallets for saving. Here, in order
to leave the option of stable purchasing power, the rebasement only intervenes in the Inv
wallets (accordingly, M in Inv wallets is subject to the higher fluctuation than the original
Hayek money, to cover the adjustment for M in Sav wallets). Namely, Morini [62] allows
users to allocate their holding money into both Inv and Sav wallets, thereby offering “the
freedom to choose how much they want to be affected by changes of money supply” [62]
along with their risk appetite. This mechanism appears to be effective as it only intervenes
in the money whose owners have accepted the unstable purchasing power; however, it has
another problem. Consider the case where most users predict an increasing trend of P (i.e.,
a decline in the price of Hayek money). In this case, decreasing M for price-stabilization
becomes difficult because speculators would transfer their money from the Inv wallet to
the Sav wallet in order to avoid the rebasement. To make matters worse, this Inv-to-Sav
transfer will impose the higher decreasing rate on the Inv wallets, which further accelerates
the Inv-to-Sav transfer. Therefore, if speculators could";"""date"",""2020-12-30T18:27:08Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""1"",""1"",""1"",""1"",""6"",""1"",""1"",""1"",""1"",""17"",""1"",""1"",""1"",""1"",""1""
""pdf:PDFVersion"",""1.5""
""xmp:CreatorTool"",""TeX""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dcterms:created"",""2020-11-23T11:25:50Z""
""language"",""en""
""Last-Modified"",""2020-12-30T18:27:08Z""
""dcterms:modified"",""2020-12-30T18:27:08Z""
""dc:format"",""application/pdf; version=1.5""
""xmpMM:DocumentID"",""uuid:6cdce01c-2142-46e2-8ad8-bdc15752dfee""
""Last-Save-Date"",""2020-12-30T18:27:08Z""
""pdf:docinfo:creator_tool"",""TeX""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2020-12-30T18:27:08Z""
""meta:save-date"",""2020-12-30T18:27:08Z""
""pdf:encrypted"",""false""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.20 (TeX Live 2019) kpathsea version 6.3.1""
""xmp:CreateDate"",""2020-11-23T11:25:50Z""
""modified"",""2020-12-30T18:27:08Z""
""Content-Length"",""2170174""
""pdf:hasMarkedContent"",""false""
""Content-Type"",""application/pdf""
""xmp:ModifyDate"",""2020-12-31T03:27:08Z""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.20 (TeX Live 2019) kpathsea version 6.3.1""
""xmp:MetadataDate"",""2020-12-31T03:27:08Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""pdf:producer"",""pdfTeX-1.40.20""
""trapped"",""False""
""meta:creation-date"",""2020-11-23T11:25:50Z""
""created"",""2020-11-23T11:25:50Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""16""
""Creation-Date"",""2020-11-23T11:25:50Z""
""resourceName"",""452""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""2599"",""2674"",""2852"",""3263"",""3730"",""2885"",""3378"",""3471"",""3182"",""3438"",""2473"",""2431"",""2251"",""2401"",""2305"",""928""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""producer"",""pdfTeX-1.40.20""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""pdfTeX-1.40.20""
""pdf:docinfo:created"",""2020-11-23T11:25:50Z""
";https://scholar.google.ch/scholar?start=750&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098809-209;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Adaptively secure constrained pseudorandom functions in the standard model;A Davidson, S Katsumata, R Nishimaki… ; Annual International …, 2020  Springer;;"… CRYPTO 2020: Advances in Cryptology – CRYPTO 2020 pp 559-589 | Cite as … The first and

second constructions are the first CPRFs for any non-trivial predicates to achieve adaptive security

outside of the random oracle model or relying on strong cryptographic assumptions …";Cité 4 fois;Les 3 versions;[PDF] iacr.org;https://eprint.iacr.org/2020/111.pdf;"
Adaptively Secure Constrained Pseudorandom Functions in the
Standard Model∗

Alex Davidson†1, Shuichi Katsumata2, Ryo Nishimaki3, Shota Yamada2, Takashi Yamakawa3

1Cloudflare, Portugal
alex.davidson92@gmail.com

2National Institute of Advanced Industrial Science and Technology (AIST), Tokyo, Japan
{shuichi.katsumata,yamada-shota}@aist.go.jp

3NTT Secure Platform Laboratories, Tokyo, Japan
{ryo.nishimaki.zk,takashi.yamakawa.ga}@hco.ntt.co.jp

January 29, 2021

Abstract
Constrained pseudorandom functions (CPRFs) allow learning “constrained” PRF keys that can evaluate the PRF on

a subset of the input space, or based on some predicate. First introduced by Boneh and Waters [AC’13], Kiayias et al.
[CCS’13] and Boyle et al. [PKC’14], they have shown to be a useful cryptographic primitive with many applications.
These applications often require CPRFs to be adaptively secure, which allows the adversary to learn PRF values and
constrained keys in an arbitrary order. However, there is no known construction of adaptively secure CPRFs based on a
standard assumption in the standard model for any non-trivial class of predicates. Moreover, even if we rely on strong
tools such as indistinguishability obfuscation (IO), the state-of-the-art construction of adaptively secure CPRFs in the
standard model only supports the limited class of NC1 predicates.

In this work, we develop new adaptively secure CPRFs for various predicates from different types of assumptions
in the standard model. Our results are summarized below.

• We construct adaptively secure and O(1)-collusion-resistant CPRFs for t-conjunctive normal form (t-CNF)
predicates from one-way functions (OWFs) where t is a constant. Here, O(1)-collusion-resistance means that
we can allow the adversary to obtain a constant number of constrained keys. Note that t-CNF includes bit-fixing
predicates as a special case.

• We construct adaptively secure and single-key CPRFs for inner-product predicates from the learning with errors
(LWE) assumption. Here, single-key security means that we only allow the adversary to learn one constrained
key. Note that inner-product predicates include t-CNF predicates for a constant t as a special case. Thus, this
construction supports more expressive class of predicates than that supported by the first construction though it
loses the collusion-resistance and relies on a stronger assumption.

• We construct adaptively secure and O(1)-collusion-resistant CPRFs for all circuits from the LWE assumption
and indistinguishability obfuscation (IO).

The first and second constructions are the first CPRFs for any non-trivial predicates to achieve adaptive security outside
of the random oracle model or relying on strong cryptographic assumptions. Moreover, the first construction is also the
first to achieve any notion of collusion-resistance in this setting. Besides, we prove that the first and second constructions
satisfy weak 1-key privacy, which roughly means that a constrained key does not reveal the corresponding constraint.
The third construction is an improvement over previous adaptively secure CPRFs for less expressive predicates based
on IO in the standard model.

∗This work is a major update version of [DKNY18] with many new results.
†Part of this work was completed while the author undertook a research internship at NTT when he was a PhD student at Royal Holloway. The

author was also supported by the EPSRC and the UK Government as part of the Centre for Doctoral Training in Cyber Security at Royal Holloway,
University of London (EP/K035584/1).

1



1 Introduction
Pseudorandom functions (PRFs) provide the basis of a huge swathe of cryptography. Intuitively, such functions take
a secret key and some binary string x as input, and output (deterministically) some value y. The pseudorandomness
requirement dictates that y is indistinguishable from the output of a uniformly sampled function operating solely on x.
PRFs provide useful sources of randomness in cryptographic constructions that take adversarially-chosen inputs. Many
constructions of PRFs from standard assumptions are known, e.g., [GGM86, NRR02, NR04, BPR12].

There have been numerous expansions of the definitional framework surrounding PRFs. In this work, we focus
on a strand of PRFs that are known as constrained PRFs or CPRFs. CPRFs were first introduced by Boneh and
Waters [BW13] alongside the concurrent works of Kiayias et al. [KPTZ13] and Boyle et al. [BGI14]. They differ from
standard PRFs in that they allow users to learn constrained keys to evaluate the PRF only on a subset of the input space
defined by a predicate. Let K be a master key used to compute the base PRF value and let KC be the constrained key
with respect to a predicate C. Then, the output computed using the master key y = CPRF.Eval(K, x) can be evaluated
using a constrained key KC if the input x satisfies the constraint, i.e., C(x) = 1. However, if C(x) = 0, then the output
y will remain pseudorandom from a holder of KC . The expressiveness of a CPRF is based on the class of constraints C
it supports, where the most expressive class is considered to be P/poly.

Similarly to the security notion of standard PRFs, we require CPRFs to satisfy the notion of pseudorandomness on
constrained points. Formally, the adversary is permitted to make queries for learning PRF evaluations on arbitrary
points as with standard PRFs. The adversary is also permitted to learn constrained keys for any predicates Ci ∈ C
where i ∈ [Q] for Q = poly.1 The security requirement dictates that the CPRF remains pseudorandom on a target
input x∗ that has not been queried so far, where Ci(x∗) = 0 for all i. There have been several flavors of this security
requirement that have been considered in previous works: when the adversary can query the constrained keys arbitrarily,
then we say the CPRF is adaptively secure on constrained points; otherwise, if all the constrained keys must be queried
at the outset of the game it is selectively secure.2 When Q > 1, then we say the CPRF is Q-collusion-resistant. In
case Q = poly, we write poly-collusion-resistant and when Q = 1, we say it is a single-key CPRF. These two notions
capture the requirements of CPRFs and satisfying both requirements (adaptively-secure, poly-collusion-resistant) is
necessary for many applications of CPRFs [BW13]. For instance, in one of the most appealing applications of CPRFs
such as length-optimal broadcast encryption schemes and non-interactive policy-based key exchanges, we require an
adaptive and poly-collusion-resistant CPRF for an expressive class of predicates.

We focus on known constructions of CPRFs in the standard model from standard assumptions, that is, CPRFs that
do not rely on the random oracle model (ROM) and non-standard assumptions such as indistinguishability obfuscation
(IO) or multilinear maps. We notice that there exists no construction of adaptively secure CPRFs for any class of
predicates in this standard setting. For instance, even if we consider the most basic puncturable or prefix-fixing
predicates, we require the power of IO or the ROM to achieve adaptive security. (For an explanation on different
types of predicates, we refer to Appendix A). Notably, even though we now have many CPRFs for various predicate
classes from different types of standard assumptions such as the learning with errors (LWE) and Diffie-Hellman (DH)
type assumptions [BFP+15, BV15, BTVW17, CC17, AMN+18, CVW18, PS18], all constructions only achieve the
weaker notion of selective security. In addition, other than selectively-secure CPRFs for the very restricted class of
prefix-fixing predicates [BW13, KPTZ13, BGI14, BFP+15], all the above constructions of CPRFs provide no notion of
Q-collusion-resistance for anyQ > 1. Indeed, most constructions admit trivial collapses in security once more than one
constrained key is exposed. A natural open question arises:

(Q1). Can we construct adaptively secure constrained PRFs for any class of predicates based on
standard assumptions in the standard model; preferably with collusion-resistance?

Next, we focus on CPRFs based on any models and assumptions. So far the best CPRF we can hope for — an
optimal CPRF— (i.e., it supports the constraint class of P/poly, it is adaptively secure, and it is poly-collusion resistant)
is only known based on IO in the ROM [HKKW19]. The moment we restrict ourselves to the standard model without
relying on the ROM, we can only achieve a weaker notion of CPRF regardless of still being able to use strong tools such

1Throughout the introduction, poly will denote an arbitrary polynomial in the security parameter.
2In general, we can upgrade selective security to adaptive security by complexity leveraging. However, we want to avoid this since complexity

leveraging needs subexponentially hard assumptions.

2



as IO. Namely, the following three incomparable state-of-the-art CPRFs (based on IO in the standard model) do not
instantiate one of the requirements of the optimal CPRF: [HKW15] only supports the very limited class of puncturing
predicates; [BLW17] only achieves selective security; and [AMN+19] only achieves single-key security for the limited
class of NC1 predicates. Therefore, a second open question that we are interested in is:

(Q2). Can we construct an adaptively secure and Q-collusion resistant (for any Q > 1) constrained
PRFs for the widest class of P/poly predicates in the standard model?

Note that solving the above question for all Q > 1 will result in an optimal CPRF, which we currently only know how to
construct in the ROM.

1.1 Our Contribution
In this study, we provide concrete solutions to the questions (Q1) and (Q2) posed above. We develop new adaptively
secure CPRF constructions for various expressive predicates from a variety of assumptions in the standard model. We
summarize our results below. The first two results are answers to (Q1), and the last result is an answer to (Q2).

1. We construct an adaptively secure and O(1)-collusion-resistant CPRF for t-conjunctive normal form (t-CNF)
predicates from one-way functions (OWFs), where t is any constant. Here, O(1)-collusion-resistance means that
it is secure against adversaries who learn a constant number of constrained keys. This is the first construction
to satisfy adaptive security or collusion-resistance from any standard assumption and in the standard model
regardless of the predicate class it supports. Our CPRF is based solely on the existence of OWFs. In particular, it
is a much weaker assumption required than all other CPRF constructions for the bit-fixing predicate (which is a
special case of t-CNF predicates) [BW13, BLW17, CC17, AMN+18]. Previous works rely on either the LWE
assumption, the decisional DH assumption, or multilinear maps.

2. We construct an adaptively secure and single-key CPRF for inner-product predicates from the LWE assumption.
Although our second CPRF does not admit any collusion-resistance, inner-product predicates are a strictly wider
class of predicates compared to the t-CNF predicates considered above. (See Appendix C.) All other lattice-based
CPRFs supporting beyond inner-product predicates (NC1 or P/poly) [BV15, BTVW17, CC17, CVW18, PS18]
achieve only selective security and admits no collusion-resistance.

3. We construct an adaptively secure andO(1)-collusion-resistant CPRF forP/poly from IO and the LWE assumption.
More specifically, we use IO and shift-hiding shiftable functions [PS18], where the latter can be instantiated from
the LWE assumption. This is the first adaptively secure CPRF for the class of P/poly in the standard model
(it further enjoys any notion of collusion-resistance). As stated above, current constructions of CPRFs in the
standard model either: only support the limited class of puncturing predicates [HKW15]; achieves only selective
security [BLW17]; or only achieves single-key security for the limited class of NC1 predicates [AMN+19].

We also note that our first two constructions satisfy (weak) 1-key privacy, previously coined by Boneh et al. [BLW17]
(see Remark 3.18for more details on the definition of key privacy).

Applications. As one interesting application, our CPRF for bit-fixing predicates can be used as a building block to
realize adaptively-secure t-CNF attribute-based-encryption (ABE) based on lattices, as recently shown byTsabary [Tsa19].
Other than identity-based encryption [ABB10, CHKP10] and non-zero inner product encryption [KY19], this is the first
lattice-based ABE satisfying adaptive-security for a non-trivial class of policies. The ABE scheme by Tsabary shows
that other than their conventional use-cases, CPRFs may be a useful tool to achieve higher security of more advanced
cryptographic primitives.

An attentive reader may wonder whether our CPRFs have any other applications. For instance, as Boneh and
Waters proved [BW13], one can construct length-optimal broadcast encryption schemes from CPRFs for bit-fixing
predicates. However, unfortunately, for these types of applications, we require Q-collusion-resistance where Q is an
a-priori bounded polynomial. Therefore, we cannot plug in our construction for these types of applications. We leave
it as an interesting open problem to progress our CPRF constructions to achieve Q-collusion-resistance for larger Q;
achieving Q = ω(1) would already seem to require a new set of ideas.

3



Relation to the lower bound by Fuchsbauer et al. [FKPR14]. One may wonder how our adaptively secure CPRF
relates to the lower bound of adaptively secure CPRFs proven by Fuchsbauer et al. [FKPR14]. They proved that we could
not avoid exponential security loss to prove adaptive pseudorandomness of the specific CPRF for bit-fixing predicates by
Boneh and Waters based on multilinear maps [BW13]. Fortunately, their proofs rely heavily on the checkability of valid
constrained keys by using multilinear maps. Therefore, their lower bounds do not apply to our setting since none of our
constructions have checkability.

Comparison with Existing Constructions. There are several dimensions to consider when we compare CPRF
constructions. In this section, we focus on adaptively secure CPRFs as it is one of our main contributions. Along with
related works, a more extensive comparison is provided in Appendix A. The following Table 1 lists all the adaptively
secure CPRFs known thus far. One clear advantage of our first two CPRFs is that they are the first CPRF to achieve
adaptive security without relying on IO or the ROM. However, it can be seen that this comes at the cost of supporting
a weaker predicate class, or achieving single-key or O(1)-collusion-resistance. Regarding our third CPRF, the main
advantage is that it achieves adaptive security and supports the broadest predicate class P/poly without resorting to the
ROM. Compared to the recent CPRF by Attrapadung et al. [AMN+19], we provide a strict improvement since our first
construction supports O(1)-collusion-resistance.

Table 1: Comparison among adaptively secure CPRFs. In column “Predicate”, LR, BF, t-CNF, and IP stand for left-right-fixing,
bit-fixing, t-conjunctive normal form, and inner-product predicates, respectively. In column “Assumption”, BDDH, LWE, SGH, and
L-DDHI stand for bilinear decisional Diffie-Hellman, multilinear decisional Diffie-Hellman, learning with errors, subgroup hiding
assumption, and L-decisional Diffie-Hellman inversion assumptions, respectively. Regarding key privacy, ‡ means that this satisfies
weak key privacy.

Adaptive Collusion-resistance Privacy Predicate Assumption
[BW13] X poly poly LR BDDH & ROM

[HKKW19] X poly 0 P/poly IO & ROM
[HKW15] X poly 0 Puncturing SGH & IO
[AMN+18] X 1 1 BF ROM

X 1 0 NC1 L-DDHI & ROM
[AMN+19] X 1 0 NC1 SGH & IO
Section 4 X O(1) 1‡ t-CNF (⊇ BF) OWF
Section 5 X 1 1‡ IP LWE
Section 6 X O(1) 0 P/poly LWE & IO

Historical Note on Our First Contribution. In the initial version of this paper, we gave a construction of adaptively
secure and O(1)-collusion-resistant CPRFs for bit-fixing predicates. After the initial version, Tsabary [Tsa19] observed
that essentially the same idea could be used to construct adaptively single-key secure CPRFs for t-CNF predicates for a
constant t. We further extend her construction to construct adaptively secure and O(1)-collusion-resistant CPRFs for
t-CNF predicates for a constant t in the current version. We stress that (the initial version of) this paper is the first to
give adaptively secure or collusion-resistant CPRFs under a standard assumption and in the standard model, for any
non-trivial class of predicates.

2 Technical Overview
In this section, we explain the approach we took for achieving each of our CPRFs. For CPRFs for bit-fixing (and t-CNF)
predicates, we take a combinatorial approach. For CPRFs for inner-product predicates, we take an algebraic approach
based on lattices incorporating the so-called lossy mode. For CPRFs for P/poly, we use shift-hiding shiftable functions
[PS18] and IO as main building blocks. In the subsequent subsections, we explain these approaches in more detail.

4



2.1 CPRF for Bit-Fixing/t-CNF
We achieve CPRFs for t-CNF predicates. However, we consider our CPRF for bit-fixing predicates in the technical
overview rather than the more general CPRF for t-CNF predicates for ease of presentation. The high-level idea is very
similar and generalizes naturally. Here, a bit-fixing predicate is defined by a string v ∈ {0, 1, ∗}` where ∗ is called the
“wildcard”. A bit-fixing predicate v on input x ∈ {0, 1} is said to be satisfied if and only if (vi = xi) ∨ (vi = ∗) for all
i ∈ [`].

We first focus on how to achieve collusion-resistance because the structure for achieving collusion-resistance
naturally induces adaptive security.

Combinatorial Techniques for CPRFs for bit-fixing predicates. We start with a simpler case of single-key CPRF
for bit-fixing predicates as our starting point. We use 2` keys of standard PRFs to construct an `-bit input CPRF for
bit-fixing predicates. Let PRF.Eval : {0, 1}κ × {0, 1}` 7→ {0, 1}n be the evaluation algorithm of a PRF. We uniformly
sample keys Ki,b ∈ {0, 1}κ for i ∈ [`] and b ∈ {0, 1}. The master key of the CPRF is K = {Ki,b}i∈[`],b∈{0,1} and
evaluation on some x ∈ {0, 1}` is computed as the output of:

CPRF.Eval(K, x) =
⊕̀
i=1

PRF.Eval(Ki,xi , x).

Figure 1 depicts the construction.

¡ ¡ ¡

K1,0

K1,1

K2,0

K2,1

K3,0

K3,1

K`,0

K`,1

Figure 1: Length-` directed line representation where each nodes are labeled with two PRF keys. In the figure, the
choices of PRF keys correspond to some input x = 011 ¡ ¡ ¡ 0.

The constrained key for a bit-fixing predicate v ∈ {0, 1, ∗}` constitutes a single PRF key Ki,vi (where vi ∈ {0, 1}),
and a pair of PRF keys (Ki,0,Ki,1) (where vi = ∗). Constrained evaluation is clearly possible for any input x that
satisfies the bit-fixing predicate v since we have keys Ki,vi for non-wildcard parts and both keys (Ki,0,Ki,1) for wildcard
parts.

The (selective) security of the scheme rests upon the fact that for a single constrained key, with respect to v, there
must exist a j ∈ [`] such that (x∗j 6= vj) ∧ (vj 6= ∗) for the challenge input x∗. This is due to the fact that the bit-fixing
predicate v does not satisfy x∗. Then, pseudorandomness of y ← CPRF.Eval(K, x∗) is achieved because

y ←
⊕̀
i=1

PRF.Eval(Ki,x∗
i
, x∗) = PRF.Eval(Kj,x∗

j
, x∗)⊕

⊕
i 6=j

PRF.Eval(Ki,x∗
i
, x∗)


where PRF.Eval(Kj,x∗

j
, x∗) is evaluated using the key that is unknown to the adversary. Thus, this evaluation can be

replaced with a uniformly sampled yj ∈ {0, 1}n by the pseudorandomness of PRF for key Kj,x∗
j
. In turn, this results

in a uniformly distributed CPRF output y and so pseudorandomness is ensured. We can instantiate pseudorandom
functions using only one-way functions [GGM86, HILL99], and therefore, so can the above single-key CPRF for the
bit-fixing predicate.

Allowing> 1 constrained key query. If we allow for more than two constrained key queries in the above construction,
the scheme is trivially broken. Consider an adversary that queries the two bit-fixing predicates v = 0 ∗ ∗ . . . ∗ ∗0 and
v̄ = 1 ∗ ∗ . . . ∗ ∗1 as an example. Notice that any binary string x of the form x = 0 . . . 1 or x = 1 . . . 0 will not satisfy

5



either of the predicates. Therefore, we would like the evaluation value y on such input x by the master key to remain
pseudorandom to the adversary. However, the adversary will be able to collect all PRF keys {Ki,b}i∈[`],b∈{0,1} by
querying v and v̄, and recover the master key itself in our construction above. Therefore, the adversary will be able to
compute on any input x regardless of its constraints.

Collusion-resistance for two constrained key queries. At a high level, the reason why our construction could not
permit more than one constrained key query is because we examined each of the input bits individually when choosing
the underlying PRF keys. Now, consider a scheme that considered two input bits instead of considering one input bit at
each node in Figure 1. Figure 2 illustrates this modified construction. In the set-up shown in Figure 2 at each node (i, j),
we now consider the ith and jth input bits of the string x ∈ {0, 1}` and choose the key K(i,j),(b1,b2) where b1 = xi and
b2 = xj ; the master key is the combination of all such keys K = {K(i,j),(b1,b2)}(i,j)∈[`]2,(b1,b2)∈{0,1}2 .

¡ ¡ ¡ ¡ ¡ ¡

{K(1,1),(x1,x1)} {K(1,`),(x1,x`)} {K(2,1),(x2,x1)} {K(`,`),(x`,x`)}

Figure 2: Length-`2 directed line representation where each nodes consider two input bits, where (xi, xj) ∈
{0, 1} × {0, 1} for all i, j ∈ [`].

Evaluation is then carried out by adding the PRF values along the directed line illustrated in Figure 2:

CPRF.Eval(K, x) =
⊕

(i,j)∈[`]×[`]

PRF.Eval(K(i,j),(xi,xj), x),

and constrained keys for v ∈ {0, 1, ∗}` contain the key K(i,j),(b1,b2), for all b1, b2 ∈ {0, 1} such that(
(vi = b1) ∨ (vi = ∗)

)∧(
(vj = b2) ∨ (vj = ∗)

)
,

is satisfied.
To see how this combinatorial change in the construction has an impact on the collusion-resistance of the scheme,

consider a pair of constrained key queries for bit-fixing predicates v, v̄ ∈ {0, 1, ∗}`. Let x∗ be the challenge input
that is constrained with respect to both v, v̄. Then there exists an i′ ∈ [`] where (x∗i′ 6= vi′) ∧ (vi′ 6= ∗) and likewise
(x∗j′ 6= v̄j′) ∧ (v̄j′ 6= ∗) for some j′ ∈ [`]. Equivalently, we must have x∗i′ = 1 − vi′ and x∗j′ = 1 − v̄j′ for some
i′, j′ ∈ [`]. As a result, for these constrained key queries we observe that the underlying PRF key K(i′,j′),(1−vi′ ,1−v̄j′ )
will never be revealed to the adversary.

Using this fact, we can prove that our new CPRF construction achieves collusion-resistance for two constrained key
queries using essentially the same aforementioned proof technique. We rewrite the CPRF evaluation on x∗ as:

CPRF.Eval(K, x∗) =
⊕

(i,j)∈[`]×[`]

PRF.Eval(K(i,j),(x∗
i
,x∗
j
), x
∗)

= PRF.Eval(K(i′,j′),(x∗
i′
,x∗
j′

), x
∗)⊕

 ⊕
(i,j)6=(i′,j′)

PRF.Eval(K(i,j),(x∗
i
,x∗
j
), x
∗)

 .

Notice that, since K(i′,j′),(x∗
i′
,x∗
j′

) is never revealed to the adversary, this evaluation is indistinguishable from a uniformly
sampled value y∗. In a simulation where y∗ replaces the underlying PRF evaluation, the entire CPRF evaluation on x∗
is distributed uniformly and pseudorandomness follows accordingly.

Expanding to O(1)-collusion-resistance. The technique that we demonstrate in this work is a generalisation of the
technique that we used for two-key collusion-resistance. Instead of considering two input bits at a time, we consider Q

6



input bits at a time and index each node in the evaluation by the vector (i1, . . . , iQ) ∈ [`]Q. Then we evaluate the CPRF
on x ∈ {0, 1}` as the output of:

CPRF.Eval(K, x) =
⊕

(i1,...,iQ)∈[`]Q
PRF.Eval(K(i1,...,iQ),(xi1 ,...,xiQ ), x).

The constraining algorithm works for a bit-fixing predicate defined by v ∈ {0, 1, ∗}` by providing all keys
K(i1,...,iQ),(b1,...,bQ) such that ∧

j∈[Q]

(bj = vij ) ∨ (vij = ∗)

is satisfied. Constrained evaluation is then possible for any input x satisfying the bit-fixing predicate defined by v.
For any set of Q constrained key queries associated with strings v(1), . . . , v(Q) and any constrained input x∗,

there must exist a vector (i′1, . . . , i′Q) such that (x∗i′
j
6= v

(j)
i′
j

) ∧ (v(j)
i′
j
6= ∗) for all j ∈ [Q]. Therefore, the key

K(i′1,...,i′Q),(x∗
i′1
,...,x∗

i′
Q

) is never revealed to the adversary. Finally, we can prove the selective pseudorandomness of the

CPRF on input x∗ using exactly the same technique as mentioned in the case when Q = 2. The proof of security is
given in the proof of Theorem 4.2.

Importantly, we cannot achieve collusion-resistance for unbounded Q because there is an exponential dependency
on Q associated with the size of the CPRF. For instance, for the node indexed by the vector (i1, . . . , iQ), there are 2Q
underlying PRF keys associated with this node; moreover, there are `Q such nodes. Therefore the total size of K is
(2`)Q. As a result, we are only able to afford Q = O(1) since ` is the input length of PRF, which is a polynomial in the
security parameter. This bound is inherent in the directed line paradigm because our technique is purely combinatorial.

Finally, we assess the security properties achieved by our CPRF for bit-fixing predicates. Although we have been
showing selective security of our CPRF, we observe that our construction satisfies adaptive security when the underlying
pseudorandom functions satisfy adaptive pseudorandomness.

Achieving Adaptive security. Our construction arrives at adaptive security essentially for free. Previous constructions
for bit-fixing predicates (or as a matter of fact, any non-trivial predicates) incur sub-exponential security loss during the
reduction from adaptive to selective security, or relies on the random oracle model or IO; see Appendix A, Table 2for an
overview. The sub-exponential security loss is incurred as previous constructions achieve adaptive security by letting
the reduction guess the challenge input x∗ that the adversary chooses.

We can achieve adaptive security with a polynomial security loss (e.g. 1/poly(Îş)): by instead guessing the key
(not the challenge input) that is implicitly used by the adversary (i.e. KT∗,x∗

T
for T ∗ ⊂ [`], |T ∗| = Q). For example

in the 2-key setting explained above, this amounts to correctly guessing the values (i, j) and (x∗i , x∗j ) of the PRF key
K(i,j),(x∗

i
,x∗
j
), which happens with probability at most (1/2`)2. If this key is not eventually used by the challenge

ciphertext, or it is revealed via a constrained key query, then the reduction algorithm aborts. This is because the entire
proof hinges on the choice of this key, rather than the input itself. Since there are only polynomially many keys (for
Q = O(1)), we can achieve adaptive security with only a 1/poly(Îş) probability of aborting.

Finally, we note that there is a subtle technical issue we must resolve which is addressed in Lemma 4.3due to the
non-trivial abort condition. Similar problems were identified by Waters [Wat05] who introduced the “artificial abort
step”.

2.2 CPRF for Inner-Product
We construct CPRF for the class of inner-product predicates (over the integers) based on lattices.

The starting point of our CPRF is the lattice-based PRF of [BLMR13, BP14]. At a very high level, the secret key K
of these PRFs is a vector s ∈ Znq and the public parameters is some matrices (Ai ∈ Zn×mq )i∈[k]. To evaluate on an
input x, one first generates a (publicly computable) matrix Ax ∈ Zn×mq related to input x and simply outputs the value
bs>Axcp ∈ Zmp , where bacp denotes rounding of an element a ∈ Zq to Zp by multiplying it by (p/q) and rounding
the result. Roughly, the values s>Ax + noise are jointly indistinguishable from uniform for different inputs x since

7



Ax acts as an LWE matrix. Therefore, if the noise term is sufficiently small, then bs>Axcp = bs>Ax + noisecp, and
hence, pseudorandomness follows.

Pioneered by the lattice-based CPRF of Brakerski and Vaikuntanathan [BV15], many constructions of CPRF
[BKM17, BTVW17] have built on top of the PRF of [BLMR13, BP14]. The high-level methodology is as follows:
the constrained key for a constraint C would be a set of LWE ciphertexts of the form KC := (cti = s>(Ai −
Ci ¡G) + noise)i∈[k], where Ci is the ith bit of the description of the constraint C and G is the so-called gadget
matrix [MP12]. To evaluate on input x using the constrained key KC , one evaluates the ciphertexts (cti)i∈[k] to
ctx = s>(Ax− (1−C(x)) ·G)+noise, using the by now standard homomorphic computation technique of [BGG+14]
originally developed for attribute-based encryption (ABE) schemes. Here, Ax is independent of the constraint C, that is,
Ax can be computed without the knowledge of C. Then, the final output of the CPRF evaluation with the constrained
key will be bctxcp. Now, if the constraint is satisfied, i.e., C(x) = 1, then computing with the constrained key KC will
result in the same output as the master key K since we would have ctx = s>Ax + noise.

Unfortunately, all works which follow this general methodology only achieves selective security. There is a noted
resemblance between this construction with the above types of CPRF and the ABE scheme of [BGG+14]. As a
consequence, achieving an adaptively secure CPRF following the above methodology would likely shed some light onto
the construction of an adaptively secure lattice-based ABE. Considering that adaptively secure ABEs are known to
be one of the major open problems in lattice-based cryptography, it does not seem to be an easy task to achieve an
adaptively secure CPRF following this approach.

We take a different approach by taking advantage of the fact that our constraint is a simple linear function in this
work due to the technical hurdle above. Specifically, we only embed the constraint in the master key s instead of
embedding the constraint in the master key s and the public matrices (Ai)i∈[k] as (s>(Ai − Ci ·G))i∈[k]. To explain
this idea, we need some preparation. Let y ∈ Z` be the vector associated with the inner-product constraint Cy, that is,
the constrained key KCy can evaluate on input x ∈ Z` if and only if 〈x,y〉 = 0 (over the integers). We also slightly
modify the PRF of [BLMR13, BP14] so that we use a matrix S ∈ Zn×`q instead of a vector s ∈ Znq as the secret key. To
evaluate on input x ∈ Z` with the secret key S, we will first compute the vector sx = Sx ∈ Zn and then run the PRF of
[BLMR13, BP14], viewing sx as the secret key. That is, the output of the PRF is now bs>x Axcp.

The construction of our CPRF is a slight extension of this. The master key and evaluation with the master key is the
same as the modified PRF. Namely, the master key is defined as K := S and the output of the evaluation is bs>x Axcp.
Our constrained key for the constraint Cy is then defined as KCy := Sy = S + d⊗ y> ∈ Zn×`q where d is a uniformly
random vector sampled over Znq . Evaluation with the constrained key KCy = Sy is done exactly the same as with
the master key K = S; it first computes sy,x = Syx and outputs bs>y,xAxcp. It is easy to check that if 〈x,y〉 = 0
(i.e., Cy(x) = 1), then Syx = (S + d ⊗ y>)x = sx. Hence, the constrained key computes the same output as the
master key for the inputs for which the constraint is satisfied. The construction is very simple, but the proof for adaptive
security requires a bit of work.

As a warm-up, let us consider the easy case of selective security and see why it does not generalize to adaptive
security. When the adversary A submits Cy as the challenge constraint at the beginning of the selective security game,
the simulator samples Ŝ $← Zn×`q and d $← Znq ; sets the master key as K = Ŝ − d ⊗ y> and the constrained key as
KCy = Ŝ; and returns KCy to A. Since the distribution of K and KCy is exactly the same as in the real world, the
simulator perfectly simulates the keys to A. Now, notice that evaluation on input x with the master key K results as

z =
⌊(

(Ŝ− d⊗ y>)x
)>

Ax

⌋
p
≈ b(Ŝx)>Axcp − 〈x,y〉 · bd>Axcp = CPRFKCy

(x)− 〈x,y〉 · PRFd(x),

where CPRFKCy
(x) is the CPRF evaluation with constrained key ";"""date"",""2021-01-29T06:26:02Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2021-01-29T06:26:02Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.19 (TeX Live 2018) kpathsea version 6.3.0""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2021-01-29T06:26:02Z""
""created"",""2021-01-29T06:26:02Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2021-01-29T06:26:02Z""
""resourceName"",""111.pdf""
""Author"",""""
""producer"",""pdfTeX-1.40.19""
""pdf:docinfo:producer"",""pdfTeX-1.40.19""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""9"",""22"",""61"",""28"",""52"",""33"",""0"",""7"",""44"",""39"",""44"",""11"",""5"",""20"",""33"",""17"",""10"",""15"",""31"",""42"",""35"",""21"",""49"",""60"",""116"",""20"",""22"",""23"",""16"",""27"",""14"",""17"",""38"",""57"",""0"",""0"",""0"",""5"",""4"",""9"",""9"",""25"",""9"",""14"",""19"",""35"",""43"",""6"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2021-01-29T06:26:02Z""
""Last-Modified"",""2021-01-29T06:26:02Z""
""dcterms:modified"",""2021-01-29T06:26:02Z""
""title"",""""
""Last-Save-Date"",""2021-01-29T06:26:02Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2021-01-29T06:26:02Z""
""meta:save-date"",""2021-01-29T06:26:02Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.19 (TeX Live 2018) kpathsea version 6.3.0""
""Content-Length"",""793248""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""52""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""3043"",""4418"",""3856"",""3099"",""2545"",""2696"",""3503"",""4237"",""4247"",""4496"",""3432"",""2396"",""2154"",""2298"",""2762"",""2946"",""2523"",""1608"",""2126"",""2723"",""2164"",""2348"",""1903"",""2895"",""2819"",""2727"",""1671"",""2435"",""2720"",""2227"",""3428"",""2678"",""2026"",""1940"",""2616"",""3019"",""3091"",""3180"",""3232"",""3216"",""2724"",""3443"",""1879"",""2637"",""1524"",""2339"",""2148"",""1942"",""2691"",""3272"",""359"",""1945""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2021-01-29T06:26:02Z""
";https://scholar.google.ch/scholar?start=750&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098822-237;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Cloud-Based Blockchaining for Enhanced Security;D Jeyabharathi, D Kesavaraja, D Sasireka ; … of Research on Blockchain …, 2020  Elsevier;;"… The ongoing instances of such effective combination of the blockchain with cloud stages are

Oracle Blockchain Cloud Service venture (Prophet, 2017) and iEx.ec … Blockchain is a novel

technology that, besides its application to cryptocurrency, features fascinating …";Autres articles;;[PDF] researchgate.net;https://www.researchgate.net/profile/Vibha-Nehra/publication/339591585_Blockchain_Implementation_for_Internet_of_Things_Applications/links/603ddce94585154e8c6e19e2/Blockchain-Implementation-for-Internet-of-Things-Applications.pdf#page=204;;;https://scholar.google.ch/scholar?start=780&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098804-196;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;[CITATION][C] BTSO: A Blockchain Protocol Based on Reconfigurable Byzantine Consensus;I Abraham, D Malkhi, K Nayak, L Rowadoski…;;;null;Autres articles;;null;;;;https://scholar.google.ch/scholar?start=740&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098729-30;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Blockchain-based access control management for Decentralized Online Social Networks;MU Rahman, B Guidi, F Baiardi ; Journal of Parallel and Distributed …, 2020  Elsevier;;"… is a decentralized social networking platform that is designed by using the Ethereum Blockchain.

Interesting features of the platform include support for customization and rewarding contents

creators without the need of central authorities. Furthermore, its cryptocurrency is called …";Cité 5 fois;Les 4 versions;[PDF] helios-h2020.eu;https://helios-h2020.eu/wp-content/uploads/2020/08/JPDC_Journal_RW1-2-1.pdf;"
Blockchain-based Access Control Management for
Decentralized Online Social Networks

Mohsin Ur Rahmana, Barbara Guidia, Fabrizio Baiardib

aDepartment of Computer Science, University of Pisa
bDepartment of Philology, Literature, and Linguistics, University of Pisa

Abstract

Online Social Networks (OSNs) represent today a big communication channel
where users spend a lot of time to share personal data. Unfortunately, the big
popularity of OSNs can be compared with their big privacy issues. Indeed, sev-
eral recent scandals have demonstrated their vulnerability. Decentralized Online
Social Networks (DOSNs) have been proposed as an alternative solution to the
current centralized OSNs. DOSNs do not have a service provider that acts as
central authority and users have more control over their information. Several
DOSNs have been proposed during the last years. However, the decentraliza-
tion of the social services requires efficient distributed solutions for protecting
the privacy of users. During the last years the blockchain technology has been
applied to Social Networks in order to overcome the privacy issues and to offer a
real solution to the privacy issues in a decentralized system. However, in these
platforms the blockchain is usually used as a storage, and content are public. In
this paper, we propose a manageable and auditable access control framework for
DOSNs using blockchain technology for the definition of privacy policies. The
resource owner uses the public key of the subject to define auditable access con-
trol policies using Access Control List (ACL), while the private key associated
with the subject’s Ethereum account is used to decrypt the private data once
access permission is validated on the blockchain. We provide an evaluation of
our approach by exploiting the Rinkeby Ethereum testnet to deploy the smart
contracts. Experimental results clearly show that our proposed ACL-based ac-
cess control outperforms the Attribute-based access control (ABAC) in terms
of gas cost. Indeed, a simple ABAC evaluation function requires 280,000 gas,
instead our scheme requires 61,648 gas to evaluate ACL rules.

Keywords: Decentralized Online Social Networks, Blockchain, privacy issue,
Access Control List

∗Corresponding Author: Barbara Guidi, guidi@di.unipi.it

Preprint submitted to Journal of Parallel and Distributed Computing June 12, 2020



1. Introduction

Today, millions of users are actively using Social Media, such as Facebook,
Instagram, Twitter, etc. In particular, Online Social Networks (OSNs), such as
Facebook, are used by 700 million users, and it attracts nearly 31% of global
Internet users on a daily basis. People are attracted to social networks because
they are free, fun, and offer useful social services, such as easy communication,
marketing, games, etc. Usually, users trust the services of the service providers
to manage their data and mine it only for specific purposes (i.e., targeted adver-
tising). Furthermore, they also trust the providers for enforcing access control
policies in order to protect their personal sensitive information such as profiles,
pictures, videos, and other posted items. However, OSNs have not consistently
achieved these objectives.

Due to the uncertain privacy guarantees of today’s OSNs, online users are
seeking for alternative data sharing techniques that offer them the possibility
to gain control of their own data (i.e., to enable them to manage their data on
their own), and to limit the support of the large service providers in controlling
their own personal information. To meet these requirements, Decentralized
Online Social Networks (DOSNs) have been proposed, ranging from Peer-to-
Peer (P2P) decentralized solutions to hybrid solutions integrating private and
external resources for storing users’ data [1, 2].

A DOSN is a decentralized social platform that facilitates social networking
services in distributed environments [1]. It is worthy to note that the dynamic
P2P nature of DOSNs necessitates distributed and lightweight access control
techniques [3, 4]. Due to the highly dynamic environment of DOSNs, guaran-
teeing data availability, defining lightweight and privacy-preserving access con-
trol algorithms, suitable algorithms for information diffusion in a distributed
environment, are the current open problems in this area [1].

Several architectures for DOSNs have been proposed. Most of them use en-
cryption in order to guarantee privacy [5, 6, 7], and only a minor part is based
on the trust concept in order to guarantee privacy [8, 9, 10]. To guarantee
privacy preserving in DOSNs, several techniques have been proposed. In par-
ticular, techniques, such as the Attribute-based Access Control (ABAC) [11],
role-based access control (RBAC) [12], and rule-based access control, are pro-
posed in order to increase the level of privacy and to guarantee more control
over data [13, 14, 15, 16]. Consider the current usage of social media, these tech-
niques are not able to provide a scalable, manageable and efficient mechanism
to meet the security requirements of DOSNs. The main issues in a DOSN are
the distributed nature of the network, the need to manage private data of users
which can not be stored everywhere in the network, and the data availability.
Access control techniques in current DOSNs require online nodes to evaluate
the access. A new generation of DOSNs takes into account the blockchain tech-
nology, as explained in [17]. However, current Blockchain-based Online Social
Networks are proposed principally to provide a way to manage the fake news
issue, and to reward users for valuable content. Usually, personal information
is stored in the blockchain and they are visible to everyone by excluding the

2



privacy options. A critical question arises: how can we design an auditable and
trustworthy access control system for DOSNs by exploiting the properties of
the blockchain technology? Indeed, the emerging blockchain technology and the
popular Ethereum platform (i.e., smart contracts) [18] can be used to address
this challenging issue. In this paper we propose a blockchain-based decentral-
ized social networks where blockchain is used as a tool for privacy preserving,
and where context information is used to define privacy policies. The novelty
of the proposed system is the application of the blockchain as a support for
access control in a DOSN scenario, by exploiting an ACL model. For the sake
of readiness, the proposed system takes into account the main characteristics
of DOSNs by exploiting access control methods, in particular privacy policies
with the support of the blockchain, which is used as a tool, instead of content
storage, by providing a trustworthy access control system.

We test different implementations of our smart contracts and our experimen-
tal evaluation shows that the Resource Owner (RO) can create a single policy
for a maximum of 14 subjects. Moreover, we tested different implementations of
the reputation contract with different number of subjects and the results show
that it can simultaneously evaluate the reputation for 66 subjects. Finally, the
inspector contract simultaneously evaluates the punishment for 75 subjects in
the DOSN network. These experiments aim to evaluate the effects of code com-
plexity on gas consumption in the Ethereum network. Our approach requires
61,648 gas to evaluate ACL rules and it clearly outperforms a simple ABAC
evaluation which requires 280,000 gas. We clearly observe that contract stor-
age and contract operations have a direct impact on gas consumption in the
Ethereum network.

The main contributions of this article are summarized as follows:

• the design of a new ACL-based access control model for DOSNs, by using
the Ethereum blockchain which provides a unique address for each regis-
tered account, which is used as the identity for each user in this framework.

• the implementation of smart contracts over the Ethereum blockchain: the
Access Control Contract able to control access to resources in the network,
the Reputation Contract to provide a trustworthy system, the Inspector
Contract able to inspect the behaviour of users, and the Registrar Con-
tract (RegC) able to find the identifying information of the access control
contracts and the corresponding access control functions.

• the usage of the challenge-response authentication protocol to verify users’
identities.

• the dynamic validation of the behavior of subjects in case of access re-
quests.

• the design of a model which takes into account context information, such
as time and location of access to define fine-grained access control policies.
In particular, time and location are important information used to define
a context in new generation of DOSNs, as described in [2]

3



• the evaluation of the proposed system on the Ethereum network in order
to evaluate the model and the gas consumption.

The rest of the paper is structured as follows. Section 2 presents the related
work concerning the major concepts considered in this paper. Section 3 discusses
the access control requirements for DOSNs. Section 4 presents the architecture
of our proposed framework. Section 5 introduces the set of smart contracts used
in our proposed framework. Section 6 describes the Access Control Process.
Section 7 reports the evaluation of the proposed approach. Finally, section 8
concludes the paper with a summary of achievements and directions for future
research.

2. Background and Related Work

In this Section, we provide an overview of both the current DOSNs and
blockchain-based solutions in order to explain the scenario in which our pro-
posal is located. Furthermore, we provide the state of art concerning the access
control, and a summary concerning the proposed scenario in order to explain
the contribution of our paper.

2.1. Decentralized Online Social Networks

The main difference among the current DOSN proposals concerns the tech-
nologies and techniques used to store and manage data. A possible classification
considering this difference has been proposed in [1]. One of the first decentralized
solutions, which has today more than 600,000 users, is Diaspora1, a federated
DOSN, where users provide servers that are administered by themselves and
that allow Diaspora users’ profiles to be hosted on their servers. If Diaspora
can be considered the distributed version of Facebook, Mastodon [19] represents
the decentralized version of Twitter. Mastodon is a decentralized microblogging
network based on open protocols and free, open-source software. During the last
two years, Mastodon was increasing the number of users (about 2M of users),
surpassing Diaspora. Mastodon is formed by a set of servers, known as instances,
and each user is a member of a specific Mastodon instance, but can connect and
communicate with users on other instances. Like Twitter, Mastodon supports
direct, private messages between users, but unlike Twitter, Mastodon’s mes-
sages can be either private to the user, private to the user’s followers, public on
a specific instance, or public across a network of instances. Mastodon is part
of the Fediverse, an interconnected and decentralized network of independently
operated servers, which includes platforms such as Diaspora, Friendica, GNU
Social, PeerTube, etc. Fediverse is a common name for the union of various
federated social networks which use a set of standard protocols: OStatus, Ac-
tivityPub, DFRN, Diaspora Network, and Zot. Diaspora, Mastodon, and all
the other systems in the FeDiverse project are not completely decentralized.

1https://joindiaspora.com

4



Indeed, they are federated and there are servers which communicate between
them. As concerns fully-decentralized DOSNs, as the scenario proposed in this
paper, several research applications have been proposed.
Safebook [20] is a three-tier architecture with the main focus on privacy, in-
tegrity and availability. Each user has a set of logical concentric structures
called Matryoshkas. Matryoshkas are concentric rings of nodes built around
each peer and provide a trusted data storage and communication obfuscation
through indirection.
PeerSon [21] is a two-tier architecture in which one tier is implemented by a
Distributed Hash Table (DHT) and it serves as a look-up service. The second
tier consists of peers and contains the user data, such as user profiles.
My3 [9] is a privacy-friendly DOSN which exploits well-known interesting prop-
erties of Online Social Networks, for instance the locality of users and the trust
among them. Users’ profiles are hosted only on a set of self-chosen trusted
nodes, called Trusted Proxy Set (TPS). Exploiting availability and performance
goals, as its geographical location and the online time period of the user, pop-
ulates the TPS of a user.
DiDuSoNet [8] is a two-tier system, where the lower level is implemented by
a DHT, and the upper level is implemented by exploiting a social overlay[1].
In the social overlay, nodes are connected to other nodes with whom the tie
strength computed on the interaction between them is higher. Social data are
stored only on trusted nodes, and each node can choose two replicas to have a
high level of availability.
Several DOSNs integrate the P2P layer with external resources, such as cloud
storage services, to increase the quality of service. External resources are used to
cope with the situations in which the users cannot deliver the service by them-
selves. Vis-à-Vis [22], Vegas [23], and SuperNova [24] are only three examples
of approaches in which cloud services are used.

2.2. Blockchain-based Online Social Networks

During the last years, several Blockchain-based Online Social Networks (BOSNs)
[17] have been proposed. These platforms give more importance to the content
by providing rewarding systems and they aim to address the problems of privacy
and fake news using the blockchain technology.
Steemit2 is a social media platform where everyone can receive a reward for
creating and curating content, in the form of STEEM, which is the unit that is
bought and sold for actual money on the open markets. It has more than one
million users and it represents the most well-known BOSN. An important char-
acteristic of Steemit is that it is fast, free, and scalable. Steemit operates based
on one-STEEM one-vote, instead of one-user one-vote, as in other platforms.
Within this model, individuals who have contributed the most to the platform
have the most influence over how contributions are scored.

2https://steemit.com/

5



SocialX3, as all the previous platforms, is decentralized and allows users to
give content feedback and reward tokens. All media files (photos and videos)
and data (messages, posts etc) are decentralised. The platform wants to face the
problem of fake accounts, fake followers, and fake votes (likes, etc.). Indeed, the
decision power is given to communities, which can decide the valuable content.

Sapien4 is a decentralized social networking platform that is designed by
using the Ethereum Blockchain. Interesting features of the platform include
support for customization and rewarding contents creators without the need
of central authorities. Furthermore, its cryptocurrency is called SPN, which is
ERC20 complaint. The SPN is based on proof of value consensus mechanism in
order to differentiate high-quality contents in the network.

2.3. Access Control Models

The Role-Based Access Control (RBAC) [25] model enables access to re-
sources based on roles, and supports principles such as separation of duties, least
privilege and partition of administrative functions. However, the basic RBAC
model is vulnerable to the role-explosion problem, thereby making it unsuitable
for the implementation of access control policies that involves complex DOSN
scenarios. One of the main problems when implementing RBAC in distributed
networks is the role-explosion problem. Solutions, such as self-management, can
be used to solve the role-explosion problem in such an environment.

To address the limitations of the RBAC model in distributed network set-
tings, a new Attribute-based Access Control (ABAC) model [11] was introduced
to define fine-grained access control policies and to solve the role-explosion prob-
lem (i.e., to decrease the number of rules associated with the RBAC model).
This model considers various attributes such as subject attributes and envi-
ronmental attributes to define access control policies. Consequently, an AC
authority can grant access rights by considering users’ attribute certificates.

Authorization and access control to personal data are important properties
in both OSNs and DOSNs systems. OSNs define access policies based on trust
or the tie strength of users. In DOSNs, access control components need to be
reactive to the dynamic of the network. Considering the proposed access control
models, RBAC are not suitable for DOSNs due to the need of specific informa-
tion that can not be provided in this model [16]. The same problem with a
rule-based access control, such as the one proposed in [26], where authors in-
troduce a model for the users in OSNs, where the policies are based on social
type information, such as relationship type and trust, stored in a server. This
specific solution can not be applied in a decentralized scenario due to the single
point of failure of a server. On the contrary, Access control list (ACL) provides
a popular technique to implement access control policies because it is suitable
for situations in which the resource owners set permissions for their resources.

3https://socialx.network/
4https://beta.sapien.network/

6



ACL is suitable for DOSNs because it provides a fine-grained mechanism allow-
ing users to restrict their sensitive content to a select subset of their friends [27].
The ACL includes a list of one or more subjects and a set of rules. Each of the
subjects is associated with a set of operations that the subject can perform on
the resource. The set of rules specify conditions at which a different set of oper-
ations is to be associated with one or more of the subjects in the list of subjects.
With ACL, the resource owner matches subjects to resources on a one-to-one ba-
sis. A subject performs an operation on a resource if that subject or a group to
which that subject belongs is specified in the ACL associated with the resource
[28]. Moreover, ACL provides information about the mode of access that sub-
jects are authorized to perform on resources. Access to a resource can be easily
revoked by deleting the associated row containing an existing ACL-based policy.

2.4. Summary of the state of the art

The current status of DOSNs systems is evolving by exploiting new tech-
nologies, such as the blockchain. Current blockchain-based social media mainly
exploit the blockchain to resolve the problem of fake news and to reward users
for valuable contents, as described in [17]. Furthermore, these systems use the
blockchain to store social data of users, which is not in line with the privacy
issue. Privacy has been one of the most important point of DOSNs. Current
P2P DOSNs provide methods for access control policies without the usage of the
blockchain, such as [16, 29]. These methods are affected by the dynamic of peers
and they require online peers to validate privacy policies. For this reason, there
is the need to manage the access control systems with a more stable solution
which can address the problem of node churn. Our proposed system takes into
account the main characteristics of DOSNs by exploiting privacy policies with
the support of the blockchain, because the main characteristics of the blockchain
technology can help to efficiently manage privacy issues5. The blockchain is a
tool to guarantee a trustworthy access control system for DOSNs. The system
is based on blockchain technology whereas the policies are enforced by it. As
concerns the Access Control Requirements for DOSNs, in [16], authors propose
a list of requirements. In particular the attention is posed to the resources
without any central authority or trusted third parties, and to the definition of
specific operation types on a resource.
The choice to combine ACL with the blockchain technology to implement our
access control model has been done because in social relationships there is the
need to provide access privileges which are mostly dependent on the social be-
haviour of users, such as the same job. Indeed, the trust is a good way to
specify the access privileges, and we want to provide a model to guarantee this
by exploiting two important information concerning contexts: time and location.

5https://helios-social.com/project/

7



The introduction of a blockchain-based access control for DOSNs can help
to overcome the privacy preserving issues of these systems by exploiting the
characteristics of the blockchain technology. In [30], a similar work has been
proposed, however authors use the blockchain as a trusted server to provide
central control services, such as user identity, newsfeed notification, and friend
recommendation.

3. Requirements Overview

Compared to OSNs which allow the service provider to manage the access
control problem, DOSNs demand new requirements for access control due to the
decentralization of the infrastructure for social networking services. In partic-
ular, special attention is needed for access control because DOSNs do not rely
on a central authority. Furthermore, we need to think of a fine-grained access
control model that fulfills the access control requirements. The following access
control properties are essential to successfully tackle the access control problem
in DOSNs:

• The provision of a user-driven and trustworthy access control for DOSNs
in a distributed setting is still a challenging research problem [31] [1].

• A fine-grained access control must address both users’ resources (i.e., pic-
tures, videos, files, etc.) and context information.

• Resources need to be protected in a user-driven manner without the sup-
port of a central authority or trusted third parties [1].

• The access control mechanism must be flexible that would allow users to
define different permissions for different operations such as view, down-
load, read and write etc. [16].

• The access control must be manageable that would allow users to easily
modify the existing policies stored in the blockchain.

• The resource owner should be able to revoke a policy that he/she has
already created. To perform this operation, he/she simply needs to make
a new transaction specifying the policy that needs to be revoked [32].

• Users in the DOSN network should be able to create a policy for a single
user or group of users as well as for a single resource or multiple resources.
In other words, a user would be able to add a group of users to perform
an operation on a single or multiple resources.

• The access control must be restrictive in the sense that a user would be
able to perform policy-related actions (i.e., policy creation, update and
revocation) and cannot perform these actions on behalf of other users in
the DOSN network.

8



Our access control requirements for DOSNs are based on the needs and di-
versity of subscribers. We decide to use the access control lists (ACLs) [28] due
to its flexibility to support distributed operation. Furthermore, ACL provides
support for important elements such as groups/teams and context information.
It is notable that, in our scheme, the access right validation is conducted by mul-
tiple entities (i.e., trusted nodes), thereby mitigating the single point of failure
issue associated with a centralized entity. Moreover, context information, such
as time and location of access, play an important role in designing a fine-grained
access control solution [33]. Thus, our proposal allows users to create security
policies based on these features while taking into account the features discussed
in the requirements list. Context-aware access control is a security technique
which considers different types of context information to control access to re-
sources. In the last few years, several context-aware access control techniques
have been proposed such as spatial information, temporal information, and both
location and time [34]. However, collecting and sharing context information in
DOSNs may lead to privacy problems because context data contains personal
data. Consequently, a context-aware access control system requires sound pri-
vacy measures to ensure that the users’ personal information are not linked to
their real identities. It is worth noticing that our blockchain-based solution ex-
ploits pseudonymity to provide anonymity protection, which ensures that each
registered user is associated with an anonymous ID that shows no information
about the real identity of that user.

4. Access Control Framework

In this paper, we address how blockchain can support DOSNs in order to
provide a distributed, auditable, user-driven, and scalable access control system
using smart contracts. This paper proposes a novel context-aware access con-
trol system using ACLs implemented using smart contracts. The emergence of
blockchain has eliminated the need for a central agency, by allowing applica-
tions and services to operate in a decentralized fashion, without the support of
a central authority.
Our framework proposes a set of smart contracts: the Access Control Contract
(ACC) able to control accesses to resources in the network, the Reputation Con-
tract (RC) to provide a trustworthy system, and finally the Inspector Contract
(IC) able to inspect the behaviour of users.
The main actors of our framework include the Resource Owner (RO), who is
the owner of a specific resource, nodes trusted from the RO, and subjects who
are interested to perform different operations on the resources of the RO. Our
proposal allows the RO to define access rights for his/her resource using ACLs,
thereby preventing trusted nodes from fraudulently denying the access rights
granted by ACLs. The RO uses the IDs of subjects to create fine-grained and
auditable access control policies using its personal ACC. Furthermore, the ap-
proach allows users to check the blockchain at any time to determine the status
of access rights. It is worth noticing that a subject interested in performing an
operation on a resource of the RO must assert that it possesses a unique ID

9



Figure 1: Illustration of the policy creation, authentication and authorization process

that was used by the RO to create a policy in the blockchain.
As illustrated in Figure 1, a RO in a DOSN can send transactions to its personal
Access Control Contract (ACC) in order to define access rights for a resource.
Furthermore, the ACC consists of necessary functions to perform the task of
access right validation based on the policy list published on the blockchain.

The RO has a set of trusted nodes where data are stored, as described in
[13], in order to guarantee the data availability even when the user is offline.
The choice of trusted replica nodes is outside the scope of this article. A generic
request is sent to the RO when it is online, otherwise it is sent to one of the
trusted nodes chosen at random. Each RO has a unique personal ACC deployed
on the blockchain to control access to resources. Trusted nodes get information
about the RO’s ACC from the registrar (RegC) contract. These nodes then use
the RO’s ACC to check access permission for the requested operation. Based on
the evaluation of access control policies, the subject is either allowed or denied to

10



Figure 2: Blockchain-based architecture for Decentralized Online Social Networks

perform the requested operation on the resource of the RO. It is worth noticing
that trusted nodes only check the status of access permission in the blockchain
and all the policy ownership operations such as policy creation, update and
revocation are performed by the RO. Figure 2 shows the architecture of our
access control framework.

Figure 3 describes the smart contract system included in our proposal. As
shown, the smart contract system consists of three different smart contracts:
the Access Control Contract, the Inspect Contract, and finally the Reputation
Contract. Each of these has a specific role in our proposal. Indeed, the RO
can use its personal ACC to control access to resources in the network; the
Inspect Contract inspects the access requests sent to the ACC and punishes the
subjects if they do not follow the rules of the ACC; the Reputation Contract
(RepC) computes the reputation score of users in the network; and the Registrar
Contract (RegC) which enables trusted nodes to find the identifying information
of the access control contracts and the corresponding access control functions.
In OSNs, the access to resources are managed by server in a centralized way.
In a DOSNs, there is the need to prevent privacy issues, and in our specific
scenario we need to check the behaviour of users in a decentralized way. This
important service is a challenge in a decentralized system due to the dynamic of
the network and the lack of a central server which can check all the users. For
this reason, we decide to introduce in our framework, a reputation score which
highlights the behaviour of a user, and thanks to the Reputation Contract, each
reputation score is stored in the blockchain and public available. This provides
a trustworthy access control system.

11



Figure 3: Illustration of the smart contract system

It is worthy to note that the reputation record is visible on the blockchain,
thereby enabling the resource owner (RO) to exclude users from the policy list
if they have negative reputation in the network.

A subject will be classified as dishonest for different reasons which are defined
and given as an input of our system. For example, a user can be considered
dishonest if it sends too frequent access requests to access the resources of the
RO. In that specific case, the access frequency is a parameter, and it should
take into account real social information, such as the behaviour of bots, which
are able to access to resource several times per seconds.

5. The System of Smart Contracts

In this section, we provide a detailed overview of our proposed smart contract
system shown in Figure 3.

5.1. Access Control Contract (ACC)

The ACC is the contract used to control access to resources. Each RO has a
unique ACC deployed on the Ethereum blockchain to control access to resources
in the DOSN. The RO can create or update an access control policy by sending
transactions to its personal ACC that contains information about the policy.
Moreover, each ACC is associated with a policy list that contains information

12



Resource Subject Location Time Range Action Permission LRT
File A user 2 Location A 10:00 - 15:00 download deny 2019-06-05 12:20
File B user 9 Location B 20:00 - 22:00 write deny 2019-06-06 20:15
obj 2 user 6 Location C 14:00 - 15:00 view allow 2019-06-07 14:11
obj 1 user 6 Location D 10:00 - 12:00 view allow 2019-05-20 11:11
File D user 7 Location E 08:00 - 11:00 write allow 2019-05-20 11:11

Table 1: Illustration of the RO’s policy list

about access control policies. An example of the policy list is provided in Table
1. Each field of the policy list is discussed below:

• Subject: This field indicates the unique id (i.e., Ethereum address) of the
subject in the DOSN network

• Resource: This field indicates the name of the resource that needs to be
included in the access control process.

• Action: It specifies the action that can be performed on the given resource
such as view, download, read, write, etc.

• Location: This field holds information about the access location of the
subject.

• Time Range: This field can be used by the RO to specify a time range in
order to restrict the access time to access resources.

• Permission: This field is used to describe the permission on a certain
(resource, subject) pair such as allow or deny.

• Last Request Time (LRT): This field records the time of the last access
request from the subject.

For the sake of simplicity, we suppose that each row of the policy list contains
a single subject ID only. However, our proposed solution is flexible because the
ACL rules can be configured to include multiple subjects as well. Indeed, the
RO can create an ACL-based policy for multiple subjects in a single transaction.
Moreover, the RO can easily revoke an existing policy by sending a policy re-
vocation transaction specifying the identification information of the policy that
need";"""date"",""2020-08-10T13:07:37Z""
""pdf:PDFVersion"",""1.5""
""xmp:CreatorTool"",""LaTeX with hyperref""
""pdf:docinfo:title"",""Blockchain-based Access Control Management for Decentralized Online Social Networks""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""Blockchain-based Access Control Management for Decentralized Online Social Networks""
""xmp:CreateDate"",""2020-06-12T12:31:14Z""
""modified"",""2020-08-10T13:07:37Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""xmp:ModifyDate"",""2020-08-10T15:07:37Z""
""pdf:docinfo:creator"",""Mohsin Ur Rahman; Barbara Guidi; Fabrizio Baiardi; ""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.20 (TeX Live 2019) kpathsea version 6.3.1""
""meta:author"",""Mohsin Ur Rahman; Barbara Guidi; Fabrizio Baiardi; ""
""trapped"",""False""
""meta:creation-date"",""2020-06-12T12:31:14Z""
""created"",""2020-06-12T12:31:14Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-06-12T12:31:14Z""
""resourceName"",""JPDC_Journal_RW1-2-1.pdf""
""Author"",""Mohsin Ur Rahman; Barbara Guidi; Fabrizio Baiardi; ""
""producer"",""pdfTeX-1.40.20""
""pdf:docinfo:producer"",""pdfTeX-1.40.20""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""1"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""Mohsin Ur Rahman; Barbara Guidi; Fabrizio Baiardi; ""
""dcterms:created"",""2020-06-12T12:31:14Z""
""Last-Modified"",""2020-08-10T13:07:37Z""
""dcterms:modified"",""2020-08-10T13:07:37Z""
""title"",""Blockchain-based Access Control Management for Decentralized Online Social Networks""
""xmpMM:DocumentID"",""uuid:6ee24b9a-c323-4466-a2d6-ca02fc73cc8f""
""Last-Save-Date"",""2020-08-10T13:07:37Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2020-08-10T13:07:37Z""
""meta:save-date"",""2020-08-10T13:07:37Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.20 (TeX Live 2019) kpathsea version 6.3.1""
""Content-Length"",""552066""
""Content-Type"",""application/pdf""
""xmp:MetadataDate"",""2020-08-10T15:07:37Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Mohsin Ur Rahman; Barbara Guidi; Fabrizio Baiardi; ""
""pdf:producer"",""pdfTeX-1.40.20""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""32""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""2021"",""2842"",""2556"",""2391"",""2460"",""2621"",""2532"",""2039"",""2770"",""972"",""1559"",""1053"",""2132"",""2791"",""2132"",""2510"",""1979"",""2096"",""2033"",""2398"",""1181"",""2711"",""2313"",""2159"",""2227"",""2313"",""1439"",""953"",""1997"",""2101"",""1984"",""2040""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-06-12T12:31:14Z""
";https://scholar.google.ch/scholar?start=570&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098826-248;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;A Setup-Free Threshold Encryption Scheme for the Bitcoin Protocol and Its Applications;G Hanaoka, Y Sakai, T Shimizu… ; … on Fundamentals of …, 2020  search.ieice.org;;"… in a security model where an adversary can access both the decryption and signing oracles … op-

erations such as multiplication and division are performed through an oracle query to … members

sign transactions for trading cryptocurrency which will be added into a blockchain …";Autres articles;;null;;;;https://scholar.google.ch/scholar?start=790&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098791-169;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;[PDF][PDF] Maintenance of Long-Living Smart Contracts.;M Lohr, S Peldszus ; Software Engineering (Workshops), 2020  west.unikoblenz.de;;"… Instead, it is possible to create so-called Oracles … However, the process for updating the

information contained in the oracle can not be initialized by a smart contract … Therefore, all

blockchain environments known to us use the blockchain as a log for the results …";Cité 2 fois;Les 2 versions;[PDF] uni-koblenz.de;https://west.uni-koblenz.de/pdf/4517694554c8c9e10491f932baf1f081.pdf;"
Maintenance of Long-Living Smart Contracts
Matthias Lohr

CCRDMT, University of Koblenz-Landau
Koblenz, Germany

matthiaslohr@uni-koblenz.de

Sven Peldszus
University of Koblenz-Landau

Koblenz, Germany
speldszus@uni-koblenz.de

Abstract—In recent years, blockchains became widely known
for offering immutable and trust-free storage of arbitrary in-
formation. Blockchains also leverage smart contracts, a concept
for executing program code for modifying the blockchain state.
While the characteristics of a blockchain, especially immutability,
enable reliability in a trust-free environment, it hinders the
maintenance of smart contracts itself.

With the increasing number, size, and lifetime of smart
contracts, they could be considered to be long-living software.
Therefore, it might become necessary to apply common tech-
niques from software engineering to maintain smart contracts.
However, updating smart contracts residing within the immutable
blockchain data raises an interesting challenge.

In this work, we analyze whether the assumption of smart
contracts being long-living is true, study how immutable smart
contracts are maintained in practice and elaborate the challenges
appearing due to these maintenance practices.

Index Terms—blockchain, smart contract, software engineer-
ing, maintenance, security

I. INTRODUCTION

Blockchains are considered to offer an immutable storage
for arbitrary data in a decentralized manner. In addition to
the widely known use case as crypto currency, it is also
possible to store the code and the result of executable programs
called smart contracts. Due to the property of immutability of
blockchains and thus also of the smart contracts stored, and
due to the determinism of the execution of smart contracts, it is
possible to validate execution results, which is the underlying
concept of a blockchain. The immutable storage of smart con-
tracts on a blockchain makes the contracts available forever.
The fact of smart contracts being available and executable
forever might qualify them as long-living software. However,
a system is not necessarily long living only because of its
implementation being stored and executable over a long period
of time. There are additional factors like maintenance and
active usage that have to be considered.

One of the biggest issues most long-living systems in
the software context have to deal with, is structural decay
due to software aging [1] resulting in the formation of de-
sign flaws [2]. Usually, long-living systems are subject to
continuous changes due to bug fixes, adoption to changing
environments, or extension with new features. When using
the blockchain for storing smart contracts, resulting from the
immutability property, it is not possible to update or delete
smart contracts. Therefore, there is no chance of fixing bugs
or adding new features once a smart contract is deployed to
the blockchain. However, this implies that a smart contract has

to be bug free and feature complete starting from the first time
it is deployed on the blockchain.

While the two challenges of implementing bug free and
feature complete smart contracts could theoretically be solved
for very small and finalized functionalities, changes in the
environment might require a change in the software system
but can neither be foreseen nor planned. These environmental
changes might include legal changes (e. g. GDPR [3]), changes
of underlying system (e. g. changes of how smart contracts are
executed on the respective blockchain instance), new attacks
against security mechanisms that have been assumed to be
secure (e. g. DES [4]), etc. To keep the smart contract legal or
secure it has to be changed.

In this work, we discuss the challenges in maintaining long-
living smart contracts. We first elaborate the assumption that
smart contracts can be considered as long-living software. We
then discuss, which mechanisms are available to update smart
contracts and how developers can deal with the urge to update
smart contracts.

The remainder of this work is structured as follows. At first,
we provide a brief background on blockchain and smart con-
tracts in Sec. II. In Sec. III, we discuss whether smart contracts
can be considered as long-living software, the update mecha-
nisms provided by the different smart contract platforms, and
how smart contracts are updated in practice. Afterwards, we
discuss related work in Sec. IV and conclude in Sec. V.

II. BACKGROUND

For a better understanding of the concerns of this paper,
we provide some general and some blockchain environment
specific background information on smart contracts.

A. General Background on Smart Contracts

In the context of blockchains, a smart contract is a software
program which is executed by several nodes participating in
the respective blockchain network. A smart contract contains
instructions on how the state of the blockchain should be
modified depending on the set of provided input parameters.
Furthermore, depending on the actual implementation, it is
also possible for a smart contract to trigger external actions
which are not observable by the blockchain. Since on-chain
state changes are observable by the blockchain, i. e. by all
participating nodes, each node can validate and accept or
ignore proposed state changes if their own computation result
equals or differs to the previously published result.

Copyright Š 2020 for this paper by its authors. Use permitted under Creative Commons License Attribution 4.0 International (CC BY 4.0).



One of the main properties utilized by smart contracts is
the concept of being free of trust. As blockchains allow us to
trace everything that happened on a blockchain, there is no
need to trust someone as we can proof everything ourselves.

There are different approaches for the implementation of
smart contracts. In this paper, we focus on the most important
blockchain platform in terms of market capitalization1, the
Ethereum blockchain [5]. To give an impression about the
possible variety of implementations, we compare Ethereum
to Hyperledger Fabric [6], a blockchain concept which signifi-
cantly differs from Ethereum in several properties, but supports
Turing-complete smart contracts as Ethereum does.

In the following subsections we give more background
information about Ethereum and Hyperledger Fabric and de-
scribe identified properties regarding smart contract implemen-
tation on blockchains.

B. Ethereum Smart Contracts
Bitcoin[7], the crypto currency that made blockchains be-

came widely known, already offered support for a simple set
of rules for unlocking account balances. Ethereum [5] is the
second most important public blockchain platform in terms
of market capitalization after Bitcoin, but the most important
one that offers support for Turing-complete smart contracts. In
Ethereum, smart contracts can be written in Solidity2 which is
compiled into bytecode. For deployment, the bytecode is writ-
ten to the Ethereum blockchain (using a create transaction). A
deployed smart contract can be identified by its address, which
is calculated using a cryptographic hash function. Once a smart
contract is deployed, Ethereum does not allow for modification
or deletion of the smart contract code. However, according to
the rules defined in the smart contract, it is possible to modify
the state of the smart contract by invoking smart contract
methods (using call transactions). Ethereum smart contracts
can implement a selfdestruct method, which allows the owner
to mark a contract as obsolete. Selfdestruction results in not
being able to use the smart contract anymore and is not
reversible.

When a user wants to call a smart contract method, he cre-
ates a call transaction with the address of the Smart Contract
and all input parameters. This transaction is published to the
network and processed by so-called mining nodes, which will
execute transaction and create a new block with the outcome.
Since the order of the transaction and the bytecode of the
smart contract is publicly known, everybody can validate the
transaction. For including the result into a new block, miners
have to execute the code. Besides the inherent consensus algo-
rithm of the Ethereum blockchain there is no need for conflict
resolution for transaction results, since – assuming correct
execution – each mining node will come to the same result.
This way, state changes are deterministic and unambiguous.
The execution pattern of Ethereum is called Order-Execute.

For our analysis, we used Ethereum data dumps provided
by Blockchair.com [8]. Since the Ethereum main network was

1CoinMarketCap Ranking – http://coinmarketcap.com [accessed Dec19]
2Solidity Documentation – http://solidity.readthedocs.io [accessed Dec19]

0 200 400 600 800 1000 1200 1400
0

50

100

150

200

250

N
um

be
r o

f c
re

at
es

 in
 th

ou
sa

nd
s

Days since the start of Ethereum

0 200 400 600 800 1000 1200 1400
0

5

10

15

20

25

30

35

Nu
m

be
r o

f c
all

s i
n 

m
illio

n

Fig. 1. Number of calls (solid line) and creates (dashed line) over time

Fig. 2. Contract size over time

started in July 2015 until end of October 2019 2,988,133
contracts have been deployed so far. According to Fig. 1 the
number of created and executed smart contracts per day has
continuously increased. The same holds for the size of the
smart contracts, which is visualized in Fig. 2.

C. Hyperledger Fabric Smart Contracts

Hyperledger Fabric [6] is a framework for creating busi-
ness grade permissioned blockchains. The main differences
between permissioned and public blockchains are that a
permissioned blockchain requires authorized access to the
blockchain while public blockchains allow users to create
an unlimited number of pseudonyms. In Hyperledger Fabric,
smart contracts can be written in any programming language
and run as standalone software. The code of a smart contract
is not part of the blockchain but can be developed and
distributed using established software deployment and delivery
architectures. When a smart contract program is started, it

http://coinmarketcap.com
http://solidity.readthedocs.io


TABLE I
COMPARISON OF SMART CONTRACT PLATFORM CHARACTERISTICS REGARDING ETHEREUM AND HYPERLEDGER FABRIC

Property Name Ethereum Hyperledger Fabric

a) Programming Language specific arbitrary
b) Code Deployment on-chain custom
c) Code Distribution on-chain custom
d) Executing Peers mining and validating nodes endorsing nodes
e) Execution Environment Ethereum Virtual Machine arbitrary
f) External Communication not possible possible
g) Result Distribution on-chain on-chain

listens to incoming transactions, calculates the result according
to the input parameters and the code and sends back the result
to the blockchain infrastructure.

When a user wants to call a smart contract, he creates a new
transaction containing the name of the smart contract and all
input parameters. This transaction is published to the network
and processed only by nodes having access to the smart con-
tract program (called endorsing nodes). All endorsing nodes
send their results to an ordering service, which defines the
order in which the transactions are applied to the blockchain.
After the transaction results have been ordered, each node in
the network applies the outcomes following predefined policies
for that specific environment. These policies can define, how
many and which kind of nodes have to present a certain result
before it gets accepted to be appended to the blockchain.

D. Smart Contract Platform Characteristics

We identified the following characteristics regarding smart
contract execution. For a comparison between Ethereum and
Hyperledger Fabric see Table I.

a) Programming Language: Depending on the smart
contract platform, smart contract developers are limited in
choosing programming languages.

For example, Solidity was influenced by existing program-
ming languages like C++, Python and JavaScript, but is
designed for use with Ethereum only. In Hyperledger Fabric, a
smart contract runs as individual application, so it is possible
to use any programming language for software development.

b) Code Deployment: Code deployment denotes how the
blockchain network is informed about a new smart contract.
Other nodes can use this information for creating transactions
to request smart contract execution.

In Ethereum, this is done by creating a transaction which
contains the smart contract and registers it with the blockchain.
In Hyperledger Fabric, this is done by publishing some meta
information (smart contract name, smart contract version, ...)
to the network. The actual code is not part of this information.

c) Code Distribution: This property describes, how the
smart contract code is distributed to the nodes which want to
execute the smart contract.

In Ethereum, since the smart contract code is deployed
to the blockchain, it is distributed along with the block
data. In Hyperledger Fabric, distribution is up to the smart
contract operator, which can use common software distribution
mechanisms (e. g. a website, package repository, etc.).

d) Executing Peers: In a blockchain network, executing
smart contracts could be a bottleneck if all nodes are obliged
to execute any smart contract, e. g. for verification. The whole
network would have to wait for the slowest node. For this
reason, only a subset of nodes in a network is actually
executing smart contract code.

In Ethereum, since the smart contract code is part of the
publicly available blockchain data, any node could execute
smart contracts. But only the one node, which “finds” a
new block is getting paid for executing smart contracts by
receiving transaction fees. Other nodes, which want to verify
the execution result can, but do not have to, execute the
smart contract on their own. In Hyperledger Fabric, nodes can,
depending on the smart contract, have the endorser role. Only
endorsing nodes will execute smart contracts. However, before
a node can become an endorsing node, the node operator has
to get the smart contract code.

e) Execution Environment: The execution environment
defines the limits in which a smart contract can run regarding
both functionality and resource consumption.

In Ethereum, smart contracts are executed in the Ethereum
Virtual Machine (EVM), which supports Turing-complete pro-
grams provided, but with a limited subset of available libraries.
Each bytecode instruction has an assigned cost value (Gas),
which has to be payed for executing the smart contract.
This way, the Ethereum Virtual Machine protects executing
nodes from high computational load, since the execution will
abort if the Gas limit is reached. In Hyperledger Fabric the
execution environment is not constrained. Nevertheless, smart
contract code is usually executed in a virtual environment
(e. g. Docker) for protecting the host from possible malicious
actions. However, it is still possible to induce high loads to
the host system, if the virtual environment is not properly
configured for limiting available hardware resources.

f) External Communication: Depending on the applica-
tion, a smart contract may need additional data, which is not
provided by the contract call. In this case, a smart contact
needs access to external data sources (e. g. weather sensor).

In Ethereum, it is not possible to query off-chain data
sources. Instead, it is possible to create so-called Oracles.
An Oracle is a smart contract, which contains a certain
information and can be updated from another source using
smart contract method calls. However, the process for updating
the information contained in the oracle can not be initialized by
a smart contract. In Hyperledger Fabric, since a smart contract



is realized as a standalone software program, it can access
any data source it wants to. Depending on the data source
(e.g. random value generator) this might result in different
results for multiple smart contract invocations with the same
input parameters provided in the call transaction. Therefore, a
method for result conflict resolution is required.

g) Result Distribution: Smart contract execution would
be useless if the execution results are ignored. Therefore, all
blockchain environments known to us use the blockchain as a
log for the results.

On Ethereum, every node can validate the result since input
parameters, code and result are written to the blockchain. In
Hyperledger Fabric, predefined policies decide how consensus
is reached if endorsing peers offer different possible results.

III. DISCUSSION

In this section, we discuss the state of the art regarding the
usage and update mechanisms of smart contracts. This covers
an analysis whether smart contracts can be considered as long-
living software and a summary of the update mechanisms
provided by different smart contract platforms. From the state
of the art and practical usage of update mechanisms we derive
issues in the development of long-living smart contracts and
discuss how software engineering can address those issues.

A. Are Smart Contracts Long-Living Systems?

As we described before, the immutability of the Ethereum
blockchain seems to automatically result in every smart con-
tract to be long-living as it cannot be removed or updated.
However, only being stored on the blockchain does not nec-
essarily imply longevity. In the context of smart contracts we
consider longevity as the active use of a smart contract over
a long period of time. However, even for traditional long-
living software systems this period of time is not precisely
defined [9]. As smart contracts are a comparably young
technology we cannot consider the long period of usage in
terms of decades like e. g. the software used by financial
institutes. For this reason, the goal is to study whether the
current usage of smart contracts indicates a potential use
similar to traditional long-living software.

To study the usage and longevity of smart contracts we
analyzed the Ethereum blockchain between its creation in mid
2015 and end of October 2019 (in total 1,555 days) using
the data provided by Blockchair [8]. All in all, this time
frame covers the creation of 2,988,133 smart contracts of
which 1,048,835 smart contracts have been called at least once.
606,821 smart contracts have been called more than once. For
the following discussion, we excluded the smart contracts that
have never been called.

To answer the question whether smart contracts are long-
living, we calculated the lifespan of each contract created by
determining the time between the creation of the contract on
the blockchain and its last execution.

In Fig. 3 we plotted how many smart contracts have been
deployed that reach a certain lifespan (measured in days). We
can see that many smart contracts are used immediately after

Fig. 3. Lifespan of smart contracts

Fig. 4. Amount of contracts that have been redeployed x times

creation and get inactive after a few days. The majority of
smart contracts has a lifespan between a couple and about 800
days. Nevertheless, there are still many smart contracts with a
lifespan higher than 800 days up to being alive for nearly the
entire time frame considered. Those smart contracts might be
considered as long-living.

Also smart contracts which have been used for a short
period of time could be considered as long-living if they
are deployed multiple times, distributed over a longer period
of time. For this reason, we counted how often exactly the
same code is redeployed to the block chain. In fact, the
2,988,133 smart contract creations considered only contain
596,229 different smart contract implementations. From these,
45,107 implementations have been deployed more than once
with exactly the same code. In Fig. 4 we show the number of
smart contracts with multiple redeployments.

Due to the young age of the Ethereum blockchain the figures
presented are heavily biased by recently created contracts that



Fig. 5. Relation between date of contract creation and lifespan of the contract

can not yet be considered as long-living. This gets even worse
due to the increase of contract creations per month as shown in
Fig. 1. To get a feeling about the distribution of the contracts
lifespan in relation to the date of their creation, we plotted
the lifespan of contacts in relation to the date of their creation
in Fig. 5. Early after the release of the Ethereum (at x=0)
a few long-living and some only short living smart contracts
have been created. For later creation dates more and more
long smart contacts with higher lifespans are created. It is
interesting that there are points of time where large amounts
of short, medium, and long lifespans have been created. The
two most obvious ones are after 200 and 600 days.

In summary, compared to the lifetime of the Ethereum
blockchain, a significant amount of smart contracts deployed
to the Ethereum blockchain can be considered as long-living
within the Ethereum ecosystem. However, in relation to time
frames traditionally considered for long-living software sys-
tems, it has to be observed if the future lifespan and usage pat-
terns of smart contracts converge to the general understanding
of long-living software systems. Regarding this, our findings
indicate that smart-contracts might become long-living. For
long-living smart contracts, we have to evaluate blockchain
characteristics colliding with smart contract maintenance.

B. Update Patterns

If a blockchain is used for smart contract deployment and
distribution, a smart contract can neither be updated nor
deleted once it is deployed. However, most systems need
to provide update functionality e. g. to deal with changing
environments. This holds especially for long-living systems
which, according to the previous subsection, smart contracts
can be.

We discovered two main patterns used to update smart
contracts on the Ethereum blockchain

a) Redeployment: The simplest update pattern is the
creation of a new smart contract where all changes are applied.
Here, we have to distinguish between smart contracts that are

created for single-use, and smart contracts which can be used
multiple times with a single deployment.

Deployment per use. In this case the recreation of the smart
contract is part of the concept and allows to maintain the smart
contracts code in between the single uses. While for smart
contracts without changes a simple comparison of the byte
code of an existing contract known to behave as expected
is enough the updated contract has to be checked in detail.
However, the same mechanism can be applied here as for a
smart contract where no version known to be secure exists.

Single deployment. It is possible to implement smart con-
tract with some kind of session management to enable the use
for multiple parallel sessions. Once the address of the smart
contract is publicly known, users can be certain to commu-
nicate with the same smart contract on each interaction. The
redeployment of such a smart contract, which will technically
result in a new smart contract with a new address, raises the
issue of distributing the new address since the fixed address
is part of the contract usage design.

One approach to tackle this issue are centralized places
for the exchange of the current address for a specific smart
contract. E.g. this can be smart contract market places, the
website of the contract deployer, or a client software used for
the execution of the smart contract. Each of these solution
contains some kind of Single-Point-of-Failure.

To avoid the usage of the old deprecated smart contract
the deployer has to revoke the old one. This step might not be
executed by the deployer due to various reasons, like expecting
too high cost for the self destruct or due of laziness. If this
self destruct does not happen or is not possible, e.g. because
required authentication data has been lost, users unaware of
the new smart contract might continue using the old one
containing bugs or security issues.

b) Proxy Smart Contracts: A pattern frequently used is
to deploy a pair of smart contracts where one of the contracts
functions as a proxy for the other smart contract. The proxy
contract has a changeable variable containing the address of
the actual smart contract doing the work. Whenever a newer
smart contract version is released, the value of this variable is
updated. If the proxy is called, it calls the newest version of the
smart contract that has been released. While this pattern seems
to behave very well in practice, it violates the assumption that
every time the same address is called with the same input, the
smart contract at this address behaves the same.

As there is currently no update mechanism that provides a
trust-free redirect to the new smart contract, updates should
be only performed for security critical changes and should be
well documented.

C. Challenges and Future Work

Based on the previous discussions we identified challenges
that should be tackled in the future. The overall challenge
is how to tackle the maintenance problem of long-living
smart contracts. To deal with this challenge, we identified the
subchallenges present in the following.



While we have already been able to extract much informa-
tion from the Ethereum blockchain there are still more things
to be studied in detail.

At first, we have to provide a more precise definition of
a long-living smart contract. In this work, we only discussed
informally, based on quantitative data, if there exist long-living
smart contracts on the Ethereum blockchain. A more formal
definition would allow to explicitly select the long-living smart
contracts and to study them in depth.

Second, we need more detailed information on the versions
of long-living smart contracts. In this work, we searched for
smart contracts that have been redeployed without changes.
However, we expect many contracts to be redeployed with
small changes, reflecting an iterative development process. The
challenge is to detect and analyze them. I.e., we have to study
which changes have been made between different versions of a
smart contract. This can allow us to get a deeper understanding
of the reasons for maintenance and allow us to reduce the
amount of redeployments by developing best practices and
tool support for reducing the probability for errors.

Extracting usage patterns from the smart contracts and
studying their pros and cons is a first step for applying mature
software engineering to smart contracts. While there is already
some work on this issue, the challenge is still to get a deeper
understanding of good patterns for smart contracts. Also these
usage patterns should be compared to the usage patterns of
traditional software with the aim of a knowledge transfer.

Another challenge is to search and identify more update pat-
terns and to quantify their usage. While we already identified
two update patterns there might be more that we are currently
not aware of. The open question is if we will find always
the same patterns to be used frequently or a larger variety
of update patterns. Again, a deeper understanding on update
patterns for smart contracts will increase the understanding on
how smart contracts are deployed and developed. Furthermore,
there are well-proven update patterns in traditional, non-
blockchain software systems. It has to be checked if these
patterns could be applied to smart contracts stored on a
blockchain. Particular attention should be payed to software
systems providing the possibility to be updated while being
handle long-running transactions.

In general, one has to follow the Ethereum community
discussions to learn in which direction smart contracts will
evolve and which concepts should get part, e.g. of Ethereum,
to allow maintenance of smart contracts. One solution to
ease the maintenance of smart contracts could be to allow
the specification of additional information when executing
a selfdestruct, e.g. by adding a pointer which points to the
succeeding version of the smart contract to be destructed.

IV. RELATED WORKS

Besides us also other researchers are studying the usage of
smart contracts. In this section we discuss their works and
relate them to our work.

Chen et al. analyze the Ethereum blockchain for occurrences
of ponzi schemes [10]. For this purpose they utilize a pattern

detection on the contracts available on the Ethereum block
chain. A similar approach could be used by us to detect
versions of contracts.

Bartoletti manually classified contracts published on the
Ethereum blockchain into different categories [11]. Further-
more, they studied which patterns have been implemented in
the contracts, e.g. an authentication.

Parizi et al. studied the effectiveness of open source security
testing tools for smart contracts on ten contracts taken from
the Ethereum blockchain [12]. Effective tools for detecting
issues early and avoiding them can help to also avoid the
issues arising from the need to update already published smart
contracts discussed in this work.

While we discuss update patterns for smart contracts,
Wohrer et al. are discussing security patterns in their
work [13]. They are presenting a collection of patterns de-
scribing solutions to typical issues.

Liu et al. discuss design patterns for smart contracts and
even identified two patterns categorized as creational pat-
terns [14]. Unfortunately, those creational patterns do not
consider maintenance and updates of the contract.

V. CONCLUSION

In this work we conducted an initial study of smart contracts
deployed on the Ethereum blockchain and discussed whether
smart contracts can or should be considered to be long-living
software. We show, that there is a conflict between the idea
of having immutable smart contract code and the need for
updates as part of a software’s life cycle.

Despite lacking a formal definition of long-living smart
contracts, we discovered that a significant amount of smart
contracts could be considered to be long-living. In general,
long-living software needs the capability of updates, e.g. for
adoption to unforeseen changes in the environment. This also
applies for software in blockchain context, like smart contracts.
For the smart contract code itself well known maintenance
principles can be applied. However, we are currently not aware
of e. g. refactoring approaches for smart contracts [15].

More challenging is the secure update of the deployed smart
contracts. While proxy smart contracts seem to work very well
in practice, it might raise the issue of smart contract address
distribution for securely informing clients about an updated
smart contract version. The key principle of an identical
behavior per invocation might be violated by the use of proxy
smart contracts. Unfortunately, for now we can not recommend
a better solution if the contract should stay available under the
same address. However, we see a high need for mechanisms to
update the code of smart contracts. For this reason, we want
to motivate discussions and research to address the conflict
between reliable and and secure smart contract platforms and
the need for updating the smart contract code.

As changes in long-living systems cannot always be pro-
hibited and smart contracts can be long-living systems, smart
contracts platforms should provide transparent ways to update
the code of smart contracts and allow everyone interested in
calling the contract to trace the changes.



In our future work we are going to get a deeper under-
standing on the versioning of smart contracts as well as in
update mechanisms. Based on this understanding we are going
to develop best practices and additional tool support.

REFERENCES

[1] D. L. Parnas, “Software Aging,” in ICSE. IEEE, 1994, pp. 279–287.
[2] S. Peldszus, G. Kulcsár, M. Lochau, and S. Schulze, “Continuous

Detection of Design Flaws in Evolving Object-Oriented Programs using
Incremental Multi-pattern Matching,” in ASE, Sep. 2016.

[3] European Parliament and Council of the European Uninon, “Regulation
(EU) 2016/679 – General Data Protection Regulation (GDPR),” in
Official Journal of the European Union, 2016.

[4] E. Biham and A. Shamir, Differential Cryptanalysis of the Data Encryp-
tion Standard. Springer Science & Business Media, 2012.

[5] G. Wood et al., “Ethereum: A Secure Decentralised Generalised Trans-
action Ledger,” Ethereum Project Yellow Paper, 2014.

[6] C. Cachin, “Architecture of the Hyperledger Blockchain Fabric,” in
DCCL, vol. 310, 2016.

[7] S. Nakamoto et al., “Bitcoin: A Peer-to-peer Electronic Cash System,”
2008.

[8] “Blockchair Database Dumps,” online, https://blockchair.com/dumps,
[accessed Feb 20";"""date"",""2020-02-12T13:51:39Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.5""
""xmp:CreatorTool"",""LaTeX with hyperref""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dcterms:created"",""2020-02-12T13:51:39Z""
""language"",""en""
""Last-Modified"",""2020-02-12T13:51:39Z""
""dcterms:modified"",""2020-02-12T13:51:39Z""
""dc:format"",""application/pdf; version=1.5""
""Last-Save-Date"",""2020-02-12T13:51:39Z""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2020-02-12T13:51:39Z""
""meta:save-date"",""2020-02-12T13:51:39Z""
""pdf:encrypted"",""false""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.20 (TeX Live 2019/Debian) kpathsea version 6.3.1""
""modified"",""2020-02-12T13:51:39Z""
""Content-Length"",""247506""
""pdf:hasMarkedContent"",""false""
""Content-Type"",""application/pdf""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.20 (TeX Live 2019/Debian) kpathsea version 6.3.1""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""meta:creation-date"",""2020-02-12T13:51:39Z""
""created"",""2020-02-12T13:51:39Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""7""
""Creation-Date"",""2020-02-12T13:51:39Z""
""resourceName"",""4517694554c8c9e10491f932baf1f081.pdf""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""4668"",""3802"",""4717"",""3522"",""4365"",""5260"",""1910""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""producer"",""pdfTeX-1.40.20""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""pdfTeX-1.40.20""
""pdf:docinfo:created"",""2020-02-12T13:51:39Z""
";https://scholar.google.ch/scholar?start=710&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098725-20;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Smart Contracts: From Formal Specification to Blockchain Code;SS Sharifi ;2020 ruor.uottawa.ca;;"Page 1. Smart Contracts: from Formal Specification to Blockchain Code by Seyed Sepehr Sharifi …

That is why the interest in Distributed Ledger Technologies (DLTs), and blockchain in particular,

has recently risen as a cyber platform for tracking systems [17] …";Autres articles;Version HTML;[PDF] uottawa.ca;https://ruor.uottawa.ca/bitstream/10393/40866/3/Sharifi_Seyed_Sepehr_2020_thesis.pdf;"
Smart Contracts: from Formal
Specification to Blockchain Code

by

Seyed Sepehr Sharifi

Thesis submitted to the
Faculty of Engineering

In partial fulfillment of the requirements
For the M.Sc. degree in

Systems Science

School of Electrical Engineering and Computer Science
Faculty of Engineering
University of Ottawa

Š Seyed Sepehr Sharifi, Ottawa, Canada, 2020



Abstract

The combination of the Internet of Things (IoT), a type of Cyber Physical Systems
(CPS), with Distributed Ledger Technology (DLT) platforms, also known as blockchains,
provides an unprecedented opportunity for automating smart contracts that monitor the
execution of legal contracts to ensure compliance. The absence of formalization of smart
contracts based on recognized legal notions may however result in uncertainty during con-
tract monitoring. The need for formal smart contract specifications, together with refine-
ments and transformations to DLT implementations (code), is undeniable and urgent.

This thesis, following a Design Science Research methodology, aims to partially address
this need by developing a formal contract specification language called Symboleo, and
selecting the suitable target language for generating smart contract code from Symboleo
specifications.

This thesis contributes a syntax and axiomatic semantics for Symboleo, with concepts
rooted in a legal ontology, and supported by an editor. It also provides an analysis of
possible target smart contract programming languages. These artifacts are evaluated with
a comprehensive example of sales of perishable goods, with positive results.

ii



Acknowledgements

This work was partially funded by an NSERC Strategic Partnership Grant titled “Mid-
dleware Framework and Programming Infrastructure for IoT Services”, SSHRC’s Part-
nership Grant “Autonomy Through Cyberjustice Technologies”, the Ontario Graduate
Scholarship (OGS) program, the University of Ottawa Faculty of Engineering Excellence
Award, and the Mitacs Accelerate Program.

I am grateful to my co-supervisors Prof. John Mylopoulos and Prof. Daniel Amyot
for their omnipresent wisdom and guidance. I certainly have learned much more than
modelling from them. I would like to also thank Prof. Luigi Logrippo whose support and
advice was available since the beginning of the project. My work has been highly affected
by my colleague Alireza Parvizimosaed which resulted in many shared contributions.

I would like to also thank E. Jonchères, V. Callipel, D. Restrepo Amariles, P. Bacquero,
F. Gélinas, G. Sileno, T. van Engers, and T. van Binsbergen (lawyers and professors from
the Autonomy Through Cyberjustice Technologies project) for their feedback on Symboleo
and guidance on subcontracting.

I would like to also acknowledge Patrick McLaughlin’s guidance, friendship and feedback
that helped me greatly, and also his support through Brane that made the Mitacs internship
possible.

Finally, I would like to thank Tristan Paul, Jeremy Fang, Andrew Rizk and Sukhraj
Bhogal for their review of the work and their feedback.

iii



Dedication

This work is mainly dedicated to the love of my life, Anahita. Her warm love and
support has helped me pull through the cold and chilly winters of Ottawa, and through
the darkness that lurks at every corner. I could not ask for a better companion.

This work is also dedicated to my parents, Hamid and Minoo, and my sister, Saba, who
have been there for me for as long as I can remember.

iv



Table of Contents

List of Tables ix

List of Figures x

List of Listings xi

Glossary of Acronyms xii

1 Introduction 1

1.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.1.1 Cyber-Physical Systems . . . . . . . . . . . . . . . . . . . . . . . . 1

1.1.2 Distributed-Ledger Technologies . . . . . . . . . . . . . . . . . . . . 3

1.1.3 Smart Contracts . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.2 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.3 Thesis Objectives and Research Questions . . . . . . . . . . . . . . . . . . 5

1.4 Research Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.4.1 DSR’s Conceptual Framework . . . . . . . . . . . . . . . . . . . . . 6

1.4.2 Artifacts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

1.4.3 Relevance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

1.4.4 Research Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

1.4.5 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

1.5 Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

1.6 Publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

1.7 Thesis Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

v



2 Literature Review 12

2.1 Fundamental Legal Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.2 Legal Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.3 Contract Law & Lifecycle . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.3.1 Formation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.3.2 Interpretation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.3.3 Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.4 Contract Ontologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2.5 Formal Models of Contracts . . . . . . . . . . . . . . . . . . . . . . . . . . 22

2.5.1 Formal Contract Language (FCL) . . . . . . . . . . . . . . . . . . . 23

2.5.2 Unifying Legal Smart Contract Modeling (Ladleif & Weske) . . . . 24

2.5.3 Time-Aware Commitments Modelling and Monitoring Framework
(Chesani et al.) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

2.5.4 Business Contract Language (BCL) . . . . . . . . . . . . . . . . . . 25

2.5.5 Defeasible Contract Machines (DCMs) . . . . . . . . . . . . . . . . 25

2.5.6 RuleML and OASIS LegalRuleML . . . . . . . . . . . . . . . . . . . 26

2.5.7 MODELLER (Daskalopulu and Sergot) . . . . . . . . . . . . . . . . 26

2.5.8 A Logic Model of Contracts (Lee) . . . . . . . . . . . . . . . . . . . 27

2.5.9 Contract Language CL (Prisacariu and Schneider) . . . . . . . . . . 27

2.5.10 PENELOPE (Goedertier and Vanthienen) . . . . . . . . . . . . . . 27

2.5.11 SCIFF (Alberti et al.) . . . . . . . . . . . . . . . . . . . . . . . . . 28

2.5.12 A Comparison of Formal Contract Models . . . . . . . . . . . . . . 28

3 An Event-based Formal Model of Contracts 32

3.1 A Contract Ontology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

3.2 Formal Baseline of the Language . . . . . . . . . . . . . . . . . . . . . . . 35

3.2.1 Contract Specification . . . . . . . . . . . . . . . . . . . . . . . . . 35

3.2.2 Domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

3.2.3 Contract Signature . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

3.2.4 Contract Body . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

3.2.5 Declarations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

3.2.6 Preconditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

3.2.7 Postconditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

vi



3.2.8 Obligations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

3.2.9 Surviving Obligations . . . . . . . . . . . . . . . . . . . . . . . . . . 39

3.2.10 Powers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

3.2.11 Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

3.3 Finite State Machines of Contract, Obligation, and Power Instances . . . . 40

3.4 Execution-time Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

4 Symboleo: Syntax and Semantics 43

4.1 Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

4.1.1 EBNF Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

4.1.2 Xtext Implementation . . . . . . . . . . . . . . . . . . . . . . . . . 45

4.2 Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

4.3 Execution-time Operations: Primitives, Syntax, and Semantics . . . . . . . 53

4.3.1 Primitive Execution-time Labels . . . . . . . . . . . . . . . . . . . . 53

4.3.2 Primitive Execution-time Operations . . . . . . . . . . . . . . . . . 54

4.3.3 Assignment, Substitution, and Subcontracting . . . . . . . . . . . . 55

4.3.4 Case Study: Multiple Freights Contracts as Subcontracts . . . . . . 57

5 From Symboleo to Smart Contract Code 60

5.1 Criteria for Selecting and Evaluating Smart Contract Languages . . . . . . 60

5.2 On Enforceable Smart Contracts . . . . . . . . . . . . . . . . . . . . . . . 62

5.2.1 Challenges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

5.2.2 Ricadian Contracts . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

5.2.3 A Hybrid Approach to Realizing Enforceable Smart Contracts . . . 64

5.3 Smart Contract Languages . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

5.3.1 Solidity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

5.3.2 DAML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

5.3.3 Accord Project’s Ergo . . . . . . . . . . . . . . . . . . . . . . . . . 72

5.4 Comparison and Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

6 Conclusion 78

6.1 Summary of Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

6.2 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

6.3 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

vii



APPENDICES 83

A Axiomatic Semantics of Symboleo 84

A.1 Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

A.2 Semantics of Obligations and Powers . . . . . . . . . . . . . . . . . . . . . 84

A.2.1 Contract is In Effect . . . . . . . . . . . . . . . . . . . . . . . . . . 85

A.2.2 Contract is in an Unsuccessful Termination Situation . . . . . . . . 88

A.2.3 Contract is in a Suspension Situation . . . . . . . . . . . . . . . . . 88

A.3 Semantics of Contracts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

B Axiomatic Semantics of Remaining Primitive Execution-time Operations 91

References 93

viii



List of Tables

1.1 Seven DSR guidelines [39] . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.1 Hohfeldian jural correlatives . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.2 Hohfeldian jural opposites . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.3 Comparison criteria for formal contract models and languages . . . . . . . 29

2.4 Comparison of formal contract languages . . . . . . . . . . . . . . . . . . 30

3.1 Sample clauses of a meat sales contract . . . . . . . . . . . . . . . . . . . . 36

3.2 Meat sales contract protocol . . . . . . . . . . . . . . . . . . . . . . . . . 37

4.1 EBNF syntax of Symboleo . . . . . . . . . . . . . . . . . . . . . . . . . . 44

4.2 Primitive predicates of Symboleo . . . . . . . . . . . . . . . . . . . . . . . 52

4.3 Primitive execution-time labels of Symboleo . . . . . . . . . . . . . . . . . 53

4.4 Primitive execution-time operations . . . . . . . . . . . . . . . . . . . . . . 55

4.5 Freight contract template example . . . . . . . . . . . . . . . . . . . . . . . 58

4.6 Freight contract specification in Symboleo . . . . . . . . . . . . . . . . . . 59

5.1 List of comparison criteria for smart contract languages . . . . . . . . . . 76

5.2 Comparison of high-level smart contract languages . . . . . . . . . . . . . 77

6.1 Research questions and their answers as thesis contributions . . . . . . . . 79

6.2 Symboleo’s line for the comparison of formal contract languages in Table 2.4 79

A.1 Glossary of terms for the axiom definitions . . . . . . . . . . . . . . . . . 84

ix



List of Figures

1.1 Average costs of industrial IoT sensors from 2004 to 2020 (in USD) [82]. . 2

1.2 Simplified schematic of a smart contract. Note that as a CPS, a smart
contract contains the blockchain smart contract code, the distributed ledger
platform, and interfaces with the environment, which involve IoT sensors/ac-
tuators but also humans. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.3 DSRM based on [69] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.1 Fragment of the UFO-L ontology (from [9]). . . . . . . . . . . . . . . . . . 21

2.2 Interplay of legal states with actions (illustration by and from [50]). . . . . 24

3.1 Proposed contract ontology . . . . . . . . . . . . . . . . . . . . . . . . . . 34

3.2 FSMs of the contract, obligation, and power concepts . . . . . . . . . . . . 41

4.1 Screenshot of the domain model of Table 3.2 implemented in Symboleo IDE
(generated by Xtext) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

4.2 Screenshot of the body of the contract in Table 3.2 implemented in Symboleo
IDE (generated by Xtext) . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

5.1 BowTie diagram of Ricardian contract elements & generatives. By Artied
- Own work, CC BY-SA 4.0, https://commons.wikimedia.org/w/index.
php?curid=50058729 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

x

https://commons.wikimedia.org/w/index.php?curid=50058729
https://commons.wikimedia.org/w/index.php?curid=50058729


List of Listings

4.1 Grammar of Symboleo implemented in Xtext . . . . . . . . . . . . . . . . . 49

5.1 An example of a micropayment contract in Solidity [81] . . . . . . . . . . . 68

5.2 Structure of a Template in DAML . . . . . . . . . . . . . . . . . . . . . . . 70

5.3 Structure of a Choice in DAML . . . . . . . . . . . . . . . . . . . . . . . . 70

5.4 An example of a payment contract in DAML . . . . . . . . . . . . . . . . . 72

5.5 An example of a contract data model in Concerto (part of the Accord project) 74

5.6 An example of a payment upon delivery contract in Ergo . . . . . . . . . . 75

xi



Glossary of Acronyms

ACT Autonomy through Cyberjustice Technologies

AHP Analytic Hierarchy Process

AST Abstract Syntax Tree

BCL Business Contract Language

CCQ Civil Code of Quebec

CISG United Nations Convention on Contracts for International Sale of Goods

CLO Core Legal Ontology

CPS Cyber-Physical System

CTD Contrary to Duty

CTL Computational Tree Logic

CWM Contract Workflow Model

DCM Defeasible Contract Machine

DLT Distributed Ledger Technology

DOI Document Object Identifier

DOLCE Descriptive Ontology for Linguistic and Cognitive Engineering

DSL Domain-Specific Language

DSR Design Science Research

DSRM Design Science Research Methodology

EBNF Extended Backus-Naur Form

ECA Event-Condition-Action

FCL Formal Contract Language

xii



FOL First-Order Logic

FSM Finite-State Machine

IDE Integrated Development Environment

IoT Internet of Things

IS Information System

ITU-T International Telecommunication Union - Telecommunication
Standardization Sector

LTL Linear Temporal Logic

MTCO Multi-Tier Contract Ontology

NDL Normative Defeasible Logic

OWL Web Ontology Language

RE Requirements Engineering

RQ Research Question

SDL Standard Deontic Logic

UCC Uniform Commercial Code

UFO Unified Foundational Ontology

UFO-L Unified Foundational Ontology – Legal

UML Unified Modeling Notation

UNCITRAL United Nations Commission on International Trade Law

USD United States Dollars

XML eXtensible Markup Language

xiii



Chapter 1

Introduction

This thesis aims to develop a software engineering framework for building smart contracts.
These are software systems that monitor and control the execution of a legal contract. The
framework includes a formal specification language for legal contracts, as well as finding
a pathway towards a tool-supported process for generating smart contract code from a
contract specification.

This chapter describes the context of the problem and presents essential background on
the major elements involved in this research. Then, the motivation for the thesis’ research
and its resulting research objective and questions are explained. This chapter also describes
the selected methodology, based on Design Science Research (DSR), the research process
and resulting artifacts, and how the latter are evaluated.

1.1 Background

Due to the multidisciplinary and novel nature of this research, a brief overview of important
background concepts involved in the research is presented.

1.1.1 Cyber-Physical Systems

A Cyber-Physical System (CPS) is a system of systems that consists of interconnected phys-
ical assets with computational capabilities [51]. CPSs are the result of integrating physical
processes with computation [52]. They can be minuscule, such as a smart drug delivery
system, or extremely large, such as a Global Positioning System satellite constellation.
Distinguishing characteristics of CPSs include their connectivity, scalability, adaptability,
and automation [41].

These systems have become more prominent as:

• Internet is now pervasive;

1



• Cloud computing relieved users from having computational resources of their own;
and

• The cost of sensors has diminished drastically in the last decades, as shown in Fig.1.1.

Figure 1.1: Average costs of industrial IoT sensors from 2004 to 2020 (in USD) [82].

The Internet of Things (IoT) is a type of CPS whose elements, in particular sensors
and actuators, are interconnected via the Internet. The International Telecommunication
Union defines IoT as follows [44]:

“A global infrastructure for the information society, enabling advanced services by in-
terconnecting (physical and virtual) things based on existing and evolving interoperable
information and communication technologies.”

IoT systems provide numerous capabilities that are most relevant for monitoring and
asset tracking, which in turn are important for assessing compliance to many types of
contracts.

2



1.1.2 Distributed-Ledger Technologies

Even though one can track and monitor assets in order to assess contract compliance, one
still must ensure the integrity of contract execution data. That is why the interest in
Distributed Ledger Technologies (DLTs), and blockchain in particular, has recently risen
as a cyber platform for tracking systems [17].

The first viral version of DLTs, Bitcoin, was introduced by Satoshi Nakamoto (a
pseudonym) in [62]. The main principle has two key components: 1) cryptography and
2) a consensus mechanism for data integrity.

The cryptography element is implemented via the following mechanism. Each transac-
tion is encrypted on the database using a hashing mechanism. The resulting block has a
public key and a private key held by the owner of the block. The hash signature can be
used to verify the chain of ownership of the block of data by other users if they have the
public key of the owner of the block. The next block of data uses the hash identifier of the
previous data and uses the current data to produce the following block [62]. The encrypted
blocks are chained through such hashing mechanism, hence the name blockchain.

The second element, the consensus mechanism, ensures that the number of transactions
per amount of time is constant. If the number of transactions increases, the difficulty of
the hashing problem that users must solve to create the block soars. The other part of the
mechanism ensures that every user connected to the chain has the same copy of the ledger.
In other words, the parts that do not match the ledgers of more than 50% of the users will
be replaced with those of the majority [62].

The generations of DLTs that followed Bitcoin allowed users to write programs on
the platform, also known as smart contracts. These blocks of code allow users to write
programs that run on a blockchain platform, while ensuring the immutability of these
programs. Prominent examples of the new generation of DLT platforms include Ethereum1

and Hyperledger Fabric2.

Note that the concept of smart contract used in this thesis is different from what smart
contracts in DLT platforms often mean. The former is defined as a legal contract that is
monitored by a CPS/IoT system while the latter is defined as a block of code that runs on
a blockchain platform. Smart legal contracts do not necessarily rely on blockchain (even
though they can benefit from the data immutability offered by blockchain technologies).

Current generations of DLTs can be categorized as permissioned or permission-less.
Permissioned DLTs allow businesses to have more control over their network of partici-
pating nodes, which makes it desirable for business applications.

By employing cryptographic security measures and consensus algorithms (e.g., proof of
work, proof of stake, Byzantine Fault Tolerant algorithms), DLT systems can ensure the
integrity of the recorded data on the shared ledger3. This feature renders DLT systems

1https://ethereum.org/
2https://www.hyperledger.org/projects/fabric
3Note that there are various DLT architectures that would not be able to completely ensure the integrity

of recorded data without assuming some percentage of trusted participants. In other words, only completely
decentralized DLT systems have a very high tolerance to malicious actors.

3

https://ethereum.org/
https://www.hyperledger.org/projects/fabric


suitable for recording terms and data that could be later the subject of judicial arbitration.
Judges and juries should be able to trust that the data recorded on the DLT system was
not tampered with. Aside from being tamper-resistant, DLT systems also offers ways
of making tampering attempts traceable and evident to the actors involved in the DLT
system.

There have also been many integrations between IoT sensors/actuators and DLT sys-
tems, creating a hybrid infrastructure that enables smart contracts [16,17,20] by gathering
data from the environment, processing it, and recording it on a tamper-resistant shared
ledger.

1.1.3 Smart Contracts

Business transactions are conducted within the guidelines of a legal contract. In large
supply chains, a myriad of contracts is often being executed. Large-scale enterprises have
a plethora of contracts with distributors, brokers, suppliers, producers, and consumers.
The combination of IoT with DLT platforms provides an unprecedented capability in au-
tomating legal contract monitoring, especially for supply chain provenance (see Fig. 1.2).
Sensors and messages from contract execution parties record the events that constitute a
legal contract execution on an immutable distributed ledger, which guarantees data in-
tegrity and can be referenced as evidence in legal disputes [17]. IoT-based smart contracts
will enable corporations to keep track of assets and of the state of the contracts with re-
spect to their contracting parties, and even take some remedial actions automatically in
some situations [16].

1.2 Motivation

The competitive nature of companies has encouraged them to utilize high-end technologies
more than ever [52]. Smart contracts, as presented in the previous section, are very in-
teresting to businesses, especially to the ones that have a complex and large supply chain
(i.e., many contracts and sub-contracts) to monitor. Currently, companies do not have
a scalable and efficient way of monitoring contracts. Smart contracts themselves cannot
easily be validated against legal contracts. As a result, it is not possible to ensure that
smart contract monitoring reflects the terms and conditions (intended behavior) of the
legal contract.

Furthermore, many design processes targeting CPSs such as the one in Fig. 1.2 lack
clear connections between the physical and cyber parts. Although it is intuitive that the
decisions made for each part will affect the other part and hence the total outcome, it
is not obvious how the design processes actually interact. To illustrate how the designs
of cyber and physical components affect each other, take the example of monitoring the
temperature condition of perishable goods being transported. How is the code, which
monitors the conditions set forth in the contract, developed if the layout of the sensors is not
determined? There are also challenges in the other direction. For instance, computing and

4



Figure 1.2: Simplified schematic of a smart contract. Note that as a CPS, a smart contract
contains the blockchain smart contract code, the distributed ledger platform, and interfaces
with the environment, which involve IoT sensors/actuators but also humans.

networking decisions have physical implications, e.g., power sources, networking modules,
etc. that consume physical space.

1.3 Thesis Objectives and Research Questions

The long-term vision of this research is to develop a software engineering framework for
building smart contracts.

As a step towards this vision, this thesis aims to explore i) the development of a
formal specification language for contracts, as well as ii) the development of a path towards
systematic, tool-supported process for refining such specifications into smart contract code.

Note that is it first important to determine how the legal contract domain is concep-
tually captured in a specification language. Moreover, the necessary elements that are to
be added to an abstract contract specification must be investigated as it is refined towards
concrete implementations and eventually meets the physical domain.

5



These objectives are further refined into the following research questions:

RQ-1: How can a legal contract be formally specified?
RQ-1.1: What are the fundamental concepts involved in a contract?
RQ-1.2: What are the life cycles of the fundamental concepts involved in a contract?

RQ-2: How can a smart legal contract specification be used to support DLT code gener-
ation?

The research on formal specification of contracts (RQ-1) has been done collaboratively
as a team, of which the thesis author is the main contributor. The answer to RQ-2 is solely
the work of the thesis author.

1.4 Research Methodology

The research methodology followed in this thesis is strongly inspired by the Design Science
Research (DSR) in Information Science (IS) methodology, which was first introduced by
Hevner et al. [39]. DSR simultaneously considers social and design aspects involved in the
field of information science, but also in other fields of engineering and computer science.

This section first presents the conceptual framework of DSR followed by its instantiation
to the specific needs of this thesis.

1.4.1 DSR’s Conceptual Framework

The DSR methodology targets the field of IS with the purpose of designing and evaluating
artifacts to solve a problem. It addresses the intricacy of the research that is being done
in the field of IS, since it has both a social (natural) science and a design science element
to it. In short, DSR addresses the field that utilizes design as a means of research and is
different from pure design science. Hevner et al. [39] introduced three main cycles that
exist in a DSR approach:

• Relevance cycle: ensures that the research addresses a viable business need and that
the results are applicable to the domain.

• Rigor cycle: ensures that the research has proper theoretical foundations from the
knowledge base and that the results will be added to it.

• Design cycle: the process of conducting the research for developing and evaluating
the artifacts. Note that the results of the evaluation will be fed back to the design
phase, which completes the design cycle.

The seven DSR guidelines are summarized in Table 1.1. The thesis follows these guide-
lines to augment the likelihood of producing valuable and viable results by the end of the
research.

6



Table 1.1: Seven DSR guidelines [39]

Guideline Description
G1: Design an artifact DSR must produce a viable artifact in the form of a

construct, a model, a method, or an instantiation.
G2: Problem relevance The objective of DSR is to develop technology-

based solutions to important and relevant business
problems.

G3: Design evaluation The utility, quality, and efficacy of a design artifact
must be rigorously demonstrated via well-executed
evaluation methods.

G4: Research
contributions

Effective DSR must provide clear and verifiable
contributions in the areas of the design artifact,
design foundations, and/or design methodologies.

G5: Research rigor Design science research relies upon the application
of rigorous methods in both the construction and
evaluation of the design artifact.

G6: Design as a search
process

The search for an effective artifact requires uti-
lizing available means to reach desired ends while
satisfying laws in the problem environment.

G7: Communication of
research

DSR must be presented effectively both to
technology-oriented as well as management-
oriented audiences.

1.4.2 Artifacts

This thesis contributes artifacts of different DSR types, according to guideline G1 in Ta-
ble 1.1:

• Constructs: a ontology of contractual concepts (e.g., obligations, powers, and assets)
that builds on earlier proposals. Additionally, the concept primitive execution-time
operations is defined.

• Models: Symboleo4, a formal specification language for contracts which at its core
contains a contract ontology that extends an existing legal ontology with the above
constructs, as well as state models for the concepts of contracts, obligations, and
powers.

• Method: a technology comparison in the format of a decision analysis that provides
the comparison criteria for target smart contract programming languages to generate
smart contract programs from Symboleo contract specifications.

• Tool: an editor for Symboleo

4From the Greek word Συµβoλαιo, which means contract.

7



1.4.3 Relevance

Part of the problem relevance was motivated in Section 1.2, according to guideline G2 in
Table 1.1. Further evidence of relevance was provided through collaboration with industrial
and research partners:

• In Canada and Europe, through being involved in the Autonomy through Cyberjus-
tice Technologies (ACT) project (sub-project 4 – Smart Contracts and Regulation
Technologies5), with collaborations in Montréal, Paris, and Bruxelles.

• In France, where a global leader in digital transformation participating to the above
ACT project has shared sample contracts and is interested in using the thesis artefacts
for specifying, verifying, and monitoring their thousands of legal contracts involving
sub-contractors.

• In Canada, where companies involved in the emerging transactive energy markets
have also shared legal contracts and smart contracts studied in this thesis. They
consider using the thesis artefacts for specifying, verifying, and monitoring their
contracts as well.

• A standardization effort led by the British Standard Institution (BSI) is focused on
developing a standard for the specification of smart legal contracts6 that shows the
general interest of the industry towards widespread use of smart contracts.

1.4.4 Research Process

To ensure research rigor and approach design as a search process (guidelines G5 and G6
in Table 1.1), a research methodology, with a problem centered research entry point, was
adapted from Design Science Research Methodology (DSRM) [69].

Figure 1.3, the DSRM process model, illustrates the research steps and feedback. The
problem was defined in Section 1.2, while Section 1.3 describes the objectives of the solu-
tion. The design process started with a study of the legal domain (Contract Law) to create
a contract taxonomy. During this process, some experience with actual smart contracts
was gained and the knowledge influenced the definition of contractual elements. Further-
more, the creation of simple smart contract programs provided a glimpse into what the
solution should look like. A contract domain model was developed (captured in the form
of an ontology), along with the finite state machines of the main contractual elements.
The syntax of the specification language was implemented in Xtext to create a text editor.
A sample contract (based on real contracts) was specified in Symboleo to demonstrate
the created artifacts. The artifacts were then evaluated via the means mentioned in Sec-
tion 1.4.5. The results of this research were communicated to the scientific community via
various publications, as listed in Section 1.6.

5https://www.ajcact.org/en/
6https://standardsdevelopment.bsigroup.com/projects/2018-03267

8

htt";"""date"",""2020-08-19T17:25:42Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2020-08-19T17:25:42Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""Sepehr Sharifi""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.19 (TeX Live 2018) kpathsea version 6.3.0""
""meta:author"",""Sepehr Sharifi""
""trapped"",""False""
""meta:creation-date"",""2020-08-19T17:25:42Z""
""created"",""2020-08-19T17:25:42Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-08-19T17:25:42Z""
""resourceName"",""Sharifi_Seyed_Sepehr_2020_thesis.pdf""
""Author"",""Sepehr Sharifi""
""producer"",""pdfTeX-1.40.19""
""pdf:docinfo:producer"",""pdfTeX-1.40.19""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""12"",""62"",""0"",""0"",""0"",""0"",""0"",""0"",""2"",""0"",""0"",""0"",""0"",""0"",""4"",""262"",""24"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""3"",""0"",""0"",""0"",""4"",""13"",""2"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""13"",""15"",""0"",""4"",""0"",""0"",""0"",""0"",""0"",""4"",""8"",""4"",""0"",""9"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""Sepehr Sharifi""
""dcterms:created"",""2020-08-19T17:25:42Z""
""Last-Modified"",""2020-08-19T17:25:42Z""
""dcterms:modified"",""2020-08-19T17:25:42Z""
""title"",""""
""Last-Save-Date"",""2020-08-19T17:25:42Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2020-08-19T17:25:42Z""
""meta:save-date"",""2020-08-19T17:25:42Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.19 (TeX Live 2018) kpathsea version 6.3.0""
""Content-Length"",""3356359""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Sepehr Sharifi""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""112""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""303"",""1058"",""1229"",""325"",""858"",""1631"",""1588"",""452"",""1084"",""1017"",""425"",""637"",""582"",""1343"",""744"",""2786"",""2476"",""974"",""1897"",""1696"",""2303"",""1124"",""1822"",""283"",""1703"",""2332"",""2742"",""2133"",""2100"",""2236"",""2113"",""2494"",""2494"",""997"",""2721"",""1734"",""1800"",""2478"",""2652"",""2272"",""2154"",""2135"",""1745"",""1696"",""1680"",""2606"",""778"",""2376"",""1612"",""1998"",""1666"",""1868"",""2428"",""971"",""2735"",""1551"",""1880"",""1731"",""904"",""1405"",""1146"",""1292"",""1465"",""518"",""1742"",""1911"",""1860"",""2181"",""2230"",""2802"",""2405"",""1349"",""1581"",""2035"",""1762"",""2151"",""2144"",""537"",""2636"",""1547"",""1526"",""1902"",""2115"",""1807"",""2310"",""2209"",""1764"",""2287"",""2549"",""1597"",""1238"",""1832"",""2108"",""2951"",""1573"",""12"",""692"",""1645"",""1929"",""1696"",""1780"",""2033"",""762"",""1217"",""429"",""1635"",""2318"",""2213"",""2247"",""2021"",""1992"",""1621""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-08-19T17:25:42Z""
";https://scholar.google.ch/scholar?start=560&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098720-2;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Flexible Threshold Ring Signature in Chronological Order for Privacy Protection in Edge Computing;Z Wang, J Fan ; IEEE Transactions on Cloud Computing, 2020  ieeexplore.ieee.org;;"… cre- ate a d-out-of-n threshold ring signature for the transaction added into the blockchain … There

are three oracles in the security model of a FTRSCO scheme, which define the ability of … Joining

Oracle(JO): On request that a new user is added to the system, this oracle returns an …";Autres articles;;null;;;;
1619098725-11;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Technical Communication in Videos on the Example of Blockchain;M Rodler ;2020 repositum.tuwien.at;;"??| | |fOffa ||CS Technical Communication in Videos on the Example of the Technology

Blockchain D|PLOMA THESIS submitted in partial fulfillment of the requirements for the degree

of Diplom-Ingenieurin in Media and Human-Centered Computing by Marion Rodler, BSc …";;;[PDF] tuwien.at;https://repositum.tuwien.at/bitstream/20.500.12708/15622/2/Rodler%20Marion%20-%202020%20-%20Technical%20Communication%20in%20Videos%20on%20the%20Example%20of...pdf;"
D
ie

 a
pp

ro
bi

er
te

 g
ed

ru
ck

te
 O

rig
in

al
ve

rs
io

n 
di

es
er

 D
ip

lo
m

ar
be

it 
is

t a
n 

de
r 

T
U

 W
ie

n 
B

ib
lio

th
ek

 v
er

fĂź
gb

ar
.

T
he

 a
pp

ro
ve

d 
or

ig
in

al
 v

er
si

on
 o

f t
hi

s 
th

es
is

 is
 a

va
ila

bl
e 

in
 p

rin
t a

t T
U

 W
ie

n 
B

ib
lio

th
ek

.
D

ie
 a

pp
ro

bi
er

te
 g

ed
ru

ck
te

 O
rig

in
al

ve
rs

io
n 

di
es

er
 D

ip
lo

m
ar

be
it 

is
t a

n 
de

r 
T

U
 W

ie
n 

B
ib

lio
th

ek
 v

er
fĂź

gb
ar

.
T

he
 a

pp
ro

ve
d 

or
ig

in
al

 v
er

si
on

 o
f t

hi
s 

th
es

is
 is

 a
va

ila
bl

e 
in

 p
rin

t a
t T

U
 W

ie
n 

B
ib

lio
th

ek
.

D
ie

 a
pp

ro
bi

er
te

 g
ed

ru
ck

te
 O

rig
in

al
ve

rs
io

n 
di

es
er

 D
ip

lo
m

ar
be

it 
is

t a
n 

de
r 

T
U

 W
ie

n 
B

ib
lio

th
ek

 v
er

fĂź
gb

ar
.

T
he

 a
pp

ro
ve

d 
or

ig
in

al
 v

er
si

on
 o

f t
hi

s 
th

es
is

 is
 a

va
ila

bl
e 

in
 p

rin
t a

t T
U

 W
ie

n 
B

ib
lio

th
ek

.

Technical Communication in
Videos on the Example of the

Technology Blockchain

DIPLOMA THESIS

submitted in partial fulfillment of the requirements for the degree of

Diplom-Ingenieurin

in

Media and Human-Centered Computing

by

Marion Rodler, BSc

Registration Number 01246786

to the Faculty of Informatics

at the TU Wien

Advisor: A.o. Univ. Prof. Dr. Dipl.-Ing. Eva KĂźhn

Assistance: Dipl.-Ing. Peter Fikar, Bakk.techn.

Vienna, 28th July, 2020

Marion Rodler Eva KĂźhn

Technische Universität Wien

A-1040 Wien Karlsplatz 13 Tel. +43-1-58801-0 www.tuwien.at

https://www.tuwien.at/bibliothek
https://www.tuwien.at/bibliothek
https://www.tuwien.at/bibliothek


D
ie

 a
pp

ro
bi

er
te

 g
ed

ru
ck

te
 O

rig
in

al
ve

rs
io

n 
di

es
er

 D
ip

lo
m

ar
be

it 
is

t a
n 

de
r 

T
U

 W
ie

n 
B

ib
lio

th
ek

 v
er

fĂź
gb

ar
.

T
he

 a
pp

ro
ve

d 
or

ig
in

al
 v

er
si

on
 o

f t
hi

s 
th

es
is

 is
 a

va
ila

bl
e 

in
 p

rin
t a

t T
U

 W
ie

n 
B

ib
lio

th
ek

.
D

ie
 a

pp
ro

bi
er

te
 g

ed
ru

ck
te

 O
rig

in
al

ve
rs

io
n 

di
es

er
 D

ip
lo

m
ar

be
it 

is
t a

n 
de

r 
T

U
 W

ie
n 

B
ib

lio
th

ek
 v

er
fĂź

gb
ar

.
T

he
 a

pp
ro

ve
d 

or
ig

in
al

 v
er

si
on

 o
f t

hi
s 

th
es

is
 is

 a
va

ila
bl

e 
in

 p
rin

t a
t T

U
 W

ie
n 

B
ib

lio
th

ek
.

https://www.tuwien.at/bibliothek
https://www.tuwien.at/bibliothek


D
ie

 a
pp

ro
bi

er
te

 g
ed

ru
ck

te
 O

rig
in

al
ve

rs
io

n 
di

es
er

 D
ip

lo
m

ar
be

it 
is

t a
n 

de
r 

T
U

 W
ie

n 
B

ib
lio

th
ek

 v
er

fĂź
gb

ar
.

T
he

 a
pp

ro
ve

d 
or

ig
in

al
 v

er
si

on
 o

f t
hi

s 
th

es
is

 is
 a

va
ila

bl
e 

in
 p

rin
t a

t T
U

 W
ie

n 
B

ib
lio

th
ek

.
D

ie
 a

pp
ro

bi
er

te
 g

ed
ru

ck
te

 O
rig

in
al

ve
rs

io
n 

di
es

er
 D

ip
lo

m
ar

be
it 

is
t a

n 
de

r 
T

U
 W

ie
n 

B
ib

lio
th

ek
 v

er
fĂź

gb
ar

.
T

he
 a

pp
ro

ve
d 

or
ig

in
al

 v
er

si
on

 o
f t

hi
s 

th
es

is
 is

 a
va

ila
bl

e 
in

 p
rin

t a
t T

U
 W

ie
n 

B
ib

lio
th

ek
.

Erklärung zur Verfassung der

Arbeit

Marion Rodler, BSc

Hiermit erkläre ich, dass ich diese Arbeit selbständig verfasst habe, dass ich die verwen-
deten Quellen und Hilfsmittel vollständig angegeben habe und dass ich die Stellen der
Arbeit – einschließlich Tabellen, Karten und Abbildungen –, die anderen Werken oder
dem Internet im Wortlaut oder dem Sinn nach entnommen sind, auf jeden Fall unter
Angabe der Quelle als Entlehnung kenntlich gemacht habe.

Wien, 28. Juli 2020

Marion Rodler

iii

https://www.tuwien.at/bibliothek
https://www.tuwien.at/bibliothek


D
ie

 a
pp

ro
bi

er
te

 g
ed

ru
ck

te
 O

rig
in

al
ve

rs
io

n 
di

es
er

 D
ip

lo
m

ar
be

it 
is

t a
n 

de
r 

T
U

 W
ie

n 
B

ib
lio

th
ek

 v
er

fĂź
gb

ar
.

T
he

 a
pp

ro
ve

d 
or

ig
in

al
 v

er
si

on
 o

f t
hi

s 
th

es
is

 is
 a

va
ila

bl
e 

in
 p

rin
t a

t T
U

 W
ie

n 
B

ib
lio

th
ek

.
D

ie
 a

pp
ro

bi
er

te
 g

ed
ru

ck
te

 O
rig

in
al

ve
rs

io
n 

di
es

er
 D

ip
lo

m
ar

be
it 

is
t a

n 
de

r 
T

U
 W

ie
n 

B
ib

lio
th

ek
 v

er
fĂź

gb
ar

.
T

he
 a

pp
ro

ve
d 

or
ig

in
al

 v
er

si
on

 o
f t

hi
s 

th
es

is
 is

 a
va

ila
bl

e 
in

 p
rin

t a
t T

U
 W

ie
n 

B
ib

lio
th

ek
.

https://www.tuwien.at/bibliothek
https://www.tuwien.at/bibliothek


D
ie

 a
pp

ro
bi

er
te

 g
ed

ru
ck

te
 O

rig
in

al
ve

rs
io

n 
di

es
er

 D
ip

lo
m

ar
be

it 
is

t a
n 

de
r 

T
U

 W
ie

n 
B

ib
lio

th
ek

 v
er

fĂź
gb

ar
.

T
he

 a
pp

ro
ve

d 
or

ig
in

al
 v

er
si

on
 o

f t
hi

s 
th

es
is

 is
 a

va
ila

bl
e 

in
 p

rin
t a

t T
U

 W
ie

n 
B

ib
lio

th
ek

.
D

ie
 a

pp
ro

bi
er

te
 g

ed
ru

ck
te

 O
rig

in
al

ve
rs

io
n 

di
es

er
 D

ip
lo

m
ar

be
it 

is
t a

n 
de

r 
T

U
 W

ie
n 

B
ib

lio
th

ek
 v

er
fĂź

gb
ar

.
T

he
 a

pp
ro

ve
d 

or
ig

in
al

 v
er

si
on

 o
f t

hi
s 

th
es

is
 is

 a
va

ila
bl

e 
in

 p
rin

t a
t T

U
 W

ie
n 

B
ib

lio
th

ek
.

Danksagung

Hier ist für mich die passende Stelle, ein Säckchen voll “Danke” auszuteilen.

Eines geht davon an meine Betreuerin Prof. Eva KĂźhn, Geri und Martina, mit denen
ich unzählige spannende Meetings fßhren durfte. Danke an Peter Fikar, der durch sein
Wissen auf dem Gebiet der qualitativen Forschung einige große Steine aus dem Weg
räumte und mir immer wieder weiterhalf.
Ein Danke geht an die Studenten der Lehrveranstaltung “VU Forschungsmethoden” aus
dem Wintersemester 2019, die durch ihre Leistungen zur Bereicherung dieser Thesis
beitrugen. Danke auch an die Experten, die sich extra die Zeit nahmen und so interessante
Statements beitrugen. Danke an alle Studienteilnehmer, insbesondere Monte und Jun,
vor allem weil sie erwähnt werden wollten.

Danke an meine Firma, die Manzler, die mich immer unterstĂźtzen, und mir eigene
Visitenkarten als Anreiz zum Abschluss in Aussicht stellten. Insbesondere mĂśchte ich
Peter und Alex erwähnen, die mir immer mit einem offenen Ohr und sehr viel Verständnis
und Flexibilität entgegenkamen.

Ein großes Danke an alle meine lieben Freunde, die mich ablenkten, wenn ich es nötig
hatte und sich immer wieder zum Korrekturlesen und fĂźr Feedbackrunden aufopferten.
Besonders bedanken mĂśchte ich mich bei meiner lieben Studienkollegin und Freundin
Kristina, ohne die das Masterstudium um einiges mĂźhsamer und sehr viel weniger lustig
gewesen wäre. Danke auch fßr die vielen Meetings, deine Eselsgeduld und das super
Feedback während der Diplomarbeitsphase.

Danke an meine Familie und besonders an meine zwei Strizis. Mit euch spielen macht am
meisten Spaß.

Danke an meine Eltern, fĂźr seelischen Beistand und die ganze Aufheiterungsmarterei und
die grenzenlose UnterstĂźtzung. Ihr seits so unglaublich lieb zu mir, das hab ich gar nicht
verdient.

Das letzte Danke mĂśchte ich mich meinem Mitbewohner geben. Sein Rappername ist
Schwaighof Louis, bekannt durch die Debütsingle ‘Straight outta Schwaighof’. Du hast
mich immer wieder motiviert, aufgeheitert, ertragen und so viel Kraft gegeben. Danke
dir.

v

https://www.tuwien.at/bibliothek
https://www.tuwien.at/bibliothek


D
ie

 a
pp

ro
bi

er
te

 g
ed

ru
ck

te
 O

rig
in

al
ve

rs
io

n 
di

es
er

 D
ip

lo
m

ar
be

it 
is

t a
n 

de
r 

T
U

 W
ie

n 
B

ib
lio

th
ek

 v
er

fĂź
gb

ar
.

T
he

 a
pp

ro
ve

d 
or

ig
in

al
 v

er
si

on
 o

f t
hi

s 
th

es
is

 is
 a

va
ila

bl
e 

in
 p

rin
t a

t T
U

 W
ie

n 
B

ib
lio

th
ek

.
D

ie
 a

pp
ro

bi
er

te
 g

ed
ru

ck
te

 O
rig

in
al

ve
rs

io
n 

di
es

er
 D

ip
lo

m
ar

be
it 

is
t a

n 
de

r 
T

U
 W

ie
n 

B
ib

lio
th

ek
 v

er
fĂź

gb
ar

.
T

he
 a

pp
ro

ve
d 

or
ig

in
al

 v
er

si
on

 o
f t

hi
s 

th
es

is
 is

 a
va

ila
bl

e 
in

 p
rin

t a
t T

U
 W

ie
n 

B
ib

lio
th

ek
.

https://www.tuwien.at/bibliothek
https://www.tuwien.at/bibliothek


D
ie

 a
pp

ro
bi

er
te

 g
ed

ru
ck

te
 O

rig
in

al
ve

rs
io

n 
di

es
er

 D
ip

lo
m

ar
be

it 
is

t a
n 

de
r 

T
U

 W
ie

n 
B

ib
lio

th
ek

 v
er

fĂź
gb

ar
.

T
he

 a
pp

ro
ve

d 
or

ig
in

al
 v

er
si

on
 o

f t
hi

s 
th

es
is

 is
 a

va
ila

bl
e 

in
 p

rin
t a

t T
U

 W
ie

n 
B

ib
lio

th
ek

.
D

ie
 a

pp
ro

bi
er

te
 g

ed
ru

ck
te

 O
rig

in
al

ve
rs

io
n 

di
es

er
 D

ip
lo

m
ar

be
it 

is
t a

n 
de

r 
T

U
 W

ie
n 

B
ib

lio
th

ek
 v

er
fĂź

gb
ar

.
T

he
 a

pp
ro

ve
d 

or
ig

in
al

 v
er

si
on

 o
f t

hi
s 

th
es

is
 is

 a
va

ila
bl

e 
in

 p
rin

t a
t T

U
 W

ie
n 

B
ib

lio
th

ek
.

Acknowledgements

This is the right place for me to hand out a bag full of “thank yous”.

One of them goes to my supervisor Prof. Eva KĂźhn and of course to Geri and Martina,
with whom I have had countless exciting meetings. Thanks to Peter Fikar, who, with his
knowledge in the field of qualitative research, put some big stones out of the way and
helped me again and again.
A thanks goes to the students of the course “VU Research Methods” from the winter
semester 2019, who contributed to the enrichment of this thesis with their efforts. Thanks
also to the experts who took the time to contribute interesting statements.

Thanks to all participants of the study, especially Monte and Jun, because they wanted
to be mentioned.

Thanks to my company, who always support me, and to the promised business cards
they gave me as an incentive to graduate. In particular I would like to mention Peter
and Alex, who always approached me with an open ear and a lot of flexibility.

A big thank you to all a dear friends, who distracted me when I needed it and always
sacrificed themselves for proofreading and feedback rounds. I would especially like to
thank my dear fellow student Kristina, without whom the Master’s degree would have
been much more tedious and much less fun. Thanks also for the many meetings, your
donkey patience and the great feedback during the thesis phase.

Thanks to my family and especially to my two strizis. Playing with you is the most fun.

Thanks also to my parents, for emotional and boundless support and all the cheering up.
You guys have been so incredibly kind to me.

The last thanks I would like to give to my favourite stone. His rapper name is Schwaighof
Louis, he became famous with the debut single ‘Straight outta Schwaighof’. You have
always motivated me, cheered me up, put up with me and given me so much strength.
Thank you.

vii

https://www.tuwien.at/bibliothek
https://www.tuwien.at/bibliothek


D
ie

 a
pp

ro
bi

er
te

 g
ed

ru
ck

te
 O

rig
in

al
ve

rs
io

n 
di

es
er

 D
ip

lo
m

ar
be

it 
is

t a
n 

de
r 

T
U

 W
ie

n 
B

ib
lio

th
ek

 v
er

fĂź
gb

ar
.

T
he

 a
pp

ro
ve

d 
or

ig
in

al
 v

er
si

on
 o

f t
hi

s 
th

es
is

 is
 a

va
ila

bl
e 

in
 p

rin
t a

t T
U

 W
ie

n 
B

ib
lio

th
ek

.
D

ie
 a

pp
ro

bi
er

te
 g

ed
ru

ck
te

 O
rig

in
al

ve
rs

io
n 

di
es

er
 D

ip
lo

m
ar

be
it 

is
t a

n 
de

r 
T

U
 W

ie
n 

B
ib

lio
th

ek
 v

er
fĂź

gb
ar

.
T

he
 a

pp
ro

ve
d 

or
ig

in
al

 v
er

si
on

 o
f t

hi
s 

th
es

is
 is

 a
va

ila
bl

e 
in

 p
rin

t a
t T

U
 W

ie
n 

B
ib

lio
th

ek
.

https://www.tuwien.at/bibliothek
https://www.tuwien.at/bibliothek


D
ie

 a
pp

ro
bi

er
te

 g
ed

ru
ck

te
 O

rig
in

al
ve

rs
io

n 
di

es
er

 D
ip

lo
m

ar
be

it 
is

t a
n 

de
r 

T
U

 W
ie

n 
B

ib
lio

th
ek

 v
er

fĂź
gb

ar
.

T
he

 a
pp

ro
ve

d 
or

ig
in

al
 v

er
si

on
 o

f t
hi

s 
th

es
is

 is
 a

va
ila

bl
e 

in
 p

rin
t a

t T
U

 W
ie

n 
B

ib
lio

th
ek

.
D

ie
 a

pp
ro

bi
er

te
 g

ed
ru

ck
te

 O
rig

in
al

ve
rs

io
n 

di
es

er
 D

ip
lo

m
ar

be
it 

is
t a

n 
de

r 
T

U
 W

ie
n 

B
ib

lio
th

ek
 v

er
fĂź

gb
ar

.
T

he
 a

pp
ro

ve
d 

or
ig

in
al

 v
er

si
on

 o
f t

hi
s 

th
es

is
 is

 a
va

ila
bl

e 
in

 p
rin

t a
t T

U
 W

ie
n 

B
ib

lio
th

ek
.

Kurzfassung

Diese Thesis erforscht mittels der Beispieltechnologie Blockchain, wie technische Themen
in Videos kommuniziert werden. Die Problemstellung dahinter ist, dass es sehr viele
Erklärvideos zu Blockchain gibt, doch ist schwer ßberprßfbar inwieweit diese Videos
verständlich fßr die Zuschauer sind. Dadurch entsteht die Vermutung, dass Viewer die
Technologie nur halb oder falsch verstehen kĂśnnten. Um herauszufinden, wie diesen
Problemen begegnet werden kann, wurden die folgenden Forschungsfragen untersucht:
Welche Metaphern und welche stilistischen Mittel funktionieren am besten, um die
präsentierten Konzepte zu verstehen und was sind die Charakteristika von Videos, die
einfach zu verstehen sind?

Es wurde folgender Mixed-Method-Ansatz angewandt: Nach einer Literaturrecherche
wurden jene Erklärvideos der Technologie Blockchain aus diversen Videoplattformen
analysiert, die festgelegten Kriterien entsprachen. Darauf folgte die erste User Studie mit
StudentInnen der TU Wien. Der nächste Schritt waren zwei Experteninterviews. Es wurde
diskutiert, wie die Experten die Technologie an andere vermitteln und welche Metaphern
sie dafür einsetzen. Abschließend wurden zwei weitere User Studien durchgeführt. Bei
der zweiten User Studie lag das Hauptaugenmerk auf den Präsentationsmitteln in Videos
während die dritte User Studie vorrangig auf die Erklärmethoden fokussierte.

Der erste Teil der Ergebnisse sind die Charakteristika der evaluierten Videos. Diese
Charakteristika wurden in drei Kategorien aufgeteilt: Die Adaption an die Zielgruppe,
die stilistischen Mittel und das Gesamtkonzept. Abgeleitet aus diesen Charakteristika
werden Guidelines fßr das Design von Erklärvideos. Die Guidelines listeten die Anpassung
auf eine definierte Zielgruppe, die stilistischen Mittel und beinhalten wichtige Punkte
auf der Inhaltsebene, die in den Studien als positiv wahrgenommen wurden. Weiters
werden die Metaphern, die aus den verschiedenen angewandten Methoden resultierten,
aufgelistet. Diese waren besonders verständlich fßr die StudienteilnehmerInnen, werden
laut den Experten gut verstanden oder wurden häufig in den evaluierten Videos erwähnt.

ix

https://www.tuwien.at/bibliothek
https://www.tuwien.at/bibliothek


D
ie

 a
pp

ro
bi

er
te

 g
ed

ru
ck

te
 O

rig
in

al
ve

rs
io

n 
di

es
er

 D
ip

lo
m

ar
be

it 
is

t a
n 

de
r 

T
U

 W
ie

n 
B

ib
lio

th
ek

 v
er

fĂź
gb

ar
.

T
he

 a
pp

ro
ve

d 
or

ig
in

al
 v

er
si

on
 o

f t
hi

s 
th

es
is

 is
 a

va
ila

bl
e 

in
 p

rin
t a

t T
U

 W
ie

n 
B

ib
lio

th
ek

.
D

ie
 a

pp
ro

bi
er

te
 g

ed
ru

ck
te

 O
rig

in
al

ve
rs

io
n 

di
es

er
 D

ip
lo

m
ar

be
it 

is
t a

n 
de

r 
T

U
 W

ie
n 

B
ib

lio
th

ek
 v

er
fĂź

gb
ar

.
T

he
 a

pp
ro

ve
d 

or
ig

in
al

 v
er

si
on

 o
f t

hi
s 

th
es

is
 is

 a
va

ila
bl

e 
in

 p
rin

t a
t T

U
 W

ie
n 

B
ib

lio
th

ek
.

https://www.tuwien.at/bibliothek
https://www.tuwien.at/bibliothek


D
ie

 a
pp

ro
bi

er
te

 g
ed

ru
ck

te
 O

rig
in

al
ve

rs
io

n 
di

es
er

 D
ip

lo
m

ar
be

it 
is

t a
n 

de
r 

T
U

 W
ie

n 
B

ib
lio

th
ek

 v
er

fĂź
gb

ar
.

T
he

 a
pp

ro
ve

d 
or

ig
in

al
 v

er
si

on
 o

f t
hi

s 
th

es
is

 is
 a

va
ila

bl
e 

in
 p

rin
t a

t T
U

 W
ie

n 
B

ib
lio

th
ek

.
D

ie
 a

pp
ro

bi
er

te
 g

ed
ru

ck
te

 O
rig

in
al

ve
rs

io
n 

di
es

er
 D

ip
lo

m
ar

be
it 

is
t a

n 
de

r 
T

U
 W

ie
n 

B
ib

lio
th

ek
 v

er
fĂź

gb
ar

.
T

he
 a

pp
ro

ve
d 

or
ig

in
al

 v
er

si
on

 o
f t

hi
s 

th
es

is
 is

 a
va

ila
bl

e 
in

 p
rin

t a
t T

U
 W

ie
n 

B
ib

lio
th

ek
.

Abstract

This thesis explores how technical themes are communicated in videos using blockchain
technology as an example. The problem behind this is that there are many explanatory
videos about blockchain, but it is difficult to check to what extent these videos are
understandable for the viewers. This has led to the assumption that the viewers of these
videos can only understand some aspects of the technology or understand it incorrectly.
To ascertain how these problems can be addressed the following research questions were
examined: Which metaphors and stylistic means work best to understand the presented
concepts and what are the characteristics of the videos that are perceived as easily
understandable?

The following mixed-method approach was applied: Following a literature review, the
explanatory blockchain technology videos from various video platforms that met the
defined criteria were analysed. This was followed by the first user study conducted
with students from a technical university. The next step consisted of two interviews
with experts in the field of blockchain technology. The experts talked about how they
communicate the technology to others and what metaphors they use to do so. Finally,
two more user studies were conducted. In the second user study, the focus was on the
presentation tools utilised in the videos. The third user study requested that the study
participants primarily pay attention to the explanatory methods.

The first part of the results are the characteristics of the evaluated videos. These
characteristics were divided into three categories: The adaptation to the target group, the
stylistic means and the overall concept. Guidelines for the design of explanatory videos
are derived from these characteristics. Furthermore, the metaphors resulting from the
different methods used are listed. These were particularly understandable for the study
participants, are well understood according to the experts or were frequently mentioned
in the evaluated videos.

xi

https://www.tuwien.at/bibliothek
https://www.tuwien.at/bibliothek


D
ie

 a
pp

ro
bi

er
te

 g
ed

ru
ck

te
 O

rig
in

al
ve

rs
io

n 
di

es
er

 D
ip

lo
m

ar
be

it 
is

t a
n 

de
r 

T
U

 W
ie

n 
B

ib
lio

th
ek

 v
er

fĂź
gb

ar
.

T
he

 a
pp

ro
ve

d 
or

ig
in

al
 v

er
si

on
 o

f t
hi

s 
th

es
is

 is
 a

va
ila

bl
e 

in
 p

rin
t a

t T
U

 W
ie

n 
B

ib
lio

th
ek

.
D

ie
 a

pp
ro

bi
er

te
 g

ed
ru

ck
te

 O
rig

in
al

ve
rs

io
n 

di
es

er
 D

ip
lo

m
ar

be
it 

is
t a

n 
de

r 
T

U
 W

ie
n 

B
ib

lio
th

ek
 v

er
fĂź

gb
ar

.
T

he
 a

pp
ro

ve
d 

or
ig

in
al

 v
er

si
on

 o
f t

hi
s 

th
es

is
 is

 a
va

ila
bl

e 
in

 p
rin

t a
t T

U
 W

ie
n 

B
ib

lio
th

ek
.

https://www.tuwien.at/bibliothek
https://www.tuwien.at/bibliothek


D
ie

 a
pp

ro
bi

er
te

 g
ed

ru
ck

te
 O

rig
in

al
ve

rs
io

n 
di

es
er

 D
ip

lo
m

ar
be

it 
is

t a
n 

de
r 

T
U

 W
ie

n 
B

ib
lio

th
ek

 v
er

fĂź
gb

ar
.

T
he

 a
pp

ro
ve

d 
or

ig
in

al
 v

er
si

on
 o

f t
hi

s 
th

es
is

 is
 a

va
ila

bl
e 

in
 p

rin
t a

t T
U

 W
ie

n 
B

ib
lio

th
ek

.
D

ie
 a

pp
ro

bi
er

te
 g

ed
ru

ck
te

 O
rig

in
al

ve
rs

io
n 

di
es

er
 D

ip
lo

m
ar

be
it 

is
t a

n 
de

r 
T

U
 W

ie
n 

B
ib

lio
th

ek
 v

er
fĂź

gb
ar

.
T

he
 a

pp
ro

ve
d 

or
ig

in
al

 v
er

si
on

 o
f t

hi
s 

th
es

is
 is

 a
va

ila
bl

e 
in

 p
rin

t a
t T

U
 W

ie
n 

B
ib

lio
th

ek
.

Contents

Kurzfassung ix

Abstract xi

1 Introduction 1

1.1 Motivation & Problem Statement . . . . . . . . . . . . . . . . . . . . . . 1

1.2 Relevance of the Topic . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.3 Aim of the Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.4 Structure of the Work . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

I Theoretical Foundation 5

2 Research Approach 7

2.1 Quantitative Research . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.2 Qualitative Research . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.3 Mixed Method Approach . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.4 Thematic Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.5 User Research Methods . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3 Background Information 17

3.1 Metaphors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.2 Technical Communication . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.3 Explanatory Videos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.4 Blockchain Basics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

4 Related Work 23

4.1 Video Analysis Criteria . . . . . . . . . . . . . . . . . . . . . . . . . . 23

4.2 Knowledge Transfer in Videos . . . . . . . . . . . . . . . . . . . . . . . 25

4.3 Technical Communication . . . . . . . . . . . . . . . . . . . . . . . . . 26

4.4 Estimating Trustworthiness in Videos . . . . . . . . . . . . . . . . . . 27

4.5 Guidelines for Designing a “Good” Video . . . . . . . . . . . . . . . . 27

4.6 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

xiii

https://www.tuwien.at/bibliothek
https://www.tuwien.at/bibliothek


D
ie

 a
pp

ro
bi

er
te

 g
ed

ru
ck

te
 O

rig
in

al
ve

rs
io

n 
di

es
er

 D
ip

lo
m

ar
be

it 
is

t a
n 

de
r 

T
U

 W
ie

n 
B

ib
lio

th
ek

 v
er

fĂź
gb

ar
.

T
he

 a
pp

ro
ve

d 
or

ig
in

al
 v

er
si

on
 o

f t
hi

s 
th

es
is

 is
 a

va
ila

bl
e 

in
 p

rin
t a

t T
U

 W
ie

n 
B

ib
lio

th
ek

.
D

ie
 a

pp
ro

bi
er

te
 g

ed
ru

ck
te

 O
rig

in
al

ve
rs

io
n 

di
es

er
 D

ip
lo

m
ar

be
it 

is
t a

n 
de

r 
T

U
 W

ie
n 

B
ib

lio
th

ek
 v

er
fĂź

gb
ar

.
T

he
 a

pp
ro

ve
d 

or
ig

in
al

 v
er

si
on

 o
f t

hi
s 

th
es

is
 is

 a
va

ila
bl

e 
in

 p
rin

t a
t T

U
 W

ie
n 

B
ib

lio
th

ek
.

II Applied User Research Methods 31

5 Methodological Approach 33

5.1 Ethics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

5.2 Data Collection and Analysis Tools . . . . . . . . . . . . . . . . . . . . 35

6 User Study 1: Student Project 37

6.1 Part 1: video analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

6.2 Part 2: Producing a Video . . . . . . . . . . . . . . . . . . . . . . . . . . 41

6.3 Results of the Focus Groups . . . . . . . . . . . . . . . . . . . . . . . . 43

6.4 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

7 Video Analysis 45

7.1 Set-Up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

7.2 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

7.3 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

8 Expert Interviews 59

8.1 Set-Up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

8.2 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

8.3 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

9 User Studies 2 and 3 67

9.1 Exploratory Interviews . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

9.2 User Study 2: Watching Videos . . . . . . . . . . . . . . . . . . . . . . 73

9.3 User Study 3: Explaining Blockchain . . . . . . . . . . . . . . . . . . . . 91

9.4 Common Results of User Study 2 and User Study 3 . . . . . . . . . . 109

9.5 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122

IIIDiscussion and Conclusion 123

10 Discussion 125

10.1 Characteristics of easily understandable Videos . . . . . . . . . . . . . 127

10.2 Guidelines for the design of an Explanatory Video . . . . . . . . . . . 133

10.3 Metaphors to understand Presented Concepts . . . . . . . . . . . . . . 135

11 Conclusion 137

11.1 Limitations & Future Work . . . . . . . . . . . . . . . . . . . . . . . . 138

A Submitted Blockchain Videos 141

B User Study 2 143

B.1 Guide for the Exploratory Interviews . . . . . . . . . . . . . . . . . . . 143

B.2 Notes from the Exploratory Interviews . . . . . . . . . . . . . . . . . . 144

https://www.tuwien.at/bibliothek
https://www.tuwien.at/bibliothek


D
ie

 a
pp

ro
bi

er
te

 g
ed

ru
ck

te
 O

rig
in

al
ve

rs
io

n 
di

es
er

 D
ip

lo
m

ar
be

it 
is

t a
n 

de
r 

T
U

 W
ie

n 
B

ib
lio

th
ek

 v
er

fĂź
gb

ar
.

T
he

 a
pp

ro
ve

d 
or

ig
in

al
 v

er
si

on
 o

f t
hi

s 
th

es
is

 is
 a

va
ila

bl
e 

in
 p

rin
t a

t T
U

 W
ie

n 
B

ib
lio

th
ek

.
D

ie
 a

pp
ro

bi
er

te
 g

ed
ru

ck
te

 O
rig

in
al

ve
rs

io
n 

di
es

er
 D

ip
lo

m
ar

be
it 

is
t a

n 
de

r 
T

U
 W

ie
n 

B
ib

lio
th

ek
 v

er
fĂź

gb
ar

.
T

he
 a

pp
ro

ve
d 

or
ig

in
al

 v
er

si
on

 o
f t

hi
s 

th
es

is
 is

 a
va

ila
bl

e 
in

 p
rin

t a
t T

U
 W

ie
n 

B
ib

lio
th

ek
.

B.3 Pre-Study Questionnaire . . . . . . . . . . . . . . . . . . . . . . . . . . 144
B.4 Watching Videos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
B.5 Closing Interview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146

List of Acronyms 147

List of Figures 149

List of Tables 151

Bibliography 153

https://www.tuwien.at/bibliothek
https://www.tuwien.at/bibliothek


D
ie

 a
pp

ro
bi

er
te

 g
ed

ru
ck

te
 O

rig
in

al
ve

rs
io

n 
di

es
er

 D
ip

lo
m

ar
be

it 
is

t a
n 

de
r 

T
U

 W
ie

n 
B

ib
lio

th
ek

 v
er

fĂź
gb

ar
.

T
he

 a
pp

ro
ve

d 
or

ig
in

al
 v

er
si

on
 o

f t
hi

s 
th

es
is

 is
 a

va
ila

bl
e 

in
 p

rin
t a

t T
U

 W
ie

n 
B

ib
lio

th
ek

.
D

ie
 a

pp
ro

bi
er

te
 g

ed
ru

ck
te

 O
rig

in
al

ve
rs

io
n 

di
es

er
 D

ip
lo

m
ar

be
it 

is
t a

n 
de

r 
T

U
 W

ie
n 

B
ib

lio
th

ek
 v

er
fĂź

gb
ar

.
T

he
 a

pp
ro

ve
d 

or
ig

in
al

 v
er

si
on

 o
f t

hi
s 

th
es

is
 is

 a
va

ila
bl

e 
in

 p
rin

t a
t T

U
 W

ie
n 

B
ib

lio
th

ek
.

https://www.tuwien.at/bibliothek
https://www.tuwien.at/bibliothek


D
ie

 a
pp

ro
bi

er
te

 g
ed

ru
ck

te
 O

rig
in

al
ve

rs
io

n 
di

es
er

 D
ip

lo
m

ar
be

it 
is

t a
n 

de
r 

T
U

 W
ie

n 
B

ib
lio

th
ek

 v
er

fĂź
gb

ar
.

T
he

 a
pp

ro
ve

d 
or

ig
in

al
 v

er
si

on
 o

f t
hi

s 
th

es
is

 is
 a

va
ila

bl
e 

in
 p

rin
t a

t T
U

 W
ie

n 
B

ib
lio

th
ek

.
D

ie
 a

pp
ro

bi
er

te
 g

ed
ru

ck
te

 O
rig

in
al

ve
rs

io
n 

di
es

er
 D

ip
lo

m
ar

be
it 

is
t a

n 
de

r 
T

U
 W

ie
n 

B
ib

lio
th

ek
 v

er
fĂź

gb
ar

.
T

he
 a

pp
ro

ve
d 

or
ig

in
al

 v
er

si
on

 o
f t

hi
s 

th
es

is
 is

 a
va

ila
bl

e 
in

 p
rin

t a
t T

U
 W

ie
n 

B
ib

lio
th

ek
.

CHAPTER 1
Introduction

1.1 Motivation & Problem Statement

In today’s information society, the Internet is a daily companion and an indispensable
part of most people’s everyday lives, both professionally and privately. People are used to
having constant access to all available information. Within hours or even minutes one can
acquire at least basic knowledge about a so far unknown topic. A quite common model
of information retrieval is to watch videos about the topic on a video-streaming platform
like YouTube 1, Dailymotion 2, Netflix 3, Amazon Prime Video 4, etc. This often happens
because it is faster and more convenient than reading through various pages, articles or
even scientific publications. While streaming sites like Netflix and Amazon Prime Video
focus on professional generated content (PGC), YouTube has massive amounts of user
generated content (UGC), as the side itself states:

“Over 1.9 billion logged-in users visit YouTube each month and every day
people watch over a billion hours of video and generate billions of views.” [85]

Apart from other positive and negative aspects of UGC, this raises the question of the
validity of the information people obtain. It is possible that unintentionally erroneous
information, possibly even due to the lack of knowledge of the video creator, may be
disseminated. There is also the possibility that false information is deliberately spread to
create a desired response from viewers.

You can publish videos under a real, verified name or under a pseudonym. This means
that you can no longer be sure who is behind a username. False information can be

1https://www.youtube.com, accessed on 10.2.2020
2https://www.dailymotion.com, accessed on 10.2.2020
3https://www.netflix.com, accessed on 10.2.2020
4https://www.amazon.com/video, accessed on 10.2.2020

1

https://www.tuwien.at/bibliothek
https://www.tuwien.at/bibliothek


D
ie

 a
pp

ro
bi

er
te

 g
ed

ru
ck

te
 O

rig
in

al
ve

rs
io

n 
di

es
er

 D
ip

lo
m

ar
be

it 
is

t a
n 

de
r 

T
U

 W
ie

n 
B

ib
lio

th
ek

 v
er

fĂź
gb

ar
.

T
he

 a
pp

ro
ve

d 
or

ig
in

al
 v

er
si

on
 o

f t
hi

s 
th

es
is

 is
 a

va
ila

bl
e 

in
 p

rin
t a

t T
U

 W
ie

n 
B

ib
lio

th
ek

.
D

ie
 a

pp
ro

bi
er

te
 g

ed
ru

ck
te

 O
rig

in
al

ve
rs

io
n 

di
es

er
 D

ip
lo

m
ar

be
it 

is
t a

n 
de

r 
T

U
 W

ie
n 

B
ib

lio
th

ek
 v

er
fĂź

gb
ar

.
T

he
 a

pp
ro

ve
d 

or
ig

in
al

 v
er

si
on

 o
f t

hi
s 

th
es

is
 is

 a
va

ila
bl

e 
in

 p
rin

t a
t T

U
 W

ie
n 

B
ib

lio
th

ek
.

1. Introduction

presented in a valid way so that it appears to be correct. All these positive and negative
effects lead people to believe and to question everything.

In that context, multiple important questions arise: Which metaphors and stylistic means
are used in videos? And which of these tools work best to understand technical concepts?
Under what circumstances can an information be trusted? How does a consumer of video
material determine, if a source has a high quality and is credible?

1.1.1 Selected Use Case: Blockchain Technology

This thesis wants to illustrate the dissemination and understanding of information via
video platforms with a current example. This exemplary topic is the technology of
blockchain, which has been hyped in the last years. When searching on the platform
YouTube for the term “what is blockchain” it results in nearly 8 million videos. One
of the reasons for this hype is the fact that cryptocurrencies that have emerged from
nothing are worth thousands of dollars virtually overnight. Its rise and functionality are
further explained in Chapter 3.4.

An interesting point about this particular technology is that it many have heard about
the technology and that blockchain and Bitcoin are related. But the application areas
and what the technology is actually able to do is often obscure. Therefore, another
crucial point for choosing the technology of blockchain: The hype around the technology
because of the rise and fall of the cryptocurrencies. Especially the prospect of quick, easy
success aroused unrealistic expectations. These expectations often do not correspond to
the actual technical conditions and the potential fields of application.

Because of the features explained in Chapter 3.4 and the relevance of the topic, the
technology which the videos will be about is blockchain. A further point is, that the
topic blockchain is composed of several important technologies. Only by combining these
different technologies does blockchain become the adaptable and secure application it is.

1.2 Relevance of the Topic

Because of the mentioned reasons in Chapter 1.1.1 and the hype around the technology
of blockchain there are many videos out there, which claim to explain the only truth.
But the question arises, if the content which they disseminate is even understood by their
audience? Aside from the comment sections on YouTube and ratings or view counts, it is
hard to determine if the viewers understood and liked the content and the way it was
presented.

The field and mechanisms of YouTube has been the scope of several studies in the last
years. The focus of these studies was mainly the examination of the videos and their
key data as well as the comments of users on the video. There have also been projects,
which aim to categorise technical and science communication and projects, which provide
guidelines for all types of videos after analysing current video material. The author sees

2

https://www.tuwien.at/bibliothek
https://www.tuwien.at/bibliothek


D
ie

 a
pp

ro
bi

er
te

 g
ed

ru
ck

te
 O

rig
in

al
ve

rs
io

n 
di

es
er

 D
ip

lo
m

ar
be

it 
is

t a
n 

de
r 

T
U

 W
ie

n 
B

ib
lio

th
ek

 v
er

fĂź
gb

ar
.

T
he

 a
pp

ro
ve

d 
or

ig
in

al
 v

er
si

on
 o

f t
hi

s 
th

es
is

 is
 a

va
ila

bl
e 

in
 p

rin
t a

t T
U

 W
ie

n 
B

ib
lio

th
ek

.
D

ie
 a

pp
ro

bi
er

te
 g

ed
ru

ck
te

 O
rig

in
al

ve
rs

io
n 

di
es

er
 D

ip
lo

m
ar

be
it 

is
t a

n 
de

r 
T

U
 W

ie
n 

B
ib

lio
th

ek
 v

er
fĂź

gb
ar

.
T

he
 a

pp
ro

ve
d 

or
ig

in
al

 v
er

si
on

 o
f t

hi
s 

th
es

is
 is

 a
va

ila
bl

e 
in

 p
rin

t a
t T

U
 W

ie
n 

B
ib

lio
th

ek
.

1.3. Aim of the Work

a lack of studies, which are observing people watching and un";"""date"",""2020-09-21T17:00:10Z""
""pdf:PDFVersion"",""1.7""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:docinfo:title"",""Technical Communication in Videos on the Example of Blockchain""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""false""
""subject"",""Diplomarbeit""
""language"",""en""
""dc:format"",""application/pdf; version=1.7""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""false""
""pdf:encrypted"",""true""
""dc:title"",""Technical Communication in Videos on the Example of Blockchain""
""xmp:CreateDate"",""2020-09-21T19:00:10Z""
""modified"",""2020-09-21T17:00:10Z""
""cp:subject"",""Diplomarbeit""
""pdf:docinfo:subject"",""Diplomarbeit""
""pdf:hasMarkedContent"",""false""
""xmp:ModifyDate"",""2020-09-21T19:00:10Z""
""pdf:docinfo:creator"",""Marion Rodler""
""meta:author"",""Marion Rodler""
""meta:creation-date"",""2020-09-21T17:00:10Z""
""created"",""2020-09-21T17:00:10Z""
""xmp:About"",""uuid:751f08a4-3448-11f6-0000-e0852971f89f""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-09-21T17:00:10Z""
""resourceName"",""Rodler%20Marion%20-%202020%20-%20Technical%20Communication%20in%20Videos%20on%20the%20Example%20of...pdf""
""Author"",""Marion Rodler""
""producer"",""GPL Ghostscript 9.27""
""pdf:docinfo:producer"",""GPL Ghostscript 9.27""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""dc:description"",""Diplomarbeit""
""Keywords"",""Technical Communication / Video  Analysis / Blockchain"",""Technical Communication / Video  Analysis / Blockchain""
""access_permission:modify_annotations"",""false""
""dc:creator"",""Marion Rodler""
""description"",""Diplomarbeit""
""dcterms:created"",""2020-09-21T17:00:10Z""
""Last-Modified"",""2020-09-21T17:00:10Z""
""dcterms:modified"",""2020-09-21T17:00:10Z""
""title"",""Technical Communication in Videos on the Example of Blockchain""
""xmpMM:DocumentID"",""uuid:751f08a4-3448-11f6-0000-e0852971f89f""
""Last-Save-Date"",""2020-09-21T17:00:10Z""
""pdf:docinfo:keywords"",""Technical Communication / Video  Analysis / Blockchain""
""pdf:docinfo:modified"",""2020-09-21T17:00:10Z""
""meta:save-date"",""2020-09-21T17:00:10Z""
""Content-Length"",""11985845""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Marion Rodler""
""pdf:producer"",""GPL Ghostscript 9.27""
""dc:subject"",""Technical Communication / Video  Analysis / Blockchain"",""Technical Communication / Video  Analysis / Blockchain""
""access_permission:assemble_document"",""false""
""xmpTPg:NPages"",""177""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""1044"",""382"",""798"",""382"",""2119"",""382"",""1910"",""382"",""2261"",""382"",""2087"",""382"",""1472"",""1817"",""601"",""382"",""1921"",""2855"",""2749"",""1240"",""409"",""382"",""1769"",""2677"",""2754"",""2858"",""2834"",""2656"",""2831"",""2667"",""2710"",""3059"",""1742"",""2884"",""2884"",""1955"",""1813"",""382"",""1778"",""3137"",""2976"",""3005"",""3000"",""2133"",""1959"",""382"",""416"",""382"",""1986"",""2850"",""2080"",""970"",""1804"",""2775"",""2376"",""3211"",""2731"",""2841"",""2972"",""1610"",""1869"",""2887"",""2868"",""1910"",""2789"",""2885"",""710"",""2763"",""3072"",""1421"",""3149"",""2948"",""1978"",""382"",""1871"",""2811"",""2227"",""3114"",""3180"",""2863"",""1654"",""382"",""1908"",""2664"",""2663"",""2043"",""1456"",""2962"",""2341"",""2832"",""2290"",""2647"",""2513"",""2945"",""802"",""1952"",""1580"",""3287"",""3364"",""3161"",""3147"",""2935"",""3088"",""2441"",""2057"",""2975"",""2753"",""2259"",""2386"",""2649"",""2157"",""2226"",""3070"",""3243"",""2829"",""2711"",""2448"",""2796"",""2426"",""2679"",""2749"",""3301"",""2923"",""2676"",""2866"",""658"",""3131"",""2179"",""1946"",""1124"",""1183"",""1100"",""1115"",""1030"",""1187"",""1115"",""1132"",""2210"",""415"",""382"",""2089"",""3283"",""3000"",""1530"",""3012"",""3109"",""3112"",""3040"",""3077"",""1866"",""2853"",""1878"",""2210"",""2980"",""561"",""382"",""419"",""469"",""1055"",""744"",""1404"",""1356"",""1453"",""467"",""1766"",""382"",""1299"",""382"",""2032"",""2672"",""2763"",""2575"",""2790"",""2489"",""2564"",""2651"",""1391""
""access_permission:extract_content"",""false""
""access_permission:can_print"",""true""
""meta:keyword"",""Technical Communication / Video  Analysis / Blockchain"",""Technical Communication / Video  Analysis / Blockchain""
""access_permission:can_modify"",""false""
""pdf:docinfo:created"",""2020-09-21T17:00:10Z""
";https://scholar.google.ch/scholar?start=560&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098787-151;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;[PDF][PDF] ?????????? ????????? ??? ???????? ?? ???????? ??????????? ????;C? ????????, ?? ???????, ?? ??????, ?? ?????? ;2020 mipt.ru;;"… Vorobyov S., Yanovich Y. Blockchain-Based Solution to Prevent Postage Stamps Fraud // 2019

IEEE International Conference on Blockchain and Cryptocurrency (ICBC … Kruglik S., Nazirkhanova

K., Yanovich Y. Challenges beyond blockchain: scaling, oracles and privacy …";;;[PDF] mipt.ru;https://mipt.ru/upload/medialibrary/4a1/4_kudryashov_31_39.pdf;"
ТРУДЫ МФТИ. 2020. Том 12, № 4 С.Ю. Кудряшов, С.А. Круглик и др. 31

УДК 004.056

C.Ю. Кудряшов1,2, С.А. Круглик3,4, И.А. Маслов1, Ю.А. Янович3,5

1ООО Битфьюри рус
2Национальный исследовательский университет Высшая школа экономики

3Сколковский институт науки и технологий
4Московский физико-технический институт (национальный исследовательский университет)

5Институт проблем передачи информации им. А.А. Харкевича РАН

Применение блокчейна для контроля за оборотом
пластиковых труб

Представлена архитектура системы по контролю за оборотом пластиковых труб
на основе блокчейна. Приведена бизнес-логика используемого решения, а также его
описание и результаты пилотного внедрения.

Ключевые слова: блокчейн, цепочки поставок, рынок пластиковых труб, доверие,
борьба с контрафактом.

S.Y. Kudryashov1,2, S. A. Kruglik3,4, I. A. Maslov1,3, Y.A. Yanovich3,5

1Bitfury Russia
2National Research University Higher School of Economics

3Skolkovo Institute of Science and Technology
4Moscow Institute of Physics and Technology

5Institute for Information Transmission Problems RAS

On the application of blockchain-based systems to plastic
pipes market

In this paper, we present an architecture of the blockchain-based control system for
plastic pipes market. We give the business logic of the proposed solution as well as its
technical description and the results of pilot implementation.

Key words: blockchain, supply chains, plastic pipes market, trust, fight against
counterfeiting.

1. Введение

Блокчейн – это децентрализованная база данных со встроенными инструментами ауди-
та, в которой все действия с данными отображаются в защищенном от несанкционированно-
го доступа журнале. Корректность процессов внутри блокчейна гарантируется с помощью
криптографических методов, таких как хэш-функции и цифровые подписи. С момента вы-
хода первой блокчейн-сети Bitcoin [1], блокчейн де-факто стал стандартом во многих про-
мышленных приложениях, например, в интернете вещей, автомобильных коммуникациях
нового поколения, умных сетях электроснабжения, электронном здравоохранении, госу-
дарственных реестрах, управлении цепочками поставок [2–11]. Во всех этих приложениях
блокчейн-решения формализуют отношения между различными пользователями матема-
тически, гарантируя необходимый уровень доверия и прозрачности. На рынке существу-
ют различные типы блокчейн-решений, но большинство вышеперечисленных отраслевых
приложений используют приватные блокчейны, реализованные на открытых платформах,

© Кудряшов С.Ю., Круглик С.А., Маслов И.А., Янович Ю.А., 2020
© Федеральное государственное автономное образовательное учреждение высшего образования

«Московский физико-технический институт (национальный исследовательский университет)», 2020



32 Информатика и управление ТРУДЫ МФТИ. 2020. Том 12, № 4

поскольку они могут предложить высокий уровень производительности при сохранении
конфиденциальности пользовательских данных [12].

В данной работе рассматривается применение блокчейна для решения задач управления
цепочками поставок в рамках существующего рабочего процесса рынка пластиковых труб
в России. В работе описаны предпосылки внедрения системы, а также дано техническое
описание системы и показано, что она соответствует прикладным требованиям. Статья
организована следующим образом. В разделе 2 дан краткий обзор рынка пластиковых труб
России. В разделе 3 описана бизнес-логика предлагаемого решения. В разделе 4 приведено
подробное техническое описание блокчейн составляющей решения. Результаты пилотного
внедрения отражены в разделе 5.

2. Обзор рынка пластиковых труб в России

На рынке пластиковых труб существуют четыре вида участников. Приведем краткое
описание каждого из них и упомянем возможные способы фальсификации рабочего про-
цесса (если таковые имеются).

� Производители трубного сырья: производят различные виды пластика для дальней-
шего производства труб. В текущем решении мы не интегрировали их в блокчейн, но это
может быть сделано в следующий версиях. Кроме того, мы предполагаем, что качество
пластика соответствует заявленным характеристикам. Отметим, что в настоящее время в
России существуют только три сертифицированных производителя трубного сырья.

� Производители пластиковых труб: производят различные виды пластиковых труб из
сырья, полученного от производителей. На рынке существует множество производителей
пластиковых труб, и некоторые из них могут использовать более дешевое сырье c целью
увеличения прибыли.

�Монтажники труб: компании, предоставляющие услуги по укладке пластиковых труб.
Эти компании могут использовать трубы от недобросовестных производителей для сниже-
ния общей себестоимости работ в обмен на снижение уровня качества.

� Конечные пользователи: пользователи трубопроводов, такие как строительные ком-
пании или поставщики воды.

Отметим, что в предлагаемом описании дистрибьютеры труб опущены для простоты.
Они являются промежуточным звеном между производителями пластиковых труб и мон-
тажниками труб в цепочке поставок и будут включены в итоговую версию.

По последним статистическим данным, общая стоимость рынка контрафактных и фаль-
сифицированных пластиковых труб составляет около 10 млрд рублей в год [13]. Этот факт
заставляет ведущие компании объединяться в промышленные альянсы. Один из них –
Российская Ассоциация Производителей Трубопроводных систем (АПТС) – рассматрива-
ется в качестве системного администратора в нашем блокчейн-решении [14]. Кроме того, та-
кая доля контрафактной и фальсифицируемой продукции и последствия от ее применения
вызывают интерес контролирующих органов/регуляторов, которые включены в блокчейн-
решение в качестве системных администраторов.

3. Бизнес-логика блокчейн-решения

Для обеспечения необходимого уровня доверия со стороны всех участников рынка,
а также борьбы с контрафактом и фальсификатом предлагаемое решение должно быть
устойчивым к вводу несогласованной информации или изменению существующей в насто-
ящее время информации постфактум, а также обеспечивать необходимый уровень синхро-
низации и управления правами доступа. Последнее, но не менее важное требование заклю-
чается в том, что решение должно быть способно синхронизироваться с существующими
в настоящее время системами учета производителей труб. Централизованные решения не
отвечают всем требованиям одновременно, и современный подход к их решению – это систе-
мы на основе технологи блокчейн. Для поддержания высокой производительности, а также



ТРУДЫ МФТИ. 2020. Том 12, № 4 С.Ю. Кудряшов, С.А. Круглик и др. 33

для обеспечения конфиденциальности пользовательских данных мы используем Exonum –
блокчейн-платформу для построения приватных блокчейнов с открытым исходным кодом.

В системе определено четыре типа организаций в соответствии со структурой рынка
пластиковых труб в России:

� системный администратор,

� производитель труб,

� потребитель,

� производитель сырья.

Монтажники труб и конечные пользователи объединены в одну группу – потребителя-
ми. Роль системного администратора в текущей версии выполняет отраслевая ассоциация
– АПТС.

Каждая организация представлена своими сотрудниками, которые разделены по ролям
и правам:

� администратор,

� принтер для печати меток,

� отгрузчик,

� приемщик,

� установщик,

� полный функционал.

Для регистрации организации пользователь с правами администратора должен принять
приглашение от нее. Также он может удалить организацию из системы и зарегистрировать
других пользователей с разными ролями.

Недобросовестные производители могут отправлять неверные данные в существующие
в настоящее время системы отчетности или вести двойную бухгалтерию. Чтобы исклю-
чить такую возможность, предлагается хранить в блокчейн-базе данных информацию о
сырье и каждой трубе, изготовленной производителем. После изготовления каждая труба
маркируется QR-кодом, содержащим всю информацию о ней, и с баланса производителя
списываем пошедшее на ее просизводство количество пластика. После каждой установки
трубы гасится ее QR-код, чтобы избежать использования труб от несанкционированных
производителей. Труба, помеченная QR-кодом, представлена на рис. 1. Схема процессов в
системе представлена на рис. 2.

Рис. 1. Труба, помеченная QR-кодом



34 Информатика и управление ТРУДЫ МФТИ. 2020. Том 12, № 4

Рис. 2. Схема процессов в системе

4. Техническое описание системы на основе технологии блокчейн

Для реализации системы была выбрана платформа с открытым исходным кодом –
Exonum [15, 16]. Чтобы гарантировать неизменную историю и контроль за использованием
сырья, каждый его сертифицированный производитель сохраняет в блокчейне информа-
цию о каждой партии сырья. После изготовления труб количество пластика соответствую-
щего типа списывается со счета предприятия и присваивается трубе. Это списание фикси-
руется в блокчейн и соответствует уникальному идентрификатору трубы, который записан
в QR-коде. Чтобы гарантировать достоверность информации на всех этапах жизненного
цикла труб с QR-меткой, для каждой из них мы отслеживали временные метки и геотеги,
которые записываются в блокчейн при сканировании метки специализированным мобиль-
ным приложением. В любое время потребители могут проверить, что их трубы соответ-
ствуют требованиям, а системные администраторы могут проверить, что производители
используют только сертифицированные материалы, пересмотрев объем пластика. После
укладки трубы такая информация добавляется в блокчейн и соответствующий QR-код га-
сится, что соответствует выходу трубы из оборота. Это делается для того, чтобы избежать
случаев подделки труб с переиспользованием действительного QR-кода. Стоит отметить,
что это частное блокчейн-решение, в котором системные администраторы поддерживают
всю блокчейн-сеть. А именно, они проверяют транзакции на правильность, формируют
новый блок и участвуют в алгоритме консенсуса. Только системные администраторы име-
ют доступ на чтение ко всему блокчейну. В более поздней версии этого блокчейн-решения
планируется добавление внешних аудиторов, которые смогут прочитать весь блокчейн и
проверять правильность протокола консенсуса.

4.1. Обзор платформы Exonum

Exonum – это платформа с открытым исходным кодом, написанная на языке програм-
мирования Rust и ориентированная на создание криптографически защищенных приват-
ных блокчейнов практически для любых бизнес-задач. Тесты производительности показа-
ли высокую пропускную способность, которая измеряется в транзакциях в секунду (TPS)
для фиксированного среднего времени задержки, а именно до 5000 TPS для 1-секундной
задержки [15, 16].



ТРУДЫ МФТИ. 2020. Том 12, № 4 С.Ю. Кудряшов, С.А. Круглик и др. 35

Сам по себе Exonum предоставляет инструменты для создания блокчейнов с любы-
ми конкретными правилами обработки транзакций. Его сервисы инкапсулируют бизнес-
логику блокчейн-приложения и могут взаимодействовать с внешним миром посредством
набора заранее определенных запросов (end-point). Сервисы выполняются на каждом узле
валидатора и аудитора в блокчейн сети Exonum. Эти правила одинаковы для всех пользо-
вателей сети и определяются алгоритмом консенсуса [15].

Транзакция в Exonum – это совокупность последовательных операций с данными, а
правила их обработки определяются в сервисах. Если транзакция верна, то она может
быть включена в блок по алгоритму консенсуса, выполненному на блокчейн-валидаторах.
Стоит отметить, что порядок между транзакциями определяется алгоритмом консенсуса.
В Exonum реализован механизм генерации блоков, который подстраивается под рабочую
нагрузку сети. Необходимо исключить случаи, когда пользователь по своему запросу на
последний сгенерированный блок получил блок, сгенерированный сутки назад. Такую си-
туацию нельзя отличить от сговора узлов, которые намеренно посылают старые блоки,
чтобы ввести пользователя в заблуждение. Для этого Exonum автоматически генерирует
пустые блоки даже в случае отсутствия новых транзакций.

4.2. Типы структур данных

Предлагаемая блокчейн-система размещается поверх существующей системы отчетно-
сти производителя сырья, поэтому структуры данных, хранящиеся в блокчейне, должны
совпадать со структурами данных в системе отчетности. Ниже перечислены основные ти-
пы структур данных, поступающих из системы отчетности, а также внутренние блокчейн-
структуры данных. Данные поступают из системы отчетности (в нашем случае система
1С [17], а именно 1C_Material, 1C_Stage, 1C_Nomenclature, 1C_Passport) и состоят из
следующих атрибутов данных:

� внутрення производственная информация,

� тип сырья,

� количество сырья,

� номер партии сырья,

� наименование производителя труб,

� количество труб,

� характеристика труб,

� номер партии труб,

� дата производства.

Эта информация записывается в структуры данных о сырье (Material order, Material
type, Material batch) и в структуры данных о заказе на производство (Stage, Nomenclature,
Quality Passport). Некоторая информация в эти структуры вносится вручную через пользо-
вательский интерфейс. Кроме этого, в блокчейне содержится информация о характеристи-
ках и жизненном цикле труб (Pipe, Shipment, Acceptance, Out) со следующими атрибутами
данных:

� внутренняя техническая информация,

� характеристики трубы,

� номер партии трубы,

� наименование производителя трубы,

� статус трубы (по этапам жизненного цикла: произведена, отгружена, принята, выве-
дена из оборота),

� наименование заказчика,

� наименование потребителя трубы,

� геотеги.



36 Информатика и управление ТРУДЫ МФТИ. 2020. Том 12, № 4

4.3. Транзакции

Весь набор системных транзакций можно сгруппировать в четыре класса в соответ-
ствии с выполняемыми действиями: администрирование пользователей, стадия сырья, ста-
дия производства и конечный продукт. Ниже мы опишем каждый из них, а также внут-
реннюю структуру каждой транзакции внутри них.

Администрирование пользователей. Транзакции этого типа используются для
управления пользователями и организациями в системе. При этом каждая организация
представлена пользователями разных типов, и системные администраторы могут добав-
лять в систему организации, пользователей внутри организации добавляют представители
самой организации с правами администратора. Существует четыре транзакции такого ти-
па, что соответствует бизнес-логике системы:

� Добавление новой организации. Данная транзакция содержит следующие поля: на-
именование организации, индивидуальный номер налогоплательщика (ИНН), тип органи-
зации, адрес электронной почты, дополнительную информацию, сведения для администра-
тивной регистрации пользователя. Содержимое последнего поля соответствует транзакции
добавления нового пользователя для первого пользователя с правами администратора.

� Добавление нового пользователя. Эта транзакция содержит следующие поля: ИНН
организации, адрес электронной почты (логин доступа), имя пользователя, должность,
номер телефона, роль.

� Изменение статуса организации. Данная транзакция содержит следующие поля:
ИНН, статус.

� Изменение статуса пользователя. Эта транзакция содержит следующие поля: иден-
тификатор пользователя, статус.

Стадия сырья. Транзакции данного типа соответствуют внутренним бизнес-
процессам производителя сырья. Существует три транзакции этого типа для записи ин-
формации:

� Приходный ордер. Транзакции этого типа содержат поля: идентификатор приходного
ордера во внутренней системе отчетности, номер приходного ордера, дата приходного ор-
дера, номер партии сырья и строки в приходном ордере, тип материала, количество, дата
производства.

� Тип сырья. Транзакции этого типа содержат поля: идентификатор производителя
сырья, тип сырья информацию о технических характеристиках сырья.

� Партия сырья. Транзакции этого типа содержат поля: тип сырья, номер партии сы-
рья, общее количество сырья в партии согласно паспорту партии (m1), общее количество
принятого сырья в партии согласно данным от производителей труб (m2) и дата производ-
ства. Случай m1< m2 свидетельствует о введении в обращение контрафактного сырья в
рамках рассматриваемой партии.

Стадия производства. Транзакции такого типа соответствуют процессу производства
труб. Существует четыре транзакции такого типа:

� Запись информации о задании на производство. Транзакции этого типа содержат
следующие поля: идентификатор задания на производства во внутренней системе учета,
номер задания на производство, номер строки в задании на производство, название номен-
клатуры, номер партии труб, тип сырья, номер производственной линии, количество труб,
длина труб, статус.

� Запись информации о номенклатуре труб. Транзакции этого типа содержат следую-
щие поля: идентификатор номенклатуры трубы во внутренней системе учета, наименование
номенклатуры, вес, диаметр, SDR, номер сертификата соответствия, статуc.

� Запись информации о паспорте качества. Транзакции этого типа содержат следую-
щие поля: идентификатор паспорта качества во внутреннем системе учета, идентификатор
производителя труб, наименование номенклатуры, номер партии труб, наименование сы-
рья, номер паспорта качества партии, объем производства, статус, ссылка для скачивания
электронного паспорта качества.



ТРУДЫ МФТИ. 2020. Том 12, № 4 С.Ю. Кудряшов, С.А. Круглик и др. 37

� Изменение статуса сертификата. Транзакция данного типа содержит поля: наиме-
нование номенклатуры и статус сертификата соответствия.

Стадия конечного продукта. Транзакции такого типа соответствуют жизненному
циклу трубы. Существует восемь транзакций такого типа:

� Запись информации о трубе. Транзакции этого типа содержат следующие поля: иден-
тификатор производителя трубы, идентификатор заказчика трубы, идентификатор партии
труб, идентификатор задания на производство, идентификатор отгрузки, идентификатор
приемки, наименование заказчика, номер заказа. Другие поля соответствуют внутренним
характеристикам трубы.

� Сопоставление отгрузки и трубы. Транзакции этого типа содержат следующие поля:
идентификатор трубы, идентификатор отгрузки, наименование заказчика.

� Сопоставление приемки и трубы. Транзакции этого типа содержат следующие поля:
идентификатор трубы, идентификатор приемки, статус.

� Запись информации об отгрузке. Транзакции этого типа содержат следующие поля:
идентификатор производителя трубы, наименование заказчика, номер заказа, дата отгруз-
ки.

� Редактирование информации об отгрузке трубы. Транзакции этого типа содержат
следующие поля: идентификатор отгрузки, идентификатор производителя труб, наимено-
вание заказчика, номер заказа.

� Запись ин";"""date"",""2021-01-28T14:15:53Z""
""pdf:unmappedUnicodeCharsPerPage"",""2"",""4"",""10"",""0"",""17"",""10"",""12"",""0"",""0""
""pdf:PDFVersion"",""1.6""
""xmp:CreatorTool"",""TeX""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dcterms:created"",""2020-11-25T12:22:11Z""
""language"",""ru""
""Last-Modified"",""2021-01-28T14:15:53Z""
""dcterms:modified"",""2021-01-28T14:15:53Z""
""dc:format"",""application/pdf; version=1.6""
""xmpMM:DocumentID"",""uuid:c4c794d0-c944-4d8c-b8d3-b5f8d82c8836""
""Last-Save-Date"",""2021-01-28T14:15:53Z""
""pdf:docinfo:creator_tool"",""TeX""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2021-01-28T14:15:53Z""
""meta:save-date"",""2021-01-28T14:15:53Z""
""pdf:encrypted"",""false""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is MiKTeX-pdfTeX 2.9.6870 (1.40.19)""
""xmp:CreateDate"",""2020-11-25T15:22:11Z""
""modified"",""2021-01-28T14:15:53Z""
""Content-Length"",""669305""
""pdf:hasMarkedContent"",""false""
""Content-Type"",""application/pdf""
""xmp:ModifyDate"",""2021-01-28T17:15:53Z""
""PTEX.Fullbanner"",""This is MiKTeX-pdfTeX 2.9.6870 (1.40.19)""
""xmp:MetadataDate"",""2021-01-28T17:15:53Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""pdf:producer"",""MiKTeX pdfTeX-1.40.19""
""trapped"",""False""
""meta:creation-date"",""2020-11-25T12:22:11Z""
""created"",""2020-11-25T12:22:11Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""9""
""Creation-Date"",""2020-11-25T12:22:11Z""
""resourceName"",""4_kudryashov_31_39.pdf""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""2381"",""3206"",""1496"",""2016"",""2451"",""3184"",""2885"",""2723"",""2576""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""producer"",""MiKTeX pdfTeX-1.40.19""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""MiKTeX pdfTeX-1.40.19""
""pdf:docinfo:created"",""2020-11-25T12:22:11Z""
";https://scholar.google.ch/scholar?start=700&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098756-82;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Hyperledger frameworks with a special focus on Hyperledger Fabric;MS Krsti?, LJ Krsti? ; Vojnotehni?ki glasnik, 2020  scindeks.ceon.rs;;"… an emphasis on highly secure solutions, a token-based approach without a native cryptocurrency,

and the … Crypto Abstraction - Allows you to replace different crypto algorithms or modules … Identity

Services - Allows you to establish trust roots during Blockchain instance setup …";Autres articles;;[PDF] ceon.rs;http://scindeks-clanci.ceon.rs/data/pdf/0042-8469/2020/0042-84692003639K.pdf;"
 

639 
 

K
rs

tić
, M

. e
t a

l, 
H

yp
er

le
dg

er
 fr

am
ew

or
ks

 w
ith

 a
 s

pe
ci

a
l f

oc
u

s 
on

 H
yp

er
le

d
g

er
 F

ab
ric

, p
p.

6
39

-6
63HYPERLEDGER FRAMEWORKS WITH A 

SPECIAL FOCUS ON HYPERLEDGER 
FABRIC 

Marija S. Krstića, Lazar J. Krstićb 
 

Academy of Vocational Studies Southern Serbia,  
Department of Business Studies, Leskovac, Republic of Serbia 
a e-mail: krstic.marija@vpsle.edu.rs, corresponding author,  
  ORCID iD: https://orcid.org/0000-0003-3009-8400 
b e-mail: krstic.lazar@vpsle.edu.rs,  
  ORCID iD: https://orcid.org/0000-0001-9131-6876 

DOI: 10.5937/vojtehg68-26206; https://doi.org/10.5937/vojtehg68-26206 

FIELD: IT  
ARTICLE TYPE: Professional Paper 

Abstract: 

Introduction/purpose: The Blockchain market is a developing market, 
and many industries are increasingly aware of the importance of 
having and implementing Blockchain due to changing business 
conditions. After an introductory consideration of the Blockchain 
concept, the article focuses on the projects under the Linux 
Hyperledger Initiative, with particular reference to Hyperledger Fabric, 
notably on the concepts, architecture, organizational focus, private 
channels and smart contracts, as well as flow of transactions in the 
Hyperledger Fabric network. In the last, practical part of the paper, we 
presented a simulation of a business network and created a simple 
application for money exchange using the Hyperledger Fabric 
framework. The aim of the paper is to present the Hyperledger 
frameworks and highlight all the details of Hyperledger Fabric in order 
to determine whether its application in practice is justified. 

Methods: Basic methods (analysis, synthesis, deduction, induction, 
concretization, generalization) as well as general-scientific methods 
(analytical-deductive and comparative) were used. 

Results: All relevant features of Hyperledger Fabric were considered, a 
blockchain business network based on it was built, and an application 
for cash exchange through the network was created. 

Conclusion: Hyperledger Fabric is the most comprehensive and the 
most flexible Hyperledger framework with the largest number of use 
cases. 

Key words: Blockchain, Hyperledger, Hyperledger Fabric. 



 

640 

 V
O

JN
O

T
E

H
N

IČ
K

I G
LA

S
N

IK
 / 

M
IL

IT
A

R
Y

 T
E

C
H

N
IC

A
L 

C
O

U
R

IE
R

, 2
02

0,
 V

ol
. 6

8,
 Is

su
e 

3 Introduction 
Blockchain technology is considered a suitable catalyst for 

transformation and has the potential to become a digital trend in the near 
future. This modern technology provides data duplication on all devices 
participating in the network. Blockchain is suitable for end users because 
the data cannot be changed after storage in a chain of blocks. Namely, 
each data update is correctly recorded, which facilitates the process of 
recording transactions and tracking assets in the business network.  

Using open source tools, we strive to create Blockchain techniques 
available to a wide range of people. One such tool is Hyperledger, a set 
of technologies used to create new blockchains. The application of 
Hyperledger Blockchain technologies in business processes improves 
transparency, enhances accountability and algorithmically guarantees 
trust between business partners. The technologies created within the 
Hyperledger projects are increasingly called Third Generation Blockchain 
systems, where the first generation is considered to be Bitcoin, and the 
second Ethereum. 

The paper presents research on the topic of Hyperledger projects 
with special reference to Hyperledger Fabric. The first part is an 
introduction to the basic concepts and principles of Blockchain 
technology, which enables a decentralized way of data storage. After 
giving the basics of the Blockchain technology, the research continues in 
the direction of the Hyperledger initiative of the Linux Foundation in the 
second part of the paper. The third part is dedicated to Hyperledger 
Fabric, i.e. concepts, architecture, organizational focus, private channels, 
smart contracts and transactions in the Hyperledger Fabric network. In 
the last, practical part of the paper, a simulation of a business network is 
given and a simple application for money exchange is created, with the 
aim of a simpler understanding of the Hyperledger Fabric working 
principle. 

Blockchain technology 
Blockchain technology is a distributed replicated database. It is 

organized in the form of a single-linked list (chain), where nodes are 
blocks with data on transactions, protected by cryptographic methods 
after grouping. Hence the name Blockchain. It is a system that enables 
the realization of digital transactions without intermediaries. It is based on 
the P2P architecture, where the nodes that participate in the 
implementation of the service have a copy of all records, and constantly 
communicate with each other and synchronize records (Minović, 2017). 



 

641 
 

K
rs

tić
, M

. e
t a

l, 
H

yp
er

le
dg

er
 fr

am
ew

or
ks

 w
ith

 a
 s

pe
ci

a
l f

oc
u

s 
on

 H
yp

er
le

d
g

er
 F

ab
ric

, p
p.

6
39

-6
63To support consistent updating of information and to enable a full 

range of functions in the general ledger (transactions, queries, etc.), the 
Blockchain network uses smart contracts to provide controlled access to 
the ledger. Smart contracts are not only a key mechanism for 
encapsulating information and maintaining online simplicity, but can also 
be drawn up to allow participants to automatically execute certain 
aspects of transactions. The process by which general ledger 
transactions are synchronized online, to ensure that the general ledger is 
updated only when the transactions are approved by the respective 
participants and that the transactions remain in the same order when 
updating the general ledger, is called consensus. 

The consensus mechanism can be said to represent a predefined 
cryptographic validation method that ensures the correct sequencing of 
transactions on Blockchain. The consensus algorithm defines the rules, 
i.e. the ways in which network participants can reach an agreement on 
transaction validation. The most commonly used algorithms are Proof of 
Work (PoW) and Proof of Stake (PoS). 

Proof of Work is the most widespread way of reaching consensus, 
which is based on mining. To validate a transaction, each node must 
perform a complex mathematical calculation. That is why the device 
consumes certain resources: electricity and processing power. On the 
other hand, for successful validation, a node (miner) is rewarded with a 
certain monetary value in cryptocurrency. The more processing power it 
has, the faster the node will complete the mathematical calculation and 
get the reward, that is, will earn more. Proof of Stake does not involve 
mining, some nodes validate transactions and others confirm them, and 
everyone keeps part of their money in a virtual safe and whoever tries to 
cheat the system loses money (Pavlović, 2018). 

Blockchain can be classified into three types: public, private and 
allowed Blockchain. The classification is based on the node's ability to 
access or add a new block to the network. Public blockchain networks 
are widely available, any node can join the network, participate in 
transactions and create blocks. The examples of public blockchain are 
Bitcoin, Ethereum, Dash and Litecoin. On the other hand, with private 
Blockchain networks, only invited members are allowed to join the 
network and there is no anonymity of participants, as with public 
networks. The identity of each participant is known and cryptographically 
authenticated, on the basis of which the execution of transactions is 
monitored. Access rights to executed transactions may be granted to 
anyone or restricted in some way. The examples of private Blockchain 



 

642 

 V
O

JN
O

T
E

H
N

IČ
K

I G
LA

S
N

IK
 / 

M
IL

IT
A

R
Y

 T
E

C
H

N
IC

A
L 

C
O

U
R

IE
R

, 2
02

0,
 V

ol
. 6

8,
 Is

su
e 

3 are Hydrachain Ripple, Monaco and Multichain. The third type of 
Blockchain, which is the middle ground between private and public 
Blockchain, is known as a consortium or allowed Blockchain. In this type 
of blockchain, the network is controlled by a group of nodes. The 
examples of the consortium Blockchain network are Hyperledger Fabric 
and Corda (Nasir et al, 2018).  

Blockchain can also be said to be a collaborative data registry. Each 
time the data is accessed and modified, the change is recorded and 
confirmed, followed by encryption that cannot be subsequently edited. All 
changes are saved and added to the total record, and each subsequent 
change requires a repetition of the entire process, with the data being 
stored in a new block that is encrypted and attached to the previous 
block. Blockchain requires a lot of processing power due to the complex 
cryptography that computers have to solve in order to enable storage and 
access to data. Six basic qualities of Blockchain can be singled out, 
which together form a functional system (Piljan et al, 2018): 

- Decentralization: Blockchain is a distributed database located on 
all users' computers around the planet, i.e. on the Internet. Thus, there is 
no central database that can be attacked, hacked or forged. Also, there is 
no need for an intermediary -  information, money, securities or 
something else can be sent without the need for a broker or a third party 
(PayPal, Western Union). 

- Encryption: Blockchain is encrypted, it uses an advanced 
encryption technique using private and public keys providing virtually 
complete security in the authenticity of the transmitted data. 

- Transparency: Blockchain is public. All users have access to the 
database and no one can hide an individual transaction. 

- Inclusiveness: Blockchain does not require special technical 
preconditions for participation, the protocol is designed in such a way that 
it can be implemented on practically any computer or mobile device, thus 
providing the possibility of use to practically the entire Internet population. 

- Immutability: after a transaction has been executed, verified and 
placed in a block, it is linked to the previous transaction or block. This 
structure is marked with a unique code and timestamp, which prevents 
the possibility of subsequent changes. 

- Historicity: there is no way to steal a transaction or data about a 
block, because that would mean rewriting the entire Blockchain, or all 
transactions ever performed in it. This means that Blockchain at all times 
contains all transactions that have been executed since the chain was 
created. 



 

643 
 

K
rs

tić
, M

. e
t a

l, 
H

yp
er

le
dg

er
 fr

am
ew

or
ks

 w
ith

 a
 s

pe
ci

a
l f

oc
u

s 
on

 H
yp

er
le

d
g

er
 F

ab
ric

, p
p.

6
39

-6
63Hyperledger 

Hyperledger is an open source project founded by the Linux 
Foundation. The initiative was launched in December 2015 in order to 
advance and promote Blockchain technologies and expand the 
possibilities of their application in the business world. Members of the 
Hyperledger initiative are many of the world's leading companies in the 
fields of information and high technologies, finance and banking, 
production and distribution of products (supply chain), such as: Intel, IBM, 
Cisco, Airbus, Daimler, JP Morgan, American Express, Deloitte, PWC, 
BNP Paribas, Baidu, SAP, Huawei, as well as many others, including the 
domestic company GameCredits (Gajić, 2018). 

Hyperledger is not a unique Blockchain technology, but a collection 
of technologies included by member companies. Although there is a 
long-term goal of greater integration between projects, most Hyperledger 
projects still operate independently. Hyperledger has never issued its 
cryptocurrency, and according to its founders, it will continue to do so in 
the future. Concrete technologies can be said to be explicitly designed 
and built for enterprise use cases, not for public markets. 

The active development of Hyperledger projects took place at the 
beginning of 2016, and it implies the development of a larger number of 
frameworks and tools. Hyperledger frameworks, i.e. distributed ledger 
technology (DLT) technologies include Fabric, Sawtooth, Iroha, Indy and 
Burrow, while tools are being developed from Composer, Cello and 
Explorer (Dhillon et al, 2017). 

Each of the Hyperledger technologies has its own specific 
advantages in certain applications. Some of the mentioned technologies 
have advanced in the development phases and are actively applied 
(Fabric, Sawtooth, Iroha), while others are still in the incubation phase 
(Burrow, Indy). As far as tools are concerned, the most developed is 
Composer. 

Hyperledger projects follow a design philosophy that includes a 
modular extensible approach, interoperability, an emphasis on highly 
secure solutions, a token-based approach without a native 
cryptocurrency, and the development of a rich and simple application 
user interface. The modular approach allows developers to experiment 
with creating different types of components. They can create components 
that can be combined, in order to develop distributed general ledger 
solutions that meet different requirements. Hyperledger recognizes that 
security is a fundamental aspect of distributed general ledgers, as many 



 

644 

 V
O

JN
O

T
E

H
N

IČ
K

I G
LA

S
N

IK
 / 

M
IL

IT
A

R
Y

 T
E

C
H

N
IC

A
L 

C
O

U
R

IE
R

, 2
02

0,
 V

ol
. 6

8,
 Is

su
e 

3 use cases involve large-value transactions or sensitive data. In the future, 
many different Blockchain networks will have to communicate and 
exchange data in order to form more complex and powerful networks. A 
high degree of interoperability will provide support for a growing 
application of Blockchain. Also, Hyperledger projects provide rich and 
simple application user interfaces that support interoperability with other 
systems. However, the design philosophy includes the ability to create 
tokens used to manage digital objects which can represent currencies. 

The Hyperledger Architecture Working Group has singled out the 
following business components of Blockchain (Hyperledger, 2018): 

- Consensus Layer - Responsible for creating an order agreement 
and validating the set of transactions that make up the block. 

- Smart Contract Layer - Responsible for processing transaction 
requests and determining the validity of transactions by applying 
business logic. 

- Communication layer - Responsible for peer-to-peer transmission 
of messages between nodes participating in a common general ledger. 

- Data Warehouse Abstraction - Allows different data warehouses to 
be used in other modules. 

- Crypto Abstraction - Allows you to replace different crypto 
algorithms or modules without affecting other modules. 

- Identity Services - Allows you to establish trust roots during 
Blockchain instance setup, enroll and register identities or system entities 
during network operation, and manage changes. They also provide 
authentication and authorization. 

- Access Services - Responsible for managing various approaches 
specified in the system, such as the validation approach, the consensus 
approach, or the group management approach. They connect and 
depend on other modules to implement different approaches. 

- Application User Interfaces - Allows clients and applications to 
connect to Blockchain. 

- Interoperability - Interoperability between different Blockchains is 
supported. 

Hyperledger goals 
Hyperledger provides a neutral space for software collaboration 

between companies that are traditionally competitors. It also provides a 
neutral space for cross-sectoral cooperation. Blockchains in Hyperledger 
are allowed and are specifically designed to be business solutions. 
Because it is a system that requires permission, only those authorized 
can join the network. This makes it more secure, as the administrator can 



 

645 
 

K
rs

tić
, M

. e
t a

l, 
H

yp
er

le
dg

er
 fr

am
ew

or
ks

 w
ith

 a
 s

pe
ci

a
l f

oc
u

s 
on

 H
yp

er
le

d
g

er
 F

ab
ric

, p
p.

6
39

-6
63restrict access to Blockchain. In addition, instead of making all 

transactions available to everyone online, they are only shown to the 
relevant parties. Hyperledger's goals include (Hyperledger, 2020d): 

- Creating acceptable working environments, i.e. distributed open 
source ledger technologies as well as code bases to support business 
transactions. 

- Providing a neutral, open community-based infrastructure 
supported by business and technical management. 

- Creating technical communities to develop Blockchain and use 
cases. 

- Educating the public about market opportunities for Blockchain 
technology. 

- Promoting the community using access to tools with many platforms  
and frameworks. 

Hyperledger frameworks 
Each of the Hyperledger technologies of the distributed general 

ledger has its own specific advantages in certain applications. The 
Hyperledger frameworks are used to build business blockchains for a 
consortium of organizations. Hyperledger incubates and promotes a 
range of business blockchain technologies, including (Blockstuffs, 2018): 

- distributed general ledger frameworks, 
- smart contracts, 
- graphical interfaces, 
- library client, 
- service libraries, and 
- simple applications. 
 
The Hyperledger strategy encourages the reuse of common blocks, 

enables rapid component innovation, and promotes interoperability 
between projects. As already mentioned, five Hyperledger Blockchain 
frameworks can be singled out (Suprunov, 2018): 

- Hyperledger Fabric, 
- Hyperledger Iroha, 
- Hyperledger Indy, 
- Hyperledger Sawtooth, and 
- Hyperledger Burrow. 
 
Hyperledger Fabric is the basis for developing applications or 

solutions with a modular architecture. It allows components, such as 



 

646 

 V
O

JN
O

T
E

H
N

IČ
K

I G
LA

S
N

IK
 / 

M
IL

IT
A

R
Y

 T
E

C
H

N
IC

A
L 

C
O

U
R

IE
R

, 2
02

0,
 V

ol
. 6

8,
 Is

su
e 

3 consensus and Membership Services Providers (MSP), to be plug-and-
play. 

Iroha Hyperledger is designed to be simple and easy to engage in 
infrastructure projects that require distributed general ledger technology. 
Hyperledger Iroha has a simple construction, modern C++ domain-based 
design, and it emphasizes the development of mobile applications, as 
well as a new, chain-based, Byzantine Fault Tolerance consensus 
algorithm, called Sumeragi (IBM Global Business Services, 2019). 

Hyperledger Indy is a distributed general ledger, built for a 
decentralized identity. Indy provides tools, libraries, and components that 
can be reused to create and use independent digital identities based on 
Blockchain or other distributed general ledgers. These identities are 
interoperable across administrative domains, applications, and all other 
parts of organizations. The key characteristics of Indy are (Blockstuffs, 
2018): 

- Independence - Indy keeps identity artifacts in the general ledger 
with distributed ownership. These artifacts can include public keys and 
evidence of existence, and no one but the rightful owner can change or 
remove the identity. 

- Privacy - Indy maintains privacy by default, as any identity owner 
can operate without any risk of correlation or trace. 

- Verifiable requirements - Identification requirements may resemble 
known credentials such as birth certificates, driver's licenses, passports, 
etc. They can be combined and transformed using methods that reveal 
only certain information to allow selective disclosure of only the data 
needed in a particular context. 

 
Hyperledger Sawtooth is a modular platform for building, 

implementing, and managing distributed general ledgers. Distributed 
general ledgers provide a digital record (such as property ownership) that 
is maintained without central management or implementation. In addition 
to enabling organizations to organize, build, implement, and run complex 
distributed books, this platform includes a new consensus algorithm, 
Proof of Elapsed Time (PoET), that targets large distributed populations 
of validators with minimal resource consumption (Hyperledger, 2020b). 
Sawtooth contains several technical innovations, such as dynamic 
consensus, proof of elapsed time, compatibility with Ethereum contracts, 
parallel transaction execution, and private transactions. Dynamic 
consensus allows a consortium to change consensus algorithms on a 
running blockchain by simply starting a transaction. Proof of Elapsed 
Time is a consensus algorithm with proven usability in operation, but 



 

647 
 

K
rs

tić
, M

. e
t a

l, 
H

yp
er

le
dg

er
 fr

am
ew

or
ks

 w
ith

 a
 s

pe
ci

a
l f

oc
u

s 
on

 H
yp

er
le

d
g

er
 F

ab
ric

, p
p.

6
39

-6
63without high energy consumption. Smart contract abstraction is also 

enabled, allowing users to create smart contracts in the language of their 
choice. In terms of private transactions, Sawtooth node clusters can be 
easily used with separate permissions, ensuring privacy and 
confidentiality among participants in that particular chain. 

Hyperledger Burrow is a modular Blockchain client with a permitted 
smart contract interpreter that is partially done in the Ethereum Virtual 
Machine (EVM) specification (Hyperledger, 2020Đ°). It can be said that 
Burrow is a smart contract machine that requires a license. Monax 
originally developed and proposed this machine to Hyperledger. Burrow 
provides an extremely deterministic, smart blockchain design that 
focuses on contracts. The components that Burrow encompasses are the 
consensus mechanism, the Application Blockchain Interface (ABCI), the 
smart contract mechanism, and the gateway. The consensus mechanism 
maintains a network stack between nodes and ordered transactions that 
will be used by applications. The ABCI application interface provides an 
interface specification for connecting the consensus mechanism and the 
application. The smart contract mechanism provides developers with an 
extremely deterministic mechanism for managing complex industrial 
processes. The gateway provides a programming interface for system 
integrations and user interfaces. 

Hyperledger tools 
Tools, such as software that facilitate deployment, debugging, and 

design, can make a huge difference in the ease of use of any system, for 
both developers and users. Hyperledger is constantly investing in 
building great support tools. There are several tools that allow easy and 
efficient access to Blockchain. The most used among the tools are 
Hyperledger Composer, Hyperledger Cello, Hyperledger Explorer and 
Hyperledger Caliper. 

Hyperledger Composer is the most developed and most powerful 
Hyperledger tool. It can be said that it is a framework for Hyperledger 
Fabric. Using Composer brings simpler concepts for Hyperledger Fabric, 
called Business Network Definitions (BND). These are source code 
packages that define a business network. This includes permissions, 
queries, participants, assets and transaction definitions, as well as the 
implementation of different types of transactions. GNI should be applied 
to all nodes of the Hyperledger Fabric network. Hyperledger Fabric is 
implemented with Hyperledger Composer as a platform and 
infrastructure (Verhoelen, 2018). Hyperledger Composer is written in 



 

648 

 V
O

JN
O

T
E

H
N

IČ
K

I G
LA

S
N

IK
 / 

M
IL

IT
A

R
Y

 T
E

C
H

N
IC

A
L 

C
O

U
R

IE
R

, 2
02

0,
 V

ol
. 6

8,
 Is

su
e 

3 JavaScript and is the most active tool for development activity. It is a tool 
for building business blockchain networks, and is designed to accelerate 
the integration of block applications and smart contracts with existing 
business models. This tool is a framework that accelerates the 
development of applications developed through Hyperledger Fabric. 

Hyperledger Cello enables easy hosting of Blockchain, connected 
components and infrastructure according to external sites. It is a module-
based Blockchain tool and a service system. Also called Blockchain as a 
Service (BaaS), it allows the user to maintain a Blockchain network and 
infrastructure (Blockstuffs, 2018). BaaS is an offer that allows users to 
leverage cloud-based solutions to build, host and use their Blockchain 
applications, smart contracts and Blockchain-based features, while a 
cloud-based service provider manages all necessary infrastructure 
maintenance tasks and activities. Hyperledger Cello also provides 
tracking and analytics capabilities. 

Hyperledger Explorer provides a control panel for viewing block 
information, node logs, statistics, smart contracts, transactions, and all 
other information stored in Blockchain. Users can query for specific 
blocks or transactions to see complete details. Hyperledger Explorer can 
integrate with any authentication or authorization platform, commercial or 
open source, to provide features that match user privileges. 

Hyperledger Caliper allows users to measure the performance of a 
particular Blockchain implementation with a set of predefined use cases. 
Hyperledger Caliper allows you to create reports that contain a number of 
performance indicators, such as Transactions Per Second, Transaction 
delays, and resource usage (Kuhrt, 2019). Hyperledger Caliper is a 
performance testing tool for Hyperledger blockchain solutions such as 
Fabric, Composer, Iroha, and others. Using Caliper, the team working on 
Blockchain applications can take continuous measurements while 
building smart contracts and transaction logic and use those 
measurements to track performance changes. Caliper is compatible with 
Sawtooth, Indi and Fabric Blockchain systems. 

Hyperledger Fabric 
Hyperledger Fabric, as a Hyperledger framework, is the most 

advanced in development. It is interesting to note that, as part of the 
Hyperledger project, it originated from IBM. This work environment offers 
a modular architecture in which components such as consensus 
algorithms and membership service providers can be modified on a plug-
and-play basis. 



 

649 
 

K
rs

tić
, M

. e
t a

l, 
H

yp
er

le
dg

er
 fr

am
ew

or
ks

 w
ith

 a
 s

pe
ci

a
l f

oc
u

s 
on

 H
yp

er
le

d
g

er
 F

ab
ric

, p
p.

6
39

-6
63Hyperledger Fabric is a platform for software solutions that use a 

distributed general ledger (database). It is a private, permissive 
blockchain infrastructure that provides a modular architecture with 
delineating roles between nodes within the Blockchain system, executing 
smart contracts, and configurable consensus and membership services. 
Its advantages are: identity management, channel privacy and 
confidentiality, efficient data transmission processing, chaincode 
functionality, and modular design. 

Hyperledger Fabric is designed to be a company-oriented 
Blockchain solution that is extremely modular and adaptable. 
Hyperledger Fabric is private and requires permission. This means that it 
is understood that Hyperledger Blockchains are not available to the 
general public and do not have tokens that can be exchanged. 
Blockchain users must have verified identities and join Blockchain using 
a Membership Service Provider (MSP). Membership service providers 
are configured in the system, and there may be more than one, but all 
members must be accessible by one or more membership service 
providers. Hyperledger Fabric also has a number of special tools that 
make it particularly well equipped (Hill et al, 2018). 

Hyperledger Fabric technology distributed general ledgers profit 
from the advantages of container technologies for working with smart 
contracts, which in this context are called a program code chain and 
which realize the application logic of the system using the Go 
programming language. The specific mechanism of private channels that 
exists in Hyperledger Fabric allows the sharing of confidential information 
between individual participants in the Blockchain network. The key 
features that set Hyperledger Fabric apart as a comprehensive and 
customizable Blockchain solution are (Hyperledger-fabricdocs 
Documentation, 2019): 

- Assets - Definitions of assets allow the exchange of almost 
anything that has monetary value over the network, from food through old 
cars to the currencies of the future. 

- Chaincode - Chaincode execution is separate from transaction 
handling, limiting required levels of trust and verification across nodes, 
and optimizing network scalability and performance. 

- General Ledger Features - A fixed, shared book that encodes the 
entire transaction history for each channel and includes the ability to ask 
SQL like queries for more efficient audit and dispute resolution. 

- Channel privacy - Channels enable multilateral transactions with a 
high degree of privacy and confidentiality required by competing 



 

650 

 V
O

JN
O

T
E

H
N

IČ
K

I G
LA

S
N

IK
 / 

M
IL

IT
A

R
Y

 T
E

C
H

N
IC

A
L 

C
O

U
R

IE
R

, 2
02

0,
 V

ol
. 6

8,
 Is

su
e 

3 companies and industries that exchange assets through a common 
network. 

- Security and Services for Members - Membership that requires 
permission provides a reliable Blockchain network, where participants 
know that all transactions can be detected and monitored by authorized 
regulators and auditors. 

- Consensus - A unique approach to consensus provides the 
flexibility and usability that a company needs. 

 
Another important feature introduced by Hyperledger Fabric is 

confidentiality when performing transactions on the same network of 
nodes. Hyperledger Fabric adopts the following terminology related to its 
workflow: Blockchain ""application"" through the interface manages the 
user and the network. Smart contracts are also called chain codes and 
are provided using the Node SDK, Java SDK and command line interface 
- as development tools (Belotti et al, 2019). 

Features of architecture 
Hyperledger Fabric is designed with several key features and use 

cases that are considered important for business users. It is basically a 
general ledger. The general ledger is a set of blocks, and each block 
contains a set of transactions. A transaction is anything that 
changes/updates the state of a Blockchain. Transactions, in turn, are 
performed using smart contract codes installed on Blockchain. The 
general ledger records the status of data and transactions, and each 
node in the network has a replicated copy of the general ledger. There 
are two basic components to a general ledger: 

- World state database in which the current values of general ledger 
data are recorded. It provides fast and efficient access to current values, 
instead of searching transaction logs. Data is stored by key-value 
structure, and this database is characterized by frequent additions, 
updates and deletions. 

- A transaction log that records all changes over the world state 
database, and once recorded, data cannot be changed or deleted. 

 
The blocks are arranged sequentially, and within each block there is 

a set of transactions. These transactions are also stored as events in a 
specific sequence. Unlike other Blockchains, the creation of a transaction 
and the resulting string does not necessarily occur at the same time or on 
the same computer. This is because ordering transactions is separate 
from executing transactions. In Hyperledger Fabric, computers used to 



 

651 
 

K
rs

tić
, M

. e
t a

l, 
H

yp
er

le
dg

er
 fr

am
ew

or
ks

 w
ith

 a
 s

pe
ci

a
l f

oc
u

s 
on

 H
yp

er
le

d
g

er
 F

ab
ric

, p
p.

6
39

-6
63manage Blockchain can be included in three different ways (node types), 

and these are (Hill et al, 2018): 
- Client: The client acts on behalf of the Blockchain user and submits 

actions and events to the network as part of the application. 
- Peers: Peers process incoming validation transactions and update 

status changes as a result of transactions and chain code applications. 
When they make a transaction, they broadcast the result to the network 
so that the transaction can be done by the customer. 

- Client: While the peer nodes execute transactions, the client nodes 
review all executed transactions and decide on the final order that is 
considered to have occurred in the Blockchain. The nodes that ordered 
the service decide on the final sequence of events and thus decide on 
the final set of events to be printed on the next block of the Blockchain. 

 
There is a possibility that one computer performs the function of all 

three types of nodes on the Hyperledger Fabric Blockchain";"""date"",""2020-07-22T11:56:20Z""
""pdf:PDFVersion"",""1.5""
""xmp:CreatorTool"",""PScript5.dll Version 5.2.2""
""pdf:docinfo:title"",""Microsoft Word - 13 Krstic KONACNO""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""PScript5.dll Version 5.2.2""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""Microsoft Word - 13 Krstic KONACNO""
""xmp:CreateDate"",""2020-07-22T13:56:20Z""
""modified"",""2020-07-22T11:56:20Z""
""pdf:hasMarkedContent"",""false""
""xmp:ModifyDate"",""2020-07-22T13:56:20Z""
""pdf:docinfo:creator"",""Intel""
""meta:author"",""Intel""
""meta:creation-date"",""2020-07-22T11:56:20Z""
""created"",""2020-07-22T11:56:20Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-07-22T11:56:20Z""
""resourceName"",""0042-84692003639K.pdf""
""Author"",""Intel""
""producer"",""Acrobat Distiller 9.5.2 (Windows)""
""pdf:docinfo:producer"",""Acrobat Distiller 9.5.2 (Windows)""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""access_permission:modify_annotations"",""true""
""dc:creator"",""Intel""
""dcterms:created"",""2020-07-22T11:56:20Z""
""Last-Modified"",""2020-07-22T11:56:20Z""
""dcterms:modified"",""2020-07-22T11:56:20Z""
""title"",""Microsoft Word - 13 Krstic KONACNO""
""xmpMM:DocumentID"",""uuid:4dc91f42-fbe8-4a8e-99aa-44e6cb613d8e""
""Last-Save-Date"",""2020-07-22T11:56:20Z""
""pdf:docinfo:modified"",""2020-07-22T11:56:20Z""
""meta:save-date"",""2020-07-22T11:56:20Z""
""Content-Length"",""619635""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Intel""
""pdf:producer"",""Acrobat Distiller 9.5.2 (Windows)""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""25""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""2137"",""2601"",""2799"",""2688"",""2595"",""2500"",""1799"",""2636"",""2637"",""2617"",""2655"",""2432"",""2499"",""1859"",""2546"",""2218"",""1929"",""806"",""747"",""378"",""2370"",""2826"",""2338"",""2101"",""2308""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-07-22T11:56:20Z""
";https://scholar.google.ch/scholar?start=630&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098884-377;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;[HTML][HTML] Fractional chaotic maps based short signature scheme under human-centered IoT environments;C Meshram, RW Ibrahim, AJ Obaid… ; Journal of Advanced …, 2020  Elsevier;;"… This paper introduces an efficient Short Signature Scheme (SSS) that uses Fractional Chaotic

Map (FCM) for secure communication in IoT based smart devices, the security of which is closely

related to a random oracle model based on FCM assumption …";Cité 4 fois;Les 3 versions;[HTML] sciencedirect.com;https://www.sciencedirect.com/science/article/pii/S2090123220302010;;;https://scholar.google.ch/scholar?start=920&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098888-383;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;[PDF][PDF] Smart Contract Technology and Financial Inclusion;World Bank Group ;2020 openknowledge.worldbank.org;;"… 6 3.3. Blockchain-Based Smart Contracts 6 4. Smart Contract Advantages and Efficiencies 9 4.1 …

28 LIST OF FIGURES Figure 1. Coding the Underlying Payout Logic in a Weather Index Insurance

Policy 5 Figure 2. Four Basic Stages of a Blockchain-based Smart Contract 7 …";Autres articles;Version HTML;[PDF] worldbank.org;https://openknowledge.worldbank.org/bitstream/handle/10986/33723/Smart-Contract-Technology-and-Financial-Inclusion.pdf?sequence=1;;"""date"",""2020-05-06T17:26:29Z""
""pdf:PDFVersion"",""1.4""
""xmp:CreatorTool"",""Adobe InDesign 15.0 (Macintosh)""
""pdf:docinfo:title"",""World Bank Document""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""language"",""en""
""dc:format"",""application/pdf; version=1.4""
""pdf:docinfo:creator_tool"",""Adobe InDesign 15.0 (Macintosh)""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""World Bank Document""
""xmp:CreateDate"",""2020-05-05T17:32:21Z""
""modified"",""2020-05-06T17:26:29Z""
""pdf:hasMarkedContent"",""false""
""xmp:ModifyDate"",""2020-05-05T22:17:30Z""
""pdf:docinfo:creator"",""World Bank Group""
""meta:author"",""World Bank Group""
""trapped"",""False""
""meta:creation-date"",""2020-05-05T21:32:21Z""
""created"",""2020-05-05T21:32:21Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-05-05T21:32:21Z""
""resourceName"",""Smart-Contract-Technology-and-Financial-Inclusion.pdf""
""xmpMM:DerivedFrom:DocumentID"",""xmp.did:fc552170-b94d-4486-a6e9-56acbf4f0fdc""
""Author"",""World Bank Group""
""producer"",""Adobe PDF Library 15.0 / PDF PT 4.7.24.2 (pdf-tools.com)""
""pdf:docinfo:producer"",""Adobe PDF Library 15.0 / PDF PT 4.7.24.2 (pdf-tools.com)""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""access_permission:modify_annotations"",""true""
""dc:creator"",""World Bank Group""
""dcterms:created"",""2020-05-05T21:32:21Z""
""Last-Modified"",""2020-05-06T17:26:29Z""
""dcterms:modified"",""2020-05-06T17:26:29Z""
""title"",""World Bank Document""
""xmpMM:DocumentID"",""xmp.id:66ba8cbf-a7df-491f-9078-76e4c9b7eac4""
""Last-Save-Date"",""2020-05-06T17:26:29Z""
""pdf:docinfo:modified"",""2020-05-06T17:26:29Z""
""meta:save-date"",""2020-05-06T17:26:29Z""
""Content-Length"",""1300072""
""Content-Type"",""application/pdf""
""xmp:MetadataDate"",""2020-05-05T22:17:30Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""World Bank Group""
""dc:language"",""en-US""
""pdf:producer"",""Adobe PDF Library 15.0""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""50""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""236"",""1515"",""1055"",""1405"",""940"",""0"",""573"",""0"",""2533"",""807"",""2204"",""3120"",""1720"",""3865"",""3081"",""0"",""2621"",""1975"",""1654"",""0"",""1340"",""4659"",""1351"",""0"",""2431"",""4641"",""4522"",""2757"",""4242"",""0"",""2482"",""2854"",""1304"",""2883"",""4531"",""3318"",""467"",""0"",""1746"",""2249"",""3689"",""2448"",""3472"",""3305"",""1905"",""3392"",""3368"",""2272"",""0"",""0""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""xmpMM:DerivedFrom:InstanceID"",""xmp.iid:164b5e15-0282-4dce-ac11-289cd47000d6""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-05-05T21:32:21Z""
";https://scholar.google.ch/scholar?start=930&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098861-329;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Oracle simulation: a technique for protocol composition with long term shared secrets;H Comon, C Jacomme, G Scerri ; … of the 2020 ACM SIGSAC Conference …, 2020  dl.acm.org;;"… attacker can interact with. Given a protocol P and a cryptographic library Mf , the oracle

OP is an extension of the previous oracles: it takes as an additional input an history

tape that records the previous queries. Given a query m …";Cité 2 fois;Les 13 versions;[PDF] inria.fr;https://hal.inria.fr/hal-02913866/file/main.pdf;"
HAL Id: hal-02913866
https://hal.inria.fr/hal-02913866

Submitted on 10 Aug 2020

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L’archive ouverte pluridisciplinaire HAL, est
destinĂŠe au dĂŠpĂ´t et Ă  la diffusion de documents
scientifiques de niveau recherche, publiĂŠs ou non,
émanant des établissements d’enseignement et de
recherche français ou Êtrangers, des laboratoires
publics ou privĂŠs.

Oracle simulation: a technique for protocol composition
with long term shared secrets

Hubert Comon, Charlie Jacomme, Guillaume Scerri

To cite this version:
Hubert Comon, Charlie Jacomme, Guillaume Scerri. Oracle simulation: a technique for protocol
composition with long term shared secrets. ACM CCS 2020, Nov 2020, Orlando, United States.
pp.1427-1444. �hal-02913866�

https://hal.inria.fr/hal-02913866
https://hal.archives-ouvertes.fr


Oracle simulation: a technique for protocol composition with
long term shared secrets

Hubert Comon1, Charlie Jacomme2, and Guillaume Scerri3

1,2LSV, CNRS & ENS Paris-Saclay & Inria & UniversitĂŠ Paris-Saclay
3UniversitĂŠ Versailles Saint-Quentin & Inria

August 10, 2020

Abstract

We provide a composition framework together with a variety of composition theorems
allowing to split the security proof of an unbounded number of sessions of a compound
protocol into simpler goals. While many proof techniques could be used to prove the
subgoals, our model is particularly well suited to the Computationally Complete Symbolic
Attacker (CCSA) model.

We address both sequential and parallel composition, with state passing and long term
shared secrets between the protocols. We also provide with tools to reduce multi-session
security to single session security, with respect to a stronger attacker. As a consequence,
our framework allows, for the first time, to perform proofs in the CCSA model for an
unbounded number of sessions.

To this end, we introduce the notion of O-simulation: a simulation by a machine
that has access to an oracle O. Carefully managing the access to long term secrets, we
can reduce the security of a composed protocol, for instance P‖Q, to the security of P
(resp. Q), with respect to an attacker simulating Q (resp. P ) using an oracle O. As
demonstrated by our case studies the oracle is most of the time quite generic and simple.

These results yield simple formal proofs of composed protocols, such as multiple ses-
sions of key exchanges, together with multiple sessions of protocols using the exchanged
keys, even when all the parts share long terms secrets (e.g. signing keys). We also provide
with a concrete application to the SSH protocol with (a modified) forwarding agent, a
complex case of long term shared secrets, which we formally prove secure.

Contents

I The Framework 3

1 Introduction 3
1.1 Our contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2 Related Works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1



2 Protocols and Indistinguishability 7
2.1 Syntax and semantics of terms . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2 Syntax of the protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.3 Semantics of the protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.4 Stateless Oracle Machines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.5 Computational indistinguishability . . . . . . . . . . . . . . . . . . . . . . . . . 12

3 Simulatability 13
3.1 Protocol Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.2 Generic Oracles for Tagged Protocols . . . . . . . . . . . . . . . . . . . . . . . . 23

4 Main Composition Theorems 25
4.1 Composition without State Passing . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.2 Composition with State Passing . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.3 Unbounded Replication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

5 Unbounded Sequential Replication 33

II Applications to Key Exchange 34

6 Application to Key Exchanges 34
6.1 Our Model of Key Exchange . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
6.2 Proofs of Composed Key Exchange Security . . . . . . . . . . . . . . . . . . . . 35

7 Basic Diffie-Hellman Key Exchange 38

8 Extension to Key Confirmations 40
8.1 Proofs with Key Confirmations . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

9 Application to SSH 41
9.1 The SSH Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
9.2 Security of SSH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
9.3 SSH with Forwarding Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

III Composition in the CCSA logic 47

10 Oracles in the CCSA Logic 48
10.1 Syntax and Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
10.2 Oracle Soundness . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

11 Computational Soundness of the logic 51
11.1 Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
11.2 Introduction of attacker’s functions . . . . . . . . . . . . . . . . . . . . . . . . . 52

12 Extension to the Model for Unbounded Replication 53

2



A Messages 59
A.1 Syntax of messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
A.2 Semantics of terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

B Protocols 60
B.1 Protocol Algebra . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
B.2 Formal definition of a protocol execution . . . . . . . . . . . . . . . . . . . . . . 60
B.3 Formal definition of protocol oracles . . . . . . . . . . . . . . . . . . . . . . . . 61

C A case study : signed DDH 64
C.1 Key exchange security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
C.2 Proof for φ3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

C.2.1 Real or random of the key . . . . . . . . . . . . . . . . . . . . . . . . . . 67
C.2.2 Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

C.3 Conclusion for Signed DDH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

D An application to SSH 69
D.1 Presentation of SSH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
D.2 The security of the protocol without forwarding agent . . . . . . . . . . . . . . 70
D.3 Proof of real of random . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

D.3.1 Proof of Ax |= φ2 ∼ ψ2 . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
D.3.2 Proof of Ax |= φ1

2 ∟ ψ1
2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

D.4 Proof for the authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

E SSH with forwarding agent 74
E.1 Scheme of the proof . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

E.1.1 First application of Corollary 3 . . . . . . . . . . . . . . . . . . . . . . . 75
E.1.2 Second application of Corollary 3 . . . . . . . . . . . . . . . . . . . . . . 76

F Proofs 77
F.1 Formal Corollary for Key Exchange . . . . . . . . . . . . . . . . . . . . . . . . . 77
F.2 Formal Corollary for Key Confirmations . . . . . . . . . . . . . . . . . . . . . . 79
F.3 Oracle Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
F.4 Autocomposition Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
F.5 Key Exchanges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
F.6 Computational soundness . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

Part I

The Framework

1 Introduction

This paper is concerned with the security proofs of composed protocols. This topic has been
widely studied in the last two decades. For instance, Universal Composability (UC) and
simulation based reductions [1–6] and other game-based composition methods [7–10] address
this issue. While the former proceed in a more bottom-up manner (from secure components in

3



any environment, construct secure complex protocols), the latter proceed in a more top-down
way: from the desired security of a complex protocol, derive sufficient security properties of its
components. Such “top-down” proofs design allows more flexibility: the security requirements
for a component can be weaker in a given environment than in an arbitrary environment.
The counterpart is the lack of “universality”: the security of a component is suitable for some
environments only.

We follow the “top-down” approach. While we aim at designing a general methodology,
our target is the management of formal security proofs in the Computationally Complete
Symbolic Attacker (CCSA) model [11]. As a side result of our work, we provide with a way
of proving the security of an arbitrary number of sessions (that may depend on the security
parameter) in the CCSA model.

When trying to (de-)compose security properties, the main difficulty comes from the fact
that different protocols may share some secrets. This is typically the case for multiple sessions
of the same protocol, or for key exchange protocols, which result in establishing a shared
secret that will be later used in another protocol. Protocols may also share long term secrets,
for instance the same signing key may be used for various authentication purposes. Another
example is the SSH protocol with the agent forwarding feature [12], which we will consider
later. The forwarding feature allows to obtain, through previously established secure SSH
connections, signatures of fresh material required to establish new connections. It raises a
difficulty, as signatures with a long term secret key are sent over a channel established using
the same long term secret key.

As far as we know, the existing composition results that follow the “top-down” approach
cannot be used in situations where there is both a “state passing”, as in key exchange protocols,
and shared long term secrets. For instance, in the nice framework of [10], the same public key
cannot be used by several protocols, a key point for reducing security of multiple sessions to
security of one session.

When decomposing the security of a composed protocol into the security of its components,
we would like to break a complex proof into simpler proofs, while staying in the same proof
framework. This is also a difficulty since the attacker on a protocol component might use the
other components: we need a proof with respect to a stronger attacker. In [10], such a strong
attacker can be simulated by a standard one, because there is no shared long term secret.

1.1 Our contributions

We provide with a composition framework that reduces the security of a compound protocols
to the security of its components. We allow both state passing and shared long term secrets.
We stay in the same proof framework of the CCSA model.

The starting idea is simple: if we wish to prove the security of a composed protocol P‖Q,
it is sufficient to prove the security of P against an attacker that may simulate Q, maybe
with the help of an oracle. If n are the secrets shared by P and Q, this simulation has
to be independent of the distribution of n. This is actually an idea that is similar to the
key-independence of [8].

Therefore, we first introduce the notion of O-simulation, in which an oracle O holds the
shared secrets: if Q is O-simulatable and P is secure against an attacker that has access to O,
then P‖Q is secure. Intuitively, O defines an interface through which the secrets can be used
(e.g. obtaining signatures of only well tagged messages). O simulatable protocols conform to
this interface.

4



We extend this basic block to arbitrary parallel and sequential compositions, as well as
replication of an unbounded number of copies of the same protocol. In the latter case, the
security of a single copy of P against an attacker that has access to an oracle allowing to
simulate the other copies, requires to distinguish the various copies of a same protocol. In the
universal composability framework, this kind of properties is ensured using explicit session
identifiers. We rather follow a line, similar to [13], in which the session identifiers are implicit.

Our main composition Theorems are generic: the classical game based setting can be used
to prove the subgoals. They are also specially well-suited for the CCSA model, which allows
to complete computational proofs of real life protocols [14–16], while only relying on first order
logic and cryptographic axioms. Many such axioms can easily be generalized so as to be sound
with respect to an attacker that has access to oracles (we will see examples later).

A proof using such axioms is valid for an attacker who has access to an environment,
while abstracting all the details of the environment and its interactions with the attacker.
Moreover, as our reductions from one session to multiple sessions are uniform, we may now
complete proofs in the CCSA model for a number of session that is parameterized by the
security parameter. This was a limitation (and left as an open issue) in all previous CCSA
papers.

We illustrate our composition results showing how to split the security of any (multi-session
with shared long term secret) composed key exchange into smaller proofs. We then complete
the formal proof of security of a Diffie-Hellman key exchange (ISO 9798-3 [17]) for any number
of sessions in parallel.

We generalize the application to key exchanges performing key confirmations, i.e. using
the derived key in the key exchange (as in TLS). The generalization is simple, which is a clue
of the usability of our framework.

To illustrate the usability of our framework, we use all our results to prove the security of
the SSH [12] protocol with a modified agent forwarding, a complex example of key exchange,
with both key confirmation and long term shared secrets. The modification, which consists in
the addition of a tag to specify if the signature was performed remotely, is necessary for the
protocol to satisfy some natural security properties related to the agent forwarding.

1.2 Related Works

We introduce the composition problem through a process algebra: protocols are either build-
ing blocks (defined,e.g, with a transition system) or composed using parallel and sequential
composition, and replication. This prevents from committing to any particular programming
language, while keeping a clean operational semantics. This approach is also advocated in [10],
which follows a similar approach. Other works on composition (e.g., [5, 7]) rely on specific
execution models.

Our starting idea, to prove a component w.r.t. a stronger attacker that has access to the
context, is not new. This is the basis of many works, including [8–10,18]. The main difference,
that we wish to emphasize, is that these works do not support long term shared secrets, used
in different components. Notably, the oracles of [10] are only used to decompose protocols
with state passing. Our notion of simulatability allows sharing long term secret by granting
the attacker access to oracles that depend on the secrets (for instance, signing oracles). It also
allows a symmetric treatment for proofs of a protocol and proofs of its context.

For several specific problems, typically key exchanges, there are composition results allow-
ing to prove independently the key exchange protocol and the protocol that uses the exchanged

5



key [8, 9, 13, 18, 19]. In such examples, the difficulty also comes from the shared secret, es-
pecially when there is a key confirmation step. In that case, the derived key is used for an
integrity check, which is part of the key exchange. Then the property of the key exchange:
“the key is indistinguishable from a random” does not hold after the key confirmation and
thus cannot be used in the security proof of the protocol that uses this exchanged key. In [8],
the authors define the notion of key independent reduction, where, if an attacker can break
a protocol for some key distribution, he can break the primitive for the same distribution of
the key. This is related to our notion of simulatability, as interactions with shared secrets
are captured by an oracle for fixed values of the key, and thus attacks on the protocol for
a fixed distribution are naturally translated into attacks against the primitive for the same
distribution. Key exchanges with key confirmation are therefore a simple application of our
composition results. Along the same line, [19] extends [18] to multi staged key exchanges,
where multiple keys might be derived during the protocol. While we do not directly tackle
this in our paper, our framework could be used for this case.

The authors of [9] also provide results allowing for the study of key renewal protocols (which
we capture with the sequential replication Theorem), and has the advantage to be inside a
mechanized framework, while we only cast our results inside a mechanizable framework. It
does not however consider key confirmations.

The UC framework initiated by [1] and continued in [3, 4, 6] is a popular way of tackling
composition. As explained above, this follows a “bottom-up” approach, in which protocols
must be secure in any context, which often yield very strong security properties, some of
which are not met in real life protocols. Moreover, to handle multiple sessions of a protocol
using a shared secret, joint-state theorems are required. This requires a tagging mechanism
with a distinct session identifier (sid) for each session. Relaxing this condition, the use of
implicit session identifiers was established in [20] for the UC framework, ideas continued in [13]
for Diffie-Hellman key exchanges, where they notably provide a proof of the ISO 9798-3 [17]
protocol.

We do not consider a composition that is universal: it depends on the context. This allows
us to relax the security properties regarding the protocol, and thus prove the compositional
security of some protocols that cannot be proved secure in the UC sense. We also rely on
implicit sids to prove the security of multiple sessions. Some limitations of the UC framework
are discussed in [18, Appendix A].

In [5], the authors also address the flexibility of UC (or reactive simulatability) showing how
to circumvent some of its limitations. The so-called “predicates” are used to restrict the order
and contents of messages from environment and define a conditional composability. Assuming
a joint-state conditional composability theorem, secret sharing between the environment and
the protocol might be handled by restricting the accepted messages to the expected use of the
shared secrets. However, the framework does not cover how to prove the required properties
of (an instance of) the environment.

Protocol Composition Logic is a formal framework [21] designed for proving, in a “Dolev-
Yao model”, the security of protocols in a compositional way. Its computational semantics is
very far from the usual game-based semantics, and thus the guarantees it provides [22] are
unclear. Some limitations of PCL are detailed in [23].

The compositional security of SSH, in the sense of [18], has been studied in [24]. They do
not consider however the agent forwarding feature. It introduces important difficulties since
the key exchange is composed with a second key exchange that uses both the first derived key
and the same long term secrets. SSH has also been studied, without agent forwarding, in [25],

6



where the implementation is derived from a secure modelling in CryptoVerif [26].
Summing up, our work is strongly linked to previous composition results and captures

analogues of the following notions in our formalism: implicit disjointness of local session
identifiers [20], single session games [18], key-independent reductions [8] and the classical
proof technique based on pushing part of a protocol inside an attacker, as recently formalized
in [10]. We build on all these works and additionally allow sharing long term secrets, thanks
to a new notion of O-simulatability. This fits with the CCSA model: the formal proofs
of composed protocols are broken into formal proofs of components. All these features are
illustrated by a proof of SSH with (a modified) agent forwarding.

2 Protocols and Indistinguishability

We first recall some features of the CCSA model. Although this model is not used until the
case studies, it may be useful for an easier understanding of the protocol semantics.

2.1 Syntax and semantics of terms

To enable composition with long term shared secrets, we must be able to specify precisely
the shared randomness between protocols. We use symbols from an alphabet of names, to
represent the random samplings. The same symbol used twice represents the same (shared)
randomness. Those names can be seen as pointers to a specific randomness, where all the
randomness has been sampled upfront at the beginning of the protocol. This idea stems from
the CCSA model [11], from which we re-use exactly the same term semantics. This is one of
the reason why our results, while applicable in a broader context, fit naturally in the CCSA
model. Let us recall the syntax and semantics of terms drawn from the CCSA model.

Syntax We use terms built over explicit names to denote messages computed by the protocol.
The terms are defined with the following syntax:

t ::= n names
| n~i indexed names
| x variable
| f(t1, . . . , tn) operation of arity n

A key addition to the CCSA model is that some names can be indexed by sequences of
index variables. This is necessary so that we may later on consider the replication of protocols.
When a replicated protocol depends on a name ni, the first copy (session) of the protocol uses
n1, the second n2, . . . . Names without index models randomness shared by all sessions of
the protocol. Variables are used to model the attacker inputs, and function symbols allows to
model the cryptographic computations.

Semantics Terms are interpreted as bitstrings. As in the computational model, the inter-
pretation depends on some security parameter Ρ. As we assume that all the randomness is
sampled at the beginning, the interpretation depends on an infinitely long random tape ρs.
We then leverage the notion of a cryptographic library1, that provides an interpretation for

1This corresponds in the CCSA model to the notion of functional model.

7



all names and function symbols. A cryptographic library Mf provides for each name n a
Probabilistic Polynomial Time Turing Machine (PPTM for short) An, that is given access to
the random tape ρs. As an additional input, all machines will always be given the security
parameter in unary. Each An extracts a bit-string of length Ρ from the random tape. Different
names extract non-overlapping parts of the random tape. In the interpretation, we give to all
the PPTM the same random tape ρs, so each name is always interpreted with the same value
in any term (and thus any protocol), and all names are interpreted independently.
Mf also provides for each function symbol f (encryption, signature,...) a PPTM Af , that

must be deterministic. To model randomized cryptographic primitives, additional randomness
must be given to the function symbol as extra names (cf. Example 2.1).

Given Mf , the semantic mapping [[¡]]Ρ,σρs evaluates its argument, a formal term, given an
assignment σ of its variables to bit-strings and a random tape ρs. For instance, if n is a
name, [[n]]Ρρs = An(1Ρ, ρs) (extracts a bit-string of length Ρ from the random tape ρs) and
[[sign(x, k)]]

η,{x 7→m}
ρs = Asign(m,Ak(1Ρ, ρs)). The details about the syntax and semantic of

messages can be found in Appendix A.

2.2 Syntax of the protocols

The summary of the protocol syntax is given in Figure 1. An elementary protocol models a
thread running on a specific computer. let denotes variable binding inside a thread, in(c, x)
(resp. (out(c,m)) denotes an input (resp. an output) of the thread over the channel c, where
all channels are taken out of a set C. For simplicity, channel identifiers are constants or indexed
constants. In particular, they are known to the attacker. The if then else constructs denotes
conditionals, 0 is a successfully terminated thread and ⊥ is an aborted thread.

For protocols, our goal is to state and prove general composition results: we first consider
sequential composition (the ; operator), where 0;P reduces to P , while ⊥;P reduces to ⊥.
In most cases, we will omit 0. We also consider parallel composition (the ‖ operator), a
fixed number N of copies running concurrently ‖i≤N , as well as an arbitrary number of copies
running concurrently ‖i. For instance, we can express a (two-parties) key-exchange consisting
of an initiator I and a responder R with I‖R, the key exchange followed by a protocol using
the exchanged key (I;P I)‖(R;PR), as well as any number of copies of the resulting protocol
running in parallel: ‖i((I;P I)‖(R;PR)). We can also consider an arbitrary iteration of a
protocol, “;i”, which could be used for expressing, for instance, key renewal.

We provide in Appendix B a full definition of the protocol algebra. For generality, the full
algebra is also parameterized by some atomic protocols, that can be used to easily extend the
syntax.

We allow terms inside a protocol to depend on some free variables and, in this case, we
denote P (x1, . . . , xn) a protocol, which depends on free variables x1, . . . , xn. P (t1, . . . , tn)
denotes the protocol obtained when instantiating each xi by the term ti.

We denote N (P ) (resp C(P )) the set of names (resp. channel names) of P .

Example 2.1. Given a randomized encryption function enc, we let P (c, x1, x2) be the protocol
in(c, x).out(c, enc(x, x1, x2)). Given names sk, r representing respectively a secret key and
a random seed, EN := ‖i≤NP (ci, ri, sk) is then the protocol allowing the attacker to obtain
cyphertexts for an unknown secret key sk. Unfolding the definitions, we get:

EN := P (c1, r1, sk)‖ . . . ‖P (cn, rn, sk)

The generalization giving access to encryption for five secret keys is expressed with ‖i‖j≤5P (cj,i, rj,i, skj).

8



elementary protocols:
Pel ::= let x = t in Pel variable binding

| in(c, x).Pel input
| out(c,m).Pel output
| if s = t then Pel else Pel conditional
| 0 success
| ⊥ failure

protocols:
P, P ′ ::= Pel

| Pel;P sequential composition
| P‖P ′ parallel composition
| ‖i≤NP bounded replication
| ‖iP unbounded replication

Figure 1: The protocol algebra

φ, (P, σ) −→
A

φ′, (P ′, σ′)

φ, (P ;Q, σ) −→
A

φ′, (P ′;Q, σ′) φ, (0;Q, σ) −→
A

φ, (Q, σ)

φ, (P, σ) −→
A

φ′, (P ′, σ′)

φ, (P, σ)‖E −→
A

φ′, (P ′, σ′)‖E

Figure 2: Operational Semantics (excerpt)

2.3 Semantics of the protocols

We give here some essential features of the formal execution model, which we need to formalize
our composition results.

A (global) state of a protocol consists in a frame, which is a sequence of bit-strings mod-
elling the current attacker knowledge, and a finite multiset of pairs (P, σ), where P is a protocol
and σ is a local binding of variables. Intuitively, each of the components of the multiset is the
current state of a running thread. We write such global states φ, (P1, σ1)‖ · · · ‖(Pn, σn).

The transition relation between global states is parameterized by an attacker A who inter-
acts with the protocol, modelled as a PPTM with its dedicated random tape ρr. The attacker
chooses which of the threads is going to move and computes, given φ, the input to that thread.
In the following, the configuration of the protocol and the security parameter are (also) always
given to the attacker, which we do not make explicit for simplicity.

We give some of the rules describing the Structural Operational Semantics in Figure 2. The
full semantics can be found in Appendix B. The transition relation −→

A
between configurations

depends on the attacker A, the security parameter Ρ and the random samplings ρs (to interpret
terms) and ρr (the randomness of the attacker). In P ;Q, P has to be executed first. When it
is completed (state 0), then the process can move to Q, inheriting the variable bindings from
P . If P is not waiting for an input from the environment, it can move independently from
any of the other parallel processes.

9



The semantics of inputs (not detailed for simplicity) reflects the interactions with the
attacker. A computes the input to the protocol, given a frame φ and its own random tape
ρr. Therefore transitions depend not only on the attacker machines, but also2 on the name
samplings ρs (secret coins) and ρr (attacker’s coins).

Example 2.2. Continuing Example 2.1, the initial configuration corresponding to E2 is
∅, (P (c1, r1, sk), ∅)‖(P (c2, r2, sk), ∅), where the attacker knowledge is empty and no local vari-
ables are bound. We consider one of the possible reductions, for some attacker A that first
sends a message over channel c1 and then c2:

∅, (P (c1, r1, sk), ∅)‖(P (c2, r2, sk), ∅)
−→
A
∅, (out(c1, enc(x, r1, sk), {x 7→ m})‖(P (c2r2, sk), ∅)

m = A(∅, ρr) is the first input
message computed by the attacker

−→
A

φ, (P (c2, r2, sk), ∅)

φ = [[enc(x, r1, sk)]]
η,{x 7→m}
ρs is the

interpretation of the output
received by the attacker

−→
A

φ, (out(c2, enc(x, r1, sk), {x 7→ m2})
m2 = A(φ, ρr) is the second input
message computed by the attacker

−→
A

(φ, [[enc(x, r2, sk)]]
η,{x 7→m2}
ρs ),0

We assume action determinism of the protocols [27]: given an input message on a given
channel, if the current state is

φ, (P1, σ1)‖ · · · ‖(Pn, σn),

at most one of the Pi may move to a non-abort state. This means that each thread checks
first that it is the intended recipient of the message. This also means that each output has to
be triggered by an input signal: none of the Pi starts with an output action. We remark that
in practice, protocols are action determinate.

For replicated protocols ‖i≤NP or ‖iP , the names in P that are indexed by the variable i
are renamed as follows: ‖i≤NP is the protocol P{i 7→ 1}‖ . . . ‖P{i 7→ N} and

φ, (‖iP, σ)‖E −→
A

φ, (‖i≤A(ρr,φ)P, σ)‖E.

In other words, the attacker chooses how many copies of P will be considered, which may
depend, in particular, on the security parameter. A(ρr, φ) must be a natural number in
unary.

2.4 Stateless Oracle Machines

For reasons that have been explained in the introduction, we wish to extend the semantics of
protocols and their indistinguishability to attackers that have access to an additional stateless
oracle. At this stage, we need stateless oracles in order to be compositional. Let us explain

2They actually also depend on the oracle’s coins, when A is interacting with an external oracle, which we
explain later.

10



this. Assume we wish to prove a property of R in the context P‖Q‖R. The idea would be to
prove R, interacting with an attacker that simulates P‖Q. This attacker is itself a composition
of an attacker that simulates P and an attacker that simulates Q. The protocols P , Q, R
share primitives and secrets, hence the simulation of P,Q requires access to an oracle that
holds the secrets. If such an oracle were to be stateful, we could not always build a simulator
for P‖Q from simulators of P,Q respectively, since oracle replies while simulating Q could
depend on oracle queries made while simulating P , for instance.

The oracles depend on a security parameter Ρ (that will not always be explicit), (secret)
random values and also draw additional coins: as a typical example, a (symmetric key) en-
cryption oracle will depend on the key k and use a random number r to compute enc(m, r, k)
from its query m. Therefore, the oracles can be seen as deterministic functions that take two
random tapes as inputs: ρs for the secret values and ρO for the oracle coins.

Formally, oracles take as input tuples (m, r, s) where m is a finite sequence of bitstrings, r
is a handle for a random value and s is a handle for a secret value. r and s are respectively used
to extract the appropriate parts of ρO, ρs resp";"""date"",""2020-08-10T15:00:27Z""
""pdf:PDFVersion"",""1.4""
""pdf:docinfo:title"",""Oracle simulation: a technique for protocol composition with long term shared secrets""
""xmp:CreatorTool"",""HAL""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""Computer Science [cs], Computer Science [cs]/Cryptography and Security [cs.CR]""
""language"",""en""
""dc:format"",""application/pdf; version=1.4""
""pdf:docinfo:creator_tool"",""HAL""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""Oracle simulation: a technique for protocol composition with long term shared secrets""
""modified"",""2020-08-10T15:00:27Z""
""cp:subject"",""Computer Science [cs], Computer Science [cs]/Cryptography and Security [cs.CR]""
""pdf:docinfo:subject"",""Computer Science [cs], Computer Science [cs]/Cryptography and Security [cs.CR]""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""Hubert Comon, Charlie Jacomme, Guillaume Scerri""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.21 (TeX Live 2020/Debian) kpathsea version 6.3.2""
""meta:author"",""Hubert Comon, Charlie Jacomme, Guillaume Scerri""
""trapped"",""False""
""meta:creation-date"",""2021-04-20T10:58:26Z""
""created"",""2021-04-20T10:58:26Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2021-04-20T10:58:26Z""
""resourceName"",""main.pdf""
""Author"",""Hubert Comon, Charlie Jacomme, Guillaume Scerri""
""producer"",""PDFLaTeX""
""pdf:docinfo:producer"",""PDFLaTeX""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""1"",""0"",""0"",""2"",""0"",""0"",""1"",""13"",""21"",""20"",""7"",""8"",""17"",""5"",""7"",""3"",""10"",""1"",""14"",""23"",""38"",""11"",""2"",""2"",""1"",""21"",""39"",""21"",""6"",""73"",""46"",""18"",""0"",""7"",""9"",""18"",""36"",""6"",""32"",""8"",""25"",""8"",""10"",""25"",""12"",""20"",""48"",""0"",""12"",""6"",""2"",""22"",""5"",""8"",""0"",""6"",""0"",""0"",""0"",""4"",""6"",""26"",""21"",""0"",""5"",""6"",""8"",""20"",""8"",""5"",""2"",""28"",""111"",""9"",""19"",""14"",""33"",""19"",""20"",""32"",""16"",""4"",""9"",""20"",""16"",""19"",""28"",""23"",""22"",""13"",""29"",""30"",""26"",""37"",""13"",""6"",""38"",""18"",""17"",""16"",""16"",""35"",""16""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""Hubert Comon, Charlie Jacomme, Guillaume Scerri""
""dcterms:created"",""2021-04-20T10:58:26Z""
""Last-Modified"",""2020-08-10T15:00:27Z""
""dcterms:modified"",""2020-08-10T15:00:27Z""
""title"",""Oracle simulation: a technique for protocol composition with long term shared secrets""
""Last-Save-Date"",""2020-08-10T15:00:27Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2020-08-10T15:00:27Z""
""meta:save-date"",""2020-08-10T15:00:27Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.21 (TeX Live 2020/Debian) kpathsea version 6.3.2""
""Content-Length"",""1508439""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Hubert Comon, Charlie Jacomme, Guillaume Scerri""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""104""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""853"",""1721"",""1531"",""1848"",""3015"",""3164"",""3363"",""2408"",""3070"",""1718"",""1957"",""2718"",""2007"",""2453"",""2508"",""2493"",""2553"",""1870"",""1734"",""1648"",""1883"",""2080"",""2180"",""2544"",""2782"",""2234"",""1636"",""1999"",""1860"",""2395"",""1814"",""1702"",""2190"",""2226"",""2030"",""2151"",""2153"",""2413"",""2482"",""1729"",""2340"",""1935"",""2355"",""2373"",""1319"",""2428"",""1549"",""1384"",""1802"",""1719"",""1578"",""2372"",""2345"",""2422"",""2399"",""2444"",""2287"",""2401"",""2626"",""2191"",""1964"",""1702"",""603"",""1382"",""1105"",""1700"",""1173"",""1344"",""1630"",""2260"",""1950"",""983"",""1492"",""1403"",""1891"",""1775"",""1773"",""1780"",""1319"",""1205"",""1394"",""1570"",""1174"",""1499"",""1918"",""1762"",""2013"",""1410"",""1281"",""993"",""956"",""1176"",""1493"",""1359"",""1505"",""939"",""1032"",""1335"",""878"",""978"",""1094"",""1001"",""2129"",""1211""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2021-04-20T10:58:26Z""
";https://scholar.google.ch/scholar?start=870&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098769-120;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;[PDF][PDF] Developing Seclusion and Protection in Distributing Multi-authority Feature-based Encryption in Cloud Computing;DS Reddy, B Jyothi ; junikhyat.com;;"… GP are and a generator. The random oracle functions are also included. Authority Setup … 29-40,

March 2016. 7. X. Boyen, B. Waters, “Anonymous hierarchical identity-based encryption (without

random oracles),” in Proc. CRYPTO, Santa Barbara, California, USA, August …";Autres articles;Version HTML;[PDF] junikhyat.com;http://www.junikhyat.com/no_14_may_20/51.pdf;"This site requires Javascript to work, please enable Javascript in your browser or use a browser with Javascript support
";"""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""Content-Encoding"",""ISO-8859-1""
""resourceName"",""51.pdf""
""language"",""en""
""Content-Length"",""847""
""Content-Type"",""text/html; charset=ISO-8859-1""
";https://scholar.google.ch/scholar?start=660&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098866-339;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;[PDF][PDF] Testing Smart Contracts;A Leid, M Christoph, JH Taljaard, J Geldenhuys… ;2020 scholar.sun.ac.za;;"… After the early success of Bitcoin [1], the first major cryptocurrency, some members of its community

started to investigate ways of running increasingly complex user applications on a public,

decentralised blockchain. One of the first and most popular cryptocurrency platforms to …";Cité 1 fois;Les 2 versions;[PDF] sun.ac.za;https://scholar.sun.ac.za/bitstream/handle/10019.1/108088/leid_testing_2020.pdf?sequence=2;"
Testing Smart Contracts

by

Alexander Leid

Thesis presented in partial fulfilment of the requirements
for the degree of Master of Science (Computer Science) in

the Faculty of Science at Stellenbosch University

Supervisor: Prof. AB van der Merwe

Co-supervisor: Prof. W Visser

March 2020

The financial assistance of the Council for Scientific and Industrial Research (CSIR) is hereby
acknowledged.



Declaration

By submitting this thesis electronically, I declare that the entirety of the work
contained therein is my own, original work, that I am the sole author thereof
(save to the extent explicitly otherwise stated), that reproduction and pub-
lication thereof by Stellenbosch University will not infringe any third party
rights and that I have not previously in its entirety or in part submitted it for
obtaining any qualification.

March 2020
Date: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Copyright Š 2020 Stellenbosch University 
All rights reserved.

i

Stellenbosch University https://scholar.sun.ac.za



Abstract

Testing Smart Contracts

A. Leid

Computer Science Division,
Department of Mathematical Sciences,

University of Stellenbosch,
Private Bag X1, 7602 Matieland, South Africa.

Thesis: MSc (Computer Science)

March 2020

There have been several high-profile exploits of smart contracts running on the 
Ethereum Virtual Machine (EVM) over the last few years since the re-lease of 
Ethereum. Many of these exploits were introduced via programmer error and 
could be avoided by proper auditing beforehand. Security analysis tooling has 
advanced in this space to aid developers and auditors to auto-matically find 

these exploits and in some cases generate test input that can recreate the 
exploit. In this work, we review the most critical vulnerabili-ties currently 

present in the EVM ecosystem and provide best practices and forms of 
prevention. Taxonomies (new and existing) are presented to cate-gorise the 
type of smart contract exploits present at the application layer and compare 
them to similar exploits in imperative programs. Automated testing tools are 
investigated and extended in areas where they may struggle to detect certain 
vulnerabilities and to synthesise adversarial smart contracts. Lastly, some of 

the most popular and actively developed automated testing tools are 
catalogued, evaluated, and benchmarked.

ii

Stellenbosch University https://scholar.sun.ac.za



Acknowledgements

First, I would like to thank my supervisors, Prof. Brink van der Merwe and
Prof. Willem Visser, for their expert insight, assistance, and guidance over the
course of my studies.

I would like to acknowledge the financial support of the CSIR for this work
and hope that they can continue enabling more students in this country to
pursue their postgraduate studies like I have.

Lastly, I would like to thank my family and friends for their unwavering
support throughout all my years of study and especially while preparing this
thesis.

iii

Stellenbosch University https://scholar.sun.ac.za



Contents

Declaration i

Abstract ii

Acknowledgements iii

Contents iv

List of Figures vii

List of Tables viii

1 Introduction 1
1.1 Testing Smart Contracts . . . . . . . . . . . . . . . . . . . . . 2
1.2 Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 Background 4
2.1 Ethereum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.1.1 Release Management . . . . . . . . . . . . . . . . . . . 4
2.1.2 Ether . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.3 Accounts and State . . . . . . . . . . . . . . . . . . . . 6
2.1.4 Transactions . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1.5 Messages . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1.6 Pre-compiled Contracts . . . . . . . . . . . . . . . . . . 8
2.1.7 The Ethereum Virtual Machine . . . . . . . . . . . . . 8

2.2 Solidity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2.1 Language Properties . . . . . . . . . . . . . . . . . . . 12
2.2.2 Basic Syntax . . . . . . . . . . . . . . . . . . . . . . . 12
2.2.3 Types . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.2.4 Functions . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.2.5 Storage Access . . . . . . . . . . . . . . . . . . . . . . 17
2.2.6 Built-in Functions and Variables . . . . . . . . . . . . . 19
2.2.7 Token Standards . . . . . . . . . . . . . . . . . . . . . 21

iv

Stellenbosch University https://scholar.sun.ac.za



CONTENTS v

2.3 Solidity Development and Testing . . . . . . . . . . . . . . . . 22
2.3.1 Test Network Clients . . . . . . . . . . . . . . . . . . . 23
2.3.2 Development Frameworks . . . . . . . . . . . . . . . . 23
2.3.3 Unit Testing . . . . . . . . . . . . . . . . . . . . . . . . 24
2.3.4 Integration Testing . . . . . . . . . . . . . . . . . . . . 24

2.4 Fuzzing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.4.1 Input Generation . . . . . . . . . . . . . . . . . . . . . 26
2.4.2 Execution Feedback . . . . . . . . . . . . . . . . . . . . 26

2.5 Symbolic Execution . . . . . . . . . . . . . . . . . . . . . . . . 26
2.5.1 Example Program . . . . . . . . . . . . . . . . . . . . . 27

3 Vulnerabilities 29
3.1 Vulnerability Taxonomies . . . . . . . . . . . . . . . . . . . . . 29
3.2 List of Vulnerabilities . . . . . . . . . . . . . . . . . . . . . . . 30

3.2.1 Integer Overflow . . . . . . . . . . . . . . . . . . . . . 30
3.2.2 Unchecked Call Return Value . . . . . . . . . . . . . . 31
3.2.3 Re-entrancy . . . . . . . . . . . . . . . . . . . . . . . . 33
3.2.4 Assert Violations . . . . . . . . . . . . . . . . . . . . . 35
3.2.5 DoS with Failed Call . . . . . . . . . . . . . . . . . . . 36
3.2.6 DoS with Block Gas Limit . . . . . . . . . . . . . . . . 38
3.2.7 DoS from Greedy State . . . . . . . . . . . . . . . . . . 40
3.2.8 Unauthorised Ether Withdrawal . . . . . . . . . . . . . 40
3.2.9 Unauthorised Self-destruct . . . . . . . . . . . . . . . . 41
3.2.10 Unauthorised Delegatecall . . . . . . . . . . . . . . . . 42
3.2.11 Transaction Order Dependence . . . . . . . . . . . . . 42
3.2.12 Authorisation Through Origin . . . . . . . . . . . . . . 44
3.2.13 Weak Sources of Randomness . . . . . . . . . . . . . . 44
3.2.14 Write to Arbitrary Storage Locations . . . . . . . . . . 45
3.2.15 Ether Invariants . . . . . . . . . . . . . . . . . . . . . . 47

3.3 Other Vulnerabilities and Bad Practices . . . . . . . . . . . . 48
3.3.1 Solidity Compiler Version Issues . . . . . . . . . . . . . 48
3.3.2 Deprecated Functions . . . . . . . . . . . . . . . . . . . 48
3.3.3 Unused or Uninitialised Variables . . . . . . . . . . . . 48
3.3.4 Use of Inline Assembly . . . . . . . . . . . . . . . . . . 49
3.3.5 Timestamp Dependency . . . . . . . . . . . . . . . . . 49
3.3.6 Signature Replay Attacks . . . . . . . . . . . . . . . . 49

4 Tools 50
4.1 Tool Taxonomies . . . . . . . . . . . . . . . . . . . . . . . . . 50
4.2 List of Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

4.2.1 Securify . . . . . . . . . . . . . . . . . . . . . . . . . . 52
4.2.2 Slither . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.2.3 MythX . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

Stellenbosch University https://scholar.sun.ac.za



CONTENTS vi

4.2.4 Echidna . . . . . . . . . . . . . . . . . . . . . . . . . . 56
4.2.5 Manticore . . . . . . . . . . . . . . . . . . . . . . . . . 59
4.2.6 Mythril . . . . . . . . . . . . . . . . . . . . . . . . . . 60

4.3 Other Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

5 Extensions 64
5.1 Framework Architecture . . . . . . . . . . . . . . . . . . . . . 64
5.2 Framework Implementation . . . . . . . . . . . . . . . . . . . 65

5.2.1 External Interfaces . . . . . . . . . . . . . . . . . . . . 65
5.2.2 Environmental Setup . . . . . . . . . . . . . . . . . . . 66
5.2.3 Vulnerability Detectors . . . . . . . . . . . . . . . . . . 67
5.2.4 Execution . . . . . . . . . . . . . . . . . . . . . . . . . 72
5.2.5 Validation . . . . . . . . . . . . . . . . . . . . . . . . . 72
5.2.6 Output . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

5.3 Limitations and Future Work . . . . . . . . . . . . . . . . . . 73

6 Evaluation 75
6.1 Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
6.2 Vulnerability Reporting Evaluation . . . . . . . . . . . . . . . 76

6.2.1 Contracts . . . . . . . . . . . . . . . . . . . . . . . . . 76
6.2.2 Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
6.2.3 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

6.3 Challenge Contract Evaluation . . . . . . . . . . . . . . . . . . 78
6.3.1 Contracts . . . . . . . . . . . . . . . . . . . . . . . . . 79
6.3.2 Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
6.3.3 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

6.4 Performance Evaluation . . . . . . . . . . . . . . . . . . . . . 80
6.4.1 Contracts . . . . . . . . . . . . . . . . . . . . . . . . . 80
6.4.2 Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
6.4.3 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

6.5 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

7 Conclusion 87
7.1 Testing Smart Contracts . . . . . . . . . . . . . . . . . . . . . 87
7.2 Limitations and Future Work . . . . . . . . . . . . . . . . . . 88
7.3 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

Bibliography 90

A Attacking Contract 98

Stellenbosch University https://scholar.sun.ac.za



List of Figures

2.1 Symbolic execution tree of the example swapping function show-
ing the symbolic variables stored in memory and current path
condition at each state. . . . . . . . . . . . . . . . . . . . . . . . 28

5.1 Structure of the symbolic execution framework outlining the ma-
jor components. . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

vii

Stellenbosch University https://scholar.sun.ac.za



List of Tables

2.1 List of major Ethereum forks. . . . . . . . . . . . . . . . . . . . 5
2.2 List of pre-compiled contracts as of Byzantium. . . . . . . . . . 8
2.3 List of EVM opcodes related to control flow. . . . . . . . . . . . 9
2.4 List of EVM opcodes related to arithmetic and mathematical op-

erations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.5 List of EVM opcodes related to environmental and call data. . . 10
2.6 List of EVM opcodes related to storage and memory functions. . 11
2.7 List of EVM opcodes related to messaging. . . . . . . . . . . . . 12
2.8 List of block variable properties. . . . . . . . . . . . . . . . . . 19
2.9 List of msg variable properties. . . . . . . . . . . . . . . . . . . . 20
2.10 List of tx variable properties. . . . . . . . . . . . . . . . . . . . 20
2.11 List of Solidity messaging functions for payable addresses. . . . 21
2.12 List of ERC-20 token standard functions. . . . . . . . . . . . . . 22

3.1 Taxonomy of vulnerabilities based on the level that they are in-
troduced at and severity. . . . . . . . . . . . . . . . . . . . . . . 30

3.2 Taxonomy of vulnerabilities grouped according to categories. . . 31

4.1 General feature classification of all the tools considered. . . . . . 51
4.2 Vulnerability classification of all the tools considered. The MythX

vulnerabilities marked “Pro” are only available in the paid sub-
scription tier. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

4.3 Mapping between our vulnerability names and the closest Securify
property names. . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

4.4 List of built-in security properties checked by Securify. . . . . . 54
4.5 Mapping between our vulnerability names and the closest Slither

detector names. . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
4.6 List of Slither’s built-in vulnerability detectors. . . . . . . . . . 57
4.7 List of Slither’s built-in informational and optimisation detectors. 58
4.8 List of SWC registry entries checked by the free tier of MythX. . 58
4.9 List of SWC registry entries checked by the premium tier of MythX. 59
4.10 Mapping between our vulnerability names and the closest Manti-

core detector names. . . . . . . . . . . . . . . . . . . . . . . . . 61

viii

Stellenbosch University https://scholar.sun.ac.za



LIST OF TABLES ix

4.11 List of built-in Manticore detectors. . . . . . . . . . . . . . . . . 62
4.12 List of SWC registry entries checked by Mythril Classic. . . . . 62

6.1 List of vulnerabilities chosen for evaluation and the number of
vulnerability occurrences included in each test suite. . . . . . . . 77

6.2 Results for the vulnerability detector evaluation. The number of
successful detections is shown for each tool compared to the total
number of contracts in each respective data set. . . . . . . . . . 78

6.3 List of benchmarks in the Capture the Ether data set. Includes
the number of contracts (C), functions (F), and lines of code
(LoC) contained in each file. The approximate number of trans-
actions (T) required to complete the level is also shown. . . . . . 80

6.4 List of benchmarks in the Ethernaut data set. Includes the num-
ber of contracts (C), functions (F), and lines of code (LoC) con-
tained in each file. The approximate number of transactions (T)
required to complete the level is also shown. . . . . . . . . . . . 81

6.5 Capture the Ether benchmark results for each tool. . . . . . . . 82
6.6 Ethernaut benchmark results for each tool. . . . . . . . . . . . . 83
6.7 Top 20 ERC-20 tokens according to their market cap (volume

times approximate price in USD) on 2019/12/15. The length
of the contract initialisation bytecode (bytes), and lines of code
(LoC) in Solidity is also shown. . . . . . . . . . . . . . . . . . . 84

6.8 Mythril performance results for the real-world token contract set.
The coverage percentage, number of reported errors, and execu-
tion time is shown for three separate runs with a limit of 1, 2 and
3 transactions (TX). . . . . . . . . . . . . . . . . . . . . . . . . 85

6.9 Manticore+ performance results for the real-world token contract
set. The coverage percentage, number of reported errors, and
execution time is shown for one transaction. Empty results failed
to initialise the contract using Solidity 0.4.25. . . . . . . . . . . 86

Stellenbosch University https://scholar.sun.ac.za



Chapter 1

Introduction

After the early success of Bitcoin [1], the first major cryptocurrency, some
members of its community started to investigate ways of running increasingly
complex user applications on a public, decentralised blockchain. One of the
first and most popular cryptocurrency platforms to focus specifically on this
trait is Ethereum.

Ethereum is a distributed computational platform that allows users to run
programs known as smart contracts, first conceived by Nick Szabo in the
1990s [2], that can autonomously respond to human blockchain interactions ac-
cording to a programmed set of rules [3]. Unlike Bitcoin, the scripting instruc-
tion set available at runtime in Ethereum is designed to be Turing-complete
in theory, but practically limited by a maximum computational allowance.

One key aspect of the Ethereum platform is that once a contract is deployed
by the user, the contract’s instruction code will not be able to be altered
any further. Naturally this immutability can spell disaster when combined
with program bugs originating from user error and the handling of monetarily
significant cryptocurrency assets.

The most infamous example of a smart contract bug causing extreme loss
of monetary value is that of The DAO, a Decentralised Autonomous Organi-
sation (DAO) designed to offer decentralised governance of enterprise organi-
sations [4]. As a result of an overlooked software bug, a single user was able to
steal roughly 3.6 million Ether [5], which at the time was worth approximately
$50 million.

Vulnerabilities like that of The DAO hack do not exploit any bugs or issues
in the platform itself, but instead rely on unintentional, yet programmatically
valid behaviour written by the smart contract developers. With this large
amount of room for error, the onus is on the developers to ensure that their
contracts are sufficiently tested and audited for vulnerabilities before deploy-
ment.

1

Stellenbosch University https://scholar.sun.ac.za



CHAPTER 1. INTRODUCTION 2

1.1 Testing Smart Contracts

A smart contract developer has many options at their disposal to ensure that
a contract is sufficiently tested for vulnerabilities before it is permanently de-
ployed to the blockchain.

Generally the first method of testing smart contracts would be to write unit
and integration tests. Solidity, a popular high-level smart contract language
targeting the Ethereum runtime environment [6], already has a mature testing
framework in the form of Truffle [7] that is well supported by its community
and allows developers to test against a local test Ethereum network.

There are, however, an increasing number of automatic testing and security
analysis tools that are available to smart contract developers and auditors.
These tools can be used to quickly cover large amounts of code and find bugs,
like that of The DAO hack, without any user input or guidance.

In this work we first investigate and survey the common vulnerabilities
that exist in the Ethereum application layer. With a computational environ-
ment like Ethereum that is constantly being developed, it is common that
some software vulnerabilities may be phased out with new updates. Although
it is impossible to catalogue each and every possible vulnerability, since one
application’s bug may be another’s feature, we can at least attempt to narrow
down the ones that are generally considered to be an issue.

Next we survey the security analysis tools at our disposal and note the
types of vulnerabilities that each claims to identify. We take the time to
investigate the use of these tools and also extend one of them, the Manticore
symbolic execution tool [8], thus demonstrating how it can be used during the
auditing process to find bugs that are extremely difficult to catch with manual
inspection.

Lastly, we evaluate these tools to determine how effective they are in auto-
matically detecting certain vulnerabilities and how efficient they are in covering
the code of larger contracts.

1.2 Contributions

The following contributions are made as part of this work:

1. Cataloguing the vulnerabilities and security analysis tools present in the
Ethereum ecosystem:

• Identification of the most severe smart contract vulnerabilities and
methods of preventing them;

• Identification of the most popular automated security analysis tools;

• Taxonomisation of vulnerabilities based on common grouping cri-
teria; and

Stellenbosch University https://scholar.sun.ac.za



CHAPTER 1. INTRODUCTION 3

• Taxonomisation of tooling according to vulnerability classification.

2. Investigating the use of the Manticore symbolic analysis tool in our own
framework, Manticore+:

• Modelling key elements of the Ethereum ecosystem symbolically;

• Automatically detecting a variety of vulnerabilities; and

• Synthesising attacking smart contracts used as part of exploit se-
quences.

3. Evaluating the effectiveness and efficiency of the investigated security
analysis tools:

• Comparing their effectiveness when automatically detecting vulner-
abilities;

• Analysing their ability to reach invariant states; and

• Investigating performance and efficiency when applied to contracts
from the main Ethereum network.

1.3 Overview

Following this introductory chapter, Chapter 2 provides the reader with back-
ground information on Ethereum, the Solidity programming language, fuzz
testing tools and symbolic execution. Chapter 3 then explains each inves-
tigated Ethereum vulnerability in-depth (with examples) and demonstrates
prevention methods and best practices to avoid them. Then we present a list
of state-of-the-art security analysis tools in Chapter 4 that is able to automat-
ically detect these vulnerabilities. Next, Chapter 5 demonstrates how one of
these tools, Manticore, can be used as part of a framework and extended to
perform advanced security analysis and exploit synthesis. We then evaluate
all these tools in terms of their efficiency and effectiveness in Chapter 6, before
finally concluding the thesis in Chapter 7.

Stellenbosch University https://scholar.sun.ac.za



Chapter 2

Background

This chapter serves to give the reader a brief overview of the Ethereum platform
and its most popular programming language Solidity, as well as an explanation
of the testing and verification methodologies presented later in this thesis.

Vulnerabilities specific to Ethereum and its smart contracts will be dis-
cussed separately in Chapter 3, but will assume a basic understanding of the
system as presented in this chapter. Tool-related discussions will only appear
afterwards in Chapter 4 to keep the background sections tool-agnostic.

2.1 Ethereum

Ethereum is a distributed computing platform hosted on a public, open-source
blockchain initially proposed by Vitalik Buterin in a white paper written in
2013 [3]. This platform allows users to run programs, known as smart con-
tracts, within an environment similar to the Bitcoin blockchain [1].

The key difference is that the scripting language for Bitcoin transactions,
known as Script [9], is intentionally designed to not be Turing-complete or to
keep track of an inter-transactional state and can thus not be used to run the
complex user applications intended to run on Ethereum.

2.1.1 Release Management

As with many other cryptocurrency platforms, Ethereum is constantly devel-
oping and must always be ready to respond to new challenges and feedback
from its community. Some of the more significant system milestones such as
changes to the consensus protocol were planned from the start, while other
modifications to the standard may be proposed by users via an Ethereum Im-
provement Proposal (EIP). Table 2.1 lists some of the major upgrades that
implement various milestones and EIPs as part of a hard fork [10].

4

Stellenbosch University https://scholar.sun.ac.za



CHAPTER 2. BACKGROUND 5

In the past the Ethereum community has also responded to major secu-
rity breaches by implementing forks in the codebase and blockchain. One
such example is the hard fork implemented after the DAO hack, allowing
users to retrieve their funds from a curator contract [11], which subsequently
also spawned the Ethereum Classic platform as a continuation of the original
blockchain.

For the purposes of this thesis, we are only concerned with the impact that
major releases have on the vulnerabilities discussed and whether or not the
testing and verification tools are compatible with the latest version. Testing
and symbolic execution frameworks that emulate the EVM are generally not
affected by changes related to mining and consensus protocols, but must be
brought up to date with changes directly affecting program execution (e.g.
adding additional opcodes or changing the way fees are handled).

# Date Name
0 2015-07-30 Frontier
1 2015-09-07 Frontier Thawing
2 2016-03-14 Homestead
3 2016-07-20 After DAO attack
4 2016-10-18 Tangerine Whistle
5 2016-11-22 Spurious Dragon
6 2017-10-16 Byzantium
7 2019-02-28 Constantinople

Table 2.1: List of major Ethereum forks.

2.1.2 Ether

Ethereum also features a tradeable cryptocurrency token called Ether. Each
account, whether owned by a user or operating as a smart contract, may have a
balance of Ether and trade it freely with other accounts. Developers may also
program additional behaviour in their smart contracts that acts on incoming
transactions that send Ether.

Ether doubles as a currency used to pay for computation performed by
smart contracts, known as the gas fee, whereby the cost of each transaction is
relative to the total cost of each instruction executed by the EVM.

The currency has a zero decimal precision, with a single base unit referred
to as Wei. This is typically the unit of measurement when denoting transaction
fees. Since these fees are orders of magnitude smaller than the amount of Wei
mined per transaction, additional denominations were introduced as per the
Ethereum white paper [3]:

Stellenbosch University https://scholar.sun.ac.za



CHAPTER 2. BACKGROUND 6

100: Wei

1012: Szabo

1015: Finney

1018: Ether

Amounts transferred between parties are therefore also generally denoted in
Ether.

2.1.3 Accounts and State

The world state in the context of Ethereum is described as a mapping between
20-byte addresses, known as accounts, and their account states [12]. The
account state is defined as follows:

• A nonce value indicating the number of transactions signed or contracts
instantiated by the account that increments each time;

• The Ether balance of the account in Wei;

• A 256-bit hash pointing to the account’s internal state storage; and

• An immutable hash of the EVM code of the account, if applicable.

These accounts are generally grouped into:

• User accounts that are controlled by a private key and possess no EVM
code of their own; and

• Contract accounts that contain code and act autonomously as defined
by this program.

The account nonce value ensures that users can not “double-spend” by sub-
mitting more than one transaction at the same time, since the nonce value will
increment between calls and therefore treat them as distinct messages.

2.1.4 Transactions

The world state of the Ethereum blockchain is modified by the application of a
successful transaction. Transactions are grouped into blocks which are mined
on average approximately every 12 seconds, as determined by the Ethereum
network’s current difficulty [13]. All fees associated with the block are paid by
the accounts submitting the transactions and rewarded to the account address
of the miner that successfully mined the block.

Ethereum transactions are specified to have the following parameters:

Stellenbosch University https://scholar.sun.ac.za



CHAPTER 2. BACKGROUND 7

• Fields representing the sender’s cryptographic signature;

• The nonce value of the sender;

• The recipient’s 20-byte address (empty during contract initialisation);

• The amount of Ether paid per unit of gas spent during execution (ex-
pressed in Wei);

• The maximum number of gas units the sender is willing to pay for;

• The amount of Ether sent with the transaction; and

• A byte array of unlimited size representing either optional call data or
the code of the newly created contract during contract initialisation.

Each instruction executed within the EVM and additional bytes of call data
costs a predetermined amount of gas, which is subtracted from the initial
starting gas value sent above. This amount of gas is then multiplied by the
gas price value specified in the transaction and paid upfront by the sender to
the miner. If execution halts gracefully, then all remaining gas is refunded to
the sender. Otherwise, the world state may be reverted without refunding any
gas to the sender. Ethereum also features a global gas limit per block as voted
on by miners.

2.1.5 Messages

Contracts within the Ethereum platform are able to send messages to other
contracts, similar to the transactions described earlier in Section 2.1.4. These
messages act like remote-process calls, but with subtle differences in the way
each contract’s storage is managed during execution. A call consists of the
following elements similar to a transaction:

• The sender of the message;

• The recipient;

• An Ether amount transferred;

• A data byte-array;

• Available gas; and

• The gas price.

Additionally, these messages contain:

• The sender of the initial block-level transaction (or originator);

Stellenbosch University https://scholar.sun.ac.za



CHAPTER 2. BACKGROUND 8

• The address of the account that contains the code that must be executed;

• The depth of the message call stack; and

• A flag to allow modifications to state.

These messages will return a byte-array value as output and behave similar to
transactions in terms of gas usage.

One important thing to note is that any changes made to the contract’s
storage preceding message calls will remain once the call is made. In other
words, the world state enters a sub-state during message execution and care
must be taken by the contract developer to ensure that it is not left in an invalid
state. The contract might be the recipient of another recursive message further
down the line if enough gas was passed to the recipient, which was the basis
for the infamous DAO attack.

2.1.6 Pre-compiled Contracts

There are a number of reserved addresses in Ethereum that implement fre-
quently used cryptographic functions that are callable by other contracts. The
number of these so-called pre-compiled contracts have increased with time and
are currently up to eight, as of the Byzantium release. The address and name
of the function is listed in Table 2.2, with a more technical description given
in the Yellow Paper [12].

Address Function
0x1 ECDSA signature recovery
0x2 SHA256 hash
0x3 RIPEMD160 hash
0x4 Identity
0x5 Modular exponentiation
0x6 Elliptic curve addition
0x7 Elliptic curve scalar multiplication
0x8 Elliptic curve pairing check

Table 2.2: List of pre-compiled contracts as of Byzantium.

2.1.7 The Ethereum Virtual Machine

The EVM is a stack-based virtual machine with a 256-bit word size and max-
imum stack depth of 1024. This specific word size was chosen because of its
use in various cryptographic functions often performed by the EVM.

Stellenbosch University https://scholar.sun.ac.za



CHAPTER 2. BACKGROUND 9

Control Flow

Control flow can be terminated with any of the instructions shown in Ta-
ble 2.3, along with the added side-effects of removing the contract from the
blockchain and transferring its Ether to the specified address in the case of
a SELFDESTRUCT. Any other opcode not defined in the specification will also
terminate execution of the current message, but not refund the remaining gas
to the caller.

Hex Code Mnemonic Description
00 STOP Stop execution
F3 RETURN Return a value to the current message

caller
FD REVERT Revert execution and returns the specified

value from memory
FF SELFDESTRUCT Terminates the current contract and trans-

fers its Ether balance to the specified ad-
dress

Table 2.3: List of EVM opcodes related to control flow.

Arithmetic Instructions

The arithmetic and mathematical operations included in Table 2.4 are all re-
turned modulo 2256 to the stack. High-level languages targeting the EVM, such
as Solidity, are able to further manipulate these values using additional instruc-
tions and truncate bits to effectively work with smaller word sizes. Division
by zero will return zero as per the yellow paper specification, but higher-level
languages generally halt execution in such cases.

Stellenbosch University https://scholar.sun.ac.za



CHAPTER 2. BACKGROUND 10

Hex Code Mnemonic Description
01 ADD Adds the top two elements on the stack,

modulo 2256

02 MUL Multiply the top two elements on the stack,
modulo 2256

03 SUB Subtracts the top two elements on the
stack, modulo 2256

04 DIV Division of the top two elements on the
stack

05 SDIV Unsigned division of the top two elements
on the stack

0A EXP Unsigned exponentiation of the top two el-
ements on the stack

20 SHA3 Keccak256 hash of the value at the specified
memory location

Table 2.4: List of EVM opcodes related to arithmetic and mathematical op-
erations.

Environmental Variables

Table 2.5 notes the opcodes related to some of the EVM-specific features, such
as information on the current message parameters or gas quotas.

Hex Code Mnemonic Description
30 ADDRESS Address of the current contract
31 BALANCE Ether balance of the specified address in

Wei
32 ORIGIN Address of the transaction originator
33 CALLER Address of the message sender
34 CALLVALUE Ether value of the message in Wei
3A GASPRICE Ether price per unit of gas for the current

message in Wei
40 BLOCKHASH Hash of the specified block
41 COINBASE Address of the current transaction fee ben-

eficiary
42 TIMESTAMP Timestamp of the current block
43 NUMBER Current block number
44 DIFFICULTY Current block difficulty
45 GASLIMIT Block gas limit
5A GAS Amount of remaining gas

Table 2.5: List of EVM opcodes related to environmental and call data.

Stellenbosch University https://scholar.sun.ac.z";"""date"",""2020-04-01T13:20:58Z""
""pdf:PDFVersion"",""1.6""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:docinfo:title"",""""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.6""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""xmp:CreateDate"",""2020-02-23T18:05:54Z""
""modified"",""2020-04-01T13:20:58Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""xmp:ModifyDate"",""2020-04-01T15:20:58Z""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017) kpathsea version 6.2.3""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2020-02-23T18:05:54Z""
""created"",""2020-02-23T18:05:54Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-02-23T18:05:54Z""
""resourceName"",""leid_testing_2020.pdf""
""Author"",""""
""producer"",""pdfTeX-1.40.18""
""pdf:docinfo:producer"",""pdfTeX-1.40.18""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2020-02-23T18:05:54Z""
""Last-Modified"",""2020-04-01T13:20:58Z""
""dcterms:modified"",""2020-04-01T13:20:58Z""
""title"",""""
""xmpMM:DocumentID"",""uuid:09923d55-3825-4fd7-97a0-9e691575874f""
""Last-Save-Date"",""2020-04-01T13:20:58Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2020-04-01T13:20:58Z""
""meta:save-date"",""2020-04-01T13:20:58Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017) kpathsea version 6.2.3""
""Content-Length"",""1231230""
""Content-Type"",""application/pdf""
""xmp:MetadataDate"",""2020-04-01T15:20:58Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""pdf:producer"",""pdfTeX-1.40.18""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""112""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""348"",""525"",""1361"",""510"",""976"",""1840"",""1432"",""320"",""1747"",""1633"",""1674"",""2084"",""1367"",""1475"",""1806"",""1427"",""1480"",""1520"",""1089"",""1230"",""1196"",""1747"",""1657"",""1239"",""1627"",""1940"",""990"",""1042"",""1606"",""1850"",""1953"",""1635"",""1689"",""1523"",""1636"",""1860"",""1657"",""432"",""1519"",""1443"",""1657"",""1396"",""2222"",""1194"",""1674"",""1957"",""1581"",""1049"",""1562"",""2192"",""1980"",""2025"",""895"",""1690"",""1813"",""867"",""1890"",""2054"",""1447"",""1341"",""1324"",""1992"",""782"",""2289"",""2150"",""1543"",""1686"",""1796"",""1622"",""2172"",""1589"",""1395"",""1791"",""1438"",""1229"",""2344"",""1760"",""1368"",""2008"",""2082"",""1866"",""2122"",""1906"",""254"",""1281"",""1651"",""1572"",""2011"",""2213"",""1367"",""1313"",""1599"",""1375"",""2017"",""1559"",""630"",""1669"",""2458"",""1527"",""1408"",""1657"",""1794"",""1931"",""1904"",""2066"",""1914"",""483"",""686"",""492"",""1503"",""1181"",""321""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-02-23T18:05:54Z""
";https://scholar.google.ch/scholar?start=880&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098879-368;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;[PDF][PDF] REGULATION OF BLOCKCHAIN TECHNOLOGY IN NIGERIA: NEED AND RISKS MITIGATION TOWARDS INDUSTRY 4.0;ON Mbadiwe ; researchgate.net;;"… According to [8] apart from the crypto currency use case, other use cases that have shown up

in Nigeria are as follows: The adoption of Oracle's blockchain technology platform … in its initial

coin offering (ICO) in partnership with South Korea's cryptocurrency fund company …";Les 2 versions;Version HTML;[PDF] researchgate.net;https://www.researchgate.net/profile/Charles_Ikerionwu/publication/344014034_Regulation_of_Blockchain_in_Nigeria_Need_and_Risk_Mitigation_towards_industry_40_Preparedness/links/60003043a6fdccdcb8518c84/Regulation-of-Blockchain-in-Nigeria-Need-and-Risk-Mitigation-towards-industry-40-Preparedness.pdf;;;https://scholar.google.ch/scholar?start=910&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098782-141;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;????????? ???? ????? ?????????? ? ???????? ???????? ??????????;?? ???????, ?? ??????? ; ??????? ??????????? ?????? ????????, 2020  elibrary.ru;;"… system in companies, the authors identified measures for the safe use of smart contracts of the

blockchain management system … ??? ??????? ??????? Ť?????? ? ????????ť (The Oracle

machine), ????????????, ??? ??? ????????? ??? ????? ?????? ???????? …";Autres articles;;null;;;;https://scholar.google.ch/scholar?start=690&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098743-53;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;A Comprehensive Approach to Creating a Trusted Document Management Platform with a Digital Signature;AY Shcherbakov ; Automatic Documentation and Mathematical …, 2020  Springer;;"… to provide for the possibility of selecting and updating the list of oracles and their … a prover and

verifier (commitment-challenge-response) and noninteractive proofs (Random oracle model,

Fiat … Miller, A., Shi, E., Wen Zikai, and Papamanthou, Ch., Hawk: The blockchain model of …";;null;null;;;;https://scholar.google.ch/scholar?start=600&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098734-37;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Design and Implementation of InBlock—A Distributed IP Address Registration System;A García;Martínez, S Angieri, B Liu, F Yang…  IEEE Systems …, 2020  ieeexplore.ieee.org;;"… InBlock relies on several third parties, oracles, for obtaining the conversion rate

between the fiat currency and Ether. An oracle is a service provided by a third party

that annotates in the blockchain a particular external world value …";Autres articles;;null;;;;https://scholar.google.ch/scholar?start=580&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098870-344;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;?????? ???? ??? ?? ????? ?? ?????????;?????? ????, ????, ???? ; ????? ???? ?????, 2020?  jplr.atu.ac.ir;;"… ????? ???? ?????? ? ? ?? ? ? ???? ?? ?? ???? ?? ? ??? ?? ? ?? ?? ????? ????? ?? ??? ?? ?? ?????

?????? ?? ???? ???? .????? 5 9 . Zibin Zheng, Shaoan Xie, Hong-Ning Dai, Huaimin Wang, An

Overview of Blockchain Technology: Architecture, Consensus, andFutureTrends … 
?";Autres articles;;[PDF] atu.ac.ir;http://jplr.atu.ac.ir/article_11137_7d31946cd79f8f00018ee3c6b0e0c3a4.pdf;"
Found

The document has moved here.

";"""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""dc:title"",""302 Found""
""Content-Encoding"",""ISO-8859-1""
""resourceName"",""article_11137_7d31946cd79f8f00018ee3c6b0e0c3a4.pdf""
""language"",""en""
""Content-Length"",""257""
""title"",""302 Found""
""Content-Type"",""text/html; charset=ISO-8859-1""
";https://scholar.google.ch/scholar?start=890&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098738-42;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Funktionsweise einer Blockchain;C Peitz ; Datenschutzrechtliche Verantwortlichkeit in Blockchain …, 2020  Springer;;"… 112 Böhme/Pesch, DuD, 2017, 473, 476; iE auch Narayanan/Bonneau/Felten/Miller/Goldfeder,

Bit- coin and cryptocurrency technologies, 1. Aufl., 2016, S. 19. III … „Oracles“ als Schnittstellen

zwi- schen Blockchain und Lebenswirklichkeit, beispielsweise in Form der Überwa …";;null;null;;;;https://scholar.google.ch/scholar?start=590&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098800-184;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Blind Schnorr signatures and signed ElGamal encryption in the algebraic group model;G Fuchsbauer, A Plouviez, Y Seurin ; … on the Theory and Applications of …, 2020  Springer;;"… This is the case for blockchain-based systems where modifying the signature scheme used for …

by a set of parameters \({\textit{par}}\) consists of a main and oracle procedures … and runs an

adversary \(\mathcal {A}\), which interacts with the game by calling the provided oracles …";Cité 20 fois;Les 3 versions;[PDF] iacr.org;https://eprint.iacr.org/2019/877.pdf;"
Blind Schnorr Signatures and Signed ElGamal Encryption
in the Algebraic Group Model

Georg Fuchsbauer1, Antoine Plouviez2, and Yannick Seurin3

1 TU Wien, Austria
2 Inria, ENS, CNRS, PSL, Paris, France

3 ANSSI, Paris, France
first.last@{tuwien.ac.at,ens.fr,m4x.org}

January 16, 2021

Abstract. The Schnorr blind signing protocol allows blind issuing of Schnorr signatures, one
of the most widely used signatures. Despite its practical relevance, its security analysis is
unsatisfactory. The only known security proof is rather informal and in the combination of the
generic group model (GGM) and the random oracle model (ROM) assuming that the “ROS
problem” is hard. The situation is similar for (Schnorr-)signed ElGamal encryption, a simple
CCA2-secure variant of ElGamal.
We analyze the security of these schemes in the algebraic group model (AGM), an idealized
model closer to the standard model than the GGM. We first prove tight security of Schnorr
signatures from the discrete logarithm assumption (DL) in the AGM+ROM. We then give
a rigorous proof for blind Schnorr signatures in the AGM+ROM assuming hardness of the
one-more discrete logarithm problem and ROS.
As ROS can be solved in sub-exponential time using Wagner’s algorithm, we propose a simple
modification of the signing protocol, which leaves the signatures unchanged. It is therefore
compatible with systems that already use Schnorr signatures, such as blockchain protocols. We
show that the security of our modified scheme relies on the hardness of a problem related to
ROS that appears much harder.
Finally, we give tight reductions, again in the AGM+ROM, of the CCA2 security of signed
ElGamal encryption to DDH and signed hashed ElGamal key encapsulation to DL.

Keywords: Schnorr signatures, blind signatures, algebraic group model, ElGamal encryption,
blockchain protocols

An extended abstract of this work appears in EUROCRYPT’20. This is the full version.

1 Introduction

Schnorr Signatures. The Schnorr signature scheme [Sch90, Sch91] is one of the oldest and
simplest signature schemes based on prime-order groups. Its adoption was hindered for years by
a patent which expired in February 2008, but it is by now widely deployed: EdDSA [BDL+12],
a specific instantiation based on twisted Edward curves, is used for example in OpenSSL,
OpenSSH, GnuPG and more. Schnorr signatures are also expected to be implemented in
Bitcoin [Wui18], enabling multi-signatures supporting public key aggregation, which will result
in considerable scalability and privacy enhancements [BDN18, MPSW19].

The security of the Schnorr signature scheme has been analyzed in the random oracle
model (ROM) [BR93], an idealized model which replaces cryptographic hash functions by truly
random functions. Pointcheval and Stern [PS96b, PS00] proved Schnorr signatures secure in



the ROM under the discrete logarithm assumption (DL). The proof, based on the so-called
Forking Lemma, proceeds by rewinding the adversary, which results in a loose reduction (the
success probability of the DL solver is a factor qh smaller than that of the adversary, where qh
is the number of the adversary’s random oracle queries). Using the “meta reduction” technique,
a series of works showed that this security loss is unavoidable when the used reductions are
either algebraic [PV05, GBL08, Seu12] or generic [FJS19]. Although the security of Schnorr
signatures is well understood (in the ROM), the same cannot be said for two related schemes,
namely blind Schnorr signatures and Schnorr-signed ElGamal encryption.

Blind Schnorr Signatures. A blind signature scheme allows a user to obtain a signature
from a signer on a message m in such a way that (i) the signer is unable to recognize the
signature later (blindness, which in particular implies that m remains hidden from the signer)
and (ii) the user can compute one single signature per interaction with the signer (one-
more unforgeability). Blind signature schemes were introduced by Chaum [Cha82] and are
a fundamental building block for applications that guarantee user anonymity, e.g. e-cash
[Cha82, CFN90, OO92, CHL05, FPV09], e-voting [FOO93], direct anonymous attestation
[BCC04], and anonymous credentials [Bra94, CL01, BCC+09, BL13a, Fuc11].

Constructions of blind signature schemes range from very practical schemes based on
specific assumptions and usually provably secure in the random oracle model [PS96a, PS00,
Abe01, Bol03, FHS15, HKL19] to theoretical schemes provably secure in the standard model
from generic assumptions [GRS+11, BFPV13, GG14].

The blind Schnorr signature scheme derives quite naturally from the Schnorr signature
scheme [CP93]. It is one of the most efficient blind signature schemes and increasingly used
in practice. Anticipating the implementation of Schnorr signatures in Bitcoin, developers are
already actively exploring the use of blind Schnorr signatures for blind coin swaps, trustless
tumbler services, and more [Nic19].

While the hardness of computing discrete logarithms in the underlying group G is obviously
necessary for the scheme to be unforgeable, Schnorr [Sch01] showed that another problem that
he named ROS, which only depends on the order p of the group G, must also be hard for the
scheme to be secure. Informally, the ROS` problem, parameterized by an integer `, asks to
find `+ 1 vectors ~ρi = (ρi,j)j∈[`] such that the system of `+ 1 linear equations in unknowns
c1, . . . , c` over Zp ∑`

j=1 ρi,jcj = Hros(~ρi) , i ∈ [`+ 1]

has a solution, where Hros : (Zp)` → Zp is a random oracle. Schnorr showed that an attacker able
to solve the ROS` problem can produce `+ 1 valid signatures while interacting (concurrently)
only ` times with the signer. Slightly later, Wagner [Wag02] showed that the ROS` problem
can be reduced to the (`+ 1)-sum problem, which can solved with time and space complexity
O
(
(`+ 1)2Îť/(1+blg(`+1)c)), where Îť is the bit size of p. For example, for Îť = 256, this attack

yields 16 valid signatures after ` = 15 interactions with the signer in time and space close to 255.
For `+ 1 = 2

√
Îť, the attack has sub-exponential time and space complexity O(22

√
Îť), although

the number of signing sessions becomes arguably impractical. Asymptotically, this attack can
be thwarted by increasing the group order, but this would make the scheme quite inefficient.

From a provable-security point of view, a number of results [FS10, Pas11, BL13b] indi-
cate that blind Schnorr signatures cannot be proven one-more unforgeable under standard
assumptions, not even in the ROM. The only positive result by Schnorr and Jakobsson [SJ99]

2



and Schnorr [Sch01] states that blind Schnorr signatures are secure in the combination of the
generic group model and the ROM assuming hardness of the ROS problem.

The recent analysis by Hauck, Kiltz, and Loss [HKL19] of blind signatures derived from
linear identification schemes does not apply to Schnorr. The reason is that the underlying
linear function family F : Zp → G, x 7→ xG lacks the property of having a pseudo torsion-free
element from the kernel (see [HKL19, Definition 3.1]). In particular, F is one-to-one, whereas
Hauck et al. reduce blind signature unforgeability to collision resistance of the underlying
function family.

The Algebraic Group Model. The generic group model (GGM) [Nec94, Sho97] is an
idealized model for the security analysis of cryptosystems that are defined over cyclic groups.
Instead of receiving concrete group elements, the adversary only gets “handles” for them and
has access to an oracle that performs the group operation (denoted additively) on handles.
This implies that if the adversary is given a list of (handles of) group elements (X1, . . . , Xn)
and later returns (a handle of) a group element Z, then by inspecting its oracle calls one can
derive a “representation” ~z = (z1, . . . , zn) such that Z =

∑n
i=1 ziXi.

Fuchsbauer, Kiltz, and Loss [FKL18] introduced the algebraic group model (AGM), a model
that lies between the standard model and the GGM. On the one hand, the adversary has direct
access to group elements; on the other hand, it is assumed to only produce new group elements
by applying the group operation to received group elements. In particular, with every group
element Z that it outputs, the adversary also gives a representation ~z of Z in terms of the
group elements it has received so far. While the GGM allows for proving information-theoretic
guarantees, security results in the AGM are proved via reductions to computationally hard
problems, like in the standard model.

Our starting point is the observation that in the combination4 AGM+ROM Schnorr
signatures have a tight security proof under the DL assumption. This is because we can
give a reduction which works straight-line, i.e., unlike the forking-lemma-based reduction
[PS96b, PS00], which must rewind the adversary, it runs the adversary only once.5 Motivated
by this, we then turn to blind Schnorr signatures, whose security in the ROM remains elusive,
and study their security in the AGM+ROM.

Our Results on Blind Schnorr Signatures. Our first contribution is a rigorous analysis
of the security of blind Schnorr signatures in the AGM+ROM. Concretely, we show that any
algebraic adversary successfully producing `+ 1 forgeries after at most ` interactions with the
signer must either solve the one-more discrete logarithm (OMDL) problem or the ROS` problem.
Although this is not overly surprising in view of the previous results in the GGM [SJ99, Sch01],
this gives a more satisfying characterization of the security of this protocol. Moreover, all
previous proofs [SJ99, Sch01] were rather informal; in particular, the reduction solving ROS
was not explicitly described. In contrast, we provide precise definitions (in particular for the
ROS problem, whose exact specification is central for a security proof) and work out the
details of the reductions to both OMDL and ROS, which yields the first rigorous proof.

Nevertheless, the serious threat by Wagner’s attack for standard-size group orders remains.
In order to remedy this situation, we propose a simple modification of the scheme which

4 This combination of idealized models was already considered when the AGM was first defined [FKL18].
5 A similar result [ABM15] shows that Schnorr signatures, when viewed as non-interactive proofs of knowledge
of the discrete logarithm of the public key, are simulation-sound extractable, via a straight-line extractor.
Our proof is much simpler and gives a concrete security statement.

3



only alters the signing protocol (key generation and signature verification remain the same)
and thwarts (in a well-defined way) any attempt at breaking the scheme by solving the ROS
problem. The idea is that the signer and the user engage in two parallel signing sessions, of
which the signer only finishes one (chosen at random) in the last round. Running this tweak
takes thus around twice the time of the original protocol. We show that an algebraic adversary
successfully mounting an (` + 1)-forgery attack against this scheme must either solve the
OMDL problem or a modified ROS problem, which appears much harder than the standard
ROS problem for large values of `, which is precisely when the standard ROS problem becomes
tractable.

Our results are especially relevant to applications that impose the signature scheme and
for which one then has to design a blind signing protocol. This is the case for blockchain-based
systems where modifying the signature scheme used for authorizing transactions is a heavy
process that can take years (if possible at all). We see a major motivation for studying blind
Schnorr signatures in its real-world relevance for protocols that use Schnorr signatures or
will in the near future, such as Bitcoin. For these applications, Wagner’s attack represents a
significant risk, which can be thwarted by using our modified signing protocol.

Update on the Hardness of the ROS Problem. Shortly after the publication of this
work, Benhamouda et al. [BLOR20] discovered a polynomial-time attack against the ROS
problem. More precisely, the attack efficiently solves ROS` when ` > log2(p). This directly
implies a polynomial-time attack against the blind Schnorr signature scheme where the attacker
produces `+ 1 signatures after ` ≥ dlog2 pe concurrent interactions with the signer. The attack
does not apply to the modified ROS problem, hence our new blind signature scheme is
unaffected.

Chosen-Ciphertext-Secure ElGamal Encryption. Recall the ElGamal public-key en-
cryption (PKE) scheme [ElG85]: given a cyclic group (G,+) of prime order p and a generator
G, a secret/public key pair is of the form (y, yG) ∈ Zp × G. To encrypt a message M ∈ G,
one draws x←$ Zp, computes X := xG, and outputs ciphertext (X,M + xY ). This scheme
is IND-CPA-secure under the decisional Diffie-Hellman (DDH) assumption [TY98], that is,
no adversary can distinguish encryptions of two messages. Since the scheme is homomorphic,
it cannot achieve IND-CCA2 security, where the adversary can query decryptions of any
ciphertext (except of the one it must distinguish). However, ElGamal has been shown to be
IND-CCA1-secure (where no decryption queries can be made after receiving the challenge
ciphertext) in the AGM under a “q-type” variant of DDH [FKL18].6

A natural way to make ElGamal encryption IND-CCA2-secure is to add a proof of knowledge
of the randomness x used to encrypt. Intuitively, this makes the scheme plaintext-aware [BR95],
which informally means that for any adversary producing a valid ciphertext, there exists an
extractor that can retrieve the corresponding plaintext. The reduction of IND-CCA2 security
can then use the extractor to answer the adversary’s decryption queries. (For ElGamal, the
extractor would extract the randomness x used to produce (X = xG,C = M + xY ) from the
proof of knowledge and return the plaintext M = C − xY .) Since the randomness x together
with the first part X of the ciphertext form a Schnorr key pair, a natural idea is to use a

6 [FKL18] showed IND-CCA1 security for the corresponding key-encapsulation mechanism, which returns a
key K = xY and an encapsulation of the key X = xG. The ElGamal PKE scheme is obtained by combining
it with the one-time-secure data-encapsulation mechanism M 7→M +K. Generic results on hybrid schemes
[HHK10] imply IND-CCA1 security of the PKE.

4



Schnorr signature [Jak98, TY98], resulting in what is usually called (Schnorr-)signed ElGamal
encryption. This scheme has a number of attractive properties: ciphertext validity can be
checked without knowledge of the decryption key, and one can work homomorphically with
the “core” ElGamal ciphertext (a property sometimes called “submission-security” [Wik08]),
which is very useful in e-voting.

Since Schnorr signatures are extractable in the ROM, one would expect that signed ElGamal
can be proved IND-CCA2 under, say, the DDH assumption (in the ROM). However, turning
this intuition into a formal proof has remained elusive. The main obstacle is that Schnorr
signatures are not straight-line extractable in the ROM [BNW17]. As explained by Shoup and
Gennaro [SG02], the adversary could order its random-oracle and decryption queries in a way
that makes the reduction take exponential time to simulate the decryption oracle.

Schnorr and Jakobsson [SJ00] showed IND-CCA2 security in the GGM+ROM, while
Tsiounis and Yung [TY98] gave a proof under a non-standard “knowledge assumption”, which
amounts to assuming that Schnorr signatures are straight-line extractable. On the other hand,
impossibility results tend to indicate that IND-CCA2 security cannot be proved in the ROM
[ST13, BFW16].

Our Results on Signed ElGamal Encryption. Our second line of contributions is two-
fold. First, we prove (via a tight reduction) that in the AGM+ROM, Schnorr-signed ElGamal
encryption is IND-CCA2-secure under the DDH assumption. While intuitively this should
follow naturally from the straight-line extractability of Schnorr proofs of knowledge for algebraic
adversaries, the formal proof is technically quite delicate: since messages are group elements,
the “basis” of group-element inputs in terms of which the adversary provides representations
contains not only the three group elements of the challenge ciphertext but also grows as the
adversary queries the decryption oracle.7

We finally consider the “hashed” variant of ElGamal (also known as DHIES) [ABR01],
in which a key is derived as k = H(xY ). In the ROM, the corresponding key-encapsulation
mechanism (KEM) is IND-CCA2-secure under the strong Diffie-Hellman assumption (which
states that CDH is hard even when given a DDH oracle) [CS03]. We propose to combine the
two approaches: concretely, we consider the hashed ElGamal KEM together with a Schnorr
signature proving knowledge of the randomness used for encapsulating the key and give a tight
reduction of the IND-CCA2 security of this scheme to the DL problem in the AGM+ROM.

2 Preliminaries

General Notation. We denote the (closed) integer interval from a to b by [a, b]. We use
[b] as shorthand for [1, b]. A function µ : N → [0, 1] is negligible (denoted µ = negl) if for all
c ∈ N there exists λc ∈ N such that µ(λ) ≤ λ−c for all λ ≥ λc. A function ν is overwhelming if
1− ν = negl. We let lg denote the logarithm in base 2 and write x ≡p y for x ≡ y (mod p).

Given a non-empty finite set S, we let x←$S denote the operation of sampling an element
x from S uniformly at random. All algorithms are probabilistic unless stated otherwise. By
y ← A(x1, . . . , xn) we denote the operation of running algorithm A on inputs (x1, . . . , xn)
and uniformly random coins and letting y denote the output. If A has oracle access to some

7 Bernhard et al. [BFW16] hastily concluded that, in the AGM+ROM, IND-CCA2-security of signed ElGamal
followed from straight-line extractability of Schnorr signatures showed in [ABM15]. Our detailed proof shows
that this was a bit optimistic.

5



algorithm Oracle, we write y ← AOracle(x1, . . . , xn). A list ~z = (z1, . . . , zn), also denoted
(zi)i∈[n], is a finite sequence. The length of a list ~z is denoted |~z|. The empty list is denoted ( ).

A security game GAMEpar(Îť) indexed by a set of parameters par consists of a main
procedure and a collection of oracle procedures. The main procedure, on input the security
parameter Îť, initializes variables and generates input on which an adversary A is run. The
adversary interacts with the game by calling oracles provided by the game and returns some
output, based on which the game computes its own output b (usually a single bit), which we
write b← GAMEApar(λ). When the game outputs the truth value of a predicate, we identify
false with 0 and true with 1. Games are either computational or decisional. The advantage of A
in GAMEpar(Îť) is defined as Advgame

par,A(λ) := Pr[1← GAMEApar(λ)] if the game is computational
and as Advgame

par,A(λ) := 2 · Pr[1← GAMEApar(λ)]− 1 if it is decisional, where the probability is
taken over the random coins of the game and the adversary. We say that GAMEpar is hard if
for any probabilistic polynomial-time (p.p.t.) adversary A, Advgame

par,A(Îť) = negl(Îť). All games
considered in this paper are computational unless stated otherwise (we only consider decisional
games in Section 6 and Appendix B and C.)

Algebraic Algorithms. A group description is a tuple Γ = (p,G, G) where p is an odd
prime, G is an abelian group of order p, and G is a generator of G. We will use additive
notation for the group law throughout this paper, and denote group elements (including the
generator G) with italic uppercase letters. We assume the existence of a p.p.t. algorithm GrGen
which, on input the security parameter 1λ in unary, outputs a group description Γ = (p,G, G)
where p is of bit-length Ν. Given an element X ∈ G, we let logG(X) denote the discrete
logarithm of X in base G, i.e., the unique x ∈ Zp such that X = xG. We write logX when G
is clear from context.

An algebraic security game (w.r.t. GrGen) is a game GAMEGrGen that (among other things)
runs Γ ← GrGen(1λ) and runs the adversary on input Γ = (p,G, G). An algorithm Aalg
executed in an algebraic game GAMEGrGen is algebraic if for all group elements Z that it
outputs, it also provides a representation of Z relative to all previously received group elements:
if Aalg has so far received ~X = (X0, . . . , Xn) ∈ Gn+1 (where by convention we let X0 = G),
then Aalg must output Z together with ~z = (z0, . . . , zn) ∈ (Zp)n+1 such that Z =

∑n
i=0 ziXi.

We let Z[~z] denote such an augmented output. When writing ~z explicitly, we simply write
Z[z0,...,zn] (rather than Z[(z0,...,zn)]) to lighten the notation.

Algebraic Algorithms in the Random Oracle Model. The original paper [FKL18]
considered the algebraic group model augmented by a random oracle and proved tight security
of BLS signatures [BLS04] in the AGM+ROM model. The random oracle in that work is of
type H : {0, 1}∗ → G, and as the outputs are group elements, the adversary’s group element
representations could depend on them.

In this work we analyze Schnorr-type cryptosystems, for which the RO is typically of type
H : G × {0, 1}∗ → Zp. Thus, an algebraic adversary querying H on some input (Z,m) must
also provide a representation ~z for the group-element input Z. In a game that implements the
random oracle by lazy sampling, to ease readability, we will define an auxiliary oracle H̃, which
is used by the game itself (and thus does not take representations of group elements as input)
and implements the same function as H.

The One-More Discrete Logarithm Problem. We recall the discrete logarithm (DL)
problem in Figure 1. The one-more discrete logarithm (OMDL) problem, also defined in

6



Game DLAGrGen(Îť)

(p,G, G)←GrGen(1λ)
x←$Zp ; X := xG

y ← A(p,G, G,X)
return (y = x)

Game OMDLAGrGen(Îť)

(p,G, G)←GrGen(1λ)
~x := ( ) ; q := 0

~y ← AChal,DLog(p,G, G)

return
(
~y = ~x ∧ q < |~x|

)

Oracle Chal()

x←$Zp ; X := xG

~x := ~x ‖ (x)
return X

Oracle DLog(X)

q := q + 1
x := logG(X)
return x

Fig. 1. The DL and OMDL problems.

Figure 1, is an extension of the DL problem and consists in finding the discrete logarithm of q
group elements by making strictly less than q calls to an oracle solving the discrete logarithm
problem. It was introduced in [BNPS03] and used for example to prove the security of the
Schnorr identification protocol against active and concurrent attacks [BP02].

3 Schnorr Signatures

3.1 Definitions

A signature scheme SIG consists of the following algorithms:

– par← SIG.Setup(1λ): the setup algorithm takes as input the security parameter λ in unary
and outputs public parameters par;

– (sk, pk)← SIG.KeyGen(par): the key generation algorithm takes parameters par and outputs
a secret key sk and a public key pk;

– σ ← SIG.Sign(sk,m): the signing algorithm takes as input a secret key sk and a message
m ∈ {0, 1}∗ and outputs a signature σ;

– b← SIG.Ver(pk,m, σ): the (deterministic) verification algorithm takes a public key pk, a
message m, and a signature σ; it returns 1 if σ is valid and 0 otherwise.

Correctness requires that for any λ and any message m, when running par← SIG.Setup(1λ),
(sk, pk) ← SIG.KeyGen(par), σ ← SIG.Sign(sk,m), and b ← SIG.Ver(pk,m, σ), one has b = 1
with probability 1. The standard security notion for a signature scheme is existential unforge-
ability under chosen-message attack (EUF-CMA), formalized via game EUF-CMA, which we
recall in Figure 2. The Schnorr signature scheme [Sch91] is specified in Figure 3.

Game EUF-CMAASIG(Îť)

par← SIG.Setup(1λ)
(sk, pk)← SIG.KeyGen(par) ; Q := ( )

(m∗, σ∗)← ASign(pk)

return
(
m∗ /∈ Q ∧ SIG.Ver(pk,m∗, σ∗)

)

Oracle Sign(m)

σ ← SIG.Sign(sk,m)
Q := Q ‖ (m)
return σ

Fig. 2. The EUF-CMA security game for a signature scheme SIG.

7



Sch.Setup(1Îť)

(p,G, G)← GrGen(1λ)
Select H : {0, 1}∗ → Zp
return par := (p,G, G,H)

Sch.Sign(sk,m)

(p,G, G,H, x) := sk ; r←$Zp ; R := rG

c := H(R,m) ; s := r + cx mod p
return σ := (R, s)

Sch.KeyGen(par)

(p,G, G,H) := par ; x←$Zp ; X := xG

sk := (par, x) ; pk := (par, X)
return (sk, pk)

Sch.Ver(pk,m, σ)

(p,G, G,H, X) := pk ; (R, s) := σ

c := H(R,m)
return (sG = R+ cX)

Fig. 3. The Schnorr signature scheme Sch[GrGen] based on a group generator GrGen.

3.2 Security of Schnorr Signatures in the AGM

As a warm-up and to introduce some of the techniques used later, we reduce security of Schnorr
signatures to hardness of DL in the AGM+ROM.

Theorem 1. Let GrGen be a group generator. Let Aalg be an algebraic adversary against the
EUF-CMA security of the Schnorr signature scheme Sch[GrGen] running in time at most τ
and making at most qs signature queries and qh queries to the random oracle. Then there exists
an algorithm B solving the DL problem w.r.t. GrGen, running in time at most τ +O(qs + qh),
such that

Adveuf-cma
Sch[GrGen],Aalg

(λ) ≤ Advdl
GrGen,B(Îť) + qs(qs + qh) + qh + 1

2λ−1 .

We start with some intuition for the proof. In the random oracle model, Schnorr signatures
can be simulated without knowledge of the secret key by choosing random c and s, setting
R := sG− cX and then programming the random oracle so that H(R,m) = c. On the other
hand, an adversary that returns a signature forgery (m∗, (R∗, s∗)) can be used to compute
the discrete logarithm of the public key X. In the ROM this can be proved by rewinding the
adversary and using the Forking Lemma [PS96b, PS00], which entails a security loss.

In the AGM+ROM, extraction is straight-line and the security proof thus tight. After
querying the signing oracle on messages m1, . . . ,mqs , the adversary obtains (Ri, si)1≤i≤qs that
verify Ri = siG− ciX with ci = H(Ri,mi). A valid forgery satisfies

R∗ = s∗G− c∗X , (1)

with c∗ := H(R∗,m∗). On the other hand, since the adversary is algebraic, when it made its
first query H(R∗,m∗), it provided a representation of R∗ in basis (G,X,R1, . . . , Rqs), that
is, (γ∗, ξ∗, ~ρ∗) with R∗ = γ∗G+ ξ∗X +

∑qs
i=1 ρ

∗
iRi = γ∗G+ ξ∗X +

∑qs
i=1 ρ

∗
i siG−

∑qs
i=1 ρ

∗
i ciX.

Together with (1), this yields(
c∗ + ξ∗ −

∑qs
i=1 ρ

∗
i ci
)
X =

(
s∗ − γ∗ −

∑qs
i=1 ρ

∗
i si
)
G .

Since c∗ was chosen at random after the adversary chose ξ∗, ρ∗1, . . . and ρ∗qs , the probability
that c∗ + ξ∗ −

∑qs
i=1 ρ

∗
i ci 6≡p 0 is overwhelming, in which case we can compute the discrete

logarithm of X from the above equation.

8



Game0
(
EUF-CMAAalg

Sch[GrGen]

)
, Game1 , Game2

(p,G, G)← GrGen(1λ)
j := 0 ; x←$Zp ; X := xG

Q := ( ) ; T := ( ) ; // U := ( )(
m∗, (R∗[γ,ξ,~ρ], s

∗)
)
← AH,Sign

alg (p,G, G,X)

// R∗ = γG+ ξX +
∑|Q|

i=1 ρiRi

if m∗ ∈ Q then return 0
c∗ := H(R∗[γ,ξ,~ρ],m

∗)
// (γ∗, ξ∗, ~ρ∗) := U(R∗,m∗)

// x = (s∗ − γ∗ −
∑|Q|

i=1 ρ
∗
i si)(Ξ

∗ −
∑|Q|

i=1 ρ
∗
i ci + c∗)−1 mod p

return (s∗G = R∗ + c∗X)

Oracle H(R[γ,Ξ,~ρ],m)

// R = γG+ ΞX +
∑|Q|

i=1 ρiRi

if T(R,m) = ⊥ then
T(R,m)←$Zp ; // U(R,m) := (γ, ξ, ~ρ)

if ξ −
∑|Q|

i=1 ρici ≡p −T(R,m) then
abort game and return 0 (I)

return T(R,m)

Oracle H̃(R,m)

if T(R,m) = ⊥ then
T(R,m)←$Zp

return T(R,m)

Oracle Sign(m) // in Game0 and Game1

j := j + 1 ; rj ←$Zp ; Rj := rjG

cj := H̃(Rj ,m) ; sj := rj + cjx mod p
Q := Q‖(m)
return (Rj , sj)

Oracle Sign(m) // in Game2

j := j + 1 ; cj , sj ←$Zp ; Rj := sjG− cjX
if T(Rj ,m) = ⊥ then T(Rj ,m) := cj

else abort game and return 0 (II)
Q := Q‖(m)
return (Rj , sj)

Fig. 4. Games in the proof of Theorem 1. Game0 is defined by ignoring all boxes; boxes are included in Game1

and Game2; gray boxes are only included in Game2. The dark-gray comments show how B solves DL.

Proof of Theorem 1. Let Aalg be an algebraic adversary in EUF-CMASch[GrGen] that makes at
most qs signature queries and qh RO queries. We proceed by a sequence of games specified in
Figure 4.

Game0. The first game is EUF-CMA (Figure 2) for the Schnorr signature scheme (Figure 3)
with a random oracle H. The game maintains a list Q of queried messages and T of values
sampled for H. Since the adversary is algebraic, it must provide a representation (γ, Ξ, ~ρ) for its
forgery (m∗, (R∗[γ,ξ,~ρ], s

∗)) such that R∗ = γG+ξX+
∑|Q|
i=1 ρiRi, and similarly for each RO query

H(R[γ,Ξ,~ρ],m). To prepare the change to Game1, we have written the finalization of the game in
an equivalent way: it first checks that m∗ /∈ Q and then runs Sch.Ver(X,m∗, (R∗, s∗)), which we
have written explicitly. Also, the game calls c∗ := H(R∗[γ,ξ,~ρ],m

∗) rather than c∗ := H̃(R∗,m∗)
but in Game0 these two oracles are equivalent. By definition,

Advgame0
Aalg

(Îť) = Adveuf-cma
Sch[GrGen],Aalg

(Îť) . (2)

Game1. In Game1, when H(R[γ,Ξ,~ρ],m) is called, the game returns 0 in case the freshly drawn
random value T(R,m) satisfies ξ −

∑|Q|
i=1 ρici ≡p −T(R,m) (line (I)). Clearly, for each call

to H this happens with probability 1/p ≤ 1/2λ−1. Since H is called at most qh times by the

9



adversary and once by the game when checking the signature, by the union bound, one has

Advgame1
Aalg

(λ) ≥ Advgame0
Aalg

(λ)− qh + 1
2λ−1 . (3)

Game2. In the final game we use the standard method for Schnorr signatures of simulating the
Sign oracle without the secret key x by programming the random oracle. Game1 and Game2
are identical unless Game2 returns 0 in line (II). For each signature query, Rj is uniformly
random, and the size of table T is at most qs + qh, hence the game aborts in line (II) with
probability at most (qs + qh)/p ≤ (qs + qh)/2λ−1. By summing over the at most qs signature
queries, we have

Advgame2
Aalg

(λ) ≥ Advgame1
Aalg

(λ)− qs(qs + qh)
2λ−1 . (4)

Reduction to DL. We now construct an adversary B solving DL with the same probability
as Aalg wins Game2. On input group description (p,G, G) and X, the adversary runs Aalg on
input (p,G, G,X) and simulates Game2, which can be done without knowledge of logG(X).
It also uses an auxiliary table U that for each query H(R[γ,Ξ,~ρ],m) stores the representation
(γ, ξ, ~ρ) of R. Assume that the adversary wins Game2 by returning (m∗, (R∗, s∗)) and let
c∗ := T(R∗,m∗) (which is necessarily defined after the call c∗ := H(R∗[γ,ξ,~ρ],m

∗)). We argue
that necessarily (γ∗, ξ∗, ~ρ∗) := U(R∗,m∗) 6= ⊥ and

ξ∗ −
∑|Q|
i=1 ρ

∗
i ci 6= −c∗ mod p. (5)

First note that m∗ /∈ Q, as otherwise the game would already have returned 0. Hence T(R∗,m∗)
can only have been defined either (1) during a call to H by the adversary or (2), if it is still
undefined when Aalg stops, by the game when calling c∗ := H(R∗[γ,ξ,~ρ],m

∗). In both cases, this
call sets both T(R∗,m∗) and U(R∗,m∗) and (5) is necessarily satisfied as otherwise the game
would have returned 0 at line (I).

Since R∗ = γ∗G+ ξ∗X+
∑|Q|
i=1 ρ

∗
iRi with Ri = siG− ciX and validity of the forgery implies

that s∗G = R∗ + c∗X, it follows that
(
s∗ − γ∗ −

∑|Q|
i=1 ρ

∗
i si
)
G =

(
ξ∗ −

∑|Q|
i=1 ρ

∗
i ci + c∗

)
X and B

can compute

logX = (s∗ − γ∗ −
∑|Q|
i=1 ρ

∗
i si)(ξ∗ −

∑|Q|
i=1 ρ

∗
i ci + c∗)−1 mod p .

We thus have

Advdl
GrGen,B(Îť) = Advgame2

Aalg
(λ) ≥ Adveuf-cma

Sch[GrGen],Aalg
(λ)− qs(qs + qh) + qh + 1

2λ−1 ,

where the inequality follows from Eqs. (2)–(4). Assuming that scalar multiplications in G and
assignments in tables T and U take unit time, the running time of B is τ +O(qs + qh).

4 Blind Schnorr Signatures

4.1 Definitions

We start with defining the syntax and security of blind signature schemes and focus on schemes
with a 2-round (i.e., 4 messages) signing protocol for concreteness.

10



Game UNFABS(Îť)

par← BS.Setup(1λ)
(sk, pk)← BS.KeyGen(par)
k1 := 0 ; k2 := 0 ; S := ∅

(m∗i , σ∗i )i∈[n] ← ASign1,Sign2 (pk)

return
(
k2 < n

∧ ∀ i 6= j ∈ [n] : (m∗i , σ∗i ) 6= (m∗j , σ∗j )

∧ ∀ i ∈ [n] : BS.Ver(pk,m∗i , σ∗i ) = 1
)

Oracle Sign1(msg)

k1 := k1 + 1 // session id

(msg′, statek1 )← BS.Sign1(sk,msg)
S := S ∪ {k1} // open sessions

return (k1,msg′)

Oracle Sign2(j,msg)

if j /∈ S then return ⊥
(msg′, b)← BS.Sign2(statej ,msg)
if b = 1 then S := S \ {j} ; k2 := k2 ";"""date"",""2021-01-16T13:38:44Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""Blind Schnorr Signatures in the Algebraic Group Model""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""Blind Schnorr Signatures in the Algebraic Group Model""
""modified"",""2021-01-16T13:38:44Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017/Debian) kpathsea version 6.2.3""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2021-01-16T13:38:44Z""
""created"",""2021-01-16T13:38:44Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2021-01-16T13:38:44Z""
""resourceName"",""877.pdf""
""Author"",""""
""producer"",""pdfTeX-1.40.18""
""pdf:docinfo:producer"",""pdfTeX-1.40.18""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""25"",""7"",""9"",""0"",""10"",""13"",""12"",""26"",""17"",""14"",""17"",""100"",""71"",""62"",""30"",""42"",""63"",""30"",""23"",""54"",""23"",""46"",""7"",""5"",""6"",""15"",""0"",""0"",""0"",""20"",""36"",""17"",""10"",""1"",""11"",""31"",""68"",""13"",""41"",""37"",""13"",""17"",""9""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2021-01-16T13:38:44Z""
""Last-Modified"",""2021-01-16T13:38:44Z""
""dcterms:modified"",""2021-01-16T13:38:44Z""
""title"",""Blind Schnorr Signatures in the Algebraic Group Model""
""Last-Save-Date"",""2021-01-16T13:38:44Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2021-01-16T13:38:44Z""
""meta:save-date"",""2021-01-16T13:38:44Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017/Debian) kpathsea version 6.2.3""
""Content-Length"",""895538""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""44""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""2397"",""3148"",""3283"",""3209"",""2994"",""3082"",""1660"",""2005"",""1892"",""2019"",""2122"",""2161"",""1999"",""1967"",""2093"",""2310"",""2966"",""2096"",""1983"",""2315"",""2284"",""1849"",""1633"",""2755"",""1726"",""2383"",""2229"",""3951"",""3744"",""3558"",""1757"",""1739"",""1602"",""2058"",""2016"",""1503"",""2423"",""1467"",""2260"",""1585"",""2204"",""1058"",""1891"",""1211""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2021-01-16T13:38:44Z""
";https://scholar.google.ch/scholar?start=730&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098725-15;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Verifiable Distributed Storage Using Blockchain;?? ?????? ;2020 artemis.cslab.ece.ntua.gr;;"… ???????????? ???????????? ?????????? ?? ????? Blockchain ??????????? ???????

??????-????? ?????? ????????? : ????????? ??????? … ???????????? ????????????

?????????? ?? ????? Blockchain ??????????? ??????? ??????-????? ?????? …";;;[PDF] ntua.gr;http://artemis.cslab.ece.ntua.gr:8080/jspui/bitstream/123456789/17763/1/diploma_thesis_Alyzia_Konsta.pdf;"
Εθνικό Μετσόβιο Πολυτεχνείο
Σχολή Ηλεκτρολόγων Μηχανικών
και Μηχανικών Υπολογιστών
Τομέας Τεχνολογίας Πληροφορικής και Υπολογιστών

Επαληθεύσιμη Κατανεμημένη Αποθήκευση με Χρήση
Blockchain

ΔΙΠΛΩΜΑΤΙΚΗ ΕΡΓΑΣΙΑ

ΑΛΥΖΙΑ-ΜΑΡΙΑ ΚΩΝΣΤΑ

Επιβλέπων : Νεκτάριος Κοζύρης

Καθηγητής Ε.Μ.Π.

Αθήνα, Οκτώβριος 2020





Εθνικό Μετσόβιο Πολυτεχνείο
Σχολή Ηλεκτρολόγων Μηχανικών
και Μηχανικών Υπολογιστών
Τομέας Τεχνολογίας Πληροφορικής και Υπολογιστών

Επαληθεύσιμη Κατανεμημένη Αποθήκευση με Χρήση
Blockchain

ΔΙΠΛΩΜΑΤΙΚΗ ΕΡΓΑΣΙΑ

ΑΛΥΖΙΑ-ΜΑΡΙΑ ΚΩΝΣΤΑ

Επιβλέπων : Νεκτάριος Κοζύρης

Καθηγητής Ε.Μ.Π.

Εγκρίθηκε από την τριμελή εξεταστική επιτροπή την 29η Οκτωβρίου 2020.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Νεκτάριος Κοζύρης
Καθηγητής Ε.Μ.Π.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Γεώργιος Γκούμας
Επίκουρος Καθηγητής, Ε.Μ.Π

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Διονύσιος Πνευματικάτος
Καθηγητής Ε.Μ.Π.

Αθήνα, Οκτώβριος 2020



. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Αλύζια-Μαρία Κώνστα
Διπλωματούχος Ηλεκτρολόγος Μηχανικός και Μηχανικός Υπολογιστών Ε.Μ.Π.

Copyright © Αλύζια-Μαρία Κώνστα, 2020.
Με επιφύλαξη παντός δικαιώματος. All rights reserved.

Απαγορεύεται η αντιγραφή, αποθήκευση και διανομή της παρούσας εργασίας, εξ ολοκλήρου ή τμή-
ματος αυτής, για εμπορικό σκοπό. Επιτρέπεται η ανατύπωση, αποθήκευση και διανομή για σκοπό
μη κερδοσκοπικό, εκπαιδευτικής ή ερευνητικής φύσης, υπό την προϋπόθεση να αναφέρεται η πηγή
προέλευσης και να διατηρείται το παρόν μήνυμα. Ερωτήματα που αφορούν τη χρήση της εργασίας
για κερδοσκοπικό σκοπό πρέπει να απευθύνονται προς τον συγγραφέα.

Οι απόψεις και τα συμπεράσματα που περιέχονται σε αυτό το έγγραφο εκφράζουν τον συγγραφέα και
δεν πρέπει να ερμηνευθεί ότι αντιπροσωπεύουν τις επίσημες θέσεις του Εθνικού Μετσόβιου Πολυτε-
χνείου.



ΠξρίΝΡψΡ

Σκοπός της διπλωματικής είναι η ανάπτυξη ενός συστήματος αποθήκευσης δεδομένων, το οποίο πα-
ρέχει υψηλή επίδοση ενώ ταυτόχρονα εξασφαλίζει την ασφάλεια των δεδομένων. Για την επίτευξη
υψηλής επίδοσης αλλά και για την κλιμακωσιμότητα σε σχέση με τον όγκο των δεδομένων, συνή-
θως καταφεύγουμε σε κατανεμημένες προσεγγίσεις όπως το HDFS ή το GFS της Google. Παρόλα
αυτά, καθώς πλέον δεν υπάρχει μια κεντρική αρχή που εμπιστευόμαστε αλλά σε ένα κατανεμημένο
σύστημα οι κόμβοι μπορεί να τρέχουν από διαφορετικές φυσικές οντότητες, εγείρεται θέμα εμπι-
στοσύνης και ασφάλειας των δεδομένων. Για να αντιμετωπίσουμε το πρόβλημα αυτό, στην εργασία
αυτή χρησιμοποιούμε την τεχνολογία του blockchain. Η δυνατότητα εκτέλεσης κώδικα με επαλη-
θεύσιμο τρόπο (έξυπνα συμβόλαια) έχει οδηγήσει στην υιοθέτηση των blockchains σε μια πληθώρα
εφαρμογών πέρα των κρυπτονομισμάτων. Το σύστημα που αναπτύξαμε, ενσωματώνει το Ethereum
blockchain στο HDFS και εξασφαλίζει ότι κανένας κόμβος δεν μπορεί να τροποποιήσει/διαγράψει
αρχεία χωρίς η ενέργεια αυτή να περάσει από το πρωτόκολλο του HDFS. Η πειραματική αξιολόγηση
του συστήματος έδειξε ότι η ασφάλεια δεν έρχεται δωρεάν αλλά πρέπει να θυσιάσουμε μέρος της
επίδοσης. Πιο συγκεκριμένα, πληρώνουμε σε χρόνο ένα επιπλέον χ% κατά την εισαγωγή αρχείων και
ενα ψ% στη διαθεσιμότητα του συστήματος.

Λέξεις κλειδιά

Ασφαλές Σύστημα Αρχείων, Merkle Trees, Blockchain, Κατανεμμημένο Σύστημα Αρχείων, HDFS.

5





Abstract

The purpose of the diploma thesis is to develop a data storage system, which provides high perfor-
mance while ensuring data security. To achieve high performance but also for scalability in relation to
the volume of data, we usually resort to distributed approaches such as HDFS or Google GFS. How-
ever, as there is no longer a central authority that we trust but in a distributed system nodes can run
from different physical entities, the issue of data trust and security arises. To deal with this problem,
in this work we use blockchain technology. The ability to execute code in a verifiable way (smart
contracts) has led to the adoption of blockchains in a variety of applications beyond cryptocurrencies.
The system we developed integrates the Ethereum blockchain into HDFS and ensures that no node
can modify / delete files without doing so through the HDFS protocol. The experimental evaluation
of the system showed that security does not come for free but we have to sacrifice part of the perfor-
mance. More specifically, we pay on time an additional x% when importing files and a y% on system
availability.

Key words

Secure File System, Merkle Trees, Blockchain, Distributed File System, HDFS.

7





Ευχαριστίες

Θα ήθελα να ευχαριστήσω θερμά τον επιβλέποντα καθηγητή Νεκτάριο Κοζύρη, για την εμπιστοσύνη
που μου έδειξε για την ανάθεση της συγκεκριμένης διπλωματικής εργασίας. Θα ήθελα επίσης να
ευχαριστήσω την Κατερίνα Δόκα και τον Ιωάννη Μυτιλήνη για την εξαιρετική συνεργασία, τις ιδέες,
την υπομονή και την υποστήριξή τους στην εκπόνηση της εργασίας.

Τέλος, θα ήθελα να ευχαριστήσω την οικογένεια και τους φίλους μου για την υποστήριξή καθ’
όλην την διάρκεια των σπουδών μου στο Εθνικό Μετσόβιο Πολυτεχνείο.

Αλύζια-Μαρία Κώνστα,

Αθήνα, 29η Οκτωβρίου 2020

9





Περιεχόμενα

ΠξρίΝΡψΡ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

Ευχαριστίες . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

Περιεχόμενα . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Κατάλογος σχημάτων . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

1. Εισαγωγή . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.1 Χρησιμότητα του Συστήματος . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.2 Σύνοψη του συστήματος . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2. Κατανεμημένα Συστήματα . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.1 HDFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3. Merkle Trees . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

4. Decentralized Δίκτυα . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.1 Blockchain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

5. Η Αρχιτεκτονική του Συστήματος . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
5.1 Γράφοντας το Αρχείο . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
5.2 Block Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
5.3 Smart Contracts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

6. Μετρήσεις και Συμπεράσματα . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

Βιβλιογραφία . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

11





Κατάλογος σχημάτων

2.1 Η Αρχιτεκτονική του HDFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.1 Merkle Tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

4.1 Blockchain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.2 Αλλαγμένο Block . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

5.1 Η Αρχιτεκτονική του Block Report . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
5.2 Πρώτο Βήμα στην Διαδικασία Επικύρωσης . . . . . . . . . . . . . . . . . . . . . . 27
5.3 Εύρεση Ρίζας . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
5.4 Smart Contract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
5.5 Seed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
5.6 Δημιουργία Ακολουθίας . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

6.1 Πειράματα του HDFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
6.2 Πειράματα για Merkle Chunk 512 bytes . . . . . . . . . . . . . . . . . . . . . . . . 32
6.3 Πειράματα για Merkle Chunk 1024 bytes . . . . . . . . . . . . . . . . . . . . . . . 32
6.4 Πειράματα για Merkle Chunk 10000 bytes . . . . . . . . . . . . . . . . . . . . . . . 33
6.5 Πειράματα για Merkle Chunk 100000 bytes . . . . . . . . . . . . . . . . . . . . . . 33
6.6 Πειράματα για Merkle Chunk 1000000 bytes . . . . . . . . . . . . . . . . . . . . . 34
6.7 Διάγραμμα με όλα τα Πειράματα . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
6.8 Πειράματα για Διαφορετικό Πελάτη . . . . . . . . . . . . . . . . . . . . . . . . . . 35
6.9 Datanode Seed vs no-Seed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
6.10 Namenode Seed vs no-Seed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
6.11 Namenode On-chain vs Off-chain . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

13





Κεφάλαιο 1

Εισαγωγή

Στις μέρες μας η ανάγκη για αποθήκευση και επεξεργασία μεγάλου όγκου δεδομένων είναι απα-
ραίτητη. Οι εφαρμογές που χρησιμοποιούν οι άνθρωποι και οι εταιρείες προϋποθέτουν την επεξερ-
γασία και την κατοχή πολλών πληροφοριών. Οι πληροφορίες αυτές είναι αδύνατο να αποθηκευτούν
και να επεξεργαστούν από μόνο έναν υπολογιστή. Η ανάγκη αυτή έφερε στο προσκήνιο τα κατανεμη-
μένα συστήματα, πιο συγκεκριμένα τα κατανεμημένα συστήματα αρχείων για την αποθήκευση ενός
τόσο μεγάλου όγκου δεδομένων. Τα κατανεμημένα συστήματα αρχείων συμπεριφέρονται ουσιαστικά
σαν ένα τοπικό σύστημα αρχείων χωρίς να γίνεται αντιληπτή από τον χρήστη η κατανεμημένη φύση
του συστήματος. Καθώς η λειτουργία αυτών των συστημάτων αρχείων έχει διαδοθεί πολλές εφαρ-
μογές δημιουργούνται οι οποίες τα χρησιμοποιούν, με αποτέλεσμα απομακρυσμένοι υπολογιστές να
κατέχουν κομμάτια των αρχείων μας.

Μέχρι στιγμής, οι περισσότερες εφαρμογές στο διαδίκτυο θεωρούν τους χρήστες αξιόπιστους και
ρυθμίζονται από έναν κόμβο ο οποίος θεωρείται η “κεντρική εξουσία” του συστήματος. Ο κόμβος
αυτός, ρυθμίζει και συντονίζει το σύστημα, επίσης θεωρείται πάντα αξιόπιστος. Η συγκέντρωση όλων
των ευθυνών σε έναν κόμβο μπορεί να αποβεί μοιραία για το σύστημα, καθώς ο κόμβος αυτός μπορεί
να είναι κακόβουλος. Οπότε στην περίπτωση του κατανεμημένου συστήματος αρχείων τα αρχεία
μας μπορεί να διαγραφούν ή να παραποιηθούν, χωρίς να γίνει αντιληπτό μέχρι την ανάκτηση του
αρχείου. Η ασφάλεια τέτοιων συστημάτων είναι πολλή σημαντική για τους χρήστες, οι οποίοι πρέπει
να γνωρίζουν πως τα δεδομένα τους είναι πάντα ακέραια και έτοιμα να ανακτηθούν.

Ένα πολύ διαδεδομένο κατανεμημένο σύστημα αρχείων είναι το HDFS, το οποίο λειτουργεί με
master-slave λογική. Δηλαδή, υπάρχει ένας κόμβος κεντρική εξουσία, o Namenode, ο οποίος συντονί-
ζει τους υπόλοιπους κόμβους-εργάτες, τους Datanodes και ελέγχει αν το σύστημα λειτουργεί σωστά.
To HDFS χρησιμοποιείται σε μια πληθώρα εφαρμογών, καθώς το λογισμικό του μπορεί να τρέξει
και σε οικιακούς υπολογιστές. Όμως η απόλυτη εμπιστοσύνη που δίνεται στον Namenode δεν μπορεί
πάντα να εξασφαλίσει την ορθή λειτουργία του συστήματος, καθώς θα μπορούσε να ”συνεργάζεται”
με κάποιον Datanode και να παρέχει λανθάνουσες πληροφορίες για την ορθή λειτουργία του συστή-
ματος. Να αποκρύπτει δηλαδή τις τροποποιήσεις που δέχονται κάποια αρχεία. Οπότε καλούμαστε
να ενισχύσουμε το σύστημα με μηχανισμούς επαλήθευσης και να δημιουργήσουμε ένα σύστημα το
οποίο να μπορεί να αντιληφθεί οποιαδήποτε προσπάθεια αλλοίωσης των πληροφοριών είτε απο τον
Namenode είτε από τους Datanodes.

Για να πετύχουμε την ασφάλεια των δεδομένων χρησιμοποιούμε Merkle Trees, τα οποία χρησι-
μοποιούνται ευρέως για την επικύρωση μεγάλων δομών δεδομένων και εκμεταλλευόμαστε τα πλε-
ονεκτήματα του Blockchain. Η διαφάνεια των συναλλαγών και η έλλειψη κεντρικής εξουσίας που
προσφέρει η τεχνολογία Blockchain, έχει διαδόσει την χρήση του σε πληθώρα εφαρμογών. Επίσης
τα δεδομένα που αποθηκεύονται στο Blockchain δεν μπορούν να διαγραφούν ή να τροποποιηθούν,
οπότε αποτελεί μια αξιόπιστη πηγή πληροφοριών που κανένας κόμβος του συστήματος δεν μπορεί
να καταχραστεί.

15



1.1 Χρησιμότητα του Συστήματος

Η τεχνολογία του cloud computing κυριαρχεί στον τομέα της πληροφορικής παγκοσμίως, επι-
τρέποντας σε οργανισμούς και άτομα να χρησιμοποιούν απομακρυσμένους πόρους, είτε είναι απο-
θήκευση, υπολογισμούς ή εφαρμογές,αντί για τοπική χρήση που μπορεί να αποτελέσει δαπανηρή σε
χρόνο και πόρους του συστήματος.

Οι υπηρεσίες Cloud βασίζονται κυρίως σε λίγους μεγάλους παρόχους που ενεργούν ως αξιόπιστοι
κόμβοι για τη μεταφορά, αποθήκευση και επεξεργασία δεδομένων. Με αυτό τον τρόπο οι χρήστες
πρέπει να δείχνουν πλήρη εμπιστοσύνη στους παρόχους για την αποθήκευση και επεξεργασία των
δεδομένων τους, οι οποίοι συγκεντρώνουν μεγάλο όγκο πληροφοριών που μπορούν να χρησιμοποι-
ήσουν προς όφελος τους. Επίσης, καταναλώνονται μεγάλα χρηματικά ποσά για την υλοποίηση τόσο
μεγάλων συστημάτων, ώστε να είναι σε θέση να εξυπηρετήσουν μεγάλο αριθμό πελατών.

Ορισμένα χαρακτηριστικά που λείπουν από αυτά τα συστήματα μπορεί να προσφέρει η τεχνο-
λογία Blockchain. Πιο συγκεκριμένα, οι ισχυρές εγγυήσεις για ακεραιότητα των δεδομένων που βα-
σίζεται σε αποδείξεις και όχι σε απλή εμπιστοσύνη μεταξύ πελάτη και η λειτουργία ενός πλήρους
decentralized συστήματος [7].

To HDFS διαμοιράζει αρχεία σε απομακρυσμένους υπολογιστές. Συμμετέχει ένας αριθμός κόμ-
βων και δουλευει με master-slave λογική, όπως αναφέρθηκε παραπάνω. Οι συμμετέχοντες κόμβοι
μπορούν να είναι οποιοιδήποτε υπολογιστές, τους οποίους δεν έχουμε κανένα λόγο να θεωρήσουμε
αξιόπιστους. Ας υποθέσουμε ότι υπάρχει ένα τέτοιο σύστημα στο οποίο θα θέλαμε να συμμετέχουν
για να αποθηκεύσουμε κάποια αρχεία που είναι αδύνατο λόγω μεγέθους να αποθηκευτούν τοπικά
στον υπολογιστή μας. Στο σύστημα αυτό συμμετέχουν τοπικοί υπολογιστές, απλοί χρήστες και όχι
μεγάλες εταιρείες που συγκεντρώνουν όλο τον όγκο δεδομένων σε συγκεκριμένους κόμβους. Οπότε
παίρνουμε την πρωτοβουλία και ανεβάζουμε τα αρχεία μας στο συγκεκριμένο HDFS Cloud. Το αρ-
χείο χωρίζεται σε Block, τα οποία αποθηκεύονται σε απομακρυσμένους υπολογιστές. Το αρχείο μας
τώρα βρίσκεται υπό την διαχείριση των συγκεκριμένων κόμβων. Οποιαδήποτε προσπάθεια για τρο-
ποποίηση ή αλλαγή των δεδομένων μας από τους Datanodes (κόμβοι που αποθηκεύουν τα αρχεία),
θα μπορούσε να μην γίνει αντιληπτή. Επομένως, όταν αποφασίσουμε να ανακτήσουμε τα αρχεία μας
να είναι τροποποιημένα ή ακόμη και κομμάτια του αρχείου να έχουν διαγραφεί.

Η προσθήκη του Blockchain στο HDFS προσφέρει μια λύση στο πρόβλημα της αξιοπιστίας και
έναν τρόπο επικύρωσης της ακεραιότητας των δεδομένων. Τα smart contracts (προγράμματα που
εκτελούνται on-chain), προσφέρουν ασφάλεια λειτουργίας και ορθότητας των αποτελεσμάτων, καθώς
αποθηκεύουν το αποτελέσματα στο Blockchain και ο καθένας μπορεί να ανακτήσει και να ελέγξει το
τελικό αποτέλεσμα.

1.2 Σύνοψη του συστήματος

Ο Namenode δέχεται κάθε 6 ώρες ένα BlockReport από κάθε Datanode, το report περιέχει μέ-
χρι στιγμής μια πληθώρα πληροφοριών για την κατάσταση του Datanode. Ενισχύσαμε το report να
περιέχει κάποιες ακόμη πληροφορίες ώστε να επικυρώνεται η ακεραιότητα των δεδομένων. Η κύ-
ρια ιδέα είναι ότι κάθε φορά που ενεργοποιείται ένα BlockReport, ο Datanode θα ενημερώνεται για
την ανάδειξη ορισμένων αποδείξεων Merkle. Οι αποδείξεις Merkle βασίζονται στην κρυπτογράφηση
των δεδομένων και χρησιμοποιούνται σε μεγάλες δομές ώστε να επικυρώνεται η ακεραιότητα τους,
χωρίς να είναι απαραίτητη η κατοχή της δομής. Για κάθε μπλοκ που ο Datanode έχει αποθηκευμένο
πρέπει να στείλει έναν συγκεκριμένο αριθμό αποδείξεων, το οποίο ζητείται από το Blockchain. Το
Blockchain καθορίζει το πόσες και ποιές αποδείξεις θα δοθούν. Στη συνέχεια, το BlockReport απο-
στέλλεται στο Namenode, ο οποίος πρέπει να επικυρώσει τα αποτελέσματα. Καθώς ο Namenode
λαμβάνει το BlockReport, συνδέεται με το Blockchain και ανακτά ποιές αποδείξεις υπέδειξε πως
πρέπει να δοθούν από τον Datanode. Επειδή δεν είναι αξιόπιστος ο Namenode, εφαρμόσαμε μια επι-
κύρωση On-chain και μια τοπική επικύρωση. Η on-chain επικύρωση είναι πιο ασφαλής, καθώς ενερ-
γοποιεί την εκτέλεση ενός smart contract, αντίθετα με αυτό που παρέχεται από την τοπική επικύρωση

16



στο Namenode. Ο Namenode μπορεί να καταστρέψει τα αποτελέσματα και να παρέχει μη έγκυρες
πληροφορίες στο σύστημα. Από την άλλη πλευρά, η εκτέλεση του smart contract αποθηκεύεται στo
Blockchain και ο καθένας μπορεί να το διαβάσει και να επιβεβαιώσει την ενέργεια του Namenode
ανά πάσα στιγμή. Ο αλγόριθμος είναι ο ίδιος για τις δύο περιπτώσεις. Άμα κάποια απόδειξη κριθεί
λανθασμένη ο εκάστοτε Datanode υποχρεούται να διαγράψει το διεφθαρμένο Block. Σαφώς η on-
chain επικύρωση προσφέρει μεγαλύτερη ασφάλεια και αξιοπιστία, αλλά έχει μεγαλύτερο κόστος στο
χρόνο.

17



Κεφάλαιο 2

Κατανεμημένα Συστήματα

Διάφοροι ορισμοί για το τι είναι ένα κατανεμημένο σύστημα έχουν δοθεί στη βιβλιογραφία. Για
τους σκοπούς μας αρκεί ο παρακάτω χαρακτηρισμός: Ένα κατανεμημένο σύστημα είναι μια συλλογή
αυτόνομων υπολογιστών που εμφανίζεται στους χρήστες ως ένα ενιαίο σύστημα. Αυτός ο ορισμός
αναφέρεται σε δύο χαρακτηριστικά των κατανεμημένων συστημάτων. Το πρώτο είναι ότι ένα κα-
τανεμημένο σύστημα είναι μια συλλογή υπολογιστιστών που ο καθένας μπορεί να συμπεριφέρεται
ανεξάρτητα. Ένας υπολογιστής, γενικά αναφέρεται ως κόμβος. Ένα δεύτερο στοιχείο είναι ότι οι χρή-
στες (είτε πρόκειται για άτομα είτε για εφαρμογές) πιστεύουν ότι ασχολούνται με ένα μόνο σύστημα.
Αυτό σημαίνει ότι με τον έναν ή τον άλλο τρόπο οι αυτόνομοι κόμβοι πρέπει να συνεργαστούν. Ο
τρόπος δημιουργίας αυτής της συνεργασίας βρίσκεται στο επίκεντρο της ανάπτυξης κατανεμημένων
συστημάτων.

Τα κατανεμημένα συστήματα στην εποχή μας είναι πολύ διαδεδομένα και ασφαλώς χρήσιμα.
Μερικές φορές είναι αναγκαία η κατασκευή ενός κατανεμημένου συστήματος, λόγω της φύσης της
εφαρμογής. Σκοπός ενός κατανεμημένου συστήματος είναι η λειτουργία του ως ενιαίο σύστημα ώστε
να μην γίνεται αντιληπτή από τους χρήστες η κατανεμημένη φύση του. Τα κατανεμημένα συστήματα
μπορεί αν είναι υπολογιστικά, δηλαδή ένα ενιαίο πρόβλημα να διαιρείται και να εκτελείται από μια
συλλογή υπολογιστών, μπορεί να είναι κατανεμημένο σύστημα πληροφοριών, για παράδειγμα μια
βάση δεδομένων ή ένα κατανεμημένο σύστημα αρχείων [21].

2.1 HDFS

Το Hadoop Distributed File System (HDFS) είναι ένα σύστημα κατανεμημένων αρχείων που έχει
σχεδιαστεί για να λειτουργεί και σε απλούς υπολογιστές. Έχει πολλές ομοιότητες με τα υπάρχοντα κα-
τανεμημένα συστήματα αρχείων. Ωστόσο, οι διαφορές από άλλα κατανεμημένα συστήματα αρχείων
είναι σημαντικές. Το HDFS είναι εξαιρετικά ανεκτικό σε σφάλματα και έχει σχεδιαστεί για ανάπτυξη
σε υλικό χαμηλού κόστους. Το HDFS παρέχει γρήγορη πρόσβαση σε δεδομένα εφαρμογών και είναι
κατάλληλο για εφαρμογές που διαθέτουν μεγάλα σύνολα δεδομένων.

Το HDFS έχει αρχιτεκτονική master / slave. Το HDFS αποτελείται από ένα μόνο NameNode,
έναν κύριο διακομιστή που διαχειρίζεται το χώρο ονομάτων του συστήματος αρχείων και ρυθμίζει
την πρόσβαση σε αρχεία από τους πελάτες. Επιπλέον, υπάρχει ένας αριθμός DataNodes, συνήθως
ένας σε κάθε κόμβο που συμμετέχει στο σύστημα, οι οποίοι διαχειρίζονται την αποθήκευση των αρ-
χείων του συστήματος. Το HDFS επιτρέπει την αποθήκευση δεδομένων χρήστη σε αρχεία. Εσωτε-
ρικά, ένα αρχείο χωρίζεται σε ένα ή περισσότερα μπλοκ και αυτά τα μπλοκ αποθηκεύονται σε ένα
σύνολο DataNodes. Ο NameNode εκτελεί τις λειτουργίες του χώρου ονομάτων του συστήματος των
αρχείων όπως άνοιγμα, κλείσιμο και μετονομασία αρχείων και καταλόγων. Καθορίζει επίσης τη χαρ-
τογράφηση μπλοκ σε DataNodes. Οι DataNodes είναι υπεύθυνοι για την εξυπηρέτηση αιτημάτων
ανάγνωσης και εγγραφής από τους πελάτες του συστήματος αρχείων. Οι DataNodes εκτελούν επίσης
δημιουργία μπλοκ, διαγραφή και αντιγραφή κατόπιν εντολής του NameNode.

Ο NameNode και ο DataNode είναι λογισμικού που έχει σχεδιαστεί για να λειτουργεί σε απλούς
υπολογιστές του εμπορίου. Αυτά τα μηχανήματα λειτουργούν συνήθως με λειτουργικό σύστημαGNU
/ Linux (OS). Το HDFS είναι γραμμένο στην γλώσσα προγραμματισμού Java, οποιοδήποτε μηχάνημα

18



που υποστηρίζει Java μπορεί να τρέξει το HDFS. Συνήθως, το HDFS έχει μόνο έναν NameNode να
τρέχει σε κάποιο μηχάνημα. Κάθε ένα από τα άλλα μηχανήματα του συστήματος εκτελεί τον κώδικα
που αναπαριστά έναν DataNode. Η αρχιτεκτονική δεν αποκλείει την εκτέλεση πολλαπλών DataNodes
στον ίδιο υπολογιστή. Η ύπαρξη ενός μόνο NameNode απλοποιεί σημαντικά την αρχιτεκτονική του
συστήματος.

Το";"""date"",""2020-11-05T13:15:53Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.5""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""language"",""el""
""Last-Modified"",""2020-11-05T13:15:53Z""
""dcterms:modified"",""2020-11-05T13:15:53Z""
""dc:format"",""application/pdf; version=1.5""
""Last-Save-Date"",""2020-11-05T13:15:53Z""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2020-11-05T13:15:53Z""
""meta:save-date"",""2020-11-05T13:15:53Z""
""pdf:encrypted"",""false""
""modified"",""2020-11-05T13:15:53Z""
""Content-Length"",""2878490""
""pdf:hasMarkedContent"",""false""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""111""
""resourceName"",""diploma_thesis_Alyzia_Konsta.pdf""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""264"",""0"",""560"",""743"",""1232"",""0"",""1015"",""0"",""477"",""0"",""1062"",""0"",""1227"",""0"",""2688"",""3493"",""479"",""2819"",""1939"",""2291"",""193"",""2713"",""1834"",""525"",""2671"",""2270"",""2069"",""1664"",""1878"",""619"",""1316"",""132"",""140"",""455"",""871"",""63"",""2388"",""21"",""1881"",""566"",""253"",""0"",""527"",""671"",""1015"",""0"",""555"",""0"",""1995"",""1159"",""2097"",""0"",""2810"",""2832"",""2611"",""2814"",""3185"",""1122"",""831"",""3590"",""3231"",""3671"",""1971"",""3196"",""1945"",""2893"",""3520"",""2517"",""934"",""2614"",""1000"",""2103"",""2509"",""22"",""2703"",""1837"",""2109"",""2826"",""3637"",""3366"",""2491"",""1534"",""1877"",""884"",""1199"",""3556"",""2543"",""3395"",""2494"",""2472"",""2452"",""2535"",""1484"",""2994"",""3500"",""1977"",""3381"",""1359"",""2015"",""3186"",""1882"",""576"",""1201"",""154"",""171"",""451"",""187"",""586"",""2047"",""1883"",""567""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""producer"",""www.ilovepdf.com""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""www.ilovepdf.com""
";https://scholar.google.ch/scholar?start=560&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098751-76;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Blockchain: instrumento de transparencia y control del sector público;JL Wanden;Berghe Lozano, E Fernández Daza 2020 rua.ua.es;;"… Se suele decir que en blockchain el código es la ley y el smart contract es código de progra-

mación que se mantiene de forma inalterable y transparente, conteniendo acuerdos entre las

partes. Para poder interactuar un smart contract requiere Ťoraclesť que transmiten la …";;;[PDF] ua.es;http://rua.ua.es/dspace/bitstream/10045/112586/1/Wanden-Berghe_Fernandez_2020_RevEspControlExterno.pdf;"
Found

The document has moved here.

";"""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""dc:title"",""302 Found""
""Content-Encoding"",""ISO-8859-1""
""resourceName"",""Wanden-Berghe_Fernandez_2020_RevEspControlExterno.pdf""
""language"",""en""
""Content-Length"",""287""
""title"",""302 Found""
""Content-Type"",""text/html; charset=ISO-8859-1""
";https://scholar.google.ch/scholar?start=620&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098787-160;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;A Tightly Secure DDH-based Multisignature with Public-Key Aggregation;M Fukumitsu, S Hasegawa ; 2020 Eighth International …, 2020  ieeexplore.ieee.org;;"… Concerning the application to the blockchain, multisignatures with public-key aggregation, which

can compress public keys of signers to a single public … public-key aggregation whose security

is proven to be tightly secure under the DDH assumption in the random oracle model …";Les 3 versions;;null;;;;https://scholar.google.ch/scholar?start=700&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098756-84;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;CVIN: Connected Vehicle Information Network;N Prakash, DG Michelson… ; 2020 IEEE 91st Vehicular …, 2020  ieeexplore.ieee.org;;"… This is mainly facilitated by the cryptography behind Indy, and may be supplemented

and supported by distributed oracles for “off-chain data” (ie, any data that originates

outside of the blockchain), such as 'Chainlink' [19]. Furthermore …";Autres articles;;null;;;;https://scholar.google.ch/scholar?start=630&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098804-199;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;A Blockchain Oriented Software Application in the Revised Payments Service Directive context;L Cocco, A Pinna, G Meloni ; Proceedings of the IEEE/ACM 42nd …, 2020  dl.acm.org;;"… Public Body, POR Sardegna FESR 2014/2020 EU grants: “SardCoin - SardCoin: tecnologie

blockchain a supporto … in Sardegna” - Top-down Cluster Projects;“EasyWallet” - R&D Grants for

R&D Projects; “Crypto-Trading”- R&D … [4] R. Gist, Building an Ethereum Oracle with Web3 …";Autres articles;;null;;;;https://scholar.google.ch/scholar?start=740&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098791-166;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Internal Controls;G Brennan, SK Dutta ; The Definitive Guide to Blockchain for …, 2020  emerald.com;;"… efficiently distribute. Not all of the cryptocurrency transactions are reported on

blockchain – preventing an end-to-end process or transaction audit – refer to the

previous discussion on “Off-line” transactions. The technology is …";Les 2 versions;;null;;;;https://scholar.google.ch/scholar?start=710&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098787-154;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Threshold Password-Hardened Encryption Services;J Brost, C Egger, RWF Lai, F Schmid… ; Proceedings of the …, 2020  dl.acm.org;;"… point of failure because key-derivation always requires access to the crypto service … The encrypt

and decrypt oracles EncO and DecO model normal interactions with adversarially … The decrypt

challenge oracle DecChO, in contrast, allows the adversary to observe interactions …";Cité 1 fois;Les 3 versions;[PDF] iacr.org;https://eprint.iacr.org/2020/1552.pdf;"
Threshold Password-Hardened Encryption Services
Julian Brost

Friedrich-Alexander University

Erlangen-Nuremberg

Christoph Egger

Friedrich-Alexander University

Erlangen-Nuremberg

Russell W. F. Lai

Friedrich-Alexander University

Erlangen-Nuremberg

Fritz Schmid

Friedrich-Alexander University

Erlangen-Nuremberg

Dominique SchrĂśder

Friedrich-Alexander University

Erlangen-Nuremberg

Markus Zoppelt

Nuremberg Institute of Technology

ABSTRACT
Password-hardened encryption (PHE) was introduced by Lai et

al. at USENIX 2018 and immediately productized by VirgilSecurity.

PHE is a password-based key derivation protocol that involves an

oblivious external crypto service for key derivation. The security

of PHE protects against offline brute-force attacks, even when the

attacker is given the entire database. Furthermore, the crypto ser-

vice neither learns the derived key nor the password. PHE supports

key-rotation meaning that both the server and crypto service can

update their keys without involving the user. While PHE signif-

icantly strengthens data security, it introduces a single point of

failure because key-derivation always requires access to the crypto

service. In this work, we address this issue and simultaneously

increase security by introducing threshold password-hardened en-

cryption. Our formalization of this primitive revealed shortcomings

of the original PHE definition that we also address in this work.

Following the spirit of prior works, we give a simple and efficient

construction using lightweight tools only. We also implement our

construction and evaluate its efficiency. Our experiments confirm

the practical efficiency of our scheme and show that it is more effi-

cient than common memory-hard functions, such as scrypt. From a

practical perspective this means that threshold PHE can be used as

an alternative to scrypt for password protection and key-derivation,

offering better security in terms of offline brute force attacks.

CCS CONCEPTS
• Security and privacy→ Cryptography.

ACM Reference Format:
Julian Brost, Christoph Egger, Russell W. F. Lai, Fritz Schmid, Dominique

SchrĂśder, and Markus Zoppelt. 2020. Threshold Password-Hardened En-

cryption Services. In Proceedings of the 2020 ACM SIGSAC Conference on
Computer and Communications Security (CCS ’20), November 9–13, 2020, Vir-
tual Event, USA. ACM, New York, NY, USA, 16 pages. https://doi.org/10.1145/

3372297.3417266

1 INTRODUCTION
An increasing amount of sensitive information is collected, pro-

cessed, and made accessible by online services. For several years

Permission to make digital or hard copies of part or all of this work for personal or

classroom use is granted without fee provided that copies are not made or distributed

for profit or commercial advantage and that copies bear this notice and the full citation

on the first page. Copyrights for third-party components of this work must be honored.

For all other uses, contact the owner/author(s).

CCS ’20, November 9–13, 2020, Virtual Event, USA
Š 2020 Copyright held by the owner/author(s).

ACM ISBN 978-1-4503-7089-9/20/11.

https://doi.org/10.1145/3372297.3417266

we witness a significant increase of data breaches and prominent

victims in 2019 include Capital One, Facebook, and Canva
1
, just to

name a few. Common encryption techniques to protect data acces-

sible on the Internet seem to be ineffective to prevent data breaches,

especially against insider attackers that have stolen the databases.

Not only can the attacker break the passwords of individual users

using offline brute-force attacks, but it can also directly learn the

master key and hence all user data.

Lai et al. [12] recently introduced password-hardened encryption

(PHE) as a password-based key-derivation protocol that involves

an external party, called rate-limiter, in addition to the server for

key derivation. Intuitively, PHE allows the server to derive a data

key that depends on the password of the user, the server key, and

the rate-limiter key, while the rate-limiter remains oblivious to the

password and the data key. The security of PHE states that neither

an active adversary having stolen the database nor the rate-limiter

alone should learn anything about the encoded password and the

data key. To recover the data key, a corrupt partymust communicate

with the other party, who rate-limits decryption attempts. Finally,

PHE supports key-rotation, which allows rotating the keys of the

server and rate-limiterwith succinct communication. Thereafter, the

server can locally update all ciphertexts without further interaction

with the rate-limiter or end-users. This property of key-rotation

is demanded by the payment card industry data security standard

(PCI DSS) [15]. PHE was directly productized by VirgilSecurity
2
.

While PHE significantly improves security, it also introduces a

single point of failure. If the rate-limiter is unreachable, e.g., due
to network failure or malicious attacks, the data would become

unavailable to the end-users as the server cannot provide decryption

service alone. Even worse, if the rate-limiter key is lost, then all

user data is effectively lost permanently. These potential issues may

discourage service providers from deploying PHE, as they may not

want to ultimately depend on third parties for emergency access to

their data. The naĂŻve solution of duplicating the rate-limiter into

multiple instances increases availability, but at a cost of security. If

anyone of the instances of the rate-limiter is corrupt, any benefit

brought by PHE would be nullified.

1.1 Our Contribution
Our main contributions are the invention, construction, and imple-

mentation of threshold password-hardened encryption with the

overall goal to address the availability and trust issues of PHE. The

1
https://en.wikipedia.org/wiki/List_of_data_breaches

2
https://developer.virgilsecurity.com/docs/use-cases/v1/passwords-and-data-

protection?_ga=2.168638369.1056320515.1579507576-2040416527.1579507576, https:

//virgilsecurity.com/wp-content/uploads/2019/04/PHE-Service-Technical-Paper.pdf

1

https://doi.org/10.1145/3372297.3417266
https://doi.org/10.1145/3372297.3417266
https://doi.org/10.1145/3372297.3417266
https://en.wikipedia.org/wiki/List_of_data_breaches
https://developer.virgilsecurity.com/docs/use-cases/v1/passwords-and-data-protection?_ga=2.168638369.1056320515.1579507576-2040416527.1579507576
https://developer.virgilsecurity.com/docs/use-cases/v1/passwords-and-data-protection?_ga=2.168638369.1056320515.1579507576-2040416527.1579507576
https://virgilsecurity.com/wp-content/uploads/2019/04/PHE-Service-Technical-Paper.pdf
https://virgilsecurity.com/wp-content/uploads/2019/04/PHE-Service-Technical-Paper.pdf


basic idea is to remove the single point of failure by spreading the

responsibility of a single rate-limiter to𝑚 independent rate-limiters.

We increase the availability by setting a threshold number 𝑡 that

are necessary and sufficient for successful en/decryption. The secu-

rity of ((𝑡,𝑚)-PHE) guarantees that as long as the adversary does

not control both the server and at least 𝑡 rate-limiters, (𝑡,𝑚)-PHE
schemes provide the same security guarantees like those of PHE

schemes. We stress that the rate-limiters are not aware of each

other and primarily interact with the server. Practically speaking,

this allows services to make use of rate-limiters hosted by differ-

ent providers, or even have some of them “in cold storage” locally

where they can be reactivated in emergency situations to avoid data

loss. Additionally, this allows strengthening security by requiring

more than one honest rate-limiter for successful decryption. In the

following, we discuss our contributions:

Formalization. We formalize (𝑡,𝑚)-PHE and define two security

properties, hiding and soundness, which consolidate und unify the

definitions of message hiding, partial obliviousness, (strong) sound-

ness, and forward security of PHE [12]. Note that since (𝑡,𝑚)-PHE
is a generalization of PHE (where 𝑡 =𝑚 = 1), we obtain also con-

solidated security definitions for PHE. In our model we assume

semi-adaptive corruptions, where the adversary must declare the

set of corrupt parties for the next time epoch when instructing a

key-rotation. Note that security under semi-adaptive corruption is

already stronger than the static security defined in [12], where the

corrupt party is fixed for the entire duration of the experiments.

Hiding. Hiding refers to the property that the adversary cannot

do better than performing online password guessing attacks to learn
an encrypted message, as long as it does not corrupt the server and

at least 𝑡 rate-limiters at the same time. Our hiding definition con-

solidates the previous hiding, obliviousness, and forward security

definitions of PHE [12]. In particular, the new hiding definition

captures attack strategies in which the adversary corrupts different

parties at different points in time.

Soundness. Soundness refers to the property that the server can-

not be fooled to make wrong decisions during decryption. More

precisely, it means that, for any fixed server secret key, a ciphertext

cannot encode two different valid password-message pairs at the

same time. Our soundness definition consolidates the previous ones

by capturing all attack strategies in a single security experiment.

Construction and Impossibility Result. We present a simple

and efficient construction that relies on lightweight cryptographic

components only. On a very high-level, our construction exploits

the linearity of the Shamir secret sharing scheme [18] and the El-

Gamal encryption scheme [6]. Assuming a communication model

where the rate-limiters are not allowed to communicate with each

other, the resulting encryption protocol consists of 3 rounds, while

the decryption protocol consists of 6 rounds. It has the nice property

that rate-limiters cannot tell whether the same incorrect password

was used in two failed decryption attempts of the same user. Re-

garding security, we prove that the construction is secure under

the DDH assumption in the random oracle model assuming semi-

adaptive corruption. Via a meta-reduction, we show that this result

is optimal and that the construction does not achieve our stronger

notion of full adaptivity. We also give evidence that an efficient yet

fully adaptively secure construction is unlikely to exist.

Implementation and Evaluation. Our prototypical implementa-

tion in Python confirms the practical efficiency of our construction.

We evaluated the latency and throughput of (𝑡,𝑚)-PHE for multiple

threshold levels 𝑡 and number of cores. The experimental evalu-

ation (see Section 4) shows that our (𝑡,𝑚)-PHE can process up

to 1045 encryption and up to 394 decryption requests per second.

Scaling (𝑡,𝑚)-PHE can easily be achieved by increasing the num-

ber of cores. Additionally, throughput performance increases faster

with the number of cores than it is slowed down by the number of

rate-limiters. Considering current recommendations for best prac-

tice [19] on password hashing and password-based key-derivation,

we note that algorithms like scrypt or Argon2 [5] are usually con-

figured to limit login throughput to tens of requests per second

which is significantly slower than using (𝑡,𝑚)-PHE.

1.2 Related Work
The original concept of password-hardening (PH) is due to Face-

book [14]. Everspaugh et al. [7] made the first step towards formal-

izing PH and identified key-rotation as the key property to make

such schemes useful in practice, which is also the key challenge

when designing PH and PHE schemes. The notion of PH has been

subsequently refined by Schneider et al. [16] and Lai et al. [13]. In
addition to password verification, Lai et al. [12] later introduced
the concept of password-hardened encryption (PHE) that allows

associated data to be encrypted under a per-user key that is inac-

cessible without the user’s password and provides strong security

guarantees analogous to those of PH.

The construction of (𝑡,𝑚)-PHE in this work is based on the

PHE scheme in [12], which in turn is based on the PH scheme

in [13]. As observed in [12], it is unclear how the PH scheme in [7]

(formalized as a partially oblivious pseudorandom function) can be

extended to a PHE scheme. Therefore, although the scheme in [7]

has a natural threshold variant, it is not helpful for constructing

(𝑡,𝑚)-PHE schemes.

A closely related notion is password-protected secret sharing

(PPSS) [4], which provides similar functionality as that of (𝑡,𝑚)-
PHE, with different formulations in syntax and security definitions.

The key feature separating (𝑡,𝑚)-PHE from PPSS is key-rotation. In-

deed, a (𝑡,𝑚)-PHE can be seen as a PPSS scheme with key-rotation.

Password-based threshold authentication (PbTA) [1] is a recent

related notion where, instead of recovering a data key, the goal

is to produce an authentication token which can be verified by

the service provider. Moreover, the PbTA scheme in [1] does not

support key-rotation.

2 DEFINITIONS
Preliminaries. Let _ ∈ N be the security parameter and𝑚 ∈ N.
The set {1, . . . ,𝑚} is denoted by [𝑚], and the set {𝑎, 𝑎 + 1, . . . , 𝑏} is
denoted by [𝑎, 𝑏]. We denote by

((𝑦1; view1), . . . , (𝑦𝑚 ; view𝑚))
← Π⟨P1 (𝑥1; 𝑟1), . . . ,P𝑚 (𝑥𝑚 ; 𝑟𝑚)⟩

the protocol Π between the interactive algorithms P1, . . . ,P𝑚 ,

whereP𝑖 has input𝑥𝑖 , randomness 𝑟𝑖 , output𝑦𝑖 , and view view𝑖 . The
2



view view𝑖 consists of the input 𝑥𝑖 , the input randomness 𝑟𝑖 , and all

messages received by P𝑖 during the protocol execution. Let 𝐼 ⊆ [𝑚].
We use the shorthand view𝐼 to denote the set {(𝑖, view𝑖 )}𝑖∈𝐼 . In case
that the output P𝑖 is not explicitly needed, we write ∗ instead of 𝑦𝑖 .
For ease of readability, we omit the randomness 𝑟𝑖 and/or the view

view𝑖 of P𝑖 if they are not explicitly needed. When the randomness

𝑟𝑖 is omitted, it means that 𝑟𝑖 is chosen uniformly from the appro-

priate domain. We use the special and distinct symbols 𝜖 and ⊥ to

denote the empty string and an error (e.g., protocol abortion), re-
spectively. Unless specified, the symbols 𝜖 and ⊥ are by default not

a member of any set considered. Let 𝑏 be a Boolean value. We use

the shorthand “ensure 𝑏” to denote the procedure which outputs

⊥ (prematurely) if 𝑏 ≠ 1.

Definition of (𝑡,𝑚)-PHE. Let 𝑡,𝑚 ∈ N with 𝑡 ≤ 𝑚. Let PW and

M be the password space and the message space, respectively. Let

S and R𝑖 refer to the server and the 𝑖-th rate-limiter respectively

for 𝑖 ∈ [𝑚].
A 𝑡-out-of-𝑚 threshold password-hardened encryption, or

((𝑡,𝑚)-PHE) scheme, for PW andM consists of the efficient al-

gorithms and protocols (Setup, Enc,Dec,Rotate,Udt), which we

define as follows:

(crs, sk
0
, . . . , sk𝑚) ← Setup(1_, 1𝑚, 1𝑡 ):

The setup algorithm inputs the security parameter _, the number of

rate-limiters𝑚, and the threshold 𝑡 in unary. It outputs the common

reference string crs, the secret key sk
0
for the server and the secret

key sk𝑖 for the 𝑖-th rate-limiter, for all 𝑖 ∈ [𝑚]. The common refer-

ence string is an implicit input to all other algorithms and protocols

for all parties.

((𝑛,𝐶), 𝜖, . . . , 𝜖) ← Enc

〈S(“enc”, sk0
, pw, 𝑀),

R1 (“enc”, sk1
),

. . . ,

R𝑚 (“enc”, sk𝑚)

〉
:

The encryption protocol is run between the server and (possibly

a subset of) the𝑚 rate-limiters. The server inputs its secret key,

a password pw ∈ PW, and a message 𝑀 ∈ M. The rate-limiters

input their respective secret keys. The server outputs a nonce 𝑛 and

a ciphertext 𝐶 , while each rate-limiter outputs an empty string 𝜖 .

(𝑀,𝑛1, . . . , 𝑛𝑚) ← Dec

〈S(“dec”, sk0
, pw, 𝑛0,𝐶),

R1 (“dec”, sk1
),

. . . ,

R𝑚 (“dec”, sk𝑚)

〉
:

The decryption protocol is run between the server and (possibly

a subset of) the𝑚 rate-limiters. The server inputs its secret key, a

candidate password pw ∈ PW, a nonce 𝑛0, and a ciphertext𝐶 . The

rate-limiters input their respective secret keys. The server outputs

a message 𝑀 . Each rate-limiter outputs a nonce 𝑛𝑖 which can be

interpreted as the identifier of the ciphertext 𝐶 in the view of R𝑖 .

((sk′
0
, 𝜏), sk′

1
, . . . , sk′𝑚) ← Rotate

〈 S(“rot”, sk0
),

R1 (“rot”, sk1
),

. . . ,

R𝑚 (“rot”, sk𝑚)

〉
:

The rotation protocol is run between the server and all 𝑚 rate-

limiters. Each party inputs its secret key and outputs a rotated key.

The server additionally outputs an update token 𝜏 .

𝐶 ′ ← Udt(𝜏, 𝑛,𝐶):
The update algorithm inputs an update token 𝜏 , a nonce 𝑛, and a

ciphertext 𝐶 . It outputs a new ciphertext 𝐶 ′.

Correctness. Correctness is defined in the obvious way and the

formal definition is omitted. Roughly speaking, a (𝑡,𝑚)-PHE is

correct whenever all honestly generated ciphertexts can be success-

fully decrypted to recover the encrypted message with the correct

password, at long as at least 𝑡 rate-limiters participate in the de-

cryption protocol. Moreover, if a ciphertext passes decryption with

respect to some secret keys, then the updated ciphertext also passes

decryption with respect to the rotated keys.

Remarks. Our model requires a trusted party to run the setup

algorithm. In a typical application of (𝑡,𝑚)-PHE it is acceptable to

let the server run the setup algorithm, send the rate-limiter keys

to the respective rate-limiters, and securely delete those keys. This

is because it is for the server’s own benefit to employ a (𝑡,𝑚)-
PHE scheme in the first place. Moreover, the rate-limiters do not

contribute any private inputs other than their secret keys in any

protocols. If we insist that the server cannot be trusted to run the

setup, a standard solution is to emulate the setup using a secure

multi-party computation (MPC) protocol.

In our syntax, we handle the nonces differently compared to the

approach in previous work [12]. We believe that the new approach

models the reality more closely and is more intuitive. Previously, the

encryption and decryption protocols take a “label” as common input

for both the server and the rate-limiter, where the label consists of a

server-side nonce and a rate-limiter-side nonce. This model deviates

from the reality where the nonce is generated during (instead of

before) the encryption protocol, stored by the server, and sent to the

rate-limiter during decryption. More confusingly, the label input to

the encryption protocol is by default an empty string, unless it is

called in the forward security experiment.

2.1 Security of (𝑡,𝑚)-PHE
We define the hiding and soundness properties of (𝑡,𝑚)-PHE. We

assume that each rate-limiter has an authenticated channel to the

server and that the rate limiters are not aware of each other, i.e., for

𝑖 ≠ 𝑗 , there may not exist any communication channel between R𝑖
and R 𝑗 . We focus on a semi-adaptive corruption model, where the

adversary must declare the set of corrupt parties for the next time

period, where a time period is the time between two honest key-

rotations. The possibility to corrupt parties during a time period

is modeled in the oracle RotateO, where the adversary can set

HonestRot to 1 and define a set 𝐼 for which he wishes to learn the

private-keys.

This corruption model is already stronger than that in previous

work [12, 13], where the adversary must declare the corrupt party at

the very beginning of the experiment, and cannot change its choice

throughout the experiment. For completeness, we also define a fully

adaptive variant, where the adversary can request to corrupt any

party at any time.

2.1.1 Hiding. Intuitively, hiding models the property that no party

should be able to do better than online brute force attacks against

the password space. As passwords have limited entropy, we limit

the adversary’s decryption queries using the counter DecCount
3



Hid𝑏
Π,A,𝑄Dec,PW (1

_, 1𝑚, 1𝑡 , 𝐼 )
1 : ensure |𝐼 ∩ [𝑚] | < 𝑡 ∨ 0 ∉ 𝐼

2 : IsChallenged := 0, 𝜏 := 𝜖, DecCount := 0

3 : CorruptParties := 𝐼

4 : (sk
0
, . . . , sk𝑚) ← Setup(1_, 1𝑚, 1𝑡 )

5 : O := {EncO,DecO, CorrO ,RotateO,
6 : UdtO,ChO𝑏 ,DecChO}
7 : 𝑏′ ← AO (1_, {sk𝑖 }𝑖∈𝐼 )
8 : if DecCount ≥ 𝑄Dec then 𝑏′ ←$ {0, 1}
9 : return 𝑏′

EncO(pw, 𝑀, 𝐼, {P𝑖 }𝑖∈𝐼 )
1 : ensure 𝐼 ⊆ CorruptParties

2 : S∗ := if 0 ∈ 𝐼 then PO
0
else := S(“enc”, sk

0
, pw, 𝑀)

3 : R∗𝑖 := if 𝑖 ∈ 𝐼 then PO𝑖 else R𝑖 (“enc”, sk𝑖 ) ∀𝑖 ∈ [𝑚]
4 : ( (𝑛,𝐶 ; view0), (∗; view1), . . . , (∗; view𝑚)) ← ⟨S∗, R∗1, . . . , R∗𝑚 ⟩
5 : return (𝑛,𝐶, view𝐼 )

DecO(pw, 𝑛0,𝐶, 𝐼 , {P𝑖 }𝑖∈𝐼 )
1 : ensure 𝐼 ⊆ CorruptParties

2 : S∗ := if 0 ∈ 𝐼 then PO
0
else := S(“dec”, sk

0
, pw, 𝑛0,𝐶)

3 : R∗𝑖 := if 𝑖 ∈ 𝐼 then PO𝑖 else R𝑖 (“dec”, sk𝑖 , 𝑛) ∀𝑖 ∈ [𝑚]
4 : ( (𝑀 ; view0), (𝑛1; view1), . . . , (𝑛𝑚 ; view𝑚)) ← ⟨S∗, R∗1, . . . , R∗𝑚 ⟩
5 : 𝑏0 := (0 ∈ 𝐼 ∨ 𝑛0 = 𝑛∗)
6 : 𝑏1 := ( |𝐼 ∩ [𝑚] | + | {𝑖 : 𝑛𝑖 = 𝑛

∗ } | ≥ 𝑡 )
7 : if 𝑏0 ∧ 𝑏1 then DecCount := DecCount + 1

8 : return (𝑀, view𝐼 )

DecChO(𝐶, 𝐼, {P𝑖 }𝑖∈𝐼 )
1 : ensure IsChallenged = 1 ∧ 𝐼 ⊆ CorruptParties \ {0}
2 : S∗ := S(“dec”, sk

0
, pw∗, 𝑛∗,𝐶)

3 : R∗𝑖 := if 𝑖 ∈ 𝐼 then PO𝑖 else R𝑖 (“dec”, sk𝑖 , 𝑛) ∀𝑖 ∈ [𝑚]
4 : ( (∗; view0), . . . , (∗; view𝑚)) ← ⟨S∗, R∗1, . . . , R∗𝑚 ⟩
5 : return view𝐼

RotateO(HonestRot, 𝐼 , {P𝑖 }𝑖∈𝐼 )
1 : if HonestRot = 1 then // Honest rotation then corruption

2 : ensure |𝐼 ∩ [𝑚] | < 𝑡 ∨ 0 ∉ 𝐼

3 : S∗ := S(“rot”, sk
0
)

4 : R∗𝑖 := R𝑖 (“rot”, sk𝑖 ) ∀𝑖 ∈ [𝑚]
5 : ( (sk

0
, 𝜏), sk

1
, . . . , sk𝑚) ← ⟨S∗, R∗1, . . . , R∗𝑚 ⟩

6 : CorruptParties := 𝐼

7 : return {sk𝑖 }𝑖∈𝐼
8 : else // Malicious rotation

9 : ensure 𝐼 ⊆ CorruptParties

10 : S∗ := if 0 ∈ 𝐼 then PO
0
else S(“rot”, sk

0
)

11 : R∗𝑖 := if 𝑖 ∈ 𝐼 then PO𝑖 else R𝑖 (“rot”, sk𝑖 ) ∀𝑖 ∈ [𝑚]
12 : ( (sk

0
, 𝜏 ; view0), (sk1

; view1), . . . , (sk𝑚 ; view𝑚)) ←
13 : ⟨S∗, R∗

1
, . . . , R∗𝑚 ⟩

14 : return view𝐼

15 : endif

CorrO(𝑖) Only available in fully adaptive variant

1 : CorruptParties′ := CorruptParties ∪ {𝑖 }
2 : ensure |CorruptParties′ ∩ [𝑚] | < 𝑡 ∨ 0 ∉ CorruptParties′

3 : CorruptParties := CorruptParties′

4 : return sk𝑖

UdtO(𝑛,𝐶)
1 : ensure 𝜏 ≠ 𝜖

2 : 𝐶′ ← Udt(𝜏,𝑛,𝐶)
3 : return𝐶′

ChO𝑏 (𝑀∗0 , 𝑀
∗
1
, 𝐼 , {P𝑖 }𝑖∈𝐼 )

1 : ensure IsChallenged = 0 ∧ 𝐼 ⊆ CorruptParties \ {0}
2 : IsChallenged := 1, pw∗ ←$ PW
3 : S∗ := S(“enc”, sk

0
, pw∗, 𝑀∗

𝑏
)

4 : R∗𝑖 := if 𝑖 ∈ 𝐼 then PO𝑖 else R𝑖 (“enc”, sk𝑖 ) ∀𝑖 ∈ [𝑚]
5 : ( (𝑛∗,𝐶∗), (∗; view1), . . . , (∗; view𝑚)) ← ⟨S∗, R∗1, . . . , R∗𝑚 ⟩
6 : return (𝑛∗,𝐶∗, view𝐼 )

Figure 1: Hiding Experiment (Procedures in dashed boxes are provided for variant with fully adaptive corruption.)

which is bounded by 𝑄Dec. At any given time, the adversary may

either corrupt the server and up to 𝑡 −1 rate limiters, or an arbitrary

subset of rate-limiters but not the server. It can also instruct the

parties to execute an honest key-rotation, after which all parties

are considered honest, and the adversary can corrupt a possibly

different subset of parties again.

The Oracles. The (encryption, decryption, key rotation, and cipher-
text update) oracles are formally defined in Figure 1. The oracles

interface protocol executions by inputting a set of adversarial proce-

dures and running the respective protocols with the codes of some

honest parties replaced. The encrypt and decrypt oracles EncO and

DecO model normal interactions with adversarially choosen mes-

sages resp. ciphertexts. The decrypt challenge oracle DecChO, in
contrast, allows the adversary to observe interactions between an

honest server and potentially malicious rate-limiters with the cor-

rect challenge password. The oracle RotateO allows the adversary

to request key-rotation. The adversary can request for an honest

key-rotation, where the update token remains secret, while the set

of corrupted parties is reset depending on the choice of the adver-

sary. The adversary can also request for a malicious key-rotation,

where the code of some parties are possibly replaced by malicious

ones. The oracle UdtO allows updating any ciphertext with the

4



most recent update token 𝜏 . In the fully adaptive variant, the ad-

versary gains access to an additional corrupt oracle CorrO from

which it can learn the current secret keys of parties of its choice.

Finally, the adversary can generate a challenge ciphertext using

ChO. Notice that the challenge may only be generated once
3
and

the server code used to generate the challenge ciphertext is honest

(although the server key might be revealed via CorrO and RotateO).
Intuitively this is reasonable as a malicious server can store the mes-

sage and the password outside the protocol, and therefore security

for maliciously generated ciphertexts is unrealistic.

Definition 1 (Hiding) . A (𝑡,𝑚)-PHE Π is semi-adaptively
hiding if, for any PPT adversary A, any integer 𝑄Dec ≥ 0, and any
password space PW4 with support size of at least 𝑄Dec,

1

2

��� Pr

[
Hid0

Π,A,𝑄Dec,PW (1
_, 1𝑚, 1𝑡 ) = 1

]
−

Pr

[
Hid1

Π,A,𝑄Dec,PW (1
_, 1𝑚, 1𝑡 ) = 1

] ��� ≤ 𝑄Dec

|PW| + negl (_ ) .

The (𝑡,𝑚)-PHE Π is fully adaptively hiding if in Hid the adversary
A is given access to the CorrO oracle.

2.1.2 Soundness. Our definition of soundness is inspired by the

complete robustness definition [8] for encryption schemes, which

intuitively captures the property that a ciphertext cannot be encrypt-

ing two distinct messages. In [12], the soundness of PHE requires

that there is no inconsistency between an encryption session and a

decryption session, whereas the strong soundness notion further

requires that there is no inconsistency between two decryption

sessions. To unify both deception strategies, we define a sound-

ness experiment where the adversary is given an encryption and a

decryption oracle. The former takes as input all the inputs of the

server, including the randomness, during an encryption session,

and possibly malicious programs for all the rate-limiters. The oracle

then runs the encryption protocol between an honest execution

of the server code on the given input, and the possibly malicious

rate-limiters. The decryption oracle is defined in a similar way, ex-

cept that the decryption protocol is run. The adversary is successful

if an inconsistency occur between the communication transcripts

produced by any two oracle queries.

Definition 2 (Soundness) . A (𝑡,𝑚)-PHE Π is sound if,
for any PPT adversary A,

Pr

[
Soundness0

Π,A (1
_, 1𝑚, 1𝑡 ) = 1

]
≤ negl (_ ) .

3 CONSTRUCTION
Our construction of a (𝑡,𝑚)-PHE scheme can be seen as a gen-

eralization of the PHE scheme of [12], where a secret key of one

rate-limiter is shared to multiple rate-limiters. In contrast to [12] it

uses a private-key encryption scheme and exploits the linearity of

the Shamir secret sharing [18] and the ElGamal encryption [6].

3
A multi-challenge version of the definition is implied by the single-challenge one

using standard hybrid argument.

4
For simplicity, we assume that passwords are distributed uniformly in the pass-

word space. The definition can be easily generalized to cover arbitrary password

distributions.

3.1 Construction Overview
Let G be a cyclic group of prime order 𝑝 with generator 𝐺 , and

let 𝐻0, 𝐻1 : {0, 1}∗ → G be two independent hash functions. A

ciphertext 𝐶 = SKE.Enc(𝑠0, (𝐶0,𝐶1)) consists of a symmetric-key

ciphertext of two group elements𝐶0 and𝐶1 under the server secret

key component 𝑠0, and is accompanied by a nonce 𝑛. The elements

𝐶0 and 𝐶1 are computed as follows

𝐶0 = 𝐻0 (pw, 𝑛) · 𝐻0 (𝑛)𝑠0

𝐶1 = 𝐻1 (pw, 𝑛) · 𝐻1 (𝑛)𝑠0 ·𝑀

where 𝑠0 is part of the conceptual rate-limiter secret key, and 𝑀

is the encrypted message. The conceptual key 𝑠0 is secret-shared

among𝑚 rate-limiters using the well-known Shamir secret sharing

scheme with reconstruction threshold 𝑡 . In contrast to [12], we

do not distinguish between server and rate-limiter nonces. In our

scheme, the nonce𝑛 is obtained via a coin-flipping protocol between

the server and 𝑡 rate-limiters. The server key is now used in a secret-

key encryption scheme to allow for stronger security properties.

An important feature of the Shamir secret sharing scheme is that

the reconstruction function is linear. That is, given a set of 𝑡 shares

and their indices {(𝑖 𝑗 , 𝑠𝑖 𝑗 )}𝑡𝑗=1
, there exists a public linear combina-

tion with some coefficients (_1, . . . , _𝑡 ) such that 𝑠0 =
∑𝑡
𝑗=1

_ 𝑗𝑠𝑖 𝑗 .

This feature is crucial for the decryption protocol, as we will see.

3.2 Formal Description
Ingredients. Given a finite set P of size |P | ≥ 𝑡 , let Subset𝑡 (P)

be an algorithm which returns an arbitrary size-𝑡 subset 𝑃 of P.
Let GGen : 1

_ ↦→ (G, 𝑝,𝐺) be a group generation algorithm which

maps the security parameter 1
_
to the description (G, 𝑝,𝐺) of a

cyclic groupG of prime order 𝑝 with generator𝐺 . Let 𝑡,𝑚 ∈ Nwith

𝑡 ≤ 𝑚 ≤ 𝑝 . For any subset 𝑃 ⊆ [𝑚] and 𝑖 ∈ 𝑃 , recall the Lagrange
polynomial ℓ𝑃,𝑖 (𝑥) :=

∏
𝑗 ∈𝑃\{𝑖 }

𝑥−𝑗
𝑖−𝑗 . Let _𝑃,𝑖 := ℓ𝑃,𝑖 (0). For the ease

of notation, we define _𝑃,0 := 1 for all 𝑃 . Let 𝐻0, 𝐻1 : {0, 1}∗ → G
and𝐻 : {0, 1}∗ → {0, 1}_ be independent hash functions to be mod-

eled as random oracles. Let SKE.(KGen, Enc,Dec) be a symmetric-

key encryption scheme. Let (GGen, Prove,Vf) be a non-interactive
zero-knowledge proof of knowledge (NIZKPoK) scheme for the

relation

𝑅GDL :=



(G,𝐺, 𝑝),©­­«
𝐴1,1 . . . 𝐴1,𝑛 𝐵1

.

.

.
. . .

.

.

.
.
.
.

𝐴𝑚,1 . . . 𝐴𝑚,𝑛 𝐵𝑚

ª®®¬ ∈ G𝑚×(𝑛+1) ,
(𝑥1, . . . , 𝑥𝑛) ∈ Z𝑛𝑝 :

∀𝑖 ∈ [𝑚], 𝐵𝑖 =
∏𝑛
𝑗=1
𝐴
𝑥 𝑗
𝑖, 𝑗


as described in Appendix A.2. Here, the tuple (G,𝐺, 𝑝) is a com-

mon reference string, the matrix in G𝑚×(𝑛+1) is the statement, and

(𝑥1, . . . , 𝑥𝑛) ∈ Z𝑛𝑝 is a witness satisfying the statement.

Setup (Figure 3). The setup algorithm runs GGen to generate

the description of the group. It then generates the secret keys

sk
0
, . . . , sk𝑚 ,where sk𝑖 has the format (𝑠𝑖 , 𝑘𝑖 , 𝐾0, {𝑆 𝑗 , 𝐾𝑗 }𝑡−1

𝑗=0
)where

5



SoundnessΠ,A (1_)
1 : Queries := ∅
2 : O := {EncO,DecO }

3 : (𝑖, 𝑗) ← AO (1_)
4 : (sk

0
, 𝑛,𝐶, pw, 𝑀) := Queries[𝑖 ]

5 : (sk′
0
, 𝑛′,𝐶′, pw′, 𝑀′) := Queries[ 𝑗 ]

6 : 𝑏0 := ( (sk
0
,𝐶) = (sk′

0
,𝐶′))

7 : 𝑏1 := (𝑀 ≠ ⊥ ∧𝑀′ ≠ ⊥)
8 : 𝑏2 := ( ( (𝑛, pw) = (𝑛′, pw′)) ∧ (𝑀 ≠ 𝑀′))
9 : 𝑏3 := ( ( (𝑛, pw) ≠ (𝑛′, pw′)) ∧ (𝑀,𝑀′ ∈ M))
10 : return 𝑏0 ∧ 𝑏1 ∧ (𝑏2 ∨ 𝑏3)

EncO(sk
0
, pw, 𝑀, 𝑟,𝑚, ˜R1, . . . , ˜R𝑚)

1 : ( (𝑛,𝐶), ∗, . . . , ∗) ← ⟨S(“enc”, sk
0
, pw, 𝑀 ; 𝑟 ), ˜RO

1
, . . . , ˜RO𝑚 ⟩

2 : Queries := Queries âˆ";"""date"",""2020-08-25T10:25:31Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""Threshold Password-Hardened Encryption Services""
""xmp:CreatorTool"",""LaTeX with acmart 2020/04/30 v1.71 Typesetting articles for the Association for Computing Machinery and hyperref 2020-05-15 v7.00e Hypertext links for LaTeX""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""-  Security and privacy  ->  Cryptography.""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with acmart 2020/04/30 v1.71 Typesetting articles for the Association for Computing Machinery and hyperref 2020-05-15 v7.00e Hypertext links for LaTeX""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""Threshold Password-Hardened Encryption Services""
""modified"",""2020-08-25T10:25:31Z""
""cp:subject"",""-  Security and privacy  ->  Cryptography.""
""pdf:docinfo:subject"",""-  Security and privacy  ->  Cryptography.""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""Julian Brost, Christoph Egger, Russell W. F. Lai, Fritz Schmid, Dominique SchrĂśder, and Markus Zoppelt""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.21 (TeX Live 2020/W32TeX) kpathsea version 6.3.2""
""meta:author"",""Julian Brost, Christoph Egger, Russell W. F. Lai, Fritz Schmid, Dominique SchrĂśder, and Markus Zoppelt""
""trapped"",""False""
""meta:creation-date"",""2020-08-25T10:25:31Z""
""created"",""2020-08-25T10:25:31Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-08-25T10:25:31Z""
""resourceName"",""1552.pdf""
""Author"",""Julian Brost, Christoph Egger, Russell W. F. Lai, Fritz Schmid, Dominique SchrĂśder, and Markus Zoppelt""
""producer"",""pdfTeX-1.40.21""
""pdf:docinfo:producer"",""pdfTeX-1.40.21""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""1"",""8"",""3"",""36"",""17"",""65"",""157"",""59"",""23"",""0"",""0"",""60"",""56"",""23"",""3""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""Julian Brost, Christoph Egger, Russell W. F. Lai, Fritz Schmid, Dominique SchrĂśder, and Markus Zoppelt""
""dcterms:created"",""2020-08-25T10:25:31Z""
""Last-Modified"",""2020-08-25T10:25:31Z""
""dcterms:modified"",""2020-08-25T10:25:31Z""
""title"",""Threshold Password-Hardened Encryption Services""
""Last-Save-Date"",""2020-08-25T10:25:31Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2020-08-25T10:25:31Z""
""meta:save-date"",""2020-08-25T10:25:31Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.21 (TeX Live 2020/W32TeX) kpathsea version 6.3.2""
""Content-Length"",""767770""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Julian Brost, Christoph Egger, Russell W. F. Lai, Fritz Schmid, Dominique SchrĂśder, and Markus Zoppelt""
""dc:language"",""en""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""16""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""5192"",""5587"",""5084"",""3108"",""4711"",""3811"",""3212"",""2293"",""3526"",""4983"",""4396"",""4566"",""3978"",""2733"",""5164"",""3234""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-08-25T10:25:31Z""
";https://scholar.google.ch/scholar?start=700&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098756-81;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Impacto del Blockchain en el sistema financiero mundial y su relación con el marketing financiero y digital;R Márquez de Amo ;2020 tauja.ujaen.es;;"… transparente. Por el hecho de estar plasmados dentro de una red Blockchain, los Contratos …

Oráculos: Una de las características más importantes para que un smart contract pueda interactuar

con el mundo real, son los llamados oráculos (oracles en inglés). Los …";Autres articles;Version HTML;[PDF] ujaen.es;http://tauja.ujaen.es/jspui/bitstream/10953.1/12463/1/Envio%20tardio.%20-%20TFG_Rubn_Mrquez_de_Amo_BUENO.pdf;"
 

 

  

Trabajo Fin de Grado 

Impacto del Blockchain en el sistema 

financiero mundial y su relaciĂłn con el 

marketing financiero y digital  

Alumno: RubĂŠn MĂĄrquez de Amo 

 

Mayo, 2020 

F
a

c
u

lt
a

d
 d

e
 C

ie
n

c
ia

s
 S

o
c
ia

le
s
 y

 J
u

rĂ­
d

ic
a

s
 

G
ra

do
 e

n 
F

in
an

za
s 

y 
C

on
ta

bi
lid

ad
 



 

PĂĄgina 2 de 30 
 

Contenido 

Impacto del Blockchain en el sistema financiero mundial y su relaciĂłn con el 

marketing financiero y digital ....................................................................................... 1 

Resumen .......................................................................................................................... 4 

IntroducciĂłn .................................................................................................................... 5 

1.1. OrĂ­genes del Blockchain .................................................................................. 5 

1.2. Normativa ......................................................................................................... 6 

1.3. Concepto del Blockchain ................................................................................. 6 

1.4. Bitcoin: El nacimiento de la banca descentralizada ..................................... 7 

1.4.1.Blockchain pĂşblicas. Tipos. .......................................................................... 8 

1.4.2.Blockchain privadas. ..................................................................................... 8 

1.5. La banca: Pionera por necesidad ................................................................... 9 

1.6. Ecosistema espaĂąol de blockchain en los servicios financieros. ................... 9 

2. Funcionamiento del Blockchain .......................................................................... 13 

2.1. Elementos bĂĄsicos. ......................................................................................... 13 

2.2. Ventajas .......................................................................................................... 14 

2.3. Aplicaciones .................................................................................................... 14 

3. Matrices DAFO de la banca tradicional y del Blockchain................................ 15 

3.1. Banca tradicional ........................................................................................... 15 

3.1.1.Debilidades: .................................................................................................. 15 

3.1.2.Amenazas ...................................................................................................... 15 

3.1.3.Fortalezas ..................................................................................................... 15 

3.1.4.Oportunidades ............................................................................................. 16 

3.2. Blockchain ...................................................................................................... 16 

3.2.1.Debilidades: .................................................................................................. 16 

3.2.2.Amenazas ...................................................................................................... 16 



 

PĂĄgina 3 de 30 
 

3.2.3.Fortalezas ..................................................................................................... 16 

3.2.4.Oportunidades ............................................................................................. 16 

4. Marketing financiero y digital basado en Blockchain ....................................... 17 

4.1. Marketing Financiero .................................................................................... 17 

4.1.1Objetivo y ventajas del marketing financiero ............................................ 18 

4.1.2.Aplicaciones del marketing financiero ...................................................... 18 

4.2. Blockchain y Criptomoneda ......................................................................... 21 

4.2.1. Criptomonedas y los smart contracts ................................................... 21 

4.3. Marketing digital de los productos financieros ........................................... 23 

4.3.1. Transparencia ......................................................................................... 23 

4.3.2. “Cero” intermediarios ............................................................................ 23 

4.3.3. Identidad del consumidor ...................................................................... 23 

4.3.4. Responsabilidad pĂşblica ........................................................................ 24 

4.3.5. Beneficios de la marca ............................................................................ 24 

4.3.6. Ventajas del Blockchain en el marketing digital ................................. 24 

4.4. Caso Estonia ................................................................................................... 25 

5. ConclusiĂłn ............................................................................................................. 28 

6. BibliografĂ­a ............................................................................................................ 30 

 

  



 

PĂĄgina 4 de 30 
 

Resumen 

En este trabajo fin de grado, voy a tratar de hablar sobre un tema que estĂĄ creciendo de 

manera exponencial en los Ăşltimos aĂąos, la tecnologĂ­a Blockchain (cadena de bloques) y 

cĂłmo la cual se relaciona con el marketing financiero y/o digital. 

 

 

Abstract: 

In this final degree project, I am going to talk about a topic that is growing 

exponentially in recent years, Blockchain technology and how it is related to financial 

and/or digital marketing.  



 

PĂĄgina 5 de 30 
 

IntroducciĂłn 

Hasta hace pocos aĂąos, las aplicaciones financieras utilizaban como referencia y punto 

de origen el sistema bancario tradicional, caracterizado por el uso de bancos y otras 

instituciones financieras como agentes de intercambio y de respaldo financiero. Eran 

extensiones o especializaciones de los bancos y otros entes financieros. En la actualidad 

el uso masivo de la tecnologĂ­a blockchain, que no es nueva en realidad, ha permitido el 

crecimiento exponencial del nĂşmero de herramientas financieras que no dependen ni 

fĂ­sica, ni funcionalmente de ningĂşn intermediario, haciendo obsoleto el papel de las 

grandes multinacionales de servicios financieros.  

 

1.1.  OrĂ­genes del Blockchain 

DetrĂĄs de cada tipo de criptomoneda se encuentra la tecnologĂ­a subyacente llamada 

cadena de bloques. 

SegĂşn (Haber, Stornetta, 1991) fueron los cientĂ­ficos que introdujeron una soluciĂłn 

prĂĄctica para que los documentos digitales no pudieran ser manipulados ni modificados. 

Este sistema contaba con una cadena de bloques con seguridad criptogrĂĄfica para el 

almacenamiento de documentos, y fue al aĂąo siguiente cuando se incorporĂł al diseĂąo 

los ĂĄrboles Merckle, lo cual hizo mĂĄs eficiente el sistema al permitir que varios 

documentos se reunieron en un solo bloque. Debido a que la patente caducĂł en 2004  no 

se pudo utilizar, curiosamente 4 aĂąos antes de la apariciĂłn del Bitcoin (primera 

criptomoneda virtual). 

 

En 2004, el informĂĄtico y activista (Finney 2004), introdujo un sistema llamado RPoW 

Reusable Proof Of Work (Prueba de Trabajo reutilizable). Este sistema empezĂł a 

funcionar al recibir Finney un token de prueba intercambiable que luego podrĂ­a 

transferirse de un individuo a otro. 

 

 

 



 

 

Fuente: Linux Foundation 

1.2.  Normativa 

No hay ninguna normativa especĂ­fica que regule su actuaciĂłn y su proceso, aunque la 

empresa Chainalysis (funciona como un tipo de auditorĂ­a), persigue el fraude y las 

actividades ilĂ­citas dentro de la r

El papel principal de un organismo internacional y con presencia en todo el mercado 

financiero, seria regular la tecnologĂ­a blockchain, sobre todo su funcionamiento y evitar 

con ello su uso inapropiado ( tráfico de armas, drogas  etc…).

Sin embargo se debe considerar que las transferencias de bitcoins y de otro tipo de 

criptomonedas son legales en Europa, debido a que el Tribunal de Justicia de la UniĂłn 

Europea en sentencia del 2015 califico a esta moneda electrĂłnica como divisa virtual 

solo a efectos de IVA; de igual manera, la Agencia Tributaria espaĂąola publicĂł en 2016, 

por medio de una consulta vinculante, que la creaciĂłn de estas monedas es legal y que la 

actividad econĂłmica correspondiente deberĂ­a ser declarada bajo el epĂ­grafe de otros 

servicios financieros. 

 

1.3. Concepto del Blockchain

Una de las definiciones mĂĄs aceptadas del novedoso y aĂşn gran desconocido 

Blockchain, serĂ­a aquella tecnologĂ­a que desarrolla el Bitcoin y permite la eliminaciĂłn 

de todo tipo de intermediarios.  Su utilidad s

todas las transacciones de manera eficaz e eficiente.

 

No hay ninguna normativa especĂ­fica que regule su actuaciĂłn y su proceso, aunque la 

empresa Chainalysis (funciona como un tipo de auditorĂ­a), persigue el fraude y las 

actividades ilĂ­citas dentro de la red blockchain. 

El papel principal de un organismo internacional y con presencia en todo el mercado 

financiero, seria regular la tecnologĂ­a blockchain, sobre todo su funcionamiento y evitar 

con ello su uso inapropiado ( tráfico de armas, drogas  etc…). 

embargo se debe considerar que las transferencias de bitcoins y de otro tipo de 

criptomonedas son legales en Europa, debido a que el Tribunal de Justicia de la UniĂłn 

Europea en sentencia del 2015 califico a esta moneda electrĂłnica como divisa virtual 

a efectos de IVA; de igual manera, la Agencia Tributaria espaĂąola publicĂł en 2016, 

por medio de una consulta vinculante, que la creaciĂłn de estas monedas es legal y que la 

actividad econĂłmica correspondiente deberĂ­a ser declarada bajo el epĂ­grafe de otros 

Concepto del Blockchain 

Una de las definiciones mĂĄs aceptadas del novedoso y aĂşn gran desconocido 

Blockchain, serĂ­a aquella tecnologĂ­a que desarrolla el Bitcoin y permite la eliminaciĂłn 

de todo tipo de intermediarios.  Su utilidad se basa en la capacidad de almacenar de 

todas las transacciones de manera eficaz e eficiente. 

PĂĄgina 6 de 30 

 

No hay ninguna normativa especĂ­fica que regule su actuaciĂłn y su proceso, aunque la 

empresa Chainalysis (funciona como un tipo de auditorĂ­a), persigue el fraude y las 

El papel principal de un organismo internacional y con presencia en todo el mercado 

financiero, seria regular la tecnologĂ­a blockchain, sobre todo su funcionamiento y evitar 

embargo se debe considerar que las transferencias de bitcoins y de otro tipo de 

criptomonedas son legales en Europa, debido a que el Tribunal de Justicia de la UniĂłn 

Europea en sentencia del 2015 califico a esta moneda electrĂłnica como divisa virtual 

a efectos de IVA; de igual manera, la Agencia Tributaria espaĂąola publicĂł en 2016, 

por medio de una consulta vinculante, que la creaciĂłn de estas monedas es legal y que la 

actividad econĂłmica correspondiente deberĂ­a ser declarada bajo el epĂ­grafe de otros 

Una de las definiciones mĂĄs aceptadas del novedoso y aĂşn gran desconocido 

Blockchain, serĂ­a aquella tecnologĂ­a que desarrolla el Bitcoin y permite la eliminaciĂłn 

e basa en la capacidad de almacenar de 



 

PĂĄgina 7 de 30 
 

El Blockchain es una tecnologĂ­a que se basa en una cadena de bloques, transacciones,  

operaciones descentralizadas y pĂşblicas. Esta red de bloques, que a su vez estĂĄ formada 

por nodos,  tiene el acceso a la misma informaciĂłn. El sistema es muy seguro y menos 

expuesto a posibles fraudes, debido a que si un nodo detecta un intento de acceder al 

sistema, el resto de nodos tratarĂĄn de bloquearlo y la amenaza habĂ­a desaparecido. 

 

Este sistema es bastante Ăştil y prĂĄctico para los auditores, debido a que existe una 

trazabilidad de cada transacciĂłn, cada participante puede rastrear cada transacciĂłn.  

 

1.4.  Bitcoin: El nacimiento de la banca descentralizada 

En los aĂąos 90, un grupo de personas conocidas como cypherpunks, tomaron la 

decisiĂłn de aprovechar el gran potencial de la infraestructura de internet y crear un 

sistema financiero abierto, sin organismos centrales, transparente, anĂłnimo y que 

garantizase la oferta monetaria. 

            DespuĂŠs de aĂąos de tediosos esfuerzos y altos dispendios, surgiĂł en 2008 la 

creaciĂłn de la primera cripto-divisa de la historia: El Bitcoin. 

Es la moneda virtual mĂĄs popular, la cual fue creada en 2009 por una persona o grupo 

de personas bajo el pseudĂłnimo de  Satoshi Nakamoto. Actualmente, es la 

criptomoneda virtual mĂĄs utilizada. 

A diferencia de los precedentes mĂŠtodos de pago, los cuĂĄles estĂĄn centralizados en una 

entidad bancaria o similar, Bitcoin se sustenta en una red criptogrĂĄfica, persona a 

persona que no depende de ninguna manera de intermediarios financieros como 

instituciones financieras, banca, etc. Con todo esto, la tecnologĂ­a Blockchain pone en 

jaque todo un sistema anquilosado en el pasado e ineficaz. 

Todo individuo que desee invertir-poseer bitcoin, primero debe de tener una billetera 

electrĂłnica, es decir un dispositivo electrĂłnico que les permita comprar Bitcoin digitales 

en lĂ­nea. No es posible vender Bitcoin digitales al descubierto, en este sentido es un 

punto a favor de la Banca tradicional, ya que la Blockchain en un futuro deberĂ­a de 

desarrollar una aplicación que permita a los cedentes de crédito “descontar” 

criptodivisas digitales, cobrando una comisiĂłn por descubierto al igual que aplica la 



 

PĂĄgina 8 de 30 
 

banca tradicional, este serĂ­a el punto a mejorar de la cadena de bloques, si mejora esto 

puede ser un punto de inflexiĂłn para la banca como la conocemos a dĂ­a de hoy. 

Con esto se comenzĂł un camino hacia la descentralizaciĂłn, es decir, no era necesario 

ningĂşn banco o terceros para llevar a cabo las funciones propias de los bancos. Los 

pagos, las transferencias internacionales y las remesas fueron las primeras operaciones 

en verse sometidas a este profundo cambio. Por ende, fue el primer caso de uso de la 

tecnologĂ­a blockchain. 

Blockchain pĂşblicas. Tipos. 

CaracterĂ­stica Principal: Son abiertas y cualquier individuo puede acceder a ellas. 

Se dividen en clĂĄsicas y nuevas: 

 Clásicas :  Bitcoin , Ethereum, Webcoin, Litecoin 

 Nuevas: 

- Abra (goabra.com): Servicio de remesas persona a persona. Sin necesidad 

de cuenta bancaria 

- BitPesa (bitpesa.com): Esta plataforma se ha especializado en envĂ­os de 

dinero desde África y hacia este continente, en países como Kenia, Nigeria, 

Tanzania y Uganda. Se orienta a negocios de importaciĂłn y exportaciĂłn 

- Circle (circle.com): Startup la cual permite realizar envĂ­os de dinero si 

comisiones. Solamente es vĂĄlido para envĂ­os a paĂ­ses sin cuentas bancarias o 

con controles de divisas, suele recurrir por tanto, a criptodivisas. 

- Rebellion: Es una app colaborativa en la que se incentiva que el usuario 

“piloto” atraiga a otros usuarios, incentivando mediante entrega de divisa 

oficial (Euros, dólares etc…) o mediante la entrega de criptodivisas, por cada 

miembro nuevo. Sin comisiones. 

 

Blockchain privadas.  

Son redes cerradas las cuales son Ăştiles para la tarea de administraciĂłn de base de datos 

o para labores de auditorĂ­a (trazabilidad de la blockchain). Podemos mencionar a 

Ripple (ripple.com): Su especialidad son los pagos internacionales interbancarios, asĂ­ 

como el proceso de conversiĂłn de divisas. 



 

PĂĄgina 9 de 30 
 

1.5.  La banca: Pionera por necesidad 

El sector financiero ha sido el primero en aprovechar el mĂĄximo potencial de este 

revolucionario sistema. SegĂşn (DĂ­ez y GĂłmez, 2018), debido a la profunda crisis que 

experimentĂł la banca y que le ocasionĂł grandes problemas para mantener la 

rentabilidad hasta la fecha. Con todo esto de antemano, la banca decidiĂł apostar 

fuertemente por esta tecnologĂ­a. Sin embargo, las empresas mĂĄs potentes de internet 

prefieren utilizar blockchain pĂşblicas para introducirse en el mundo Fintech e  Insur 

Tech (empresas que usan las nuevas tecnologĂ­as).  

 

1.6.  Ecosistema espaĂąol de blockchain en los servicios financieros.  

SegĂşn Gartner la Blockchain (o cadena de bloques en espaĂąol) es una tecnologĂ­a 

emergente, la cual puede mejorar de forma radical la forma de trabajar de las entidades 

bancarias y otras redes de transacciones a travĂŠs del proceso de eliminaciĂłn de pagos, 

mediante la eliminaciĂłn de los bancos comerciales y centrales, con gran potencial sobre 

los contratos inteligentes, remesas, auditorĂ­as  procesos electorales, dando nuevas 

oportunidades para la innovaciĂłn y el crecimiento al tiempo que se reducen los costes y 

el riesgo. 

 

En el mercado existen diversas fintechs, dedicadas al  pago a travĂŠs de Smartphones o 

digitales (Bizum), criptomonedas, crowdfunding, crowdlending. 

 

 Dato importante: La implementación de la tecnología Blockchain en el 

mercado financiero espaĂąol dio comienzo en octubre de 2013. 

 

 



 

 

Fintech en el mercado actual; 

 

 

 Según (Cristina, 2016), 

tecnologĂ­a, diversas entidades financieras o empresas dedicadas a las prestaciĂłn de 

servicios bancarios han ido desarrollando los llamados 

“con los los que hacer frente a los nuevos retos que tienen que asumir para satisfacer 

a un cliente cada vez mĂĄs sofisticado y especializado en las nuevas tecnologĂ­as.

 Blockchain hará que todo lo que es difícil de gestionar, se convierta en un mero 

trĂĄmite. 

 

SegĂşn informaciĂłn recopilada por la Oficina EconĂłmica y Comercial de la Embajada de 

EspaĂąa en Londres,  se estima que e

2027 serĂĄ de un 10% dato mĂĄs que relevante a la hora de analizar el peso de esta 

tecnologĂ­a a nivel mundial.

Ejemplos de Fintechs en las Blockchains de pagos: Destacaremos dos importantes 

Fintechs de pagos: 

Fintech en el mercado actual; Fuente: Gartner 2018 

 a partir de la fecha de implementaciĂłn de estĂĄ revolucionaria 

diversas entidades financieras o empresas dedicadas a las prestaciĂłn de 

servicios bancarios han ido desarrollando los llamados “laboratorios 

los los que hacer frente a los nuevos retos que tienen que asumir para satisfacer 

a un cliente cada vez mĂĄs sofisticado y especializado en las nuevas tecnologĂ­as.

Blockchain harĂĄ que todo lo que es difĂ­cil de gestionar, se convierta en un mero 

egĂşn informaciĂłn recopilada por la Oficina EconĂłmica y Comercial de la Embajada de 

EspaĂąa en Londres,  se estima que el PIB mundial registrado con Blockchain para 

dato mĂĄs que relevante a la hora de analizar el peso de esta 

nivel mundial. 

Ejemplos de Fintechs en las Blockchains de pagos: Destacaremos dos importantes 

PĂĄgina 10 de 30 

 

a partir de la fecha de implementaciĂłn de estĂĄ revolucionaria 

diversas entidades financieras o empresas dedicadas a las prestaciĂłn de 

“laboratorios financieros 

los los que hacer frente a los nuevos retos que tienen que asumir para satisfacer 

a un cliente cada vez mĂĄs sofisticado y especializado en las nuevas tecnologĂ­as. 

Blockchain harĂĄ que todo lo que es difĂ­cil de gestionar, se convierta en un mero 

egĂşn informaciĂłn recopilada por la Oficina EconĂłmica y Comercial de la Embajada de 

l PIB mundial registrado con Blockchain para 

dato mĂĄs que relevante a la hora de analizar el peso de esta 

Ejemplos de Fintechs en las Blockchains de pagos: Destacaremos dos importantes 



 

PĂĄgina 11 de 30 
 

Uno de los más interesantes y pioneros proyectos a destacar sería “2gether”: Este 

innovador proyecto se define como una plataforma financiera colaborativa, en dĂłnde se 

cambian las criptodivisas (Bitcoin, Ethereum, Webcoin…) por dinero en circulación 

(Euros, dólares…) para después poder realizar los habituales pagos por tarjeta. 

“Marketpay”, es una plataforma de pagos inteligentes para negocios digitales, en la 

cual se puede hacer diversas operaciones como por ejemplo, pagos por custodia, contar 

votos, pagos de campaĂąas de crowdfounding, pagos para soluciones en el Internet de las 

cosas (IoT), pagos en aplicaciones de ventas de segunda mano y plataforma de pagos 

inteligentes. 

Por ende, nos encontramos con los “wallets”,  que es el software específico para 

guardar, enviar y recibir todo tipo de transacciones con criptomonedas. Con este sistema 

se puede realizar todo tipo de transacciones con monedas virtuales o digitales y puede 

ser la analogía perfecta con una cuenta bancaria. Buen ejemplo de ello sería “Coinbase”. 

Ejemplos de Blockchain en mercados de capital 

 

Una de las empresas que quiere destacar en este ámbito es “Symbiont”, la cual 

desarrolla productos en contratos inteligentes y libros de contabilidad distribuidos para 

su uso en los mercados de capital. 

Su finalidad es proporcionar una interfaz segura e inmutable para especificar  

condiciones cuando se emiten valores inteligentes. AdemĂĄs se le suma la integraciĂłn de 

fuentes con datos de mercado. 

Los valores inteligentes son contratos inteligentes autoejecutables, esto tiene la ventaja 

principal de reducir el tiempo y el coste en las transacciones respecto a los sistemas 

tradicionales. 

Ejemplos de Blockchain en Legaltech 

“Finboot Tech”; es una plataforma digital para la firma de contratos inteligentes (Smart 

contracts), sĂłlo y exclusivamente para uso corporativo. 

En este ĂĄmbito estĂĄn trabajando fundamentalmente dos aplicaciones: 

 



 

PĂĄgina 12 de 30 
 

I. Black Labs: el cometido principal de esta aplicaciĂłn es la certificaciĂłn de la 

calidad de los productos derivados del petrĂłleo y la trazabilidad de su 

producciĂłn a medida que va rotando entre los diferentes actores de la cadena de 

suministro. 

 

II. Salma: Su actividad principal es la utilizaciĂłn de la cadena de bloques para la 

protecciĂłn de datos. Funciona devolviendo a los usuarios el control de sus datos 

y facilita a las empresas a adaptarse a los cambios en las leyes. 

 

 Por otro lado y no menos importantes nos podemos encontrar con la empresa privada 

Chainalysis, que tiene como principal finalidad rastrear a aquellas personas que realizan 

transacciones fuera de la legalidad o utilizan las criptomonedas de manera incorrecta, 

asĂ­ como todo tipo de actividades ilĂ­citas, fraude, extorsiĂłn y lavado de dinero para 

hacer de la cadena de bloques un entorno seguro, inmutable y sin riesgo en las 

transacciones realizadas. En definitiva, es un medio para aumentar la trazabilidad de las 

transacciones y es una herramienta ideal para que los auditores puedan detectar errores 

y fraudes.   

 

Chainalysis, (The Blockchain Analisys Company; GestiĂłn de fraudes en la cadena de 

bloques: Es una empresa auditora dentro del entorno de trabajo de la cadena de bloques, 

la cual tiene un triple objetivo: 

- Perseguir el fraude, lavado de dinero asĂ­ como tratar de evitar en la medida de lo 

posible el mercado negro de trĂĄfico de armas, drogas...etc. 

- Dar soporte de todo tipo de documentos y datos y anĂĄlisis a gobiernos, bancos, 

agencias y empresas. 

- Reduce considerablemente la burocracia. 

Un ejemplo que se podrĂ­a comparar; como un gran libro contable que se va dejando 

constancia de todas las transacciones acometidas entre dos partes (acuerdos bilaterales). 

(AnalogĂ­a) 



 

PĂĄgina 13 de 30 
 

2. Funcionamiento del Blockchain  

Hablando en tĂŠrminos financieros, blockchain es una plataforma donde los individuos 

pueden realizar transacciones de todo tipo  sin la intermediaciĂłn de un intermediario de 

confianza. 

SegĂşn (Juan, Cristina 2019) La cadena de bloques es un registro sistemĂĄtico de todas las 

transacciones, almacenadas y compartidas de forma pĂşblica. 

2.1. Elementos bĂĄsicos. 

Según (Preukschat, Álex), para comprender esta tecnología hay que explicar los 4 

elementos de que se compone: 

1) Se puede tratar de un ordenador personal o una mega computadora (dependerĂĄ de la 

complejidad de la red). 

Con independencia de la capacidad de procesar Ăłrdenes, todos los nodos deberĂĄn de 

tener implĂ­cito el mismo protocolo para comunicarse entre sĂ­. 

Podemos distinguir entre una blockchain pĂşblica, donde los nodos no tienen la 

obligatoriedad de identificarse y por otro lado una blockchain privada, donde los 

nodos se conocen entre sĂ­. 

2) Un protocolo estĂĄndar, en forma de software informĂĄtico para que una red de 

ordenadores (nodos) puedan comunicarse entre sĂ­. 

Existe por ejemplo el TCP/IP para el desarrollo de internet o SMTP, con el cual se 

intercambian correos electrĂłnicos. Con todo esto, el protocolo de una blockchain 

utiliza un estĂĄndar comĂşn para definir la comunicaciĂłn entre los ordenadores 

participantes en la red. 

3) Una red entre pares o P2P (Peer-to-Peer, en inglĂŠs), se define como una red de 

nodos conectados directamente con la misma red. Un ejemplo de red P2P serĂ­a 

BitTorrent. 

4) Un sistema descentralizado: En un sistema centralizado, toda la informaciĂłn estĂĄ 

controlada por un Ăşnico nodo, en un sistema descentralizado, todos los ordenadores  

conocen la misma informaciĂłn debido a que son iguales, esto es una blockchain 

pĂşblica. En una blockchain privada, al existir una jerarquĂ­a, algunos nodos pueden 

tener mĂĄs poder o influencia sobre el sistema a la hora de acceder a la informaciĂłn.  



 

PĂĄgina 14 de 30 
 

2.2. Ventajas  

Entre las ventas mĂĄs importantes derivadas de su usabilidad, nos encontramos: 

1) Menor Riesgo: SegĂşn (Rovito y Zocchi, 2019) blockchain va a permitir reducir 

el riesgo de los fondos desde que se aprueba la transacciĂłn hasta que se entregan 

los bienes y servicios. Con ello, se harĂĄn liquidaciones mĂĄs rĂĄpidas y se evitarĂĄn 

fraudes. 

2) Contratos Inteligentes (en inglĂŠs Smart Contracts); Estos contratos, gracias a 

cĂłdigos informĂĄticos (previamente se acuerdan contratos bilaterales),  son 

capaces de ejecutarse por sĂ­ solos, sin intermediarios, ahorrando costes a todo el 

sistema financiero. 

3) Intercambios baratos y Real time: Esta tecnologĂ­a tan novedosa va a 

proporcionar al sistema financiero un mecanismo alternativo de transferencia de 

valores, fondos, divisas etc. A su vez es rĂĄpido, con menos intermediarios y con 

la capacidad de implementaciĂłn de sistemas de compensaciĂłn en tiempo real. 

4) Registro de la informaciĂłn y ahorro: (Petovel, 2019) nos dice, que el Banco 

Central de la RepĂşblica de Argentina permitirĂĄn registrar todas las 

transacciones/ informaciĂłn de la cadena de bloques la cual es generada por el 

sistema financiero en una base de datos descentralizada. 

Según ésta entidad de derecho público Argentina “Actualmente, cada integrante 

del sistema financiero genera y resguarda su propia informaciĂłn, la cual no es 

compartida hacia los restantes participantes del sistema”. Al estar toda la 

informaciĂłn en manos de todo el mundo, ello va a simplificar procesos y reducir 

significativamente los costes. 

2.3.  Aplicaciones 

SegĂşn (GĂĄlvez, 2020), hay 3 aplicaciones en los que la cadena de bloques puede 

solventar problemas del mundo actual: 

 Aseguradoras: Con la Blockchain, permitirá a las compañías aseguradoras 

establecer unos protocolos en los que segĂşn la forma de conducir y el tiempo de 

uso por parte de los clientes, cuantificara lo que cada cliente tendrĂĄ que pagar. 

Normalmente se tomarĂĄ como medida los kilĂłmetros recorridos. Es un producto 

innovador en el mundo de los seguros. Todo esto se medirĂĄ con un chip en la 

parte delantera del vehĂ­culo. 



 

 

 Trazabilidad de todo tipo de productos;

incluido contenedores Maersk ( mediante un chip implĂ­cito en cada uno IoT) , 

cada empresa o individuo p

producto llega al destino final.

3. Matrices DAFO de la banca tradicional y del Blockchain

3.1.  Banca tradicional

A continuaciĂłn se muestra una matriz correspondiente a las Debilidades, Amenazas, 

Fortalezas y Oportunidades del sistema bancario y financiero tradicional. 

Debilidades:  

Las debilidades del sistema bancario tradicional se derivan de los gastos en la 

intermediaciĂłn financiera (tazas, cuotas y otras primas) y el mayor riesgo que tienen 

durante el proceso que, de igual manera, lo expresan en dinero (monetarizaciĂłn del 

riesgo bancario)  

Amenazas 

Se presentan por las nuevas tecnologĂ­as, productos y procesos, los cuales generan altos 

riesgos financieros 

Fortalezas 

Este aspecto se caracteriza por el tamaĂąo y manejo que tiene el sector financiero, en 

general, del mercado; asĂ­ como 

Trazabilidad de todo tipo de productos; desde origen hasta destino final 

incluido contenedores Maersk ( mediante un chip implĂ­cito en cada uno IoT) , 

cada empresa o individuo puede tener el control desde que pagas hasta que el 

producto llega al destino final. 

Matrices DAFO de la banca tradicional y del Blockchain 

Banca tradicional 

A continuaciĂłn se muestra una matriz correspondiente a las Debilidades, Amenazas, 

Fortalezas y Oportunidades del sistema bancario y financiero tradicional. 

Fuente: ElaboraciĂłn Propia 

Las debilidades del sistema bancario tradicional se derivan de los gastos en la 

intermediaciĂłn financiera (tazas, cuotas y otras primas) y el mayor riesgo que tienen 

durante el proceso que, de igual manera, lo expresan en dinero (monetarizaciĂłn del 

Se presentan por las nuevas tecnologĂ­as, productos y procesos, los cuales generan altos 

Este aspecto se caracteriza por el tamaĂąo y manejo que tiene el sector financiero, en 

general, del mercado; asĂ­ como su infraestructura y su cartera de productos. 

PĂĄgina 15 de 30 

desde origen hasta destino final 

incluido contenedores Maersk ( mediante un chip implĂ­cito en cada uno IoT) , 

uede tener el control desde que pagas hasta que el 

A continuaciĂłn se muestra una matriz correspondiente a las Debilidades, Amenazas, 

Fortalezas y Oportunidades del sistema bancario y financiero tradicional.  

 

Las debilidades del sistema bancario tradicional se derivan de los gastos en la 

intermediaciĂłn financiera (tazas, cuotas y otras primas) y el mayor riesgo que tienen 

durante el proceso que, de igual manera, lo expresan en dinero (monetarizaciĂłn del 

Se presentan por las nuevas tecnologĂ­as, productos y procesos, los cuales generan altos 

Este aspecto se caracteriza por el tamaĂąo y manejo que tiene el sector financiero, en 

su infraestructura y su cartera de productos.  



 

 

Oportunidades 

El que se le permita a la banca explorar nuevos productos y mercados, abre la puerta a 

una mayor oferta monetaria y la oportunidad de crear o acceder a nuevos producto 

financieros. 

3.2.  Blockchain 

A continuaciĂłn se muestra una matriz correspondiente a las Debilidades, Amenazas, 

Fortalezas y Oportunidades de la tecnologĂ­a Blockchain aplicada al sistema financiero

Debilidades:  

El mercado no estĂĄ habituado a esta tecnologĂ­

culturales para la entrada y mayor captaciĂłn del mercado

Amenazas 

Ciertamente no se consideran amenazas en un futuro prĂłximo.

Fortalezas 

Las fortalezas estĂĄn ligadas a la seguridad de la transacciĂłn, el anonima

inexistente discrecionalidad.

Oportunidades 

La capacidad de las instituciones tradicionales o no de incorporar esta 

de su desarrollo natural 

El que se le permita a la banca explorar nuevos productos y mercados, abre la puerta a 

una mayor oferta monetaria y la oportunidad de crear o acceder a nuevos producto 

continuaciĂłn se muestra una matriz correspondiente a las Debilidades, Amenazas, 

Fortalezas y Oportunidades de la tecnologĂ­a Blockchain aplicada al sistema financiero

Fuente: ElaboraciĂłn Propia 

El mercado no estĂĄ habituado a esta tecnologĂ­a, razĂłn por la cual existen 

culturales para la entrada y mayor captaciĂłn del mercado 

Ciertamente no se consideran amenazas en un futuro prĂłximo. 

Las fortalezas estĂĄn ligadas a la seguridad de la transacciĂłn, el anonima

inexistente discrecionalidad. 

La capacidad de las instituciones tradicionales o no de incorporar esta tecnologĂ­a

PĂĄgina 16 de 30 

El que se le permita a la banca explorar nuevos productos y mercados, abre la puerta a 

una mayor oferta monetaria y la oportunidad de crear o acceder a nuevos producto 

continuaciĂłn se muestra una matriz correspondiente a las Debilidades, Amenazas, 

Fortalezas y Oportunidades de la tecnologĂ­a Blockchain aplicada ";"""date"",""2020-06-04T17:38:16Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.5""
""xmp:CreatorTool"",""pdfsam-console (Ver. 2.4.3e)""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dcterms:created"",""2020-06-04T17:38:16Z""
""language"",""es""
""Last-Modified"",""2020-06-04T17:38:16Z""
""dcterms:modified"",""2020-06-04T17:38:16Z""
""dc:format"",""application/pdf; version=1.5""
""Last-Save-Date"",""2020-06-04T17:38:16Z""
""pdf:docinfo:creator_tool"",""pdfsam-console (Ver. 2.4.3e)""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2020-06-04T17:38:16Z""
""meta:save-date"",""2020-06-04T17:38:16Z""
""pdf:encrypted"",""false""
""modified"",""2020-06-04T17:38:16Z""
""Content-Length"",""751415""
""pdf:hasMarkedContent"",""false""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""meta:creation-date"",""2020-06-04T17:38:16Z""
""created"",""2020-06-04T17:38:16Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""30""
""Creation-Date"",""2020-06-04T17:38:16Z""
""resourceName"",""Envio%20tardio.%20-%20TFG_Rubn_Mrquez_de_Amo_BUENO.pdf""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""250"",""2889"",""1990"",""474"",""1709"",""3662"",""2202"",""1874"",""1475"",""2289"",""1936"",""1789"",""1936"",""2112"",""2761"",""2020"",""1861"",""2022"",""2434"",""2202"",""2209"",""2157"",""1832"",""1942"",""1820"",""2490"",""1833"",""2489"",""601"",""1212""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""producer"",""iText 2.1.7 by 1T3XT""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""iText 2.1.7 by 1T3XT""
""pdf:docinfo:created"",""2020-06-04T17:38:16Z""
";https://scholar.google.ch/scholar?start=630&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098875-351;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Cost-effective data feeds to blockchains via workload-adaptive data replication;K Li, Y Tang, J Chen, Z Yuan, C Xu, J Xu ; Proceedings of the 21st …, 2020  dl.acm.org;;"… a user program that runs on a blockchain, such as Ethereum [10] and EOS.IO [5]. It holds the

promises to expand the blockchain's functionalities from the basic cryptocurrency payments to

broader applications in decen- tralized nance (DeFi), supply chains, online gaming, et al …";Cité 1 fois;Les 5 versions;[PDF] arxiv.org;https://arxiv.org/pdf/1911.04078;"
Cost-Effective Data Feeds to Blockchains via
Workload-Adaptive Data Replication
Kai Li

kli111@syr.edu
Syracuse University

Syracuse, NY

Yuzhe Tang∗
ytang100@syr.edu
Syracuse University

Syracuse, NY

Jiaqi Chen
jchen217@syr.edu
Syracuse University

Syracuse, NY

Zhehu Yuan†
zy2262@nyu.edu

New York University
New York, NY

Cheng Xu
chengxu@comp.hkbu.edu.hk
Hong Kong Baptist University

Kowloon, Hong Kong

Jianliang Xu
xujl@hkbu.edu.hk

Hong Kong Baptist University
Kowloon, Hong Kong

Abstract
Feeding external data to a blockchain, a.k.a. data feed, is
an essential task to enable blockchain interoperability and
support emerging cross-domain applications, notably sta-
blecoins. Given the data-intensive feeds in real life (e.g.,
high-frequency price updates) and the high cost in using
blockchain, namely Gas, it is imperative to reduce the Gas
cost of data feeds. Motivated by the constant-changing work-
loads in finance and other applications, this work focuses
on designing a dynamic, workload-aware approach for cost
effectiveness in Gas. This design space is understudied in
the existing blockchain research which has so far focused
on static data placement.
This work presents GRuB, a cost-effective data feed that

dynamically replicates data between the blockchain and an
off-chain cloud storage. GRuB’s data replication is workload-
adaptive by monitoring the current workload and making
online decisions w.r.t. data replication. A series of online al-
gorithms are proposed that achieve the bounded worst-case
cost in blockchain’s Gas. GRuB runs the decision-making
components on the untrusted cloud off-chain for lower Gas
costs, and employs a security protocol to authenticate the
data transferred between the blockchain and cloud. The over-
all GRuB system can autonomously achieve low Gas costs
with changing workloads.

We built a GRuB prototype functional with Ethereum and
Google LevelDB, and supported real applications in stable-
coins. Under real workloads collected from the Ethereum
contract-call history and mixed workloads of YCSB, we sys-
tematically evaluate GRuB’s cost which shows a saving of
Gas by 10% ∟ 74%, with comparison to the baselines of static
data-placement.

∗� Corresponding author
†Work is done when the author is an undergraduate student at Syracuse
University.

Middleware’20, DEC 2020, DELFT

1 Introduction
A smart contract is a user program that runs on a blockchain,
such as Ethereum [10] and EOS.IO [5]. It holds the promises
to expand the blockchain’s functionalities from the basic
cryptocurrency payments to broader applications in decen-
tralized finance, supply chains, online gaming, et al. Feeding
external data onto the blockchain, a.k.a. data feed, is an essen-
tial task to enable these blockchain applications. Today, data
feeds are widely adopted, notably in decentralized finance.
For instance, stablecoins, a cryptocurrency with stable price
that sees an explosion of interest (as in Facebook’s Libra [11])
and deployment (as in the popular DAI [23] and Tether [24]
tokens on Ethereum) since 2019, require feeding real-world
asset prices to the blockchain, for instance the Ether-price
feed used in DAI [23]. For another instance, to enable asset
exchange across different blockchains, say allowing a Bitcoin
owner to transact with an Ethereum token owner, it entails
a “side-chain” feed such as BtcRelay [2, 8, 67] to send the re-
cently found Bitcoin blocks onto Ethereum for verifying Bit-
coin deposit. There are many other blockchain applications
that have been or can be enabled by data feeds, including
decentralized insurance [69], tracing supply-chains [17, 63],
healthcare [51], transparency logging [14, 30, 64], trustless
information-security [15], et al.
Operating today’s data feeds can be an expensive busi-

ness. Specifically, many real-world data feeds generate an
intensive stream of data updates at a high frequency (e.g.,
the price updates in seconds and microseconds). Under these
data-intensive streams, data feeds, if improperly designed,
could cause a heavy use of blockchain and lead to high mon-
etary cost, known as Gas [66]. The expense burdens not only
data-feed operators (e.g., ChainLink andMakerDAO) but also
the financial applications running on top of the data feeds
(e.g., decentralized exchanges such as AmpleForth and Syn-
theix [48]), eventually transferring to high fees for end users
(e.g., users of decentralized exchanges). It is thus impera-
tive to design cost-effective data feeds for scaling blockchain
applications to support real-world data-intensive scenarios.

1

ar
X

iv
:1

91
1.

04
07

8v
3 

 [
cs

.C
R

] 
 1

4 
Se

p 
20

20



Middleware’20, DEC 2020, DELFT Kai Li, Yuzhe Tang, Jiaqi Chen, Zhehu Yuan, Cheng Xu, and Jianliang Xu

The goal of this work is to explore how a dynamic,
workload-aware design of data feed can effectively save Gas.
The design goal is motivated by 1) the observation that real-
world financial applications exhibit highly dynamic work-
load patterns, which present opportunities to reduce costs
— Intuitively, if one can dynamically adjust the location of
the data feeds (w.r.t. the blockchain) according to the current
data supply-demand, the Gas cost caused by the repeated
use of blockchains could be avoided. See the next two para-
graphs for a detailed justification. 2) Furthermore, the design
space of a workload-aware approach has not been studied
in the existing blockchain-systems research. While there
is a large body of research works on reducing blockchain
costs, notably the layer-two protocols exemplified by pay-
ment channels [16, 36, 52, 56] that aim to place application
logic off the blockchain, all existing approaches are based
on static data placement. That is, the placement of data and
computation w.r.t. blockchains stays fixed once the system
starts running, and it does not reflect the constant change
in the workloads. The design space of a dynamic, workload-
aware approach to optimize the smart-contract cost (in Gas)
for data feeds and blockchain applications beyond is an un-
charted territory.

This work presents GRuB, a workload-adaptive data repli-
cation framework for cost-effective data feeding. The system
model is a data pipeline involving three actors: As illustrated
in the left part of Figure 1, an off-chain data producer (DO)
feeds a stream of data updates to multiple data-consumer
smart contracts (DUs) on the blockchain. The data flow is
coordinated by an intermediarykey-value (KV) store between
the DO and DUs. A conventional design of data feed is to
realize the KV store in a smart contract that accepts DO’s
data updates in transactions and DU’s queries in contract
internal calls. An alternative design is to statically place the
KV store off the blockchain (e.g., the static off-chain feed,
TownCrier [69]). By contrast, GRuB is a KV store built on
hybrid storage media: By default, the data updates are per-
sisted on an off-chain cloud storage provider (SP) such as
Amazon S3 [1] and upon DU’s queries, are brought to the
blockchain, buffered in a smart-contract memory. Optionally,
the buffered data can be persisted to the smart-contract stor-
age, as a data replica, to benefit future read queries. GRuB’s
system model is illustrated by the right part of Figure 1. Note
that our system model assuming any cloud provider is un-
trusted should be differentiated from the multi-cloud model
adopted in existing works [29, 33] which trusts at least one
cloud provider.

The key decision to make in GRuB is whether and when a
data record in the feed should be replicated onto the smart-
contract storage on a blockchain. Always storing a replica
of the data being read, on the one hand, can benefit future
data reads by avoiding loading data onto the blockchain re-
peatedly. On the other hand, if there are no future reads,
such a data replica would be wasted. Thus, GRuB chooses to

gPuts

DO

gGet

DU smart contracts

Storage-manager 
smart contract

Cloud storage 

provider (SP)

Callbacks

Data 
producer
(DO)

Data-consumer  
smart contracts (DUs)

Storage-
manager 

smart contract

Conventional data feed GRuB�s data feed (hybrid storage)

Data 

updates

Queries 

(internal 

calls)

Dynamic data replication

Figure 1. System model: The conventional data feed (left
part) shows an on-chain KV store in a smart contract that me-
diate between an off-chain data producer (DO) and multiple
on-chain data-consumer smart contracts (DUs). GRuB (the
right part) introduces an off-chain cloud storage provider (SP)
in the system model, which, together with a smart contract,
provides a hybrid KV store that exposes a remote-procedure
call interface (i.e., gPuts) to the DO and an internal-call
interface (i.e., gGet with callbacks) to the DU smart con-
tracts. With the default storage on SP, the fed data is dynam-
ically replicated onto the blockchain by demand (in blue).
Green in this figure illustrates smart contracts running on a
blockchain and red is the SP who is the primary adversary
in our trust model.

replicate data in a workload-adaptive manner: If the current
workload is dominated by the reads from DUs, the GRuB
would decide to store a data replica on the blockchain. Oth-
erwise, if the current workload is dominated by the updates
from the DO, the GRuB would decide to avoid replicating
data on chain. This design systematically avoids the two
most expensive operations in Gas. That is, replicating data
on chain under read-intensive workloads can avoid the ex-
pensive transactions otherwise needed to bring data onto the
blockchain, and evicting data replicas under write-intensive
workloads can prevent the expensive storage writes in smart
contracts. See Section 2.2 for details on Ethereum’s Gas-based
cost model and Section 2.3 for a basic measurement study
that corroborates our insight here.

Dynamic decision making w.r.t. data replication has been
a well-studied research topic in conventional distributed sys-
tems. Briefly, a common approach [43] is to model the target
system by multiple “sites”, and run workload monitoring
and decision making distributedly on each site. These solu-
tions lay an important foundation for designing dynamic
data-replication in GRuB. However, simply using them as
they are in GRuB is insufficient. Notably, existing dynamic
replication frameworks are not designed with blockchain’s
Gas cost model in mind or do not reflect the GRuB’s cost to
enforce data security (e.g., on untrusted SP off-chain). If used
improperly in GRuB, they may lead to excessive costs; for
instance, the Gas model charges higher unit cost (e.g., per
word) for “local” operations in smart contract (e.g., on-chain

2



Cost-Effective Data Feeds to Blockchains via Workload-Adaptive Data Replication Middleware’20, DEC 2020, DELFT

storage updates) than for data movement over the network
(by transactions). Such a unique cost characteristic may inval-
idate the existing design that collocates the decision making
with data replicas.

To fill the gap, GRuB presents a Gas-aware data-replication
system which places workload monitoring and decision mak-
ing off the blockchain. We propose a security protocol to
guarantee the integrity of workload trace and replication
decisions that are transferred from untrusted off-chain SP
to the blockchain. The decisions in GRuB are made by a
Gas-aware online algorithm that achieves the bounded “Gas
competitiveness” – Specifically, the worst-case Gas caused by
the data replication following the decision made by this on-
line algorithm is bounded by a small-constant multiplicative
factor (e.g., 2) to that caused by an optimal offline algorithm.
This work emphasizes building a data-replicationmechanism
supporting sample policies to bound competitiveness. A com-
prehensive study of policies to configure the mechanism is
out of the scope. Overall, GRuB can autonomously run in the
hybrid data feeds with changing workloads, while keeping
the Gas low.

GRuB’s system is generic: To support applications, GRuB
exposes an extensible KV store interface (API) that supports
Puts from the DO and Gets with callbacks to process queries
in a DU contract. GRuB can be built relying on generic in-
terfaces of the underlying systems (similar to an ABI); that
is, any blockchain supporting smart contracts and any off-
chain storage services supporting KV storage. We have built
a GRuB prototype functional with Ethereum [10] and Google
LevelDB [13], and used it to enable a financial application:
A stablecoin collateralized with an Ether-price feed built on
GRuB. Based on the real-world workloads collected from
Ethereum, we evaluate GRuB’s Gas cost, which shows that
GRuB can save up to 67% Gas compared to the static-data-
placement baselines. For more extensive evaluation, we build
a benchmark by mixing the YCSB workloads. The evalua-
tion under YCSB benchmark shows that compared to the
baselines, GRuB can save Gas by 10% ∟ 74% depending on
specific record sizes and read-write ratios.

The contributions of this paper are outline as following:
1. Propose a dynamic, workload-adaptive approach by

mixing on-chain and off-chain data storage to optimize the
smart-contract costs. To the best of our knowledge, this iden-
tifies an unexplored design space in the existing blockchain
research.

2. Present GRuB, a Gas-efficient data feed by dynamically
replicating data between the hybrid data storage on and
off the blockchain. GRuB employs new techniques, a Gas-
aware online algorithm for replication decision-making and
a security-centric protocol for running the decision compo-
nents off-chain at a low cost.

3. Validate the applicability of GRuB and evaluate its cost
in Gas extensively, by systematically studying real-world
applications, building a benchmark suite from real-world

traces, and evaluating the costs. The result shows that GRuB
can achieve a Gas saving by 10% ∟ 74% when compared to
static data-placement baselines.

2 Design Motivations
2.1 Preliminary on Motivating Applications
Data feeding enables a blockchain to be able to interoperate
with external worlds (i.e., the blockchain interoperability),
which further enables a good number of deployed blockchain
applications in cross-domain scenarios. Here, we describe
two such applications in detail, as an effort to motivate our
work.

Stablecoins (on price feeds): Unlike Bitcoin, Ether and other
“native” cryptocurrencies, a stablecoin is a cryptocurrency
with stable prices. Price stability is the key requirement for
real-world adoption of today’s cryptocurrencies in realistic
applications (e.g., loans, derivatives, and prediction markets).
Recently, there is an explosion of stablecoins proposed (e.g.,
Facebook Libra) and deployed (e.g., DAI [23], Tether [24],
and the other 57 stablecoins operational on Ethereum, as of
May 2020 [27]).
There are different approaches to realize price stabil-

ity [37]: A stablecoin can be either directly backed by a
stable asset (e.g., USD or gold) or indirectly backed via yet
another cryptocurrency. The latter design, named indirectly-
backed stablecoin, has the benefit of not relying on a trusted
third-party vault off-chain to keep collateral and is adopted
in popular stablecoins such as DAI [23] which is indirectly
backed by Ether. To manage the price instability of Ether
itself, the DAI runs a smart contract on Ethereum that con-
trols the issuance and redemption of DAI. To make each DAI
redeemable with one-USD worth of Ether, the DAI smart
contract needs to be aware of the current price of Ether (or
Ether-USD exchange rate). This is done by a price feed in
practice [12], which upload the stream of price updates from
a trusted source off-chain, such as Coinbase.1
Cross-chain swaps (on side-chain feeds): Supporting as-

set swaps across multiple blockchains is an important fi-
nancial application paradigm, enabling asset liquidity on
Blockchains. For instance, there are Bitcoin-pegged ERC20 to-
kens on Ethereum [25] which allow a Bitcoin owner to trans-
act with an asset owner on Ethereum. An efficient approach
to enable such applications is the side-chain paradigm where
blockchain A feeds its produced blocks to smart contracts
running on blockchain B. For instance, BtcRelay [2, 8] is such
a side-chain feed connecting Bitcoin and Ethereum. BtcRe-
lay style side-chain feeds are widely used in Bitcoin-pegged
ERC20 tokens (e.g., tBTC [4, 22, 28] and others [25, 67]),
Ethereum lottery games [3, 9], et al.

1The off-chain party trusted by an indirectly-backed stablecoin performs a
much simpler task than that by the directly-backed stablecoin. The former is
a price feed, while the latter is a full-fledged vault storing the collateralized
asset, subject to the public auditing [37, 53].

3



Middleware’20, DEC 2020, DELFT Kai Li, Yuzhe Tang, Jiaqi Chen, Zhehu Yuan, Cheng Xu, and Jianliang Xu

1 101 201 301 401 501 601 701
Write sequence

0

5

10

15

20

N
u
m

b
e
r 

o
f 

re
a
d
s
 a

ft
e
r 

a
 w

ri
te

Figure 2. The workloads of ethPriceOracle [18] that feed
the MakerDAO stablecoin platform [19] on Ethereum

Other than the above two classes of data feeds, there are
many other uses of data feeds, either deployed or envisioned.
For instance, running flight insurances on Ethereum requires
data feeds to provide flight cancel/deploy information. Run-
ning stock exchanges may require an off-chain order book to
feed stock/order prices. In other domains, blockchains are en-
visioned to support the auditing of transparency logs [14, 64],
where the smart contracts running auditing logic need data
feeds of log updates from off-chain servers.
Table 1. Distribution of writes by the number of reads fol-
lowed in the ethPriceOracle trace (#r represents the number
of reads per write)

#r Percentage #r Percentage #r Percentage
0 70.4% 5 0.76% 10 0.13%
1 16.0% 6 0.63% 12 0.13%
2 6.46% 7 0.25% 13 0.25%
3 2.91% 8 0.13% 17 0.13%
4 1.52% 9 0.25% 20 0.13%

Workloads: In these applications, the workload a data-
feed serves consists of data reads from the consumer smart-
contracts and the updates from the data producer. One of the
motivating observations of this work is that many real-world
workloads in data feeds fluctuate widely in the read-write
ratio. Here, we present a measurement result as an exam-
ple. EthPriceOracle [18] is a price feed operational in the
Ethereum mainnet and in use to support indirectly-backed
stablecoin DAI, as part of the MakerDAO platform [19]. Eth-
PriceOracle allows 14 off-chain accounts to update the price
feed and is implemented as a smart contract supporting a
price-update function (i.e., poke()) and a price-read function
(i.e., peek()). We collected a call trace of poke() and peek()
between April 25th, 2018 to April 30th, 2018; the collection
is done in two means, by running an Ethereum full node and
by querying a public Ethereum dataset hosted on Google
BigQuery [7]. Figure 2 plots the 5-day trace where each X
tick is a data-feed update (i.e., a poke() call) and the Y value
associated with a X value is the number of data-feed reads
(i.e., peek() calls) immediately following the write in the
call trace. The workload distribution is also summarized in
Table 1. It can be seen that the number of reads following a

write fluctuate; half of Y values are 0 and 1, but occasionally
it also reaches as high as 20 reads after a write.
While this is the case of one particular application, the

data-feed workloads being fluctuating commonly apply. Be-
cause in a typical data feed, the updates are produced con-
tinuously at a regular rate, while the reads from the data
consumer smart contract are by demand, which typically
come and go in an ad-hoc fashion.

2.2 System Model and Trust Model
In this subsection, we formally describe the system model
introduced before. Recall Figure 1 that our system model
includes three parties: A data producers (DO), a key-value
(KV) store (i.e., the GRuB) and a number of data-consumer
smart contracts (DUs). The off-chain DO sends data updates
to the KV store, by invoking its function, gPuts. A DU smart
contract queries the data feed stored in the KV store by
issuing a function call to gGet. The two functions exposed
by the KV store are described by Listing 1.
// external call by off -chain DO

bool gPuts(KV[] kvs);

// internal call by smart contract (DU)

KV[] gGet(Key k1, Callback cb);

Listing 1. GRuB APIs

Specifically, a single gPuts call by the data producer
batches multiple KV records in an epoch (e.g., every 1 min.)
to update the KV store. A gGet call issued by a DU smart
contract retrieves KV records by a specified data key and
returns its control to an optional callback function in the
caller smart contract. The callback function often executes
query-processing logic based on the retrieved KV records.
Here, note that the caller of gPuts is the off-chain data pro-
ducer and it can be implemented as a remote-procedure call,
for instance, in Python. The caller of gGet is a smart contract
and it can be implemented as a Solidity function.

GRuB is a KV store based on “hybrid” storage media both
on and off the blockchain. On the blockchain, it runs a
storage-manager smart contract. Off the blockchain, it runs
a KV store instance on an untrusted cloud storage provider
(SP), such as Amazon S3.

GRuB can be used as a base to support different domain
applications. To do so, an application developer writes a DU
smart contract encoding the application logic and embedding
a query-processor function to be called by gGet. GRuB can
enable a price feed: Recall Section 2.1 that a price feed sup-
ports a price-update function poke() and a price-read func-
tion peek(). These two functions can be mapped to GRuB’s
gPuts and gGet, respectively, by modeling the price of each
collateral asset as a KV record (e.g., ⟨Ether, 150USD⟩). Sec-
tion 4 presents two end-to-end applications built on GRuB.

Trust model: In our system, the primary adversary is the
untrusted cloud storage provider who can forge, replay, omit
and fork the data sent to the blockchain, in order to break

4



Cost-Effective Data Feeds to Blockchains via Workload-Adaptive Data Replication Middleware’20, DEC 2020, DELFT

the data integrity. The “data” includes the KV records, proofs
and various protocol-specific metadata including collected
trace of workloads and replication decisions. We assume
high availability among all participating parties and exclude
denial-of-service attacks from the scope of this paper. All
smart contracts including the application smart contracts
and GRuB’s storage-manager contracts are trusted in terms
of program security (no exploitable security bugs), execution
non-stoppability, etc. We also make standard assumption
on blockchain security that the blockchain is immutable,
fork-consistent and Sybil-secure. The underlying security
assumption is that a deployed blockchain system runs among
a large number of peers where majority of them are honest
peers and compromising the majority is hard.
Table 2. Ethereum’s Gas cost w.r.t. different operations [66]:
Operations related to data movement (transactions) and stor-
age updates are the most expensive in Gas.

Operation Gas cost (X is the number of 32-byte words)
Transaction Ctx (X ) = 21000 + 2176X (X < 1000)
Storage write (insert) Cinser t (X ) = 20000X
Storage write (update) Cupdate (X ) = 5000X
Storage read Cr ead (X ) = 200X
Hash computation Chash (X ) = 30 + 6X

Cost model: The primary cost considered in this work is
the cost in using blockchains and executing smart contracts.
This paper considers the use of Ethereum. Table 2 presents
the Ethereum cost model in Gas (the cost unit in Ethereum).
It can be seen the most expensive operations in Gas per word
are transactions and storage writes/updates. In our system
model, the use of cloud service (SP) may also lead to expenses,
which however is much cheaper than that of blockchains:
Consider storing one gigabytes in today’s cloud storage,
which falls under the free tier for all major providers (i.e.,
Amazon S3, Dropbox, et al), leading to zero-dollar spending,
whereas doing the same on Ethereum costs more than $231
million USD (with the Ether price as of Nov. 2019). Because
of this, the cloud-service fee in our target application is
negligible compared with the Gas cost from blockchains.

Also reducing the Gas of a blockchain application implies
improving the throughput of this application, because 1)
the transaction throughput of a blockchain is bounded by
the total Gas a block can take, such as 10 million gas per
Ethereum block; reducing the Gas per operation implies the
application can submitmore operations in a given time. 2)We
assume blockchain is the bottleneck of a target application,
which currently takes tens of transactions per second and
is much lower than that of conventional computer systems,
even for a single machine. Thus, the main goal of this work
is to reduce the Gas cost of a blockchain application.

2.3 Motivating Cost Observation
Design Space: This work addresses the design of hybridized
data storage over blockchain and SP. We consider the two
design baselines: 1) data is only stored on the off-chain SP

0 0.125 0.5 1 4 16 64 256
Read-to-write ratio

0

2

4

6

8

10

P
e
r-

o
p
e
ra

ti
o
n
 c

o
s
t 

(X
1
0
0
0
 G

a
s
)

No replica (BL1)

Always with replica (BL2)

Figure 3. Preliminary Gas measurements of static baselines

and is brought into the smart-contract memory when serv-
ing gGet. This baseline is named BL1. Alternatively, 2) data
is stored both on the off-chain SP and on blockchain. The
baseline is named BL2. Note that our cost model only consid-
ers blockchain-induced cost, Gas, and excludes the off-chain
costs including cloud service fee (on SP). Thus, BL2’s cost is
equivalent to the design of placing data storage only on the
blockchain. Note that these two baselines are based on static
decisions regarding data replication.

Measurement observation: To motivate dynamic data
replication of this work, we conduct a rapid measurement
study: In this study, we consider the simplest data model
involving a single KV record. We implement a simple smart
contract on the Ethereum testnet that processes the single KV
record with optional on-chain storage. We use an off-chain
machine running Ethereum client geth, to represent the SP.
The two static baselines, BL1 and BL2, are implemented. We
use a series of workloads with varying read-write ratios.
Each workload is a repeated sequence of X1 writes followed
by X2 reads (all of which are under the single data key). On
the one end, we use a write-only sequence , that is, X 2

X 1 = 0.
On the other end, we use a read-intensive sequence with
each write followed by 256 reads X 2

X 1 = 256. After driving
each workload to our system, we measure the average Gas
per operation on BL1 and BL2. We vary the read-to-write
ratio (X 2

X 1 ) and report BL1 and BL2’s Gas per operation in
Figure 3.

It is clear that as the workload changes from thewrite-only
sequence to read-intensive ones, there is a tradeoff between
the two static baselines. When the workload is write-only,
BL1 achieves lower Gas per operation than BL2, with cost
saving more than 100×. When the workload becomes about
every 1.5 read per write (i.e., X 2

X 1 = 1.5), the two approaches
cost equal Gas. When the workload is more read intensive,
such as X 2

X 1 = 256, BL2’s Gas per operation is 1
7 of BL1’s.

While having a data replica on the blockchain is expected
to shift the cost distributions between reads and writes, the
striking cost difference it makes (100× and 7×) was sur-
prising to us. This can be attributed to Ethereum’s unique

5



Middleware’20, DEC 2020, DELFT Kai Li, Yuzhe Tang, Jiaqi Chen, Zhehu Yuan, Cheng Xu, and Jianliang Xu

cost model: When the workload is write-only, the always-
replicate baseline (BL2) incurs expensive operations to up-
date smart-contract storage, which costs 5, 000 ∟ 20, 000
Gas per word; recall Table 2. When the workload is read in-
tensive, the never-replicate baseline (BL1) incurs expensive
transactions to move the latest value of KV record to the
blockchain, while BL2 avoids the expense by reading storage
data on chain; recall Table 2 that a read from smart-contract
storage costs 200 Gas per word while a transaction costs
a much higher 2176 per word; let alone the initial cost of
21, 000 of an empty transaction.

3 GRuB: System Design and Impl.
GRuB overview: Recall the system model in Section 2.2
that a trusted DO feeds data updates to the GRuB KV store,
which is queried by DU smart contracts. The internal system
of the GRuB consists of two “planes”, as depicted in Figure 4:
1) A secure-data plane where the DO securely updates the
KV store on GRuB by associating data updates with proofs,
and a DU smart contract querying the GRuB retrieves query
proofs to authenticate (non-replicated) KV records stored
on the untrusted cloud provider. The data plane runs a secu-
rity protocol known as authenticated data structures (ADS;
which will be introduced and described in Section 3.3) across
the DO, the SP and the blockchain. 2) A control plane which
monitors the workloads (data updates and reads), makes
replication decisions w.r.t. individual KV records, and stores
the decisions as auxiliary states in each KV record, which
instructs the data plane to materialize the decisions. The con-
trol plane runs on the trusted DO and federates the traces of
data reads (from the blockchain’s natively logged contract-
call history) and data updates. The key component of GRuB
is a series of online decision-making algorithms running in
the control plane.
In this section, we describe the algorithm design of on-

line decision maker, which is the core of GRuB’s control
plane (Section 3.1), the control-plane system design (Sec-
tion 3.2), the data-plane system design (Section 3.3), overall
system properties (Section 3.4) and implementation notes
(Section 3.5).

3.1 Online Decision-Making: Algorithm Design &
Analysis

In this subsection, we describe the online decision-making al-
gorithm: Given a sequence of gPuts and gGet calls, GRuB’s
decision-making algorithm produces the replication deci-
sions on affected KV records. The replication decision will
be actuated as described in the next subsection. The design
goal of such algorithms is to reduce the Gas cost of future
data reads and writes based on the assumption that the read-
/write history will repeat. Intuitively, the algorithm needs to
predict the future reads/writes on the KV record, estimate
the cost of the two alternative decisions (R or NR) based on

the prediction, and pick the one with lower costs as the out-
put. Using the existing online algorithms [43] is insufficient
as they are designed without awareness to GRuB’s cost in
Gas and the cost caused by security proofs. We propose algo-
rithm designs and configurations that are tailored to GRuB’s
unique costs and that can autonomously achieve bounded
worst-case Gas cost. In the following, we present the design
and analysis of two algorithms: a “memoryless” online algo-
rithm that resets its state/memory about past reads/writes
upon each run, and a “memorizing” online algorithm that
remembers the operation history across runs.

Memoryless Algorithm The memoryless algorithm for
replication decision making is described in Algorithm 1. The
algorithm internally maintains a list of counters, each for a
NR record. The counter counts the number of consecutive
reads on the data record that are received since the last write.
The algorithm iterates through the read/write trace. Upon a
write on a record, say ⟨k,v⟩, the algorithm resets the counter
of record ⟨k,v⟩ back to zero and updates the record’s NR.
Upon a read on a NR record, it increments its counter. When
the counter reaches a preset parameter, K , the algorithm
changes the record’s state from NR to R and removes the
data record from the list of counters.
Algorithm 1MemorylessRepl(ops , count , states)

Input: read/write operations ops , read count count , and the
replication states states

Output: updated replication states states
1: for all o ∈ ops do
2: if o.isWrite() then
3: count[o.key] = 0; states[o.key].set(NR);
4: else
5: if count[o.key] < K then
6: count[o.key] + +;
7: end if
8: if count[o.key] ≥ K then
9: states[o.key].set(R);
10: else
11: states[o.key].set(NR);
12: end if
13: end if
14: end for

Algorithm analysis: The memoryless algorithm in Al-
gorithm 1 has competitiveness (w.r.t. the worst-case Gas)
bounded by 1+K Cr ead_of f

Cupdate
. Here,Cupdate is the Gas to update

a byte on the blockchain storage, and Cr ea";"""date"",""2020-09-16T01:00:21Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"","" Cost-Effective Data Feeds to Blockchains via Workload-Adaptive Data Replication ""
""xmp:CreatorTool"",""LaTeX with acmart 2019/10/19 v1.65 Typesetting articles for the Association for Computing Machinery and hyperref 2016/06/24 v6.83q Hypertext links for LaTeX""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with acmart 2019/10/19 v1.65 Typesetting articles for the Association for Computing Machinery and hyperref 2016/06/24 v6.83q Hypertext links for LaTeX""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"","" Cost-Effective Data Feeds to Blockchains via Workload-Adaptive Data Replication ""
""modified"",""2020-09-16T01:00:21Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""Kai Li, Yuzhe Tang, Jiaqi Chen, Zhehu Yuan, Cheng Xu, and Jianliang Xu""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016) kpathsea version 6.2.2""
""meta:author"",""Kai Li, Yuzhe Tang, Jiaqi Chen, Zhehu Yuan, Cheng Xu, and Jianliang Xu""
""trapped"",""False""
""meta:creation-date"",""2020-09-16T01:00:21Z""
""created"",""2020-09-16T01:00:21Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-09-16T01:00:21Z""
""resourceName"",""1911.04078""
""Author"",""Kai Li, Yuzhe Tang, Jiaqi Chen, Zhehu Yuan, Cheng Xu, and Jianliang Xu""
""producer"",""pdfTeX-1.40.17""
""pdf:docinfo:producer"",""pdfTeX-1.40.17""
""pdf:unmappedUnicodeCharsPerPage"",""1"",""1"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""5"",""0"",""0"",""0"",""0"",""0"",""8"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""Kai Li, Yuzhe Tang, Jiaqi Chen, Zhehu Yuan, Cheng Xu, and Jianliang Xu""
""dcterms:created"",""2020-09-16T01:00:21Z""
""Last-Modified"",""2020-09-16T01:00:21Z""
""dcterms:modified"",""2020-09-16T01:00:21Z""
""title"","" Cost-Effective Data Feeds to Blockchains via Workload-Adaptive Data Replication ""
""Last-Save-Date"",""2020-09-16T01:00:21Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2020-09-16T01:00:21Z""
""meta:save-date"",""2020-09-16T01:00:21Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016) kpathsea version 6.2.2""
""Content-Length"",""2485138""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Kai Li, Yuzhe Tang, Jiaqi Chen, Zhehu Yuan, Cheng Xu, and Jianliang Xu""
""dc:language"",""en""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""20""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""3922"",""5024"",""5097"",""4349"",""4607"",""4424"",""3768"",""5111"",""4497"",""4226"",""3691"",""4142"",""5415"",""6222"",""3957"",""4807"",""3550"",""2883"",""4249"",""3588""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-09-16T01:00:21Z""
";https://scholar.google.ch/scholar?start=900&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098844-286;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;[PDF][PDF] On Pairing-Free Blind Signature Schemes in the Algebraic Group Model;J Kastner, J Loss, J Xu ; Cryptology ePrint Archive, 2020  eprint.iacr.org;;"… In particular, for large- scale settings (eg, cryptocurrency tumblers), it is important for schemes

to … julia.kastner@inf.ethz.ch, supported by ERC Project PREP-CRYPTO 724307 ** Department

of … A is given access to the following oracles: • Oracle chal takes no input and samples a …";Autres articles;;[PDF] iacr.org;https://eprint.iacr.org/2020/1071.pdf;"
On Pairing-Free Blind Signature Schemes in the
Algebraic Group Model

Julia Kastner?, Julian Loss??, and Jiayu Xu? ? ?

Abstract Studying the security and efficiency of blind signatures is an
important goal for privacy sensitive applications. In particular, for large-
scale settings (e.g., cryptocurrency tumblers), it is important for schemes
to scale well with the number of users in the system. Unfortunately, all
practical schemes either 1) rely on (very strong) number theoretic hard-
ness assumptions and/or computationally expensive pairing operations
over bilinear groups, or 2) support only a polylogarithmic number of
concurrent (i.e., arbitrarily interleaved) signing sessions per public key.
In this work, we revisit the security of two pairing-free blind signature
schemes in the Algebraic Group Model (AGM) + Random Oracle Model
(ROM). Concretely,

1. We prove that the popular blind Schnorr scheme is secure under the
one-more discrete logarithm assumption if the signatures are issued
sequentially. While the work of Fuchsbauer et al. (EUROCRYPT
‘20) proves the security of the blind Schnorr scheme for concur-
rent signing sessions in the AGM+ROM, its underlying assump-
tion, ROS, is proven false by Benhamouda et al. (EUROCRYPT
‘21) when more than polylogarithmically many signatures are issued.
Given the recent progress, we present the first security analysis of the
blind Schnorr scheme in the slightly weaker sequential setting. We
also show that our security proof reduces from the weakest possible
assumption, with respect to known reduction techniques.

2. We then reconsider the security of Abe’s scheme (EUROCRYPT
‘01), which is known to have a flawed proof in the plain ROM.
We give a proof under the discrete logarithm assumption in the
AGM+ROM, even for (polynomially many) concurrent signing ses-
sions.

1 Introduction

Blind signatures, first introduced by Chaum [Cha82], are a fundamental cryp-
tographic building block. They find use in many privacy sensitive applications

? Department of Computer Science, ETH Zurich, Zurich, Switzerland,
julia.kastner@inf.ethz.ch, supported by ERC Project PREP-CRYPTO
724307

?? Department of Computer Science, University of Maryland, College Park, MD, USA,
lossjulian@gmail.com

? ? ? Department of Computer Science, George Mason University, Fairfax, VA, USA,
jxu27@gmu.edu



such as anonymous credentials, eCash, and eVoting. Informally, a blind signa-
ture scheme is a interactive protocol between a user and a signer. Here, the
signer holds a secret key sk and the user holds the corresponding public key pk.
The goal of the interaction is for the user to learn a signature σ on a message
m of its choice such that σ can efficiently be verified using pk. The protocol
should ensure two properties [JLO97]: (1) Blindness: the signer cannot link the
transcripts of protocol runs to the signatures that they created. In particular,
it does not learn the messages that it signs. (2) One-More-Unforgeability: if the
protocol is run ` times, the user should not be able to create ` + 1 or more
valid signatures. In spite of decades of study, the security guarantees of prac-
tical blind signature schemes are not satisfactory. Practical constructions rely on
strong number-theoretic hardness assumptions and/or computationally expens-
ive pairing operations over bilinear groups groups [Bol03; Bel+03; Oka06; GG14;
FHS15]. Other constructions rely on weaker assumptions (and no pairings) but
allow only for a very small (polylogarithmic) number of signatures to be issued
per public key [PS96; PS97; PS00; HKL19; Hau+20]. The reason for this is that
the homomorphic structure of these schemes gives rise to the so-called ROS
attack (Random inhomogenities in Overdetermined System of equations) when
sufficiently many sessions of the scheme are executed concurrently (i.e., if session
can be interleaved arbitrarily). Shortly after its discovery by Schnorr [Sch01],
Wagner [Wag02] showed how to carry out the ROS attack in sub-exponential
time against the Schnorr and Okamoto-Schnorr[Oka93] signature schemes.1 A re-
cent result of Benhamouda et al. [Ben+21] improved the parameters of Wagners
attack, presenting the first polynomial-time attack (assuming that polylogarith-
mically many signing sessions can be opened concurrently). This leaves the state
of affairs on blind signatures unsatisfactory.

The Algebraic Group Model. Fuchsbauer, Kiltz and Loss [FKL18] intro-
duced the algebraic group model (AGM) as a means to analyze group based
cryptosystems. In the AGM, an adversary must output an explanation of how it
computed its output group elements from the group elements in its input. Since
its introduction, the AGM has been readily adopted and has served as useful
tool to prove the security of schemes that would be too difficult to analyze in
the plain model. From a qualitative point of view, proofs in the AGM provide a
weaker form of security than proofs in the plain model, but a much stronger one
than proofs in the GGM. The recent work of Agrikola et al. [AHK20] shows that
results from the AGM can be transferred to the standard model using strong,
but falsifiable assumptions. This suggests that proofs in the AGM indeed hold
some meaning for the plain model.

1 Although the attack can be formulated for all the aforementioned blind signature
schemes, the algebraic structure in the latter two schemes gives rise to an efficient
attack.

2



1.1 Our Results

In this work, we revisit the security properties of two classic blind signature
schemes which do not rely on pairings: Schnorr’s blind signature scheme and
Abe’s blind signature scheme [Abe01]. Neither of these schemes have meaning-
ful security guarantees if the number of concurrent signing sessions is beyond
polylogarithmic (in fact, Abe’s blind signature scheme has no security proof at
all outside a non-generic model of computation). Given the popularity of these
schemes, we believe that a reassessment of their security properties is long over-
due.

We give a summary of our results below. We begin by studying the security
of blind Schnorr signatures in the algebraic group model (AGM) [FKL18] +
random oracle model (ROM) [BR93] with sequential signing sessions, i.e., where
the i-th session must be completed before the (i+ 1)-st session is opened.

Positive Result (Schnorr). We show that under the above model assump-
tions, the blind Schnorr signature scheme remains secure against `-sequential
one-more-unforgeability (`-SEQ-OMUF) under the `-one-more discrete logar-
ithm (`-OMDL) assumption even when polynomially many signatures are is-
sued for the same public key pk. This improves upon the result of Fuchsbauer
et al. [FPS20], which proves that the scheme is secure under the OMDL+ROS
assumption. While the ROS problem is known to be information theoretically
hard as long as the number of signing sessions is polylogarithmic, the recent work
of Benhamouda et al. [Ben+21] shows a polynomial-time attack with super-
polylogarithmic signing sessions. Therefore, the blind Schnorr scheme is con-
currently secure (in the AGM+ROM) if and only if the signer issues at most
polylogarithmically many signatures. This is a weak security guarantee as an
attacker that is allowed to make polynomially many concurrent signing queries
can break the scheme. We remark that security under sequential signing sessions
is still a very meaningful security guarantee and has been explored in prior works
(see below). Namely, sequentiality of sessions is easy to ensure (from the signer’s
perspective) at the expense of some efficiency.

Negative Result (Schnorr). We also show that our reduction for blind Schnorr
signatures in the AGM+ROM is optimal in the sense that it is not possible to
reduce `-SEQ-OMUF from (`−1)-OMDL (or OMDL with any lower dimension).
We use the meta-reduction technique [Cor02] to rule out reductions in a very
strong sense: we show that any algebraic reduction that reduces `-SEQ-OMUF
from (` − 1)-OMDL in the AGM+ROM, can be turned into an efficient solver
against (` − 1)-OMDL. Our result complements that of Baldimtsi and Lysy-
anskaya [BL13b], which also rules out a certain class of reductions for the blind
Schnorr scheme. Concretely, they show that reductions that program the ran-
dom oracle in a certain predictable way, can be turned into an efficient solver
against the underlying hardness assumption. While their approach restricts the
type of random oracle programming that the reduction may do, ours allows
for arbitrary programming, but restricts the reduction to be algebraic. On the

3



other hand, our (algebraic) reductions may themselves work in the AGM, which
further strengthens our result.

Positive Result (Abe). In the second part of our work, we revisit the con-
current security properties of Abe’s blind signature scheme. This scheme was
initially proven secure under the DL assumption in the ROM (with blindness
holding computationally under the DDH assumption). However, a later work by
Abe and Okhubo [OA03] pointed out that the original proof contained a flaw
and gave a security proof in the generic group model (GGM)+ROM instead.
To give a more meaningful security guarantee, we show that the scheme can be
proven secure with concurrent signing sessions under the DL assumption in the
far more realistic AGM+ROM. Our reduction follows the original proof strategy
of Abe, but uses the AGM to avoid the rewinding step which causes the problem
in his proof. This also has the upside of leading to a tightly secure scheme with
relatively practical parameter sizes.

1.2 Related Work and Discussion

We have already mentioned several works that study the security of blind sig-
natures in the concurrent signer model. In the sequential model, the work of
Baldimtsi and Lysyanskaya [BL13a] proves that an enhanced version of Abe’s
scheme is secure under DL. Pointcheval [Poi98] gave a transformation of the blind
Okamoto-Schnorr scheme that remains secure even in a (slightly) relaxed version
of the sequential model. Either of these schemes are significantly less efficient
than the Schnorr scheme (both in signature size and required computational ef-
fort). Fuchsbauer et al. [FPS20] gave a (concurrently secure) scheme under the
OMDL and modified ROS assumption in the AGM+ROM. The latter assump-
tion asserts the conjectured hardness of an (apparently harder) version of the
ROS problem, even given unbounded computing power. Nicolosi et al. [Nic+03]
showed, in the context of proactive two-party signature schemes, an attack sim-
ilar to the aforementioned ROS attack. They resolve this by heavily restricting
concurrency. Drijvers et al. [Dri+19] show how a ROS based attack can be ap-
plied in the context of multi-signatures. Finally, various constructions of blind
signatures in the standard model exist (e.g. [Fis06; Gar+11]), but are usually
not considered practical.

Open Questions. Our work leaves open the question of what can be proven
about both the Abe and Schnorr blind signature schemes in the random oracle
model only. Interestingly, the already mentioned work of Baldimtsi and Lysy-
anskaya [BL13b] rules out a security proof for the blind Schnorr scheme using
standard reduction techniques even in the sequential signing model. Namely,
their result excludes such a reduction from a computational hardness assump-
tion even if the signer just issues a single signature (which trivially restricts the
sessions to being sequential). Another interesting direction for future work could
be a more fine-grained security analysis (in the AGM+ROM) of the Schnorr
scheme in a less restrictive signing model that allows for a low degree of con-
currency. Namely, the ROS attack requires a polylogarithmic number of signing

4



sessions to be open at the same time. Thus, it might be possible to prove the
security of the scheme if, say, up to a constant number of signing sessions may
be interleaved at any given point in time. Regarding Abe’s scheme, there might
yet be a glimmer of hope that the original proof can be salvaged (i.e., without
requiring the AGM).

1.3 Organization

We first recall some preliminaries in section 2. We then provide the proof of
sequential security of blind Schnorr signatures in the AGM in section 3 and
show that this result is optimal in the number of OMDL-queries in section 3.1.
In section 4 we provide a tight reduction showing that Abe’s blind signature
scheme is concurrently secure under the discrete logarithm assumption.

2 Preliminaries

2.1 Notation and Security Games

Notation. For positive integer n, we write [n] for {1, . . . , n}. We write xj for
the j-th entry of −→x and write x $← X to denote that x is drawn uniformly at
random from set X . We denote the security parameter with Îť.

Security Games. We use the standard notion of (prose-based) security games
[BR04; Sho04] to present our proofs. We denote the binary output of a game G
with an adversary A as GA and say that A wins G if GA = 1.

2.2 The Algebraic Group Model

In the following, let pp be public parameters that describe a group G of prime
order q with generator g. (We assume for simplicity that pp also includes the
security parameter Îť). We denote the neutral element by Îľ and write all other
group elements in bold face. We further write Zq for Z/qZ.

Definition 1 (Algebraic Algorithm). We say that an algorithm A is algeb-
raic if, for any group element y ∈ G that it outputs, it also outputs a list of
algebraic coefficients −→z ∈ Ztq, i.e.,

(y,−→z ) $← A(−→x )

such that
y =

∏
xzii

We denote this representation as [y]−→x . For an adversary A that has access to
oracles during its runtime, we impose the above restriction to all group elements
that it outputs to an oracle. Similarly, all group elements that A receives through
oracle interactions are treated as inputs to A; hence, such group elements become
part of −→x when A outputs group elements (and hence algebraic coefficients) at a
later point.

5



In the algebraic group model (AGM), all algorithms are treated as algebraic
algorithms. Moreover, we define the running time of an algorithm A in the AGM
as the number of group operations that A performs.

2.3 Hardness Assumptions

We introduce the two main hardness assumptions that we will use in the sub-
sequent sections. As before, we will tacitly assume that some public parameters
pp are known and describe a group G of prime order q with generator g.

Definition 2 (Discrete Logarithm Problem (DLP)). For an algorithm A,
we define the game DLP as follows:

– Setup. Sample x $← Zq and run A on input g,U := gx.

– Output Determination. When A outputs x′, return 1 if gx
′

= U. Other-
wise, return 0.

We define the advantage of A in DLP as

AdvDLP
A := Pr

[
DLPA = 1

]
.

Definition 3 (One-More-Discrete Logarithm Problem (OMDL)). For
a stateful algorithm A and a positive integer `, we define the game `-OMDL as
follows:

– Setup. Initialize C = ∅. Run A on input g.
– Online Phase. A is given access to the following oracles:

• Oracle chal takes no input and samples a group element y $← G. It sets
C := C ∪ {y} and returns y.

• Oracle dlog takes as input a group element y. It returns dlogg y. We
assume that dlog can be queried at most ` many times.

– Output Determination. When A outputs (yi, xi)
`+1
i=1 , return 1 if for all

i ∈ [`+ 1]: yi ∈ C, gxi = yi, and yi 6= yj for all j 6= i. Otherwise, return 0.

We define the advantage of A in `-OMDL as

AdvOMDL
A,` := Pr

[
`-OMDLA = 1

]
.

2.4 Blind Signature Schemes

In this section, we introduce the syntax and security definitions of blind (three-
move) signature schemes [HKL19]. We also give a definition of blindness in the
appendix. However, we only focus on one-more-unforgeability in this work; blind-
ness proofs of either schemes can be found in previous works (although for com-
pleteness, we provide a proof of blindness for Abe’s scheme in appendix A).

6



Definition 4 (Three-Move Blind Signature Scheme). A three-move blind
signature scheme is a tuple of algorithms BS = (KeyGen,Sign := (Sign1,Sign2),
User := (User1,User2),Verify) with the following behaviour.

– The randomized key generation algorithm KeyGen takes as input paramet-
ers pp, and outputs a public key pk and a secret key sk. We assume for
convenience that pk contains pp and sk contains pk.

– The signing algorithm Sign := (Sign1,Sign2) is split into two algorithms:
• The randomized algorithm Sign1 takes as input a secret key sk and out-

puts a commitment C as well as a state StS.
• The deterministic algorithm Sign2 takes as input a secret key sk, a state
StS, and a challenge e. It outputs a response R.

– The user algorithm User := (User1,User2) is split into two algorithms:
• The randomized algorithm User1 takes as input a public key pk, a message
m, and a commitment C. It outputs a challenge e and a state StU .
• The deterministic algorithm User2 takes as input a public key pk, a state
StU , and a response R. It outputs a signature σ or ⊥.

– The deterministic verifier algorithm Verify takes as input a public key pk, a
signature σ, and a message m. It outputs either 1 (accept) or 0 (reject).

Definition 5 (`-One-More-Unforgeability (`-OMUF)). For a stateful al-
gorithm A, a three-move blind signature scheme BS, and a positive integer `, we
define the game `-OMUFBS as follows:

– Setup. Sample pk, sk via (pk, sk) $← BS.KeyGen(pp). Initialize `closed := 0
and run A on input (pk, pp).

– Online Phase. A is given access to the oracles Sign1 and Sign2 that behave
as follows.
• Oracle Sign1 takes no input and samples a fresh session identifier id. It

sets sessionid := open and generates (Cid, Stid)
$← BS.Sign1(sk). Then

it returns Cid and id.
• If `closed < `, oracle Sign2 takes as input a challenge e and a ses-

sion identifier id. If sessionid 6= open, it returns ⊥. Otherwise, it sets
`closed := `closed + 1 and sessionid := closed. Then it generates the
response R via R $← BS(sk, Stid, e) and returns R.

– Output Determination. When A outputs tuples (m1, σ1), ..., (mk, σk), re-
turn 1 if k ≥ `closed + 1 and for all i ∈ [k] : BS.Verify(pk, σi,m) = 1 and
(mi, σi) 6= (mj , σj) for all j 6= i. Otherwise, return 0.

We define the advantage of A in OMUFBS as

AdvOMUF
A,BS,` := Pr

[
`-OMUFA

BS = 1
]
.

Definition 6 (`-Sequential One-More Unforgeability (`-SEQ-OMUF)).

For a stateful algorithm A, a three-move blind signature scheme BS, and a
positive integer `, we define the game `-SEQ-OMUFBS as follows:

7



– Setup. Generate a key pair pk, sk via (pk, sk) $← BS.KeyGen(pp) and set
a flag open := 0 to indicate whether the adversary currently has an open
signing session. Initialize `closed := 0 and run A on input (pk, pp).

– Online Phase. A is given access to the following oracles.

• Oracle Sign1: if no session is currently open (open = 0), Sign1 gener-
ates (C, St) $← BS.Sign1. It sets the flag open := 1 and returns C to the
adversary. If there is already an open session (open = 1) it outputs ⊥.

• If `closed < `: Oracle Sign2 takes as input a challenge e. If the session is
open (open = 1), Sign2 generates the response R via BS.Sign2(sk, St, e).
It sets open := 0 and `closed := `closed+1, and outputs R to the adversary.
If the session is not open (open = 0) it outputs ⊥.

– Output Determination. Same as for OMUFBS.

We define the advantage of A in SEQ-OMUFBS as

AdvSEQ-OMUF
A,BS,` := Pr

[
`-SEQ-OMUFA

BS = 1
]
.

3 Sequential Unforgeability of Schnorr’s Blind Signature
Scheme

In this section we show that Schnorr’s blind signature scheme satisfies sequential
one-more unforgeability under the one-more DL assumption in the AGM. We
first recall Schnorr’s blind signature scheme BSS below.2 LetH : {0, 1}∗ → G\{ε}
be a hash function.

– KeyGen : On input pp, KeyGen samples x $← Zq and sets x := gx. It sets
sk := x, pk := x and returns (sk, pk).

– Sign1 : On input sk, Sign1 samples r $← Zq and returns the commitment
r := gr and the state StS := r.

– Sign2 : On input a secret key sk, a state StS = r and a challenge c, Sign2
computes s := c ¡ sk + r mod q and returns the response s.

– User1 : On input a public key pk, a commitment r, and a message m, User1
does the following. It samples first samples α, β $← Zq. Then, it computes

r′ := r·gα ·pkβ and c′ := H(r′,m), c := c′+β mod q. It returns the challenge
c and the state StU := (r, c, ι, β,m).

– User2 : On input a public key pk, a state StU = (r, c, α, β,m), and a response
s, User2 first checks if gs = r·xc and returns ⊥ if not. Otherwise, it computes
r′ := r · gα · pkβ and s′ := s+ α and returns the signature σ := (r′, s′).

– Verify : On input a public key pk, a signature σ = (r′, s′) and a message m,

Verify computes c′ := H(r′,m) and checks whether gs
′

= r′ · pkc
′
. If so, it

returns 1; otherwise, it returns 0.

2 We use different letters to denote the variables in the scheme than what we used
in the previous section. Our choices are in line with the standard notation for this
scheme.

8



Theorem 1. Let M be an algebraic adversary that runs in time tM, makes at
most ` queries to Sign2 in `-SEQ-OMUFBSS, and at most qh random oracle
queries to H. Then there exists an adversary B such that

AdvOMDL
B,` ≥ AdvSEQ-OMUF

M,`,BSS − q2h + qh + 2

2q
,

and B runs in time tB = tM +O(`+ qh).

We explain the proof idea first. Many of the ideas and notations are reused
from [FPS20]; we include them for completeness. Since M can query Sign2 a total
of ` times, it is allowed to open `+1 sessions and close the first ` of them (the last
session is never closed). Let x be the public key, and r1, . . . , r`+1 be the group
elements returned by Sign1. Let (m∗1, (r

∗
1, s
∗
1)), . . . , (m∗`+1, (r

∗
`+1, s

∗
`+1)) be M’s fi-

nal outputs, i.e., (r∗i , s
∗
i ) (where i ∈ [`+1]) is M’s forgery on message m∗i . Since M

is algebraic, it also outputs r∗i ’s algebraic representation (γ∗i , ξ
∗
i , ρ
∗
i,1, . . . , ρ

∗
i,`+1)

based on g,x, r1, . . . , r`+1, i.e.,

r∗i = gγ
∗
i ¡ xΞ

∗
i ¡
∏̀
j=1

r
ρ∗i,j
j ¡ rρ

∗
i,`+1

`+1 = gÎł
∗
i +ρ

∗
i,`+1r`+1 ¡ xΞ

∗
i ¡
∏̀
j=1

r
ρ∗i,j
j

(where r`+1 = dlog r`+1). Suppose M wins `-SEQ-OMUFBSS, i.e., (r∗i , s
∗
i ) is a

valid forgery on message m∗i and we have that

gs
∗
i = r∗i · xc

∗
i , (1)

where c∗i = H(r∗i ,m
∗
i ), for all i ∈ [` + 1]. The two equations above combined

yield

xc
∗
i+Ξ

∗
i ¡
∏̀
j=1

r
ρ∗i,j
j = gs

∗
i−γ

∗
i −ρ

∗
i,`+1r`+1 . (2)

The reduction to `-OMDL, B, works as follows. B queries its challenge oracle
` + 1 times to obtain x, r1, . . . , r`, samples r`+1

$← Zq and sets r`+1 ← gr`+1 ,
and simulates Sign1() by returning ri. To simulate Sign2(cj) queries, B queries
its dlog oracle and returns sj := dlog(rj ¡ xcj ). Substituting the definition of sj
into Eq. (2), we get

xc
∗
i+Ξ

∗
i−

∑`
j=1 ρ

∗
i,jcj = gs

∗
i−γ

∗
i −

∑`
j=1 ρ

∗
i,jsj−ρ

∗
i,`+1r`+1 ,

which can be used to compute x = dlog x as long as χi = c∗i +ξ∗i −
∑`
j=1 ρ

∗
i,jcj 6= 0

for some i.
Now we need to upper bound the probability that χi = 0 for all i = 1, . . . , `+

1. Recall that in [FPS20], this is reduced to the `-ROS problem (which can be
solved in polynomial time when ` ≥ λ, as shown in the recent work of [Ben+21]).
Here, since we are in the sequential setting where the adversary must close one
session before opening another, we can make a statistical argument instead.

9



For each message/forgery pair (m∗i , (r
∗
i , s
∗
i )), there is a corresponding random

oracle query H(r∗i ,m
∗
i ). (If M does not make such a query, then Pr[χi = 0] =

1/q.) Call this query the i-th special query. Any special query is made during
a session which is eventually closed (i.e., between M’s j-th Sign1 query and
j-th Sign2 query for some j ∈ [`]), or between two sessions (including before
the first session), or during the last session which is never closed. If there is any
special query (say the i-th) made between two sessions or during the last session,
then it is not hard to see that all coefficients in χi’s expression, except c∗i , are
fixed when M makes its i-th special query. On the other hand, c∗i is a uniformly
random integer in Zq. Therefore, Pr[χi = 0] = 1/q for a single H(r∗i ,m

∗
i ) query.

Otherwise, i.e., if all special queries are made during some session which is
eventually closed, since there are ` such sessions and `+ 1 special queries, there
is at least one session (say the j0-th) with at least two special queries (say the
i-th and (i + 1)-th) during it. At the time when M makes its (i + 1)-th special
query, i.e., when c∗i+1 is chosen at random from Zq, all coefficients in both χi
and χi+1’s expression, except c∗i+1 and cj0 , are fixed. Therefore, at this time
whether M can come up with a cj0 s.t. χi = χi+1 = 0 is already determined,
and it depends on the random choice of c∗i+1. It can be shown that there is at
most one c∗i+1 s.t. the linear system χi = χi+1 = 0 (with unknown cj0) has a
solution; therefore, Pr[χi = χi+1 = 0] ≤ 1/q for a single pair of H(r∗i ,m

∗
i ) and

H(r∗i+1,m
∗
i+1) queries.3

Proof. Let M be as in the theorem statement. Without loss of generality, we
assume that M makes exactly ` + 1 many Sign1() and exactly ` many Sign2

queries, and returns exactly ` + 1 valid signatures (r∗1, s
∗
1), . . . , (r∗`+1, s

∗
`+1) of

messages m∗1, . . . ,m
∗
`+1.4 We further assume that pairs (m∗1, r

∗
1), . . . , (m∗`+1, r

∗
`+1)

are all distinct; otherwise M could not win `-SEQ-OMUFBSS as we prove in
the following simple claim.

Claim. The pairs (m∗i , r
∗
i ), . . . , (m

∗
j , r
∗
j ) are pairwise distinct for all i, j ∈ [`+ 1].

Proof. Suppose (m∗i , r
∗
i ) = (m∗j , r

∗
j ) for i 6= j ∈ [` + 1]. If s∗i = s∗j then M

outputs two identical message/signature pairs, violating the winning condition.
Otherwise it cannot be the case that both (r∗i , s

∗
i ) and (r∗i , s

∗
j ) are both valid

signatures of m∗i , since given m∗i and r∗i , s
∗
i as in the valid signature is uniquely

defined (as in Eq. (1)). ut

Let x be the public key, r1, . . . , r`+1 be the group elements returned by Sign1,
and M’s Sign2 queries be Sign2(c1), . . . ,Sign2(c`). The proof goes by a sequence

3 We remark that this is essentially the 1-ROS problem, which is statistically hard.
4 Since the security game is sequential OMUF, and M can make at most ` many Sign2

queries, this implies that M can make at most `+ 1 many Sign1 queries. Obviously,
any adversary who makes less than ` + 1 many Sign1 queries, or less than ` many
Sign2 queries, or returns more than ` + 1 valid signatures, can be turned into an
adversary who makes exactly ` + 1 many Sign1 and exactly ` many Sign2 queries,
and returns exactly `+ 1 valid signatures, with the same advantage and roughly the
same running time.

10



of games, which we describe below. For convenience, we set AdvGi

M := Pr[GM
i =

1].

Game G0. This is the `-SEQ-OMUF game. We have that

AdvG0

M = AdvSEQ-OMUF
M,`,BSS .

Game G1. In G1 we make the following change. When M returns its final
outputs (m∗1, (r

∗
1, s
∗
1)), . . . , (m∗`+1, (r

∗
`+1, s

∗
`+1)), together with r∗i ’s algebraic rep-

resentation (γ∗i , ξ
∗
i , ρ
∗
i,1, . . . , ρ

∗
i,`+1) based on g,x, r1, . . . , r`+1, for each i ∈ [`+1]

for which H(r∗i ,m
∗
i ) is undefined, we emulate a query c∗i := H(r∗i ,m

∗
i ) via lazy

sampling. (If M has not seen a certain rj when outputting r∗i , then the game
naturally sets ρ∗i,j = 0, as M is not allowed to use rj as a base.) After that, we

define χi := c∗i + ξ∗i −
∑`
j=1 ρ

∗
i,jcj , and abort if χi = 0 for all i. (Note that ρ∗i,`+1

does not appear in the definition of χi.)
G1 and G0 are identical unless χi = 0 for all i ∈ [`+ 1]. Call this event E.

Claim. Pr[E] ≤ q2h+qh+2
2q

Proof. If M does not query H(r∗i ,m
∗
i ) for some i, then c∗i is a uniformly random

element of Zq in M’s view, so Pr[χi = 0] = 1/q.
Next we assume that M queries H(r∗i ,m

∗
i ) for all i; call such query the i-th

special query. Since (m∗i , r
∗
i ) pairs are all distinct, c∗i = H(r∗i ,m

∗
i ) is a uniformly

random element in Zq (independent of everything else) when M makes the i-
th special query. Also, r∗i ’s algebraic representation (γ∗i , ξ

∗
i , ρ
∗
i,1, . . . , ρ

∗
i,`+1) is

already determined when M makes its i-th special query. Any special query is
made either during a session which is eventually closed (i.e., between M’s j-th
Sign1 query and j-th Sign2 query for some j ∈ [`]), or between two sessions
(including before the first session), or during the last session which is never closed
(i.e., after M’s (`+ 1)-th Sign1 query). We consider these cases separately:

Case C1. Suppose that there is any special query (say the i-th) made (a) between
two sessions (including before the first session); say the i-th special query is
made after the j0-th Sign2 query and before the (j0 + 1)-th Sign1 query, or
(b) after the (` + 1)-th Sign1 query. Consider the time when M makes its i-th
special query H(r∗i ,m

∗
i ). In case (a), at this point all group elements M has

seen are g,x, r1, . . . , rj0 , so ρ∗i,j0+1 = . . . = ρ∗i,` = 0; furthermore, the algebraic
coefficients (for r∗i ) ξ

∗
i , ρ
∗
i,1, . . . , ρ

∗
i,j0

are all fixed. Finally, cj (where j ∈ [j0])
is fixed when M makes its j-th Sign2 query, which happens before M’s i-th
special query. Similarly, in case (b), at this point the algebraic coefficients (for
r∗i ) ξ

∗
i , ρ
∗
i,1, . . . , ρ

∗
i,`+1 are all fixed, and c1, . . . , c` are fixed when M makes its

`-th Sign2 query, which happens before M’s i-th special query. This means that
in both cases (a) and (b), all coefficients in χi’s expression, except c∗i , are fixed
when M makes its i-th special query. On the other hand, c∗i is a uniformly random

element in Zq. Therefore, Pr[χi = c∗i + ξ∗i −
∑j0
j=1 ρ

∗
i,jcj = 0] = 1

q , for a single

H(r∗i ,m
∗
i ) query. Since M makes qh random oracle queries in total, we have that

Pr[χi = 0 ∧ C1] ≤ qh
q , and hence Pr[E ∧ C1] ≤ qh

q .

11



Case C2. Suppose that all special queries are made during some session which
is eventually closed. Since there are ` such sessions and ` + 1 special queries,
there is at least one session with at least two special queries during it; say the
i-th and (i+1)-th special queries are made during the j0-th session. Consider the
time when M makes its (i+ 1)-st special query. At this point all group elements
M has seen are g,x, r1, . . . , rj0 , so ρ∗i,j0+1 = . . . = ρ∗i,` = 0; furthermore, the
algebraic coefficients (for r∗i and r∗i+1) ξ∗i , ρ

∗
i,1, . . . , ρ

∗
i,j0
, ξ∗i+1, ρ

∗
i+1,1, . . . , ρ

∗
i+1,j0

are all fixed. The output of M’s i-th special query c∗i is also fixed right after M
makes its i-th special query, which happens before M’s (i+ 1)-th special query.
Finally, cj (where j ∈ [j0−1]) is fixed when M makes its j-th Sign2 query, which
again happens before M’s (i+ 1)-th special query. (This is because M’s (i+ 1)-th
special query is made during the j0-th session, which is started after the j-th
session is closed.) This means that all coefficients in χi and χi+1’s expressions,
except cj0 and c∗i+1, are fixed when M makes its (i+ 1)-th special query.
Next consider the time when M makes its j0-th Sign2 query (i.e., when the j0-th
session is closed). At this point c∗i+1 is also fixed, so the only coefficient in χi
and χi+1’s expressions which is not fixed is cj0 (to be chosen by M). In sum, the
last coefficient fixed is cj0 (chosen by M), and the second last coefficient fixed is
c∗i+1 (uniformly random in Zq).
Consider the linear system with unknown cj0

{
χi = c∗i + ξ∗i −

∑j0
j=1 ρ

∗
i,jcj = 0,

χi+1 = c∗i+1 + ξ∗i+1 −
∑j0
j=1 ρ

∗
i+1,jcj = 0.

(3)

Denote A :=

(
ρ∗i,j0 c∗i + ξ∗i −

∑j0−1
j=1 ρ∗i,jcj

ρ∗i+1,j0
c∗i+1 + ξ∗i+1 −

∑j0−1
j=1 ρ∗i+1,jcj

)
and B :=

(
ρ∗i,j0
ρ∗i+1,j0

)
the

augmented matrix and coefficient matrix, respectively, of (3). Then

Pr[χi = χi+1 = 0] = Pr[cj0 is the solution of (3)] ≤ Pr[(3) has a solution]

= Pr [rank(A) = rank(B)] ≤ Pr [rank(A) ≤ 1] = P";"""date"",""2021-03-04T13:29:18Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2021-03-04T13:29:18Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.20 (TeX Live 2019/Debian) kpathsea version 6.3.1""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2021-03-04T13:29:18Z""
""created"",""2021-03-04T13:29:18Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2021-03-04T13:29:18Z""
""resourceName"",""1071.pdf""
""Author"",""""
""producer"",""pdfTeX-1.40.20""
""pdf:docinfo:producer"",""pdfTeX-1.40.20""
""pdf:unmappedUnicodeCharsPerPage"",""12"",""2"",""9"",""0"",""2"",""16"",""21"",""25"",""49"",""27"",""21"",""16"",""33"",""17"",""27"",""47"",""19"",""47"",""3"",""16"",""20"",""46"",""3"",""7"",""30"",""29"",""20"",""28"",""0"",""3"",""22"",""3"",""0"",""0"",""0"",""23"",""10"",""6"",""8""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2021-03-04T13:29:18Z""
""Last-Modified"",""2021-03-04T13:29:18Z""
""dcterms:modified"",""2021-03-04T13:29:18Z""
""title"",""""
""Last-Save-Date"",""2021-03-04T13:29:18Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2021-03-04T13:29:18Z""
""meta:save-date"",""2021-03-04T13:29:18Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.20 (TeX Live 2019/Debian) kpathsea version 6.3.1""
""Content-Length"",""536053""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""39""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""1988"",""2574"",""2649"",""2657"",""1790"",""1541"",""2065"",""1946"",""1772"",""2643"",""2448"",""1955"",""1098"",""2185"",""1461"",""2057"",""1526"",""1479"",""2409"",""2133"",""2178"",""1901"",""2153"",""2306"",""1756"",""1662"",""1876"",""2136"",""2321"",""2091"",""1203"",""1614"",""2283"",""2326"",""513"",""1702"",""2049"",""2389"",""2213""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2021-03-04T13:29:18Z""
";https://scholar.google.ch/scholar?start=830&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098725-16;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;What's in the Box? Combating Counterfeit Medications in Pharmaceutical Supply Chains;T Clohessy, S Clohessy ; Blockchain and Distributed Ledger …, 2020  books.google.com;;"… Blockchain, the technology underpinning the Bitcoin cryptocurrency, has been touted as a … of

elimination (eg removal of duplicates, companies focusing solely on crypto services, brokers … and

secured manner by all supply chain ecosystem partners, Oracle's blockchain cloud IoT …";Autres articles;;null;;;;https://scholar.google.ch/scholar?start=560&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098853-305;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Towards an auditable cryptographic access control to high-value sensitive data;K Kanciak, K Wrona ; International Journal of Electronics and …, 2020  yadda.icm.edu.pl;;"… From crypto perspective it is more like hash- ing than encryption … Every operation (addition, removal,

key instantiation) is logged on blockchain … The scheme is characterized by a chosen-ciphertext

security in the random oracle model, assuming a variant of the com- putational …";Autres articles;;[PDF] icm.edu.pl;http://yadda.icm.edu.pl/baztech/element/bwmeta1.element.baztech-fde71d25-3594-4f3d-bcea-12207b9df78b/c/449-458_Kanciak.pdf;"
INTL JOURNAL OF ELECTRONICS AND TELECOMMUNICATIONS, 2020, VOL. 66, NO. 3, PP. 449-458
Manuscript received February 29, 2020; revised July, 2020. DOI: 10.24425/ijet.2020.131898

Towards an Auditable Cryptographic Access
Control to High-value Sensitive Data

Krzysztof Kanciak, and Konrad Wrona

Abstract—We discuss the challenge of achieving an auditable
key management for cryptographic access control to high-value
sensitive data. In such settings it is important to be able to audit
the key management process - and in particular to be able to
provide verifiable proofs of key generation. The auditable key
management has several possible use cases in both civilian and
military world. In particular, the new regulations for protection
of sensitive personal data, such as GDPR, introduce strict
requirements for handling of personal data and apply a very
restrictive definition of what can be considered a personal data.
Cryptographic access control for personal data has a potential
to become extremely important for preserving industrial ability
to innovate, while protecting subject’s privacy, especially in the
context of widely deployed modern monitoring, tracking and pro-
filing capabilities, that are used by both governmental institutions
and high-tech companies. However, in general, an encrypted data
is still considered as personal under GDPR and therefore cannot
be, e.g., stored or processed in a public cloud or distributed
ledger. In our work we propose an identity-based cryptographic
framework that ensures confidentiality, availability, integrity of
data while potentially remaining compliant with the GDPR
framework.

Keywords—Identity-based encryption, GDPR

I. INTRODUCTION

IT is often claimed that the 21st century is an age of data.
The data is one of the most important assets, enabling

information superiority for military operations, protection of
citizens by the governments and continuous improvement in
health care and other public services. Although data mining
and artificial intelligence have been around for several decades,
attracting fluctuating research and commercial interest, it is in
the last decade that the data, and particular the personal data,
became one of the most sought for assets - both in context of
commercial activities and the intelligence gathering.

Despite of all this potential for contributing to greater good,
the data can be also used for malicious purposes - and indeed
the immediate impact of this malicious use on individuals
and society can be even greater than long-term opportunities
promised by so-called data science. Identity theft, manipu-
lation of public opinion, and activity of companies such as
Cambridge Analytica are all good examples how data can be

This work was supported by the project SEMACITI financed by the
Polish Ministry of Defence as a part of Kosciuszko Programme.

K. Kanciak is with Military University of Technology, Warsaw, Poland.
K. Wrona is with NATO Cyber Security Centre, The Hague, The

Netherlands and with Military University of Technology, Warsaw, Poland.
This work was presented at the International Scientific Conference Math-

ematical Cryptology & Cybersecurity (MC&C 2020), Warsaw, 16-17.01.2020.

misused. Moreover, the high profile leaks by insiders, such as
Bradley Manning and Edward Snowden, and through national-
sponsored hackers, such as the Sandworm group [1], underline
the need for strengthening defence-in-depth measures and
ensuring confidentiality and integrity of data at rest, in transit
and in use. We need to develop a comprehensive approach for
protection of high-value sensitive data that meets both strin-
gent requirements related to defence against sophisticated and
powerful adversaries as well as stringent legal requirements
introduced by the recent privacy regulations. In the rest of
this paper we primarily focus on a civilian use case related
to protection of personal data in context of the European
GDPR regulation, however our discussion is also applicable
to governmental and military applications.

A. Protection of personal data

During the last decade we could observe an increasing
awareness among regulators and non-governmental organi-
zations about importance of protection of privacy - and in-
adequacy of the existing norms and laws in this context.
This has resulted in development of several legally-binding,
as well as voluntary, frameworks focusing on protection of
personal information - the most prominent of them being
the European Union General Data Protection Regulation [2].
The GDPR by design gives individuals better control over
their personal data (any information relating to an identified
or identifiable natural person) and establishes a single data
protection regulation across the EU, covering an easier access
to personal data, a right to rectification, a clearer right to
erasure (right to be forgotten), a new right to data portability,
a right to consent, and a right to be informed about a breach
of one’s personal data. The GDPR generally follows a binary
approach to personal data – the data is either personal or not.
If data is considered to be personal data, the full weight of the
GDPR’s regulatory regime applies to any entity processing that
information. In this context, an encrypted personal data falls
in a kind of a grayscale - although ciphertexts can be mostly
considered as indistinguishable in context of the concerned
subjects, they can still be matched to the concrete subject if
an appropriate key is available.

There is a fundamental contradiction between development
of new business models, that often utilize a wide spectrum
of data sources, and the ability to enforce an effective pro-
tection of personal data. The increased operational burden
and potential liability, introduced by legal frameworks such as

cŠ The Author(s). This is an open-access article distributed under the terms of the Creative Commons Attribution License (CC BY 4.0,
https://creativecommons.org/licenses/by/4.0/), which permits use, distribution, and reproduction in any medium, provided that the Article is properly cited.

https://creativecommons.org/licenses/by/4.0/deed.en
https://creativecommons.org/licenses/by/4.0/


450 K. KANCIAK, K. WRONA

the GDPR, can discourage and hamper innovation in services
and new business model. With the GDPR, even organizations
without a physical market presence in the EU may still be
required to comply with the GDPR if the organization offers
paid or unpaid goods or services to individuals located in the
EU or if the organization is collecting personal data about
individuals within the EU. In addition, if an organization works
with suppliers or partners that operate in the EU, they will
expect the organization to comply with the GDPR in order to
limit their own risk. The GDPR compliance is considered a
requirement to conduct business with EU data subjects.

It is worth mentioning that year by year (or data theft by
data theft) individuals are becoming increasingly aware of
the threats of data breaches, as well as of commercial value
of their personal data. The GDPR provides a framework for
protecting personal data across the European Union and aims
to give back the control over personal data to individuals. As
a consequence, an adequate balance between personal data
protection and data-based business models has to be achieved.
We think that modern cryptography offers tools that make it
possible.

B. Cryptographic solutions to personal data protection

We believe that cryptography provides a key solution to
protect privacy of individuals while preserving opportunities
for innovation in IT services. In our work we discuss a
set of cryptographic techniques that ensure confidentiality,
availability, integrity of data and at the same time are in our
opinion compliant with data protection framework. Moreover,
thanks to use of cryptography, consumers could in a potentially
much more fine-grained and dynamic way decide with whom,
when and what data they share.

Personal data encryption has a potential to become ex-
tremely important for preserving innovation in business mod-
els in a data-driven economy, while protecting subjects’ pri-
vacy, especially in the context of widely deployed modern
monitoring, tracking and profiling capabilities, used both
by governmental institutions and by high-tech companies.
We support an opinion that for achieving balance between
data protection and not restricting the growth of the digital
economy would be for the European Data Protection Board
(EDPB) to maintain an up-to-date list of proven encryption
technologies. Any personal data that was encrypted with those
technologies vetted by the EDPB would be considered “not
personal” for any parties who did not have the encryption
key. [3]. In such scenario, any personal data that is encrypted
using cryptographic solutions vetted by the EDPB would be
considered not personal. In this article we propose suitable
candidates for such cryptographic solutions and discuss some
of challenges related to their use in practice.

In order to make our discussion more concrete, let us discuss
some examples of business use cases where individuals will-
ingly provide their consent to disclose some of their personal
data. In 1998 auto insurance company Progressive launched
in the United States so called Snapshot program 1, the first
large scale telematic-based tracking program. Progressive used

1https://www.progressive.com/auto/discounts/snapshot/

the program to incentivize good driving habits by offering
discounts to safe drivers. However, in 2013, the company
started using the collected data also to penalize the bad drivers.
Quasi overnight, the application of the collected data has
changed - from awarding to penalizing. And although from a
technical perspective one could argue that this is alike, clearly
from the perspective of the users, it has a completely different
impact.

C. Privacy-preserving storage

Privacy-preserving storage of personal data in a public
repository, such as a public cloud or a distributed ledger,
enables also new channels of communication between or-
ganizations, including financial institutions, and their users
or clients. Various EU regulatory provisions require that a
company must provide certain information to a client in
writing, either on paper or using another durable medium.
Such record-keeping requirements are included, for example,
in the revised Markets in Financial Instruments Directive
(MiFID II). Therefore, durable medium has become one of
the biggest regulatory challenges for the financial institutions
and banks are analyzing various durable medium options
and looking into innovative alternatives. One of frequently
discussed technologies include distributed ledger technology.
However, most of such blockchain-based notary-like solutions
are not compliant with the restrictions placed on personal data
processing by the GDPR.

D. Fine-grained release of information

Many of the current approaches to protecting access to
personal data are largely binary - when a legal agreement with
a service provider is acknowledged by the user, the provider
gains access to all future (and sometimes even some past)
personal data of interest. This approach is questionable, as
the user has to rely on and trust the provider with respect
to technical measures taken to protect his data, as well as to
adhering to an intended use of the data. Of course, there is
a legal framework in place to protect user, but this does not
address the fact that once privacy regarding some data is lost,
e.g. due to a successful cyber attack or commercial misuses,
it cannot be regained.

Cryptographic access control has a potential to offer much
more fine-grained control over release of personal data. In
particular, using approaches such as attributed-based access
control, relatively complex access control policies can be
integrated into the key management process. This, combined
with individual encryption of specific data elements, enable
implementation of fine-grained approach to control and release
of personal data.

Our proposed framework uses a combination of mechanisms
in order to ensure a holistic protection of data. Identity-based
encryption (IBE) is used to preserve confidentiality, whereas
integrity and accountability are protected by a blockchain.
Availability is ensured by a decentralized high-performance
storage system.

As our goal is to make our work understandable to a broad
spectrum of readers with varying background, we provide in

https://www.progressive.com/auto/discounts/snapshot/


TOWARDS AN AUDITABLE CRYPTOGRAPHIC ACCESS CONTROL TO HIGH-VALUE SENSITIVE DATA 451

the following sections a concise introduction to all crypto-
graphic, legal and operational concepts that are required to
understand our framework.

E. Related work

We observe growing number of articles about managing
sensitive data in distributed environments and we share emerg-
ing opinion that simple encryption mechanisms do not cover
all desired by GDPR regulation requirements. This subject is
gaining a lot of attention recently, but we are not aware of any
ready-made approach or system in the world of cryptography
that solves all issues formulated above without any doubts.
In our work we cover various areas, such as the GDPR com-
pliance [4], [5], data protection, cryptography and distributed
ledger technology. However, from a functional perspective
the most related work is in the area of blockchain-based
encryption schemes and privacy-preserving solutions [6]–[12]
such as Identity-Based Puncturable Encryption, decentralized,
fine-grained key management [13]–[15], decryption delegation
rights management [16]–[18], and threshold schemes [19]–
[21]. In our work we focus on permissioned blockchain
solutions like Hyperledger blockchain technologies ecosys-
tem [22]. However, our solution could be also extended to
achieve larger decentralization by using a public ledger -
our inspiration here is from the work performed within the
NuCypher project 2 and Umbral threshold proxy re-encryption
scheme [23], [24]. NuCypher allows data owner delegating
decryption rights to recipient through a re-encryption process
performed by a set of semi-trusted proxies. When threshold
value of proxies perform re-encryption, recipient is able to
combine these independent re-encryptions and decrypt the
original message using his private key.

II. CRYPTOGRAPHY AND LEGAL DATA PROTECTION
REQUIREMENTS

An obvious and potentially effective approach to protecting
personal data is encryption. Data-intensive systems, such as
financial systems or IoT solutions, may collect various data
that can be considered personal, at the same time introducing
a business need to store and process collected big data in
a convenient and cost-effective way. But the question if an
encrypted data should be treated as personal or not gets
convoluted due to the GDPR’s inclusion of two other concepts:
anonymization and pseudonymization.

The GDPR considers anonymized data as data, which has
been irreversibly stripped of any way of identifying the
underlying individual, even by the organization that did the
anonymizing. From crypto perspective it is more like hash-
ing than encryption. Encryption assumes ciphertext-plaintext
mapping existence. Thus encryption is definitely not locking
the data up and throwing away the key.

Pseudonymization, on the other hand, involves the process-
ing of personal data in such a way that the data can no
longer be attributed to a specific data subject without the use
of additional information. While it does provide additional

2https://www.nucypher.com/

safeguards, pseudonymized data, unlike anonymized data, is
still unequivocally considered personal data under the GDPR,
as noted in Recital 26. Under that same recital, anonymized
data is no longer personal data because it has been transformed
to unidentifiable. Article 4 of the GDPR states that personal
data is ‘any information relating to an identified or identifiable
natural person (‘data subject’).’ Thus, as long as there is a key
to the encrypted data out there somewhere, the personal data
can be traced back to the individual and the GDPR will apply.

Pseudonymized data, however, should be considered identi-
fiable if it could be attributed to an individual. Pseudonymiza-
tion is reversible and entity, which pseudonymized the data,
possesses secret mapping to reverse the process. This is,
from cryptographic point of view, more or less definition of
encryption. In anonymization, no one has a secret key or
the key is gone. In pseudonymization, the same party who
pseudonymizes the data usually does have a key. However,
with encryption, many of the parties who are processing
the data, such as cloud storage providers, do not have the
encryption key to unscramble that data. The encryption key
stays with the generator or the end user of the data. The
fundamental difference is: Who holds the metaphorical key?

A. Role of encryption in enforcement of the GDPR

Encryption is mentioned in the GDPR as one of the mea-
sures that can be taken to maintain security and to prevent
processing in infringement of the regulation, but it is not as
strong category as pseudonymization or anonymization. The
GDPR states that companies need to take into account the
state-of-the-art, risks and severity for the rights and freedoms
of the data subjects when implementing encryption. This en-
cryption should ideally always cover the entire communication
in an end-to-end manner and it is nowadays becoming common
practice.

The simple conclusion is that encrypted data is consid-
ered as personal and cannot be processed, e.g., on a public
blockchain. This differs from an approach commonly taken by
cryptographers and in secure protocol design, where an objec-
tive is to ensure that an encrypted data is, generally speaking,
indistinguishable from a random string of bits and thus may
be transported over public channels. Nevertheless, because of
mostly reversible character of encryption, it is often argued
that encryption is from a legal perspective more conceptually
similar to pseudonymization than anonymization and therefore
encrypted data would also be considered as a personal data
under the GDPR [3]. We think that the question of how
encrypted data would be viewed under the GPDR is still an
open one. We believe it is important to create discussion forum
with participants with legal and cryptographic background in
order to explore this important topic more in-depth.

B. Identity-based encryption for personal data protection

We believe that identity-based encryption (IBE) may offer a
suitable answer to the GDPR personal data protection require-
ments. In identity-based approach publicly known string (e.g
email address of recipient) is needed to encrypt message, but
the instantiation of the decryption key is separated in time until

https://www.nucypher.com/


452 K. KANCIAK, K. WRONA

the moment when recipient makes request to so-called Key
Generation Center (KGC). The complete process is described
in more details in Section IV. But, the most important fact
from the privacy perspective is that the secret key, required for
decryption of the data, does not exist until the recipient asks
for its generation. We think this very specific setting may solve
the problem of possessing keys to pseudonymized data (that
was formulated in paragraph above) and allows considering
IBE encrypted data as not personal. Proposed approach has
several advantages:
• key recovery in IBE setting is fully controlled by KGC

and the key does not exist up to successful authorization
of secret message recipient;

• key recovery process fulfills policy implemented in orga-
nization (including the right to be forgotten);

• organization is able to implement policies that will ensure
proper data processing like private key expiration period
or forgotten user policy;

• message recipient does not need private key before he
receives message (PKI case).

In [25] we can find same considerations: there is an on-
going debate surrounding whether data typically stored on
a distributed ledger, such as public keys and transactional
data qualify as personal data for the purposes of the GDPR.
Specifically, the question is whether personal data that has
been encrypted or hashed still qualifies as personal data. This
document points that the holder of the encryption key can
still re-identify each data subject through decryption given that
the personal data is still present in the dataset that has been
encrypted. As a consequence, encrypted data remains personal
data — at least for the holder of the key able to identify
such data. The Article 29 Working Party 3 indeed clarified
in its opinion on cloud computing that although encryption
’may significantly contribute to the confidentiality of personal
data if implemented correctly’ it does not ’render personal
data irreversibly anonymous’ (Directive 95/46/EC. Recital 26).
In [26] it was suggested that ’sufficiently well-encrypted data,
where the provider has no access to the key, should not be
’personal data’, and similarly with sufficiently anonymised
data’. This implies that there is a fundamental distinction from
a legal perspective between scenarios, where parties may have
access to the decryption key and the scenarios where it could
be ensured that such access does not exist.

IBE allows decryption key creation to be postponed to
the decryption moment. Until the key is created the risk of
linking the data to the owner is reduced - and would require
successful attack on a used cryptographic mechanism or its
implementation. In our work we consider blockchain-based
IBE decryption key creation that meets the requirement of
auditability.

III. AUDITABLE KEY AND DATA MANAGEMENT

As discussed earlier, a critical assumption in our approach is
non-existence of the decryption key before generation of such
key is requested by an authorized user. However, the meaning

3https://ec.europa.eu/newsroom/article29/news.cfm

of non-existence requires some more discussion. In particular,
in a naive implementation of an IBE, the key generation
authority has to be treated as a trusted-third party, as it can
generate, without user’s knowledge, private keys related to
his identity. A same naive implementation could include an
identifier of a recipient of an encrypted document in a metadata
attached to the encrypted object. In such a scenario, it would
be easy for a compromised - or misbehaving - key generation
authority to generate the decryption and to decrypt any chosen
object encrypted under the scheme. Moreover, such a scenario
does not provide a strong and auditable privacy protection. In
this case, although the decryption key might not exist in the
theory at the moment when data is encrypted, in practice it
can be easily generated on-demand by an authority without a
control or knowledge of a user - this can result effectively in a
Big Brother scenario that, although most probably welcomed
by many governments and organizations, is unacceptable from
a citizen’s perspective.

In order to prevent such a systematic failure, the imple-
mented IBE scheme needs to meet specific requirements that
are discussed in the following sections.

A. Anonymization of encrypted objects
The encrypted objects cannot provide any clues that would

enable disclosure of the identity required for decryption. The
idea of fully anonymous IBE ciphertexts was explored, e.g.,
in [27] and [28]. The committed blind anonymous IBE scheme
has been proposed in [29] and has an advantage of fulfilling
both our requirement for anonymity of the ciphertext and
escrow protection, as discussed in the next section.

B. Preventing unilateral generation of decryption keys
In order to ensure an auditable cryptographic access control,

we would like to prevent any entity from unilateral generation
of the decryption keys. This simple to formulate requirement
is rather difficult to achieve in practice. For example, in IBE
the ability to generate the decryption key is removed from the
end user, and assigned to the key generation center (KGC)
instead. Unfortunately, in simple IBE schemes KGC needs to
be a trusted party, as it is able to generate any decryption
used in the system.There are two main approaches that can
be implemented in order to reduce and control the inherent
key escrow characteristics of the IBE schemes. They both rely
on splitting of some aspects of the key generation authority
between multiple entities:

1) Separation of the identity authentication and key gener-
ation actions between two or more parties [30],

2) Dividing of the secret key required for generation of the
private decryption key between multiple entities [31],
[32].

In both cases the ability of key escrow and uncontrolled de-
cryption and access to private data is significantly reduced, as
performing such illegitimate activity would require collusion
of several independent parties.

Separation of authentication and key issuing tasks between
two parties - an identity certifying authority and a key generat-
ing authority has been proposed in [30]. In this approach, iden-
tity certifying identity issues a certificate, that can be verified



TOWARDS AN AUDITABLE CRYPTOGRAPHIC ACCESS CONTROL TO HIGH-VALUE SENSITIVE DATA 453

by the key generation authority. In order to achieve increased
privacy, it is assumed that the identity certifying authority does
neither log identity of the user requesting certification nor the
issued certificate - or any other information that could be used
to connect these two.

Another method of avoiding key escrow relies on splitting
the master secret key between multiple parties, by relaying on
threshold schemes. This approach was first suggested in [31],
where implementation using verifiable secret sharing [33] was
proposed. The concept was further extended in [32].

Recently, an approach called registration-based encryption
(RBE) [34] has been proposed in order to solve the key
escrow problem in the IBE. The solution relies on replacing
private key generator with a public key accumulator. This
work has been further extended in [35], where first efficient
implementation of RBE has been proposed, and in [36], where
a verifiable RBE, providing succinct proofs of registration and
non-registration, has been proposed.

Trusted third party don’t have to be given the ability to
decrypt ciphertexts intended for users in so called certificate-
less encryption schemes [37], [38]. It’s a form of asymmetric
encryption that eliminates the disadvantages of traditional
PKI based public-key encryption scheme, i.e. doesn’t require
digital certificates or a public-key infrastructure, and identity-
based encryption i.e. it remains secure against any third party
attacks including KGC. These schemes use two pairs of keys.
One of them is a classic private-public key pair but the public
key is not signed by any kind of Certificate Authority. Second
pair of keys is ID-based and consists identity as a public
component and and the associated identity-based private key
supplied by a key generation centre beforehand. To encrypt
the message use of both public components is needed (identity
and classic public key. Decryption requires both secret values
- classic private key generated by the party of communication
and the id-based private key supplied by the key generation
centre. This setting implies the key generation centre cannot
break the confidentiality of a transmitted message as it does
not know the classic private key of any party. The problem is
that classic public keys still have to be somehow publicised
and identity cannot be easily changed (KGC is still needed
to generate private keyassociated with identity) which means
granularity and expressiveness of this approach is very limited.

C. Unique decryption key for each object

In order to enable a fine-grained cryptographic access
control and a selective release of sensitive data, it is important
to ensure that each data object is encrypted with a separate
key.

D. Durable log of key generation requests

It is important to verify, for which data objects a decryption
key has been generated - and thus which objects require
different handling and protection. Every operation (addition,
removal, key instantiation) is logged on blockchain. Decrypted
objects in our PoC are deleted or re-encrypted with ’new
identity’ which translates into a changed period of validity
(explained in Section IV-B).

IV. IDENTITY-BASED ENCRYPTION

The IBE is not a new idea - it has almost 20 years of
research history and it is an established encryption method.
For example, the Boneh-Franklin IBE scheme, which uses
techniques from pairing-based cryptography, is described in
RFC 5091, published in 2007 []. The concept of identity-
based cryptography has been introduced in [39]. Its primary
innovation was the use of user identity attributes, such as email
addresses or phone numbers, instead of digital certificates, for
encryption and signature verification. The original motivation
for IBE was to simplify certificate management in email
systems. This feature significantly reduces the complexity of
a cryptography system by eliminating the need for generating
and managing users’ certificates. It also makes it much easier
to encrypt messages to non-enrolled users, since messages may
be encrypted for users before they interact with any system
components.

Identity-based cryptosystems do not instantiate secret keys
before first encrypted message. Main advantage of IBE is
that it allows a user to encrypt a message without a need
for pre-distribution of encryption keys. An IBE is a public
key scheme, where the public key is derived directly from
the user identity, while a trusted third party, called the Key
Generation Center (KGC), generates the corresponding private
key. It means that there is a way for a sender to encrypt
secret message to a receiver without establishing symmetric
secret key or having public key of receiver. The sender needs
only identity of receiver to encrypt his message. Decryption
key is being instantiated at a distant time when receiver is
authenticated by the KGC. This means in turn that before the
user makes request to KGC for his decryption key, the key
does not exist - and therefore one can argue that encrypted
data is not pseudonymized but anonymized.

A fully functional IBE scheme has been proposed in [31].
The scheme is characterized by a chosen-ciphertext security
in the random oracle model, assuming a variant of the com-
putational Diffie-Hellman problem [40].

When Alice sends an email to Bob, she can simply encrypt
the message using the public key string. There is no need
for Alice to obtain Bob’s public key certificate. When Bob
receives the encrypted email he contacts a third party, the PKG.
Bob authenticates himself to the PKG and obtains his private
key from the PKG. Bob can then read his email.

A. Mathematical background

There are two main methods for implementing IBE
schemes. Bilinear parings on ellipitc curves groups and lat-
tices. Bilinear pairings based schemes have much shorter
keys and ciphertexts and these are important in context
of distributed computing and communication with public
or permissioned distributed ledgers. But these schemes are
susceptible to quantum attacks due to Shor’s algorithm. On
the other hand lattice based IBEs such like Gentry-Peikert-
Vaikuntanathan [41] and Agraval-Boneh-Boyen [42] and their
extensions have quantum algorithm resistance i.e. there are no
quantum algorithms for solving hard computational problems
for lattices.



454 K. KANCIAK, K. WRONA

Below we describe an IBE scheme using pairings on elliptic
curves. Pairings map pairs of points on an elliptic curve
into the multiplicative group of a finite field. First identity-
based encryption scheme was published in 2001 by Boneh
and Franklin’s [31]. A comprehensive report on pairing-based
cryptography has been published by NIST in 2015 [43].

A point on the elliptic curve E is an ordered pair (x, y),
where x, y ∈ Fq is satisfying equation y2 = x3 + ax + b
(so called the short Weierstrass equation) where a and b are
chosen so that 4a3+27b2 6= 0. Points on elliptic curve form a
finite Abelian group structure. It means there is a way to ”add”
two points on an elliptic curve, and always get another point.
To get possibility of ”points multiplication” we can add them
repeatedly and the discrete logarithm problem in such groups
is believed to be hard, making it ideal for cryptography.

A pairing is a function e that takes a pair of two poi";"""date"",""2020-07-05T23:18:08Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2020-07-05T23:18:08Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.20 (TeX Live 2019) kpathsea version 6.3.1""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2020-07-05T23:18:08Z""
""created"",""2020-07-05T23:18:08Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-07-05T23:18:08Z""
""resourceName"",""449-458_Kanciak.pdf""
""Author"",""""
""producer"",""pdfTeX-1.40.20""
""pdf:docinfo:producer"",""pdfTeX-1.40.20""
""pdf:unmappedUnicodeCharsPerPage"",""1"",""0"",""0"",""0"",""0"",""6"",""0"",""0"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2020-07-05T23:18:08Z""
""Last-Modified"",""2020-07-05T23:18:08Z""
""dcterms:modified"",""2020-07-05T23:18:08Z""
""title"",""""
""Last-Save-Date"",""2020-07-05T23:18:08Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2020-07-05T23:18:08Z""
""meta:save-date"",""2020-07-05T23:18:08Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.20 (TeX Live 2019) kpathsea version 6.3.1""
""Content-Length"",""263153""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""10""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""5162"",""5349"",""5347"",""5293"",""5373"",""4456"",""5076"",""5741"",""7027"",""2819""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-07-05T23:18:08Z""
";https://scholar.google.ch/scholar?start=850&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098892-396;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Quantum-access-secure message authentication via blind-unforgeability;G Alagic, C Majenz, A Russell, F Song ; … on the Theory and Applications of …, 2020  Springer;;"… Finally, we demonstrate that blind unforgeability is strictly stronger than a previous definition of

Boneh and Zhandry [EUROCRYPT '13, CRYPTO '13] and resolve an open problem concerning

this previous … Given an oracle algorithm \(\mathcal A\) and two oracles F and G, the …";Cité 9 fois;Les 5 versions;[PDF] nsf.gov;https://par.nsf.gov/servlets/purl/10164363;"
Quantum-Access-Secure Message
Authentication via Blind-Unforgeability

Gorjan Alagic1(B), Christian Majenz2(B), Alexander Russell3, and Fang Song4

1 QuICS, University of Maryland, and NIST, Gaithersburg, MD, USA
galagic@gmail.com

2 QuSoft and Centrum Wiskunde & Informatica, Amsterdam, The Netherlands
c.majenz@uva.nl

3 Department of Computer Science and Engineering, University of Connecticut,
Storrs, CT, USA

acr@cse.uconn.edu
4 Department of Computer Science and Engineering, Texas A&M University,

College Station, TX, USA
fang.song@tamu.ed

Abstract. Formulating and designing authentication of classical mes-
sages in the presence of adversaries with quantum query access has been
a longstanding challenge, as the familiar classical notions of unforgeabil-
ity do not directly translate into meaningful notions in the quantum
setting. A particular difficulty is how to fairly capture the notion of “pre-
dicting an unqueried value” when the adversary can query in quantum
superposition.

We propose a natural definition of unforgeability against quantum
adversaries called blind unforgeability . This notion defines a function to
be predictable if there exists an adversary who can use “partially blinded”
oracle access to predict values in the blinded region. We support the pro-
posal with a number of technical results. We begin by establishing that
the notion coincides with EUF-CMA in the classical setting and go on to
demonstrate that the notion is satisfied by a number of simple guiding
examples, such as random functions and quantum-query-secure pseudo-
random functions. We then show the suitability of blind unforgeability
for supporting canonical constructions and reductions. We prove that the
“hash-and-MAC” paradigm and the Lamport one-time digital signature
scheme are indeed unforgeable according to the definition. To support
our analysis, we additionally define and study a new variety of quantum-
secure hash functions called Bernoulli-preserving.

Finally, we demonstrate that blind unforgeability is strictly stronger
than a previous definition of Boneh and Zhandry [EUROCRYPT ’13,
CRYPTO ’13] and resolve an open problem concerning this previous def-
inition by constructing an explicit function family which is forgeable yet
satisfies the definition.

1 Introduction

Large-scale quantum computers will break widely-deployed public-key cryptog-
raphy, and may even threaten certain post-quantum candidates [6,9,10,12,23].
cŠ International Association for Cryptologic Research 2020
A. Canteaut and Y. Ishai (Eds.): EUROCRYPT 2020, LNCS 12107, pp. 788–817, 2020.
https://doi.org/10.1007/978-3-030-45727-3_27

http://crossmark.crossref.org/dialog/?doi=10.1007/978-3-030-45727-3_27&domain=pdf
https://doi.org/10.1007/978-3-030-45727-3_27


Quantum-Secure Message Authentication 789

Even elementary symmetric-key constructions like Feistel ciphers and CBC-
MACs become vulnerable in quantum attack models where the adversary is
presumed to have quantum query access to some part of the cryptosystem [16–
18,22]. As an example, consider encryption in the setting where the adversary
has access to the unitary operator |x〉|y〉 �→ |x〉|y⊕fk(x)〉, where fk is the encryp-
tion or decryption function with secret key k. While it is debatable if this model
reflects physical implementations of symmetric-key cryptography, it appears nec-
essary in a number of generic settings, such as public-key encryption and hashing
with public hash functions. It could also be relevant when private-key primitives
are composed in larger protocols, e.g., by exposing circuits via obfuscation [21].
Setting down appropriate security definitions in this quantum attack model is
the subject of several threads of recent research [8,13].

In this article, we study authentication of classical information in the
quantum-secure model. Here, the adversary is granted quantum query access
to the signing algorithm of a message authentication code (MAC) or a digital
signature scheme, and is tasked with producing valid forgeries. In the purely
classical setting, we insist that the forgeries are fresh, i.e., distinct from previous
queries to the oracle. When the function may be queried in superposition, how-
ever, it’s unclear how to meaningfully reflect this constraint that a forgery was
previously “unqueried.” For example, it is clear that an adversary that simply
queries with a uniform superposition and then measures a forgery—a feasible
attack against any function—should not be considered successful. On the other
hand, an adversary that uses the same query to discover some structural property
(e.g., a superpolynomial-size period in the MAC) should be considered a break.
Examples like these indicate the difficulty of the problem. How do we correctly
“price” the queries? How do we decide if a forgery is fresh? Furthermore, how can
this be done in a manner that is consistent with these guiding examples? In fact,
this problem has a natural interpretation that goes well beyond cryptography:
What does it mean for a classical function to appear unpredictable to a quantum
oracle algorithm? 1

Previous approaches. The first approach to this problem was suggested by
Boneh and Zhandry [7]. They define a MAC to be unforgeable if, after making
q queries to the MAC, no adversary can produce q + 1 valid input-output pairs
except with negligible probability. We will refer to this notion as “PO security”
(PO for “plus one,” and k-PO when the adversary is permitted a maximum of k
queries). Among a number of results, Boneh and Zhandry prove that this notion
can be realized by a quantum-secure pseudorandom function (qPRF).

Another approach, due to Garg, Yuen and Zhandry [14] (GYZ), considers a
function one-time unforgeable if only a trivial “query, measure in computational
basis, output result” attack2 is allowed. Unfortunately, it is not clear how to

1 The related notion of “appearing random to quantum oracle algorithms” has a sat-
isfying definition, which can be fulfilled efficiently [29].

2 Technically, the Stinespring dilation [25] of a computational basis measurement is
the most general attack.



790 G. Alagic et al.

extend GYZ to two or more queries. Furthermore, the single query is allowed
in a limited query model with an non-standard restriction.3 Zhandry recently
showed a separation between PO and GYZ by means of the powerful tool of
obfuscation [31].

It is interesting to note that similar problems arise in encryption schemes of
quantum data and a convincing solution was recently found [2,3]. However, it
relies on the fact that for quantum messages, authentication implies secrecy. This
enables “tricking” the adversary by replacing their queries with “trap” plaintexts
to detect replays. As unforgeability and secrecy are orthogonal in the classical
world, adversaries would easily recognize the spoofed oracle. This renders the
approach of [2,3] inapplicable in this case.

Unresolved issues. PO security, the only candidate definition of quantum-
secure unforgeability in the general, multi-query setting, appears to be insuf-
ficient for several reasons. First, as observed in [14], it is a priori unclear if
PO security rules out forging on a message region A while making queries to a
signing oracle supported on a disjoint message region B. Second, there may be
unique features of quantum information, such as the destructiveness of quantum
measurement, which PO does not capture. In particular, quantum algorithms
must sometimes “consume” (i.e., fully measure) a state to extract some useful
information, such as a symmetry in the oracle. There might be an adversary
that makes one or more quantum queries but then must consume the post-query
states completely in order to make a single, but convincing, forgery.

Surprisingly, prior to this work none of these plausible attack strategies have
been exploited to give a separation between PO and “intuitive security.”

2 Summary of Results

A new definition: Blind-unforgeability. To address the above mentioned
issues, and in light of the concrete “counterexample” presented below as Con-
struction 8, we develop a new definition of many-time unforgeability we call
“blind-unforgeability” (or BU). In this approach we examine the behavior of
adversaries in the following experiment. The adversary is granted quantum ora-
cle access to the MAC, “blinded” at a random region B. Specifically, we set B to
be a random Îľ-fraction of the message space, and declare that the oracle function
will output ⊥ on all of B.

BÎľMack(x) :=

{
⊥ if x ∈ Bε,

Mack(x) otherwise.

Given a MAC (Mac,Ver), an adversary A, and A-selected parameter ε, the “blind
forgery experiment” is:

3 Compared to the standard quantum oracle for a classical function, GYZ require the
output register to be empty prior to the query.



Quantum-Secure Message Authentication 791

1. Generate key k and random blinding BÎľ;
2. Produce candidate forgery (m, t) ← ABεMack(1n).
3. Output win if Verk(m, t) = acc and m ∈ Bξ; otherwise output rej.

Definition 1. A MAC is blind-unforgeable (BU) if for every adversary (A, Îľ),
the probability of winning the blind forgery experiment is negligible.

In this work, BU will typically refer to the case where A is an efficient
quantum algorithm (QPT) and the oracle is quantum, i.e., |x〉|y〉 �→ |x〉|y ⊕
BεMack(x)〉. We will also consider q-BU, the information-theoretic variant where
the total number of queries is a priori fixed to q. We remark that the above defi-
nition is also easy to adapt to other settings, e.g., classical security against PPT
adversaries, quantum or classical security for digital signatures, etc.

We remark that one could define a variant of the above where the adversary
is allowed to describe the blinding distribution, rather than it being uniform.
However, this is not a stronger notion. By a straightforward argument, an adver-
sary wins in the chosen-blinding BU game if and only if it wins with a uniform
Îľ-blinding for inverse-polynomial Îľ. Indeed, the adversary can just simulate its
chosen blinding herself, and this still succeeds with inverse polynomial probabil-
ity when interacting with a standard-blinded oracle (see Theorem2 below).

Results about blind-unforgeability. To solidify our confidence in the new
notion, we collect a series of results which we believe establish BU as a definition
of unforgeability that captures the desired intuitive security requirement. In par-
ticular, we show that BU is strictly stronger than previous candidate definitions,
and that it classifies a wide range of representative examples (in fact, all exam-
ples examined thus far) as either forgeable or unforgeable in a way that agrees
with cryptographic intuition.

Relations and characterizations. First, we show that BU correctly classifies
unforgeability in the classical-query setting: it is equivalent to the classical
unforgeability notion of EUF-CMA (existential unforgeability against chosen-
message attack). Then, we show that it implies PO.

Theorem 1. If a function family is BU-unforgeable, then it is PO-unforgeable.

One key technical component of the proof is a general simulation theorem,
which tightly controls the deviation in the behavior of an algorithm when sub-
jected to the BU experiment.

Theorem 2. Let A be a quantum query algorithm making at most T queries.
Let f : X → Y be a function, Bε a random ε-blinding subset of X, and for each
B ⊂ X, let gB a function with support B. Then

E
BÎľ

∥∥Af (1n) − Af⊕gBε (1n)
∼∼
1

≤ 2T
√

Îľ.

This result can be viewed as strong evidence that algorithms that pro-
duce “good forgeries” in any reasonable sense will also win the BU experiment.



792 G. Alagic et al.

Specifically, adversaries that produce “good forgeries” will not be disturbed too
much by blinding, and will thus in fact also win the BU experiment with non-
negligible probability.

We can formulate and prove this intuition explicitly for a wide class of adver-
saries, as follows. Given an oracle algorithm A, we let supp(A) denote the union
of the supports of all the queries of A, taken over all choices of oracle function.

Theorem 3 (informal). Let A be QPT and supp(A) ∩ R = ∅ for some R �= ∅.
Let Mac be a MAC, and suppose AMack(1n) outputs a valid pair (m,Mack(m))
with m ∈ R with noticeable probability. Then Mac is not BU secure.

Blind-unforgeable MACs. Next, we show that several natural constructions sat-
isfy BU. We first show that a random function is blind-unforgeable.

Theorem 4. Let R : X → Y be a random function such that 1/|Y | is negligible.
Then R is a blind-unforgeable MAC.

By means of results of Zhandry [29] and Boneh and Zhandry [7], this leads
to efficient BU-secure constructions.

Corollary 1. Quantum-secure pseudorandom functions (qPRF) are BU-secure
MACs, and (4q+1)-wise independent functions are q-BU-secure MACs.

We can then invoke a recent result about the quantum-security of domain-
extension schemes such as NMAC and HMAC [24], and obtain variable-length
BU-secure MACs from any qPRF.

In the setting of public verification, we show that the one-time Lamport
signature scheme [19] is BU-secure, provided that the underlying hash function
family R : X → Y is modeled as a random oracle.

Theorem 5. Let R : X → Y be a random function family. Then the Lamport
scheme LR is BU against adversaries which make one quantum query to LR and
poly-many quantum queries to R.

Hash-and-MAC. Consider the following natural variation on the blind-forgery
experiment. To blind F : X → Y , we first select a hash function h : X → Z
and a blinding set Bε ⊆ Z; we then declare that F will be blinded on x ∈ X
whenever h(x) ∈ Bε. We refer to this as “hash-blinding.” We say that a hash
function h is a Bernoulli-preserving hash if, for every oracle function F , no QPT
can distinguish between an oracle that has been hash-blinded with h, and an
oracle that has been blinded in the usual sense. Recall the notion of collapsing
from [27].

Theorem 6. Let h : X → Y be a hash function. If h is Bernoulli-preserving
hash, then it is also collapsing. Moreover, against adversaries with classical ora-
cle access, h is a Bernoulli-preserving hash if and only if it is collision-resistant.

We apply this new notion to show security of the Hash-and-MAC construc-
tion Πh = (Mach,Verh) with Mach

k(m) := Mack(h(m)).

Theorem 7. Let Π = (Mack,Verk) be a BU-secure MAC with Mack : X → Y ,
and let h : Z → X a Bernoulli-preserving hash. Then Πh is a BU-secure MAC.



Quantum-Secure Message Authentication 793

We also show that the Bernoulli-preserving property can be satisfied by pseu-
dorandom constructions, as well as a (public-key) hash based on lossy functions
from LWE [20,26].

A concrete “counterexample” for PO. Supporting our motivation to devise
a new unforgeability definition, we present a construction of a MAC which is
forgeable (in a strong intuitive sense) and yet is classified by PO as secure.

Construction 8. Given a triple k = (p, f, g) where p ∈ {0, 1}n and f, g :
{0, 1}n → {0, 1}n, define Mk : {0, 1}n+1 → {0, 1}2n by

Mk(x) =

⎧⎪⎨
⎪⎩

02n x = 0‖p,

0n‖f(x′) x = 0‖x′, x′ �= p,

g(x′ mod p)‖f(x′) x = 1‖x′.

Define gp(x) := g(x mod p) and consider an adversary that queries only on
messages starting with 1, as follows:∑

x,y

|1, x〉X |0n〉Y1 |y〉Y2 �−→
∑
x,y

|1, x〉X |gp(x)〉Y1 |y ⊕ f(x)〉Y2 ; (1)

discarding the first qubit and Y2 then yields
∑

x |x〉|gp(x)〉, as
∑

y |y⊕f(x)〉Y2 =∑
y |y〉Y2 . One can then recover p via period-finding and output (0‖p, 02n). We

emphasize that the forgery was queried with zero amplitude. In practice, we can
interpret it as, e.g., the attacker queries only on messages starting with “From:
Alice” and then forges a message starting with “From: Bob”. Despite this, we
can show that it is PO-secure.

Theorem 9. The family Mk (for uniformly random k = (p, f, g)) is PO-secure.

The PO security of M relies on a dilemma the adversary faces at each query:
either learn an output of f , or obtain a superposition of (x, g(x))-pairs for Fourier
sampling. Our proof shows that, once the adversary commits to one of these two
choices, the other option is irrevocably lost. Our result can thus be understood
as a refinement of an observation of Aaronson: quantumly learning a property
sometimes requires uncomputing some information [1]. Note that, while Aaron-
son could rely on standard (asymptotic) query complexity techniques, our prob-
lem is quite fragile: PO security describes a task which should be hard with q
queries, but is completely trivial given q + 1 queries. Our proof makes use of a
new quantum random oracle technique of Zhandry [30].

EUF-CMA
[7]⇐⇒ PO

Proposition 2⇐⇒ BU

Unforgeability against classical adversaries

PO
Corollary 2

�=⇒
⇐=

Theorem 1
BU

Observation
�=⇒
⇐=

Corollary 1
qPRF

Unforgeability against quantum adversaries

Fig. 1. Relationship between different unforgeability notions



794 G. Alagic et al.

A straightforward application of Theorem3 shows that Construction 8 is BU-
insecure. In particular, we have the following.

Corollary 2. There exists a PO-secure MAC which is BU-insecure.

The relationship between BU, PO some other notions are visualized in Fig. 1.

3 Preliminaries

Basic notation, conventions. Given a finite set X, the notation x ∈R X will
mean that x is a uniformly random element of X. Given a subset B of a set X,
let χB : X → {0, 1} denote the characteristic function of B, i.e., χB(x) = 1 if
x ∈ B and χB(x) = 0 else. When we say that a classical function F is efficiently
computable, we mean that there exists a uniform family of deterministic classi-
cal circuits which computes F . We will consider three classes of algorithms: (i)
unrestricted algorithms, modeling computationally unbounded adversaries, (ii)
probabilistic poly-time algorithms (PPTs), modeling classical adversaries, and
(iii) quantum poly-time algorithms (QPTs), modeling quantum adversaries. We
assume that the latter two are given as polynomial-time uniform families of cir-
cuits. For PPTs, these are probabilistic circuits. For QPTs, they are quantum
circuits, which may contain both unitary gates and measurements. We will often
assume (without loss of generality) that the measurements are postponed to the
end of the circuit, and that they take place in the computational basis. Given an
algorithm A, we let A(x) denote the (in general, mixed) state output by A on
input x. In particular, if A has classical output, then A(x) denotes a probability
distribution. Unless otherwise stated, the probability is taken over all random
coins and measurements of A, and any randomness used to select the input x.
If A is an oracle algorithm and F a classical function, then AF (x) is the mixed
state output by A equipped with oracle F and input x; the probability is now
also taken over any randomness used to generate F .

We will distinguish between two ways of presenting a function F : {0, 1}n →
{0, 1}m as an oracle. First, the usual “classical oracle access” simply means that
each oracle call grants one classical invocation x �→ F (x). This will always be
the oracle model for PPTs. Second, “quantum oracle access” will mean that each
oracle call grants an invocation of the (n+m)-qubit unitary gate |x〉|y〉 �→ |x〉|y⊕
F (x)〉. For us, this will always be the oracle model for QPTs. Note that both QPTs
and unrestricted algorithms could in principle receive either oracle type.

We will need the following lemma. We use the formulation from [8, Lemma
2.1], which is a special case of a more general “pinching lemma” of Hayashi [15].

Lemma 1. Let A be a quantum algorithm and x ∈ {0, 1}∗. Let A0 be another
quantum algorithm obtained from A by pausing A at an arbitrary stage of exe-
cution, performing a partial measurement that obtains one of k outcomes, and
then resuming A. Then Pr[A0(1n) = x] ≥ Pr[A(1n) = x]/k.

We denote the trace distance between states ρ and σ by δ(ρ, σ). Recall its
definition via the trace norm, i.e., δ(ρ, σ) = (1/2)‖ρ − σ‖1. When ρ and σ are
classical states, the trace distance is equal to the total variation distance.



Quantum-Secure Message Authentication 795

Quantum-secure pseudorandomness. A quantum-secure pseudorandom
function (qPRF) is a family of classical, deterministic, efficiently-computable
functions which appear random to QPT adversaries with quantum oracle access.

Definition 2. An efficiently computable function family f : K × X → Y is a
quantum-secure pseudorandom function (qPRF) if, for all QPTs D,∣∣∣ Pr

k∈RK

[Dfk(1n) = 1
]− Pr

g∈RFY
X

[Dg(1n) = 1
]∣∣∣ ≤ negl(n).

Here FY
X denotes the set of all functions from X to Y . The standard “GGM+GL”

construction of a PRF yields a qPRF when instantiated with a quantum-secure
one-way function [29]. One can also construct a qPRF directly from the Learning
with Errors assumption [29]. If we have an a priori bound on the number of
allowed queries, then a computational assumption is not needed.

Theorem 10. (Lemma 6.4 in [7]). Let q, c ≥ 0 be integers, and f : K ×X →
Y a (2q+c)-wise independent family of functions. Let D be an algorithm making
no more than q quantum oracle queries and c classical oracle queries. Then

Pr
k∈RK

[Dfk(1n) = 1
]

= Pr
g∈RFY

X

[Dg(1n) = 1
]
.

PO-unforgeability. Boneh and Zhandry define unforgeability (against quantum
queries) for classical MACs as follows [7]. They also show that random functions
satisfy this notion.

Definition 3. Let Π = (KeyGen,Mac,Ver) be a MAC with message set X. Con-
sider the following experiment with an algorithm A:

1. Generate key: k ← KeyGen(1n).
2. Generate forgeries: A receives quantum oracle for Mack, makes q queries, and

outputs a string s;
3. Outcome: output win if s contains q + 1 distinct input-output pairs of Mack,

and fail otherwise.

We say that Π is PO-secure if no adversary can succeed at the above experiment
with better than negligible probability.

The Fourier Oracle. Our separation proof will make use of a new technique of
Zhandry [30] for analyzing random oracles. We briefly describe this framework.

A random function f from n bits to m bits can be viewed as the outcome
of a quantum measurement. More precisely, let HF =

⊗
x∈{0,1}n HFx

, where
HFx

∟= C
2m

. Then set f(x) ← MFx
(ηF ) with ηF = |φ0〉〈φ0|⊗2n

, |φ0〉 = 2− m
2∑

y∈{0,1}m |y〉, and where MFx
denotes the measurement of the register Fx in

the computational basis. This measurement commutes with any CNOTA:B gate
with control qubit A in Fx and target qubit B outside Fx. It follows that, for any
quantum algorithm making queries to a random oracle, the output distribution
is identical if the algorithm is instead run with the following oracle:



796 G. Alagic et al.

1. Setup: prepare the state ΡF .
2. Upon a query with query registers X and Y , controlled on X being in state

|x〉, apply (CNOT⊗m)Fx:Y .
3. After the algorithm has finished, measure F to determine the success of the

computation.

We denote the oracle unitary defined in step 2 above by UO
XY F . Having

defined this oracle representation, we are free to apply any unitary UH to
the oracle state, so long as we then also apply the conjugated query unitary
UH(CNOT⊗m)Fx:Y U†

H in place of UO
XY F . We choose UH = H⊗m2n

, which means
that the oracle register starts in the all-zero state now. Applying Hadamard to
both qubits reverses the direction of CNOT, i.e., HA ⊗HBCNOTA:BHA ⊗HB =
CNOTB:A, so the adversary-oracle-state after a first query with query state
|x〉X |φy〉Y is

|x〉X |φy〉Y |0m〉⊗2n �−→ |x〉X |φy〉Y |0m〉⊗(lex(x)−1)|y〉Fx
|0m〉⊗(2n−lex(x)), (2)

where lex(x) denotes the position of x in the lexicographic ordering of {0, 1}n,
and we defined the Fourier basis state |φy〉 = H⊗m|y〉. In the rest of this section,
we freely change the order in which tensor products are written, and keep track
of the tensor factors through the use of subscripts. This adjusted representation
is called the Fourier oracle (FO), and we denote its oracle unitary by

UFO
XY F =

(
H⊗m2n

)
F

UO
XY F

(
H⊗m2n

)
F

.

An essential fact about the FO is that each query can only change the number
of non-zero entries in the FO’s register by at most one. To formalize this idea,
we define the “number operator” NF =

∑
x∈{0,1}n(1−|0〉〈0|)Fx

⊗1⊗(2n−1). The
number operator can also be written in its spectral decomposition,

NF =
2n∑
l=0

lPl where Pl =
∑
r∈Sl

|r〉〈r|,

Sl =
{

r ∈ ({0, 1}m)2
n
∣∣∣|{x ∈ {0, 1}n|rx �= 0}| = l

}
.

Note that the initial joint state of a quantum query algorithm and the oracle (in
the FO-oracle picture described above) is in the image of P0. The following fact
is essential in working with the Fourier Oracle; the proof is given in AppendixA.

Lemma 2. The number operator satisfies
∼∼[NF , UFO

XY F

]∼∼
∞ = 1. In particular,

the joint state of a quantum query algorithm and the oracle after the q-th query
is in the kernel of Pl for all l > q.



Quantum-Secure Message Authentication 797

4 The New Notion: Blind-Unforgeability

Formal definition. For ease of exposition, we begin by introducing our new
security notion in a form analogue to the standard notion of existential unforge-
ability under chosen-message attacks, EUF-CMA. We will also later show how to
extend our approach to obtain a corresponding analogue of strong unforgeability.
We begin by defining a “blinding” operation. Let f : X → Y and B ⊆ X. We let

Bf(x) =

{
⊥ if x ∈ B,

f(x) otherwise.

We say that f has been “blinded” by B. In this context, we will be particularly
interested in the setting where elements of X are placed in B independently at
random with a particular probability Îľ; we let BÎľ denote this random variable.
(It will be easy to infer X from context, so we do not reflect it in the notation.)

Next, we define a security game in which an adversary is tasked with using
a blinded MAC oracle to produce a valid input-output pair in the blinded set.

Definition 4. Let Π = (KeyGen,Mac,Ver) be a MAC with message set X. Let
A be an algorithm, and ε : N → R≥0 an efficiently computable function. The
blind forgery experiment BlindForgeA,Π(n, ξ) proceeds as follows:
1. Generate key: k ← KeyGen(1n).
2. Generate blinding: select Bε ⊆ X by placing each m into Bε independently

with probability Îľ(n).
3. Produce forgery: (m, t) ← ABεMack(1n).
4. Outcome: output 1 if Verk(m, t) = acc and m ∈ Bξ; otherwise output 0.

We say that a scheme is blind-unforgeable if, for any efficient adversary, the
probability of winning the game is negligible. The probability is taken over the
choice of key, the choice of blinding set, and any internal randomness of the
adversary. We remark that specifying an adversary requires specifying (in a
uniform fashion) both the algorithm A and the blinding fraction Îľ.

Definition 5. A MAC Π is blind-unforgeable (BU) if for every polynomial-time
uniform adversary (A, Îľ), Pr

[
BlindForgeA,Π(n, ε(n)) = 1] ≤ negl(n).

We also define the “q-time” variant of the blinded forgery game, which is
identical to Definition 4 except that the adversary is only allowed to make q
queries to BÎľMack in step (3). We call the resulting game BlindForgeq

A,Π(n, ξ),
and give the corresponding definition of q-time security (now against computa-
tionally unbounded adversaries).

Definition 6. A MAC Π is q-time blind-unforgeable (q-BU) if for every q-query
adversary (A, Îľ), we have Pr

[
BlindForgeq

A,Π(n, ε(n)) = 1] ≤ negl(n).

The above definitions are agnostic regarding the computational power of the
adversary and the type of oracle provided. For example, selecting PPT adver-
saries and classical oracles in Definition 5 yields a definition of classical unforge-
ability; we will later show that this is equivalent to standard EUF-CMA. The
main focus of our work will be on BU against QPTs with quantum oracle access,
and q-BU against unrestricted adversaries with quantum oracle access.



798 G. Alagic et al.

Some technical details. We now remark on a few details in the usage of BU.
First, strictly speaking, the blinding sets in the security games above cannot be
generated efficiently. However, a pseudorandom blinding set will suffice. Pseudo-
random blinding sets can be generated straightforwardly using an appropriate
pseudorandom function, such as a PRF against PPTs or a qPRF against QPT. A
precise description of how to perform this pseudorandom blinding is given in the
proof of Corollary 3. Note that simulating the blinding requires computing and
uncomputing the random function, so we must make two quantum queries for
each quantum query of the adversary. Moreover, verifying whether the forgery is
in the blinding set at the end requires one additional classical query. This means
that (4q + 1)-wise independent functions are both necessary and sufficient for
generating blinding sets for q-query adversaries (see [7, Lemma 6.4]). In any
case, an adversary which behaves differently in the random-blinding game ver-
sus the pseudorandom-blinding game immediately yields a distinguisher against
the corresponding pseudorandom function.

The Blinding Symbol. There is some flexibility in how one defines the blinding
symbol ⊥. In situations where the particular instantiation of the blinding symbol
might matter, we will adopt the convention that the blinded version Bf of
f : {0, 1}n → {0, 1}� is defined by setting Bf : {0, 1}n → {0, 1}�+1, where
Bf(m) = 0�||1 if m ∈ B and Bf(m) = f(m)||0 otherwise. One advantage of this
convention (i.e., that ⊥ = 0�||1) is that we can compute on and/or measure the
blinded bit (i.e., the (
 + 1)-st bit) without affecting the output register of the
function. This will also turn out to be convenient for uncomputation.

Strong Blind-Unforgeability. The security notion BU given in Definition 5 is an
analogue of simple unforgeability, i.e., EUF-CMA, for the case of a quantum-
accessible MAC/Signing oracle. It is, however, straightforward to define a corre-
sponding analogue of strong unforgeability, i.e., SUF-CMA, as well.

The notion of strong blind-unforgeability, sBU, is obtained by a simple adjust-
ment compared to BU: we blind (message, tag) pairs rather than just messages.
We briefly describe this for the case of MACs. Let Π = (KeyGen,Mac,Ver)
be a MAC with message set M , randomness set R and tag set T , so that
Mack : M × R → T and Verk : M × T → {acc, rej} for every k ← KeyGen.
Given a parameter Îľ and an adversary A, the strong blind forgery game pro-
ceeds as follows:

1. Generate key: k ← KeyGen; generate blinding: select Bε ⊆ M × T by placing
pairs (m, t) in BÎľ independently with probability Îľ;

2. Produce forgery: produce (m, t) by executing A(1n) with quantum oracle
access to the function

BÎľMack;r(m) :=

{
⊥ if (m,Mack(m; r)) ∈ Bε,

Mack(m; r) otherwise.

where r is sampled uniformly for each oracle call.
3. Outcome: output 1 if Verk(m, t) = acc ∧ (m, t) ∈ Bξ; otherwise output 0.



Quantum-Secure Message Authentication 799

Security is then defined as before: Π is sBU-secure if for all adversaries A (and
their declared Îľ), the success probability at winning the above game is negligi-
ble. Note that, for the case of canonical MACs, this definition coincides with
Definition 5, just as EUF-CMA and SUF-CMA coincide in this case.

5 Intuitive Security and the Meaning of BU

In this section, we gather a number of results which build confidence in BU as
a correct definition of unforgeability in our setting. We begin by showing that a
wide range of “intuitively forgeable” MACs (indeed, all such examples we have
examined) are correctly characterized by BU as insecure.

Intuitively forgeable schemes. As indicated earlier, BU security rules out any
MAC schemes where an attacker can query a subset of the message space and
forge outside that region. To make this claim precise, we first define the query
support supp(A) of an oracle algorithm A. Let A be a quantum query algorithm
with oracle access to the quantum oracle O for a classical function from n to m
bits. Without loss of generality A proceeds by applying the sequence of unitaries
OUqOUq−1...U1 to the initial state |0〉XY Z , followed by a POVM E . Here, X and
Y are the input and output registers of the function and Z is the algorithm’s
works";"""date"",""2020-04-07T10:22:53Z""
""pdf:PDFVersion"",""1.6""
""xmp:CreatorTool"",""Springer""
""pdf:docinfo:title"",""Quantum-Access-Secure Message Authentication via Blind-Unforgeability""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""Advances in Cryptology – EUROCRYPT 2020, doi:10.1007/978-3-030-45727-3_27""
""pdfa:PDFVersion"",""A-2b""
""xmpMM:History:Action"",""converted"",""converted""
""language"",""en""
""dc:format"",""application/pdf; version=""""A-2b"""""",""application/pdf; version=1.6""
""pdf:docinfo:custom:robots"",""noindex""
""pdf:docinfo:creator_tool"",""Springer""
""access_permission:fill_in_form"",""true""
""xmpMM:History:When"",""2020-04-07T15:52:10Z"",""2020-04-07T15:52:53Z""
""pdf:encrypted"",""false""
""dc:title"",""Quantum-Access-Secure Message Authentication via Blind-Unforgeability""
""xmp:CreateDate"",""2020-04-07T15:51:06Z""
""modified"",""2020-04-07T10:22:53Z""
""cp:subject"",""Advances in Cryptology – EUROCRYPT 2020, doi:10.1007/978-3-030-45727-3_27""
""xmpMM:History:SoftwareAgent"",""pdfToolbox"",""pdfToolbox""
""pdf:docinfo:custom:CrossMarkDomains[1]"",""springer.com""
""robots"",""noindex""
""pdf:docinfo:subject"",""Advances in Cryptology – EUROCRYPT 2020, doi:10.1007/978-3-030-45727-3_27""
""pdf:hasMarkedContent"",""false""
""xmpMM:History:InstanceID"",""uuid:b8de6289-65fa-48a2-9872-98cea07d8516"",""uuid:e9065eed-a4f4-4444-ae55-2b9279e906a2""
""xmp:ModifyDate"",""2020-04-07T15:52:53Z""
""pdf:docinfo:creator"",""Gorjan Alagic ""
""meta:author"",""Gorjan Alagic "",""Christian Majenz "",""Alexander Russell "",""Fang Song ""
""meta:creation-date"",""2020-04-07T10:21:06Z""
""pdf:docinfo:custom:CrossmarkMajorVersionDate"",""2010-04-23""
""created"",""2020-04-07T10:21:06Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-04-07T10:21:06Z""
""resourceName"",""10164363""
""pdfaid:part"",""2""
""pdf:docinfo:custom:CrossMarkDomains[2]"",""springerlink.com""
""pdf:docinfo:custom:doi"",""10.1007/978-3-030-45727-3_27""
""pdf:docinfo:custom:CrossmarkDomainExclusive"",""true""
""Author"",""Gorjan Alagic "",""Christian Majenz "",""Alexander Russell "",""Fang Song ""
""CrossmarkDomainExclusive"",""true""
""doi"",""10.1007/978-3-030-45727-3_27""
""pdf:unmappedUnicodeCharsPerPage"",""1"",""5"",""5"",""21"",""3"",""31"",""8"",""20"",""37"",""19"",""13"",""13"",""18"",""50"",""39"",""29"",""49"",""11"",""23"",""1"",""26"",""9"",""93"",""22"",""64"",""10"",""30"",""36"",""2"",""1""
""dc:description"",""Advances in Cryptology – EUROCRYPT 2020, doi:10.1007/978-3-030-45727-3_27""
""access_permission:modify_annotations"",""true""
""dc:creator"",""Gorjan Alagic "",""Christian Majenz "",""Alexander Russell "",""Fang Song ""
""description"",""Advances in Cryptology – EUROCRYPT 2020, doi:10.1007/978-3-030-45727-3_27""
""dcterms:created"",""2020-04-07T10:21:06Z""
""Last-Modified"",""2020-04-07T10:22:53Z""
""dcterms:modified"",""2020-04-07T10:22:53Z""
""title"",""Quantum-Access-Secure Message Authentication via Blind-Unforgeability""
""xmpMM:DocumentID"",""uuid:33c9cfd7-89fb-4671-8ca6-6980a444c30d""
""Last-Save-Date"",""2020-04-07T10:22:53Z""
""CrossMarkDomains[1]"",""springer.com""
""pdf:docinfo:modified"",""2020-04-07T10:22:53Z""
""meta:save-date"",""2020-04-07T10:22:53Z""
""Content-Length"",""514820""
""Content-Type"",""application/pdf""
""xmp:MetadataDate"",""2020-04-07T15:52:53Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Gorjan Alagic "",""Christian Majenz "",""Alexander Russell "",""Fang Song ""
""pdfaid:conformance"",""B""
""dc:language"",""EN""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""30""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""2260"",""2819"",""2232"",""2353"",""2284"",""1954"",""2611"",""2084"",""1746"",""2419"",""2448"",""2242"",""1861"",""2098"",""2160"",""2107"",""2357"",""2096"",""2411"",""2242"",""2119"",""2368"",""1479"",""2114"",""2049"",""2482"",""2394"",""2121"",""2711"",""3106""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""CrossMarkDomains[2]"",""springerlink.com""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-04-07T10:21:06Z""
""CrossmarkMajorVersionDate"",""2010-04-23""
";https://scholar.google.ch/scholar?start=940&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098884-373;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;[PDF][PDF] Long Paper v1. 0.0 Clément Lesaege, William George, and Federico Ast March 2020;C Lesaege ;2020 kleros.io;;"… These include applications such as curated lists, escrows, and oracles, see Section 6. “Arbitrable”

contracts designate an “arbitrator” contract such as that … courts with a particularly low session time

(for example, a court solving disputes in a web to blockchain oracle) this random …";Autres articles;;[PDF] kleros.io;https://kleros.io/static/yellowpaper_en-28d8e155664f3f21578958a482f33bd1.pdf;;;https://scholar.google.ch/scholar?start=920&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098835-266;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Blockchain-based database in an IoT environment: challenges, opportunities, and analysis;L Tseng, X Yao, S Otoum, M Aloqaily, Y Jararweh ; Cluster Computing, 2020  Springer;;"… While Bitcoin [1] is focusing on using Blockchain for cryptocurrency, Blockchain can be better

thought of as … Auditability: Since all participants hold a replica of the Blockchain (ie, a local chain),

they have … Following [6, 7], the PoW mechanism is modeled as an oracle in this paper …";Cité 22 fois;Les 2 versions;null;;;;https://scholar.google.ch/scholar?start=810&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098857-316;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;GRANDPA: a Byzantine finality gadget;A Stewart, E Kokoris;Kogia  arXiv preprint arXiv:2007.01560, 2020  arxiv.org;;"… Page 2. a finality gadget. Separating the liveness of the consensus protocol from the

finality of the blocks. This approach has three concrete benefits for the overlying blockchain

protocol … 2.1 Byzantine Agreement with a Consistency Oracle …";Cité 6 fois;Les 2 versions;[PDF] arxiv.org;https://arxiv.org/pdf/2007.01560;"
ar
X

iv
:2

00
7.

01
56

0v
1 

 [
cs

.D
C

] 
 3

 J
ul

 2
02

0

GRANDPA: a Byzantine Finality Gadget

Alistair Stewart

stewart.al@gmail.com

Eleftherios Kokoris-Kogia

eleftherios.kokoriskogias@epfl.ch

June 30, 2020

Abstract

Classic Byzantine fault-tolerant consensus protocols forfeit liveness in the face of asynchrony in order
to preserve safety, whereas most deployed blockchain protocols forfeit safety in order to remain live. In
this work, we achieve the best of both worlds by proposing a novel abstractions called the finality gadget.
A finality gadget allows for transactions to always optimistically commit but informs the clients that these
transactions might be unsafe. As a result, a blockchain can execute transactions optimistically and only
commit them after they have been sufficiently and provably audited. In this work, we formally model the
finality gadget abstraction, prove that it is impossible to solve it deterministically in full asynchrony (even
though it is stronger than consensus) and provide a partially synchronous protocol which is currently
securing a major blockchain. This way we show that the protocol designer can decouple safety and
liveness in order to speed up recovery from failures. We believe that there can be other types of finality
gadgets that provide weaker safety (e.g., probabilistic) in order to gain more efficiency and this can
depend on the probability that the network is not in synchrony.

1 Introduction

Bitcoin [14] and its descendants [17, 16] are cryptocurrencies that provide secure automated value exchange
without the need of a central managing authority. Instead a decentralized consensus protocol maintains a
distributed public ledger known as the blockchain. To be able to rely on public ledger one needs to know
that it has reached consensus on a certain block, i.e., when a block will not be reverted anymore, which we
refer to as reaching finality. One of the challenges of Nakomoto-like consensus protocols is that they only
satisfy eventual consensus, which only guarantees that an ever growing prefix of the chain will be agreed
upon by all participants forever onward. The eventual consensus process generally takes tens of minutes and
it only gives probabilistic guarantees (for a certain block number at a certain point in time).

Unfortunately these guarantees only hold if the underlying network is well-connected and the client is able
to find an uncensored source of information, two assumptions that do not hold in adversarial environments [3,
9, 10]. The underlying problem which enables these attacks is that first generation blockchain protocols do
not consider finality (i.e., when will a block never be reverted) as a first class property, prioritising liveness
instead.

An alternative to probabilistic finality is having provable finality where anyone can be convinced of the
finality of a block, regardless of being a consensus participants or actively following the network.New gen-
eration protocols [11, 6, 15] propose the complete opposite. They propose every block to be finalized one
by one and to forfeit liveness when finality is not readily achievable. This gives provable finality immedi-
ately.Unfortunately, these types of protocols inherit the shortcoming of classic consensus protocol on losing
performance when many nodes are required to participate. Hence, they need to put a limit on the number
of consensus participants which might lead to centralization.

In this work we show the that the middle ground also merits exploration. The approach that we will take
is similar to the approach that Ethereum plans to take with Casper the Friendly Finality Gadget (Casper
FFG)[2]. We introduces and formalize the idea of lazy finality which is encapsulated in the abstraction of

1

http://arxiv.org/abs/2007.01560v1


a finality gadget. Separating the liveness of the consensus protocol from the finality of the blocks. This
approach has three concrete benefits for the overlying blockchain protocol.

A first benefit is that since consensus is not tied to liveness of the chain we can have optimistic execution.
As a result, the chain can grow before it is certain that blocks are valid. Later on, we can finalize blocks
when we are sure they are correct i.e., all verification information is available. A second benefit is that we
can make some (unsafe) progress when the network is unstable. This enables a fast recovery process when
the network heals. Similarly, we can make progress in chain growth even when finlzation is slow, e.g., when
we have many particiapnts thus promoting decentenralization.

Third, a finality gadget can be deployed gradually and light clients can choose to consult it or follow the
longest chain rule and ignore it, enabling light client heterogeneity. The light client that trust the gadget
do not need to have the full chain or actively listen to the network. This can in turn enable scalability [4]
in an ecosystem of multiple chains (weather sharding [12, 1, 2] or heterogeneous [18]), where no single party
receives or stores all the data in the system.

In short, we fromalize the abstraction of a finality gadget that runs along any block production mechanism
(e.g., Nakamoto consensus) providing provable finality guarantees. We show that it is impossible to satisfy its
properties with a deterministic asynchronous protocol. To circumvent this impossibility result, we introduce
the GRANDPA finality gadget that works in a partially synchronous network model, in the presence of up
to 1/3 Byzantine actors.

The combination of GRANDPA with a classic block production mechanism like GHOST [13] results in the
existing deployment of the polkadot network 1 which provides fast finality under good network conditions
and protects the clients without compromising the liveness when under attack. The implementation of
GRANDPA is available on github 2.

In summary we make the following contributions:

• Introduce the idea of lazy finality and instantiate it through a finality gadget abstraction

• Prove that BFG is impossible in asynchrony and present GRANDPA

2 Model, Definitions, and Impossibilities

We want to formalise the notion of finality gadget to be a sub-protocol that can be deployed along any protocol
with eventual consensus and probabilistic finality and enhancing such protocol with provable finality. To
achieve this, we need to incorporate into the classic definition of Byzantine agreement the fact that we
additionally have access to a protocol that would achieve eventual consensus if we did not affect it.

2.1 Byzantine Agreement with a Consistency Oracle

Consider a typical definition of a multi-values Byzantine agreement: We have a set of participants V , the
majority of whom obey the protocol, but a constant fraction may be Byzantine, meaning they behave
arbitrarily, e.g. provide false or inconsistent information or randomly go offline when they ought to be
online.

Definition 2.1. A protocol for multi-valued Byzantine agreement has a set of values S and a set of voters
V , a constant fraction of which may be Byzantine, for which each voter v ∈ V starts with an initial value
sv ∈ S and, in the end, decides a final value fv ∈ S such that the following holds:

• Agreement: All honest voters decide the same value for fv

• Termination: All honest voters eventually decide a value

• Validity: If all honest voters have the same initial value, then they all decide that value

1https://polkadot.network
2See https://github.com/paritytech/finality-grandpa and https://github.com/paritytech/substrate/tree/master/client/finality-grandpa

2

https://polkadot.network
https://github.com/paritytech/finality-grandpa
https://github.com/paritytech/substrate/tree/master/client/finality-grandpa


We can change this definition to assume that instead of having an initial value, all voters have access to
an external protocol, an oracle for values, that achieves eventual consensus in that it returns the same value
to all voters when called after some unknown time.

Definition 2.2. We say an oracle A in a protocol is eventually consistent if it returns the same value to all
participants after some unspecified time.

Definition 2.3. A protocol for the multi-valued Byzantine finality gadget problem has a set of values S, a
set of voters V , a constant fraction of which may be Byzantine, for which each voter v ∈ V has access to an
eventually consistent oracle A and, in the end, each voter decides a final value fv ∈ S such that the following
holds:

• Agreement: All honest voters decide the same value for fv

• Termination: All honest voters eventually decide a value

• Validity: All honest voters decide a value that A returned to some honest voter sometime.

Impossibility of Deterministic Agreement with an Oracle. For the binary case, i.e. when |S| = 2,
the Byzantine finality gadget problem is reducible to Byzantine agreement. This does not hold for |S| > 2,
because the definition of validity is stronger in our protocol. Note that it is impossible for multi-valued
Byzantine agreement to make the validity condition require that we decide an initial value of some honest
voter and tolerate more than a 1/|S| fraction of faults, since we may have a 1/|S| fraction of voters reporting
each initial value and Byzantine voters can act honestly enough not to be detectable. For finality gadgets,
this stronger validity condition is possible. A natural question is then weather the celebrated FLP [8]
impossibility holds for our stronger requirements. Next, we show that an asynchronous, deterministic binary
finality gadget is impossible, even with one fault. This means that the extra information voters have here,
that A will eventually agree for all voters, is not enough to make this possible.

Proof: The asynchronous binary fault tolerant agreement problem is as follows:
We have number of voters which each have an initial vi in {0, 1}
We may have one or more faulty nodes, which here means going offline at some point. Nodes have

asynchronous communication - so any message arrives but we have no guarantee when it will. The goal is
to have all non-faulty nodes output the same v, which must be 0 if all inputs vi are 0 and 1 if all are 1.

Fischer, Lynch and Paterson[8] showed that this is impossible if there is one faulty node.
The binary fault-safe finality gadget problem is similar, except now there is an oracle A that any node

can call at any time with the following properties:
either A always outputs x in {0, 1} to all nodes at all times or else there is an x in {0, 1} and for each

node i, there is a Ti such that when i calls A before Ti. it gives x but if it calls A after Ti, it returns not x .
and we want that if A never switches, then all non-faulty nodes output x. If A does switch then all

non-faulty nodes should output the same thing, but it can be 0 or 1.
Then this is also impossible, even for one faulty node, which just goes offline. Note that this generalises

Byzantine agreement, since if we could each node i could call A once at the start and use the output as vi.
(For the multi-valued case, we will define the problem so that this reduction does not hold.)

Proof sketch. We follow the notation of [8] and assume for a contradiction that we use a correct protocol.
Let r be a run of the protocol where A gives 0 all the time. Then by correctness r decides 0. Now we consider
what can happen when A switches to 1 after each configuration in r. If it switches to 1 at the start, then
the protocol decides 1. If we switch to 1 when all node have already decided 0, then we decide 0.

We claim that some configuration in the run r, where there are two runs from it where A is always 1
that decide 0 and 1. We call such states 1-bivalent. To see this, assume for a contradiction that r contains
no such configurations. Then there are successive configurations C,C′ such that if A return 1 in the future
from C then we always decide 0 but from C′, we always decide 1. Let events be (p,m, x) where node

3



(processor/voter) p receives message m (which may be null) and executes some code where any calls to A
return x in {0, 1}, then sends some messages. Then there is some event (p,m, 0) that when applied to C
gives C′. Now suppose that p goes offline at C, then if A always returns 1 afterwards, then we still decide 1.
Thus there is a run r′ that starts at C where p takes no steps, A always returns 1 and all other nodes still
output 1. But since p takes no steps in r′, we can apply r′ after (p,m, 0) and so we have that C′ has a run
where A always returns 1 but decides 1, which is a contradiction.

Now let C be a 1-bivalent configuration. We can follow the FLP proof to show that there is a run from
C for which A always returns 1, all messages are delivered but all configurations are 1-bivalent and so the
protocol never decides. This completes the proof by contradiction that there is no correct protocol.

2.2 Definition of a Finality Gadget

In this section we show how to extend the one-shot agreement to agreeing on a chain of blocks. One
difficulty in formalising the problem is that the block production mechanism cannot be entirely separate
from the finality gadget. In order to finalise new blocks, we must first build on the chain we have already
finalised. So at a minimum, the block production mechanism needs to recognise which blocks the finality
gadget has finalised. We will also allow the block production mechanism to interact with the state of the
finality gadget in other ways.

We want the finality gadget to work with the most general block production mechanisms as possible.
Thus we need a condition that combines the property of eventual consensus and this requirement to build
on the last finalised block, but is otherwise not too restrictive. We assume a kind of conditional eventual
consensus. If we keep building on our last finalised block B and don’t finalise any new blocks, then eventually
we have consensus on a longer chain than just B, which the finality gadget can use to finalise another block.
We also want a protocol that does not terminate, but instead keeps on finalising more blocks.

We assume that there is a block production protocol P that runs at the same time as the finality gadget
protocol G. Actors who are participants in both protocols may behave differently in P depending on what
happened in G. However in the reverse direction, the only way that an honest voter v’s behaviour in G is
affected by P is through a voting rule, a function A(v, sv, B) that depends on v and its state sv and takes a
block B and returns a block B′ at the head of a chain including B.

We say that the system G, P , and A achieves conditional eventual consensus, if G has finalised a block
B, then eventually, either G will finalise some descendant of B or else all the chains with head Av,sv (B) for
all voters v at all future states sv will contain the same descendant B′ of B.

Definition 2.4. Let F be a protocol with a set of voters V , a constant fraction of which may be Byzantine.
We say that F solves blockchain Byzantine finality gadget problem if for every block production protocol P
and voting rule A we have the following

• Safety: All honest voters finalise the same block at each block number.

• Liveness: If the system F,G,A achieves conditional eventual consensus, then all honest voters keep
finalising blocks.

• Validity: If an honest voter finalises a block B then that block was seen in the best chain observed by
some honest voter containing some previously finalised ancestor of B,

As an example, we could assume F uses proof of work to build on the longest chain and includes the last
block G finalised. Then we take A(v, sv, B) as being the longest chain which includes B and which v sees in
state sv. It is well-known [14] that longest chain with proof of work achieves eventual consensus under the
right assumptions and similar arguments show that in this case we have conditional eventual consensus. As
long as we do not change the chain we are building on by finalising another block, we will eventually agree
on some prefix longer than the last finalised block. Thus, any finality gadget that satisfies Definition 2.4
will work in this system so that all honest voters finalise an increasingly long common chain. Thanks to the
abstraction above, we can switch F for one of many possible alternative consensus algorithms and G will
still work.

4



2.3 Preliminaries

Network model : We will be using the partially synchronous network model introduced by [7] and in
particular the gossip network variant used in [5]. We assume that any message sent or received by an honest
participant reaches all honest participants within time T , but possibly only after some Global Synchronisation
Time GST. Concretely, any message sent or received by some honest participant at time t is received by all
honest participants by time GST + T at the latest.

Voters: For each voting step, there is a set of n voters. We will frequently need to assume that for each
such step, at most f < n/3 voters are Byzantine. We need n− f of voters to agree on finality. Whether or
not block producers ever vote, they will need to be participants who track the state of the protocol.

Votes: A vote is a block hash, together with some metadata such as round number and the type of vote,
such as prevote or precommit, all signed with a voter’s private key.

Rounds: Each participant has their own idea of what is the current round number. Every prevote and
precommit has an associated round number. Honest voters only vote once (for each type of vote) in each
round and do not vote in earlier rounds after later ones. Participants need to keep track of which block they
see as currently being the latest finalised block and an estimate of which block could have been finalised in
the last round.

For block B, we write chain(B) for the chain whose head is B. The block number, n(B) of a block B
is the length of chain(B). For blocks B′ and B, we say B is later than B′ if it has a higher block number.
We write B > B′ or that B is descendant of B′ for B, B′ appearing in the same blockchain with B′ later
i.e. B′ ∈ chain(B) with n(B) > n(B′). B ≥ B′ and B ≤ B′ are similar except allowing B = B′. We write
B ∼ B′ or B and B′ are on the same chain if B < B′, B = B′ or B > B′; and B ≁ B′ or B and B′ are not
on the same chain if there is no such chain.

Blocks are ordered as a tree with the genesis block as root. So any two blocks have a common ancestor
but two blocks not on the same chain do not have a common descendant. A vote v for a block B by a voter
V is a message signed by V containing the blockhash of B and meta-information like the round numbers
and the type of vote.

A voter equivocates in a set of votes S if they have cast multiple different votes in S. We call a set S
of votes safe if the number of voters who equivocate in S is at most f . We say that S has a supermajority
for a block B if the set of voters who either have a vote for blocks ≥ B or equivocate in S has size at least
(n+f+1)/2. We count equivocations as votes for everything so that observing a vote is monotonic, meaning
that if S ⊂ T then if S has a supermajority for B so does T , while being able to ignore yet more equivocating
votes from an equivocating voter.

For our finality gadget (GRANDPA) we use the ghost [13] eventual consensus algorithm as F . The
2/3-GHOST function g(S) takes a set S of votes and returns the block B with highest block number such
that S has a supermajority for B. If there is no such block, then it returns ‘nil‘. Note that, if S is safe,
then we can compute g(S) by starting at the genesis block and iteratively looking for a child of our current
block with a supermajority, which must be unique if it exists. Thus we have:

Lemma 2.5. Let T be a safe set of votes. Then

1. The above definition uniquely defines g(T )

2. If S ⊆ T has g(S) 6= nil, then g(S) ≤ g(T ).

3. If Si ⊆ T for 1 ≤ i ≤ n then all non-nil g(Si) are on a single chain with head g(T ).

Note that we can easily update g(S) to g(S∪{v}), by checking if any child of g(S) now has a supermajority.
The third rule tells us that even if participants see different subsets of the votes cast in a given voting round,
this rule may give them different blocks but all such blocks are in the same chain under this assumption.

5



Next, we define a notion of possibility to have a supermajority which says that if the set of all votes in
a vote T is safe and some participant observes a subset S ⊆ T that has a supermajority for a block B then
all participants who see some other subset S′ ⊆ T still see that it is possible for S to have a supermajority
for B. We need a definition that extends to unsafe sets. We say that it is impossible for a set S to have a
supermajority for B if at least (n+f+1)/2 voters either vote for a block 6≥ B or equivocate in S. Otherwise
it is possible for S to have a supermajority for B.

Note that if S is safe, it is possible for S to have a supermajority for B if and only if there is a safe T ⊇ S
that has a supermajority for B, which can be constructed by adding a vote from B for all voters without
votes in S and enough voters who already have votes in S to bring the number of equivocations up to f .

We say that it is impossible for any child of B to have a supermajority in S if S has votes from at least
2f + 1 voters and it is impossible for S to have a supermajority for each child of B appearing on the chain
of any vote in S. Again, provided S is safe, this holds if and only if for any possible child of B, there is no
safe T ⊆ S that has a supermajority for that child.

Lemma 2.6. (i) If B′ ≥ B and it is impossible for S to have a supermajority for B, then it is impossible
for S to have a supermajority for B′.

(ii) If S ⊆ T and it is impossible for S to have a supermajority for B, then it is impossible for T to have
a supermajority for B.

(iii) If g(S) exists and B ≁ g(S) then it is impossible for S to have a supermajority for B.

3 Finality Gadget Protocols

In order to find a solution to the finality gadget protocol we look in consensus protocols that solve the
stronger problem as described in the previous section. The key idea for our solution is to inherit the safety
properties of a consensus protocol, but use the underlying blockchain as the driving force of liveness. This
results in a protocol which does not stop when for example the network is split. Instead, only the finalization
stops, but the blocks keep getting created and propagated to everyone. This means that when the conditions
are safe again, the finality gadget only needs to finalize the head of the chain3, instead of having to transmit
and run consensus on every block.

3.1 The GRANDPA Protocol

In this section, we give our solution to the Byzantine finality gadget problem, GRANDPA. Our finality gadget
works the partially synchronous setting, we also provide a fully asynchronous solution in Appendix ??.

GRANDPA works in rounds, each round has a set of 3f + 1 eligible voters, 2f + 1 of which are assumed
honest. Furthermore, we assume that each round has a participant designated as primary and all participants
agree on the voter sets and primary. We will can either choose the primary pseudorandomly from or rotate
through the voter set. On a high-level, each round consists of a double-echo protocol after which every party
waits in order to detect whether we can finalize a block in this round (this block does not need to be the
immediate ancestor of the last finalized block, it might be far ahead from the last finalized block). If the
round is unsuccessful, the parties simply move on to the next round with a new primary. When a good
primary is selected, the oracle is consistent (returns the same value to all honest parties), and the network is
in synchrony (after GST), then a new block will be finalized and it will transitively finalized all its ancestors.

More specifically, we let Vr,v and Cr,v be the sets of prevotes and precommits respectively received by v
from round r at the current time.

We define Er,v to be v’s estimate of what might have been finalised in round r, given by the last block
in the chain with head g(Vr,v) for which it is possible for Cr,r to have a supermajority. Next we define a
condition which will allow us to safely conclude that Er,v ≥ B for all B that might be finalised in round r:

3Which the oracle will return quickly to a supermajority of miners.

6



If either Er,v < g(Vr,v) or it is impossible for Cr,v to have a supermajority for any children of g(Vr,v), then
we say that v sees that round r is completable. E0,v is the genesis block, assuming we start at r = 1.

In other words, a round r is completable when our estimate chain Er,v contains everything that could
have been finalised in round r, which makes it possible to begin the next round r + 1.

We have a time bound T that after GST suffices for all honest participants to communicate with each
other. Inside a round, the properties both of Er,v having a supermajority, meaning Er,v < g(Vr,v), as well
as of it being impossible to have a supermajority for some given block are monotone, so the property of
being completable is monotone as well. We therefore expect that, if anyone sees a round is completable,
then everyone will see this within time T . Leaving a gap of 2T between steps is then enough to ensure that
every party receives all honest votes before continuing.

Protocol Description. In round r an honest participant v does the following:

1. A voter v can start round r > 1 when round r−1 is completable and v has cast votes in all previous
rounds where they are a voter. Let tr,v be the time v starts round r.

2. At time tr,v, if v is the primary of this round and has not finalised Er−1,v then they broadcast
Er−1,v. If they have finalised it, they can broadcast Er−1,v anyway (but do not need to).

3. If v is a voter for the prevote of round r, v waits until either it is at least time tr,v + 2T or round r
is completable, then broadcasts a prevote. They prevote for the head of the best chain containing
Er−1,v unless we received a block B from the primary and g(Vr−1,v) ≥ B > Er−1,v, in which case
they use the best chain containing B instead.

4. If v is a voter for the precommit step in round r, then they wait until g(Vr,v) ≥ Er−1,v and one of
the following conditions holds

(i) it is at least time tr,v + 4T ,

(ii) round r is completable or

(iii) it is impossible for Vr,v to have a supermajority for any child of g(Vr,v),

and then broadcasts a precommit for g(Vr,v) ( (iii) is optional, we can get away with just (i) and
(ii)).

Note that Cr,v and Vr,v may change with time and also that Er−1,v, which is a function of Vr−1,v and
Cr−1,v, can also change with time if v sees more votes from the previous round.

Finalisation. If, for some round r, at any point after the precommit step of round r, we have that
B = g(Cr,v) is later than our last finalised block and Vr,v has a supermajority, then we finalise B. We may
also send a commit message for B that consists of B and a set of precommits for blocks ≥ B (ideally for B
itself if possible see ”Alternatives to the last blockhash” below).

To avoid spam, we only send commit messages for B if we have not receive any valid commit messages
for B and its descendants and we wait some time chosen uniformly at random from [0, 1] seconds or so before
broadcasting. If we receive a valid commit message for B for round r, then it contains enough precommits
to finalise B itself if we haven’t already done so, so we’ll finalise B as long as we are past the precommit
step of round r.

4 Analysis

To analyse the performance of our finality gadget, we will need versions of our properties that appropriately
depend on time:

7



• Fast termination: If the last finalised block has number n and, until another block is finalised, the
best chain observed by all participants will include the same block with block number n+1, then a block
with number n+ 1 will be finalised within time T .

• Recent validity: If an honest voter finalises a block B then that block was seen in the best chain
observed by some honest voter containing some previously finalised ancestor of B more recently than
time T ago.

Intuitively, fast termination implies that we finalise blocks fast as long as the block production mechanism
achieves consensus fast whereas recent validity bounds the cost of starting to agree on something the block
production mechanism’s consensus later decides is not the best. In this case, we may waste time building
on a chain that is never finalised so it is important to bound how long we do that.

These properties will typically only hold with high probability. In the asynchronous case, we would need
to measure time in rounds of the protocol rather than seconds to make sense of these properties. We are
also interested in being able to remove and punish Byzantine voters, for which we will need:

• Accountable Safety: If blocks on different chains are finalised, then we can identify at least f + 1
Byzantine voters.

4.1 Accountable Safety

The first thing we want to show is asynchronous safety, assuming we have at most f Byzantine voters. This
follows from the property that if v sees round r as completable then any block B with Er,v 6≤ B has that
it is impossible for one of Cr,v or Vr,v to have a supermajority for B and so B was not finalised in round
r. This ensures that all honest prevotes and precommits in round r + 1 are for chains that include any
blocks that could have been finalised in round r. With an induction, this is what ensures that we cannot
finalise blocks on different chains. To show accountable safety, we need to turn this proof around to show
the contrapositive, when we finalise different blocks , then there are f +1 Byzantine voters. If we make this
proof constructive, then it gives us a challenge procedure, that can assign blame to such voters.

Theorem 4.1. If the protocol finalises any two blocks B,B′ for which valid commit messages were sent,
but which do not lie on the same chain, then there are at least f + 1 Byzantine voters who all voted in a
particular vote. Furthermore, there is a synchronous procedure to find some such set X of f + 1 Byzantine
voters.

The challenge procedure works as follows: If B and B′ are committed in the same round, then the union
of their precommits must contain at least f equivocations, so we are done. Otherwise, we may assume by
symmetry that B was committed in round r and B′ in round r′ > r. There are at least n − f voters who
precommitted ≥ B′ or equivocated in round r in their commit messages, so we ask those who precommitted
≥ B′ why they did so.

Starting with r′′ = r′, we ask queries of the following form:

• Why was Er′′−1 6≥ B when you prevoted for or precommitted to B′′ 6≥ B in round r′′ > r?

Any honest voter should be able to respond to this, as is shown in Lemma 4.2 below.
The response is of the following form:

• A either a set S of prevotes for round r′′ − 1, or else a set S of precommits for round r′′ − 1, in either
case such that it is impossible for S to have a supermajority for B.

Any honest voter should respond. In particular, if no voter responds, then we consider all voters how
should have responded but didn’t as Byzantine and we return this set of voters, along with any equivocators,
which will be at least n − f voters total. If any do respond, then if r′′ > r + 1, we can ask the same query
for at least n − f voters in round r′′ − 1. We note however that if any voters do respond then we will not
punish non-responders.

8



If we ask such queries for a vote in all rounds between r′′ = r′ and r′′ = r + 1 and get valid responses,
since some voter responds when r′′ = r + 1, then we have either a set S of prevotes or precommits in round
r that show it is impossible for S to have a supermajority for B in round r.

If S is a set of precommits, then if we take the union of S and the set of precommits in the commit
message for B, then the resulting set of precommits for round r has a supermajority for B and it is impossible
for it to have a supermajority for B. This is possible if the set is not safe and so there must be at least f +1
voters who equivocate an so are Byzantine.

If we get a set S of prevotes for round r that does not have a supermajority for B, then we need to ask
a query of the form

• Whi";"""date"",""2020-07-06T00:56:42Z""
""pdf:PDFVersion"",""1.4""
""pdf:docinfo:title"",""GRANDPA: a blockchain finality gadget""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.4""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""GRANDPA: a blockchain finality gadget""
""xmp:CreateDate"",""2020-07-05T20:56:42Z""
""modified"",""2020-07-06T00:56:42Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""xmp:ModifyDate"",""2020-07-05T20:56:42Z""
""pdf:docinfo:creator"",""Alistair Stewart""
""meta:author"",""""
""meta:creation-date"",""2020-07-06T00:56:42Z""
""created"",""2020-07-06T00:56:42Z""
""xmp:About"",""uuid:1b0e7a82-f740-11f5-0000-fa3ba62726aa""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-07-06T00:56:42Z""
""resourceName"",""2007.01560""
""Author"",""""
""producer"",""dvips + GPL Ghostscript GIT PRERELEASE 9.22""
""pdf:docinfo:producer"",""dvips + GPL Ghostscript GIT PRERELEASE 9.22""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""1"",""1"",""0"",""3"",""5"",""1"",""2"",""1"",""0""
""Keywords"",""blockchain finality gadget, consensus, Polkadot, Substrate""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2020-07-06T00:56:42Z""
""Last-Modified"",""2020-07-06T00:56:42Z""
""dcterms:modified"",""2020-07-06T00:56:42Z""
""title"",""GRANDPA: a blockchain finality gadget""
""xmpMM:DocumentID"",""uuid:1b0e7a82-f740-11f5-0000-fa3ba62726aa""
""Last-Save-Date"",""2020-07-06T00:56:42Z""
""pdf:docinfo:keywords"",""blockchain finality gadget, consensus, Polkadot, Substrate""
""pdf:docinfo:modified"",""2020-07-06T00:56:42Z""
""meta:save-date"",""2020-07-06T00:56:42Z""
""Content-Length"",""224316""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""blockchain finality gadget, consensus, Polkadot, Substrate""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""13""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""3160"",""3155"",""3446"",""3569"",""3131"",""3307"",""2659"",""3087"",""3160"",""3411"",""3119"",""3110"",""3149""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""meta:keyword"",""blockchain finality gadget, consensus, Polkadot, Substrate""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-07-06T00:56:42Z""
";https://scholar.google.ch/scholar?start=860&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098729-22;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Attacking the DeFi ecosystem with flash loans for fun and profit;K Qin, L Zhou, B Livshits, A Gervais ; arXiv preprint arXiv:2003.03810, 2020  arxiv.org;;"… a pump and arbitrage from the 15th of February 2020 and an oracle manipulation from the … At

its core, a blockchain is a chain of blocks [8], [36], extended by … A. Decentralized Finance (DeFi)

Decentralized Finance is a conglomerate of financial cryptocurrency-related protocols …";Cité 21 fois;Les 3 versions;[PDF] arxiv.org;https://arxiv.org/pdf/2003.03810;"
Attacking the DeFi Ecosystem with Flash Loans
for Fun and Profit

Kaihua Qin, Liyi Zhou, Benjamin Livshits, and Arthur Gervais

Imperial College London, United Kingdom
{kaihua.qin,liyi.zhou,b.livshits,a.gervais}@imperial.ac.uk

Abstract. Credit allows a lender to loan out surplus capital to a bor-
rower. In the traditional economy, credit bears the risk that the bor-
rower may default on its debt, the lender hence requires upfront collat-
eral from the borrower, plus interest fee payments. Due to the atomicity
of blockchain transactions, lenders can offer flash loans, i.e., loans that
are only valid within one transaction and must be repaid by the end of
that transaction. This concept has lead to a number of interesting attack
possibilities, some of which were exploited in February 2020.
This paper is the first to explore the implication of transaction atomicity
and flash loans for the nascent decentralized finance (DeFi) ecosystem.
We show quantitatively how transaction atomicity increases the arbitrage
revenue. We moreover analyze two existing attacks with ROIs beyond
500k%. We formulate finding the attack parameters as an optimization
problem over the state of the underlying Ethereum blockchain and the
state of the DeFi ecosystem. We show how malicious adversaries can
efficiently maximize an attack profit and hence damage the DeFi ecosys-
tem further. Specifically, we present how two previously executed attacks
can be “boosted” to result in a profit of 829.5k USD and 1.1M USD,
respectively, which is a boost of 2.37× and 1.73×, respectively.

1 Introduction

A central component of our economy is credit: to foster economic growth, market
participants can borrow and lend assets to each other. If credit creates new
and sustainable value, it can be perceived as a positive force. Abuse of credit,
however, necessarily entails negative future consequences. Excessive debt can
lead to a debt default — i.e., a borrower is no longer capable to repay the loan
plus interest payment. This leads us to the following intriguing question: What
if it were possible to offer credit without bearing the risk that the borrower does
not pay back the debt? Such a concept appears impractical in the traditional
financial world. No matter how small the borrowed amount, and how short the
loan term, the risk of the borrower defaulting remains. If one were absolutely
certain that a debt would be repaid, one could offer loans of massive volume –
or lend to individuals independently of demographics and geographic location,
effectively providing capital to rich and poor alike.

Given the peculiarities of blockchain-based smart contracts, flash loans emerged.
Blockchain-based smart contracts allow to programmatically enforce the atomic

ar
X

iv
:2

00
3.

03
81

0v
4 

 [
cs

.C
R

] 
 2

0 
M

ar
 2

02
1



2 K. Qin et al.

execution of a transaction. A flash loan is a loan that is only valid within one
atomic blockchain transaction. Flash loans fail if the borrower does not repay
its debt before the end of the transaction borrowing the loan. That is because
a blockchain transaction can be reverted during its execution if the condition
of repayment is not satisfied. Flash loans yield three novel properties, absent in
traditional finance:

– No debt default risk: A lender offering a flash loan bears no risk that the
borrower defaults on its debt1. Because a transaction and its instructions
must be executed atomically, a flash loan is not granted if the transaction
fails due to a debt default.

– No need for collateral: Because the lender is guaranteed to be paid back,
the lender can issue credit without upfront collateral from the borrower: a
flash loan is non-collateralized.

– Loan size: Flash loans can be taken from public smart contract-governed
liquidity pools. Any borrower can borrow the entire pool at any point in
time. As of September 2020, the largest flash loan pool Aave [13] offers in
excess of 1B USD [1].

To the best of our knowledge, this is the first paper that investigates flash
loans. This paper makes the following contributions:

– Flash loan usage analysis. We provide a comprehensive overview of how
and where the technique of flash loans can and is utilized. At the time of
writing, flash loan pool sizes have reached more than 1B USD.

– Post mortem of existing attacks. We meticulously dissect two events
where talented traders realized a profit of each about 350k USD and 600k
USD with two independent flash loans: a pump and arbitrage from the 15th
of February 2020 and an oracle manipulation from the 18th of February 2020.

– Attack parameter optimization framework. Given the interplay of six
DeFi systems, covering exchanges, credit/lending, and margin trading, we
provide a framework to quantify the parameters that yield the maximum
revenue an adversary can achieve, given a specific trading attack strategy.
We show that an adversary can maximize the attack profit efficiently (in less
than 13ms) due to the atomic transaction property.

– Quantifying opportunity loss. We show how the presented flash loan at-
tackers have forgone the opportunity to realize a profit exceeding 829.5k USD
and 1.1M USD, respectively. We realize this by finding the optimal adver-
sarial parameters the trader should have employed, using a parametrized
optimizer. We experimentally validate the opportunity loss on a locally de-
ployed blockchain mirroring the attacks’ respective blockchain state.

– Impact of transaction atomicity on arbitrage. We show quantitatively
how atomicity reduces the risk of revenue from arbitrage. Specifically, by
analyzing 6.4M transactions, we find that the expected arbitrage reward de-
creases by 123.49Âą1375.32 USD and 1.77Âą10.59 USD for the DAI/ETH and

1 Besides the risk of smart contract vulnerabilities.



Attacking the DeFi Ecosystem with Flash Loans for Fun and Profit 3

MKR/ETH markets respectively when the number of intermediary transac-
tions reaches 5, 000.

Paper organization: The remainder of the paper is organized as follows. Sec-
tion 2 elaborates on the DeFi background. Section 3 dissects two known flash
loan attacks. Section 4 proposes a framework to optimize the attack revenues
and Section 5 evaluates the framework on the two analyzed attacks. Section 6
analyses the implications of the atomic transaction property. Section 7 provides
a discussion. We conclude the paper in Section 8.

2 Background

Decentralized ledgers, such as Bitcoin [44], enable the performance of trans-
actions among a peer-to-peer network. At its core, a blockchain is a chain
of blocks [17,44], extended by miners crafting new blocks that contain trans-
actions. Smart contracts [49] allow the execution of complicated transactions,
which forms the foundation of decentralized finance, a conglomerate of financial
cryptocurrency-related protocols. These protocols for instance allow to lend and
borrow assets [39,4], exchange [24,11], margin trade [24,3], short and long [3],
and allow to create derivative assets [4]. At the time of writing, the DeFi space
accounts for over 8B USD in smart contract locked capital among different
providers. The majority of the DeFi platforms operate on the Ethereum blockchain,
governed by the Ethereum Virtual Machine (EVM), where the trading rules are
governed by the underlying smart contracts. A decentralized exchange is typi-
cally referred to as DEX. We refer to the on-chain DeFi actors as traders and
distinguish among the two types of traders:
Liquidity Provider: a trader with surplus capital may choose to offer this
capital to other traders, e.g., as collateral within a DEX or lending platform.
Liquidity Taker: a trader which is servicing liquidity provider with fees in
exchange for accessing the available capital.

2.1 DeFi Platforms

We briefly summarize relevant DeFi platforms for this work.
Automated market maker (AMM) DEX: While many exchanges follow the
limit order book design [40,35,34], an alternative exchange design is to collect
funds within a liquidity pool, e.g., two pools for an AMM asset pair X/Y [11,34].
The state (or depth) of an AMM market X/Y is defined as (x, y), where x rep-
resents the amount of asset X and y the amount of asset Y in the liquidity pool.
Liquidity providers can deposit/withdraw in both assets X and Y to in/de-
crease liquidity. The simplest AMM mechanism is a constant product market
maker, which for an arbitrary asset pair X/Y , keeps the product x × y con-
stant during trades. When trading on an AMM exchange, there can be a differ-
ence between the expected price and the executed price, termed slippage [10].
Insufficient liquidity and other front-running trades can cause slippage on an



4 K. Qin et al.

AMM [52]. We assume that a constant product AMM ETH/WBTC market is
supplied with 10 ETH and 10 WBTC (i.e., the exchange rate is 1 ETH/WBTC).
A trader can purchase 5 WBTC with 10 ETH (cf. 10×10 = (10+10)× (10−5))
at an effective price of 2 ETH/WBTC. Hence, the slippage is 2−1

1 = 100%.
Margin trading: Trading on margin allows a trader to take under-collateralized
loans from the trading platform and trade with these borrowed assets to amplify
the profit (i.e., leverage). On-chain margin trading platforms remain in control
of the loaned asset (or the exchanged asset) and hence is able to liquidate when
the value of the trader’s collateral drops too low.
Credit and lending: With over 3B USD total locked value, credit represents
one of the most significant recent use-cases for blockchain based DeFi systems.
Due to the lack of legal enforcement when borrowers default, they are required
to provide between 125% [24] to 150% [39] collateral of an asset x to borrow
100% of another asset y (i.e., over-collateralization).

2.2 Reverting EVM State Transitions

The Ethereum blockchain is in essence a replicated state machine. To achieve a
state transition, one applies as input transactions that modify the EVM state
following rules encoded within deployed smart contracts. A smart contract can be
programmed with the logic of reverting a transaction if a particular condition is
not met during execution. The EVM state is only altered if a transaction executes
successfully, otherwise, the EVM state is reverted to the previous, non-modified
state.

Flash Loans. Flash loans are possible because the EVM allows the reversion of
state changes. A flash loan is only valid within a single transaction and relies
on the atomicity of blockchain (and, specifically, EVM) transactions within a
single block. Flash loans entail two important new financial properties: First, a
borrower does not need to provide upfront collateral to request a loan of any
size, up to the flash loan liquidity pool amount. Any borrower, willing to pay
the required transaction fees (which typically amounts to a few USD) is an
eligible borrower. Second, risk-free lending: If a borrower cannot pay back the
loan, the flash loan transaction fails. Ignoring smart contract and blockchain
vulnerabilities, the lender is hence not exposed to the risks of a debt default.

2.3 Flash Loan Usage in the Wild

To our knowledge, the Marble Protocol introduced the concept of flash loans [8].
Aave [13] is one of the first DeFi platforms to widely advertise flash loan capabil-
ities (although others, such as dYdX also allow the non-documented possibility
to borrow flash loans) since January 2020. At the time of writing, Aave charges
a constant 0.09% interest fee for flash loans and amassed a total liquidity be-
yond 1B USD [1]. In comparison, the total volume of U.S. corporation debt
reached 10.5T USD in August, 2020 [12].



Attacking the DeFi Ecosystem with Flash Loans for Fun and Profit 5

9200000 9600000 10000000 10400000 10800000
Block

$1

$10

$100

$1k

$10k

$100k

$1M

$10M

$100M

A
cc

um
ul

at
iv

e
F

la
sh

L
oa

n
A

m
ou

nt
(U

S
D

)

Token (price)

DAI ($1)

ETH ($350)

USDC ($1)

BAT ($0.2)

WBTC ($10,000)

ZRX ($0.3)

MKR ($500)

LINK ($10)

USDT ($1)

REP ($15)

KNC ($1.5)

LEND ($0.5)

sUSD ($1)

Fig. 1: Accumulative flash loan amounts of 13 cryptocurrencies on Aave. Note
that the y-axis is a logarithmic scale.

By gathering all blockchain event logs from Aave with a full archive Ethereum
node, we find 5, 616 flash loans issued from the Aave smart contract (cf. 0x398eC7
346DcD622eDc5ae82352F02bE94C62d119) between the 8th of January, 2020 and
the 20th of September, 2020. In Figure 1, we show the accumulative flash loan
amounts of 13 different loan currencies. Among them, DAI is the most popular
with the accumulative amount of 447.2M USD. We inspect and classify the Aave
flash loan transactions depending on which platforms the flash loans interact
with (cf. Figure 11 in Appendix A). We notice that most flash loans interact
with lending/exchange DeFi systems and that the flash loan’s transaction costs
(i.e., gas) appear significant (at times beyond 4M gas, compared to 21k gas for
regular Ether transfer). The dominating use cases are arbitrage and liquidation.
Further details are presented in Appendix A.
Flash Loan Arbitrage example: The value of an asset is typically determined
by the demand and supply of the market, across different exchanges. Due to a
lack of instantaneous synchronization among exchanges, the same asset can be
traded at slightly different prices on different exchanges. Arbitrage is the pro-
cess of exploiting price differences among exchanges for a financial gain [46].
In Figure 2, we present, as an example, the execution details of a flash loan
based arbitrage transaction on the 31st of July, 2020. The arbitrageur borrowed
a flash loan of 2.048M USDC, performed two exchanges, and realized a profit

1.	Flash	Loan	 M	USDC

4.	Repay	 M	USDC

2.	Exchange	 M	USDC
for	 M	DAI

	at	price	 	USDC/DAI		

3.	Exchange	 M	DAI
for	 M	USDC

	at	price	 	USDC/DAI		

dYdX arbitrageur

Curve
Y

Curve
sUSDProfit:	 k	USDC

Fig. 2: High-level executions of a flash loan based arbitrage transaction 0xf7498a2
546c3d70f49d83a2a5476fd9dcb6518100b2a731294d0d7b9f79f754a: (1) flash loan;
(2) exchange USDC for DAI in Curve Y pool; (3) exchange DAI for USDC
in Curve sUSDC pool; (4) repay. Note that Curve provides several on-chain
cryptocurrency markets, also known as pools.

https://etherscan.io/address/0x398eC7346DcD622eDc5ae82352F02bE94C62d119
https://etherscan.io/address/0x398eC7346DcD622eDc5ae82352F02bE94C62d119
https://etherscan.io/tx/0xf7498a2546c3d70f49d83a2a5476fd9dcb6518100b2a731294d0d7b9f79f754a
https://etherscan.io/tx/0xf7498a2546c3d70f49d83a2a5476fd9dcb6518100b2a731294d0d7b9f79f754a


6 K. Qin et al.

of 16.182k USDC (16.182k USD). This example highlights how given atomic
transactions, a trader can perform arbitrage on different on-chain markets, with-
out the risk that the prices in the DEX would intermediately change. Flash loans
moreover remove the currency volatility risk for arbitrageurs. In Section 6, we
quantify the implications of transaction atomicity on arbitrage risks.

Besides arbitrage, we noticed another two use cases for flash loans: (i) wash
trading (fraudulent inflation of trading volume), (ii) loan collateral swapping
(instant swapping from one collateral to another), and also a variation of flash
loan, (iii) flash minting (the momentarily token in- and decrease of an asset).
We elaborate further on these in Appendix B and provide real-world examples.

2.4 Related work

There is a growing body of work focusing on various forms of manipulation and
financially-driven attacks in cryptocurrency markets.
Crypto Manipulation: Front-running in cryptocurrencies has been extensively
studied [25,22,18,32,5,52]. Remarkably, Daian et al. [22] introduce the concept of
miner extractable value (MEV) and analyze comprehensively the exploitability of
ordering blockchain transactions. Our work focuses on flash loans, which qualify
as a potential MEV that miners could exploit. Gandal et al. [26] demonstrate
that the unprecedented spike in the USD-BTC exchange rate in late 2013 was
possibly caused by price manipulation. Recent papers focus on the phenomenon
of pump-and-dump for manipulating crypto coin prices [51,33,28].
Smart Contract Vulnerabilities: Several exploits have taken advantage of
smart contract vulnerabilities (e.g., the DAO exploit [9]). The most commonly
known smart contract vulnerabilities are re-entrancy, unhandled exceptions,
locked ether, transaction order dependency and integer overflow [37]. Many tools
and techniques, based on fuzzing [36,31,50], static analysis [48,19,47], symbolic
execution [37,43,45], and formal verification [16,14,27,29,30], emerged to detect
and prevent these vulnerabilities. In this work, we focus on DeFi economic se-
curity, which might not result from a single contract vulnerability and could
involve multiple DeFi platforms.

3 Flash Loan Post-Mortem

Flash loans enable anyone to have instantaneous access to massive capital. This
section outlines how that can have negative effects, as we explain two attacks
facilitated by flash loans yielding an ROI beyond 500k%. We evaluate the pro-
posed DeFi attack optimization framework (cf. Section 4) on these two analyzed
attacks (cf. Section 5).

3.1 Pump Attack and Arbitrage (PA&A)

On the 15th of February, 2020, a flash loan transaction (cf. 0xb5c8bd9430b6cc87a
0e2fe110ece6bf527fa4f170a4bc8cd032f768fc5219838 at an ETH price of 264.71 US-
D/ETH), followed by 74 transactions, yielded a profit of 1, 193.69 ETH (350k

https://etherscan.io/tx/0xb5c8bd9430b6cc87a0e2fe110ece6bf527fa4f170a4bc8cd032f768fc5219838
https://etherscan.io/tx/0xb5c8bd9430b6cc87a0e2fe110ece6bf527fa4f170a4bc8cd032f768fc5219838


Attacking the DeFi Ecosystem with Flash Loans for Fun and Profit 7

1)	Flash	Loan	Provider	(dYdX)
borrow	10,000.00	ETH

2)	Lending	(Compound)
collateralize	5,500.00	ETH	and	borrow	112.00	WBTC

3.1)	Margin	Trade	Provider	(bZx)
5x	short	1,300.00	ETH	against	WBTC

3.2)	Exchange	(WBTC	Uniswap)
convert	5,637.62	ETH	to	51.35	WBTC

4)	Exchange	(WBTC	Uniswap)
convert	112.00	WBTC	to	6,871.41	ETH

5)	Flash	Loan	Provider	(DyDx)
repay	10,000.00	ETH

3,200.00	ETH 10,071.41	ETH

71.41	ETH

Flash	loan
transaction

(block	9484688)

Block	
9484917	-	9496602

a)	Exchange	(Kyber)
convert	4,377.72	ETH	to	112.00	WBTC

b)	Lending	(Compound)
repay	112.00	WBTC	and	redeem	5,500.00	ETH

ETH	Flow

WBTC	Flow

Uniswap	Pool	Size
2817.77	ETH	
77.09	WBTC

8455.40	ETH	
25.74	WBTC

Uniswap	Pool	Size
8455.40	ETH
25.74	WBTC

1583.98	ETH	
137.74	WBTC

Fig. 3: The pump attack and arbitrage. The attack consists of two parts, a flash
loan and several loan redemption transactions.

USD) given a transaction fee of 132.36 USD (cumulative 50, 237, 867 gas, 0.5
ETH). We show in Section 5.1 that the adversarial parameters were not opti-
mal, and that the adversary could have earned a profit exceeding 829.5k USD.
Attack intuition: The core of PA&A is that the adversary pumps the price
of ETH/WBTC on a constant product AMM DEX (Uniswap) with the lever-
aged funds of ETH in a margin trade. The adversary then purchases ETH at
a “cheaper” price on the distorted DEX market (Uniswap) with the borrowed
WBTC from a lending platform (Compound). As shown in Figure 3, this attack
mainly consists of two parts. For simplicity, we omit the conversion between
ETH and WETH (the 1:1 convertible ERC20 version of ETH).
Flash Loan (single transaction): The first part of the attack (cf. Figure 3)
consists of 5 steps within a single transaction. In step 1 , the adversary bor-
rows a flash loan of 10, 000.00 ETH from a flash loan provider (dYdX). In step
2 , the adversarial trader collateralizes 5, 500.00 ETH into a lending platform
(Compound) to borrow 112.00 WBTC. Note that the adversarial trader does
not return the 112.00 WBTC within the flash loan. This means the adver-
sarial trader takes the risk of a forced liquidation against the 5, 500.00 ETH
collateral if the price fluctuates. In steps 3 , the trader provides 1, 300 ETH
to open a short position for ETH against WBTC (on bZx) with a 5× lever-
age. Upon receiving this request, bZx transacts 5, 637.62 ETH on an exchange
(Uniswap) for only 51.35 WBTC (at 109.79 ETH/WBTC). Note that at the
start of block 9484688, Uniswap has a total supply of 2, 817.77 ETH and 77.09
WBTC (at 36.55 ETH/WBTC). The slippage of this transaction is significant
with 109.79−36.55

36.55 = 200.38%. In step 4 , the trader converts 112.00 WBTC
borrowed from lending platform (Compound) to 6, 871.41 ETH on the DEX
(Uniswap) (at 61.35 ETH/WBTC). We remark that the equity of the adversar-
ial margin account is negative after the margin trading because of the significant
price movement. The pump attack could have been avoided if bZx checked the
negative equity and reverted the transaction. At the time of the attack, this
logic existed in the bZx contracts but was not invoked properly. In step 5 , the
trader pays back the flash loan plus an interest of 10−7 ETH. After the flash loan
transaction (i.e., the first part of PA&A), the trader gains 71.41 ETH, and has
a debt of 112 WBTC over-collateralized by 5, 500 ETH (49.10 ETH/WBTC). If

https://etherscan.io/block/9484688


8 K. Qin et al.

the ETH/WBTC market price is below this loan exchange rate, the adversary
can redeem the loan’s collateral as follows.
Loan redemption: The second part of the trade consists of two recurring steps,
(step a - b ), between Ethereum block 9484917 and 9496602. Those transactions
aim to redeem ETH by repaying the WBTC borrowed earlier (on Compound).
To avoid slippage when purchasing WBTC, the trader executes the second part
in small amounts over a period of two days on the DEX (Kyber, Uniswap). In
total, the adversarial trader exchanged 4, 377.72 ETH for 112 WBTC (at 39.08
ETH/WBTC) to redeem 5, 500.00 ETH.
Identifying the victim: We investigate who of the participating entities is
losing money. Note that in step 3 of Figure 3, the short position (on bZx)
borrows 5, 637.62 − 1, 300 = 4, 337.62 ETH from the lending provider (bZx),
with 1, 300 ETH collateral. Step 3 requires to purchase WBTC at a price
of 109.79 ETH/WBTC, with both, the adversary’s collateral and the pool funds
of the liquidity provider. 109.79 ETH/WBTC does not correspond to the mar-
ket price of 36.55 ETH/WBTC prior to the attack, hence the liquidity provider
overpays by nearly 3× of the WBTC price.
How much are the victims losing: We now quantify the losses of the liquidity
providers. The loan provider lose 4, 337.62 (ETH from loan providers) - 51.35
(WBTC left in short position) × 39.08 (market exchange rate ETH/WBTC) =
2, 330.86 ETH. The adversary gains 5, 500.00 (ETH loan collateral in Compound)
- 4, 377.72 (ETH spent to purchase WBTC) + 71.41 (part 1) = 1, 193.69 ETH.
More money is left on the table: Due to the attack, Uniswap’s price of ETH
was reduced from 36.55 to 11.50 ETH/WBTC. This creates an arbitrage oppor-
tunity, where a trader can sell ETH against WBTC on Uniswap to synchronize
the price. 1, 233.79 ETH would yield 60.65 WBTC, instead of 33.76 WBTC,
realizing an arbitrage profit of 26.89 WBTC (286, 035.04 USD).

3.2 Oracle Manipulation Attack

We proceed to detail a second flash loan attack, which yields a profit of 2, 381.41
ETH (c. 634.9k USD) within a single transaction (cf. 0x762881b07feb63c436de
e38edd4ff1f7a74c33091e534af56c9f7d49b5ecac15, on the 18th of February, 2020,
at an ETH price of 282.91 USD/ETH) given a transaction fee of 118.79 USD.
Before diving into the details, we cover additional background knowledge. We
again show how the chosen attack parameters were sub-optimal and optimal
parameters would yield a profit of 1.1M USD instead (cf. Section 5.2).
Price oracle: One of the goals of the DeFi ecosystem is to not rely on trusted
third parties. This premise holds both for asset custody as well as additional
information, such as asset pricing. One common method to determine an asset
price is hence to rely on the pricing information of an on-chain DEX (e.g.,
Uniswap). DEX prices, however, can be manipulated with flash loans.
Attack intuition: The core of this attack is an oracle manipulation using a
flash loan, which lowers the price of sUSD/ETH. In a second step, the adversary
benefits from this decreased sUSD/ETH price by borrowing ETH with sUSD as
collateral.

https://etherscan.io/block/9484917
https://etherscan.io/block/9496602
https://etherscan.io/tx/0x762881b07feb63c436dee38edd4ff1f7a74c33091e534af56c9f7d49b5ecac15
https://etherscan.io/tx/0x762881b07feb63c436dee38edd4ff1f7a74c33091e534af56c9f7d49b5ecac15


Attacking the DeFi Ecosystem with Flash Loans for Fun and Profit 9

1)	Flash	Loan	Provider	(bZx)
borrow	7,500.00	ETH

2)	Exchange	(sUSD	Uniswap)
convert	540.00	ETH	to	92,419.70	sUSD

3)	Exchange	(Kyber)
convert	360.00	ETH	to	63,584.09	sUSD

4)	Exchange	(Synthetix)
deposit	3,517.86	ETH	for	943,837.59	sUSD

5)	Lending	(bZx)
collateralize	1,099,841.39	sUSD	and	borrow	6,799.27	ETH

6)	Flash	Loan	Provider	(bZx)
repay	7,500.00	ETH

3,082.14	ETH

1,099,841.39	sUSD

9,881.41	ETH

2,381.41	ETH ETH	Flow sUSD	Flow

Uniswap	Pool	Size
879.76	ETH		243,441.12	sUSD

1,419.76	ETH	151,021.42	sUSD

Kyber	Reserve	Pool	Size
0.91	ETH	107,901.90	sUSD

360.91	ETH	44,317.80	sUSD

Fig. 4: The oracle manipulation attack.

Adversarial oracle manipulation: We identify a total of 6 steps within
this transaction (cf. Figure 4). In step 1 , the adversary borrows a flash loan
of 7, 500.00 ETH (on bZx). In the next three steps ( 2 , 3 , 4 ), the adversary
converts a total of 4, 417.86 ETH to 1, 099, 841.39 sUSD (at an average of 248.95
sUSD/ETH). The exchange rates in step 2 and 3 are 171.15 and 176.62 sUS-
D/ETH respectively. These two steps decrease the sUSD/ETH price to 106.05
sUSD/ETH on Uniswap and 108.44 sUSD/ETH on Kyber Reserve, which are col-
lectively used as a price oracle of the lending platform (bZx). Note that Uniswap
is a constant product AMM, while Kyber Reserve is an AMM following a dif-
ferent formula (cf. Appendix C). The trade on the third market (Synthetix) in
step 4 is yet unaffected by the previous trades. The adversarial trader then
collateralizes all the purchased sUSD (1, 099, 841.39) to borrow 6, 799.27 ETH
(at exchange rate

collateral factor = max(106.05, 108.44) × 1.5 = 162.66 sUSD/ETH on bZx).
Now the adversary possesses 6, 799.27+3, 082.14 ETH and in the last step repays
the flash loan amounting to 7, 500.00 ETH. The adversary, therefore, generates a
revenue of 2, 381.41 ETH while only paying 0.42 ETH (118.79 USD) transaction
fees.
Identifying the victim: The adversary distorted the price oracle (Uniswap
and Kyber) from 268.30 sUSD/ETH to 108.44 sUSD/ETH, while other DeFi
platforms remain unaffected at 268.30 sUSD/ETH. Similar to the pump attack
and arbitrage, the lenders on bZx are the victims losing assets as a result of the
distorted price oracle. The lender lost 6, 799.27 ETH - 1, 099, 841 sUSD, which
is estimated to be 2, 699.97 ETH (at 268.30 sUSD/ETH). The adversary gains
6, 799.27 (ETH from borrowing) - 3, 517.86 (ETH to purchase sUSD) - 360 (ETH
to purchase sUSD) - 540 (ETH to purchase sUSD) = 2, 381.41 ETH.

4 Optimizing DeFi Attacks

The atomicity of blockchain transactions guarantees the continuity of the action
executions. When the initial state is deterministically known, this trait allows an
adversary to predict the intermediate results precisely after each action execution
and then to optimize the attacking outcome by adjusting action parameters.
In light of the complexity of optimizing DeFi attacks manually, we propose
a constrained optimization framework that is capable of optimizing the action
parameters. We show, given a blockchain state and an attack vector composed
of a series of DeFi actions, how an adversary can efficiently discover the optimal
action parameters that maximize the resulting expected revenue.



10 K. Qin et al.

4.1 System and Threat Model

The system considered is limited to one decentralized ledger which supports
pseudo-Turing complete smart contracts (e.g., similar to the Ethereum Virtual
Machine; state transitions can be reversed given certain conditions).

We assume the presence of one computationally bounded and economically
rational adversary A. A attempts to exploit the availability of flash loans for
financial gain. While A is not required to provide its own collateral to perform the
presented attacks, the adversary must be financially capable to pay transaction
fees. The adversary may amass more capital which possibly could increase its
impact and ROI.

4.2 Parametrized Optimization Framework

We start by modeling different components that may engage in a DeFi attack. To
facilitate optimal parameter solving, we quantitatively formalize every endpoint
provided by DeFi platforms as a state transition function S′ = T (S; p) with the
constraints C(S; p), where S is the given state, p are the parameters chosen by
the adversary and S′ is the output state. The state can represent, for example,
the adversarial balance or any internal status of the DeFi platform, while the
constraints are set by the execution requirements of the EVM (e.g., the Ether
balance of an entity should never be a negative number) or the rules defined
by the respective DeFi platform (e.g., a flash loan must be repaid before the
transaction termination plus loan fees). When quantifying profits, we ignore
the loan interest/fee payments and transaction fees, which are negligible in the
present DeFi attacks. The constraints are enforced on the input parameters and
output states to ensure that the optimizer yields valid parameters.

We define the balance state function B(E; X; S) to denote the balance of
currency X held by entity E at a given state S and require Equation 1 to hold.

∀(E, X, S), B(E; X; S) ≥ 0 (1)

The mathematical DeFi models applied in this work are detailed in Appendix C.
Our parametrized optimizer is designed to solve the optimal parameters that

maximizes the revenue given an on-chain state, DeFi models and attack vector.
An attack vector specifies the execution order of different endpoints across var-
ious DeFi platforms, depending on which we formalize a unidirectional chain of
transition functions (cf. Equation 2).

Si = Ti(Si−1; pi) (2)

By nesting transition functions, we can obtain the cumulative state transition
functions ACCi(S0; p1:i) that satisfies Equation 3, where p1:i = (p1, ..., pi).

Si = Ti(Si−1; pi) = Ti(Ti−1(Si−2; pi−1); pi)
= Ti(Ti−1(...T1(S0, p1)...; pi−1); pi) = ACCi(S0; p1:i)

(3)



Attacking the DeFi Ecosystem with Flash Loans for Fun and Profit 11

Therefore the constraints generated in each step can be expressed as Equation 4.

Ci(Si; pi)⇐⇒ Ci(ACCi(S0; p1:i); pi) (4)

We assume an attack vector composed of N transition functions. The objective
function can be calculated from the initial state S0 and the final state SN (e.g.,
the increase of the adversarial balance).

O(S0; SN )⇐⇒ O(S0;ACC(S0; p1:N )) (5)

Given the initial state S0, we formulate an attack vector into a constrained
optimization problem with respect to all the parameters p1:N (cf. Equation 6).

maximize O(S0;ACC(S0; p1:N ))
s.t. Ci(ACCi(S0; p1:i); pi) ∀i ∈ [1, N ]

(6)

5 Evaluation

In the following, we evaluate our parametrized optimization framework on the
existing attacks described in Section 3. We adopt the Sequential Least Squares
Programming (SLSQP) algorithm from SciPy2 to solve the constructed opti-
mization problems. Our framework is evaluated on a Ubuntu 18.04.2 machine
with 16 CPU cores and 32 GB RAM.

5.1 Optimizing the Pump Attack and Arbitrage

We first optimize the pump attack and arbitrage. Figure 5 summarizes the no-
tations and the on-chain state when the attack was executed (i.e., S0). We use
these blockchain records as the initial state in our evaluation. X and Y denote
ETH and WBTC respectively. In the PA&A attack vector, we intend to tune
the following two parameters, (i) p1: the amount of X collateralized to borrow Y
(cf. step 2 and 3 in Figure 3) and (ii) p2: the amount of X collateralized to short
Y (cf. step 4 in Figure 3). Following the methodology specified in Section 4.2,
we derive the optimization problem and the corresponding constraints, which
are presented in Figure 6. We detail the deriving procedure in Appendix D. We
remark that there are five linear constraints and only one nonlinear constraint,
which implies that the optimization can be solved efficiently.

We repeated our experiment for 1, 000 times, the optimizer spent 6.1ms
on average converging to the optimum. The optimizer provides a maximum
revenue of 2, 778.94 ETH when setting the parameters (p1; p2) to (2, 470.08;
1, 456.23), while in the original attack the parameters (5, 500; 1, 300) only yield
1, 171.70 ETH. Due to the ignor";"""date"",""2021-03-23T01:46:38Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2021-03-23T01:46:38Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.21 (TeX Live 2020) kpathsea version 6.3.2""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2021-03-23T01:46:38Z""
""created"",""2021-03-23T01:46:38Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2021-03-23T01:46:38Z""
""resourceName"",""2003.03810""
""Author"",""""
""producer"",""pdfTeX-1.40.21""
""pdf:docinfo:producer"",""pdfTeX-1.40.21""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""2"",""0"",""4"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""4"",""4"",""12"",""4"",""3"",""1"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2021-03-23T01:46:38Z""
""Last-Modified"",""2021-03-23T01:46:38Z""
""dcterms:modified"",""2021-03-23T01:46:38Z""
""title"",""""
""Last-Save-Date"",""2021-03-23T01:46:38Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2021-03-23T01:46:38Z""
""meta:save-date"",""2021-03-23T01:46:38Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.21 (TeX Live 2020) kpathsea version 6.3.2""
""Content-Length"",""2091975""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""29""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""2344"",""2460"",""2407"",""2416"",""2129"",""2435"",""2908"",""2584"",""2788"",""2201"",""2099"",""2554"",""2643"",""2099"",""2800"",""2672"",""2881"",""2378"",""2397"",""2086"",""2144"",""1500"",""1422"",""1541"",""1857"",""882"",""1112"",""1496"",""1601""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2021-03-23T01:46:38Z""
";https://scholar.google.ch/scholar?start=570&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098743-57;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Impact of Supply Chain Digitalisation on a Connected Global Market;F Habib, MF Khan ; Handbook of Research on Innovations in …, 2020  igiglobal.com;;"… Tethering and stabilis- ing the value of the cryptocurrency to national currencies would eliminate

credit risk, increase central banks … customer experience, prevention of fraud, facilitation of timely

compliance and the maximisation of operational efficiency (Oracle, 2019b … Blockchain …";Autres articles;;null;;;;https://scholar.google.ch/scholar?start=600&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098835-267;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Security Evaluation of Smart Contract-Based On-chain Ethereum Wallets;P Praitheeshan, L Pan, R Doss ; International Conference on Network and …, 2020  Springer;;"… of wallets are more convenient and trustful since they run on Ethereum blockchain, and they …

contracts wallets running on Ethereum and identify reliable wallets to manage crypto assets safely …

call external libraries, accounts, and third-party web services through oracle interfaces …";Cité 2 fois;Les 2 versions;null;;;;https://scholar.google.ch/scholar?start=810&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098866-332;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;[PDF][PDF] Anonymous, Attribute Based, Decentralized, Secure, and Fair e-Donation;O Biçer, A Küpçü ; Proceedings on Privacy Enhancing …, 2020  petsymposium.org;;"… Abstract: E-cash and cryptocurrency schemes have been a focus of applied cryptography for

a … How- ever, we acknowledge the continuing need for a crypto- graphic protocol that provides …

Our framework relies on a public ledger that can be realized via a distributed blockchain …";Autres articles;;[PDF] petsymposium.org;https://www.petsymposium.org/2020/files/papers/issue4/popets-2020-0067.pdf;"
Proceedings on Privacy Enhancing Technologies ; 2020 (4):196–219

Osman Biçer and Alptekin Kßpçß

Anonymous, Attribute Based, Decentralized,
Secure, and Fair e-Donation
Abstract: E-cash and cryptocurrency schemes have been
a focus of applied cryptography for a long time. How-
ever, we acknowledge the continuing need for a crypto-
graphic protocol that provides global scale, decentral-
ized, secure, and fair delivery of donations. Such a pro-
tocol would replace central trusted entities (e.g., charity
organizations) and guarantee the privacy of the involved
parties (i.e., donors and recipients of the donations). In
this work, we target this online donation problem and
propose a practical solution for it. First, we propose
a novel decentralized e-donation framework, along with
its operational components and security definitions. Our
framework relies on a public ledger that can be realized
via a distributed blockchain. Second, we instantiate our
e-donation framework with a practical scheme employ-
ing privacy-preserving cryptocurrencies and attribute-
based signatures. Third, we provide implementation re-
sults showing that our operations have feasible compu-
tation and communication costs. Finally, we prove the
security of our e-donation scheme via formal reductions
to the security of the underlying primitives.

Keywords: anonymous donation, attribute based signa-
ture, blockchain, anonymous credentials

DOI 10.2478/popets-2020-0069
Received 2020-02-29; revised 2020-06-15; accepted 2020-06-16.

1 Introduction
Since the first secure e-cash scheme was proposed by
Chaum [21], digital currencies have been a center of at-
tention in applied cryptography. One development of
practical importance has been the invention of Bitcoin
[54], which combines the ideas of conventional e-cash,
proof of work [25], distributed systems, and game the-
ory for a decentralized electronic payment scheme. The
emergence of Bitcoin has not only contributed to state-
of-the-art cryptocurrency schemes, but also brought to
attention the blockchain, which is a decentralized and
unalterable public ledger. Informally, a public ledger is

Osman Biçer: Koç University, obicer17@ku.edu.tr
Alptekin Kßpçß: Koç University, akupcu@ku.edu.tr

an append-only bulletin board, where new data can be
added only if it satisfies a predetermined criterion. The
proposed Bitcoin and blockchain mechanism depends
on only proof of work (PoW) [25] instead of requir-
ing a trusted third party for maintenance. PoW can be
briefly described as a race among blockchain miners for
computing brute-force solutions to a cryptographic puz-
zle with ever-changing parameters. Recent blockchain
and Bitcoin research has focused on novel applications
[2, 4, 6, 8, 40, 44, 45, 58], improved security [28–30, 39],
and enhanced privacy [51, 60]. In this paper, we focus
on the novel problem of anonymous decentralized online
donations as a public ledger application.

The context that we consider is similar to the “help-
ing a stranger” described in CAF 2018 World Giving
Index [36]. There, international charity organizations
(ICO) match the donor and recipients based on the for-
mer’s attribute choices. The size of the charity organi-
zations is usually underestimated. In fact, they have a
grand sector of its own with numbers as high as more
than 180,000 organizations only in United Kingdom [11]
and more than 2 out of 3 people donate in countries
like Indonesia, Australia, New Zealand, America, Ire-
land, United Kingdom [36]. We acknowledge this high
demand for charity, and differentiate our work from this
traditional setting by being decentralized, i.e., by elim-
inating ICOs to carry out the donation process. Our
work enables donors to choose recipients based on their
attributes in one compact system, providing fairness1

of donation distributions by allowing each recipient to
obtain a limited amount in each time period.

In an online donation scheme, a donor (Alice)
chooses a recipient (Bob) based on his attributes with-
out meeting him in person. Alice picks an attribute pol-
icy (e.g., the recipient should be “a high school stu-
dent” AND “a person whose family’s monthly income is
lower than $750 per month”), and publishes it in a pub-
licly visible venue (the Ledger) along with the donation
amount. She might go offline afterwards. Assume that
Bob meets this criteria, and has obtained attribute to-
kens from the authorities (e.g., student certificate from
his school, and low income certificate from the min-
istry). Upon seeing this donation on the Ledger, Bob

1 For a further discussion on fairness, see Section 7.



e-Donation 197

Fig. (1) The flow of the online donation scheme that we propose. 1Š Bob obtains his attribute token from an attribute authority. 2Š
Alice publishes the donation and the attribute policy on a publicly seen medium. She might go offline afterwards. 3Š Upon seeing the
donation, Bob claims the donation by showing the proof of his conformity to the attribute policy that he generated via the attribute
token. 4Š Bob then spends the donation amount, according to his wish.

proves his conformity to this attribute policy via the
obtained attribute tokens to claim the donation. Figure
1 shows the flow of the online donation scheme. The
identities of all the parties involved remain anonymous
and their actions remain unlinkable during the whole
process. Further, the protocol ensures that Bob will not
be able to claim more donations (even if he satisfies their
policies) than a publicly set amount from the system in
a time period for fairness to the other people. The sys-
tem also ensures that someone (who does not meet the
attribute policy that Alice picked), cannot claim any
money from her donation. We list the aspects that an
e-donation scheme needs to satisfy as follows:
- donor privacy: it should prevent the leakage of
Alice’s identity and linkage between multiple dona-
tions by her.

- recipient privacy: it should prevent linking be-
tween donations that Bob has received and leakage
about his identity.

- fair distribution of donations: it should not al-
low Bob to receive more than a publicly determined
amount of donation from the system in a given time
period for fairness to other potential recipients.

- decentralization: it should not require trusted
third parties (e.g., charity organizations) for the do-
nation process.2

2 We observe that trusted authorities are inevitable for checking
recipient attributes (e.g., being a student), but they are not

- always-on: it should not require Alice and Bob to
remain and interact online, in particular, it should
allow Alice to go offline after sending her donation
money and the recipient attribute policy.

- security: it should protect the overall balance of
the involved parties.

- scalability: it should be supporting multiple at-
tribute authorities for issuing attributes to multiple
recipients and multiple donors, and Bob should be
able to receive a donation from any geographical
location as long as he satisfy its policy.

- accountability: donations should be binding such
that Bob should indeed receive a donation if he
proves his conformity to the associated policy.3

- revocability: it should allow revocation of at-
tributes or users.
We note that some of these aspects may not be nec-

essary in all cases. For example, some donors may choose
not to be anonymous or may like to see the recipients
of their donations. In our solution, we choose to pro-
vide the most capable and privacy-preserving solution
that we could, and some aspects of our solution is pre-
sented in a modular way such that they can be removed
for obtaining a more efficient but less capable solution.

required for monetary transactions or for each donation (they
are used only for issuing attributes per user not per transaction).
3 Without this property, the scheme would allow an unethical
opportunity of data collection via fake donations, without the
attacker losing any money.



e-Donation 198

donor
privacy

recipient
privacy

fair dis-
tribution

decentra
lization

always-
on

secu-
rity

scala-
bility

accoun-
tability

revoca-
bility

ICO X* X* X* X* X* X* X* X*
NCC X X X X X

ACC X X X X X X X

PSC X X X X X X X

Our scheme X X X X X X X X X

Table (1) Comparison of traditional international charity organizations (ICO), the non-anonymous cryptocurrency (NCC) schemes
(e.g., Bitcoin [54] and Ethereum [13]), the anonymous cryptocurrency (ACC) schemes (e.g., Monero [52], Zerocoin [51], and Zerocash
[60]), the private smart contract (PSC) schemes (e.g., Hawk [42], Arbitrum [37], Zether [12], ZEXE [10], and Enigma [1]) and our e-
donation scheme (see Section 4 in terms of adequacy of e-donation requirements. Xdenotes satisfaction of a requirement. By X*, we
refer the facts that the traditional ICOs can only provide donor and recipient privacy in a limited way, as they do learn the identities
of the parties (but they may choose to hide this information when trusted); and that fair distribution of donations in these schemes is
limited, as recipients can obtain donations from various ICOs; and that their security, being always-on, scalability, accountability, and
revocability depend on the honesty of a single organization for all these tasks to be carried out.

Table 1 provides a comparison of various possible solu-
tions with respect to our e-donation requirements. We
highlight that the traditional ICOs can only provide
donor and recipient privacy in a limited way as they
do learn the identities of the parties. Also, fair distribu-
tion of donations in this scheme is limited, as recipients
may obtain donations from various ICOs. Furthermore,
their security, being always-on, scalability, accountabil-
ity, and revocability depend on the honesty of a single
organization for all these tasks to be carried out. The
motivation behind our proposed profile relies on the re-
port of [11], showing that the donor behavior tends to
be simplistic with few attribute choices in recipients and
caring more about fast delivery and ease of the donation
process than finding the best fitting recipient.

System Model. In our framework, in each state
or region there is a top level authority identity provider
(e.g., Census Bureau or State Authority) that user in-
teracts when he joins the system to generate his user
token. Thus, upon joining the system, each user has an
identity attribute (e.g., national identity number or so-
cial security number). This is required for preventing
Sybil attacks [61]. There are also attribute authorities
for issuing attributes of users. An attribute authority
can provide tokens for various attributes, and an at-
tribute can be issued by more than one authority. We
highlight that the system should prevent different users
from combining their attributes. For a further discus-
sion on possible authority architecture improvements,
see Section 7.

We trust identity providers and attribute authori-
ties (e.g., school districts) for honest issuing of user and
attribute tokens by checking identities and eligibility of
the users for attributes (e.g., high school student). The
only malicious actions that authorities can take are is-

suing tokens to the undeserving users and revealing the
identity of the users that applied to them for tokens,
which can happen in any donation system. Yet, none
of the authorities can donate or claim on behalf of a
user, nor can they carry out the whole donation pro-
cess as an ICO. They do not have monetary transaction
abilities, and are not involved in each donation; rather,
they are required only once per person while obtaining
the attribute. Even the authorities collectively cannot
identify a user from her transactions. Other than those
potential malicious actions, no authority can deduce a
user’s secret key or sign on behalf her. Besides, even the
authorities cannot identify a user from her signature.

Failed Approaches. One might imagine a triv-
ial online solution to the secure donation problem as
follows. First, the donor publishes the attribute policy
that she prefers the recipient to conform to. Next, a po-
tential recipient and the donor together run an anony-
mous credential protocol (e.g., [18]), where the recipient
proves his eligibility to the donor. Then, the donor di-
rectly pays the donation money to the recipient using an
anonymous e-cash scheme to preserve privacy. However,
although this scheme seems applicable, it can hardly sat-
isfy some of the above-mentioned requirements, namely,
online decentralization (due to the need for a trusted
third party in the e-cash scheme), scalability (since it is
not easy for every donor to always have secure access to
all valid authority certificates and potential recipients),
revocability (again, since secure access to all revocation
lists or keys may be hard for every donor), and account-
ability (since once the recipient proves his conformity,
the donor can still choose not to send the e-cash). More-
over, this trivial solution requires the recipients and the
donors to remain online and to interact directly, not
allowing decentralization in its full sense as described



e-Donation 199

PrivateDonate  PrivateClaim

Ledger

BaseCash PrivCashMint PrivCashSpendClaimDonate

Fig. (2) The flow of transactions in our e-donation scheme. The PrivCashMint and Donate transactions are made by the donor (to-
gether called PrivateDonate), while the Claim and PrivCashSpend transactions are made by the recipient of the donation (together
called PrivateClaim). The BaseCash tuples referenced by the PrivCashMint transaction (leftmost ones) belong to the donor, whereas
the output of the PrivCashSpend transaction belongs to the final payee(s). The straight arrows represent direct referencing of the
transaction (linkable), while the dashed arrows represent the use of the outputs (unlinkable). We note that the block boxes are placed
arbitrarily.

above. Lastly, in such a setting, enforcing fair distri-
bution seems impossible. In our solution, we employ a
distributed ledger together with proper novel crypto-
graphic tools to deal with these issues, and provide the
first definition and instantiation for the anonymous fair
e-donation paradigm.

The anonymous decentralized e-cash schemes [51,
60] cannot be directly applied for the e-donation pur-
pose, as they do not provide a mechanism for anony-
mous attribute-based money transfer between donors
and recipients who are non-privy to each other. Also, it
is non-trivial to directly combine these with the existing
anonymous attribute proving techniques (e.g., anony-
mous credentials [14, 15, 17, 18, 23, 31, 48]), attribute
based signatures [19, 26, 32, 49, 56, 67], group signa-
tures [5, 16, 27, 35, 55, 62, 71]), while satisfying the
above-mentioned requirements. We note that even let-
ting ICOs use anonymous cryptocurrencies (e.g., Zero-
cash [60]) does not help with all of our e-donation re-
quirements. While such a trivial scheme may increase
donor and recipient privacy, it can hardly distribute do-
nations fairly. Further, the above-mentioned shortcom-
ings of ICOs still prevail.

An existing private smart contract scheme (e.g.,
Hawk [42], Arbitrum [37], Zether [12], ZEXE [10], and
Enigma [1]) would also not solve the online donation
problem itself, since it does not achieve fair distribution
of donations. We show that combining a decentralized
e-cash scheme or a private contract scheme with an at-
tribute based signature scheme (e.g, VABS of [7]) would
achieve e-donation.

Overview of Our Techniques. In this work, we
employ a public ledger for decentralization and account-
ability. We highlight that according to the flowchart
presented by NIST [69, Fig. 6], the use of blockchain
in our application is appropriate. We highlight that al-
though e-donation fits better to blockchain-based ledger
applications, there is no limitation for using it with con-
ventional e-cash schemes, as we abstract out the ledger
implementation. The ledger can be maintained by a
trusted party (e.g., the issuer of the e-cash), and all
its security guarantees still hold.

Our scheme is based on three cryptographic build-
ing blocks: an underlying BaseCash scheme (i.e., our ab-
straction of decentralized e-cash such as Bitcoin [54])
that provides the amount of donations, an anonymized
PrivCash scheme (i.e., our abstraction of decentral-
ized anonymous e-cash such as Zerocash [60]) and an
attribute-based signature scheme called VABS [7] that
provides usage limitation, revocability, and decentral-
ization features. PrivCash scheme basically has two op-
erations, PrivCashMint for minting PrivCash (e.g., in Ze-
rocash a Mint operation for converting the amounts in
t-addresses into the ones z-addresses) and PrivCashSpend
for spending minted PrivCash (e.g., in Zerocash a Pour
operation by converting the amounts in z-addresses into
the ones in t-addresses). A PrivateDonate transaction
made by the donor consists of two main actions: one
for minting some PrivCash (i.e., PrivCashMint) and one
for sending it to some attribute policy (i.e., Donate) as
a spending transaction. Similarly, a PrivateClaim trans-
action made by the recipient consists of two main ac-
tions: one for claiming a previous donation (i.e., Claim)



e-Donation 200

signed with a VABS for proving attribute policy confor-
mity and one for spending it to a separate payee (i.e.,
PrivCashSpend). Once the donor makes a donation to an
attribute policy, the donation is fixed on the Ledger as a
PrivateDonate transaction tuple, and the donor no longer
needs to be involved in its delivery. The donations on
the Ledger are delivered in a first-come-first-served ba-
sis. Any qualified recipient (adhering to the attribute
policy) can claim a donation with a PrivateClaim trans-
action tuple, as long as the donation (partially) remains
unclaimed on the Ledger. Furthermore, for fair distri-
bution of the donations, we limit the total amount of
donations that a recipient can claim in a given time
period. Figure 2 shows the flow of transactions in our
e-donation scheme.

Our Contributions. We list the overall contribu-
tions of this paper as follows:
1. In Section 3, we propose a novel, secure, and decen-

tralized e-donation framework. Our generic frame-
work is ledger-based, therefore, it can be realized on
top of a distributed blockchain. We scrupulously de-
fine the component algorithms and transaction tu-
ples of the framework. We further provide formal
game-based definitions for its security properties,
(1) unforgeability and balance, (2) fair distribution
of donations, (3) donation and recipient privacy.

2. In Section 4, we instantiate our e-donation frame-
work with a practical and provably secure scheme.
Our scheme is based on two cryptographic building
blocks: an anonymized PrivCash scheme (i.e., our ab-
straction for decentralized anonymous e-cash such
as Zerocash [60]) and a recent attribute-based sig-
nature scheme called VABS [7]. In Appendix A, we
formally prove that our proposed scheme satisfies
the security requirements of the e-donation frame-
work, if the underlying building blocks are secure.

3. In Section 6, we provide efficiency information for
our e-donation scheme, showing that our operations
have reasonable computation and communication
costs (i.e., for many cases, donating takes less than
1.7 min and 6 kB, while receiving donations takes
around 1.7 min and less than 90 kB).

2 Preliminaries
Notation.Throughout this paper,
- a ďż˝ B denotes that a gets a value from the set B
sampled uniformly at random,

- a ← B denotes that a gets the output of a proba-
bilistic polynomial time algorithm (PPT) B,

- a := b denotes that a gets the value of b,
- A(a) → b denotes that A is a PPT taking as in-
put a and outputting b (A may output values non-
deterministically), and

- A{B1(b1), B2(b2)} → (c1), (c2) denotes that B1 and
B2 are two parties executing the protocol A on their
inputs b1 and b2, respectively, and A outputs c1 and
c2 to parties B1 and B2, respectively (A may output
values non-deterministically to both parties).
Ideal Public Ledger. We now briefly describe an

ideal public ledger functionality based on the public
ledger functionality definition of [40]. Any party can se-
curely read the current LedgerC, while only the Ledger
writer is allowed to write on it by appending some data.
Any transaction4 handed to the Ledger writer is written
to the Ledger, if it satisfies a validation function f , i.e., a
commonly determined polynomial time function taking
as input a transaction, and outputting either 1 (satis-
fied) or 0 (unsatisfied).

Two commonly known realizations of the Ledger
functionality are via a blockchain or via a trusted party.
In [29] and [30], the authors show that the Bitcoin
protocol provides the requirements of a public ledger,
based on the assumptions that the number of min-
ers are constant, and that the majority of the hashing
power belongs to the honest miners. However, existing
blockchains, in practice, have issues such as connectiv-
ity problems or Eclipse attacks on the peer-to-peer net-
work of blockchain. Therefore, when realizing the Ledger
functionality as a blockchain, such issues should be con-
sidered. Further, blockchains do not offer network layer
anonymity themselves as required by the Ledger func-
tionality, but this can be provided via an additional re-
source such as using the TOR network [65].

BaseCash scheme. Our e-donation framework re-
quires an underlying BaseCash scheme that functions as
the value of the donations. A BaseCash is a tuple (v, p),
where v is a value determining the amount and p is a
public key of the owner who also has a related secret
key s. We note that each BaseCash tuple has a unique
reference number r given by the Ledger writer when it
is written on the Ledger. In Zerocash, BaseCash corre-
sponds to Bitcoin or a coin belonging to t-addresses
in Zerocash [60]. Yet, we do not separate these tuples
and refer both as BaseCash. We note that BaseCash may
have setup, transaction generation, and verification al-

4 We use the term “transaction” to refer to any information
string that conforms to some predefined rules.



e-Donation 201

gorithms, but are abstracted out for simplicity. The key
generation algorithm for (s, p) is part of a digital signa-
ture scheme that is assumed to satisfy existential unfor-
geability under an adaptive chosen-message attack [38].

PrivCash scheme. Based on the decentralized
e-cash definitions of Zerocash [60], we now describe
a generic decentralized anonymous payment scheme
PrivCash, which we utilize for donor and recipient pri-
vacy in our e-donation scheme. Yet, our description
is simplified as including three types of operations
PrivCashKeyGen, PrivCashMint, and PrivCashSpend. Also,
it differs from the one in [60] by inclusion of a unit
BaseCash amount u of each transaction (we require
this for fair distribution of donations in our e-donation
scheme) and exclusion of details (e.g., Merkle root in-
puts to spending operations) that are not generalizable.
We note that similar ideas exist in [51] or other “mix-
ing” based currencies [9, 59, 68, 72]. At the start of the
PrivCash scheme execution, the Ledger writer runs the
setup algorithm, obtains and publishes the global setup
parameters pparams. The operations PrivCashKeyGen,
PrivCashMint, and PrivCashSpend of the PrivCash scheme
are defined as follows.

PrivCashKeyGen(pparams)→ (s, p): This is executed
by a user for generating the user’s private/public key
pair (s, p). The user can publish the public key p, but
needs to keep s as secret.

PrivCashMint(r, s, s, p, LedgerC, pparams)→ (c,
TXPrivCashMint): This is executed by a user (with at least
u amount of BaseCash referenced as r with the corre-
sponding secret key s) for hiding the coins that will be
spent. It takes as input the user’s private/public key
pair (s, p), the current ledger LedgerC, and the setup pa-
rameters pparams. The algorithm outputs the minted
PrivCash c and a transaction TXPrivCashMint. The user
sends the output TXPrivCashMint to the Ledger writer and
keep c as secret spending information.

PrivCashSpend(c, s, p, info, p, LedgerC, pparams) →
TXPrivCashSpend: This is executed by a user for spending
her private coin. It takes as input a previously minted
PrivCash c, the user’s private/public key pair (s, p), a
public information info the receiver BaseCash public key
p, the current ledger LedgerC, and the setup parameters
pparams. The user sends the output TXPrivCashSpend
(including info as plaintext) to the Ledger writer. As a
result, u amount of PrivCash is deducted from the user’s
balance and added to the recipient’s one as BaseCash.

Each transaction TXX also has a corresponding ver-
ification algorithm (X.Vrfy) so that the Ledger writer can
verify that they are structured correctly. The Ledger
writer also keeps a serial number database to pre-

vent double-spending. We note that each PrivCashSpend
transaction has a unique reference number r given by
the Ledger writer when it is written on the Ledger,
whereas a PrivCashMint transaction is only referenced
implicitly (by spending the minted coin by it). We
also note that in case Zerocash is used as PrivCash,
PrivCashKeyGen, PrivCashMint and PrivCashSpend cor-
respond to their CreateAddress, Mint, and Pour with
the following slight modifications for generality, respec-
tively. s of PrivCashMint is used for signing the output
transaction of Mint for verification with the related pub-
lic key in BaseCash. PrivCashSpend is adjusted so that the
output address is BaseCash public key, and p1 and info of
PrivCashSpend are written to info part of the Pour trans-
action. We assume that BaseCash tuples and PrivCash
transactions existing on a single Ledger for simplicity,
yet in reality they may be on separate ledgers (e.g., Bit-
coin and Zerocash). We assume that PrivCash satisfies
correctness, balance and non-malleability (see Appendix
B), and ledger indistinguishability (see Appendix C).

Attribute-based Signature (ABS) scheme.
For our e-donation construction we need a scheme that
enables non-interactive proving of suitability to an at-
tribute policy while keeping the signer’s identity anony-
mous (i.e., other than what the attribute policy reveals).
Attribute-based signatures (ABS) are the generic tools
that allows this. However, since we want fair distribution
of donations, our design requires the number of signa-
tures that a signer can generate in a time period to be
limited. Therefore, most of the existing ABS schemes
do not provide all features for our target in one pack-
age (see Section 5 for further discussion). Fortunately, a
recent proposal VABS [7] provides a versatile attribute-
based signature definition and construction. The versa-
tility comes from additional features on top of standard
ABS solutions: they provide decentralization, usage lim-
itation, revocation, threshold traceability, and author-
ity hiding. We utilize the anonymity, signature unforge-
ability, and signature soundness definitions in VABS [7]
for our security proofs, and provide those definitions in
Appendix D for completeness. We omit the traceability
related definitions, as the design of [7] is modular.

The system model of [7] requires a top level author-
ity (i.e., an identity provider) in each state or region for
each user to interact before joining the system. Via this
interaction, the user generates an identity token that
will be used while obtaining each of her other attribute
tokens for attribute authorities. The identity token is
also used in each of her signatures. Therefore, this would
protect against Sybil attacks or collusion. We acknowl-
edge that this requires a central authority, but we only



e-Donation 202

trust this authority, for issuing only one distinct identity
token for each user.

The setup operation takes place once in the sys-
tem setup to obtain the parameters vparams, and can
be executed as an algorithm or as a multi-party pro-
tocol. VABS.IdPJoin and VABS.AuthJoin operations are
for the identity providers and attribute authorities to
join the system. Similarly, the VABS.UserJoin opera-
tion enables a user to enter the system via interacting
with an identity provider to generate her identity to-
ken. To obtain their attribute tokens, users should run
VABS.AttrIssue with the attribute authorities. VABS.Sign
and VABS.Verify algorithms are to sign documents while
only revealing attributes and verify the given VABSs,
respectively. During verification, n-times periodic usage
limitation can be enforced. Moreover, VABS.UserRevoke
and VABS.AttrRevoke operations are provided for re-
vocation of users and their attributes by entitled au-
thorities. Here we provide the shortened descriptions of
VABS.Sign and VABS.Verify in [7]. We omit the defini-
tions of others and refer the reader to [7] for further
details related to them, as their use in our e-donation
scheme is straightforward.

VABS.Sign(m,S, β,Σβ , IAP, t, J, vparams) → σ: Be-
ing executed by a user, it takes as input a message m,
a secret key S, an attribute policy β, an attribute token
set Σβ that proves that the owner of S conforms to the
attribute policy β, the public key set IAP of the identity
providers and authorities, the time period indicator t,
a signature counter J , and the global setup parameters
params. The output of the algorithm is a VABS σ on
m. Upon execution, the user increments the counter J
for verification of his next signatures.

VABS.Verify(m,σ, β, IAP, t, SDB, vparams) → b:
Executed by a verifier, it takes as input a message m, a
VABS σ, an attribute policy β, the public key set IAP
of the identity providers and authorities, the time pe-
riod indicator t, the current signature database SDB,
and the global setup parameters vparams. The output
of the algorithm is a bit b defined as 1, if verification
succeeds. Otherwise, it is defined as 0. If the algorithm
output is 1, the signature database is updated by the
addition of σ (i.e., SDB := SDB||σ).

3 E-Donation Framework
In this section, we define the properties and security no-
tions of an e-donation scheme, along with the games re-
lated to them. Our framework requires a Ledger scheme

(as described in Section 2) that can be instantiated by
a trusted third party or a distributed system, and is
publicly available for read access. No one can directly
write on the Ledger except for the honest Ledger writer.
The Ledger is characterized as permanent, i.e., whatever
is written on it remains unalterable afterwards. The e-
donation framework is built on top of a BaseCash scheme
that makes donations worthy.

3.1 Operations

We define the e-donation operations, GlobalSetup,
IdPJoin, AuthJoin, UserJoin, RecipJoin, AttrGen, Private-
Donate, and PrivateClaim, as follows.

GlobalSetup(1λ)→ (dparams): This operation is run
by the Ledger writer at the start of the protocol. It takes
as input a unary security parameter 1Îť, and outputs
global setup parameters dparams. The Ledger writer
may also update dparams using this operation. We note
that if the Ledger writer is a distributed system (as in
blockchain), this operation might run as a multi-party
protocol where all involved parties have the same input
1Îť, and obtain dparams at the end.

IdPJoin(dparams) → (is, ip): This operation is
run by an identity provider for generation of its pri-
vate/public key pair (is, ip).

AuthJoin(dparams) → (as, ap): This operation is
run by an attribute authority for generation of its pri-
vate/public key pair (as, ap).

UserJoin(dparams) → (s, p): This operation is run
by a user (a donor or a recipient) for generation of its
private/public key pair s, p.

RecipJoin{User(uid, ip), Identity Provider(uid, is, ip)}
→ (S), (⊥): This operation is a two-party protocol be-
tween a user (a potential recipient) and an identity
provider for generating the user’s secret key S that
will be used receiving donations. The identity provider
has a secret key is, and both parties know the user
identity uid and the identity provider public key ip.
The algorithm outputs to the user the secret key S that
is tied to uid.

AttrGen{User(uid,S, ap, ω),Attribute Authority(uid,
as, ap, ω)} → (σω), (⊥): This operation is a two-party
protocol between a user and an attribute authority for
issuing the attribute token to the user. The user has a
secret S obtained from RecipJoin, the authority has a
secret key as, and both parties know the user identity
uid, the authority public key ap, and the attribute
ω that the user wishes to get approved upon. The
algorithm outputs to the user the attrib";"""date"",""2020-07-12T23:17:41Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2020-07-12T23:17:41Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is MiKTeX-pdfTeX 2.9.7439 (1.40.21)""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2020-07-12T23:17:41Z""
""created"",""2020-07-12T23:17:41Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-07-12T23:17:41Z""
""resourceName"",""popets-2020-0067.pdf""
""Author"",""""
""producer"",""MiKTeX pdfTeX-1.40.21""
""pdf:docinfo:producer"",""MiKTeX pdfTeX-1.40.21""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""4"",""38"",""0"",""1"",""0"",""0"",""0"",""8"",""1"",""0"",""2"",""6"",""0"",""0"",""0"",""0"",""14"",""12"",""2"",""14"",""3"",""2"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2020-07-12T23:17:41Z""
""Last-Modified"",""2020-07-12T23:17:41Z""
""dcterms:modified"",""2020-07-12T23:17:41Z""
""title"",""""
""Last-Save-Date"",""2020-07-12T23:17:41Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2020-07-12T23:17:41Z""
""meta:save-date"",""2020-07-12T23:17:41Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is MiKTeX-pdfTeX 2.9.7439 (1.40.21)""
""Content-Length"",""1261324""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""24""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""3908"",""2787"",""4316"",""3481"",""4078"",""4685"",""4046"",""4535"",""4059"",""3935"",""3457"",""4210"",""3772"",""4417"",""3031"",""4400"",""4843"",""3970"",""3782"",""3851"",""3866"",""3372"",""3798"",""935""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-07-12T23:17:41Z""
";https://scholar.google.ch/scholar?start=880&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098870-343;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Fast, compact, and expressive attribute-based encryption;J Tomida, Y Kawahara, R Nishimaki ; IACR International Conference on …, 2020  Springer;;"… Keywords. Attribute-based encryption Standard assumption Non-monotone Unbounded

Multi-use Random oracle model. Download conference paper PDF. 1 Introduction … One note is

that our schemes require the random oracle model for security analysis as well as FAME …";Cité 3 fois;Les 2 versions;[PDF] iacr.org;https://eprint.iacr.org/2019/966.pdf;"
Fast, Compact, and Expressive Attribute-Based Encryption

Junichi Tomida∗

NTT Corporation, Japan
Yuto Kawahara†

NTT Corporation, Japan

Ryo Nishimaki‡

NTT Corporation, Japan

Abstract

Attribute-based encryption (ABE) is an advanced cryptographic tool and useful to build various
types of access control systems. Toward the goal of making ABE more practical, we propose
key-policy (KP) and ciphertext-policy (CP) ABE schemes, which first support unbounded sizes
of attribute sets and policies with negation and multi-use of attributes, allow fast decryption,
and are adaptively secure under a standard assumption, simultaneously. Our schemes are more
expressive than previous schemes and efficient enough. To achieve the adaptive security along with
the other properties, we refine the technique introduced by Kowalczyk and Wee (Eurocrypt’19)
so that we can apply the technique more expressive ABE schemes. Furthermore, we also present
a new proof technique that allows us to remove redundant elements used in their ABE schemes.
We implement our schemes in 128-bit security level and present their benchmarks for an ordinary
personal computer and smartphones. They show that all algorithms run in one second with the
personal computer when they handle any policy or attribute set with one hundred attributes.

Keywords: attribute-based encryption; standard assumption; non-monotone; unbounded; multi-
use; random oracle model

1 Introduction

Attribute-based encryption (ABE) [18] is an advanced form of public key encryption (PKE), which
yields fine-grained access control over encrypted data. More concretely, ABE allows us to embed an
attribute x into a ciphertext when we encrypt a message. An authority that has a master secret key
can issue a secret key that is associated with a predicate y. The ciphertext can be decrypted with the
secret key only if x and y satisfy some relation R.

Previously, ABE schemes have been proposed for various relations, such as equality [10], threshold
[31], orthogonality of vectors [20], and so on. One of the most notable relations among them is that
expressed by an access structure [8,18]. In a key-policy ABE (KP-ABE) scheme, for instance, one can
embed an access structure in a secret key such as (Year:1991-2000 AND Category:jazz). The secret
key can decrypt ciphertexts that have attributes Year:1991-2000 and Category:jazz but cannot
ones that only have at most one of them. Ciphertext-policy ABE (CP-ABE) is a dual of KP-ABE and
allows us to embed an access structure into ciphertexts.

Recently, Agrawal and Chase proposed practical KP-ABE and CP-ABE schemes named FAME [1],
which are the first schemes that simultaneously:

1. have no restriction on sizes of policies and attribute sets (unboundedness);

2. allow an arbitrary string as an attribute (large universe);

∗junichi.tomida.vw@hco.ntt.co.jp
†yuto.kawahara.yk@hco.ntt.co.jp
‡ryo.nishimaki.zk@hco.ntt.co.jp

1



3. are based on the fast Type-III pairings;

4. need a small number of pairings for decryption;

5. satisfy the adaptive security under standard assumptions.

All these properties are arguably important in practice. We briefly explain the reasons. The first two
properties say about scalability. It is not uncommon that we extend a system to add new attributes
to a database in operation. In such cases, scalability is essential property because if the scheme
does not have the scalability, we need a redeployment of the scheme. The second two properties say
about efficiency. The efficiency of building blocks directly affects that of the entire system. Thus,
efficient cryptographic schemes are desirable. The final property says about security. In contrast
to the selective security, the adaptive security considers a model that captures a natural attack of
an adversary against a scheme. Additionally, standard assumptions are based on well-studied hard
problems and thus reliable. Hence, the adaptive security under standard assumptions guarantees that
schemes are secure enough.

1.1 Our Contribution

Toward the goal to make ABE schemes more usable and realistic, we propose more expressive schemes.
More precisely, we propose KP-ABE and CP-ABE schemes that satisfy all the above properties and
additionally allow us to use

6. negation in a natural form (non-monotonicity);

7. the same attribute more than once (multi-use of attributes or compactness);

in a policy. These properties allow us to use more fine-grained policies that are commonly used in
practice. Negation is essential for access control by blacklisting. Multi-use of attributes in policies is
indispensable to express certain types of policies such as (A AND B) OR (A AND C) OR (B AND
D), where A,B,C,D are Boolean variables.

Thanks to great works on ABE [3,23,29], we have several ABE schemes that can handle unbounded
sizes of attribute sets and policies in prime-order groups. To our knowledge, however, there are no
schemes that achieve all the properties listed above simultaneously. We summarize previous schemes
and ours in Table 1.

One note is that our schemes require the random oracle model for security analysis as well as
FAME. Whereas a random oracle cannot be replaced with any implemented hash function in some
particular cases [12], it is still a widely accepted and standard methodology to analyze the security of
cryptographic schemes. Actually, many practical schemes that are used in the real world require the
random oracle model for their security analysis [6, 7, 16].

In the following, we elaborate on the last two properties.

Non-monotonicity. Previously, there are several works that consider access structures including
negation (non-monotone access structures) in ABE [3,4,26,28–30,34]. Among them, only the negation
form defined by Okamoto and Takashima (OT negation) [28, 29] is different from that by the others
(non-OT negation). Considering an example is the best way to describe the difference. Let attributes
consist of a pair of a label and value, e.g., Year:1991-2000, where Year is a label and 1991-2000 is
a value. Suppose there are two labels Year and Category in an access control system supported
by KP-ABE. Then, non-OT negation is like (NOT Year:1991-2000) whereas OT negation is like
(Year:NOT 1991-2000). Semantically, the former implies that the secret key can decrypt a ciphertext
if it does not have attribute Year:1991-2000. On the other hand, the latter implies that a ciphertext
is decryptable if it has an attribute on label Year and its attribute is not 1991-2000.

When we consider large universe ABE, which is exactly the desirable case in practice, the natural
negation form is arguably OT negation. In large universe ABE, it is unreasonable to fix all attributes

2



Table 1: Comparison of unbounded KP and CP-ABE schemes based on prime-order groups.

Scheme
Unbounded-

ness
Large

universe
Type-III

Fast
Dec

Standard
assump.

Non-
monotonicity

Multi-
use

w/o
RO

OT12 [29] ✓ ✓ ✓ × ✓ ✓ × ✓
AC17 [1] ✓ ✓ ✓ ✓ ✓ × × ×
CGKW18 [14] ✓ ✓ ✓ × ✓ × × ✓
KW19 [23] ✓ ✓ ✓ × ✓ × ✓ ✓
Att19 [3] ✓ ✓ ✓ × × ×a ✓ ✓
Ours ✓ ✓ ✓ ✓b ✓ ✓ ✓ ×

a The scheme that is explicitly described by Attrapadung [3] can handle negation, but it is not the natural form that we
consider.
b The number of pairings in decryption of our schemes does not depend on the size of policies or the number of attributes
but only depends on the number of multi-use of labels in a policy. Thus, as long as considering the same setting as FAME,
which imposes one-use restriction on policies, the decryption requires only a constant number of pairings.

used in a system at the setup phase because the most significant advantage of large universe ABE is
that we can utilize an exponentially large number of attributes. Associating strings with attributes that
the ABE scheme handles in an ad-hoc way by a hash function would be a better solution. However,
if we use non-OT negation in the system, we have to fix all attributes that the system supports at
the setup phase. This is because a secret key whose policy is negation of an attribute that the system
has not supported before can decrypt all ciphertexts generated so far. More concretely, in the above
example, we consider the case where we add a new label Artist in the system. Then, if an authority
issues a key whose policy is (NOT Artist:The Beatles), all previous ciphertexts are decrypted by the
key even if the underlying content is by The Beatles because they do not have an attribute on label
Artist. On the other hand, OT negation does not cause this inconvenience because a key whose
policy is (Artist:NOT The Beatles) is useless to decrypt ciphertexts without an attribute on label
Artist. Thus, we refer to OT negation as a natural form.

Note that we can use monotone ABE as non-monotone ABE by preparing attributes for both
positive and negative if they are small-universe constructions, in which the number of attributes are
polynomially bounded. That is, non-possession of attributes can be expressed by possession of negative
attributes. However, this is not the case in large-universe constructions because we cannot attach an
exponentially large number of negative attributes to a ciphertext or secret key. Hence, monotone ABE
and non-monotone ABE are completely different things in the context of large-universe constructions.

Multi-use of attributes (Compactness). Many ABE schemes whose security relies on the dual
system methodology [32] have a one-use restriction on access structures [13, 14, 25, 28, 29]. In an
ABE scheme with the one-use restriction, one can use only policies in which all attributes appear
once. That is, one cannot embed a policy into a ciphertext or secret key such as ((Year:1991-
2000 AND Category:jazz) OR (Year:2001-2010 AND Category:jazz) OR (Year:2001-2010 AND
Artist:The Beatles)) because attributes Category:jazz and Year:2001-2010 appear twice in the
policy.

One way to circumvent this restriction is to prepare multiple nominal attributes for each single
attribute in advance like Category:jazz-1, . . . ,Category:jazz-d for Category:jazz. However, this
solution has two problems. The first is that the maximum number d of multi-use is fixed at the setup
phase. Thus, the access structures that the scheme supports are still limited. The second is that, in
KP-ABE, for instance, the solution increases the sizes of ciphertexts proportionally to the maximum
number of multi-use, and it leads to efficiency loss. This prevents the solution to set a sufficiently large
number for the limit.

On the other hand, in an ABE scheme that supports multi-use of attributes, we have no restrictions
on policies and can combine any attributes in an arbitrary way to generate a policy. In KP-ABE, for
instance, the sizes of ciphertexts are independent of policies and thus satisfies “compactness” [23].

3



1.2 Design of Our ABE Schemes

In the following, we focus on the design our KP-ABE scheme, and the CP-ABE scheme is similarly
constructed. The relation R of our ABE is close to that by Okamoto and Takashima in [29]. As we
mentioned, an attribute consists of a label and value. Our schemes are unbounded in terms of this
tuple, that is, a user can attach an arbitrary number of tuples of a label and value to a ciphertext or
secret key. A predicate is an arbitrary Boolean formula that is a combination of variables by operations
AND, OR, and NOT such as ((Year:1991-2000 AND Category:jazz) OR (Year:1991-2000 AND
Artist:NOT The Beatles)). That is, our scheme A formal definition of R is described in Definition 2.5.

Our scheme is based on the dual system encryption, which we can instantiate from either composite-
order or prime-order bilinear groups [13,27,32,33]. Our actual scheme is based on prime-order bilinear
groups following the framework by Chen et al. [13] to utilize the dual system methodology in prime-
order groups and the technique by Agrawal and Chase [1] to utilize a random oracle in asymmetric
prime-order bilinear groups. For ease of exposition, we describe the composite-order variant of our
scheme here. Let N = p1p2 for primes p1 and p2, and (G,H,GT ) be bilinear groups of order N . Let g
and h be generators of G and H, and gi and hi be generators of subgroups Gi and Hi of order pi for
i = {1, 2}, respectively. Let R : {0, 1}∗ → G1 × G1 be a hash function modeled as a random oracle,
and its input is a label. We denote the output of R(i) by (gui1 , g

hi
1 ). Then, our scheme can be written

as

pk = (g1, h1, e(g1, h1)
Îą)

ct = (hs1, {g
s(xiui+hi)
1︸ ︡︡ ︸
ct of IBE

}i∈S , e(g1, h1)sιM)

sk =

{hri1 }i∈[n],

g
ιi ¡ gri(yiuψ(i)+hψ(i))

1︸ ︡︡ ︸
sk of IBE

or
g−αi · griuψ(i)

1 ,

gyiιi ¡ grihψ(i)

1︸ ︡︡ ︸
sk of NIBE


i∈[n]

 ,

where S is the set of labels, n is the number of variables in the formula, ψ : [n]→ {0, 1}∗ is a function
that specifies the label of each variable, Îąi is a share of the secret Îą, and xi and yi are the values for
label i. Note that the reason ct and sk contain both elements in G and H is to utilize a hash function
in asymmetric groups as FAME [1].

The high-level idea of the construction is a combination of secret sharing (SS) and two-mode
identity-based encryption (TIBE) [34]. TIBE is obtained by just combining identity-based encryption
(IBE) and negation of IBE (NIBE). Our scheme can instantiate an arbitrary number of TIBE on the
fly by leveraging hash function R, and each instance corresponds to each label. A secret key of our
scheme consists of secret keys of IBE and NIBE, and each secret key hides a share Îąi of a master secret
Îą generated by SS according to the formula. A ciphertext of ABE consists of ciphertexts of IBE, which
have the same form as those in Boneh-Boyen IBE [9]. Note that ciphertexts of IBE and NIBE are
identical, and thus we do not need to include both ciphertexts of IBE and NIBE in a ciphertext of
our scheme. In decryption, one computes {e(g1, h1)sÎąi}i for labels in which the relation of (in)equality
between the ciphertext and secret keys is satisfied. Note that one cannot compute e(g1, h1)

sÎąi if the
relation of (in)equality does not hold in label i, thanks to the security of underlying TIBE. If e(g1, h1)

sÎą

is recovered via reconstruction of SS, which means that the policy in the secret key is satisfied by the
attribute in the ciphertext, one can decrypt the ciphertext of ABE. By the construction, e(g1, h1)

sÎąi

cannot be computed if a ciphertext of ABE does not contain a ciphertext of TIBE for label i, and this
property yields OT negation.

4



1.3 Our Main Technique

We can easily prove the adaptive security of our scheme from a standard assumption by the dual system
methodology and the predicate encoding framework as in [33] if ψ is injective, or the scheme has the
one-use restriction of labels in policies. However, if it is not the case, to prove the adaptive security
of the scheme from standard assumptions becomes quite difficult and had been a long-standing open
problem. Very recently, Kowalczyk and Wee brought a breakthrough for this problem (KW19) [23].
More precisely, they proposed a methodology to prove the adaptive security of the most simple ABE
scheme, which supports monotone NC1 circuits (or equivalently Boolean formulae) for a small attribute
universe. The scheme can be written in composite-order groups as

pk = (g1, h1, g
w1
1 , . . . , gwℓ1 , e(g1, h1)

Îą)

ct = (gs1, {g
swi
1 }i∈S , e(g1, h1)sιM)

sk = ({hri1 }i∈[n], {hιi ¡ h
riwψ(i)

1 }i∈[n]).

Roughly speaking, this scheme can be seen as KP-ABE whose ingredients are ElGamal-like encryption
whereas the counterpart of our scheme corresponds to TIBE.

We briefly recall the framework by KW19. Their framework follows the dual system methodology,
which is the standard technique to achieve the adaptive security. In the methodology, we change the
challenge ciphertext and secret keys into the semi-functional form. Roughly speaking, semi-functional
ciphertexts and secret keys have an additional structure in G2 and H2 as follows:

ct = (gs, {gswi}i∈S , e(g, h)sιM)

sk = ({hri1 }i∈[n], {hιi ¡ h
riwψ(i)

1 ¡ hγi2 }i∈[n]),

where Îłi is a share of a random secret Îł.
In the dual system methodology, we consider a series of hybrids where we first change the challenge

ciphertext into the semi-functional form and then the secret keys into the semi-functional form one
by one. In the latter part, the methodology allows us to focus on only one secret key by leveraging
components in G2 and H2. Therefore, to show the following indistinguishability for the adaptive choice
of ct and the one key sk is sufficient to change the target secret key into a semi-functional form:

ct : (gs2, {g
swi
2 }i∈S),

sk : ({hri2 }i∈[n], {h
riwψ(i)+ γ0,i
2 }i∈[n])

≈c

(gs2, {g

swi
2 }i∈S),

({hri2 }i∈[n], {h
riwψ(i)+ γ1,i
2 }i∈[n])


where Îł0,i is a share of secret 0 and Îł1,i is a share of secret Îł. This core component is called core
1-ABE.

The difficulty of showing the indistinguishability of core 1-ABE from a standard assumption arises
from the fact that we need to embed a computational problem into sk depending on ct. That is, if an
adversary first asks for sk, a simulator has no idea on how to embed the computational problem into
sk. Their framework tells us how to construct a series of hybrids to show the above indistinguishability.
In each transition of hybrids, the simulator guesses a part of the adversary’s output that has sufficient
information to embed the problem into sk. Simultaneously, the part must be so small that the simulator
can guess it with non-negligible probability. In our case, the part tells the correct element in sk where
the simulator embeds the problem. Observe that each Îłi is masked by ElGamal-like encryption in H2.
Thus, we can embed the DDH problem based on the guess and gradually change shares {γi}i∈[n].

At a glance, their framework seems applicable to our scheme directly, but actually, it does not work.
The main problem is the fact that whereas their framework tells us the location and its label where
we should embed the problem in sk, it does not tell us the value of the label in ct. In other words,
the difficulty of directly applying their framework to our scheme seems essentially the same as that
of proving the adaptive security of Boneh-Boyen IBE, which was proven secure only in the selective

5



setting. This problem does not occur in the scheme by KW19 because the corresponding part is just
the ElGamal-like encryption, that is, public-key encryption.

To overcome the problem, we introduce new usage of KW19 framework that allows us to utilize the
dual system methodology more beneficially. As we mentioned previously, a secret key of our scheme
contains many secret keys of TIBE based on the dual system encryption. Furthermore, the framework
tells us which secret key should be changed in each hybrid in the core 1-ABE. Thus, we can gradually
randomize the component in H2 of each element in sk by the dual system methodology instead of the
DDH problem in H2.

For simplicity, we show the case where we apply our new technique to the scheme by KW19. In
our technique, we consider the following indistinguishability of core 1-ABE:

(gs, {gswi}i∈S),

({hri1 }i∈[n], {h
riwψ(i)

1 ¡ h
Îł0,i
2 }i∈[n])

≈c

(gs, {gswi}i∈S),

({hri1 }i∈[n], {h
riwψ(i)

1 ¡ h
Îł1,i
2 }i∈[n])

 .

The difference from the original core 1-ABE is that our core 1-ABE considers both normal space
(G1 and H1) and semi-functional space (G2 and H2), whereas the original one considers only semi-
functional space. We use the dual system methodology to randomize the component in H2. Let i

∗ be
the location where γi∗ is supposed to be changed in some two hybrids, which means that i∗ ̸∈ S. Then,
from the subgroup assumption, the dual system methodology argue that (hri∗1 , h

ri∗wψ(i∗)

1 · hγi∗2 ) ≈c
(hri∗ , hri∗wψ(i∗) · hγi∗2 ). Then, we can observe that wψ(i∗) mod p2 in sk is randomly distributed in Zp2
from the Chinese remainder theorem and the fact i∗ ̸∈ S. Thus, term γi is completely hidden by term
ri∗wψ(i∗). Unlike the framework by KW19, we can apply this technique to our scheme similarly.

1.4 Other Techniques

Furthermore, we give the following technical contributions:

• reducing the number of pairings in decryption;

• reducing the number of shares of secret sharing;

• making the proof simpler;

• presenting our CP-ABE scheme.

Number of pairings. Our scheme described in Section 1.2 requires O(n) pairings in decryption.
To reduce the number, we employ the construction by Agrawal and Chase in [2]. That is, we use an
exponent rπ(i) instead of ri, where π(i) = |{j | ψ(j) = ψ(i), j ≤ i}|. In this construction, we need
O(d) pairings in decryption where d = maxπ(i) is the maximum number of multi-use of labels in the
policy. Because our scheme in prime-order groups follows the construction, it allows fast decryption
for secret keys with a small number of multi-use of labels. We show that we can prove the security of
our schemes under standard assumptions even if we use this construction. Note that the construction
by Agrawal and Chase relies on a q-type assumption.

Number of shares. In the scheme by KW19, they use a secret sharing scheme where the number
of shares corresponds to the summation of the numbers of gates and input wires when we capture a
Boolean formula as a circuit. On the other hand, our schemes employ a secret sharing scheme where
the number of shares corresponds to only the number of input wires. Their framework derives from the
technique to prove the adaptive security of secret sharing for monotone circuits by Jafargholi et al. [19],
which requires the same number of shares as in KW19. We guess that this is why their construction
employs such a secret sharing scheme. However, we show that we do not need shares for the gates in
secret sharing schemes for Boolean formulae to utilize the framework.

6



Simpler proof. Our scheme follows the technique of FAME to make our scheme unbounded by a
hash function [1]. We show that we can utilize a pseudorandom function (PRF) to significantly ease
the security proof. Concretely, we can skip the part that corresponds to Hyb0 to Hyb2,3,q in their
security proof [1, Appendix C]. Note that the additional computational cost by the modification is
quite small compared with the whole procedure of the key generation because it requires only small
numbers of PRF evaluations and multiplications in Zp for each element in a secret key.

CP-ABE scheme. We present our CP-ABE scheme and its security proof . Note that the security
proof of our CP-ABE scheme is more complicated than that of our KP-ABE scheme, because we need
two hidden spaces as in [14,17] due to a technical reason.

1.5 Implementation and Evaluation

We implement our KP and CP-ABE schemes in 128-bit security level and measure benchmarks for an
ordinary personal computer and two smartphones: iPhone XR and Pixel 3. In our schemes, a running
time of each algorithm is affected by the numbers of negation and multi-use of labels in a policy as
well as the number of attributes. To show the effects of these factors, we present benchmarks for four
types of policies that differ in the existence of negation and multi-use.

We roughly describe the running times of our schemes when we handle a policy or attribute set
with 100 attributes on a personal computer. In all cases, our KP-ABE (resp. CP-ABE) scheme takes
about 0.4 to 0.7s (resp. 0.4 to 0.9s) for encryption and key generation. Decryption is heavily affected
by a type of policy, and our schemes take only about 0.02s (KP & CP) in the fastest case and 0.5
(KP) or 0.7s (CP) even in the slowest case. Thus, we can conclude that our schemes take less than 1s
in any process and any cases with 100 attributes.

We also implement KP and CP-ABE schemes by Okamoto and Takashima (OT12), which are the
only known ABE schemes that support OT negation and the unboundedness [29]. There are no known
schemes that are as expressive as ours (see Table 1), and OT12 seems to have a closet functionality.
This is why we choose OT12 to compare. The comparison between our schemes and OT12 shows that
our schemes achieve significant speedups for each algorithm.

2 Preliminaries

2.1 Notation

For a natural number n ∈ N, [n] denotes a set {1, . . . , n}. For a set S, s ← S denotes that s is
uniformly chosen from S. For matrices with the same number of rows A1 and A2, (A1||A2) denotes
the matrix generated by their concatenation. We denote the whole space spanned by all columns of
matrix A by span(A). For a matrix A := (aj,ℓ)j,ℓ over Zp, [A]i (i ∈ {1, 2, T}) denotes a matrix over
Gi whose (j, ℓ) entry is g

aj,ℓ
i , and we apply the similar notation to vectors and scalars. We denote

([A]1, [A]2) by [A]1,2. For matrices A and B where A⊤B is defined, we abuse the pairing notation in

the following way: e([A]1, [B]2) = [A⊤B]T . A function f : N→ R is called negligible if f(λ) = λ−ω(1)

and denotes f(λ) ≤ negl(λ). For families of distributions X := {Xλ}λ∈N and Y := {Yλ}λ∈N, X ≈c Y
means that they are computationally indistinguishable.

2.2 Basic Tools

Boolean Formula and NC1. A monotone Boolean formula can be represented by a Boolean circuit
whose all gates have fan-in 2 and fan-out 1. We can specify a monotone Boolean formula f : {0, 1}n →
{0, 1} as f = (n,w, v,G), where n,m, v ∈ N and G : [v]→ {AND, OR}× [w]3. This means the Boolean
formula f has n input wires, w wires including the input wires, and v gates. We number the wires
1, . . . , w and the gates 1, . . . , v. The function G specifies a type, incoming wires, and an outgoing wire

7



of each gate. That is, for G(i) = (T, a, b, c) such that a < b < c, T specifies a type of gate i, a and
b specify the incoming wires, and c specifies the outgoing wire. A non-monotone Boolean formula
additionally contains NOT gates, which have fan-in 1 and fan-out 1. It is well-known that we can
express all non-monotone Boolean formulae by one in which all NOT gates are put on the input wires,
and we only consider such formulae in this paper. Thus, we can specify a non-monotone Boolean
formula f ′ : {0, 1}n → {0, 1} as f ′ = (f, t), where f = (n,w, v,G) is a monotone Boolean formula and
t : [n] → {0, 1} specifies input gates that connect to a NOT gate. That is, input wire i connects to a
NOT gate if t(i) = 0 and does not if t(i) = 1.

Standard complexity theory tells us that circuit complexity class NC1 and Boolean formulae are
equivalent. It is known also that NC1 is equivalent to the class captured by log-depth Boolean formulae
(see e.g., [23]). Thus, the circuit complexity class captured by Boolean formulae is equivalent to the
class captured by log-depth Boolean formulae.

Definition 2.1 (Pseudorandom Functions). A pseudorandom function (PRF) family F := {FK}K∈KΝ
with a key space KÎť, a domain XÎť, and a range YÎť is a function family that consists of functions
FK : Xλ → Yλ. Let Rλ be a set of functions consisting of all functions whose domain and range are
XÎť and YÎť respectively. For any PPT adversary A, the following condition holds,

AdvPRFA (λ) := |Pr[1← AFK(·)]− Pr[1← AR(·)]| ≤ negl(λ),

where K ← Kλ and R←Rλ.

Definition 2.2 (Bilinear Groups). A description of bilinear groups G:=(p,G1, G2, GT , g1, g2, e) consist
of a prime p, cyclic groups G1, G2, GT of order p, generators g1 and g2 of G1 and G2 respectively, and
a bilinear map e : G1 ×G2 → GT , which has two properties.

• (Bilinearity): ∀h1 ∈ G1, h2 ∈ G2, a, b ∈ Zp, e(ha1 , hb2) = e(h1, h2)
ab.

• (Non-degeneracy): For g1 and g2, gT := e(g1, g2) is a generator of GT .

A bilinear group generator GBG(1Îť) takes a security parameter 1Îť and outputs a description of bilinear
groups G with Ω(λ) bit prime. In this paper, we refer to Type-I groups, where efficient isomorphisms
exist in both way between G1 and G2, as symmetric bilinear groups, and Type-III groups, where no
efficient isomorphisms exist between them, as asymmetric bilinear groups.

For the proofs of our schemes, we utilize the Dk-MDDH assumption [15], which is generalization of
the DDH assumption. There are mainly two types of Dk-MDDH assumption families for asymmetric
bilinear groups. In the first one, an instance contains unilateral group elements such as the SXDH
assumption. The other one consists of assumptions that are involved with bilateral group elements
such as the DLIN assumption used in [1], which is sometimes called the XDLIN assumption. In our
paper, we utilize the latter type.

Definition 2.3 (Dj,k-MDDH Assumption). For j > k, let Dj,k be a matrix distribution over Zj×kp

that outputs full rank matrix with overwhelming probability. We can assume that, wlog, the first k rows
of a matrix A chosen from Dj,k form an invertible matrix. We consider the following distribution:

G← GBG(1λ), A← Dk, v← Zkp, t0 := Av, t1 ← Zjp,
Pβ := (G, [A]1,2, [tβ ]1,2).

We say that the bilateral Dj,k-MDDH assumption holds with respect to GBG if, for any PPT adversary
A,

Adv
Dj,k-MDDH
A,bi (λ) := |Pr[1← A(P0)]− Pr[1← A(P1)]| ≤ negl(λ).

We denote Dk+1,k by Dk. Let Uj,k be a uniform distribution over full rank matrices in Zj×kp . Then,
the following relations hold with tight reductions; Dk-MDDH⇒ Uk-MDDH⇒ Uj,k-MDDH.

For an appropriate distribution Dk, the Dk-MDDH assumption generically holds in k-linear groups
[15]. Thus, in asymmetric bilinear groups, we can utilize the bilateral Dk-MDDH assumption for k ≥ 2.

8



Matrix Notation. For a matrix A ∈ Dk, we define a matrix A∗ and vectors a1 and a∗1 as follows.
Vector a1 is a k+1 dimensional vector whose last entry is 1 and the others are 0. Then, it is not hard
to see that A := (A||a1) forms a basis of Zk+1

p because the first k rows of a matrix A chosen from Dk
form an invertible matrix. A∗ and a∗1 are the matrix that consists of the left k columns of (A

⊤
)−1 and

the vector that consists of right one column of (A
⊤
)−1, respectively. Note that we have A⊤A∗ = Ik,

A⊤a∗1 = 0, and A∗A⊤ + a∗1a
⊤
1 = Ik+1. We use a similar notation for a matrix B ∈ GLk+Ρ(Zp) where

Ρ ∈ N. B and bi denote a matrix consists of the first k columns of B and a vector consists of the
k+ i-th column of B, respectively. Similarly, B∗, b∗

i denote a matrix consists of the first k columns of

(B
⊤
)−1 and a vector consists of the k + i-th column of (B

⊤
)−1, respectively. For the convenience, we

denote (b1||b2) by B12, and this notation is applied to other cases similarly.

2.3 Attribute-Based Encryption

Definition 2.4 (Attribute-Based Encryption). An attribute-based encryption (ABE) scheme for re-
lation R : X × Y → {0, 1} consists of four algorithms, where X and Y are an attribute universe and
predicate universe, respectively.

Setup(1Îť): It takes a security parameter 1Îť and outputs a public key pk and a master secret key msk.
pk specifies a message spaceM.

Enc(pk, x,m): It takes pk, an attribute x ∈ X and a message m ∈M and outputs a ciphertext ctx.

KeyGen(pk,msk, y): It takes pk,msk, and a predicate y ∈ Y and outputs a secret key sky.

Dec(pk, ctx, sky): It takes pk, ctx and sky and outputs a message m′ or ⊥.

Correctness. An ABE scheme is correct if it satisfies the following condition. For all Ν ∈ N, x ∈ X ,
y ∈ Y such that R(x, y) = 1, and m ∈M, we have

Pr

m = m′

(pk,msk)← Setup(1λ)
ctx ← Enc(pk, x,m)
sky ← KeyGen(pk,msk, y)
m′ := Dec(pk, ctx, sky)

 = 1.

Security. An ABE scheme is adaptively secure if it satisfies the following condition. That is, the
advantage of A defined as follows is negligible in Îť for all stateful PPT adversary A:

AdvABEA (Îť) :=

∣∣∣∣∣∣∣∣∣∣
Pr

β = β′

β ← {0, 1}
(pk,msk)← Setup(1λ)
(x∗,m0,m1)← AKeyGen(pk,msk,·)(pk)
ctx∗ ← Enc(pk, x∗,mβ)
β′ ← AKeyGen(pk,msk,·)(ctx∗)

− 1

2

∣∣∣∣∣∣∣∣∣∣
,

where {yi}i∈[qsk] on which A queries KeyGen must satisfy R(x∗, yi) = 0.

A relation for ABE that we consider in our paper is expressed by a non-monotone Boolean formula
over the equivalence relation in Zp. More specifically, each input of the Boolean formula is decided by
whether certain componen";"""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""12"",""0"",""0"",""0"",""0"",""20"",""0"",""22"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""13"",""34"",""17"",""18"",""18"",""0"",""0"",""0"",""0"",""0"",""11"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.5""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dcterms:created"",""2020-02-12T04:25:31Z""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""Content-Length"",""910894""
""pdf:hasMarkedContent"",""false""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""meta:creation-date"",""2020-02-12T04:25:31Z""
""created"",""2020-02-12T04:25:31Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""37""
""Creation-Date"",""2020-02-12T04:25:31Z""
""resourceName"",""966.pdf""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""2472"",""3175"",""3375"",""2990"",""3113"",""2918"",""3007"",""3083"",""2548"",""2439"",""2266"",""2454"",""1871"",""1433"",""2295"",""2278"",""1348"",""2086"",""1966"",""2758"",""1274"",""1815"",""2266"",""1531"",""2708"",""1644"",""1705"",""2010"",""1595"",""1804"",""971"",""1596"",""2598"",""1584"",""2390"",""2681"",""2299""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""producer"",""dvipdfm""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""dvipdfm""
""pdf:docinfo:created"",""2020-02-12T04:25:31Z""
";https://scholar.google.ch/scholar?start=890&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098831-254;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;[PDF][PDF] ???????????? ??????????? ????????????????? ??????? ?????????? ??????? ? ???????????????? ???????? ????? ?????????? ?????????? …;?? ???????, ?? ???????? ; … ?????????????????? ??????????? …, 2020  ibm5.ru;;"… Keywords: blockchain, cryptocurrency, tokens, smart contracts, oracles, artificial intelligence … IS

Application of artificial intelligence technology and the Internet of things in the second stage of

the Almazy blockchain system (using … 5. Cryptocurrency D1 Coin-crypto diamonds …";Autres articles;;[PDF] ibm5.ru;http://ibm5.ru/uploads/s/x/p/d/xpdbpwymfmfu/file/hJOuANo4.pdf#page=182;"
     

 
 

 
 

Москва 

20 февраля 2020 года  

 

 
 

МЕЖДУНАРОДНАЯ НАУЧНО-ПРАКТИЧЕСКАЯ  

 КОНФЕРЕНЦИЯ, ПОСВЯЩЕННАЯ 25-ЛЕТИЮ КАФЕДРЫ  

 «ФИНАНСЫ» МГТУ ИМ. Н.Э. БАУМАНА  

 

«ПРИОРИТЕТНЫЕ ФИНАНСОВЫЕ ТЕХНОЛОГИИ РАЗВИТИЯ 

НАЦИОНАЛЬНЫХ ЭКОНОМИК» 

 

 



 

 
МОСКОВСКИЙ ГОСУДАРСТВЕННЫЙ ТЕХНИЧЕСКИЙ 

УНИВЕРСИТЕТ ИМЕНИ Н.Э. БАУМАНА (НАЦИОНАЛЬНЫЙ 

ИССЛЕДОВАТЕЛЬСКИЙ УНИВЕРСИТЕТ) 

 

 

 

МЕЖДУНАРОДНАЯ НАУЧНО-

ПРАКТИЧЕСКАЯ КОНФЕРЕНЦИЯ, 

ПОСВЯЩЕННАЯ 25-ЛЕТИЮ КАФЕДРЫ  

 «ФИНАНСЫ» МГТУ ИМ. Н.Э. БАУМАНА 

 

«ПРИОРИТЕТНЫЕ ФИНАНСОВЫЕ 

ТЕХНОЛОГИИ РАЗВИТИЯ НАЦИОНАЛЬНЫХ 

ЭКОНОМИК» 
 

 

 

Программа  

и материалы конференции 

 

 

20 февраля 2020 года 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Москва 

2020 Đł. 

  



Международная научно-практическая конференция посвящённая 25-летию кафедры 

«Финансы» МГТУ им. Н.Э. Баумана «Приоритетные финансовые технологии развития 

национальных экономик» Программа и материалы конференции. СПб.:  Изд-во 

 

ISBN 978-5-600-02631-5 

 

ОРГКОМИТЕТ 

 

Омельченко Ирина Николаевна – д.т.н., д.э.н., проф., руководитель НУК ИБМ  МГТУ 

им. Н.Э. Баумана (председатель); 

Соколов Евгений Васильевич – д.т.н., проф., зав. каф. «Финансы» МГТУ им. Н.Э. 

Баумана  (заместитель председателя);  

Бектенова Дамира Чотуевна – д.э.н., проф., зав. каф. «Финансы и кредит» ГОУ ВПО 

Кыргызско-Российского Славянского университета (заместитель председателя); 

Пансков Владимир Георгиевич – д.э.н., проф., заслуженный экономист Российской 

Федерации, академик РАЕН, проф. Каф. «Налогов и таможенного регулирования» Фин. 

университета при Правительстве РФ  (заместитель председателя); 

Алашкевич Юрий Давыдович -д.т.н., проф., академик РАО, проф., зав. каф. «Машин и 

аппаратов промышленных технологий» Сибирского государственного университета науки 

и технологий имени академика М.Ф. Решетнева  (заместитель председателя); 

Болвачёв Алексей Ильич – д.э.н., проф., директор ОНЦ «Финансы» (образовательный 

научный центр), РЭУ имени Г.В. Плеханова  (заместитель председателя). 

Зозуля Валентина Владимировна – д.э.н., проф. каф. «Финансы» МГТУ имени Н.Э. 

Баумана; 

Романченко Ольга Викторовна – к.т.н., доцент, замдиректора ОНЦ «Финансы» 

(образовательный научный центр), РЭУ имени Г.В. Плеханова; 

Куранов Александр Рэмович –преподаватель каф. «Финансы» МГТУ им. Н.Э. Баумана 

(ответственный секретарь); 

Костырин Евгений Вячеславович – к.э.н., доц. Каф. «Финансы» МГТУ им. Н.Э. Баумана; 

Мачина Анна Евгеньевна – ассистент, зам. зав. каф. «Финансы» МГТУ им. Н.Э. Баумана; 

Пилюгина Анна Валерьевна – к.э.н., доц. каф. «Финансы» МГТУ им. Н.Э. Баумана; 

Анищенко Павел Александрович – магистрант, МГТУ им. Н.Э. Баумана –(техническое 

обеспечение конференции) 

 

 

 

РЕДАКЦИОННАЯ ГРУППА 

Зозуля Валентина Владимировна – д.э.н., проф. каф. «Финансы» МГТУ им. Н.Э. Баумана; 

Шуркалин Александр Константинович – д.э.н., проф. каф. «Финансы» МГТУ им. Н.Э. 

Баумана; 

Романченко Ольга Викторовна – к.т.н., доц., зам. директора ОНЦ «Финансы», РЭУ им. 

Г.В. Плеханова; 

Гарипова Зайтуна Латиповна – д.э.н., проф. каф. «Финансы» МГТУ им. Н.Э. Баумана 

 

 

 

 

 

 

 

 

  



ПРОГРАММА КОНФЕРЕНЦИИ 

20 февраля 2020 г. 

 

9.00 – 10.00 Регистрация участников (Зал Учёного Совета). 

10.00-10.30 - Торжественное открытие конференции (Зал Учёного        Совета). 

10.30- 13.00  Пленарное заседание «Технологии развития финансовой системы и экономики 

России» (Зал Учёного Совета). 

13.00-14.00 Обед 

14.00-16.30  Работа по секциям: 

- Заседание секции «Приоритетные финансовые технологии развития экономики России» 

(Аудитория  514 ИБМ). 

- Круглый стол «Результаты научных исследований магистрантов, аспирантов и студентов»  

(Аудитория     ) 

17.00  – Торжественное закрытие конференции. 

 

Список докладов на конференции. 

Соколов Е.В. Прорывные технологии финансирования здравоохранения, пенсионного 

обеспечения и экономики России  

Мохов А.А. Медицинские накопительные счета: правовой взгляд  

Бектенова Д.Ч. Теоретические основы формирования рыночной финансовой системы в 

Кыргызской Республике  

Занин В.П. Защита фундаментальных жизненных интересов населения России изменением 

валютной политики  

Занин В.П. О вариантах повышения роли народовластия в системе здравоохранения 

РОссии 

Шуркалин А.К., Глущенко Е.И. Палладий на рынке драгоценных металлов 

Останин В.А. Инвестиционная политика Китая и России на территориях ускоренного 

развития: сравнительный анализ  

Филькевич И.А., Рахматулина Г.Г. Новые стратегические подходы к развитию 

экономического партнерства в рамках Евразийского экономического союза: проблемы 

конкурентоспособности  

Аврамчикова Н.Т., Рожнов И.П., Монгуш С.П., Захарова Л.Н. Концептуальная основа 

пространственно социально-экономического развития взаимодействующих регионов (на 

примере регионов СФО)  

Зозуля В.В., Аль Хадж К.А., Маан С.В. Финансовые технологии в четвертой 

промышленной революции  

Бобылева А.З. Роль института банкротства в обеспечении устойчивости экономики России  

Зозуля В.В., Юнда П.Н. Инвестиционная деятельность России и Китая в современных 

условиях: перспективы её развития  

Костырин Е.В., Амбросенкова А.С., Глущенко Е.И., Краева А.А. Экономико-

математические модели факторного анализа стоимости медицинского бизнеса  

Филькевич И.А. Оценка влияния фактических и потенциальных взаимных эффектов от 

шоков и изменений в политике ЕАЭС  

Медведев С.О. Развитие кластерных структур в лесной отрасли: организационно-

экономический и ресурсный аспекты  

Данилов Д.Д. Оптимизация финансового положения приходов русской православной 

церкви, находящихся на территории российской федерации  

Измайлов Р.Н. Модель расчета заработанной платы в зависимости от результата работы и 

стоимости рабочего места  

Журавлева И.А., Левошич Н.В. Концептуальные взгляды Маркса и философские основы 

совершенствования налоговой системы  

Бадалова А.Г., Ларионов В.Г. Методы оценки и анализа рисков нефинансовых 

организаций  



Романченко О.В., Леонова Е.М., Толкунова Е.В. Развитие рынка ипотечного 

кредитования и ипотечных ценных бумаг в условиях экономической нестабильности  

Селюков В.К., Горюнова И.С.  Исследование возможности совершенствования системы 

управления рисками в алмазодобывающей компании путём применения технологий 

цифровизации  

Бондаренко Т.Г. P2P-Кредитование как финансовая технология будущего  

Пилюгина А.В., Ласунова С.В. Ответственное инвестирование: подходы к учету ESG-

факторов  

Ивакова З.А. Практика стимулирования иностранных инвестиций  

Васюткина Л.В., Протопопов Д.В. Модель управления платными услугами поликлиник  

Селюков В.К., Ван Юйяо Управления финансовыми рисками китайской компания GREE  

Руднев К.В. Перспективы развития основных механизмов привлечения иностранных 

инвестиций в экономику России на Дальнем Востоке  

Савяк Н.Н. Приоритетные финансовые технологии: Российский опыт и перспективы 

развития  

Кирова Е.А., Леоненко К.А. Направления развития учета расчетов по налогу на прибыль 

в организациях оптовой IT-дистрибуции  

Зозуля В.В., Германов М.Г., Серебренников Д.А. Лизинг как форма инвестирования в 

развитие экономики для машиностроительной промышленности  

Костенко В.Б., Гнедько А.Г., Корчагин И.П. Факторный анализ как инструмент системы 

управления финансами предприятия: проблемы и перспективы  

Юсуфова О.М., Бадюк А.А., Галактионова В.А. Анализ привлекательности рынка 

виртуальной реальности для инвесторов  

Васюткина Л.В., Жамкова И.М., Потапова К.М., Ковалевский Н.О. Мировые 

инвестиции: проблемы и пути развития  

Шнюкова Е.А., Редкоус М.А. Влияние структуры инвестиционного портфеля ценных 

бумаг на экономическую безопасность коммерческого банка  

Долгова И.В., Мохов И.А., Мохова С.С., Урумова Ф.М., Шкарпетина Е.В. Венчурный 

капитал как технология привлечения финансовых ресурсов на инновации для развития 

экономики России 

Куликова Е.В., Васюткина Л.В., Соколова Е.А. Оценка влияния инвестиций в развитие 

производства на результаты деятельности предприятия  

Роземан Э.А. Новые тенденции в глобализации, цифровой трансформации и человеческий 

капитал  

Виногоров Г.Г. Проблемы методики анализа рентабельности работы майнинг-фермы  

Мачина А.Е. Экономико-математическая модель управления финансовым результатом 

предприятия по производству древесных топливных гранул  

Баланцев А.Б., Туркичева А.И. Ипотечное кредитование как инструмент решения 

жилищного вопроса: оценка величины переплаты и выбор финансового партнера в 

современных условиях 

Романов А.А. Модель управления потоком посетителей торгового предприятия 

электронной коммерции в зависимости от расходов по видам рекламных кампаний  

Маврина Л.А. Проблемы финансирования пенсионных систем  

Цобор Л.В. Специфические механизмы налогового регулирования в условиях 

экономической изоляции  

Саханов В.В. Репликации индекса ММВБ дивидендными бумагами  

Зозуля И.В. Финансирование инноваций как условие формирования 

высокопроизводительных рабочих мест в лесном секторе экономики  

Феденкова М.В. Финансовый контроль над экологичностью бизнеса  

Вандышева И.Н., Петровнина А.М. Влияние АI-технологий на развитие маркетинга в 

России и за рубежом  

Червяков Д.В., Долбилкин А.В. Уровень финансовой грамотности и его влияние  

Ваняшкина А.Ю., Пахомова О.О. Факторинг как фактор устойчивого развития 

предприятий мсб (малого и среднего бизнеса) в Российской Федерации  



УДК 338.32.57  
 

 

 

Прорывные технологии финансирования здравоохранения, 

пенсионного обеспечения и экономики России. 
Breakthrough technologies for financing healthcare, pensions and the Russian 

economy. 
 

 

 

Е. В. СОКОЛОВ,  

доктор технических наук, профессор, заведующий  

кафедрой ИБМ5 «Финансы», Московский государственный  

технический университет им. Н. Э. Баумана,  

Москва, Российская Федерация  

E-mail: ibm5-moskwa@rambler.ru  

 

 

 

Аннотация. 

В статье показано, что существующая система финансирования здравоохранения и 

пенсионного обеспечения принуждает работающих граждан и работодателей уходить в 

«тень» и что при такой тенденции финансирование здравоохранения и пенсионного 

обеспечения будет уменьшаться.  

Предложен механизм, позволяющий мотивировать работающих граждан к 

высокопроизводительному труду и заботе о своем здоровье, существенно сократить 

расходы федерального и территориальных бюджетов на здравоохранение и пенсионное 

обеспечение, накопить огромные долгосрочные финансовые ресурсы для роста экономики 

России и повышения уровня жизни ее граждан.  

Ключевые слова: производительность труда, финансирование здравоохранения, 

медицинские накопительные счета (МНС), пенсия.  

 

Annotation. 

The article shows that the existing system financing of healthcare and pensions forces working 

citizens and employers to go into ÂŤthe shadowsÂť and that with such a tendency financing of 

healthcare and pensions will decrease.  

Proposed a mechanism to motivate working citizens to high-performance work and care for 

their health, significantly reduce the costs of federal and territorial budgets for healthcare and 

pensions, accumulate enormous long-term financial resources for the growth of the Russian 

economy and improve the living standards of its citizens.  

Keywords: performance work, financing of healthcare, medical savings accounts (MSA), 

pension. 

 

 

 

 Все товары, работы и услуги в любом государстве производят и оказывают на 

предприятиях работающие граждане, и бюджеты всех уровней тоже наполняются ими, 

поэтому главная, прорывная, задача экономики России заключается в мотивации 

работающих граждан к высокоэффективному труду, но для этого необходимо, чтобы 

социальные отчисления (а это 30% от заработной платы) шли не в фонд обязательного 

медицинского страхования и пенсионный фонд, а на медицинские накопительные счета 

(МНС) и персонифицированные пенсионные счета работающих граждан в банках. Важно, 

mailto:ibm5-moskwa@rambler.ru


чтобы на эти счета начислялись проценты, а средства сверх неснижаемого остатка, 

необходимого на дожитие после выхода на пенсию, гражданин мог использовать по своему 

усмотрению (покупка жилья, образование, перевод на пенсионные накопления, передача по 

наследству).  В наших расчётах возраст дожития равен 20 годам, хотя в настоящее время, 

особенно после изменения пенсионного возраста, это 7 лет (72-65) для мужчин и 12 лет (72-

60) для женщин. Средний по России неснижаемый остаток составляет 600 000-700 000 

рублей. Очевидно, что 600 000 руб. на 20 лет это 30 000 руб. в год, однако в настоящее 

время это всего 12 734 руб. в 2,4 раза меньше. 

      Следует отметить, что по данным официального интернет-ресурса Федеральной службы 

государственной статистики в июне 2018 года средняя заработная плата в России 

составляла 45 848 руб. Соответственно, средние годовые отчисления в Федеральный фонд 

обязательного медицинского страхования (ФФОМС) на одного работающего составят  

45 848 ∙ 0,051 ∙ 12 = 28 059 руб., фактически же в среднем по России до каждого 

работающего доходит 12 734 руб. [2]. В 2,2 раза меньше.  

     Существующая ситуация  с перечислениями в Пенсионный фонд также не мотивирует 

работающих граждан к высокопроизводительному труду, так как накопительная часть 

пенсии заморожена с 2014 года. Размер страховой пенсии, которую будет получать 

работающий гражданин, до сих пор чётко не определён (пресловутый индивидуальный 

пенсионный коэффициент). В случае смерти пенсионера (допустим, через год после выхода 

на пенсию) его страховая пенсия, которую он всю свою трудовую деятельность кому-то 

перечислял примерно 40 лет, не передаётся по наследству, и, следовательно, не может 

улучшить благосостояние его семьи. Важно отметить, что Пенсионный фонд был создан в 

1990 году (прошло почти 30 лет), но ситуация с пенсиями не улучшается. Средняя 

пенсия по России в 2018 году (13 323 руб.) лишь немного превышает прожиточный 

минимум (11 280 руб.). 

Поскольку отчисления в Фонд обязательного медицинского страхования и в 

Пенсионный фонд практически не доходят до работающих граждан, то примерно 29 млн 

или вообще ничего не переводят в социальные фонды, или трудятся в «серую»  

(официально получают минимальную заработную плату, а остальное – в конвертах), что 

позволяет им положить «серые» деньги в банк, купить недвижимость и тем самым обе-

спечить себе достойную старость. При этом они получают такое же медицинское 

обслуживание, как и все граждане России, и получают такую же пенсию. Надо 

подчеркнуть, что «серая» зарплата выгодна и для работодателей, поскольку 

существенно сокращается объем социальных отчислений. Из вышеизложенного следует 

сделать вывод, что существующая система финансирования здравоохранения и 

пенсионного обеспечения не эффективна и принуждает работающих и работодателей 

уходить в тень.  

      При такой тенденции роста работающих граждан, ничего не перечисляющих или полу-

чающих «серую» зарплату, финансирование медицинского и пенсионного обеспечения 

граждан, вышедших на пенсию и будущих пенсионеров, будет только уменьшаться.  

     Финансирование здравоохранения на основе медицинских накопительных счетов (МНС) 

впервые было предложено в США в 1970-х годах. Сингапур освободившись от 

колониальной зависимости (1965 г.) и изучив все существующие системы здравоохране-

ния в 1984 году начал целенаправленно внедрять МНС. Основное фундаментальное 

отличие использования МНС заключается в том, что социальные отчисления, которые 

делают работодатели (предприятия) направляются не в общий фонд и потом распреде-

ляются между работающими гражданами, а сразу (без посредников) на персональные МНС 

работающих на этих предприятиях граждан (табл 1). 

 

 

 

 

 

 



Таблица 1 

Процент отчислений с заработной платы в центральный резервный фонд и их 

распределение по счетам в зависимости от возраста 

Возрас

т 

(годы) 

Распределение отчислений 

Работодател

ь 

(% от ЗП)  

Работни

Đş 

(%от ЗП) 

 

Всег

Đž 

(%от 

ЗП) 

 

Обычный 

сберегательны

й счет (жилье, 

образование, 

инвестиции), 

OA 

(%от ЗП) 

Спец.счет 

(пенсионный)

, SA 

(%от ЗП) 

Медицински

й счет 

Medisave, MA 

(%от ЗП) 

1 2 3 4 5 6 7 

35 и 

ниМо 

17 20 37 23 6 8 

36-45 17 20 37 21 7 9 

46-50 17 20 37 19 8 10 

51-55 17 20 37 15 11.5 10.5 

56-60 13 13 26 12 3.5 10.5 

61-65 9 7.5 16.5 3.5 2.5 10.5 

>65 7.5 5 12.5 1 1 10.5 

 

Такой подход мотивирует работающих граждан к росту произво-дительности труда 

(лучше работаешь – больше заработная плата, а следовательно, больше средств на твоё 

медицинское обслуживание) и заботе о своём здоровье (не болеешь – средства на МНС 

накапливаются), быть здоровым выгодно [2]. За короткий промежуток времени, 

прошедший с момента обретения независимости (1965 год), Сингапур не только достиг 

высоких темпов роста ВВП, но и добился впечатляющих достижений в области 

здравоохранения. Коэффициент младенческой смертности, который в 1960 году превышал 

35 смертей на 1000 рожденных, снизился до 2,1 к 2007 году и остается на таком же низком 

уровне и сейчас. Примечательно и то, что Сингапур добился этого, потратив существенно 

меньше средств на здравоохранение по сравнению с почти любой другой развитой страной. 

Сингапур последовательно тратит менее 3% своего ВВП на здравоохранение, тогда как в 

2014 году Япония  потратила 8,6%, Финляндия –  7,3%, Швейцария – 7,7%, Франция – 9%, 

Швеция –  10%, США – 16%. Высвободившиеся средства пошли на улучшение жилья, 

очистку воды, улучшение санитарии, образование, улучшение питания и профилактику 

СайОНованиК. 

    В Китае МНС в качестве пилотного проекта начали внедрять в 1994 г. в двух городах 

Чженьцзяне и Цзюцзяне общей численностью 5 млн. человек.  А с 1998 г. система была 

распространена на всю территорию страны решением Госсовета КНР «О создании системы 

базового медицинского страхования работников в городской местности». Вопрос об 

участии в данной системе самозанятого населения решается на уровне муниципалитетов. В 

настоящее время примерно 300 млн. городского населения Китая имеют МНС.  Введение 

МНС в Китае резко повысило эффективность финансирования здравоохранения. Уже к 



2001 г. удалось устранить дефицит средств направляемых на здравоохранение. А к 2016 г. 

уже профицит составил 324 миллиарда юаней (50,5 миллиарда долларов). 

     В США для финансирования медицинского обслуживания используется пять различных 

подходов [4]. Наибольшее распространение (49% охвата населения) получила система 

Добровольного медицинского страхования (ДМС), которую оплачивает работодатель. Но 

наиболее динамично развивается подход основанный на МНС. Ежегодный прирост МНС 

составляет 11%, и им пользуются примерно 25 млн. граждан.  

      На кафедре «Финансы» МГТУ им. Н. Э. Баумана с использованием опыта Сингапура, 

США, Китая и ЮАР разработаны технологии финансирования здравоохранения, в 

соответствии с которыми предприятия перечисляют социальные платежи не в ФФОМС, а 

на размеŃ";"""date"",""2020-02-13T17:31:47Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""1"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.7""
""xmp:CreatorTool"",""MicrosoftÂŽ Word 2016""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dc:creator"",""User""
""language"",""ru""
""dcterms:created"",""2020-02-13T17:31:47Z""
""Last-Modified"",""2020-02-13T17:31:47Z""
""dcterms:modified"",""2020-02-13T17:31:47Z""
""dc:format"",""application/pdf; version=1.7""
""xmpMM:DocumentID"",""uuid:5C1EC95E-55DC-40D2-B249-882671B1E64C""
""Last-Save-Date"",""2020-02-13T17:31:47Z""
""pdf:docinfo:creator_tool"",""MicrosoftÂŽ Word 2016""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2020-02-13T17:31:47Z""
""meta:save-date"",""2020-02-13T17:31:47Z""
""pdf:encrypted"",""false""
""xmp:CreateDate"",""2020-02-13T20:31:47Z""
""modified"",""2020-02-13T17:31:47Z""
""Content-Length"",""3995416""
""pdf:hasMarkedContent"",""false""
""Content-Type"",""application/pdf""
""xmp:ModifyDate"",""2020-02-13T20:31:47Z""
""pdf:docinfo:creator"",""User""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""User""
""dc:language"",""ru-RU""
""meta:author"",""User""
""pdf:producer"",""MicrosoftÂŽ Word 2016""
""meta:creation-date"",""2020-02-13T17:31:47Z""
""created"",""2020-02-13T17:31:47Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""381""
""Creation-Date"",""2020-02-13T17:31:47Z""
""resourceName"",""hJOuANo4.pdf""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""223"",""393"",""2307"",""2740"",""3326"",""2407"",""3666"",""2309"",""2949"",""1716"",""3950"",""1750"",""2438"",""3181"",""3379"",""3644"",""3709"",""3388"",""1286"",""3325"",""3488"",""3587"",""3735"",""3358"",""3268"",""2054"",""1944"",""2460"",""3854"",""3579"",""3846"",""3768"",""3772"",""2653"",""5"",""1283"",""408"",""906"",""1189"",""129"",""2650"",""3787"",""3607"",""3486"",""3682"",""2980"",""2424"",""3806"",""3893"",""3939"",""4095"",""2890"",""3100"",""4060"",""3682"",""4163"",""3850"",""3888"",""1726"",""2647"",""3733"",""2531"",""3757"",""3724"",""3759"",""3366"",""2791"",""3353"",""3593"",""3251"",""2055"",""1875"",""2364"",""3123"",""4178"",""3607"",""3598"",""3600"",""3974"",""1828"",""3813"",""4025"",""3617"",""3427"",""2817"",""2800"",""4098"",""3655"",""3755"",""3504"",""2131"",""1857"",""3761"",""3595"",""1907"",""1567"",""3438"",""2538"",""1989"",""2239"",""2534"",""3954"",""3953"",""3436"",""3666"",""3898"",""2999"",""3674"",""2661"",""2849"",""3074"",""3241"",""2613"",""2477"",""2572"",""2945"",""2546"",""2484"",""2560"",""2073"",""3111"",""2902"",""3500"",""1440"",""3244"",""3721"",""3499"",""4045"",""3483"",""3823"",""335"",""2876"",""3573"",""4114"",""2087"",""2438"",""3445"",""3193"",""535"",""2817"",""3734"",""3493"",""3719"",""3596"",""3190"",""3303"",""2983"",""3743"",""2580"",""2346"",""2053"",""3089"",""2136"",""3541"",""4150"",""2622"",""2202"",""2140"",""1772"",""2221"",""1463"",""2324"",""3272"",""2226"",""2421"",""3476"",""904"",""2147"",""2106"",""334"",""2615"",""1941"",""1672"",""401"",""3043"",""320"",""2920"",""2628"",""4143"",""4140"",""2278"",""2580"",""3031"",""2556"",""3894"",""1544"",""2858"",""2665"",""2025"",""2875"",""2740"",""3251"",""3469"",""3901"",""1771"",""2418"",""4111"",""3882"",""3795"",""4038"",""3805"",""3493"",""1103"",""3524"",""3954"",""3445"",""3555"",""3268"",""4"",""1877"",""2352"",""2568"",""3706"",""976"",""2605"",""2434"",""1591"",""2217"",""1144"",""2035"",""2867"",""3969"",""3341"",""3678"",""3537"",""3434"",""3616"",""3336"",""3413"",""3638"",""2859"",""1856"",""3352"",""3283"",""3877"",""3645"",""2165"",""2725"",""2885"",""2288"",""2614"",""3163"",""2585"",""3728"",""3642"",""1300"",""1791"",""2292"",""2552"",""1003"",""1307"",""1738"",""2128"",""2191"",""2672"",""2084"",""2068"",""2910"",""2579"",""3045"",""1495"",""1614"",""3730"",""2954"",""1630"",""2270"",""3637"",""752"",""2592"",""3647"",""2621"",""3502"",""3199"",""3452"",""3160"",""1701"",""2858"",""597"",""2171"",""3540"",""3682"",""3679"",""3306"",""4176"",""2965"",""3709"",""3586"",""2311"",""2808"",""3536"",""2873"",""1964"",""2462"",""1201"",""2884"",""2574"",""2522"",""1793"",""1755"",""3210"",""3879"",""2047"",""3263"",""2821"",""1991"",""1685"",""3127"",""3750"",""309"",""3308"",""2802"",""3594"",""2980"",""649"",""2436"",""3047"",""3426"",""2131"",""2095"",""1902"",""1291"",""1979"",""3259"",""3615"",""3286"",""3220"",""3682"",""1931"",""1232"",""2307"",""2494"",""2328"",""1447"",""2544"",""3605"",""4122"",""4015"",""2901"",""2300"",""3210"",""3955"",""4038"",""3762"",""3493"",""418"",""3100"",""538"",""258"",""3318"",""4106"",""3387"",""260"",""2997"",""2722"",""2627"",""1238"",""3323"",""1363"",""2519"",""2722"",""3480"",""3593"",""3634"",""3599"",""734"",""2818"",""3708"",""2300"",""2953"",""2092"",""2173"",""2342"",""3185"",""3514"",""2669"",""3196"",""3575"",""3506"",""1576"",""3444"",""1850""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""Author"",""User""
""producer"",""MicrosoftÂŽ Word 2016""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""MicrosoftÂŽ Word 2016""
""pdf:docinfo:created"",""2020-02-13T17:31:47Z""
";https://scholar.google.ch/scholar?start=800&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098756-88;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;POTENCIJAL PRIMJENE BLOCKCHAIN TEHNOLOGIJE U RA?UNOVODSTVU;A Ževrnja ;2020 zir.nsk.hr;;"… POTENCIJAL PRIMJENE BLOCKCHAIN TEHNOLOGIJE U RA?UNOVODSTVU Mentor … Mnogi

start-upovi su po?eli koristiti blockchain tehnologiju za pohranjivanje osjetljivih informacija, s

obzirom na to da je blockchain tehnologija otpornija na „curenje“ informacija, za …";Autres articles;;[PDF] nsk.hr;https://zir.nsk.hr/islandora/object/efst:3264/datastream/PDF/download;"
  
    Skip to main content
  

    




    

        
        
            
            
                        
                
                
                    
                          
    

    
  
    	English


  





    
  
    	Početna
	Za studente
	Za ustanove
	O ZIR-u
	Etičnost	Znanstvena čestitost
	Etički kodeksi
	Video


	Kontakt
	Upute i priručnici

  



  

                    

                

                
            

                        
                        
            

        

        

    



    



    
        
        
        
            
            
                
                    
                    

                    
                                        

                                        
                    Nacionalni repozitorij zavrĹĄnih i diplomskih radova ZIR
                    

                                        
                                        
                    Nacionalna i sveučilišna knjižnica u Zagrebu                    

                    
                    

                    
                      

                    

                    
                

                
                
                    
                    

                        
                        
                             
                                                                  
    

    
  
    	[image: ] Pregledavanje	Prema godini
	Prema autoru
	Prema ustanovi
	Prema području
	Prema vrsti rada
	Prema repozitorijima
	Svih dokumenata


	[image: ] Napredno pretraĹživanje
	[image: ] Pohranjivanje

  





    
  
    
  Search Term 
 



 ovaj repozitorij
sve repozitorije u Dabru









  



  

                                                            
                        

                        

                    

                                            
                

         
            

        

        

    









    
        

    
    
    
        

            

                                
                    
                    
                      
    

    
  
    [image: Digitalni akademski arhivi i repozitoriji]  





    
  
    [image: ]

  





    
  
    [image: ]

  





    Statistika

  
  
    [image: ]


Ukupan broj objekata
:total
Postotak objekata u otvorenom pristupu
:open access percent
Statistika posjećenosti
Statistika objava


  



  

                    
                    
                
                
                

                    
                                        

                    
                    

                                                                        
                        
                                                    
                                                        

                                                

                        
                        
                                                

                         
                          
    

    
  
    



[image: prikaz prve stranice dokumenta POTENCIJAL PRIMJENE BLOCKCHAIN TEHNOLOGIJE U RAČUNOVODSTVU]
Pristup korisnicima matične ustanove



diplomski rad

																Kontakt
																	 Urednik repozitorija


															


POTENCIJAL PRIMJENE BLOCKCHAIN TEHNOLOGIJE U RAČUNOVODSTVU
diplomski rad
Split: Sveučilište u Splitu, Ekonomski fakultet, 2020. urn:nbn:hr:124:580036


Ževrnja, Anita
Sveučilište u Splitu
Ekonomski fakultet



Citirajte ovaj rad


APA 6th EditionŽevrnja, A. (2020). POTENCIJAL PRIMJENE BLOCKCHAIN TEHNOLOGIJE U RAČUNOVODSTVU : diplomski rad (Diplomski rad). Preuzeto s https://urn.nsk.hr/urn:nbn:hr:124:580036

MLA 8th EditionŽevrnja, Anita. ""POTENCIJAL PRIMJENE BLOCKCHAIN TEHNOLOGIJE U RAČUNOVODSTVU : diplomski rad."" Diplomski rad, Sveučilište u Splitu, Ekonomski fakultet, 2020. https://urn.nsk.hr/urn:nbn:hr:124:580036

Chicago 17th EditionŽevrnja, Anita. ""POTENCIJAL PRIMJENE BLOCKCHAIN TEHNOLOGIJE U RAČUNOVODSTVU : diplomski rad."" Diplomski rad, Sveučilište u Splitu, Ekonomski fakultet, 2020. https://urn.nsk.hr/urn:nbn:hr:124:580036

HarvardŽevrnja, A. (2020). 'POTENCIJAL PRIMJENE BLOCKCHAIN TEHNOLOGIJE U RAČUNOVODSTVU : diplomski rad', Diplomski rad, Sveučilište u Splitu, Ekonomski fakultet, citirano: 28.04.2021., https://urn.nsk.hr/urn:nbn:hr:124:580036

VancouverŽevrnja A. POTENCIJAL PRIMJENE BLOCKCHAIN TEHNOLOGIJE U RAČUNOVODSTVU : diplomski rad [Diplomski rad]. Split: Sveučilište u Splitu, Ekonomski fakultet; 2020 [pristupljeno 28.04.2021.] Dostupno na: https://urn.nsk.hr/urn:nbn:hr:124:580036

IEEEA. Ževrnja, ""POTENCIJAL PRIMJENE BLOCKCHAIN TEHNOLOGIJE U RAČUNOVODSTVU : diplomski rad"", Diplomski rad, Sveučilište u Splitu, Ekonomski fakultet, Split, 2020. Dostupno na: https://urn.nsk.hr/urn:nbn:hr:124:580036



Za citiranje koristite ovu mreĹžnu adresu: https://urn.nsk.hr/urn:nbn:hr:124:580036

[image: ]
[image: ]
[image: ]
[image: ]
[image: ]
[image: ]



Prijavite se u repozitorij kako biste mogli spremiti objekt u svoju listu.
Podaci o radu	Naslov	POTENCIJAL PRIMJENE BLOCKCHAIN TEHNOLOGIJE U RAČUNOVODSTVU : diplomski rad
	Autor	Anita Ževrnja
	Mentor	Marko Čular (mentor)
	Ustanova koja je dodijelila
akademski / stručni stupanj	Sveučilište u Splitu
Ekonomski fakultet
Split
	Datum i drĹžava obrane	2020-05, Hrvatska
	Znanstveno / umjetničko
područje, polje i grana	DRUŠTVENE ZNANOSTI
Ekonomija
Računovodstvo
	Sažetak	U ovom radu se analizira blockchain tehnologija, koja bi mogla postati inherentan dio računovodstvene industrije - informacije u bazi podataka su pouzdane i istinite, bez obzira na povjerenje druge ugovorne strane. Transakcija se događa samo ako su je odobrili svi sudionici. Uz pomoć distribuirane knjige koja je svima dostupna podaci se mogu prevesti u siguran, transparentan i jednostavan oblik koji je spreman za korištenje. Uvođenje tehnologije u računovodstvo ima sljedeće prednosti: mrežne transakcije su brze i jednostavne, računi se mogu ažurirati pomoću aplikacija, optički sustavi za prepoznavanje podataka omogućuju automatizaciju cijelog postupka, počevši od uvođenja primarnih dokumenata. U trenutku nastanka rada, najveći nedostaci tehnologije su sigurnost, nedostatak zakonskih regulativa i nedovoljna prilagođenost korisnicima. Blockchain bi mogao promijeniti tradicionalne metode naplate, dokumentiranja, obrade, registracije, sustava inventara i plaćanja poslovanja. Tehnologija će omogućiti poduzećima da istovremeno zabilježe obje strane transakcije u zajedničkoj knjizi u stvarnom vremenu, umjesto da vode revidirane zapise o financijskim transakcijama u zasebnim bazama podataka ili knjigovodstvenim knjigama. Blockchain uvelike pojednostavljuje međunarodne transakcije za mala poduzeća i pojednostavljuje postupak nabave, jer omogućava sigurno snimanje transakcija i poboljšava operativnu učinkovitost. Svi računovodstveni dokumenti i zapisi bili bi šifrirani u sigurnom obliku, što bi praktično onemogućilo brisanje unosa ili manipuliranje podacima te bi olakšalo proces revizije. Primjena tehnoloških mogućnosti u računovodstvenoj industriji mijenja oblik njegove organizacije, povećava razinu profesionalne kompetencije i odgovornosti osoblja, prikazuje sustav informacijske podrške na kvalitativno novom nivou transparentnosti, sigurnosti, učinkovitosti.

	SaĹžetak (engleski)	This paper analyses blockchain technology, which could become an inherent part of the accounting industry - the information in the database is reliable and true, regardless of the trust of the other party. The transaction only happens if it has been approved by all participants. With the help of a distributed ledger that is accessible to everyone, data can be translated into a safe, transparent and easy-to-use format. The introduction of technology into accounting has the following advantages: online transactions are fast and easy, accounts can be updated using applications, and optical data recognition systems allow the entire process to be automated, starting with the introduction of primary documents. At the time of writing this thesis, the major drawbacks of the technology were security, lack of legal regulations and lack of user-friendliness. Blockchain could change the traditional methods of billing, documenting, processing, registering, inventory systems and business payment. The technology will allow companies to record both sides of a transaction in a joint ledger at the same time, rather than keeping audited financial transaction records in separate databases or ledgers. Blockchain greatly simplifies international transactions for small businesses and streamlines the procurement process, as it enables secure transaction recording and improves operational efficiency. All accounting documents and records would be encrypted in a secure format, making it virtually impossible to delete entries or manipulate data and to facilitate the audit process. The application of technological capabilities in the accounting industry changes the form of its organization, increases the level of professional competence and responsibility of staff, shows the information support system at a qualitatively new level of transparency, security, efficiency.

	Ključne riječi	
				
					
						Blockchain tehnologija
					
						Pretraži slične


				

			
				
					
						računovodstvena industrija
					
						Pretraži slične


				

			
				
					
						trojno računovodstvo
					
						Pretraži slične


				

			
	Ključne riječi (engleski)	
				
					
						Blockchain technology
					
						Pretraži slične


				

			
				
					
						accounting industry
					
						Pretraži slične


				

			
				
					
						triple-entry accounting
					
						Pretraži slične


				

			
	Jezik	hrvatski
	URN:NBN	urn:nbn:hr:124:580036
	Studijski program	Naziv: Poslovna ekonomija
Vrsta studija: sveučilišni
Stupanj studija: diplomski
Akademski / stručni naziv: magistar/magistra ekonomije (mag. oec.)
	Vrsta resursa	Tekst
	Način izrade datoteke	Izvorno digitalna
	Prava pristupa	Pristup korisnicima matične ustanove
	Uvjeti korištenja	[image: Ikona licence Zaštićeno autorskim pravom.]
	Repozitorij	REFST
	Datum i vrijeme pohrane	2020-05-27 09:54:15





  



  

                                                
                    

                    

                

                                
            


        

    

    









    

        
                        
                
                  
    

    Nacionalna i sveučilišna knjižnica u Zagrebu

  
  
    	„Pa ćutim, ja i moj otac mi smo jedno…“ – u spomen na Vjekoslava Majera

	Održana jubilarna Noć knjige

	Posjet predsjednika Vlade Republike Hrvatske Zbirci rukopisa i starih knjiga

	Dan hrvatske knjige u znaku 500. obljetnice tiskanja Judite

	Virtualna izložba „Automobili u Hrvatskoj“



ViĹĄe
  



  

                

            

                  

                  
            
                
                  
    

    Dabar

  
  
    	U Dabru implementirana podrĹĄka za izradu Virtualnih zbirki

	Prvi repozitorij iz Dabra u katalogu podatkovnih repozitorija Re3Data

	Dabar u EBSCO Discovery servisu

	Implementirana je funkcionalnost srediĹĄnjeg pretraĹživanja svih repozitorija u Dabru



ViĹĄe
  



  

                

            

            
            
                    


    

 



	
		
		
		
            
    			
                    
                                        
    			

    			
                    
                                        
                      
    

    
  
    (©) Nacionalna i sveučilišna knjižnica u Zagrebu 2015. Sva prava pridržana. | Hrvatske bratske zajednice 4 p.p. 550, 10000 Zagreb, Hrvatska Tel. ++ 385 1 616-4040
OIB: 84838770814 | IBAN: HR66 2340 0091 1000 1008 1, Porezni broj (PDV identifikacijski broj) - VAT Number: HR84838770814
Prijava u repozitorij

  





    
  
    [image: Dabar: Digital academic archives and repositories]  





    
  
    
      Politike repozitorija   Izjava o pristupačnosti   Kontakt
  



  

                    

                                        
    			

            

		

		
	
	



  
";"""citation_keywords"",""Blockchain tehnologija;računovodstvena industrija;trojno računovodstvo;Blockchain technology;accounting industry;triple-entry accounting""
""dc.publisher"",""Sveučilište u Splitu. Ekonomski fakultet."",""University of Split. Faculty of economics Split.""
""citation_publication_date"",""2020/05""
""og:image"",""https://zir.nsk.hr/islandora/object/efst:3264/datastream/TN/view""
""citation_title"",""POTENCIJAL PRIMJENE BLOCKCHAIN TEHNOLOGIJE U RAČUNOVODSTVU""
""twitter:card"",""summary""
""HandheldFriendly"",""true""
""language"",""hr""
""title"",""POTENCIJAL PRIMJENE BLOCKCHAIN TEHNOLOGIJE U RAČUNOVODSTVU | Nacionalni repozitorij završnih i diplomskih radova ZIR""
""og:description"",""This paper analyses blockchain technology, which could become an inherent part of the accounting industry - the information in the database is reliable and true, regardless of the trust of the other party. The transaction only happens if it has been approved by all participants. With the help of a distributed ledger that is accessible to everyone, data can be translated into a safe, transparent and easy-to-use format. The introduction of technology into accounting has the following advantages: online transactions are fast and easy, accounts can be updated using applications, and optical data recognition systems allow the entire process to be automated, starting with the introduction of primary documents. At the time of writing this thesis, the major drawbacks of the technology were security, lack of legal regulations and lack of user-friendliness. Blockchain could change the traditional methods of billing, documenting, processing, registering, inventory systems and business payment. The technology will allow companies to record both sides of a transaction in a joint ledger at the same time, rather than keeping audited financial transaction records in separate databases or ledgers. Blockchain greatly simplifies international transactions for small businesses and streamlines the procurement process, as it enables secure transaction recording and improves operational efficiency. All accounting documents and records would be encrypted in a secure format, making it virtually impossible to delete entries or manipulate data and to facilitate the audit process. The application of technological capabilities in the accounting industry changes the form of its organization, increases the level of professional competence and responsibility of staff, shows the information support system at a qualitatively new level of transparency, security, efficiency.""
""og:image:secure_url"",""https://zir.nsk.hr/islandora/object/efst:3264/datastream/TN/view""
""twitter:image"",""https://zir.nsk.hr/islandora/object/efst:3264/datastream/TN/view""
""citation_online_date"",""2020/05/27""
""dc.type"",""info:eu-repo/semantics/masterThesis""
""citation_language"",""hr""
""dc.creator"",""Ževrnja, Anita""
""dc:title"",""POTENCIJAL PRIMJENE BLOCKCHAIN TEHNOLOGIJE U RAČUNOVODSTVU | Nacionalni repozitorij završnih i diplomskih radova ZIR""
""Content-Encoding"",""UTF-8""
""Content-Type-Hint"",""text/html; charset=utf-8""
""citation_pdf_url"",""https://zir.nsk.hr/islandora/object/efst:3264/datastream/PDF/download""
""Content-Type"",""text/html; charset=UTF-8""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""dc.description"",""This paper analyses blockchain technology, which could become an inherent part of the accounting industry - the information in the database is reliable and true, regardless of the trust of the other party. The transaction only happens if it has been approved by all participants. With the help of a distributed ledger that is accessible to everyone, data can be translated into a safe, transparent and easy-to-use format. The introduction of technology into accounting has the following advantages: online transactions are fast and easy, accounts can be updated using applications, and optical data recognition systems allow the entire process to be automated, starting with the introduction of primary documents. At the time of writing this thesis, the major drawbacks of the technology were security, lack of legal regulations and lack of user-friendliness. Blockchain could change the traditional methods of billing, documenting, processing, registering, inventory systems and business payment. The technology will allow companies to record both sides of a transaction in a joint ledger at the same time, rather than keeping audited financial transaction records in separate databases or ledgers. Blockchain greatly simplifies international transactions for small businesses and streamlines the procurement process, as it enables secure transaction recording and improves operational efficiency. All accounting documents and records would be encrypted in a secure format, making it virtually impossible to delete entries or manipulate data and to facilitate the audit process. The application of technological capabilities in the accounting industry changes the form of its organization, increases the level of professional competence and responsibility of staff, shows the information support system at a qualitatively new level of transparency, security, efficiency.""
""og:image:alt"",""prikaz prve stranice dokumenta POTENCIJAL PRIMJENE BLOCKCHAIN TEHNOLOGIJE U RAČUNOVODSTVU""
""twitter:title"",""POTENCIJAL PRIMJENE BLOCKCHAIN TEHNOLOGIJE U RAČUNOVODSTVU""
""og:title"",""POTENCIJAL PRIMJENE BLOCKCHAIN TEHNOLOGIJE U RAČUNOVODSTVU""
""citation_author"",""Ževrnja, Anita""
""resourceName"",""download""
""dc.contributor"",""Čular, Marko""
""dc.date.issued"",""2020-05""
""X-UA-Compatible"",""IE=edge""
""citation_dissertation_institution"",""University of Split. Faculty of economics Split""
""MobileOptimized"",""width""
""viewport"",""width=device-width, initial-scale=1""
""twitter:description"",""This paper analyses blockchain technology, which could become an inherent part of the accounting industry - the information in the database is reliable and true, regardless of the trust of the other party. The transaction only happens if it has been approved by all participants. With the help of a distributed ledger that is accessible to everyone, data can be translated into a safe, transparent and easy-to-use format. The introduction of technology into accounting has the following advantages: online transactions are fast and easy, accounts can be updated using applications, and optical data recognition systems allow the entire process to be automated, starting with the introduction of primary documents. At the time of writing this thesis, the major drawbacks of the technology were security, lack of legal regulations and lack of user-friendliness. Blockchain could change the traditional methods of billing, documenting, processing, registering, inventory systems and business payment. The technology will allow companies to record both sides of a transaction in a joint ledger at the same time, rather than keeping audited financial transaction records in separate databases or ledgers. Blockchain greatly simplifies international transactions for small businesses and streamlines the procurement process, as it enables secure transaction recording and improves operational efficiency. All accounting documents and records would be encrypted in a secure format, making it virtually impossible to delete entries or manipulate data and to facilitate the audit process. The application of technological capabilities in the accounting industry changes the form of its organization, increases the level of professional competence and responsibility of staff, shows the information support system at a qualitatively new level of transparency, security, efficiency.""
""dc.title"",""POTENCIJAL PRIMJENE BLOCKCHAIN TEHNOLOGIJE U RAČUNOVODSTVU""
""dc.identifier"",""efst:3264"",""https://urn.nsk.hr/urn:nbn:hr:124:580036""
""og:url"",""https://urn.nsk.hr/urn:nbn:hr:124:580036""
""Content-Language"",""hr""
""Generator"",""Drupal 7 (http://drupal.org)""
";https://scholar.google.ch/scholar?start=630&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098800-183;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;[PDF][PDF] PRIVACY PRESERVING OF ENCRYPTED CLOUD DOCUMENTS USING ACCESS CONTROL POLICY BASED (ABE) ALGORITHMS;JV RAJESWARI, AD DEVI, K RAMBABU ; shabdbooks.com;;"… 440-456. [5]X. Boyen, B. Waters, “Anonymous hierarchical identity-based encryption(without

random oracles),”inProc.CRYPTO, Santa Barbara, California, USA, August.2006, pp. 290-307.

[6]B. Waters, “Dual system encryption: Realizing fully secure IBE and HIBE under simple …";Autres articles;Version HTML;[PDF] shabdbooks.com;http://shabdbooks.com/gallery/688-may2020.pdf;"
PRIVACY PRESERVING OF ENCRYPTED CLOUD 

DOCUMENTS USING ACCESS CONTROL 

POLICY BASED (ABE) ALGORITHMS 

 

JAVVAJI VIJAYA RAJESWARI #1, A.DURGA DEVI #2, K.RAMBABU #3 
 

#1 MSC  Student, Master of  Computer Science, 
D.N.R. College, P.G.Courses & Research Center, Bhimavaram, AP, India. 

 
#2 Assistant Professor, Master of  Computer Applications, 

D.N.R. College, P.G.Courses & Research Center, Bhimavaram, AP, India. 
 

#3 Head & Assistant Professor, Master of  Computer Applications, 

D.N.R. College, P.G.Courses & Research Center, Bhimavaram, AP, India 
 

ABSTRACT  

 

 In current day’s secure document storage and retrieval is one of the hottest research 

directions in cloud computing. Though many searchable encryption schemes have been 

proposed, few of them support efficient retrieval over the documents which are encrypted based 

on their attributes. In this paper, a Hierarchical Attribute-Based Encryption Scheme(HABE) is 

first designed for a document collection and a set of documents can be encrypted together if they 

share an integrated access structure. Here we try to integrate a new concept like CA(Certificate 

Authority) in which the CA will take the responsibility of verifying the user request to and from 

the cloud server and then grant permissions for the data users. Those who got permission from 

the CA can able to access the data in a plain text manner and remaining users can be able to 

access the data only in cipher manner. A thorough analysis and a series of experiments are 

performed to illustrate the security and efficiency of the proposed scheme. 

 

Key Words: Hierarchical Attribute-Based Encryption Scheme, Certificate Authority, Efficient 

Retrieval 

I. INTRODUCTION 

 Cloud computing, a rising innovation was first proposed in Quite a while 2006(Search 

Engine Strategies 2006) by San Jose and characterized by NIST(National Institute of Standards 

Mukt Shabd Journal

Volume IX, Issue V, MAY/2020

ISSN NO : 2347-3150

Page No : 6321



and Technology).Since it was proposed distributed computing has pulled in more noteworthy 

consideration from various areas of society. Distributed computing can gather and rearrange an 

enormous measure of information and obviously, the cloud workers can give safer and adaptable, 

monetary and customized administrations contrasted and the neighborhood workers. As cloud 

administrations have gotten more well-known, requests for figuring information in the cloud 

have expanded. Regardless of the benefits of cloud administrations, releasing the delicate data, 

for example, individual data to the general population is a major danger to the information 

proprietors. What's more, to utilize the information on the cloud, the information clients need to 

get to them deftly and proficiently. A natural methodology is to encode the archives first and 

afterward transferring them to the cloud.  

 

ADMINISTRATIONS MODELS  

 Cloud Computing includes three distinctive help models, to be specific Infrastructure-as-

a-Service (IaaS), Platform-as-a-Service (PaaS), and Software-as-a-Service (SaaS). The three help 

models or layer are finished by an end client layer that epitomizes the end client point of view on 

cloud administrations. The model is appeared in figure beneath. On the off chance that a cloud 

client gets to administrations on the foundation layer, for example, she can run her own 

applications on the assets of a cloud framework and stay answerable for the help, upkeep, and 

security of these applications herself. In the event that she gets to an assistance on the application 

layer, these assignments are typically dealt with by the cloud specialist organization.  

 

DATABASE-AS-A-SERVICE (DBAAS)  

 In our plan, we use DataBase-as-a-Service (DBaaS) administration model, which is a 

distributed computing administration model that furnishes clients with some type of access to a 

database without the requirement for setting up physical equipment, introducing programming or 

designing for execution. The entirety of the regulatory undertakings and support are dealt with 

by the specialist organization so the clients or application proprietors should simply utilize the 

database.In our project,the records transferred by the information proprietors are safely put away 

in the DRIVEHQ live cloud in scrambled manner.Any client who attempts to download 

documents legitimately from the Drivehq cloud will have the option to see them just in figure 

text way. 

Mukt Shabd Journal

Volume IX, Issue V, MAY/2020

ISSN NO : 2347-3150

Page No : 6322



 

Figure 1.Represent the Architecture of DataBase as a Service Model 

 

II. LITERATURE SURVEY 

 

In this section we will mainly discuss about the background work that is carried out in 

order to prove the performance of our proposed Method. Now let us discuss about them in detail 

 

MOTIVATION 

 

1) Constant-size powerful k-TAA  

Creators: M. H. Au, W. Susilo, and Y. Mu  

 Dynamic k-times unknown validation (k-TAA) plans permit individuals from a gathering 

to be confirmed secretly by application suppliers for a limited number of times, where 

application suppliers can freely and powerfully award or disavow get to right to individuals in 

their own gathering. In this paper, we build a powerful k-TAA plot with existence complexities 

Mukt Shabd Journal

Volume IX, Issue V, MAY/2020

ISSN NO : 2347-3150

Page No : 6323



of O(log(k)) and a variation, where the validation convention just requires consistent reality 

complexities at the expense of O(k) - measured open key. We additionally depict some tradeoff 

issues between various framework attributes. We detail all the zero-information evidence of-

information conventions included and show that our development is secure in the arbitrary 

prophet model under the q-solid Diffie–Hellman supposition and q-decisional Diffie–Hellman 

reversal presumption. We give a proof-of-idea execution, probe its exhibition, and show that our 

plan is pragmatic.  

 

2) A safe distributed computing based system for large information data the executives of savvy 

framework  

Creators: J. Baek, Q. H. Vu, J. K. Liu, X. Huang, and Y. Xiang  

 Shrewd lattice is a mechanical development that improves effectiveness, unwavering 

quality, financial matters, and supportability of power administrations. It assumes a critical job in 

present day vitality framework. The fundamental difficulties of shrewd matrices, be that as it 

may, are the means by which to oversee various kinds of front-end keen gadgets, for example, 

power resources and brilliant meters proficiently; and how to process an immense measure of 

information got from these gadgets. Distributed computing, an innovation that gives 

computational assets on requests, is a decent contender to address these difficulties since it has a 

few decent properties, for example, vitality sparing, cost sparing, readiness, adaptability, and 

adaptability. In this paper, we propose a protected distributed computing based system for large 

information data the board in shrewd networks, which we call ""Savvy Frame."" The principle 

thought of our structure is to construct a various leveled structure of distributed computing 

habitats to give various kinds of figuring administrations for data the board and enormous 

information examination. Notwithstanding this basic system, we present a security arrangement 

dependent on personality based encryption, mark and intermediary re-encryption to address basic 

security issues of the proposed structure.  

 

3) Ciphertext-strategy quality based encryption  

Creators: J. Bethencourt, A. Sahai, and B. Waters  

 

Mukt Shabd Journal

Volume IX, Issue V, MAY/2020

ISSN NO : 2347-3150

Page No : 6324



 In a few disseminated frameworks a client should possibly have the option to get to 

information if a client groups a specific arrangement of accreditations or traits. Right now, the 

main technique for implementing such strategies is to utilize a believed worker to store the 

information and intercede get to control. Notwithstanding, in the event that any worker putting 

away the information is undermined, at that point the classification of the information will be 

undermined. In this paper we present a framework for acknowledging complex access control on 

encoded information that we call Ciphertext-Policy Attribute-Based Encryption. By utilizing our 

strategies scrambled information can be kept classified regardless of whether the capacity worker 

is untrusted; in addition, our techniques are secure against intrigue assaults.  

 

III. EXISTING METHODOLOGY 

  In the existing cloud servers ,there was no concept like encryption of cloud data 

and also there was no facility like  key generation and maintenance of  data. The current cloud 

storage is almost centralized and all the data which is stored along with details of data owners 

and data users is clearly visible by the cloud server department, which is almost a big problem in 

the current cloud service providers. In the current cloud servers all the data can be viewed and 

accessed by any one who is having an account access within the cloud, so that the data is not 

having integrity or security in terms of any modification or changes done by any user. Also in the 

current cloud servers there is no facility like multi cloud access. Also there is no concept like 

providing authorization for the owners and users for accessing the file. And there is also no 

concept to identify the attacker details. 

  

LIMITATIONS OF THE EXISTING METHODOLOGY 

  

        The following are the limitation of existing system. They are as follows: 

1. All the existing schemes are limited to the single-owner model.  

2. All the current cloud servers has search in a normal manner under plain text model, but 

they don’t have any facility to search in a ENRYPTED manner 

3. The existing cloud servers are almost  operated in a centralized manner, where all the 

access can be viewed and monitored by the cloud service providers. 

Mukt Shabd Journal

Volume IX, Issue V, MAY/2020

ISSN NO : 2347-3150

Page No : 6325



4. The current cloud servers don’t have a facility to store the sensitive information under a 

de-centralized manner in which the access should lie in the hands of separate individual 

departments. 

III. PROPOSED  METHODOLOGY 

  In the proposed scheme, a set of documents can share a same integrated access tree and 

be encrypted together rather than being encrypted individually. In this way, both the cipher text 

storage space and time costs of the encryption/decryption are saved. The security of the proposed 

scheme is proved theoretically and its effectiveness is also evaluated by simulation. In this paper, 

a hierarchical attribute-based encryption scheme (HABE) is first designed for a document 

collection and a set of documents can be encrypted together if they share an integrated access 

structure. Here we try to integrate a new concept like CA(Certificate Authority) in which the CA 

will take the responsibility of verifying the user request to and from the cloud server and then 

grant permissions for the data users. Those who got permission from the CA can able to access 

the data in a plain text manner and remaining users can be able to access the data only in cipher 

manner. A thorough analysis and a series of experiments are performed to illustrate the security 

and efficiency of the proposed scheme. 

ADVANTAGES OF THE PROPOSED SYSTEM 

 The following are the advantages of the proposed system. They are as follows: 

1. The proposed scheme allows  user to encrypt the data before it is stored into the  cloud 

server. 

2. Here the CA or Key Authority will grant key permissions for the owners or users 

3. The CA or Key authority will give access or deny access for each and every individual 

file request that was send to the cloud server.  

IV. IMPLEMENTATION STAGE 

 
 Implementation Stage is where the hypothetical structure is changed over into 

automatically way. In this stage we will partition the application into various modules and 

afterward coded for arrangement. The application is separated essentially into following 4 

modules. They are as per the following:  

1. Data Owner Module 

Mukt Shabd Journal

Volume IX, Issue V, MAY/2020

ISSN NO : 2347-3150

Page No : 6326



2. CA Module 

3. Data User Module 

4. Cloud server  

  Now let us discuss about each and every module in detail as follows: 

1) DATA OWNER MODULE 

 Here the Data owner register first and then try to login with valid id password. Once he 

gets registered he will login and upload the files in encrypted manner. He will request CA for 

keys to encrypt the file and store in cloud server. 

2)  DATA USER   MODULE 

 Every user need to register while accessing to cloud. After user registered, at the time of 

user login then user can request keys from CA for downloading the files in plain text manner. 

3)  CLOUD SERVER   MODULE 

 Cloud view uploaded files in cloud. Cloud view Downloaded files by user in cloud. Here 

we try to use live cloud DRIVEHQ public account for showing the data stored in encrypted 

manner. 

4)  CA  MODULE 

 This is used to grant keys for the owners and users. This will receive the key request from 

owners and users and in turn try to grant the permissions if the user details are matched 

successfully. 

V. EXPERIMENTAL REPORTS 
 

USER TRY TO DOWNLOAD THE FILE 

 

 
    Figure. Represents the File Download 

Mukt Shabd Journal

Volume IX, Issue V, MAY/2020

ISSN NO : 2347-3150

Page No : 6327



CA MAIN PAGE 

 

 
 

    Figure .Represents the CA main page 

 

CA GRANTS THE KEY FOR FILE ACCESS 

 

 
 

   Figure. Represents the CA Grants the Keys 

 

Mukt Shabd Journal

Volume IX, Issue V, MAY/2020

ISSN NO : 2347-3150

Page No : 6328



 USER RECEIVE THE KEY TO HIS MAIL 

 

 
    Figure. Represents the Key Details 

 

 

FILE CAN BE DOWNLOADED WITH THESE KEYS 

 

 
    Figure . Represents the File Download Keys 

 

Mukt Shabd Journal

Volume IX, Issue V, MAY/2020

ISSN NO : 2347-3150

Page No : 6329



VI. CONCLUSION 
 

 In this paper we designed a hierarchical attribute-based encryption scheme(HABE) is 

first designed for a document collection and a set of documents can be encrypted together if they 

share an integrated access structure. Here we try to integrate a new concept like CA(Certificate 

Authority) in which the CA will take the responsibility of verifying the user request to and from 

the cloud server and then grant permissions for the data users. Those who got permission from 

the CA can able to access the data in a plain text manner and remaining users can be able to 

access the data only in cipher manner. A thorough analysis and a series of experiments are 

performed to illustrate the security and efficiency of the proposed scheme. 

 

     VII. REFERENCES 

[1]J. Horwitz,B. Lynn, “Towards hierarchicalidentity-based encryption,”inProc.EUROCRYPT, 

Amsterdam, The Netherlands, April.2002, pp.466-481. 

 

[2]C. Gentry, A. Silverberg, “Hierarchical ID-based cryptography,”inProc.ASIACRYPT, 

Singapore, December. 2002, pp. 548-566. 

 

[3]D. Boneh, X. Boyen, “Efficient Selective-ID secure identity based encryption without random 

oracles,”inProc.EUROCRYPT, Interlaken, Switzerland, May.2004,pp. 223-238. 

 

[4]D. Boneh, X. Boyen, E. Goh, “Hierarchical identity based encryption with constant size 

ciphertext,”inProc.EUROCRYPT, Aarhus, Denmark, May.2005, pp. 440-456. 

 

[5]X. Boyen, B. Waters, “Anonymous hierarchical identity-based encryption(without random 

oracles),”inProc.CRYPTO, Santa Barbara, California, USA, August.2006, pp. 290-307. 

 

[6]B. Waters, “Dual system encryption: Realizing fully secure IBE and HIBE under simple 

assumptions,”inProc.CRYPTO,Santa Barbara, CA,August. 2009, pp.619-636. 

 

Mukt Shabd Journal

Volume IX, Issue V, MAY/2020

ISSN NO : 2347-3150

Page No : 6330



[7]A. Lewko, B. Waters, “New techniques for dual system encryption and fully secure HIBE 

with short ciphertexts,”inProc.TCC,Zurich, Switzerland, February.2010, pp. 455-579. 

 

[8]G. Wang, Q. Liu, J. Wu, “Hierarchical attribute-based encryption for fine-grained access 

control in cloud storage services,”inProc.CCS, Chicago,Illinois, USA, October.2010, pp. 735-

737. 

 

[9] G. Wang, Q. Liu, J. Wu,M. Guo, “Hierarchical attribute-based encryption and scalable user 

revocation for sharing data in cloud servers,”Computers&security, 30 (5), pp. 320-331, 

July.2011. 

 

[10]Zhiguo Wan, Jun’e Liu, Robert H. Deng, “HASBE: A Hierarchical attribute-based solution 

for flexible and scalable access control in cloud computing,”IEEE Transactions on Information 

Forensics and Security, 7(2),pp. 743-753, April.2012. 

 

[11] Q. Huang, L.Wang, Y.Yang, “DECENT: Secure and fine-grained data access controlwith 

policy updating for constrained IoT devices,”World Wide Web, 2017 (11), pp. 1-17, 2017. 

 

[12]A. Beimel, “Secure Schemes for secret sharing and key distribution[Ph.D. Thesis],”Haifa: 

Israel Institute of Technology, 1996. 

Mukt Shabd Journal

Volume IX, Issue V, MAY/2020

ISSN NO : 2347-3150

Page No : 6331


";"""date"",""2020-08-24T07:15:58Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.4""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dcterms:created"",""2020-08-24T07:15:58Z""
""language"",""en""
""Last-Modified"",""2020-08-24T07:15:58Z""
""dcterms:modified"",""2020-08-24T07:15:58Z""
""dc:format"",""application/pdf; version=1.4""
""Last-Save-Date"",""2020-08-24T07:15:58Z""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2020-08-24T07:15:58Z""
""meta:save-date"",""2020-08-24T07:15:58Z""
""pdf:encrypted"",""false""
""modified"",""2020-08-24T07:15:58Z""
""Content-Length"",""303152""
""pdf:hasMarkedContent"",""false""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""meta:creation-date"",""2020-08-24T07:15:58Z""
""created"",""2020-08-24T07:15:58Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""11""
""Creation-Date"",""2020-08-24T07:15:58Z""
""resourceName"",""688-may2020.pdf""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""1936"",""2536"",""806"",""2286"",""2344"",""2178"",""1189"",""219"",""245"",""1779"",""1183""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""producer"",""PlotSoft PDFill 12.0""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""PlotSoft PDFill 12.0""
""pdf:docinfo:created"",""2020-08-24T07:15:58Z""
";https://scholar.google.ch/scholar?start=730&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098818-223;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;???????? ??????? ??????????? ????????? ?????????????? ??????? ? ?????????????? ?????????? ??????????????? ???????;?? ????????, ?? ?????????, ?? ??????? ; … ? ????????????????????? …, 2020  elibrary.ru;;"… ??? ??????????? ???????? ???????????? ?????????? ????????? ?????????: 1) ?????? ?

?????????? ????????-?????????, ????????, Oracle Blockchain Platform ??? IBM Blockchain

Platform; 2) ?????????? ????????-?????????????? ? Ť??????ť; 3) ??????????? …";;null;null;;;;https://scholar.google.ch/scholar?start=770&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098800-188;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Improved Security Proof for the Camenisch-Lysyanskaya Signature-Based Synchronized Aggregate Signature Scheme;M Tezuka, K Tanaka ; … Conference on Information Security and Privacy, 2020  Springer;;"… The Camenisch-Lysyanskaya signature scheme in CRYPTO 2004 is a useful building block to …

For instance, we consider a blockchain protocol that records several signed transactions in each

new … One is constructed in the random oracle model and the other is constructed in …";Autres articles;;null;;;;https://scholar.google.ch/scholar?start=730&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098826-242;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;[PDF][PDF] Towards Vehicular Digital Forensics from Decentralized Trust: An Accountable, Privacy-preservation, and Secure Realization;C Obimbo ; eprint.iacr.org;;"… To mitigate this issue, in this paper, we propose a decentralized solution based on blockchain

for VDF named BB-VDF, in which the accountable protocols and privacy-preservation algorithm

are constructed … Other parties are allowed to join in the blockchain with the permission …";Autres articles;Version HTML;[PDF] iacr.org;https://eprint.iacr.org/2020/011.pdf;"
IEEE TRANSACTIONS ON COMPUTERS, VOL. XX, NO. XX, XXX 2015 1

Towards Vehicular Digital Forensics from
Decentralized Trust: An Accountable,

Privacy-preservation, and Secure Realization
Ming Li, Jian Weng∗, Member, IEEE , Jia-Nan Liu, Student Member, IEEE , Xiaodong Lin, Fellow, IEEE ,

Charlie Obimbo,

Abstract—With the increasing number of traffic accidents and terrorist attacks by modern vehicles, vehicular digital forensics (VDF)
has gained significant attention in identifying evidences from the related digital devices. Ensuring the law enforcement agency to
accurately integrate various kinds of data is a crucial point to determine the facts. However, malicious attackers or semi-honest
participants may undermine the digital forensic procedures. Enabling accountability and privacy-preservation while providing secure
data access control in VDF is a non-trivial challenge. To mitigate this issue, in this paper, we propose a decentralized solution based on
blockchain for VDF named BB-VDF, in which the accountable protocols and privacy-preservation algorithm are constructed. The
desirable security properties and fine-grained data access control are achieved based on smart contract and the customized
cryptographic construction. Specifically, we design a distributed key-policy attribute based encryption scheme with partially hidden
access structures, named DKP-ABE-H, to realize the secure fine-grained forensics data access control. Then, a novel smart contract is
designed to model the forensics procedures as a finite state machine, which guarantees accountability that each participant performs
auditable cooperation under tamper-resistant and traceable transactions. Systematic security analysis and extensive experimental
results show the feasibility and practicability of our proposed BB-VDF scheme.

Index Terms—Vehicular digital forensics, blockchain, accountability, privacy-preservation.

F

1 INTRODUCTION

THe functionalities of vehicles have been strengthened
tremendously with the increasing in-vehicle sensors,

control units, and communication methods, such as Elec-
tronic Control Unit (ECU), Bluetooth, and Wi-Fi. According
to statistics from Ford Motor Company [1], a modern-day
vehicle has approximate 50-70 computers, which enables
it to be an important source of digital data (e.g., locations
where doors are open/close, when the tires are pumped
and lights are on/off). These wealth of sensing and opera-
tion data make vehicles more intelligent and smart, which
will prompt the prosperity of autonomous driving industry
effectively in the near future [2].

However, as everything has its two sides, the increasing
vehicles also bring us lots of security issues. Specifically, us-
ing vehicles as weapons to conduct terrorist attacks are not
rare and have caused tremendous damages to our society
[3], [4]. Vehicle Ramming Attack (VRA), one of the typical
attacks in reality, refers to malicious attackers deliberately
using a vehicle to ram to a building or a crowd of people. For
example, in July 14, 2016, a 20-ton rental truck rammed into
the crowd who were watching a firework display in Nice,
France, which has resulted in the deaths of 86 people and
wounded more than 450 people [5]. Moreover, according to

• M. Li, J. Weng, and J. Liu are with the College of Cyber Security, Jinan
University, Guangzhou 510632, China. Jian Weng is the corresponding
author. E-mail: cryptjweng@gmail.com, limjnu@gmail.com.

• X. Lin and C. Obimbo are with the School of Computer Science, University
of Guelph, Guelph ON N1G 2W1, Canada. E-mail: xlin08@uoguelph.ca,
cobimbo@uoguelph.ca.

a cnn.com report on terrorist attacks caused by vehicles1, at
least 7 major attacks happened in 2017, which led to at least
37 people dead and hundreds of pedestrians injured. Since
it is incredibly easy to get one car from rental companies,
many terrorist attackers choose a rental car as the crim-
inal weapon2. In other words, launching a VRA requires
minimal capability while can cause catastrophic disasters to
the society (vehicle and car are used interchangeably in this
paper).

To mitigate these types of VRAs, forensics investigation
specialized for vehicles can be conducted to analyze the
suspicious behaviors and collect evidences, which is called
Vehicular Digital Forensics [6] (VDF) (also called “Vehicle
Forensics” [7]). VDF has gained considerable attention both
in academic and industrial area [8] since a vast amount of
data being collected by in-vehicle computers. It can help law
enforcement agency to detect a potential VRA by identifying
suspicious activities. In particular, this field becomes more
significant with the forthcoming of car-sharing and self-
driving cars, which are the way of the future [2]. However,
it also brings a burning question: who is at fault if a self-
driving car gets involved in a fatal accident, the driver or the
car manufacturer who develops the self-driving algorithms? If
it is in the latter case, the manufacturer could be sued
for an unprecedented amount of money for a lost life,
and eventually goes out of business. Thus, it has become
crucial to have a forensically sound way for authorities to

1. https://www.bbc.com/news/world-europe-37137816
2. https://www.cnn.com/2017/05/03/world/terrorist-attacks-by-

vehicle-fast-facts/index.html



IEEE TRANSACTIONS ON COMPUTERS, VOL. XX, NO. XX, XXX 2015 2

investigate car accident in the era of autonomous driving.
As for VRA, the law enforcement agency may prevent

it from happening beforehand if he obtains valuable data
by VDF. For instance, the rental company can detect that
someone has difficulty in explaining the purposes of renting
a car. Combining with other related data, such as traffic
management center to report that the car parks in a specific
area for several days without any reasonable explanation,
the law enforcement agency (i.e., the investigator) may
conjecture that it is a potential threat to the public safety in
this area [3]. Obviously, a single data source is not enough
for the analysis of suspicious behaviors, comprehensive
historical data from the car and related data sources should
be obtained by the investigator. Unfortunately, it is not
easy to conduct a vehicle forensics investigation due to the
existence of several security issues. Let’s take the following
hypothetical scenario as an example:

Example: Carl is a terrorist attacker. He intends to rent
a car as the criminal tool. When Carl appears in a specific
place, a pedestrian, Alice, discovers that Carl’s behaviors are
suspicious. Thus, Alice calls the policeman Bob and tells him
the necessary information. Bob launches a VDF to investigate
the case immediately. He first applies for a warrant from the
court. After being authorized, Bob uses the permitted warrant
to request the historic data on that car from related parties, such
as the corresponding rental company, traffic management center,
and maintenance service provider.

Actually, there are several security and privacy issues
in the above example that may have adverse impacts on
the implementation of VDF: 1) First, the details of the
warrant may be leaked to Carl by malicious external at-
tackers, which makes Carl alert and changes his behavior
temporarily. 2) Second, Bob may violate the purview of the
warrant to require more data than being authorized. He
may even tamper the collected evidences. 3) Third, there
exist malicious insiders in the related parties who might
modify the historical data before presenting to Bob, or
claim the historical data has been lost, which apparently
violates the digital chain of custody [9]. Apart from these
issues, other problems which are adverse to the normative
VDF procedures also exist. Specifically, as vehicles become
smarter and more complicated than before, it is hard for
the law enforcement agency to get forensics data due to
the lack of specialized tools, but to appeal for technical
help from a commercial party. However, it may bring the
potential threat of privacy leakage. Besides, since the court
has released large number of warrants accumulatively, he
may forget to trace the warrants’ states, which allows semi-
honest investigators to still use these warrants to require
sensitive data (even though they are expired) [10]. It is not
an easy work for the court to trace the states of all released
warrants in reality.

We note that while some existing schemes have been pro-
posed to address parts of the issues [10]–[13], most of them
are for different applications, and under different system
models or security threats. Specifically, the public should
be able to audit the process of VDF while preserving the
privacy, which assures the accountability and legitimacy of
the forensics process without powers abusing or misusing.
In addition, the forensics data should be securely obtained
by the law enforcement agency with fine-grained access

control, nothing more and nothing less. It is non-trivial
to consider the above security issues and challenges in
VDF scenario simultaneously. Closest to our work is [11]
which is the first research that proposes a framework on
integrating different parties’ data to conduct the vehicle
forensics through blockchain. However, they do not resolve
the challenges that 1) the confidentiality of warrants should
be preserved during the forensics process (especially for
the terrorist attacks), and 2) the law enforcement agency or
other participants may behave dishonestly.

Therefore, we explore the potential of blockchain, and
take advantage of cryptographic primitives to design a
blockchain-based VDF solution with achieving accountabil-
ity, privacy preservation, and fine-grained data access con-
trol. We construct a permissioned blockchain to integrate
data from different data sources to assist the law enforce-
ment agency to accomplish an investigation. The procedures
of VDF is modeled as a finite-state machine (FSM) in smart
contracts, which enables involved parties to cooperate and
behave legally under the supervision of the public. In a
nutshell, our contributions can be summarized as follows:

• We propose a blockchain-based VDF solution with
accountability and privacy preservation named BB-
VDF, in which the privacy of the warrant details
and forensics data are preserved by leveraging the
customized cryptographic algorithms. To generalize
the forensics data access control in a fine-grained
manner, a distributed KP-ABE with partially hidden
access structures scheme (short for DKP-ABE-H) is
designed to to protect the privacy of the warrant
and eliminate single point of failure/compromise
(SPoF/C) issues on secret key management.

• We design a set of smart contracts that model the
vehicle forensics process as an FSM. The FSM follows
the verification-then-forwarding pattern, in which any
state transition needs to satisfy the pre-designed
conditions and should be publicly verified by the ma-
jority of blockchain nodes without privacy breaches.

• We implement a prototype of the proposed scheme
and deploy it to the Ethereum public test network
Rinkeby. Extensive experimental results indicate the
feasibility and practicability of the proposed BB-VDF
scheme.

Paper Structure. The remainder of the paper is organized
as follows. In the next section, we introduce the background
and related preliminaries. In section 3, we formalize the
system model, threat model, and the security goals. In
section 4, we present the construction of DKP-ABE-H and
analyze its security. In section 5, we present the proposed
concrete scheme, including security proof and analysis. In
section 6, we present the experiments and evaluation results.
The related works are given in section 7. Finally, we give the
conclusion in section 8.

2 BACKGROUND AND PRELIMINARIES

2.1 Digital Forensics
As illustrated in Fig. 1, a typical digital forensics can be
depicted as two main phases: 1) the first phase is the
warrant authorization that law enforcement agency (e.g.,



IEEE TRANSACTIONS ON COMPUTERS, VOL. XX, NO. XX, XXX 2015 3

Warrant 

Authorization

② Collection ③ Examination

④ Analysis⑤ Reporting

①

PHASE 1

PHASE 2

Fig. 1. The workflow of digital forensics.

the policeman) requests a valid authorization from the
court before accessing data of any individual entity [14].
The warrant contains a signature from the court to permit
the law enforcement agency to conduct the investigation.
2) The second phase is on data processing that contains
four steps: collection, examination, analysis, and reporting [15].
Specifically, collection is the process of evidences collection
that aims to gather sufficient data from the software system
(e.g., mobile App) or hardware devices (e.g., physical RAM
and SD card). These data and devices should be stored
with due care to protect the integrity and confidentiality.
Examination is to perform search of the data that is related
with the respondent or the suspected crime. Analysis aims
to conduct more systematical and professional analysis on
the collected data or devices. Reporting is responsible for
providing the final investigation reports on the results of
the previous process.

2.2 Blockchain and Smart Contract

Most recently, the blockchain technology has been employed
in many applications, such as financial services, healthcare
[16], internet-of-things [17] and crowdsourcing [18], [19]. It
is essentially a distributed ledger that is maintained by a
number of network nodes (also called blockchain nodes)
[20]. Blockchain nodes may be mutually distrustful while
can still reach an agreement based on the consensus pro-
tocol, e.g., proof of work (PoW) or proof of stake (PoS).
More preciously, the blockchain is composed of a series of
consecutive blocks, i.e, an ordered hash chain. Each block
contains a number of transactions. Its security assurance
is based on the cryptographic primitives that ensure the
transmissions of digital currency or status transitions among
different entities in a secure way.

Particularly, the review of main features on blockchain
can be listed as follows: 1) Complete Decentralization: it is
based on distributed P2P network that many untrusted
nodes can achieve fair data exchange without reliance on
a central party. 2) Correct Execution: blockchain is a global
computer that each blockchain node can trace and verify
the correctness of the data computation. 3) Tamper-resistance:
the data (i.e., blocks and transactions) are tamper-resistant
since they are organized in a special data structure (Merkle
tree and hash chain).

And also, smart contracts are designed to construct
the decentralized application (DApp) [21] that facilitates
the process of an application to be executed automatically
and verifiably. People could participate in one DApp by
providing valid inputs through on-chain transactions to call
a function in smart contract.

2.3 Cryptography Algorithms
In our constructions, we make use of the following cryp-
tographic algorithms as building blocks to achieve the ac-
countability and fine-grained access control.
Bilinear Pairing: Let G1 and GT be two multiplicative cyclic
groups of prime order p. g is a random generator of G1. Let
e : G1×G1 → GT be a computable bilinear pairing with the
follow properties:

• Bilinearity: for all g ∈ G1 and a, b ∈ Zp, we have
e(ga, gb) = e(gb, ga) = e(g, g)ab.

• Non-degeneracy: e(g, g) 6= 1.
• Computability: the bilinear mapping and the group

computation in GT are efficiently computable.

Distributed Key Generation (DKG): DKG is one of the
components in (t, n)-threshold cryptosystem [22]. It allows
n parties to collectively generate a key pair (i.e., public
key and private key) without letting any single party to
reconstruct the secret key. Besides, it also does not rely on
any trusted party to achieve t-secure, which means that the
protocol is secure if no more than t + 1 parties are broken.
Further, Gennaro et al. [23] improved the security of DKG
protocol with the uniform randomness property. In [23],
each honest party holds a share Îąi of a secret key Îą. For
any each set N of t + 1 correct shares, Îą =

∑
i∈N Νi ¡ ιi,

where Îťi are Lagrange interpolation coefficients for set N .
Specially, the t-secure DKG protocol will always satisfy the
following correctness and secrecy properties:

• Correctness: Any subsets of t + 1 shares define the
same privacy key ι (ι ∈ Zp) and all parties share
the same public key y = gÎą.

• Secrecy: There is no information learned on α expect
for the implication of value y = gÎą.

Key Police Attribute-Based Encryption (KP-ABE): KP-ABE
scheme is a type of public key encryption. It allows user to
encrypt and decrypt data based on attributions. Compared
with the identity-based encryption (IBE) scheme, KP-ABE
scheme is more suitable to support fine-grained access con-
trol policy. Generally, KP-ABE consists of the following four
algorithms [24]:

-Setup(1η) → (PK,MSK). The setup algorithm takes
a security parameter Ρ as the input and outputs the public
parameters PK and a master secret key MSK.

-Encrypt(PK,M,S) → CT . The encryption algorithm
takes the public parameters PK, a set of attributes S and a
messageM as the inputs. It selects a random number s ∈ Zp
outputs a ciphertext CT .

-KeyGen(PK,MSK,A) → SK. The key generation
algorithm takes the public parameters PK, the master secret
key MSK and an access structure A as the inputs and
outputs the private key SK.

-Decrypt(PK,SK,CT )→M . The decryption algorithm
takes as input the public parameters PK, a private key
SK, and a ciphertext CT associated with a set of attributes
S. The algorithm will decrypt the ciphertexts and return a
message M .

3 SYSTEM AND SECURITY MODELS

In this section, we formally present the blockchain-based
VDF framework and system model. Then, we give our



IEEE TRANSACTIONS ON COMPUTERS, VOL. XX, NO. XX, XXX 2015 4

TABLE 1
The notations of explanation.

Notation Explanation
L The law enforcement agency.
C The court.
B The blockchain platform.
D The distributed data storage system.

|N |, |`| The sequence number of (1, ..., n), (1, ..., `), respective-
ly.

(A1, ...,An) The n decryption authorities.
(S1, ...,Sm) The data sources.
PK,MSK The public parameters and master secret key.
id, type, t The identifier, type and timestamp of forensics data.
Kp
e , Ks

e The party’s public key and private key.
M1||M2 The concatenation of message M1 and M2.

H0, H1, H2 Three non-cryptographic hash functions.
Encsk(M) The symmetric encryption on message M with private

symmetric key sk, e.g., AES.
r′, rx , rx,y The generated random numbers.
A = (W, ρ) The access structure in KP-ABE.

Ti The timestamp in the transaction.

Smart Contract

Court

Maintenance

Service Provider

Car

Manufacturer

Traffic

Management

Center

Distributed Data Storage System

Vehicle
Decryption

Authorities

…

Wallet

Data flow Transaction flow

Wallet

Wallet

…
Rental

Company

Law 

Enforcement Agency

Fig. 2. System model.

security assumptions and discuss the threat model. Finally,
the security goals are clearly defined. The notations that will
be utilized are presented in TABLE 1.

3.1 System Architecture
The architecture of the proposed scheme is illustrated in
Fig.2. It consists of six entities: Data Sources, Law En-
forcement Agency, Court, Decryption Authorities, Blockchain
Nodes, Data Storage Nodes. Each party has a corresponding
key pair (i.e., public key and private key).

• Data Sources: identified by S = {S1, ...,So}, refer to
the parties who generate the forensics data which are
helpful for VDF and stores them to the data storage
based on forensics-by-design paradigm [25].

• Law Enforcement Agency: identified by L, refers to
the investigator (e.g., the policeman) who is respon-
sible for launching a digital forensics investigation.
L has the professional skills (including software and
hardware skills) to collect valuable data from differ-
ent data sources.

• Court: identified by C, refers to the official judges
who can approve L’s request to conduct an inves-
tigation on a vehicle by following specified legal
standard.

• Decryption Authorities, identified by A =
{A1, ...,An}, refer to the parties who jointly
maintain a master secret key. They provide the
shares to allow L to recover the decryption key if he
has an authorized warrant. A can be the established
organizations in real-world deployment, e.g., the
government departments.

• Blockchain Nodes: recognized as a permissioned
blockchain (identified by B) that is maintained by
multiple members, such as the court, the law enforce-
ment agency. Other parties are allowed to join in the
blockchain with the permission.

• Data Storage Nodes, refer to the data nodes that
stores the related forensics data. Our scheme adopts
the distributed data storage techniques, e.g., S3. Data
are encrypted in D that if L intends to retrieve
data, he should be granted with a corresponding
decryption key.

The authorities initializes the system by generating the
public parameters. Upon a suspicious behavior or an ac-
cident happen, L first applies for a warrant from C. If
C permits, he will issue an authorized warrant which is
cryptographically signed by her/his secret key to L. Then,
L can require a decryption key from A using the war-
rant and collect data from D. During this investigation,
each procedure is finished by submitting a transaction to
prompt state machine transition in smart contracts, which
enables the public to audit the validity and legitimacy of
the investigation. The underlying B is built atop of the
existing blockchain architecture in our scheme, e.g., En-
terprise Ethereum Blockchain. It supports Turing-complete
smart contract (e.g., solidity), which is extremely useful for
constructing the state machine and accomplishing auditable
forensics investigations. In practice, the involved entities can
be motivated by rewards and penalties in smart contracts,
including transaction fee, we leave the incentive design to
our future work.

Specifically, to obtain the forensics data from vehicles, a
forensics daemon is assumed to run inside OBU to communi-
cate with roadside units, and submit the real-time data to B
and D periodically. In addition, an embedded hardware-
security-module (HSM) based scheme [26] is adopted in
our scheme that data request should be authorized, which
ensures ECUs with secure communications for on-board
system. When it is necessary to collect directly from the
vehicle (e.g., traffic accidents), the forensics daemon com-
municates with different ECUs through Controller Area
Network (CAN) bus requires access authorization, which
guarantees the security of data collection.

3.2 Security Model
Here we discuss threats to digital forensics. Without loss
of generality, the security of B follows the majority-honest-
assumption [18], [27] that is, if most of the blockchain nodes
are honest, B will perform the pre-defined computation
correctly. The forensics daemon are assumed run securely
inside OBU that malicious attackers can not disturb the
normal running, or tamper the content of the collected data.
Similar with the previous schemes on digital forensics, most
of the entities are honest and perform their duties properly,



IEEE TRANSACTIONS ON COMPUTERS, VOL. XX, NO. XX, XXX 2015 5

and all of them are assumed with bounded computation.
Moreover, L, C, and honest A do not collude during the in-
vestigation. However, there still exist some malicious insid-
ers or external attackers who may undermine the forensics
investigation. Specifically, we mainly focus on the following
security threats:

Threat 1: Malicious Law Enforcement Agency L. Gen-
erally, L belongs to a trusted institution in reality. However,
there exist some malicious insiders who are in pursuit of
individual profit and do not follow the standardized digital
forensics process. Thus, we consider that L is untrustworthy
in our threat model. In particular, a warrant authorized by C
has designated the data range, which specifies thatL can not
acquire data more than the designated during the investiga-
tion. However, malicious L (denote as L∗) may attempt to
1) acquire more data without explicit authorization, 2) take
advantage of an expired warrant to obtain access to data, or
3) alter or forge the collected evidences before presenting to
C. Furthermore, potential external attackers may attempt to
compromise L and impersonate an authorized L to conduct
further attacks.

Threat 2: Honest-but-Curious Court. C is also a trusted
institution who complies with the designated protocols to
make a judgement. C can not learn about the details of
data records besides the related forensics data. However,
there may exist malicious insiders who are curious about
the detailed forensics data which are not applied by L. In
addition, C might forget to track the state of an authorized
warrant, which allows L to acquire data by the expired
warrants.

Threat 3: Untrustworthy Authorities. None of A can
learn about the details of warrant and forensics data. Given
an authorized warrant, A will provide the correct secret
shares honestly. However, partial compromised or internal
malicious A (denotes as A∗, no more than a pre-defined
ratio) might exist. They attempt to learn and exposure the
details of an investigation, e.g., the identity of a suspicious
vehicle. In addition, they may collude with suspicious vehi-
cles, which allows them to change their behaviors.

4 THE PROPOSED DKP-ABE-H
In this section, we present the construction of DKP-ABE-H
which is a critical building block for the BB-VDF scheme.

4.1 Syntax of DKP-ABE-H

Formally, the proposed decentralized key-policy attribute-
based encryption with partially hidden access structures
scheme (or simply DKP-ABE-H) DKP-ABE-H=(Setup, En-
crypt, SubPolicyHiddenGen, SubKeyGen, KeyAggre, De-
crypt) is defined by six polynomial-time computable algo-
rithms. Each algorithm is run by one of the three parties: the
sender, the receiver, the authorities:

• Setup(1η, t, n): is a stateful setup algorithm is run by
the authorities A collaboratively. It chooses the security
parameter Ρ ∈ Zp, key management parameters t and
n, and key pairs owned by A as inputs, and outputs the
master public key PK. The master private key MSK is
privacy-preserved that no one could recover it.

• Encrypt(M,PK,S) is a probabilistic encryption algo-
rithm run by the sender. It takes a message M , the
attributes S and PK as inputs, and outputs the ciphertext
C .

• SubPolicyHiddenGen(A) is a probabilistic encryption
algorithm run by the receiver. It outputs the intermedi-
ate parameters {ϕj}j∈|`| which are used to recover the
decryption key. These parameters can be public that others
can not learn the attributes.

• SubKeyGen({ϕj}j∈|`|, αi) is a probabilistic encryption
algorithm run by an authority Ai. It takes partial policies
{ϕj}j∈|`| andAi’s secret key αi of as inputs, and outputs
a share of the decryption key S̃Ki.

• KeyAggre({S̃Kτ}τ∈N ) is a deterministic key aggre-
gation algorithm run by the receiver. It takes any N
authorities’ shares as inputs and outputs the decryption
key SK.

• Decrypt(SK,C) is a deterministic key aggregation algo-
rithm run by the receiver. It takes SK and C as inputs
and outputs the message M .

4.2 Security Definition of DKP-ABE-H
Our security model of DKP-ABE-H is similar with the
typical selective-set model as in [28], [29]. Specifically, we
consider the following experiment ExpAT ,Π(Ρ, S) for an
adversary AT and a challenger C:

Init. The adversary AT chooses a challenge attributes
set S∗ and sends it to the challenger.

Setup. The challenger C runs the Setup algorithm to
generate the system parameters, and gives the public pa-
rameters PK to the adversary while keeping the master
secret key MSK.

Phase 1. The challenger C initializes an empty table T,
two empty set D,E and two integer counter j = 0, l = 0.
The adversary AT can adaptively and repeatedly issue the
following two queries:

• Create(A): If S∗ satisfies A, then it returns ⊥.
The challenger sets j = j + 1. It executes the
SubPolicyHiddenGen(A), SubKeyGen({ϕj}j∈|`|, αi)
and KeyAggre({S̃Kτ}τ∈N ) algorithms to obtain the
private key SK and stores the entry (i,A, SK) into
the table T .

• CorruptSK(i): If there exists an i-th entry in table T ,
the challenger obtains the entry (i,A, SK), and sets
D = D ∪ {A}. Then it sends the private key SK to
the adversary. Otherwise, it returns ⊥.

• CorruptPartialMSK(k): If l ≥ t, it returns ⊥. The
challenger sets l = l + 1, E = E ∪ {ιk} and returns
the partial MSK Îąk to the adversary.

Challenge. The adversary chooses two messages M∗0
and M∗1 as challenge messages. The challenger randomly
chooses a bit b ∈ {0, 1} and encrypts Mb by running
Encrypt(M∗b , PK, S

∗) algorithm. The output C∗ is given to
the adversary.

Phase 2. Phase 1 is repeated with the following restric-
tions:

• The adversary cannot obtain the secret key for the
challenge ciphertext C∗. That is, the adversary can-
not issue a CorruptSK query to obtain a secret key



IEEE TRANSACTIONS ON COMPUTERS, VOL. XX, NO. XX, XXX 2015 6

SK that the corresponding access structure A which
S∗ satisfies.

• The adversary cannot issue the CorruptPartialMSK
query for more than t times.

Guess. The adversary outputs the guess b′ of b. The
experiment outputs 1 iff b = b′.

Definition 2. A decentralized key-policy attribute-based en-
cryption (DKP-ABE-H) is CPA-secure in the selective model, if
for all probabilistic polynomial-time adversary, the advantage of
the adversary in the ExpAT ,Π(η, S∗) satisfied:

Pr[ExpAT ,Π(η, S∗) = 1]− 1/2 ≤ negl(η), (1)

where Ρ is the security parameter.

4.3 Construction of DKP-ABE-H
Setup(1η, t, n) → {PK, {αi}i∈|N |} is a stateful setup al-
gorithm. Given the security parameters Ρ, it generates the
public parameters. Let G1 be a bilinear group with prime
order p ∈ Θ(2Ρ), g is a random generator of G1. H0

is a cryptographic hash function: H0 : {0, 1}∗ → G1.
Specifically, each authority Aj holds a secret share Îąj and
jointly maintains a master secret key Îąwith other authorities
based on the secure DKG protocol [23]. After that, a set N
of t + 1 authorities publish their partial public parameters
v
j

= e(g, g)Îąj and generate the system public parameter:

∏

j∈N

(
e(g, g)Îąj

)Îťj
= e(g, g)

∑
j∈N

Îť
j
¡ι
j

= e(g, g)Îą, (2)

where Îť
j

is the Lagrange interpolation coefficient for shar-
ing secret Îą. The authorities collaboratively specifies the
master public parameters PK = (G, p, g, e(g, g)Îą, H0).
Note that the master secret key MSK = {Îą} is not con-
trolled by any party.

Encrypt(M,PK,S) → C is a probabilistic encryption
algorithm. It randomly generates one number s ∈ Gp, and
takes the master public parameters PK, a message M ∈ GT
and an attributes set S as inputs. The output ciphertext is
computed as follows:

C = M · e(g, g)αs, Ĉ = gs, {Cx = H0(x)s}x∈{0,1}∗ . (3)

SubPolicyHiddenGen(A) → {ϕj}j∈|`| is a probabilistic
partial policy generation algorithm, where A = (W,ρ), ρ is
a function that associates rows of W (an `×n matrix) to the
attributes. To preserve the privacy of access structure, the
attribution values ρ(1), ..., ρ(`) are not revealed to any third
party. To achieve this, the receiver chooses a set of random
numbers {ri, ri,d}i∈|`| ∈ Zp and computes blinded values
as follows:

ϕ1 = (H0(ρ(1))r1 , gr1r1,1 ,∀d ∈ Γ/ρ(1), H0(d)r1r1,d ),

...

ϕ` = (H0(ρ(`))r` , gr`r`,1 ,∀d ∈ Γ/ρ(`), H0(d)r`r`,d ),

(4)

where Γ = {d : ∃i ∈ |`|, ρ(i) = d}. {ϕ1, ..., ϕ`} are sent
to the authorities. Note that ϕi = {H0(ρ(i))ri , griri,1 ,∀d ∈
Γ/ρ(i), H1(ρ(d))riri,d}, i ∈ |`| have the random number
ri,1 , ri,d , such that the authorities cannot learn the values
of the attributes by launching guessing attack, e.g., using
the pairing algorithm.

SubKeyGen({ϕj}j∈|`|, αi) → S̃Ki is a probabilistic par-
tial secret key generation algorithm. Specifically, an honest
authority Aj utilizes the share of the master secret Îą

j
to

generate a share of the decryption key. Since the master
secret key Îą are not kept by any single authority, Aj cannot
compute {gÂľ1 , ..., gÂľ` } directly as in [24], while he can use
Îą
j

to compute the intermediate parameters {gÂľ1,j , ..., gÂľ`,j }
as follows:

gµi,j = gWi·−→vj = gWi·(αj ,y2,...,yn), i ∈ |`|. (5)

Specially, to prevent the receiver from learning the value
gµi,j , Aj chooses a random number r′j ∈ Zp, and computes
the decryption key share S̃Kj = (ϕ̃1,j , ..., ϕ";"""date"",""2020-11-02T00:23:51Z""
""pdf:unmappedUnicodeCharsPerPage"",""1"",""0"",""2"",""3"",""7"",""106"",""46"",""2"",""37"",""58"",""8"",""59"",""0"",""0"",""23""
""pdf:PDFVersion"",""1.5""
""xmp:CreatorTool"",""TeX""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dcterms:created"",""2020-10-30T23:59:11Z""
""language"",""en""
""Last-Modified"",""2020-11-02T00:23:51Z""
""dcterms:modified"",""2020-11-02T00:23:51Z""
""dc:format"",""application/pdf; version=1.5""
""xmpMM:DocumentID"",""uuid:dcbd67a4-c2cc-494d-a148-55c0ba72a52e""
""Last-Save-Date"",""2020-11-02T00:23:51Z""
""pdf:docinfo:creator_tool"",""TeX""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2020-11-02T00:23:51Z""
""meta:save-date"",""2020-11-02T00:23:51Z""
""pdf:encrypted"",""false""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is MiKTeX-pdfTeX 2.9.4307 (1.40.12)""
""xmp:CreateDate"",""2020-10-31T07:59:11Z""
""modified"",""2020-11-02T00:23:51Z""
""Content-Length"",""1231965""
""pdf:hasMarkedContent"",""false""
""Content-Type"",""application/pdf""
""xmp:ModifyDate"",""2020-11-02T08:23:51Z""
""PTEX.Fullbanner"",""This is MiKTeX-pdfTeX 2.9.4307 (1.40.12)""
""xmp:MetadataDate"",""2020-11-02T08:23:51Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""pdf:producer"",""MiKTeX pdfTeX-1.40.12""
""trapped"",""False""
""meta:creation-date"",""2020-10-30T23:59:11Z""
""created"",""2020-10-30T23:59:11Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""15""
""Creation-Date"",""2020-10-30T23:59:11Z""
""resourceName"",""011.pdf""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""4523"",""5590"",""4824"",""4526"",""4817"",""4015"",""4587"",""4457"",""4682"",""13186"",""5351"",""4735"",""4408"",""7255"",""3080""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""producer"",""MiKTeX pdfTeX-1.40.12""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""MiKTeX pdfTeX-1.40.12""
""pdf:docinfo:created"",""2020-10-30T23:59:11Z""
";https://scholar.google.ch/scholar?start=790&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098729-26;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;A Survey on Blockchain & Cloud Integration;S Sarker, AK Saha, MS Ferdous ; arXiv preprint arXiv:2012.02644, 2020  arxiv.org;;"… the introduction of Bitcoin [8] as an immutable ledger of transactions for a crypto-currency called …

34] and Google [35] have also launched their Baas offering where Oracle and SAP … Google is

using both Hyperledger Fabric and Enterprise Ethereum (a private blockchain initiative …";Autres articles;;[PDF] arxiv.org;https://arxiv.org/pdf/2012.02644;"
2020 23rd International Conference on Computer and Information Technology (ICCIT), 19-21 December, 2020.

A Survey on Blockchain & Cloud Integration

Soumik Sarker, Arnob Kumar Saha, Md Sadek Ferdous
Department of Computer Science and Engineering, Shahjalal University of Science and Technology, Sylhet-3114, Bangladesh.

Email: ronodhirsoumik@gmail.com, arnobkumarsaha00@gmail.com, sadek-cse@sust.edu

Abstract—Blockchain is one of the emerging technologies with
the potential to disrupt many application domains. Cloud is an
on-demand service paradigm facilitating the availability of shared
resources for data storage and computation. In recent years,
the integration of blockchain and cloud has received significant
attention for ensuring efficiency, transparency, security and even
for offering better cloud services in the form of novel service
models. In order to exploit the full potential of blockchain-cloud
integration, it is essential to have a clear understanding on the
existing works within this domain. To facilitate this, there have
been several survey papers, however, none of them covers the
aspect of blockchain-cloud integration from a service-oriented
perspective. This paper aims to fulfil this gap by providing a
service oriented review of blockchain-cloud integration. Indeed,
in this survey, we explore different service models into which
blockchain has been integrated. For each service model, we
review the existing works and present a comparative analysis
so as to offer a clear and concise view in each category.

Index Terms—Blockchain, cloud computing, cloud service
models, blockchain-as-a-service, blockchain-enabled cloud

I. INTRODUCTION

Cloud computing has already been a day-to-day purpose
technology. It offers on demand services using a pay-as-you-go
approach. It gives uninterrupted network access and resource
pooling with rapid elasticity [1]. Cloud computing solves
the traditional resource management problem by minimizing
the cost at an eye-catching rate. However, it still has some
limitations such as shared infrastructure problems, virtual-
ization issues, API securities, privacy, SLA (Service Level
Agreement) based legal issues and so on [2]. Researchers
are trying to solve these problems with the help of different
technologies. Recently, Blockchain has emerged as one of the
most common technologies in this regard.

Blockchain is regarded as a foundational technology with
the potential to disrupt a number of application domains,
including cloud computing. It enables a public or private
distributed system that holds data in a secure cryptographic
fashion [3], thus ensuring a secured transaction mechanism
without involving any central entity. Overall, this provides
a much better complementary service provision methods for
many established service platforms including cloud comput-
ing. Therefore, researchers and practitioners are exploring how
blockchain and cloud can be integrated to mitigate different
issues in cloud environments.

To exploit the full benefits of this cloud-blockchain inte-
gration, it is important to have a clear understanding of the
impacts blockchain has over different aspects of cloud. There
have been a few review papers in this regard which can be

found in [4]–[6]. Particularly, the review in [6] is noteworthy
as the authors presented a comprehensive survey on different
aspects involving blockchain-cloud integration. Unfortunately,
a concise service-oriented review of blockchain-cloud inte-
gration is missing, even though the majority of the service
provision mechanism in cloud relies on a service model. We
aim to fulfil this gap in this paper.

Contributions: In this survey, we have reviewed a number of
works in the cross-section of blockchain and cloud following
a service-oriented taxonomy highlighting the service models
into which blockchain has been integrated. For each such
domain, we have reviewed the existing works and provided
a comparative analysis so as to highlight their advantages and
limitations.
Structure: The rest of this paper is structured as follows. In
Section II, we present a brief background of cloud comput-
ing and blockchain. Section III presents the service-oriented
taxonomy. Afterwards, a review for each service category is
presented in Section IV, Section V, Section VI and Section
VII. We discuss and analyze our findings in Section VIII and
finally, conclude in IX.

II. BACKGROUND

In this section, we provide a brief background on cloud
computing and blockchain.
Cloud computing: Cloud services are facilitated by cloud
service providers (CSPs) which are basically third parties
that provide cloud storage and virtualization as well as other
services such as networking components, data, operating
systems and so on [1]. CSPs package these services in
three fundamental service models: Infrastructure-as-a-Service
(IaaS), Platform-as-a-Service (Paas) and Software-as-a-Service
(SaaS). Recently other service models such as Blockchain-
as-a-service and Security-as-a-service are emerging. There are
some useful requirements, such as elasticity, privacy, low-cost,
scalability, inter-operability and high performance, that should
be kept in mind when designing a cloud architecture. Data
management, virtualization management, adaptability and load
balancing are also very important factors to consider.

Blockchain: Blockchain is a distributed fault-tolerant database
where each network participant can share, but no entity can
control this [3]. It is organized as an append-only list, where
every block contains the hash of the previous block, except
the first block, called the Genesis block. Each of the block
encodes some functionalities such as assets and data transfer.

978-0-7381-2333-2/20/$31.00 Š2020 IEEE

ar
X

iv
:2

01
2.

02
64

4v
1 

 [
cs

.C
R

] 
 4

 D
ec

 2
02

0



Every block is broadcast to the network, verified and added to
the existing chain by special nodes or discarded according to
the verification result [7]. The concept of blockchain was pop-
ularised with the introduction of Bitcoin [8] as an immutable
ledger of transactions for a crypto-currency called Bitcoin.
Since then, Blockchain has evolved from a digital currency to a
programmable interactive environment for building distributed
reliable applications [9]. Some key characteristics which are
driving blockchain forward are data immutability (integrity),
data provenance, data persistence and distributed consensus
[10].

III. SERVICE-ORIENTED TAXONOMY

This paper focuses on the researches which focus on the
blockchain integration with cloud platforms. To review the
studies we have created a classification developed under the
‘as-a-service’ perspective, which we call the service-oriented
taxonomy. Under this perspective, all researches within the
scope of the paper (blockchain-cloud integration) have been
grouped together into four service models as illustrated in
Figure 1. The first group is called Security as a Service in
which we explore the blockchain-based works that aim to
improve the existing security services within a cloud platform.
The second group, called Blockchain as a Service, deals
with those works that offer blockchain services using cloud
environments. The third group is a special service model called
Federation as a Service investigating the works that elaborate
on how a blockchain-enabled identify federation can be formed
and managed within multiple cloud environments. Our final
group consists of research works that focus on the management
of tenants and other resources using blockchain within a
cloud environment, creating the notion of a Management as a
Service. For each of these categories, we have reviewed and
compared major influential works under different criteria so
as to provide a visual analogy of their differences, strengths
and weaknesses.

  

Blockchain-cloud 
Integra�on 

Security as a 
Service 

Blockchain as a 
Service 

Federa�on as a 
Service 

 

Management as 
a Service 

 

Access Control 

Data Security 

Industrial 
approaches 

Research 
approaches 

Tenant 
management 

Resources 
management 

Fig. 1. Taxonomy for blockchain-cloud integration

IV. SECURITY AS A SERVICE

The Security as a Service (SECaaS) model enables the pro-
vision of different security services of a cloud platform [11].
In this section we explore two different types of blockchain-
based cloud security services: access control (Section IV-A)
and data security (Section IV-B).

A. Access control

Access Control is a fundamental security mechanism used
not only for cloud platforms but also for many traditional
schemes. It is used to define policies that dictate who can
access which data or resources within a system, thereby
providing a crucial mechanism to handle unauthorised access
in a system. Blockchain-based access control models for cloud
aim to tackle two major challenges:

• In an encryption-based traditional access control model,
one trusted central server is required to store access
policies governing the rights and permissions obligations
as well as to generate, manage and distribute the keys,
thereby making it a single point of failure.

• Securely sharing data/resources using a flexible access
control mechanism within a cloud.

Wang et al. [12] proposed a blockchain-based
framework for data sharing within cloud environments
utilising Ethereum (a public blockchain platform,
https://ethereum.org/en/), IPFS (a distributed
data sharing platform, https://ipfs.io/) and Attribute
Based Encryption (ABE) mechanism. Their scheme filters un-
authorized search requests using an AND gate access policy
for multiple attribute values and wildcards and allows the data
owner to secretly share data in cloud with public generator
keys (PKG). On a similar note, the authors in [13] proposed
a cloud storage framework with automated access control
enforced using Ethereum and a cryptographic mechanism
called Ciphertext-policy Attribute Based Encryption (CP-
ABE). This scheme enables a data owner to assign attribute
sets and define an access policy with a validity period for
a resource by creating and deploying a smart-contract with
which the policy is enforced.

The scheme proposed by Sukhodolskiy et al. [14] has the
ability to define and enforce dynamic access policies using
Ethereum within a cloud platform. It utilises a Certificate
Authority (CA) that generates public and secret keys as a
response to a user’s requests and an Attribute Authority
(AA) that is responsible for managing keys for all attributes.
One limitation of the scheme is the assumption that each
resource has only one owner which is not always true in
an organizational setting. AuthPrivacyChain [15] uses EOS
blockchain (a public blockchain, https://eos.io/) to
store the access control rights. It designs an authentication and
authorization revocation process by assuming the blockchain
account address as the identity. It can resist different types of
external and internal attacks and protect the privacy of users.

The summary of our evaluation of the reviewed works
under this section is presented in Table I. In the table, the



TABLE I
COMPARISON OF ACCESS CONTROL MECHANISMS IN BLOCKCHAIN-CLOUD INTEGRATION

Research Technique Platform Encryp. Method FG Advantages Disadvantages
Wang et al. [12] DAC,ABAC Ethereum MIRACL

(ABE-80)
Feasible, Inter-operable No attribute revocation, policy

update
Wang et al. [13] ABAC Ethereum CPABE No central key distributor Lack of Integrity
Sukhodolskiy et

al [14]
ABAC Ethereum ABE Dynamic access policy Cannot handle a resource with

multiple owners
AuthPrivacy [15] Identity

based
EOS AES &

Asymmetric
Authorization revocation Complex implementation

TABLE II
COMPARISON OF BLOCKCHAIN-BASED SSE MECHANISMS IN CLOUD

Research Client-side Verification Server-side Verification TTP Updatability Platform
Li et al. [16] Bitcoin
Cai et al. [17] Ethereum

TKSE [18] Ethereum and Bitcoin
Zhang et al. [19] Ethereum and Bitcoin

Hu et al. [20] - - Ethereum
Chen et al. [21] - - Ethereum

notations ‘ ‘ and ‘ ’ have been used to signify if the FG
(Fine-grained) property is satisfied or not respectively. Apart
from what is presented in the table, there is one issue that is
worth mentioning. All these works utilised public blockchain
platforms such as Ethereum and EOS. Even though public
blockchain platforms provide better security, in comparison to
any private one, there is associated cost to store data and smart-
contract execution [10]. Furthermore, most public blockchain
systems are slow in nature and have scalability issues. Also,
public blockchains have privacy issues and all of these works
had to separately resolve privacy issues.

B. Data security

Schemes under this category aim to ensure the confiden-
tiality, privacy, integrity and provenance of data utilising
blockchain within cloud environments.

Data confidentiality & privacy: To maintain the confidential-
ity and privacy, data must be stored with some pre-processing
formats or using any encryption methodology before storing
them in cloud. This raises complications while retrieving the
encrypted data. In fact, users have to download all data,
decrypt them and retrieve the needed portion using a query,
which requires additional time and expensive computations for
large data size [16]. In recent years, SSE (Secure Searchable
Encryption) schemes have emerged where user’s data are
encrypted using a private key and stored in a masked index
table with encrypted massages’ keyword pairs. This table and
pre-processed data are stored on the server. For retrieving or
querying, a search token is generated from the user side and it
filters out the encrypted data from the server using that masked
index table without needing to decrypt them.

Towards this motivation, Li et al. [16] proposed an “SSE-
using-BC” scheme where the encrypted data is stored in a
blockchain-enabled decentralized storage supporting data con-
fidentiality and search efficiency. The data owner can upload
encrypted file and its corresponding index to the cloud. The

data containing the keyword, will be retrieved in an encrypted
manner and the user can decrypt it locally using search tokens.
Their proposal can handle both small and large scale data.

Cai at el. [17] proposed an encrypted decentralized storage
architecture, considering the security and fair payment services
utilising a TTP (Trusted Third Party). This scheme, compatible
with both Ethereum and Bitcoin, enables the client or the
data owner to perform file addition on targeted storage peers
with verifiable keyword searching. In TKSE [18], they first
introduced an SSE scheme with the user and server sided
verifiability supporting cost minimization and fair judgement.
For the user-sided verifiability, a data owner can integrate
search requirements into the output script of joint transactions
in such a way that the data owner can resist malicious cloud
servers. The server-side verifiability has been achieved using
the public verification of digital signature.

Zhang et al. [19] introduced BPay, a blockchain-enabled
outsourcing service framework with payment fairness against
malicious users or service providers. Their robust all-or-
nothing protocol is based on SSE and is compatible with both
Bitcoin and Ethereum. In [20], Hu et al. leveraged an Ethereum
smart-contract to replace a central server architecture and
constructed an efficient search scheme preserving security with
efficient computation. The integrating search algorithm in the
smart-contract had focused on two issues: correctness in search
result and computational overhead. Following the approach of
[20], Chen et al. [21] focused on data access control of health
record data in cloud and presented a blockchain-enabled SSE
scheme. They also implemented a smart-contract in Ethereum
for fair payment services in a multi-user setting.

The summary of blockchain-supported SSE based research
works is presented in Table II. Like before, the notations ‘ ’
and ‘ ’ have been used to signify if a property is satisfied
or not respectively whereas ‘-’ implies not applicable. As per
the table, only Cai et al. utilised a TTP and all are based on
public blockchain platforms (mostly Ethereum). Also, when



TABLE III
COMPARISON OF BLOCKCHAIN-BASED DATA PROVENANCE MECHANISMS IN CLOUD

Research Scalability Customizability Inter-
operability

Access-
Control

Environment Platform Monitoring Tool

Smartprovenance [22] Google drive Ethereum Event listener module
Provchain [23] OwnCloud Bitcoin Hooks API

BlockCloud [24] OwnCloud PoS
blockchain

Hooks and listeners

Tosh et al. [25] Federated cloud - Hooks and listeners
Zhang et al. [26] Cloud forensic - User

Gaetani et al. [27] Distributed DB - Database
CPVPA [28] Public cloud - Auditor

applicable, a client-side verification issue has been addressed
whereas the server-side verification has been considered in
only TKSE scheme.

Data integrity and provenance: Data integrity is the main-
tenance and assurance of the accuracy, completeness and con-
sistency of data whereas data provenance generally describes
the custodial chronology of an object by recording every
information of a data object, from its creation to modification
to deletion and then storing this information in a verifiable
audit trail. The core idea of utilising blockchain for these
two is to use the immutability and transparency properties of
blockchain to record each activities associated with a data.

Smartprovenance [22] uses an open provenance method
(OPM) and introduces a fully automated verification scheme
using two smart-contracts. The document tracker contract, as
its name says, keeps track of the changes of a particular
document while the voting contract is used to implement &
initiate the voting protocols. The proposal was deployed using
Ethereum and Google Drive cloud storage.

Provchain [23] offers a solution for collecting, storing and
verifying provenance data in a highly scalable way in which
auditors are used for the verification process and for answering
the provenance-related queries. It was implemented using
Bitcoin and OwnCloud (a cloud based file sharing service,
https://owncloud.com/). BlockCloud [24] architecture
is almost similar to Provchain, except that it utilised a Proof-of-
Stake (PoS) consensus algorithm for reducing high electricity
usage in Proof-of-WorK (PoW) consensus algorithm. A cen-
tralized entity called Federation service controls the resources
and manages the process of stake determination, allocation &
verification.

Tosh et al. [25] proposed an integrity checking mechanism
with provenance data by querying searchable provenance
database through the auditor within a cloud. Zhang et al. [26]
proposed a process provenance, which provides the proof of
existence and privacy preservation for process records using
blockchain and group signature.

A two-layered blockchain within a cloud environment was
proposed by Gaetani et al. [27], where the first layer was a
mining rotation-based blockchain to improve the performance
whereas the second layer was a PoW-based as-is blockchain to
ensure the integrity. CPVPA [28] introduced a certificate-less
public verification scheme against procrastinating auditors.
Their scheme removes the trusted third-party auditor in data

integrity checking, instead introduces a dedicated trust-less
third-party auditor which can itself be audited easily (using
block generation time) by any user. Because of its certificate-
less mechanism, it avoids the certificate management problem
as well.

A comparative summary of the reviewed works under this
category is presented in Table III where the notations have
their usual semantics.

V. BLOCKCHAIN AS A SERVICE

Blockchain as a Service (BaaS) can be considered as a
service like SaaS, however, instead of providing a particular
software service, BaaS enables the customers to create, deploy
and maintain blockchain networks within a cloud environment.
With the increasing adoption of blockchain in business plans of
different sectors, the CSPs have seen the benefits of providing
blockchain based services to their users. Researchers have
also started exploring how such services can be improved.
We segregate and explore these industrial (Section V-B) and
research (Section V-B) schemes next.

A. Industrial Approaches

Almost all major CSPs such as Microsoft, Amazon and
IBM are providing BaaS. Microsoft Azure [29] is con-
sidered as a pioneer in this domain when they intro-
duced EBaaS (Ethereum BaaS). Now Azure also supports
other private blockchain platforms such as Hyperledger Fab-
ric (https://www.hyperledger.org/use/fabric)
and Corda (https://www.corda.net/). IBM Blockchain
[30] is rendering BaaS using Hyperledger Fabric. Amazon
AWS [31] also offers BaaS in two forms: i) Amazon Quan-
tum Ledger Database (QLDB) which enables users to create
customised blockchains and ii) Amazon Managed Blockchain
(AMB) using Hyperledger Fabric. Hewlett Packard Enterprise
also introduced a “Mission Critical Distributed Ledger Tech-
nology” [32] to provide BaaS backed by Corda. Similarly, Or-
acle [33], SAP [34] and Google [35] have also launched their
Baas offering where Oracle and SAP are utilising Hyperledger
Fabric whereas Google is using both Hyperledger Fabric and
Enterprise Ethereum (a private blockchain initiative). The
summary of different BaaS is presented in Table IV.

B. Research Approaches

Chen et al. [43] proposed Functional BaaS (FBaaS) on
serverless architecture focusing on storage overhead and busi-



TABLE IV
COMPARISON OF INDUSTRIAL BAAS APPLICATIONS

Services Platform Type Scalability
Azure [29] Ethereum, Corda, Fabric Private Auto scaling on service demand
IBM [30] Fabric Private High scalability with IBM cloud
AWS [31] Ethereum, Corda, Fabric Private Quick node creation APIs
HPE [32] Corda Private Linear scalability with backup facilities

Oracle [33] Fabric Private, Consortium Dynamic scaling for all resources
SAP [34] Fabric Private High scalability with SAP HANA facilities

Google [35] Ethereum, Fabric Private Scaling with Google App Engine

TABLE V
COMPARISON OF FAAS APPLICATIONS

Research Platform Purpose Inter-operability Privacy
Schiavo et al. [36] Any Democratic governance on data and services
Alansari et al. [37] Ethereum Finegrained attribute-based access control
Alansari et al. [38] Ethereum Attribute based access control

Yang et al. [39] Fabric Differntially-private data sharing
DRAMS [40] Ethereum Decentralised runtime monitoring -

Margheri et al. [41] Ethereum Governance for democratic control -
CloudChain [42] Fabric Democratic control on IaaS provisioning

ness logic stages. Apart from other conventional BaaS models,
Big Data Open Architecture (BDOA) with four layers has been
incorporated with this model. Chen et al. [44] presented Full-
Spectrum Blockchain as a Service (FSBaaS) which is a plat-
form to enhance both centralized and decentralized business
collaborations using blockchain technologies. NutbaaS [45] is
another similar platform providing services, such as network
deployment, system monitoring, smart contact analysis and
testing, within a more reliable and secure environment. Their
four-layer model supports Hyperledger Fabric, Ethereum, EOS
and Filecon and thus, enabling users to combine different
blockchain types. uBaaS [46] is a unified BaaS platform
which aims to address the issue of vendor-lockins within
the existing BaaS models. uBaaS facilitates an independent
model including a one-click deployment as a service, design
pattern as a service and auxiliary services. These works have
similar features and differ only in the number of supported
blockchains.

VI. FEDERATION AS A SERVICE

Cloud federation refers to the unification of different ser-
vices from different providers who may come from disparate
networks. It gives the users a more flexible service-delivery
option with enhanced availability. In a federated cloud, orga-
nizations share resources across their infrastructures and and
users can access those services via the internet. The notion
of Federation as a Service (FaaS) was first introduced in [36]
in which the authors presented a blockchain-enabled decen-
tralised federated governance model. This model emphasizes
on the role of blockchain for the secure, transparent and
accountable creation and management of cloud federations as
well as data and services in a cloud federation.

Other researchers explored how blockchain could be lever-
aged for different aspects of cloud federations. For example,
Alansari et al. presented an identity and access management
system for secure data sharing within a cloud federation [37].
Their approach adopted Intel’s SGX, a trusted hardware envi-

ronment, for protecting the integrity and confidentiality of the
policy enforcement process. In another work, Alansari et al.
[38] proposed a privacy preserving access control framework
for a cloud federation which utilises blockchain, Oblivious
Commitment Based Envelope (OCBE) protocol and a two-
phase Pedersen commitment scheme for ensuring security and
privacy. Yang et al. [39] proposed a blockchain-based privacy
preserving data sharing mechanism within a cloud federation.
Their proposal utilises differential privacy to anonymize data
before sharing where a smart-contract in the blockchain plat-
form is used to validate and allocate privacy budgets in order
to balance between the utility and privacy of the data.

DRAMS [40] proposes a blockchain-based decentralized
runtime access monitoring system for a federated cloud in
order to ensure that the components that receive, process and
exchange access requests can not be subverted. Margheri et al.
[41] proposed an innovative governance approach, data mask-
ing, anonymization and access control monitoring services, to
ensure a democratic control of different providers in a cloud
federation. On the other hand, CloudChain [42] proposed a
blockchain-based democratic infrastructure service provision-
ing system for a cloud federation ensuring the transparency
and immutability in resource and information exchange.

The reviewed works are summarized in Table V where the
symbols carry the usual semantics. As evident from the table,
most of approaches have strong support for privacy and utilised
Ethereum, however, two have adopted Hyperledger Fabric for
their deployment.

VII. MANAGEMENT AS A SERVICE

In a broader sense, the management in cloud can be referred
to the administrative controls which encapsulate the process
of evaluating and monitoring of users, data, resources, appli-
cations, and services. In this section, we review those research
works which focus on the utilization of blockchain for different
aspects of cloud management.

Resource Management on cloud comprises of energy optimiza-



TABLE VI
COMPARISON OF BLOCKCHAIN-BASED RESOURCE AND TENANT MANAGEMENT IN CLOUD

Research Scope Services Smart-contract Dependency
Xu et al. [47] Cloud datacenters Energy cost minimization Decision making on power utilization

Xiong et al. [48] Local Computaional resources Profit maximization and utility management Resource auction and mining tasks
Nayak et al. [49] Users’ service management Service and pricing management Services and pricing monitoring
Weber et al. [50] Users’ privacy Individual permissioned blockchain Managing private and public blockchain

tion, capacity allocation and load balancing between several
distributed nodes. Xu et al. [47] proposed a blockchain-based
decentralized resource management framework to minimize
the total cost of energy consumption within a cloud. The main
feature of this framework is that its consensus process is not
similar to PoW or PoS, instead, it allows all participants in
the cloud to participate in the consensus process. Xiong et al.
[48] on the other hand proposed a game theoretic approach for
achieving efficiency over computational resource management.
To achieve the desired optimization, they implemented two
staged Stackelberg game for the consensus process. This
unique game theoretic approach enables the cloud provider
to set reasonable pricing over computational resources.

Tenant Management is an important issue in cloud for both sin-
gle or multi-tenancy environments. Nayak et al. [49] claimed
their system, Saranyu, to be the first smart contract based ap-
plication on account management for cloud tenants. Weber et
al. [50] proposed an architecture for multi-tenant blockchain-
based system where every tenant is assigned an individual
permissioned blockchain network to maintain the privacy for
their data and smart-contract.

The reviewed works in this category are summarised in
Table VI focusing on their scopes, services and smart-contract
utilisation.

VIII. DISCUSSION

In this survey, we have reviewed a number of influential
works in the cross-section of blockchain and cloud integration
using a service-oriented taxonomy. Next, we highlight some
of our observations that we have noted while carrying out this
survey.

Security: The majority of the research works in blockchain-
cloud integration focus on the security aspects where
blockchain has been used to satisfy, mitigate or improve one
or more security issues. This is not surprising because of the
number of security advantages offered by blockchain in the
form of immutability (integrity), provenance, no single point
of failure and so on.

Blockchain platforms: As mentioned in Section IV-A, public
blockchains have scalability and privacy issues and a signifi-
cant cost is incurred for computation and data storage in such
platforms [10]. Despite these, a surprising observation from
our review is that the majority of the deployments have utilised
public blockchain platforms. A possible reason could be that a
stable private blockchain platform such as Hyperledger Fabric
was not available two/three years ago, forcing the researchers
to experiment with a public blockchain platform. However,

we expect a change in this regard in future as more and more
private blockchain platforms emerge in the market.

Trend analysis: The year-wise distribution of research (Figure
2) illustrates interesting trends and provides an indication of
the time-frame of the works within a service model.

10

5

0
Access

 Control

N
um

be
r o

f P
ap

er
s

SSE BaaSIntegrity & 
Provenance

ManagementFaaS

2016 2017 2018 2019 2020

5

2 2 2
1 1

1

2

4

1

1

3

4

4

5

1

2
1

1

1

Fig. 2. Year-wise distributions of blockchain-cloud integration research

Novel service models: Blockchain has not only been used
to mitigate existing issues in cloud. Indeed, it has facilitated
the creation of novel service models such as BaaS or even
FaaS where blockchain remains at the heart of service delivery
model. We expect to see more such novel cloud service
models, underpinned by blockchain, in future.

IX. CONCLUSION

With the increasing growth in the use of cloud platform
and the popularity of blockchain technology, different CSPs
and researchers are exploring the ways to integrate these two
technologies. In our survey, we have reviewed a number of
influential works using a service oriented taxonomy in the
cross-section of these two technologies. Under each category
of the taxonomy, we have summarized the reviewed works in
a table so as to provide a side by side comparison of the works
against a set of properties. Such comparison between existing
approaches within a service model will help the practitioners
and researches to analyze the paradigms in an efficient way
and thereby, providing a concise understanding of the research
gaps which will ultimately help them to explore exciting
researches in this domain.



REFERENCES

[1] J. S. Hurwitz and D. Kirsch, Cloud computing for dummies. John Wiley
& Sons, 2020.

[2] B. P. Rimal, E. Choi, and I. Lumb, “A taxonomy and survey of cloud
computing systems,” in 2009 Fifth International Joint Conference on
INC, IMS and IDC. Ieee, 2009, pp. 44–51.

[3] D. Drescher, “Blockchain basics (vol 276),” Apress, Berkeley, CA, 2017.
[4] F. Han, J. Qin, and J. Hu, “Secure searches in the cloud: A survey,”

Future Generation Computer Systems, vol. 62, pp. 66–75, 2016.
[5] J. H. Park and J. H. Park, “Blockchain security in cloud computing: Use

cases, challenges, and solutions,” Symmetry, vol. 9, no. 8, p. 164, 2017.
[6] K. Gai, J. Guo, L. Zhu, and S. Yu, “Blockchain meets cloud computing:

A survey,” IEEE Communications Surveys & Tutorials, 2020.
[7] I. Bashir, Mastering blockchain. Packt Publishing Ltd, 2017.
[8] S. Nakamoto, “Bitcoin: A peer-to-peer electronic cash system,”

Manubot, Tech. Rep., 2019.
[9] F. Tschorsch and B. Scheuermann, “Bitcoin and beyond: A technic";"""date"",""2020-12-07T01:56:45Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2020-12-07T01:56:45Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.21 (TeX Live 2020) kpathsea version 6.3.2""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2020-12-07T01:56:45Z""
""created"",""2020-12-07T01:56:45Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-12-07T01:56:45Z""
""resourceName"",""2012.02644""
""Author"",""""
""producer"",""pdfTeX-1.40.21""
""pdf:docinfo:producer"",""pdfTeX-1.40.21""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2020-12-07T01:56:45Z""
""Last-Modified"",""2020-12-07T01:56:45Z""
""dcterms:modified"",""2020-12-07T01:56:45Z""
""title"",""""
""Last-Save-Date"",""2020-12-07T01:56:45Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2020-12-07T01:56:45Z""
""meta:save-date"",""2020-12-07T01:56:45Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.21 (TeX Live 2020) kpathsea version 6.3.2""
""Content-Length"",""496333""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""7""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""4960"",""4475"",""4294"",""4495"",""4475"",""4076"",""7638""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-12-07T01:56:45Z""
";https://scholar.google.ch/scholar?start=570&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098839-275;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Decentralized autonomous organization as a disruptive innovation in insurance industry;R Siliämaa ;2020 trepo.tuni.fi;;"… Blockchain technology has raised a lot of discussions within academia as well as in financial

industry … Keywords: decentralized autonomous organization, blockchain, smart contracts,

insurance industry, disruption in insurance industry, digitalization …";Les 2 versions;Version HTML;[PDF] tuni.fi;https://trepo.tuni.fi/bitstream/handle/10024/119890/Silia%CC%88maaRosa.pdf?sequence=2&isAllowed=y;"
 

  

 

Rosa Siliämaa 

DECENTRALIZED AUTONOMOUS 

ORGANIZATION AS A DISRUPTIVE 

INNOVATION IN INSURANCE INDUSTRY 
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Faculty of Management and Business 

Master’s Thesis 

February 2020  



 

 

ABSTRACT 

Rosa Siliämaa: Decentralized autonomous organization as a disruptive innovation in insurance industry 

Thesis supervisors: Timo Rintamäki and Ville Eloranta 

Master’s Thesis 

Tampere University 

Insurance and risk management 

February 2020 

 

Blockchain technology has raised a lot of discussions within academia as well as in financial industry. The 

founder of Ethereum, Vitalik Buterin, was first to introduce the idea of decentralized autonomous organization 

(DAO), in which blockchain and smart contracts are used to form a new kind of organization. This concept is 

at the center of this study: could DAO disrupt the insurance industry? 

DAO in this thesis is referred to as a system which utilizes transparent blockchain technology and smart 

contracts while being both governed and owned in a decentralized manner. This qualitative research focuses 

on providing a comprehensive view on DAO’s potential in insurance industry on a conceptual level. The 

findings combine expertise gathered from 17 informants in semi-structured interviews. This research describes 

the changes in insurance value chain. Additionally, several possibilities for DAO utilization in insurance 

industry were identified. The DAO potential is also reviewed from the perspective of a disruptive innovation, 

as the main research question of this study aims to understand the disruptive potential (if there is such) of DAO 

in insurance industry.  

The main finding of this research is that DAO’s disruptive potential in insurance industry cannot be 

completely denied. However, there are still many open questions which stem from mindset change, regulation, 

governance, social construction, consumer perspective, quality of information, and technological maturity. The 

study did not find challenges that would have been seen as unsolvable barriers for DAO adoption. Furthermore, 

markets where DAO would not have any potential could not be identified. Another key finding concerns how 

DAO could affect insurance value chain — in essence, DAO has potential to affect all parts of the insurance 

value chain, depending on the chosen implementation strategy. 

Based on this research, DAO seems to have manifold potential in insurance industry. Three main categories 

arose from the expert interviews regarding opportunities to exploit DAO in insurance: (1) peer-to-peer 

insurance models, (2) new markets, and, most notably, (3) existing companies could also act as DAO exploiters. 

Specifically, it seems that existing companies may utilize DAOs in three different ways: (1) as internal startup 

for certain products, (2) as an entity to which a particular part of the value chain is outsourced to, and (3) in a 

way, we don't know yet.  

 

Keywords: decentralized autonomous organization, blockchain, smart contracts, insurance industry, 

disruption in insurance industry, digitalization 

 

The originality of this thesis has been checked using the Turnitin OriginalityCheck service. 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 



 

 

ACKNOWLEDGEMENTS  

 

I am extremely grateful for this amazing journey with this Thesis.  

 

First, I want to express my warm words of thanks to my closest advisor Ville Eloranta from 

Aalto University, who greatly helped me with this thesis. Ville, I am grateful that you 

believed in me and wanted to help me on my last sprint with my studies. You encouraged 

me to continue with this demanding subject at times when it seemed too hard to continue. 

You raised my motivation when I wanted to lower my goals. It is because of your 

encouragement and advice that made this study possible and my learning experience much 

higher than I expected. I am truly grateful for having such a good advisor to guide me. 

Thank you. 

 

Secondly, I wish to thank each of my informants. I have enjoyed dearly on every 

conversation I had with you. Having such experts as informants is valuable for the study, 

but these conversations also meant a lot for me personally. You gave me tons of education, 

inspiration and energy on this journey. I want to give special thanks to you whom took 

more time than was originally expected due to brilliant conversations that we had. I believe 

that time is one of the most valuable things one can give to another. It shows the kind of 

respect for this study that I will never forget.   

 

Lastly, I want to thank my closest supporter Henri. Henri, this journey would have been a 

whole lot different without your influence. You supported me with selecting this 

fascinating topic when others expressed their doubts. You read and commented my text 

multiple times, connected me with right people and gave valuable ideas for the graphics on 

this thesis as well. I am grateful for all of your efforts, and your support has meant a lot for 

me. Hot potato. 

 

I would also like to thank all my blockchain minded friends who have shared thoughts 

around this topic for the past year and also my employer Accenture for allowing me to take 

time for this research. 

 

 

The journey continues, 

Rosa Siliämaa 



 

 

 

CONTENT 
 

1 INTRODUCTION .................................................................................................... 7 

1.1 Research background and key concepts ........................................................... 7 

1.2 Research objectives, research questions and scope .......................................... 9 

1.3 Literature review and earlier researches ......................................................... 10 

1.4 Theoretical and conceptual framework .......................................................... 11 

1.5 Thesis structure ............................................................................................... 13 

2 INTRODUCTION TO INSURANCE INDUSTRY AND DISRUPTIVE 

INNOVATION ....................................................................................................... 15 

2.1 Introduction to insurance ................................................................................ 15 

2.2 Insurance value chain ..................................................................................... 16 

2.3 Competition and challenges in the insurance markets .................................... 19 

2.4 Trends in insurance industry relevant to this study ........................................ 20 

2.4.1 Digitalization and automation in insurance industry ............................ 20 

2.4.2 Blockchain in insurance context ........................................................... 22 

2.5 Disruptive innovation in insurance industry ................................................... 23 

2.5.1 Disruptive innovation ............................................................................ 24 

2.5.2 Disruption in insurance industry ........................................................... 26 

3 DECENTRALIZED AUTONOMOUS ORGANIZATION ................................... 29 

3.1 Enabling decentralization and trust through blockchain technology .............. 29 

3.2 Enabling automation through smart contracts ................................................ 31 

3.3 Example of DAO: Augur ................................................................................ 32 

3.4 Decentralized autonomous organization in scientific discussion ................... 36 

3.5 Definition of DAO – Decentralized Autonomous Organization .................... 38 

4 METHODOLOGY ................................................................................................. 40 

4.1 Interview structure .......................................................................................... 40 

4.2 Description of interviews and experts ............................................................ 41 

4.3 Analysis of the results ..................................................................................... 44 

5 RESULTS ............................................................................................................... 46 

5.1 Informants’ definition of DAO ....................................................................... 46 

5.2 DAO’s potential impact on insurance value chain ......................................... 47 

5.2.1 Primary activities .................................................................................. 48 



 

 

5.2.2 Support activities .................................................................................. 58 

5.3 Additional differences between traditional insurance company and DAO .... 63 

5.4 DAO’s disruptive potential in insurance industry .......................................... 65 

5.4.1 Markets where DAO could have opportunities .................................... 66 

5.4.2 Markets where DAO could not have opportunities .............................. 72 

5.5 Perceived challenges and barriers for DAO adoption .................................... 73 

5.6 DAO from a regulatory perspective................................................................ 77 

6 DISCUSSION ......................................................................................................... 80 

6.1 Answering research questions ........................................................................ 80 

6.2 Research evaluation and critique .................................................................... 84 

6.3 Suggestions for further research ..................................................................... 85 

7 CONCLUSIONS .................................................................................................... 86 

REFERENCES ............................................................................................................... 89 

ATTACHMENTS ........................................................................................................... 98 



 

  
 
 

 

LIST OF TABLES 
 

Table 1 - Key concepts .................................................................................................................. 8 

Table 2 - Tasks in insurance value chain .................................................................................... 18 

Table 3 - Comparisons among public blockchain, consortium blockchain and private blockchain.

 ............................................................................................................................................ 31 

Table 4 - List of informants ........................................................................................................ 43 

Table 5 - Theme categories used in analysis ............................................................................... 45 

Table 6 - The changes in insurance value chain by DAO ........................................................... 81 

 

 

 

LIST OF FIGURES 
 

Figure 1 - Theoretical framework ............................................................................................... 12 

Figure 2 - Insurance-specific value chain ................................................................................... 17 

Figure 3 - Accenture's disruptability index ................................................................................. 28 

Figure 4 - Simplified outline of the lifetime of a prediction market ........................................... 33 

Figure 5 - Simplified outline of the lifetime of an insurance market .......................................... 34 

Figure 6 - Reporting flowchart of Augur .................................................................................... 35 

Figure 7 - Venn diagram illustrating DAO’s key building blocks .............................................. 38 

 

 

 

  

file://///Users/rosasiliamaa/Library/Mobile%20Documents/com~apple~CloudDocs/Koulu/Gradu/GRADU_ROSA_v.0.5.docx%23_Toc30947261


 

2 
 

1 INTRODUCTION 

 

 

1.1 Research background and key concepts 

 

Justice Hugo Black wrote in 1943: “Perhaps no modern commercial enterprise directly affects so many 

people in all walks of life as does the insurance business. Insurance touches the home, the family, and 

the occupation or business of almost every person in the United States.” (Dorfman & Cather 2013, 80). 

Insurance affects many people’s ordinary life and that life may be influenced as megatrends such as 

automation and digitalization shape the industry.  

 

Eling and Lehmann (2018) have studied the impact of digitalization1 on the insurance value chain. In 

their research one of the obvious changes considered the automation of business processes (such as 

automated processing of contracts and automated reporting of claims) and decisions (such as automated 

underwriting, claim settlement and product offerings) (Eling & Lehmann 2018). As the level of 

automation rises, could it be possible to form an end-to-end automated insurance-like processes that 

would also include automation of the governance in these systems? 

 

In 2008 Satoshi Nakamoto introduced a new way of organizing trade in a decentralized manner 

(Nakamoto 2008). The Bitcoin network can be considered as the first truly autonomous organization 

governed exclusively by a decentralized consensus protocol that anyone can freely adopt (Shermin 

2018). It is likely that the world will see many different use cases and purposes for these kind of 

decentralized autonomous organizations (DAOs2) in the future that evolve on top of the technology that 

Bitcoin first pioneered (Olpinski 2016). Could some of these use cases and purposes belong to the 

insurance sector? 

 

Studies have found multiple use cases for blockchain technology and smart contracts in insurance 

industry (see chapters 1.3 and 2.4.2). Some indications that DAOs could have potential in insurance 

industry have also been made. For example, Gatteschi, Lamberti, Demartini, Pranteda, & SantamarĂ­a 

(2018) suggest that in insurance industry blockchain and smart contracts could enable a shift to a full 

decentralization by e.g. automating the management of funds in self-insured groups. Also, Mehar, Shier, 

Giambattista, Gong, Fletcher, Sanayhie and Laskowski (2019) use insurance as an example to illustrate 

 
1 Digitalization can be characterized as the use of new technologies to industrialize and automize processes, to 

change the communication between customer and insurer, and to generate and evaluate new data. (Tischhauser, 

Naumann, Candreia, Treier and Senser 2016) 
2 In this research DAO is referred as an automated organization that utilizes blockchain technology and smart 

contracts (see chapter 3.5). 



 

2 
 

the functionality of smart contracts through organizations such as in the blockchain project called “The 

DAO”3. Following these discussions, this study aims to seek what are the use cases for DAO in 

insurance (if any) in a more detailed level. 

 

As the area of blockchain and DAO is fairly new, the usage of central terms is diverse. Therefore, the 

Table 1 describes what is meant by these concepts in this research. 

 
Table 1 - Key concepts 

 
CONCEPT 

 

DEFINITION 

 

Organization Organizations are systems of coordinated action among individuals and 

groups whose preferences, information, interests or knowledge differ. 

Organization theories describe the delicate conversion of conflict into 

cooperation, the mobilization of resources and the coordination of effort 

that facilitate the joint survival of an organization and its members (March 

and Simon 1993: 2).  

 

Digitalization Digitalization can be characterized as the use of new technologies to 

industrialize and automize processes, to change the communication 

between customer and insurer, and to generate and evaluate new data. 

(Tischhauser, Naumann, Candreia, Treier and Senser 2016) 

 

Decentralization “A decentralized system is where some decisions by the agents are made 

without centralized control or processing.” (Johnson 1999) 

 

Autonomy A state where one is able to make significant decisions without the consent 

of others (Brock 2003). 

 

Innovation Innovation = new idea + execution + value creation (Ståhle, Sotarauta and 

Pöyhönen 2004, 11). 

 

Disruptive innovation A process in which new entrants challenge incumbent firms, often despite 

inferior resources. (Hopp, Antons, Kaminski and Salge 2018, 446) 

 

Blockchain A database type that is distributed, shared and cryptographically 

protected. Each block is always chained to the next block using a 

cryptographic signature. (Walport 2016)  

 

Smart contract A self-executing computer code that contains pre-programmed rules that 

apply to parties to a contract. For example, a smart contract can be used 

in a blockchain. (Lauslahti & Mattila & Seppälä 2016)  

 

Decentralized autonomous 

organization (DAO) 

In this thesis Decentralized Autonomous Organization is defined as a 

transparent  organization that is managed and owned in a decentralized 

manner and where administrative rules are formalized, automated, and 

implemented with software that utilizes blockchain technology and smart 

contracts. 

 

 

 

 
3 “The DAO” was a blockchain project (see chapter 3.4) and should not be confused with the general term DAO 

(decentralized autonomous organization). 



 

2 
 

1.2 Research objectives, research questions and scope 

 

This thesis aims to form a better understanding of DAO’s potential in insurance industry. Voshmgir 

Shermin (2017) has stated that DAO has a potential to disrupt governance as we understand it today. 

Therefore, special attention will be given to DAO’s disruptive potential in insurance environment. 

 

Main research question: 

What is the disruptive potential of decentralized autonomous organization (DAO) in insurance 

industry? 

 

Sub-questions: 

1. What is the impact of DAO to the insurance value chain? 

2. How does DAO align with the characteristics of a disruptive innovation? 

3. In which insurance markets does DAO have potential opportunities, if any? 

4. What are the main conceptual challenges for DAO adoption? 

 

The main question is divided into four sub-questions. After these sub-questions have been answered it 

is expected that answering to the main question is possible. The first sub-question concerns the impact 

of DAO to the insurance value chain. In order to understand DAO’s potential in insurance industry, I 

believe it is necessary to first better understand what DAO means in the context of insurance and how 

DAO could shape the value chain, as it might have impact on the potential opportunities. In order to 

understand DAO’s disruptive potential, it needs to be viewed from the perspective of disruptive 

innovation (a concept founded by Clayton Christensen, 1997). Therefore, that is set as the second sub- 

question. The third sub-question aims to understand characteristics of the insurance markets where DAO 

could have potential. As Gatteschi et al. (2018) have stated, insurance markets could have such potential 

in peer-to-peer insurance, but what are the constraints (if any) and is that the only potential use case? If 

this research would only answer to these questions, the probability of the potential to be realized may 

appear as too optimistic. Therefore, the fourth sub-question is added in order to understand the main 

conceptual challenges for DAO adoption. If such challenges can be found that would dramatically affect 

to the likelihood of DAO adoption, it will also affect to the disruptive potential of DAO as a whole. 

 

To answer these sub-questions, I will use both theorical and empirical information. Description of 

theoretical material is addressed in chapter 1.3. The empirical material is collected from 17 expert 

interviews and the more detailed description of the method can be found from chapter 4. The first sub-

question will be answered purely by the empirical material. The second sub-question needs theory of 

disruptive innovation to be compared to characteristics of DAO. It’s assumed that empirical findings 

would form an understanding what DAO is from the insurance market point of view. After I have 



 

2 
 

gathered this understanding, it is possible to compare if it satisfies the characteristics of a disruptive 

innovation. The third question will also utilize both theoretical material and empirical findings, although 

the emphasis lies with empirical side. Empirical findings are expected to offer opportunities to answer 

to fourth question as well, and this will be enriched by theoretical material. 

 

The scope of this research is to remain on a conceptual level and not to dive deeper into technical 

problems that DAO may have. This study looks DAO as a separate phenomenon from the insurance 

industry’s point of view. The study has no geographical delimitation as it would not have been 

meaningful due to the nature of DAO — therefore, limitations of the specific operating environment are 

not taken into account. Instead, the characteristics of the environment for DAO’s are searched through 

the third sub-question.  

 

1.3 Literature review and earlier researches 

 

As DAO builds up on blockchain technology and smart contracts, understanding the ongoing scientific 

discussions around these topics is needed. Additionally, insurance theories are addressed in chapter 2 as 

they create the framework for this study, from which the insurance value chain is the central element 

and it also provides a basis for interview questions. Lastly, as this study aims to form an understanding 

of DAO’s disruptive potential, the theory of a disruptive innovation by Christensen is assessed in chapter 

2.5. 

 

Blockchain technology has been widely discussed topic during last years. Governments and companies 

around the world are experimenting this new technology trying to figure out its applications and 

potential. Blockchain has aroused particular interest in financial sector and new consortiums have been 

established for developing solutions for this sector (e.g. R34, we.trade5, B3i6, RiskStream 

Collaborative7). In academia, blockchain has been widely discussed as well and in 2014 a journal for 

blockchain and related subjects was established (Ledger 2019).  

 

Blockchain in all of its forms is expected to possess a large amount of business value in the future. 

Gartner (2017) forecasts that by 2030 blockchain business value will exceed USD 3,1 trillion. 

Blockchain is said to have potential in all forms of trading where trust is essential and identity security 

is needed (Plansky, O’Donnell, & Richards, 2016). In corporate environment, blockchain’s potential 

shows up in optimizing business processes in situations where registering and transferring any type of 

 
4 https://www.r3.com 
5 https://we-trade.com 
6 https://b3i.tech/home.html 
7 https://www.theinstitutes.org/guide/riskstream-collaborative 



 

2 
 

asset is needed (Brenig, Schwarz, & Rückeshäuser, 2016). As discussed in chapter 2, these are some of 

the core functions in insurance, which indicates that insurance might benefit from this technology. 

 

Utilization of blockchain technology and smart contracts in insurance has been subject for research over 

many years and it has been seen to offer potential in many ways. Gatteschi et al. (2018) have suggested 

that blockchain and smart contracts can be utilized in insurance industry to speed up claims processing, 

reduce operating costs, fraud prevention, pay-per-use insurance, identity identification, and peer-to-peer 

insurance. Crawford (2017) notes that blockchain will enable the insurance company to set up an 

operational system that can handle and enforce claims almost immediately, without any manual work. 

The same applies to insurance applications and insurance renewal requests (Crawford 2017). 

 

Since 2008, when Satoshi Nakamoto (2008) introduced Bitcoin, blockchain has emerged in various 

forms, often allowing records of transactions automatically make further transactions when blockchain 

participants reach consensus on those transactions. This has enabled the rise of functions called smart 

contracts – automated and self-forced digital contracts on immutable ledger. It is believed that this 

technology could disrupt the business and financial services as the internet disrupted off-line commerce. 

(Cong & He 2018) One potential way for this disruption to emerge could be innovation called 

decentralized autonomous organization (DAO) — a complex set of smart contracts to form a new kind 

of organization (Shermin 2017).  

 

DAO has been encountered in literature as an innovation that utilizes computerized rules and contracts 

(Chohan 2017g; Dupont 2017; Jentzsch 2016; Norta, Othman & Taveter 2015; Norta 2016; Swan 2017) 

which are used to eliminate governmental roles in an organization (Mehar et al. 2019). It has been seen 

as capable to organize similar or the same functions as the most traditional forms of organization 

(Lauslahti, Mattila, Seppälä 2017). One of the most studied DAO projects has been “The DAO”, which 

had an intent to serve as a platform for investors to invest directly in certain kind of blockchain projects 

(Dupont 2017). More detailed description of DAO in scientific discussion can be found in chapter 3.4. 

 

1.4 Theoretical and conceptual framework 

 

Theory can be seen as a starting point for interpretation and discussion, as a point of view as well as a 

base for new theories (Hirsijärvi & Hurme 2011, 40). This research aims to examine the phenomena of 

DAO in the context of existing theories and aims not to build a new theory. The research utilizes 

conceptual and interpretation theory as shown in figure 1. Conceptual theory creates a frame for 

research, which is needed in order to understand the results of the study. Conceptual theory can be seen 

as a start point for interpretation. A selected phenomenon is being examined from the point of view 

framed by interpretation theory. (Eskola & Suoranta 2014, 82) 



 

2 
 

 

 

Figure 1 - Theoretical framework 

 

As this research examines innovation that affects how an insurance company organizes its activities, 

understanding of insurance company’s operation as a whole is needed. Therefore, insurance company’s 

value chain and operating environment must be taken into account. In framework this is described as 

insurance industry. Customers are seen as the most vital stakeholder for the company, and the changing 

needs of the customers have a strong impact on insurance company’s operation.  

 

Relevant forces in context of this research identified to transform the operation are digitalization and 

disruption. Digitalization has had a strong and continuous changes for insurance companies and 

customers, and as DAO may also be seen as being part of digitalization it has been selected. Disruption 

is selected, as this research studies DAO’s disruptive potential. Insurance industry is more susceptibility 

for the future disruption than industries on average (Abbosh, Savic, and Moore 2018). Disruption may 

occur due to disruptive innovation and is therefore linked to it. 

 

Blockchain and smart contracts are strongly affecting to DAO as it builds on them (See chapter 3). 

Blockchain and smart contracts are seen necessary for DAO operation and therefore this study examines 

DAO by building on their theory. In chapter 3 DAO is addressed in more detail.  

 

The research question builds in between of these two entities: DAO and insurance industry (see the dark 

arrow in Figure 1). Thus, the study aims to understand what is the potential that DAO holds for insurance 

industry from insurance companies’ point of view. Furthermore, this study aims to understand if that 

potential can be seen as disruptive or not.  

Customers Insurance 

company

Individual

Business

Blockchain

Smart contracts

Decentralized Autonomous 

Organization

Digitalization

Disruption Disruptive innovation

Value 

chain

Research phenomenon

Conceptual Theory

Insurance industry

Interpretation Theory



 

2 
 

1.5 Thesis structure 

 

The theoretical part of this thesis is divided into two chapters: (1) INTRODUCTION TO INSURANCE 

INDUSTRY AND DISRUPTIVE INNOVATION and (2) DECENTRALIZED AUTONOMOUS 

ORGANIZATION. These chapters form a basis for understanding the empirical findings. The first 

chapter covers the environment where this research takes place and description of the disruptive 

innovation. The second chapter covers the phenomenon in question. Empirical findings will be 

encountered in chapter 5 and lastly follows the discussion part.  

 

The first theoretical chapter will go through foundational insurance theories and also innovation 

theories. The first subchapter 2.1 presents characteristics of insurance, which forms the frame for this 

study and DAO’s conceivable potential. In chapter 2.2 the insurance value chain is presented. This 

helps to categorize DAO’s potential in insurance value chain level and is used as a part of the 

interview question. Chapter 2.3 deepens the understanding what it is like for organization to act on 

insurance markets from the competitional and other challenges point of view. Chapter 2.4 creates the 

background for technological trends relevant for this study and leads reader to the chapter 3. The last 

subchapter 2.5 presents innovation theories from which DAO is analyzed in this study. As DAO is 

examined form the disruptability point of view, the last subchapter describes innovation theories to be 

utilized and also looks into disruption in insurance industry. This is necessary in order to answer to the 

first research sub-question. 

 

The second theoretical chapter (chapter 3) focuses on creating an understanding of DAO. As described 

earlier in chapter 1.4 blockchain and smart contracts are seen vital tools for DAO. Therefore, they are 

needed to be concerned before an understanding of DAO can be created. As 3.1 and 3.2 subchapters 

describe the technology behind the DAO, the chapter 3.3 describes a business level example so that 

deeper understanding of DAO can be formed. Chapter 3.4 gathers separately what literature has said 

about DAO. As DAO is still rather new term, the chapter 3.5 seeks to summarize what the term means 

in this study. 

 

Methodology is described in chapter 4. First the interview structure has been explained in chapter 4.1. 

The description of interviews and experts are addressed in chapter 4.1. Informants have been 

anonymized because this was believed to increase the quality of the research. However, a description 

of the individual informants’ background in provided in chapter 4.2 as well as the description of the 

interviews. Lastly, the chapter 4.3 describes the methodology used in analysis.  

 

The chapter 5 is the empirical part of this study and contains all of the insights gathered from the 

interviews. In chapter 5.1 informants’ definition of DAO is presented. In order to have comparable 



 

2 
 

point of views, it was important to make clear that the informants have understood the concept of 

DAO somewhat similarly and as it may differ from the theoretic definition it is addressed first. The 

rest of the empirical subchapters are formed to answer to the sub-research questions. Chapter 5.2 

describes section by section what is the believed impact of DAO to the insurance value chain on a high 

level. Informants raised up some differences between DAO and traditional insurance organization and 

these aspects are introduced in chapter 5.3. In chapter 5.4 the disruptive potential of DAO is presented 

and in chapter 5.5 perceived challenges and barriers for DAO adoption is presented. Lastly chapter 5.6 

presents what the DAO looks from the regulative perspective.  

 

Discussion takes its place in chapter 6 where the focus is answering to the research questions. 

Additionally, research valuation and critique are addressed in chapter 6.2 and suggestions for future 

research are presented in chapter 6.3. Lastly, the conclusion can be found from chapter 7.  



 

2 
 

2 INTRODUCTION TO INSURANCE INDUSTRY AND DISRUPTIVE 

INNO";"""date"",""2020-03-02T09:02:27Z""
""pdf:PDFVersion"",""1.7""
""xmp:CreatorTool"",""MicrosoftÂŽ Word for Office 365""
""pdf:docinfo:title"",""Master's Thesis""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""pdfa:PDFVersion"",""A-3a""
""language"",""en""
""dc:format"",""application/pdf; version=""""A-3a"""""",""application/pdf; version=1.7""
""pdf:docinfo:creator_tool"",""MicrosoftÂŽ Word for Office 365""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""Master's Thesis""
""xmp:CreateDate"",""2020-03-02T11:02:27Z""
""modified"",""2020-03-02T09:02:27Z""
""pdf:hasMarkedContent"",""true""
""xmp:ModifyDate"",""2020-03-02T11:02:27Z""
""pdf:docinfo:creator"",""Rosa.Siliamaa@arek.fi""
""meta:author"",""Rosa.Siliamaa@arek.fi""
""meta:creation-date"",""2020-03-02T09:02:27Z""
""created"",""2020-03-02T09:02:27Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-03-02T09:02:27Z""
""resourceName"",""Silia%CC%88maaRosa.pdf""
""pdfaid:part"",""3""
""Author"",""Rosa.Siliamaa@arek.fi""
""producer"",""MicrosoftÂŽ Word for Office 365""
""pdf:docinfo:producer"",""MicrosoftÂŽ Word for Office 365""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""access_permission:modify_annotations"",""true""
""dc:creator"",""Rosa.Siliamaa@arek.fi""
""dcterms:created"",""2020-03-02T09:02:27Z""
""Last-Modified"",""2020-03-02T09:02:27Z""
""dcterms:modified"",""2020-03-02T09:02:27Z""
""title"",""Master's Thesis""
""xmpMM:DocumentID"",""uuid:EA579DA0-E02B-449D-9298-896611AE21BA""
""Last-Save-Date"",""2020-03-02T09:02:27Z""
""pdf:docinfo:modified"",""2020-03-02T09:02:27Z""
""meta:save-date"",""2020-03-02T09:02:27Z""
""Content-Length"",""1710267""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Rosa.Siliamaa@arek.fi""
""pdfaid:conformance"",""A""
""dc:language"",""en-US""
""pdf:producer"",""MicrosoftÂŽ Word for Office 365""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""105""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""194"",""2960"",""1996"",""3211"",""1486"",""1796"",""2701"",""2557"",""2810"",""2697"",""3071"",""1979"",""2879"",""1065"",""2656"",""2964"",""1063"",""2450"",""2792"",""2913"",""2977"",""3045"",""2938"",""2518"",""3286"",""3047"",""2739"",""1225"",""2849"",""2773"",""2561"",""2949"",""2280"",""1841"",""1832"",""3018"",""2739"",""1794"",""1314"",""2737"",""3132"",""1668"",""4363"",""2082"",""785"",""1806"",""3173"",""2974"",""2970"",""3032"",""2792"",""3099"",""3016"",""3168"",""3165"",""3067"",""2774"",""2713"",""2826"",""2882"",""2925"",""2735"",""2545"",""2979"",""2632"",""2392"",""2698"",""2473"",""2981"",""3044"",""2627"",""3039"",""2492"",""2610"",""2580"",""2568"",""2482"",""3202"",""526"",""433"",""3845"",""3144"",""2912"",""2809"",""2840"",""2922"",""3164"",""2832"",""2775"",""3417"",""3198"",""3401"",""3199"",""2572"",""3365"",""3429"",""674"",""58"",""74"",""72"",""998"",""3299"",""4331"",""5128"",""759""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-03-02T09:02:27Z""
";https://scholar.google.ch/scholar?start=820&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098774-124;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Non-interactive proofs of proof-of-work;A Kiayias, A Miller, D Zindros ; International Conference on Financial …, 2020  Springer;;"… mining power captured by the number of queries q available per player to the random oracle

per round … 3. Given two hash functions H and G modelled as random oracles, the id of a block

is … A blockchain proof protocol (P, V) about a predicate Q is succinct if for all PPT provers …";Cité 92 fois;Les 12 versions;[PDF] iacr.org;https://eprint.iacr.org/2017/963.pdf;"
Non-Interactive Proofs of Proof-of-Work

Aggelos Kiayias1, Andrew Miller2, and Dionysis Zindros3

1 University of Edinburgh, IOHK
2 University of Illinois at Urbana-Champaign, Initiative for Cryptocurrencies and Contracts

3 National and Kapodistrian University of Athens, IOHK

May 31, 2018

Abstract. Open consensus protocols based on proof-of-work (PoW) mining are at the core
of cryptocurrencies such Bitcoin and Ethereum, as well as many others. In this work, we
construct a new primitive called Non-Interactive-Proofs-of-Proof-of-Work (NIPoPoWs) that
can be adapted into existing PoW-based cryptocurrencies to improve their performance
and extend their functionality. Unlike a traditional blockchain client which must verify the
entire linearly-growing chain of PoWs, clients based on NIPoPoWs require resources only
logarithmic in the length of the blockchain. NIPoPoWs are thus succinct proofs and require
only a single message between the prover and the verifier of the transaction.
With our construction we are able to prove a broad array of useful predicates in the context
of cross PoW-based blockchain transfers of assets, including predicates about facts buried
deep within a blockchain which is necessary for the basic application of accepting payments.
We provide empirical validation for NIPoPoWs through an implementation and benchmark
study, in the context of two new applications: First, we consider a multi-client blockchain
that supports all proof-of-work currencies rather than just one, with up to 90% reduction
in bandwidth. Second, we discuss a “cross-chain ICO” application that spans multiple inde-
pendent blockchains. Using our experimental data, we provide concrete parameters for our
scheme.

1 Introduction

Today, Bitcoin and Ethereum remain the two largest proof-of-work cryptocurrencies by
market cap. However, the ecosystem has grown diverse, with dozens of viable “altcoin”
competitors. Given such an environment, it becomes increasingly important to be able
to efficiently handle multiple blockchains by the same client and reliably transfer assets
between them.

The first objective requires optimizing the “SPV client” described in the original Bit-
coin paper [19] which requires processing an amount of data growing linearly with the size
of the blockchain.

The second objective has received significant attention in the context of “cross-chain”
applications, i.e., logical transactions that span multiple separate blockchains. Simple
cross-chain transactions are feasible today: the most well-known is the atomic exchange [14,
20], e.g., a trade of bitcoin for ether. However, more sophisticated applications [6,9,16,25,
27,30] could be enabled by a more efficient proof process, which would allow the blockchain
of one cryptocurrency to embed a client of a separate cryptocurrency. This concept, ini-
tially popularized by a proposal by Back et al. [2] can be used to avoid a difficult upgrade
process: a new blockchain with additional features, such as experimental opcodes, can be
backed by deposits in the original bitcoin currency, obviating the need to transfer capital
to the new cryptocurrency. As one example of cross-chain interfacing, we describe an ini-
tial coin offering (ICO) [26] which distributes tokens issued on one blockchain, but allows
paying for them using coins in another blockchain.

1.1 Our contributions

Our main technical contribution is the introduction and instantiation of a new crypto-
graphic primitive called Non-Interactive Proofs of Proof-of-Work (NIPoPoW).

1



We present a formal model and a provably secure instantiation of NIPoPoWs. Our
contribution builds on previous work of the backbone model [12] in terms of modeling
and [15] who introduced the concept of (interactive) Proofs of Proof-of-Work, which, in
turn, are based on previous discussion of such concepts in the bitcoin forums [18]. In fact,
we present an attack against the construction of [15] that can be mounted by an adversary
with less than 50% of hashing power. As a result our construction is the first Proof of Proof-
of-Work (regardless of interactivity) that is secure assuming honest majority. Furthermore,
our solution is non-interactive making it the first protocol of this kind.

Regarding to the predicates that are to be demonstrated, previous work allowed only
proving that the k-sized suffix of the currently adopted blockchain is as claimed. We
generalize this notion to prove any predicate across a class of predicates which we call infix
sensitive. This enables proving powerful statements pertaining to the blockchain such as
the fact that a transaction took place, that a smart contract method ran with certain
parameters, or that a payment was made into an account. The most basic application of
such proofs, payment verification, require more general predicates than what is covered in
previous work, and we enable these.

We prove the proofs are optimistically succinct meaning that they are logarithmic
in size in honest conditions. Improving previous work, we show that, in the optimistic
model of no adversarial mining power, succinctness can be achieved for even adversarially-
generated proofs by introducing the novel concept of certificates of badness. Our definition
fills the gap in terms of security modeling and design that existed in previous proposals,
e.g., the notion of cumulative “Dynamic Member Multisignature” [2].

We provide concrete parameterization and empirical analysis showing the savings of
our approach versus existing clients. Using real data from the Bitcoin and other networks,
we quantify the savings of NIPoPoWs over the previous techniques of constructing SPV
verifiers. For a multi-blockchain client that receives 100 payments per day, we offer a 90%
reduction in bandwidth compared to näĹve SPV.

In summary, we make the following contributions:

1. We construct the first provably secure Proofs of Proof-of-Work.
2. We make them non-interactive.
3. We describe an attack against the previously known proof-of-proof-of-work construc-

tion.
4. We extend proofs to prove generic infix predicates pertaining to transactions deep

within the blockchain.
5. We improve succinctness of previous proofs by weakening the optimality assumptions.
6. We provide experimental data which measure the efficiency and security of our scheme

as well as concrete parameters based on these experiments.

2 Model and Definitions

Our model for describing our results is based on the standard “backbone” model for
proof-of-work cryptocurrencies [12], extended with the widely used Simplified Payment
Verification (SPV) mode due to Nakamoto [19]. We consider three roles in our setting:
lightweight clients, full nodes, and miners.4

Nodes and miners run the Bitcoin backbone protocol, maintaining a copy of the
blockchain and committing new transactions they receive from clients. Clients do not
store the entire blockchain, but instead connect to nodes for service and request up-to-
date information about the blockchain, for example whether a particular payment has

4 Full nodes can be thought of as miners with zero hashpower.

2



been finalized. Our main challenge is to design a protocol so that clients can sieve through
the responses they receive from the network and reach a conclusion that should never
disagree with the conclusion of a full node who is faced with the same objective and infers
it from its local blockchain state.

2.1 Backbone model

The entities on the blockchain network are of 3 kinds: (1) miners, who try to mine new
blocks on top of the longest known blockchain and broadcast them as soon as they are
discovered (for simplicity we assume that difficulty is constant and thus the “longest
chain rule” sufficiently describes honest miner behavior); (2) full nodes, who maintain
the longest blockchain without mining and also act as the provers in the network; (3)
verifiers or stateless clients, who connect to provers and ask for proofs in regards to which
blockchain is the largest. The verifiers attempt to determine the value of a predicate on
these chains.

We model proof-of-work discovery attempts by using a random oracle [4] as in [12].
For clarity, we present our results in the backbone model [12], although we suspect our
results transfer easily to more refined models, such as Pass et al. [21]. More specifically, we
remark that we assume a synchronous model in this paper. While we suspect our results
carry over in a treatment in a partially synchronous model with bounded delay, this is left
for future work.

The random oracle produces κ-bit strings, where κ is the system’s security parameter.
The network is synchronized into numbered rounds, which correspond to moments in time.
n denotes the total number of miners in the game, while t denotes the total number of
adversarial miners. Each miner is assumed to have equal mining power captured by the
number of queries q available per player to the random oracle, each query of which succeeds
independently with probability p (a successful query produces a block with valid proof-of-
work). Mining pools and miners of different computing power can be captured by assuming
multiple players combine their computing power. This is made explicit for the adversary,
as they do not incur any network overhead to achieve communication between adversarial
miners. On the contrary, honest players discovering a block must diffuse it (broadcast it)
to the network at a given round and wait for it to be received by the rest of the honest
players at the beginning of the next round. A round during which an honest block is
diffused is called a successful round ; if the number of honest blocks diffused is one, it is
called uniquely successful round. We assume there is an honest majority, i.e., that t/n < 0.5
with a significant gap [12]. We further assume that the network is adversarial, but that
there is no eclipsing attacks [13]. More specifically, we allow the adversary to reorder
messages transmitted at a particular round, to inject new messages thereby capturing
Sybil attacks [10], but not to drop messages. Each honest miner maintains a local chain
C which they consider the current active blockchain. Upon receiving a different blockchain
from the network, the current active blockchain is changed if the received blockchain is
longer than the currently adopted one. Receiving a different blockchain of the same length
as the currently adopted one does not change the adopted blockchain.

Blockchain blocks are generated by including the following data in them: ctr, the
nonce used to achieve the proof-of-work; x the Merkle tree [17] root of the transactions
confirmed in this block; and interlink [15], a vector containing pointers to previous blocks,
including the id of the previous block. The interlink data structure contains pointers to
more blocks than just the previous block. We will explain this further in Section 3. Given
two hash functions H and G modelled as random oracles, the id of a block is defined as
id = H(ctr,G(x, interlink)). In bitcoin’s case, both H and G would be SHA256.

3



2.2 The prover and verifier model

In our protocol, the nodes include a proof along with their responses to clients. We need to
assume that clients are able to connect to at least one correctly functioning node (i.e., that
they cannot be eclipsed from the network [1, 13]). Each client makes the same request to
every node, and by verifying the proofs the client identifies the correct response. Henceforth
we will call clients verifiers and nodes provers. Note that in the interactive protocol from
prior work [15], the prover and verifier may engage in more than one round of message
passing.

The prover-verifier interaction is parameterized by a predicate (e.g. “the transaction t
is committed in the blockchain”). The predicates of interest in our context are predicates
on the active blockchain. Some of the predicates are more suitable for succinct proofs than
others. We focus our attention in stable predicates having the property that all honest
miners share their view of them in a way that is updated in a predictable manner, with a
truth-value that persists as the blockchain grows (an example of an unstable predicate is
e.g., the least significant bit of the hash of last block). Following the work of [12], we wait
for k blocks to bury a block before we consider it confirmed and thereby the predicates
depending on it stable. k is the common prefix security parameter, which in bitcoin folklore
is often taken to be k = 6.

In our setting, for a given predicate Q, several provers (including adversarial ones) will
generate proofs claiming potentially different truth values for Q based on their claimed
local longest chains. The verifier receives these proofs and accepts one of the proofs,
determining the truth value of the predicate. We denote a blockchain proof protocol for
a predicate Q as a pair (P, V ) where P is the prover and V is the verifier. P is a PPT
algorithm that is spawned by a full node when they wish to produce a proof, accepts
as input a full chain C and produces a proof π as its output. V is a PPT algorithm
which is spawned at some round, receives a pair of proofs (πA, πB) from both an honest
party and the adversary and returns its decision d ∈ {T, F} before the next round and
terminates. The honest miners produce proofs for V using P , while the adversary produces
proofs following some arbitrary strategy. Before we introduce the security properties for
blockchain proof protocols we introduce some necessary notation for blockchains.

2.3 Blockchain addressing

Our development makes use of several notation conventions for manipulating blockchain
data structures, which we introduce here. Blockchains are finite block sequences obeying
the blockchain property that in every block in the chain there exists a pointer to its previous
block. A chain is anchored if its first block is genesis, denoted Gen.

For chain addressing we use Python brackets C[¡] as in [22]. A zero-based positive
number in a bracket indicates the indexed block in the chain. A negative index indicates
a block from the end, e.g., C[−1] is the tip of the blockchain. A range C[i : j] is a subarray
starting from i (inclusive) to j (exclusive).

Given chains C1, C2 and blocks A,Z we concatenate them as C1C2 or C1A. C2[0] must
point to C1[−1] and A must point to C1[−1]. We denote C{A : Z} the subarray of the chain
from A (inclusive) to Z (exclusive). We can omit blocks or indices from either side of the
range to take the chain to the beginning or end respectively.

The id function returns the id of a block given its data, i.e., id = H(ctr,G(x, interlink)).

2.4 Provable chain predicates

Our aim is to prove statements about the blockchain, such as “The transaction t is included
in the current blockchain.” We consider a general class of predicates that take on values

4



true or false. Since a Bitcoin-like blockchain can experience delays and intermittent forks,
not all honest parties will be in exact agreement about the entire chain. However, when
all honest parties are in agreement about the truth value of the predicate, we will soon
require in our security definition that the verifier also arrives at the same truth value.

To aid the construction of our proofs, we focus on predicates that are monotonic; they
start with the value false and, as the blockchain grows, can change their value to true but
not back.

Definition 1. (Monotonicity) A chain predicate Q(C) is monotonic if for all chains C
and for all blocks B we have that Q(C)⇒ Q(CB).

Additionally, we require that our predicates only depend on the stable portion of the
blockchain, blocks that are buried under k subsequent blocks. This ensures that the value
of the predicate will not change due to a blockchain reorganization.

Definition 2. (Stability) Parameterized by k ∈ N, a chain predicate Q is k-stable if its
value only depends on the prefix C[: −k].

2.5 Desired properties

We now define two desired properties of a non-interactive blockchain proof protocol, suc-
cinctness and security.

Definition 3. (Security) A blockchain proof protocol (P, V ) about a predicate Q is secure
if for all environments and for all PPT adversaries A and for all rounds r ≥ ηk, if V
receives a set of proofs P at the beginning of round r, at least one of which has been
generated by the honest prover P , then the output of V at the end of round r has the
following constraints:

– If the output of V is false, then the evaluation of Q(C) for all honest parties must be
false at the end of round r − ηk.

– If the output of V is true, then the evaluation of Q(C) for all honest parties must be
true at the end of round r + Ρk.

Fig. 1. The truth value of a fixed predicate Q about the blockchain, as seen from the point of view of 5
honest nodes, drawn on the vertical axis, over time, drawn as the horizontal axis. The truth value evolves
over time starting as false at the beginning, indicated by a dashed red line. At some point in time t0, the
predicate is ready to be evaluated as true, indicated by the solid blue line. The various honest nodes each
realize this independently over a period of Ρk duration, shaded in gray. The predicate remains false for
everyone before t0 and true for everyone after t0 + Ρk.

t0
t

t0 + Ρk

node 1
node 2
node 3
node 4
node 5

Some explanation is needed for the rationale of the above definition. The parameter
Ρ is borrowed from the Backbone [12] work and indicates the rate at which new blocks

5



are produced, i.e., the number of rounds needed on average to produce a block. If the
scheme is secure, this means that the output of the verifier should match the output of a
potential honest full node. However, in various executions, not all potential honest full node
behaviors will be instantiated. Therefore, we require that, if the output of the proof verifier
is true then, consistently with honest behavior, all other honest full nodes will converge to
the value true. Conversely, if the output of the proof verifier is false then, consistently with
honest behavior, all honest full nodes must not have indicated true sufficiently long in the
past. The period Ρk is the period needed for obtaining sufficient confirmations (k) in a
blockchain system. A predicate’s value has the potential of being true as seen by an honest
party starting at time t0. Before time t0, all honest parties agree that the predicate is false.
It takes Ρk time for all parties to agree that the predicate is true, which is certain after
time t0+Ρk. The adversary may be able to convince the verifier that the predicate has any
value during the period from t0 to t0 +Ρk. However, our security definition mandates that
before time t0 the verifier will necessarily output false and after time t0 + Ρk the verifier
will necessarily output true.
Remark. The above security definition, which works in the synchronous model, strictly
requires that all NIPoPoW proofs have all been generated at some round r. In a partially
synchronous setting, NIPoPoW proofs could be generated for a period of time of a certain
length Ρk. Without loss of generality, it can be assumed that, in such a setting, the honest
party P generates the NIPoPoW proof at time r while the adversary generates her proof
at time r + Ρk, gaining some advantage. The security definition can be altered to allow
for such a setting by requiring the truth value to alter only within the period r − 2ηk to
r + 2Ρk.

Definition 4. (Succinctness) A blockchain proof protocol (P, V ) about a predicate Q is
succinct if for all PPT provers A, any proof π produced by A at some round r, the verifier
V only reads a O(polylog(r))-sized portion of π.

It is easy to construct a secure but not succinct protocol for any computable predicate
Q: The prover provides the entire chain C as a proof and the verifier simply selects the
longest chain: by the common-prefix property of the backbone protocol (c.f. [12]), this is
consistent with the view of every honest party (as long as Q depends only on a prefix of the
chain, as we explain in more detail shortly). In fact this is how widely-used cryptocurrency
clients (including SPV clients) operate today.

It is also easy to build succinct but insecure clients: The prover simply sends the
predicate value directly. This is roughly what hosted wallets do [5].

The challenge we will solve is to provide a non-interactive protocol that at the same
time achieves security and (optimistic) succinctness over a large class of useful predicates.

3 Consensus layer support

3.1 The interlink pointers data structure

In order to construct our protocol, we rely on the same interlink data structure used by
PoPoW [15]. This is an additional hash-based data structure that is proposed to include
in the header of each block. The interlink data structure is a skip-list [23] that makes
it efficient for a verifier to process a sparse subset of the blockchain, rather than only
consecutive blocks.

Valid blocks satisfy the proof-of-work condition: id ≤ T , where T is the mining target.
Throughout this work, we make the simplifying assumption that T is constant. Some
blocks will achieve a lower id. If id ≤ T

2Âľ we say that the block is of level Âľ. All blocks

6



are level 0. Blocks with level Âľ are called Âľ-superblocks. Âľ-superblocks for Âľ > 0 are also
(µ−1)-superblocks. The level of a block is given as µ = blog(T )− log(id(B))c and denoted
level(B). By convention, for Gen we set id = 0 and µ =∞.

Observe that in a blockchain protocol execution it is expected half of the blocks will
be of level 1, 1/4 of the blocks will be of level 2, 1/8 will be of level 3 and 1/2Âľ blocks
will be of level Âľ. In expectation, the number of superblock levels of a chain C will be
Θ(log(C)) [15]. Figure 2 illustrates the blockchain superblocks starting from level 1 and
going up to level 4 in case these blocks are distributed exactly according to expectation.
Here, each level contains half the blocks of the level below.

In our protocol, the verifier must roughly scan along one level at a time. To enable
this, instead of just the previous block, the interlink vector also points to the most recent
preceding block of every level Âľ. Genesis is of infinite level and hence a pointer to it is
included in every block at the first available index within the interlink data structure. The
number of pointers that need to be included per block is in expectation log(|C|).

Figure 2 illustrates the blockchain superblocks starting from level 1 and going up to
level 4 in case these blocks are distributed exactly according to expectation. Note that
each level contains half the blocks of the level below.

Fig. 2. The hierarchical blockchain. Higher levels have achieved a lower target (higher difficulty) during
mining.

The algorithm for this construction is shown in Algorithm 1 and is borrowed from [15].
The interlink data structure turns the blockchain into a skiplist-like [23] data structure.

The updateInterlink algorithm accepts a block B′, which already has an interlink data
structure defined on it. The function evaluates the interlink data structure which needs to
be included as part of the next block. It copies the existing interlink data structure and
then modifies its entries from level 0 to level(B′) to point to the block B′.

Algorithm 1 updateInterlink
1: function updateInterlink(B′)
2: interlink← B′.interlink
3: for µ = 0 to level(B′) do
4: interlink[µ]← id(B′)
5: end for
6: return interlink
7: end function

Traversing the blockchain. As we have now extended blocks to contain multiple point-
ers to previous blocks, if certain blocks are omitted from a chain we will obtain a subchain,
as long as the blockchain property that each block must contain a pointer to its previous
block in the sequence is maintained.

7



Blockchains are sequences, but it is more convenient to use set notation for some
operations. Specifically, B ∈ C; C1 ⊆ C2 and ∅ have the obvious meaning. C1 ∪ C2 is the
chain obtained by sorting the blocks contained in both C1 and C2 into a sequence (this
may be not always defined). We will freely use set builder notation {B ∈ C : p(B)}.
C1 ∊ C2 is the chain {B : B ∈ C1 ∧ B ∈ C2}. In all cases, the blockchain property must be
maintained. The lowest common ancestor is LCA(C1, C2) = (C1 ∩ C2)[−1]. If C1[0] = C2[0]
and C1[−1] = C2[−1], we say the chains C1, C2 span the same block range.

It will soon become clear that it is useful to construct a chain containing only the
superblocks of another chain. Given C and level µ, the upchain C↑µ is defined as {B ∈ C :
level(B) ≥ µ}. A chain containing only µ-superblocks is called a µ-superchain. It is also
useful, given a µ-superchain C′ to go back to the regular chain C. Given chains C′ ⊆ C,
the downchain C′↓ C is defined as C[C′[0] : C′[−1]]. C is the underlying chain of C′. The
underlying chain is often implied by context, so we will simply write C′↓ . By the above
definition, the C↑ operator is absolute: (C↑µ)µ+i = C↑µ+i. Given a set of consecutive rounds
S = {r, r + 1, · · · , r + j} ⊆ N, we define CS = {B ∈ C : B was generated during S}.

4 Non-interactive blockchain suffix proofs

In this section, we modify the PoPoW scheme introduced in KLS [15] to make it non-
interactive. With foresight, we caution the reader that the non-interactive construction
we present in this section is insecure, because the PoPoW scheme it is based on is also
insecure. A very small patch will later allow us to modify our construction to achieve
security.

Their scheme only allowed proving suffix predicates, predicates that pertain to the suffix
of the blockchain. We continue along those lines to give our NIPoPoW construction which
allows proving certain predicates Q of the chain C. Among the predicates which are stable,
in this section, we will limit ourselves to suffix sensitive predicates (similar to previous
work which did not make this distinction explicit). We extend the protocol to support
more flexible predicates (such as transaction inclusion, as needed for our applications) in
Section 5.

Definition 5 (Suffix sensitivity). A chain predicate Q is called k-suffix sensitive if for
all chains C, C′ with |C| ≥ k and |C′| ≥ k such that C[−k :] = C′[−k :] we have that
Q(C) = Q(C′).

Notice that if a predicate Q is suffix-sensitive, then then its value must be determined
only by the k-suffix of the chain.

Example. In general our applications will require predicates that are not suffix-sensitive.
However, as an example, consider the predicate “an Ethereum contract at address C
has been initialized with code h at least k blocks ago” where h does not invoke the
selfdestruct opcode. This can be implemented in a suffix-sensitive way because, in
Ethereum, each block includes a Merkle Trie over all of the contract codes [8, 29], which
cannot be changed after initializtion. This predicate is thus also monotonic and k-stable.

4.1 Construction

We next present a generic form of the verifier first and the prover afterwards. The generic
form of the verifier works with any practical suffix proof protocol. Therefore, we describe
the generic verifier first before we talk about the specific instantiation of our protocol. The
generic verifier is given access to call a protocol-specific proof comparison operator ≤m that

8



Algorithm 2 The Verify algorithm for the NIPoPoW protocol

1: function VerifyQm,k(P)
2: π̃ ← (Gen) . Trivial anchored blockchain
3: for (π, χ) ∈ P do . Examine each proof (π, χ) in P
4: if validChain(πχ) ∧ |χ| = k ∧ π ≥m π̃ then
5: π̃ ← π
6: χ̃← χ . Update current best
7: end if
8: end for
9: return Q̃(χ̃)

10: end function

we define. We begin the description of our protocol by first illustrating the generic verifier.
Next, we describe the prover specific to our protocol. Finally, we show the instantiation of
the ≤m operator, which plugs into the generic verifier to make a concrete verifier for our
protocol.

The generic verifier. The Verify function of our NIPoPoW construction for suffix pred-
icates is described in Algorithm 2. The verifier algorithm is parameterized by a chain
predicate Q and security parameters k,m; k pertains to the amount of proof-of-work
needed to bury a block so that it is believed to remain stable (e.g., k = 6); m is a security
parameter pertaining to the prefix of the proof, which connects the genesis block to the
k-sized suffix. The verifier receives several proofs by different provers in a collection of
proofs P at least one of which will be honest. Iterating over these proofs, it extracts the
best.

Each proof is a chain. For honest provers, these are subchains of the adopted chain.
Proofs consist of two parts, π and χ; πχ must be a valid chain; χ is the proof suffix; π is
the prefix. We require |χ| = k. For honest provers, χ is the last k blocks of the adopted
chain, while π consists of a selected subset of blocks from the rest of their chain preceding
χ. The method of choice of this subset will become clear soon.

The verifier compares the proof prefixes provided to it by calling the ≥m operator.
We will get to the operator’s definition shortly. Proofs are checked for validity before
comparison by ensuring |χ| = k and calling validChain which checks if πχ is an anchored
blockchain.

At each loop iteration, the verifier compares the next candidate proof prefix π against
the currently best known proof prefix π̃ by calling π ≥m π̃. If the candidate prefix is
better than the currently best known proof prefix, then the currently known best prefix is
updated by setting π̃ ← π. When the best known prefix is updated, the suffix χ̃ associated
with the best known prefix is also updated to match the suffix χ of the candidate proof by
setting χ̃← χ. While χ̃ is needed for the final predicate evaluation, it is not used as part
of any comparison, as it has the same size k for all proofs. The best known proof prefix
is initially set to (Gen), the trivial anchored chain containing only the genesis block. Any
well-formed proof compares favourably against the trivial chain.

After the end of the for loop, the verifier will have determined the best proof (π̃, χ̃). We
will later prove that this proof will necessarily belong to an honest prover with overwhelm-
ing probability. Since the proof has been generated by an honest prover, it is associated
with an underlying honestly adopted chain C. The verifier then extracts the value of the
predicate Q on the underlying chain. Note that, because the full chain is not available
to the verifier, the verifier here must evaluate the predicate on the suffix. Because the
predicate is suffix-sensitive, it is possible to do so. As a technical detail, we denote Q̃ the

9



predicate which accepts only a k-suffix of a blockchain and outputs the same value that
Q would have output if it had been evaluated on a chain with that suffix.

Algorithm 3 The Prove algorithm for the NIPoPoW protocol
1: function Provem,k,δ(C)
2: B ← C[0] . Genesis
3: for µ = |C[−k].interlink| down to 0 do
4: α← C[: −k]{B :}↑µ
5: π ← π ∪ α; B ← α[−m]
6: end for
7: χ← C[−k :]
8: return πχ
9: end function

The concrete prover. The NIPoPoW prover construction is shown in Algorithm 3. The
honest prover is supplied with an honestly adopted chain C and security parameters m, k, δ
and returns proof πχ, which is a chain. The suffix χ is the last k blocks of C. The prefix
π is constructed by selecting various blocks from C[: −k] and adding them to π, which
consists of a number of blocks for every level Âľ. At the highest possible level at which at
least m blocks exist, all these blocks are included. Then, inductively, for every superchain
of level Âľ that is included in the proof, the suffix of length m is taken. Then the underlying
superchain of level µ−1 spanning the same blocks as that suffix is also included, until level
0 is reached. This underlying superchain will have 2m blocks in expectation and always
at least m blocks.

The algorithm returns a chain πχ. In this chain, χ is the suffix of an honestly adopted
blockchain containing the most recent k blocks. π is a subchain of the underlying blockchain
with the last k blocks removed, C[: −k].

In each iteration of the for loop, blocks of level Âľ are considered, starting from the top-
most level |C[−k].interlink| and descending down to level 0. When we take a µ-sup";"""date"",""2018-05-31T17:26:38Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2018-05-31T17:26:38Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.19 (TeX Live 2018) kpathsea version 6.3.0""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2018-05-31T17:26:38Z""
""created"",""2018-05-31T17:26:38Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2018-05-31T17:26:38Z""
""resourceName"",""963.pdf""
""Author"",""""
""producer"",""pdfTeX-1.40.19""
""pdf:docinfo:producer"",""pdfTeX-1.40.19""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""9"",""11"",""3"",""1"",""2"",""11"",""19"",""9"",""16"",""3"",""1"",""1"",""4"",""12"",""0"",""0"",""1"",""0"",""0"",""0"",""4"",""4"",""17"",""9"",""1"",""0"",""16"",""46"",""21"",""16"",""11"",""12"",""11"",""9"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2018-05-31T17:26:38Z""
""Last-Modified"",""2018-05-31T17:26:38Z""
""dcterms:modified"",""2018-05-31T17:26:38Z""
""title"",""""
""Last-Save-Date"",""2018-05-31T17:26:38Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2018-05-31T17:26:38Z""
""meta:save-date"",""2018-05-31T17:26:38Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.19 (TeX Live 2018) kpathsea version 6.3.0""
""Content-Length"",""660403""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""42""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""3010"",""3002"",""3282"",""3124"",""2136"",""3062"",""2116"",""2825"",""2724"",""2691"",""1955"",""3033"",""1550"",""1529"",""2640"",""2723"",""3020"",""2431"",""2965"",""2558"",""2740"",""2027"",""2765"",""632"",""2923"",""3333"",""980"",""3237"",""2310"",""3263"",""2988"",""3445"",""2583"",""2638"",""3079"",""1364"",""2474"",""2725"",""2543"",""2531"",""3093"",""2228""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2018-05-31T17:26:38Z""
";https://scholar.google.ch/scholar?start=670&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098866-338;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;[PDF][PDF] Stochastic modelling and analysis of bitcoin;S Bistarelli, R De Nicola, L Galletta, C Laneve… ; Manuscript submitted …, 2020  cs.unibo.it;;"… In particular, miners who want to solve the crypto-puzzle synchronize with the Hasher which … In

the above contributions, the properties are verified by using oracles that drive the … above works,

in [24], P?rlea and Sergey propose a formaliza- tion of blockchain consensus focusing …";Cité 1 fois;Les 3 versions;[PDF] unibo.it;https://www.cs.unibo.it/~laneve/papers/StochasticModellingBitcoin.pdf;"
Stochastic Modelling and Analysis of Bitcoin

Stefano Bistarelli 1,Rocco De Nicola 2, Letterio Galletta 2, Cosimo Laneve 3,
Ivan Mercanti 2, Adele Veschetti 3

1 University of Perugia
2 IMT School for Advanced Studies, Lucca

3 University of Bologna – INRIA Focus

Abstract. Nakamoto’s Bitcoin blockchain protocol implements a dis-
tributed ledger on peer-to-peer asynchronous networks. In this paper we
analyze Bitcoin by (i) extending PRISM, a probabilistic model checker,
with a ledger datatype, (ii) modelling the behaviour of blockchain’s key
participants – the miners – and (iii) describing the whole protocol as a
parallel composition of processes. The probabilistic analysis of the model
highlights how forks happen and how they depend on some parameters of
the protocol, such as the difficulty of the crypto-puzzle and the network
communication delays. Our results confirms that considering transac-
tions in blocks at depth larger than 5 as permanent is reasonable because
the majority of miners have consistent blockchains up-to that depth with
probability almost 1.

1 Introduction

Blockchain is an emerging technology that implements a distributed ledger on
peer-to-peer asynchronous networks that are dynamic, in the sense that nodes
may either join or leave. It is exploited in many contexts including the manage-
ment of cryptocurrencies (Bitcoin being the most famous one [21]) and of decen-
tralized applications (e.g., Ethereum smart contracts [7]), the implementation of
voting systems [5] and the support of other application specific protocols [2, 25,
26].

When implementing a distributed ledger on a dynamic peer-to-peer asyn-
chronous network, one has to address the problem of inconsistent updates of
the ledger performed by different nodes. This problem is actually a variant of
the distributed consensus, which is known to be unsolvable since 1985 [13]. To
overcome this shortcoming, blockchain uses an ingenious approach: it guarantees
a so-called eventual consistency whereby the various replicas of the ledger may
be temporarily inconsistent in at most the last m blocks.

The blockchain consensus protocol is very complex and the current research
is actively involved in studying its properties and its criticalities. Indeed, under-
standing the details of the behaviour of such protocol is of paramount impor-
tance because overseeing some details might introduce vulnerabilities and pave
the way to attacks. For example, inconsistencies of the ledger replicas, which are
called forks, occurring when there are two or more blocks at the same height



2 Bistarelli et al.

of the ledger, may be used for rewriting the transaction histories and make the
blockchain evolve to a wrong state.

In this paper we consider the consensus protocol used in Bitcoin and study
its properties by taking advantage of formal methods. In particular, we focus
on the key participants of the protocol, the miners and model their behaviour
as PRISM [19] processes; then we describe the whole protocol as the parallel
composition of the involved miners. Since the duration of mining a block and of
broadcasting a message to all the nodes of the network can be modelled as an
exponential distribution with a so-called rate parameter [4, 12, 28], we found it
appropriate to rely on Continuous Time Markov Chains (CTMCs) for providing
a probabilistic model of our processes. Remarkably, to the best of our knowledge
this is one of the first paper formally studying the properties of Bitcoin through
a probabilistic model checker.

In order to model and analyse Bitcoin, we use PRISM [19], an off-the-shelf
tool suitable for modelling and analysing systems that exhibit random or prob-
abilistic behaviours. However, since PRISM lacks linguistic primitives to model
the complex datatypes used by the protocol underlying Bitcoin, we had to ex-
tend it with a library implementing the notion of block of transactions and of
ledger in a native way: ledger, block and set. After this extension, we have
been able to define a simple model of the Bitcoin protocol that details miners’
behaviours as processes and analyse the resulting system. As an initial step, we
assess the coherence of our model by verifying that the probability of mining
a new block within a given amount of time and the probability of forking we
compute are in full agreement with the values available from the literature.

In particular, it turns out that the probability of a fork strictly depends
on the broadcast delay and on the difficulty of the cryptopuzzle, that is the
difficulty of computational problem that miners must resolve in order to add a
new block to the ledger. Our analysis also vindicates the statement that waiting
for at least 6 confirmations before considering a transaction as permanent in the
ledger is reasonable because at that time the majority of miners has a consistent
blockchain with probability almost 1.

After the empirical validation of the model, we study the trade-off between
security guarantees and hardness of the solution of the cryptopuzzle needed
to add a new block to the ledger. More precisely, we study the probability of
reaching forking states when we decrease the level of difficulty of the cryptopuzzle
in order to increase the speed of the mining process. Our analysis shows that by
slightly decreasing the difficulty level the speed of mining increases at the cost
of an almost irrelevant increase of the probability of forking.

We would like to stress that our PRISM libraries (ledger, block and set)
are generic, in the sense that they are not tied to the Bitcoin protocol. In fact,
they can be used for modelling and analysing other blockchain protocols, which
is one of the research topics in our future agenda.

The rest of the paper is structured as follows. Section 2 contains a short
account of Bitcoin and its (Proof of Work) consensus algorithm and recap the
main constructs of the PRISM language. Section 3 presents our extension of the



Stochastic Modelling and Analysis of Bitcoin 3

PRISM language with the new data types, ledger, block and set. Our model
of Bitcoin is presented in Section 4. Section 5 contains our simulations of the
Bitcoin protocol and the comparison with results obtained when the difficulty
parameter is changed. Section 6 compares our proposal with the literature and
Section 7 draws some conclusions and discusses possible future work.

2 Background

2.1 Bitcoin and Proof of work (PoW)

Bitcoin is a peer-to-peer asynchronous global network of nodes that hosts a
ledger logging economic transactions. Transactions are created by participants
to record cryptocurrency transfers and are broadcasted to all the nodes of the
network. Suitable nodes of the network – the miners – gather these transactions,
collect them in blocks and update the ledger. The integrity and the consistency
of the ledgers are ensured by a mix of cryptographic primitives, i.e. secure hash
functions and digital signatures, and by the consensus protocol. This protocol is
run by every miner of the network and ensures that the updates performed on
the ledger by the different miners will be eventually consistent. In particular, the
protocol is byzantine fault tolerant [9, 20] and guarantees that the (eventual)
consensus is always reached found by the majority of the nodes.

A key parameter of the Bitcoin consensus protocol is the mining speed.
Clearly, the faster miners are, the higher is the probability of conflicts and thus
of inconsistencies likely is the inconsistency between miners. Bitcoin regulates
mining by relying on the Proof of work (PoW) [21] technique, which requires
miners to solve a computational hard problem before being allowed to add a new
block to the ledger1. By regulating the difficulty of the PoW, Bitcoin keeps the
mining speed at around 10 minutes. Once a miner solves the PoW, it broadcasts
the block to all the other nodes of the network to be added to their own ledger,
and starts working on the next block.

Since the Bitcoin network is asynchronous it may happen that two nodes mine
and broadcast a block concurrently. This phenomenon, called fork, is at the core
of the inconsistency between ledgers of the network. To overcome this problem,
the Bitcoin protocol guarantees the so-called eventual consistency that we shall
shortly explain. Every miner has a view of the ledger, which is the longest chain
starting from the root (the genesis block) – this chain is called blockchain –
(there may be several such chains, a miner just commits to one). When a miner
creates a new block, the block is added to its ledger in the leaf position of his
blockchain and sends the block to the other nodes with the pointer to his parent.
When a miner receives new blocks, it connects them to his ledger and updates its

1 Technically, the problem consists of finding a number, dubbed nonce, that, once
concatenated and hashed together with the (header of the) block, produces a target
that starts with a certain number of zeros. The only solution to find such a nonce
is through an exhaustive search and the difficulty is proportional to the size of the
nonce search space and to the number of zeros required to the target.



4 Bistarelli et al.

“view” if another chain has become longer than its own blockchain, generating
stale blocks2. Notice that due to network delays it might happen that a miner
receives a block that cannot be connected to its ledger because a previous block
is missing (they are called orphan). Eventual consistency means that all the
blockchains of the network are consistent up-to the last few blocks. For this
reason, Bitcoin considers both transactions and miner’s rewards in blocks at
depth greater than 6 as permanent [1].

In this paper we will overlook a number of features of Bitcoin that are either
not relevant for the analysis of the protocol or that can be abstracted out. Such
as the Bitcoin rewards that are reserved for those who solve the problem3 or
the computational complexity of the cryptopuzzle (that can be abstracted by
choosing ad-hoc rates of the mining actions).

2.2 PRISM language

PRISM [19] is a probabilistic model checker that inputs a formal probabilistic
description of a system and computes the likelihood of the occurrence of certain
events. PRISM supports different kinds of probabilistic formalisms; in this con-
tribution we focus on CTMCs models, which are transition system where each
transition from a state s to a state s′ is labeled by a positive real number ρ,
dubbed the rate of the transition. Then, the probability of performing a tran-
sition from state s to state s′ within t time units is given by the exponential
distribution 1 − e−ρt [18]. We refer to [17] for a full account of the formalisms
supported by PRISM.

In order to specify systems, PRISM uses a concurrent language, the PRISM
language. A system is the parallel composition of a set of modules, representing
processes, that can interact with each other; every module represents a (sequen-
tial) agent and has an internal state represented by a tuple of local variables.
The overall state of a system is determined by the state of all the modules.

The behaviour of a module is defined by a set of commands that specify
how and under which conditions a module performs a transition and updates its
internal state. Modules have commands of the form

[] guard -> rho_1:update_1 +...+ rho_n:update_n;

where guard is a predicate over the variables in the module (even those of other
modules); and update_i corresponds to a transition that the system can make.
A transition is defined as an update that assign a new value to some variables
of the module. When guard is true, the module chooses a transition specified in
the command (the operator + denotes a nondeterministic choice) according to
the rate rho_i associated to that update. That is, the next state is computed
according to a race condition [18]. In fact, typically from one state there is more

2 Blocks which were successfully mined but which are not included on the current best
blockchain, likely because another block at the same height had its chain extended
first.

3 These are 6.25 Bitcoin in May 26th 2020.



Stochastic Modelling and Analysis of Bitcoin 5

than one reachable state and the first transition to be triggered determines the
next state of the CTMC.

Commands can also specify synchronizations between modules through ac-
tions, which are placed inside square brackets. To clarify, we propose a simple
example from PRISM documentation4 that models an N -place queue of jobs
and a server which removes jobs from the queue and processes them:

1 ctmc
2
3 const int N = 10;
4 const double mu = 1/10;
5 const double lambda = 1/2;
6 const double gamma = 1/3;
7
8 module queue
9 q : [0..N];

10
11 [] q<N -> mu:(q’=q+1);
12 [] q=N -> mu:(q’=q);
13 [serve] q>0 -> lambda :(q’=q-1);
14 endmodule
15
16 module server
17 s : [0..1];
18
19 [serve] s=0 -> 1:(s’=1);
20 [] s=1 -> gamma:(s ’=0);
21 endmodule

In the above code we define two modules, queue (row 8 to 14) and server (row
16 to 21) that synchronize on the action serve (in square parenthesis). Mod-
ule queue has an integer variable q (defined in row 9) representing its size (the
constant N - defined in row 3 - denotes its capacity). Transitions describe the
operations on the queue. The first one (row 11) inserts a new element with rate
mu, if the queue is not full (q<N); the insertion is rendered by incrementing the
value of q. Note that the PRISM language uses the prime notation to denote the
new value of a variable, in our case q’ = q + 1. The second transition (row 12)
says that no new element is inserted when the queue is full. The last transition
(row 13) removes an element; it is triggered when the queue is not empty and
there is a synchronization with module server on the variable serve.

In the module server, the boolean variable s (row 17) defines whether the
server is busy or not. The first transition (row 19) allows the server to synchronize
with queue on variable serve when the server is idle. After this synchronization
the server updates its state to busy (s’=1). Note that the rate of this transition
is equal to the product of the two individual rates (in this case, lambda*1). The
second transition (row 20) of module server states that a busy server (s=1) may
complete its task with rate gamma.

4 http://www.prismmodelchecker.org/manual/ThePRISMLanguage/Example2



6 Bistarelli et al.

3 The Extended PRISM Language

To have a faithful implementation of the Bitcoin protocol we have extended the
PRISM model checker with three dynamic data types: block, ledger and list.
In this section we overview our extension.

3.1 The Block

As discussed in Section 2, Bitcoin blocks record the transactions that are going to
be certified and also contain additional information, such as its hash value and a
pointer to its parent. In our model, a block consists of two pieces of information:
a name that uniquely identify the block and the name of the previous block (call
it father) to which it is connected. Therefore the pair {name;father} uniquely
identifies a block. In turn, name is a pair whose first element is the identity of the
miner which mined the block and the second element is a unique numeric label.
For instance, m4,7 represents the name of a block created by the miner m4 with
label 7. The numeric label counts the number of blocks minted by the miner.
The father is encoded by the name of the corresponding block. Henceforth,
{m3,0; m4,7} denotes a block named m3,0 whose previous block is m4,7. We
also consider all blocks of this model as valid 5

3.2 The ledger

The ledger data type is a pair {T;p}, where T is a tree of blocks with each
block pointing to its own parent, and p is a pointer to a leaf at maximal depth
(therefore the name of the corresponding block). The root of the tree is the
genesis block that is denoted by {genesis,0; genesis,0}. The blockchain of
{T;p} is the sequence of blocks starting from p (therefore the last block is the
genesis one). When a miner with a ledger {T;p} receives a block, he connects
the block at his own ledger and, in case the corresponding depth is higher than
the one pointed by p, his updates p. (This is not always possible because the
father of the block maybe not in T.) When a (honest) miner mines a new block,
the corresponding father is set to p and p is updated. In order to define these
operations we use an operator + that has different implementations depending
on its argument types. In particular:

– ledger+block: the first term is a ledger {T;p} and the second is a block b.
The operator adds b to T if the father of the block is already in the chain. If
the block is not present in the chain, the operator does nothing. In case the
chain of b becomes longer than p, p is updated to the name of b.

– ledger+integer: the first term is a ledger {T;p} and the second is an in-
teger n. In this case, the operator + represents the creation of a new block.
In particular, if the miner is honest, it creates a block whose father is p

and whose name is the miner’s name plus n+1 (the new block points to p,
therefore it is at longer depth). The pointer p is updated to the name of the
new block and the number of nodes created by the miner is set to n+1.

5 For a block to be valid it must hash to a value less than the current target one.



Stochastic Modelling and Analysis of Bitcoin 7

– ledger+set: the first term is a ledger {T;p} and the second one a set of
blocks. The operator extracts one element from the set and adds it to the T,
if it is possible. If the block is added then it is removed from the set.

Figure 1. An example of blockchain.

In Figure 1, we represent a ledger with two blocks created by m1 and one
block created by m2. The corresponding blockchain is the one pointed by the
rightmost arrow. Instead the block created by m2 is a valid stale block.

3.3 The Set

The set data type is implemented as a list of blocks without duplications. The
data type has an extraction operation, represented by the operator +, that re-
turns an element of the set (which is extracted randomly) and removes it from
the set. The list is used to maintain, for each miner, the orphan blocks.

4 The Bitcoin Model

In our model, a Bitcoin system is a parallel composition of n miners and two
processes (Hasher and Network) that simulate, respectively, the miner hashing
process and the broadcast of new blocks (see Figure 2). Every process is expressed

Figure 2. The Bitcoin model architecture.



8 Bistarelli et al.

as a CTMC entity because

1. the time spent by a minermi to mine a block can be described by an exponen-
tial distribution 1− e−λmi , where the parameter λmi depends on the miner
hashing power and the difficulty level of the crytopuzzle Nakamoto [21],

2. the communication delay across the Bitcoin network can be also approxi-
mated by an exponential distribution [10].

For the sake of clarity, we are presenting a simplified version of the imple-
mented code6.

1 module Hasher
2 [win] (Hashers_STATE=HasherRes) -> mR : τHasher;
3 [lose] (Hasher_STATE=HasherRes) -> lR : τHasher;
4 endmodule
5
6 module Miner
7 Miner_i_STATE : [Mine ,Winner ,Lost ,Add] init Mine;
8 b : block {m,0; genesis ,0};
9 B : ledger [{genesis ,0; genesis ,0}];

10 c : [0..N] init 0;
11 setMiner_i : set [];
12
13 [win] (Miner_i_STATE=Mine) -> hR_i : (Miner_i_STATE ’= Winner );
14 [lose] (Miner_i_STATE=Mine) -> hR_i : (Miner_i_STATE ’=Lost);
15 [addBlock] (Miner_i_STATE=Winner) ->
16 1 : (c’=c+1)&(b’=B+c)&(B’=B+b)&( Miner_i_STATE ’=Mine);
17 [addBlock] (Miner_i_STATE=Lost) ->
18 rMw_i : (setMiner_i ’= setMiner_i+set)&( Miner_i_STATE ’=Add);
19 [] (Miner_i_STATE=Add) -> 1 : (B’=B+setMiner_i )&( Miner_i_STATE ’=Mine);
20 endmodule

Listing 1. Simplified model of the Hasher and a miner.

The Hasher process is described in lines 1 to 4 of Listing 1. We use it to ab-
stractly represent the PoW made by miners. In particular, miners who want
to solve the crypto-puzzle synchronize with the Hasher which “answers” telling
them if they succeeded or not. The Hasher consists of two transitions: the first
one with action [win] and rate mR is triggered when the synchronizing miner
finds a solution for the PoW ; the second one with action [lose] and rate lR

(lR = 1−mR) is triggered when the synchronizing miner does not find a solution
to PoW.

A Miner, described in Listing 1 line 6 to 20, behaves as follows:

– it may receive a block from the network.
– it may create (e.g. mine) a new block: in our setting, mining a block amounts

to winning the proof of work contest and it is represented by a rate. This rate
indicates the nodes’ rate of generating new blocks. Therefore, it corresponds
to the computational power of miners to solve the cryptopuzzles of the proof-
of-work. In this way we abstract away from the proof-of-work technique for
mining blocks. When a block is created by a miner, it is added to the local
ledger and it is forwarded to all the other miners of the network.

6 The actual implementation can be found here https://github.com/

adeleveschetti/bitcoin-analysis/



Stochastic Modelling and Analysis of Bitcoin 9

– it may try to add blocks stored in his local set to the local ledger.

A Miner has four state variables: B represents its own ledger corresponding tp
the local view of the state of the system; b indicates the last valid block added
to B; setMiner indocates the miner’s local set in which the block received by
the network are stored before being (eventually) added to the local blockchain
B, and c is a counter of the minted blocks.

The Network process is defined in Listing 2.

1 module Network
2 Network_STATE : 0;
3 n : numberOfMiners
4 for e from 0 to n:
5 set_e : set [];
6
7 for i from 0 to n:
8 [addBlock] (Miner_i_STATE=Winner) ->
9 1 :

10 for e from 0 to n:
11 if e != i:
12 set_e ’=set_e+b;
13 endmodule

Listing 2. Simplified model of the Network.

It has one set per miner that stores the messages (the blocks) to be delivered to
the corresponding miner.

As the reader can observe from code in Listing 1, Miner and Hasher synchro-
nize over the win and lose actions. Miner receives from Hasher the answer for
its work, which can be either positive or negative depending on the difficulty of
the problem (represented by the hasher values mR and lR) and the hashing power
of the miner (represented by hR i). Since the rate of a synchronization is equal
to the product of the rates of the two actions, the rate of mining a new block
is mR×hR i, which corresponds to the parameter λmi introduced in the previous
section, and the rate of loosing the competition is lR×hR i

If the miner wins, it changes its status in Winner and creates a new block,
which is used to update its ledger – action addBlock – and to send it to the Net-
work in order to communicate the new block to the other miners (e.g. updating
other miners’ sets with the new block). If the miner looses, its status becomes
Lost and it checks for new blocks in the Network with a certain rate rMw i,
which simulates the latency of the network. If there are new blocks, it adds one
of them, chosen randomly to simulate the delay of the network, to its local set.
Then, the state of the Miner becomes Add and it tries to add the blocks to its
ledger. Finally, its status returns to Mine and the process starts again.

5 Simulations

In this section we discuss the outcome of two probabilistic analyses resulting
from the use of PRISM to model the behavior of Bitcoin. The first analysis
validates our model with respect to Bitcoin; the second one studies the trade-off
between the security and the efficiency/scalability of the network (e.g. we study
the relationship between the probability of reaching a fork and the difficulty of



10 Bistarelli et al.

the cryptopuzzle). We always assume that all miners work honestly; for example,
they never try to mine new blocks and attach them in internal nodes of the ledger.

5.1 Bitcoin coherence

We analyse a system with 16 miners representing the main pools in the Bitcoin
network. To each miner we assign a hashing power (a rate) taking the current
hashing power distribution of Bitcoin illustrated in Figure 3. Figure 4 shows

Figure 3. Hashrate distribution of Bitcoin mining pools on May 2020.
Source: https://www.blockchain.com/.

Figure 4. Probability of mining a block within 3000 seconds.

the probability that a block will be mined in 3000 seconds. As the reader can
observe, the probability of a block being found within 600 seconds is about



Stochastic Modelling and Analysis of Bitcoin 11

63% (or 1 − e−1). In 30 minutes (1800 seconds) a block has about 95% chance
of being found and in 3000 seconds the probability that someone has found
the block is close to 1. We would like to stress that our model follows what is
observed in the real execution of the protocol.7 It is, indeed, well known that
the Bitcoin protocol automatically adjust the difficulty of the cryptopuzzle to
maintain constant, around 10 minutes, the average time between the creation of
two blocks [21].

Figure 5. Probability of reaching a fork of length 1 by varying the broadcast delay.

In Figure 5, we analyze the probability of reaching a state where at least two
different blockchains differ for one block (fork of length 1). The reader may notice
that the probability decreases with the increase of the communication delay
rate. This follows form the remark that the higher is the rate, the smaller is the
expected time for the transition to occur. We notice that, with rate rbroadcast =
0.08, we obtain results in line with those of [10].

Figure 6. Probability of a fork of increasing length.

7 https://en.bitcoin.it/wiki/Confirmation



12 Bistarelli et al.

Figure 6 reports the probability of having forks of increasing length. In this
case, we fix the broadcast delay to rbroadcast = 0.08. As the reader can observe,
the probability to obtain a fork of length 5 is of the order of 10−8, while it is
approximately zero when the length of the fork reaches 6. This is a key result,
because a fork of length 6 is considered to be the longest Bitcoin fork.

5.2 Variation of Cryptopuzzle Difficulty

In this section, we compare the probability of mining new blocks and having a
fork while varying the difficulty of the cryptopuzzle.

Figure 7 highlights the relationship between the probabilities of mining a
block in a specific amount of time with two different difficulty rates D. In par-

Figure 7. Probability of mining a block within 600 seconds.

ticular, the comparison is between a system with Bitcoin difficulty rate (1/600)
and a system where a new block is produced every 12 seconds (1/12). Of course,
the probability that a miner finds a new block in this second system is way higher
than Bitcoin. In particular, after 100 seconds the probability that a miner mines
a new block is 1 when the difficulty rate is 1/12. On the contrary, with the
Bitcoin rate, the probability is less than 0.2.

Figure 8 shows how the probability of reaching longer forks varies when the
difficulty rate changes. We have considered the same difficulty rates of Figure 7.
In this case, the probability of reaching a fork of length 6 with difficulty rate
1/12 is greater than 0, whereas it becomes zero with the difficulty rate of Bitcoin.

Finally, we study how the time required to mine a block varies when we
consider different cryptopuzzle difficulties. The results in Figure 9 confirm that
the easier the cryptopuzzle is, the faster the entire system mines a block.

Since the difficulty of the cryptopuzzle affects the speed, one might be inter-
ested in studying the trade off between speed and security. Figure 10 displays



Stochastic Modelling and Analysis of Bitcoin 13

Figure 8. Probability of forks.

Figure 9. Probability of mining a block within 3000 seconds.

how the probability of reaching a fork of length 1 varies depending on the diffi-
culty parameter. Our results show that a good balance between speed and safety
can be obtained with a difficulty rate equals to 1/500. Indeed, with this rate, the
process of mining a block is faster than in Bitcoin (1/600), but the probability
of reaching a state of fork is not much higher. Even if this is a theoretical result,
it shows that a better trade off between the speed of the mining process and
the security of the network can be obtained. Since mining in Bitcoin is time and
energy consuming, adjusting this trade off may lead to some improvements in
the practice.



14 Bistarelli et al.

Figure 10. Probability of a fork of length 1 with different difficulty parameter.

6 Related Works

The blockchain protocol was introduced by Haber and Stornetta [15] and only in
the last few years, because of Bitcoin, the problem of analyzing the consistency
of the ledgers has caught the interest of several researchers.

In [14], Garay et al. demonstrate the correctness of the protocol when the
network communications are synchronous, focusing on its two key security prop-
erties: Common Prefix and Chain Quality. The first property guarantees the
existence of a common prefix of blocks among the chain of honest players. The
second property constrains the number of blocks mined by hostile players, when
the honest players are in the majority and follow the protocol.

The extension of this analysis to asynchronous networks with bounded de-
lays of communications and with new nodes joining the network has been un-
dertaken in [22]. In the above contributions, the properties are verified by using
oracles that drive the behaviours of actors. Then, combining the probabilistic
behaviours and assuming possible distributions, one computes expected values.
In contrast with the above works, in [24], P̂ırlea and Sergey propose a formaliza-
tion of blockchain consensus focusing on the notion of global system safety. They
present an operational model that provides an executable semantics of the sys-
tem where nondeterminism is managed by external schedules and demonstrate
the correctness by means of a proof assistant.

The main difference between these contributions and our work is that we
formalize the blockchain protocol as a stochastic system (with exponential dis-
tribution of durations) and derive the properties by simulating the model through
the PRISM model checker. As regards stochastic models for blockchain, few re-
cent researches use them to select optimal strategies for maximizing profit of a
player [4, 29], for formalizing interactions between miners as a game [6, 8] and to
check the ability to discard double-spending attacks of blockchain protocols [23].



Stochastic Modelling and Analysis of Bitcoin 15

7 Conclusions and Future Works

In this paper we analyzed the consensus protocol of Bitcoin by resorting to
an extension of the probabilistic model checker PRISM. In particular, we ex-
tended PRISM with a library implementing the notion of block of transactions
and ledger natively: ledger, block and set. Using this extension, we defined a
simple model of the Bitcoin protocol where miners’ behaviours are described as
processes and the whole protocol as a parallel composition of miners.

Then we performed two probabilistic analyses covering different features of
the protocol. The first one assessed the coherence of our model by verifying that
the probability of mining a new block within a given amount of time and that of
reaching a fork correspond to that of the real Bitcoin system and to the values
available in the literature. The second analysis has been concerned with the
trade-off between the security and the difficulty of the cryptopuzzle. It pointed
out that slightly decreasing the difficulty level of the cryptopuzzle increases the
speed of mining at the cost of an almost irrelevant increase of the probability of
a fork. To the best of our knowledge, we are the first to use a model checker to
study properties of Bitcoin.

The security of blockchains has received much attentions in the last few years
and various types of attacks have been found. In this work we restricted our anal-
ysis to systems where all miners are honest and work to extend the blockchain.
In future research, we plan to study these security issues by considering both
peer-to-peer network based attacks and mining-based attacks. The first type of
attacks, e.g. Eclipse attack [16] and Sybil attack [11], can be modeled by changing
the behavior of the Network process, whereas the second one, e.g. 51% attack,
can be analyzed introducing malicious Miner processes.

As further future work, we plan to extend our PRIM";"""date"",""2020-06-03T08:38:22Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""2"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.5""
""xmp:CreatorTool"",""TeX""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dcterms:created"",""2020-06-03T08:38:22Z""
""language"",""en""
""Last-Modified"",""2020-06-03T08:38:22Z""
""dcterms:modified"",""2020-06-03T08:38:22Z""
""dc:format"",""application/pdf; version=1.5""
""Last-Save-Date"",""2020-06-03T08:38:22Z""
""pdf:docinfo:creator_tool"",""TeX""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2020-06-03T08:38:22Z""
""meta:save-date"",""2020-06-03T08:38:22Z""
""pdf:encrypted"",""false""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.20 (TeX Live 2019) kpathsea version 6.3.1""
""modified"",""2020-06-03T08:38:22Z""
""Content-Length"",""905989""
""pdf:hasMarkedContent"",""false""
""Content-Type"",""application/pdf""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.20 (TeX Live 2019) kpathsea version 6.3.1""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""trapped"",""False""
""meta:creation-date"",""2020-06-03T08:38:22Z""
""created"",""2020-06-03T08:38:22Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""17""
""Creation-Date"",""2020-06-03T08:38:22Z""
""resourceName"",""StochasticModellingBitcoin.pdf""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""2179"",""2809"",""2665"",""2468"",""1838"",""2376"",""944"",""2139"",""2145"",""634"",""969"",""1601"",""655"",""1768"",""2550"",""2242"",""2408""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""producer"",""pdfTeX-1.40.20""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""pdfTeX-1.40.20""
""pdf:docinfo:created"",""2020-06-03T08:38:22Z""
";https://scholar.google.ch/scholar?start=880&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098734-38;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Secure smart contract generation based on petri nets;N Zupan, P Kasinathan, J Cuellar, M Sauer ; Blockchain Technology for …, 2020  Springer;;"… In particular, we see that in many blockchain use cases we need external information and this

can be provided into the Petri Nets model via Oracle places; in other … We explain in detail how

we use oracles, transitions extended with guarded commands and other Petri Nets …";Cité 4 fois;Les 4 versions;[PDF] inatel.br;https://biblioteca.inatel.br/cict/acervo%20publico/sumarios/Ebooks/Springer%20Text%20books%20-%20Organizado%20por%20ano/2020_Blockchain%20and%20Industry%204.0_%20Overview%20-%20convergence%20-%20and%20Analysis.pdf#page=79;"
Blockchain Technologies

Blockchain 
Technology for
Industry 4.0

Rodrigo da Rosa Righi
Antonio Marcos Alberti
Madhusudan Singh Editors

Secure, Decentralized, Distributed
and Trusted Industry Environment



Blockchain Technologies

Series Editors

Dhananjay Singh, Department of Electronics Engineering, Hankuk University of
Foreign Studies, Yongin-si, Korea (Republic of)
Jong-Hoon Kim, Kent State University, Kent, OH, USA
Madhusudan Singh, Endicott College of International Studies, Woosong
University, Daejeon, Korea (Republic of)



This book series aims to provide details of blockchain implementation in technology and
interdisciplinary fields such asMedical Science,AppliedMathematics, Environmental Science,
Business Management, and Computer Science. It covers an in-depth knowledge of blockchain
technology for advance and emerging future technologies. It focuses on the Magnitude: scope,
scale & frequency, Risk: security, reliability trust, and accuracy, Time: latency & timelines,
utilization and implementation details of blockchain technologies. While Bitcoin and
cryptocurrency might have been the first widely known uses of blockchain technology, but
today, it has far many applications. In fact, blockchain is revolutionizing almost every industry.
Blockchain has emerged as a disruptive technology, which has not only laid the foundation for
all crypto-currencies, but also provides beneficial solutions in other fields of technologies. The
features of blockchain technology include decentralized and distributed secure ledgers,
recording transactions across a peer-to-peer network, creating the potential to remove
unintended errors by providing transparency aswell as accountability. This could affect not only
the finance technology (crypto-currencies) sector, but also other fields such as:

Crypto-economics Blockchain
Enterprise Blockchain
Blockchain Travel Industry
Embedded Privacy Blockchain
Blockchain Industry 4.0
Blockchain Smart Cities,
Blockchain Future technologies,
Blockchain Fake news Detection,
Blockchain Technology and It’s Future Applications
Implications of Blockchain technology
Blockchain Privacy
Blockchain Mining and Use cases
Blockchain Network Applications
Blockchain Smart Contract
Blockchain Architecture
Blockchain Business Models
Blockchain Consensus
Bitcoin and Crypto currencies, and related fields

The initiatives in which the technology is used to distribute and trace the communication start
point, provide and manage privacy, and create trustworthy environment, are just a few
examples of the utility of blockchain technology, which also highlight the risks, such as
privacy protection. Opinion on the utility of blockchain technology has a mixed conception.
Some are enthusiastic; others believe that it is merely hyped. Blockchain has also entered the
sphere of humanitarian and development aids e.g. supply chain management, digital identity,
smart contracts and many more. This book series provides clear concepts and applications of
Blockchain technology and invites experts from research centers, academia, industry and
government to contribute to it.
If you are interested in contributing to this series, please contact msingh@endicott.ac.kr OR

loyola.dsilva@springer.com

More information about this series at http://www.springer.com/series/16276

mailto:msingh@endicott.ac.kr
mailto:loyola.dsilva@springer.com
http://www.springer.com/series/16276


Rodrigo da Rosa Righi •

Antonio Marcos Alberti •

Madhusudan Singh
Editors

Blockchain Technology
for Industry 4.0
Secure, Decentralized, Distributed
and Trusted Industry Environment

123



Editors
Rodrigo da Rosa Righi
Universidade do Vale do Rio dos Sinos
Sao Leopoldo, Brazil

Antonio Marcos Alberti
ICT Lab
Information and Communications
Technologies (Inatel)
Santa Rita do Sapucai, Minas Gerais, BrazilMadhusudan Singh

Endicott College of International Studies
Woosong University
Daejeon, Korea (Republic of)

ISSN 2661-8338 ISSN 2661-8346 (electronic)
Blockchain Technologies
ISBN 978-981-15-1136-3 ISBN 978-981-15-1137-0 (eBook)
https://doi.org/10.1007/978-981-15-1137-0

Š Springer Nature Singapore Pte Ltd. 2020
This work is subject to copyright. All rights are reserved by the Publisher, whether the whole or part
of the material is concerned, specifically the rights of translation, reprinting, reuse of illustrations,
recitation, broadcasting, reproduction on microfilms or in any other physical way, and transmission
or information storage and retrieval, electronic adaptation, computer software, or by similar or dissimilar
methodology now known or hereafter developed.
The use of general descriptive names, registered names, trademarks, service marks, etc. in this
publication does not imply, even in the absence of a specific statement, that such names are exempt from
the relevant protective laws and regulations and therefore free for general use.
The publisher, the authors and the editors are safe to assume that the advice and information in this
book are believed to be true and accurate at the date of publication. Neither the publisher nor the
authors or the editors give a warranty, expressed or implied, with respect to the material contained
herein or for any errors or omissions that may have been made. The publisher remains neutral with regard
to jurisdictional claims in published maps and institutional affiliations.

This Springer imprint is published by the registered company Springer Nature Singapore Pte Ltd.
The registered company address is: 152 Beach Road, #21-01/04 Gateway East, Singapore 189721,
Singapore

https://doi.org/10.1007/978-981-15-1137-0


Contents

History of Industrial Revolutions: From Homo Sapiens Hunters
to Bitcoin Hunters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Hasan Tinmaz

Blockchain and Industry 4.0: Overview, Convergence,
and Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Thiago Bueno da Silva, Everton Silva de Morais,
Luiz Felipe Fernandes de Almeida, Rodrigo da Rosa Righi
and Antonio Marcos Alberti

Blockchain Technology for Data Management in Industry 4.0 . . . . . . . . 59
Madhusudan Singh

Secure Smart Contract Generation Based on Petri Nets . . . . . . . . . . . . 73
Nejc Zupan, Prabhakaran Kasinathan, Jorge Cuellar and Markus Sauer

Blockchain for Machine to Machine Interaction in Industry 4.0 . . . . . . 99
CĂŠlio MĂĄrcio Soares Ferreira, Ricardo Augusto Rabelo Oliveira,
Jorge SĂĄ Silva and Carlos Frederico Marcelo da Cunha Cavalcanti

Blockchain-Based Crowdfunding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
Hasnan Baber

Engineering 4.0: Future with Disruptive Technologies . . . . . . . . . . . . . . 131
Pooja Khanna and Sachin Kumar

The Opportunities of Blockchain in Health 4.0 . . . . . . . . . . . . . . . . . . . 149
Prateeti Mukherjee and Dhananjay Singh

v



History of Industrial Revolutions: From
Homo Sapiens Hunters to Bitcoin
Hunters

Hasan Tinmaz

Abstract Homo sapiens have become the leading force of the earth by their abil-
ity of transformations. Initial hunter-gatherers transformed to agriculture-oriented
small groups which finally led to early of civilizations. Civilizations produced more
complex social human lives in the forms of cities and states. In distinct geographical
areas, humans discovered new tools and methods to make their lives better. In that
search for “effectiveness”, humans tended to spend less (force, money or time) but
achieve more. At the end of thousand years of this tendency, 18th century became
the witness of early industrial revolution efforts. It was defined as a revolution due to
its game-breaker or disruptive nature. Besides, it was associated with the term indus-
try, since the source of power shifted from humans to different tools or machines.
From that time to the current date, many scholars divide that timeline into four time-
zones by considering the most disruptive technology of the time. In that manner, the
first industrial revolution has linked to steam engines (using the power of water).
The second revolution has associated to the electricity for assembly lines and mass
production. The third revolution has been connected to computer technologies form-
ing automation and lastly the fourth industrial revolution has been named with its
capacity for cyber-physical system development with the application of advanced
technologies. In those four revolutions, we can realize two essential points; the latter
revolution has been stemming from the advancements in former revolution and the
total time of revolution has becoming shorter. Therefore, it is clear that the effects of
Industry 4.0 revolution will be widespread in public very soon. Among all the other
high level technologies, blockchain technology which could be perceived as one of
the most complicated and ultimate level of Industry 4.0 implementations could be
listed as the last but not the least historical advancements for human beings.

H. Tinmaz (B)
Technology Studies—Endicott College of International Studies, Woosong University, Daejeon,
South Korea
e-mail: htinmaz@endicott.ac.kr

Š Springer Nature Singapore Pte Ltd. 2020
R. da Rosa Righi et al. (eds.), Blockchain Technology for Industry 4.0,
Blockchain Technologies, https://doi.org/10.1007/978-981-15-1137-0_1

1

http://crossmark.crossref.org/dialog/?doi=10.1007/978-981-15-1137-0_1&domain=pdf
mailto:htinmaz@endicott.ac.kr
https://doi.org/10.1007/978-981-15-1137-0_1


2 H. Tinmaz

1 Introduction

Human history has been written in many different ways; civilizations’ history, reli-
gions’ history, finance history and so forth. While writing about these histories, they
have been either finalized or kept stable for a long time. On the other hand, writing
about technology related histories is very challenging, since the technology changes
more rapidly than our expectations. Moreover, the technology history of humans
has not been experienced the same way in different parts of the planet. As some
countries are working on spaceships projects, some other countries are dealing with
better waterline or electricity projects.

In order to understand that digitally divided situation, the author believes that we
need to visit the early history of human-beings. Although different sources point out
different timelines for the first homo-sapiens on earth, recent discoveries by famous
archeologists Peter Benedict and Halet Çambel in 1963 unfolded a new Neolithic
period settlement in modern day of Turkey; ‘Gobekli Tepe’ which is dated back
between 12000 and 10000 BC (Fig. 1a). As a center of human gathering, Gobekli
Tepe has changed the history of human civilizations (Fig. 1b) [4].

Initial homo-sapiens were having survival challenges such as finding food, shel-
ter or protection. By developing their first social and communication skills, homo-
sapiens were altered from individuals than to groups. These new groups of homo-
sapienswere hunter-gatherers. Initial success of group dynamics guided these hunter-
gatherers was followed by the development of agricultural centers (they were neither
villages nor cities inmodern terms). Themore they experienced agriculture, themore
they learned about development of new tools for each step of farming. In that sense,
these tools could be named as the very first technological advancements in human
history. By having more food and safety, humans initiated their first civilizations
around bigger groups [14].

Fig. 1 a Gobekli Tepe complex, b one pillar in Gobekli Tepe



History of Industrial Revolutions … 3

The ability of feeding more people and providing more food triggered an increase
in the capacity of labor force. That working groups constructed bigger living centers
where we can call cities in today’s terms [34]. These cities were not only bigger
in population, but also bigger in the opportunities/services provided. For example,
first schooling started in cities or a wealthier job opportunity in the state or city
administration was appeared in that cities. As a result, more people moved from
rural areas to urban areas.

That shift toward urban areas has still been continuing for centuries and unfolding
several overt or covert outcomes for humans. First of all, the increase in labor force
for cities has been pushing people to kick off first industrial attempts. It may not be
very plausible to call these attempts as factories, but there at least exists of group of
people producing similar materials or tools. Besides, the cities have been demanding
more food to offer these new labor forces. Totally, an increase in capital formation
and exchange has been formed around cities. That financial capital has finally turned
out to be investments in different industries.

As a result, humanity met with industrial revolutions starting from mid 18th cen-
tury. Industrial revolutions primarily altered muscle based production to mechanical
power which was followed by augmented cognitive power in production [34].

Last but not least, we can conclude that without finalization of agricultural revolu-
tion settlement, it would be highly challenging to fully achieve industrial revolutions.
That could be seen how certain countries have been experiencing different timelines
on industrial revolutions.

2 Industrial Revolutions at Glance

Understanding industrial revolution cannot be separated from centralization of the
technology as a concept. Hence, industrial revolution can also be defined as industrial
utilization of different technologies. The industrial revolutions have shaped the way
we live today. ‘Industrial Revolution’ as a concept could be defined in various differ-
ent ways. According Britannica Encyclopedia [5], the term “Industrial Revolution”
was named by Arnold Toynbee (1852–1883) referring to the economical progress
in Britain from 1760 to 1840. According to Tomory [42], industrial revolution as a
concept indicates economical changes in England as a result of technological inno-
vation from 1760 to 1830. Essentially, it characterizes an enormous change in how
humans perform their manufacturing, business or any other industrial actions. In
another way of depiction, industrial revolution could be perceived as a significant
shift in producing things manually to factory situated serial production.

Understanding industrial revolutions requires another clarification on ‘evolution’
versus ‘revolution’ terms. Evolution also refers to change, yet it happens gradually as
a process. Hence, when an analog dial-up phone changes to a digital digital-up phone,
it is an evolutionary change from one phase to another phase. On the other hand,
when these phones change mobile/smart phones, the change is radical and affects the
fundamentals of phone technologies. In that sense, mobile phone technology could



4 H. Tinmaz

be labeled as a revolution. Hence, a revolution represents an “…abrupt and radical
change” [34]. In 2019, Samsung authorities are demonstrating new foldable phones
which could be marked as evolutionary approach to phone technologies. Last but not
least, it is clear that revolutions are followed by several additional evolutions.

From the social part of human history, industrial revolutions have altered innate
traditional and hierarchical social structure of nations.Although there is no consensus
about the underlying reasons of these changes, it is clear that people started to question
their social roles and positions as they were becoming financially more independent.
French Revolution of 1789, which was also listed as one of the triggers toward
industrial revolution, remarked as another contributor to that change as well [13].
Possible overt outcomes of these changes could be listed as; the shift from lower
income class tomiddle income class level formore people, the increase in the average
life span (which was even lowered to 38 in British cities), the educational endeavors
overcoming the new jobs’ required skills and abilities and democratization (including
labor unions and employee rights agreements).

By considering the industrial changes from past to the present, it is possible to
delineate industry revolutions in four phases;

• Industry 1.0 as the initial attempts toward mechanization supported by the steam
engines of water power,

• Industry 2.0 as the period of electricity guided, assembly line supported mass
production,

• Industry 3.0 as the stage of computer technologies leading effective automated
systems,

• and lastly, Industry 4.0 as current phase of industrial revolutionswhich is associated
to cyber physical systems.

From steamengines to advanced digital productions, these industrial revolutions have
disseminated drastic changes in different processes and procedures of manufacturing
systems [7].

Before we move forward to scrutinize each industrial revolution separately, it
is important to remind that there is no sharp cutting edge between those industrial
revolutions. Therefore other than thinking a linear developmental phases of these
industrial revolutions, it is better to perceive them in a spiral or curve-linear time-
line (similar approach to Harari [14] explaining the history of humankind) (Fig. 2).
Besides, not all the countries or all the world citizens are experiencing the effects of
industrial revolutions together. While some countries give the impression of Industry
2.0 endeavors, some other countries discuss about advanced stages of Industry 4.0
infusion to different sectors.

3 Industry 1.0—the Mechanical Period

As a consensus, first industrial revolution has been believed to start in England
and disseminated to Europe continent and then the rest of the world. After Britain,



History of Industrial Revolutions … 5

Fig. 2 The spiral history of
industrial revolutions

industrial revolution developments jumped to mainland Europe, especially Belgium
and France. Germany and the rest of the European countries were not fast followers
of these advancements. Many scholars agree that first industrial revolution began in
England which unfolded a radical change from an agricultural society to industrial
society [7].

Two main changes of Industry 1.0 revolution were dominance of machine based
production over manual productions and dominance of factory massive production
over small scale workshop manufacturing. As a result, Industry 1.0 enabled the
growth for economies which changed the dynamics of previous economical relation-
ships. Factory is a termcommonlyused for contemporarybigbuildings surroundedby
tall towers/chimneys, comprising an immense number of people working, encircled
by many transportation devices like trucks, producing mass amount of everything.
On the other hand, factories of 18th or 19th centuries were small shops where a
small group of people, who were trained for specific manufacturing processes, was
manually producing only certain things [38].

Since new cities demand more rawmaterials for production, railroad construction
became a priority for transportation. In parallel to evolving fromagricultural period to
industrialized period, it was obvious to find alternative transportation methods (espe-
cially against animal power provided logistics). Therefore, an innovative method of
steam engines was utilized on these railroads [34]. Steam engines mechanism fun-
damentally works by coal fire stimulating water vaporization leading to pumping of
cylinders and pistons integrated in the locomotives. As a note, steam engine triggered
transportation yielded an obvious dependence on coal mines and coal production as
well.

The coal for the steam engines was initially transported by animal-dominant
power, such as horse wagons. On the other hand, that was very expensive and the
amount of coal was very limited in comparison to the overall demand. After using



6 H. Tinmaz

coal based steam engines for transportation, that situation changed deeply that more
coal moved easily to far distances with lower costs, which reflected on decreasing
general trade costs and effect of first industrial revolution disseminated to other
countries and continents [37].

Although stem engines were not forgotten by their contribution to railroad trans-
portation, steam engineswere actually serving awide range of other industries aswell
(Fig. 3). Thus, steam engines could be perceived as a key power for Industry 1.0 but
addressing the needs of other industries as an all-purpose technology. Since steam
engines were changing heat energy to mechanical energy, all industries requiring
mechanical energy were in need to utilize steam engines. For instance, ship industry
was radically altered by the shift from sailing to steam empowered energy. While
travelling/logistics to longer distances became possible and shorter in time, workers
of that ship industry were learning new skills and becoming more engineer-wise
workers than regular sailors [8].

Another field of productionwhichwas affected innately from Industry 1.0 changes
in England was the cotton/textile industry. Two fundamental processes of cotton
based productions; spinning and weaving, were shifted from home-based manual
tasks tomachine guided industries.Moreover, new steam engine based ironmachines
were yielding mass production of textile manufacturing [43].

Fig. 3 Steam locomotive [24]



History of Industrial Revolutions … 7

4 Industry 2.0—the Electrical Period

While first industrial revolution was leading the formation of an industry culture
paying attention to quality, competence and amounts, second industrial revolution
culture was focusing on new and advanced production management methods for the
progress of quality and products [16]. Industry 2.0 is associated by two concepts;
advancements in electricity as a new source of energy and mass-production via
assembly lines as an implementation of electricity to production [34].

As an innovative effect of first industrial revolution’s transportation opportuni-
ties (such as steamboats), the second industrial revolution witnessed an important
shift from the dominance of regional agricultural communities to geographically
accessible, industry oriented, skill based, connected communities [11]. Therefore,
it was easy to transfer labor force (immigrants) and industrial developments from
Europe to the United States. In that sense, second industrial revolution is associated
with the United States whereas the first industrial revolution is labeled with the UK
dominantly.

The generally accepted start for the second industrial revolution is the mass pro-
duction age in the USA. As a result of enhanced transportation network with steam
engines and USA’s new prosperous natural resources from new regions, transporta-
tion of any type of rawmaterials, products and workers became very straightforward.
Moreover, according to the Library of Congress sources, fourteen million people
immigrated to this new country from 1860 to 1900. Hence, relatively in short time,
USA possessed an immense number of human resources whom can work in a wide
range of industries in all over the country [40].

Henry Ford’s automobile factory was first implemented that mass-production
approach which was later widely adopted during post-World War II period. In this
period, the influences of Keynesian spending policies were dominant. High uses of
assembly lines created new economical issues around mass production and mass
consumption dilemma (Fig. 4). The characteristic feature of this period was the pres-
ence of the sliding assembly line systems which were allowing massive production
of a single outcome in a short period of time. Due to this one-type production feature,
in the following years, factories failed to address the diversity in local/global com-
petitions and diversification in consumer preferences. Hence, this system collapsed
in mid 70s [1].

During Industry 2.0 period, many American inventors contributed to existing
technologies guidingmany other personal and professional changes in transportation,
communication andmanufacturing. For example, Alexander GrahamBell invented a
machine which can transfer human voice for distances, which we call it as telephone
today. Furthermore, Thomas Edisonwas becoming the father of electricity and newly
developed other technologies (such as the light bulb or electric dynamo), while
contributing the existing technologies at hand, such as telegraph, as well [40].

The second industrial revolution observed several technological innovations
which were mutually affecting each other in development. In 1870s, the telephone,
electrical lighting and typewriters were invented. In 1880s, first elevators and steel



8 H. Tinmaz

Fig. 4 The assembly lines of the Bell Aircraft Corporation in 1944 (the United States Library of
Congress’s Prints and Photographs division)

structures for the buildingswere at the stage andmaking the construction of skyscrap-
ers possible. Afterwards, in the formof fundamental filming industry, the phonograph
and motion pictures were developed. Steam powered engines were starting to be
replaced by the electric generators where fridges and washing machines were sup-
portedwith that new engines.Another engine related change in 1890swas the internal
combustion engines which contributed to the later invention of first automobiles and
airplanes [11].

Another important change in this periodwas about replacements inworkers’ skills
and abilities. After the infusion of electricity into different industries, the ways of
performing job tasks also altered dramatically. In that case, workers had to learn
new skills either to keep their existing job (although the job and related tasks were
not the same as before) or to find jobs in newly shaped industries [8]. Many people
started working around assembly lines in big companies where each individual was
functioning like a robot for continuously repetitive one small task of production. In
most cases, workers, who were dominantly men, were working in very unhygienic
and hazardous conditions. Hence, after a certain time,menwere supported bywomen
labor force. Regrettably, child labor was also becoming common issue for the society.



History of Industrial Revolutions … 9

Although mass production and all other developments were bringing several
advantages for the countries, the governments were not generous enough to compen-
sate the hard work of the employees. For instance, some US companies were making
their employees to work up to sixteen hours for seven days in a week or shifts were
so tight that employees could not get rest in between. Moreover, working conditions
were not safe, hygienic or human-friendly. Due to lack of labor unions in many cases
and lack of health insurances, the employee rights were not either not protected or
maintained.

5 Industry 3.0—the Computers

The failure in one type production on assembly lines triggered more programmable
machines so that the existing production systems could address customers’ diversified
needs. These programmable machines were changed their names to computers or
robots and the period of Industry 3.0 began [1]. Industry 3.0 witnessed a series of
technological developments in a relatively short time starting from improvements in
semiconductors and leading mainframe computers in mid 60s, personal computers
in mid 70s (Fig. 5) and finally the Internet in 90s [34].

The third industrial revolution has resulted in the development of automated
machines in subsequent to the invention of transistors and integrated circuits. In
that period, Programmable Logic Controller (PLC) was the trigger of this automa-
tion progress from 1960s [16]. The more different electronic devices (also called
as hardware) adjusted to manufacturing processes and systems, the more programs

Fig. 5 Early version of IBM PC (Model 5150)



10 H. Tinmaz

(also known as software later on) needed to enable these devices. Thus, the innova-
tions in the electronic devices have created the software market with all its derivates
for different industries, such as ERP (enterprise resource planning), SCMS (supply
chainmanagement systems), TPS (transaction processing systems) or IMS (inventory
management systems).

The drastic changes in hardware and enduring demand from different industries
for automation have stimulated different software products for manufacturing. The
demand toward these innovative manufacturing software and hardware systems have
decreased their prices and promoted awider range of utilization not only in developed
countries but also in developing states as well.

Generally, the third industrial revolution has been advanced by USA founded
information and communication technologies companies focusing on the Internet
and mobile technologies more than ever before. In addition to that hardware issues,
the developers have been addressing the social dimension of computing as well.
With the advancements of social media, advance technologies have been infused into
daily human lives. Especially mobile technologies (Fig. 6) and related fields such as
artificial intelligence, smart audio and visual designs and gaming fields have gained
a special importance. Hence, it has been comprehensible that the third industrial
revolution has the potential to influence all other industries ultimately.

The industry culture in the third revolution has been specified on better accuracy,
augmented pace and decreased effort [16]. In parallel to technological advancements,
general public have started to question mass production techniques and looking for
more customized and user-friendly products. The customization efforts have had
an effect on many industries such as construction, architecture, health, fashion and
education. For instance; one of the most important dimensions of Industry 3.0 has
been observed in biotechnology field where scientists have started the discovery of
human genome (all the genes a human has) system mysteries with big data analytics

Fig. 6 Nokia 9110 and 9000



History of Industrial Revolutions … 11

working on supercomputers and advanced software such as Hadoop. Genome studies
have started around 1990s and the full sequence of genome was accomplished in
2003, April where $2.7 billion spent during the entire project. Eventually, Human
Genome Project has discovered that we have 20,500 genes in our body [23].

The third industrial revolution has experienced many innovations, evolutions and
changes. Table 1 shows a summary of major events or developments within the
history of Industry 3.0 [6, 22, 36, 39].

On the other hand, industrial revolutions have altered human history in way that
people have realized that they could utilize, manipulate and change the environmen-
tal elements. Unfortunately, until the mid 20th century, people did not realize how
much they have been damaging the nature as they experience industrial revolutions.
Therefore, starting from Industry 3.0 and expanding to Industry 4.0 actions, people
have initiated new consensus toward green technologies, nature-friendly devices and
less carbon dioxide emission factories.

Third industrial revolution has been experiencing new type of energy; nuclear
energy. Human beings were witnessed the power of nuclear energy in two atomic
bombs to Hiroshima and Nagasaki. Then Chernobyl nuclear reactor accident (1986)
showedhowmuch it could damage the nature, humans and animals. Recently after the
big earthquake in Japan, Fukushima nuclear reactor (2011) could not struggle with
tsunami effects. In spite of these adverse events, nuclear energy is still perceived as an
effective energy source within the fourth industrial revolution context. Additionally,
solar energy has become an essential source starting from Germany and China.
Besides, wind turbulences have been widespread in countries where air conditions
yield strong winds, such as the Netherlands or Jeju Island in South Korea.

6 Industry 4.0—the Digitalization Period

The term ‘Industry 4.0’ was firstly unfolded at the Hannover Fair (Germany) in
2011 referring to how advancements in technologies would deeply change “… the
organization of global value chains” [34]. Even though Industry 4.0 (as a term from
Germany) is commonly welcomed by stakeholders, similar concepts have also been
derived to refer digitalization of production in this era [32] (Fig. 7).

One of these terms is ‘Industrial Internet’ which was coined by General Electric
(GE) Company in late 2012. Originally, GE has been aiming to bring digitalization to
their core operations through their new software business and the Internet of Things
approach [17]. Furthermore, GE believes that Industrial Int";"""date"",""2020-06-16T13:40:35Z""
""pdf:PDFVersion"",""1.6""
""xmp:CreatorTool"",""Adobe InDesign 14.0 (Windows)""
""pdf:docinfo:title"",""478482_1_En_Print.indd""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""false""
""xmpMM:History:Action"",""converted"",""converted""
""language"",""en""
""dc:format"",""application/pdf; version=1.6""
""pdf:docinfo:creator_tool"",""Adobe InDesign 14.0 (Windows)""
""access_permission:fill_in_form"",""false""
""xmpMM:History:When"",""2019-12-21T11:23:46Z"",""2019-12-21T11:24:34Z""
""pdf:encrypted"",""true""
""dc:title"",""478482_1_En_Print.indd""
""xmp:CreateDate"",""2019-12-21T09:36:17Z""
""modified"",""2020-06-16T13:40:35Z""
""xmpMM:History:SoftwareAgent"",""pdfToolbox"",""pdfToolbox""
""pdf:hasMarkedContent"",""false""
""xmpMM:History:InstanceID"",""uuid:87a523ae-eb9c-48b6-805f-9c8517f6a8a3"",""uuid:748acdb2-0479-4fb5-b7e4-9a1510daa3c4""
""xmp:ModifyDate"",""2020-06-16T10:40:35Z""
""pdf:docinfo:creator"",""Pagination_Cover""
""meta:author"",""Pagination_Cover""
""meta:creation-date"",""2019-12-21T04:06:17Z""
""created"",""2019-12-21T04:06:17Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-12-21T04:06:17Z""
""resourceName"",""2020_Blockchain%20and%20Industry%204.0_%20Overview%20-%20convergence%20-%20and%20Analysis.pdf""
""Author"",""Pagination_Cover""
""producer"",""Acrobat Distiller 10.0.0 (Windows)""
""pdf:docinfo:producer"",""Acrobat Distiller 10.0.0 (Windows)""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""1"",""2"",""0"",""0"",""0"",""1"",""0"",""0"",""13"",""13"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""access_permission:modify_annotations"",""false""
""dc:creator"",""Pagination_Cover""
""dcterms:created"",""2019-12-21T04:06:17Z""
""Last-Modified"",""2020-06-16T13:40:35Z""
""dcterms:modified"",""2020-06-16T13:40:35Z""
""title"",""478482_1_En_Print.indd""
""xmpMM:DocumentID"",""uuid:e8769ceb-5ae8-4277-844f-47ddad59dcc0""
""Last-Save-Date"",""2020-06-16T13:40:35Z""
""pdf:docinfo:modified"",""2020-06-16T13:40:35Z""
""meta:save-date"",""2020-06-16T13:40:35Z""
""Content-Length"",""5096506""
""Content-Type"",""application/pdf""
""xmp:MetadataDate"",""2020-06-16T10:40:35Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Pagination_Cover""
""dc:language"",""EN""
""pdf:producer"",""Acrobat Distiller 10.0.0 (Windows)""
""access_permission:assemble_document"",""false""
""xmpTPg:NPages"",""169""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""193"",""286"",""2405"",""160"",""1671"",""964"",""2076"",""1731"",""2773"",""2434"",""1806"",""1267"",""2845"",""1272"",""1390"",""1847"",""2651"",""2535"",""2936"",""1828"",""3173"",""1896"",""1155"",""1532"",""3092"",""1650"",""1736"",""1448"",""2642"",""2279"",""3370"",""2424"",""1601"",""2650"",""2376"",""1922"",""1495"",""1959"",""2773"",""3119"",""3234"",""2762"",""1423"",""2579"",""2955"",""2731"",""3039"",""2991"",""2952"",""2686"",""2742"",""3074"",""2951"",""3079"",""2824"",""3114"",""2502"",""2839"",""496"",""2225"",""2735"",""3195"",""3381"",""1327"",""1461"",""1130"",""1128"",""1242"",""1159"",""1447"",""907"",""333"",""1272"",""1725"",""1243"",""1264"",""1752"",""1688"",""1786"",""2487"",""2823"",""3066"",""2727"",""2463"",""1549"",""1996"",""2535"",""1700"",""1907"",""2893"",""1837"",""721"",""2640"",""2418"",""2262"",""1045"",""2907"",""2222"",""1604"",""1802"",""1808"",""3343"",""3514"",""220"",""1550"",""2519"",""2286"",""2312"",""2254"",""2462"",""1087"",""2902"",""2551"",""2748"",""2852"",""2613"",""2050"",""2582"",""2183"",""2815"",""3570"",""418"",""2044"",""1623"",""2482"",""2250"",""2521"",""1177"",""2837"",""3036"",""2732"",""3105"",""1723"",""2630"",""3318"",""946"",""1928"",""3172"",""958"",""1376"",""2376"",""1340"",""2578"",""2572"",""2266"",""1484"",""1307"",""2382"",""2253"",""2182"",""2437"",""3419"",""1873"",""2077"",""2408"",""1182"",""2795"",""2839"",""2146"",""2353"",""68"",""2693"",""1946"",""2567"",""2735"",""2815"",""2788"",""2941"",""2037""
""access_permission:extract_content"",""false""
""access_permission:can_print"",""false""
""access_permission:can_modify"",""false""
""pdf:docinfo:created"",""2019-12-21T04:06:17Z""
";https://scholar.google.ch/scholar?start=580&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098884-378;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Distributed Ledger Technologies in Logistik und Supply Chain Management im Kontext von Datensicherheit und Datenqualität;M Stange ; monami.hsmittweida.de;;"… Nur durch eine Protokolländerung (Hard Fork) der gesamten Ethereum-Blockchain konnte der

Schaden … Firma ChainLink angewandt wird, ist die Verteilung von Da- tenquellen und Oracles.

Einfach ausgedrückt, wer- den für ein Oracle verschiedene Datenquellen ge- nutzt und …";Les 2 versions;Version HTML;[PDF] hs-mittweida.de;https://monami.hs-mittweida.de/files/11869/Druckversion_Stange_Paper.pdf;"
DISTRIBUTED LEDGER TECHNOLOGIES IN LOGISTIK UND SUPPLY CHAIN  
MANAGEMENT IM KONTEXT VON DATENSICHERHEIT UND DATENQUALITÄT 

Maximilian Stange 
Fraunhofer Institut fĂźr Werkzeugmaschinen und Umformtechnik IWU,  

Reichenhainer Straße 88, D-09126 Chemnitz 

In der Anfangszeit der Distributed Ledger Technologies (DLT) waren die hauptsächlichen Betrachtungswinkel die der 
Disruption des Bank- und Finanzwesens. Mit dem Aufkommen des Systems Ethereum im Jahr 2015, hat die Auseinan-
dersetzung mit der Anwendung von Blockchain in weiteren Branchen, an Bedeutung gewonnen. Eine davon ist die Lo-
gistik und das Supply Chain Management (SCM). Gerade in Deutschland spielt der Logistiksektor eine große Rolle, nach 
der Beschäftigtenzahl ist er die drittgrößte Branche und erzielt einen Umsatz von rund 258 Milliarden Euro. Im Beitrag 
werden konkrete Anwendungsfelder identifiziert und gezeigt welche potentiellen Vorteile sich dort, durch den Einsatz 
von DLT, erzielen lassen. Ein Schwerpunkt liegt dabei auf der Einschätzung der Technologie hinsichtlich ihrer Sicher-
heitseigenschaften. Im Beitrag wird den Fragen nachgegangen, ob Datensicherheit mithilfe von DLT verbessert werden 
kann und auf welchem Wege.  
 
 
1. Einleitung 

Bitcoin hat es im Jahr 2017 geschafft der breiten Öf-
fentlichkeit ein Begriff zu werden. Das liegt vor allem 
an der enormen Wertsteigerung, die die Kryptowäh-
rung zu einem begehrten Investment gemacht haben. 
Die den Kryptowährungen zugrundeliegende Tech-
nologie ist als Blockchain bekannt. Sie ist, vereinfacht 
ausgedrückt, „ein Medium für digitale Werte“, das 
diese durch kryptografische Verfahren schĂźtzt.  

Anhand des Aufkommens von digitalen Währungen 
ist ersichtlich, dass ein großes Potential besteht, die 
Finanzbranche grundlegend umzuwälzen. Aber auch 
andere Branchen stehen, aufgrund der Technologie, 
vor einem Wandel. Dabei werden immer wieder die 
Bereiche Logistik und SCM genannt. Gerade in 
Deutschland spielt der Logistiksektor eine große 
Rolle, nach der Beschäftigtenzahl ist er die drittgrößte 
Branche und erzielt einen Umsatz von rund 279 Milli-
arden Euro [1]. 

Ein Beispiel fĂźr die Anwendung in diesem Bereich ist 
die Rechnungsstellung. Derzeitige Warenwirtschafts-
systeme erfassen heute in Sekundenbruchteilen Än-
derungen im Bestand bei einer Bestellung. Die Rech-
nungsstellung findet aber oft noch manuell statt und 
dauert dementsprechend länger. Es ist denkbar die-
sen Prozess mithilfe eines Smart Contracts zu auto-
matisieren und somit zu beschleunigen, womit bei-
spielsweise die Liquidität einer Unternehmung erhÜht 
werden kann. Daneben existieren eine Reihe weiterer 
angedachter Anwendungen von DLT in der Branche, 
die zum Teil auch auf Smart Contracts basieren. 
Diese sollen hier aufgezeigt und deren Potential ab-
geschätzt werden. Ein Schwerpunkt liegt dabei auf 
der Einschätzung der Technologie hinsichtlich ihrer 
Sicherheitseigenschaften. Denn das Thema IT-Si-
cherheit gewinnt immer mehr an Bedeutung, gerade 
im Hinblick auf die gleichbleibend hohe Gefährdungs-
lage im Bereich der Cyberspionage zu Ungunsten 
deutscher Unternehmen [2].  

2. Begriffseinordnungen 

Distributed-Ledger-Technologien stellen ein relativ 
neues Forschungsfeld dar, daher gibt es auch keine 
einheitliche Definition und verschiedene technische 
AusfĂźhrungen werden darunter subsumiert [3]. Ver-
allgemeinert handelt es sich um Systeme zur verteil-
ten KontofĂźhrung, bei denen die Daten von allen, o-
der zumindest mehreren Computern im beteiligten 
Netzwerk genutzt, weitergegeben und verifiziert wer-
den [4]. Hauptmerkmale von DLT sind: 

a) Im Vergleich, zu den bisher Ăźblichen Shared-
Ledgers sind Distributed-Ledger-Systeme nicht auf 
eine Ăźbergeordnete, zentrale Instanz angewiesen. 
Informationen in digitaler Form kĂśnnen zwischen 
Parteien, die sich untereinander nicht vertrauen, 
ausgetauscht und gespeichert werden. 

b) DLT stellen sicher, dass es zu keinem Double-
Spending kommen kann. Double Spending be-
zeichnet dabei das mehrfache Ausgeben eines di-
gitalen Guts beispielsweise eines Bitcoins. 

Allgemein ausgedrĂźckt werden DLT dazu genutzt den 
Besitz von digitalen GĂźtern nachzuverfolgen. Bei-
spiele fĂźr DLT sind das Bitcoin- und das Ethereum-
Netzwerk. 

Smart Contracts (SC) kĂśnnen, wenn sie mithilfe ei-
ner DLT implementiert wurden, als unveränderliche 
Computerprogramme bezeichnet werden, die „recht-
lich relevante Handlungen […] in Abhängigkeit von di-
gital prĂźfbaren Ereignissen steuer[n], kontrollier[en] 
und/oder dokumentier[en] […] [5]. 

Smart Contracts, die fĂźr ihre AusfĂźhrung auf Informa-
tionen außerhalb der Blockchain angewiesen sind, 
werden als non-deterministic Smart Contracts 
(NDSC) bezeichnet. Diese Art von Smart Contracts 
erweitert das Spektrum an mĂśglichen Anwendungs-
szenarien beträchtlich [6]. Ihr Einsatz birgt jedoch 
auch Gefahren, da hier der RĂźckgriff auf Daten einer 
dritten Partei nĂśtig ist, die nicht in jedem Fall fehlerfrei 
agiert und nicht immer vĂśllig vertrauensvoll ist. Dem 
gegenĂźber stehen sogenannte deterministic Smart 
Contracts (DSC). DSC sind solche Smart Contracts 
die nur aufgrund der Informationen, die in dem DL 



vorhanden sind funktionieren.  

Da eine direkte Anbindung an eine externe Daten-
quelle (z.B. ein aktueller BĂśrsenkurs) einen nicht de-
terministischen Zustand des Ledgers auslĂśsen 
kĂśnnte, werden Oracles als vermittelnde Instanz ver-
wendet. Grundsätzlich sind Oracles auch Smart 
Contracts. Sie dienen lediglich als vermittelnde In-
stanz zwischen externen Datenquellen und anderen 
Smart Contracts. Smart Contracts, die auf externe In-
formationen angewiesen sind, um zu funktionieren, 
fragen ein Oracle ab, anstatt dies direkt bei der origi-
nären Datenquelle zu tun. Dafßr sendet die externe 
Datenquelle dem Oracle Updates Ăźber den abzufra-
genden Zustand, dadurch werden Inkonsistenzen 
vermieden, da nun ein Smart Contract einen anderen 
abfragt [7]. Das bedeutet, dass das an sich geschlos-
sene System eines Distributed Ledgers durch 
Oracles um eine Anbindung an die Außenwelt erwei-
tert wird, was die Nutzung externer Datenquellen er-
laubt. 

3. Anwendungsfelder von Smart Contracts 

Die Anwendungsfelder von Smart Contracts werden 
durch die Vorteile definiert, die diese Technologie mit 
sich bringt. Zu den größten Vorteilen von Smart 
Contracts gehĂśren: 
 Sehr geringe Wahrscheinlichkeit, dass die in den 

Smart Contract festgelegten Vereinbarungen 
nicht durchgesetzt werden  Durch die dezent-
rale AusfĂźhrung und Validierung des Smart 
Contracts 

 Genauigkeit  z.B. Reduzierung der Fehler-
quote, dort wo sonst manuell Daten Ăźbertragen 
werden 

 Höhere Geschwindigkeit durch Automatisierung 
von bisher manuellen Prozessen  z.B. Ver-
gleich mehrerer Quellen ob ein Flugzeug Ver-
spätung hat und sofortige Freigabe der Versiche-
rungssumme, sollte der Versicherungsfall eintre-
ten. 

 Reduzierung der Zahl an Intermediären  Ver-
trauen unter den Vertragsparteien ist nicht nĂśtig, 
daher werden Dritte, die fĂźr die Einhaltung von 
vertraglichen Vereinbarungen garantieren, nicht 
benĂśtigt 

 Geringere Kosten  Durch die vorher genannten 
Punkte [8] 

 

Use Cases fĂźr Smart Contracts sind somit dort zu fin-
den, wo die Digitalisierung und Automatisierung von 
Prozessen bisher, aufgrund des Fehlens fälschungs-
sicherer digitaler Dokumente, nicht mĂśglich war. Ne-
ben der Prozessoptimierung werden durch Smart 
Contracts auch gänzlich neue Geschäftsmodelle 
mĂśglich. Decentralized Autonomous Organizations 
(DAO) sind ein Beispiel fßr ein neues Geschäftsmo-
dell auf Basis von Smart Contracts. DAOs sind Orga-
nisationen ohne Vorstände und Geschäftsfßhrer, die 
sich selbst verwalten und in denen Nutzer Stimm- und 
Eigentumsrechte erwerben kĂśnnen, um beispiels-
weise Ăźber zukĂźnftige Investitionen zu bestimmen [9]. 

4. Limitierungen von Smart Contracts 

Die zuvor genannten Vorteile der Smart Contracts 
lassen sich aufgrund von Limitierungen hinsichtlich 
der Sicherheit, Anwendbarkeit und weiterer Faktoren, 
noch nicht in umfänglicher Weise in reale Anwendun-
gen Ăźbertragen beziehungsweise verhindern deren 
Ausdehnung auf größere Benutzergruppen. 

Zu den gewichtigsten Faktoren, die den Einsatz von 
Smart Contracts hemmen, gehĂśren problematische 
Aspekte bei der Sicherheit von Smart Contracts. Eine 
vollumfängliche Darstellung gibt es auch hier noch 
nicht, unter anderem wegen der noch geringen Ver-
breitung von Smart Contracts [7]. Trotzdem ist bereits 
bekannt, welche gravierenden Folgen durch Sicher-
heitslĂźcken entstehen kĂśnnen. Bekanntestes Beispiel 
dafĂźr ist die bereits angesprochene DAO, eine Invest-
mentfirma ohne menschliches Personal. Durch einen 
Programmierfehler wurden digitale Token im Wert 
von 53 Millionen Dollar entwendet. Nur durch eine 
Protokolländerung (Hard Fork) der gesamten 
Ethereum-Blockchain konnte der Schaden rßckgän-
gig gemacht werden. Dadurch existiert aber seitdem 
neben Ethereum noch die Kryptowährung Ethereum 
Classic [10].  

Eine der ersten Publikationen zur Sicherheit von 
Smart Contracts auf Basis von Ethereum stammt von 
DELMOLINO ET AL. (2016) und bezieht sich auf die 
Besonderheiten in der Programmierung von Smart 
Contracts und häufig begangenen Fehlern, die auf 
die Eigenheiten von DL zurĂźckzufĂźhren sind. 

Im Wesentlichen stellen sie drei Fehlerarten fest: 
 

1. Smart Contracts, die gesendeten Beträge ein-
schließen und nicht wieder freigeben 

2. Speichern von Nutzerinformationen in Klartext, 
wodurch eine andere Partei einen Vorteil erzielen 
kann 

3. Falsch gesetzte Anreize kĂśnnen dazu fĂźhren, 
dass sich Nutzer nicht wie beabsichtig verhalten, 
da ein Fehlverhalten nicht oder nicht stark genug 
bestraft wird [11]. 
 

LUU ET AL. (2016) zeigen mit ihrem Tool Oyente, 
dass 45 % aller Smart Contracts in Ethereum nach 
ihrer Definition Bugs besitzen, die von Angreifern 
ausgenutzt werden kĂśnnten [12]. Die meisten Fehler 
treten dabei bei der Behandlung von Ausnahmen auf. 
Das kann unter anderem dazu fĂźhren, dass Gelder 
unwiderruflich in einem Smart Contract verbleiben, 
ohne dass der rechtmäßige Besitzer darauf Zugriff er-
hält [12]. 

 

NIKOLIC ET AL. (2018) definieren in ihrer Untersu-
chung drei Arten angreifbarer Contracts: 

Verschwenderische Smart Contracts  Sind solche 
Verträge, die Gelder willkßrlich an andere Adressen 
schicken kĂśnnen. 

1. Suizidale Smart Contracts  KÜnnen von ande-
ren Nutzern als dem Ersteller oder an-deren be-
rechtigten Personen zerstĂśrt werden. 

2. Gierige Smart Contracts  Behalten eingezahlte 
Gelder ein, ohne dass eine MĂśglichkeit besteht 



sie wieder freizugeben [13]. 

Von knapp einer Million untersuchter Smart Contracts 
kĂśnnen rund 2,5 % in einer der von den Autoren defi-
nierten Kategorien eingeordnet werden. Die Diskre-
panz zwischen den Zahlenangaben zu Smart 
Contracts mit sicherheitsrelevanten Schwachstellen 
(45% zu 2,5 %) zeigt, dass einheitliche Bewertungs-
maßstäbe gefunden werden müssen. Beide Untersu-
chungen zeigen jedoch unabhängig davon, dass ein 
nicht vernachlässigbarer Anteil von Smart Contracts 
ßber potentiell gefährliche Fehler verfßgt, die die Gel-
der von Nutzern gefährden. Eine LÜsung hierfßr ist 
die Überprüfung von Smart Contracts mit den von 
den Autoren entwickelten Tools, bevor sie eingesetzt 
werden, um solche SicherheitslĂźcken zu vermeiden. 
NatĂźrlich gibt es auch in jeder anderen Software 
Bugs, Anwendungen auf Basis von DLT sind jedoch 
durch drei Eigenschaften besonders gefährdet: 

 
1. Finalität von Transaktionen 

Eigentlich ein Vorteil von Distributed Ledgers, je-
doch kĂśnnen beispielweise bei einer erfolgrei-
chen Attacke die Beträge nicht zurßckgebucht 
werden oder ähnliches. Nur durch die Änderung 
des gesamten Protokolls, der alle Knoten zustim-
men mßssen kann eine Entschädigung stattfin-
den. Im Falle von The DAO wurde dies nur durch-
geführt, da ein großer Anteil von Ether in The 
DAO investiert wurde, dadurch war die Anwen-
dung „too big to fail“ [10]. Für Smart Contracts mit 
kleineren Summen ist diese Art der Rettung so 
gut wie ausgeschlossen. Aber auch Hacks und 
Bugs, deren Größenordnung, gemessen an den 
involvierten Summen an Kryptowährungen, die 
des DAO-Hacks Ăźbersteigen, kĂśnnen nicht 
grundsätzlich auf eine Rettung hoffen. Beispiel 
hierfĂźr ist der als Parity Bug bzw. Hack bezeich-
nete Fall, indem die Gelder einer Wallet Software 
nicht mehr zugänglich waren, da ein unberechtig-
ter Nutzer eine notwendige Bibliothek gelĂśscht 
hatte (Suizidaler Smart Contract).  

2. Starker monetärer Anreiz Smart Contracts an-
zugreifen 
Da fast die Hälfte aller Smart Contracts Finanz-
geschäfte abwickeln und somit Kryptowährungen 
verwalten, ist der potentielle finanzielle Gewinn 
eines Angriffes hoch. 

3. Noch keine Rechtssicherheit 
Fehlende Regulierung im Bereich der DL erhĂśht 
das Risiko fĂźr Nutzer im Falle eines Angriffs keine 
Entschädigung außerhalb der DL-Infrastruktur zu 
erhalten etwa Ăźber ein Gerichtsverfahren. 

5. Problematik Oracles  

Die Probleme, welche sich mit der Nutzung von 
Oracles auftun, sind offensichtlich, da sie die Zielset-
zungen von DL konterkarieren zu scheinen. Distribu-
ted Ledger werden genutzt, um revisionssichere 
Transaktionen durchzufĂźhren, ohne dass sich die 
Teilnehmer untereinander vertrauen. Wird jedoch fĂźr 
ein Smart Contract ein Oracle genutzt, das die Daten 

aus einer externen Quelle bezieht wird Vertrauen wie-
der nÜtig [14]. Zum einem Vertrauen in die Validität 
der Daten aus der externen Quelle, zum anderen Ver-
trauen darin, dass die Daten vom eingesetzten 
Oracle nicht verändert wurden.  

Allgemein, sind die als CIA-Triade bezeichneten Be-
griffe, confidentiality (Vertraulichkeit), integrity (Integ-
rität) und availability (Verfßgbarkeit), ein fundamenta-
les Modell fĂźr Betrachtungen in der Computersicher-
heit, auch fĂźr Smart Contract Oracles gĂźltig. Vertrau-
lichkeit steht fĂźr den Schutz, dass Daten nicht unau-
torisiert verÜffentlicht werden. Integrität ist der Schutz 
vor der unerlaubten Änderung von Daten und Verfüg-
barkeit bezeichnet den Schutz vor unautorisierter 
Dienstverweigerung (beispielsweise durch Distribu-
ted-Denial-of-Service-Attacken) [15]. Oracles kĂśnnen 
diese Eigenschaften ohne zusätzliche Maßnahmen 
nur schlecht erfĂźllen. Dieses konzeptionelle Problem, 
sich widersprechender Eigenschaften von Smart 
Contracts und Oracles, ist ein in der Forschung und 
Industrie bekanntes. 

Ein Ansatzpunkt den Widerspruch aufzulĂśsen ist die 
Nutzung von externen Quellen denen ohnehin ver-
traut wird, beziehungsweise denen vertraut werden 
muss. Anwendungen die beispielsweise die Validie-
rung von staatlichen Stellen benĂśtigen, kĂśnnen und 
mĂźssen von eben diesen mit Daten in Form von 
Oracles gespeist werden, womit keiner zusätzlichen 
Entität vertraut werden muss [16]. Dies ist jedoch nur 
fĂźr eine begrenzte Anzahl von Anwendungen der Fall 
und mit Hinblick auf die Zielsetzung von DL, dass si-
chere Transaktionen zwischen Parteien abgewickelt 
werden sollen, die sich nicht vertrauen, auch keine 
primäre Anwendung. 

ZHANG ET AL. (2016) setzen fĂźr das Problem der si-
cheren und nicht manipulierten Übertragung von Da-
ten, von externen Quellen zu einem Oracle auf ein 
von ihnen entwickeltes Protokoll mit dem Namen 
Town Crier [17]. Town Crier setzt hierbei stark auf die 
Nutzung von Software Guard Extensions von Intel, 
wie auch der Konsensmechanismus Proof of Elapsed 
Time, um Code in einer sicheren Umgebung auszu-
fßhren. Dadurch soll die Authentizität und Integrität 
der Daten eines Oracles sichergestellt werden. Dane-
ben soll durch die VerschlĂźsselung von so genannten 
„datagrams“ Vertraulichkeit in den Abfragen an ein 
Oracle gewährleistet werden. Dies ist insofern wich-
tig, weil in einem Ăśffentlichen DL alle Transaktionen 
fĂźr jeden Teilnehmer einsehbar sind. FĂźr viele An-
wendungen ist jedoch ein gewisser Grad an Vertrau-
lichkeit notwendig. 

Ein weiterer Ansatz, der zum Beispiel von der Firma 
ChainLink angewandt wird, ist die Verteilung von Da-
tenquellen und Oracles. Einfach ausgedrĂźckt, wer-
den fĂźr ein Oracle verschiedene Datenquellen ge-
nutzt und deren Ergebnisse zu einer Abfrage aggre-
giert, weitere Oracles mit teilweise anderen Daten-
quellen fĂźhren auch eine Abfrage durch und aggre-
gieren die Ergebnisse. Die Ergebnisse aller Oracles 
werden am Ende ebenfalls aggregiert und bilden so-
mit den Input fĂźr den Smart Contract, der einen be-
stimmten Parameter abfragt [18]. 



Mithilfe aller dieser Ansätze lassen sich Risiken in der 
Nutzung von Oracles fĂźr Smart Contracts minimieren. 
Jedoch kann, durch die ständige Weiterentwicklung 
des Feldes, noch kein abschließendes Urteil zur Si-
cherheit von Oracles getroffen werden. 

6. Anwendung von DLT in Logistik und SCM  

Nachdem in den vorherigen Abschnitten aufgezeigt 
wurde, wo die Potentiale von DLT liegen, aber auch 
ihre Limitierungen, soll geprĂźft werden, wo diese 
Technologien in Logistik und SCM angewandt wer-
den. Dazu wurden 37 verschiedenen Case Studies 
bzw. Projekte ausgewertet, die alle Üffentlich zugäng-
lich sind. Die Anwendungsbereiche wurden in sechs 
Kategorien zusammengefasst. Diese sind in Tabelle 
1 zusammengefasst.    

 

Abbildung 1 - Anwendungsfelder von DLT in Logistik und 
SCM 

Die Case Studies und Projekte wurden zu denen in 
Tabelle 1 definierten Anwendungsfeldern zugeord-
net. Eine Mehrfacheinordnung wurde teilweise vorge-
nommen. Die Ergebnisse sind in Abbildung 1 zu se-
hen. Das Anwendungsfeld Supply Chain Visibility, 
worunter auch das Tracking und Tracing fällt ist do-
minant in der Anwendung der DLT im SCM. Supply 
Chain Finance folgt mit deutlichem Abstand, was 
Ăźberraschend ist, da die ganze Technologie als ein 
neuartiges Finanzinstrument gestartet ist und in vie-
len Berichten primär auch noch als dieses gesehen 
wird. Die Integration von IoT-Geräten und Sensoren 
sowie Risikomanagement sind weiterhin wichtige An-
wendungsfelder. Marktplätze fßr logistische Dienst-
leistungen und die Integration in die Additive Ferti-
gung stellen derzeit Nischenanwendungen dar.  

Kategorie  
Supply Chain 

Visibility 
Supply Chain 

Finance 

Merkmale  

Tracking und 
Tracing  

Digitalisierung 
von Frachtdoku-
menten  

Herkunftsnach-
weise fĂźr Kun-
den und Endver-
braucher und 
BehĂśrden 

Automatische Ab-
wicklung von Zah-
lungen Ăźber To-
ken, Kryptowäh-
rungen und Smart 
Contracts  

Audits  
Know Your Custo-
mer Bestandsma-

nagement 

Kategorie  IoT Integration 
Additive 

Fertigung (AF) 

Merkmale  

Integration von 
IoT Geräten und 
Sensoren zur 
Datenerfassung 
& Automatisie-
rung  

Sichern der Da-
tenĂźbertragung in 
der AF + Her-
kunfts-nachweise 
in DLT  

Kategorie  
Risikomanage-

ment 
Marktplatz 

Merkmale  

Reaktionsver-
mĂśgen durch 
besseren Zugriff 
auf Daten 

Sicherer Markt-
platz zum Handel 
von GĂźtern und 
Dienstleistungen  

Sichere Quali-
tätsnachweise 
der Lieferanten  Automatische 

Verhandlungen 
M2M  
 

Einfachere 
StreitlĂśsung  
Schutz vor Pro-
duktfälschungen 

Tabelle 1 - Kategorisierung der Anwendungsfelder von 
DLT in SCM und Logistik 

Daneben wurde den untersuchten Fällen ein Anwen-
dungsbereich zugeordnet. Die Ergebnisse sind dazu 
in Abbildung 2 zusammengefasst.  

 

Abbildung 2 - Anwendungsbereiche von DLT in Logistik 
und SCM 

Eine Branche in der der Einsatz von DLT stark disku-
tiert wird, ist die Nahrungsmittelbranche. Hier geht es 
primär darum das Vertrauen der Verbraucher, das 
durch die zahlreichen Lebensmittelskandale stark ge-
litten hat, wieder zu gewinnen. Sichere Herkunfts-
nachweise sollen den Verbrauchern eine Garantie 
Ăźber die Quelle ihrer Produkte geben und zwar Ăźber 
die ganze Supply Chain hinweg. Eine ähnliche The-
matik spielt fĂźr die Anwendung in der Pharmalogistik 
eine Rolle. Auch hier gab es in den vergangenen Jah-
ren Skandale gerade in Asien. Weitere Anwendungs-
bereiche sind der GĂźterverkehr und die Herstellung 
und Handel mit hochwertigen GĂźtern, worunter bei-
spielsweise die Firma Everledger fällt, die Diamanten 
registriert. 

0 10 20 30

Additive Fertigung

Markplatz

IoT Integration

Risikomanagement

Supply Chain Finance

Supply Chain Visibility

3

4

11

12

14

29

Anwendungsfelder von DLT in Logistik 
und SCM

0 5 10 15

Additive Fertigung
Hochwertige GĂźter

Pharmalogistik
Sonstige

GĂźterverkehr
Nahrungsmittel

Übergreifende Plattform

2
3

4
4

5
9

12

Anwendungsbereiche



In den Case Studies häufig genannte Vorteile von 
DLT in Logistik und SCM waren: hĂśhere Transpa-
renz, Sichere Herkunftsnachweise, ErhĂśhung von 
Datensicherheit und -integrität, Prozessautomatisie-
rungen, Kostensenkungen.  

Um die in den Case Studies identifizierten Vorteile 
weiter zu untersetzen, wird ein Literature Review 
durchgefĂźhrt.  

7. Literature Review  

Als Grundlage der eigenen Methodik dienen die Aus-
fĂźhrungen von DURACH ET AL. (2017), die Literature 
Reviews im Bereich der Forschung zum Supply 
Chain Management systematisierten [19]. Im ersten 
Schritt der Methode geht es um die mĂśglichst kon-
krete Formulierung der Forschungsfragen. Die vor-
dergrĂźndig zu beantwortenden Forschungsfragen 
sind hierbei: 
 

1. Welche Vorteile werden durch den Einsatz von 
DLT erzielt und wie sind sie quantifizierbar? 

2. Welche Implikationen ergeben sich daraus auf 
die Datensicherheit im Speziellen und die Sicher-
heit der Unternehmung im Allgemeinen, bei-
spielsweise bezogen auf die Einhaltung rechtli-
cher Vorgaben? 

 

Darauffolgend werden potentiell relevante Quellen 
durch eine Suche in einschlägigen Datenbanken er-
mittelt. Neben der bloßen Suche in den Datenbanken 
werden auch die Querverweise der ausgewählten 
Publikationen untersucht. Die Suchmethode orientiert 
sich dabei an den von DENYER UND TRANFIELD 
(2009) gemachten Angaben [20]. Gefundene Quellen 
werden anhand der in Schritt zwei bereits definierten 
Kriterien, entweder in die Untersuchung aufgenom-
men oder davon ausgeschlossen. 

8. Vorteile durch DLT in Logistik und SCM 

Im Bezug zu den Vorteilen, die durch DLT erreicht 
werden kĂśnnen, decken sich die Ergebnisse der Aus-
wertung der wissenschaftlichen Quellen zum Groß-
teil, mit denen aus der Auswertung der Case Studies. 
Die Ergebnisse sind dazu in Tabelle 3 festgehalten. 
Eine Quantifizierung der Vorteile, die durch DLT er-
bracht werden, findet sich jedoch in keiner Quelle.  

Von vielen Autoren werden die Automatisierung von 
Prozessen und die Schaffung von Transparenz als 
die größten Vorteile der Implementierung von DLT 
gesehen. Die Automatisierung bezieht sich dabei vor 
allem auf Finanztransaktionen, Streitresolution und 
Dokumentation von Prozessen. Diese Prozesse be-
nĂśtigen heute noch viele manuelle Interventionen, da 
sie nicht digitalisiert ablaufen und papierbasierte Do-
kumente benĂśtigen. Bei vielen Prozessen ist dies der 
Fall, weil digitale Dokumente noch nicht genĂźgend Si-
cherheit gegenßber Manipulation und Vervielfältigung 
aufweisen. Digitale Originale werden jedoch durch 
DLT mĂśglich und erĂśffnen so neue NutzungsmĂśglich-
keiten und Wege zur Automatisierung von Prozes-
sen, welche in der Regel durch Kosteneinsparung 
und einer hĂśheren GĂźte der Prozesse verbunden 

sind. 

Ein Beispiel, dass die Fähigkeit von DLT, Prozesse 
zu automatisieren, gut beschreibt ist die Digitalisie-
rung der Bill of Lading (BoL), die auch als Konnosse-
ment bezeichnet wird. STAHLBOCK ET AL. (2018) 
haben sich damit auseinandergesetzt [21]. 

Die BoL ist ein wichtiges Dokument im maritimen Wa-
renverkehr. Ihre hauptsächlichen Funktionen sind: 
„Beleg des Erhalts oder Verschiffens von Gütern, Be-
weis eines abgeschlossenen Frachtvertrags und die 
Repräsentation des Besitzrechtes der Güter.“ [21]. 
Durch den letzten Punkt wird die Digitalisierung des 
Dokumentes erschwert, denn es stellt auch ein Wert-
papier dar. Also muss sichergestellt werden, dass 
eine digitale Repräsentation dieses Dokuments nicht 
vervielfältigt werden kann, dass also nur ein digitales 
Original besteht. 

Warum ist eine Digitalisierung sinnvoll? Durch die In-
volvierung vieler verschiedener Parteien, beim Trans-
port von Seefracht, kann es dazu kommen, dass die 
BoL nicht immer dort ist, wo sie gerade benĂśtigt wird, 
beispielsweise um Waren freizugeben, die am Zielort 
angekommen sind. So kann die BoL, die nicht verviel-
fältigt werden darf, noch bei der Hafenverwaltung 
sein, obwohl sie vom Zoll benĂśtigt wird. Dadurch kann 
es zu VerzĂśgerung beim LĂśschen der Ware kommen, 
was in der Regel zu finanziellen Einbußen führt (z.B. 
kĂśnnten empfindliche Nahrungsmittel verderben). 
Daneben ist eine BoL als Papierdokument fehleran-
fällig, sie kÜnnte beispielsweise verloren gehen.  

Eine digitale BoL muss einige Anforderungen erfĂźl-
len. Die digitale BoL muss einzigartig und Ăźbertragbar 
sein. Die Integrität der Dokumente muss sicherge-
stellt sein und, es muss ein Mechanismus bestehen, 
mit dem der Besitz des Dokumentes nachgewiesen 
werden kann, nach Ende des Geschäfts muss das 
Dokument seine rechtliche Wirkung verlieren [21]. 
Diese Eigenschaften lassen sich mit DLT erreichen. 
Ein Nachweis ßber den Besitz des Dokumentes lässt 
sich beispielsweise von jedem Teilnehmer, beim Blick 
auf die Transaktionen im Ledger, nachvollziehen. 
Durch eine mit DLT digitalisierte BoL werden manu-
elle Schritte wie das Übergeben der BoL nach dem 
Festmachen des Schiffes an die jeweiligen Autoritä-
ten unnĂśtig. Sie kĂśnnte gleich bei der Einfahrt in den 
Hafen automatisch Ăźbermittelt werden. Somit kĂśnn-
ten Wartezeiten vermieden und die Ware schneller 
gelĂśscht werden. 

Weitere Anwendungen im Bereich der Automatisie-
rung gehen stark auf die Abwicklung von FinanzflĂźs-
sen ein. Ein Ziel im SCM ist die Integration von Wa-
ren-, Informations- und ZahlungsflĂźssen. Die Abwick-
lung von ZahlungsflĂźssen ist jedoch noch stark von 
den eigentlichen WarenflĂźssen entkoppelt. Wie be-
reits beschrieben ist dies vor allem auf die weitver-
breitete Nutzung papierbasierter Dokumente zurĂźck-
zufĂźhren. Analog zum Beispiel der BoL sind in die-
sem Bereich auch Vorteile durch die Digitalisierung 
solcher Dokumente zu erzielen. Daneben entstehen 
durch die automatisierte Abwicklung von Zahlungs-
strĂśmen, auch in M2M-Beziehungen, neue Ge-



schäftsmodelle, wie dezentralisierte autonome Orga-
nisationen oder P2P-Netzwerke zum Handeln von 
GĂźtern z.B. elektrische Energie aus privaten regene-
rativen Quellen. 

Vorteile durch DLT Anzahl Quellen 

Automatisierung 12 

[21]; [26]; 
[27];[28]; 
[29];[30]; 
[31]; [32]; 
[33];[34]; 
[35];[36] 

Transparenz (unterneh-
mensintern)  

8 

[26]; [32]; 
[34]; [35]; 
[37]; [38]; 
[39]; [40] 

Transparenz (extern fĂźr 
Endverbraucher)  

5 
[25]; [37]; 
[41]; [42]; 
[43] 

Neue Geschäftsmodelle 4 
[28]; [29]; 
[44];[45];  

Kontrollebene in IoT-Sys-
temen  

3 
[27]; [39]; 
[43] 

Produktfälschungen ver-
hindern  

3 
[39]; [42], 
[46] 

Interoperabilität von Sys-
temen  

2 [38]; [47] 

Besserer Zugang zu Fi-
nanzierungsinstrumenten  
fĂźr KMU  

1 [31] 

Tabelle 2 - Auswertung Literature Review Vorteile durch 
DLT 

Ein letzter Punkt der Automatisierung beschreibt die 
Streitresolution. Mithilfe von Smart Contracts kĂśnnen 
Logiken festgelegt werden, nach denen Algorithmen 
zwingend handeln, ohne dass eine Partei darin ein-
greifen kĂśnnte. Ein Beispiel hierzu sind Smart 
Contracts, die die KĂźhlung eines Medikamentes Ăźber-
wachen, sollten die Temperaturen Ăźber einen vorher 
definierten Zeitraum, nicht eingehalten werden, muss 
der Logistikdienstleister dem Hersteller eine Entschä-
digung zahlen, da das Produkt mĂśglicherweise nicht 
mehr verkäuflich ist. Mit Smart Contracts wird sicher-
gestellt, dass die Entschädigung auch gezahlt wird, 
da diese eine Zahlung automatisch veranlassen kĂśn-
nen, sobald der gewĂźnschte Transportzustand nicht 
mehr erfĂźllt wird. Verhandlungen mit dem Transport-
dienstleister ßber solche Entschädigungen sind dann 
nicht mehr nĂśtig. 

Die Erzielung von Transparenz in Supply Chains ist, 
laut der Auswertung der Literature Reviews, neben 
der Automatisierung der bestimmende Vorteil von 
DLT im SCM. Es kann grob zwischen dem Ziel nach 
der Schaffung von unternehmensinterner und von ex-
terner Transparenz unterschieden werden. Externe 
Transparenz bezieht sich dabei auf die Schaffung von 
Transparenz fĂźr den Endkonsumenten eines Produk-
tes. Das heißt dem Kunden wird die Möglichkeit ge-
boten die Herkunft seines Produktes und die Produk-
tionsbedingungen nachzuvollziehen. Dies ist eine 
MĂśglichkeit, Vertrauen zwischen Unternehmen und 
Kunden aufzubauen und so die Kundenbindung zu 

stärken. Einher geht dieser Ansatz auch oft mit dem 
Ziel, Produktfälschungen zu verhindern, beziehungs-
weise zu erschweren, dadurch, dass sich nur genuine 
Produkte Ăźber eine Abfrage in einem DL verifizieren 
lassen. 

 

Interne Transparenz bezieht sich ausschließlich auf 
das Unternehmensnetzwerk. Der Grund hierfĂźr liegt 
in der Absicherung der Unternehmen hinsichtlich der 
Herkunft der von Lieferanten bezogenen Teile oder 
Rohstoffe. So ist ein wichtiger Ansatzpunkt im Risiko-
management, der ausschließliche Bezug von Teilen 
und Rohstoffen aus bekannten Quellen. Dass ein be-
stimmtes Teil tatsächlich von einem bestimmten Lie-
feranten stammt, lässt sich mithilfe von DLT anhand 
der getätigten Transaktionen leicht ßberprßfen. 

Grundlegend bei fast allen der diskutierten Anwen-
dungen ist eine Datenbasis aus vielen Sensoren und 
Geräten. Somit sind diese Anwendungen von einer 
primären IoT-Infrastruktur abhängig. Um diese siche-
rer zu machen werden DLT in einigen Publikationen 
als eine Art Kontrollinstanz gesehen, die Informatio-
nen bzw. Transaktionen validiert und diese Netz-
werke so zusätzlich schßtzt. Somit sind IoT und DLT 
fundamentale Bausteine fĂźr eine Verbesserung der 
Visibility, des Risikomanagements und der Abwick-
lung von ZahlungsflĂźssen in Supply Chains. 

9.  Sicherheitsimplikationen  

Der Einsatz von DLT wird oft unter dem Aspekt einer 
Verbesserung der Sicherheit diskutiert. Daher wur-
den die Quellen, die sich mit der Anwendung der 
Technologie beschäftigen, auch dahingehend unter-
sucht, wie DLT eine erhĂśhte Sicherheit von Anwen-
dungen erzielen und welche Punkte sich mĂśglicher-
weise negativ darauf auswirken. 

Das am häufigsten angebrachte Argument dafßr, 
dass DLT mehr Sicherheit schafft, ist dass dadurch 
die Manipulierbarkeit von Daten stark reduziert wird 
oder sogar, mit vertretbaren Mitteln, ganz ausge-
schlossen ist. Gerade in Bezug auf IoT-Geräte, die 
allzu oft leicht angreifbar sind und bei Finanztransak-
tionen, ist eine Verbesserung der Manipulationssi-
cherheit gewĂźnscht. 

Die Forderung nach Manipulationssicherheit ist im 
Grunde genommen, dieselbe wie die Forderung nach 
Datenintegrität, einer der drei Säulen der Informati-
onssicherheit, nach dem Modell der CIA-Triade [15]. 
In vielen wissenschaftlichen Quellen wird davon aus-
gegangen, dass DLT grundsätzlich sicher sind. Be-
grĂźndet wird dies mit den genutzten kryptographi-
schen Verfahren und den verteilten Konsens. Anhand 
von Smart Contracts wurde bereits gezeigt, dass An-
wendungen auf Grundlage von DLT nicht zwangsläu-
fig sicher sind. Daher ist es wichtig an dieser Stelle zu 
prüfen, ob die oft getätigte Aussage „Blockchains sind 
sicher“ wirklich zutrifft und somit auch ihre Eignung 
Daten manipulationssicher zu verarbeiten. 



Sicherheitsimplikatio-
nen durch DLT 

Anzahl Quellen 

Manipulierbarkeit von Da-
ten verringern 

12 

[21]; [26]; 
[27]; [31]; 
[32]; [33]; 
[35]; [36];   
[40]; [43], 
[44]; [47]; 
[51];  

Produktsicherheit fĂźr Ver-
braucher 

6 
[25]; [37]; 
[41]; [42]; 
[46]; [48] 

Sicherheit in IoT Anwen-
dungen (z.B. verhindern 
von DDOS-Attacken, 
Schutz von Updates) 

4 
[45]; [49]; 
[50]; [51] 

Kein Single-Point of Fai-
lure 

4 
[30]; [32]; 
[44] [49];  

Klärung von Haftungsfra-
gen 

2 [38]; [40] 

Manuelle Eingaben ge-
fährden das System 

1 [25] 

Tabelle 3 - Auswertung Literature Reviews Sicher-
heitsimplikationen durch DLT 

Aufgrund des sich schnell entwickelnden Feldes an 
DLT gibt es bislang keine allgemeine Übersicht über 
die Sicherheit aller Systeme. Das liegt auch daran, 
dass zwar viele DLT ähnliche Konzepte nutzen, die 
sich jedoch in ihrer Implementierung stark unterschei-
den kÜnnen. Grundsätzlich gilt, dass zwar in vielen 
Publikationen behauptet wird, dass DLT sicher sind, 
jedoch kann es fĂźr kein S";"""date"",""2020-09-11T11:58:46Z""
""pdf:PDFVersion"",""1.4""
""xmp:CreatorTool"",""PScript5.dll Version 5.2.2""
""pdf:docinfo:title"",""Microsoft Word - Druckversion_Stange_Paper.docx""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""language"",""de""
""dc:format"",""application/pdf; version=1.4""
""pdf:docinfo:creator_tool"",""PScript5.dll Version 5.2.2""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""Microsoft Word - Druckversion_Stange_Paper.docx""
""xmp:CreateDate"",""2020-09-11T13:57:25Z""
""modified"",""2020-09-11T11:58:46Z""
""pdf:hasMarkedContent"",""false""
""xmp:ModifyDate"",""2020-09-11T13:58:46Z""
""pdf:docinfo:creator"",""ilange""
""meta:author"",""ilange""
""meta:creation-date"",""2020-09-11T11:57:25Z""
""created"",""2020-09-11T11:57:25Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-09-11T11:57:25Z""
""resourceName"",""Druckversion_Stange_Paper.pdf""
""Author"",""ilange""
""producer"",""Acrobat Distiller 20.0 (Windows)""
""pdf:docinfo:producer"",""Acrobat Distiller 20.0 (Windows)""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""access_permission:modify_annotations"",""true""
""dc:creator"",""ilange""
""dcterms:created"",""2020-09-11T11:57:25Z""
""Last-Modified"",""2020-09-11T11:58:46Z""
""dcterms:modified"",""2020-09-11T11:58:46Z""
""title"",""Microsoft Word - Druckversion_Stange_Paper.docx""
""xmpMM:DocumentID"",""uuid:924723b0-b71a-46b1-8107-8f7a9c73858b""
""Last-Save-Date"",""2020-09-11T11:58:46Z""
""pdf:docinfo:modified"",""2020-09-11T11:58:46Z""
""meta:save-date"",""2020-09-11T11:58:46Z""
""Content-Length"",""253402""
""Content-Type"",""application/pdf""
""xmp:MetadataDate"",""2020-09-11T13:58:46Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""ilange""
""pdf:producer"",""Acrobat Distiller 20.0 (Windows)""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""10""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""5061"",""5272"",""5729"",""3710"",""5663"",""4960"",""5395"",""5726"",""5325"",""4184""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-09-11T11:57:25Z""
";https://scholar.google.ch/scholar?start=920&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098861-321;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;[PDF][PDF] Central bank issued digital currencies: is it a solution or a problem??;Z Bujtár ; EU Business Law and Digital Revolution  real.mtak.hu;;"… 725, 3. 15 Judit Glavanits: Smart Cities, Iot and Blockchain: The importance of Oracles … Libra's

value can fluctuate according to the fiat currency basket against which it is defined, but Paxos

guarantees to change Paxos tokens19 to USD on its crypto exchange itBit and also …";Autres articles;;[PDF] mtak.hu;http://real.mtak.hu/117964/1/EU%20Business%20Law%20and%20Digital%20Revolution.pdf#page=71;"
EU Business Law and Digital Revolution 
 





 

EU Business Law and 

Digital Revolution 
 
 

– Selected Studies from  

New Fields of Technology 
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

SzĂŠchenyi IstvĂĄn University 

DeĂĄk Ferenc Faculty of Law and Political Sciences 

Department of International and European Law 

2019 



 
  

© Zsolt Bujtár, Sonja Bunčić, Neera Chopra, Olena Demchenko,  

Judit Glavanits, Zsolt Halász, Balázs Horváthy, Andrea Ivanišević,  

GĂĄbor KertĂŠsz, PĂŠter BĂĄlint KirĂĄly, LĂĄszlĂł Knapp, Andrea Labancz,  

Alpar Loťonc, Måria T. Patakyovå, Istvån Pesti-Farkas, Laura Stănilă, 

ZoltĂĄn Szegedi; 2019 

 

Editors: 

Judit Glavanits 

BalĂĄzs HorvĂĄthy 

LĂĄszlĂł Knapp 

 

The manuscript has been reviewed by LĂĄszlĂł Milassin. 

 

ISBN 978-615-5837-64-7 (Print) 

ISBN 978-615-5837-65-4 (PDF) 

 

This book has been published within the research stream of  

“Jean Monnet Module on EU Business Law” (EUBLAW) funded by  

the Erasmus+ Programme of European Union. 

Győr, 2019 

 
 

Published by Széchenyi István University – 

Deák Ferenc Faculty of Law and Political Sciences – 

Department of International and European Law  

(H-9026 Győr, Áldozat u. 12.) 

Tel.:+36/96/503-478 

Fax: +36/96/503-472 

Web: nejt.sze.hu 



 

Content 

 

 

 

Content ................................................................................................. 5 

 

Foreword  .............................................................................................. 7 

 

I. Artificial Intelligence: legal implications  

 

      Knight Rider’s Brothers Coming Soon – What About Their Legal 

            Situation? .................................................................................... 11 

      (GĂĄbor KertĂŠsz) 

 

      Artificial Intelligence and Bid Rigging .......................................... 29 

      (MĂĄria T. PatakyovĂĄ) 

 

      Fear the Robots? – Attitudes from the Supply Chain .................. 43 

      (István Pesti-Farkas – Zoltán Szegedi) 

 

      AI Risk Assessment Tools: The Trojan Horse of the Criminal 

           Justice System .............................................................................. 51 

      (Laura Stănilă) 

 

II. Cryptocurrencies 

 

     Central Bank Issued Digital Currencies: is it a Solution or a 

           Problem? ...................................................................................... 71 

      (Zsolt BujtĂĄr) 

 

     Fluidity of Term of Cryptocurrency – A Challenge for Regulators  89 

      (Sonja Bunčić – Alpar Lošonc – Andrea Ivanišević) 

 

     Virtual Currencies – Legal Challenges........................................ 113 

      (Zsolt HalĂĄsz) 

 

 



6 
 

    The Classification of Virtual Currencies Related to Blockchains 133 

    (PĂŠter BĂĄlint KirĂĄly) 

 

     Cryptocurrencies: A Theoretical Approach ................................. 149 

    (Andrea Labancz) 

 

III. Business and digitalization 

 

     Adoption of ICT in Higher education: Readiness of University 

          Students in Rural India................................................................ 171 

    (Neera Chopra) 

 

     Electronic Commerce in Gaming Industry. European Perspective 

          on the Legal Regulations of In-game Virtual Transactions ......... 193 

    (Olena Demchenko) 

 

     Smart Cities, Iot and Blockchain: The Importance of Oracles  ... 209 

    (Judit Glavanits) 

 

     Autonomous Vehicles – Challenges for EU Private 

     International Law  ....................................................................... 233 

     (BalĂĄzs HorvĂĄthy) 

 

Annex – The Centre for European Studies (CES)  at the 

     SzĂŠchenyi IstvĂĄn University .............................................................. 255 

 

 

 



 

Foreword 
 

 

 

 

 

 

 

 

 

In 2017 the Centre for European Studies (CES) of Faculty of Law and 

Political Sciences of the SzĂŠchenyi IstvĂĄn University launched the 

conference series ‘EU Business Law Forum’ with the aim to establish a 

regular event, which reflects on topical issues of EU business law and 

explores the related contemporary challenges in their legal, political, 

economic and social reality.  

The 2nd EU Business Law Forum “EU Business Law through the lens 

of Digital Revolution” held between 13–14 June 2019, was devoted to 

discuss the implications of the current technological revolution on the 

business environment in the European Union, particularly on the EU 

business law regulation. The Forum identified the recent challenges that 

the EU business actors are facing as a result of the digitalization and 

posed the question, whether – analogically to the concept of ‘Industry 

4.0’ – a process of a ‘Law 4.0’ is expected to become tangible in the EU 

business law regulation, responding adequately the challenges arising 

from the new disruptive technologies.  

This book offers an insight into the main focus areas of the 

conference. The first chapter (I. Artificial Intelligence: legal implications) 

reflects on the growing importance of using artificial intelligence and the 

role of the legal regulation. The articles pose questions form general as 

well as specific perspectives and illustrates the legal problems of the 

artificial intelligence by varieties of topics, from the public procurements 

to the supply chains. The second chapter collects the papers that are 

focusing on the new instruments of exchange (II. Cryptocurrencies). The 

chapter lays down the conceptual basis of cryptocurrencies and 

examines the legal and regulatory challenges arising from the current 

use and the probable future prevalence of the virtual currencies. The 

third chapter of the book pays attention to emerging fields of regulations 



 

(III. Business and digitalization). The papers examine the adoption of 

technological innovations in higher education, e-commerce related 

aspects of computer games, legal challenges of smart contracts and 

autonomous vehicles.  

The Forum was a part of the ‘Jean Monnet Module on EU Business 

Law’ (EUBLAW) project funded by the European Commission’s Erasmus+ 

Programme in the Period of 2016 – 2019, and this year, the CES 

organized the event in cooperation with the SmartLaw Research Group. 

 

 

Editors 

Győr, December 2019 

 



 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

I. Artificial Intelligence: legal 

implications 
 

 

 

 





 

 

Knight Rider’s Brothers Coming Soon – What About Their 

Legal Situation?

 

 

 

GĂĄbor KertĂŠsz*  
 

 
Abstract: Nowadays, we are confronted more and more times with the issues of 

artificial intelligence and (partly or completely) self-driving vehicles. How does this 

technical development change our daily lives? What can ""Law"" do with these? In the 

analysis I am looking for the answer how these technical novelties can fit into the 

structure and logic of the legal system. During this process I use examples of history 

and legal history, other social sciences and modern business logic as well. 

 

 

Keywords: artificial Intelligence, self-driving cars, responsibility for damages  

 

1.  Introduction 

In the 1990s, television channels broadcasted the Knight Rider 

action film in a huge number of countries around the world, in which one 

of the main characters was a self-driving car. That time it existed only at 

the level of dreams and on the design tables of engineers, today it is 

reality in some parts of the world.  

1.1. A bit of „layman philosphy” 

Our long-standing expectation towards machines to work perfectly, 

flawlessly. In the contrary our recurring experience is that ""nothing is 

perfect"" ""what may go wrong will go wrong"" and we have to admit that a 

thing without any errors has never been made by a non-perfect person. 

From this point of view, we can ask how many % of the errors are 

accepted in practice naming the thing ""perfect"" or rather appropriate. 

The concept of damage appears already in the earliest legal systems. 

The concept clarified in the old Roman law is still perfectly applicable 

today, according to which the damage has two parts: the real damage 

 

 
* College professor, International Business School (Budapest). 



12 GĂĄbor KertĂŠsz 

 

(dannum emergens) and the loss of profit (lucrum cessans). Based on 

these, it is a question of argumentation to determine whose (active or 

passive) behavior caused the damage and who bears responsibility for 

the damage. It is usually a judicial procedural task not to allow the 

evidence procedure to sink into the infinite marsh of the principle of 

conditio sine qua non. 

2. Historical examples 

2.1. Legal instruments nowadays that come from legal history 

These legal instruments of responsibility have been created in the 

history of law during the technical development to solve the current 

problem. Man first tamed / domesticated animals that typically followed 

his instructions, but sometimes did not or not well executed the 

instruction and caused damage. The issue of liability for such damages 

caused by animals has been established long ago, and its structure has 

not changed since the first civilizations, and our act uses their logic still 

today.1 Also, since the earliest settled civilizations where built 

environment has been built, the question of damage caused by objects 

falling from buildings2 is known. Although the material and design of our 

buildings have undergone many changes over the past millennia, the 

handling of damages by objects falling from the buildings has not 

changed much over the past two thousand years. The next form of 

responsibility was developed due to another historical step that was the 

industrial revolution. The concept and liability of dangerous operations3 

is approached by the structure that was formed at that time, although 

nowadays many of these types of ""operations"" operate on a daily basis, 

and only the detailed rules for the new types are added to the centuries-

old structure. The last type of liability (although it can still be argued that 

this is not yet clear, but still in the process of being developed) is product 

liability4, where the link is created between the manufacturer and the 

 
1 Liability for the damages caused by animals Ptk. 6.:562-563. §. Here and 

thereafter, I refer to certain provisions of the Hungarian Civil Code (Ptk.), which has the 

same content in civil law in all the legal systems of the world. 
2 Liablity for building damages Ptk. 6.:560-561. §. 
3 Liability for dangerous operations Ptk. 6.:535-539. §. 
4 Product liability Ptk. 6.:550-559. §. 



Knight Rider’s Brothers Coming Soon – What About Their Legal Situation? 13 

 

end user of the product by omitting the intermediate elements of the 

causal chain.  

As a continental lawyer I looked for similar cases for autonomous, 

self-driving vehicles.  One of the “precedents” - using several multiple 

quotation marks - is the case of animal damages5. In this case an animal 

with independent autonomous animal intelligence causes damage and it 

is a partial question if the owner “led” the animal, or is made itself 

independent or uncontrollable. The other case that could be a 

“precedent” is the liability of the legal entity, where the legal person that 

caused the damage, will be liable for the damage and the legal entity will 

be obliged by the court to pay the compensation for the damage. 

With legal logic and expert arguments on a case-by-case basis, it is 

possible to determine in which proportion and percentage the potential 

responsible people (responsible groups) listed and analyzed above are 

responsible for the damage. The traditional market logic provides 

insurance as a solution to a potential threat, where we can atomize the 

actual damage between the members of the risk community. 

Another possible answer of business logic is to burden the damage to 

the one who caused it. Here the legal logic says today that to oblige a 

damage-causing truly self-driving vehicle to indemnify the damage, it 

should be a legal entity. Not going into the solutions of ancient - not 

Roman - and medieval rights that have passed the ownership of the 

damage-causing animal, or the harmed received temporary use on the 

animal, in case of self-driving cars the similar solution is possible, as it is 

a fact that the damage-causing thing has a value for use and it is able to 

produce it regularly. 

2.2. Philip IV. (the Fair) 

The next example is about a minor change made by the legislator 

that made a huge change in the historical perspective and that 

fundamentally influences national identity. Philip the Fair, king of France 

ordered in 1308 that in a case between non-barons, the court 

established at that time and permanently operating at the Royal Palace 

in Paris should make a final decision either in direct action or in appeal 

against a provincial judgment. This court used the local language around 

 
5 Ptk. 6:562.563. § 



14 GĂĄbor KertĂŠsz 

 

Paris and its code of conduct made it clear to accept only contracts and 

actions written in the language of the court6. From the early Middle Ages 

in today's France, the provinces with individual feudal autonomy spoke 

their own local language7. As a result of this law, in just a few decades, 

the language of the court became known as a written language in every 

corner of the Kingdom of France, which we now know as a French 

language, as it was in everyone's interest to write all the contracts in that 

language. Nowadays, French is an important element of French national 

identity. 

This is a good example of the fact that standardization of the rules for 

the use of certain elements of Artificial Intelligence (e.g. self-driving cars) 

will be significant for all members of society and will have a social 

organizing and forming effect in the long run. 

3. Who can be liable if Knight Rider makes an accident? 

Let us shortly list the different human beings who have any 

connection with Knight Rider’s birth. 

3.1. Possible liable people 

3.1.1. Driver 

This is the only member of the coming list, where - according to the 

current Hungarian legal environment - only one natural person can be a 

subject. Until now, the liability of the driver was an evidence in the case 

of damages caused by man-, animal- or machine powered vehicles. 

Nowadays there are vehicles that are not driven by humans, but are 

driven by the intelligent / autonomous vehicle itself in self-driving, 

however in the Union they drive only on test fields, not in real traffic. 

After a broad social debate involving the whole human civilization, it can 

be agreed if the natural people in self-driving vehicles should, and if so 

at what level, control the proper / accident-free operation of the vehicle. 

Currently, although we have already met a few legal cases, where the 

 
6 PĂĄl HorvĂĄth, IstvĂĄn KajtĂĄr, LĂĄszlĂłnĂŠ Nagy, T. MihĂĄly RĂŠvĂŠsz, IstvĂĄn Stipta and 

Jånos Zlinszky, Általånos jogtÜrtÊnet I. (Nemzeti TankÜnyvkiadó 1994) 64. 
7 This was the language of the certain Gaul tribe from which the people of the 

province originate. 



Knight Rider’s Brothers Coming Soon – What About Their Legal Situation? 15 

 

responsibility of the driver has been established on the basis of 

traditional logic, neither the public opinion nor the legislator has 

conducted this increasingly necessary debate yet. If the decision is 

made, it can be translated then into a known form of liability. According 

to the current Hungarian rules, if the vehicle is in motion, one person 

must be in the driving position continuously8. The Hungarian practice 

has not yet faced a case when the vehicle was self-driven with an empty 

driver seat causing an accident / damage. However, with the 

development of technology the question has to be answered soon 

whether the person who switches the vehicle into self-driving mode is a 

driver according to the Road Traffic Code? Does this person stay a driver 

after leaving the vehicle, which continues the way in self-driving mode? 

With traditional legal deduction the question can be replied in a 

conventional way. In this case, the question is modified to the following: 

does it worth to invest in the development / acquisition of such a 

vehicle, if my responsibility for a self-driving vehicle is the same as if I 

were actually driving it? Or how worthy it is for me if I have possibility to 

do other activity(s) besides controlling the vehicle during sitting in the 

driver's seat? 

3.1.2. Owner 

The Road Traffic Code basically lays down rules for the traffic 

participants: the driver and the passenger, and the owner appears only 

once in the text9, but in the meantime the owner is recorded separately 

in the traffic license. We have been treating it for thousands of years as 

an evidence that the owner is responsible for the damage caused by his 

property.10 It is important to recall here for a moment the analogy that 

the tutelary is responsible for the damage caused by the unpunishable 

person.11 

 

 

 

 
8 Road Traffic Code (KRESZ) 4. §. 
9 Road Traffic Code (KRESZ) 59. § (3) subpar. 
10 See e.g. footnote no 2, 3, 4. 
11 Liability for damages caused by unpunishable person Ptk. 6:544-547. §. 



16 GĂĄbor KertĂŠsz 

 

3.1.3. Retailer, Wholesaler, Importer 

At this point, we arrived at to the actors of the sales chain, calling the 

person12 - in practice typically a legal person - a retailer who sold the 

vehicle to the owner; the other players are working on the basis of 

traditional trade contracts, their responsibilities are governed by the 

contracts, the relevant customs and the practice of the judiciary and 

arbitration court. 

3.1.4. Tester team 

Here, on the one hand, it is the task and responsibility of the team to 

perform all the necessary tests thoroughly and professionally and on the 

other hand to ensure that all relevant tests are performed. Although this 

team typically consists of engineers, they have to keep in mind that they 

have to test the vehicle in every theoretically possible situation and 

check how it behaves in each case. It is often told about us as lawyers 

that we are writing novel-length contracts as 'graphomans' in which we 

try to get prepared for every single theoretically imaginable risk factor. 

The test team has a similar task to examine how the vehicle responds in 

a self-driven mode to the variety of all theoretically possible situations. 

For the test team only the collective responsibility can be imagined, 

since the outstanding and indispensable contribution of a team member 

is theoretically conceivable, but apart from such extreme situations, the 

contribution of all members of the team is equally important for the 

proper performance of the test and the evaluation of the result. Although 

they are not members of the testing team, but the decision-makers of 

the enterprise also have a responsibility here, as the management 

decides based on the results of the tests, with engineer, lawyer and 

economist support if the vehicle is ready to be put on the market / in 

traffic or further development is needed. 

3.1.5. Software-developer team 

This team develops the software (system) that ensures the vehicle's 

self-driving ability. Nowadays, developers generally “teach” the systems 

 
12 I examine only the sales of new vehicles. The sales of used vehicles is out of 

scope of the examination. 



Knight Rider’s Brothers Coming Soon – What About Their Legal Situation? 17 

 

in a way that it faces decision-making situations continuously, and it 

achieves a better percentage of success due to this “learning”. The 

other, nowadays in minority applied solution is to program the ""right / 

good / desirable"" solution and the system has to avoid the rest. The 

responsibility of the developers is unavoidable for both methods. In the 

first method the responsibility originates in the examples that were the 

base for teaching the system. It can happen that even though the 

sample consists of a large number of elements, there can be cases that 

are out of the model and the machine will not recognize them and it will 

not be able to handle them well. In the second method, the more 

detailed description of the good solution is important, so that the 

machine can handle the situation that actually arises, even if it is new, 

but similar to a learned rule. At this point, the question of the need for 

ethics arises. If in a given situation only bad decisions can be made and 

non-decision is also a bad decision, which wrong decision should be 

made by the Artificial Intelligence that was taught and built in the 

system? 

A comprehensive research project was launched in 2016 with 40 

million people worldwide, related to the artificial intelligence-driven cars 

being developed nowadays. Researchers were looking for an answer to 

what people say: if there is no way to avoid an accident, who should hit 

the car? The answers outline a world-wide view of what we are protecting 

more and what less. The results of the research have been published 

only half a year ago13. The article first states that it cannot be considered 

worldwide statistically representative because of the limited possibilities 

of sampling, but the data collected show that children are more likely to 

be saved than adults, but this is only a global average statistical result, 

because the range of bad decisions differ from country to country and 

even more from culture to culture. The results of the world average are 

not the same as the results of the regions and metropolises that are the 

most multicultural according to sociologists. So according to the data, 

people in different cultures of the world set different order of 

importance, or approach the question from the other side, a different 

order is set in the list of other people and objects to be sacrificed. So, if 

 
13 Edmond Awad, Sohan Dsouza, Richard Kim, Jonathan Schulz, Joseph Henrich, 

Azim Shariff, Jean-François Bonnefon and Iyad Rahwan, ’The Moral Machine 

experiment’ (Nature, 24 October 2018). 



18 GĂĄbor KertĂŠsz 

 

there are such significant sequencing differences in case of people from 

different parts or different cultures of the world, in which order to protect 

the different values in an emergency, then Artificial Intelligence will also 

not be able to decide according to a generally accepted sequence, 

although such situations relatively  often occur during traffic. 

In this case, the question arises which culture’s prioritization will be 

the base for the self-driving vehicles choice, i.e. which sequence was 

programmed/taught by the programming team. Here, group dynamics 

and hierarchical relationships within the group as well within the 

organization can also influence the sequence they teach, along with the 

cultural patterns of the team members and other individuals involved. 

I.e. if the development team is culturally homogeneous and whether the 

final decision-making management has the same, homogeneous cultural 

background. For most of these companies, we cannot say yes to this 

question with a calm heart. This results in the following: there is a 

significant likelihood that the sequence of priority will be determined 

differently by not only the vehicle types produced by the different 

manufacturers, but also by the same brand and type of self-driving cars, 

if they are produced in different plants of the world far away from each 

other, if Artificial Intelligence is made independently in the plant, rather 

than installing a centrally-produced system in vehicles manufactured in 

all factories around the world. The issue is about the choice of victim14 in 

an inevitable situation of a self-driven vehicle programmed under the 

rules of other cultures. In my opinion this issue can be settled 

satisfactorily through an agreement resulting from a consultancy with 

the presence of the whole world, or if the producers mutate the vehicles 

into the different cultural regions where they are sold. It is not primarily a 

business law issue, but a fundamental rights issue if it is allowed to the 

owner/driver to download versions of other cultures; either because he 

disagrees with the culture of his place of residence and feels another his 

own, or because he is planning to go to the territory of this culture - 

though the latter can be automatically solved by the service that if the 

vehicle crosses the ""cultural boundary"" according to its GPS coordinates, 

the system downloads the version that is valid in that area. 

 
14  E.g. the choices were different when the vehicle hits the old person or the child 

in order to save the other one – see same as footnote no 13. 



Knight Rider’s Brothers Coming Soon – What About Their Legal Situation? 19 

 

3.1.6. Planner team 

This is a team consisting of mostly engineers who design the 

""hardware"" of the vehicle. In addition to the fault possibilities of 

conventional vehicle design, only one new risk factor appears here. It is 

a well-known experience in conventional vehicle driving that there are 

""dead spaces"" in case of all vehicles depending on the vehicle’s size, 

which are not visible to the driver. Their magnitude cannot be completely 

removed, only reduced with the rear-view mirror system. In case of self-

driving vehicles, however, the expectation is that the machine should 

see everything in real time, simultaneously and drive itself accordingly. 

That's why the design team here, beyond the usual design 

responsibilities of traditional vehicle design, has to meet „only” one new 

requirement. On the vehicle the environment sensors must be 

positioned so that they can continuously see all objects in real time 

within the current speed braking distance that would presents a risk of 

accident in case of going without change. (Of course, the danger of a 

new object that might come out of the cover of another object is 

excluded here.) If the design really reduced the size of ""dead spaces"" for 

self-guiding sensors to 0%, the design team does not have any more 

responsibilities than the ones coming from traditional design 

responsibilities. The current traffic situation was detected by the sensors 

that transmitted it to the software, which made the decision in self-

driving mode, which is the result of the work of the development team15. 

3.1.7. Controller team 

Modern states usually have a body that controls various activities 

carried out by economic actors. The depth of control that this body 

performs varies from body to body and from country to country. If a 

causal link can be established between the authorization procedure of 

the authority and the damage caused, the determination of damage 

caused by administrative law may arise if it was not possible to avert the 

damage by ordinary legal remedy or in administrative juridical action16. 

The theoretical possibility of this in the examined issue arises only if 

 
15 See footnotes no 13 and 14. 
16 Ptk. 6: 548. §. 



20 GĂĄbor KertĂŠsz 

 

such an error originating in the type of the self-driving vehicle, which has 

not been recognized either by the licensing authority or the 

manufacturer's designer, software developer and test team previously. 

3.1.8. Legislator  

Legal acts created by the legislator are applied by legal entities and 

by the executive and judiciary branches. And it is a century-old, if not a 

millennium-old fact, for which we can find more and more examples 

nowadays that it is possible to legislate only such situations that already 

occurred, or they could be predicted with significant possibility. The new 

life situations that have arisen after the legislation have typically 

appeared as a legal loophole in continental law systems, and in the 

Anglo-Saxon systems precedents are sought. From a legal point of view, 

the “legislator's silence” - if no law was created on the certain situation - 

cannot be interpreted as a damaging fault. However, economic actors 

can perceive it as a damaging fault according to the logic of the 

economy, of the business and if the market. The question that arises 

here is whether the legislator has created the legal system so that it is 

able to deal with the problem of damage caused by a self-driving vehicle, 

and whether this solution is appropriate for society (for voters?). 

3.2. How can Knight Rider be liable? 

According to the basic division in law, there are legal subjects and 

legal objects. There are no third and temporary categories. We neglect to 

discuss the historical development of the general, unconditional and 

equal legal subject people have. We only mention the last step in the 

development of legal entities, the second group of legal subjects known 

today: ""The legal personality of a legal person extends to all rights and 

obligations that, by their very nature, may not only be related to a human 

being""17, i.e. the legal personality of the legal person is not bound to a 

purpose, but it is general. It is not a matter of jurisdiction, but a matter of 

legislation which listed actors and in which extent are made liable for the 

damages caused by the self-driving vehicle. It is already the task of 

 
17 Ptk. 3:1. § (2) subpar. 



Knight Rider’s Brothers Coming Soon – What About Their Legal Situation? 21 

 

political science to examine political programs, political marketing, and 

legal lobbying of the interested companies. 

Taking the two premises into consideration that the self-driving 

vehicle is capable of making autonomous decisions - respecting the 

rules of social cohabitation - and is capable to generate financial value 

continuously, the business logic raises the question in a right way why 

this vehicle cannot be an actor in business life on its own? As besides 

people - nowadays mainly in the international business community, 

instead of people – it is worldwide an accepted evidence by everyone 

and everywhere that ”legal constructions” named legal entities have 

legal subject, independent from the fact that no one has seen a legal 

entity, only a person representing it, its logo, or its headquarters. 

However, the self-driving vehicle is a tangible physical reality. 

Since the concept of a legal person appeared in legal history till the 

present, there is clear evidence that non-human private entities 

ultimately have a human owner. Nowadays, a new concept has emerged 

on the periphery of the legal subjects, which is the ""actual beneficial 

owner"" who increases its assets with the values produced by the 

examined legal entity, or has the right to dispose of these assets either 

directly or through mandatory instructions given to the participants in the 

chain18. Not going into details in the psychological, corporate, and social 

sociological question of what group dynamics each company (regardless 

of its legal form) has; we can say that the purpose of the company (the 

legal entity in question) is to live / operate further. As an analogy to this 

approach, we can assume that the autonomous, self-driving vehicles are 

also aimed for further operation; however, this hypothesis gives the 

software development, testing, and control teams an important task. The 

mentioned research looked for a reply about who the vehicle would 

rather hit19. For a human driver, it is an existing option, for which there 

are some famous examples, that the person sacrifices his own life, and 

with this, saving many. With the sensors of the vehicle's seats, on the 

base of the weight of each passenger, the vehicle “knows”20 how many 

 
18 About the concepts „beneficial owner” and „actual beneficial owner” see the 

different conventions about avoiding double taxation and 7. point of 7. App of the 

Hungarian citizens income tax act. 
19 Awad et al. (n 13) 
20 Not going into details about the results of Awad et. al. (n 13), according to which 

the general cultural reply to this in Europe is that the driver puts suitcases on each seat 

 



22 GĂĄbor KertĂŠsz 

 

adults and how many children are traveling in it, and even through the 

impleme";"""date"",""2020-12-07T10:39:34Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""EUBLAW-WP""
""xmp:CreatorTool"",""MicrosoftÂŽ Word 2010""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dc:creator"",""Iroda""
""language"",""en""
""dcterms:created"",""2020-12-07T10:39:34Z""
""Last-Modified"",""2020-12-07T10:39:34Z""
""dcterms:modified"",""2020-12-07T10:39:34Z""
""dc:format"",""application/pdf; version=1.5""
""title"",""EUBLAW-WP""
""Last-Save-Date"",""2020-12-07T10:39:34Z""
""pdf:docinfo:creator_tool"",""MicrosoftÂŽ Word 2010""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2020-12-07T10:39:34Z""
""meta:save-date"",""2020-12-07T10:39:34Z""
""pdf:encrypted"",""false""
""dc:title"",""EUBLAW-WP""
""modified"",""2020-12-07T10:39:34Z""
""Content-Length"",""2226858""
""pdf:hasMarkedContent"",""true""
""Content-Type"",""application/pdf""
""pdf:docinfo:creator"",""Iroda""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Iroda""
""dc:language"",""hu-HU""
""meta:author"",""Iroda""
""meta:creation-date"",""2020-12-07T10:39:34Z""
""created"",""2020-12-07T10:39:34Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""258""
""Creation-Date"",""2020-12-07T10:39:34Z""
""resourceName"",""EU%20Business%20Law%20and%20Digital%20Revolution.pdf""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""40"",""0"",""240"",""865"",""1381"",""1031"",""1925"",""520"",""67"",""0"",""1736"",""2347"",""2321"",""2110"",""2073"",""2138"",""2625"",""2588"",""2256"",""2183"",""2704"",""2471"",""2659"",""2363"",""2602"",""2091"",""968"",""0"",""2169"",""2280"",""2653"",""2383"",""2542"",""2136"",""2590"",""2306"",""2311"",""2238"",""2312"",""1798"",""1790"",""676"",""1831"",""1382"",""776"",""2506"",""2587"",""2459"",""1728"",""0"",""2200"",""2483"",""2247"",""2469"",""2655"",""2168"",""2411"",""2657"",""2414"",""2244"",""2518"",""2287"",""2703"",""1928"",""2007"",""1949"",""1810"",""0"",""42"",""0"",""1883"",""2347"",""2910"",""2888"",""2727"",""2656"",""1069"",""2579"",""2452"",""2700"",""2408"",""2526"",""2580"",""2486"",""2195"",""1892"",""1829"",""0"",""2535"",""2609"",""2579"",""2502"",""2474"",""2544"",""2614"",""2744"",""2333"",""2217"",""2298"",""2522"",""2425"",""2298"",""2392"",""2385"",""2324"",""2425"",""2147"",""2499"",""2086"",""1840"",""1973"",""484"",""1924"",""2346"",""2454"",""2432"",""2190"",""2515"",""2335"",""2601"",""2434"",""2341"",""2238"",""2606"",""2535"",""2472"",""2624"",""2385"",""2792"",""2262"",""1781"",""1037"",""1913"",""2410"",""2496"",""2333"",""2235"",""2632"",""2394"",""2538"",""2645"",""2558"",""2287"",""2324"",""1766"",""1963"",""1853"",""634"",""2016"",""2355"",""2581"",""2717"",""2226"",""2225"",""2747"",""2395"",""2490"",""2376"",""2265"",""2203"",""2254"",""2258"",""2506"",""1992"",""1823"",""1829"",""1202"",""0"",""53"",""0"",""2270"",""2645"",""2699"",""2376"",""2655"",""2255"",""1454"",""2186"",""2544"",""1573"",""1965"",""1561"",""1682"",""581"",""1298"",""1362"",""2069"",""1962"",""2248"",""1677"",""392"",""0"",""2036"",""2380"",""1999"",""2294"",""2339"",""1840"",""2364"",""2298"",""2155"",""2099"",""2418"",""1985"",""1863"",""1841"",""1022"",""0"",""1848"",""2262"",""1060"",""2503"",""2657"",""2575"",""905"",""632"",""2493"",""2335"",""2272"",""2282"",""1317"",""1844"",""817"",""2285"",""2701"",""2388"",""2125"",""2181"",""1996"",""2040"",""1918"",""1629"",""2257"",""2690"",""3383"",""2858"",""2732"",""2340"",""2647"",""2216"",""2699"",""2557"",""2280"",""2671"",""2875"",""3011"",""2558"",""2234"",""2266"",""2486"",""2184"",""2035"",""1968"",""1441"",""1697"",""1864"",""2598"",""691""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""Author"",""Iroda""
""producer"",""MicrosoftÂŽ Word 2010""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""MicrosoftÂŽ Word 2010""
""pdf:docinfo:created"",""2020-12-07T10:39:34Z""
";https://scholar.google.ch/scholar?start=870&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098787-153;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Corporate Cash Flow Transformation and Payment Space Digitalisation in the Eurasian Economic Union;N Kunitsyna, E Dyudikova ; Journal of Corporate Finance Research …, 2020  cfjournal.hse.ru;;"… transfer of information consists in innovative distributed registry technology (eg blockchain), which

entered … but from the perspective of modification of operat- ing cryptocurrency systems which …

consolidates the furnished information and places it into the oracle (an infrastructure …";;;[PDF] hse.ru;https://cfjournal.hse.ru/article/download/11117/12671;"
Journal of Corporate Finance Research / Discussions 2020 | Vol. 14 | # 3

Higher School of  Economics90

Corporate Cash Flow Transformation 
and Payment Space Digitalisation in 
the Eurasian Economic Union

Ekaterina Dyudikova 
candidate of Economics, Doctoral student of Department “Finance and Credit”
ORCID
E-mail: dudikova.e@gmail.com
North-Caucasus Federal University, Stavropol, Russia

Natalia Kunitsyna 
Doctor of Economics, professor, Head of Department “Finance and Credit”
ORCID
E-mail: natkun2004@mail.ru
North-Caucasus Federal University, Stavropol, Russia

Journal of Corporate Finance Research, Vol. 14, No. 3, pp. 90-102 (2020) 
DOI: https://doi.org/10.17323/j.jcfr.2073-0438.14.3.2020.90-102
Received 13 April 2020   |   Peer-reviewed 15 May 2020   |   Accepted 25 May 2020 

The journal is an open access journal which means that everybody can read, download, copy, distribute, print, search, or link to the full texts of these 
articles in accordance with CC Licence type: Attribution 4.0 International (CC BY 4.0 http://creativecommons.org/licenses/by/4.0/).

https://orcid.org/0000-0001-8126-6529
mailto:dudikova.e@gmail.com
https://orcid.org/0000-0001-9336-8100
mailto:natkun2004@mail.ru


Journal of Corporate Finance Research / Discussions 2020 | Vol. 14 | # 3

Higher School of  Economics91

Corporate Cash Flow Transformation and Payment Space Digitalisation in the Eurasian 
Economic Union

Abstract
Modern digital systems in the EEU do not meet the requirements for official methods of transferring funds, and are not 
appropriate for use in the field of corporate finance. As such, we propose the development of a modified digital system 
combining the principles and capabilities of traditional and innovative systems based on distributed registry technolo-
gy. This should promote integration of national payment systems into the financial sphere under conditions of sanction 
burden, and low trust in the virtual world. 
First, we outline the features of corporate cash flows through digital financial assets transfer in a national digital system, 
and cross-border settlements within a common digital payment space. Next, we describe the possible roles of corporate 
structures and individuals in payment systems within an EEU common digital payment space. We combine methods of 
formal logic, historical and comparative analysis, modeling, and graphical interpretation. The study of the digital finan-
cial space was carried out on a selection of materials from the Russian Federation, Armenia, Belarus, Kazakhstan, and 
the Kyrgyz Republic.
Our results illustrate the practical value of a new digital system in reducing the influence of intermediaries, and of inte-
grating systems with different types of information into a common database. In addition, we indicate how the prevailing 
international digital transfer system will accelerate, simplify and reduce the cost of cash flow procedures for organisa-
tions. By leveling the need for an international digital unit, such a system will play an intermediary role. We identify the 
necessary conversion operations to achieve this. 
The scientific novelty of this study resides in the fact that there is no current analogue for the project proposed herein. As 
such, we present a large scale and straightforward roadmap for an ambitious and adaptive response to digital develop-
ment opportunities, social evolution, and financial obstacles.

Keywords: cash flow, corporate finance, distributed register; digital system; digital settlements; digital financial assets
JEL classification:  G30, О16, О33



Journal of Corporate Finance Research / Discussions 2020 | Vol. 14 | # 3

Higher School of  Economics92

Introduction
Nowadays, society is highly dependent on information 
financial systems. Their regular failures result in losses of 
funds, reputational damage, instability in financial flows, 
decline of trust to organisations and national payment 
systems, and interstate conflicts. Existing closed settlement 
and payment systems are based on the principle of central-
isation and concentrating “power in the hands of a single 
person” which impedes the reliability, transparency, and 
independence of operations as well as countering the dollar 
spread in circumstances of a global recession, financial cri-
sis, or a generally tight geopolitical and economic environ-
ment [1–5]. The available information systems are over-
loaded by the increasing amounts of data to be processed. 
As a result, significant financial expenditures are necessary 
to modify these systems, otherwise they fail to ensure a 
proper quality of rendered services. At the same time, their 
autonomous functioning complicates and lengthens the 
relevant cross-functional interaction procedures. Corpo-
rate entities increasingly need to develop automation of 
financial procedures and transform their corporate inter-
actions, which in the long run facilitates reduction of time, 
labour, financial costs, intermediation of economic entities, 
the number of repetitive (double) operations, and the paper 
and electronic workflows. The solution which addresses the 
requirements imposed by the fourth industrial revolution 
regarding storage, processing, and transfer of information 
consists in innovative distributed registry technology (e.g. 
blockchain), which entered the financial field at lightning 
speed and is still gaining popularity [6–13]. In previously 
published papers dedicated to issues of common digital 
space creation, the authors identified comparative char-
acteristics of the traditional and innovative approaches to 
arranging settlement and payment systems. These were 
accompanied by descriptions of operational principles and 
advantages and disadvantages of each of them1, a stipula-
tion that it is reasonable to integrate innovative technology 
into the settlement and payment space (which consists of 
a positive technological, economic and social effect2), and 
compared versions of the common digital space model, 
justifying the most reasonable choice3. Apparently, it is 
exactly the capability of digital settlements to satisfy the 
corporations’ needs in the automation of financial proce-
dures which made them popular against the background 
of no lawful status and legal and regulatory framework. 
Digital systems did not find legal use either in the national 
payment system or in the international payment space 
[14–16]. Different attitudes to the digital financial system 

1 Apergis N., Kunitsyna N., Dyudikova E. The Role of Electronic Money in the Payment System: Evidence from Middle-Income Economies // 
International Journal of Emerging Trends in Engineering Research. 2020. Vol. 8. No 1. Рр. 67–78.  
2 Kunitsyna N., Dyudikova E. Prospects of Implementation of Cryptocurrency in the Russian National Payment System  // Current Problems of 
Operation of the Regional Financial Mechanism: Materials of All-Russian Research-to-Practice Conference. Makhachkala: Dagestan State University, 
2016. pp. 215–221; Dyudikova E. Risks as an Integral Part of Applying Centralized and Decentralized Approaches to Arrangement of Electronic Money 
Systems // Contemporary Trends in Economics and Management: New Insight: Collection of papers of the XLII International Research-to-Practice 
Conference. Novosibirsk: publishing house Center of Scientific Cooperation Development, 2016.
3 Dyudikova E. Implementation of Cryptocurrency into the Russian National Payment System // Economics and Management: Problems, Solutions. 
2016. No. 9. Vol. 1 (57). Pp. 185–190; Dyudikova E. Models of Digital Technology Integration into the International Payment Space // St. Petersburg 
State Polytechnical University Journal. Economics. 2020. Vol. 13. No. 3. Pp. 187–200.

of the Eurasian Economic Union members slows down 
the process of establishment of the common digital space. 
In this context, it is reasonable to create a common digital 
settlement and payment system, and to establish an EAEU 
Interstate Bank (EAEU IB) which will initiate and drive 
preparation and unification of information exchange for-
mats, creating a new structural architecture and arranging 
of an extensive implementation of innovative technology at 
the international and national level.

Model of the EAEU Common Digital 
Payment Space  
Currently, the majority of central banks of the countries 
which jointly account for 75% of the global population 
and 90% of economic industry acknowledged the poten-
tial of digital settlements which are gaining popularity 
[17]. The Bank of Russia is no exception. It made a public 
announcement of the consultation paper “A Digital Ruble” 
[18], which was the first stage of digitalisation of the 
settlement and payment field. This document defines con-
troversial issues related to the integration of digital assets 
into the payment system. The author’s position on these 
issues is outlined in this paper.
Payment space digitalisation requires a unification of 
different functionalities in order to achieve a transparent 
‘interdepartmental’ interaction and respond to current 
global challenges. Therefore it is important to note that 
the digital system modifications we propose are aimed 
at providing an opportunity for use by corporations and 
organisations which cash flows are mainly serviced by 
cashless transfers. In particular, these systems which 
clearly indicate the roles of legal entities and stages of 
cash transfer require the attention of corporations and 
organisations. While credit organisations and government 
authorities are still considering and investigating the 
possibility of implementing digital systems, organisations 
already use them for mutual settlements’ procedures, ad-
justing the technology innovation to requirements of the 
Russian legislation (S7 Airlines is a specific example).
The development and implementation of the model of 
the common digital payment space involves the following 
stages:
• formation of the legislative framework for digital 

financial assets turnover, which unambiguously 
determines the concept of their integration and 
further development;



Journal of Corporate Finance Research / Discussions 2020 | Vol. 14 | # 3

Higher School of  Economics93

• defining requirements to a legitimate digital 
settlement and payment system;

• defining the approach to creating a common digital 
payment space;

• choosing the model of the national digital settlement 
and payment system;

• calculation of financial and economic indicators of 
the national digital settlement and payment system;

• development of organisational and methodological 
recommendations for interaction between subjects of 
the national digital settlement and payment system;

• establishment of the national digital settlement and 
payment system in accordance with the chosen 
model and its integration into the payment space;

• transformation of the national digital settlement 
and payment system into a common comprehensive 
multifunction digital platform;

• calculation of financial and economic indicators of 
the digital system of international interaction;

• development of organisational and methodic 
recommendations for interaction of subjects of the 
digital system of international interaction;

• establishment of the digital system of international 
interaction in accordance with the chosen approach 
and model with its further integration into the 
payment space.

In constructing the model of the common digital payment 
space of the EAEU, we presume that each member state 
will establish a common national digital settlement and 
payment system. The interaction between the countries 
when making settlements should be performed through 
the common digital payment space. The EAEU IB will 
be its operator, which will devise rules for international 
settlements, and become the supervision and control 
authority for cross-border settlements (Figure 1).

Figure 1. Structural diagram of the common digital payment space in the EAEU

Russian
Federation

Republic 
of Armenia 

Kyrgyz
Republic

Republic of Belarus

 Republic 
of Kazakhstan

Individuals Digital systems servers Common payment 
space 

Legal entities National 
digital system

International 
digital system

Government 
organizations

 Central Bank 
(financial organizations) Interstate Bank



Journal of Corporate Finance Research / Discussions 2020 | Vol. 14 | # 3

Higher School of  Economics94

According to the presented model, the national digital 
systems and the international digital system are autono-
mous and interact on the basis of the sidechain technolo-
gy within the common digital space [19]. National digital 
systems operate in accordance with the relevant national 
legislation, and are available for their departmental cor-
porations and organisations in the operations monitoring 
mode. The model serves to automate the taxation and set-
tlements functions. In its turn, the EAEU Interstate Bank 
can monitor all financial operations in the international 
digital system.
Making a distinction between the role of users (corporate 
entities and individuals) and national and international 
settlement systems, we defined their functionality and 
identified cash flow directions. Various proposed modifi-
cations of interactions between settlement participants are 
characterised in the model below. We would like to em-
phasise that the presented components are considered not 
as a part of the digital system in the context of its architec-
ture, but from the perspective of modification of operat-
ing cryptocurrency systems which allow to eliminate their 
drawbacks to make them legitimately applicable. 

User Roles in the National Digital 
System 
Depending on the user’s role in the digital system, users 
are divided into individuals and legal entities. Various 
functions and capabilities will be available for them. Indi-
viduals performing settlement and payment operations in 
the system personally, on behalf of third parties, or as an 
organisation’s representative, may be the ultimate users of 
digital systems. Each of them registers an account in the 
digital system which allows to go through an identifica-
tion and authorisation process using a public and private 
key to enter the personal account. A user with an account 
can transfer funds through the system, request informa-
tion on other users, get access to private and public infor-
mation about other users in the system, and sign smart 
contracts (SC). Each account is mandatorily inextricably 
connected with the object (an individual), and if neces-
sary, has additional connections with other objects (e.g. 
individuals, third parties, corporations, organisations, and 
government authorities). 
The personal account of an individual user contains his/
her private data, information on all issued documents, 
an electronic wallet, and states the resident/non-resident 
status. This information is placed and stored in the private 
data register. If necessary, additional entries may be en-
tered in it. Information may be used by means of inter-
departmental interactions in order to automate taxation 
procedures, the granting of social payments, etc. Individ-
uals may make a transfer of digital financial assets (DFAs) 
between users of the national digital system. As such, 
the digital system may limit the amount of a transaction, 
or number and frequency of transfers within a certain 
period.

Users’ accounts are unique and belong to specific individ-
uals. Depending on the roles available to the user, opera-
tions may be performed by an individual on his/her behalf 
or on behalf of a legal entity. Access to management and 
performance of functions on behalf of an organisation is 
granted through the role of an officer of such organisation 
when the organisation is established, or when such person 
is appointed to his/her position. All information on a legal 
entity is placed and stored in the legal entities register and 
is available for interdepartmental interaction.
Financial organisations are granted additional functions 
such as the routing of financial information between 
users, rendering financial services, and the recharging 
and lessening of the balance of users’ e-wallets by means 
of cash lodgments and transfer of funds performed with 
use of other settlement and payment systems. It should be 
emphasised that apart from the Bank of Russia, financial 
organisations cannot issue DFAs in the national digital 
system. The Bank of Russia is authorised to make the rules 
of settlement operations. 
It is supposed that information in the national digital 
system is entered by government administrators while 
they perform their operations. Thus, for example, original 
registration and information update for individuals is car-
ried out by civil registry offices and the migration service, 
for legal entities this is done by the tax authorities etc. 
Functions of the authorised government establishments 
also comprises monitoring of international funds trans-
fers. As such, supervisory authorities are able to control 
all incoming and outgoing DFA flows in the national digi-
tal system in order to comply with anti-money laundering 
legislation.

User Roles in the International 
Digital System
Unlike the national digital system, where accounts are 
registered for each user, in the international system 
accounts may be registered only by the EAEU IB and 
financial organisations’ employees authorised to deal with 
international operations. In this case, mandatory inex-
tricable connections are established with the object (an 
individual user) and objects (organisations). In the inter-
national digital system only utility functions are available 
for them (e.g. identification and authorisation using a 
public and private key; adding and changing the rules and 
terms of DFA settlements; request of information from 
the national digital system in order to register accounts). 
The account of an individual user in the international 
digital system contains only his/her private data, placed 
and stored in the private data register. 
Information on financial organisations which are 
cross-border settlement participants is entered in the 
legal entities register of the international digital system. 
The international digital system provides for the routing 
of financial information between users in the interna-
tional space. It also provides for the exchange of public 



Journal of Corporate Finance Research / Discussions 2020 | Vol. 14 | # 3

Higher School of  Economics95

information between national digital systems on request 
of financial organisations regarding the correctness and 
legitimacy oftransaction possibility. The EAEU IB would 
exclusively perform the function of differentiating access 
and registration rights’ of the end users in the internation-
al system.

Digital System Infrastructure 
Components
We presume that the following objects of the digital 
platform and its subsystems will be the digital system 
infrastructure components, inform the digital platform’s 
operation, and arrange the functions necessary for its us-
ers: access to the right verification servers, validators, and 
registration of storage servers. Access to the right verifica-
tion servers will provide for confirming the possibility of 
performing operations before they are added to the block 
on the basis of the rules of access (connection) to the 
distributed registers of the digital system. Validators will 
generate transaction blocks and send them to the distrib-
uted register after verifying the performed operations for 
absence of semantic errors and compliance with the terms 
of transfers (availability of a necessary DFA amount, un-
blocked status of the account, etc.). Finally, registration of 
storage servers is intended to add operation entries to the 
distributed register’s structure, such as:
• private data register, intended to store different types 

of individuals’ private information;
• legal entities register, providing storage information 

on legal entities stated in the Unified State Register 
of Legal Entities / Unified State Register of Individual 
Entrepreneurs;

• access rights register, comprising access permissions 
to the distributed registers’ data. The control 
mechanism of access to the user’s personal account 
provides an opportunity to restore access to the 
digital system in case of loss of access to the account 
and to entrust to a third party a complete or partial 
control on behalf of an individual. Such mechanism 
confirms the legitimacy of certain operations 
with data: if entries concerning furnishing of such 
information have not been cancelled, such an 
operation is deemed legitimate;

• payment register, which stores information on DFA 
flows: charging and withdrawal of funds, transmitting 
between the digital system users (the register 
comprises smart contracts);

• a register of the data not included in other registers. 
The list of registers in the international and national 
digital systems is similar but limited by the available set 
of information. Private data comprises information on 
employees of financial organisations dealing with interna-
tional operations, and processed corporate data comprises 
information on financial organisations involved in inter-
national operations.

In each EAEU member country the government is 
responsible for the digital system design and creation 
expenses. The central bank maintains its operation. At 
the international level, the capital financial expenditures 
for implementation of the system are distributed among 
countries, while the EAEU IB covers operational costs. 
We propose for the EAEU IB to own 100% of computa-
tion capacity (servers). However, in order to ensure the 
system’s territorial independence the servers should be 
located in EAEU countries pro rata with the estimated 
amount of operations performed in the international 
space multiplied by two.

User Logging in the Digital System
The primary account in the national digital system will be 
the entry made by the central bank of the country, in the 
international system – that of the EAEU IB. The central 
bank will establish a department for support of the digital 
platform whose functions will comprise the registration 
of accounts (and thus control of access to accounts) of 
financial and governmental organisations of the country, 
as well as their first administrators responsible for the 
registering and the state of accounts of their organisa-
tions. Then, on the basis of available data, governmental 
organisations enter the information into the legal entities 
and individual registers. Accounts of users of the national 
digital system, which also provides access to the e-wal-
let, are registered by financial organisations if there is 
validated information in the individuals and legal entities 
registers. If such information is unavailable, requests are 
sent to corresponding governmental organisations.
It is necessary to establish a department of the EAEU IB 
for support of the digital platform in the international 
digital system. Its functions will comprise aggregation of 
accounts of financial organisations involved in interna-
tional settlements and the relevant access control.

User Rights and Personal Account 
Access Control in the Digital 
System
Depending on their role, users may be assigned different 
rights. The same user may perform several roles simulta-
neously (for example, as an individual and an employee). 
According to the user’s role, the system of personal ac-
count access control allows for determination of the possi-
bility of certain operations with data and objects of the 
digital system (Figure 2). When a user is assigned rights, 
information on the administrator assigning it is indicated. 
Rights cannot be eliminated from the digital system per-
manently and tracelessly. In case of change in the rights 
‘portfolio’, a new right is assigned. In order to provide an 
opportunity to use this function, the objects in the digital 
system are connected with other objects (for example with 
a user) via his/her rights portfolio. An account is an object 
of the digital system, therefore the application of rights 



Journal of Corporate Finance Research / Discussions 2020 | Vol. 14 | # 3

Higher School of  Economics96

establishes relations between the object of an “account” 
and a “user”. In case of a locking of the “account” object, 
rights will emerge which deny access to the previously 
connected “user” object. In this instance the “user” object 
and all objects connected with it remain intact, and access 
to them may be granted through a new account.
We assume that rules of use of the distributed register of 
access rights should comprise the following:
• all rights and their changes are entered into the 

common register and are added in the order of 
arrival;

• the right of the same object and user entered into the 
register later than the previous one prevails;

• all user rights in the system are registered as separate 
entries indicating a certain right or limitation 
(prohibition);

• each entry regarding a change of the access right 
contains a hash (record) of the previous entry of the 
distributed register, a hash of the previous entry on 
the right of this user, a hash of the user, and a hash of 
the administrator which has assigned this right.

Issue and Introduction of Digital 
Financial Assets  
It is supposed that at the national level the issue of DFAs is 
the responsibility of central banks. DFAs are handed over 
to financial organisations entitled to operate in this field 
by transfer from the central bank’s e-wallet to the financial 
organisation’s e-wallet. The central bank may perform a 
continuous online control in the national digital system. 
Besides this, we would like to note that in this model, 
national DFAs have the status of a legitimate payment in-
strument and are identical all through their country, thus 
complementing the cashless money operations.
DFAs are not issued within the international digital 
system. DFAs introduced into the international digital 
system by means of the sidechain technology are indicat-
ed in e-wallets of financial organisations. In the interna-
tional system, DFAs are an accounting unit of national 
digital financial assets. The EAEU IB has an opportunity 
to perform continuous online control in the international 
settlement and payment system.

Figure 2. Personal account access control system4

П УЗX Y Z

#1 #N#2 #3 #4

Hash of the previous entry 
in the user rights register

Rights Register

Objects

Hash of user objects 
(users and administrator)

– “User” object;

– Objects of distributed registers of the digital system;

– User’s “Account” object.

Hash of the digital system 
objects of different registers

Hash of the previous entry of the right 
of the same user to the same object

П
X, Y, Z

УЗ

4 The administrator has the function of creating and changing user accounts, as well as assigning rights to them. 



Journal of Corporate Finance Research / Discussions 2020 | Vol. 14 | # 3

Higher School of  Economics97

Interaction of the Digital System 
with Cash and Cashless Money 
Turnover
There are two ways of introducing money into the nation-
al digital system at the ratio of 1:1. One is replenishing 
e-wallet with cash through a system representative, and 
the other is a cashless transfer from a bank account in the 
electronic settlement and payment system to the e-wallet 
in the digital system.
Money may be withdrawn from the national digital system 
at the ratio 1:1 only by a transfer from the e-wallet in the 
digital system to a bank account in the electronic settlement 
and payment system. After this, encashment is available.
Introduction and withdrawal of traditional payment in-
struments may be performed only within national digital 
systems through financial organisations. 
In the international digital system, the e-wallet balance 
may be increased or decreased exclusively by financial 
organisations participating in international settlements by 
the use of the sidechain technology. In the international 
system, financial assets are not kept in the e-wallet. In this 
case, the e-wallet is intended to register current cross-bor-
der transfers because it emerges from the national digital 
system. In the international segment, the operations are 
performed automatically.
The exchange rates of national DFAs exchanged for DFAs 
of the system member states are furnished to the EAEU IB 
automatically by each central bank of the EAEU at the in-
tervals defined by the charter of the EAEU IB. The EAEU 
IB consolidates the furnished information and places it 
into the oracle (an infrastructure algorithm which trans-
fers information from external environment to the digital 
system [20]) of exchange rates for further use in the digital 
system. This simplifies the procedure of cross-border 
settlements due to the automation of direct conversion of 
national currencies within the international digital system.
In each DFA transfer transaction, its type and description 
is indicated. The conducted transaction is processed on 
the basis of this information. Certain requirements may 
be imposed on transfers in digital systems, for example: 
maintaining records of the amount of transferred DFA 
sums, maintaining records of the number of conducted 
transactions, automatic calculation and transfer of tax 
payments (at the international level tax payments are not 
taken into consideration because they are registered and 
entered in the national digital systems), etc.

Smart Contracts
The innovative technology of digital systems provides an 
opportunity to enter into smart contracts. These allow for 
the automation of settlement operations and fulfillment 

5 Sandbox is an isolated information environment where a smart contract may get access to described data for reading. However, information and 
transactions stored in it are not transferred to the actual environment of the digital system.

of contracts, including those concluded with legal entities 
and governmental organisations [21]. In order to transfer 
DFAs on the basis of a smart contract it is necessary to in-
dicate the terms and type of the deal, transfer description, 
amount of tax burden etc.
A smart contract is an object with a unique address in the 
distributed register, and unique input and output parame-
ters. The contract processing description differs from a tra-
ditional agreement (as a rule, concluded in hard copy) by 
the fact that it is entered in the distributed register and has 
a certain algorithm of automated processing of its terms. 
It contains a hash of the previous entry in the distributed 
register and hashes of its parties. The following two basic 
requirements should be imposed on smart contracts: first, 
a strict typing of their parameters and results, and second, 
a strict format of the contract’s description. When a smart 
contract is fulfilled its parameters are processed automati-
cally, its value is distributed between the parties, and trans-
actions are entered in the distributed register of the digital 
system. It is advisable to add details of which mechanism 
has been tested to the system contract forms for frequent-
ly performed operations. The result should be explicitly 
guaranteed. In order to mitigate the risks of development 
of new smart contracts, sandboxes5 are necessary for mod-
elling and assessment of contracts results.
Apart from the sandbox mechanism, a smart contract 
designer may be used for making new contracts. It draws 
them up using standard components which makes them 
less flexible but allows to analyse the interaction between 
the standard components included in it. 

Transfer of Digital Financial Assets 
in the National Digital System
A transmitter and recipient of funds take part in trans-
ferring DFAs in the national digital system as well as 
financial organisations servicing them, where a DFA 
transmitter and recipient have bank accounts. Figure 3 
shows the diagram of funds transfer from Customer 1 
(C1) to Customer 2 (C2).

Cross-Border Transfer of DFAs on 
the basis of a Smart Contract in the 
International Digital System
In order to make cross-border transfers, e-wallets of the 
national and international digital system are used. There-
fore the EAEU IB takes an indirect part in settlement op-
erations, maintaining the operation of the digital system, 
estab";"""date"",""2021-02-14T10:49:51Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.6""
""xmp:CreatorTool"",""Adobe InDesign 16.1 (Windows)""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dcterms:created"",""2021-02-11T05:36:19Z""
""language"",""en""
""Last-Modified"",""2021-02-14T10:49:51Z""
""dcterms:modified"",""2021-02-14T10:49:51Z""
""dc:format"",""application/pdf; version=1.6""
""xmpMM:DocumentID"",""uuid:48d66e91-95e6-4583-8a07-368ca18d16a9""
""Last-Save-Date"",""2021-02-14T10:49:51Z""
""pdf:docinfo:creator_tool"",""Adobe InDesign 16.1 (Windows)""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2021-02-14T10:49:51Z""
""meta:save-date"",""2021-02-14T10:49:51Z""
""pdf:encrypted"",""false""
""xmp:CreateDate"",""2021-02-11T08:36:19Z""
""modified"",""2021-02-14T10:49:51Z""
""Content-Length"",""343981""
""pdf:hasMarkedContent"",""true""
""Content-Type"",""application/pdf""
""xmp:ModifyDate"",""2021-02-14T13:49:51Z""
""xmp:MetadataDate"",""2021-02-14T13:49:51Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""pdf:producer"",""Adobe PDF Library 15.0""
""meta:creation-date"",""2021-02-11T05:36:19Z""
""created"",""2021-02-11T05:36:19Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""13""
""Creation-Date"",""2021-02-11T05:36:19Z""
""resourceName"",""12671""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""1051"",""2325"",""6402"",""2113"",""5992"",""5663"",""2720"",""5534"",""1554"",""587"",""4386"",""4909"",""3652""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""producer"",""Adobe PDF Library 15.0""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""Adobe PDF Library 15.0""
""pdf:docinfo:created"",""2021-02-11T05:36:19Z""
";https://scholar.google.ch/scholar?start=700&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098861-322;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;[PDF][PDF] Laying the foundation for smart contract development: an integrated engineering process model;C Sillaber, B Waltl, H Treiblmaier… ; Information Systems and …, 2020  Springer;;"… had already perceived problems with existing testing approaches in a blockchain-based

environment … were explicitly mentioned with regards to the availabil- ity of testing data from oracles …

expression language Actors (eg, legal party, smart contract engineer, oracle, miner, legal …";Cité 4 fois;Les 4 versions;[PDF] springer.com;https://link.springer.com/content/pdf/10.1007/s10257-020-00465-5.pdf;;;https://scholar.google.ch/scholar?start=870&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098791-161;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;[PDF][PDF] CCA Secure Unidirectional PRE with Key Pair in the Standard Model without Pairings.;A Sbai, C Drocourt, G Dequen ; ICISSP, 2020  hal.archivesouvertes.fr;;"… Then we propose a new construction based on Cramer- Shoup crypto-system (Cramer and Shoup,

1998), that is CCA secure without pairings nor random oracle … Let A be an oracle TM representing

the adversary … The game consists in an execution of A with the following oracles …";Cité 1 fois;;[PDF] archives-ouvertes.fr;https://hal.archives-ouvertes.fr/hal-02773918/document;"
HAL Id: hal-02773918
https://hal.archives-ouvertes.fr/hal-02773918

Submitted on 10 Apr 2021

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L’archive ouverte pluridisciplinaire HAL, est
destinĂŠe au dĂŠpĂ´t et Ă  la diffusion de documents
scientifiques de niveau recherche, publiĂŠs ou non,
émanant des établissements d’enseignement et de
recherche français ou Êtrangers, des laboratoires
publics ou privĂŠs.

Distributed under a Creative Commons Attribution - NonCommercial - NoDerivatives| 4.0
International License

CCA Secure Unidirectional PRE with Key Pair in the
Standard Model without Pairings

Anass Sbai, C. Drocourt, Gilles Dequen

To cite this version:
Anass Sbai, C. Drocourt, Gilles Dequen. CCA Secure Unidirectional PRE with Key Pair in the
Standard Model without Pairings. 6th International Conference on Information Systems Security and
Privacy, Feb 2020, Valletta, Malta. pp.440-447, �10.5220/0008955704400447�. �hal-02773918�

https://hal.archives-ouvertes.fr/hal-02773918
http://creativecommons.org/licenses/by-nc-nd/4.0/
http://creativecommons.org/licenses/by-nc-nd/4.0/
http://creativecommons.org/licenses/by-nc-nd/4.0/
https://hal.archives-ouvertes.fr


CCA secure unidirectional PRE with key pair in the standard model
without pairings

Anass Sbai1, Cyril Drocourt 1 and Gilles Dequen 1

1 MIS Laboratory, University of Picardie Jules Verne
{anass.sbai, cyril.drocourt, dequen.gilles}@u-picardie.fr

Keywords: Proxy Re-Encryption, Unidirectional, Chosen Ciphertext Attack, Cramer-Shoup, Standard model.

Abstract: Secure Data sharing has become an ubiquitous need. One way of pursuing it is to use Proxy Re-Encryption
(PRE), which allows delegation of decryption rights selectively. This work tackles the problem of designing a
Proxy Re-Encryption that is unidirectional and CCA-secure in the standard model without pairings. In (Zhang
et al., 2013) they propose a solution that makes the Cramer-Shoup encryption scheme publicly verifiable and
use their result to construct a CCA secure PRE in the standard model. However, we show that their scheme is
vulnerable against adaptive chosen ciphertexts attacks. Then we propose a new construction based on Cramer-
Shoup crypto-system (Cramer and Shoup, 1998), that is CCA secure without pairings nor random oracle.

1 INTRODUCTION

Proxy Re-Encryption (PRE) is a very useful tool
that transforms ciphers intended for Alice into new ci-
phers that can be decrypted by Bob. Thus, it allows
the delegation of the decryption rights on Alice’s data,
only for the intended recipients (we will also refer to
Alice as the delegator and Bob as the delegate). The
first scheme was proposed by Blaze, Bleumer, and
Strauss (Blaze et al., 1998) whose goal was to avoid
that the data must be recovered, decrypted then en-
crypted with the delegate’s key. And thus, relying on
a semi-trusted proxy that converts the ciphers using
re-encryption keys created by the delegator. The ma-
jor disadvantage of their scheme is that Alice’s dele-
gation to Bob automatically allowed Bob’s delegation
to Alice, what will later be called bidirectional PRE.
This property is due to the fact that re-encryption keys
were created using the private keys of the two actors.

In terms of security, such as PKE (Public Key En-
cryption), we can assess the secrecy of the schemes
on three levels:
• IND-CPA (indistinguishability under chosen

plaintexts attacks) , where we give the attacker
access to an encryption oracle. He has the pos-
sibility to query plaintexts of his choice and get
the corresponding ciphertexts. Then comes the
challenge where he generates two messages with
the same length and sends it to the challenger
who will then chose randomly to encrypt one of
them. The scheme is broken if the adversary is

able to guess which of the two messages has been
encrypted with a non-negligible probability.

• IND-CCA-1 (indistinguishability under chosen
ciphertexts attack), here the attacker has access
to an encryption and a decryption oracle. He can
send decryption queries as much as he can before
the challenge. The later remains the same as in
IND-CPA game and the scheme is broken if the
adversary guesses which of the two messages has
been encrypted with a non-negligible probability.

• IND-CCA-2 (indistinguishability under adaptive
chosen ciphertexts attack), the game runs the
same as in the IND-CCA-1, but in addition the
attacker can send decryption queries to the ora-
cle after the challenge except for the challenge ci-
phertext.

The main difference in the indistinguishability
game between PKE and PRE is that the adversary
has access to a re-encryption oracle, thus the proxy
should not learn any information about the message
during the re-encryption process. We give a more for-
mal definition in section 5. For the rest of this paper,
a CCA secure scheme will stand for the IND-CCA-2
security notion.

The construction of the BBS (Blaze et al., 1998)
PRE achieves CPA security. In (Ateniese et al.,
2006) the authors formalizes the properties and se-
curity requirements of PRE that we define in section
2 and propose the first unidirectional scheme. Since
then, several works have been published concerning



PRE. The first functional system of an Identity-based
Proxy Re-Encryption (IB-PRE) using pairing that is
CPA secure was proposed in (Green and Ateniese,
2007). (Canetti and Hohenberger, 2007) proposes the
first bidirectional CCA secure PRE scheme where he
proves the security of his scheme using the UC frame-
work (Universal Composability framework (Canetti,
2001)). In (Deng et al., 2008), the authors deal with
the open problem presented by Canetti concerning
the construction of a CCA secure PRE without pair-
ing. (Ateniese et al., 2009) formalizes the notion of
key privacy which means that using the re-encryption
key we cannot recover the identity of both the del-
egate and the delegator. He shows why the previ-
ous systems were not key-private and proposes a new
re-encryption system considered as the first unidirec-
tional PRE that is key private. Their construction
is single-use CPA secure. (Chow et al., 2010) has
demonstrated the possibility of conducting a CCA at-
tack on the Shao’s system (Shao and Cao, 2009) and
shows how to fix the issue. They proposed their own
scheme without using pairing and relying only on El-
Gamal and the Schnorr signature. (Selvi et al., 2017)
find a flaw in the security proof of Chow’s construc-
tion and propose to fix it. The system is unidirectional
CCA secure in the random oracle model and was im-
plemented in (Sbai et al., 2019).

The security proofs in this model are founded on
the existence of an ideal hash function that guarantees
uniformly-random outputs which in practice, cannot
be instantiated. And there is no proof that a ran-
dom oracle can exist. Nevertheless, many schemes
base their security proofs on random oracle and are
used in practice e.g RSA-OAEP. Thus, without show-
ing any vulnerability so far. But still, it is recom-
mended to have a scheme which is proved secure un-
der standard cryptographic assumptions e.g discrete
logarithm problem or other. This does not mean that
we cannot use hash function, as long as the proofs
rely on the assumption of collision resistance or sec-
ond preimage and not as ideal hash function. Un-
til now, the only unidirectional PRE scheme that has
been claimed to be CCA secure without relying on
pairing nor random oracles is (Zhang et al., 2013).
Where the authors propose a PVPKE (Public Verifi-
able Public Key Encryption) and use their result to
construct a PRE scheme.

In this paper, we first evince that the proposal of
(Zhang et al., 2013) is not CCA-secure. Then, we
deal with the open problem of constructing a PRE
scheme with CCA-security in the standard model
without relying on pairing, based only on a DVPKE
(Designated Verifier Public Key Encryption) which
is Cramer Shoup cryptosystem. And thus, by giv-

ing the proxy a private and public key pair, that al-
lows him to check the validity of ciphertexts. Unlike
(Wei et al., 2010) we do not need to include a new
signature scheme and new key pairs. In this case, it
amounts to the same problem where all efficient sig-
nature schemes relies on random oracle or pairing.
Our method shows that the property of designated
verifier in the Cramer Shoup encryption is sufficient
to construct a CCA secure PRE, by setting the proxy
as peer. We show later in the paper its benefits and in-
conveniences. We explain our construction and prove
its CCA-security. This work was inspired by (Chow
et al., 2010) and (Wang et al., 2009) cryptosystems.

2 PRELIMINARIES

2.1 PRE definition

Usually a PRE scheme can be defined as a tuple Îś :
{Setup,KGen,RkGen,Encrypt,ReEncrypt,Decrypt}
where :
• Setup(1λ) : takes as input a security parameter

Îť and generates the scheme parameters denoted
params.

• KGen(params) : take as input the scheme pa-
rameters and generate the pair public/private key
(Pk,Sk).

• RkGen(Ska,Pkb) : in the case of unidirectional
PRE, it takes as input a’s private key denoted as
Ska and b’s public key Pkb to generate the re-
encryption key Rka→b.

• Encrypt(m,Pka) = Ca : is the encryption func-
tion.

• ReEncrypt(Ca,Rka→b) =Cb : is the re-encryption
function.This can be either deterministic or prob-
abilistic.

• Decrypt(C,Sk) = M : is the decryption function.
In some cases, we can find two more functions used
for encryption and decryption in which the cipher
cannot be re-encrypted that we call non-transformable
ciphertexts, so that only the owner of the private
key can decrypt. There are also schemes like (Wei
et al., 2010) and (Purushothama et al., 2013) that uses
key pairs for the proxy. The definition remains the
same, but some properties can be missed especially
the transparency. In (Ateniese et al., 2006) Ateniese
gives a more formal definition for PRE and defines
concretely the properties such that :
• Unidirectional: Delegation of decryption rights

from Alice to Bob does not allow Alice to decrypt
Bob’s cipher.



• Non-interactive: The re-encryption key can be
generated by Alice without interacting with Bob,
and thus using only Bob’s public key.

• Transparent: Or invisible, meaning that the del-
egate cannot distinguish between an encrypted
message and a re-encrypted message.

• Key-optimal: The size of Bob’s secret storage
must remain unchanged, no matter how many del-
egations he accepts.

• Original access: The sender can decrypt any re-
encrypted message of which he was originally the
owner.

• Collusion-safe: If the proxy and Bob collude, they
should not get Alice’s secret key.

• Non-transitive: The proxy cannot re-delegate re-
encryption rights. (e.g from Rka→b and Rkb→c the
proxy cannot calculate Rka→c)

• Non-transferable: The proxy and delegates can-
not redefine decryption rights. (e.g from Rka→b
and Pkc and Skb we cannot calculate Rka→c)

• Temporary: Bob can decipher the messages re-
ceived from Alice only at a certain point in time.

2.2 Cramer-Shoup encryption scheme
(Cramer and Shoup, 1998)

It is the first efficient asymmetric encryption scheme
that fulfills CCA security in the standard model. This
under the assumption that we have a universal one-
way hash function, and the Decisional Diffie-Hellman
Problem is hard in the underlying group. Assume we
have a group G with large prime order q, the plain-
texts are elements of G and the key generation process

as follow : Choose g1, g2 from G and xi
$←− Zq , i ∈

{1,2, ..,5} then compute c = gx1
1 ×gx2

2 , d = gx3
1 ×gx4

2 ,
h = gx5

1 . Next choose a hash function H from the fam-
ily of universal one-way hash functions. Set the pri-
vate key as Sk = (x1,x2,x3,x4,x5) and the public key
Pk = (q,g1,g2,H,c,d,h). To encrypt a message the

sender must choose r $←− Zq and compute u1 = gr
1 ,

u2 = gr
2 , e = m×hr, α = H(u1,u2,e), v = cr×dr×α.

The ciphertext is (u1,u2,e,v), to be decrypted the first
step is to verify the validity of the ciphertext by com-
puting v = ux1+α×x3

1 × ux2+α×x4
2 . If this equality does

not hold reject the decryption request else compute
and return m = e

u
x5
1

.

3 Analysis of PVPKE by (Zhang
et al., 2013)

The trick that helps to create a CCA secure PRE
is the public verifiability of ciphertexts. the first step
for the proxy will be to check the validity of the ci-
phertext before its re-encryption. As an example,
(Chow et al., 2010) relies on schnorr signature with a
slight modification to get the public verifiability. This
makes also ElGamal encryption CCA secure. The
schnorr signature used is a sort of NIZK (Non Inter-
active Zero-Knowledge) proof obtained from the Fiat
and Shamir transformation on the interactive schnorr
identification scheme. This transformation leads to
the use of random oracle in the security model.

As for (Zhang et al., 2013), their scheme is based
on Cramer-Shoup encryption. In order to make it pub-
licly verifiable, the authors opted for the use of com-
posite order groups. Thus, based on the problem of
factorization of large prime numbers, they can com-
pute using some elements of the private key a val-
ues in Zφ(N) that can be used for verification by rais-
ing it in exponent in ZN while keeping φ(N) hidden.
The scheme is CPA secure but not CCA as they had
claimed. We review the scheme due to (Zhang et al.,
2013), and show how to achieve an adaptive chosen
ciphertext attack below.

3.1 Review of the scheme

• KGen() :

– Let p, q , p′ and q′ be big primes such that p =
2× p′+1,q = 2×q′+1 and N = p×q

– Choose g1, g2 from ZN such that gφ(N)
i ≡ 1 mod

N (i = 1, 2)

– Choose b $←− Zφ(N) and xi
$←− Zφ(N) (i = 1, 2, 3,

4, 5)
– Choose a hash function H : {0,1}∗→ ZN .
– Compute x′i ≡ b× xi mod φ(N) (i = 1, 2, 3, 4).
– Compute c = gx1

1 ×gx2
2 , d = gx3

1 ×gx4
2 , h = gx5

1
– Return Sk = (p′,q′,x1,x2,x3,x4,x5) and Pk =
(N,g1,g2,H,b,x′1,x

′
2,x
′
3,x
′
4,c,d,h)

• Encrypt(Pk,m) :

– Choose r $←− ZN
– Compute u1 = gr

1 , u2 = gr
2 .

– Compute e = m× hr mod N, α = H(u1,u2,e),
v = cr×dr×α mod N

– Return C = (u1,u2,e,v)

• Decrypt(Sk,C) :



– Compute α = H(u1,u2,e) and test if vb =

u
x′1+α×x′3
1 ×u

x′2+α×x′4
2 mod N

– If the condition does not hold return ”reject”
else return m = e

u
x5
1

3.2 Weakness in the PVPKE scheme of
(Zhang et al., 2013)

In this section we demonstrate that their PVPKE is
not CCA2-secure. This imples that its use to design
the PRE is also not secure. We can easily prove it
based on IND-CCA2 game .

Recall that the game can be seen as two phases,
the first one gives the attacker access to a fixed public
key and to decryption oracles. The adversary can sub-
mit a large amount of decryption queries without any
restriction. Then it comes the challenge which con-
cerns the distinction between two ciphers created by
the challenger. Those ciphers correspond to two mes-
sages chosen by the attacker and encrypted under the
same public key, e.g the attacker sends m0 & m1 and
receives : C∗= (u1,u2,e,v) which is the encryption of

mi with i $←−{0,1} . In the second phase the adversary
can submit decryption queries to the oracle except for
the challenge C∗ = (u1,u2,e,v).

The attack consists of computing an invalid but
uniformly distributed ciphertext C′ such that C′ 6=
C∗ and still the decryption oracle will not reject
the request as the verification will pass. The in-
valid ciphertext could be constructed this way C′ =

(ub
1,u

b
2,e

b,v′ = u
(x′1+x′3×α)
1 × u

(x′2+x′4×α)
2 ). The de-

cryption oracle will verify the signature : v′b =

u
′(x′1+x′3×α)
1 ×u

′(x′2+x′4×α)
2 = (u

(x′1+x′3×α)
1 ×u

(x′2+x′4×α)
2 )b

which is valid . Thus the decryption will return

m′ = e′/u′x5
1 = mb× hr×b/g

x′5×r
1 = mb. Now the at-

tacker has only to test if mb
0 = mb or mb

1 = mb and win
the challenge.

The other schemes proposed in (Zhang et al.,
2013), could also be broken by the same attack.

4 Our construction based on the
Cramer-Shoup scheme

As we have demonstrated in the latter section, the
public verifiability for the Cramer-Shoup in (Zhang
et al., 2013) scheme is not secure. In order to deflect
this issue, (Wei et al., 2010) they consider the delega-
tor, the proxy and the delegate as peers, having their
own encryption public/private keys and sign/verify
keys. Thus the proxy cannot modify the challenge

ciphertext and other outside adversaries cannot mod-
ify the original and the re-encrypted ciphertext. Nev-
ertheless their system is not fully CCA secure, since
no verification is made on the validity of the cipher-
texts by the proxy. The idea of using key pairs at the
proxy level seemed interesting to us. For our case
we use encryption public/private keys which permit
the proxy to verify the validity of original ciphertexts
and for the delegate to test the validity of re-encrypted
ciphertexts. It can be seen as constraining in terms
of flexibility and transparency, but is rather advanta-
geous in the sense that we can easily detect malicious
proxies with their public keys. In addition to check-
ing the validity of the ciphertexts and re-encrypted
ciphertexts, we can also check the well-formness of
the re-encryption keys which decreases the damage
of DDos attacks. The scheme is proved CCA-secure
under DDH assumption in the next section.

4.1 The proposed scheme :

• Setup(1λ) :

– Let G be a group of prime order q, such that
the bit-length of q is the security parameter Îť.
Choose random elements g1,g2 ∈ G and two
universal one way hash function H1 : {0,1}∗→
Zq and H2 : G2 → Z∗q. The parameters are
params : (G,q,g1,g2,H1,H2)

• KGen(params) :

– Let us denote (Ska,Pka) the couple of pri-
vate/public key associated to the user ’a’. Pick

Ska = (xi : i ∈ {1,2, ...,7}) where xi
$←− Zq and

set Pka = (c,d,h1,h2) such that c = gx1
1 × gx2

2 ,
d = gx3

1 ×gx4
2 ,h1 = gx5+H1(c,d)×x6

1 , h2 = gx7
1

• Encrypt(m,Pka) :

– For non-transformable ciphertexts :

Choose r $←− Zq

Compute u1 = gr
1, u2 = gr

2
Compute e = hr

a2×m, α = H2(u1,u2,e)
Compute v = cr

a×dr×α
a

Output Ca = (u1,u2,e,v)
– For transformable ciphertext : add the proxy

public key Pkp as input :

Choose r $←− Zq

Compute u1 = gr
1, u2 = gr

2
Compute e = hr

a1×m, α1 = H2(u1,u2,e)
Compute v = cr

a×dr×α1
a , Îą2 = H2(Îą1,v)

Compute vp = cr
p×dr×α2

p

Output Ca = (u1,u2,e,v,vp)



• RkGen(Ska,Pkb,Pkp) :

– On input user a’s private key Ska and user b’s
public key Pkb and the proxy public key Pkp :

Choose j $←− Zq , k $←− Zq

Compute rk =
xa5+H1(c,d)×xa6

k

Compute u′1 = g j
1, u′2 = g j

2

Compute e′ = h j
b1× k, α′1 = H2(u′1,u

′
2,e
′)

Compute v′ = c j
b × d

j×α′1
b , α′2 = H2(α

′
1,v
′) ,

v′p = c j
p×d

j×α′2
p

Return Rka→b = (rk,u′1,u
′
2,e
′,v′,v′p)

• ReEncrypt(Rka→b,Ca,Pkp,Skp) :

– On input a re-encryption key, a transformable
ciphertext and the proxy public/private key
pair:

Test if vp = u
(xp1+xp3×α2)

1 × u
(xp2+xp4×α2)

2 &

v′p = u
′(xp1+xp3×α′2)
1 ×u

′(xp2+xp4×α′2)
2

Choose ω
$←− Zq

Compute β = urk
1 , u′′1 = gω

1 , u′′2 = gω
2

Compute e′′ = e, α′′ = H2(u′′1 ,u
′′
2 ,e
′′,β)

Compute v′′ = cω

b ×dω×α′′
b

Output Cb = (β,u′1,u
′
2,e
′,v′,u′′1 ,u

′′
2 ,e
′′,v′′)

• Decrypt(skb,Cb) :

– If Cb = (u1,u2,e,v)

Test if v = u
(xb1+xb3×α)

1 ×u
(xb2+xb4×α)

2
Compute m = e

u
xb7
1

– If Cb = (u1,u2,e,v,vp)

Test if v = u
(xb1+xb3×α1)

1 ×u
(xb2+xb4×α1)

2
Compute m = e

u
(xb5

+H1(c,d)×xb6
)

1

– If Cb = (β,u′1,u
′
2,e
′,v′,u′′1 ,u

′′
2 ,e
′′,v′′)

Test if v′′ = u
′′(xb1+xb3×α′′)
1 × u

′′(xb2+xb4×α′′)
2 &

v′ = u
′(xb1+xb3×α′)
1 ×u

′(xb2+xb4×α′)
2

Compute k = e′

u
′(xb5

+H1(c,d)×xb6
)

1

Compute m = e′′
βk

4.2 Correctness and security analysis :

• The correctness of decryption for original cipher-
text (transformable or non transformable) is trivial
since it is the same as in Cramer-Shoup. Correct-
ness of decryption for re-encrypted ciphertexts
can be viewed as follow :

m = e′′
βk = e′′

urk×k
1

=
m×g

r×(x5+H1(c,d)×x6)
1

g
r×(x5+H1(c,d)×x6)

k ×k
1

• Intuitively, we can check the IND-CCA security
of our scheme as follow :
– For original non-transformable ciphertexts,

they’re a Cramer-Shoup ciphers which is
proved in (Cramer and Shoup, 1998) as CCA-
secure under DDH assumption and second
preimage.

– With original transformable ciphers, encryption
is almost the same as Cramer-Shoup. However,
we compute a vp so that the proxy could ver-
ify the validity of the ciphertext. In the IND
CCA-2 game we give the challenger access to
both secret keys of the proxy and the delegator
so that he can verify the validity of vp. Oth-
erwise, it does not effect on the security of the
scheme since the vp is computed with another
public key, thus it will be linearly independent
of v even if we use the same random coin.

– Re-encryption keys generation was inspired by
the work of (Chow et al., 2010), where even if k
is leaked which was chosen randomly to com-
pute rk = x5+H1(c,d)×x6

k , eg. as the proxy and the
delegate collude, only x5 +H1(c,d)× x6 could
be computed. This linear combination prevents
from finding x5 and x6 due to the fact that there
are as many possible solutions as the cardinal
of the group G to which xi belong. And thus
no information on the private keys is revealed
which make the scheme collusion resistant.

– Re-encrypted ciphertexts are two different
Cramer-Shoup ciphers, the first one is used to
decrypt the substitution key k created by the
delegator which is primordial for the decryp-
tion of the second cipher as we saw before in
the correctness.

5 Proof of security

We first give the definition of unidirectional
single-hop PRE-CCA game following the model of
(Canetti and Hohenberger, 2007). We take into ac-
count the changes proposed by the authors for uni-
directional schemes, since the formal model was in-
tended to bidirectional PRE. We have made changes
related to the addition of proxy key pairs :

Let Îť be a security parameter. Let A be an oracle
T M representing the adversary. The game consists in
an execution of A with the following oracles. They
can be invoked several times in any order, subject to
the constraints below:



OKGen : For uncorrupted users return Pk ,
where (Pk,Sk)← KGen(params). For corrupted
users return Pk and Sk , where (Pk,Sk) ←
KGen(params)

ORkGen : On input Pka , Pkb and Pkp, the
re-encryption key generation algorithm outputs
Rka→b. We reject the query if it’s a re-encryption
key generation between a corrupted and uncor-
rupted key.

OEncryption : For non transformable cipher-
text, on input a message m, the output is C =
(u1,u2,e,v). For original transformable cipher-
text, output C = (u1,u2,e,v,vp).

OChallenge : This oracle can be queried only
once. On input, (Pk∗,m0,m1). where Pk∗ is
called the challenge key, the oracle chooses a bit

b $←− {0,1} and returns the challenge ciphertext
C = Enc(Pk,mb). (As we note later, the challenge
key must be uncorrupted for A to win).

OReEncryption : On input (Pka,Pkb,Ca), if Pkb
is corrupted or a = b returns ⊥. Otherwise it re-
turns Cb

ODecryption : On input (Pk,C), if Pk was
not generated before returns ⊥. Else returns
Decrypt(C,Sk)

ODecision : This oracle can also be queried only
once. On input b′ : If b′ = b and the challenge key
pk∗ is not corrupted , then outputs 1 else outputs
0.

We say that A wins the PRE-CCA game with ad-
vantage Îľ, if the probability over the random choices
of A and the oracles, that the decision oracle is in-
voked and outputs 1, is at least 1/2+ Îľ

Theorem 1. Our scheme is secure against adaptive
chosen ciphertexts attack assuming that (1) the hash
functions H1,H2 are chosen from a universal one-way
family, and (2) the Diffie-Hellman decision problem is
hard in the group G .

We give our scheme’s formal proof based on
(Wang et al., 2009) and (Chow et al., 2010) proofs
as follows :

Assume the external adversarie’s algorithm B
breaking the IND-CCA2 property of the scheme ,we
use B to construct algorithm A distinguish a four
tuple (g1,g2,u1,u2) from G is a DDH tuple or not.
Oralce queries from B are handled by A as follow-
ing:

• Query to OKGen : If user A is corrupted ,

A randomly chooses Ska = (xai)
$←− Zq for (i =

1,2, ...,7), computes Pka = (g1,g2,ca = g
xa1
1 ×

g
xa2
2 ,da = g

xa3
1 ×g

xa4
2 ,ha1 = g

xa5+H1(c,d)×xa6
1 ,ha2 =

g
xa7
1 ) returns Ska,Pka which is an identical distri-

bution to the real distribution of real private and
public key. For uncorrupted user B, randomly

chooses Skb =(xbi)
$←−Zq for (i= 1,2, ...,9), com-

putes Pkb = (g1,g2,cb = g
xb1
1 × g

xb2
2 ,db = g

xb3
1 ×

g
xb4
2 ,hb1 = g

xb5+H1(c,d)×xb6
1 × g

xb8
2 ,ha2 = g

xa7
1 ×

g
xb9
2 ) and returns Pkb. Assuming that g2 = gw

1 the
output has an identical distribution to the real dis-
tribution of real public key. Which gives us a per-
fect simulation.

• Query to ORkGen : On input Pka,Pkb and
Pkp if one of A and B is corrupted we re-

ject the query. Else A outputs Rka→b = (rk $←−
Zφ(N)),Ca1 ,v

′
p) which is indistinguishable with

Rki→ j = ( (x5+H1(c,d)×x6)
k ,Ci1 ,v

′
p)

• Query to OEncryption : For a non transformable
encryption, given a message m, the encryption al-
gorithm returns C = (u1,u2,e,v) = (gr

1,g
r
2,u

x7
1 ×

ux9
2 × m,cr × dr×α) where r $←− Zq. This is a

perfect simulation as in Cramer-Shoup encryp-
tion scheme. For an original transformable en-
cryption, if the users are uncorrupted the en-
cryption algorithm returns C = (u1,u2,e,v,vp) =

(gr
1,g

r
2,u

(x5+H1(c,d)×x6)
1 ×ux8

2 ×m,cr×dr×α1 ,c′r×
d′r×α1) where r $←− Zq and vp is computed with
a random public key. Else, it output ⊥. This is
also a perfect simulation. We will show below
one cannot construct a valid tuple (u1,u2,e,v,vp)
by itself with (g1,g2,u1,u2) being not a DDH tu-
ple, relying on the same method used in Cramer-
Shoup Encryption.

• Query to OReEncryption : On input
Pka,Pkb,Ca = (u1,u2,e,v,vp) from user i
to user j, search in the RkGen list an item
including i and j. If it does not exist run
the querying to ORkGen. Then the proxy
verifies ciphertext’s validity by testing, if
vp 6= u

xp1
1 × u

xp2
2 × u

xp3×α2
1 × u

xp4×α2
1 return ⊥.

Else, return C j = (β,u′1,u
′
2,e
′,v′,u′′1 ,u

′′
2 ,e
′′,v′′) =

(u(x5+H1(c,d)×x6)
1 ,u′1,u

′
2,e
′,v′,u′′1 ,u

′′
2 ,e
′′,v′′)

which include two Cramer-Shoup ciphers
and have the same distribution as for
(urk

1 ,u′1,u
′
2,e
′,v′,u′′1 ,u

′′
2 ,e
′′,v′′). Thus the real

output and simulated output are indistinguish-
able. So this is also a perfect simulation.

• Query to ODecryption : In the real de-
cryption, given a re-encrypted ciphertext C =
(β,u′1,u

′
2,e
′,v′,u′′1 ,u

′′
2 ,e
′′,v′′) , the decryption al-



gorithm runs as follows. It first computes α′′1 =

H2(u′′1 ,u
′′
2 ,e
′′,β), and tests if v′′ = u

′′(x1+x3×α′′1)
1 ×

u
′′(x2+x4×α′′1)
2 & v′ = u

′(x1+x3×α′1)
1 ×u

′(x2+x4×α′1)
2 . If

this condition does not hold, the decryption al-
gorithm outputs ⊥, otherwise, it computes k =

e′

u
′(x5+H1(c,d)×x6)
1

and outputs m = e′′
βk . In our simula-

tion, on input C j from user i to j , B first verifies
ciphertexts’s validity. If it’s invalid ciphertexts
return ⊥,else computes k = e′

u
′(x j5

+H1(c,d)×x j6
)

1 ×u
′x j8
2

then outputs m = e′′
βk = e′′

u
1/(x j5

+H1(c,d)×x j6
)

1

As in Cramer-Shoup encryption, if (g1,g2,u1,u2)
is a DDH tuple, our simulated decryption is a
perfect decryption. For original ciphertexts the
same proof holds as for Cramer-Shoup encryp-
tion, there is a slightly difference in the proof for
original transformable ciphertexts which we will
explain below. And the simulated decryption is
also a perfect decryption.

Lemma 2. If (g1,g2,u1,u2) is not a DDH tuple, the
ODecryption will reject all invalid ciphertexts, except
with negligible probability.

The proof of this lemma is the same as (Cramer
and Shoup, 1998), the only difference is that in
ODecryption simulation for transformable cipher-
texts, the adversary must solve these equations :

x1 +w× x2 = logg1c mod q
x3 +w× x4 = logg1d mod q
x′p1

+w× x′p2
= logg1cp mod q

x′p3
+w× x′p4

= logg1dp mod q
r1x1 + r2Îą1x3 + r1wx2 + r2Îą1wx4 = logg1v mod q
r1xp1 + r2Îą2xp3 + r1wxp2 + r2Îą2wxp4 = logg1vp

mod q
Which are linearly independent, thus our simulation
is perfect for the external adversary. Unless the proxy
reveals his private key. If A can break our re-
encryption scheme, B can solve the DDH problem
in G. Thus we prove our theorem.

6 Conclusion

In this paper, we point out that the schemes
in (Zhang et al., 2013) are not CCA-secure , we
show how an adversary could distinguish between
two ciphers in the IND-CCA2 game. Also, we
present a construction of unidirectional proxy re-
encryption scheme without bilinear pairing in the
standard model. Our scheme is proven CCA-secure in
the standard model under decisional Diffie-Hellman
assumption and second preimage resistance of the

chosen universal one way hash family. We do not con-
sider efficiency, but rather and above all to come up
with a solution for one of the two open problems left
by (Deng et al., 2008). As a perspective, we will im-
plement the proposed algorithm in order to compare
it with other related works, and try to design more ef-
ficient schemes.

ACKNOWLEDGEMENTS

We would like to thank Damien Vergnaud for the
valuable discussions and for his constructive com-
ments about the flaw, which leads us to find the con-
crete attack in (Zhang et al., 2013) . This work is
supported by ADEME on the VertPom project.

REFERENCES

Ateniese, G., Benson, K., and Hohenberger, S. (2009). Key-
private proxy re-encryption. In Cryptographers’ Track
at the RSA Conference, pages 279–294. Springer.

Ateniese, G., Fu, K., Green, M., and Hohenberger, S.
(2006). Improved proxy re-encryption schemes with
applications to secure distributed storage. ACM Trans-
actions on Information and System Security (TISSEC),
9(1):1–30.

Blaze, M., Bleumer, G., and Strauss, M. (1998). Divertible
protocols and atomic proxy cryptography. In Interna-
tional Conference on the Theory and Applications of
Cryptographic Techniques, pages 127–144. Springer.

Canetti, R. (2001). Universally composable security: A new
paradigm for cryptographic protocols. In Proceedings
42nd IEEE Symposium on Foundations of Computer
Science, pages 136–145. IEEE.

Canetti, R. and Hohenberger, S. (2007). Chosen-ciphertext
secure proxy re-encryption. In Proceedings of the 14th
ACM conference on Computer and communications
security, pages 185–194. ACM.

Chow, S. S., Weng, J., Yang, Y., and Deng, R. H. (2010).
Efficient unidirectional proxy re-encryption. In Inter-
national Conference on Cryptology in Africa, pages
316–332. Springer.

Cramer, R. and Shoup, V. (1998). A practical public key
cryptosystem provably secure against adaptive chosen
ciphertext attack. In Annual International Cryptology
Conference, pages 13–25. Springer.

Deng, R. H., Weng, J., Liu, S., and Chen, K. (2008).
Chosen-ciphertext secure proxy re-encryption without
pairings. In International Conference on Cryptology
and Network Security, pages 1–17. Springer.

Green, M. and Ateniese, G. (2007). Identity-based proxy
re-encryption. In International Conference on Applied
Cryptography and Network Security, pages 288–306.
Springer.



Purushothama, B., Shrinath, B., and Amberker, B. (2013).
Secure cloud storage service and limited proxy re-
encryption for enforcing access control in public
cloud. International Journal of Information and Com-
munication Technology, 5(2):167–186.

Sbai, A., Drocourt, C., and Dequen, G. (2019). Pre as a
service within smart grid cities. In 16th International
Conference on Security and Cryptography.

Selvi, S. S. D., Paul, A., and Pandurangan, C. (2017).
A provably-secure u";"""date"",""2020-01-02T15:23:36Z""
""pdf:PDFVersion"",""1.4""
""pdf:docinfo:title"",""CCA Secure Unidirectional PRE with Key Pair in the Standard Model without Pairings""
""xmp:CreatorTool"",""HAL""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""Computer Science [cs]/Cryptography and Security [cs.CR]""
""language"",""en""
""dc:format"",""application/pdf; version=1.4""
""pdf:docinfo:creator_tool"",""HAL""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""CCA Secure Unidirectional PRE with Key Pair in the Standard Model without Pairings""
""modified"",""2020-01-02T15:23:36Z""
""cp:subject"",""Computer Science [cs]/Cryptography and Security [cs.CR]""
""pdf:docinfo:subject"",""Computer Science [cs]/Cryptography and Security [cs.CR]""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""Anass Sbai, C. Drocourt, Gilles Dequen""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.19 (TeX Live 2018) kpathsea version 6.3.0""
""meta:author"",""Anass Sbai, C. Drocourt, Gilles Dequen""
""trapped"",""False""
""meta:creation-date"",""2021-04-14T19:16:38Z""
""created"",""2021-04-14T19:16:38Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2021-04-14T19:16:38Z""
""resourceName"",""document""
""Author"",""Anass Sbai, C. Drocourt, Gilles Dequen""
""producer"",""PDFLaTeX""
""pdf:docinfo:producer"",""PDFLaTeX""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""11"",""28"",""89"",""55"",""38"",""0""
""Keywords"",""Proxy Re-Encryption, Unidirectional, Chosen Ciphertext Attack, Cramer-Shoup, Standard Model., Standard model""
""access_permission:modify_annotations"",""true""
""dc:creator"",""Anass Sbai, C. Drocourt, Gilles Dequen""
""dcterms:created"",""2021-04-14T19:16:38Z""
""Last-Modified"",""2020-01-02T15:23:36Z""
""dcterms:modified"",""2020-01-02T15:23:36Z""
""title"",""CCA Secure Unidirectional PRE with Key Pair in the Standard Model without Pairings""
""Last-Save-Date"",""2020-01-02T15:23:36Z""
""pdf:docinfo:keywords"",""Proxy Re-Encryption, Unidirectional, Chosen Ciphertext Attack, Cramer-Shoup, Standard Model., Standard model""
""pdf:docinfo:modified"",""2020-01-02T15:23:36Z""
""meta:save-date"",""2020-01-02T15:23:36Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.19 (TeX Live 2018) kpathsea version 6.3.0""
""Content-Length"",""324282""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Anass Sbai, C. Drocourt, Gilles Dequen""
""dc:subject"",""Proxy Re-Encryption, Unidirectional, Chosen Ciphertext Attack, Cramer-Shoup, Standard Model., Standard model""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""9""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""1007"",""3351"",""3994"",""3206"",""3358"",""2985"",""3578"",""3765"",""1157""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""Proxy Re-Encryption, Unidirectional, Chosen Ciphertext Attack, Cramer-Shoup, Standard Model., Standard model""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2021-04-14T19:16:38Z""
";https://scholar.google.ch/scholar?start=710&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098826-241;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;DApp for Rating;A Buterchi, A Arusoaie ; arXiv preprint arXiv:2009.03253, 2020  arxiv.org;;"… In this way, the one cannot find the credentials by simply inspecting the blockchain … chain request

involved also the usage of custom cryptocurrencies (eg, LINK for Chainlink oracle) … The ones

that use external providers (oracles) like Provable or Chainlink have an unacceptable …";Autres articles;;[PDF] arxiv.org;https://arxiv.org/pdf/2009.03253;"
DApp for Rating

Andreea But,erchi1, Andrei Arusoaie1

Alexandru Ioan Cuza, University of Iaşi,
andreea.buterchi,arusoaie.andrei@info.uaic.ro

Abstract. Lots of existing web applications include a component for
rating internet resources (e.g., social media platforms include mecha-
nisms for rating videos or posts). Based on the obtained rating, the most
popular internet resources can generate large amounts of money from
advertising. One issue here is that the existing rating systems resources
are entirely controlled by a single entity (e.g., social media platforms).
In this paper we present a blockchain-based decentralized application for
rating internet resources. The proposed solution provides a transparent
rating mechanism, since no central authority is involved and the rating
operations are handled by a specialised smart contract. We provide an
implementation of our idea, where we combine existing authentication
methods with blockchain specific features so that anonymity is preserved.
We show that this approach is better than existing rating components
present in various web applications.

1 Introduction

These days, blockchain-based decentralized applications are designed for a vari-
ety of use cases. The society embraced the innovation of the blockchain technol-
ogy and transformed its potential into ingenious software products. Since one of
the main purposes of the blockchain technology is to remove the interaction with
a central authority or a third party which has control over specific information,
the potential of the blockchain was widely acknowledged and it was adopted in
various domains: finance, government, digital identity, media and entertainment,
healthcare and supply chain management.

Rating systems are widely used by many social media platforms to establish
specific trends or trending posts, videos, movies, and so on. There are various
rating systems, which have different purposes with respect to the rated resources:
like/dislike-based rating systems, star-based rating systems and review-based rat-
ing systems, which are used for media contents and products evaluation.

Most of the existing rating systems are used for advertisement, which can
provide the one who controls a specific resource with substantial incomes. An
interesting fact is that most of the media platforms control directly the rat-
ing systems they are using. Even if the politics of media platforms seem to be
transparent, there is still no evidence for this transparency. The users on these
platforms have to trust the rating process, without any certain proof that it is
indeed transparent.

ar
X

iv
:2

00
9.

03
25

3v
1 

 [
cs

.C
R

] 
 2

1 
A

ug
 2

02
0



2 Buţerchi et. al.

To our best knowledge, at this moment there is no solution that has the
purpose of moving rating systems into the blockchain. However, we can associate
rating with voting, which is a concept widely discussed [2,9,1,8,10]. In this case,
the blockchain technology is used to distribute an open voting record among
citizens, such that the citizens do not need anymore to put their trust into
central authorities.

Considering the similarity between decentralized voting and decentralized rat-
ing, we can admit that a blockchain-based decentralized application for rating
could have a major impact, since it allows the users to rate internet resources in
a trustworthy manner.

Most of the existing media platforms include a component for rating their
content (e.g., posts, videos, songs, movies). For example both YouTube and
IMDb provide rating mechanisms. The rating process on these two platforms is
handled by specialised implementations. Even if YouTube informs its users with
respect to the number of views, likes or dislikes that a video resource collected,
there are other factors that influence these numbers (e.g., watch time, session
time or the popularity of a specific channel). Since the number of views collected
by the video resources is usually a criteria for producing advertising money, the
owners of these resources may be determined to use fraudulent means to increase
their incomes. On the other hand, YouTube claims that their algorithms handle
these kinds of situations, even if there is still a lack of transparency in their
actions1.

On the IMDb platform, one of the main problems is the determination of
the ranking of a specific movie. The platform does not consider the mean of the
ratings, but it proposes a complex algorithm which computes the ranking based
on some criteria. Even if the rating values are accessible, the users can not trust
entirely the accuracy of the rating process, since its transparency is still under
question 2.

In order to address these issues, we propose a decentralized application for
rating. Besides the rating functionalities, which are provided by a specialised
smart contract, our solution comes with an additional authentication mecha-
nism, that guarantees the uniqueness of each user who rates resources. In this
way, the fraud tendencies are reduced and the rating process is transparent and
trustworthy.

Contributions. The main contribution of this paper is a blockchain-based decen-
tralized application for rating different kinds of internet resources. The applica-
tion provides its users with an intuitive UI, which facilitates the rating process.

1 There are plenty of web pages where users complain (e.g., https:

//www.authorsguilds.com/how-youtube-algorithm-works/, https://support.

google.com/youtube/thread/11131851?hl=en, https://www.appypie.com/

how-youtube-algorithm-works). Even if these pages cannot be necessarily trusted,
it is hard for YouTube to guarantee/prove that its rating algorithms are transparent
and work correctly.

2 https://help.imdb.com/article/imdb/track-movies-tv/ratings-faq/

G67Y87TFYYP6TWAV#.

https://www.authorsguilds.com/how-youtube-algorithm-works/
https://www.authorsguilds.com/how-youtube-algorithm-works/
https://support.google.com/youtube/thread/11131851?hl=en
https://support.google.com/youtube/thread/11131851?hl=en
https://www.appypie.com/how-youtube-algorithm-works
https://www.appypie.com/how-youtube-algorithm-works
https://help.imdb.com/article/imdb/track-movies-tv/ratings-faq/G67Y87TFYYP6TWAV#
https://help.imdb.com/article/imdb/track-movies-tv/ratings-faq/G67Y87TFYYP6TWAV#


DApp for Rating 3

The rating functionalities are implemented by a specialised smart contract, which
guarantees the protection of the identities of the users and stores rating records
in a proper manner.

Paper Organisation. In Section 2 we present background information on the
blockchain and the technologies we use. In Section 3 we present our main con-
tribution, that is, a decentralized application for rating. In Section 4 we present
some experiments that we have performed and their execution cost analysis. We
conclude in Section 5.

2 Background and tools

This section recalls several background notions and tools that we use in this
paper. We give a brief presentation of each of them, and we point the readers to
additional material if necessary.

The blockchain is a new technology, which records data across a peer-to-peer
network in a distributed shared ledger. The nodes of the network contribute
to the creation this distributed ledger, which is chain of blocks of transactions.
The creation of blocks is a complex process that requires computing power.
Specialised nodes, called miners, are incentivised to invest computational power
in order to create new blocks. Transactions are broadcasted in the network, and
miners collect them and try to build a block of transactions following strict
rules, including a link to the last known block in the chain of blocks. When a
miner finishes the creation of a block, the block is send across the network and
consensus algorithms are used to accept the block. The centralised control is out
of the question. Based on the consensus principles, approved blocks are added to
the main ledger and stored chronologically. Even if this technology was initially
designed for cryptocurrency trading [13], its potential is used in a variety of
software products.

Ethereum [23,3] is a popular blockchain platform, which enables the use
of smart contracts. A smart contract is just a program that encodes a digi-
tal agreement which is executed automatically by the miners in the network.
Such programs are deployed in the network as special transactions and the min-
ers need to execute them when creating blocks. Smart contracts can simulate
real-world agreements for different kinds of assets. Usually they are written in
higher-level languages (e.g., Solidity [5], Vyper [6]) and compiled into Ethereum
bytecode [23,3]. The compiled code is packed in a transaction and sent across the
network. Miners use the Ethereum Virtual Machine (EVM) to execute compiled
contracts. Each bytecode instruction has an associated execution cost. This is
yet another incentive for the miners to execute the code. On the other hand,
the smart contract programmer needs to balance the benefits with the execution
costs.

Solidity [5] is a statically-typed, high-level and contract-oriented program-
ming language designed for implementing smart contracts that run on the EVM.



4 Buţerchi et. al.

Solidity has a wide range of functionalities inspired by existing programming lan-
guages (e.g., JavaScript, C++ and Python). This programming language is used
on several platforms, including Ethereum and Hyperledger [7].

Remix [17] is a powerful tool that allows its users to design, deploy and test
smart contracts directly in the browser. It provides development environments
for several contract-oriented programming languages (e.g., Solidity, Vyper). Since
Remix can simulate the deployment process of a smart contract, users can in-
teract with the smart contract functions, emit events, debug or even inspect
transactions. Users can choose from a wide range of plugins, which are designed
to improve the development process of smart contracts (e.g., vulnerabilities de-
tection, costs estimation, oracles integration). Remix can connect with Meta-
mask [12] and deploy the smart contracts on various existing test networks (e.g.,
Ropsten [19], Kovan [11], Rinkeby [18]).

Metamask [12] is a browser extension, which can be used on various exist-
ing browsers (e.g., Chrome, Firefox and Brave). It represents a way to connect
normal browsers with the Ethereum blockchain and also to interact with de-
centralized applications. Metamask is a token wallet, which manages the digital
assets of the users and protects the personal data and the access keys. For test-
ing purposes, Metamask can be connected with a local blockchain network by
importing the predefined accounts.

Truffle [21] is a popular development framework for Ethereum. It provides
several tools that facilitate the development process of decentralized applications.
Truffle manages smart contracts deployments, automates the smart contracts
testing and provides its users with an interactive console, which includes useful
commands for smart contracts manipulation.

Ganache [20] is a tool provided by Truffle. It creates a local Ethereum
blockchain network, which can be used for smart contracts deployment and test-
ing purposes. The users can inspect the issued transactions or events and explore
the debugging information. Ganache contains a set of predefined accounts, which
can be imported in Metamask using their private keys and the mnemonic code.
The information about each account (e.g., address, balance, number of issued
transactions) can be also explored.

React [16] is a JavaScript library used for building the user interface for
web applications. We use React and Material UI [22] to create the UI of our
decentralized application for rating.

Passport [14] is a JavaScript library, which provides a wide range of authen-
tication strategies that can be embedded into a web application. Our solution
incorporates an authentication mechanism, which makes use of these strategies.

3 A decentralized application for rating

In this section we present a general workflow of the proposed decentralized
application for rating. The application is divided into several components, which
have specific roles (e.g., authentication, validation, storage, error handling and



DApp for Rating 5

Fig. 1. A use case diagram for the decentralized App for Rating. The user interacts with
the smart contract using several components: an authentication mechanism, an input
validation component, and a component that sends the rating to the smart contract.
A query-like component is used to retrieve data from the smart contract. The order of
the steps to perform is given by the numbered labels.

rating). The diagram in Figure 1 illustrates the main use cases of the application
and highlights the steps of the rating process using numbered labels. We explain
these steps in the next paragraphs.

First, the users need to authenticate (step 1 in Figure 1) with one of the
available providers (e.g., Google, GitHub and Spotify). If the user provides valid
credentials then the authentication process succeeds and an ID of the user is
returned (step 2). The IDs are used when users initiate a rating operation.

After authentication, the users can rate a diversity of internet resources (step
3) using their IDs (step 4). In order to be recorded, the ratings need to be valid.
The application contains a component responsible for input validation. Each time
an user initiates a rating operation, the validation component checks if a set of
conditions (e.g., if the rated resource is truly hosted by a specific provider or if
the user has already rated a specific resource) is met (step 5). If the requirements
are satisfied, the rating process can continue, otherwise an error is thrown.

Finally, the rating component is used to interact with the smart contract (step
6). The smart contract exposes a function that handles the rating, that has to be



6 Buţerchi et. al.

called only with valid arguments. The function creates a new transaction (step
7), sends it across the network and the state of the smart contract is eventually
updated (step 8).

There is also a component responsible for retrieving the rating data (steps
9 and 10) from the smart contract that informs the users with respect to the
updated rating history.

3.1 DApp components

In the current section, we will focus our attention on the main components of
the decentralized application: the smart contract, the authentication mechanism
and the user interface. We will briefly discuss the role of each component within
the application.

1. The smart contract encapsulates the logic of the rating process. It exposes a
public function that is called each time an user initiates a rating operation.
This function handles accurately different use cases and alters the state of
the smart contract when a rating operation succeeds. The smart contract
includes several data structures that keep track of the rating history. We
do not perform any additional checks in the smart contract code, since this
could increase the execution cost.

2. The authentication mechanism guarantees the fact that users have valid ac-
counts. Since the users are uniquely identified, the attempts to rate multiple
times a specific resource are easily detected. In this way, the fraudulent ten-
dencies are reduced and the users are provided with a trustworthy rating
experience.

3. The user interface provides the users with an intuitive visual experience of
the rating process and contains three sections: the authentication section,
the rating section and the data visualisation section. The user interface ac-
cesses the state of the smart contract and retrieves the rating history in an
asynchronous manner. The extracted information can be used not only for
the data visualisation section, but also for error handling within the rating
section.

3.2 Smart contract for rating

We designed a smart contract which simulates the behaviour of a like/dislike-
based rating system. We developed the smart contract in a Solidity environment
within the Remix platform. The smart contract allows the users to rate positively
or negatively different kinds of media contents. The behaviour of the smart
contract does not change, no matter which one is the content provider. The
users and the rated resources are uniquely identified and the ratings consist of
tuples of the following form:

〈 a user identifier, a resource identifier, a boolean value 〉,



DApp for Rating 7

where the boolean flag represents a positive or a negative rating. The logic of the
smart contract was simplified, since a part of the conditions and requirements
are handled directly at the application level. This simplification process has no
impact on the accuracy of the rating operations, and it reduces considerably the
execution costs, which is one of our goals.

Data structures. The smart contract contains a set of data structures which
record the rating operations. In this section, we will provide a brief description
of the used data structures. The identifiers for users are of type bytes32 and
the identifiers for resources are of type string.

1. resourceRating is a struct used to monitor the number of likes and dislikes
for a specific resource.

2. resourcesInformation represents a mapping. The structure records the
number of likes and dislikes for each rated resource.

3. resources is an array data structure. This component stores all the re-
sources that were rated.

4. ratedResources represents a mapping. It contains tuples of user IDs and
boolean values, where the boolean values indicate if a resource was previously
rated or not.

5. ratingsInformation is a mapping data structure. It records a tuple of the
following form: user, resource, rating value. This data structure is helpful,
because it provides information with respect to the rating history. If an
user attempts to rate multiple times (e.g., positively or negatively) a spe-
cific resource, the rating operation will be rejected, since this data structure
contains the proof of the previous rating operation.

6. usersToResources is a similar to the data structure which was previously
described. The purpose of this mapping is to record if a resource was previ-
ously rated by a specific user. The application can handle several error cases
based on the information stored within this data structure.

These data structures are used within the rating function exposed by the
smart contract. If a rating operation succeeds, these data structures are updated.
The state of the smart contract can be accessed externally, since all these data
structures are publicly available.

Smart contract functions. In this section, we will focus our attention on
the functionalities exposed by the smart contract. We will enumerate a set of
possible use cases, which are handled by the smart contract.

1. The users can rate the resources positively or negatively (e.g., by giving likes
or dislikes).

2. The users can change their rating options for the previously rated resources.
In this case, the number of likes and dislikes of the resources updates accord-
ing to the current rate (e.g., if the initial rate is positive and the current rate
is negative, the number of likes decreases by one and the number of dislikes
increases by one).



8 Buţerchi et. al.

3. If an user intends to rate a resource that was not previously included in the
rating history, the resource is recorded and its number of likes or dislikes,
initially 0, updates to 1.

4. If an user intends to rate a resource that was previously recorded, the number
of likes or dislikes increases by one, with respect to the current rate.

The rate function (Listing 1.1) handles accurately each possible use case of
a like/dislike-based rating system. Based on the provided arguments ( cred –
the user identifier, res – the resource identifier and vote – the rate value), this
function updates the state of the smart contract each time a new transaction
is issued. The resource is plainly recorded within the smart contract, but the
identities of the users are protected, since their IDs are previously hashed.

Listing 1.1. The implementation for the rate function.

function rate(
bytes32 _cred ,
string memory _res ,
bool _vote

) public {
if (usersToResources[_cred][_res] == true) {

if (
ratingsInformation[_cred][_res] == true &&
_vote == false

) {
ratingsInformation[_cred][_res] = false;
resourcesInformation[_res].likes -= 1;
resourcesInformation[_res]. dislikes += 1;

}
if (

ratingsInformation[_cred][_res] == false &&
_vote == true

) {
ratingsInformation[_cred][_res] = true;
resourcesInformation[_res].likes += 1;
resourcesInformation[_res]. dislikes -= 1;

}
} else {

if (ratedResources[_res] == false) {
ratedResources[_res] = true;
resources.push(_res);
usersToResources[_cred ][_res] = true;
if (_vote == true) {

resourcesInformation[_res] = resourceRating (1, 0);
ratingsInformation[_cred ][_res] = true;

} else {
resourcesInformation[_res] = resourceRating (0, 1);
ratingsInformation[_cred ][_res] = false;

}
} else {

usersToResources[_cred ][_res] = true;
if (_vote == true) {

resourcesInformation[_res].likes += 1;
} else {

resourcesInformation[_res]. dislikes += 1;
}

}
}

}



DApp for Rating 9

In addition to the rate function, the smart contract exposes several helper
functions:

1. getResourceInformation returns the number of likes and dislikes associated
with a specific resource. The resource identifier is given as argument to this
function.

2. getNumberOfRatedResources returns the total number of rated resources.
3. getRatedResource returns the identifier of a resource based on its index in

the list of rated resources.

They are called at the application level for retrieving the rating history or
other useful information.

3.3 Authentication mechanism

The decentralized application includes an authentication mechanism. In order
to rate media contents, the users need to use the credentials from a specific
provider (e.g., YouTube, Spotify, GitHub). Even if the users are required to
use their credentials, the ID provided by the authentication mechanism is not
plainly stored in the smart contract. The credentials used in the rating process
are previously hashed with md5. In this way, the one cannot find the credentials
by simply inspecting the blockchain. This authentication mechanism ensures the
fact that users have valid accounts. We are interested in this because we need
to make sure that the rating process is trustworthy w.r.t. existing accounts.

Our approach is efficient in preventing multiple rating situations. For in-
stance, a smart contract which records the ratings based on the Ethereum ad-
dresses of the users is not resistant to multiple rating attempts. An user can
generate multiple Ethereum addresses and rate a specific resource using those
addresses. In this way, the ratings can be easily tricked.

The advantage of our solution is precisely this additional authentication layer.
Even so, the users can rate multiple times a specific resource, but they need to
have active accounts on the platform that share the resource. This is more dif-
ficult to achieve than the generation of Ethereum addresses. We actually reuse
existing algorithms for detecting and removing fake accounts currently imple-
mented by the media platforms.

For the authentication mechanism we used Passport, a JavaScript library
which provides a variety of authentication strategies. Currently, in our applica-
tion we provide support for Google, GitHub and Spotify, but other strategies
can be easily added.

3.4 User Interface

The decentralized application offers an intuitive user experience. Besides the
capacity of the smart contract to handle the rating process, some operations
and conditions are included directly in the application. The user interface is
divide into three main sections: authentication, a section for rating and data
visualisation.



10 Buţerchi et. al.

Fig. 2. Authentication page where the users can select the platform to sign in. In order
to connect with one of the existing log in options, the users should have a valid account
on the chosen platform.

In the authentication section, the users can choose one of the available login
strategies (e.g., Google, GitHub and Spotify). Once the authentication mecha-
nism issues the IDs, the users can start to rate resources.

The rating section is more complex, because it encapsulates the modules for
input validation and error handling. The users need to provide an URL of the
resource and to select a rating option (e.g., like or dislike). Before we call the
rating function from the smart contract, we perform two input validation steps:

1. We check the provenience of the resource;
2. We check the rating history (i.e., if the user rated the resource with the same

rating value, then the user cannot rate it again);

If one of the situations below occurs, the error handling module throws some
errors:

1. If the user intends to rate an invalid resource, then the error handling module
returns a notification message with the following content: Invalid resource.

2. If the user attempts to rate multiple times the same resource, then the error
handling module returns a notification message with the following content:
Multiple ratings for the same resource are not allowed.



DApp for Rating 11

Fig. 3. The rating page. The users can complete the form with an URL-based resource
and rate it positively or negatively by clicking one of the two specialised buttons. The
users can inspect their rating history (e.g., the users have access to a table which
contains the rated resources and their associated number of likes/dislikes) by clicking
the See ratings link.

If all requirements are met, the rating process continues and a Metamask
window will inform the user regarding the rating costs. When the user confirms
the transaction, the rating function is called and the state of the smart contract
will be modified by the miners in the Ethereum network. The URL-based re-
sources are validated using API calls to the services that share the resources.
The state of the smart contract is accessed through reading operations and the
rating history can be user to determine if an user rated previously a specific
resource.

The data visualisation section accesses the state of the smart contract and the
users can inspect directly in the application their rating history. The interactions
with the smart contract are asynchronous and it is a matter of seconds until the
updated information is displayed within the application.

We designed the decentralized application using React and Material UI (i.e.,
JavaScript libraries which provide a variety of predefined UI components).



12 Buţerchi et. al.

4 Evaluation/Experiments

In this section we evaluate all the costs required by our decentralized application.
There are several categories of costs: the cost to deploy the application, the costs
to maintain the smart contract and the costs supported by users for rating the
resources. We will present our approaches and their impact on the execution
costs.

Our initial attempt was to encapsulate the entire logic within the smart
contract. Since our rating system aims to avoid the multiple voting problem and
to validate the resource provenience, the smart contract gained in complexity.
This led to increased execution costs and made our initial attempt unfeasible.
Moreover, smart contracts can not access information outside the network. Since
we needed confirmations that the rated resources are shared by specific providers,
we initially used an oracle (i.e, a service that verifies real world data and submits
the collected information to the smart contract). We used Provable [15] and
Chainlink [4] to validate the arguments for the rating function. This approach
led to different kinds of problems. First of all, the deployment costs and the costs
supported by users for the rating operations increased considerably, because the
off-chain requests require extra fees. The off-chain request involved also the usage
of custom cryptocurrencies (e.g., LINK for Chainlink oracle).

In order to stimulate the interest for the proposed rating system, we tried
to minimize the costs3. Based on the observation that off-chain interactions are
far more suitable, we moved the authentication, input validation and other side
logic outside the smart contract. The complexity of the smart contract is now
considerably reduced. Except the minimal information (IDs, resources and their
associated ratings) required to keep the ratings in a decentralized manner, the
rest of the logic is directly handled at the application level. Thus, the off-chain
dependencies were removed from the smart contract.

In Table 1, we present a brief comparison between the versions of the smart
contract that we have developed. The ones that use external providers (oracles)
like Provable or Chainlink have an unacceptable execution cost for rating. The
simple smart contract with no external providers has significantly lower execu-
tion costs per rating operation. This is the one we have currently implemented4.

The codebase is available at https://github.com/buterchiandreea/rating-dapp.
The Github repository contains the source code and installation instructions.
The smart contract code is written in Rating.sol under the contracts folder,
while the UI is mainly in the client folder.

3 The costs involved by the smart contract deployment and the costs for a rating oper-
ation with and without off-chain interaction were observed in a testing environment
provided by Ganache.

4 The code is available on GitHub:https://github.com/buterchiandreea/
rating-dapp/blob/master/contracts/Rating.sol

https://github.com/buterchiandreea/rating-dapp
https://github.com/buterchiandreea/rating-dapp/blob/master/contracts/Rating.sol
https://github.com/buterchiandreea/rating-dapp/blob/master/contracts/Rating.sol


DApp for Rating 13

Costs analysis

Smart Contract ver-
sion

Deployment Rating operation

Simple smart contract
(no external providers)

10 $ 0.2 $

Provable 10 $ 2 $

Chainlink 10 $ 2-8 $

Table 1. A comparison between various smart contract versions that we experimented.
The table shows the costs for deployment and rating operations. Note that the versions
of the smart contract that use external providers (oracles) like Provable or Chainlink
have an unacceptable execution cost for rating.

5 Conclusions

The solution we propose in this paper is a decentralized application that stores
the rating in the blockchain using a simple smart contract. In order to rate an
internet resource, users need accounts on the platform that shares that resource.
Obviously, their accounts or login information are not stored in the blockchain,
but their hashed value is used to limit the number of votes to a maximum of 1 per
account. Note that this approach keeps the benefits brought by the algorithms
for eliminating or detecting fake accounts currently implemented in the existing
media platforms. In this context, our rating application cannot accept more fake
ratings than the existing approaches, as shown in Figure 4. The transparency
and decentralisation are guaranteed by the use of the blockchain.

To summarise, our approach provides a decentralized solution to keep rat-
ings for internet resources identified by an URL. The approach is based on the
blockchain technology that provides anonymity and immutability of data besides
decentralisation. We use authentication with third parties in order to provide an
inferior limit to the number of votes. The limit is the number of accounts con-
trolled by an user.

Future work. There are at least two new features than we intent to add to our
decentralized application. First, we want to add more extensions, so that users
can authenticate with other accounts. Currently we support only Google, Spotify,
and GitHub, but our architecture allows any extension that is compatible with
Passport. Another improvement is related to the various types of ratings. At
this point, our application only allows users to rate resources using a two choice
(positive/negative) option. However, other rating systems allow scores or systems
based on stars. Adding reviews is also an interesting feature, but this requires a
very strong analysis on the costs involved to keep the reviews on the blockchain.
An interesting idea would be not to keep the reviews on the blockchain, but
only a hashed value of the review so that it can be easily checked if a review
retrieved from a different resource is indeed the one whose hash is stored in the
blockchain.



14 Bu";"""date"",""2020-09-08T01:12:06Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2020-09-08T01:12:06Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016) kpathsea version 6.2.2""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2020-09-08T01:12:06Z""
""created"",""2020-09-08T01:12:06Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-09-08T01:12:06Z""
""resourceName"",""2009.03253""
""Author"",""""
""producer"",""pdfTeX-1.40.17""
""pdf:docinfo:producer"",""pdfTeX-1.40.17""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""2"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2020-09-08T01:12:06Z""
""Last-Modified"",""2020-09-08T01:12:06Z""
""dcterms:modified"",""2020-09-08T01:12:06Z""
""title"",""""
""Last-Save-Date"",""2020-09-08T01:12:06Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2020-09-08T01:12:06Z""
""meta:save-date"",""2020-09-08T01:12:06Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016) kpathsea version 6.2.2""
""Content-Length"",""533976""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""15""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""2266"",""2651"",""2442"",""2598"",""1381"",""2122"",""2362"",""1628"",""2273"",""1157"",""1169"",""2538"",""2240"",""1566"",""1119""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-09-08T01:12:06Z""
";https://scholar.google.ch/scholar?start=790&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098818-221;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;[PDF][PDF] Beyond Software Watermarking: Traitor-Tracing for Pseudorandom Functions.;R Goyal, S Kim, B Waters, DJ Wu ; IACR Cryptol. ePrint Arch., 2020  eprint.iacr.org;;"… Finally, there is a trace algorithm Trace that takes as input the tracing key tk and has oracle access

to a distinguisher D … we have numerous construc- tions via combinatorial tools [CFN94, SW98,

CFNP00, SSW01, PST06, BP08] as well as a variety of crypto- graphic assumptions …";Autres articles;;[PDF] iacr.org;https://eprint.iacr.org/2020/316.pdf;"
Beyond Software Watermarking:

Traitor-Tracing for Pseudorandom Functions

Rishab Goyal∗ Sam Kim† Brent Waters‡ David J. Wu§

Abstract

A software watermarking scheme provides a method to prevent unauthorized distribution of software.
Specifically, watermarking schemes allow a user to embed an identifier into a piece of code such that
the resulting program is nearly functionally-equivalent to the original program, and yet, it is difficult
to remove the identifier without destroying the functionality of the program. Existing constructions of
watermarking have focused primarily on watermarking pseudorandom functions (PRFs).

In this work, we revisit the definitional foundations of watermarking, and begin by highlighting a
major limitation in the existing security notion. Currently, the security requirement in watermarking
schemes only requires that the identifier be successfully extracted from programs that preserve the exact
input/output behavior of the original program. In the context of PRFs, this means that an adversary
that constructs a program which computes a quarter of the output bits of the PRF or that is able to
distinguish the outputs of the PRF from random are considered to be outside the threat model. However,
in any application (e.g., watermarking a decryption device or an authentication token) that relies on PRF
security, an adversary that manages to predict a quarter of the bits or distinguishes the PRF outputs
from random would be considered to have defeated the scheme. Thus, existing watermarking schemes
provide very little, if any, security guarantee against realistic adversaries. We emphasize that none of
the existing constructions of watermarkable PRFs would be able to extract the identifier from a program
that only outputs a quarter of the bits of the PRF or one that perfectly distinguishes.

To address the shortcomings in existing watermarkable PRF definitions, we introduce a new primitive
called a traceable PRF. Our definitions are inspired by similar definitions from public-key traitor trac-
ing, and aim to capture a very robust set of adversaries: namely, any adversary that produces a useful
distinguisher (i.e., a program that can break PRF security), can be traced to a specific identifier. We
provide a general framework for constructing traceable PRFs via an intermediate primitive called private
linear constrained PRFs. Finally, we show how to construct traceable PRFs from a similar set of assump-
tions previously used to realize software watermarking. Namely, we obtain a single-key traceable PRF
from standard lattice assumptions and a fully collusion-resistant traceable PRF from indistinguishability
obfuscation (together with injective one-way functions).

1 Introduction

Software watermarking is a mechanism for protecting against unauthorized re-distribution of software. In a
watermarking scheme, a user can embed some special information called a “mark” into a program such that
the resulting program is nearly functionally-equivalent to the original one, and moreover, it is difficult for an

∗Simons Institute for the Theory of Computing. Email: goyal@utexas.edu. Part of this work was done while at UT Austin.
Research supported in part by an IBM PhD fellowship and the Simons-Berkeley research fellowship.
†Stanford University and Simons Institute for the Theory of Computing. Email: skim13@cs.stanford.edu. Research supported
by NSF, DARPA, a grant from ONR, and the Simons Foundation.
‡UT Austin and NTT Research. Email: bwaters@cs.utexas.edu. Research supported by NSF CNS-1908611, CNS-1414082, a
Simons Investigator award and a Packard Foundation Fellowship.
§University of Virginia. Email: dwu4@virginia.edu. Part of this work was done while visiting the Simons Institute for the
Theory of Computing. Research supported by NSF CNS-1917414 and a University of Virginia SEAS Research Innovation
Award.

1

mailto:goyal@utexas.edu
mailto:skim13@cs.stanford.edu
mailto:bwaters@cs.utexas.edu
mailto:dwu4@virginia.edu


(a) Original (b) Encrypted (c) Recovered (pixel-level) (d) Recovered (block-level)

Figure 1: Illustration of plaintext recovery using a PRF-based encryption scheme given a
circuit that computes the top n/4 bits of the PRF. Fig. 1a shows the original image and
Fig. 1b shows the image encrypted using a PRF in counter mode. Figs. 1c and 1d shows the
recovered image if the image is encrypted pixel-by-pixel and block-by-block, respectively, and
the adversary has a circuit that computes the n/4 most significant bits of the PRF output.

adversary to remove the watermarking without destroying its input/output behavior. The majority of works
studying cryptographic notions of watermarking have focused primarily on watermarking pseudorandom
functions (PRFs) [CHN+16, BLW17, KW17, QWZ18, YAL+18, KW19b, YAL+19]. Namely, the goal in
each of these constructions is to embed an identifier (e.g., a user’s name or a device id) into a PRF key
such that (1) the marked key still preserves the input/output behavior of the original PRF; and (2) no
efficient adversary is able to construct a key that both preserves the input/output behavior of the PRF
on an Îľ-fraction of the domain and does not contain the identifier. The first requirement corresponds to
“correctness” while the second corresponds to “unremovability.”

The brittleness of existing definitions. While the correctness and unremovability definitions above
seemingly capture an intuitive notion of what we might desire from a software watermarking scheme, they
fall short of capturing meaningful notions of security in most settings. For instance, suppose we have a
watermarkable PRF secure under the above notions, and consider an adversary that takes a marked circuit
C : {0, 1}n → {0, 1}n and outputs a circuit C ′ that on input x, outputs the first n/4 bits of C(x). Under
existing watermarking definitions, mark-extraction is allowed to fail in this setting, even though critical
information about the original function is revealed by C ′. In other settings, an adversary might construct
a circuit C ′′ that takes as input a pair (x, y) and outputs 1 whenever C(x) = y. Namely, C ′′ is able to
completely break pseudorandomness of the construction, and yet would evade the tracing algorithm. Here,
even though the syntax of the circuit C ′′ is different from the original circuit C, access to the distinguisher
C ′′ can still invalidate the security of any scheme built using the underlying PRF. The preserved information
in the examples above is often sufficient to compromise security of any scheme that relies on the watermarked
PRF. For instance, if the PRF is used to construct a symmetric encryption scheme, a circuit that outputs a
quarter of the bits of the PRF completely breaks semantic security of the encryption scheme (see Fig. 1 for
an illustration), and yet, under existing definitions, it need not be possible to identify the compromised key.

The above examples highlight a limitation in the prevailing security notion for cryptographic watermark-
ing, as the existing definition only allows for a very narrow range of adversarial strategies. Indeed, none
of the existing constructions [CHN+16, BLW17, KW17, QWZ18, YAL+18, KW19b, YAL+19] of software
watermarking remain secure if we expand the set of admissible adversarial strategies to include even the
simple examples described above. Existing constructions of watermarking all take the approach of carefully
embedding the identifier in the output of the function. Such an embedding critically takes advantage of
the assumption that the adversary will preserve much of the exact input/output behavior of the original
function, in which case, most of the original outputs (that embed the identifier) would also be preserved.
Consequently, if the adversary constructs a circuit that drops a quarter of the bits of the output (or worse yet,

2



does not compute the output at all and only distinguishes input-output pairs), then the tracing algorithm
cannot recover the embedded identifier.1 Consequently, using existing watermarkable PRF constructions to
construct watermarked decryption or authentication devices does not provide adequate security guarantees
in realistic settings.

In cryptography, it is not only prudent, but oftentimes, essential for applications, to design expressive
threat models that enable the broadest range of adversaries. Indeed, the very first formal security no-
tions [GM84, GGM84] in cryptography carefully distinguished between the functionality requirements of a
primitive and what the adversary would need to do to break it. In the case of semantic security [GM84], it
sufficed for an adversary to distinguish between encryptions of two messages, and not that the adversary be
able to recover the original message. In the case of PRFs [GGM84], it sufficed that the adversary could dis-
tinguish PRF evaluations from random as opposed to needing to predict the outputs of the PRF (and indeed,
imposing such a restriction on the adversary would limit the usefulness of the primitive). In each of these
examples, the adversary’s objective is easier to achieve than emulating the exact functionality or semantic
requirements of the primitive. This is the philosophy we take when designing our security definitions.

This work. Our primary motivation in this work is to re-evaluate the security definitions for building
watermarkable PRFs. Drawing from related definitions developed in the literature on traitor tracing [CFN94,
BSW06, NWZ16, GKRW18, GKW18] as well as recent work on watermarking public-key cryptographic
primitives [GKM+19], we introduce a new notion of a traceable PRF which not only suffices to instantiate
all of the existing applications of watermarkable PRFs, but which also addresses the limitations of existing
watermarkable PRF definitions and offers meaningful security guarantees in realistic scenarios (e.g., they can
be used to construct traceable symmetric encryption schemes). We then show how to construct non-collusion-
resistant traceable PRFs from private constrained PRFs [BLW17] and fully collusion-resistant traceable PRFs
from indistinguishability obfuscation [BGI+01]. We note that the assumptions needed to instantiate both of
our schemes match the assumptions needed to instantiate watermarkable PRFs. This means that our new
primitives can be instantiated from the same assumptions as watermarkable PRFs, and yet, provide much
stronger security guarantees.

1.1 Our Results

Our first contribution is a new security definition that better captures the security goals in watermarkable
PRFs. Here, we start from the beginning by re-examining the original motivation for building watermarkable
PRFs. The original intent of watermarking PRFs is to be able to give a user a marked implementation of a
PRF (e.g., for use in a symmetric encryption or authentication scheme) such that if the user later on tries to
replicate the PRF functionality, there is a way to trace the replicated program back to the user’s original key.
The question is what constitutes a “valid” attempt at replicating the functionality. In this work, we consider
any program that violates the security of the PRF (i.e., is able to distinguish PRF outputs from random)
to be a “valid” attack. This definition is in part inspired by security definitions proposed in the setting
of traitor tracing by Nishmaki et al. [NWZ16] (and adopted by later papers [GKRW18, GKW18]). In the
earlier definitions starting with [CFN94], the tracing algorithm was only required to work against adversarial
decoders that could successfully decrypt and recover the original message in its entirety from a ciphertext.
However, [NWZ16] observed that this definition can be too restrictive as it ruled out valid attacks that
could extract partial information about the encrypted message (e.g., the first quarter of an encrypted video
stream) or simply distinguished between different messages. Fortunately, most traitor tracing constructions
developed under earlier definitions also remained secure under the strengthened definition. However, this
does not appear to be the case for watermarkable PRFs.

1In some cases (e.g., [CHN+16]), the tracing algorithm can still partially recover the identity (e.g., a quarter of the bits) from
a circuit that outputs a quarter the bits of each output. But this tracing algorithm can be defeated by an adversary which
outputs a circuit that only distinguishes the output of the PRF (i.e., on input (x, y), output 1 if Eval(msk, x) = y and 0
otherwise) or a circuit that computes the parity of the bits of the PRF output.

3



Our notion: traceable PRFs. Since the functionality in this case is a PRF, a natural security notion
is that if the adversary outputs any functionality that helps one break pseudorandomness (i.e., distinguish
the outputs of the PRF from random), then it should be possible to trace the identity associated with the
functionality. For technical reasons we discuss in Section 3.1, we focus on weak pseudorandomness in this
work. We require that any program that can distinguish the PRF outputs on random domain elements can
be traced to one (or more) compromised keys. Observe that this not only captures adversarial strategies that
construct programs that preserve the exact input/output behavior of the PRF on an Îľ-fraction of the domain
(as in the case of watermarking), but also captures both the adversarial cases we described earlier where the
adversary produces a program that outputs a quarter of the bits of the PRF or a program that manages
to distinguish input-output pairs of the PRF from random. Under our definition, no efficient adversary is
able to remove a mark from the program unless it produces a program that is useless for breaking weak
pseudorandomness of the PRF.

More precisely, a traceable PRF scheme consists of four algorithms: Setup, KeyGen, Eval, and Trace. The
Setup algorithm samples a PRF key msk and a tracing key tk that is used for tracing. The key-generation
algorithm takes as input the PRF key msk and an identifier id and outputs a “marked” key skid. The
evaluation algorithm Eval takes as input either the PRF key msk or an identity key skid and implements PRF
evaluation. We require that Eval(skid, ¡) and Eval(msk, ¡) agree almost everywhere (i.e., on all but a negligible
fraction of the domain). This property is the analog of the “correctness” or “functionality-preserving”
property in the setting of watermarking schemes. Finally, there is a trace algorithm Trace that takes as
input the tracing key tk and has oracle access to a distinguisher D, and outputs a set of compromised keys
(if any). Our security requirement says that if the distinguisher D is able to break weak pseudorandomness of
the PRF (i.e., distinguish the outputs of Eval(msk, ¡) at random points from those of a random function), then
the tracing algorithm must successfully identify the set of compromised keys used to construct D. Similar to
the corresponding notions in traitor tracing (and watermarking), we can consider several variations of our
basic schema and requirements:

• Collusion-resistance: We say that a traceable PRF is fully collusion-resistant if an adversary who has
an arbitrary number of identity keys S = {skid1 , . . . , skidk} still cannot construct a useful distinguisher
D where TraceD(tk) does not output a non-empty set T ⊆ S.2 We say that a scheme satisfies bounded
(resp., Q-key) collusion resistance if security only holds against adversaries that compromise an a priori
bounded number of keys (resp., at most Q keys). In this work, we show how to construct a single-key
traceable PRF from standard lattice assumptions3 and a fully collusion resistant traceable PRF from
indistinguishability obfuscation (and injective one-way functions).

• Public tracing vs. secret tracing: We say that a traceable PRF supports public tracing if security
holds even if the tracing key tk is public. Otherwise, we say the traceable PRF is in the secret tracing
setting. Our basic single-key traceable PRF from standard assumptions is secure in the secret-tracing
setting, while our obfuscation-based construction is secure in the public-tracing setting.

We provide the full definition in Section 4.1.

Constructing traceable PRFs. To construct traceable PRFs, we introduce an intermediate primitive
of a private linear constrained PRF. This primitive can be viewed as a symmetric analog of a “private
linear broadcast encryption” (PLBE) from [BSW06] and which has featured prominently in a number of
subsequent traitor tracing constructions [GKSW10, NWZ16, GKW18]. First, recall that in a constrained
PRF [BW13, KPTZ13, BGI14], the holder of the PRF master secret key msk can issue a constrained key skf
for a constraint f such that the constrained key can be used to evaluate on only the inputs x that satisfy the

2We cannot stipulate that T = S since the adversary might not use every compromised key when constructing the distinguisher
D. The tracing algorithm can only recover the keys the adversary actually uses.

3A traceable PRF bears many similarities with a constrained PRF [BW13, KPTZ13, BGI14], and all known constructions of
collusion-resistant constrained PRFs for sufficiently complex constraints from standard assumptions are secure only in the
single-key setting [BV15].

4



constraint (i.e., the inputs x where f(x) = 1). Moreover, the value of the PRF at points x where f(x) = 0
remain pseudorandom even given skf .

A private linear constrained PRF is similar in spirit to a constrained PRF for a class of linear constraints.4

In this case, the constrained keys are each associated with a κ-bit index id ∈ [0, 2κ − 1]. Every input in
the domain is associated with a private index t ∈ [0, 2κ] and a constrained key for index id can be used to
evaluate the PRF on all inputs whose index t ≤ id. In addition to the usual Setup (for sampling the PRF
key), KeyGen (for issuing constrained keys), and Eval (for evaluating the PRF), there is a fourth algorithm
Samp that is used to sample domain elements with a given tag t together with the PRF evaluation at the
sampled point. The sampling algorithm Samp can either be public-key algorithm (in which case we obtain a
publicly-traceable PRF) or a secret-key algorithm (in which case we obtain a secretly-traceable PRF). Similar
to a PLBE scheme, there are three main security requirements we require on a private linear constrained
PRF:

• Normal hiding: A random domain element is computationally indistinguishable from a randomly-
sampled domain element with index 0 (output by Samp), even given any collection of identity keys.

• Identity hiding: A randomly-sampled domain element with index i is computationally indistinguish-
able from a randomly-sampled domain element with index j, provided that the adversary does not
have any identity keys for an index id ∈ [i, j − 1].

• Pseudorandomness: The PRF evaluations on randomly-sampled domain elements with index 2κ are
computationally indistinguishable from uniform given any collection of identity keys.

Given a private linear constrained PRF satisfying the above properties, we can construct a traceable PRF
using a similar type of transformation used to construct traitor tracing from PLBE. Namely, we can reduce
the tracing problem to a “jump-finding” problem as follows. Let D be the decoder constructed by the
adversary. By assumption, we assume that D is useful: namely, it breaks weak pseudorandomness of the
encryption scheme. This means that D is able to distinguish the PRF evaluation at a randomly-sampled
domain element from a uniformly random value with non-negligible advantage Îľ. By the normal hiding
property, D must also have advantage Îľ when distinguishing evaluations at randomly-sampled points with
index 0. Next, by the pseudorandomness property, the distinguishing advantage of D for randomly-sampled
points with index 2κ must be negligible. Thus, there must be a “jump” in the decoder’s distinguishing
advantage on domain elements on some index 0 < t < 2κ. By the identity-hiding property, such “jumps” can
only occur on indices for which the adversary possesses an identity key. We can then identify these jumps
(and correspondingly, the set of compromised keys) by either performing a linear scan over the identity space
(when the identity space is polynomial) [BSW06, GKSW10, GKW18] or by using a jump-finding algorithm
(when the identity space is exponential) [NWZ16].

Due to some technical differences between PLBE and private linear constrained PRFs, we actually have to
run the tracing algorithm twice in our construction. Very briefly, the reason behind this requirement is that,
unlike encryption systems where the distinguisher just receives a single ciphertext and has to output its guess,
the distinguisher in the case of traceable PRFs receives a tuple consisting of both a random domain element
together with its evaluation. Here, the distinguisher may stop working if it notices the tracer is changing the
distribution used to sample the inputs (i.e., domain elements). This means that if the tracer only performs
a single scan, such decoders may evade detection. Thus, we need to apply the underlying tracing algorithm
twice to circumvent this issue. In the first scan, the tracer runs the scan with a consistent output distribution,
and then it performs a second scan where the output distribution is random and essentially independent of
the input distribution. We provide the full technical details in Section 4.2.

Constructing private linear constrained PRFs. In this work, we describe two constructions of private
linear constrained PRFs. The first construction gives a single-key private linear constrained PRF in the
secret-tracing setting and can be instantiated from LWE while the second construction is a collusion-resistant

4As we describe more formally below, the “privacy” requirement refers to a property on the inputs to the PRF, and not the
notion of constraint-privacy in the standard definition of a “private constrained PRF” from [BLW17].

5



private linear constrained PRF in the public-tracing setting. Interestingly, both of our constructions rely on
a similar set of building blocks as those used for watermarkable PRFs. We give a high-level sketch of our
main constructions here:

• Single-key private linear constrained PRF. Our first construction combines a private constrained
PRF together with an authenticated encryption scheme with pseudorandom ciphertexts. Recall first
that a private constrained PRF is a constrained PRF where the constrained key skf hides the associated
constraint function f .

Let ` be the bit-length of the ciphertexts in the authenticated encryption scheme, and let sk be the
secret key of the authenticated encryption scheme. The domain of our PRF will be {0, 1}`, and a point
with index t ∈ [0, 2κ] will be an authenticated encryption of t. A constrained key for an identity id
consists of a private constrained key for the function fsk,id where fsk,id(x) = 0 whenever x is a valid
encryption under sk of some index t′ > id, and is 1 otherwise. The (secret-key) sampling algorithm
will first encrypt the target index t under sk and output the resulting ciphertext ctt together with the
PRF evaluation at ctt.

At a high-level, the security proof relies on the fact that a private constrained PRF hides the constraint
function, which in this particular case, means that it hides the secret key sk. Then, normal hiding
and identity hiding follows from the fact that ciphertexts are pseudorandom, and pseudorandomness
follows from constrained security of the underlying constrained PRF. We give the full description and
analysis in Section 5.

• Collusion-resistant private linear constrained PRF with public-tracing. Our second con-
struction gives a fully collusion resistant private linear constrained PRF that supports public tracing
from indistinguishability obfuscation and injective one-way functions (the latter is implied by most
algebraic assumptions such as DDH or LWE). The high-level idea is very similar to our secret-key
scheme above. Namely, the domain elements are ciphertexts in a (puncturable) public-key encryption
scheme [CHN+16], and the identity keys consist of an obfuscated program with the decryption key
hard-wired within it. To publicly sample inputs/outputs of the PRF (needed for public tracing), we
provide an obfuscated program with a (puncturable) PRF key hard-wired within. We provide the
details and analysis in Section 6.

An application: secret-key traitor tracing. We note that our notion of traceable PRFs lends itself
naturally to a secret-key traitor tracing scheme. For instance, we can take our encryption scheme to be
standard nonce-based encryption with a PRF (i.e., to encrypt a message m, sample a random r ← {0, 1}n
and compute the ciphertext ct = (r,m⊕ PRF(k, r)). If we instantiate the underlying PRF with a traceable
PRF, then the resulting scheme immediately gives a traitor tracing scheme. Namely, any decoder that is
able to distinguish between the encryption of two messages m0 and m1 also necessarily is able to distinguish
PRF(k, r) from uniformly random for a random choice of r ← {0, 1}n. The claim then follows by tracing
security. We stress here that a similar notion would not follow if we replace PRF with a watermarkable PRF.
Here, it is not clear how to translate a decoder D that is only able to distinguish between encryptions of two
messages into an algorithm that is able to recover the full input/output behavior of the PRF on a noticeable
fraction of the domain.

Comparison with watermarkable PRFs. One distinction between traceable PRFs and watermarkable
PRFs is that in our definition of a traceable PRF, the tracing key is sampled jointly with the PRF key. In
classic definitions of watermarking, it is possible to have a single (fixed) tracing key for an entire family of
PRFs. This means that it is possible to sample a PRF key and decide to mark it at a later point in time.
As we discuss in Section 3.1, having a tracing key that depends on the PRF key is essential to realizing the
strong security notions in a traceable PRF. In most practical scenarios, if one wanted to take advantage of
watermarking for software protection, it seems reasonable for them to sample the PRF key together with the

6



marked key(s). Thus this distinction does not seem significant in practice, and we believe that the stronger
and meaningful security notions achieved by traceable PRFs makes it a far more suitable primitive than a
watermarkable PRF in any realistic environment.

1.2 Related Work

Watermarking. Barak et al. [BGI+01, BGI+12] and Hopper et al. [HMW07] introduced the first rigorous
mathematical frameworks for software watermarking that considered arbitrary adversarial strategies (i.e.,
the adversary is allowed to output an arbitrary circuit that preserves the input-output behavior of the
original program). Cohen et al. [CHN+16] provided the first construction of a watermarking scheme for
PRFs using indistinguishability obfuscation. Earlier works on watermarking [NSS99, YF11, Nis13] imposed
additional restrictions on the adversary’s capabilities. Several works have also studied watermarking public-
key cryptographic primitives [CHN+16, BKS17, GKM+19]. Notably, the recent work of [GKM+19] expanded
watermarking security definitions (in the public-key setting) to include adversaries that are able to break
the “semantics” of a scheme (as opposed to just the set of adversaries that preserve exact input/output
behavior).

Traitor tracing. The notion of traitor tracing was first proposed by Chor et al. [CFN94] for solving the
piracy problem in broadcast systems. Since then, numerous relaxations have been studied in order to achieve
short ciphertexts. Broadly these can be categorized as follows: schemes where the traceability guarantees hold
as long as the adversary corrupts an a priori bounded number of users and schemes where the guarantees hold
as long as the adversary’s decoder succeeds with probability greater than an a priori threshold. The former
relaxation leads to traitor tracing schemes in the bounded collusion setting where we have numerous construc-
tions via combinatorial tools [CFN94, SW98, CFNP00, SSW01, PST06, BP08] as well as a variety of crypto-
graphic assumptions [KD98, BF99, KY02a, KY02b, CPP05, ADM+07, FNP07, LPSS14, NWZ16, ABP+17].
The latter schemes are typically referred to as “threshold traitor tracing” [NP98, CFNP00, BN08]. In another
line of work, [GKRW18] considered schemes with a relaxed tracing guarantee: namely, the tracing algorithm
does not need to be succeed in all cases. Recently, there has been significant progress on constructing fully
collusion-resistant compact traitor tracing schemes from standard lattice assumptions [GKW18, GKW19a].
Since then, a sequence of works has built new traitor tracing systems with more functionality from standard
cryptographic assumptions [CVW+18, GQWW19, GKW19b, KW19a].

2 Preliminaries

We write PPT to denote probabilistic polynomial-time. We denote the set of all positive integers up to n as
[n] := {1, . . . , n}. Throughout this paper, unless specified otherwise, all polynomials we consider are positive
polynomials. For any finite set S, x ← S denotes a uniformly random element x from the set S. Similarly,
for any distribution D, x← D denotes an element x drawn from distribution D. The distribution Dn is used
to represent a distribution over vectors of n components, where each component is drawn independently
from the distribution D.

For (possibly randomized) algorithms A and D, we use the notation AD to denote that algorithm A has
oracle access to algorithm D. Here, if the algorithm D is stateless, then on each query made by A to D, the
oracle responds with a randomly drawn sample from the corresponding output distribution. If the algorithm
D is stateful, then whenever A queries the oracle D, it can choose to either suspend the current execution
of the oracle D or to continue executing D while it maintains its state. If D terminates after receiving an
input, then it sends the final output of the computation as its query response to A.

Pseudorandom generator. A pseudorandom generator PRG : {0, 1}λ → {0, 1}` is secure if for every PPT
adversary A, there exists a negligible function negl(¡) such that

Pr

[
A(tb) = b :

s← {0, 1}λ, t0 ← PRG(s)
t1 ← {0, 1}`, b← {0, 1}

]
≤ 1

2
+ negl(Îť).

7



3 Defining Traceable PRFs

In this section, we formally introduce our notion of a traceable PRF.

Syntax. A traceable PRF scheme, with input-output space X = {XΝ,κ}Ν,κ∈N and Y = {YΝ,κ}Ν,κ∈N
5,

consists of the following four algorithms:

Setup(1λ, 1κ)→ (msk, tk). The setup algorithm takes as input the security parameter λ, the “’identity space”
parameter Îş, and outputs a master PRF key msk and a tracing key tk.

KeyGen(msk, id)→ skid. The key generation algorithm takes as input the master key and an identity id ∈
{0, 1}Îş. It outputs a secret key skid.

Eval(sk, x)→ y. The decryption algorithm takes as input a secret key sk (which could be the master key),
input x ∈ X , and outputs y ∈ Y.

TraceD(tk, 1z)→ T ⊆ {0, 1}κ. The tracing algorithm has oracle access to a program D, it takes as input the
tracing key tk, parameter z, and it outputs a set T of identities.

Weak pseudorandomness. Below we define the weak pseudorandomness property for traceable PRFs.

Definition 3.1 (Weak pseudorandomness). A traceable PRF scheme Tr-PRF = (Setup,KeyGen,Eval,Trace)
satisfies weak pseudorandomness property if for every stateful PPT adversary A, there exists a negligible
function negl(¡) such that for all Ν ∈ N, the following holds

Pr

[
AOb(msk) = b :

1κ ← A(1λ), b← {0, 1}
(msk, tk)← Setup(1λ, 1κ)

]
≤ negl(λ),

where the oracle Ob(msk) is defined as follows: if b = 0, then on each evaluation query made by adversary
A, the oracle samples random input x ← X and sends (x,Eval(msk, x)) to A; otherwise, if b = 1, then on
each evaluation query made by adversary A, the oracle samples random input x ← X and sends (x, f(x))
to A where f : X → Y is a random function.6

Key-similarity property. Informally, the key-similarity property says that the marked key is functionally
equivalent to the original unmarked key on all but a negligible fraction of inputs. Formally, we define the
property as follows:

Definition 3.2 (Key similarity). A traceable PRF scheme Tr-PRF = (Setup,KeyGen,Eval,Trace) satisfies
key-similarity if t";"""date"",""2020-03-14T03:52:34Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2020-03-14T03:52:34Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016) kpathsea version 6.2.2""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2020-03-14T03:52:34Z""
""created"",""2020-03-14T03:52:34Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-03-14T03:52:34Z""
""resourceName"",""316.pdf""
""Author"",""""
""producer"",""pdfTeX-1.40.17""
""pdf:docinfo:producer"",""pdfTeX-1.40.17""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""10"",""0"",""0"",""0"",""3"",""4"",""5"",""11"",""1"",""0"",""0"",""2"",""2"",""15"",""4"",""4"",""6"",""12"",""6"",""4"",""10"",""13"",""12"",""12"",""14"",""12"",""14"",""10"",""15"",""3"",""10"",""11"",""10"",""18"",""28"",""41"",""18"",""35"",""11"",""25"",""25"",""7"",""0"",""1"",""0"",""4"",""11"",""3"",""4"",""5"",""5"",""2"",""1""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2020-03-14T03:52:34Z""
""Last-Modified"",""2020-03-14T03:52:34Z""
""dcterms:modified"",""2020-03-14T03:52:34Z""
""title"",""""
""Last-Save-Date"",""2020-03-14T03:52:34Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2020-03-14T03:52:34Z""
""meta:save-date"",""2020-03-14T03:52:34Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016) kpathsea version 6.2.2""
""Content-Length"",""690008""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""54""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""3298"",""3236"",""3989"",""3954"",""3957"",""3559"",""3456"",""2332"",""3030"",""3075"",""4099"",""2816"",""3551"",""2618"",""2661"",""2900"",""3248"",""2920"",""2921"",""2497"",""2299"",""2754"",""3169"",""2652"",""2927"",""2698"",""2724"",""3038"",""2820"",""3192"",""3175"",""2352"",""2094"",""2921"",""2585"",""2547"",""3082"",""2644"",""2762"",""2985"",""2138"",""3041"",""2676"",""2578"",""2465"",""2509"",""1740"",""2564"",""1304"",""1800"",""1748"",""2957"",""3283"",""806""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-03-14T03:52:34Z""
";https://scholar.google.ch/scholar?start=770&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098725-18;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Survey of smart contract security;M Bo, LIU Jiabing, LIU Qin, W Xiaoxiao… ; Chinese Journal of …  infocommjournal.com;;"… ???? Bug? ????????????ether lost in transfer? ????????stack size

limit??? Blockchain ? ? … ??????????? ???????????????????

????????????????????? ?????????Oracle [41] ? RealityKeys …";Autres articles;;[PDF] infocomm-journal.com;http://www.infocomm-journal.com/cjnis/EN/article/downloadArticleFile.do?attachType=PDF&id=170344;;;https://scholar.google.ch/scholar?start=560&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098751-71;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;A Certificateless Consortium Blockchain for IoTs;X Guo, Q Guo, M Liu, Y Wang, Y Ma… ; 2020 IEEE 40th …, 2020  ieeexplore.ieee.org;;"… edge computing. To the best of our knowledge, this is the first implementation of

certificateless signature in consortium blockchain. We formally prove the security

of our schemes in the random oracle model. Specifically, the …";Les 2 versions;;null;;;;https://scholar.google.ch/scholar?start=620&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098720-6;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;[LIVRE][B] Artificial Intelligence, Data and Blockchain in a Digital Economy;DKC Lee ;2020 books.google.com;;"Future Economy Series 19? |- Œ 190 (…) U^) ? |- Un) CD U ş |90 (…) U”) ?? (…) O U?) ?= O > * ?

Un) |- GU |× ş ) CD |- C G. [u] ? 19= U?) igence, jal Intell |C Data and Blockchain Art ital Economy

Dig In 3 inst Edition F Edited by David Lee Kuo Chuen In collaboration With …";;null;null;;;;
1619098857-313;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;On the Cryptographic Deniability of the Signal Protocol;N Vatandas, R Gennaro, B Ithurburn… ; … Conference on Applied …, 2020  Springer;;"… The random oracle (RO) queries made by the adversary are visible to the simulator. However,

the simulator might not be able to freely tamper with the RO input-output pairs (program the

RO), because the judge is granted access to the random oracles, too …";Cité 1 fois;;null;;;;https://scholar.google.ch/scholar?start=860&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098734-40;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Towards the Use of Blockchain Prediction Markets for Forecasting Wind Power;M Shamsi, P Cuffe ; 2020 6th IEEE International Energy …, 2020  ieeexplore.ieee.org;;"… 36], this issue matters in blockchain-hosted prediction markets as an oracle problem which … Augur

is a set of open source smart contracts that run on Ethereum blockchain. It allows cryptocurrency

users to create prediction markets or trade contracts associated with possible …";Autres articles;;[PDF] ucd.ie;https://researchrepository.ucd.ie/bitstream/10197/11730/2/Submitted%20Towards%20the%20Use%20of%20Blockchain%20Prediction%20Markets%20for%20Forecasting%20Renewables.pdf;"
Provided by the author(s) and University College Dublin Library in accordance with publisher 

policies. Please cite the published version when available.

Title Towards the Use of Blockchain Prediction Markets for Forecasting Wind Power

Authors(s) Shamsi, Mahdieh; Cuffe, Paul

Publication date 2020-10-01

Publication information 2020 6th IEEE International Energy Conference (ENERGYCon)

Conference details The 6th IEEE International Energy Conference (EnergyCon 2020), Gammarth, Tunisia 

(held online due to coronavirus outbreak), 28 September - 1 October 2020

Publisher IEEE

Item record/more information http://hdl.handle.net/10197/11730

Publisher's statement Š 2020 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.

Publisher's version (DOI) 10.1109/energycon48941.2020.9236467

Downloaded 2021-04-28T12:27:19Z

The UCD community has made this article openly available. Please share how this access 

benefits you. Your story matters! (@ucd_oa)

Š Some rights reserved. For more information, please see the item record link above.

https://twitter.com/intent/tweet?via=ucd_oa&text=DOI%3A10.1109%2Fenergycon48941.2020.9236467&url=http%3A%2F%2Fhdl.handle.net%2F10197%2F11730


1

Towards the Use of Blockchain Prediction Markets
for Forecasting Renewables

Mahdieh Shamsi and Paul Cuffe, Member, IEEE

Abstract—This paper proposes and discusses the idea of using
nascent blockchain hosted prediction markets as a decentralised
crowd sourcing method for renewable energy forecasting. This
method is further used as a risk management and hedging tool
against volatility in weather variables they depend on. While
existing approaches have been centralised by nature, with limited
sources of input data and models, prediction markets allow
anyone to participate in forecasting by betting on an outcome
and earning profits for correct results. Since they have mercenary
motivations, these participants are most likely to provide reliable
and accurate information. Moreover, renewable energy producers
can participate in these prediction markets to hedge against low
income periods of time due to poor weather conditions. This paper
delivers a conceptual framework to exploit prediction markets in
a blockchain platform with the aim of forecasting and hedging
of renewable energy sources. The potential financial gain from
applying this approach has been demonstrated through a case
study for a typical small wind power producer.

I. Introduction

RENEWABLE energy is expanding in the power sector.
Its global capacity grew to around 2,378 GW in 2018,

accounting for more than 33% of the world total installed power
generating capacity [1].
At such high penetration level, uncertainty in the output

power of volatile weather-based sources, such as wind and
solar, cause electrical systems to face various technical and
economical challenges such as reducing stability [2] and
reliability [3] and increasing capacity reserve requirements [4].
To overcome these challenges, it is timely to develop improved
prediction models to make these sources more forecastable.
Inaccuracy in renewable energy forecasting brings significant
costs to wind generators due to compensating imbalances in
electricity markets and this could be as much as 10% of the
total wind generator incomes from selling energy, based on the
assessment provided in [5].
On the other side, from system operator point of view,

prediction errors result in costs associated with daily unit
commitment/economic dispatch decisions. Every percentage
point of improvement in forecast errors will benefit the system
in terms of reduction in conventional generators production
costs and renewable source curtailment (considered in [6]–[8])
as well as operation, maintenance and start up/shutdown costs
of generators (considered in [7], [8]).

This publication has been funded by the Sustainable Energy Authority of
Ireland under the SEAI Research, Development & Demonstration Funding
Programme 2018, grant number 18/RDD/373.
M. Shamsi (mahdieh.shamsi@ucdconnect.ie) and P. Cuffe

(paul.cuffe@ucd.ie) are with the School of Electrical and Electronic
Engineering, University College Dublin.

Interests disclosure: P. Cuffe holds cryptographic assets.

While various factors such as renewable power penetration
level, method of modelling (deterministic or stochastic methods
as stated in [6]), scheduling time horizons and generation
resources mix and their different ramp rate capabilities (as
stated in [8]) affect the results of assessment and quantifying
the value of forecasting, they all suggest significant amounts
of stake, e.g. one case study in [6] shows that reduction in
conventional generators cost for Ireland electricity market would
be e 1.2 M per year for every percentage decrease in forecast
error of wind power generation. Work in [9] demonstrates
that in addition to the economic value of renewable forecasting
improvement, there would be improvement in reliability indexes
as well.
Considering the value of renewable forecasting, there is

an extensive research on different forecasting methods for
wind power generation (reviewed in [10]–[12]), solar power
generation (reviewed in [13]) or both of these sources (reviewed
in [14], [15]).

These forecasting methods are generally classified based on
forecasting time horizons i.e. short-term, medium-term, long-
term and type of methods which include physical, statistical
(time-series) and artificial intelligence techniques such as
machine learning, fuzzy logic and hybrid methods. Articles
[10], [12], [13], [15] provide a clear definition for forecasting
time horizons (e.g. short-term is defined as 30 minutes to 6
hours a head in [12] or long-term is defined as 1 month to 1
year ahead in [13]). Articles [11], [12], [14], [15] categorise
forecasting methods with respect to time horizons (e.g. physical
approach suitable for long-term forecast as stated in [12] or
artificial based methods for short-term forecast as mentioned
in [11]). Article [14] also specifies spatial resolution in its
classification.
The application area of each forecasting horizon in power

systems (regardless of the method of forecasting) is covered in
[10], [12]–[14] (e.g. day ahead forecast is considered for unit
commitment in [13] or forecasts in the range of a few seconds
has been suggested for voltage regulation and grid stability
in [14]). It is worth mentioning that these definitions are not
identical and vary from one reference to another.
In above mentioned methods, the input data to prediction

models are mostly provided through one or limited sources of
data and forecasting task is performed centrally by means of
one single method or algorithm.
One promising approach that appears to be entirely absent

from the literature on renewable energy forecasting is the
use of prediction markets and this paper attempts to address
this gap. Prediction markets are a form of financial markets
where participants trade in contracts whose payoffs depends on
unknown future events. In a truly efficient prediction market,
at any time the market price will be the best predictor of the



2

event [16]. Like in a stock market, participants in a prediction
market can buy or sell contracts with prices associated with
the probabilities for event possible outcomes [17]. As stated in
[18]: ""There is mounting evidence that such markets can help
to produce forecasts of event outcomes with a lower prediction
error than conventional forecasting methods"". It has been proved
that they outperform over traditional approaches in various
areas such as elections [19], sports matches [20], [21] and
in business section for sales forecasting [22]. While they are
widely celebrated amongst economists, they have not been
deployed in power systems to date.

There has been a few examples in recent research works for
using crowdsourced prediction methods in electricity sector,
specifically for demand forecasting. Article [23] proposes
an online platform where residential customers have access
to their electricity consumption data provided by advanced
metering infrastructures and can post questions and answers
related to electricity consumption which would be used to
achieve a prediction model. In article [24], a data collection
platform through mobile devices has been proposed in which
an electricity utility company can request for data and candidate
workers can provide it.

The aforementioned crowdsourcing applications do not
consider any specific kind of incentives or motivations for
participants to provide accurate data. Regarding this issue, work
in [25] provides an approach in which electricity supplier gives
each consumer rewards proportional to their forecast accuracy.
This way, consumers have incentives to forecast as accurately
as possible or adjust their electricity consumption to match
their own forecast. Work in [26] presents a design for a binary
prediction market for electrical demand forecasting. All these
proposals still are performed in a centralised format.

The remainder of this paper is organised as follows: Section
II describes the methodology of the research. It provides
background information about prediction markets and discusses
how blockchain platforms implement these markets. Moreover,
it delivers a conceptual framework for the application of
prediction markets in renewable energy forecasting and hedging
and demonstrates the financial gain that a typical wind power
producer might attain by participating in these markets. Finally
Section III concludes the paper.

II. Methodology

Prediction markets, in centralised forms, have existed for
many years. In these type of markets, a trusted entity is in charge
of running the market, recording the trades and specifying the
outcome of the events. They finally perform market clearing
tasks and distributes payoffs to the winners who speculated
the outcome correctly. One of the best known platforms of
such prediction markets is iem (Iowa Electronic Markets) [27],
developed by the faculty at the University of Iowa in 1988 as
a research and teaching tool. It has been able to make efficient
forecasts for various events such as political contests, with
an average absolute error of about 2.5% for five presidential
elections, as mentioned in [28] and also for forecasting box
office receipts with a root mean square error not exceeding than
0.05, as examined in [28] for 11 movies predicted by a group
of students. Another example of these prediction markets is

Intrade, founded in 2001 in Ireland which correctly predicted
US presidential elections outcome in 2008 [29] .
However, centralised prediction markets have their own

limitations as they put restriction on global participation and
on the types of markets that can be created or traded. Moreover,
they require traders to trust the market operator who is resolving
the market [30]. These challenges can be overcome through
blockchain technology in an efficient manner.

A. Blockchain Prediction Markets
Blockchain is a trustless decentralised data ledger for storing

transactions performed with cryptocurrencies, such as Bitcoin
and Ethereum (eth), as the medium of exchange. The validity
of these transactions is confirmed through a decentralised
consensus process among the users [31]. Therefore, this removes
the role of intermediaries and since the data contained in each
block can not be altered without being observed, its security
and transparency is ensured.
In prediction markets, blockchain can be applied to record

and verify transactions associated with trades happening in
the market. Gnosis [32], Stox [33], Hivemind [34] and Augur
[35] are examples of platforms for implementing blockchain
hosted prediction markets. While a key challenge in prediction
markets is the question of outcome determination [36], this
issue matters in blockchain-hosted prediction markets as oracle
problem which refers to providing real-word, off-chain data
to blockchain. Game theoretical mechanisms [31] in recent
announced blockchain platforms like Augur where independent
participants can report, dispute and validate the data through a
decentralised set of smart contracts, suggest a robust solution
to this challenge.
In this paper the Augur platform [35] has been considered

as the basis of prediction market design for renewable energy
forecasting. Augur is a set of open source smart contracts that
run on Ethereum blockchain. It allows cryptocurrency users
to create prediction markets or trade contracts associated with
possible outcomes of the events.
The next section is dedicated to explain how this protocol

works based on Augur v1, with the use of information provided
in references [30], [35], where further details can be found.

B. Augur Platform
The lifetime of a prediction market in Augur consists of four

stages: creation, trading, reporting and settlement.
1) Market Creation: A prediction market can be created by

anyone with a small cost according to the amount of gas used
on Ethereum. A market creator in Augur sets an event end
time, a resolution source to be used by reporters to determine
the outcome of the event and a designated reporter to submit
the first public report on the outcome, within three days after
market end-time (which can be disputed by other reporters).

Moreover, the market creator should lock up some capital for
two type of bonds: validity bond and no show bond. Normally,
these bonds would be returned to market creators, but when the
final outcome of the market is invalid, the validity bond would
go to reporters in reporting fee pool, and in the case that the
designated reporter does not return within three days after the



3

market end-time to submit the first report, the no show bond
would be given to the first public reporter.

To earn money, market creators can set a creator fee which
will be collected by them whenever shares are settled.

2) Trading: Augur supports three types of prediction markets
including binary market for events with yes/no outcomes,
categorical markets for events with more than two but not
more than eight possible outcomes and scalar markets with
a wide range of potential outcomes between a lower and an
upper band specified by the market creator.

Market participants forecast the outcomes of events by trading
shares associated with those market outcomes. There is an
order book for every market and orders created by participants
are filled by an automated matching engine that exists within
Augur’s smart contracts.

3) Reporting: Final outcomes of the events are determined by
Augur decentralised oracle mechanism. It consists of a process
during which profit-motivated reporters report the actual final
outcome of the event or dispute others’ reports. Those reporters
whose reports are consistent with consensus are financially
rewarded (by paying them reporters’ fee), while those reporters
whose reports are not consistent with consensus will be at a
loss. Each reporting and disputing round last seven days in
Augur v1. Utilisation of game theoretical incentive mechanism
[31] justify this reporting approach to reach consensus.

4) Settlement: When the final outcome of the event is
specified by reporting process, market will be settled and payoffs
will be distributed among shareholders. Since the value of a
complete set of shares is equal to 1 eth, the amount of payoffs,
depending on the type of market, can be 0, 1 or a fraction of
1 eth per share. Settlement fees (including creator’s fee and
reporters’ fee) are deducted from share holders’ payoffs.

C. Prediction Market Framework for Renewables
While prediction markets can have a broad range of applica-

tions in power systems, in this section we discuss this approach
for renewable energy forecasting and hedging as two specific
use cases.

1) Forecasting: Fig.1 presents a conceptual framework
for implementing a prediction market to forecast different
uncertainties associated with renewables. It should be mentioned
that wind power plant has been selected as a typical renewable
energy source and the idea can simply be generalised to other
renewable sources such as solar power plants.

The market creator of the prediction market can be either a
renewable energy producer or an electric network operator who
may seek more accurate forecasting for different applications
areas. Therefore, they should post appropriate questions in
prediction markets respective to their application areas.

A renewable energy producer may wish to create a prediction
market for participating and bidding in day ahead electricity
market [5], maintenance scheduling [10], specifying potential
areas for investment decisions [37] and making decisions when
they want to buy weather derivatives [38] to hedge against poor
weather conditions.

Electric network operators on the other side, may create
prediction markets to make decisions related to planning and
operation of the overall electric system such as unit commitment,

economic dispatch, capacity reserve requirements and electricity
market clearing [12].
As Fig.1 shows, renewable energy prediction markets in

Augur platform, depending on the applications and respective
questions, can be binary or scalar. For both types of markets,
some examples of questions according to each application area
have been provided in this figure.

As it is depicted in Fig.1, the meaning behind price per share
and payoffs in a binary market would be different from scalar
market in Augur.

In a binary market in Augur, participants speculate the answer
(Yes or No) to the question related to the event with a probability
assessed for it and then trade associated shares with a price
according to probability. For example, price for buying a Yes
share with 50 percent probability would be 0.5 eth. After
market finalisation, holders of the share associated with the
correct answer are considered as winners and payoffs to them
is 1 eth per share (minus settlement fees).

However, in a scalar market, participants can trade two shares,
Long share indicating an increase in the value of outcome and
Short shares indicating a decrease in the value of outcome.
Participants speculate on the outcome of the events somewhere
between the lower and upper bands with its direction (an
increase or decrease) and then trade either Long or Short shares.
A complete set of shares in a scalar market amounts to 1 eth,
like binary markets, but payoffs to each share holder is a fraction
of 1 eth, which is defined linearly based on the final value
of outcome and the distance of the share from the upper and
lower bands.

Depending on whether the intention of market creators is to
obtain final forecasting results or is just to assess potential wind
speed in order to use it as an input data in their own developed
prediction model, forecast variable can be either wind power
or wind speed.

2) Hedging: While forecasting is the most widely used and
best known application of prediction markets, another useful
application would be hedging against undesired events, which
is demonstrated in Fig.2. This can be achieved through buying
the shares associated with the event which would negatively
affect the buyer, as a form of insurance.

While future contracts and weather derivatives already exist
in some exchanges or in bilateral forms and can be used as
a hedging tool for renewable sources, as considered in [39]
for wind power producers, since weather is not a storable and
tradable good, making the standard futures pricing framework
unusable [40], pricing weather derivatives requires forecasting
on underlying weather variable [38]. In prediction markets, on
the other hand, since the price of the shares are associated
with the probability of the event, thus it is a direct result
of forecasting and the issue of pricing derivatives would not
be a problem any more. This is the advantage of hedging
through prediction markets compared to bilateral forms of
derivatives. In the field of renewable energy sources, wind power
producers for example, who can lose money in poor wind speed
conditions, can create a binary market in Augur and then buy
shares indicating that wind speed will be lower than their initial
forecasts. In this way, if this poor wind speed happens, they
will earn money through their payoffs in prediction market and
hence they would be hedged against poor weather conditions.



4

Market Creator

Forecast Variable

W
in

d 
Sp

e
ed

W
in

d 
P

o
w

er

W
in

d
 

Sp
e

ed

W
in

d 
P

o
w

er

 

 Will average wind speed at my 
site be less than 5 m/s in July?

 What will be the average wind 
speed at my site between 7m/s 
and 8 m/s in 2020?

 Will wind speed in Ireland 
exceed 7 m/s in peak hours in 
2020? 

 What will be the wind speed 
in site X tomorrow at 10 a.m. 
between 7 m/s and 8 m/s?

 Will wind power production 
in site X at 6 p.m. tomorrow 
be more than 200 MW?

 Will average wind power at 
my site be less than 90 MW in 
next month?

 What will be average wind 
power at my site tomorrow 
between 100 and 150 MW?

 What will be the wind power  
in site X at 8 p.m tomorrow 
between 300 and 350 MW?

P
ro

d
u

ce
r

O
perator

P
ro

d
u

ce
r

O
perator

P
ro

du
ce

r
O

p
e

ra
to

r
P

ro
du

ce
r

O
p

e
ra

to
r

Market Type

Maintenance Scheduling Investment

Capacity Reserve Planning Unit Commitment 

Buying Weather Derivatives Participate in Electricity Market

Day-ahead Market Clearing Economic Dispatch 

B
IN

A
R

Y
S

C
A

L
A

R

Price
Of

Shares

Yes || No Shares Long || Short Shares

Price
Of

Shares

Probability of the 
Outcome

Direction Towards 
Upper/Lower Bands

Fig. 1. Wind Energy Prediction Market in Augur.

Create

Wind Power 

Producer
Will average wind speed in 
my site be less than 7 m/s?

Yes No

Binary Market

Buy

Hedge Financial Loss 

Through Payoffs

Fig. 2. Wind Power Hedging through Prediction Markets.

D. Case Study

In this section, we attempt to illustrate the financial flexibility
of a typical wind power producer through hedging its monthly
revenues by participating in a blockchain prediction market.
The basic characteristic of the wind farm belonging to this
producer is shown in Table I. By considering the fact that
he aims to maintain his investment profitably, his expected
revenues and consequent payback period is based on a wind
speed of 8 m/s. Therefore, as an example, a wind speed of 7
m/s would affect his revenues as demonstrated in Table II. It
should be noted that in all calculations, eth has been considered
equivalent to 146 Euro. It is worth mentioning that stablecoin
cryptocurrencies, which their value is pegged to fiat money
facilitate less fluctuations in price.
For investigating and evaluating the proposed hedging

strategy for the wind power producer, We consider this binary
prediction market in Augur platform: Will the average wind
speed at site XX be less than 7.5 m/s in May 2020? Settlement
fees for this market are set to 3% totally. The market trading
phase is from 15th to 30th of April 2020. A sample order book
for this prediction market on the first day of trading period is



REFERENCES 5

TABLE I. Assumed Wind Power Producer Characteristics.

Wind Farm Capacity 2.5 mw
Expected Wind Speed 8 m/s
Capacity Factor @ 8 m/s 40%
Turbine Availability 98%
Expected Monthly Energy 729,120 kwh
Energy Selling Price 8 cent.euro/kwh
Expected Revenue 400 eth

TABLE II. Wind Power characteristics in poor wind speed.

Wind Speed 7 m/s
Capacity Factor @ 7 m/s 38%
Monthly Energy 464,031 kwh
Monthly Revenue 254 eth
Amount Required to be Hedged 146 eth

shown in Table III. It is a collection of open orders including
ask (sell) and bid (buy) orders of YES shares indicating their
quantities (Qty) and prices (eth). We consider that wind power
producer estimates a probability of above 60% occurrence of a
wind speed lower than 7.5 m/s and by taking into account a
3% fees, the price per share that he is willing to pay would be
equal or lower than 0.582 eth. Therefore at the beginning of the
trading period, he fills ask orders with the prices lower than this
limit. After one week, on date 22th of April, by approaching
to the event, wind power producer realises that there is more
chance and around 70% probability can be expected for a wind
speed lower than 7.5 m/s in his site. Thus, he places buy orders
for up to 191 shares with a price up to 0.68 eth. Although as it
is obvious from the order book on this day, available in Table
IV, the market is not liquid enough to take the other side of
all his orders and so it is only partially filled with 55 shares.

The cash flow of wind power producer by considering costs
associated with participating in prediction markets (for buying
shares and paying settlement fees) and revenues through selling
electricity in energy market plus payoffs in prediction market
has been shown in Fig.3 over the timeline of the market in
Augur.

As can be inferred from this figure, the gain through this
hedging approach is 95 eth; the difference between net cashflow
after the settlement of the market (349 eth) and expected
revenue from selling energy without hedging it in prediction
market (254 eth). While this hedging tool did not completely
cover the amount required to be hedged (146 eth) due to lack
of enough liquidity in the market, it succeeded to cover 65% of
this amount which is a significant gain for wind power producer.
However, this assumes counterparties were available.
It should be noted that since we aimed to show the effect

of hedging through prediction market, revenues from selling
electricity in periods other than hedging period (May 2020)
have not been shown in Fig.3 as they are irrelevant to the
subject. It is also worth mentioning that this timeline is based
on Augur v1 platform. In Augur v2 [41] trading currency could
be Dai (a cryptocurrency-backed stable coin) and the duration
of designated reporting phase and first reporting window which
are 3 days and 7 days, respectively, in version 1, will be reduced
to 24 hours to resolve the market quicker.

TABLE III. Sample augur order book on 15 April 2020.

Ask Qty Price (eth)
78 0.7
12 0.68
97 0.59
101 0.58
94 0.56
40 0.54
93 0.52

Bid Qty Price (eth)

TABLE IV. Sample augur order book on 22 April 2020.

Ask Qty Price (eth)
9 0.74
11 0.73
23 0.71
77 0.7
55 0.68
191 0.68
15.5 0.65

Bid Qty Price (eth)

15
-A

pr-
20

20

22
-A

pr-
20

20

30
-A

pr-
20

20

31
-M

ay
-2

02
0

03
-J

un-2
02

0

10
-J

un-2
02

0
0

111
148

254

497

E
T

H
Cost
Revenue

349Market event happens

 Market End Time

 Trading Period

Settlement
Designated

reporting

Report

Fig. 3. Wind power producer cash flow during prediction market timeline.

III. Conclusion
A blockchain prediction market for renewable energy sources

forecasting creates an environment where unlimited number
of participants can compete with their predictions in the
market and earn money for correct results in a decentralised
way. Therefore, they have enough motivations in the form
of monetary incentives to provide accurate information and
develop the most efficient prediction models to achieve precise
forecast results. Therefore, a renewable energy producer or the
electric network operator can use the result of these markets for
different purposes. In addition, buying shares associated with
poor condition of underlying weather variable in a prediction
market can be considered as a hedging tool for renewable
energy producer as payoffs in winning situation will compensate
the financial loss for these producers. The flexibility and
decentralised nature of blockchain prediction markets make
them a powerful forecasting tool for renewables. However, the
success of this approach rely on the adequacy of liquidity.
Further works will explore appropriate market mechanisms to
enhance liquidity in prediction markets.

References
[1] “Renewables 2019 global status report.” [Online]. Available:

https://www.ren21.net/reports/global-status-report/.



6

[2] S. Q. Bu, W. Du, H. F. Wang, Z. Chen, L. Y. Xiao, and
H. F. Li, “Probabilistic analysis of small-signal stability of
large-scale power systems as affected by penetration of wind
generation,” IEEE Transactions on Power Systems, vol. 27,
no. 2, pp. 762–770, May 2012.

[3] A. Safdarian, M. Fotuhi-Firuzabad, and F. Aminifar, “Com-
promising wind and solar energies from the power system
adequacy viewpoint,” IEEE Transactions on Power Systems,
vol. 27, no. 4, pp. 2368–2376, Nov. 2012.

[4] K. De Vos, J. Morbee, J. Driesen, and R. Belmans, “Impact of
wind power on sizing and allocation of reserve requirements,”
IET Renewable Power Generation, vol. 7, no. 1, pp. 1–9, Feb.
2013.

[5] A. Fabbri, T. G. S. Roman, J. R. Abbad, and V. H. M. Quezada,
“Assessment of the cost associated with wind generation
prediction errors in a liberalized electricity market,” IEEE
Transactions on Power Systems, vol. 20, no. 3, pp. 1440–1446,
Aug. 2005.

[6] E. M. Garrigle and P. Leahy, “Quantifying the value of
improved wind energy forecasts in a pool-based electricity
market,” Renewable Energy, vol. 80, pp. 517–524, 2015.

[7] C. B. Martinez-Anido, B. Botor, A. R. Florita, C. Draxl, S. Lu,
H. F. Hamann, and B.-M. Hodge, “The value of day-ahead
solar power forecasting improvement,” Solar Energy, vol. 129,
pp. 192–203, 2016.

[8] Q. Wang, H. Wu, A. R. Florita, C. B. Martinez-Anido, and
B.-M. Hodge, “The value of improved wind power forecasting:
Grid flexibility quantification, ramp capability analysis, and
impacts of electricity market operation timescales,” Applied
Energy, vol. 184, pp. 696–713, 2016.

[9] M. Cui, J. Zhang, B. Hodge, S. Lu, and H. F. Hamann, “A
methodology for quantifying reliability benefits from improved
solar power forecasting in multi-timescale power system
operations,” IEEE Transactions on Smart Grid, vol. 9, no. 6,
pp. 6897–6908, Nov. 2018.

[10] A. M. Foley, P. G. Leahy, A. Marvuglia, and E. J. McKeogh,
“Current methods and advances in forecasting of wind power
generation,” Renewable Energy, vol. 37, no. 1, pp. 1–8, 2012.

[11] M. Lei, L. Shiyan, J. Chuanwen, L. Hongling, and Z. Yan,
“A review on the forecasting of wind speed and generated
power,” Renewable and Sustainable Energy Reviews, pp. 1–8,
Sep. 2010.

[12] S. S. Soman, H. Zareipour, O. Malik, and P. Mandal, “A
review of wind power and wind speed forecasting methods with
different time horizons,” in North American Power Symposium
2010, Sep. 2010, pp. 1–8.

[13] M. N. Akhter, S. Mekhilef, H. Mokhlis, and N. Mohamed
Shah, “Review on forecasting of photovoltaic power generation
based on machine learning and metaheuristic techniques,” IET
Renewable Power Generation, vol. 13, no. 7, pp. 1009–1023,
2019.

[14] E. B. Ssekulima, M. B. Anwar, A. Al Hinai, and M. S.
El Moursi, “Wind speed and solar irradiance forecasting
techniques for enhanced renewable energy integration with
the grid: A review,” IET Renewable Power Generation, vol. 10,
no. 7, pp. 885–989, 2016.

[15] Y. Ren, P. Suganthan, and N. Srikanth, “Ensemble methods for
wind and solar power forecasting - a state-of-the-art review,”
Renewable and Sustainable Energy Reviews, vol. 50, pp. 82–91,
2015.

[16] J. Wolfers and E. Zitzewitz, “Prediction markets,” Journal of
Economic Perspectives, vol. 18, no. 2, pp. 107–126, Jun. 2004.

[17] W. Chen, X. Li, and D. D. Zeng, “Simple is beautiful: Toward
light prediction markets,” IEEE Intelligent Systems, vol. 30,
no. 3, pp. 76–80, May 2015.

[18] K. J. Arrow, R. Forsythe, M. Gorham, and et al, “The promise
of prediction markets,” Science, vol. 320, no. 5878, pp. 877–
878, 2008.

[19] J. E. Berg, F. D. Nelson, and T. A. Rietz, “Prediction market
accuracy in the long run,” International Journal of Forecasting,
vol. 24, no. 2, pp. 285–300, 2008.

[20] E. Franck, E. Verbeek, and S. Nuesch, “Prediction accuracy
of different market structures - bookmakers versus a betting
exchange,” International Journal of Forecasting, vol. 26, no. 3,
pp. 448–459, 2010.

[21] M. Spann and B. Skiera, “Sports forecasting: A comparison
of the forecast accuracy of prediction markets, betting odds
and tipsters,” Journal of Forecasting, vol. 28, no. 1, pp. 55–72,
2009.

[22] A. Bassamboo, R. Cui, and A. Moreno, “The wisdom of crowds
in operations: Forecasting using prediction markets,” SSRN
E";"""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.4""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""7""
""resourceName"",""Submitted%20Towards%20the%20Use%20of%20Blockchain%20Prediction%20Markets%20for%20Forecasting%20Renewables.pdf""
""language"",""en""
""pdf:hasXMP"",""false""
""dc:format"",""application/pdf; version=1.4""
""pdf:charsPerPage"",""1330"",""5001"",""5513"",""5588"",""2289"",""3988"",""5740""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""Content-Length"",""800694""
""access_permission:can_modify"",""true""
""pdf:hasMarkedContent"",""false""
""Content-Type"",""application/pdf""
";https://scholar.google.ch/scholar?start=580&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098826-246;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Tight security for the generic construction of identity-based signature (in the multi-instance setting);Y Lee, JH Park, K Lee, DH Lee ; Theoretical Computer Science, 2020  Elsevier;;"… in the multi-user setting with corruption, recently proposed by Gjřsteen and Jager (CRYPTO 2018).

As a result, we can obtain the first efficient and tightly secure IBS schemes (in the multi-instance

setting) based on the Diffie–Hellman assumptions in the random oracle model …";Autres articles;;null;;;;https://scholar.google.ch/scholar?start=790&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098888-387;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;[PDF][PDF] Perspektische Einsatzmöglichkeiten einer Blockchain in einer Landkreisverwaltung;M Junker ; opus.bszbw.de;;"… Die Bedingungen aus der Realität werden als Oracle bezeichnet, deshalb spricht man bei

Problemen mit der Korrektheit dieser von einem Oracle-Problem.45 2.11 Zusammenfassung

Eine Blockchain ist eine verteilte Datenbank, die auf mehreren Computern in einem …";;;[PDF] bsz-bw.de;https://opus.bsz-bw.de/hsf/files/1141/Junker_Marc-Bachelorarbeit.pdf;"
Perspektivische EinsatzmĂśglichkeiten einer Blockchain
in einer Landkreisverwaltung

B a c h e l o r a r b e i t
an der Hochschule fĂźr Ăśffentliche Verwaltung und Rechtspflege (FH),

Fortbildungszentrum des Freistaates Sachsen
zum Erwerb des Hochschulgrades

Bachelor of Laws (LL.B.)

Vorgelegt von
Marc Junker

aus Lengenfeld

Meißen, 23.03.2020



Inhaltsverzeichnis

Abbildungsverzeichnis...................................................................................................3

AbkĂźrzungsverzeichnis..................................................................................................3

1 Einleitung....................................................................................................................4

2 Technische Grundlagen..............................................................................................6

2.1 Allgemein.................................................................................................................6

2.2 Kryptografische Grundlagen und asymmetrische VerschlĂźsselung..........................7

2.3 Hashwert und Hashfunktion.....................................................................................8

2.4 Verwendung der Blockchain in Kryptowährungen....................................................9

2.4.1 Blockerstellung....................................................................................................10

2.4.2 Blockstruktur und Berechnung des Hash-Wertes................................................10

2.5 Miningprozess........................................................................................................12

2.6 Proof of Work.........................................................................................................12

2.7 Proof of Stake........................................................................................................15

2.8 Smart Contracts.....................................................................................................15

2.9 Ausprägungen........................................................................................................16

2.9.1 Public/Private......................................................................................................16

2.9.2 Permissioned und Permissionless.......................................................................17

2.10 Oracle Problem....................................................................................................17

2.11 Zusammenfassung...............................................................................................17

3 Projekte in Deutschland............................................................................................18

3.1 Strategiepapier Bundesregierung...........................................................................18

3.2 Koordinierungsprojekt Blockchain des IT-Planungrates.........................................19

3.3 Blockchain Competence Center Mittweida.............................................................20

4 Aktueller Einsatz.......................................................................................................20

4.1 „Krypto-Valley“ Kanton Zug (Schweiz)...................................................................21

4.2 E-residency (Estland).............................................................................................23

4.3 Blockchain-basiertes Grundbuch in Schweden......................................................23

5 Hyperledger..............................................................................................................24

6 ZukĂźnftige EinsatzmĂśglichkeiten in einer Landkreisverwaltung.................................25

6.1 Digitale Identitäten und Fßhrerscheine...................................................................25

6.2 Grundbßcher und Eigentumsverhältnisse..............................................................31

6.3 Wahlen...................................................................................................................33

6.4 Kontrolle der KĂźhlkette mittels Blockchain..............................................................37

6.4.1 Technische Umsetzung mittels IBM Food Trust..................................................39

6.4.2 Technische Umsetzung mittels Seafood Supply Chain.......................................39

6.4.3 Technische Umsetzung mittels TradeLens..........................................................40

6.5 Bezahlung von Verwaltungsdienstleistungen mit Kryptowährungen.......................41

7 Fazit .........................................................................................................................43

Kernsätze.....................................................................................................................47

Literaturverzeichnis......................................................................................................48

Internetquellenverzeichnis...........................................................................................50

Eidesstattliche Versicherung........................................................................................54

2



Abbildungsverzeichnis

Abbildung 1: Kollision einer Hashfunktion....................................................................10
Abbildung 2: Hashbaum...............................................................................................12

AbkĂźrzungsverzeichnis

Abkßrzung Erläuterung

BAMF Bundesamt fĂźr Migration und FlĂźchtlinge

BCCM Blockchain Competence Center Mittweida

BMBF Bundesministerium fĂźr Bildung und Forschung

IoT Internet of Things (dt. Internet der Dinge, steht u. a. fĂźr die Ver-
netzung von Gegenständen)

NFC Near Field Communication

PBFT Practical-Byzantine-Fault-Tolerance

RBFT Redundant-Byzantine-Fault-Tolerance

SSI Self Sovereign Identity (dt. Selbstsouveräne Identität)

ZFER Zentrales Fahrerlaubnisregister

3



1 Einleitung

Die Digitalisierung hält  im Jahr 2020 in alle Bereiche des gesellschaftlichen Lebens

Einzug. Dabei kommen immer neue Technologien zum Einsatz, deren Verwendung zu-

meist zu Zeitersparnis und Effizienzsteigerung fĂźhren kann, aber auch zu Problemen.

Vor allem mangelnder Datenschutz spielt  dabei eine erhebliche Rolle.  Dabei ist  die

Nutzung von Daten fßr personalisierte Werbung bereits in vollem Gange. Zusätzlich

geht auch die Angst vor Überwachung durch Staat oder Unternehmen in der Bevölke-

rung um. Auch die elektronische Abwicklung des Zahlungsverkehrs trägt zu dieser Sor-

ge bei. Als MÜglichkeit zur Anonymisierung von Zahlungen werden oftmals Kryptowäh-

rungen ins Spiel gebracht. Datenschutz und Anonymität wird bei dieser Art Währung

teils fälschlicherweise als gegeben betrachtet, in der allgemeinen Wahrnehmung die-

nen diese Währungen (allen voran Bitcoin) in erster Linie dazu, Drogen und Waffen-

handel ßber versteckte Online-Marktplätze abzuwickeln. Aber spätestens seit den ex-

tremen Kursschwankungen und dem Rekordhoch von Bitcoin Ende 2017 ist die Kryp-

towährung in aller Munde1.  Doch was steckt eigentlich hinter den Kryptowährungen,

und kĂśnnte diese Technologie nicht auch fĂźr andere Anwendungen eingesetzt werden?

Die Technologie hinter den Kryptowährungen ist die sog. Blockchain, eine Distributed-

Ledger-Technologie  (dt.  „Verteilte-Datenbanken-Technologie).  Erste  Grundlagen  zu

dieser Technologie wurden Ende der 1990er Jahre entwickelt2. Der große Durchbruch

gelang dieser Technologie aber erst im Jahr 2008, als eine Person unter dem Pseud-

onym Satoshi Nakamoto via E-Mail verkĂźndete, an einem neuen elektronischen Geld-

system zu arbeiten,  welches ohne eine vertrauenswĂźrdige dritte Partei  auskomme3.

Die aktuell wohl bekannteste Kryptowährung Bitcoin war geboren. Es existieren jedoch

auch weitere AnwendungsmĂśglichkeiten dieser Technologie, deren konkrete Funktio-

nalität von Nakamoto fßr die Währung Bitcoin in einem Whitepaper konkretisiert wurde.

Durch eine Reihe von Eigenschaften und Funktionalitäten bietet sich auch eine Ver-

wendung in der Ăśffentlichen Verwaltung an, welche die Bundesregierung in ihrem Stra-

tegiepapier zum Thema Blockchain teilweise aufgreift. Demnach sollen u. a. digitalisier-

te Verwaltungsdienstleistungen bereitgestellt werden, z. B. digitale Identitäten von Per-

sonen.

In dieser Arbeit sollen neben den technischen Grundlagen und Funktionsweisen auch

EinsatzmĂśglichkeiten in der Verwaltung allgemein aufgezeigt werden. Um den aktuel-

len Stand der Entwicklung und Etablierung dieser Technologie in Deutschland sichtbar

1Vgl. https://www.faz.net/aktuell/finanzen/digital-bezahlen/kryptowaehrung-bitcoin-kurs-bricht-um-mehr-als-
1000-dollar-ein-16402059.html (zuletzt geĂśffnet am 08.01.2020).
2 Z. B. die Arbeit zum Thema: „Sichere Log-Dateien auf Grundlage kryptographisch verketteter Einträge“, 
abrufbar unter http://www.konst.de/stefan/seclog.pdf (zuletzt geĂśffnet am 03.02.2020).
3 Vgl. https://www.mail-archive.com/cryptography@metzdowd.com/msg09959.html (zuletzt geĂśffnet am 
04.02.2020).

4

https://www.mail-archive.com/cryptography@metzdowd.com/msg09959.html
http://www.konst.de/stefan/seclog.pdf
https://www.faz.net/aktuell/finanzen/digital-bezahlen/kryptowaehrung-bitcoin-kurs-bricht-um-mehr-als-1000-dollar-ein-16402059.html
https://www.faz.net/aktuell/finanzen/digital-bezahlen/kryptowaehrung-bitcoin-kurs-bricht-um-mehr-als-1000-dollar-ein-16402059.html


zu machen, wird auch auf Projekte in Deutschland eingegangen, aus denen beispiels-

weise hervorgeht, dass die Forschung an der Blockchain auch von staatlicher Seite

aus eine Rolle spielen soll. Es werden auch Anwendungen aus anderen Ländern auf-

gefßhrt, in denen die Digitalisierung der Üffentlichen Verwaltung stärker fortgeschritten

ist als in Deutschland. Nach Betrachtung dieser soll eine Ableitung zu potenziellen Ver-

wendungen auf Verwaltungsebene der Landkreise erfolgen und auf die mĂśgliche tech-

nische Umsetzung eingegangen werden. Dabei wird auch ein Augenmerk darauf ge-

legt, ob die Blockchain-basierte LĂśsung gegenĂźber der bestehenden LĂśsung Verbes-

serungspotenzial mit sich bringt, da nur dann der Mehraufwand fĂźr Entwicklung und

Unterhaltung einer solchen LÜsung gerechtfertigt wäre.

5



2 Technische Grundlagen

Bevor jedoch auf AnwendungsmÜglichkeiten sowie -beispiele näher eingegangen wird,

werden zunächst die technischen Grundlagen betrachtet.

2.1 Allgemein

In der Informationstechnik gibt es den Byzantinischen Fehler (auch genannt Problem

der byzantinischen Generäle). Dieser beschreibt den Umgang mit Falschinformationen

durch zuverlässige Computersysteme, ausgedrßckt durch die abstrakte Situation der

Belagerung einer Stadt durch mehrere Generäle, die sich untereinander nicht vertrau-

en. Um die Stadt einzunehmen, mßssen sich die Generäle auf einen Schlachtplan eini-

gen.  Die  Kommunikation  erfolgt  ausschließlich  über  Boten.  Um Manipulationen des

Schlachtplans  durch einzelne Generäle zu vermeiden,  kommen letztendlich  nur fäl-

schungssichere schriftliche Boten als Mittel der sicheren Kommunikation in Frage, da

bei Verwendung mßndlicher Botschaften bereits ein Anteil  von einem Drittel verräte-

rischer Generäle ausreicht, um den Schlachtplan zunichte zu machen und alle Generä-

le zu verwirren. Bei dieser ProblemlĂśsung handelt es sich um einen Konsensalgorith-

mus, wie er bei einer Blockchain zur Anwendung kommt, auch wenn dieser Algorith-

mus eigentlich fĂźr die Netzwerktechnik entwickelt wurde.4

Eine Blockchain benutzt demzufolge einen Konsensalgorithmus, um Manipulationssi-

cherheit zu gewährleisten. Die Daten allerdings werden weiterhin in einer Datenbank

gespeichert, wenn auch dezentral. Eine Blockchain ist somit eine Kombination aus ei-

ner dezentralen Datenbank und einem Konsensalgorithmus5. Eine umfassendere Defi-

nition gibt Julian Hosp: „Eine Blockchain ist eine digitale Datei, in der dieselbe Informa-

tion von allen Mitgliedern einer Gesellschaft abgespeichert und Updates in regelmäßi-

gen ZeitblÜcken an die bereits bestehende Information gehängt werden, sodass jeder

Teilnehmer  die  gesamte  Information  besitzt  und  sich  nicht  auf  andere  verlassen

muss“6. Da die Technologie der Blockchain außerhalb der Kryptowährungen noch am

Anfang ihrer  Entwicklung steht,  hat  sich noch keine einheitliche Definition  durchge-

setzt7. Es muss aber zwischen der Blockchain als Datei und zwischen dem zugrunde

liegenden  System einer  Netzwerkstruktur  aus mehreren Teilnehmern unterschieden

werden8. Die Blockchain als Datei an sich wird oft als eine Art Datenbank bezeichnet,

in der die einzelnen Datensätze in BlÜcke gruppiert werden, die dann mittels kryptogra-

4Vgl. Lamport, Shostak, Pease (1982, S. 383 ff.).
5Vgl. Meier, Stormer (2018, S. 1141).
6Hosp (2018, S. 42).
7Vgl. Swan (2015).
8Vgl. Schlatt et al. (2016, S.8).

6



fischer Signatur in bestimmter Reihenfolge miteinander verknĂźpft werden9. Diese Da-

tenbank kann jeder der Teilnehmer in einem Netzwerk einsehen und ergänzen, aber

nachträglich nicht mehr abändern. Außerdem wird eine zentrale Autorität im Netzwerk

vermieden, alle Teilnehmer sind gleichberechtigt und verifizieren die Ergänzungen der

Datenbank10.

Zusammenfassend lässt sich festhalten: Eine Blockchain ist eine verteilte Datenbank,

welche von mehreren Teilnehmern eines Netzwerks identisch gespeichert und regel-

mäßig aktualisiert wird. Die Einträge in der Datenbank bestehen dabei jeweils aus Blö-

cken, bei denen der nachfolgende Block den kryptografisch verschlĂźsselten vorange-

gangen Block enthält  (Verkettung).  Ein Ausfall  eines Netzwerkteilnehmers behindert

nicht die Abläufe im Netzwerk. Der Konsensalgorithmus stellt sicher, dass die Inhalte

der Datenbank von allen Teilnehmern verifiziert, also auf Richtigkeit ĂźberprĂźft werden.

Nachträgliche Änderungen der Inhalte sind nur mit extrem großen Aufwand möglich, da

bei allen Netzwerkteilnehmern die gesamte Datenbank gleichzeitig geändert werden

mĂźsste, da durch kryptografische Verkettung jeder Eintrag (Block) auf dem vorherge-

henden basiert.

2.2 Kryptografische Grundlagen und asymmetrische VerschlĂźsselung

Kryptografie bedeutet in etwa die Lehre vom Geheimen Schreiben. Es geht darum, ei-

nen Text (Klartext), der vom Sender verfasst wurde, in eine Form zu bringen, die fĂźr

Dritte nur eine unverständliche Zeichenfolge darstellt (Chiffretext). Nur der Empfänger

kann den Chiffretext mittels eines Schlßssels wieder in eine verständliche Form brin-

gen. Die VerschlĂźsselung von Klartext in Chiffretext nennt man chiffrieren, die Entsch-

lĂźsselung dechiffrieren. Der SchlĂźssel ist dabei das Regelwerk bzw. der Informations-

träger, welches die Regeln fßr die Verschlßsselung bestimmt.11

Von einer symmetrischen VerschlĂźsselung spricht man, wenn zum Chiffrieren und zum

Dechiffrieren derselbe SchĂźssel (Key) zum Einsatz kommt oder wenn sich ein SchlĂźs-

sel leicht aus einem anderen berechnen lässt. Dabei ist die Übertragung des Schlüs-

sels  kritisch,  diese  muss Ăźber  einen  sicheren Weg erfolgen,  da  ein  Abfangen  des

SchlĂźssels durch Dritte eine VerschlĂźsselung obsolet machen wĂźrde.12

Bei der sog. Public-Key-VerschlĂźsselung oder auch asymmetrischen VerschlĂźsselung

(1976 von Diffie und Hellman13 entwickelt) existieren zwei unterschiedliche SchlĂźssel

fĂźr jeden Benutzer, ein privater SchlĂźssel und ein Ăśffentlicher SchlĂźssel. Der Ăśffentliche

9Vgl. Walport (2015, S.17).
10Vgl. Glaser, Bezzenberger (2015, S.8 ff.).
11Vgl. Wätjen (2018, S. 1 f.).
12Vgl. Wätjen (2018, S. 4).
13In New Directions in Cryptography. IEEE Trans. on Info. Theory IT-22 (1976), 644–654.

7



SchlĂźssel (Public Key) wird aus dem privaten SchlĂźssel (Private Key) berechnet; eine

Umkehrung dieser Rechenoperation ist nicht mĂśglich. Die verschlĂźsselte Kommunikati-

on beruht auf dem Austausch der Public Keys. Der Sender verschlĂźsselt den Klartext

der Nachricht mithilfe des Üffentlichen Schlßssels des Empfängers, somit kann nur die-

ser die Nachricht mittels seines eigenen Private Key dechiffrieren. Dieser Vorgang ist

auch unter umgekehrter Verwendung der SchlĂźssel mĂśglich, allerdings unter dem As-

pekt der Geheimhaltung des Nachrichtentextes sinnlos, da jeder mit Kenntnis des Pu-

blic Key die Nachricht dechiffrieren kĂśnnte. Der Private Key muss sicher und vor Zugrif-

fen Dritter geschĂźtzt aufbewahrt werden. Eine sichere Kommunikation zwischen Sen-

der und Empfänger ist gewährleistet. Eine weitere AnwendungsmÜglichkeit des Public-

Key-Verfahrens sind digitale Signaturen. Diese dienen dem Nachweis der Authentizität

einer Nachricht, d.h. der Sender einer Nachricht ist dadurch verifizierbar. Dazu muss

der Sender die Nachricht mit seinem Private Key verschlĂźsseln (ohne das dieser verĂśf-

fentlicht wird). Wird die Nachricht dann mit dem Public Key des vermeintlichen Versen-

ders entschlĂźsselt, so muss sich ein sinnvoller Klartext ergeben, ansonsten stammt die

Nachricht nicht vom entsprechenden Absender. Die Identität des Versenders kann mit

diesem Verfahren bestätigt werden.14

2.3 Hashwert und Hashfunktion

Ebenso von Bedeutung fĂźr eine Blockchain sind kryptografische Hashfunktionen. Has-

hen (engl.) bedeutet dabei in etwa soviel wie „zerhacken“. Dabei sollen Kollisionen (s.

Abbildung 1) verhindert werden. Mittels einer Hashfunktion wird eine PrĂźfsumme bzw.

Zusammenfassung von fester Länge (z.B: 256 Bit) fßr einen Ausgangstext von beliebi-

ger Länge erzeugt.  Es ist  praktisch unmÜglich,  aus der Prßfsumme (Hashwert) den

Ausgangstext zu berechnen, da dieser Hashwert eine nahezu eindeutige Kennzeich-

nung des Ausgangstextes darstellen soll.  Ebenso soll  es unmĂśglich sein zwei  Aus-

gangstexte zu finden, die den selben Hashwert besitzen sowie aus einem Text samt

Hashwert einen zweiten Text zu ermitteln, welcher den selben Hashwert ergibt. Wer-

den diese beiden Bedingungen erfĂźllt, gilt die Hashfunktion als kollisionsfrei. Bei der

Verwendung digitaler Signaturen wird im Regelfall auch nur die PrĂźfsumme mit dem

Private Key des Senders verschlĂźsselt, da eine VerschlĂźsselung der gesamten Nach-

richt sehr zeitintensiv ist. Anschließend wird mittels derselben Hashfunktion ein Hash-

wert aus der Nachricht gebildet und mit dem zuvor durch den Ăśffentlichen SchlĂźssel

des Senders dechiffrierten Hashwert verglichen Bei Übereinstimmung ist die Authenti-

zität des Absenders gewährleistet15. Die Aussagen beziehen sich auf einen klassischen

14Vgl. Wätjen (2018, S. 75 ff.).
15Vgl. Meier, Stormer (2018, S. 1143).

8



Computer, die MÜglichkeiten eines funktionsfähigen Quantencomputers werden dabei

außer Acht gelassen.16

Abbildung 1: Kollision einer Hashfunktion17

2.4 Verwendung der Blockchain in Kryptowährungen

Um die Funktionsweise einer Blockchain beispielhaft zu erläutern, soll im Folgenden

die populärste Kryptowährung Bitcoin herangezogen werden. Mit Bitcoin sollte ein elek-

tronisches Peer-to-peer-Währungssystem geschaffen werden, das Geldtransaktionen

ohne eine dritte Partei (z. B. eine Bank) ermĂśglichet.

Ein Peer-to-peer-System (P2P-System) ist eine dezentrale Netzwerkarchitektur, bei der

alle Knoten bzw. Teilnehmer (Peers) am Netzwerk direkt miteinander kommunizieren

(ohne Umleitung Ăźber einen Server). Die Peers kommunizieren symmetrisch miteinan-

der und kĂśnnen auch gemeinsam Daten nutzen. Diese Daten mĂźssen redundant auf

allen Peers im Netzwerk gespeichert werden, um bei Abwesenheit eines Peers weiter-

hin Vollständigkeit der Daten im Netzwerk zu gewährleisten. Da kein Server im Netz-

werk vorhanden ist, mĂźssen die Peers auch Infrastrukturaufgaben (z. B. Adresszuwei-

sung) eigenständig wahrnehmen.18

Den Grundstein fßr die Entwicklung der Kryptowährung legte der Entwickler mit dem

Pseudonym Satoshi Nakamoto mit seinem Artikel „Bitcoin: A Peer-to-Peer Electronic

Cash System“. Dabei soll das Vertrauen, dass bei Geldtransaktionen in einen Dritten

(in diesem Fall die Bank) vorhanden sein muss, durch kryptografische Beweise ersetzt

werden. Eine Geldeinheit (sog. Bitcoin, kurz BTC) ist eine Aneinanderreihung von elek-

16Vgl. Wätjen (2018, S. 93 ff.).
17In Anlehnung an Jorge Stolfi.
18Vgl. Dunkel et al. (2008, S. 142 ff.).

9

Haus

Baum

Straße

Garage

Hashfunktion

..

20

21

22

23

..

Ausgangstext Hashwerte

Kollision



tronischen Signaturen. Diese Signaturen stellen die Transaktionen dar, fĂźr welche der

Bitcoin verwendet wurde. Demzufolge gibt es auch keine Kontostände, es wird lediglich

die Summe aus den Transaktionen gebildet,  um nachzuweisen, dass eine Ausgabe

von vorhandenen Bitcoins mĂśglich ist. Anweisungen von Transaktionen werden mittels

den oben genannten VerschlĂźsselungsprinzipien authentifiziert. Eine Anweisung zu ei-

ner Transaktion wird im Netzwerk Ăśffentlich gemacht und mit dem Private Key des An-

weisungsgebers signiert. So ist die Authentizität der Anweisung sichergestellt, da nie-

mand, der nicht den privaten SchlĂźssel des Anweisungsgebers besitzt, die Anweisung

signieren kann. Die Herkunft der Anweisung kann mit dem Ăśffentlichen SchlĂźssel durch

jeden Peer ßberprßft werden. Empfänger und Absender werden nur durch die Hash-

werte der jeweiligen Ăśffentlichen SchlĂźssel identifiziert (im Prinzip Kontonummern bei

herkÜmmlichen Währungssystemen). Will der Empfänger wiederum die erhaltenen Bit-

coins weiterverwenden, verĂśffentlicht er nun ebenfalls eine signierte Anweisung, die

zusätzlich noch enthält, dass die Bitcoins vorher erhalten wurden.19

2.4.1 Blockerstellung

Diese Transaktionen werden in regelmäßigen Zeitabständen in einem Block zusam-

mengefasst. Dabei enthält jeder neue Block den Hashwert des vorangegangen Blocks.

Dadurch kann eine Änderung der Blockinhalte durch Unbefugte im Nachhinein verhin-

dert werden. Um die Funktion des Netzwerks zu gewährleisten, muss die regelmäßige

Erstellung  neuer  BlÜcke gewährleistet  sein.  Deshalb  werden Bitcoins  an diejenigen

Peers ausbezahlt,  die Ressourcen fĂźr die Erstellung neuer BlĂścke bereitstellen. Nur

mittels  des Ăśffentlichen SchlĂźssels  ĂźberprĂźfte Transaktionen werden in  einen Block

aufgenommen. Ein Block enthält also den Hashwert des Vorgängerblocks sowie eine

bestimmte Anzahl an Transaktionen. Dieser Block wird nun von anderen Peers Ăźber-

prĂźft und bei Korrektheit in die knoteneigene Kopie der Blockchain aufgenommen. An-

schließend werden die neuen folgenden Transaktionen wiederum in einen neuen Block

zusammengefasst. Die beschriebenen Vorgänge werden auch als Mining20 bezeichnet

und sichern die Akzeptanz der BlĂścke und somit auch der Transaktionen durch das ge-

samte Netzwerk ab.21

2.4.2 Blockstruktur und Berechnung des Hash-Wertes

Ein Block in einer Blockchain besteht aus dem Block-Header und einem Hashbaum.

Ein Hashbaum ist ein Baum aus den Hashwerten von Datensätzen einer Datei, dieser

wurde von Ralph Merkle entwickelt und trägt deshalb auch den Namen Merkle Tree.

19Vgl. BĂśhme et al. (2015, S. 215 ff.).
20Auf den Miningprozess wird in Abschnitt 2.5 noch näher eingegangen.
21Vgl. BĂśhme et al. (2015, S. 215 ff.).

10



Bei der Bitcoin-Blockchain werden beispielsweise die Transaktionen 0 und 1 gehasht

(es wird also die Hashfunktion berechnet), die jeweils Hash 0 und Hash 1 ergeben (sie-

he Abbildung). Um nun Hash 01 zu erhalten, werden die beiden Hashwerte 0 und 1 zu-

sammen nochmals gehasht. Die Hashfunktion aus Hashwert 01 und Hashwert 23 er-

gibt den Root-Hash, der Teil des Block-Headers ist. Ebenfalls im Block-Header zu fin-

den ist der Hashwert des Vorgänger-Blocks. Dies stellt sicher, dass Blockinhalte in ei-

nem Block nicht mehr geändert werden kÜnnen, ohne alle vorhergehenden BlÜcke zu

ändern. Der Zeitstempel ist auch Teil des Block-Headers und gibt den Zeitpunkt der

Block-Erstellung an. Im Header wird auch ein Schwierigkeitsgrad aufgefĂźhrt, der an-

gibt, wie klein ein gĂźltiger Hashwert sein muss. Dies wird realisiert, in dem die Anzahl

Nullen,  die am Anfang des Hashwertes stehen muss, festgelegt  wird.  Des weiteren

existiert noch eine Nonce (Number used once). Diese muss per Zufallsverfahren varia-

bel geändert werden, um einen gßltigen Hashwert zu finden, der mit der vorgeschriebe-

nen Anzahl an Nullen beginnt. Der Hashwert eines Blockes muss aus allen aufgefĂźhr-

ten Inhalten berechnet werden.22 

Ein Block-Header könnte also folgendermaßen Aussehen: 

Hashwert 0000000000000000000a3e370954c035e
e4f234fed9fcd34663b2611618c7115

Root-Hash c7972e-
ca48b63083532287a45003f857107e6cd-
d42572455c536b6419f8cf101

Hashwert des Vorgänger-Blocks (Prev 
Hash)

0000000000000000000304ba1531985e9
e53c80dc5f1636a3291ce54aedab47a

Zeitstempel 2020-02-12 17:50

Schwierigkeit Vereinfacht: Die ersten 19 Stellen des 
Hashwertes mĂźssen 0 sein.

Nonce 314.867.287

22Vgl. Meier, Stormer (2018, S. 1144 ff.).

11



Abbildung 2: Hashbaum23

2.5 Miningprozess

Das Erstellen neuer BlĂścke ist zwingend notwendig fĂźr die Funktion einer Blockchain.

Auch ist es durch die verteilte Topologie des Peer-to-Peer-Netzwerkes und der daraus

resultierenden DatenĂźbertragungsgeschwindigkeit notwendig, die Erstellung neuer BlĂś-

cke soweit zu verzĂśgern, bis die Daten Ăźber neue Transaktionen bei allen Peers ange-

kommen sind. Dieses Problem kann durch einen Proof-of-Work (dt. Arbeitsnachweis)

gelĂśst werden.

2.6 Proof of Work

Der Proof-of-Work stellt in der Bitcoin-Blockchain das Finden der Nonce24 dar, um die

vorgeschriebene Größe des Hashwertes (Schwierigkeit)  nicht zu überschreiten. Das

Problem der Ermittlung einer gßltigen Nonce lässt sich nur durch Ausprobieren ver-

schiedener zufälliger Werte für die Nonce und dem anschließenden Berechnen des je-

weiligen Hashwertes lösen,  bis ein solcher Hashwert die vorgegebene Höchstgröße

unterschreitet. Dies erfordert je nach Schwierigkeit einen erheblichen Rechenaufwand,

der durch die dafür benötigte Zeit die Übertragung der Daten an alle Peers im Netz-

werk sichert und lĂśst somit das Problem der Netzwerkgeschwindigkeit. Durch die stei-

gende Rechenleistung im Bitcoin-Netzwerk wird die Schwierigkeit kontinuierlich erhĂśht,

damit im Schnitt nur alle zehn Minuten ein gĂźltiger Hashwert gefunden wird. Die Be-

rechnungen werden in der Regel von allen Peers im Netzwerk ausgefĂźhrt. Um die kon-

23Entnommen aus: Nakamoto (2008, S.4).
24Siehe Abschnitt 2.4.2

12



tinuierliche Erstellung neuer BlÜcke zu gewährleisten und einen Anreiz zu schaffen,

sich als Peer am Netzwerk zu beteiligen, erhält ein Knoten, der als erstes einen gßlti-

gen Wert findet, eine Belohnung. Dies geschieht dadurch, dass in einen Block eine

Transaktion aufgenommen wird, bei welcher der Knoten selbst neue Bitcoins in vorge-

gebener HÜhe an sich ßberträgt, diese sozusagen generiert. Ein neuer Block wird an-

schließend  an  andere  Netzwerkteilnehmer  gesendet  und von diesen  überprüft.  Die

Überprüfung besteht aus dem Ermitteln des Hashwertes des Blocks unter Verwendung

der vom jeweiligen Peer vorgeschlagenen Nonce. Stimmen die Hashwerte Ăźberein und

überschreitet der Block die Höchstgröße nicht, nimmt jeder Peer den Block in seine ei-

gene Blockchain-Kopie auf und speichert diesen ab.25

Zusätzlich zur o. g. Kontrolle der Authentizität des Anweisungsgebers werden durch

die Peers weitere Überprüfungen der in einem Block enthaltenen Transaktionen durch-

gefĂźhrt. Unter anderem wird ĂźberprĂźft, ob der Absender bei einer Transaktion die ent-

sprechende Menge Bitcoins vorher erhalten hat, ob die HĂśhe der Belohnung fĂźr das

Ermitteln eines korrekten Hashwertes mit den Vorgaben Ăźbereinstimmt. Erst wenn der

Block  durch die  Peers  vollständig  verifiziert  ist,  wird  dieser  in  die  lokale  Kopie  der

Blockchain Ăźbernommen.26

Ein Problem, welches in einer Blockchain durch den Proof-of-Work-Mechanismus ge-

lĂśst wird, ist das sog. Double-Spending-Problem. Dieses tritt auf, wenn ein berechtigter

Anweisungsgeber  zwei  Transaktionen  zeitgleich  bekanntgibt,  die  sich  auf  dasselbe

Guthaben an Bitcoins bezieht. Angenommen, die Nachrichten Ăźber die Transaktionen

verbreiten sich so ungĂźnstig im Netzwerk, das ein Knoten die Nachricht Ăźber die erste

Transaktion erhält, während ein zweiter Knoten die Nachricht ßber die zweite Transak-

tion zuerst  erhält.  Da die  Transaktionen vom berechtigten Teilnehmer  verÜffentlicht

wurden, stellen die Knoten bei der Überprüfung der jeweiligen Nachrichten keine Un-

gĂźltigkeit fest. Jeder dieser Knoten nimmt nun die jeweils erhaltene Transaktionen in

seinen Block auf und beginnt mit dem Suchen der Nonce. Wird diese von einem Kno-

ten gefunden, sendet er seinen erstellten Block an alle anderen Teilnehmer im Netz-

werk, die diesen nun ßberprßfen. Da dieser keine Fehler enthält, wird dieser von den

Knoten in ihre Blockchain-Kopie aufgenommen, auch von jenem Knoten, der die ande-

re Transaktion erhalten hat und seinen Block (der eben diese zweite Transaktion ent-

hält) verwirft. Wird die zweite Transaktion, die sich (noch) nicht in einem Block befindet,

nun von einem Knoten wieder aufgenommen und in einen neuen Block integriert, stellt

dieser Knoten fest, dass der Anweisungsgeber nicht mehr Ăźber die entsprechenden

25Vgl. Berentsen, Schär (2017, S. 54 ff.).
26Vgl. ebenda (S. 205).

13



Bitcoins verfĂźgt und nimmt diese Transaktion nicht in seinen Block auf, da er somit ri-

skiert, dass die anderen Peers seinen Block nicht akzeptieren und er seine Belohnung

nicht erhält. Somit ist dieses Problem mittels einer Blockchain gelÜst.27

Eine weitere Vereinbarung der Knoten untereinander zur Erreichung eines Konsensus

ist, dass die Peers nur die längste Blockkette als gßltig akzeptieren28. Ein Angreifer, der

eine Transaktion in einem weiter  zurßckliegenden Block zu seinen Gunsten ändern

mÜchte, mßsste zunächst den Hashwert von diesem Block und allen Folgenden neu

berechnen (unter BerĂźcksichtigung der entsprechenden Transaktion). Dabei mĂźsste er

die Geschwindigkeit  der Erstellung neuer BlĂścke,  die das gesamte Netzwerk bereit

stellt, ßbertreffen, um im Laufe der Zeit eine längere Kette zu berechnen, die dann von

den anderen Knoten akzeptiert wird. Ein Angriff auf die Blockchain wäre also nur mÜg-

lich, wenn der potenzielle Angreifer mehr als die Hälfte der Rechenleistung aller Peers

zur VerfĂźgung hat oder genĂźgend Peers kontrolliert29. Dieser Weg eines potenziellen

Angriffs wird durch den Arbeitsnachweis, der bei der Erstellung neuer Blocks notwen-

dig ist, erheblich erschwert und ist bei der aktuellen Rechenleistung des Bitcoin-Net-

werkes nahezu unmĂśglich.30

Zusammenfassend lässt sich sagen: Eine Blockchain besitzt durch die zugrunde lie-

gende  Netzwerkstruktur  (Peer-to-Peer)  und  die  Konsensusmechanismen  ein  hohes

Maß an Fälschungssicherheit. Für Konsens sorgen dabei folgende Prinzipien:

Als erstes das Prinzip der Legitimität, welches durch Kontrolle der Transaktionen sowie

allen sonstigen Inhalten die Richtigkeit dieser sicherstellt.

Als zweites Prinzip folgt die Verkettung der einzelnen BlĂścke mittels Einbeziehung des

Vorgänger-Blocks. Dies stellt sicher, dass die Änderung einer einzelnen zurückliegen-

den Transaktion die Neuberechnung aller folgenden BlĂścke erfordert.

Dies steht in Verbindung mit dem dritten Prinzip, dem Arbeitsnachweis. Dieser sorgt

dafĂźr, dass die Erstellung neuer BlĂścke mit einem Aufwand verbunden ist, sodass die

Erstellung von BlĂścken eine bestimmte Zeit sowie Rechenleistung erfordert.

Mit dem Proof-of-Work hängt auch die Schwierigkeit zusammen, die bei steigender Re-

chenleistung die Erstellung neuer BlĂścke begrenzt. Um das fortlaufende Erstellen neu-

er BlÜcke zu gewährleisten, wird ein Anreiz durch Entlohnung des erfolgreichen Peers

geschaffen.

27Vgl. Berentsen, Schär (2017, S.57 ff.).
28In der Bitcoin-Blockchain trifft dies nicht zur Gänze zu, dort wird die Kette als legitim akzeptiert, deren Er-
stellung den hĂśheren Rechenaufwand notwendig machte. Aufgrund der mangelnden Bedeutung fĂźr den 
Ăźbrigen Teil der Arbeit wird hier auf weitergehende AusfĂźhrung dieses Themas verzichtet.
29Vgl. Nakamoto (2008, S.4).
30Vgl. Berentsen, Schär (2017, S. 59 ff.)

14



Abschließend gilt noch das Prinzip der längsten Kette, sodass ein Angriff durch Nach-

berechnung aller BlÜcke erschwert wird. Mittels dieser Algorithmen lässt sich ei";"""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.4""
""pdf:docinfo:title"",""Bachelorarbeit""
""xmp:CreatorTool"",""Writer""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""language"",""de""
""dcterms:created"",""2020-03-30T09:34:01Z""
""dc:format"",""application/pdf; version=1.4""
""title"",""Bachelorarbeit""
""pdf:docinfo:creator_tool"",""Writer""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""Bachelorarbeit""
""Content-Length"",""360743""
""pdf:hasMarkedContent"",""false""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""dc:language"",""de-DE""
""meta:creation-date"",""2020-03-30T09:34:01Z""
""created"",""2020-03-30T09:34:01Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""54""
""Creation-Date"",""2020-03-30T09:34:01Z""
""resourceName"",""Junker_Marc-Bachelorarbeit.pdf""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""315"",""4827"",""718"",""3037"",""794"",""2524"",""2688"",""2801"",""1688"",""2671"",""1667"",""1458"",""2796"",""2800"",""2682"",""2860"",""2653"",""2554"",""2488"",""2893"",""2971"",""3022"",""2763"",""2612"",""2921"",""2885"",""2781"",""2824"",""2863"",""2934"",""2710"",""2704"",""2751"",""2857"",""2872"",""2917"",""2848"",""2753"",""2818"",""2721"",""2652"",""888"",""2836"",""2610"",""2550"",""145"",""1275"",""2612"",""2552"",""2344"",""2190"",""2157"",""891"",""557""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""producer"",""LibreOffice 6.0""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""LibreOffice 6.0""
""pdf:docinfo:created"",""2020-03-30T09:34:01Z""
";https://scholar.google.ch/scholar?start=930&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098747-67;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Formal security proofs of cryptographic standards;C Baritel;Ruet 2020 tel.archivesouvertes.fr;;"… de mon stage de M2 et que j'ai eu le plaisir de retrouver ŕ Crypto 2019 … Random oracles are

typically used as an ideal replacement for cryptographic hash functions (see Chapter 5) where …

In the random oracle model, a random oracle is assumed to exist and be accessible to the …";Les 9 versions;Version HTML;[PDF] archives-ouvertes.fr;https://tel.archives-ouvertes.fr/tel-03150443/document;"
HAL Id: tel-03150443
https://tel.archives-ouvertes.fr/tel-03150443

Submitted on 23 Feb 2021

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L’archive ouverte pluridisciplinaire HAL, est
destinĂŠe au dĂŠpĂ´t et Ă  la diffusion de documents
scientifiques de niveau recherche, publiĂŠs ou non,
émanant des établissements d’enseignement et de
recherche français ou Êtrangers, des laboratoires
publics ou privĂŠs.

Formal Security Proofs of Cryptographic Standards
CĂŠcile Baritel-Ruet

To cite this version:
CĂŠcile Baritel-Ruet. Formal Security Proofs of Cryptographic Standards. Computer Science [cs].
Université côte d’azur, 2020. English. �tel-03150443�

https://tel.archives-ouvertes.fr/tel-03150443
https://hal.archives-ouvertes.fr


Preuves Formelles de la SĂŠcuritĂŠ de
Standards Cryptographiques
Un objectif nÊcessaire, possible grâce à EasyCrypt

CĂŠcile BARITEL-RUET
INRIA Sophia Antipolis

Présentée en vue de l’obtention du
grade de docteur en Informatique
d’Université Côte d’Azur.

DirigĂŠe par : Yves BERTOT

Co-encadrĂŠe par :
Benjamin GRÉGOIRE

Soutenue le : 02/10/2020

Devant le jury, composĂŠ de :
Manuel Barbosa,
Yves Bertot,
Sandrine Blazy,
François Dupressoir,
Steve Kremer,
Benjamin GrĂŠgoire,
Bruno Martin





Preuves Formelles de la SĂŠcuritĂŠ de
Standards Cryptographiques
Un objectif nÊcessaire, possible grâce à EasyCrypt

Jury :

Directeurs

Yves Bertot, Directeur de recherche, Inria Sophia Antipolis MĂŠditerrannĂŠe
Benjamin GrĂŠgoire, ChargĂŠ de recherche, Inria Sophia Antipolis MĂŠditerrannĂŠe

Rapporteurs

Sandrine Blazy, Professeur et Chercheur, UniversitĂŠ de Rennes 1 et IRISA
Steve Kremer, Directeur de recherche, Inria Nancy

Examinateurs

Manuel Barbosa, Lecturer and Researcher, University of Porto and HASLab
François Dupressoir, Senior Lecturer, University of Bristol
Bruno Martin, Professeur et Chercheur, Université Côte d’Azur et I3S





Formal Security Proofs of Cryptographic
Standards

A necessity achieved using EasyCrypt

Jury :

Advisors

Yves Bertot, Research director, Inria Sophia Antipolis MĂŠditerrannĂŠe
Benjamin GrĂŠgoire, Researcher, Inria Sophia Antipolis MĂŠditerrannĂŠe

Rapporteurs

Sandrine Blazy, Lecturer and Researcher, UniversitĂŠ de Rennes 1 and IRISA
Steve Kremer, Research director, Inria Nancy

Examiners

Manuel Barbosa, Lecturer and Researcher, University of Porto and HASLab
François Dupressoir, Senior Lecturer, University of Bristol
Bruno Martin, Lecturer and Researcher, Université Côte d’Azur et I3S





Titre : Preuves Formelles de la SĂŠcuritĂŠ de Standards Cryptographiques

RĂŠsumĂŠ :

En cryptographie, Shannon a montré que le secret parfait n’existe pas. Ainsi, la cryp-
tographie moderne considère des propriÊtÊs de sÊcuritÊ dans lesquelles un attaquant peut
briser l’algorithme cryptographique mais seulement avec une faible probabilité. Dans ce
contexte, les algorithmes cryptographiques et les propriÊtÊs/hypothèses de sÊcuritÊ sont ex-
primĂŠs sous forme de programmes probabilistes. Les preuves de sĂŠcuritĂŠ consistent Ă  borner
la probabilité d’un événement dans de tels programmes. Ces preuves sont difficiles à prou-
ver et malgré le système de relecture académique des erreurs continuent d’être publiées.
Nous proposons l’utilisation des preuves formelles pour assurer une fiabilité suffisante des
standards cryptographiques.

Ma thèse fournit les preuves formelles de sécurité de trois standards dans l’assistant de
preuve EasyCrypt. Ces schémas sont CMAC (qui fournit l’authentification et l’intégrité des
messages), SHA-3 (une fonction de hachage cryptographique), et ChaCha20-Poly1305 (un
schéma de chiffrement authentifié avec données associées). L’objectif de la thèse n’est pas
seulement de formaliser la preuve de sĂŠcuritĂŠ de ces standards, mais aussi de dĂŠvelopper
des techniques gÊnÊriques et des bibliothèques qui peuvent être rÊutilisÊes. Toutefois, les
preuves formelles de sécurité n’assurent que la sécurité des algorithmes et non de leurs
implĂŠmentations. Pour contourner cette lacune, avec mes collaborateurs, nous lions formel-
lement nos implĂŠmentations sĂťres et efficaces avec la preuve de sĂŠcuritĂŠ, ceci conduit Ă  la
première preuve de sécurité cryptographique d’implémentations.

Mots clĂŠs : Cryptographie, Standards, SĂŠcuritĂŠ prouvable, EasyCrypt, Preuve formelle,
CMAC, SHA-3, ChaCha20-Poly1305.





ix

Title: Formal Security Proofs of Cryptographic Standards

Abstract:

In cryptography, Shannon showed that perfect secrecy does not exist. Thus, modern
cryptography considers security properties in which attackers may break the cryptographic
algorithm only with a small (negligible) probability. In this context, cryptographic algo-
rithms and security properties/assumptions are expressed as probabilistic programs. Secu-
rity proofs consist of bounding the probability of an event in such programs. Such proofs
have been peer-reviewed for some decades, but since they are difficult to prove and to verify,
fallacies keep emerging. We propose to use formal proofs to provide enough trustworthiness
for crypto-systems such as cryptographic standards.

My thesis provides the formal security proofs of three standards that are formally verified
using the proof assistant EasyCrypt. The cryptographic standards I have worked on are
CMAC (that provides message authentication and integrity), SHA-3 (a cryptographic hash
function), and ChaCha20-Poly1305 (an authenticated encryption scheme with associated
data). The goal of the thesis is not only to provide formal proof of those standards, but also
to develop generic techniques and libraries that can be reused. However, the formal security
proofs only ensure the security of the algorithms and not its implementation. To circumvent
this gap, with my collaborators, we have developed fast and secure implementations of
the last two schemes that are also side-channel resistant. Furthermore, we formally link
the implementation with the security proof, leading to the first formal security proof of an
implementated standard.

Keywords: Cryptography, Standards, Provable security, EasyCrypt, Formal proof, CMAC,
SHA-3, ChaCha20-Poly1305.





Remerciements — Acknowledgements

Je souhaite remercier en tout premier lieu mes deux directeurs, Yves Bertot et Benjamin
Grégoire, pour leur temps, leur soutien et leurs conseils que vous avez su m’offrir pendant
ces quatre annĂŠes de travail ensemble.

Merci Ă  toi Benjamin pour le soutien indĂŠfectible et la bienveillance que tu as su tĂŠmoi-
gner durant notre travail ensemble. Merci de m’avoir posé toutes ces questions auxquelles
je ne savais pas répondre immédiatement, m’enseignant beaucoup et en particulier cette
compétence fort utile qu’est la prise de recul. Je te suis reconnaissante pour tes efforts de
relecture, que j’espère savoir apprécier à leur juste valeur.

Merci Ă  toi Yves pour ton humanitĂŠ, tes conseils et ton ĂŠcoute pendant toute la durĂŠe
de ma thèse. Malgré la différence dans nos domaines d’expertise respectifs, nos échanges
ont toujours ĂŠtĂŠ non seulement enrichissant, mais aussi ont contribuĂŠ Ă  la prise de recul
sur mon domaine de recherche et le domaine de la recherche de manière gÊnÊrale. Plus
particulièrement, merci pour ton soutien pendant ce confinement de mars à mai 2020.

I want to humbly thank my jury for accepting to review my work.
In particular, I am wholeheartedly grateful to both Sandrine Blazy and Steve Kremer,

who dared to be rapporteurs, even though the health crisis and the summer break would
leave them little time to read this manuscript and write their report.

Thank you, François Dupressoir, Manuel Barbossa, and Bruno Martin for showing enough
interest in my work to participate in this jury.

Je tiens à remercier tous les membres de l’équipe Marelle — maintenant l’équipe Stamp
— qu’ils soient permanents ou non. L’ambiance que vous avez su maintenir est à la hauteur
du temps de la rĂŠgion : chaleureuse, agrĂŠable et humaine. Merci Laurence, pour ta gen-
tillesse, tes conseils, ta bienveillance et ton ĂŠnergie. Merci Ă  Laurent pour ses conseils sur
l’Agreg, même si je ne souhaite plus m’y diriger. Merci à Reynald pour toutes les inspirations
que tu m’as données à propos de la constitution de ces remerciements. Merci à Sophie et
Damien pour ces discussions entre doctorants toujours très intÊressantes et enrichissantes,
notamment sur l’éducation. Thank you, Anders, for the pleasant co-habitation at the office.
Merci à Mohammad et Adam pour la bonne humeur qu’ils ont instaurée dans le bureau.
Merci à Pierre pour ces discussions autour d’un (un ?) café. Merci à Cyril pour son point de
vue rafraichissant et bienveillant. Merci Ă  Maxime et Enrico pour avoir animĂŠ les repas du
midi. Merci Ă  Nathalie pour son soutien, son humanitĂŠ, sa bonne humeur et sa bienveillance.
Son travail nous soulage d’un poids administratif et je pense ne pas savoir mesurer son im-
portance tant elle fait bien son travail pour qu’on ne le remarque pas. Merci pour sa trilogie,
que j’attends avec impatience en version électronique. Je souhaite rendre hommage à José
qui nous a quittĂŠ en 2019, on pense Ă  lui.



xii Remerciements — Acknowledgements

Merci à tous ceux qui ont bien voulu m’écouter parler de ma recherche. Je tiens notam-
ment à remercier les deux membres de mon comitÊ de suivi doctoral, François Dupressoir
et Cinzia Di Guisto, pour vos retours, vos encouragements et vos ĂŠclairements.

Merci aux enseignants Cinzia Di Guisto, Sid Touati et Étienne Lozes, pour m’avoir permis
de travailler avec vous pour mon service en tant que chargĂŠ de TP/TD. Je tiens aussi Ă 
remercier mes élèves avec qui le contact humain lors de l’échange pédagogique a été source
de beaucoup d’enthousiasme et de motivation pour moi.

Merci Ă  Madtree pour cette discussion sur le cours de cryptographie sur Coursera, et
dont la prÊsente thèse en est le produit fortuit. Merci à Xavier Urbain pour son aide et son
soutien pour poursuivre le parcours académique qui m’intéressait. Merci à Serge Haddad
pour m’avoir présenté le second concours d’entrée à l’ENS de Cachan. Merci à Stéphanie
Delaune pour son soutien et de m’avoir fait découvrir qui allait être mon encadrant de
thèse. Merci à Pierre-Alain Fouque pour son co-encadrement de mon stage de M2 et que j’ai
eu le plaisir de retrouver Ă  Crypto 2019. Merci Ă  Cristina Onete pour son soutien pendant
ce stage, et pour m’avoir fait découvrir le workshop CrossFyre. Je tiens à remercier François
Dupressoir qui m’a accueilli pour une visite juste après l’édition 2018 de CrossFyre. Merci
à Pierre-Yves Strub pour son soutien pendant la demande de bourse de thèse et pour le
travail commun pendant la thèse. Merci à Gilles Barthe pour sa ligne de recherche qui a ÊtÊ
indirectement dĂŠterminante pour mon travail de recherche.

Enfin, je remercie tous ceux qui m’ont soutenu et encouragé. Merci en particulier à mes
amis et ma famille, que j’ai peu vus ces dernières années à cause de la distance, mais qui
comptent beaucoup pour moi et m’accueillent comme si je n’étais jamais partie.

Merci Ă  Nicole, Pascal, Audrey, NathanaĂŤl, le petit MaĂŤl (qui est arrivĂŠ le 17 mars 2020),
Marthe, JoĂŤlle, Pauline, Luca, HervĂŠ, Catherine, Philippe, RĂŠmy, Thomas, OphĂŠlie, Djamal,
Thomas, Élodie, Fabien, Louis, Charly, Pierre, Tristan, Amélie, Nicolas, Olivier, Karina, Sté-
phane, Daniel et aux autres que j’oublie. Merci à Ahri, ma chienne, qui a été d’une aide
prĂŠcieuse, en particulier pour continuer Ă  sortir pendant le confinement.



Contents

Page

Introduction 1

I Methodology 7

1 Practice-Oriented Provable Security 9

1.1 Provable Security Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.1.1 Random Oracle Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.1.2 Ideal Cipher Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

1.2 Limitations and Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2 EasyCrypt and General Formalization Techniques 15

2.1 Foundations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.1.1 Probability Distributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.1.2 Modules in EasyCrypt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.2 Adversarial Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.2.1 Restrictions on Oracle Procedure Calls . . . . . . . . . . . . . . . . . . . 24
2.2.2 Adversarial Restrictions on Program Variables . . . . . . . . . . . . . . . 24
2.2.3 Computation Time Restrictions . . . . . . . . . . . . . . . . . . . . . . . . 25

2.3 Formalization Techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.3.1 PRP-PRF switching lemma . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.3.2 Eager Sampling [Almeida et al., 2019b] . . . . . . . . . . . . . . . . . . 32
2.3.3 Split Random Oracle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

II Message Authentication 39

3 Security of a MAC Scheme 41

3.1 Security Definition : Forgery Resistance . . . . . . . . . . . . . . . . . . . . . . . 42
3.2 Indistinguishability from a Random Function implies Forgery Resistance . . . 43

3.2.1 Forgery Resistance of a Random Function . . . . . . . . . . . . . . . . . 43
3.2.2 Indistinguishability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

3.3 Block Cipher Mode of Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
3.3.1 Security Definition of a Block Cipher . . . . . . . . . . . . . . . . . . . . 47
3.3.2 Security Definition of a Block Cipher Mode of Operation . . . . . . . . 47

4 CMAC’s Formal Security Proof [Baritel-Ruet et al., 2018] 49

4.1 Historical presentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49



xiv Contents

4.2 MAC Security Proofs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.2.1 Indistinguishability of ECBC from a Random Function . . . . . . . . . . 56
4.2.2 Indistinguishability of FCBC from ECBC . . . . . . . . . . . . . . . . . . 59
4.2.3 Indistinguishability of XCBC from FCBC . . . . . . . . . . . . . . . . . . 60
4.2.4 Indistinguishability of CMAC from FCBC . . . . . . . . . . . . . . . . . . 62

III Cryptographic Hash Function 69

5 Security of a Hash Function 71

5.1 Security Definitions and Formalization . . . . . . . . . . . . . . . . . . . . . . . . 71
5.2 Random Function Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
5.3 Indifferentiability, not indistinguishability . . . . . . . . . . . . . . . . . . . . . . 74
5.4 Security from Indifferentiability . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

6 SHA3’s Formal Security Proof [Almeida et al., 2019b] 77

6.1 The SPONGE construction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
6.2 Security Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
6.3 Layered Indifferentiability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

6.3.1 General Decomposition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
6.3.2 First Layer : SPONGE (not part of my contributions) . . . . . . . . . . . 84
6.3.3 Second Layer : BLOCKSPONGE . . . . . . . . . . . . . . . . . . . . . . . . . 86
6.3.4 Core Layer : CORESPONGE . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
6.3.5 The final SPONGE simulator . . . . . . . . . . . . . . . . . . . . . . . . . . 90

6.4 A deeper look at the upto-bad game . . . . . . . . . . . . . . . . . . . . . . . . . 91

IV Confidentiality and Authentication 101

7 Security of Authenticated Encryption 103

7.1 Authenticated Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
7.2 Security Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

7.2.1 IND-CPA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
7.2.2 IND-CCA1 and IND-CCA2 . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
7.2.3 INT-CTXT : Integrity of the CipherTeXT . . . . . . . . . . . . . . . . . . . 107

7.3 Relations between IND-CCA, IND-CPA and INT-CTXT . . . . . . . . . . . . . . . 108
7.3.1 IND-CCA from IND-CPA and INT-CTXT . . . . . . . . . . . . . . . . . . . 109
7.3.2 Ideal Encryption Scheme . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

8 ChaCha20-Poly1305’s Formal Proof 113

8.1 Description of ChaCha20-Poly1305 . . . . . . . . . . . . . . . . . . . . . . . . . . 114
8.2 Security of ChaCha20-Poly1305 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115

8.2.1 Adversarial Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
8.2.2 Security Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117

8.3 Security Proof . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117



Contents xv

Conclusion 127

List of Figures 129





Introduction

Whenever I speak about my PhD in a non-expert context, I start talking about com-

puter security and I get simple but meaningful questions that resemble to: “Are you actually
breaking into software to exploit vulnerabilities ?”, “Do you know about this threatening
vulnerability X ?”, or “Which anti-virus should I install to protect my data ?”. This kind of
questions belongs to one particular field of computer security where the focus is on breaking

security, while I work in the field where the focus is on ensuring security.
In computer networks, data flows from places to places. Some of the data is sensitive

and attackers like hackers or spies want to find an access through vulnerabilities of the data
flow. The objective of computer security is to analyze the flow of data, to find vulnerabilities
and place barriers to prevent intruders from accessing it. Some of those barriers come from
cryptography and my work is to analyze the “robustness” of some particular barriers.

Cryptography prior to the modern age was actually synonymous with encryption, the
conversion of information from a readable meaningful state to apparent nonsense. The orig-
inator of an encrypted message shares the decoding technique (the encryption and decryption

algorithms and the secret key) only with intended recipients to preclude access from adver-

saries. Because the adversary cannot understand and know the content of the encrypted
message, this is one way of how the barriers are implemented.

There are two ways to ensure security, either the secrecy depends on hiding both the
algorithm and the secret key, or the algorithm is known to the adversary and only the secret
key needs to be hidden. History has shown that the first one is not practical, and leads to
greater security flows, as the amount of secret data to keep the secrecy is much larger if the
algorithm is included. This was first explicitly stated as a fundamental principle in 1883 by
Auguste Kerckhoffs [Kerckhoffs, 1883] and is generally called Kerckhoffs’s Principle; alter-
natively and more bluntly, it was restated by Claude Shannon, the inventor of information

theory and the fundamentals of theoretical cryptography in [Shannon, 1949]:

The enemy knows the system.

Since the development of rotor cipher machines in World War I and the advent of com-
puters in World War II, the methods used to carry out cryptology have become increas-
ingly complex and its application more widespread. In recent decades, the field has ex-
panded beyond confidentiality concerns to include techniques for message integrity check-
ing, sender/receiver identity authentication, digital signatures, interactive zero-knowledge
proofs and secure computation, among others, as shown in Figure 1.

Modern cryptography is heavily based on mathematical theory and computer science
practice. Cryptographic algorithms, or more generally cryptosystems, are based on mathe-

matical problems that are easy to state but have been found difficult to solve. If one can



2 Introduction

Cryptography

Confidentiality

Public-
Key

Encryption

Block
Ciphers,
Stream
Ciphers

Origin Non-
Repudiation

Entity
Authentication

Digital
Signatures

Zero-
Knowledge

Proofs

Data
Integrity

MAC
Algorithms

Hash
Functions

AE

Figure 1 – Cryptography: a field composed of various security goals and techniques

reduce any adversary that efficiently breaks a cryptosystem into an efficient solution to a
hard mathematical problem, this means that breaking this cryptosystem is harder than find-
ing an efficient solution to this hard mathematical problem. This reasoning pattern is called
a security reduction proof (or reduction, or security proof) and is instrumental in the modern
approach to cryptography: provable security [Katz and Lindell, 2014].

We use a mathematical method for the basis of our work that includes the reduction of
the number of concepts, for instance by reducing the number of actors, the form of attacks,
and using probabilities. This approach makes explicit a simple model and is well accepted
in the community. For instance, the standardization institute NIST recommends: ÂŤ The
review of technical merit includes a precise, formal statement of security claims, based on
minimal security assumptions and supported as far as possible by documented cryptanalysis
and security reduction proofs. Âť (NIST Cryptographic Standards and Guidelines Development

Process [Regenscheid, 2016])

Provable Security

Traditionally, provable security is asymptotic: it classifies the hardness of computational
problems using polynomial-time reducibility. Secure schemes are defined to be those in
which the advantage of any computationally bounded adversary to break the cryptosystem
is negligible. While such a theoretical guarantee is important, in practice one needs to know
exactly how efficient a reduction is because of the need to instantiate the security parameter

(e.g. key length). It is not enough to know that ""sufficiently large"" security parameters will



3

do. An inefficient reduction results either in the success probability for the adversary or the
resource requirement of the scheme being greater than desired.

Concrete security is a practice-oriented approach [Bellare, 1997] that needs a more pre-
cise estimate of the computational complexity of adversarial tasks than polynomial equiva-
lence would allow. Concrete security aims at quantifying an upper bound on the probability
of any adversary to break the system studied. More precisely, a proof of security involves
an upper bound on the advantage of the adversary to break the system as a function of
adversarial resources and of the problem size. The resource available to the adversary are
commonly running time and memory, and other resources specific to the system in question,
such as the number of plaintexts it can obtain or the number of queries it can make to any
available oracle. The problem size usually is the size of the key, but it can also include the
size of blocks when blocks are defined in the system.

There are several lines of research in provable security. One is to establish the ""cor-
rect"" definition of security for a given, intuitively understood task. Another is to suggest
possible solutions: cryptographic constructions and their security proofs. The cryptography
community is confronted to the difficulty to produce correct proofs. Several researchers
found mathematical fallacies in proofs; proofs that had been used to make claims about the
security of important protocols. This is illustrated in the list below where the name of a
cryptosystem is followed by the initial paper when it was claimed to be proven secure then
by the reference in which the first fallacy was reported. For some of those constructions,
successive corrections were also shown to be defective.

— OAEP [Bellare and Rogaway, 1994] [Shoup, 2002];

— HMQV [Krawczyk, 2005] [Menezes, 2007];

— CBC-MAC and EMAC [Bellare et al., 2005] [Jha and Nandi, 2016];

— Boneh-Franklin IBE [Boneh and Franklin, 2003] [Galindo, 2005];

— GCM [McGrew and Viega, 2004b] [Iwata et al., 2012];

— XLS [Ristenpart and Rogaway, 2007] [Nandi, 2014];

— RSA screening [Bellare et al., 1998b] [Coron and Naccache, 1999];

— XCB [McGrew and Fluhrer, 2007] [Chakraborty et al., 2015];

— Cascade encryption [Bellare and Rogaway, 2006] [Gaži and Maurer, 2009];

— RSA-FDH [Coron, 2002] [Kakvi and Kiltz, 2012];

— OCB2 [Rogaway, 2004a] [Inoue et al., 2019].

The scientific community thinks that for any claim the claimer should be the one to pro-
duce enough non-fallacious material to convince of the correctness of its logical arguments.
The referring process is here to ensure that no wrong proof is accepted. However, the list
above shows that this is not enough. Delegating the verification of a proof’s correctness to
a computer is a way to answer this issue. This is my second field of expertise which is part
of the larger field of formal verification.

Formal Verification

The verification of a mathematical proof is a tedious work, and as a lot of tedious works,
this can be eased by the use of machines. This is well explained by Thomas C. Hales in his
advocacy for formal proofs [Hales, 2008]:



4 Introduction

Traditional mathematical proofs are written in a way to make them easily un-
derstood by mathematicians. Routine logical steps are omitted. An enormous
amount of context is assumed on the part of the reader. Proofs, especially in
topology and geometry, rely on intuitive arguments in situations where a trained
mathematician would be capable of translating those intuitive arguments into a
more rigorous argument.

A formal proof is a proof in which every logical inference has been checked all
the way back to the fundamental axioms of mathematics. All the intermediate
logical steps are supplied, without exception. No appeal is made to intuition,
even if the translation from intuition to logic is routine. Thus, a formal proof is
less intuitive, and yet less susceptible to logical errors.

Formal verification involves the use of logical and computational methods to establish
claims that are expressed in precise mathematical terms. These can include ordinary mathe-
matical theorems, as well as claims that pieces of hardware or software, network protocols,
and mechanical and hybrid systems meet their specifications (expected behavior defined by
a mathematical property). Formal verification requires describing hardware and software
systems in mathematical terms, at which point establishing claims about their correctness
becomes a form of theorem proving.

Interactive theorem proving focuses on the verification aspect of theorem proving requir-
ing that every claim is supported by a proof in a suitable axiomatic foundation. This sets a
very high standard: every rule of inference and every step of a calculation has to be justified
by appealing to prior definitions and theorems, all the way down to basic axioms and rules.
HOL [Gordon, 1988], Isabelle [Paulson, 1994], PVS [Owre et al., 1992], Coq [Coq, 1984]
and Lean [Lea, 2012] are some of the most well-known interactive theorem provers, also
known as proof assistants.

Without minimizing nor dismissing their respective strengths, they primary work on
mathematical proofs and aim to reduce towards a minimum its axiomatic basis. My work in-
volves the game-based technique of provable security, a feature that is included in EasyCrypt,
a proof assistant introduced as a proof of concept to address the problem of the security of
OAEP [Barthe et al., 2011b]. It implements a model in which the game-based technique
and distributions (probabilities) set up an interactive theorem prover for the formalization
of concrete security bounds. I will describe EasyCrypt along with the methodology used for
security proofs in detail in the next part.

Cryptographers have the intuition of why a system is secure, but translating this intuition
into formal logical steps is a long and tedious work and requires expertise in both cryptogra-
phy and formal verification. Deductive verification has the disadvantage that it requires the
user to understand in detail how the system works exactly, and to convey this information
to the verification system. There exist a lot of cryptographic constructions and not so many
cryptographers are also versed into formal verification.

Contributions

My work aims at extending the number of formally proven secure schemes with two
objectives in mind:

1. for the sake of verifying concrete security bounds of cryptographic standards,

2. to extend the proof of concept into a proof of usability, so that formal verification with
EasyCrypt may be included in the process of standardization.



5

This extension includes the formalization of the security proof of three different cryp-
tographic standards, each of them answering a different security requirement. Because of
the downsides of formalization efforts, we have intentionally prioritized cryptographic stan-
dards. Those standards are from either NIST, or the IETF (Internet Engineering Task Force).

My first contribution is the study of the formal security bound of a standard MAC (mes-
sage authentication code) scheme named CMAC [Baritel-Ruet et al., 2018].

My second contribution is part of a joint work to produce a fast and secure implemen-
tation of a standard hash function named SHA-3 [Almeida et al., 2019b]. My personal con-
tribution on this is situated in the formal security bound.

The third contribution presented in my manuscript is the study of the formal security
bound of an authenticated symmetric encryption scheme named ChaCha20-Poly1305. This
last work has not been published yet.

Organization of this thesis

Part I explains the scientific methodology and is composed of two chapters.

— Chapter 1 explains in more details practice-oriented provable security, and the limits
and controversies of provable security.

— Chapter 2 exposes EasyCrypt.

Part II explores the notion of message authentication with the study of the security of one
standardized MAC scheme and is composed of two chapters.

— Chapter 3 explains what message authentication actually means and state the formal
security definition of a MAC scheme.

— Chapter 4 explains the security proof of the standardized MAC scheme named CMAC.

Part III explores the notion of cryptographic hash function with the study of the security of
one standardized hash function and is composed of two chapters.

— Chapter 5 states the formal security definition of a cryptographic hash function.

— Chapter 6 explains the security proof of the standardized hash function named SHA-3.

Part IV explores the notion of authenticated encryption with the study of the security of an
authenticated encryption and is composed of two chapters.

— Chapter 7 states the formal security definition of an authenticated encryption.

— Chapter 8 explains the security proof of ChaCha20-Poly1305, an authenticated en-
cryption scheme.





Part I

Methodology





Chapter 1

Practice-Oriented Provable Security

The security of a service is its ability to be resilient against potential risks. In providing
a service, the goal is to maximize its usefulness while minimizing the risks associated with
its use. This balance between risk and efficiency is essential in IT security. However, this is
not up to cryptographers to provide such a balance in the use of a cryptosystem, but rather
the “architect” of the service. Instead, the responsibility of the cryptographers is to provide
sufficient analytical material to the “architect” so that the choice on which cryptosystems
and their parameters should be based on an informed one.

The choice of such a cryptosystem can be guided by the fact that the longer the cryptosys-
tem remains unattacked, the more secure it is believed to be. Before modern cryptography,
the common practice was to find a particular attack on a cryptographic scheme, then update
the scheme, and do it again (and again). This practice is tantamount to playing the cat and
mouse game and reveals an empirical approach that is not sufficiently releva";"""date"",""2020-12-15T19:47:41Z""
""pdf:PDFVersion"",""1.4""
""xmp:CreatorTool"",""LaTeX with hyperref""
""pdf:docinfo:title"",""Formal Security Proofs of Cryptographic Standards""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""Computer Science [cs]""
""language"",""fr""
""dc:format"",""application/pdf; version=1.4""
""pdf:docinfo:creator_tool"",""HAL""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""Formal Security Proofs of Cryptographic Standards""
""xmp:CreateDate"",""2020-12-15T20:53:11Z""
""modified"",""2020-12-15T19:47:41Z""
""cp:subject"",""Computer Science [cs]""
""pdf:docinfo:subject"",""Computer Science [cs]""
""pdf:hasMarkedContent"",""false""
""xmp:ModifyDate"",""2020-12-15T20:53:11Z""
""pdf:docinfo:creator"",""CĂŠcile Baritel-Ruet""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.21 (TeX Live 2020/Debian) kpathsea version 6.3.2""
""meta:author"",""""
""meta:creation-date"",""2021-04-27T18:04:30Z""
""created"",""2021-04-27T18:04:30Z""
""xmp:About"",""uuid:b5cbcc6b-772b-11f6-0000-521f7da06ae7""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2021-04-27T18:04:30Z""
""resourceName"",""document""
""Author"",""""
""producer"",""PDFLaTeX""
""pdf:docinfo:producer"",""PDFLaTeX""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""3"",""0"",""8"",""0"",""4"",""32"",""0"",""0"",""0"",""6"",""11"",""0"",""13"",""0"",""0"",""13"",""7"",""9"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""14"",""0"",""0"",""21"",""20"",""34"",""0"",""0"",""0"",""3"",""0"",""0"",""1"",""0"",""8"",""37"",""28"",""17"",""22"",""19"",""4"",""34"",""53"",""29"",""27"",""21"",""13"",""0"",""0"",""0"",""0"",""11"",""6"",""8"",""6"",""0"",""0"",""0"",""11"",""5"",""15"",""7"",""16"",""6"",""5"",""5"",""11"",""1"",""0"",""16"",""0"",""0"",""0"",""0"",""0"",""1"",""1"",""0"",""1"",""0"",""0"",""0"",""0"",""11"",""11"",""14"",""0"",""13"",""12"",""1"",""0"",""0"",""5"",""1"",""0"",""24"",""4"",""11"",""4"",""8"",""0"",""5"",""8"",""9"",""5"",""0"",""0"",""4"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""Keywords"",""Cryptography, Standards, Provable security, EasyCrypt, Formal proof, CMAC, SHA-3, ChaCha20-Poly1305Cryptographie, Standards, SĂŠcuritĂŠ prouvable, EasyCrypt, Preuve formelle, CMAC, SHA-3, ChaCha20-Poly1305""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2021-04-27T18:04:30Z""
""Last-Modified"",""2020-12-15T19:47:41Z""
""dcterms:modified"",""2020-12-15T19:47:41Z""
""title"",""Formal Security Proofs of Cryptographic Standards""
""xmpMM:DocumentID"",""uuid:b5cbcc6b-772b-11f6-0000-521f7da06ae7""
""Last-Save-Date"",""2020-12-15T19:47:41Z""
""pdf:docinfo:keywords"",""Cryptography, Standards, Provable security, EasyCrypt, Formal proof, CMAC, SHA-3, ChaCha20-Poly1305Cryptographie, Standards, SĂŠcuritĂŠ prouvable, EasyCrypt, Preuve formelle, CMAC, SHA-3, ChaCha20-Poly1305""
""pdf:docinfo:modified"",""2020-12-15T19:47:41Z""
""meta:save-date"",""2020-12-15T19:47:41Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.21 (TeX Live 2020/Debian) kpathsea version 6.3.2""
""Content-Length"",""3188056""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""pdf:producer"",""GPL Ghostscript 9.25""
""dc:subject"",""Cryptography, Standards, Provable security, EasyCrypt, Formal proof, CMAC, SHA-3, ChaCha20-Poly1305Cryptographie, Standards, SĂŠcuritĂŠ prouvable, EasyCrypt, Preuve formelle, CMAC, SHA-3, ChaCha20-Poly1305""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""154""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""758"",""411"",""0"",""549"",""0"",""507"",""0"",""1567"",""0"",""1530"",""0"",""2466"",""1962"",""1568"",""2048"",""39"",""0"",""2528"",""1684"",""2648"",""2944"",""1896"",""0"",""16"",""0"",""2217"",""2842"",""3229"",""2163"",""3091"",""1217"",""1844"",""1649"",""1930"",""1894"",""1929"",""2115"",""2031"",""2123"",""1735"",""1920"",""1677"",""2041"",""1835"",""1779"",""1722"",""1671"",""1315"",""2196"",""1670"",""755"",""1871"",""1362"",""821"",""0"",""27"",""0"",""1767"",""2646"",""1703"",""1550"",""1908"",""1524"",""1596"",""1114"",""1035"",""2357"",""1149"",""1266"",""987"",""1158"",""869"",""2281"",""2246"",""2678"",""2134"",""2423"",""2403"",""1609"",""1875"",""2203"",""1075"",""2092"",""1527"",""1455"",""32"",""0"",""1853"",""1517"",""956"",""1880"",""1467"",""1501"",""2172"",""3214"",""1770"",""1212"",""2837"",""2500"",""1855"",""1196"",""1697"",""2434"",""2107"",""2135"",""2233"",""2818"",""1252"",""1363"",""1104"",""916"",""1238"",""661"",""1556"",""1838"",""1480"",""878"",""37"",""0"",""2180"",""2981"",""1956"",""2004"",""1664"",""1745"",""1823"",""1802"",""1048"",""0"",""2219"",""1750"",""2170"",""1860"",""2198"",""1783"",""815"",""1563"",""1337"",""2374"",""1584"",""2053"",""1720"",""319"",""2354"",""2340"",""2252"",""1063"",""2088"",""2895"",""2826"",""2745"",""2765"",""2705"",""1995""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""meta:keyword"",""Cryptography, Standards, Provable security, EasyCrypt, Formal proof, CMAC, SHA-3, ChaCha20-Poly1305Cryptographie, Standards, SĂŠcuritĂŠ prouvable, EasyCrypt, Preuve formelle, CMAC, SHA-3, ChaCha20-Poly1305""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2021-04-27T18:04:30Z""
";https://scholar.google.ch/scholar?start=610&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098818-222;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Livestock Welfare by Means of an Edge Computing and IoT Platform;I Sittón;Candanedo, J Prieto  Ambient IntelligenceSoftware and …, 2020  books.google.com;;"… benefits in terms of security, traceability and data integrity, due to the characteristics provided

by the elements associated with the Distributed Ledger Technologies of the Global Edge

Computing Architecture, including the blockchain itself and the Crypto-IoT boards and oracles …";Autres articles;;null;;;;https://scholar.google.ch/scholar?start=770&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098875-354;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;[HTML][HTML] Blockchain-Based Data Integrity for Collaborative CAD;S Lemeš ; Mixed Reality and Three Dimensional Computer …, 2020  intechopen.com;;"… Although several top-tier software providers offer blockchain-based solutions: Microsoft Azure

Blockchain service, SAP Leonardo Blockchain, Amazon Blockchain as a Service, IBM Blockchain

Platform, and Oracle Blockchain Cloud Service; the major CAD software vendors still …";Autres articles;;[HTML] intechopen.com;https://www.intechopen.com/online-first/blockchain-based-data-integrity-for-collaborative-cad;"[image: IntechOpen]	Books
	Publish
	About
	News
	Contact

	Author Panel Sign in

Submit
What is Open Access?Open Access is an initiative that aims to make scientific research freely available to all. To date our community has made over 100 million downloads. It’s based on principles of collaboration, unobstructed discovery, and, most importantly, scientific progression. As PhD students, we found it difficult to access the research we needed, so we decided to create a new Open Access publisher that levels the playing field for scientists across the world. How? By making research easy to access, and puts the academic needs of the researchers before the business interests of publishers.

Our authors and editorsWe are a community of more than 103,000 authors and editors from 3,291 institutions spanning 160 countries, including Nobel Prize winners and some of the world’s most-cited researchers. Publishing on IntechOpen allows authors to earn citations and find new collaborators, meaning more people see your work not only from your own field of study, but from other related fields too.

Content AlertsBrief introduction to this section that descibes Open Access especially from an IntechOpen perspective
How it worksManage preferences
ContactWant to get in touch? Contact our London head office or media team here
CareersOur team is growing all the time, so we’re always on the lookout for smart people who want to help us reshape the world of scientific publishing.




Open access peer-reviewed chapter
Blockchain-Based Data Integrity for Collaborative CAD
By Samir LemeĹĄ
Submitted: November 7th 2019Reviewed: August 3rd 2020Published: September 24th 2020
DOI: 10.5772/intechopen.93539


Home > Books > Mixed Reality and Three-Dimensional Computer Graphics


Advertisement

Downloaded: 330


Advertisement


Abstract
Distributed and collaborative computer-aided design (CAD) environments include building information modeling (BIM) and geographical information systems (GISs) in civil engineering and architecture, or product data management/product life cycle management (PDM/PLM) in mechanical engineering. It is essential to keep the data integrity in these computer applications as it contributes to buildingusers’ confidence in CAD/BIM/PDM data. Blockchain technology, the core foundation of cryptocurrencies, is increasingly being used for other purposes and could solve the data integrity issue in collaborative CAD environments. However, it has some disadvantages such as the transparency of data and the slowness of storing data in the blockchain due to distributed consensus. Increasing demand by the Industry 4.0, IoT, Smart Cities, and other initiatives could foster the best what blockchain has to offer: data integrity, reliability, and traceability. This chapter explains how blockchain works, how can it be utilized in distributed CAD environments, what are the major challenges for implementation, and how CAD vendors could use it to increase CAD data integrity.


Keywords
	blockchain
	CAD
	BIM
	PDM/PLM
	data integrity


chapter and author info
Author
	Samir LemeĹĄ*
	University of Zenica, Zenica, Bosnia and Herzegovina



*Address all correspondence to: slemes@unze.ba


DOI: 10.5772/intechopen.93539
From the Edited Volume
IntechOpenMixed Reality and Three-Dimensional Computer GraphicsEdited by Branislav Sobota

Mixed Reality and Three-Dimensional Computer Graphics
Edited by Branislav Sobota and Dragan Cvetković

Show +
1. Introduction
The increasing complexity of modern engineering products requires new paradigms and leveraging any available technology to keep in pace with the competition. Increasing market demands such as environmentally friendly products, sustainable buildings, dynamic global supply chains, cost reduction requirements, and workforce mobility have changed most steps in the product life cycle process (design-manufacturing-control-utilization-decommissioning). Even the most individual creative tasks such as product design now require teamwork to deliver products on time. It is not unusual to have globally distributed teams working on any single engineering task. These teams use the advantages of cloud computing to collaborate and share skills and resources. Simultaneously, the software vendors keep shifting their products from computer workstations to cloud computing resources, thus enabling globally distributed teamwork, but introducing the new challenges.
The use of cloud computing in computer-aided design (CAD) is still not mature enough to prevail over desktop computing. Computer-aided engineering (CAE) applications do make use of cloud computing to overcome the computing power limitation of computer workstations to perform resource-demanding simulation tasks. Collaborative CAD environments such as building information modeling (BIM) and product data management/product life cycle management (PDM/PLM) have already embraced the advantages of cloud computing, which brought another issue—the problem of information security. This issue could be resolved by using emerging technologies such as blockchain.
Although several top-tier software providers offer blockchain-based solutions: Microsoft Azure Blockchain service, SAP Leonardo Blockchain, Amazon Blockchain as a Service, IBM Blockchain Platform, and Oracle Blockchain Cloud Service; the major CAD software vendors still hesitate to leverage blockchain in their BIM/PDM/PLM solutions, and they are still waiting for what small start-ups will have to offer in a near future [1].
London-based engineering consultant company, ARUP, has been studying blockchain since 2013. Their research indicates that early adoption within the architecture/engineering/construction (AEC) industry might not begin before 2025 [2]. An American international technical professional services company, Jacobs Engineering Group, cofounded the Integrated Engineering Blockchain Consortium (IEBC), which launched its CoEngineers Blockchain in 2018 [3]. The first integrated BIM and blockchain application is still under development in the Spanish technological research and development project, DELFOS [4].
A French start-up technology company, Lutecium, started to develop a blockchain-based software, BIMChain, aimed to accelerate the BIM for the construction industry [5, 6]. Their solution, based on an Ethereum-based platform, integrates BIM ecosystem through dedicated plugins for Revit or ArchiCAD. It increases BIM data quality through accountability and incentive mechanisms, transforms BIM into a collaborative and legally binding process, and provides traceability. The project is supported by the Autodesk and the French task group Plan Transition NumÊrique dans le Bâtiment. An early beta version of the software was launched at the beginning of 2019. Their ambition is to create a collaborative process bridging the gap between 3D CAD models and legally binding paper-based formal processes related to project management, building maintenance and control, and insurance and payment. They aim to link validated proofs of contributions to 3D CAD models with a form of smart contract, thus making BIM data contractual.

Advertisement
2. Collaborative CAD environments
The National Institute of Standards and Technology (NIST) defines cloud computing as “a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources that can be rapidly provisioned and released with minimal management effort or service provider interaction” [7]. These resources include computer networks, servers, storage, applications, and services. In other words, cloud computing is shifting the computing power, data, and management from the local computers and workstations to a globally accessible network of computer resources. This technology helped users to make the data and software globally accessible and enabled teamwork and collaboration in any computer-aided task.
CAD only recently started to use the advantages of cloud computing. Figure 1 shows how engineering design collaboration evolved from traditional paper-based documentation to modern cloud computing solutions. Personal computers did leverage the expansion of CAD into every engineering office but initially lacked the collaboration features. They were introduced gradually, first over the local file sharing, then using internet servers, gradually increasing the ratio of data and software stored online, converging toward completely cloud-based solutions.
[image: ]
Figure 1.

The development phases of CAD.

Cloud computing is increasingly making web-based synchronous CAD commercially available. Multiple designers are now able to simultaneously modify a model from their workstations. CAD platforms now offer benefits like synchronous access, cost-effectiveness, higher utilization of resources, and enhanced security, while still having unresolved issues related to usability, security, and computational performance [8].
Another CAD-related technology, computer-aided manufacturing (CAM), was limited for decades to using CAD files to generate code for machining, and it was boosted recently by the rapid expansion of 3D printing (sometimes referred to as additive manufacturing) technology. As a vast number of digital models ready for 3D printing are available in cloud-based repositories, there is a risk of intellectual property (IP) infringements by enabling cheap manufacturing of counterfeit products or simply of altering these files. Open issues could be solved by integration of the blockchain in additive manufacturing supply chains, provided that the technology is available and affordable [9].
2.1 PDM/PLM
Product data management (PDM) is a specialized information system developed primarily to manage CAD design files and CAE simulation results. It represents the extension of 3D CAD models to a specialized design environment that manages a set of CAD files in hierarchically distributed files.
The product life cycle management (PLM) concept emerged from PDM by providing services to extend the product design data to manufacturing and operations [10]. PLM manages the complete product life cycle, usually in a networked or, more recently, cloud environment. In PLM, multiple users have access to CAD models stored in the database rather than in individual files stored locally or on dedicated servers. CAD files in the PLM database are only one of the set of attributes describing a machine part, machine assembly, or entire construction. PLM systems connect intangible to physical asset information managed by enterprise resource planning (ERP) and customer relationship management (CRM).
An analysis presented in [10] suggests that PLM is based upon the three fundamental concepts. According to [10], these concepts enable (1) product definition and related information being used and managed universally and securely; (2) product definition and related information being maintained throughout the entire product life; and (3) business processes being managed and maintained, enabling creating, managing, communicating, and using the product and related information. The product information can thus be shared to all stakeholders in the product life cycle, from design, manufacturing, assembling, quality control, sale, operation, and disposal or decommission at the end of its useful life.
Most CAD/CAE software vendors also have the PDM/PLM solutions, such as Siemens Teamcenter (Figure 2), Autodesk Fusion Lifecycle, Dassault Systems Enovia, Aras Innovator, PTC Windchill, and SAP. Despite that, not more than one third of CAD users use PDM/PLM to create Bill of Materials for their CAD drawings. Most users still use spreadsheets to create Bill of Materials. It can be concluded that this technology is rather emerging than mature [1].
[image: ]
Figure 2.

Siemens Teamcenter (source:www.plm.automation.siemens.com).

The deployment of PLM platforms, used for handling the product data exchange, is quite costly, and very often, small companies cannot afford them. When such companies become part of larger original equipment manufacturers’ (OEMs) networks, the PLM platforms used typically belong to an OEM and the transparency of the information contained is limited. Besides, these platforms represent the possible attack pints compromising the security of the PLM. Security and transparency could be increased by using the blockchain technology [11].

2.2 BIM
As PLM is used in the mechanical engineering sector, such as automotive and aerospace, BIM is used by the architecture/engineering/construction industry to collaboratively manage a virtual representation of the physical facilities. The difference between PLM and BIM is in the fact that the mechanical engineering sector is more globalized and consolidated industry; by contrast, a majority of construction projects remain rooted in local contexts [10]. The level of automation is also different in two sectors, and BIM is generally characterized by the low level of information technology (IT) implementation. The main perception of the construction industry relative to BIM implementation challenges focuses on answering many of the same data exchange, business process and policy phasing problems that have faced PLM deployment [10].
Both PLM and BIM emphasize open communication and information exchange, collaborative decision-making, early participation and contribution of knowledge and expertise by downstream stakeholders (contractors and suppliers), and greater levels of risk sharing [10]. However, BIM has not yet solved issues of trust, reliability, and transparency [12].
BIM platforms, such as Autodesk Revit (Figure 3), originally or through external plug-ins, can be used to simulate the real-world conditions of the building, including geography, seismic data, weather conditions, sun position, and lighting. They also tend to integrate more advanced tools such as structural analysis, energy audit, seismic behavior, etc. The review presented in [13] suggests that BIM could be developed in a near future in such a way that all design and analysis tools are contained in a single software platform, most probably in the cloud computing environment.
[image: ]
Figure 3.

Autodesk Revit (source:www.autodesk.com).

This technology is emerging, and basic definitions are being upgraded and updated [1]. The main purpose of BIM 3D, based on the 3D CAD geometry, is visualization. The next generation BIM 4Dadds time-related data and facilitates programming. When costsare included, it is considered as BIM 5D. BIM 6Dadds product operationand facilities management to 3D CAD objects, enabling the monitoring of the product sustainability(sometimes referred to as BIM 7D) and product performance. BIM 7D (or BIM 8D) embeds the safetyand emergency plans to prevent security issues.



3. Blockchain
Blockchain is a digital, replicated ledger of transactions that are secured against alterations once the peer-to-peer network has validated and added the transaction to all instances of the ledger [2], allowing traceability and accountability.
Blockchain will likely affect most business processes requiring a trusted digital environment. The term was coined in 2008 by “Satoshi Nakamoto” (it is still unclear whether it is a person or an alias for a group of persons). Initially, it was meant to act as the public transaction ledger used by the cryptocurrency, Bitcoin. New applications of that system keep arising. Blockchain can be described as a simple distributed and decentralized database of transactions or contracts, chronologically stored across a wide computer network, without centralized management and a single managing authority [1].
Technically, blockchain relies on three well-known IT concepts: peer-to-peer networks, public key cryptography, and distributed consensus based on the resolution of a random mathematical challenge. The combination of these concepts allows a breakthrough in computing.
Blockchain creates fixed-size blocks of information using so-called hash functions. These blocks are then added to an array called a blockchain. Each new block is encrypted irreversibly using a hash function and then shortened to make the fixed-size output. The chain of blocks thus contains the encrypted version of the complete history of changes of all blocks. The blockchain information is prone to changes, as any change in any data transfer phase would irreversibly alter the final output. One can say that blockchain disables the famous “undo” function.
The blockchain relies on cryptographic hash functions. They are mathematical functions creating the fixed-size bit-string output (hash). It is nearly impossible to guess the length of the hash if someone tries to decrypt the blockchain. The hash algorithm produces a unique output and it is a one-way function. A Bitcoin and Ethereum blockchain both use SHA-256 (secure hash algorithm), developed in 2001 by the National Security Agency (NSA) in the USA.
The family of cryptographic hash functions include [1] the following: 224–512-bit BLAKE (BLAKE2, BLAKE3), Merkle tree-based 128–512-bit message digest algorithm (MD5, MD6), 128–320-bit RACE Integrity Primitives Evaluation Message Digest (RIPEMD), 224–512-bit secure hashing algorithm (SHA-2 also known as SHA-256 or SHA-512, SHA-3), Russian 256, 512-bit Streebog, etc. These hash functions are implemented in programming languages as classes, which can contain more different algorithms. These hash functions differ slightly in the way they create output from a given input data and in the length of a produced output (number of bits). Figure 4 shows an example of a hashed filename. If only one letter in the file name is changed, the MD5 hash function gives an entirely different hash digest. The same is valid for any other information, but the hash digest always has the fixed 128-bit size (32 characters in hexadecimal notation).
[image: ]
Figure 4.

Using MD5 hash function for irreversible data encryption.

Information stored in the blockchain cannot be altered or lost. It replicates into the same number of copies as there are nodes in the network. The blockchain stores the complete history of all previous states of information stored. In that way, anyone could check the final state validity simply by using the same hashing algorithm to all information from the beginning to the end. The blockchain uses hash functions to encrypt information and to digitally sign the information from all previous steps. Hash functions are much older than blockchain, and they were used to encrypt data for decades. A good hash function has some main characteristics as follows: (1) The hash value is fully determined by the input data and gives unique result for any input, (2) Even though the output has fixed length, the hash function uses all input data, (3) The hash function “uniformly” distributes the data across the entire set of possible hash values, (4) The hash outputs of similar strings are very different, (5) The hash function is computationally efficient, and (6) The hash does not reveal any information about the input.
3.1 How does blockchain technology works?
Blockchain (with a capital B) was originally defined as the electronic ledger for Bitcoin. Today, blockchain (lowercase, as in blockchain technology) is most easily defined by an example [14] as follows:
	Some data is stored in a Microsoft Excel workbook. This file can be shared with collaborators as an e-mail attachment. Any change made by collaborators needs to be returned by e-mail and then merged with the original document. If there are more collaborators, this makes the process cumbersome and increases chances of error.

	Cloud-based sharing services such as Microsoft Office365 or Google Sheets can be used to overcome this problem. Collaborators do not receive an e-mail attachment but only a link to the online file. More collaborators can update the spreadsheet simultaneously, and there is a version history showing what changes are made by whom and when. This sounds much better from a collaborative point of view, but there is still a chance that any user with enough credentials can erase or alter the file in the cloud. A blockchain can provide a solution to this problem.


Blockchain is also the cloud-stored shared information but is duplicated thousands of times across a network of computers, which has been designed to regularly update this sheet. Information held on a blockchain exists as a shared and continually reconciled database (i.e., once every 10 min). Each group of transactions in the database is referred to as a block which cannot be altered once added to the chain.
Blockchain security relies on encryption, based on the public and private keys. The keys are long, randomly generated strings of numbers. The public key represents a user’s ID on the blockchain, and the private key, which must be safeguarded, is used to digitally sign the transaction, providing for data traceability and integrity.
Figure 5 shows how each block in the blockchain contains the cryptographic hash of the previous block, which cannot be changed. Each next block strengthens the verification of the previous block and the blockchain’s security. Adding new blocks increases the reliability of the blockchain.
[image: ]
Figure 5.

The sequence of the hash value in the blockchain.

The blocks contain public data, such as product ID, user manuals, disposal, and recycling guidelines, and transaction data, such as CAD files, technical and material specifications, mechanical properties, assembly instructions, requisition orders, signatures, and cryptography keys [11].
The blockchain consists of linear sequence blocks, which are added to chain with the regular intervals [15]. The information in the blocks depends on the blockchain network, but the timestamp, transaction, and hash exist in all the blockchain variants. The blockchain relies on several specific mechanisms such as PoW, PoS, PBFT, and delegated proof-of-stake (DPoS) [16, 17].
The proof-of-work (PoW) mechanism works by determining the node that writes a block on ledgers. The nodes in the network compete to solve a mathematical puzzle (generally a computationally complex but easily verifiable pattern) to record a transaction. After the puzzle is solved, other nodes in the network reach consensus by broadcasting the solution. The two most popular blockchain systems, Bitcoin and Ethereum, operate on the PoW mechanism, involving extensive computing power and cumbersome mining processes to create new blocks.
The proof-of-stake (PoS) mechanism chooses the creator of the block in a deterministic method. It requires the credibility of data, denoted by proof of ownership. This method operates solely on transaction fees.
The practical Byzantine fault tolerance (PBFT) algorithm, used by Hyperledger Fabric, is a consensus method that can tolerate a maximum of 1/3 malicious byzantine replicas. A primary is selected in each round and is responsible for ordering the transaction. PBFT requires each node to query other nodes.
The delegated proof-of-stake (DPoS) algorithm lets stakeholders elect representatives to validate blocks. Since this mechanism features a smaller number of nodes, the transaction processing is faster.
Figure 6 illustrates the processes of signing and verification of blocks in the blockchain. The process is based on the private/public key cryptography. Each transaction is verified by the previous block owner’s public key and signed by his private key. The hash function ensures data integrity as it is irreversible.
[image: ]
Figure 6.

The signing and verification in the blockchain.

Common uses of blockchain now include financial services (payments, money transfer, customer benchmarking, and full trade life cycle management), supply chain (traceability of product components, electronic compliance records, patent-pending, quality control data, and non-repudiation of IoT sensor data), public sector (government-managed personal data records, import/export customs and taxes, regulatory certifications, and digital citizen identity), and health care (personal health records, credentials of service providers, and clinical data). This list is likely to expand, and new applications appear daily. This makes blockchain a “solution seeking for problems that need to be solved.”



4. Utilizing blockchain in distributed CAD environments
As more available resources and stakeholders are involved during the product life cycle, the exchange and management of product-related information become a challenging task, affecting significantly the intellectual property protection process as well as the distinction of roles among stakeholders [11].
In a modern engineering environment, projects rely on teamwork, where team members with the same or different experience, skills, and function have to collaborate intensively. Very often, team members do not share the same office space, and sometimes they are globally distributed. This increases the need for reliable and traceable data. Traceability, in this case, means that each change in an engineering project can easily be attributed to a team member who made it and who “owns” the process step. All team members have to have their digital signature. Using cryptographic hash functions to encrypt data and blockchain to make it change-proof keeps the complete supply chain transparent, reliable, and traceable.
If there is a centralized authority providing traceability and reliability of data, this would make the information vulnerable to external attacks. As blockchain is decentralized and distributed, it becomes very secure, traceable, and reliable.
Figure 7 shows an example of how blockchain can be used to enable data integrity in the product development process. Each block consists of public data and encrypted transaction data. Both data is hashed and stored in encrypted form, the signature contains the timestamp, nonce, and each block contains the hash from the previous block. The term nonce is used to describe an arbitrary number called “number used once” or “number once,” which is used with the timestamp to add another level of difficulty [18]. If any unauthorized data alteration is made within the process, the resulting blockchain is compromised and the owner is aware that changes have been made. The blocks are distributed within the network of users, thus eliminating the need for a single verification authority.
[image: ]
Figure 7.

The blockchain primer for CAD-based development process.

Some potential uses of blockchain in construction are mentioned in [19]: storing sensor data from buildings in a trustworthy and distributed way, maintaining records of digital property, timestamping acts or transactions, automated dispute resolution and smart cities, and in real estate investment. The same authors suggest using blockchain on the construction site to improve logbooks’ reliability and to monitor workers’ performance and material balance in a more reliable way. They also suggest using blockchain in the maintenance phase when sensors are used to collect sensitive data and blockchain has the potential to store the data securely, thus improving data privacy. However, they don’t see any use of blockchain in the initial phases, when architectural design and Bill of Materials are created.
Other potential applications of blockchain in construction engineering management suggested in [20] are: notarization-related applications to eliminate the verification time of documents’ authenticity, transaction-related applications to facilitate automated procurement and payment, and provenance-related applications to improve the transparency and traceability of construction supply chains.
More potential applications of blockchain in the preconstruction stage, where the use of BIM is at its maximum, are suggested in [21]. Blockchain can enhance stakeholder confidence by enabling change tracking, establishing clear liabilities, providing visual evidence of information ownership, and reducing disputes over information authenticity. A distributed database avoids concentration of ownership and eliminates misuse and corruption of information, making it suitable for legal proofs.
During the design phase, any information exchange could be managed using blockchain to ensure that consensus is reached among all stakeholders. During the construction phase, invoicing and payments could be managed by blockchain-verified transactions. During operation, blockchain can be used to ensure that data collected by IoT sensors are validated and reliable, making, that is, HVAC installers and contractors accountable for sustainability targets declared during the design phase.
Blockchain is a technology that can help reduce confusion and the resulting litigation between a large number of parties involved in engineering projects. Blockchain may be part of the automation process, helping people make more things, better things, with less effort; more and better in terms of increasing efficiency, performance, quality, and innovation; and less in terms of time, resources, and negative impacts (e.g., social, environmental).

5. The major implementation challenges
The main disadvantages of the blockchain identified in [15] are: the high energy consumption, due to high demand for computing power used for the calculation process, and the balance between the number of nodes and the favorable user costs.
The key advantages of blockchain identified in [22] include decentralization, persistency, non-repudiation, anonymity, and auditability. Some of the most common vulnerabilities are end point vulnerabilities, public and private key security, blockchain integration platforms, untested at full scale, lack of standards and regulation, and untested code and vulnerabilities on smart contracts.
Turk and Klinc [19] observed that BIM files are usually huge, making the implementation of blockchain too demanding. They suggest that proper position for the integration of blockchain could be between the transaction-processing component of the BIM server and its storage functionality, adding signed fingerprints to any information interchange. The biggest advantage blockchain technology provides is in using smart contracts to negotiate editing privileges and storing an immutable public record of all modifications to the model [20].

Advertisement
6. CAD data integrity
6.1 Information security
Information security consists of three components: confidentiality, integrity, and accessibility. Confidentiality protects against unauthorized disclosure of information. Integrity involves protection from unauthorized modifications of data—preventing adding, deleting, or changing the stored digital records. Availability means that data are fully available to authorized users when needed.
The integrity of the information means that the user’s data cannot be changed without permission or that the information must be correct and complete. Confidential information must be protected from unauthorized changes, especially in a system such as financial institutions, health-care institutions, energy systems, etc., because the intentional or unintentional ordering of integrity can have catastrophic consequences. Preserving the integrity of information ensures this accuracy and correctness. The most important aspect of maintaining integrity is user authentication or identity verification to ensure that only authorized people can modify data in the system. The information must not be changed by accident or by the mistake of the user or the system. When handling confidential information, it is necessary to provide a strictly confidential environment that reduces the possibility of both intentional and accidental changes.

6.2 Data integrity threats
Trust is the key feature of blockchain technology [20]. If the construction activities are supported by the blockchain system, participants rely on blockchain to establish the trust relationship. Also, blockchain technology makes every participant a custodian of all the information flowing through the project’s life cycle. Thus, blockchain creates an opportunity from the vulnerability; although the information is public, distributed, and unprotected, the traceability provided by blockchain ensures that any information stored in a blockchain is safe and cannot be altered.
Figure 8 shows how blockchain can be implemented in an engineering environment consisting of 3D CAD modeling and computer simulation (i.e., static structural analysis). A random string “0” serves as a cryptographic public key and is used to confirm the authenticity of the final output. The CAD ";"""og:image"",""https://cdn.intechopen.com/books/images_new/7603.jpg""
""DC.AccessRights"",""open-access""
""citation_publication_date"",""2020/09/24""
""citation_isbn"",""978-1-83962-623-4""
""twitter:card"",""summary""
""citation_title"",""Blockchain-Based Data Integrity for Collaborative CAD""
""theme-color"",""#ffffff""
""citation_reference"",""Lemeš S, Lemeš L. Blockchain in distributed CAD environments. In: International Conference on “New Technologies, Development and Applications,” 2019 June 27. Cham: Springer; 2019. pp. 25-32. DOI: 10.1007/978-3-030-18072-0_3"",""Nguyen B et al. Blockchain and the Built Environment. London: ARUP; 2019. Available from: https://research.arup.com/download/7605 [Accessed: 23 February 2020]"",""Caulfield J. Chain of Command: Blockchain for AEC [Internet]. 2019. Available from: https://www.bdcnetwork.com/chain-command-blockchain-aec [Accessed: 12 February 2020]"",""Valero F. BIM and Blockchain. Barcelona: Zigurat Global Institute of Technology. 2018. Available from: https://www.e-zigurat.com/blog/en/bim-and-blockchain/ [Accessed: 12 February 2020]"",""Cousins S. French Start-Up Develops Blockchain Solution for BIM. UK: BIM+ Task Group; 2018. Available from: http://www.bimplus.co.uk/news/french-start-develops-blockchain-solution-bim/ [Accessed: 12 February 2020]"",""Gueguen A. BIM and Blockchain an Alliance that Makes Sense. Paris, France: Lutecium SAS; 2018. Available from: https://bimchain.io/bim-and-blockchain-an-alliance-that-makes-sense/ [Accessed: 12 February 2020]"",""Mell P, Grance T. The NIST Definition of Cloud Computing. Recommendations of the National Institute of Standards and Technology. Gaithersburg, Maryland, US: NIST Special Publication 800-145; 2011. DOI: 10.6028/NIST.SP.800-145"",""Phadnis VS, Leonardo KA, Wallace DR, Olechowski AL. An exploratory study comparing CAD tools and working styles for implementing design changes. In: Proceedings of the Design Society: International Conference on Engineering Design, 2019 July, Vol. 1, No. 1. Cambridge, UK: Cambridge University Press; 2019. pp. 1383-1392. DOI: 10.1017/dsi.2019.144"",""Kurpjuweit S, Schmidt CG, Klöckner M, Wagner SM. Blockchain in additive manufacturing and its impact on supply chains. Journal of Business Logistics. 2019. pp. 1-25 (Special Issue). DOI: 10.1111/jbl.12231"",""Jupp JR, Nepal M. BIM and PLM: Comparing and learning from changes to professional practice across sectors. In: Fukuda S, Bernard A, Gurumoorthy B, Bouras A, editors. Product Lifecycle Management for a Global Market. PLM 2014. IFIP Advances in Information and Communication Technology, Vol. 442. Berlin, Heidelberg: Springer; 2014. DOI: 10.1007/978-3-662-45937-9_5"",""Papakostas N, Newell A, Hargaden V. A novel paradigm for managing the product development process utilising blockchain technology principles. CIRP Annals. 2019;68(1):137-140. DOI: 10.1016/j.cirp.2019.04.039"",""Dounas T, Lombardi D, Jabi W. Towards blockchains for architectural design—Consensus mechanisms for collaboration in BIM. 37 Education and Research in Computer Aided Architectural Design in Europe and XXIII Iberoamerican Society of Digital Graphics, Joint Conference (N. 1). In: Proceedings Blucher Design. Vol. 7, 2009, pp. 267-274. ISSN: 2318-6968"",""Nawari NO, Ravindran S. Blockchain technology and BIM process: Review and potential applications. ITcon. 2019;24:209-238"",""Sheppard S. Autodesk is Investigating Blockchain for AEC. 2018. Available from: https://labs.blogs.com/its_alive_in_the_lab/2018/05/autodesk-in-investigating-blockchain-for-aec.html [Accessed: 15 June 2020]"",""Golosova J, Romanovs A. The advantages and disadvantages of the blockchain technology. In: 2018 IEEE 6th Workshop on Advances in Information, Electronic and Electrical Engineering (AIEEE). Vilniaus Apskritis, Lithuania: IEEE; 8 November 2018. pp. 1-6. DOI: 10.1109/AIEEE.2018.8592253"",""Nawari NO, Ravindran S. Blockchain technologies in BIM workflow environment. In: Computing in Civil Engineering 2019: Visualization, Information Modeling, and Simulation 2019 June 13. Reston, VA: American Society of Civil Engineers; 2019. pp. 343-352. DOI: 10.1061/9780784482421.044"",""Zheng Z, Xie S, Dai H, Chen X, Wang H. An overview of blockchain technology: Architecture, consensus, and future trends. In: 2017 IEEE International Congress on Big Data (BigData Congress), 2017 June 25. IEEE; 2017. DOI: 10.1109/BigDataCongress.2017.85"",""Memon RA, Li JP, Ahmed J, Nazeer MI, Ismail M, Ali K. Cloud-based vs. blockchain-based IoT: A comparative survey and way forward. Frontiers of Information Technology &amp; Electronic Engineering. 2020;21(4):563. DOI: 10.1631/FITEE.1800343"",""Turk Ž, Klinc R. Potentials of blockchain technology for construction management. Procedia Engineering. 2017;196:638-645. DOI: 10.1016/j.proeng.2017.08.052"",""Wang J, Wu P, Wang X, Shou W. The outlook of blockchain technology for construction engineering management. Frontiers of Engineering Management. 2017;4(1):67-75. DOI: 10.15302/J-FEM-2017006"",""Erri Pradeep AS, Yiu TW, Amor R. Leveraging blockchain technology in a BIM workflow: A literature review. In: International Conference on Smart Infrastructure and Construction 2019 (ICSIC) Driving Data-Informed Decision-making. London, UK: ICE Publishing; 2019. pp. 371-380. DOI: 10.1680/icsic.64669.371"",""Leka E, Selimi B, Lamani L. Systematic literature review of blockchain applications: Smart contracts. In: 2019 International Conference on Information Technologies (InfoTech). Sofia, Bulgaria. 2019 September 19. IEEE; 2019. pp. 1-3. DOI: 10.1109/InfoTech.2019.8860872"",""Penzes B. Blockchain Technology in the Construction Industry. One Great George Street, Westminster, London, Institution of Civil Engineers; 2019. DOI: 10.13140/RG.2.2.14164.45443"",""Azuma RT. A survey of augmented reality. Presence Teleoperators and Virtual Environments. 1997 Aug;6(4):355-385. DOI: 10.1162/pres.1997.6.4.355""
""citation_publisher"",""IntechOpen""
""description"",""Distributed and collaborative computer-aided design (CAD) environments include building information modeling (BIM) and geographical information systems (GISs) in civil engineering and architecture, or product data management/product life cycle management (PDM/PLM) in mechanical engineering. It is essential to keep the data integrity in these computer applications as it contributes to buildingusers’ confidence in CAD/BIM/PDM data. Blockchain technology, the core foundation of cryptocurrencies, is increasingly being used for other purposes and could solve the data integrity issue in collaborative CAD environments. However, it has some disadvantages such as the transparency of data and the slowness of storing data in the blockchain due to distributed consensus. Increasing demand by the Industry 4.0, IoT, Smart Cities, and other initiatives could foster the best what blockchain has to offer: data integrity, reliability, and traceability. This chapter explains how blockchain works, how can it be utilized in distributed CAD environments, what are the major challenges for implementation, and how CAD vendors could use it to increase CAD data integrity.""
""language"",""en""
""title"",""Blockchain-Based Data Integrity for Collaborative CAD | IntechOpen"",""Blockchain-Based Data Integrity for Collaborative CAD | IntechOpen""
""og:description"",""Distributed and collaborative computer-aided design (CAD) environments include building information modeling (BIM) and geographical information systems (GISs) in civil engineering and architecture, or product data management/product life cycle management (PDM/PLM) in mechanical engineering. It is essential to keep the data integrity in these computer applications as it contributes to buildingusers’ confidence in CAD/BIM/PDM data. Blockchain technology, the core foundation of cryptocurrencies, is increasingly being used for other purposes and could solve the data integrity issue in collaborative CAD environments. However, it has some disadvantages such as the transparency of data and the slowness of storing data in the blockchain due to distributed consensus. Increasing demand by the Industry 4.0, IoT, Smart Cities, and other initiatives could foster the best what blockchain has to offer: data integrity, reliability, and traceability. This chapter explains how blockchain works, how can it be utilized in distributed CAD environments, what are the major challenges for implementation, and how CAD vendors could use it to increase CAD data integrity.""
""twitter:image"",""https://cdn.intechopen.com/books/images_new/7603.jpg""
""citation_online_date"",""2020/09/24""
""dc:title"",""Blockchain-Based Data Integrity for Collaborative CAD | IntechOpen""
""citation_public_url"",""https://www.intechopen.com/books/mixed-reality-and-three-dimensional-computer-graphics/blockchain-based-data-integrity-for-collaborative-cad""
""citation_fulltext_html_url"",""https://www.intechopen.com/books/mixed-reality-and-three-dimensional-computer-graphics/blockchain-based-data-integrity-for-collaborative-cad""
""Content-Encoding"",""UTF-8""
""DC.Format"",""text/html""
""DC.Publisher"",""IntechOpen""
""citation_pdf_url"",""https://www.intechopen.com/citation-pdf-url/73091""
""Content-Length"",""387238""
""DC.Contributor"",""Samir LemeĹĄ""
""Content-Type"",""text/html; charset=UTF-8""
""citation_fulltext_world_readable"",""""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""og:type"",""article""
""DC.Identifier"",""10.5772/intechopen.93539""
""og:title"",""Blockchain-Based Data Integrity for Collaborative CAD""
""DC.Title"",""Mixed Reality and Three-Dimensional Computer Graphics""
""citation_inbook_title"",""Mixed Reality and Three-Dimensional Computer Graphics""
""citation_author"",""Samir LemeĹĄ""
""resourceName"",""blockchain-based-data-integrity-for-collaborative-cad""
""msapplication-TileColor"",""#e10000""
""X-UA-Compatible"",""IE=edge""
""viewport"",""width=device-width,initial-scale=1""
""DC.Language"",""en""
""citation_doi"",""10.5772/intechopen.93539""
""DC.Date"",""2020/09/24""
""citation_access"",""all""
""category"",""Chapter""
""og:url"",""https://www.intechopen.com/books/mixed-reality-and-three-dimensional-computer-graphics/blockchain-based-data-integrity-for-collaborative-cad""
""Content-Language"",""en""
""DC.relation.ispartof"",""Mixed Reality and Three-Dimensional Computer Graphics""
""authors"",""Samir LemeĹĄ""
";https://scholar.google.ch/scholar?start=900&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098853-309;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Consensus from signatures of work;JA Garay, A Kiayias, G Panagiotakos ; Cryptographers' Track at the RSA …, 2020  Springer;;"… such enabling functionality as a stand-alone cryptographic primitive, and relied instead on the

random oracle (RO) model [10] or similar idealized assumptions (cf. the \(\mathcal {F}_{\textsc

{tree}} \) functionality in [43]) to prove directly the properties of the blockchain protocol …";Cité 6 fois;Les 3 versions;[PDF] allquantor.at;https://allquantor.at/blockchainbib/pdf/garay2017consensus.pdf;"
Consensus from Signatures of Work

Juan A. Garay
Texas A&M University

garay@cse.tamu.edu

Aggelos Kiayias*

University of Edinburgh
& IOHK

akiayias@inf.ed.ac.uk

Giorgos Panagiotakos
University of Edinburgh
giorgos.pan@ed.ac.uk

April 13, 2020

Abstract

Assuming the existence of a public-key infrastructure (PKI), digital signatures are a fundamen-
tal building block in the design of secure consensus protocols with optimal resilience. More recently,
with the advent of blockchain protocols like Bitcoin, consensus has been considered in the “permis-
sionless” setting where no authentication or even point-to-point communication is available. Yet,
despite some positive preliminary results, all attempts to formalize a building block that is sufficient
for designing consensus protocols in this setting, rely on a very strong independence assumption
about adversarial accesses to the underlying computational resource.

In this work, we relax this assumption by putting forth a primitive, which we call signatures
of work (SoW). Distinctive features of our new notion are a lower bound on the number of steps
required to produce a signature; fast verification; moderate unforgeability—producing a sequence
of SoWs, for chosen messages, does not provide an advantage to an adversary in terms of running
time; and honest signing time independence—most relevant in concurrent multi-party applications,
as we show.

Armed with SoW, we then present a new permissionless consensus protocol which is secure
assuming an honest majority of computational power, thus in a sense providing a blockchain coun-
terpart to the classical Dolev-Strong consensus protocol. The protocol is built on top of a SoW-based
blockchain and standard properties of the underlying hash function, thus improving on the known
provably secure consensus protocols in this setting, which rely on the strong independence property
mentioned above in a fundamental way.

*Research partly supported by Horizon 2020 project PANORAMIX, No. 653497.

1



Contents

1 Introduction 3

2 Preliminaries 8

3 Signatures of Work 10

4 Applications 13
4.1 The Permissionless Model, Revisited . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.2 Public Transaction Ledger from Signatures of Work . . . . . . . . . . . . . . . . . . . 15

4.2.1 The Bitcoin backbone protocol. . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.2.2 Security properties of the blockchain. . . . . . . . . . . . . . . . . . . . . . . . . 17
4.2.3 Security proof. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

4.3 Consensus from Signatures of Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

5 SoW Constructions from Idealized Assumptions 31

2



1 Introduction

The consensus problem—reaching agreement distributedly in the presence of faults—has been exten-
sively studied in the literature starting with the seminal work of Shostak, Pease and Lamport [48, 42].
The problem formulation has a number of servers (parties) starting with an individual input which
should agree at the end to a joint output that has to match the input in the case where all non-faulty
servers happened to have the same input value. One of the critical measures of effectiveness for con-
sensus protocols is maximizing their resilience to Byzantine faults, typically denoted by t. It is known
that t < n/2 is necessary to achieve consensus, where n is the total number of parties, while protocols
have been designed that reach that level of resilience assuming synchrony and a way to authenticate
messages using digital signatures [22]1 (or “pseudosignatures” [49]). This result is known to be tight
since lack of synchrony would imply t < n/3 [24] (as well as randomization [27]), while lack of a
message authentication mechanism has a similar effect [18].

Recently, with the advent of blockchain protocols like Bitcoin, the problem has experienced renewed
interest from a much wider community of researchers and has seen its application expand to various
novel settings, such as the so-called “permissionless” setting, where participation in the protocol is
both unrestricted and unauthenticated. In fact, this setting was initially studied in [45, 46], where it
was shown that deterministic consensus algorithms are impossible for even a single failure but that
probabilistic consensus is still feasible by suitably adapting the protocols of [13, 26]. Nevertheless, the
resulting protocol required exponentially many rounds in n.

The first efficient solutions for the consensus problem in the permissionless setting were formally
shown to be possible utilizing an abstraction of the Bitcoin blockchain protocol in [31], against adver-
saries controlling less than half of the computational power which, in a uniform configuration (meaning
parties are endowed with the same computational power), corresponds to a number of Byzantine faults
t < n/2 in the original setting. At a high level, these protocols (as well as the Bitcoin blockchain pro-
tocol itself) rely on a concept known as proofs of work (PoW), which, intuitively, enables one party to
convince others that he has invested some computational effort for solving a given task. While being
formulated a while back [25] and used for a variety of purposes—e,g, spam mitigation [25], sybil at-
tacks [23], and denial of service protection [38, 5]—their role in the design of permissionless blockchain
protocols [44], is arguably their most impactful application.

In the context of permissionless blockchain protocols, the way a PoW-like primitive helps is by
slowing down message generation for all parties indiscriminately, thus generating opportunities for
honest parties to converge to a unique view under the assumption that the aggregate computational
power of honest parties sufficiently exceeds that of the adversary. Now, while this intuition matches the
more rigorous analyses of the Bitcoin protocol that have been carried out so far [31, 47, 32, 7], these
works have refrained from formally defining such enabling functionality as a stand-alone cryptographic
primitive, and relied instead on the random oracle (RO) model [11] or similar idealized assumptions
(cf. the Ftree functionality in [47]) to prove directly the properties of the blockchain protocol. The
same is true for other provably secure PoW-based distributed protocols [3, 39, 33].

The core of the hardness (or even impossibility [20]) of implementing the assumed idealized re-
sources is that they satisfy a strong independence property: Each bit output on a new query to the
resource is independently sampled, even if the adversary is the one who is accessing the resource. This
is indeed a very strong property, as it directly implies that the best way to compute a PoW for both
an honest party and the adversary is brute force. Moreover, the same property is explicitly used to
argue the security of the proposed consensus protocols in the PoW setting [31, 3], as we explain in

1Recall that the protocol in [22] tolerates an arbitrary number of Byzantine faults (n > t), but in the version of the
problem of a single sender (a.k.a. “Byzantine Generals,” or just broadcast); in the case of consensus, t < n/2 is necessary
regardless of the resources available to the parties in the protocol execution (see, e.g., [28, 29]).

3



detail later.
In this work we make progress in relaxing this assumption, by putting forth a formalization of a

PoW-like primitive, which we call signatures of work (SoW). An SoW can be implemented in the RO
model or by using Ftree, but the adversarial SoW computation process does not necessarily satisfy such
strong guarantees as the ones mentioned above. Indeed, in contrast to previous approaches, only an
upper bound on the rate at which the adversary generates SoWs needs to be assumed. We then present
a new permissionless consensus protocol based on SoWs that can be proven secure without relying
on such strong independence guarantees. The protocol utilizes a SoW-based blockchain and standard
properties of the underlying hash function, and is secure assuming an honest majority of computational
power. As a result, this protocol can be seen as an exemplar of how a permissionless signature-like
primitive enables honest majority consensus in the same way that classical digital signatures imply
honest-majority consensus protocols in the traditional setting.

Why signatures of work? We first provide some intuition behind the relevance of SoW as a useful
primitive for the design of permissionless distributed protocols. Recall the main property of a digital
signature in the design of classical consensus protocols: It enables parties to communicate to each
other their protocol view and inputs at a certain stage of the protocol execution in a way that is
transferable and non-repudiable. Indeed, Bob, upon receiving Alice’s signed message, can show it to
Charlie in a way that the latter is unequivocally convinced of the message’s origin. It follows that
Bob cannot modify Alice’s messages, playing man-in-the-middle between Alice and Charlie, and thus
Alice can be held accountable in case she provides conflicting views to the two parties. A SoW scheme
provides a similar capability: Using a SoW, a party like Alice can invest effort into a specific protocol
view and inputs, so that when Bob is presented with a SoW produced by Alice it will be infeasible for
Alice to provide a conflicting view and inputs to Charlie, unless she invests twice the effort. Moreover,
the above argument holds without establishing any set of identities among the parties, so for example
Bob does not need to know he talks to Alice per se but rather to an arbitrary party that invested some
effort with respect to a specific protocol view. Furthermore, exactly like digital signatures, SoWs can
be chained recursively, enabling the parties to build on each other’s protocol view.

While the above functionalities hint to the usefulness of SoWs in the distributed permissionless
setting, formalizing and applying them properly is no simple task. Firstly, in contrast with classical
signatures, there is no secret key involved in this primitive. This make sense, since in a permisionless
setting signing messages using some kind of secret information is meaningless, as parties do no have
any secret setup to begin with. Hence, if they are to sign any message, they should use some other kind
of resource that only they have access to, such as their computational power. Secondly, in classical
signatures, the exact time when the verification key becomes available to different parties is irrelevant;
The key is only useful for verification, up to polynomial-time differences. In the context of SoWs,
however, this time is of great importance. For example, allowing a party to learn the verification key,
say, two days earlier than other parties, means that this party will be able to compute two days worth
of signatures more than them. Hence, in contexts where counting the number of generated signatures
matters, as is the case in blockchain protocols, great care should be taken on guaranteeing that the
verification key is “fresh” enough for the relevant application.

Our results. Our contributions are are as follows:

1) Formalization of an SoW scheme. The syntax of an SoW scheme entails four algorithms: Pub-
lic parameter generation, key generation, signing and verification—PPub,KeyGen, Sign and Verify,
respectively. PPub is invoked on input 1Îť, where Îť is the security parameter, and outputs public
security parameters pp. KeyGen is invoked on input pp, and outputs a random verification key vk.
Sign is invoked on input (pp, vk,msg , h), where msg is the message to be signed, and h is the hardness
level of the signature generation. Expectedly, Verify is invoked on input (pp, vk,msg , h, σ), where σ is
(possibly) an output of Sign. We require a SoW scheme to be:

4



Correct: As in the case of classical signatures, we require that signatures produced by Sign should
be accepted by the Verify algorithm.

(t, Îą)-Successful: This property lower-bounds the probability that an honest signer will success-
fully produce a SoW in a certain number of steps t; Îą is a function of the hardness level h.

t-Verifiable: The verifier should be able to verify a SoW in t steps. (Typically, t is a lot smaller
than the time need to produce a signature.)

Moderately Unforgeable against Tampering and Chosen-Message Attacks ((β, ξ)-MU-
TCMA): This property is akin to the property of existential unforgeability under chosen-message
attacks of digital signatures (EU-CMA). It captures the fact that producing a sequence of SoWs,
for chosen messages, does not provide an advantage to an adversary in terms of running time.
Specifically, the chances to produce more than β ¡ t SoWs in t steps (for any t) are less than ξ.2

Further, this should hold against an adversary able to tamper with the keys, and even in the
presence of a Sign oracle.

Run-time independent: This final property captures the setting where honest signers are po-
tentially invoked on adversarial inputs and ensures that their running time enjoys some degree of
independence. Specifically, the random variables defined as the running time of each Sign invo-
cation is a set of almost independent random variables (cf. [1]). We stress that the adversarial
signing algorithm may not satisfy this property.

As a “sanity check,” we show in the full version of the paper that a SoW scheme can be easily
designed and proven secure in the random oracle model (or by using Ftree), and hence in practice can
be instantiated by a cryptographic hash function such as SHA-256.

2) Consensus from SoW. Next, we design a consensus protocol for an honest majority of computational
power that can be reduced to the SoW primitive above. The core idea behind our new protocol is as
follows. First, the parties build a blockchain using SoWs in a way reminiscent of the Bitcoin blockchain.
Using SoWs we show how to emulate the Bitcoin backbone protocol [31] by having parties compute
a SoW in parallel, “on top” of the current view that incorporates the largest number of SoWs, i.e.,
the longest chain. However, in contrast with the consensus protocol of [31], to generate a block, the
parties include not only their input to the consensus protocol, but also the headers of “orphan” blocks
that exist in forks stemming off their main chain and which have not been included so far, where the
header of a block contains the hash of the previous block in the chain, the signature, the input to the
consensus protocol, and a hash of the block’s contents.

Using this mechanism, as shown in Figure 1, we prove that it is possible to reconstruct the whole
tree of block headers from the blockchain contents, and thus in this way preserve all block headers
produced by the honest parties. This ensures that the resulting ledger will reflect the number of parties
and hence a consensus protocol may now be easily reduced to this blockchain protocol.

Our new consensus protocol relying on the SoW primitive in the setting where no PKI is available,
exemplifies the contrast with consensus in the classical setting, relying on standard signatures and a
PKI setup [22] (cf. [29]). It is worth noting that the only known blockchain-based provably secure
and optimally resilient consensus protocol is given in [31], using a technique called “2-for-1 PoW”
where two PoW-based protocols can be run concurrently and create a blockchain where the number
of honest-party contributions is proportional to their actual number, but which relies on the strong
independence property of the RO model, discussed earlier, in a fundamental way. Indeed, in the RO
model, each witness for a PoW can be rearranged in a certain way so as to obtain a test for a witness
for another PoW in a way that is independent from the first solution. Our new protocol gets rid of

2Note that, unlike previous unforgeability definitions (e.g, [12]), this definition is parameterized by the rate β at
which the adversary can produce signatures, instead of the number of steps it needs to compute one. We feel that this
formulation is more appropriate for the moderate unforgeability game where the adversary tries to produce multiple
signatures. For further details, see Definition 7.

5



BGen

A[0] B[1]

C[1] D[1]

? ?

E[0]

G[0]

F[1]

he
ad
er

Figure 1: The data structure maintained by the consensus protocol. Block F has consensus input 1,
and includes the headers of blocks D and G, with input 1 and 0, respectively. Block D includes the
headers of invalid blocks. This is not a problem, since any chain that contains D will be invalid and
not selected by any party, while D’s consensus input is correctly counted as a valid block header.

this need. The only other (non-blockchain) PoW-based consensus protocol [3] also relies on the RO
model.

As intermediate steps in our analysis, we first introduce an appropriate adaptation of the model
of [31] that allows for a standard model analysis and which may be of independent interest. We then
recall the three basic properties of the blockchain data structure presented in [31]: (strong) common
prefix, chain quality and chain growth, and show how our SoW-based blockchain protocol satisfies
them assuming, beyond the security of SoW, standard collision resistance from the underlying hash
function that is used to “glue” the blocks together. This is achieved as follows: We first prove that
using the MU-TCMA property and assuming the adversarial hashing power is suitably bounded, it is
unlikely in any sufficiently long time window for the adversary to exceed the number of SoWs of the
honest parties. Then, using the (t, ι)-Successful and (β, ξ)-MU-TCMA properties in conjunction with
run-time independence, we establish that summations of running times of successive Sign invocations
have the variance needed to ensure that “uniquely successful rounds” (i.e., rounds where exactly one
of the honest parties produces a SoW) happen with high density in any sufficiently long time window.
Using these last two core results, and under suitable constraints for the basic SoW parameters ι, β, ξ, h
and number of parties n, we prove that the the security of the Bitcoin backbone protocol implements a
robust transaction ledger [31]. Further, and as a sanity check, in the full version of the paper, we argue
that the results we get from our black-box analysis (and the RO-based SoW construction mentioned
earlier), are similar to those from the random-oracle analysis of [31].

Our analysis is carried out in the synchronous setting. It is relatively straightforward to extend
our results to the ∆-synchronous setting of [47], by using the same techniques as in [30] (Section 7)].
We leave as an open question extending our results to the variable difficulty setting of [32].
3) Other applications. In addition to the blockchain and consensus applications of SoW, we note
that the security properties we put forth are suitable for the more traditional DDOS setting, with
considerable advantages over existing approaches (cf. [54]). The problem is as follows: A server
wants to protect itself from malicious actors in the network which send network packets to eat up
its resources. The canonical defense for this attack is for the server to run a PoW challenge-response
protocol with the sender, in order to make sending a message costly. The MU-TCMA property, we
have defined, directly implies exactly this property in the strongest sense: For any, adaptively selected,
set of messages sent, the adversary must consume computational resources proportional to the number
of messages, even if it can also see SoWs sent by other parties. Moreover, this process can be made
non-interactive by delegating the generation of the verification key to some public randomness service,
e.g., the NIST beacon, and only accept messages that include a SoW with respect to this key. Finally,
note that the same security guarantees can be easily extended to multiple servers who use the same

6



beacon, by requiring that the sent messages contain some unique identification string.

Prior and related work. We have already mentioned above relevant related work regarding classical
and blockchain-based consensus protocols. For a more exhaustive recent survey, refer to [29]. We also
note that the focus of the paper is the original consensus problem [48, 42], and not so-called “ledger
consensus” (sometimes referred to as “Nakamoto consensus”), which is an instance of the state machine
replication problem [51]; see also [29] for an overview of such protocols. The idea of referencing off-
chain blocks has been considered early on in the ledger consensus literature (see, e.g., [43, 53, 52, 14])
as a way to obtain fairness, better throughput and faster confirmation times. Our novelty is that we
leverage this technique along with the new SoW notion to build a provably secure consensus protocol,
which, unlike prior results, is not based on the “2-for-1 PoW” technique described earlier.

There have been a number of attempts to formalize a proof of work (PoW) primitive that it is also
sufficient to imply the security of a blockchain protocol. Nevertheless, such works were either informal
[6, 50, 37], or they did not produce a correctness proof for a blockchain or consensus protocol, focusing
instead on other applications [16, 2, 17, 8, 35]. We proceed to give a partial list of such considerations.

In [35], Garay et al. study the necessary hardness condition that the underlying computational
problem should satisfy in order for Bitcoin to implement a public ledger. In contrast to our work,
an enhanced version of that security notion is shown to be sufficient to implement a public ledger
against an adversary controlling only 1/3 (as opposed to 1/2) of the computational power. Further,
it is unclear whether such notion can be used to solve the original consensus problem.

Another effort to formalize an intermediate PoW-like building block for the Bitcoin protocol was
made in [47]. The proposed ideal functionality, Fptree, keeps track of a tree of messages, which both
the honest parties and the adversary can extend with probability p. The outcome of each such trial is
independent of the others, even if it is made by the adversary. Fptree satisfies the strong independence
property mentioned before, and hence it is not suitable for the goals of this paper. Moreover, we
note that any protocol instantiating this functionality must necessarily be interactive, as two parties
can use Fptree to communicate at least one bit. Finally, in [47], it was shown how to implement a
transaction ledger, but not how to achieve consensus; the techniques introduced in this paper can be
adapted to implement a consensus protocol using Ftree.

Another relevant work, is that of Back et al. [6] and of Poelstra [50], where the concept of “dynamic
membership multi-party signatures” (DMMS) is proposed to describe the underlying primitive used in
Bitcoin. The author of the latter work also argues the security of Bitcoin, based on a DMMS scheme.
While the properties described there bear some similarities to our work, the treatment is not formal.

Another related work, is that of Dwork and Naor [25], which considered PoWs under the term
“pricing functions,” as a means of protection against spam e-mail. The main properties discussed in
their work are amortization resistance, “moderate hardness” and the existence of trapdoors (“short-
cuts” in their terms). Interestingly, among the three constructions described there, one of them is a
partially “broken” signature scheme, i.e., while it is hard for an attacker to obtain the signing key, it
is moderately hard to forge signatures.

In a different direction, Juels and Jacobsson [37] and Back [4, 5] use PoWs to construct electronic
payment systems. In [37], the authors consider the following properties: Amortization resistance,
fast verification, and some special “useful work” property which states that generating a PoW for
some scheme may help in generating a PoW for another scheme. As acknowledged by the authors
themselves, the definitions they provide are only sketches. In [4, 5] another set of closely related
properties is considered, including amortization and “trapdoor-freeness.” Amortization refers to the
ability to combine PoWs of lesser difficulty in order to construct PoWs of greater difficulty. “Trapdoor-
freeness” dictates that the party which generates the initial parameters of the scheme should not be
able to also generate a trapdoor regarding these parameters. Again the approach is not rigorous.

Bitansky et al. [16] construct time-lock puzzles as well as PoW schemes from randomized encod-

7



ings. Since the focus of their work is time-lock puzzles, the properties of PoW schemes—amortization
resistance, moderate hardness and fast verification—are only briefly investigated, although they do in-
stantiate a PoW scheme based on randomized encodings and the existence of non-amortizing languages
in the worst case.

Another interesting approach is that of Ball et al. [8], who construct a PoW from worst case
assumptions. They base the security of their PoW system on the worst case hardness of classical com-
plexity theory problems, e.g., the Orthogonal Vectors problem. As many of the previously mentioned
works, they also adopt a proof-system view in their security definitions.

In [2], Alwen and Tackmann study moderately hard functions (MoHF), providing simulation based
definitions for what they call “non-interactive proofs of effort” (niPoE), which—as explicitly acknowl-
edged by the authors—cannot be used to analyze Bitcoin. The main impediment is that the adversary
can only invoke the same MoHF only once per protocol session, while for the Bitcoin protocol multiple
invocations of the same MoHF should be allowed.

Another related moderately hard (albeit in a sequential manner) primitive is the recently intro-
duced notion of Verifiable Delay Functions (VDF) [17]. However, while the authors explicitly mention
the encoding of messages using the primitive, the provided security definitions do not capture CMA
security, a property which is necessary in a concurrent multi-party setting.

Summary of differences with a previous version [34]. The most important difference of this
version of the paper from [34] is the introduction of the notion of SoW, replacing the Proof of Work
(PoW) notion. Moreover, many proofs have been rewritten in a clearer fashion, and the properties
required from the underlying computational primitive have been simplified. Finally, additional related
work regarding consensus protocols has been added.

Organization of the paper. The basic computational model, definitions and cryptographic building
blocks used by our constructions are presented in Section 2. Formal definition of the SoW primitive
and its security properties are presented in Section 3. Section 4 is dedicated to applications of SoW:
First, we introduce an appropriate model for our applications (Section 4.1). We then analyze the
Bitcoin backbone protocol based on (and reducing its security to) SoW (Section 4.2), followed by the
new blockchain-based consensus protocol (Section 4.3). Further, and as a “sanity check,” in Section 5
we show how to implement SoW in the RO model, or using Ftree.

2 Preliminaries

In this section we introduce basic notation and definitions that are used in the rest of the paper. For
k ∈ N+, [k] denotes the set {1, . . . , k}. For strings x, z, x||z is the concatenation of x and z, and
|x| denotes the length of x. We denote sequences by (ai)i∈I , where I is the index set. For a set X,
x← X denotes sampling a uniform element from X. For a distribution U over a set X, x← U denotes
sampling an element of X according to U . By UÎť we denote the uniform distribution over {0, 1}Îť.
We denote the statistical distance between two random variables X,Z with range U by ∆[X,Y ], i.e.,
∆[X,Z] = 1

2

∑
v∈U |Pr[X = v]−Pr[Z = v]|. For ε > 0, we say that X,Y are ε-close when ∆(X,Y ) ≤ ε.

We let λ denote the security parameter. In this paper we will follow a more concrete (“exact”)
approach [12, 9, 36, 15] to security evaluation rather than an asymptotic one. We will use functions t, Îľ,
whose ranges are N,R, respectively, and have possibly many different arguments, to denote concrete
bounds on the running time (number of steps) and probability of adversarial success of an algorithm
in some fixed computational model, respectively. When we speak about running time this will include
the execution time plus the length of the code (cf. [15]; note also that we will be considering uniform
machines). We will always assume that t is a polynomial in the security parameter Îť, although we
will sometimes omit this dependency for brevity.

8



Instead of using interactive Turing machines (ITMs) as the underlying model of distributed com-
putation, we will use (interactive) RAMs. The reason is that we need a model where subroutine
access and simulation do not incur a significant overhead. ITMs are not suitable for this purpose,
since one needs to account for the additional steps to go back-and-forth all the way to the place where
the subroutine is stored. A similar choice was made by Garay et al. [36]; refer to [36] for details
on using interactive RAMs in a UC-like framework, as well as to Section 4.1. Given a RAM M ,
we will denote by StepsM (1Îť, x) the random variable that corresponds to the number of steps of M
given as input the security parameter 1Îť and x. We will say that M is t-bounded if it holds that
Pr[StepsM (1λ, x) ≤ t(λ)] = 1.

Finally, we remark that in our analyses there will be asymptotic terms of the form negl(Îť) and
concrete terms; throughout the paper, we will assume that Îť is large enough to render the asymptotic
terms insignificant compared to the concrete terms.

Cryptographic hash functions. We will make use of the following notion of security for crypto-
graphic hash functions:

Definition 1. Let H = {{Hk : M(λ)→ Y (λ)}k∈K(λ)}λ∈N be a hash-function family, and A be a PPT
adversary. Then H is collision resistant if and only if for any Ν ∈ N and corresponding {Hk}k∈K in
H,

Pr[k ← K; (m,m′)← A(1λ, k); (m 6= m′) ∧ (Hk(m) = Hk(m
′))] ≤ negl(λ).

Robust public transaction ledgers. The notion of a public transaction ledger was introduced
in [31] to describe the functionality implemented by the Bitcoin protocol. It is defined with respect to
a set of valid ledgers L and a set of valid transactions T , each one possessing an efficient membership
test. A ledger x ∈ L is a vector of sequences of transactions tx ∈ T . Ledgers correspond to chains in
the Bitcoin protocol. It is possible for the adversary to create two transactions that are conflicting;
valid ledgers must not contain conflicting transaction. Moreover, it is assumed that in the protocol
execution there also exists an oracle Txgen that generates valid transactions, and is unambiguous, i.e.,
the adversary cannot create transactions that come in ‘conflict’ with the transactions generated by the
oracle. A transaction is called neutral if there does not exist any transactions that comes in conflict
with it.

Definition 2. A protocol Π implements a robust public transaction ledger if it organizes the ledger as
a chain of blocks of transactions and satisfies the following two properties:

Persistence: Parameterized by k ∈ N (the “depth” parameter), if in a certain round an honest
player reports a ledger that contains a transaction tx in a block more than k blocks away from the
end of the ledger, then tx will always be reported in the same position in the ledger by any honest
player from this round on.

Liveness: Parameterized by u, k ∈ N (the “wait time” and “depth” parameters, resp.), provided
that a transaction either (i) issued by Txgen, or (ii) is neutral, is given as input to all honest
players continuously for u consecutive rounds, then all honest parties will report this transaction
at a block more than k blocks from the end of the ledger.

The consensus problem. Next, we give the definition of the well-known consensus problem (a.k.a.
Byzantine agreement) [48, 42]. There are n parties, t < n of which might be corrupted, taking an
initial input x ∈ V (without loss of generality, we can assume V = {0, 1}).

Definition 3. A protocol Π solves the consensus problem provided it satisfies the following properties:
";"""date"",""2020-04-13T14:10:25Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2020-04-13T14:10:25Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017/Debian) kpathsea version 6.2.3""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2020-04-13T14:10:25Z""
""created"",""2020-04-13T14:10:25Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-04-13T14:10:25Z""
""resourceName"",""garay2017consensus.pdf""
""Author"",""""
""producer"",""pdfTeX-1.40.18""
""pdf:docinfo:producer"",""pdfTeX-1.40.18""
""pdf:unmappedUnicodeCharsPerPage"",""2"",""0"",""0"",""0"",""2"",""2"",""0"",""5"",""4"",""2"",""13"",""11"",""7"",""0"",""10"",""16"",""10"",""8"",""9"",""27"",""18"",""19"",""13"",""17"",""15"",""3"",""8"",""6"",""16"",""0"",""4"",""3"",""65"",""20"",""6"",""10"",""0"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2020-04-13T14:10:25Z""
""Last-Modified"",""2020-04-13T14:10:25Z""
""dcterms:modified"",""2020-04-13T14:10:25Z""
""title"",""""
""Last-Save-Date"",""2020-04-13T14:10:25Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2020-04-13T14:10:25Z""
""meta:save-date"",""2020-04-13T14:10:25Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017/Debian) kpathsea version 6.2.3""
""Content-Length"",""630837""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""39""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""1713"",""493"",""3856"",""3818"",""3655"",""3112"",""3927"",""3396"",""3092"",""2788"",""3506"",""2372"",""2575"",""3863"",""3159"",""1803"",""1566"",""2664"",""3283"",""2368"",""3150"",""2571"",""2123"",""1598"",""1422"",""2529"",""2640"",""3060"",""2532"",""3186"",""3080"",""1288"",""3548"",""2190"",""2063"",""3067"",""3299"",""3306"",""1187""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-04-13T14:10:25Z""
";https://scholar.google.ch/scholar?start=850&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098787-156;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;IoT in medical & pharmaceutical: Designing lightweight RFID security protocols for ensuring supply chain integrity;M Safkhani, S Rostampour, Y Bendavid, N Bagheri ; Computer Networks, 2020  Elsevier;;"JavaScript is disabled on your browser. Please enable JavaScript to use all

the features on this page. Skip to main content Skip to article …";Cité 4 fois;Les 3 versions;[HTML] nih.gov;https://www.ncbi.nlm.nih.gov/pmc/articles/PMC7497782/;;;https://scholar.google.ch/scholar?start=700&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098809-201;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;??? ???? ????? ??? ??? ?? ???-??? ??? ??? ??, ????? ???? ??? ??;??? ; ??, 2020  papersearch.net;;"… There are some ways to mitigate this rigidity through implementing 'kill switch' codes from the

outset, or by using oracles to import … Merely producing virtual representations of off-chain assets

('tokenization') would not be sufficient to bridge the gap between the blockchain and the …";;;null;;;;https://scholar.google.ch/scholar?start=750&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098818-227;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Exploring Interoperability of Blockchain Technology and the Possibility of Collaboration with the Existing Information Systems of the Enterprises;I Dimitrov, R Gigov ; 2020 III International Conference on High …, 2020  ieeexplore.ieee.org;;"… Keywords ? Blockchain technologies, interoperability, infor- mation systems, distributed ledger

technologies … It is for this reason that crypto projects offering in- teroperability with various industry …

to use solutions such as BlocNchain as a service (BaaS) and Oracle BlocN- chain …";;null;null;;;;https://scholar.google.ch/scholar?start=770&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098800-190;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;[PDF][PDF] TARDIS: A Foundation of Time-Lock Puzzles in UC;C Baum, B David, R Dowsley, JB Nielsen12… ;2020 eprint.iacr.org;;"… puzzles and other time- based primitives, since those are finding widespread use in complex

scenarios like the widely distributed and concurrent blockchain setting, where … But needs a random

oracle. The paper [29] shows that even without random oracles not everything is lost …";Cité 3 fois;;[PDF] iacr.org;https://eprint.iacr.org/2020/537.pdf;"
TARDIS: A Foundation of Time-Lock Puzzles in
UC

Carsten Baum1 ?, Bernardo David3 ??, Rafael Dowsley4 ? ? ?,
Jesper Buus Nielsen12, and Sabine Oechsner1 †

1 Aarhus University, Denmark
2 Concordium Blockchain Research Center, Aarhus University, Denmark

3 IT University of Copenhagen, Denmark
4 Monash University, Australia

Abstract. Time-based primitives like time-lock puzzles (TLP) are find-
ing widespread use in practical protocols, partially due to the surge of
interest in the blockchain space where TLPs and related primitives are
perceived to solve many problems. Unfortunately, the security claims
are often shaky or plainly wrong since these primitives are used under
composition. One reason is that TLPs are inherently not UC secure and
time is tricky to model and use in the UC model. On the other hand, just
specifying standalone notions of the intended task, left alone correctly
using standalone notions like non-malleable TLPs only, might be hard
or impossible for the given task. And even when possible a standalone
secure primitive is harder to apply securely in practice afterwards as its
behavior under composition is unclear. The ideal solution would be a
model of TLPs in the UC framework to allow simple modular proofs. In
this paper we provide a foundation for proving composable security of
practical protocols using time-lock puzzles and related timed primitives
in the UC model. We construct UC-secure TLPs based on random ora-
cles and show that using random oracles is necessary. In order to prove
security, we provide a simple and abstract way to reason about time in
UC protocols. Finally, we demonstrate the usefulness of this foundation
by constructing applications that are interesting in their own right, such
as UC-secure two-party computation with output-independent abort.

? This work was funded by the European Research Council (ERC) under the European
Unions’ Horizon 2020 research and innovation programme under grant agreement No
669255 (MPCPRO).

?? This work was supported by the Concordium Foundation, by Protocol Labs grant
S2LEDGE and by the Independent Research Fund Denmark with grants number
9040-00399B (TrA2C) and number 9131-00075B (PUMA).

? ? ? This work was partially done while Rafael Dowsley was with Bar-Ilan University
and was supported by the BIU Center for Research in Applied Cryptography and
Cyber Security in conjunction with the Israel National Cyber Bureau in the Prime
Minister’s Office.
† Supported by the Danish Independent Research Council under Grant-ID DFF-8021-

00366B (BETHE).



1 Introduction
The Universal Composability (UC) framework [17] is widely used for formally
analyzing cryptographic protocols as it provides strong security guarantees that
allow UC-secure protocols to be arbitrarily composed. This is a very useful prop-
erty and enables the modular design of cryptographic protocols. However, the
original UC framework is inherently asynchronous and does not support the no-
tion of time. Katz et al. [36] introduced a clock functionality in order to define
universally composable synchronous computation. Their clock functionality cap-
tures the essence of synchronized wall clocks that are available to all parties. This
notion is particularly useful in reasoning about synchronous protocols in the UC
framework, since the honest parties can use the clock to achieve synchronization.

However, many cryptographic protocols do not depend on concrete time pro-
vided by a wall clock, but just on the relative order of events, such as the arrival
of messages or the completion of some computation. In particular, protocols
in a semi-synchronous communication model (e.g. [25,5]) rely on the fact that
there exists a finite (but unknown) upper bound for the delay in communication
channels, without requiring that events (e.g. the arrival of a message) occur at
a specific wall clock time (or even within a concrete delay) as long as they occur
in a certain order. In this case, using a clock can make the design and security
analysis of such protocols unnecessarily complicated.

Another important challenge lies in modeling sequential computation and
computational delays in the UC framework. Since the environment may operate
in many parallel sessions and activate parties arbitrarily, it obtains an unfair
computational advantage in relation to the parties. For example, even if its
computational power is constrained within a session, the environment can use
multiple sessions to solve faster than a regular party a computational problem
assumed to require at least a certain amount of computational steps (and thus
time). This precludes the UC modeling and construction of primitives based on
sequential computation and computational delays, such as time-lock puzzles [45].

1.1 Our Contributions

In this work, we introduce a new abstract notion of time in the UC framework
that allows us to reason about communication channels with delays as well as
delays induced by sequential computation. We demonstrate the power of our
approach by introducing the first definition and construction of composable time-
lock puzzles (TLPs) without resorting to clocks, which we use to obtain the
first two-party computation protocol with output-independent abort. Finally,
we establish that a programmable random oracle is necessary for obtaining UC-
secure TLPs. Our contributions are summarized below:

– Abstract Time in UC: we put forth a novel abstract notion of time for
the UC framework capturing relative event ordering without a clock.

– Impossibility of UC-Secure TLPs without Programmable Random
Oracles: we prove that programmable random oracles are necessary for con-
structing UC-secure TLPs, yielding a new separation between programmable
and non-programmable random oracles.

2



– First Composable Treatment of Time-Lock Puzzles (TLPs): we in-
troduce the first composable definition and construction of time-lock puzzles.
Our construction uses a RO, as it must. However, it has a flavor of “graceful
degradation”: if the hash function is not modeled as a random oracle, our
TLPs are still non-malleable, which is in some sense optimal without a RO.

– First Two-Party Computation Protocol with Output Independent
Abort: we use TLPs to construct a UC-secure two-party computation pro-
tocol where the adversary cannot see the output before deciding to abort.

The incompatibility of time-lock puzzles and UC security is easy to explain.
All that is needed is to recall that UC has straight-line simulation. Let P =
TLP(x, T, t) be a timed commitment to x which can be opened in time T and
is hiding for time t < T . Consider simultaneous message exchange. In the UC
functionality Alice inputs a, Bob inputs b and only then are both given (a, b).
Here is a toy protocol which does not work for many reasons. Alice and Bob
each publish PA = TLP(a, T, t) and PB = TLP(b, T, t) and then open the puzzles
or brute force them. Assume that Alice is supposed to send her puzzle first,
and Bob is corrupted. In the security proof, the UC simulator needs to extract
Bob’s input b in order to query the ideal functionality and learn a. However, the
simulator needs to learn PB for that. PB though is only sent by Bob after seeing
PA. As a result, the simulator has to produce PA without knowing a. Rewinding
is not allowed, so the simulator cannot go back and replace the puzzle PA.
The simulator had to put some a′ inside PA and is now committed to it. If a
is random then with noticeable probability a′ 6= a. In UC these problems are
typically handled by having trapdoors which allow to do equivocation. Had PA
been a UC commitment we could have changed a′ to a before opening. But PA is
a TLP, so there is no way to cheat. The UC environment can simply take PA and
brute-force it open. So the a′ is irrevocably committed to by PA. A shorter way
to explain the problem is as follows. In a UC simulation the simulator must for
all puzzles it sends agree on what is inside at the point in time where they were
sent. And the UC experiment will keep running as long as the environment wants,
so it can allow itself time enough to open all puzzles eventually. Hence puzzles
will not afford us the power of a UC commitment which can be equivocated.
Unfortunately, equivocation is exactly the power needed for simulating time-
lock puzzles in the UC framework for most interesting applications.

Although the above argument only shows that one particular protocol does
not work, we show that the problem cannot be circumvented by any protocol
even allowing setup like a CRS. Assuming a random oracle, however, one can
cheat and use the random oracle to get equivocation. Note the if we model H as
a random oracle and send TLP(r), H(r)⊕m in a simulation, we can reprogram
H at r as long as TLP(r) is hiding r such that H was not queried at r. This is
of course an unsatisfactory solution, but some comfort can be gained from the
fact that we provably cannot do without such a cheat if we want UC security.

There is a clear need for a UC model of time-lock puzzles and other time-
based primitives, since those are finding widespread use in complex scenarios like
the widely distributed and concurrent blockchain setting, where there is no way

3



around having composable security for the protocol building blocks. Many of the
proposed uses are often relatively simple a la the above simultaneous message
exchange example. However, the security statements are often provably wrong,
as TLPs for instance cannot yield composable simultaneous message exchange.
Reverting to non-composable game-based definitions of the intended tasks and
using non-malleable TLPs for the standard model is in principle a solution, but
the proofs are typically complicated and the protocols inefficient. We therefore
introduce a foundation for practical TLP-based protocols using a UC model of
TLPs that allows simple analysis of practical protocols. This model is motivated
in the same vein as the random oracle model, which was also proposed as a basis
for analysing efficient, practical protocols.

Clearly, when using TLPs we also need a notion of time. If a TLP that can
be broken in an hour is received through a network, it should not be trusted to
be hiding an hour later. That requires a notion of time (e.g. a clock). Often the
reliance on time in practical protocols using TLPs if fairly light. In line with the
motivation above, we therefore provide also a simple abstract notion of time.

The advantage of our new abstract notion of time for the UC framework
is twofold: 1. it captures delays without explicitly referring to wall clock time
and 2. it allows for modeling delays induced by sequential computation. This
notion makes it possible to state protocols and security proofs in terms of the
relative delays between events (e.g. the arrival of a message or completion of a
computation) and the existence of large enough delays that ensure that these
events occur in a certain order.

Building on this model, we introduce the first definition and construction of
UC-secure time-lock puzzles. Our construction is based on the classical time-lock
assumption of Rivest et al. [45] and uses a restricted programmable and observ-
able global random oracle, which we prove to be necessary. As an application of
our composable TLPs, we introduce the notion of two-party computation (2PC)
with output independent abort (OIA) along with the first OIA-2PC protocol.
This new security notion for secure computation guarantees that an adversary
who aborts the execution cannot learn any information about the output before
deciding to abort, only obtaining the output after this decision is made. Our
new definition improves on the standard security notion with abort (realized by
all known 2PC protocols), which allows for the adversary to decide whether to
force the honest parties to abort without obtaining the output after learning the
output itself. We argue that this new security notion is optimal, since fairness
(i.e. ensuring all parties obtain the output if the adversary does so) for 2PC
protocols is impossible [22].

1.2 Related Work.

Composition frameworks with time and fairness. Composition frameworks for
cryptographic protocols (e.g. UC [17], constructive cryptography [40], the reac-
tive simulatability (RSIM) framework [43]) provide strong security guarantees
for protocols under concurrent composition. In all mentioned frameworks, com-
munication is through inherently asynchronous channels. Several works have

4



therefore studied general composition guarantees with synchronous communica-
tion by introducing a shared source of time or restricting adversarial scheduling.
Modeling network timing assumptions such as bounded message delay and clock
drift and the resulting concurrent composition guarantees for specific tasks was
studied for zero-knowledge [26], [30] and MPC [34]. In the context of composition
frameworks, Backes et al. [4] model traffic-related timing attacks in GNUC [32]
by allowing the adversary to measure the local time at which a message arrives.
In this setting, each party has a local execution time, and the EXEC function of
GNUC maps the local times into a global time. Backes et al. [3] studied fairness
in the RSIM framework and achieve a composable notion of fairness by restrict-
ing the adversary model to fair schedulers who deliver any message after at most
a polynomial number of steps.

The work that is most closely related to ours is that of Kiayias et al. [37],
which points out limitations of the local clock functionality of Katz et al. [36]
and adapts it to the Global UC (GUC) framework [18] to provide all parties with
access to a global clock functionality for the purpose of synchronization. Their
model requires all parties executing a (semi-)synchronous protocol to keep track
of current global clock time and to actively query the global clock functionality in
order to advance of time. In particular, even if their model is used to define semi-
synchronous communication, it implies that all parties are kept synchronized and
may learn how much time has elapsed since their last activation (i.e. by obtaining
the current time from the global clock), which is a rather strong synchrony
assumption. However, many protocols cast in this model do not crucially rely on
obtaining concrete time stamps or determining concrete delays between party
activations, as long as messages are guaranteed to be delivered within certain
delays and in a certain order (e.g. as in [5]). This is exactly the kind of guarantees
that our model captures without explicitly exposing time keeping to parties
or requiring them to keep track of concrete time sources. By doing that, our
model allows us to analyse many protocols cast in their model while significantly
relaxing synchrony assumptions. Moreover, our model can be used to capture
delays induced by sequential computation, which is not captured by the global
clock model of Kiayias et al..

Another work technically related to ours is the notion of resource-fairness
for protocols in UC introduced by Garay et al. [29]. Resource fairness ensures
that honest parties who invest a certain amount of resources (e.g. computational
time) can always recover from an abort and obtain the protocol output in case
the adversary causes an abort in such a way that it learns the output. In order to
realize this notion, Garay et al. show a generic compiler based on a “time-line”
construction and a secure computation functionality. Essentially, this time-line
encodes a number of computational states into a programmable common refer-
ence, which parties use in order to commit to messages that can be recovered by
another party who invests enough computational steps. This idea differs from
our work in that it limits TLP delay a priori, since the maximum number of
computational states used to ensure delay is fixed by the CRS. This crucial dif-
ference also forces the resource-fairness framework to modify the UC framework

5



in such a way that environments, adversaries and simulators must have an a pri-
ori bounded running time. On the other hand, our modelling of computational
time and TLPs does not make modifications or restrictions to the UC environ-
ment, as well as allowing us to define TLPs in a more natural way where there’s
no a priori bound to the TLP delay. In particular, this means that TLPs can be
parameterized with any arbitrary delay and that honest parties are always able
to solve a TLP, which also allows us to realize our notion of output independent
abort in such a way that honest parties can always either retrieve the output
of the computation or determine that the adversary has aborted (by solving the
adversary’s TLPs).

Another relation to [29] is that both papers circumvent the problem that
TLPs are not UC simulatable. We do it using the simple hack of using a random
oracle, to get a simple model to work with. In [29] it is done by letting the
simulator depend on the running time of the environment.

As an example of how to exploit this consider a party that wants to commit to
s. It secret shares it into (s1, . . . , sk) and makes public P1 = TLP(s1), . . . , Pk =
TLP(sk). The hardness of Pi is set to 2i and k is the security parameter. So
Pk cannot be brute-forced open. For each si it also gives a UC commitment
to si and a ZK proof that the commitment is to the value in the TLP. To
do fair message exchange both Alice and Bob do the above with s = a and
s = b. Then the parties open the commitments (not the TLPs) to the shares in
the order sk, sk−1, . . ., taking turns to reveal a share. If a party stops opening
commitments, then use the TLPs to learn the remaining shares, if the hardness
of the remaining TLPs is feasible. Now in the simulation, if the running time of
the environment is upper bounded to some polynomial t, then there exists i0 < k
such that 2i0 > t. Now the simulator can put dummy shares s′i in Pj for j ≥ i.
When it learns the message a of Alice it can then adjust the UC commitments to
be a secret sharing of a. It does not have to adjust the TLPs as the environment
will not have time to open them. The fact that there is an ”end of time” in the
simulation allows to simulate some TLPs. On the other hand, the fact that there
is an “end of time” in the simulation makes composition cumbersome. Indeed [29]
gets a complicated notion of security where a protocol to be called secure must
be secure in two ways. It must be secure in a so-called resource game, and it
must also be so-called full simulation secure. This requires [29] to develop a new
variant of the UC framework. This variant does not imply security in the normal
UC model which does not have an “end of time”.

It also seems hard to prove security of most practical protocols in [29]. The
reason is that it seems hard to exploit the simulator’s knowledge of the running
time of the environment (which can be any polynomial) without using TLPs
of super-polynomial running time, as in the above examples with TLPs of dou-
bling hardness. This seems to make it hard to prove security of many simple and
intuitively secure scheme like the first protocol above with two TLPs for simul-
taneous message exchange. Either these two TLPs have a hardness set such that
real-world parties can brute-force them (and then so can the environment) or it
is set so hard that the environment cannot brute-force them, then neither can

6



the parties. In the first case the protocols falls prey to our impossibility result.
In the later case the TLPs seems useless.

We find the techniques and models in our paper and [29] complementary. Our
model is built on the normal (G)UC model without modifying it and is simple
to specify and use. But needs a random oracle. The paper [29] shows that even
without random oracles not everything is lost. It is possible to get models and
some constructions with UC like security.

Time-Lock Puzzles and Computational Delay The original construction of time-
lock puzzles was proposed by Rivest, Shamir and Wagner [45]. Boneh and Naor
[14] introduced the notion of timed commitments. An alternative construction
of time-lock puzzles was presented by Bitansky et al. [12]. Recently, the related
notion of verifiable delay functions has been investigated [13,44,49]. These con-
structions are closely related in that they rely on sequential computational tasks
that force parties to spend a certain amount of time before they are able to
obtain an output. However, none of these works have considered composability
issues for such time-based primitives. In particular, the issues of malleability
for these time-based primitives and the relationship between computational and
communication delay are notably ignored in previous works. The lack of compos-
abillity guarantees for time-lock puzzles is a significant shortcoming, since these
primitives are mostly used as building blocks for more complex protocols and
current constructions do not ensure that their security guarantees are retained
when composed with other primitives to obtain such protocols. Our composable
treatment of time-lock puzzles addresses theses issues by introducing construc-
tions that can be arbitrarily composed along with a framework for analysing
complex protocols whose security relies on the relative delays in computation
and communication.

Concurrently to us, Katz et al. [35] as well as Ephraim et al. [27] have con-
structed Non-Malleable Timed Commitments. Among others, [24] have shown
that UC (non-timed) Commitments imply Non-Malleable Commitments. A sim-
ilar argument can be made for timed commitments as well. In that sense, our
construction of UC-secure TLPs implies [35,27]. At the same time, our work
crucially relies on a programmable Random Oracle (and indeed shows that it
is necessary to achieve UC security). Neither [35] nor [27] require such strong
assumptions and can be seen as realising the strongest notion of non-malleability
achievable without using a (programable) random oracle or similar assumption:
the beautiful construction of [35] does not require any Random Oracle-type as-
sumption and builds upon RSW-TLPs in the Algebraic Group Model, while [27]
use an observable Random Oracle but their construction can be realized from
a generic TLP. At the same time, [27] also constructs publicly verifiable TLPs
departing from generic strong trapdoor VDFs. We’d like to stress that our con-
struction of a UC-secure TLP is publicly verifiable, although this is only shown
in recent follow-up work [7]. We further note that the work of [27] shows a bound
on the composability of non-malleable TLPs, but their bound does not apply to
our setting as they assume a distinguisher with an arbitrary runtime, while the
UC environment is computationally restricted in our setting.

7



Aborts and Fairness in Secure Computation An MPC protocol is said to be fair
if a party can obtain the output if and only if all other parties also obtain the
output. It is a well-known fact that fair MPC in the standard communication
model is impossible with a dishonest majority [22]. Given the impossibility to
achieve fairness, techniques for identifying misbehaving parties responsible for
causing an abort have been investigated [33,8,9]. In the last few years a line
of work developed which imposes financial penalties on parties who are identi-
fied as misbehaving by using cryptocurrencies and smart contracts, thus giving
financial incentives for rational parties to behave in a fair way. Protocols have
been designed to punish misbehavior at any point of the protocol execution (Fair
Computation with Penalties) [2,39,37] or to only punish participants that learn
the output but prevent others from doing the same (Fair Output Delivery with
Penalties) [1,11,38,6]. However, these protocols allow the adversary to make a
decision on whether to abort or not after seeing the output that will be obtained
by the honest parties in case the execution proceeds.

The recent work of Couteau et al. [23] studies the problem of obtaining
partially-fair exchange from time-lock puzzles, but in much weaker security and
adversarial models. In particular, their work does not consider composability
issues and is limited to the specific problem of fair exchange rather than the
general problem of secure computation considered in our results.

Random oracle separation results. Our impossibility result provides yet another
separation between the programmable and non-programmable random oracle
models, complementing the few previously known separations [41,48,28,10].

1.3 Our Techniques

In the remainder of this section, we briefly outline the new techniques behind
our results and their implications.

Abstract Time: Our goal is to express different timing assumptions (possibly
related) within the GUC framework in such a way that protocols are oblivious
to them. We do so by providing the adversary with a way of advancing time
in the form of ticks. A tick represents a discrete unit of time. Time can only
be advanced, and moreover only one unit at a time. In contrast to Katz et al.
[36,37], however, these ticks and thus the passing of time are not supposed to
be directly visible to the protocol. Thus instead of a (global) clock that parties
can ask for the current time, we add a ticking interface to ideal functionali-
ties. This way, timing-related observable behavior becomes an assumption of the
underlying functionalities, e.g. of a computational problem or a channel. Par-
ties may now observe events triggered by elapsed time, but not the time itself.
Ticked functionalities are free to interpret ticks in any way they like; this way we
can synchronize and relate ticks representing elapsed time in different “units”
like passed time or computation steps. The technical challenge is to ensure in a
composable way that all honest parties have a chance at observing all relevant
timing-related events. Katz et al. solved this issue inside the clock by keeping

8



track of which parties have been activated in the current time period (and thus
asked for the time) and refusing to advance time if necessary. We enforce the
requirement that all honest parties must be activated between ticks by defining a
global ticker functionality that makes sure this constraint is obeyed. In contrast
to the global clock, our global ticker does not provide any information about the
time elapsed between queries by functionalities, only informing functionalities
that a new tick has ocurred. From the point of view of honest parties, our global
ticker is even more restricted, since it does not inform parties whether a tick
has occurred or not. To further control the observable side effects of ticks, we
restrict protocols and ideal functionalities to interact in the “pull model” known
from Constructive Cryptography, precluding functionalities from implicitly pro-
viding communication channels between parties and instead requiring parties
to actively query functionalities in order to obtain new messages. Apart from
presenting a clear abstraction of time, this notion explicitly exposes issues that
must be taken in consideration when implementing protocols that realize our
functionalities, i.e. the concrete delays in real world communication channels
and computation. In particular, while the theoretical protocol description and
security analysis can be carried in terms of such abstract delays, our techniques
clarify the relationship between concrete time-based parameters (e.g. timeouts
vs. network delays) that must be respected in protocol implementations. We will
go into this in more detail in Section 2.

Composable Treatment of Time-Lock Puzzles: To illustrate the potential uses
of our framework, we present the first definition and construction of UC-secure
Time-Lock Puzzles (TLP). We depart from the classical construction by Rivest
et al. [45] and provide the first UC abstraction of the Time-Lock Assumption,
which is modeled in a “generic group model” style, hiding the group description
from the environment and limiting its access to group operations. A party acting
as the “owner” of an instance of the TLP functionality can generate a puzzle
containing a certain message that should be revealed after a certain number of
computational steps. The functionality allows the parties to make progress on
the solution of the puzzle every time that it is ticked. Once a party solves a
puzzle, it can check that a certain message was contained in that puzzle. The
ticks given to this functionality come externally from the adversary and we
require in the framework that the parties get activated often enough. We show
that our UC abstraction of the Time-Lock Assumption allows us to implement
UC-secure TLPs in the restricted programmable and observable global random
oracle model of Camenisch et al. [15] (which turns out to be necessary for UC-
realizing TLPs). We introduce our notion of TLP in the UC model with a global
ticker in Section 4 and our construction of a protocol realizing this notion in
Section 5.

Two-Party Computation with Output Independent Abort: To further showcase
our framework we construct the first protocol for secure two-party computation
(2PC) with output-independent abort, i.e., the adversary must decide whether
to abort or not before seeing the output. In order to do so, we build on techniques

9



from [6]: there, the authors combine an MPC protocol with linearly secret-shared
outputs and an additively homomorphic commitment by having each party com-
mit to its share of the output and then reconstruct the output inside the commit-
ments. In [6], the output of the secure computation is obtained by opening the
final commitments resulting from the reconstruction procedure, which allows the
adversary to learn the output before the honest parties do. He can then refuse
to open its commitment, causing the protocol to abort, based on this informa-
tion. Similarly to [6], we combine a 2PC protocol with secret-shared outputs and
an additively homomorphic commitment, but we define and construct commit-
ments with a new delayed opening interface. When a delayed opening happens,
the receiver is notified after a communication delay but only receives the re-
vealed message after an opening delay. Hence, we can obtain output independent
abort by delayed opening the final commitments obtained after reconstructing
the output and considering that a party aborts if it does not execute a delayed
opening of their commitments before the other parties delayed openings reveal
their messages. Finally, we show how to obtain UC-secure additively homomor-
phic commitments with delayed opening by modifying the scheme of Cascudo
et al. [20] with the help of the delayed secure message transmission and TLP
functionalities. We present these results in Section 6.

Impossibility Result. Finally, we prove that a non-programmable random oracle
is not sufficient for obtaining UC-secure fair-coin flip, secure 2PC with output-
independent abort or TLP. Therefore a programmable random oracle is necessary
to implement these primitives, yielding a separation between the programmable
and non-programmable random oracle models. This also shows that our TLP
construction which requires this strong assumption is in that sense “optimal”.
We present this impossibility result in Section 7.

2 UC with Relative Time

This section describes our notion of abstract time. In order to obtain universal
composability, we model our ideas on top of the GUC framework [18]. The
framework is further discussed in Appendix A. The goal is to capture time in
such a way that parties are oblivious to it and can only observe the progression
of time indirectly through events like the arrival of messages or the completion
of a computation. At the same time, the passing of abstract time is completely
under adversarial control. And most importantly, the notion is meant to be
composable.

Timing assumptions. Our first observation is that timing assumptions are
assumptions about physical systems and should thus be captured at the level of
ideal functionalities. Such a timed functionality has a notion of passing time and
can adapt its behavior as time progresses. This will allow us to reduce properties
of a protocol that require concrete timing assumptions. Note that the time is only
a proof construct, it is not visible to the actual protocol, much like physical time.
Most importantly, having a notion of passing time should not imply synchrony
like in the UC clock models of [37,36].

10



Functionality Gticker

Initialize a set of registered parties P = ∅, a set of registered functionalitie";"""date"",""2021-03-04T21:37:43Z""
""pdf:unmappedUnicodeCharsPerPage"",""12"",""0"",""5"",""0"",""0"",""1"",""0"",""0"",""0"",""0"",""0"",""4"",""15"",""0"",""0"",""7"",""0"",""22"",""1"",""1"",""0"",""1"",""0"",""0"",""7"",""3"",""2"",""0"",""0"",""0"",""0"",""13"",""0"",""2"",""6"",""12"",""9"",""7"",""0"",""8"",""2"",""7"",""11"",""4"",""3"",""10"",""13"",""0"",""0""
""pdf:PDFVersion"",""1.5""
""xmp:CreatorTool"",""TeX""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dcterms:created"",""2021-03-04T21:37:43Z""
""language"",""en""
""Last-Modified"",""2021-03-04T21:37:43Z""
""dcterms:modified"",""2021-03-04T21:37:43Z""
""dc:format"",""application/pdf; version=1.5""
""Last-Save-Date"",""2021-03-04T21:37:43Z""
""pdf:docinfo:creator_tool"",""TeX""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2021-03-04T21:37:43Z""
""meta:save-date"",""2021-03-04T21:37:43Z""
""pdf:encrypted"",""false""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.20 (TeX Live 2019) kpathsea version 6.3.1""
""modified"",""2021-03-04T21:37:43Z""
""Content-Length"",""627618""
""pdf:hasMarkedContent"",""false""
""Content-Type"",""application/pdf""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.20 (TeX Live 2019) kpathsea version 6.3.1""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""trapped"",""False""
""meta:creation-date"",""2021-03-04T21:37:43Z""
""created"",""2021-03-04T21:37:43Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""49""
""Creation-Date"",""2021-03-04T21:37:43Z""
""resourceName"",""537.pdf""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""2149"",""2720"",""2815"",""2753"",""2919"",""2781"",""2848"",""2659"",""2841"",""2658"",""2477"",""2746"",""2203"",""2661"",""2905"",""2241"",""2754"",""2309"",""2854"",""2392"",""2587"",""1995"",""2770"",""2117"",""2273"",""2410"",""2631"",""2418"",""2787"",""2257"",""1462"",""993"",""1013"",""2354"",""2517"",""2554"",""2676"",""2105"",""2430"",""2338"",""2398"",""2440"",""2168"",""2287"",""2467"",""2429"",""2457"",""2313"",""1449""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""producer"",""pdfTeX-1.40.20""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""pdfTeX-1.40.20""
""pdf:docinfo:created"",""2021-03-04T21:37:43Z""
";https://scholar.google.ch/scholar?start=730&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098760-99;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;A Responsabilidade Civil no Transporte Multimodal de Mercadorias ea Introduçăo da Tecnologia Blockchain;DM Peixoto ;2020 estudogeral.uc.pt;;"… but that promises to change the international transport of goods as a whole. We are talking

about blockchain technology. Although its use is linked to financial technology, in particular

cryptocurrency, it has many applications in the field of freight transport …";Les 3 versions;Version HTML;[PDF] uc.pt;https://estudogeral.uc.pt/bitstream/10316/92686/1/2020.10.28%20-%20Diogo%20Mendes%20Peixoto%20-%20Disserta%C3%A7%C3%A3o%20de%20Mestrado%202020.pdf;"
 
 

 

 
 

 
 

Diogo Mendes Peixoto 
 
 
 
 

 
A RESPONSABILIDADE CIVIL NO TRANSPORTE 

MULTIMODAL DE MERCADORIAS E A INTRODUÇÃO 
DA TECNOLOGIA BLOCKCHAIN 

 
 
 
 

Dissertação no âmbito do 2.º Ciclo de Estudos em Direito (conducente ao 
grau de Mestre), na Área de Especialização em Ciências Jurídico-

Empresariais/Menção em Direito Empresarial, sob orientação do Senhor 
Professor Doutor Alexandre Miguel Cardoso de Soveral Martins e 
apresentada Ă  Faculdade de Direito da Universidade de Coimbra 

 

 
 
 

Outubro de 2020



 

 

Diogo Mendes Peixoto 

 

A RESPONSABILIDADE CIVIL NO TRANSPORTE MULTIMODAL DE 

MERCADORIAS E A INTRODUÇÃO DA TECNOLOGIA BLOCKCHAIN 

 

THE LIABILITY IN MULTIMODAL TRANSPORT OF GOODS AND THE 

INTRODUCTION OF BLOCKCHAIN TECHNOLOGY 

 

 

Dissertação apresentada à Faculdade de Direito da 

Universidade de Coimbra no âmbito do 2.º Ciclo de Estudos 

em Direito (conducente ao grau de Mestre), na Área de 

Especialização em Ciências Jurídico-Empresariais/Menção 

em Direito Empresarial, sob orientação do Senhor Professor 

Doutor Alexandre Miguel Cardoso de Soveral Martins 

 

 

Outubro de 2020 



3 
 

 

 

 

 

 

 

 

 

 

 

 

 

 

Aos meus pais 

À minha João 

Por tudo. 
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 



4 
 

 

 

 

 

Recomeça... 

Se puderes 

Sem angĂşstia 

E sem pressa. 

E os passos que deres, 

Nesse caminho duro 

Do futuro 

DĂĄ-os em liberdade. 

Enquanto nĂŁo alcances 

NĂŁo descanses. 

De nenhum fruto queiras sĂł metade. 

 

E, nunca saciado, 

Vai colhendo ilusĂľes sucessivas no pomar. 

Sempre a sonhar e vendo 

O logro da aventura. 

És homem, não te esqueças! 

SĂł ĂŠ tua a loucura 

Onde, com lucidez, te reconheças... 

 

MIGUEL TORGA, SĂ­sifo [Coimbra, 1977], DiĂĄrio: Vols. XIII 

 

 

 

 



5 
 

RESUMO  
 

O transporte multimodal de mercadorias estĂĄ intrinsecamente ligado ao comĂŠrcio 

internacional e Ă  forma como hoje se efetuam as trocas comerciais a nĂ­vel mundial. PorĂŠm, a 

sua concretização pråtica levanta vårias questþes cujas respostas não são de todo claras, dando 

aso a um extenso debate. Começando pela sua própria definição, pela natureza jurídica do 

contrato, pelas complexas relaçþes contratuais que se desenrolam e, por fim, pelo regime de 

responsabilidade aplicåvel às partes aquando da produção de algum tipo de dano. Este último 

ponto serå aquele que merecerå da nossa parte uma redobrada atenção.  

Paralelamente, o comĂŠrcio internacional e bem assim o transporte de mercadorias tem 

vindo a sofrer vårias alteraçþes fruto dos avanços tecnológicos que foram surgindo. Desde a 

contentorização às tÊcnicas de navegação, passando pelo desenvolvimento dos navios e dos 

restantes meios de transporte. Hoje, talvez estejamos a assistir a um novo movimento ou atĂŠ a 

uma revolução tecnológica que estå a dar os seus passos iniciais, mas que promete mudar o 

transporte internacional de mercadorias no seu todo. FalĂĄmos da tecnologia blockchain. 

Apesar da sua utilização estar associada à tecnologia financeira, em concreto às 

criptomoedas, são inúmeras as suas aplicaçþes no âmbito do transporte de mercadorias. A 

montante, Ê possível reduzir os riscos inerentes, acedendo em tempo real à localização exata 

dos bens, às suas condiçþes especificas e a todas as suas movimentaçþes, sendo neste âmbito 

utilizada em paralelo com a Internet of Things (IoT). Por outro lado, alĂŠm de possibilitar uma 

redução significativa do uso de documentos em papel, diminui tambÊm o tempo de 

processamento dos mesmos, tornando todo o processo mais cĂŠlere. Simultaneamente, auxilia 

as partes a conduzirem todas as transaçþes comerciais de forma mais transparente. A jusante, 

nĂŁo se conseguindo evitar o conflito jurĂ­dico, a blockchain pode servir de auxĂ­lio ao poder 

decisório, na medida em que facilita a localização do momento em que se origina o prejuízo, 

tornando, assim, mais recetĂ­vel a escolha de um sistema de rede para reger as questĂľes de 

responsabilidade civil, tal como teremos a oportunidade de defender. 

 

PALAVRAS-CHAVE: comĂŠrcio internacional; transporte multimodal de mercadorias; 

responsabilidade civil; evolução tecnológica; blockchain. 



6 
 

ABSTRACT  
 

The multimodal transport of goods is intrinsically linked to international trade and the 

way in which world trade is conducted today. However, its practical implementation raises 

several questions whose answers are not at all clear, giving rise to an extensive debate. Starting 

with its own definition, the legal nature of the contract, the complex contractual relations that 

take place and, finally, the liability regime applicable to the parties when producing some kind 

of damage. This last point will be the one to which we shall devote a great deal of attention.  

At the same time, international trade and the transport of goods have been undergoing 

various changes as a result of technological advances. From containerisation to shipping 

techniques, including the development of ships and other means of transport. Today, we may 

be witnessing a new movement or even a technological revolution that is taking its initial steps, 

but that promises to change the international transport of goods as a whole. We are talking about 

blockchain technology. 

Although its use is linked to financial technology, in particular cryptocurrency, it has 

many applications in the field of freight transport. Upstream, the inherent risks can be reduced 

by accessing in real time the exact location of the goods, their specific conditions and all their 

movements, although in this context it is used in parallel with the Internet of Things (IoT). On 

the other hand, in addition to allowing a significant reduction of the use of paper documents, it 

also reduces their processing time, making the whole process faster. At the same time, it helps 

the parties to conduct all business transactions in a more transparent manner. Downstream, if 

the legal conflict cannot be avoided, the blockchain can serve as an aid to decision making by 

turning it easier to locate the moment at which the damage originates, thus making the choice 

of a network system to govern liability issues more palatable, as we will have the opportunity 

to defend. 

 

KEYWORDS: international trade; multimodal transport of goods; liability; 

technological breakthrough; blockchain. 

 



7 
 

SIGLAS E ABREVIATURAS  
 

B/L - Bill of Landing 

BDTS - Blockchain Documentation Transaction System 

BIMCO - Baltic and International Maritime Council 

BiTA - Blockchain in Transport Alliance 

BOLERO - Bill of Landing Eletronic Registry Organisation 

BW - Burgerlijk Wetboek 

CIM - Uniform Rules concerning the Contract of International Carriage of Goods by Rail 

CIV - Uniform Rules concerning the Contract of International Carriage of Passengers by Rail 

CLECAT - European Association for Forwarding, Transport, Logistics and Customs Services  

CMI - ComitĂŠ Maritime International 

CMR - Convention on the Contract for the International Carriage of Goods by Road 

COTIF - Convention concerning International Carriage by Rail 

CSR - Corporate Social Responsibility 

ECSA - European Community Shipowners Associations 

EPRS - European Parliamentary Research Service 

ESC - European Shippers Council 

FIATA - International Federation of Freight Forwarders Associations 

GPS - Global Positioning System 

HGB - Handelsgesetzbuch 

ICC - International Chamber of Commerce 

ICS - International Chamber of Shipping 

IMO - International Maritime Organization 



8 
 

IoT - Internet of Things 

IRU - International Road Transport Union  

ISF - International Shipping Federation 

MTC - Multimodal Transport Convention  

NITL - National Industrial Transportation League  

NVOCC - Non Vessel Operator Common Carrier 

OTM - Operador de Transporte Multimodal 

SDR - Special Drawing Rights 

UNCITRAL - United Nations Commission on International Trade Law 

UNCTAD - United Nations Conference on Trade and Development 

UNECE - United Nations Economic Commission for Europe 

UNECE - United Nations Economic Commission for Europe  

UNIDROIT - International Institute for the Unification of Private Law 

WSC - World Shipping Council  

A. - Autor 

Ed. - Edição 

In - Em 

ob. cit. - Obra Citada 

ss. - Seguintes 

v.g - verbi gratia 

Vol. - Volume 

 

 



9 
 

ÍNDICE 

RESUMO ............................................................................................................................ 5 

ABSTRACT ......................................................................................................................... 5 

SIGLAS E ABREVIATURAS ................................................................................................. 7 

I - INTRODUÇÃO .............................................................................................................. 11 

II - DO TRANSPORTE MULTIMODAL DE MERCADORIAS ............................................... 13 

1. Noção geral .......................................................................................................... 13 
2. Distinção entre outras figuras ............................................................................... 16 

2.1 Transporte sucessivo ..................................................................................... 16 
2.2 Transporte segmentado ................................................................................. 17 

2.3 Transporte com reexpedição ......................................................................... 17 

2.4 Transporte roll-on/roll-off ............................................................................. 18 

3. Vantagens ............................................................................................................. 20 

4. O contrato ............................................................................................................. 22 

4.1 As partes contratantes ................................................................................... 22 

4.2 A subcontratação – uma prática recorrente ................................................... 25 

4.3 A sua natureza jurĂ­dica e os casos da Alemanha e PaĂ­ses Baixos ................ 27 

III- A PROBLEMÁTICA DA RESPONSABILIDADE ............................................................ 31 

5. Tentativas de regulação do transporte multimodal .............................................. 31 

5.1 A Convenção Internacional das Naçþes Unidas sobre o Transporte 
Multimodal de Mercadorias (MTC) ......................................................................... 32 
5.2 Soft Law ........................................................................................................ 33 

5.3 Acordos sub-regionais .................................................................................. 34 

6. Aplicação de convençþes unimodais ao transporte multimodal? ......................... 37 

6.1 CMR .............................................................................................................. 37 
6.2 Regras de Haia-Visby ................................................................................... 41 

6.3 COTIF-CIM .................................................................................................. 44 
6.4 Convenção de Montreal ................................................................................ 46 

6.5 Regras de RoterdĂŁo ....................................................................................... 47 
7. Sistemas de responsabilidade propostos .............................................................. 53 

7.1 Network liability system ................................................................................ 53 

7.2 Uniform liability system ................................................................................ 55 



10 
 

7.3 Modified liability system ............................................................................... 56 
7.4 Apreciação Crítica ........................................................................................ 57 

8. A implementação da tecnologia blockchain – admirável mundo novo ............... 61 
8.1 A digitalização dos documentos de transporte .............................................. 63 

8.2 Localização do dano e a Internet of Things (IoT) ......................................... 67 
8.3 Smart contracts e a automatização do contrato ............................................. 70 

IV – CONCLUSÃO ............................................................................................................ 74 

BIBLIOGRAFIA ................................................................................................................. 75 

JURISPRUDÊNCIA ............................................................................................................ 85 

 

 

 

 

 

 
 
 
 

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 



11 
 

I- INTRODUÇÃO   
 

O presente estudo divide-se essencialmente em duas partes. Ao longo do primeiro 

capĂ­tulo as questĂľes a abordar estarĂŁo relacionadas com o conceito geral de transporte 

multimodal. Porquanto, sendo, em nossa opiniĂŁo, um dos tipos de transporte mais importantes 

no âmbito do comÊrcio internacional, carece de uma explicitação clara das suas principais 

características. Começaremos por procurar definir o transporte multimodal para, de seguida, o 

distinguirmos de outros contratos de transporte que, apesar de apresentarem certas semelhanças, 

comportam vårias diferenças que urge sublinhar. Adicionalmente, serå importante, para 

completar esta conceção abstrata, enumerar algumas das vantagens inerentes a este tipo de 

transporte. Como forma de encerrar este capĂ­tulo, abordaremos o contrato em causa, tratando 

de apresentar, em primeiro lugar, as partes contratantes e a figura da subcontratação para, por 

fim, explorar uma temĂĄtica mais controversa que se prende com a natureza jurĂ­dica deste 

contrato. Para tal, usaremos como base os ordenamentos jurĂ­dicos da Alemanha e dos PaĂ­ses 

Baixos e os seus respetivos exemplos, visto serem os únicos países na Europa com disposiçþes 

legais a regular o transporte multimodal. 

Aqui chegados, importarĂĄ, no segundo capĂ­tulo, discorrer sobre a responsabilidade 

civil das partes e em que termos ĂŠ que, na prĂĄtica, ĂŠ feito o apuramento dessa responsabilidade. 

Visto que nĂŁo existe um regime uniforme, teremos que analisar as primeiras tentativas de 

regulação e, mais detalhadamente, a Convenção Internacional das Naçþes Unidas sobre o 

Transporte Multimodal de Mercadorias, de 1980 que, embora nĂŁo tenha entrado em vigor, 

contribuiu em grande medida para a perceção atual do transporte multimodal e serviu de base 

Ă  maioria das propostas que surgiram posteriormente. ApĂłs uma anĂĄlise destes regimes, 

tentaremos encontrar uma solução para o facto de não existir nenhuma convenção internacional 

que regule expressa e autonomamente este tipo de transporte. Assim, serĂĄ imperativo uma 

apreciação das convençþes unimodais em vigor para cada modo de transporte para perceber a 

sua viabilidade na aplicação ao nosso transporte multimodal. Paralelamente, teremos de 

concluir sobre a adoção de um sistema de responsabilidade que possa solucionar as questþes 

atĂŠ aqui apresentadas. 

A final, de modo a explorar os avanços tecnológicos que têm vindo a ser desenvolvidos 

mais recentemente, abordaremos a introdução da tecnologia blockchain no transporte 

internacional de mercadorias e quais as suas aplicabilidades, em concreto, ao transporte 



12 
 

multimodal, nomeadamente no que diz respeito Ă  responsabilidade civil das partes. Em suma, 

tentaremos abordar de forma clara e concisa como poderĂĄ esta tecnologia, em todas as suas 

vertentes, ajudar a melhorar a forma como se realizam estas transaçþes comerciais e 

revolucionar o transporte internacional de mercadorias.   

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 



13 
 

II - DO TRANSPORTE MULTIMODAL DE MERCADORIAS 
 

1. Noção geral  

Embora não haja uma definição uniforme, o transporte multimodal de mercadorias1  

pode ser caracterizado, em traços gerais, como o transporte de bens efetuado atravÊs de pelo 

menos dois modos distintos de transporte, de um local num determinado Estado onde se 

encontram os bens, para um outro local, num outro Estado2, tendo como base apenas um Ăşnico 

contrato3. Esta definição foi moldada essencialmente na Convenção Internacional das Naçþes 

Unidas sobre o Transporte Multimodal de Mercadorias, assinada em Genebra no dia 24 de maio 

de 19804 e dela podemos retirar as duas principais caracterĂ­sticas deste tipo de transporte: a 

unidade contratual e o transporte realizado atravĂŠs de vĂĄrios modos de transportes (pelo menos 

dois).  

Nos dias de hoje, o transporte internacional de mercadorias ĂŠ predominantemente 

multimodal5. As mercadorias são transportadas desde a “porta” do carregador à “porta” do 

destinatårio atravÊs da combinação de diferentes modos de transporte6. Em termos pråticos, 

 
1 Hå uma certa variedade terminológica no que diz respeito à definição deste tipo de transporte. Poderíamos chamar 
de transporte misto, intermodal ou combinado. Destes, o mais utilizado parece ser o transporte intermodal, 
principalmente pela sua divulgação na doutrina americana. No entanto, nas palavras de MARIAN HOEKS, 
“Multimodal Transport Law - The Law Applicable to the Multimodal Contract for the Carriege of Goods”, Wolters 
Kluwer, 2010, p. 4, com quem tendemos a concordar, “the preferable term is multimodal and not intermodal as 
«multi» refers to more than one, while «inter» means between.” Ora, “em termos práticos, vale dizer, na questão 
física, o transporte intermodal assemelha-se muito ao multimodal. Em termos jurídicos, há diferenças”. Cf. 
PAULO HENRIQUE CREMONEZE, “Prática de Direito Marítimo: O contrato de Transporte Marítimo e a 
Responsabilidade Civil do Transportador”, São Paulo, Aduaneiras, 2017, p. 58. Tanto este como os outros termos 
referidos nĂŁo se pautam pela precisĂŁo necessĂĄria, quando comparamos com o termo maioritariamente preferĂ­vel: 
transporte multimodal. Neste sentido, FRANCISCO CARLOS LOPÉZ RUEDA, “El Regímen Jurídico del Transporte 
Multimodal”, La Ley, Madrid, 2000, pp. 127-134. 
2 É seguro dizer que a maioria do transporte multimodal é internacional.  
3 Não estando afastada a possibilidade de existir uma subcontratação, como veremos mais adiante.  
4 United Nations Convention on International Multimodal Transport of Goods (MTC). Convenção esta que não 
chegou a entrar em vigor, mas que, não obstante, deixou uma clara marca no que toca à definição deste tipo de 
transporte. Cf. RALPH DE WIT, “Multimodal Transport. Carrier Liability and Documentation”, in Lloyd's London 
Press, Londres, 1995; LUÍS ALEXANDRE CARTA WINTER/ MARTINHO MARTINS BOTELHO, “O Regime Jurídico 
Internacional do Transporte Multimodal de Mercadorias: Um Comparativo entre a Convenção de Genebra de 1980 
e as Regras CNUCED/CCI”, in Lex Humana, Universidade Católica de Petrópolis, Vol. 6, n.º 1, 2014, p. 116 e ss. 
5 Cf., neste sentido, PAULA BÄCKDÉN, “The Contract of Carriage – Multimodal Transport and Unimodal 
Regulation”, Informa Law from Routledge, 2019, p. 3 e SIMON BAUGHEN, “Shipping Law”, 7th Ed., Routledge, 
2019, p. 170.  
6 “Empieza así a acuñarse la expresión «puerta a puerta» para referirse al transporte de mercancias, que se 
efectúa desde el almacén – generalmente, de un vendedor – al almacén – generalmente, del comprador. Servicios, 
que pueden implicar el traslado por uno o por vĂĄrios modos de transporte, y en el que pueden intervenir uno o 
vários portadores”. Cf., sobre este ponto, TATIANA ARROYO VENDRELL, “El contrato de Transporte Internacional 
de Mercancías Puerta a Puerta -Cooperacion y Conflicto Entre Convenciones”, Marcial Pons, 2015, p. 85. 



14 
 

pegando num exemplo, o transporte multimodal materializa-se da seguinte forma: Uma 

empresa de produção de medicamentos indiana e um distribuidor dos mesmos produtos inglês, 

com um armazĂŠm em Cambridge, acordam a compra e venda de uma grande quantidade de 

medicamentos. A melhor forma de desenrolar esta troca comercial seria atravĂŠs de um contrato 

de transporte multimodal em que o primeiro segmento seria o transporte marĂ­timo de 

mercadorias entre o porto de Navi Mumbai, na Índia e o porto de Southampton, no Reino Unido. 

DaĂ­ as mercadorias poderiam seguir o restante trajeto por via de transporte rodoviĂĄrio atĂŠ Ă  

cidade de Cambridge7. Este tipo de contrato simplifica a relação contratual entre o carregador 

e o transportador, pois em vez de realizar dois contratos de transporte separados, apenas precisa 

de celebrar um. Além disso, como veremos mais adiante, o transportador – que aqui será 

denominado de Operador de Transporte Multimodal (OTM) responsabiliza-se por todo o 

trajeto, desde a saĂ­da dos medicamentos do porto indiano atĂŠ estes se encontrarem na posse do 

comprador, independentemente do facto de por vezes os segmentos individuais do transporte 

multimodal estarem abrangidos por diferentes regimes de responsabilidade. A principal 

diferença reside, de facto, nos contratos. O que é novo é que, no presente, este transporte “porta-

a-porta” é realizado tendo por base apenas um contrato8 que efetivamente permite a utilização 

de mais do que um modo de transporte. Apesar de a mercadoria ser na mesma transbordada, 

permanece no mesmo contentor, Ă  medida que vai passando de um modo de transporte para 

outro, nĂŁo havendo assim rutura de carga. 

Ora, isto traz à colação um fenómeno de grande importância no råpido 

desenvolvimento do transporte multimodal: a contentorização9, que proporcionou uma maior 

vantagem operacional e econĂłmica, visto que o tratamento das mercadorias se tornou mais 

råpido e eficiente. Ademais, foi possível uma redução acentuada dos riscos inerentes à 

transferĂŞncia das mercadorias entre transportadores. O que nĂŁo significa, por outro lado, que os 

contentores são condição sine qua non para este tipo de transporte10, pois o contrato Ê tido como 

 
7 A maioria das empresas destinatårias não têm um armazÊm ou outras instalaçþes no porto de receção dos bens e 
essa ĂŠ uma das razĂľes que torna o transporte multimodal muito utilizado, visto que de forma mais eficiente as 
mercadorias chegam “à porta” do destinatário. 
8 Sobre o contrato em si, parte mais importante do transporte, mas igualmente mais potenciadora de problemas, 
debruçar-nos-emos mais à frente.  
9 A introdução dos contentores pode ser caracterizada como o primeiro passo na evolução do transporte multimodal 
e teve início da década de 50. Cf., nesta matéria, RALPH DE WIT, ob. cit. p. 5; DAVID A. GLASS, “Freight 
Forwarding and Multimodal Transport Contracts”, Routledge, 2012, p. 2 e MARIAN HOEKS, ob. cit., pp. 2-4.  
10 “The prerequisites for the carriage of goods by different modes of transport had existed since ancient times, 
when goods were first moved by boats and then by horses, many years before containers were first utilized. 
 



15 
 

multimodal independentemente da forma de acondicionamento das mercadorias. No entanto, 

não se pode negar a relação entre ambos e o que significou a contentorização na evolução do 

transporte multimodal11.  

Em relação ao regime aplicåvel a este tipo de transporte, não obstante os esforços 

realizados, nĂŁo hĂĄ nenhum normativo uniforme que o regule12. Isto traz, alĂŠm da Ăłbvia 

insegurança nas trocas comerciais, problemas jurídicos de difícil resolução, tal como o regime 

jurĂ­dico de responsabilidade aplicĂĄvel, provavelmente o maior destes problemas. Pois que, 

saber, no caso de ocorrĂŞncia de um dano, perda ou atraso, quem se irĂĄ responsabilizar civilmente 

perante o comprador pode ser uma questĂŁo de difĂ­cil resposta. Se ĂŠ verdade que, em teoria, 

neste tipo de contratos quem se responsabiliza por todo o transporte ĂŠ o Operador de Transporte 

Multimodal que ĂŠ aquele com quem o expedidor contrata,  tambĂŠm ĂŠ verdade que, nĂŁo raras as 

vezes, este Transportador celebra subcontratos com outros transportadores para efetuarem um 

determinado segmento do transporte no seu todo, seja por falta de meios ou por haver uma 

maior facilidade de logĂ­stica. Levantando-se, assim, outros problemas no que toca Ă  

responsabilização, pois ficamos sem saber concretamente quem serå responsåvel. Tudo isto 

varia consoante o local onde se verificou verdadeiramente o dano, isto ĂŠ, em que segmento de 

transporte. A questĂŁo torna-se ainda mais complexa quando o dano nĂŁo ĂŠ localizĂĄvel13.  E mais. 

Como não hå uma convenção de transporte multimodal em vigor, recorre-se muitas vezes às 

Convençþes Unimodais para resolver estas questþes, defendendo-se que se deve aplicar cada 

uma delas a cada segmento de transporte correspondente14.    

 

 
Therefore, it is incorrect to say that multimodal transportation appeared in the second half of the twentieth century 
with the first utilization of the container in 1956.” Cf. OLENA BOKAREVA, “Uniformity of Transport Law through 
International Regimes”, Edward Elgar, 2019, p. 42. 
11 “With the advent of the container, the practice of carrying goods using different modes of carriage expanded to 
the extent that it is now considered to be the fastest growing method of transporting goods”. Cf. CHRISTINE 
BESONG, “Towards A Modern Role For Liability In Multimodal Transport Law”, University of London, 2007, p. 
22.  
12 “None of the attempts to create unifrom law for multimodal carriage have as yet met with sucess, and there 
have been many.” O que se vem traduzindo num regime efetivamente fragmentado. Cf. MARIAN HOEKS, ob. cit., 
p. 10.  
13 É sobretudo nesta questão que os avanços tecnológicos poderão desempenhar um papel determinante.  
14 Tendo sido criados, neste âmbito, sistemas de responsabilidade próprios que serão tratados com pormenor no 
capĂ­tulo seguinte. A saber: o Network Liability System; Uniform Liability System e o Modified Liability System. 



16 
 

2. Distinção entre outras figuras 

Sendo a incerteza jurĂ­dica um dos principais problemas que surgem no transporte 

internacional de mercadorias, mais concretamente no transporte multimodal, mas tambĂŠm 

noutros ramos do direito internacional, não podemos, neste âmbito, deixar de especificar e 

distinguir brevemente o transporte multimodal de outros tipos de transporte, que embora 

semelhantes, comportam vårias diferenças pråticas.  

2.1 Transporte sucessivo 

Tal como no transporte multimodal, estamos perante um tipo de transporte complexo 

que pode ser definido como o transporte pelo qual, existindo apenas um contrato, este ĂŠ levado 

a cabo por vårios transportadores de forma sucessiva ou cumulativa15. A principal diferença 

prende-se com o facto ser realizado apenas por um modo de transporte, isto ĂŠ, hĂĄ um Ăşnico 

contrato que produz efeitos em relação a todos os transportadores, sem que haja uma troca de 

modo de transporte, sendo este efetuado na totalidade por mar, por terra ou ar16. Por essa razĂŁo, 

encontra previsĂŁo legal na CMR17, COTIF/CIM18, Regras de Hamburgo19 e ainda nas 

Convençþes de Varsóvia20 e de Montreal21. Em suma, os transportadores que sucedem ao 

primeiro, ao aceitarem a mercadoria e a declaração de expedição, tornam-se partes no contrato 

nas condiçþes da declaração da expedição22.  

Neste caso, cada um dos transportadores assume a obrigação de cumprir os segmentos 

a que estĂĄ adstrito, ao contrĂĄrio do que sucede no transporte multimodal em que, sem prejuĂ­zo 

de um eventual subcontrato, ĂŠ sobre o OTM que recai toda a responsabilidade pelo 

 
15 Cf., mais desenvolvidamente, NUNO MANUEL CASTELLO-BRANCO BASTOS, “Direito dos Transportes”, Cadernos 
IDET, Almedina, 2004, p. 71 e ss. 
16 Cf., nesta matéria, MANUEL JANUÁRIO DA COSTA GOMES, “Do Transporte «port to port» ao transporte «door to 
door», in I Jornadas de Lisboa de Direito Marítimo – O contrato de transpore marítimo de mercadorias, Almedina 
2008, p. 382; FRANCISCO CARLOS LOPÉZ RUEDA, ob. cit., pp. 48-51 e CARLOS LLORENTE GOMÉZ DE SEGURA, “El 
Contrato De Transporte Multimodal Internacional de Mercancias”, Contratos Internacionales, 1997, p. 594.  
17 Vide artigos 34.Âş- 40.Âş. 
18 Vide artigo 26.Âş. 
19 Vide, artigo 10.Âş. 
20 Vide artigo 30.Âş.  
21 Vide artigo 36.Âş.  
22 Este contrato encontra tambĂŠm previsĂŁo legal em Portugal, no que diz respeito ao transporte rodoviĂĄrio nacional 
de mercadorias, nos artigos 11.Âş e ss. do Decreto-Lei n.Âş 239/2003.  



17 
 

cumprimento integral do transporte. Com efeito, assiste-se a uma responsabilidade solidĂĄria de 

todos transportadores envolvidos23. 

2.2 Transporte segmentado 

Um dos tipos de transporte que mais facilmente se confunde com o transporte 

multimodal ĂŠ precisamente o transporte segmentado, isto porque hĂĄ tambĂŠm uma necessidade 

de recorrer a mais do que um modo de transporte. Todavia, a principal diferença reside no 

contrato. Ou, neste caso, nos contratos. O carregador, ou intermediĂĄrio, realiza um contrato para 

cada modo de transporte, ou seja, em vez de um Ăşnico contrato multimodal, temos vĂĄrios 

contratos unimodais24, um para cada segmento25. Diferentemente do que sucede no contrato de 

transporte multimodal, nĂŁo hĂĄ aqui unidade contratual26.  

Com esta figura, alĂŠm de vĂĄrios modos de transporte e vĂĄrios contratos, hĂĄ tambĂŠm 

uma pluralidade de intervenientes, o que acarreta diversas consequĂŞncias em termos de 

responsabilidade. Ora, como cada um dos segmentos de transporte tem a sua autonomia 

jurídica, hå uma separação total da responsabilidade. Os transportadores ficam, assim, sujeitos 

a um regime diferente, consoante o conteúdo do referido contrato e das múltiplas Convençþes 

Internacionais em vigor. O que quer dizer, em termos prĂĄticos, que se a mercadoria se perder 

ou danificar durante um destes segmentos, o Ăşnico responsĂĄvel serĂĄ o transportador com quem 

o carregador realizou o contrato para aquele modo de transporte em causa27. NĂŁo havendo lugar 

Ă  responsabilidade solidĂĄria ou direito de regresso, como sucede no transporte sucessivo, 

aludido supra.  

2.3 Transporte com reexpedição 

De forma geral, nesta figura o carregador e o transportador celebram um contrato em 

que este Ăşltimo se obriga a transportar as mercadorias apenas num determinado segmento e se 

 
23 “en cuanto que cada uno de los porteadores responde por la totalidad del transporte frente al emissor de la 
mercancia, sin importar quiĂŠn fue el culpable del daĂąo en la mencancĂ­as o retraso en la entrega (a menos que 
hayan incluĂ­do reservas en el documento de transporte). Por ello, cabe afirmar que el cargador o el destinatĂĄrio 
pueden reclamar frente a cualquiera de los porteadores. No obstante, en lo que se refiere a la relaciĂłn interna de 
los diversos porteadores, es oportuno advertir que el porteador que ha pagado la totalidade de la indemnizaciĂłn 
puede ejercer una acciĂłn de regresso contra los demĂĄs porteadores que hayan participado en la ejucuciĂłn del 
transporte y así lograr que el portador culpable assuma totalmente el pago de la indemnización”. Cf. AURA 
YOLIMA RODRÍGUEZ BURBANO, ob. cit. pp. 33-34. 
24 “Constitui uma justaposição de vários transportes unimodais”. Cf, JANUÁRIO DA COSTA GOMES, ob. cit. p. 384.  
25 Vide o nº 2 do artigo 3º da Convenção de Genebra de 1980.  
26 Cf, neste sentido, AURA YOLIMA RODRÍGUEZ BURBANO, ob. cit. p. 57.  
27 Cf. FRANCISCO CARLOS LOPÉZ RUEDA, ob. cit. p. 90.  



18 
 

obriga ademais a realizar, em nome do carregador um ou mais contratos com outros 

transportadores para o restante percurso. Como tal, o transportador tem duas funçþes. AlÊm da 

obrigação natural de realizar o transporte, obriga-se tambÊm a desempenhar tarefas de logística. 

Desta forma, como se de um transitĂĄrio se tratasse, responde tambĂŠm duplamente, isto ĂŠ, pelo 

transporte que realiza e pelos serviços que p";"""date"",""2020-10-27T09:54:52Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""2.0""
""xmp:CreatorTool"",""Soda PDF""
""pdf:docinfo:title"",""""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dc:creator"",""diogo""
""language"",""pt""
""Last-Modified"",""2020-10-27T09:54:52Z""
""dcterms:modified"",""2020-10-27T09:54:52Z""
""dc:format"",""application/pdf; version=2.0""
""title"",""""
""Last-Save-Date"",""2020-10-27T09:54:52Z""
""pdf:docinfo:creator_tool"",""Soda PDF""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2020-10-27T09:54:52Z""
""meta:save-date"",""2020-10-27T09:54:52Z""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2020-10-27T09:54:52Z""
""Content-Length"",""695959""
""pdf:hasMarkedContent"",""false""
""Content-Type"",""application/pdf""
""xmp:ModifyDate"",""2020-10-27T09:54:52Z""
""xmp:MetadataDate"",""2020-10-27T09:53:47Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""diogo""
""meta:author"",""diogo""
""pdf:producer"",""Soda PDF""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""85""
""resourceName"",""2020.10.28%20-%20Diogo%20Mendes%20Peixoto%20-%20Disserta%C3%A7%C3%A3o%20de%20Mestrado%202020.pdf""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""491"",""571"",""68"",""451"",""2348"",""2148"",""1130"",""750"",""3482"",""1024"",""2585"",""351"",""3852"",""3148"",""2882"",""2438"",""2902"",""2420"",""1744"",""3271"",""470"",""2955"",""3786"",""2974"",""2532"",""3067"",""3326"",""2654"",""3413"",""1695"",""2565"",""3734"",""3045"",""2329"",""2984"",""1572"",""2632"",""3368"",""2743"",""2853"",""3032"",""3425"",""3948"",""2447"",""3095"",""3076"",""3168"",""3703"",""3425"",""3628"",""3256"",""2253"",""2602"",""3386"",""2957"",""3136"",""2985"",""2888"",""3065"",""1047"",""2328"",""2823"",""3499"",""3018"",""2918"",""3294"",""3141"",""2631"",""2431"",""3068"",""2986"",""3159"",""1091"",""2445"",""2427"",""1452"",""1315"",""1417"",""1428"",""1447"",""1356"",""1414"",""1497"",""995"",""1224""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""Author"",""diogo""
""producer"",""Soda PDF""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""Soda PDF""
";https://scholar.google.ch/scholar?start=640&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098861-324;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;[PDF][PDF] Unconditionally secure quantum bit commitment: Revised;MX Luo, X Wang ; eprint.iacr.org;;"… 22]. QCC1 and QCC2 are useful for committing a crypto- graphic functionality. – This

first is oracle function. Suppose that Alice hopes to commit an or- acle function O

to Bob. This is generally difficult for any oracles. Two parties …";Autres articles;Version HTML;[PDF] iacr.org;https://eprint.iacr.org/2020/1077.pdf;"
Unconditionally secure quantum bit
commitment: Revised

Ming-Xing Luo1 and Xiaojun Wang2

1. Information Security and National Computing Grid Laboratory, Southwest
Jiaotong University, Chengdu 610031, China

2. School of Electronic Engineering, Dublin City University, Dublin 9, Ireland
mxluo@home.swjtu.edu.cn, xiaojun.wang@dcu.ie

Abstract. Bit commitment is a primitive task of many cryptographic
tasks. It has been proved that the unconditionally secure quantum bit
commitment is impossible from Mayers-Lo-Chau No-go theorem. A vari-
ant of quantum bit commitment requires cheat sensible for both parties.
Another results shows that these no-go theorem can be evaded using the
non-relativistic transmission or Minkowski causality. Our goal in this
paper is to revise unconditionally secure quantum bit commitment. We
firstly propose new quantum bit commitment using distributed settings
and quantum entanglement which is used to overcome Mayers-Lo-Chau
No-go Theorems. The present protocol is perfectly concealing, perfectly
binding, and cheating sensible in asymptotic model against entanglement-
based attack and splitting attack from quantum networks. It is then
extended to commit secret bits against eavesdroppers. We further pro-
pose two new applications. One is to commit qubit states. The other is
to commit unitary circuits. These new schemes are useful for commit-
ting several primitives including sampling models, random sources, and
Boolean functions in cryptographic protocols.

1 Introduction

Bit commitment as a basic cryptographic task has been applied in various
problems. A bit commitment protocol consists of two parties, the committer and
receiver. A committer, Alice, commits a bit x to the receiver who cannot recover
the value of x before unveiling it. In the unveiling stage, Alice sends some classical
or quantum information to Bob who can then unveil the committed bit. In ideal
settings, the goal of a commitment protocol is to guarantee that Bob recovers x
exactly which is initially committed by Alice (not changed after the commitment
stage), i.e., the perfectly binding. Moreover, Alice should also ensure that Bob
can learn no information about the committed bit before it being unveiled, i.e.,
the perfectly concealing.

Intuitively, a classical bit commitment protocol may be easily followed. The
committer can put the committed bit in the box which is locked using a unique
key. Any receiver can get no information because he/she cannot open the box
without key. In the unveiling stage, receiver can verify the committed bit by



opening the box with the received key. However, this protocol is only secure
when the box is unconditionally secure one-way system. Otherwise, Bob can
break the box with unlimited computation power. So far, it is believes that
there is no unconditionally secure bit commitment against the attackers with
unlimited computation powers.

Different from classical cryptography, quantum cryptography makes use of
quantum superposition states. One typical example is to construct key distribu-
tion protocol using four nonorthogonal states [7], or entanglement [20]. Quantum
key distribution provides the first nontrivial application of quantum superposi-
tion states for unconditionally secure cryptographic goal, which has not been
completed in classical cryptography. Hence, Brassard, et al. hope to invent a
similar quantum protocol for committing a secret bit [9]. Unfortunately, their
protocol is insecure from the no-go results of Mayers [40] and Lo and Chau
[36], which state that any concealing bit commitment protocol is argued to be
necessarily non-binding. These no-go theorems still hold when both players are
restricted by superselection rules.

Our goal is to revise the quantum bit commit by using distributed quantum
entanglement. As usual in quantum cryptography, we present the protocol in ide-
al assumptions of perfect state preparations, transmissions and measurements.
This poses no important problem here: all the protocols remain secure in the
presence of errors up to a negligible threshold. All the protocols are secure in
realistic implementations with negligible noises.

1.1 Our contributions

Quantum bit commitment We propose an unconditionally secure quantum
bit commitments using two-way quantum channel or one-way quantum channel.
These protocols are perfectly binding and perfectly concealing and cheat sensible.

1. We propose a quantum bit commitment (QBC1).
We use Einstein-Podolsky-Rosen (EPR) states and Greenberger-Horne-Zeilinger
(GHZ) states to design quantum bit commitment. Informally, committer and
receiver use four tripartite entangled states to encode one bit. Two orthogo-
nal entangled states are used for committing each value of one bit.
We should carefully overcome Mayers-Lo-Chau No-go Theorems [40, 36] which
forbid unconditionally secure quantum bit commitment originated from B-
B84 scheme [7]. On one hand, committer should firstly conceal the committed
bits against leaking the committed bit to receiver, i.e., committer guarantees
the reduced density matrix of the systems owned by receiver is invariant for
x = 0 and x = 1. On the other hand, receiver should bind the committed
bit after completing the committing steps against cheating of committer in
the unveiling stage. This is more difficult from Mayers-Lo-Chau No-go The-
orems [40, 36]. We use a random distributed quantum entanglement before
the unveiling stage. The system owned by committer can be regarded as a
quantum key while the systems of receiver can be viewed as a quantum lock
for binding the committed bit. It is also implementable in one-way manner.

2



2. We propose a private quantum bit commitment (QBC2).
In practical applications, committer wants to commit privacy messages to a
special receiver without leaking any information to potential adversary. In
QBC2, committer and receiver can build secure quantum channel by test-
ing the violation of CHSH inequality [14], and then share a random key.
Here, two parties complete a quantum bit commitment assisted by quantum
teleportation [8] and one-time pad [50]. This protocol is finally extended
for one-way quantum channel from committer to receiver. They are differ-
ent from device-independent bit commitments [44, 3] with nonzero cheating
probability.

Quantum qubit commitment Assume that committer Alice wants to commit
one qubit to receiver. We propose two kinds of quantum qubit commitment
(QQC) based on QBC1 and QBC2 using quantum privacy channel [5]. These
protocols are perfectly binding and perfectly concealing and cheat sensible.

3. We propose a quantum qubit commitment (QQC1).
Based on QBC1, we design a protocol to commit a qubit state chosen from
specific set. In QQC1, committer hides a qubit by encoding with a secret key
which is then committed using QBC1. Its security depends on the security of
QBC1 and new encoding [5].QQC1 provides the first secure quantum qubit
commitment which disproves recent no-go theorem [41]. This protocol can
be easily extended to multi-qubit states or one-way quantum channel.

4. We propose a private quantum qubit commitment (QQC2).
Assume that committer wants to commit privacy qubits to a special receiver
even if there is potential adversary. Similar to QBC2, the CHSH test [14] is
used to build quantum channel, which is then used for distributing random
key [20] and transferring qubits [8]. QBC2 is cheating sensible [50]. It is
finally extended for one-way quantum channel from committer to receiver.

Quantum circuit commitment Assume that Alice commits one circuit to
receiver Bob. Generally, one cannot transfer a quantum circuit to another. We
use another method by committing its outputs defined by the circuit U and
specific inputs. We propose two kinds of schemes for based on QQC1 and QQC2.
These protocols are perfectly binding and perfectly concealing and cheat sensible.

5. We propose a quantum circuit commitment (QCC1).
In QCC1, committer uses a random pure state as input going into a uni-
tary circuit. Similar to QQC1, committer uses random encoding to conceal
the output states. Moreover, the secret key is committed using QBC1. The
security of QCC1 is based on the privacy quantum channel [5], QQC1 and
statistical discrimination of two unitary operations [2]. QCC1 provides the
first secure quantum circuit commitment. This protocol can be easily ex-
tended for committing n-qubit unitary operations or Boolean functions even
for one-way quantum channel.

3



6. We propose a private quantum circuit commitment (QCC2).
SimilarQQC2, we design cheating sensible commitment against potential ad-
versary. The main idea is similar to QQC2 except for an additional encoding
of quantum circuit. The security is based on the CHSH test [14], random key
[20], teleportation [8], and one-time pad. This protocol is cheating sensible
for both legal parties, and adversary.

1.2 Applications

Commit a sampling model. Sampling as a statistical method provides s-
tatistical inferences about specific problems. Random sampling as a special mod-
el has been widely used in lattice-based cryptography [39, 24, 35]. The present
schemes can be used to commit specific sampling model.

– The first is Gaussian sampling for signature [39, 24, 35]. committer may use
an efficient and parallel Gaussian sampler to generate sample series, which
are then committed by committer and receiver using an extension of QBC1,
or QBC2 which provides a private commitment against leaking information.
Here, receiver may use classical method to verify randomness and specific
distribution from the committed samples.

– The second is quantum Boson sampling model [1] B for solving permanent
problem of matrix as #P-complete problem [49], which may be used for
analogue speech scramblers [6] or anonymous (t, w)-threshold scheme [46].
Alice can commit sampling machine to receiver Bob using QBC1 or QBC2.
The verification is completed by polynomial-time approximation algorithm
[30].

– The third is for recommender systems applied in Internet and E-commerce.
From a sampling model [47] we can generate samples from a rank-k approx-
imation of recommendation systems in polynomial time. Combining with
homomorphic encryption [22], the new model provides an efficient private
recommendation systems or private computations using QBC1 or QBC2.

Commit a random source. Random sources are elementary primitives for
cryptographic schemes. QQC1 and QQC2 are useful for committing a specific
random source.

– One example is uniform distribution over a discrete set {a1, · · · , an}, which
can be encoded into a superposition state |ϕ⟩ = 1√

n

∑n
i=1 |i⟩. Alice can com-

mit |ϕ⟩ using an extension of QQC1 or QQC2. Different from sampling
model, this scheme sends a random source to receiver.

– Another example is Gaussian source S for lattice-based cryptography [39,
24, 35]. All the samples may be limited to the finite interval [0, τσS ] with a
positive tail-cut factor τ for practical scenarios. committer can use coherent
entanglement [51] to complete committing continuous Gaussian source with
extensions of QQC1 or QQC2.

4



Commit functionality. Cryptographic functionality includes most of prim-
itives such as encryption, authentication, signature, delegation computation and
privacy computation [22]. QCC1 and QCC2 are useful for committing a crypto-
graphic functionality.

– This first is oracle function. Suppose that Alice hopes to commit an or-
acle function O to Bob. This is generally difficult for any oracles. Two
parties may focus on special oracles which should be distinguished statis-
tically using polynomial resources. One method is to commit its graphic set
G = {(x,O(x))} using QBC1 for discrete inputs x ∈ {0, 1}n, or QQC1
for continuous inputs. Another method is to represent an oracle O(x)) by a
Boolean function F [13]. This may be committed by using QCC1 or QCC2.

– Second is quantum solver which is a quantum circuit or quantum model
for solving special problem. An interesting quantum solver may be built on
Shor’s algorithm [45] or Grover’s algorithm [26]. These quantum solvers can
be represented by proper unitary transformations U ∈ SU(2n). committer
may use an extension of QCC1 or QCC2 for committing unitary operations.
Interesting, this can be regarded as a different case of delegation computation
using homomorphic encryption [22]. These schemes are different from zero-
knowledge proof [12] which leaks no information for any receiver.

1.3 Related works

Several recent papers discussed similar issues. In view of the no-go results,
there are various constructions under reasonable constraints. Kent [31] shows
that relativistic signalling constraints may facilitate secure bit commitment.
In cheatsensitive bit commitment protocols [4, 29], both players may have the
chance to cheat, however, their fraud may be detected by the adversary [27].
Building on Kent’s original proposal [32], the tradeoff between the bindingness
and concealment has recently been investigated [10]. Other researchers change to
build bit commitment protocols with practical relativistic security [37], partial
security with cheating probabilities [32, 15, 16], computational security [18], clas-
sical security without communication [11, 17], asymptotical security [27], device-
independent security [44]. Meanwhile, the Mayers-Lo-Chau no-go theorem is not
general enough to exclude all conceivable quantum bit commitment protocols.

Although our schemes are generally presented as committing one bit, there is
no technique limit to generalize into commit bit string. The second improvement
of quantum resources should be interesting. Another is interesting applications
of quantum bit commit, quantum qubit commit or quantum circuit commit.
We summarize the mentioned variants of quantum commitment in Table 1. We
view our work as an initial step and hope further fundamental investigations of
noisy scenarios or imperfect scenarios or cryptographic applications inspired by
quantum commitment.

There are lots of open problems. First, is there a secure quantum bit com-
mitment without distributed storage before the unveiling stage? Second, are

5



Table 1. The security result of present quantum bit commitments using entanglement.
PS denotes perfectly security including perfectly concealing and binding. PP denotes
perfectly privacy against eavesdropper. RS denotes relativistic security. SS denotes
statistical security. CS denotes computational security. PPS means that at least one
party has a non-negligible cheating probability.

PP RS SS CS PPS

[18] - - -
√

-

[4, 29, 32] - - - -
√

[31, 29, 33, 37] -
√

- - -

[44, 15, 16, 3]
√

- - - -

QBC1, QQC1, QCC1 √
- - - -

QBC2, QQC2, QCC2 -
√

- - -

unconditionally secure quantum one-way functions necessary for the construc-
tion of quantum bit commitment when there is no distributed storage of en-
tanglement? Recent results show that there are quantum bit commitment with
unconditionally concealing and computationally binding from any quantum one-
way permutation [18]. Third, can we construct quantum bit commitment with
other reasonable scenarios?

2 Preliminary

2.1 Quantum ingredients

Denote a d-dimensional Hilbert space by Hd. A quantum pure state |ϕ⟩ is
vector inHd with unit norm. The density matrix of |ϕ⟩, i.e., ρϕ = |ϕ⟩⟨ϕ|, is a pos-
itive semi-definitive matrix. An ensemble of pure states {|ϕi⟩}mi=1 is represented
by the positive semi-definitive matrix of ρ =

∑m
i=1 piρϕi , where pi denotes the

probability of |ϕi⟩. In what follows, we denote Hilbert space of the system A by
HA if its dimension is not considered.

Denote {|0⟩, |1⟩} as the computational basis of H2. Another one is rectilinear
basis of {|+⟩, |−⟩} with |±⟩ = 1√

2
(|0⟩ ± |1⟩). For multiple qubits, there are

entangled states that can not be decomposed into the product of single qubit
states. One example is EPR state [21] in Hilbert space H2 ⊗H2 defined as

|EPR⟩ = 1√
2
(|0, 0⟩+ |1, 1⟩) (1)

Another entanglement is tripartite GHZ state [23] in Hilbert space H2⊗H2⊗H2

which is defined as

|GHZ⟩ABC =
1√
2
(|0, 0, 0⟩+ |1, 1, 1⟩)ABC (2)

A projection measurement of quantum state in Hilbert space Hn is described
by a set of n projection operators {Mi}ni=1, whereMis satisfy

∑n
i=1 Mi = 1 with

the identity operator 1.

6



For qubit space H2, Pauli operators σx, σy, σz and Hadamard transformation
H have matrix representatives as follows

σx =

(
0 1
1 0

)
, σy =

(
0 −i
i 0

)
, σz =

(
1 0
0 −1

)
,H =

1√
2

(
1 1
1 −1

)
(3)

For two-qubit gates, the controlled not (CNOT) gate is given by CNOT=diag(1, σx).

2.2 CHSH inequality

Quantum entanglement may result in interesting statistics that cannot be
described with classical physics. Here, we use CHSH inequality [14] given by

⟨A0B0⟩+ ⟨A0B1⟩+ ⟨A1B0⟩ − ⟨A1B1⟩ ≤ 2 (4)

for two parties sharing a hidden variable in classical scenarios, where Ax and By

are measurements with outputs in the set {Âą1} which are conditional on inputs
x, y ∈ {0, 1}, ⟨AxBy⟩ (named as correlators) denotes the average outcomes given
by ⟨AxBy⟩ =

∑
a,b=Âą1 abP (a, b|x, y), P (a, b|x, y) denotes the joint probability

distribution for two outputs a, b ∈ {1,−1} conditional on two inputs x, y ∈
{0, 1}, which may depend on some hidden variable [14]. In quantum scenarios,
for each round of experiment Alice and Bob share an EPR state |EPR⟩. Alice
performs local measurement using observable Ax ∈ {σz, σx} while Bob performs
local measurement using observable By ∈ { 1√

2
(σz ¹ σx)} on their shared qubit.

The expect of quantum observable Ax and By is given by ⟨AxBy⟩ = tr[Ax ⊗
By|EPR⟩⟨EPR|]. Hence, two parties can get

⟨A0B0⟩+ ⟨A0B1⟩+ ⟨A1B0⟩ − ⟨A1B1⟩ = 2
√
2 (5)

which violates the inenquality (4). This means that the quantum correlations
derived from local measurements on EPR state is incompatible with any classical
correlations from shared randomness [14].

2.3 Quantum teleportation

EPR state as an interesting resource is useful for transmitting an unknown
qubit faithfully [8]. The protocol is assisted with local operations and classi-
cal communication (LOCC). Assume that Alice and Bob share one EPR pair
|EPR⟩AB prior to transmission, where Alice has qubit A and Bob has qubit
B. Alice wants to transmit an unknown qubit A0 in the state |χ⟩ to Bob. Alice
firstly performs a joint measurement on A0 and A and broadcasts outcomes. Bob
then performs a unitary operation on B (depending on measurement outcomes)
to recover |χ⟩B . The success probability is unit. Any adversary can only eaves-
drop measurement outcomes, which have no information related to qubit A0.
This provides an unconditionally secure transmission of quantum states assisted
by classical communication and secure quantum channel.

7



Theorem 1 (Quantum no-communication theorem) [25]. It is impos-
sible for one observer, by making a measurement of a subsystem of the total
state, to communicate information to another observer during measurement of
an entangled quantum state.

The quantum no-communication theorem [25] implies that one can not trans-
fer information faster than the speed of light through the quantum measurement
process even if two parties share an entanglement.

3 Quantum bit commitment

In this section, we propose two quantum bit commit (QBC) protocols using
EPR state [21], GHZ state [23] and noiseless quantum channels.

Definition 1. A QBC is perfectly binding if committer cannot change the re-
duced density matrix of particles owned by receiver after committing, i.e.,

ρCom:x = ρUnv:x (6)

where ρCom:x (or ρUnv:x) denotes the reduced density matrix of particles own by
receiver in the committing stage (or the unveiling stage).

Definition 2. A QBC is perfectly concealing if receiver cannot learn any useful
information before the unveiling stage, i.e.,

ρx = ρx⊕1 (7)

where ρx denotes the reduced density matrix of particles owned by receiver for
committing the bit x ∈ {0, 1} and ⊕ denote plus with modular 2.

In ideal scenarios, QBC should be perfectly binding and perfectly concealing.
Another weaker variant of QBC is cheat sensible [4, 29].

Definition 3. A QBC is cheat sensible if any cheating strategy of each party
can be detected by the other with a non negligible probability, i.e.,

(i) Committer cannot change the committed bit x into x′ after the commitment
stage without being detected by receiver, i.e.,

Pr[Succcommiter(x→ x′)|commitcommiter(x)] < nelg(ϵ) (8)

where nelg(Ďľ) is a negligible constant depending on some parameter Ďľ.
(ii) Receiver cannot learn any useful information of x before it being unveiled

without being detected by committer, i.e.,

Pr[Succreceiver(I(x;x
′) > nelg(ϵ))|commitcommiter (x)] < nelg(ϵ) (9)

where I(x;x′) denotes Shannon mutual information of variables x and x′

(obtained by receiver) [42].

The assumptions of our protocols are as follows.

A1. Alice and Bob have unlimited quantum ability including quantum computer.

8



A2. Alice is honest for committing x ∈ {0, 1} in the committing stage while she
may be not in the unveiling stage.

A3. Bob may learn the information of the committed bit x before unveiling.

A4. Both the classical and quantum channels are noiseless.

A1 implies that both parties have abilities to perform quantum operations
such as preparing, storing or measuring states. From A2, Alice is not allowed
to commit a wrong bit x′ which is finally unveiled as the right bit x. The fake
commitment is useless because Bob finally convinced the right bit. We do not
consider this cheating. From A3, Alice hides x perfectly. Otherwise, Bob may
recover it before the unveiling stage. A4 is used to show that all the evaluations
are performed without noise.

3.1 Quantum bit commitment with two-way quantum channel

We present a new scheme using distributed particles to realize concealing
and binding tasks. The detail is shown in QBC1. Different from recent GHZ
paradox-based protocol [44], all the measurements are performed by receiver.
Another difference is from the preparations of quantum entanglement by receiver.
From these differences, we can use qubit as quantum locking key. This allows an
unconditionally secure quantum bit commitment.

QBC1

Commitment
1. Bob prepares an EPR state |EPR⟩AB , and sends the qubit A to Alice.
2. After receiving A Alice performs the following operations.

2.1 Alice performs CNOT A and an auxiliary qubit A0 in the state |0⟩A0 .
2.2 Alice randomly chooses one bit r ∈ {0, 1} according to uniform distribution,

and performs qubit operation Hxσr
x on A.

2.3 Alice sends A to Bob.
Unveiling

3. In the unveiling stage, two parties perform the following operations.
3.1 Alice sends the qubit A0 and bits {x, r} to Bob.
3.2 Bob performs σr

xH
x on A. He performs measurement on A0, A and B under

the basis {|Φ0⟩ = 1√
2
(|0, 0, 0⟩+ |1, 1, 1⟩),|Φ1⟩ = 1√

2
(|0, 1, 0⟩+ |1, 0, 1⟩),

1− |Φ0⟩⟨Φ0| − |Φ1⟩⟨Φ1|}. The commitment is right if and only if he obtains
{|Φ0⟩, |Φ1⟩} with unit probability.

Correctness-Take x = 0 as an example. The total state of A0, A and B is
changed from |0⟩A0 |EPR⟩AB into |Φ0⟩ if r = 0, or |Φ1⟩ if r = 1. |Φ0⟩ and |Φ1⟩
are orthogonal states. Hence, Bob can convince x = 0 from the measurement
from step 3.2 in the unveiling stage. Similar result holds for x = 1.

9



3.2 Security analysis

Similar to the analysis of Mayer-Lo-Chau no-go theorem [40, 36], the security
of QBC1 includes two parts. One is perfectly concealing. The other is perfectly
binding. Similar to quantum key distribution [7], it is generally impossible for
constructing a perfectly secure bit commitment. Here, we consider asymptotically
perfect security [7], which means that QBC1 can be arbitrarily close to perfectly
concealing and perfectly binding when n is large enough.

Theorem 2. QBC1 is perfectly concealing if committer is honest.
Proof. Assume that Alice honestly implements all operations in the commit-

ting stage. From step 2.2, the correspondence between the committed bit x and
total system |Φx,r⟩ of Alice and Bob is given by

C : x = 0 7→ {|Φ00⟩A0AB = |Φ0⟩, |Φ01⟩A0AB = |Φ1⟩}
x = 1 7→ {|Φ10⟩A0AB , |Φ11⟩A0AB} (10)

where |Φ10⟩ = 1√
2
(|0,+, 0⟩ + |1,−, 1⟩), |Φ11⟩ = 1√

2
(|0,−, 0⟩ + |1,+, 1⟩), and C

denotes committing in step 2. The density matrices of A and B is given by
ρAB = 1

41 for x = 0 or x = 1. Bob cannot distinguish A and B before unveiling.
Similar result holds for other inputs in Appendix A.

QBC1 will be implemented in parallel with n EPR states. Bob can get the
same committed bit with unit probability. Hence, Alice can realize asymptoti-
cally perfectly concealing when n is large enough. ďż˝

Theorem 3. QBC1 is perfectly binding if receiver is honest.
Proof. The binding is actually essential drawback in previous schemes [9]. In

Mayer-Lo-Chau No-go theorem [40, 36], the main drawback is from final system
after committing. In QBC1, there are four final states given in Eq.(10). From
Schmidt decomposition the local basis of B in Eq.(10) cannot be changed by
Alice after committing. In what follows, we complete the proof with two methods.

Proof based on Theorem 1 [25]. The proof is completed by contradiction.
Take |Φ00⟩ as an example. Suppose that Alice wants to unveil x = 1 but com-
mitting x = 0. Assume that Alice can successfully change |Φ00⟩ into |Φ10⟩ in the
unveiling stage. There is a unitary operation UA′A0 on A0 and axillary system
A′ in the state |0⟩ satisfying:

(UA′A0 ⊗ 1AB)|0⟩A′ |Φ00⟩A0AB = |ψ⟩A′ |Φ10⟩A0AB (11)

where |ψ⟩A′ is any normalized state.
From Eq.(11), we construct a communication protocol. Alice and Bob share

n copies of |Φ00⟩A0AB , where Alice has A0 and Bob owns A and B in each
copy. Alice performs nothing for transmitting the bit y = 0 while she performs
the local operation UA′A0 on the system A′ in the state |0⟩ and A0 if y = 1.
Bob performs measurement on A and B with projection operators {Pi0i1 =
|i0, i1⟩⟨i0, i1|, i0, i1 = 0, 1}. He gets a probability distribution

Pr(i0i1 = 00) = Pr(i0i1 = 11) =
1

2
(12)

10



for |Φ00⟩, or the other probability distribution as

Pr(i0i1 = 00) = Pr(i0i1 = 01) = Pr(i0i1 = 10) = Pr(i0i1 = 11) =
1

4
(13)

for |Φ10⟩. This means that Bob can recover one bit y by distinguishing the output
distribution. Note that the present communication protocol do not require any
communication between Alice and Bob. This contradicts to Theorem 1 [25].
Hence, there is no local operation UA′A0 for Alice satisfying Eq.(11).

Similarly, Alice cannot use any local operations to change the state in {|Φ00⟩, |Φ01⟩}
into any one in {|Φ10⟩, |Φ11⟩}, and conversely. Another proof is based on stabilizer
of GHZ state given in Appendix B.

We have proved the binding security using two different methods. Actually,
this is insufficient. The main reason is that there are three qubits owned by two
parties. Alice may transmit a different qubit A′ (not the qubit A) in the step 1,
and keeps the qubits A and A0. And then, Alice use local operations to get a
joint state |Φi0i1⟩A0A′B in Eq.(10) in the unveiling stage. This splitting attack is
analysed in Appendix C.

Theorem 4. QBC1 is cheating sensible.
Proof. Firstly, Bob can detect Alice’s cheating in the unveiling stage if Alice

wants to change the committed bit. Alice should ensure the binding for Bob
before the committed bit being unveiled. Any local operations performed by
Alice will then disturb the global states in the unveiling stage. On the other
hand, any local unitary operations do not change the reduced density matrices
of particle owned by Bob. Hence, Alice has to perform the local measurement
to forge the committed bit or change the committed bit after step 2. However,
the failure probability will result in a nonzero detecting probability. Otherwise,
Alice has committed the wrong bit in the commitment stage (see Appendix D).

Another cheating is from Bob who may prepare a fake state in step 1 or
performs local measurement after step 2 to recover the committed bit. To detect
this cheating, Alice may require Bob to send two qubits A and B to her. And
then, She implements step 3.2 because she knows {x, r}. The proof is similar to
Appendix D. Another method is to test GHZ paradox [23, 44]. Hence, QBC 1 is
cheating sensible. This completes the proof. ďż˝

3.3 Quantum bit commitment using one-way quantum channel

If Alice prepares a GHZ state |Φ00⟩ in step 1, QBC1 do not require quantum
channel from Bob to Alice. This provides an implementation with one-way quan-
tum channel. The proof of perfectly concealing is similar to Theorem 2. However,
perfectly concealing is different from Theorem 2 because all the quantum states
are prepared by Alice, see Appendix E. Although all quantum states are pre-
pared by committer, receiver can detect the cheating operations of committer.
The main technique is from distributed scenarios in step 2.

Now, consider the detection to Bob’s cheating for recovering the committed
bit by performing local measurement after step 2. Since the present protocol

11



uses one-way quantum channel from Alice to Bob, Bob cannot send the qubits
A and B to Alice for detecting. One possible solution is to test GHZ paradox
[23, 44], where all the final states |Φ01⟩s are locally equivalent to GHZ state [23].
It means that QBC1 is cheating sensible from Definition 3 in one-way manner.

4 Private quantum bit commitment

In Sec.3, we propose two ideal quantum bit commitments. The committed
bit is transmitted in an open channel. This leaves chance for an eavesdropper
[3]. We here present a private quantum bit commitment. The main idea is as
follows. Two parties build secure quantum channel based on CHSH inequality
[14]. These channels are used to teleport qubits securely [8] and distribute key
[20]. Finally, Alice can send the committed bit by using one-time pad [50].

4.1 Two-way quantum channel

Assume that Alice commits bit string x1 · · ·xℓ to Bob secretly. We present
private qubit commitment as QBC2.

QBC2

1. Building secure quantum channels
1.1 Bob prepares 2n EPR states ⊗2n

i=1|EPR⟩AiBi , and sends Ai’s to Alice.
1.2 Bob randomly chooses a qubit subset {Bi1 , · · · , Bim} with im ≈

√
n. He

performs measurement with observable Bŷ chosen from { 1√
2
(σz ¹ σx)} with

uniform distribution. He broadcasts bit string i1 ¡ ¡ ¡ im.
1.3 Alice performs measurements on Ai1 , · · · , Aim using observable Ax̂ chosen

from {σz, σx} with uniform probability. If their outcomes satisfy

⟨A0B0⟩+ ⟨A0B1⟩+ ⟨A1B0⟩ − ⟨A1B1⟩ < 2
√
2− negl(ϵ) (14)

they stop the commitment. Otherwise, they continues the protocol.
2. (Commitment)

2.1 Encode xi as step 2.1 in QBC1 using |EPR⟩AiBi and an axillary qubit Ci.
2.2 Alice teleports Ai to Bob [8].

3. (Unveiling)
3.1 Alice and Bob share a random bit string k1 ¡ ¡ ¡ ks by using quantum key

distribution [20].
3.2 Alice teleports Ci to Bob [8].
3.3 Alice generates a signature y1 · · · yt [50]. She gets cyphertext c1 · · · ct+ℓ with

ci = xi ⊕ ki for i ≤ ℓ and cj = yj−ℓ ⊕ kj for j > ℓ. Finally, she sends
c1 · · · ct+ℓ to Bob.

3.4 Bob recovers x1 · · ·xℓy1 · · · yt using the shared keys. He detects adversary by
verifying signature y1 · · · yℓ [50]. If there is no adversary, Bob can convince xi

using step 2.2 of QBC1, i = 1, · · · , ℓ.

12



The correctness of QBC2 is easily followed from QBC1, quantum teleporta-
tion, and one-time pad.

The security analysis of QBC2 is based on QBC1, CHSH test [14] and quan-
tum teleportation [8].

Theorem 5. QBC2 is perfectly concealing, perfectly binding, and cheating sen-
sible.

Proof. The proofs of perfectly concealing, perfectly binding and cheating sensi-
ble of committer and receiver are similar to the proofs of QBC1 in Sec.3. In what
follows, we only need to prove that QBC2 is cheating sensible against attackers
from outside if committer and receiver are honest.

There are three facts. First, step 1 is used to distribute EPR states from Bob
to Alice. Denote quantum observable of committer and receiver as Ax̂=0 = σz,
Ax̂=1 = σx, Bŷ=0 = 1√

2
(σz + σx), and Bŷ=1 = 1√

2
(σz − σx). Suppose that an

EPR state is changed into

|Φ̂⟩AiBi =
1√
2
(|ϕ0⟩|0⟩+ |ϕ1⟩|1⟩) (15)

by an eavesdropper, where {|ϕ0⟩ = cos θ|0⟩ + eiϕ sin θ|1⟩, |ϕ1⟩ = cos θ|1";"""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""12"",""1"",""0"",""1"",""5"",""1"",""0"",""1"",""1"",""5"",""1"",""0"",""1"",""24"",""1"",""0"",""0"",""0"",""3"",""7"",""4"",""5"",""1"",""4"",""0""
""pdf:PDFVersion"",""1.4""
""xmp:CreatorTool"","" TeX output 2020.09.07:1613""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dcterms:created"",""2020-09-07T08:13:26Z""
""language"",""en""
""dc:format"",""application/pdf; version=1.4""
""pdf:docinfo:creator_tool"","" TeX output 2020.09.07:1613""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""Content-Length"",""255682""
""pdf:hasMarkedContent"",""false""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""meta:creation-date"",""2020-09-07T08:13:26Z""
""created"",""2020-09-07T08:13:26Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""30""
""Creation-Date"",""2020-09-07T08:13:26Z""
""resourceName"",""1077.pdf""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""2182"",""2610"",""2382"",""2198"",""2582"",""1728"",""1982"",""1815"",""1889"",""2208"",""2459"",""1784"",""2010"",""1845"",""1889"",""1634"",""1865"",""1814"",""1620"",""1723"",""2414"",""2833"",""2624"",""2362"",""1714"",""1876"",""1690"",""1442"",""1470"",""791""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""producer"",""MiKTeX-dvipdfmx (20110311)""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""MiKTeX-dvipdfmx (20110311)""
""pdf:docinfo:created"",""2020-09-07T08:13:26Z""
";https://scholar.google.ch/scholar?start=870&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098879-369;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Ad hoc multi-input functional encryption;S Agrawal, M Clear, O Frieder, S Garg… ; 11th Innovations in …, 2020  drops.dagstuhl.de;;"… Experiment INDaMIFE A (1?) (1n,I, (PPi)i?I , st) ?$ A0(1?) b ?$ {0, 1} For all i /?

I do: (MSKi, PPi) ?$ aMIFE.Setup(1?) st ?$ A Oenc(ˇ,ˇ,Okg(ˇ,ˇ, 1 (st) b ?$ A

Oenc(ˇ,ˇ,Okg(ˇ,ˇ, 2 ((PPi)i/?I , st) Return (b = b ) Oracle Oenc(i, x0, x1";Cité 9 fois;Les 7 versions;[PDF] dagstuhl.de;https://drops.dagstuhl.de/opus/volltexte/2020/11725/pdf/LIPIcs-ITCS-2020-40.pdf;"
Ad Hoc Multi-Input Functional Encryption
Shweta Agrawal
Dept. of Computer Science and Engineering, IIT Madras, Chennai, India
shweta@iitm.ac.in

Michael Clear
Dept. of Computer Science, Georgetown University, Washington, DC, USA
clrmic2@gmail.com

Ophir Frieder
Dept. of Computer Science, Georgetown University, Washington, DC, USA
ophir@ir.cs.georgetown.edu

Sanjam Garg
Dept. of EECS, University of California at Berkeley, CA, USA
sanjamg@berkeley.edu

Adam O’Neill
Dept. of Computer Science, University of Massachusetts, Amherst, MA, USA
amoneill@gmail.com

Justin Thaler
Dept. of Computer Science, Georgetown University, Washington, DC, USA
Justin.Thaler@georgetown.edu

Abstract
Consider sources that supply sensitive data to an aggregator. Standard encryption only hides the
data from eavesdroppers, but using specialized encryption one can hope to hide the data (to the
extent possible) from the aggregator itself. For flexibility and security, we envision schemes that
allow sources to supply encrypted data, such that at any point a dynamically-chosen subset of
sources can allow an agreed-upon joint function of their data to be computed by the aggregator. A
primitive called multi-input functional encryption (MIFE), due to Goldwasser et al. (EUROCRYPT
2014), comes close, but has two main limitations:

it requires trust in a third party, who is able to decrypt all the data, and
it requires function arity to be fixed at setup time and to be equal to the number of parties.

To drop these limitations, we introduce a new notion of ad hoc MIFE. In our setting, each source
generates its own public key and issues individual, function-specific secret keys to an aggregator. For
successful decryption, an aggregator must obtain a separate key from each source whose ciphertext
is being computed upon. The aggregator could obtain multiple such secret-keys from a user
corresponding to functions of varying arity. For this primitive, we obtain the following results:

We show that standard MIFE for general functions can be bootstrapped to ad hoc MIFE for
free, i.e. without making any additional assumption.
We provide a direct construction of ad hoc MIFE for the inner product functionality based on
the Learning with Errors (LWE) assumption. This yields the first construction of this natural
primitive based on a standard assumption.

At a technical level, our results are obtained by combining standard MIFE schemes and two-round
secure multiparty computation (MPC) protocols in novel ways highlighting an interesting interplay
between MIFE and two-round MPC.

2012 ACM Subject Classification Security and privacy → Cryptography; Security and privacy
→ Public key (asymmetric) techniques; Security and privacy → Mathematical foundations of
cryptography

Keywords and phrases Multi-Input Functional Encryption

Digital Object Identifier 10.4230/LIPIcs.ITCS.2020.40

© Shweta Agrawal, Michael Clear, Ophir Frieder, Sanjam Garg, Adam O’Neill, and Justin Thaler;
licensed under Creative Commons License CC-BY

11th Innovations in Theoretical Computer Science Conference (ITCS 2020).
Editor: Thomas Vidick; Article No. 40; pp. 40:1–40:41

Leibniz International Proceedings in Informatics
Schloss Dagstuhl – Leibniz-Zentrum für Informatik, Dagstuhl Publishing, Germany

mailto:shweta@iitm.ac.in
mailto:clrmic2@gmail.com
mailto:ophir@ir.cs.georgetown.edu
mailto:sanjamg@berkeley.edu
mailto:amoneill@gmail.com
mailto:Justin.Thaler@georgetown.edu
https://doi.org/10.4230/LIPIcs.ITCS.2020.40
https://creativecommons.org/licenses/by/3.0/
https://www.dagstuhl.de/lipics/
https://www.dagstuhl.de


40:2 Ad Hoc Multi-Input Functional Encryption

Related Version A full version of the paper is available at https://eprint.iacr.org/2019/356.

Funding Sanjam Garg: Research supported in part from DARPA/ARL SAFEWARE Award
W911NF15C0210, AFOSR Award FA9550- 15-1-0274, AFOSR YIP Award, DARPA and SPAWAR
under contract N66001-15-C-4065, a Hellman Award and research grants by the Okawa Foundation,
Visa Inc., and Center for Long-Term Cybersecurity (CLTC, UC Berkeley). The views expressed are
those of the author and do not reflect the official policy or position of the funding agencies.

Acknowledgements We thank Romain Gay for pointing out a subtlety in the security definition of
(standard) MIFE for inner products, which necessitated a minor adjustment in our ad hoc MIFE
construction.

1 Introduction

In modern society, there is an inherent need for external entities to aggregate and analyze
sensitive data from a variety of sources. A few prominent examples are:

To track diseases, disease control centers would like hospital patients’ medical information.
To determine medication efficacy for a given subpopulation, pharmaceutical companies
would like patients’ genomic information.
To provide targeted advertising to consumers, corporations would like buyers’ demographic
information.

However, this release of sensitive data to external entities is unsettling, as these entities must
now be trusted to preserve the confidentiality of the released data. We would like to avoid
the need for this trust and believe that specialized encryption schemes will be an important
tool for doing so. At a high level, we would like schemes that allow users to encrypt their
data before transferring them to an external entity, such that only certain user-specified
joint functions of the data are revealed to the entity holding it. We would like this security
guarantee to be supported in a flexible way, allowing joint functions of the data to be revealed
by any dynamically-chosen subset of users that permit it.

A primitive that comes close, due to Goldwasser et al. [45], is multi-input functional
encryption (MIFE). To understand MIFE, we first recall the simpler notion of functional
encryption (FE) [20]. Just as in traditional encryption, in functional encryption ciphertexts
can be generated with an encryption key. However, each decryption key is associated with
a function f , and decryption of an encryption of m using this key results in not m but
f(m). Intuitively, security requires that nothing more than f(m) can be learned from the
encryption of m and the decryption key for f . In MIFE, decryption keys allow computing
joint functions of (possibly) different plaintexts underlying multiple ciphertexts. That is,
decryption takes a key for a function f and ciphertexts c1, . . . cn encrypting m1, . . . ,mn, and
outputs f(m1, . . . ,mn).

However, MIFE has an important drawback: encryption and decryption keys are generated
via a global setup procedure run by an external entity usually called the key authority. This
begs the question of whether putting trust in the key authority is really better than putting
trust in the external entities that aggregate and analyze the data in the first place. A similar
point was made by Rogaway about identity-based encryption (IBE) [60]. Indeed, removing
this in the case of IBE (and other settings) has been an active area of investigation, e.g.
see [18, 49, 35]. We contend that for MIFE (and indeed FE) the concern is heightened, as the
authority can not only decrypt all the data but is also the one in charge of which functions of
the data other external entities can compute. Hence, MIFE does not allow users to enforce
their own privacy policies.

https://eprint.iacr.org/2019/356


S. Agrawal, M. Clear, O. Frieder, S. Garg, A. O’Neill, and J. Thaler 40:3

Additionally, from a flexibility standpoint, MIFE is limited in that it fixes the number of
senders and function arity at setup time. This does not support a dynamic setting in which
users can join or leave. Progress on removing this limitation was made by Badrinarayanan et
al. [10], who introduced a notion of MIFE for unbounded arity functions. However, their
notion does not allow any subset of users to reveal a joint function of their data to an external
entity without coordination from all other users, and moreover relies on strong “knowledge
type” assumptions. Another closely related notion to ours is that of decentralized multi-client
FE, recently introduced by Chotard et al. [27]. While this work shares some of the high
level motivation of the present work, the two primitives are very different. Please see Section
1.3.3 for a comparison.

1.1 Our Notion: Ad Hoc MIFE
To address the above limitations, we introduce a new notion of ad hoc MIFE. In ad hoc MIFE,
each source (aka. sender or user) will run a local setup procedure to generate some public
parameters as well as a private encryption key. (One can also consider a public-key setting,
but this puts limits on achievable security and we do not do so in this work.1) Each source
publishes their public parameters and encrypts using their private key. These ciphertexts can
be sent to an aggregator (aka. decryptor). Furthermore, using their private keys, sources can
issue “partial decryption keys” to an aggregator. Each partial decryption key is associated
with an `-ary function f for some ` and is generated using the public keys of ` − 1 other
(dynamically chosen) sources. If these other ` − 1 sources also issue “matching” partial
decryption keys for f to this aggregator, it can decrypt any ` ciphertexts c1, . . . , c`, each
produced by the corresponding source, to f(m1, . . . ,m`) where m1, . . . ,m` are the plaintexts.
One can also consider restricted versions of the above notion, that bound the number of
users or fix ` (or both). In particular, taking the number of users equal to ` gives a version
of MIFE that still drops the global setup procedure but lacks the dynamic aspect. Finally,
we also consider the restricted notion of bounded ad hoc MIFE, where we place a bound on
the number of “partial decryption keys” a user is allowed to issue. Intuitively, for security,
we require that an aggregator learns only the functions of the data for which it has been
given all of the matching partial decryption keys.

Note that while we assume each source can obtain the authentic public parameters of
other sources with whom it wants to allow joint functions of the data to be computed, there
is no other prior coordination between users (this is one of the main advantages of our notion
over [27]). In particular, there is no external entity that generates public parameters or keys.
In some of our constructions, we work in the common reference string (CRS) model, but
note that this is still much weaker than having an authority who can decrypt all the data.

1.2 Our Results
Our results may be summarized as follows:

Feasibility result for general functions: First, we show that standard MIFE for general
functions can be bootstrapped to ad hoc MIFE for general functions for free. More
specifically, we show that ad hoc MIFE for any functionality is implied by standard MIFE
for that functionality combined in a novel way with general FE and a special type of
two-round secure multiparty computation (MPC) protocol. The latter two are implied by
standard MIFE for general functions.

1 In more detail, in the public-key setting a decryptor could launch an attack where it replaces one user’s
input with various values to determine information about the input of another user.

ITCS 2020



40:4 Ad Hoc Multi-Input Functional Encryption

Table 1 Our new constructions of ad hoc MIFE.

Functionality Assumptions Security CRS? Section

General std. MIFE Semi-honest No 4

General std. MIFE Malicious Yes 4

Inner Product LWE Semi-honest Yes 5

Inner Product LWE Malicious Yes 5

Inner Product (Bounded) DDH, LWE, DCR Semi-honest No 5

Inner Product (Bounded) DDH, LWE, DCR Malicious Yes 5

While very general, the result leaves open the goal of obtaining ad hoc MIFE under
standard assumptions. In general, this is challenging as standard MIFE is already known
to be equivalent to indistinguishability obfuscation [33, 8, 17], which is a central open
problem in cryptography. In fact, some negative evidence about the hardness of obtaining
such constructions has also been provided [37, 38]. Thus, with the goal of moving towards
using standard assumptions, we consider the task of ad hoc MIFE for special but natural
functionalities.

Constructions for Inner Products from Standard Assumptions: We provide a construction
of ad hoc MIFE for the inner product functionality from standard assumptions, namely
LWE.2 Introduced by Abdalla et al. [1] in the single-input setting, this functionality has
applications in data mining and information retrieval. Our result is obtained via a general
paradigm for constructing ad-hoc MIFE schemes from standard MIFE schemes satisfying
certain natural properties; or, what we call “ad hoc friendly” standard MIFE schemes.
We show that certain constructions of standard MIFE scheme for inner products from
the literature [3, 2] based on standard assumptions (DDH, LWE, or DCR) already satisfy
these properties. Additionally, we use a specific two-round MPC protocol [57] that can
also be obtained via LWE. We note that by using a two-round MPC protocol from any
two-round OT protocol [41, 42, 15] here, we also obtain results for the case of bounded ad
hoc MIFE for inner products – namely, we get bounded ad hoc MIFE for inner products
from DDH, LWE and DCR as well.3 We remark that since our general construction (first
result) already relies on general MIFE for circuits, there is no advantage to mitigating
assumptions for the two-round MPC protocol in that setting.

We emphasize that our transformation is general. Thus, our transformation can be used
to upgrade the security of any “ad hoc friendly” standard MIFE for a given functionality
to ad hoc MIFE for the same functionality. This result might also be useful in obtaining
future constructions of ad hoc MIFE. Furthermore, the modularity of this approach allows
for simplifications in our constructions.

We tabulate our results in Table 1 and provide explanation of which MPC protocol is needed
for each of the results in Section 1.3.

2 We stress that this functionality outputs inner products in the clear and is therefore a different type of
functionality than that of Katz et al. in [54], which tests if an inner product is zero or not.

3 Note that semi-honest constructions of two-round OT are known under each of these assumptions.



S. Agrawal, M. Clear, O. Frieder, S. Garg, A. O’Neill, and J. Thaler 40:5

1.3 Technical Overview

In this section, we describe at a high level the challenges involved in constructing ad hoc
MIFE and our techniques for overcoming them.

1.3.1 Ad Hoc MIFE for Arbitrary Functions.

Standard MIFE and ad hoc MIFE can be seen as secure multiparty computation (MPC)
protocols with a particular allowable interaction pattern and certain additional reuse cap-
abilities.4 To begin, let us consider the interaction pattern followed by standard MIFE.
In standard MIFE, there is a trusted global setup which receives as input the number of
parties `, and outputs a public key and a set of ` encryption keys. Additionally, global setup
on input a function f generates the decryption key DKf . Of these, the public parameters
are broadcast to all users and encryption key EKi is provided to encryptor i, for i ∈ [`].
The encryptors then compute their ciphertexts CT(mi) and send these to the aggregator
who may now compute the function output f(m1 . . . ,m`) using the decryption/function key
DKf . Finally, the system supports arbitrary number of decryption keys and ciphertexts. As
explained in Section 1.1, in ad hoc MIFE, we seek to eliminate the trusted global procedure
as well as support dynamic choice of parties involved in any function computation.

1.3.1.1 Challenges Involved

An approach to eliminating the trusted setup from standard MIFE is to use MPC to
replace the global setup. However, naively computing the setup procedure using MPC
would introduce interaction between the parties, which the syntax of MIFE does not allow.
Moreover, this (interactive) procedure would need to be rerun each time a function key is
required to be generated. Using two round MPC, one may hope to overcome the barrier of
interaction using the following natural idea: let parties perform a two-round MPC to perform
the setup and key generation for a standard MIFE. In more detail, parties in the first round
could publish as their public parameters the first round MPC messages with their secret
randomness as input. Given the first round messages, parties could send the second round
MPC message to the aggregator, who could use it to compute the function key. However,
this approach does not suffice since:
1. MIFE requires that the public parameters be published only once whereas the above

template requires publishing fresh public parameters for each function key.
2. Even more fundamentally, the above approach precludes users from being able to encrypt,

as their encryption keys are not available given just the first round MPC message.
In particular, the above approach does not decouple ciphertexts and functions as in traditional
MIFE, which leads to the limitation that an evaluator cannot evaluate the same function on
multiple inputs chosen by the parties, nor evaluate other functions on the same set of inputs.
Additionally, the problem is made challenging by the fact that in MIFE an aggregator might
obtain arbitrary number of secret keys and an encryptor might generate arbitrary number of
ciphertexts.

4 Recall that MPC allows a set of parties to compute a joint function of their inputs without revealing
anything else but in general allows these parties to freely interact (although restrictions may apply in
special cases).

ITCS 2020



40:6 Ad Hoc Multi-Input Functional Encryption

1.3.1.2 Overcoming the first barrier: Function re-runnable two-round MPC

In order to mitigate the first problem above, we require that the first round MPC message
be sent only once, and reused for all subsequent second round messages thus providing
re-usability/re-runnability for secret key generation. Towards achieving this re-usability, an
idea is to use function rerunnable two-round MPC protocols, where the same first round
message can be reused for multiple functions in the second round. As we will see, certain
existing two-round MPC protocols satisfy this requirement (see later), but this still does not
solve the problem. This is because in adhoc MIFE, we additionally need that for the MPC
protocol, the function or even its arity are not known at the time the first round message
is sent. We overcome this hurdle by using “function delayed” protocols, which permit the
choice of function to be delayed to the second round of the protocol. Together, these special
protocols may be used to overcome the first barrier outlined above.

1.3.1.3 Overcoming the second barrier: Delaying Encryption

In order to overcome the second barrier, we allow the encryptor to delay the encryption
process until the encryption keys are known (in similar spirit as [13, 30]). In more detail,
we will have each source independently run the setup algorithm of a single input FE scheme,
denoted as FE and compute the first round message of an MPC protocol using the FE master
key as input. This message is published as part of the public key and made available to all
other sources. Additionally, each source provides an encryption of its input mi using the
algorithm FE.Encrypt.

The sources may choose the function f to be computed and the group that will participate
in the computation dynamically. At this point, each source independently executes the
partial key generation algorithm as follows: it generates the second round message of an MPC
protocol for a suitable f dependent functionality GenKeysf and sends this to the aggregator.
Intuitively, the functionality GenKeysf has the circuit f hard-coded in it, and enables the
aggregator to compute the output.

However, recall that the inputs to the GenKeys functionality are not the messages on which
the computation must be performed, but rather the FE master keys generated independently
by each player. To proceed, the functionality instead uses the FE master keys to compute
FE function keys for a re-encryption procedure, which translates FE ciphertexts to MIFE
ciphertexts for a freshly generated (standard) MIFE scheme. During this time, the arity of
the function f is known, so a suitable standard MIFE scheme may be instantiated. It further
outputs an MIFE function key for the function f .

We are almost done: GenKeysf runs the setup procedure for a suitable fixed arity standard
MIFE scheme, computes FE function keys for each party for the re-encryption functionality,
computes the MIFE function key for f and outputs these. The aggregator uses the FE keys
together with the FE ciphertexts provided by each encryptor to translate FE.Enc(mi) to
ci = MIFE.Enc(mi) and then runs the MIFE decryption procedure to obtain f(m1, . . . ,m`).

Put together, we resolved all difficulties by carefully nesting a a multi-input FE scheme
MIFE, within the single input FE scheme FE, which in turn is nested within a re-runnable
two-round MPC protocol MPC.

One final problem remains: the adversary could get some partial information from an
“incomplete” set of partial decryption keys for some function. This is because standard MPC
makes no guarantee when an honest party does not send their final message. We solve this
problem by masking the output of MPC by pseudorandom values generated for each party.
The partial decryption keys contains the respective user’s pseudorandom masks so that only
a complete set of user keys can be used to unmask the output.



S. Agrawal, M. Clear, O. Frieder, S. Garg, A. O’Neill, and J. Thaler 40:7

While security appears to follow intuitively from the security of MPC, FE and MIFE, the
proof must contend with several technical hurdles as we are forced to deal with indistin-
guishability style security of FE, MIFE (simulation security for these primitives is known
to be impossible [20, 6]). We argue security via a careful sequence of hybrids, please see
Section 4 for details.

1.3.1.4 Instantiating MPC

We now discuss possible instantiations of MPC to fit the above template. Depending on the
properties of the underlying two-round MPC protocol, we obtain different properties of the
resulting ad hoc MIFE scheme. In both the semi-honest (passive decryptor) and the malicious
(active decryptor) settings, the most general function-rerunnable, two-round MPC protocols
without CRS can be constructed [32, 48] from indistinguishability obfuscation [33], which
itself can be constructed from multi-input functional encryption [8]. Furthermore, as already
noted in [40], we remark that in the semi-honest setting the construction of [32] can actually
be instantiated in the plain model. This is based on the observation that the CRS in the
protocol of [32] was only needed for the computation in the second round. Thus semi-honest
parties could obtain a CRS by just performing a one-round coin flipping in the first round.
This yields our first result: we get ad hoc MIFE for general functions from standard MIFE for
general functions. In the semi-honest setting, the ad hoc MIFE construction is in the plain
model. On the other hand, in the malicious setting, these protocols work in the common
reference string (CRS) model.

Alternatively, function-rerunnable two-round MPC in the common reference string (CRS)
model can be constructed [28, 57, 24, 59] from learning-with-errors (LWE). This yields ad hoc
MIFE from LWE and standard MIFE in the CRS model (either semi-honest or malicious).
While bounded two-round MPC in the CRS model can be constructed from bilinear maps [41]
and even two-round oblivious transfer [15, 42, 39] or information theoretically [9, 36], these
constructions are not function-rerunnable so do not suffice for our general construction. We
note that these constructions would suffice for obtaining bounded ad hoc MIFE, where a
user issues only a bounded number of partial decryption keys and maintains state across key
issues. However, since in our general result we anyway require the minimum assumption of
FE/MIFE, instantiating MPC from weaker assumptions does not yield any benefits, and we
do not discuss this further. Our results are highlighted in Table 1.

1.3.2 Ad Hoc MIFE for Inner Products.
While our construction of ad hoc MIFE above applies to arbitrary functionalities, it requires
use of standard MIFE for general functions. Unfortunately, as noted above, standard
MIFE implies indistinguishability obfuscation. Hence, there is limited hope of basing it
on standard assumptions. Additionally, our general transformation uses an FE scheme
for a potentially complicated re-encryption functionality and also requires general-purpose,
function-rerunnable two-round MPC for computing a complex functionality. These aspects
limit the practical applicability of our general result.

Next, we describe a paradigm for constructing ad-hoc MIFE schemes from standard MIFE
schemes that are “ad hoc friendly” and a (hopefully simple) two-round MPC protocol. This
paradigm significantly simplifies our general construction and provides a way for basing it on
standard assumptions. We then show that the standard MIFE scheme for inner products
[3, 2], which may be based on DDH, LWE or DCR, is ad hoc friendly and the corresponding
two-round MPC protocol is only required to compute inner-products, thus obtaining an
efficient ad hoc MIFE scheme for inner products.

ITCS 2020



40:8 Ad Hoc Multi-Input Functional Encryption

More formally, in the inner product functionality a decryption key corresponds to a
concatenated vector y = (y1 ‖ · · · ‖ yn) where yi ∈ Zmq , and a ciphertext encrypts a vector
xi ∈ Zmq . The desired result of decryption is

∑n
i=1〈xi,yi〉. Importantly, the decryptor should

not learn the partial sums 〈xi,yi〉. The inner product functionality has applications in data
mining and information retrieval [1, 3]. We use constructions of standard MIFE for inner
product by [3, 2].

Below, we start by summarizing our notion of “ad hoc freindliness,” which (as we see
later) is indeed satisfied by the above mentioned standard MIFE for inner product by [3, 2].
Our notion of ad hoc friendliness may be summarized as follows:
1. Decentralized Setup. The MIFE.Setup algorithm of the MIFE is decentralized in the sense

that:
a. The encryption keys EKi for i ∈ [n] corresponding to party i may be generated

independently of the encryption keys of the remaining parties [n] \ i.
b. The master secret key MSK can be decomposed into n components {MSKi}i∈[n]. The

partial MSKi corresponding to party i may be generated locally by party i, without
any interaction or shared state with the remaining parties.

2. Local Encryption. The encryption algorithm only takes its encryption key and message
as input and does not depend on the number of parties or their public parameters.

3. Piecewise Master Secret Key. The master secret in standard MIFE
MSK = {MSK1, . . . ,MSKn}, if restricted to some subset S ⊆ [n] with |S| = `, has the
same distribution as a master secret generated for functions of arity `.

We show that a standard MIFE with the above properties can be upgraded to ad hoc
MIFE described above in a more direct manner than our generic transformation from standard
MIFE to ad hoc MIFE. To see this, recall that one of the key challenges in ad hoc MIFE
is that the encryptor must encrypt her messages without knowing the encryption key for
the underlying standard MIFE. This is because the members or size of the group that will
participate in the computation are chosen dynamically later.

To handle this, we used single input FE to encrypt messages and the MPC protocol for
functionality GenKeys to sample an MIFE scheme and then translate the FE ciphertexts to
MIFE ciphertexts. In the current setting however, due to properties (1) and (2) above, the
encryption key of each party can be generated locally and each party can directly perform
MIFE encryption locally. Since the re-encryption functionality involves computing a PRF
and computing an MIFE encryption, the savings accrued by skipping this step are significant.

We will still require MPC to compute the MIFE function key, but no longer need the MPC
functionality to sample the master secret key, so for simple functionalities this protocol may
be much leaner than our general MPC protocol. For instance, in the case of inner products,
we show that the required MPC protocol only needs to support inner product computations.

While the structural requirements described above may seem very strong, as mentioned
earlier, we show that these requirements are enjoyed by the MIFE for inner products recently
constructed by Abdalla et al. [2] and can be used to instantiate our compiler providing a
very simple and efficient ad hoc MIFE for inner products. Please see Section 5 for details.

1.3.2.1 Instantiating MPC

As discussed for the case of our generic construction, we use two-round MPC protocols to
obtain ad hoc MIFE for inner products. Specifically, since function-rerunnable two-round
MPC in the common reference string (CRS) model can be constructed [28, 57, 24, 59] from
learning-with-errors (LWE), we immediately get ad hoc MIFE from LWE. This result can



S. Agrawal, M. Clear, O. Frieder, S. Garg, A. O’Neill, and J. Thaler 40:9

be upgraded to the malicious setting at the additional cost of NIZKs. On the other hand,
construction of two-round MPC from two-round oblivious transfer [15, 42, 39], yields bounded
ad hoc MIFE for inner products under DDH, LWE or DCR, albeit with the requirement that
the sources maintain state across key issues. One nice feature of these schemes is that they
work without the need for a CRS in the semi-honest setting and upgrade to the malicious
setting can be made just using CRS. Please see Section 5 for details.

Our results are highlighted in Table 1.

1.3.3 Related Work
In this section, we discuss the prior work in this area. Here, we focus on two related primitives,
decentralized multi-client FE and and non-interactive MPC. Further related work on FE,
MIFE, MPC and multi-authority FE can be found in Appendix A.

1.3.3.1 Decentralized Multi-Client Functional Encryption

Very recently, Chotard et al [27] proposed the notion of decentralized multi-client functional
encryption (D-MCFE). While the motivation for the two works is similar in removing the
common key authority, our notion of adhoc MIFE is significantly more general in that:
1. MCFE itself is more restricted than MIFE, since only CTs with the same labels can be

combined. In MIFE there is no such restriction. MIFE for circuits captures MCFE for
circuits (by checking for equal labels within the MIFE functionality) but not vice versa.

2. Crucially, the setup algorithm in D-MCFE is a protocol that is run between multiple
senders, requiring interaction, whereas our setup algorithm is run independently by each
source and is thus non-interactive. Note that developing a non-interactive solution is one
of the main motivations of this work.

3. The work of Chotard et al [27] only provides a construction for inner products. We
provide a general construction as well as one for inner products. Since our model is
stronger, our inner product construction is significantly more involved than theirs.

4. Decentralized MCFE lacks the dynamic aspect, which is one of the main contributions of
our work. We permit the function arity and participating parties to be chosen dynamically
– a feature no other construction supports (to the best of our knowledge).

Non-Interactive MPC

Another related notion is that of non-interactive MPC (NI-MPC), where a group of asyn-
chronous parties may evaluate a function over their inputs by sending a single message to
an evaluator who computes the output [51]. While they appear superficially similar, we
note that the model of ad hoc MIFE is fundamentally different from NI-MPC since, unlike
NI-MPC, it separates inputs and functions, i.e. provides ciphertexts and function keys which
allows reusing an input/ciphertext with many different functions, and a function with many
different inputs. On the other hand, NI-MPC does not support function reusability at all,
and only a very restricted version of input re-usability, namely where only ciphertexts in the
same “session” may be combined. The function arity in NI-MPC is also fixed, unlike ad hoc
MIFE.

2 Preliminaries

Due to space constraints, the preliminaries can be found in Appendix B.

ITCS 2020



40:10 Ad Hoc Multi-Input Functional Encryption

3 Ad hoc Multi-Input Functional Encryption

We are now ready to define our new notion of ad hoc multi-input func";"""date"",""2019-12-06T09:56:04Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""Ad Hoc Multi-Input Functional Encryption""
""xmp:CreatorTool"",""LaTeX with lipics-v2019.cls and hyperref.sty""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""LIPIcs, Vol.151, ITCS 2020; Copyright (C) Shweta Agrawal, Michael Clear, Ophir Frieder, Sanjam Garg, Adam O'Neill, and Justin Thaler; licensed under Creative Commons License CC-BY""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with lipics-v2019.cls and hyperref.sty""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""Ad Hoc Multi-Input Functional Encryption""
""modified"",""2019-12-06T09:56:04Z""
""cp:subject"",""LIPIcs, Vol.151, ITCS 2020; Copyright (C) Shweta Agrawal, Michael Clear, Ophir Frieder, Sanjam Garg, Adam O'Neill, and Justin Thaler; licensed under Creative Commons License CC-BY""
""pdf:docinfo:subject"",""LIPIcs, Vol.151, ITCS 2020; Copyright (C) Shweta Agrawal, Michael Clear, Ophir Frieder, Sanjam Garg, Adam O'Neill, and Justin Thaler; licensed under Creative Commons License CC-BY""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""Shweta Agrawal, Michael Clear, Ophir Frieder, Sanjam Garg, Adam O'Neill, Justin Thaler""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.20 (TeX Live 2019) kpathsea version 6.3.1""
""meta:author"",""Shweta Agrawal, Michael Clear, Ophir Frieder, Sanjam Garg, Adam O'Neill, Justin Thaler""
""trapped"",""False""
""meta:creation-date"",""2019-12-06T09:56:04Z""
""created"",""2019-12-06T09:56:04Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-12-06T09:56:04Z""
""resourceName"",""LIPIcs-ITCS-2020-40.pdf""
""Author"",""Shweta Agrawal, Michael Clear, Ophir Frieder, Sanjam Garg, Adam O'Neill, Justin Thaler""
""producer"",""pdfTeX-1.40.20""
""pdf:docinfo:producer"",""pdfTeX-1.40.20""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""10"",""0"",""4"",""1"",""0"",""9"",""0"",""31"",""16"",""2"",""21"",""28"",""10"",""8"",""20"",""21"",""12"",""0"",""0"",""0"",""0"",""0"",""12"",""13"",""7"",""14"",""22"",""28"",""9"",""33"",""47"",""49"",""45"",""48"",""34"",""48"",""52"",""11"",""7""
""Keywords"",""Multi-Input Functional Encryption""
""access_permission:modify_annotations"",""true""
""dc:creator"",""Shweta Agrawal, Michael Clear, Ophir Frieder, Sanjam Garg, Adam O'Neill, Justin Thaler""
""dcterms:created"",""2019-12-06T09:56:04Z""
""Last-Modified"",""2019-12-06T09:56:04Z""
""dcterms:modified"",""2019-12-06T09:56:04Z""
""title"",""Ad Hoc Multi-Input Functional Encryption""
""Last-Save-Date"",""2019-12-06T09:56:04Z""
""pdf:docinfo:keywords"",""Multi-Input Functional Encryption""
""pdf:docinfo:modified"",""2019-12-06T09:56:04Z""
""meta:save-date"",""2019-12-06T09:56:04Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.20 (TeX Live 2019) kpathsea version 6.3.1""
""Content-Length"",""865178""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Shweta Agrawal, Michael Clear, Ophir Frieder, Sanjam Garg, Adam O'Neill, Justin Thaler""
""dc:subject"",""Multi-Input Functional Encryption""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""41""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""2790"",""3101"",""3184"",""2539"",""2785"",""3298"",""3264"",""3125"",""2707"",""2330"",""1820"",""1653"",""1977"",""1529"",""2251"",""1763"",""1958"",""2350"",""3004"",""3616"",""3545"",""3360"",""3152"",""2806"",""2476"",""2202"",""1830"",""1470"",""2068"",""1814"",""1968"",""2198"",""2294"",""2245"",""2026"",""2373"",""3178"",""2069"",""2035"",""2742"",""2469""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""Multi-Input Functional Encryption""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-12-06T09:56:04Z""
";https://scholar.google.ch/scholar?start=910&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098809-205;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Non-interactive cryptographic timestamping based on verifiable delay functions;E Landerreche, M Stevens, C Schaffner ; International Conference on …, 2020  Springer;;"… Our timestamps are based on random-oracle sequences, originally presented in [7]. In contrast

with that work, our sequences are generated by two distinct random oracles, \(\mathsf {H … functions,

each block containing a hash of the previous block, similar to a blockchain …";Cité 6 fois;Les 5 versions;[PDF] iacr.org;https://eprint.iacr.org/2019/197.pdf;"
Non-interactive Cryptographic Timestamping
based on Verifiable Delay Functions

Esteban Landerreche1, Marc Stevens1, and Christian Schaffner2

1 CWI Amsterdam
2 University of Amsterdam & QuSoft

esteban@cwi.nl

Abstract. We present the first treatment of non-interactive publicly-verifiable timestamping
schemes in the Universal Composability framework. Similar to a simple construction by
Mahmoody et al., we use non-parallelizable computational work that relates to elapsed time
to avoid previous impossibility results on non-interactive timestamping. We extend these
ideas to the UC-framework and show how to model verifiable delay functions (VDF) related
to a global clock, and non-interactive timestamping, in the UC-framework. Furthermore,
we present new constructions that are substantial improvements over Mahmoody et al.’s
construction, such that any forged timestamps by the adversary are now limited to within a
certain time-window that depends only on its ratio to compute VDFs more quickly and the
time-window of corruption. Finally, we discuss natural applications for our construction in
decentralized protocols.

Keywords: non-interactive cryptographic timestamping, universal composability, verifiable
delay functions, time-lock cryptography

1 Introduction

In the digital domain, giving evidence that a certain amount of time has passed is more challenging
than in the physical world. Exploring how to reliably create digital timestamps has been an active
research area for the last thirty years. The first paper to deal with digital timestamping by Haber
and Stornetta [HS91] presented two different solutions that avoid having to fully trust a third
party to validate timestamps. Their first solution uses a hashchain: a sequence of documents linked
through a collision-resistant hash function. The second solution relies on a pseudorandom function
to choose a set of validators for a timestamp, which also allows to identify misbehaving actors.
Both solutions require interaction with distributed validators, as a different hashchain can be easily
generated by an adversarial party.

Modifications and extensions of these protocols have been proposed, most notably substituting
the individual records in a hashchain with a Merkle tree (or similar) [BHS93, BLS00]. These
timestamping systems require many parties to maintain records and their timestamps, as well as
the availability to answer validation queries. Other protocols require less space but stronger trust
assumptions on the set of validators [BDM93].

While timestamping evokes the idea of fixing an event in a specific point in clocktime, in practice
most timestamping schemes are relative; they provide only an ordering. A significant limitation of
such ordering systems is that it is impossible to directly compare the timestamps to events outside
the protocol. Clock-based timestamping generally requires stronger trust assumptions, as the notion
of clocktime in a computational setting is problematic.

One of the goals of this paper is to provide the first treatment of non-interactive timestamping
in the universal composability framework. In the classical literature, almost every timestamping
service requires interaction with a group of validators and provides security guarantees only for
relative timestamping. Non-interactive timestamping has been explored before in [MSTS04], where
the authors present a generic impossibility result, as an adversarial prover would simply need to
simulate the execution of an honest prover to generate a fake timestamp. They sidestep this result
by working in the bounded-storage model where they construct a secure protocol. Another approach
to sidestep this result is to relate computational work to elapsed time.



For instance, there are constructions that use the Bitcoin blockchain [Nak08] for timestamping
in the absolute sense and not only relatively [CE12] 3. Haber and Stornetta’s hashchain protocol
served as a fundamental building block for the Bitcoin blockchain. Nakamoto’s blockchain consists
of a hashchain where new elements of the chain, or blocks, are added if and only if they are solutions
to a cryptographic puzzle known as a Proof-of-Work (PoW). The work required to create a new
block ensures that the blockchain cannot be easily rewritten, especially for block created a long
time ago [GKL15]. The protocol is tuned to create a block every ten minutes in average, meaning
that one can roughly associate each block to a ten minute slot. There are other constructions that
utilize the blockchain to provide timestamping [GMG15, SV17], which simply treat it as a trusted
party and do not formally prove security.

Constructions that use PoW-based blockchain’s computational work to encode time are interest-
ing for timestamping purposes, but these require enormous computational resources which come
with cost and sustainability concerns4. The main argument for this computational cost is its direct
relation to the blockchain’s security: an adversary must hold the majority of the computational
power to significantly rewrite the blockchain. The adversary is still computationally restricted in how
deep it can rewrite blocks in a certain amount of time, i.e. on average after time T the adversary can
only successfully rewrite blocks in the network up to T · α/1−α time deep, where α is the adversary’s
fraction of the total hashing power. Even under total adversarial control, the blockchain cannot be
arbitrarily rewritten. We are interested in replicating this resilience to adversarial corruption for
timestamps without incurring the costs and complications of proof-of-work blockchains.

Due to the above issues, we specifically study constructions that use inherently sequential or
non-parallelizable functions which have a long history in cryptography. Originally conceived for
timed-release encryption [RSW96], these functions have been used as way to achieve pseudonymous
[KMS14] or deniable authentication [Wes18] and to create non-malleable commitments [LPS17].
Lately, there has been interest in generating verifiable proofs of sequential computation to represent
time for distributed protocols. One can distinguish between two similar but slightly different types
of primitives: proof-of-sequential-work (PoSW) and verifiable delay functions (VDF).

In [MMV11], the authors present the concept of a proof of sequential work (PoSW) in order
to verify that a number of computational steps have happened since something existed. The gap
between computation and verification of PoSWs is exponential, which is fundamental for their
practical use. However, by the nature of the problems the proofs are non-unique and grow with
the length of the computation (size of the graph) in order to maintain security, even for the more
efficient follow-up [MMV13]. Another construction based on graph pebbling [CP18] links the size
of the proof only with the expected security parameter. However, for a reasonable security level,
the proofs are still very large (in the order of 200kB).

Verifiable delay functions, that are similar to PoSW but have unique proofs, such as the sloth
construction from [LW15]. Unfortunately sloth’s verification gap is linear at best. Since then,
functions having an exponential gap were first presented and characterized in [BBBF18], although
the proposals presented there were somewhat vulnerable to parallelization. Newer constructions
based on modular exponentiation [Pie18, Wes18] are more resilient to parallelization. The main
difference between the last two proposals is the proof size and the efficiency in computing a proof.
Such slow functions have been postulated before in order to generate publicly verifiable randomness
[LW15, PW16].

1.1 Our contributions

We study non-interactive cryptographic timestamping based on verifiable delay functions in the
universal-composability framework and using the random-oracle model. This is the first treatment
of non-interactive timestamping in the UC model. In contrast to interactive timestamping, the
time of proof-generation and time of proof-verification may lie far apart. Since proofs do not
magically adjust over time, it is easy to see that there is a fundamental limitation of non-interactive
timestamping that only allows relative timestamping, namely proving the record’s age at the time
of proof-generation.

3 Although with certain limitations as this is not its primary purpose http://culubas.blogspot.nl/

2011/05/timejacking-bitcoin_802.html
4 https://digiconomist.net/bitcoin-energy-consumption

2

http://culubas.blogspot.nl/2011/05/timejacking-bitcoin_802.html
http://culubas.blogspot.nl/2011/05/timejacking-bitcoin_802.html
https://digiconomist.net/bitcoin-energy-consumption


Towards our goals, we first explore the modelling of parties’ ability to compute VDFs at a
certain rate with respect to some global clock. This is non-trivial since the UC-framework is based
on a simple scheduling mechanism for all parties (machines) where only one party is active at a
time. Based on this setting we define an ideal timestamping functionality FÎąts that maintains a
timestamped record of bitstrings, which can be queried to generate a non-interactive proof for the
record’s age at the time of proof-generation. We parametrize the adversary’s power to compute VDFs
faster as a time-diluting factor Îą, and the adversary can corrupt the timestamping functionality at
any time. Our ideal functionality continues to perform its goal even after adversarial corruption,
as the adversary is only allowed to forge proofs under certain constraints. Specifically, when the
adversary corrupted the functionality time T ago, the adversary can for any record (of age TrueAge)
only craft forged timestamps of age less than ι ¡min(T,TrueAge). And in particular this implies
that it cannot create any forged timestamps with age larger than T ¡ ι, and that it cannot exploit
honest VDF computations to create forged timestamps. This is a substantially stronger security
guarantee than provided by Mahmoody et al.’s construction [MMV13], where for any record of any
age the adversary can craft forged timestamps that are at most α times older than the record’s
true age. Note that in Section 4 we provide a treatment of Mahmoody et al.’s construction in the
UC-framework for easy comparison with our work.

We then first present a simple construction to demonstrate the basic techniques, However this
construction is rather inefficient in practice as it requires individual continuous VDF computations
for each record entry. Next we present a more efficient construction that combines our first
construction with the hashchain technique in the original timestamping mechanism from [HS91].
For both constructions, the prover provides a non-interactive proof to a verifier in order to attest
the age of a bitstring. The ability to create forged proofs depends solely on the period of corruption
and the adversaries’ ability to compute VDFs in less time, which can only be achieved through
a faster VDF core, as VDFs are designed to be resistant to parallelization. We show that both
constructions securely implement the timestamping functionality in the random-oracle model and
universal-composability framework against an adversary that can compute verifiable delay functions
faster than the prover by the time-diluting factor Îą.

Finally, in Section 7, we discuss the impact and potential applications of our construction.

2 Model and Definitions

We construct our protocol in the universal-composability framework [Can18] where two PPT
algorithms Z and A interact with parties executing a protocol. We assume a hybrid model where
parties have access to a global clock, random oracles, an unforgeable signature scheme and the
FÎłVDF functionality that represents our verifiable delay function.

Time. Representing time in the UC framework is a non-trivial issue, as the framework is funda-
mentally synchronous. In general, the ordering of events is dictated by the passing of messages,
where only one machine (party) is active at a time, which does not correspond to the usual concepts
of time and concurrent computing. However, the UC framework remains sufficiently general to
represent distributed computations at any granularities (see [Can18]):

Indeed, by setting individual activations of ITMs to represent the appropriate granularity
of “atomic sequential operations”, it is possible to represent distributed computations at any
desired level of abstraction or detail - from the granularity of physical interrupts in actual
CPUs, to virtualized processes in a multi-process virtual system, to abstract processes that do
not necessarily correspond to specific physical computations.

We represent time through a global read-only functionality clock that any party can access.
When queried, this functionality outputs a (strictly monotonously increasing) time receipt of
constant length θ stating the current time. For instance, clock may increase by one for every
step of the active machine. We do not specify exactly how clock increases, but any monotously
increasing function is sufficient for our purposes as we show in the modeling of VDFs. This leaves
our model sufficiently general and allows close representations of real-world clocks and distributed
computing. As an abuse of notation, we perform operations over time receipts, where the result of
these operations is a natural number.

3



Public-key signatures. We assume a EU-CMA signature scheme with security parameter Îş. For
consistency, we represent the computations related to this scheme as interaction with a signature
oracle ÎŁ in the following way:

– Each participant has a public/secret key pair (pk, sk) known to Σ.
– On query Σ.sign(sk,msg):

A signature sig ∈ {0, 1}κ is generated and the tuple (sk,msg, sig) is saved into memory. Return
sig.

– On query Σ.verify(pk,msg, sig):
If (sk,msg, sig) is in the memory of ÎŁ and (pk, sk) is a valid keypair, return accept. Otherwise,
return reject.

We assume the probability that any PPT adversary forges a signature without knowledge of the
corresponding secret key is negligible in Îş.

3 Verifiable Delay Functions

Informally, verifiable delay functions are functions that require inherently sequential computation
and can be efficiently verified. The computation of these proofs is not inherently sequential and
should not take too long to compute compared to the function evaluation. For simplification, we
treats both outputs as one, assuming that the proof construction is effectively immediate. VDFs
have unique proofs, so we can still assert than our construction is still a function.

More formally, we consider a verifiable delay function to be a triple of algorithms (VDF.gen,
VDF.verify,VDF.extend) with security parameter ¾ and parameters g, v ∈ N as defined below.

VDF.gen(x, s) is a slow cryptographic algorithm that for an input x ∈ {0, 1}∗ and strength s ∈ N
computes an output (s, p) ∈ {0, 1}µ × N in s · g parallel time steps.

VDF.verify(x, s, p) is a fast cryptographic algorithm that for inputs x ∈ {0, 1}∗, p ∈ {0, 1}µ, and
s ∈ N outputs accept if (s, p) = VDF.gen(x, s), and reject otherwise, in at most s ¡ v time steps.

We use a canonical unambiguous encoding of integers s ∈ N as bitstrings, so (s, p) has a natural
description as a bitstring s||p ∈ {0, 1}∗.

Our construction differs from the definitions in the literature in a couple of ways. The output of
the VDF contains not only the final result of the computation but also a proof that allows for faster
verification. We treat both outputs as one, which we can do as VDFs have unique proofs. This
point of view assumes that computation of these proofs is effectively immediate. This approach
is also outlined in [Wes18], which states that the computation of the proof can be considered as
part of the overall computation, without noticeably affecting the computation time (as generally
the proof generation can be parallelized). We have taken this road, as treating the output as two
separate entities introduces uninteresting complications.

Another difference lies on what we consider an execution of the VDF. As seen in [LW15], VDFs
can be chained together for better efficiency. All constructions assume that the number of sequential
executions is a fixed parameter, which we call strength. Instead of that, we assume that the function
is iterated indefinitely until the party decides to stop it, receiving the number of iterations s in the
output.

If we consider a VDF to be the sequential composition of a function, given an output it is
possible to start executing the VDF from that output, as a continuation of the original execution.
Therefore, we assume an additional algorithm VDF.extend that allows continuing an existing VDF
output:

VDF.extend is a slow cryptographic algorithm that for inputs x ∈ {0, 1}∗, (s, p) = VDF.gen(x, s)
and s∗ ∈ N returns the output (p∗, s + s∗), where (p∗, s + s∗) = VDF.gen(x, s + s∗), in s∗ · g
parallel time steps.

We use this mechanism to model the capability of running VDFs a variable number of iterations
that is decided a posteriori.

Moreover, we use the ability to ‘extend’ VDF outputs to capture the adversaries capability
to query the running VDF computations of any just-corrupted party and then continue VDF

4



computations with its own faster VDF-rate. Note that if we do not assume that proof computation
is immediate, extending a VDF through this mechanism would require wasting time computing the
proof more than once. We use this algorithm to allow the adversary to act in a realistic manner
within the UC framework, honest parties have no need for it. Because our assumption benefits only
the adversary in this case, the security oproperties are not affected by allowing VDF extension.

We require perfect correctness: VDF.verify(x,VDF.gen(x, s)) = accept for all x ∈ {0, 1}∗ and
s ∈ N. The VDF is called sound if no efficient adversary given an input x with sufficient min-entropy
can compute values (s, p) in less than s ¡ g parallel time steps for which VDF.verify(x, s, p) = accept
with non-negligible probability. The usability of the VDF is the factor g/v by which verification is
faster than generation of the proof.

To deal with VDFs and real-world time, we consider for each party its VDF-rate Îł which
represents the largest number of iterations of the VDF that that party can compute in a time unit
given its computational resources. For our results to be meaningful, the honest prover must compute
the VDF efficiently enough such that the advantage the adversary might get, represented by Îą, is
not too large. While we cannot ensure the physical reality of this assumption, the impossibility
of parallelization greatly limits this possible advantage, in contrast to generic (parallelizable)
computation. Studies in specialized hardware for [Wes18] have already started5, rendering our
assumption even closer to reality.

3.1 Candidate constructions

A candidate construction that satisfies our notion of a VDF is the sloth construction by Lenstra
and Wesolowski [LW15] that iterates modular-square-root and (keyed)-binary-permutation func-
tions. Unfortunately, this construction only has a logarithmic usability. Wesolowski’s subsequent
construction [Wes18] is the closest to our characterization. It is especially useful as the output
consists of only two field elements. This succinctness of the proof is particularly interesting for our
work, minimizing overheads in the produced timestamps.

While our constructions use verifiable delay functions, in essence they could be substituted by
proofs of sequential work like the ones presented in [CP18, MMV13], although this would require
slightly changing our VDF, as the outputs must be treated differently due to non-uniqueness of the
proof. A more practical problem is that the security level of these constructions depend on the size
of the proof, which consists of node labels. In contrast, most VDFs allow for constant-size proofs.
Furthermore, timed-release cryptography primitives [RSW96] cannot be used for our purpose, even
if the principle is similar to the preceding functions. The reason is that timed-release cryptography
allows for a puzzle and a solution to be sampled at the same time, hence the generating party
already knows the solution and does not have to solve the puzzle.

3.2 Modelling Time and Verifiable Delay Functions

The primary goal of our construction is to generate non-interactive proofs that a certain amount
of time has passed since a message was recorded by the prover. To that end, we directly link
each party’s VDF rate to the global clock, which we have modeled as a read-only global oracle
that returns monotously increasing time receipts. Throughout our construction, we simulate the
execution of our VDF through the oracle functionality presented in Figure 1.

Our VDF is represented a random oracle VDF that cannot be directly queried by participants.
Instead, they only interact with it through a functionality FÎłVDF. The FÎłVDF oracle simulates the
execution of the VDF across the passage of time. Participants can query this functionality to start a
computation and again to output the result. Depending on the amount of time passed between these
two events and the rate Îł, participants get a proof of a certain strength. The strength represents
the number of sequential iterations that were computed. By adding the notion of rate, we can
compare the execution of the same function in different hardware and the implications this has
for the timestamping protocol. In particular, the ability of the adversary to compute VDFs more
efficiently than an honest party.

In addition, participants are able to input any string to the functionality, so if this is not the
case for the particular VDF construction then we assume that a full-domain hash is applied to any

5 https://medium.com/@chia_network/chia-vdf-competition-guide-5382e1f4bd39

5

https://medium.com/@chia_network/chia-vdf-competition-guide-5382e1f4bd39


Oracle FÎłVDF

The functionality is parametrized by a computation rate γ > 0. Let VDF : {0, 1}∗ × N→ {0, 1}µ be a
global random oracle each oracle instance has access to. The oracle also has access to the global clock
clock. Let Q := ∅ be the (initially empty) query log.

– On input (start, x):
Update Q← Q ∪ {(x, clock())}.

– On input (output, x) at time to = clock():
Let ts ← mint{(x, t) ∈ Q}, return ⊥ if there is no such ts;
Let s := (to − ts) · γ; /* the strength of the resulting proof */

Let p := VDF(x, s);
Return (s, p)

– On input (verify, x, p, s):
If VDF(x, s) = p then return accept, else return reject.

– On input (extend, x, p, s):
/* Continue computation from a given existing function output */

If VDF(x, s) 6= p return ⊥.
Else update Q← Q ∪ {(x, clock()− s/γ)}.

Fig. 1: The functionality FÎłVDF is the only way to query the random oracle VDF.

inputs. In the case of the verifier, its own VDF-rate is not important in which case we just refer to
F∗VDF.

This functionality replicates the desirable properties of a verifiable delay function. Correctness
and soundness are achieved by default. Every valid proof is accepted (VDF(x, s) = p) and an
adversary is able to guess valid proofs by performing verify queries, which it can only successfully
do with negligible probability in Âľ.

Note that these VDF oracles are only active when it responds to a query, but the returned
outputs remain solely dependent on the difference between time receipts of the start and end of the
VDF computation. This ensures that regardless of the UC-framework synchronous modeling where
only one machine is active at a time, our VDF oracle faithfully models VDF computations linked
to the passage of the clock.

Our construction of FÎłVDF is not only relevant for timestamping but something similar could be
used to represent timed-release cryptography. Our approach fulfills the expected properties of the
passage of time, effectively creating a relationship between sequential computation and clock time.
Universal composability is framework that acts in a very high level of abstraction. Our construction
allows us to use it to express timestamping and computational limitations, which the framework
was not designed to handle. This approach might be of independent interest as it allows us to talk
about physical properties of computation, as long as you accept that FÎłVDF accurately reflects the
real-world properties of a VDF.

4 A trivial timestamping scheme from VDFs

In this section we present a trivial construction based on the one found in [MMV13], using verifiable
delay functions instead of proofs of sequential work. The purpose of this construction is primarily
didactic, as it can only realize a weaker functionality FÎątriv, justifying the design choices made for
the protocol presented in Section 5. This section also allows the reader to become familiar with the
proof structures in the remainder of this paper.

The functionality models a very pessimistic view, namely that the prover is always corrupted
and it gives the adversary tremendous power, since for every stamp query, it is the adversary that
generates the claimed age a and proof string u. Nevertheless, he cannot make the functionality
accept (c, a, u) as valid, unless the claimed age a ≤ areal · α is bounded by the time-dilution factor
α multiplied by the real record’s age at the time when the proof was generated.

6



Timestamping functionality FÎątriv

The functionality is parametrized with an adversarial time-dilution factor α ≥ 1. It answers queries from
the environment Z and interacts with an adversary Aid. It maintains two internal lists:R ⊂ {0, 1}∗×R+

for (record,time)-tuples and C ⊂ {0, 1}∗ × R+ × {0, 1}∗ × {0, 1} for (record,age,proof,valid)-tuples.

– On input (record, c), c ∈ {0, 1}∗:
If Aid is not sender then send (record, c) to Aid;
If 6 ∃t : (c, t) ∈ R then set R ← R∪ (c, clock).

– Procedure checkstamp(c, a, u, v):
/* Claimed age a older than Îą times real age is not allowed. */

If {(c′, t′) ∈ R | c′ = c ∧ a ≤ (clock− t′) · α} = ∅ then v ← 0.
/* Once (in)valid is always (in)valid. */

If ∃(c, a, u, v̂) ∈ C then v ← v̂.
Let C ← C ∪ (c, a, u, v).

– On input (stamp, c), c ∈ {0, 1}∗:
/* Let the adversary produce a claimed age and proof string */

Query (c, a, u, v)← Aid(stamp, c);
Call checkstamp(c, a, u, v);
Return (c, a, u).

– On input (stamped, c, a, u, v):
/* The adversary produced a stamp for a record unasked */

Call checkstamp(c, a, u, v).
– On input (verify, c, a, u), c ∈ {0, 1}∗, a ∈ R, p ∈ {0, 1}∗:

If (c, a, u, 1) ∈ C then return accept.
Let C ← C ∪ (c, a, u, 0);
Return reject.

Fig. 2: Simple timestamping functionality

Simple VDF prover PÎłtriv

Given parameter VDF rate Îł. It answers queries
from the environment Z and interacts with its
oracle FÎłVDF:

– On input (record, c), c ∈ {0, 1}∗:
Query FÎłVDF(start, c).

– On input (stamp, c), c ∈ {0, 1}∗:
Query u← FγVDF(output, c);
If u = ⊥ then return (c, 0,⊥);
/* Here u ∈ N+ × {0, 1}µ */

Let (s, p) = u, a = s/Îł;
Return (c, a, u);

(a) Simple VDF prover

Simple VDF verifier VÎłtriv

Given parameter VDF rate Îł. It answers queries
from the environment Z and interacts with its
oracle F∗VDF:

– On input (verify, c, a, u),
c ∈ {0, 1}∗, a ∈ R+, u ∈ {0, 1}∗:
If u 6= (s, p) ∈ N+ × {0, 1}µ then

return reject;
If a 6= s/Îł then return reject;
Return F∗VDF(verify, c, s, p).

(b) Simple VDF verifier

Fig. 3: Simple timestamping prover and verifier using VDFs

7



4.1 Security proof

The ideal functionality assumes an always corrupted prover, so our real world consists of an arbitrary
PPT adversary A (instead of PÎłtriv) and the honest verifier VÎłtriv. We assume a PPT environment Z
that either interacts with the ideal world Ideal(FÎątriv,Aid) consisting of the ideal functionality and
an ideal adversary (cf. Figure 4a), or interacts with the real world Real(VÎłtriv,A) (cf. Figure 4b),
and that at the end outputs a guessing bit.

The below theorem states that we can bound the advantage of Z to distinguish between the real

world and ideal world for a certain instantiation of the ideal adversary Aid by a simulator SA,F
γ¡ι
VDF

triv ,
which has black-box access to the PPT real adversary A (and may observe its oracle calls).

Theorem 4.1. Let ¾ ∈ N+ be the security parameter. For any real-world PPT adversary A with
oracle access to Fγ¡ιVDF, there exists a black-box PPT simulator Aid such that for any PPT environment
Z there exists a negligible function negl(Âľ) such that the the probability that Z can distinguish
between the ideal world with FÎątriv and Aid and the real world with A and VÎłtriv (cf. Figure 3b,4b) is
negligible: ∣∣∣Pr[ZIdeal(Fαtriv,Aid) = 1]− Pr[ZReal(Vγtriv,A) = 1]

∣∣∣ ≤ negl(µ) .

Z FÎątriv Aid

(record, c) (record, c)

(stamp, c) (stamp, c)

(c, a, u, v)(c, a, u)

(record, c)

(stamped, c, a, u, v)

(verify, c, a, u)

accept/reject

output ∈ {0, 1} Ideal(Fιtriv,Aid)

(a) Ideal-world experiment ZIdeal(FÎątriv,Aid)

Z

A

VÎłtriv

Fγ¡ιVDF

F∗VDF

(record, c)

(stamp, c)

(c, a, u)

(start, c)

(output, c)

(c, s, p)

(verify, c, a, u)

accept/reject

(verify, c, s, p)

accept/reject

output ∈ {0, 1}
Real(VÎłtriv,A)

(b) Real-world experiment ZReal(VÎłtriv,A)

Fig. 4: Environment Z in ideal- and real-world experiment for simple timestamping

Proof. Let the ideal-world simulator Aid := SA,F
γ¡ι
VDF

triv be defined as in Figure 5. We consider all
related execution transcripts in the ideal and real world

(Πideal, Πreal)← Exec(ZIdeal(Fαtriv,S
A,Fγ¡ι

VDF
triv ),ZReal(VÎłtriv,A)),

where Z and A receive the same input and use the same random coin toss outcomes. If these
executions are identical from the viewpoint of Z, then Z will output the same bit. It follows that
to prove the theorem we only have to bound the probability that these views are not identical:∣∣∣∣Pr[ZIdeal(Fιtriv,S

A,Fγ¡ι
VDF

triv ) = 1]− Pr[ZReal(Vγtriv,A) = 1]

∣∣∣∣ ≤ Pr[ViewZ(Πideal) 6= ViewZ(Πreal)].

One can verify that in the ideal world all record and stamp queries by Z and their answers by A
are perfectly forwarded by the functionality and the simulator without changing content or timing.
Hence the only way for Z’s view to be different is when a verify query results in a different outcome
between the ideal world and real world. We now bound the probability that this event occurs.

Given some related pair (Πideal, Πreal) of execution transcripts, let
(tbad,Z, (verify, c, a, u)) ∈ Πideal ∊ Πreal be the first query for which the answer oi in the ideal
world differs from the output or 6= oi in the real world. Let qverify, and qVDF be the maximum of the

8



Simulator SA,F
γ¡ι
VDF

triv

Given any real-world PPT A, the simulator SA,F
γ¡ι
VDF

triv runs the verifier VÎłtriv, the A and their VDF
functionalities F∗VDF and Fγ·αVDF in a black box manner. It sees all VDF queries they make, but faithfully
and immediately forwards all queries and responses unmodified. The simulator acts as follows:

– On input (record, c), c ∈ {0, 1}∗:
Send (record, c) to A.

– On input (stamp, c), c ∈ {0, 1}∗:
/* Let the adversary produce a claimed age and proof string */

Query (c, a, u)← A(stamp, c);
/* Check validity of the proof */

If Vγtriv(verify, c, a, u) = accept then v ← 1 else v ← 0;
Return (c, a, u, v);

– When A outputs query (start, c) to Fγ·αVDF:
Send (record, c) to FÎątriv;

– When A receives (s, p) for query (output, c) from Fγ·αVDF:
Send (stamped, c, s/Îł, (s, p), 1) to FÎątriv;

Fig. 5: Simulator

amount of verify and VDF queries, respectively, made in Πreal or Πideal. Below we only consider
what happened up to time tbad and disregard anything afterwards.

Assume oi = accept, this is only possible if SA,F
γ¡ι
VDF

triv has output (c, a, u, 1) (as answer to a stamp
query or as a stamped query). That can only happen when VÎłtriv(verify, c, a, u) = accept and thus
that or = accept, which is a contradiction. It follows that oi = reject and or = accept and u = (s, p)
for some s and p.

Next consider the case when SA,F
γ¡ι
VDF

triv never outputted (stamped, c, a, u, 1) in Πideal. This implies
that the real adversary never received (s, p) ← Fγ·αVDF(output, c), where (s, p) = u. Note that the
value VDF(c, s) can only be directly queried through a F∗VDF(output, c) query, which thus did not
";"""date"",""2019-02-21T15:29:29Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2019-02-21T15:29:29Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017) kpathsea version 6.2.3""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2019-02-21T15:29:29Z""
""created"",""2019-02-21T15:29:29Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-02-21T15:29:29Z""
""resourceName"",""197.pdf""
""Author"",""""
""producer"",""pdfTeX-1.40.18""
""pdf:docinfo:producer"",""pdfTeX-1.40.18""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""1"",""7"",""16"",""3"",""0"",""0"",""3"",""14"",""1"",""16"",""38"",""11"",""5"",""4"",""7"",""11"",""4"",""2"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2019-02-21T15:29:29Z""
""Last-Modified"",""2019-02-21T15:29:29Z""
""dcterms:modified"",""2019-02-21T15:29:29Z""
""title"",""""
""Last-Save-Date"",""2019-02-21T15:29:29Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2019-02-21T15:29:29Z""
""meta:save-date"",""2019-02-21T15:29:29Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017) kpathsea version 6.2.3""
""Content-Length"",""556810""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""25""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""3189"",""4080"",""3953"",""3180"",""3891"",""2796"",""1588"",""2548"",""2629"",""2474"",""4096"",""1949"",""2774"",""2733"",""3331"",""2855"",""3608"",""3419"",""3108"",""2316"",""3602"",""2471"",""3402"",""3771"",""3246""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-02-21T15:29:29Z""
";https://scholar.google.ch/scholar?start=750&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098853-302;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;A secure end-to-end verifiable internet-voting system using identity-based blind signature;M Kumar, S Chand, CP Katti ; IEEE Systems Journal, 2020  ieeexplore.ieee.org;;"… the first decentralized ranked-choice e-voting system based on the smart contract on Ethereum

blockchain … query on ID and s0, and responds di to F; 4) Bling signature oracles: F queries … ? ? >

is a valid message-signature pair against ID ? ; 2) the blind signature oracle has not …";Cité 7 fois;Les 2 versions;[PDF] researchgate.net;https://www.researchgate.net/profile/Mahender-Kumar/publication/338957202_A_Secure_End-to-End_Verifiable_Internet-Voting_System_Using_Identity-Based_Blind_Signature/links/60706ba8a6fdcc5f7793734d/A-Secure-End-to-End-Verifiable-Internet-Voting-System-Using-Identity-Based-Blind-Signature.pdf;;;https://scholar.google.ch/scholar?start=850&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098826-250;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;[PDF][PDF] Computational Hardness of Optimal Fair Computation: Beyond Minicrypt;HK Maji, M Wang ; Unpublished work, 2020  cs.purdue.edu;;"… and Rudich [42] first proposed the notion of black-box separation between crypto- graphic

primitives … Malkin [19] showed that when the message complexity is small, random oracle can

be … oblivious” and showed that for this particular type of protocols, random oracles cannot yield …";Cité 1 fois;;[PDF] purdue.edu;https://www.cs.purdue.edu/homes/hmaji/papers/MajWan20a.pdf;"
Computational Hardness of Optimal Fair
Computation: Beyond Minicrypt

Hemanta K. Maji and Mingyuan Wang

Abstract. Secure multi-party computation allows mutually distrusting
parties to compute securely over their private data. However, guarantee-
ing output delivery to honest parties when the adversarial parties may
abort the protocol has been a challenging objective. As a representative
task, this work considers two-party coin-tossing protocols with guaran-
teed output delivery, a.k.a., fair coin-tossing.
In the information-theoretic plain model, one of the parties can force an
output with certainty. In the commitment-hybrid, any r-message coin-
tossing protocol is 1/

√
r-unfair, i.e., the adversary can change the honest

party’s output distribution by 1/
√
r in the statistical distance. Moran,

Naor, and Segev (TCC–2009) constructed the first 1/r-unfair protocol
in the oblivious transfer-hybrid. No further security improvement is pos-
sible because Cleve (STOC–1986) proved that 1/r-unfairness is unavoid-
able. Therefore, Moran, Naor, and Segev’s coin-tossing protocol is op-
timal. However, is secure oblivious transfer necessary for optimal fair
coin-tossing?
Maji and Wang (CRYPTO–2020) proved that any coin-tossing protocol
using one-way functions in a black-box manner is at least 1/

√
r-insecure.

That is, optimal fair coin-tossing is impossible in Minicrypt. Our work fo-
cuses on tightly characterizing the hardness of computation assumption
necessary and sufficient for optimal fair coin-tossing within Cryptoma-
nia, outside Minicrypt. Haitner, Makriyannia, Nissim, Omri, Shaltiel,
and Silbak (FOCS–2018 and TCC–2018) proved that better than 1/

√
r-

unfairness, for any constant r, implies the existence of a key-agreement
protocol.
We prove that any coin-tossing protocol using public-key encryption (or,
multi-round key agreement protocols) in a black-box manner must be
1/
√
r-unfair. Next, our work entirely characterizes the additional power

of secure function evaluation for optimal fair coin-tossing. We augment
the model with an idealized secure function evaluation of f , a.k.a., the
f -hybrid. If f is complete, that is, secure oblivious transfer computation
is possible in the f -hybrid, then optimal fair coin-tossing is also possible
in the f -hybrid. On the other hand, if f is not complete, then a coin-
tossing protocol using public-key encryption in a black-box manner in
the f -hybrid is at least 1/

√
r-unfair.

Keywords: Fair computation, Optimal fair coin-tossing, Cryptomania, Black-
box separation, Hardness of computation results, Secure function evaluation.



1 Introduction

Secure multi-party computation [69, 30] allows mutually distrusting parties to
compute securely over their private data. However, guaranteeing output delivery
to honest parties when the adversarial parties may abort during the protocol
execution has been a challenging objective. A long line of highly influential works
has undertaken the task of defining security with guaranteed output delivery
(i.e., fair computation) and fairly computing functionalities [32, 11, 33, 10, 1, 5,
37, 3, 55, 4, 2, 14]. This work considers the case when honest parties are not in
the majority. In particular, as is standard in this research, the sequel relies on
the representative task of two-party secure coin-tossing, an elegant functionality
providing uncluttered access to the primary bottlenecks of achieving security in
any specific adversarial model.

In the information-theoretic plain model, one of the parties can fix the coin-
tossing protocol’s output (using attacks in two-player zero-sum games, or games
against nature [60]). If the parties additionally have access to the commitment
functionality (a.k.a., the information-theoretic commitment-hybrid), an adver-
sary is forced to follow the protocol honestly (otherwise, the adversary risks
being identified), or abort the protocol execution prematurely. Against such ad-
versaries, referred to as fail-stop adversaries [18], there are coin-tossing proto-
cols [12, 13, 6, 17] where a fail-stop adversary can change their output distribu-
tion by at most O(1/

√
r) , where r is the round-complexity of the protocol. That

is, these protocols are O (1/
√
r)-insecure. In a ground-breaking result, Moran,

Naor, and Segev [56] constructed the first secure coin-tossing protocol in the
oblivious transfer-hybrid [61, 62, 23] that is O (1/r)-insecure. No further secu-
rity improvements are possible because Cleve [17] proved that O(1/r)-insecurity
is unavoidable; hence, the protocol by Moran, Naor, and Segev is optimal.

Incidentally, all fair computation protocols rely on the oblivious transfer func-
tionality to achieve O (1/r)-insecurity. A fundamental principle in theoretical
cryptography is to securely realize cryptographic primitives based on the mini-
mal computational hardness assumptions. Consequently, the following question
is natural.

Is oblivious transfer necessary for optimal fair computation?

Towards answering this fundamental research inquiry, recently, Maji and
Wang [54] proved that any coin-tossing protocol that uses one-way functions
in a black-box manner [42, 63, 7] must incur Ω (1/

√
r)-insecurity. This result

proves the qualitative optimality of the coin tossing protocols of [12, 13, 6, 17]
in Minicrypt [40] because the commitment functionality is securely realizable by
the black-box use of one-way functions [57, 58, 36]. Consequently, the minimal
hardness of computation assumption enabling optimal fair coin-tossing must be
outside Minicrypt.

Summary of our contributions. This work studies the insecurity of fair
coin-tossing protocols outside Minicrypt, within (various levels of) Cryptoma-
nia [40]. Our contributions are two-fold.

2



1. First, we generalize the (fully) black-box separation of Maji and Wang [54]
to prove that any coin-tossing protocol using public-key encryption in a fully
black-box manner must be Ω (1/

√
r)-insecure.

2. Finally, we prove a dichotomy for two-party secure (possibly, randomized
output) function evaluations. For any secure function evaluation functional-
ity f , either (A) optimal fair coin-tossing exists in the information-theoretic
f -hybrid, or (B) any coin-tossing protocol in the f -hybrid, even using public-
key encryption algorithms in a black-box manner, is Ω (1/

√
r)-insecure.

Our hardness of computation results hold even for a game-theoretic definition
of fairness as well (which extends to the stronger simulation-based security def-
inition). Section 1.1 summarizes our contributions.

1.1 Our Contribution

This section provides an informal summary of our results and positions our
contributions relative to the state-of-the-art. To facilitate this discussion, we need
to introduce a minimalistic definition of coin-tossing protocols. An (r,X)-coin-
tossing protocol is a two-party r-message interactive protocol where parties agree
on the final output ∈ {0, 1}, and the expected output of an honest execution of
the protocol is X. A coin-tossing protocol is Îľ-unfair if one of the parties can
change the honest party’s output distribution by ε (in the statistical distance).

Maji and Wang [54] proved that the existence of optimal coin-tossing pro-
tocols is outside Minicrypt [40], where one-way functions and other private-
key cryptographic primitives exist (for example, pseudorandom generator [41,
38, 39], pseudorandom function [28, 29], pseudorandom permutation [51], sta-
tistically binding commitment [57], statistically hiding commitment [58, 36],
zero-knowledge proof [31], and digital signature [59, 64]). Public-key crypto-
graphic primitives like public-key encryption, (multi-message) key-agreement
protocols, and secure oblivious transfer protocol are in Cryptomania [42] (out-
side Minicrypt). Although the existence of a secure oblivious transfer protocol
suffices for optimal fair coin-tossing, it was unknown whether weaker hardness of
computation assumptions (like public-key encryption and (multi-message) key-
agreement protocols [26]) suffice for optimal fair coin-tossing or not. Previously,
Haitner, Makriyannis, Nissim, Omri, Shaltiel, and Silbak [35, 34], for any con-
stant r, prove that r-message coin-tossing protocols imply key-agreement proto-
cols, if they are less than 1/

√
r-insecure.

Result I. Towards this objective, we prove the following result.

Corollary 1 (Separation from Public-key Encryption). Any (r,X)-coin-
tossing protocol that uses a public-key encryption scheme in a fully black-box
manner is Ω (X(1−X)/

√
r)-unfair.

We emphasize that X may depend on the message complexity r of the protocol,
which, in turn, depends on the security parameter. This hardness of computation
result extends to the fair computation of any multi-party functionality (possibly
with inputs) such that the output has some entropy, and honest parties are not

3



in the majority (using a standard partition argument). Intuitively, relying on
stronger hardness of computation assumptions like the existence of public-key
cryptography provides no “fairness-gains” for coin-tossing protocols than only
using one-way functions.

The heart of this result is the following relativized separation in the information-
theoretic setting (refer to Theorem 5). There exists an oracle PKEn [52] that
enables the secure public-key encryption of n-bit messages. However, we prove
that any (r,X)-coin-tossing protocol where parties have oracle access to the
PKEn oracle (with polynomial query complexity) is Ω (X(1−X)/

√
r)-unfair.

This relativized separation translates into a fully black-box separation using
by-now-standard techniques in this field [63]. Conceptually, this black-box sepa-
ration indicates that optimal fair coin-tossing requires a hardness of computation
assumption that is stronger than the existence of a secure public-key encryption
scheme.

Since public-key encryption scheme implies key agreement protocols, our re-
sults prove that optimal fair coin-tossing is black-box separated from key agree-
ment protocols as well.

Result II. Let f : X × Y → RZ be a two-party secure symmetric function
evaluation functionality, possibly with randomized output. The function takes
private inputs x and y from the parties and samples an output z ∈ Z according
to the probability distribution pf (z|x, y). The information-theoretic f -hybrid is
an information-theoretic model where parties have additional access to the (un-
fair) f -functionality.1 As an aside, we highlight that the fair f -hybrid (where
the adversary cannot block output delivery to the honest parties), for any f
where both parties influence the output, straightforwardly yields perfectly or
statistically secure fair coin-tossing protocol.2

Observe that if f is the (symmetrized) oblivious transfer functionality,3 then
the Moran, Naor, and Segev protocol [56] is an optimal fair coin-tossing protocol
in the (unfair) f -hybrid. More generally, if f is a functionality such that there is
an oblivious transfer protocol in the f -hybrid, one can emulate the Moran, Naor,
and Segev optimal coin-tossing protocol; consequently, optimal coin-tossing ex-
ists in the f -hybrid. Kilian [45] characterized all functions f such that there

1 The functionality delivers the output to the adversary first. If the adversary wants, it
can abort the protocol and block the output delivery to the honest parties. Otherwise,
if the adversary wants, it can permit the delivery of the output to the honest parties
and continue with the protocol execution.

2 Suppose f = XOR. In a fair f -hybrid, the adversary cannot block the output deliv-
ery to the honest parties. So, parties input random bits to the f -functionality and
agree on the output. This protocol has 0-insecurity. A similar protocol (using a de-
terministic extractor for independent small-bias sources) can extract the fair output
from any f where both parties have influence on the output distribution.

3 In the symmetrized oblivious transfer functionality, the sender has input (x0, x1) ∈
{0, 1}2, and the receiver has input (b, r) ∈ {0, 1}2. The symmetric oblivious transfer
functionality returns xb⊕r to both the parties. If the receiver picks r $←− {0, 1}, then
this functionality hides the receiver’s choice bit b from the sender.

4



exists a secure oblivious transfer protocol in the f -hybrid, referred to as com-
plete functions.

Our work explores whether a function f that is not complete may enhance
the security of fair coin-tossing protocols.

Corollary 2 (Dichotomy of Functions). Let f be an arbitrary 2-party sym-
metric function evaluation functionality, possibly with randomized output. Then,
exactly one of the following two statements holds.

1. For all r ∈ N and X ∈ [0, 1], there exists an optimal (r,X)-coin-tossing
protocol in the f -hybrid (a.k.a., O(1/r)-unfair protocol).

2. Any (r,X)-coin-tossing protocol that uses public-key encryption protocols in
a black-box manner in the f -hybrid is Ω (X(1−X)/

√
r)-unfair.

For example, Corollary 1 is implied by the stronger version of our result by
using a constant-valued f , a trivial function evaluation. For more details, refer
to Theorem 6. We emphasize that, in our model, parties can perform an arbitrary
number of f -invocations in parallel in every round.

Let us further elaborate on our results. Consider a function f that has a
secure protocol in the information-theoretic plain model, referred to as trivial
functions. For deterministic output, the full characterization of trivial functions
is known [48, 9, 53, 47]. For randomized output, the characterization of trivial
functions is a long-standing open problem.4 Observe that trivial functions are
definitely not complete; otherwise, a secure oblivious transfer protocol shall exist
in the information-theoretic plain model, which is impossible. For every t ∈ N,
there are functions ft such that any secure protocol for ft requires t rounds
of interactive communication in the information-theoretic plain model. For the
randomized output case, the authors know of functions such that |X| = |Y | = 2
and |Z| = (t+1) that need t-round protocols for secure computation. Compiling
out the ft-hybrid using such a t-round secure computation protocol allows only
for an Θ

(
X(1−X)/

√
rt
)
-insecurity, which yields a useless bound for t = Ω (r).

Consequently, compiling out the trivial functions is inadequate.

2

1

0

0 1 2
z0

z1

z2
z3

z4

Fig. 1. The Kushilevitz Function, where Alice holds input x ∈ {0, 1, 2} and Bob holds
input y ∈ {0, 1, 2}. For example, the output is z0 if x = 0 and y ∈ {0, 1}.

It is also well-known that functions of intermediate complexity exist [48, 9,
53, 47], which are neither complete nor trivial (for example, the Kushilevitz
4 Even for perfect security, the characterization of randomized trivial functions is open.

5



function, refer Figure 1). In fact, there are randomized functions of intermediate
complexity such that |X| = |Y | = 2 and |Z| = 3 [22]. For example,

1

54

(
(18, 18, 18) (36, 12, 6)
(21, 3, 30) (42, 2, 10)

)
.

Our result claims that even an intermediate function f is useless for optimal
fair coin-tossing; it is as useless as one-way functions or public-key encryption.
Therefore, our results’ technical approach must treat each f -hybrid invocation
as one step in the protocol. We highlight that the intermediate functions are
useful in securely realizing other non-trivial functions as well [65]. However, for
fair coin-tossing they are useless.

Before we move ahead, the authors feel that it is instructive to elaborate on
what our paper does not prove. Let f be an intermediate function, and “sh-f ”
represents the hardness of computation assumption that there exists a semi-
honest secure protocol for the function f . We do not rule out the possibility
that sh-f implies optimal coin-tossing protocols. Our result only proves that the
f -hybrid cannot help construct optimal coin-tossing protocols. The existence of
a protocol for an intermediate f may have significantly additional implicit con-
sequences, which may, in turn, imply optimal coin-tossing protocol construction.
In particular, such a result would imply the separation of sh-f and sh-OT, which
is one of the most fundamental open problems in this field.5

1.2 Prior Works

Deterministic secure function evaluation. In this paper, we focus on two-party
secure function evaluation functionalities that provide the same output to the
parties. Consider a deterministic function f : X × Y → Z. The unfair ideal
functionality implementing f takes as input x and y from two parties and delivers
the output f(x, y) to the adversary. The adversary may choose to block the
output delivery to the honest party, or permit the delivery of the output to the
honest party.

In this document, we consider security against a semi-honest information-
theoretic adversary, i.e., the adversary follows the protocol description honestly
but is curious to find additional information about the other party’s private in-
put. There are several natural characterization problems in this scenario. The
5 For an insight into some of the bottlenecks encountered for this problem, consider an
oracle that allows the computation of f using t interactive rounds. If f is a function
where both parties influence the output, then there exists a round where one party
can predict the final output with 1/t additional advantage than the other party. The
primary origin of the non-triviality is the fact that the oblivious transfer protocol
can prescribe the parties to partially run the oracle-protocol evaluating f up to this
round. This additional advantage in output prediction of one party, for example,
may be amplified into an oblivious transfer protocol using the techniques of [21].
Consequently, this problem is extremely subtle and one of the most challenging
open problems in this field.

6



functions that have perfectly secure protocols in the information-theoretic plain
model, a.k.a., the trivial functions, are identical to the set of decomposable func-
tions [48, 9]. For every t ∈ N, there are infinitely many functions that require
t-rounds for their secure evaluation. Interestingly, relaxing the security from per-
fect to statistical security, does not change this characterization [53, 47].

Next, Kilian [44] characterized all deterministic functions f that enable obliv-
ious transfer in the f -hybrid, the complete functions. Any functions that has an
“embedded OR-minor” (refer to Definition 4) is complete. Such functions, intu-
itively, are the most powerful functions that enable general secure computation
of arbitrary functionalities.

The sets of trivial and complete functions are not exhaustive (for |Z| >
3 [16, 46]). There are functions of intermediate complexity, which are neither
trivial nor complete (see, for example, Figure 1). The power of the f -hybrid, for
an intermediate f , was explored by [65] using restricted forms of protocols.

Randomized secure function evaluation. A two-party randomized function
f(x, y) : X × Y → RZ is a function that, upon receipt of the inputs x and
y, samples an output according to the distribution pf (z|x, y) over the samples
space Z. Kilian [45] characterized all complete randomized functions. Any func-
tion that has an “embedded generalized OR-minor” (refer to Definition 4) is
complete. Recently, [22] characterized functions with 2-round protocols. Beyond
these characterization, not much is known in the literature and most fundamen-
tal characterization problems in this field are essentially open. However, there is
sufficient evidence that the landscape of randomized secure function evaluation
is extremely rich and fascinating. For example, even when |X| = |Y | = 2 the
authors know of functions (with |Z| = (t+ 1)) that require t rounds of commu-
nication, for any t ∈ N. Furthermore, even for |X| = |Y | = 2 and |Z| = 3, there
are random function evaluations that are of intermediate complexity [22].

In the field of black-box separation, the seminal work of Impagliazzo and
Rudich [42] first proposed the notion of black-box separation between crypto-
graphic primitives. Since then, there has been many influential works [66, 68,
26, 25, 27, 24, 63] in this line of research. Below, we elaborate on a few works
that are most relevant to us.

Firstly, for the fair coin-tossing in the random oracle model, the work of
Dachman-Soled, Lindell, Mahmoody, and Malkin [19] showed that when the
message complexity is small, random oracle can be compiled away and hence is
useless for fair coin-tossing. In another work, Dachman-Soled, Mahmoody, and
Malkin [20] studied a restricted type of protocols that they called “function-
oblivious” and showed that for this particular type of protocols, random oracles
cannot yield optimal fair coin-tossing. Recently, Maji and Wang [54] resolved
this problem in the full generality. They showed that any r-message coin-tossing
protocol in the random oracle model must be Ω (1/

√
r)-unfair.

In a recent work of Haitner, Nissim, Omri, Shaltiel, and Silbak [35] and
Haitner, Makriyannis, and Omri [34], they proved that, for any constant r, the
existence of an r-message fair coin-tossing protocol that is more secure than
1/
√
r implies the existence of (infinitely often) key agreement protocols.

7



1.3 Technical Overview

In this section, we present a high-level overview of our proofs. We start by
recalling the proofs of Maji and Wang [54].

Proof ideas of Maji and Wang [54]. Consider an arbitrary fair coin-tossing pro-
tocol πO where Alice and Bob have black-box access to some oracle O. In their
setting, O is a random oracle. Let r and X be the message complexity and the
expected output of this protocol. They used an inductive approach to prove this
protocol is (c ·X(1−X)/

√
r)-insecure as follows (c is a universal constant).

Every possile
first messages

m1 m
`¡ ¡ ¡

(r − 1, x1)-sub-
protocol

(r − 1, x`)-sub-
protocol

Attack I

Attack II

Fig. 2. An Intuitive Illustration of the approach of Maji and Wang [54].

For every possible first message of this protocol, they consider two attacks
(refer to Figure 2). Firstly, parties can attack by immediately abort upon this
first message. Secondly, parties can defer their attack to the remaining sub-
protocol, which has only r − 1 messages. Suppose when the first message is mi,
the remaining sub-protocol has expected output xi. Additionally, the expectation
of Alice and Bob defense is ai and bi. The effectiveness of the first attack is
precisely

|xi − ai|+ |xi − bi| ,

where |xi − ai| is the change of Alice’s output if Bob aborts, and analogously,
|xi − bi| is the change of Bob’s output if Alice aborts. On the other hand, by the
inductive hypothesis, we know the effectiveness of the second attack is at least

c · xi(1− xi)/
√
r − 1.

Now, they employed the results of [43] (refer to Imported Lemma 1) and show
that the maximum of these two quantities is lower bounded by

c√
r
¡
(
xi(1− xi) + (xi − ai)2 + (xi − bi)2

)
.

8



Define potential function Φ(x, a, b) := x(1 − x) + (x − a)2 + (x − b)2. Maji
and Wang noted that if Jensen’s inequality holds, i.e.,

E
i
[Φ(xi, ai, bi)] ≥ Φ

(
E
i
[xi] ,E

i
[ai] ,E

i
[bi]

)
, (1)

then the proof is complete. This is because the overall effectiveness of the attack
is lower bounded by

E
i

[
c√
r
¡
(
xi(1− xi) + (xi − ai)2 + (xi − bi)2

)]
≥ c√

r
¡ Ό
(
E
i
[xi] ,E

i
[ai] ,E

i
[bi]

)
≥ c√

r
¡ E
i
[xi]

(
1− E

i
[xi]

)
≥ c√

r
·X(1−X).

To prove Equation 1, they noted that ÎŚ(x, a, b) could be rewritten as

Φ(x, a, b) = x+ (x− a− b)2 − 2ab.

Observe that x and (x − a − b)2 are convex functions, and hence Jensen’s in-
equality holds. The only problematic term is ab. To resolve this, they noted that
suppose we have the following guarantee.

Conditioned on the partial transcript,
Alice private view and Bob private view are (close to) independent.

Then we shall have E
i
[aibi] ≈ E

i
[ai] E

i
[bi] (refer to Claim 1).6 Consequently,

Equation 1 shall hold and the proof is done.
Note that the argument thus far is oblivious to the fact that the oracle in

use is a random oracle. For any oracle O, if we have the guarantee above, this
proof will follow.

In particular, when the oracle in use is the random oracle, Maji and Wang
observed that, standard techniques (namely, the heavy querier [8]) do ensure
that Alice private view and Bob private view are (close to) independent. This
completes their proof.

Extending to f -hybrid. When f is a complete function, one can build oblivious
protocol in the f -hybrid model and, consequently, by the MNS protocol [56],
optimal fair coin-tossing does exist in the f -hybrid model.

On the other hand, if f is not complete, Kilian [45] showed that f must satisfy
the cross product rule (refer to Definition 4). This implies that conditioned on the
partial transcript, which includes ideal calls to f , Alice and Bob private view are
(perfectly) independent (refer to Lemma 3). Therefore, the proof immediately
follows.
6 In particular, if Alice private view and Bob private view are perfectly independent,
we shall have E

i
[aibi] = E

i
[ai] E

i
[bi].

9



Extending to Public-key Encryption. Our proof for the public-key encryption
follows from the ideas of Mahmoody, Maji, and Prabhakaran [52]. Firstly, we
define a collection of oracles PKEn (refer to Section 5.1), with respect to which
public-key encryption exists. To prove that optimal fair coin-tossing protocol
does not exist, it suffices to just ensure that Alice and Bob private view are (close
to) independent. However, since with the help of PKEn oracle, Alice and Bob can
agree on a secret key such that a third party, Eve, who sees the transcript and
may ask polynomially many queries to the oracle, cannot learn any information
about the key. It is impossible to ensure the independence of the private views
by only invoking a public algorithm.

To resolve this, [52] showed that one could compile any protocol π in the
PKEn oracle to be a new protocol π′ in the PKEn oracle where parties never
query the decryption oracle (refer to Imported Theorem 1). This compiler satis-
fies that given a local view of Alice (resp., Bob) in protocol π, one could simulate
the local view of Alice (resp., Bob) in protocol π′ and vice versa. Therefore, in-
stead of considering a fair coin-tossing protocol in the PKEn oracle model, one
could consider a fair coin-tossing protocol in the PKEn oracle model where par-
ties never query the decryption oracle. And [52] showed that, when the parties
do not call the decryption oracle, there does exist a public algorithm, namely the
common information learner, who can find all the correlation between Alice and
Bob (refer to Imported Theorem 2). And conditioned on the partial transcript
with the additional information from the common information learner, Alice and
Bob private view are (close to) independent. Therefore, our proof follows.

2 Preliminaries

For a random function f : X → Y, we shall use f(x; s) for f evaluated with input
x and randomness s.

We use uppercase letters for random variables, (corresponding) lowercase
letters for their values, and calligraphic letters for sets. For a joint distribution
(A,B), A and B represent the marginal distributions, and A × B represents
the product distribution where one samples from the marginal distributions A
and B independently. For two random variables A and B distributed over a
(discrete) sample space Ω, their statistical distance is defined as SD (A,B) := 1

2 ·∑
ω∈Ω |Pr[A = w ]− Pr[B = w ]| .
For a sequence (X1, X2, . . .), we use X≤i to denote the joint distribution

(X1, X2, . . . , Xi). Similarly, for any (x1, x2, . . . ) ∈ Ω1 × Ω2 × · · ·, we define
x≤i := (x1, x2, . . . , xi) ∈ Ω1×Ω2×· · ·×Ωi. Let (M1,M2, . . . ,Mr) be a joint dis-
tribution over sample space Ω1×Ω2×· · ·×Ωr, such that for any i ∈ {1, 2, . . . , n},
Mi is a random variable over Ωi. A (real-valued) random variable Xi is said to be
M≤i measurable if there exists a deterministic function f : Ω1×· · ·×Ωi → R such
that Xi = f(M1, . . . ,Mi). A random variable τ : Ω1 × · · · × Ωr → {1, 2, . . . , r}
is called a stopping time, if the random variable 1τ≤i is M≤i measurable, where
1 is the indicator function. For a more formal treatment of probability spaces,
σ-algebras, filtrations, and martingales, refer to, for example, [67].

10



The following inequality shall be helpful for our proof.

Theorem 1 (Jensen’s inequality). If f is a multivariate convex function,
then E

[
f
(
~X
)]
≥ f

(
E
[
~X
])

, for all probability distributions ~X over the domain
of f .

In particular, f(x, y, z) = (x− y − z)2 is a tri-variate convex function where
Jensen’s inequality applys.

3 Fair Coin-tossing Protocol in the f-hybrid Model

Let f : X ×Y → Z be an arbitrary (possibly randomized) function. As standard
in the literature, we shall restrict to f such that the input domain X and Y and
the range Z are of constant size. A two-party protocol in the f -hybrid model is
defined as follows.

Definition 1 (f-hybrid Model [15, 49]). A protocol between Alice and Bob
in the f -hybrid model is identical to a protocol in the plain model except that
both parties have access to a trusted party realizing f . At any point during the
execution, the protocol specifies which party is supposed to speak.

– Alice/Bob message. If Alice is supposed to speak, she shall prepare her
next message as a deterministic function of her private randomness and the
partial transcript. If Bob is supposed to speak, his message is prepared in a
similar manner.

– Trusted party message. At some point during the execution, the protocol
might specify that the trusted party shall speak next. In this case, the protocol
shall also specify a natural number `, which indicates how many instances of
f should the trusted party compute. Alice (resp., Bob) will prepare her inputs
~x = (x1, . . . , x`) (resp., ~y = (y1, . . . , y`)) and send it privately to the trusted
party. The trusted party shall compute (f(x1, y1), . . . , f(x`, y`)) and send it
as the next message.

In this paper, we shall restrict to fail-stop adversarial behavior.

Definition 2 (Fail-stop Attacker in the f-hybrid Model). A fail-stop at-
tacker follows the protocol honestly and might prematurely abort. She might de-
cide to abort when it is her turn to speak. Furthermore, during the trusted party
message, she shall always receive the trusted party message first and, based on
this message, decide whether to abort or not. If she decides to abort, this action
prevents the other party from receiving the trusted party message.

In particular, we shall focus on fair coin-tossing protocols in the f -hybrid
model.

Definition 3 (Fair Coin-tossing in the f-hybrid Model). An (X0, r)-fair
coin-tossing in the f -hybrid model is a two-party protocol between Alice and Bob
in the f -hybrid model such that it satisfies the following.

11



– X0-Expected Output. At the end of the protocol, parties always agree on
the output ∈ {0, 1} of the protocol. The expectation of the output of an honest
execution is X0 ∈ (0, 1).

– r-Message Complexity. The total number of messages of the protocol is
(at most) r. This includes both the Alice/Bob message and the trusted party
message.

– Defense Preparation. Anytime a party speaks, she shall also prepare a
defense coin based on her private randomness and the partial transcript. Her
latest defense coin shall be her output when the other party decides to abort.
To ensure that parties always have a defense to output, they shall prepare a
defense before the protocol begins.

– Insecurity. The insecurity is defined as the maximum change a fail-stop
adversary can cause to the expectation of the other party’s output.

For any (randomized) functionality f , Kilian [45] proved that if f does not
satisfy the following cross product rule, f is complete for information-theoretic
semi-honest adversaries. That is, for any functionality g, there is a protocol in
the f -hybrid model that realizes g, which is secure against information-theoretic
semi-honest adversaries. In particular, this implies that there is a protocol in the
f -hybrid model that realizes oblivious transfer.

Definition 4 (Cross Product Rule). A (randomized) functionality f : X ×
Y → Z is said to satisfy the cross product rule if for all x0, x1";"""date"",""2020-10-09T13:01:42Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2020-10-09T13:01:42Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.20 (TeX Live 2019) kpathsea version 6.3.1""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2020-10-09T13:01:42Z""
""created"",""2020-10-09T13:01:42Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-10-09T13:01:42Z""
""resourceName"",""MajWan20a.pdf""
""Author"",""""
""producer"",""pdfTeX-1.40.20""
""pdf:docinfo:producer"",""pdfTeX-1.40.20""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""2"",""0"",""2"",""2"",""0"",""4"",""10"",""5"",""18"",""0"",""7"",""29"",""12"",""16"",""94"",""14"",""67"",""68"",""4"",""4"",""24"",""23"",""3"",""0"",""0"",""0"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2020-10-09T13:01:42Z""
""Last-Modified"",""2020-10-09T13:01:42Z""
""dcterms:modified"",""2020-10-09T13:01:42Z""
""title"",""""
""Last-Save-Date"",""2020-10-09T13:01:42Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2020-10-09T13:01:42Z""
""meta:save-date"",""2020-10-09T13:01:42Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.20 (TeX Live 2019) kpathsea version 6.3.1""
""Content-Length"",""590327""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""30""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""2224"",""2675"",""2650"",""2866"",""2114"",""2535"",""2867"",""1366"",""1683"",""2622"",""2072"",""2409"",""1731"",""1646"",""2194"",""2310"",""1751"",""1698"",""1395"",""1191"",""2148"",""2052"",""2078"",""2250"",""2157"",""2902"",""3043"",""2874"",""2939"",""980""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-10-09T13:01:42Z""
";https://scholar.google.ch/scholar?start=790&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098831-257;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Blockchain-based decentralized storage networks: A survey;NZ Benisi, M Aminian, B Javadi ; Journal of Network and Computer …, 2020  Elsevier;;"… key nor private. The traded cryptocurrency in this blockchain is also called bitcoin and

goes by the ticker “BTC” … Sia runs on its own open source blockchain and uses SiaCoin

(SC) as its native cryptocurrency. However, Sia's developers …";Cité 13 fois;Les 3 versions;null;;;;https://scholar.google.ch/scholar?start=800&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098774-121;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;MicroCash: Practical Concurrent Processing of Micropayments;G Almashaqbeh, A Bishop, J Cappos ; International Conference on …, 2020  Springer;;"… Hash functions are modeled as random oracles, and the hash values of the blocks on the

blockchain are modeled … The probability of predicting the latter is negligible (in the random oracle

model and under the assumption that block hashes on the blockchain are modeled …";Cité 3 fois;Les 6 versions;[PDF] arxiv.org;https://arxiv.org/pdf/1911.08520;"
MicroCash: Practical Concurrent Processing of
Micropayments

Ghada Almashaqbeh1?, Allison Bishop2,3??, and Justin Cappos4

1 CacheCash Development Company, NY, USA ghada@cachecash.com
2 Columbia University, NY, USA allison@cs.columbia.edu

3 Proof Trading, NY, USA
4 New York University, NY, USA jcappos@nyu.edu

Abstract. Micropayments are increasingly being adopted by a large
number of applications. However, processing micropayments individu-
ally can be expensive, with transaction fees exceeding the payment value
itself. By aggregating these small transactions into a few larger ones, and
using cryptocurrencies, today’s decentralized probabilistic micropayment
schemes can reduce these fees. Unfortunately, existing solutions force mi-
cropayments to be issued sequentially, thus to support fast issuance rates
a customer needs to create a large number of escrows, which bloats the
blockchain. Moreover, these schemes incur a large computation and band-
width overhead, which limit their applicability in large-scale systems.
In this paper, we propose MicroCash, the first decentralized probabilistic
framework that supports concurrent micropayments. MicroCash intro-
duces a novel escrow setup that enables a customer to concurrently issue
payment tickets at a fast rate using a single escrow. MicroCash is also
cost effective because it allows for ticket exchange using only one round
of communication, and it aggregates the micropayments using a lottery
protocol that requires only secure hashing. Our experiments show that
MicroCash can process thousands of tickets per second, which is around
1.7-4.2x times the rate of a state-of-the-art sequential micropayment sys-
tem. Moreover, MicroCash supports any ticket issue rate over any period
using only one escrow, while the sequential scheme would need more than
1000 escrows per second to permit high rates. This enables our system
to further reduce transaction fees and data on the blockchain by ∟ 50%.

1 Introduction

Micropayments, or payments in pennies, are increasingly being used by applica-
tions as diverse as ad-free web surfing, online gaming, and peer-assisted service
networks [33]. This paradigm allows participants to exchange monetary incen-
tives at a small scale, e.g., pay per minute in online games. Such a fine-grained
payment process has several advantages, including a great deal of flexibility for
customers who may stop a service at any time. In addition, it reduces the finan-
cial risks between mutually-distrusted participants, where there is no guarantee

? Most work done while at Columbia supported by NSF CCF-1423306.
?? Supported by NSF CCF-1423306 and NSF CNS-1552932.

ar
X

iv
:1

91
1.

08
52

0v
1 

 [
cs

.C
R

] 
 1

9 
N

ov
 2

01
9



that a client will pay after being served, or that a server will deliver service when
paid in advance.

However, processing these small payments individually can incur high trans-
action fees that exceed the few pennies received. For example, the average base
cost of a debit or credit card transaction in the US is around 21 to 24 cents,
and 23 to 42 cents [9,10], respectively. In cryptocurrencies such a fee could be
even higher, e.g., above $1 in Bitcoin [7]. Beside this financial drawback, han-
dling micropayments individually can impose a huge workload on the system,
and may explode the log needed for accountability purposes. Thus, there is a
need for a payment aggregation mechanism that records fewer transactions with
values that still compensate properly for the small payments received to date.

Probabilistic micropayment schemes have emerged as a solution that fits the
criteria outlined above [39,35,31,36]. In these models, the amount of required
payments is locked in an escrow and micropayments are issued as lottery tickets.
Each ticket has a probability p of winning a lottery, and when it wins, produces
a transaction of β currency units. This means that, on average, only one large
transaction is processed out of a batch of 1

p tickets. Unfortunately, these early
proposals rely on a trusted party to audit the lottery and manage payments.
Such a centralized approach may increase the deployment cost and limit the use
of the payment service to systems of fully authenticated participants [25].

As cryptocurrencies evolved, a number of initiatives have attempted to con-
vert these schemes to distributed ones [33,25]. This is done by replacing the
trusted party with the miners, and utilizing the blockchain to provide pub-
lic verifiability of system operation. Yet, these approaches have several draw-
backs that may hinder their usage in large-scale systems. First, they force a cus-
tomer to issue micropayments sequentially using the same escrow. This means
a new ticket cannot be issued until it is confirmed that the previous one did
not win, which requires a merchant to report the lottery outcome back to the
customer. To issue tickets at a fast rate under this structure, this customer
needs to create a large number of escrows, which increases the amount of data
on the blockchain. Second, these schemes rely on computationally-heavy cryp-
tographic primitives [33,25], and several rounds of communication to exchange
payments [25], which incur a large overhead. Such performance issues reduce the
potential benefits of micropayments.

This paper proposes a solution to these drawbacks by introducing MicroCash,
the first decentralized probabilistic framework that supports concurrent micro-
payments. MicroCash features a novel payment setup that allows a customer to
issue micropayments in parallel and at a fast rate using a single escrow that can
pay many winning tickets. This is achieved by having the customer specify the
total number of tickets it may issue, and provide an escrow balance that covers
all winning tickets under its payment setup.

MicroCash is also cost effective because it introduces a lightweight non-
interactive lottery protocol. This protocol requires only secure hashing and allows
a payment exchange using only one round of communication without demanding
the merchant to report anything to the customer. Furthermore, this protocol is

2



the first to eliminate situations where all lottery tickets may win or lose the
lottery. Although the probability of these events is very small, it may discourage
customers from using the system since such a possibility, i.e., to pay much more
than the expected payments, may impose a strong psychological obstacle [31].
Moreover, accounting for the worst case when all, or almost all, tickets win re-
quires a large escrow balance, which increases the collateral cost. Our protocol
solves this problem by selecting an exact number of winning tickets each round
(where a round is the time needed to mine a block on the blockchain). All tickets
issued in the same round are tied to a lottery draw value in a future block on
the blockchain, which is used to determine the set of winning tickets through an
iterative hashing process. The security of this protocol, and the whole system, is
enforced using both cryptographic and financial techniques. The latter requires
a customer to create a penalty escrow that is revoked upon cheating, with a
lower bound derived using a game theoretic modeling of the system.

To evaluate its efficiency, we experimentally test MicroCash’s performance
and compare it to MICROPAY [33], a state-of-the-art sequential micropayment
scheme. Our results show that a modest merchant machine in MicroCash is able
to process 2,240 - 10,500 ticket/sec, which is around 1.7-4.2x times the rate in
MICROPAY, with 60% reduction in the aggregated payment size. Furthermore,
a modest customer machine in MicroCash is able to concurrently issue more than
33,000 ticket/sec using one escrow over any period, while MICROPAY requires
the creation of more than 1000 escrows per second to support a comparable issue
rate. This allows MicroCash to reduce transaction fees and amount of data on
the blockchain in a video delivery and online gaming applications by ∟ 50%.

2 Related Work

To orient readers to the current state-of-the-art in probabilistic micropayments,
in this section we review prior work done in this area. In addition, we review an
alternative payment aggregation mechanism, called payment networks [26,34],
focusing on its limitations when used to handle micropayments.

Probabilistic Micropayments. The idea of probabilistic micropayments dates
back to the seminal works of Wheeler [39] and Rivest [35]. In these schemes, a
customer and a merchant run the lottery on each ticket by using a simple coin
tossing protocol. Thus, there is a chance than more, or less, tickets than expected
may win. All of these schemes rely on a centralized bank to track and authorize
payments. This imposes additional overhead on the users who have to establish
business relationships with this bank. Also, it limits the use of the service to
only fully authenticated users. Therefore, this centralization issue is viewed as
the main reason for the limited adoption of such solutions [25].

Systems using cryptocurrency-based probabilistic micropayments have the
potential to overcome both the cost and efficiency problems inherent in ear-
lier schemes. To the best of our knowledge, only two such schemes have been
proposed to date in the literature, MICROPAY [33] and DAM [25].

3



MICROPAY translates the scheme of Rivest [35] into an implementation on
top of a cryptocurrency system. Instead of using an authorized bank account,
customers create escrows on the blockchain that they use to issue lottery tickets.
For the lottery protocol, MICROPAY implements a similar interactive coin toss-
ing protocol, and adds an alternative non-interactive version that reduces the
communication complexity (a merchant still has to report the lottery result back
to the customer). However, the latter is computationally-heavy since it requires
public key cryptography-based operations and a non-interactive zero knowledge
(NIZK) proof system. Moreover, MICROPAY only supports sequential micro-
payments as mentioned earlier. DAM shares similar constraints, but it adds the
feature of preserving user privacy (not like MICROPAY that is public), where
it extends Zerocash [38] primitives to implement anonymous micropayments.

We believe that the added blockchain transactions due to sequential pay-
ments, coupled with the high computation cost, point to the need for optimized
approaches that support concurrent micropayments at a lower overhead. This
need is the motivation behind building MicroCash.

Payment Channels and Networks. This payment paradigm was originally
developed to handle micropayments in Bitcoin [6], where it relies on a similar
concept of processing most of the small payments locally. Later on, it was geared
to enhancing the scalability of cryptocurrencies [29,26,34,32,28,30], where utiliz-
ing off-chain processing to reduce on-chain traffic helps increase the transaction
throughput at a lower overhead.

A payment channel is a contract between a customer and a merchant tied to a
shared escrow fund. The ownership of this fund is adjusted over time based on the
off-chain transactions, or local payments, made to date. Only two transactions
are logged on the blockchain per channel, the opening transaction and the closing
one that expresses the latest state of the fund ownership.

In general, payment channels and networks suffer from the high collateral
cost of setting up multiple escrows when constructing payment paths between
transacting parties. These costs may indirectly push the network towards cen-
tralization [13]. This is because only wealthy parties can afford multiple escrows
to establish payment channels, and hence, most users will rely on these parties,
or hubs, to relay the off-chain transactions. In addition, each hub on the path
charges a fee to relay payments. With micropayments, such a setup would be
infeasible because these fees could be much larger than the payments themselves.
Probabilistic approaches, on the other hand, are more flexible in allowing sev-
eral parties to be paid using the same escrow. And by doing so, they reduce the
collateral cost and eliminate any fees when exchanging lottery tickets. Hence,
distributed probabilistic micropayments provide a better solution for handling
small payments in cryptocurrency systems.

3 Threat Model

The reliance on off-chain transactions in distributed probabilistic micropayments
creates the potential for various types of attacks. In this section, we outline a

4



threat model that accounts for these attacks, which guided the design of Micro-
Cash. In developing this model, we make the following assumptions:

– No trusted party exists.

– Participants are rational, meaning that they may follow the protocol without
violation, or deviate from it, based on what will maximize their utility gain.

– The underlying cryptocurrency scheme is secure in the sense that the major-
ity of the mining power is honest. This means that the confirmed state of the
blockchain contains only valid transactions, and that an attacker who tries
to mutate or fork the blockchain will fail with overwhelming probability.

– Hash functions are modeled as random oracles, and the hash values of the
blocks on the blockchain are modeled as a uniform distribution.

– Efficient adversaries cannot break the basic cryptographic building blocks
(SHA256, digital signatures, etc.) with non-negligible probability.

– Communication between customers and merchants takes place over a channel
that provides integrity, confidentiality, and authenticity, such as TLS/SSL.

We used ABC [22] to build a threat model for MicroCash (a detailed version
of this threat model is available online [19]). During this process, we identified the
assets to be protected in distributed probabilistic micropayments, which include
the escrows, the lottery tickets, and the lottery protocol. Then, by analyzing the
security requirements of these assets, we produced the broad threat categories
in such systems. Our list includes the following:

– Escrow overdraft: A customer creates a payment escrow insufficient for
honoring the winning lottery tickets, or creates a penalty deposit that does
not cover the cheating punishment imposed by the miners. Such a threat
could be the result of creating small balance escrows, or front running attacks
in which a customer withdraws the escrows before paying.

– Duplicate ticket issuance: A customer issues lottery tickets with the same
sequence number to several merchants. This leads to issuing more tickets
than the escrow can cover, allowing the customer to obtain more service
than it pays for.

– Invalid payments: A malicious customer hands merchants lottery tickets
that do not comply with its payment setup or with the system specifications.
Because these tickets will be rejected by the miners if they win the lottery,
the customer can avoid paying merchants.

– Unused-escrow withholding: An attacker prevents or delays a customer
from withdrawing its unused escrows. For example, merchants may delay
claiming their winning lottery tickets to keep the payment escrow on hold.

– Lottery manipulation: An attacker attempts to influence the outcome of
the lottery draw, and hence, bias the payment process.

– Denial of service (DoS): This is a large threat category that threatens
any distributed system. This work focuses on attacks related to the payment
process. For example, an attacker may monitor the network and drop all
lottery tickets to disturb the service.

5



Note that dealing with malicious merchants who collect lottery tickets and
do not deliver a service is outside the scope of MicroCash. The same is true for
dealing with malicious customers who may obtain the service without paying. In
this work, we are concerned with the payment scheme design, rather than how
to exchange service for a payment, which is part of an application design.

In addition, MicroCash does not address payment anonymity. Addressing this
issue securely, while preserving the low overhead of MicroCash, is a direction of
our future work.

4 MicroCash Design

Having outlined the security threats to probabilistic micropayments, and the
limitations of existing solutions, this section presents the design of MicroCash, a
concurrent micropayment system that addresses these issues. We start with an
overview of the system, followed by a more detailed technical description.

1
Escrow creation 

transaction

Miners

Check customer 

payment setup

2

Process all transactions, 
monitor escrows, maintain 

the blockchain

Blockchain

MerchantsCustomer Lottery tickets3

4

Claim winning 

lottery tickets 

5
Observe 

lottery draw

Fig. 1: Flow of operations in MicroCash.

A high level illustration of MicroCash, that also captures the remainder of
this section’s organization, is found in Figure 1. As shown, during the payment
setup (Step 1, Section 4.1), each customer issues a transaction creating two
escrows: payment and penalty. The customer uses the former to make payments
in the form of lottery tickets, while the miners use the latter to financially pun-
ish this customer if it cheats. Payment exchange starts as soon as the escrow
transaction is confirmed on the blockchain. At that time, merchants can check
the escrow setup before transacting with the customer (Step 2). In exchange for
the delivered service, the customer issues these merchants lottery tickets accord-
ing to a ticket issue schedule that limits the ticket issue rate over a set period
(Step 3, Section 4.2). To redeem these payments, a merchant keeps each of its
tickets until the lottery draw time of this ticket. It then observes a value derived
based on the block mined at that time to determine if this ticket won (Step 4,
Section 4.3). If it is a winning ticket, the merchant can claim currency from the
customer’s escrow during the ticket redemption period (Step 5, Section 4.4).
This interaction continues until the end of the escrow lifetime. At that time, and
when all issued tickets expire, the customer can spend any remaining funds.

6



4.1 Escrow Setup

MicroCash introduces a novel escrow setup that allows multiple winning tickets
to be redeemed, which enables both concurrent ticket issuance and reduces the
amount of on-chain escrow-related data. This setup provides techniques to de-
termine the needed escrow balance to cover all concurrent tickets, and to track
the issuance of these tickets in a distributed way.

Escrow creation. As an off-chain payment scheme, MicroCash must ensure
that customers can and will pay. This includes honoring winning tickets, and,
if caught cheating, complying with a stipulated financial punishment. To satisfy
these requirements, each customer must create payment and penalty escrows
with sufficient funds to cover both eventualities.

Given that each payment escrow must be tied to a penalty escrow, a customer
sets up both using one creation transaction. This transaction provides funds
to be locked under each escrow balance, where we refer to the payment and
penalty escrow balances as Bescrow and Bpenalty, respectively. It also configures
a set of parameters that influence how the value of both Bescrow and Bpenalty are
computed, and how they are to be spent. These parameters, whose values are
specified by the customer possibly after negotiating with the merchants, include
the following:

– The lottery winning probability p.
– The currency value of a winning lottery ticket β.
– The ticket issue rate tktrate, which is the maximum number of tickets a

customer is allowed to hand out per round. This is used to calculate which
ticket sequence numbers are valid within each ticket issuing round.

– A lottery draw round length, denoted as drawlen, such that drawlen ∈ {1, . . . , c}
for some small system parameter c. The customer has to configure drawlen,
p, and tktrate in a way that makes ptktrate drawlen of an integer value (this
is the number of winning tickets in a lottery draw).

– The set of beneficiary merchants that can be paid using the escrow, where
the size of this set is denoted as m.

Computing Bescrow and Bpenalty based on the above parameters proceeds as
follows. To permit concurrent micropayments, Bescrow must be large enough to
pay all winning tickets tied to an escrow. Given that each winning ticket has
a value of β currency units, and that there are ptktrate drawlen winning tickets
per drawlen rounds, Bescrow can be simply computed as follows (where lesc is the
escrow lifetime in rounds, and there are lesc/drawlen lottery draws):

Bescrow = βptktratelesc (1)

For Bpenalty, we compute a lower bound for this deposit using an economic
analysis that accounts for the additional utility gain a customer may obtain by
cheating. This bound is given by the following equation:

Bpenalty > (m−1)pβtktratedrawlen

(
1− p

1− ρ−1
+drawlen

(
(1−p)(ddraw−1)+dredeem

))
(2)

7



where ddraw is the lottery draw period in rounds, dredeem is the ticket redemption
period in rounds, and ρ =

(
a
b

)
such that a = tktratedrawlen and b = (1 − p)a

(more about these parameters in Section 4.3). This lower bound ensures that
the financial punishment exceeds the additional utility gain of cheating, and
hence, makes cheating unprofitable compared to acting honestly. The full details
of deriving this bound are found in Section 5.

Verifying the correctness of a payment setup is performed by the miners upon
receiving the escrow creation transaction. First, they verify that the customer
owns the input funds. Then, the miners use Bescrow to compute the escrow
lifetime as lesc = Bescrow

βptktrate
. After that, they check that both lesc and ptktrate

drawlen are of integer values, drawlen is within the allowed range, and that lesc
is multiples of drawlen. Lastly, the miners verify that Bpenalty satisfies the bound
given above. If all these checks pass, the miners add the escrow transaction to
the blockchain. Otherwise, they reject the escrow by dropping its transaction.

Escrow management. In MicroCash, the escrow funds can be spent only for a
restricted set of transactions. This set includes claiming winning tickets, present-
ing proofs-of-cheating, and (after the escrow lifetime is over) enabling a customer
to spend its unused escrow funds.

To track the locked funds, miners maintain a state for each escrow in the
system. This state includes the following:

– The ID of the escrow, which is a random value generated by the miner who
adds the escrow creation transaction to the blockchain.

– The balances of both the payment and penalty escrows.
– The public key of the owner customer, which is used to verify all signed

tickets that are issued using this escrow.
– The values of p, β, lesc, tktrate, drawlen, and the set of beneficiary merchants

(both the public key of each merchant and a corresponding index).
– An escrow refund time, denoted as trefund, at which the customer can spend

any remaining funds. Miners set this time to be equal to the expiry time of
the tickets issued in the last round of an escrow lifetime.

Ticket issuance using an escrow must follow a schedule based upon the tickets
sequence numbers. That is, if an escrow supports a rate of tktrate tickets per
round, then in the first round tickets with sequence numbers 0 to tktrate-1 may
be issued. Then, in the second round tickets with sequence number range tktrate
to 2tktrate-1 can be issued, and so on until the last round of an escrow lifetime.
Merchants will accept tickets in the current round with sequence numbers that
follow this assignment schedule. In order to deal with the fact that customers
and merchants may have inconsistent views of the blockchain, and hence, may
not agree about what the current round is (i.e., current height of the blockchain),
merchants will also accept tickets from the prior and next round given that these
tickets use the correct sequence number range.

An example of a ticket issuing schedule is found in Figure 2. As shown, the
escrow creation transaction is published at round 10 and confirmed at round 16.

8



Blockchain Block 
10

Block 
16

... Block 
17

Block 
18

Block 
19

1st issue round
issue time = 17

seqno = {0, ..., 999}

escTr Confirmed
Escrow Creation 

Transaction (escTr) 

2nd issue round
issue time = 18

seqno = {1000, ..., 1999}
3rd issue round
issue time = 19

seqno = {2000, ..., 2999}

Fig. 2: An example of a ticket issuing schedule.

This escrow has lesc = 3 rounds, and allows a ticket issue rate of 1000 tickets
per round. Thus, the customer has 3 ticket issuing rounds, starting at round 17,
with the sequence number ranges shown in the figure.

The miners update the escrow state based on the escrow related transac-
tions (mentioned earlier) they process. For example, redeeming a winning ticket
reduces Bescrow by β coins, and receiving a valid proof-of-cheating against the
customer causes the miners to burn the funds in Bpenalty. All these transactions
are logged on the blockchain, which permits anyone to validate the state.

The miners discard an escrow state once all tickets tied to this escrow expire,
which happens at time trefund, or when an escrow is broken after receiving a valid
proof-of-cheating (proof-of-cheating is discussed in Section 4.5). At that time,
the customer may spend the remaining funds of its payment escrow (if any) and
its penalty deposit (if not revoked).

4.2 Paying with Lottery Tickets

After the escrow is confirmed on the blockchain, a customer can start paying for
service by giving merchants lottery tickets. A lottery ticket tktL is a structure
containing several fields as follows:

tktL = indexM ||idesc||seqno||σC (3)

where indexM is the recipient merchant index as listed in the escrow state, idesc
is the escrow ID, seqno is the ticket sequence number, and σC is the customer’s
signature. The seqno field, along with idesc, identifies a ticket, which also pro-
vides means for ticket tracking in the system. Note there is no need to include
any information about the escrow setup or the parties’ public keys in the ticket
itself. Merchants and miners can look these up on the blockchain using idesc.

When issuing a ticket, the customer fills in the above fields and signs the ticket
using the secret key tied to the public key the customer used when creating the
escrow. The ticket seqno can be any sequence number within the range assigned
to the current ticket issue round. The customer can continue issuing lottery
tickets, without waiting the lottery results of previously issued ones, until it
finishes all sequence numbers in this range. After that, it must wait the next
round to generate more tickets.

Upon receiving a ticket, a merchant verifies it as follows:

9



Blockchain Block 40... ...Block 30Block 28 Block 29...

Fig. 3: An example of lottery draw time (drawlen = 3, p = 1/300, tktrate = 1000,
and ddraw = 10).

– Check that the escrow is not broken

– Check that its index indexM , that appears in the ticket, is identical to the
one listed in the escrow state.

– Verify that seqno is within the valid range based on the ticket issuing sched-
ule. (As mentioned before, to handle inconsistencies in the blockchain view,
tickets from the previous or next issuance round can be accepted.)

– Verify σC over the ticket using the customer’s public key.

If any of the above checks fails (except the fourth one), the merchant drops
the ticket. On the other hand, if the ticket has an out-of-range sequence number
(i.e., larger than the maximum sequence number allowed by the escrow), the
recipient merchant can issue a proof-of-cheating that will cost the customer its
penalty deposit. Otherwise, if all the above checks pass, the merchant accepts
the ticket and keeps it until its lottery draw time.

4.3 The Lottery Protocol

MicroCash introduces a lightweight lottery protocol that relies solely on secure
hashing. This protocol does not require any interaction between the customer
and the merchant. Instead, it utilizes only the state of the blockchain, where the
lottery draw outcome is determined by a value derived from the block mined at
the lottery draw time.

To specify the lottery draw time, MicroCash defines two system parameters,
ddraw and drawlen mentioned earlier. ddraw represents the least number of rounds
a ticket has to wait after its issue round (which we call tissue) until it enters the
lottery. drawlen determines the number of consecutive ticket issuing rounds that
will have all their lottery tickets enter the same lottery draw5. Hence, if drawlen

= 1, then the draw time tdraw of a ticket is computed as tdraw = tissue + ddraw.
On the other hand, if drawlen > 1, then tdraw of a ticket is tdraw of the last ticket
issuing round in the contiguous set of rounds.

A clarifying example of determining the lottery draw time is found in Fig-
ure 3. As shown, starting with the first ticket issuing round, which is 28 in the
figure, each set of contiguous drawlen rounds enter the lottery together. For ex-
ample, all tickets issued in rounds 28, 29, and 30 enter the lottery at round 40,
which is 10 rounds after the last ticket issue round in this set.

5 Since drawlen affects tdraw of a ticket, MicroCash specifies a small interval for its
possible values to prevent a customer from excessively delaying paying merchants.

10



Accordingly, whether a ticket wins or loses depends on a lottery draw value
tied to the block mined at time tdraw. This value is computed using a simple
verifiable delay function (VDF) [24] that is evaluated over this block. This eval-
uation takes a period of time, hence the name delay function, where this period
is a system parameter. Consequently, when a miner mines the block at index
tdraw, it cannot tell immediately which ticket will win or lose. This miner first
has to compute the VDF over this block.

We instantiate this VDF using iterative hashing, where the number of itera-
tions is set to a value that delays producing the output by the period specified
in the system. In addition, we let the miners compute this function as part of
the mining process. That is, when a miner mines a new block, it evaluates the
VDF over the previous block. Therefore, the VDF value of the block at index
tdraw appears on the blockchain when the block at index tdraw + 1 is mined.

Accordingly, in our protocol a merchant keeps a ticket tktL until its lottery
draw time tdraw. Then, after observing the VDF value of the block mined at that
time, the miners, and any party in the system, can compute the set of winning
sequence numbers for that round as follows. First, the hash of the VDF value
along with the escrow ID is computed, which we call h1, and then h1 is mapped
to a sequence number within the assigned range of the ticket issuing rounds tied
to tdraw. To obtain the second winning ticket sequence number, the hash of h1 is
computed to obtain h2, and then h2 is mapped to a ticket sequence number in
the given range. If a collision occurs, i.e., a previously seen sequence number is
produced, it is discarded and the process proceeds with hashing h2 to obtain h3,
and so on. This continues until a set of distinct ptktrate drawlen winning sequence
numbers is drawn6.

The previous process is clarified by the example depicted in Figure 4, which
has the same setup as in Figure 3. As shown, and assuming that round 28 is
the first ticket issuing round, the ticket has been issued at round 29, and hence,
it entered the lottery at round 40. The VDF value of the block with index 40
appears inside block 41. By using this value, a set of winning sequence numbers
is chosen, based on which the ticket in the figure is a winning one because its
sequence number is within this set.

Note that the lottery draw involves only values that are part of the escrow
state. In other words, it relies on parameters that the issuing customer cannot
manipulate, which do not include the merchant recipient address. This means
that a ticket’s chance of winning the lottery is not affected by who owns it. In
addition, this means that if a customer issues tickets with duplicated sequence
numbers to multiple merchants, all these tickets will win or lose together. If the
tickets win, detecting cheating is trivial because both merchants will publish
their winning tickets to the blockchain to redeem the tickets.

6 We design a version of this lottery protocol with independent ticket winning events
in Appendix A. This version can be used in case it is infeasible in some applications
to configure ptktrate drawlen to be an integer.

11



Block 41

tktL is a winning ticket

Blockchain Block 30 Bloc";"""date"",""2019-11-21T02:19:33Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2019-11-21T02:19:33Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016) kpathsea version 6.2.2""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2019-11-21T02:19:33Z""
""created"",""2019-11-21T02:19:33Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-11-21T02:19:33Z""
""resourceName"",""1911.08520""
""Author"",""""
""producer"",""pdfTeX-1.40.17""
""pdf:docinfo:producer"",""pdfTeX-1.40.17""
""pdf:unmappedUnicodeCharsPerPage"",""6"",""0"",""0"",""0"",""0"",""0"",""4"",""2"",""0"",""0"",""0"",""0"",""0"",""0"",""2"",""2"",""12"",""5"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""3"",""12"",""2"",""3"",""13""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2019-11-21T02:19:33Z""
""Last-Modified"",""2019-11-21T02:19:33Z""
""dcterms:modified"",""2019-11-21T02:19:33Z""
""title"",""""
""Last-Save-Date"",""2019-11-21T02:19:33Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2019-11-21T02:19:33Z""
""meta:save-date"",""2019-11-21T02:19:33Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016) kpathsea version 6.2.2""
""Content-Length"",""1452383""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""35""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""2309"",""2857"",""2674"",""2700"",""2525"",""2139"",""2332"",""2612"",""2202"",""2135"",""2642"",""1846"",""2656"",""2752"",""1552"",""2739"",""1818"",""2045"",""2681"",""2513"",""2665"",""2255"",""2345"",""2693"",""2452"",""2093"",""2613"",""1994"",""2630"",""2496"",""2422"",""1711"",""1999"",""2081"",""1241""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-11-21T02:19:33Z""
";https://scholar.google.ch/scholar?start=670&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098774-122;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;A Brief Review of Database Solutions Used within Blockchain Platforms;B Podgorelec, M Turkanovi?, M Šestak ; … Congress on Blockchain and …, 2020  Springer;;"… These platforms either: (1) are in the form of platform-as-a-service (Oracle Blockchain platform,

SAP … 113–129, Springer, Cham (2018)Google Scholar. 3. Wüst, K., Gervais, A.: Do you need a

blockchain? In: 2018 Crypto Valley Conference on Blockchain Technology (CVCBT), pp …";Cité 1 fois;Les 2 versions;[PDF] researchgate.net;https://www.researchgate.net/profile/Blaz_Podgorelec/publication/342941591_A_Brief_Review_of_Database_Solutions_Used_within_Blockchain_Platforms/links/5f3bb09f92851cd302015519/A-Brief-Review-of-Database-Solutions-Used-within-Blockchain-Platforms.pdf;;;https://scholar.google.ch/scholar?start=670&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098769-111;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;[PDF][PDF] Epistemological Mechanism Design (Extended Abstract)?;H Matsushima, S Noda ; econcs.pku.edu.cn;;"… 4 Application: Blockchain and Oracle Problem This … However, in this case, we face

the problem of how to incentivize agents to input correct informa- tion into the smart

contract—the oracle problem in the blockchain literature. This …";Autres articles;Version HTML;[PDF] pku.edu.cn;https://econcs.pku.edu.cn/wine2020/wine2020/Workshop/GTiB20_paper_4.pdf;;;https://scholar.google.ch/scholar?start=660&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098870-346;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;[PDF][PDF] EL sisTEMA JURÍDICo;A LA DIGITALIZACION ;2020 researchgate.net;;"… La tec- nología blockchain se relaciona con su entorno mediante los Oracles u oráculos, que

es una red de observadores externos que comprueban los eventos producidos durante la

ejecución del contrato, responden a las instrucciones de las partes en el sistema oa eventos …";;null;[PDF] researchgate.net;https://www.researchgate.net/profile/Cristina-Argelich-Comelles/publication/345001030_Desafios_legales_de_Blockchain_y_Ethereum_proteccion_de_datos_y_responsabilidad_civil/links/5fa2999692851cc2869377ca/Desafios-legales-de-Blockchain-y-Ethereum-proteccion-de-datos-y-responsabilidad-civil.pdf;;;https://scholar.google.ch/scholar?start=890&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098769-119;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;On Finality in Blockchains;E Anceaume, A Pozzo, T Rieutord… ; arXiv preprint arXiv …, 2020  arxiv.org;;"… In this section we assume that processes are equipped with an Oracle ?P or ?F,k (as defined

in [1]) to access the blockchain, ie, to … Briefly, oracles are abstraction that encapsulate the creation

of valid blocks and since only valid blocks can be appended to the blocktree, it …";Autres articles;;[PDF] arxiv.org;https://arxiv.org/pdf/2012.10172;"
ar
X

iv
:2

01
2.

10
17

2v
1 

 [
cs

.D
C

] 
 1

8 
D

ec
 2

02
0

On Finality in Blockchains

Emmanuelle Anceaume1, Antonella Del Pozzo2,

Thibault Rieutord2, Sara Tucci-Piergiovanni2

1CNRS, Univ Rennes, Inria, IRISA, Rennes, France
2Université Paris-Saclay, CEA, List, F-91120, Palaiseau, France

Abstract

There exist many forms of Blockchain finality conditions, from determinis-
tic to probabilistic terminations. To favor availability against consistency in
the face of partitions, most blockchains only offer probabilistic eventual final-
ity: blocks may be revoked after being appended to the blockchain, yet with
decreasing probability as they sink deeper into the chain. Other blockchains
favor consistency by leveraging the immediate finality of Consensus – a block
appended is never revoked – at the cost of additional synchronization.

In this paper, we focus on necessary and sufficient conditions to implement a
blockchain with deterministic eventual finality, which ensures that selected main
chains at different processes share a common increasing prefix. This is a much
weaker form of finality that allows us to provide a solution in an asynchronous
system subject to unlimited number of byzantine failures. We study stronger
forms of eventual finality as well and show that it is unfortunately impossible to
provide a bounded displacement. By bounded displacement we mean that the
(unknown) number of blocks that can be revoked from the current blockchain is
bounded. This problem reduces to consensus or eventual consensus depending
on whether the bound is known or not. We also show that the classical selection
mechanism, such as in Bitcoin, that appends blocks at the longest chain is not
compliant with a solution to eventual finality.

1 Introduction

This paper focuses on blockchain finality, which refers to the time when it becomes
impossible to remove a block that has previously been appended to the blockchain.
Blockchain finality can be deterministic or probabilistic, immediate or eventual. In-
formally, immediate finality guarantees, as its name suggests, that when a block
is appended to a local copy, it is immediately finalized and thus will never be re-
voked in the future. Most of the permissionned blockchains satisfy the deterministic
form of immediate consistency, including Red Belly blockchain [8] and Hyperledger
Fabric blockchain [3], while the probabilistic form of immediate consistency is typi-
cally achieved by permissionless pure proof-of-stake blockchains such as Algorand [7].
Designing blockchains with immediate finality favors consistency against availabil-
ity in presence of transient partitions of the system. It leverages the properties of
Consensus (i.e a decision value is unique and agreed by everyone), at the cost of
synchronization constraints. On the other hand eventual finality ensures that all
local copies of the blockchain share a common increasing prefix, and thus finality of

1

http://arxiv.org/abs/2012.10172v1


their blocks increases as more blocks are appended to the blockchain. The majority
of cryptoassets blockchains, with Bitcoin [15] and Ethereum [19] as celebrated ex-
amples, guarantee eventual finality with some probability: blocks may be revoked
after being appended to the blockchain, yet with decreasing probability as they sink
deeper into the chain.

Formalization of blockchains in the lens of distributed computing has been rec-
ognized as an extremely important topic [12]. Garay et al. [10] have been the first to
analyse the Bitcoin backbone protocol and to define invariants this protocol has to
satisfy to verify with high probability an eventual consistent prefix, i.e. probabilis-
tic eventual finality. The authors analyzed the protocol in a synchronous system,
while Pass et al. [17] extended this line of work considering a more adversarial net-
work. Anta et al. [4] proposed a formalization of distributed ledgers modeled as an
ordered list of records along with implementations for sequential consistency and lin-
earizability using a total order broadcast abstraction. Not related to the blockchain
data structure, authors of [11] formalized the notion of cryptocurrency showing that
Consensus is not needed.

While probabilistic eventual finality has been widely studied in the context of
Bitcoin [10, 5, 17], some few studies have started to lay the foundations of the com-
putation power of blockchains with deterministic eventual finality consistency. An-
ceaume et al. [2] have been the first to propose a formal blockchain specification as a
composition of abstract data types all together with a hierarchy of consistency crite-
ria. This work captured the convergence process of two distinct classes of blockchain
systems: the class providing strong prefix (for each pair of chains returned at two
different processes, one is the prefix of the other) and the class providing eventual
prefix, in which the common prefix eventually converges. Interestingly, the authors
of [2] show that to solve strong prefix, Consensus is needed, however the work does
not address the solvability of eventual prefix, which is the focus of this paper.

The objective of this paper is thus to push further this line of inquiry by present-
ing an in-depth study of deterministic eventual finality. We reinvestigate in Section 2
the definition of (deterministic) eventual prefix consistency presented in [2] to fit both
the context in which an infinite number of blocks are appended to the blockchain.
We introduce the notion of bounded displacement, which informally says that the
number of blocks that can be revoked from the current blockchain is bounded. Pro-
viding solutions that guarantee a known bound of the displacement reveals to be
an important crux in the construction of blockchains. Specifically, in Section 3 we
show that known bounded displacement eventual prefix consistency, that is eventual
prefix consistency guaranteeing a bounded and known displacement, is equivalent
to Consensus. We also demonstrate that unknown bounded displacement eventual
prefix consistency, that is eventual prefix consistency guaranteeing a bounded but
unknown displacement, is equivalent to eventual strong prefix consistency. Finally
we show that eventual strong prefix consistency is stronger than Eventual Consensus,
an abstraction that captures eventual agreement among all participants. Then in
Section 4 we provide an algorithm that guarantees eventual prefix consistency in an
asynchronous environment with an unbounded number of Byzantine processes. We
are not aware of any such solution in the literature. We also show that it is impos-
sible to build a blockchain that guarantees eventual prefix consistency based on the
longest chain rule. Note that such a selection function is used by many cryptoassets

2



blockchains. Finally, we discuss impossibilities and possibilities of unbounded dis-
placement eventual prefix consistency. In particular, we propose an algorithm that
solves unknown bounded displacement eventual prefix in an eventually synchronous
environment in presence of less than a majority of Byzantine processes. Once again,
we are not aware of any such solution in the literature. To summarize, we close the
gap between eventual prefix and strong prefix consistencies.

2 Definitions

2.1 Preliminary Definitions

Similarly to [2], we describe a blockchain object as an abstract data type which allows
us to completely characterize a blockchain by the operations it exports [14]. The
basic idea underlying the use of abstract data types is to specify shared objects using
two complementary facets: a sequential specification that describes the semantics
of the object, and a consistency criterion over concurrent histories, i.e. the set of
admissible executions in a concurrent environment [16]. Prior to presenting the
blockchain abstract data type we first recall the formalization used to describe an
abstract data type (ADT).

Abstract data types. An abstract data type (ADT) is a tuple of the form
T = (A,B,Z, z0, τ, δ). Here A and B are countable sets called the inputs and outputs.
Z is a countable set of abstract object states, z0 ∈ Z being the initial state of the
object. The map τ : Z × A → Z is the transition function, specifying the effect of
an input on the object state and the map δ : Z × A → B is the output function,
specifying the output returned for a given input and object local state. The input
represents an operation with its parameters, where (i) the operation can have a side-
effect that changes the abstract state according to transition function τ and (ii) the
operation can return values taken in the output B, which depends on the state in
which it is called and the output function δ.

Concurrent histories of an ADT. Concurrent histories are defined consider-
ing asymmetric event structures, i.e., partial order relations among events executed
by different processes.

Definition 1. (Concurrent history H) The execution of a program that uses an
abstract data type T =〈A,B,Z, ξ0, τ, δ〉 defines a concurrent history H = 〈Σ, E,Λ, 7→
,≺,ր〉, where

• Σ = A ∪ (A×B) is a countable set of operations;

• E is a countable set of events that contains all the ADT operations invocations
and all ADT operation response events;

• Λ : E → Σ is a function which associates events to the operations in Σ;

• 7→: is the process order, irreflexive order over the events of E. Two events
(e, e′) ∈ E2 are ordered by 7→ if they are produced by the same process, e 6= e′

and e happens before e′, that is denoted as e 7→ e′.

3



• ≺: is the operation order, irreflexive order over the events of E. For each
couple (e, e′) ∈ E2 if e′ is the invocation of an operation occurred at time t′

and e is the response of another operation occurred at time t with t < t′ then
e ≺ e′;

• ր: is the program order, irreflexive order over E, for each couple (e, e′) ∈ E2

with e 6= e′ if e 7→ e′ or e ≺ e′ then e ր e′.

2.2 The blockchain ADT

Following [2], we represent a blockchain structure as a a tree of blocks. Indeed, while
consensus-based blockchains prevent forks or branching in the tree of blocks, most
blockchain systems based on proof-of-work allow the occurrence of forks to happen
hence presenting blocks under a tree structure. The blockchain object is thus defined
as a blocktree abstract data type (Blocktree ADT). However, we modify the original
version of the blocktree ADT proposed in [2] so that distinct selection functions fr()
and fa() for respectively the read() and append() operations exist. As will be shown
latter in the paper, by relying on different functions to select the blockchain to be
returned by a read() operation and to select the chain of the blocktree to which the
new block is appended, this allows us to present the first algorithm that constructs
a blockchain satisfying deterministic eventual finality in an asynchronous system in
presence of an unbounded number of Byzantine processes.

2.2.1 Sequential Specification

A blocktree data structure is a directed rooted tree bt = (Vbt, Ebt) where Vbt repre-
sents a set of blocks and Ebt a set of edges such that each block has a single path
towards the root of the tree b0 called the genesis block. Let B be the countable
and non empty set of uniquely identified blocks and let BC be the countable non
empty set of blockchains, where a blockchain is a path from a leaf of bt to b0. A
blockchain is denoted by bc. The structure is equipped with two operations append()
and read(). Operation append(b) adds the block b 6∈ bt to Vbt and adds the edge
(b, b′) to Ebt where b

′ ∈ Vbt is returned by the append selection function fa() applied
to bt. Operation read() returns the chain bc selected by the read selection function
fr() applied to bt. In the following the chain bc returned by a read() operation r
is often denoted by r/bc. Only blocks satisfying some validity predicate P can be
appended to the tree. The definition of the Blocktree (BT) ADT amended with the
two types of selection functions is as follows.

Definition 2. (Blocktree ADT (BT-ADT) The Blocktree Abstract Data Type is the
6-tuple BT−ADT = {A = {append (b), read ()/bc ∈ B}, B = BC ∪ {⊤,⊥}, Z =
BT , ξ0 = b0, τ, δ}, where the transition function τ : Z ×A → Z is defined by

τ(bt, read ()) = bt

τ(bt, append(b)) =

{

(Vbt ∪ {b}, Ebt ∪ {b, last block (fa(bt))}) if P (fa(bt)
⌢b)

bt otherwise,

4



and where the output function δ : Z ×A → B is defined by

δ(bt, read ()) = fr(bt)

δ(bt, append(b)) =

{

⊤ if P (fa(bt)
⌢b)

⊥ otherwise.

The read selection fr() takes as argument the blocktree and returns a chain,
that is a sequence of blocks starting from the genesis block to a leaf block of the
blocktree. The chain returned by the read() operation is called the blockchain. The
append selection function fa() takes as argument the blocktree and returns a chain
of blocks. Function last block() takes as argument a chain of blocks and returns the
last appended block of the chain.

Predicate P is an application-dependent predicate used to verify the validity of
the chain obtained by appending the new block b to the chain returned by fa(). In
Bitcoin for instance this predicate embeds the logic to verify that the obtained chain
does not contain double spending or overspending transactions.

Note that we do not need to add the validity check during the read operation
in the sequential specification, because in absence of concurrency the validity check
during the append operation is enough.

2.2.2 Concurrent specification and consistency criteria

The concurrent specification of a blocktree abstract data type is the set of concurrent
histories. A blocktree consistency criterion is a function that returns the set of
concurrent histories admissible for a blocktree abstract data type. We define three
consistency criteria for the blocktree: BT Eventual Prefix consistency, BT Strong
Prefix consistency and BT Eventual Strong consistency. For ease of readability, we
employ the following notations:

• E(a∗, r∗) is an infinite set containing an infinite number of append() and read()
invocation and response events;

• E(a, r∗) is an infinite set containing (i) a finite number of append() invoca-
tion and response events and (ii) an infinite number of read() invocation and
response events;

• oinv and orsp indicate respectively the invocation and response event of an
operation o; and in particular for the read() operation, rrsp/bc denotes the
returned blockchain bc associated with the response event rrsp and for the
append() operation ainv((b)) denotes the invocation of the append operation
having b as input parameter;

• length : BC → N denotes a monotonic increasing deterministic function that
takes as input a blockchain bc and returns a natural number as length of bc.
Increasing monotonicity means that length(bc⌢{b}) > length(bc);

• bc ⊑ bc′ iff bc prefixes bc′.

• bc[i] refers to the i− th block in the blockchain bc.

5



Eventual Prefix (EP) Consistency

Definition 3 (BT Eventual Prefix Consistency (EP) criterion). A concurrent his-
tory H = 〈Σ, E,Λ, 7→,≺,ր〉, of a system that uses a BT-ADT, verifies the BT
Eventual Prefix Consistency criterion if the following properties hold:

• Chain validity:

∀rrsp ∈ E,P (rrsp/bc).

Each returned chain is valid.

• Chain integrity:

∀rrsp ∈ E,∀b ∈ rrsp/bc : b 6= b0,∃ainv(b) ∈ E, ainv(b) ր rrsp.

If a block different from the genesis block is returned, then an append operation
has been invoked with this block as parameter. This property is to avoid the
situation in which reads return blocks never appended.

• Eventual prefix:

∀E ∈ E(a, r∗) ∪ E(a∗, r∗),∀rrsp/bc,∀i ∈ N : bc[i] 6= ⊥,∃r′rsp,∀r
′′
rsp : r′rsp ր

r′′rsp, ((r
′
rsp/bc)[i] = (r′′rsp/bc)[i]).

In all the histories in which the number of read invocations is infinite, then
for any non empty read chain position i, there exists a read r′/bc′ from which
all the subsequent reads r′′/bc′′ will return the same block at position i, i.e.
bc′[i] = bc′′[i].

• Ever growing tree:

∀E ∈ E(a∗, r∗),∀k ∈ N,∃r ∈ E : length(rrsp/bc) > k.

In all the histories in which the number of append and read invocations is
infinite, for each length k, there exists a read that returns a chain with length
greater than k. This property avoids the trivial scenario in which the length of
the chain remains unchanged despite the occurrence of an infinite number of
append operations. This can happen for instance if the tree is built as a star
with infinite branches of bounded length.

Strong Prefix (SP) Consistency

Definition 4 (BT Strong Prefix Consistency criterion (SP )). A concurrent history
H = 〈Σ, E,Λ, 7→,≺,ր〉 of the system that uses a BT-ADT verifies the BT Strong
Consistency criterion if Chain validity, Chain integrity, Ever growing tree (as defined
for EP) and the following property hold:

• Strong prefix:

∀rrsp, r
′
rsp ∈ E2, (r′rsp/bc

′ ⊑ rrsp/bc) ∨ (rrsp/bc ⊑ r′rsp/bc
′).

For each pair of returned blockchains, one blockchain is the prefix of the other.

6



Eventual Strong Prefix (ESP) Consistency

Definition 5 (BT Eventual Strong Prefix Consistency criterion (ESP )). A con-
current history H = 〈Σ, E,Λ, 7→,≺,ր〉 of the system that uses a BT-ADT verifies
the BT Strong Consistency criterion if Chain validity, Chain integrity, Ever growing
tree (as defined for EP) and the following property hold:

• Eventual strong prefix:

∀E ∈ E(a, r∗) ∪ E(a∗, r∗), ∃rrsp ∈ E,∀r′rsp, r
′′
rsp ∈ E2 : rrsp ր r′rsp ∧ rrsp ր

r′′rsp, (r
′′
rsp/bc

′ ⊑ r′rsp/bc) ∨ (r′rsp/bc ⊑ r′′rsp/bc
′).

In all histories with an infinite number of reads, there exists a read r from
which for each pair of returned blockchains, one blockchain is the prefix of the
other.

Bounded displacement

Informally, the bounded displacement says that for any two reads r/bc and r′/bc′

such that r precedes r′, then by pruning the last dis blocks from bc the obtained
chain is a prefix of bc’. Note that constant dis can be initially known or not.

Definition 6. Bounded displacement

• ∃dis ∈ N,∀rrsp, r
′
rsp ∈ E : rrsp ր r′rsp,∀i ∈ N : i ≤ length(rrsp/bc) −

dis, (rrsp/bc)[i] = (r′rsp/bc
′)[i].

We will show in the following that satisfying the eventual prefix consistency crite-
rion plus the bounded displacement property with known dis boils down to getting
the strong prefix consistency criterion. This is because any algorithm implementing
the read selection function fr, can safely select the current chain but the last dis
blocks. Eventual prefix consistency criterion plus the known bounded displacement
is designated in the sequel by known bounded displacement eventual prefix consis-
tency.

The eventual prefix consistency criterion plus the bounded displacement property
with unknown dis boils down to get the eventual strong prefix consistency criterion.
In this case a simple algorithm implementing the read operation always returns half
of the selected longest chain. Since chains are always growing, the number of re-
moved blocks increases up to reaching dis. In the sequel, eventual prefix consistency
criterion plus the unknown bounded displacement is designated by unknown bounded
displacement eventual prefix consistency.

In the following section we prove the above-mentioned equivalences more formally
and study relationships to known problems such as Consensus and Eventual Con-
sensus to determine the assumptions on the system needed to implement blocktree
consistency models.

3 (Eventual) Consensus Reductions

In this Section we investigate the impact of the bounded displacement property
combined with the eventual prefix consistency problems. In particular, we derive

7



that when the displacement is known, such problem is equivalent to Consensus, while
when unknown, this problem is stronger than Eventual Consensus [9].

3.1 Known Bounded Displacement and Consensus

Theorem 1. Known bounded displacement eventual prefix is equivalent to Consen-
sus.

Proof. We first show how to solve strong prefix given a solution PEP for known
bounded displacement eventual prefix and then the reciprocal direction. Indeed, the
equivalence between the strong prefix consistency criteria with Consensus is known
from [1].

Let us show that we can solve the strong prefix consistency criteria, known to be
equivalent to Consensus [1], using PEP . To do so, we consider the following trans-
formation from the protocol PEP . To make an append() operation, processes simply
use the append() operation provided by PEP . But, for the the read() operation,
processes use the read() operation provided by PEP to obtain a chain and prune the
last dis blocks from it before returning the remaining chain. Note that if there are
less than dis blocks, processes then return the genesis block.

Let us show that this modified protocol solves the strong prefix consistency. For
this, we need to show that the following properties are satisfied:

• Chain validity: The chain validity property is still satisfied by pruning dis
blocks.

• Chain integrity: The chain integrity property is still satisfied by pruning dis
blocks.

• Strong prefix: The strong prefix property follows from the known bounded
displacement and the removal of the last dis blocks. Indeed, if we remove the
last dis blocks, then for any two read() operations, then the first read() returns
a prefix of the second read() operation.

• Ever growing tree: The ever growing tree property is still satisfied by prun-
ing dis blocks.

For the other direction, we can build a solution to known bounded displace-
ment eventual prefix using a solution for the strong prefix consistency criteria.
This trivially solves the eventual known bounded displacement prefix property with
dis = 0.

If we consider known bounded displacement eventual prefix then we have strong
prefix (we can read a chain and remove the last dis blocks to be sure that what
we read is final). Thus, since strong prefix requires Consensus and Consensus in
impossible in an asynchronous system (with a single failure) then, known bounded
displacement eventual prefix is impossible to solve in an asynchronous system.

8



3.2 Unknown Bounded Displacement and Eventual Consensus

Eventual Strong prefix and Unknown Bounded Displacement. If we have
an unknown bounded displacement, then eventual prefix, combined with such prop-
erty is stronger than Eventual Consensus. To show that, we first show its equivalence
with eventual strong prefix. Later we recall the Eventual Consensus problem (with
a small modification of the Validity property, to make it suits to the blockchain
context) and finally we show that unknown bounded displacement eventual prefix
is stronger than Eventual Consensus.

Theorem 2. Unknown bounded displacement eventual prefix is equivalent to even-
tual strong prefix.

Proof. Let P be a protocol solving the unknown bounded displacement eventual
prefix and let us show that we can solve the eventual strong prefix property. To do
so, we consider the following modification to the protocol P. To make an append()
operation, processes simply use the append() operation provided by P. But, for
read() operation, processes use the read() operation to obtain a chain and prune the
second half of the returned chain before returning the remaining half of the chain.

Let us show that this modified protocol solves the eventual strong prefix property.
For this, we need to show that the following properties are satisfied:

• Chain validity: The chain validity property is still satisfied by pruning half
the chain.

• Chain integrity: The chain integrity property is still satisfied by pruning
half the chain.

• Eventual Strong prefix: The eventual strong prefix property follows from
the unknown bounded displacement and the removal of the second half of the
chain. Indeed, if we remove the second half of the chain, then eventually for any
two read() operations, then the first read() returns a prefix of the second read()
operation. Indeed, since we remove a growing number of blocks, eventually we
remove more than dis blocks and obtain chains such that one is the prefix of
the other.

• Ever growing tree: The ever growing tree property is still satisfied by prun-
ing half the chain.

For the other direction, let us consider a protocol P solving the eventual strong
prefix property and let us show that it solves the unknown bounded displacement
eventual prefix. The property of eventual strong prefix clearly implies the eventual
prefix property. Let displacement(b1, b2) be the function that takes two blockchains
b1 and b2 and returns the number of blocks needed to prune b1 and obtain b′1 such that
b′1 ⊑ b2. Let us show that ∃dis ∈ N,∀rrsp, r

′
rsp ∈ E2, r ր r′, displacement(rrsp/bc, r

′
rsp/bc) <

dis. Assume by contradiction that this property is not satisfied, then it implies that
for any dis, there exists a couple of reads with a greater displacement than dis.
This implies that the eventual strong prefix property is not satisfied which leads
to a contradiction, hence eventual strong prefix property implies unknown bounded
displacement eventual prefix.

9



Eventual Consensus. The eventual consensus [9] (EC) abstraction captures even-
tual agreement among all participants. It exports, to every process pi, operations
proposeEC1, proposeEC2, . . . that take multi-valued arguments (correct processes pro-
pose valid values) and return multi-valued responses. Assuming that, for all j ∈ N,
every process invokes proposeECj as soon as it returns a response to proposeECj−1,
the abstraction guarantees that, in every admissible run, there exists k ∈ N and a
predicate PEC(), such that the following properties are satisfied:

• EC-Termination Every correct process eventually returns a response to proposeECj

for all j ∈ N.

• EC-Integrity No process responds twice to proposeECj for all j ∈ N.

• EC-Validity Every value returned to proposeECj is valid with respect to
PEC().

• EC-AgreementNo two correct processes return different values to proposeECj

for all j ≥ k.

Theorem 3. Eventual strong prefix is stronger than Eventual Consensus.

Proof. We show that it exists a protocol PEC to solve Eventual Consensus starting
from a protocol PESP for eventual strong prefix. We do the transformation as
follows. Every correct process p invokes proposeECj for all j ∈ N. We impose that
the validity predicate P () of the blocktree ADT (see Section 2) be equal to predicate
PEC(). When a correct process invokes the proposeECj(v) operation of PEC , for any
j ∈ N, then it directly invokes the append(v) operation of PESP . After that, p
invokes a sequence of read() operations up to the moment it returns a chain bc such
that bc[j] 6= ⊥. Process p then returns chain bc as decision for proposeECj(v) and
triggers the next operation proposeECj+1(v

′).
Let us show that protocol PEC solves the Eventual Consensus.

• EC-Termination This property is guaranteed by the ever growing tree prop-
erty.

• EC-Integrity This property follows directly from the transformation.

• EC-Validity This property follows by construction and the chain validity
property, since P () = PEC().

• EC-Agreement This property follows by the eventual strong prefix property,
that guarantees that there exists a read() operation r such that, all the subse-
quent ones, return blockchains that are each prefix of the other one. In other
words, eventually there is agreement on the value contained in bc[j]. This im-
plies that there exists k for which all proposeECj with j > k returns the same
value to all correct processes.

10



b0

t0
b′
1,1

t1

. . . b′
1,h

t2

b′
1,h+1

t5

. . . b′
1,h′

t6

b′
2,1

t3

. . . b′
2,l

t4

b′
2,l+1

t7

lenght—
s1,1

—

s1,h
—
s2,1

—

s2,l
—

s1,h+1

—

s1,h′

—

s2,l+1

Figure 1: A blocktree generated by two processes. On the x-axis the longest chain
value of each chain at different time instants (from the root to the current leaf) and
the relationships between those values.

4 Eventual Prefix solutions

In this section we assume that processes are equipped with an Oracle ΘP or ΘF,k

(as defined in [1]) to access the blockchain, i.e., to read its status (getValidBlock ()
operation) and append a new block to it (setValidBlock () operation). Briefly, oracles
are abstraction that encapsulate the creation of valid blocks and since only valid
blocks can be appended to the blocktree, it follows that oracles grant the access to
the blocktree. Oracle ΘF,k also owns a synchronization power to control the number
of forks (k), in terms of branches of the blocktree from a given block. On the other
hand ΘP poses no constraints on the number of blocks that can be appended to the
same block, i.e., it allows forks and it poses no bound on the number of blocks in a
fork (more details can be found in in [1]).

4.1 Impossibility of Eventual Prefix with longest chain rule

In the following we prove that we cannot provide eventual prefix consistency in the
shared-memory model if the append selection function follows the the longest chain
rule even when equipped with ΘF,2.

We consider a crash-prone asynchronous system with a finite number of processes
and an append selection function f equipped with ΘF,2 that deterministically selects
a chain with the longest chain, and in case of a tie selects a chain based on the
lexicographical order. We show that it is impossible to implement a blockchain that
satisfies eventual prefix consistency for this append selection function.

Note that such a selection function is used by many blockchain systems. In
particular in proof-of-work systems such as Bitcoin, chains are selected as the longest
chain while in Ethereum chains are selected using the chain with greatest weight,
both captured by the selection of chains according to the longest chain.

Theorem 4. It is impossible to build a blockchain that guarantees eventual prefix
consistency when the append operation is based on the longest chain rule and is
equipped with ΘF,2.

Proof. Intuitively, the impossibility follows from the fact that with the longest chain
selection, races can occur between different branches in the tree. We show that as
forks may occur, we can create two infinite branches sharing only the root. Alterna-
tively, one or the other branch constitutes the longest chain and append operations
selects chains from each branch alternatively. This is enough to show that the only

11



common prefix that is returned is the root, hence, violating the eventual prefix
consistency.

Let p1 and p2 be two processes trying to append infinitely many blocks.
At time t0, for both p1 and p2, the update view of bt equals b0, thus both call

getValidBlock(b0, bi,1) = b′i, where i = 1 for p1 and i = 2 for p2. At time t1 > t0, p1
and p2 are poised to call setValidBlock (b0, b

′
i,1). Let p2 be slower than p1, thus p1

cannot distinguish whether p2 is slow or crashed. Process p1 gets the set {b′1,1} as
result of the function and proceeds to append a new block b1,2, i.e., it updates bt’s
view and applies f on it to select the leaf where to append the new block, in this
case the only leaf is b′1,1. p1 calls getValidBlock (b′1,1, b1,2) which returns {b′1,2} and
hereafter at time t2 > t1 it is poised to call setValidBlock (b′1,1, b

′
1,2).

We can continue in the same way up to time t3 ≥ t2, the moment in which the
function setValidBlock (b0, b

′
2,1) returns {b′1,1, b

′
2,1} to p2. We assume that at time

t3, p1 built a chain from the root b0 to b′
1,h and is poised to append b′

1,h+1
. The

chain from b0 to b′
1,h has a length s1,h and the chain b0 to b′2,1 has a length s2,1.

W.l.o.g., we assume that s1,h < s2,1 and s1,h+1 > s2,1. At time t4 > t3, p2 updates
its view of bt and f applied to it selects the chain from b0 to b′2,1, as s1,h < s2,1,
to append the new block. We can make it append blocks until it is poised to call a
setValidBlock (b′

2,l, b
′
2,l+1

) such that s2,l < s1,h+1 and s2,l+1 > s2,h+1 (cf. Figure 1).
We can continue to create two infinite branches sharing only the root. A read
operation can alternatively return a chain from each branch, depending on the time
(cf. Figure 1), e.g., from b0 to b′

1,h at time t2 and from b0 to b′
2,l at time t4. Thus, the
";"""date"",""2020-12-21T01:59:13Z""
""pdf:PDFVersion"",""1.4""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.4""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""xmp:CreateDate"",""2020-12-20T20:59:13Z""
""modified"",""2020-12-21T01:59:13Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""xmp:ModifyDate"",""2020-12-20T20:59:13Z""
""pdf:docinfo:creator"",""""
""meta:author"",""""
""meta:creation-date"",""2020-12-21T01:59:13Z""
""created"",""2020-12-21T01:59:13Z""
""xmp:About"",""uuid:ac3bdf27-7b4c-11f6-0000-e70b3f9719c0""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-12-21T01:59:13Z""
""resourceName"",""2012.10172""
""Author"",""""
""producer"",""dvips + GPL Ghostscript GIT PRERELEASE 9.22""
""pdf:docinfo:producer"",""dvips + GPL Ghostscript GIT PRERELEASE 9.22""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""9"",""4"",""1"",""8"",""3"",""0"",""0"",""1"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2020-12-21T01:59:13Z""
""Last-Modified"",""2020-12-21T01:59:13Z""
""dcterms:modified"",""2020-12-21T01:59:13Z""
""title"",""""
""xmpMM:DocumentID"",""uuid:ac3bdf27-7b4c-11f6-0000-e70b3f9719c0""
""Last-Save-Date"",""2020-12-21T01:59:13Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2020-12-21T01:59:13Z""
""meta:save-date"",""2020-12-21T01:59:13Z""
""Content-Length"",""201120""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""17""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""2474"",""3205"",""2254"",""2277"",""2106"",""1655"",""2158"",""2025"",""2451"",""2026"",""2297"",""2078"",""2365"",""2393"",""2790"",""2142"",""1184""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-12-21T01:59:13Z""
";https://scholar.google.ch/scholar?start=660&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098892-395;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;How might broad adoption of blockchain?based traceability impact the US fresh produce supply chain?;AJ Collart, E Canales ; Applied Economic Perspectives and …, 2020  Wiley Online Library;;"… How might broad adoption of blockchain?based traceability impact the US fresh produce supply

chain? Alba J. Collart Corresponding Author. alba.collart@msstate.edu … WHAT IS BLOCKCHAIN?

Blockchain is a type of distributed ledger technology used to manage digital data …";Cité 2 fois;;null;;;;https://scholar.google.ch/scholar?start=940&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098720-4;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Stakes and Challenges Regarding the Financial Auditor's Activity in the Blockchain Era.;N FARCANE, D DELIU ; Audit Financiar, 2020  search.ebscohost.com;;"… in 2008, to serve as the public trading record of a bitcoin cryptocurrency, the identity … make efforts

to regulate the Blockchain technology and cryptocurrencies, but the few regulations that have …

In the absence of specific regulations, it appears that crypto-assets can be used freely …";Cité 1 fois;;null;;;;
1619098892-398;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Koronavirüs sebebiyle yayg?nla?an online al??veri?lerde kabul edilen elektronik sözle?melerin tüketicinin korunmas?na etkileri;M Arslan ;2020 openaccess.ihu.edu.tr;;"Page 1. — 475 — Koronavirüs Sebebiyle Yayg?nla?an Online Al??veri?lerde Kabul

Edilen Elektronik Sözle?melerin Tüketicinin Korunmas?na Etkileri Ar. Gör. Merve

ARSLAN* Özet Elektronik ileti?im araçlar? kullan?larak elektronik …";Les 2 versions;Version HTML;[PDF] ihu.edu.tr;http://openaccess.ihu.edu.tr/xmlui/bitstream/handle/20.500.12154/1235/sempozyum12.pdf?sequence=1;"
— 475 —

Koronavirüs Sebebiyle Yaygınlaşan 
Online Alışverişlerde Kabul 

Edilen Elektronik Sözleşmelerin 
TĂźketicinin KorunmasÄąna Etkileri

Ar. GĂśr. Merve ARSLAN*

Özet

Elektronik iletişim araçları kullanılarak elektronik ortamda kurulan 
elektronik sözleşmelerin en yaygını internet üzerinden web siteleri aracı-
lığıyla kurulan sözleşmelerdir. Bu sözleşmeler kural olarak hazır olmayan-
lar arası, katılmalı ve mesafeli sözleşme özelliği gösterirler. Katılmalı sözleş-
melerin taraflara mĂźzakere imkanÄą sunmamasÄą sebebiyle TĂźketici Hukuku 
kapsamında haksız şartlar meydana gelmekte ve sözleşme kesin hükümsüz-
lük yaptırımına tabi tutularak tüketici korunmaktadır. Yine sözleşmelerin 
mesafeli sözleşme niteliğinde olması ve mesafeli sözleşmeler bakımından 
hukukumuzda tĂźketiciyi koruyucu hĂźkĂźmlere yer verilmesi sayesinde ko-
runma sağlanmaktadır. Mesafeli sözleşmeler bakımından tüketicinin ko-
runması özellikle satıcı/sağlayıcının tüketiciyi bilgilendirme yükümlülüğü 
ve tüketicinin cayma hakkına sahip olması yoluyla sağlanmaktadır.

Anahtar Kelimler: Elektronik Sözleşmeler, Haksız Şartlar, Mesafe-
li Sözleşmeler, Tüketicinin Korunması, Ön Bilgilendirme Yükümlülüğü, 
Cayma HakkÄą.

Abstract

The most common of electronic contracts established in electron-
ic form using electronic communication tools are contracts established 
through websites over the internet. These contracts, as a rule, exhibit 

 * Tokat Gaziosmanpaşa Üniversitesi Hukuk Fakültesi Medeni Hukuk Anabilim Dalı 
Araştırma Görevlisi, merve.arslan@gop.edu.tr, ORCID: 0000-0002-9702-3422.



Äą. bĂślĂźm  | Ar . GĂśr . Merve ARSL AN

— 476 —

inter-participant, participatory and distance contracts. Since participatory 
contracts do not offer negotiation opportunities to the parties, unfair terms 
arise under the Consumer Law and the consumer is protected by subject-
ing the contract to absolute invalidity. Again, protection is provided by the 
fact that contracts are distant contracts and in terms of distant contracts, 
protective provisions are included in our law. The protection of the con-
sumer in terms of distance contracts is provided by the seller/provider, in 
particular, with the obligation to inform the consumer and the right of the 
consumer to withdraw.

Key Words: Electronic Contract, Unfair Terms, Distance Contract, 
Consumer Protection, Obligation to Inform, Right of Withdrawal.

GİRİŞ

İçinde bulunduğumuz pandemi çağında günlük ihtiyaçlarımızı karşı-
lamak adına online alışverişlere yönelmekteyiz. Öyle ki sokağa çıkma ya-
sakları sebebiyle alışveriş yapmak zorlaşmakta ve sokağa çıkma yasakları 
haricinde dahi uzun market kuyruklarÄąnda beklemek durumunda kalmak-
tayız. Bu sebeplerle yardımımıza online alışveriş siteleri koşmakta, sağla-
dığı ürün çeşitliliği sayesinde tercih edilebilir durumda bulunmaktadır. Bu 
çerçevede alıcı konumundaki tüketiciler elektronik sözleşmeler kurmakta 
ve karşılaşabilecekleri uyuşmazlıklar konusunda bilgilendirilmeye ve ko-
runmaya ihtiyaç duymaktadırlar. Konunun önemine binaen bu çalışma ya-
pılmış olup öncelikle elektronik sözleşmenin ne anlama geldiği, türleri ve 
Üzellikleri açĹsĹndan genel açĹklamalarda bulunulacak, ardĹndan Üzellikle 
haksız şartlar ve mesafeli sözleşmeler çerçevesinde tüketiciyi koruyucu hü-
kĂźmlerden bahsedilecektir.



KoronavirĂźs DĂśneminde GĂźncel Hukuki Meseleler Sempozyumu

— 477 —

I. ELEKTRONİK SÖZLEŞMELER

A. TanÄąmÄą 

Elektronik sözleşmeler, elektronik iletişim araçları kullanılarak dijital 
ortamda kurulan sözleşmelerdir1. Elektronik iletişim araçlarının en yaygını-
nı internet oluşturduğundan elektronik sözleşmeleri internet araçları kulla-
nılarak internet üzerinden kurulan sözleşmeler olarak tanımlayan yazarlar 
da mevcuttur2. Ancak bu yaklaşım doğru olmayıp elektronik sözleşmelerin 
internet üzerinden kurulan sözleşmelerden daha geniş kapsama sahip oldu-
ğunu ve internet dışındaki telefon, faks, televizyon gibi elektronik iletişim 
araçları kullanılarak kurulan sözleşmelerin de elektronik sözleşme niteliği 
taşıdığını belirtmek gerekir3. Bu sebeplerle çalışmanın devamında internet 
üzerinden kurulan sözleşmeler için daha geniş kapsama sahip elektronik 
sözleşme ibaresini değil internet üzerinden kurulan sözleşmeler ibaresini 
kullanacağız.

Türk Borçlar Kanunu (TBK)’nun 1. maddesinde sözleşmelerin “taraf-
ların iradelerini karşılıklı ve birbirine uygun olarak açıklamalarıyla” kuruldu-
ğu belirtilmiştir. İnternet üzerinden kurulan sözleşmeler de tıpkı TBK anla-
mında kurulan sözleşmelerde olduğu gibi tarafların karşılıklı ve birbirlerine 
uygun irade beyanlarĹnĹ açĹklamalarĹyla kurulurlar4. İnternet ßzerinden kuru-

 1 Özge Uzun Kazmacı, ‘İnternet Üzerinden Kurulan Mesafeli Sözleşmelerde Tüketici-
nin Korunması’ (2016) 22(3) Marmara Üniversitesi Hukuk Fakültesi Hukuk Araş-
tırmaları Dergisi (Cevdet Yavuz’a Armağan) 2791, 2792; Nahide Siller, 6502 Sayılı 
Tüketicinin Korunması Hakkındaki Kanun Kapsamında Web Sitesi Vasıtasıyla Sözleş-
melerin Kurulması (1. Baskı, Onikilevha 2019) 13: Elektronik iletişim araçları yerine 
elektronik vasıtalar ifadesini kullanarak elektronik sözleşmeleri elektronik vasıtalarla 
kurulan sözleşmeler  olarak tanımlamıştır; Sera Reyhani Yüksel, ‘Elektronik Sözleşme-
lerde Cayma Hakkı’ nin Hakan Tokbaş ve Ali Suphi Kurşun (eds), E-ticaret Sektörün-
de TĂźketici Hukuku UygulamalarÄą (Aristo 2017) 129, 129.

 2 İpek Sağlam, Elektronik Sözleşmeler (1. Baskı, Legal 2007) 72; Bülent Sözer, Elektro-
nik Sözleşmeler (1. Baskı, Beta 2002) 89; Cüneyt Bellican, ‘Elektronik Sözleşmelerde 
Tüketicinin Bilgilendirilmesi’nin Hakan Tokbaş ve Ali Suphi Kurşun (eds), E-ticaret 
SektĂśrĂźnde TĂźketici Hukuku UygulamalarÄą (Aristo 2017) 94.

 3 Uzun KazmacÄą 2792.
 4 Sağlam 71; Turgay Sarıakçalı, İnternet Üzerinden Akdedilen Sözleşmeler (1. Baskı, 

Seçkin 2008) 39.



Äą. bĂślĂźm  | Ar . GĂśr . Merve ARSL AN

— 478 —

lan sözleşmelerin TBK anlamındaki sözleşmelerden kurulum açısından far-
kını sözleşmenin kurulmasında bir elektronik iletişim aracı olan internetin 
kullanılması oluşturur5.

İnternet kullanılarak kurulan sözleşmeler her ne kadar elektronik söz-
leşme kategorisinde değerlendirilse de internet üzerinden kurulan bütün 
sözleşmeler elektronik sözleşme niteliği taşımazlar: Web sayfası kurulumu 
amacıyla yapılan sözleşmeler6, internet üzerinden reklam yapılması ama-
cıyla kurulan sözleşmeler, internet bağlantısı kurulumu amacıyla yapılan 
sözleşmeler elektronik sözleşme kategorisine girmeyen tür sözleşmelerdir7.

B. İnternet Üzerinden Kurulan Sözleşme Türleri

1. Elektronik Veri Değişimi (EDI- Electronic Data 
Internchange) 

EDI, insan unsuru devreye girmeksizin bilgisayarlar arası veri deği-
şimi sağlayan sistemler dahilinde gerçekleştirilir8 ve esasen bir sözleşme 
türü değil elektronik ticaret türüdür9. Genellikle işletmeler arasında ger-

 5 Sağlam 71-72; Sarıakçalı 39; Aziz Erman Bayram, ‘Güncel Gelişmeler Işığında Elekt-
ronik Sözleşmelerin Kurulması’ (2015) (119) TBB Dergisi 331, 334.

 6 Web sayfası kurulumu amacıyla yapılan sözleşmelerin TBK madde 470’te düzenlenen 
eser sözleşmesi niteliğine haiz olduğuna ilişkin ayrıntılı açıklama için bkz  Sağlam 72.

 7 Sözer 89; Sağlam 72. 
 8 Sağlam 89; Sözer 90; Alper Uyumaz, ‘Elektronik Sözleşmelerin Web Siteleri Aracılı-

ğıyla Kurulması ve Bu Sözleşmelerin İfası’ (2007) 9(Özel Sayı) Dokuz Eylül Üniver-
sitesi Hukuk Fakültesi Dergisi 907, 911; Sibel Özel, ‘Sözleşmesel İlişkide MÖHUK 
m. 24/II’de Öngörülen Objektif Bağlama Kuralının Mukayeseli Hukuk Açısından 
Değerlendirilmesi’ (2002) (2) Milletlerarası Hukuk ve Milletlerarası Özel Hukuk 
BĂźlteni 577, 613.

 9 Sözer 90: TBK madde 1 çerçevesinde bir sözleşmeden bahsedebilmek için sözleş-
menin iradelerini açıklama yeteneğine sahip taraflara sahip olması ve bu tarafların 
iradelerinin karşılıklı ve birbirine uyguyn olarak açıklanmış olması gerekir. EDI’da 
bilgisayarlar arası bir veri değişimi söz konusu olduğundan sözleşme nitelendirme-
si yapılması doğru olmayacaktır; karşı görüş için bkz Abdurrahman Savaş, İnternet 
Ortamında Yapılan Sözleşmeler (1. Baskı, Adal Ofset 2005) 193 (Alper Uyumaz, 
‘Elektronik Sözleşmelerin Web Siteleri Aracılığıyla Kurulması ve Bu Sözleşmelerin 
İfası’ (2007) 9(Özel Sayı) Dokuz Eylül Üniversitesi Hukuk Fakültesi Dergisi 907, 
911-912’den naklen)



KoronavirĂźs DĂśneminde GĂźncel Hukuki Meseleler Sempozyumu

— 479 —

çekleştirilirler ve çoğunlukla taşımacılık, bankacılık, sağlık gibi alanlar-
da kullanÄąlÄąrlar10.

EDI bir sözleşme tipi olmamasına rağmen EDI’yı uygulayacak taraf-
lar öncesinde asıl işi düzenleyen bir sözleşme ile EDI’nın ne şekilde uygu-
lanacağına dair kuralların belirlendiği TPA (Trading Partner Agreement) 
denilen bir sözleşme yaparlar11. EDI’nın gerçekleştirildiği aşamada bir tara-
fın bilgisayarı diğer tarafa bir mesaj gönderir (örneğin mal satımına ilişkin 
sözleşmede eczanenin bilgisayarı stoku biten 100 adet ilaç siparişine yöne-
lik mesajı gönderir), diğer tarafın bilgisayarı bu mesajı algılar ve gereken 
yere mesajın iletimini sağlar (ilaç satım firmasınınn bilgisayarı mesajı alır 
ve depo birimine aktarÄąr), ardÄąndan genellikle insan unsuru devreye girerek 
işlemi gerçekleştirir (depo birimi 100 adet ilacı araca yükleyerek sipariş sa-
hibine gĂśnderir)12.

EDI, insan unsuru bulundurmadığından hata riskini aza indirmesi, za-
mandan tasarruf sağlaması ve kişilerin yapacağı işlemlere göre maliyeti dü-
şürmesi sebebiyle avantajlıdır ve tercih edilmektedir13.

2. Chat Yoluyla Kurulan Sözleşmeler

Haberleşmenin eş zamanlı ve kesintisiz olarak iki veya daha çok taraf 
arasında internet üzerinden sağlandığı ve bu şekilde birbirine uygun irade-
lerin karşılıklı değişimi yoluyla sözleşmelerin kurulduğu sözleşmeleri ifade 
eder14. Sözleşmenin kurulumu icap ve kabul beyanlarının chat imkanı su-
nan sistem üzerinden internet kullanılarak iletilmesi şeklinde olsa da ifanın 
genellikle geleneksel yöntemlerle yapıldığını söyleyebiliriz. Örneğin chat 
esnasında alıcı satıcıya ait bir telefonu satın almak istediğini, satıcı ise tele-
fonu sattığını beyan etmekle bir satım sözleşmesi kurmakta ancak satılanın 

 10 Sağlam 90; Sarıakçalı 41.
 11 SĂśzer 91.
 12 SĂśzer 90.
 13 Sağlam 90.
 14 Sağlam 94-95; Muzaffer Şeker, ‘6098 Sayılı Yeni Türk Borçlar Kanununa Göre İnter-

net Üzerinden Sözleşmelerin Kurulması’ (2012) 11(22) İstanbul Ticaret Üniversitesi 
Sosyal Bilimler Dergisi 127,138.



Äą. bĂślĂźm  | Ar . GĂśr . Merve ARSL AN

— 480 —

ifası internet ortamı haricinde malın fiziken teslim edilmesi şeklinde ger-
çekleşebilmektedir. Ancak istisnai olarak örneğin bir e-kitabın, filmin, bil-
gisayar programının chat sistemi dahilinde karşı tarafa gönderildiği du-
rumlarda ifanın da internet üzerinden chat yoluyla sağlanması söz konusu 
olmaktadÄąr.

1. E-mail Yoluyla Kurulan Sözleşmeler

E-mail yoluyla kurulan sözleşmeler geleneksel anlamdaki posta yoluy-
la mektuplaşma şeklinde kurulan sözleşmelerden temel olarak farklı değil-
dir, tek fark postanın internet ortamında karşı tarafa varmasıdır15. E-mail 
yoluyla kurulan sözleşmelerde tarafların irade beyanlarını (icap, icaba da-
vet, kabul) içeren metinler internet aracılığıyla e-mail gönderme suretiy-
le bir bilgisayardan diğerine dolayısıyla iradesini sunan taraftan diğer tarafa 
iletilmektedir16. Ä°cap, icaba davet, kabul gibi beyanlarÄąnÄąn yanÄąnda taraf-
lar sözleşme kurmaya yönelik oluşturdukları kendi genel işlem şartlarını da 
e-mail eki olarak sunmaktadÄąrlar. 

Taraflar sözleşmenin esaslı noktalarında uyuşmuşlarsa sözleşme ku-
rulmuş sayılır17 ancak genel işlem koşullarında ikincil noktalar konusunda 
çatışma mevcutsa18 hangi tarafın genel işlem koşulunun uygulanacağı so-
runu ortaya çıkacaktır. Bu konuda TBK’da bir çözüm getirilmemiş olup 
icap ve kabule ilişkin genel hükümler uygulanacaktır. Doktrindeki hâkim 
görüşe göre, henüz ifa aşamasına geçilmemiş bir sözleşmede icap kayıtla-
rının subjektif esaslı nokta teşkil ettiği ve karşı taraf kayıtları kabul etme-
dikçe sözleşmenin kurulamayacağı ileri sürülmektedir19. Ancak ifa aşa-

 15 Sağlam 93; Şeker 137 (İnternet); Turan Şahin, ‘Elektronik Sözleşmelerin Kuruluşu-
na İlişkin İrade Beyanları ve Bu Beyanların Geri Alınması’ (2011) (95) TBB Dergisi 
331, 339.

 16 Şeker 137 (İnternet).
 17 TBK m 2: “Taraflar sözleşmenin esaslı noktalarında uyuşmuşlarsa, ikinci derecedeki nok-

talar üzerinde durulmamış olsa bile, sözleşme kurulmuş sayılır.”
 18 GÜkhan Antalya, Borçlar Hukuku Genel Hßkßmler (2. BaskĹ, Beta 2013) 300-301: Ta-

rafların genel işlem şartlarının uyuşmaması “formların çatışması (battle of the forms)” 
şeklinde adlandırılır. 

 19 Erdem Büyüksağış, ‘Borçlar Kanunu ve Viyana Satım Sözleşmesi Perspektifinden 
Çelişen Genel İşlem Koşulları’ (2015) (5) Uluslararası Antalya Üniversitesi Hukuk 
FakĂźltesi Dergisi 135, 139.



KoronavirĂźs DĂśneminde GĂźncel Hukuki Meseleler Sempozyumu

— 481 —

masına geçilmişse uyuşulmayan şartların subjektif esaslı nokta oldukları 
ve sözleşmenin geçersiz olduğu sonucuna artık varılamaz20, geçerli olarak 
kurulmuş bir sözleşme mevcuttur, sorun ise çatışan genel işlem şartların-
dan hangilerinin uygulama alanı bulacağı yönündedir. Burada karşımıza 
iki görüş çıkmaktadır; birinci görüşe göre, çatışan şartlar birbirini nötrle-
yecek ve ortaya çıkan boşluk genel hükümlerce doldurulacaktır21, öyle ki 
kural olarak susma biçimindeki pasif davranış çatışan şartını kabul anla-
mına gelmez22. İkinci görüşe göre, söz konusu durumda dayanağını işlem 
güvenliği ilkesinin oluşturduğu son söz teorisi (last shot kuralı) uygulama 
alanı bulacaktır23. Buna göre genel işlem şartlarını en son gönderen tara-
fın şartları sözleşmeye dâhil edilecek ve uygulanacaktır24. Öyle ki bu gö-
rüşe göre son gönderilen genel işlem koşullarına karşın karşı tarafın sus-
ması kabul olarak değerlendirilmektedir25.

2. Web Siteleri Aracılığıyla Kurulan Sözleşmeler

Web siteleri aracılığıyla kurulan sözleşmeler, satıcı tarafın web sitesin-
de tek taraflı olarak belirlediği şartları sunduğu, alıcının ise müzakere im-
kanı tanınmaksızın genellikle bir ikonu tıklamak suretiyle şartlara yönelik 
kabul beyanında bulunarak sözleşmenin kurulmasını sağladığı sözleşmeler-
dir26. Web sitesinin teklif verme imkanı sağladığı durumlar haricinde alıcı 
satıcının belirlediği sözleşme şartlarını kabul etmezse sözleşme kurulmaz, 
yani alÄącÄąya pazarlÄąk imkanÄą tanÄąnmamaktadÄąr27.

Web siteleri aracılığıyla kurulan sözleşmelerle uygulamada genellik-
le satım sözleşmeleri olarak karşılaşmaktayız ancak açık artırmayla satım 

 20 Antalya 301.
 21 Antalya 301.
 22 Büyüksağış 139.
 23 Antalya 301.
 24 Yasemin Yücesoy Yılmaz, ‘Viyana Satım Anlaşması Hükümlerine Göre Kabul’ (2017) 

(30) TAAD 423, 436.
 25 Büyüksağış 140.
 26 Sözer 92; Sağlam 96; Özel (Sibel) 612.
 27 Uyumaz 314: Bu durum, İngilizcede “take it or leave it” deyimiyle ifade edilmektedir.



Äą. bĂślĂźm  | Ar . GĂśr . Merve ARSL AN

— 482 —

sözleşmeleri, dijital ürün temini sözleşmeleri, hizmet sunumu sözleşmeleri 
gibi çeşitli sözleşmeler de web siteleri aracılığıyla kurulabilmektedir28. 

Konumuz açısından esas teşkil eden internet üzerinden kurulan söz-
leşme türü, web siteleri aracılığıyla kurulan satım sözleşmeleridir. Öyle ki 
pandemi döneminde tüketiciler online alışverişlere yönelmekte, web site-
leri aracılığıyla satım sözleşmesi kurmaktadır. Bu durumda sözleşmenin bir 
tarafını zayıf konumda bulunan tüketici (alıcı) oluşturduğundan koruyu-
cu hükümler konusunda tüketicinin bilgilendirilme ihtiyacı doğmuştur. Bu 
husus tüketiciyi koruyucu hükümler çerçevesinde aşağıda ayrıntılı olarak 
ele alÄąnacaktÄąr.  

C. Elektronik Sözleşmelerin Elektronik Ticaretle 
İlişkisi ve Elektronik Ticaret Türleri

1. Elektronik Ticaretle İlişkisi

Elektronik sözleşmelerin internet üzerinden kurulan sözleşmeleri 
içine alan ve elektronik iletişim araçları kullanılarak dijital ortamda ku-
rulan sözleşmeler olarak tanımlandığını belirtmiştik29. Elektronik ticaret 
ise tıpkı elektronik sözleşmelerde olduğu gibi elektronik iletişim araçla-
rÄą kullanÄąlarak yapÄąlan ticari faaliyetleri ifade eder30. Ancak bazÄą yazarlar 
elektronik ticareti yalnızca internet aracılığıyla yapılan ticaret olarak ta-
nÄąmlamaktadÄąrlar31.

Elektronik sözleşmelerin elektronik ticaretle ilişkisinden bahsettiği-
mizde elektronik sözleşme kurmak yoluyla ticari faaliyet göstermeyi elekt-
ronik ticaret olarak adlandırmamız mümkündür. Öyle ki internet üzerinden 

 28 Web siteleri aracılığıyla kurulan sözleşme çeşitleri hakkında ayrıntılı açıklamalar için 
bkz Sağlam 96.

 29 Uzun Kazmacı 2792; Siller 13: Elektronik iletişim araçları yerine elektronik vasıtalar 
ifadesini kullanarak elektronik sözleşmeleri elektronik vasıtalarla kurulan sözleşmeler 
olarak tanımlamıştır.

 30 Sarıakçalı 18; Sağlam 62; Mehmet Demir, Mesafeli Sözleşmelerin İnternet Üzerinden 
KurulmasÄą (1. BaskÄą, Turhan 2004) 117.

 31 SĂśzer 89.



KoronavirĂźs DĂśneminde GĂźncel Hukuki Meseleler Sempozyumu

— 483 —

kurulan elektronik sözleşme bir ticari faaliyet çerçevesinde kurulmuşsa bu-
rada da elektronik ticaretin varlığından bahsederiz. Sonuç olarak elektro-
nik sözleşme ve elektronik ticaret çoğunlukla iç içe geçmiş kavramlar ola-
rak karşımıza çıkmaktadır. 

Elektronik ticarette, elektronik sözleşmelerden farklı olarak sözleşme-
nin dayanağını ticari iş oluşturmaktadır.  Bir işin ticari iş olup olmadığının 
tespiti TTK m. 3 ve TTK m. 19 çerçevesinde yapĹlmaktadĹr. TTK m.3 ge-
reğince bir iş iki halde ticari iş sayılabilecektir; söz konusu iş, ya TTK’da dü-
zenlenen müesseselerle ilgili olmalı ya da ticari işletmeyi ilgilendirmelidir. TTK 
m. 19’a göre de ticari iş sayılmanın iki kriteri vardır; ya iş tacirin işi olmalıdır32 
ya da taraflardan en az biri için ticari sayılan bir sözleşme ilişkisi mevcut olma-
lıdır. Bu kriterler çerçevesinde bir iş ticari iş olarak nitelendirilebiliyorsa ve 
söz konusu ticari iş elektronik iletişim araçlarıyla gerçekleştiriliyorsa elekt-
ronik ticaretin varlığından söz edilebilecektir.

2. TĂźrleri

a. TaraflarÄą BakÄąmÄąndan Elektronik Ticaret TĂźrleri

i. İşletmeler Arasında Elektronik Ticaret 
(Business to Business-B2B)

Elektronik ticaretin tarafları açısından en çok karşılaşılan türü olup iş-
letmeler arasındaki ticari faaliyetlerin elektronik iletişim araçlarıyla (özel-
likle internet aracılığıyla) gerçekleştirilmesini ifade eder. İşletmeler ara-
sı elektronik ticaret, elektronik pazaryerlerinde gerçekleştirilebildiği gibi 

 32 İsmail Kayar, Ticaret Hukuku (3. Baskı, Seçkin 2015) 88-89: Bu durum ‘ticari iş 
karinesi’ olarak adlandırılmakta ve kural olarak tacirin işi ticari iş sayılmaktadır. Bu 
karinenin aksi tüzel kişi tacirler için ispat edilemez, zira tüzel kişi tacirlerin adi işi ola-
mayacağından her işlemi istisnasız ticari iş niteliğindedir; Gerçek kişi tacirler için ise 
karinenin istisnaları TBK m. 19/1’in ikinci cümlesinde ön görülmüştür. Buna göre 
iki halde gerçek kişi tacirin borcunun ticari olmaması söz konusudur. Gerçek kişi tacir 
işlemi yaptığı anda karşı tarafa işlemin ticari işletmesiyle ilgili olmadığını söylediyse 
veya iş, ticari iş sayılmaya elverişli değilse karine geçerli olmayacaktır.



Äą. bĂślĂźm  | Ar . GĂśr . Merve ARSL AN

— 484 —

Elektronik Veri Değişimi (EDI) aracılığıyla uzun yıllardır kullanılagelen bir 
elektronik ticaret tĂźrĂźdĂźr33.

İşletmeler arası elektronik ticarette genellikle internet ağı kullanı-
lır, bunun yanında diğer firmalarla yapılan faaliyetler için bir kapalı ağ 
(extranet)34 ve firma içi faaliyetler için bir başka kapalı ağ (intranet)35 kul-
lanÄąlabilmektedir.

İşletmeler arası elektronik ticarette iki tarafı da işletme oluşturduğun-
dan tüketici hukukunun koruma alanı dışında kalmaktadır. Bu ticaret tü-
ründe ortaya çıkabilecek uyuşmazlıklara TTK hükümlerine göre çözüm 
yolları aranacak ve gerektiğinde TBK hükümleri de uygulanabilecektir36.

ii. İşletme-Tüketici Arasında Elektronik 
Ticaret (Business to Consumer-B2C)

İşletme ile tüketici arasında, işletmenin tüketiciye mal ve hizmet sunu-
mu çerçevesinde37, elektronik iletişim araçları (özellikle internet) kullanıla-
rak gerçekleştirilen elektronik ticaret türüdür.

İşletme ile tüketici arası elektronik ticaret konumuz açısından önem 
arzeden ticaret türüdür. Tüketicinin bu türün sağladığı zaman tasarrufu, 
ürün çeşitliliği, ürün özelliklerini karşılaştırma imkanı, mekan kısıtının ol-
mayışı sebepleriyle yaygınlaşmış olup pandeminin sebep olduğu fiziki alış-
veriş kısıtı sonucunda tüketici açısından daha fazla tercih edilir hale gel-
miştir. Pandemi döneminde tüketiciler ile işletmeler arasında özellikle web 

 33 Ferman Kaya, E-Ticaret Hukuku ve TĂźketici Hukukundaki UygulamalarÄą (2. BaskÄą, 
Seçkin 2018) 73; Gamze Turan, ‘Elektronik Sözleşmeler ve Elektronik Sözleşmelere 
Uygulanacak Hukukun Tespiti’ (2008) (77) TBB Dergisi 87, 91; Elektronik Veri De-
ğişimi (EDI) hakkında ayrıntılı bilgi için bkz 3-4.

 34 SarĹakçalĹ 35.
 35 SarĹakçalĹ 35.
 36 TTK m. /2: “Mahkeme, hakkında ticari bir hüküm bulunmayan ticari işlerde, ticari örf ve 

âdete, bu da yoksa genel hükümlere göre karar verir”
 37 Sarıakçalı 36: Yazar, bu tür ticareti internet üzerinden mal satışı ve hizmet sunumu ola-

rak tanÄąmlamaktadÄąr.



KoronavirĂźs DĂśneminde GĂźncel Hukuki Meseleler Sempozyumu

— 485 —

siteleri aracılığıyla mal satımına yönelik elektronik sözleşmeler kurularak 
bu ticaret türü yaygınlaştırılmıştır. 

İşletme ile tüketici arası elektronik ticaretin bir tarafını tüketici38 oluş-
turduğundan ve bu tür elektronik ticaret tüketici işlemi39 niteliği taşı-
dığından ortaya çıkan uyuşmazlıklara TKHK uygulanacak ve tüketici 
TKHK’nun sağladığı korumadan yararlanacaktır40.

iii. TĂźketiciler ArasÄąnda Elektronik Ticaret 
(Consumer to Consumer-C2C)

Tüketici ile bir başka tüketici arasında çoğunlukla elektronik pazar-
yerleri dahilinde gerçekleştirilen işlemleri ifade eder41. Genellikle kullanı-
cı konumundaki tüketicinin başka bir tüketiciye kullandığı ürünü ikinci el 
olarak müzayede siteleri aracılığıyla, açık artırma suretiyle satması şeklinde 
karşımıza çıkmaktadır42.

Tüketiciler arası elektronik ticarette iki tarafı da tüketici oluşturdu-
ğundan TKHK kapsamında bir tüketici işlemi söz konusu olmayıp TKHK 
uygulama alanı bulmayacaktır. Ancak işlem elektronik pazaryeri aracılığıy-
la yapılmışsa, bu durumda zarar gören tüketici TKHK’nın sağladığı koru-
madan yararlanabilecektir43.

 38 TKHK m. 3/1-k: “Tüketici: Ticari veya mesleki olmayan amaçlarla hareket eden gerçek 
veya tüzel kişiyi ifade eder.”

 39 TKHK m. 3/1-l: “Tüketici işlemi: Mal veya hizmet piyasalarında kamu tüzel kişileri de 
dâhil olmak ßzere ticari veya mesleki amaçlarla hareket eden veya onun adĹna ya da he-
sabına hareket eden gerçek veya tüzel kişiler ile tüketiciler arasında kurulan, eser, taşıma, 
simsarlık, sigorta, vekâlet, bankacılık ve benzeri sözleşmeler de dâhil olmak üzere her türlü 
sözleşme ve hukuki işlemi ifade eder.”

 40 TKHK m. 2: “Bu Kanun, her türlü tüketici işlemi ile tüketiciye yönelik uygulamaları 
kapsar.”

 41 Kaya 74.
 42 SarĹakçalĹ 36; Kaya 74; Turan 92.
 43 Kaya 75.



Äą. bĂślĂźm  | Ar . GĂśr . Merve ARSL AN

— 486 —

iv. İşletme- Devlet Arasında Elektronik 
Ticaret (Business to Government-B2G)

İşletmeler ile devlet (kamu kuruluşları) arasında elektronik iletişim 
araçlarıyla yapılan ticari faaliyetleri ifade eder. Örneğin alıcı konumundaki 
bir kamu kuruluşunun internet üzerinden ihale açması, satıcı konumunda-
ki işletmenin ihaleye katılarak teklif vermesi ve bu çerçevede satım sözleş-
mesi kurulması işletme ile devlet arasındaki elektronik ticarete örnek ola-
rak verilebilir44.

İşletme ile devlet arasındaki elektronik ticarette tüketici unsuru bu-
lunmadığından bu tür elektronik ticaret konumuz açısından önem arz et-
memekte ve TKHK’nın uygulanması söz konusu olmamaktadır.

v. Devlet-TĂźketici ArasÄąnda Elektronik Ticaret 
(Government to Consumer-G2C)

Devletin (kamu kuruluşlarının) vergi, sigorta, sağlık gibi birçok alanda 
tüketiciye hizmetlerini elektronik iletişim araçlarıyla sunmasını ifade eder. 
Bu elektronik ticaret tĂźrĂźne sigorta primleri ile vergilerin internet Ăźzerin-
den ödenmesi ve e-devlet uygulamaları örnek olarak verilebilir45. Bu işlem-
ler her ne kadar taraflarÄą bakÄąmÄąndan elektronik ticaret tĂźrleri arasÄąnda sa-
yılsa da esasen ticari nitelik taşımamakta46 ve tüketici işlemi kapsamında 
değerlendirilmemektedir, bu sebeple TKHK’ın uygulama alanı dışında kal-
maktadÄąr.

 44 Kaya 75. 
 45 Kaya 75.
 46 Turan 92.



KoronavirĂźs DĂśneminde GĂźncel Hukuki Meseleler Sempozyumu

— 487 —

b. Mal ve Hizmetin Teslimi BakÄąmÄąndan TĂźrleri

i. DolaylÄą Elektronik Ticaret

Dolaylı elektronik ticarette doğrudan elektronik ticarette olduğu gibi 
sözleşme elektronik ortamda elektronik iletişim araçları kullanılarak kurul-
makta, ancak sözleşmeden doğan borçların ifası malın ve paranın elden tes-
limi gibi geleneksel yollarla sağlanmaktadır47. 

Her ürün elektronik ortamda ifa edilmeye uygun olmadığından gü-
nĂźmĂźzde yaygÄąn olan mal ve hizmetin teslimi bakÄąmÄąndan elektronik tica-
ret dolaylı elektronik ticarettir. Web siteleri vasıtasıyla yapılan online alışve-
rişlerde de sözleşme online olarak kurulmaktaysa da tüketicinin karşısında 
bulunan satıcı/sağlayıcı taraf edimin ifasını çoğunlukla geleneksel yollarla 
gerçekleştirmektedir. Ancak elektronik ifası mümkün olan mal ve hizmetler 
bakımından doğrudan elektronik ticaret türü karşımıza çıkmaktadır.

ii. Doğrudan Elektronik Ticaret

Doğrudan elektronik ticarette hem sözleşmenin kurulması hem ifa-
sı elektronik ortamda elektronik iletişim araşlarıyla gerçekleşmektedir48. 
Doğrudan elektronik ticarete örnek olarak kitap, film, bilgisayar program-
ları gibi elektronik ortamda ifa edilebilen malların satımına ve danışmanlık 
hizmetlerine yönelik sözleşmeler verilebilir49.

 47 Sarıakçalı 37; Turan 90; Sözer 21; Gülin Güngör, ‘Yeni Düzenleme Çalışmalarında 
Elektronik Akitlerin Kuruluşu ve Click-wrap Yazılım Lisansı Sözleşmelerinde Hu-
kuk Seçimi Kaydı’ (2002) 51(1) Ankara Üniversitesi Hukuk fakültesi Dergisi 19, 21; 
Özel (Sibel)  610.

 48 SarĹakçalĹ 37; SÜzer 21; Turan 90.
 49 SarĹakçalĹ 37-38; Turan 90.



Äą. bĂślĂźm  | Ar . GĂśr . Merve ARSL AN

— 488 —

D. İnternet Üzerinden Kurulan 
Sözleşmelerin Özellikleri

Pandemi döneminde online alışverişlerde web siteleri aracılığıyla ku-
rulan satım sözleşmelerinin özelikleri üç kalemde toplanarak incelenebilir: 

1. Hazır Olmayanlar Arası Sözleşme Özelliği

Hazırlararasında bir sözleşmeden bahsedebilmek için tarafların aynı 
ortamda veya yakın mesafelerde bulunmaları şart olmayıp aynı anda (doğ-
rudan) ve kesintisiz olarak sağladıkları bir iletişim yoluyla, karşılıklı irade 
beyanlarını (icap-kabul beyanları) gönderebilmeleri ve gönderildiği anda 
beyanları öğrenebilme ve cevap verebilme imkanına sahip olmaları gere-
kir50. Aksi halde sözleşme hazır olmayanlar arası sözleşme niteliği taşıyacak-
tır. Daha açık ifadeyle, iletişim aynı anda ve kesintisiz sağlanamamışsa yani 
bir tarafın icap beyanı gönderildiği anda değil, araya zaman girdikten sonra 
karşı tarafça öğreniliyorsa, aynı şekilde  karşı tarafın kabul beyanı gönderil-
diği anda değil, araya zaman girdikten sonra diğer tarafça öğreniliyorsa bu-
rada hazır olmayanlar arası bir sözleşmeden bahsedilecektir.

Bir sözleşmenin hazırlararası sözleşme veya hazır olmayanlar arası söz-
leşme olmasının önemi sözleşmenin hüküm ve sonuçlarını doğurmaya baş-
layacağı anın tespiti bakımından ortaya çıkmaktadır. Hazırlarası sözleşme-
lerde icaba karşılık kabul beyanının derhal gönderilmesi gerekir (TBK m 
4/1) ve kabul beyanının gönderilmesiyle sözleşme kurulur ve aynı anda 
hüküm ve sonuçlarını doğurur51. Hazır olmayanlar arası sözleşmelerde ise 
icaba karşılık kabul beyanının zamanında ve usulüne uygun olarak gönde-
rilmesi (TBK m 5/1) ve karşı tarafa ulaşması ile sözleşme kurulur ancak 
hüküm ve sonuçlarını karşı tarafın kabul beyanını gönderdiği andan itiba-
ren doğurur52. 

 50 Sağlam 73-74; Şahin 334-335; Sinan Sami Akkurt, ‘Elektronik Ortamda Hizmet Su-
numu ve Buna İlişkin Sözleşmelerin Hukuki Özellikleri’ (2011) 60 (1) AUHFD 19, 
31-32; TBK m 4/2: “Telefon, bilgisayar gibi iletişim sağlayabilen araçlarla doğrudan ile-
tişim sırasında yapılan öneri, hazır olanlar arasında yapılmış sayılır.”

 51 Sağlam 73; Akkurt 31.
 52 Sağlam 73; Akkurt 31; Bayram 351.



KoronavirĂźs DĂśneminde GĂźncel Hukuki Meseleler Sempozyumu

— 489 —

İnternet üzerinden kurulan sözleşme tipleri açısından hazır olma-
yanlar arası ve hazırlarası sözleşme ayrımını inceleyecek olursak; aynı 
anda kesintisiz iletişim sağlayan chat yoluyla kurulan sözleşmeler hazırla-
rası sözleşme niteliğindeyken53, e-mail yoluyla kurulan sözleşmelerde ke-
sintisiz ve doğrudan iletişim söz konusu olmadığından hazır olmayanlar 
arası sözleşme özelliği gösterir54. Web siteleri aracılığıyla kurulan sözleş-
meler kural olarak kabul beyanının sözleşmeyi kabul etme anlamındaki 
ikona tıklanması suretiyle iletilmesi halinde doğrudan diğer tarafa ulaş-
maması, öncelikle web sitenin bilgi işlem sistemine düşmesi ve kontrol-
den geçirilerek diğer tarafa ulaştırılması yani araya zaman girmesi ve ke-
sintisiz iletişim sağlanamaması sebebiyle hazır olmayanlar arası sözleşme 
özelliği gösterir55. Ancak web sitenin aynı anda ve kesintisiz irade beyanı 
sağlama konusunda alt yapısının bulunması durumları bunun istisnasını 
oluşturur ve bu durumda web siteleri aracılığıyla kurulan sözleşmeler ha-
zırlararası sözleşme niteliği gösterecektir56. 

2. Katılmalı Sözleşme Özelliği

TBK m 26’da düzenlenen sözleşme özgürlüğü ilkesi çerçevesinde ta-
raflar sözleşmenin içeriğini kanunda öngörülen sınırlar içinde özgürce be-
lirleyebilirler. Bu sözleşme özgürlüğü ilkesinin istisnasını genel işlem koşul-
ları57 ve katılmalı sözleşmeler oluşturur58. Genel işlem koşulları ve katılmalı 
sözleşmeler benzerlik göstermekle beraber farklı müesseselerdir. 

 53 Şeker 138 (İnternet).
 54 Akkurt 32; Şeker 137 (İnternet).
 55 Akkurt 32; Kabul beyanının bilgi işlem merkezine derhal düşmesini ve devamında 

yapılacak işlem için derhal sayfanın açılmasını kesintisiz iletişim olarak değerlendi-
rerek web siteleri aracılığıyla kurulan sözleşmeleri hazırlararası sözl";"""date"",""2020-09-24T06:41:39Z""
""pdf:PDFVersion"",""1.6""
""xmp:CreatorTool"",""Adobe InDesign 15.1 (Macintosh)""
""pdf:docinfo:title"",""korona sempozyum cilt 2.pdf""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""language"",""tr""
""dc:format"",""application/pdf; version=1.6""
""pdf:docinfo:creator_tool"",""Adobe InDesign 15.1 (Macintosh)""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""korona sempozyum cilt 2.pdf""
""xmp:CreateDate"",""2020-09-24T09:41:39Z""
""modified"",""2020-09-24T06:41:39Z""
""pdf:hasMarkedContent"",""false""
""xmp:ModifyDate"",""2020-09-24T09:41:39Z""
""pdf:docinfo:creator"",""kubra.bostanci""
""meta:author"",""kubra.bostanci""
""trapped"",""False""
""meta:creation-date"",""2020-09-24T06:41:39Z""
""created"",""2020-09-24T06:41:39Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-09-24T06:41:39Z""
""resourceName"",""sempozyum12.pdf""
""xmpMM:DerivedFrom:DocumentID"",""xmp.did:7e700168-8869-432b-a676-6c76dc8a7388""
""Author"",""kubra.bostanci""
""producer"",""Acrobat Distiller 20.0 (Windows)""
""pdf:docinfo:producer"",""Acrobat Distiller 20.0 (Windows)""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""39"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""27"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""access_permission:modify_annotations"",""true""
""dc:creator"",""kubra.bostanci""
""dcterms:created"",""2020-09-24T06:41:39Z""
""Last-Modified"",""2020-09-24T06:41:39Z""
""dcterms:modified"",""2020-09-24T06:41:39Z""
""title"",""korona sempozyum cilt 2.pdf""
""xmpMM:DocumentID"",""xmp.id:c933ead5-b618-4dde-bbc6-303dfa695586""
""Last-Save-Date"",""2020-09-24T06:41:39Z""
""pdf:docinfo:modified"",""2020-09-24T06:41:39Z""
""meta:save-date"",""2020-09-24T06:41:39Z""
""Content-Length"",""559946""
""Content-Type"",""application/pdf""
""xmp:MetadataDate"",""2020-09-21T15:58:51Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""kubra.bostanci""
""pdf:producer"",""Acrobat Distiller 20.0 (Windows)""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""106""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""1534"",""1689"",""2458"",""2408"",""2033"",""2328"",""1993"",""1957"",""2206"",""1977"",""1825"",""1347"",""1615"",""2136"",""2154"",""2347"",""2116"",""1784"",""2286"",""2449"",""3400"",""2356"",""2098"",""2281"",""1960"",""2529"",""2330"",""1693"",""1604"",""2032"",""2304"",""1980"",""2179"",""1922"",""2006"",""1612"",""2162"",""2082"",""1440"",""1852"",""2264"",""2221"",""2072"",""1993"",""1549"",""2407"",""1997"",""2014"",""2005"",""919"",""1739"",""2369"",""1961"",""2504"",""1819"",""1674"",""1903"",""2834"",""2325"",""2007"",""2237"",""2021"",""2256"",""2142"",""1992"",""1914"",""1642"",""2981"",""593"",""1583"",""1243"",""2300"",""1752"",""1025"",""2279"",""1939"",""1870"",""2261"",""2286"",""2725"",""3101"",""3028"",""1814"",""2215"",""2588"",""2516"",""2343"",""2054"",""2108"",""2973"",""2122"",""1912"",""2299"",""2008"",""2680"",""2165"",""2074"",""1938"",""2482"",""2194"",""2111"",""1961"",""1797"",""2089"",""1334"",""0""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""xmpMM:DerivedFrom:InstanceID"",""xmp.iid:ba2f01fb-1220-4058-88af-5ae7d00839b9""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-09-24T06:41:39Z""
";https://scholar.google.ch/scholar?start=940&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098888-386;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Implementation of building information modelling in the Dominican Republic construction industry;AK Silverio Rodriguez ;2020 wlv.openrepository.com;;… 2.3.1 Industry 4.0 .....49 2.3.2 Blockchain .....52 2.3.3 Internet of Things .....64 …;Autres articles;;[PDF] openrepository.com;https://wlv.openrepository.com/bitstream/handle/2436/623695/Silverio_Rodriguez_PhD_thesis_Redacted.pdf?sequence=1&isAllowed=y;"
  

 

 

IMPLEMENTATION OF BUILDING INFORMATION MODELLING IN 

THE DOMINICAN REPUBLIC CONSTRUCTION INDUSTRY 

 

 

 

Ana Karina Silverio Rodriguez 

B. Arch., MSc., PGCert. 

 

 

 

 

 

 

PhD Thesis                                                                                 2020 

  



 

ii 
 

IMPLEMENTATION OF BUILDING INFORMATION MODELLING IN 

THE DOMINICAN REPUBLIC CONSTRUCTION INDUSTRY 

 

 

Ana Karina Silverio Rodriguez 

B. Arch., MSc., PGCert. 

 

A thesis submitted in partial fulfilment of the requirements of the University 

of Wolverhampton for the degree of Doctor of Philosophy (PhD) 

 

May 2020 

 

This work or any part thereof has not previously been presented in any form to the 

University or to any other body whether for the purposes of assessment, publication or 

for any other purpose (unless otherwise indicated). Save for any express 

acknowledgements, references and/or bibliographies cited in the work, I can confirm 

that the intellectual content of the work is the result of my own efforts and of no other 

person. 

The right of Ana Karina Silverio Rodriguez to be identified as author of this work is 

asserted in accordance with ss. 77 and 78 of the Copyright, Design and Patents Act 

1988. At this date, the author owns copyright. 

 

 

Signature  

Date……………………………………………………… 

 

 

12-05-2020 



 

iii 
 

ABSTRACT 

The Dominican Republic (D.R.) is a Caribbean nation whose construction industry is key 
in the economic growth and development of the country; however, the productivity of 
the sector is being affected by inefficient traditional practices. The increased use and 
proven benefits of Building Information Modelling worldwide suggest that its 
implementation could be of great help in decreasing current issues in the Dominican 
construction industry. Nonetheless, there is no empirical work that sets the scene of the 
implementation of BIM in the country to make suggestions for its implementation. 
Therefore, this research aimed to bridge this gap by investigating the status of BIM in 
the D.R. and developing a framework to facilitate its implementation. For this purpose, 
a review of literature on BIM and emerging concepts, processes and technologies was 
undertaken. Furthermore, the initiatives and key players of BIM implementation 
worldwide were studied, which allowed the identification of the critical enabling factors 
for country-wide BIM implementation. A qualitative approach was adopted to carry out 
this research. The qualitative inquiry involved semi-structured interviews and was 
divided into two phases: the preliminary and the main study. In the preliminary study, 
eleven interviews were conducted with construction organisations to appraise and 
document BIM awareness and BIM implementation in the Dominican construction 
industry. In the main study, twenty-eight interviews directed to construction 
organisations were conducted to attain the same objective. This phase of the study also 
included interviews directed to professionals involved with the diffusion of BIM 
knowledge to explore and document the presence of BIM Education in the country, 
from which eight interviews were carried out. The data was analysed with the method 
of content analysis.  

The research concluded that the Dominican Republic is a BIM infant country. Most 

organisations are not implementing BIM, and current BIM approaches are mainly single-

disciplinary, principally in Architecture. Implementation strategies are incomplete, 

primarily focusing on the provision of training to selected staff. Drivers to implement 

BIM in the country include BIM benefits, competitive advantage and pressure from 

external partners. Hitherto, there is only BIM training and different modes of 

dissemination of BIM knowledge in the country. Nonetheless, efforts to integrate BIM 

into university curricula were identified. Challenges hindering the implementation of BIM 

in the country were explored, and initiatives to propel the implementation were 

proposed. A framework for implementing BIM in the Dominican construction industry 

was developed and validated to confirm its suitability for the Dominican construction 

industry. Recommendations for industry practitioners, government, and academics have 

been put forward. This research contributes to the body of knowledge in the area of 

country-wide BIM implementation, BIM education, and the implementation of BIM at an 

organisational level.     



 

iv 
 

TABLE OF CONTENTS 
ABSTRACT ......................................................................................................................... iii 

LIST OF TABLES ................................................................................................................ ix 

LIST OF FIGURES .............................................................................................................. xi 

ABBREVIATIONS .............................................................................................................. xiii 

ACKNOWLEDGEMENTS ...................................................................................................... xv 

DEDICATION ................................................................................................................... xvi 

RESEARCH OUTPUT ........................................................................................................ xvii 

CHAPTER 1: INTRODUCTION ............................................................................................18 

1.1 Statement of the research problem .......................................................................18 

1.1.1 The construction sector in the Dominican Republic ...........................................21 

1.1.2 The need for BIM in the Dominican construction industry..................................22 

1.2 Research aim and objectives .................................................................................24 

1.3 Research questions ..............................................................................................24 

1.4 Methodology .......................................................................................................25 

1.5 Scope and limitations of this research ....................................................................29 

1.6 Structure of the thesis ..........................................................................................31 

CHAPTER 2: LITERATURE REVIEW ON BUILDING INFORMATION MODELLING AND RELEVANT 

EMERGING CONCEPTS, PROCESSES AND TECHNOLOGIES ...................................................35 

2.1 Introduction ........................................................................................................35 

2.2 Introduction to Building Information Modelling .......................................................35 

2.2.1 BIM dimensions .............................................................................................38 

2.2.2 BIM maturity levels ........................................................................................40 

2.2.3 OpenBIM ......................................................................................................46 

2.3 Emerging concepts, processes and technologies related to BIM ...............................48 

2.3.1 Industry 4.0 ..................................................................................................49 

2.3.2 Blockchain ....................................................................................................52 

2.3.3 Internet of Things .........................................................................................64 

2.3.4 Big data ........................................................................................................68 

2.3.5 Digital Twin ..................................................................................................69 

2.3.6 Artificial Intelligence ......................................................................................74 

2.3.7 Need for Open standards ...............................................................................78 

2.4 Summary ............................................................................................................80 

CHAPTER 3: AN OVERVIEW OF THE IMPLEMENTATION OF BIM WORLDWIDE ......................82 



 

v 
 

3.1 Introduction ........................................................................................................82 

3.2 Early BIM adopter countries ..................................................................................83 

3.2.1 United States of America ................................................................................83 

3.2.2 Scandinavia: Finland, Denmark and Norway ....................................................90 

3.2.3 United Kingdom .......................................................................................... 100 

3.2.4 Singapore ................................................................................................... 106 

3.3 Late BIM adopter countries ................................................................................. 109 

3.3.1 Hong Kong ................................................................................................. 109 

3.3.2 China ......................................................................................................... 113 

3.3.3 Latin America .............................................................................................. 115 

3.4 Discussion on the implementation of BIM worldwide ............................................. 127 

3.5 BIM in the Dominican Republic ............................................................................ 135 

3.6 Summary .......................................................................................................... 138 

CHAPTER 4: RESEARCH METHODOLOGY ......................................................................... 140 

4.1 Introduction ...................................................................................................... 140 

4.2 Selection of research approach ........................................................................... 140 

4.2.1 Philosophical worldviews .............................................................................. 141 

4.2.2 Research design .......................................................................................... 147 

4.2.3 Research methods ....................................................................................... 152 

4.3 Research strategy .............................................................................................. 162 

4.3.1 Need for a preliminary study ........................................................................ 162 

4.3.2 Sampling .................................................................................................... 164 

4.3.3 Data analysis process .................................................................................. 169 

4.4 Preliminary study ............................................................................................... 188 

4.4.1 Objectives................................................................................................... 189 

4.4.2 Data collection details .................................................................................. 189 

4.4.3 Interviews design ........................................................................................ 190 

4.4.4 Abductive content analysis ........................................................................... 192 

4.4.5 Impact of the preliminary study to the main study ......................................... 195 

4.5 Main study ........................................................................................................ 197 

4.5.1 Data collection details .................................................................................. 197 

4.5.2 Interviews design ........................................................................................ 200 

4.5.3 Research outcome: Framework..................................................................... 201 



 

vi 
 

4.6 Synopsis of the research strategy ........................................................................ 201 

4.7 Summary .......................................................................................................... 202 

CHAPTER 5: STATUS OF BIM IN THE DOMINICAN CONSTRUCTION INDUSTRY .................. 204 

5.1 Introduction ...................................................................................................... 204 

5.2 Construction organisations characteristics ............................................................ 206 

5.3 BIM Awareness .................................................................................................. 208 

5.4 Status of BIM implementation in the country ........................................................ 209 

5.4.1 Organisations that do not implement BIM ...................................................... 211 

5.4.2 Organisations in transition to implementing BIM and implementing BIM ........... 220 

5.4.3 Organisations implementing BIM .................................................................. 236 

5.5 Summary .......................................................................................................... 247 

CHAPTER 6: BIM EDUCATION IN THE DOMINICAN REPUBLIC ........................................... 250 

6.1 Introduction ...................................................................................................... 250 

6.2 Investigation process ......................................................................................... 251 

6.3 Shortage of BIM experts ..................................................................................... 253 

6.4 Lack of BIM education: Presence of training only .................................................. 255 

6.4.1 Software courses ......................................................................................... 255 

6.4.2 BIM diploma courses ................................................................................... 256 

6.4.3 In-house training and BIM consultancy to companies ..................................... 258 

6.5 Dissemination of BIM knowledge in the country .................................................... 258 

6.6 Plans on BIM education and training .................................................................... 260 

6.7 Summary .......................................................................................................... 262 

CHAPTER 7: CHALLENGES HINDERING THE IMPLEMENTATION OF BIM IN THE DOMINICAN 

CONSTRUCTION INDUSTRY ............................................................................................. 265 

7.1 Introduction ...................................................................................................... 265 

7.2 Inter-organisational/Environmental challenges ...................................................... 266 

7.2.1 Lack of government support ......................................................................... 266 

7.2.2 Lack of client demand .................................................................................. 267 

7.3 Educational challenges ....................................................................................... 268 

7.3.1 Lack of BIM Education ................................................................................. 269 

7.3.2 Deficiencies of current Education delivered in careers related to the construction 

industry 271 

7.4 Economic challenges .......................................................................................... 272 

7.4.1 Economic challenges related to high investment in BIM .................................. 273 



 

vii 
 

7.4.2 Economic challenges related to the organisations ........................................... 275 

7.5 Cultural challenges ............................................................................................. 276 

7.5.1 Characteristics and way of working in the Dominican construction industry ...... 277 

7.5.2 Negative attitudes towards BIM .................................................................... 281 

7.6 Standardisation challenges.................................................................................. 282 

7.6.1 Lack of a BIM mandate ................................................................................ 283 

7.6.2 Lack of standards and regulations in the Dominican construction industry ........ 283 

7.6.3 Deficient systematisation in governmental institutions of the Dominican 

construction industry. ............................................................................................... 284 

7.6.4 Nonexistence of BIM standards ..................................................................... 285 

7.7 Initiatives to propel the implementation of BIM in the Dominican construction industry

 285 

7.7.1 Provision of BIM Education ........................................................................... 286 

7.7.2 Government leadership ................................................................................ 288 

7.7.3 BIM diffusion .............................................................................................. 290 

7.8 Summary .......................................................................................................... 292 

CHAPTER 8: A FRAMEWORK FOR IMPLEMENTING BIM IN THE D.R. ................................... 295 

8.1 Introduction ...................................................................................................... 295 

8.2 Status of BIM in the Dominican Republic .............................................................. 297 

8.3 The need for a framework and framework’s content ............................................. 301 

8.4 Development of a framework to facilitate the implementation of BIM in the Dominican 

Republic ...................................................................................................................... 304 

8.4.1 Framework to guide the integration of BIM into university curricula ................. 306 

8.4.2 Framework to guide the BIM implementation process in construction organisations

 318 

8.4.3 Framework to guide the development of a BIM mandate by government and 

public entities ........................................................................................................... 343 

8.5 Validation of the framework ................................................................................ 352 

8.5.1 Description of the validation process ............................................................. 353 

8.5.2 Validation results ......................................................................................... 355 

8.6 Summary .......................................................................................................... 357 

CHAPTER 9: CONCLUSIONS AND RECOMMENDATIONS ..................................................... 359 

9.1 Introduction ...................................................................................................... 359 

9.2 How the research objectives were achieved ......................................................... 359 

9.3 Key findings ...................................................................................................... 364 



 

viii 
 

9.4 Beneficiaries of the research ............................................................................... 371 

9.5 Contribution to the body of knowledge ................................................................ 371 

9.6 Recommendations ............................................................................................. 374 

9.6.1 Recommendations for industry practitioners .................................................. 374 

9.6.2 Recommendations for the government .......................................................... 376 

9.6.3 Recommendations for academics and further studies ..................................... 377 

REFERENCES .................................................................................................................. 379 

APPENDICES .................................................................................................................. 402 

Appendix 4-A. Cover letter for interviews ....................................................................... 402 

Appendix 4-B. Sample Consent form for interviews ......................................................... 405 

Appendix 4-C. Interview guide to construction organisations used in the preliminary study 407 

Appendix 4-D. Interview guide to construction organisations used in the main study ......... 409 

Appendix 4-E. Interview guide for BIM Education ........................................................... 411 

Appendix 4-F. General information of the participant construction organisations ............... 412 

Appendix 4-G. Open coding comparison......................................................................... 416 

Appendix 4-H. A transcribed version of one interview (directed to construction organisations.

 .................................................................................................................................. 419 

Appendix 8-A. Initial framework for BIM Education ......................................................... 431 

Appendix 8-B. Cover letter for the framework validation process. ..................................... 433 

Appendix 8-C. Framework validation questionnaire online ............................................... 434 

 

 

  



 

ix 
 

LIST OF TABLES 

Table 1.1 Correlational table of the objectives, research questions and chapters of the study ..28 

Table 3.1 BIM standards and guidelines developed in Wisconsin, Ohio and Tennesse..............86 

Table 3.2 Universities of the USA involved with BIM through BIM mandates and the 

development of standards..................................................................................................89 

Table 3.3 Public research organisations in Finland and their BIM initiatives ............................93 

Table 3.4 Summary of key aspects of the implementation of BIM in the early and late BIM 

adopter countries ............................................................................................................ 127 

Table 4.1 Comparison of the major philosophical worldviews considered in this study ........... 145 

Table 4.2 Qualitative, quantitative and mixed methods research ......................................... 149 

Table 4.3 Main characteristics of structured, semi-structured and unstructured interviews ..... 153 

Table 4.4 Total of interviews conducted in this study ......................................................... 169 

Table 4.5 Profile of the interviewees that participated in the preliminary study the interviews 

directed to construction organisations ............................................................................... 190 

Table 4.6 Challenges to BIM implementation identified in the literature ............................... 194 

Table 4.7 Challenges identified deductively in the preliminary study .................................... 195 

Table 4.8 Profile of the interviewees that participated in the interviews directed to construction 

organisations in the main study ........................................................................................ 198 

Table 4.9 Profile of the interviewees that participated in the interviews related to BIM education

 ..................................................................................................................................... 199 

Table 4.10 Research strategy of the preliminary study and main study ................................ 201 

Table 5.1 Classification criteria for Micro, Small, and Medium Enterprises according to the 

Dominican Law 488-08 .................................................................................................... 206 

Table 5.2 Classification of the construction organisations of the study according to their size 207 

Table 5.3 Number of construction companies in the Dominican Republic and their number of 

employees ...................................................................................................................... 207 

Table 5.4 Classification of the construction organisations according to their involvement with 

BIM ............................................................................................................................... 210 

Table 5.5 Training provided for the implementation of BIM in the organisations in transition to 

implementing BIM and implementing BIM ......................................................................... 224 

Table 5.6 Summary of how the organisations prepared to transition/implement BIM ............. 229 

Table 5.7 Standards used for the implementation of BIM in the organisations ...................... 244 

Table 5.8 Summary of Chapter 5 ...................................................................................... 248 

Table 6.1 Differences between education and training ........................................................ 250 

Table 6.2 Results of the online search on BIM education in the D.R. .................................... 252 

Table 6.3 Profile of the participants of the study of BIM Education in the country ................. 253 

Table 6.4 Academic background of the participants and BIM training/knowledge they provide

 ..................................................................................................................................... 254 

Table 7.1 Summary of challenges identified by the interviewees ......................................... 293 

Table 8.1 Challenges for inserting BIM in Academia ........................................................... 308 

Table 8.2 Existing frameworks to assist the insertion of BIM in academia ............................. 312 

Table 8.3 Rationale for framework structure directed to construction organisations .............. 319 

Table 8.4 Key Performance Indicators to measure BIM benefits .......................................... 328 



 

x 
 

Table 8.5 Profile of participants of the framework validation process ................................... 355 

Table 8.6 Recommendations for the framework ................................................................. 357 

 

 

 

  



 

xi 
 

LIST OF FIGURES 

Figure 1.1 Location of the Dominican Republic.....................................................................21 

Figure 1.2 Research process ..............................................................................................27 

Figure 1.3 Structure of the thesis .......................................................................................33 

Figure 2.1 Use of BIM in different stages of the project’s lifecycle .........................................37 

Figure 2.2 BIM Levels by Bew and Richards .........................................................................42 

Figure 2.3 BIM maturity stages ..........................................................................................44 

Figure 2.4 Key technologies and concepts of Industry 4.0 in the construction industry ............51 

Figure 2.5 Example of the use of oracles on-site for smart contracts .....................................61 

Figure 3.1 Levels of BIM adoption in the USA by region ........................................................90 

Figure 3.2 Levels of BIM awareness and implementation in Finland .......................................95 

Figure 3.3 BIM adoption over time in the UK ..................................................................... 104 

Figure 3.4 Singapore's BIM roadmap plan ......................................................................... 107 

Figure 3.5 BIM BR Roadmap ............................................................................................ 118 

Figure 3.6 Plan BIM roadmap ........................................................................................... 121 

Figure 3.7 Presence of BIM in higher education institutions in Chile ..................................... 123 

Figure 3.8 Presence of BIM in Higher education institutions in Chile per discipline ................. 123 

Figure 3.9 Comparison of the results from the National BIM survey in Chile on BIM adoption. 125 

Figure 3.10 Critical enabling factors for country-wide BIM implementation ........................... 135 

Figure 3.11 Core strategies of the Digital Republic programme ........................................... 137 

Figure 4.1 Framework for research ................................................................................... 141 

Figure 4.2 Phases of the research: preliminary study and main study .................................. 163 

Figure 4.3 Organisation of interviews transcripts in NVivo ................................................... 171 

Figure 4.4 Note-taking in NVivo with the tool Annotation .................................................... 173 

Figure 4.5 Organisation of nodes in NVivo ......................................................................... 174 

Figure 4.6 Use of Highlight and Coding Stripes in NVivo to check categories ........................ 176 

Figure 4.7 Tree diagrams created by hand in the abstraction process of content analysis ...... 178 

Figure 4.8 Example of the definition of main categories in the software NVivo ...................... 179 

Figure 4.9 Last branching tree system created in NVivo to study the challenges hindering the 

implementation of BIM in the Dominican construction industry ............................................ 180 

Figure 4.10 Excerpt of interview linked to the literature ...................................................... 182 

Figure 4.11 Excerpt of the literature linked to the interview ................................................ 182 

Figure 4.12 Diagram containing the categories and subcategories to explain the reasons why 

BIM is not implemented in the participant organisations that do not implement BIM (Chapter 5, 

Section 5.4.1.1) .............................................................................................................. 183 

Figure 4.13 Inductive content analysis process of this study assisted by the software NVivo .. 184 

Figure 4.14 Interview guides in the preliminary study......................................................... 191 

Figure 4.15 Structure of interview guide directed to construction organisations .................... 192 

Figure 4.16 Structure of interview guide to evaluate BIM projects ....................................... 192 

Figure 5.1 Reasons why BIM is not implemented in the organisations .................................. 212 

Figure 5.2 Issues affecting current involvement with BIM in organisations in transition to 

implementing BIM and organisations implementing BIM ..................................................... 230 



 

xii 
 

Figure 5.3 Reasons why the scope of BIM is not extended in organisations currently 

implementing BIM ........................................................................................................... 239 

Figure 7.1 Inter-organisational/Environmental challenges to BIM implementation in the D.R. . 266 

Figure 7.2 Education challenges to BIM implementation in the D.R. ..................................... 269 

Figure 7.3 Economic challenges to BIM implementation in the D.R. ..................................... 273 

Figure 7.4 Cultural challenges to BIM implementation in the D.R. ........................................ 277 

Figure 7.5 Standardisation challenges to BIM implementation in the D.R.............................. 283 

Figure 7.6 Initiatives to propel the implementation of BIM in the Dominican construction 

industry.......................................................................................................................... 286 

Figure 7.7 Detailed initiatives to propel the implementation fo BIM in the Dominican 

construction in";"""date"",""2020-10-07T08:39:19Z""
""pdf:PDFVersion"",""1.7""
""xmp:CreatorTool"",""MicrosoftÂŽ Word for Office 365""
""pdf:docinfo:title"",""_""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""language"",""en""
""dc:format"",""application/pdf; version=1.7""
""pdf:docinfo:creator_tool"",""MicrosoftÂŽ Word for Office 365""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""_""
""xmp:CreateDate"",""2020-05-12T12:31:52Z""
""modified"",""2020-10-07T08:39:19Z""
""pdf:hasMarkedContent"",""true""
""xmp:ModifyDate"",""2020-10-07T09:39:19Z""
""pdf:docinfo:creator"",""Ana Karina Silverio RodrĂ­guez""
""meta:author"",""Ana Karina Silverio RodrĂ­guez""
""meta:creation-date"",""2020-05-12T11:31:52Z""
""created"",""2020-05-12T11:31:52Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-05-12T11:31:52Z""
""resourceName"",""Silverio_Rodriguez_PhD_thesis_Redacted.pdf""
""Author"",""Ana Karina Silverio RodrĂ­guez""
""producer"",""MicrosoftÂŽ Word for Office 365""
""pdf:docinfo:producer"",""MicrosoftÂŽ Word for Office 365""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""access_permission:modify_annotations"",""true""
""dc:creator"",""Ana Karina Silverio RodrĂ­guez""
""dcterms:created"",""2020-05-12T11:31:52Z""
""Last-Modified"",""2020-10-07T08:39:19Z""
""dcterms:modified"",""2020-10-07T08:39:19Z""
""title"",""_""
""xmpMM:DocumentID"",""uuid:1C86151D-694B-47BB-9475-E8E4B2F8789A""
""Last-Save-Date"",""2020-10-07T08:39:19Z""
""pdf:docinfo:modified"",""2020-10-07T08:39:19Z""
""meta:save-date"",""2020-10-07T08:39:19Z""
""Content-Length"",""5515209""
""Content-Type"",""application/pdf""
""xmp:MetadataDate"",""2020-10-07T09:39:19Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Ana Karina Silverio RodrĂ­guez""
""dc:language"",""en-US""
""pdf:producer"",""MicrosoftÂŽ Word for Office 365""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""436""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""262"",""1003"",""3082"",""3854"",""3834"",""3672"",""3598"",""2226"",""4581"",""233"",""4561"",""3437"",""1521"",""1609"",""1112"",""70"",""567"",""1483"",""1678"",""1670"",""851"",""1724"",""1724"",""1168"",""1449"",""1697"",""230"",""2410"",""1765"",""1702"",""1609"",""1626"",""526"",""1359"",""1622"",""1839"",""674"",""1688"",""1753"",""1699"",""1523"",""856"",""1746"",""1420"",""1660"",""1631"",""1587"",""1613"",""1821"",""1410"",""1644"",""1677"",""1778"",""1674"",""1600"",""1807"",""1544"",""1524"",""1582"",""1627"",""1265"",""1731"",""1420"",""1654"",""1600"",""1503"",""1533"",""1670"",""1594"",""1837"",""1593"",""1402"",""1603"",""1574"",""1588"",""1600"",""1546"",""1587"",""1822"",""1833"",""489"",""1538"",""1660"",""1452"",""1506"",""1569"",""1679"",""1559"",""1656"",""1399"",""1412"",""1563"",""1754"",""1618"",""1252"",""1752"",""1363"",""1626"",""1497"",""1695"",""1767"",""1678"",""1673"",""1309"",""1505"",""1624"",""1726"",""1711"",""1245"",""1793"",""1665"",""1676"",""1577"",""1655"",""1781"",""1541"",""1740"",""1826"",""1581"",""1730"",""1392"",""1430"",""829"",""1632"",""1254"",""1635"",""2203"",""2279"",""2239"",""1706"",""1820"",""1713"",""1721"",""1689"",""1028"",""1506"",""1685"",""1739"",""1042"",""1469"",""928"",""1873"",""1671"",""1730"",""1860"",""2045"",""1548"",""1658"",""1980"",""2069"",""1750"",""1309"",""2479"",""1680"",""1516"",""1350"",""1581"",""1548"",""1576"",""1642"",""1759"",""1607"",""1021"",""1549"",""1501"",""1603"",""1856"",""1680"",""1654"",""1592"",""985"",""1436"",""942"",""1170"",""1236"",""447"",""1566"",""238"",""508"",""470"",""1212"",""166"",""615"",""508"",""1610"",""1472"",""1705"",""1425"",""1116"",""1373"",""1398"",""1106"",""1729"",""1714"",""1412"",""1429"",""1352"",""1497"",""1601"",""1432"",""1758"",""1610"",""354"",""1574"",""1538"",""1546"",""1544"",""1710"",""1463"",""1832"",""1616"",""824"",""1514"",""1767"",""1494"",""1687"",""1732"",""1591"",""1810"",""1355"",""1502"",""1668"",""1603"",""1837"",""1523"",""1686"",""1495"",""1660"",""1643"",""958"",""1614"",""1712"",""1493"",""1609"",""1580"",""1609"",""1782"",""1893"",""829"",""1798"",""1850"",""1406"",""1596"",""1753"",""1637"",""1343"",""1564"",""1709"",""1143"",""1499"",""1623"",""1795"",""1588"",""1936"",""1510"",""1457"",""1655"",""1698"",""1922"",""1601"",""1690"",""1571"",""1635"",""223"",""1453"",""1343"",""1699"",""1520"",""831"",""1414"",""1776"",""1557"",""1154"",""1432"",""1695"",""1700"",""820"",""1668"",""1510"",""1658"",""1723"",""1452"",""944"",""1632"",""1467"",""1038"",""1469"",""1643"",""1783"",""1297"",""1507"",""653"",""1917"",""251"",""1500"",""1574"",""1296"",""119"",""727"",""1609"",""1432"",""1411"",""1232"",""1645"",""1620"",""1612"",""1521"",""2697"",""1900"",""1410"",""1495"",""1713"",""2114"",""1794"",""673"",""1569"",""1532"",""1354"",""1245"",""1514"",""157"",""1642"",""1365"",""1379"",""1665"",""1346"",""1540"",""1566"",""1306"",""1404"",""893"",""1757"",""1562"",""1667"",""1667"",""1601"",""1718"",""1373"",""1357"",""1316"",""1223"",""1146"",""1446"",""1506"",""140"",""1629"",""1697"",""1699"",""361"",""1735"",""1609"",""1629"",""1669"",""1702"",""1405"",""1467"",""1642"",""951"",""1412"",""1759"",""1557"",""1496"",""1583"",""1671"",""1653"",""1641"",""1537"",""1553"",""1609"",""1492"",""1452"",""1711"",""1503"",""1467"",""1663"",""1534"",""1407"",""689"",""2730"",""2725"",""2584"",""2692"",""2520"",""2582"",""2593"",""2867"",""2371"",""2783"",""2771"",""2951"",""2978"",""2878"",""2757"",""2905"",""2430"",""2707"",""2553"",""2845"",""2741"",""3062"",""590"",""1131"",""2493"",""1329"",""1723"",""511"",""1399"",""949"",""1373"",""747"",""855"",""2389"",""2615"",""2244"",""2092"",""2338"",""1946"",""1507"",""1891"",""1474"",""1841"",""1815"",""1928"",""1856"",""1927"",""1792"",""2333"",""2227"",""2336"",""254"",""2674"",""823"",""2110"",""64"",""8"",""10""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-05-12T11:31:52Z""
";https://scholar.google.ch/scholar?start=930&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098831-259;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Mind the composition: birthday bound attacks on EWCDMD and SoKAC21;M Nandi ; Annual International Conference on the Theory and …, 2020  Springer;;"… In CRYPTO'19, Chen et al … Motivated by the above two attacks exploiting the composition nature,

we consider some generic relevant composition based constructions of ideal primitives (possibly

in the ideal permutation and random oracle model) and present birthday bound …";Cité 1 fois;Les 2 versions;[PDF] iacr.org;https://eprint.iacr.org/2020/236.pdf;"
Mind the Composition: Birthday Bound Attacks
on EWCDMD and SoKAC21

Mridul Nandi

Indian Statistical Institute, Kolkata, India
mridul.nandi@gmail.com

Abstract. In an early version of CRYPTO’17, Mennink and Neves pro-
posed EWCDMD, a dual of EWCDM, and showed n-bit security, where
n is the block size of the underlying block cipher. In CRYPTO’19, Chen
et al. proposed permutation based design SoKAC21 and showed 2n/3-
bit security, where n is the input size of the underlying permutation. In
this paper we show birthday bound attacks on EWCDMD and SoKAC21,
invalidating their security claims. Both attacks exploit an inherent com-
position nature present in the constructions. Motivated by the above
two attacks exploiting the composition nature, we consider some generic
relevant composition based constructions of ideal primitives (possibly in
the ideal permutation and random oracle model) and present birthday
bound distinguishers for them. In particular, we demonstrate a birthday
bound distinguisher against (1) a secret random permutation followed
by a public random function and (2) composition of two secret random
functions. Our distinguishers for SoKAC21 and EWCDMD are direct con-
sequences of (1) and (2) respectively.

Keywords: PRF, birthday bound, SoKAC21, EWCDMD.

1 Introduction

Motivated from DES block cipher design, Luby and Rackoff [LR88] formally
analyzed a paradigm of constructing a pseudorandom permutation (PRP) from
a pseudorandom function (PRF). However, the opposite trend is more popular
due to wide availability of block ciphers (modeled to be pseudorandom permu-
tations). So pseudorandom functions are traditionally built upon block ciphers.
A straightforward application of the classical PRP-PRF switch [Sho04] gives
security up to the birthday bound. However, in view of lightweight block ci-
phers [BPP+17,BKL+07] this bound may not be suitable. For example, a birth-
day bound secure PRF construction based on DES (64-bit block cipher) may
be broken in approximately 232 bits of data. In fact, Bhargavan and Leurent
[BL16] performed practical attacks on TLS and OpenVPN when a 64-bit block
cipher is used. To resist such attacks, several beyond birthday bound secure
constructions have been proposed. This includes popular constructions such as
sum of permutations (or SoP in short) [HWKS98,Pat08,DHT17,BN18b], trunca-
tion of permutation [HWKS98,BN18a], EDM type constructions [CS16,CS18],



2 Mridul Nandi

Sum-ECBC [Yas10], Pmac Plus [Yas11], 3Kf9 [ZWSW12], DbHtS [DDNP18]
and 1kPmac Plus [DDN+17a].

Apart from block cipher, the recent trend of using ideal (unkeyed) permuta-
tion has also motivated several pseudorandom functions from ideal permutation.
Sponge-based PRF [BDPVA11b,CDH+12,BDPVA11a,ADMVA15] and Farfalle
[BDH+17] are two such examples of PRF from ideal permutations. Recently,
Chen et al. in Crypto 2019 [CLM19] considered permutation versions of SoP
and EDM-dual. Depending on the choice of the keys and the permutation, some
of the constructions provide birthday bound security, while some achieve be-
yond the birthday bound. They have also claimed tight security by showing
some matching attacks.

1.1 Some Beyond Birthday Bound Constructions

Most of the constructions mentioned above are sequential in nature. Some of
these constructions can be viewed as composition of two simpler constructions.
For a permutation π, we denote π(x) ⊕ x as π⊕(x) (this is known as Davies-
Meyer function which has been used to define hash functions in case of public
permutation). Let π1 and π2 be two independent keyed random permutations
over {0, 1}n.

EDM and Its Dual. For a message m ∈ {0, 1}n, we define

EDM(m) = π2(π⊕1 (m)) (1)

In other words, EDM (encrypted Davies-Meyer) is a composition function π2◦π⊕1 .
Here π1 and π2 are two independently keyed block ciphers (or random permuta-
tions). Dual version of EDM (denoted as EDMD) is defined as the composition
in the other direction:

EDMD(m) = π⊕1
(
π2(m)

)
.

In [CS16,CS18] it has been proved that EDM is PRF secure up to 22n/3

queries (i.e. 2n/3-bit secure). Later in Crypto 2017 [DHT17], security of EDM
is shown to be at least 3n/4-bit using χ2-method. Independently, Mennink and
Neves in [MN17] proved that EDM and EDMD have n-bit PRF security using
the generalized version of Patarin’s mirror theory [Pat08]. However, the proofs
of mirror theory are extremely sketchy and contain several unverified gaps.

EWCDM and Its Dual. The previous constructions can only process n-bit mes-
sage. With the help of universal hash H, one can extend the message space,
using the Wegman Carter paradigm [WC81]. We now recall the construction
EWCDM [CS16] and its dual version EWCDMD [MN17] (see Fig. 1.1). For a
nonce (which should be fresh for every execution of MAC) ν ∈ {0, 1}n and a
message m ∈M, we define

EWCDM(ν,m) = π2(π⊕1 (ν)⊕H(m)) (2)

EWCDMD(ν,m) = π⊕2 (π1(ν)⊕H(m)) (3)



Title Suppressed Due to Excessive Length 3

ν π1
v

H(M)

⊕ π2
x y

c⊕

Fig. 1.1: EWCDMD: Wegman-Carter followed by Davies-Meyer.

In [CS16], Cogliati and Seurin proved 2n/3-bit PRF (pseudorandom function)
and MAC (message authentication) security for EWCDM in a nonce respecting
model.

SoKAC21. So far we have considered constructions based on secret keyed primi-
tives. Very recently, Chen et al. in CRYPTO 2019 [CLM19] proposed a pseudo-
random function, called SoKAC21 (see Fig 1.2), based on ideal public permuta-
tions. It is designed for small message space and claimed to be achieving beyond
birthday bound security. For an n-bit message m, and two ideal permutations
πpub
1 , πpub

2 , and an n-bit secret key K, we define

SoKAC21(K,m) = πpub
2

(
πpub
1 (m⊕K)⊕K

)
⊕ πpub

1 (m⊕K)⊕K (4)

m

K

⊕ π1
u v

K

⊕ π2
x y

c⊕

Fig. 1.2: SoKAC21 - Sum of Key Alternating Cipher with a single key.

This construction can be viewed as a composition of Even Mansour followed
by Davies-Meyer. We note that an equivalent view (due to which it is named sum
of key alternating cipher) of the above construction is π2(v⊕K)⊕π1(m⊕K)⊕K
where v = π1(m⊕K).

1.2 Composition Constructions and Our Contribution

All the constructions mentioned in the previous subsection can be viewed as
composition of ideal primitives or some functions derived from ideal primitives.

Public and Secret Ideal Primitives. Let γ←$Func(n) and π←$Perm(n)
denote n-bit random function and random permutation respectively. A random
function or permutation is called public if adversary has direct access to these



4 Mridul Nandi

primitives or their inverses whenever exist, in addition with concerned construc-
tions based on these primitives. In this case we call the adversarial model ideal
function or ideal permutation model. We denote the public random function and
permutation as γpub and πpub respectively.

When the ideal primitives are secret (i.e. cannot accessed directly by an ad-
versary), we denote them as γsec and πsec. Note that secret primitives appears
when a keyed function (e.g. a keyed compression function) or a keyed permuta-
tion (e.g., a block cipher) is replaced by the ideal counterpart through hybrid
argument.

We use subscript notation to denote independent copies of the primitives.
For example, π1, π2 are two independent random permutations (either secret or
public which would be understood from the superscript notation).

Our Contribution. In this paper, we first analyze the PRF or PRP construc-
tions g ◦ f where

f, g ∈ {γpub, γsec, πsec}.

Due to a trivial reason1 we exclude πpub. Moreover, we must assume that at
least one of the functions is secret. In this paper, we show birthday bound PRF
attack on (1) γsec2 ◦ γsec1 and (2) γpub ◦ πsec. The idea behind the attacks for
these constructions are simple. For γsec2 ◦ γsec1 we expect more collisions than
perfect random function. In other words, we have higher probability of realizing
collision on γsec2 ◦ γsec1 than that of γsec. For the second construction, we observe
the outputs of public function γpub and outputs of γpub ◦ πsec (or γsec in case of
ideal oracle). We show that the probability of collision between these two lists
is higher in case of the real world than the ideal world. In the real construction,
collision can happen in two ways – (1) an output of πsec collides with an input
of public function call Îłpub, (2) accidental collision (which happens in the final
outputs without having collision among inputs).

Birthday Attack on EWCDMD. We exploit the attack idea of γsec2 ◦ γsec1 to
describe a PRF attack against EWCDMD in query complexity 2n/2. In an early
version of CRYPTO 20172, Mennink and Neves [MN17] showed almost n-bit
PRF security for EWCDMD. So our result invalidates the initial claim of the
construction.

The main idea of the attack is simple. EWCDMD can be viewed as a compo-
sition of two keyed non-injective functions (and so it follows birthday paradox),
namely π⊕2 and a function f mapping (ν,m) to π1(ν)⊕H(m). Thus, we expect
that the collision probability of the composition π⊕2 ◦ f is almost double of the
collision probability for the random function. So, by observing a collision we can

1 Note that if the outer function g is πpub or the inner function f is πpub then the
composition is essentially reduced to a single primitive. An adversary can always
uncover πpub by making calls to πpub and (πpub)−1.

2 The early version can be accessed on ePrint 2017/473 posted on 28-May-2017. This
paper was initially accepted in CRYPTO 2017. Later, after finding the flaw in the
analysis, authors removed this analysis from the final proceeding.



Title Suppressed Due to Excessive Length 5

distinguish EWCDMD from a random function. Note that EWCDM is a composi-
tion of a permutation and a non-injective keyed function. Hence our observation
is not applicable to it.

Birthday Attack on SoKAC21. Similarly, we exploit the attack idea of γpub ◦
πsec to have birthday bound PRF attack on SoKAC21. In this construction we
have π⊕2 instead of public random function. However, with a careful analysis (and
using the recent result on sum of permutation) we can have birthday attack on
SoKAC21. This again violates the beyond birthday security claimed in [CLM19].

2 Preliminaries

Notation. For n ∈ N, [n] denotes the set {1, 2, . . . , n}. For n, k ∈ N, such that
n ≥ k, we define the falling factorial (n)k := n!/(n−k)! = n(n−1) · · · (n−k+1).
For a ∈ N, an a-tuple (x1, x2, . . . , xa) and also a multi-set {x1, . . . , xa} is simply
denoted as xa (this should be clear from the context). For any set X, (X)a
denotes the set of all xa so that x1, . . . , xa are distinct. We call all those xa

element-wise distinct. Note, |(X)q| = (|X|)q.
The set of all functions from X to Y is denoted as Func(X,Y) and the

set of all permutations over X is denoted as Perm(X). We use shorthand nota-
tions Perm(n) (or Func(n)) to denote the set of all permutations (or functions
respectively) from {0, 1}n to itself.

For a finite set X, X←$X denotes the uniform and random sampling of X
from X. We write X1, . . . ,Xa←$D when Xi’s are chosen uniformly and inde-
pendently from the set D. In other words, X1, . . . ,Xa is a random with replace-
ment sample. We write X1, . . . ,Xa←worD when Xi’s are chosen randomly from
D in without replacement manner. More precisely, for all element-wise distinct
xa ∈ (D)a,

Pr(X1 = x1, . . . ,Xa = xa) =
1

(|D|)a
.

2.1 Statistical Distance

Let X,Y be two random variables over a sample space S. Then the statistical
distance between X and Y is defined as

D(X,Y) :=
1

2

∑
a∈S
|Pr(X = a)− Pr(Y = a)|.

An equivalent definition of statistical distance is the following:

D(X,Y) = max
E⊆S
|Pr(X ∈ E)− Pr(Y ∈ E)|.

To see why it is an equivalent definition, we first note that the maximization
holds for E1 = {a ∈ S : Pr(X = a) > Pr(Y = a)}. From the definition of E1, we



6 Mridul Nandi

can write the sum
∑
a∈S |Pr(X = a) − Pr(Y = a)| (after splitting over E1 and

Ec1) as ∑
a∈E1

(Pr(X = a)− Pr(Y = a)) +
∑
a∈Ec

1

Pr(Y = a)− Pr(X = a)

= Pr(X ∈ E1)− Pr(Y ∈ E1) + Pr(Y ∈ Ec1)− Pr(X ∈ Ec1)

= 2
(
Pr(X ∈ E1)− Pr(Y ∈ E1)

)
.

Thus we have established the equivalence.

Lemma 1 (replacement lemma). Let X,Y be two random variables over a
sample space S and Z be independent with X and Y sampled from T. Let E ⊆
S×T then

|Pr((X,Z) ∈ E)− Pr((Y,Z) ∈ E)| ≤ D(X,Y). (5)

Proof. For every z, let Ez = {s ∈ S : (s, z) ∈ E}. Then by independence, we
have

1. p1 := Pr((X,Z) ∈ E) =
∑
z Pr(Z = z) ¡ Pr(X ∈ Ez) and similarly,

2. p2 := Pr((Y,Z) ∈ E) =
∑
z Pr(Z = z) ¡ Pr(Y ∈ Ez).

Hence,

|p1 − p2| = |
∑
z

Pr(Z = z) · Pr(X ∈ Ez)−
∑
z

Pr(Z = z) ¡ Pr(Y ∈ Ez)|

≤
∑
z

Pr(Z = z) · |Pr(X ∈ Ez)− Pr(Y ∈ Ez)|

≤
∑
z

Pr(Z = z) ¡ D(X,Y)

= D(X,Y)

2.2 Sum of Without Replacement Samples

Let D be a set of size N . In [DHT17] it has been proved that sum of two indepen-
dent without replacement sample almost behaves like one with replacement sam-
ple. More precisely, let X1, . . . ,Xa←worD, Y1, . . . ,Ya←worD, Z1, . . . ,Za←$D

and Xa, Ya are independent. Define Wi = Xi ⊕ Yi for all i ∈ [a]. Then, in
[DHT17] it is shown 3 that

D(Za,Wa) ≤ 4a

N
. (6)

Due to Lemma 1, we can simply replace sum of random without replacement
sample involved in an event by the random sample at the cost of probability
4a/N . We use this idea of replacement while we analyze SoKAC21 construction.

3 The original bound is 1.5a
N

+ 3
√
a

N
which is less than the bound we consider here for

all a ≥ 3. For a = 2, one can easily establish the bound.



Title Suppressed Due to Excessive Length 7

2.3 Security Definitions

Random Function and Random Permutation. γ←$Func(X,Y) is said to
be the random function from the set X to Y. Similarly, π←$Perm(Y) is said
to be the random permutation over the set Y. In this paper we mostly use the
set X = Y = {0, 1}n.

Keyed Function and Permutation. A keyed function with key space K,
domain X and range Y is a function F : K ×X → Y and we denote F(K,X)
by FK(X). Similarly, a keyed permutation with key space K and domain X is
a mapping E : K ×X → X such that for all key K ∈ K, X 7→ E(K,X) is a
permutation over X and we denote EK(X) for E(K,X).

PRF. Given an oracle algorithm A with oracle access to a function from X to
Y, making at most q queries, running time at most t and outputting a single
bit, we define the prf-advantage of A against the family of keyed functions F as

AdvPRF
F (A) := |Pr(K ←$K : AFK = 1)− Pr(γ←$Func(X,Y) : Aγ = 1)|.

PRP. Given an oracle algorithm A with oracle access to a permutation of X,
making at most q queries, running time at most t and outputting a single bit,
we define the prp-advantage of A against the family of keyed permutations E as

AdvPRP
E (A) := |Pr(K ←$K : AEK = 1)− Pr(π←$Perm(X) : Aπ = 1)|.

PRF and PRP in Ideal Model. Some keyed constructions uses ideal public
primitive such as a random function and a random permutation. Let P1, . . . , Pr
be such all primitives used for a keyed construction FK := FP1,...,Pr

K . Let PÂąi
denotes both Pi and its inverse P−1i . We define PRF and PRP-advantage in the
public primitive model as follows.

AdvPRF
F (A) := |Pr(AFK ,P

Âą
1 ,...,P

Âą
r = 1)− Pr(Aγ,P

Âą
1 ,...,P

Âą
r = 1)|.

In the above two probabilities, K, Îł, P1, . . . , Pr are all independently drawn.
Similarly, we define PRP-advantage in public model as

AdvPRP
F (A) := |Pr(AFK ,P

Âą
1 ,...,P

Âą
r = 1)− Pr(Aπ,P

Âą
1 ,...,P

Âą
r = 1)|.

Almost XOR Universal Hash Function. A keyed hash function HK : D→
R is called ε-AXU (almost xor universal) if Pr(HK(m) ⊕HK(m′) = δ) ≤ ε for
all m 6= m′ and for all δ. Here the probability is computed under randomness of
the key chosen uniformly from the key space.

3 Collision Probability

Let D be a set of size N . We quickly recall collision probability for a uniform
random sample X1, . . . ,Xa←$D. For any positive integers a ≤ N , we write



8 Mridul Nandi

dpN (a) := (N)a
Na and cpN (a) := 1−dpN (a). When N is understood from the con-

text, we skip the notation N . If a is very small compared to N (i.e. a/N ≈ 0), a
precise estimation of dpN (a) is e−a(a−1)/2N . This follows from the approximation
1− ε ≈ e−ε for very small positive ε. In fact the error term |e−ε − (1− ε)| is in
the order O(Îľ2).

Given a list L of elements x1, . . . , xa, we write Dist(L) if xi’s are distinct.
Otherwise, we write Coll(L).

Lemma 2 (collision probability). Let D be a set of size N . Let X1, . . . ,Xa←$D

and let L denote the list containing Xi’s, 1 ≤ i ≤ a. Then,

1. Pr(Dist(L)) = dpN (a).
2. Pr(Coll(L)) = cpN (a) ≤ a2/2N .

We skip the proof as it is straightforward conclusion from the definition. The
second statement follows from the union bound.

Now we compute probability for having a collision between two lists. We say
that there is a collision between two lists, denoted as LColl(L1,L2) if the lists
are not disjoint.

Lemma 3 (list-collision probability for without replacement sample).
Let X1, . . . ,Xp←worD and Y1, . . . ,Yq ←worD such that Xp and Yq are indepen-
dent. Then,

Pr(LColl(Xp,Yq)) = 1− (N − p)q
(N)q

Proof. We compute the complement event, i.e., Xp and Yq are disjoint. The
conditional probability of the complement event conditioning on Xp = xp is
(N−p)q
(N)q

. This can be easily seen as the number of choices of Yq is exactly (N−p)q.
As the conditional probability is independent of choice of xp, the unconditional

probability is also same as
(N−p)q
(N)q

. This completes the proof. ut

We denote the the probability 1− (N−p)q
(N)q

as lcpworN (p, q) (or simply lcpwor(p, q)

whenever N is understood from the context).
When L1 := Xp and L2 := Yq, where X1, . . . ,Xp,Y1, . . . ,Yq ←$D, we denote

the list-collision probability Pr(LColl(L1,L2)) as lcp$N (p, q) (or simply lcp$(p, q)
whenever N is understood from the context). Here D is a set of size N .

Lemma 4 (list-collision probability for random samples). For all positive
integers p, q, we have

|lcp$N (p, q)− 1 +
(
1− q

N

)p| ≤ 2cpN (p). (7)

(When p is small compared to
√
N , the collision probability cpN (p) is almost zero and

in that case, the above result says that 1−
(
1− p

N

)q
is a very good approximation of

lcp$N (p, q).)



Title Suppressed Due to Excessive Length 9

Proof. Let X1, . . . ,Xp,Y1, . . . ,Yq ←$D and E denote the event Dist(Xp). So
Pr(E) = dpN (p). Fix any distinct xp. Then, the list collision LColl(xp,Yq) holds
with probability 1− (1− p

N )q. Now,

Pr(LColl(Xp,Yq)) = Pr(LColl(Xp,Yq) ∧ E) + Pr(LColl(Xp,Yq) ∧ Ec)

=
∑

xp∈(D)p

Pr(LColl(xp,Yq) ∧ Xp = xp) + Pr(LColl(Xp,Yq) ∧ Ec)

= (1− (1− p

N
)q)×

∑
xp∈(D)p

Pr(Xp = xp) + Pr(LColl(Xp,Yq) ∧ Ec)

= (1− (1− p

N
)q)× Pr(E) + Pr(LColl(Xp,Yq) ∧ Ec)

= (1− (1− p

N
)q)× (1− Pr(Ec)) + Pr(LColl(Xp,Yq) ∧ Ec)

Note that in our notation, Pr(LColl(Xp,Yq)) = lcp$N (p, q). Hence,

|lcp$N (p, q)− 1 +
(
1− q

N

)p| = |(1− (1− p

N
)q)× Pr(Ec) + Pr(LColl(Xp,Yq) ∧ Ec)|

≤ 2 · Pr(Ec).

The lemma follows from the definition that Pr(Ec) = cpN (p). ut

4 Birthday Attack on Composition of Ideal Primitives

In this section, we analyze compositions of ideal primitives. We recall that
γ←$Func(n) and π←$Perm(n) denote n-bit random function and random per-
mutation respectively. We follow the notations described in Sect. 1.2. Here ≡ is
used to mean two systems equivalent (i.e. the probabilistic behavior of interac-
tion for any adversary would be same for both).

1. It is easy to verify that πsec ◦ γsec ≡ γsec ◦ πsec ≡ γ and πsec
1 ◦ πsec

2 ≡ π. In
[MS15] πsec ◦ πsec (iterated random permutation) has been analyzed and it
almost behaves as πsec with a maximum distinguishing advantage O(q/2n)
where q is the number of queries. Authors of [MS15,Nan15] have actually
analyzed a more general construction πsec ◦ · · · ◦ πsec (applied r times).

2. In [BDD+17], γsec ◦ γsec (iterated random function) has also been ana-
lyzed. This is equivalent to Îłsec with a maximum distinguishing advantage
O(q2/2n). Authors of [BDD+17] actually analyzed more general construction
γsec ◦ · · · ◦ γsec (applied r times). The main idea behind the distinguishing
attack is that the collision probability of an iterated random function is more
probable than that of a random function.

Using a similar argument, we can show that γsec2 ◦ γsec1 can be distinguished
from Îłsec by making 2n/2 queries. Let x1, . . . , xq be q queries and let y1, . . . , yq



10 Mridul Nandi

be the responses. In case of the real world, yi = Îłsec2 (zi) where zi = Îłsec1 (xi).
Let Âľ := cp2n(q). Now,

Pr(Coll(yq)) = Pr(Coll(zq)) + Pr(Coll(yq) | Dist(zq))× Pr(Dist(zq))

= µ+ µ(1− µ)

Let A return 1 if it observes a collision among outputs. Thus, the distin-
guishing advantage of the adversary is at least µ(1 − µ). When q = 2n/2,
cp(q) ≈ 1− 1√

e
and hence advantage is 1√

e
× (1− 1√

e
) which is at least 0.2.

One can also choose q (which should be again O(2n/2)) such that µ ≈ 1/2
and hence the advantage would be about 0.25.

Same attack can be applied to γsec ◦ γpub and γpub ◦ γsec as if the adversary
does not take an advantage of accessing the public random function Îłpub.

3. Let us consider the construction πsec ◦ γpub. An adversary A first finds a
collision pair (m,m′) of γpub by making 2n/2 queries to it. Then, πsec ◦
γpub(m) = πsec ◦ γpub(m′). Clearly, in the ideal world, γ(m) = γ(m′) holds
with probability 2−n. So A is a PRF-distinguisher against πsec ◦γpub making
about 2n/2 queries to the public random function. The same attack is also
applied to γsec ◦ γpub.

4. Although γsec◦πsec is equivalent to a random function, we have the following
birthday bound complexity PRF-attack on γpub ◦ πsec (replacing the outer
layer of secret random function by public random function). Here we ex-
ploit the public access of Îłpub (since otherwise it is equivalent to a random
function).

PRF Distinguisher AO,Îłpub

1 : x1, . . . , xp ←wor {0, 1}n

2 : queries x1, . . . , xp to Îłpub

3 : yi = γpub(xi), i ∈ [p] be the responses

4 : for i ∈ [q], i is queried to O

5 : let ci = O(i), i ∈ [q] be the responses

6 : if ∃i, j, yi = cj

7 : return 1

8 : else

9 : return 0

Fig. 4.1: Distinguisher for composition construction γpub ◦ πsec .

Let E denote the event that there are i, j such that yi = cj .



Title Suppressed Due to Excessive Length 11

Ideal World: In the ideal world we have c1, . . . , cq, y1, . . . , yp←$ {0, 1}n.
So

Pr(E) = lcp$(p, q) = Âľ (say).

Real World: In the real world, let zi = πsec(i). So ci = γpub(zi). Thus,
z1, . . . , zq ←wor {0, 1}n independent of xp. Now, we write the event E as the
disjoint union (denoted as t)

LColl(zq, xp) t
(
LColl(zq, xp) ∧ LColl(cq, yp)

)
.

Given that zq is distinct from xp, we have c1, . . . , cq, y1, . . . , yp←$ {0, 1}n.
Now, Pr(LColl(zq, xp)) = lcpwor(p, q) := Âľ1 (say). Then,

Pr(E) = µ1 + (1− µ1)µ.

So, the distinguishing advantage of our adversary is µ1(1−µ). By Lemma 3
and Lemma 4, the distinguishing advantage is at least

(1− (2n − p)q
(2n)q

)×
(
(1− p

2n
)q − 2cp2n(q)

)
. (8)

Further, we have

(2n − p)q
(2n)q

=

q−1∏
i=0

(1− p

2n − i
)

≤ (1− p

2n
)q

≤ 1− pq

2n
+

pq2

22n+1
.

The last inequality follows from the following fact:

(1− x)q ≤ 1−
(
q

1

)
x+

(
q

2

)
x2, 0 ≤ x ≤ 1.

We also have (1 − p
2n )q ≥ 1 − pq

2n . By substituting the above inequalities in
Eq. 8, the distinguishing advantage is at least

(1− pq

2n
− q2

2n
)× pq

2n
× (1− q

2n+1
).

Now if we choose p = q =
√

2n/3 then the advantage is at least 1
9 (1− 1

3×2n/2 ).

This value is almost 1/9 for a reasonably large n.



12 Mridul Nandi

5 Birthday Attack on SoKAC21

In the previous section we have shown the basic attacks on composition of ideal
primitives. A similar idea can be used for composition of constructions which
are not ideal. However, a more dedicated analysis of advantage computation
is required. In this section we show a birthday attack on a recent proposal
SoKAC21. In the following section we show birthday attack of Dual EWCDM.

We first recall the definition of SoKAC21 (see Fig. 1.2 and Eq. 4 for details.).

It uses two public n-bit random permutations πpub
1 and πpub

2 . Given an n-bit key
K, an n-bit input m, we define SoKAC21 output as

FK(m) := πpub
2 (x)⊕ x, where x = πpub

1 (m⊕K)⊕K.

Our attack does not exploit public queries to πpub
1 and hence πpub

1 (m ⊕ K) ⊕
K behaves identically to a secret random permutation πsec(m). Let DM(x) :=

πpub
2 (x)⊕x (Davies-Meyer construction based on a public random permutation).

So SoKAC21 is actually the composition DM ◦ πsec. However, DM is not perfect
random function. But if we choose the inputs of DM in a without replacement
manner, the output of DM can be viewed as the sum of two WOR samples
and hence it is very close to uniform distribution. We use this principle along
with the attack strategy as described in the previous section for the composition
construction γpub ◦πsec. We simply write πpub instead of πpub

2 and πsec instead of

the Even-Mansour construction on πpub
1 .

PRF Distinguisher AO,πpub

1 : x1, . . . , xp ←wor {0, 1}n

2 : queries x1, . . . , xp to πpub

3 : x′i = πpub(xi), i ∈ [p] be the responses

4 : let yi = x′i ⊕ xi
5 : for i ∈ [q], i is queried to O

6 : let ci = O(i), i ∈ [q] be the responses

7 : if ∃i, j, yi = cj return 1

8 : else return 0

Fig. 5.1: Distinguisher for SoKAC21 which can be viewed as the composition construc-
tion DM ◦ πsec .

We define the event E := LColl(cq, yp) (i.e. there exists i, j such that yi = cj).

Ideal World: In the ideal world c1, . . . , cq ←$ {0, 1}n. Moreover, yi is defined
as sum of two without replacement sample. By Eq. 6, yi’s are close to a with



Title Suppressed Due to Excessive Length 13

replacement sample y′1, . . . , y
′
p with the statistical distance at most 4p/2n. More-

over y′i’s are independent of cq. Let µ := Pr(LColl(cq, (y′)p)) = lcp$(p, q). So by
using Lemma 1,

Pr(E) = Pr(LColl(cq, yp)) ≤ lcp$(p, q) + 4p/2n.

Real World: In the real world, let zi = πsec(i). So ci = πpub(zi) ⊕ zi for all i
and z1, . . . , zq ←wor {0, 1}n independent of xp. Now, the event E can be written
as a disjoint union E1 t E2 where

1. E1 is LColl(zq, xp) and
2. E2 is LColl(zq, xp) ∧ LColl(cq, yp).

Let Pr(E1) = lcpwor(p, q) = Âľ1 (say).
Now, we compute the probability of the event E2 which is same as Ec1 ∧

LColl(cq, yp). Given that zq is distinct from xp (i.e. Ec1 holds) we have

z1, . . . , zq, x1, . . . , xp←wor {0, 1}n.

As ci = DM(zi) and yi = DM(xi), ci’s and yi’s are almost uniformly distributed.
More precisely, for c′1, . . . , c

′
q, y
′
1, . . . , y

′
p←$ {0, 1}n,

D((cq, yp); ((c′)q, (y′)p)) ≤ 4(p+ q)/2n.

So by Lemma 1, Pr(E2) ≥ (1 − µ1) × (µ − 4(p + q)/2n) where µ = lcp$(p, q).
Now,

Pr(E) = Pr(E1) + Pr(E2)

≥ µ1 + (1− µ1)(µ− 4(p+ q)

2n
).

So, subtracting the probability Pr(E) of the real world from that of the ideal
world, the distinguishing advantage is at least

µ1(1− µ)− 8p+ 4q

2n
.

We have already shown that µ1(1−µ) is at least 1
9−

1
27¡2n/2 when p = q =

√
2n/3

(see the last paragraph of our analysis on γpub ◦ πsec). Hence the advantage is at
least 1

9 −
1

2n/2−1 .

6 Birthday Attack on Dual-EWCDM

In this section we provide details of a nonce respecting distinguishing attack
on EWCDMD. For better understanding we consider a specific hash function
H(m) = K ¡ m where K is a nonzero random key chosen uniformly from
{0, 1}n \ {0} and m ∈ M := {0, 1}n. Here K ¡ m means the field multiplica-
tion with respect to a fixed primitive polynomial. Clearly, H is 1

2n−1 AXU hash.



14 Mridul Nandi

Moreover it is injective hash. In other words, for distinct messages m1, . . . ,mq,
H(m1), . . . ,H(mq) are distinct.

Distinguishing Attack. A choses (ν1,m1), . . . , (νq,mq) ∈ {0, 1}n ×M where
all νi’s are distinct and all mi’s are distinct. Suppose T1, . . . , Tq are all responses.
A returns 1 if there is a collision among Ti values, otherwise returns zero.

When A is interacting with a random function, Pr[A → 1] ≤ q(q − 1)/2n+1

(by using the union bound). Now we provide lower bound of Pr[A → 1] while A

is interacting with EWCDMD in which π1, π2 are two independent random per-
mutations and H is the above hash function whose key is chosen independently.
To obtain a lower bound we first prove the following lemma. Let N = 2n.

Lemma 5. Let x1, . . . , xq ∈ {0, 1}n be q distinct values. Let π be a random
permutation. Then, for all distinct ν1, . . . , νq, let C denote the event that there
is a collision among values of π(νi)⊕ xi, 1 ≤ i ≤ q. Then,

α(1− β) ≤ Pr[C] ≤ α

where α = q(q−1)
2(N−1) and β = (q−2)(q+1)

4(N−3) . In particular, for distinct xi’s, there is a

collision among π(xi)⊕ xi values has probability at least α(1− β).

Proof . Let Ei,j denote the event that π(νi)⊕ π(νj) = xi ⊕ xj . So for all i 6= j,
Pr[Ei,j ] = 1/(N − 1). Let C = ∪i 6=jEi,j denote the collision event. By using
union bound we can easily upper bound

Pr[C] ≤ α :=
q(q − 1)

2(N − 1)
.

Now, we show the lower bound. For this, we apply Boole’s inequality and we
obtain lower bound of collision probability as

Pr[C] ≥ α−
∑

Pr[Ei,j ∊ Ek,l]

where the sum is taken over all possible choices of {{i, j}, {k, l}}, and the number

of such choices is at most
(
q(q−1)/2

2

)
= q(q − 1)(q + 1)(q − 2)/8. Note that for

each such choice i, j, k, l,

Pr[Ei,j ∩ Ek,l] ≤
1

(N − 1)(N − 3)
.

Hence,

Pr[C] ≥ α− q(q − 1)(q + 1)(q − 2)

8(N − 1)(N − 3)
(9)

= α(1− (q − 2)(q + 1)

4(N − 3)
) = α(1− β). (10)

This completes the proof. ut



Title Suppressed Due to Excessive Length 15

Advantage Computation. Using the above Lemma we now show that the
probability that A returns 1 while interacting with EWCDMD is significant when
q = O(2n/2).

Let C1 denote the event that there is a collision among the values zi :=
π1(νi) ⊕H(mi). We can apply our lemma as H(mi)’s are distinct due to our
choice of the hash function. Thus, Pr[C1] ≥ α(1−β). Moreover, Pr[¬C1] ≥ (1−α).
Given ÂŹC1, T values are outputs of Davies-Meyer based on random permutation
π2 for distinct inputs. So by using previous lemma,

Pr(collision in T values | ¬C1) ≥ α(1− β).

Hence,

Pr(A → 1) ≥ Pr(C1) + Pr(collision in T values | ¬C1)× Pr[¬C1]

≥ α(1− β) + (1− α)× Pr(collision in T values | ¬C1)

≥ α(1− β) + α(1− α)(1− β)

= (2α− α2)(1− β) ≥ 2α− 2αβ − α2.

Thus, the advantage of the adversary is at least α− 2αβ − α2. It is easy to see
that when 2q2 ≥ N , we have 1 − 2β − α ≤ 1/2 and hence the advantage is at
least α/2 = q(q − 1)/4(N − 1).

Remark 1. We would like to note that the distinguishing advantages of both
constructions can be made closer to one if we repeat the whole process indepen-
dently O(n) times.

6.1 Issues in the Previous Proofs

Now we briefly describe what were the issues in the proofs of [CLM19,MN17].
Both proofs used H-technique and hence it is broadly divided into two parts:
bounding probability of bad events and finding good lower bound for realizing
any fixed good transcript in the real world. The flaws in their proof lie on the
good transcript analysis.

Suppose π1 and π2 are two random permutations. In the both proofs, good
transcript analysis deals to compute the probability distribution of sum of the
two random permutations. More precisely, for fixed Ν1, x1, y1, . . . xq, yq, Νq ∈
{0, 1}n, we want to provide a lower bound of the event π1(xi) ⊕ π2(yi) = λi
for all i. This is also known as mirror theory and have been studied in several
papers[Pat10,Pat13,DDN+17b,DDNY19,DDNY18]. A desired lower bounds are
known if the equality patterns of xi and yi’s satisfy certain conditions. In the
proofs of [CLM19,MN17], equality pattern of yi’s depend on the values of π1(xi)
for all i. So, clearly, we cannot use the mirror theory based lower bound. This is
the main flaw of the proofs.



16 Mridul Nandi

7 Concluding Di";"""date"",""2020-02-20T09:34:26Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2020-02-20T09:34:26Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.16 (TeX Live 2015) kpathsea version 6.2.1""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2020-02-20T09:34:26Z""
""created"",""2020-02-20T09:34:26Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-02-20T09:34:26Z""
""resourceName"",""236.pdf""
""Author"",""""
""producer"",""pdfTeX-1.40.16""
""pdf:docinfo:producer"",""pdfTeX-1.40.16""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""2"",""2"",""0"",""1"",""11"",""6"",""12"",""6"",""3"",""12"",""2"",""12"",""7"",""0"",""2"",""0"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2020-02-20T09:34:26Z""
""Last-Modified"",""2020-02-20T09:34:26Z""
""dcterms:modified"",""2020-02-20T09:34:26Z""
""title"",""""
""Last-Save-Date"",""2020-02-20T09:34:26Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2020-02-20T09:34:26Z""
""meta:save-date"",""2020-02-20T09:34:26Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.16 (TeX Live 2015) kpathsea version 6.2.1""
""Content-Length"",""439191""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""19""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""2068"",""2036"",""1295"",""2532"",""1788"",""1242"",""1841"",""1818"",""1745"",""1447"",""954"",""1652"",""1453"",""1503"",""1819"",""1657"",""2502"",""2679"",""355""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-02-20T09:34:26Z""
";https://scholar.google.ch/scholar?start=800&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098747-64;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Viabilidad de la mediación familiar sobre Blockchain;E Escobar Rojo ;2020 eprints.ucm.es;;"… They should be normalized and legally regulated to maximize their potential.

Keywords Family Mediation, Blockchain, dApp, Smart Contract, Divorced,

Ethereum, Separation Page 8 … 76 6.4.5 Better oracles ..... 76 …";Autres articles;;[PDF] ucm.es;https://eprints.ucm.es/id/eprint/62577/1/edgar_tfm.pdf;"
 

 

 

VIABILIDAD DE LA MEDIACIÓN FAMILIAR 

SOBRE BLOCKCHAIN 

VIABILITY OF FAMILY MEDIATION ON 

BLOCKCHAIN 

 

 
 

TRABAJO FIN DE MÁSTER 

CURSO 2019-2020 

 

AUTOR 

EDGAR ESCOBAR ROJO 

 

DIRECTOR 

ANTONIO A. SÁNCHEZ RUIZ-GRANADOS 

 

 
MÁSTER EN INGENIERÍA INFORMÁTICA 

FACULTAD DE INFORMÁTICA 

UNIVERSIDAD COMPLUTENSE DE MADRID 



 

 

 

VIABILIDAD DE LA MEDIACIÓN FAMILIAR 

SOBRE BLOCKCHAIN 

VIABILITY OF FAMILY MEDIATION ON 

BLOCKCHAIN 
 

 

TRABAJO DE FIN DE MÁSTER EN INGENIERÍA INFORMÁTICA 

DEPARTAMENTO DE INGENIERÍA DEL SOFTWARE E INTELIGENCIA 

ARTIFICIAL 

  

 

AUTOR 

EDGAR ESCOBAR ROJO 

 

DIRECTOR 

ANTONIO A. SÁNCHEZ RUIZ-GRANADOS 

 

CONVOCATORIA: SEPTIEMBRE 2020 

CALIFICACIÓN:  

9 

 
MÁSTER EN INGENIERÍA INFORMÁTICA 

FACULTAD DE INFORMÁTICA 

UNIVERSIDAD COMPLUTENSE DE MADRID 

 

7 DE SEPTIEMBRE DE 2020 

 



i 

 

DEDICATORIA 

A mi novia, por haberme animado 

en los momentos en los que solo veĂ­a 

oscuridad, y haber aguantado esos 

dĂ­as junto a mĂ­, que he estado 

ausente centrado en el trabajo, sin 

dejar de apoyarme. 

A mi madre, que siempre me ayuda 

a relajarme en los momentos de 

agobio, permitiĂŠndome tomar de 

vez en cuando. 

A mi padre, por la fuerza de 

voluntad que me ha transferido, 

durante toda mi vida, y durante el 

proyecto. 

Y a los tres en conjunto porque sin 

ellos es muy posible que hubiera 

tardado otros dos aĂąos en acabar 

este trabajo. 

Gracias por no dejar de creer en mĂ­. 

 

 

 

 

 

 

  



ii 

 

AGRADECIMIENTOS 

TambiĂŠn me gustarĂ­a agradecer el apoyo de mis compaĂąeros de trabajo, 

asĂ­ como la flexibilidad que me han concedido cuando la he necesitado. 

A mi casero, que siendo abogado entendido en los procesos de mediaciĂłn, 

fue el que me abriĂł camino para enfocar el trabajo en este aspecto, 

resolviĂŠndome diferentes dudas y aclarĂĄndome el proceso para poder trasladarlo 

lo mejor posible a la aplicaciĂłn. 

Y sobre todo a mi tutor Antonio A. Sanchez Ruiz-Granados, que siempre ha 

sido paciente conmigo durante el largo tiempo que ha durado el desarrollo del 

trabajo, y que me ha motivado y ayudado a continuar en diferentes momentos. 



iii 

 

RESUMEN 

Viabilidad de la mediaciĂłn familiar sobre Blockchain 

La tecnologĂ­a de cadenas de bloques o Blockchain es conocida por su 

potencial al ser una base de datos totalmente descentralizada, pĂşblica y con una 

seguridad muy robusta. Sin embargo, su uso estĂĄ poco enfocado a las personas 

individuales, siendo las empresas sus principales beneficiarias, a pesar de sus 

posibilidades en entornos sociales.  

La mediaciĂłn familiar es una vĂ­a alternativa a la judicial para llevar a cabo 

un proceso de divorcio de forma pacĂ­fica y de mutuo acuerdo entre los 

divorciados, la cual se apoya en una figura mediadora y otra legal. 

El objetivo de este trabajo es mostrar la viabilidad del uso de la tecnologĂ­a 

en procesos cotidianos entre dos personas, concretamente en la mediaciĂłn 

familiar.   

Para ello, a partir de una investigaciĂłn sobre las limitaciones legales y 

tecnolĂłgicas de la cadena de bloques, y sobre el proceso tradicional de 

mediaciĂłn, asĂ­ como de otros casos de uso similares, se ha diseĂąado y construido 

una aplicaciĂłn basada en tecnologĂ­as distribuidas (dApp) para abogados, 

mediadores, y personas que se van a separar, sobre la que realizar el proceso de 

mediaciĂłn.  

Entre otros beneficios de esta aplicaciĂłn se puede destacar la 

descongestiĂłn en la justicia al simplificar y minimizar la gestiĂłn de los procesos 

judiciales, la mejora del proceso de mediaciĂłn en la forma de participaciĂłn de los 

mediadores y los abogados intentando asegurar su imparcialidad, facilitar el 

proceso para los separados y aumentar la transparencia del proceso y por lo tanto 

su fiabilidad.  

TambiĂŠn se expone la falta de regulaciĂłn legal sobre estas aplicaciones, que 

aĂşn necesita tiempo para que se normalice completamente, y permita llevar el 

potencial del Blockchain al mĂĄximo. 



iv 

 

Palabras clave 

MediaciĂłn familiar, dApp, Contrato inteligente, Cadena de bloques, 

SeparaciĂłn, Divorcio, Ethereum 



v 

 

ABSTRACT 

Viability of family mediation Blockchain 

Blockchain technology is a fully decentralized and public database with very 

robust security. However, despite its possibilities in social settings, it is focused on 

companies rather than individuals.  

In a divorce process, family mediation is an alternative way to carry out a 

peaceful agreement between the divorced. Family mediation avoids the judicial 

players and is supported by a mediator and a legal figure. 

This work is focused on the use of the blockchain technology in daily 

processes between two people, with an especial interest in family mediation. 

Accordingly, an application based on distributed technologies (dApp) for 

people involved in a divorce has been designed. This application is based on the 

legal and technological limitations of the blockchain, the traditional mediation 

process, as well as other similar cases. 

One of the main advance of this application is the simplification of the judicial 

processes. It leads to an improvement of the mediation process, facilitates the 

participation of mediators and lawyers and ensures their impartiality. Altogether, the 

application facilitates the divorce and increase the transparency of the process, 

and therefore its reliability. 

The lack of legal regulation on these applications is also exposed. They should 

be normalized and legally regulated to maximize their potential. 

Keywords 

Family Mediation, Blockchain, dApp, Smart Contract, Divorced, Ethereum, 

Separation 

 

 

 



 

 

ÍNDICE DE CONTENIDOS 

CapĂ­tulo 1 - IntroducciĂłn .......................................................................................... 1 

1.1 MediaciĂłn familiar en el divorcio ................................................................ 3 

CapĂ­tulo 2 - MotivaciĂłn ............................................................................................ 5 

CapĂ­tulo 3 - Objetivos y plan de trabajo ................................................................. 7 

3.1 Objetivo general ........................................................................................... 7 

3.2 Objetivos especĂ­ficos .................................................................................... 7 

3.3 Plan de trabajo ............................................................................................. 8 

CapĂ­tulo 4 - Conceptos previos sobre contratos inteligentes en el ĂĄmbito de la 

mediación ………………………………………………………………………………….10 

4.1 Cadena de bloques y contratos inteligentes ........................................... 10 

4.2 Aplicaciones actuales de los Smart Contracts ........................................ 12 

4.3 Validez legal de los contratos inteligentes ............................................... 13 

4.3.1    La firma del contrato ................................................................................. 13 

4.3.2    Legalidad de las clĂĄusulas ........................................................................ 17 

4.4 Arbitraje en contratos inteligentes ............................................................ 19 

4.5 Legalidad de los orĂĄculos .......................................................................... 21 

4.6 Flujo de creaciĂłn de un Smart Contract .................................................. 22 

4.7 Conferencias de chat sobre Blockchain .................................................. 22 

CapĂ­tulo 5 - DiseĂąo de la aplicaciĂłn ..................................................................... 24 

5.1 IntroducciĂłn ................................................................................................ 24 

5.2 Actores ......................................................................................................... 26 

5.3 DefiniciĂłn funcional .................................................................................... 29 

5.3.1    IdentificaciĂłn de actores humanos ......................................................... 29 



 

 

5.3.2   CreaciĂłn de acuerdo entre S1 y S2 .......................................................... 31 

5.3.3    SelecciĂłn de validadores y ĂĄrbitros ......................................................... 32 

5.3.4 Desarrollo de la mediaciĂłn ....................................................................... 38 

5.3.5 EjecuciĂłn de las clĂĄusulas ......................................................................... 40 

5.4 Materiales y mĂŠtodos ................................................................................. 42 

5.4.1 IntroducciĂłn ............................................................................................... 42 

5.4.2 Arquitectura base y herramientas ............................................................ 43 

5.4.3 Tipos de funciones y variables utilizadas .................................................. 45 

5.5 DiseĂąo tĂŠcnico ............................................................................................ 46 

5.5.1 Arquitectura ................................................................................................ 46 

5.5.2 Comprobaciones de identidad y creaciĂłn del contrato ...................... 49 

5.5.3 SelecciĂłn de participantes ....................................................................... 51 

5.5.4 Desarrollo de la mediaciĂłn ....................................................................... 52 

5.5.4.1 Propuestas ........................................................................................... 52 

5.5.4.2 Aceptaciones ..................................................................................... 54 

5.5.4.3 Solicitud de mediaciĂłn ...................................................................... 56 

5.5.5 ResoluciĂłn del contrato............................................................................. 56 

5.6 Resultado ..................................................................................................... 59 

5.6.1 Objetivos conseguidos............................................................................... 60 

5.6.2 Objetivos no conseguidos ......................................................................... 60 

CapĂ­tulo 6 - Conclusiones y trabajo futuro ............................................................ 62 

6.1 Conclusiones ............................................................................................... 62 

6.2 Trabajo futuro .............................................................................................. 65 

6.2.1 IoT para la propiedad ................................................................................ 65 



 

 

6.2.2 Cambios sobre el contrato vigente .......................................................... 66 

6.2.3 AutomatizaciĂłn del pago ......................................................................... 66 

6.2.4 Feedback y calendario ............................................................................. 67 

6.2.5 Mejores orĂĄculos ........................................................................................ 67 

6.2.6 Plantillas dinĂĄmicas .................................................................................... 67 

6.2.7 Otras aplicaciones ..................................................................................... 67 

ApĂŠndice A - Introduction ............................................................................................ 69 

7.1. Family mediation in divorce ....................................................................... 70 

ApĂŠndice B - Conclusions and future work ................................................................. 72 

6.3 Conclusions .................................................................................................. 72 

6.4 Future work .................................................................................................. 74 

6.4.1 IoT for property ............................................................................................ 74 

6.4.2 Changes to the current contract.............................................................. 75 

6.4.3 Payment automation ................................................................................. 76 

6.4.4 Feedback and calendar ........................................................................... 76 

6.4.5 Better oracles .............................................................................................. 76 

6.4.6 Dynamic templates .................................................................................... 76 

6.4.7 Other apps .................................................................................................. 77 

 

  



 

 

ÍNDICE DE FIGURAS 

Figura 1.1: Gráfico utilización de Blockchain por sectores [5] ………………...……….. 2 

Figura 2.1: Ejemplo visual del cálculo de la clave pública …………………..……….. 16 

Figura 2.2: Interfaz Confideal [27] ………………………………………………………...... 19 

Figura 3.1: Esquema de actores e interacciones básicas …………………………...... 25 

Figura 3.2: Mockup de la interfaz de creación del contrato …………………………. 31 

Figura 3.3: Mockup de la interfaz de selecciĂłn de ĂĄrbitros y validadores para S1 y S2 

……………………………………………………………………………………………...... 33 

Figura 3.4: Mockup de la interfaz de registro para árbitros y validadores …………. 34 

Figura 3.5: Mockup de la interfaz de mediación ………………………………………... 39 

Figura 3.6: Mockup de la interfaz de ejecución de cláusulas …………………………41 

Figura 3.7: Modelo Cliente-Servidor tradicional …………………………………………..42 

Figura 3.8: Modelo Cliente-Servidor en Blockchain ……………………………………...43 

Figura 3.9: Diagrama de tecnologías empleadas ……………………………………….44 

Figura 3.10: Interacción y arquitectura de la aplicación ……………………………….47 

Figura 3.11: Creación del contrato ………………………………………………………….49 

Figura 3.12: Registro y actualización para validadores y árbitros ……………………..50 

Figura 3.13: Elección de candidatos (validadores y árbitros) ………………………….52 

Figura 3.14: Propuesta / Corrección de cláusulas …………………………………….….53 

Figura 3.15: Aceptación de cláusulas ……………………………………………………....55 

Figura 3.16: Solicitud de mediación ………………………………………………………....56 

Figura 3.17: Pago manutención y notificación de incumplimiento …………………..58 

Figura 3.18: Solicitud de acceso a la propiedad ……………………………………….....59 

 



 

 

ÍNDICE DE TABLAS 

Tabla 3.1: Tabla de ganancias y pérdidas en la aplicación ………………………….. 35 

 



1 

 

CapĂ­tulo 1 -  IntroducciĂłn 

Desde que apareciĂł la tecnologĂ­a de cadena de bloques en el aĂąo 2008, el 

mundo empezĂł a experimentar un gran cambio, que junto con el IoT y otras 

tecnologĂ­as se denominĂł RevoluciĂłn Industrial 4.0 [1]. Entonces se especulaban 

muchas posibles aplicaciones de esta tecnologĂ­a que se han cumplido a lo largo 

de su evoluciĂłn, asĂ­ como han aparecido nuevas posibilidades. 

En su comienzo, con el conocido Bitcoin su funciĂłn era Ăşnicamente el 

traspaso de capital de forma segura y sin intermediarios, lo cual era de gran utilidad 

en muchos escenarios [2]. Pero fue con la apariciĂłn de los contratos inteligentes o 

Smart Contracts cuando las posibilidades de la tecnologĂ­a Blockhain se dispararon, 

y siguen aumentando de manera exponencial, con aplicaciĂłn en gran cantidad 

de sectores, permitiendo ejecutar contratos entre dos partes de manera 

automĂĄtica, segura y con validez legal [3]. 

Aunque la tecnologĂ­a ha tenido una buena aceptaciĂłn y ya es utilizada en 

diferentes sectores, aĂşn tiene un largo camino por recorrer hasta que se consigan 

explotar sus beneficios al mĂĄximo. 

En la actualidad la realidad es que los principales beneficiarios de esta 

tecnologĂ­a estĂĄn siendo las empresas y sectores industriales en general, utilizĂĄndola 

por ejemplo para realizar contratos entre empresas colaboradoras, para la 

trazabilidad de sus productos, o seguridad en las transferencias de capital, 

aportando beneficios empresariales y aumentando la confianza de los clientes en 

las empresas [4]. En el siguiente texto se muestran las conclusiones de un trabajo de 

anĂĄlisis del Blockchain. Por un lado, hace visible la inmadurez de la tecnologĂ­a, y 

por otro, el enfoque de la misma, el cual se estĂĄ dirigiendo, principalmente, a 

modelos de negocio de grandes empresas, en vez de utilizar su verdadero 

potencial, la descentralizaciĂłn y su uso pĂşbico en el ĂĄmbito social. 

“Existen una variedad de industrias en el ámbito privado que ven a la 

tecnologĂ­a Blockchain como una forma de mejorar sus procesos reduciendo 



2 

 

tiempos de procesos, reducciĂłn de costos, aumento de la seguridad, 

transparencia y estabilidad del sistema. Sin embargo, el verdadero potencial de la 

tecnologĂ­a se puede apreciar en una red mayor mediante una rĂĄpida adopciĂłn 

general, con la generaciĂłn de nuevos modelos de negocio mediante aplicaciones 

pĂşblicas descentralizadas apoyando el desarrollo de la infraestructura en un 

aspecto econĂłmico, empresarial y social. Pero esta adopciĂłn requiere de la 

articulaciĂłn tanto del ĂĄmbito tecnolĂłgico como polĂ­tico, social y econĂłmico para 

llegar a una fase de maduraciĂłn, si hoy existe un ecosistema robusto aĂşn falta el 

desarrollo en temas relacionados a la regulaciĂłn y al conocimiento por parte del 

macro-entorno.” [4]. 

En la siguiente figura 1.1 se muestra un grĂĄfico del uso del Blockchain por 

sectores, donde es visible su baja aplicaciĂłn en sectores pĂşblicos o en aplicaciones 

enfocadas a las personas individuales. Es curioso que su mayor uso sea en la banca, 

cuando el Bitcoin naciĂł como un posible sustituto de ella. 

 

Figura 1.1 GrĂĄfico utilizaciĂłn de Blockchain por sectores [5]. 

 

 



3 

 

1.1 MediaciĂłn familiar en el divorcio 

Como se ha dicho en el apartado anterior, la aplicaciĂłn de los contratos 

inteligentes estĂĄ poco orientada a los acuerdos entre personas individuales, y como 

se detalla en los objetivos, este trabajo pretende fortalecer este enfoque. Para ello 

se ha elegido abordar el proceso de mediaciĂłn familiar, que intenta sustituir la vĂ­a 

judicial de los procesos comunes de divorcio, como caso de uso en el que aplicar 

la tecnologĂ­a tratada. 

El proceso de mediaciĂłn familiar surge de la necesidad de humanizar y 

facilitar el proceso de divorcio. Por lo general, un divorcio es un suceso triste para 

las partes, que suele ir unido a otras emociones como la ira, el disgusto, depresiones, 

etc [15]. Si a las emociones se le suma un entorno judicial, con abogados y jueces, 

estas emociones pueden aumentar fĂĄcilmente debido al ambiente serio y hostil 

existente. AdemĂĄs, en muchas ocasiones, los abogados no toman conciencia del 

estado anĂ­mico de las personas o de la situaciĂłn que rodea a cada una (hijos, 

entorno familiar de cada uno, etc.), llegando incluso a intensificar el odio hacia la 

otra parte, aunque sea de manera no intencionada, o alentando a una de las 

partes a pedir unas condiciones en el divorcio desproporcionadas o muy daĂąinas 

para la otra parte [16]. 

Por lo tanto, la mediaciĂłn pretende sustituir todo este proceso por uno mĂĄs 

amistoso, en la medida de lo posible, y para ello se basa en los siguientes puntos: 

● Las condiciones de divorcio o separación nacen del consenso de las 

dos partes, sin tener participaciĂłn de terceros, como abogados, 

posicionados hacia alguna de las partes.  

● La existencia de una figura mediadora. La misión de esta persona es 

ayudar a que las partes resuelvan los conflictos que van surgiendo 

durante el procedimiento de forma pacĂ­fica y consensuada. Esta 

persona debe ser totalmente imparcial y tener conocimientos de 

psicologĂ­a y sociologĂ­a para conseguir su objetivo. 



4 

 

● La existencia de una figura con conocimientos legales que ayude a 

redactar las clĂĄusulas (dictadas por las partes) del contrato de forma 

legal y valida ante un jurado. Esta figura tambiĂŠn debe ser totalmente 

imparcial. 

● Un juez que valide el acuerdo una vez finalizado el proceso. 

Durante el proceso se producen varias iteraciones con reuniones en las que 

se va llegando a consenso entre las partes y redactando las diferentes clĂĄusulas.  

Puede darse que la figura legal y mediadora sea la misma si tiene los 

conocimientos requeridos tanto legales como psicosociolĂłgicos.  

Si una vez el contrato estĂĄ vigente, por haber sido validado por la autoridad 

judicial, se da un incumplimiento del acuerdo, o existen factores que hacen que 

alguna de las partes estĂŠ en desacuerdo, se deberĂ­a volver a iniciar el proceso 

hasta volver a alcanzar un consenso [17]. 

Es importante mencionar que no se pretende validar la posibilidad de sustituir 

completamente el proceso actual de mediaciĂłn familiar por un proceso 

Ăşnicamente tecnolĂłgico, ya que como veremos en detalle a continuaciĂłn, existen 

diferentes factores y componentes sociolĂłgicos y psicolĂłgicos del proceso que 

deben seguir siendo humanos y no son sustituibles. Pero es posible que la tecnologĂ­a 

pueda ayudar a complementar ciertas partes del proceso, o incluso conseguir 

hacerlo viable en escenarios que serĂ­an imposibles. 

  



5 

 

CapĂ­tulo 2 -  MotivaciĂłn 

La motivaciĂłn de este trabajo surge de la falta de acercamiento de la 

tecnologĂ­a Blockchain a las personas, que podrĂ­a facilitar y mejorar muchos 

ĂĄmbitos de la vida cotidiana. Mostrando la viabilidad y el potencial de 

aplicaciones descentralizadas, se espera que las personas tomen conciencia, y se 

redirija el enfoque de las aplicaciones Blockchain a una verdadera 

descentralizaciĂłn Ăştil para todo el mundo. 

La idea principal comienza con buscar cĂłmo la tecnologĂ­a del Blockchain 

se puede utilizar en interacciones entre dos personas de forma que les ayude en 

situaciones o procesos del dĂ­a a dĂ­a, de alguna manera similar a como estĂĄ 

ayudando a las empresas al aportar fiabilidad a la trazabilidad de sus productos, 

por ejemplo, o a funciones de la administraciĂłn pĂşblica como el conteo de voto.  

Para encontrar una aplicaciĂłn concreta de la tecnologĂ­a se ha buscado un 

proceso pĂşblico que pueda aprovechar las ventajas de la cadena de bloques: 

● Transparencia.  

● Anonimato.  

● Descentralización. 

● Confianza.  

Debido a conocer la problemĂĄtica que conlleva un divorcio o separaciĂłn y 

gracias a la cercanĂ­a de un abogado conocedor de los procesos de mediaciĂłn 

familiar, los cuales, al igual que la tecnologĂ­a Blockchain, estĂĄn en una etapa 

temprana de maduraciĂłn, se escoge este caso de uso para elaborar una 

aplicaciĂłn, ya que se basa en puntos similares, al requerir confianza en el proceso, 

los abogados, y el mediador, asĂ­ como el respeto de la privacidad de los 

participantes. Otro punto de motivaciĂłn es la saturaciĂłn de la justicia, la cual 

puede disminuir con el uso de aplicaciones de este tipo. 



6 

 

Aunque se detalle mĂĄs adelante, en resumen, la mediaciĂłn intenta evitar la 

confrontaciĂłn entre las partes, eliminando tanto a los abogados personales de 

cada parte, que pueden llegar a ser avivadores del enfrentamiento, como el 

entorno de un juzgado presencial, que suele hacer que la situaciĂłn tome un 

carĂĄcter o enfoque deprimente y belicoso. 

Por lo tanto, en el siguiente trabajo se va a desarrollar una aplicaciĂłn que 

permita mantener las premisas de un proceso de mediaciĂłn (privacidad, 

imparcialidad y legalidad), agilizar y facilitar el proceso de mediaciĂłn, y acercar 

tanto el proceso como la tecnologĂ­a a un mayor nĂşmero de personas de cualquier 

clase social al hacer visibles los procesos y aumentar la confianza de los posibles 

usuarios. 

  



7 

 

CapĂ­tulo 3 -  Objetivos y plan de trabajo 

3.1 Objetivo general     

El principal objetivo de este trabajo es, por lo tanto, mejorar un proceso 

concreto, la mediaciĂłn familiar, mediante una aplicaciĂłn basada en la cadena 

de bloques. 

En segundo lugar, se pretende visibilizar las posibles aplicaciones de la 

tecnologĂ­a en diferentes procesos cotidianos de las personas, mostrando el valor 

de esta a un nivel mĂĄs bajo y personal que el empresarial y promoviendo su uso a 

todos los niveles y para todo el mundo, ayudando por lo tanto a que la misma 

crezca de manera mĂĄs rĂĄpida aportando su valor real.  

 

3.2 Objetivos especĂ­ficos  

Se intenta mejorar los procesos de mediaciĂłn familiar entre dos personas 

utilizando la tecnologĂ­a Blockchain con estos fines: 

● Abaratar costes:  

o En desplazamientos, tanto para los separados como para los 

abogados o mediadores que deben participar en el proceso. 

o En tiempo de intervenciĂłn de los abogados y los mediadores. 

o El coste del proceso en general para las partes, reduciendo 

papeleo, tiempos de gestiĂłn, etc. 

● Aumentar la confianza en la imparcialidad de abogados y 

mediadores. 

● Facilitar el dialogo y el arbitraje sin necesidad de tener reuniones 

presenciales, pero sin perder el seguimiento del proceso por parte de 

los abogados o los mediadores, minimizando asĂ­ el impacto 

psicolĂłgico del divorcio en los separados. 



8 

 

● Empoderar a las partes separadas en cuanto a la gestión y la 

decisiĂłn, haciĂŠndolas propietarias de su proceso de separaciĂłn a la 

vez que se asegura la equidad de responsabilidades, derechos y 

obligaciones de cada parte. 

● Tener un registro público del proceso completo, validado por 

autoridades legales y posibilitando la revisiĂłn del mismo por un juez, 

en caso de necesidad una vez resuelto el acuerdo, pero 

manteniendo el anonimato de las personas que actĂşan en el 

contrato para todo el mundo, excepto para cualquier autoridad 

legal que requiera conocer a las partes, como podrĂ­a ser un juez. 

● Agilizar los procesos judiciales al necesitar menos participación de 

jueces y abogados, asĂ­ como descongestionar los juzgados, 

dejĂĄndolos libres para situaciones que de verdad lo requieran. 

 

3.3 Plan de trabajo  

Para conseguir estos objetivos, en primer lugar, se investigarĂĄn diferentes 

casos de uso de la tecnologĂ­a Blockchain para conocer sus aplicaciones y 

extrapolar ideas al contexto del trabajo. 

El segundo paso serĂĄ investigar el proceso de mediaciĂłn en divorcios, 

viendo las ventajas que aporta, el estado actual del proceso, y el camino que estĂĄ 

llevando ya que es un proceso joven, que estĂĄ en crecimiento, y aĂşn se estĂĄ 

regulando. 

Llegados a este punto, se revisarĂĄn los casos de uso de la tecnologĂ­a, 

investigados en un primer momento, con mĂĄs detalle, buscando aplicaciones 

concretas que puedan servir o ayudar en el caso concreto que aborda el trabajo. 

TambiĂŠn se investigarĂĄn nuevos casos de uso, mĂĄs focalizados en el contexto del 

trabajo para resolver puntos especĂ­ficos del proceso. 



9 

 

Una vez se haya recabado suficiente informaciĂłn del contexto y las 

posibilidades de la tecnologĂ­a, se extrapolarĂĄ todo lo investigado a una aplicaciĂłn 

que resuelva los objetivos para el caso de la mediaciĂłn en divorcios. Primero se 

realizarĂĄ un primer diseĂąo con la funcionalidad bĂĄsica de la aplicaciĂłn para a 

posteriori diseĂąar la parte tĂŠcnica (arquitectura, interacciones necesarias, etc.). 

DespuĂŠs se comenzarĂĄ a configurar la plataforma y a desarrollar la base de la 

aplicaciĂłn. En este punto se harĂĄ una valoraciĂłn de lo desarrollado, extrayendo los 

puntos no resueltos y buscando posibles soluciones. 

 

 

 

  



10 

 

CapĂ­tulo 4 -  Conceptos previos sobre 

contratos inteligentes en el ĂĄmbito de la 

mediaciĂłn 

4.1 Cadena de bloques y contratos inteligentes 

Aunque en este trabajo no se van a detallar las bases teĂłricas que sustentan 

la tecnologĂ­a de cadena de bloques o de los contratos inteligentes, es necesario 

indicar ciertos puntos bĂĄsicos que permiten entender como esta tecnologĂ­a puede 

servir para cumplir los objetivos de este trabajo.  

Una cadena de bloques es una base de datos, con unas caracterĂ­sticas 

especĂ­ficas: 

● Control de usuario: son los usuarios de la aplicación los que controlan 

totalmente las acciones (transacciones de informaciĂłn) entre ellos y la 

cadena de bloques. 

● Transparencia: los datos contenidos están disponibles públicamente y son 

verificables. 

● Anonimidad y confiabilidad: los usuarios pueden interactuar con la cadena 

de bloques de forma anĂłnima y segura, sin existir conflicto con el principio 

de transparencia. Aunque se conozcan los datos enviados a la cadena de 

bloques, y se asegure que proceden de una cuenta verificada, no se tiene 

por quĂŠ saber quiĂŠn es el propietario de esa cuenta de manera pĂşblica si el 

usuario no lo desea. 

● Inmutabilidad: Los datos añadidos a la base de datos Blockchain son 

inmutables. Un dato no se puede sobre-escribir borrando el anterior. Esto 

significa que la cadena siempre contendrĂĄ el histĂłrico de cambios, similar a 

un libro de cuentas. 

Una vez conocidas esas caracterĂ­sticas que serĂĄn importantes para lograr 

cubrir los objetivos propuestos tambiĂŠn es necesario hablar de Blockchain como 



11 

 

red. Dependiendo de la permisividad de acceso, existen dos tipos principales de 

redes: 

● Redes públicas o no permisionadas. 

En estas, todo el mundo puede acceder y operar, y sus datos son totalmente 

pĂşblicos, aunque sean anĂłnimos. Un ejemplo podrĂ­a ser Bitcoin o Ethereum. 

● Redes privadas o permisionadas. 

Los usuarios deben ser invitados para poder acceder y se pueden establecer 

permisos para operar. Hyperledger es una de estas redes. En estas no se 

asegura el anonimato, ya que, como mĂ­nimo, el propietario de la red 

conoce la identidad del resto. [6] 

Por otro lado, y ya que este trabajo gira en torno a los contratos inteligentes, 

se debe explicar de forma breve lo que son los contratos inteligentes. Para ello, 

primero describimos lo que es un contrato tradicional: 

“Un contrato es un acuerdo entre dos o más partes, en el que se define lo 

que se puede hacer, cĂłmo se puede hacer, y que pasa si no se hace, y que las 

dos partes se comprometen a cumplir y respetar.” [7]. 

De forma resumida un contrato inteligente es como un contrato tradicional 

cuyas clĂĄusulas se encuentran definidas en cĂłdigo sobre la cadena de bloques, y 

que puede contener scripts que hagan que ciertas acciones se ejecuten 

automĂĄticamente.  

Con estas premisas ya se puede ver gran parte del potencial que tienen, ya 

que implica que utilizando esta tecnologĂ­a: 

● Las cláusulas del contrato no podrán modificarse de forma unilateral de 

ninguna manera, ya que necesitarĂ­an el consentimiento de las dos partes. 

● Siempre se tendrá el historial de modificaciones de las cláusulas, siempre 

aceptadas por las dos partes, permitiendo revisar si esas modificaciones son 

vĂĄlidas y se hicieron en la forma correcta, ante cualquier problema que 

pueda suceder entre las partes. 



12 

 

● En caso de que el contrato implique acciones de las partes automatizables, 

se podrĂĄn programar automĂĄticamente, asegurando su cumplimiento. 

Con todo esto los contratos inteligentes pueden facilitar la realizaciĂłn de un 

acuerdo entre dos partes, ahorrĂĄndose ambas, en algunos casos, la necesidad de 

contratar a terceros que verifiquen ese acuerdo o el coste de llevar el proceso por 

una vĂ­a judicial. En caso de necesitar participaciĂłn de terceros la ventaja que 

puede ofrecer la tecnologĂ­a es la confianza en estos [8]. 

 

4.2 Aplicaciones actuales de los Smart Contracts 

Dadas las caracterĂ­sticas de la tecnologĂ­a, esta puede aportar valor en 

cualquier sector en el q";"""date"",""2020-10-01T10:22:29Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.5""
""xmp:CreatorTool"",""MicrosoftÂŽ Word 2016""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dc:creator"",""KSU""
""language"",""es""
""dcterms:created"",""2020-10-01T10:22:29Z""
""Last-Modified"",""2020-10-01T10:22:29Z""
""dcterms:modified"",""2020-10-01T10:22:29Z""
""dc:format"",""application/pdf; version=1.5""
""Last-Save-Date"",""2020-10-01T10:22:29Z""
""pdf:docinfo:creator_tool"",""MicrosoftÂŽ Word 2016""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2020-10-01T10:22:29Z""
""meta:save-date"",""2020-10-01T10:22:29Z""
""pdf:encrypted"",""false""
""modified"",""2020-10-01T10:22:29Z""
""Content-Length"",""1917860""
""pdf:hasMarkedContent"",""true""
""Content-Type"",""application/pdf""
""pdf:docinfo:creator"",""KSU""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""KSU""
""dc:language"",""en-US""
""meta:author"",""KSU""
""meta:creation-date"",""2020-10-01T10:22:29Z""
""created"",""2020-10-01T10:22:29Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""95""
""Creation-Date"",""2020-10-01T10:22:29Z""
""resourceName"",""edgar_tfm.pdf""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""303"",""456"",""581"",""640"",""1774"",""117"",""1493"",""2427"",""2625"",""2032"",""1585"",""94"",""2023"",""1093"",""1949"",""1379"",""1635"",""754"",""1364"",""1604"",""617"",""1555"",""1750"",""1794"",""1957"",""1960"",""1916"",""561"",""1629"",""2168"",""670"",""2046"",""1986"",""1817"",""543"",""1070"",""62"",""1645"",""1754"",""1770"",""1486"",""1974"",""1117"",""1954"",""877"",""1060"",""1401"",""2111"",""2306"",""1674"",""1077"",""1481"",""1109"",""581"",""804"",""804"",""1690"",""880"",""850"",""2059"",""1089"",""1175"",""1468"",""946"",""985"",""868"",""558"",""1175"",""1549"",""956"",""925"",""1594"",""389"",""1820"",""2108"",""2056"",""1882"",""1804"",""1324"",""150"",""2161"",""1790"",""1214"",""1785"",""1934"",""1713"",""1910"",""1382"",""361"",""1591"",""1786"",""1583"",""1506"",""4"",""5""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""Author"",""KSU""
""producer"",""www.ilovepdf.com""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""www.ilovepdf.com""
""pdf:docinfo:created"",""2020-10-01T10:22:29Z""
";https://scholar.google.ch/scholar?start=610&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098729-27;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;[LIVRE][B] Datenschutzrecht im Smart Metering unter Berücksichtigung der Blockchain-Technologie;V Lehner ;2020 books.google.com;;"Page 1. DATENSCHUTZ- BERATER Viktoria Lehner Datenschutzrecht im Smart Metering unter

Berücksichtigung der Blockchain-Technologie dfv Mediengruppe Page 2. Datenschutzrecht im

Smart Metering unter Berücksichtigung der Blockchain-Technologie Page 3 …";Autres articles;;null;;;;https://scholar.google.ch/scholar?start=570&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098778-131;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;A data privacy protection scheme for Internet of things based on blockchain;J Gong, Y Mei, F Xiang, H Hong… ; Transactions on …, 2020  Wiley Online Library;;"… of this scheme has slightly increased. Blockchain is the technology behind the Bitcoin

cryptocurrency system, so it is used to ensure enhanced security and privacy in the

IoT ecosystem. References 15, 16 used the Pow algorithm …";Autres articles;;null;;;;https://scholar.google.ch/scholar?start=680&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098751-74;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Estado del arte de la aplicación de la tecnología Blockchain en la Cadena de Suministro;I Olaizola Arregui ;2020 upcommons.upc.edu;;"… Page 21. Estado del arte de la aplicación de la tecnologia Blockchain en la CS Pag. 21 … Para esto,

es necesario que de alguna manera el contrato inteligente reciba información esta y para ello

existen los oracles (oráculos) (fuente: criptonoticias.com/criptopedia) …";Autres articles;Version HTML;[PDF] upc.edu;https://upcommons.upc.edu/bitstream/handle/2117/189124/tfm-v015-final.pdf;"
Treball de Fi de MĂ ster 
 

MĂĄster Universitario en IngenierĂ­a de OrganizaciĂłn 

 
  

 
 

 

Estado del arte de la aplicaciĂłn de la tecnologĂ­a 

Blockchain en la Cadena de Suministro 

 

 

 

MEMORIA 

 

 
 

 

 

 

 

 Autor:  Imanol Olaizola Arregui 

 Director:  Imma Ribas 

 Convocatòria:  Abril 2020  
 
 

 
 

 

Escola Tècnica Superior 
d’Enginyeria Industrial de Barcelona 



Pàg. 2  Memòria 

 



Estado del arte de la aplicaciĂłn de la tecnologia  Blockchain en la CS PĂ g. 3 

 

Resumen 

El presente trabajo tiene como objetivo analizar el estado actual de la tecnologĂ­a Blockchain 

en la Cadena de Suministro. 

Para ello, se ha diseĂąado y realizado una revisiĂłn sistemĂĄtica de la bibliografĂ­a para poder 

informarse y recolectar los artĂ­culos acadĂŠmicos que tenga mayor relaciĂłn con el tema 

analizado. Una vez recolectados estos artĂ­culos, se han leĂ­do y analizado para despuĂŠs 

agruparlos en tres grupos mayoritarios: trazabilidad, aplicaciones industriales y 

transparencia y reducciĂłn de costes. 

BasĂĄndonos en estas agrupaciones generales, se ha indagado en el estado actual que 

tiene la tecnologĂ­a Blockchain en las Cadenas de Suministros para asĂ­, ademĂĄs, detectar y 

enlistar los beneficios que dicha tecnologĂ­a puede proveer a las empresas actuales. Desde 

ventajas competitivas y revolucionarias que podrĂ­an ser clave para que muchas 

agrupaciones y cooperativas puedan seguir subsistiendo en el mercado hasta grandes 

proyectos para empresas industriales que facilitarĂ­an la integraciĂłn con sus proveedores y 

posibilitarĂ­an un mayor grado de automatizaciĂłn y optimizaciĂłn de recursos. 

Por otro lado, tambiĂŠn se han detallado y estudiado las limitaciones que puede llegar a 

tener dicha tecnologĂ­a, como falta de estandarizaciones o elevados costes de computaciĂłn 

y energĂ­a, convirtiĂŠndolo de esta manera una inversiĂłn arriesgada, puesto que puede que 

para ciertas empresas el coste sea demasiado elevado y no puedan llegar a rentabilizarlo. 

En todo caso, la tecnologĂ­a Blockchain ha venido para quedarse en las Cadenas de 

Suministro y en los prĂłximos aĂąos seguramente se presenciarĂĄn avances y mejoras que 

hagan de esta tecnologĂ­a una gran revoluciĂłn industrial. 

 

 



Pàg. 4  Memòria 

 

 



Estado del arte de la aplicaciĂłn de la tecnologia  Blockchain en la CS PĂ g. 5 

 

Sumario 

SUMARIO ____________________________________________________ 5 

ÍNDICE DE FIGURAS ___________________________________________ 7 

1. GLOSARIO _______________________________________________ 9 

2. INTRODUCCIÓN _________________________________________ 11 

2.1. Objetivos del proyecto .................................................................................. 11 

2.2. Alcance del Proyecto ................................................................................... 12 

3. LA TECNOLOGÍA BLOCKCHAIN ____________________________ 13 

3.1. En que se basa la tecnologĂ­a Blockchain .................................................... 14 

3.1.1. El Consenso ................................................................................................... 15 

3.1.2. Los Bloques .................................................................................................... 15 

3.1.3. Firma digital .................................................................................................... 18 

3.1.4. CĂłmo funciona la tecnologĂ­a Blockchain ........................................................ 19 

3.1.5. Contratos Inteligentes ..................................................................................... 21 

3.1.6. Tipos de redes Blockchain .............................................................................. 22 

4. LA TECNOLOGÍA BLOCKCHAIN EN LA CADENA DE SUMINISTRO25 

4.1. RevisiĂłn BibliogrĂĄfica ................................................................................... 26 

4.1.1. Paso 1 ............................................................................................................. 27 

4.1.2. Paso 2 ............................................................................................................. 27 

4.1.3. Paso 3 ............................................................................................................. 27 

4.1.4. Paso 4 ............................................................................................................. 28 

4.1.5. Paso 5 ............................................................................................................. 28 

4.1.6. Paso 6 ............................................................................................................. 28 

4.1.7. Paso 7 ............................................................................................................. 28 

4.2. ClasificaciĂłn de la DocumentaciĂłn AcadĂŠmica Seleccionada .................... 29 

5. ANÁLISIS DE LA LITERATURA _____________________________ 30 

5.1. Trazabilidad .................................................................................................. 31 

5.2. Aplicaciones Industriales .............................................................................. 43 

5.3. Transparencia y ReducciĂłn de Costes ........................................................ 53 

6. CONCLUSIONES _________________________________________ 63 

7. IMPACTO AMBIENTAL ____________________________________ 65 

8. PRESUPUESTO DEL PROYECTO ___________________________ 66 



Pàg. 6  Memòria 

 

AGRADECIMIENTOS __________________________________________ 67 

BIBLIOGRAFIA _______________________________________________ 68 

Referencias BibliogrĂĄficas..................................................................................... 68 

Índice de Tablas 

Tabla 1: Diferencia entre Blockchain PĂşblico y Privado. Fuente: propia.............................. 22 

Tabla 2: Pasos de la revisiĂłn sistemĂĄtica. Fuente: propia. .................................................. 26 

Tabla 3: Tipos de ClasificaciĂłn. Fuente: propia ................................................................... 29 

Tabla 4: Tabla resumen de los artĂ­culos analizados respecto a la trazabilidad. .................. 42 

Tabla 5: Tabla resumen de los artĂ­culos analizados respecto a las aplicaciones industriales

 ............................................................................................................................................. 52 

Tabla 6: Tabla resumen de los artĂ­culos analizados respecto a la transparencia y reducciĂłn 

de costes .............................................................................................................................. 62 

Tabla 7: Presupuesto del proyecto. Fuente: propia. ............................................................ 66 

 



Estado del arte de la aplicaciĂłn de la tecnologia  Blockchain en la CS PĂ g. 7 

 

Índice de Figuras 

Figura 1: Ejemplo de arquitectura de la secuencia de bloques. Fuente: Zheng, 2017. ....... 15 

Figura 2: Estructura de un bloque. Fuente: Zheng, 2017. ................................................... 16 

Figura 3: GeneraciĂłn de la cadena de bloques mediante transacciones. Fuente: (Crosby et 

al., 2016) .............................................................................................................................. 16 

Figura 4: Funcionamiento de una firma digital. Blair Marshall, 2015. .................................. 18 

Figura 5: Funcionamiento del Bitcoin. Fuente: cryptonario.net ............................................ 19 

Figura 6: Ejemplo del proceso de minado de bloque. Fuente: es.cointelegraph.com ......... 20 

Figura 7: BĂşsqueda en base datos y revisiĂłn sistemĂĄtica. (Casino, 2019) ......................... 30 

Figura 8: Importaciones de madera aserrada por paĂ­s. Fuente: (Vilkov, 2019) ................... 32 

Figura 9: Flujo de la producciĂłn y distribuciĂłn del tĂŠ. Fuente: Liao, et al., 2019. ................ 33 

Figura 10: Diagrama de Flujo para la recogida y almacenamiento de datos en la CS. 

Fuente: Borrero, 2018 .......................................................................................................... 34 

Figura 11:Arquitectura general de la cadena propuesta. Fuente: Salah et al., 2019 ........... 36 

Figura 12: Esquema de la GCOIN. Fuente: Tseng et al., 2018 ........................................... 38 

Figura 13: Flujo de Trabajo de la GCOIN. Fuente: Tseng et al., 2018 ................................ 38 

Figura 14: Capturas de la aplicaciĂłn SmartTree. Fuente: Figorilli, 2018 ............................. 40 

Figura 15: Estructura de OriginChain. Fuente: Lu y Xu, 2017. ............................................ 41 

Figura 16: Estructura de las conexiones con la Blockchain. Fuente: FernĂĄndez-CaramĂŠs, 

2019 ..................................................................................................................................... 43 

Figura 17: Resultados de los 4 test de inventario. Fuente: FernĂĄndez-CaramĂŠs, 2019 ...... 44 

Figura 18: Posibles mejoras de la Blockchain en la Industria AutomovilĂ­stica.  Fuente: 

Fraga-Lamas, 2019. ............................................................................................................. 45 

Figura 19: Diagrama de Flujo para la Blockchain. Fuente: Fraga-Lamas, 2019. ................ 47 



Pàg. 8  Memòria 

 

Figura 20: Esquema del ensamblaje. Fuente: Madhwal y Panfilov (2017) .......................... 51 

Figura 21: Arquitectura del sistema. Fuente: Harshavardhan et al., (2019) ........................ 55 

Figura 22: ComparaciĂłn de precios de venta por cada usuario de la CS. Fuente: 

Harshavardhan et al., (2019) ............................................................................................... 56 

Figura 23: Arquitectura Blockchain planteada. Fuente: Baumung y Fomin (2018). ............ 58 

Figura 24: Portal web de la Blockchain. Fuente: Baumung y Fomin (2018). ....................... 58 



Estado del arte de la aplicaciĂłn de la tecnologia Blockchain en la CS Pag. 9 

 

1. Glosario 

BC: Blockchain. Se entiende como Blockchain una estructura de datos en la que la 

informaciĂłn contenida se agrupa en conjuntos (bloques) a los que se les aĂąade 

metainformaciones relativas a otro bloque de la cadena anterior en una lĂ­nea temporal, de 

manera que, gracias a tĂŠcnicas criptogrĂĄficas, la informaciĂłn contenida en un bloque solo 

puede ser repudiada o editada modificando todos los bloques posteriores. 

HASH: es un algoritmo criptogrĂĄfico unidireccional, es decir, solo se puede calcular en una 

direcciĂłn y no se puede decodificar de vuelta. En el caso del Bitcoin el hash usado es el 

SHA-256, donde el resultado estĂĄ compuesto de 62 dĂ­gitos hexadecimales. 

IdC: Internet de las Cosas. Se define como la interconexiĂłn a travĂŠs de Internet de 

dispositivos informĂĄticos integrados en objetos cotidianos, lo que les permite enviar y recibir 

datos. Es decir, el IdC hace conectar los aparatos a Internet para asĂ­ poder habilitar nuevas 

funciones como por ejemplo controlar elementos inteligentes de forma remota y recibir 

alertas. 

P2P: Red Peer-to-Peer. Es entendido como es una red de ordenadores en la que todos o 

algunos aspectos funcionan sin clientes ni servidores fijos, sino una serie de nodos que se 

comportan como iguales entre sĂ­. Es decir, actĂşan simultĂĄneamente como clientes y 

servidores respecto a los demĂĄs nodos de la red. Las redes P2P permiten el intercambio 

directo de informaciĂłn, en cualquier formato, entre los ordenadores interconectados. 

CS: Cadena de Suministro o Supply Chain. Definido por la APICS se entiende como Supply 

chain “un sistema de organizaciones, personas, tecnologías, actividades, información y 

recursos involucrados en el movimiento de materiales, productos y servicios durante todo el 

proceso de fabricaciĂłn, desde el proveedor original del proveedor de materiales hasta el 

cliente final.” 

HA-256: es un conjunto de funciones hash criptogrĂĄficas diseĂąadas por la Agencia de 

Seguridad Nacional (NSA) y publicada en 2001 por el Instituto Nacional de EstĂĄndares y 

TecnologĂ­a (NIST) como un EstĂĄndar Federal de Procesamiento de la InformaciĂłn (FIPS). 

Es un algoritmo que transforma un conjunto arbitrario de elementos de datos, como puede 

ser un fichero de texto, en un Ăşnico valor de longitud fija, el hash. 

Tiempo Unix: tambiĂŠn conocido como Tiempo POSIX es un sistema para la descripciĂłn de 

instantes de tiempo. Se define como la cantidad de segundos transcurridos desde la 

medianoche UTC del 1 de enero de 1970, sin contar segundos intercalares. 



Pag. 10  Memoria 

 

Timestamp: es una secuencia de caracteres que denotan la hora y fecha (o alguna de 

ellas) en la/s que ocurriĂł determinado evento. Es un tĂŠrmino muy usado en la informĂĄtica 

para referirte al tiempo en las BBDD, programaciĂłn, etc. 

Smart Factory: La fĂĄbrica inteligente es un sistema flexible que puede optimizar el 

rendimiento a travĂŠs de una red mĂĄs amplia, adaptarse y aprender de las nuevas 

condiciones en tiempo real o casi real, y ejecutar de forma autĂłnoma procesos de 

producciĂłn completos. 



Estado del arte de la aplicaciĂłn de la tecnologia Blockchain en la CS Pag. 11 

 

2. IntroducciĂłn 

En un entorno globalizado como el actual las empresas deben ser competitivas para 

mantenerse en el mercado. Esta competitividad, en muchos casos, se logra a travĂŠs de la 

cadena de suministro donde diferentes empresas, que pueden estar en diferentes paĂ­ses, 

deben colaborar y coordinarse para alcanzar un objetivo comĂşn. Esta coordinaciĂłn no 

siempre es fĂĄcil y es uno de los mayores retos a los que se tienen que enfrentar. 

En los Ăşltimos 20 aĂąos han surgido diferentes iniciativas para lograr esta coordinaciĂłn y 

colaboraciĂłn en las que la tecnologĂ­a, en particular los sistemas de la informaciĂłn han 

jugado un rol destacado. Aun asĂ­, el reto y la necesidad de mejorar estos aspectos estĂĄ 

vigente. 

Una de las tecnologĂ­as que podrĂ­a marcar el antes y despuĂŠs de la cadena de suministro 

podrĂ­a ser la tecnologĂ­a Blockchain. Una tecnologĂ­a transparente, segura e inmutable que 

es considerada de las mayores revoluciones de la Ăşltima dĂŠcada.  

Esta tecnologĂ­a ha empezado a aplicarse para resolver problemas de coordinaciĂłn 

existentes en algunos sectores, aunque todo su potencial aĂşn estĂĄ por llegar. Es por tanto 

que se ha propuesto realizar este trabajo para asĂ­ ver y analizar el estado del arte de esta 

tecnologĂ­a aplicado a la cadena de suministro. 

2.1. Objetivos del proyecto 

El objetivo de este proyecto es analizar las aplicaciones que la tecnologĂ­a Blockchain ha 

tenido en la cadena de suministro, los beneficios que ha aportado y las barreras que 

encuentra, actualmente, su aplicaciĂłn. Este objetivo general se divide en los siguientes 

objetivos especĂ­ficos: 

 Buscar y obtener los Ăşltimos artĂ­culos acadĂŠmicos e informes relacionados con el 

estado del arte de la aplicaciĂłn de la tecnologĂ­a Blockchain en la cadena de suministro. La 

bĂşsqueda se harĂĄ en las bases de datos SCOPUS y Web of Science, pero tambiĂŠn en 

Google Scholar ya que al ser una tecnologĂ­a tan reciente se debe ampliar la bĂşsqueda en 

otras bases de datos menos exigentes. 

 Analizar los artĂ­culos que estĂŠn directamente relacionados con la aplicaciĂłn de la 

tecnologĂ­a Blockchain en la cadena de Suministro. 

  



Pag. 12  Memoria 

 

 Identificar los beneficios que el uso de esta tecnologĂ­a ha tenido para la cadena de 

suministro, asĂ­ como las barreras principales para su uso. 

2.2. Alcance del Proyecto 

El proyecto se centra en buscar informaciĂłn respecto al tema y analizar los beneficios que 

ha aportado sin desarrollar o llevar a cabo un proyecto de Blockchain en una cadena de 

suministro de manera empĂ­rica y prĂĄcticas. 



Estado del arte de la aplicaciĂłn de la tecnologia Blockchain en la CS Pag. 13 

 

3. La TecnologĂ­a Blockchain 

La tecnologĂ­a Blockchain se basa en la combinaciĂłn de tecnologĂ­as de intercambio, 

procesamiento y almacenamiento de datos entre mĂşltiples participantes basados en 

criptografĂ­a moderna, protocolo de consistencia distribuida, tecnologĂ­a de comunicaciĂłn de 

red punto a punto y lenguaje de programaciĂłn de contratos inteligentes (Huang et al., 

2019). Otra definiciĂłn podrĂ­a ser la de un registro distribuido e inmutable de informaciĂłn, y 

al mismo tiempo integrable y programable (Garcia, 2019). 

Estas definiciones pueden llegar a ser demasiado tĂŠcnicas y complejas, pero se puede 

explicar de una manera mĂĄs sencilla utilizando un sĂ­mil. La tecnologĂ­a Blockchain es como 

un libro de contabilidad de una empresa en el cual se anota la entrada y salida de 

transacciones y se coteja con el de las empresas que lo reciben (Christidis, 2016). Hoy en 

dĂ­a si una persona transfiere una cantidad de dinero, estĂĄ obligada a hacerlo mediante los 

intermediarios financieros tradicionales (como pueden ser los bancos o las empresas 

digitales como Paypal) los cuales certifican, validan su identidad y registran la transacciĂłn. 

En el caso de la Blockchain no hay necesidad de intermediarios puesto que esta 

transferencia se da directamente del emisor al receptor (Nakamoto, 2008). La cadena de 

bloques actĂşa como una fuente inmutable y segura que no permite errores y provee a los 

usuarios una fiabilidad total respecto a sus transferencias (Christidis, 2016). 

Mediante la tecnologĂ­a Blockchain, por lo tanto, se consigue eliminar la necesidad de este 

tercero evitando asĂ­ posibles costes aĂąadidos (Christidis, 2016). Esto significa que ninguna 

entidad obtendrĂ­a los datos de las transferencias, evitando asĂ­ cualquier tipo de 

compraventa de datos (Contreras, 2015). El ejemplo mĂĄs comĂşn de la tecnologĂ­a 

Blockchain es la transferencia financiera, pero esta tecnologĂ­a es posible usarla para 

transferir cualquier tipo de datos, con lo cual, se puede encontrar aplicaciones en sectores 

totalmente diferentes. 

Dicha tecnologĂ­a fue usada por primera vez para la criptomoneda Bitcoin, presentada por 

Satoshi Nakamoto el 2009, supuesta identidad falsa para referirse a los creadores del 

Bitcoin que podrĂ­an ser una o varias personas (Davis, 2011). El supuesto creador, publicĂł 

un artĂ­culo en metzdowd.com en el aĂąo 2008 que describĂ­a un sistema P2P de dinero 

digital. El siguiente aĂąo, lanzĂł el software Bitcoin, creando la red necesaria con el mismo 

nombre y las primeras monedas tambiĂŠn llamadas Bitcoin (Nakamoto, 2008). 

Por suerte, la tecnologĂ­a Blockchain no tiene por quĂŠ estar limitado al mercado de las 

criptomonedas, es mĂĄs, los diferentes usos que se le pueden dar son casi ilimitados. De 

acuerdo con Melanie Swan, fundadora del Institute for Blockchain Studies, es posible dividir 



Pag. 14  Memoria 

 

los diferentes tipos de Blockchain en tres categorĂ­as (Swan, 2015), basĂĄndonos en el uso 

que se les es dado. 

 

 Blockchain 1.0 – es el uso de la moneda, el despliegue de criptomonedas en 

aplicaciones relacionadas con efectivo, como transferencia de divisas, remesas y 

sistemas de pago digital. 

 Blockchain 2.0 – es el uso de contratos, todo lo que es abarcado por la economía, 

aplicaciones financieras y de mercado que usan Blockchain y que son mĂĄs 

extensas que transacciones simples de efectivo: acciones, bonos, prĂŠstamos, 

hipotecas, tĂ­tulos, propiedad inteligente, contratos inteligentes. 

 Blockchain 3.0 – son las aplicaciones de Blockchain más allá de la moneda, las 

finanzas y los mercados particularmente en las ĂĄreas de gobierno, salud, ciencia, 

cultura y arte.  

3.1. En que se basa la tecnologĂ­a Blockchain 

Para conseguir comprender la tecnologĂ­a Blockchain es necesario entender la naturaleza y 

el funcionamiento de la cadena de bloques. Siguiendo con el sĂ­mil anterior, se puede 

entender la cadena de bloques o Blockchain como un libro de contabilidad en el que las 

anotaciones se agrupan en bloques con una marca de tiempo (tambiĂŠn conocido como 

Timestamp) para cada anotaciĂłn.  

Cada bloque tiene un nĂşmero identificador que lo hace diferente del resto de los bloques. 

Por otro lado, cuando un bloque es aĂąadido a la cadena, se aĂąade al bloque el nĂşmero 

identificador del bloque anterior. De esta manera todos los bloques tienen el nĂşmero que 

identifica a su bloque anterior, ratificando el orden de los bloques y haciendo posible 

encontrar su ubicaciĂłn en caso de querer buscarlos (Christidis, 2016).  La cadena puede 

verse en la Figura 1 con los componentes de los bloques que se explicarĂĄn mĂĄs en detalle 

en el apartado 3.1.2. 



Estado del arte de la aplicaciĂłn de la tecnologia Blockchain en la CS Pag. 15 

 

 

Figura 1: Ejemplo de arquitectura de la secuencia de bloques. Fuente: Zheng, 2017. 

Para que la cadena de bloques pueda funcionar existen tres conceptos necesarios que 

estĂĄn relacionados entre ellos; el consenso, los bloques y la firma digital. 

3.1.1. El Consenso 

Una de las claves para que la tecnologĂ­a Blockchain funcione es el consenso. TambiĂŠn 

conocido como “consensus”, es basado en la aceptación por todos los miembros de la red 

Blockchain de que la informaciĂłn que se tiene es correcta y de que el bloque puede ser 

validado y aceptado en la cadena (fuente: academy.bit2me.com).  

Para desarrollar estos consensos existen diferentes tipos de algoritmos de consenso 

siendo el mĂĄs conocido la Prueba de Trabajo o Proof-of-Work, usado por ejemplo por 

Bitcoin. Este tipo se basa en obtener el cĂłdigo hash (lo que serĂ­a como un nĂşmero 

identificador) de cada bloque mediante prueba y error heurĂ­stico y al haber conseguido el 

nĂşmero, compartirlo con los otros nodos para que confirmen que el cĂłdigo coincide con el 

bloque (fuente: hashcash.org). El proceso de obtener el hash es mĂĄs conocido como 

minerĂ­a y es explicado en detalle en el apartado 3.1.4. 

En el caso de la red Bitcoin, la informaciĂłn se agrupa en bloques y estos son validados 

mediante el minado. El minado no es mĂĄs que la sincronizaciĂłn de todos los nodos que 

forman parte de la red, para que mediante esta sincronizaciĂłn puedan estar seguros de 

que la informaciĂłn es correcta y no existen manipulaciones (fuente: academy.bit2me.com). 

Este proceso es explicado mĂĄs en detalle en el pĂĄrrafo 3.1.4. 

3.1.2. Los Bloques 

El bloque consiste en dos partes generales: la cabecera del bloque (block header) y el 

cuerpo (block body). 



Pag. 16  Memoria 

 

 

Figura 2: Estructura de un bloque. Fuente: Zheng, 2017. 

La cabecera del bloque es donde se ubican la mayorĂ­a de los parĂĄmetros del bloque 

(Zheng, 2017) como es posible verlo en la Figura 2. Este estĂĄ compuesto por elementos 

como la versiĂłn del bloque, el nĂşmero hash del bloque anterior, la marca de tiempo, etc. Es 

donde se ubican todas las caracterĂ­sticas tĂŠcnicas que dan informaciĂłn sobre el bloque y 

su posiciĂłn en la cadena. 

Por otra parte, el cuerpo del bloque es donde se acumula casi toda la informaciĂłn. EstĂĄ 

compuesto por dos apartados: el contador de transacciones, para llevar un registro de 

cuantas transacciones se encuentran en el bloque, y las mismas transacciones, es decir, 

en el caso del Bitcoin por ejemplo cuantas unidades Bitcoin se han transferido del usuario A 

al B. El nĂşmero mĂĄximo de transacciones que un bloque puede contener depende del 

tamaĂąo del bloque y del tamaĂąo de cada transacciĂłn. 

 

 

Figura 3: GeneraciĂłn de la cadena de bloques mediante transacciones. Fuente: (Crosby et al., 2016) 

En la Figura 3 se puede ver una representaciĂłn grĂĄfica mĂĄs simplificada de la creaciĂłn de 

bloques con las transacciones y diferentes hash. Por ejemplo, en el bloque de la izquierda, 

el “Block # 2A4” sería el hash del bloque. El elemento “Prev #9DA” sería el hash del bloque 



Estado del arte de la aplicaciĂłn de la tecnologia Blockchain en la CS Pag. 17 

 

anterior y por último “Tx dc8” y “Tx ab3” representarían los datos guardados en ese bloque. 

Por otro lado, podemos ver arriba las transacciones que todavĂ­a no han sido confirmadas y 

por lo tanto no han pasado a ser parte de un nuevo bloque. 



Pag. 18  Memoria 

 

3.1.3. Firma digital 

En las redes de tecnologĂ­a Blockchain, cada usuario posee una clave privada y una clave 

pĂşblica. La llave pĂşblica puede ser distribuida a cualquier otro usuario sin ningĂşn tipo de 

riesgo. La clave privada por otro lado, solo debe ser conocida por su dueĂąo. Las claves son 

lĂ­neas alfanumĂŠricas con una extensiĂłn determinada (PĂŠrez, 2015). 

De esta manera, la persona que actĂşa de remitente puede cifrar cualquier mensaje con la 

llave pĂşblica del destinatario. Con el mensaje cifrado, solo la llave privada de ese receptor 

puede descifrarlo debido a que existe una relaciĂłn matemĂĄtica entre ambas llaves. 

Dicho esto, se define como firma digital la combinaciĂłn entre una llave privada y un hash de 

los datos a firmar (como puede ser por ejemplo una transacciĂłn). Esta combinaciĂłn de 

ambos componentes da una identificaciĂłn digital Ăşnica para demostrar la autenticidad del 

mensaje, sin revelar en ningĂşn momento la llave privada del firmante. 

 

Figura 4: Funcionamiento de una firma digital. Blair Marshall, 2015. 

Usando la Figura 4 como guĂ­a, se plantea el siguiente ejemplo. Un usuario llamado, Jon, 

quiere enviar a otro usuario, Alex, un mensaje (dĂ­gase una transacciĂłn de Bitcoins). Para 

que esta transacciĂłn pueda ser vĂĄlida, debe estar firmada por la llave privada de Jon y Alex 

debe validar que la firma es autĂŠntica. Para asegurarlo, la tecnologĂ­a Blockchain sigue los 

siguientes pasos: 

i. Jon toma los datos de la transacciĂłn y utiliza el algoritmo SHA-256 para cifrarlo con 

un resultado de un hash de 64 caracteres. 

ii. El hash se “firma” con la llave privada de Jon, obteniendo como resultado dos 



Estado del arte de la aplicaciĂłn de la tecnologia Blockchain en la CS Pag. 19 

 

nĂşmeros conocidos como R y S. Estos tienen un peso variable entre 71 y 73 bytes, 

y es esto lo que considerarĂ­amos una firma digital. 

iii. Se manda a Alex los datos de la transacciĂłn, la clave pĂşblica de Jon y la firma 

digital. 

iv. Con la llave pĂşblica de Jon, el sistema podrĂĄ descifrar la firma digital para conseguir 

el hash correspondiente a los datos de la transacciĂłn, que previamente Jon habĂ­a 

cifrado con SHA-256 y su llave privada. 

v. Como los datos de la transacciĂłn tambiĂŠn fueron recibidos por Alex, el sistema 

repite el proceso de cifrarlos para asĂ­ conseguir el hash correspondiente. 

Con los hashes obtenidos en los pasos 4 y 5, se verifica que ambos sean iguales. Si esto 

no es asĂ­, significarĂ­a que los datos han sido alterados por alguien o que la clave pĂşblica de 

Jon no corresponde con su clave privada. Debido a esto, la transacciĂłn no serĂ­a vĂĄlida, ya 

que ha sido modificada durante el trĂĄnsito o la llave no corresponde al dueĂąo de los fondos. 

 

3.1.4. CĂłmo funciona la tecnologĂ­a Blockchain 

Para comprender el potencial de la tecnologĂ­a Blockchain, es necesario entender cuĂĄl cual 

es el funcionamiento de toda la cadena para asĂ­ entender sus puntos fuertes y tambiĂŠn las 

limitaciones que puede llegar a tener. BasĂĄndonos en el ejemplo del Bitcoin vĂŠase la Figura 

5. 

 

Figura 5: Funcionamiento del Bitcoin. Fuente: cryptonario.net 



Pag. 20  Memoria 

 

El proceso se puede dividir en seis partes. El estado inicial es cuando un usuario A quiere 

hacer una transferencia de informaciĂłn (en este caso monetaria) al usuario B. Esta 

transacciĂłn es mandada a la red y es aĂąadida a un conjunto de transacciones que 

terminarĂĄn componiendo un bloque. Como se ha explicado anteriormente, los bloques 

estĂĄn compuestos mayoritariamente por un cĂşmulo de transacciones. 

La cantidad de informaciĂłn o transacciones que agrupa cada bloque es definida por la red, 

en el caso del Bitcoin se crea un bloque cada 10 minutos juntando asĂ­ todas las 

transacciones que se hayan dado a lo largo de esos 10 minutos. Una vez se haya 

completado un bloque se da el aviso a la red compuesta por nodos. Los nodos, son puntos 

de la red que se pueden crear, recibir y/o transmitir un mensaje. En el caso del Bitcoin, 

cualquier nodo que se conecte a la interfaz puede ser considerado como un nodo en el 

sentido de que se comunican de alguna manera entre sĂ­ (Tschorsch, 2016).  

TambiĂŠn existe la figura del nodo completo o nodo de validaciĂłn total los cuales estĂĄn 

involucrados en el proceso de verificar las transacciones y los bloques con respecto a las 

reglas de consenso del sistema. Dichos nodos tambiĂŠn pueden transmitir nuevas 

transacciones (fuente: binance.vision/es). Normalmente un nodo completo tendrĂĄ 

descargada una copia de la Blockchain de Bitcoin con cada bloque y transacciĂłn que haya 

ocurrido. 

Estos usuarios son los que aseguran que la red sea inmutable y segura porque tienen una 

copia de cada uno de los bloques que ya estĂĄn aĂąadidos a la cadena. 

Algunos nodos (usuarios) tienen el estatus de mineros. Estos al recibir la seĂąal de que un 

bloque está cerrado, empiezan a “minar” el bloque. El minado se basa en conseguir el 

clave hash del bloque. Para conseguir el hash es necesario un nivel de computaciĂłn muy 

alto, es por esto que la metodologĂ­a usada por los mineros es el ensayo y error heurĂ­stico. 

De esta manera van probando diferentes resultados y el usuario que acierte con el hash se 

queda con el minado. 

Figura 6: Ejemplo del proceso de minado de bloque. Fuente: es.cointelegraph.com 



Estado del arte de la aplicaciĂłn de la tecnologia Blockchain en la CS Pag. 21 

 

Cuando un minero da con el hash correcto, lo hace saber a todos los demĂĄs nodos de la 

red y estos verifican que el hash coincide con el bloque como se puede ver en la Figura 6. 

A pesar de que descifrar el hash requiere una capacidad de computaciĂłn elevada, 

comprobar si la soluciĂłn es la correcta con el resultado es rĂĄpido y sencillo, por lo tanto, es 

instantĂĄneamente comprobado por todos los nodos de la red. 

Cuando todos los usuarios de la red dan el visto bueno confirmando que el hash es el 

correcto, este bloque es aĂąadido a la cadena de bloques y al minero que ha conseguido 

descifrarlo se le da una recompensa (en el caso del Bitcoin, recibe 12,5 Bitcoins). 

AsĂ­, cuando el bloque ha sido consensuado y ha quedado consolidado en la cadena, la 

transferencia se da por realizada y todos los nodos pueden asegurar que ese proceso ha 

sido efectuado. 

3.1.5. Contratos Inteligentes 

Un contrato inteligente es de hecho un contrato, pero en vez de estar firmado en un papel 

es un programa informĂĄtico que asegura que, si ambas partes del contrato cumplen con lo 

establecido, se llevara a cabo el acuerdo planteado en dicho contrato (Christidis, 2016). 

Esto se puede llevar a cabo en temas monetarios, por ejemplo. DĂ­gase, por ejemplo, que 

Juan quiere apostar una cantidad de X bitcoins a favor de que el Futbol Club Barcelona 

gana el siguiente partido y apuesta con Joan por el resultado contrario. Ambos podrĂ­an 

depositar los fondos en un Smart contract o contrato inteligente para de esta manera 

asegurarse de que una vez se termine el partido y se sepa el resultado, el ganador se lleve 

los fondos apostados. Para esto, es necesario que de alguna manera el contrato inteligente 

reciba informaciĂłn esta y para ello existen los oracles (orĂĄculos) (fuente: 

criptonoticias.com/criptopedia). Estos son el medio que conduce el flujo de informaciĂłn del 

mundo real a los contratos inteligentes (Luu, 2016). 

Otro uso Ăştil de los contratos inteligentes cada vez mĂĄs popular, es el uso de esta 

herramienta con el IoT (fuente: criptonoticias.com/criptopedia). Por ejemplo, imagĂ­nese que 

se tiene una casa inteligente y Juan quiere comprar la casa de Judith mediante cuotas 

mensuales. Ambos llegan a un acuerdo y utilizan una plataforma de contratos inteligentes 

(como podrĂ­a ser Ethereum o SmartContract) para crear un contrato inteligente que 

programe todos los tĂŠrminos establecidos entre ambos. 

Entre estos tĂŠrminos estarĂĄ que Juan pagarĂĄ una cantidad X de dinero antes de cierta 

fecha cada mes, y si no, al ser una casa inteligente el contrato ordenara a la cerradura de 

la casa que se bloquee. Por otro lado, si todos los pagos se realizan co";"""date"",""2020-04-20T17:36:00Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""Plantilla PFC""
""xmp:CreatorTool"",""MicrosoftÂŽ Word 2016""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""Plantilla PFC""
""language"",""es""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""MicrosoftÂŽ Word 2016""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""Plantilla PFC""
""modified"",""2020-04-20T17:36:00Z""
""cp:subject"",""Plantilla PFC""
""pdf:docinfo:subject"",""Plantilla PFC""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""Rafael Ruiz""
""meta:author"",""Rafael Ruiz""
""meta:creation-date"",""2020-04-20T17:36:00Z""
""created"",""2020-04-20T17:36:00Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-04-20T17:36:00Z""
""resourceName"",""tfm-v015-final.pdf""
""Author"",""Rafael Ruiz""
""producer"",""MicrosoftÂŽ Word 2016""
""pdf:docinfo:producer"",""MicrosoftÂŽ Word 2016""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""access_permission:modify_annotations"",""true""
""dc:creator"",""Rafael Ruiz""
""dcterms:created"",""2020-04-20T17:36:00Z""
""Last-Modified"",""2020-04-20T17:36:00Z""
""dcterms:modified"",""2020-04-20T17:36:00Z""
""title"",""Plantilla PFC""
""Last-Save-Date"",""2020-04-20T17:36:00Z""
""pdf:docinfo:modified"",""2020-04-20T17:36:00Z""
""meta:save-date"",""2020-04-20T17:36:00Z""
""Content-Length"",""1142271""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Rafael Ruiz""
""dc:language"",""es-ES""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""73""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""338"",""17"",""1764"",""18"",""3159"",""1296"",""2516"",""617"",""2583"",""513"",""2176"",""410"",""2876"",""1762"",""1769"",""1313"",""320"",""1642"",""1429"",""2142"",""2829"",""2370"",""2580"",""242"",""2793"",""2267"",""2465"",""2110"",""1445"",""1240"",""2325"",""2053"",""1311"",""2479"",""3048"",""1871"",""2374"",""1109"",""3039"",""2093"",""2066"",""2299"",""1303"",""1716"",""2310"",""2887"",""1294"",""2534"",""2956"",""2185"",""1980"",""1680"",""2399"",""2794"",""837"",""978"",""2969"",""897"",""3049"",""2596"",""2859"",""2161"",""2849"",""1085"",""2720"",""2066"",""1136"",""1982"",""2162"",""2122"",""2163"",""2117"",""486""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-04-20T17:36:00Z""
";https://scholar.google.ch/scholar?start=620&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098743-51;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;?????????? ?????????? ?????-?????????? ? ????????-???????? ??????????;?? ???????, ?? ????????? ; ?????????? ???????????, 2020  elibrary.ru;;"… ???????? ?? ?????????? ?????: SECURE USE OF SMART-CONTRACTS IN

BLOCKCHAIN MANAGEMENT SYSTEMS. GUMEROV EMIL A. 1 ,. ALEKSEEVA TAMARA V.

1. 1 Moscow University for Industry and Finance ŤSynergyť, Moscow, Russia …";Cité 1 fois;Les 3 versions;null;;;;https://scholar.google.ch/scholar?start=600&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098861-328;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;[CITATION][C] Off-Chain Trusted Computing;L Zhang, S Bakshi, JK Zao ; IEEE Internet of Things Magazine, 2020  ieeexplore.ieee.org;;"… The specification offers a set of standardized application pro- gramming interfaces (APIs)

to create, inspect, share and re-use application programs for Blockchain transactions that

require privacy, oracle services or computation-intensive workload …";;null;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/8548628/9125412/09125420.pdf;"
		
	";"""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""dc:title"",""IEEE Xplore Full-Text PDF:""
""Content-Encoding"",""UTF-8""
""resourceName"",""09125420.pdf""
""language"",""es""
""Content-Length"",""2565""
""title"",""IEEE Xplore Full-Text PDF:""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.ch/scholar?start=870&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098822-240;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;[CITATION][C] FRONT MATTER ii-iv PREFACE v LIST OF REVIEWER vi-viii TABLE OF CONTENT ix-xix;DK Fiade, HT Sukmana ; ieeexplore.ieee.org;;"… Noriaki Kamiyama 259-266 Converging Artificial Intelligence and Blockchain

Technology using Oracle Contract in Ethereum Blockchain Platform 38 Richard,

Mahenda Metta Surya, Avenia Clarissa Wibowo 267-272 The Role …";;null;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/9288361/9288512/09288620.pdf;"
		
	";"""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""dc:title"",""IEEE Xplore Full-Text PDF:""
""Content-Encoding"",""UTF-8""
""resourceName"",""09288620.pdf""
""language"",""es""
""Content-Length"",""2565""
""title"",""IEEE Xplore Full-Text PDF:""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.ch/scholar?start=780&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098848-298;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Next-generation Blockchain-Enabled Virtualized Cloud Security Solutions: Review and Open Challenges;M Uddin, A Khalique, AK Jumani ;2020 techrxiv.org;;"… Notably, the security is improved by using blockchain-enabled smart contracts to allows

distributed data control by cloud owners [52]. Sharma, proposed a cryptocurrency enabled

blockchain solution for reducing cloud security risks [53] …";Autres articles;;[PDF] techrxiv.org;https://www.techrxiv.org/articles/preprint/Next-generation_Blockchain-Enabled_Virtualized_Cloud_Security_Solutions_Review_and_Open_Challenges/13233887/files/25486871.pdf;"
Next-generation Blockchain-Enabled Virtualized Cloud Security Solutions: 

Review and Open Challenges  

Mueen Uddin1, Anjum Khalique2, Awais Khan3 
1,3Faculty of Science & Technology 

Ilma University Karachi Pakistan  

2SZABIST Hyderabad 
 
  

Abstract 

Cloud computing is a well-known technology that provides flexible, efficient, and cost-effective IT 

solutions for multinationals to offer improved and enhanced quality of business services to end-users. 

The Cloud computing paradigm is instigated from grid and parallel computing models as it uses 

virtualization, server consolidation, utility computing, and other computing technologies and models for 

providing better IT solutions for large-scale computational data centers. It encompasses different services 

for supporting data storage, networking, and computing facilities and amenities for businesses and 

multinational corporations. The enormous elastic on-demand cloud provisioning resources and services 

and datasets are processed and stored in tier level virtualized cloud data centers operated by third-party 

service providers called cloud owners. The primary issue with these cloud service providers is to provide 

and maintain data security, privacy, and confidentiality, as well as service availability and data support 

for end-users. This paper reviews, discusses, and highlights some of the standard cloud computing 

vulnerabilities primarily related to virtualization platforms and their implementations while outsourcing 

services and resources to different end-users and business enterprises. Furthermore, we provide 

Blockchain-enabled solutions for virtualized cloud computing platform involving both the end-users as 

well as cloud service providers (CSP) to address and solve different security and privacy-related 

vulnerabilities using blockchain-enabled solutions to improve their cloud services and resource 

provisioning facilities.  

Keywords: Blockchain; Cloud Data Center; Cloud Vulnerabilities; Virtualization vulnerabilities. 

Introduction 

In today's era of ‘Digital World’, everything is available and accessible on the Internet through various 

technology-enabled solutions. Cloud computing is one of the data storage and access platform where 

client data is stored and accessed through digital devices and gadgets from any locations using the Internet 

platform. It provides end-users with the facility to effortlessly research out on their data records, software 

and application tools, infrastructure platforms, and several additional cloud-enabled services and 

facilities. The current revolution in information edge in the form of big data and IoT engenders several 

security-related challenges that need to be solved and appropriately handled to help business enterprises 

grow and make better decisions for their business benefits. One of the critical questions is: how to store, 

access, and adequately manage these enormous quantities of data being generated through Information 

Communication Technology (ICT). Cloud Computing offers and provides the most flexible, reliable, and 

efficient ways to handle this vast data using Cloud Data Centers, which are also called as data farms or 

server farms where millions of server machines are arranged and placed in different infrastructures and 

models such as blade servers, racks, etc., to provide on-demand provisioning services and facilities to 

end-users and business firms [1]. The cloud computing platform is an innovative, extended, and improved 

computing facility compared to existing computing models such as grid and parallel computing, 

autonomic, and utility computing infrastructures based on a centralized client-server computing model 

being implemented and deployed in large tier level data centers [2]. It provides a ubiquitous service 

distribution model where different infrastructure facilities are provided to end-users in the form of a wide 

range of services such as personal file sharing to enterprise data warehouses [3].  

It is essential to highlight that today’s virtualized tier level cloud computing platforms require improved 

collaboration, responsiveness, promptness, and scalability features involving new technologies to enable 

better and dynamic on-demand service allocation and provisioning at the client level to support and 



enhance industrial throughputs, global competitive advantage using business analytical tools, etc. [4, 5]. 

As cloud computing provides efficient, reliable, flexible, scalable, cost-effective, and agility based 

solutions, its usage, adoption, and migration has tremendously enlarged and is helping the business 

enterprises earn better revenues every year [6]. This trend is helping CSPs, and their market share is 

increasing to more than 12% in software-based companies only with increased revenue of almost $95 

billion in the next five years of technology [7]. One of the significant advantages of cloud computing is 

its reliable and high-speed X as a Service (XaaS) facility, where different application and computing 

development processes and platforms are provided to clients on-demand enabling them to save huge costs 

of installations and deployments as shown in figure 1[8, 9]. 

 

Figure 1: Cloud Reference Architecture 

In a virtualized cloud computing infrastructure facility, different types of services provided by CSPs 

include Infrastructure as Service (IaaS), software as a Service (SaaS), and Platform as a Service (PaaS) 

where cloud users can easily download and upload their required content from cloud storage and network 

systems, from anyplace and anywhere in the world using high-speed Internet [10, 11]. The profligate 

rising of cloud computing adoption and migration is unavoidable as the majority of the people are 

becoming more and more dependent on the technology by storing their sensitive data and information on 

outsources cloud platforms owned by CSPs. It is causing severe security risks and breaches, allowing 

attackers and cybercriminals to break into clients' data and services and cause substantial potential losses 

to cloud infrastructure platforms and systems [12]. Some of the major cloud security breaches include 

security at the physical level, virtual level, and, more importantly, web-based in tier level virtualized 

cloud data centers [13, 14]. Furthermore, there are security gaps that exist between end-user and vendor 

assessments of cloud security, privacy, and transparency [15]. Similarly, the majority of enterprises with 

sensitive data such as banks, financial institutions, insurance companies, etc., are also very reluctant to 

choose cloud computing services and platforms as their primary concern rotate around the integrity, 

privacy, secrecy, and confidentiality of their data being stored and accessed from the cloud platform [16].  

The services provided by virtualized cloud infrastructure acts as a black box to the end-user who has no 

idea and visibility about the location of actual storage and network mechanisms being used in the cloud 

data center.  In a multi-tenant environment, where a client has no idea about what’s happening inside the 

cloud infrastructure engenders different vulnerabilities such as CSP system administrator can easily 

change operational functionality of different virtual machines (VMs) running in the facility as well as 

can modify the user authentication and authorization rules on behalf of CSPs interrupting and modifying 



user privacy and data integrity settings. Some of the existing virtualized cloud-enabled solutions such as 

VPNs, Firewalls, security policies, and procedures are providing data and service security protocols and 

solutions such as differential-privacy mechanisms. However, lack of privacy and transparency controls 

on both the CSP side and client-side along with connectivity amongst the cloud vendors and their 

interactions can be easily abused by the attackers and assailants to unveil attacks like triggering linkages 

attacks against differential-privacy protection methods, and data mining-based linkage attacks as shown 

in figure 2 [17]. 

 

Figure 2: Cloud Computing Challenges 

Blockchain is one of the latest core technologies that has drawn attention as a next-generation promising 

solution for the problems mentioned above highlighted in cloud computing infrastructures in the recent 

information era. It helps to create a decentralized network of untrusted participants (peers) where a ledger 

of blocks of records is created. It enables us to establish an authentications system for peer nodes to 

securely share virtual cash, services, and encrypted transactions on the network to develop a secure and 

trusted relationship among the participating peers [18]. Blockchain helps CSPs to effectively handle 

(distribute, store, and record) cloud transactions and services in a way that doesn’t compromise end-users 

Quality of Service (QoS) and acts as middleware technology to provide sensitive data protection, avoid 

delays in sensitive data, and delays in searching and sorting vast chunks of data being stored and 

processed on the cloud platform using encrypted cryptographic methods [19].  

Blockchain technology also provides Resilience in cloud infrastructure by creating a distributed ledger 

of transactions being processed and executed on the cloud platform. It diminishes the problem of a single 

point of failure as provided by the cloud paradigm [20]. It also enhances transparency and scalability in 

the cloud network by improving the computation power through the number of distributed peers in the 

network without using a centralized computing model. The encrypted security model supported by 

blockchain also enhances the security and integrity of data being stored and processed on the cloud 

infrastructure through robust cryptographic hashing mechanisms such as SHA-256 or encryption using 

ECC or RSA to generate digital signatures for every transaction being processed or accessed on the 

network [21].  

Blockchain also helps cloud computing CSPs to offers the best approach for the application developers 

to create a virtual database of their services and transactions with one click just like Pay-Per-User to 

further improve the autonomy of their cloud services since these services will be carried out through a 



decentralized mechanism where functionalities are performed autonomously without the intervention of 

central authorities. This process enhances the trustworthiness amongst the participating clients as QoS 

information is persistent and cannot be modified [22]. This paper explores and evaluates various cloud 

security issues and threats happening at multiple levels in cloud infrastructures with a particular focus on 

virtualization specific threats and vulnerabilities. It then provides Blockchain-enabled solutions for these 

problems highlighted to improve further and enhance the services provided in virtualized cloud 

computing platforms. 

Cloud Data Center Security Concerns and Threats 

Cloud Computing technology has become another buzzword after the introduction of Web 2.0 to Web 

5.0. It provides on-demand services such as storage, processing, infrastructure, etc. to business enterprises 

over the Internet. It supports another vision of IT whereby programming applications and computational 

resources are pooled and provisioned as organizations and end-users demand these services over 

virtualized ICT infrastructures accessible through the Internet [23]. The end-users do not need to have 

built-in computing and network infrastructure to use these services provided by a cloud computing 

platform. Currently, the collaboration and integration of cloud computing with industrial applications 

have brought many security issues and challenges for both the CSPs and the clients [24]. The cloud 

computing supports inclinations for customers (i.e., end-users and pro-communities), which can refit 

some part of their businesses to the cloud infrastructures, helping them in lessening the cost of ownership, 

working, and keeping up the enrolling establishment, growing flexibility, and scalability by adopting to 

cloud platforms [25]. 

One of the critical challenges faced by today's’ clouds is their data Level security as the majority of the 

enterprise's sensitive and vital data needs proper security measures as hackers can steal the business data, 

such as daily sales, profit reports, financial reports, etc. [26]. These security issues are posing substantial 

barriers to the adoption of cloud-enabled solutions in business enterprises, especially the cloud services 

provided by trusted and non-trusted third-party service providers [27]. Thus, cloud computing paradigm 

apprehensions with traditional data privacy, data integrity, accessibility, and privacy issues that need to 

be sorted out and solved using the newest technologies and techniques [28]. So far, our work has focused 

on discussing various security threats in the cloud environment. However, the cloud paradigm, while 

promising virtually unlimited storage and computing power, introduces latency to the equation, which 

might not be acceptable in specific scenarios. 

Furthermore, the cloud paradigm introduces several security vulnerabilities to the infrastructure. This 

paper revolves around IaaS security issues and challenges, where traditional virtualization functionalities 

are commonly used. A break in the security of the virtualized infrastructure opens a direct gateway for 

attackers to unswervingly ambushes on organizational layers, making such attacks more prevailing and 

perilous [29]. The majority of cloud users are uninformed about the risks of storing and communicating 

their private data and information in a shared virtualized cloud environment. Therefore, critical 

technological restraints such as transparency, multi-tenancy, velocity-of-attack, information assurance, 

data privacy and ownership, compliance, encryption, integrity should be handled more prudently. It 

implies that the clients are entirely not secure and immune to the threats in their own cloud infrastructures. 

This, calls for an appropriate secure cloud mechanism to be developed and deployed to handle today’s 

Internet technologies [30]. In this paper, we also discoursed various security issues at different levels in 

virtualized data center infrastructures, their threats, and specific solutions provided by blockchain 

technology. Some of the prevalent virtualized security issues are explained below. 

1. Multitenancy (More for CSP compare to Client) 

2. Velocity of attack (More for CSP compare to Client) 

3. Information assurance (Client) 

4. Data privacy and ownership (Client) 

 

1. Multitenancy 

Multi-Tenancy has been recognized as one of the significant security issues in a virtualized cloud 

computing model. It is defined as a shared virtualized environment where computing resources are 

shared, i.e., separate virtual machines are operating and processing in the same physical server machine 



to achieve economic gain. It directly enables attackers with information leakage and increased attack 

surface that directly affects the integrity, confidentiality, privacy, and trust issues. It creates new targets 

for intrusions as both the attacker and the victim are sharing the same physical server machine. The major 

problem in a multi-tenancy environment is “how to assure data isolation in a multi-tenant environment?”. 

It needs a vertical solution from the Software-as-a-Service (SaaS) down to Infrastructure-as-a-Service 

(IaaS). Regardless of the advantage offered by multi-tenancy (distributed processing groundwork) to a 

CSP, it is enormous security stress for cloud clients [31].  

2. The ‘Velocity-of-Attack’ 

The virtualized cloud computing infrastructure, harness the power of thousands of computing nodes, 

combined with the homogeneity of the operating system deployed by the hosts. This leads to a situation 

where any present security threat will spread and amplify more rapidly called the ""speed of ambush"" 

factor and has a more significant impact than in a typical client-server network. It is essential to highlight 

that, the hosts in a virtualized environment must understand their trust boundaries and responsibilities for 

each other to secure the whole cloud environment as set by CSPs before moving to the cloud [32, 33]. 

3. Information Assurance 

The issues of end-to-end security, privacy, and business integrity and continuity are of greater complexity 

in a cloud computing world than in a single data center. Some critical issues of cloud security include 

trust, multitenancy, encryption, and compliance. Information assurance is the collection of innumerable 

information practices cloud computing service providers and vendors must follow and implement to 

certify the privacy, secrecy, confidentiality, integrity, accessibility, and availability of their customers’ 

information and data being stored on cloud storage. It is one of the foremost security characteristic and 

apprehension which makes sure that every client working on the cloud infrastructure is real and are 

appropriately authenticated and authorized to with legitimate rights and extensions assign to them by 

CSPs [34]. 

4. Data privacy and ownership 

Information protection and ownership are key cloud security issues for clients. It guarantees that 

information stored in the cloud is ""sheltered."" Data privacy and proprietorship explicitly identifies the 

menaces of unapproved information exposure due to a lack of privacy policies in cloud infrastructure as 

clients don’t know if the third-party or cloud computing vendors have privacy policies similar to or better 

than their policies. Therefore, it the responsibility of CSPs to let a client create and assign an access 

control list outlining how, when, and by whom the data will be accessed. Moreover, many clients also 

fear that their secret and critical data is being viewed by cloud vendors and owners while being stored 

and processed. They also want to see the access logs and audit trails of all cloud users and vendor 

employees. Furthermore, cloud CSPs and vendors might need provisions for external audits on their 

infrastructure and controls [35]. A CSP needs to guarantee that private and Personally Identifiable 

Information (PII) about its customers is lawfully shielded from an unapproved exposure. Private 

information may include:  

▪ Single user Identification on Cloud  

▪ Clients details as per request 

▪ Ownership of client data 

▪ A CSP needs to guarantee that the private information of its customers is shielded from 

unapproved revelation. Both assortment and spread of the private information needs security 

from any conceivable unapproved divulgence, specifically, according to the provincial 

legitimate necessities.  

Virtualization-Specific Vulnerabilities, Security Concerns and Threats 

Virtualization technology in its technological uprising enables us to implement key attributes of cloud 

computing by creating a virtualized environment from abstract hardware resources (servers, storage and 

other network equipment) by separating operational functionalities from the underlying hardware 

devices. It allows the creation, installation, configuration, effective allocation and adjustment of multiple 

VMs on a different physical host machine (servers). The hypervisor, also called Virtual Machine Monitor 



(VMM), one of the key components of virtualization technology in the cloud computing paradigm offers 

significant benefits in terms of functional segregation, performance isolation, live-migration-enabled load 

balance, fault tolerance, portability of applications, and higher resource utilization [36]. However, the 

design, implementation, and deployment of virtualization technology also opens up new threats and 

security vulnerabilities and is being targeted by attackers for malicious activities in the cloud 

infrastructures.  

IaaS permits the clients to access different VMs and install their own operating systems as needed to 

perform their computational queries, without the installation of appropriate security measures and 

solutions. Unfortunately, these types of settings in virtualized cloud infrastructures create significant 

vulnerabilities and limitations when we perform security-critical computations and store sensitive data. 

For example, there are no secure means currently available that guarantees the trustworthiness and fidelity 

of a Virtual Machine (VM) in terms of its origin as well as identity and reliability of the data being 

uploaded, stored and processed by server machines and storage devices [37]. Furthermore, there can be 

many other attack pathways like predefined and prebuilt VMs and other virtual equipment’s and 

appliances carrying malicious and malevolent codes, erroneously configured virtual firewalls and 

Intrusion detection systems (IDS) systems and networks, inaccurately installed and configured 

hypervisor, and information leakage or VM escape through offline configurations. In reality, protecting 

a VM is more complicated and resource-consuming compare to physical machines [38]. Furthermore, 

multiple clients sharing the same virtualized environment can cause security vulnerabilities as a large 

number of components involved in the configuration process create complex management issues, which 

can lead to DDoS type of service attacks as well as losing client's sensitive and critical data [39]. Another 

issue can be of trust between various participating clients with their data privacy and data assurance. 

One of the significant issues in the virtualized cloud data center is to protect client's sensitive data from 

being leaked over the Internet from attackers and unwanted people [40]. On the other hand, the stored 

data in the storage devices is unencrypted as well as handled by a different type of cloud administrators 

hired by CSPs, causing the trust and integrity issues [41]. These vulnerabilities and limitations require a 

macro-level solution for identified common cloud infrastructure level security threats and concerns to 

provide secure, efficient and transparent services to cloud end users. Cloud vendors and CSPs are putting 

substantial costs and exertions in securing their existing virtualized cloud infrastructures to achieve 

maximum compliance with the prevailing industry security services management standards (e.g., 

Amazon Cloud lately accomplished the Payment Card Industry Data Security Standard [PCIDSS] 

compliance certification and Microsoft Azure Cloud prerogatives compliance with (ISO27001 security 

standards) [42]. However, the overall security of cloud-based applications and services still needs better 

implementation and configuration services as well as advanced security services with fine-grained access 

controls bonded between virtualized services such as IaaS, SaaS and PaaS and cloud virtualization 

platforms.  

In this section, we have identified and evaluated numerous virtualized cloud security issues and 

challenges revealed in recent years in diverse virtualization components, such as a VMM, VMs, and guest 

operating systems and disk storage images and devices [43]. Attacks and hackers use malicious and 

spiteful programs and tools in various VMs in a virtualized cloud infrastructure to get illegal access 

permissions to record and log different screen updates and keystrokes across physical and virtual server 

machines (terminals) to gain sensitive and critical information required. Once a cloud network is 

compromised it becomes relatively easy to duplicate and copy live VM images to create and configure 

new VM image files causing VM image sprawl issue, in which colossal number rogue VMs can be created 

and then can be used to generate DDoS and other types of attacks on the network. In the same way, 

attackers and intruders can cause hypervisor-based attacks to exploit the vulnerabilities where the 

hypervisor is used to control multiple operating systems to operate concurrently on a single hardware 

platform, usually the physical server machine. A hacked and compromised hypervisor allows hackers to 

attack and control each VM installed and configured on a virtual host. Attackers use different APIs, 

software stacks and coding bugs to control the degree of security assurance for privacy and secrecy to 

further increase the risk levels for these cloud environments [44]. We highlight the following attack types 

in different virtualized environments, as shown in figure 3. 



 

Figure 3: Virtualization Attack Types 

 

1. VM Theft or VM Stealing 

Hypervisor vulnerabilities allow an attacker to use VMs for a longer duration of time and by 

changing/manipulating the set configurations such as memory, CPU and cache manipulations permit an 

attacker to hijack the VM along with its resources. This type of attack is also called VM theft or VM 

stealing or theft-of-service attack, as VMs have insufficient security controls permitting their unapproved 

duplication of development [45]. In this attack, the cloud infrastructure is financially affected, along with 

no record or logs of user’s activities leading to further risks related to the cloud paradigm. VM theft can 

be restricted by applying Duplicate and Move restrictions on VMs, which have more sensitive and critical 

data. This solution is considered as an underlying security mechanism where VMs are limited/tied to 

function and operate in a fixed secure physical server machine to stop the duplication of VM. A VM with 

duplicate and move limitations can't run on a hypervisor familiarized other physical machines; hence its 

movement and duplication can be stopped. Even though these limitations are fundamental to the 

protection of VMs against VM theft, it still has several disadvantages, such as it limits the VMs crosswise 

movement across multiple physical machines to share and execute different workloads based on 

applications being executed [46]. 

2. VM Escape 

In a virtualized cloud infrastructure, VMs are designed and created in a way to support secure isolation 

between the host physical machines and VMs. Virtual machine escape is a security vulnerability within 

a VM or the whole virtualized cloud infrastructure where an attacker exploits the exposures in the 

operating system running inside a virtual machine and inserts a malicious code. When a VM executes 

this malicious package code, it allows the attacker to gain access and control of the main primary 

hypervisor installed in the virtual network. It further breaks up the isolated boundaries between several 

VMs, thus bypasses the hypervisor to interconnect with other VMs in the network directly and get control 

of the host. It creates privacy, integrity and trust issues in the cloud infrastructure along with opening up 

the doors for other attackers to access and get control of other host machines and launch further attacks.    

These attacks include VM creation, VM manipulation, VM deletion, resource quota amendment and 

changes etc. the attacker can also play with access privileges allocated to explicit VMs [47]. 



3. VM Sprawl and VM Image Sprawl  

Virtual machine sprawl or virtualization sprawl and VM image sprawl is a situation in a virtualized cloud 

infrastructure, where cloud vendors, CSPs, or cloud administrators have no effective control and 

management over the creation, deletion, and configuration of VMs and their images files during the live 

migration process. The sprawl also includes resources shared and provisioned to these VMs such as 

memory, cache, storage, network channels, CPU, etc. This scenario underutilizes these resources as they 

can’t be assigned to other VMs because of a lack of control and proper management of these cloud 

resources [40]. This type of situation usually occurs when multiple VMs are created and set up by 

different departments in the same enterprise without the knowledge, control, policies, and proper 

procedures followed by different cloud administrators. It leads to the formation of bottlenecks on server 

machines, which further leads to crashed systems because of low resource availability in a cloud 

environment. 

4. VM Inside and Outside Attacks  

Virtual machines can be attacked and infected with malware and operating systems rootkits. The inside 

attacker can have several perspectives, such as an insider who wants to attack cloud’s local data center 

IT infrastructure for personal gains using existing cloud resources, or the rouge CSP administrator or an 

inside employee who intends to exploit cloud vulnerabilities for getting access to sensitive and essential 

information or it can be the cloud owner also called CSP with malicious intent. In this attack, the attackers 

get complete control of the VMs in the facility and ultimately controls the whole network where he can 

legitimately create copies and backups of VMs, delete and modify several VMs, and with service-level-

agreement acceptance can log in to a customer’s VMs for administrative purposes. [23].  

Whereas in outside attacks, VMs are co-located and connected through virtual network connections, 

shared memory, and other shared resources. A malicious VM inside this network can determine where 

another VM’s allocated memory lies. It allows this VM to read or write to that specific location and 

interfere with the other’s operation [37]. 

5. VM Cross Side-Channel Attack 

In virtualized cloud infrastructures, resource sharing techniques like deduplication of data and co-location 

of computation (multiple VMs placed on the same physical server machines) are critical for enhancing 

the efficiencies of VMs. But they also increase the security risks to OpenSSL AES implementations as 

they build a powerful cache-based attack on AES and recover the keys of an AES implementation in a 

targeted VM. It is, therefore, essential to highlight that long term co-location of computation should not 

be allowed along with deduplication of data be disabled. In these cross VM side-channel attacks, a 

malicious VM can quickly penetrate the isolation between several VMs and gets access to shared 

hardware and software resources and cache locations to extract confidential information from the target 

VMs [34]. 

6. Outdated Software Packages in VMs  

Obsolete software packages in virtualized cloud environments allow us to create and install new low-cost 

VMs for performing diverse tasks, extend and branch new VMs based on old ones, create image files of 

existing VMs, and even rollback machines to previous states [41]. These operations pose serious security 

threats, and implications such as a VM rollback may depict a software bug or vulnerability that has 

already been fixed. 

7. Hyperjacking  

A hypervisor or VMM is installed to execute several guest VMs and applications concurrently on a single 

host physical server machine and to provide separation amongst the guest VMs in a cloud environment 

[33]. These hypervisors are vulnerable and prone to attacks from various hackers. Hyperjacking is an 

attack on the hypervisor, in which the hacker injects a rogue hypervisor or takes malicious control over 

the installed hypervisor between the target system and the hardware to controls the whole internal server 

resources within a virtualized cloud environment. The attacker tries to attack the target operating system 

below the VMs to execute its malicious code and applications on VM [48]. The most important thing 



about hypervisor is that attackers can efficiently run unauthorized applications over the system without 

realizing the presence of any suspicious activity to the administrator. It is essential to highlight that 

regular security measures such as firewalls, IDS systems, and other antivirus tools are ineffective against 

these threats as the operating system, running above the rogue hypervisor, is unaware that the machine 

has been compromised. 

8. Data leakage 

Confidential and sensitive data stored on third party cloud storage platform is potentially vulnerable to 

unauthorized access and manipulations. In cloud environments, even when we apply secure shell 

protocols to encrypt and secure the stored data on virtual disks and communication between different 

VMs, hackers still apply different types of a";"""date"",""2020-11-13T08:27:05Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.7""
""xmp:CreatorTool"",""MicrosoftÂŽ Word 2016""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dc:creator"",""Dr Mueen""
""language"",""en""
""dcterms:created"",""2020-11-13T08:27:05Z""
""Last-Modified"",""2020-11-13T08:27:05Z""
""dcterms:modified"",""2020-11-13T08:27:05Z""
""dc:format"",""application/pdf; version=1.7""
""xmpMM:DocumentID"",""uuid:251C15C2-029B-49E4-A4C5-81C3B37E91DA""
""Last-Save-Date"",""2020-11-13T08:27:05Z""
""pdf:docinfo:creator_tool"",""MicrosoftÂŽ Word 2016""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2020-11-13T08:27:05Z""
""meta:save-date"",""2020-11-13T08:27:05Z""
""pdf:encrypted"",""false""
""xmp:CreateDate"",""2020-11-13T13:27:05Z""
""modified"",""2020-11-13T08:27:05Z""
""Content-Length"",""800187""
""pdf:hasMarkedContent"",""true""
""Content-Type"",""application/pdf""
""xmp:ModifyDate"",""2020-11-13T13:27:05Z""
""pdf:docinfo:creator"",""Dr Mueen""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Dr Mueen""
""dc:language"",""en-US""
""meta:author"",""Dr Mueen""
""pdf:producer"",""MicrosoftÂŽ Word 2016""
""meta:creation-date"",""2020-11-13T08:27:05Z""
""created"",""2020-11-13T08:27:05Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""22""
""Creation-Date"",""2020-11-13T08:27:05Z""
""resourceName"",""25486871.pdf""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""4270"",""3105"",""2829"",""4658"",""4368"",""5080"",""2567"",""4312"",""4801"",""4852"",""4557"",""3584"",""2937"",""4982"",""4847"",""4351"",""4084"",""4497"",""4216"",""4551"",""4504"",""4290""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""Author"",""Dr Mueen""
""producer"",""MicrosoftÂŽ Word 2016""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""MicrosoftÂŽ Word 2016""
""pdf:docinfo:created"",""2020-11-13T08:27:05Z""
";https://scholar.google.ch/scholar?start=840&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098892-399;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;H ?????????? Blockchain ???? ????? ??? ??????;? ????? ;2020 hellanicus.lib.aegean.gr;;"… ? ?ó??? ??? ??????? ?? Blockchain Ťdistributed ledger technologyť(DLT) ????????? ????

????????? ??? ???????? ????????? ???? ????????? ?????ó????? ??? ???????? ??ó ?? ?????? ????????

??? , ?? ????? ?? … (DDBMS ????? ?? ????????? SQL-based ( ?.? Oracle,) ??? ?? NoSQL …";;;[PDF] aegean.gr;https://hellanicus.lib.aegean.gr/bitstream/handle/11610/21475/%CE%94%CE%B9%CF%80%CE%BB%CF%89%CE%BC%CE%B1%CF%84%CE%B9%CE%BA%CE%AE%20%CE%91%CE%BD%CE%B1%CF%83%CF%84%CE%B1%CF%83%CE%AF%CE%B1%20%CE%99%CE%BD%CF%84%CE%B6%CE%AD.pdf?sequence=1&isAllowed=y;"
 

 

   

ΠΑΝΔΠΗ΢ΣΖΜΗΟ ΑΗΓΑΗΟΤ 
ΠΟΛΤΣΔΥΝΗΚΖ ΢ΥΟΛΖ 

 

ΣΜΖΜΑ ΜΖΥΑΝΗΚΩΝ ΠΛΖΡΟΦΟΡΗΑΚΩΝ ΚΑΗ ΔΠΗΚΟΗΝΩΝΗΑΚΩΝ ΢Τ΢ΣΖΜΑΣΩΝ 

 

ΠΡΟΓΡΑΜΜΑ ΜΔΣΑΠΣΤΥΗΑΚΩΝ ΢ΠΟΤΓΩΝ  

[ΠΛΖΡΟΦΟΡΗΑΚΑ ΚΑΗ ΔΠΗΚΟΗΝΩΝΗΑΚΑ ΢Τ΢ΣΖΜΑΣΑ] 

 

 

 

“H τεχνολογία Blockchain στον τομέα της Υγείας” 

 

 

ΓΗΠΛΩΜΑΣΗΚΖ  ΔΡΓΑ΢ΗΑ 
 

Ρξο 

 

ΑΝΑ΢ΣΑ΢ΗΑ΢  Γ. ΗΝΣΕΔ 
 

 

 

 

 

 

 

 

 

Δπηβιέπσλ : ΓΔΩΡΓΗΟ΢   ΚΟΡΜΔΣΕΑ΢ 

 

 

Μέιε εμεηαζηηθήο επηηξνπήο:  ΢ΚΟΤΣΑ΢ ΓΖΜΖΣΡΗΟ΢, ΚΑΠΟΡΖ΢ ΑΛΔΞΖ΢  

 

 

 

 

 

 

 

΢άκνο,   Οθηψβξηνο  2020 



 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Ζ ζειίδα απηή είλαη ζθφπηκα ιεπθή.



 

 

Πξόινγνο θαη επραξηζηίεο 

       Θα ήζεια λα επραξηζηήζσ ζεξκά ηνλ επηβιέπνληα θαζεγεηή κνπ Κ. Κνξκέληδα Γεψξγην γηα 

ηελ αλάζεζε ηεο πνιχ ελδηαθέξνπζαο δηπισκαηηθήο εξγαζίαο ζην ρψξν ηνπ blockchain, θαζψο 

θαη γηα ηελ εκπηζηνζχλε πνπ κνπ έδεημε θαηά ηε δηάξθεηα ηεο εθπφλεζήο ηεο. Δπραξηζηψ επίζεο 

ηνλ θαζεγεηή κνπ γηα ηηο πνιχηηκεο γλψζεηο πνπ απνθφκηζα απφ ηνλ ίδην θαζ‘φιε ηε δηάξθεηα ηνπ 

κεηαπηπρηαθνχ πξνγξάκκαηνο. 

      Δλ ζπλερεία, γηα ηελ έσο ηψξα ζηαδηνδξνκία κνπ ζα ήζεια λα επραξηζηήζσ ζεξκά ηνπο γνλείο 

κνπ Γεψξγην θαη Άλλα γηα ηελ ακέξηζηε θαη ζπλερή ζπκπαξάζηαζή ηνπο θαη γηα φια φζα κνπ 

έρνπλ πξνζθέξεη φια απηά ηα ρξφληα ηεο δσήο κνπ θαη ζπνπδψλ κνπ. 

 Δπραξηζηψ επίζεο ηα αδέξθηα κνπ ΢ηέξγην, Αζελφδσξν θαη ΢σηεξία πνπ είλαη πάληα δίπια κνπ 

θαη κε ζηεξίδνπλ ζε φιεο κνπ ηηο επηινγέο. Δπραξηζηψ ηνλ παππνχιε κνπ Γέξνληα Μάμηκν πνπ 

πξνζεχρεηαη γηα εκέλα θαη κε εληζρχεη πλεπκαηηθά. 

Ηδηαίηεξα ζεξκέο επραξηζηίεο ζέισ λα δψζσ ζην ζχδπγφ κνπ Θεφδσξν πνπ κε ππνκνλή θαη 

αγάπε κνπ πξνζέθεξε ηελ απαξαίηεηε εζηθή ζπκπαξάζηαζε γηα ηελ νινθιήξσζε ηεο 

δηπισκαηηθήο κνπ εξγαζίαο. 

Υσξίο ηνπο αλζξψπνπο πνπ αλέθεξα δελ ζα κπνξνχζα λα έρσ θηάζεη ζην ζεκείν πνπ είκαη 

ΜΎκξΞι. 

Σέινο, επραξηζηψ φινπο ηνπο θαζεγεηέο, ην ππνζηεξηθηηθφ πξνζσπηθφ θαη φινπο ηνπο 

αλζξψπνπο πνπ ζπληεινχλ ζηελ άςνγε ιεηηνπξγία ηνπ Παλεπηζηεκίνπ Αηγαίνπ. 

Ζ παξνχζα δηπισκαηηθή εξγαζία αθηεξψλεηαη ζηε κλήκε ηνπ Κσλζηαληίλνπ Καηζίθα πνπ 

ΡξΝ 28
Îľ
 Οθησβξίνπ ζπκπιεξψλνληαη 2 ρξφληα απφ ηε δνινθνλία ηνπ.   

 

 

 

 

 

 

 

 

Š 2020 

  Ρξο 

ΑΝΑ΢ΣΑ΢ΗΑ΢  Γ.  ΗΝΣΕΔ 

Σκήκα Μεραληθψλ Πιεξνθνξηαθψλ θαη Δπηθνηλσληαθψλ ΢πζηεκάησλ 

ΠΑΝΔΠΗ΢ΣΖΜΗΟ ΑΗΓΑΗΟΤ 

 

 



 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Ζ ζειίδα απηή είλαη ζθφπηκα ιεπθή.



Διπλωματική εργαςία: “H τεχνολογία Blockchain στον τομέα της Υγείας” 

  

ΑΝΑΣΤΑΣΙΑ  ΙΝΤΖΕ, Πανεπιςτήμιο Αιγαίου, Τμ. Μηχ/κών Π.Ε.Σ. i 
 

Πίλαθαο πεξηερνκέλσλ 

1 Δηζαγσγή ................................................................................................ ΢θάικα! Γελ έρεη νξηζηεί ζειηδνδείθηεο. 

2 Θεσξεηηθό ππόβαζξν -΢πζρεηηδόκελεο εηαηξίεο θαη εξγαζίεο .......................................................................... 7 

2.1 Bitcoin  ............................................................................................................................................... 7 

2.2 Κξππηνλνκίζκαηα: Πξνθιήζεηο θαη Λχζεηο  ..................................................................................... 8 

     2.2.1     Peer-to-peer double spending problem  ...................................................................................... 8 

     2.2.2     Single-point-of-failure  ............................................................................................................ 8 

     2.2.3     The Bitcoin blockchain solution  ................................................................................................ 8 

2.3 Μεραληζκφο blockchain  .................................................................................................................... 9 

     2.3.1  PoW Πξσηφθνιιν ....................................................................................................................... 10 

     2.3.2  Καθφβνπιεο αιπζίδεο .................................................................................................................. 11 

2.4 Απινπνηεκέλν blockchain  .............................................................................................................. 12 

2.5 Αλαηνκία ηνπ Block  ........................................................................................................................ 14 

2.6 Δλαιιαθηηθά blockchains ................................................................................................................ 15 

2.7 Σχπνη blockchain  ............................................................................................................................. 16 

2.8 ΢πζρεηηδφκελεο εηαηξίεο θαη εξγαζίεο  ............................................................................................. 17 

     2.8.1  Δξγαζίεο ζρεηηθά κε ηελ αληαιιαγή, δηαρείξηζε, απνζήθεπζε δεδνκέλσλ θαη EHRs  ............... 24 

     2.8.2  Δξγαζίεο ζρεηηθά κε ηηο θιηληθέο δνθηκέο  ................................................................................... 27 

     2.8.3 Δξγαζίεο ζρεηηθά κε ηε θαξκαθεπηηθή  ........................................................................................ 28 

     2.8.4  Δξγαζίεο ζρεηηθά κε ην IoT θαη ηηο ηαηξηθέο ζπζθεπέο................................................................ 28 

     2.8.5 Δξγαζίεο ζρεηηθά κε ηελ Σερλεηή Ννεκνζχλε ............................................................................ 32 

3 Δθαξκνγέο .......................................................................................................................................................... 33 

3.1 Data Management apps .................................................................................................................... 36 

     3.1.1 Παγθφζκηα αληαιιαγή επηζηεκνληθψλ δεδνκέλσλ γηα έξεπλα θαη αλάπηπμε (data sharing) ....... 37 

     3.1.2 Γηαρείξηζε δεδνκέλσλ (data management)  .................................................................................. 38 

     3.1.3 Απνζήθεπζε δεδνκέλσλ (data storage) ........................................................................................ 38 

     3.1.4 Ζιεθηξνληθά αξρεία πγείαο : EHRs ( electronic health records)  ................................................. 38 

3.2 Supply Chain Management (SCM) apps  ......................................................................................... 40 

     3.2.1 Κιηληθέο δνθηκέο  (clinical trials )  ................................................................................................ 43 

     3.2.2 Φαξκαθεπηηθή  (pharmaceutical )  ................................................................................................ 43 

3.3 Internet of Medical Things (IoMT) apps  ........................................................................................ 44 

     3.3.1  IoT ζηελ Τγεηνλνκηθή πεξίζαιςε  θαη  Ηαηξηθέο ζπζθεπέο  (Healthcare IoT and Medical 

devices) ....................................................................................................................................................... 45 



Διπλωματική εργαςία: “H τεχνολογία Blockchain στον τομέα της Υγείας” 

  

ΑΝΑΣΤΑΣΙΑ  ΙΝΤΖΕ, Πανεπιςτήμιο Αιγαίου, Τμ. Μηχ/κών Π.Ε.Σ. ii 
 

     3.3.2  Τπνδνκή ησλ IoT ζηελ Τγεηνλνκηθή πεξίζαιςε  θαη  Αζθάιεηα ησλ δεδνκέλσλ (Healthcare 

IoT Infrastructure and  Data Security )  ...................................................................................................... 45 

     3.3.3 Σερλεηή Ννεκνζχλε  (Artificial Intelligence )  ............................................................................ 46 

3.4 Απνκαθξπζκέλε παξαθνινχζεζε αζζελψλ (remote patient monitoring) ....................................... 46 

     3.4.1  Πεξηγξαθή ηνπ ζπζηήκαηνο ......................................................................................................... 48 

     3.4.2  Ρνή εθηέιεζεο ηνπ ζπζηήκαηνο  ................................................................................................. 50 

     3.4.3 Αλάιπζε ηνπ ζπζηήκαηνο θαη ζχγθξηζε κε ην παξαδνζηαθφ ζχζηεκα  ...................................... 51 

3.5 Ηαηξηθή Δθπαίδεπζε (medical education)  ....................................................................................... 52 

     3.5.1  Πεξηγξαθή ηνπ ζπζηήκαηνο VECefblock      ................................................................................ 57 

     3.5.2 Ρνή εθηέιεζεο ηνπ ζπζηήκαηνο VECefblock   .............................................................................. 59 

3.6 Γνληδησκαηηθά δεδνκέλα (genomic data generation)     ................................................................... 60 

     3.6.1  Πεξηγξαθή ηνπ ζπζηήκαηνο NEBULA BLOCKCHAIN  .............................................................. 66 

     3.6.2  Ρνή εθηέιεζεο ηνπ ζπζηήκαηνο NEBULA BLOCKCHAIN  ........................................................ 68 

3.7 Βειηίσζε πνηφηεηαο Κιηληθψλ Γνθηκψλ (Clinical research quality)   ............................................. 75 

     3.7.1  Ρνή εθηέιεζεο ηνπ ζπζηήκαηνο  .................................................................................................. 76 

3.8 Γεσρσξηθέο εθαξκνγέο γηα έμππλεο πγηείο πφιεηο  (Geospatial application for smart healthy cities ) . 78 

     3.8.1  Έμππλν Αζζελνθφξν   ................................................................................................................. 79 

     3.8.2  Απηληδσηήο ζε drone ................................................................................................................... 80 

3.9 Νεπξνεπηζηήκεο (Neuroscience)  ..................................................................................................... 82 

3.10 Γηαρείξηζε  δεδνκέλσλ εγγξαθήο (Enrollment Data Management)  ............................................... 84 

3.11 Γηαρείξηζε απαηηήζεσλ ηηκνινγίσλ (Claims and Billing Management)  ........................................ 88 

3.12 Δληνπηζκφο απάηεο (fraud detection) θαη Γηαρείξηζε Πνηφηεηαο (Quality management)  .............. 89 

3.13 Μνληέια πξφβιεςεο γηα ηελ πξνζηαζία ηεο ηδησηηθήο δσήο (privacy-preserving predictive 

models)  ....................................................................................................................................................... 92 

4 ΠΞνθΚΎΜξΡο ........................................................................................................................................................ 94 

4.1 Γηαθάλεηα (transparency) - Δκπηζηεπηηθφηεηα (confidentiality) ..................................................... 94 

4.2 Σαρχηεηα (speed) ............................................................................................................................. 94 

4.3 Δπεθηαζηκφηεηα (scalability) ........................................................................................................... 95 

4.4 Απεηιή επίζεζεο 51% (threat of 51% attack) ................................................................................... 95 

4.5 Αζθάιεηα  (Security) ....................................................................................................................... 96 

4.6 Απνζήθεπζε  (Storage) .................................................................................................................... 97 

4.7 Σξνπνπνίεζε  (modification ) .......................................................................................................... 97 

4.8 Πξνζηαζία ηεο ηδησηηθφηεηαο θαη θαλνληζκνί (Privacy and Regulations) ...................................... 98 

     4.8.1  Blockchain θιΡ GDPR.................................................................................................................. 99 

5 Δπίινγνο............................................................................................................................................................ 102 

5.1 Μειινληηθέο πξννπηηθέο ................................................................................................................ 102 



Διπλωματική εργαςία: “H τεχνολογία Blockchain στον τομέα της Υγείας” 

  

ΑΝΑΣΤΑΣΙΑ  ΙΝΤΖΕ, Πανεπιςτήμιο Αιγαίου, Τμ. Μηχ/κών Π.Ε.Σ. iii 
 

5.2 Δπηπηψζεηο θαη ζπκπεξάζκαηα ...................................................................................................... 102 

Βηβιηνγξαθία .............................................................................................................................................................. 104 

 

  



Διπλωματική εργαςία: “H τεχνολογία Blockchain στον τομέα της Υγείας” 

  

ΑΝΑΣΤΑΣΙΑ  ΙΝΤΖΕ, Πανεπιςτήμιο Αιγαίου, Τμ. Μηχ/κών Π.Ε.Σ. iv 
 

Λίζηα ΢ρεκάησλ 

Δηθφλα 1.1 : Ρνή εξγαζίαο ηεο δηαδηθαζίαο blockchain ………………………………………..  5 

Δηθφλα 2.1 : Σν πξφβιεκα ηεο δηπιήο δαπάλεο ρσξίο θεληξηθφ δηακεζνιαβεηή …….……….   8 

Δηθφλα 2.2: ΢χγθξηζε ησλ ηνπνινγηψλ θαηαλεκεκέλσλ δηθηχσλ …………………….............. 9 

Δηθφλα 2.3: Παξάδεηγκα απινπνηεκέλνπ blockchain (hash-chain) ……………………............ 9 

Δηθφλα 2.4:  Παξάδεηγκα ηνπ κεραληζκνχ nonce γηα ην PoW πξσηφθνιιν ………………….. 10 

Δηθφλα 2.5:  Παξάδεηγκα ηνπ πψο ην  blockchain δηαρεηξίδεηαη ηηο αιπζίδεο δηαθιάδσζεο …. 12  

Δηθφλα 2.6 : Απινπνηεκέλν blockchain ηξηψλ blocks …………………………………………  13 

Δηθφλα 2.7 : Απινπνηεκέλν blockchain κε πεηξαγκέλν block ………………………………… 13 

Δηθφλα 2.8: Αλαηνκία ηνπ block ……………………………………………………………….. 14 

Δηθφλα 2.9 : Γηάθνξνη ηχπνη ηεο ηερλνινγίαο blockchain ……………………………………..  17   

Δηθφλα 3.1 : Αλαπαξάζηαζε ηεο ξνήο εξγαζίαο ησλ εθαξκνγψλ πγεηνλνκηθήο πεξίζαιςεο πνπ         

βαζίδνληαη ζην blockchain ……………………………………………………………………...   33 

Δηθφλα 3.2: Οη ελδηαθεξφκελνη γηα ηα δεδνκέλα πγεηνλνκηθήο πεξίζαιςεο ………………….. 35 

Δηθφλα 3.3: Γηαρείξηζε δεδνκέλσλ πγεηνλνκηθήο πεξίζαιςεο ζην blockchain ……………….. 36 

Δηθφλα 3.4: EMR .…...………………………………………………………………………….. 39                                                        

Δηθφλα 3.5: Γεδνκέλα αηζζεηήξσλ ……………………………………………………………... 39 

Δηθφλα 3.6: Γηαρείξηζε ηεο εθνδηαζηηθήο αιπζίδαο ζην blockchain……………………………  41 

Δηθφλα 3.7: Internet of medical things (IoMT) ζην blockchain ………………………………..  44 

Δηθφλα 3.8: Σα αθαηέξγαζηα δεδνκέλα ησλ αηζζεηήξσλ ζπγθεληξψλνληαη απφ ηε θχξηα ζπζθεπή 

θαη έπεηηα απνζηέιινληαη ζηνπο θφκβνπο ηνπ blockchain γηα επεμεξγαζία απφ ην έμππλν 

ζπκβφιαην ……………………………………………………………………………………….    49 



Διπλωματική εργαςία: “H τεχνολογία Blockchain στον τομέα της Υγείας” 

  

ΑΝΑΣΤΑΣΙΑ  ΙΝΤΖΕ, Πανεπιςτήμιο Αιγαίου, Τμ. Μηχ/κών Π.Ε.Σ. v 
 

Δηθφλα 3.9: Σα πξνζαξκνζκέλα δεδνκέλα ησλ έμππλσλ ζπζθεπψλ απνζηέιινληαη ζηα έμππλα 

ζπκβφιαηα, ηα νπνία επεμεξγάδνληαη θαη εθηεινχλ ηηα απαξαίηεηεο ελέξγεηεο, κε βάζε ηα 

απνηειέζκαηα θαη ηηο πξνθαζνξηζκέλεο παξακέηξνπο …………………………………………    49 

Δηθφλα 3.10: Ζ ινγηθή ξνή εθηέιεζεο ηνπ ζπζηήκαηνο ………………………………………..  50 

Δηθφλα 3.11: Οη ελλέα θαηεγνξίεο ηεο Ηαηξηθήο Δθπαίδεπζεο …………………………………   53 

Δηθφλα 3.12: Ηδαληθφο ζρεδηαζκφο  ……………………………………………………………..  54 

Δηθφλα 3.13:΢ρεδηαζκφο ησλ ηεζζάξσλ θάζεσλ ηνπ VECefblock ...………………………….   57 

Δηθφλα 3.14:  Αξρηηεθηνληθή ηνπ ζπζηήκαηνο …………………………………………………   58 

Δηθφλα 3.15: VECefblock επηρεηξεκαηηθή δηαδηθαζία …………………………………………   59 

Δηθφλα 3.16: Κφζηνο αιιεινπρίαο αλζξψπηλνπ γσληδηψκαηνο, 2001-2018 ………………….    60    

Δηθφλα 3.17: Σν παξαδνζηαθφ κνληέιν γηα ηε δεκηνπξγία θαη θνηλή ρξήζε ησλ γνληδησκαηηθψλ 

κνληέισλ  ……………………………………………………………………………………….    61 

Δηθφλα 3.18: Δλαιιαθηηθφ κνληέιν πνπ κπνξεί λα αληηκεησπίζεη ηηο πξνθιήζεηο …………..   63 

Δηθφλα 3.19: Πιαηθφξκα NEBULA …………………………………………………………...   66 

Δηθφλα 3.20: Δπηδφηεζε πιεξσκήο γηα ηελ αιιεινπρία ηνπ γνληδηψκαηνο ζην blockchain …    68 

Δηθφλα 3.21: Σα blocks δεδνκέλσλ απνζεθεχνληαη ζην KEEP. Οη θαηαθεξκαηηζκνί απνζεθεχνληαη 

ζην blockchain  …………………………………………………………………………………  70 

Δηθφλα 3.22: Απινπνηεκέλε παξνπζίαζε κηαο ―tile library‖ θαη ελφο CGF αξρείνπ. Σα νξζνγψληα 

αληηπξνζσπεχνπλ παξαιιαγέο ησλ tile δηαθνξεηηθψλ ζέζεσλ. Ζ δηαθεθνκκέλε γξακκή απεηθνλίδεη 

ηε ζχλζεζε ησλ tiles ζπγθεθξηκέλνπ γνληδηψκαηνο …………………………………………… 71 

Δηθφλα 3.23: Αζθαιήο αλαθάιπςε δεδνκέλσλ κέζσ εξσηεκάησλ ζηα νκνκνξθηθά 

θξππηνγξαθεκέλα δεδνκέλα  ...………………………………………………………………….72 

Δηθφλα 3.24: Έιεγρνο πξφζβαζεο ζηα δεδνκέλα θαη αγνξά δεδνκέλσλ ………………………74 

Δηθφλα 3.25: Ρνή εξγαζίαο ζχλζεησλ θιηληθψλ δνθηκψλ θσδηθνπνηεκέλε ζε blockchain …... 76 

Δηθφλα 3.26: Πξνηεηλφκελν κνληέιν …………………………………………………………... 79 

Δηθφλα 3.27: Αλάγθε γηα αζζελνθφξν ή φρη …………………………………………………… 80 



Διπλωματική εργαςία: “H τεχνολογία Blockchain στον τομέα της Υγείας” 

  

ΑΝΑΣΤΑΣΙΑ  ΙΝΤΖΕ, Πανεπιςτήμιο Αιγαίου, Τμ. Μηχ/κών Π.Ε.Σ. vi 
 

Δηθφλα 3.28: To drone ελζσκαηψλεηαη κε κηα ζπζθεπή IoT, επηηξέπνληάο ηεο λα έρεη πιήξεηο 

δπλαηφηεηεο blockchain  ………………………………………………………………………...    82 

Δηθφλα 3.29:    Δγγξαθή ηαπηφηεηαο ρξήζηε ζην blockchain ……………………………………  85 

Δηθφλα 3.30α:  Γεκηνπξγία θαη θνηλή ρξήζε ελφο EMR ζε έλα blockchain (α κέξνο) …………  86 

Δηθφλα 3.30β:  Γεκηνπξγία θαη θνηλή ρξήζε ελφο EMR ζε έλα blockchain (β κέξνο) …………  87 

Δηθφλα 3.31:    Δξψηεζε ζην EMR ζε έλα blockchain …………………………………………...88 

Δηθφλα3.32: Απινπνηεκέλε εθνδηαζηηθή αιπζίδα θαξκάθσλ βαζηζκέλε ζηελ ηερλνινγία 

blockchain  ………………………………………………………………………………………   91 

Δηθφλα 4.1:   Απεηιή επίζεζεο 51%  …………………………………………………………….  96 

Δηθφλα 4.2:    Κχθινο θηλδχλνπ γηα ηελ αζθάιεηα ησλ κεγάισλ δεδνκέλσλ πγεηνλνκηθήο 

πεξίζαιςεο  ……………………………………………………………………………………...   97  

Δηθφλα 4.3:   off-chain blockchain αξρηηεθηνληθή ……………………………………………...  100 

Δηθφλα 4.4: ΢πλεξγαζία ηνπ blockchain ζπκβαηή κε ην GDPR γηα ηα κεγάια δεδνκέλα 

πγεηνλνκηθήο πεξίζαιςεο  …………………………………………………………………...….  101 

 

  



Διπλωματική εργαςία: “H τεχνολογία Blockchain στον τομέα της Υγείας” 

  

ΑΝΑΣΤΑΣΙΑ  ΙΝΤΖΕ, Πανεπιςτήμιο Αιγαίου, Τμ. Μηχ/κών Π.Ε.Σ. vii 
 

Λίζηα Πηλάθσλ 

Πίλαθαο  3.1 : Αλάιπζε ηνπ ζπζηήκαηνο blockchain θαη ζχγθξηζε κε ην παξαδνζηαθφ ζχζηεκα  …. 51 

Πίλαθαο 3.2 : ΢χγθξηζε ησλ πιαηθνξκψλ βηνπιεξνθνξηθήο  ………………………………………64 

Πίλαθαο 3.3 : ΢χγθξηζε ησλ πιαηζίσλ Blockchain  …………………………………………………65 

Πίλαθαο 3.4 : ΢χγθξηζε ησλ privacy-preserving ηερλνινγηψλ  …………………………………….  65 

Πίλαθαο 4.1 : Καλνληζκνί πξνζηαζίαο ηεο Ηδησηηθφηεηαο γηα ηηο δηάθνξεο ρψξεο θαη νξγαληζκνχο..98 



Διπλωματική εργαςία: “H τεχνολογία Blockchain στον τομέα της Υγείας” 

  

ΑΝΑΣΤΑΣΙΑ  ΙΝΤΖΕ, Πανεπιςτήμιο Αιγαίου, Τμ. Μηχ/κών Π.Ε.Σ. viii 
 

Αθξσλύκηα 

DLT  Distributed ledger technology 

P2P Peer to peer 

EHR Electronic health records 

EMR Electronic medical records 

SCM Supply chain management 

DDBMS Distributed database management system 

SHA-256 Secure hash algorithm 

ECDSA-256 Elliptic curve digital signature algorithm 

POW Proof of work 

BTC Bitcoin 

CPU Central processing unit 

KSI  Keyless Signature Infrastructure 

UAE   United Arab Emirates 

HIPPA Health Insurance portability and accountability act 

GDPR General data protection regulation 

UHC   Universal Health Coin 

PHI Personal health information 

PHR Personal health records 

PCOR   Patient centered outcomes research 

NIST  National Institute of standards and technology 

PoET Proof of elapsed time 

PoS Proof of stake 

PBFT Practical byzantine fault tolerance 

RFID  Radio frequency identification 

PSN  Pervasive Social Network 

APIs  Application program interface 

IDSs  Intrusion Detection Systems 

ADS   Anomaly detection System 

MDS   Misuse detection 

ITI Information Technology Infrastructure 

PD  Parkinson Disease 

WBAN  Wireless body- area network 



Διπλωματική εργαςία: “H τεχνολογία Blockchain στον τομέα της Υγείας” 

  

ΑΝΑΣΤΑΣΙΑ  ΙΝΤΖΕ, Πανεπιςτήμιο Αιγαίου, Τμ. Μηχ/κών Π.Ε.Σ. ix 
 

 

ICT Information and Communication Technology 

DApps  Decentralized Applications 

CPD  Continuing Professional Development 

HPO   Human Phenotype Ontology 

FHIR  Fast Healthcare Interoperability Resources 

AES  Advanced encryption standard 

AWS   Amazon Web Services 

GCP    Google Cloud Platform 

CGF   Compact Genome Format 

CWL     Common Workflow Language 

OSMaps    Ordnance Survey map data 

S.A.  Smart ambulance 

ToF Time of Flight 

CA    Client app 

ECert      Enrollment Certificate 

TCert    Transaction Certificate 

IoMT   Internet of medical things 

CRAB    Create Retrive Append Burn 

 

  



Διπλωματική εργαςία: “H τεχνολογία Blockchain στον τομέα της Υγείας” 

  

ΑΝΑΣΤΑΣΙΑ  ΙΝΤΖΕ, Πανεπιςτήμιο Αιγαίου, Τμ. Μηχ/κών Π.Ε.Σ. x 
 

Πεξίιεςε 

 

΢ηηο κέξεο καο ε ηερλνινγία blockchain έρεη ζπγθεληξψζεη ηελ πξνζνρή φισλ, κε 

απμαλφκελν ελδηαθέξνλ γηα πιεζψξα εθαξκνγψλ, απφ ηε δεκηνπξγία ηνπ θξππηνλνκίζκαηνο 

Bitcoin έσο ηηο κε- ρξεκαηννηθνλνκηθέο ππεξεζίεο. Σα ηειεπηαία ρξφληα ιφγσ ηεο  ξαγδαίαο 

αλάπηπμεο ηεο ηερλνινγίαο απηήο, νη επηζηήκνλεο εμέηαζαλ λένπο ηξφπνπο εθαξκνγήο ηεο 

ηερλνινγίαο ζε έλα επξχ θάζκα ηνκέσλ, ζπκπεξηιακβαλνκέλνπ ηνπ ηνκέα Τγείαο. 

Σν blockchain είλαη κηα ηερλνινγία θνηλνχ, θαηαλεκεκέλνπ, ςεθηαθνχ εκεξνινγίνπ, ε νπνία 

δηεπθνιχλεη ηε δηαρείξηζε, ηελ πξνέιεπζε θαη ηελ αζθάιεηα ησλ δεδνκέλσλ. Πξφθεηηαη γηα κηα 

αιπζίδα πνπ θαιχπηεη πιεξνθνξίεο θαη δηαηεξεί ηελ εκπηζηνζχλε κεηαμχ ησλ αηφκσλ, 

αλεμαξηήηνπ ηνπνζεζίαο, βειηηψλνληαο ηνλ έιεγρν ηεο απζεληηθφηεηαο θαη ηεο δηαθάλεηαο ησλ 

δεδνκέλσλ πγεηνλνκηθήο πεξίζαιςεο. 

Ζ βαζηθή αξρή ηνπ blockchain είλαη φηη θάζε ππεξεζία πνπ βαζίδεηαη ζε αμηφπηζηνπο ηξίηνπο 

κπνξεί λα θαηαζθεπαζηεί κε έλαλ δηαθαλή, απνθεληξσκέλν θαη αζθαιή ηξφπν ζηνλ νπνίν δελ 

απαηηείηαη εκπηζηνζχλε. ΢ηελ πξαγκαηηθφηεηα ππάξρεη εκπηζηνζχλε αιιά είλαη ζθιεξά 

θσδηθνπνηεκέλε κέζσ ελφο ζχλζεηνπ θξππηνγξαθηθνχ αιγνξίζκνπ. Οη ρξήζηεο θαηέρνπλ πςειφ 

βαζκφ ειέγρνπ, απηνλνκίαο, εκπηζηνζχλεο θαη αθεξαηφηεηαο ησλ δεδνκέλσλ. Δπίζεο, ην 

blockchain επηηξέπεη ηελ επίηεπμε ζεκαληηθνχ επηπέδνπ ηζηνξηθφηεηαο ησλ δεδνκέλσλ, ρσξίο λα 

επηηξέπεηαη ε νπνηαδήπνηε παξαβίαζε, γηα νιφθιεξε ηε ξνή ησλ δεδνκέλσλ. Σέινο, ε ηερλνινγία 

εμαζθαιίδεη ηνλ ιεπηνκεξή έιεγρν ησλ δεδνκέλσλ θαη ηελ αζθάιεηά ηνπο γηα θάζε 

ελδηαθεξφκελν πνπ ζπκκεηέρεη ζην δίθηπν ησλ νκφηηκσλ θφκβσλ P2P.  

Οη blockchain ιχζεηο δηεξεπλψληαη γηα: ηε δηαηήξεζε αδεηψλ ζηα ειεθηξνληθά αξρεία πγείαο 

(EHRs), ηε δηαρείξηζε ηεο θαξκαθεπηηθήο εθνδηαζηηθήο αιπζίδαο θαη ηεο αιπζίδαο ησλ ηαηξηθψλ 

ζπζθεπψλ, ηελ θιηληθή έξεπλα θαη ηε λνκηζκαηνπνίεζε ησλ δεδνκέλσλ, ηελ αλίρλεπζε ηαηξηθήο 

απάηεο θαη ηελ ελίζρπζε ηεο ζπκκφξθσζεο, ηελ επηηήξεζε ηεο δεκφζηαο πγείαο, ηελ ηξνθνδνζία 

πνιιψλ απηφλνκσλ ζπζθεπψλ πνπ ζπλδένληαη ζην IoT, ηηο θνξεηέο ζπζθεπέο, ην drone 

απηληδσηή, ην έμππλν αζζελνθφξν, ηελ έξεπλα ηνπ εγθεθάινπ, ηελ ηαηξηθή ε";"""date"",""2020-11-24T10:30:49Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""template_vol_I""
""xmp:CreatorTool"",""MicrosoftÂŽ Office Word 2007""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dc:creator"",""Alkis Simitsis""
""language"",""el""
""dcterms:created"",""2020-11-24T10:30:49Z""
""Last-Modified"",""2020-11-24T10:30:49Z""
""dcterms:modified"",""2020-11-24T10:30:49Z""
""dc:format"",""application/pdf; version=1.5""
""title"",""template_vol_I""
""Last-Save-Date"",""2020-11-24T10:30:49Z""
""pdf:docinfo:creator_tool"",""MicrosoftÂŽ Office Word 2007""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2020-11-24T10:30:49Z""
""meta:save-date"",""2020-11-24T10:30:49Z""
""pdf:encrypted"",""false""
""dc:title"",""template_vol_I""
""modified"",""2020-11-24T10:30:49Z""
""Content-Length"",""3978388""
""pdf:hasMarkedContent"",""true""
""Content-Type"",""application/pdf""
""pdf:docinfo:creator"",""Alkis Simitsis""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Alkis Simitsis""
""dc:language"",""el-GR""
""meta:author"",""Alkis Simitsis""
""meta:creation-date"",""2020-11-24T10:30:49Z""
""created"",""2020-11-24T10:30:49Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""146""
""Creation-Date"",""2020-11-24T10:30:49Z""
""resourceName"",""%CE%94%CE%B9%CF%80%CE%BB%CF%89%CE%BC%CE%B1%CF%84%CE%B9%CE%BA%CE%AE%20%CE%91%CE%BD%CE%B1%CF%83%CF%84%CE%B1%CF%83%CE%AF%CE%B1%20%CE%99%CE%BD%CF%84%CE%B6%CE%AD.pdf""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""423"",""59"",""1603"",""55"",""4640"",""4948"",""453"",""1808"",""2089"",""1159"",""563"",""1195"",""717"",""2817"",""2263"",""3210"",""3589"",""2620"",""2466"",""1691"",""1341"",""2211"",""1921"",""1402"",""2538"",""3103"",""2022"",""1707"",""1853"",""2144"",""2571"",""1901"",""3008"",""2869"",""2922"",""2939"",""3035"",""3575"",""2017"",""2879"",""2718"",""3085"",""3049"",""2699"",""2966"",""3323"",""2212"",""1631"",""2331"",""1573"",""2046"",""2571"",""2513"",""1918"",""3162"",""1686"",""1930"",""2470"",""1529"",""2311"",""2688"",""3248"",""2850"",""1001"",""1496"",""2357"",""2460"",""1637"",""1710"",""3404"",""3291"",""2083"",""1565"",""1687"",""2306"",""2216"",""3074"",""1912"",""1457"",""656"",""1519"",""2920"",""1371"",""2912"",""1816"",""1815"",""1293"",""2731"",""2243"",""3298"",""1362"",""2773"",""3430"",""1521"",""2285"",""3012"",""2314"",""3598"",""3147"",""2135"",""362"",""859"",""1607"",""3113"",""3685"",""1813"",""3389"",""3138"",""2448"",""2584"",""1962"",""1992"",""1236"",""2657"",""2064"",""1492"",""2742"",""2924"",""3076"",""3629"",""3394"",""3811"",""2844"",""3350"",""3303"",""4048"",""3622"",""3559"",""3805"",""3826"",""4128"",""3850"",""3750"",""3621"",""3315"",""4082"",""3924"",""3965"",""3159"",""2757"",""2967"",""3368"",""2857"",""3246"",""3373"",""223""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""Author"",""Alkis Simitsis""
""producer"",""MicrosoftÂŽ Office Word 2007""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""MicrosoftÂŽ Office Word 2007""
""pdf:docinfo:created"",""2020-11-24T10:30:49Z""
";https://scholar.google.ch/scholar?start=940&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098738-44;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Exploiting smart contracts for capability-based access control in the Internet of Things;Y Nakamura, Y Zhang, M Sasabe, S Kasahara ; Sensors, 2020  mdpi.com;;"… Blockchain was originally invented as a distributed and tamper-resistant ledger for cryptocurrency

systems to store the financial … was proposed in [36] to manage access control for data sharing

in IoT systems, where oracles are used to connect blockchain, data hosts, and …";Cité 10 fois;Les 11 versions;[PDF] mdpi.com;https://www.mdpi.com/1424-8220/20/6/1793/pdf;;;https://scholar.google.ch/scholar?start=590&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098866-336;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;[PDF][PDF] Tight quantum security of the Fiat-Shamir transform for commit-and-open identification schemes with applications to post-quantum signature schemes;A Chailloux ; eprint.iacr.org;;"… 1 Page 2. translating the Random Oracle Model1 (ROM) to the Quantum ROM (QROM) and

we need to rewrite all the security proofs involving the QROM … However, we only have black

box access to ? and we don't have access to a inversion oracle …";Cité 1 fois;;[PDF] iacr.org;https://eprint.iacr.org/2019/699.pdf;"
Tight quantum security of the Fiat-Shamir transform for

commit-and-open identification schemes with applications to

post-quantum signature schemes

André Chailloux
Inria de Paris, EPI COSMIQ

Abstract

Applying the Fiat-Shamir transform on identification schemes is one of the main ways
of constructing signature schemes. While the classical security of this transformation is well
understood, it is only very recently that generic results for the quantum case have been pro-
posed [DFMS19, LZ19]. These results are asymptotic and therefore can’t be used to derive
the concrete security of these signature schemes without a significant loss in parameters.

In this paper, we show that if we start from a commit-and-open identification scheme,
where the prover first commits to several strings and then as a second message opens a subset
of them depending on the verifier’s message, then there is a tight quantum reduction for the
the Fiat-Shamir transform to special soundness notions. Our work applies to most 3 round
schemes of this form and can be used immediately to derive quantum concrete security of
signature schemes.

We apply our techniques to several identification schemes that lead to signature schemes
such as Stern’s identification scheme based on coding problems, the [KTX08] identification
scheme based on lattice problems, the [SSH11] identification schemes based on multivariate
problems, closely related to the NIST candidate MQDSS, and the PICNIC scheme based on
multiparty computing problems, which is also a NIST candidate.

Keywords: post-quantum cryptography, quantum random oracle model, Fiat-Shamir trans-
form, signature schemes.

1 Introduction

Each year brings new advances in quantum technologies [ABB+19] and we will soon need to de-
ploy post-quantum cryptography in order to prevent ourselves against the potential construction
of a quantum computer capable of running Shor’s algorithm [Sho94] and other powerful quan-
tum algorithms. The NIST standardization process of post-quantum cryptographic primitives
[NIS17] (specifically encryption schemes, key encapsulation mechanisms and signature schemes)
is currently ongoing and it becomes crucial to continue to build trust for these schemes. A first
way to build trust is to constantly challenge the post-quantum computational assumptions by
designing new quantum algorithms. Another very important aspect is to make sure we have
sound security reductions even with quantum computers. In particular, several technical prob-
lems arise when translating the Random Oracle Model1 (ROM) to the Quantum ROM (QROM)

1In the Random Oracle Model, we model a hash function by a truly random function to which we only have
black box access. This model is in all generality unrealistic and can be too strong in some pathological scenarios

1



and we need to rewrite all the security proofs involving the QROM.

Quantum security reductions for signature schemes

In this paper, we focus on quantum security reductions for signature schemes. There are
mainly 2 families of signature schemes that use security reductions in the QROM: (1) Hash and
Sign signatures and (2) signatures using the Fiat-Shamir transform on identification schemes.
We understand well the security of Hash and Sign signatures in the QROM [Zha12]. For those
using the Fiat-Shamir transform, it is only recently that there exists a general proof of its
security in the QROM [DFMS19, LZ19].

So is this the end of the story? Not quite. The results of [DFMS19, LZ19] are only asymptotic
and are not tight. This means that if you want your signature scheme to have 128 bits of security,
you need to choose parameters such that your post-quantum computational assumption has
256, 384 or often much more bits of security. Several schemes have tight security reductions
QROM, for example those based on lossy identification schemes [KLS18] or closely related
[ABB+19]. However, several others have only non tight security reductions and some even don’t
have a post-quantum security reduction, including some NIST candidates2 Of course, designers
that use a non-tight security reduction could take this into account in their parameters but
almost no one does this as it would be devastating for their parameters. Instead, designers
often have to fix parameters as if the reductions were tight and accept not having concrete
security claims. For example, in their latest design specification, the authors of PICNIC write
the following:

“One caveat we note is that this generalization comes with a cost in tightness of the reduc-
tion. The reduction for the ZKB++ parameter sets looses a factor of q2, and for KKW the
loss is a factor q6, where q is the number of hash queries. As the results are non-tight, and
depend on the asymptotic analysis of [DFMS19], we make no claims about the concrete security
of Picnic in the QROM.”

In a similar vein, the authors of the MQDSS signature scheme [CHR+20] write in their latest
specifications:

“Another weakness of our security proof is that it is not at all tight. This is again an inherent
weakness introduced by the rewinding technique of the forking lemma. Therefore, in order to
produce a tight security reduction for MQDSS one would have to base the proof on different
techniques. At the moment, we are not aware of such techniques that we could use”

This lack of tightness can have real consequences. For example, there has been a recent
attack exploiting the non-tightness of the security reduction of the MQDSS signature scheme
by Kales and Zaverucha [KZ19]. This was fortunately easily fixable by increasing the param-
eters without too much harm but this overall situation is unsettling for the trust we have in
the parameter sets of these schemes, which is especially problematic since the NIST will soon
choose some post-quantum signature schemes to standardize with some fixed parameters. There
is therefore an urgent need to find as tight security reductions as possible for signature schemes
in the QROM.

[CGH04] but has been extremely useful for making efficient security reductions [KM15] and is passing well the
test of time.

2The GeMSS signature scheme described in [CFM+20] doesn’t even have a full concrete security claims against
classical adversaries for instance.

2



Our work in a few words

In this work, we show tight security reduction in the QROM for a large class of identification
schemes: namely 3-round commit-and-open identification schemes. We also derive a more pre-
cise reduction when considering parallel repetition of commit-and-open identification schemes.
We apply our results to existing signature schemes and show their concrete security, while until
now, only asymptotic security was known. We consider Stern’s signature scheme [Ste93] 3, the
3 round SSH signature scheme, which is a non-optimized version of the MQDSS signature the
PICNIC signature scheme and the scheme from [KTX08].

In order to find these tight reductions, we can’t use rewinding techniques as they introduce
non-tightness. Moreover, we have to be careful with quantum reprogramming techniques since
these can also add some non-tightness as we can see from the [DFMS19] results. So how do
we proceed? We first extend Unruh’s result and show the quantum security of the Fiat-Shamir
transform for identification schemes that have some notion of soundness between statistical
and computational soundness. Then, at a crucial moment of our proof, we need to replace
a random permutation by a pseudorandom permutation which is easily invertible. We use
the recent result on the quantum security of Feistel networks to construct this pseudorandom
permutation. We present all steps and proof techniques more in detail in Section 2. A drawback
of this work is that we use an extra computational assumption, namely the Small Range Function
Instantiation Assumption which states that we can instantiate the random oracle corresponding
to the commitment function with a random small range function (we will give much more details
later). Despite this assumption, we still think that currently, a tight proof in the QROM with
this extra assumption gives significantly more guarantees than a non-tight security proof which
can hide some real weaknesses, as shown by the attack of [KZ19].

This work is quite different and complements well the recent work [DFMS19, DFM20,
GHHM20] as it is more suited for concrete quantum security claims useful for designers of
signature schemes but is less general.

Related work

We briefly presented a few security results in the QROM, let us present a more detailed
presentation of related work which will still be far from exhaustive. The QROM was first studied
quite late actually in [BDF+11] where it was correctly assessed that in the quantum setting, an
adversary making queries to a random oracle should have a quantum access to it, since the hash
function it models has a public description. There, they showed the security of some schemes in
the QROM, as well as examples where schemes were secure in the ROM but not in the QROM.
Other impossibility results showed settings where, in all generality, the quantum Fiat-Shamir
transform is not secure [DFG13, ARU14]. On the positive side, [DFG13] proved the security
of the quantum Fiat-Shamir transform when oblivious commitments are used. Unruh [Unr15]
then showed that it was possible to do a Fiat-Shamir like transform to remove the interaction
from identification protocols. This transform is however rather inefficient and was hardly used
in practice. More recently, there have been new positive results related to the quantum security
of the Fiat-Shamir transform. If an identification scheme is lossy, then [KLS18] showed tight
concrete quantum security bounds for the Fiat-Shamir transform. They used this result to prove
the security of the Dilithium signature [DKL+17], which is a NIST competitor. Another related

3This scheme actually already has concrete quantum security bounds because the underlying identification
scheme can be made lossy[Lei18]. However, this introduces some losses in the parameters that don’t arise with
our techniques.

3



result is the security proof of qTESLA [ABB+19]. Unruh [Unr17] showed the quantum security
of the Fiat-Shamir transform for identification schemes with statistical security, or using a dual-
mode hard instance generator, a property closely related to the lossiness property. Another
related work is the the framework of recording quantum queries by Zhandry [Zha19] which is a
very powerful tool for studying random functions and the QROM.

Recently, 2 papers [DFMS19, LZ19] showed generic reduction for the quantum Fiat-Shamir
transform. Unlike what was believed before, they show that it is actually possible to perform
reprogramming of a quantum random oracle and to follow the classical proofs. Their results
are not tight and lose at least a factor of O(q2) where q is the number of queries to the random
function. The results of [LZ19] add even a larger factor of non-tightness but can be applied to
more general settings than those of [DFMS19]. Then, another work [DFM20] showed that this
O(q2) loss is tight and showed a large of class of examples where this is necessary. We will discuss
this in the next section and show that this is less harmful than it seems for security reductions.
Finally a recent result [GHHM20] presents optimal quantum reprogramming techniques with
applications.

2 State of the art, overview of our results and proof techniques

We will focus on the quantum security of the Fiat-Shamir transform for identification schemes
and we will use known results in the QROM to transform this security into the quantum security
for resulting signature schemes. As we will show, there are many cases where these reprogram-
ming techniques still lead to a large amount of non-tightness in the proof and the goal of this
paper is to present new techniques that overcomes this issue for an important class of signature
schemes.

State of the art for identification schemes

In an identification scheme IS, a prover P has a pair of public and secret key (pk, sk) and
wants to convince a verifier V (that sees only the public key pk) that he has a valid corresponding
secret key sk. In its most standard form, an identification scheme consists of 3 messages: a
first message x from P to V , a challenge c from V to P which is a random string and finally a
response z from P to V . V finally has a procedure that from (pk, x, c, z) determines whether
he is convinced or not. The Fiat-Shamir transform consists of replacing the above interaction
with a single message (x,H(x), z)4 from P to V where H is a hash function modeled as a truly
random function in the QROM.

An adversary, who knows only pk and no corresponding sk, breaks the Fiat-Shamir transform
of IS if he can construct a triplet (x,H(x), z) that the verifier will accept. Breaking the
identification scheme (in the sense of computational soundness) means that an adversary can
construct a string x and, when he receives a challenge c, he can construct a string z such that
the verifier will accept (pk, x, c, z).

The security of the quantum Fiat-Shamir transform means that we can polynomially relate
the above 2 probabilities. For example, the result in [DFMS19] can be stated as follows

QADVFSH[IS](t, qH) ≤ q2H ·QADVIS(O(t)). (1)

On the left side is the quantum probability (or advantage) of breaking the Fiat-Shamir transform
of an identification scheme IS with a quantum adversary running in time t and making qH

4The message actually just consists of (x, z) since H(x) can be constructed from x.

4



quantum queries to H. The right side corresponds to the probability of breaking IS for an
adversary running in time O(t). We can see already the term q2H accounting for the non-tightness
of this reduction.

There is another source of non-tightness: we often require a bound in terms of the quantum
advantage for special soundness and not computational soundness. An adversary that breaks
the 2-special soundness property is able to construct 2 valid triplets (x, c, z) and (x, c′, z′) with
c 6= c′5(the first message x is the same for both triplets). This can be generalized to γ-special
soundness where we require an adversary to create Îł valid triplets (x, c1, z1), . . . , (x, cÎł , zÎł) where
the challenges ci are pairwise distinct. One can relate computational soundness advantage with
Îł-special soundness advantage but this comes with another big loss in tightness. For example,
the authors of [DFMS19] use roughly6 the following bound:

QADVIS(t) ≤
[
QADV Îł-sp

IS (O(t))
] 1
2γ−1 (2)

which, when combined to Equation 1, gives the bound

QADVFSH[IS](t, qH) ≤ q2H ·
[
QADV Îł-sp

IS (O(t))
] 1
2γ−1 . (3)

We can see that already with Îł = 2, we have a cubic loss in the exponent because we use
special soundness and we lose a power 5 when requiring 3-special soundness, which are the 2
most common cases. In conclusion, while these asymptotic results, as well as those in [LZ19],
are extremely important for having post-quantum trust in the Fiat-Shamir transform for identi-
fication schemes, the amount of non-tightness is significantly too large to make concrete security
claims with decent parameters.

Overview of our results

Our results will remove this non-tightness for an important class of identification schemes,
namely commit-and-open identification schemes. In a commit-and-open identification scheme,
the prover can extract a string z = z1, . . . , zn from the secret key sk. His first message x =
G(z1), . . . , G(zn) consists of committing to all the values zi with a commitment function G and
then in the second message, he reveals a subset of the zi depending on the challenge c. Several
schemes, such as Stern’s identification scheme, the Picnic identification scheme and the SSH
identification scheme that inspired the MQDSS signature are of this form. They are all even
more particular: they consist of a parallel repetition of a commit-and-open identification scheme
IS with challenge size 3 and the advantage of the underlying post-quantum computational
assumption is equal to QADV 3-sp

IS (t).
Our results will rely on an additional computational, namely that the commitment function

modeled as a random oracle can be replaced with a random small range function. We discuss
this assumption now.

5In the asymptotic case, 2-special soundness is often defined with an efficient extractor that takes a pair of
triplets and outputs a valid secret key. The current definition is similar in spirit and uses an advantage notion
which is more adapted for concrete security bounds.

6The bound is actually slightly worst as Theorem 25 of [DFMS19] (in the eprint version) generalizes Lemma
7 of [Unr12] while it should generalize Lemma 8 in order to account for the fact that the challenges have to
be pairwise distinct. The difference is however only minimal and doesn’t change the asymptotic behavior, even
though it may add some small dependence in the size of the challenge space.

5



What do we mean when we say G can be replaced with a small range function and
why is this assumption justified?

A security claim in the (Q)ROM for a signature scheme S has the following 2 steps:

1. A security proof when some hash functions are modeled with random oracles.

2. An assumption that these random oracles can be replaced with (quantum) secure hash
functions without harming the security of S.

Usually, a proof in the (Q)ROM consists of proving (1) and S is said to be secure in the (Q)ROM
when it uses (2). The proof of (1) becomes useful when (2) is applied because random oracles
do not exist in real life. In our case, the situation is a bit different because we need some version
of (2) in order to prove (1). More precisely, we need the following statement, which we call the
Small Range Function Instantiation Assumption: if the hash function used for the commitment
is modeled as a random function from {0, 1}x to {0, 1}x, then it can be replaced with a function
f = h ◦ g where g is a random function from {0, 1}x to [r] and h is a random injective function
from [r] to {0, 1}x without harming the security of S. First, of course, this statement has to
depend on the size of r so we say we don’t lose more that the quantum security of f , which here

is O( q
3

r ) from collision lower bounds where q is the number of queries made to the commitment
function. For r sufficiently large, f is a very strong hash function, the only structure we have
is the separate access to h and g and our assumption essentially says that an adversary cannot
exploit this structure for breaking S. We say that this is a mild version of (2) because usually in
(2), we have an explicit functionH such as SHAKE256 that replaces the random oracle for which
we know much more structure and we assume this structure doesn’t help the adversary. Recall
that such an assumption (not necessarily with SHAKE256 but for some explicit function) has
to be made in order to make the proof in the QROM useful. However, since we can’t formally
prove that this is a weaker assumption than using (2) with a specific function, we keep this as
an extra computational assumption.

A final remark, our assumption is on functions from {0, 1}x to {0, 1}x but this doesn’t mean
we require the signature scheme we use to use a commitment of this form. In particular, the
output space can be smaller than the input space, which is not a problem for our proof.

We can now go back to the statement of ours results. Our first theorem deals specifically
with the parallel repetition case.

Theorem 1 (Simplified). Let IS be a commit-and-open identification scheme that uses a com-
mitment G modeled as a random oracle. Let γ ≥ 2 be an integer. For any t, qH, qG, and number
of repetition r, using the Small Range Function Instantiation Assumption, we have

QADVFSH[IS⊗r](t, qH, qG) ≤ QADV γ-sp
IS (O(t)) +O

(
q2H(γ − 1)r

|C|r

)
+O

(
q3G
|M |

)
where |C| is the size of the challenge space and |M | is the size of the space of each xi = G(zi).

Before discussing what we mean by the non-standard assumption ’that can be instantiated
with a random function with small range’, let us present the different terms of this theorem. The
left hand side is the probability (i.e. advantage) that a quantum adversary has of breaking the
Fiat-Shamir transform of IS⊗r, the r-fold parallel repetition of IS. The adversary is running in

6



time t and performs qH quantum queries to the hash function used in the Fiat-Shamir transform
and qG quantum queries to the commitment function G. We also use the QROM and model G
as a truly random function.

These terms on the right hand side are all necessary. The first term is supposed to be related

to the hardness of the computational problem. The term O
(
q2H(γ−1)r
|C|r

)
corresponds to applying

Grover’s algorithm on the challenge space. This attack appears for example in schemes that
have 3-special soundness but where an adversary can easily construct an x for which he can
successfully answer 2 of the 3 verifier’s challenges. This is also the attack that was presented in
[DFM20] with Îł = 2. So indeed, the q2H might be necessary but only for the part of advantage
related to the challenge attack and crucially, the O(q2H) factor loss in [DFMS19] isn’t tight in
front of the advantage to break the computational problem. What we describe here is also
true for the example presented in [DFM20] so their tightness result of the O(q2) loss factor is
much less harmful that what it seems even for schemes where it holds. The third term is also
necessary corresponds to attacking the commitment function and breaking the binding property
by finding collisions on G. An interesting remark about this theorem is that designers already
implicitly used results very similar to Theorem 2 but without a formal proof and used it to
determine the value of r7.

What we omitted in the description of Theorem 1 is that the O(t) hides some additive terms
that depend on |C| so they are well suited for parallel repetition of schemes with small challenge
but are not suited when these are exponential. To circumvent this, we also generalize the above
theorem when we don’t have parallel repetition but just a single identification scheme with
potentially a large challenge space. We prove the following

Theorem 2 (Simplified). Let γ ≥ 2 be an integer and let IS be a commit-and-open identification
scheme with a commitment function G modeled as a random oracle that can be instantiated with
a random function with small range. Using the Small Range Function Instantiation Assumption,
we have for any running time t and number of queries qH, qG

QADVFSH[IS](t, qH, qG) ≤ QADV γ-osp
IS (O(t)) +O

(
q2HÎł

|C|

)
+O

(
q3G
|M |

)
.

Here, the O(¡) terms do not depend on |C| anymore. This theorem is very similar to Theorem
1 but the reduction is to a weaker notion of special soundness, namely output special soundness
(hence the Îł-osp in the theorem) that we will discuss more in detail in the paper. Informally,
we want again the adversary to produce γ valid triplets (x, ci, zi) except that he doesn’t need to
know what are the challenges ci that correspond to the zi. The identification schemes we study all
can use Theorem 1 but it would be interesting to see if some other schemes could use Theorem 2.

Finally, an important conceptual step of our results is to relate the quantum Fiat-Shamir
advantage for any identification scheme (so not necessarily commit and open) to the notion of
Îł-rigid soundness. This notion can be seen as a computational-statistical notion of soundness
meaning that the adversary is computationally bounded when producing the first message x

7For example, the PICNIC scheme is of the form IS⊗r and we have 3-special soundness for IS (so we pick
Îł = 3) and |C| = 3. If we want 64 bits of quantum security (so qH = 264), we want from the challenge attack
q2H2r

3r
≤ 1 (omitting the O(·)) which implies r ≥ 219. If we want 128 bits of quantum security, this r has to be

doubled. This corresponds exactly to the number of repetitions of the PICNIC scheme respectively for levels 1
and 5 of the NIST security levels.

7



but unbounded when producing the response z (that depends on pk, x, and the challenge c).
Informally, an adversary breaks the Îł-rigid soundness property if he can construct x such that
he will be able to answer in a valid way at least Îł different challenges (he is unbounded for this
second message). We prove the following

Proposition 1. For any integer γ ≥ 2, time t, number of queries qH, and identification scheme
IS, we have

QADVFSH[IS](t, qH) ≤ QADV γ-rs
IS (t, qH) +O(

q2HÎł

|C|
).

This proposition can be seen as a generalization of Unruh’s reduction from the quantum
advantage of the Fiat-Shamir transform to statistical soundness. The fact that we impose a Îł
threshold here in our rigid soundness definition makes it easier to related to Îł-special soundness
without any losses in tightness. We use this proposition for commit-and-open identification
schemes but it could have more applications.

Techniques used

How to we achieve our results? The most common ways of proving the quantum security
of the Fiat-Shamir transform use techniques such as quantum rewinding or quantum repro-
gramming. These techniques are very general but introduce some non-tightness that we want
to avoid so we have to manage without them. Our starting point is to use Unruh’s result on
the quantum security of the Fiat-Shamir transform when the underlying identification scheme
has statistical soundness. In this case, things are fairly easy and we can invoke quantum lower
bounds on the search problem to conclude. As we wrote above, we first introduce the notion of
Îł-rigid soundness to achieve Proposition 1 that holds for any identification scheme.

We then look more precisely at commit-and-open identification schemes, where during the
first message, the prover commits to some values x = G(z1), . . . , G(zn) where G is the commit-
ment function and reveals a subset of those zi as his second message. We first show that we can
replace this function G with a random permutation σ 8. This comes from the fact that the actual
values of G(z1), . . . , G(zn) are used only for computing the challenge c = H(G(z1), . . . , G(zn)).
Since H is also random, we show that this change of G doesn’t change the quantum advan-
tage, on average on H. This is actually where we use the Small Range Function Instantiation
Assumption and we don’t use later in the proof.

However, because we want tight results, we are far from done. We can’t use generic relations
from computational soundness to Îł-special soundness (like the one in Equation 2). We need to
directly reduce to Îł-special soundness without going through computational soundness. To do
so, we need from the string σ(z1), . . . , σ(zn) to be able to recover the whole string z = z1, . . . , zn.
However, we only have black box access to σ and we don’t have access to a inversion oracle.
The idea we use to do this is to replace σ with a random permutation from a pseudorandom
permutation family {π̃K} which doesn’t change the security claim but which is easily invertible.
From there, we can tightly relate the Fiat-Shamir advantage to a Îł-special soundness advantage.
How do we construct this function π̃K? We use recent results on the quantum security of Feistel
networks from [HI19]. This result shows how to construct quantum secure random permutations
from random functions with black box access. These Feistel networks also have the property
that they are easily computable and invertible, even when the underlying random function is

8We note here that this replacement is just part of a proof technique. We prove the security of identification
schemes for random commitment schemes which are not permutations.

8



hard for the preimage finding problem. We use as the underlying pseudorandom function the
keyed KMAC256 functions, which are believed to be quantum secure.

Putting this all together, we can relate the quantum Fiat-Shamir to special soundness no-
tions. In order to use the security of the Feistel networks, we have to artificially increase the size
of the input space of the commitment scheme and we also replaced the random function G with
a function π̃K for random K. So how we can conclude about special soundness for the original
scheme. For Theorem 2, this is immediate as our transformations do not change the Îł-output
special soundness advantage. However, this is not true for Îł-special soundness. For Theorem
1, we actually reduce to a stronger variant of Îł-special soundness which is also invariant under
our transformations which immediately implies Theorem 1.

We now dive in the more formal part of this paper.

3 Preliminaries

Basic notations. For an integer N ∈ N∗, we denote by [N ] the set {1, . . . , N}. For a (usually
probabilistic) algorithm A(·), x ← A(·) means that we run A(·) with some fresh randomness
and get some output x. We will sometimes also use the notation A(·)→ x. We will also use the
notation x← D when D is a distribution when we sample x from D. For a set S, the notation

x
$←− S means that x is chosen uniformly at random from the set S. Let FXY be the set of

functions from X to Y and let PX be the set of permutations acting on X. The notation
4
=

designs an equality which is a definition. We will use Landau notations and also On(¡) meaning
poly(n)O(¡).

3.1 Quantum query algorithms.

In this work, we will often work with query algorithms that have a black box access to some
deterministic function f . A classical access to f means that we can perform queries that on
input x outputs f(x). A quantum access to f means that we can perform the unitary Uf in a
black box manner, where

Uf : |x〉|y〉 → |x〉|y ⊕ f(x)〉.

A quantum query algorithm with classical access to f will be denoted A f and a quantum
query algorithm with quantum access to f will be denoted A |f〉. For any quantum algorithm
A , we denote by |A | it’s total running time. We write |A |f〉| = (t, qf ) when A |f〉 runs in time
t and performs qf quantum queries to f. We can also write |A |f〉| = (∗, qf ) to specify only the
number of queries but not the running time. Unless stated otherwise, black box calls to f or
Uf are efficient and we fix the running time of a query to be equal to 1.

In the notation A |f〉, the behavior of the query algorithm is described by A and the super-
script |f〉 only indicates which function is queried. This means that the algorithm A |g〉 behaves
exactly as A |f〉 where calls to Uf are replaced with calls to Ug. We can also write A for a
quantum query algorithm where the queried function is not specified.

A query algorithm can perform queries to different functions. For example A |f〉,|g〉,|h〉 has a
black box access to the 3 unitaries Uf , Ug, Uh. We write |A |f〉,|g〉,|h〉| = (t, qf , qg, qh) to denote the
fact that A |f〉,|g〉,|h〉 runs in time t, performs qf queries to Uf , qg queries to Ug and qh queries to
Uh. Finally, we define the q-query quantum variational distance between 2 distributions D1, D2

9



on functions as

∆q(D1, D2)
4
= max

A :|A |=(∗,q)

∣∣∣∣ Pr
f←D1

[A |f〉(·) outputs 0]− Pr
g←D2

[A |g〉(·) outputs 0]

∣∣∣∣ .
3.2 Hash functions and Feistel networks

SHAKE256. A prime function for instantiating random oracles in the post-quantum setting
is SHAKE256. It is a SHA-3 variant [BDPV11] that uses the sponge construction with variable
input and output sizes. We write SHAKE256X,Y to explicit the input space X and output space
Y . The sponge construction is known to be quantum secure [CHS19] and it is standard in the
QROM to model SHAKE256X,Y with a random function in FXY for which we only have black
box access. There are keyed versions of SHAKE256 called KMAC256K indexed with a key K.
This function family is believed to be a quantum secure pseudo random function family.

Feistel networks. Feistel networks are a generic way to transform pseudorandom functions
in pseudorandom permutations. They were first studied by Luby and Rackoff [LR88], and
we know well their classical security. Recently, the quantum security was proven for 4 round

Feistel networks. Very briefly, the 4 round Feistel network starts with a function f ∈ F{0,1}
n

{0,1}n

and constructs a permutation Fe4(f) ∈ P{0,1}2n . Fe4(f) uses 4 black box calls to f and both
Fe4(f) and Fe4(f)−1 are efficiently computable if we know how to efficiently comput";"""date"",""2021-03-16T12:48:28Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2021-03-16T12:48:28Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017) kpathsea version 6.2.3""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2021-03-16T12:48:28Z""
""created"",""2021-03-16T12:48:28Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2021-03-16T12:48:28Z""
""resourceName"",""699.pdf""
""Author"",""""
""producer"",""pdfTeX-1.40.18""
""pdf:docinfo:producer"",""pdfTeX-1.40.18""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""8"",""4"",""6"",""2"",""23"",""13"",""6"",""0"",""6"",""44"",""17"",""46"",""7"",""26"",""26"",""102"",""46"",""48"",""50"",""39"",""9"",""0"",""0"",""0"",""3"",""85"",""34"",""14""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2021-03-16T12:48:28Z""
""Last-Modified"",""2021-03-16T12:48:28Z""
""dcterms:modified"",""2021-03-16T12:48:28Z""
""title"",""""
""Last-Save-Date"",""2021-03-16T12:48:28Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2021-03-16T12:48:28Z""
""meta:save-date"",""2021-03-16T12:48:28Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017) kpathsea version 6.2.3""
""Content-Length"",""527658""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""32""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""2378"",""2875"",""3237"",""2871"",""2807"",""2750"",""3064"",""3019"",""2621"",""2219"",""2774"",""2591"",""1632"",""1925"",""2028"",""1883"",""1955"",""1897"",""2465"",""1931"",""1339"",""1740"",""1744"",""1558"",""2273"",""2209"",""1968"",""440"",""1614"",""1826"",""1623"",""858""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2021-03-16T12:48:28Z""
";https://scholar.google.ch/scholar?start=880&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098839-280;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Blockchain and Industry Use Cases;S Van Hijfte ; Decoding Blockchain for Business, 2020  Springer;;"… Enterprise applications team, which works on solutions that integrate blockchain with the Oracle

ERP cloud … We mentioned a bit earlier that the blockchain world has also seen a rise in … Later in

this book you will read an entire section on cryptocurrency regulation, which really …";Cité 1 fois;;[HTML] nih.gov;https://www.ncbi.nlm.nih.gov/pmc/articles/pmc7989945/;;;https://scholar.google.ch/scholar?start=820&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098870-349;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;A Combinatorial Approach to Quantum Random Functions;N Döttling, G Malavolta, S Pu ; … Conference on the Theory and Application …, 2020  Springer;;"… Let A be a quantum algorithm making q quantum queries to an oracle \(H:\mathcal {X} \rightarrow

\mathcal {Y} \). If we draw H from … This is proved in [28] and immediately implies that, if two weight

assignments on oracles, \(D_1\) and \(D_2\), are 2q-wise equivalent, then any q …";Autres articles;;[PDF] iacr.org;https://eprint.iacr.org/2020/1508.pdf;"
A Combinatorial Approach to Quantum Random
Functions

Nico Döttling1, Giulio Malavolta2, and Sihang Pu1

1 CISPA Helmholtz Center for Information Security,
{doettling, sihang.pu}@cispa.saarland,

2 Max Planck Institute for Security and Privacy.
giulio.malavolta@hotmail.it

Abstract. Quantum pseudorandom functions (QPRFs) extend the classical secu-
rity of a PRF by allowing the adversary to issue queries on input superpositions.
Zhandry [Zhandry, FOCS 2012] showed a separation between the two notions and
proved that common construction paradigms are also quantum secure, albeit with
a new ad-hoc analysis. In this work we revisit the question of constructing QPRFs
and propose a new method starting from small-domain (classical) PRFs: At the
heart of our approach is a new domain-extension technique based on bipartite
expanders. Interestingly, our analysis is almost entirely classical.
As a corollary of our main theorem, we obtain the first (approximate) key-
homomorphic quantum PRF based on the quantum intractability of the learning
with errors problem.

1 Introduction

Pseudorandom functions (PRFs) are one of the fundamental building blocks of modern
cryptography. PRFs were introduced in the seminal work of Goldreich, Goldwasser and
Micali [13] answering the question of how to build a function that is indistinguishable
from a random function. Loosely speaking, a PRF guarantees that no efficient algo-
rithm, with oracle access to such a function, can distinguish it from a truly random
function. PRFs have been shown to be an invaluable tool in the design of cryptographic
primitives (such as block ciphers and message authentication codes) and are by now
a well-understood object: After the tree-based construction of [13], PRFs have been
build from pseudorandom synthesizers [19] and directly from many hard problems
[20,21,22,11,18,7,2].

However, when considering the more delicate quantum settings, the study of the
hardness of PRFs is still at its infancy. Before delving into the details of this primitive,
some clarification is needed as one can define the quantum security of a PRFs in two
ways:

1. The PRF is secure against a quantum machine that can only issue classical queries
to the function (although the internal state of the adversary is quantum).

2. The PRF is secure against a quantum machine that is allowed to query it on input
superposition states and is given as a response the superposition of the corresponding
outputs, i.e., it can issue quantum queries. This setting is the focus of our work and
we refer to it as quantum security.



The first setting is commonly referred to as post-quantum security and it involves the use
of hard problems that are conjectured to be intractable even for quantum computers, but
this aspect typically does not further affect the analysis of known construction paradigms.
On the other hand, the latter setting has been shown to require a fundamentally different
approach: In his pioneer work, Zhandry [27] gave a separation between the two models,
i.e., he constructed a PRF that is post-quantum secure but provably not quantum secure.
On the positive side, he showed that the generic constructions of [13] and [19] are also
quantum secure, albeit with a completely different analysis. He also provided a quantum
analysis of the PRFs of [2], which assumes the post-quantum hardness of the learning
with errors problem [24].

Beyond the theoretical interest, quantum security gives a more conservative model
to analyze the hardness of PRFs in a world with quantum machines. As an example, if
PRF is used as a message authentication code (MAC) by some quantum computer, then
it is reasonable to assume that an adversary might be able to obtain the function output
when evaluated on some input superposition. In this case, MACs based on post-quantum
secure PRFs might not be secure anymore. Boneh and Zhandry in their work[8] studied
this problem and constructed the first message authentication codes against quantum
chosen message attack. They also showed that a quantum secure PRF is sufficient for
constructing a quantum secure MAC. Unfortunately, the current landscape of quantum
PRFs is rather unsatisfactory: Current techniques to analyze hardness of PRFs in the
quantum settings are geared towards specific constructions. As a result, only a handful
of quantum-secure schemes are known.

1.1 What Makes QPRFs Challenging?

At the heart of Zhandry’s separation result [27] is the observation that quantum algorithms
can detect hidden linear structures. This problem is also present when we extend the
domain of truly random functions. Assume that f : {0, 1}λ → {0, 1}λ is a uniformly
random function and H : {0, 1}2λ → {0, 1}λ is a random linear function and therefore
a universal hash function [9]. The function x 7→ f(H(x)) can easily be shown to be
statistically indistinguishable from a truly random function for any classical distinguisher
with oracle access to this function. However, using the algorithm of Boneh and Lipton [6]
one can efficiently find elements in the kernel of H via superposition queries to f(H(¡)).
Given an element z in the kernel of H , f(H(x)) can be distinguished from a truly
random function g : {0, 1}2λ → {0, 1}λ by two classical queries, as it holds for any
x ∈ {0, 1}2Ν that f(H(x + z)) = f(H(x)). Such a collision, however, happens only
with exponentially small probability for a random g.

What this shows is that the advantage of superposition adversaries over classical
adversaries goes far beyond their computational advantage. Superposition adversaries
can learn strictly more about the structure of a function it is given oracle access to than a
classical (even unbounded) adversary ever could.

1.2 Our Results

In this work we explore a different route and we propose a new approach to construct
QPRFs. Our construction is based on the framework of Döttling and Schröder [12],

2



which in turn builds on earlier ideas of PRF domain extension [16,4] and constructions
of adaptively secure PRFs from non-adaptively secure ones [3].

At the heart of our approach is a domain extension technique based on bipartite
expander graphs, which crucially allows us to reduce the quantum hardness of our PRF
to the classical (post-quantum) hardness of a small-domain PRF. Specifically, we will
prove the following theorem.

Theorem 1 (Informal). For any q let PRFq : K × Y → Z be a (post-quantum) classi-
cally secure PRF with (small) domain Yq and let Γ (x, j) be a suitable expander mapping
from a vertex x to its j-th degree neighbor, where the expander Γ has degree Di. Then

F (K,x) =
ω(logλ)⊕
i=1

⊕
j∈[Di]

PRF2i(K2i , Γ (x, j)),

where K = (K21 , . . . ,K2i , . . . ,K2ω(logλ))3, is a quantum PRF.

This gives an alternative and (arguably) conceptually simpler approach to construct-
ing QPRFs. An interesting aspect of our result is that our analysis concerns almost
exclusively the classical settings and quantum security is achieved by a simple observa-
tion: The crux of our analysis will consist in reducing the classical hardness of the PRF
to that of a small domain PRF, which is also trivially quantum secure since the attacker
can query the full domain. This result can be seen as a compiler which converts any
post-quantum secure PRF into a QPRF at a moderate overhead and without having to go
through the (expensive) GGM construction of [27].

As an additional result, we obtain a new implication: Assuming the quantum-
intractability of the learning with errors problem, then there exists a quantum (almost)
key-homomorphic PRF.

Quantum Key-Homomorphic PRF. Key-homomorphic PRFs were introduced by
Boneh et al. [5] and have applications in the context of proxy-re-encryption and re-
lated key security. In a nutshell, for key-homomorphic PRFs the key-space is a group
and it holds for all x that PRF (K1 + K2, x) = PRF (K1, x) + PRF (K2, x). Key-
homomorphic PRFs give rise to a very natural protocol for a distributed PRF. Boneh et
al. showed that the function

PRFKH(k, x) =
⌈∏̀
i=1

Axi ¡ k
⌋
p

,

where A0 and A1 are two random public matrices in Zm×mq , is additively key-
homomorphic (ignoring a small error) over the vector space Zmq . The function is
pseudorandom under the learning with errors assumption, which is conjectured to be

3 Note that we could XOR them from log λ to ω(log λ), but for simplicity, we still use the range
from 1 to ω(log λ).

3



intractable also for quantum computers. Then a simple application of our compiler
shows us that

F (K,x) =
ω(logλ)∑
i=1

∑
j∈[Di]

PRFKH(K2i , Γ (x, j)) mod p

is a quantum key-homomorphic PRF.

1.3 Technical Overview

We start by providing a technical outline of our results. As mentioned above, we use the
framework of [12] to construct our QPRFs. This framework has two steps, a domain
extension step and a combiner step. The domain extension step takes a small domain PRF
with domain size poly(q) and constructs from it a q-bounded PRF on a large domain, e.g.
{0, 1}Îť. A PRF is called q-bounded if security is only guaranteed for adversaries which
make at most q queries. An important aspect about this step is that the small domain
PRF can be evaluated in time (essentially) independent of q.

The second step, or combiner step, combines a small number of bounded PRFs
which have the same domain. The key idea here is to set the bounds in an exponentially
increasing way. More specifically, if PRFq(Kq, x) are q-bounded PRFs, we combine
them into a function F via

F (K,x) =
t⊕
i=1

PRF2i(K2i , x)

where K = (K1, . . . ,K2t). We will choose the parameter t to be slightly super-
logarithmic in the security parameter Îť. We claim that if PRFq(Kq, x) is a q-bounded
QPRF as long as q is polynomial, then F (K,x) is an (unbounded) QPRF. We will briefly
argue how this can be established. Fix a BQP distinguisher A against the QPRF security
of F . Since this distinguisher is efficient, there is a polynomial upper bound q on the
number of superposition queriesA will make. Given such a distinguisher we will, choose
i∗ = dlog(q)e 6 t and construct a BQP distinguisher A′ against the 2i∗-bounded secu-
rity of PRF2i∗ . Notice that since 2i∗ 6 2q and q is polynomial it holds that 2i∗ is also
polynomial. The distinguisher A′ gets q-bounded superposition access to an oracle O
which computes either PRF2i∗ or a uniformly random function f . Given a superposition
query

∑
|x〉 by A, A′ submits this query to its oracle O obtaining a superposition state∑

|x〉|O(x)〉. Now, A′ can convert this state into∑
|x〉|O(x)⊕

⊕
i 6=i∗

PRF2i(K2i , x)〉

via a local quantum computation and forwards this state to A. In the end, A′ outputs
whateverA outputs. Now notice that ifO(·) computes PRF2i∗ (K2i∗ , ·), thenA′ perfectly
simulated superposition access to F (K, ¡) to A. On the other hand, if O(¡) computes
a truly random function, then O(x) ⊕

⊕
i6=i∗ PRF2i(K2i , x) is also a truly random

4



function. Consequently, A′ distinguishes PRF2i∗ from uniform with the same advantage
that A distinguishes F from uniform.

The more challenging aspect of our approach is the construction of a q-bounded
QPRF from a small domain PRF. As outlined in Section 1.1, even domain extension
techniques that are statistically secure against classical adversaries might be completely
insecure against a superposition adversary. We circumnavigate this problem by adopting a
perfectly secure domain extension technique. We can then use a Lemma by Zhandry [27]
which states that any classical 2q-independent function is identically distributed to a
uniform function from the view of a q-bounded superposition adversary.

It turns out that we can realize perfectly secure domain extension using highly unbal-
anced expander graphs via constructions that have previously been used to construct
space-efficient k-independent functions [10]. In a nutshell, a highly unbalanced expander
is a bipartite graph Γ where the set of left vertices [N ] can be made super-polynomially
large, the set of right vertices [L] is only polynomially large, and the degree D is poly-
logarithmic. Moreover, such graphs have a unique neighbor expansion property in the
sense that it holds for any subset S ⊂ [N ] of left-vertices not larger than a (polynomial)
bound Q that there exists a vertex v in Γ (S) ⊂ [L] (the neighborhood of S) which has
a unique neighbor in S. A construction of such graphs was provided by Guruswami,
Umans and Vadhan [14].

Equipped with such a graph Γ , we can now extend a random function f defined on
the small domain [L] to a Q-bounded random function g defined on the large domain
[N ] as via a simple tabulation function. For a left vertex x ∈ [N ] and an index j ∈ [D],
let Γ (x, j) ∈ [L] be the j-th neighbor of x. Define the function g by

g(x) =
⊕
j∈[D]

f(Γ (x, j)).

We claim that if f is a uniformly random function, then g is a Q-wise-independent
function, i.e. it holds for any pairwise distinct x1, . . . , xQ ∈ [N ] that g(x1), . . . , g(xQ)
are independent and uniformly random. To see this note that by the unique neighbor
expansion property of Γ , as the set S = {x1, . . . , xQ} is of size Q there exists a vertex
v ∈ Γ (S) which has a unique neighbor xi∗ in S. In other words, there is an index
j∗ ∈ [D] such that the term f(Γ (xi∗ , j∗)) only appears in

g(xi∗) =
⊕
j∈[D]

f(Γ (xi∗ , j)),

but not in any other g(xi) for i 6= i∗. Since f(Γ (xi∗ , j∗)) is uniformly random and inde-
pendent of all the g(xi), it follows that g(xi∗) is uniformly random and independent of
all the g(xi). We can repeat this argument recursively arguing that the g(x1), . . . , g(xQ)
are uniformly random and independent. Now assume that Q = 2q. We claim that if PRF
is a post-quantum PRF with (polynomially-sized) domain [L], then it holds that

F (K,x) =
⊕
j∈[D]

PRF(K,Γ (x, j))

is a q-bounded QPRF on the large domain [N ]. To argue security, assume that A is a
q-bounded BQP distinguisher which distinguishes F from a truly random function. We

5



will first replace PRF with a truly random function f and argue security via the post-
quantum security of PRF. Specifically, if A could distinguish these two cases we can
construct a post-quantum distinguisher A′ against the PRF security of PRF. A′ is given
access to an oracle O and proceeds as follows. It first queries O on every possible input
obtaining the entire function table of O. This can be performed efficiently as the domain
of O is of size L, which is polynomial. Now, A′ can give A superposition access to the
function O′(x) =

⊕
j∈[D]O(Γ (x, j)) via a local quantum computation, since it knows

the entire function table ofO. Consequently, ifA distinguishes F (K,x) from a function
F ′(x) =

⊕
j∈[D] f(Γ (x, j)) where f is a truly random function, then A′ distiguishes

PRF from a truly random function. Finally, as F ′(x) =
⊕

j∈[D] f(Γ (x, j)) is a 2q-
independent function, we can argue that since A is q-bounded it is identically distributed
to a uniformly random function from the view of A via a Lemma by Zhandry [27]. This
concludes the overview.

From a conceptual perspective, the main reason why our proof is simpler than, e.g.,
Zhandry’s proof for QPRF security of the GGM construction [27], stems from the fact
that the above reduction A′ can query the entire function table of the small domain PRF
PRF and simulate a quantum oracle for A locally.

2 Applications

In this section we discuss the possible applications of quantum secure PRFs.

2.1 Quantum secure MACs

Classically, any pseudorandom function can be used to implement message authentication
codes (MAC). Moreover, for quantum adversaries, we can use post-quantum secure PRFs
to protect classical messages. However, what if the quantum adversary has the ability
to query superpositions of messages? In this situation, the entire chosen message game
would be held in the quantum environment which needs stronger version of security.
For instance, considering a random oracle H , if the adversary can only issue classical
queries, after learning q queries she does not learn any additional information at other
inputs; but if she can issue quantum queries, then she might get information on all inputs
simultaneously, even with just a single query.

Boneh and Zhandry [8] defined a quantum chosen message attack game to model
the security of any MAC scheme in the quantum setting. First, quantum queries need to
be explicitly modeled as the adversary could be entangled with the queries. We denote
the adversary’s state just prior to issuing a signing query by Σm,x,yψm,x,y|m,x, y〉 and
the signing oracle performs the following transformation,

Σm,x,yψm,x,y|m,x, y〉 → Σm,x,yψm,x,y|m,x⊕ S(k,m; r), y〉,

where r is a random string and S(k,m; r) is the signing algorithm of a MAC scheme.
Then we say that the adversary wins this game if she can generate q + 1 valid classical

6



message-tag pairs after issuing q quantum chosen message queries. The formal definition
of quantum secure MACs is given as follows 4.

Definition 1. A MAC system is existentially unforgeable under a quantum chosen mes-
sage attack (EUF-qCMA) if no adversary can win the quantum MAC game with non-
negligible advantage in Îť.

Boneh and Zhandry [8] also showed that a quantum secure pseudorandom function
gives rise to the quantum-secure MAC, namely S(k,m) = PRF(k,m).

Theorem 2 ([8]). If PRF : K ×X → Y is a quantum-secure pseudorandom function
and 1/|Y| is negligible, then S(k,m) = PRF(k,m) is a EUF-qCMA-secure MAC.

Therefore, the theorem 2 implies that a quantum secure PRF is sufficient to give us a
quantum secure MAC.

2.2 Pseudorandom Quantum States

Pseudorandom states (or pseudorandom quantum states, denoted as PRS), are a set of
random states {|φk〉} that is indistinguishable from Haar random quantum states. In
[17], Ji et al. generalizes the definition of pseudorandomness in the classical case to the
quantum setting:

Definition 2 (Pseudorandom states). Let Îş be the security parameter. Let H be a
Hilbert space and K the key space, both parameterized by Îş. A keyed family of quantum
states {|φk〉 ∈ S(Hk∈K)} is pseudorandom, if the following two conditions hold:

1. Efficient generation. There is a polynomial-time quantum algorithmG that generates
state |φk〉 on input k. That is, for all k ∈ K, G(k) = |φk〉.

2. Pseudorandomness. Any polynomially many copies of |φk〉 with the same random
k ∈ K is computationally indistinguishable from the same number of copies of a
Haar random state. More precisely, for any efficient quantum algorithm A and any
m ∈ poly(κ),

| Pr
k←K

[A(|φk〉⊗m) = 1]− Pr
|ψ〉←µ

[A(|ψ〉⊗m) = 1]| = negl(κ)

where Âľ is the Haar measure on S(H).

Moreover, they also show that any quantum secure PRF could be used to construct
PRS as follows.

Theorem 3 ([17]). For any QPRF PRF : K ×X → X , the family of states {|φk〉}k∈K,

|φk〉 = 1√
N

∑
x∈X

ω
PRFk(x)
N |x〉,

is a PRS.

Finally, PRS can be immediately used to construct a private-key quantum money
scheme [17].

4 Recently, blind-unforgeable, a stronger security notion for qMAC is defined in [1]. It implies
EUF-qCMA notion and can also be satisfied by quantum secure PRF.

7



3 Preliminaries

We denote by Ν ∈ N the security parameter, by poly(Ν) any function that is bounded by a
polynomial in Îť, and by negl(Îť) any function that is negligible in the security parameter.
We abbreviate computational indistinguishability of two distributions by ≈c. The set of
N elements is always written as [N ]. We also denote as DO a distinguisher D access to
an oracle O via classical queries and A|O〉 via quantum queries.

3.1 Quantum Computing

We recall some basic facts about quantum computing.

Fact 1 ([23]) Any classical efficiently computable function f can be implemented effi-
ciently by a quantum computer. Furthermore, any function that has an efficient classical
algorithm computing it can be implemented efficiently as a quantum-accessible oracle.

Fact 2 ([28]) For any sets X and Y , we can efficiently ‘construct’ a random oracle
from X to Y capable of handling q quantum queries, where q is a polynomial. More
specifically, the behavior of any quantum algorithm making at most q queries to a 2q-
wise independent function is identical to its behavior when the queries are made to a
random function.

A more formal statement of Fact 2 is given in the following.

Theorem 4 ([28]). Let A be a quantum algorithm making q quantum queries to an
oracle H : X → Y . If we draw H from some weight assignment D5, then for ev-
ery z, the quantity PrH ←$D[AH(·) = z] is a linear combination of the quantities
PrH ←$D[H(xi) = ri,∀i ∈ {1, . . . , 2q}] for all possible settings of the xi and ri.

This is proved in [28] and immediately implies that, if two weight assignments on oracles,
D1 and D2, are 2q-wise equivalent, then any q query quantum algorithm behaves the
same under both weight assignments, since for all 2q pairs (xi, ri) it holds that

Pr
H ←$D1

[H(xi) = ri,∀i ∈ {1, . . . , 2q}] = Pr
H ←$D2

[H(xi) = ri,∀i ∈ {1, . . . , 2q}].

3.2 Pseudorandom Functions

We recall definition of classical pseudorandom functions [13].

Definition 3 (Pseudorandom Functions). Let XÎť and YÎť be two finite sets depending
on λ. We say that an efficiently computable keyed function PRF : Kλ × Xλ → Yλ
with key-space KÎť is a pseudorandom function (PRF), if it holds for every PPT oracle
adversary A that

|Pr[APRF(K,·)(1λ) = 1]− Pr[AR(1λ) = 1]| 6 negl(λ),

where K ←$Kλ and R : Xλ → Yλ is a randomly chosen function. Moreover, if |X | 6
poly(Îť), then we say that PRF is a small-domain PRF, otherwise we call PRF a large-
domain PRF.

5 A weight assignment on a set X is a function D : X → R such that
∑

x
D(x) = 1. As an

example, and the way we use it in our work, it could model a probability distribution.

8



If A is a quantum machine, then we say that the PRF is post-quantum secure. Note that
A is restricted to issue only classical queries, but its computation can be quantum. We
now recall the notion of q-bounded PRF [12]. The difference between q-bounded PRF
and PRF is just the former can only send at most q distinct queries. As in [12], our only
restriction is that the runtime of the function depends polynomially on Îť and log(q).

Definition 4 (Bounded Pseudorandom Functions). Let XÎť and YÎť be finite sets. A
keyed function Fq : Kq ×Xλ → Yλ parameterized by a parameter q is a q-bounded
pseudorandom function (bPRF), if Fq is computable in time poly(Îť, log(q)) and if it
holds for all efficiently computable q∗ = q(λ) 6 poly(λ) and all q∗-query distinguishers
D (i.e. send at most q∗ distinct queries) that

|Pr[DFq(K,·)(1λ) = 1]− Pr[DR(1λ) = 1]| 6 negl(λ),

where K ←$Kq and R : Xλ → Yλ is a randomly chosen function.

Quantum Pseudorandom Functions. We define quantum PRFs in the following.
Roughly speaking, we say a pseudorandom function PRF is quantum-secure if no
efficient quantum adversary A making quantum queries can distinguish between a ran-
dom function R and the function PRF. By quantum query we mean that the adversary A
can send a quantum superposition to the oracle and receive a the corresponding quantum
superposition of the function evaluation in return.

Definition 5 (Quantum-secure Pseudorandom Functions). A pseudorandom func-
tion PRF : Kλ×Xλ → Yλ is quantum-secure if no efficient quantum adversaryAmaking
quantum queries can distinguish between a truly random function R and the function
PRF(K, ·) for a randomK ←$Kλ. Specifically, for keyed function PRF : Kλ×Xλ → Yλ
with key-space KÎť, we say it is a quantum-secure pseudorandom function (QPRF) if it
holds for every efficient quantum adversary A that

|Pr[A|PRF(K,·)〉(1λ) = 1]− Pr[A|R〉(1λ) = 1]| 6 negl(λ),

where K ←$Kλ and R : Xλ → Yλ is a randomly chosen function.

We also define the notion of q-bounded quantum PRFs in a similar spirit as above.

Definition 6 (Bounded Quantum-secure Pseudorandom Functions). Let XÎť and
Yλ be finite sets. A keyed function Fq : Kq ×Xλ → Yλ parameterized by a parameter q
is a q-bounded quantum-secure pseudorandom function (bQPRF), if Fq is computable in
time poly(λ, log(q)) and if it holds for all efficiently computable q∗ = q(λ) 6 poly(λ)
and all q∗-query quantum adversary A (i.e. send at most q∗ distinct quantum queries)
that

|Pr[A|Fq(K,·)〉(1λ) = 1]− Pr[A|R〉(1λ) = 1]| 6 negl(λ),

where K ←$Kq and R : Xλ → Yλ is a randomly chosen function.

9



4 Bipartite Expanders

Expanders are highly connected sparse graphs, which are significantly useful in computer
science, and there is a rich body of work on constructions and properties of expanders
(see, e.g., [15] and references therein). We recall the definitions of bipartite graphs and
expanders in the following.

Definition 7 (Bipartite Graph). A bipartite graph withN left-vertices,L right-vertices,
and D left-degrees is specified by a function Γ : [N ] × [D] → [L], where Γ (x, j)
denotes the j-th neighbor of x. For a set S ⊆ [N ], we denote as Γ (S) its set of neighbors
{Γ (x, j) : x ∈ S, j ∈ [D]}.

Definition 8 (Bipartite Expander). A bipartite graph Γ : [N ] × [D] → [L] is a
(6 Q,A) expander if for all S ⊆ [N ] with |S| 6 Q, it has: |Γ (S)| > A · |S|, where A
is expansion factor.

We are only interested in highly unbalanced expanders with N ďż˝ L. An explicit
construction (i.e., where Γ (·, ·) is computable in polynomial time) of such an expander
has been shown in [14]. We recall here the theorem.

Theorem 5 ([14]). For all constants ι > 0 : for every N ∈ N, Q 6 N , and Ξ > 0,
there is an explicit (6 Q, (1 − ξ)D) expander Γ : [N ] × [D] → [L] with degree
D = O

(
((logN)(logQ)/Ξ)1+1/ι) and L 6 D2 ¡ Q1+ι. Moreover, D and L are

powers of 2.

4.1 Q-unique Expanders

In our construction, we need a (6 Q, (1− ξ)D) expander to be Q-unique, which means
in every subset of left-vertices with size not greater than Q, there must exist a vertex
with a unique neighbor (i.e., this unique neighbor is connected to only one vertex). This
property is defined in [10] as constructing functions where every subset S of inputs of
size at most Q contains an input that has many unique neighbors. It is formalized as:

Definition 9 (Q-unique Expander). A (6 Q, (1−ξ)D) expander Γ : [N ]×[D]→ [L]
is Q-unique if for all S ⊆ [N ], |S| 6 Q, there exists a x ∈ S such that
|Γ ({x})\Γ (S\{x})| > l > 0 holds.

Note l in Definition 9 is a way to measure uniqueness of a expander: The greater the l is,
the more unique neighbors an input can have. In our construction, we only need l = 0
which means (at least) one unique neighbor would be sufficient for us. Moreover, there
is also a concept of Q-wise-independence:

Definition 10 (Q-wise-independence). LetQ be a positive integer and letF be a family
of functions from Y to Z . We say that F is a Q-wise-independent family of functions if,
for every choice of l 6 Q distinct keys y1, . . . , yl and arbitrary values z1, . . . , zl, then,
for f selected uniformly at random from F we have that

Pr[f(y1) = z1, . . . , f(yl) = zl] = |Z|−l.

10



The existence of such Q-unique expanders is showed as follows.

Theorem 6. Given any (6 Q, (1−ξ)D) expander Γ : [N ]× [D]→ [L] from Definition
8, if ξ < 1/2, then expander Γ is Q-unique for l = 0.

Proof. First we want to show that there must exist a vertex in Γ (S) with degree at most
one, when ξ < 1/2. Assume towards contradiction that every vertex in Γ (S) has degree
at least 2 when ξ < 1/2. Then the number of edges between S and Γ (S) is at least two
times as |Γ (S)|. By Definition 7, we have that

D · |S| > 2 · |Γ (S)|.

Next, by Definition 8, we have |Γ (S)| > (1− ξ)D · |S| (in which (1− ξ)D is expansion
factor), therefore

D · |S| > 2(1− ξ)D · |S|
1 > 2(1− ξ)
Ξ > 1/2,

which is a contradiction since there is Ξ < 1/2. It follows that if Ξ < 1/2, then there
exists one vertex in Γ (S) with degree less than or equal to 1. However, we already know
that the degree cannot be zero since it’s in the neighbors set. Therefore it must be 1. This
completes the proof. ut

Now we will state a useful lemma here. In his seminal paper [25], Siegel showed
how a Q-unique expander can be combined with a small domain random function to
obtain a Q-wise-independent function. We use a light variation of Siegel’s technique
here. It is also used by works [26] and [10].

Lemma 1. Let Γ : [N ]× [D]→ [L] be a Q-unique expander, let f : [L]→ {0, 1}λ be
a uniformly random function and let h : [N ]→ {0, 1}λ be defined by

h(x) =
⊕
j∈[D]

f(Γ (x, j)).

Then h is a Q-wise-independent function.

4.2 Parameters

Typically, goals in constructing an unbalanced bipartite expander are to maximize the
expansion factor A, minimize the degree D, and minimize the size L of the right-
hand side (L 6 N ). Although we do not care about the concrete expansion factor
A in this work, we still expect a small L (to highly extend domains of PRFs) and
small D (to reduce computational overheads). By Theorem 5 we can fix a domain size
N = 2λ and a bound Q = poly(λ) and get an explicit expander Γ : [N ]× [D]→ [L]
where D = poly(log(N), log(Q)) and L = poly(D,Q). Consequently, the degree D is
essentially independent of Q and L is of size at most polynomial in Q.

11



5 Our Quantum Pseudorandom Function

In this section, we present our constrction for a quantum PRF from bipartite expanders.
First we show how to construct a perfectly secure (or loseless) domain extender which
takes as input a small-domain classical (post-quantum) PRF and outputs a q-bounded
quantum PRF with large domain. Second we show a combiner that turns a family of
q-bounded quantum PRFs into a standard quantum PRF. Note that our proof of security
is tight: If a quantum adversary A can distinguish a quantum PRF F from truly random
function R with advantage ε, then there exists an adversary A′ which can distinguish a
small-domain PRF from a truly random function (issuing only classical queries) with
the same advantage Îľ.

5.1 Domain Extension

In the following we present a new domain extension technique based on bipartite
expanders. Our compiler is shown below.

Construction 1 Let PRF : Kq × Y → Z be a keyed function with key space Kq. Let
Γ : {0, 1}λ × [D] → {0, 1}l be a (6 2q, (1 − ξ)D) expander with ξ ∈ (0, 1/2). We
define the keyed function Fq : Kq ×X → Z with key space Kq by

Fq(K,x) =
⊕
j∈[D]

PRF(K,Γ (x, j)),

where K ←$Kq, D = poly(λ), l = O(log(λ)), and X : {0, 1}λ,Y : {0, 1}l,Z :
{0, 1}m.

The following theorem states that the function Fq is a q-bounded quantum PRF.

Theorem 7. Let PRF and Fq be as in Construction 1. If PRF is a post-quantum (clas-
sically secure) PRF, then Fq is a q-bounded quantum PRF. More specifically, if there
exists a q∗ 6 poly(λ) and a q∗-query quantum adversary A that distinguishes Fq∗ from
a truly random function R : X → Z with advantage ε, then there exists an efficient
quantum adversary A′ with essentially the same runtime asA that distinguish PRF from
a truly random function R′ : Y → Z with advantage at least ε.

Before delving into the proof of the main theorem, we state the following useful lemma.
Loosely speaking, we show that if a small-domain PRF is post-quantum secure6(where
the adversary is allowed to issue only classical queries), then such a PRF is also quantum
secure. Intuitively, this holds because an adversary can query classically the full domain
of the PRF in polynomial time. We stress that the counterexample of [27] does not apply
in these settings, since we consider only PRFs with small (poly-sized) domain.

6 Any small domain PRF built from symmetric primitives is post-quantum secure as long as
underling symmetric assumptions are post-quantum secure.

12



Lemma 2. Let PRF be a small-domain and post-quantum secure PRF as defined in
Definition 3, then PRF is also quantum-secure as defined in Definition 5. Specifically,
if there exists an efficient quantum adversary A which can make quantum queries
to distinguish PRF : K × Y → Z from truly random function R : Y → Z with
advantage Îľ,where |Y| 6 poly(Îť), then there exists an efficient quantum adversary
A′ (with essentially the same runtime as A) that can only make classical queries to
distinguish from PRF andR with advantage Îľ.

Proof. Assume that there exists an efficient (i.e., running in polynom";"""date"",""2020-12-01T21:57:00Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2020-12-01T21:57:00Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.19 (TeX Live 2018) kpathsea version 6.3.0""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2020-12-01T21:57:00Z""
""created"",""2020-12-01T21:57:00Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-12-01T21:57:00Z""
""resourceName"",""1508.pdf""
""Author"",""""
""producer"",""pdfTeX-1.40.19""
""pdf:docinfo:producer"",""pdfTeX-1.40.19""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""1"",""6"",""25"",""5"",""14"",""12"",""4"",""9"",""14"",""10"",""10"",""31"",""27"",""48"",""55"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2020-12-01T21:57:00Z""
""Last-Modified"",""2020-12-01T21:57:00Z""
""dcterms:modified"",""2020-12-01T21:57:00Z""
""title"",""""
""Last-Save-Date"",""2020-12-01T21:57:00Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2020-12-01T21:57:00Z""
""meta:save-date"",""2020-12-01T21:57:00Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.19 (TeX Live 2018) kpathsea version 6.3.0""
""Content-Length"",""396026""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""18""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""2172"",""2773"",""2037"",""2019"",""2473"",""2363"",""1851"",""2110"",""2110"",""2058"",""1700"",""2007"",""2106"",""1363"",""1626"",""2047"",""3290"",""3026""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-12-01T21:57:00Z""
";https://scholar.google.ch/scholar?start=890&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098769-114;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;[HTML][HTML] Smart Contracts, Insurtechs and the Future of Insurance;J Scherrer, A Salahshor ;2020 lup.lub.lu.se;;"… Insurers just have to overcome two things: (1) codifying contract terms, and (2) finding oracles

that provide relevant event information. The business community would profit from a greater focus

on this concept, rather than the hype-driven chase after blockchain …";Autres articles;;[HTML] lu.se;https://lup.lub.lu.se/student-papers/record/9001985;;;https://scholar.google.ch/scholar?start=660&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098848-293;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Bridges between islands: Cross-chain technology for distributed ledger technology;N Kannengießer, M Pfister, M Greulich… ; Proceedings of the …, 2020  128.171.57.22;;"… Rootstock sets up a two-way peg with the Bitcoin block- chain although the Bitcoin blockchain

is not … level of automa- tion in the previous SCM example [6]. In contrast to cross-chain oracles,

the execution … For example, sharding can be assigned to the cross-chain oracle use case …";Cité 14 fois;Les 9 versions;[PDF] 128.171.57.22;http://128.171.57.22/bitstream/10125/64394/1/0524.pdf;"
 

Bridges Between Islands:  

Cross-Chain Technology for Distributed Ledger Technology 
 

Niclas Kannengießer 

Karlsruhe Institute  

of Technology 

niclas.kannengiesser 

@kit.edu 

Michelle Pfister 

Karlsruhe Institute of 

Technology 

michelle.pfister 

@gmx.com 

Malte Greulich 

Karlsruhe Institute  

of Technology 

malte.greulich 

@kit.edu 

Sebastian Lins 

Karlsruhe Institute  

of Technology 

lins@kit.edu 

 

Ali Sunyaev 

Karlsruhe Institute of 

Technology 

sunyaev@kit.edu 

 

 

 

Abstract 

 

Since the emergence of blockchain in 2008, we see a 

kaleidoscopic variety of applications built on distrib-

uted ledger technology (DLT), including applications 

for financial services, healthcare, or the Internet of 

Things. Each application comes with specific require-

ments for DLT characteristics (e.g., high throughput, 

scalability). However, trade-offs between DLT charac-

teristics restrict the development of a DLT design (e.g., 

Ethereum, IOTA) that fits all use cases’ requirements. 

Separated DLT designs emerged, each specialized to 

suite dedicated application requirements. To enable the 

development of more powerful applications on DLT, 

such DLT islands must be bridged. However, knowledge 

of cross-chain technology (CCT) is scattered across sci-

entific and practical sources. Therefore, we examine 

this diverse body of knowledge and provide comprehen-

sive insights into CCT by synthesizing its underlying 

characteristics, evolving patterns, and use cases. Our 

findings resolve contradictions in the literature and pro-

vide avenues for future research in an emerging scien-

tific field. 

 

 

1. Introduction 
 

Distributed Ledger Technology (DLT) is one of the 

major technological innovations within the last decade 

[4, 37]. DLT enables the operation of a highly available 

and almost immutable shared, collaborative infrastruc-

ture for individuals and organizations [8]. Data is orga-

nized in an append-only ledger that is replicated across 

multiple storage devices, so-called nodes, that are syn-

chronized by using a consensus mechanism. However, 

several challenges withhold the development of more 

powerful applications built on DLT. Developers face in-

herent trade-offs between DLT characteristics (e.g., 

availability vs. consistency [16, 26]), which is why the 

fulfillment of one DLT characteristic may impede oth-

ers [26]. Consequently, while one DLT design can be 

well suited for a particular use case, it may not fit other 

use cases, ultimately inhibiting the development of a 

one-size-fits-all DLT design, and fueling the emergence 

of diverse DLT designs (e.g., Ethereum, IOTA, or Te-

zos) [16], each operating separately. To take advantage 

of individual DLT designs and to design more powerful 

applications, DLT designs must interoperate. Cross-

Chain Technology (CCT), therefore, gained further at-

tention among researchers and practitioners alike. For 

example, CCT could help extend the functionality of ap-

plications based on a private DLT design (e.g., Hy-

perledger Fabric) by allowing payments through a pub-

lic DLT design (e.g., Ethereum). Thus, CCT is crucial 

to overcome the limitations of DLT designs and to pre-

vent the emergence of separate ‘islands’ of distributed 

ledgers [14]. CCT enables different DLT designs to in-

teroperate, thereby ‘bridging islands’ of distributed 

ledgers across industries and use contexts.  

A growing number of CCT artifacts seek to enable 

cross-chain interoperability (e.g., Interledger or Polka-

dot). However, CCT artifacts pose different technical re-

quirements (e.g., concerning locking or verification 

mechanisms) and non-technical requirements (e.g., con-

cerning performance and security) on distributed ledg-

ers. Consequently, developers must carefully compare 

CCT artifacts in order to choose an artifact that best suits 

their use case. 

However, much of the current knowledge into CCT 

is not readily accessible to researchers and practitioners 

that would allow for such a comparison. We see three 

main reasons for this. First, existing comparisons of 

CCT artifacts (e.g., [18]) do not use a common set of 

characteristics, which limits the usefulness of such com-

parisons. Second, the literature into CCT proposes sev-

eral patterns that describe the general functionality of 

CCT artifacts (e.g., sidechains [1]). Such patterns also 

inform the understanding of capabilities and limitations 

of such artifacts. Third, most of the current knowledge 

on CCT comes from blog posts (e.g., [4, 25]) or white-

papers (e.g., [34]). This scattered knowledge into CCT 

lacks transparency and rigor of (scientific) methods used 

to produce these insights. Likewise, the limited scien-

Proceedings of the 53rd Hawaii International Conference on System Sciences | 2020

Page 5298
URI: https://hdl.handle.net/10125/64394
978-0-9981331-3-3
(CC BY-NC-ND 4.0)



 

tific research on CCT mainly refers to surveys for moti-

vational purposes and seldom scrutinizes the claims 

made in blog posts (e.g., [4]) or whitepapers (e.g., [22]). 

Thus, there is a discrepancy between research and prac-

tice, which also hinders the scientific debate on DLT it-

self owing to the essential role of CCT for the diffusion 

of DLT at scale [14, 21].  

In order to compare CCT artifacts more comprehen-

sively concerning specific use case requirements, and to 

provide much-needed insights into CCT, a synthesis of 

characteristics and patterns of CCT artifacts is required. 

We thus seek to answer the following research question:   

What are the characteristics and patterns of CCT? 
 

By conducting a thorough review of the extant liter-

ature on CCT, we identified existing CCT artifacts and 

synthesized underlying characteristics. Then, we aggre-

gated common functionalities across the identified arti-

facts into general patterns that enable easy and compre-

hensive comparison between artifacts. Finally, we com-

pared these patterns with regard to particular use cases, 

which we identified during the literature review. 

This work contributes to research and practice by de-

fining common characteristics of CCT artifacts that al-

low researchers and developers to compare artifacts 

based on use case requirements. We provide a holistic 

comparison between patterns and their functioning, 

which offers generalized knowledge on CCT and which 

helps to overcome the scattered insights and prevailing 

disconnect between research and practice. 

 

2. Theoretical background 
 

2.1. Distributed ledger technology 
 

DLT enables the operation of a distributed ledger, 

which is a special type of an append-only, distributed 

database that is particularly suited to the peculiarities of 

an untrustworthy environment [37]. DLT allows for the 

presence of Byzantine failures [20], which include arbi-

trarily crashed or unreachable nodes, network delays, or 

malicious behavior of nodes [20]. In DLT, new data is 

added to the ledger using transactions that are commit-

ted to each node’s local replication. Owing to the use of 

cryptographic mechanisms (e.g., hashing), data that has 

been recorded in the distributed ledger typically cannot 

be removed or altered. 

To reach consistency between the replications stored 

on nodes of a distributed ledger, each DLT design em-

ploys a consensus mechanism. A consensus mechanism 

is an algorithm used to negotiate the current valid state 

of the ledger between different nodes of the distributed 

ledger. Due to inherent trade-offs that pertain to consen-

sus finding in distributed systems, consensus mecha-

nisms either reach total finality or probabilistic finality 

[11, 28]. Total finality is reached if all nodes agree on 

the same replication of the ledger. In probabilistic final-

ity, it is only assumed that data is finalized to a certain 

probability, which depends on the number of successors 

after a transaction has been recorded. For example, such 

successors are blocks, which serve as a superordinate 

data structure, which includes transactions. The mini-

mum number of successors that are required to assume 

stored data as finalized to a certain probability deter-

mines the so-called confirmation latency of a DLT de-

sign (e.g., 1 h in Bitcoin to append 6 blocks). 

In general, there are two types of DLT designs that 

differ in their hierarchical structure: public and permis-

sioned DLT designs. In public DLT designs, anyone can 

join the distributed ledger with an own node, which has 

equal permissions concerning reading from and writing 

to the distributed ledger. In contrast, permissioned DLT 

designs exclude nodes from operations (e.g., transaction 

validation, joining the distributed ledger) as they em-

ploy a permission model. Such permission models 

strongly influence the applicability of consensus mech-

anisms due to trade-offs between characteristics that 

pertain to distributed systems [11, 28]. For example, 

public DLT designs predominantly employ consensus 

mechanisms that only reach probabilistic finality (e.g., 

Nakamoto consensus). In contrast, consensus mecha-

nisms of most permissioned DLT designs reach total fi-

nality and, thus, do not fork or only fork for a short pe-

riod but can only include a limited number of nodes into 

consensus finding. 

 

2.2. Smart contracts 
 

Several DLT designs enable the deployment and the 

execution of customized software programs, so-called 

smart contracts. Smart contracts allow for the expres-

sion of formalized conditions in program code for the 

issuance of transactions [5]. Initially, smart contacts 

were limited to (un-)locking of assets stored on a dis-

tributed ledger (e.g., using hash locks, time locks, and 

multi-signatures) [13]. To increase developers’ flexibil-

ity for implementing more expressive smart contracts, 

an environment for the execution of Turing-complete 

smart contracts was developed [5]. Today, smart con-

tracts can store assets and issue transactions once the 

smart contract’s formalized conditions are met. Such 

conditions can relate to data stored on the same distrib-

uted ledger (on-chain) as well as data from external 

sources (off-chain), so-called oracles [36]. Smart con-

tracts are also crucial to enable atomic communication 

between distributed ledgers (e.g., asset transfers) and, 

thus, cross-chain interoperability. 

 

 

 

Page 5299



 

2.3. Cross-chain technology 
 

Interoperability of a DLT design refers to its ability 

to retrieve data from or exchange data with external sys-

tems. CCT helps to achieve interoperability by enabling 

data exchange between DLT designs or with external 

systems. Such data exchanges can increase a DLT de-

signs’ flexibility (e.g., [14, 32]), overcome performance 

issues (e.g., [24, 30]), and increase security of DLT de-

signs (e.g., [1, 29]). For example, poor scalability and 

low throughput can be tackled using sharding [24]. In 

sharding, a distributed ledger is split into smaller 

chunks, which can be managed independently and ena-

bles parallel processing of transactions to increase 

throughput and scalability [24]. 

The development of CCT artifacts is mainly driven 

by organizations that publish the functioning of their 

own-developed artifact in whitepapers (e.g., Interledger, 

Wanchain). Several articles present a classification of 

such artifacts into patterns (e.g., [4, 22]), which are ab-

stract descriptions of the functioning of assigned arti-

facts. However, the proposed patterns lack empirical ev-

idence, which makes the results hard to reproduce. 

 

3. Methodology  
 

We applied a three-step research approach. First, we 

conducted a literature review to extract CCT artifacts, 

their characteristics, existing patterns, and use cases. 

Our descriptive literature review was guided by recom-

mendations for literature reviews in the information sys-

tems field [3, 17, 33]. Second, we derived patterns from 

the identified artifacts. Third, we compared the derived 

patterns and explain dependencies between characteris-

tics inherent to artifacts and patterns. 

 

3.1. Literature search 
 

To identify publications addressing CCT, we 

searched scientific databases that we deemed repre-

sentative as they cover the top computer science and in-

formation systems conferences and journals: EBSCO-

host, IEEE Xplore, AIS eLibrary, ScienceDirect, ACM 

Digital Library, ProQuest, and Springer. To cover a 

broad set of publications, we searched each database 

with the following string in title, abstracts, and key-

words: (‘Distributed Ledger Technolog*’ OR ‘DLT*’ 

OR ‘Blockchain*’) AND (‘Interoperab*’ OR ‘Cross-

chain*’ OR ‘Sidechain*’ OR ‘Multi-chain*’ OR ‘Inter-

connect*’ OR ‘Connect*’). As whitepapers in this par-

ticular context are a crucial source of knowledge on 

CCT, we additionally applied the search string to the 

search engine DuckDuckGo. 

We identified 611 articles in this initial search as of 

May 2019. To identify and filter articles, we first 

checked the relevance of each article by analyzing title, 

abstract, and keywords. If any indication for relevance 

appeared, the article was marked for further analysis. 

We excluded articles that were non-English articles (5), 

grey literature (i.e., books, news articles; 2), duplicate 

articles (31), and off-topic (504). This first relevancy as-

sessment resulted in a sample of 69 articles deemed to 

be potentially relevant. Afterward, a fine-grained rele-

vance validation was made by reading the articles in de-

tail, resulting in a sample of 38 relevant articles on 

which we applied a forward and backward search. For 

each of these articles, we applied the exclusion criteria, 

which resulted in a final set of 81 relevant articles. 

 

3.2. Data analysis 

 

We analyzed the relevant articles by applying the 

coding rules proposed by Lacity et al. [19]. First, we 

carefully read and analyzed the relevant articles inde-

pendently to identify and code artifacts, corresponding 

characteristics, use cases, and patterns in the context of 

CCT. For each extracted code, we recorded a name, a 

description, and the original source [19] and came up 

with a preliminary set of 57 artifacts, 139 characteris-

tics, 19 patterns, and 15 use cases for CCT. Since differ-

ent people name things differently, it is crucial to avoid 

semantic ambiguities for the validity of qualitative anal-

ysis (e.g., different terminology for the same character-

istics) [19]. Therefore, we aggregated the codes into 

master codes (e.g., aggregating throughput and transac-

tion volume into the master code throughput). If an iden-

tified code fitted into an existing master code, we as-

signed it accordingly; otherwise, we created a new mas-

ter code. We repeated the aggregation of master codes 

two times and discussed and validated the generated 

master codes with two additional researchers, who are 

knowledgeable in the domain of DLT. The goals were 

to agree on a set of master codes for artifacts, character-

istics, patterns, and use cases and to reach theoretical 

saturation, in order to stabilize the list of master codes. 

We applied the same coding approach for artifacts, char-

acteristics, patterns, and use cases. We came up with a 

final set of 57 distinct artifacts, 37 distinct characteris-

tics, 3 distinct patterns, 1 hybrid pattern, and 4 use cases 

for CCT. We assume to have reached theoretical satura-

tion because no new master codes were identified for the 

last 20 articles. Please find details on the literature 

search and coding in the supplementary online material 

(https://bit.ly/2lUWprE). 

Second, we used an inductive grouping approach to 

classify master codes for characteristics into superordi-

nate properties. We generated the properties under con-

sideration of the characteristics’ predominant classifica-

tion in extant literature. For example, we assigned the 

master code throughput to the property performance. 

Page 5300

https://bit.ly/2lUWprE


 

Third, we evaluated the coded patterns by considering 

the identified artifacts. We compared the artifacts with 

regards to their values for the particular characteristics 

and assigned the artifacts accordingly to the coded pat-

terns. Artifacts that use a similar approach to achieve 

cross-chain interoperability were assigned to the same 

pattern (e.g., Dogeethereum and InfiniteChain were as-

signed to the sidechain pattern). 

 

4. Results 
 

4.1. Properties and characteristics of CCT 
 

For parsimoniousness, we briefly introduce the 

properties of CCT artifacts in Table 1 and refer to Table 

2 for a description of the associated characteristics. 

Please see a full list of the coding and the identified ar-

tifacts (e.g., BTCRelay, Polkadot, and Wanchain) in the 

online material (https://bit.ly/2lUWprE). 

 

4.2. Patterns of cross-chain technology 
 

Our analysis of the artifacts and their characteristics 

(cf. Table 1) revealed three distinct patterns: manual as-

set exchange (MAE), notary schemes, and relays. Addi-

tionally, we identified a fourth, hybrid pattern, which in-

cludes the three distinct patterns. By and large, the pat-

terns differ in terms of characteristics that are related to 

the networking property (e.g., communication). The net-

working property strongly influences other properties. 

For example, the procedure characteristic (e.g., atomic 

cross-chain swap [13], three phase commit [15]) influ-

ences transaction speed as it determines the number of 

verifications and requests between the distributed ledg-

ers. We describe these implications in more detail in 

Section 4.4. 

 

4.2.1. Manual Asset Exchange. A MAE is the simplest 

CCT pattern. MAEs follow the typical lifecycle of fi-

nancial transactions: settlement, order matching, and 

clearance. In the first stage, A settles a new asset ex-

change order as A locks assets on the corresponding dis-

tributed ledgers using a certain secret (e.g., pre-image of 

a hash value, a private key for an account). In the second 

stage, A must find a corresponding exchange partner B 

to eventually agree upon the asset exchange rate for the 

respective orders (e.g., 1 Bitcoin in reward for 32.5 

Ether). In MAEs, such order matching is conducted off-

chain, for example, by a third party or through personal 

interaction. After A and B agreed on the exchange, B 

locks assets on the corresponding distributed ledger. In 

the third stage, the order clearance, the actual assets ex-

change takes place. Therefore, A and B exchange their 

secrets to unlock the locked assets respectively. MAEs 

have certain drawbacks and can only be applied for asset 

exchanges (as opposed to the other patterns). Typically, 

MAEs do not employ automated order matching and do 

not require an artifact because the asset exchange can 

solely base on a personal agreement of parties. How-

ever, MAEs can be vulnerable to fraud. If A receives B's 

secret first and there is no mechanism to unlock A's se-

cret in return, A could use B's secret to unlock B's assets 

without transferring its own assets to B. A would thus 

not complete the exchange correctly. In order to prevent 

exchange partners from carrying out fraudulent activi-

ties that could lead to financial losses, atomicity is cru-

cial for the exchange of assets [13]. The most prominent 

protocol for MAEs to achieve atomicity is the atomic 

cross-chain swap protocol [13], which is based on 

hashed time-locked contracts [13, 25]. A hashed time-

lock contract locks assets using a hash value sh during a 

period t. Assets are unlocked when a pre-image s is pro-

vided within a period t with a hash value equal to sh. 

 

4.2.2. Notary Schemes. In notary schemes, a trusted 

third party establishes the connection between distrib-

uted ledgers [22]. The notary scheme provides an infra-

structure (e.g., multi-miner) and related services (e.g., 

order matching) to facilitate asset transfers or similar ac-

tions (e.g., execution of a smart contract). Before an ac-

tion on a distributed ledger is executed, a notary must 

first agree that a certain event (e.g., commitment of a 

transaction) on another distributed ledger took place. 

For instance, consider the case of a cryptocurrency ex-

change. Here, a notary must first verify that a transaction 

was completed successfully on distributed ledger A, be-

fore it issues the corresponding transaction to distributed 

ledger B. Thus, the data exchange between distributed 

ledgers is completely managed by notaries. Notary 

schemes follow a centralized architecture to achieve 

cross-chain interoperability [14, 22]. 

 

Table 1. Properties of CCT artifacts 

Property Description 

Administration Characteristics concerned with the management and 
assignment of responsibilities for the operation and 

maintenance of an artifact.  

Flexibility Characteristics concerned with the developers’ free-
dom of customizability of the artifact, the connected 

DLT designs, and applications on these distributed 

ledgers or artifacts. 

Performance Characteristics referring to the effectiveness of a data 
exchange measured by accuracy, completeness, cost, 

and speed. 

Security Characteristics concerned with the preservation of 
confidentiality, integrity, and availability of data 

stored on a distributed ledger. 

Networking Characteristics concerned with the structure and pro-

cesses that enable the exchange of data between dis-
tributed ledgers. 

 

 

Page 5301

https://bit.ly/2lUWprE


 

A notary scheme can correspond to either a single notary 

(centralized notary scheme or centralized exchange), or 

a consortium of notaries (decentralized notary scheme 

or decentralized exchange) [31]. In centralized notary 

schemes, a single notary may set up and operate a node 

per connected distributed ledger. For example, when a 

Table 2. Characteristics of cross-chain technology artifacts 

Prop-

erty 
Characteristic Description 

A
d

m
in

-

is
tr

at
io

n
 Accountability The presence of a party responsible and liable for the correct operation of the artifact. 

Auditability The degree to which the artifact behavior can be analyzed (e.g., examination and traceability of stored transactions). 

Compliance The ability of an artifact to adhere to laws and regulations. 

Governance The process and assignment of responsibilities for deciding to change the artifact and connected distributed ledgers. 

F
le

x
ib

il
it

y
 

Development 

Support 

The degree to which the community or organization that maintains an artifact provides developers with documenta-

tions, guidelines, and additional features to facilitate the setup and maintenance of the connection to the artifact. 

Feature Scope The artifact’s feature richness and appropriateness for use cases. 

Maintainability The ease with which developers can update the inter-connected distributed ledgers, the applied artifact, or the asso-
ciated applications on DLT. 

Openness The ease with which an artifact enables developers to independently register or unregister distributed ledgers in the 

multi-chain network. 

Supported DLT 

Designs 

The variety of DLT designs the artifact can support. 

N
et

w
o

rk
in

g
 

Communication  
Approach 

The direction of the data flow, the direct or indirect communication, the used data structures (e.g., tokens), and the 
necessary events (e.g., successful transaction commit). 

Locking  

Mechanism 

A mechanism that securely locks assets on one ledger and unlocks transactions on another (e.g., hash locking, time 

locking, hash-time lock-contracts). 

Procedure The procedure determined by the artifact to reliably fulfil its feature scope. 

Routing The management of forwarding data sent over the network via particular entities. 

Topology The structural organization of the inter-connection of distributed ledgers. 

Verification 

Mechanism 

The applied mechanism to verify that transactions on one distributed ledger have been finalized. 

P
er

fo
rm

an
ce

 

Cost The total sum of (monetary) cost to execute a transaction, including, for example, transaction fees and collaterals. 

Resource  
Consumption 

The required amount of computational resources (e.g., bandwidth or storage space) to operate an artifact. 

Scalability The ability of the distributed ledger to appropriately adapt to increasing and decreasing workload. 

Throughput The number of transactions that can be included in the ledger within a given period. 

Transaction 

Speed 

The period between a cross-chain transaction is issued and its (probabilistic) finalization at the distributed ledger(s). 

S
ec

u
ri

ty
 

Atomicity The ability of an artifact to guarantee that each (cross-chain) transaction either succeeds completely or fails com-

pletely. 

Availability The probability to which an artifact is in a functioning state at a random point in time. 

Censorship- 
Resistance 

The probability of transactions being intentionally delayed or even dropped. 

Confidentiality The degree to which unauthorized access to stored data is prevented. 

Consistency The homogeneity of data stored by all nodes participating in a DLT design without contradictions. 

Durability The degree of durability that ensures transactions are saved permanently and do not accidentally disappear or get 

erased, even during a database crash. 

Finality The type of finality (e.g., probabilistic or total) and time that is needed to undergo a threshold to consider a transac-
tion finalized. 

Fault Tolerance The degree to which the artifact is able to cope with Byzantine failures (e.g., node failure, network delays). 

Isolation The degree to which the operations on a distributed ledger can affect or are affected by operations in concurrent 

transactions. 

Incentive  

Mechanism 

The applied reward mechanism that motivates maintainers of an artifact to act honestly and to share computational 

resources (e.g., mining or merge mining). 

Integrity The degree to which the artifact protects exchanged data from being modified without consent of the data owner. 

Ledger  
Independence 

The degree to which at least two distributed ledgers, which are connected via an artifact, remain autonomous. 

Liveness The ability of concurrent systems to make progress despite concurrently executing processes. 

Non-Repudia-

tion 

The ease of proving participation in transactions. 

Reliability The period of time during which a distributed ledger is correctly functioning. 

Safety The degree to which the artifact is able to avert or not cause (economic) loss (e.g., loss of assets). 

Transparency The degree to which identities and their activities are visible or traceable to others. 
 

Page 5302



 

notary decides to enable assets transfers from Bitcoin to 

Ethereum, the notary sets up a Bitcoin and Ethereum 

node to manage the receive and the issuance of transac-

tions on both distributed ledgers. The notary alone con-

firms if an event occurred (e.g., transaction reception) 

and triggers the corresponding event (e.g., transaction 

issuance). To democratize the confirmation of events 

among a consortium of notaries, to increase transpar-

ency, and to increase the availability of the exchange 

service decentralized notary schemes have been intro-

duced [31]. To issue a corresponding transaction for an 

event in decentralized notary schemes, trusted third par-

ties often share, for instance, a distributed private key 

[22, 23] or employ a multi-signature wallet [35]. Only if 

a certain number of notaries confirms the event (e.g., 

locking assets on distributed ledger A), a corresponding 

event is executed (e.g., unlocking assets on distributed 

ledger B). 

 

4.2.3. Sidechains (relays). In general, sidechains are 

subordinate distributed ledgers that are connected to a 

central distributed ledger (main chain), such as Bitcoin 

or Ethereum. Sidechains are technically independent of 

the main chain and, thus, can have their own consensus 

mechanism, tokens, and miners. Initially, sidechains 

were developed to enhance the extensibility of existing 

distributed ledgers through asset transfers. Sidechains 

can read and verify data from the main chain [1], which 

is important, for example, to transfer assets from the 

main chain to the sidechain (one-way peg [1]). In such 

asset transfers, several assets (e.g., coins) are locked on 

the main chain. The locking of assets is confirmed by 

the verification mechanism of the destination sidechain, 

which eventually unlocks (or generates) a correspond-

ing amount of native tokens [1, 5]. 

Several articles refer sidechains almost exclusively 

to the use in combination with the Bitcoin blockchain 

[6, 22]. For example, BTC Relay extends the Bitcoin 

blockchain with support for smart contracts [10]. The 

original sidechains only allow for asset transfers or for-

warding information in one direction: from the main 

chain to the sidechain (cf. one-way peg [2]). Meanwhile, 

the concept of sidechains has been enhanced and imple-

mented in artifacts that allow for bidirectional commu-

nication of distributed ledgers. This subordinate pattern 

of sidechains in which distributed ledgers communicate 

bidirectionally is called a two-way peg [1]. To be able 

to transfer the assets back to the main chain or to another 

sidechain, the main chain must also be able to verify 

data on the relay, which decreases the number of sup-

ported DLT designs. 

 

4.2.4. Hybrid solutions. There are also hybrid solu-

tions, which combine certain aspects of the previously 

explained patterns. Hybrid solutions, for example, help 

to set up a two-way pegged sidechain although one of 

the DLT designs does not support an appropriate verifi-

cation mechanism (e.g., Simple Payment Verification 

(SPV) [12]). In such situations, a notary scheme re-

places the ability of the particular relay to recognize and 

validate included transactions and let trusted notaries 

provide this information [1]. For instance, such a feder-

ated pegged relay is implemented in Rootstock [29]. 

Rootstock sets up a two-way peg with the Bitcoin block-

chain although the Bitcoin blockchain is not able to per-

form light client proofs on other distributed ledgers [29]. 

Furthermore, Rootstock implements a mechanism to 

empower the notaries to sign valid transactions as the 

overall hashing power in the Rootstock chain is below 

5 % of the Bitcoin hashing power to prevent double-

spending. 

 

4.3. Use cases for cross-chain technology 
 

The literature review revealed four use cases: asset 

transfers, cross-chain oracles, and cross-chain smart 

contracts. In asset transfers, assets are moved from one 

distributed ledger to another. As a special form of asset 

transfer, we identified asset exchanges, which allow us-

ers to spend assets of one distributed ledger in return of 

assets from another distributed ledger (e.g., trading of 

cryptocurrencies or other assets). Asset exchanges pose 

a requirement for atomicity to prevent financial loss. 

Rather than moving assets, cross-chain oracles, in 

contrast, provide information from one distributed 

ledger to another [5]. Thus, cross-chain oracles can be 

employed to verify that certain events (e.g., a transac-

tion) occurred on another distributed ledger (e.g., SPV 

[12]) enabling, for example, the migration of data from 

one distributed ledger to another or the interaction of 

distributed ledger in supply chain management (SCM). 

In SCM, one distributed ledger for payments could re-

quest the current state of a shipment on another distrib-

uted ledger for tracking to execute conditional pay-

ments. Cross-chain oracles are of particular importance 

for asset encumbrance (cf. [4, 18]), which is the ability 

of a ledger to lock assets and unlocking the locked assets 

if a certain predefined event on another distributed 

ledger occurs, which is of particular importance for the 

migration of a ledger from its DLT design to another. 

Cross-chain smart contracts describe the ability to 

trigger the execution of a smart contract on another dis-

tributed ledger, which can increase the level of automa-

tion in the previous SCM example [6]. In contrast to 

cross-chain oracles, the execution of cross-chain smart 

contracts requires the iss";"""date"",""2020-01-01T01:31:31Z""
""pdf:PDFVersion"",""1.7""
""xmp:CreatorTool"",""MicrosoftÂŽ Word fĂźr Office 365""
""pdf:docinfo:title"",""Bridges Between Islands:""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""pdf:docinfo:custom:source-Producer"",""MicrosoftÂŽ Word fĂźr Office 365""
""subject"",""Cross-Chain Technology"",""Cross-Chain Technology""
""language"",""en""
""dc:format"",""application/pdf; version=1.7""
""pdf:docinfo:creator_tool"",""Hummus-Recipe (https://github.com/chunyenHuang/hummusRecipe)""
""access_permission:fill_in_form"",""true""
""source-Producer"",""MicrosoftÂŽ Word fĂźr Office 365""
""pdf:encrypted"",""false""
""dc:title"",""Bridges Between Islands:""
""xmp:CreateDate"",""2019-09-20T09:02:33Z""
""modified"",""2020-01-01T01:31:31Z""
""pdf:docinfo:custom:source-ModDate"",""D:20190920090233+02'00'""
""pdf:hasMarkedContent"",""true""
""xmp:ModifyDate"",""2019-09-20T09:02:33Z""
""pdf:docinfo:creator"",""niclas.kannengiesser@kit.edu""
""meta:author"",""niclas.kannengiesser@kit.edu""
""meta:creation-date"",""2019-09-20T07:02:33Z""
""created"",""2019-09-20T07:02:33Z""
""source-Creator"",""MicrosoftÂŽ Word fĂźr Office 365""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-09-20T07:02:33Z""
""resourceName"",""0524.pdf""
""pdf:docinfo:custom:source-Creator"",""MicrosoftÂŽ Word fĂźr Office 365""
""Author"",""niclas.kannengiesser@kit.edu""
""producer"",""PDFHummus (https://github.com/galkahana/HummusJS)""
""pdf:docinfo:producer"",""PDFHummus (https://github.com/galkahana/HummusJS)""
""source-ModDate"",""D:20190920090233+02'00'""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""Keywords"",""Cross-Chain Technology"",""Cross-Chain Technology""
""access_permission:modify_annotations"",""true""
""dc:creator"",""niclas.kannengiesser@kit.edu""
""dcterms:created"",""2019-09-20T07:02:33Z""
""Last-Modified"",""2020-01-01T01:31:31Z""
""dcterms:modified"",""2020-01-01T01:31:31Z""
""title"",""Bridges Between Islands:""
""xmpMM:DocumentID"",""uuid:13B3DF8C-0BBE-4800-8E2B-C4A4DE5B8615""
""Last-Save-Date"",""2020-01-01T01:31:31Z""
""pdf:docinfo:keywords"",""Cross-Chain Technology""
""pdf:docinfo:modified"",""2020-01-01T01:31:31Z""
""meta:save-date"",""2020-01-01T01:31:31Z""
""Content-Length"",""395229""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""niclas.kannengiesser@kit.edu""
""dc:language"",""de-DE""
""pdf:producer"",""MicrosoftÂŽ Word fĂźr Office 365""
""dc:subject"",""Cross-Chain Technology"",""Cross-Chain Technology""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""10""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""4745"",""5344"",""5447"",""5332"",""5013"",""5675"",""4441"",""5840"",""5344"",""5669""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""meta:keyword"",""Cross-Chain Technology"",""Cross-Chain Technology""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-09-20T07:02:33Z""
";https://scholar.google.ch/scholar?start=840&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098848-294;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;On the need for large quantum depth;NH Chia, KM Chung, CY Lai ; Proceedings of the 52nd Annual ACM …, 2020  dl.acm.org;;"… the separation, we generalize techniques in cryptography (from both quantum and classical crypto

literature) to show … it to the shuffling oracle (which is more complicated than random oracle) and

show indistinguishability to a convex combi- nation of shuffling oracles with a …";Cité 4 fois;Les 5 versions;[PDF] arxiv.org;https://arxiv.org/pdf/1909.10303;"
On the Need for Large Quantum Depth

Nai-Hui Chia1, Kai-Min Chung2, and Ching-Yi Lai3

1Department of Computer Science, University of Texas at Austin, Texas 78731, USA
2Institute of Information Science, Academia Sinica, Taipei 11529, Taiwan

3Institute of Communications Engineering, National Chiao Tung University, Hsinchu
30010, Taiwan

Abstract

Near-term quantum computers are likely to have small depths due to short coherence time
and noisy gates. A natural approach to leverage these quantum computers is interleaving them
with classical computers. Understanding the capabilities and limits of this hybrid approach is an
essential topic in quantum computation. Most notably, the quantum Fourier transform can be
implemented by a hybrid of logarithmic-depth quantum circuits and a classical polynomial-time
algorithm. Therefore, it seems possible that quantum polylogarithmic depth is as powerful as
quantum polynomial depth in the presence of classical computation.

Indeed, Jozsa conjectured that “Any quantum polynomial-time algorithm can be implemented
with only O(log n) quantum depth interspersed with polynomial-time classical computations.”
This can be formalized as asserting the equivalence of BQP and “BQNCBPP”. On the other
hand, Aaronson conjectured that “there exists an oracle separation between BQP and BPPBQNC.”
BQNCBPP and BPPBQNC are two natural and seeming incomparable ways of hybrid classical-
quantum computation.

In this work, we manage to prove Aaronson’s conjecture and in the meantime disproves
Jozsa’s conjecture relative to an oracle. In fact, we prove a stronger statement that for any
depth parameter d, there exists an oracle that separates quantum depth d and 2d + 1 in the
presence of classical computation. Thus, our results show that relative to oracles, doubling the
quantum circuit depth indeed gives the hybrid model more power, and this cannot be traded
by classical computation.

1 Introduction

Circuit depth may become an essential consideration when designing algorithms on near-term
quantum computers. Quantum computers with more than 50 qubits have been realized recently
by Google [Kel18] and IBM [IBM17]; both the quantity and quality of the qubits are continually
improving. Furthermore, Google and NASA recently showed that their quantum computer outper-
forms the best supercomputers on the task of random circuit sampling [AAB+19]. However, due
to noisy gates and limited coherence time, these quantum computers are only able to operate for a
short period. Hence the effective circuit depths of these quantum computers are limited,∗ and this
seems to be an essential bottleneck for quantum technologies.

Studies from a theoretical perspective indicate that small-depth quantum computers can demon-
strate so-called “Quantum Supremacy” [AC17, TD04], which means solving some computational
problems that are intractable for classical computers. Terhal and DiVincenzo first showed that

∗Indeed, the experiments of Google and NASA consider circuits with depth at most 20.

1

ar
X

iv
:1

90
9.

10
30

3v
2 

 [
qu

an
t-

ph
] 

 1
2 

Se
p 

20
20



constant-depth quantum circuits can sample certain distributions that are intractable for classi-
cal computers under some plausible complexity conjecture [TD04], and more recent works showed
that this can be based on the conjecture that the polynomial hierarchy (PH) is infinite [AC17].
Aaronson and Chen showed that under a natural average-case hardness assumption, there exists
a statistical test such that no polynomial-time classical algorithm can pass it, but a small-depth
quantum circuit can [AC17].

On the other hand, it is worth noting that the capability of constant-depth quantum computers
is limited. Specifically, consider the standard setting where the composing gate set only includes
one- and two-qubit gates. It is obvious that a constant-depth quantum circuit cannot solve any
classically intractable decision problem or even some classically easy problems, e.g., computing a
parity function. This is because that each output qubit depends on only O(1) input qubits. Al-
though involving unbounded fan-out gates allows a quantum circuit to conduct many operations in
small depth, such as parity, mod[q], threshold[t], arithmetic operations, phase estimations, and the
quantum Fourier transform [HS05], it seems that unbounded fan-out gates are hard to implement
in practice and thus is rarely considered for near-term quantum device.†

A natural idea to exploit the power of small-depth quantum computers is interleaving them
with classical computers. Many of the known quantum algorithms require only small depths in the
quantum part. Notably, Cleve and Watrous showed that the quantum Fourier transform can be par-
allelized to have only logarithmic quantum depth [CW00], which implies that quantum algorithms
for abelian hidden subgroup problems, such as Shor’s factoring algorithm, can be implemented
with logarithmic quantum depth. Therefore, “quantum polylogarithmic depth is as powerful as
quantum polynomial depth in the presence of classical computation” seems to be a live possibility!

Aware of this possibility, Jozsa [Joz05] conjectured that

“Any polynomial time quantum algorithm can be implemented with only O(log n) quantum
depth interspersed with polynomial-time classical computations.”

Nevertheless, there are other opinions in the community. It has been conjectured by Aaron-
son [Aar05, Aar10, Aar11, Aar19] more than a decade ago that

“There exists an oracle O relative to which BQP 6= BPPQNC.”

Here, BPPBQNC is corresponding to one of the hybrid approaches for interleaving classical comput-
ers with small-depth quantum circuits. It is worth noting that the models Jozsa and Aaronson
considered were related but different, and we will clarify this later in Section 1.2.

In this work, we disprove Jozsa’s conjecture and prove Aaronson’s conjecture. In fact, we prove
a stronger conclusion that relative to oracles, doubling the quantum circuit depth already gives the
computational model more power, and this cannot be traded by classical computations.

1.1 Main Results

We start by defining two hybrid models, which interleave d-depth quantum circuits and classical
computers. The first scheme, called d-depth quantum-classical scheme (d-QC scheme), is a general-
ized model for small-depth measurement-based quantum computers (MBQC). The second scheme,
called d-depth classical-quantum scheme (d-CQ scheme), characterizes the hybrid quantum and
classical computations. Briefly, a d-QC scheme is based on a d-depth quantum circuit and can
access some classical computational resources after each level, while a d-CQ scheme is based on a
classical computer with access to some d-depth quantum circuits. We (informally) define BQNCBPP

d

†Our oracle separation results hold even if the unbounded fan-out gates are allowed.

2



to be the set of languages decided by d-QC schemes, and BPPBQNCd to be the set of languages de-
cided by d-CQ schemes. Also, when we write BQNCBPP (resp., BPPBQNC), we refer to the union of

BQNCBPP
logk n

(resp., BPPBQNC
logk n) for constant k ∈ N. (These definitions will be formally given in

Section 3.)
Note that Jozsa’s conjecture refers to the equivalence problem of BQP and the hybrid model

d-QC schemes, and Aaronson’s conjecture refers to the separation between BQP and the other
hybrid model d-CQ schemes. As we shall see, we will introduce an oracle problem below, which
can be used to show separation results for both conjectures.

Our oracle problem is a variant of Simon’s problem. Given a function f : Zn2 → Zn2 with the
promise that there exists s ∈ Zn2 such that f(x) = f(x ⊕ s) for x ∈ Zn2 , Simon’s problem is to
find s [Sim94]. Such two-to-one function f is called a Simon function. Simon’s problem is easy for
quantum-polynomial-time (QPT) algorithms but hard for all probabilistic-polynomial-time (PPT)
algorithms; however, Simon’s problem can be solved by a constant-depth quantum circuit with
classical postprocessing.

To devise a harder problem, we first represent a Simon function as a composition of random
one-to-one functions f0, . . . , fd−1 and a two-to-one function fd such that f = fd ◦ · · · ◦ f0 as shown
in Fig. 1, where fj : Sj → Sj+1 has domain Sj and range Sj+1 for j = 0, . . . , d. Suppose that f is
hidden and only access to these functions fi are provided. If f0, . . . , fd must be queried in sequence
to evaluate f , then a d-depth quantum circuit cannot solve this variant of Simon’s problem, since
it can only make at most d sequential queries (but there are d+ 1 random functions).

Figure 1: Composing d random one-to-one function f0, . . . , fd−1 and a two-to-one function fd such
that f = fd ◦ · · · ◦ f0.

Nevertheless, a cleverer approach that does not query the functions in sequence might exist.
To rule out the possibility of such an approach, we further make it infeasible for the domain
of fi to be accessed before the (i+ 1)-th parallel queries. Specifically, fj is now defined on

a larger domain S
(0)
j such that Sj is a subset of S

(0)
j and |Sj |/|S(0)

j | is chosen to be negligible for
j = 0, 1, . . . , d+ 1. This is illustrated in Fig. 2. Therefore, to evaluate fi, one must find the target

domain Si from the larger domain S
(0)
i , and the success probability is negligible by construction. It

is worth noting that an algorithm can learn Si after the i-th query with probability one, and thus
is able to evaluate f after d+ 1 sequential queries. However, using at most d sequential queries is
still not enough for the algorithm to evaluate f .

To sum up, the oracle we consider is as follows. Let f be an arbitrary Simon function. Choose a

sequence of random one-to-one functions f0, . . . , fd−1 defined on much larger domains S
(0)
0 , . . . , S

(0)
d ,

respectively, and let fd be a two-to-one function such that fd ◦ · · · ◦ f0(x) = f(x) for x ∈ S0. We
define the shuffling oracle of f with respect to f1, . . . , fd−1 to be an oracle that returns a value of

3



Figure 2: The shuffling oracle: f0, . . . , fd−1 are random one-to-one functions on a greater domain.
For x ∈ S0, f(x) = fd ◦ · · · ◦ f0(x).

f0, . . . , fd−1 or fd when queried. Thus an algorithm with access to this oracle can access f0, . . . , fd.
We will simply call it the shuffling oracle of f in the following without mentioning the underlying
f0, . . . , fd−1.

The d-Shuffling Simon’s Problem (d-SSP) is a decision problem defined as follows:

Definition 1.1 (d-SSP (Informal)). Let f be a random one-to-one function or a random Simon
function. Given oracle access to the shuffling oracle of f (as in Fig. 2), the problem is to decide
whether f is a Simon function or not.

We summarize our results in the following theorem.

Theorem 1.2 (Informal). For any d, d-SSP ∈ (BQNCBPP
2d+1)

O ∊ (BPPBQNC2d+1)O, but d-SSP /∈
(BQNCBPP

d )O ∪ (BPPBQNCd
O

), where O is the shuffling oracle of f . ‡

Theorem 1.2 states that relative to the shuffling oracles, (2d+1)-QC schemes (resp., (2d+1)-CQ
schemes) are strictly more powerful than d-QC schemes (resp., d-CQ schemes). Namely, doubling
the quantum circuit depth indeed gives the hybrid model more power, and this cannot be traded
for classical computation.

Theorem 1.2 immediately implies the following corollary, which states that Jozsa’s conjecture
is false relative to an oracle.

Corollary 1.3 (Informal). For d = logω(1) n, d-SSP ∈ BQPO, but d-SSP /∈ (BPPBQNC)O ∪
(BQNCBPP)O, where O is the shuffling oracle of f .

1.2 Discussion and Open Problems

Jozsa’s and Aaronson’s conjectures The hybrid model Jozsa considered in [Joz05] is the
small-depth MBQC, which is characterized by the d-QC scheme in this work. On the other hand,
Aaronson considered the complexity class BPPBQNC, which is corresponding to the d-CQ scheme
defined in this paper.

Since we cannot even prove that BPP 6= BQP, an unconditional separation seems unachievable
by the state-of-the-art techniques. Instead, we can expect an oracle separation or a conditional lower

‡Following the definition of BQNCBPP
d and BPPBQNCd , the gate set is the collection of one- and two-qubit gates.

However, our oracle separation actually works for any gate set even with unbounded fan-out gates. The main point
is that the depth of the queries is less than the depth of the shuffling oracle.

4



bound based on certain assumptions in cryptography or complexity. In this work, we obtain an
oracle separation between BQP and BPPBQNC∪BQNCBPP. Therefore, one central question is: can we
achieve a conditional separation based on plausible assumptions, or equivalently, can we instantiate
our oracle? A natural approach is to instantiate it based on cryptographic assumptions, such as
virtual-black-box (VBB) obfuscations. However, while it is possible to make our oracle efficient,
since our oracle uses random shuffling to hide the Simon’s function, we may not assume secure VBB
obfuscation of our oracle given the known negative evidence by Bitansky et al. [BCC+14]. It is not
clear whether our oracle can be instantiated based on any reasonable cryptographic assumptions.

Our work also address another critical question: can we trade classical computations for quan-
tum circuit depth? If this is possible, then it may be easier for near-term quantum computers to
achieve quantum supremacy on practical problems. In this work, we give some negative evidence by
showing a fine-grained depth separation result that (BPPBQNCd)O 6= (BPPBQNC2d+1)O. This result
implies that doubling the quantum depth gives the model more power, and this cannot be traded
by classical computations in the relativized world. We would like to see if we can obtain a sharper
separation, such as d versus d+ 1, under plausible assumptions in cryptography or complexity.

1.3 Acknowledgement

We are grateful to Scott Aaronson for bringing us to the problem of separating BQP and BPPBQNC.
We also thank him for helpful discussions and valuable comments on our manuscript. We would like
to thank Richard Jozsa for clarifying his conjecture and Aaronson’s conjecture. We acknowledge
conversations with Matthew Coudron for explaining their related work to us.

NHC’s research is supported by Scott Aaronson’s Vannevar Bush Faculty Fellowship from the
US Department of Defense. KMC’s research is partially supported by the Academia Sinica Career
Development Award under Grant 23-17 MOST QC project, and MOST QC project under Grant
MOST 107-2627-E-002-002. CYL was financially supported from the Young Scholar Fellowship
Program by Ministry of Science and Technology (MOST) in Taiwan, under Grant MOST108-2636-
E-009-004.

1.4 Independent Work

Independent and concurrent to our work, Coudron and Menda also investigated Jozsa’s conjecture
and proved that the conjecture is false relative to some oracle [CM19a]. However, they did not
establish the sharp separation between quantum depth d vs. 2d + 1 as we did. Interestingly, the
oracle problem used in their work as well as the analysis are very different from ours, which may lead
to incomparable extensions or applications in the future. In the following, we provide a high-level
discussion and compare the two works.

At a high-level, Coudron and Menda use the Welded Tree Problem of Childs et al. [CCD+03] as
the oracle problem to disprove Jozsa’s conjecture, which leverage the separation between quantum
walk and classical random walk. To show the separation, they do not need to modify the oracle
problem, and the crux is a simulation argument showing that low depth quantum computation
can be simulated by (inefficient) classical computation without blowing up the number of oracle
queries too much. Hence, the hardness of the hybrid models follows by the classical hardness. The
simulation argument relies on the structure of the welded tree oracle and does not seem to apply
to our oracle.

In contrast, our starting point is Simon’s problem, which can be viewed as a separation between
quantum depth 0 (i.e., classical computation) and 1 in the hybrid models, and our main idea is
to lift the separation by pointer chasing and domain hiding. This allows us to prove the sharp

5



separation between quantum depth d vs. 2d+ 1. To prove the separation, we generalize techniques
in cryptography (from both quantum and classical crypto literature) to show that small quantum
depth is not enough to find the hidden domain and hence the hybrid models with quantum depth
d are not capable to solve the d-SSP problem.

We mention that the original version of Coudron and Menda [CM19a] only explicitly considered
the hybrid model d-CQ schemes, but their analysis extends directly to establish hardness of the
Welded Tree Problem for d-QC schemes. Furthermore, we believe that the techniques in both
works extend to establish hardness of respective oracle problems for the natural hierarchy of hybrid

models like BPPBQNCBPP
¡¡¡

[CM19b].

2 Proof Overview

The main idea behind our shuffling oracle is combining pointer chasing and domain hiding to lift
the hardness of Simon’s problem. We start with the intuition behind our construction.

Pointer Chasing & Domain Hiding The pointer chasing is to allow the function to be eval-
uated by using d + 1 parallel queries, but make it hard by using at most d parallel queries. To
implement this idea, we decompose a Simon function f as f0, . . . , fd, where f0, . . . , fd−1 are random
“shufflings” of the original function and fd is the function such that f = fd ◦ · · · ◦ f0. Ideally, to
evaluate f , a standard approach is to evaluate the functions in sequence. However, it is unclear if
there are clever methods. To tackle this, our second idea is hiding the original domains S0, . . . , Sd
in larger domains S

(0)
0 , . . . , S

(0)
d , respectively. Intuitively, to evaluate f , one needs to learn fd in Sd,

or say, needs to find Sd in S
(0)
d . Note that it suffices to use i rounds of parallel queries to learn Si.

The goal of the shuffling oracle is to obtain the (tight) hardness that it prevents the algorithm from
learning Sd before dth parallel queries so that one cannot evaluate fd in the dth parallel queries.

Obtaining Indistinguishability from Hiding The intuition behind our analysis is similar to
the One-way-to-Hiding (O2H) Lemma [AHU18, Unr15] in quantum cryptography, and our analysis
can be viewed as generalizing the lemma to the setting of the shuffling oracle against both hybrid
models. Briefly, the O2H Lemma shows that given any two random functions which have same
function values on most elements except for some hidden subset, we can bound the probability
of distinguishing these two functions by the probability that the queries are in the hidden set,
which we call the finding probability. This probability will be negligible if the subset is a small
enough random subset. The O2H Lemma implies that given a random function, we can program
the mappings in the hidden subset arbitrarily. In our context, a natural approach is to argue that

Sd is a hidden subset in S
(0)
d and hence we can indistinguishably program the mappings in Sd in

a way such that the programmed oracle has no information about f . However, different from the
typical use of O2H Lemma in cryptography, in the shuffling oracle, the algorithm can find Sd by
using d parallel queries starting from S0 (and query Sd at the d + 1st query), so we need to be
careful in arguing that Sd is a hidden subset.

Russian-Nesting-Doll Trick We bypass the difficulty above by partitioning the large set S
(0)
d

into a series of smaller subsets S
(1)
d , . . . , S

(d)
d , such that S

(`)
d is a exponentially small subset of

S
(`−1)
d for ` ∈ [d], and for the ease of illustrating ideas, Sd ⊂ S

(d)
d
§. We do such partition for all

§For the proof of d-QC and d-CQ scheme, there will be a small subset in Sd which is not in S
(d)
d ; however, we will

show in the proof that it suffices to prove the oracle separation.

6



Figure 3: The domains partitions under the Russian-nesting-doll trick: f0 on S
(0)
0 and f1, . . . , fd on

S
(0)
1 \ S

(1)
1 , . . . , S

(0)
d \ S

(1)
d can be viewed as the “first doll”, which will be opened by the first round

parallel queries. Along this line, fi−1 on S
(i−1)
i−1 and fi, . . . , fd on S

(i−1)
i \ S(i)

i , . . . , S
(i−1)
d \ S(i)

d can
be viewed as the ith doll, which will be opened by the ith round parallel queries.

domains of f0, . . . , fd. Then, we use the O2H Lemma to show that after the first parallel query, the

algorithm can learn f0 on S
(0)
0 and f1, . . . , fd on domains out of S

(1)
1 , . . . , S

(1)
d ; however, it learns

nothing about f1, . . . , fd on S
(1)
1 , . . . , S

(1)
d . For the second parallel queries, we start from f1, . . . , fd

on S
(1)
1 , . . . , S

(1)
d , and use the O2H Lemma again to argue that the algorithm learns little about

f2, . . . , fd on S
(2)
2 , . . . , S

(2)
d . Finally, for the dth parallel queries, the algorithm has no information

about fd on S
(d)
d and thus has no information about f . We can think of this approach as a Russian-

nesting-doll trick: the mappings f0 on S
(0)
0 and f1, . . . , fd on domains out of S

(1)
1 , . . . , S

(1)
d are the

largest doll outside, there are d dolls, and fd on S
(d)
d is the smallest one we want to see. For an

algorithm to see Sd, it needs to open all the dolls, and each requires one round parallel queries;
therefore, the algorithm cannot see the smallest doll before dth parallel queries. We illustrate the
idea of the Russian-nesting-doll trick as in Fig. 3.

We give a brief overview of how to formalize the ideas above in the follows.

2.1 QNCd circuit

This is the warm-up case. Let U := U1, . . . , Ud+1 be a d-depth quantum circuit which can make
superposed queries to the shuffling oracle F := (f0, . . . , fd) after Ui for i ∈ [d]. We represent the
computation as

Ud+1FUd ¡ ¡ ¡ FU1.

Following the Russian-nesting-doll trick, we partition the domains S
(0)
0 , . . . , S

(0)
d into d subsets.

Then, for the ith parallel queries, we construct a shadow oracle Gi of F such that Gi agrees with F on

elements out of S
(j)
j , . . . , S

(j)
d , but maps the rest to ⊥ (a specific notation for no information). Here,

we need to choose the subsets in a specific way, which we will describe in the formal proof. By using
hybrid arguments and O2H Lemma, we inductively prove that Ud+1FUd ¡ ¡ ¡ FU1 is indistinguishable
from Ud+1GdUd ¡ ¡ ¡ G1U1.

7



2.2 d-QC scheme

For the d-QC scheme, since the classical algorithm can make polynomial classical parallel queries,
the set Sd can be found by the classical algorithm. However, the classical algorithm can only make
polynomially many queries, and the rest of the points which are not queried are still uniform.

Therefore, we can remove whatever points learned by classical queries from the hidden sets S
(j)
k ,

and use O2H Lemma and the hybrid arguments as before. At the end, the algorithm does not
learn Sd except for polynomially many points, which is unlikely to learn the shift (as in the proof
of classical hardness for Simons).

2.3 d-CQ scheme

Arguing that Sd is a hidden subset in S
(0)
d against the d-CQ scheme is the most challenging part

of our analysis. The main obstacle is that the measurement outcome of the quantum circuit can
contain global information about the shuffling oracle, and this makes it hard to reason that the
shuffling oracle is still uniformly random conditioned on the measurement outcome. However, since
the measurement outcomes can only be a “short classical advice”, intuitively, it cannot contain too
much information about the shuffling oracle.

To formalize this intuition, we (partially) generalize a presampling argument in (classical) cryp-
tography [CDGS18, Unr07]. Informally, the argument states that a random function conditioned
on a short classical advice string is indistinguishable from a convex combination of random func-
tions that are fixed on a few elements for any classical algorithm making polynomial queries.
Ideally, we would like to generalize it to the shuffling oracle (which is more complicated than ran-
dom oracle) and show indistinguishability to a convex combination of shuffling oracles with a few
points fixed for quantum algorithms with a bounded number of queries. Unfortunately, we do not
know how to achieve this, but we prove something weaker that is sufficient: we show that given
a short classical advice string, the shuffling oracle is indistinguishable from a convex combination
of “almost-uniform” shuffling oracles with few points fixed for any quantum algorithm making one
quantum parallel query.

This weaker statement suffices to prove our oracle separation. While there are some further
subtleties, the main idea is that we apply it inductively after each quantum parallel query, and the
short advice string only fixes polynomially many random points in the shuffling oracle. Given this,
we are able to show that Sd remains a hidden set against the d-CQ scheme and establish hardness
of d-SSP against BPPBQNCd .

3 Preliminaries

In this section, we first introduce the distance measures of quantum states. Then, we give formal
definitions of the d-CQ and d-QC schemes.

3.1 State distance

Definition 3.1. Let H be a Hilbert space. For any two pure states |ψ〉, |φ〉 ∈ H, we define

• (Fidelity) F (|ψ〉, |φ〉) := |〈ψ|φ〉|;

• (Two-norm distance) ‖|ψ〉 − |φ〉‖.

Then, we define distance measures between mixed states.

8



Definition 3.2. Let H be a Hilbert space. For any two mixed states ρ, ρ′ ∈ H,

• (Fidelity) F (ρ, ρ′) := tr(
√√

ρρ′
√
ρ).

• (Trace distance) TD(ρ, ρ′) := 1
2 Tr |ρ− ρ′|.

• (Bures distance) B(ρ, ρ′) :=
√

2− 2F (ρ, ρ′).

The probability for a quantum procedure to distinguish two states can be bounded by the Bures
distance between the two states.

Claim 3.3. For any two mixed states ρ and ρ′, for any quantum algorithm A and for any classical
string s,

|Pr[A(ρ) = s]− Pr[A(ρ′) = s]| ≤ B(ρ, ρ′).

Proof. It is well-known that |Pr[A(ρ) = s]− Pr[A(ρ′) = s]| ≤ 1
2 Tr |ρ− ρ′|. Then,

TD(ρ, ρ′) ≤
√

1− F (ρ, ρ′)2

=

√
1 + F (ρ, ρ′)

2

√
2− 2F (ρ, ρ′)

≤ B(ρ, ρ′).

The state distance and Claim 3.3 will be used shortly in the following sections.

3.2 Computational Model

We here define two schemes which interleave low-depth quantum circuits and classical computers.
The first scheme is called d-depth quantum-classical scheme (d-QC scheme) and the second scheme
is d-depth classical-quantum scheme (d-CQ scheme).

We say a set of gates forms a layer if all the gates in the set operate on disjoint qubits. Gates in
the same layer can be parallelly applied. We define the number of layers in a circuit as the depth of
the circuit. In the following, we define circuit families which has circuit depth d as in [TD04, MN98].

Definition 3.4 (d-depth quantum circuit QNCd). A QNCd quantum circuit family {Cn : n > 0} is
defined as below:

• There exists a polynomial p such that for all n > 0, Cn operates on n input qubits and p(n)
ancilla qubits;

• for n > 0, Cn has the initial state |0n+p(n)〉, consists of d layers of one- and two-qubit gates,
and measures all qubits after the last layer.

We can illustrate a QNCd circuit as in Fig. 4, where Ui for i ∈ [d] is a unitary which can
be implemented by one layer of one- and two-qubit gates, and the last computational unit is a
qubit-wise measurement in the standard basis.

In some studies, QNC is also used to refer the set of languages decided by the quantum circuits.
For clarity, we define the set of languages decided by QNCd as BQNCd as follows:

Definition 3.5 (BQNCd). The set of languages L = {Ln : n > 0} for which there exists a circuit
family {Cn : n > 0} ∈ QNCd such that for n > 0, for any x where |x| = n,

9



Figure 4: The QNCd circuit: The single-line wires are the quantum wires, and the double-line wire
is the classical wire.

• if x ∈ Ln, then Pr[Cn(x) = 1] ≥ 2/3;

• otherwise, Pr[Cn(x) = 1] ≤ 1/3.

Then we define the quantum analogue of Nick’s class

Definition 3.6 (BQNCk). The set of languages L = {Ln : n > 0} for which there exists a circuit
family {Cn : n > 0} ∈ QNCd for d = O(logk n) such that for n > 0, for any x where |x| = n,

• if x ∈ Ln, then Pr[Cn(x) = 1] ≥ 2/3;

• otherwise, Pr[Cn(x) = 1] ≤ 1/3.

For simplicity, we define BQNC as the set of languages which can be decided by poly log-depth
quantum circuit that is BQNC :=

⋃
k BQNC

k.
A d-depth quantum circuit with oracle access to some classical function f is a sequence of

operations

U1
q−→ f

q−→ U2
q−→ f

q−→ · · ·Ud
q−→ f

q−→ Ud+1, (1)

where Ui’s are unitaries as we have defined in 3.4. The transition
q−→ implies that Ui can send and

receive quantum messages from f . We add an additional layer of unitary Ud+1 to the computational
model to process the information from the last call of f .

In the quantum query model, we usually consider f as an unitary operator Uf

Uf |x〉|0〉 = |x〉|f(x)〉.

We represent the process in Eq. 1 as follows: let |0, 0〉QA|0〉W be the initial state, where registers Q
and A consist of qubits the algorithm sends to or receives from the oracle and register W consists
of the rest of the qubits the algorithm holds as working space. Let

U1|0, 0〉QA|0〉W =
∑
x,y

c(x, y)|x, y〉QA|z(x, y)〉W

be the quantum message before applying the first Uf . After applying Uf ,

Uf
∑
x,y

c(x, y)|x, y〉QA|z(x, y)〉W =
∑
x,y

c(x, y)|x, y ⊕ f(x)〉QA|z(x, y)〉W .

We represent Eq. 1 as a sequence of unitaries Ud+1UfUd ¡ ¡ ¡UfU1 in this way. For simplicity, we
rewrite Eq. 1 as Ud+1fUd ¡ ¡ ¡ fU1 in the rest of the paper.

10



Figure 5: The d-depth quantum-classical (d-QC) scheme: The single-line wires stands for the
quantum wires, and the double-line wires are for classical wires.

3.2.1 The d-QC Scheme and BQNCBPP
d

The first scheme we consider is the d-QC scheme, which is a generalized model for d-depth MBQC
and can be represented as the following sequence

Ac
c−→ (Π0/1 ⊗ I) ◦ U (1) c−→ Ac

c/q−−→ · · · c/q−−→ (Π0/1 ⊗ I) ◦ U (d) c−→ Ac, (2)

where Ac is a randomized algorithm, U (i) is a single-depth quantum circuit, and Π0/1 is a projective

measurement in the standard basis on a subset of the qubits. The arrows
c−→ and

q−→ indicate the
classical and quantum messages transmitted. We illustrate the scheme as in Fig. 5

In this model, after applying U (i), one measures a subset of qubits, uses the measurement
outcome to decide U (i+1) by the classical polynomial algorithm Ac, and then apply U (i+1) to the
rest of the qubits. Let L(i) be the procedure Ac → c(Π0/1 ⊗ I) ◦ U (i). Then, we rewrite Eq. 2 as

L(1) c/q−−→ · · · c/q−−→ L(d) c−→ Ac. (3)

Then, we define the languages which can be decided by d-QC scheme.

Definition 3.7 (BQNCBPP
d ). The set of languages L = {Ln : n > 0} for which there exists a family

of d-QC schemes {An : n > 0} such that for n > 0, for any x where |x| = n,

• if x ∈ Ln, then Pr[An(x) = 1] ≥ 2/3;

• otherwise, Pr[An(x) = 1] ≤ 1/3.

Let A be a d-QC scheme with access to some oracle O. We represent AO as a sequence of
operators:

(L(1))O
c/q−−→ · · · c/q−−→ (L(d))O

c−→ AOc , (4)

where (L(i))O := AOc
c−→ (Π0/1 ⊗ I) ◦ OU (i). We illustrate the scheme as in Fig. 6.

Definition 3.8 ((BQNCBPP
d )

O
). The set of languages LO := {LOn : n > 0} for which there exists a

family of d-QC schemes {AOn : n > 0} such that for n > 0, for any x where |x| = n,

• if x ∈ LOn , then Pr[AOn (x) = 1] ≥ 2/3;

• otherwise, Pr[AOn (x) = 1] ≤ 1/3.

Similar to the definition of BQNC, we define BQNCBPP as a set of languages which can be
decided by a family of d-QC schemes with d = O(poly log n).

11



Figure 6: The d-QC scheme with access to an oracle O

Figure 7: The d-depth classical-quantum (d-CQ) scheme

3.2.2 The d-CQ scheme and BPPBQNCd

Here we define the d-CQ scheme that is a classical algorithm which has access to a QNCd circuit
during the computation. We represent the scheme as follows:

Ac,1
c−→ Π0/1 ◦ C

c−→ · · · c−→ Ac,m
c−→ Π0/1 ◦ C

c−→ Ac,m+1, (5)

where m = poly(n), Ac,i is a randomized algorithm, C is a d-depth quantum circuit, and Π0/1 is
the standard-basis measurement. We illustrate the scheme as in Fig. 7.

In t";"""date"",""2020-09-15T01:47:47Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2020-09-15T01:47:47Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016) kpathsea version 6.2.2""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2020-09-15T01:47:47Z""
""created"",""2020-09-15T01:47:47Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-09-15T01:47:47Z""
""resourceName"",""1909.10303""
""Author"",""""
""producer"",""pdfTeX-1.40.17""
""pdf:docinfo:producer"",""pdfTeX-1.40.17""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""1"",""0"",""1"",""1"",""3"",""0"",""10"",""23"",""18"",""0"",""0"",""0"",""29"",""0"",""35"",""50"",""58"",""73"",""30"",""34"",""27"",""9"",""19"",""45"",""13"",""3"",""37"",""31"",""20"",""5"",""27"",""14"",""7"",""16"",""10"",""13"",""6"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2020-09-15T01:47:47Z""
""Last-Modified"",""2020-09-15T01:47:47Z""
""dcterms:modified"",""2020-09-15T01:47:47Z""
""title"",""""
""Last-Save-Date"",""2020-09-15T01:47:47Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2020-09-15T01:47:47Z""
""meta:save-date"",""2020-09-15T01:47:47Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016) kpathsea version 6.2.2""
""Content-Length"",""842665""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""40""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""2619"",""3201"",""2510"",""1877"",""3198"",""3048"",""1896"",""2477"",""1799"",""1420"",""1570"",""1034"",""1469"",""2095"",""2002"",""1717"",""1628"",""1754"",""1491"",""1280"",""1497"",""1526"",""1313"",""2019"",""1247"",""1472"",""1666"",""1974"",""1428"",""1462"",""1974"",""1475"",""1243"",""1456"",""1393"",""1372"",""1738"",""1484"",""2586"",""1448""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-09-15T01:47:47Z""
";https://scholar.google.ch/scholar?start=840&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098875-359;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Decentralized and Privacy-Preserving Public Auditing for Cloud Storage Based on Blockchain;Y Miao, Q Huang, M Xiao, H Li ; IEEE Access, 2020  ieeexplore.ieee.org;;"… in which he applied blockchain as the core compo- nent of the famous cryptocurrency named

Bitcoin … Our DBPA scheme employs the PoW consensus mecha- nism and utilizes blockchain

to record … We show that our DBPA scheme is secure in the random oracle model based …";Cité 1 fois;;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/6287639/8948470/09152981.pdf;"
		
	";"""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""dc:title"",""IEEE Xplore Full-Text PDF:""
""Content-Encoding"",""UTF-8""
""resourceName"",""09152981.pdf""
""language"",""es""
""Content-Length"",""2565""
""title"",""IEEE Xplore Full-Text PDF:""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.ch/scholar?start=900&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098857-318;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Improvements on Easypaysy: The Bitcoin's Layer-2 Accounts Protocol;E Ebadi, H Yajam, MA Akhaee ; 2020 17th International ISC …, 2020  ieeexplore.ieee.org;;"… organizations that are active in Bitcoin's ecosystem such as cryptocurrency exchanges and …

proposed two improvements to the Easypaysy layer-2 solution for Bitcoin's Blockchain … Waters,

“Anonymous hierarchical identity- based encryption (without random oracles),” in Annual …";Autres articles;;[PDF] researchgate.net;https://www.researchgate.net/profile/Habib-Yajam-2/publication/347144264_Improvements_on_Easypaysy_The_Bitcoin%27s_Layer-2_Accounts_Protocol/links/6001840f92851c13fe10e666/Improvements-on-Easypaysy-The-Bitcoins-Layer-2-Accounts-Protocol.pdf;;;https://scholar.google.ch/scholar?start=860&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098839-272;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;A study on solutions of cross-ledger intercommunication: Classification, analysis and comparison of crosschain projects;Y Fan ;2020 divaportal.org;;"… Page 4. ii Abstract The phenomenon of isolated value in each blockchain system has become

a distinct issue of the blockchain field … Page 5. iii Sammanfattning Fenomenet isolerat värde

i varje blockchain-system har blivit en distinkt frĺ- ga om blockchainfält …";Autres articles;Version HTML;[PDF] diva-portal.org;https://www.diva-portal.org/smash/get/diva2:1453625/FULLTEXT01.pdf;"
IN DEGREE PROJECT ELECTRICAL ENGINEERING,
SECOND CYCLE, 30 CREDITS

,  STOCKHOLM SWEDEN 2020

A study on solutions of 
cross-ledger 
intercommunication
Classification, analysis and comparison of 
crosschain projects

YUAN FAN

KTH ROYAL INSTITUTE OF TECHNOLOGY
SCHOOL OF ELECTRICAL ENGINEERING AND COMPUTER SCIENCE





A study on solutions of cross-ledger
intercommunication

Classification, analysis and comparison of cross-chain projects

YUAN FAN

Master Thesis in Communication System
Supervisor(s): Henrik Gradin, GyĂśrgy DĂĄn

Examiner: Viktoria Fodor
School of Electrical Engineering and Computer Science

KTH Royal Institute of Technology
Host Company: Centiglobe

February 22, 2020
Stockholm, Sweden 2019



ii

Abstract

The phenomenon of isolated value in each blockchain system has become a
distinct issue of the blockchain field. To address this problem, the demand
of cross-chain intercommunication came up. In a narrow sense, cross-chain
refers to the process of asset interoperability between relatively independent
blockchains. In this thesis, we mainly analyze the design principles, technical
difficulties, and solutions of cross-chain intercommunication in this narrow
sense. With the introduction of distributed ledger technology(DLT), we de-
scribe the interaction with other ledgers as the fundamental problem of cur-
rent blockchain technology.

The implementation of cross-chain is mainly manifested as asset swap and as-
set transfer. So far, there are many existing application scenarios and projects
adopted from these manifestation. This paper will focus on these two imple-
mentations, illustrate their principles, locate the realization difficulties, and
put forward corresponding possible solutions. Then we elaborated on eight
popular cross-chain projects underlying mechanism listed with three main
categories. A detailed comparison according to their interoperability level,
consensus algorithm and application scenarios of the overall overview of 20
cross-chain projects is presented as a table in the Appendix A.

During the implementation process, we performed a simple atomic swap cross-
chain framework based on Hash Time Lock Contract between Bitshares and
Ethereum, then compare the performance with a wallet application present
by Ripple using Interledger Protocol. These two applications are represented
the two different use case of cross-chain realization.

With limited number of projects to test out, our conclusion was reached after
a discussion with the relative merits of the two approaches. Interledger proto-
col has a better solution from the aspects of the decentralization, scalability,
and whether it supports traditional ledgers.

Keywords: Distributed Ledger Technology, Cross-chain study, Atomic
swaps, Interledger protocol, Relay, Sidechains



iii

Sammanfattning

Fenomenet isolerat värde i varje blockchain-system har blivit en distinkt frü-
ga om blockchainfält. FÜr att hantera detta problem kom kravet pü inter-
kommunikation mellan kedjor upp. I en smal mening hänvisar tvärkedjan
till processen fĂśr interoperabilitet mellan tillgĂĽngar mellan relativt oberoende
blockchains. I denna avhandling analyserar vi huvudsakligen designprinciper,
tekniska svĂĽrigheter och lĂśsningar fĂśr interkommunikation mellan kedjor i
en smal bemärkelse. Med introduktionen av distribuerad huvudboksteknologi
(DLT) beskriver vi interaktionen med andra bokar som det grundläggande
problemet med den nuvarande blockchain-tekniken.

Tvärkedjans implementeringsform manifesteras huvudsakligen som tillgüngs-
byte och ĂśverfĂśring av tillgĂĽngar. Hittills finns det mĂĽnga befintliga applika-
tions scenarier och Pro projekt som antagits frĂĽn dessa manifestation. Detta
dokument kommer att fokusera pĂĽ dessa tvĂĽ implementeringar, illustrera de-
ras principer, lokalisera fÜrstüelsessvürigheterna och lägga fram motsvarande
mÜjliga lÜsningar. Sedan utarbetade vi ütta populära tvärkedjeprojekt under-
liggande mekanism listade med tre huvudkategorier. En detaljerad jämfÜrelse
beroende pü deras driftskompatibilitetsnivü, konsensusalgoritm och tillämp-
ningsscenarier av den Üvergripande Üversikten Üver 20 tvärkedjeprojekt pre-
senteras som en tabell i Appendix A.

Under genomfĂśrandeprocessen genomfĂśrde vi en enkel atomisk swap Cross-
Chain ram baserad pĂĽ hash Time lock kontrakt mellan Bitshares och Ethere-
um, sedan jämfÜra prestanda med en plünbok program som finns med Ripple
med Interledger Protocol. Dessa tvü applikationer fÜreställs de tvü olika an-
vändningsfallen av Cross-Chain genomfÜrande.

Med begränsade projekt att testa, nüddes vür slutsats efter en diskussion med
relativa fĂśrdelar med tvĂĽ metoder praktiskt taget. Interledger-protokollet har
en bättre lÜsning med avseende pü decentralisering, skalbarhet och huruvida
det stĂśder traditionella bokar.

Keywords: Distribuerad Huvudboksteknik, Tvärkedjestudie, Atombyte,
Interledger-protokoll, Relä, Sidokedjor



iv

Acknowledgements

This thesis work proceed smoothly with the kind support and help of many indi-
viduals whose names may not all be enumerated. I would like to extend my sincere
appreciation to all of them.

Foremost, this interesting topic is come up by my industry supervisor Dr.Henrik
Gradin, who plays an important role of conducting me with the research purpose,
leading my direction when the obstacles comes and express the confidence in me.

Also, I am thankful for having professor GĂśrgy DĂĄn and professor Viktoria
Fodor as my academic supervisor and examiner respectively. Professor GĂśrgy
gives the great guidance and supervision regarding this research and Viktoria im-
parts her knowledge and constant help with the report in this study.

My thanks to all relatives, friends and others who share their support through a
long time of thesis project. My beloved parents, who is always by my side when I
get frustrated and upset, the saying of yours to get together with myself touched
me a lot.

Finally, I would express my deep gratitude to enthusiastic developers of Interledger.
They patiently answered my questions with the concept and the implementation
efficiently and detailedly.

Yuan Fan,
Stockholm,
February 22, 2020



Contents

Contents v

List of Tables vii

List of Figures viii

List of Acronyms ix

Listings x

1 Introduction 1
1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Research Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3 Research Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.4 Research Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.5 Delimitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.6 Thesis Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2 Literature Study 7
2.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.1.1 What is cross-ledger? . . . . . . . . . . . . . . . . . . . . . . 7
2.1.2 Evolution of Cross-chain . . . . . . . . . . . . . . . . . . . . . 7

2.2 Cross-chain manifestation . . . . . . . . . . . . . . . . . . . . . . . . 8
2.3 Difficulties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.4 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3 Projects Classification 13
3.1 Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.1.1 Ensure the atomic of transactions . . . . . . . . . . . . . . . 13
3.1.2 Complete the transaction confirmation . . . . . . . . . . . . . 16
3.1.3 Realize multiple chains interoperability . . . . . . . . . . . . 20

3.2 Project study . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.2.1 Lightning Network . . . . . . . . . . . . . . . . . . . . . . . . 22

v



vi CONTENTS

3.2.2 Notary Scheme . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.2.3 Relay Scheme . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.2.4 Sidechain Scheme . . . . . . . . . . . . . . . . . . . . . . . . . 34

3.3 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

4 Implementation and analysis 39
4.1 Environment Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

4.1.1 Blockchains . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.2 Smart contract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.3 HTLC Atomic-swaps implementation . . . . . . . . . . . . . . . . . . 42
4.4 Interledger switch wallet . . . . . . . . . . . . . . . . . . . . . . . . . 46

4.4.1 STREAM payment . . . . . . . . . . . . . . . . . . . . . . . . 46
4.4.2 Work flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

4.5 Market Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
4.6 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

5 Conclusion and Future Work 53
5.1 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
5.2 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

Bibliography 55

Appendix A 59

Appendix B 67
I. Atomic swaps based on HTLC . . . . . . . . . . . . . . . . . . . . . . . 67
II. Ethereum smart contracts . . . . . . . . . . . . . . . . . . . . . . . . . 69



List of Tables

4.1 Feature summary of chosen blockchains . . . . . . . . . . . . . . . . . . 41
4.2 Market Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

1 Summary of 20 Cross-chain Projects . . . . . . . . . . . . . . . . . . . . 60

vii



List of Figures

1.1 Research components of cross-chain intercommunication . . . . . . . . . 4

2.1 Cross-chain development tree . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2 Inter-chain exchange diagram . . . . . . . . . . . . . . . . . . . . . . . . 9
2.3 Inter-chain transfer diagram . . . . . . . . . . . . . . . . . . . . . . . . . 10

3.1 Atomic swaps diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.2 Hash Time-lock Contract diagram . . . . . . . . . . . . . . . . . . . . . 16
3.3 Centralized Notary Scheme diagram . . . . . . . . . . . . . . . . . . . . 17
3.4 Multi-sig Notary Scheme diagram . . . . . . . . . . . . . . . . . . . . . . 18
3.5 Distributed signature Notary Scheme diagram . . . . . . . . . . . . . . . 18
3.6 Direct interconnection network architecture diagram . . . . . . . . . . . 20
3.7 Cross-chain platform network architecture diagram . . . . . . . . . . . . 21
3.8 ILP example process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.9 Data transfer process from Ethereum to Wanchain1 . . . . . . . . . . . 25
3.10 Data transfer process from Wanchain to Ethereum2 . . . . . . . . . . . 26
3.11 The normal process of executing the exchange contract (with Jury en-

dorsement) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.12 The normal process of executing the exchange contract (with Mediator

endorsement) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.13 BTC-Relay cross-chain process diagram . . . . . . . . . . . . . . . . . . 30
3.14 Cosmos network architecture1 . . . . . . . . . . . . . . . . . . . . . . . . 31
3.15 IBC sequence diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.16 IBC sequence diagram, timeout . . . . . . . . . . . . . . . . . . . . . . . 33
3.17 2-way pegged sidechain diagram1 . . . . . . . . . . . . . . . . . . . . . . 35
3.18 Drivechain working diagram . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.19 OneLedger sidechain architecture . . . . . . . . . . . . . . . . . . . . . . 37

4.1 BTS->ETH swap diagram . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.2 CLI application outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.3 Switch wallet interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.4 Exchange Sequence diagram . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.5 Sequence diagram of payment channel . . . . . . . . . . . . . . . . . . . 49

viii



List of Acronyms

ICT Information Communications Technology
BTC Bitcoin
ETH Ethereum coin
HTLA Hash Time-locked Agreement
HTLC Hash Time-locked Contract
MPC Multi-Party Computation
SPV Simplified Payment Verification
RSMC Recoverable Sequence Maturity Contract
addr address
Tx Transmit(Tx) Data
ILP Interledger Protocol
DApps Decentralized Applications
ETF Exchange Traded Fund
HHCM Hierarchical Hybrid Consensus Mechanism
PoW Proof-of-Work
PoS Proof-of-Stake
BFT Byzantine Fault Tolerance
DAG Directed Acyclic Graph
DPoS Delegated Proof-of-Stake
PoI Proof-of-Intelligence
API Application Programming Interface
IBC Inter-Blockchain Communication protocol
UDP User Datagram Protocol
TCP Transmission Control Protocol
PBFT Practical Byzantine Fault Tolerance
LFT Loop Fault Tolerance
AUXPoW+DPoS Auxiliary Proof of Work and Delegated Proof of Stake
RPCA Ripple Protocol consensus algorithm
FBA Federated Byzantine Agreement
cli command line interface
SHA-256 Secure Hash Algorithm 256

ix



x LISTINGS

Listings

1 Bitshares deploy the HTLC . . . . . . . . . . . . . . . . . . . . . . . 67
2 Ethereum refund after expiration . . . . . . . . . . . . . . . . . . . . 68
3 Create hash timelock contract example . . . . . . . . . . . . . . . . . 69
4 Ethereum micro-payment channel structure – Machinomy . . . . . . 71



Chapter 1

Introduction

Chapter 1 gives a general introduction to the thesis contributions. Section 1.1
describes Distributed Ledger Technology and points out the main issue this area is
facing now. Section 1.2 lists out the main problem this thesis addresses. This is
followed by the discussion of the research methods, objectives and delimitations in
Section 1.3, 1.4, and 1.5. The outline of the thesis is presented in Section 1.6.

1.1 Motivation

Initially, the ledger means the foundation of accounting. However, it is not difficult
to find that there are many shortcomings in the long-term use of traditional ledgers,
for example, low efficiency, high cost, opacity and easy to cause fraud and abuse
issues [1].

With the development of information technology, these ledgers have gradually
evolved into digital technology. The distributed ledger is a significant leap after
the digitization of ledger-based technology. It is a database that is shared, repli-
cated, and synchronized between network members [2]. It records transactions
between network participants, such as the exchange of assets or data. From a tech-
nical point of view, the Distributed Ledger Technology (DLT) not only inherits the
traditional bookkeeping philosophy but also has its unique innovations, which has
some advantages that traditional ledgers cannot reach.

Blockchain systems perform as one ""single-machine"" for a long time since the Bit-
coin was introduced. Every blockchain is highly independent and challenging to
communicate with each other. Hence, the data and services in the blockchain
world are confined to the individual blockchain. As a result, this phenomenon will
discourage development. As if we could find a standardized cross-chain protocol/-
platform that could link all blockchain systems, the services could be more specific
and complete due to the co-operation of the blockchains. The popularization and

1



2 CHAPTER 1. INTRODUCTION

maturity of cross-chain technology will lead a revolutionary development in the
blockchain field. Moreover, different from the Internet to achieve the circulation of
information, cross-ledger could realize the distribution of values.

Based on the background above, there exist many distributed ledgers, but for them
to be fully distributed, there is a strong need of them to communicate with each
other and also traditional ledgers. Otherwise, the consistency between the ledgers
of different entities across the chain would not be guaranteed. There have been
many different approaches, such as cross-chain protocols and platforms released to
realize the cross-chain transactions, so it is worthy of finding out the differences
between them.

1.2 Research Questions

There is one technical issue that affects the blockchain developers, which is the
intercommunications. A single blockchain network is a relatively closed system
that does not actively interact with the outside world. The assets of each chain
are also an independent value system. If we can break through the interoperability
among different ledgers and let the value circulate on the broader world, it will
inevitably promote the rapid development of the blockchain industry. Cross-chain
technology is dedicated to building a bridge of trust between ledgers, breaking the
situation of an isolated value system, and realizing asset interoperability to achieve
a real win-win situation.

For the existing blockchain system, it is very time-consuming and laborious to
connect them individually. With the development of the computer network, we
need a set of across chain standards for blockchain interoperability, but this is not
an easy thing to do. It should be an industry-driven standard that is widely applied.
When the majority of projects follow a common, easy-to-use protocol, this standard
is genuinely established. Having a universal standard of cross-chain communication
patterns can be represented as an important milestone for the industry. The rapid
flow of information will inevitably drive the improvement of efficiency and become
the internal driving force for the development of the blockchain industry.

In fact, cross-chain technology is facing several key difficulties such as how to ensure
atomicity, etc. The detailed discussion is elaborated in section 2.3. So how well a
mature cross-chain project meets with those criteria will be taken into consideration
during the whole study.



1.3. RESEARCH METHODOLOGY 3

1.3 Research Methodology

This project mainly makes uses of a combination of qualitative and quantitative
research strategy.

For the beginning of this research, a literature study and review was taken first to
gain a deep understanding of cross-ledger history and realization of communications
through published papers. Then the critical point is the case study among popular
projects. By studying the different cross-chain implementations, exacting the ideas
and scheme they uses, we can summarize and categorize them into different groups,
hence, identify patterns and commonalities in the cross-chain field. Moreover, we
can help the increasing developers to consummate the blockchain design.

To gain a proper perspective of the practical usage and performance of purposed
solutions, it is necessary to actually implement at least one of them. During this
thesis, we introduced two test cases at the implementation stage, involving the-
oretical comparison between a framework design and integration with the HTLC
atomic swaps, and one asset transfer test scenario working mechanism analysis.

1.4 Research Objectives

My research has contributed to the universal demanding and requirements on cross-
ledger communication towards blockchain areas. In particular, I have focused on
the problems that the realization of cross-chain communication is facing.

To understand different patterns or implementations of cross-chain technology, we
need to start with the history of cross-chain and grasp the main idea of chain
interoperability based on literature review. Based on those findings, we sum-
marized the fundamental problems the blockchains are facing, according to those
difficulties, I will give several examples through the case study in the following
chapters. The analysis and comparison from various aspects will next lead to a
standard and universal needs of the cross-chain area. In my thesis, I have considered
the following three major elements of this study as shown in Figure 1.1



4 CHAPTER 1. INTRODUCTION

Figure 1.1: Research components of cross-chain intercommunication

1.5 Delimitations

Information provided in this thesis work is the result of multiple new kinds of
research, some findings and theoretical background are based on publicly avail-
able resources of varying quality, including the posts from the discussion forum.
Addressing the cross-chain problem located in one specific field could lead to an
unbalanced view, since cross-chain may evolve into a financial aspect that I do not
comprehend. This thesis conclusion does not provide any suggestion for investment.

There are tons of nuance, variations in cross-chain system design and assumptions.
Due to the time limit, here we focus on the analysis of specific cross-chain trans-
actions performance. Aside from the projects that are not landing for use, many
projects outlined are proposing solutions that in requirement of multiple different
blockchain systems, so we are not able to test them out accordingly.

1.6 Thesis Organization

This thesis is organized into five chapters, as follows:
• Chapter 1 concentrates on the research value and market meaning of this

thesis, then briefly introduces the concept of cross-chain communication.
• Chapter 2 studies the background of the cross-chain project by classifying

different manifestations of cross-chain communication as well as pointing out the
problems cross-ledger communication are facing.



1.6. THESIS ORGANIZATION 5

• Chapter 3 focuses on the theoretical solutions that will address the difficul-
ties, discusses the communication process of various cross-chain projects based on
different group rules.

• Chapter 4 puts efforts in analyzing the market demand situation, and discusses
the applications that could be adopted. Besides, this chapter also compares the
technology development of some representative projects.

• Chapter 5 summarizes the findings during the research and suggests several
ideas for related future work.

• Appendix A contains a comparison table that evaluates 20 cross-chain projects
from several valuable aspects.

• Appendix B lists implementation code pieces with essential functions explained
and the utilization of smart contracts, for further test usage.





Chapter 2

Literature Study

This chapter gives a concept background towards cross-chain technology in Sec-
tion 2.1, characterizes the specific manifestation of cross-chain projects in Sec-
tion 2.2, and addresses the cross-chain realization difficulties into 5 parts in Sec-
tion 2.3.

2.1 Background

2.1.1 What is cross-ledger?
With the development of blockchain technology, many different chains have been
born, and the information isolation of many chains inevitably restraint the circu-
lation of value in blockchain systems. It turned out that there is a need for a
technology that can work with different blockchains and become the bridge con-
necting them.

Cross-ledger (or cross-chain), in the narrow sense, is the process of asset/data in-
teroperability between two relative independent blockchains.

Traditional ICT field defines the interoperability as the ability to share and utilize
information between different ICT systems or modules in a reliable way [3]. While
Vitalik Buterin mentioned in Chain Interoperability [4] that interoperability in
the blockchain area mainly describes the ability of assets exchange, information
intercommunication, and atomic transactions between various blockchains. The
blockchain interoperability can be achieved by introducing the third party without
modifying the original chains.

2.1.2 Evolution of Cross-chain
As shown in Figure 2.1, it has not been a short period for Ripple to release the
Interledger Protocol(ILP) [5] in 2012 since the advent of Bitcoin Network in

7



8 CHAPTER 2. LITERATURE STUDY

2009. Interledger protocol proposed a cross-ledger interoperability scheme for the
first time in the blockchain area, which enables cross-ledger transfers through third-
party notaries. In 2014, the BlockStream team, founded by the Bitcoin core devel-
oper group, first proposed a Pegged Sidechains cross-chain interaction scheme,
introducing a sidechain with a two-way peg to achieve cross-chain asset transfer.
Soon in 2015, the Bitcoin Lightning Network [6] adopted a Hashed Timelock
mechanism to implement a fast transaction channel off the Bitcoin main chain. In
2016, the BTC-Relay [7] solution was released, and the one-way cross-chain com-
munication from Bitcoin to Ethereum was realized based on the relay cross-chain
scheme. In the same year, Vitalik Buterin made a comprehensive and in-depth
analysis of blockchain interoperability issues. In 2017, Polkadot [8] and Cosmos [9]
first proposed a solution for building a cross-chain network infrastructure platform.
Now the Cosmos hub blockchain has launched in March 2019.

Figure 2.1: Cross-chain development tree

2.2 Cross-chain manifestation

So far we know, current public blockchain is a self-adaptive, relatively closed dis-
tributed system. Although the system allows new nodes to join and old nodes exit,
it is still hard to be compatible with external systems because of its fault-tolerant



2.2. CROSS-CHAIN MANIFESTATION 9

mechanism.

In a way, there are two main value/data interoperability implementations between
chains:

1. Inter-chain asset exchange:
It usually refers to asset swapping between different users on both chains.
However, the total amount of assets in each chain does not increase or de-
crease. Instead, the ownership of the assets has changed. The process of this
change needs to occur synchronously on both chains.

Figure 2.2: Inter-chain exchange diagram

This diagram briefly describes the situation when Alice wants to use X
amount of chain M’s tokens to exchange for Bob’s Y amount of chain N’s
token. Eventually, Bob’s token in chain N swaps to Alice’s address in chain
N. Similarly, Alice’s token swaps to Bob’s address located in chain M.

2. Inter-chain asset transfer (one/two-way):
Compared with the consistency in the total assets number of asset exchange,
the transfer has a change of asset value, which is manifested in the increase
or decrease of the available assets in each chain. For example in Figure 2.3,
the scenario is Alice wants to transfer X number of tokens from chain M to



10 CHAPTER 2. LITERATURE STUDY

chain N. As a result, chain M send X amount of token to a locked address in
original chain, in turn, chain N generates an equal amount of tokens of itself
in a certain address for future uses. Thus, the transfer of this asset succeed.

Figure 2.3: Inter-chain transfer diagram

For now, researches and applications of cross-chain are mainly focused on these
two manifestations. Some projects have proposed the concept of cross-chain smart
contracts, which is similar to the realization of cross-chain asset transfer in terms
of technical implementation.



2.3. DIFFICULTIES 11

2.3 Difficulties

The number one feature in the blockchain is immutability, and every record must
be accurate to protect the value. Hence, in the cross-chain project, the key point is
to ensure the accuracy of each transaction. There are many obstacles cross-chain
need to encounter. To sum up, the following are several key points:

• How to ensure the atomicity of transactions.
The transactions should be atomic, that is, cross-chain transactions either
occur or do not occur. Otherwise, the inconsistency and ""out-of-sync"" sta-
tus of the two chains will become the most significant system vulnerabilities
in cross-chain transactions, and the security of both systems will be threat-
ened. The consistency is the fundamental guarantee for realizing cross-chain
transactions, and it is also a keystone that must be solved in cross-chain
transactions.

• How to complete the confirmation of the transaction for other
chains.
The confirmation of the transaction contains two levels of problems. One is
to confirm that the transaction has occurred, wound up and written into the
right block. Second is to make sure the system has approved the transaction
with enough blocks. In this way, the probability of invalidation of the trans-
action due to system reconfiguration will be very low. The blockchain system
itself is relatively isolated, lacking the mechanism to obtain external infor-
mation actively. Therefore, it is not an easy task to confirm the transaction
status of another chain. It can be said that it is one of the core difficulties of
cross-chain transactions.

• How to ensure that the total assets of the two chains remain un-
changed.
In the scenario of asset exchange, the assets of the two chains are not sub-
stantially exchanged, so this type of situation does not change the total assets
of each chain. However, in the scenario of asset transfer, the number of avail-
able assets in each chain will be altered. The total assets of both chains
can remain unchanged only when the cross-chain transactions are accurately
recorded, and atomically occurred.

• How to ensure the independent security of the two chains.
When two chains interoperate, they inevitably affect each other with depen-
dency issues. It is a considerable problem that how to ensure blockchain
system security during the process of cross-chain communications. If the se-
curity issue cannot be isolated, then one attacked chain will affect the entire
cross-chain network.



12 CHAPTER 2. LITERATURE STUDY

• How to realize multiple chains interoperability.
Take the history of the computer network as a reference. The independent
blockchain network will eventually embark on the future of interconnection.
How to link these existing and future blockchain networks to be unified into
one whole network will be one of the most important issues of the future
cross-chain network.

2.4 Summary

This chapter introduced a thorough background study of the cross-chain research
area. It briefly reviewed the history of cross-chain development and outlined the
importance of the growing technology of cross-chain. Two main manifestations of
cross-chain transactions were proposed to give a classification standard for Chapter
3 project study. Chapter 2 also described the critical difficulties that cross-chain
projects are facing. Some of them will be discussed in the following chapters.



Chapter 3

Projects Classification

Chapter 3 presents the corresponding solutions in Section 3.1 based on the difficul-
ties mentioned in Chapter 2. Followed by the case study of eight well-known cross-
chain projects in cross-chain industry in Section 3.2. By illustrating the working
theory and new terms that purposed, we will be familiar with the scheme categories
defined by Section 3.1.

3.1 Solutions

Based on what we discussed about the difficulties in the previous sections, some
solutions came up with multiple cross-chain projects. The following paragraphs will
illustrate them thoroughly.

3.1.1 Ensure the atomic of transactions
3.1.1.1 Atomic swaps

An atomic cross-chain swap [10] is the basic theoretical framework for multiple par-
ties exchanging assets across multiple blockchains. Atomic operations in computer
science ensure every exchange either success or failure, no third intermediate state.
For a more intuitive introduction to the atomic swap protocol, we assume an ex-
change scenario shown in Figure 3.1:

1. Assume Alice has 1 BTC on Bitcoin while Bob has 20 ETH on Ethereum.
Alice wants to exchange Bob’s 20 ETH for 1 BTC. Both Alice and Bob have
wallet addresses on both Bitcoin and Ethereum.

2. To start this transaction, Alice needs to randomly generate a key K, which
is known only to Alice. Then she initiates a 1 BTC on-chain transaction
(transaction 1O) to Bob. The transaction can only be finished when Alice
obtains the signature of Bob and provides the key K.

13



14 CHAPTER 3. PROJECTS CLASSIFICATION

Figure 3.1: Atomic swaps diagram

3. Before broadcast transaction 1O, Alice will first broadcast a retracement (trans-
action 2O). If transaction 1O does not receive the correct key or signature
within 48 hours, the amount paid by that transaction will be returned to
Alice. Transaction 2O must be signed by Alice and Bob after broadcasted to



3.1. SOLUTIONS 15

take effect. At the same time, Alice will only broadcast the transaction 1O to
the network if transaction 2O is successfully validated.

4. Bob now sees the transaction 2O sent by Alice. If Bob agrees, he will sign the
transaction 2O, of course, Alice will also complete the signature so that the
retracement will take effect. Then Alice will broadcast the transaction 1O to
the whole network.

5. Bob can only get the value K after he pays Alice with 20 ETH. Hence Bob
initiates transaction 3O on Ethereum to pay Alice 20 ETH. These 20 ETH
are only available if Alice enters the decrypted key K and attaches Alice’s
signature. To prevent Alice from denying, Bo";"""date"",""2020-02-28T07:50:07Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""1"",""4"",""12"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.6""
""xmp:CreatorTool"",""LaTeX with hyperref""
""pdf:docinfo:title"",""""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dcterms:created"",""2020-02-25T07:49:54Z""
""language"",""en""
""Last-Modified"",""2020-02-28T07:50:07Z""
""dcterms:modified"",""2020-02-28T07:50:07Z""
""dc:format"",""application/pdf; version=1.6""
""title"",""""
""xmpMM:DocumentID"",""uuid:47a6f416-44bb-4c20-a88a-6ffe20b5aa4e""
""Last-Save-Date"",""2020-02-28T07:50:07Z""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2020-02-28T07:50:07Z""
""meta:save-date"",""2020-02-28T07:50:07Z""
""pdf:encrypted"",""false""
""dc:title"",""""
""xmp:CreateDate"",""2020-02-25T08:49:54Z""
""modified"",""2020-02-28T07:50:07Z""
""Content-Length"",""4310010""
""pdf:hasMarkedContent"",""false""
""Content-Type"",""application/pdf""
""xmp:ModifyDate"",""2020-02-28T08:50:07Z""
""xmp:MetadataDate"",""2020-02-28T08:50:07Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""pdf:producer"",""Adobe Acrobat Pro DC 19.12.20035""
""meta:creation-date"",""2020-02-25T07:49:54Z""
""created"",""2020-02-25T07:49:54Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""86""
""Creation-Date"",""2020-02-25T07:49:54Z""
""resourceName"",""FULLTEXT01.pdf""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""298"",""0"",""336"",""1783"",""1840"",""1031"",""1009"",""905"",""174"",""1683"",""860"",""226"",""1612"",""2106"",""1713"",""1215"",""674"",""0"",""1291"",""1178"",""941"",""489"",""2072"",""765"",""1251"",""318"",""1989"",""1023"",""1319"",""820"",""2258"",""1325"",""1380"",""2123"",""1944"",""830"",""346"",""865"",""2285"",""864"",""786"",""911"",""1306"",""689"",""899"",""2144"",""467"",""993"",""639"",""696"",""1481"",""2197"",""1733"",""2027"",""65"",""1836"",""151"",""1450"",""2028"",""669"",""92"",""1347"",""1675"",""0"",""1670"",""2088"",""1462"",""1802"",""780"",""0"",""508"",""839"",""946"",""1043"",""929"",""952"",""986"",""391"",""718"",""1232"",""1412"",""1060"",""1670"",""513"",""0"",""31""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""producer"",""Adobe Acrobat Pro DC 19.12.20035""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""Adobe Acrobat Pro DC 19.12.20035""
""pdf:docinfo:created"",""2020-02-25T07:49:54Z""
";https://scholar.google.ch/scholar?start=820&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098765-102;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;An Accountable Decryption System Based on Privacy-Preserving Smart Contracts;R Li, Q Wang, F Liu, Q Wang, D Galindo ; International Conference on …, 2020  Springer;;"… private state with the initial state \(\mathsf {s}\), \mathcal {S'}\) is the new state set after the specified

operations, \(\mathcal {T}\) means the publicly visible transactions that can trigger the execution

of a contract, and \(\mathbb {B}\) represents the blockchain oracle which provides …";Cité 1 fois;Les 3 versions;[PDF] rujia.uk;http://rujia.uk/ppt/isc20.pdf;;;https://scholar.google.ch/scholar?start=650&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098795-180;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;[PDF][PDF] Yield Zone;YZZ Team ; yzz.fm;;"… not participate in the price formation of Oracle. No matter whether the transaction … bitcoin network,

it is difficult for other blockchain applications that want to try to … The Page 22. cryptocurrency

uses the workload proof mechanism to issue new currency, and …";Autres articles;Version HTML;[PDF] yzz.fm;https://www.yzz.fm/YZZ%20White%20Paper%202.1.pdf;;;https://scholar.google.ch/scholar?start=720&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098765-105;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;The Need to Use a Hash Function to Build a Crypto Algorithm for Blockchain;O Belej, K Staniec, T Wi?ckowski ; International Conference on …, 2020  Springer;;"… It happens and vice versa, when a block cipher becomes the basis of crypto-transformation used …

So, although the random oracle does not exist in real life, it is to be hoped … functions discussed

above, its application is important in the task of protecting blockchain information from …";Autres articles;;null;;;;https://scholar.google.ch/scholar?start=650&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098734-35;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;[PDF][PDF] Johdanto älysopimuksiin;P Piironen ;2020 theseus.fi;;"… In this thesis, an extensive independent research into smart contract and blockchain

technologies was conducted … Smart contracts have been emerging from rapidly evolving

blockchain technology which is under constant de- velopment …";Autres articles;Version HTML;[PDF] theseus.fi;https://www.theseus.fi/bitstream/handle/10024/336650/Piironen_Petteri.pdf?sequence=5;"
 
Petteri Piironen 

Johdanto älysopimuksiin

Metropolia Ammattikorkeakoulu 

InsinÜÜri (AMK) 

Tieto- ja viestintätekniikka 

InsinÜÜrityÜ 

26.4.2020



 

Tekijä 
Otsikko 

Sivumäärä 
Aika

Petteri Piironen 
Johdanto älysopimuksiin 

45 sivua + 1 liite 
26.4.2020

Tutkinto InsinÜÜri (AMK)

Tutkinto-ohjelma Tieto- ja viestintätekniikka

Ammatillinen pääaine Mediatekniikka

Ohjaaja Yliopettaja Kari Aaltonen

InsinÜÜrityÜssä tutkittiin älysopimuksia uutena teknologiana ja perehdyttiin niiden 
käyttÜtarkoituksiin, hyÜtyihin ja haasteisiin. TyÜ toteutettiin itsenäisenä tutkimukse-
na. 

InsinÜÜrityÜn tavoite on tarjota lukijalle kattava käsitys lohkoketjuteknologioiden pe-
rusteista, älysopimusteknologiasta ja älysopimusten kehittämisestä. InsinÜÜrityÜssä 
tehtyä tutkimusta voidaan hyÜdyntää oppimateriaalina lohkoketjuteknologioiden ja 
älysopimusten opetuksessa. 

TyÜssä perehdytään lohkoketjuteknologian perusteisiin, älysopimuksiin ja niiden 
käyttötarkoituksiin, hyötyihin sekä tämänhetkisiin rajoitteisiin. Älysopimukset ovat 
kehittyneet lohkoketjuteknologian pohjalta, ja ne ovat toistaiseksi uusi ja vilkkaan 
kehityksen alla oleva teknologia. Älysopimukset ovat sopimuksia koodin muodossa, 
johon voidaan määritellä lukuisia ehtoja ja määritteitä, joilla saavutetaan nykyisiä 
sopimusmalleja luotettavampi malli, jossa ei tarvita välikäsiä tai sovittelijoita. 

InsinÜÜrityÜssä toteutettiin myÜs mallisopimus Solidity-ohjelmointikielellä Remix web 
-kehitysympäristÜssä. Mallisopimuksen on tarkoitus havainnollistaa älysopimusten 
kehityksen kulku ja niihin vaadittaviin tyĂśkaluihin ja teknologioihin tutustuminen.   

TyĂśn tuloksena saatiin kattava esittely lohkoketjuteknologian perusteista, 
älysopimuksista ja niiden käyttÜtarkoituksista, hyÜdyistä ja rajoitteista sekä kehitetti-
in mallisopimus, jonka avulla havainnollistetaan ja opastetaan älysopimusten kehi-
tys vaihe vaiheelta.

Avainsanat älysopimus, lohkoketju, Ethereum, kryptografia, automaa-
tio, bitcoin 

 



 

Author 
Title 

Number of Pages 
Date

Petteri Piironen 
Introduction to Smart Contract technologies 

45 pages + 1 appendix  
26 April 2020

Degree Bachelor of Engineering

Degree Programme Information and Communications Technology

Professional Major Media Technology

Instructor Kari Aaltonen, Principal Teacher

In this thesis, an extensive independent research into smart contract and blockchain 
technologies was conducted. The purpose of this final year project was to provide 
answers to smart contract benefits, use cases and to bring forth the current issues 
that smart contract technologies need to overcome. 

The study also aims at giving a broad understanding into blockchain and smart con-
tract technologies and to also provide instructions for smart contract development 
using modern development tools. The research carried out in this thesis also serves 
as material for any future courses in these technologies. Smart contracts have been 
emerging from rapidly evolving blockchain technology which is under constant de-
velopment. Smart contracts are programmable, deterministic and automatic forms 
of contracts that do not require a middleman, as they can be fully trusted to execute 
on the terms and functions written in the contract. 

This thesis also includes an example contract written in Solidity in Remix-web inte-
grated development environment. The goal of this example contract is to provide the 
required technologies and steps to develop a functioning smart contract on the 
Ethereum blockchain. 

The results of this study offer an extensive introduction to blockchain and smart con-
tract technologies and smart contract development. This thesis also provides an-
swers to smart contract benefits, use cases and some of the current issues that 
smart contracts are currently facing.

Keywords smart contract, blockchain, Ethereum, cryptography, au-
tomation, bitcoin



 

Sisällys 

Lyhenteet 

Liitteet  
Liite 1. Haastattelu  

1. Johdanto 1 

2. Lohkoketjuteknologian perusteet 2 

2.1. Lohkoketjun konsepti 2 
2.2. Lohkoketjujen kryptografia 4 
2.3. Lohkon datarakenne 10 
2.4. Proof-of-Work-protokolla 11 
2.5. Proof-of-Stake-protokolla 13 
2.6. Kryptovaluutta 14 

3. Älysopimusten perusteet 15 

3.1 Konsepti 15 
3.2 HyĂśdyt 16 
3.3 Ethereum-ekosysteemi 19 
3.4 Oraakkelit datan varmentamisen ratkaisuna 19 
3.5 KäyttÜtarkoituksia 22 
3.6 Älysopimusten haasteet 24 
3.7 Tulevaisuuden näkymät 27 

4. Älysopimuksen toteutus Solidity-kielellä 28 

4.3 Sopimuksen rakenne 32 
4.4 Mallisopimuksen toteutus 36 
4.5 Tulokset 39 

5. Yhteenveto 42 

Lähteet 43



 

Lyhenteet 

BTC Bitcoin. Vuonna 2009 Satoshi Nakamoton julkaisema kryptovaluutta. 

ETH Ethereum. Lohkoketjuteknologiaan perustuva hajautettu avoimen 
lähdekoodin tietojenkäsittely-ympäristÜ, jolla on oma, erillinen lohkoketju. 

dapp Decentralized App. Hajautettu sovellus, jonka palvelinpuolen koodi pyĂśrii 
hajautetulla vertaisverkolla. Hajautettu sovellus voi muuten näyttää ja 
toimia täysin muiden sovellusten tavoin. 

EVM Ethereum Virtual Machine. Ethereumin tarjoama hajautettu virtuaalikone, 
joka pystyy suorittamaan ohjelmakoodia kansainvälisen tietoverkon avul-
la. 

P2P Peer-to-Peer. Vertaisverkko, jolla ei ole kiinteitä palvelimia tai käyttäjiä, 
vaan jokainen verkkoon kytketty taho toimii palvelimena ja asiakkaana 
muille tahoille. 

PoW Proof-of-Work. Proof-of-work konsensusmekanismi, jolla kryptovaluutto-
jen kontekstissa louhijat palkitaan sen perusteella, kuka on lÜytänyt 
ratkaisun ja pystynyt lisäämään lohkonsa lohkoketjuun. Tätä ratkaisua 
kutsutaan nimellä “proof of work”. 

PoS Proof-of-Stake. toisenlainen konsensusmekanismi, jolla kryptovaluutojen 
kontekstissa seuraavan lohkon luoja valitaan erinäisillä kriteereillä, kuten 
satunnaisuudella ja osuuden vauraudella sekä iällä. 

ICO Initial Coin Offering. Englanninkielinen termi joukkorahoituksen muodolle, 
joka keskittyy kryptovaluuttoihin kasvuyritysten pääoman lähteenä. 

IDE Integrated Development Environment. OhjelmointiympäristÜ, jolla ohjel-
moija toteuttaa ja suunnittelee ohjelmistoa. OhjelmointiympäristÜssä 
yhdistyvät tyypillisesti tekstieditori ja ohjelmointikielen kääntäjä. 

HTTPS Hypertext Transfer Protocol Secure. HTTP-protokollan ja TLS/SSL-pro-
tokollan yhdistelmä, jota käytetään suojattuun tiedonsiirtoon internetissä. 



 

SHA-256 Secure Hash Algorithm. Yhdysvaltain kansallisen turvallisuusviraston ke-
hittämä salausalgoritmi, jota käytetään mm. bitcoinin transaktioiden 
vahvistamiseen. 

SAT Satoshi. Bitcoin-kryptovaluutan rakenteellinen osa, joka on sadas-
miljoonasosa yhtä kokonaista bitcoinia. 

ERC20 Ethereum Request For Comments 20. ERC20, Ethereum-verkon pro-
tokolla joka määrittää tiettyjä sääntÜjä ja standardeja Ethereum-verkon 
rahakkeisiin. Luku 20 viittaa tiettyyn standardiin. 

API Application Programming Interface. API, ohjelmointirajapinta, määritelmä, 
jonka mukaan eri ohjelmat voivat tehdä pyyntÜjä ja vaihtaa tietoja 
keskenään.  



1

1. Johdanto 

InsinÜÜrityÜn tavoitteena on perehtyä älysopimuksiin uutena teknologiana ja arvioida 
niiden tuomia vaikutuksia tulevaisuuden kannalta sekä tarjota kattava esittely 
lohkoketjuteknologiasta, kryptografiasta, älysopimusten perusteista ja käyttÜtarkoituk-
sista. TyÜssä toteutetaan myÜs malliälysopimus Solidity-ohjelmointikielellä. 

Sopimukset ovat perinteisesti käsitettynä kahden osapuolen välille asetettuja 
määritelmiä tai lupauksia, joita käytetään pääasiassa kaupankäynnissä ja taloudessa, 
mutta niille on käyttÜtarkoituksia myÜs ihmissuhteissa, kuten avioliitoissa. Sopimukset 
ovat tärkeitä valtiotasolla, sillä sopimukset ovat kautta aikojen olleet kapitalististen val-
tioiden peruspiirre. Sopimukset ovat vapaan markkinatalouden perusrakenne riip-
pumatta siitä, paneeko ne täytäntÜÜn hallitus vai jokin muu hallitseva taho. [1.]  

Älysopimus on termi, jolla kuvataan koodia, joka automaattisesti suorittaa kaiken tai 
osia sopimuksesta, joka on tallennettu lohkoketjupohjaiselle alustalle. Historiallisesti 
sopimuksen jokaista vaihetta ovat valvoneet ja hallinnoineet ihmiset, oli kyseessä 
sopimuksen luominen, sovittelu tai täytäntöönpano. Älykkäiden sopimusten konsepti 
mahdollistaa luotettavien sopimusluontoisten tapahtumien, kuten rahallisten transak-
tioiden suorittamisen ilman kolmannen osapuolen valvontaa tai osallistumista. 
Lohkoketjuteknologian myÜtä nämä sopimukset ovat esillä julkisesti jaetussa tilikirjas-
sa, josta sopimus voidaan varmentaa koska tahansa, eikä sen sisältÜä voi 
lohkoketjuteknologian luonteen mukaan muuttaa. Älysopimusten myötä ollaan siir-
tymässä omistajuuden määrittelyn ylle, sillä omistajuuden lisäksi voidaan määritellä 
omistukseen liittyviä ehtoja, jotka tulevat tietynlaisten sopimustyyppien mukana, kuten 
arvopapereiden tai obligaatioiden. Obligaatiot sisältävät tietynlaisia ehtoja, kuten koron 
tuottoa tai ajoittaista uudelleenmaksua tai voi seurata rangaistuksia, mikäli tiettyjä 
velvoitteita ei noudateta. Näitä ehtoja voidaan määritellä älysopimuksiin ja automatisoi-
da tarpeen mukaan. Älysopimuksiin voidaan määritellä koodilla erinäisiä sääntöjä liit-
tyen sopimuksen luonteeseen, kuten varainsiirto taholta A taholle B tai sopimuksen yk-
sityisyyteen liittyviä ominaisuuksia, joihin perehdytään tässä tyÜssä tarkemmin. 



2

2. Lohkoketjuteknologian perusteet 

Tässä luvussa käydään läpi lohkoketjuteknologian peruskäsitteet ja siihen liittyvät 
teknologiat ja protokollat. 

2.1. Lohkoketjun konsepti 

Lohkoketju (engl. blockchain) on monelle tuttu termi, vaikkei sen teknisestä puolesta 
välttämättä ymmärretä tarkemmin. Lohkoketjuteknologian merkittävin toteutus julkaisti-
in vuonna 2008 artikkelissa Bitcoin: A Peer-to-Peer Electronic Cash System, jossa ke-
hittäjä Satoshi Nakamoto (alias) julkisti bitcoin avoimen lähdekoodin [2]. 

Lohkoketjuteknologialla kuvataan konseptia, jolla voidaan tallentaa tietoa niin sanottui-
hin lohkoihin, jotka yhdessä muodostavat julkisen rekisterin, tietynlaisen tilikirjan kaik-
ista ketjussa tapahtuneista tapahtumista ja tiedoista. Lohkoketju koostuu lohkoista, jot-
ka ovat yhdistettynä toisiinsa kryptografisin menetelmin muodostaen listamaisen raken-
teen, kuten kuvassa 1. 

Kuva 1. Lohkoketju visualisoituna. 

Tämä lista jaetaan kaikkien osallistujien kesken, jolloin tuloksena on hajautettu ver-
taisverkko, joka ei luota keskitettyyn palvelimeen tai toimijaan, johon kaikki osallistujat 
olisivat yhdistettynä. Jaetun listan voi täten tarkastaa mistä tahansa lähteestä, mikä 
mahdollistaa anonyymin luottamuksen osallistujien välillä. Hajautettu malli on luotet-
tavampi kuin keskitetty malli, jossa kaikki keskitettyyn toimijaan yhdistetyt tahot ovat 
riippuvaisia keskitetyn toimijan luotettavuudesta. Hyvä esimerkki perinteisestä keskite-
tystä mallista on esimerkiksi pankkien toiminta, jossa kaikki maksuliikenne kulkee 
pankin kautta, kuten kuvassa 2. 



3

 

Kuva 2. Keskitetty malli, jossa kaikki toimijat nojaavat yhteen keskeiseen tahoon. 

Hajautetussa mallissa jokaisella osapuolella on sama tilikirjan versio, joka päivittyy au-
tomaattisesti silloin, kun ketjuun kirjataan uusia tapahtumia. Tämän myÜtä jokaisen 
transaktion pätevyys voidaan varmentaa kaikkien osallistuvien tahojen kautta, ja mikäli 
transaktio vastaa sitä, mitä kaikkien tilikirjaan on kirjattu, voidaan turvallisesti olettaa 
sen olevan pätevä. Hajautettu malli ei nojaa keskitettyyn toimijaan ja on täten luotet-
tavampi ei pelkästään moraalisesti, vaan myÜs toiminnallisesti, sillä yhden toimijan 
kaatuessa mikään informaatio ei enää liiku verkossa. Jos taas hajautetussa mallissa 
yksi tahoista kaatuu, se ei vaikuta verkon toimintaan millään tavalla (kuva 3). 

 

Kuva 3. Hajautettu malli, jossa yhdistetyt tahot eivät nojaa keskeiseen toimijaan, vain jakavat 
kaiken tiedon keskenään. 



4

Jokainen lohko sisältää dataa edeltävästä lohkosta, kuten kryptografisen hajautusalgo-
ritmin eli tiivisteen, aikaleiman sekä transaktiodataa. Lohkoketju voi haarautua uusiin 
ketjuihin, jolloin voimaan jää se haara, jonka lohkojen yhteenlaskettu vaikeustaso on 
suurempi. Poisjäävän haaran lohkoja kutsutaan orpolohkoiksi. Lohkoketjuteknologia 
mahdollistaa myÜs sen, ettei lohkoketjun historiaa voi muuttaa, sillä se vaatisi lohkon 
uudelleenluomista ja siihen liittyvien aiempien lohkojen uusiksi luomista. Tämä on yksi 
lohkoketjuteknologian vahvimmista puolista, sillä se estää mahdollisen datan väären-
tämisen. 

Bitcoinin lohkoketjussa jokainen kahden käyttäjän välinen transaktio tallennetaan 
lukuisten muiden samantyyppisten transaktioiden kanssa yhteen lohkoon, joka liitetään 
jatkuvaan lohkoketjuun. Bitcoinin transaktioluontoisessa kontekstissa lohkoketjun 
hyÜdyt tulevat parhaiten esille, sillä transaktioissa ei tarvita välikäsiä ja jokainen 
transaktio jää muiden todistettavaksi ja julkiseksi lohkoketjussa olevaan tilikirjaan. 

2.2. Lohkoketjujen kryptografia 

Yleisesti lohkoketjujen yhteydessä kryptografiaan viitattaessa tarkoitetaan kryptaamista 
eli salausta, joka on prosessi, jossa viesti tai tieto muunnetaan muotoon, jossa vain 
oikeutetut osapuolet voivat lukea viestin. Yleisin ja tunnetuin näistä on Public-key en-
cryption, jossa kahden osapuolen välinen kommunikaatio tapahtuu salatusti julkisen ja 
yksityisen avaimen avulla. Tätä menetelmää on helppo lähestyä esimerkillä, jossa Bob 
lähettää Alicelle viestin, jonka hän kryptaa omalla julkisella avaimella ja Alicen yksi-
tyisellä avaimella. Alice purkaa viestin kryptauksen omalla julkisella avaimella ja Bobin 
yksityisellä avaimella. Milläkään muulla taholla, jolla ei ole pääsyä yksityisiin avaimiin, 
ei myÜskään ole pääsyä viestin sisältÜÜn (kuva 4). 

 

Kuva 4. Public-key encryption, jossa kahden osapuolen välinen kommunikaatio voidaan salata 
ja avata osapuolten omistamien avainten avulla [26]. 



5

Hajautusfunktio 

Lohkoketjuille yleisin kryptaamisen muoto on Hash Function eli hajautusfunktio. Hajau-
tusfunktio on matemaattinen algoritmi, jota hyÜdynnetään jonkin konseptin, kuten 
sanan, muuttamiseksi ennaltamäärättyyn koodiin. Mikäli jokin osa sanasta muuttuu, 
sitä mukaa myÜs koodi muuttuu. Täten jokaiselle muunnetulle objektille on oma hash 
eli tiiviste. Kuva 5 havainnollistaa erilaisten merkkijonojen tiivisteiden luomisen. 

Kuva 5. Esimerkkiarvoja SHA-256-tiivisteille. Yksikin muutos merkkijonossa saa koko tiivisteen 
muuttumaan. 

Lohkoketjuissa yleisin hajautusfunktio  on Yhdysvaltojen kansallisen turvallisuusviras-
ton eli NSAn kehittämä Secure Hash Algorithm, eli tiivistefunktio josta käytetään lyhen-
nettä SHA. SHA-perheeseen kuuluu useita eri iteraatioita algoritmista, mutta tässä 
tapauksessa perehdytään SHA-256 -algoritmiin. SHA-256 käytetään mm. bitcoinin 
transaktioissa ja Proof-of-Work-ja Proof-of-Stake-protokollissa. SHA-256 -algoritmin 
perusominaisuus on se, että riippumatta syÜtetyn konseptin pituudesta, tulos on aina 
256 bittiä pitkä. Tulos usein esitetään heksadesimaalina, jossa tapauksessa pituus on 
64 merkkiä. [4.] 

SyĂśte Tiiviste

Merkkijono 48fbfc83242b688fb60fad0f82b5cf65fef4a573d9b0c1
3955b84a9ebbc6798c

merkkijono d72149fdc8b2eaa2fbd1eb7a23b89d6ba42abaa09c1
9fca483908875311500f1

Merkkijooono 92467eea9dbcfeb6dcd0c562f54bc8192b209ec688aa
42ed8d9c279b0d8a5a90



6

  

Kuva 6. Hajautusfunktio visualisoituna. SyÜtetyn merkkijonon pituudella ei ole väliä tuloksen 
kannalta, tulos on aina yhtä pitkä. [5, s. 75.]. 

Digitaaliset allekirjoitukset 

Digitaalisella allekirjoituksella tarkoitetaan sähkÜiseen viestiin tehtyä aiemmin mainit-
tuun julkisen avaimen formaattiin perustuvaa allekirjoitusta, jolla varmennetaan viestin  
tai datan sisältÜ ja allekirjoittajan henkilÜllisyys [6]. Mikäli viestiä muutettaisiin, allekirjoi-
tus paljastaisi väärennÜksen. Viestiä muutattaessa sen tallentamisen tai siirtämisen 
aikana tai väärää henkilÜllisyyttä käytettäessä matemaattinen allekirjoitus ei enää täs-
mää. Digitaalisia allekirjoituksia kuten kuvassa 6 hyÜdynnetään yritysten asiakirjoissa 
ja sähkÜposteissa, ja ne ovat laillisesti päteviä. Digitaalisia allekirjoituksia voidaan 
soveltaa älysopimuksissa osapuolten varmistamiseen. 



7

  

Kuva 7. Digitaalisen allekirjoituksen prosessi [27]. 

Digitaaliset allekirjoitukset, aivan kuten käsin kirjoitetut allekirjoitukset, ovat ainutlaatu-
isia. Kun allekirjoittaja digitaalisesti allekirjoittaa dokumentin, allekirjoitus luodaan käyt-
täen allekirjoittajan yksityistä avainta. Matemaattinen algoritmi toimii salauksena ja luo 
dataa, joka vastaa allekirjoitettua dokumenttia, jota kutsutaan tiivisteeksi ja joka salaa 
allekirjoitetun datan. Tulokseksi jäänyt tiiviste on digitaalinen allekirjoitus, jolle on an-
nettu lisäksi aikaleima, joka kertoo, milloin se on luotu. Tämä varmistaa sen, että jos 
dokumenttia muutetaan allekirjoittamisen jälkeen, digitaalinen allekirjoitus on 
epäpätevä kuten kuva 8 havainnollistaa. 



8

 

Kuva 8. Digitaalisen allekirjoituksen varmistaminen [27]. 

Merkle-puu 

Kyrptografiassa ja lohkoketjuissa esiintyvä tiivistepuu tai Merkle-puu on puuta muistut-
tava rakenne, jonka avulla voidaan tallentaa suuria määriä dataa tehokkaasti ja data 
voidaan varmentaa turvallisesti. Merkle-puu mahdollistaa sen, että lohkoketjuun ei 
tarvitse luoda yhtä jättimäistä ylätunnistetta, johon kaikki lohkon transaktiot tallentuisi-
vat. Merkle-puu mahdollistaa transaktioiden varmistamisen ns. ylhäältä alas, jolloin 
syntyy useita puun haaroja, jotka ovat kooltaan pienempiä ja täten vaativat pienempää 
laskentatehoa. Rakenteessa tiivisteitä luodaan alhaalta ylÜspäin, jolloin ensimmäiset 
tiivisteet ovat yksittäisten siirtojen tiivisteitä. Merkle-puun rakenteessa näitä tiivisteitä 
kutsutaan lehdiksi. MyÜhemmät ei-lehtitiivisteet luodaan yhdistämällä kaksi aiempaa 
tiivistettä, joita kutsutaan oksiksi. Lopulta jäljelle jää yksi tiiviste, jota kutsutaan juureksi. 
Kuvassa 9 havainnollistuu Merkle-puun rakenne. L-alkuiset datalohkot muodostavat 
tiivisteet 0-0, 0-1, 1-0 ja 1-1, joita kutsutaan lehdiksi. Seuraavaksi tiivisteistä 0-0 ja 0-1 
muodostetaan tiiviste 0, ja tiivisteistä 1-0 ja 1-1 luodaan tiiviste 1, joita kutsutaan oksik-
si. Lopulta tiivisteet 0 ja 1 muodostavat Merkle-juuren.  



9

 

Kuva 9. Merkle-juuren tiivisterakenne. Data muodostaa lehdet, jotka muodostavat oksat jotka 
yhdessä muodostavat puun juuren [28]. 

Merkle-puun avulla voidaan yksinkertaisesti todentaa, onko jokin tieto puussa. Toden-
nus kulkee ylhäältä alas. Tämä mahdollistaa sen, ettei koko puuta tarvitse ladata, kuten 
kuvasta 10 voidaan todeta.  

Kuva 10. Merkle-juuren rakenteesta yksittäisen tiedon varmentaminen [8]. 

Merkle-puulle on myÜs ominaista sen muuttumattomuus, eli mikäli jonkin rakenteessa 
olevan tiivisteen tietoa muutetaan, muuttuvat kaikki puun ylemmät oksat. Merkle-puun 
suurimmat hyÜdyt ovat sen nopeus, tehokkuus ja vähäinen tallennustilan käyttÜ. 



10

2.3. Lohkon datarakenne 

Kaikki transaktiodata on pysyvästi tallennettu tiedostoihin, joita kutsutaan lohkoiksi. Ne 
voidaan kuvitella yksittäisiksi sivuiksi pÜytäkirjassa tai osakkeen tilikirjassa. Nämä 
lohkot järjestetään lineaariseen järjestykseen suhteutettuna aikaan ja ne muodostavat 
lohkoketjun. Uusien lohkojen transaktioiden prosessoiminen syntyy louhinnan yhtey-
dessä, samoin kuin itse lohkojen luominen. Jokainen lohko sisältää oletukseltaan 
aikaleiman, viimeaikaisten transaktioiden tallenteet ja viittauksen edelliseen lohkoon. 
Lohkosta lĂśytyy myĂśs vastaus vaikeaan laskennalliseen matemaattiseen ongelmaan, 
joka on uniikki jokaiselle lohkolle. Ilman oikeaa vastausta ei uutta lohkoa voi lisätä 
ketjuun. Louhinnan konsepti on ratkoa näitä matemaattisia ongelmia, lÜytää uusia 
lohkoja ja tätä myÜtä saada uuden lohkon lÜytämisestä palkkio.  

Kuva 11. Bitcoin-lohkoketjun yksittäisen lohkon rakenne, joka koostuu aiemman lohkon tiivis-
teestä, Merkle-juuresta, aikaleimasta ja bittiarvosta, joka ilmaisee lohkon laskennallisen 
vaikeustason sekä satunnaisluvun noncen [29]. 

Jokainen lohko koostuu pääosin kahdesta tekijästä, ns. block headerista, johon tallen-
netaan erinäistä metadataa, ja pitkästä listasta, johon on listattu kaikki viimeaikaiset 
transaktiot. Kuvassa 11 näkyy block headerin rakenne, johon sisältyy previousblock– 
arvo, joka on aiemman lohkon tiiviste, Merkle root eli lohkon Merkle-juuri, joka on luotu 
lohkon transaktioiden tiivisteistä, time eli aikaleima, joka ilmastaan Unix-muodossa. ja 
bits, joka ilmaisee lohkon matemaattisen vaikeuden. Nonce on satunnainen luku, jonka 
louhijat lÜytävät uuden lohkon luonnin yhteydessä ja jonka mukaan louhija saa palkin-
non. 



11

Block headerista ja Merkle-puusta voidaan havaita, kuinka lohkoketju ei ole yksinker-
taisesti pelkkään datan turvalliseen säilyttämiseen perustuva teknologia, vaan erittäin 
tehokas ja muuttumaton, sillä pienikin muutos lohkossa vaikuttaa aiempiin ja on välit-
tÜmästi havaittavissa. 

2.4. Proof-of-Work-protokolla 

Proof-of-Work (PoW), eli todiste tyÜstä, on protokolla, jolla alun perin vuonna 1993 
julkaistussa artikkelissa “On Memory-Bound Functions For Fighting Spam” havainnol-
listettiin roskapostin estämistä tuomalla sähkÜposteihin prosessin, joka vaatii lähettäjää 
prosessoimaan jokaista viestiä määritetyn ajan verran ennen lähettämistä. Tämä todis-
taa, että postin lähettämiseen oli käytetty määritetyn verran laskentaa ja aikaa, eli se ei 
ole roskapostia. PoW on konsensusalgoritmi, joka on tiedon tuottamiseen kallis ja 
aikaa vievä, mutta helposti muiden todennettavissa. [10.] 

Bitcoinin PoW vaatii louhijoiden ratkaisevan matemaattisia laskuja lÜytääkseen uusia 
lohkoja ketjuun. Laskujen vaikeus ei aina ole sama, ja se mukautuu jatkuvasti, jotta uu-
sia lohkoja voitaisiin luoda tasaisin väliajoin. Protokollan perusidea on, että kalliista ja 
aikaa vievästä tyÜstä louhijat saavat palkkion joka kerta, kun uusi lohko lÜydetään. 
Tämä kuitenkin johtaa tilanteeseen, jossa yhdellä lohkoketjulla on tuhansittain louhijoi-
ta, jotka kilpailevat uusista lohkoista itsenäisesti. Seurauksena voi olla, että kaksi louhi-
jaa lÜytävät uuden lohkon, jolla on eri Merkle-juuren tiiviste, mikä johtaa kokonaan eri-
laiseen lohkon tiivisteeseen. Tämän vuoksi lohkoketju jaetaan kahteen eri haaraan, ja 
se haara jonka alussa olevan lohkon ratkaiseminen oli haastavampaa, saa jatkaa viral-
lisena lohkoketjuna, jolle louhijat siirtyvät. 

Kuva 12. Lohkoketjun haarauma. 

Yksi merkittävistä PoW-protokollan ongelmista on louhinnan keskittäminen. [8.] 
Jokainen taho voi halutessaan louhia itsenäisesti, mutta kilpailun kasvaessa on syn-
tynyt suuria louhintajoukkoja, joiden laskentateho on marginaalisesti suurempi kuin yk-
sittäisten toimijoiden, jolloin niiden tuotto on suurempaa yksittäisiin toimijoihin verrat-



12

tuna. Tämä on johtanut siihen, että monet yksittäiset louhijat eivät enää louhi itselleen, 
vaan antavat laskentatehoaan isojen organisaatioiden louhinta“altaaseen”, jota organ-
isaatio hallinnoi. Täten kaikki altaaseen liittyvät louhijat saavat oman laskentatehonsa 
edestä palkkiota sitä mukaa, kun organisaatio lÜytää uusia lohkoja. Näin yksittäisten 
toimijoiden ei tarvitse kilpailla suurta laskentatehoa vastaan, vaan voivat liittyä osaksi 
sitä. Karkeasti 80 % koko verkon laskentatehosta tulee seitsemästä isosta louhinta-al-
taasta, joista kuusi on peräisin Kiinasta. Teoreettisesti nämä tahot voisivat tehdä 
yhteistyÜtä ja koordinoida hyÜkkäyksiä verkkoa kohtaan tai manipuloida transaktioita 
oman tarpeensa mukaisesti, mikä johtaisi esimerkiksi “double-spending”-ongelmaan. 
[11.] 

Louhijoiden suorituskykyä mitataan heidän laskentakykyjen mukaan, ja tätä suori-
tuskykyä voi kuvata termillä hash rate. Koska bitcoin on hajautettu järjestelmä kaikille 
sen käyttäjille, myÜs sen louhiminen tapahtuu maailmanlaajuisesti ja hajautetusti. Teo-
reettisesti jokin taho, joka kykenee saamaan yli 50 % kokonaissuorituskyvystä,kykenisi 
manipuloimaan transaktioiden hyväksymistä ja järjestelyä. [11.] Tämä taho voisi jopa 
peruuttaa transaktioita, mikä johtaisi “douple-spending”-ongelmaan, jossa hyökkääjän 
valuuttasumma palautuisi, mikä mahdollistaisi valuutan uudelleen käytÜn, ja tämä olisi 
koko bitcoinin perusideaa vastaan. Onnistunut hyÜkkääjä voisi myÜs estää muita louhi-
joita louhimasta, mikä johtaisi monopoliasemaan louhinnassa. Tämänkaltaista teoreet-
tista hyÜkkäystä kutsutaan nimellä 51 % -hyÜkkäys. [11.] 

51 % -hyÜkkäys on kuitenkin monissa tapauksissa erittäin epätodennäkÜistä, ja teo-
reettisesti lähes mahdotonta. Bitcoinin arvon nousun myÜtä se on houkuttanut enem-
män ja enemmän louhijoita ketjulle, jonka ansiosta järjestelmä on päässyt kasvamaan 
hyvin laajaksi. Tämänhetkinen lohkopalkkio louhijalle on 12,5 BTC lohkoa kohden, joka 
210 000 lohkon välein puolittuu jatkuvasti, kunnes uusia lohkoja ei voida enää lÜytää. 
Tällainen kilpailullinen asettelu takaa louhijoiden rehellisyyden, kun he  saavuttavat 
lohkopalkkioita. [30.] 

Bitcoinin tämänhetkinen hash rate on noin 120 000 000 TH/s (triljoonaa hashia per 
sekunti) 28.1.2020. Jos jokin taho haluaa manipuloida tätä, tulisi hänen tuottaa 60 000 
000 TH/s, mikä ei teoriassa ole mahdotonta, mutta erittäin epätodennäkÜistä käytän-
nÜssä. [31.] 



13

2.5. Proof-of-Stake-protokolla 

Lohkoketjun perusperiaatteeseen kuuluu hajauttaminen. Tässä mallissa yhteen yksit-
täiseen toimijaan tai keskukseen ei tarvitse luottaa vaan koko järjestelmä on hajautettu 
useiden osallistujien kesken ja uusien lohkojen luonti on jaettu tasaisesti kaikkien 
kesken. PoW-protokolla kuitenkin tuo mukanaan omia ongelmia, kuten louhinnan 
keskittäminen, korkea energiankulutus sekä 51 % -hyÜkkäykset. Näiden ongelmien in-
spiroimana kehittäjät ovat luoneet toisenlaisen protokollan nimeltä Proof-of-Stake eli 
todiste osuudesta. Laskennallisen tyÜn sijaan osallistujat näyttävät todisteen omasta 
osuudestaan ja laittavat sen ns. pantiksi. Mitä suurempi pantti, sitä suurempi mahdol-
lisuus on päästä muodostamaan seuraava lohko. Tämän ansiosta osallistujat eivät kil-
pailisi laskennallisesta tehosta saadakseen uuden lohkon ketjuun, vaan protokolla val-
itsisi seuraavan kirjoittajan tiettyjen kriteerien mukaan, kuten osuuden iän, määrän 
sekä satunnaisuuden perusteella. [12.] 

Taistellakseen suuria osuuksia vastaan protokolla hyÜdyntää satunnaisuutta ja osuu-
den ikää kriteereinä, jolloin suuret osuudet eivät pelkästään takaa voittoa. Protokollas-
sa osallistujat laittavat pantiksi rahakkeita (tai kryptovaluuttoja), mistä syntyy rahallinen 
sitoutuminen. Mitä pidempään osuus on ollut ylhäällä, sitä suurempi sen mahdollisuus 
on päästä muodostamaan seuraava lohko. Satunnaisessa valinnassa muodostajat vali-
taan pienimmän tiivistearvon ja suurimman pantin mukaan. PoS-protokolla yhdistää 
näitä kolmea edellä mainittua kriteeriä, ja niiden yhteisen konsensuksen perusteella 
valitsee seuraavan muodostajan. Protokollassa ei lasketa matemaattisia ongelmia eikä 
uusia lohkoja lÜydetä louhinnan kautta vaan niitä muodostetaan. 

PoS-protokolla tarjoaa potentiaalisia ratkaisuja louhinnan keskittymiselle ja korkealle 
energiankulutukselle, mutta PoS ei tule kuitenkaan ongelmitta. Vaikka se käyttää er-
inäisiä kriteerejä taistellakseen suuria osuuksia vastaan, ne ovat silti yksi kriteereistä, 
joten mitä suurempi osuus, sitä enemmän painoarvoa sillä kriteerillä on. Tämä voi jo-
htaa keskittymiseen, mikäli suurimmat osuudet olisivat vain muutamalla taholla. 
Toiseksi PoW-protokollassa uusien haarojen muodostuessa valitaan aina se, kumpaan 
on käytetty enemmän laskennallista energiaa, mutta PoS-protokollassa uusien haaro-
jen muodostuessa se jää tahojen päätettäväksi. Tämä johtaa siihen, että molempia 
haaroja voidaan jatkaa, sillä lohkojen muodostamiseen ei mene kuluja energian 
kannalta, joten se on taloudellisesti kannattavaa lohkoja validoiville tahoille. Joku 
haitallinen taho voisi hyÜdyntää tätä luomalla uuden haaran ennen varojensa käyt-
tämistä ja jatkaa oman haaransa louhimista, jolloin aiemman mainitun periaatteen 
mukaan muut louhijat jatkavat hänen haaraansa, sillä siitä ei synny lisäkuluja. Täten 



14

hyÜkkääjän haarasta tulisi ajan myÜtä pisin haara, vaikka hänellä olisi hyvin pieni osu-
us siinä. [13.] 

Tätä ongelmaa kutsutaan ‘nothing-at-stake’ -ongelmaksi. Vaikka tämänkaltaiset ongel-
mat ovat hyvin vaikeita toteuttaa eikä niistä välttämättä ole suurta taloudellista hyÜtyä 
mahdolliselle hyÜkkääjälle, ne ovat silti varteenotettavia ongelmia vertailtaessa erilaisia 
protokollia. 

2.6. Kryptovaluutta 

Kryptovaluutat, eli erinäiset digitaalisen valuutan muodot, kuten bitcoin, hyÜdyntävät 
lohkoketjuteknologiaa. Kryptovaluuttojen keskeinen konsepti perustuu vapaaseen, ha-
jautettuun valuutanmuotoon, jossa sitä eivät määrää pankit tai niiden asettamat korko-
prosentit, vaan kysynnän ja tarjonnan laki. Bitcoinien teoreettinen maksimimäärä on 21 
miljoonaa kolikkoa, joista osa on ajan myÜtä kadonnut inhimillisiin virheisiin, kuten yksi-
tyishenkilĂśiden lompakoiden yksityisten avainten katoamiseen. Bitcoineja on siis rajattu 
määrä olemassa, ja kun viimeiset louhinnan yhteydessä luodut bitcoinit on jaettu, niitä 
ei tule enempää. Kullan tavoin bitcoinin arvo perustuu sen rajallisuuteen sekä muihin 
ominaisuuksiin, kuten sen nopeaan ja globaaliin siirtämiseen, sen yksityiseen luon-
teeseen ja välikäsien tarpeettomuuteen. Sen käyttämistä helpottaa myÜs se, että bit-
coin voidaan jakaa pienempiin yksikkÜihin eli satosheihin (SAT), joilla käyttäjät voivat 
suorittaa pienempiä maksuja. [32.] 

Perinteisessä maksuliikenteessä transaktiot menisivät kolmannen osapuolen kautta 
A:n ja B:n välillä, missä nousee erinäisiä kysymyksiä esiin, kuten kolmannen osa-
puolen luotettavuus, transaktion suoriutuminen ongelmitta, transaktion käsittelymaksu 
jne. Kryptovaluutan tapauksessa transaktio osapuolten välillä on suora, luotettava ja 
joidenkin kryptovaluutojen tapauksessa myÜs anonyymi. Nämä ominaisuudet tekevät 
kryptovaluutoista arvokkaan valuutan muodon henkilÜille, jotka eivät tarvitse perinteistä 
valuuttaa tai usko siihen. 

Kryptovaluutoja on bitcoinin julkaisun jälkeen kehitetty moniin eri käyttÜtarkoituksiin, 
joista osa tarjoaa ominaisuuksia, joita bitcoin ei tarjoa, kuten anonyymiä transaktiota, 
nopeampia suoritusaikoja, eri lohkoarkkitehtuuria yms. MyÜs perinteisiä omistuksia on 
alettu muuttaa digitaaliseen muotoon, jolloin esimerkiksi osake muunnetaan digi-
taaliseen valuuttaan tai rahakkeeseen, joka edustaa osaketta.  

Kryptorahakkeet 



15

Kryptorahakkeet ovat erikoisempi digitaalisen valuutan muoto, jossa jokainen rahake 
edustaa jotain omaisuutta tai hyÜdykettä oikeassa maailmassa, kuten osakkuutta tai 
arvopaperia. Yleisin kryptorahakkeen muoto on ERC20-rahake, joita kuka tahansa voi 
luoda Ethereum-lohkoketjulla. ERC20 on protokolla, joka määrittelee tiettyjä sääntÜjä ja 
standardeja Ethereum-lohkoketjun rahakkeisiin. Yksinkertaisesti selitettynä, mikäli ra-
hakkeen luoja sisällyttää tiettyjä funktioita rahakkeen älysopimuksessa, on rahake täl-
lĂśin ERC20-standardia noudattava. [33.] 

Rahakkeita usein tarjotaan ICO- eli Initial Coin Offering -yhteydessä, jossa yhtiÜt tar-
joavat mahdollisuuden osallistua rahakkeiden jakamiseen joukkorahoituksen kautta. 
Joukkorahoitusta tarjoavat yhtiÜt määrittelevät, kuinka monta rahaketta kukin sijoittaja 
saa esimerkiksi yhtä Etheriä vastaan. Rahakkeilla voidaan tarjota ratkaisuja yhtiÜn 
ekosysteemeihin, luoda kannustimia yksilĂśille osallistua yhtiĂśn palveluun tai luoda es-
imerkiksi Proof-of-Stake -järjestelmä. Rahakkeille on useita eri käyttÜtarkoituksia, ja 
niiden markkina-arvo on kasvanut viime vuosina merkittävän kokoiseksi, mikä on jo-
htanut yritysmaailman ja lainsäätäjien nousevaan mielenkiintoon rahakkeita ja krypto-
valuuttoja kohtaan. [34.] 

3. Älysopimusten perusteet 

Tässä ";"""date"",""2020-05-06T11:39:48Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.4""
""xmp:CreatorTool"",""Pages""
""pdf:docinfo:title"",""Piironen_Petteri""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dcterms:created"",""2020-05-05T10:58:59Z""
""language"",""fi""
""Last-Modified"",""2020-05-06T11:39:48Z""
""dcterms:modified"",""2020-05-06T11:39:48Z""
""dc:format"",""application/pdf; version=1.4""
""title"",""Piironen_Petteri""
""xmpMM:DocumentID"",""uuid:b03b8ec6-4d24-45ec-a0f6-ad287349437b""
""Last-Save-Date"",""2020-05-06T11:39:48Z""
""pdf:docinfo:creator_tool"",""Pages""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2020-05-06T11:39:48Z""
""meta:save-date"",""2020-05-06T11:39:48Z""
""pdf:encrypted"",""false""
""dc:title"",""Piironen_Petteri""
""xmp:CreateDate"",""2020-05-05T10:58:59Z""
""modified"",""2020-05-06T11:39:48Z""
""Content-Length"",""2855763""
""pdf:hasMarkedContent"",""true""
""Content-Type"",""application/pdf""
""xmp:ModifyDate"",""2020-05-06T14:39:48Z""
""xmp:MetadataDate"",""2020-05-06T14:39:48Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""pdf:producer"",""macOS Version 10.15.1 (Build 19B88) Quartz PDFContext""
""meta:creation-date"",""2020-05-05T10:58:59Z""
""created"",""2020-05-05T10:58:59Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""60""
""Creation-Date"",""2020-05-05T10:58:59Z""
""resourceName"",""Piironen_Petteri.pdf""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""138"",""1784"",""1856"",""648"",""1699"",""624"",""2280"",""1560"",""898"",""1967"",""1387"",""856"",""729"",""1281"",""654"",""1695"",""2101"",""2410"",""2834"",""2347"",""2324"",""2508"",""2672"",""2541"",""2713"",""1800"",""566"",""1611"",""2488"",""2453"",""2826"",""2798"",""2606"",""2497"",""1508"",""1009"",""1170"",""2332"",""1611"",""1848"",""997"",""1753"",""1551"",""1852"",""1246"",""810"",""1745"",""1902"",""2363"",""2457"",""1855"",""1742"",""2800"",""2878"",""2909"",""2819"",""2970"",""2663"",""3222"",""1228""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""producer"",""macOS Version 10.15.1 (Build 19B88) Quartz PDFContext""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""macOS Version 10.15.1 (Build 19B88) Quartz PDFContext""
""pdf:docinfo:created"",""2020-05-05T10:58:59Z""
";https://scholar.google.ch/scholar?start=580&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098725-12;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;[PDF][PDF] Peer-prediction in the presence of outcome dependent lying incentives;N Goel, A Filos;Ratsikas…  Proceedings of the 29th …, 2020  pdfs.semanticscholar.org;;"… Our work is motivated by distributed platforms, where decen- tralized data oracles collect

information … in a completely decentral- ized, trustless and transparent manner by using the

blockchain tech- nology … ensure that the decen- tralized platform can be used as an oracle, in …";Cité 1 fois;Les 3 versions;[PDF] semanticscholar.org;https://pdfs.semanticscholar.org/b464/6a77910a0b6fa862f539195aaaf1174ed274.pdf;"
    
    Skip to search formSkip to main content>



Semantic Scholar's Logo
Search




Sign InCreate Free Account


You are currently offline. Some features of the site may not work correctly.

	DOI:10.24963/ijcai.2020/18

Corpus ID: 220484672Peer-Prediction in the Presence of Outcome Dependent Lying Incentives
@inproceedings{Goel2020PeerPredictionIT,
  title={Peer-Prediction in the Presence of Outcome Dependent Lying Incentives},
  author={Naman Goel and Aris Filos-Ratsikas and B. Faltings},
  booktitle={IJCAI},
  year={2020}
}
	Naman Goel, Aris Filos-Ratsikas, B. Faltings
	Published in IJCAI 2020
	Computer Science

We derive conditions under which a peerconsistency mechanism can be used to elicit truthful data from non-trusted rational agents when an aggregate statistic of the collected data affects the amount of their incentives to lie. Furthermore, we discuss the relative saving that can be achieved by the mechanism, compared to the rational outcome, if no such mechanism was implemented. Our work is motivated by distributed platforms, where decentralized data oracles collect information about realworld… Expand

View via Publisher
ijcai.org





Save to Library
Create Alert
Cite
Launch Research Feed





Share This Paper

1 Citations Methods Citations
1


View All









Figures and Topics from this paper


	[image: figure 1]
figure 1
	[image: figure 2]
figure 2



	Peer-to-peer








One Citation



Citation Type
Citation Type

	All Types
	Cites Results
	Cites Methods
	Cites Background






Has PDF
Publication Type


Author


More Filters
More Filters
Filters

Sort by Relevance
Sort by Most Influenced Papers
Sort by Citation Count
Sort by Recency






Infochain: A Decentralized, Trustless and Transparent Oracle on Blockchain
	Naman Goel, Cyril van Schreven, Aris Filos-Ratsikas, B. Faltings
	Computer Science
	IJCAI
	2020

	1

	PDF




	View 2 excerpts, cites methods



Save
Alert
Research Feed








References


SHOWING 1-10 OF 33 REFERENCES
SORT BYRelevance
Most Influenced Papers
Recency




Crowdsourced Outcome Determination in Prediction Markets
	Rupert Freeman, SĂŠbastien Lahaie, D. Pennock
	Computer Science
	AAAI
	2017

	8

	Highly Influential

	PDF




	View 6 excerpts, references results and background



Save
Alert
Research Feed




Peer Prediction with Heterogeneous Users
	Arpit Agarwal, D. Mandal, D. Parkes, Nisarg Shah
	Computer Science
	EC
	2017

	24

	PDF




	View 2 excerpts, references methods and background



Save
Alert
Research Feed




Equilibrium Selection in Information Elicitation without Verification via Information Monotonicity
	Yuqing Kong, G. Schoenebeck
	Mathematics, Computer Science
	ITCS
	2018

	21

	PDF




	View 2 excerpts, references background



Save
Alert
Research Feed




A Robust Bayesian Truth Serum for Non-Binary Signals
	Goran Radanovic, B. Faltings
	Computer Science
	AAAI
	2013

	95

	PDF




	View 2 excerpts, references methods



Save
Alert
Research Feed




Mechanisms for Making Crowds Truthful
	R. Jurca, B. Faltings
	Computer Science
	J. Artif. Intell. Res.
	2009

	128

	PDF




Save
Alert
Research Feed




Informed Truthfulness in Multi-Task Peer Prediction
	V. Shnayder, Arpit Agarwal, Rafael M. Frongillo, D. Parkes
	Computer Science
	EC
	2016

	84

	PDF





Save
Alert
Research Feed




Deep Bayesian Trust: A Dominant and Fair Incentive Mechanism for Crowd
	Naman Goel, B. Faltings
	Computer Science, Mathematics
	AAAI
	2019

	12

	PDF




	View 2 excerpts, references methods and background



Save
Alert
Research Feed




Game Theory for Data Science: Eliciting Truthful Information
	B. Faltings, Goran Radanovic
	Computer Science
	Game Theory for Data Science
	2017

	30

	Highly Influential



	View 5 excerpts, references methods and background



Save
Alert
Research Feed




Trading on a Rigged Game: Outcome Manipulation in Prediction Markets
	Mithun Chakraborty, Sanmay Das
	Business, Computer Science
	IJCAI
	2016

	13

	PDF




	View 1 excerpt, references background



Save
Alert
Research Feed




Incentives for Effort in Crowdsourcing Using the Peer Truth Serum
	Goran Radanovic, B. Faltings, R. Jurca
	Computer Science
	ACM Trans. Intell. Syst. Technol.
	2016

	71

	PDF




Save
Alert
Research Feed







...

1

2

3

4

...








Related Papers

















	Abstract
	Figures and Topics
	1 Citations
	33 References
	Related Papers







Stay Connected With Semantic Scholar
Sign Up

About Semantic Scholar
Semantic Scholar is a free, AI-powered research tool for scientific literature, based at the Allen Institute for AI.
Learn More →

Resources
DatasetsSupp.aiAPIOpen Corpus
Organization
About UsResearchPublishing PartnersData Partners
 
FAQContact



Proudly built by AI2 with the help of our Collaborators
Terms of Service•Privacy Policy

The Allen Institute for AI


By clicking accept or continuing to use the site, you agree to the terms outlined in our Privacy Policy, Terms of Service, and Dataset License
ACCEPT & CONTINUE




    
    
  
    
    

    
    
    






    
    
  ";"""citation_publication_date"",""2020""
""og:image"",""https://www.semanticscholar.org/img/semantic_scholar_og.png""
""citation_title"",""Peer-Prediction in the Presence of Outcome Dependent Lying Incentives""
""og:image:width"",""1110""
""twitter:card"",""summary_large_image""
""msapplication-square70x70logo"",""https://cdn.semanticscholar.org/86e6c2539915adc9/img/mstile-70x70.png""
""citation_journal_title"",""undefined""
""description"",""We derive conditions under which a peerconsistency mechanism can be used to elicit truthful data from non-trusted rational agents when an aggregate statistic of the collected data affects the amount of their incentives to lie. Furthermore, we discuss the relative saving that can be achieved by the mechanism, compared to the rational outcome, if no such mechanism was implemented. Our work is motivated by distributed platforms, where decentralized data oracles collect information about realworld events, based on the aggregate information provided by often self-interested participants. We compare our theoretical observations with numerical simulations on two public real datasets.""
""msapplication-wide310x150logo"",""https://cdn.semanticscholar.org/86e6c2539915adc9/img/mstile-310x150.png""
""language"",""en""
""title"",""[PDF] Peer-Prediction in the Presence of Outcome Dependent Lying Incentives | Semantic Scholar""
""og:description"",""We derive conditions under which a peerconsistency mechanism can be used to elicit truthful data from non-trusted rational agents when an aggregate statistic of the collected data affects the amount of their incentives to lie. Furthermore, we discuss the relative saving that can be achieved by the mechanism, compared to the rational outcome, if no such mechanism was implemented. Our work is motivated by distributed platforms, where decentralized data oracles collect information about realworld events, based on the aggregate information provided by often self-interested participants. We compare our theoretical observations with numerical simulations on two public real datasets.""
""og:image:secure_url"",""https://www.semanticscholar.org/img/semantic_scholar_og.png"",""https://www.semanticscholar.org/img/semantic_scholar_og.png""
""twitter:image"",""https://www.semanticscholar.org/img/semantic_scholar_og.png"",""https://www.semanticscholar.org/img/semantic_scholar_og.png""
""twitter:site"",""@allenai_org""
""msapplication-square310x310logo"",""https://cdn.semanticscholar.org/86e6c2539915adc9/img/mstile-310x310.png""
""dc:title"",""[PDF] Peer-Prediction in the Presence of Outcome Dependent Lying Incentives | Semantic Scholar""
""Content-Encoding"",""UTF-8""
""citation_pdf_url"",""https://doi.org/10.24963/ijcai.2020%2F18""
""robots"",""noarchive,noindex""
""Content-Type"",""text/html; charset=UTF-8""
""s2-ui-version"",""2cfb8f55a25a62a824f97b333bd41eb95e1e3822""
""application-name"","" ""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""twitter:title"",""[PDF] Peer-Prediction in the Presence of Outcome Dependent Lying Incentives | Semantic Scholar""
""og:type"",""website""
""og:title"",""[PDF] Peer-Prediction in the Presence of Outcome Dependent Lying Incentives | Semantic Scholar""
""citation_author"",""Naman Goel"",""Aris Filos-Ratsikas"",""B. Faltings""
""og:image:height"",""582""
""resourceName"",""6a77910a0b6fa862f539195aaaf1174ed274.pdf""
""msapplication-square150x150logo"",""https://cdn.semanticscholar.org/86e6c2539915adc9/img/mstile-150x150.png""
""msapplication-TileColor"",""#FFFFFF""
""viewport"",""width=device-width,initial-scale=1""
""twitter:description"",""We derive conditions under which a peerconsistency mechanism can be used to elicit truthful data from non-trusted rational agents when an aggregate statistic of the collected data affects the amount of their incentives to lie. Furthermore, we discuss the relative saving that can be achieved by the mechanism, compared to the rational outcome, if no such mechanism was implemented. Our work is motivated by distributed platforms, where decentralized data oracles collect information about realworld events, based on the aggregate information provided by often self-interested participants. We compare our theoretical observations with numerical simulations on two public real datasets.""
""og:locale"",""en_US"",""en_US""
""Content-Language"",""en""
""msapplication-TileImage"",""https://cdn.semanticscholar.org/86e6c2539915adc9/img/mstile-144x144.png""
";https://scholar.google.ch/scholar?start=560&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098866-340;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Stable Cryptocurrencies: First Order Principles;C Calcaterra, WA Kaal, V Rao ; Stan. J. Blockchain L. & Pol'y, 2020  HeinOnline;;"… com/exclusive- trueusd-partners-with-nexo-to-provide-holders-with-instant-loans-on-

cryptocurrency … latest/2018/10/stablecoin-guide-why-are- stablecoins-so-important-to-crypto-

markets … Tether to Launch New Version of USDT Stablecoin on Tron Blockchain, COINDESK …";Cité 13 fois;Les 3 versions;[PDF] pubpub.org;https://assets.pubpub.org/ndc8dfu4/11578223064725.pdf;;;https://scholar.google.ch/scholar?start=880&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098774-129;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Formal Software Architectural Migration Towards Emerging Architectural Styles;N Chondamrongkul, J Sun, I Warren ; European Conference on Software …, 2020  Springer;;"… 6. MedRecord is added as an oracle that connects to a blockchain called MedChain with

medupwire connector. Open image in new window Fig … Formula (4) is for the Secure Data Writing

rule. It ensures that the data can be stored on the blockchain according to Oracle pattern …";Autres articles;;null;;;;https://scholar.google.ch/scholar?start=670&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098822-232;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;A New Framework of IND-CCA Secure Public Key Encryption with Keyword Search;S Ma, Q Huang ; The Computer Journal, 2020  academic.oup.com;;"… Probing phase I. The adversary |$\mathcal{A}_{1}$| can adaptively ask the following oracles:

Trapdoor oracle: It takes any keyword |$\textsf{m}\in \{0,1\}^{\ast }$| submitted by

|$\mathcal{A}_{1}$| and returns a trapdoor |$t$| by running the Trapdoor algorithm using its secret …";Cité 1 fois;Les 2 versions;null;;;;https://scholar.google.ch/scholar?start=780&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098760-91;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Blockchain Ecosystem—Technological and Management Opportunities and Challenges;KKR Choo, S Ozcan, A Dehghantanha… ; IEEE Transactions on …, 2020  ieeexplore.ieee.org;;"… 2020. [29] MH Ur Rehman, K. Salah, E. Damiani, and D. Svetinovic, “Trust in blockchain

cryptocurrency ecosystem,” IEEE Trans. Eng … 299–321. [50] K. Nelaturu et al., “On public

crowdsource-based mechanisms for a decentralized blockchain oracle,” IEEE Trans. Eng …";Cité 2 fois;Les 4 versions;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/17/9226631/09226671.pdf;"
		
	";"""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""dc:title"",""IEEE Xplore Full-Text PDF:""
""Content-Encoding"",""UTF-8""
""resourceName"",""09226671.pdf""
""language"",""es""
""Content-Length"",""2560""
""title"",""IEEE Xplore Full-Text PDF:""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.ch/scholar?start=640&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098857-311;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;[LIVRE][B] Blockchain ? ?????????;? ?????? ;2020 books.google.com;;"Page 1. Page 2. Blockchain ? ????????? ????????? ?????? Page 3 … ? ?????? ??????? ? ??????

???????? ??? ???????? ?????????? ?????????????. ?????????????? ????? ???

??????-?????, ?????????? ?? ?????????? blockchain, ???????? ????????? ??? ?????? …";Cité 9 fois;Les 2 versions;null;;;;https://scholar.google.ch/scholar?start=860&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098835-269;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;[PDF][PDF] Publicly Verifiable Zero Knowledge from (Collapsing) Blockchains;A Scafuro, L Siniscalchi, I Visconti ; IACR Cryptol. ePrint Arch, 2020  eprint.iacr.org;;"… community, constructions of NIZK proofs either rely on the existence of a trusted common reference

string (CRS) computed by a trusted entity or are based on heuristic assumptions (eg, random

oracles) … Publicly verifiable zero-knowledge proofs from a “Blockchain Assumption” …";Cité 1 fois;;[PDF] iacr.org;https://eprint.iacr.org/2020/1435.pdf;"
Publicly Verifiable Zero Knowledge

from (Collapsing) Blockchains∗

Alessandra Scafuro† Luisa Siniscalchi ‡ Ivan Visconti§

Abstract

Publicly Verifiable Zero-Knowledge proofs are known to exist only from setup assumptions
such as a trusted Common Reference String (CRS) or a Random Oracle. Unfortunately, the
former requires a trusted party while the latter does not exist.

Blockchains are distributed systems that already exist and provide certain security properties
(under some honest majority assumption), hence, a natural recent research direction has been
to use a blockchain as an alternative setup assumption.

In TCC 2017 Goyal and Goyal proposed a construction of a publicly verifiable zero-knowledge
(pvZK) proof system for some proof-of-stake blockchains. The zero-knowledge property of their
construction however relies on some additional and not fully specified assumptions about the
current and future behavior of honest blockchain players.

In this paper we provide several contributions. First, we show that when using a blockchain to
design a provably secure protocol, it is dangerous to rely on demanding additional requirements
on behaviors of the blockchain players. We do so by showing an “attack of the clones” whereby
a malicious verifier can use a smart contract to slyly (not through bribing) clone capabilities of
honest stakeholders and use those to invalidate the zero-knowledge property of the proof system
by Goyal and Goyal.

Second, we propose a new publicly verifiable zero-knowledge proof system that relies on non-
interactive commitments and on an assumption on the min-entropy of some blocks appearing
on the blockchain.

Third, motivated by the fact that blockchains are a recent innovation and their resilience
in the long run is still controversial, we introduce the concept of collapsing blockchain, and we
prove that the zero-knowledge property of our scheme holds even if the blockchain eventually
becomes insecure and all blockchain players eventually become dishonest.

Keywords: publicly verifiable zero knowledge, (collapsing) blockchain.

1 Introduction

Following the success of Bitcoin many other cryptocurrencies based on blockchain technology have
been proposed and, despite a few security issues, they are still expanding their networks with
gigantic market capitalizations. What is so appealing in decentralized blockchains?

∗This paper appeared in Public-Key Cryptography (PKC) 2021 [38].
†North Carolina State University, Raleigh, USA, ascafur@ncsu.edu
‡Concordium Blockchain Research Center, Aarhus University, Aarhus, Denmark, lsiniscalchi@cs.au.dk
§Università di Salerno, Salerno, Italy, visconti@unisa.it

1



Public verifiability. One of the most supported answers is the paradigm shift from trust in
some entity to “public verifiability”. This property allows every one to check that the system works
consistently with the pre-specified rules of the game. This makes users willing to be involved in
transactions recorded in a blockchain therefore investing their real-world money. In many blockchain
applications both anonymity and public verifiability are required, calling for advanced cryptographic
primitives such as publicly verifiable zero-knowledge proofs. For example, when the blockchain is
used to record payments, confidential transactions are indeed implemented using publicly verifiable
zero-knowledge proofs called zk-SNARKs [8, 22].

Publicly verifiable zero-knowledge proofs. Known constructions of publicly verifiable zero-
knowledge (pvZK) proofs are instantiated with non-interactive zero-knowledge proofs (NIZK) and,
as such, require setup assumptions. Indeed, despite a significant effort of the research community,
constructions of NIZK proofs either rely on the existence of a trusted common reference string
(CRS) computed by a trusted entity or are based on heuristic assumptions (e.g., random oracles).
Recent existing work has shown mechanisms to relax the trust assumptions required to generate
the CRS [13] or to mitigate the effect of a malicious CRS [28, 34]. While this line of work is very
promising, it still requires the employment of third entities that help computing the CRS.

Publicly verifiable zero-knowledge proofs from a “Blockchain Assumption”. Since its
introduction in 2008 with Nakamoto’s protocol [35], blockchain protocols have been scrutinized
by many communities, and currently, we have a good understanding of the security properties
they provide and the class of adversaries they withstand. In particular, several works from the
cryptographic community provided a formalization of the Bitcoin security guarantees [21, 36], a
formalization of the ideal functionality it implements [4] as well as game-theoretic analysis [2].
Furthermore, new blockchain designs have been proposed, based on different assumptions on the
collective power of the adversary. Some prominent examples that are also implemented in practice
are Ouroboros [3] and Algorand [24].

Given that blockchains have been formally analyzed and are up and running in practice, a
natural question to ask is whether we can use a blockchain as a setup assumption to replace trusted
setups required for certain cryptographic tasks, particularly, for publicly verifiable zero-knowledge
proof systems that are needed the most in blockchain applications.

This question was first investigated by Goyal and Goyal in [25], where they aimed to construct
NIZK using as setup the existence of a proof-of-stake (PoS) blockchain. The security of the NIZK
proof provided in [25] – that we will denote by GG-NIZK– however is analyzed in a threat model
that does not faithfully match the threat model of PoS blockchains, since it considers only static
adversaries and additionally requires that honest stakeholder never reveal their secret keys. Specif-
ically, the zero-knowledge property of GG-NIZK is proved in the presence of a static adversary
who decides in advance which stakeholder will corrupt in its entire attack. This does not match
the widely accepted threat model for proof-of-stake blockchains where an adversary is allowed to
corrupt stakeholders at any time, and the only restriction is that, at any point, the total amount
of stake held by the adversary is a minority of the total stake of the system. Moreover, in the
GG-NIZK security analysis, the zero-knowledge property holds under the additional assumption
that honest stakeholders will never leak their stakeholder keys, not even when such keys become
irrelevant for the blockchain protocol (for example, because there is zero stake associated to them).

It was observed in [39] that the assumption on stakeholder keys further limits the generality
of GG-NIZK since it cannot be used in conjunction with any proof-of-stake (PoS) blockchain. In
particular [39] observes that one could design a PoS blockchain where stakeholders are required to

2



often refresh their stakeholder keys, by regularly publishing new public keys and voiding old keys
by posting their secret keys on the blockchain. Such blockchain protocol, while being a potentially
valid PoS blockchain protocol, cannot be used to instantiate GG-NIZK.

The full version of [25] has been recently updated [26] adding a section in the appendix where
the authors confirm the security of their construction even in light of the counter-example of [39]
by stressing that they expect honest stakeholders to delete keys when they lose significance.

In light of the observations of [39] and of the counter-argument of [26], a natural question to
ask is whether such additional assumptions/expectations on the behavior of honest stakeholders
required in [25, 26] could be symptomatic of unexpected security flaws that would manifest when
GG-NIZK is executed with a real blockchain environment, even one that complies with all GG-NIZK
assumptions/expectations. In other words, assuming that the additional restrictions on the power
of the adversary and the behavior of honest stakeholders are met, would GG-NIZK be actually
secure when executed in the presence of a PoS blockchain that complies with them?

A negative answer to the above question would signify that constructing a publicly verifiable
zero-knowledge proof that leverages any blockchain assumption is still an open question.

1.1 Our Contribution

In this paper we target the problem of constructing publicly verifiable zero-knowledge proofs lever-
aging a blockchain assumption and provide the following contributions.

1.1.1 A More Realistic Blockchain Threat Model.

We consider a model where the blockchain can potentially be used to post and fulfill arbitrary smart
contracts. Since all existent blockchain protocols either already support or aim to support smart
contracts capabilities (e.g., Ethereum Casper, Cardano) and, since smart contracts are among the
most appealing feature of blockchains, this model is arguably realistic. Within this model, an
adversary can consequently also leverage her ability to publish smart contracts just like any party
who uses the blockchain.

Within this threat model, we show that the zero-knowledge property of GG-NIZK is easily
violated even assuming that all restrictions required by the security analysis of GG-NIZK are satis-
fied, that is, even assuming that the adversary can only perform static corruption and that honest
stakeholders will never reveal their keys. Specifically, we present an adversarial strategy that lever-
ages legitimate smart contracts to collect information that are useful to disturb the security of the
external cryptographic protocols that use the blockchain as a building block. We name this type of
attacks “attack of the clones” to highlight the adversary’s aim to clone the capability of a honest
player to perform computations using her secret key. However, the smart contract posted by the
adversary is completely harmless for a honest stakeholder. Indeed, it does not ask the stakeholder
to do anything that will make her lose her stake, or perform any operation against the consensus
protocol. Yet, it allows the adversary to break the zero knowledge of the GG-NIZK proof. Our
attack leverages a specific dangerous use of stakeholder identifiers in the GG-NIZK. The starting
point is that the NIZK proof of [25] includes encryptions of shares of the witness under the pub-
lic keys inferred by the identifiers of the stakeholders. To break the zero-knowledge property of
the NIZK of [25] our attack is rather simple: after the NIZK proof π is received, the adversarial
verifier posts a smart contract containing ciphertexts (these are the ciphertext contained in π)
and a promised reward (e.g., money, raffle tickets for a vacation in Barbados, etc) in exchange for
decryptions.

Notice that an honest stakeholder participating in this smart contract remains fully honest,

3



does not subtract any resource (unlike in bribing attacks against proof-of-work blockchains) from
the participation to the consensus protocol and does not reveal her secret keys to anyone. She just
plays with smart contracts as contemplated by the blockchain rules and uses her stake for some
harmless entertainment. Indeed, the crux of this attack is that a stakeholder is not aware that
an external cryptographic protocol is basing its zero-knowledge property on the assumption that
stakeholders would not entertain in smart contracts that are harmless for the underlying blockchain
protocol.

One might object that it is plausible that a PoS blockchain would simply forbid the execution
of such “weird” smart contracts. However, it is not clear what a “weird” smart contract is, and
whether the above smart contract could be redesigned in order to look innocent and harmless
(furthermore, the well known DAO attack inflicted to Ethereum suggests that it is unclear whether
we are able to identify and stop an harmful smart contract too much in advance).

Our attack is obviously a simple example and after-the-fact can possibly be mitigated, for
instance by adding specific further restrictions on how the stakeholder should use her secret keys.
However, the point of our attack is not prove that there is no blockchain for which GG-NIZK can
be secure. Instead, we want to highlight the vulnerabilities arising when the long-term security of
a cryptographic protocol relies on the behavior of blockchain players.

The main lesson of our attack is the following: when designing protocols that leverage a
blockchain assumption, one has to consider a threat model where the adversary is allowed to
perform the same actions that are allowed on the blockchain (e.g., run smart contracts1). Note that
this should be true even when analyzing the consensus protocol itself. However, since this is out of
the scope of this paper, we assume that the underlying blockchain consensus protocol is secure in
the presence of smart contracts.

Another lesson to be drawn by our attack is that, when using the blockchain as an underlying
assumption, one should take into account the unstable and evolving nature of blockchains. Unlike
a common reference string, blockchains evolve over time – due to software updates for example,
or governance decisions– stake is transferred among players, new smart contracts are installed etc.
Last but not least one might take into account the possibility that a blockchain that todays is
reliable tomorrow could collapse and could then be completely controlled by an adversary.

The above attack on the ZK of GG-NIZK leaves open the following natural question.

Can we design a pvZK proof leveraging the existence of blockchains, that makes
no particular assumption on the underlying consensus mechanism neither on the way
honest keys must be used (for instance, they can still be used in smart contracts)?

1.1.2 Publicly Verifiable Zero Knowledge from a Generic Blockchain in Our Threat
Model.

As a second contribution we provide a new protocol for pvZK that is secure in the blockchain
threat model discussed above even in the presence of adaptive adversaries. To show this security
guarantee, we will prove that once the proof (computed using our protocol) is published, it will
preserve its security even if the blockchain collapses, that is, even if the adversary corrupts all the
players of the blockchain (and gets all the secrets). We now proceed describing our protocol and
our blockchain assumption.

1We note that this threat model was never considered before. [39] only made observations about additional
limitations that GG-NIZK imposes on their underlying blockchain. Instead, in this work we are showing an attack
that works for any PoS blockchain (even the ones that comply with GG-NIZK pre-requirement) allowing the execution
of such smart contracts.

4



A recent work by Choudhuri et al. [15] shows that using a blockchain as a black-box object
that provides only a global ledger does not allow to overcome some impossibility results in the
plain model and in particular it does not allow to construct NIZK proofs. We notice that their
argument can be extended also to pvZK proofs (see Section 5 for more details). Therefore, in order
to build a publicly verifiable zero-knowledge proof system from a blockchain, it seems that one
needs to provide more power to the simulator besides black-box access to a global ledger. Thus,
following [25] we will assume that the simulator has the power of controlling the honest players.
However, unlike [25] we assume that the adversary can adaptively corrupt players and moreover
we want our pvZK proof to remain zero knowledge even in case of blockchain failure, in the sense
that in the future the adversary might take full control over the blockchain.

To leverage this simulation power while making no assumption on the consensus protocol un-
derlying the blockchain (i.e., we do not assume that the blockchain is based on proof-of-work,
proof-of-stake, etc), we require that the blockchain satisfies a more nuanced notion of chain quality.
Very informally (a formal definition is provided in Assumption 1) we assume the blockchain has
the following mild structure. First, every block contains a distinguished field v. For concreteness,
the reader can assume that this field is the same as the “coinbase” value of any Bitcoin block,
and to ease the discussion, in the text that follows, we will call this field wallet. Our blockchain
assumption, very roughly, is that there exists a parameter d, such that, for any sequence of d blocks,
considering the new wallets2 observed in the sequence, we have that a majority of those wallets
has been generated by honest players using independent randomnesses. Essentially our blockchain
assumption builds on top of the standard chain quality assumption, requiring that the adversary
will be the “winning” node that decides the next block using a fresh wallet less often than honest
players. Similar assumptions have been leveraged in the literature. For example [37, 27] use the
assumption that the majority of mined blocks are honest, to select a committee for secure compu-
tation. The difference between our blockchain assumption and the standard chain quality property
is mainly that we additionally require that many of the honest blocks will additionally have an
high-min entropy field. We discuss more extensively our blockchain assumption Section 1.

We will leverage this blockchain assumption and the simulator’s control of the honest majority
to build a pvZK proof as follows. The high-level idea is to follow the FLS approach [18] and prove
the OR of two statements: either “x in L” or “Previously I have predicted the majority of fresh
wallets appeared in the last d blocks”. In particular our idea reminds the implementation of the
FLS approach proposed by Barak [6] where the trapdoor theorem consists of some unpredictable
information that becomes predictable during the straight-line simulation. The soundness of our
construction will follow from similar arguments and will actually be simpler. The reason is that
we implement the prediction step with perfectly binding commitments and thus, unlike Barak, we
will not have to worry about a prover finding collisions in a collision-resistant hash function.

To implement this approach we need two ingredients: a non-interactive commitment scheme
(that can be constructed from 1-1 one-way functions) and a publicly verifiable witness indistinguish-
able proof system pvWI. We use the pvWI proof system recently constructed in [39] which is the
first pvWI proof system from a blockchain assumption. Our blockchain assumption implies the one
of [39]. The pvWI proof system of [39] leverages the underlying blockchain assumption by providing
an interactive prover and a non-interactive verification function. Concretely, the pvWI proof of [39]
builds on a classic 3-round WI proof system where the first two rounds are played by the prover
and blockchain: the prover posts the first round of the classic WI proof on the blockchain, then
she waits for a few blocks extending the block containing the first message and from those extracts
a challenge that corresponds to the second round of a classic 3-round WI proof. The third round

2Here we refer to wallets identifying the block leader cashing the reward and not to wallets involved in transactions.

5



of the classic WI proof is then sent to the actual verifier, who can use the blockchain to validate
all 3 rounds, non-interactively. If the third round is posted on the blockchain then all verifiers can
validate the proof. We need the following 3 properties from the pvWI proof: (1) delayed-input
completeness, which means that the prover will use the theorem and the witness only for comput-
ing the last message of the protocol, which implies that all other messages of the pvWI proof are
independent from the witness; (2) WI in the presence of blockchain failure, that is, (2.1) the WI
property holds even when the prover is the only honest player and therefore the blockchain could
be completely controlled by the adversary; (2.2) the WI property is preserved even when, after a
pvWI proof is computed, the adversary could corrupt the prover; (3) unconditional soundness3 in
the presence of our blockchain assumption (i.e., Assumption 1). Since such properties were not
explicitly claimed in [39] we show in Appendix A.1 that through minor updates to their protocol
those 3 properties are satisfied. The reason why we need the above 3 special properties will be
explained later when we will highlight the security proof.

With the above ingredients in hands, our pvZK proof system works as follows. First, the
prover, using a non-interactive commitment scheme, commits to u ¡ d strings com1, . . . , comu¡d (u
is the blockchain parameters associated to our chain-quality assumption (Assumption 1), more
details about u will be provided later) and posts the commitments on the blockchain. Note that
the prover securely erases the decommitment information of com1, . . . , comu¡d. Then, she waits until
the blockchain is extended by a sequence of d blocks B1, . . . , Bd, that include n blocks B1, . . . , Bn
with fresh wallets (that is, with wallets that were not observed before). Let v1, . . . , vn be such
fresh wallets observed on the blockchain. In the final step, the prover computes the pvWI proof,
for the theorem:“x ∈ L or (com1, . . . , comu·d) are commitments of at least n/2 + 1 of the wallets
(v1, . . . , vn)”.

The simulator SpvZK uses the same power of the simulator of [25] controlling the honest players in
the simulated experiment (in particular, the simulator adds the blocks in the blockchain on behalf
of honest players). Therefore SpvZK can predict the majority of the unpredictable new wallets
associated with a sequence of d future blocks, and can use this knowledge as a trapdoor theorem
when computing the messages of the pvWI proof. Notice that the simulator can not tightly predict
the future wallets that will be permanently added to the blockchain since there will be several other
honest blocks to simulate that will circulate in the network, they might even appear in some forks
but eventually will not be part of the blockchain. Since the simulator has no direct power to decide
which branch of a fork will remain in the blockchain, we require way more than just d commitments.
Indeed we consider the parameter u that measures the upper bound on the amount of valid blocks
that honest players propose for each index of the sequence of blocks of the blockchain.

The pvZK that we construct preserves zero knowledge even in case of adaptive corruption during
the protocol execution and in case the blockchain completely collapses and the adversary gets the
state of all players. To achieve this strong form of zero knowledge, we use secure erasure so that
differences in the committed values are not detected. Moreover we rely on the delayed-input pvWI
so that the simulator can run the prover procedure of the pvWI except that a different witness is
used in last message. Therefore before the last message is played, adaptive corruption is not harmful
since the simulator played exactly like a prover of the pvWI. Assuming that the underlying pvWI
is secure in case the blockchain collapses (fact that we prove), the proof remains zero-knowledge
forever.

A crucial aspect of our construction is that the security of the prover is in the hands of the
prover only and does not depend on the behavior of the stakeholders. To achieve adaptive security
we rely on secure erasure. In contrast, even if the prover of GG-NIZK would erase its randomness,

3See the paragraph below about the power of the adversary.

6



the proof would still suffer of our attack.
For the soundness proof, the main observation is that, as long as our blockchain assumption

holds, even an unbounded malicious prover cannot break soundness since it cannot predict enough
future wallets. This together with the perfect binding property of the commitment scheme and the
unconditional soundness of the pvWI guarantees the soundness of our pvZK.

An additional property of our construction is that all messages except the last one can be
computed even before knowing the statement to prove (i.e., it satisfies delayed-input completeness
and adaptive-input zero knowledge and soundness).

Finally, we remark that even though messages of our pvZK proof can be very long, therefore
exceeding some rule of the blockchain, one can anyway resort to techniques (and assumptions)
like IPFS that allow to keep off-chain long message but still accessible by everyone and succinctly
notarized on chain.

On the computational power of the adversary and rationality of players. In a publicly
verifiable proof assuming that an adversarial prover is PPT does not really say much about his
limits with respect to the security of the blockchain. Indeed in case of proof-of-work blockchains
the limitation of the adversary should be compared to the overall computational capabilities of the
network rather than compared to a generic polynomial on input the security parameter. In our
definition of soundness we will therefore consider an unbounded prover. When proving the security
of our construction we will state explicitly our blockchain assumption and implicitly we will assume
that the constraints on the adversary (see Section 3.2) required by the underlying blockchain are
maintained.

We remark that this work following [25, 26, 39] considers either honest or corrupted players,
without exploring the game-theoretic scenario where players are instead rational.

1.2 Related Work

The idea of using a blockchain as a trusted setup has been explored already (e.g., fair multi-party
computation [11], extraction of week randomness [1]). In [10] a randomness beacon is obtained
assuming players to be somehow rational (i.e., they assume that the adversary that will prefer
to be honest cashing mining rewards rather than misbehaving compromising the beacon). In our
work, as well as the one of [25], we consider zero-knowledge proofs with public verifiability sticking
with the traditional setting where security holds against malicious players.

In [15] a blockchain is used as a global setup assumption to obtain concurrent self-composable
secure computation protocol, which is impossible in the standard model. We stress that [15] does
not provide public verifiability (for the interested reader we expand this discussion in Section 5).
Recently in [27, 9] a blockchain is used to maintain a secret via proactive secrete sharing. As
mentioned above[27] requires some chain quality parameters (n2 + 1, n) which means that for any
sequence of n blocks, the majority of them n

2 + 1 are computed by honest parties. In [9] the
adversary controls up to 25% of the stake. However using the technique discussed in [23] one could
lift up this requirement to less than 50%.

In [5] the notion of Crowd verifiable zero-knowledge (CVZK) is introduced4. In CVZK a prover
wants to convince a set of n verifiers of the validity of a certain statement. In more detail, a CVZK
is a 3-round protocol where first the prover speaks, then n verifiers compute a private state and
send as a second-round a string that may contain some entropy, finally, the prover finishes the proof
π. The verification procedure takes as input π the corresponding statement and also the states

4Our results were publicly announced in [40] way before we have noticed CVZK, therefore the two works are
independent.

7



of the n verifiers. Instead we consider a different notion requiring a zero-knowledge proof that is
publicly verifiable (i.e., any verifier with no additional information could check the veracity of the
statement). Moreover, the definition of CVZK does not require any setup at the price of allowing
the simulator to run in super-polynomial time. Our goal is also to diminish the trust in the setups,
however, instead of requiring super-polynomial time simulation, we exploit more realistic setups
like the blockchains.

2 The Attack of the Clones to GG-NIZK [25]

A high-level overview of the NIZK presented in [25] was provided in the Introduction. In this
section we describe an attack of clones with which a malicious verifier, using a smart contract, is
able to break the zero-knowledge property of GG-NIZK without corrupting any player.

Our attack leverages the fact that, if a blockchain is used as setup assumption for a protocol Π,
the security proof of Π must take into account the fact that a player of Π is also a legitimate player
of the blockchain protocol. As such, legitimate blockchain activities – such as smart contracts –
can be performed by her.

Before describing the attack, we provide a formal description of the GG-NIZK.

Notation for GG-NIZK

- Blockchain B: this is the latest version blockchain which might contain unconfirmed blocks.

- Stable Blockchain B
′
: this is defined as Bd`1 , which is the blockchain B pruned of `1 blocks

(that are possibly unconfirmed blocks).

- Parameter `2: number of last blocks taken into consideration in B
′
.

- StakeholdersM: set of public keys associated to the player that have added at least one block
in the last `2 blocks of B

′
. In [25], such public keys are crucially used for both encryption

and signature.

- Chain quality parameters (see Appendix A.2 for the formal definition of chain quality): `3, `4
used in the soundness proof.

- params:= (1`1 , 1`2 , 1`3 , 1`4).

GG-NIZK: The proof. A proof π for theorem x is computed as follows. Let w be the witness
s.t. (x,w) ∈ R.

1. Secret share the witness w using a weighted secret sharing scheme, using as weights the stake
of the public keys appearing in M. Do the same with the zero-string.

Namely, produce the following two sets5:

{sh1,i}i∈M = Share(w, {stakei}i∈M, β ¡ staketotal, s1)

{sh2,i}i∈M = Share(0, {stakei}i∈M, β ¡ staketotal, s2)
5The role of s1, s2 and β is not relevant for our discussion and therefore they can be ignored.

8



2. Encrypt each weighted share using the public key of the corresponding player. Namely for all i
such that PKi ∈M, sample random strings r1,i, r2,i and compute: ctx1,i = Enc(PKi, sh1,i, r1,i)
ctx2,i = Enc(PKi, sh2,i, r2,i).

3. Compute a non-interactive witness indistinguishable proof (NIWI) πniwi for the theorem: (1)
either the first set of ciphertexts are correct encryptions under the public keys inM of shares
of the witness w or (2) (trapdoor witness) the second set of ciphertexts is a collection of
correct encryptions under the public keys in M of shares of a valid fork of length `3 + `4.

Hence, a proof π for theorem x ∈ L consists of the tuple:

π = (B, {ctx1,i, ctx2,i}i∈M, πniwi, params)

Note that the proof π is not published on the blockchain and it is only sent to the verifier.

Security of GG-NIZK: Intuition. Zero knowledge follows from the assumption of honest majority
of stake. Under such assumption, the simulator –controlling all honest players– is able to compute
a valid fork that constitutes a valid trapdoor witness for the NIWI. Even if the trapdoor witness is
encrypted in (ctx2,i)PKi∈M, a malicious verifier cannot detect that the trapdoor witness was used,
since it does not control enough secret keys (associated to the public keys in M) that would allow
for collection of enough shares.

Soundness is proved by witness extraction: the extractor controls a sufficient fraction of honest
secret keys (associated to the public keys inM) and this allows the decryption of enough ciphertexts,
that leads to enough shares to reconstruct the witness.

Clearly by obtaining in the future (e.g., when those keys will correspond to a reduced amount
of stake) the secrets of the involved stakeholders (through adaptive corruptions or by naturally re-
ceiving the keys from honest stakeholders) the adversary would be able to decrypt those ciphertexts
therefore breaking the zero knowledge property and without violating the proof-of-stake assump-
tion. This problem imposes the assumptions/limitations of the GG-NIZK discussed previously.

A Simple Smart Contract that Breaks the ZK Property of GG-NIZK. The zero-
knowledge property of GG-NIZK crucially relies on the assumption that the malicious verifier
– controlling only a minority of stake– does not have enough secret keys for the public keys in M
to be able to decrypt enough ciphertexts and thus reconstruct the witness.

Our main observation is that in order to obtain decryptions of enough ciphertexts, a malicious
verifier, does not necessarily need to own enough of the stake/secret keys of the honest players. In-
stead, the malicious verifier can upload a smart contract – that we called Decryptio";"""date"",""2021-04-15T10:49:52Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2021-04-15T10:49:52Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.20 (TeX Live 2019) kpathsea version 6.3.1""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2021-04-15T10:49:52Z""
""created"",""2021-04-15T10:49:52Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2021-04-15T10:49:52Z""
""resourceName"",""1435.pdf""
""Author"",""""
""producer"",""pdfTeX-1.40.20""
""pdf:docinfo:producer"",""pdfTeX-1.40.20""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""14"",""2"",""0"",""3"",""7"",""3"",""0"",""6"",""9"",""11"",""2"",""11"",""12"",""21"",""15"",""8"",""3"",""0"",""0"",""0"",""0"",""2"",""8"",""7"",""23"",""12"",""21""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2021-04-15T10:49:52Z""
""Last-Modified"",""2021-04-15T10:49:52Z""
""dcterms:modified"",""2021-04-15T10:49:52Z""
""title"",""""
""Last-Save-Date"",""2021-04-15T10:49:52Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2021-04-15T10:49:52Z""
""meta:save-date"",""2021-04-15T10:49:52Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.20 (TeX Live 2019) kpathsea version 6.3.1""
""Content-Length"",""524729""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""34""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""2276"",""3560"",""3307"",""3264"",""3799"",""3585"",""3194"",""2022"",""3111"",""2257"",""2657"",""2844"",""3111"",""2380"",""1979"",""927"",""1928"",""2551"",""2175"",""2752"",""2589"",""2674"",""2600"",""2760"",""2633"",""2891"",""2791"",""1154"",""2877"",""1736"",""2431"",""2070"",""2340"",""2369""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2021-04-15T10:49:52Z""
";https://scholar.google.ch/scholar?start=810&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098787-159;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;[PDF][PDF] Economics Design and Engineering for Robust DLT Ecosystems;L Tan ; Available at SSRN 3604815, 2020  economicsdesign.com;;"… 2. Community information (Automated mechanism) (a) Oracles to aggregate the flow of

information and data within the to- ken ecosystem (Eg Etherisc, TLSNotary, VeChain, Weeve,

Oraclize, Blockchain Nervous System in Difinity, Ultimate Oracle in Gnosis) …";Autres articles;Version HTML;[PDF] economicsdesign.com;https://www.economicsdesign.com/wp-content/uploads/2019/09/Economics-Design-and-Engineering-for-Robust-DLT-Ecosystems-.pdf;"
Economics Design and Engineering for Robust

DLT Ecosystems

Lisa JY Tan
lisa@economicsdesign.com

Economics Design

Abstract

Matching economic theories, the paper discusses the underlying funda-
mentals of token economics that exist within a token ecosystem. 3 design
fundamentals that affect the soundness of token economics: 1) Market
Design, 2) Mechanism Design and, 3) Token Design. Token ecosystems
facilitate an exchange of goods and services between participants in the
ecosystem. Concepts from matching theory, auction theory, monetary
economics, allocation theory, network economics and game theory, can
help better design strong incentives for participants, produce robust sta-
ble outcomes, reduce inefficient allocation and improve the efficiency of
transaction within the ecosystem. This challenges existing systems that
will open powerful potential for long-term sustainability of token ecosys-
tems and overcoming existing challenges.

Keywords: token economics, token engineering, ecosystem architecture,
systems design, market design, mechanism design, token design, decentralised
governance, blockchain economics, network economics, allocation theory

JEL classification O31, O33, O39, Y20

1 Introduction

Token economics is the engineering of factors that affect, define and govern a
digital ecosystem. The purpose is to understand and affect the decisions made
by participants. It consists of both economics and engineering. It involves re-
sponsibility for detail to deal with externalities [25].

2016 saw a start using tokens as a way to raise funds for token ecosystems
(aka blockchain project, ICO, crypto-project). By 2017, projects are popping
up at every day, raising hundreds of millions of dollars, in hopes to capitalise
on this booming technology. Towards mid-2018, people began to realise the
importance of sound economics underlying each token ecosystem. As the boom
in decentralised finance (DeFi) highlighted the secondary market use-cases for
the token, it only highlights the importance of robust economics design.

1



Engineering is the optimisation machine to achieve the outcome, while eco-
nomics is the oracle that dictates what to optimise, exactly . Together, they
build the architecture for digital ecosystems.

Being the foundation of tokenised ecosystems, token economics designs the
model used to influence the allocation and use of tokens in the decentralised
ecosystem, through incentive mechanisms in a defined environment.

It looks at the long-term and short-term objectives and drivers of the ecosys-
tem. Well-designed token economics, with rules and incentives, can define the
long-term outcomes of token ecosystems. Poorly designed ecosystems can lead
to the collapse of the ecosystem.

Token ecosystems require coordination within the network. Rules help to in-
crease the coordination. Because tokens are digital, they can be programmed
with certain rules. Those programmable rules can be used to define the activ-
ities the token network does or does not support. The assets and transactions
obey the rules and there are no exceptions, unlike the physical world.

Incentives are a central part of economics and token ecosystems give new ways
to design and build incentive systems. With programmable assets, it is possible
to program incentives and influence users’ behaviours.

1.1 Motivation

The main motivation of this paper is to build the foundational literature for
the field of token economics. This is done by deconstructing existing economics
principles and applying the core concepts to digital and decentralised economies.

Most papers focus on building the cryptography [4] [22], financial model for
token valuation [12] [14], legal regulations [5], regulating ICOs [2] or basics of
the economics for blockchain [13] [8]. This paper seeks to build the foundation
to token economics, so as to develop further valuable research in this new and
evolving field.

1.2 Outline

This paper relies on economic theory to explain the 3 fundamentals pillars of
designing token ecosystems, to achieve sound economics with robust mecha-
nisms, and to identify the factors that could affect the long-term sustainability.
Token economics is more than just valuing the tokens. This paper presents a
framework that considers endogenous factors to value, design and define the
ecosystem.

The paper is organised accordingly: Section 2 starts with the theoretical back-

2



ground on the relevant economic principles. Section 3 shares the methodology
for this theory building paper and Section 4 focuses on expanding the theo-
ries. Section 5 shares the results, with the token economics framework and its
applications to token ecosystems. Section 6 and 7 concludes with discussions,
limitations and further research topics.

2 Theoretical Background

Economists look at markets as given, trying to make predictions about the par-
ticipant’s behaviours and outcomes in the markets. Market design, in contrast,
does not take markets as given. Instead, it combines insights from economics
and game theory, together with lessons learned from empirical work and exper-
imental analysis to aid in the design and implementation of actual markets [34].

Market design is a form of economic engineering [33], where formal rules gov-
ern the interactions of users within the market. It involves the specification
of detailed rules, which are typically analysed using what used to be called
“noncooperative” game theory. The analysis focuses on the incentives for indi-
vidual behaviour in the particular environment considered and its consequences.

It invovles:

• Solving problems in existing marketplaces through incentives

• Making individual strategic decisions through interactions

• Organising and understanding markets through rules

• Considering behavioural economics in the interactions of users

Mechanism design defines the rules of the game [24] to govern actions of partici-
pants, e.g. to incentivise good actions, de-incentivise bad actions and ultimately
influencing participants’ behaviours. Good mechanism design directly affects
the long-term sustainability of decentralised ecosystem. The desired outcomes
in good mechanism design include Pareto efficiency, strategy-proof mechanisms
[21], fairness, or more general goals represented by a Bergson-Samuelson social
welfare function which allow trade-offs between efficiency and equality [24].

Sometimes referred to as token engineering, token design directly relates to
the token in the ecosystem. Based on the token’s function, type, and purpose,
the design of the token varies differently. Tokens, being a core incentive driver,
can take on different functions: securities, utilities or currencies. This greatly
affects the design of the tokens and the domains in economics.

2.1 Research Question

This paper proposes that, to build a robust digital and distributed ecosystem,
one has to consider the factors within the 3 main pillars in token economics:

3



market design, mechanism design and token design.
Together, they build the underlying architecture of the ecosystem, which can
be engineered to optimise the specific objectives of the ecosystem.

3 Methodology

The research is built through reviewing literature in the different domains and
fields of economics. Then, deconstruct them to understand the core economic
principles, which are lastly applied to build the model for token ecosystems.

The core economic principles are focused around market design, mechanism
design and token design. The domains of reference includes market design, auc-
tion theory, systems designs, allocation mechanisms, property rights, monetary
economics, game theory, principle-agent theory, voting and property rights.

3.1 Market Design

Market design defines the environment which users and the token co-exists so
that markets are operated and governed efficiently [29]. It is important because
a successful market design will encourage users to participate in the network,
increasing the value of the token ecosystem.

In token economics, creators can design more efficient networks and platforms to
provide greater value for participants through sound economics. Market design
achieves this by qualifying the environment that the tokens and participants
co-exist.

Market design shares insights about the market institutions (token ecosystem)
and the general tasks markets have to perform (transactions, validations). Chal-
lenges and difficulties in market design factors are often the roots of market
failures that call for new market designs.

Cheap and ubiquitous [26] technology allow for the creation of “smart mar-
kets”. These markets aggregate complex inputs to determine the best outcome
possible. Markets have to attract enough participation to reach suitable adop-
tion level and reduce congestion when transaction occurs. In addition, markets
need to convey information (e.g. eBay needs to share information about sellers
and products) to make it safe for participation.

3.2 Mechanism Design

Mechanism design provides a coherent framework for analysing this great vari-
ety of institutions [11], with a focus on the problems associated with incentives
and private information. Mechanism design shows which mechanisms are opti-
mal for different participant.

4



The theory of mechanism design [17] takes a systematic look at the design of
institutions and how these affect the outcomes of interactions, to satisfy certain
objectives, assuming that the individuals interacting through the institution
will act strategically and may hold private information that is relevant to the
decision at hand.

3.3 Token Design

Depending on the distributed ledger technology (DLT) system, permissioned or
permission-less, some of the factors in token design may not be relevant.

These token design rules are coded or embedded into the decentralised system,
sometimes with a smart contract. Token design is important to ensure that
participants follow the rules of the tokenised economy. Since token economies
are decentralised, it is important to establish certain rules of the tokens into the
programmable code.

Since token design is engineering the token as a core incentive for participants
in the ecosystem, a significant factor that affects the design is the function of
the token. It could be a security, utility or currency. Depending on the func-
tions, the design can differ greatly under the various economic domains. E.g.
monetary economics, financial economics, property rights.

4 Theory

The theory is built from deconstructing the various economic domains and ap-
plying them to the new decentralised digital ecosystems.

4.1 Market Design

Market design focuses on the environment in which the participants will interact
with each other. Good market design allows trust to develop within the token
ecosystem. This is a type of trust, where participants are able to communicate
their priorities easily [33]. It can only develop if users reasonably believe that
the agents (e.g. other users or users with authority) they use are at least as
good at achieving their goals as they do it themselves.

4.1.1 Factors in Market Design

To work well, marketplaces need to [27]

1. Provide thickness

2. Overcome congestion

3. Make it safe to participate in the eocsystem

5



(a) As opposed to transacting outside the marketplace

(b) As opposed to engaging in strategic behaviour that reduces overall
welfare

4. Consider repugnance in some transactions

5. Run experiments to diagnose and understand market failures and successes

Thickness A market provides thickness when it makes many potential trans-
actions available at the same time so that relevant offers can be compared.
They need to attract a sufficient proportion of potential market participants to
come togehter to transact. The main issue with thickness lies in the network
externalities and other economies of scope [27].

Ease of Congestion A market is congested if there is insufficient time or
resources to fully evaluate all the potentially available transactions. Congestion
is a particular problem of markets with many heterogeneous silimar opportu-
nities. When individuals are faced with congestion, they may react in ways
that damage other properties of the market. Overcoming congestion can be
done by providing sufficient time for consideratoin or making transactions fast
enough, so that market participants can consider enough alternative possible
transactions to arrive at satisfactory ones.

Safety If it is risky to participate in the market, individual participants may
try to manage their risk in ways that damage the market as a whole, or otherwise
try to prevent their trading counterparties from being able to receive other
offers. In the environment of token ecosystems where safety can be measured in
code, an additional layer of safety for participants can be included, like privacy
features, cryptographic agility and peer-reviewed algorithmic codes.

4.2 Mechanism Design

In a centralised system, a central entity can get together and deal with any
situation that does not achieve the objectives. (E.g. government, central banks,
board of directors.) But in the decentralised ecosystem, there need to be rules
in place to reduce bad behaviours and negative outcomes.

Mechanism design is important because it affects the actions and behaviours
of people in the network. It also seeks to account for endogenous preferences
in market design [16], an important contributing factor to efficient mechanism
design.

Mechanism design seems complex, extending classical general equilibrium the-
ory to non-classical environments, and attempting to create a general normative
theory of economic policy [24]. However, they can be broken down into vari-
ous factors: trading institutions, theory of the firm, public choice, industrial

6



organisation, regulation, public economics, finance, macroeconomics, law and
economics, and development.

4.2.1 Factors in Mechanism Design

In the context of token ecosystems, mechanism design needs to consider:

1. Provide adequate governance

2. Include non-financial incentives

3. Design structure of the mechanism

Governance In decentralised ecosystems, governance becomes of utmost im-
portance to govern actions of agents (participants) in the ecosystem. Gover-
nance help to organise the transaction within the ecosystem, make it safe for
participation and prevent congestion when issues arise. This can take various
forms, including the legalisations and design of smart contracts. Klement and
Neeman (2004 [18], 2005 [19], 2008 [20]) discussed the mechanism design frame-
works to identify the procedural mechanisms to minimise the resources needed
in disputes. Heifetz et el [16] (2007) discussed the inclusion of behavioural eco-
nomics analysis to design governance with endogenous preferences.

Governance constrains the ecosystem differently, depending on the token func-
tion, use-case and objective function. There are concerns with a high degree
of centralisation, inflexible smart contracts, consensus protocols and the regu-
lations and laws of the various judiciaries. It is also not limited to just smart
contracts, but can also include various resolution mechanisms, consensus proto-
cols and other layers of governance.

Non-financial incentives Depending on how attractive financial incentives,
non-financial incentives may also involve different types of mechanism strate-
gies. This helps to further strengthen the incentive-compatible mechanism to
achieve the objectives. Non-financial incentives can reach Nash implementa-
tion theory through the phenomena of possible renegotiation of the mechanism
and observability sans verifiability of contingencies [24]. Reputation is also a
noteworthy variable to reduce information asymmetry, incentivise low-quality
sellers to report their true information [32] and mitigate the moral hazards when
transacting within the economy (Bolton, 2004) [6].

Structure A mechanism provides a structure for the token economy to achieve
Pareto efficiency, produce a dominant strategy [17] (Jackson, 2003), achieving
Egalitarian mechanism or feasible utility profile that is Lorenzo dominant [33]
(Vulkan et al., 2003). Further study by Makris and Renou [23] (2018) shares
about the design model in multi-stage games and solution to bilateral bargaining
problems. These structures can involve various (incomplete) contract theories,

7



resolving asymmetric information between participants and quasilinear prefer-
ences over allocations to achieve the desired outcome in the ecosystem.

A problem in mechanism structure lies in ecosystems with opposing outcome
functions (e.g. stakeholders’ vs shareholders’ objectives). It is unclear how use-
ful traditional mechanism design theory will be in these contexts; e.g. whether
approaches based on analysis of specific mechanisms will be more useful than
the attempt to characterize optimal mechanisms. Nevertheless, it is precisely by
exploiting the special features of many important economic contexts that this
approach has generated significant new insights [24].

4.3 Token Design

Token design is highly dependent on the token type and token function. i.e.
Security, Utility, Currency To work well, tokens need to

• Define the token policy

• Reward with financial incentives to encourage specific behaviours outlined
in Mechanism Design

• Design proper architecture of the token – that is to consider aspects of the
tokens including property rights, identity, payoffs.

• Mathematical proofs or models for necessary valuation, supply, etc.

Token policy Token policy is adapted from traditional monetary economics
and monetary policy. It seeks to design how tokens, incentive itself, will be
managed and governed, unlike mechanisms where it seeks to design how the
system mechanism is governed and managed.

Traditional monetary policy includes open market operations, discount rates,
required reserves and quantitative easing. The equivalent in token policy is
to open the market by listing on exchanges or secondary market transactions.
Although discount rates are not as applicable in the decentralised market, the
direct application is through the savings function of the mechanism. Catalini
and Gans (2018) summarise that the incentives for token holders to save is a
function of the expected growth in demand of the platform and expected growth
in money supply. The required reserves can be achieved through saving choices
as the ICO design stage [9].

Token policy constraints market differently, based on the objectives of the token
ecosystems, such as ensuring price stability (stable currencies), extracting rent
from token holders (decentralised governance), etc. Unlike monetary policy, to-
ken policy can extend to use-cases beyond the function of money. Token policy
also considers expansionary or contractionary policy by altering the number of
tokens available in the network.

8



Financial incentives A market can reach mass adoption much easier with
financial incentives in participating in the token ecosystem. Sometimes this
involves financial rewards for joining (e.g. airdrops), and it can also involve
potential returns to equity owned, arbitrage on the exchange rates of the token
price in dollars in 2 periods. Financial incentives become an important con-
straint to achieving network effects in the ecosystem.

Valuation of token ecosystems is a compelling incentive for venture capital, in-
vestors and buyers to participate in the ecosystem. As token ecosystems derive
its values from ex-ante factors, instead of the Quantity Theory of Money from
ex-post factors (e.g. velocity), a better mechanism should be used. Instead,
we should consider valuation from an endogenous and ex-ante perspective. 2
valuation models for utility tokens uses dynamic price equilibrium and dynamic
adoption are analysed by Catalini and Gans [9] (2018) and Cong et el [12] (2018)
respectively.

Architecture: Property Rights Architecture includes principles from
structure of property rights, payoffs based on property rights, identity and de-
sign of monetary tokens. Property rights are not the resource itself that is
owned, rather the rights to use the resource [1]. With clear definitions of prop-
erty rights come with bargaining power (ex-ante, ex-post), ownership, identity
and property rights. Based on the GHM results regarding ownership, invest-
ments and incentives, there are plenty of papers researching on the topic of
property rights and ownership. Chiu (1998) examines the effect of asset owner-
ship on investment decisions with the absence of contracts [10]. Schmitz (2006)
[30] analyses the payoffs if ex-post bargaining fails. Schmitz (2013) concluded
that it might be optimal to allocate ownership (a property right) to the party
whose investments are less productive, condition that the party has relatively
small ex-post bargaining power [31].

Self-identity is another variable of consideration in the property rights of to-
kens. The role of blockchain is enabling the property rights inherent in the
concept of self-identity [15]. We optimise the token economy for economies with
decentralised participation constraint because participants can stake claims to
the Ricardian rent. This is due to traceability of ownership over the self-identity
without a third-party.

9



5 Results: Token Economics Model

Figure 1: Token Economics Model

This results in a token economics model that consists of the various endogenous
factors to be considered, when developing the token economics model for the
project. (See Appendix A)

The factors are divided into 3 design pillars, Market Design, Mechanism Design
and Token Design. Market design is the design of the environment. Mechanism
design is the design of the overall gears in the token economy. Token design is
the design specific to the token that will be used in the token economy.

5.1 Application of Market Design to Token Ecosystems

Thickness (Size of Network) Bring all the relevant parties who want to
transact together. Make sure to consider the timing of transactions like when
should offers to be made and how long it can be left open.

1. Attract Early Adopters

(a) Incentivise early participation using diminishing returns mechanisms
(E.g. Bitcoin block reward, Loom limited edition NFT)

2. Partnerships

(a) Partner with related companies to drive early adoption and bootstrap
network effect (E.g. Alliances and consortium)

10



(b) Tokens to entice network partnership between companies and users

3. Bonuses

(a) Extra token if someone joins the network through referral

(b) Airdrop

Ease of Congestion Ensure that there is sufficient time to consider the op-
tions. Otherwise, there are too many offers and no time to consider them.
Resolve this issue by having the system to help people make better choices and
reduce information asymmetry.

1. Govern Transaction

(a) Grade transactions and remove low-quality transactions to ease con-
gestion

(b) Meter bandwidth

2. Charge Fees

(a) Access fees

(b) Congestion fees

3. Governing validators

(a) Fixed set of validators for consensus (E.g. EOS)

(b) Randomly select groups of nodes for consensus (E.g. Cardano, Dfin-
ity)

(c) Specifying super-nodes with authority for consensus (E.g. Maker-
Dao)

(d) Proof of Authority Notary notes (E.g. Hyperledger Fabric, Corda)

Ease of use (Safe and simple participation) Make it easy for people to
join and also make it safe for them to transact.

1. Resolving asymmetric information

2. Staking

(a) Safety deposits that can be activated during a dispute

(b) Skin in the game so everyone is less likely to a bad actor (E.g. Algo-
rand, Ethereum)

3. Privacy Features

(a) Privacy mechanisms like zero-knowledge proofs (E.g. zCash, Quo-
rum, Corda)

(b) Ring signatures (E.g. Monero)

11



4. Cryptographic Ability

(a) Post-quantum security (E.g. QRLedger, IOTA, Corda)

(b) Compatibility with hardware secure models and better key manage-
ment

5. Peer-reviewed White papers

(a) Fundamental algorithmic issues (E.g. algorithm and code that pro-
duces skewed results, creating non-random outcomes , collisions and
forgery )

5.2 Application of Mechanism Design to Token Ecosys-
tems

Governance (Rules and strategies) To govern actions within the token
ecosystem in a decentralised manner, should something arise, there must be
balance between automation and human inputs.

1. Consensus (Participants can have a say in this process)

(a) Various decentralised layers of governance, in case of external faults,
with different objectives (E.g. MakerDao’s varying layers of gover-
nance)

(b) Honest interaction between participant

i. TCR mechanism to reveal true value
ii. Layered TCR (Ocean Protocol)
iii. Design details

2. Resolution Mechanisms (Automated mechanism)

(a) Smart contracts: Hardcoded into the system (E.g. Money will auto-
matically be paid when actions are done/goals are met.)

(b) Schelling point (E.g. Schellingcoin)

Non-Financial Incentives (Other incentives to strengthen strategy)
Ensure that incentives account for financial and non-financial variables to strengthen
the strategy desired in the mechanism design.

1. Voting Protocol (Participants can have a say in this process)

(a) Commit-reveal (E.g. Ethereum smart contract)

(b) Quadratic Voting (Similar concepts E.g. Dfinity, Tezos, Futarchy,
PeerVote)

(c) Quorum voting (E.g. Dfinity)

(d) Delegated voting (E.g. Tezos)

(e) Partial-Lock Commit-Reveal Voting (E.g. Token Curated Registries)

12



(f) Politeia voting (E.g. Dcred, Politeia)

(g) Conviction Voting (E.g. Giveth)

2. Allocation mechanisms (Automated mechanism)

(a) Reputation: to mitigate the moral hazard problems when transacting

(b) Egalitarian mechanism models (E.g. Algorand)

Structure (incentives, strategies and efficient trade) Ensure that the
underlying mechanism that allows the ecosystem to run is efficient. Strategy
needs to prevent bad actors from colluding.

1. Bargaining Protocols (Participants can have a say in this process)

(a) Auction mechanisms: multi-attribute auctions, payment mechanisms
, pace of auctions [28] as solutions to congestion and safety issues

(b) Bargaining payment mechanism (within the ecosystem): fixed price,
first price, second price, Vickrey-Clarke-Groves, Reverse Dutch, All-
Pay

2. Community information (Automated mechanism)

(a) Oracles to aggregate the flow of information and data within the to-
ken ecosystem (E.g. Etherisc, TLSNotary, VeChain, Weeve, Oraclize,
Blockchain Nervous System in Difinity, Ultimate Oracle in Gnosis)

5.3 Application of Token Design to Token Ecosystems

Token Structure (Properties of the token) How the token is specifically
designed, that can be defined and coded into the token ecosystem.

1. Token policy

(a) Supply of tokens; Expected growth of money supply

(b) Saving function of tokens

(c) Inflation/deflation tokens

(d) Distribution of token allocation

(e) Velocity (if necessary)

2. Token valuation: variables that can allow tokens to have endogenous value

(a) Token bonding curve and curated markets

(b) Expected value of funds

(c) Dynamic price equilibrium [3]

(d) Exchange rate of tokens to dollars reflect buyer’s willingness to buy
(ex-ante, market clearing condition)

13



(e) Scarcity of tokens included by pricing choices causes buyer competi-
tion that reveals consumer values

(f) Rational expectation of exchange rate in next period by agents

(g) Value of price commitments

(h) Demand growth from demand of buyers

(i) Savings function/incentives to save

(j) Function of expected growth through demand of platform or money
supply

(k) Value to consumer

(l) Heterogeneity of user base

(m) Platform productivity

Financial Incentives Rewards for participating in the token economy to fur-
ther strengthen the incentive-compatible mechanism to achieve the objectives.

1. Platform activities

(a) Transaction fees

(b) Rewards for joining the network

(c) Discount tokens [7]

(d) Referral links

(e) Reward policies beyond mining [14]

2. Returns to investment

(a) Potential returns to equity owned

(b) Arbitrage on exchange rates of token prices

Architecture (Design of token structure) Tokens can help to govern ac-
tions through property rights and establish trust through scale economies.

1. Property rights

(a) Economics of property rights: claim rights, ownership rights, and
governance

(b) Self-identity

2. Distribution

(a) Scale economics: balancing size and trust. The larger the blockchain
and the more heterogeneous its participants, the more politically
complex is the challenge of setting strategy.

(b) Allocation and lock-up of tokens in various time periods

3. Peer-reviewed Algorithm and Code

14



6 Discussion and Further Research

6.1 Discussion

This is a general base framework for designing a token ecosystem. The factors
in the token economics framework have differing level of significance. For exam-
ple, governance under Mechanism Design is more important than some factors.
As the ecosystem moves towards decentralisation, decentralised governance will
become a crucial factor for the robustness of the ecosystem.

Not all factors are always applicable to the token ecosystem. Some permis-
sioned ecosystems do not require tokens, hence, there is no need to consider the
properties of token policy. However, the tokens could represent an asset and
property rights would be a relevant factor to consider.

The endogenous factors define the success and value from within the token
ecosystem. There are other external factors like the interaction with the real-
world ecosystem and factors relevant to the project itself (i.e. team, choice of
blockchain platform, regulations, jurisdictions).

As much as part of the mechanism design can be automated with code, it
is important to balance both digital decision making and decentralised partici-
pants’ decisions. The left factors under Mechanism Design are factors that allow
for users’ participation. The right factors are factors that have a high level of
automation within the system, usually governed by code. (See Figure 1)

6.2 Limitations

This paper is only the start of this new field. The current factors can benefit
from further creative design mechanisms, which were not included, like voting
(quadratic voting ) and creative allocation of digital property rights (Harberger
tax).

It also focuses mainly on the factors that affects the system and architecture of
the ecosystem. It does not include other critical factors like performance of the
blockchain platform and algorithms underlying the specific DLT.

Lastly, the framework is based upon the reasonability rationality of partici-
pants. However, humans are irrational. Hence, the framework is limited by
the irrationality of human behaviours that is not mitigated by the economical
design.

6.3 Further Research

Future research will focus on expanding on the various endogenous factors, in-
cluding auction mechanisms, incomplete contract theory, agent-principle theory,

15



second-price discrimination, and systems architecture from computer science.

In addition, further studies on the exogenous factors like expertise of the team,
regulations and blockchain platform and its popularity will be reviewed. They
also determine the value and success of a token ecosystem, be it in a permis-
sioned or permission-less distributed leger technology. Outside of the token
ecosystem, future studies can include important external factors like different
legislations, global jurisdictions and macro-economy of digital assets as a whole.

Finally, additional research based on consumer psychology and behavioural eco-
nomics can help to better design robust ecosystems for decentralised environ-
ments.

7 Conclusion

This paper introduces the framework to design the economics of new decen-
tralised and token-based ecosystems. It comes in 3 pillars: market design,
mechanism design and token design.

Market design governs the environment of the network, mechanism design gov-
erns the rules of the network. Token design governs the actions of the people
on the network through direct incentives.

The discussion illustrates the important roles played by economics in design-
ing sound mechanisms, using endogenous factors within the token ecosystem.
These designs take an engineering approach with economic foundations applied.

Incentives and rules need to be designed so that ecosystems can produce ro-
bust outcomes and are resilient to externalities (gaming and collusion). The
largest obstacle with designing ecosystems lies in the complexity of human ob-
jectives and bounds of rational judge";"""date"",""2020-05-19T03:40:49Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2020-05-19T03:40:49Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.19 (TeX Live 2018) kpathsea version 6.3.0""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2020-05-19T03:40:49Z""
""created"",""2020-05-19T03:40:49Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-05-19T03:40:49Z""
""resourceName"",""Economics-Design-and-Engineering-for-Robust-DLT-Ecosystems-.pdf""
""Author"",""""
""producer"",""pdfTeX-1.40.19""
""pdf:docinfo:producer"",""pdfTeX-1.40.19""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2020-05-19T03:40:49Z""
""Last-Modified"",""2020-05-19T03:40:49Z""
""dcterms:modified"",""2020-05-19T03:40:49Z""
""title"",""""
""Last-Save-Date"",""2020-05-19T03:40:49Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2020-05-19T03:40:49Z""
""meta:save-date"",""2020-05-19T03:40:49Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.19 (TeX Live 2018) kpathsea version 6.3.0""
""Content-Length"",""321462""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""20""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""1751"",""1989"",""2157"",""1959"",""1677"",""2141"",""2216"",""2126"",""2037"",""928"",""1118"",""1432"",""1466"",""1218"",""1941"",""1436"",""1833"",""1779"",""576"",""657""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-05-19T03:40:49Z""
";https://scholar.google.ch/scholar?start=700&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098848-295;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Analysis Toward RLWE-Based Key Exchange Protocol Based on Automatic Learning Structure;S Zhu, Y Han ; International Conference on Security and Privacy in …, 2020  Springer;;"… 4.5. The adversary's backend collects all the responses for each key exchange process, and

builds the guess oracles for four attack instances respectively … During the constructing of guess

oracle, the adversary can arbitrarily make transformation on collected samples …";Autres articles;;null;;;;https://scholar.google.ch/scholar?start=840&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098875-355;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Efficient Verifiable Delay Functions;B Wesolowski ; Journal of Cryptology, 2020  Springer;;"… Watermarking consists in tying a proof to the evaluator's identity; in a blockchain setting, this allows

to give credit (and a reward) to the party who spent time and resources … ({\mathcal {B}}^{{mathcal

{O}}}(x)\) outputs a value \({y}\), where \({\mathcal {O}}\) is an oracle that outputs …";Cité 4 fois;Les 3 versions;[PDF] cwi.nl;https://ir.cwi.nl/pub/30021/Wesolowski2020_Article_EfficientVerifiableDelayFuncti.pdf;"
https://doi.org/10.1007/s00145-020-09364-x
J Cryptol (2020) 33:2113–2147

Efficient Verifiable Delay Functions
Benjamin Wesolowski

Univ. Bordeaux, CNRS, Bordeaux INP, IMB, UMR 5251, 33400 Talence, France
INRIA, IMB, UMR 5251, 33400 Talence, France

Cryptology Group, CWI, Amsterdam, The Netherlands
benjamin.wesolowski@math.u-bordeaux.fr

Communicated by Masayuki Abe

Received 21 October 2019 / Revised 27 July 2020
Online publication 9 September 2020

Abstract. We construct a verifiable delay function (VDF). A VDF is a function whose
evaluation requires running a given number of sequential steps, yet the result can be
efficiently verified. They have applications in decentralised systems, such as the gener-
ation of trustworthy public randomness in a trustless environment, or resource-efficient
blockchains. To construct our VDF, we actually build a trapdoor VDF. A trapdoor VDF
is essentially a VDF which can be evaluated efficiently by parties who know a secret
(the trapdoor). By setting up this scheme in a way that the trapdoor is unknown (not
even by the party running the setup, so that there is no need for a trusted setup environ-
ment), we obtain a simple VDF. Our construction is based on groups of unknown order
such as an RSA group or the class group of an imaginary quadratic field. The output of
our construction is very short (the result and the proof of correctness are each a single
element of the group), and the verification of correctness is very efficient.

Keywords. Time-lock puzzle, VDF, Randomness beacon, RSA, Class group.

1. Introduction

We describe a function that is slow to compute and easy to verify: a verifiable delay
function (henceforth, VDF) in the sense of [4].1 These functions should be computable
in a prescribed amount of timeΔ, but not faster (the timemeasures an amount of sequen-
tial work, that is work that cannot be performed faster by running on a large number of
parallel cores), and the result should be easy to verify (i.e. for a cost polylog(Δ)). These
special functions are used in [25] (under the name of slow-timed hash functions) to con-
struct a trustworthy randomness beacon: a service producing publicly verifiable random
numbers, which are guaranteed to be unbiased and unpredictable. These randomness
beacons, introduced by Rabin [30], are a valuable tool in a public, decentralised setting,

1The paper [4] was developed independently of the present work, yet we adopt their terminology for
verifiable delay functions, for the sake of uniformity.

Š International Association for Cryptologic Research 2020

http://crossmark.crossref.org/dialog/?doi=10.1007/s00145-020-09364-x&domain=pdf


2114 B. Wesolowski

as it is not trivial for someone to flip a coin and convince their peers that the outcome
was not rigged. A number of interesting applications of VDFs have recently emerged—
see [4] for an overview. Most notably, they can be used to design resource-efficient
blockchains [12], eliminating the need for massively power-consuming mining farms.
VDFs play a key role in the Chia blockchain design (chia.net), and the Ethereum
Foundation (ethereum.org) and Protocol Labs (protocol.ai) are teaming up to
investigate the technology of VDFs which promise to play a key role in their respective
platforms.
There is thereby a well-motivated need for an efficient construction. This problem

was left open in [4], and we address it here with a new, simple, and efficient VDF.

1.1. Contribution

An efficient construction The starting point of our construction is the time-lock puzzle
of Rivest, Shamir and Wagner [31]: given as input an RSA group (Z/NZ)×, where N
is a product of two large, secret primes, a random element x ∈ (Z/NZ)×, and a timing
parameter t , compute x2

t
. Without the factorisation of N , this task is assumed to require

t sequential squarings in the group. More generally, one could work with any group G
of unknown order. This construction is only a time-lock puzzle and not a VDF, because
given an output y, there is no efficient way to verify that y = x2

t
.

The new VDF construction consists in solving an instance of the time-lock puzzle of
[31], and computing a proof of correctness, which allows anyone to efficiently verify
the result. Fix a timing parameter Δ, a security level k (say, 128,192, or 256), and a
group G. Our construction has the following properties:

1. It isΔ-sequential (meaning that it requiresΔ sequential steps to evaluate) assuming
the classic repeated squaring assumption of [31] in the group G.

2. It is sound (meaning that one cannot produce a valid proof for an incorrect output)
under some group theoretic assumptions on G, believed to be true for RSA groups
and class groups of quadratic imaginary number fields.

3. The output and the proof of correctness are each a single element of the group
G (also, the output can be recovered from the proof and a 2k-bit integer, so it is
possible to transmit a single group element and a small integer instead of 2 group
elements).

4. Theverificationof correctness requires essentially twoexponentiations in the group
G, with exponents of bit-length 2k.

5. The proof can be produced in O(Δ/ log(Δ)) group operations.

For applications where a lot of these proofs need to be stored, widely distributed, and
repeatedly verified, having very short and efficiently verifiable proofs is invaluable.
Following discussion about the present work at the August 2018workshop at Stanford

hosted by the Ethereum Foundation and the Stanford Center for Blockchain Research,
we note that our construction features two other useful properties: the proofs can be
aggregated and watermarked. Aggregating consists in producing a single short proof
that simultaneously proves the correctness of several VDF evaluations. Watermarking
consists in tying a proof to the evaluator’s identity; in a blockchain setting, this allows



Efficient Verifiable Delay Functions 2115

to give credit (and a reward) to the party who spent time and resources evaluating the
VDF. These properties are discussed in Sect. 7.

Note that the method we describe to compute the proof requires an amount
O(Δ/ log(Δ)) group operations. Hence, there is an interval between the guaranteed
sequential work Δ and the total work (1 + ε)Δ, where ε = O(1/ log(Δ)). For practical
parameters, this Îľ is in the order of 0.05, and this small part of the computation is easily
parallelisable, so that the total evaluation time with s cores is around (1 + 1/(20s))Δ.
This gap should be of no importance since anyways, computational models do not cap-
ture well small constant factors with respect to real-world running time. Precise timing
is unlikely to be achievable without resorting to trusted hardware; thus, applications of
VDFs are designed not to be too sensitive to these small factors.
If despite these facts it is still problematic in some applications to know the output of

the VDF slightly before having the proof, it is possible to eliminate this gap by artificially
considering the proof as part of the output (the output is now a pair of group elements, and
the proof is empty). The resulting protocol is still Δ-sequential (trivially), and as noted
in Remark 5, it is also sound (note that this is specific to our construction: generically,
adding the proof to the output does not preserve soundness). We also propose a second
method in Sect. 8.1 which allows to exponentially reduce the overhead of the proof
computation at the cost of lengthening the resulting proof by a few group elements.
Trapdoor verifiable delay function The construction proposed is actually a trapdoor
VDF, from which we can derive an actual VDF. A party, Alice, holds a secret key sk
(the trapdoor), and an associated public key pk. Given a piece of data x , a trapdoor VDF
allows to compute an output y from x such that anyone can easily verify that either y
has been computed by Alice (i.e. she used her secret trapdoor), or the computation of
y required an amount of time at least Δ (where, again, time is measured as an amount
of sequential work). The verification that y is the correct output of the VDF for input x
should be efficient, with a cost polylog(Δ).
Deriving a verifiable delay function Suppose that a public key pk for a trapdoor VDF
is given without any known associated secret key. This results in a simple VDF, where
the evaluation requires a prescribed amount of time Δ for everyone (because there is no
known trapdoor).
Now, how to publicly generate a public key without any known associated private

key? In the construction we propose, this amounts to the public generation of a group
of unknown order. A standard choice for such groups is RSA groups, but it is hard to
generate an RSA number (a product of two large primes) with a strong guarantee that
nobody knows the factorisation. It is possible to generate a random number large enough
that with high probability it is divisible by two large primes (as done in [32]), but this
approach severely damages the efficiency of the construction, and leaves more room for
parallel optimisation of the arithmeticmodulo a large integer, or for specialised hardware
acceleration. It is also possible to generate a modulus by a secure multiparty execution of
the RSA key generation procedure among independent parties, each contributing some
secret random seeds (as done in [7]). However, in this scenario, a third party would have
to assume that the parties involved in this computation did not collude to retrieve the
secret. Instead, we propose to use the class group of an imaginary quadratic order. One
can easily generate an imaginary quadratic order by choosing a randomdiscriminant, and
when the discriminant is large enough, the order of the class group cannot be computed.



2116 B. Wesolowski

These class groups were introduced in cryptography by Buchmann and Williams [10],
exploiting the difficulty of computing their orders (and the fact that this order problem is
closely related to the discrete logarithm and the root problems in this group). To this day,
the best known algorithms for computing the order of the class group of an imaginary
quadratic field of discriminant d are still of complexity L |d|(1/2) under the generalised
Riemann hypothesis, for the usual function Lt (s) = exp

(
O

(
log(t)s log log(t)1−s

))
, as

shown in [22,34].
Circumventing classic impossibility results Finally, we further motivate the notion of
trapdoor VDF by showing that it constitutes an original tool to circumvent classic
impossibility results.We illustrate this in Sect. 9 with a simple and efficient identification
protocol with surprising zero-knowledge and deniability properties.

1.2. Time-Sensitive Cryptography and Related Work

Rivest et al. [31] introduced in 1996 the use of time-locks for encrypting data that can
be decrypted only in a predetermined time in the future. This was the first time-sensitive
cryptographic primitive taking into account the parallel power of possible attackers.
Other timed primitives appeared in different contexts: Bellare and Goldwasser [1,2]
suggested time capsules for key escrowing in order to counter the problem of early
recovery. Boneh and Naor [8] introduced timed commitments: a hiding and binding
commitment scheme, which can be forced open by a procedure of determined running
time. More recently, and as already mentioned, the notion of slow-timed hash function
was introduced in [25] as a tool to provide trust to the generation of public random
numbers.
Verifiable delay functions These slow-timed hash functions were recently revisited and
formalised by Boneh et al. [4] under the name of verifiable delay functions. The func-
tion proposed in [25], sloth, is not asymptotically efficiently verifiable: the verification
procedure (given x and y, verify that sloth(x) = y) is faster than the evaluation pro-
cedure (given x , compute the value sloth(x)) only by a constant factor. The authors of
[4] proposed practical constructions that achieve an exponential gap between evaluation
and verification, but do not strictly achieve the requirements of a VDF. For one of them,
the evaluation requires an amount polylog(Δ) of parallelism to run in parallel time Δ.
The other one is insecure against an adversary that can run a large (but feasible) pre-
computation, so the setup must be regularly updated. The new construction we propose
does not suffer these disadvantages.
Succinct arguments The core of the new construction is a method to produce constant
sized and efficiently verifiable proofs that a triple (g, h, t) satisfies h = g2

t
, where g

and h are two elements from a group of unknown order. The verification is significantly
more efficient than direct computation, and proofs for a false statement are practically
impossible to find: these proofs are succinct arguments. The first feasibility results for
such constructions appear in seminal works of Kilian [24] and Micali [27].
Pietrzak’s verifiable delay function Independently from the present work, another effi-
cient VDF was proposed in [29]. The author describes an elegant construction, provably
secure under the classic repeated squaring assumption of [31] when implemented over
an RSA group (Z/NZ)× where N is a product of two safe primes. The philosophy of
[29] is close to our construction: it consists in solving the puzzle of [31] (for a timing



Efficient Verifiable Delay Functions 2117

parameterΔ), and computing a proof of correctness. Their proofs can be computed with
O(

√
Δ log(Δ)) group multiplications. However, the proofs obtained are much longer

(they consist of O(log(Δ)) group elements, versus a single group element in our con-
struction), and the verification procedure is less efficient (it requires O(log(Δ)) group
exponentiations, versus essentially two group exponentiations in our construction—for
exponents of bit-length the security level k in both cases).
In the example given in [31], the group G is an RSA group for a 2048 bit modulus,

and the time Δ is set to 240 sequential squarings in the group, so the proofs are 10KB
long. In comparison, in the same setting, our proofs are 0.25KB long.
Subsequent work Since the first version of this article, our new method to prove correct
exponentiation in a group of unknown order has found applications beyond the construc-
tion of VDFs. Observing that the method allows to prove statements on the form h = ge

for arbitrary integer exponents e (it is a proof of exponentiation, or PoE), Boneh et al.
[6] expand on this technique to construct a proof of knowledge of an integer exponent
(or PoKE). From these, they obtain cryptographic accumulators and vector commitment
schemes that significantly improve over previous constructions.
Extending further in this direction, and still employing the new technique for PoE in

a group of unknown order, BĂźnz et al. [11] construct a new polynomial commitment
scheme for univariate and multivariate polynomials over finite fields, with no trusted
setup. As an application, they build the first universal SNARKs (succinct non-interactive
arguments of knowledge) with practical proof sizes and verification times that do not
require a trusted setup.

1.3. Notation

Throughout this paper, the integer k denotes a security level (typically 128,192, or 256),
and the map H : {0,1}∗ → {0,1}2k denotes a secure cryptographic hash function. For
simplicity of exposition, the function H is regarded as a map from A∗ to {0,1}2k ,
where A∗ is the set of strings over some alphabet A such that {0,1} ⊂ A. The alphabet
A contains at least all nine digits and twenty-six letters, and a special character ďż˝.
Given two strings s1, s2 ∈ A∗, denote by s1||s2 their concatenation, and by s1|||s2 their
concatenation separated by �. The function int : {0,1}∗ → Z≥0 maps x ∈ {0,1}∗
in the canonical manner to the non-negative integer with binary representation x . The
function bin : Z≥0 → {0,1}∗ maps any nonzero integer to its binary representation
with no leading 0-characters, and bin(0) = 0.

2. Trapdoor Verifiable Delay Functions

Let Δ : Z>0 → R>0 be a function of the (implicit) security parameter k. This Δ is
meant to represent a time duration, and what is precisely meant by time is explained
in Sect. 3 (essentially, it measures an amount of sequential work). A party, Alice, has
a public key pk and a secret key sk. Let x be a piece of data. Alice, thanks to her
secret key sk, is able to quickly evaluate a function trapdoorsk on x . On the other hand,
other parties knowing only pk can compute evalpk(x) in time Δ, but not faster (and
importantly parallel computing power does not give a substantial advantage in going



2118 B. Wesolowski

faster, remember that Δ measures the sequential work), such that the resulting value
evalpk(x) is the same as trapdoorsk(x).

More formally, a trapdoor VDF consists of the following components (very close to
the classic VDF defined in [4]):

keygen → (pk, sk) is a key generation procedure, which outputs Alice’s public
key pk and secret key sk. As usual, the public key should be publicly available,
and the secret key is meant to be kept secret.
trapdoorsk(x,Δ) → (y, π) takes as input the data x ∈ X (for some input space
X ), and uses the secret key sk to produce the output y from x , and a (possibly
empty) proof π . The parameter Δ is the amount of sequential work required to
compute the same output y without knowledge of the secret key.
evalpk(x,Δ) → (y, π) is a procedure to evaluate the function on x using only the
public key pk, for a targeted amount of sequential work Δ. It produces the output
y from x and a (possibly empty) proof π . This procedure is meant to be infeasible
in time less than Δ (this will be expressed precisely in the security requirements).
verifypk(x, y, π,Δ) → true or false is a procedure to check if y is indeed the
correct output for x , associated with the public key pk and the evaluation time Δ,
possibly with the help of the proof π .

Note that the security parameter k is implicitly an input to each of these procedures.
Given any key pair (pk, sk) generated by the keygen procedure, the functionality of
the scheme is the following. Given any input x and time parameter Δ, let (y, π) ←
evalpk(x,Δ) and (y′, π ′) ← trapdoorsk(x,Δ). Then, y = y′ and the procedures
verifypk(x, y, π,Δ) and verifypk(x, y

′, π ′,Δ) both output true.
We also require the protocol to be sound, as in [4]. Intuitively, we want that if y′ is not

the correct output of evalpk(x,Δ) then verifypk(x, y
′,Δ) outputs false. We however

allow the holder of the trapdoor to generate misleading values y′.

Definition 1 (Soundness) A trapdoor VDF is sound if any polynomially bounded al-
gorithm solves the following soundness-breaking game with negligible probability (in
k): given as input the public key pk, output a message x , a value y′ and a proof π ′ such
that y′ 
= evalpk(x,Δ), and verifypk(x, y

′, π ′,Δ) = true.

The second security property is that the correct output cannot be produced in time less
than Δ without knowledge of the secret key sk. This is formalised in the next section
via the Δ-evaluation race game. A trapdoor VDF is Δ-sequential if any polynomially
bounded adversary wins the Δ-evaluation race game with negligible probability.

3. Wall-Clock Time and Computational Assumptions

Primitives such as verifiable delay functions or time-lock puzzles wish to deal with the
delicate notion of real-world time. This section discusses how to formally handle this
concept, and how it translates in practice.



Efficient Verifiable Delay Functions 2119

3.1. Theoretical Model

A precise notion of wall-clock time is difficult to capture formally. However, we can
get a first approximation by choosing a model of computation and defining time as an
amount of sequential work in this model. A model of computation is a set of allowable
operations, together with their respective costs. For instance, working with circuits with
gates ∨, ∧ and  which each have cost 1, the notion of time complexity of a circuit
C can be captured by its depth d(C), i.e. the length of the longest path in C. The time
complexity of a Boolean function f is then the minimal depth of a circuit implementing
f , but this does not reflect the time it might take to actually compute f in the real world
where one is not bound to using circuits. A random accessmachinemight perform better,
or maybe a quantum circuit.
A good model of computation for analysing the actual time it takes to solve a prob-

lem should contain all the operations that one could use in practice (in particular the
adversary). From now on, we suppose the adversary works in a model of computation
M. We do not define exactly M, but only assume that it allows all operations a poten-
tial adversary could perform, and that it comes with a cost function c and a time-cost
function t . For any algorithmA and input x , the cost C(A, x) measures the overall cost
of computing A(x) (i.e. the sum of the costs of all the elementary operations that are
executed), while the time-cost T (A, x) abstracts the notion of time it takes to run A(x)
in the model M. For the model of circuits, one could define the cost as the size of the
circuit and the time-cost as its depth. For concreteness, one can think of the modelM as
the model of parallel random-access machines.
All forthcoming security claims are (implicitly) made with respect to the model M.

The repeated squaring assumption of Rivest, Shamir and Wagner [31] can be expressed
as Assumption 1.

Definition 2 ((δ, t)-squaring game) Let k ∈ Z>0 be a difficulty parameter, and A be
an algorithm playing the game. The parameter t is a positive integer, and δ : Z>0 → R>0
is a function. The (δ, t)-squaring game goes as follows:

1. An RSAmodulus N is generated at random by an RSA key-generation procedure,
for the security parameter k;

2. A(N ) outputs an algorithm B;
3. An element g ∈ Z/NZ is generated uniformly at random;
4. B(g) outputs h ∈ Z/NZ.

Then, A wins the game if h = g2
t
mod N and T (B, g) < tδ(k).

Assumption 1 (Repeated squaring assumption) There is a cost function δ : Z>0 →
R>0 and a small constant Îľ > 0 such that the following two statements hold:

1. There is an algorithm S such that for any modulus N generated by an RSA key-
generation procedure with security parameter k, and any element g ∈ Z/NZ, the
output of S(N , g) is the square of g, and T (S, (N , g)) < (1 + ξ)δ(k);



2120 B. Wesolowski

2. For any t ∈ Z>0, no algorithm A of polynomial cost2 wins the (δ, t)-squaring
game with non-negligible probability (with respect to the difficulty parameter k).

The function δ encodes the time-cost of computing a single modular squaring, and
Assumption 1 expresses that without knowledge of the factorisation of N , there is no
faster way to compute g2

t
mod N than performing t sequential squarings.

With this formalism, we can finally express the security notion of a trapdoor VDF.

Definition 3 (Δ-evaluation race game) Let A be a party playing the game. The pa-
rameter Δ : Z>0 → R>0 is a function of the (implicit) security parameter k. The
Δ-evaluation race game goes as follows:

1. The random procedure keygen is run and it outputs a public key pk;
2. A(pk) outputs an algorithm B;
3. Some data x ∈ X is generated according to some random distribution of min-

entropy at least k;
4. BO(x)outputs a value y,whereO is anoracle that outputs the evaluation trapdoorsk

(x ′,Δ) on any input x ′ 
= x .

Then, A wins the game if T (B, x) < Δ and evalpk(x,Δ) outputs y.

Definition 4 (Δ-sequential) A trapdoor VDF is Δ-sequential if any polynomially
bounded player (with respect to the implicit security parameter) wins the above Δ-
evaluation race game with negligible probability.

Observe that it is useless to allowA to adaptively ask for oracle evaluations of theVDF
during the execution of A(pk): for any data x ′, the procedure evalpk(x ′,Δ) produces
the same output as trapdoorsk(x

′,Δ), so any such request can be computed by the
adversary in time O(Δ).

Remark 1 Suppose that the input x is hashed as H(x) (by a secure cryptographic hash
function) before being evaluated (as is the case in the construction we present in the next
section), i.e.

trapdoorsk(x,Δ) = tsk(H(x),Δ),

for some procedure t , and similarly for eval and verify. Then, it becomes unnecessary
to give to B access to the oracleO. We give a proof in Appendix A when H is modelled
as a random oracle.
We choose to give B oracle access to O (thereby differing from the sequentiality

defined in [4]) because it provides stronger security, ruling out undesirable properties
like the VDF being a group homomorphism (see Remark 3).

Remark 2 At the third step of the game, the bound on the min-entropy is fixed to k. The
exact value of this bound is arbitrary, but forbidding low entropy is important: if x has a

2i.e. C(A, g) = O( f (len(g))) for a polynomial f , with len(g) the binary length of g.



Efficient Verifiable Delay Functions 2121

good chance of falling in a small subset of X , the adversary can simply precompute the
VDF for all the elements of this subset.

3.2. Timing Assumptions in the Real World

Given an algorithm, or even an implementation of this algorithm, its actual running time
will depend on the hardware onwhich it is run. If the algorithm is executed independently
on several single-core general purpose CPUs, the variations in running time between
them will be reasonably small as overclocking records on clock-speeds barely achieve
9GHz (cf. [14]), only a small factor higher than a common personal computer. Assuming
the computation is not parallelisable, using multiple CPUs would not allow to go faster.
However, specialised hardware could be built to perform a certain computation much
more efficiently than on any general purpose hardware.
For these reasons, the theoretical model developed in Sect. 3.1 has a limited accuracy.

To resolve this issue, and evaluate precisely the security of a timing assumption like
Assumption 1, one must estimate the speed at which the current state of technology
allows to perform a certain task, given a possibly astronomical budget. To this end,
the Ethereum Foundation and Protocol Labs [19] are currently investigating extremely
fast hardware implementations of RSA multiplication, and hope to construct a piece
of hardware close enough to today’s technological limits, with the goal of using the
present construction in their future platforms. Similarly, the Chia Network has opened a
competition for very fast multiplication in the class group of a quadratic imaginary field,
a choice of group with several advantages over RSA groups, as discussed in Example 2.

4. Construction of the Verifiable Delay Function

Let x ∈ A∗ be the input at which the VDF is to be evaluated. Alice’s secret key sk
is the order of a finite group G, and her public key is a description of G allowing to
compute the group multiplication efficiently. We also assume that any element g of G
can efficiently be represented in a canonical way as binary strings bin(g). Also part of
Alice’s public key is a hash function HG : A∗ → G.

Example 1 (RSA setup) A natural choice of setup is the following: the group G
is (Z/NZ)× where N = pq for a pair of distinct prime numbers p and q, where
the secret key is (p − 1)(q − 1) and the public key is N , and the hash function
HG(x) = int(H(“residue""||x)) mod N (where H is a secure cryptographic hash
function). For a technical reason explained later in Remark 4, we actually need to work
in (Z/NZ)×/{±1}, and we call this the RSA setup.

Example 2 (Class group setup) For a public setup where we do not want the private
key to be known by anyone, one could choose G to be the class group of an imaginary
quadratic field. This construction is presented in more detail in Sect. 4.3.

Consider a targeted evaluation time given by Δ = tδ for a timing parameter t , where
δ is the time-cost (i.e. the amount of sequential work) of computing a single squaring in
the group G (as done in Assumption 1 for the RSA setup).



2122 B. Wesolowski

To evaluate the VDF on input x , first let g = HG(x). The basic idea (which finds
its origins in [31]) is that for any t ∈ Z>0, Alice can efficiently compute g2

t
with two

exponentiations, by first computing e = 2t mod |G|, followed by ge. The running
time is logarithmic in t . Any other party who does not know |G| can also compute g2

t

by performing t sequential squarings, with a running time tδ. Therefore anyone can
compute y = g2

t
but only Alice can do it fast, and any other party has to spend a time

linear in t . However, verifying that the published value y is indeed g2
t
is long: there

is no shortcut to the obvious strategy consisting in recomputing g2
t
and checking if it

matches. To solve this issue, we propose the following public-coin succinct argument,
for proving that y = g2

t
. The input of the interaction is (G, g, y, t). Let Primes(2k)

denote the set containing the 22k first prime numbers.

1. The verifier samples a prime ďż˝ uniformly at random from Primes(2k).
2. The prover computes π = g
2t/�� and sends it to the verifier.
3. The verifier computes r = 2t mod ďż˝, (the least positive residue of 2t modulo ďż˝),

and accepts if g, y, π ∈ G and π�gr = y.

Now, it might not be clear how Alice or a third party should compute π = g
2t/��. For
Alice, it is simple: she can compute r = 2t mod ďż˝. Then we have 
2t/�� = (2t − r)/�,
and since she knows the order of the group, she can compute q = (2t − r)/� mod |G|
and π = gq . We explain in Sect. 4.1 how anyone else can compute π without knowing
|G|, with a total of O(t/ log(t)) group multiplications.

This protocol is made non-interactive using the Fiat–Shamir transformation, by letting
ďż˝ = Hprime(bin(g)|||bin(y)), where Hprime is a hash functionwhich sends any string
s to an element of Primes(2k).We assume in the security analysis below that this function
is a uniformly distributed random oracle. The procedures trapdoor, verify, and eval are
fully described in Algorithms 1, 2, and 3, respectively.

Remark 3 Instead of hashing the input x into the group G as g = HG(x), one could
be tempted to consider x ∈ G. However, the function x �→ x2

t
being a group homo-

morphism, bypassing the hashing step has undesirable consequences. Note that being a
group homomorphism renders the construction insecure under Definition 3, where B is
given oracle access to the trapdoor: given the outputs corresponding to xy and y−1 for
any y ∈ G\{1G , x−1}, an adversary can recover the output for x .

Verification It is straightforward to check that the verification condition π�gr = y holds
if the evaluator is honest. Now, what can a dishonest evaluator do? That question is
answered formally in Sect. 6, but the intuitive idea is easy to understand. We will show
that given x , finding a pair (y, π) different from the honest one amounts to solve a
root-finding problem in the underlying group G (supposedly hard for anyone who does
not know the secret order of the group). As a result, only Alice can produce misleading
proofs.
Consider the above interactive succinct argument, and suppose that the verifier accepts,

i.e. π�gr = y, where r is the least residue of 2t modulo �. Since r = 2t − �
2t/��, the
verification condition is equivalent to

yg−2t =
(
πg−
2t/��)�

.



Efficient Verifiable Delay Functions 2123

Data: a public key pk = (G, HG ) and a secret key sk = |G|, some input x ∈ A∗, a targeted evaluation
time Δ = tδ.

Result: the output y, and the proof π .
g ← HG (x) ∈ G;
e ← 2t mod |G|;
y ← ge;
� ← Hprime(bin(g)|||bin(y));
r ← least residue of 2t modulo �;

q ← (2t − r)�−1 mod |G|;
π ← gq ;
return (y, π);

Algorithm 1: trapdoorsk(x, t) → (y, π)

Data: a public key pk = (G, HG ), some input x ∈ A∗, a targeted evaluation time Δ = tδ, a VDF
output y and a proof π .

Result: true if y is the correct evaluation of the VDF at x , false otherwise.
g ← HG (x);
� ← Hprime(bin(g)|||bin(y));
r ← least residue of 2t modulo �;

if π�gr = y then
return true;

else
return false;

end
Algorithm 2: verifypk(x, y, π, t) → true or false

Data: a public key pk = (G, HG ), some input x ∈ A∗, a targeted evaluation time Δ = tδ.
Result: the output value y and a proof π .
g ← HG (x) ∈ G;

y ← g2
t
; // via t sequential squarings

� ← Hprime(bin(g)|||bin(y));

π ← g
2t /�� ; //";"""date"",""2020-10-08T14:30:01Z""
""pdf:PDFVersion"",""1.6""
""xmp:CreatorTool"",""Springer""
""pdf:docinfo:title"",""Efficient Verifiable Delay Functions""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""Journal of Cryptology, https://doi.org/10.1007/s00145-020-09364-x""
""pdfa:PDFVersion"",""A-2b""
""xmpMM:History:Action"",""converted""
""language"",""en""
""dc:format"",""application/pdf; version=""""A-2b"""""",""application/pdf; version=1.6""
""pdf:docinfo:custom:robots"",""noindex""
""pdf:docinfo:creator_tool"",""Springer""
""access_permission:fill_in_form"",""true""
""xmpMM:History:When"",""2020-10-08T19:59:30Z""
""pdf:encrypted"",""false""
""dc:title"",""Efficient Verifiable Delay Functions""
""xmp:CreateDate"",""2020-09-07T22:02:43Z""
""modified"",""2020-10-08T14:30:01Z""
""cp:subject"",""Journal of Cryptology, https://doi.org/10.1007/s00145-020-09364-x""
""xmpMM:History:SoftwareAgent"",""pdfToolbox""
""pdf:docinfo:custom:CrossMarkDomains[1]"",""springer.com""
""robots"",""noindex""
""pdf:docinfo:subject"",""Journal of Cryptology, https://doi.org/10.1007/s00145-020-09364-x""
""pdf:hasMarkedContent"",""false""
""xmpMM:History:InstanceID"",""uuid:0b2ff03d-391a-4087-819b-17b3d31a0d97""
""xmp:ModifyDate"",""2020-10-08T20:00:01Z""
""pdf:docinfo:creator"",""Benjamin Wesolowski ""
""meta:author"",""Benjamin Wesolowski ""
""meta:creation-date"",""2020-09-07T16:32:43Z""
""pdf:docinfo:custom:CrossmarkMajorVersionDate"",""2010-04-23""
""created"",""2020-09-07T16:32:43Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-09-07T16:32:43Z""
""resourceName"",""Wesolowski2020_Article_EfficientVerifiableDelayFuncti.pdf""
""pdfaid:part"",""2""
""pdf:docinfo:custom:CrossMarkDomains[2]"",""springerlink.com""
""pdf:docinfo:custom:doi"",""10.1007/s00145-020-09364-x""
""pdf:docinfo:custom:CrossmarkDomainExclusive"",""true""
""Author"",""Benjamin Wesolowski ""
""CrossmarkDomainExclusive"",""true""
""doi"",""10.1007/s00145-020-09364-x""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""4"",""2"",""14"",""0"",""6"",""0"",""31"",""20"",""39"",""25"",""21"",""12"",""0"",""6"",""18"",""29"",""28"",""19"",""45"",""6"",""5"",""10"",""24"",""7"",""0"",""0"",""7"",""17"",""4"",""0"",""0"",""0""
""dc:description"",""Journal of Cryptology, https://doi.org/10.1007/s00145-020-09364-x""
""access_permission:modify_annotations"",""true""
""dc:creator"",""Benjamin Wesolowski ""
""description"",""Journal of Cryptology, https://doi.org/10.1007/s00145-020-09364-x""
""dcterms:created"",""2020-09-07T16:32:43Z""
""Last-Modified"",""2020-10-08T14:30:01Z""
""dcterms:modified"",""2020-10-08T14:30:01Z""
""title"",""Efficient Verifiable Delay Functions""
""xmpMM:DocumentID"",""uuid:f70b377a-b9d3-4d1a-a2ab-da77f12189be""
""Last-Save-Date"",""2020-10-08T14:30:01Z""
""CrossMarkDomains[1]"",""springer.com""
""pdf:docinfo:modified"",""2020-10-08T14:30:01Z""
""meta:save-date"",""2020-10-08T14:30:01Z""
""Content-Type"",""application/pdf""
""xmp:MetadataDate"",""2020-10-08T20:00:01Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Benjamin Wesolowski ""
""pdfaid:conformance"",""B""
""dc:language"",""EN""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""35""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""2158"",""2669"",""3207"",""3007"",""2712"",""2346"",""2333"",""2038"",""2556"",""2634"",""1493"",""1574"",""1926"",""1518"",""1678"",""2288"",""2351"",""2530"",""2396"",""2334"",""1693"",""1790"",""2863"",""2725"",""2166"",""1750"",""1750"",""2508"",""2232"",""2117"",""2129"",""2525"",""3136"",""3403"",""1990""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""CrossMarkDomains[2]"",""springerlink.com""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-09-07T16:32:43Z""
""CrossmarkMajorVersionDate"",""2010-04-23""
";https://scholar.google.ch/scholar?start=900&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098857-312;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Non-interactive zero-knowledge in pairing-free groups from weaker assumptions;G Couteau, S Katsumata, B Ursu ; … on the Theory and Applications of …, 2020  Springer;;"… of group elements of the form \((g^x,h^x)\). To transform the sigma protocol into a NIZK for \(

\mathcal {L}_\textsf {DH} \), the idea of the CI framework is to apply the Fiat-Shamir transform,

but instead of using random oracles, the random oracle is replaced with a CI hash function …";Cité 3 fois;Les 3 versions;[PDF] iacr.org;https://eprint.iacr.org/2020/535.pdf;"
Non-Interactive Zero-Knowledge in Pairing-Free Groups from
Weaker Assumptions

Geoffroy Couteau1, Shuichi Katsumata2, and Bogdan Ursu3

1 CNRS, IRIF, UniversitĂŠ Paris-Diderot, France
geoffroy.couteau@ens.fr

2 AIST, Japan
shuichi.katsumata@aist.go.jp
3 ETH Zurich, Switzerland
bogdan.ursu@inf.ethz.ch

Abstract. We provide two new constructions of non-interactive zero-knowledge arguments
(NIZKs) for NP from discrete-logarithm-style assumptions over cyclic groups, without relying on
pairings. A previous construction from (Canetti et al., Eurocrypt’18) achieves such NIZKs under
the assumption that no efficient adversary can break the key-dependent message (KDM) security
of (additive) ElGamal with respect to all (even inefficient) functions over groups of size 2Îť, with
probability better than poly(Îť)/2Îť. This is an extremely strong, non-falsifiable assumption. In
particular, even mild (polynomial) improvements over the current best known attacks on the
discrete logarithm problem would already contradict this assumption. (Canetti et al. STOC’19)
describe how to improve the assumption to rely only on KDM security with respect to efficient
functions while additionally assuming public-key encryption schemes, therefore obtaining an
assumption that is (in spirit) falsifiable.
Our first construction improves this state of affairs. We provide a construction of NIZKs for
NP under the CDH assumption together with the assumption that no efficient adversary can
break the key-dependent message one-wayness of ElGamal with respect to efficient functions
over groups of size 2λ, with probability better than poly(λ)/2cλ (denoted 2−cλ-OW-KDM), for
a constant c = 3/4. Unlike the previous assumption, our assumption leaves an exponential gap
between the best known attack and the required security guarantee.
Our second construction is interested in the case where CDH does not hold. Namely, as a second
contribution, we construct an infinitely often NIZK argument system for NP (where soundness
and zero-knowledge are only guaranteed to hold for infinitely many security parameters), under
the assumption that CDH is easy together with the 2−cλ-OW-KDM security of ElGamal with
c = 28/29 + o(1) and the existence of low-depth pseudorandom generators (PRG).
Combining our two results, we obtain a construction of (infinitely-often) NIZKs for NP under
the 2−cλ-OW-KDM security of ElGamal with c = 28/29 + o(1) and the existence of low-depth
PRG, independently of whether CDH holds. To our knowledge, since neither OW-KDM security
of ElGamal nor low-depth PRGs are known to imply public key encryption, this provides the
first construction of NIZKs from concrete and falsifiable Minicrypt-style assumptions.

Keywords: Non-interactive zero-knowledge arguments, pairing-free groups, KDM security

1 Introduction

Zero-knowledge proof systems, introduced in [25], are a fundamental cryptographic primitive, allowing
a prover to convince a verifier of the veracity of a statement, while not divulging anything beyond
whether the statement is true. When the proof consists of a single message from prover to the verifier,
this results in a non-interactive zero-knowledge proof system (NIZK) [5]. Due to their large number of
applications in cryptography, NIZKs enjoy particular interest, ranging from efficient implementations
to feasibility results.

On Building NIZKs from Concrete Assumptions. While one-way functions are known to be
necessary [45] and sufficient [24] for zero-knowledge proof systems, the exact relation of NIZKs to
other cryptographic assumptions and primitives is considerably less clear. NIZKs are known to exist
in the plain model only for trivial languages [44]. To circumvent this issue, cryptographers design
NIZKs in the common reference string (CRS) model, where a common reference string is honestly

mailto:geoffroy.couteau@ens.fr
mailto:shuichi.katsumata@aist.go.jp
mailto:bogdan.ursu@inf.ethz.ch


2 Geoffroy Couteau, Shuichi Katsumata, and Bogdan Ursu

generated beforehand in a setup phase and is given to both prover and verifier. A large body of
work has been dedicated to the construction of NIZKs in the CRS model from various cryptographic
assumptions. As a result, NIZKs are known to exist from a wide range of assumptions, from pairing
groups [26,27], factorization assumptions [5,17], and indistinguishability obfuscation [51], to circularly-
secure LWE [8] and plain LWE [47]. Yet, in spite of three decades of efforts, it remains an intriguing
open question whether one can construct NIZKs from discrete-logarithm-style assumptions (without
relying on pairing groups), which are among the most well-established assumptions in cryptography.
Here, the only known result is the recent work of [9], which constructs NIZKs under the exponential
key-dependent message security of ElGamal with respect to all (even inefficient) functions. While
this is a remarkable stepping stone, it remains an extremely strong and non-standard assumption.
Therefore, an important question remains open:

“Is it possible to build NIZKs from (weaker) discrete-logarithm-style assumptions?”

NIZKs and Public-Key Encryption. While it is known that one-way functions are a minimal
assumption for zero-knowledge proofs [43, 45], the situation concerning NIZKs is much less clear.
In particular, almost all known concrete constructions of NIZKs to date rely on assumptions which
are known to imply public-key encryption (PKE) (such as factorization, pairing-based assumptions,
indistinguishability obfuscation, and LWE variants). We are aware of only two exceptions to the
above:

– NIZKs built on top of an interactive protocol, through the Fiat-Shamir transform, are “plausibly
secure” when the hash function is instantiated with e.g. SHA3. Hence, these NIZKs are secure
under the tautological assumption that they cannot be broken, and this assumption is not known
to imply PKE (since no structure is required from the hash function).

– The construction of [9] relies on the assumption that it is infeasible to recover k given (ga, gak+f(k))
(with more than a polynomial advantage over the random guess), for every (even inefficient)
function f . This is an extremely strong, non-falsifiable assumption.

The first of these two exceptions is essentially a restatement of our inability to show that NIZKs
imply PKE, while the second requires a very strong and non-falsifiable assumption. This situation
is somewhat unsatisfying, and we view it as an important open question to base NIZKs on concrete
“Minicrypt-style” assumptions (i.e. assumptions not known to imply PKE), while avoiding extreme
non-falsifiable assumptions.

“Is it possible to build NIZKs from (better, concrete) symmetric-style assumptions?”

In fact, the bigger picture is unclear, even for relaxations of NIZKs such as designated-verifier NIZKs
(which are known based on DDH groups [14,31,49], factorization [12], or LPN [35] with a noise rate
that implies PKE). The only known positive results are preprocessing NIZKs (where the prover and the
verifier share a secret key) from flavors of LPN not known to imply PKE [6,7] and designated-prover
NIZKs based on SIS [32].

Interestingly, we note that although the assumption of [9] is not known to imply PKE, a slight
strengthening of the assumption would: assuming that it is hard to recover k given (ga, gk, gak+f(k))
(note the additional gk term) for any (even inefficient) f already implies PKE: setting f such that
gf(k) = Encode(k) where Encode is some efficiently invertible encoding of k into a group element, we
get that the assumption implies CDH (which itself is known to imply PKE). Indeed, a CDH adversary
could, given (ga, gk), compute gak and retrieve Decode(gf(k)) = k from gak+f(k). This illustrates the
fact that the power of unfalsifiable assumptions of this form, allowing f to be arbitrary, can be hard
to estimate, and that classifying them as plausible Minicrypt candidate assumptions is quite shaky.

NIZKs from Correlation Intractability. Our work follows the blueprint of a recent line of research,
which seeks to compile interactive protocols into NIZKs using the Fiat-Shamir paradigm [19], by
instantiating the underlying hash function by a correlation-intractable hash function. Informally, a
correlation-intractable hash function (CIH) with respect to a relation R is a hash function such
that it is infeasible to find an input x satisfying (x,H(x)) ∈ R. CIH have been introduced in [10],
where it was also shown that correlation-intractability for all sparse relations suffices to instantiate
the Fiat-Shamir paradigm. Despite some impossibility results [4], a recent line of work has shown



NIZK in Pairing-Free Groups from Weaker Assumptions 3

how to construct CIH for various sparse relations of interest [8, 9, 29, 30, 47], obtaining NIZKs from
new assumptions. Out of these works, [9] relies on the exponential key-dependent messages (KDM)
security for all (even inefficient) functions of an encryption scheme with universal ciphertexts, which
can be instantiated over pairing-free groups with a suitable variant of ElGamal; unfortunately, this
is an extremely strong assumption, which has several undesirable features. In this paper, we seek to
improve the result of [9] and to construct NIZKs for NP from weaker assumptions over pairing-free
groups.

On the Strong-KDM Security Assumption of [9]. The construction of [9] relies on the following
assumption over cyclic groups: let G be a group of order p ≈ 2λ with a generator g. Then, for any
probabilistic polynomial time adversary A, any function F : Zp 7→ Zp in a family of (possibly
inefficient) functions F , and any superpolynomial function s, it holds that

Pr
(a,k)←rZ2

p

[
A
(
g, ga, gak+F (k)

)
= k

]
≤ s(λ)

2Îť
.

While this assumption is not contradicted by known attacks on the discrete logarithm problem over
suitably chosen elliptic curves, it is an extremely strong assumption, with several undesirable features:

– Optimality.Optimal security means that every PPT adversary has advantage at most λO(1)/2λ. 4

The above assumption requires optimal security, which is equivalent to assuming that no improve-
ment (by more than polynomial factors) to the best known existing attack will ever be found.
Hence, even mild cryptanalytic improvements would already contradict the above assumption.

– Non-Falsifiablity. The above assumption is not falsifiable, in the sense of [21,41], since it might
not be possible to efficiently check whether an adversary breaks the assumption with respect
to some specific inefficient function. However, [8] notes that it is possible to construct NIZKs
even when the functions f considered in the assumption are efficient by additionally assuming
public-key encryption.

Insecurity with Auxiliary Inputs. In the same spirit as knowledge of exponent assumptions,
which are known to become insecure (under obfuscation-style assumptions) when auxiliary inputs
are allowed, unfalsifiable flavors of KDM security have been recently shown to be insecure as soon as
auxiliary inputs are allowed, assuming that LWE is hard and one-way permutations exist [20]. While
this does not directly contradict the unfalsifiable flavor of the assumption above, it makes it very
sensitive to any side information an adversary might have access to when it is used in a higher-level
application.

1.1 Our Contribution

We propose two new constructions of NIZKs, improving over the NIZK of [9] in terms of the underlying
assumption. As noted in [8], the assumption in [9] can be improved to consider only efficient functions
by additionally assuming public-key encryption and thus construct NIZKs based on a falsifiable-style
notion of KDM-security 5. In this work, we remove the need of relying on optimal security of the
underlying assumption, while maintaining the falsifiable flavor of KDM security.

We note that our second construction satisfies a weaker notion of security, infinitely-often security,
where soundness and zero-knowledge are only required to hold for infinitely many security parameters.
For a discussion on the notion of infinitely-often security and its usage in cryptography, please refer
to Appendix A.

In more detail, the assumption at the core of our new construction is a strong flavor of the
OW-KDM security of ElGamal: given a group G of size ≈ 2λ with generator g, the 2−cλ-OW-KDM
4 In the case of DDH groups, the best known generic PPT adversary is Pollard’s rho algorithm [48], which
runs in time O(2Îť/2) and has constant success probability. However, restricted to polynomial time, it only
provides a polynomial advantage over randomly guessing the discrete logarithm. Moreover, it is known [52]
that no generic algorithm with T oracle queries can have better success probability than O

(
T2

2Îť

)
.

5 More precisely, these assumptions are falsifiable in spirit in the sense that they can be modeled as an
efficient game with a challenger, but the winning condition can occur with exponentially small probability.



4 Geoffroy Couteau, Shuichi Katsumata, and Bogdan Ursu

assumption states that for a family of (randomized) efficient functions F , any PPT adversary receiving
an ElGamal ciphertext encrypting F (k) (in the exponent) with the key k is unable to recover the
plaintext with advantage greater than s(Îť)/2cÎť, for any superpolynomial function s:

Pr
(k,a)←rZ2

q

m←rF (k)

[A(g, ga, gak+m) = k] ≤ s(λ)

2cÎť
for some c ∈ [0, 1].

The value c determines the strength of the assumption: c = 1 corresponds to assuming optimal
security (as in [8,9]), while smaller values of c leave a gap between the success probability of the best
known attacks and the success probability that can be tolerated by the assumption. In particular, a
constant c < 1 indicates that the assumption can stand even exponential improvements in the success
probability of the best known attacks. We propose two new NIZK constructions:

1. Our first construction assumes the hardness of CDH. Then, further assuming the 2−cλ-OW-KDM
security of ElGamal with c = 3/4, we propose an adaptively-sound adaptively-multi-theorem
NIZK for all of NP. Both soundness and zero knowledge are computational, the first is implied by
OW-KDM, while the second is implied by CDH.

2. Our second construction aims at analyzing the complementary landscape. More precisely, we inves-
tigate the possibility of building NIZKs in groups where CDH does not hold. Then, further assuming
the 2−cλ-OW-KDM security of ElGamal with c = 28/29+ o(1), together with the assumption that
Goldreich’s PRG [22] instantiated under the Lombardi-Vaikuntanathan predicate [36] is secure up
to some (arbitrarily small) polynomial stretch6, we propose an adaptively-sound, adaptively-multi-
theorem zero-knowledge (infinitely often) NIZK for all of NP. Both soundness and zero knowledge
are computational, the first is implied by OW-KDM, while the second is implied by OW-KDM and
the pseudorandomness of Goldreich’s PRG.

As a direct consequence, combining the above two results, we obtain a construction of (infinitely-
often) NIZKs for NP under the same assumptions, independently of whether CDH holds. Since both our
OW-KDM assumption and the existence of low-depth PRGs are not known to imply PKE, this provides
(to our knowledge) the first NIZK construction from a concrete falsifiable (in spirit) Minicrypt-style
assumption. In both constructions, an important effort is devoted to obtaining the smallest possible
constant c, to minimize the strength of the underlying assumption. We view it as an interesting open
problem to further minimize the value of c, especially in our second construction.

1.2 Our Techniques – First Construction

Both our constructions follow a similar footprint: we start from a ÎŁ-protocol for a carefully chosen, but
limited language. We compile this ÎŁ-protocol using a correlation-intractable (CI) hash function into a
NIZK for the same limited language. Then we use different techniques to bootstrap this restricted NIZK
to NIZK for all of NP, by using them to build a verifiable pseudorandom generator (VPRG) [14,31,49],
which in turns leads to NIZKs for NP. Our approach is inspired by [9]. Their strategy is to design a
correlation-intractable (CI) hash function based on a scheme with universal ciphertexts, which they
use to transform an underlying sigma protocol into a NIZK. In their case, the interactive protocol
is the one in [18, Section 2.1]. We diverge from this approach by applying the CI hash function to
a sigma protocol for a more restricted, but still expressive enough language (which we bootstrap
later to a full-fledged NIZK through VPRGs). Looking ahead, the parameters of the KDM security
assumption are intrinsically tied to the ratio between the size of the first flow of the sigma protocol and
its adaptive soundness. By allowing the underlying sigma protocol to support only a more restricted
language, we expand the field of potential candidates and eventually identify a protocol with a better
first flow/soundness ratio. Our initial attempt is to start with the standard ÎŁ-protocol for the Diffie-
Hellman relation LDH, described in figure 1. Choose a cyclic group G of prime order p, along with
two generators g and h. The relation consists of all pairs of group elements of the form (gx, hx). To
transform the sigma protocol into a NIZK for LDH, the idea of the CI framework is to apply the
Fiat-Shamir transform, but instead of using random oracles, the random oracle is replaced with a CI
hash function.
6 The security of Goldreich’s PRG is a well-established and widely studied assumption, which provably resists
large classes of attacks [2, 3, 13,40,42].



NIZK in Pairing-Free Groups from Weaker Assumptions 5

Prover Verifier
r ←r Zp and

set (R,S) = (gr, hr)
e←r Zp

d = e ¡ x+ r Check gd = Xe ¡R
and hd = Y e ¡ S

(R,S)

e

d

Fig. 1. ÎŁ-protocol for the Diffie-Hellman language for the word (g, h,X = gx, Y = hy). This is a variant of a
protocol by [1]

CI Hash Functions. A CI hash function H for a specific relation R is a function for which it is hard
to find an input ι, such that (ι,H(ι)) ∈ R. Consider the case where the initial relation is sparse,
meaning that for every α, the number of potential β’s satisfying (α, β) ∈ R is negligible. Then, the
above sigma protocol can be transformed into a NIZK by asking the prover to generate the second flow
himself, by running e = H(R,S). The verifier will only accept if the resulting transcript is accepting
and also e = H(R,S). From the correlation intractability of H, even a malicious prover will be unable
to cheat by finding a properly chosen initial flow (R,S), such that ((R,S),H(R,S)) ∈ R (this also
holds because the sparsity of the relation R is bounded by the soundness error of the sigma protocol,
which is negligible).

Choice of H. To construct the hash, we choose a function closely related to the one used in [9], where
the (keyed) hash HK(x) interprets the input x as a decryption key and the key K as a ciphertext, and
returns Decx(K). For our instantiation, we crucially rely on a specific property of the additive variant
of ElGamal (which is, informally, that keys and plaintexts are “interchangeable”). Since additive
ElGamal does not provide efficient decryption (the decryption procedure recovers only G̃m, and we
cannot guarantee that m will be small in our construction), we modify the CI hash of [9] so that it
returns Trunc(G̃m), where Trunc is some function that parses its input as a bitstring and truncates
it appropriately. More precisely, we pick a second cyclic group G̃ of order q, generated by G̃ where
dlog qe = 2dlog pe. The CI function is keyed by key C̃ = (C̃0, C̃1), where (C̃0, C̃1) ←r G̃2. Then, we
define:

H(C̃0,C̃1)
(ι) = first dlog pe bits of C̃1/C̃

Îą
0 .

Parameters. This protocol has 1
p soundness and the size of the first flow is 2dlog pe, which translates

into a 2−λ/2-KDM assumption for the CI hash function. Unfortunately, this Σ-protocol does not
satisfy adaptive soundness (that is, given an honestly-generated first flow and challenge, there always
exist words that are not in the relation, for which there exists an accepting third flow). Adaptive
soundness is a crucial requirement for bootstrapping our first NIZK to cover all NP statements.
Fortunately, performing a parallel repetition of the ÎŁ-protocol yields adaptive soundness, albeit at
the cost of worser parameters in our assumption (c = 3/4).

Reduction to KDM for Efficient Functions. The above construction reduces to the KDM
security of ElGamal, but only with respect to an inefficient function f , which maps first flows to
accepting challenges. (Note that computing the unique accepting challenge e from a first flow (R,S)
amounts to solving the discrete logarithm problem.) From here, we leverage the fact that an ElGamal
encryption (G̃r, G̃kr+m) of a plaintextm with key k, with respect to a generator G̃, can be equivalently
seen as an ElGamal encryption of a plaintext k with the key m with respect to the generator G̃r.
Building upon this observation and the fact that f−1 is efficient, we show that the security of our
NIZK for the DDH language can in fact be reduced to the KDM security of ElGamal with respect to
the efficient function f−1.

From NIZKDH for LDH to a NIZK for all of NP. In this step, we use an idea from [16] (that was
slightly generalized and implicitly employed in recent works [14, 31, 49]). We use the NIZKDH for the
LDH relation to construct a verifiable pseudo-random generator (VPRG), which we then in turn use to
instantiate the hidden bits model of [18], to obtain NIZKs for all of NP. Intuitively, a VPRG is a pseudo-
random generator with the additional property that one can compute proofs for any individual bit of



6 Geoffroy Couteau, Shuichi Katsumata, and Bogdan Ursu

the output, certifying that the bit is consistent with a commitment of the initial seed. Let G be a cyclic
group of order p, the VPRG public parameters will consist of m + 1 group elements (g, h1, . . . , hm).
Seeds are elements τ ←r Zp, and committing to a seed is Commit(τ) = gτ . The ith output bit of the
VPRG is of the form B(gτ , hτi ), where B is the Goldreich-Levin hardcore bit. Now notice than we can
actually certify this as a correctly computed bit, by noticing that (gτ , hτi ) ∈ LDH and computing a
proof using our NIZKDH. (additionally, we need to output hτi as well, so that the verifier can compute
B(gτ , hτi ) itself). Intuitively, this VPRG satisfies the following security properties:

1. Binding: if xi is the ith output of the VPRG with respect to a seed τ , one should not be able to
certify bit 1− xi. This is implied in our construction by the soundness of NIZKDH.

2. Hiding: An adversary should not be able to recover the ith output of the VPRG, even if it received
all the other output bits and proofs certifying that they are correct. In our construction, this
property reduces to the CDH assumption.

NIZK for all of NP through the Hidden-Bit Model. In this model [18], the prover and the
verifier benefit from having access to a common reference string with special properties. The bits of
the common reference string are initially hidden from the verifier. When proving a statement, the
prover can decide to selectively reveal some bits of the common reference string, which allows the
verifier to check the proof. The work of [18] has showed that NIZKs exist unconditionally in this model.
The VPRG we construct allows us to simulate the hidden-bits model on the prover side. Initially, all
bits are hidden from the verifier from the hiding property of the VPRG. Subsequently, the prover can
decide to reveal several bits, which corresponds to computing VPRG proofs.

1.3 Our Techniques – Second Construction

The previous construction relies on the CDH assumption. In our second construction, we take the
complementary road: we seek to construct NIZKs for NP under the strong KDM security of ElGamal
assuming that CDH does not hold. Together with our first construction, this implies a NIZK for NP
that does not rely on the CDH assumption (albeit with an infinitely-often security notion). To this
end, we also seek to build a VPRG.

Self-Pairing. First, we notice that if CDH does not hold, there exists an efficient adversary solving it
with non-negligible advantage. We use previous results by [39, 52] to amplify the success probability
of this adversary to obtain a self-pairing map. Since from the definition of CDH, the adversary is
only guaranteed to succeed on infinitely-many security parameters, our NIZK will be secure only on
infinitely-many security parameters. This self-pairing will allow us to perform homomorphic compu-
tations and to evaluate bounded integer arithmetic circuits in the exponent. Our core idea, informally,
is to rely on this self-pairing to let the parties homomorphically evaluate a pseudorandom generator
in the exponent: at a high level, given a (bit-by-bit) commitment c to the seed, the parties can homo-
morphically compute, using the self-pairing, a commitment ci to the i-th output bit of the PRG (for
all i). Then, the prover will open a given PRG value by providing a NIZK proof of correct opening.

A Commitment from Short-Exponent Discrete Logarithm. To instantiate this idea, we in-
troduce a new commitment scheme which is perfectly binding, and which is hiding under the short-
exponent discrete logarithm assumption (which states that given gx for a random but short x, it is
infeasible to retrieve x). This does not introduce any new assumption, as we further show that the
short-exponent discrete logarithm assumption is implied by the strong OW-KDM security of ElGamal.
Furthermore, we carefully design this commitment scheme so that it suffices, to convince the verifier
that the opening was correct, to demonstrate that the randomness r of the commitment is almost
short. By almost short, we mean that there exists short values (u, v) such that v ¡ r = u mod p. This
turns out to be a crucial property, since the language of group elements with almost-short exponents
is precisely one for which we are able to build a NIZK under the 2−cλ-OW-KDM security of ElGamal,
for some c < 1.



NIZK in Pairing-Free Groups from Weaker Assumptions 7

A ÎŁ-protocol for Almost-Short Exponents. Let G be a cyclic group of p elements. We consider
a simple ÎŁ-protocol for proving that a word gx has a short exponent, i.e. writing x as an integer
yields a number ≤ 2`, for some carefully chosen ` < dlog pe. Our protocol has a similar shape to
the sigma protocol used in the previous construction, and is described in figure 3. However, we are
unable to directly prove soundness, meaning that a malicious prover can convince the verifier of the
validity of words gx, where x is not short. Fortunately, we are able to ensure that if gx is accepted,
then x = u · v−1, where u and v are themselves short. We denote this as the language Lα,β of
(ι, β)-almost-short elements:

Lα,β = {gx | x = u · v−1 ∈ Zp, u ∈ [−2α, 2α], v ∈ [0, 2β ]}.

Our ÎŁ-protocol is somewhat atypical, in the honest run the prover must start with a word of the form
gx and a short witness x (notice that if x is short it belongs to the almost-short language). However,
when proving soundness, we only safeguard membership to the larger almost-short set of words;
therefore, there is a gap between the correctness requirement, and the soundness guarantees (this is
similar to some lattice constructions using the Fiat-Shamir with aborts paradigm, for example [37]).

NIZKAS for the Language of Almost-Short Exponents. We will design another CI hash func-
tion, closely related to the one we built for the first construction, to transform the ÎŁ-protocol above
into a NIZK for the almost-short exponent language. This CI hash function will additionally employ
a 2-universal hash function, which we use to reduce the security loss in our security analysis and
achieve a better parameter c for the OW-KDM assumption. Now, equipped with our NIZKAS, we only
need one final tool before moving on to our VPRG.

A Low-Depth Local PRG. Equipped with the above tools, it remains to find a suitable PRG
to be used in our construction. For correctness, we need to ensure that no overflow occurs during
the homomorphic operations in the exponent; therefore, we must pick the group size large enough
so that the homomorphic PRG evaluation does not cause an overflow. Since picking a larger group
translates into a larger security loss in our reduction, we seek to rely on a PRG (with some arbitrary
small polynomial stretch) that has a minimal arithmetic degree. Fortunately, such PRGs were recently
studied in [36], which exhibits a PRG with arithmetic degree 3 which provably resists a large class
of attacks for a stretch up to 1.25 − ε. Combining this low-degree PRG with our new commitment
scheme and our NIZK for the almost-short language yields a VPRG in groups where CDH does not
hold, hence NIZKs for NP.

Wrapping Up. Combining our first and second construction, we get the following: assume that
ElGamal is 2−cλ-OW-KDM secure with respect to efficient functions (with c = 28/29 + o(1)), and
that the previous PRG is secure. Then either CDH holds, in which case our first construction implies a
NIZK for NP, or CDH does not hold, in which case our second construction implies an (infinitely-often)
NIZK for NP. Therefore, under a PRG assumption and the strong OW-KDM security of ElGamal, we
prove the existence of an infinitely-often NIZK for NP (but our proof is non-constructive, in that it
does not tell which of the two candidate constructions is actually secure; only that one is).

1.4 Organization

Section 2 introduces necessary preliminaries and Section 3 introduces an algorithm for performing ho-
momorphic computation in the exponent under the assumption that CDH is easy. Section 4 presents
our first NIZK construction (assuming that CDH is hard) and Section 5 contains our second construc-
tion (assuming that CDH is easy). Finally, in Section 6, we summarize the consequence of our two
constructions.

2 Preliminaries

Notation. Throughout this paper, Îť denotes the security parameter. A probabilistic polynomial
time algorithm (PPT, also denoted efficient algorithm) runs in time polynomial in the (implicit)
security parameter Îť. A function f is negligible if for any positive polynomial p there exists a bound



8 Geoffroy Couteau, Shuichi Katsumata, and Bogdan Ursu

B > 0 such that, for any integer k ≥ B, |f(k)| ≤ 1/|p(k)|. We will write f(λ) ≈ 0 to indicate that
f is a negligible function of λ; we also write f(λ) ≈ g(λ) for |f(λ) − g(λ)| ≈ 0. An event occurs
with overwhelming probability p when p ≈ 1. Given a finite set S, the notation x ←r S means a
uniformly random assignment of an element of S to the variable x. For a positive integer n,m such
that n < m, we denote by [n] the set {1, · · · , n}, by [±n] the set {−n, · · · , n}, and by [n,m) the set
{n, n + 1, · · · ,m − 1}. Given an element x of a set Zp for prime p, we denote by int(x) the integer
x′ ∈ [±(p−1)/2] such that x = x′ mod p. When manipulating elements (x, y) of Zp, we will generally
abuse the notation and write x ≤ y for int(x) ≤ int(y).

The Computational Diffie-Hellman Assumption. Let DHGen be a deterministic algorithm that
on input 1Îť returns a description G = (G, p) where G is a cyclic group of prime order p. Then the
computational Diffie-Hellman assumption is defined as follows.

Definition 1 (CDH Assumption). We say that the computational Diffie-Hellman (CDH) assump-
tion holds relative to DHGen if for all PPT adversaries A,

Pr
[
G ← DHGen(1λ), g ←r G, α, β ←r Zp : gαβ ←r A(1λ,G, g, gα, gβ)

]
≤ negl(λ).

Here, note that DHGen outputs a fixed group G per security parameter.

2.1 Non-Interactive Zero-Knowledge

A (publicly-verifiable) non-interactive zero-knowledge (NIZK) argument system for an NP relation R,
with associated language L (R) = {x | ∃w, (x,w) ∈ R} is a 3-tuple of efficient algorithms (Setup,Prove,
Verify), where Setup outputs a common reference string, Prove(crs, x, w), given the crs, a word x, and
a witness w, outputs a proof π, and Verify(crs, x, π), on input the crs, a word x, and a proof π, outputs
a bit indicating whether the proof is accepted or not. A NIZK argument system satisfies the following:
completeness, adaptive soundness, and selective single-theorem zero-knowledge properties: (we let RÎť
denote the set R ∩ ({0, 1}λ × {0, 1}∗)).

– A non-interactive argument sy";"""date"",""2020-05-07T06:15:35Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2020-05-07T06:15:35Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.19 (TeX Live 2018) kpathsea version 6.3.0""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2020-05-07T06:15:35Z""
""created"",""2020-05-07T06:15:35Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-05-07T06:15:35Z""
""resourceName"",""535.pdf""
""Author"",""""
""producer"",""pdfTeX-1.40.19""
""pdf:docinfo:producer"",""pdfTeX-1.40.19""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""7"",""0"",""8"",""0"",""4"",""7"",""2"",""8"",""4"",""7"",""55"",""5"",""11"",""11"",""9"",""8"",""10"",""13"",""83"",""43"",""23"",""28"",""23"",""27"",""31"",""33"",""0"",""0"",""0"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2020-05-07T06:15:35Z""
""Last-Modified"",""2020-05-07T06:15:35Z""
""dcterms:modified"",""2020-05-07T06:15:35Z""
""title"",""""
""Last-Save-Date"",""2020-05-07T06:15:35Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2020-05-07T06:15:35Z""
""meta:save-date"",""2020-05-07T06:15:35Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.19 (TeX Live 2018) kpathsea version 6.3.0""
""Content-Length"",""754588""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""33""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""3252"",""3975"",""3610"",""3877"",""3306"",""3644"",""3454"",""3211"",""3069"",""2560"",""2606"",""2844"",""2615"",""2422"",""2386"",""1631"",""2210"",""3296"",""3350"",""3442"",""2817"",""3155"",""1528"",""2341"",""3017"",""3782"",""2901"",""3514"",""3702"",""4008"",""4373"",""855"",""2001""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-05-07T06:15:35Z""
";https://scholar.google.ch/scholar?start=860&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098857-320;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;[PDF][PDF] Transaction Cost;CŘ Gřtze, A Buni? ; Education, 2020  projekter.aau.dk;;"… Reduction in the Construction Industry by Embracing Blockchain Technology … Project Title:

Transaction Cost - Reduction in the Construction Industry by Embracing Blockchain Technology

Project Type and ECTS Points: Master's Thesis 30 ECTS points per student …";Autres articles;Version HTML;[PDF] aau.dk;https://projekter.aau.dk/projekter/files/335183277/Ana_Casper_Master_Thesis.pdf;"
Transaction Cost 
- Reduction in the Construction Industry by 

Embracing Blockchain Technology 

 

 

 

 
 

 

 

 

 

 

 

Casper Østergaard Gøtze 

Ana Bunić 

 

Master's Thesis | MSc in Engineering – Management in the Building Industry 

Department of the Built Environment | Aalborg University 

June 2020 

 



Master’s Thesis at the Faculty of

Engineering and Science

Department of the Built Environment

Thomas Manns Vej 23

9220 Aalborg Ø

byggeri.aau.dk

Project Title:
Transaction Cost -
Reduction in the Construction Industry by
Embracing Blockchain Technology

Project Type and ECTS Points:
Master’s Thesis
30 ECTS points per student

Project Period:
February 2020 - June 2020

Education
Master of Science in Engineering (Msc.) -
Management in the Building Industry

Authors:
Ana Bunić
Casper Østergaard Gøtze

Supervisor:
Søren Munch Lindhard

Pages: 70
Appendix: 73
Hand in date: 10-06-2020

Synopsis:

This master’s thesis researched blockchain
technology’s possibilities in the construction
industry, within a transaction cost framework.
The research started with investigating so-
lutions to reduce unnecessary transaction
costs, which led to a research of blockchain
technology. This led to the problem formula-
tion: How can blockchain technology benefit
the construction industry in relation to reduc-
ing the transaction costs?
The problem formulation was answered
through a literature study, two rounds of inter-
views with first 5 experts within blockchain in
construction and second 3 construction pro-
fessionals, and a conceptual model for using
blockchain in the procurement phase. That
led to the conclusion that blockchain tech-
nology provides high collaboration levels in
a trusting environment through transparency,
traceability, trust in the system and security.

The content of the report is freely available, but publication (with source reference) may only take place in agreement

with the authors.



Abstract

Dette Speciale af kandidatuddannelsen ""Management in the Building Industry"" (Byggeledelse
pü dansk) undersøger, emnet transaktionsomkostninger i byggebranchen og hvordan disse kan
reduceres ved hjĂŚlp af blockchain teknologien.

Dette er gjort gennem, først at lave et litteraturstudie af hvad transaktionsomkostninger er,
hvorefter transaktionsomkostningers betydning i byggebranchen bliver klargjort. dette ender ud i
en pre-problemformulering:

""Hvad kan reducere de unødvendige transaktionsomkostninger i byggebranchen?""

Denne pre-problemformulering besvares gennem de 4 mulige løsninger: Ikke digitale løsninger,
BIM, IoT, Big Data og Machine learning og blockchain technology. En blockchain løsning arbejdes
videre med og ender ud i problemformuleringe:

""Hvordan kan blockchain teknologien sĂŚnke transaktionsomkostninger i byggebranchen?""

Med problemformuleringen in mente, er der lavet et litteraturstudie, som gennemgĂĽr hvordan
blockchain teknologien fungerer og hvordan blockchain teknologien kan bruges i byggebranchen.
Ud fra litteraturstudiet, formuleres der spørgsmül til 1. runde af interviews som bliver lavet med
5 eksperter inden for BCT i byggebranchen. Svarerne fra 1. interview runde og litteraturstudiet
lÌgger grundlag for spørgsmülene til 2. interviewrunde. I 2. interview runde bliver 3 udviklere
spurgt til hvordan BCT kan hjĂŚlpe deres arbejde i byggebranchen. Ud fra den viden som er
indsamlet er der lavet en koncept model, til hvordan BCT kan implementeres i byggebranchen.

Gennem diskussionen er der fundet frem til, at blockchain teknologien generer bedre
samarbejde, i et trovÌrdig miljø gennem transperens, sporbarhed, tillid til systemet samt
sikkerhed, som vil give lavere transaktionsomkostninger.

iii





Preface

This Master thesis has been created by Ana Bunic and Casper Gøtze who study ""Management
in the Building Industry"", at Aalborg University. This report has been made in the time span from
the 1st of February to the 10th of June.

The thesis group want to thank all the companies who have participated in the research of
transaction costs reduction through blockchain technology in the construction industry.

Readers guide
The report utilises the Harvard citation method, and a bibliography can be found in the rear of the
report. All tables and figures in this report have been enumerated after the chapter they appear
in, along with the number they appear in the chapter. For example, Figure 2 in Chapter 1 will has
the name Figure 1.2. If a figure or table does not have a citation, it means it has been produced
by the project group.

In order to keep the report in one language, transcriptions of the interviews have been translated
from Danish to English. The report utilises abbreviations for terms that are used frequently the
list of abbreviations.

Aalborg, June 2020

Ana Bunic and Casper Østergaard Gøtze,

Keywords: Transaction cost, Blockchain technology, Procurement in the construction industry.

List of abbreviations
TC Transaction Costs
TCE Transaction Cost Economics
IoT Internet of Things
BIM Building Information Model
DLT Distributed Ledger Technology
p2p Peer-to-peer

v



Table of Contents

Chapter 1 Introduction 1
1.1 Background and Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Relevance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

Chapter 2 Research Methodology 9
2.1 Project Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2 Philosophies of Science . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.3 Research Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.4 Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.5 Reliability and Validity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

Chapter 3 Pre-Problem Formulation 17

Chapter 4 Approaches to Reduce TC 19
4.1 Non-Digital Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.2 BIM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.3 IoT, Big Data And Machine Learning . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.4 Blockchain Technology (BCT) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.5 Selected Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

Chapter 5 Problem Formulation 25

Chapter 6 Knowledge from Literature - Blockchain Technology 27
6.1 Fundamentals and Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
6.2 Key Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
6.3 Implications for TC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
6.4 BCT in the Construction Industry . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
6.5 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

Chapter 7 Interviews with Experts 43
7.1 Chosing the Interviewees . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
7.2 Introduction to interviewees . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
7.3 Findings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

Chapter 8 Interviews with Construction Professionals 51
8.1 Purpose and Consideration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
8.2 Introduction to Interviewees . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
8.3 Findings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

Chapter 9 Proposals for the Construction Industry 55
9.1 Purpose and Consideration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

vi



Table of Contents Aalborg University

9.2 Conceptual Model of BCT for Procurement and Tendering . . . . . . . . . . . . . 55
9.3 Recommendations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

Chapter 10 Discussion 63
10.1 The Understanding of BCT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
10.2 BCT in Reducing Ex-ante TC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
10.3 BCT in Reducing Ex-post TC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
10.4 Impact of BCT on the Governance Type . . . . . . . . . . . . . . . . . . . . . . . . 65
10.5 Challenges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
10.6 Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

Chapter 11 Conclusion 69

Bibliography 71

Appendix A Interview Guide for Experts 79

Appendix B Interview Guide for Professionals 83

Appendix C Transcription of Interview with HD Lab 91

Appendix D Transcription of Interview with ZĂźblin 103

Appendix E Transcription of Interview with IBM 111

Appendix F Transcription of Interview with Vilhelm Lauritzen 117

Appendix G Transcription of Interview with DI 125

Appendix H Transcription of Interview with S. Enggaard 131

Appendix I Transcription of Interview with Kuben 139

Appendix J Transcription of Interview with VivaBolig 145

vii





CHAPTER

1
Introduction

This chapter introduces the topic and explains the motivation to pursue this topic and its
relevance.

1.1 Background and Motivation

This thesis is taking an offset in the project report written in the previous semester, which
was concerned with modifying the procurement process in the construction industry with
consideration of reducing TCs (Bunic and Gøtze, 2019). The focus was put on the events
during projects that precede the contract signing and all the wastefulness in terms of money,
time and resources that generate TCs. A share of TCs is necessary and expected to ensure that
procurement regulations are followed, fair competition is organised and that the most suitable
solution is awarded. However, a motivating factor to this research remains an unnecessary part
of TCs, which does not add economic value or quality to the construction project. Considering
TCs are the foundation of this research, here follows an overview of literature concerned with
aforementioned, both from economics’ and the construction industry’s perspective.

TC in Economics
A substantial body of knowledge is produced on the subject of TC. The literature is dominated by
two leading scholars and Nobel Laureates, Coase and Williamson, who gave explanatory views
of TCs (Suematsu et al., 2014). Therefore, the following sections will highlight the basic insights
of the two mentioned scholars.
TC theory is one of the theories that are a part of an economic stream called the New Institutional
Economics (NIE) (Obińska-Wajda, 2016). The founder of NIE is considered to be economist
Ronald Coase with his pioneering paper “The theory of the firm” (1937), as claimed by Obińska-
Wajda (2016); Carroll et al. (1999); Rao (2002). Prior to Coase’s article, the classical economists
thought of markets to be frictionless, having no TCs, where resources are reallocated by “the
invisible hand” of the market (Suematsu et al., 2014). Coase opposed the classical economists’
claims by asking the question of why firms exist at all, when the market is such a perfect
mechanism (Suematsu et al., 2014). Later, Coase (2005) clarified that a firm, “a little planned
society”, could only continue to exist if it performed at a lower cost than would be incurred if it
were achieved in the market, and also at a lower cost than it could be performed by another
firm. He states that there is friction in the market and that there are costs of using the pricing
mechanism – discovering what the relevant prices are, negotiation costs, costs of drafting the
contracts, costs of inspections and arrangements for settling disputes. These costs have come
to be known as transaction costs (Coase, 2005). Coase (1937) also explains why then all the
production is not performed by one big company to avoid TC. To answer, Coase (1937) says, as
the company grows, there may be decreasing returns, which means that the costs of organising
additional transaction within the firm may rise. Additionally, a production might not be used in a
way to yield the greatest value and supply price might rise for the larger firm. With those insights,

1



Bunic And Gøtze 1. Introduction

Coase gave a view of boundaries of the firm in terms of decisions about whether to produce
internally or to outsource (make or buy), based on cost minimization (Rao, 2002). Based on his
work, some scholars considered the make-or-buy decision as a focus (Rao, 2002; Shah, 2007)
and paradigm problem (Shelanski and Klein, 1995) of TCE. Suematsu et al. (2014) argues that
TCE addresses the question of the company to produce internally, vertically integrate or buy from
the market.
While Coase started the school of TCE, Williamson extended it and thoroughly studied.
Williamson (2007) claims that a transaction happens when a good or service is transferred
across a technologically separable interface. According to Suematsu et al. (2014), transaction
interfaces are all organisations, processes and systems. The design of these determines the
amount of TC incurred. Williamson (2007) compares transaction with a mechanical system
and the force of friction. More friction in economic exchange means that misunderstandings
and conflicts between exchanging parties occur, which leads to delays and breakdowns. Thus,
more friction brings higher TCs. Williamson claims that the total costs of economic activity are
the sum of production and transaction costs (Winch, 1995). Given that production is efficiently
organised, the question posed is how to keep TC to a minimum (Winch, 1995)? The answer
lies in Williamson’s concept of TCE. He comprehensively explains that TCs differ relative to the
decision of governance type employed. Williamson (1996) supports Coase’s observation that
firms (hierarchies) and markets are alternative forms to manage the very same transaction, and
also allows other different forms of relationships based on collaboration. Williamson (1996) refers
to them as “hybrids”, while Winch (1995) denotes those as “network governances”, and Eccles
(1981) uses a term “quasi-firm”.
Each of the mentioned governance types is preferable in different situations, and the choice is
depending on three environmental factors, where each stimulates a specific human behavioural
characteristic. Three environmental dimensions are uncertainty, asset specificity and transaction
frequency (Winch, 1995). A first dimension, uncertainty, Galbraith (1977) defined as a function
of difference between the amount of information required for a decision, and the information
that is available, as found in Winch (1995). Winch (1995) adds that uncertainty is generated by
complexity and/or dynamism. The condition of complexity happens when information is available,
but its collection or analysis is either technically impossible in the given time, or would cost more
than returns; whereas dynamism denotes an inconstant situation in which present information
are poor guides to future events (Winch, 1995). A second dimension is asset specificity, which
Williamson (2007) marks as the most important for TCE. It is defined as the extent to which the
resources required are available from a large number of sources or only a few sources (Winch,
1995). Finally, the last dimension is transaction frequency, which refers to whether an input is
required on a regular or occasional basis (Winch, 1995).
Above described three contingencies, uncertainty, asset specificity and transaction frequency,
encourage three human behaviour factors: bounded rationality, opportunism and learning,
respectively. According to Williamson (2007), bounded rationality acknowledges limits on
cognitive competence, or that a “organisation man” has “less powerful analytical data-processing
apparatus”. Put differently, human beings have every intention to make a rational decision, but
they are limited in absorbing and analysing all the information that surrounds them. The incidence
of asset specificity encourages opportunism – the strongest form of self-interest (Williamson,
2007). Opportunism can be observed when holders of scarce assets take advantage of their
situation by overcharging, or by using their power to influence the other party in the exchange
(Winch, 1995). Williamson (2007) emphasizes that bounded rationality and opportunism are

2



1.1. Background and Motivation Aalborg University

especially important when combined. Without both, the issues of TCs and governance type
would be changed or even disappear. Finally, transaction frequency relates to a factor of
learning, seeing that spot transactions provide no opportunity to learn about the transacting
parties, while repeated transactions allow learning and building a relationship (Winch, 2009).
Figure 1.1 sums up the three dimensions of TC and behavioural factors. It shows that
an appropriate governance type is in a three-dimensional space as a function of the three
contingency factors (Winch, 2001). Issues and increased TCs are caused only when these
factors interact with each other: if uncertainty is close to zero, everything is transparent and
known so contracts can be made to prevent opportunism. If asset specificity is close to zero,
unforeseen events can be dealt with as they happen.

Figure 1.1: The transaction governance level, (Winch, 2001)

Wang (2003) states that despite a voluminous body of knowledge on the subject of TC, there
is still no theoretical consensus on the definition of TC. Rao (2002) supports that by saying that
TCs are still largely unexplored area of economics. Scholars usually provided a definition that
suits their research. They defined TCs by describing what TC are comprised of and in which
process they arise. As an example, here follows a list of costs that are included in TC given by
Shah (2007), who specifically researched TCs in the construction industry:

• The parties to a transaction finding each other and communicating directly or indirectly;
• The drawing up of agreements and contracts;
• The definition and inspection of goods involved in the transactions;
• The keeping of records;
• Enforcement of the agreements and contracts.

There are many more definitions found in the literature to denote terms transaction and
transaction costs. Ramstad (1996) noticed a difference in Williamson (2007)’s and Commons
(1931)’s interpretation of a transaction, where former is focused on the movement of a good or
service, and latter on the property rights and ownership. Similar distinction follows in denoting
term transaction costs with Pint and Baldwin (1997) on one side, and North (1990) on the other.

3



Bunic And Gøtze 1. Introduction

For this report, it is deemed not important to list definitions found in the literature. A description
that scholars agree on and is generally acceptable, is that TCs are those costs that are not
production costs (Hughes et al., 2006; Williamson, 2007; Buitelaar, 2007; Suematsu et al., 2014).
As Petersen and BĂŚkkeskov (2015) show with a simple equation, TCs together with production
costs summate total cost:

Total activity cost = production cost + transaction cost.

The most commonly used categorization of TC is given by Williamson (2007) and will be used
in this report. He differentiates between ex-ante and ex-post types of TC, meaning TC before
and after the contract signing. Ex-ante are costs of information gathering, drafting contracts,
negotiating conditions, decision-making and safeguarding an agreement. Ex-post are the ones
incurred while monitoring and enforcing a contract, cost of solving disputes and deviations from
the agreement. Ex-ante and ex-post costs are interdependent, meaning that increasing or
decreasing one group of costs could influence the other, and vice versa (Rao, 2002).
As it comes to quantifying TCs, yet again, scholars are not agreeing on how to or if it is even
possible to measure TC. On one hand, Buitelaar (2007) states that empirical studies are almost
impossible as TCs are often hidden, indirect and are not measured in terms of money and
man-hours. Additionally, Wallis and North (1986) claim that economic actors do not have the
motivation to observe TC as a separate cost, they are concerned with the bottom line. On the
other hand, Suematsu et al. (2014) says that universal procedures for measuring, analysing and
streamlining TCs could be defined because transaction structures are invariable, despite different
production in every sector, company and department.

TC in the Construction Industry
Where there is an economic activity, there are TC, and that goes also for the construction
industry. Rajeh et al. (2013) argues that there is a need to better evaluate TCs in construction,
given that the procurement decision is highly cost-sensitive. Available literature that deals
with the application of TC framework in this industry is limited, but also scattered because of
different definitions and many variables that influence TC. TCs in the construction sector are
typically associated with the procurement and tendering process, and its consequences. For
example, Hughes et al. (2006), who studied TCs in the construction sector, groups TCs in pre-
tendering (marketing, selling, pre-qualification rounds), tendering (calculating prices, risk and
environmental assessments, health and safety plans, quality plans), and post-tendering work
(performance monitoring, enforcement and disputes). That TCs are related to procurement is
reassured with interviews from the previous project report, where 8 construction professionals
confirmed the fact (Bunic and Gøtze, 2019). The following Table 1.2 sums up costs and activities
that might comprise ex-ante and ex-post TC in the construction industry.

4



1.1. Background and Motivation Aalborg University

Figure 1.2: Ex-ante and ex-post TC, extracted from (Jin et al., 2017)

There have been attempts to estimate and measure TCs in the construction industry. However,
the results of those studies have shown different figures. The first reason for that is the unclear
definition of TC, so the inconsistency in defining TC leads to differences in collecting data and
measuring (Li et al., 2014). Secondly, construction procurement is a complex process that offers
different options in terms of contracting methods, tendering procedure and price agreement, and
in each of these options, the amount od TCs differ. Furthermore, it is important to define whose
TCs are being measured (client, contractor, consultant, losing bidders etc.). Finally, as Tah et al.
(1994) and Shash (1998) noted, not many companies are willing to participate in these kinds of
studies due to the sensitive nature of the information required. A few examples are extracted
to point out that the amount of TC that should not be negligible. Bygherre Foreningen (2018)
states that 5 consultants together use up to 28% of the contract value in the tender process while
bidding for a project. Li et al. (2014) estimated TCs for clients (private and public), and found
that average ex-ante TCs are 3.6% of the contract value, and ex-post 6.4%. Hughes et al. (2006)
gives a combined estimation from different studies that says that overall TC might vary from 0.5
to 15%.
To depict and summarize important variables that influence TC, Bunic and Gøtze (2019) inspired
by Hughes et al. (2006), made a table that shows a conceptual distinction of procurement
methods in Denmark (Table 1.1). The idea behind it is to show that by describing a project by

5



Bunic And Gøtze 1. Introduction

a method of contracting does not sufficiently describe how something is procured and what are
TC (Hughes et al., 2006). For example, knowing that Design & Build Contract is used, suggest
merely that Contractor is the party responsible for design, coordination and construction. It does
not indicate what the amount of TC could be, because the client is unknown, the tendering
method and the extent od subcontracting. Thus, when considering TCs, all of the categories
shown in Table 1.1 should be taken into consideration.

Table 1.1: Conceptual definitions in procurement, inspired by Hughes et al. (2006)

Category Examples

Ownership, initiation, funding

Private Client,
Public Client,
Subsidized Client,
Developer

Responsibility for design
Consultant (Architect, Engineer),
Turnkey Contractor,
In-house design team

Responsibility for management
and coordination

Client,
Main Contractor,
Turnkey Contractor,
Lead Consultant (for consulting services)

Tendering procedure

Public tender,
Restricted tender with prequalification,
Restricted tender without prequalification,
Confidential tender,
Negotiated procedure,
Negotiated procedure without prior announcement,
Competitive dialogue,
Innovation partnership,
Project competition

Amount of subcontracting 0 - 100%

As it was noted earlier, from the point of Coase (1937)’s article, the concept of TC has
developed into a branch of theories concerned with the make-or-buy decision (Hughes et al.,
2006). Winch (2009) states that the pure market and pure hierarchy have rare application in
construction projects, what indicates that collaborative forms (Williamson’s hybrids) are preferred
over producing entirely in-house or buying of the market. Hughes et al. (2006) remark that in-
house production is not feasible in the modern construction industry. On the contrary, many
characteristics of the industry are working in favour of subcontracting. Those include the definite
period of a project, the wide geographical spread of locations of construction sites, diversity of
skills required during projects and uneven requirements and for specific skills (Hughes et al.,
2006). However, Hughes et al. (2006) states that multiple layers of subcontracting greatly
increase TCs. That is significant, since 80 – 90% of work is outsourced in the construction
sector (Hinze and Tracey, 1994; Lingard et al., 1998; Mbachu, 2008; Al-Hammad, 1993). This
is why Hughes et al. (2006) draws attention from the make-or-buy decision to the problem of
structuring the relationships in the complex network of contracts in the course of a construction
project.

As already indicated, not all TC are wasteful (Buitelaar, 2007; Rao, 2002; Suematsu et al., 2014).

6



1.1. Background and Motivation Aalborg University

A general tendency is to think of TCs as costs that should be reduced. However, unrestrained
reduction of TC is not a sustainable course for maximising social welfare and profit in companies
(Rao, 2002). Buitelaar (2007) expressed TCs as both means with a purpose and deadweight
losses, meaning that TCs bring certain benefits like security and trust in the system, but at a
point, they become a waste of time, resources and money. Buitelaar (2007) asks here how to
draw the boundary between “good” and “bad” TC and who is to judge? Finally, companies and
industries have the ability to reduce TC, but should not aim for eliminating them. Hence, TC
management is an issue of resource allocation, and not an issue of maximum reduction of TC.

To summarize, this section extracted the required knowledge of TC framework for this report.
TCE can hardly be utilised without looking into Coase’s and Williamson’s work. Therefore, this
section presented Coase’s observation of friction in the market, which should be accounted for
in the decision whether to produce in-house or to buy in the market. Williamson extended his
work and added a social component, saying that uncertainty, specific assets and frequency of
transactions influence bounded rationality, opportunistic behaviour and learning, respectively.
Important to mention is that these factors have an influence when combined. Taking into account
these factors, a decision about the appropriate governance type can be made, which will result
in the reduced TCs. However, knowing that this is a theoretical framework, when making a
decision, the strategic capabilities of the company should also be considered. When applying
TC framework in the modern construction industry and projects, it is observed that complete
hierarchical governance is uncommon.

During the previous semester project, interviews were conducted with contractors, developers
and consultants to get their view on TC (Bunic and Gøtze, 2019). It was found that individual
companies are inadvertently reducing their TCs by favouring networking governance type and
working with familiar companies. Approaches to reduce excess TCs were observed and will
be revised in Chapter 3. However, a major accumulator of unnecessary TC happens in public
procurement. It was discovered that contractors do not get invited to the next project if they fail to
submit a bid to the current project. To “stay in the game” contractors make the bid, despite it being
overpriced due to heavy outsourcing. These practices add to unneeded TC (Bunic and Gøtze,
2019). Next, an issue was found in a practice that on the first look seems like it could reduce TC.
It concerns EU tenders where there is a possibility to avoid tendering on one part of the deal,
which is 20% of the contract cost, but a maximum of DKK 500 000. The issue arises when the
allowance is spent on an architect, and when developer tenders the project, he cannot select
the same architect. That causes the additional issue of copyrights that the first architect owns,
and these increase TC (Bunic and Gøtze, 2019). Here mentioned are just some of the issues in
public procurement, and higher TCs are expected since the procurement of public projects needs
a balance between competition and cooperation (DorĂŠe, 2004). However, having the government
as a dominant market player (DorĂŠe, 2004; Barima, 2017), construction procurement is still an
issue that needs attention. Having said that, the motivation remained to explore a construction
procurement process within the transaction cost framework yet again, only this time on the scale
of an industry, and not individual companies.

7



Bunic And Gøtze 1. Introduction

1.2 Relevance

The relevance of the subject of transaction costs lies in the efficiency of the procurement and
tendering processes, and contract management in the industry, given that TCs are closely
associated with these procedures.
McKinsey published a report entitled ""Reinventing Construction: A Route to Higher Productivity"",
which claims that the construction sector, as one of the largest in the world economy and
contribution of 13% of GDP, is significantly less productive relative to other sectors (McKinsey,
2017). Moreover, the productivity of the sector has been flat for decades (McKinsey, 2015).
Therefore, McKinsey (2017) proposed seven routes to fight poor productivity, and three of those
are related to the procurement process, which directly points to transaction costs and related
activities. Firstly, McKinsey (2017) incentives to improve procurement and supply-chain
management, given that research showed that poor supply-chain and procurement accounts
for 10 – 30% of the cost and time overruns. Setting up relationships and contracts in highly
fragmented industry results in transaction costs. To depict high fragmentation and complexity in
supply chains, ICE (2018) offers an example of the Crossrail project in London, where more than
700 suppliers were contracted. Since transaction costs are economic losses based on the quality
of contract management, the contract framework is influencing the amount of costs. Accordingly,
McKinsey (2017) suggests rewiring the contractual framework with the claim that misaligned
contractual structures are one of the top causes of low productivity. The change should happen
by improving tendering practices and ensuring a trusting environment for all parties. Finally,
McKinsey (2017) proposes to reshape regulation and raise transparency, where are also TCs
incurred, given that resources spent on regulation and transparency are TCs. In summary, the
McKinsey report is greatly focused on the procurement process and surrounding activities, which
generate transaction costs. If seven identified routes to higher productivity are implemented, it
is suggested to boost productivity by 50 – 60% (McKinsey, 2017). This claim suggests the
importance of addressing the aforementioned issues.
The UK has conducted several studies long before the mentioned McKinsey’s report to document
the problems of the sector and put in place a progra";"""date"",""2020-06-10T09:37:50Z""
""pdf:PDFVersion"",""1.6""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.6""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2020-06-10T09:37:50Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.20 (TeX Live 2019) kpathsea version 6.3.1""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2020-06-10T09:37:50Z""
""created"",""2020-06-10T09:37:50Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-06-10T09:37:50Z""
""resourceName"",""Ana_Casper_Master_Thesis.pdf""
""Author"",""""
""producer"",""pdfTeX-1.40.20""
""pdf:docinfo:producer"",""pdfTeX-1.40.20""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2020-06-10T09:37:50Z""
""Last-Modified"",""2020-06-10T09:37:50Z""
""dcterms:modified"",""2020-06-10T09:37:50Z""
""title"",""""
""Last-Save-Date"",""2020-06-10T09:37:50Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2020-06-10T09:37:50Z""
""meta:save-date"",""2020-06-10T09:37:50Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.20 (TeX Live 2019) kpathsea version 6.3.1""
""Content-Length"",""5068839""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""160""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""282"",""1372"",""1514"",""0"",""1166"",""1719"",""1008"",""0"",""2614"",""3542"",""1914"",""2614"",""1466"",""2320"",""3105"",""3437"",""1909"",""2105"",""1061"",""2712"",""1816"",""2534"",""1968"",""0"",""2665"",""292"",""2529"",""3145"",""3092"",""2695"",""906"",""964"",""2346"",""1477"",""2522"",""1980"",""3080"",""2085"",""1573"",""1893"",""864"",""3198"",""3115"",""2236"",""3341"",""3500"",""2214"",""1796"",""2160"",""1788"",""2041"",""2729"",""2933"",""3433"",""3299"",""3153"",""2304"",""0"",""1943"",""2493"",""2461"",""1042"",""1811"",""2294"",""1883"",""3166"",""3121"",""2338"",""116"",""0"",""2714"",""3098"",""3304"",""2949"",""237"",""0"",""2430"",""1109"",""1908"",""2277"",""2395"",""2207"",""2306"",""2179"",""2178"",""1839"",""35"",""1997"",""2252"",""1206"",""41"",""1591"",""1852"",""719"",""862"",""1310"",""1402"",""0"",""2170"",""3256"",""3264"",""2868"",""3383"",""2860"",""2900"",""3158"",""3359"",""2993"",""1089"",""0"",""1622"",""3057"",""2449"",""2752"",""2470"",""2515"",""1575"",""0"",""2280"",""3450"",""3475"",""3024"",""2992"",""3003"",""1957"",""2780"",""3075"",""2701"",""2807"",""2757"",""2121"",""0"",""2011"",""3136"",""2825"",""2849"",""2909"",""326"",""2222"",""2784"",""2873"",""2536"",""1874"",""2458"",""2823"",""207"",""2017"",""3212"",""2783"",""2123"",""2457"",""0"",""1881"",""2361"",""2614"",""2845"",""2780"",""2062"",""2687"",""850""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-06-10T09:37:50Z""
";https://scholar.google.ch/scholar?start=860&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098822-235;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;A new ECDLP-based PoW model;A Meneghetti, M Sala, D Taufer ; Mathematics, 2020  mdpi.com;;"… (This article belongs to the Special Issue The Cryptography of Cryptocurrency) … Abstract.

Blockchain technology has attracted a lot of research interest in the last few years. Originally,

their consensus algorithm was Hashcash, which is an instance of the so-called Proof-of-Work …";Cité 2 fois;Les 7 versions;[PDF] mdpi.com;https://www.mdpi.com/2227-7390/8/8/1344/pdf;;;https://scholar.google.ch/scholar?start=780&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098813-211;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;[HTML][HTML] Identity-Based Identification Scheme without Trusted Party against Concurrent Attacks;F Tang, J Bao, Y Huang, D Huang… ; Security and …, 2020  hindawi.com;United Kingdom;"Identification schemes support that a prover who holding a secret key to prove itself to any verifier

who holding the corresponding public key. In traditional identity-based identification schemes,

there is a key generation center to generate all users' secret keys. This means that the …";Autres articles;;[HTML] hindawi.com;https://www.hindawi.com/journals/scn/2020/8820271/;"[image: logo]
	Journals
	Publish with us
	Publishing partnerships
	About us
	Blog




Security and Communication Networks
+Journal Menu
[image:  ]PDF[image:  ] 
    
     Icons/Arrow Right White
     Created with Sketch.
     
         
    
     
         
             
                 
                     
                         
                             
                                 
                            
                             
                             
                                 
                            
                        
                    
                
            
        
    



Journal overview
For authorsFor reviewersFor editorsTable of ContentsSpecial Issues
[image:  ]         

Submit






Security and Communication Networks / 2020 / Article
Article SectionsOn this page
AbstractIntroductionPreliminariesApplicationsConclusionData AvailabilityConflicts of InterestAcknowledgmentsReferencesCopyright


Special IssueMathematical Models for New Types of Cyberattack and Associated Defence Strategies
View this Special Issue

Research Article | Open Access
Volume 2020 |Article ID 8820271 | https://doi.org/10.1155/2020/8820271
Fei Tang, Jiali Bao, Yonghong Huang, Dong Huang, Fuqun Wang, ""Identity-Based Identification Scheme without Trusted Party against Concurrent Attacks"", Security and Communication Networks, vol. 2020, Article ID 8820271, 9   pages, 2020. https://doi.org/10.1155/2020/8820271

Show citation
Identity-Based Identification Scheme without Trusted Party against Concurrent Attacks


Fei Tang[image:  ]   .cls-1{fill:#a6ce39;}.cls-2{fill:#fff;}.cls-3{fill:none;} orchid     

,1,2 Jiali Bao[image:  ]   .cls-1{fill:#a6ce39;}.cls-2{fill:#fff;}.cls-3{fill:none;} orchid     

,1 Yonghong Huang,2 Dong Huang,3  and Fuqun Wang4,51College of Computer Science and Technology, Chongqing University of Posts and Telecommunications, Chongqing 400065, China
2School of Cyber Security and Information Law, Chongqing University of Posts and Telecommunications, Chongqing 400065, China
3Chongqing Vocational and Technical University of Mechatronics, Chongqing 402760, China
4Department of Mathematics, Hangzhou Normal University, Hangzhou 311121, China
5Westone Cryptologic Research Center, Beijing 100071, China

Show more
Academic Editor: Chunming Zhang
Received03 Aug 2020
Revised03 Sep 2020
Accepted21 Sep 2020
Published17 Oct 2020


Abstract
Identification schemes support that a prover who holding a secret key to prove itself to any verifier who holding the corresponding public key. In traditional identity-based identification schemes, there is a key generation center to generate all users’ secret keys. This means that the key generation center knows all users’ secret key, which brings the key escrow problem. To resolve this problem, in this work, we define the model of identity-based identification without a trusted party. Then, we propose a multi-authority identity-based identification scheme based on bilinear pairing. Furthermore, we prove the security of the proposed scheme in the random oracle model against impersonation under passive and concurrent attacks. Finally, we give an application of the proposed identity-based identification scheme to blockchain.
1. Introduction
In identification schemes, the user, playing the role of a prover, can identity itself to any verifier in a protocol in which the verifier begins by holding only the corresponding public key. One of the purposes of identification is to promote access control to resources, when an access privilege is linked to a particular identity.
There are a lot of research studies on identification schemes. The fundamental work of identification scheme [1] was proposed by Fiat and Shamir, named FS scheme. The authors described an identification scheme in which any user can prove its identity to other users. They combined zero-knowledge interactive proofs with identity-based schemes. The key of FS scheme is to assume that there is a trusted center, such as computer center, government, and credit card company. This center gives smart cards to users after checking their physical identities. The FS scheme is based on the factorization problem. Feige et al. [2] proposed another identification scheme, named FFS scheme, which is also based on the factorization problem. Okamoto [3] presented a three-move interactive identification scheme and proved that the scheme has the same security as the discrete logarithm problem. Schnorr’s scheme [4] is one of the famous identification schemes. The GQ scheme which was proposed by Guillou and Quisquater [5] is based on the RSA-inversion problem. The formal proof of security for GQ and Schnorr schemes was realized by Bellare and Palacio [6]. They provided a proof for GQ scheme based on RSA-inversion assumption and a proof for Schnorr scheme based on one more discrete logarithm (OMDL) assumption. These two schemes are provably secure against impersonation under active and concurrent attacks. Girault [7] gave a modification of Schnorr’s identification scheme, in which each user can select his own secret key but the center can not get it from the public key. Kim and Kim [8] proposed a new identification scheme based on bilinear Diffie-Hellman problem, which is secure against passive and active attacks.
In traditional identification schemes, we need a certificate authority (CA) to authenticate prover’s public key in the setting of public key infrastructure (PKI). Shamir [9] introduced the notion of identity-based cryptography (IBC). The purpose of IBC is to simplify the management of certificates in PKI. Shamir pointed out that the key generation center (KGC) generates the corresponding secret key with the public identity and sends it to the user when he first joins in the system. Each user has a unique and meaningful identity as the public key and thus avoids the complicated certificate management problem. Then, Boneh and Franklin proposed an identity-based encryption (IBE) scheme [10], which is based on bilinear pairing. Since then, a large number of identity-based identification schemes have been proposed by using bilinear pairings.
The formal definition of identity-based identification (IBI) scheme was introduced by Kurosawa and Heng [11]. They constructed a transformation from any standard digital signature scheme to an IBI scheme. Then, in [12], they proposed two IBI schemes, one of which is provably secure against impersonation passive attacks, and the other is provably secure against impersonation active and concurrent attacks. The security model of IBI [11, 13] can be divided into three types, called security against impersonation under passive attacks, active attacks, and concurrent attacks, respectively. Then, Chin et al. [14] presented a provably secure IBI scheme in the standard model. The scheme of [14] is secure against impersonation under active and concurrent attacks based on one more computational Diffie-Hellman assumption. Barapatre and Rangan [15] proposed a general framework of IBI based on the identity-based key encapsulation mechanism. The scheme of [15] is secure against impersonation under active and concurrent attacks based on the -bilinear Diffie-Hellman inversion assumption.
It is well known that, the IBI schemes suffer the key escrow problem, which means that we need a trusted KGC to generate all users’ key. In order to solve this problem, in this work, we consider the IBI scheme without a trusted party. The main contributions of this work can be summarized as follows:(1)We give the formal definition of IBI scheme in the multi-authority setting. In our definition, there are  authorities. The generation of users’ secret key needs at least  authorities.(2)We construct an IBI scheme with multiple authorities based on the BLS signature scheme [16]. The security of the proposed scheme is provably against impersonation under passive and concurrent attacks in the random oracle model.(3)We consider the applications of the proposed multi-authority IBI scheme. We show that the scheme can be used to identification in blockchain.
The rest of this paper is organized as follows. In Section 2, we give the definitions of bilinear pairing and complexity assumptions. We also present the definition and security models of the IBI scheme in Section 2. Section 3 presents the details of IBI scheme. In Section 4, we prove the security of the proposed scheme. In Section 5, we describe the applications of the multi-authority IBI scheme in blockchain. Finally, we make a conclusion about this paper in section 6.
2. Preliminaries
In this section, we describe the relevant definitions and security models.
2.1. Bilinear Map and Complexity Assumptions
In the construction of our identity-based identification scheme, we use bilinear pairing as the basic tool. Therefore, we briefly introduce the concept of bilinear pairing.
Let  and  be two cyclic multiplicative groups, where  is generated by an element , i.e., . Groups  and  have same prime order . We say that  is an admissible bilinear pairing if it satisfies the following properties:(1)Bilinearity:  for all .(2)Nondegeneracy: there exists , for , such that , where  represents the identity element of the group .(3)Computability: there is an efficient algorithm to compute  for all .
The security of our scheme relies on the following two difficult problems: Computational Diffie-Hellman (CDH) Problem and One More Discrete Logarithm (OMDL) Problem.
Definition 1 (CDH). Given  for some , it is hard to compute .
Definition 2 (OMDL) (see [17]). The definition of the OMDL problem is defined by the following experiment .(i)Training: A polynomial-time adversary  makes  queries to the challenge oracle  and  queries to the Discrete-Logarithm (DL) oracle . Let .(ii)Output: If , where  are random points in  output by the challenge oracle , and , where  denotes the number of queries to the DL oracle, then return 1. Otherwise, return 0.We define the advantage of adversary  as . We say that OMDL problem is hard if  is negligible in  for any polynomial-time adversary.
2.2. Definition of Multi-authority IBI
An identity-based identification (IBI) scheme  is specified by four probabilistic polynomial-time algorithms, called Setup, Key-generation, Proving, and Verification, respectively. On input security parameter ,  returns system public parameters and the master secret key.  is executed by the key generation center to generate a secret key corresponding to a given public identity.  and  are interactive algorithms that implement the prover and verifier. We call  an identification protocol.
As far as we know, there is no IBI scheme in the setting of multiple authorities. The standard IBI schemes have a key generation center to produce all users’ secret key. Therefore, it is well known that identity-based cryptographic schemes have the key escrow problem. This work defines the notion of IBI scheme with multiple authorities. In our scheme, there has one more algorithm, Authority Setup, to generate all authorities’ master secret keys. The notion of IBI scheme with multiple authorities is consists of the following algorithms:(i)System-setup: This algorithm takes as input the security parameter  and outputs the system public parameter .(ii)Authority-setup: The authority setup algorithm is interactively executed by all authorities. On input the system public parameter  and identities , output their master secret keys .(iii)Key-generation: User  makes queries to at least  authorities, , where  for key generation. Each authority  takes as inputs the system public parameter , master secret key , and user’s identity  and outputs user its partial key . Finally, user  can compute the secret key  by itself.(iv)Identification:  receives as inputs , , and  and  receives as inputs , and ), where  is the secret key corresponding to the public identity . After an interactive execution of ,  outputs 1 (accept) or 0 (reject).(v)Correctness: A legitimate  should always be accepted, i.e., .
2.3. Security Models
The accepted framework of security concepts for identification schemes was proposed by Feige et al. [2]. Then, the security definition for IBI scheme was presented in [11, 13]. This is an extension of the framework of [2]; that is, the three concepts of security for standard identification schemes are extended to IBI. Usually, we consider adversary goals, adversary capabilities or attacks. The adversary goal is impersonation that if the adversary interacts with the verifier playing the role of prover with identity  and can persuade the verifier to accept with a nonnegligible probability. To achieve this goal, the adversary can carry out various attacks. We consider three kinds of attacks, namely, passive attacks [2], active attacks [2], and concurrent attacks [6]. These attacks should take place and complete before the impersonation attempt.
Passive attacks are the weakest one of the above three kinds of attacks for IBI schemes. In passive attacks, the adversary does not interact with the prover. The adversary just eavesdrops and obtains a transcript of a conversation between the prover and verifier. The definition of passive attacks of IBI schemes is defined by the following game which is executed by an adversary  and a challenger .
Definition 3 (Security against Impersonation under Passive Attacks). Let  be an impersonation adversary with passive attacks (imp-pa).(i)System-setup: The challenger  runs the system setup algorithm on input a security parameter  to generate system public parameters . Then,  returns  to .(ii)Authority-setup: The challenger  runs the authority setup algorithm to generate master secret keys  for all authorities .(iii)Queries:  can issues some queries as follows:(1)Master secret key queries:  issues a request for some authorities  for their master secret key. For such a request,  transmits  to .(2)Key generation queries:  issues some key generation queries .  then returns the corresponding private key  as the answer.(3)Transcript queries:  can issue some transcript queries on . In passive attacks,  returns the transcripts  which denotes the conversations between the valid prover  and other verifiers.(iv)Challenge:  chooses a challenge identity . Then,  plays the role of a cheating prover, trying to convince any verifier.We define that adversary  succeeds in impersonating if it can make the verifier accepts. The advantage of an imp-pa adversary  denoted by . We say that IBI scheme is secure against impersonation under passive attacks if  is negligible in  for any imp-pa adversary.
Different from passive attacks, in the active and concurrent attacks, the adversary first plays the role of the cheating verifier, interacting with the honest prover multiple times, trying to extract some useful information. Then it plays role of cheating prover, interacting with the honest verifier, trying to persuade the honest verifier to accept. It is easy to see that the security notions of active and concurrent attacks are stronger than the notion of passive attacks. Generally, we pursue stronger security notion for crytographic schemes, such as [18, 19].
Active attacks are a special case of concurrent attacks. In the active attacks, the next round of attack is carried out after one attack is completed, that is, the interaction is one by one. In the concurrent attacks, however, the adversary can interact with multiple different prover “replicas” concurrently. The replicas all have the same secret key but are initialized with independent coins and maintain their own state. Apparently, security against impersonation under concurrent attack implies security against impersonation under active attack.
Difinition 4 (Security against Impersonation under Concurrent Attacks). An impersonation under concurrent attacks (imp-ca) adversary  is a pair of randomized polynomial-time algorithms, which denotes the cheating verifier and the cheating prover, respectively. The definition of the concurrent attacks of IBI schemes is defined by the following game which is played by a concurrent adversary and challenger .(i)System-setup: The challenger  runs the system setup algorithm on input  to generate system public parameters . Then,  sends  to different replicas of prover  and adversary .(ii)Authority-setup: The challenger  runs the authority setup algorithm to generate master secret keys  for all authorities .(iii)Queries:  can issues some queries as follows:(1)Master secret key queries:  issues a request for some authorities  for their master secret key. For such a request,  transmits  to .(2)Key generation queries:  issues some key generation queries .  then returns the corresponding private key  as the answer.(3)Identification training:  first plays the role of a cheating verifier to execute the identification protocols with the honest prover . In concurrent attacks, the adversary  can issue the identification protocol at any time regardless of whether the last protocol is end or not. The difference between concurrent attack and active attack is that the active adversary only can issue a new identification protocol after the end of the last protocol. We denote the transcript of -th protocol as .(iv)Challenge: Finally, adversary plays the role of a cheating prover  to execute the identification protocol with a valid verifier  to try to convince that he is the valid prover.We define that adversary  succeeds in impersonating if it can make the verifier accepts. The advantage of an imp-ca adversary  denoted by . We say that IBI scheme is secure against impersonation under concurrent attacks if  is negligible in  for any imp-ca adversary.
3. The Proposed Scheme
In this section, we give our multi-authority IBI scheme without a trusted party. Generally speaking, in traditional IBI schemes, there is a trusted party for the generation and distribution of user secret keys. To address the problem of no trusted party, we utilize distributed key generation (DKG) protocol to generate user secret keys. DKG was proposed by Gennaro et al. [20]. The core idea of DKG is  threshold secret sharing. The concept of secret sharing was introduced by Shamir [21]. Secret sharing is used to share a secret among a group of participants, each of whom has partial information about secret.  threshold secret sharing means that at least  participate among  participants can reconstructed the secret value.
In the DKG protocol, the participants jointly choose and generate a random secret share . Each participant  chooses a random share , and then a random secret share  can be recovered by at least  participants. At the end of the protocol, the public key can be defined as . There is no trusted party, who owns the secret value  in the secret sharing scheme. The secret value  can only be reconstructed by the cooperation of at least  participants.
The construction of our scheme refers to two article by Lin et al. [22] and Tang et al. [23]. Lin et al. proposed a threshold multi-authority attribute-based encryption scheme. In their scheme, they use  threshold secret sharing to get the system secret key . Each authority only has the share  about secret . Therefore, the system secret key  is unknown to any authority. Tang et al. proposed an efficient multi-authority authentication scheme for electronic health records system based on blockchain.
3.1. Construction
The construction of the scheme is outlined below:(i)System-setup: Given the security parameter  as input, generates prime  randomly to establish the system parameters. First of all, it chooses two multiplication cycles  and  with some prime order , and a bilinear map . Let  be a generator of the group . Next, it chooses a cryptographic hash function . The system parameters are , where  is the number of authorities in the system, and  is the threshold value which denotes the number of authorities to generate secret key for users.(ii)Authority-setup: In this algorithm, all authorities take public parameters  and their identities  as inputs and establish their master secret keys . It consists of the following two phases:(a)Phase 1 (generation of the master secret key): Each authority generates the public key and private key, as well as the master public key of the system.(1)Each authority  selects at random a polynomial  of degree :(2) calculates  for  and then broadcasts .(3)  computes secret value  for , and then sends  secretly to authority  for .(4)  verifies the equation  holds or not. If it holds, the secret sharing from  is valid. Otherwise,  broadcasts a complaint against .(5)If authority  is complained, then it needs to broadcast values  that satisfy the equation. If the disclosed  still does not match,  has to keep proving itself to be honest until the equation is true.(6)  computes its own private key  and calculates its own public key . The master secret key  can be recovered by any  values in .(b)Phase 2 (generation of master public key): According to the above phase, each authority has broadcasted values  for  which can verified publicly. Therefore, the master public key can be computed as After the above two phases, each authority adds parameters  and  to the parameters .(iii)Key-generation: User  makes key-generation request to at least  authorities. Then, the authority generates the corresponding partial secret key and sends it to the user. After receiving the partial secret key, the user can verify its correctness using the public key of the corresponding authority. Finally, user  computes his secret key  by himself.(1)Phase 1 (generation of partial secret key): Each authority  computes a value  and secretly transmits it to user .(2)Phase 2 (verification of partial secret key): After receiving the partial secret key  from authority , the user  verifies the equation  holds or not. If it holds, then the partial secret key is correct. Otherwise, the user exposes the partial secret key and requests other authorities to authenticate it. The authority  needs to retransmit the correct value to satisfies the equation.(3)Phase 3 (generation of secret key): After receiving all partial secret keys, the user  computes his own secret key as(iv)Identification: We consider two types of identification protocols which corresponding to the passive attack and concurrent (or active) attack, respectively.(a)Identification protocol against passive attacks:(1) The prover  selects  randomly, computes , and sends  to verifier.(2) The verifier chooses  randomly and sends it to prover .(3) The prover  computes  and returns it to verifier.(4) The verifier checks  holds or not. If it holds, outputs accept; otherwise, outputs reject.(b)Identification protocol against active and concurrent attacks:(1) The prover  blinds the secret key . Let , where  is the blinding factor.(2) The prover  randomly selects an integer , computes , and sends  and  to verifier.(3) The verifier chooses a random integer  and sends it to prover .(4) The prover  computes  and sends  to verifier.(5) The verifier checks  holds or not. If it holds, outputs accept; otherwise, outputs reject.
3.2. Correctness
The correctness of the identification protocol against passive attacks can be verified by the following equation:
The correctness of the identification protocol against concurrent attacks can be verified by the following equation:
4. Security Proofs
In this section, we prove the security of the proposed multi-authority IBI scheme.
As said above, the proposed scheme is based on the distributed key generation technique [20] and a centralized IBI scheme. It seems that the security of the scheme directly holds based on the securities of the two schemes. It is not true because in the security proof of IBI scheme we need to embed the challenge instance to a fixed element  which is one of the public parameters. However, the value  which is generated by the distributed key generation technique [20] is randomly in the beginning.
To resolve this problem, we use the proof framework of [23] which introduced the approach of hybrid games for this kind of schemes. The core technique of [23] is that define three games. The first game corresponds to the honest execution of the security proof. Then, in the second game, we set the master key as  where  is the exponent of the CDH or OMDL instance and  is the master secret key randomly generated by all authorities, respectively. No one knows  and . In the last game, the challenger plays the role of all authorities, and thus it knows the value . Then, we can prove that the advantage of any probabilistic polynomial time (PPT) adversary in the first game is close to the another two games. Hence, if we can prove the advantage of any PPT adversary in the last game which corresponds to the proof of centralized IBI scheme is negligible, then we can obtain the security result that the advantage of any PPT adversary of the multi-authority IBI scheme is also negligible. Therefore, in this work, we only prove the security of the centralized IBI scheme. Please refer to [23] for details of the proof technique which describes the security from centralized scheme to the multi-authority setting.
Theorem 1. The proposed multi-authority IBI scheme is secure against impersonation under passive attack in the random oracle model assuming that the CDH problem is hard.
Proof. Let  be a polynomial-time imp-pa impersonator that tries to break the IBI scheme. Let  be a challenger that tries to break the BLS signature scheme under chosen message attack.  takes as input , generates public parameters , where  is a hash function modeled as a random oracle.  chooses , computes , and then gives system public parameters  to adversary .
If  makes a key generation query on .  then returns the corresponding private key  as the answer. If  makes a transcript query on . Then  chooses ,  randomly and computes  such that .  then gives  to  as the transcript. Finally,  chooses a challenge identity .
Now,  plays the role as the cheating prover and interacts with challenger .  can still issues some key generation queries and transcript queries in this phase, with the restriction that the query on the challenge identity  is not allowed.  runs  to get the response . After receiving ,  selects  randomly, runs  to get its response  and verifies the equation  holds or not. If the equation holds,  runs  again with the same state but with different challenge value , obtains its response , and verifies the equation  hold or not. If the equation holds,  outputs  as a forgery. Since we have  and . Thus,  is a valid signature on .
Theorem 2. The proposed multi-authority IBI scheme is secure against impersonation under concurrent attack in random oracle model assuming that the OMDL problem is hard.
Proof. Let  be a polynomial-time imp-ca impersonator that tries to break the identity-based identification scheme. Let  be an OMDL challenger. We assume that  never repeats a request.  takes as input  and generates public parameters .  chooses  and computes  and then outputs  as system public parameters.  returns  to adversary .
If  makes a key generation query on .  then returns the corresponding private key  as the answer.
Now,  makes a identification training. First, challenger  queries its challenge oracle  to obtain a challenge point , where .  now chooses an arbitrary identity .  is hash function viewed as a random oracle. We set it as follows.  chooses a random  and sets . If ,  chooses a random  and sets .  next computes  and sends it to adversary . Since  for random ,  for random . Now,  simulates an interaction between  and the prover replicas as follows. A random tape  is chosen for prover replicas .  then initializes prover replicas  with .  first queries its challenge oracle  to get the response .  computes  and sends this to . Since  for random , we have .  chooses random  and returns to .  makes the query  to its discrete log oracle  and get the response .  sends  to .  verifies the equation  hold or not. The correctness of the equation is as follows:After performing the above simulations,  outputs some state information and stops interaction. Now,  attempts to extract the discrete logarithm  of challenge point . Then using this value,  can further compute the discrete logarithm  of other challenge points . To do so,  runs  in state  obtaining , selects a random , and runs  to get its response .  then verifies the equation  holds or not. If the equation holds,  runs  again with the same state  but with different challenge value , obtains its response  and verifies the equation  hold or not. If the equation holds,  computes . We show that  is the discrete logarithm of . Observing thatFrom the above equation, we obtain . We now can further compute  for . Finally,  outputs .
5. Applications
The proposed IBI scheme provides a good solution for scenarios where there is no trusted center, such as blockchain. Hence, in this section, we consider the application of the multi-authority IBI scheme in blockchain.
Blockchain technology was introduced by Nakamoto [24] in Bitcoin. Blockchain as the underlying technology of Bitcoin is essentially a type of distributed ledger. It can avoid the single point of failure. The advantages of blockchain are decentralization, anonymity, trustworthiness, and so on. According to different application scenarios and participants, blockchain can be divided into three categories, including public blockchain, consortium blockchain, and private blockchain [25]. In public blockchain, everyone can read and send transactions and everyone could join in the consensus process. For private blockchain, the node coming from a specific organization can be allowed to enter into the consensus process. The consortium blockchain is between public blockchain and private blockchain. It is a specific blockchain with authorized nodes. The consensus process is controlled by authorized nodes. The consortium blockchain is a community composed of  member organizations, and each member runs a node. Only with the confirmation of  of the member organizations can each block take effect. At present, many researchers are trying to utilize blockchain in different fields, such as healthcare [26, 27], Internet of things (IoT) [28], and so on. This will make data freedom from ideal to reality, and these data providers will become the buliders and users of blockchain. In order to achieve the security of data sharing and privacy protection and confirm that data usage is legitimate, it is necessary to reach a consensus on the identification to ensure the authenticity of the identity on the chain.
Traditional IBI schemes are centralized which have a trusted party to generate and distribute users’ key. However, the main feature of blockcahin is decentralization. Traditional IBI schemes are suitable for single authority instead of multiple authorities. There is no trusted party in blockchain. At the same time, we cannot build a trusted party in blockchain. Distrbuted identification is a way to address this problem. In distributed identification, we do not need to rely on the trusted third party for secret key generation and distribution and identity management.
Our multi-authority IBI scheme can provide a good solution for consortium blockchain. We describe the application of our IBI scheme in consortium blockchain. In the consortium blockchain, we can divide nodes into two types, authority and user. The member of consortium blockchain plays the role of the authority, and the user is assumed by other nodes that join the consortium blockchain. The identification protocol for blockchain based on multi-authority IBI scheme is as shown in Figure 1.
[image: ]


Figure 1 
The identification protocol of blockchain based on multi-authority IBI scheme.


(1)System-setup: In the beginning, all  authorities are cooperating to initialize the consortium blockchain system. In this phase, they generate the public parameters according to the security parameters. Meanwhile, all master secret keys can be generated by themselves. Finally, public parameters are published to all users in this system, and the master secret keys are secretly kept by all authorities.(2)User-registration: When a user wants to join the system, he submits his enrollment request to at least  authorities. Then, the system assign an unique recognizable identity  and corresponding partial secret key . Eventually, user verifies the validity of the partial secret key and computes its own secret key .(3)Identification: Finally, in some cases, the user needs to prove that he is a legitimate user of this system. Then he can use the identification protocol of the I";"""dc.publisher"",""Hindawi""
""og:image"",""https://images.hindawi.com/journals/scn/scn.banner.jpg""
""og:image:width"",""600""
""twitter:card"",""summary_large_image""
""citation_journal_title"",""Security and Communication Networks""
""language"",""en""
""og:description"",""Identification schemes support that a prover who holding a secret key to prove itself to any verifier who holding the corresponding public key. In traditional identity-based identification schemes, there is a key generation center to generate all users&#x2019; secret keys. This means that the key generation center knows all users&#x2019; secret key, which brings the key escrow problem. To resolve this problem, in this work, we define the model of identity-based identification without a trusted party. Then, we propose a multi-authority identity-based identification scheme based on bilinear pairing. Furthermore, we prove the security of the proposed scheme in the random oracle model against impersonation under passive and concurrent attacks. Finally, we give an application of the proposed identity-based identification scheme to blockchain.""
""prism.issn"",""1939-0114""
""citation_issn"",""1939-0114""
""dc:title"",""Identity-Based Identification Scheme without Trusted Party against Concurrent Attacks""
""Content-Encoding"",""UTF-8""
""citation_pdf_url"",""https://downloads.hindawi.com/journals/scn/2020/8820271.pdf""
""robots"",""index""
""google-site-verification"",""AxEuDsL7vXGOxRe53-uFhOk2ODN0bbXMeuBy6Pfq4ww""
""citation_author"",""Tang, Fei"",""Bao, Jiali"",""Huang, Yonghong"",""Huang, Dong"",""Wang, Fuqun""
""dc.date"",""2020/10/17""
""prism.volume"",""2020""
""citation_doi"",""https://doi.org/10.1155/2020/8820271""
""prism.publicationName"",""Security and Communication Networks""
""dc.title"",""Identity-Based Identification Scheme without Trusted Party against Concurrent Attacks""
""Author"",""Hindawi""
""citation_volume"",""2020""
""dc.language"",""en""
""Content-Language"",""en""
""authors"",""Fei Tang | Jiali Bao | ... | Fuqun Wang""
""citation_title"",""Identity-Based Identification Scheme without Trusted Party against Concurrent Attacks""
""citation_year"",""2020""
""citation_publisher"",""Hindawi""
""dc.format"",""text/html""
""description"",""Identification schemes support that a prover who holding a secret key to prove itself to any verifier who holding the corresponding public key. In traditional identity-based identification schemes, there is a key generation center to generate all users&#x2019; secret keys. This means that the key generation center knows all users&#x2019; secret key, which brings the key escrow problem. To resolve this problem, in this work, we define the model of identity-based identification without a trusted party. Then, we propose a multi-authority identity-based identification scheme based on bilinear pairing. Furthermore, we prove the security of the proposed scheme in the random oracle model against impersonation under passive and concurrent attacks. Finally, we give an application of the proposed identity-based identification scheme to blockchain.""
""og:image:type"",""image/jpeg""
""citation_date"",""2020/10/17""
""title"",""Identity-Based Identification Scheme without Trusted Party against Concurrent Attacks"",""Identity-Based Identification Scheme without Trusted Party against Concurrent Attacks""
""twitter:image"",""https://images.hindawi.com/journals/scn/scn.banner.jpg""
""citation_online_date"",""2020/10/17""
""twitter:site"",""website""
""dc.type"",""Research Article""
""dc.source"",""Security and Communication Networks""
""dc.creator"",""Tang, Fei"",""Bao, Jiali"",""Huang, Yonghong"",""Huang, Dong"",""Wang, Fuqun""
""citation_fulltext_html_url"",""https://www.hindawi.com/journals/scn/2020/8820271/""
""prism.publicationDate"",""2020/10/17""
""Content-Length"",""1458441""
""citation_xml_url"",""https://downloads.hindawi.com/journals/scn/2020/8820271.xml""
""Content-Type"",""text/html; charset=UTF-8""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""og:type"",""website""
""twitter:title"",""Identity-Based Identification Scheme without Trusted Party against Concurrent Attacks""
""dc.description"",""Identification schemes support that a prover who holding a secret key to prove itself to any verifier who holding the corresponding public key. In traditional identity-based identification schemes, there is a key generation center to generate all users&#x2019; secret keys. This means that the key generation center knows all users&#x2019; secret key, which brings the key escrow problem. To resolve this problem, in this work, we define the model of identity-based identification without a trusted party. Then, we propose a multi-authority identity-based identification scheme based on bilinear pairing. Furthermore, we prove the security of the proposed scheme in the random oracle model against impersonation under passive and concurrent attacks. Finally, we give an application of the proposed identity-based identification scheme to blockchain.""
""og:title"",""Identity-Based Identification Scheme without Trusted Party against Concurrent Attacks""
""citation_abstract"",""Identification schemes support that a prover who holding a secret key to prove itself to any verifier who holding the corresponding public key. In traditional identity-based identification schemes, there is a key generation center to generate all users&#x2019; secret keys. This means that the key generation center knows all users&#x2019; secret key, which brings the key escrow problem. To resolve this problem, in this work, we define the model of identity-based identification without a trusted party. Then, we propose a multi-authority identity-based identification scheme based on bilinear pairing. Furthermore, we prove the security of the proposed scheme in the random oracle model against impersonation under passive and concurrent attacks. Finally, we give an application of the proposed identity-based identification scheme to blockchain.""
""og:image:height"",""315""
""prism.doi"",""https://doi.org/10.1155/2020/8820271""
""dcterms.issued"",""2020/10/17""
""viewport"",""width=device-width, initial-scale=1""
""twitter:description"",""Identification schemes support that a prover who holding a secret key to prove itself to any verifier who holding the corresponding public key. In traditional identity-based identification schemes, there is a key generation center to generate all users&#x2019; secret keys. This means that the key generation center knows all users&#x2019; secret key, which brings the key escrow problem. To resolve this problem, in this work, we define the model of identity-based identification without a trusted party. Then, we propose a multi-authority identity-based identification scheme based on bilinear pairing. Furthermore, we prove the security of the proposed scheme in the random oracle model against impersonation under passive and concurrent attacks. Finally, we give an application of the proposed identity-based identification scheme to blockchain.""
""dc.identifier"",""https://doi.org/10.1155/2020/8820271""
""prism.section"",""Research Article""
""og:url"",""https://www.hindawi.com/journals/scn/2020/8820271/""
";https://scholar.google.ch/scholar?start=760&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098879-365;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Easy Simple Factoring-based Digital Signature Scheme;SY Hue, NH Sarmin, ES Ismail… ; 2020 15th International …, 2020  ieeexplore.ieee.org;;"… Index Terms—digital signature scheme, provably security, random oracle model, identification

scheme, Fiat-Shamir trans … solutions to identification and signature problems,” in Advances in

Cryptology — CRYPTO' 86, AM … [4] M. Bellare and P. Rogaway, “Random oracles are prac …";;null;null;;;;https://scholar.google.ch/scholar?start=910&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098870-347;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Blockchain-mediated Collaboration of Citizens in Open Government Processes;M Emaldi, K Zabaleta, I Guillén… ; 2020 5th International …, 2020  ieeexplore.ieee.org;;"… The blockchain protocol integration module acts as a Smart Oracle which is blockchain network

agnostic and pluggable to other distinct blockchain networks … These developers can be rewarded

through the blockchain protocol selected cryptocurrency (Audacoin in the …";Autres articles;;null;;;;https://scholar.google.ch/scholar?start=890&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098782-143;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;[PDF][PDF] CONVERGING BLOCK CHAIN AND NEXT-GENERATION ARTIFICIAL INTELLIGENCE TECHNOLOGIES;SK Sahoo, P Pattanaik ; academia.edu;;"… enabler —cover the method for the execution of the new technology.[1] & explore Oracle's potential

in … M. Dogan, and A. Yurdakul, “IDMoB: IoT data marketplace on blockchain,” in Proceedings -

2018 Crypto Valley Conference on Blockchain Technology, CVCBT …";;;[PDF] academia.edu;https://www.academia.edu/download/66125259/IJARET_11_11_177.pdf;;;https://scholar.google.ch/scholar?start=690&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098734-36;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;[CITATION][C] A PoR/PoS-Hybrid Blockchain: Proof of Reputation with Nakamoto Fallback.;L Kleinrock, R Ostrovsky, V Zikas ; IACR Cryptol. ePrint Arch., 2020;;null;Cité 3 fois;;null;;;;https://scholar.google.ch/scholar?start=580&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098857-317;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Blockchain as a cryptographic primitive;NP Varnovsky ; International Journal of Open Information Technologies, 2020  injoit.org;;"… Therefore there is no black box construction of a PoW-blockchain from a collision-resistant hash

function family. Keywords—Black box construction, blockchain, crypto- graphic hash functions,

cryptographic primitive, information security, Proof-of-Work, random oracle model …";Cité 2 fois;Les 4 versions;[PDF] injoit.org;http://www.injoit.org/index.php/j1/article/viewFile/1044/999;"
International Journal of Open Information Technologies ISSN: 2307-8162 vol. 8, no. 12, 2020

Блокчейн как криптографический примитив
Н.П. Варновский

Аннотация—В работе блокчейн рассматривается как но-
вый криптографический примитив, представляющий собой
особую базу данных, записи в которой линейно упорядоче-
ны, а допустимые запросы к ней могут быть лишь двух
видов –– запросы на чтение записей (любым желающим)
и на добавление записи в конец базы (пользователем,
выполнившим определённые условия). При этом блокчейн
должен удовлетворять требованиям живучести и незыб-
лемости, гарантирующим добавление любой записи, коль
скоро она снабжена необходимым подтверждением права
на это действие, и «вечную сохранность» раз добавленной
Саписи.
Одним из основных является вопрос о принципиаль-

ной возможности построения такого криптографического
примитива. В статье обсуждается проблема обоснования
существования блокчейна в различных моделях, позволя-
ющих использовать (гипотетически) этот примитив для за-
щиты информации. Известные положительные результаты
не дают удовлетворительного ответа на данный вопрос.
В частности, все они получены в модели со случайным
оракулом.
В настоящей работе основное внимание уделено блокчей-

нам, отвечающим парадигме Proof-of-Work, в конструкции
которых существенным образом используются криптогра-
фические хэш-функции. При сравнительно сильных пред-
положениях доказан следующий отрицательный резуль-
тат: при условии существования семейств хэш-функций с
труднообнаружимыми коллизиями всегда найдутся такие
семейства, на которых нельзя строить PoW-блокчейны.
Как следствие, не существует blackbox-конструкции PoW-
блокчейна на основе семейства хэш-функций с труднообна-
ружимыми коллизиями.

Ключевые слова—блокчейн, защита информации, крип-
тографические хэш-функции, криптографический прими-
тив, модель со случайным оракулом, blackbox-конструк-
ции, Proof-of-Work

I. ВВЕДЕНИЕ
Посвящённая блокчейнам литература весьма обширна,

и практически всегда в ней используется словосочетание
«технология блокчейн». Однако, строго говоря, данный
термин некорректен. Очевидно, что ни конкретные крип-
тографические конструкции, ни способы их реализации
в конкретных моделях не относятся к категории техно-
логий. При этом понятие криптографического примитива
здесь более чем уместно.
По своей структуре блокчейн –– это особая база дан-

ных, состоящая из линейно упорядоченных записей и
допускающая только два вида запросов:

• запрос на чтение любой записи –– доступен любому
пользователю;

• запрос на добавление записи в конец базы данных ––
право пользователей на это действие определяется
способом реализации блокчейна и конкретным при-
НОМониоП.

Статья получена 17 ноября 2020.
Николай Павлович Варновский, Институт проблем информационной

безопасности МГУ им.М.В. Ломоносова, (email: math-dep@iisi.msu.ru).

Собственно криптографическим примитивом, называе-
мым блокчейном, такая база данных является при вы-
полнении следующих двух основных требований.
Первое условие (требование) связано с обеспечением

свойства незыблемости (persistency). Содержательно оно
означает, что никакая запись базы данных не может
быть изменена или удалена. Более того, порядок записей
зафиксирован раз и навсегда.

Замечание 1. Сто́ит отметить, что указанное свойство
имеет и негативный эффект в плане практического при-
менения соответствующих систем. Специалистам по ба-
зам данных хорошо известно, что контроль входных дан-
ных представляет собой серьёзную научно-техническую
проблему. Исправление ошибок в данных требует суще-
ственных затрат. В случае же блокчейна эта проблема
и вовсе неразрешима: ошибки во внесённых записях
исправить невозможно по определению.

Второе условие –– обеспечение свойства живучести
(liveness): если подан запрос на добавление (в конец базы
данных) записи, удовлетворяющей всем необходимым
требованиям, то эта запись будет непременно добавлена
в базу с задержкой, не превосходящей определённую
величину. Требования к записи и определение допу-
стимой задержки задаются спецификациями конкретных
реализации и приложения блокчейна.
Модели, в которых анализируются блокчейны, делят-

ся на две больших категории –– с контролем доступа
(permissioned) и без контроля доступа (permissionless).
В последнем случае добавлять записи в базу данных
может любой пользователь, выполнивший все необходи-
мые действия, предписанные протоколом. В первом же
случае добавлять записи могут только те пользователи,
которые получили на это соответствующее разрешение
(это можно отнести к тем требованиям к записи, которые
упоминались выше) от некоторого центрального органа
управления и контроля, который, следовательно, должен
быть предусмотрен в системе.
В теоретических и прикладных исследованиях систем,

связанных с защитой информации, рассматриваются цен-
тральные органы следующих трёх основных типов.
Первый тип представляет выделенный участник (поль-

зователь), выполняющий особые функции. Вопреки рас-
пространённому мнению, такой участник необходим и
для блокчейнов без контроля доступа: кто-то должен,
как минимум, инициировать процесс и задать началь-
ное состояние блокчейна. С точки зрения криптографии,
нельзя не учитывать возможность коррумпированности
этого участника, однако сценарий с таким противником
в литературе не рассматривается.
Ко второму типу относится центр доверия, который

представляет собой участника, наделённого доверием
всех остальных пользователей. Стойкость соответствую-

28



International Journal of Open Information Technologies ISSN: 2307-8162 vol. 8, no. 12, 2020

щей системы защиты информации анализируется только
в предположении, что центр доверия –– честный. Если же
центр доверия отклоняется от предписанного поведения,
должна иметься возможность доказать этот факт некоему
арбитру.
Третий тип центрального органа –– большой брат (Big

Brother): это центр доверия, действия которого не под-
вергаются контролю со стороны других пользователей,
его нечестность недоказуема.
Следует отметить, что в предполагаемых приложениях

практически всегда присутствует какой-либо централь-
ный орган, которому пользователи вынуждены доверять
выполнение тех или иных функций. В связи с этим важно
для конкретного приложения оценить степень доверия
участников этому органу и проанализировать возмож-
ность реализации блокчейна в модели с центром доверия
соответствующего вида. Естественно предположить, что
в таком случае (когда, в отличие от первоначальной
задумки, не имеет места полная децентрализация сети)
для построения блокчейнов было бы достаточно исполь-
зовать уже известные –– и хорошо изученные –– крипто-
графические средства. Однако эта проблематика остаётся
до сих пор неисследованной.
По-видимому, только одно разумное приложение, ре-

ализуемое в модели без контроля доступа, можно выде-
лить в имеющейся научной литературе по блокчейнам.
Речь идёт о решении проблемы приоритета: представ-
ляется целесообразным использовать блокчейн для фик-
сации информации о научных открытиях, изобретениях
и т. п.
Первоначальная и наиболее популярная идея созда-

ния блокчейна без контроля доступа основана на май-
нинге и протоколе консенсуса. Всякий желающий мо-
жет добавить новую запись в базу данных, если ре-
шит так называемую умеренно трудную вычислительную
задачу, которая определяется некоторой фиксированной
криптографической хэш-функцией H . Запись r поме-
щается в блок, содержащий также h−1 –– хэш-значение
предыдущего блока –– и некоторое специальное значение
η. Умеренно трудная вычислительная задача состоит в
поиске такого значения η, что выполнено неравенство
H(h−1, r, η) < Dp, где Dp –– параметр, определяющий
трудность этой задачи. Процесс поиска такого значения η
называется майнингом. На основе общих теоретических
предположений о свойствах хэш-функций считается, без
всякого обоснования, что параметр Dp можно задать
таким образом, что при случайном выборе η указанное
неравенство выполняется с вероятностью p.
Благодаря включению в каждый добавляемый блок

ссылки на предыдущий (h−1) весь массив блоков ока-
зывается объединённым в цепочку, что, собственно, и
породило (в английском варианте) термин «блокчейн».
Каждый участник хранит у себя текущее состояние

цепочки блоков и в случае успеха процедуры майнинга
(положительного завершения протокола консенсуса), до-
бавляет новый блок в конец цепочки и рассылает её всем
участникам сети с помощью специального протокола
(broadcast).
Этот подход к созданию блокчейнов основан на так

называемой парадигме проверки выполнения вычисли-
тельной работы (proof of work). Он предполагает, что

честные участники контролируют бо́льшую часть вычис-
лительных ресурсов сети.
Исследования PoW-блокчейнов находятся пока на сво-

ём начальном этапе. Имеющиеся результаты, касающи-
еся вопросов существования такого криптографическо-
го примитива, можно трактовать лишь как частичное
обоснование PoW-блокчейнов. Подробнее об этом будет
сказано ниже, в разделе III.
В литературе нередко встречаются утверждения,

смысл которых сводится к следующему: поскольку так
называемые криптовалюты используют PoW-блокчейны
и существуют годами, такие блокчейны достаточно на-
дёжны. Но следует заметить, что в некоторых теорети-
ческих работах, посвящённым криптовалютам, использу-
ются математические методы теории игр и исследования
операций, а не математической криптографии. Поскольку
в случае криптовалюты единственной целью участни-
ков является прибыль, вполне разумным представляется
предположение о том, что подавляющее большинство
участников использует рациональные стратегии. Одна-
ко оно неприменимо к криптографическому примитиву
блокчейн, предназначенному для защиты информации
(в определённом смысле).

II. МАТЕМАТИЧЕСКАЯ МОДЕЛЬ БЛОКЧЕЙНА

Блокчейн как криптографический примитив опреде-
ляется четвёркой следующих объектов: E –– множество
возможных (допустимых) записей, представляющих со-
бой битовые строки конечной длины, E ⊆ {0, 1}∗; P ––
эффективно вычислимый трёхместный предикат; R ––
эффективный алгоритм, выполняющий запросы на чте-
ние записей в блоках (этот компонент может отсутство-
вать: в предлагаемых реализациях, как правило, записи в
блокчейне общедоступны); S –– эффективный алгоритм,
выполняющий запросы на добавление записей в конец
базы данных. Запись r, данная в запросе, добавляется
при выполнении условия P (state, r, proof) = 1, где
state –– состояние блокчейна на момент получения за-
проса (в общем случае под состоянием подразумева-
ется вся цепочка блоков), proof –– зависящая от типа
блокчейна дополнительная информация, которая играет
роль подтверждения права пользователя на добавление
даннОК Саписи.
Например, в общей схеме PoW-блокчейна необходи-

мым и достаточным условием равенства P (state, r, η) =
1 (и, соответственно, возможности добавить запись) вы-
ступает выполнение неравенства H(h−1, r, η) < Dp и
отношения r ∈ E (в данном случае h−1 определяется
значением state). Если рассматривается модель с контро-
лем доступа, следует добавить и условие, проверяющее
полномочия данного абонента на добавление записей.
Требование незыблемости блокчейна определяется

следующим образом. Положим, state(t) –– состояние
блокчейна в момент времени t, представляющее собой
последовательность имеющихся в нём на данный момент
блоков. Тогда, для любых t1, t2 с условием t1 < t2
последовательность state(t1) должна быть префиксом
последовательности state(t2).
Второе требование –– живучесть –– означает существо-

вание такого числового параметра ∆, что если в момент
времени t выдан запрос на добавление записи r и предъ-
явлено доказательство proof , удовлетворяющее условию

29



International Journal of Open Information Technologies ISSN: 2307-8162 vol. 8, no. 12, 2020

P (state, r, proof) = 1, то в любой момент времени t′,
t′ > t + ∆, блокчейн (его состояние) будет содержать
запись r.
Приведённые формулировки –– это метаопределения,

поскольку для полной формализации понятий незыбле-
мости и живучести необходима модель противника, а она
существенно зависит от конкретной реализации.

III. ВОПРОС СУЩЕСТВОВАНИЯ PoW-БЛОКЧЕЙНОВ

Далее будем рассматривать основной вариант реализа-
ции блокчейна, с майнингом и протоколом консенсуса.
После того как введены все необходимые опреде-

ления, важнейшим теоретическим вопросом становится
обоснование существования данного примитива. В рабо-
те [1] при определённых предположениях и допущениях
доказана теорема существования для PoW-блокчейнов.
Подобного рода результаты можно найти и в некоторых
других публикациях.
Однако, строго говоря, вопрос о существовании PoW-

блокчейнов всё же остаётся открытым: все известные
положительные результаты доказаны в модели со слу-
чайным оракулом, когда хэш-функция заменяется ора-
кулом, вычисляющим случайную функцию, а это допу-
щение противоречит предположениям о блокчейне как о
средстве защиты информации в моделях, где нет никаких
центральных органов.
Очевидно, свойства блокчейна тесно связаны со свой-

ствами составляющих его компонентов. И в рассматри-
ваемом случае PoW-блокчейнов основной целью соот-
ветствующей теории может ставиться доказательство их
существования в предположении о стойкости использу-
емой хэш-функции. Однако здесь возникают определён-
ные проблемы, первая из которых –– обоснование суще-
ствования самой криптографически стойкой хэш-функ-
ции. На данный момент в математической криптографии
достаточно хорошо обоснованы лишь односторонние се-
мейства хэш-функций.
Рассмотрим подробнее некоторые варианты опреде-

ления семейств хэш-функций. Для этого предполагаем,
что для каждого натурального n задано некое множество
функций Hn = {h : Σn → Σm}, где m = m(n) < n и Σ
обозначает множество (алфавит) {0, 1}.

Определение 1. Пусть для каждого натурального n за-
дано Hn = {h : Σn → Σm}, где m < n. Семейство
{Hn} называется односторонним семейством хэш-функ-
ций, если выполнены следующие условия.
1) Существует полиномиальная вероятностная маши-

на Тьюринга G, такая, что G(1n) = h̄, где h̄ ––
элемент множества H̄n описаний функций из Hn.

2) Существует полиномиальная машина Тьюринга C,
такая, что C(h̄, x) = h(x) для любого h̄ ∈ H̄n и
любого x ∈ Σn.

3) Для любой полиномиальной вероятностной маши-
ны Тьюринга A, которая, получив на первом шаге
на вход 1n, выдаёт начальное значение z ∈ Σn,
справедливо следующее: пусть h̄ –– описание хэш-
функции, сгенерированное машиной G на входе 1n,
тогда для любого полинома p и всех достаточно
больших n

Pr[A(h̄) = y : y ̸= z, h(z) = h(y)] ≤ 1

p(n)
.

Известно, что такое семейство можно построить из
произвольной односторонней функции. Более проблема-
тичным является семейство хэш-функций с труднообна-
ружимыми коллизиями. В определении этого примитива
первые два пункта такие же, как и для одностороннего
семейства хэш-функций, поэтому мы их опустим, о при-
ведём только третий.

Определение 2. Семейство {Hn} называется семей-
ством хэш-функций с труднообнаружимыми коллизиями,
если для любой полиномиальной вероятностной машины
Тьюринга A, для любого полинома p и всех достаточно
больших n справедливо неравенство

Pr[A(h̄) = (z, y), y ̸= z, h(z) = h(y)] ≤ 1

p(n)
,

где h̄ –– описание хэш-функции, сгенерированное маши-
ной G на входе 1n.

Уточним некоторые особенности используемой далее
модели. Во-первых, оговорим, каким образом генериру-
ются описания конкретных хэш-функций из семейства.
Для этих целей мы дополняем модель специальным ора-
кулом, который выбирает описания хэш-функций. По-
скольку результат (теорема 1 ниже) отрицательный, такое
расширение модели его только усиливает.
Во-вторых, если описание хэш-функции выбирается

уже после того, как зафиксирована подготовленная для
добавления в блокчейн запись r (например, в модели, где
r служит запросом к оракулу), то требуются семейства,
занимающие промежуточное положение между двумя
определёнными выше семействами хэш-функций. Такие
семейства были введены в работе [2] и, независимо, в
работе [3]. Как и в предыдущем случае, мы опускаем в
определении пункты 1 и 2.

Определение 3. Пусть α : N → N –– функция, вместе
со своей обратной вычислимая за полиномиальное время
и удовлетворяющая условию α(n) ≤ n для любого n.
Семейство {Hn} называется CRα-семейством хэш-функ-
ций, если для любой полиномиальной вероятностной
машины Тьюринга A, которая, получив на первом шаге
на вход 1n, выдаёт начальное значение z ∈ Σα(n), спра-
ведливо следующее: пусть h̄ –– описание хэш-функции,
сгенерированное машиной G на входе 1n, тогда для
любого полинома p и всех достаточно больших n

Pr[A(h̄, z) = (x, y), x = zz′, x ̸= y, h(x) = h(y)] ≤ 1

p(n)
.

Для дальнейшего в дополнение к соглашению о спе-
циальном оракуле мы принимаем самое сильное из при-
ведённых предположение –– о существовании семейств
хэш-функций с труднообнаружимыми коллизиями. В
этих условиях справедливо следующее утверждение, ко-
торое показывает, что нельзя строить blackbox-конструк-
ции PoW-блокчейна исходя из произвольного семейства
хэш-функций такого типа.

Теорема 1. Существуют семейства хэш-функций с
труднообнаружимыми коллизиями, не позволяющие
строить PoW-блокчейны.

Доказательство. Пусть {Hn} –– семейство хэш-функций
с труднообнаружимыми коллизиями, гдеHn = {h : Σn →

30



International Journal of Open Information Technologies ISSN: 2307-8162 vol. 8, no. 12, 2020

Σm}, m < n. Построим ещё одно семейство функ-
ций {H ′

n}, полагая, что множества описаний функций
из обоих семейств совпадают, H̄ ′

n = H̄n. Пусть Dp ––
параметр из определения предиката P . Dp очевидным
образом определяет параметр l –– количество начальных
нулей в «целевом» для майнинга хэш-значении, то есть
l –– минимальная длина состоящего из нулей префикса в
хэш-значении, которое успешно пройдёт проверку, опре-
деляемую предикатом P . Для всякой функции h ∈ Hn

строим функцию h′ ∈ H ′
n, которая отличается от h только

в случае, когда для данного аргумента x в хэш-значении
h(x) есть l начальных нулей, –– тогда h′ записывает в
начальный (старший) бит единицу.
Очевидно, что {H ′

n} –– семейство хэш-функций с труд-
нообнаружимыми коллизиями. Так же очевидно, что се-
мейство {H ′

n} не позволяет строить блокчейны, посколь-
ку майнинг никогда не приводит к успеху.

IV. ЗАКЛЮЧЕНИЕ

Понятие блокчейна с математической точки зрения
наиболее адекватно вписывается в ряд криптографиче-
ских примитивов. Подтверждение выполненной работы
(proof of work) остаётся основным подходом к построе-
нию блокчейнов в модели без контроля доступа. Однако
и для этого случая до сих пор не найдено надёжного
обоснования.
Вместе с ";"""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.5""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dcterms:created"",""2020-12-01T11:16:31Z""
""language"",""ru""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""Content-Length"",""152945""
""pdf:hasMarkedContent"",""false""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""meta:creation-date"",""2020-12-01T11:16:31Z""
""created"",""2020-12-01T11:16:31Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""5""
""Creation-Date"",""2020-12-01T11:16:31Z""
""resourceName"",""999""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""4751"",""5273"",""4694"",""1816"",""1774""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""producer"",""XeTeX 0.99998""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""XeTeX 0.99998""
""pdf:docinfo:created"",""2020-12-01T11:16:31Z""
";https://scholar.google.ch/scholar?start=860&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098778-137;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Formalizing Bitcoin Crashes with Universally Composable Security;J Ke, P Szalachowski, J Zhou, Q Xu ; International Conference on …, 2020  Springer;;"… The node can not mining locally by using random oracle … the modification of Extend State is actually

not the key point of the selfish mining, withholding proof-of-work means the attacker can not earn

the reward from the blockchain … In: Katz, J., Shacham, H. (eds.) CRYPTO 2017 …";Autres articles;;[PDF] iacr.org;https://eprint.iacr.org/2020/1098.pdf;"
Formalizing Bitcoin Crashes with Universally Composable Security

Junming Ke
Shandong University

junmingke1994@gmail.com

Pawel Szalachowski
SUTD

pawel@sutd.edu.sg

Jianying Zhou
SUTD

jianying zhou@sutd.edu.sg

Qiuliang Xu
Shandong University

xql@sdu.edu.cn

Abstract— Bitcoin has introduced an open and decentralized
consensus mechanism which in combination with an append-
only ledger allows building so-called blockchain systems,
often instantiated as permissionless cryptocurrencies. Bitcoin
is surprisingly successful and its market capitalization has
reached about 168 billion USD as of July 2020. Due to its high
economic value, it became a lucrative target and the growing
community has discovered various attacks, proposed promis-
ing improvements, and introduced contingency plans for
handling catastrophic failures. Nonetheless, existing analysis
and contingency plans are not formalized and are tailored
only to handle a small specific subset of diverse attacks, and
as such, they cannot resist unexpected emergency cases and
it is hard to reason about their effectiveness and impact on
the system.

In this work, we provide a formalized framework to
help evaluate a variety of attacks and their mitigations.
The framework is based upon the universal composability
(UC) framework [4] to describe the attacker’s power and the
system’s security goals. We propose the system in the context
of Bitcoin and to the best of our knowledge, no similar
work has been proposed previously. Besides, we demonstrate
and evaluate our model with different case studies from the
real world. Finally, we signal remaining challenges for the
contingency plans and their formalization.

Index Terms—Blockchain Security, Bitcoin, Contingency
Plans, Attacks

1. Introduction

Satoshi Nakamoto’s Bitcoin [35] is the first decentral-
ized system which does not rely on a trusted party to reach
consensus in a large set of mutually untrusting nodes.
Up to now, Bitcoin is the most popular cryptocurrency.
Every Bitcoin node replicates the public ledger, called
the blockchain, and tries to extend it by generating a
new block pointing to the previous block and aggregating
received transactions. The process of generating a new
valid block is called mining and nodes (called miners)
are incentivized to run the protocol as each added block
rewards its finder with a block reward and transaction fees
included.

With the increasing success of Bitcoin, there have been
proposed multiple blockchain systems with different capa-
bilities [20], [22], [34], [36]. Consequently, the blockchain
security has received increasing attention by researchers
analyzing various aspects of blockchain platforms [2], [7],
[14], [15], [37], [40]. Since these systems promise to

significantly change multiple sectors and businesses their
security is critical. Interestingly, their inherent properties,
like decentralization and openness, do not help with the
security life cycle known from traditional platforms and
applications. These systems are difficult to be updated
and patched and this limitation is strongly manifested
while considering hypothetical catastrophic crashes, like
a broken cryptographic primitive, that may affect most of
the blockchain users.

Unfortunately, we can predict that it is only a matter
of time when a catastrophic failure happens to a popular
cryptocurrency like Bitcoin. For instance, an implemen-
tation of a privacy-oriented cryptocurrency Zerocoin [26]
had a critical bug found by noticing irregular coin spends
on the 19 April 2019. Subsequently, the developers tried to
replace the core element of the system by another protocol
as an ad-hoc contingency plan [24]. To mitigate the effects
of such events, Bitcoin developers maintain the documen-
tation of Bitcoin contingency plans [38]. However, these
plans cover only a small subset of possible failures in their
limited scope. Moreover, these plans are based rather on
predictions and speculations, and are not supported by any
rigorous formal reasoning.

In this paper, we propose a methodology and frame-
work that helps to formally reason about crashes in
Bitcoin. In particular, we aim to answer the following
questions:

• What component failures may be particularly
harmful to the protocol?

• How could we respond if these components fail
(i.e., propose contingency plans)?

• Can we provide a uniform framework for model-
ing crashes and contingency plans of blockchain
systems?

Due to the uncertainty of the adversary’s power and
strategies, it is not an easy task to formulate possible
crashes and contingency plans. One promising direction
is to use abstraction and model the Bitcoin functionality.
In short, the main application of the The bitcoin protocol
is as a decentralized currency system with a payment
mechanism, which is what it was designed for. An impor-
tant question is then: what functions does Bitcoin achieve
and under what assumptions? To formally answer this
question we propose to use the universally composable
(UC) paradigm [4] that has been proved to be a successful
methodology reasoning about such complex systems [3].
Contributions

In this work, we aim to analyze the Bitcoin security
via the UC blockchain protocol and formalize the Bit-



coin crashes through the meticulous investigation. More
specifically, our contributions are as follows:

• Firstly, we propose a general framework for the
Bitcoin system in order to analyze, detect, and mit-
igate adversarial behaviors. Our framework takes
the given attacks as input, while handling the
detection method, damage level of the system, as
well as a contingency plan as output. To the best
of our knowledge, there is no any similar prior
work.

• Secondly, thanks to the UC treatment of the Bit-
coin protocol, we illustrate the basic structure of
our formalized security model as well as its analy-
sis by extracting the functionality of each protocol.
Our security model could help the framework to
generate contingency plans.

• Thirdly, considering the diversity of attack strate-
gies, our framework categorizes the damage level
of the system and provides a mitigation step,
which could be adopted as the template for a
contingency plan.

• Finally, we show the feasibility of our framework
by demonstrating and analyzing it with two dif-
ferent use cases (i.e., network assumptions, and
mining process). We also identify remaining chal-
lenges for the contingency plans modeling.

2. Related Work

The Bitcoin design and its rationale are mostly de-
scribed in its whitepaper [35]. The document is not formal
and does not dive into system details or its analysis,
however, multiple papers have focused on analyzing the
underlying concepts and techniques related to Bitcoin and
the blockchain technology [1], [6], [17], [41]. Due to
the immaturity of the Bitcoin protocol at the beginning,
a lot of attacks has been raised, such as selfish mining
[1], [2], [15], where a miner adopts a deviated (mali-
cious) mining strategy to increase its reward. Other attacks
include double-spending attacks [32], network-level split
attacks [9], forking the public blockchain to invalidate the
target transactions [27], or eclipse attacks isolating victims
from other peers in the peer-to-peer network [13], [25],
[29]. Given the Bitcoin’s weakness, a large kind of litera-
ture has been proposed with a novel scheme named proof
of stake protocol, With all recent interest in blockchain
systems, only a little research effort has been devoted to
blockchain catastrophic events and contingency plans [38].
Giechaskiel et al. [10] first present the systematic analysis
of the effect of broken primitives in Bitcoin. Their analysis
reveals that some breakage causes serious problems for
Bitcoin, whereas others seem to be inconsequential.

In cryptography, proof of security in the simulation-
based UC framework is considered the standard for
demonstrating that a protocol “does its job securely” [4].
The framework was subsequently extended and modified.
Katz et al. [19] proposed a novel approach to defining syn-
chrony in the UC framework by introducing functionali-
ties exactly meant to model, respectively, bounded-delay
networks and loosely synchronized clocks. No constant-
round asynchronous MPC protocols based on standard
assumptions are known at that time, Coretti et al. [5]

realized the synchronous and asynchronous models have
to a large extent developed in parallel with results on
both feasibility and asymptotic efficiency improvements
in either track and they close this gap by providing the
first constant-round asynchronous MPC protocol that is
optimally resilient (i.e., it tolerates up to 1/3 corrupted
parties), adaptively secure, and makes black-box use of a
pseudo-random function.

Based on the assumption that the computational puzzle
is modeled as a random oracle, Pass et al. [30] then proved
that the blockchain consensus mechanism satisfies a strong
forms of consistency and liveness in an asynchronous
network with adversarial delays that are a-priori bounded,
within a formal model allowing for adaptive corruption
and spawning of new players. Concurrently, Garay et al.
[7] proposed and analyzed applications that can be built
“on top” of the backbone protocol, specifically focusing
on the Byzantine agreement (BA) and on the notion of
a public transaction ledger. Garay et al. [8] subsequently
extend this work to provide the first formal analysis of
Bitcoin’s target calculation function in the cryptographic
setting, i.e., against all possible adversaries aiming to
subvert the protocol’s properties.

From those points of view, Kiayias et al. [21] modeled
the ideal guarantees as a transaction-ledger functionality
in the context of universal composition framework. Sub-
sequently, Badertscher et al. [3] put forth the first UC
(simulation-based) proof of the Bitcoin security and the
functionality allows for participants to join and leave the
computation and allows for adaptive corruption.

3. Preliminaries

3.1. Functionalities

In contrast to weaker property-based notions, that only
guarantee security in a standalone setting [18] or under
sequential composition [11], a UC-secure protocol main-
tains all security properties even when run concurrently
with arbitrary other protocol instances.

The basic idea of the security proofs in the UC model
is the real and ideal worlds paradigm [4]. First, we should
define a cryptographic task to be achieved in the real
world, namely, a distributed protocol that achieves the
task across many untrusted processes. Then, to show that
it is secure, we compare it with an idealized protocol in
which processes simply rely on a single trusted process
to carry out the task for them (and so security is satisfied
trivially). The program for this single trusted process is
called an ideal functionality as it provides a uniform way
to describe all the security properties we require from the
protocol [23]. We assume a protocol π realizes an ideal
functionality F (i.e., it meets its specification) if every
adversarial behavior in the real world can also be exhibited
in the ideal world. The steps to prove a protocol secure
can seem as follows:

1) Specification: for a given ideal functionality F in
the ideal world, we should design a protocol π
in the real world which achieves the task in the
ideal world.

2) Construction: we must provide a simulator S that
translates any attack A on the protocol π into an
attack on F .

2



3) Security proof: we need to show that running
π under an attack by any adversary A (the real
world) is indistinguishable from running F under
attack by S (the ideal world) to any distinguisher
Z called the environment.

In particular, Z is an adaptive distinguisher, meaning
that it interacts with both the real world and the ideal
world, and the simulation is sound if no Z can distinguish
between the two. The primary goal of the UC model is
composability. Suppose a protocol π is a protocol func-
tionality that realizes a functionality F , and a protocol P
relies on F as a subroutine, in turn realizes an application
specification functionality G. Then, the composed protocol
P ◦π, in which calls to F are replaced by calls to π, also
realizes G. Instead of analyzing the composite protocol
consisting of P and π, it suffices to analyze the security
of P itself in the simpler world with F , the idealized
version of π.

This paper focuses on the functionalities in the ideal
world. Because we base on a secure proof of Bitcoin’s UC
model from the previous research [3], for every attack
we consider only the functionality it breaks, i.e., the
attacker’s behavior could threaten or break nothing but
the functionality assumptions. In such a case, we fix the
protocol by “recovering” the functionality, what then can
be specified as a contingency plan.

3.2. Notation

A blockchain C = B1, ..., Bn is a sequence of blocks
where each block Bi =< si, sti, ni > is a triple consisting
of the pointer si, the state block sti and the nonce ni. The
head of the chain C is the block head(C) := Bn and the
length length(C) of the chain is the number of blocks,
i.e., length(C) = n. The chain Cek is the sequence of the
first length(C)−k blocks of C. A special block is the gen-
esis block G =<⊥, gen,⊥> which contains the genesis
block state gen := Îľ. The state ~st encoded in C is defined
as a sequence of the corresponding state blocks, i.e.,
~st := st1||...||stn. For a blockchain C to be considered a
valid blockchain, it needs to satisfy following two certain
conditions. The first is chain-level validity, this is defined
with respect to a difficulty parameter D ∈ [2k], where
k is the security parameter, it also requires a given hash
function H(·) from random oracle: {0, 1}∗ → {0, 1}k.

The Bitcoin system can be seen as a protocol run by
each participant (i.e., node) Pi among the Bitcoin network.
We treat each functionality in the Bitcoin protocol as
the functionality F providing some functions which are
needed for the node Pi. Before we define the security goal
of the blockchain, we introduce the basic components of
the model.

• Functionality denotes the process algorithm
which could accept a query and respond to the
query. In our model, we treat each composable
function in the UC model as the functionality.

• Protocol in the real world achieves the task in the
ideal world, the UC paradigm treats protocol as
the real world.

• Node represents each user Pi ∈ P who has
access to query a functionality. In Bitcoin, each

Algorithm

Functionality

Protocol

Registration
De-Registration

Clock Transaction
Network

Block
Network

Random
Oracle

Ledger
Queries

Other
Calls

Fetch
Information

Ledger
Maintenance

Extend
State

Valid
Struct

Is
Validate

Max
Valid

Extend
Chain

Validate Blockify
Extend
Policy

Predict
Time

Function

Figure 1. The components of the main structure of the UC blockchain
protocol.

participant is a node, and the Bitcoin network in-
tends to allow each node to process functionalities
correctly.

• Environment. In our model, all regular processes
are within the environment. An attacker A can
observe the environment and launch adaptive at-
tacks, e.g., change the functionality output (we
will define the malicious behavior later).

3.3. Bitcoin as a Transaction Ledger

To model the Bitcoin protocol, we need to define its
(sub)protocols that will be run to facilitate access to the
Bitcoin network resources and to provide its security. The
main question in that context can be formulated as:: what
functionality can the blockchain provide to cryptographic
protocols? For a simple presentation, in this work we do
not present all functionalities and protocols of the Bitcoin
protocol, and we refer readers to the work we base on [3].
However, we select a few significant functionalities and
protocols to illustrate how our framework works. We show
the UC blockchain protocol components in Fig 1, where
the parties have access to the functionalities and execute
the protocol (including its algorithms and functions).

3.3.1. Functions and Algorithms. Each block st ∈ ~st
of the state encoded in the blockchain has the form
st = blockify( ~N) where ~N is a vector of transactions and
blockify is defined as the function to format the ledger
state output. In order to maintain the global ledger, the
function predict time is used to predict the real-world time
advancement according to the current time τL reported by
the clock functionality (see Appendix for more details).
Extend policy guarantees that the adversary cannot block
the extensions of the state indefinitely, and that occasion-
ally an honest miner will create a block. The element
buffer is used for submitting input values, and Validate
is used to clean the buffer of transactions, which decides
on the validity of a transaction with respect to the current
state.

To valid a blockchain, the two aspects should be
guaranteed: chain-level validity (Valid Struct) and state-
level validity (Is Valid State).

Chain-level Validity. This algorithm is defined to repre-
sent the chain validity requirement, i.e., for each i > 1,

3



Algorithm 1 Algorithm Max Valid
Input: input (C1, C2, ..., Ck).
Output: output Ctemp.
1: Ctemp ← ε.
2: for i = 1 to k do
3: if Valid Struct and Is Valid State and (length(Ci) >

length(Ctemp)) then
4: length(Ctemp) = (length(Ci).
5: end if
6: end for
7: Return Ctemp.

Algorithm 2 Algorithm Extend Chain

Input: input valid Chain C is valid with state ~st, state
~st||st is valid.
Output: output C.
1: Set B ←⊥.
2: s← H[head(C)].
3: for i = 1 to q do
4: Choose nonce n uniformly at random form (0, 1)k

and set B ←< s, st, n >.
5: if H(B) < D then
6: break.
7: end if
8: end for
9: if B 6=⊥ then

10: C ← C||B.
11: end if
12: Return C.

the value si contained in Bi satisfies si = H[Bi−1] and
H[Bi] < D, w.r.t. D ∈ 2K which is a difficulty parameter.

State-level Validity. The state-level validity is defined on
the state ~st encoded in the blockchain C and specifies
whether this content is valid.

We omit the presentation of instantiations of these two
elements since they are proposed by the previous work.

To maintain a blockchain, the notion of the longest
valid chain is significant. The algorithm is given as Alg 1.

In addition, a core step in Bitcoin is to extend a given
chain C by a new block B to yield a longer chain C||B.
The algorithm shown in Alg 2 tries to find a proof-of-work
which allows extending the given chain C by a found
block B which encodes st.

3.3.2. UC blockchain Protocol. The UC blockchain pro-
tocol contains the following four parts.

Variables and initial values. The protocol stores a local
working chain Cloc and manages a separate chain Cexp
to store the current chain whose encoded state ~st is
exported as the ledger state. The variable isInit stores the
initialization status and the variable buffer stores a list
of transactions received from the network. A timestamp
t denotes when a given party was active last time, while
the flag Welcome is to indicate whether a notification that
a new party joined the network was received (the party
stores its registration status to the hybrid functionalities
internally).

Algorithm 3 Sub-protocol Read Ledger

Input: input t, T, τ, sid, isInit,~st, Cexp.
Output: output (Read, sid, s̃t

bT
).

1: if τ corresponds to an update mini-round and t < τ
and isInit then

2: Excute the sub-protocol Fetch Information.
3: Set t← τ .
4: end if
5: Encode state ~st in Cexp.
6: Return (Read, sid, s̃t

bT
).

Algorithm 4 Sub-protocol Fetch Information

Input: input (Fetch, sid), buffer,Welcome, ~st
bT

.
Output: output Cloc, Cexp, buffer.

1: Send (Fetch, sid) to Fbc
N−MC .

2: Denote the response from Fbc
N−MC by (Fetch, sid, b).

3: Cloc, Cexp ← maxvalid(Cloc, Cexp, C1..., Ck).
4: Send (Fetch, sid) to F tx

N−MC .
5: Denote the response from F tx

N−MC by (Fetch, sid, b).

6: Extract received transactions (tx1, ..., txk) from b.
7: Set buffer← buffer||(tx1, ..., txk).
8: if a newparty message was received then
9: Welcome = 1.

10: else
11: Welcome = 0.
12: end if
13: Remove all transactions from buffer which are invalid

with respect to ~st
bT

.
14: Return Cloc, Cexp, buffer.

(De)Registration. The protocol defines that on receiving
(register, sidC) and (deregister, sidC) it is forwarded to
Clock and its output is returned. The protocol receives
(register, sid) and (deregister, sid), sends (register, sid)
and (deregister, sid) to the network and the random oracle
functionality, if the party is registered with the clock.
Then the respective variables are set. The protocol on
receiving (is− register, sid) returns (register, sid, 1) if the
party is registered with the network and the random oracle
functionality. Otherwise, (register, sid, 0) is returned.

Ledger-Queries. Upon receiving (Submit, sid, tx),
buffer← buffer||tx is set, and (Multicast, sid, tx) is sent
to F tx

N−MC . Upon receiving (Read, sid), (Clockread, sidC)
is sent to GClock, and (Clockread, sidC, τ) is received as
a response and processed as in Alg 3.

Upon receiving (Maintainledger, sid,minerID) the fol-
lowing is executed atomically:

• If isInit = false, then set all variables to their
initial values. set isInit← true and output
(Multicast, sid, newparty) to F txN−MC .

• Execute sub-protocol Ledger Maintenance.

The sub-protocol Ledger Maintenance is specified as
following:

4



Algorithm 5 Sub-protocol Maintenance
Input: input τ .
Output: output Cloc.

1: if τ corresponds to a working mini-round then
2: Let ~st be the encoded state in Cloc.
3: Set buffer′ = buffer.
4: Phase buffer′ as sequence (tx1, ..., txn).
5: Set ~N ← txcoin−baseminerID .
6: Set st← blockify( ~N).
7: repeat
8: Let (tx1, ..., txn) be the current list of transac-

tions in buffer′.
9: for i = 1 to n do

10: if V alidTx(tx, ~st||st) = 1 then
11: ~N ← ~N ||txi.
12: Remove tx from buffer′.
13: Set st← blockify( ~N).
14: end if
15: end for
16: until ~N does not increase anyone.
17: Cnew ← extendchainD(Cloc, st, q).
18: if Cnew 6= Cloc then
19: Update the local chain, i.e., Cloc ← Cnew.
20: end if
21: Send (Multicast, sid,Cloc) to Fbc

N−MC .
22: if the flag Welcome = 1 then
23: Send (Multicast, sid, buffer) to F tx

N−MC .
24: else
25: Give up activation.
26: end if
27: Go to the next step in the next activation.
28: else
29: Go to the beginning of step 2 in the next activation.
30: end if
31: Return Cloc.

1) If a (Clockupdate, sidC) has been received
during this update (mini)round then send
(Clockupdate, sidC) to Gclock, and in the next
activation go to the next step. Otherwise in the
next activation repeat this step.

2) Send (Clockread, sidC) to Gclock, receive as an-
swer (Clockread, sidC), and proceed as shown in
Alg 5.

3) If a (Clockupdate, sidC) has been received during
this working round then send (Clockupdate, sidC)
to Gclock, and in the next activation go to the next
step. Else in the next activation repeat this step.

4) Execute sub-protocol Read Ledger as shown in
Alg 3.

Handling other external calls. Upon receiving
(Clockread, sidC), forward it to Clock and return its
output. Upon receiving (Clockupdate, sidC), forward it to
Clock (if it was registered with the clock).

Algorithm 6 Functionality Random Oracle FRO

Input: input x. It maintains a function table T1 (initially
T1 = {}).
Output: output (x, y).
1: if no pair of the form (x, ) is in T1 then
2: Sample a value y uniformly.
3: Add (x, y) to T1.
4: end if
5: Get (x, y) from T1.
6: Return (x, y)

Algorithm 7 Functionality Chosen-format Bounded Pre-
image Oracle FCBRO

Input: input (a, b, yl, yh, i). It maintains a function table
T2 (initially T2 = {}).
Output: output (x, y).
1: Find x to satisfy yl ≤ h(a||xi||b) ≤ yh.
2: add (x, y) to T2.
3: Return (x, y).

4. Formalizing Bitcoin Crashes

4.1. Motivation

Bitcoin is a complex decentralized system that com-
bines network, consensus, computation, game theory and
other aspects from different areas. This paper does not
intend to model the Bitcoin system, however, we base on
the prior work [3] to extract some useful constructions
and assumptions. As a large-scale protocol, Bitcoin can
be divided into functionalities. A functionality is part of
the features to be implemented by the Bitcoin system (it
is modeled like an algorithm executed by a trusted third
party). Functionalities represent action goals the protocol
aims to achieve in the ideal world. For example, a simple
functionality is the hash query, which provides a random
number y for each input x – it is commonly recognized
as the random oracle (RO) model as presented in Alg 9.

However, with aging hash functions and their imple-
mentations the RO assumption may not hold and such
an event would “modify” this functionality. Giechaskiel
et al. [10] present the first systematic analysis of the
effects of the broken hash mechanism on Bitcoin. They
summarize different types of breakage into a chosen-
format bounded pre-image oracle as in Alg 7, and they
discuss potential migration pitfalls of the breakage and
the contingency plans.

Inspired by this approach, this work aims at another
promising direction, namely to analyze every functionality
of the Bitcoin system and to find out corresponding for-
malized contingency plans. Unlike previous work, we give
a framework allowing to reason about entire crash classes
and contingency plan of each functionality of the proto-
col (within the considered UC model). Using the above
example, we use the modified functionality F ′CBRO to
represent an adversary. The modified functionality F ′CBRO
corresponds to the adversary with the ability to access not
only the FRO, but also the FCBPO. As shown in Fig 8, the
adversary could access the random mapping y of arbitrary
input x and could also determine x of arbitrary input y
(if the input y does not have corresponding pre-image x,

5



Algorithm 8 The modified functionality Chosen-format
Bounded Pre-image Oracle F ′CBRO
Input: input x or (, , y, y, 0).
Output: output (x, y).
1: if receive x then
2: Send x to FRO and receive (x, y).
3: end if
4: if receive (, , y, y, 0) then
5: Send (, , y, y, 0) to FCBRO and receive (x, y).
6: end if
7: Return (x, y).

return φ). Such a modeling corresponds to reasoning about
the Bitcoin’s hash function being broken in the real world,
allowing the adversary to find the pre-image of the input
y.

Interestingly, the Bitcoin documentation considers the
case of the hash function being broken and the correspond-
ing contingency plan can be summarized by the following
steps:

• Every participant should be informed about the
breach.

• A new secure hash algorithm should be deployed.
• The old blockchain state (i.e., the unspent coins)

should be hardcoded and protected by the new
secure hash algorithm.

The first and third steps are introduced to eliminate
losses and to maintain the state before the breakage. From
our perspective, the second step is quite interesting as we
can view it as denying the functionality FCBRO for the
adversary, i.e., if the broken hash function is replaced,
she has no access to the functionality FCBRO anymore.

As shown in Fig 2, when the hash function is broken,
the adversary has access to F ′CBRO. F ′CBRO is the com-
bination of FCBRO and FRO, for an adversary, she could
invoke F ′CBRO, then F ′CBRO could access the FCBRO or
FRO with inputs, namely, x or (, , y, y, 0), F ′CBRO receives
the outputs from FCBRO or FRO and finally returns the
results to the adversary. Thus a contingency plan could
be specified as follows: if the adversary obtains access
to FCBRO, we need to restrict this access by replacing
(recovering) FCBRO by FRO.

...

F1

F2

FRO

...

F1

F2

F’CBRO

Broken

Recover

Protocol Breach

Figure 2. Our functionality and the contingency plan

This simple example provides the main intuitions be-
hind our framework. In short, we represent an adversary
by parts of the protocol she can affect. Then we build
the extracted functionality to analyze the advantage that

Attacker’s 
Behaviour

Check Call Difference Rectify

Output

Our Formalized Model 

The Given
    Attack

Detection Breach Contingency
      Plans

Input

Figure 3. Our methodology to cope with attacks.

the adversary is obtaining while attacking the system. The
change to the functionality that restricts such an advantage
is proposed as a contingency plan.

4.2. Methodology

We aim to analyze and mitigate attacks and crashes,
however, in practice it is infeasible to enumerate all
possible attacks due to the protocol complexity and the
huge attack vector space. On the other hand, omitting
an attack in the analysis could result in incomplete anal-
ysis or non-functional contingency plans. Therefore, to
maximize the effectiveness of our framework, we take
an approach where entire attack classes are considered
(instead of single attack vectors). Our core observation is
that abstractions introduced by the UC model significantly
help our approach to capture and handle the protocol’s
complexity in a formalized way.

Our framework is illustrated in Fig 3.

• For a given attack, we first extract the attacker’s
behavior as the basis of our process. The process
goes as follows, firstly we put the attacker’s be-
havior into our formalized model and we intend
to find the attack’s pattern and the broken parts.
We can verify the broken parts through invoking
a special function (i.e., a check call), which can
be seen as a detection module.

• Secondly, from the attacker’s behavior, we can
find the difference between the base protocol (that
we want to achieve) and the broken protocol (i.e.,
after the attack). This difference characterizes the
breakage of the protocol (i.e., its specific affected
components).

• Finally, because we identified the breakage (i.e.,
the difference between the base and broken proto-
col), we can rectify the deviation from the model’s
view and this rectification can be mapped in the
contingency plan in the real world.

To sum up, the framework imports the given attack
as the input, and exports the detection, the breakage, and
the contingency plans as the output. In the following we
sketch our framework as shown in Figure 4.

To realize our methodology, in the first place we need
to formalize the protocol by defining what are the prop-
erties of the ideal protocol (i.e., what properties should
be achieved when the protocol functions correctly). We
adopt the UC model of Badertscher et al. [3] as the base

6



Protocol

Statistically close

 Given
Attacks

    UC
Paradigm

Real World

...

F1

F2

P1

P2

Breach

Contingency 
      plans

Detection

Mining
Network

Consensus

...

Hash

Nodes

Input / Output

Protocol
Functionality

Process in real world
Interact

Attacker

BrokenRecover

Storage
...

F1

F2

F3

       Idea
Functionality

 Broken
Protocol

...

F1

F2

P’1

P2

Figure 4. High-level overview of our framework.

model for the correct Bitcoin protocol. Once an attack is
launched by an attacker, the real world’s process could
be harmed more or less, this event will be modeled as
a deviation from the base Bitcoin protocol, i.e., some
functionalities or protocols will not work as expected
which can be seen as replacing this functionality by the
attacker.

For example, the Bitcoin protocol requires a solution
to a cryptographic puzzle as part of the block generation.
This solution is found by finding a partial pre-image
of a hash function (i.e., Proof-of-Work, PoW), requiring
enormous computation of the Bitcoin network. However,
if the adversary finds a way to solve the hard puzzle with-
out finding a pre-image, the PoW mechanism would be
replaced by a simple computation in our model (modeling
the adversary breaking the hash functionality). This would
imply that the Bitcoin protocol is partially modified by the
attacker. In our model, we define such a replacement as
an attack and we are able to give the contingency plans
to restore the Bitcoin protocol in such a case. Moreover,
another advantage in adopting the UC methodology is that
when a property is proved under some assumptions, we do
not need to consider the adversary’s behavior beyond the
Bitcoin protocol, i.e., the environment in the UC model.
We only deal with the replacement or the modification of
the affected functionalities in the ideal world.

Moreover, although we focus on Bitcoin, our frame-
work could also be deployed in other cryptocurrencies as
long as the basic protocol has been proved to be secure
in the UC model.

4.3. Adversary Model

Firstly, we assume an adversary able to cha";"""date"",""2020-09-11T15:49:16Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2020-09-11T15:49:16Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016) kpathsea version 6.2.2""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2020-09-11T15:49:16Z""
""created"",""2020-09-11T15:49:16Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-09-11T15:49:16Z""
""resourceName"",""1098.pdf""
""Author"",""""
""producer"",""pdfTeX-1.40.17""
""pdf:docinfo:producer"",""pdfTeX-1.40.17""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""6"",""13"",""15"",""6"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""24"",""6""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2020-09-11T15:49:16Z""
""Last-Modified"",""2020-09-11T15:49:16Z""
""dcterms:modified"",""2020-09-11T15:49:16Z""
""title"",""""
""Last-Save-Date"",""2020-09-11T15:49:16Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2020-09-11T15:49:16Z""
""meta:save-date"",""2020-09-11T15:49:16Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016) kpathsea version 6.2.2""
""Content-Length"",""2017860""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""15""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""4437"",""5217"",""4645"",""3459"",""3641"",""3774"",""4108"",""4818"",""4957"",""4622"",""4814"",""3922"",""5806"",""5231"",""3111""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-09-11T15:49:16Z""
";https://scholar.google.ch/scholar?start=680&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098835-264;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;[PDF][PDF] Blockchain Systems and Their Potential Impact on Business Processes;S Heister, V LoRusso, K Yuthas ; Journal of Behavioral …, 2020  jbam.scholasticahq.com;;"… After completing the exercise, they were able to successfully execute transactions in an Oracle

blockchain software environment and said the Smartify case … Many more resources, for both

beginners and experts in blockchain, can be accessed through the Crypto Canon web …";Autres articles;;[PDF] scholasticahq.com;https://jbam.scholasticahq.com/article/14183.pdf;"
BLOCKCHAIN SYSTEMS AND BUSINESS PROCESSES 

  

Copyright Š Institute of Behavioral and Applied Management. All Rights Reserved 97 
 

 
Blockchain Systems and Their Potential Impact on Business Processes 

 

 

Stanton Heister 

Portland State University 

 

Vince LoRusso 

TrueUp 

 

Kristi Yuthas 

Portland State University 

 

Abstract 

 

Blockchain technologies introduce fundamental changes in the mechanisms for verifying 

identity, transferring wealth, securing records, and tracing the movement of assets. The 

technology is poised to profoundly affect business processes and models in industry, 

government, and the social sector. Because graduating business students are likely to work in 

businesses that deploy or interact with blockchain and blockchain-related technologies, business 

programs must prepare them by introducing  the intellectual foundations of this emerging 

technology and the operating practices it enables. This paper introduces a paper-based 

assignment designed to provide students this valuable opportunity. 

 

Keywords: blockchain, business, students, teaching, technology 

 

Introduction 

 

Blockchain technology is essentially an advanced tracking system that links multiple 

parties involved in a business process—buyers, sellers, logistics companies, banks, and other 

intermediaries—in a single system known as a “distributed ledger.” The transactions in this 

shared ledger are encrypted and immutable; this enables participants to establish a single source 

of truth, consensus around each transaction, and real-time tracking of assets and value between 

parties.  Global investment in this groundbreaking technology by businesses and industries is 

increasing dramatically each year. Business students of today are likely to soon work in 

companies that deploy or interact with blockchain, so introducing them to these technologies is 

critical. Further, assurance of learning standards applied by the AACSB recognize the 

importance of equipping students with an understanding of emerging technologies (AACSB, 

2019).  

 

Despite businesses’ rapidly growing investment in and experimentation with blockchain 

technology, many business school programs do not yet offer training in the subject. One reason 

for this may be the newness and technological complexity of the subject, which create a steep 

learning curve for professors who are seeking to cover it. In addition, formalized teaching 



BLOCKCHAIN SYSTEMS AND BUSINESS PROCESSES 

  

Copyright Š Institute of Behavioral and Applied Management. All Rights Reserved 98 
 

materials on blockchain—in particular, hands-on assignments for beginning students without 

computer science backgrounds—are difficult to find.   

 

This paper provides a simple pencil-and-paper assignment that can be used to introduce 

students to blockchain software from a user perspective. Most business users do not need to 

understand the mathematical and technological underpinnings of blockchain platforms to learn 

how these systems operate and to recognize their potential value for business. The hands-on 

project in this paper is designed to help students develop a working understanding of the basic 

concepts of this high-potential technology.   

 

Background 

 

Blockchain is positioned to bring major changes to all areas of business. Students 

graduating today need to understand what blockchain technology is and how it is likely to affect 

their future professions. Because blockchain has the potential to profoundly disrupt many 

industries, training students about it now and in the near future is increasingly important. The 

knowledge that business students gain from their basic accounting and information systems 

courses provides a solid foundation for understanding this technology. 

 

Blockchain has captured the attention of companies across many vertical markets; 

governments; and venture capital firms. Investment in the technology is rapidly growing. 

International Data Corporation (IDC), a global provider of market intelligence, estimates that 

worldwide spending on blockchain solutions reached over $2 billion in 2018, an increase of 

more than 100% over 2017 (Shirer & Goepfert, 2018).  Additionally, IDC predicts that 

blockchain spending will grow at a compound annual growth rate of 81.2% over the next few 

years, reaching $9.7 billion in 2021 (Shirer & Goepfert, 2018).  Driving this growth in spending 

is an increasing awareness of blockchain technologies among senior executives around the globe. 

In a 2018 Deloitte survey of over 1000 senior executives (in companies of $500 million or 

more), 84% of executives agreed with the statement that “blockchain technology is broadly 

scalable and will eventually achieve mainstream adoption” (Pawczuk, Massey, & Schatsky, 

2018). Consistent with this, a 2019 report by the identity management firm Okta found that 61 

percent of large global companies (over $1 billion in revenue) are investing in some form of 

blockchain technology (Okta | the digital enterprise report, 2019).    

 

Business students can benefit from exposure to blockchain technology. As with many 

emerging technologies, much of the early work in blockchain involves engineers and IT 

departments learning how to build out infrastructure and test theoretical applications in 

alpha and beta environments.  Deloitte reports that 55% of the activities in the blockchain 

space are currently being driven by the R&D and IT functions within the organization; to 

date, only 39% is being driven by business departments (Pawczuk et al., 2018). But as the 

technology becomes more proven and scalable, businesspeople will need to direct its 

application to business problems and opportunity areas within the company. Kris 

Bennett, Chief Learning Officer at Blockchain Training Alliance, notes that “there is a 

tremendous opportunity for developers and engineers but there is even more opportunity 

for non-technical [business] people. The most important person on your team is not the 



BLOCKCHAIN SYSTEMS AND BUSINESS PROCESSES 

  

Copyright Š Institute of Behavioral and Applied Management. All Rights Reserved 99 
 

developer or engineer but the [business] storyteller ( Blockchain training alliance live Q 

& A volume 7, 2019). As blockchain use increases, business students and faculty will 

increasingly be expected to know this technology. The 2020 exposure draft for AACSB 

accreditation policies states that “all AACSB-accredited schools will be expected to have 

processes in place to ensure that both learners and faculty are competent with current and 

emerging technologies” (AACSB, 2018 p.10).  

 

Blockchain technologies are driving changes to key areas of management and business in 

almost every industry vertical. Certain industries may face radical disruption; others will take 

advantage of emerging blockchain technologies to innovate, solve problems, and improve 

efficiencies.  

 

Key use cases that are emerging from proof of concepts and going into production are 

changing the way companies are managed, including how they reconcile records with trading 

partners, track product histories, streamline payments and receivables, and increase the safety of 

food and pharmaceuticals though new methods of provenance. Walmart, for example, is 

requiring all of its suppliers of leafy vegetables to be blockchain-enabled by September 2019, so 

that it can more easily track and trace the products in its chain in the event of an E. coli or 

salmonella outbreak (Hyperledger, 2018). This blockchain solution is expected to reduce, from 

weeks to minutes, the time it takes to identify a lot of bacteria-affected produce, potentially 

saving time, money, and lives. In addition, IBM and the shipping company Maersk have teamed 

to create a blockchain solution called TradeLens. TradeLens streamlines document workflows by 

digitizing and storing them on an immutable ledger where all partners in the supply chain have 

visibility. The TradeLens process improvements reduce paperwork and improve supply chain 

efficiencies. Finally, the banking industry is using blockchain-related process changes to 

generate new efficiencies in many areas. In claims processing and dispute resolution, for 

example, a proof of concept resulted in a decrease in dispute-resolution time from over 40 to 

under 10 days, improving cash flow and profits (Jenkinson, 2018).   

 

These changes in business processes directly affect the way we manage our respective 

business areas and underscore the importance of raising the collective awareness and skill level 

of our business students and professionals before blockchain becomes a wide-scale solution for 

businesses.  Indeed, blockchain-related business skills are essential precursors to blockchain 

solutions, as business will eventually drive the wide-scale adoption of the solutions.    

  

Educational resources 

 

Faculty and students know disruptive changes are coming, and many are interested in 

learning about blockchain. Because the field is so new, blockchain-related educational resources 

have not yet been designed for university courses or with clear learning goals in mind. To date, 

there is a small number of professional articles and cases in reputable outlets, but no textbooks 

and few traditional resources that are suitable for classroom settings. This is not to say there is a 

lack of information on blockchain. Literally thousands of web articles, trade publications, and 



BLOCKCHAIN SYSTEMS AND BUSINESS PROCESSES 

  

Copyright Š Institute of Behavioral and Applied Management. All Rights Reserved 100 
 

videos describe blockchain concepts. However, the quality of these resources varies greatly, and 

it is difficult to know which are accurate and reliable.  

 

Professional services and business consulting firms have written high-quality white 

papers outlining blockchain concepts. Although some are excellent resources, they are often 

directed toward readers who already possess a foundational understanding of core concepts, or 

toward current or potential customers.  

 

The most difficult resources to find are instructional materials for blockchain assignments 

and projects. A handful of blockchain activities and games are described online, but they 

typically explain only low-level technical concepts such as decentralized consensus or hashing 

algorithms— concepts that are more useful to students who are learning the underlying 

architecture than to ones who are approaching blockchains from a business user perspective. 

Likewise, there are online resources for interacting with blockchain software, but most are 

designed for software engineers and not business software users.  

 

Being new and complex, blockchain concepts can be difficult to grasp through reading 

alone. Conceptual descriptions of blockchain technology and business use cases do not always 

give business students a line of sight into how businesses can apply these systems. The case 

described here enables students and faculty to engage blockchain and business software concepts 

through a hands-on, concrete approach. 

 

Business blockchain project 

 

The Smartify case, provided in full in the appendix, begins with a description of 

blockchain fundamentals that is written at a level appropriate for students with no prior 

knowledge of the technology. Some of the technical blockchain concepts, such as cryptography 

and consensus mechanisms, are complicated, but students do not need to master these concepts 

in order to understand what blockchains are and how businesses can use them. Business 

blockchains are essentially accounting ledgers that record transactions such as purchases, 

material transfers, and sales. The primary difference between blockchain and traditional 

enterprise systems is that blockchain systems can be shared by multiple companies, since the 

transactions are validated by all affected parties, secure, and unchangeable once they are 

recorded. This eliminates the need to reconcile different systems when questions arise about 

terms, activities, or payments between parties. These highly accurate shared ledgers allow 

businesses to transfer and track assets in new ways.  

 

1. Transferring assets: blockchain enables unique identification of many assets, 

including ownership documents and cryptocurrency. This enables assets to be transferred directly 

between the parties, significantly reducing the need for intermediaries. 

 

2. Tracking assets: blockchain can track the movement of ownership or an asset 

across multiple parties, such as through a supply chain, and make this movement visible to 

authorized parties. When each party benefits from transparency in this movement, the 

blockchain-enabled visibility reduces friction in the business process. 



BLOCKCHAIN SYSTEMS AND BUSINESS PROCESSES 

  

Copyright Š Institute of Behavioral and Applied Management. All Rights Reserved 101 
 

Because the operation and value of shared ledgers can be difficult to grasp, we believe 

that working through this process step by step will benefit students. 

The Smartify assignment helps students develop an in-depth understanding of how 

business blockchains work. It does so by providing: 

1) A summary of blockchain basics 

2) A discussion of software concepts relevant to business blockchains 

3) A hands-on practice case in which students plan, record, and audit blockchain 

transactions. 

4)  

The assignment’s description of a company and its practices helps students understand 

blockchain concepts in a business context. Using blockchain software in a pencil-and-paper 

format provides students with a concrete understanding of difficult concepts in an unintimidating 

setting.  

 

When introduced through concrete examples, basic blockchain concepts are relatively 

easy for many business students to grasp, especially graduate students or undergraduate students 

who are in the upper division of their business programs or who have work experience. Business 

students tend to have a strong understanding of the concept of a transaction ledger, which, at its 

core, is very similar to a blockchain. They also understand the need for an audit trail—the need 

to track a transaction from an original source document to a database and ultimately to 

accounting reports. As a result, they can appreciate some of the key advantages of the blockchain 

system for business: accuracy, traceability, and security. 

 

The Smartify case was developed by a company known as TrueUp, whose mission is to 

change the learning experience through interactive innovation challenges, technology 

simulations, and professional skill development using modes of gamification to engage learners 

differently. TrueUp developed the original version of the case as one of the exercises in its 

National Blockchain Challenge. Participants found the case to be very helpful in understanding 

how blockchain systems and software work. After completing the exercise, they were able to 

successfully execute transactions in an Oracle blockchain software environment and said the 

Smartify case made blockchain software seem more familiar and easier to grasp. In the final 

segment of the challenge, students were tasked with identifying potential errors and 

inefficiencies within another current business process, such as the sales or purchasing cycle. 

Their work on the Smartify assignment familiarized them with workflows and enabled them to 

understand ways blockchain could address problems and enhance the business cycle. 

 

We have tested different versions of this case in our blockchain and analytics courses and 

have found that it helps students to more clearly picture business blockchains than they could 

from reading alone. Students also appreciated having the opportunity to learn about blockchain 

concepts. Many had heard about the technologies, but most did not understand them or how they 

could be implemented by businesses. 

 

Teaching notes 

 

The Smartify Blockchain assignment is appropriate for use in any undergraduate business 

major or graduate business program. The assignment does not assume that students have any 



BLOCKCHAIN SYSTEMS AND BUSINESS PROCESSES 

  

Copyright Š Institute of Behavioral and Applied Management. All Rights Reserved 102 
 

prior blockchain knowledge and does not require access to a computer or software. Nor does the 

professor guiding the class need prior blockchain knowledge.  

 

Assignment Objectives 

 

The purpose of this project is to introduce students to blockchain concepts through a 

hands-on assignment that exemplifies how a blockchain system is operationalized in a common 

business setting. The objectives of the assignment are to: 

 

• Introduce fundamental blockchain concepts 

• Demonstrate the functioning of blockchain enterprise software 

• Provide an opportunity to practice configuring an enterprise system 

• Provide an opportunity to practice entering and evaluating business transactions 

 

The Smartify assignment begins with a brief description of the fundamental elements of 

blockchain systems, followed by a discussion of how these elements differentiate blockchain 

enterprise software from traditional database-oriented systems. After reading the fundamentals, 

instructors may wish to provide opportunities for discussions of these concepts, either in class or 

online. Blockchain concepts are so deep and varied that no individual professor or blockchain 

practitioner can be an expert in all aspects. The goal here is to help students develop a working 

knowledge of the basic concepts. 

 

We ask students to first read through the case, then have them work on the case together 

during class. The case is also appropriate as an independent homework assignment for in-person 

or online courses. Blockchain concepts can be overwhelming for some students. In our 

experience, even students who have read articles or watched videos on the topic often feel that it 

is too complex to master. The case is designed to help students realize that blockchains are 

similar to any other accounting ledger. After completing the case, they should feel confident in 

their understanding of the basic functioning of a blockchain. 

 

Some instructors may wish to assign discussion questions in addition to the case. There 

are no “correct answers” to these questions. Rather, the questions will reinforce what students 

learned through the case and build on that knowledge through the process of speculation. With 

new blockchain innovations being announced every day, a discussion of the value of blockchain 

systems for businesses can be useful on its own. 

 

Additional materials and discussion questions 

 

The case is designed to be accessible to students with no prior knowledge of blockchain 

technology.  If instructors would like to provide additional resources, many are available online. 

We have found Blockchain for Dummies, 2nd IBM Limited Edition (Gupta, 2018) to be a great 

starting point for a business audience. The first two chapters of the book explain the business 

benefits and basic technical elements of blockchains. Many more resources, for both beginners 

and experts in blockchain, can be accessed through the Crypto Canon web resource page hosted 

by the venture capital firm Andreessen Horowitz. ).  

 



BLOCKCHAIN SYSTEMS AND BUSINESS PROCESSES 

  

Copyright Š Institute of Behavioral and Applied Management. All Rights Reserved 103 
 

Some instructors may wish to assign discussion questions in order to build upon the 

foundational knowledge that students attain through the case study. Once students have a basic 

understanding of how blockchains function, they can benefit further by discussing what they 

have learned from the case and by speculating about the benefits of business blockchains for 

participating organizations. The following questions can be used to guide that discussion. 

 

1) Describe the core elements of blockchain technology and enterprise blockchain 

software. 

The information and definitions are presented at the beginning of the case, and the 

instructor can review them with the students. This can be done before or after students work 

through the case. 

 

2) Does a shared blockchain system replace the existing enterprise systems of 

Smartify or its partners? 

The blockchain supplements existing enterprise systems, but does not replace them. Even 

after a blockchain has been implemented, participants’ enterprise systems will maintain records 

of their own internal transactions and transactions with external parties. A subset of these 

transactions will also be recorded on the blockchain. These are shared transactions, such as those 

depicted in the Smartify case. 

 

3) How does the blockchain system depicted in the flowchart differ from traditional 

inventory management using an enterprise system?  

A traditional enterprise system contains a broad variety of transactions for a single 

enterprise. The system is owned and controlled by that enterprise. In the Smartify case example, 

each of the customers and suppliers would have their own enterprise system and would record 

their own transactions. Companies sometimes allow their trading partners to see information like 

production or delivery schedules, but each company keeps its own record of transactions.  

 

The blockchain system is shared between Smartify and its suppliers and customers. It 

does not replace the existing system but works in conjunction with it. Every node or partner 

keeps a complete record of transactions stored on the blockchain, and all parties can record 

transactions. When a transaction is recorded, it is validated by all participants, and the record is 

secured and unchangeable.  

 

This eliminates many problems that result from erroneous or fraudulent transactions in an 

individual party’s recordkeeping system. It is common for companies to have different records 

about their shared transactions, such as whether a product or payment was received. Because 

both parties validate transactions before they are stored, and because the records cannot be 

changed, many inconsistencies and disputes are avoided.  

 

4) How is privacy maintained using the blockchain software? For example, how 

does Smartify ensure that customers don’t see each other’s orders and terms? 

Participants in shared blockchain systems send information to one another through 

private channels. Only the parties who participate in a channel are allowed to view the 

information sent on it, unless they authorize other parties to view those transactions. 



BLOCKCHAIN SYSTEMS AND BUSINESS PROCESSES 

  

Copyright Š Institute of Behavioral and Applied Management. All Rights Reserved 104 
 

Transactions on business blockchains are typically encrypted, so even though all partners store 

copies of the transactions, only the parties that have permission can read them. 

 

5) What are the advantages of implementing a blockchain software package for 

inventory management? 

a. Traceability—an authorized participant can track the movement of inventory 

throughout the entire inventory management system. As soon as a new transaction has been 

recorded and validated, that transaction will be visible across the network. 

 

b. Dispute resolution—because both the partner transferring the asset and the 

partner receiving it agree upon and validate the transaction before it has been recorded to the 

blockchain, the number of disputes is minimized. Inventory transfer disputes typically arise from 

missing or improperly entered transactions or simple data entry errors, which cause discrepancies 

between the official records of the two parties. With blockchain,  there is one shared copy of the 

transaction, so disputes can be easily resolved. The few errors that are missed by both parties 

during validation cannot be changed but can be resolved through additional transactions. 

 

c. Auditing—because a company’s suppliers and customers have already attested to 

the validity of transactions, these transactions are pre-audited. And because transactions cannot 

be changed once they have been recorded, their validity is also pre-established.  This adds 

confidence to the audit process. 

 

 

6) What are the advantages of using smart contracts/chaincode over traditional 

business documents? 

This question was not addressed in the assignment, but it could be an interesting add-on 

for an instructor-guided discussion or for independent research by students. Because smart 

contracts are programmable, they can contain the types of if/then logic that are associated with a 

large number of traditional business documents and processes. This capability is especially 

powerful when information can be gathered from embedded chips, barcodes, or equipment. For 

example, a shipping notice with detailed tracking information could be instantly available to a 

customer and viewable in a block ledger as soon as a delivery truck leaves the warehouse. 

Because the smart contract and blockchain system are shared by Smartify and its customer, the 

smart contract could trigger actions in the ERP systems of both companies. Likewise, a delivery 

truck could automatically be summoned when a batch of goods leaves a production line or 

arrives on the supplier’s shipping dock. The smart contract could release a payment for goods as 

soon as the goods arrive; chip readers in the manufacturer’s loading dock or records from a bar 

code scanner could trigger the release. This feature will be especially valuable when companies 

are using cryptocurrencies for intercompany transactions. Some companies consider bitcoin and 

similar currencies to be too volatile for day-to-day transactions. However, these companies may 

be more amenable to “stable-coins,” which are backed by US or foreign currency, and to other 

new solutions for reducing risk. 

 

 

 

 



BLOCKCHAIN SYSTEMS AND BUSINESS PROCESSES 

  

Copyright Š Institute of Behavioral and Applied Management. All Rights Reserved 105 
 

Conclusions 

 

Today’s business students will graduate into a world in which blockchain plays an 

increasingly important role in business, government, and civil society.  At a minimum, these 

students need a basic understanding of blockchain concepts, and confidence in their ability to 

learn and use blockchain systems. Because blockchain topics are so new, and because few 

business professionals have expertise in this area, even a small amount of blockchain training is 

valuable. Two students who had no prior knowledge of blockchain participated in the 2-week-

long National Blockchain Challenge, in which a version of this project appeared. Upon 

graduation, these students were hired by an accounting firm into roles that include designing 

blockchain workshops and educating senior managers on blockchain concepts.  

 

The Smartify project presented here explains blockchain fundamentals, describes an 

inventory process in which blockchain software is used, and gives students experience in 

recording and validating blockchain transactions. This practical exercise can fill an important 

knowledge gap and give students the conceptual foundations and confidence to explore 

blockchain and other emerging technologies. 

 

References 

 

AACSB (2019). 2020 Standards for AACSB Business Accreditation, Exposure Draft 2. 

 https://www.aacsb.edu//media/aacsb/docs/accreditation/business/standards-and-

 tables/2020%20aacsb%20business%20accreditation%20standards%20%20exposure%20

 draft%20no%201%20distributefinal.ashx?la=en&hash=E9B979E1F216730D3ABA637A

 A61CDEA29E7BB8CA 

Blockchain Training Alliance (Producer) (2019, Jan 23, 2019). Blockchain training alliance 

  live Q & A volume 7. [Video/DVD] 

 https://www.youtube.com/watch?v=0UZ2WVF6H3g 

Chokshi, S., Dixon, C., Nazarov, D., Walden, J. & Yahya, A. (2019). Crypto Cannon. 

https://a16z.com/2018/02/10/crypto-readings-resources/ 

Gupta, M. (2017). Blockchain for Dummies - IBM. Hoboken New Jersey: John Wiley & Sons, 

 Inc 

Hyperledger (2018). How Walmart brought unprecedented transparency to the food supply chain 

  https://www.hyperledger.org/resources/publications/walmart-case-study 

IBM (2018, August 9). Maersk and IBM Introduce TradeLens Blockchain Shipping Solution. 

 newsroom.ibm.com: https://newsroom.ibm.com/2018-08- 09-Maersk-and-IBM-

 IntroduceTradeLens-Blockchain-Shipping-Solution. 

Jenkinson, G. (Oct. 15, 2018). IBM’s blockchain patents: From food-tracking and  shipping to 

IoT and security solutions. https://cointelegraph.com/news/ibms-blockchain-patents-

from-food-tracking-and-shipping-to-iot-and-security-solutions 

Octa (2019) The digital enterprise report.  https://www.okta.com/resources/whitepaper/the-

 digital-enterprise-report-how-the-worlds-largest-companies-are-evolving-with-

 technology/ 

Pawczuk, M. & Schatsky (2018). Deloitte’s 2018 global blockchain survey. London, United 

Kingdom: Deloitte Consulting LLP. 



BLOCKCHAIN SYSTEMS AND BUSINESS PROCESSES 

  

Copyright Š Institute of Behavioral and Applied Management. All Rights Reserved 106 
 

https://www2.deloitte.com/content/dam/Deloitte/cz/Documents/financial-services/cz-

2018-deloitte-global-blockchain-survey.pdf 

Shirer, M., & Goepfert, J. (2018, Jan 24, 2018). New IDC spending guide sees worldwide 

 blockchain spending growing to $9.7 billion in 2021. 

 https://www.idc.com/getdoc.jsp?containerId=prUS43526618 

 

  



BLOCKCHAIN SYSTEMS AND BUSINESS PROCESSES 

  

Copyright Š Institute of Behavioral and Applied Management. All Rights Reserved 107 
 

Appendix 

 

Business Partners on a Blockchain 

 

Blockchain fundamentals 

 

At its core, blockchain technology is a distributed ledger system that allows two or more 

parties to store shared business transactions on a shared ledger. The well-known Bitcoin 

blockchain records transmission of cryptocurrency on its shared ledger. Businesses use 

blockchains to record all sorts of transactions, which may or may not involve cryptocurrency. 

Transactions stored on a shared ledger can be viewed by anyone who has been granted 

permission. Blockchains have several unique attributes that ensure that transactions are accurate, 

unchangeable, and secure:  

 

• Blocks are groups of transactions, similar to a list of transactions on a Google 

sheet. Each list of transactions, or block, has a link to the block that came before it. Together the 

blocks form a “chain.” 

 

• Each block has an algorithmic hash—a unique code that is calculated based on the 

contents of the block—which can serve as an ID for that transaction. If even one character in the 

block is changed, the calculation will result in a completely different hash.  

 

• There are multiple copies of each block of transactions, and the copies are 

regularly compared by the computers on which they are hosted to make sure they are identical. If 

a copy doesn’t match up with the others, it is immediately apparent that transactions have been 

damaged or tampered with, and the copy is invalidated. This is the feature that makes 

transactions stored on the blockchain immutable. 

 

• The transactions can be private.  On a shared business blockchain, transactions are 

typically stored in encrypted format. Only authorized users with a key or password can view 

them.  

 

Smartify 

 

Smartify is a successful watch manufacturing company that takes standard watches and 

“smartifies” them by adding state-of-the art software and features.   

The Smartify manufacturing process can be described as follows: 

 

 



BLOCKCHAIN SYSTEMS AND BUSINESS PROCESSES 

  

Copyright Š Institute of Behavioral and Applied Management. All Rights Reserved 108 
 

Suppliers supply watch parts to Smartify’s manufacturing division. After the watches are 

assembled, they are transferred through Smartify’s installation, testing, and finishing 

departments. The finished products are then sold to customers. Smartify currently has three 

suppliers and three customers.   

 

Smartify has strong relationships with its suppliers and customers, and the involved 

parties are working together to implement a shared blockchain. The new system will enable the 

parties to mor";"""date"",""2020-07-22T22:02:03Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.7""
""xmp:CreatorTool"",""MicrosoftÂŽ Word for Microsoft 365""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dc:creator"",""user""
""language"",""en""
""dcterms:created"",""2020-07-22T22:02:03Z""
""Last-Modified"",""2020-07-22T22:02:03Z""
""dcterms:modified"",""2020-07-22T22:02:03Z""
""dc:format"",""application/pdf; version=1.7""
""xmpMM:DocumentID"",""uuid:1F98C8CE-0502-4C8B-A4F4-6815C42B1EF4""
""Last-Save-Date"",""2020-07-22T22:02:03Z""
""pdf:docinfo:creator_tool"",""MicrosoftÂŽ Word for Microsoft 365""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2020-07-22T22:02:03Z""
""meta:save-date"",""2020-07-22T22:02:03Z""
""pdf:encrypted"",""false""
""xmp:CreateDate"",""2020-07-22T18:02:03Z""
""modified"",""2020-07-22T22:02:03Z""
""pdf:hasMarkedContent"",""true""
""Content-Type"",""application/pdf""
""xmp:ModifyDate"",""2020-07-22T18:02:03Z""
""pdf:docinfo:creator"",""user""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""user""
""dc:language"",""en-US""
""meta:author"",""user""
""pdf:producer"",""MicrosoftÂŽ Word for Microsoft 365""
""meta:creation-date"",""2020-07-22T22:02:03Z""
""created"",""2020-07-22T22:02:03Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""18""
""Creation-Date"",""2020-07-22T22:02:03Z""
""resourceName"",""14183.pdf""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""2382"",""3529"",""3418"",""3272"",""3312"",""3115"",""3220"",""3246"",""2997"",""455"",""2064"",""2861"",""879"",""621"",""996"",""878"",""532"",""921""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""Author"",""user""
""producer"",""MicrosoftÂŽ Word for Microsoft 365""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""MicrosoftÂŽ Word for Microsoft 365""
""pdf:docinfo:created"",""2020-07-22T22:02:03Z""
";https://scholar.google.ch/scholar?start=810&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098760-93;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;A Construction of Robustly Reusable Fuzzy Extractors over Blockchains;K Sato, K Yasunaga, T Fujiwara ; … International Symposium on …, 2020  ieeexplore.ieee.org;;"… we need to guarantee that input w has enough entropy even if the adversary queries on the

generation algorithm oracle … Ouroboros: A provably secure proof-of-stake blockchain protocol.

In CRYPTO (1), volume 10401 of Lecture Notes in Computer Science, pages 357–388 …";Les 3 versions;;null;;;;https://scholar.google.ch/scholar?start=640&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098813-218;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;[PDF][PDF] Quantum indistinguishability for public key encryption;T Gagliardoni, J Krämer, P Struck ; IACR Cryptol. ePrint Arch, 2020  eprint.iacr.org;;"… (CRYPTO'16) advanced the study of quantum security by giving, for symmetric key en … that any

communication between adversary and challenger is also classical (including oracles provided

by … give a security definition that allows the adversary to query the signing oracle on a …";Cité 1 fois;Les 2 versions;[PDF] iacr.org;https://eprint.iacr.org/2020/266.pdf;"
Quantum Indistinguishability
for Public Key Encryption

Tommaso Gagliardoni1, Juliane Krämer2, and Patrick Struck2

1 Kudelski Security, Switzerland
firstname.lastname@kudelskisecurity.com
2 Technische Universität Darmstadt, Germany
{juliane,patrick}@qpc.tu-darmstadt.de

Abstract. In this work we study the quantum security of public key
encryption schemes (PKE). Boneh and Zhandry (CRYPTO’13) initiated
this research area for PKE and symmetric key encryption (SKE), al-
beit restricted to a classical indistinguishability phase. Gagliardoni et al.
(CRYPTO’16) advanced the study of quantum security by giving, for
SKE, the first definition with a quantum indistinguishability phase. For
PKE, on the other hand, no notion of quantum security with a quantum
indistinguishability phase exists.
Our main result is a novel quantum security notion (qIND-qCPA) for
PKE with a quantum indistinguishability phase, which closes the afore-
mentioned gap. We show a distinguishing attack against code-based
schemes and against LWE-based schemes with certain parameters. We
also show that the canonical hybrid PKE-SKE encryption construction
is secure, even if the underlying PKE scheme by itself is not. Finally,
we classify quantum-resistant PKE schemes based on the applicability
of our security notion and discuss concurrent and independent work.
Our core idea follows the approach of Gagliardoni et al. by using so-called
type-2 operators for encrypting the challenge message. At first glance,
type-2 operators appear unnatural for PKE, as the canonical way of
building them requires both the secret and the public key. However, we
identify a class of PKE schemes - which we call recoverable - and show
that for this class type-2 operators require merely the public key. More-
over, recoverable schemes allow to realise type-2 operators even if they
suffer from decryption failures, which in general thwarts the reversibility
mandated by type-2 operators. Our work reveals that many real-world
quantum-resistant PKE schemes, including most NIST PQC candidates
and the canonical hybrid construction, are indeed recoverable.

1 Introduction

The discovery of Shor’s [43] and Grover’s [27] quantum algorithms had a signif-
icant impact on cryptographic research. Shor’s algorithm in particular has the
potential to completely break most of the public key cryptosystems used nowa-
days. This led to the development of quantum-resistant cryptography,3 that is,

3 This type of cryptography is often called “post-quantum cryptography” [12].



cryptography that can run on non-quantum computers but should withstand
attackers equipped with quantum computing power. In recent years the research
efforts on quantum-resistant cryptography accelerated significantly due to the
standardization process initiated by the NIST [39].

Modern cryptography is based on the paradigm of provable security, which
is itself given in terms of a security notion, an adversarial model, and a security
proof. A widely used framework for defining security notions is the so-called
game-based security, which is presented as a game between two or more parties.4

In the case of encryption schemes these parties are: a challenger, represent-
ing the user of the scheme, and an adversary, representing an attacker against
the scheme. Any meaningful model for quantum-resistant schemes should entail
that the adversary has quantum computing power. Based on this, we can dif-
ferentiate between different models depending on the computing power of the
challenger. In the literature there are mainly two of these models that are taken
into account. In the first, the challenger remains fully classical, implying that
any communication between adversary and challenger is also classical (including
oracles provided by the challenger to the adversary), while the adversary retains
local quantum computing power. This is the model most often considered in
quantum-resistant cryptography, and it is also called QS1 [24] or Q1 [30]. In the
second case, the challenger also has quantum computing power, which enables
quantum communication between challenger and adversary. This stronger model
is sometimes called “superposition-attack security” [22], QS2 [24], or Q2 [30].

Boneh and Zhandry [15] initiated the study of QS2 security for cryptographic
primitives. For signature schemes, they give a security definition that allows
the adversary to query the signing oracle on a superposition of messages. For
public and symmetric key encryption (PKE and SKE) schemes, on the other
hand, they prove that simply allowing the adversary to query a superposition of
messages as challenge in a “natural” way gives an unachievable security notion
(fqIND-CPA). This is due to entanglement between the plaintext register and the
ciphertext register. They show how to exploit this entanglement to break this
security notion irrespectively of the used encryption scheme. To resolve this,
they propose another security notion (IND-qCPA) which allows the adversary
superposition queries in the CPA phase while the challenge messages in the IND
phase are restricted to be classical. This notion coincides with the traditional
QS1 security notion for PKE (as the adversary can simulate the encryption in
superposition using his local computing power and the public key), while for
SKE, this yields a notion of QS2 security - although the restriction to a classical
challenge in this case is clearly a shortcoming.

Gagliardoni et al. [25] overcame this shortcoming in the symmetric key case
by showing how to model a quantum challenge query, while keeping the resulting
security notion (qIND-qCPA) still achievable, yet stronger than IND-qCPA. At
the heart of their idea lies the use of so-called type-2 operators5 rather than so-

4 Other frameworks exist, such as simulation-based, but as a first approximation game-
based security notions are very convenient for their intuitivity and simplicity.

5 Also called minimal oracles in [31].

2



called type-1 operators when encrypting the challenge messages of the adversary.
Type-1 operators are the “canonical” way of implementing a classical function F
on a quantum superposition of input, by mapping the state |x, y〉 to |x, y ⊕F(x)〉,
thereby ensuring reversibility for any function F (reversibility being necessary
when defining non-measurement quantum operations). An important property of
type-1 operators is that they create entanglement between the input and output
registers. This is exactly the entanglement which Boneh and Zhandry exploit
to show that fqIND-CPA is unachievable. In contrast to these, type-2 operators
work directly on the input register, i.e., they map the state |x〉 to |F(x)〉. Only
reversible functions, for instance permutations, can be implemented as type-2
operators, while it is impossible to compute, say, an arbitrary one-way function
through a type-2 operator. Gagliardoni et al. observe that SKE schemes act as
permutations between the plaintext space and the ciphertext space, which allows
to implement the encryption algorithm as a type-2 operator. This, in turn, allows
to build a solid framework for QS2 security in the case of SKE.

In [25] the authors speculate that their techniques could be extended to
the public key case (PKE) as well. However, defining type-2 operators for PKE
schemes is much more involved than for SKE schemes. First, to achieve IND-CPA
security, PKE schemes are inherently randomised and the randomness is usually
erased in the process of decryption. Second, many constructions for quantum-
resistant PKE schemes, in particular lattice-based and code-based schemes, suf-
fer from a small probability of decryption failures, i.e., ciphertexts which do not
decrypt correctly. Given the above, at first glance it is unclear whether type-2
operators for PKE schemes are possible at all, as these two properties seem to
thwart the mandatory reversibility. Hence, QS2 security for the public key case
remained an open problem so far.

1.1 Our Contribution

We present a novel QS2 security notion6 for PKE, provide both achievability
results and separation to the QS1 security notion for many real-world schemes,
and give a general classification of PKE with respect to our security notion.

Our core focus is to extend the results from [25] to the public key scenario. We
first formalize the theory of type-2 encryption operators for PKE. For perfectly
correct schemes (i.e., schemes which do not suffer from the possibility of decryp-
tion failures) we define the type-2 operator to preserve a randomness register
in input and output. Even if such approach might look strange at first glance,
we show that this is the most natural way of defining type-2 operators for PKE
schemes. As a next step, we identify a class of PKE schemes (which we call recov-
erable) where decryption failures can always be avoided given knowledge of the
randomness used during encryption, regardless of the actual failure probability
of the decryption algorithm. We observe that most real-world partially correct
PKE schemes (including many quantum-resistant NIST candidates) are actually
of this type. Then, for schemes that are perfectly correct or recoverable, we show

6 See Appendix C for independent and concurrent work.

3



how to efficiently construct the type-2 encryption operator. Moreover, we show
that for recoverable schemes, this can be done by knowledge of the public key
only! This implies, perhaps surprisingly, that the adversary can implement effi-
ciently this type-2 operator already in the QS1 model. Such observation marks
a substantial difference from the symmetric key case, where the need for type-2
operators is dictated by necessity in order to cover exotic attack models. Thus,
the type-2 operator for these schemes can be realised without the secret key.

Using the theory of type-2 operators developed so far, we give a novel QS2
security notion for PKE, that we call quantum ciphertext indistinguishability
under quantum chosen plaintext attack (qIND-qCPA). For a new security notion
to be meaningful, two properties are required. First, it has to be achievable, and,
second, it has to differ from existing security notions.

We analyse several real-world PKE schemes in respect to our new qIND-qCPA
security notion. We show that the canonical LWE-based PKE scheme [41] can be
attacked, at least for certain parameters. The attack is similar to the “Hadamard
distinguisher” given in [25]. Moving on to code-based schemes, we observe that
some constructions encrypt the message using a one-time pad operation, which
again allows to exploit the distinguishing attack. As an example we show that
the code-based scheme ROLLO-II [10] is not qIND-qCPA secure.

However, in practice most real-world PKE schemes (including the NIST sub-
missions) are used as Key Encapsulation Mechanisms (KEM) in combination
with a SKE scheme, yielding a hybrid PKE-SKE construction. Looking at such
canonical hybrid construction then, we show that its qIND-qCPA security mostly
depends on the underlying SKE scheme, while the PKE scheme only needs to be
secure in the QS1 sense. Hence, even the code-based PKE scheme ROLLO-II,
which as a stand-alone PKE scheme is not qIND-qCPA-secure, can be used to
achieve qIND-qCPA security if combined with a qIND-qCPA-secure SKE scheme
via the hybrid construction, which is the default way of using it in practice.

Finally, we discuss the difficulty of defining type-2 operators (and the related
QS2 security notion) for arbitrary schemes that are neither perfectly correct nor
recoverable. We study the problem of their general classification and we identify
a class of schemes, that we call isometric, that allow to overcome such difficulty,
and we provide constructions and separation results.

1.2 The Motivation for QS2 Security

Defining security against quantum adversaries with superposition access to cer-
tain oracles requires some motivation. Sometimes, the resulting security notion
is already implicitly captured by the corresponding QS1 scenario (for example
in the case of quantum random oracles [13]). In other cases, for instance those
considered in [7, 29,33], it might look like an artificial extension of the theory.

However, QS2 security extends quantum properties to types of attack scenar-
ios not covered in QS1, and at the same time “bridges” certain security notions
from the classical realm to schemes which are meant to run natively on a quan-
tum computer. Some of the reasons why QS2 notions are important to consider
are explained in detail in [24]. They basically boil down to five points.

4



1. To ensure that quantum-resistant classical schemes retain their security even
if executed on a quantum computer, possibly in complex environments or
protocols where composition should be taken into account.

2. To fix security proofs, where the sole QS1 security of certain underlying
building blocks is not enough to ensure that the whole proof goes through.
An example is the need of QS2-secure pseudorandom functions (QPRF) in
order to simulate a quantum random oracle [46], which is a QS1 concept.

3. To ensure the security of quantum protocols (i.e., meant to run natively
on a quantum computer and protect quantum data) when using classical
algorithms as building blocks. For example, [24] shows how it is possible to
build a secure symmetric quantum encryption scheme (falling into the so-
called QS3 domain) by using a qIND-qCPA symmetric classical encryption
scheme (QS2), but not necessarily a simple quantum-resistant (QS1) one.

4. To consider cases of code obfuscation; for example creating a quantum-
resistant PKE scheme by hardcoding a symmetric key into an obfuscated
encryption program (a technique known as whiteboxing [20]), which is then
distributed as a public key.

5. To cover cases of exotic quantum attacks. These include, for instance, quan-
tum fault injection attacks, where a classical device is subject to controlled
and artificial physical conditions that induce full or partial quantum be-
haviour of its hardware (“tricking” a classical device into being quantum,
like in the “frozen smart-card attack” presented in [25]); or cases where a
quantum computer is used to run a classical algorithm, but an adversary
manages to intercept the intermediate result of the computation before the
final measurement meant to produce a classical outcome.

In our specific case, our results follow from the core use of type-2 operators. This
kind of quantum operations is poorly studied in the quantum computing realm,
and might therefore look artificial for cryptographic use. In the present work
we make an effort to expand in a detailed way the formalization of such opera-
tors which, we stress, are only given for functions that are inherently invertible.
It is a well-known fact (see for example [25]) that implementing these opera-
tors for encryption schemes usually requires knowledge of the secret key. We do
not consider this to be a limitation because in the quantum setting, an honest
challenger equipped with the secret key could be allowed to generate particu-
lar ciphertext-encoding states which would be hard to compute for an external
party: it is therefore necessary to cover this distinction in the preparation of
ciphertext states, and type-2 operators do just that. Moreover, as we show in
the present work, for many natural PKE schemes, type-2 encryption operators
can actually be efficiently implemented by knowledge of the public key only.

1.3 Related Work

The study of quantum security under adversarial queries in superposition can be
traced back to works such as [13, 22, 45], which explore different settings where
this additional adversarial power has an impact on security. However, for the

5



case of signatures and encryption schemes, the first framework going beyond the
traditional QS1 paradigm was given in [15]. This paradigm was further extended
in [25] for symmetric key encryption schemes, and in [6] for MACs/signatures.

Regarding examples of exotic quantum attacks previously mentioned: it is
currently not known whether any of these are feasible at all, but as noted in [24]:
(1) if they are feasible, in some cases they do not even require a fully fledged quan-
tum computer (for example, in the attack from [25] it would be only necessary
to produce and detect a Hadamard superposition of messages); and (2) it is al-
ready known in the literature that these attacks can be devastating. For example,
related-key attacks [42], and superposition attacks against Even-Mansour [33],
Feistel networks [28,32], block ciphers [7, 9], and HMAC constructions [29].

Qualitatively different, but technically very connected to the QS2 setting is
the fully quantum setting, or QS3 in short. This security domain encompasses se-
curity notions and constructions for schemes which are natively run on quantum
hardware. In the case of QS3 encryption, these are schemes which are meant to
protect quantum, rather than classical data. It turns out that many of the chal-
lenges in this area are shared with the QS2 case. In the computational security
setting, the first security notions have been provided in [17] for the CPA case,
and in [3] for the CCA1 and semantic security case. These results have been
further extended to the CCA2 setting in [5] for the symmetric case, and in [4]
for the public key case.

In concurrent and independent work, Chevalier et al. [19] propose alternative
QS2 security notions for encryption schemes. Their and our notion are incom-
parable, as also claimed in a recent work by Carstens et al. [18]. We discuss the
differences in more detail in Appendix C.

1.4 Organization of the Paper

Section 2 gives the required background for this work. In Section 3 we study
type-2 operators for PKE schemes, define recoverable schemes, and give our new
quantum security notion for those. Positive and negative results for real-world
PKE schemes are presented in Section 4. Finally, we refine the classification of
PKE schemes in terms of QS2 security in Section 5 and conclude with open
questions in Section 6.

2 Preliminaries

In the following, we use “classical” as meaning “non-quantum”. By algorithm or
procedure (classical or quantum) we mean a uniform family of circuits (classical
or quantum) of depth and width polynomial in the index of the family. We call
such index a security parameter, and we denote it by Îť (or 1Îť if written in unary
notation). We implicitly assume that all algorithms take 1Îť as a first input, so
we will often omit this. If a classical algorithm A is deterministic, we denote its
output y on input x as y := A(x), while if it is randomized we use y ← A(x); when
derandomizing an algorithm we look at the deterministic algorithm obtained

6



when considering explicitly the internal randomness r as an additional auxiliary
input, and we write y := A(x; r). We will also use x ← D to denote that an
element x is sampled from a distribution D; or we will write x $←−X if x is sampled
uniformly at random from a set X. We will call negligible a function that grows
more slowly than any inverse polynomial, and overwhelming a function which is
1 minus a negligible function. Finally, a‖b denotes concatenation of a and b.

2.1 Quantum Notation

We assume familiarity with the topic of quantum computing, but recall here the
basic required notation. For an in-depth discussion we refer to [38].

A quantum system, identified by a letter A, is represented by a complex
Hilbert space, which we denote by HA. If A is clear from the context, we write
H rather than HA. Pure states in a Hilbert space H are representatives of equiv-
alence classes of elements of H of norm 1. Mixed states, on the other hand, are
a more general representation of quantum states that takes entanglement with
external systems into account; they are elements of the density matrix opera-
tor space over H, that is, Hermitian positive semi-definite linear operators of
trace 1, denoted as D(H). We use the ket notation for pure states, e.g., |ϕ〉,
while mixed states will be denoted by lowercase Greek letter, e.g., ρ. Opera-
tions on pure states from A to B are performed by applying a unitary operator
U : HA → HB to the state, while the more general case of operations on mixed
states is described by superoperators of the form U : D(HA)→ D(HB)

The canonical way to compute a classical function F : X → Y on a super-
position of possible inputs

∑
x∈X αx |x〉 is through the so-called type-1 operator

for F described by:

U
(1)
F :

∑
x,y

αx,y |x, y〉 7→
∑
x,y

αx,y |x, y ⊕F(x)〉 ,

This can always be implemented efficiently whenever F is efficient [38]. By lin-
earity, it is sufficient to specify just the behaviour on the basis elements, i.e.:

U
(1)
F : |x, y〉 7→ |x, y ⊕F(x)〉 .

If F is invertible, then there is another non-equivalent possible way to compute
F in superposition. This is done through the so-called type-2 operators, which
are defined as the unitary:

U
(2)
F : |x〉 7→ |F(x)〉 .

See Fig. 1 for an illustration of these different operators. Kashefi et al. [31] first
introduced type-2 operators using the term minimal oracles instead. They show
that these operators are strictly stronger by giving a problem which can be
solved exponentially faster with type-2 operators than with type-1 operators.
They also observe that the adjoint of the type-2 operator corresponds to the
type-2 operator of the inverse function F−1, which is (usually) not the case for
type-1 operators. Besides that, type-2 operators have been used by Gagliardoni
et al. [25] to define quantum security for secret key encryption schemes.

7



U
(1)
F U

(2)
F

|x〉

|y〉

|x〉

|y ⊕F(x)〉
|x〉 |F(x)〉

Fig. 1: Type-1 operator (left) and type-2 operator (right) for a function F .

2.2 Public Key Encryption

In this section we give the formal definition for public key encryption schemes
and the correctness of such schemes.

Definition 1 A public key encryption (PKE) scheme is a tuple (KGen, Enc, Dec)
of three efficient algorithms such that:

– KGen : N×R → P×S is the key generation algorithm which takes a security
parameter Îť and a randomness r as input, and returns a keypair consisting
of a public key pk and a secret key sk. If clear from the context, we will
denote it by (pk, sk)← KGen.

– Enc : P ×M×R → C is the encryption algorithm which takes a public key
pk, a message m, and a randomness r as input, and returns a ciphertext c.
It will be usually denoted by c ← Encpk(m) or c := Encpk(m; r).

– Dec : S × C → M is the (deterministic) decryption algorithm7 which takes
as input a secret key sk and a ciphertext c, and returns a message m. It will
be usually denoted by m := Decsk(c).

By P, S,M, C, and R, we denote the public key space, secret key space, message
space, ciphertext space, and randomness space, respectively.

We assume w.l.o.g. that the randomness space for key generation and encryption
are identical. Below we define two notions of correctness for PKE schemes.

Definition 2 (Perfectly Correct PKE) A PKE scheme ÎŁ = (KGen, Enc, Dec)
is perfectly correct if for any (pk, sk)← KGen, m ∈M, and r ∈ R, it holds that

Decsk(Encpk(m; r)) = m .

Definition 3 ((1− α)-Correct PKE [23]) A (1−α)-correct PKE scheme, or
PKE with decryption error Îą, is a PKE scheme ÎŁ = (KGen, Enc, Dec) such that,
for any m ∈M:

Pr
(pk,sk)←KGen

r←R

[Decsk(Encpk(m; r)) 6= m] ≤ α .

7 For simplicity here we only consider decryption with implicit rejection, that is, such
the output is a random value whenever the input is not a well-formed ciphertext
for the particular sk. The extension to explicit rejection decryption can be done for
example by adding a flag bit that marks the output as ⊥ whenever decryption fails.

8



3 Quantum Indistinguishability for PKE Schemes

In this section we extend the QS2 security notion of qIND-qCPA introduced for
SKE schemes in [25] to the public key case. This is much more complex than
the symmetric case, for the following reasons:

1. PKE schemes are randomized to achieve cipertext indistinguishability;
2. when derandomizing the encryption procedure and considering the random-

ness as additional input, there might be collisions (different randomnesses
leading to the same ciphertext), hence ensuring reversibility of type-2 oper-
ators is not straightforward;

3. many existing schemes, such as lattice- or code-based NIST candidates, suffer
from a small decryption failure probability.

In particular, as we will see, there are two main consequences: (1) the inverse of
type-2 encryption operators is not generally a type-2 decryption operator; and
(2), most interestingly, many type-2 encryption operators can be built efficiently
by using only knowledge of the public key. The last point is crucial: it shows that
in the PKE case, type-2 encryption operators are much more natural than in the
SKE case, and for certain schemes they are actually covered in the usual notion
of QS1 “post-quantum” security already. We will also show that some of these
schemes are very relevant, such as the LWE-based scheme used as a blueprint
for many NIST submissions. In this section we will do the following:

1. First, we revisit and define formally type-1 operators for PKE, and we show
the difference between type-1 encryption and decryption (cf. Section 3.1).

2. We define type-2 encryption operators for perfectly correct PKE schemes,
and we show that they can be efficiently implemented with knowledge of
secret and public key (cf. Section 3.2).

3. We define what we call recoverable PKE schemes, i.e., schemes that admit
an efficient procedure to recover the message given randomness, ciphertext
and public key, without the secret key. We show that for such schemes the
‘canonical’ type-2 encryption operator can be built by only using the public
key, even if the scheme is not perfectly correct (cf. Section 3.3).

4. We define the qIND-qCPA security notion for any PKE scheme where one
can efficiently build the type-2 encryption operator. This includes in partic-
ular perfectly correct and recoverable schemes (cf. Section 3.4).

5. Finally, we discuss how to extend these results to the chosen ciphertext attack
(CCA) scenario (cf. Section 3.5).

3.1 Type-1 Operators for PKE

Recall that, for an arbitrary function f : X → Y, the corresponding type-1
operator is the “canonical” way of computing f on a superposition of input
through the unitary operator Uf : HX ⊗HY → HX ⊗HY defined by: Uf : |x, y〉 7→
|x, y ⊕ f(x)〉. Realising Uf is always efficient if f is efficiently computable.

9



Traditionally, when looking at (deterministic) encryption schemes, the type-1
operator for encryption has been defined as:

UEnc : |m, y〉 7→ |m, y ⊕ Enc(m)〉 .

This is the approach used in, e.g., [15] and [25]. However, in our case of PKE
schemes (which are generally randomized), we have to consider that encryp-
tion can be performed locally by the quantum adversary, who therefore has full
control not only on the randomness used for encryption (i.e., it is necessary to
explicitly derandomize the encryption procedure8), but also on the public key
used (i.e., it is theoretically possible to compute encryption for a superposi-
tion of different public keys). Therefore, the most general definition of a type-1
encryption operator would look like:

UEnc : |pk, r ,m, y〉 7→ |pk, r ,m, y ⊕ Encpk(m; r)〉 .

We argue that this is the most general and correct way to model the local com-
putational power of a quantum adversary, even in the QS1 case. However, for
ease of exposition (and also because it would go beyond the traditional mean-
ing of ciphertext indistinguishability), in the present work we do not consider
superpositions of public keys, as we assume that the public key to be attacked
is given to the adversary at the beginning of the security game. This leads us to
the following definition.

Definition 4 (Type-1 Encryption for PKE) Let ÎŁ = (KGen, Enc, Dec) be a
PKE scheme and let (pk, sk)← KGen. The type-1 encryption operator for pk is
the unitary defined by:

U
(1)
Encpk

: |r ,m, y〉 7→ |r ,m, y ⊕ Encpk(m; r)〉 .

Usually the public key is clear from the context, so we will omit that dependency

and just write U
(1)
Enc. As usual, when there is no ambiguity, we identify the corre-

sponding superoperator acting on mixed states rather than pure states with the

same symbol U
(1)
Enc : D(HR ⊗ HM ⊗ HC) → D(HR ⊗ HM ⊗ HC). By letting the

randomness be an input, Definition 4 allows to encrypt using a superposition
of randomnesses, which is fine in the case of the adversary generating cipher-
texts himself. Note also that the case of different randomnesses for each message
in superposition can be realised by using a single classical randomness and a
QS2-secure pseudorandom function [46], as shown by Boneh and Zhandry [15].

The type-1 decryption operator is defined analogously to Definition 4, but
with an important difference: the decryption algorithm does not take the ran-
domness used for encryption as input.

Definition 5 (Type-1 Decryption for PKE) Let ÎŁ = (KGen, Enc, Dec) be a
PKE scheme and let (pk, sk) ← KGen. The type-1 decryption operator for sk is
the unitary defined by:

U
(1)
Decsk

: |c, z〉 7→ |c, z ⊕ Decsk(c)〉 .
8 This is implicitly considered in [15] and [25], but not explicitly formalized.

10



As usual we denote it by U
(1)
Dec, leaving the secret key understood, and when there

is no ambiguity with the same symbol we denote the superoperator acting on

mixed states also by U
(1)
Dec : D(HC ⊗ HM)→ D(HC ⊗ HM).

Notice the difference in type-1 encryption and decryption acting on different
spaces: this is not surprising, as it is already known that the adjoint of a type-1
encryption operator is not, generally, a type-1 decryption operator. Notice also
how both operators are efficiently computable, because Enc and Dec are efficient

algorithms. The difference is that realising U
(1)
Dec requires knowledge of the secret

key sk, while for realising U
(1)
Enc it is sufficient to know the public key pk.

3.2 Type-2 Encryption for PKE

When defining type-2 encryption for PKE schemes, we have to remember that
defining these operators only makes sense for functions which are reversible. If a
PKE scheme is perfectly correct, then encryption is always reversible if seen as
a function of the plaintext, but not necessarily as a function of the randomness.
That is because it might be the case that for a given message different random-
nesses lead to the same ciphertext. In the context of security games, message
and randomness have very different roles anyway, as one is generally chosen by
the adversary, while the other is generally chosen by the challenger.

Ultimately, what we want is to define a type of unitary which generalizes
the case of arbitrary permutations from plaintext to ciphertext spaces (the same
approach as considered in [25]). In order to avoid the issue raised by random-
ness collisions, we will keep the auxiliary randomness register both in input and
output of the circuit. This ensures reversibility of the operator, because given a
certain ciphertext and a certain randomness, there is only one possible plaintext
which was mapped to that ciphertext (otherwise we would have a decryption
failure, and for now we are only considering perfectly correct schemes). So, if
the sizes of the plaintext space and the ciphertext space coincide, i.e., there is
no ciphertext expansion and thus dim(HM) = dim(HC), then we can define the
corresponding type-2 encryption operator as:

U
(2)
Enc : |r ,m〉 7→ |r , Encpk(m; r)〉 ,

where, as usual, the public key pk is implicit in the definition of U
(2)
Enc, i.e., it is

a parameter of the unitary operator in question.

In the more general case of message expansion, i.e., dim(HM) < dim(HC),
we use the same approach as in [25]: we introduce an auxiliary register in a
complementary space HC−M

9 that ensures reversibility of the operation, and

9 We denote by HC−M a Hilbert space such that HM ⊗ HC−M is isomorphic to HC.
Notice that the opposite case, i.e., dim(HM) > dim(HC), cannot happen because it
would lead to collisions on the ciphertexts and thus introduce decryption failures.
Also notice that, as in [25], the case of adversarially-controlled ancilla qubits is left
as an open problem.

11



which is initialized to |0 . . . 0〉 during an honest execution to yield a correct
encryption. So we consider a family of unitary superoperators of the form:

U : D(HR ⊗ HM ⊗ HC−M)→ D(HR â";"""date"",""2021-02-23T11:26:53Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2021-02-23T11:26:53Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is MiKTeX-pdfTeX 2.9.7338 (1.40.21)""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2021-02-23T11:26:53Z""
""created"",""2021-02-23T11:26:53Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2021-02-23T11:26:53Z""
""resourceName"",""266.pdf""
""Author"",""""
""producer"",""MiKTeX pdfTeX-1.40.21""
""pdf:docinfo:producer"",""MiKTeX pdfTeX-1.40.21""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""4"",""0"",""0"",""0"",""15"",""7"",""3"",""12"",""3"",""12"",""16"",""5"",""6"",""2"",""15"",""0"",""10"",""26"",""11"",""24"",""2"",""15"",""7"",""5"",""5"",""2"",""0"",""10"",""0"",""0"",""0"",""0"",""10"",""10"",""18"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2021-02-23T11:26:53Z""
""Last-Modified"",""2021-02-23T11:26:53Z""
""dcterms:modified"",""2021-02-23T11:26:53Z""
""title"",""""
""Last-Save-Date"",""2021-02-23T11:26:53Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2021-02-23T11:26:53Z""
""meta:save-date"",""2021-02-23T11:26:53Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is MiKTeX-pdfTeX 2.9.7338 (1.40.21)""
""Content-Length"",""679790""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""39""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""2161"",""2912"",""2750"",""2798"",""2636"",""2485"",""2326"",""1668"",""2325"",""2234"",""2447"",""2228"",""1693"",""2194"",""2181"",""2410"",""2183"",""2348"",""1782"",""1820"",""1396"",""1991"",""1901"",""2195"",""2158"",""2261"",""2511"",""2558"",""1458"",""1745"",""2501"",""2925"",""3065"",""2663"",""1411"",""2107"",""1965"",""2547"",""2214""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2021-02-23T11:26:53Z""
";https://scholar.google.ch/scholar?start=760&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098831-252;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Protect Your Smart Contract Against Unfair Payment;Y Li, H Liu, Z Yang, B Wang, Q Ren… ; 2020 International …, 2020  ieeexplore.ieee.org;;"… While ether is the cryptocurrency on Ethereum, token is often implemented as a specific storage …

E). Particularly, the detection aims at checking satisfiability of the FVE oracle as defined … by the

engine to update contract storage or communicate with other contracts on blockchain …";Autres articles;;null;;;;https://scholar.google.ch/scholar?start=800&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098831-251;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;On the design of conditional privacy preserving batch verification-based authentication scheme for Internet of vehicles deployment;AK Sutrala, P Bagga, AK Das, N Kumar… ; IEEE Transactions …, 2020  ieeexplore.ieee.org;;"… scheme is shown to be highly secure against a passive/active adversary through various security

analysis, such as random oracle based formal … CNPq) via under Grant 309335/2017-5, and in

part by the Ripple Centre of Excellence Scheme, CoE in Blockchain (Sanction No …";Cité 10 fois;Les 2 versions;null;;;;https://scholar.google.ch/scholar?start=800&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098787-152;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;A BLS Signature Scheme from Multilinear Maps;F Tang, D Huang ; International Journal of Network Security, 2020  airitilibrary.com;;"… The BLS scheme has shown to be very useful to construct other crypto- graphic primitives, such

as threshold … However, it is well known that random oracle is an ideal model … This leads us to a

question: Can we instan- tiate the BLS signature scheme without random oracles …";Autres articles;;[PDF] asia.edu.tw;http://isrc.ccs.asia.edu.tw/~vdoi/upload/JID190002/2020/1816-3548-2020-00015.pdf;"
International Journal of Network Security, First Online Apr. 6, 2020 (VDOI: 1816-3548-2020-00015) 1

A BLS Signature Scheme from Multilinear Maps

Fei Tang1 and Dong Huang2,3

(Corresponding author: Fei Tang)

School of Cyber Security and Information Law, Chongqing University of Posts and Telecommunications1

Chongqing, China

Chongqing University of Science and Technology 2

Chongqing Vocational and Technical University of Mechatronics3

(Email: tangfei@cqupt.edu.cn)

(Received Mar. 12, 2019; Revised and Accepted Dec. 10, 2019; First Online Apr. 6, 2020)

Abstract

The security of the BLS signature scheme is based on the
random oracle model. Hence, there is a question that
how to instantiate BLS scheme without random oracles.
In this work, by using a powerful tool multilinear map,
we answer this question. The main contributions of this
work are as follows. First of all, we describe the BLS
scheme in the setting of multilinear group and prove its
security in the standard model. Then, we design a ring
signature scheme based on the multilinear BLS scheme.
In the proposed scheme, ring signatures consist of a single
multilinear group element.

Keywords: BLS Signatures; Multilinear Map; Ring Sig-
natures; Standard Model

1 Introduction

Digital signatures are one of the most fundamental and
well studied cryptographic primitives. The research of
digital signatures has two aspects: practicability and se-
curity. As for the aspect of practicability, we mainly con-
sider the efficiencies of the signing and verification algo-
rithms, the storage space of the state information, and
the properties that the scheme can provide, such as ag-
gregate signatures [17], ring signatures [23], blind signa-
tures [16,19,20] and so on. As for the aspect of the secu-
rity, we mainly focus on the assumptions that the scheme
based on, such as one-way function, and whether in the
random oracle model or standard model.

At ASIACRYPT 2001, Boneh, Lynn, and Shacham [6]
designed a short signature scheme based on bilinear
group, the so called BLS scheme. The BLS scheme
has shown to be very useful to construct other crypto-
graphic primitives, such as threshold signature scheme [7],
blind signature scheme [7], signcryption scheme [10], key-
generation algorithm of identity-based encryption (IBE)
scheme [4]. The main reason of the BLS scheme is so
useful is that it has a relatively simple structure. The

security of the BLS scheme is rely on the random ora-
cle model. However, it is well known that random oracle
is an ideal model. After BLS scheme, there has several
works that presented some signature schemes which se-
cure in the standard model, such as [3]. However, all of
these schemes do not preserve the BLS scheme’s simple
structure. This leads us to a question: Can we instan-
tiate the BLS signature scheme without random oracles?
In this work, by using a powerful tool multilinear map,
we answer this question.

The notion of multilinear maps was introduced (but
without concrete instantiation) by Boneh and Silver-
berg [8]. Until 2013, Garg, Gentry, and Helevi [12]
gave the first approximate candidate. Then there has
many multilinear map schemes been proposed or ana-
lyzed, e.g., [9, 15,21] et al.

There are several relevant works answered the above
question. Hohenberger et al. [18] instantiated the ran-
dom oracle with an actual family of hash functions for
the BLS scheme by using a more powerful tool indis-
tinguishability obfuscation [13]. Freire et al. [11] took
advantage of multilinear maps to realize programmable
hash functions and construct IBE, BLS signature, and
SOK non-interactive key exchange schemes. In addi-
tion, Hohenberger et al. [17] made use of the multilinear
BLS scheme to construct an (identity-based) aggregate
signature scheme which admits unrestricted aggregation.
In [17], Hohenberger et al. followed in the Waters [25]
framework and proved the adaptive security of the mul-
tilinear BLS signature scheme.1 However, their proof is
based on a strong new assumption, (n, k)-modified mul-
tilinear computational Diffie-Hellman exponent where n
is a polynomial of the number of queries made by the
adversary.

In this work, we also give an adaptive proof for the
multilinear BLS scheme. However, our proof which takes
advantage of the technique of admissible hash function [2]
is based on a weaker assumption, multilinear computa-

1Their adaptive proof of the aggregate signature scheme implies
this result. (Please refer to Appendix D.2 of [17] for details.)



International Journal of Network Security, First Online Apr. 6, 2020 (VDOI: 1816-3548-2020-00015) 2

tional Diffie-Hellman assumption [12]. In addition, we
consider the applications of the multilinear BLS signature
scheme. It can be served as the key-generation algorithm
of the multilinear IBE scheme [11]. It also can be used
to construct aggregate signature [17], threshold signature
scheme [7] and so on. In this work, we take advantage of
the structure of the multilinear BLS scheme to construct
a ring signature scheme in the standard model. In a ring
signature scheme [23], a signer can generate signatures on
behalf of a group of users (i.e., ring) if and only if he is a
member of the ring. Then, any verifier can confirm that
the message has been signed by one of the members in
the ring, but he cannot know who is the real signer. Our
ring signature scheme has an attractive feature that for n
members of a ring the signatures consist of just a single
group element.

2 Preliminaries

2.1 Notations

The following notations will be used in this paper. Let Z
be the set of integers and Zp be the ring modulo p. 1Îť

denotes the string of Ν ones for Ν ∈ N. |x| denotes the
length of the bit string x. [k] is a shorthand for the set
{1, 2, . . . , k}. Finally, we write PPT for the probabilistic
polynomial time.

2.2 Multilinear Maps

Let (G1, . . . ,Gk) be a sequence of groups each of large
prime order p, and gi be a generator of group Gi, where
we let g = g1. There exists a set of bilinear maps {ei,j :
Gi ×Gj → Gi+j |i, j ≥ 1 ∧ i+ j ≤ k}, which satisfy:

ei,j(g
a
i , g

b
j) = gabi+j : ∀a, b ∈ Zp.

When the context is obvious, we omit the indexes i
and j, i.e., e(gai , g

b
j) = gabi+j . It also will be conve-

nient to abbreviate e(h1, h2, . . . , hj) = e(h1, e(h2, . . .,
e(hj−1, hj) . . .)) ∈ Gi for hj ∈ Gij and i1+i2+. . .+ij ≤ k.

Let MulGen(1Îť, k) be a PPT multilinear group genera-
tor algorithm which takes as input a security parameter Îť
and an integer k, where k is the number of allowed pair-
ing operations, then it outputs the multilinear parameters
MP = (G1, . . ., Gk, p, g = g1, g2, . . . , gk, ei,j) to satisfy the
above properties.

In recent years, there has many multilinear maps been
proposed, e.g., [9,12,14,22]. However, some of them have
been shown to be insecure, e.g., [15, 21]. Fortunately,
there still has several multilinear maps are beyond the
existing cryptanalysis, e.g., [1,14]. Therefore, we also can
use this tool to design cryptographic schemes. For exam-
ple, [26,28,29] take advantage of the multilinear maps to
design different cryptographic schemes.

2.3 Complexity Assumption

We assume that the following assumption holds in the set-
ting described above: Multilinear Computational Diffie-
Hellman (MCDH) assumption.

Definition 1. For any PPT algorithm B, any polynomial
p(¡), any integer k, and all sufficiently large Ν ∈ N,

Pr

 MP← MulGen(1λ, k);

c1, . . . , ck
R← Zp; : v = g

∏
i∈[k] ci

k−1

v ← B(MP, gc1 , . . . , gck)

 < 1

p(Îť)
.

This assumption can be viewed as an adaptation of the
Bilinear Computational Diffie-Hellman (BCDH) assump-
tion [4] in the setting of multilinear groups.

3 Digital Signatures

3.1 Definitions

For ease of description, we define digital signature
schemes with four algorithms: Setup, KeyGen, Sign, and
Vrfy. Formally, given a security parameter Îť, the PPT
algorithm Setup, run by a trusted authority, generates
public parameters PP. The public parameters will be
used in all of the following three algorithms, for simplicity,
we omit this fact. The PPT algorithm KeyGen outputs
a signing/verification key pair (SK, V K) for the signer.
The PPT algorithm Sign takes as input a signing key SK
and a message M , then outputs a signature σ. Finally,
the deterministic algorithm Vrfy processes a purported
signature σ with respect to a message M and verification
key V K, accordingly, it outputs 1 to indicate a successful
verification and 0 otherwise.

3.2 Existential Unforgeability

The security model for signature schemes is Existential
Unforgeability against adaptive Chosen-Message Attacks
(EU-CMA) which is defined by the following game.

1) Setup: Challenger runs Setup and KeyGen algo-
rithms to generate the public parameters and chal-
lenge keys (SK∗, V K∗). Adversary A is given the
public parameters and V K∗.

2) Signing queries: Adversary A is allowed to adap-
tively queries the signing oracle at most q times on
messages M1, . . . ,Mq. In its i-th query, it receives
back a signature σi ← Sign(SK∗,Mi).

3) Output: Finally, adversary A outputs a tuple of
(M∗, σ∗), where M∗ 6= Mi for all i ∈ [q]. A wins the
game if Vrfy(V K∗,M∗, σ∗) = 1.

We denote the success probability of a PPT adversary
A (taken over the random choices of the challenger and
adversary) to win the game as Adveu−cmaA .



International Journal of Network Security, First Online Apr. 6, 2020 (VDOI: 1816-3548-2020-00015) 3

Definition 2. We say that a signature scheme is EU-
CMA secure, if for any PPT adversary A, it cannot win
the above game with non-negligible advantage.

Selective security. The model of selective security is a
weaker notion of the model of EU-CMA. In such
model, we require that the adversary gives its chal-
lenge message M∗ before the setup phase, then it
cannot make signing query for M∗.

Definition 3. We say that a signature scheme is selec-
tively secure, if for any PPT adversary, it cannot win the
selective game with non-negligible advantage.

4 Multilinear BLS Scheme

In this section, we describe the multilinear BLS signature
scheme and its security.

4.1 Construction

We specify the message space M := {0, 1}`, more gener-
ally, a collision resistant hash function can be used to hash
messages to this size. The construction of the multilinear
BLS signature scheme is as follows:

• Setup(1λ, `): Trusted authority takes as input a secu-
rity parameter Îť and the length ` of messages to runs
this algorithm to generate the public parameters.
It first runs MP = (G1, . . . ,Gk, p, g, . . . , gk, e) ←
MulGen(1Îť, k = `+1). Next, it chooses 2` random in-
tegers (a1,0, a1,1), . . . , (a`,0, a`,1) ∈ Z2

p and computes
Ai,β = gai,β ∈ G1, for i ∈ [`] and β ∈ {0, 1}. The
public parameters PP contain the group descriptions
MP and (A1,0, A1,1), . . . , (A`,0, A`,1).

• KeyGen(PP): Each user chooses a random element
x ∈ Zp as his signing key SK. The corresponding
verification key is V K = gx ∈ G1.

• Sign(SK,M): Given a message, M , of length `, let
m1, . . . ,m` be the bits of this message, the signer
computes the signature as:

σ = e(A1,m1
, . . . , A`,m`)

x = (g
∏`
i=1 ai,mi

k−1 )x ∈ Gk−1.
2

• Vrfy(V K,M, σ): Given a verification key V K and
a purported signature σ on message M , verify the
following equation:

e(σ, g)
?
= e(A1,m1

, . . . , A`,m` , V K).

2In the bilinear BLS signature scheme [6], signer computes a
signature as σ = H(M)x, where H(¡) is a collision-resistant hash
function that will be treated as a random oracle in the proof.
In the multilinear BLS signature scheme, H(M) is defined as
e(A1,m1 , . . . , A`,m` ) which can be computed from the public pa-
rameters of the (leveled) multilinear maps.

Correctness. To see the correctness, a signature σ

on message M is (g
∏`
i=1 ai,mi

k−1 )x, and thus we have

e(σ, g) = e((g
∏`
i=1 ai,mi

k−1 )x, g) = e((g
∏`
i=1 ai,mi

k−1 ), gx) =
e(A1,m1

, . . ., A`,m` , V K).

4.2 Security of Multilinear BLS Scheme
in the Standard Model

We now prove the security of the multilinear BLS scheme
in the standard model based on the MCDH assumption.
Our proof needs an admissible hash function h which can
be used to partition the message space to two subsets
with probability 1/θ(q) (where q is the upper bound of
the adversary’s queries) so that: the adversary’s query
messages Mi fall in one subset where we know a trap-
door that allows us to answer its queries, and the adver-
sary’s challenge message M∗ falls in the other set where
we do not know any trapdoor but hope to embed a chal-
lenge element. We show that we can leverage the struc-
ture of the multilinear BLS signature scheme to prove
adaptive security. For simplicity of exposition, we as-
sume that there is a polynomial s(Îť) which denotes the
length of messages space to be signed. We use a function
h : {0, 1}s(λ) → {0, 1}`(λ) maps the messages to ` bits,
and an efficient randomized algorithm Sample that is θ-
admissible. The following definition of admissible hash
functions is from [17] which is a slight variant of the sim-
plified definition in [11].

Definition 4. Let s, ` and θ be efficiently computable
univariate polynomials. We say that a function h :
{0, 1}s(λ) → {0, 1}`(λ), and an efficient randomized algo-
rithm Sample, are θ-admissible if the following properties
hold:

• For any u ∈ {0, 1,⊥}`, define Pu : {0, 1}s → {0, 1} as
follows: Pu(X) = 0 iff ∀i : h(X)i 6= ui, and otherwise
(if ∃i : h(X)i = ui) we have Pu(X) = 1.

• We require that for any efficiently computable poly-
nomial q(Ν), for all X1, . . ., Xq, Z ∈ {0, 1}s, where
Z 6∈ {Xi}, we have Pr[Pu(X1) = . . . = Pu(Xq) =
1 ∧ Pu(Z) = 0] ≥ 1/θ(q), where the probability is
taken only over u← Sample(1λ, q).

Theorem 1. For any efficiently computable polynomials
s, `, there exists an efficiently computable polynomial θ
such that there exists θ-admissible function families map-
ping s bits to ` bits.

The construction is identical to the multilinear BLS
scheme with the exception of the Setup algorithm cre-
ates the admissible hash functions. Then the signing and
verification algorithms take as input h(M) instead of M .

Theorem 2. If h is a θ-admissible function and the k-
MCDH problem is hard in the multilinear groups, then
the multilinear BLS signature scheme with an admissible
hash is adaptively secure.



International Journal of Network Security, First Online Apr. 6, 2020 (VDOI: 1816-3548-2020-00015) 4

Proof. If there exists a PPT adversary A who can break
the security of the multilinear BLS signature scheme with
an admissible hash in the EU-CMA game with advantage
Îľ for message length s, level k of the multilinear maps,
and security parameter Îť, then we can construct a PPT
challenger B to break the k-MCDH assumption with prob-
ability ε′ ≥ ε/θ(q). The challenger B takes as input a
k-MCDH instance (gc1 , . . . , gck) together with the group
descriptions MP to interactive with the adversary. The

challenger’s goal is to compute g
∏
i∈[k] ci

k−1 .

We describe the proof as a sequence of hybrid games
where the first hybrid corresponds to the original EU-
CMA game. Then in the first hybrid step we do a “par-
titioning” of the space of the messages. After the first
proof step, we prove that any PPT adversary’s advan-
tage must be close with negligible gap at most between
each successive hybrid games. We finally show that any
PPT adversary in the final game that succeeds with non-
negligible advantage can be used to break the k-MCDH
assumption.

• Game0 is the original EU-CMA game.

1) Setup: Challenger B runs MulGen(1Îť, k) to
produce group parameter MP. It then chooses
a random exponent x ∈ Zp for the secret
key and sets the challenge verification key
as V K∗ = gx. It also randomly chooses
(a1,0, a1,1), . . . , (a`,0, a`,1) from Zp and com-
putes Ai,β = gai,β for i ∈ [`], β ∈ {0, 1}. Finally,
it sets PP = (MP, {Ai,β |i ∈ [`], β ∈ {0, 1}}) and
gives PP and V K∗ to the adversary A.

2) Signing queries: Adversary A adaptively
queries the signing oracle at most q times on
messages M1, . . . ,Mq. In its i-th query, it re-
ceives back e(A1,mi1

, . . . , A`,mi` )
x from chal-

lenger B.

3) Output: At some point A outputs a forgery
σ∗ with respect to the challenge key V K∗ and
message M∗, it wins the game if Vrfy(V K∗,M∗,
σ∗) = 1 and M∗ 6= Mi for i ∈ [q].

• Game1 is the same as Game0 except that the chal-
lenger begins by sampling a string u ∈ {0, 1,⊥}` by
revoking u← Sample(1λ, q). At the end of the game,
the adversary is only considered to be successful if
both its output satisfies the winning conditions and
for the challenge message M∗ we have Pu(M∗) = 0
and for all messages Mi queried Pu(Mi) = 1.

• Game2 is the same as Game1 except that the follow-
ing modification. The challenger sets the parameters
(A1,0, A1,1), . . . , (A`,0, A`,1) in the following way: for
i ∈ [`] and β ∈ {0, 1} it chooses random bi,β ∈ Zp
and sets

Ai,β =

{
gbi,β , if β = ui
(gci)bi,β , if β 6= ui.

Lemma 1. Assume an adversary that makes at most a
polynomial of signing queries q = q(Îť) in Game0. If the
advantage of an adversary in Game0 is Îľ, then the advan-
tage of the adversary in Game1 will be at least ξ/θ(q). In
particular, any PPT adversary with non-negligible advan-
tage in Game0 will also have non-negligible advantage in
Game1.

Proof. The lemma follows immediately from the property
of function h satisfies the definition of a θ-admissibility,
since the only independent choice of u ← Sample(1λ, q)
determines whether or not the game aborts.

Lemma 2. The advantage of any PPT adversary in
Game2 is the same as its advantage in Game1.

Proof. The two games are equivalent as all Ai,β ∈ G1 are
still set to uniformly at random in both games.

Lemma 3. If the k-MCDH assumption holds, then the
advantage of any PPT adversary in Game2 is negligible.

Proof. We prove this lemma by giving a reduction to the
k-MCDH assumption. To do so, we construct an algo-
rithm B.
B takes as input a k-MCDH problem instance

(MP, gc1 , . . . , gck). Next, B runs u ← Sample(1λ, q). It
sets the challenge key as V K∗ = gck . All these steps
together simulate the Setup phase of the Game2. Now,
it plays the game with the adversary A by using pub-
lic parameters PP = (MP, {Ai,β |i ∈ [`], β ∈ {0, 1}}) and
challenge key V K∗.

The adversary A will then adaptively make
at most q signing queries each for message Mi.
If Pu(Mi) = 0, B aborts and quits. Other-
wise, Pu(Mi) = 1 and there exists an Îł we have
h(Mi)Îł = uÎł . Thus, B can compute the signature as
σ = e(A1,h(Mi)1 , . . . , Aγ−1,h(Mi)γ−1

, AÎł+1,h(Mi)Îł+1
, . . .,

A`,h(Mi)` , V K
∗)bγ,h(Mi)γ by knowing the exponent

bÎł,h(Mi)Îł of the parameter AÎł,h(Mi)Îł .
Finally, the adversary A outputs an attempted forgery

σ∗ with respect to the challenge verification V K∗ on
some message M∗. B first checks the signature ver-
ification Vrfy(V K∗,M∗, σ∗) and aborts if it returns 0.
Next, it checks if Pu(M∗) = 1 and aborts if that is the
case. Otherwise, Pu(M∗) = 0 and for all i we have
h(M∗)i 6= ui. This means that the hash of M∗ will

be g
∏
i∈[k−1] ci

k−1 raised to some known product of bi,β val-

ues. The signature therefore contains g
∏
i∈[k] ci

k−1 raised to
some known product of bi,β values. This value can be re-
covered by taking the proper root of the signature, i.e.,

(σ∗)1/
∏
i∈[`] bi,h(M∗)i = g

∏
i∈[k] ci

k−1 , and thus if σ∗ is a suc-
cessful forgery, then this root of the signature is a solution
to the challenge instance of the k-MCDH problem.

By construction of the algorithm B, the probability of
B succeeds is exactly the advantage that the adversary A
succeeds in Game2. Whenever B aborted, the adversary
by the rules of Game2 was not considered to be successful



International Journal of Network Security, First Online Apr. 6, 2020 (VDOI: 1816-3548-2020-00015) 5

since its queries or forgery violated the partition. The
lemma follows.

These three lemmas together yield the main theorem
that the multilinear BLS signature scheme with an ad-
missible hash is adaptively secure.

5 Ring Signatures from Multilin-
ear BLS Scheme

In this section, we show the applications of the multilin-
ear BLS signatures. It can be served as the key-generation
algorithm of the multilinear IBE scheme [11], it also can
be used to construct aggregate signature [17]. In addi-
tion, based on Boldyreva’s [7] work, we can easily obtain
a threshold signature, a multi-signature, and a blind sig-
nature scheme, respectively, based on the multilinear BLS
scheme in the standard model. Here, we take advantage
of the multilinear BLS scheme to construct a ring signa-
ture scheme in the standard model. The resultant scheme
has an attractive feature that for n members of a ring our
signatures consist of just a single group element.

5.1 Definition of Ring Signatures

For convenience, we define an algorithm Setup, run by
trusted authority, to generate public parameters and build
the system of the ring signature scheme. The public pa-
rameters will be used in all of the following three algo-
rithms. In addition, we refer to an ordered set R =
{V K1, . . . , V Kn} of verification keys as a ring, and let
R[i] = V Ki. We will also freely use set notation, e.g.,
V K ∈ R if there exists an index i such that R[i] = V K.

Definition 5. A ring signature scheme contains the fol-
lowing four algorithms:

• Setup(1λ) → PP: The system setup algorithm takes
as input a security parameter Îť to produce the sys-
tem public parameters PP.

• KeyGen() → (SK, V K): The key generation algo-
rithm generates users’ signing and verification keys
(SK, V K).

• Sign(SKs, R,M) → σ: The signing algorithm takes
as input a message M to be signed, a set of verifica-
tion keys R (i.e., the ring), and an user’s signing key
SKs. It is required that V Ks ∈ R meanings that the
signer is a member of the signing ring. The algorithm
outputs a signature σ.

• Vrfy(R,M, σ) → 0/1: The verification algorithm
takes as input a purported signature σ on a ring R
and a message M . It outputs 1 if σ is valid. Other-
wise, it outputs 0.

5.2 Security Models of Ring Signatures

Security models of the ring signature scheme contains two
parts: unforgeability and anonymity.

5.2.1 Ring Unforgeability

This security guarantees that an adversary can compute
a valid signature on behalf of a ring only if he knows a
secret key corresponding to one of them. In this work, we
use Bender et al.’s [5] model: unforgeability with respect
to insider corruption3 which is defined by the following
game:

1) Setup: The challenger runs Setup and KeyGen al-
gorithms to generate public parameters and users’

keys {(SKi, V Ki)}n(Îť)
i=1 . Then it gives the adver-

sary A the system parameters and verification keys

S = {V Ki}n(Îť)
i=1 . In addition, the challenger main-

tains a set C to record the corrupted users, initially,
C ← ∅.

2) Signing queries: The adversary A can adaptively
make singing queries on inputs (M,R, s), where M
is the message to be signed, R ⊆ S is a ring of veri-
fication keys and s is an index such that V Ks ∈ R.
The challenger returns back a ring signature σ ←
Sign(SKs, R,M) to A.

3) Corruption queries: The adversary A also can
adaptively make some corruption queries on input
s ∈ [n(Ν)]. The challenger returns back SKs to A
and adds V Ks into the set C.

4) Output: Finally, the adversary A outputs a tuple
of (M∗, σ∗, R∗). We say that A wins the game if the
following conditions hold: (1) Vrfy(R∗,M∗, σ∗) = 1;
(2) R∗ ⊆ S\C; (3) it never made a singing query
(M∗, R∗, s) for any s.

We denote the success probability of a PPT adversary
A (taken over the random choices of the challenger and

adversary) to win the above game as AdvUnfA .

Definition 6. We say that a ring signature scheme has
the property of unforgeability with respect to insider cor-
ruption, if for any PPT adversary A, it cannot win the
above game with non-negligible advantage.

Selective security. We define a weaker notion, selective
security, to the above model. In the game of selec-
tive security, the adversary A is required that to give
a forgery ring/message pair (R∗,M∗)4 to the chal-
lenger before the setup phase, then it cannot make

3We make use of a weaker notion of this security model in which
corruptions of honest users are allowed but adversary-chosen public
keys are not allowed. This weaker notion has been used in [24,27].

4In the beginning, A does not given the keys S = {V Ki}
n(Îť)
i=1 .

In order to obtain the forgery ring R∗, we require that A out-
puts a set of index IR∗ = {i1, . . . , i|R∗|} ⊆ [n(λ)]. Then, after

the keys S = {V Ki}
n(Îť)
i=1 be generated, the forgery ring R∗ =

{V Ki1 , . . . , V Ki|R∗|} ⊆ S also be defined.



International Journal of Network Security, First Online Apr. 6, 2020 (VDOI: 1816-3548-2020-00015) 6

signing query on inputs (M∗, R∗, s) for any s, it also
cannot make corruption query on input s for which
V Ks ∈ R∗.

Definition 7. We say that a ring signature scheme is
selectively unforgeable with respect to insider corruption,
if for any PPT adversary A, it cannot win the selective
game with non-negligible advantage.

5.2.2 Ring Anonymity

This security guarantees that any verifier can be con-
vinced that someone in the ring has generated a valid ring
signature, but the real signer remains unknown. In this
paper, we make use of the notion of perfect anonymity.
We say that a ring signature scheme is perfectly anony-
mous, if a signature on a message M∗ under a ring R∗

and key V Ki0 looks exactly the same as a signature on
the same message M∗ under the same ring R∗ and a dif-
ferent key V Ki1 . This means that the signer’s key is hid-
den among all the honestly generated keys in the ring.
Formally, it is defined by the following game:

1) Setup: The challenger runs Setup and KeyGen algo-
rithms to generate public parameters and users’ keys

{(SKi, V Ki)}n(Îť)
i=1 . Then it returns back the public

parameters and all keys {(SKi, V Ki)}n(Îť)
i=1 to the ad-

versary A.

2) Challenge: The adversary A gives a tuple of
(M∗, R∗, i0, i1), where M∗ is the challenge message,
R∗ is the challenge ring, i0 and i1 are two indices
such that {V Ki0 , V Ki1} ⊆ R∗, to the challenger.
The challenger chooses random b ∈ {0, 1}, computes
σ∗ ← Sign(M∗, SKib , R

∗), and sends σ∗ to the ad-
versary.

3) Guess: Finally, the adversary outputs b′, indicating
his guess for b.

We denote the advantage of an unbounded adversary A
(taken over the random choices of the challenger and the
adversary) to win the above game as AdvAnoA = |Pr[b′ =
b]− Pr[b′ 6= b]|.

Definition 8. A ring signature scheme has the property
of perfect anonymity, if even an unbounded adversary can-
not win the above game with non-negligible advantage.

5.3 Construction

We now construct a ring signature scheme based on the
multilinear BLS scheme. We specify the message space
M := {0, 1}`, more generally, a collision resistant hash
function can be used to hash messages to this size. Let
m1, . . . ,m` be the bits of the message M ∈ M. The
following construction is an n-user ring signature scheme,
means that |R| = n.

• Setup(1λ, n, `): Trusted authority takes as input
a security parameter Îť, the length ` of messages
and ring size n to runs this algorithm to gen-
erate public parameters. It first runs MP =
(G1, . . . ,Gk, p, g, . . . , gk, ei,j) ← MulGen(1λ, k = n +
`). Next, it chooses 2` random values (a1,0, a1,1), . . .,
(a`,0, a`,1) ∈ Z2

p and computes Ai,β = gai,β ∈ G1, for
i ∈ [`] and β ∈ {0, 1}. The public parameters PP con-
tain the group descriptions MP and group elements
(A1,0, A1,1), . . . , (A`,0, A`,1).

• KeyGen(PP): Each user i chooses a random value
xi ∈ Zp as his signing key SKi. The corresponding
verification key is V Ki = gxi ∈ G1.

• Sign(M,SKs, R = {V K1, . . . , V Kn}): Given a ring
of n verification keys, the holder of signing key SKs

with s ∈ [n] can sign some message M ∈ M as σ =
e(A1,m1

, . . . , A`,m` , V K1, . . . , V Ks−1, V Ks+1, . . .,
V Kn)xs . The signature consists of just a single group

element. In fact, σ = g
(
∏`
i=1 ai,mi )¡(

∏n
j=1 xj)

k−1 ∈ Gk−1.

• Vrfy(M,σ,R = {V K1, . . . , V Kn}): Given a ring of n
verification keys and a purported signature σ on a

message M , check the following equation: e(σ, g)
?
=

e(A1,m1
, . . . , A`,m` , V K1, . . . , V Kn).

Correctness. To see the correctness, a signature σ on

message M and ring R is g
(
∏`
i=1 ai,mi )¡(

∏n
j=1 xj)

k−1 , and

thus we have e(σ, g) = e(g
(
∏`
i=1 ai,mi )¡(

∏n
j=1 xj)

k−1 , g) =

e(g
∏`
i=1 ai,mi

k−1 , g
∏n
j=1 xj ) =

e(A1,m1
, . . . , A`,m` , V K1, . . . , V Kn).

In the setting of the multilinear maps, the space to repre-
sent a group element might grow with k (which is n+ `),
because this happens in the GGH [12] framework. To mit-
igate this problem, we can use the method in [17], which
differs the message alphabet size in a tradeoff between
computation and storage. The above construction uses a
binary message alphabet. If it uses an alphabet of 2d sym-
bols, then the ring signature could resident in the group
G`/d+n with `/d+ n− 1 pairings required to compute it,

at the cost of the public parameters requiring 2d ¡ ` group
elements in G1.

5.4 Security

Theorem 3. The ring signature scheme with message
length ` and ring size n in the above is selectively unforge-
able with respect to insider corruption under the (n+ `)-
MCDH assumption.

Proof. If there exists a PPT adversary A who can break
the selective security of the ring signature scheme with ad-
vantage Îľ for message length `, ring size n, level k = n+ `
of multilinear maps, and security parameter Îť, then we
show that we can construct a PPT challenger B to break
the k-MCDH assumption for security parameter Îť with



International Journal of Network Security, First Online Apr. 6, 2020 (VDOI: 1816-3548-2020-00015) 7

probability ε. Initially, A gives (M∗ ∈ {0, 1}`, IR∗ =
{i1, . . . , in} ⊆ [n(λ)]) to B who is given an instance,
(MP, gc1 , . . . , gck), of the k-MCDH assumption.

1) Setup: The challenger B first sets signing and
verification keys for the challenge ring (SKi1 =
c`+1, V Ki1 = gc`+1), . . . , (SKin = ck, V Kin = gck)
(it does not know these ci). For indices i 6∈ IR∗ , it
chooses random xi ∈ Zp and sets SKi = xi, V Ki =
gxi . It then generates parameters as follows:

• Choose random integers a1, . . . , a` ∈ Zp.
• For i ∈ [`], set Ai,m∗i = gci and compute
Ai,m̄∗i = gai .

Note that these parameters are distributed uniformly
at random as in the real ring signature scheme. Then
B sets the public parameters PP = (MP, {Ai,β |i ∈
[`], β ∈ {0, 1}}). Finally, it gives PP and {V Ki}n(Ν)

i=1

to A.

2) Signing queries: Conceptually, the challenger B
can generate signatures for the adversary, because
the adversary’s requests and the challenge ring or
message will be different in at least one bit. Specifi-
cally, when A makes a query to the signing oracle on
input (M,R = {V K1, . . . , V Kn}, s). If R 6= R∗, we
assume that V Kj ∈ R but 6∈ R∗, then B ignores the
index s and signs M with SKj in the usual way since
B knows V Kj ’s singing key xj . If R = R∗, then we
know M 6= M∗ and assume that mγ 6= m∗γ , where mγ

and m∗γ are the γ-th bit of the message M and M∗,
respectively. Hence B can compute σ = e(A1,m1 , . . .,
Aγ−1,mγ−1

, AÎł+1,mÎł+1
, . . . , A`,m` , V K1, . . . , V Kn)aÎł

by knowing the exponent aγ of the parameter Aγ,m̄∗γ .
Finally, it returns σ to the adversary A.

3) Corruption queries: When Amakes a query to the
corruption oracle with input an index i for i 6∈ IR∗ ,
B gives SKi to A and adds V Ki to the set C of the
corrupted users.

4) Output: Finally, A outputs a forgery σ∗ with re-
spect to the challenge ring R∗ = {V Ki1 , . . . , V Kin}
and message M∗. Then B outputs σ∗ as the so-
lution to the given instance of the k-MCDH as-
sumption. According to the setting of the public
parameters and the verification keys of the chal-
lenge ring in the setup phase, and the assumption
that σ∗ is valid, we know that σ∗ should be equal
to e(A1,m∗1

, . . . , A`,m∗` , V K1, . . . , V Kj−1, V Kj+1, . . .,

V Kn)c`+j = g
∏
i∈[1,k] ci

k−1 , where c`+j is a certain sign-
ing key A ";"""date"",""2020-04-06T13:33:23Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""2"",""37"",""29"",""0"",""42"",""29"",""0""
""pdf:PDFVersion"",""1.5""
""xmp:CreatorTool"",""TeX""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dcterms:created"",""2020-04-06T13:33:23Z""
""language"",""en""
""Last-Modified"",""2020-04-06T13:33:23Z""
""dcterms:modified"",""2020-04-06T13:33:23Z""
""dc:format"",""application/pdf; version=1.5""
""Last-Save-Date"",""2020-04-06T13:33:23Z""
""pdf:docinfo:creator_tool"",""TeX""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2020-04-06T13:33:23Z""
""meta:save-date"",""2020-04-06T13:33:23Z""
""pdf:encrypted"",""false""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is MiKTeX-pdfTeX 2.9.6668 (1.40.19)""
""modified"",""2020-04-06T13:33:23Z""
""Content-Length"",""366145""
""pdf:hasMarkedContent"",""false""
""Content-Type"",""application/pdf""
""PTEX.Fullbanner"",""This is MiKTeX-pdfTeX 2.9.6668 (1.40.19)""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""trapped"",""False""
""meta:creation-date"",""2020-04-06T13:33:23Z""
""created"",""2020-04-06T13:33:23Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""8""
""Creation-Date"",""2020-04-06T13:33:23Z""
""resourceName"",""1816-3548-2020-00015.pdf""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""3783"",""3889"",""3962"",""4281"",""3999"",""3973"",""4080"",""4595""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""producer"",""MiKTeX pdfTeX-1.40.19""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""MiKTeX pdfTeX-1.40.19""
""pdf:docinfo:created"",""2020-04-06T13:33:23Z""
";https://scholar.google.ch/scholar?start=700&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098875-360;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Blockchain Enables Your Bill Safer;Q Wang, L Huang, S Chen… ; IEEE Internet of Things …, 2020  ieeexplore.ieee.org;;"… The crypto scheme is build on top of underlying blockchain systems by replacing the origi- nal

plaintext of bills with encrypted ones in their amount fields. Thus, the transparent values on bills

are hidden without exposure to the governments or public verifies …";Autres articles;;null;;;;https://scholar.google.ch/scholar?start=900&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098804-195;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;[PDF][PDF] Creating a Better Future with Ethical AI: Key Challenges and Solutions;V Chen ; academia.edu;;"… 2019]. Cahana, A. (2019). To Keep AI Ethical We Need To Use Blockchain. [online] Medium.

Available at: https://medium.com/crypto-oracle/to-keep-ai-ethical-we-need-to-

use-blockchain-aaf2733626cd [Accessed Mar. 2019]. Page 8. Chopra, D. (2018) …";Autres articles;Version HTML;[PDF] academia.edu;https://www.academia.edu/download/62284823/Academia_Creating_a_Better_Future_with_Ethical_AI.pdf;;;https://scholar.google.ch/scholar?start=740&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098839-278;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Libra und Blockchain–Potenziale für den Mittelstand;B Holste, I Horn ; Wirtschaftsinformatik & Management, 2020  Springer;;"… Neben Start-ups haben auch klassische Softwareanbieter (z. B. IBM, SAP, Oracle)

den Zukunftstrend erkannt und bieten unter dem Namen Blockchain-as-a-Service

(BaaS) cloudbasierte Blockchain-Lösungen an. Unternehmen …";Autres articles;;null;;;;https://scholar.google.ch/scholar?start=820&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098765-106;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;[PDF][PDF] SGAxe: How SGX fails in practice;S van Schaik, A Kwong, D Genkin, Y Yarom ;2020 sgaxe.com;;"… enclaves as genuine. Finally, we analyze the impact of our attack on two proposed

SGX applications, the Signal communication app and Town Crier, an SGX-based

blockchain application. I. INTRODUCTION Trusted Execution …";Cité 10 fois;Les 3 versions;[PDF] sgaxe.com;https://sgaxe.com/files/SGAxe.pdf;"
SGAxe: How SGX Fails in Practice
Stephan van Schaik

University of Michigan
stephvs@umich.edu

Andrew Kwong
University of Michigan
ankwong@umich.edu

Daniel Genkin
University of Michigan

genkin@umich.edu

Yuval Yarom
University of Adelaide and Data61

yval@cs.adelaide.edu.au

Abstract—Intel’s Software Guard Extensions (SGX) promises
an isolated execution environment, protected from all software
running on the machine. A significant limitation of SGX is its
lack of protection against side-channel attacks. In particular,
recent works have shown that transient-execution attacks can
leak arbitrary data from SGX, breaching SGX’s confidentiality.
However, less work has been done on the implications of such
attacks on the SGX ecosystems.

In this work we start from CacheOut, a recent confidentiality
attack on SGX, which allows the retrieval of an enclave’s
memory contents. We show how CacheOut can be leveraged
to compromise the confidentiality and the integrity of a victim
enclave’s long-term storage. By using the extended attack against
the Intel-provided and signed architectural SGX enclaves, we
retrieve the secret attestation key used for cryptographically
proving the genuinity of enclaves over the network, allowing us
to pass fake enclaves as genuine. Finally, we analyze the impact
of our attack on two proposed SGX applications, the Signal
communication app and Town Crier, an SGX-based blockchain
application.

I. INTRODUCTION

Trusted Execution Environments (TEEs) are architectural
extensions, recently introduced in commodity processors,
which collectively provide strong security guarantees to soft-
ware running in the presence of powerful adversaries. TEEs’
promise to allow secure execution on adversary-controlled
machines has spawned many new applications [57, 76, 84,
98, 100], both in academia [7, 8, 11, 18, 24, 27, 38, 78, 98]
and industry [1, 2, 4, 22, 25, 39, 60, 63, 80]. Whereas several
TEEs have been proposed (e.g., ARM’s TrustZone [6, 70, 75]
or AMD’s Secure Encrypted Virtualization [53]), the currently
prevailing x86 TEE implementation is Intel’s Software Guard
eXtensions (SGX) [20].

To support private and secure code execution, SGX provides
isolated execution environments, called enclaves, which offer
confidentiality and integrity guarantees to programs running
inside them. While SGX’s security properties strongly rely
on the processor’s hardware implementation, SGX removes
all other system components (such as the memory hardware,
the firmware, and the operating system) from the Trusted
Computing Base (TCB). In particular, SGX ensures that the
processor and memory states of an enclave are only accessible
to the code running inside it and that they remain out of reach
to all other enclaves and software, running at any privilege
level, including a potentially malicious operating system (OS),
and/or the hypervisor. At a high level, SGX achieves these
strong security guarantees by encrypting enclave memory
and protecting it with a secure authentication code, making

the associated cryptographic keys inaccessible to software.
Finally, SGX provides a remote attestation mechanism, which
allows enclaves to prove to remote parties that they have been
correctly initialized on a genuine (hence, presumed secure)
Intel processor.

Notwithstanding its strong security guarantees, SGX does
not protect against microarchitectural side channel attacks.
As acknowledged by Intel, “SGX does not defend against
this adversary” [46, Page 115] arguing that “preventing side
channel attacks is a matter for the enclave developer” [45].
Starting with the controlled channel attack [94], numerous
works have demonstrated side channel attacks on or from
SGX enclaves [10, 21, 23, 32, 67, 91, 92]. Foreshadow [85]
and following transient-execution attacks [17, 56, 79, 86, 87],
demonstrated the capability of recovering contents from within
the enclave’s memory space.

Recognizing the danger, Intel released several patches, CPU
microcode updates, and even new architectures designed to
mitigate SGX side channel leakage via transient execution.
However, the fix for TSX Asynchronous Abort (TAA) [44, 88],
released in November 2019, was shown to be insufficient [79,
89, 90]. In particular, the CacheOut attack demonstrated the
capability to leak SGX data by first evicting the data from the
cache and then using TAA to recover it.

While CacheOut shows the ability to steal data from
enclaves, it stops short of investigating the implications of
this leak on the security of the SGX ecosystem. Given the
increasing adoption of SGX as an alternative to heavyweight
cryptographic protocols [2, 18, 31, 63, 98], there is clear
danger in deploying SGX-based protocols on current Intel
machines. With several SGX-based works aiming to offer
some security guarantees even in the presence of information
leakage, in this paper we ask the following questions:

What are the implications of information leakage from en-
claves on the security of the SGX ecosystem? In particular, can
SGX-based protocols maintain their strong security guarantees
in the presence of side channel attacks?

A. Our Contributions

In this work we show that the security of the SGX ecosys-
tem completely collapses, even in the presence of all currently-
published countermeasures. Specifically, we test CacheOut on
a fully updated machine, including a dedicated GPU to avoid
Intel’s Security Advisory SA-00219 [47], the latest SGX SDK
and Intel-signed enclaves for mitigating LVI [86], and all
of the countermeasures and microcode updates required to

stephvs@umich.edu
ankwong@umich.edu
genkin@umich.edu
yval@cs.adelaide.edu.au


mitigate TAA [44, 79, 88], PlunderVolt [69], Zombieload [79],
RIDL [87] and Foreshadow [85]. We show that despite activat-
ing all countermeasures, CacheOut [90] can effectively dump
the contents of SGX enclaves.

Moreover, we show that CacheOut does not need to execute
code within the enclave to dump its contents. Instead, it
works while the enclave is completely idle. Thus, the attack
bypasses all software-based SGX side-channel defenses, such
as constant-time coding and countermeasures that rely on
enclave code for ensuring protection [16, 26, 71, 77, 81].
Breaking the Integrity of Sealed Data. Next, going beyond
attacks on SGX’s confidentiality properties, in this work we
extend CacheOut to also breach SGX enclaves’ integrity.
Specifically, we target the SGX sealing mechanism [5], which
provides long-term storage of data, by securely generating
an encryption key used to seal data by encrypting it before
forwarding it to the operating system for long-term storage.

We use CacheOut to extract the sealing key from a victim
enclave. The main challenge is that the SGX SDK imple-
mentation of the sealing API [40] wipes out the sealing key
immediately after using it, leaving a short window in which
the key can be retrieved. After recovering the sealing key, we
use it to unseal and read the sealed information, then modify
and reseal it. As SGX provides no integrity mechanism to
detect such a change, the victim enclave now operates on data
corrupted by the attacker.
Breaking Remote Attestation Next, we turn our attention to
SGX’s remote attestation protocol, which allows an enclave to
prove to a remote party that it has been initialized correctly and
is executing on a genuine (presumably secure) Intel processor.
To attack attestation, we first use our attack on SGX’s sealing
mechanism and retrieve the sealing key of the SGX Quoting
Enclave. Notably, unlike previous works [79, 86, 90] which
build and sign their own quoting enclave, we attack a genuine,
Intel-signed, production enclave, which employs all of Intel’s
countermeasures for transient-execution attacks, including the
recent hardening for the LVI attack [86].

We then use the retrieved sealing key to unseal the persistent
storage of the Quoting Enclave, which contains the private
attestation key. We note that this attestation key is the only
differentiating factor between a fully secure SGX enclave
running on genuine Intel hardware and a malicious SGX
simulator offering no security guarantees. Thus, we can build
a malicious SGX simulator that passes Intel’s entire remote
attestation process. Performing remote attestation with the
provider’s server is usually the first task of any enclave
running on the user’s machine, resulting in a secure connec-
tion between the user’s enclave and provider’s servers. With
the machine’s production attestation keys compromised, any
secrets provided by server are immediately readable by the
client’s untrusted host application, while all outputs allegedly
produced by enclaves running on the client cannot be trusted
for correctness. This effectively renders SGX-based DRM
applications [35] useless, as any provisioned secret can be
trivially recovered. Finally, our ability to read enclave contest
and fully pass remote attestation also erodes trust in SGX-

based secure remote computation protocols such as [1, 2, 7,
8, 11, 18, 22, 24, 27, 38, 39, 76, 78, 80, 98] as users cannot
trust that their data will be properly protected by a genuine
SGX enclave.
Exploiting SGX’s Privacy Guarantees. Finally, we note
that Intel’s Extended Privacy ID (EPID) [52] severely com-
pounds the consequences of compromised attestation keys.
More specifically, when running in anonymous mode, EPID
signatures are unlinkable, meaning that an attestation output
cannot be linked to identity of the machine producing it [52].
This means that obtaining even a single EPID private key
allows us to forge signatures for the entire EPID group,
which contains millions of SGX-capable Intel CPUs. Thus,
the leak of even a single key from a single compromised
machine jeopardizes the trustworthiness of large parts of the
SGX ecosystem. Luckily however, the unlinkable attestation
mode is not recommended by default [52], allowing remote
stakeholders to recognize our attestation quotes as coming
from a different platform.
Undermining SGX-Based Protocols. To demonstrate the
concrete implications of our breach of SGX, we conduct case
studies examining how actual protocols, in both academic
software and commercial products, may fail in practice when
they rely upon SGX. We explore the Signal App [3] and Town
Crier [98], which was acquired by ChainLink, a cryptocur-
rency with a $1.5B market cap. We explore nuanced effects
that breaching the integrity and confidentiality of SGX has
on reliant protocols. This discussion is vital for securing the
future of SGX-reliant protocols and designing such protocols
to be resilient even when the underlying TEE is compromised.
Summary of Contributions. In this paper we make the
following contributions:
• We use CacheOut to obtain the sealing key of enclaves,

including architectural enclaves compiled and signed by
Intel (Section III).

• We show how to use the sealing key of the Intel’s Quoting
enclave in order to retrieve the machine’s attestation key
(Section III-C).

• We show how to use the retrieved attestation key to forge
SGX attestation quotes (Section IV).

• Finally, we discuss the implications of a broken attestation
mechanism on Signal and on Town Crier (Section V).

B. Current Status and Disclosure

As part of the disclosure of CacheOut [90], we notified
Intel of our findings in October 2019. While initial results
about CacheOut’s application to SGX were made public on a
mutually agreed upon date of January 27th, 2020, Intel did not
publish countermeasures mitigating CacheOut or the attacks
described in this paper. Finally, Intel indicated that microcode
updates mitigating the SGX leakage described in this paper
will be published on June 9th, 2020.

C. Threat Model

Following the SGX threat model, we assume a compromised
operating system where the attacker can install kernel modules

2



or otherwise execute code with supervisor (ring-0) privileges.
We assume that the hardware and software has been fully
updated with Intel’s latest microcode, and that the victim
enclave contains no software bugs or vulnerabilities. Finally,
we assume that the hardware is capable of supporting transac-
tion memory (TSX). While this feature has been disabled by
operating systems on all Intel machines released after 2018-
Q4, we used elevated privileges in order to re-enable TSX
RTM. We note that this does not violate the SGX threat model,
as the OS is untrusted, while Intel’s latest microcode update
forcibly aborts TSX transactions during SGX operations [44].

II. BACKGROUND

We now present background information on Intel’s Software
Guard Extensions and on microarchitectural attacks.

A. Intel Software Guard Extensions

Intel Software Guard Extensions (SGX) [5, 65] is an exten-
sion of the x86 64 instruction set, supporting secure execution
of code in untrusted environments. SGX creates secure execu-
tion environments, called enclaves, which protect the code and
data residing inside them from being maliciously inspected or
modified. Additionally, SGX provides an ecosystem for remote
attestation of enclaves’ software and the hardware on which
they run.

The SGX threat model assumes that the only trusted system
components are the processor and Intel-provided and Intel-
signed architectural enclaves. After booting, only the pro-
cessor is trusted. The trust is extended to the architectural
enclaves by hard-coding the public key used to sign them into
the processor. Other than the architectural enclaves, SGX does
not trust any software executing on the processor, including
the operating system, the hypervisor, and the firmware (BIOS).
The processor’s microcode, however, is considered part of the
processor and hence trusted.

For each enclave, SGX keeps an enclave-identity comprised
of the enclave developer’s identifier and a measurement rep-
resenting the enclave’s initial state. The developer’s identifier,
referred as MRSIGNER in SGX literature, is a cryptographic
hash of the public RSA key the enclave developer used to
sign the enclave’s measurement. The enclave measurement,
representing the enclave’s initial state, is a cryptographic hash
of those parts of the enclave’s contents (code and data) that its
developer chose to include in the measurement. The SDK im-
plementation includes in the measurement all contents added
to the enclave via EADD. Following the SGX nomenclature,
we refer to this measurement as MRENCLAVE.

B. SGX’s Sealing Mechanism

SGX provides enclaves with a mechanism for an encrypted
and authenticated persistent storage. During CPU production, a
randomly generated Root Seal Key, which is not kept in Intel’s
records, is fused in every SGX-enabled CPU. Using this key,
the CPU can derive a sealing key, which can be used to encrypt
and authenticate information from within the enclave’s address
space. Data that is sealed with this key, i.e., encrypted and

authenticated, can be safely passed to the operating system
for long-term storage, for example, on the computer’s disk.
SGX provides two types of sealing mechanisms, which we
now describe (See [5, 49] for additional details).
Sealing Using the Enclave’s Identity. As described in
Section II-A, each enclave has a unique field, called MREN-
CLAVE, which is a cryptographic hash of the contents used
to initialize the enclave code as well as some additional prop-
erties. Using the values of the Root Seal Key, MRENCLAVE,
and the CPU Security Version Number (SVN) an enclave can
use the EGETKEY instruction to derive a unique sealing key for
sealing data before passing it to the operating system for long
term storage. Note that as a consequence of this approach, for
the same Root Sealing Key (i.e., on the same CPU), different
software versions of the same enclave have different sealing
keys. This prohibits both data migration between different
versions of enclaves as well as using these sealed keys for
intra-enclave communication.
Sealing Using the Developer’s Identity. An alternative
option to the one discussed above is to generate the sealing
key using the Root Seal Key, the SVN, and MRSIGNER
(instead of MRENCLAVE). As explained in Section II-A,
MRSIGNER is a cryptographic hash of the public RSA key
of the enclave developer and there remains the same for all
enclaves developed by the same vendor. Thus, data sealed
in this way is accessible by different versions of the same
enclave, as well as by different enclaves belonging to the same
vendor.

C. Caching Hierarchy in Modern Processors

Modern processors contain a series of caching components
that all collaborate to bridge the speed gap between the fast
processor core and the slower memory, see Figure 1.

L2 Cache (256 KiB)

Write Path

Read Path Execution Unit

Fill Buffer (12 entries)L1-D Cache (32 KiB)New Path L1-D Cache (32 KiB)

Uncore

Fig. 1: Caching hierarchy in Intel processors.

When accessing memory, the processor first searches if the
data exists in the L1-Data cache. In case of a cache hit,
when the data is found in the cache, the accessing instruction
receives the data from the cache and proceeds to process it.
Conversely, in case of a cache miss, when the data is not
found in the cache, the processor resumes its search further
down the memory hierarchy until the data is found. When
data is retrieved from lower-level caches, it is often stored in
higher-level caches for possible future use.
Out-of Order Execution and Line Fill Buffers. To
exploit the inherent concurrency in software, the execution

3



engine of modern processors is out-of-order. That is, rather
than executing instructions in the order that is stipulated by
the program, the processor executes instructions as soon as
the data they process is available. Consequently, multiple
instructions may be in various stages of execution at the
same time. The main use of the line fill buffers (LFBs) is
to avoid locking the cache during cache-miss handling, in
order to allow concurrently-executing instructions to access the
cache. Specifically, when a cache miss occurs, the processor
allocates an entry in the LFB, which processes cache misses
asynchronously. When the data arrives from the lower levels
of the hierarchy, the LFB transfers the retrieved data to the
waiting instruction and copies it into the cache for potential
future use.
Cache Evictions. The capacity of the L1-Data cache is
typically relatively small (32 KiB in Intel processors). Hence,
when new data is being cached, old data has to be evicted
from the cache. In case the old data has not been modified,
it can just be discarded. However, if the data to be evicted
has been previously modified, the processor needs to percolate
the modifications in lower levels of the cache hierarchy, and
ultimately in the memory.

D. Microarchitectural Attacks

Cache Attacks. Because the behavior and the state of
microarchitectural components affects the execution speed of
programs, programs sharing the use of components can detect
contention and infer information on the execution of other
programs [28]. A large body of work exploits contention on
space in caches to recover cryptographic keys [13, 29, 30, 50,
59, 66, 73, 74, 96, 99] and other sensitive information [10,
33, 37, 95]. Temporal contention, i.e., exploiting the limited
capacity of the cache to handle concurrent accesses, can also
leak information [97]. Finally, cache contention can be used
to construct covert communication channels that bypass the
system’s protection guarantees [59, 64].
Transient Execution Attacks. Starting form Spectre and
Meltdown [55, 58], there has been a large body of work
on exploiting speculative and out-of-order execution to leak
information (see [15] for a survey). Specifically, in out-of-
order execution, the processor aims to predict the future
instruction stream in order to optimize the execution of future
instructions. However, when the processor mispredicts the
instruction stream it may execute instructions that deviate from
the program’s nominal behavior, bypassing the program’s con-
trol flow, or permission checks. When the processor discovers
the misprediction, it attempts to revert the incorrect execu-
tion by discarding the outcome of misspredicted instructions,
never committing them to the processor’s architectural state.
However, as discovered by Spectre and Meltdown [55, 58],
changes performed by incorrect transient execution do affect
the processor’s microarchitectural state, allowing attackers
to use the CPU’s microarchitecture as a means of storing
information. More specifically, in transient-execution attacks,
the attacker first causes transient execution of instructions that
access data not normally used by the program. The attacker

then uses a microarchitectural covert channel to exfiltrate the
data, thus bypassing the processor’s state reversion.
Meltdown-Type Attacks. While other transient attacks do
exist [9, 36, 51, 54, 55, 56, 61, 62], Meltdown-type attacks [15]
exploit delayed exception handling on Intel processors in order
to bypass hardware-backed security boundaries. Following
their original utilization in Meltdown [58] for reading kernel
data, such attacks have been used to recover the content
of floating-point registers [82, 89] as well as the L1-Data
cache [85, 93]. More recently, a new type of transient execu-
tion attacks was discovered, where the attacker is able to leak
information from internal microarchitectural buffers, including
the line fill buffers [79, 87], write combining operations [68],
and store buffers [14]. Dubbed Microarchitectural Data Sam-
pling (MDS) attacks by Intel, these attacks are likened to
“drinking from the firehose”, as the attacker has little control
over what data is observed and from what origin.

Recognizing the danger stemming from uncontrolled data
leaking from various internal microarchitectural data struc-
tures, two high level defense strategies have emerged. First,
for older processors, Intel have issues microcode updates that
overwrites the contents of various microarchitectural elements
such as internal buffers or L1-D cache [41, 43]. These were
then adopted by all major operating systems, flushing mi-
croarchitectural data structures on security domain changes. In
parallel, Intel has launched new processor architectures, which
attempt to mitigate transient execution issues in hardware.

E. CacheOut and LVI: Ineffective Flushing

While secure at first sight, recent works [86, 90] have
shown that Intel’s contents overwriting strategy does not fully
mitigate transient execution issues.
Load Value Injection (LVI). More specifically, LVI [86]
shows how an attacker can use the still leaky buffers in order
to inject values into the address space of a victim process or
SGX enclave. As the victim now performs transient execution
on incorrect data, it possible to temporary hijack the victim’s
control flow, or expose his secrets. Since LVI is particularly
effective against SGX enclaves, Intel has issued a series of
software mitigations [42], hardening enclave code and data
against injection attacks by restricting speculation.
CacheOut: Leaking Data via Cache Evictions. Next, buffer
overwriting does offer any protection in case the attacker
can somehow move data back after the buffer’s contents
was overwritten. Indeed, utilizing the observation that when
modified data is evicted from the L1-Data cache it can
sometimes end up in the LFB, the CacheOut [90] attack
was able to successfully bypass Intel’s buffer overwriting
countermeasures, again breaching the confidentiality of nearly
all secuirty domains.

Figure 2 is a schematic overview of the two scenarios
considered in CacheOut [90], where an attacker can observe
the victim’s data through the fill buffer (despite Intel’s buffer
overwriting countermeasures). The left shows how an attacker
can sample data that the victim is reading. Here, the the
attacker first ensures that the data the victim is about to read is

4



Evict

Write Secret

L1-D Cache

L1-D Cache

Fill Buffer

Sample
using TAA

W
riteback

FLUSH
RELOAD

Evict

Read Secret

L1-D Cache

Context

Sample
using TAA

FLUSH
RELOAD

Fill Buffer

Sampling Reads Sampling Writes

Switch

Context
Switch

Context
Switch

Context
Switch

2

3

4

1
1

2

3

4

L1d Cache

L2 Cache

Fig. 2: Overview of how the victim’s data can end up in the
LFB allowing an attacker to sample the data from the Fill
Buffers using an attack like TAA. Victim activity, attacker
activity, and microarchitectural effects are shown in green, red,
and yellow respectively. The context switches both illustrate
the OS flushing the MDS buffers before switching to the other
process as well as switching between actual Hyper Threads.
(from CacheOut [90])

no longer in the L1-D cache. The attacker does this by filling
up the L1-D cache with its own data to evict the victim’s data.
Now when the victim executes, the victim tries to read some
data again. However, since the data that the victim wishes to
read is no longer present in the L1-D cache, the CPU now has
to fetch the data from the higher-level caches or the physical
memory. Since cache misses have to be served through the
LFB, the attacker now has an opportunity to sample the data
from the LFB using an attack like TAA [44].

On the right we see how an attacker can sample data from
the victim when writing data. In this case, the victim will
write the data to the L1-D cache, as the CPU will handle
updating the higher-level caches and the physical memory in
the background. This presents an opportunity to the attacker
to leak the data. Similar to the case on the left, the attacker
fills up the L1-D cache to evict the victim’s modified cache
line. This forces the CPU to update the higher-level caches
immediately, as there is no longer space available in the L1-D
cache to host the victim’s data. In order to perform this update,
the data has to pass through the LFB. Now that the attacker
forcefully pushed the victim’s data into the LFB, it can again
use an attack like TAA to sample the data from the LFB.

In both cases the attacker can fully manipulate the micro-
architectural state to ensure that reads or writes originates from
the victim will have to pass through the LFB. Moreover, in the
case of writes, an attacker can force the data into the LFB and

sample it immediately without the intervention of a context
switch. This renders mitigations that rely on flushing these
leaky buffers during context switches ineffective.
Leaking SGX Enclaves via CacheOut. CacheOut further
demonstrates the use of the attack to build a read primitive that
leaks information from SGX enclaves. The read primitive uses
a modified SGX driver that exercises the control the operating
system has on the enclave to provide an interface that swaps
enclave pages out and in. In a nutshell, SGX includes two
instructions, ewb and eldu, which are used to export memory
pages from an enclave, while encrypting their contents, and to
import such encrypted pages back. Swapping a page out and
in leaves the contents of the page in the L1-Data cache, and
because the processor writes the contents into the enclave,
these contents are marked as ‘modified’. Concurrently with
swapping the pages, CacheOut evicts data from the L1-Data
cache, and uses the TSX Asynchronous Abort technique [44]
to leak the evicted data from the LFB. Using this technique,
an attacker can target specific bytes in the page that is being
swapped out and in, and retrieve them.

III. ATTACKING SGX’S SEALING MECHANISM

The CacheOut attack described in Section II-E is capa-
ble of breaching SGX’s confidentiality guarantees, effectively
dumping the contents of any SGX enclave available on the
target machine. It cannot, however, breach SGX’s integrity
guarantees as it is unable to modify the contents of the
enclave’s code or data.

In this section, we show an attack against SGX’s sealing
mechanism, which is a mechanism designed to provide en-
claves with encrypted and authenticated persistent storage. In
a nutshell, we use CacheOut to recover the sealing keys from
within the address space of Intel’s production quoting enclave.
Finally, we use the recovered sealing keys in order to decrypt
the long term storage of the quoting enclave, obtaining the
machines EPID attestation keys.

A. Extracting SGX Sealing Keys

Key derivation using EGETKEY leaves the sealing key in
the memory of the victim enclave. Thus, in principle, it is
possible to read this key using CacheOut [90]. However,
immediately after using it to encrypt or decrypt the sealed data,
the implementation of SGX’s sealing API erases the sealing
key from memory. Hence, to extract the key we need a method
for launching CacheOut during the data sealing or unsealing
process, before these keys are erased from the memory.
Tracing Quote Enclave Execution. We use a variant of
the controlled-channel attack [94] to induce an Asynchronous
Enclave Exit (AEX) when the enclave calls our functions of
interest. More specifically, we use mprotect() using the
PROT_NONE flag to unmap the page that contains our function
of interest. When the enclave then tries to execute the function,
it instead results in an AEX and a page fault, returning control
back to the operating system (or, more specifically, to the
attacker-controlled signal handler). However, since pages are
4 KiB in size, they may host multiple functions, meaning that

5



we have to carefully select the order of pages to unmap to
properly stop the quoting enclave at the point while the sealing
keys are still in memory. To achieve that, when control returns
back to our malicious signal handler, we mark the current
page as executable and proceed to unmap the page of the
next function of interest. Finally, we return control flow back
to SGX, in order to resume enclave execution until the next
function of interest.

Using the above describe method, we can trace the execution
of the quoting enclave until a point after the sealing keys have
been stored in memory but before they have been zeroed out.
Once the quoting enclave execution has reached this point, we
never resume its execution, proceeding to the next phase of
our attack.
Leaking Enclave Contents. Following the method of
Cachout [90], we use a modified SGX Linux driver that
repeatedly swaps the page holding the sealing keys in and
out of the physical memory, using SGX’s ewb and eldu
instructions with a short delay in between. As observed by
[90], this physical memory activity requires SGX pages to be
repeatedly encrypted and decrypted. Therefore, the CPU’s L1-
D cache will contain a decrypted copy of the page’s contents.
Next, using another Hyper-Thread on the same physical core,
the attacker uses CacheOut’s methodology, and evicts the
cache set whose values he would like to leak from the L1-
D cache to the CPU’s LFB. Finally, the attacker uses TAA
to recover the values from the CPU’s LFB. Finally, note that
since the victim enclave never resumes execution, no software
mitigation can be used to prevent the information from leaking.
Pinpointing Functions of Interest. The above descrip-
tion assumes that the attacker knows the precise execution
sequence of functions inside the quoting enclave from the
get_quote() function to the AES decryption operation
used to unseal the EPID keys. To recover this calling sequence,
we first compiled our own version of the quoting enclave
using Intel’s SDK and PSW. We then executed the quoting
enclave in debug mode with dummy inputs, tracking execution
up to the sgx_rijndael128GCM_decrypt() function,
which is used to decrypt the (dummy) EPID blob. The sgx_-
rijndael128GCM_decrypt() function proceeds by call-
ing l9_aes128_KeyExpansion_NI() to perform AES
key scheduling, expanding the AES sealing key into individual
AES round keys. Next, in order to stop enclave execution
immediately after the key scheduling, we leverage the fact that
the recently-introduced LVI countermeasures [42] mean that
enclaved functions no longer return using the ret instruction
directly, but instead call __x86_return_thunk() to re-
turn from a function. Thus, by unmapping the page containing
__x86_return_thunk() just after the execution of of
l9_aes128_KeyExpansion_NI(), we can run the quot-
ing enclave until the end of the AES key expansion process,
and stop its execution immediately after it, while the round
keys are still present in the enclave’s memory. Experimentally
verifying this, we were able to recover some round keys from
this self-compiled and signed quoting enclave, verifying the
ground truth using a debugger.

Attacking Intel’s Production Quoting Enclave. After our
practi";"""date"",""2020-06-12T13:47:25Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2020-06-12T13:47:25Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.21 (TeX Live 2020 Gentoo Linux) kpathsea version 6.3.2""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2020-06-12T13:47:25Z""
""created"",""2020-06-12T13:47:25Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-06-12T13:47:25Z""
""resourceName"",""SGAxe.pdf""
""Author"",""""
""producer"",""pdfTeX-1.40.21""
""pdf:docinfo:producer"",""pdfTeX-1.40.21""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2020-06-12T13:47:25Z""
""Last-Modified"",""2020-06-12T13:47:25Z""
""dcterms:modified"",""2020-06-12T13:47:25Z""
""title"",""""
""Last-Save-Date"",""2020-06-12T13:47:25Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2020-06-12T13:47:25Z""
""meta:save-date"",""2020-06-12T13:47:25Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.21 (TeX Live 2020 Gentoo Linux) kpathsea version 6.3.2""
""Content-Length"",""272090""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""14""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""4717"",""5193"",""4725"",""5439"",""4492"",""5257"",""4538"",""4581"",""5222"",""5080"",""4880"",""4589"",""4464"",""3588""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-06-12T13:47:25Z""
";https://scholar.google.ch/scholar?start=650&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098760-96;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;A generic construction of CCA-secure deterministic encryption;M Huang, B Yang, Y Zhao, X Wang, Y Zhou… ; Information Processing …, 2020  Elsevier;;"… gave the “strongest possible” notion of security for this primitive, called PRIV, and they also showed

how this notion can be achieved in the random oracle model. Afterwards, Boldyreva, Fehr, and

O'Neill (CRYPTO'08), followed by many other researchers, designed chosen …";Cité 1 fois;Les 2 versions;null;;;;https://scholar.google.ch/scholar?start=640&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098756-87;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Efficient and Round-Optimal Oblivious Transfer and Commitment with Adaptive Security;R Canetti, P Sarkar, X Wang ; International Conference on the Theory and …, 2020  Springer;;"… Yet another dimension is the setup used. Commonplace models include the common

random string model (\(\text {CRS} \)), the common reference string (CReS) model and

the random oracle (RO) model … Global Random Oracle Model …";Cité 1 fois;Les 2 versions;[PDF] iacr.org;https://eprint.iacr.org/2020/545.pdf;"
Efficient and Round-Optimal Oblivious Transfer and Commitment

with Adaptive Security∗

Ran Canetti
Boston University
canetti@bu.edu

Pratik Sarkar
Boston University
pratik93@bu.edu

Xiao Wang
Northwestern University

wangxiao@cs.northwestern.edu

Abstract

We construct the most efficient two-round adaptively secure bit-OT in the Common Ran-
dom String (CRS) model. The scheme is UC secure under the Decisional Diffie-Hellman (DDH)
assumption. It incurs O(1) exponentiations and sends O(1) group elements, whereas the state
of the art requires O(Îş2) exponentiations and communicates poly(Îş) bits, where Îş is the com-
putational security parameter. Along the way, we obtain several other efficient UC-secure OT
protocols under DDH :

– The most efficient yet two-round adaptive string-OT protocol assuming global programmable
random oracle. Furthermore, the protocol can be made non-interactive in the simultaneous
message setting, assuming random inputs for the sender.

– The first two-round string-OT with amortized constant exponentiations and communication
overhead which is secure in the global observable random oracle model.

– The first two-round receiver equivocal string-OT in the CRS model that incurs constant
computation and communication overhead.

We also obtain the first non-interactive adaptive string UC-commitment in the CRS model
which incurs a sublinear communication overhead in the security parameter. Specifically, we
commit to polylog(Îş) bits while communicating O(Îş) bits. Moreover, it is additively homomor-
phic.

We can also extend our results to the single CRS model where multiple sessions share the
same CRS. As a corollary, we obtain a two-round adaptively secure MPC protocol in this model.

∗This work was supported by the the IARPA ACHILLES project, the NSF MACS project and NSF grant CNS-
1422965. The first author also thanks the Check Point Institute for Information Security.



Contents

1 Introduction 2
1.1 Our Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.1.1 Global Random Oracle Model. . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1.2 Common Random String Model. . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1.3 Single Common Random String model . . . . . . . . . . . . . . . . . . . . . . 5

1.2 Key Insights . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2 Preliminaries 7

3 Technical Overview 10
3.1 Adaptively Secure OT in the Global Programmable RO Model . . . . . . . . . . . . 10
3.2 Receiver Equivocal Oblivious Transfer in the CRS model . . . . . . . . . . . . . . . . 12
3.3 Adaptively Secure Oblivious Transfer in the CRS model . . . . . . . . . . . . . . . . 12
3.4 Non-Interactive Commitment with Adaptive Security . . . . . . . . . . . . . . . . . . 13

4 Oblivious Transfer in the Global Random Oracle Model 14
4.1 Adaptively Secure OT in the Global Programmable RO Model . . . . . . . . . . . . 14

4.1.1 Practical optimizations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.2 Statically Secure OT in the Global Observable RO Model . . . . . . . . . . . . . . . 22

4.2.1 Security proof. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

5 Receiver Adaptively Secure OT in the CRS Model 25
5.1 Properties of CRS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
5.2 Security Proof . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
5.3 Efficient Static OT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

6 Adaptively Secure Oblivious Transfer in the CRS Model 28
6.1 Semi-adaptively secure OT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

6.1.1 Security Proof . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
6.2 Obtaining Full Adaptive Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

6.2.1 Efficiency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

7 Adaptively Secure Non-Interactive Commitment in the CRS Model 32
7.1 Security Proof . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
7.2 Concrete Instantiation and Efficiency . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

8 Results in the Single CRS Model 34
8.1 Security requirements from CRSssid . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
8.2 Adaptively Secure OT in the sCRS model . . . . . . . . . . . . . . . . . . . . . . . . 37
8.3 Adaptively Secure Non-interactive Commitment in the sCRS model . . . . . . . . . 39
8.4 Adaptively Secure MPC in the sCRS model . . . . . . . . . . . . . . . . . . . . . . . 40

1



Table 1: Comparing our actively-secure UC-OT protocols with state-of-the-art DDH-based 2-round
actively-secure UC-OT protocols.

Setting Protocols Setup Security
Sender-input

Exponentiations
Communication

size (bits) (bits)

1
[34]

GPRO
Adaptive Îş 6 4log |G| + 2Îş

[6] Adaptive Îş 11 6Îş
πaOT-GPRO (Fig. 4)1 Adaptive κ 5 2log |G|+2κ

2
[10]

GORO Static
Îş O(Îş) O(Îş2)

πsOT-GORO (Fig. 10)2 κ 5 2log |G|+2κ

3
[38]3 CReS

Static
log |G| 11 6log |G|

πsOT-CRS(Fig. 16) CRS log |G| 8 5log |G|

4
[23] CRS

Receiver
log |G| poly(Îş) poly(Îş)

[5]3 CReS
Equivocal

log |G| O(Îş) O(Îş2)
πreOT-CRS(Fig. 13) CRS log |G| 9 5log |G|

5
[5]3 CReS

Adaptive
1 Ω(κ2) + 2 · NCEE = O(κ2) poly(κ)

πaOT-CRS (Fig. 20)4 CRS 1 11 + 2 NCEE = O(1) 6 log |G| + 2 NCEC = O(κ)

Note: The computational security parameter is Îş and G denotes a group where DDH holds with log |G| = O(Îş). NCEE
and NCEC denotes the exponentation and communication cost of an augmented NCE on a bit respectively. It can be
instantiated using the DDH-based scheme of [14] where NCEC = O(κ) and NCEE = O(1). 1 πaOT-GPRO requires a
one-time communication of 2 group elements and κ bits and computation of 4 exponentiations. 2 πsOT-GORO requires a
one-time communication of 2 group elements and Îş bits and computation of 2 NIZKPoKs and 5 exponentiations. 3Can
be instantiated from QR and LWE too. 4 πaOT-CRS has a one-time communication cost of log |G| and one exponentiation.

1 Introduction

Oblivious Transfer (OT), introduced in [39, 21], is one of the main pillars of secure distributed
computation. Indeed, OT is a crucial building block for many MPC protocols, e.g. [40, 26, 31, 25,
4, 5]. As a result, significant amount of research has been dedicated to constructing OT protocols
that are efficient enough and secure enough to be of practical use.

Designing good OT protocols is a multi-dimensional challenge: One obvious dimension is the
complexity, in terms of computational and communication overhead, as well as the number of
rounds. Another dimension is the level of security guaranteed. Here the standard measure is
Universally Composable (UC) security [8], in order to enable seamless modular composition into
larger MPC protocols. Yet another dimension is the setup used. Commonplace models include
the common random string model (CRS), the common reference string (CReS) model and the
random oracle (RO) model. (Recall that UC-secure OT does not exist in the plain model [9], thus
it is essential to use some sort of setup.) Yet another dimension is the computational hardness
assumptions used.

A final dimension, which is the focus of this work, is whether security is guaranteed for adaptive
corruption of one or both of the participants, or alternatively only for the static case where one
of the parties is corrupted, and the corruption takes place before the computation starts. Indeed,
most of the recent works towards efficient OT concentrates on the static case, e.g. [38, 10, 34, 20].

We concentrate on the case of two-round, adaptively UC-secure OT. We only consider the
case of malicious adversaries. It is easy to see that two rounds is the minimum possible, even
for static OT. Furthermore, two-round OT enables two-round MPC [3, 25, 4, 5] which is again
round-optimal. More importantly, the efficiency of the two-round MPC protocol crucially depends
on the efficiency of the underlying two-round UC-OT protocol. Still, there is a dearth of efficient
two-round adaptively UC-secure OT protocols which can tolerate malicious corruptions.

2



1.1 Our Contributions

We present a number of two-round UC-secure OT protocols. Our protocols are all based on the
plain DDH assumption and work with any group where DDH is hard. While the protocols are
quite different and in particular work in very different settings, they all use the same underlying
methodology, which we sketch in Section 1.2. But first we summarize our results and compare it
with the relevant state-of-the-art protocols. We organize the presentation and comparison based
on the setup assumptions - the global random oracle (GRO) model, and the common reference and
random string models. A stronger notion of RO is the GRO model where the same instance of
RO is shared globally among different sessions. We have results in the global observable random
oracle (GORO) model and the global programmable random oracle (GPRO) model. Our results
are further subdivided into cases based on static and adaptive corruptions. A detailed comparison
can be found in Table 1. We assume that the number of bits required to represent a group element
(for which DDH holds) is O(Îş). For example, the DDH assumption holds in the elliptic curve
groups and a group element can be represented with O(Îş) bits.

1.1.1 Global Random Oracle Model.

Our protocols are proven to be secure in the well established GRO [7, 10] model. Our results in
the GRO model are as follows:

– Efficient Adaptive OT in Programmable GRO model. The work of “Simplest OT” [16]
presented a 3-round OT in the programmable RO (PRO) model, which was later shown as not
UC-statically secure [32, 6]. Inspired by their protocol, we design a 2-round adaptively secure OT
πaOT-GPRO in the GPRO model. Our protocol requires roughly 5 exponentiations and communicates
2 group elements and 2κ bits when the sender’s input messages are κ bits long and the computational
security parameter is Îş.

State-of-the-art. The work of [6] presents an adaptively secure OT assuming DDH. They require
11 exponentiations and 5Îş bits of communication. The work of [34] obtains a two-round OT based
on DDH using 6 exponentiations. They obtained static security assuming PRO. We observe that it
can be proven to be adaptively secure under the same assumptions. They also provide an optimized
variant requiring 4 exponentiations under the non-standard assumption of Interactive DDH, which
is not known to be reducible to standard DDH. The work of [27] presented a 8 round adaptive
OT protocol from semi-honest UC adaptive-OT and observable GRO (i.e. GORO) model in the
tamper-proof hardware model. We do not compare with them due to difference in the underlying
setup assumptions. A detailed comparison with other protocols is shown as Setting 1 in Table 1.

– One-round random OT in the GPRO + short single CRS model. Our GPRO-based
protocol can be further improved to obtain a one-round random OT (where the sender’s messages
are randomly chosen) πaROT-GPRO in the simultaneous message (where the parties can send messages
in parallel) setting assuming a single short CRS of two group elements. By single CRS, we refer to
the setting of [11] where the same CRS is shared among all sessions and the simulator knows the
trapdoor of the CRS. In our protocols, each random OT requires communicating 2 group elements
and computing roughly 5 exponentiations. This is particularly useful to compute the base OT in
OT extension [30, 37] non-interactively during the offline phase.

State-of-the-art. In comparison, the work of [34] can obtain a one-round random OT in the
simultaneous message setting from non-interactive Key Agreement protocols. Assuming DDH,

3



they can instantiate their protocol using 6 exponentiations.1 The work by Doerner et al. [19]
presented an OT with selective failure based on observable RO (ORO) and used it to obtain OT
extension while computing roughly 3 exponentiations per base-OT and 1 NIZKpok. However, their
OT requires 5 rounds of interaction and communication of 4 group elements and 3Îş bit strings,
yielding a 6 round OT extension. On the other hand, our protocol would give a 3 round OT
extension with communication of 2 group elements per base-OT and it should outperform theirs in
the WAN setting where interaction dominates the computation time.

– Static OT in the Observable GRO model. We replace the GPRO by a non-programmable
GORO, with an extra one-time cost of 2 NIZKPoKs for Discrete Log and 5 exponentiations, which
can be reused across multiple executions. One-time cost is a cost that is incurred only once per
session/subsession even if multiple OT protocols are run in that session/subsession between the
pair of parties. The remaining per-OT cost of this protocol is 5 exponentiations, except that now
the protocol is only statically secure.

State-of-the-art. In comparison, the only two-round OT protocol from GORO is known from
[10]. The authors generate a statically-secure one-sided simulatable OT under DDH assumption. It
is used to obtain a UC-secure 2PC protocol using garbled circuits [3]. The 2PC can be instantiated
as an UC-secure OT protocol. Each such OT would cost O(Îş) exponentiations, which cannot be
amortized for large number of OTs. A detailed comparison can be found in Setting 2 of Table. 1.

1.1.2 Common Random String Model.

Next we present our results in the CRS model. We would like to note that the state-of-the-art
protocols are in a stronger model, i.e. the common reference string model and yet we work in the
common random string model and still outperform them. Our results and detailed comparison
follows:

– Static OT in the CRS model. We replace the GRO with a non programmable CRS. This gives
us an efficient two-round static OT πsOT-CRS which requires 8 exponentiations and communication
of 5 group elements.

State-of-the-art. In contrast, The state-of-the-art is obtained by [38] in the common reference
string model from DDH, Quadratic Residuosity (QR) and Learning with Errors (LWE). Their
DDH based instantiation required 11 exponentiations and communicated 6 group elements, while
other instantiations required more. Following this, [15] presented constructions in the single com-
mon reference string model (of [11]), which is a weaker setup assumption. They have a 2 round
construction from Decision Linear Assumption which requires 20 exponentiations and they have a
4 round construction from DDH and Decisional Composite Residuosity Assumption. The recent
work of [20] presents a theoretical construction based on CDH and Learning with Parity. Detailed
comparison can be found in Setting 3 of Table. 1.

– Receiver equivocal OT in the CRS model. Next, we add security against adaptive cor-
ruption of receiver at the cost of one extra exponentiation. This yields a receiver equivocal OT
πreOT-CRS which requires 9 exponentiations and communication of 5 group elements. Such an OT
can find useful applications in efficient adaptively-secure zero knowledge [22] schemes.

1They have an optimized variant (in Appendix D.2 of their paper) from Interactive DDH requiring 4 exponentia-
tions based on a non-standard assumption, not known to be reducible to standard DDH assumption.

4



State-of-the-art. Previous receiver equivocal OT protocol of [23] required somewhere equivocal
encryption leading to a practically infeasible solution. On the other hand, [5] required O(Îş) in-
stances of static string-OTs and non-blackbox usage of non-interactive equivocal commitment to
construct a receiver equivocal OT. A detailed comparison can be found in Setting 4 of Table. 1.

– Adaptive OT in the CRS model. Finally, we add sender equivocation in our receiver equivocal
OT to obtain a semi-adaptive OT (which is secure against static corruption of one party and
adaptive corruption of another party) πsaOT-CRS in two rounds. Then, we apply the transformation
of [5] to obtain our adaptively-secure bit OT πaOT-CRS in two rounds. Their transformation upgrades
a semi-adaptively secure OT to an adaptively secure OT in the augmented NCE model. Our final
protocol πaOT-CRS computes 11 exponentiations and communicates 7 group elements. In addition,
it encrypts 2 bits using augmented NCE. Upon instantiating the NCE scheme using the DDH-
based protocol of [14], we obtain the first two round adaptively secure bit-OT which has constant
communication and computation overhead.

State-of-the-art. In this setting, few works [24, 12, 24] achieve adaptive security based on
general two-round MPC protocol using indistinguishability obfuscation. The only round optimal
adaptively-secure protocol under standard computational assumption is due to [5] from DDH, LWE,
and QR. They obtain a semi-adaptive bit-OT by garbling a non-interactive equivocal commitment
scheme using equivocal garbling techniques of [13]. The construction also requires O(Îş2) invoca-
tions to a static string OT with oblivious sampleability property. Then, they provide a generic
transformation to obtain an adaptively secure bit OT from a semi-adaptively secure bit-OT in the
augmented NCE model. On efficiency measures, the work of [5] constructs the equivocal garbled
circuit by communicating poly(Îş) bits and their semi-adaptive bit OT requires O(Îş2) exponenti-
ations, thus yielding a feasibility result. In contrast, our protocol is concretely efficient. We have
compared with their protocol in Setting 5 of Table. 1.

– Non-interactive adaptive commitment. As an independent result, we demonstrate that the
first message of any two-round receiver equivocal OT behaves as an adaptively-secure commitment.
By applying this result to our receiver equivocal OT πreOT-CRS, we obtain the first non-interactive
adaptive string commitment scheme with sublinear communication in Îş. More specifically, we
commit polylog(Îş) bits using 4 exponentiations and communicating 2 group elements. Interestingly,
our scheme is additively homomorphic.

State-of-the-art. On the other hand, the previous non-interactive adaptively-secure commitment
schemes [9, 11, 1, 2] in the common reference string model were bit commitments requiring O(1)
exponentiations and O(Îş) bits communication to commit a bit. There are string commitments
[18, 17] but they require 3 rounds of interaction for commitment. The work of [28] presented
a theoretical construction from the minimal assumption of public key encryption with oblivious
ciphertext generation. It has an interactive commitment phase and communicates O(Îş2) bits to
commit to a single bit. Table. 2 provides a qualitative comparison of our protocol with other
schemes.

1.1.3 Single Common Random String model

Currently, our results in this subsection are in the local CRS model. We can extend it to the
single common random string, i.e. sCRS model of [11], where all parties share the same sCRS for
their subsessions. A subsession is computed between a pair of parties with unique roles (party A

5



Table 2: Comparing our protocol with state-of-the-art Adaptively Secure (without erasures) UC
commitment schemes where the commitment size is O(Îş) bits

Protocols
Message No. of rounds

Setup Assumptions
bit length Commit Decommit

[9] 1 1 1 CReS DDH + UOWHF

[11] 1 1 1 CReS TDP

[1] 1 1 1 CReS SXDH

[2] 1 1 1 CReS DDH

[18] Îş 3 1 CReS DCR

[17] Îş 3 1 CReS DCR + SRSA

Our DDH-based
polylog(Îş) 1 1 CRS DDH

protocol (Fig. 24)

Notations:
UOWHF - Universal One-Way Hash Functions
TDP - Trapdoor Permutations, SXDH - Symmetric External Diffie–Hellman,
DCR - Decisional Composite Residuosity, SRSA - Strong RSA

is the sender of an OT subsession and Party B is the receiver). The local CRS is generated from
sCRS by the parties during the protocol. There can be multiple instances of the same protocol
within a subsession with the same local CRS between same parties with their roles preserved, i.e.
A will be the sender and B will be the receiver. The simulator knows the hidden trapdoors for
sCRS. This benefit comes at a cost of keeping the sCRS length to 4Îş + 2 group elements. The
length is independent of the number of parties or the number of instances of the protocol being
run. However, we assume that the subsession ids are chosen statically by the environment Z before
seeing sCRS. Using our adaptive OT and commitment protocol in the sCRS model, we obtain a
two-round adaptively secure MPC protocol in the sCRS model. Similar result was observed in the
work of [5].

1.2 Key Insights

Our OT protocols are in the dual-mode [38, 33] paradigm. In this paradigm, the protocol can
be either in extractable mode or equivocal mode based on the mode of the setup assumption. In
the extractable mode, the input of a corrupt receiver can be extracted by a simulator(playing the
role of sender) using a trapdoor; whereas in the equivocal mode the simulator(playing the role of
honest receiver) can use the trapdoor to compute randomness that would equivocate the receiver’s
message to both bit values b ∈ {0, 1}. This would enable the simulator to extract a corrupt
sender’s input messages corresponding to both bit values. Previous protocols ensured that the real
world protocol was always in the extractable mode by programming the setup distribution [38, 33].
However, this required programming the setup based on which party is statically corrupt and this
was incompatible with adaptive security.

The novelty of our paper lies in programming the mode of the protocol, during the protocol
execution, without explicitly programming the setup. We achieve this by relying on the Computa-
tional Diffie-Hellman(CDH) and DDH assumption. The protocols either start off with a common
random string - (g, h, T1) or generate one by invoking the GRO on a random string. The receiver
is required to generate T2 and execute the OT protocol using (g, h, T1, T2) as the setup tuple. The

6



protocol ensures that if the tuple is non-DDH then the protocol is in extractable mode, else it is in
equivocal mode. The CDH assumption guarantees that the tuple is a non-DDH tuple and hence
the real world protocol is in extractable mode. Meanwhile, the simulator can compute T2 = htd

s.t. the tuple is in equivocal mode by using the trapdoor td = logg T1. The simulated tuple is
indistinguishable from real tuple due to DDH assumption. This trick follows by carefully tweaking
the DDH based instantiation of the PWV framework such that it satisfies an additional property,
i.e. the CRS for the protocol will be in extractable mode (a.k.a messy mode according to PVW)
and it can be set to equivocal mode (a.k.a decryption mode according to PVW) by the simulator,
given a trapdoor. This enables simulation in the adaptive setting as the simulator can conveniently
program the CRS based on which party gets corrupted. Extending our techniques to hold under
additional assumptions is an intriguing open question, especially LWE and QR since PVW can be
instantiated from them. See Section 3 for a more detailed overview.

Paper Organization. In the next section, we introduce some notations and important concepts
used in this paper. In Section 3, we present the key intuitions behind our protocols. This is followed
by our results in the global random oracle model in Section 4. Then, we replace the random oracle
assumption with a CRS setup to obtain a receiver equivocal OT in Sec. 5. Our optimized static-OT
is present in the same section. In Section 6 we add sender equivocation in our receiver equivocal
OT to obtain adaptively-secure OT in the CRS model. We present our independent result on
adaptively-secure commitment scheme in Section 7. Finally, we conclude by replacing our local
CRS with a single CRS in Section 8. In the same section we provide our two round adaptive MPC
protocol in the single CRS model.

2 Preliminaries

Notations. We denote by a← D a uniform sampling of an element a from a distribution D. The
set of elements {1, . . . , n} is represented by [n]. We denote polylog(a) and poly(b) as polynomials in
log a and b respectively. We denote a probabilistic polynomial time algorithm as PPT. We denote
the computational security parameter by κ. Let Zq denote the field of order q, where q = p−1

2 and
p are primes. Let G be the multiplicative group corresponding to Z∗p with generator g, where DDH
assumption holds. We denote the set of natural numbers as N. When a party S gets corrupted we
denote it by S∗. Our protocols have the following naming convention π〈sec〉〈prot〉-〈setup〉 where 〈sec〉
refers to the security model and it can be either s (static), re (receiver equivocal) or a (adaptive).
〈prot〉 refers to the protocol which is either OT or ROT or COM based on OT or random OT or
commitment protocol respectively. Similarly, 〈setup〉 refers to the setup assumption where it can
be either PRO (PRO model) or ORO (ORO model) or CRS (CRS). Our security proofs are in the
Universal Composability (UC) framework of [8]. We refer to the original paper for details.

Global Random Oracle Model. We present the global random oracle functionality from [7]
in Fig. 1. It allows a simulator to observe illegitimate queries that are made by the adversary
from outside the session by invoking the Observe command. It also enables the simulator to
program (using the Program command) the random oracle on unqueried input points. Meanwhile,
an adversary can also program (using the Program command) the random oracle on a point
but an honest party can check whether that point has been programmed or not by invoking the
IsProgrammed command. In the ideal world, a simulator can successfully program the RO since
it can always return the result of IsProgrammed command as 0 when the adversary invokes it to
verify whether a point has been programmed or not. More details can be found in Section 8 of [7].
In our OT protocols we require multiple instances of the GRO due different distributions on the

7



Figure 1: The ideal functionality FGRO for Global Random Oracle

FGRO

FGRO is parameterized by a domain D and range R and it proceeds as follows, running on security
parameter Îş:

– FGRO maintains a list L (which is initially empty) of pairs of values (ŝid, m̂, ĥ), s.t. m̂ ∈ D, ĥ ∈ R
and ŝid is a session id.

– Upon receiving a value (Query,m, sid′) (where m ∈ D) from a party P, from session with session

id sid, perform the following: If there is a pair (sid′,m, ĥ), for some ĥ ∈ R, in the list L, set h := ĥ.
If there is no such pair, sample h←R R and store the pair (sid′,m, h) in L. If sid 6= sid′, then add
(sid′,m, h) to the illegitimate query set Qsid. Once h is set, reply to the activating machine with
(HashConfirm, h).

– Upon receiving a value (Observe, sid) from the adversary: If Qsid does not exist then set Qsid = ⊥.
Output Qsid to the adversary.

– Upon receiving a value (Program,m, h′, sid) from the adversary, if there exists an entry (sid,m, h)
and h 6= h′ then ignore this input. Else, set L = L ∪ (sid,m, h) and prog = prog ∪m and return
(ProgramConfirm) to adversary.

– Upon receiving a value (IsProgrammed,m, sid′) from a party (P, sid), if sid 6= sid′ then ignore
the input. Else, set b = 1 if m ∈ prog. Otherwise set b = 0. Return (IsProgrammedResult, b)
to the calling entity.

domain and range of the GRO. We denote them as FGRO1, FGRO2 and so on. We assume FGROi is
indexed by a parameter i ∈ N, in addition to sid. We avoid writing i as part of the parameters to
avoid notation overloading.

Common Random String Model. In this assumption, the parties of a session sid have access
to a string randomly sampled from a distribution. A CRS is local to the session sid and should not
be used for protocols outside the session. In the security proof, the simulator would have access
to the trapdoors of the CRS which would enable him to simulate the ideal world adversary. In the
MPC literature, the acronym CRS can also refer to common reference string which is a stronger
assumption than common random string. In this paper, we always use CRS for common random
string unless explicitly mentioned. We also use the single CRS model [11] where a single CRS -
sCRS is shared among all sessions and the simulator knows the trapdoor of the sCRS.

Oblivious Transfer. In a 1-out-of-2 OT, we have a sender (S) holding two inputs a0, a1 ∈ {0, 1}n
and a receiver (R) holding a choice bit b. The correctness of OT means that R will obtain ab as
the outcome of the protocol. At the same time, S should learn nothing about b, and R should
learn nothing about the other input of S, namely ab̄. The ideal OT functionality FOT is shown in
Figure 2. We also consider the multi-session variant FmOT (Figure 25) where multiple parties can
run pairwise OT protocols, while sharing the same setup resources. This captures our OT protocols
in the single CRS model.

Adversarial Model. We initially consider security against static corruptions by a malicious adver-
sary. Later, we need different levels of adaptive security and we enlist them as follows:

- Static corruption: The adversary corrupts the parties at the beginning of the protocol.
- Receiver equivocal corruption: The adversary corrupts sender statically and he corrupts the

receiver adaptively.

8



Figure 2: The ideal functionality FOT for Oblivious Transfer

FOT

FOT interacts with a sender S and a receiver R as follows:

– On input (Choose, rec, sid, b) from R where b ∈ {0, 1}; if no message of the form (rec, sid, b) has
been recorded in the memory, store (rec, sid, b) and send (rec, sid) to S.

– On input (Transfer, sen, sid, (a0, a1)) from S with a0, a1 ∈ {0, 1}n, if no message of the form
(sen, sid, (a0, a1)) is recorded and a message of the form (rec, sid, b) is stored, send (sent, sid, ab) to
R and (sent, sid) to S. Ignore future messages with the same sid.

Figure 3: The ideal functionality FCOM for Commitment Scheme

FCOM

FCOM interacts with committer C and verifier V as follows:

– On receiving input ((Commit,V),C, sid,m) from C, if (sid,C,V,m′) has been recorded, ignore the
input. Else record the tuple (sid,C,V,m) and send (Receipt, sid,C,V) to V.

– On receiving input (Decommit,C, sid) from C, if there is a record of the form (sid,C,V,m′) return
(Decommit, sid,C,V,m′) to V. Otherwise, ignore the input.

- Sender equivocal corruption: The adversary corrupts receiver statically and he corrupts the
sender adaptively.

- Semi-adaptive corruption: The adversary corrupts one party statically and the other party
adaptively.

- Adaptive corruption: The adversary corrupts both parties adaptively. This scenario covers the
previous corruption cases.

Commitment. A commitment scheme allows a committing party C to compute a commitment
c to a message m, using randomness r, towards a party V in the Commit phase. Later in the
Decommit phase, C can open c to m by sending the decommitment to V. The commitment should
hide m from a corrupt V∗. Binding ensures that a corrupt C∗ cannot open c to a different message
m′ 6= m. In addition, UC-secure commitments require a simulator (for honest V) to extract the
message committed by C∗. Also, it enables a simulator (for honest C) to commit to 0 and later open
it to any valid message by using the trapdoor. The ideal commitment functionality FCOM is shown
in Figure 3. We also consider the multi-session [11] variant FmCOM (Figure 26) where multiple
parties can run pairwise commitment schemes protocols, while sharing the same setup resources.
This captures our commitment scheme in the single CRS model.

Non-Committing Encryption. A non-committing encryption consists of three algorithms NCE =
(Gen;Enc;Dec). It is a public key encryption scheme which allows a simulator to encrypt a plain-
text in the presence of an adaptive adversary. Given a trapdoor, the simulator (on behalf of the
honest party) can produce some dummy ciphertext c without the knowledge of any plaintext m.
Later when the honest party gets corrupted and the simulator produces matching randomness (or
decryption key) s.t. c decrypts to m. More formally, it is defined as follows.

Definition 1. (Non-Committing Encryption). A non-committing (bit) encryption scheme
(NCE) consists of a tuple (NCE.Gen,NCE.Enc,NCE.Dec,NCE.S) where (NCE.Gen,NCE.Enc,NCE.Dec)
is an IND-CPA public key encryption scheme and NCE.S is the simulation satisfying the following
property: for b ∈ {0, 1} the following distributions are computationally indistinguishable:

{(pk, c, rG, rE) : (pk, sk)← NC";"""date"",""2020-09-12T19:27:12Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2020-09-12T19:27:12Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.20 (TeX Live 2019) kpathsea version 6.3.1""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2020-09-12T19:27:12Z""
""created"",""2020-09-12T19:27:12Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-09-12T19:27:12Z""
""resourceName"",""545.pdf""
""Author"",""""
""producer"",""pdfTeX-1.40.20""
""pdf:docinfo:producer"",""pdfTeX-1.40.20""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""12"",""12"",""5"",""8"",""6"",""4"",""12"",""5"",""3"",""0"",""15"",""4"",""16"",""13"",""12"",""0"",""0"",""0"",""0"",""0"",""9"",""1"",""0"",""11"",""0"",""0"",""4"",""6"",""8"",""18"",""16"",""8"",""11"",""16"",""10"",""0"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2020-09-12T19:27:12Z""
""Last-Modified"",""2020-09-12T19:27:12Z""
""dcterms:modified"",""2020-09-12T19:27:12Z""
""title"",""""
""Last-Save-Date"",""2020-09-12T19:27:12Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2020-09-12T19:27:12Z""
""meta:save-date"",""2020-09-12T19:27:12Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.20 (TeX Live 2019) kpathsea version 6.3.1""
""Content-Length"",""582908""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""45""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""1619"",""1860"",""2902"",""3002"",""2948"",""3142"",""2365"",""3322"",""2668"",""2712"",""1869"",""3271"",""3265"",""3063"",""2886"",""2356"",""2005"",""2538"",""2505"",""2145"",""2509"",""2419"",""2321"",""2119"",""2186"",""2546"",""1563"",""2074"",""1851"",""1662"",""2163"",""2186"",""2374"",""2301"",""2339"",""2369"",""2681"",""3052"",""1999"",""2866"",""2311"",""2563"",""2485"",""2440"",""644""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-09-12T19:27:12Z""
";https://scholar.google.ch/scholar?start=630&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098857-315;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;A composable security treatment of the lightning network;A Kiayias, OST Litos ; 2020 IEEE 33rd Computer Security …, 2020  ieeexplore.ieee.org;;"… the Bitcoin blockchain protocol has been demonstrated in previous work [Badertscher et al.,

Crypto'17] … 10], and further refined in [11], which we know that is realised by the Bitcoin blockchain …

network protocol ?LN and prove that it realises FPayNet in the Random Oracle model …";Cité 19 fois;Les 6 versions;[PDF] cointhinktank.com;https://cointhinktank.com/upload/Lightning%20Network%20-%20A%20Composable%20Security%20Treatment.pdf;"
A Composable Security Treatment of the
Lightning Network

Aggelos Kiayias1,2 and Orfeas Stefanos Thyfronitis Litos1

1 University of Edinburgh
2 IOHK

akiayias@inf.ed.ac.uk, o.thyfronitis@ed.ac.uk

Abstract. The high latency and low throughput of blockchain proto-
cols constitute one of the fundamental barriers for their wider adoption.
Overlay protocols, notably the lightning network, have been touted as
the most viable direction for rectifying this in practice. In this work we
present for the first time a full formalisation and security analysis of
the lightning network in the (global) universal composition setting that
takes into account a global ledger functionality for which previous work
[Badertscher et al., Crypto’17] has demonstrated its realisability by the
Bitcoin blockchain protocol. As a result, our treatment delineates exactly
how the security guarantees of the protocol depend on the properties of
the underlying ledger. Moreover, we provide a complete and modular
description of the core of the lightning protocol that highlights precisely
its dependency to underlying basic cryptographic primitives such as dig-
ital signatures, pseudorandom functions, identity-based signatures and
a less common two-party primitive, which we term a combined digital
signature, that were originally hidden within the lightning protocol’s im-
plementation.

1 Introduction

Improving the latency of blockchain protocols, in the sense of the time it takes
for a transaction to be “finalised”, as well as their throughput, in the sense of
the number of transactions they can handle per unit of time, are perhaps the
two most crucial open questions in the area of permissionless distributed ledgers
and remain fundamental barriers for their wider adoption in applications that
require large scale and reasonably expedient transaction processing, cf. [1]. The
Bitcoin blockchain protocol, introduced by Nakamoto [2], provides settlement
with probability of error that drops exponentially in the number of blocks k
that accumulate over a transaction of interest. This has been informally argued
in the original white paper, and further formally demonstrated in [3], from where
it can be inferred that the total delay in actual time for a transaction to settle
is linear in k in the worst case. These results were subsequently generalised
to the setting of partial synchrony [4] and variable difficulty [5]. Interestingly,
this latency “deficiency” is intrinsic to the blockchain approach (see below), i.e.,
latency’s dependency on k is not a side-effect of the security analysis but rather
a characteristic of the underlying protocol and the threat model it operates in.



Given the above state of affairs, one has to either change the underlying
settlement protocol or devise some other mechanism that, in conjunction with
the blockchain protocol, achieves high throughput and low latency. A number of
works proceeded with the first direction, e.g., hybrid consensus [6] or Algorand
[7]. A downside of this approach is that the resulting protocols fundamentally
change the threat model within which Bitcoin is supposed to operate, e.g., by
changing the threshold required for security or the underlying cryptographic
assumptions and setup that is needed. The additional side-effect of such solutions
is that they are fundamentally incompatible with the Bitcoin blockchain, which
is arguably the currently most successful deployed instance of the blockchain
protocol.

The alternative approach is to build an overlay protocol that utilises the
blockchain protocol as a “fall back” layer, while facilitating “off-chain” settlement
under certain additional assumptions. We note that in light of the impossibility
result regarding protocol “responsiveness” from [6] that states that no protocol
can provide settlement in time proportional to actual network delay and provide
a security threshold over 1/3, we know that some additional assumption would
be required for the overlay protocol to work.

The first instance of this approach and by far the most widely known and
utilised so far, came with the lightning network [8]3 that provided an overlay
mechanism over the Bitcoin blockchain that introduces and takes advantage of
the concept of a bilateral payment channel. The latency for a transaction be-
comes linear to actual network delay and another factor that equals the number
of bilateral payment channel hops in the path that connects the two end-points of
the transaction. If a payment transaction is confirmed by the parties implicated
in a payment then it is guaranteed that, should the parties wish it, eventually
the ledger will record “gross” settlement transactions between the parties in the
path of the payment transaction that are consistent with it. Deviations from this
guarantee are cryptographically feasible but deincentivised via on-chain penal-
ties. Moreover, note that no record of a specific payment transaction need ever
appear on-chain thus the number of lightning transactions that can be exchanged
can reach the maximum capacity the network allows between the parties, with-
out being impeded by any restrictions of the underlying blockchain protocol.

The lightning network has been very influential in the space and spun a
number of follow up research and implementations (see below for references).
We note that the lightning network is not the only option for building an overlay
over a blockchain, see e.g., [9] for an alternative approach where it is shown that
if the assumption is raised to a security threshold of 3/4 plus the honesty of an
additional special player it is possible to obtain optimal latency. Nevertheless,
the lightning network is currently the only option that readily interoperates with
the Bitcoin blockchain.

3 The specification available online is a more descriptive reference for the inner work-
ings of the protocol, see https://github.com/lightningnetwork/lightning-rfc/
blob/master/02-peer-protocol.md. See also the raiden network that implements
Lightning over Ethereum, https://raiden.network.

2

https://github.com/lightningnetwork/lightning-rfc/blob/master/02-peer-protocol.md
https://github.com/lightningnetwork/lightning-rfc/blob/master/02-peer-protocol.md
https://raiden.network


Despite the importance of the lightning network for low latency payments
over Bitcoin there is still no work so far providing a thorough formal security
analysis. This is a dire state of affairs given the fact that the protocol is actually
currently operational4 and its complexity makes it difficult to extract precise
statements regarding the level of security it offers.
Our Results.We present the first, to our knowledge, complete security analysis
of the lightning network in the universal composition (UC) setting. We model
the payment overlay that the lightning network provides as an ideal function-
ality and we demonstrate how it can be implemented in a hybrid world which
assumes a global ledger functionality. Our treatment is general and does not
assume any specific implementation for the underlying ledger functionality. The
“paynet” functionality that we introduce abstracts all the salient security fea-
tures achieved by the lightning network. We subsequently describe the whole
lightning protocol in this setting and we prove that it realises our paynet func-
tionality under standard cryptographic assumptions; the security guarantees of
the functionality reflect specific environmental conditions regarding the avail-
ability of the honest parties to poll the status of the network. In more details
our results are as follows.

1. We present the FPayNet functionality which abstracts the syntax and security
properties that are provided by the lightning network. Using FPayNet, parties
can open and close channels, forward payments along channel paths in the
network as well as poll its status. Importantly, the functionality keeps track
of all the off-chain and on-chain balances of the parties registered and ensures
that when a channel closes the on-chain balances are in line with the off-chain
balances. In order to handle adversarial deviations in multi-hop payments,
the functionality permits the adversary to determine the outcome of each
payment by choosing either one of the following options (i) let it go through
as requested, (ii) charge it to an adversarial party along the path, (iii) charge
it to negligent honest party along the path. This last outcome is a crucial
characteristic of the security that is provided by the lightning network to
its participants: honest parties are expected to poll the functionality at a
certain specific rhythm that corresponds to their level of involvement in the
network and the properties of the underlying ledger. If a party misses that
requirement it is identified as negligent by the functionality and may lose
funds.

2. We identify for the first time the exact polling requirements that are im-
posed by the lightning network to the honest parties that are participating
so that they do not lose funds as a function of the underlying parameters
of the ledger functionality over which the lightning network is overlaid. We
describe our FPayNet given the global ledger functionality defined in [10], and
further refined in [11], for which we know already that is realised by the Bit-
coin blockchain. The functionality provides explicit security guarantees with
respect to consistency and liveness which in turn impact the guarantees pro-
vided by FPayNet. The polling requirements for each party are two-fold: (i)

4 For current deployment statistics see e.g., https://1ml.com/statistics.

3

https://1ml.com/statistics


the first type of polling refers to monitoring for closures of channels that the
party is one of the end-points and is specified by the user chosen parameter
delay, (ii) the second type of polling refers to monitoring for specific events
related to receiving and relaying payments; in particular for each payment
that a party acts as an intermediary, polling should happen twice within
the window of time when the chain in the view of the party advances from
blockheight h to blockheight h′ − a, where h, h′ are two blockheight param-
eters specified in the particular payment path, and a is a (derived) ledger
parameter which is the upper bound to the number of blocks that may be
finalised in the ledger from the time a certain transaction is emitted to the
time it becomes finalised (i.e. it is included in a block in the “stable” part
of the ledger). Moreover, the two pollings should be separated by a time
window that allows the chain to grow by at least a blocks.

3. We provide a complete pseudocode description of the lightning network pro-
tocol ΠLN and we prove that indeed it realises FPayNet under a specific set of
cryptographic assumptions. In order to express ΠLN in a way that is succinct
we identify a number of underlying cryptographic primitives that have been
used in the specification of the lightning network in a non-black-box fash-
ion and without reference. Interestingly, while some of these cryptographic
primitives are standard (they include a PRF, a Digital Signature scheme
and an Identity Based Signature scheme) there is one additional primitive
that is slightly less standard and we call combined digital signature. A com-
bined digital signature is a special case of an asymmetric two-party digital
signature primitive (e.g., see [12] and references therein) with the charac-
teristic that one of the two parties, the shareholder, generates and stores
a share of the signing key, while the public-key of the combined signature
is determined non-interactively based on public-key information produced
by both two parties. Issuing signatures requires the availability of the share
which is verifiable given the public information provided by the shareholder.
We formalise the combined digital signature primitive and show that the
construction lying within the specification of lightning is realising it under
standard cryptographic assumptions. In summary, the realisation of FPayNet
is achieved assuming the security of the underlying primitives (which in turn
can be based on EC-DLOG and the Random Oracle model).

Related Work. A first suggestion for building a unidirectional payment chan-
nel appeared in [13]. Bidirectional payment channels were developed in [14] and,
of course as part of the lightning network [8]. Subsequent work on the topic dealt
with either improving payment networks by utilising more expressive blockchains
such as Ethereum [15], hardward assumptions, see e.g., [16], or extending its func-
tionality beyond payments, to smart contracts, [17] or finally enhancing their
privacy, see e.g., [18,19,20]. Additional work looked into developing supporting
protocols for the payment networks such as rebalancing [21] or finding routes in
a decentralised fashion [22,23]. With respect to idealising the payment network
functionality in the UC setting, a number of previous papers [24,18,17,15] pre-
sented ideal functionalities abstracting the concept. The fundamental advantage

4



of our approach however here is that, for the first time, we present a payment
network functionality that interoperates with a global ledger functionality for
which we know, in light of the results of [10], that is realisable by the Bitcoin
blockchain and hence also reflects the actual parameters that can be enforced
by the implementation (in contrast, previous work utilised “too idealised” ledger
functionalities for which it is unknown whether they can be realised). See Ap-
pendix A for more details.
Organisation. In section 2 we present preliminaries for the model we employ
and the relevant cryptographic primitives. In Section 5 we present an overview of
the lightning network. Our payment network functionality is given an overview
description in Section 4. Our abstraction of the core lightning protocol is pro-
vided in Section 5. We give more details about the combined digital signature
primitive in Section 6. Finally, in Section 7 we provide an overview of the se-
curity proof. In the appendix, first we give more details on the preliminary
primitives, specifically in Sections B,C,D we discuss digital signatures, identity
based signatures and pseudorandom functions. Subsequently in Section E we go
into more details about combined digital signatures. The transaction structure
that is assumed to be provided by the underlying distributed ledger is discussed
in Section F. The paynet functionality is presented in detail in Section G. The
complete description of protocol ΠLN is presented in Section I. The ledger func-
tionality is presented in Section J and finally, the security proof is presented in
Section K.

2 Preliminaries

In this section we will give a brief overview of the tools and frameworks that we
use in this work.
Universal Composability framework. In simulation-based security, crypto-
graphic tasks are defined via an ideal “functionality” F , which can be thought
of as an uncorruptible entity that gets the inputs of all parties and returns the
expected outputs while also interacting with the adversary in a prescribed man-
ner. In this way, the functionality expresses the essence of a cryptographic task
and its security features. A protocol Π realises the functionality F if for any
real world adversary we can define a “simulator” S, acting as an ideal world
adversary, such that any environment cannot distinguish between the real world
and the ideal world executions. Albeit a powerful tool, simulation-based security
only works when a single instance of the protocol is run in isolation. However,
real-world systems almost always run several programs concurrently, which fur-
thermore may run different instances of the same protocol. To facilitate this in
the Universal Composability [25] framework it is possible to analyse a single in-
stance of the protocol and then take advantage of a generic composition theorem
to infer the security of the protocol more broadly. This is achieved by allowing
arbitrary interactions between the environment and the real-world adversary.
Hybrid functionalities used. Both our main protocol and the corresponding
functionality use GLedger [10,11] as a hybrid. GLedger formalizes an ideal dis-

5



tributed append-only data structure akin to a blockchain. Any participating
party can read from GLedger, which returns an ordered list of transactions. Fur-
thermore parties can submit new transactions which, if valid, will be added to
the ledger at the discretion of the adversary, but necessarily within a predefined
time window. This property is called liveness. Once a transaction is added to the
ledger, it becomes visible to all parties at the discretion of the adversary, but
within another predefined time window, and cannot be removed or reordered.
This is called persistence. The exact definition can be found in Appendix J.

Furthermore, GLedger needs two more functionalities: Gclock and F∆N-MC. Gclock
models the notion of time. Every participating party can request to read the cur-
rent time (which is initialized to 0) and inform Gclock that her round is over.
Gclock increments the time by one once all parties have declared the end of their
round. F∆N-MC provides an abstraction of the network. A party can send F∆N-MC
a message to be multicast to all other participants of the network. A party can
also fetch its new messages from F∆N-MC. F∆N-MC makes a message available to be
fetched immediately after its arrival, but the adversary may delay the arrival for
up to ∆ rounds. A can choose different delays for different players and reorder
messages. Additionally, he has the power to send his own messages to selected
subsets of players.

The protocol and functionality defined in the current work do not make
direct use of Gclock or F∆N-MC. We therefore omit these two in the statements
of Lemmas 4-8 and Theorem 1 for simplicity of notation; they should normally
appear as hybrids along with GLedger. Their exact definition can be found in
Appendix J. We also note that GLedger and Gclock are global functionalities [26],
whereas FPayNet and F∆N-MC are not.
Transaction structure. GLedger does not define what is a valid transaction,
but leaves it as a system parameter. Importantly, no notion of coins is built in
GLedger. We therefore specify a valid transaction, closely following concepts put
forth in Bitcoin [2], but avoiding specifying the entire Bitcoin script.

At a high level, every transaction consists of inputs and outputs. Each output
has an associated value in coins and a number of “spending methods”. A spending
method specifies the exact requirements for spending the output. Each input
must be connected to exactly one output and satisfy one of its spending methods.

Transactions in GLedger form a DAG. A new transaction is valid only if each
of its inputs correctly spends an output with no other connected input and
the sum of the values of its outputs does not exceed the sum of the values of
the outputs connected to its inputs. We refer the reader to Appendix F for a
complete overview.
Cryptographic Primitives. In the Lightning Network specification, a custom
scheme for deriving keys is used. Its syntax and security aims closely match
those of previously studied Identity Based Signature schemes [27,28], thus we
use the latter to abstract away the complexity of the construction and highlight
the security requirements it satisfies. We slightly modify previous IBS schemes
by adding an algorithm that, on input of the public parameters mpk and a label
l, returns the verification key pkl. Such an IBS scheme provides 5 algorithms:

6



– (mpk,msk)← Setup(1k): master keypair generation
– (pkl, skl)← KeyDer(mpk,msk, l): keypair derivation with label l
– pkl ← PubKeyDer(mpk, l): verification key derivation with label l
– σ ← SignIBS(m, skl): signature generation with signing key skl
– {0, 1} ← VerifyIBS(σ,m, pkl): signature verification

We refer the reader to [28] for more details. Other cryptographic primitives used
are digital signatures and pseudorandom functions, see Sections B, C, D. Finally,
a less common two-party cryptographic primitive is employed that we formalise
as combined digital signatures, see Section 6.

3 Lightning Network high level overview

Two-party channels. The aim of LN is to enable fast and cheap transactions
that do not have to be added to the blockchain, without compromising secu-
rity. Specifically no additional trust between counterparties is assumed. This is
achieved in the following way: Two parties, Alice and Bob, that have recurring
monetary exchanges create one on-chain transaction that locks up some funds,
known as the “funding transaction”. This transaction is funded by one of the
two parties and has a 2-of-2 multisig output, which needs the signatures of both
counterparties by their “funding” secret keys in order to be spent. Before ac-
tually submitting this transaction though, both parties individually ensure that
they hold a transaction that spends the 2-of-2 funding output in a way that gives
the funds to the funder, along with the signature of this transaction with the
counterparty’s funding key. These two transactions (one for each counterparty)
are called “commitment transactions”. Each party can broadcast her “local”
commitment transaction and has signed the “remote” commitment transaction,
which is the one held by the counterparty.

Every time they want to make a payment to each other, they exchange a
sequence of messages (that include specially crafted signatures) that have two
effects. Firstly, a new pair of commitment transactions, along with their signa-
tures by the funding keys, is created. Each of these transactions ensures that,
if broadcast, each party will be able to spend the appropriate share from the
coins contained in the funding output. Secondly, the two old commitment trans-
actions are revoked. This ensures that no party can close a channel using an old
commitment transaction which may be more beneficial to her than the latest
one.

Invalidating past commitment transactions requires some care. The reason
is that it is impossible to actually make past commitment transactions invalid
without spending the funding output; however, spending it would need an on-
chain transaction for each channel update, thus essentially defeating the purpose
of LN. The following idea is leveraged instead: If Alice broadcasts an old commit-
ment and Bob sees it, he can punish Alice by taking all the money in the channel.
Therefore Alice is technically able to broadcast an old commitment transaction,
but has no financial benefit in doing so. At the same time this imposes the re-
quirement that parties are vigilant about observing the blockchain — see below

7



when we talk about time-locks and how they facilitate a time window within
which parties should react.

The punishing mechanism operates as follows. Suppose Alice considers post-
ing her old local commitment transaction which has an output that carries her
old share of the funds. This output can be spent in two ways: either with a
signature by Alice’s “delayed payment” secret key which is a usual ECDSA key,
or with a signature by Bob’s “revocation” secret key, which is also an ECDSA
key, but with an additional characteristic that we will explain soon. Thus, if
Alice broadcasts an old commitment transaction, Bob will be able to obtain her
funds by spending her output using his “revocation” key. This privilege of course
opens the possibility for Bob to abuse it (in particular, when a channel is closed
— see below — Bob may steal Alice’s funds by using such revocation key) and
hence this side effect should also be carefully mitigated. The mitigation has the
following form. At the time of creation of a new commitment, both parties will
know Bob’s “revocation” public key, but no party knows its corresponding secret
– the key can only be computed by combining one secret value that Alice knows
and one secret value that Bob knows. Alice therefore can prevent Bob from us-
ing his revocation key until she sends this secret value to him. As a result, Alice
will send the secret value to Bob only after the new commitment transaction is
built and signed. Thus Bob cannot abuse his ability to use the revocation key
on a commitment transaction before this transaction is revoked. We note that
the underlying cryptographic mechanism that enables such “revocation keys” is
not straightforward and, as part of our contributions, we formalise it as a new
two-party cryptographic primitive. We call the primitive “combined signature”
and we prove that the construction hidden in the LN implementation realizes it
in the random oracle model under the assumption that the underlying digital
signature scheme is secure in Appendix E.

The last element needed to make updates secure is the so called “relative
timelock”. If Alice broadcasts a commitment transaction, she is not allowed to
immediately spend her funds with her “delayed payment” key. Instead, she has
to wait for the transaction to reach a pre-agreed block depth (the relative time-
lock, hardcoded in the output script of the commitment transaction) in order
to give some time to Bob to see the transaction and, if it does not correspond
to the latest version of the channel, punish her with his “revocation” key. This
avoids a scenario in which Alice broadcasts an old commitment transaction and
immediately spends her output, which would prevent Bob from ever proving that
this commitment was old.

Lastly, if Alice wants to unilaterally close a channel, all she has to do is
broadcast her latest local commitment transaction (the only one that is not
revoked) and wait for the timelock to expire in order to spend her funds. The
LN specification allows for cooperative channel closure which avoids the need
to wait for the timelock, but in the current work this last type of closure is not
considered.

As mentioned time locks provide specific time windows within which both
parties have to be vigilant in order to punish a misbehaving counterparty who

8



broadcasts an old commitment transaction. This means that parties have to be
regularly online to safeguard against theft. LN makes it possible to trustlessly
outsource this, but this mechanism is not analyzed in the current work.

Multi-hop payments. Having funds locked down for exclusive use with a par-
ticular counterparty would be a serious limitation. LN goes beyond that by
allowing multi-hop payments. In a situation where Alice has a channel with Bob
and he has another channel with Charlie, it is possible for Alice to pay Charlie
off-chain by leveraging Bob’s help. Remarkably, this can be achieved without
any one party trusting any of the other two. One can think of Alice giving some
“marked” money to Bob, who in turn either delivers it to Charlie or returns it
to Alice – it is impossible for Bob to keep the money. It is also impossible for
Alice and Charlie to make Bob pay for this transaction out of his pocket.

We will now give an informal overview of how this counterintuitive dynamic
is made possible. Alice initiates the payment by asking Charlie to create a new
hash for a payment of x coins. Charlie chooses a random secret, hashes it and
sends the hash to Alice. Alice promises Bob to pay him x in their channel if
he shows her the preimage of this particular hash within a specific time frame.
Bob makes the same promise to Charlie: if Charlie tells Bob the preimage of the
same hash within a specific time frame (shorter than the one Bob has agreed
with Alice), Bob will pay him x in their common channel. Charlie then sends
him the preimage (which is the secret he generated initially) and Bob agrees to
update the channel to a new version where x is moved from him to Charlie.
Similarly, Bob sends the preimage to Alice and once again Alice updates their
channel to give Bob x coins. Therefore x coins were transmitted from Alice to
Charlie and Bob did not gain or lose anything, he just increased his balance
in the channel with Alice and reduced his balance by an equal amount in the
channel with Charlie.

This type of promise where a preimage is exchanged for money is called
Hash TimeLocked Contract (HTLC). It is enforceable on-chain in case the payer
does not cooperatively update upon disclosure of the preimage, thus no trust is
needed. In the previous example with Alice, Bob and Charlie, two HTLCs were
signed and fulfilled for the payment to go through and the whole interaction
was completely off-chain. Two updates happened in each channel: one to sign
the HTLC and one to fulfill it. The time frames were chosen so that every
intermediary has had the time to learn the preimage and give it to the previous
party on the path.

Direct payments are also carried out using HTLCs.

LN gives the possibility for intermediaries to charge a fee for their service, but
such fees are not incorporated in the current analysis. Furthermore, LN leverages
the Sphinx onion packet scheme [29] to increase the privacy of payments, but
we do not formaly analyze the privacy of LN in this work – we just use it in our
protocol description to syntactically match the message format used by LN.

9



4 Overview of FPayNet

One of our contributions is the specification of FPayNet (Appendix G) a func-
tionality that describes the functional and security guarantees given by an ideal
payment network. The central aim of FPayNet is opening payment channels,
keeping track of their state, updating them according to requested payments
and closing them, as requested by honest players, all in a secure manner. In par-
ticular, the three main messages it can receive from Alice are (openChannel),
(pay) and (closeChannel).

When FPayNet receives (openChannel, Alice, Bob, x, tid) from Alice, it
informs S of E ’s intention to create a channel between Alice and Bob where
Alice owns x coins. When it receives (pay, Bob, x,−−→path, receipt) from Alice,
it informs S that E asked to perform a multi-hop payment of x coins from Alice
to Bob along the −−→path. As expected, when FPayNet receives (closeChannel,
receipt, tid) from Alice, it leaks to S the fact that E wants to close the relevant
channel.

In order to provide security guarantees, there are various moments when
FPayNet verifies whether certain expected events have actually taken place. A
number of messages prompt FPayNet to read from GLedger and perform these
checks. In the actual implementations of LN these checks are done periodically
by a polling daemon. Such checks are done by FPayNet in the following cases:
– On receiving (poll) by Alice, FPayNet asks GLedger for Alice’s latest ΣAlice

and verifies that no bad events have happened. In particular, FPayNet halts
if any of Alice’s channels has been closed maliciously with a transaction at
height h and, even though Alice has polled within [h, h+delay(Alice)−1],
she did not manage to punish the counterparty. Refer to lines 5 and 10 of
Fig. 16 for more details. If FPayNet does not halt, it leaks to S the polling
details (including the identity of the poller and the state of the ledger in
their view).

– FPayNet expects S to send a (resolvePays, charged) message that gives
details on the outcome of one or more multi-hop payments that include the
identity of the party that is charged. Moreover, for each resolved payment,
the message includes two expiry values in block height: OutgoingCltvExpiry,
which is the largest block in which the charged party could claim money from
the previous hop (closer to the payment initiator) and IncomingCltvExpiry,
which is the smallest block in which the charged party could claim money
from the next hop (closer to the payment receiver). FPayNet checks that for
each payment the charged party was one of the following: (a) the one that
initiated the payment, (b) a malicious party or (c) an honest party that is
negligent. The latter case happens when the honest party either:
1. did not poll in time to catch a malicious closure (similarly to the check

performed when a poll message is handled, as described above) (Fig. 12,
line 14) or

2. did not poll twice while the block height in the view of the player was in
[OutgoingCltvExpiry, IncomingCltvExpiry−(2 + r) windowSize] with
a distance of at least (2 + r) windowSize between the two polls or

10



3. did not enforce the retrieval of the funds lost as a result of this pay-
ment when the chain in her view had height IncomingCltvExpiry −
(2 + r) windowSize (Fig. 12, l";"""date"",""2019-07-03T17:30:03Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2019-07-03T17:30:03Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017) kpathsea version 6.2.3""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2019-07-03T17:30:03Z""
""created"",""2019-07-03T17:30:03Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-07-03T17:30:03Z""
""resourceName"",""Lightning%20Network%20-%20A%20Composable%20Security%20Treatment.pdf""
""Author"",""""
""producer"",""pdfTeX-1.40.18""
""pdf:docinfo:producer"",""pdfTeX-1.40.18""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""2"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""8"",""2"",""17"",""4"",""3"",""10"",""20"",""12"",""18"",""8"",""16"",""2"",""0"",""0"",""0"",""0"",""6"",""3"",""0"",""2"",""0"",""0"",""0"",""0"",""4"",""0"",""0"",""4"",""6"",""6"",""4"",""20"",""8"",""1"",""9"",""1"",""0"",""2"",""4"",""9"",""22"",""19"",""2"",""0"",""0"",""0"",""0"",""0"",""2"",""0"",""2"",""0"",""57"",""4"",""0"",""0"",""0"",""0"",""3"",""0"",""0"",""0"",""2"",""0"",""0"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2019-07-03T17:30:03Z""
""Last-Modified"",""2019-07-03T17:30:03Z""
""dcterms:modified"",""2019-07-03T17:30:03Z""
""title"",""""
""Last-Save-Date"",""2019-07-03T17:30:03Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2019-07-03T17:30:03Z""
""meta:save-date"",""2019-07-03T17:30:03Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017) kpathsea version 6.2.3""
""Content-Length"",""920417""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""84""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""2267"",""2868"",""2825"",""2882"",""2673"",""2812"",""2618"",""2759"",""2562"",""2579"",""2569"",""2615"",""2755"",""2705"",""2336"",""1753"",""1833"",""1174"",""1056"",""1202"",""850"",""1273"",""1380"",""1005"",""981"",""1169"",""1411"",""993"",""1584"",""1245"",""931"",""1113"",""1616"",""326"",""1540"",""911"",""1567"",""701"",""832"",""1028"",""1170"",""1015"",""1097"",""1193"",""1273"",""1115"",""880"",""1854"",""1865"",""1031"",""912"",""879"",""838"",""1543"",""1979"",""2428"",""1979"",""1715"",""2135"",""1335"",""1123"",""1667"",""1875"",""2707"",""711"",""1643"",""1755"",""2568"",""2873"",""2726"",""2639"",""2891"",""1445"",""2843"",""2813"",""1466"",""1629"",""1586"",""2121"",""1608"",""2060"",""3016"",""3014"",""901""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-07-03T17:30:03Z""
";https://scholar.google.ch/scholar?start=860&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098809-202;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;[PDF][PDF] PROCESS: Privacy-Preserving On-Chain Certificate Status Service;M Jia, K He, J Chen, R Du, W Chen, Z Tian, S Ji ; nesa.zju.edu.cn;;"… In this paper, we present PROCESS, an online privacy-preserving on-chain certificate status service

based on the blockchain architecture, which can ensure decentralized trust and provide privacy

pro- tection for clients … blockchain nodes via traditional consensus …";;;[PDF] zju.edu.cn;https://nesa.zju.edu.cn/download/PROCESS%20Privacy-Preserving%20On-Chain%20Certificate%20Status%20Service.pdf;"
PROCESS: Privacy-Preserving On-Chain
Certificate Status Service

Meng Jia1, Kun He1, Jing Chen1, Ruiying Du1, Weihang Chen1, Zhihong Tian2, Shouling Ji3
1School of Cyber Science and Engineering, Wuhan University, Wuhan, China

2Guangzhou University, Guangzhou, China
3Zhejiang University, Hangzhou, China

Email:{jiameng, hekun, chenjing, chenweihang}@whu.edu.cn, duraying@126.com, tianzhihong@gzhu.edu.cn, sji@zju.edu.cn

Abstract—Clients (e.g., browsers) and servers require public
key certificates to establish secure connections. When a client
accesses a server, it needs to check the signature, expiration time,
and revocation status of the certificate to determine whether the
server is reliable. The existing solutions for checking certificate
status either have a long update cycle (e.g., CRL, CRLite) or
violate clients’ privacy (e.g., OCSP, CCSP), and these solutions
also have the problem of trust concentration. In this paper,
we present PROCESS, an online privacy-preserving on-chain
certificate status service based on the blockchain architecture,
which can ensure decentralized trust and provide privacy pro-
tection for clients. Specifically, we design Counting Garbled
Bloom Filter (CGBF) that supports efficient queries and Block-
Oriented Revocation List (BORL) to update CGBF timely in the
blockchain. With CGBF, we design a privacy-preserving protocol
to protect clients’ privacy when they check the certificate statuses
from the blockchain nodes. Finally, we conduct experiments and
compare PROCESS with another blockchain-based solution to
demonstrate that PROCESS is suitable in practice.

I. INTRODUCTION

Public Key Infrastructure (PKI) plays an important role
in today’s Internet, in which Certificate Authorities (CAs)
manage public key certificates for authentication and estab-
lishment of secure connections. For example, in the Hypertext
Transfer Protocol Secure (HTTPS), a browser authenticates
the accessed server by the server’s certificate, and establishes
a TLS (Transport Layer Security) [1] connection with that
server.

However, the status of a certificate authorized by a CA
may become invalid in various circumstances, even before the
expiration time set by the CA [2]. For example, the private
key of the server (which corresponds to the public key in the
server’s certificate) is compromised. In this case, CAs need to
revoke the invalid certificates and publish the revocations to
clients (e.g., browsers). Otherwise, clients may still consider
those certificates as valid, and attackers can perform man-
in-the-middle attacks accordingly, such as tampering with
information and forging identity [3].

The most common mechanisms for publishing revocations
are Certificate Revocation List (CRL) [2] and Online Certifi-
cate Status Protocol (OCSP) [4]. In CRL, CAs periodically
push a large list of revoked certificates to clients for checking
certificate statuses. However, due to the high update latency
and growing network overhead, CRL may be superseded by a
more efficient alternative, OCSP. In OCSP, a client can run an

on-demand query for a single certificate’s status to an OCSP
server, rather than downloading the entire list of the revoked
certificates. Unfortunately, there are two urgent problems in
existing OCSP mechanisms: trust concentration [5] and pri-
vacy leakage. Trust concentration concerns the compromise
of the centralized OCSP server, in which incorrect certificate
statuses may then be returned to clients, while privacy leakage
refers to the problem that an OCSP server can learn which
server (e.g., the website) the querying client is interested in
from its on-demand certificate status query.

Our goal is to solve above two problems in OCSP. The
blockchain technology, famous for having both distributed
storage and anonymity features, seems an ideal solution.
However, applying blockchain in this field is not trivial due
to the following challenges. First, the practical application is
heavily constrained because of the limited block size, when
confronting massive data storage. Existing solutions based on
the blockchain technology, such as CertLedger [6], ECBC [7]
and CertChain [8], encode all the revoked certificates into a
data structure (e.g., Merkle Hash Tree (MHT), MPT-Chain,
and Bloom filter), and store this structure in a block. Due to
the huge number of certificates (Let’s Encrypt [9] had issued
over 538 million certificates for 223 million domain names
by January 2019), even those highly compact data structures
still cannot be stored in a relatively small block and are
inefficient in practice. Therefore, we need to design a suitable
on-chain data structure when solving the trust concentration
problem through the blockchain architecture. Second, the
privacy leakage problem [10] is more subtle when we apply
the blockchain technology in OCSP. Due to the sensitivity of
certificates, solutions need to be designed in the form of an
alliance chain, which means that only OCSP servers act as
the blockchain nodes. Clients who check certificate statuses
do not participate in the blockchain, and thus the anonymity
feature of blockchain cannot protect clients’ privacy [8].
Some solutions (e.g., CertLedger [6]) employ OCSP Must
Staple mechanism [11, 12] to protect privacy. However, OCSP
Must Staple requires a custom extension for established and
standardized certificates, and thus it is not widely adopted [13].
Third, existing solutions for privacy protection (e.g., Private
Information Retrieval (PIR) [14]) has a high latency because
of their complex calculations [15]. Clients may be reluctant to
check the certificate status due to the poor efficiency and high



latency [16].
In this paper, we propose a PRivacy-preserving On-chain

CErtificate Status Service, called PROCESS. Specifically,
CAs upload the information of the revoked certificates to
blockchain nodes, which update global revocation statuses by
data structures designed for online revocation status query.
A client queries the blockchain nodes for the revocation
status through a privacy protection protocol, where the client
can set parameters to balance privacy protection and latency
requirements. The main contributions are as follows.
• Towards the limited block size challenge, we propose an

on-chain data structure called Block-Oriented Revocation
List (BORL), which is to accommodate Counting Gar-
bled Bloom Filter (CGBF) and update CGBF timely in
the blockchain architecture, where CGBF stores global
revocation statuses for efficient query and supports both
insertion and deletion.

• Regarding the privacy leakage and high latency chal-
lenges, we propose an efficient privacy-preserving on-
chain certificate status check protocol. Moreover, clients
can set parameters in the protocol to balance privacy
requirements and latency limitations.

• We conduct experiments and analyze the performance
of PROCESS. Compared with the existing work [8],
PROCESS has advantages in terms of space cost, privacy,
and latency.

This paper is organized as follows. In Section II, we
describe the models, design goals, and building blocks. Then,
we present CGBF and BORL in Section III and PROCESS
in Section IV. In Section V and Section VI, we analyze
the security and evaluate the performance of our proposal,
respectively. Finally, we review related work in Section VII
and conclude in Section VIII.

II. PRILIMINARIES

A. System Model

PROCESS consists of four entities: certificate authority
(CA), server, client, and blockchain node, as shown in Fig. 1.
• A CA is responsible for authorizing, updating, and re-

voking public key certificates for servers.
• A server (e.g., a website) publishes information or pro-

vides network services to clients.
• A client (e.g., a browser) checks the validity of the

certificates before it establishes secure connections (e.g.,
TLS connections) with servers.

• Blockchain nodes are designed to maintain a distributed
ledger storing the certificate statuses from CAs and reply
to the certificates’ status queries from clients.

B. Threat Model

From the practical perspective, we assume that the capabil-
ities of an adversary are as follows.
• The adversary can eavesdrop, tamper, and forge messages

between communicating entities in an untrusted network.

Establish secure 
connections

Upload revocation statuses Check certificate statuses

¡¡¡

Blockchain Nodes • Update revocations
• Update BORL
• Maintain CGBF
• Respond to query

Authorize, update, 
revoke certificates

CAs Servers Clients

Fig. 1. Deployment of PROCESS

• The adversary can control a number of blockchain nodes,
but cannot control more than 51% computing power in
blockchain.

• The adversary cannot obtain the chameleon hash private
keys of the blockchain nodes, and cannot sign the revo-
cation information or calculate the random number of the
chameleon hash without the entity’s private key.

C. Design Goals

We aim to design a certificate status service that satisfies
the following goals.
• Timeliness. After a CA uploads the revoked information

to the blockchain nodes, the nodes can update the global
information in time.

• Privacy. The client does not disclose the information
of the server that it plans to access when querying the
certificate status.

• Compatibility. PROCESS can be compatible with cur-
rent PKI architecture without any custom extensions for
certificates.

D. Chameleon Hash

A chameleon hash function is a hash function that allows
one to find arbitrary collisions with a trapdoor [17, 18].
We employ the following chameleon hash scheme CH =
(Gen,ReHash,Hash,Check,Adapt).
• Gen(1λ). With the input of the security parameter λ, this

algorithm generates a group G of prime order p with
a generator g. Then, it chooses a random x ∈ Zp and
outputs the private key sk ← x and public key pk ← gx.

• ReHash(pk,msg, r). With the input of the public key
pk, a message msg, and a randomness r, this algorithm
outputs the hash h← gmsgpkr.

• Hash(pk,msg). With the input of the public key pk and
a message msg, this algorithm outputs a randomness r ∈
Zp and the hash h← ReHash(pk,msg, r).

• Check(pk,msg, r, h). With the input of the public key
pk, a message msg, a randomness r, and a hash h, this
algorithm outputs 1 if h = gmsgpkr and 0 otherwise.

• Adapt(sk,msg, r, h,msg′). With the input of the private
key sk, a message msg, a randomness r, a hash h,
and a new message msg′, this algorithm outputs a new
randomness r′ ← (msg + r · sk −msg′)/sk.



¡¡¡¡¡¡
Merkle_rootMerkle_root

Prev_hash Timestamp

Merkle_root

Prev_hash Timestamp
¡¡¡¡¡¡

Merkle_rootMerkle_root

Prev_hash Timestamp

Merkle_root

Prev_hash Timestamp

Merkle_rootMerkle_root

Prev_hash Timestamp

Merkle_root

Prev_hash Timestamp
¡¡¡

Tx(0xcc)
type

addrp

addrn

rand

hashs

insertion
height1

(2,s2),(i-1,si-1),(i,si), date3

0xbb
null

r2

hash2

Tx(0xbb)
type

addrp

addrn

rand

hashs

deletion
time0

(0,3,m-1), 0xaa

0xaa
0xcc

r1'
hash1

Tx(0xaa)
type

addrp

addrn

rand

hashs

insertion
height0

(0,s0),(3,s3),(m-1,sm-1), date1

(1,s1),(i,si),(m-1,sm-1), date2

0x00
0xbb

r0'
hash0

¡¡¡

BORL

CGBF

hashc hashc0 hashc hashc1 hashc hashc2

update update update

share

counter

s0 s1 0 s3 … 0 si 0 sm-1

1 1 0 1 … 0 1 0 2

x1 x2

…

…

0 s1 0 0 … 0 si 0 sm-1

0 1 0 0 … 0 1 0 1

x2

…

…

0 s1 s2 0 … si-1 si 0 sm-1

0 1 1 0 … 1 2 0 1

x2

…

…

x3

Fig. 2. An illustration of BORL and CGBF where k = 3. First, we insert x1 = s0 ⊕ s3 ⊕ sm−1, x2 = s1 ⊕ si ⊕ sm−1 into CGBF and generate a
BORL node in a transaction addressed by 0xaa. Then, we delete x1 from CGBF in 0xbb, and insert x3 = s2 ⊕ si−1 ⊕ si into CGBF in 0xcc.

E. Digital Signature

Let DS = (Gen, Sign,Verify) be a digital signature scheme,
such as RSA. The key generation algorithm Gen(1Îť) takes as
input a security parameter Îť, and outputs a pair of public-
private keys (pk, sk). The signing algorithm Sign(sk,msg)
takes as input the private key sk and a message msg,
and outputs a signature sig. The verification algorithm
Verify(pk, (msg, sig)) takes as input the public key pk and
a message-signature pair (msg, sig), and outputs a bit where
0/1 indicates that the message-signature pair is invalid/valid.

III. REVOCATION STATUS STRUCTURE

We propose a data structure for storing and retrieving
certificate statuses in the blockchain architecture. Roughly
speaking, the revoked certificates are encoded into a structure,
called Counting Garbled Bloom Filter (CGBF). Then, CGBF
is decomposed into a number of structured pieces for block
storage, called Block-Oriented Revocation List (BORL). The
data structures of CGBF and BORL are shown in Fig. 2.

A. Counting Garbled Bloom Filter

Essentially, retrieving a certificate status is testing whether
a given certificate is in the set of revoked certificates. Garbled
Bloom Filter (GBF) is an efficient data structure for member-
ship testing, whose false positive is negligible compared to
traditional Bloom Filter [19]. Also, inserting new revocation
statuses into GBF does not change existing data. Therefore, it
looks that we can store the insertion into new blocks instead
of rewriting old ones, if we store GBF directly in blocks.
Unfortunately, GBF does not support deletion, which means
that revocation statuses cannot be deleted from GBF when they
are expired. The increasing number of revoked certificates will

quickly reach the upper bound of GBF and cause the time-
consuming reconstruction of GBF.

To support both insertion and deletion, we propose an
updatable data structure, called Counting Garbled Bloom
Filter (CGBF) as shown in Fig. 2. CGBF is an array and
each element consists of a string and a counter. The string
represents a share of a revocation status, and the counter
indicates the number of revoked certificates that use the
share. Formally, a CGBF instance CGBF is parameterized
by (m,n, Îť, k,H). That means CGBF can encode at most
n revoked certificates in an m-length array, and every share
in the array is a Îť-bit string. Every revoked certificate uses
k shares that are located by k independent uniform hash
functions H = {H0, . . . ,Hk−1}, where Hj : {0, 1}∗ →
{0, . . . ,m− 1} (0 ≤ j ≤ k − 1).

For convenience, the i-th (0 ≤ i ≤ m− 1) share/counter in
CGBF are denoted by CGBF [i].share/CGBF [i].counter,
respectively. For any revocation status rs ∈ {0, 1}Ν stored in
CGBF , we have rs =

⊕k−1
j=0 CGBF [Hj(rs)].share.

B. Block-Oriented Revocation List

In general, the size of CGBF will eventually exceed the
capacity of a block. Therefore, we need to design a data
structure that stores CGBF as a number of small pieces and
supports efficient insertion and deletion. A trivial solution
is to divide a CGBF instance by elements. For example,
the first piece of CGBF contains the first two elements
(CGBF [0], CGBF [1]), the second piece contains the third
and fourth elements (CGBF [2], CGBF [3]), so on and so
forth. Unfortunately, this solution is inefficient since revocation
status insertion and deletion will cause the frequent modifica-
tion of all counters, namely rewriting of existing pieces.



To accommodate CGBF in the blockchain architecture, we
design a data structure called Block-Oriented Revocation List
(BORL) as shown in Fig. 2. BORL is a doubly linked list that
every node of the list contains the CGBF update (insertion
or deletion) over a period of time and can be stored in a
transaction on the blockchain. The doubly linked design is to
eliminate the forking of CGBF update. Since deletion needs
the certificates’ expiration time, to avoid traversing the BORL
and improve the efficiency, we also design the BORL state
which is possessed locally by every blockchain node.

Formally, a BORL instance BORL is parameterized by
(u, d, CH, (m,n, Îť, k,H),H). The integers u and d are the up-
per bounds of updated revocation statuses contained in a trans-
action for insertion and deletion, respectively. The chameleon
hash scheme CH (Section II-D) is employed to modify the next
address stored in the transaction on the blockchain to imple-
ment the doubly linked design. The parameter (m,n, Îť, k,H)
describes the CGBF instance stored in BORL. We also use a
cryptographic hash function H : {0, 1}∗ → {0, 1}λ to generate
the digest of the BORL state and CGBF instance.

A BORL node is a seven-tuple (type, update, addrp,
addrn, hs, hc, r). The boolean type determines whether the
update stored in the transaction is for insertion or dele-
tion. The CGBF update is stored in update. More specifi-
cally, if type is insertion, update consists of height and a
number of ((H0(rs), CGBF [H0(rs)].share), . . . , (Hk−1(rs),
CGBF [Hk−1(rs)].share)), daters). The integer height indi-
cates the last block in which the revocation status has been
inserted into CGBF and the revocation status of a revoked
certificate rs =

⊕k−1
j=0 CGBF [Hj(rs)].share is expired after

the timestamp daters. If type is deletion, update consists of
time and a number of ((H0(rs), . . . ,Hk−1(rs)), addrrs). It
indicates that certificates expired before timestamp time are
deleted from CGBF , and the expired revocation status rs is
stored in a transaction addressed by addrrs when inserting.
The integers addrp/addrn represent the previous/next BORL
nodes, respectively. The string hs and hc are the hash value of
the BORL state and CGBF before the update is performed,
respectively. The integer r is used by CH to modify addrn.

We define the BORL state of the instance BORL as
BORL.state= (addrins, addrdel, {datel, rsl, addrrsl}

γ−1
l=0 ).

The addresses addrins/addrdel indicate the transaction ad-
dresses of latest BORL nodes for insertion/deletion, respec-
tively. The array {datel, rsl, addrrsl}

γ−1
l=0 records the infor-

mation of all Îł revoked certificates stored in CGBF , where
the revocation status rsl is expired after the timestamp datel
and addrrsl is the transaction address where rsl is inserted.

IV. PROCESS
A. Overview

We aim to design an online service for storing and retrieving
the revocation statuses of certificates issued in current PKI
systems. To solve the trust concentration problem and the
block size challenge, we adopt the blockchain architecture
along with the proposed BORL structure. Then, the revocation
statuses can be confirmed by and stored on a number of

Algorithm 1 Revocation
1: procedure REVOCATION(certs, C, skDSC )
2: revo← Revoke(certs)
3: sig ← DS.Sign(skDSC , (C, revo))
4: return ((C, revo), sig)

Algorithm 2 Package
1: procedure PACKAGE(pkDSC , C, revo, sig, CGBF )
2: if DS.Verify(pkDSC , ((C, revo), sig)) = 1 then
3: return TransGen((C, revo), sig)

blockchain nodes via traditional consensus. To solve the pri-
vacy leakage problem and the latency challenge, we design an
efficient privacy-preserving certificate status check protocol for
the CGBF structure. Our solution, named PROCESS, consists
of four phases: initialization, certificate revocation, BORL
update, and certificate status check.

B. Initialization

In PKI systems, CAs generate public-private key pairs for
authorizing, revoking, and verifying certificates, which are also
used in our solution to sign revocation information. For the
sake of completeness, those key pairs are generated in the
initialization phase. On the other hand, blockchain nodes need
to prepare essential materials for CGBF and BORL.

CA. A CA C generates a pair of public-private keys
(pkDSC , skDSC ) by DS.Gen(1Îť), where Îť is the security pa-
rameter. Then, the CA publishes the public key pkDSC and
keeps the private key skDSC secret.

Blockchain Node. A blockchain node N generates a pair
of public-private keys (pkCHN , skCHN ) by CH.Gen(1Îť), where
Îť is also the security parameter. Then, the node deploys
a smart contract Confirmation(pkCHN , ¡, ¡) on the blockchain,
which accepts two parameters (see Section IV-D), and keeps
the private key skCHN secret. Finally, the node initializes an
empty CGBF instance CGBF with the global parameters
(m,n, Îť, k,H) and the BORL state of the instance BORL
parameterized by (u, d, CH, (m,n, Îť, k,H),H). Both CGBF
and BORL.state are stored locally on the node.

C. Certificate Revocation

To revoke certificates, a CA generates revocation infor-
mation (Algorithm 1), and a blockchain node records the
information in the blockchain as a transaction (Algorithm 2).

CA. Let certs = {cert0, . . . , certγ−1} be the set of
certificates issued by a CA C that will be revoked, and
Îł be the number of certificates in certs. To revoke those
certificates (Line 2), the CA extracts the expiration time (i.e.,
NotAfter) datecertl from the certificate certl(0 ≤ l < γ)
and generates revocation status rscertl ← H(certl), where
H : {0, 1}∗ → {0, 1}λ is the cryptographic hash function
defined in BORL. The revocation information is revo =
{(datecert0 , rscert0), . . . , (datecertγ−1

, rscertγ−1
)}.

Then, the CA signs the revocation information revo along
with its identity C with its private key skDSC to obtain a



signature sig (Line 3). Finally, the CA sends ((C, revo), sig)
to any blockchain node.

Blockchain Node. When a blockchain node receives
((C, revo), sig) from the CA C, it verifies that whether the
revocation information is valid (Line 2). Then, the node
packages ((C, revo), sig) into a transaction (Line 3) and
broadcasts the transaction in the blockchain network. Finally,
the blockchain node returns the address of the transaction to
CA for revocation transparency [20] once the transaction is
recorded on the blockchain.

D. BORL Update

Transactions of revocation information in the certificate
revocation phase are not directly used for certificate status
query, because they are inefficient and may leak clients’
privacy. Instead, all necessary information is maintained in
BORL in this phase, which includes three kinds of operations:
element insertion, element deletion, and update confirmation.

1) Element Insertion: To support certificate status query,
blockchain nodes collect revocation information from transac-
tions on the blockchain, and insert the revocation information
into the CGBF instance by generating a BORL node of
insertion type. This operation is shown in Algorithm 3.

According to transaction address addrins in BORL.state,
a blockchain node N obtains the height in the BORL node
at addrins, and height is the block height where last in-
sertion stops. The blockchain node traverses the transactions
on the blockchain bc from height-th block, and retrieves the
revocation information revo = {(datecert0 , rscert0), . . . } that
contains at most u revocation statuses. It also records the block
height height′ where the retrieval stops (Line 2).

Before proceeding, the blockchain node takes a snapshot of
current BORL state and CGBF instance by computing the hash
values of BOLR.state (Line 3)/CGBF (Line 4), respectively.
The following steps generate the CGBF update (Line 5-22),
and are performed on a temporary duplicate of BORL.state
and CGBF rather than modifying them (see the update
confirmation operation later in this section). More specifically,
each rscert in revo is mapped into k locations of CGBF
(Line 7-20). If some locations are never used, the blockchain
node keeps one location for generating a special share (Line
12-13 and 20) and fills others with random shares (Line 15). If
there is no unused location (i.e., empty = −1 in Line 19), the
element insertion fails and CGBF needs to be reconstructed.
Then, the CGBF update is update = (height′, list).

To complete the BORL node, the blockchain node obtains
the transaction address of previous BORL node, which is either
addrins or addrdel (Line 23), and computes the random value
of chameleon-hash function (Line 25). Finally, the blockchain
node packages (insertion, update, addrp, ⊥, hs, hc, r) into
a transaction (Line 26) and broadcasts the transaction in the
blockchain network.

2) Element Deletion: To reduce the frequency of CGBF
reconstruction, blockchain nodes delete the expired certificates
from the CGBF instance by generating a BORL node of
deletion type. This operation is shown in Algorithm 4.

Algorithm 3 Element Insertion
1: procedure INSERTION(bc, BORL.state, CGBF, pkCHN )
2: revo, height′ ← GetRS(bc, BORL.state, u)
3: hs ← H(BORL.state)
4: hc ← H(CGBF )
5: list← {}
6: for each item (datecert, rscert) in revo do
7: empty ← −1, share← 0λ, sset← {}
8: for j from 0 to k − 1 do
9: i← Hj(rscert)

10: if CGBF [i].counter = 0 then
11: if empty = −1 then
12: empty ← i
13: CGBF [i].share← 0λ

14: else
15: CGBF [i].share

$← {0, 1}λ

16: CGBF [i].counter ← CGBF [i].counter + 1
17: share← share⊕ CGBF [i].share
18: sset← sset ∪ {(i, CGBF [i].share)}
19: if empty 6= −1 then
20: CGBF [empty].share← share⊕ rscert
21: list← list ∪ {(sset, datecert)}
22: update← (height′, list)
23: addrp ← GetPrev(addrins, addrdel)
24: ins← (insertion, update, addrp,⊥, hs, hc)
25: r ← CH.Hash(pkCHN , ins)
26: return TransGen(ins, r)

According to transaction address addrdel in BORL.state, a
blockchain node N obtains the time that deletion operation has
been processed which is recorded as time in the BORL node
at addrdel. The blockchain node extracts an array array =
{(datel, rsl, addrrsl), . . . } that contains at most d revocation
statuses from BORL.state. It also records the expired time
time′ where the deletion stops (Line 2).

Before proceeding, the blockchain node takes a snapshot of
current BORL state and CGBF instance as in the element in-
sertion operation (Line 3-4). The following operations generate
the CGBF update (Line 5-13) that are also performed on a tem-
porary duplicate of BORL.state and CGBF . More specifi-
cally, for each item in array, the blockchain node computes k
locations and reduces the counter at each location (Line 8-11).
Then, the CGBF update is update = (time′, list).

To complete the BORL node, the blockchain node performs
similarly to the last four steps of the element insertion oper-
ation, where (deletion, update, addrp,⊥, hs, hc, r) is finally
packaged into a transaction and broadcasted in the blockchain
network (Line 14-17).

3) Update Confirmation: In element insertion and deletion,
all operations are performed on the temporary duplicate of
the BORL state and CGBF instance, since the update (i.e.,
insertion and deletion) packaged in the BORL node is not
confirmed in the blockchain network yet. Let the BORL node
containing unconfirmed update be node = (type, update,



Algorithm 4 Element Deletion
1: procedure DELETION(BORL.state, CGBF, pkCHN )
2: time′, array ←GetDS(BORL.state, d)
3: hs ← H(BORL.state)
4: hc ← H(CGBF )
5: list← {}
6: for each item (datel, rsl, addrrsl) in array do
7: iset← {}
8: for j from 0 to k − 1 do
9: i← Hj(rsl)

10: CGBF [i].counter ←CGBF [i].counter − 1
11: iset← iset ∪ {i}
12: list← list ∪ {(iset, addrrsl)})
13: update← (time′, list)
14: addrp ← GetPrev(addrins, addrdel)
15: del← (deletion, update, addrp,⊥, hs, hc)
16: r ← CH.Hash(pkCHN , del)
17: return TransGen(del, r)

addrp,⊥, hs, hc, r) at the transaction addressed by addrn, and
the BORL node at the transaction addressed by addrp be
node∗ = (type∗, update∗, addr∗p,⊥, h∗s, h∗c , r∗). To confirm
the update, addrn needs to be recorded in node∗. Then, all of
the blockchain nodes can apply the update in node to obtain
the latest BORL state and CGBF instant.

To record addrn in node∗ (see Algorithm 5), the blockchain
node N who generated node∗ first verifies whether node is
valid (Line 2). This process is similar to Algorithm 3 and 4
except for GetRS and GetDS. Instead of invoking GetRS and
GetDS, the blockchain node extracts revocation statuses from
the blockchain bc based on the height range (height, height′)
if type = insertion, where height is in the BORL node
at addrins and height′ is in node, and extracts array from
BORL.state based on (time, time′) if type = deletion,
where time is in the BORL node at addrdel and time′ is
in node. Then, the blockchain node replaces ⊥ in node∗ with
the transaction address addrn, and calculates new randomness
r′ (Line 3-6). As a result, the BORL node node∗ = (upd∗, r∗)
is changed to node′ = (upd′, r′), which is broadcasted in the
blockchain network.

For all of the blockchain nodes, they need to verify
node′ before applying the update. To this end, they perform
the smart contract Confirmation(pkCHN , ¡, ¡) with the param-
eters (node∗, node′) (Algorithm 6). First, it calculates the
chameleon hash h of node∗ before modification (Line 2),
and then verifies whether the modified r′ is correct (Line
3). If the smart contract execution result is 1, all of the
blockchain nodes replace node∗ with node′, and update
the state of BORL BORL.state and CGBF with node.
Specifically, they update shares and counters in CGBF
and (addrins, addrdel, {date, rs, addrrs}) according to node.
Otherwise they ignore node and the modification of node∗.

Algorithm 5 Node Modification
1: procedure MODIFICATION(bc, BORL.state, CGBF,
skCHN , node, addrn, node

∗)
2: if Verify(bc, BORL.state, CGBF, node) = 1 then
3: upd∗ ← (type∗, update∗, addr∗p,⊥, h∗s, h∗c)
4: upd′ ← (type∗, update∗, addr∗p, addrn, h

∗
s, h
∗
c)

5: h← CH.ReHash(pkCHN , upd∗, r∗)
6: r′ ← CH.Adapt(skCHN , upd∗, upd′, r∗, h)
7: return (upd′, r′)

Algorithm 6 Update Confirmation
1: procedure CONFIRMATION(pkCHN , node∗, node′)
2: h← CH.ReHash(pkCHN , upd∗, r∗)
3: return CH.Check(pkCH , upd

′, r′, h)

❷Verify sig and date

❼Restore element to get status

❶Return server's cert

❚Send query

❻Return response
Sending queries to blockchain nodes

❸Generate query

Clients Servers Blockchain nodes

❺Calculate a response

❚Send query

❻Return response
❺Calculate a response

Fig. 3. Certificate status check protocol

E. Certificate Status Check

Before a client establishes the secure connection with a
server, the client checks whether the certificate provided by
the server is valid, as shown in Fig. 3.

When a client accesses a server, the server provides the
client with its certificate cert (Step 1). The client verifies the
signature and expired time of cert (Step 2). If the signature is
valid and cert is not expired, the client invokes the revocation
status query protocol (Step 3-7).

In the revocation status query protocol, the client first
generates the query of cert (Step 3). According to the pri-
vacy and latency requirements, the client sets the length of
index range len when querying a share and the number of
blockchain nodes num when answering for each share, and
performs Algorithm 7. For each index i, the client chooses len
successive indexes that contain i (Line 7-8) and computes for
each blockchain node the shares it should retrieve (Line 9-13).
Specifically, the query is {(ij−posj), len, {padj,l}num−1l=0 }k−1j=0

and each ((ij − posj), len, padj,l) is sent to a random (better
not repetitive) blockchain node (Step 4).

When a blockchain node receives ((ij − posj), len, padj,l),
it computes resj,l =

⊕ij−posj+len−1
i=ij−posj ,padj,l[i]=1 CGBF [i].share

(Step 5) and sends resj,l back to the client (Step 6).



Algorithm 7 Query Generation
1: procedure QUERYGEN(m,Îť, k,H,H, cert, len, num)
2: rscert ← H(cert)
3: query ← {}
4: for j = 0 to k − 1 do
5: i← Hj(rscert)
6: target← 0len, pad← 0len, strings← {}
7: pos

$← {0, . . . , len− 1}
8: target[pos]← 1
9: for l from 0 to num− 2 do

10: pad
$← {0, 1}len

11: strings← strings ∪ {pad}
12: target← target⊕ pad
13: strings← strings ∪ target
14: query ← query ∪ {((i− pos), len, strings)}
15: return query

After receiving the responses {resj,l}num−1l=0 for one in-
dex, the client can restore CGBF [Hj(rscert)].share =⊕num−1

l=0 resj,l. Then, the client combines the k shares by
rs′cert =

⊕k−1
j=0 CGBF [Hj(rscert)].share and compares it

with rscert obtained in Algorithm 7 (Step 7). If rs′cert is
equal to rscert, the certificate cert is revoked, otherwise the
certificate is valid.

V. SECURITY ANALYSIS

We show that PROCESS solves the problems in Section I
(i.e., trust concentration and privacy leakage) through the
following theorems. Especially, Theorem 1 claims that the
certificate status cannot be compromised and Theorem 2 states
that the blockchain node cannot learn the certificate queried
by the client.

Theorem 1: Under the threat model in section II-B, CAs and
blockchain nodes c";"""date"",""2021-01-03T05:42:04Z""
""pdf:PDFVersion"",""1.5""
""xmp:CreatorTool"",""Certified by IEEE PDFeXpress at January 3, 2021 05:42:03 ""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""pdfa:PDFVersion"",""A-2b""
""xmpMM:History:Action"",""converted""
""language"",""en""
""dc:format"",""application/pdf; version=""""A-2b"""""",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""Certified by IEEE PDFeXpress at January 3, 2021 05:42:03 ""
""access_permission:fill_in_form"",""true""
""xmpMM:History:When"",""2020-12-30T10:10:58Z""
""pdf:encrypted"",""false""
""xmp:CreateDate"",""2020-12-29T14:45:56Z""
""modified"",""2021-01-03T05:42:04Z""
""xmpMM:History:SoftwareAgent"",""Preflight""
""pdf:hasMarkedContent"",""false""
""xmpMM:History:InstanceID"",""uuid:5da014a8-e90f-42bd-b261-cf52cb439d29""
""xmp:ModifyDate"",""2021-01-03T05:42:04Z""
""trapped"",""False""
""meta:creation-date"",""2020-12-29T06:45:56Z""
""created"",""2020-12-29T06:45:56Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-12-29T06:45:56Z""
""resourceName"",""PROCESS%20Privacy-Preserving%20On-Chain%20Certificate%20Status%20Service.pdf""
""pdfaid:part"",""2""
""producer"",""MiKTeX pdfTeX-1.40.21""
""pdf:docinfo:producer"",""MiKTeX pdfTeX-1.40.21""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""4"",""1"",""1"",""7"",""23"",""6"",""0"",""0"",""0""
""access_permission:modify_annotations"",""true""
""dcterms:created"",""2020-12-29T06:45:56Z""
""Last-Modified"",""2021-01-03T05:42:04Z""
""dcterms:modified"",""2021-01-03T05:42:04Z""
""xmpMM:DocumentID"",""uuid:813ff814-306e-43ea-88dc-f50e0af1d6e3""
""Last-Save-Date"",""2021-01-03T05:42:04Z""
""pdf:docinfo:modified"",""2021-01-03T05:42:04Z""
""meta:save-date"",""2021-01-03T05:42:04Z""
""Content-Length"",""841256""
""Content-Type"",""application/pdf""
""xmp:MetadataDate"",""2021-01-03T05:42:04Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""pdfaid:conformance"",""B""
""pdf:producer"",""MiKTeX pdfTeX-1.40.21""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""10""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""4796"",""4009"",""3731"",""4837"",""4519"",""3783"",""4390"",""4595"",""4658"",""4414""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-12-29T06:45:56Z""
";https://scholar.google.ch/scholar?start=750&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098839-279;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;[PDF][PDF] A Control Plane in Time and Space for Locality-Preserving Blockchains;A Pannatier ;2020 epfl.ch;;"… It is not the case of a cryptocurrency. For this kind of system, one can expect to have at least some

churn, some moving nodes and some joining nodes … Control Plane Blockchain Distance Oracle

Transaction Synchronicity Handler Liveness Checker Request Handler …";Autres articles;Version HTML;[PDF] epfl.ch;https://www.epfl.ch/labs/dedis/wp-content/uploads/2020/02/report-2019-2-Arnaud_Pannatier-nyle.pdf;"
École Polytechnique Fédérale de Lausanne

A Control Plane in Time and Space for Locality-Preserving
Blockchains

by Arnaud Pannatier

Master Thesis

Approved by the Examining Committee:

Prof. Bryan Ford
Thesis Advisor

Prof. Pawel Szalachowski
External Expert

Cristina Basescu
Thesis Supervisor

EPFL IC DEDIS
Bâtiment BC

Station 14
CH-1015 Lausanne

January 16, 2020





Acknowledgments

I want to give a special thanks to my supervisor Cristina Basescu for the precious help during the
Master Thesis. Sometimes starting in a new field such as distributed and decentralized systems
require a certain level of abstraction and the advice provided during the weekly meetings allowed
me to have a good understanding of the subject.
I would also like to thank Prof. Bryan Ford for the supervision of this work. And the external
expert, Prof. Pawel Szalachowski, for his involvement in the corrections.
It was a pleasure for me to have the chance of working on this Master Thesis during the same
time as Bastian Nanchen. The master’s thesis can sometimes feel like a solitary journey, and it
was nice to be able to rely on a friend during this time.
I want to thank Marion Bourqui for her support on a daily basis, especially during the last three
weeks of the master’s thesis where the work was the most intense.

Lausanne, January 16, 2020 Arnaud Pannatier

3



Contents

Acknowledgments 3

1 Introduction 7

2 Related Work 11

3 Background 13
3.1 CRUX - Fast and Resilient Datastore with Automated Locality . . . . . . . . . . . . 13

3.1.1 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.1.2 Common Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3.2 Nyle - A Locality-Preserving Blockchain . . . . . . . . . . . . . . . . . . . . . . . . 17
3.2.1 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.2.2 What is already implemented for Nyle . . . . . . . . . . . . . . . . . . . . . 18
3.2.3 Purpose of This Project: Motivation for a Control Plane . . . . . . . . . . . 18

4 Design 19
4.1 Problem definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

4.1.1 Hypotheses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.1.2 Threat Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

4.2 General Presentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.2.1 Membership Component . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.2.2 Distance Oracle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.2.3 Region Component . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.2.4 Epoch Component . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.2.5 Request Handler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

4.3 Simple Control plane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.3.1 Membership Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.3.2 Threshold-Signing Registration . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.3.3 Committee Consensus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.3.4 Public distributed source of randomness . . . . . . . . . . . . . . . . . . . 24

4.4 Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.4.1 Advantages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.4.2 Drawbacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

4



4.5 Security Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.5.1 Network Attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.5.2 Malicious Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.5.3 Problem With Too Many Different Levels . . . . . . . . . . . . . . . . . . . 33

5 Improvements 35
5.1 Strawman 1 : Locarno Treaties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

5.1.1 Rebalancing the Levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
5.1.2 Motivation for Keeping the Levels . . . . . . . . . . . . . . . . . . . . . . . . 36
5.1.3 Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
5.1.4 Threat Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

5.2 Strawman 2 : Fog of the War . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
5.2.1 Purpose : Reducing the Need of the Consensus on Distances . . . . . . . . 42
5.2.2 Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
5.2.3 Attack on Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

5.3 Discussion : Space/Time Interaction distance . . . . . . . . . . . . . . . . . . . . . 44
5.3.1 Interactions as a Distance on Space/Time Graphs . . . . . . . . . . . . . . 45
5.3.2 Finding Meaning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
5.3.3 Justification to Replace the Locality . . . . . . . . . . . . . . . . . . . . . . . 48
5.3.4 Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
5.3.5 Drawback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

6 Possible Improvements 51
6.1 Roadmap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

7 Conclusion 53

Bibliography 55

A Locarno Treaties : Data 58

B Space Time : Data 60

C Dataset on Master Thesis 64

5





Chapter 1

Introduction

Distributed ledgers were the trend of the last ten years. You might realize that when your hair-
dresser starts to tell you that he plans to put his money into blockchains or when your little
cousin asks to have some Bitcoin [21] for Christmas. The research in this field is growing every
year.

However, distributed ledgers still have weaknesses. The purpose of this work is to propose a
solution concerning two well-known weaknesses. The first one is the time required to confirm a
transaction. Indeed, in Bitcoin [21], validating a transaction can take around one hour, because
it takes around ten minutes to validate a block, and it needs around six blocks to be convinced
with a high probability that the ledger won’t be forked, and the transaction invalidated. This
might be acceptable for some transactions of great value. For example, if somebody is buying a
car using Bitcoin [21], this person might agree to wait one hour so that its transaction is validated.
However, if somebody wants to use it to buy its daily coffee, he might be a bit annoyed to wait
that long. The other weakness appears in World War III scenarios. If a third World War occurs,
splitting the World in two, one can expect that the circumstances would cut the communication
between the two sides. This is a problem for standard distributed ledgers as it is leading to forks
that the system cannot resolve at the end of World War III.

This work is part of a larger project called Nyle [Figure 1.1], which uses the notion of locality
to solve these problems. The idea is to replicate the system along regions of different sizes, from
local (e.g., Switzerland, London) to global. With this idea, a transaction can be validated in a
local region first, but it is still possible to wait for global validation if needed. Most of the time,
a transaction that was validated locally is validated globally as well. Still, in some cases, when
propagating the information to the global regions, some transactions might be invalidated as they
are in conflict with others. Therefore one or both won’t be accepted to avoid double-spending.
For significant transactions, people might prefer to wait for global confirmation. Nevertheless, if
one wants to buy its daily coffee, local validation might be enough for the merchant, especially if
he already knew the person. For World War IIIs Scenarios, Nyle offers a solution as well, indeed if

7



a global partition occurs, the system replicated in smaller regions that are not split by a partition
can continue working flawlessly.

Figure 1.1 – Sketch of Nyle: The Blockchain is replicated across all regions.

Nodes that are spread over the World are maintaining Nyle’s distributed ledger. Clients can
ask the nodes to proceed with their transactions or other requests. Nodes are participating in
a different number of regions. A first challenge is to draw these regions adequately. A second
challenge is churn: in an internet-like network with open-membership the control plane should
be dynamic, as nodes can join, leaves or move in the system at any moment. This challenge
might not be a problem for classic distributed ledger as Bitcoin [21], as its protocol only takes
into account the computational power that is in the system at a given time. But as Nyle is locality-
based, this might lead to additional challenges, each corresponding to the different actions
possible: joining, leaving and moving.

For joining nodes, consider the case where there were only a few nodes spread along a vast
region, for example, Western Europe, and after a while, a large number of new nodes want to join
there. If region creation is not allowed, this big region stays the smaller unit of locality, and this
might lead to some problems. Furthermore, for a region of this size, the probability of a partition
is relatively substantial. One might want that the joining of new nodes creates additional regions
with the size of countries, for example. Therefore, regions should be able to adapt, depending
on node membership. If nodes leave the system, this might lead to problems as well. Indeed
if too many nodes leave, some regions might not contain any nodes that are maintaining the
system. To avoid this situation, it could be possible to modify the regions when nodes leave
to guarantee that a sufficient number of nodes are in a region at any time. Moving nodes are
creating problems as well with fixed region assignment. As nodes are mobile, a node can drift
apart after a while far away from his assigned regions. This drifting might take a while, but one

8



can imagine the situation where many nodes have moved far away from their original position.
In case of a global partition, this can lead to the failure of even small regions, that is one problem
to avoid in Nyle. Therefore the regions should be adapted with the movement of the nodes.

CRUX [2] is the basis of most of this work, which introduces an algorithm that allows creating
regions based on compact graph theory. Chapter 3 describes this algorithm in more detail.
This work uses the existing code base for CRUX in Go. A first work on Nyle [26] proposes a first
implementation of Nyle building on the top CRUX [2] but focusing directly on how to improve the
storage of the transactions and the tree structure of the regions. This work builds directly upon
the existing work, but is slightly orthogonal, as the Control Plane has not a direct relation to the
replicated blockchain. Sabrina Kall [9] has done a second work on Nyle, called proof-of-location.
Her work is proposing first, a way of checking the location of a node efficiently. And second, a
method to assert if nodes were lying about the location where they claimed to be. There is a
current work by Guillaume Michel on the Interplanetary-File System (IPFS) [18] that is based on
CRUX as well but with the purpose of creating a locality-aware overlay to speed the system up.
However, it is not directly related to blockchains. Chapter 2 describes the rest of the related work.
These works are mostly orthogonal to the current approach: some other solutions to speed the
validation of transaction are Bitcoin [21], Byzcoin [12], Omniledger [13], DFINITY [8], Monoxide
[29] and Stellar [15]. However, they don’t use the concept of the locality for this purpose.

Here is the structure of this work: first, a simple version of the control plane was designed
in Chapter 4, which splits the time into epochs and takes as an assumption that the system
remains fixed during one epoch. This work proposes and discusses a protocol, and gives his
threat analysis. Based on its implementation and performance analysis, some drawbacks are
put into light. Then a series of strawman models try to correct some of these drawbacks and
are analyzed as well in Chapter 5. The first one is called ""Locarno Treaties"" and try to keep the
system coherent from one epoch to the next. The next one is called ""Fog of the war"", and try to
reduce the need for communication between nodes. The last and the most complex Strawman
considers the interactions of the nodes as a space-time graph and try to build upon the existing
patterns that appear in these graphs to propose a different notion of distance.

This work proposes A Control Plane in Time and Space for Locality-Preserving
Blockchains. This control plane for Nyle is needed to ensure to have a open-membership and to
solve the problems of World War III scenarios and to allow regional validations. The series of
strawman models improving the simple control plane leads to the use of Space-Time graphs
that allowed to improve the existing design.

9





Chapter 2

Related Work

This work builds upon several other works in the domains of blockchain and locality. Nyle
proposes a decentralized cryptocurrency using different strategies than Bitcoin [21], Byzcoin
[12], Omniledger [13], DFINITY [8], Monoxide [29] and Stellar [15]. But it uses them as a source
of inspiration and shares some aspects with these general cryptocurrencies. It is somehow
orthogonal to them because it can use any of these cryptocurrencies as an underlying system
and enhance them using the idea of the locality to provide them with some partition-resistance
and regional validation.

These works are the direct source of inspiration for some key concepts of this work. DFINITY
[8] directly inspires the Sybil-resistant scheme used in the registration system, using endorsement
in the general way, which can be in practice replaced by any Sybil-resistance scheme like Proof-
of-Work [21], Proof-of-Stake [30], or even Proof-of-Personhood [4]. In particular, this work tries
to solve some drawbacks of traditional cryptocurrencies like Bitcoin [21], solving the problem of
the waiting time for transaction validation by using regional validation and making it resistant
to WWIII scenarios. Byzcoin [12] and Omniledger [13] give another interesting solution to
accelerate the validation, but their results are orthogonal to this research. Stellar’s solution for
open-membership [15] is based on a quorum, allowing each node to trust a subset of other nodes
of its choice. It is an elegant solution and permits to validate transactions fast and securely. A
certain complexity seems to be added both in the theoretical and practice part. This justifies why
a similar approach was not followed. However, the idea to allow nodes to have a different view of
the system is at the core of one of the improvements of this work, described in section 5.2.

Omniledger [13] and Monoxide [29] use sharding to increase performance. Sharding, which
splits the system in a random committee that allows the fastest processing of the transaction.
Sharding is orthogonal to the replication process used in this work. As even if the system is split
into different parts, first, it is not done randomly but based on the locality. Furthermore, the
system is replicated in all regions. However, cryptocurrencies using shards can still be used as
an underlying system of Nyle, enhancing the performance of the partition-resistant blockchain

11



system created by this means.

This work is directly related to the locality-preserving algorithms developed in CRUX [2] and
compact-graph algorithms [28], which are described in detail in Chapter 3. There is a class of
algorithms that uses the idea of locality differently. For example, Geo-DNS [11] or IP Anycast [1]
use the locality to shorten the path for the packets, connecting the servers via the closest path.
Replication is often used to guarantee the integrity of the stored information [20]. In CRUX [2]
and Nyle regional replication of the system is used to create partition-resistance, and in Nyle, it
can be used to allow region validation.

Some classic consensus protocols as PAXOS [14], PBFT [5] were used as an inspiration to the
protocol. In practice, and for efficiency, this work uses BlsCoSi [3] that is much more efficient,
because it makes smart use of trees for communication. BlsCoSi [3] is still prone to some failures
in case of successive view-changes, it could be improved using a different protocol such as
HotStuff [31] which solves the problem of view change using a third round of communication.

This work uses a distributed public algorithm for the source of randomness like Randhound
[27]. Each node uses this source to draw a random level. The way it is used is described in detail
in the next section.

12



Chapter 3

Background

This Master Thesis is part of a larger project that concerns locality-preserving systems. In partic-
ular, it builds upon CRUX [2] and is part of Nyle. This section describes two different projects.

3.1 CRUX - Fast and Resilient Datastore with Automated Locality

3.1.1 Description

CRUX [2] introduces a smart way of dealing with partitions in decentralized systems. Partitions
occur in decentralized systems, but one can try to find a solution to reduce their effects on
the global system. For example, if a partition occurs, there are no reasons that nodes that are
functioning on the same side of the partition should stop working because of the partition.

The general idea is that a system can be replicated at different scales, from local (big cities,
small countries) to global. The replication means that a separate instance of the system is created
in all regions. This ensures the additional property that each replicated system continues to work
correctly if no partition splits it. If a global partition occurs, then the global region might not
work, but all the replicated systems in local regions continue working. This is a direct solution
to the previously mentioned problem: nodes working on the same of the partition continue
to work. The force of CRUX is that it provides a locality property [2]. For any two nodes in the
system, it is guaranteed that they participate within a region with a radius that is equal to a small
multiple of their Round Trip Time (RTT).

This solution comes with an overhead, as the system should be replicated in all the regions.
However, there are ways to reduce these overhead costs so that they remain reasonable and
that resistance to partition is maintained. CRUX algorithm for regions creation [2] presented
below ensures that the proper number of regions is created in a manner that the number of

13



regions created induces a reasonable overhead and that the partition resistance stays efficient.
If CRUX [2] is used for a specific system, overhead can be even more reduced: as the systems
are replicated in every region, most of the data is replicated as well. So one might dig inside the
specification of one system and manages not to store twice the same data. But this goes beyond
the goal of CRUX [2], which wants to be the more general possible.

Indeed, the force of CRUX [2] is that it applies to any distributed system, as no particular
hypothesis on the system is made. It only starts from a straightforward idea: one system can be
replicated at a smaller scale to ensure some partition resistance.

A note should be made about the CAP-theorem, which states that no system can be consistent,
available and partition-resistant at the same time. It seems that this solution is adding partition
tolerance to an available and consistent system, thus leading to the violation of the theorem. But
it is not precisely the case, as the enhanced system only ensures that nodes can still work in some
regions that are not affected by the partition. The regions split by a partition are not working
anymore. Even if the system can still work on the same side of a partition, it’s not partition
resistant as a whole.

3.1.2 Common Tools

This section describes how to create regions that are used to replicate the system. These regions
are used by Nyle as well. These regions are called Available Responsive Areas (ARA), in each
region, a copy of the replicated system is deployed. Each node, starting at level 0, participates
first at a lottery. Then each node goes to the next level with a given probability P . This procedure
is repeated at every level and is stopped when no nodes are promoted to the next level. This first
empty level is called K. Then each node can compute two quantities that are necessary to create
ARAs: their bunch and their cluster.

System Level #1 Level #2 Level #3 Level #4

100 90 9 1 0
200 180 18 2 0
500 450 45 5 0

1000 900 90 9 1

N, k = 2 N(1− p) Np(1− p) Np2 0

N, k = 3 N(1− p) Np(1− p) Np2(1− p) Np3

Table 3.1 – Example of lottery with P = 0.1 where k = 3 for N = 100, 200, 500 and 4 for N = 1000.
Columns represents the number of nodes and the row the levels.

Bunch A node can compute its bunch in the following manner. It looks at every other node by
order of distances in ascending order and includes it in its bunch if its level is not smaller than

14



0

0 0
0

0
0

0

0 0
0

0
0

0
0

0

0 0
0

0

0
0

0

0 0
0

0
0

0
0

0 0
0 0

0
0

0 0
0

0
0

0
0

0
0

0
0

0

0

0 0
0

0
0

0
0

Level 0

Level 1

Level 2

1

0

1

0

1

0

1

0

1

0

1

0

1

0

1

0

1

0

2

1

2

Figure 3.1 – Sketch of the Lottery process, nodes goes from one level to the next with probability
P

any level it encountered so far, including its level [Figure 3.2].

0

0

0

1

2

0
0

0

A B

0

1

A have B in his bunch

node considered

node in the bunch

Figure 3.2 – The bunch of the level-0 blue node with solid border is depicted in blue. The cluster
of the higher level node covers the whole system.

Cluster A cluster is a complementary concept. The cluster of node A is defined as the set of
other nodes that have A in their bunch [Figure 3.3].

The smallest region radius Rmin is defined for the whole system. Each node constructs ARAs

around itself, starting at Rmin and doubling the radius at each time. It stops at the first ARA that

15



0

0

0

1

2

0
0

0

A B

1

0

A have B in his bunch

node considered

node in the cluster

Figure 3.3 – The cluster of the level-1 orange node is depicted in orange. The cluster of the higher
level node covers the whole system.

Rmin

Rmax

0

0

1

Figure 3.4 – A node (red) participates in two kinds of regions. The ones it creates with a radius
from Rmin to one that is covering its cluster (orange). And some regions created by the nodes in
its cluster, which are covering him (blue).

16



is covering its entire cluster [Figure 3.4].

By the lottery, most nodes are level-zero nodes. Therefore, their clusters are supposed to be
small, conducting to the creation of a small number of ARAs. The small number of nodes that
are at level K − 1 have every other node in their cluster by construction. This means that there is
at least one ARA that covers the whole system.

3.2 Nyle - A Locality-Preserving Blockchain

Nyle is a cryptocurrency that uses locality to answer some classical problems of blockchains.
Two central problems are addressed: WWIII scenarios and approval time for a transaction.

WWIII Scenarios In case of a WWIII, we can expect to have at least a long-lasting partition that
split the system in two. This is a problem for classical cryptocurrencies like Bitcoin [21] because
for a block to be approved, the users are supposed to wait to have a global consensus. This
consensus will not be reached with a long-lasting partition and therefore, it creates problems for
classical cryptocurrencies. Nyle solves this issue by design using locality.

Approval Time for a Transaction Another issue with waiting global consensus is that it usually
takes a long time. If a customer wants to use a cryptocurrency in daily life, the nodes should be
able to validate (at least partially) transactions relatively fast. The solution provided by Nyle uses
locality again: a transaction can be validated at different geographical levels, and it is up to the
customer to wait for a local, or global validation for a transaction. For small transactions, e.g.,
for buying a coffee, the customer might agree only to have local validation. For more significant
transactions, he might want to wait a bit longer to have global validation.

3.2.1 Description

Nyle uses ARAs as the representation of one region. In each of these regions, there is a copy of the
same system; in the case of Nyle, the system is a blockchain. So each region has its blockchain
and validates all the transactions between the nodes that are included in it. Some nodes can
be contained in different regions, and they send their transactions to all the regions they are
part of. As all nodes participate in the global region by design, this ensures that a transaction is
eventually seen by all nodes.

The big difference between CRUX [2] and Nyle is that the purpose of CRUX [2] is to work in
environments where machines are relatively ""stable"" which means that they are not supposed
to churn, where the machines are not supposed to move or to join, and more importantly, where
nodes are not malicious. This is not the case for Nyle: if we have a cryptocurrency, we can expect

17



to have deficient, malicious and moving nodes. This adds some difficulties that are managed by
the protocol.

Each region has its blockchain. In Nyle, the choice for the blockchain is chosen between
ByzCoin [12] or Omniledger [13], but it can be generalized to any blockchain.

3.2.2 What is already implemented for Nyle

CRUX algorithm for region creation We already have an algorithm for drawing regions [2].

Block storage on node As each node participates in different regions (from very local to world-
wide), it needs to store the blockchain for all of these regions. We have a method that reduces the
redundancy, by only storing the hash of a block instead of the full block at each level [26].

Proof-of-Location We already have a protocol for controlling the distance from a new node to
the rest of the nodes, and that assures no one cheats by giving false distances [9].

3.2.3 Purpose of This Project: Motivation for a Control Plane

CRUX [2] proposes a system that is working in a stable system (with low-churn) and where nodes
do not move too much. This situation corresponds to some systems like a wide-area database.
It is not the case of a cryptocurrency. For this kind of system, one can expect to have at least
some churn, some moving nodes and some joining nodes. If the system has a precise protocol
for dealing with nodes entering, leaving and moving in the system, then the problem of the
evolution of the system is solved. Indeed the churn phenomenon can be described as some
nodes leaving the system and optionally reentering later.

CRUX [2] can still envisage the use of a control plane, and it considers it as future work. As
even if CRUX [2] does not have high churn, the RTT between nodes can still vary.

Therefore the purpose of the control plane is to manage the regions in order to follow the
evolution of the nodes in the system. Once that problem is solved, the blockchain can be
replicated in the evolving region and the strategy is the same as in CRUX [2]. This project
introduces a control plane, that is in charge of the evolution of the nodes. In particular, it is in
charge of dealing with nodes joining, leaving and moving. The blockchains are replicated in all
the regions, but the control plane is global.

18



Chapter 4

Design

This part describes the design of the Control Plane, which has the mission to solve the problem
of node insertion, deletion and movement inside the system. A first version of the control plane
is designed, and then it is improved by a series of Strawman models.

4.1 Problem definition

4.1.1 Hypotheses

Three hypotheses are made on the network. First, it assumes an Internet-like network with
one-to-one communication. Each node can contact any other nodes. This hypothesis is required
as nodes need to communicate for the different consensus. Second nodes need to have synchro-
nised clocks, and the protocol requires this as it assumes that they are two successive periods,
one for the registration and one for executing the system, and nodes should know when they are
supposed to start and to register. The third hypothesis is made on the geometry of the network.
It states that for small pings (under 100ms), the round-trip-time is correlated with the distance
between two nodes. This is the case for the Internet network [25]. This is required as the locality
component use that hypotheses to estimate distances with pings. On this result, we build the
locality properties of the system.

4.1.2 Threat Model

Attacks on the system can be made internally from malicious nodes or externally by delaying the
interaction between nodes or intercepting and forging messages. We give the precise portion of
malicious nodes that this protocol can handle. In this threat model, malicious nodes are regular

19



nodes that decide to act against the system. In particular, malicious nodes have only access to
limited computational power, and they cannot break the cryptographic primitives.

4.2 General Presentation

The Control Plane is composed of five different components [Figure 4.1], each necessary to
address different parts of the problem. It needs a membership component, to define which
nodes are in the system at any time. It needs a distance oracle which gives the distance between
two nodes in the system. Then it needs a region management component, which creates and
alter the regions based on the membership and the locality. The time is split into epochs, and a
component is in charge of dealing with that aspect. And finally, the control plane is in charge of
answering some requests linked to the location and presence of the nodes in the system. Each
component is described in detail below.

Control PlaneBlockchain

Distance Oracle
Transaction Synchronicity

Handler 

Liveness Checker

Request Handler

Membership system

Transaction Validation

Transaction History

Region Management

Creation

Update

Regions

Epoch Manager

Security Checker Has a
In charge of

Figure 4.1 – List of modules of Nyle. This works concerns the components in blue.

4.2.1 Membership Component

At each epoch, a list of all participants for the current epoch is created and it is signed by the
participants of the previous epoch. It is based on registration, which is made during the previous
epoch. Registration use endorsement (for example solution to a proof-of-work problem). This

20



system is global. Nodes can ask the participants of the system to know the identity of other
nodes. For a new contract to be validated, it should be signed by the majority of the nodes of the
previous epoch.

4.2.2 Distance Oracle

The role of the locality component is to give all pairwise distances between nodes of the system.
We assume it already exists (distance oracle), or that nodes can compute it. In this protocol, the
metric that is used as a distance is the latency. Therefore all pairwise-latencies are computed
between each node and every node agrees on them via consensus.

We also assume the existence of a control function that is able to assert the validity of the
distances based on the latencies.

4.2.3 Region Component

This component is used to create and update regions. This part is based on CRUX. At each epoch,
CRUX is run based on the new registration, and regions are created.

4.2.4 Epoch Component

The epoch manager is linked to the membership system (we allow to change membership at the
beginning of one epoch). New nodes can register during one epoch and join for the next. If nodes
have moved, the Region component change or maintain their assignment at the beginning of
one epoch. If nodes have crashed, they won’t be able to join for the next epoch and will, therefore,
leave the system.

Epochs happen at a defined rhythm, e.g. one day. This frequency can be shortened to ensure
that nodes, wanting to join, do not wait too long, or made longer if one wants regions not to be
redrawn too frequently.

4.2.5 Request Handler

The control plane is responsible for handling requests as it is aware of the nodes locat";"""date"",""2020-01-16T10:49:34Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2020-01-16T10:49:34Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017) kpathsea version 6.2.3""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2020-01-16T10:49:34Z""
""created"",""2020-01-16T10:49:34Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-01-16T10:49:34Z""
""resourceName"",""report-2019-2-Arnaud_Pannatier-nyle.pdf""
""Author"",""""
""producer"",""pdfTeX-1.40.18""
""pdf:docinfo:producer"",""pdfTeX-1.40.18""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2020-01-16T10:49:34Z""
""Last-Modified"",""2020-01-16T10:49:34Z""
""dcterms:modified"",""2020-01-16T10:49:34Z""
""title"",""""
""Last-Save-Date"",""2020-01-16T10:49:34Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2020-01-16T10:49:34Z""
""meta:save-date"",""2020-01-16T10:49:34Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017) kpathsea version 6.2.3""
""Content-Length"",""2956291""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""64""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""310"",""0"",""811"",""1435"",""1272"",""0"",""2010"",""1789"",""2516"",""0"",""2056"",""1114"",""1559"",""2013"",""696"",""387"",""2200"",""1847"",""1269"",""1324"",""1445"",""1384"",""2477"",""1389"",""335"",""1680"",""878"",""1014"",""1264"",""1031"",""1966"",""2315"",""954"",""0"",""1135"",""1864"",""1635"",""1136"",""1390"",""1352"",""1568"",""1672"",""2475"",""1191"",""1908"",""1382"",""788"",""1826"",""1604"",""0"",""1853"",""1112"",""1984"",""931"",""1670"",""2762"",""926"",""135"",""115"",""160"",""419"",""1689"",""1937"",""405""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-01-16T10:49:34Z""
";https://scholar.google.ch/scholar?start=820&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098795-179;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;[PDF][PDF] A new RSA public key encryption scheme with chaotic maps.;N Tahat, AA Tahat, M Abu;Dalu…  International Journal of …, 2020  academia.edu;;"… Proof: If ?? = 0 = ??, then ??1 = ????2(??) = 1 = ????2(??) and so to be a particular case of the proposed

scheme is satisfied by the dependent RSA crypto-system. Therefore, if an oracle exists such that

it is capable of breaking the proposed scheme, then it is capable also of breaking …";Cité 4 fois;Les 3 versions;[PDF] academia.edu;https://www.academia.edu/download/64034342/35%2017oct%205oct%2026jun%2020517%20ED%20By%20Ez.pdf;;;https://scholar.google.ch/scholar?start=720&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098826-244;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Efficient simulation of random states and random unitaries;G Alagic, C Majenz, A Russell ; … on the Theory and Applications of …, 2020  Springer;;"… We will use stateful machines to describe functionalities (and implementations) of collections

of oracles which relate to each other in some way. For example, one oracle might output a fixed

state, while another oracle reflects about that state. Definition 1 (Stateful machine) …";Cité 7 fois;Les 11 versions;[PDF] arxiv.org;https://arxiv.org/pdf/1910.05729;"
ar
X

iv
:1

91
0.

05
72

9v
1 

 [
qu

an
t-

ph
] 

 1
3 

O
ct

 2
01

9

Efficient simulation of random states and random unitaries

Gorjan Alagic1,2, Christian Majenz3,4, and Alexander Russell5

1 Joint Center for Quantum Information and Computer Science, University of Maryland
2 National Institute of Standards and Technology, Gaithersburg, Maryland

3 QuSoft, Amsterdam
4 Centrum Wiskunde & Informatica, Amsterdam

5 Department of Computer Science and Engineering, University of Connecticut

Abstract. We consider the problem of efficiently simulating random quantum states and random
unitary operators, in a manner which is convincing to unbounded adversaries with black-box oracle
access.

This problem has previously only been considered for restricted adversaries. Against adversaries with
an a priori bound on the number of queries, it is well-known that t-designs suffice. Against polynomial-
time adversaries, one can use pseudorandom states (PRS) and pseudorandom unitaries (PRU), as
defined in a recent work of Ji, Liu, and Song; unfortunately, no provably secure construction is known
for PRUs.

In our setting, we are concerned with unbounded adversaries. Nonetheless, we are able to give stateful
quantum algorithms which simulate the ideal object in both settings of interest. In the case of Haar-
random states, our simulator is polynomial-time, has negligible error, and can also simulate verification
and reflection through the simulated state. This yields an immediate application to quantum money:
a money scheme which is information-theoretically unforgeable and untraceable. In the case of Haar-
random unitaries, our simulator takes polynomial space, but simulates both forward and inverse access
with zero error.

These results can be seen as the first significant steps in developing a theory of lazy sampling for
random quantum objects.

1 Introduction

1.1 Motivation

Efficient simulation of randomness is a task with countless applications, ranging from cryptography to deran-
domization. In the setting of classical probabilistic computation, such simulation is straightforward in many
settings. For example, a random function which will only be queried an a priori bounded number of times t
can be perfectly simulated using a t-wise independent function [31]. In the case of unbounded queries, one
can use pseudorandom functions (PRFs), provided the queries are made by a polynomial-time algorithm [16].
These are examples of stateless simulation methods, in the sense that the internal memory of the simulator
is initialized once (e.g., with the PRF key) and then remains fixed regardless of how the simulator is queried.
Against arbitrary adversaries, one must typically pass to stateful simulation. For example, the straightfor-
ward and well-known technique of lazy sampling suffices to perfectly simulate a random function against
arbitrary adversaries; however, the simulator must maintain a list of responses to all previous queries.

Each of these techniques for simulating random classical primitives has a plethora of applications in
theoretical cryptography, both as a proof tool and for cryptographic constructions. These range from con-
structing secure cryptosystems for encryption and authentication, to proving security reductions in a wide
range of settings, to establishing security in idealized models such as the Random Oracle Model [6].

Quantum randomness. As is well-known, quantum sources of randomness exhibit dramatically different
properties from their classical counterparts [23,7]. Compare, for example, uniformly random n-bit classical
states (i.e., n-bit strings) and uniformly random n-qubit (pure) quantum states. A random string x is
obviously trivial to sample perfectly given probabilistic classical (or quantum) computation, and can be

http://arxiv.org/abs/1910.05729v1


copied and distributed arbitrarily. However, it is also (just as obviously) deterministic to all parties who
have examined it before. By contrast, a random state |ϕ〉 would take an unbounded amount of information
to describe perfectly. Even if one manages to procure such a state, it is then impossible to copy due to the
no-cloning theorem. On the other hand, parties who have examined |ϕ〉 many times before, can still extract
almost exactly n bits of randomness from any fresh copy of |ϕ〉 they receive – even if they use the exact
same measurement procedure each time.

The differences between random classical and random quantum maps are even more stark. The outputs of
a classical random function are of course classical random strings, with all of the aforementioned properties.
Outputs which have already been examined become effectively deterministic, while the rest remain uniformly
random and independent. This is precisely what makes efficient simulation possible via lazy sampling. A
Haar-random unitary U queried on two inputs |ψ〉 and |φ〉 also produces (almost) independent and uniformly
random states when queried, but only if the queries are orthogonal, i.e., 〈ψ | φ〉 = 0. Unitarity implies that
overlapping queries must be answered consistently, i.e., if 〈ψ | φ〉 = δ then 〈(Uψ) | (Uφ)〉 = δ. This possibility
of querying with a distinct pure state which is not linearly independent from previous queries simply doesn’t
exist for classical functions.

We emphasize that the above differences should not be interpreted as quantum random objects simply
being “stronger” than their classical counterparts. In the case of classical states, i.e. strings, the ability to copy
is quite useful, e.g., in setting down basic security definitions [8,3,2] or when rewinding an algorithm [29,30,14].
In the case of maps, determinism is also quite useful, e.g., for verification in message authentication.

1.2 The problem: efficient simulation

Given the dramatic differences between classical and quantum randomness, and the usefulness of both, it
is reasonable to ask if there exist quantum analogues of the aforementioned efficient simulators of classical
random functions. In fact, given the discussion above, it is clear that we should begin by asking if there even
exist efficient simulators of random quantum states.

Simulating random states. The first problem of interest is thus to efficiently simulate the following ideal
object: an oracle IS(n) which contains a description of a perfectly Haar-random n-qubit pure state |ϕ〉,
and which outputs a copy of |ϕ〉 whenever it is invoked. We first make an obvious observation: the classical
analogue, which is simply to generate a random bitstring x ← {0, 1}n and then produce a copy whenever
asked, is completely trivial. In the quantum case, efficient simulation is only known against limited query
algorithms (henceforth, adversaries.)

If the adversary has an a priori bound on the number of queries, then state t-designs suffice. These are
indexed families {|ϕk,t〉 : k ∈ Kt} of pure states which perfectly emulate the standard uniform “Haar”
measure on pure states, up to the first t moments. State t-designs can be sampled efficiently, and thus yield
a stateless simulator for this case [4]. A recent work of Ji, Liu and Song considered the case of polynomial-
time adversaries [18]. They defined a notion of pseudorandom states (PRS), which appear Haar-random to
polynomial-time adversaries who are allowed as many copies of the state as they wish. They also showed how
to construct PRS efficiently, thus yielding a stateless simulator for this class of constrained adversaries [18];
see also [9].

The case of arbitrary adversaries is, to our knowledge, completely unexplored. In particular, before this
work it was not known whether simulating IS(n) against adversaries with no a priori bound on query or
time complexity is possible, even if given polynomial space (in n and the number of queries) and unlimited
time. Note that, while the state family constructions from [18,9] could be lifted to the unconditional security
setting by instantiating them with random instead of pseudorandom functions, this would require space
exponential in n regardless of the number of queries.

Simulating random unitaries. In the case of simulating random unitaries, the ideal object is an oracle
IU (n) which contains a description of a perfectly Haar-random n-qubit unitary operator U , and applies U
to its input whenever it is invoked. The classical analogue is the well-known Random Oracle, and can be

2



simulated perfectly using the aforementioned technique of lazy sampling. In the quantum case, the situation
is even less well-understood than in the case of states.

For the case of query-limited adversaries, we can again rely on design techniques: (approximate) unitary
t-designs can be sampled efficiently, and suffice for the task [10,21]. Against polynomial-time adversaries,
Ji, Liu and Song defined the natural notion of a pseudorandom unitary (or PRU) and described candidate
constructions [18]. Unfortunately, at this time there are no provably secure constructions of PRUs. As in
the case of states, the case of arbitrary adversaries is completely unexplored. Moreover, one could a priori
plausibly conjecture that simulating IU might even be impossible. The no-cloning property seems to rule out
examining input states, which in turn seems to make it quite difficult for a simulator to correctly identify
the overlap between multiple queries, and then answer correspondingly.

Extensions. While the above problems already appear quite challenging, we mention several natural exten-
sions that one might consider. First, for the case of repeatedly sampling a random state |ϕ〉, one would ideally
want some additional features, such as the ability to apply the two-outcome measurement {|ϕ〉〈ϕ|,1−|ϕ〉〈ϕ|}
(verification) or the reflection 1− 2|ϕ〉〈ϕ|. In the case of pseudorandom simulation, these additional features
can be used to create a (computationally secure) quantum money scheme [18]. For the case of simulating
random unitaries, we might naturally ask that the simulator for a unitary U also has the ability to respond
to queries to U−1 = U †.

1.3 This work

In this work, we make significant progress on the above problems, by giving the first simulators for both ran-
dom states and random unitaries, which are convincing to arbitrary adversaries. We also give an application of
our sampling ideas: the construction of a new quantum money scheme, which provides information-theoretic
security guarantees against both forging and tracing.

We begin by remarking that our desired simulators must necessarily be stateful, for both states and
unitaries. Indeed, since approximate t-designs have Ω((22n/t)2t) elements (see, e.g., [26] which provides a
more fine-grained lower bound), a stateless approach would require superpolynomial space simply to store
an index from a set of size Ω((22n/t(n))2t(n)) for all polynomials t(n).

In the following, we give a high-level overview of our approach for each of the two simulation problems
of interest.

Simulating random states. As discussed above, we wish to construct an efficient simulator ES(n) for
the ideal oracle IS(n). For now we focus on simulating the procedure which generates copies of the fixed
Haar-random state; we call this IS(n).Gen. We first note that the mixed state observed by the adversary
after t queries to IS(n).Gen is the expectation of the projector onto t copies of |ψ〉. Equivalently, it is the
(normalized) projector onto the symmetric subspace Symn,t of (C2n)⊗t:

τt = Eψ∼Haar|ψ〉〈ψ|⊗t ∝ ΠSymtC2n . (1)

Recall that Symn,t is the subspace of (C2n)⊗t of vectors which are invariant under permutations of the t
tensor factors. Our goal will be to maintain an entangled state between the adversary A and our oracle
simulator ES such that the reduced state on the side of A is τt after t queries. Specifically, the joint state
will be the maximally entangled state between the Symn,t subspace of the t query output registers received
by A, and the Symn,t subspace of t registers held by ES. If we can maintain this for the first t queries,
then it’s not hard to see that there exists an isometry V t→t+1 which, by acting only on the state of ES,
implements the extension from the t-fold to the (t+ 1)-fold joint state.

The main technical obstacle, which we resolve, is showing that V t→t+1 can be performed efficiently. To
achieve this, we develop some new algorithmic tools for working with symmetric subspaces, including an
algorithm for coherent preparation of its basis states. We let A denote an n-qubit register, Aj its indexed
copies, and At = A1 · · ·At t-many indexed copies (and likewise for B.) We also let {|Sym(α)〉 : α ∈ S↑

n,t}

3



denote a particular orthonormal basis set for Symn,t, indexed by some set S↑

n,t (see Section 3 for definitions
of these objects.)

Theorem 1. For each n and t, there exists a polynomial-time quantum algorithm which implements an
isometry V = V t→t+1 from Bt to At+1B

t+1 such that, up to negligible trace distance,

(1At ⊗ V )
∑

α∈S↑
n,t

|Sym(α)〉At |Sym(α)〉Bt =
∑

β∈S↑

n,t+1

|Sym(β)〉At+1 |Sym(β)〉Bt+1 .

Above, V is an operator defined to apply to a specific subset of registers of a state. When no confusion
can arise, in such settings we will abbreviate 1⊗V—the application of this operator on the entire state—as
simply V .

It will be helpful to view V t→t+1 as first preparing |0n〉At+1 |0n〉Bt+1 and then applying a unitary U t→t+1

on At+1B
t+1. Theorem 1 then gives us a way to answer Gen queries efficiently, as follows. For the first query,

we prepare a maximally entangled state |φ+〉A1B1 across two n-qubit registers A1 and B1, and reply with
register A1. Note that Symn,1 = C2n . For the second query, we prepare two fresh registers A2 and B2,
both in the |0n〉 state, apply U1→2 on A2B1B2, return A2, and keep B1B2. For the t-th query, we proceed
similarly, preparing fresh blank registers At+1Bt+1, applying U t→t+1, and then outputting the register At+1.

With this approach, as it turns out, there is also a natural way to respond to verification queries Ver

and reflection queries Reflect. The ideal functionality IS.Ver is to apply the two-outcome measurement
{|ϕ〉〈ϕ|,1 − |ϕ〉〈ϕ|} corresponding to the Haar-random state |ϕ〉. To simulate this after producing t sam-
ples, we apply the inverse of U t−1→t, apply the measurement {|02n〉〈02n|,1 − |02n〉〈02n|} to AtBt, reapply
U t−1→t, and then return At together with the measurement outcome (i.e., yes/no). For IS.Reflect, the ideal
functionality is to apply the reflection 1−2|ϕ〉〈ϕ| through the state. To simulate this, we perform a sequence
of operations analogous to Ver, but apply a phase of −1 on the |02n〉 state of AtBt instead of measuring.

Our main result on simulating random states is to establish that this collection of algorithms correctly
simulates the ideal object IS, in the following sense.

Theorem 2. There exists a stateful quantum algorithm ES(n, ÇŤ) which runs in time polynomial in n,
log(1/ÇŤ), and the number of queries q submitted to it, and satisfies the following. For all oracle algorithms
A,

∣

∣

∣Pr
[

AIS(n) = 1
]

− Pr
[

AES(n,ÇŤ) = 1
]∣

∣

∣ ≤ ǫ .

A complete description of our construction, together with the proofs of Theorem 1 and Theorem 2, are
given in Section 3.

Application: untraceable quantum money. To see that the efficient state sampler leads to a powerful
quantum money scheme, consider building a scheme where the bank holds the ideal object IS. The bank
can mint bills by IS.Gen, and verify them using IS.Ver. As each bill is guaranteed to be an identical and
Haar-random state, it is clear that this scheme should satisfy perfect unforgeability and untraceability, under
quite strong notions of security.

By Theorem 7, the same properties should carry over for a money scheme built on ES, provided ÇŤ is
sufficiently small. We call the resulting scheme Haar money. Haar money is an information-theoretically
secure analogue of the scheme of [18], which is based on pseudorandom states. We remark that our scheme
requires the bank to have quantum memory and to perform quantum communication with the customers.
However, given that quantum money already requires customers to have large-scale, high-fidelity quantum
storage, these additional requirements seem reasonable.

The notions of correctness and unforgeability (often called completeness and soundness) for quantum
money are well-known (see, e.g., [1].) Correctness asks that honestly generated money schemes should verify,
i.e., Ver(Mint) should always accept. Unforgeability states that an adversary with k bills and oracle access to
Ver should not be able to produce a state on which Ver⊗k+1 accepts. In this work, we consider untraceable
quantum money (also called “quantum coins” [24].) We give a formal security definition for untraceability,

4



which states that an adversary A with oracle access to Ver and Mint cannot do better than random guessing
in the following experiment:

1. A outputs some candidate bill registers {Mj} and a permutation π;
2. b← {0, 1} is sampled, and if b = 1 the registers {Mj} are permuted by π; each candidate bill is verified

and the failed ones are discarded;
3. A receives the rest of the bills and the entire internal state of the bank, and outputs a guess b′ for b.

Theorem 3. The Haar money scheme HM, defined by setting

1. HM.Mint = ES(n, negl(n)).Gen
2. HM.Ver = ES(n, negl(n)).Ver

is a correct quantum money scheme which satisfies information-theoretic unforgeability and untraceability.

One might reasonably ask if there are even stronger definitions of security for quantum money. Given
its relationship to the ideal state sampler, we believe that Haar money should satisfy almost any notion of
unforgeability and untraceability, including composable notions. We also remark that, based on the structure
of the state simulator, which maintains an overall pure state supported on two copies of the symmetric
subspace of banknote registers, it is straightforward to see that the scheme is also secure against an “honest
but curious” or “specious” [27,15] bank. We leave the formalization of these added security guarantees to
future work.

Sampling Haar-random unitaries. Next, we turn to the problem of simulating Haar-random unitary
operators. In this case, the ideal object IU(n) initially samples a description of a perfectly Haar-random
n-qubit unitary U , and then responds to two types of queries: IU.Eval, which applies U , and IU.Invert, which
applies U †. In this case, we are able to construct a stateful simulator that runs in space polynomial in n and
the number of queries q, and is exactly indistinguishable from IU(n) to arbitrary adversaries. Our result can
be viewed as a polynomial-space quantum analogue of the classical technique of lazy sampling for random
oracles.

Our high-level approach is as follows. For now, suppose the adversary A only makes parallel queries to
Eval. If the query count t of A is a priori bounded, we can simply sample an element of a unitary t-design.
We can also do this coherently: prepare a quantum register I in uniform superposition over the index set of
the t-design, and then apply the t-design controlled on I. Call this efficient simulator EUt. Observe that the
effect of t parallel queries is just the application of the t-twirling channel T (t) to the t input registers [10],
and that EUt simulates T (t) faithfully. What is more, it applies a Stinespring dilation6 [28] of T (t) with
dilating register I.

Now suppose A makes an “extra” query, i.e., query number t + 1. Consider an alternative Stinespring
dilation of T (t), namely the one implemented by EUt+1 when queried t times. Recall that all Stinespring
dilations of a quantum channel are equivalent, up to a partial isometry on the dilating register. It follows
that there is a partial isometry, acting on the private space of EUt, that transforms the dilation of T (t)

implemented by EUt into the dilation of T (t) implemented by EUt+1. If we implement this transformation,
and then respond to A as prescribed by EUt+1, we have achieved perfect indistinguishability against the
additional query. By iterating this process, we see that the a priori bound on the number of queries is
no longer needed. We let EU denote the resulting simulator. The complete construction is described in
Construction 4 below.

Our high-level discussion above did not take approximation into account. All currently known efficient
constructions of t-designs are approximate. Here, we take a different approach: we will implement our con-
struction using exact t-designs. This addresses the issue of adaptive queries: if there exists an adaptive-query
distinguisher with nonzero distinguishing probability, then by post-selection there also exists a parallel-query
one via probabilistic teleportation. This yields that the ideal and efficient unitary samplers are perfectly in-
distinguishable to arbitrary adversaries.

6 The Stinespring dilation of a quantum channel is an isometry with the property that the quantum channel can be
implemented by applying the isometry and subsequently discarding an auxiliary register.

5



Theorem 4. For all oracle algorithms A, Pr
[

AIU(n) = 1
]

= Pr
[

AEU(n) = 1
]

.

The existence of exact unitary t-designs for all t is a fairly recent result. It follows as a special case of
a result of Kane [19], who shows that designs exist for all finite-dimensional vector spaces of well-behaved
functions on path-connected topological spaces. He also gives a simpler result for homogeneous spaces when
the vector space of functions is invariant under the symmetry group action. Here, the number of elements of
the smallest design is bounded just in terms of the dimension of the space of functions. The unitary group is
an example of such a space, and the dimension of the space of homogeneous polynomials of degree t in both
U and U † can be explicitly derived, see e.g. [26]. This yields the following.

Corollary 1. The space complexity of EU(n) for q queries is bounded from above by 2q(2n+log e)+O(log q).

An alternative approach. We now sketch another potential approach to lazy sampling of unitaries. Very
briefly, this approach takes a representation-theoretic perspective and suggests that the Schur transform [5]
could lead to a polynomial-time algorithm for lazy sampling Haar-random unitaries. The discussion below
uses tools and language from quantum information theory and the representation theory of the unitary and
symmetric groups to a much larger extent than the rest of the article, and is not required for understanding
our main results.

We remark that the analogous problem of lazy sampling a quantum oracle for a random classical function
was recently solved by Zhandry [32]. One of the advantages of Zhandry’s technique is that it partly recovers
the ability to inspect previously made queries, an important feature of classical lazy sampling. The key
insight is that the simulator can implement the Stinespring dilation of the oracle channel, and thus record
the output of the complementary channel.7 As the classical function is computed via XOR, changing to the
Zn2 -Fourier basis makes the recording property explicit. It also allows for an efficient implementation.

In the case of Haar-random unitary oracles, we can make an analogous observation. Consider an algorithm
that makes t parallel queries to U . The relevant Fourier transform is now over the unitary group, and is

given by the Schur transform [5]. By Schur-Weyl duality (see e.g. [12]), the decomposition of
(

C2n
)⊗t

into
irreducible representations is given by

(

C
d
)⊗t ∼=

⊕

λ⊢dt

[λ]⊗ Vλ,d. (2)

Here λ ⊢d t means λ is any partition of t into at most d parts, [λ] is the Specht module of St, and Vλ,d is
the Weyl module of U(d), corresponding to the partition λ, respectively. By Schur’s lemma, the t-twirling
channel acts as

T (t) =
⊕

λ⊢dt

id[λ] ⊗ ΛVλ,d
, (3)

where id is the identity channel, and Λ = Tr(·)τ with the maximally mixed state τ is the depolarizing
channel. We therefore obtain a Stinespring dilation of the t-twirling channel as follows. Let B̃, B̃′ be registers
with Hilbert spaces

HB̃ = HB̃′ =
⊗

λ⊢dt

VÎť,d (4)

and denote the subregisters by B̃λ and B̃′
λ, respectively. Let further |φ+〉B̃B̃′ be the standard maximally

entangled state on these registers, and let C be a register whose dimension is the number of partitions of t
(into at most 2n parts). Define the isometry

V̂AtB̃→AtB̃C =
⊕

λ⊢dt

FVΝ,dB̃Ν
⊗ I[λ] ⊗ |λ〉C (5)

7 The complementary channel of a quantum channel maps the input to the auxiliary output of the Stinespring
dilation isometry.

6



In the above equation VΝ,d and [Ν] are understood to be subspaces of At, the identity operators on B̃¾, ¾ 6= Ν
are omitted and F is the swap operator. By (3), a Stinespring dilation of the t-twirling channel is then given
by

VAt→AtB̃B̃′C = V̂AtB̃→AtB̃C |φ+〉B̃B̃′ . (6)

By the equivalence of all Stinespring dilations, the exists an isometry WB̂t→B̃B̃′C that transforms the state
register of EU(n) after t parallel queries so that the global state is the same as if the Stinespring dilation
above had been applied to the t input registers. But now the quantum information that was contained in
the subspace Vλ,d of the algorithm’s query registers can be found in register B̃λ.

1.4 Organization

The remainder of the paper is organized as follows. In Section 2, we recall some basic notation and facts,
and some lemmas concerning coherent preparation of certain generic families of quantum states. The proofs
for these lemmas are given in Appendix A. We also describe stateful machines, which will be our model
for thinking about the aforementioned ideal objects and their efficient simulators. In Section 3 we describe
our efficient simulator for Haar-random states, and in Section 4 we describe our polynomial-space simulator
for Haar-random unitaries. We end by describing the Haar money scheme and establishing its security in
Section 5.

1.5 Acknowledgments

The authors thank Yi-Kai Liu, Carl Miller, and Fang Song on helpful comments on an earlier draft. CM
thanks Michael Walter for discussions about t-designs. CM was funded by a NWO VIDI grant (Project No.
639.022.519) and a NWO VENI grant (Project No. VI.Veni.192.159). GA acknowledges support from NSF
grant CCF-1763736.

2 Preliminaries

2.1 Some basics

Given a fixed-size (e.g., n-qubit) register A, we will use A1, A2, . . . to denote indexed copies of A. We will use
At to denote a register consisting of t indexed copies of A, i.e., At = A1A2 ¡ ¡ ¡At. Unless stated otherwise,
distances of quantum states are measured in the trace distance, i.e.,

d(ρ, σ) =
1

2
‖ρ− σ‖1 where ‖X‖1 = Tr

(√
X†X

)

.

Distances of unitary operators are measured in the operator norm.
We will frequently apply operators to some subset of a larger collection of registers. In that context, we

will use register indexing to indicate which registers are being acted upon, and suppress identities to simplify
notation. The register indexing will also be suppressed when it is clear from context. For example, given an
operator XA→B and some state ρ on registers A and C, we will write X(ρ) in place of (X⊗1C)(ρ) to denote
the state on BC resulting from applying X to the A register of ρ.

We let |φ+〉AA′ denote the maximally entangled state on registers A and A′. For a linear operator X and
some basis choice, we denote its transpose by XT .

Lemma 1 (Mirror lemma; see, e.g., [22]). For XA→B a linear operator,

XA→B|φ+〉AA′ =

√

dim(B)

dim(A)
XT
B′→A′ |φ+〉BB′ .

7



2.2 Unitary designs

Let Âľn be the Haar measure on the unitary group U(2n). We define the Haar t-twirling channel T (t)
Haar by

T (t)
Haar(X) =

∍

U(2n)

U⊗tX
(

U⊗t
)†

dÂľ(U). (7)

For a finite subset D ⊂ U(2n), we define the t-twirling map with respect to D as

T (t)
D (X) =

1

|D|
∑

U∈D

U⊗tX
(

U⊗t
)†
. (8)

An n-qubit unitary t-design is a finite set D ⊂ U(2n) such that

T (t)
D = T (t)

Haar(X) (9)

Another twirling channel is the mixed twirling channels with ℓ applications of the unitary and t − ℓ
applications of it’s inverse,

T (ℓ,t−ℓ)
Haar (Γ ) =

∍

U(2n)

U⊗ℓ ⊗
(

U⊗(t−ℓ)
)†

Γ
(

U⊗ℓ
)† ⊗ U⊗(t−ℓ)dµ(U). (10)

The mixed twirling channel T (ℓ,t−ℓ)
D for a finite set D ⊂ U(2n) is also defined analogous to Equation (8). As

our definition of unitary t-designs is equivalent to one based on the expectation values of polynomials (see,
e.g., [21]), we easily obtain the following.

Proposition 1. Let D be an n-qubit unitary t-design and 0 ≤ ℓ ≤ t. Then

T (ℓ,t−ℓ)
Haar = T (ℓ,t−ℓ)

D (11)

Finite exact unitary t-designs exist. In particular, one can apply the following theorem to obtain an upper
bound on their minimal size. Here, a design for a function space W on a topological space X with measure
µ is a finite set D ⊂ X such that the expectation of a function f ∈ W is the same whether it is taken over
X according to Âľ or over the uniform distribution on D.

Theorem 5 ([19], Theorem 10). Let X be a homogeneous space, Âľ an invariant measure on X and W a
M -dimensional vector subspace of the space of real functions on X that is invariant under the symmetry group
of X, where M > 1. Then for any N > M(M − 1), there exists a W -design for X of size N . Furthermore,
there exists a design for X of size at most M(M − 1).

The case of unitary t-designs is the one where X = U(2n) is acting on itself (e.g., on the left), Âľ is the
Haar measure, and W is the vector space of homogeneous polynomials of degree t in both U and U †8. The
dimension of this space is

Mt =

(

22n + t− 1
t

)2

≤
(

e(22n + t− 1)

t

)t

, (12)

see e.g. [26]. We therefore get

Corollary 2. For all n, there exists an exact n-qubit unitary t-design with a number of elements which is
at most

(

e(22n + t− 1)

t

)2t

.

8 The output of the twirling channel (7) is a matrix of such polynomials.

8



2.3 Real and ideal stateful machines

We will frequently use stateful algorithms with multiple “interfaces” which allow a user to interact with
the algorithm. We will refer to such objects as stateful machines. We will use stateful machines to describe
functionalities (and implementations) of collections of oracles which relate to each other in some way. For
example, one oracle might output a fixed state, while another oracle reflects about that state.

Definition 1 (Stateful machine). A stateful machine S consists of:

– A finite set Λ, whose elements are called interfaces. Each interface I ∈ Λ has two fixed parameters
nI ∈ N (input size) and mI ∈ N (output size), and a variable tI initialized to 1 (query counter.)

– For each interface I ∈ Λ, a sequence of quantum algorithms {S.Ij : j = 1, 2, . . . }. Each S.Ij has an
input register of nI qubits, an output register of mI qubits, and is allowed to act on an additional shared
work register R (including the ability to add/remove qubits in R.) In addition, each S.Ij increments the
corresponding query counter tI by one.

The typical usage of a stateful machine S is as follows. First, the work register R is initialized to be empty,
i.e., no qubits. After that, whenever a user invokes an interface S.I and supplies nI qubits in an input
register M , the algorithm S.ItI is invoked on registers M and R. The contents of the output register are
returned to the user, and the new, updated work register remains for the next invocation. We emphasize
that the work register is shared between all interfaces.

We remark that we will also sometimes define ideal machines, which behave outwardly like a stateful
machine but are not constrained to apply only maps which are implementable in finite space or time. For
example, an ideal machine can have an interface that implements a perfectly Haar-random unitary U , and
another interface which implements U †.

2.4 Some state preparation tools

We now describe some algorithms for efficient coherent preparation of certain quantum state families. The
proofs for the following lemmas can be found in Appendix A. We begin with state families with polynomial
support.

Lemma 2. Let |ϕ〉 =
∑

x∈{0,1}n ϕ(x)|x〉 be a family of quantum states whose amplitudes ϕ have an efficient

classical description ϕ̃, and such t";"""date"",""2019-10-15T00:44:57Z""
""pdf:PDFVersion"",""1.4""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.4""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""xmp:CreateDate"",""2019-10-14T20:44:57Z""
""modified"",""2019-10-15T00:44:57Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""xmp:ModifyDate"",""2019-10-14T20:44:57Z""
""pdf:docinfo:creator"",""""
""meta:author"",""""
""meta:creation-date"",""2019-10-15T00:44:57Z""
""created"",""2019-10-15T00:44:57Z""
""xmp:About"",""uuid:8f5cc59a-2701-11f5-0000-8f5d6db64177""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-10-15T00:44:57Z""
""resourceName"",""1910.05729""
""Author"",""""
""producer"",""dvips + GPL Ghostscript GIT PRERELEASE 9.22""
""pdf:docinfo:producer"",""dvips + GPL Ghostscript GIT PRERELEASE 9.22""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""14"",""11"",""32"",""0"",""14"",""12"",""17"",""28"",""42"",""66"",""80"",""32"",""39"",""6"",""14"",""11"",""8"",""0"",""2"",""13"",""78"",""18""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2019-10-15T00:44:57Z""
""Last-Modified"",""2019-10-15T00:44:57Z""
""dcterms:modified"",""2019-10-15T00:44:57Z""
""title"",""""
""xmpMM:DocumentID"",""uuid:8f5cc59a-2701-11f5-0000-8f5d6db64177""
""Last-Save-Date"",""2019-10-15T00:44:57Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2019-10-15T00:44:57Z""
""meta:save-date"",""2019-10-15T00:44:57Z""
""Content-Length"",""371213""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""23""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""3209"",""3797"",""3518"",""3401"",""3598"",""2862"",""2392"",""1775"",""2592"",""2813"",""2292"",""1849"",""2455"",""2265"",""3253"",""2579"",""2503"",""2423"",""2918"",""3977"",""3601"",""3045"",""776""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-10-15T00:44:57Z""
";https://scholar.google.ch/scholar?start=790&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098897-402;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;[HTML][HTML] ???????? ??? ????????????????? ????????;?? ?????????? ; International Journal of Open Information …, 2020  cyberleninka.ru;;"… ???????? / ?????? ?? ????????? ???????? / BLACK BOX CONSTRUCTION /

BLOCKCHAIN / CRYPTOGRAPHIC HASH FUNCTIONS / CRYPTOGRAPHIC PRIMITIVE /

INFORMATION SECURITY / PROOF-OF-WORK / RANDOM ORACLE MODEL …";Cité 2 fois;Les 2 versions;[HTML] cyberleninka.ru;https://cyberleninka.ru/article/n/blokcheyn-kak-kriptograficheskiy-primitiv;"
    

    


    
      
        



  [image: Научная статья на тему 'БЛОКЧЕЙН КАК КРИПТОГРАФИЧЕСКИЙ ПРИМИТИВ'][image: ]



  БЛОКЧЕЙН КАК КРИПТОГРАФИЧЕСКИЙ ПРИМИТИВ Текст научной статьи по специальности «Математика»

  
    

    
    
      [image: ]CC BY

    
    
      [image: ]20
[image: ]7

    

  


  
    
    

  


	
  
    
      
        
          

        

        
          

        

        

      

    

  

  
  
    
       
         i
         Надоели баннеры? Вы всегда можете 
           отключить рекламу.
       

    

  


	

  
    
			
      Журнал[image: ]

      International Journal of Open Information Technologies
      
	      2020

        
  ВАК


      

    

    
      Область наук

      	Математика


    

  


  
  
    
      Ключевые слова

      
        
          БЛОКЧЕЙН / 
        
          ЗАЩИТА ИНФОРМАЦИИ / 
        
          КРИПТОГРАФИЧЕСКИЕ ХЭШ-ФУНКЦИИ / 
        
          КРИПТОГРАФИЧЕСКИЙ ПРИМИТИВ / 
        
          МОДЕЛЬ СО СЛУЧАЙНЫМ ОРАКУЛОМ / 
        
          BLACK BOX CONSTRUCTION / 
        
          BLOCKCHAIN / 
        
          CRYPTOGRAPHIC HASH FUNCTIONS / 
        
          CRYPTOGRAPHIC PRIMITIVE / 
        
          INFORMATION SECURITY / 
        
          PROOF-OF-WORK / 
        
          RANDOM ORACLE MODEL
        
      
    

  

  

  
  
    
      Аннотация научной статьи по математике, автор научной работы — Варновский Николай Павлович

      В работе блокчейн рассматривается как новый криптографический примитив, представляющий собой особую базу данных, записи в которой линейно упорядочены, а допустимые запросы к ней могут быть лишь двух видов - запросы на чтение записей (любым желающим) и на добавление записи в конец базы (пользователем, выполнившим определённые условия). При этом блокчейн должен удовлетворять требованиям живучести и незыблемости, гарантирующим добавление любой записи, коль скоро она снабжена необходимым подтверждением права на это действие, и «вечную сохранность» раз добавленной записи. Одним из основных является вопрос о принципиальной возможности построения такого криптографического примитива. В статье обсуждается проблема обоснования существования блокчейна в различных моделях, позволяющих использовать (гипотетически) этот примитив для защиты информации. Известные положительные результаты не дают удовлетворительного ответа на данный вопрос. В частности, все они получены в модели со случайным оракулом. В настоящей работе основное внимание уделено блокчейнам, отвечающим парадигме Proof-of-Work, в конструкции которых существенным образом используются криптографические хэш-функции. При сравнительно сильных предположениях доказан следующий отрицательный результат: при условии существования семейств хэш-функций с труднообнаружимыми коллизиями всегда найдутся такие семейства, на которых нельзя строить PoW-блокчейны. Как следствие, не существует blackbox-конструкции PoW-блокчейна на основе семейства хэш-функций с труднообнаружимыми коллизиями.

    

  

  

	
	
		
			
			        
					

				

			        
					

				

			

		

	

  
  
    
       
         i
         Надоели баннеры? Вы всегда можете 
           отключить рекламу.
       

    

  


	

	
    
      Похожие темы научных работ по математике , автор научной работы — Варновский Николай Павлович

      	Профессиональный библиограф составит и оформит по ГОСТ список литературы для вашей работы
Подбор литературы
	
          
            ОБ ОДНОМ КЛАССЕ ДИСКРЕТНЫХ ФУНКЦИЙ ДЛЯ СИНТЕЗА ПРОТОКОЛОВ СОГЛАСОВАНИЯ PROOF-OF-SPACE В БЛОКЧЕЙНАХ

            2020 / Логачев Олег Алексеевич, Федоров Сергей Николаевич
          
        
	
          
            Об универсальном древовидном режиме выработки хэш-кода

            2018 / Богданов Дмитрий Сергеевич, Дали Фархад Алишерович, Миронкин Владимир Олегович
          
        
	
          
            Криптографические хэш-функции, основанные на обобщённых клеточных автоматах

            2013 / Ключарёв П. Г.
          
        
	
          
            Метод построения криптографических хэш-функций на основе итераций обобщенного клеточного автомата

            2017 / Ключарёв Петр Георгиевич
          
        
	
          
            Применение алгоритмов решения проблемы булевой выполнимости к криптоанализу хэш-функций семейства MD

            2015 / Богачкова Ирина Александровна, Заикин Олег Сергеевич, Кочемазов Степан Евгеньевич, Отпущенников Илья Владимирович, Семёнов Александр Анатольевич
          
        


    

  


  
    
       iНе можете найти то, что вам нужно? Попробуйте сервис подбора литературы.

    

  


  
    

  


	
  
    
      
        
          

        

        
          

        

      

    

  

  
  
    
       
         i
         Надоели баннеры? Вы всегда можете 
           отключить рекламу.
       

    

  


	

  
  
    
      BLOCKCHAIN AS A CRYPTOGRAPHIC PRIMITIVE

      We consider blockchain as a new cryptographic primitive. This primitive is defined as an ordered database that allows only the following two types of queries: (a) read the data (by any user) and (b) add a new record to the end of the database (by a user who complied with certain requirements). A blockchain must satisfy the liveness and persistency conditions. The former condition guarantees that after a query to add a correct record, this record will eventually appear in the database. The latter one means that a record once added cannot be removed or modified. One of the main problems concerning blockchain is whether this primitive exists. The paper discusses this problem in various models. Known positive results do not provide a satisfactory answer to this problem. In particular, they are all proved in the random oracle model. In this paper, we focus on Proof-of-Work (PoW) blockchains that are based on cryptographic hash functions. Our main result is that if collision-resistant hash function families exist, then there exists such a family that cannot be used in a PoWblockchain. Therefore there is no black box construction of a PoW-blockchain from a collision-resistant hash function family.

    

  

  
  
    
      Текст научной работы на тему «БЛОКЧЕЙН КАК КРИПТОГРАФИЧЕСКИЙ ПРИМИТИВ»

      
				
        
          

        

				
        
        Блокчейн как криптографический примитив

         
        
        Н. П. Варновский

         
         
         
        
        Аннотация—В работе блокчейн рассматривается как новый криптографический примитив, представляющий собой особую базу данных, записи в которой линейно упорядочены, а допустимые запросы к ней могут быть лишь двух видов — запросы на чтение записей (любым желающим) и на добавление записи в конец базы (пользователем, выполнившим определённые условия). При этом блокчейн должен удовлетворять требованиям живучести и незыблемости, гарантирующим добавление любой записи, коль скоро она снабжена необходимым подтверждением права на это действие, и «вечную сохранность» раз добавленной записи.

         
         
         
        
        Одним из основных является вопрос о принципиальной возможности построения такого криптографического примитива. В статье обсуждается проблема обоснования существования блокчейна в различных моделях, позволяющих использовать (гипотетически) этот примитив для защиты информации. Известные положительные результаты не дают удовлетворительного ответа на данный вопрос. В частности, все они получены в модели со случайным оракулом.

         
         
         
        
        В настоящей работе основное внимание уделено блокчей-нам, отвечающим парадигме Proof-of-Work, в конструкции которых существенным образом используются криптографические хэш-функции. При сравнительно сильных предположениях доказан следующий отрицательный результат: при условии существования семейств хэш-функций с труднообнаружимыми коллизиями всегда найдутся такие семейства, на которых нельзя строить PoW-блокчейны. Как следствие, не существует blackbox-конструкции PoW-блокчейна на основе семейства хэш-функций с труднообна-ружимыми коллизиями.

         
         
         
        
        Ключевые слова—блокчейн, защита информации, криптографические хэш-функции, криптографический примитив, модель со случайным оракулом, blackbox-конструк-ции, Proof-of-Work

         
         
         
        
        I. Введение

         
         
         
        
        Посвящённая блокчейнам литература весьма обширна, и практически всегда в ней используется словосочетание «технология блокчейн». Однако, строго говоря, данный термин некорректен. Очевидно, что ни конкретные криптографические конструкции, ни способы их реализации в конкретных моделях не относятся к категории технологий. При этом понятие криптографического примитива здесь более чем уместно.

         
         
         
        
        По своей структуре блокчейн —это особая база данных, состоящая из линейно упорядоченных записей и допускающая только два вида запросов:

         
         
         
        
        •	запрос на чтение любой записи — доступен любому пользователю;

         
         
         
        
        •	запрос на добавление записи в конец базы данных — право пользователей на это действие определяется способом реализации блокчейна и конкретным приложением.

         
         
         
        
        Статья получена 17 ноября 2020.

         
         
         
        
        Николай Павлович Варновский, Институт проблем информационной безопасности МГУ им. М. В. Ломоносова, (email: math-dep@iisi.msu.ru).

         
         
         
        
        Собственно криптографическим примитивом, называемым блокчейном, такая база данных является при выполнении следующих двух основных требований.

         
         
         
        
        Первое условие (требование) связано с обеспечением свойства незыблемости (persistency). Содержательно оно означает, что никакая запись базы данных не может быть изменена или удалена. Более того, порядок записей зафиксирован раз и навсегда.

         
         
         
        
        Замечание 1. Стоит отметить, что указанное свойство имеет и негативный эффект в плане практического применения соответствующих систем. Специалистам по базам данных хорошо известно, что контроль входных данных представляет собой серьёзную научно-техническую проблему. Исправление ошибок в данных требует существенных затрат. В случае же блокчейна эта проблема и вовсе неразрешима: ошибки во внесённых записях исправить невозможно по определению.

         
         
           iНе можете найти то, что вам нужно? Попробуйте сервис подбора литературы.

         
         
        
        Второе условие — обеспечение свойства живучести (liveness): если подан запрос на добавление (в конец базы данных) записи, удовлетворяющей всем необходимым требованиям, то эта запись будет непременно добавлена в базу с задержкой, не превосходящей определённую величину. Требования к записи и определение допустимой задержки задаются спецификациями конкретных реализации и приложения блокчейна.

         
         
         
        
        Модели, в которых анализируются блокчейны, делятся на две больших категории — с контролем доступа (permissioned) и без контроля доступа (permissionless). В последнем случае добавлять записи в базу данных может любой пользователь, выполнивший все необходимые действия, предписанные протоколом. В первом же случае добавлять записи могут только те пользователи, которые получили на это соответствующее разрешение (это можно отнести к тем требованиям к записи, которые упоминались выше) от некоторого центрального органа управления и контроля, который, следовательно, должен быть предусмотрен в системе.

         
         
         
        
        В теоретических и прикладных исследованиях систем, связанных с защитой информации, рассматриваются центральные органы следующих трёх основных типов.

         
         
         
        
        Первый тип представляет выделенный участник (пользователь), выполняющий особые функции. Вопреки распространённому мнению, такой участник необходим и для блокчейнов без контроля доступа: кто-то должен, как минимум, инициировать процесс и задать начальное состояние блокчейна. С точки зрения криптографии, нельзя не учитывать возможность коррумпированности этого участника, однако сценарий с таким противником в литературе не рассматривается.

         
         
         
        
        Ко второму типу относится центр доверия, который представляет собой участника, наделённого доверием всех остальных пользователей. Стойкость соответствую-

         
         
         
        
        щей системы защиты информации анализируется только в предположении, что центр доверия — честный. Если же центр доверия отклоняется от предписанного поведения, должна иметься возможность доказать этот факт некоему арбитру.

         
         
         
        
        Третий тип центрального органа — большой брат (Big Brother): это центр доверия, действия которого не подвергаются контролю со стороны других пользователей, его нечестность недоказуема.

         
         
         
        
        Следует отметить, что в предполагаемых приложениях практически всегда присутствует какой-либо центральный орган, которому пользователи вынуждены доверять выполнение тех или иных функций. В связи с этим важно для конкретного приложения оценить степень доверия участников этому органу и проанализировать возможность реализации блокчейна в модели с центром доверия соответствующего вида. Естественно предположить, что в таком случае (когда, в отличие от первоначальной задумки, не имеет места полная децентрализация сети) для построения блокчейнов было бы достаточно использовать уже известные — и хорошо изученные — криптографические средства. Однако эта проблематика остаётся до сих пор неисследованной.

         
         
         
        
        По-видимому, только одно разумное приложение, реализуемое в модели без контроля доступа, можно выделить в имеющейся научной литературе по блокчейнам. Речь идёт о решении проблемы приоритета: представляется целесообразным использовать блокчейн для фиксации информации о научных открытиях, изобретениях и т. п.

         
         
         
        
        Первоначальная и наиболее популярная идея создания блокчейна без контроля доступа основана на май-нинге и протоколе консенсуса. Всякий желающий может добавить новую запись в базу данных, если решит так называемую умеренно трудную вычислительную задачу, которая определяется некоторой фиксированной криптографической хэш-функцией H. Запись r помещается в блок, содержащий также h-i —хэш-значение предыдущего блока — и некоторое специальное значение П. Умеренно трудная вычислительная задача состоит в поиске такого значения п, что выполнено неравенство H(h-1 ,r,n) < Dp, где Dp — параметр, определяющий трудность этой задачи. Процесс поиска такого значения п называется майнингом. На основе общих теоретических предположений о свойствах хэш-функций считается, без всякого обоснования, что параметр Dp можно задать таким образом, что при случайном выборе п указанное неравенство выполняется с вероятностью p.

         
         
         
        
        Благодаря включению в каждый добавляемый блок ссылки на предыдущий (h-i) весь массив блоков оказывается объединённым в цепочку, что, собственно, и породило (в английском варианте) термин «блокчейн».

         
         
         
        
        Каждый участник хранит у себя текущее состояние цепочки блоков и в случае успеха процедуры майнинга (положительного завершения протокола консенсуса), добавляет новый блок в конец цепочки и рассылает её всем участникам сети с помощью специального протокола (broadcast).

         
         
         
        
        Этот подход к созданию блокчейнов основан на так называемой парадигме проверки выполнения вычислительной работы (proof of work). Он предполагает, что

         
         
         
        
        честные участники контролируют большую часть вычислительных ресурсов сети.

         
         
         
        
        Исследования PoW-блокчейнов находятся пока на своём начальном этапе. Имеющиеся результаты, касающиеся вопросов существования такого криптографического примитива, можно трактовать лишь как частичное обоснование PoW-блокчейнов. Подробнее об этом будет сказано ниже, в разделе III.

         
         
           iНе можете найти то, что вам нужно? Попробуйте сервис подбора литературы.

         
         
        
        В литературе нередко встречаются утверждения, смысл которых сводится к следующему: поскольку так называемые криптовалюты используют PoW-блокчейны и существуют годами, такие блокчейны достаточно надёжны. Но следует заметить, что в некоторых теоретических работах, посвящённым криптовалютам, используются математические методы теории игр и исследования операций, а не математической криптографии. Поскольку в случае криптовалюты единственной целью участников является прибыль, вполне разумным представляется предположение о том, что подавляющее большинство участников использует рациональные стратегии. Однако оно неприменимо к криптографическому примитиву блокчейн, предназначенному для защиты информации (в определённом смысле).

         
         
         
        
        II. Математическая модель блокчейна

         
         
         
        
        Блокчейн как криптографический примитив определяется четвёркой следующих объектов: E — множество возможных (допустимых) записей, представляющих собой битовые строки конечной длины, E С {0,1}*; P — эффективно вычислимый трёхместный предикат; R — эффективный алгоритм, выполняющий запросы на чтение записей в блоках (этот компонент может отсутствовать: в предлагаемых реализациях, как правило, записи в блокчейне общедоступны); S — эффективный алгоритм, выполняющий запросы на добавление записей в конец базы данных. Запись r, данная в запросе, добавляется при выполнении условия P(state, r, proof) = 1, где state — состояние блокчейна на момент получения запроса (в общем случае под состоянием подразумевается вся цепочка блоков), proof — зависящая от типа блокчейна дополнительная информация, которая играет роль подтверждения права пользователя на добавление данной записи.

         
         
         
        
        Например, в общей схеме PoW-блокчейна необходимым и достаточным условием равенства P(state, r, п) = 1 (и, соответственно, возможности добавить запись) выступает выполнение неравенства H(h_1,r,n) < Dp и отношения r G E (в данном случае h_i определяется значением state). Если рассматривается модель с контролем доступа, следует добавить и условие, проверяющее полномочия данного абонента на добавление записей.

         
         
         
        
        Требование незыблемости блокчейна определяется следующим образом. Положим, state(t) —состояние блокчейна в момент времени t, представляющее собой последовательность имеющихся в нём на данный момент блоков. Тогда, для любых t1,t2 с условием t1 < t2 последовательность state(ti) должна быть префиксом последовательности state(t2).

         
         
         
        
        Второе требование — живучесть — означает существование такого числового параметра Д, что если в момент времени t выдан запрос на добавление записи r и предъявлено доказательство proof, удовлетворяющее условию

         
         
         
        
        P(state, r,proof) = 1, то в любой момент времени t', t' > t + А, блокчейн (его состояние) будет содержать запись r.

         
         
         
        
        Приведённые формулировки — это метаопределения, поскольку для полной формализации понятий незыблемости и живучести необходима модель противника, а она существенно зависит от конкретной реализации.

         
         
         
        
        III. Вопрос существования PoW-блокчейнов

         
         
         
        
        Далее будем рассматривать основной вариант реализации блокчейна, с майнингом и протоколом консенсуса.

         
         
         
        
        После того как введены всо необходимые определения, ваМноКшиП теоретическим вопросом становится ОйОснОванио существования даннОгО примитива. В работе [1] при определёнĐ";"""citation_keywords"",""БЛОКЧЕЙН, ЗАЩИТА ИНФОРМАЦИИ, КРИПТОГРАФИЧЕСКИЕ мЭШ-ФУНКЦИИ, КРИПТОГРАФИЧЕСКИЙ ПРИМИТИВ, МОДЕЛЬ СО СЛУЧАЙНЫМ ОРАКУЛОМ, BLACK BOX CONSTRUCTION, BLOCKCHAIN, CRYPTOGRAPHIC HASH FUNCTIONS, CRYPTOGRAPHIC PRIMITIVE, INFORMATION SECURITY, PROOF-OF-WORK, RANDOM ORACLE MODEL""
""og:image"",""https://cyberleninka.ru/article/n/blokcheyn-kak-kriptograficheskiy-primitiv/og""
""og:image:width"",""1074""
""twitter:card"",""summary_large_image""
""eprints.ispublished"",""pub""
""og:site_name"",""КиберЛенинка""
""keywords"",""научная статья бесплатно на тему БЛОКЧЕЙН КАК КРИПТОГРАФИЧЕСКИЙ ПРИМИТИВ текст научной работы по математике из научного журнала International Journal of Open Information Technologies. БЛОКЧЕЙН, ЗАЩИТА ИНФОРМАЦИИ, КРИПТОГРАФИЧЕСКИЕ ХЭШ-ФУНКЦИИ, КРИПТОГРАФИЧЕСКИЙ ПРИМИТИВ, МОДЕЛЬ СО СЛУЧАЙНЫМ ОРАКУЛОМ, BLACK BOX CONSTRUCTION, BLOCKCHAIN, CRYPTOGRAPHIC HASH FUNCTIONS, CRYPTOGRAPHIC PRIMITIVE, INFORMATION SECURITY, PROOF-OF-WORK, RANDOM ORACLE MODEL""
""eprints.pagerange"",""28-32""
""citation_journal_title"",""International Journal of Open Information Technologies""
""eprints.publication"",""International Journal of Open Information Technologies""
""language"",""ru""
""og:description"",""В работе блокчейн рассматривается как новый криптографический примитив, представляющий собой особую базу данных, записи в которой линейно упорядочены, а допустимые запросы к ней могут быть лишь двух видов - запросы на чтение записей (любым желающим) и на добавление записи в конец базы (пользователем, выполнившим определённые условия). При этом блокчейн должен удовлетворять требованиям живучести и незыблемости, гарантирующим добавление любой записи, коль скоро она снабжена необходимым подтверждением права на это действие, и «вечную сохранность» раз добавленной записи. Одним из основных является вопрос о принципиальной возможности построения такого криптографического примитива. В статье обсуждается проблема обоснования существования блокчейна в различных моделях, позволяющих использовать (гипотетически) этот примитив для защиты информации. Известные положительные результаты не дают удовлетворительного ответа на данный вопрос. В частности, все они получены в модели со случайным оракулом. В настоящей работе основное внимание уделено блокчейнам, отвечающим парадигме Proof-of-Work, в конструкции которых существенным образом используются криптографические хэш-функции. При сравнительно сильных предположениях доказан следующий отрицательный результат: при условии существования семейств хэш-функций с труднообнаружимыми коллизиями всегда найдутся такие семейства, на которых нельзя строить PoW-блокчейны. Как следствие, не существует blackbox-конструкции PoW-блокчейна на основе семейства хэш-функций с труднообнаружимыми коллизиями.""
""eprints.full_text_status"",""public""
""citation_issn"",""2307-8162""
""dc:title"",""БЛОКЧЕЙН КАК КРИПТОГРАФИЧЕСКИЙ ПРИМИТИВ – тема научной статьи по математике читайте бесплатно текст научно-исследовательской работы в электронной библиотеке КиберЛенинка""
""eprints.place_of_pub"",""Россия, Москва""
""Content-Encoding"",""UTF-8""
""citation_pdf_url"",""https://cyberleninka.ru/article/n/blokcheyn-kak-kriptograficheskiy-primitiv/pdf""
""robots"",""NOODP"",""noyaca""
""eprints.volume"",""8""
""eprints.citation"",""Варновский Николай Павлович БЛОКЧЕЙН КАК КРИПТОГРАФИЧЕСКИЙ ПРИМИТИВ // International Journal of Open Information Technologies. 2020. Выпуск номер 12 том 8, С.28-32""
""eprints.number"",""12""
""citation_author"",""Варновский Николай Павлович""
""resourceName"",""blokcheyn-kak-kriptograficheskiy-primitiv""
""citation_abstract_html_url"",""https://cyberleninka.ru/article/n/blokcheyn-kak-kriptograficheskiy-primitiv""
""citation_issue"",""12""
""eprints.abstract"",""We consider blockchain as a new cryptographic primitive. This primitive is defined as an ordered database that allows only the following two types of queries: (a) read the data (by any user) and (b) add a new record to the end of the database (by a user who complied with certain requirements). A blockchain must satisfy the liveness and persistency conditions. The former condition guarantees that after a query to add a correct record, this record will eventually appear in the database. The latter one means that a record once added cannot be removed or modified. One of the main problems concerning blockchain is whether this primitive exists. The paper discusses this problem in various models. Known positive results do not provide a satisfactory answer to this problem. In particular, they are all proved in the random oracle model. In this paper, we focus on Proof-of-Work (PoW) blockchains that are based on cryptographic hash functions. Our main result is that if collision-resistant hash function families exist, then there exists such a family that cannot be used in a PoWblockchain. Therefore there is no black box construction of a PoW-blockchain from a collision-resistant hash function family."",""В работе блокчейн рассматривается как новый криптографический примитив, представляющий собой особую базу данных, записи в которой линейно упорядочены, а допустимые запросы к ней могут быть лишь двух видов - запросы на чтение записей (любым желающим) и на добавление записи в конец базы (пользователем, выполнившим определённые условия). При этом блокчейн должен удовлетворять требованиям живучести и незыблемости, гарантирующим добавление любой записи, коль скоро она снабжена необходимым подтверждением права на это действие, и «вечную сохранность» раз добавленной записи. Одним из основных является вопрос о принципиальной возможности построения такого криптографического примитива. В статье обсуждается проблема обоснования существования блокчейна в различных моделях, позволяющих использовать (гипотетически) этот примитив для защиты информации. Известные положительные результаты не дают удовлетворительного ответа на данный вопрос. В частности, все они получены в модели со случайным оракулом. В настоящей работе основное внимание уделено блокчейнам, отвечающим парадигме Proof-of-Work, в конструкции которых существенным образом используются криптографические хэш-функции. При сравнительно сильных предположениях доказан следующий отрицательный результат: при условии существования семейств хэш-функций с труднообнаружимыми коллизиями всегда найдутся такие семейства, на которых нельзя строить PoW-блокчейны. Как следствие, не существует blackbox-конструкции PoW-блокчейна на основе семейства хэш-функций с труднообнаружимыми коллизиями.""
""eprints.eissn"",""2307-8162""
""citation_volume"",""8""
""format-detection"",""telephone=no""
""citation_publication_date"",""2020""
""citation_title"",""БЛОКЧЕЙН КАК КРИПТОГРАФИЧЕСКИЙ ПРИМИТИВ""
""eprints.date"",""2020""
""citation_publisher"",""Лаборатория Открытых Информационных Технологий факультета ВМК МГУ им. М.В. Ломоносова""
""eprints.type"",""article""
""description"",""В работе блокчейн рассматривается как новый криптографический примитив, представляющий собой особую базу данных, записи в которой линейно упорядочены, а допустимые запросы к ней могут быть лишь двух видов - запросы на чтение записей (любым желающим) и на добавление записи в конец базы (пользователем, выполнившим определённые условия). При этом блокчейн должен удовлетворять требованиям живучести и незыблемости, гарантирующим добавление любой записи, коль скоро она снабжена необходимым подтверждением права на это действие, и «вечную сохранность» раз добавленной записи. Одним из основных является вопрос о принципиальной возможности построения такого криптографического примитива. В статье обсуждается проблема обоснования существования блокчейна в различных моделях, позволяющих использовать (гипотетически) этот примитив для защиты информации. Известные положительные результаты не дают удовлетворительного ответа на данный вопрос. В частности, все они получены в модели со случайным оракулом. В настоящей работе основное внимание уделено блокчейнам, отвечающим парадигме Proof-of-Work, в конструкции которых существенным образом используются криптографические хэш-функции. При сравнительно сильных предположениях доказан следующий отрицательный результат: при условии существования семейств хэш-функций с труднообнаружимыми коллизиями всегда найдутся такие семейства, на которых нельзя строить PoW-блокчейны. Как следствие, не существует blackbox-конструкции PoW-блокчейна на основе семейства хэш-функций с труднообнаружимыми коллизиями.""
""title"",""БЛОКЧЕЙН КАК КРИПТОГРАФИЧЕСКИЙ ПРИМИТИВ – тема научной статьи по математике читайте бесплатно текст научно-исследовательской работы в электронной библиотеке КиберЛенинка""
""eprints.document_url"",""https://cyberleninka.ru/article/n/blokcheyn-kak-kriptograficheskiy-primitiv""
""twitter:site"",""@CyberLeninka""
""citation_fulltext_html_url"",""https://cyberleninka.ru/article/n/blokcheyn-kak-kriptograficheskiy-primitiv""
""eprints.keywords"",""БЛОКЧЕЙН, ЗАЩИТА ИНФОРМАЦИИ, КРИПТОГРАФИЧЕСКИЕ ХЭШ-ФУНКЦИИ, КРИПТОГРАФИЧЕСКИЙ ПРИМИТИВ, МОДЕЛЬ СО СЛУЧАЙНЫМ ОРАКУЛОМ, BLACK BOX CONSTRUCTION, BLOCKCHAIN, CRYPTOGRAPHIC HASH FUNCTIONS, CRYPTOGRAPHIC PRIMITIVE, INFORMATION SECURITY, PROOF-OF-WORK, RANDOM ORACLE MODEL""
""Content-Type-Hint"",""text/html; charset=utf-8""
""eprints.publisher"",""Лаборатория Открытых Информационных Технологий факультета ВМК МГУ им. М.В. Ломоносова""
""Content-Type"",""text/html; charset=UTF-8""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""og:type"",""article""
""eprints.title"",""БЛОКЧЕЙН КАК КРИПТОГРАФИЧЕСКИЙ ПРИМИТИВ""
""og:title"",""БЛОКЧЕЙН КАК КРИПТОГРАФИЧЕСКИЙ ПРИМИТИВ""
""og:image:height"",""480""
""eprints.creators_name"",""Варновский Николай Павлович""
""eprints.date_type"",""published""
""viewport"",""width=device-width, initial-scale=1""
""apple-mobile-web-app-capable"",""yes""
""og:url"",""https://cyberleninka.ru/article/n/blokcheyn-kak-kriptograficheskiy-primitiv""
""citation_eissn"",""2307-8162""
""eprints.metadata_visibility"",""show""
""eprints.refereed"",""TRUE""
""eprints.issn"",""2307-8162""
";https://scholar.google.ch/scholar?start=950&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098747-65;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;[LIVRE][B] Datenschutzrechtliche Verantwortlichkeit in Blockchain-Systemen;C Peitz ;2020 Springer;;"Page 1. Datenschutzrechtliche Verantwortlichkeit in Blockchain-Systemen Carlo Peitz Juridicum –

Schriften zum Medien-, Informations- und Datenrecht … Page 4. Carlo Peitz Datenschutzrechtliche

Verantwortlichkeit in Blockchain-Systemen Page 5. Carlo Peitz Neuss, Deutschland …";Les 2 versions;;null;;;;https://scholar.google.ch/scholar?start=610&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098738-50;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;BLOCKCHAIN KAO INFRASTRUKTURA PAMETNIH GRADOVA;M Ivandi? ;2020 zir.nsk.hr;;"… Ekonomski fakultet DIPLOMSKI RAD BLOCKCHAIN KAO INFRASTRUKTURA

PAMETNIH GRADOVA Mentor: Student … Centralizirani i decentralizirani pristup u

pametnim gradovima ..... 22 3. BLOCKCHAIN TEHNOLOGIJA ..... 24 3.1 …";Autres articles;;[PDF] nsk.hr;https://zir.nsk.hr/islandora/object/efst:3307/datastream/PDF/download;"
BLOCKCHAIN KAO INFRASTRUKTURA PAMETNIH
GRADOVA

Ivandić, Matej

Master's thesis / Diplomski rad

2020

Degree Grantor / Ustanova koja je dodijelila akademski / stručni stupanj: University of 
Split, Faculty of economics Split / Sveučilište u Splitu, Ekonomski fakultet

Permanent link / Trajna poveznica: https://urn.nsk.hr/urn:nbn:hr:124:158213

Rights / Prava: In copyright

Download date / Datum preuzimanja: 2021-04-28

Repository / Repozitorij:

REFST - Repository of Economics faculty in Split

https://urn.nsk.hr/urn:nbn:hr:124:158213
http://rightsstatements.org/vocab/InC/1.0/
https://repozitorij.efst.unist.hr
https://zir.nsk.hr/islandora/object/efst:3307
https://repozitorij.svkst.unist.hr/islandora/object/efst:3307
https://dabar.srce.hr/islandora/object/efst:3307


 
 

Sveučilište u Splitu 

Ekonomski fakultet 

 

 

 

 

 

 

 

DIPLOMSKI RAD 

 

BLOCKCHAIN KAO INFRASTRUKTURA 

PAMETNIH GRADOVA 

 

 

 

 

 

 

Mentor:         Student: 

izv.prof.dr.sc. Mario Jadrić       Matej Ivandić 

 

 

Lipanj 2020.godine, Split 

  



 
 

 SADRŢAJ 

1. UVOD ............................................................................................................ 1 

1.1. Problem istraĹŁivanja ..................................................................................................2 

1.2. Predmet istraĹŁivanja ..................................................................................................3 

1.3. Postavljanje istraţivačkih hipoteza ...........................................................................4 

1.4. Svrha istraĹŁivanja ......................................................................................................5 

1.5. Ciljevi istraĹŁivanja .....................................................................................................5 

1.6. Metode istraĹŁivanja ....................................................................................................6 

1.7. Doprinos istraĹŁivanja .................................................................................................7 

1.8. SadrĹŁaj diplomskog rada ...........................................................................................7 

2. PAMETNI GRADOVI ................................................................................... 9 

2.1. Definicija pametnog grada .........................................................................................9 

2.2. Internet of things i upotreba u gradovima .............................................................. 12 

2.3. Sigurnost podataka u pametnim gradovima ........................................................... 16 

2.4. Čimbenici pametnog grada ...................................................................................... 18 

2.5. Centralizirani i decentralizirani pristup u pametnim gradovima .......................... 22 

3. BLOCKCHAIN TEHNOLOGIJA ............................................................... 24 

3.1. Ĺ to je blockchain? .................................................................................................... 24 

3.1.1. Arhitektura blockchaina ....................................................................................... 26 

3.1.2. Blockchain protokoli ............................................................................................ 27 

3.2. Pametni ugovori ....................................................................................................... 29 

3.3. Vrste blockchain mreĹŁa ........................................................................................... 32 

3.3.1. Javna mreĹža ......................................................................................................... 33 

3.3.2. Privatna mreĹža ..................................................................................................... 34 

3.3.3. Hibridna mreĹža .................................................................................................... 35 

3.4. Prednosti blockchaina .............................................................................................. 36 

3.4.1. Decentralizacija ................................................................................................... 36 

3.4.2. Transparentnost ................................................................................................... 37 

3.4.3. Povjerljivost ........................................................................................................ 37 

3.4.4. Sigurnost ............................................................................................................. 38 

3.5. Problemi blockchaina ............................................................................................... 39 

3.5.1. Skalabilnost ......................................................................................................... 39 

3.5.2. Privatnost............................................................................................................. 40 



 
 

3.5.3. Pristup eksternim podacima ................................................................................. 41 

3.6. Primjena blockchaina u pametnim gradovima ....................................................... 41 

3.6.1. Javna uprava ........................................................................................................ 42 

3.6.2. Transport ............................................................................................................. 43 

3.6.3. Zdravstveni sustav ............................................................................................... 45 

3.6.4. Financijski sustav ................................................................................................ 46 

3.6.5. Energetski sustav ................................................................................................. 48 

4. EMPIRIJSKO ISTRAŽIVANJE ................................................................. 49 

4.1. Definiranje uzorka ................................................................................................... 49 

4.2. Metodologija istraĹŁivanja ........................................................................................ 49 

4.3. Rezultati i analiza provedenog istraĹŁivanja ............................................................ 49 

4.4. Testiranje hipoteza ................................................................................................... 51 

5. ZAKLJUČAK............................................................................................... 66 

6. SAŽETAK .................................................................................................... 67 

7. SUMMARY.................................................................................................. 67 

8. LITERATURA............................................................................................. 68 

Popis tablica i slika.......................................................................................................... 72 

Prilozi .............................................................................................................................. 74 



1 
 

1. UVOD 
 

Izazovi koji se javljaju pred modernim i suvremenim gradovima postaju sve veći, a brzi rast 

stanovništva i ograničenost resursa zahtijevaju bolje i učinkovitije upravljanje gradovima. 

Ispravno korištenje tehnologije može uvelike olakšati razvoj gradova i povećati kvalitetu 

Ĺživota u njima. 

Gradovi koji uspjeĹĄno koriste tehnoloĹĄka rjeĹĄenja za svakodnevno funkcioniranje nazivaju se 

pametni gradovi.  

Smart City ili pametni grad je pojam koji Washburn et al. (2010.)  definiraju kao grad koji 

koristi suvremene tehnologije za sastavljanje kritičnih infrastrukturnih komponenti i usluga 

grada - uključujući gradsku administraciju, obrazovanje, zdravstvo, javnu sigurnost, promet 

nekretninama, transport i komunalije – te ih čini inteligentnijima, meĎusobno povezanima i 

učinkovitijima. Singh (2018) pametni grad definira kao termin koji identificira tehnologiju 

kao pokretača ugodnog života. U studiji Harrison et al. (2010.), pametan grad označava 

instrumentirani, meĎusobno povezani i inteligentni grad. MohammadZadeh et al. (2019) 

navode da dolazi do povećanja broja pametnih gradova zbog povećanja broja pametno 

povezanih vozila i Interneta stvari (IoT) gdje je povezan širok raspon ureĎaja za razmjenu 

podataka. 

Grad je Ĺživi organizam koji se svakodnevno razvija, a da bi se grad ispravno razvio njegov 

razvoj je potrebno planirati, njime upravljati, kontrolirati ga i optimizirati.  

I pojam pametnog grada i blockchaina je već neko vrijeme u upotrebi. Haber i Storenetta 

(1991) prvi objavljuju rad o kriptografski povezanim blokovima, meĎutim blockchain kakav 

danas poznajemo se javlja kada je Nakamoto (2008) u svome radu iznio ideju o kriptovaluti 

Bitcoin. Pinna et al. (2018) smatraju da je sve do danas bitcoin najpoznatija i najvaĹžnija 

kriptovaluta. 

Tschorsch i Scheuermann (2016) blockchain predstavljaju kao decentraliziranu, 

nepromjenjivu i javnu bazu podataka. Koncept blockchaina temelji se na peer-to-peer mreĹžnoj 

arhitekturi u kojoj informacije o transakcijama ne kontrolira niti jedan centralizirani entitet. 

Transakcije pohranjene u lancu blokova javno su dostupne svim članovima blockchain mreže 

na pouzdan način, te mreža koristi konsenzusne mehanizme i kriptografiju za potvrĎivanje 



2 
 

legitimnosti transakcija podataka. Shibata (2019) smatra da je blockchain rastući popis 

blokova podataka koji su dizajnirani tako da budu otporni na promjene. Nguyen et al. (2019) 

navode da blockchain tehnologija preuzima svijet te je sa svojom decentraliziranom, 

transparentnom i sigurnom prirodom postao disruptivna tehnologija za novu generaciju 

brojnih industrijskih aplikacija. 

I dok su neke od ideja i prednosti koje se spominju u svezi blockchaina kao i pametnih 

gradova prenapuhane, oba koncepta i dalje mogu donijeti velike prednosti u razvoju modernih 

gradova. 

 

1.1. Problem istraĹživanja 
 

Današnji gradovi se susreću s mnogobrojnim problemima, kao što je logistika, transport, 

zdravstveni sustav, promet, javna uprava, rast stanovniĹĄtva, sigurnost, ubrzani rast cijena 

nekretnina i sl. Monzon (2015) smatra da su gradovi takoĎer mjesta na kojima su nejednakosti 

jače i ako se njima pravilno ne upravlja, negativni učinci mogu nadmašiti pozitivne. Pournaras 

(2019) navodi da urbana okruĹženja postaju veoma kompleksna i digitalno se transformiraju. 

Postavlja se pitanje može li tehnologija i tehnološka rješenja omogućiti bolji razvoj gradova i 

omogućiti pametnije upravljanje resursima. Chourabi et al. (2012.) navode da više od pola 

svjetskog stanovniĹĄtva Ĺživi u gradovima, te se trend iseljavanja stanovniĹĄtva iz sela u gradove 

očekuje i u narednim desetljećima.  

Routray et al. (2019) u svome radu navode da pametni gradovi omogućavaju mnoge nove 

usluge koje u tradicionalnoj gradskoj infrastrukturi nije moguće pravilno izvesti. U ovome 

radu će se istražiti upravo može li blockchain tehnologija kao jedno od tehnoloških rješenja 

omogućiti bolji i održiviji razvoj pametnih gradova. Sama činjenica da je u 2018. godini bilo 

4673 patenta, a u 2019. 2354 patenta iz područja blockchain tehnologije govori o zanimanju 

stručnjaka i najvećih svjetskih organizacija za ovo područje (Statista, 2019).  

Kichin (2014) smatra da je pametnom gradu prioritet analiza i prikupljanje podataka s ciljem 

podupiranja razvoja utemeljenog na informacijama, uvoĎenje novih načina tehnokratskog 

upravljanja, osnaživanje graĎana putem otvorenih, transparentnih informacija i poticanje 

ekonomskih inovacija i rasta. Podaci se stoga smatraju vaĹžnim sastavnim materijalom za 

ostvarivanje pametne vizije grada. Pametni gradovi podrazumijevaju veliku upotrebu Internet 



3 
 

of Things rjeĹĄenja i raznih senzora upravo radi prikupljanja podataka, a zbog same naravi 

takvog sadržaja Joh (2019) postavlja pitanje privatnosti graĎana i sigurnosti njihovih 

podataka. Biswas i Muthukkumarasamy (2016) smatraju da je značajni napredak u IoT-u i 

bežičnoj komunikaciji olakšao meĎusobno povezivanje niza ureĎaja i omogućio im 

sveprisutni prijenos podataka čak i s udaljenih mjesta. MeĎutim, ovi su sustavi koriste mnogo 

podataka kao ĹĄto su lokacije, osobne i financijske informacije i, stoga, moraju biti sposobni 

obraniti se od sigurnosnih napada.  Postoji nada da se ovi problemi mogu riješiti uz pomoć 

tehnologije koja se naziva blockchain. 

Becket al. (2018) predstavlja blockchain kao revolucionarnu tehnologiju. Liang et al. (2017) 

navode da je blockchain tehnologija privukla interes zbog zajedničke, distribuirane baze 

podataka koja je otporna na greĹĄke i u kojoj su razmjenjivane informacije otporne na 

manipulaciju. Blockchain mreža je distribuirana javna knjiga u kojoj o svakoj pojedinačnoj 

transakciji svjedoče te je provjeravaju mrežni čvorovi, a decentralizirana arhitektura može se 

iskoristiti za razvoj sigurne pohrane podataka. Kushch et al. (2019) govore o tome da je dizajn 

mehanizama kontrole pristupa brojnim sustavima izazovan te mora uspostaviti pravi odnos 

izmeĎu dozvola i ograničenja što se može takoĎer riješiti blockchainom. 

S obzirom da je prošla početna faza uzbuĎenja oko blockchain tehnologije i uz nju usko 

vezanih kriptovaluta istražiti će se stvarni primjeri primjene ove tehnologije u svrhu razvoja 

pametnih gradova, njen daljnji potencijal, te ostvaruju li gradovi koji koriste blockchain 

tehnologiju prednosti nad gradovima koji ne koriste ovu vrstu tehnologije.  

 

1.2. Predmet istraĹživanja 
 

Predmet istraživanja u ovome radu će biti pametni gradovi i blockchain tehnologija. 

Blockchain tehnologija moĹže smanjiti administraciju i ubrzati donoĹĄenje odluka. Smatra se da 

su decentralizacija i transparentnost jedne od ključnih prednosti ove tehnologije, a da se  

korištenjem pametnih ugovora, koji su jedna od ključnih funkcionalnosti, može povećati 

efikasnost pri upravljanju a njihovo automatsko izvršavanje, pri čemu nije potrebna prisutnost 

treće osobe, može ubrzati donošenje odluka. Nasulea i Mic (2018) smatraju da blockchain 

tehnologija ima ogroman potencijal kada je riječ o pametnim zajednicama budućnosti. 



4 
 

Često mijenjanje odluka i nemogućnost donošenja ispravnog automatiziranog rješenja 

predstavlja jedan od izazova koji se može riješiti blockchainom, a takoĎer, mnogi stručnjaci 

smatraju da blockchain tehnologija gradovima koji je koriste moĹže donijeti komparativnu 

prednost u odnosu na one gradove koji je ne koriste. Na taj način se ti gradovi mogu brže 

razvijati i povećati kvalitetu života svojih graĎana u odnosu na one koji je ne koriste. 

Transparentnost predstavlja još jednu potencijalnu prednost blockchaina, jer će se korištenjem 

te tehnologije omogućiti svakome na mreži uvid u sve trenutne i prethodne transakcije i kako 

se raspolaĹže resursima. Kim i Kang (2017) u svome radu govore o tome da se transakcije koje 

se odvijaju na javnoj blockchain mreži mogu lako pratiti što onemogućava netransparentnost i 

korupciju u radu. Kshetri i Voas (2018) smatraju da blockchain moĹže nadoknaditi nedostatak 

učinkovitih formalnih institucija, pravila, zakona, propisa i njihovu neučinkovitu primjenu. 

Smatra se da će ovakav način funkcioniranja i upravljanja gradom smanjiti stopu korupcije i 

povećati informiranost graĎana, a kao što je već spomenuto, s obzirom da pametni gradovi 

koriste mnoge senzore i ureĎaje za prikupljanje podataka i koriste te podatke za njihovu 

daljnju obradu, javlja se i pitanje moĹže li blockchain radi svoje decentralizirane i distribuirane 

strukture omogućiti sigurnu pohranu ovih podataka i onemogućiti njihovu manipulaciju.  

 

1.3. Postavljanje istraživačkih hipoteza 
 

U radu će se postaviti jedna glavna hipoteza i tri pomoćne hipoteze koje će pomoći u 

testiranju glavne hipoteze: 

H1: Blockchain predstavlja tehnologiju koja će u budućnosti sluţiti kao temelj za 

izgradnju rjeĹĄenja za pametne gradove 

H1.1: Decentralizacija i transparentnost su ključne prednosti blockchain tehnologije 

H1.2: Primjena blockchaina je povezana s povjerenjem prema javnim institucijama 

H1.3: Blockchain moţe povećati sigurnost rješenja za pametne gradove 

Rezultati empirijskog istraživanja dobiti će se provoĎenjem ankete. Pomoću prikupljenih 

podataka donijeti će se odluka za prihvaćanje ili odbacivanje navedenih hipoteza. Na taj način 



5 
 

će se odrediti je li blockchain perspektivna tehnologija koja može poslužiti u uspješnom 

razvoju pametnih gradova. 

Po provoĎenju anketnog istraživanja i prikupljanju svih podataka, pristupiti će se obradi istih. 

Za obradu podataka, odnosno utvrĎivanje rezultata istraživanja iz provedenog anketiranja 

koristiti će se statističke metode obrade podataka, kroz program SPSS Statistic Viewer. 

Različitim statističkim testiranjima se želi utvrditi postoji li ili ne postoji zavisnost izmeĎu 

dviju varijabli, pomoću čega će se utvrditi prihvaća li se ili odbacuje pomoćna, odnosno radna 

hipoteza. 

U ovome istraživanju će se za dokazivanje istinitosti pomoćnih hipoteza koristiti Spearmanov 

test korelacije ranga i crosstabulation.  

 

1.4. Svrha istraĹživanja 
 

Svrha istraživanja je istražiti mogućnosti primjene blockchaina kao podloge za razvoj 

pametnih gradova, te predstaviti kako ĹĄto bolje iskoristiti prednosti koje pruĹža ova tehnologija 

za povećanje učinkovitosti, transparentnosti i kvalitete gradova.  

U radu će se analizirati glavne karakteristike pametnih gradova i blockchain tehnologije, te će 

se identificirati osnovni problemi i prepreke koriĹĄtenja ove tehnologije u pametnim 

gradovima. Gervais et al. (2016) navode da od 2009. godine, blockchain je potaknuo  

inovacije i brojne nove aplikacije, poput pametnih ugovora, dizajnirane su tako da iskoriste 

prednost blockchaina. U ovome radu će se takoĎer istražiti i potencijalne primjene tehnologije 

u pametnim gradovima. Provedenim istraživanjem testirati će se hipoteze navedene u radu. 

 

1.5. Ciljevi istraĹživanja 
 

Cilj je koji se pokušava postići izradom ovoga rada je odgovoriti na postavljene hipoteze i 

doći do zaključaka je li blockchain može funkcionirati kao jedna od temeljnih tehnologija 

koje koriste pametni gradovi.  



6 
 

Dakle, u radu se pokušava utvrditi povećava li blockchain efikasnost pametnih gradova, 

olakšava li proces donošenja odluka, povećava li transparentnost u radu javne uprave, 

smanjuje li korupciju, povećava li sigurnost prikupljenih podataka i poboljšava li kvalitetu 

života graĎana.  

Istraživanjem će se ispitati ima li blockchain potencijal u razvoju pametnih gradova, ispitati 

će se koje su ključne prednosti blockchain tehnologije, te utjecaj blockchaina na povjerenje 

prema javnim institucijama i sigurnost podataka.  

 

1.6. Metode istraĹživanja 
 

Metode koje će se koristiti u izradi teorijskog dijela su (Zelenika, 1998): 

 Metoda analize – postupak kojim složene pojmove, sudove i zaključke raščlanjujemo 

na jednostavnije sastavnice. Analizirati će se pojmovi blockchaina, pametnih gradova, 

Internet of Things, te slični pojmovi koje treba pojednostaviti radi lakšeg shvaćanja,  

 Metoda indukcije – metoda kojom se na temelju činjenica i saznanja dolazi do nekih 

novih saznanja i spoznaja, tj. otkrivanja novih zakonitosti, a koristiti će se prilikom 

obrade sustava u kojima se blockchain potencijalno moĹže koristiti, te na temelju 

podataka prikupljenih iz anketnog istraživanja će se takoĎer izvući neki zaključci, 

 Metoda dedukcije –  metoda pomoću koje se iz općih sudova izvode posebni i 

pojedinačni zaključci primjenom deduktivnog načina zaključivanja, a koristiti će se 

prilikom istraživanja potencijala blockchain tehnologije, istraživanja ključnih 

prednosti te tehnologije i sl., 

 Metoda sinteze – postupak znanstvenog istraživanja i objašnjavanja stvarnost putem 

spajanja, sastavljenih jednostavnih misaonih tvorevina u sloĹžene i sloĹženijih u joĹĄ 

složenije, povezujući izdvojene elemente, pojave, procese i odnose u jedinstvenu 

cjelinu u kojoj u njezini dijelovi uzajamno povezani, a koristiti će se prilikom 

donošenja zaključaka o blockchainu kao tehnologiji koja se može upotrebljavati u 

svrhu razvoja pametnih gradova, 

 Metoda kompilacije – postupak preuzimanja tuĎih rezultata znanstvenoistraživačkog 

rada, odnosno tuĎih opažanja, stavova, zaključaka i spoznaja, te će se ova metoda 

koristiti kod teorijskog objaĹĄnjavanja pojmova tijekom cijelog rada, 



7 
 

 Metoda klasifikacije – postupak kojim se vrši sistemska podjela općeg pojma na 

posebne elemente koje taj pojam obuhvaća, a koristiti će se za one pojmove koje je 

nuĹžno objasniti, kao ĹĄto je pojam blockchaina i pametnog grada, 

 Metoda deskripcije – postupak jednostavnog opisivanja činjenica, predmeta i procesa 

u prirodi i društvu, te njihovih empirijskih potvrĎivanja i veza, ali bez znanstvenog 

tumačenja i objašnjavanja, a ova metoda će se koristit prilikom opisivanja raznih 

pojmova radi njihova lakšeg shvaćanja. 

 

1.7. Doprinos istraĹživanja 
 

Ovaj rad svoj doprinos daje onim istraĹživanjima koja istraĹžuju razvoj koncepta pametnih 

gradova i primjenu blockchain tehnologije. 

S obzirom na potrebu za boljom upotrebom resursa, boljom organizacijom i općenito boljim 

razvojem gradova javlja se potreba za rješenjima koja će pružiti poboljšanja u svim 

segmentima života graĎana. Riječ je o dvama popularnim pojmovima a ovaj rad može pomoći 

u boljem razumijevanju potencijala koje blockchain moĹže pruĹžiti u razvoju pametnih gradova. 

Blockchain se joĹĄ uvijek moĹže smatrati novom tehnologijom koja joĹĄ nije zaĹživjela u 

potpunosti, ali svakodnevno se razvijaju novi projekti i otkrivaju nove funkcionalnosti ove 

tehnologije. Potencijalna primjena ove tehnologije može omogućiti bolju podlogu za razvoj 

pametnih gradova, a pomoću ovoga istraživanja ispitati će se hipoteze koje će potencijalno 

pomoći drugima da bolje shvate koncepte pametnog grada, blockchaina i njihovu meĎusobnu 

povezanost. 

 

1.8. SadrĹžaj diplomskog rada 
 

Rad će se sastojati od dva dijela, teorijskog i empirijskog. U teorijskom dijelu rada će se 

objasniti i predstaviti pojmovi pametnog grada i blockchain tehnologije, izvući informacije i 

zaključci iz relevantnih istraživanja u ovim područjima, te kritički analizirati dobivene 

informacije. U drugom, empirijskom, dijelu rada na temelju odgovora dobivenih iz ankete će 

se odbaciti ili prihvatiti postavljene hipoteze.  



8 
 

Diplomski rad se sastoji od 5 poglavlja. 

Prvo poglavlje sluĹži kao uvod u diplomski rad te se u prvom poglavlju definiraju problem i 

predmet istraživanja, istraživačka pitanja, svrha i ciljevi istraživanja, te doprinos rada sličnim 

istraĹživanjima. 

U drugom poglavlju definirati će se koncept pametnih gradova, zašto se pametni gradovi 

smatraju „pametnima“ te će se istražiti na koji način na pametni gradovi funkcioniraju.  

Zatim, u trećem poglavlju,  detaljno će se objasniti blockchain tehnologija, njene prednosti i 

mane, predstaviti će se različite vrste blockchaina te mogućnosti primjene ove tehnologije u 

kontekstu pametnih gradova. 

U četvrtom poglavlju će se razraditi prikupljeni podaci putem ankete. Pomoću podataka 

dobivenih iz ankete, a koji će biti obraĎeni u programu SPSS, prihvatiti će se ili odbaciti 

postavljene hipoteze. 

U zadnjem, zaključnom poglavlju, će se dati zaključak autora o provedenom istraživanju, 

pruĹžiti saĹžetak rada te prikazati sva koriĹĄtena literatura. 

 

  



9 
 

2. PAMETNI GRADOVI 
 

2.1. Definicija pametnog grada 
 

Mnogi su već čuli za pojam pametnog grada, odnosno smart city, ovaj pojam spominju 

političari, mediji, znanstvenici, pa čak i obični graĎani, ali rijetki znaju što je zapravo pametni 

grad i ĹĄto bi pametni grad trebao predstavljati. Kako Albino et al. (2015) navode, razlog tome 

može biti to što koncept pametnog grada nije ograničen na primjenu tehnologija u gradovima. 

Zapravo se upotreba termina koristi u mnogim sektorima bez dogovorenih definicija. To je 

dovelo do zbrke meĎu kreatorima urbane politike s nadom da će njihove gradove učiniti 

pametnima. 

Postoje brojne inicijative u različitim gradovima da se ti gradovi naprave pametnijima, 

optimiziranijima, učinkovitijima te da povećaju kvalitetu života graĎana. Dok se većina 

gradova razvijala stihijski, čak i kroz povijest su postojali brojni primjeri u različitim 

drĹžavama gdje su se gradovi razvijali planski, kao ĹĄto je Brasilia, Canberra, Washington i sl. 

Danas u gradovima postoje veliki zahtjevi za tehnoloĹĄkim promjenama, digitalizacijom, 

ekološkim razvojem i boljim obrazovanjem, a najveće svjetske tvrtke ulaze na tržište razvoja 

pametnih gradova i razvijaju rjeĹĄenja koja bi mogla rijeĹĄiti mnoge probleme gradova.  

Naravno, svaki grad koji se smatra pametnim privlači nove investicije, a političarima pruža 

odobravanje javnosti, pa stoga postoji pitanje koliko je gradova koji se deklariraju kao 

„pametni“ stvarno pametni grad i kakva to rješenja pružaju. Često se ovime pojmom olako 

koristi te se brojni gradovi samoinicijativno proglaĹĄavaju pametnima bez da su stvarno 

implementirana adekvatna rješenja ili su ona tek polovično integrirana u razvoj grada. Pa se 

tako informatička rješenja za pojedinačan problem proglašavaju pametnima i na osnovu toga 

brojni gradovi dobivaju status pametnog grada. 

Zanella et al. (2014) smatraju da iako još ne postoji formalna i općenito prihvaćena definicija 

pametnog grada, konačna ciljeva stvaranja javnih resursa povećava kvalitetu usluga 

ponuĎenih graĎanima, smanjujući operativne troškove javnih uprava. Ovaj se cilj može 

slijediti primjenom urbanog IoT-a, tj. komunikacijske infrastrukture koja pruĹža jedinstven, 

jednostavan i ekonomičan pristup širokim javnim uslugama, čime se oslobaĎaju potencijalne 

sinergije i povećava transparentnost za graĎane. Aktivnost doista može utjecati na upravljanje 

i optimizaciju tradicionalnih javnih usluga , kao ĹĄto su prijevoz i parkiranje, rasvjeta, nadzor i 



10 
 

održavanje javnih površina, očuvanje kulturne baštine, odvoz smeća, blagostanje bolnica i 

ĹĄkola. 

Caraglia et al. (2011) navode da unatoč golemim izazovima i nedostacima povezanim s 

urbanim aglomeracijama, svjetsko se stanovniĹĄtvo kroz povijest neprestano koncentriralo u 

gradovima. Prema njihovim podacima doĹĄlo je do velikog porasta postotka koncentracije 

stanovništva u gradovima, s 5,1 posto 1790. godine na više od 75 posto američkog 

stanovništva koje se nalazilo u urbanim područjima 2000. godine što predstavlja poprilično 

velik i brz rast,a Lazaroiu i Roscia (2012) tvrde da gradovi troše veliku količinu energije, 

zahtijevajući više od 75% svjetske proizvodnje energije i generirajući 80% emisije 

stakleničkih plinova što predstavlja veliku prijetnju čovječanstvu, uzrokuje globalno 

zagrijavanje, skraćuje životni vijek graĎana i općenito smanjuje kvalitetu života.  

Prema Caraglia et al. (2011) grad je pametan kad ulaganja u ljudski i socijalni kapital te 

tradicionalnu (prometnu) i modernu (ICT) komunikacijsku infrastrukturu potiču održivi 

gospodarski rast i visoku kvalitetu Ĺživota, uz pametno upravljanje prirodnim resursima, a 

Lazaroiu i Roscia (2012) smatraju da razvoj pametnog grada predstavlja i neke nove izazove, 

odnosno gradski model u kojem tehnologija sluĹži pojedincu i njegovom poboljĹĄanju 

ekonomskog i druĹĄtvenog Ĺživota.  

Albino et al. (2015) u svome radu navode da Ballas (2013) smatra da u urbanističkom polju, 

termin ""pametni grad"" se često tretira kao pojma kojim vladajući žele ostvariti svoje strateške 

ciljeve, pa kao što je već spomenuto često taj pojam upotrebljavaju u svrhe kampanje i u 

slične svrhe.  

TakoĎer u svome radu predstavljaju dimenzije koje pametni gradovi moraju imati, definirane 

od strane različitih autora, a koje su vidljive u sljedećoj tablici. 

 

 

 

 

 

 



11 
 

Tablica 1: Dimenzije pametnih gradova 

Ključne dimenzije pametnog grada Izvor 

Informatička edukacija Mahizhnan (1999) 

IT infrastruktura 

IT ekonomija 

Kvaliteta Ĺživota 

Ekonomija Giffinger et al. (2007) 

Mobilnost 

OkoliĹĄ 

Ljudi 

Vlada 

Tehnologija Eger (2009) 

Ekonomski razvoj 

Razvoj poslova 

Povećana kvaliteta života 

Kvaliteta Ĺživota Thuzar (2011) 

OdrĹživi ekonomski razvoj 

Gospodarenje prirodnim resursima kroz 

participativnu politiku 

Konvergencija ekonomskih, socijalnih i okoliĹĄnih 

ciljeva 

Ekonomska povezanost Nam and Pardo (2011) 

Društveno-politička pitanja grada 

Ekonomsko-tehničko-socijalna pitanja okoliša 

Instrumentacija 

Integracija 

Aplikacije 

Inovacije 

Ekonomski faktori (BDP, snaga sektora, 

meĎunarodne transakcije, strane investicije) 

Barrionuevo et al. (2012) 

 

Ljudski faktori (talent, inovativnost, kreativnost, 

obrazovanje) 

Socijalni faktori (tradicije, navike, religije, obitelji) 

OkoliĹĄ (energetske politike, upravljanje otpadom i 

vodama, krajolik) 

Institucionalni faktori (graĎanski angažman, 

upravna vlast, izbori) 

Ljudski kapital (npr. kvalificirana radna snaga) Kourtit and Nijkamp (2012) 



12 
 

Infrastrukturni kapital (npr. visokotehnoloĹĄki 

komunikacijski objekti) 

DruĹĄtveni kapital (npr. intenzivne i otvorene 

mreĹžne veze) 

Poduzetnički kapital (npr. kreativne i rizične 

poslovne aktivnosti) 

MenadĹžment i organizacija Chourabi et al. (2012) 

Tehnologija 

Vlada 

Politika 

Ljudi i zajednice 

Ekonomija 

IzgraĎena infrastruktura 

Prirodno okruĹženje 

Izvor: Smart Cities: Definitions, Dimensions, Performance, and Initiatives 

Najčešće karakteristike pametnih gradova koje proizlaze iz ove tablice su (ibid.):  

 gradska mrežna infrastruktura omogućuje političku učinkovitost i socijalni i kulturni 

razvoj. 

 naglasak je na poslovni urbani razvoj i kreativne aktivnosti za promicanje urbanog 

rasta.  

 bitna je socijalna uključenost raznih gradskih stanovnika i bitan je socijalni kapital u 

urbanom razvoju.  

 prirodno okruženje je strateška komponenta budućnosti. 

 

2.2. Internet of things i upotreba u gradovima 
 

Internet of Things (IoT) je pojam koji je prvi upotrijebio Kevin Ashton 1999. godine. Kao ĹĄto 

sam Ashton (2009) navodi tehnologija je dugo vremena bila ovisna o ljudima i njihovoj 

sposobnosti generiranja informacija. MeĎutim, ljudi imaju odreĎena fizička ograničenja koja 

se odražavaju na količinu podataka koja je prikupljena. Kada bi stvari, kao što su strojevi, 

kućna pomagala i sl. prikupljali podatke bez ljudske intervencije to bi uvelike smanjilo 

troĹĄkove, vrijeme potrebno za prikupljanje podataka i gubitak vrijednih podataka. 



13 
 

Zanella et al. (2014) navode da će internet stvari (IoT) moći transparentno i neprimjetno 

ugraditi veliki broj različitih i heterogenih sustava, istovremeno pružajući otvoreni pristup 

odabranim podskupovima podataka za razvoj razvojnih aplikacija. Izgradnja opće arhitekture 

za IoT stoga je vrlo složen zadatak, uglavnom zbog izuzetno velike raznolikosti ureĎaja, 

tehnologija i usluga koji mogu biti uključeni u takav sustav. Riječ je o nedavnoj 

komunikacijskoj paradigmi koja predviĎa blisku budućnost u kojoj će predmeti svakodnevnog 

Ĺživota biti opremljeni mikrokontrolerima, primopredajnicima za digitalnu komunikaciju i 

prikladnim protokolima koji će omogućiti ureĎajima meĎusobnu komunikaciju i omogućiti 

ureĎajima da postanu sastavni dio interneta. 

Dakle, Internet stvari se može opisati kao velika količina ureĎaja koji pomoću različitih vrsta 

senzora prikupljaju podatke, povezani su na internet te mogu ostvariti meĎusobnu 

komunikaciju kao i komunikaciju s ljudima. 

Xia et al. (2012) smatraju da zahvaljujući brzom napretku tehnologije, IoT otvara ogromne 

mogućnosti za veliki broj novih aplikacija koje obećavaju poboljšanje kvalitete našeg života. 

Posljednjih godina IoT je privukao veliku pažnju istraživača i korisnika iz cijelog svijeta. 

Zane";"""date"",""2021-04-28T10:40:56Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.4""
""xmp:CreatorTool"",""MicrosoftÂŽ Word 2010""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dc:creator"",""SHAQ""
""language"",""hr""
""dcterms:created"",""2021-04-28T10:40:56Z""
""Last-Modified"",""2021-04-28T10:40:56Z""
""dcterms:modified"",""2021-04-28T10:40:56Z""
""dc:format"",""application/pdf; version=1.4""
""Last-Save-Date"",""2021-04-28T10:40:56Z""
""pdf:docinfo:creator_tool"",""MicrosoftÂŽ Word 2010""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2021-04-28T10:40:56Z""
""meta:save-date"",""2021-04-28T10:40:56Z""
""pdf:encrypted"",""false""
""modified"",""2021-04-28T10:40:56Z""
""Content-Length"",""1796885""
""pdf:hasMarkedContent"",""true""
""Content-Type"",""application/pdf""
""pdf:docinfo:creator"",""SHAQ""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""SHAQ""
""dc:language"",""hr-HR""
""meta:author"",""SHAQ""
""meta:creation-date"",""2021-04-28T10:40:56Z""
""created"",""2021-04-28T10:40:56Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""81""
""Creation-Date"",""2021-04-28T10:40:56Z""
""resourceName"",""download""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""476"",""221"",""3918"",""2166"",""2216"",""2358"",""2372"",""2152"",""1787"",""2174"",""1942"",""992"",""2464"",""1809"",""1105"",""1449"",""2331"",""2390"",""2343"",""2438"",""2637"",""1479"",""1633"",""1851"",""1316"",""1124"",""2363"",""2484"",""2666"",""2226"",""1277"",""2482"",""2564"",""2777"",""1982"",""1665"",""1884"",""2427"",""2228"",""2449"",""1949"",""2433"",""2382"",""2397"",""2472"",""2349"",""2167"",""2675"",""2390"",""2257"",""2185"",""1682"",""1480"",""420"",""1481"",""1348"",""1284"",""1264"",""1071"",""430"",""1069"",""950"",""446"",""1112"",""1017"",""1038"",""977"",""947"",""794"",""2448"",""2082"",""2280"",""2218"",""2237"",""2160"",""2099"",""1413"",""913"",""1022"",""1014"",""484""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""Author"",""SHAQ""
""producer"",""dompdf 0.8.6
 + CPDF""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""dompdf 0.8.6
 + CPDF""
""pdf:docinfo:created"",""2021-04-28T10:40:56Z""
";https://scholar.google.ch/scholar?start=590&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098774-130;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Subvert KEM to Break DEM: Practical Algorithm-Substitution Attacks on Public-Key Encryption;R Chen, X Huang, M Yung ; International Conference on the Theory and …, 2020  Springer;;"… In Crypto 2014, Bellare, Paterson, and Rogaway [7] initiated the formal study of algorithm-

substitution attack … A}\) is an algorithm with inputs \(x,y,\cdots \) and access to oracle \({\mathcal

{O … of running \(\mathcal {A}\) with inputs \((x,y,\cdots )\) and access to oracles \({\mathcal {O …";Cité 2 fois;Les 2 versions;[PDF] iacr.org;https://eprint.iacr.org/2020/1079.pdf;"
A preliminary version of this paper appears in Advances in Cryptology - ASIACRYPT 2020.
This is the full version.

Subvert KEM to Break DEM:

Practical Algorithm-Substitution Attacks on Public-Key

Encryption

Rongmao Chen ∗

chromao@nudt.edu.cn

Xinyi Huang †

xyhuang@fjnu.edu.cn

Moti Yung ‡

moti@cs.columbia.edu

September 8, 2020

Abstract

Motivated by the currently widespread concern about mass surveillance of encrypted
communications, Bellare et al. introduced at CRYPTO 2014 the notion of Algorithm-
Substitution Attack (ASA) where the legitimate encryption algorithm is replaced by a sub-
verted one that aims to undetectably exfiltrate the secret key via ciphertexts. Practically
implementable ASAs on various cryptographic primitives (Bellare et al., CRYPTO’14 &
ACM CCS’15; Ateniese et al., ACM CCS’15; Berndt and Lískiewicz, ACM CCS’17) have
been constructed and analyzed, leaking the secret key successfully. Nevertheless, in spite
of much progress, the practical impact of ASAs (formulated originally for symmetric key
cryptography) on public-key (PKE) encryption operations remains unclear, primarily since
the encryption operation of PKE does not involve the secret key, and also previously known
ASAs become relatively inefficient for leaking the plaintext due to the logarithmic upper
bound of exfiltration rate (Berndt and Lískiewicz, ACM CCS’17).

In this work, we formulate a practical ASA on PKE encryption algorithm which, perhaps
surprisingly, turns out to be much more efficient and robust than existing ones, showing that
ASAs on PKE schemes are far more effective and dangerous than previously believed. We
mainly target PKE of hybrid encryption which is the most prevalent way to employ PKE in
the literature and in practice. The main strategy of our ASA is to subvert the underlying key
encapsulation mechanism (KEM) so that the session key encapsulated could be efficiently
extracted, which, in turn, breaks the data encapsulation mechanism (DEM) enabling us to
learn the plaintext itself. Concretely, our non-black-box yet quite general attack enables
recovering the plaintext from only two successive ciphertexts and minimally depends on a
short state of previous internal randomness. A widely used class of KEMs is shown to be
subvertible by our powerful attack.

Our attack relies on a novel identification and formalization of certain properties that
yield practical ASAs on KEMs. More broadly, it points at and may shed some light on
exploring structural weaknesses of other “composed cryptographic primitives,” which may
make them susceptible to more dangerous ASAs with effectiveness that surpasses the known
logarithmic upper bound (i.e., reviewing composition as an attack enabler).

∗National University of Defense Technology. Part of this work was done while visiting COSIC in KU Leuven.
†Fujian Provincial Key Laboratory of Network Security and Cryptology, College of Mathematics and Infor-

matics, Fujian Normal University, China
‡Columbia University & Google



Contents

1 Introduction 2
1.1 Algorithm-Substitution Attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 Our Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2 Preliminaries 7
2.1 Entropy Smoothing Hash Functions . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2 Key Encapsulation Mechanism (KEM) . . . . . . . . . . . . . . . . . . . . . . . . 7

3 Asymmetric ASA Model for KEMs 8
3.1 Asymmetric ASA on KEMs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.2 Session Key Recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.3 Undetectability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

4 Mounting ASAs on KEMs 11
4.1 A Module-Level Syntax of KEM . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.2 Our Non-Black-Box ASA on KEMs . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.3 Formal Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

5 Instantiations 19
5.1 KEMs from Hash Proof Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
5.2 Concrete KEMs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

6 Discussions on Countermeasures 23
6.1 Abandoning Randomized Algorithms . . . . . . . . . . . . . . . . . . . . . . . . . 23
6.2 Permitting Randomized Algorithms with Further Assumptions . . . . . . . . . . 24

7 Conclusions 25

A Omitted Definitions, Proof and Instantiations 28
A.1 Hash Proof System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
A.2 Proof of Theorem 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
A.3 Instantiating HPSs from Graded Rings . . . . . . . . . . . . . . . . . . . . . . . . 29

B Constructing Subversion-Resistant KEMs 30
B.1 Subversion-resistant KEMs in the Cliptographic Model . . . . . . . . . . . . . . . 30
B.2 Further Discussions on other Approaches . . . . . . . . . . . . . . . . . . . . . . 34

C ASA on Hybrid Encryption 36

1



1 Introduction

Provable security provides strong guarantees for deploying cryptographic tools in the real world
to achieve security goals. Nevertheless, it has been shown that even provably secure cryptosys-
tems might be problematic in practice. Such a security gap—between the ideal and the real
world—lies in the fact that the robustness of provable security closely depends on the adopted
adversarial model which, however, often makes idealized assumptions that are not always ful-
filled in actual implementations.

An implicit and common assumption—in typical adversarial models for provable security—
is that cryptographic algorithms should behave in the way specified by their specifications. In
the real world, unfortunately, such an assumption may turn out to be invalid due to a variety of
reasons such as software/hardware bugs and even malicious tampering attacks. In particular,
attackers (manufacturers and supply-chain intermediaries), in reality, may be able to modify
the algorithm implementation so that the subverted one remains indistinguishable—in black-
box testing—from the specification, while leaking private information (e.g., secret keys) during
its subsequent runs. The threat was originally identified as kleptography by Young and Yung
[35, 36] over two decades ago, while the Snowden revelations of actual deployments of such
attacks (in 2013) attracted renewed attention of the research community [7, 6, 3, 17, 5, 29, 18,
12, 20, 32, 9, 10, 28, 33, 34, 21, 4, 13].

1.1 Algorithm-Substitution Attacks

In Crypto 2014, Bellare, Paterson, and Rogaway [7] initiated the formal study of algorithm-
substitution attack (ASA), which was defined broadly, against symmetric encryption. In the
ASA model, the encryption algorithm is replaced by an altered version created by the adversary.
Such a substitution is said to be undetectable if the detector—who knows the secret key—
cannot differentiate subverted ciphertexts from legitimate ones. The subversion goal of an
ASA adversary is to gain the ability to recover the secret key from (sequential) subverted
ciphertexts. Concretely, [7] proposed actual substitution attacks against certain symmetric
encryption schemes.

Subsequently, Degabriele, Farshim and Poettering [17] further justified Bellare et al.’s ASA
model [7] from an increased practical perspective, and redefined the security notion by relax-
ing the assumption that any subverted ciphertext produced by the altered algorithm should
be decryptable. Bellare, Jaeger and Kane [6] strengthened the undetectability notion of [7] by
considering stronger detectors which are able to adaptively feed the encryption code with some
specified inputs and see all outputs written to memory, including the current state of the en-
cryption code. They then designed stateless ASAs against all randomized symmetric encryption
schemes. In [3], Ateniese, Magri and Venturi extended the ASA model and studied signature
schemes in the setting of fully-adaptive and continuous subversion. Berndt and Lískiewicz [9], in
turn, rigorously investigated the relationship between ASAs and steganography—a well-known
concept of hiding information in unsuspicious communication. By modeling encryption schemes
as steganographic channels, they showed that successful ASAs correspond to secure stegosys-
tems on the channels and vice versa. This indicates a general result that there exist universal
ASAs—work with no knowledge on the internal implementation of the underlying cryptographic
primitive—for any cryptographic algorithm with sufficiently large min-entropy, and in fact al-
most all known ASAs [7, 6, 3] are universal ASAs.

In this work, we turn to another fundamental cryptographic primitives, i.e., public-key
encryption (PKE), aiming at better understanding the impact of ASAs on PKE systems. Indeed,
Bellare, Paterson and Rogaway mentioned in [7] that:

2



“...one can consider subversion for public-key schemes or for other cryptographic goals,
like key exchange. There are possibilities for algorithms-substitution attacks (ASAs) in
all these settings...the extensions to cover additional schemes is an obvious and important
target for future research.”

At first glance, the general result by Berndt and Lískiewicz [9] has already illustrated the
feasibility of ASAs on randomized PKE algorithms, and, further, a concrete attack was indeed
exhibited on the CPA-secure PKE by Russell et al. [33] (where their main result was a concrete
architectural setting and construction to prevent such attacks). However, as we will explain
below, the impact of such univerisal ASAs on PKE encryption algorithm turns out to be much
weaker (i.e., much less efficient) than those on symmetric encryption [7, 6]. We concentrate in
this work on subverting the system via the content of its ciphertexts.

Limited efficiency and impact of previously known ASAs on PKE. It is proved that
the exfiltration rate of universal ASAs—the number of embedded bits per ciphertext—suffers
a logarithmic upper bound[9]. Concretely, for the case of encryption schemes, no universal and
consistent ASA is able to embed more than log(Îş) (Îş is the key length) bits of information into a
single ciphertext in the random oracle model. Although this upper bound is somewhat limited,
it does not significantly weaken the impact of universal ASAs on secret-key algorithms [7, 6, 3],
since given sufficient ciphertexts—or sufficient signatures in the case of signature schemes—the
adversary can extract the whole secret key, and afterwards can completely break the security
of these algorithms, as long as the underlying secret key remains unchanged. However, when it
comes to the case of PKE, the impact of universal ASAs turns out to be quite impractical as
the encryption procedure of PKE has only access to the public key, and thus it is impossible
to leak the secret key via subverting the PKE encryption algorithm itself (via the ciphertexts).
Hence, as we see it, the best possible goal for ASAs on PKE encryption procedure is to recover
plaintexts. For legitimate users, this seems somewhat positive as different from the (fixed)
secret key, the plaintext is usually much longer, and thus the adversary needs to collect much
more ciphertexts—due to the logarithmic upper bound of universal ASAs—to recover the whole
plaintext successfully. Note that although gaining one-bit information of plaintext suffices for
the adversary to win the indistinguishibility-based security game (e.g., IND-CPA), such a bit-
by-bit recovery of plaintext is rather inefficient and thus not desirable from the point of view of
the adversary, especially given the fact that plaintexts are usually fresh across various encryption
sessions in reality.

Concrete examples. We apply Bellare et al.’s ASAs [7, 6] to PKE to give a more intuitive
picture. Precisely, the biased ciphertext attack [7]—using rejection sampling of randomness—
could be also mounted on PKE and it has been indeed proposed by Russell et al. [33] to leak the
plaintext bit from the subverted PKE ciphertext. However, such an attack could only leak one
bit of information per subverted ciphertext, and thus fully recovering a plaintext would (at least)
require as many ciphertexts as the length of a plaintext. This concretely shows that existing
ASAs are relatively inefficient on PKE. Moreover, such an attack is stateful with a large state,
as it needs to maintain a global counter that represents which bit(s) of the plaintext it is trying
to exfiltrate in each run. This weakens the robustness of attacks in practice as it depends on a
state related to a long system history, in order to successfully leak the whole plaintext of PKE
encryption. Note also that the strong ASA proposed in [6]—although being stateless—turns
out to be much less efficient on PKE due to the application of the coupon collector’s problem.

Our concrete question: efficient and robust ASAs on PKE? The aforementioned ob-
servations and the importance of better understanding of the impact of ASAs, motivated us to
consider the following question:

3



Are there ASAs that could be efficiently mounted on a wide range of PKE schemes and
only have much limited (i.e., constant length) dependency on the system history?

In particular, we mainly consider the possibility of practical ASAs on PKE that enable the
plaintext recovery with a constant number—independent of the plaintext length—of ciphertexts
while only depending on a short system history. Generally, a stateful attack is more robust
if its state depends on just a small history. For example, in the backdoored Dual EC DRBG
(Dual Elliptic Curve Deterministic Random Bit Generator)[11], an attack which apparently
was successfully employed, there is a dependency on prior public randomness and learning the
current seed. Nevertheless, it turned out to be deployed and the limited dependency does not
weaken its impacts on practical systems. This is mainly due to the fact that an implementation
of pseudo-random generators (PRGs), in fact, needs to maintain some states and the state
of generators always persists for a while at least in systems (hence, some limited dependency
on the past is natural, whereas long history dependency is not that typical and creates more
complicated state management).

Remark: Young and Yung’s Kleptography [35, 36, 37]. In the line of kleptography, subversions
of PKE have been studied (primarily of key generation procedures of PKE) by Young and Yung
[35, 36, 37]. They introduced the notion of secretly embedded trapdoor with universal protection
(SETUP) mechanism, which enables the attacker to exclusively and efficiently recover the user
private information. Young and Yung showed how SETUP can be embedded in several concrete
cryptosystems including RSA, ElGamal key generation and Diffie-Hellman key exchange [35,
36, 37]. Our motivation may be viewed as a modern take on Young and Yung’s kleptographic
attacks on PKE key generation, but in the ASA model against the encryption operation itself,
and particularly we ask: to what extent their type of attacks may be extended to cover PKE
encryption algorithms (and composed methods like hybrid encryption) more generally?

1.2 Our Results

In this work, we provide an affirmative answer to the above question by proposing a practical
ASA that is generically applicable to a wide range of PKE schemes, demonstrating that ASAs
on PKE could be much more dangerous than previously thought. Our idea is initially inspired
by the observation that almost all primary PKE constructions adopt the hybrid encryption:
a public key cryptosystem (the key encapsulation mechanism or KEM) is used to encapsulate
the so-called session key which is subsequently used to encrypt the plaintext by a symmetric
encryption algorithm (the data encapsulation mechanism or DEM). Specifically, we turn to
consider the possibility of substituting the underlying KEM stealthily so that the attacker is
able to recover the session key to break the DEM (and thereafter recover the plaintext). The
idea behind such an attack strategy is somewhat intuitive as compared with the plaintext
that might be of arbitrary length, the session key is usually much shorter and thus easier to
recover. However, this does not immediately gain much efficiency improvement in subverting
PKE encryption, mainly due to the fact that the underlying KEM produces fresh session keys in
between various encryption invocations. Hence, we further explore the feasibility of efficient ASA
on KEMs that could successfully recover a session key from a constant number of ciphertexts.
Given the logarithmic upper bound of universal ASAs [9], we turn to study the possibility of
non-black-box yet still general ASAs.

To the end, due to the successful dentification of a general structural weakness in existing
KEM constructions, we manage to mount a much more efficient ASA on KEMs that could
recover a session key from only two successive ciphertexts, which means that the state required
by the attack is much smaller than the generic one. In fact, the state relation (as we will discuss

4



below) in our proposed ASA is similar to that of the well-known Dual EC DRBG attack, and
thus it is similar to typical state cryptosystems keep in operation, which indicates that the
attack is very robust in actual systems.

Our proposed attack relies on the novel identification of non-black-box yet general enough
properties that yield practical ASAs on KEMs. Also, it is a fundamental property that turns out
to be conceptually easy to explain after we formulate the non-black-box assumption. However,
we remark that the exact formulations and analysis are challenging. In particular, we are
able to prove that the attack works only assuming that the underlying KEM satisfies some
special properties, and we formally define them, rigorously showing a wide range of KEMs
suffering from our ASA. This new finding explains why the attack was not considered before,
even though the rationale behind our attack (as briefly shown below) was implicitly informally
already hinted about if one considers the cases given in [35]. In fact, our attack could be regarded
as a general extension of Young and Yung’s kleptographic attacks in the ASA model against
the modern encryption procedures of PKE schemes. More broadly, our work may shed some
light on further exploring the non-black-box but quite general structural weaknesses of other
composed cryptographic primitives (which the KEM/ DEM paradigm is an example of), that
may make them susceptible to more efficient and effective ASAs that surpass the logarithmic
upper bound of universal ASAs [9].

Our contributions. To summarize, we make the following contributions.

1. We formalize an asymmetric ASA model for KEMs. Compared with previous works
that mainly studied symmetric ASAs [7, 6, 3, 17], in this work we consider a stronger
setting where revealing the hard-wired subversion key does not provide users with the
same cryptographic capabilities as the subverter.

2. We redefine the KEM syntax in a module level with two new properties—namely uni-
versal decryptability and key-pseudo-randomness—that are vital to our proposed ASA.
We then introduce a generic ASA and rigorously prove its session-key-recoverability and
undetectability in our ASA model.

3. We show that our attack works on a wide range of KEMs including the generic construc-
tion from hash proof system [27, 23]; and concrete KEMs derived from popular PKE
schemes such as the Cramer-Shoup scheme [15], the Kurosawa-Desmedt scheme [27], and
the Hofheinz-Kiltz scheme [23].

Below we further elaborate on the results presented in this work.

Asymmetric ASA model. We start with briefly introducing the adopted ASA model in our
work. Current ASA models [7, 6, 3, 17, 9] are in the symmetric setting where the subversion key
hard-wired in the (subverted) algorithm is the same with the one used for secret key recovery.
Such a symmetric setting would enable anyone who reverse-engineers the subversion key from
the subverted algorithm to have the same cryptographic ability as the subverter. In this work,
we turn to the asymmetric ASA setting advocated by kleptograhic attacks [36], and we carefully
formalize an asymmetric ASA model specifically for KEMs. In our model, the subverted KEM
contains the public subversion key while the corresponding secret subversion key is only known
to the subverter. The session key recovery requires the secret subversion key and thus the
attacking ability is exclusive to the subverter (and is not acquired by reverse engineering the
subverted device). Also, we further enhance the notion of undetectability in the sense that the
detector is allowed to know the public subversion key in the detection game. We note that in
[7], an asymmetric ASA model is also discussed in the context of symmetric encryption, whereas

5



r1 r2 r3 ¡ ¡ ¡ ri ri+1

(K1, C1 ) ( K2 , C2 ) ( K3 , C3 ) (Ki, Ci ) ( Ki+1 , Ci+1 )

KEM.Enc KEM.Enc KEM.Enc

KEM.Dec KEM.Dec KEM.Dec

Figure 1: The sketch map of our ASA on (simplfied) KEMs. The dashed line at the top
represents that in the subverted encapsulation algorithm, ri+1 is derived from ri (i starts with
“1”) via running the legitimate algorithm KEM.Enc. The dashed diagonal line indicates that
the attacker recovers ri+1 (and Ki+1) from Ci via running KEM.Dec.

all the proposed ASAs are symmetric. In fact, as we will show later, the asymmetric setting
essentially enables our proposed effective ASAs.

A sketch map of our ASA (simplified version). We now informally describe our identified
non-black-box structural weakness in existing KEM constructions and show how it enables our
efficient attack. We remark that here we only take the case of simplified KEM as an example to
illustrate our basic idea. For more details and formal analysis we refer the reader to Section 4.2
where we present our ASA on more general KEMs. We first roughly recall the syntax of
(simplified) KEM. Informally, a KEM is defined by a tuple of algorithms (KEM.Setup, KEM.Gen,
KEM.Enc, KEM.Dec). The key generation algorithm KEM.Gen generates the public/secret key
pair (pk, sk). The encapsulation algorithm KEM.Enc takes as input pk and output the session
key K with the key ciphertext C. The decapsulation algorithm KEM.Dec uses sk to decrypt
C for computing K. Our proposed ASA is essentially inspired by the observation that many
popular KEM constructions, in fact, produce “public-key-independent” ciphertexts which only
depend on the internal random coins generated by KEM.Enc while is independent of the public
key. Consequently, such kind of key ciphertexts are “decryptable” with any key pair honestly
generated by KEM.Gen (formalized as universal decryptability in our work). Relying on this
fact, we manage to mount a substitution attack on KEM.Enc via manipulating the internal
random coin. Specifically, the subverter runs the legitimate algorithm KEM.Gen—with the
public parameter—to generate the subversion key pair (psk, ssk) of which psk is hard-wired in
the subverted KEM.Enc (denoted by ASA.Enc in our ASA model), while ssk is exclusively held by
the subverter. Note that KEM.Enc would be run repeatedly in an ongoing encryption procedure
of PKE and let ri denote the random coin generated by KEM.Enc in its i-th invocation. Ideally, it
is expected that random coins from different invocations are generated independently. However,
in our designed ASA.Enc, as roughly depicted in Fig. 1, the random coin ri+1 is actually derived
via KEM.Enc taking psk and ri (maintained as an internal state) as inputs. Consequently, due
to the universal decryptability of KEM, the subverter is able to recompute ri+1 (and thereafter
recover the session key Ki+1) by running KEM.Dec to decrypt Ci using ssk. In this way, our
attack enables the subverter to recover the session key of a subverted ciphertext with the help
of the previous subverted ciphertext.

On the robustness of our stateful attacks. As pointed out by Bellare et al. [6], stateful
ASAs may become detectable upon the system reboot (e.g., resetting the state). However,
we argue below that the state in our attack is practically acceptable, and our attack could
still be very robust and meaningful in cryptographic implementation practices nowadays. The

6



state relation (i.e., only the previous randomness) in our proposed ASA is similar to that of
Dual EC DRBG, and is much more limited than the stateful ASA on symmetric encryption
[7], which needs to maintain a global counter that represents which bit(s) of the secret is
trying to exfiltrate in each run. More broadly, modern cryptosystems in the cloud services are
implemented typically in secure hardware modules that are rented to cloud customers. This
has become a popular configuration in recent years. It is inconceivable that such service cannot
be temporarily non-volatile and stateful. Even if it happens or all relevant tools are reinitiated
at system initiation, our attack persists since we do not really need a state depending on the
entire system history, but only the randomness generated in the previous session. Therefore,
we categorically see no practical weakness with our configuration, primarily in view of modern
secure hardware modules as cryptographic implementations, and the successful large scale attack
on Dual EC DRBG [11].

2 Preliminaries

Notations. For any randomized algorithm F , y := F(x; r) denotes the output of F on the
fixed randomness r and y←$F(x) denotes the random output of F . We writeAO1,O2,···(x, y, · · · )
to indicate that A is an algorithm with inputs x, y, ¡ ¡ ¡ and access to oracle O1,O2, ¡ ¡ ¡ . Let
z ← AO1,O2,···(x, y, · · · ) denote the outputs of running A with inputs (x, y, · · · ) and access to
oracles O1,O2, ¡ ¡ ¡ .

2.1 Entropy Smoothing Hash Functions

Let H = {Hk̂}k̂∈K̂ (K̂ is the key space) be a family of keyed hash functions, where every function
Hk̂ maps an element of group X to another element of group Y . Let D be a PPT algorithm that

takes as input an element of K̂, and an element from Y , and outputs a bit. The ES-advantage
of D is defined as

AdvesH,D(n) := |Pr
[
D(k̂, Hk̂(x)) = 1|k̂←$ K̂, x←$X

]
− Pr

[
D(k̂, y) = 1|k̂←$ K̂, y←$Y

]
|.

We say H is εes(n)-entropy smoothing if for any PPT algorithm D, AdvesH,D(n) ≤ εes(n). It
has been shown in [19] that the CBC-MAC, HMAC and Merkle-Damg̊ard constructions meet
the above definition on certain conditions.

2.2 Key Encapsulation Mechanism (KEM)

Syntax. A key encapsulation mechanism KEM consists of algorithms (KEM.Setup, KEM.Gen,
KEM.Enc, KEM.Dec) which are formally defined as below.

• KEM.Setup(1n). Takes as input the security parameter n ∈ N and outputs the public
parameter pp. We assume pp is taken by all other algorithms as input (except of KEM.Gen
where it is explicitly given).

• KEM.Gen(pp). Takes as input pp, and outputs the key pair (pk, sk).

• KEM.Enc(pk). Takes as input the public key pk, and outputs (K,ψ) where K is the session
key and ψ is the ciphertext.

• KEM.Dec(sk, ψ). Takes as input the secret key sk and the ciphertext ψ, and outputs the
session key K or ⊥.

7



Correctness. Let KEM = (KEM.Setup, KEM.Gen,KEM.Enc, KEM.Dec) be a KEM. We say
KEM satisfies correctness if for any n ∈ N, for any pp←$KEM.Setup(1n), for any (pk, sk)←$

KEM.Gen(pp), we have KEM.Dec(sk, ψ) = K where (K,ψ)←$KEM.Enc(pk).

Security. Let KEM = (KEM.Setup, KEM.Gen, KEM.Enc, KEM.Dec) be a KEM. We say KEM
is IND-CCA-secure if for any PPT adversary A,

Advccakem,A(n) :=

∣∣∣∣∣∣∣∣∣∣∣∣∣∣∣
Pr


b = b′ :

pp←$KEM.Setup(1n)

(pk, sk)←$KEM.Gen(pp)

(K0, ψ
∗)←$KEM.Enc(pk)

K1←$Kkem, b←$ {0, 1}

b′ ← AODec(·)(pk,Kb, ψ
∗)


− 1

2

∣∣∣∣∣∣∣∣∣∣∣∣∣∣∣
≤ negl(n) ,

where Kkem is the key space of KEM, and ODec is a decryption oracle that on input any
ciphertext ψ, returns K := KEM.Dec(sk, ψ) on the condition that ψ 6= ψ∗. As a weak security
definition, we say KEM is IND-CPA-secure if in the above definition, the adversary is restricted
not to query ODec.

3 Asymmetric ASA Model for KEMs

In this section, we extend the notion of ASA model by Bellare et al. [7] to the asymmetric
setting for KEMs. We remark that we mainly consider substitution attacks against the en-
capsulation algorithm while assuming that the key generation and decapsulation algorithm are
not subverted. It is worth noting that via subverting the decapsulation algorithm it is possi-
ble to exfiltrate decapsulation key. Particularly, in a recent work [1], Armour and Poettering
demonstrated the feasibility of exfiltrating secret keys by subverting the decryption algorithm
of AEAD.

3.1 Asymmetric ASA on KEMs

An ASA on KEM is that in the real-world implementation, the attacker replaces the legitimate
algorithm KEM.Enc by a subverted one denoted by ASA.Enc, which hard-wires some auxiliary
information chosen by the subverter. The goal of subverter is to break the security of the
subverted KEM. The algorithm ASA.Enc could be arbitrary. Particularly, the randomness space
in ASA.Enc could be different from that of KEM.Enc, and the subverted ciphertext space is not
necessarily equal to the valid ciphertext space of KEM.Enc1. Also, ASA.Enc may be stateful by
maintaining some internal state, even in the case that KEM.Enc is not.

Syntax. Let KEM = (KEM.Setup, KEM.Gen,KEM.Enc, KEM.Dec) be a KEM which generates
pp←$KEM.Setup(1n) and (pk, sk)←$KEM.Gen(pp). An asymmetric ASA on KEM is denoted
by ASA = (ASA.Gen,ASA.Enc,ASA.Rec).

• (psk, ssk)←$ASA.Gen(pp). The subversion key generation algorithm takes as input pp,
and outputs the subversion key pair (psk, ssk). This algorithm is run by the subverter.
The public subversion key psk is hard-wired in the subverted algorithm while the secret
subversion key ssk is hold by the attacker.

1For example, the subverted algorithm ASA.Enc may directly output the key as its ciphertext.

8



• (K,ψ)←$ASA.Enc(pk, psk, τ). The subverted encapsulation algorithm takes as input pk,
psk, and the (possible) internal state τ , outputs (K,ψ) and updates the state τ (if exists).
This algorithm is created by the subverter and run by the legitimate user. The state τ is
never revealed to the outside.

• K←$ASA.Rec(pk, ssk, ψ,Φψ). The key recovery algorithm takes as input pk, ssk, ψ and
an associated ciphertext set Φψ, and outputs K or ⊥. This algorithm is run by the
subverter to recover the session key K encapsulated in ψ.

Remark. The algorithm ASA.Rec is run by the subverter to “decrypt” the subverted cipher-
text ψ—output by ASA.Enc—using the secret subversion key ssk that is associated with psk
hard-wired in ASA.Enc. However, due to the information-theoretic reasons, it might be impos-
sible for the subverter to recover the key given the subverted ciphertext only. Therefore, we
generally assume that the subverter needs some associated ciphertexts (e.g., a tuple of previous
ciphertexts) to successfully run ASA.Rec. More details are provided in Section 4.2.

Below we define the notion of decryptability which says that the subverted ciphertext—
produced by ASA.Enc—is still decryptable to the legitimate receiver. In fact, decryptability
could be viewed as the basic form of undetectability notion defined in Section 3.3.

Definition 3.1 (Decryptability). Let ASA = (ASA.Gen,ASA.Enc,ASA.Rec) be an ASA on
KEM = (KEM.Setup, KEM.Gen,KEM.Enc, KEM.Dec). We say ASA preserves decryptability
for KEM if for any n ∈ N, any pp←$KEM.Setup(1n), and any (pk, sk) ←$KEM.Gen(pp), for
any (psk, ssk)←$ASA.Gen(pp), and all state τ ∈ {0, 1}∗,

Pr[Dec(sk, ψ) 6= K : (K,ψ)←$ASA.Enc(pk, psk, τ)] ≤ negl(n) ,

where the probability is taken over the randomness of algorithm ASA.Enc.

3.2 Session Key Recovery

Generally, the goal of the subverter is to gain some advantages in attacking the scheme. In
the ASA model for symmetric encryption and signature schemes, the notion of key recovery is
defined as a strong goal [6, 3]. However, for KEMs, the encapsulation algorithm has no access
to the secret (decapsulation) key and thus it is impossible to exfiltrate the long-term secret of
a subverted encapsulation algorithm. Alternatively, we define another notion which captures
the ability of the subverter—who has the secret subversion key ssk—to recover the session key
from t";"""date"",""2020-09-08T03:00:51Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2020-09-08T03:00:51Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016) kpathsea version 6.2.2""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2020-09-08T03:00:51Z""
""created"",""2020-09-08T03:00:51Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-09-08T03:00:51Z""
""resourceName"",""1079.pdf""
""Author"",""""
""producer"",""pdfTeX-1.40.17""
""pdf:docinfo:producer"",""pdfTeX-1.40.17""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""6"",""33"",""3"",""45"",""4"",""3"",""46"",""1"",""20"",""17"",""21"",""20"",""11"",""0"",""20"",""22"",""1"",""0"",""0"",""0"",""0"",""36"",""19"",""2"",""2"",""0"",""1"",""0"",""0"",""0"",""8""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2020-09-08T03:00:51Z""
""Last-Modified"",""2020-09-08T03:00:51Z""
""dcterms:modified"",""2020-09-08T03:00:51Z""
""title"",""""
""Last-Save-Date"",""2020-09-08T03:00:51Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2020-09-08T03:00:51Z""
""meta:save-date"",""2020-09-08T03:00:51Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016) kpathsea version 6.2.2""
""Content-Length"",""562059""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""38""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""2545"",""1354"",""3306"",""3501"",""3374"",""3159"",""2845"",""2301"",""2278"",""2506"",""2651"",""2211"",""2462"",""2328"",""2026"",""1374"",""1214"",""1288"",""1320"",""1781"",""2163"",""1537"",""2048"",""2458"",""3689"",""2879"",""3200"",""3092"",""1994"",""2407"",""2023"",""1899"",""2197"",""2205"",""3108"",""2961"",""2710"",""823""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-09-08T03:00:51Z""
";https://scholar.google.ch/scholar?start=670&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098738-46;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Address-based Signature;H Cui, TH Yuen ; 2020 IEEE 19th International Conference on …, 2020  ieeexplore.ieee.org;;"… In this paper, we propose a compact address- based signature scheme for cryptocurrency,

summarized in … is based on the discrete logarithm assumption in the random oracle model … In terms

of blockchain application, Schnorr signature is not compatible with Bitcoin Improvement …";Les 3 versions;;null;;;;https://scholar.google.ch/scholar?start=590&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098839-271;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Blockchain-Based Dynamic Group Key Agreement Protocol for Ad Hoc Network;Q Zhang, B Wang, X Zhang, J Yuan, R Wang ; Chinese Journal of Electronics, 2020  IET;;"Page 1. Chinese Journal of Electronics Vol.29, No.3, May 2020 Blockchain-Based Dynamic

Group Key … III. The Process of BD-GKA Protocol 1. Initialization In this section, we describe a

lightweight symmetric group key agreement protocol based on blockchain …";Cité 2 fois;Les 4 versions;[PDF] ejournal.org.cn;http://www.ejournal.org.cn/Jweb_cje/EN/article/downloadArticleFile.do?attachType=PDF&id=11921;;;https://scholar.google.ch/scholar?start=820&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098729-25;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Fully Collision-Resistant Chameleon-Hashes from Simpler and Post-quantum Assumptions;D Derler, S Krenn, K Samelin, D Slamanig ; International Conference on …, 2020  Springer;;"… ch}}\) to initialize the adversary. The adversary gains access to two oracles. The

oracle \(\mathsf {CHash}'\) allows the adversary to adaptively receive hashes on

messages of its choice. The generated hash/randomness pairs …";Autres articles;;[PDF] iacr.org;https://eprint.iacr.org/2020/1084.pdf;"
Fully Collision-Resistant Chameleon-Hashes from

Simpler and Post-Quantum Assumptions

David Derler1, Stephan Krenn2, Kai Samelin3, and Daniel Slamanig2

1 DFINITY, Zurich, Switzerland
david@dfinity.org

2 AIT Austrian Institute of Technology, Vienna, Austria
{stephan.krenn, daniel.slamanig}@ait.ac.at

3 Independent, Hamburg, Germany
kaispapers@gmail.com

Abstract. Chameleon-hashes are collision-resistant hash-functions par-
ametrized by a public key. If the corresponding secret key is known,
arbitrary collisions for the hash can be found. Recently, Derler et al.
(PKC '20) introduced the notion of fully collision-resistant chameleon-
hashes. Full collision-resistance requires the intractability of �nding col-
lisions, even with full-adaptive access to a collision-�nding oracle. Their
construction combines simulation-sound extractable (SSE) NIZKs with
perfectly correct IND-CPA secure public-key encryption (PKE) schemes.
We show that, instead of perfectly correct PKE, non-interactive commit-
ment schemes are su�cient. For the �rst time, this gives rise to e�cient
instantiations from plausible post-quantum assumptions and thus candi-
dates of chameleon-hashes with strong collision-resistance guarantees and
long-term security guarantees. On the more theoretical side, our results
relax the requirement to not being dependent on public-key encryption.

1 Introduction

Chameleon-hashes (CHs) are collision-resistant hash-functions parametrized by
a public key. Knowledge of the corresponding secret key allows �nding arbi-
trary collisions. Chameleon-hashes were initially introduced by Krawczyk and
Rabin [KR00]. Similar underlying ideas even date back to the introduction of
�trapdoor commitments� by Brassard et al. [BCC88]. They are an integral part
of many cryptographic constructions, both in theory and practice. For instance,
CHs �nd usage in on/o�ine signatures [CZSM07, EGM96, ST01], to generically
lift non-adaptively secure signature schemes to adaptively secure ones [HW09,
ST01], or as a building block for tightly-secure signatures [BKKP15]. Likewise,
they �nd applications in strong one-time signatures [Moh10], the construction of
IND-CCA secure public-key encryption [Zha07] or to extend Schnorr and RSA

This is the full version of a paper which appears in Security and Cryptography for
Networks - SCN 2020 - 12th Conference on Security and Cryptography for Networks,
Amalďż˝, Italy, September 14-16, 2020. The proceedings version is available online at:
https://doi.org/10.1007/978-3-030-57990-6_21

mailto:david@dfinity.org?subject=Question About Your Paper 'Fully Collision-Resistant Chameleon-Hashes from Simpler and Post-Quantum Assumptions'
mailto:stephan.krenn@ait.ac.at?subject=Question About Your Paper 'Fully Collision-Resistant Chameleon-Hashes from Simpler and Post-Quantum Assumptions'
mailto:daniel.slamanig@ait.ac.at?subject=Question About Your Paper 'Fully Collision-Resistant Chameleon-Hashes from Simpler and Post-Quantum Assumptions'
mailto:kaispapers@gmail.com?subject=Question About Your Paper 'Fully Collision-Resistant Chameleon-Hashes from Simpler and Post-Quantum Assumptions'
https://doi.org/10.1007/978-3-030-57990-6_21


signatures to the universal designated-veri�er setting [SBWP03]. CHs are also
widely used in sanitizable signatures [ACdMT05, BCD+17, BFF+09, CDK+17],
i.e., signatures where a designated entity can alter certain parts of a signed
message while also deriving a valid new signature for the altered message. Bel-
lare and Ristov have shown that chameleon-hashes and ÎŁ-protocols (mean-
ing three-round public-coin honest-veri�er zero-knowledge proofs of knowledge),
are equivalent [BR08, BR14]. Likewise, several extensions such as (hierarchi-
cal) identity-based [AdM04a, AdM04b, BDD+11], policy-based chameleon-hash
functions [DSSS19, SS20], or multi-trapdoor CHs [CDK+17, KPSS18] have been
studied.

Derler et al. [DSS20] recently studied existing collision-resistance notions of
CHs and introduced the notion of full collision-resistance, which is the strongest
known such notion and arguably the most natural one. Compared to prior no-
tions, their de�nition requires that an adversary which has full adaptive access to
a collision-�nding oracle cannot �nd any collisions that it did not receive from
the oracle. For comparison, the weakest meaningful notion (those satis�ed by
trapdoor commitments) does not allow the adversary to see any collision.

Contribution. Given the wide variety of application scenarios relying on CHs
as building blocks, striving to �nd e�cient instantiations and construction para-
digms, based on minimal assumptions, yet with strong security guarantees, is
an important task. Our contributions are along those lines, and, in particular,
include:

ďż˝ A black-box construction of fully collision-resistant chameleon-hashes based
on SSE NIZKs and non-interactive commitment schemes. Most importantly,
this construction manages to remove the requirement to rely on public-key
encryption. While this is interesting from a practical point of view as it gives
more freedom for possible instantiations, it is also interesting from a theoreti-
cal perspective, as we can instantiate our constructions from primitives which
require weaker assumptions. Besides that, our construction o�ers strong in-
distinguishability, a strong privacy notion recently introduced by Derler et
al. [DSSS19].

� An e�cient instantiation from post-quantum assumptions. In particular, we
present a concrete construction from the learning parity with noise (LPN)
problem. This yields the �rst chameleon-hash from post-quantum assump-
tions that provides a collision-resistance notion stronger than that provided
by trapdoor commitments (e.g., the lattice-based chameleon-hash by Cash
et al. [CHKP10]). We note that although the security of the used SSE NIZKs
obtained from the Fiat-Shamir transform are just argued in the random or-
acle model (ROM), there is a recent line of works [DFMS19, LZ19, DFM20]
that prove security of (SSE) NIZKs obtained via Fiat-Shamir in the quan-
tum accessible ROM (QROM) [BDF+11]. Latter gives evidence that security
in the ROM based on post-quantum assumptions is a meaningful security
guarantee in practice. We leave it as an interesting open question to study

2



the security of instantiations from other post-quantum assumptions in the
QROM.

� An e�cient instantiation from the discrete logarithm (DL) assumption, in
contrast to the DDH assumption used by Derler et al. [DSS20].

ďż˝ The new notion of randomness unforgeability of chameleon-hashes. Intu-
itively, it requires that the adversary cannot �nd new randomness for an
honestly generated hash. This notion is weaker than the uniqueness notion
by Camenisch et al. [CDK+17], but may �nd its usage in cases where neither
the holder of the secret key nor the hashing party is adversarial, protecting
against outsiders tempering with the generated values.

2 Preliminaries

Notation. With Ν ∈ N we denote our security parameter. All algorithms im-
plicitly take 1λ as an additional input. We write a←r A(x) if a is assigned to the
output of an algorithm A with input x (and use a← A(x) if A is deterministic).
An algorithm is e�cient, if it runs in probabilistic polynomial time (PPT) in the
length of its input. All algorithms are PPT, if not explicitly mentioned other-
wise. Most algorithms may return a special error symbol ⊥ /∈ {0, 1}∗, denoting
an exception. Returning output ends execution of an algorithm or an oracle. In
order to make the presentation in the security proofs more compact, we occa-
sionally use (a,⊥)←r A(x) to indicate that the second output is either ignored
or not returned by A. If S is a �nite set, we write a←r S to denote that a is cho-
sen uniformly at random from S.M denotes a message space of a scheme, and
we generally assume that M is derivable from the scheme's public parameters
or its public key. For a list we require that there is an injective, and e�ciently
reversible, encoding, that maps the list to {0, 1}∗. A function ν : N → R≥0
is negligible, if it vanishes faster than every inverse polynomial, i.e., ∀k ∈ N,
∃n0 ∈ N such that ν(n) ≤ n−k, ∀n > n0.

2.1 One-Way Functions

A one-way function f is a function, where computing the function is easy, but
reversing the function is hard.

De�nition 1 (One-Way Functions). A function f : {0, 1}∗ → {0, 1}∗ is one-
way, if (1) there exists a PPT algorithm A1 so that for all ∀ x ∈ {0, 1}∗ : A1(x)
= f(x), and (2) for every PPT adversary A2 there exists a negligible function ν
such that:

Pr[x←r {0, 1}λ, x′ ←r A2(f(x)) : f(x) = f(x′)] ≤ ν(λ).

2.2 Non-Interactive Commitment Schemes

Non-interactive commitment schemes allow one party to commit itself to a value
without revealing it [Blu81]. Later, the committing party can give some opening
information to the receiver to �open� the commitment.

3



De�nition 2 (Non-Interactive Commitments). A non-interactive commit-
ment scheme Γ is a tuple of PPT algorithms de�ned as follows:

ParGenΓ . This algorithm takes as input a security parameter λ and outputs the
public parameters ppΓ :

ppΓ ←r ParGenΓ (1
Îť)

CommitΓ . This algorithm takes as input a message m, and outputs a commit-
ment C together with corresponding opening information O:

(C,O)←r CommitΓ (ppΓ ,m)

OpenΓ . This deterministic algorithm takes as input a commitment C, a message
m, and some opening information O. It outputs a decision d ∈ {0, 1}:

d← OpenΓ (ppΓ , C,O,m)

De�nition 3 (Correctness). A non-interactive commitment scheme Γ is said
to be (perfectly) correct, if for all λ ∈ N, all ppΓ ←r ParGenΓ (1

Îť), for all mes-
sages m ∈M, for all (C,O)←r CommitΓ (ppΓ ,m), it holds that OpenΓ (ppΓ , C,
O,m) = 1.

De�nition 4 (Binding). A non-interactive commitment scheme is binding, if
for all PPT adversaries A there exists a negligible function ν such that:

Pr[ExpBinding
A,Γ (λ) = 1] ≤ ν(λ),

where the corresponding experiment is depicted in Figure 1b.

De�nition 5 (Hiding). A non-interactive commitment scheme Γ is hiding, if
for any PPT adversary A, there exists a negligible functions ν such that:∣∣∣Pr[ExpHiding

A,Γ (λ) = 1]− 1/2
∣∣∣ ≤ ν(λ),

where the corresponding experiment is depicted in Figure 1b.

2.3 Non-Interactive Proof Systems

Let L be an NP-language with associated witness relation R, i.e., such that
L = {x | ∃w : R(x,w) = 1}. A non-interactive proof system allows to prove
membership of some statement x in the language L. More formally, such a system
is de�ned as follows.

De�nition 6 (Non-Interactive Proof System). A non-interactive proof sys-
tem Π for language L consists of three algorithms {PGΠ,PrfΠ,VfyΠ}, such that:

PGΠ. The algorithm PGΠ outputs public parameters of the scheme, where Ν is
the security parameter:

crsΠ ←r PGΠ(1
Îť)

4



ExpBinding
A,Γ (λ)

ppΓ ←r ParGenΓ (1
Îť)

(C∗, O∗, O′∗,m∗,m′∗)←r A(ppΓ )
return 1, if OpenΓ (ppΓ , C

∗, O∗,m∗) = 1 ∧
OpenΓ (ppΓ , C

∗, O′∗,m′∗) = 1 ∧
m∗ 6= m′∗

return 0

(a) Binding

ExpHiding
A,Γ (λ)

ppΓ ←r ParGenΓ (1
Îť)

b←r {0, 1}
b∗ ←r ACommit′Γ (ppΓ ,·,·,b)(ppΓ )
where Commit′Γ on input ppΓ , m0, m1, and b:
return ⊥, if m0 /∈M∨m1 /∈M
(C,O)←r CommitΓ (ppΓ ,mb)
return C

return 1, if b∗ = b
return 0

(b) Hiding

Fig. 1: Security Games for Non-Interactive Commitments

PrfΠ. The algorithm PrfΠ outputs the proof π, on input of the CRS crsΠ, state-
ment x to be proven, and the corresponding witness w:

π ←r PrfΠ(crsΠ, x, w)

VfyΠ. The deterministic algorithm VfyΠ veri�es the proof π by outputting a bit
d ∈ {0, 1}, w.r.t. to some CRS crsΠ and some statement statement x:

d← VfyΠ(crsΠ, x, π)

De�nition 7 (Correctness). A non-interactive proof system is called correct,
if for all λ ∈ N, for all crsΠ ←r PGΠ(1

Ν), for all x ∈ L, for all w such that
R(x,w) = 1, for all π ←r PrfΠ(crsΠ, x, w), it holds that VfyΠ(crsΠ, x, π) = 1.

In the context of (zero-knowledge) proof-systems, correctness is sometimes also
referred to as completeness. In addition, we require two standard security no-
tions for zero-knowledge proofs of knowledge: zero-knowledge and simulation-
sound extractability (also known as simulation-extractability). We de�ne them
analogously to the de�nitions given in [DS19].

Informally speaking, zero-knowledge says that the receiver of the proof π
does not learn anything except the validity of the statement. It is required that
the distribution of crsΠ output by SIM1 is distributed identically to PGΠ.

De�nition 8 (Zero-Knowledge). A non-interactive proof system Π for lan-
guage L is zero-knowledge, if for any PPT adversary A, there exists an PPT
simulator SIM = (SIM1,SIM2) such that there exist negligible functions ν1 and
ν2 such that∣∣∣Pr [crsΠ ←r PGΠ(1

λ) : A(crsΠ) = 1]−

Pr
[
(crsΠ, τ)←r SIM1(1

Ν) : A(crsΠ) = 1
]∣∣∣ ≤ ν1(λ),

and that ∣∣∣Pr [ExpZero-Knowledge
A,Π,SIM (Ν) = 1

]
− 1/2

∣∣∣ ≤ ν2(λ),
where the corresponding experiment is depicted in Figure 2a.

5



ExpZero-Knowledge
A,Π,SIM (Ν)

(crsΠ, τ)←r SIM1(1
Îť)

b←r {0, 1}
b∗ ←r APb(·,·)(crsΠ)
where P0 on input x, w:
return π ←r PrfΠ(crsΠ, x, w), if R(x,w) = 1
return ⊥

and P1 on input x, w:
return π ←r SIM2(crsΠ, τ, x), if R(x,w) = 1
return ⊥

return 1, if b∗ = b
return 0

(a) Zero-Knowledge

ExpSimSoundExt
A,Π,E (Ν)

(crsΠ, τ, ζ)←r E1(1λ)
Q ← ∅
(x∗, π∗)←r ASIM(·)(crsΠ)
where SIM on input x:
obtain π ←r SIM2(crsΠ, τ, x)
Q ← Q∪ {(x, π)}
return π

w∗ ←r E2(crsΠ, ζ, x
∗, π∗)

return 1, if VfyΠ(crsΠ, x
∗, π∗) = 1 ∧

R(x∗, w∗) = 0 ∧ (x∗, π∗) /∈ Q
return 0

(b) Simulation-Sound Extractability

Fig. 2: Security Games for Non-Interactive Proof Systems

Simulation-sound extractability says that every adversary which is able to come
up with a proof π∗ for a statement must know the witness, even when seeing
proofs for statements potentially not in L [Sah99]. Clearly, this implies that
the proofs output by a simulation-sound extractable proof-systems are non-
malleable. Note that the de�nition of simulation-sound extractability of [Gro06]
is stronger than ours in the sense that the adversary also gets the trapdoor Îś
as input. However, in our context this weaker notion (previously also used e.g.
in [ADK+13, DHLW10]) su�ces.

De�nition 9 (Simulation-Sound Extractability). A zero-knowledge non-
interactive proof system Π for language L is said to be simulation-sound ex-
tractable, if for any PPT adversary A, there exists a PPT extractor E = (E1, E2),
such that∣∣∣Pr [(crsΠ, τ)←r SIM1(1

λ) : A(crsΠ, τ) = 1
]
−

Pr
[
(crsΠ, τ, ζ)←r E1(1λ) : A(crsΠ, τ) = 1

]∣∣∣ = 0,

and that there exist a negligible function ν so that

Pr
[
ExpSimSoundExt

A,Π,E (Ν) = 1
]
≤ ν(λ),

where the corresponding experiment is depicted in Figure 2b.

3 Syntax and Security of Chameleon-Hashes

We next present the formal framework for CHs used by Derler et al. [DSS20],
which itself is based on prior work [AMVA17, BFF+09, CDK+17].

De�nition 10. A chameleon-hash CH is a tuple of �ve PPT algorithms (CHPG,
CHKG,CHash,CHCheck,CHAdapt), such that:

6



CHPG. The algorithm CHPG, on input a security parameter Îť outputs public
parameters of the scheme:

ppch ←r CHPG(1λ)

We assume that ppch contains 1Îť and is implicit input to all other algorithms.
CHKG. The algorithm CHKG, on input the public parameters ppch outputs the

private and public keys of the scheme:

(skch, pkch)←r CHKG(ppch)

CHash. The algorithm CHash gets as input the public key pkch, and a message
m to hash. It outputs a hash h, and some randomness r:4

(h, r)←r CHash(pkch,m)

CHCheck. The deterministic algorithm CHCheck gets as input the public key
pkch, a message m, randomness r, and a hash h. It outputs a bit d ∈ {0, 1},
indicating whether the hash h is valid:

d← CHCheck(pkch,m, r, h)

CHAdapt. The algorithm CHAdapt on input of a secret key skch, the message m,
the randomness r, hash h, and a new message m′ outputs new randomness
r′:

r′ ←r CHAdapt(skch,m,m
′, r, h)

De�nition 11 (Correctness). A chameleon-hash is called correct, if for all
security parameters λ ∈ N, for all ppch ←r CHPG(1λ), for all (skch, pkch) ←r

CHKG(ppch), for all m ∈ M, for all (h, r) ←r CHash(pkch,m), for all m′ ∈ M,
we have for all r′ ←r CHAdapt(skch,m,m

′, r, h), that 1 = CHCheck(pkch,m,
r, h) = CHCheck(pkch,m

′, r′, h).

Full Collision-Resistance. Derler et al. [DSS20] recently de�ned the notion
of full collision-resistance. Here, the adversary gets access to a collision-�nding
oracle CHAdapt′, which outputs a collision for the adversarially chosen hash,
but also keeps track of each of the queried and returned hash/message pairs
(h,m) and (h,m′), using the list Q. The adversary wins, if it comes up with
a hash/message pair (h∗,m∗) colliding with (m′∗, r′∗), for the given public key,
where (m′∗, r′∗) was never queried to or output from the collision-�nding oracle.

De�nition 12 (Full Collision-Resistance). A chameleon-hash CH provides
full collision-resistance, if for any PPT adversary A there exists a negligible
function ν such that

Pr[ExpF-CollRes
A,CH (λ) = 1] ≤ ν(λ)

The corresponding experiment is depicted in Figure 3a.

4 We note that the randomness r is also sometimes called �check value� [AMVA17].

7



ExpF-CollRes
A,CH (Îť)

ppch ←r CHPG(1
Îť)

(skch, pkch)←r CHKG(ppch)
Q ← ∅
(m∗, r∗,m′∗, r′∗, h∗)←r ACHAdapt′(skch,·,·,·,·)(pkch)
oracle CHAdapt′ on input skch,m,m

′, r, h:
return ⊥, if CHCheck(pkch,m, r, h) 6= 1
r′ ←r CHAdapt(skch,m,m

′, r, h)
Return ⊥, if r′ = ⊥
Q ← Q∪ {(h,m), (h,m′)}
return r′

return 1, if CHCheck(pkch,m
∗, r∗, h∗) = 1 ∧

CHCheck(pkch,m
′∗, r′∗, h∗) = 1 ∧

m∗ 6= m′∗ ∧ (h∗,m∗) /∈ Q
return 0

(a) Full Collision-Resistance

ExpS-Ind
A,CH(Îť)

ppch ←r CHPG(1
Îť)

(skch, pkch)←r CHKG(ppch)
b←r {0, 1}
b∗ ←r AHashOrAdapt(skch,pkch,·,·,b)(skch, pkch)
where HashOrAdapt on input skch, pkch,m,m

′, b:
(h, r)←r CHash(pkch,m

′)
(h′, r′)←r CHash(pkch,m)
r′′ ←r CHAdapt(skch,m,m

′, r′, h′)
return ⊥, if r′′ = ⊥ ∨ r′ = ⊥ ∨ r = ⊥
if b = 0, return (h, r)
if b = 1, return (h′, r′′)

return 1, if b∗ = b
return 0

(b) Strong Indistinguishability

Fig. 3: Security Games for Chameleon-Hashes

Strong Indistinguishability. Strong indistinguishability is a strong privacy
notion [DSSS19]. It requires that a randomness r does not reveal whether it was
generated using CHash or CHAdapt, even if the adversary A knows all secret
keys.

De�nition 13 (Strong Indistinguishability). A chameleon-hash CH pro-
vides strong indistinguishability, if for any PPT adversary A there exists a neg-
ligible function ν such that∣∣∣Pr[ExpS-Ind

A,CH(λ) = 1]− 1/2
∣∣∣ ≤ ν(λ)

The corresponding experiment is depicted in Figure 3b.

Randomness Unforgeability. Uniqueness, introduced by Camenisch et al. at
PKC20 [CDK+17], requires that an adversary controlling all values (but the
public parameters) cannot �nd two distinct randomness values r∗ 6= r′∗ for the
same hash/message pair (h,m).5Uniqueness is a very strong notion that is hard
to achieve, and, in this strong form, only seems to be required in one particu-
lar use case [BCD+17, CDK+17, HZM+20, SS20]. To this end, we introduce a
slightly weaker variant that is easier to achieve while still being useful in other ap-
plications. It requires that an adversary cannot �nd new randomness for hashes
it did not create by itself. We call this notion randomness unforgeability.

In our formalization, the challenger generates the key pair and parameters
honestly, and uses pkch to initialize the adversary. The adversary gains access to
two oracles. The oracle CHash′ allows the adversary to adaptively receive hashes
on messages of its choice. The generated hash/randomness pairs (h, r) are stored
in a set Q. The oracle CHAdapt′ allows the adversary to adaptively �nd collisions
for hashes. If the adversary queries a hash/randomness pair which is an element
of Q, the resulting (h, r′) is also added to Q. The adversary wins, if it can come
up with a new randomness r∗ (i.e., not stored in Q) for whatever message m∗,
verifying for a hash h∗ which was output by CHash′.

5 The de�nition of uniqueness is restated in Appendix A.

8



ExpRand-Uf
A,CH (Îť)

ppch ←r CHPG(1
Îť)

(skch, pkch)←r CHKG(ppch)
Q ← ∅
(m∗, h∗, r∗)←r ACHash′(pkch,·),CHAdapt′(skch,·,·,·,·)(pkch)
oracle CHash′ on input pkch,m:

(h, r)←r CHash(pkch,m)
Q ← Q∪ {(h, r)}
return (h, r)

oracle CHAdapt′ on input skch,m,m
′, r, h:

r′ ←r CHAdapt(skch,m,m
′, r, h)

return ⊥, if CHCheck(pkch,m
′, r′, h) 6= 1

If ∃(h, ¡) ∈ Q:
Q ← Q∪ {(h, r′)}

return r′

return 1, if CHCheck(pkch,m
∗, r∗, h∗) = 1 ∧

(h∗, ·) ∈ Q ∧ (h∗, r∗) /∈ Q
return 0

Fig. 4: Randomness Unforgeability

De�nition 14 (Randomness Unforgeability). A chameleon-hash CH o�ers
randomness unforgeability, if for any PPT adversary A there exists a negligible
function ν such that

Pr[ExpRand-Uf
A,CH (λ) = 1] ≤ ν(λ)

The corresponding experiment is depicted in Figure 4.

4 Generic Construction

The main idea of our generic construction follows the original idea by Derler et
al. [DSS20], but slightly altered to meet our requirements. Namely, hashing a
message m means committing to it. The randomness r is a SSE NIZK proving
membership of a tuple containing the opening O for the commitment, and the
pre-image x of a one-way function f , ful�lling the following NP-relation:

L := {(ppΓ , h,m, y) | ∃ (O, x) : OpenΓ (ppΓ , h,O,m) = 1 ∨ y = f(x)} (1)

Informally, this language requires the prover to demonstrate that it either knows
an opening O such that h is a well-formed commitment of m under ppΓ , or the
pre-image x corresponding to f(x) of a one-way function f is known. Our con-
struction of a fully collision-resistant, strongly indistinguishable, and randomness
unforgeable, CH is presented as Construction 1.

4.1 Security

Subsequently, we prove the security of our CH in Construction 1.

Theorem 1. If Γ is correct, and Π is complete, then CH in Construction 1 is
correct.

9



CHPG(1λ) : Fix a commitment scheme Γ , a one-way function f , and a compatible
NIZK proof system for language L in (1). Return ppch = (f, ppΓ , crsΠ), where

ppΓ ←r ParGenΓ (1
λ), and crsΠ ←r PGΠ(1

Îť).

CHKG(ppch) : Return (skch, pkch) = (x, y), where

x←r {0, 1}λ, y ← f(x).

CHash(pkch,m) : Parse pkch as ((f, ppΓ , crsΠ), y) and return (h, r) = (C, π), where

(C,O)←r CommitΓ (ppΓ ,m), and π ←r PrfΠ(crsΠ, (ppΓ , h,m, y), (O,⊥)).

CHCheck(pkch,m, r, h) : Parse pkch as ((f, ppΓ , crsΠ), y) and r as π, and return 1, if the
following holds, and 0 otherwise:

m ∈M ∧ VfyΠ(crsΠ, (ppΓ , h,m, y), π) = 1.

CHAdapt(skch,m,m
′, r, h) : Parse skch as x, and set y ← f(x). Check that m′ ∈M and

CHCheck(y,m, r, h) = 1. Return ⊥, if not. Otherwise, return r′ = π′, where

π′ ←r PrfΠ(crsΠ, (ppΓ , h,m
′, y), (⊥, x)).

Construction 1: Our Construction of a Fully Collision-Resistant CH

Correctness follows from inspection and the (perfect) correctness of the used
primitives.

Theorem 2. If Γ is binding, f is a one-way function, and Π is simulation-
sound extractable, then CH in Construction 1 is fully collision-resistant.

The proof of this theorem is along the same lines as that in Derler et al. [DSS20].

Proof. We prove full collision-resistance using a sequence of games.

Game 0: The original full collision-resistance game.
Game 1: As Game 0, but we replace the CHPG algorithm with an algorithm

CHPG′ and modify the CHAdapt′ oracle as follows:

CHPG′(1λ) :

crsΠ ←r PGΠ(1
Îť
) (crsΠ, τ)←r SIM1(1

Îť) .

CHAdapt′(skch,m,m
′, r, h) : In CHAdapt:

π ←r PrfΠ(crsΠ, (ppΓ , h,m, y), (x,⊥)) π ←r SIM2(crsΠ, τ, (ppΓ , h,m, y)).

Transition - Game 0 → Game 1: We bound the probability for an adversary to
detect this game change by presenting a hybrid game, which, depending on
a zero-knowledge challenger Czk, either produces the distribution in Game
0 or Game 1, respectively. In particular, assume that we use the following
algorithm CHPG′′ instead of CHPG and CHPG′:

10



CHPG′′(1λ) :

(crsΠ, τ)←r SIM1(1
Îť
) crsΠ ←r Czk .

CHAdapt′(skch,m,m
′, r, h) : In CHAdapt:

π
′ ←r SIM2(crsΠ, τ, (ppΓ , h,m

′
, y)) π′ ←r Czk.Pb((ppΓ , h,m

′, y), (⊥, x)) .

Clearly, if the challenger's internal bit is 0 we simulate the distribution in
Game 0, whereas we simulate the distribution in Game 1 otherwise. We have
that |Pr[S0]− Pr[S1]| ≤ νzk(λ).

Game 2: As Game 1, but we replace the CHPG′ algorithm with an algorithm
CHPG′′′ which works as follows:

CHPG′′′(1λ) :

(crsΠ, τ)←r SIM1(1
Îť
) (crsΠ, τ, ζ)←r E1(1λ) .

Transition - Game 1 → Game 2: Under simulation-sound extractability, Game
1 and Game 2 are indistinguishable. That is, |Pr[S1]− Pr[S2]| = 0.

Game 3: As Game 2, but we keep a list Q of all tuples (h, r,m) previously
submitted to the collision-�nding oracle which are accepted by the CHCheck
algorithm, where h was never submitted to the collision-�nding oracle before.

Transition - Game 2 → Game 3: This change is purely conceptual, i.e., it does
not change the view of the adversary. |Pr[S2]− Pr[S3]| = 0 follows.

Game 4: As Game 3, but for every valid collision (m∗, r∗,m′∗, r′∗, h∗) output by
the adversary we observe that either (m∗, r∗) or (m′∗, r′∗) must be a �fresh�
collision, i.e., one that was never output by the collision-�nding oracle. We
assume, without loss of generality, that (m′∗, r′∗) is the �fresh� collision. We
run (x′, O′) ←r E2(crsΠ, ζ, (ppΓ , h

∗,m′∗, y), r′∗) and abort if the extraction
fails. We call this event E1.

Transition - Game 3 → Game 4: Game 3 and Game 4 proceed identically, un-
less E1 occurs. Assume, towards contradiction, that event E1 occurs with
non-negligible probability. We now construct an adversary B which breaks
the simulation-sound extractability property of the NIZK proof-system with
non-negligible probability. We engage with a simulation-sound extractability
challenger Csse and modify the algorithms as follows:

CHPG′′′′(1λ) :

(crsΠ, τ, ζ)←r E1(1λ) (crsΠ,⊥,⊥)←r Csse .

CHAdapt′′(skch,m,m
′, r, h) :

π
′ ←r SIM2(crsΠ, τ, (ppΓ , h,m

′
, y)) π′ ←r Csse.SIM(ppΓ , h,m

′, y) .

In the end we output ((ppΓ , h
∗,m′∗, y), r′∗) to the challenger. This shows

that we have |Pr[S3]− Pr[S4]| ≤ νsse(λ).
Game 5: As Game 4, but we observe that if (m∗, r∗) does not correspond

to a fresh collision for h∗ in the above sense, then we will have an entry

11



(h∗, r,m) ∈ Q where (m, r) is a �fresh� collision, i.e., one computed by the
adversary. We run the extractor for the fresh collision, i.e., either obtain
(x′′, O′′) ←r E2(crsΠ, ζ, (ppΓ , h

∗,m∗, y), r∗) or (x′′, O′′) ←r E2(crsΠ, ζ, (ppΓ ,
h∗,m, y), r), respectively. In case the extraction fails, we abort. We call the
abort event E2.

Transition - Game 4 → Game 5: Analogously to the transition between Game
3 and Game 4, we argue that Game 4 and Game 5 proceed identically unless
E2 occurs which is why we do not restate the reduction to simulation-sound
extractability here. We have that |Pr[S4]− Pr[S5]| ≤ νsse(λ).

Reduction to Binding and One-Wayness: We are now ready to construct
an adversary B which breaks either the binding property of the used one-
way function or the binding property of the underlying Γ . Our adversary B
proceeds as follows. It receives ppΓ from its binding challenger, as well as, f
and y from a one-way challenger. It embeds them straightforwardly as ppch

and pkch to initialize A. Now we know that we have extracted two witnesses
(x,O) as well as (x′′, O′′) where one attests membership of (pkΩ, h

∗,m′∗, y)
in L and one attests membership of (pkΩ, h

∗,m′′, y) for some m′′ 6= m′∗ in
L. In either case, B can check whether f(x) = y or f(x′′) = y holds. In
this case, it can return x, or x′′ resp., to its one-way challenger. In all other
cases, O and O′′ open the commitment h∗ to di�erent messages. Thus, B
can directly return (h∗, O,O′′,m∗,m′∗) as its own forgery. A union bound
gives us Pr[S5] ≤ νowf(λ) + νbinding(λ). This concludes the proof. ut

Remark 1. Note that, like Derler et al. [DSS20], we conduct a full collision-
resistance proof that only requires extracting twice. While the formal notion of
simulation-sound extractability would allow us to simply extract in every oracle
query, and, thus, obtain a more general result, this is to ensure that one can plug
in proof systems that rely on a rewinding extractor without putting a restriction
on the allowed adversarial queries. We note, however, that this way of proving the
theorem implies some limitations and if one can not a�ord these limitations one
would need to prove it via extracting in every oracle query, thus excluding some
of the proof systems we can plausibly plug in when only extracting twice. The
limitations are as follows: Observe that the extractor is formally only guaranteed
to work as long as either the proof we want to extract from, or the corresponding
statement does not correspond to an output of a query to the simulator. For the
proof above to go through, this means that the concrete proof system plugged
into our generic construction needs to have the property that for any given valid
proof for some statement the probability that the proof output by an honest
run of the simulator for the same statement will only collide with this proof
with negligible probability. This is a pretty common property for proof systems,
and all proof systems we can think of provide the required guarantees (e.g.,
Groth-Sahai proofs [GS08], or Fiat-Shamir transformed ÎŁ protocols).

Theorem 3. If Γ is hiding, and Π is zero-knowledge, then CH in Construction 1
is strongly indistinguishable.

12



In the proof, we use frameboxes and  to highlight the changes we make in
the algorithms throughout a sequence of games (and we only show the changes).

Proof. To prove strong indistinguishability, we use a sequence of games:

Game 0: The original strong indistinguishability game.
Game 1: As Game 0, but we modify the algorithms CHPG and the HashOrAdapt

oracle as follows:

CHPG′(1λ) :

crsΠ ←r PGΠ(1
Îť
) (crsΠ, τ)←r SIM1(1

Îť) .

HashOrAdapt′(pkch, skch,m,m′, b) : In CHash:

π ←r PrfΠ(...) π ←r SIM2(crsΠ, τ, (ppΓ , h,m, pkch))

and CHAdapt:

π
′ ←r PrfΠ(...) π′ ←r SIM2(crsΠ, τ, (pkΩ, h,m

′, f(skch))).

Transition - Game 0 → Game 1: We bound the probability for an adversary to
detect this game change by presenting a hybrid game, which, depending on
a zero-knowledge challenger Czk, either produces the distribution in Game
0 or Game 1, respectively. In particular, assume that we use the following
changes:

CHPG′′(1λ) :

(crsΠ, τ)←r SIM1(1
Îť
) crsΠ ←r Czk .

HashOrAdapt′′(pkch, skch,m,m′, b) : In CHash:

π ←r SIM2(...) π ←r Czk.Pb((ppΓ , h,m, pkch), (O,⊥)) .

and CHAdapt:

π
′ ←r SIM2(...) π′ ←r Czk.Pb((ppΓ , h,m

′, f(skch)), (⊥, x)) .

Clearly, if the challenger's internal bit is 0 we simulate the distribution in
Game 0, whereas we simulate the distribution in Game 1 otherwise. We have
that |Pr[S0]− Pr[S1]| ≤ νzk(λ).

Game 2: As Game 1, but we modify the HashOrAdapt oracle as follows:

HashOrAdapt′′′(·, ·, ·, b) : In CHash

(C,O)←r CommitΓ (ppΓ ,m) (C,O)←r CommitΓ (ppΓ , 0) .

Transition - Game 1 → Game 2: We bound the probability for an adversary to
distinguish between two consecutive games by introducing a hybrid game
which uses a hiding challenger to interpolate between two consecutive games.

13



CHPG′′′(λ) :

ppΓ ←r ParGenΓ (1
Îť
) ppΓ ←r Chiding .

HashOrAdapt′′′′(pkch, skch,m,m′, b) : In CHash:

(C,O)←r CommitΓ (ppΓ , 0) (C,⊥)←r Chiding.Commit′Γ (m, 0) .

Now, dep";"""date"",""2020-09-09T18:48:10Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2020-09-09T18:48:10Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is MiKTeX-pdfTeX 4.0.1 (1.40.21)""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2020-09-09T18:48:10Z""
""created"",""2020-09-09T18:48:10Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-09-09T18:48:10Z""
""resourceName"",""1084.pdf""
""Author"",""""
""producer"",""MiKTeX pdfTeX-1.40.21""
""pdf:docinfo:producer"",""MiKTeX pdfTeX-1.40.21""
""pdf:unmappedUnicodeCharsPerPage"",""2183"",""2636"",""1949"",""1281"",""1206"",""1198"",""1359"",""1783"",""1057"",""1050"",""1404"",""2412"",""945"",""1725"",""1500"",""1266"",""1203"",""2545"",""2818"",""2849"",""2809"",""2790"",""1427"",""1189"",""2006"",""987"",""948"",""739"",""1415""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2020-09-09T18:48:10Z""
""Last-Modified"",""2020-09-09T18:48:10Z""
""dcterms:modified"",""2020-09-09T18:48:10Z""
""title"",""""
""Last-Save-Date"",""2020-09-09T18:48:10Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2020-09-09T18:48:10Z""
""meta:save-date"",""2020-09-09T18:48:10Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is MiKTeX-pdfTeX 4.0.1 (1.40.21)""
""Content-Length"",""592612""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""29""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""2194"",""2651"",""2119"",""1557"",""1705"",""1651"",""1761"",""2371"",""1450"",""1583"",""1904"",""2644"",""1410"",""1957"",""2214"",""2335"",""2521"",""2603"",""2821"",""2850"",""2810"",""2790"",""1702"",""1449"",""2433"",""1376"",""1352"",""1384"",""1867""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-09-09T18:48:10Z""
";https://scholar.google.ch/scholar?start=570&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098743-58;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Smart Contracts and Automation of Private Relationships;P Sirena, FP Patti ; Bocconi Legal Studies Research Paper, 2020  papers.ssrn.com;;"… which have the ability to send data to the outside world; 'consensus-based oracles', which get …

39 See Janssen (n 23) 23 (declaring that every oracle added to a smart contract … it is theoretically

possible to provide for technical modifications of the smart contract in the blockchain …";Cité 1 fois;;null;;;;https://scholar.google.ch/scholar?start=600&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098778-132;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Extensible Visual Business Intelligence for Analyzing XBRL Big Data on Blockchain;A Bagherian Kasgari, H Mousavi… ; … 2020 TECTONIC SHIFT …, 2020  divaportal.org;;"… Factors EVBI Oracle BI Extensible BI cubes unlimited NA Technical Staff Need No … Eric E.

Cohen(2018), XBRL + Blockchain + AI/Machine Learning = Continuous Audit Tool … Horia Mircea

BOTOS (2017)., ""Bitcoin Intelligence - Business Intelligence meets Crypto Currency,"" CES …";Autres articles;;[PDF] diva-portal.org;https://www.diva-portal.org/smash/get/diva2:1466695/FULLTEXT01.pdf;"
Extensible Visual Business Intelligence for Analyzing 

XBRL Big Data on Blockchain 

Abbas Bagherian Kasgari1, Hamed Mousavi2 and Dr. Saeid Homayoun 2 

1 Allameh Tabataba'i University, Tehran, Iran, a.bagherian@atu.ac.ir 
2 Shahid Beheshti University, Tehran, Iran 

3 University of Gävle, Gävle,Sweden, saeid.homayoun@hig.se 

 

Abstract. The state-of-the-art patented EVBI (Extensible Visual Business Intel-

ligence) provides a new visual programming language for modeling Business In-

telligence applications over all databases at the intra- and inter-organizational 

levels. This paper describes the EVBI (Extensible Visual Business Intelligence) 

based on a case study research method in for illustrating how the solution aid for 

analyzing XBRL big data securely on Blockchain. The EVBI makes it easy for 

senior executives to design and develop supervisory reports using an extensible 

visual modeler desktop, without help of technical staff such as programmers. The 

results would be easy to use, as well.  A one-click reporting component can be 

served to non- technical users, which at the organizational level, senior execu-

tives of the country can access all supervised entities and organizations, even 

without interacting with supervised entities, at any time. Ability to model pro-

cesses and processing algorithms as visual multilayer models, enable the imple-

mentation of SQL Procedures visually and without the need for technical staff, 

which in addition to the ability to store knowledge, the ability to develop knowl-

edgeable teams stored in models is realized by the state-of-the-art idea. The out-

put can be displayed in any environment, including, but not limited to web 

pc/smartphone applications. 

Keywords: Business Intelligence, XBRL Analytics, Blockchain. 

1 Introduction 

The use of conventional BI in financial reporting necessitates auditors to modify 

their evidence-gathering procedures for implementing continuous auditing.  There is a 

need for more flexible BI which can server effectively for various auditing procedures.  

 

BI solutions should decrease work time searching for missing or erroneous data. The 

benefits of BI involved more accurate financial reporting with fewer errors due to a 

reduction in human involvement, resulting in more reliable and relevant information 

But since BI has been expected to support dynamic auditing procedures, the BI sys-

tem eventually becomes very complex.  

 



2 

BI systems tend to be complex for two major reasons. One reason for complexity is 

that BI systems have many independent components that require integration. (Deanne 

Larsona 2016) 

From the technical point of view a traditional Business Intelligence solution BI in-

cludes etl-tools including Data warehousing (architecture, modeling, storage, managing 

and data processing), ETL process (extracting, transforming, loading and data integra-

tion), implementation of reports(data visualization and dashboards), Online Analytical 

Processing OLAP and multidimensional data analysis, data mining, statistical analysis 

and forecasting modules. (Mihaela Filofteia Tutunea 2012). The complexity of BI 

would inevitably affect the business application.  

The second reason is BI systems are impacted by continuous changes.(Deanne 

Larsona 2016) The traditional business intelligence(BI) methodologies include identi-

fying of requirements, designing, defining and working with data, development of cre-

ation codes and databases, testing and validating of developments, deployment to pro-

duction, then supporting phases.(Deanne Larsona 2016) Aligning on one hand what a 

BI solution can offer and, on the other, the changing needs and expectations of users, 

the way they like to work – their work style, can thus be difficult.(J Jaklič 2018) Fur-

thermore, the current BI systems do not adequately detect and characterize user inter-

ests.(Krista Drushku 2019)  

This problem is felt more in fast growing and evolving auditing applications like 

accounting fraud detection. Because fraud makers are constantly changing their ap-

proaches and due to the rapid change of fraud scenarios, the auditing requirements 

cannot be fully recognized in advance. 

Since it is hard to both foresee all the business intelligence users’ requirements and 

be ensure of the covering of all new demands in advanced, the traditional business 

intelligence methodologies suffer from constant dependencies to support of expensive 

technical staff. Thus, the evolution of the traditional BI system is not possible without 

technical staff assistance or outsourcing team support. 

In course of time, the increasing complexity of the BI systems leads to the develop-

ment of diverse system islands in an organization, which does not meet organization's 

needs separately. 

The development of various systems, in addition to wasting the available financial 

resources of organization, can lead to unnecessary complexity and lack of coordination 

among software. 

For this reason, it is always observed that conventional BI users like traditional au-

ditors cannot work paper free. 

This has led to a lot of problems that some of the most important of these problems 

are listed below: 

 Difficulty in responding BI requirements spontaneously and without tremen-

dous support of technical team 

 The impossibility of designing the information processing processes required 

for BI reports without making changes to existing systems  

 Lack of desired agility in the implementation of new BI needs 

 Lack of unlimited development possibility in existing BI systems 



3 

 Lack of sufficient scalability or flexibility of technical architec-

ture(Vallurupalli Vamsi 2018) 

To deal with above problem, there is a need for an extensible BI platform to pass 

traditional limitation in answering business requirements. This necessity would be felt 

more when there are heterogeneous business systems in the organization. 

Moreover, millions of XBRL files are produced and its technology is vastly distrib-

uted. (Below figure) There is a need for boasting validation, verification and accelera-

tion of time of auditing process for the mentioned XBRL big data.  

 
Development of XBRL Filings by countries between 2010 and 2020(expected)(Dirk, 

2018) Source: XBRL.org, World Federation of Exchanges and own estimate 

 

BI is meant to take in all the data being generated by a business and present easy to 

digest performance measures and trends that will inform management decisions. ( Horia 

Mircea BOTOS, 2017) 

Without extensible BI systems, auditors not only will encounter to wasting tremen-

dous amount of time and energy, but also dependency in responding the confidential 

changing business systems will increase the risk of financial frauds. 

To address mentioned problems with BI platforms, the current study intended to 

introduce a state-of-the-art business intelligence framework named Extensible Visual 

Business Intelligence (EVBI) provides a blockchain based solution for modeling au-

diting BI procedure on XBRL filings eliminating traditional dependency to companies’ 

systems. 

The solution gets advantages of focusing on combining XBRL, business intelli-

gence, visual modeling of big data analytics with blockchain technology. 

 

 



4 

2 Background 

Many companies such as SAP, Microsoft, Oracle and informatica, have developed 

traditional business intelligence systems. Each of these systems have their weaknesses 

and strengths. However, all of these systems have the same limitation as their weakness 

in supporting of various BI needs. For example, the system lacks the ability to provide 

business team full independence from the technical team. 

 

2.1  Why this research is important? 

High-quality financial information is the lifeblood of financial markets, and that 

quality can be adversely affected by the existence and persistence of corporate miscon-

ducts both financial and non-financial. Prior research has primarily focused on financial 

misconducts and financial reporting fraud (FRF) and their effects on quality of corpo-

rate disclosures.  For example, Dichev et al. (2013, 2015) find that over 20 percent of 

firms intentionally misrepresent their earnings. The existing financial and auditing sys-

tems do not provide adequate incentives and accountability for management and audi-

tors to protect investors from receiving misleading financial information (Rice et al., 

2015). Business organizations lose about 5% of their revenues to fraud each year, which 

can exceed 3.5 trillion (USD) worldwide (The Association of Certified Fraud Examin-

ers (ACFE, 2015).  FRF incidents will continue to increase in the next several years 

(AICPA, 2014) and a minimal portion (less than 5%) of FRF is discovered by external 

auditors (Rezaee and Riley, 2009). **12 

In addition, there is a need for designing data processing and processing algorithms, 

that traditional intelligence system lacks such capabilities. The business intelligence 

systems have to provide both unlimited development capabilities and independence 

from technical staff for BI users in their platform. 

There are many BI solutions, each has its pros and cons. For example, the BI solu-

tion of Informatica provides simple visual tools for designing query by non-technical 

user. These reports can include facilities such as data filtering, line and output columns 

selection, selection of output data sources, and combining them with other relevant 

data, grouping and using functions such as aggregation, counting and sorting, as well 

as data representation. The Business Object SAP Company has offered similar tools. 

However, both tools lack possibility of visually modeling the business processes or 

SQL Procedure, without the need for technical expertise. An SQL Procedure may in-

clude some queries used for data processing, as well as some code for saving the results 

of each processing step in temporary tables. The result would be save in physical tables 

and would be used in other queries and SQL Procedures for subsequent processing. 

The SQL Procedures may go further and includes complex business logic. However, 

the result would appear in reports with different visualizations. 

Other feature of SQL Procedure are operators like SQL Loop such as For and While, 

conditions such as If, and Case Switch. 

A larger financial services firm will have a substantial set of software applications 

to support its business processes. If you are lucky, these applications use the same 



5 

databases and run on the same operating system but typically it will be a mix of MSQL, 

Oracle, and NoSQL databases plus Linux and Windows. Firms have to think carefully 

whether they favor buying BI solution from third parties or whether they develop in-

house. If they do buy third-party products, they have to choose where on the adoption 

curve they want to be. This boils down to a choice between knowing with a high degree 

of probability you are making a suboptimal choice and taking a bet on something that 

can drastically change your capabilities. Build versus buy considerations can have its 

pros and cons.  

When a firm buys BI solution, never would be an exact match to its business needs. 

Suppliers can act unpredictably; they can be acquired, loose focus, or unexpectedly 

raise prices. It may depend on supplier willingness to make enhancements to the soft-

ware, or pay much more than you would have done if you controlled the code. The 

firm have to be careful to prevent lock-in to specific entities, such as software vendors 

or their consultants. 

When a firm decide to build in-house BI solution with its own staff, it may be rein-

venting the wheel and start on a learning curve a vendor’s clients have already climbed 

Proprietary knowledge—hard to reengineer if people leave the company.(Groot 2017) 

In large organizations, there is always a stream of technical staff turnover. BI staff 

carry important knowledge of the organization.  

Therefore, providing a BI platform to store and transfer this knowledge to the next 

forces is very important. 

Such BI platform should provide understandable and self-interpretable framework 

for transferring the firms’ BI knowledge treasure from the existing BI staff is to the 

new experts; it protects the organization's business knowledge assets and reduces risk 

from loss of its business operation. 

On the other hand, while a firm lose its BI staff, the critical BI knowledge acquired 

by leaving staff, would be transferred to its biggest competitor or its own clients. 

Therefore, the desired BI platform should control privileged access to business 

knowledge, and perhaps encapsulate its critical business secrets.  

The BI solution should provide capability of separation of business content from its 

presentation in different access layers. 

The outputs of the analysis of BI systems are reports with relevant information value 

for managers, which also serve as inputs into decision-making and management pro-

cesses of the organizations.(Milan Kubinaa 2015) 

Key attention areas for BI departments are to get tools to preserve flexibility and 

not lock the data to the process.(Groot 2017) 

Both BI reports and its related business processes should have powered up by men-

tioned capabilities.  

Traditional BI systems offer tools for structuring and storing data in a data ware-

house, in which data are modeled with a multidimensional model representing the anal-

ysis axis.  



6 

These systems can be extended with semantic technologies to capture the meaning 

of data and new ways of interacting with data, intuitive and dynamic. Having the mean-

ing of data and a reasoning mechanism may assist a user during his analysis 

task.(Marie-Aude Aufaure 2016) 

However, there is also a need to model the process of generating information from 

data. The BI data, interaction, business processes and decision-making mechanism 

need to be harmonized by an BI modeling framework regarding above considerations.   

In regulatory organization, experts spend huge amount of time over motioning many 

market transactions for finding suspected cases to frauds. The traditional BI solution 

involves regulatory roles to scrutinize every transaction detail. (Bagherian Kasgari 

2016)  

Proactive surveillance is essential for financial regulators who are concerned with 

taking appropriate actions prior to performing new scenarios of frauds in financial mar-

ket. These frauds are conducted by fraud makers who creatively innovate new fraud 

scenarios. If the BI systems were successful in tackling fraud makers, the door will be 

open for regulators to proactively prevent fraud makers from fulfilling their fraud mis-

sion.(Bagherian Kasgari 2016) 

Detecting new financial frauds involves new BI requirements, which means new 

development efforts.  Whereas the stream of devising financial frauds is continuous, 

the process of updating financial surveillance BI systems will be continuous as well. 

Therefore, there is a need for extensible BI systems for financial supervision. 

The current research intended to facilitate auditing of financial filings, through a BI 

solution for rapid reporting of all financial frauds at different levels of inter/intra or-

ganizational levels. 

Thus, we contribute to the literature by extending and complementing prior research 

on providing new technology based solution for modernizing auditing applications.  

 
2.2 Analyzing XBRL Big Data on Blockchain 

Blockchain 2.0 led to the creation of Blockchain platforms where software code, 

called Smart Contracts, can be stored and executed on a Blockchain publicly. These 

contracts allow unstoppable, unmodifiable and publicly verifiable code execution as 

transactions between online entities. Blockchain 3.0 is expected to further immerse the 

technology into our daily lives with IoT integration.(Matthew Dixon and at al,2018) 

The expectation by the market are very high given the vast investments in blockchain 

infrastructure projects(Dirk Beerbaum, 2019). Recently Blockchain has been applied in 

aiding auditing applications extending literature about XBRL and blockchain as the fol-

lowing: 

• Continuous auditing and verification with XBRL blockchain (Dai, 2017, 

Chan et al., 2018, Deloitte, 2018, Dai and Vasarhelyi, 2017) 11 

• Real-time accounting and reporting with XBRL combined blockchain (By-

strĂśm, 2016, Trigo et al., 2014) 

• Acceleration of time with the XBRL blockchain (Colgren, 2018, Monterio, 

2016) 



7 

• This article and demo explains how to build a distributed ledger platform 

prototype from the ground up, specifically designed to manage financial re-

ports, in the line of other proposals in the financial area.(Boixo et al., 2019) 

• Design and implementation of a prototype to validate and store financial 

statements using Ethereum blockchain (d’Atri et al., 2019) 

The following advantages are seen in the application of blockchain to XBRL filings for 

accountants and auditors:  

• Validation of postings  

• Verification of financial nad non-financial information  

• Acceleration of time 

Since all entries are distributed and cryptographically sealed, falsifying or destroying 

them to conceal activity is practically impossible. Speed is a next domain, in which 

blockchain and XBRL have its real advantages. Accounting processes can vastly auto-

mated while control andaudit costs will decrease due to the built-in validation. XBRL 

ombined within a blockchain has the potential to enable real-time reporting and real-

time accounting, as stakeholders can directly access to blockchain acounting infor-

mation.( Dirk Beerbaum, 2018) 

Blockchain records track information about financial payments, movements of products 

and Analytics on this data can provide provenance histories, predictive planning, fraud 

identification, and regulatory compliance.  (D. N. Dillenberger et al,2019) 

 

 

 
Opportunities brought by artificial intelligence to address challenges of blockchain 

(Zibin Zheng, at al,2020) 

Big data analytics of blockchain data is beneficial to fraud recognition of transactions 

and vulnerability detection of smart contracts. However, it is also challenging to con-

duct big data analytics of blockchain data. It is extremely time consuming to download 

the entire blockchain data due to the bulky blockchain size and it requires substantial 

efforts in extracting and processing binary and encrypted blockchain data so as to obtain 

valuable information while this process is non-trivial as conventional data analytic 

methods may not work for this type of data. Also, there is no general data extract tool 

for blockchain data. Although several open source tools for blockchain data extraction 

are available, most of them can only support to extract partial blockchain data (not the 

entire data). (Zibin Zheng, at al,2020) 

 



8 

 
Data processing during Ethereum transaction flow(Zibin Zheng, at al,2020) 

Blockchain is seen as revolutionary or incremental change technology. In the last 

twenty years a technological revolution also occurred fueled by the widespread diffu-

sion of the internet. With regard to Financial Reporting, this trend also generated the 

development of Extensible Business Reporting Language (XBRL), which many ac-

counting experts expect to revolutionize financial reporting since it allows corporate 

financial information to be aggregated, transmitted and analyzed quicker and more ac-

curately. Blockchain and XBRL combined may represent a “centauromachy ( Dirk 

Beerbaum, 2019) 

The ongoing digitization of the economy presents challenges and opportunities for 

the auditing profession and requires both auditors and their clients to adapt, motivating 

the current technological developments in big data analytics, artificial intelligence (AI), 

and blockchain technology, offering numerous opportunities to financial world. ( Victor 

Tiberius, 2019) 

Some researchers suggested using blockchain as storage for XBRL filings, providing 

a standard data framework for machine learning/AI process, motivating future chal-

lenges in auditing research. (Eric E. Cohen, 2018) 

 
Blockchain Auditing challenges (Eric E. Cohen, 2018) 



9 

In this paper, we suggested EVBI as a visual intelligent auditing solution for model-

ing auditing procedure shared on blockchain as storage for processing XBRL filings.  

The EVBI will allow auditing firms to review transactions of public firms using a col-

lection of auditing process of data stored on a distributed ledger, as well as streamline 

and automate the fraud detection process. 

It is expected that the new platform will reduce audit procedure times from several 

weeks currently to “a fraction of second”. The blockchain maintain an audit trail that 

never goes away. Blockchain is not a data standard. And XBRL is not a distributed 

ledger system. 

But both are used to communicate, which in, one is playing role as the standard, and 

the other uses the standard. Indeed, the blockchain uses XBRL as a data standard to 

record information, a digitized financial data storage that resides on the blockchain. 

Smart contracts between two auditing agent may specify that if the certain auditing ratio 

alert of one auditee company falls below a certain level, an auditing action is triggered 

by the digital contract. In this application, the concept of the smart contract was fully 

developed, and it became clear that reliable, consistent, machine-readable data is nec-

essary for auditing smart contracts to be fulfilled.  

Smart contracts that rely on XBRL data prepared using a financial data standard can 

automatically trigger an action without the need for auditor intervention.The EVBIpro-

vide visual modeling desktop for auditing analytics connected to blockchains to provide 

easy-to-use configurable dashboards, predictive models, provenance histories, and 

compliance checking. As it is illustrated in the below conceptual model, auditing pro-

cedure are separated from XBRL filing big data and both are stored in the blockchain. 

User in upper level see the visual dashboard including AI models,  

 

We also describe how blockchain data can be combined with external data sources 

for secure and private analytics, enable artificial intelligence (AI) model creation over 

geographically dispersed data, and create a history of model creation enabling prove-

nance and lineage tracking for trusted Fraud Detection AI/ML, XBRL Analytics 

Visual Models and Continous Auditing Procedures. 

 

 
Conceptual model for Extensible Visual Business Intelligence(EVBI), sharing 

XBRL big data analytics.  

 

 

EVBI Blockchain

XBRL Big Data 

Fillings

Fraud Detection 
AI/ML Algorithms

XBRL Analytics

Visual Models

Auditing 
Procedures 

Continous Auditing 
Procedures



10 

 
Therefore, our major contribution in this study is addressing all mentioned problem 

with blockchain-based with state-of-the-art idea of EVBI, which is illustrated in the next 

section. 

3 Extensible Visual BI  

In this section we described the features of EVBI, illustrated building a Visual BI com-

ponent and finally evaluated the benchmarking EVBI with traditional BI solution. 

3.1 BI Visual Modeler(BO)  

The following section introduce an application interface called Visual Modeler, 

which is the design desktop for the innovative idea EVBI launched as Visual Modeler™ 

(BO). In the Component Category bars, user can create libraries of BI business pro-

cesses, printable reports, algorithms, and multilayer BI models. The top toolbar also 

includes Run, Save, Open, convert Visual Model to Business Process buttons, and a 

new button (to create a new BI object). There are some features for controlling the BI 

user privilege and sharing. By simple Drag and Drop the designed report move to the 

visual design desktop BO and will connect to query. 

 
Figure 11 Visual Modeler™ (BO), displays a sample query object created by drag and drop to 
connect the designed BI report to query 

The user can execute the report, saved as a visual BI procedure stored or a BI com-

ponent and customize the output via a simple or advanced filtering parameter.  

 
Figure 2 Setting BI Business Process Parameters 



11 

The input can have diverse formats static or dynamic formats including, but not limited 

to BI Reports, User-Defined, Multilayer Visual Models, Automatic feed via Algorithm, 

etc.  

 
Figure 3 Diverse static or dynamic input and output in EVBI 

The created BI process can be saved as BI component. Then, by dragging a saved BI 

component onto the screen, the component icon positioned on the drawing pad, can be 

used to create new BI processing models or execution for seeing the results. The output 

can have different format, including but not limited to Visual Modeler™ objects, Live 

Report™, Interactive Output, Printable reports, BI Movie™, Excel, Word, PDF, etc. 

and can be served as input for other BI algorithm.  

 

 
Figure 4 A sample BI report illustrating alerting trends 

After designing reports in Visual Modeler (VM), BI reports can be run in-house, as 

an application, or published on iBO(web-based interface for BI analytics) as needed. 

The Web Reporting Environment is called the Intelligent Business Object (iBO). The 

technical model carried out a few application prototypes to show how to transform busi-

ness data into BI documents, how to employ query instruments to analyze BI reports, 

and how to align to the globally adopted business reporting standard. 

All users around the globe can access to BI analytics based on their privileges. 

If the BI administrator decide, BI process, designed BI algorithms and reports, can 

be published over the web. For this purpose, while publishing each BI processes and 

reports, components within each process, is also transferred through BI web service and 

will be kept on the web server in the relevant database. 

Complex BI process can be drawn simply by selecting and connecting related BI 

component which the result can be save as new BI process or algorithm.  



12 

3.2 Smartphone BI Applications 

The development of mobile technologies and applications for mobile devices has 

opened new horizons for BI solution providers, in terms of developing applications for 

mobile BI, developing Mobile BI modules. The functionalities of mobile BI solutions 

will continue to improve steadily, BI solution providers giving them a better adapta-

bility to the type of terminals and mobile software platforms, and better security and 

performance. We should specify that all commercial BI solutions providers already 

included in their offer customizable Mobile BI modules depending on the type of client 

and its infrastructure. (Mihaela Filofteia Tutunea 2012) 

3.3 Building a Visual BI component 

By double-clicking on each BI component, Non-technical users can change BI pro-

cess using visual interface. (Fig. 8)  

 

  
Figure 5 Designing A sample BI process using EVBI visual desktop 

The BI data warehouse connect diverse databases including financial reports. Fig. 

13 displays sample Eps analysis report component. Motivated by the benefits of XBRL 

(Extensible Business Reporting Language) and growing interest in modern financial 

reporting technologies among listed companies led most companies to disclose their 

financial report in XBRL format.(Bagherian Kasgari 2009) So, EVBI can receive and 

process XBRL files to build its database of financial reports.   

For analysis of financial report, BI users can design different analysis component 

and connect the designed component to create a comprehensive financial analysis pro-

cess. BI analytics can be used for different applications, including auditing.  

Auditors who are dependent on company managers for receiving information can-

not be sure that the company does not fabricate the financial data, this contradict audi-

tor independency principals (SOX act). Another application which EVBI can serve 

effectively is continuous auditing. (Bagherian Kasgari 2014) 

 



13 

3.4 EVBI Benchmark 

Numerous innovative capabilities of EVBI has initiated by it genuine Architecture. 

Traditional BI data warehouse in EVBI is boasted. Extensive BI cube and reusable BI 

process enable users to add their data structure to BI data warehouse and build their 

business process in multilayer EVBI architecture.  

Then Visual modeler enable users to visually create and change the BI business 

process and then compose them to build a complex business process. This can finally 

trace a scenario of financial frauds. Traditional surveillance system such as NASDAQ 

Smart surveillance system lacks such features. User can access the result in EVBI sur-

veillance system via Live Report™. 

 Live Report™ is an innovative interactive object, which bound to EVBI and carry 

data and upper layer process to be displayed in different environment. This object can 

be used for analytical or regulatory purposes. For example, financial fraud cases can 

be displayed via this object in court of law or financial report can be better interpreted 

by non-technical investor by watching BI Movie™.(Fig. 16) 

 
Figure 6. Benchmarking architecture of proactive surveillance base on EVBI solution vs. reac-

tive architecture in NASDAQ SMART surveillance system 

This Table 1 listed differences between financial surveillance based on EVBI tech-

nology and a sample surveillance system, NASDAQ Smart market surveillance sys-

tem.  

 
Table 1 Benchmarking EVBI and NASDAQ  SMART surveillance system 

Factors EVBI NASDAQ  
SMART 

Extensible BI cubes unlimited Limited and prede-
signed 

Technical Staff Need  No Need Technical staff is 
needed for support  

BI Reports unlimited Limited 



14 

Data Sources Connec-
tivity 

Extensible Limited and prede-
signed 

Implementing New BI 
Requirement  

Extensible NA 

Live Report Offered NA 

Visual Fraud Modeling Offered NA 

Visual SQL Procedure 
Modeling 

Offered NA 

BI Process Reusability Offered NA 

BI Data Reusability Offered NA 

Required Manual Alert 
checking 

NA Required 

Development Year 2014-2019 2006-2010 

The dream of proactive surveillance is realized by EVBI solution, because unlike 

the tradition reactive surveillance approach (used by NASDAQ SMART), the financial 

supervisor can track fraud makers by both tracing their activity and forecasting their 

next probable steps. So, since the user is pre-informed about fraud action in the market, 

he/she can proactively take regulatory action in advanced of fraud mission performed. 

This state-of-the-art EVBI Architecture make complex BI process become transpar-

ent to high level BI users. This feature plus user friendly visual modeling options in 

EVBI enabled user to design visually complex business process without support of 

technical BI developers. The table 2 listed difference between EVBI and a traditional 

BI, Oracle BI.  

 
Table 2 Benchmarking feature of EVBI A traditional BI, Oracle BI 

Factors EVBI Oracle BI 

Extensible BI cubes unlimited NA 

Technical Staff Need  No Need Technical staff is 
needed for support  

BI Reports unlimited Limited 

Data Sources Connec-
tivity 

Extensible Limited and prede-
signed 

Implementing New BI 
Requirement  

Extensible NA 

User-defined 
 data structure 

Offered NA 

User ad-hoc data en-
tries 

 

Offered NA 

Visual SQL Procedure 
Modeling 

Offered NA 

BI Process Reusability Offered NA 

BI Data Reusability Offered NA 

   

Development Year 2014-2019 2006-2010 

 



15 

For example, the user can import a table and use it instantly in joining with other 

data and can create business process visually, finally saved as BI components. Users 

can creatively mode real life scenarios via Visual Modeling.  

 

4 Conclusion and Future Work 

The current study introduced state-of-the-art EVBI, known as a Blockchain-based 

solution for auditing on XBRL Big Data, which can be served as a continuous auditing 

applications. This solution can enable auditors to detect financial frauds without asking 

auditee staff to support. The knowledge in auditing firm can be visually modeled in 

multilayer levels.  

This study examines the impact of BI reporting on audit and assurance services and 

how the use o";"""date"",""2020-06-08T03:29:26Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.5""
""xmp:CreatorTool"",""MicrosoftÂŽ Word 2016""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dc:creator"",""Markus Richter""
""language"",""en""
""dcterms:created"",""2020-06-08T03:29:26Z""
""Last-Modified"",""2020-06-08T03:29:26Z""
""dcterms:modified"",""2020-06-08T03:29:26Z""
""dc:format"",""application/pdf; version=1.5""
""Last-Save-Date"",""2020-06-08T03:29:26Z""
""pdf:docinfo:creator_tool"",""MicrosoftÂŽ Word 2016""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2020-06-08T03:29:26Z""
""meta:save-date"",""2020-06-08T03:29:26Z""
""pdf:encrypted"",""false""
""modified"",""2020-06-08T03:29:26Z""
""Content-Length"",""1272550""
""pdf:hasMarkedContent"",""true""
""Content-Type"",""application/pdf""
""pdf:docinfo:creator"",""Markus Richter""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Markus Richter""
""dc:language"",""en-US""
""meta:author"",""Markus Richter""
""meta:creation-date"",""2020-06-08T03:29:26Z""
""created"",""2020-06-08T03:29:26Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""17""
""Creation-Date"",""2020-06-08T03:29:26Z""
""resourceName"",""FULLTEXT01.pdf""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""2409"",""3096"",""1653"",""3208"",""2922"",""2986"",""2325"",""1311"",""2537"",""1390"",""1812"",""1936"",""1657"",""1687"",""2955"",""3105"",""1407""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""Author"",""Markus Richter""
""producer"",""MicrosoftÂŽ Word 2016""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""MicrosoftÂŽ Word 2016""
""pdf:docinfo:created"",""2020-06-08T03:29:26Z""
";https://scholar.google.ch/scholar?start=680&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098866-334;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;[HTML][HTML] How digitalization affects insurance companies: overview and use cases of digital technologies;C Eckert, K Osterrieder ; Zeitschrift für die gesamte …, 2020  Springer;;"… (2016) apply big data to better predict customer profitability. Gatteschi et al. (2018) contribute

with an investigation of strengths, weaknesses, opportunities and threats when applying

blockchain as distributed ledger technology for smart insurance contracts …";Cité 1 fois;;[HTML] springer.com;https://link.springer.com/article/10.1007/s12297-020-00475-9;"
    
    
    
        
            
            
                
            

            
        
    


    
        
        

        
            
                Advertisement

                    

            

        


    
        
            
                
    
        
            
            [image: SpringerLink]
        
        
        
    


            

            
                
    
        
            
                Search
                
                    
                
            
        
        
            	
                    Log in
                


        
    

    



            

        

    

    
        
            
                
                    
                        
    
        Search SpringerLink
        
            
            
                Search
                
                    
                
            
            
                
            
            
        

    




                    

                

            

        

    



        

    
        
            
                
                
                    
                        
                            How digitalization affects insurance companies: overview and use cases of digital technologies
                        

                        
    
        
            
                Download PDF
                
            
        
    



                    

                

            

            
                
    
        
            
                Download PDF
                
            
        
    


            


            
                
    

            



            
                
                    
                        	Abhandlung
	
            Open Access
        
	Published: 01 October 2020



                        
                        How digitalization affects insurance companies: overview and use cases of digital technologies

                        	Christian Eckert1 & 
	Katrin Osterrieder 
            ORCID: orcid.org/0000-0002-3773-60841 


                        
                            
    Zeitschrift fĂźr die gesamte Versicherungswissenschaft

                            volume 109, pages333–360(2020)Cite this article
                        

                        
    

                        
                            
    
        	
                    3201 Accesses

                
	
                    2 Citations

                
	
                Metrics details

            


    




                        

                            
    

    

                    
                


                
                    Abstract
The digital transformation is of increasing relevance for insurance companies’ business models. It leads to opportunities as well as challenges, especially for IT departments as core enablers or preventers. Against this background, the aim of this paper is to provide a comprehensive overview of digital technologies (e.g., artificial intelligence, cloud computing) and the resulting use cases for the insurance industry. To this end, we conduct a review of academic articles, industry studies and publications of the supervisory authorities. We point to the resulting requirements for an insurer’s IT and find many interdependencies between the digital technologies. Our results therefore emphasize the importance of a holistic digital strategy.


Zusammenfassung
Die digitale Transformation ist auch in der Versicherungswirtschaft von hÜchster Relevanz und bietet Versicherungsunternehmen vielfältige Chancen, stellt aber auch zahlreiche Herausforderungen. Insbesondere die IT von Versicherungsunternehmen nimmt hierbei eine zentrale Rolle ein. Die Zielsetzung des vorliegenden Beitrags liegt in der Darstellung und Analyse digitaler Technologien wie beispielsweise Kßnstlicher Intelligenz oder Cloud Computing. Basierend auf einer umfassenden Aufarbeitung akademischer sowie praxisorientierter Literatur werden die dazugehÜrigen Anwendungsfälle fßr Versicherer identifiziert. Darßber hinaus werden die veränderten Anforderungen an die IT der Versicherungsunternehmen diskutiert. Aufgrund der zahlreichen Interdependenzen bei der Implementierung der digitalen Technologien begrßndet der Beitrag die Relevanz einer holistischen, digitalen Strategie fßr Versicherungsunternehmen.



                    
    


                    

                    

                    
                        
                            Introduction
Innovation through digital technologies, platforms and infrastructures provides entrepreneurial opportunities across all industries and is reflected by new products, services and enhanced processes (e.g., Gault 2018; Nambisan et al. 2019). With regard to the insurance sector, innovation is strongly interrelated with the emerging technologies and concerns the entire value chain (e.g., Bohnert et al. 2019; Eling and Lehmann 2018).
The specific impact of the “digital transformation” through selected technologies for the insurance value chain has been discussed before (e.g., Bramblet et al. 2019; Eling and Lehmann 2018; Naujoks et al. 2017). However, academic as well as practitioner-oriented research lacks a comprehensive overview of the benefits and the opportunities for major technologies with associated insurance use cases and (technical) requirements for the IT in insurance companies.
Academic attention has been given to digitalization in the insurance industry with a systematic overview of previous research on the implications to the insurance value chain and its impact on the insurability of risks (Eling and Lehmann 2018). Bohnert et al. (2019) investigate the positive impact of digital agendas in terms of holistic strategic approaches to the performance of insurance companies. The majority of further academic studies are limited to excerpts of digitalization in insurance and thus specific technologies, e.g., the internet of things with the application of wearables for life and health insurers (Spender et al. 2019) or usage-based insurance (e.g., Desyllas and Sako 2013; Huang and Meng 2019). Moreover, previous literature investigates the opportunities of applying big data (analytics) for insurers. For instance, Zhang et al. (2019) focus on benefits in customer relationship management, Owadally et al. (2019) employ a data mining approach to detect periodicity in the context of underwriting cycles, and Fang et al. (2016) apply big data to better predict customer profitability. Gatteschi et al. (2018) contribute with an investigation of strengths, weaknesses, opportunities and threats when applying blockchain as distributed ledger technology for smart insurance contracts.
In this paper, we aim to contribute to previous literature by comprehensively analyzing the major technologies: big data, artificial intelligence, the internet of things, cloud computing, and the distributed ledger technology. These are all of current and future relevance for insurers. We comprehensively describe their functionalities, and emphasize the benefits as well as the opportunities for the insurers. Employing the digital technologies leads to specific insurance use cases, which reflect digitalization in the insurance industry. Identifying and analyzing them enables a better assessment of the value of digitalization for the insurers (e.g., Deloitte 2017). That is also why we comprehensively review the academic and practitioner-oriented literature to describe the related insurance use cases. Based on this, we identify specific requirements for an insurer’s IT that arise when implementing the different technologies. We also consider interdependencies between them and thus combine a business-related perspective with a technological perspective. Since we find a multitude of interdependencies, our results emphasize the need for a holistic digital transformation strategy that takes a comprehensive perspective on the benefits, the use cases and the requirements for the IT as a result of a bundle of different digital technologies.
The remainder of this article is structured as follows. Section 2 provides an overview of the major digital technologies and includes subsections to define and describe each technology, to analyze the benefits and opportunities, to derive insurance use cases, and to explain the resulting requirements for the IT of the insurers. Section 3 discusses interdependencies and Section 4 summarizes the results.


Relevant insurance use cases and requirements for an insurer’s IT
Overall, we construct a data sample of 102 articles, which result from key word searches (“digitalization” AND “insurance”, “big data” AND “insurance”, “artificial intelligence” AND “insurance”, “internet of things” AND “insurance”, “cloud computing” AND “insurance”, “distributed ledger technology” AND “insurance”, “blockchain” AND “insurance”) in the databases Business Source Complete, EconLit Full Text, and ABI/INFORM Collection.Footnote 1 We also incorporate the results of Google Scholar and Google searches to consider recent discussions of the practitioners as done, for example, by Gatzert and Osterrieder (2020). In addition, we review, assess and incorporate cited references.
We aim to further examine the impact of digitalization on the insurance industry and therefore refer to digitalization as a comprehensive trend (e.g., Gatzert and Osterrieder 2020) with a broad range of (amongst others) economic consequences and do not use the term digitization, which is often utilized for purely technical investigations (e.g., Eling and Lehmann 2018). In terms of digital technologies, we include big data, artificial intelligence, the internet of things, cloud computing and the distributed ledger technology with blockchain as a common form, and refer to these as major digital technologies (e.g., Eling and Lehmann 2018; Kotalakidis et al. 2016), which are defined and discussed in detail in the following subsections. Table 1 summarizes our main findings and comprehensively presents a description of the technologies for insurers. Furthermore, Table 1 explains the benefits as well as the opportunities for each technology and points to the specific insurance use cases. Based on that, we then derive and emphasize the resulting requirements for an insurer’s IT.
Table 1 A description of major technologies for the insurers with related benefits and opportunities, insurance use cases and the resulting requirements for an insurer’s IT based on the literatureFull size table

Big data
Description
While De Mauro et al. (2016) conclude that there is no single definition for big data due to its broad utilization, the term usually refers to a specific type of multidimensional datasets and is commonly attributed to “3V”: volume, velocity, and variety (Laney 2001; Owadally et al. 2019). Volume is assigned to the size of data, while velocity indicates the pace of data being generated and further processed. Variety focuses on the diversity of data, which can be structured, semi-structured or unstructured (e.g., Taleb et al. 2018; Solanki et al. 2019). The attributes can be extended to “5V” by veracity and value, where veracity reflects the degree of reliability of the data and describes the accompanying uncertainty of the results (Ravi and Kamaruddin 2017). With regard to value, there may be ambiguity, latency or lack of traceability of data, reducing the data quality due to the large amount of structured, unstructured and partially structured data. Consequently, the data quality can hardly be controlled (Taleb et al. 2018). In general, value requires the transformation of information into insights to realize economic value for the company and society (De Mauro et al. 2016).Footnote 2
Benefits and opportunities for insurers
The relevance of big data for insurers is substantiated by the functionalities to collect, process and analyze large amounts of (customer) data (e.g., Eling and Lehmann 2018; Kotalakidis et al. 2016). This is fundamental for generating valuable insight from semi-structured and unstructured data stemming from different sources such as social media (e.g., Owadally et al. 2019; Venkatesh 2019).Footnote 3 Thus, big data fosters a better understanding of the customers due to the accessibility of a comprehensive pool of information, which can refer to the interactions between insurer and customer, e.g., during a claims process, but also to the general behavior of a customer, e.g., when driving a car or with regard to sports activities or specific individual habits (Eling and Lehmann 2018; Heo and Grable 2017; Venkatesh 2019). Moreover, analytics approaches convert big data to understandable results for the insurers, e.g., by explaining how customers make their buying decisions. Big data (analytics) enables a high number of correlated variables to be investigated, wherein conventional methods of analytics fail (e.g., Heo and Grable 2017).
Insurance use cases
From these benefits and opportunities of big data, various use cases can be derived for the insurance industry (e.g., Eling and Lehmann 2018; Garde 2017; Helfand 2017; Heo and Grable 2017; Owadally et al. 2019).Footnote 4 Big data is thereby capable of improving the insurance product at its core since integrating the technology to the risk assessment process can improve precise ratemaking and underwriting (e.g., Eling and Lehmann 2018; Venkatesh 2019). Due to the increasing availability of data around a customer, big data might lead to new risk factors and creates business opportunities in the fields of telematics referring to usage and behavior-based pricing (Eling and Lehmann 2018). Continually extending the information base about the customer allows insurance companies to more precisely differentiate several customer segments and positively affects customer lifetime value calculations (Eling and Lehmann 2018; Fang et al. 2016). Kotalakidis et al. (2016) additionally refer to the use case of a more precise prediction of lapse probabilities, which enables insurers to benefit from advanced churn management. However, knowing a policyholder also facilitates tailoring products and services to the customer, e.g., by customized cross- and up-selling recommendations or by delimiting the specific target groups for each product (Venkatesh 2019). Moreover, using big data in combination with related analytics approaches, e.g., text mining, allows the insurers to enhance claims assessments by better identifying fraudulent claims patterns (Eling and Lehmann 2018; Garde 2017).
Managing information streams within an own insurance organization is also subject to big data. Business units such as finance and operations can employ big data to deliver information for investment decisions or to process and analyze internal data more efficiently (e.g., performance data to analyze internal productivity), which is relevant to increase operational excellence (Eling and Lehmann 2018; Helfand 2017). Moreover, controlling products and insured risks can benefit from the vast amount of data as well as the general management of insurance companies since decision-making can be based on a more profound database (Naujoks et al. 2017). In this context, advanced management support systems and business intelligence can improve factors such as the calculation and monitoring of key performance indicators. Furthermore, the technology allows more advanced analyses in risk management. Practical examples refer to managing reserves, calculating large losses (e.g., in the event of a catastrophe), solvency predictions in the context of stress tests and own risk and solvency assessments (ORSA) (Helfand 2017).
Resulting requirements for an insurer’s IT
For the efficient archiving, administration and analysis of large amounts of structured data, relational database management systems (DBMS) have been available for quite some time. These are based on the database language Structured Query Language (SQL) (Foster et al. 2017). With regard to big data, relational DBMS fail due to their size and diversity (Ravi and Kamaruddin 2017). For a large number of unstructured data Not only SQL (NoSQL) databases can be preferred.Footnote 5 NoSQL databases do not have a relational approach, but are compatible with relational DBMS and combine conventional statistical packages (Foster et al. 2017).
Given the main functionality of big data to collect and process vast amounts of data, the requirements for an insurer’s IT include the installation of data lakes and master data management (MDM), which enable insurers to own a single source of truth (SSOT) (DalleMule and Davenport 2017). Data lakes collect data from multiple sources and store data in their original format, which is in contrast to data warehouses (e.g., Wibowo et al. 2017). Data lakes are therefore also able to store unstructured data, which is not possible in relational data systems of data warehouses. Hence, data lakes are not only especially useful to avoid data silos, but also offer an increasing number of efficient possibilities to find patterns and correlations in data (Stein and Morrison 2014; Zies and Schmid 2016).Footnote 6
To comprehensively interpret big data, insurers are required to work with big data analytics and its subcategories descriptive, predictive and prescriptive analytics (Pusala et al. 2016; Sivarajah et al. 2017).Footnote 7 Besides specific algorithms and databases, insurance companies have to gather knowledge and need appropriately skilled staff able to implement the respective big data tools, to monitor data quality, and to address the aforementioned requirements. Finally, the benefit of big data also depends on the availability, accuracy and reliability of the underlying data (EIOPA 2019). Hence, the preparation of data is a crucial step in order to gain useful information from the data. To be able to conduct holistic big data analyses, it is necessary to have a single data platform, where all data are stored, in contrast with data silos (BaFin 2018a).
Artificial intelligence
Description
Artificial intelligence can be defined as intelligence demonstrated by machines that mimics cognitive functions associated with the human mind, e.g., learning, problem solving and reasoning (Anyoha 2017; Kelley et al. 2018; Russell and Norvig 2016).Footnote 8 Machine learning is an important subcategory of artificial intelligence (Eckert and Eckert 2020; Kelley et al. 2018). Algorithms use data to learn the transformation rules for generating a desired output by reducing the deviations between the generated and the desired result within an iterative training process (Deloitte 2017).Footnote 9 While machine learning algorithms automatically improve through structural feedback, deep learning refines machine learning (e.g., Kelley et al. 2018) by using artificial neural networks (De Armond 2016; Eckert and Eckert 2020; Kelley et al. 2018).
Benefits and opportunities
One major opportunity of artificial intelligence for insurers refers to deriving the benefits of customer data along with big data (Kelley et al. 2018; Riikkinen et al. 2018). Implementing and integrating the corresponding algorithms into existing products and processes increases effectiveness and efficiency (Eling and Lehmann 2018). Assessing information by employing big data as well as further processing it with artificial intelligence implies information as a “commodity” of insurance companies, which substantiates the potential to significantly lower expenses and transaction costs. Artificial intelligence is generally highlighted as technology to further handle analytical results about insureds and to generate insight in terms of (ex-ante) risk prediction and (ex-post) risk monitoring (SCOR 2018).Footnote 10
Insurance use cases
Artificial intelligence allows insurers to improve customer segmentation by means of pattern recognition compared to conventional approaches, e.g., by removing human bias, by finding hidden patterns, by providing automated updates based on individual behavior, or by defining personalized micro-segments. The resulting customer segmentation approaches are therefore characterized by high scalability with less intense maintenance (Brenner 2019). Based on customer segmentation, the technology further supports the insurance company by providing predictive analytics tools such as Extreme Gradient Boosting techniques to calculate lapse rates, churn propensities or to derive up- and cross-selling recommendations (Albrecher et al. 2019; EIOPA 2019; Riikkinen et al. 2018). Along with the use cases of big data, artificial intelligence can also be used in insurance ratemaking and underwriting (e.g., Riikkinen et al. 2018; Burri et al. 2019). Compared to conventional pricing methods, applying pattern recognition can, for example, result in more precise risk factors (e.g., Burri et al. 2019). Moreover, artificial intelligence improves the opportunities to detect fraudulent claims (Eling and Lehmann 2018; Gruhn 2018). For instance, insurers can utilize anomaly and image recognition mechanisms, which can also incorporate information stemming from external databases, to reliably detect insurance fraud (Gruhn 2018).Footnote 11 Automated claims assessment processes can incorporate information about the behavior of insureds and of individuals within their social (media) networks or third parties, who are affected by the reported damage, or can square historical claims with the reported claims and consider fraudulent patterns (Ravi and Kamaruddin 2017).Footnote 12
While those insurance use cases can be basically developed by analyzing big data, the potential of artificial intelligence can also be applied to increase the quality of the insurance customer experience, e.g., due to advanced services and fast processes (e.g., Eling and Lehmann 2018; Hall 2017; SCOR 2018). Facial recognition simplifies authorization and may therefore increase customer satisfaction in sales and service processes, whilst image recognition in general can be used to automatically analyze images in claims management (e.g., Shang 2018) allowing an acceleration of respective processes.Footnote 13 Similarly, emotion recognition also typically applies convolutional neural networks and enables insurance companies to assess the emotions of their customers, e.g., during a phone call (Hijazi et al. 2015). Insurers can thus evaluate a customer’s feedback based on sentiment analysis, which helps to improve the interaction with the customer (EIOPA 2019).
With regard to customer interaction use cases, the reviewed articles refer to robo-advisory (e.g., Eling and Lehmann 2018; Kelley et al. 2018; Maedche et al. 2016; Sironi 2016), which provides an automated, interactive, and intelligent process of advisory to the customer (e.g., Maedche et al. 2016; Sironi 2016). Currently, the term robo-advisor tends to refer to asset management user assistance (Kelley et al. 2018), but can also be transferred to fields such as healthcare (Jung et al. 2018). By integrating robo-advisors into insurance organizations, the digital assistant can rebalance portfolios with regard to asset management considering pre-defined risk appetites and in line with solvency requirements (Catlin et al. 2015; Eling and Lehmann 2018). In addition to robo-advisors, chatbots can digitally offer insurance products and services (e.g., Riikkinen et al. 2018).Footnote 14 Chatbots are natural language processing-based dialogue systems consisting of text input and output used in communication and customer care (e.g., Belanche et al. 2019; Abdul-Kader and Woods 2015; Hill et al. 2015).Footnote 15
Resulting requirements for an insurer’s IT
Supervised machine learning models are depicted as self-learning technology that needs to train and enhance its analysis capabilities over time (Hall 2017). Hence, it is necessary to provide the required data. Moreover, from a regulatory perspective, in Germany the BaFin (2018a) demands comprehensible and transparent models as well as a non-discriminatory data analysis. This is particularly challenging when using neural networks. Neural networks are often rather like black boxes, which is why further research regarding explainable and trustworthy artificial intelligence is necessary (BaFin 2018a). In addition, the IT infrastructure is continuously required to ensure data quality (e.g., resistance against manipulation) including the possibility to conduct internal revisions (BaFin 2019; SCOR 2018).
Moreover, by focusing on the functionalities of the application programming interfaces (APIs), insurance companies increasingly gain the ability to integrate, e.g., specific applications of artificial intelligence such as image recognition or external data from devices, which are related to the internet of things, as well as data stemming from brokers or members of partnering networks within holistic insurance ecosystems. APIs are therefore standardized interfaces that enable and simplify communication between different services (Spichale 2017). In the German insurance industry, BiPro and FRIDA, for example, provide APIs in order to achieve a more efficient data exchange.
Internet of things
Description
Due to the increasing integration of devices via the Internet (Wierse and Riedel 2017) along with the continuous adoption of smartphones, (connected) wearables, “smart” homes and cities, the internet of things becomes increasingly relevant (e.g., Capgemini 2019). The technology generally refers to an identifiable system of objects (e.g., furniture, wearables, vehicles) whose information is transmitted without human intervention, and has emerged in particular from the integration of microelectromechanical systems, wireless technologies and the Internet (Priyadarshini et al. 2019; Spender et al. 2019).
Benefits and opportunities
Integrating the opportunities through the internet of things helps to increase the interaction with the customer and extends the knowledge about the customer as an individual. The connected devices can comprehensively collect information about the specific behavior of an individual customer and thus have the potential to support insurers in extending their product offerings with insurance “on demand” or in offering insurance products with the value proposition of additional services (e.g., Behm et al. 2019; Eling and Lehmann 2018; EIOPA 2019; Franke 2019; Priyadarshini et al. 2019; Spender et al. 2019).
For instance, health and life insurers assign particular relevance to wearables such as fitness trackers, but also to medical devices or clothing, including shoes. Moreover, property and liability insurers can benefit from the information, for example, that is recorded and transmitted by the sensors of connected cars (Spender et al. 2019).Footnote 16 The devices and the vast amount of related customer information in addition to conventional data (e.g., demographic information, exposure, and customer interaction history) substantiates the relevance of the internet of things for the insurers (e.g, Behm et al. 2019; EIOPA 2019). Insurers benefit from the increasing number of measures to monitor the behavior of the individual customers. Based on this, insurers can steer the individual behavior of insureds by providing the impetus to change habits, e.g., increasing health awareness by incentivizing desirable behavioral patterns (e.g., EIOPA 2019; Spender et al. 2019).
Insurance use cases
The internet of things and big data are major drivers of new products such as telematics and usage-based insurance (e.g., Eling and Lehmann 2018; Spender et al. 2019).Footnote 17 In this context, insurance ratemaking is based on the specific behavior of an individual and thus results in a more accurate pricing (Derikx et al. 2016; EIOPA 2019). Behavior-related data enable insurance companies to conduct digital monitoring and, therefore, to improve loss prevention by offering preventative support for customers and to reduce losses (Behm et al. 2019; EIOPA 2019; Eling and Lehmann 2018). Hence, the internet of things allows insurance companies to increase the frequency of customer interaction, to enhance customer engagement and to extend their scope beyond the moment-of-truth (Spender et al. 2019). This is particularly rewarding when insurance companies partner with companies from other industries and build an ecosystem (Behm et al. 2019). For instance, by partnering with tech companies such as the providers of wearables, insurers can introduce related marketing initiatives, e.g., by offering price reduction for fitness trackers (e.g., Spender et al. 2019).Footnote 18
Moreover, the internet of things helps insurance companies to automate their processes (e.g., an automated first notice of loss or an automated trouble report) and allows insurance companies to collect more data about customers. Due to the better understanding of the customers, insurers can improve fraud detection (Behm et al. 2019; EIOPA 2019). Finally, the internet of things might also increase data quality due to fewer manual processes and increased automation (e.g., Karkouch et al. 2016).
Resulting requirements for an insurer’s IT
The technology requires the implementation and integration of specific sensors, which collect and transfer data (e.g., Banafa 2016). Assessing large amounts of raw customer data accompanies the internet of things and requires sufficient capacity and knowledge to translate the results into insurance products, e.g., by employing a data analytics tool (e.g., Spender et al. 2019) and substantiates the need for appropriate IT services. The large amount of transmitted data is also why insurers are required to increase data storage capacities with regard to their IT infrastructures (Eling and Lehmann 2018; Priyadarshini et al. 2019; Spender et al. 2019).
Cloud computing
Description
Cloud computing service providers offer external computing and storage capacities that enable flexible access to pooled computing resources such as networks, servers, storage capacities, or applications (e.g., Sedkaoui 2018).Footnote 19 The technology incorporates the service delivery models Software as a Service (SaaS), Platform as a Service (PaaS), Infrastructure as a Service (IaaS), and Database as a Service (DBaaS) (e.g., Marinescu 2018). The service models differentiate between the provided services and capabilities (Mell and Grance 2011). Moreover, utilizing cloud computing can refer to private clouds, community clouds, public clouds or hybrid clouds. Whilst a public cloud is open to the public, a private cloud infrastructure is operated by internal, company-owned data centers or a selected service provider and is exclusively accessible by a predefined target group. Community clouds are implemented by an extended circle of people with common interests. A hybrid cloud combines attributes of the two aforementioned cloud models (e.g., Leroy et al. 2018; Marinescu 2018; Mell and Grance 2011).
Benefits and opportunities
In general, the resulting computing resources facilitate a decline in management costs (e.g., Mell and Grance 2011). Due to on-demand payment schemes, cloud computing is a measure to increase cost effectiveness (e.g., Ali et al. 2015). Cloud computing allows insurers to increase their own flexibility as well as efficiency, since the required capacities can be rapidly scaled (BaFin 2018a; EIOPA 2019).Footnote 20 For instance, the service delivery model IaaS includes renting storage capacities and computing power and allows insurers to reduce their own hardware capacities, which are required to be sufficient even at peak times. As a consequence, this kind of outsourcing enables insurance companies not only to save hardware and software costs but also leads to reduced expenses with respect to installation and maintenance. Moreover, SaaS can be applied to get standard software, services and applications of artificial intelligence with respect to, for example, image recognition or natural language processing from the cloud (e.g., BaFin 2018a). In addition to saving software development costs (e.g., Leroy et al. 2018), SaaS allows insurance companies to use the most up-to-date software (Kimmig 2020). In general, cloud computing enables access to data independent of time and location, which is especially relevant to the timely processing of data (e.g., large-scale data as a result of the i";"""dc.publisher"",""Springer""
""og:image"",""https://media.springernature.com/w200/springer-static/cover/journal/12297.jpg""
""twitter:card"",""summary""
""og:site_name"",""Zeitschrift fĂźr die gesamte Versicherungswissenschaft""
""citation_reference"",""citation_journal_title=Int. J. Adv. Comput. Sci. Appl.; citation_title=Survey on chatbot design techniques in speech conversation systems; citation_author=SA Abdul-Kader, J Woods; citation_volume=6; citation_issue=7; citation_publication_date=2015; citation_pages=72-80; citation_id=CR1"",""citation_journal_title=Eur. Actuar. J.; citation_title=Insurance: models, digitalization, and data science; citation_author=H Albrecher, A Bommier, D Filipović, P Koch-Medina, S Loisel, H Schmeiser; citation_volume=9; citation_publication_date=2019; citation_pages=349-360; citation_id=CR2"",""citation_journal_title=Inform. Sci.; citation_title=Security in cloud computing: opportunities and challenges; citation_author=M Ali, SU Kahn, AV Vasilakos; citation_volume=305; citation_publication_date=2015; citation_pages=357-383; citation_id=CR3"",""Anyoha, R.: The history of artificial intelligence (2017).                    http://sitn.hms.harvard.edu/flash/2017/history-artificial-intelligence/                                    . Accessed 26 Aug 2020"",""BaFin: Big Data trifft auf künstliche Intelligenz (2018a).                    https://www.bafin.de/SharedDocs/Downloads/DE/dl_bdai_studie.pdf?__blob=publicationFile&v=3                                    . Accessed 7 Mar 2020"",""BaFin: Cloud-Computing: Einhaltung der aufsichtsrechtlichen Vorgaben zu Informations- und Prüfungsrechten sowie Kontrollmöglichkeiten (2018b).                    https://www.bafin.de/SharedDocs/Veroeffentlichungen/DE/Fachartikel/2018/fa_bj_1804_Cloud_Computing.html                                    . Accessed 19 Feb 2020"",""BaFin: Insurtech – Eine Einordnung. BaFin Journal (2019).                    https://www.bafin.de/SharedDocs/Veroeffentlichungen/DE/Fachartikel/2019/fa_bj_1901_Insurtech.html                                    . Accessed 3 Mar 2020"",""Banafa, A.: IoT standardization and implementation challenges. IEEE Internet of Things Newsletter (2016).                    https://iot.ieee.org/newsletter/july-2016/iot-standardization-and-implementation-challenges.html                                    . Accessed 26 Aug 2020"",""Baron, R., Chaudey, M.: Blockchain and smart-contract: a pioneering approach of inter-firms relationships? The case of franchise networks. Working Paper, University of Lyon (2019).                    https://ssrn.com/abstract=3378477                                    . Accessed 24 May 2019"",""Behm, S., Deetjen, U., Kaniyar, S., Methner, N., Münstermann, B.: Digital ecosystems for insurers: opportunities through the internet of things (2019).                    https://www.mckinsey.com/~/media/McKinsey/Industries/Financial%20Services/Our%20Insights/Digital%20ecosystems%20for%20insurers%20Opportunities%20through%20the%20Internet%20of%20Things/Digital-ecosystems-for-insurers-Opportunities-through-the-Internet-of-Things.ashx                                    . Accessed 26 Jan 2020"",""citation_journal_title=Ind. Manag. Data Syst.; citation_title=Artificial intelligence in FinTech: understanding robo-advisors adoption among customers; citation_author=D Belanche, LV Casaló, C Flavián; citation_volume=119; citation_issue=7; citation_publication_date=2019; citation_pages=1411-1430; citation_id=CR11"",""citation_title=Bitcoin, Blockchain und Kryptoassets: Eine umfassende Einführung; citation_publication_date=2017; citation_id=CR12; citation_author=A Berentsen; citation_author=F Schär; citation_publisher=Books on Demand GmbH"",""citation_journal_title=J. Emerg. Trends Comput. Inf. Sci.; citation_title=Detecting auto insurance fraud by data mining techniques; citation_author=R Bhowmik; citation_volume=2; citation_issue=4; citation_publication_date=2011; citation_pages=156-162; citation_id=CR13"",""Bitkom, KPMG: Mit Daten Werte schaffen (2016).                    https://cdn2.hubspot.net/hubfs/571339/LandingPages-PDF/kpmg-mdws-201-sec.pdf                                    . Accessed 4 Aug 2020"",""citation_journal_title=Geneva Pap. Risk Insur. Issues Pract.; citation_title=Digital agendas in the insurance industry: the importance of comprehensive approaches; citation_author=A Bohnert, A Fritzsche, S Gregor; citation_volume=44; citation_issue=1; citation_publication_date=2019; citation_pages=1-19; citation_id=CR15"",""Bramblet, J., Presutti, D., Lyman, M., Starrs, A., Viale, E., Rangwala, A.: The post digital era is upon us (get ready for what’s next in insurance) (2019).                    https://financialservices.accenture.com/rs/368-RMC-681/images/Accenture-Technology-Vision-for-Insurance-2019-Full-Report.pdf                                    . Accessed 29 Jan 2020"",""Brenner, M.: How to improve customer segmentation with AI (2019).                    https://marketinginsidergroup.com/artificial-intelligence/how-to-improve-customer-segmentation-with-ai/                                    . Accessed 30 Jan 2020"",""citation_title=Blockchain Kurz & Gut; citation_publication_date=2018; citation_id=CR18; citation_author=K Brünnler; citation_publisher=O’Reilly"",""citation_journal_title=Int. J. Adv. Sci. Technol.; citation_title=Insurance claim analysis using machine learning algorithms; citation_author=RD Burri, R Burri, RR Bojja, S Buruga; citation_volume=127; citation_issue=1; citation_publication_date=2019; citation_pages=147-155; citation_id=CR19"",""Capgemini: 5G in industrial operations (2019).                    https://www.capgemini.com/research/5g-in-industrial-operations/                                    . Accessed 26 Jan 2020"",""Catlin, T., Hartmann, R., Segev, I., Tentis, R.: The making of a digital insurer: the path to enhanced profitability, lower costs and stronger customer loyalty (2015).                    http://www.mckinsey.com/industries/financial-services/our-insights/the-making-of-a-digital-insurer                                    . Accessed 12 Aug 2019"",""Corea, F.: The convergence of AI and blockchain: what’s the deal? (2017).                    https://hackernoon.com/the-convergence-of-ai-and-blockchain-whats-the-deal-60c618e3accc                                    . Accessed 3 Aug 2020"",""citation_journal_title=J. Insur. Inst. India; citation_title=Impact of technological advancements on general insurance; citation_author=SK Dahuja; citation_volume=6; citation_issue=2; citation_publication_date=2019; citation_pages=47-55; citation_id=CR23"",""citation_journal_title=Harv. Bus. Rev.; citation_title=What’s your data strategy; citation_author=L DalleMule, TH Davenport; citation_volume=95; citation_issue=3; citation_publication_date=2017; citation_pages=112-121; citation_id=CR24"",""citation_journal_title=J. Inst. Econ.; citation_title=Blockchains and the economic institutions of capitalism; citation_author=S Davidson, P De Filippi, J Potts; citation_volume=14; citation_issue=4; citation_publication_date=2018; citation_pages=639-658; citation_id=CR25"",""De Armond, C.: Deep learning has deep potential for insurers (2016).                    https://insuranceblog.accenture.com/deep-learning-has-deep-potential-for-insurers                                    . Accessed 22 Aug 2019"",""citation_journal_title=Libr. Rev.; citation_title=A formal definition of big data based on its essential features; citation_author=A De Mauro, M Greco, M Grimaldi; citation_volume=65; citation_issue=3; citation_publication_date=2016; citation_pages=122-135; citation_id=CR27"",""Deloitte: From mystery to mastery: unlocking the business value of artificial intelligence in the insurance industry (2017).                    https://www2.deloitte.com/content/dam/Deloitte/ie/Documents/Technology/IE_Insurance%20Whitepaper_0318.pdf                                    . Accessed 27 Aug 2019"",""citation_journal_title=Electron. Mark.; citation_title=Can privacy concerns for insurance of connected cars be compensated?; citation_author=S Derikx, M De Reuver, M Kroesen; citation_volume=26; citation_issue=1; citation_publication_date=2016; citation_pages=73-81; citation_id=CR29"",""citation_journal_title=Res Policy; citation_title=Profiting from business model innovation: evidence from pay-as-you-drive auto insurance; citation_author=P Desyllas, M Sako; citation_volume=42; citation_publication_date=2013; citation_pages=101-116; citation_id=CR30"",""Duncan, C., Dague, D., Giunta, S., Chandler, D., Schlieker, A.: Exploring cloud readiness in insurance (2019).                    https://www.accenture.com/us-en/insights/financial-services/tech-advisory-insurance-cloud-strategic-investment-europe                                    . Accessed 26 Jan 2020"",""citation_title=Maschinelles Lernen: Wie künstliche Intelligenz die Versicherungswirtschaft verändert; citation_inbook_title=Insurance & Innovation 2020: Ideen und Erfolgskonzepte von Experten aus der Praxis; citation_publication_date=2020; citation_pages=87-93; citation_id=CR32; citation_author=C Eckert; citation_author=J Eckert; citation_publisher=Verlag Versicherungswirtschaft"",""EIOPA: Big data analytics in motor and health insurance: a thematic review (2019).                    https://www.eiopa.europa.eu/content/eiopa-reviews-use-big-data-analytics-motor-and-health-insurance_en                                    . Accessed 24 Apr 2020"",""citation_journal_title=Geneva Pap. Risk Insur. Issues Pract.; citation_title=The impact of digitalization on the insurance value chain and the insurability of risks; citation_author=M Eling, M Lehmann; citation_volume=43; citation_issue=3; citation_publication_date=2018; citation_pages=359-396; citation_id=CR34"",""citation_journal_title=Comput. Ind. Eng.; citation_title=Customer profitability forecasting using big data analytics: a case study of the insurance industry; citation_author=K Fang, Y Jiang, M Song; citation_volume=101; citation_publication_date=2016; citation_pages=554-564; citation_id=CR35"",""citation_title=Big Data and Social Science (A Practical Guide to Methods and Tools); citation_publication_date=2017; citation_id=CR36; citation_author=I Foster; citation_author=R Ghani; citation_author=RS Jarmin; citation_author=F Kreuter; citation_author=J Lane; citation_publisher=CRC Press"",""Franke, U.: Towards increased transparency in digital insurance. ERCIM News (2019).                    https://ercim-news.ercim.eu/images/stories/EN116/EN116-web.pdf                                    . Accessed 26 Aug 2020"",""citation_journal_title=J. Insur. Inst. India; citation_title=Fraud management in insurance claims; citation_author=MD Garde; citation_volume=IV; citation_issue=IV; citation_publication_date=2017; citation_pages=11-13; citation_id=CR38"",""citation_journal_title=Future Internet; citation_title=Blockchain and smart contracts for insurance: is the technology mature enough; citation_author=V Gatteschi, F Lamberti, C Demartini, C Pranteda, V Santamaria; citation_volume=10; citation_issue=2; citation_publication_date=2018; citation_pages=1-16; citation_id=CR39"",""citation_journal_title=Risk Manag. Insur. Rev.; citation_title=The future of mobility and its impact on the automobile insurance industry; citation_author=N Gatzert, K Osterrieder; citation_volume=23; citation_issue=1; citation_publication_date=2020; citation_pages=31-51; citation_id=CR40"",""citation_journal_title=Res Policy; citation_title=Defining and measuring innovation in all sectors of economy; citation_author=F Gault; citation_volume=47; citation_issue=3; citation_publication_date=2018; citation_pages=617-622; citation_id=CR41"",""GDV: Versicherungscloud nach internationalen Sicherheitsstandards zertifiziert (2015).                    https://www.gdv.de/de/themen/news/versicherungscloud-nach-internationalen-sicherheitsstandards-zertifiziert-16952                                    . Accessed 7 Mar 2020"",""German Federal Government: Big Data und künstliche Intelligenz im Versicherungssektor (2018).                    http://dip21.bundestag.de/dip21/btd/19/063/1906310.pdf                                    . Accessed 30 Jan 2020"",""citation_journal_title=Geneva Pap. Risk Insur. Issues Pract.; citation_title=A STEEP framework analysis of the key factors impacting the use of blockchain technology in the insurance industry; citation_author=S Grima, J Spiteri, I Romanova; citation_volume=45; citation_publication_date=2020; citation_pages=398-425; citation_id=CR44"",""citation_journal_title=Wirtschaftsinform. Manag.; citation_title=Versicherungen: Von Natur aus für Künstliche Intelligenz geeignet; citation_author=V Gruhn; citation_volume=10; citation_issue=4; citation_publication_date=2018; citation_pages=104-111; citation_id=CR45"",""Hall, S.N.: How artificial intelligence is changing the insurance industry. CIPR newsletter (2017).                    https://www.naic.org/cipr_newsletter_archive/vol22_ai.pdf                                    . Accessed 26 Aug 2020"",""citation_journal_title=J. Netw. Innov. Comput.; citation_title=Computational intelligence models for insurance fraud detection: a review of a decade of research; citation_author=AKI Hassan, A Abraham; citation_volume=1; citation_publication_date=2013; citation_pages=341-347; citation_id=CR47"",""citation_journal_title=J. Internet Law; citation_title=Big data and insurance: what lawyers need to know and understand; citation_author=RD Helfand; citation_volume=21; citation_issue=3; citation_publication_date=2017; citation_pages=2-35; citation_id=CR48"",""citation_journal_title=Econ. Invest. Manag.; citation_title=Demand for life insurance: a consumer perspective; citation_author=W Heo, JE Grable; citation_volume=71; citation_issue=3; citation_publication_date=2017; citation_pages=19-22; citation_id=CR49"",""Hijazi, S., Kumar, R., Rowen, C.: Using convolutional neural networks for image recognition (2015).                    https://ip.cadence.com/uploads/901/cnn_wp-pdf                                    . Accessed 26 Aug 2020"",""citation_journal_title=Comput. Hum. Behav.; citation_title=Real conversations with artificial intelligence: a comparison between human-human online conversations and human-chatbot conversations; citation_author=J Hill, WR Ford, IG Farreras; citation_volume=49; citation_publication_date=2015; citation_pages=245-250; citation_id=CR51"",""citation_journal_title=Decis. Support Syst.; citation_title=Automobile insurance classification ratemaking based on telematics driving data; citation_author=Y Huang, S Meng; citation_volume=127; citation_publication_date=2019; citation_pages=113-156; citation_id=CR52"",""citation_journal_title=Bus. Inf. Syst. Eng.; citation_title=Robo-advisory—digitalization and automation of financial advisory; citation_author=D Jung, V Dorner, F Glaser, S Morana; citation_volume=60; citation_issue=1; citation_publication_date=2018; citation_pages=81-86; citation_id=CR53"",""citation_journal_title=Int. J. Healthc. Manag.; citation_title=A systematic perspective on the applications of big data analytics in healthcare management; citation_author=SS Kamble, A Gunasekaran, M Goswami, J Manda; citation_volume=12; citation_issue=3; citation_publication_date=2019; citation_pages=226-240; citation_id=CR54"",""citation_journal_title=J. Netw. Comput. Appl.; citation_title=Data quality in Internet of Things: a state-of-the-art survey; citation_author=A Karkouch, H Mousannif, H Al Moatassime, T Noel; citation_volume=73; citation_publication_date=2016; citation_pages=57-81; citation_id=CR55"",""citation_journal_title=Risk Manag Insur Rev; citation_title=Artificial intelligence: implications for social inflation and insurance; citation_author=KH Kelley, LM Fontanetta, M Heintzman, N Pereira; citation_volume=21; citation_issue=3; citation_publication_date=2018; citation_pages=373-387; citation_id=CR56"",""Ketterer, H., Koopmans, J., Mäurers, R.: Building a digital technology foundation in insurance (2016).                    https://www.bcg.com/de-de/publications/2016/building-a-digital-technology-foundation-in-insurance.aspx                                    . Accessed 26 Jan 2020"",""Kimmig, M.: Evolution statt Revolution: Zehn IT-Trends für die Assekuranz 2020 (2020).                    https://versicherungswirtschaft-heute.de/maerkte-und-vertrieb/2020-01-13/evolution-statt-revolution-zehn-it-trends-fuer-die-assekuranz-2020/                                    . Accessed 30 Jan 2020"",""Kotalakidis, N., Naujoks, H., Müller, F.: Digitalisierung der Versicherungswirtschaft: Die 18-Milliarden-Chance (2016).                    https://www.bain.com/contentassets/47d312fae3a94e9d9629c66d078243ab/bain-google-studie_digitalisierung_der_versicherungswirtschaft_ds_final.pdf                                    . Accessed 26 Aug 2019"",""Laney, D.: 3D data management: controlling data volume, velocity, and variety. META Group research note (2001).                    https://blogs.gartner.com/doug-laney/files/2012/01/ad949-3D-Data-Management-Controlling-Data-Volume-Velocity-and-Variety.pdf                                    . Accessed 26 Aug 2020"",""citation_journal_title=J. Manag. Inf. Syst.; citation_title=How big data analytics enables service innovation: materiality, affordance, and the individualization of service; citation_author=C Lehrer, A Wieneke, J Vom Brocke, R Jung, S Seidel; citation_volume=35; citation_issue=2; citation_publication_date=2018; citation_pages=424-460; citation_id=CR61"",""Leroy, R., de Fontenay, E.B., Murugavel, K.: Insurance cloud – from tactical to strategic investment for European insurers (2018).                    https://www.accenture.com/_acnmedia/pdf-86/accenture-insurance-cloud-strategic-investment-europe.pdf                                    . Accessed 26 Jan 2020"",""citation_title=Blockchain and IoT data analytics for fine-grained transportation insurance; citation_inbook_title=IEEE 224th Int. Conf. Parallel Distrib. Syst.; citation_publication_date=2018; citation_pages=1022-1027; citation_id=CR63; citation_author=Z Li; citation_author=Z Xiao; citation_author=Q Xu; citation_author=E Sotthiwat; citation_author=RSM Goh; citation_author=X Liang"",""Lünendonk Study: Versicherungen in der Zeitfalle (2018).                    https://www.luenendonk.de/portfolio/versicherungen-in-der-zeitfalle/                                    . Accessed 21 Aug 2019"",""citation_journal_title=Bus Inf Syst Eng; citation_title=Advanced user assistance systems; citation_author=A Maedche, S Morana, S Schacht, D Werth, J Krumeich; citation_volume=58; citation_issue=5; citation_publication_date=2016; citation_pages=367-370; citation_id=CR65"",""citation_title=Cloud Computing (Theory and Practice); citation_publication_date=2018; citation_id=CR66; citation_author=DC Marinescu; citation_publisher=Morgan Kaufmann"",""citation_journal_title=J. Manag. Sci. Bus. Intell.; citation_title=Big data has unique needs for information governance and data quality; citation_author=CA Mathes; citation_volume=1; citation_issue=1; citation_publication_date=2016; citation_pages=12-20; citation_id=CR67"",""Mell, P., Grance, T.: The NIST definition of cloud computing (2011).                    https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-145.pdf                                    . Accessed 27 July 2020"",""citation_journal_title=Res. Policy; citation_title=The digital transformation of innovation and entrepreneurship: progress, challenges and key themes; citation_author=S Nambisan, M Wright, M Feldman; citation_volume=48; citation_issue=8; citation_publication_date=2019; citation_pages=1-9; citation_id=CR69"",""Naujoks, H., Müller, F., Kotalakidis, N.: Digitalization in insurance: the multibillion dollar opportunity (2017).                    https://www.bain.com/insights/digitalization-in-insurance/                                    . Accessed 11 Aug 2019"",""Nguyen, D.C., Pathirana, P.N., Ding, M., Seneviratne, A.: Integration of blockchain and cloud of things: architecture, applications and challenges (2019).                    https://arxiv.org/abs/1908.09058                                    . Accessed 8 Aug 2020"",""citation_journal_title=N. Am. Actuar. J.; citation_title=Time series data mining with an application to measure of underwriting cycles; citation_author=I Owadally, F Zhou, R Otunba, J Lin, D Wright; citation_volume=23; citation_issue=3; citation_publication_date=2019; citation_pages=469-484; citation_id=CR72"",""Poppleton, A., Struntz, J., Lees, C.: Get comfortable outside your comfort zone (2019).                    https://www.accenture.com/_acnmedia/pdf-92/accenture-insurance-digital-transformation-remaking-an-industry.pdf                                    . Accessed 26 Jan 2020"",""Pritchett, W., Terry, H., Makita, Y., Brenchley, P., Adesman, I., Milligan, D., Huang, B., Plotkin, G.: Insurtech 10: trends for 2019 (2019).                    https://assets.kpmg/content/dam/kpmg/mu/pdf/2019/insurtech-trends-2019.pdf                                    . Accessed 4 Aug 2020"",""citation_title=The role of IoT and big data in modern technological arena: a comprehensive study; citation_inbook_title=Internet of Things and Big Data Analytics for Smart Generation; citation_publication_date=2019; citation_pages=13-25; citation_id=CR75; citation_author=SBB Priyadarshini; citation_author=A BhusanBagjadab; citation_author=BK Mishra; citation_publisher=Springer"",""citation_title=Massive data analysis: tasks, tools, applications, and challenges; citation_inbook_title=Big Data Analytics; citation_publication_date=2016; citation_pages=11-40; citation_id=CR76; citation_author=MK Pusala; citation_author=MA Salehi; citation_author=JR Katukuri; citation_author=Y Xie; citation_author=V Raghavan; citation_publisher=Springer"",""PwC: Blockchain in Financial Services – Mehr als nur ein Hype? (2018).                    https://www.pwc.de/de/finanzdienstleistungen/Blockchain_in_Financial_Services_2018.pdf                                    . Accessed 30 Jan 2020"",""citation_title=Big data analytics enabled smart financial services: opportunities and challenges; citation_inbook_title=Big Data Analytics; citation_publication_date=2017; citation_pages=15-39; citation_id=CR78; citation_author=V Ravi; citation_author=S Kamaruddin; citation_publisher=Springer"",""citation_journal_title=Int. J. Bank Mark.; citation_title=Using Artificial Intelligence to Create Value in Insurance; citation_author=M Riikkinen, H Saarijärvi, P Sarlin, I Lähteenmäki; citation_volume=36; citation_issue=6; citation_publication_date=2018; citation_pages=1145-1168; citation_id=CR79"",""citation_title=Artificial intelligence: a modern approach; citation_publication_date=2016; citation_id=CR80; citation_author=S Russell; citation_author=P Norvig; citation_publisher=Prentice Hall"",""SCOR: The impact of artificial intelligence on the (re)insurance sector (2018).                    https://www.scor.com/sites/default/files/focus_scor-artificial_intelligence.pdf                                    . Accessed 29 Jan 2020"",""citation_title=Data Analytics and Big Data; citation_publication_date=2018; citation_id=CR82; citation_author=S Sedkaoui; citation_publisher=John Wiley & Sons"",""Shang, K.: Applying image recognition to insurance. Society of Actuaries (2018).                    https://www.soa.org/globalassets/assets/Files/resources/research-report/2018/applying-image-recognition.pdf                                    . Accessed 26 July 2020"",""citation_journal_title=Manag. Financ.; citation_title=Blockchain and contract theory: modeling smart contracts using insurance markets; citation_author=A Sheth, H Subramanian; citation_publication_date=2019; citation_doi=10.1108/MF-10-2018-0510; citation_id=CR84"",""citation_journal_title=Risk Manag.; citation_title=Can blockchain improve insurance?; citation_author=AW Singer; citation_volume=66; citation_issue=1; citation_publication_date=2019; citation_pages=20-25; citation_id=CR85"",""citation_title=FinTech Innovation: From Robo-Advisors to Goal Based Investing and Gamification; citation_publication_date=2016; citation_id=CR86; citation_author=P Sironi; citation_publisher=John Wiley & Sons"",""citation_journal_title=J Bus Res; citation_title=Critical analysis of big data challenges and analytical methods; citation_author=U Sivarajah, MM Kamal, Z Irani, V Weerakkody; citation_volume=70; citation_publication_date=2017; citation_pages=263-286; citation_id=CR87"",""citation_title=Theoretical analysis of big data for smart scenarios; citation_inbook_title=Internet of Things and Big Data Analytics for Smart Generation; citation_publication_date=2019; citation_pages=1-12; citation_id=CR88; citation_author=VK Solanki; citation_author=S Makkar; citation_author=R Kumar; citation_author=JM Chatterjee; citation_publisher=Springer"",""citation_title=End to end automation on cloud with build pipeline: the case for DevOps in insurance industry, continous integration, continous testing, and continous delivery; citation_inbook_title=IEEE Int. Conf. Cloud Comput. Emerg. Mark.; citation_publication_date=2015; citation_pages=85-89; citation_id=CR89; citation_author=M Soni"",""citation_journal_title=Br. Actuar. J.; citation_title=Wearables and the Internet of Things: considerations for the life and health insurance industry; citation_author=A Spender, C Bullen, L Altmann-Richer, J Cripps, R Duffy, C Falkous, M Farrell, T Horn, J Wigzell, W Yeap; citation_volume=24; citation_issue=22; citation_publication_date=2019; citation_pages=1-31; citation_id=CR90"",""citation_title=API-Design: Praxishandbuch für Java- und Webservice-Entwickler; citation_publication_date=2017; citation_id=CR91; citation_author=K Spichale; citation_publisher=dpunkt"",""Stein, B., Morrison, A.: The enterprise data lake: better integration and deeper analytics. PwC technology forecast: rethinking integration (2014).                    https://www.pwc.com/us/en/technology-forecast/2014/cloud-computing/assets/pdf/pwc-technology-forecast-data-lakes.pdf                                    . Accessed 5 Aug 2020"",""citation_title=Big data quality assessment model for unstructured data; citation_inbook_title=13th Int. Conf. Innov. Inf. Technol.; citation_publication_date=2018; citation_pages=69-74; citation_id=CR93; citation_author=I Taleb; citation_author=MA Serhani; citation_author=R Dssouli"",""citation_journal_title=Insur. Law J.; citation_title=Distributed ledger technology, blockchain and insurance: opportunities, risk, and challenges; citation_author=JA Tarr; citation_volume=29; citation_publication_date=2018; citation_pages=254-268; citation_id=CR94"",""citation_journal_title=Int. J. Inf. Manag.; citation_title=Big data reduction framework for value creation in sustainable enterprises; citation_author=MH Ur Rehman, V Chang, A Batool, TY Wah; citation_volume=36; citation_issue=6; citation_publication_date=2016; citation_pages=917-928; citation_id=CR95"",""citation_title=IT-Management im Zeitalter der Digitalisierung; citation_publication_date=2016; citation_id=CR96; citation_author=N Urbach; citation_author=F Ahlemann; citation_publisher=Springer"",""citation_journal_title=J. Insur. Inst. India; citation_title=Big data—Can it make a big impact in the insurance sector?; citation_author=S Venkatesh; citation_volume=VI; citation_issue=IV; citation_publication_date=2019; citation_pages=92-97; citation_id=CR97"",""Vesset, D.: Descriptive analytics 101: what happened? (2018).                    https://www.ibm.com/blogs/business-analytics/descriptive-analytics-101-what-happened/                                    . Accessed 25 Aug 2019"",""citation_title=Machine learning in data lake for combining data silos; citation_inbook_title=Int. Conf. Data Min. Big Data; citation_publication_date=2017; citation_pages=294-306; citation_id=CR99; citation_author=M Wibowo; citation_author=S Sarina; citation_author=MS Siti"",""citation_title=Smart Data Analytics: Zusammenhänge erkennen, Potenziale nutzen, Big Data verstehen; citation_publication_date=2017; citation_id=CR100; citation_author=A Wierse; citation_author=T Riedel; citation_publisher=De Gruyter"",""citation_journal_title=Int. J. Inf. Technol. Decis. Mak.; citation_title=A novel hybrid correlation measure for probablistic linguistic term sets and crisp numbers and its application in customer relationship management; citation_author=XF Zhang, ZS Xu, PJ Ren; citation_volume=18; citation_issue=2; citation_publication_date=2019; citation_pages=673-694; citation_id=CR101"",""Zies, I., Schmid, U.: Mehr Tempo, weniger Altlasten: IT-Architektur im digitalen Zeitalter (2016).                    https://www.bain.com/de/insights/more-speed-fewer-legacies-it-architecture-in-the-digital-age/                                    . Accessed 26 Jan 2020""
""citation_journal_title"",""Zeitschrift fĂźr die gesamte Versicherungswissenschaft""
""language"",""en""
""citation_cover_date"",""2020/12/01""
""og:description"",""The digital transformation is of increasing relevance for insurance companies’ business models. It leads to opportunities as well as challenges, especially for IT departments as core enablers or preventers. Against this background, the aim of this paper is to provide a comprehensive overview of digital technologies (e.g., artificial intelligence, cloud computing) and the resulting use cases for the insurance industry. To this end, we conduct a review of academic articles, industry studies and publications of the supervisory authorities. We point to the resulting requirements for an insurer’s IT and find many interdependencies between the digital technologies. Our results therefore emphasize the importance of a holistic digital strategy.""
""prism.issn"",""1865-9748""
""citation_author_email"",""katrin.osterrieder@fau.de""
""twitter:image:alt"",""Content cover image""
""prism.number"",""5""
""citation_issn"",""1865-9748""
""citation_language"",""en""
""dc:title"",""How digitalization affects insurance companies: overview and use cases of digital technologies | SpringerLink""
""Content-Encoding"",""UTF-8""
""citation_pdf_url"",""https://link.springer.com/content/pdf/10.1007/s12297-020-00475-9.pdf""
""citation_lastpage"",""360""
""DOI"",""10.1007/s12297-020-00475-9""
""citation_fulltext_world_readable"",""""
""citation_journal_abbrev"",""ZVersWiss""
""prism.rightsAgent"",""journalpermissions@springernature.com""
""citation_author"",""Christian Eckert"",""Katrin Osterrieder""
""resourceName"",""s12297-020-00475-9""
""dc.date"",""2020-10-01""
""citation_springer_api_url"",""http://api.springer.com/metadata/pam?q=doi:10.1007/s12297-020-00475-9&api_key=""
""citation_issue"",""5""
""prism.volume"",""109""
""prism.publicationName"",""Zeitschrift fĂźr die gesamte Versicherungswissenschaft""
""citation_doi"",""10.1007/s12297-020-00475-9""
""dc.title"",""How digitalization affects insurance companies: overview and use cases of digital technologies""
""prism.url"",""https://link.springer.com/article/10.1007/s12297-020-00475-9""
""citation_volume"",""109""
""dc.language"",""En""
""Content-Language"",""en""
""format-detection"",""telephone=no""
""citation_publication_date"",""2020/12""
""prism.endingPage"",""360""
""citation_title"",""How digitalization affects insurance companies: overview and use cases of digital technologies""
""citation_author_institution"",""School of Business, Economics and Society, Friedrich-Alexander University Erlangen-NĂźrnberg (FAU), Nuremberg, Germany"",""School of Business, Economics and Society, Friedrich-Alexander University Erlangen-NĂźrnberg (FAU), Nuremberg, Germany""
""access"",""Yes""
""citation_publisher"",""Springer Berlin Heidelberg""
""applicable-device"",""pc,mobile""
""dc.format"",""text/html""
""description"",""The digital transformation is of increasing relevance for insurance companies’ business models. It leads to opportunities as well as challenges, espe""
""title"",""How digitalization affects insurance companies: overview and use cases of digital technologies | SpringerLink""
""citation_online_date"",""2020/10/01""
""twitter:site"",""@SpringerLink""
""dc.source"",""Zeitschrift fĂźr die gesamte Versicherungswissenschaft 2020 109:5""
""dc.type"",""OriginalPaper""
""dc.copyright"",""2020 The Author(s)""
""dc.creator"",""Christian Eckert"",""Katrin Osterrieder""
""citation_fulltext_html_url"",""https://link.springer.com/article/10.1007/s12297-020-00475-9""
""prism.publicationDate"",""2020-10-01""
""Content-Type"",""text/html; charset=UTF-8""
""journal_id"",""12297""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""dc.description"",""The digital transformation is of increasing relevance for insurance companies’ business models. It leads to opportunities as well as challenges, especially for IT departments as core enablers or preventers. Against this background, the aim of this paper is to provide a comprehensive overview of digital technologies (e.g., artific";https://scholar.google.ch/scholar?start=880&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098760-92;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Generic authenticated key exchange in the quantum random oracle model;K Hövelmanns, E Kiltz, S Schäge, D Unruh ; … International Conference on …, 2020  Springer;;"… Quantum oracles and quantum Adversaries. Following [6, 14], we view a quantum oracle

\(|{\mathsf {O}} \rangle \) as a mapping $$\begin{aligned} |{x} \rangle |{y} \rangle \mapsto

|{x} \rangle |{y \oplus \mathsf {O}(x)} \rangle , \end{aligned} …";Cité 26 fois;;null;;;;https://scholar.google.ch/scholar?start=640&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098725-17;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;[PDF][PDF] Pradnya Patil, M. Sangeetha &;V Bhaskar ; researchgate.net;;"… Oracles are used as gateways which act as an interface between blockchain, service providers,

and remote clients. Multiple smart contracts are used which governs the interaction and right

to use the IoT data … Blockchain and trusted oracles are im plemented for decentralized …";;;[PDF] researchgate.net;https://www.researchgate.net/profile/Pradnya-Patil-7/publication/346542241_Blockchain_for_IoT_Access_Control_Security_and_Privacy_A_Review/links/5ff2a31e299bf140886c63fc/Blockchain-for-IoT-Access-Control-Security-and-Privacy-A-Review.pdf;;;https://scholar.google.ch/scholar?start=560&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098774-123;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;[PDF][PDF] Cryptocurrencies: a theoretical approach?;A Labancz ; EU Business Law and Digital Revolution  core.ac.uk;;"… a common concept in the practice, the term 'virtual currency' or 'crypto-asset'is … 2 AMLD5, the

directive related to cryptocurrency regulation, uses and defines the term'virtual … 9 2 J.

Glavanits–PB Király: A blockchain-technológia alkalmazásának jogi el?kérdései: a fogalmi keretek …";Autres articles;;[PDF] core.ac.uk;https://core.ac.uk/download/pdf/362658342.pdf#page=149;"
EU Business Law and Digital Revolution 
 





 

EU Business Law and 

Digital Revolution 
 
 

– Selected Studies from  

New Fields of Technology 
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

SzĂŠchenyi IstvĂĄn University 

DeĂĄk Ferenc Faculty of Law and Political Sciences 

Department of International and European Law 

2019 



 
  

© Zsolt Bujtár, Sonja Bunčić, Neera Chopra, Olena Demchenko,  

Judit Glavanits, Zsolt Halász, Balázs Horváthy, Andrea Ivanišević,  

GĂĄbor KertĂŠsz, PĂŠter BĂĄlint KirĂĄly, LĂĄszlĂł Knapp, Andrea Labancz,  

Alpar Loťonc, Måria T. Patakyovå, Istvån Pesti-Farkas, Laura Stănilă, 

ZoltĂĄn Szegedi; 2019 

 

Editors: 

Judit Glavanits 

BalĂĄzs HorvĂĄthy 

LĂĄszlĂł Knapp 

 

The manuscript has been reviewed by LĂĄszlĂł Milassin. 

 

ISBN 978-615-5837-64-7 (Print) 

ISBN 978-615-5837-65-4 (PDF) 

 

This book has been published within the research stream of  

“Jean Monnet Module on EU Business Law” (EUBLAW) funded by  

the Erasmus+ Programme of European Union. 

Győr, 2019 

 
 

Published by Széchenyi István University – 

Deák Ferenc Faculty of Law and Political Sciences – 

Department of International and European Law  

(H-9026 Győr, Áldozat u. 12.) 

Tel.:+36/96/503-478 

Fax: +36/96/503-472 

Web: nejt.sze.hu 



 

Content 

 

 

 

Content ................................................................................................. 5 

 

Foreword  .............................................................................................. 7 

 

I. Artificial Intelligence: legal implications  

 

      Knight Rider’s Brothers Coming Soon – What About Their Legal 

            Situation? .................................................................................... 11 

      (GĂĄbor KertĂŠsz) 

 

      Artificial Intelligence and Bid Rigging .......................................... 29 

      (MĂĄria T. PatakyovĂĄ) 

 

      Fear the Robots? – Attitudes from the Supply Chain .................. 43 

      (István Pesti-Farkas – Zoltán Szegedi) 

 

      AI Risk Assessment Tools: The Trojan Horse of the Criminal 

           Justice System .............................................................................. 51 

      (Laura Stănilă) 

 

II. Cryptocurrencies 

 

     Central Bank Issued Digital Currencies: is it a Solution or a 

           Problem? ...................................................................................... 71 

      (Zsolt BujtĂĄr) 

 

     Fluidity of Term of Cryptocurrency – A Challenge for Regulators  89 

      (Sonja Bunčić – Alpar Lošonc – Andrea Ivanišević) 

 

     Virtual Currencies – Legal Challenges........................................ 113 

      (Zsolt HalĂĄsz) 

 

 



6 
 

    The Classification of Virtual Currencies Related to Blockchains 133 

    (PĂŠter BĂĄlint KirĂĄly) 

 

     Cryptocurrencies: A Theoretical Approach ................................. 149 

    (Andrea Labancz) 

 

III. Business and digitalization 

 

     Adoption of ICT in Higher education: Readiness of University 

          Students in Rural India................................................................ 171 

    (Neera Chopra) 

 

     Electronic Commerce in Gaming Industry. European Perspective 

          on the Legal Regulations of In-game Virtual Transactions ......... 193 

    (Olena Demchenko) 

 

     Smart Cities, Iot and Blockchain: The Importance of Oracles  ... 209 

    (Judit Glavanits) 

 

     Autonomous Vehicles – Challenges for EU Private 

     International Law  ....................................................................... 233 

     (BalĂĄzs HorvĂĄthy) 

 

Annex – The Centre for European Studies (CES)  at the 

     SzĂŠchenyi IstvĂĄn University .............................................................. 255 

 

 

 



 

Foreword 
 

 

 

 

 

 

 

 

 

In 2017 the Centre for European Studies (CES) of Faculty of Law and 

Political Sciences of the SzĂŠchenyi IstvĂĄn University launched the 

conference series ‘EU Business Law Forum’ with the aim to establish a 

regular event, which reflects on topical issues of EU business law and 

explores the related contemporary challenges in their legal, political, 

economic and social reality.  

The 2nd EU Business Law Forum “EU Business Law through the lens 

of Digital Revolution” held between 13–14 June 2019, was devoted to 

discuss the implications of the current technological revolution on the 

business environment in the European Union, particularly on the EU 

business law regulation. The Forum identified the recent challenges that 

the EU business actors are facing as a result of the digitalization and 

posed the question, whether – analogically to the concept of ‘Industry 

4.0’ – a process of a ‘Law 4.0’ is expected to become tangible in the EU 

business law regulation, responding adequately the challenges arising 

from the new disruptive technologies.  

This book offers an insight into the main focus areas of the 

conference. The first chapter (I. Artificial Intelligence: legal implications) 

reflects on the growing importance of using artificial intelligence and the 

role of the legal regulation. The articles pose questions form general as 

well as specific perspectives and illustrates the legal problems of the 

artificial intelligence by varieties of topics, from the public procurements 

to the supply chains. The second chapter collects the papers that are 

focusing on the new instruments of exchange (II. Cryptocurrencies). The 

chapter lays down the conceptual basis of cryptocurrencies and 

examines the legal and regulatory challenges arising from the current 

use and the probable future prevalence of the virtual currencies. The 

third chapter of the book pays attention to emerging fields of regulations 



 

(III. Business and digitalization). The papers examine the adoption of 

technological innovations in higher education, e-commerce related 

aspects of computer games, legal challenges of smart contracts and 

autonomous vehicles.  

The Forum was a part of the ‘Jean Monnet Module on EU Business 

Law’ (EUBLAW) project funded by the European Commission’s Erasmus+ 

Programme in the Period of 2016 – 2019, and this year, the CES 

organized the event in cooperation with the SmartLaw Research Group. 

 

 

Editors 

Győr, December 2019 

 



 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

I. Artificial Intelligence: legal 

implications 
 

 

 

 





 

 

Knight Rider’s Brothers Coming Soon – What About Their 

Legal Situation?

 

 

 

GĂĄbor KertĂŠsz*  
 

 
Abstract: Nowadays, we are confronted more and more times with the issues of 

artificial intelligence and (partly or completely) self-driving vehicles. How does this 

technical development change our daily lives? What can ""Law"" do with these? In the 

analysis I am looking for the answer how these technical novelties can fit into the 

structure and logic of the legal system. During this process I use examples of history 

and legal history, other social sciences and modern business logic as well. 

 

 

Keywords: artificial Intelligence, self-driving cars, responsibility for damages  

 

1.  Introduction 

In the 1990s, television channels broadcasted the Knight Rider 

action film in a huge number of countries around the world, in which one 

of the main characters was a self-driving car. That time it existed only at 

the level of dreams and on the design tables of engineers, today it is 

reality in some parts of the world.  

1.1. A bit of „layman philosphy” 

Our long-standing expectation towards machines to work perfectly, 

flawlessly. In the contrary our recurring experience is that ""nothing is 

perfect"" ""what may go wrong will go wrong"" and we have to admit that a 

thing without any errors has never been made by a non-perfect person. 

From this point of view, we can ask how many % of the errors are 

accepted in practice naming the thing ""perfect"" or rather appropriate. 

The concept of damage appears already in the earliest legal systems. 

The concept clarified in the old Roman law is still perfectly applicable 

today, according to which the damage has two parts: the real damage 

 

 
* College professor, International Business School (Budapest). 



12 GĂĄbor KertĂŠsz 

 

(dannum emergens) and the loss of profit (lucrum cessans). Based on 

these, it is a question of argumentation to determine whose (active or 

passive) behavior caused the damage and who bears responsibility for 

the damage. It is usually a judicial procedural task not to allow the 

evidence procedure to sink into the infinite marsh of the principle of 

conditio sine qua non. 

2. Historical examples 

2.1. Legal instruments nowadays that come from legal history 

These legal instruments of responsibility have been created in the 

history of law during the technical development to solve the current 

problem. Man first tamed / domesticated animals that typically followed 

his instructions, but sometimes did not or not well executed the 

instruction and caused damage. The issue of liability for such damages 

caused by animals has been established long ago, and its structure has 

not changed since the first civilizations, and our act uses their logic still 

today.1 Also, since the earliest settled civilizations where built 

environment has been built, the question of damage caused by objects 

falling from buildings2 is known. Although the material and design of our 

buildings have undergone many changes over the past millennia, the 

handling of damages by objects falling from the buildings has not 

changed much over the past two thousand years. The next form of 

responsibility was developed due to another historical step that was the 

industrial revolution. The concept and liability of dangerous operations3 

is approached by the structure that was formed at that time, although 

nowadays many of these types of ""operations"" operate on a daily basis, 

and only the detailed rules for the new types are added to the centuries-

old structure. The last type of liability (although it can still be argued that 

this is not yet clear, but still in the process of being developed) is product 

liability4, where the link is created between the manufacturer and the 

 
1 Liability for the damages caused by animals Ptk. 6.:562-563. §. Here and 

thereafter, I refer to certain provisions of the Hungarian Civil Code (Ptk.), which has the 

same content in civil law in all the legal systems of the world. 
2 Liablity for building damages Ptk. 6.:560-561. §. 
3 Liability for dangerous operations Ptk. 6.:535-539. §. 
4 Product liability Ptk. 6.:550-559. §. 



Knight Rider’s Brothers Coming Soon – What About Their Legal Situation? 13 

 

end user of the product by omitting the intermediate elements of the 

causal chain.  

As a continental lawyer I looked for similar cases for autonomous, 

self-driving vehicles.  One of the “precedents” - using several multiple 

quotation marks - is the case of animal damages5. In this case an animal 

with independent autonomous animal intelligence causes damage and it 

is a partial question if the owner “led” the animal, or is made itself 

independent or uncontrollable. The other case that could be a 

“precedent” is the liability of the legal entity, where the legal person that 

caused the damage, will be liable for the damage and the legal entity will 

be obliged by the court to pay the compensation for the damage. 

With legal logic and expert arguments on a case-by-case basis, it is 

possible to determine in which proportion and percentage the potential 

responsible people (responsible groups) listed and analyzed above are 

responsible for the damage. The traditional market logic provides 

insurance as a solution to a potential threat, where we can atomize the 

actual damage between the members of the risk community. 

Another possible answer of business logic is to burden the damage to 

the one who caused it. Here the legal logic says today that to oblige a 

damage-causing truly self-driving vehicle to indemnify the damage, it 

should be a legal entity. Not going into the solutions of ancient - not 

Roman - and medieval rights that have passed the ownership of the 

damage-causing animal, or the harmed received temporary use on the 

animal, in case of self-driving cars the similar solution is possible, as it is 

a fact that the damage-causing thing has a value for use and it is able to 

produce it regularly. 

2.2. Philip IV. (the Fair) 

The next example is about a minor change made by the legislator 

that made a huge change in the historical perspective and that 

fundamentally influences national identity. Philip the Fair, king of France 

ordered in 1308 that in a case between non-barons, the court 

established at that time and permanently operating at the Royal Palace 

in Paris should make a final decision either in direct action or in appeal 

against a provincial judgment. This court used the local language around 

 
5 Ptk. 6:562.563. § 



14 GĂĄbor KertĂŠsz 

 

Paris and its code of conduct made it clear to accept only contracts and 

actions written in the language of the court6. From the early Middle Ages 

in today's France, the provinces with individual feudal autonomy spoke 

their own local language7. As a result of this law, in just a few decades, 

the language of the court became known as a written language in every 

corner of the Kingdom of France, which we now know as a French 

language, as it was in everyone's interest to write all the contracts in that 

language. Nowadays, French is an important element of French national 

identity. 

This is a good example of the fact that standardization of the rules for 

the use of certain elements of Artificial Intelligence (e.g. self-driving cars) 

will be significant for all members of society and will have a social 

organizing and forming effect in the long run. 

3. Who can be liable if Knight Rider makes an accident? 

Let us shortly list the different human beings who have any 

connection with Knight Rider’s birth. 

3.1. Possible liable people 

3.1.1. Driver 

This is the only member of the coming list, where - according to the 

current Hungarian legal environment - only one natural person can be a 

subject. Until now, the liability of the driver was an evidence in the case 

of damages caused by man-, animal- or machine powered vehicles. 

Nowadays there are vehicles that are not driven by humans, but are 

driven by the intelligent / autonomous vehicle itself in self-driving, 

however in the Union they drive only on test fields, not in real traffic. 

After a broad social debate involving the whole human civilization, it can 

be agreed if the natural people in self-driving vehicles should, and if so 

at what level, control the proper / accident-free operation of the vehicle. 

Currently, although we have already met a few legal cases, where the 

 
6 PĂĄl HorvĂĄth, IstvĂĄn KajtĂĄr, LĂĄszlĂłnĂŠ Nagy, T. MihĂĄly RĂŠvĂŠsz, IstvĂĄn Stipta and 

Jånos Zlinszky, Általånos jogtÜrtÊnet I. (Nemzeti TankÜnyvkiadó 1994) 64. 
7 This was the language of the certain Gaul tribe from which the people of the 

province originate. 



Knight Rider’s Brothers Coming Soon – What About Their Legal Situation? 15 

 

responsibility of the driver has been established on the basis of 

traditional logic, neither the public opinion nor the legislator has 

conducted this increasingly necessary debate yet. If the decision is 

made, it can be translated then into a known form of liability. According 

to the current Hungarian rules, if the vehicle is in motion, one person 

must be in the driving position continuously8. The Hungarian practice 

has not yet faced a case when the vehicle was self-driven with an empty 

driver seat causing an accident / damage. However, with the 

development of technology the question has to be answered soon 

whether the person who switches the vehicle into self-driving mode is a 

driver according to the Road Traffic Code? Does this person stay a driver 

after leaving the vehicle, which continues the way in self-driving mode? 

With traditional legal deduction the question can be replied in a 

conventional way. In this case, the question is modified to the following: 

does it worth to invest in the development / acquisition of such a 

vehicle, if my responsibility for a self-driving vehicle is the same as if I 

were actually driving it? Or how worthy it is for me if I have possibility to 

do other activity(s) besides controlling the vehicle during sitting in the 

driver's seat? 

3.1.2. Owner 

The Road Traffic Code basically lays down rules for the traffic 

participants: the driver and the passenger, and the owner appears only 

once in the text9, but in the meantime the owner is recorded separately 

in the traffic license. We have been treating it for thousands of years as 

an evidence that the owner is responsible for the damage caused by his 

property.10 It is important to recall here for a moment the analogy that 

the tutelary is responsible for the damage caused by the unpunishable 

person.11 

 

 

 

 
8 Road Traffic Code (KRESZ) 4. §. 
9 Road Traffic Code (KRESZ) 59. § (3) subpar. 
10 See e.g. footnote no 2, 3, 4. 
11 Liability for damages caused by unpunishable person Ptk. 6:544-547. §. 



16 GĂĄbor KertĂŠsz 

 

3.1.3. Retailer, Wholesaler, Importer 

At this point, we arrived at to the actors of the sales chain, calling the 

person12 - in practice typically a legal person - a retailer who sold the 

vehicle to the owner; the other players are working on the basis of 

traditional trade contracts, their responsibilities are governed by the 

contracts, the relevant customs and the practice of the judiciary and 

arbitration court. 

3.1.4. Tester team 

Here, on the one hand, it is the task and responsibility of the team to 

perform all the necessary tests thoroughly and professionally and on the 

other hand to ensure that all relevant tests are performed. Although this 

team typically consists of engineers, they have to keep in mind that they 

have to test the vehicle in every theoretically possible situation and 

check how it behaves in each case. It is often told about us as lawyers 

that we are writing novel-length contracts as 'graphomans' in which we 

try to get prepared for every single theoretically imaginable risk factor. 

The test team has a similar task to examine how the vehicle responds in 

a self-driven mode to the variety of all theoretically possible situations. 

For the test team only the collective responsibility can be imagined, 

since the outstanding and indispensable contribution of a team member 

is theoretically conceivable, but apart from such extreme situations, the 

contribution of all members of the team is equally important for the 

proper performance of the test and the evaluation of the result. Although 

they are not members of the testing team, but the decision-makers of 

the enterprise also have a responsibility here, as the management 

decides based on the results of the tests, with engineer, lawyer and 

economist support if the vehicle is ready to be put on the market / in 

traffic or further development is needed. 

3.1.5. Software-developer team 

This team develops the software (system) that ensures the vehicle's 

self-driving ability. Nowadays, developers generally “teach” the systems 

 
12 I examine only the sales of new vehicles. The sales of used vehicles is out of 

scope of the examination. 



Knight Rider’s Brothers Coming Soon – What About Their Legal Situation? 17 

 

in a way that it faces decision-making situations continuously, and it 

achieves a better percentage of success due to this “learning”. The 

other, nowadays in minority applied solution is to program the ""right / 

good / desirable"" solution and the system has to avoid the rest. The 

responsibility of the developers is unavoidable for both methods. In the 

first method the responsibility originates in the examples that were the 

base for teaching the system. It can happen that even though the 

sample consists of a large number of elements, there can be cases that 

are out of the model and the machine will not recognize them and it will 

not be able to handle them well. In the second method, the more 

detailed description of the good solution is important, so that the 

machine can handle the situation that actually arises, even if it is new, 

but similar to a learned rule. At this point, the question of the need for 

ethics arises. If in a given situation only bad decisions can be made and 

non-decision is also a bad decision, which wrong decision should be 

made by the Artificial Intelligence that was taught and built in the 

system? 

A comprehensive research project was launched in 2016 with 40 

million people worldwide, related to the artificial intelligence-driven cars 

being developed nowadays. Researchers were looking for an answer to 

what people say: if there is no way to avoid an accident, who should hit 

the car? The answers outline a world-wide view of what we are protecting 

more and what less. The results of the research have been published 

only half a year ago13. The article first states that it cannot be considered 

worldwide statistically representative because of the limited possibilities 

of sampling, but the data collected show that children are more likely to 

be saved than adults, but this is only a global average statistical result, 

because the range of bad decisions differ from country to country and 

even more from culture to culture. The results of the world average are 

not the same as the results of the regions and metropolises that are the 

most multicultural according to sociologists. So according to the data, 

people in different cultures of the world set different order of 

importance, or approach the question from the other side, a different 

order is set in the list of other people and objects to be sacrificed. So, if 

 
13 Edmond Awad, Sohan Dsouza, Richard Kim, Jonathan Schulz, Joseph Henrich, 

Azim Shariff, Jean-François Bonnefon and Iyad Rahwan, ’The Moral Machine 

experiment’ (Nature, 24 October 2018). 



18 GĂĄbor KertĂŠsz 

 

there are such significant sequencing differences in case of people from 

different parts or different cultures of the world, in which order to protect 

the different values in an emergency, then Artificial Intelligence will also 

not be able to decide according to a generally accepted sequence, 

although such situations relatively  often occur during traffic. 

In this case, the question arises which culture’s prioritization will be 

the base for the self-driving vehicles choice, i.e. which sequence was 

programmed/taught by the programming team. Here, group dynamics 

and hierarchical relationships within the group as well within the 

organization can also influence the sequence they teach, along with the 

cultural patterns of the team members and other individuals involved. 

I.e. if the development team is culturally homogeneous and whether the 

final decision-making management has the same, homogeneous cultural 

background. For most of these companies, we cannot say yes to this 

question with a calm heart. This results in the following: there is a 

significant likelihood that the sequence of priority will be determined 

differently by not only the vehicle types produced by the different 

manufacturers, but also by the same brand and type of self-driving cars, 

if they are produced in different plants of the world far away from each 

other, if Artificial Intelligence is made independently in the plant, rather 

than installing a centrally-produced system in vehicles manufactured in 

all factories around the world. The issue is about the choice of victim14 in 

an inevitable situation of a self-driven vehicle programmed under the 

rules of other cultures. In my opinion this issue can be settled 

satisfactorily through an agreement resulting from a consultancy with 

the presence of the whole world, or if the producers mutate the vehicles 

into the different cultural regions where they are sold. It is not primarily a 

business law issue, but a fundamental rights issue if it is allowed to the 

owner/driver to download versions of other cultures; either because he 

disagrees with the culture of his place of residence and feels another his 

own, or because he is planning to go to the territory of this culture - 

though the latter can be automatically solved by the service that if the 

vehicle crosses the ""cultural boundary"" according to its GPS coordinates, 

the system downloads the version that is valid in that area. 

 
14  E.g. the choices were different when the vehicle hits the old person or the child 

in order to save the other one – see same as footnote no 13. 



Knight Rider’s Brothers Coming Soon – What About Their Legal Situation? 19 

 

3.1.6. Planner team 

This is a team consisting of mostly engineers who design the 

""hardware"" of the vehicle. In addition to the fault possibilities of 

conventional vehicle design, only one new risk factor appears here. It is 

a well-known experience in conventional vehicle driving that there are 

""dead spaces"" in case of all vehicles depending on the vehicle’s size, 

which are not visible to the driver. Their magnitude cannot be completely 

removed, only reduced with the rear-view mirror system. In case of self-

driving vehicles, however, the expectation is that the machine should 

see everything in real time, simultaneously and drive itself accordingly. 

That's why the design team here, beyond the usual design 

responsibilities of traditional vehicle design, has to meet „only” one new 

requirement. On the vehicle the environment sensors must be 

positioned so that they can continuously see all objects in real time 

within the current speed braking distance that would presents a risk of 

accident in case of going without change. (Of course, the danger of a 

new object that might come out of the cover of another object is 

excluded here.) If the design really reduced the size of ""dead spaces"" for 

self-guiding sensors to 0%, the design team does not have any more 

responsibilities than the ones coming from traditional design 

responsibilities. The current traffic situation was detected by the sensors 

that transmitted it to the software, which made the decision in self-

driving mode, which is the result of the work of the development team15. 

3.1.7. Controller team 

Modern states usually have a body that controls various activities 

carried out by economic actors. The depth of control that this body 

performs varies from body to body and from country to country. If a 

causal link can be established between the authorization procedure of 

the authority and the damage caused, the determination of damage 

caused by administrative law may arise if it was not possible to avert the 

damage by ordinary legal remedy or in administrative juridical action16. 

The theoretical possibility of this in the examined issue arises only if 

 
15 See footnotes no 13 and 14. 
16 Ptk. 6: 548. §. 



20 GĂĄbor KertĂŠsz 

 

such an error originating in the type of the self-driving vehicle, which has 

not been recognized either by the licensing authority or the 

manufacturer's designer, software developer and test team previously. 

3.1.8. Legislator  

Legal acts created by the legislator are applied by legal entities and 

by the executive and judiciary branches. And it is a century-old, if not a 

millennium-old fact, for which we can find more and more examples 

nowadays that it is possible to legislate only such situations that already 

occurred, or they could be predicted with significant possibility. The new 

life situations that have arisen after the legislation have typically 

appeared as a legal loophole in continental law systems, and in the 

Anglo-Saxon systems precedents are sought. From a legal point of view, 

the “legislator's silence” - if no law was created on the certain situation - 

cannot be interpreted as a damaging fault. However, economic actors 

can perceive it as a damaging fault according to the logic of the 

economy, of the business and if the market. The question that arises 

here is whether the legislator has created the legal system so that it is 

able to deal with the problem of damage caused by a self-driving vehicle, 

and whether this solution is appropriate for society (for voters?). 

3.2. How can Knight Rider be liable? 

According to the basic division in law, there are legal subjects and 

legal objects. There are no third and temporary categories. We neglect to 

discuss the historical development of the general, unconditional and 

equal legal subject people have. We only mention the last step in the 

development of legal entities, the second group of legal subjects known 

today: ""The legal personality of a legal person extends to all rights and 

obligations that, by their very nature, may not only be related to a human 

being""17, i.e. the legal personality of the legal person is not bound to a 

purpose, but it is general. It is not a matter of jurisdiction, but a matter of 

legislation which listed actors and in which extent are made liable for the 

damages caused by the self-driving vehicle. It is already the task of 

 
17 Ptk. 3:1. § (2) subpar. 



Knight Rider’s Brothers Coming Soon – What About Their Legal Situation? 21 

 

political science to examine political programs, political marketing, and 

legal lobbying of the interested companies. 

Taking the two premises into consideration that the self-driving 

vehicle is capable of making autonomous decisions - respecting the 

rules of social cohabitation - and is capable to generate financial value 

continuously, the business logic raises the question in a right way why 

this vehicle cannot be an actor in business life on its own? As besides 

people - nowadays mainly in the international business community, 

instead of people – it is worldwide an accepted evidence by everyone 

and everywhere that ”legal constructions” named legal entities have 

legal subject, independent from the fact that no one has seen a legal 

entity, only a person representing it, its logo, or its headquarters. 

However, the self-driving vehicle is a tangible physical reality. 

Since the concept of a legal person appeared in legal history till the 

present, there is clear evidence that non-human private entities 

ultimately have a human owner. Nowadays, a new concept has emerged 

on the periphery of the legal subjects, which is the ""actual beneficial 

owner"" who increases its assets with the values produced by the 

examined legal entity, or has the right to dispose of these assets either 

directly or through mandatory instructions given to the participants in the 

chain18. Not going into details in the psychological, corporate, and social 

sociological question of what group dynamics each company (regardless 

of its legal form) has; we can say that the purpose of the company (the 

legal entity in question) is to live / operate further. As an analogy to this 

approach, we can assume that the autonomous, self-driving vehicles are 

also aimed for further operation; however, this hypothesis gives the 

software development, testing, and control teams an important task. The 

mentioned research looked for a reply about who the vehicle would 

rather hit19. For a human driver, it is an existing option, for which there 

are some famous examples, that the person sacrifices his own life, and 

with this, saving many. With the sensors of the vehicle's seats, on the 

base of the weight of each passenger, the vehicle “knows”20 how many 

 
18 About the concepts „beneficial owner” and „actual beneficial owner” see the 

different conventions about avoiding double taxation and 7. point of 7. App of the 

Hungarian citizens income tax act. 
19 Awad et al. (n 13) 
20 Not going into details about the results of Awad et. al. (n 13), according to which 

the general cultural reply to this in Europe is that the driver puts suitcases on each seat 

 



22 GĂĄbor KertĂŠsz 

 

adults and how many children are traveling in it, and even through the 

impleme";"""date"",""2020-12-07T10:39:34Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""EUBLAW-WP""
""xmp:CreatorTool"",""MicrosoftÂŽ Word 2010""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dc:creator"",""Iroda""
""language"",""en""
""dcterms:created"",""2020-12-07T10:39:34Z""
""Last-Modified"",""2020-12-07T10:39:34Z""
""dcterms:modified"",""2020-12-07T10:39:34Z""
""dc:format"",""application/pdf; version=1.5""
""title"",""EUBLAW-WP""
""Last-Save-Date"",""2020-12-07T10:39:34Z""
""pdf:docinfo:creator_tool"",""MicrosoftÂŽ Word 2010""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2020-12-07T10:39:34Z""
""meta:save-date"",""2020-12-07T10:39:34Z""
""pdf:encrypted"",""false""
""dc:title"",""EUBLAW-WP""
""modified"",""2020-12-07T10:39:34Z""
""Content-Length"",""2226858""
""pdf:hasMarkedContent"",""true""
""Content-Type"",""application/pdf""
""pdf:docinfo:creator"",""Iroda""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Iroda""
""dc:language"",""hu-HU""
""meta:author"",""Iroda""
""meta:creation-date"",""2020-12-07T10:39:34Z""
""created"",""2020-12-07T10:39:34Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""258""
""Creation-Date"",""2020-12-07T10:39:34Z""
""resourceName"",""362658342.pdf""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""40"",""0"",""240"",""865"",""1381"",""1031"",""1925"",""520"",""67"",""0"",""1736"",""2347"",""2321"",""2110"",""2073"",""2138"",""2625"",""2588"",""2256"",""2183"",""2704"",""2471"",""2659"",""2363"",""2602"",""2091"",""968"",""0"",""2169"",""2280"",""2653"",""2383"",""2542"",""2136"",""2590"",""2306"",""2311"",""2238"",""2312"",""1798"",""1790"",""676"",""1831"",""1382"",""776"",""2506"",""2587"",""2459"",""1728"",""0"",""2200"",""2483"",""2247"",""2469"",""2655"",""2168"",""2411"",""2657"",""2414"",""2244"",""2518"",""2287"",""2703"",""1928"",""2007"",""1949"",""1810"",""0"",""42"",""0"",""1883"",""2347"",""2910"",""2888"",""2727"",""2656"",""1069"",""2579"",""2452"",""2700"",""2408"",""2526"",""2580"",""2486"",""2195"",""1892"",""1829"",""0"",""2535"",""2609"",""2579"",""2502"",""2474"",""2544"",""2614"",""2744"",""2333"",""2217"",""2298"",""2522"",""2425"",""2298"",""2392"",""2385"",""2324"",""2425"",""2147"",""2499"",""2086"",""1840"",""1973"",""484"",""1924"",""2346"",""2454"",""2432"",""2190"",""2515"",""2335"",""2601"",""2434"",""2341"",""2238"",""2606"",""2535"",""2472"",""2624"",""2385"",""2792"",""2262"",""1781"",""1037"",""1913"",""2410"",""2496"",""2333"",""2235"",""2632"",""2394"",""2538"",""2645"",""2558"",""2287"",""2324"",""1766"",""1963"",""1853"",""634"",""2016"",""2355"",""2581"",""2717"",""2226"",""2225"",""2747"",""2395"",""2490"",""2376"",""2265"",""2203"",""2254"",""2258"",""2506"",""1992"",""1823"",""1829"",""1202"",""0"",""53"",""0"",""2270"",""2645"",""2699"",""2376"",""2655"",""2255"",""1454"",""2186"",""2544"",""1573"",""1965"",""1561"",""1682"",""581"",""1298"",""1362"",""2069"",""1962"",""2248"",""1677"",""392"",""0"",""2036"",""2380"",""1999"",""2294"",""2339"",""1840"",""2364"",""2298"",""2155"",""2099"",""2418"",""1985"",""1863"",""1841"",""1022"",""0"",""1848"",""2262"",""1060"",""2503"",""2657"",""2575"",""905"",""632"",""2493"",""2335"",""2272"",""2282"",""1317"",""1844"",""817"",""2285"",""2701"",""2388"",""2125"",""2181"",""1996"",""2040"",""1918"",""1629"",""2257"",""2690"",""3383"",""2858"",""2732"",""2340"",""2647"",""2216"",""2699"",""2557"",""2280"",""2671"",""2875"",""3011"",""2558"",""2234"",""2266"",""2486"",""2184"",""2035"",""1968"",""1441"",""1697"",""1864"",""2598"",""691""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""Author"",""Iroda""
""producer"",""MicrosoftÂŽ Word 2010""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""MicrosoftÂŽ Word 2010""
""pdf:docinfo:created"",""2020-12-07T10:39:34Z""
";https://scholar.google.ch/scholar?start=670&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098861-326;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Análisis de las obligaciones condicionales en la implementación de Smart Contracts en el ordenamiento jurídico colombiano;D Luque Restrepo ;2020 repository.upb.edu.co;;"… Finalmente se dará al lector una aproximación a lo que son los oráculos en el ecosistema de

Blockchain y cómo estas entidades ayudan a facilitar las transacciones … Palabras clave Blockchain,

Smart Contracts, contratos, obligaciones condicionales, derecho civil. Page 4 …";Autres articles;Version HTML;[PDF] upb.edu.co;https://repository.upb.edu.co/bitstream/handle/20.500.11912/6157/An%C3%A1lisis%20de%20las%20obligaciones%20condicionales%20en%20la%20implementaci%C3%B3n%20de%20Smart%20Contracts.pdf?sequence=1;"
 

AnĂĄlisis de las obligaciones condicionales en la implementaciĂłn de Smart Contracts en el 

ordenamiento jurĂ­dico colombiano. 

 

 

 

 

 

 

Daniel Luque Restrepo 

 

 

 

 

 

 

 

 

Universidad Pontificia Bolivariana 

Escuela de Derecho y Ciencias PolĂ­ticas 

Facultad de Derecho 

MedellĂ­n 

2020 

 



 

AnĂĄlisis de las obligaciones condicionales en la implementaciĂłn de Smart Contracts en el 

ordenamiento jurĂ­dico colombiano. 

 

 

 

 

 

 

Daniel Luque Restrepo 

 

Trabajo de grado para optar al tĂ­tulo de abogado 

 

Asesor 

NĂŠstor RaĂşl LondoĂąo SepĂşlveda 

Doctor en Derecho 

 

 

Universidad Pontificia Bolivariana 

Escuela de Derecho y Ciencias PolĂ­ticas 

Facultad de Derecho 

MedellĂ­n 

2020 

 



Resumen 

Este artículo aborda el fenómeno de los denominados “Smart Contracts” o contratos inteligentes 

desde un punto de vista tĂŠcnico informĂĄtico y desde la teorĂ­a del negocio jurĂ­dico con miras a aclarar 

algunas nociones y consecuencias jurĂ­dicas que se tienen sobre estos programas informĂĄticos. 

Especialmente, el artĂ­culo se centra en aquellos contratos que contienen obligaciones sometidas a 

condiciĂłn y cĂłmo se evalĂşa el cumplimiento de dicha condiciĂłn tanto en los contratos tradicionales 

como en los contratos inteligentes. Finalmente se darĂĄ al lector una aproximaciĂłn a lo que son los 

orĂĄculos en el ecosistema de Blockchain y cĂłmo estas entidades ayudan a facilitar las transacciones 

y los negocios en esta plataforma. 

 

Palabras clave 

Blockchain, Smart Contracts, contratos, obligaciones condicionales, derecho civil. 

 

  



IntroducciĂłn 

En la actualidad la mayorĂ­a de las empresas en el mundo se han interesado por las llamadas 

tecnologĂ­as de la cuarta revoluciĂłn industrial o revoluciĂłn digital, entre las que se suelen incluir el 

internet de las cosas (IoT), la Inteligencia Artificial y la tecnologĂ­a Blockchain. La importancia del 

fenĂłmeno estudiado surgiĂł por la amplia difusiĂłn que hay en la opiniĂłn pĂşblica sobre las posibilidades 

y oportunidades que trae esta novedosa tecnologĂ­a tanto en el mundo informĂĄtico como en el 

jurĂ­dico y por la gran desconexiĂłn conceptual y epistemolĂłgica que existe entre el Derecho y la 

transformaciĂłn InformĂĄtica en todas las economĂ­as del mundo.  Los abogados y despachos jurĂ­dicos 

han puesto sus ojos en la tecnologĂ­a Blockchain por sus ventajas de seguridad y transparencia en 

transacciones de valores y por su promesa de programar contratos inteligentes o autoejecutables, 

es por ello por lo que el Derecho debe acompaĂąarla y ampliarla, facilitando regulaciones para el uso 

de estas herramientas al servicio de la sociedad. 

Lo que se pretende con este artĂ­culo, es destacar que, con el Blockchain y los contratos 

inteligentes, se busca innovar en Derecho, y que se pueden prestar servicios legales mĂĄs seguros y 

eficientes, para revolucionar industrias enteras y asĂ­ combatir la corrupciĂłn pĂşblica y privada, por 

medio de una transparencia valiosĂ­sima desde la tecnologĂ­a de la informaciĂłn. En particular, el 

ejercicio al que invita este artĂ­culo es a analizar la composiciĂłn lĂłgica de estos contratos inteligentes 

para contrastarlos con los contratos tradicionales.  No se pretende hacer un anĂĄlisis exhaustivo, 

pues es un tema que no ha comenzado a regularse en nuestro ordenamiento, y se debe anotar que, 

al no contar con un cuerpo legal robusto y asentado ni una jurisprudencia detallada que aclare 

conceptos propios y conexos sobre los contratos inteligentes, este escrito no aspira a ser mĂĄs que 

una nociĂłn sobre un aspecto concreto del tema de los contratos inteligentes y es el del anĂĄlisis de 

las condiciones en las obligaciones sometidas a condiciĂłn. Muchas preguntas quedarĂĄn abiertas y se 

invita a los lectores de este artĂ­culo que se profundice en esta nueva rama del Derecho. 



Para abordar este tema, en primer lugar, se harĂĄ una aproximaciĂłn conceptual tĂŠcnico - 

informĂĄtica sobre los Smart Contracts, cumpliendo con el alcance de este trabajo, Luego observarĂĄ 

cuidadosamente el ordenamiento jurĂ­dico para suplir los vacĂ­os, debido a que legalmente no existe 

regulaciĂłn nacional concreta sobre el tema objeto de estudio. En segundo lugar, se traerĂĄ a colaciĂłn 

la teorĂ­a de las obligaciones civiles, especĂ­ficamente las obligaciones condicionales en el CĂłdigo Civil 

y parte de la doctrina colombiana para exponer un paralelo entre Smart Contract o contrato 

inteligente y el contrato tradicional entendido como acuerdo de voluntades para producir efectos 

jurĂ­dicos. En tercer lugar, se explicarĂĄ el proceso de implementaciĂłn de las condiciones 

informĂĄticamente y la funciĂłn que cumplen los orĂĄculos en dicho proceso. 

Finalmente se arrojarĂĄn las conclusiones pertinentes sobre el tema, que no son definitivas 

ni definitorias y que dejan mĂĄs preguntas que respuestas, pues este tema queda abierto a muchas 

investigaciones posteriores. 

 

 

 

  



ÂżQuĂŠ son los Smart Contracts? 

 

Concepto informĂĄtico. 

Un contrato inteligente es un programa informĂĄtico que es programado y posteriormente 

instalado sobre una plataforma informática especial consistente en una red de pares llamada “cadena 

de bloques” o Blockchain y que puede recibir o transferir criptoactivos a cuentas de usuarios 

siguiendo reglas estipuladas por su desarrollador. Estos programas siguen determinadas 

instrucciones, las mĂĄs relevantes son aquellas que regulan el almacenamiento de informaciĂłn y la 

transferencia de criptoactivos1 entre cuentas. 

SegĂşn lo seĂąalado en el pĂĄrrafo anterior, el Smart Contract tiene las siguiente caracterĂ­sticas: 

i) es un programa de computador, es decir, es un conjunto de instrucciones que obedece a reglas 

lĂłgicas, especializado en la transferencia de informaciĂłn y de criptoactivos; ii) es instalado y 

ejecutado en una plataforma electrĂłnica especial denominada cadena de bloques o Blockchain, la 

cual tiene ciertas particularidades que delimitan el alcance de las aplicaciones que se pueden 

desarrollar en este entorno2 y iii) que es programado por un desarrollador, es decir, una persona 

natural que introduce las instrucciones o reglas que el programa va a ejecutar. 

Para entender a cabalidad los Smart Contracts y su funcionamiento, se debe tener 

conocimiento, no solo de su definiciĂłn, sino tambiĂŠn aquellas circunstancias que dieron origen a este 

fenĂłmeno tecnolĂłgico. En principio, el problema del doble gasto implicĂł un gran lĂ­mite para crear 

sistemas de pagos y de transacciones digitales eficientes durante mucho tiempo. DespuĂŠs de la 

creaciĂłn de este sistema se evidenciĂł que al tenerse un archivo que almacena una cantidad de 

 
1 Criptoactivo es un medio digital de intercambio que utiliza criptografĂ­a fuerte para asegurar las transacciones, 

controlar la creaciĂłn de unidades adicionales y verificar la transferencia de activos usando tecnologĂ­as de 

registro distribuido (Shueffel, Groeneweg, & Baldegger, 2019, p. 11). Un ejemplo de un criptoactivo es un 

bitcoin o cualquier otra criptomoneda individualmente considerada. 

 
2 En informĂĄtica, el entorno de desarrollo delimita las funciones del programa. Por ejemplo, los programas en 

un Smartphone dependen si el dispositivo cuenta con cĂĄmara delantera y trasera. Si ese es el caso, se podrĂĄn 

escribir programas de captura de fotos con filtros. De caso contrario no serĂ­a posible. Lo mismo sucede para 

computadores, smartwatch, sistemas embebidos, autos inteligentes, dispositivos IoT, etc. 



“dinero” asociado a un usuario para transferir de una cuenta a otra, no había ninguna forma definitiva 

y segura de constatar que ese archivo hubiera sido leĂ­do o transferido una y solamente una vez entre 

las dos cuentas, lo que posibilitaba fraudes y corrupciĂłn en este sistema.  

Para solucionar esto, en el comercio electrĂłnico tradicional se ha hecho necesaria la 

intervenciĂłn de uno o varios terceros intermediarios que suelen ser bancos o entidades financieras 

encargados de constatar la veracidad y seguridad de la transacciĂłn. Lo que ayudarĂ­a a comprobar 

que el usuario A enviĂł el dinero al usuario B una y sĂłlo una vez al usuario B, constatando que 

correlativamente el mismo valor desaparece de la cuenta del usuario A y aparece en la cuenta del 

usuario B. 

Un ejemplo de lo seĂąalado en el pĂĄrrafo anterior es que, cuando el usuario A tiene en su 

monedero digital la cantidad de 100 monedas y le paga al usuario B 80 monedas, se necesita de un 

tercero que verifique que el usuario A efectivamente tiene las 100 monedas; que la direcciĂłn del 

usuario B es la direcciĂłn que aparece en la transferencia del usuario A; que en la cuenta del usuario 

A desaparecen 80 monedas e instantĂĄneamente aparecen en la cuenta del usuario B. De lo contrario, 

la persona podrĂ­a pagar el mismo valor dos veces, por ello, durante muchos aĂąos se tuvo que hacer 

uso de estos intermediarios lo que generaba sobrecostos en la transacciĂłn, comisiones, vulneraciĂłn 

de la privacidad de cada usuario, entre otros. 

Para resolver este problema, fue publicado un White Paper titulado “Bitcoin: a peer-to-peer 

electronic cash system” (Nakamoto, 2009, p. 1), distribuido en una lista de correos en el que se 

explica cĂłmo se podrĂ­a solucionar este problema mediante un sistema de pagos basado en 

criptografĂ­a y redes de pares junto con otros algoritmos.  

El sistema que describe Nakamoto, consiste en una base de datos descentralizada, es decir, 

una estructura o forma de organizar datos, que funciona como un libro de registro de transacciones, 

que es replicado en cada computador (dentro de una red de computadores, a cada computador 



conectado tambiĂŠn se le conoce como nodo3) que hace parte de una red de pares entrelazados y 

comunicados entre sĂ­. Es decir, es una tabla de datos en la cual el usuario tiene una copia entera en 

su computador y en la que no se le permite hacer modificaciones sin la autorizaciĂłn de todos los 

demĂĄs usuarios o nodos4 al mismo tiempo. En la base de datos se indican las direcciones fĂ­sicas y 

virtuales5 de cada nodo y la fecha y el monto de la transacciĂłn. Cada nodo tiene una copia completa 

de la base de datos y tiene a su vez referencias a los otros bloques con funciones hash6 seguras, de 

tal suerte que, si se cambia un registro, debe tener un consenso de toda la cadena para cambiarlo 

para que no se pueda modificar la transacciĂłn sin antes ser verificada por todos los nodos o 

eslabones de la cadena; este sistema permitiĂł la creaciĂłn de la primera criptomoneda, conocida 

como Bitcoin. 

Con el documento de Nakamoto, se dio acceso al pĂşblico general de internet a la posibilidad 

de cualquier persona de crear en su propia casa una tecnologĂ­a avanzada que permite desde la 

matemĂĄtica y la encriptaciĂłn, la creaciĂłn de un sistema de transferencia de criptoactivos, 

criptomonedas e intercambio de informaciĂłn altamente seguro. 

El tĂŠrmino de contrato inteligente apareciĂł por primera vez en los aĂąos noventa de mano 

del genial jurista e informĂĄtico Nick Szabo haciendo referencia a un contrato, el cual, a diferencia de 

su contraparte en papel, se vale de medios de hardware y software para automatizar y garantizar su 

ejecuciĂłn, evitando actos vandĂĄlicos y protegiendo la transacciĂłn de tal manera que resulte mĂĄs 

 
3 En informĂĄtica y en telecomunicaciĂłn, de forma muy general, un nodo es un punto de intersecciĂłn, conexiĂłn 

o uniĂłn de varios elementos que confluyen en el mismo lugar. En este caso se refiere a un punto o extremo de 

la red. 
4 En este contexto, un nodo es una instancia, particularizaciĂłn o realizaciĂłn especĂ­fica de la base de datos 

mencionada. La cual puede estar almacenada en un computador. 
5 Una direcciĂłn fĂ­sica o virtual hace referencia a un cĂłdigo que referencia a un Ă­ndice el cual se corresponde a 

un determinado lugar o espacio en la memoria. Un ejemplo de la memoria a que se hace referencia en este 

contexto es la memoria de acceso aleatorio o Random Access Memory (RAM), la cual es una memoria de trabajo 

en donde se almacena temporalmente informaciĂłn que va a ser luego procesada por las instrucciones del 

procesador. 
6 Las funciones hash son funciones informĂĄticas utilizadas en criptografĂ­a las cuales admiten como valor de 

entrada una pieza de texto y produce como valor de salida unos caracteres aleatorios. Esta tĂŠcnica es utilizada 

comĂşnmente para asignar valores Ăşnicos a entidades y para guardar informaciĂłn. Por ejemplo, es la manera en 

que se encriptan las contraseĂąas para almacenar en sitios web, o es usada para generar cĂłdigos de identificaciĂłn 

Ăşnicos. 



costoso intentar romper el sistema que obtener el valor que este guarda, como por ejemplo, una 

mĂĄquina expendedora de gaseosas (Szabo, 1996, pp. 1-11). Sin embargo, en la actualidad ha cobrado 

especial relevancia el uso que se le ha dado al tĂŠrmino en el contexto de la tecnologĂ­a Blockchain, 

especĂ­ficamente sobre la plataforma Ethereum (Ethereum Organization, 2020). 

Bajo las especificaciones descritas por Nakamoto en su documento, el informĂĄtico Vitalik 

Buterin creĂł su propia cadena de bloques y encima de la misma creĂł una envoltura llamada la 

MĂĄquina Virtual de Ethereum7. Dicha mĂĄquina virtual sirve como un entorno de desarrollo8 sobre 

el cual puede correr un lenguaje de programaciĂłn Turing-completo. Es decir, que puede simular la 

lĂłgica de cualquier algoritmo computacional (Buterin, 2020).  Lo anterior significa que puede simular 

exclusivamente aquellas cosas susceptibles de ser programadas computacionalmente9.  

En el ĂĄmbito de aplicaciĂłn de los Smart Contracts, de acuerdo a las limitaciones, se 

desprende la siguiente comparaciĂłn; mientras los contratos jurĂ­dicos encuentran sus limitaciones en 

los denominados requisitos de existencia y validez como el objeto lĂ­cito, la causa lĂ­cita, el 

consentimiento libre de vicios, la capacidad, entre otros (CĂłdigo Civil Colombiano, 1887, Art. 1261), 

los contratos inteligentes encuentran su limitaciĂłn en la lĂłgica booleana10 inherente a su naturaleza, 

junto con los limitantes tĂŠcnicos del hardware y software en que corre la cadena. 

 
7 Una mĂĄquina virtual es un programa de computador que simula o emula otro computador. La mĂĄquina 

principal se llama host, que es la que pone los recursos, y luego en esta host se instala el sistema operativo 

guest. Dentro de un computador fĂ­sico se pueden instalar varios sistemas operativos y los recursos de memoria 

RAM, disco duro, procesador, etc, son repartidos entre los sistemas operativos por un programa llamado 

hipervisor. 
8 Un entorno de desarrollo en programaciĂłn es un programa o aplicaciĂłn que reĂşne algunos componentes 

necesarios para pasar el cĂłdigo fuente a cĂłdigo mĂĄquina, el cual contiene las instrucciones lĂłgicas que puede 

ejecutar el procesador a travĂŠs de sus puertas lĂłgicas. Un entorno de desarrollo contiene normalmente: Un editor 

de texto en donde se escribe el cĂłdigo fuente en lenguaje de programaciĂłn. Un debugger o herramienta para 

detectar errores. Un linter para analizar la sintaxis. Un parser que se encarga de detectar las palabras claves del 

cĂłdigo fuente y construir un objeto virtual que es el que se compila. Un compilador que traduce el cĂłdigo fuente 

procesado a cĂłdigo hexadecimal, tambiĂŠn llamado lenguaje ensamblador. 
9 No todo puede ser programado. Si bien la informĂĄtica hace un gran trabajo en manipular la informaciĂłn en 

distintas formas, bien sea texto, imĂĄgenes, audio o video, existen acciones que aĂşn no pueden ser programadas 

o generadas mediante computadores, como la empatĂ­a. 
10 La lĂłgica booleana es un sistema lĂłgico ideado por el matemĂĄtico George Boole, mediante el cual se expresan 

operaciones aritmĂŠticas y algebraicas usando dos valores (verdadero y falso), y algunos conectores lĂłgicos (y, 

o, y/o). Con esta herramienta es que se diseĂąan los circuitos integrados o microchips. 



Con la MĂĄquina Virtual de Ethereum, se abre un mundo de posibilidades puesto que, en este 

entorno, las transferencias de criptoactivos pueden ser programados, configurados, creados, 

escritos o modificados para que sigan ciertas reglas lĂłgicas.  

Por ejemplo, se puede programar un pago para que sea ejecutado mediante transferencia de 

criptoactivos el dĂ­a 5 de cada mes o la transferencia de cierta cantidad de criptoactivos si se cumple 

determinada condiciĂłn, que es el objeto del presente trabajo. 

DespuĂŠs de haber realizado un anĂĄlisis informĂĄtico, es posible afirmar que los Smart 

Contracts son programas informĂĄticos que agrupan una serie de instrucciones y lĂłgica 

computacional para su propia ejecuciĂłn (que termina en transferencias de criptoactivos o envĂ­o de 

informaciĂłn); es decir, sin intervenciĂłn posterior de un usuario.  Este conjunto de instrucciones es 

luego instalado en un entorno informĂĄtico seguro, llamado Blockchain, el cual protege, mediante la 

criptografĂ­a y las matemĂĄticas, la informaciĂłn o datos almacenados garantizando su autenticidad, su 

no duplicidad, y su incorrupciĂłn. Al ser instalados y ejecutados por primera vez en dicha plataforma, 

estos programas no pueden ser modificados unilateralmente, sino mediante el consenso de todos 

los participantes en la red, asegurando asĂ­ que la lĂłgica contenida en ese programa serĂĄ ejecutada y 

que dicha ejecuciĂłn se corresponde con la transferencia de una cuenta a otra de determinados 

criptoactivos, informaciĂłn o criptomonedas. 

El sistema de Blockchain ha sido ideado desde su concepciĂłn como un sistema de seguridad, 

el cual se vale de tĂŠcnicas de encriptaciĂłn avanzada para garantizar la fiabilidad de la informaciĂłn y 

de las transacciones que tienen lugar en ella. 

Los criptoactivos lucen por su irreplicabilidad y univocidad matemĂĄtica, lo que los hace, 

literal y computacionalmente, Ăşnicos en su especie (CĂĄmara de Comercio de BogotĂĄ, 2019). AsĂ­ 

como en la industria de la construcciĂłn algunos materiales son preciados por sus caracterĂ­sticas o 

asĂ­ como en los equipos de fĂştbol se busca a los mejores jugadores para armar el equipo, asĂ­ mismo 



en la informĂĄtica los criptoactivos son una materia prima Ăşnica para el diseĂąo de programas y 

sistemas de pagos.  

 

Concepto legal.  

En Colombia en la actualidad no se cuenta con una regulaciĂłn expresa sobre los Smart 

Contracts o contratos inteligentes; sin embargo, el proyecto de Ley 028 de 2018, trajo una definiciĂłn 

de la tecnologĂ­a Blockchain: 

ArtĂ­culo 3. Definiciones. Para efectos de la presente Ley, se entenderĂĄn como definiciones 

que permita la interpretaciĂłn de la misma, los siguientes: (...) 

3.2. Blockchain. base de datos distribuida y conformada por cadenas de bloques, la cual 

estĂĄ diseĂąada para evitar su modificaciĂłn, despuĂŠs de realizar la publicaciĂłn de un dato 

usando un sellado de tiempo confiable, el cual es enlazado a uno de los bloques de la 

cadena. 

La finalidad de este proyecto de ley no es regular la naturaleza jurĂ­dica de los contratos 

inteligentes sino otra muy especĂ­fica, que consiste en regular el trading de criptoactivos. Esta prĂĄctica 

ha debido ser objeto de regulaciĂłn pues se ha prestado para estafas y captaciĂłn de dinero. 

Si bien el concepto Blockchain fue definido por el proyecto de ley 28 de 2018, otro concepto 

relevante en Colombia es el de los criptoactivos, los cuales no fueron aceptados por el banco de la 

RepĂşblica como monedas locales, porque dentro de su argumento sostienen que la moneda de curso 

legal en la repĂşblica colombiana es el peso colombiano. En ese mismo concepto el Banco de la 

RepĂşblica afirma que las monedas virtuales son activos que no pueden ser considerados una divisa, 

puesto que no tienen el respaldo de los bancos centrales de otros paĂ­ses (Banco de la RepĂşblica, 

2016).  

Con ocasiĂłn del impacto de la revoluciĂłn digital alrededor del mundo, muchos paĂ­ses se 

pusieron en la tarea de regular las nuevas tecnologĂ­as como el Blockchain y los contratos inteligentes. 



Uno de estos países es Italia, quien de la mano de la Agenzia per l’Italia Digitale11, promulgó el 

Decreto Legislativo 135 de 2018, en el que se incluyĂł a la tecnologĂ­a Blockchain dentro del conjunto 

de las tecnologĂ­as basadas en registros distribuidos. Siendo estas las que utilizan un registro 

compartido, distribuido, replicable, accesible simultĂĄneamente y descentralizado 

arquitectĂłnicamente sobre bases criptogrĂĄficas, para permitir el registro, la validaciĂłn, la 

actualizaciĂłn y el archivo de datos en forma clara y protegida por una criptografĂ­a verificable por 

cada participante, que no puede ser alterado y no puede ser modificado. AdemĂĄs, se afirmĂł la 

relevancia de la tecnologĂ­a Blockchain en cuanto a la protecciĂłn de la propiedad intelectual en Italia 

(La Loggia, 2019). 

La definiciĂłn italiana de las tecnologĂ­as basadas en registros distribuidos es muy pertinente 

por dos razones. La primera, es que nunca ha sido conveniente plantear una regulaciĂłn exclusiva 

para una tecnologĂ­a en concreto, puesto que la tecnologĂ­a sufre adaptaciones, mejoras y cambios 

que hacen que la legislaciĂłn para el caso particular quede rĂĄpidamente obsoleta; La segunda, es 

porque define la tecnologĂ­a Blockchain de una manera precisa de tal manera que englobe el 

fenĂłmeno social o humano, independientemente de la implementaciĂłn concreta de la tecnologĂ­a. Es 

decir, esta definiciĂłn generalizada de las tecnologĂ­as basadas en registros distribuidos goza de un 

nivel de abstracciĂłn adecuado y facilita la labor del intĂŠrprete y ejecutor de la norma. 

Habiendo abarcado los conceptos informĂĄticos y legales de los Smart Contracts y su 

contexto, se expondrĂĄn dos ejemplos de Smart Contracts, en los que se explicarĂĄ su contenido. 

 

 

  

 
11 Es una instituciĂłn que procura la implementaciĂłn de las tecnologĂ­as de la informaciĂłn en la administraciĂłn 

pĂşblica, toda vez que se entiende que es un medio idĂłneo para desarrollar los principios de transparencia, 

eficiencia y eficacia en el manejo de los recursos pĂşblicos. 



Ejemplo nĂşmero 1. 

 pragma solidity ^0.4.0; 

  contract ChildSavings { 

   address owner; 

   uint256 public birthday; 

     event UserStatus(string _msg, address user, uint amount, uint256 

time); 

  function ChildSavings(uint256 _birthday) payable { 

 owner = msg.sender; 

 birthday = _birthday; 

 UserStatus('Child savings account created', msg.sender, msg.value, 

block.timestamp); 

  }   

modifier onlyOwner() { 

if(owner == msg.sender && block.timestamp > (birthday + 180)) { 

_; 

 } else { 

  revert(); 

   } 

  } 

   function depositFunds() payable { 

   UserStatus('User has deposited some money', 

msg.sender, msg.value, block.timestamp); 

  } 

  function withdrawFunds(uint amount) onlyOwner { 

   if (owner.send(amount)) { 

    UserStatus('User has withdrawn some money', 

msg.sender, amount, block.timestamp); 

   }  

  } 

  function getAllFunds() onlyOwner { 

   UserStatus('User Removed all Funds', msg.sender, 

this.balance, block.timestamp); 

   owner.transfer(this.balance); 

  } 

  function Kill() onlyOwner { 

   UserStatus('Contract Disabled, Transfering Balance 

to Owner', msg.sender, this.balance, block.timestamp); 

      suicide(owner); 

  } 

Nota:  Palacios Paiva, N. (2018, Junio 5). magonicolas/Ethereum-Solidity. Retrieved from GitHub: 

https://github.com/magonicolas/Ethereum-Solidity  

       Este contrato es una especie de seguro o de ahorros, en virtud del cual se declaran unas 

funciones que depositan dinero cada aĂąo (en determinada fecha) a un niĂąo menor de edad y se 

corroborarĂĄ luego, al cumpleaĂąos 18 del niĂąo, que podrĂĄ retirar el dinero. 

Ejemplo nĂşmero 2. 



1. pragma solidity ^0.4.0; 
2.  contract LastWill { 

3.      address owner; 

4.      uint256 public lastTouch; 

5.      address[] public childs; 

6.      event Status(string _msg, address user, uint256 time); 

7.      function LastWill() payable { 

8.          owner = msg.sender; 

9.          lastTouch = block.timestamp; 

10.          Status('Last Will Created', msg.sender, 

block.timestamp); 

11.      } 

12.       

13.      function depositFunds() payable { 

14.          Status('Funds Deposited', msg.sender, 

block.timestamp); 

15.      } 

16.       

17.      function stillAlive() onlyOwner { 

18.          lastTouch = block.timestamp; 

19.          Status('I Am Still Alive!', msg.sender, 

block.timestamp); 

20.      } 

21.       

22.      function isDead() { 

23.          Status('Asking if dead', msg.sender, 

block.timestamp); 

24.          if(block.timestamp > (lastTouch + 120)) { 

25.              giveMoneyToChilds(); 

26.          } else { 

27.              Status('I Am still Alive!', msg.sender, 

block.timestamp); 

28.          } 

29.      } 

30.       

31.      function giveMoneyToChilds() { 

32.          Status('I am dead, take my money', msg.sender, 

block.timestamp); 

33.          uint amountPerChild = this.balance/childs.length; 

34.          for(uint i = 0; i < childs.length; i++) { 

35.              childs[i].transfer(amountPerChild); 

36.          } 

37.      } 

38.      function addChild(address _address) onlyOwner { 

39.          Status('Child Added', _address, block.timestamp); 

40.          childs.push(_address); 

41.      } 

42.       

43.      modifier onlyOwner { 

44.    if (msg.sender != owner) { 

45.     revert(); 

46.    } else { 

47.     _; 

48.    } 

49.   } 

50.     } 



Nota: Palacios Paiva, N. (2018, Junio 5). magonicolas/Ethereum-Solidity. Retrieved from GitHub: 

https://github.com/magonicolas/Ethereum-Solidity 

Este segundo ejemplo trata de una Ăşltima voluntad o legado. Los nombres de las funciones 

en las lĂ­neas 13, 19, 23, 28 y 31 son: LastWill, depositFunds, stillAlive, isDead y giveMoneyToChilds(). 

Que en espaĂąol serĂ­an Ăşltima voluntad, depositar fondos, todavĂ­a vivo, estĂĄ muerto y dar dinero a 

los hijos. Lo que se traduce en que, si el usuario dueĂąo del dinero estĂĄ vivo, el programa se abstendrĂĄ 

de realizar transacciĂłn alguna, pero que, si el dueĂąo del dinero por lo contrario, estĂĄ muerto, realizar 

se habilitan los fondos para que sean retirados por los herederos. 

Otras aplicaciones importantes que han tenido los Smart Contracts han sido: juego de loterĂ­as 

(si sale la balota ganadora se transfieren los fondos al ganador), apuestas (Si el Real Madrid gana la 

liga, se paga la apuesta al ganador), Contratos financieros (mutuo con y sin intereses. CreaciĂłn y 

emisiĂłn de acciones: se emiten las acciones como tokens y se transfieren a los accionistas). Como 

complemento al contexto legal, es importante realizar un paralelo entre los contratos Civiles y los 

contratos inteligentes. El punto de partida es la definiciĂłn clĂĄsica de contrato, el cual seĂąala un 

acuerdo de voluntades libre de vicios sobre un objeto lĂ­cito como su principal requisito de existencia 

(CĂłdigo Civil Colombiano, 1887, Art. 1495). 

Ahora bien, Âżun programa informĂĄtico como el Smart Contract es un acuerdo de 

voluntades?  

La respuesta es negativa, por las siguientes razones: i) el programa nace porque un 

desarrollador lo programĂł siendo entonces un acto unilateral. Esto desafĂ­a la concepciĂłn del alcance 

de la autonomĂ­a de la voluntad en un contrato; ii) porque el computador no tiene una manera eficaz 

de determinar la capacidad jurĂ­dica de una persona; iii) el programa se escribe en un lenguaje de 

programaciĂłn que no es idĂłneo para manifestar una voluntad, pues una persona ordinaria, ni siquiera 

el buen hombre de negocios tiene los conocimientos tĂŠcnicos, no lo puede entender a primera vista 

y necesitarĂ­a de una aclaraciĂłn o peritaje para comprender su contenido. 



Y sin embargo, nos encontramos frente a una especie de documento sui generis que contiene 

unas instrucciones para la modificaciĂłn del patrimonio de las personas partĂ­cipes. Dependiendo del 

punto de vista desde el que se observe, el contrato inteligente puede ser este puede ser considerado 

a lo sumo como el instrumento utilizado para la ejecuciĂłn de un acuerdo de voluntades previamente 

estipulado, acordado y establecido. 

AsĂ­ entonces, no es posible equiparar los Smart Contracts o contratos inteligentes con los 

contratos tradicionales regulados expresamente en el ordenamiento jurĂ­dico colombiano. Sin 

perjuicio de lo anterior, es posible afirmar que los Smart Contracts resultan ser una herramienta de 

ejecuciĂłn a un acuerdo de voluntades previamente informado, analizado y aceptado por las partes; 

para explicar esto, es necesario remitirse a la teorĂ­a general del contrato y las etapas contractuales. 

La primera etapa en un contrato es la etapa precontractual, mencionada en el artĂ­culo 863 

del código de comercio, según el cual “Las partes deberán procede de buena fe exenta de culpa en 

el período precontractual, so pena de indemnizar los perjuicios que se causen”. Esta etapa es 

comĂşnmente la etapa de la oferta.  

La segunda etapa, es la contractual, correspondiente a la ejecuciĂłn del contrato, en la cual 

las partes cumplen de manera diligente y satisfactoria las obligaciones contenidas en el contrato que 

en el derecho de obligaciones colombiano pueden ser de dar, hacer o no hacer y que para los Smart 

Contracts aplicarĂĄn extensamente en los negocios jurĂ­dicos que versen sobre obligaciones de dar, 

pues para obligaciones de hacer o no hacer resulta complejo en muchos casos. El contrato se 

ejecutarĂĄ tambiĂŠn bajo el principio de pacta sunt servanda operando bajo la condiciĂłn resolutoria 

tĂĄcita.  

La tercera y Ăşltima etapa es la post contractual, esta inicia si las obligaciones respectivas se 

llevaron a feliz tĂŠrmino por las partes y mantendrĂĄ algunas responsabilidades como el saneamiento 

de vicios redhibitorios o la ejecuciĂłn de alguna garantĂ­a (Tamayo Lombana, 2005, pĂĄg. 32). 



DespuĂŠs de poner en conocimiento las etapas del contrato tradicional, resulta conveniente 

resaltar que los contratos inteligentes o Smart Contracts una vez superada la etapa informĂĄtica en 

la que se programa y se determinan las tareas a ejecutar, operan de manera rĂĄpida, sencilla, 

inmodificable, por lo que son calificados como autoejecutables. En palabras de EchabarrĂ­a Saenz:  

AsĂ­ pues, sin perjuicio de que el pacto pueda ser escrito en lenguaje humano, al menos una 

parte de este serĂĄ transcrita a un cĂłdigo de programaciĂłn o formato electrĂłnico que, 

propiamente, es un programa de ejecuciĂłn. En ĂŠl se definen las reglas y las consecuencias 

de estas y una vez fijadas las reglas de ejecuciĂłn, por ejemplo; la entrega de la mercancĂ­a 

en almacĂŠn se seĂąala como evento desencadenante, el mecanismo de ejecuciĂłn no 

dependerĂĄ de la voluntad de las partes, sino de un programa que actuarĂĄ 

automĂĄticamente cuando identifique las reglas de ejecuciĂłn (EchabarrĂ­a Saenz, 2017, pĂĄg. 

27). 

SegĂşn lo anterior, es posible desprender que el Smart Contract a pesar de que no pueda 

equipararse a un contrato tradicional, se puede identificar como una gran herramienta que permite 

la ejecuciĂłn automĂĄtica de las obligaciones de una forma mĂĄs segura a la comĂşn; asĂ­, las partes en el 

ejercicio de la autonomĂ­a de la voluntad pueden acordar utilizar la tecnologĂ­a Blockchain para 

asegurar la ejecuciĂłn del contrato porque la voluntad de las partes en un contrato bilateral puede 

existir independientemente de la forma en que se establezca, esto en razĂłn de que el ordenamiento 

jurĂ­dico rige la libertad de formas contractuales con las respectivas excepciones y que, hasta el 

momento, no ha exigido nunca que el contrato se deba implementar mediante Smart Contract. 

     Resulta transcendental aclarar que el artĂ­culo 1502 del CĂłdigo Civil deja por fuera los 

requisitos de forma en los contratos, haciendo prevalecer el principio de solus consensus obligat, es 

decir, rige el consensualismo en la formaciĂłn de contratos y las excepciones son pocas (aunque no 

poco importantes), como, por ejemplo, la compraventa de inmuebles. 



Las partes gozan de libertad a la hora de establecer la forma en que se va a perfeccionar el 

contrato, en especial si se trata de particulares, pudiendo, en consecuencia, elegir la creaciĂłn de un 

Smart Contract como requisito formal a la";"""date"",""2020-08-11T18:19:51Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.7""
""xmp:CreatorTool"",""MicrosoftÂŽ Word para Microsoft 365""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dc:creator"",""NRL""
""language"",""es""
""dcterms:created"",""2020-08-11T18:19:51Z""
""Last-Modified"",""2020-08-11T18:19:51Z""
""dcterms:modified"",""2020-08-11T18:19:51Z""
""dc:format"",""application/pdf; version=1.7""
""xmpMM:DocumentID"",""uuid:067B8C2E-717F-40A7-8624-8D901B045441""
""Last-Save-Date"",""2020-08-11T18:19:51Z""
""pdf:docinfo:creator_tool"",""MicrosoftÂŽ Word para Microsoft 365""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2020-08-11T18:19:51Z""
""meta:save-date"",""2020-08-11T18:19:51Z""
""pdf:encrypted"",""false""
""xmp:CreateDate"",""2020-08-11T13:19:51Z""
""modified"",""2020-08-11T18:19:51Z""
""Content-Length"",""284268""
""pdf:hasMarkedContent"",""false""
""Content-Type"",""application/pdf""
""xmp:ModifyDate"",""2020-08-11T13:19:51Z""
""pdf:docinfo:creator"",""NRL""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""NRL""
""dc:language"",""es-MX""
""meta:author"",""NRL""
""pdf:producer"",""MicrosoftÂŽ Word para Microsoft 365""
""meta:creation-date"",""2020-08-11T18:19:51Z""
""created"",""2020-08-11T18:19:51Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""34""
""Creation-Date"",""2020-08-11T18:19:51Z""
""resourceName"",""An%C3%A1lisis%20de%20las%20obligaciones%20condicionales%20en%20la%20implementaci%C3%B3n%20de%20Smart%20Contracts.pdf""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""270"",""370"",""832"",""2209"",""1060"",""2505"",""2107"",""2898"",""3236"",""2122"",""1838"",""2002"",""1557"",""1668"",""2197"",""2099"",""2109"",""1892"",""2101"",""2065"",""1761"",""2266"",""1987"",""1926"",""1467"",""2288"",""1062"",""2109"",""2044"",""2139"",""1722"",""1723"",""1725"",""131""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""Author"",""NRL""
""producer"",""MicrosoftÂŽ Word para Microsoft 365""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""MicrosoftÂŽ Word para Microsoft 365""
""pdf:docinfo:created"",""2020-08-11T18:19:51Z""
";https://scholar.google.ch/scholar?start=870&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098835-268;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Oracle separations between quantum and non-interactive zero-knowledge classes;B Morrison, A Groce ; Information Processing Letters, 2020  Elsevier;;"… Using this algorithm and the quantum query lower bound on the collision problem we have

demonstrated the existence of an oracle relative to which NIPZK ? BQP. This result has

applications to the quantum-resistance of cryptography and cryptocurrency, where algorithms …";Autres articles;;[PDF] arxiv.org;https://arxiv.org/pdf/1907.03205;"
Oracle Separations Between Quantum and Non-interactive

Zero-Knowledge Classes

Benjamin Morrison1 and Adam Groce2

1University of New Mexico
2Reed College

Abstract

We study the relationship between problems solvable by quantum algorithms in polynomial time and
those for which zero-knowledge proofs exist. In prior work, Aaronson [1] showed an oracle separation
between BQP and SZK, i.e. an oracle A such that SZKA 6⊆ BQPA. In this paper we give a simple
extension of Aaronson’s result to non-interactive zero-knowledge proofs with perfect security. This class,
NIPZK, is the most restrictive zero-knowledge class. We show that even for this class we can construct
an A with NIPZKA 6⊆ BQPA.

1 Introduction

We investigate the relationship between quantum-computable problems and those with zero-knowledge
proofs. We are motivated by the general desire of complexity theory to understand all relationships between
complexity classes, as well as implications this particular relationship has for quantum-resilient cryptography.
Specifically we consider the class BQP, those languages decidable by a quantum computer in polynomial
time with bounded error. (See [8] for a more thorough discussion.)

Zero-knowledge is really a family of complexity classes. In a zero-knowledge proof for language L, the
prover P must convince a verifier V that x ∈ L. The zero-knowledge property requires that the verifier
cannot learn anything other than the statement being proved. (For example, P cannot send a witness for x.)
This is formalized by requiring that a simulator without access to P can produce a transcript T ′ that is
indistinguishable from a transcript T of a real interaction. If T ′ is required to be distributed identically to T ,
then the resulting complexity class is perfect zero-knowledge (PZK). If it is required only to be statistically
close, we get statistical zero-knowledge (SZK). If it is only required to be computationally indistinguishable,
we get computational zero-knowedge (CZK). (See [3] for a more thorough discussion.)

We can further restrict the three classes above by requiring that the protocols be non-interactive. That
is, we require that the whole interaction between P and V consist of a single message sent from P to V . To
make this possible, we must give the parties access to a common random string. We therefore have three
non-interactive classes, analogous to those above (NICZK, NISZK, and NIPZK).

There are no unconditional results proving anything about the relationship between BQP and any of the
six zero-knowledge classes discussed above. However, Aaronson [1] gave an oracle separation, an oracle A
under which SZKA 6⊆ BQPA. This is evidence that there are problems with zero-knowledge proofs but no
quantum algorithms, and it rules out many proof techniques for proving otherwise. In this paper we give a
simple extension of this result, showing an oracle separation between BQP and NIPZK. NIPZK is the most
restrictive of the zero-knowledge classes, so when we show an A such that NIPZKA 6⊆ BQPA we implicitly
show the same for PZK, NICZK, and NISZK.

Implications for cryptography In recent years a variety of cryptographic protocols have been built using
non-interactive zero-knowledge proofs. For example, Miller et al. use them to create a cryptocurrency that
can be generated and spent anonymously [9]. Haralambiev uses them to create leakage-resilient signatures,
signatures that remain secure even when some of the secret key is disclosed [4]. Juels et al. show they can

1

ar
X

iv
:1

90
7.

03
20

5v
1 

 [
cs

.C
C

] 
 6

 J
ul

 2
01

9



be used in a less desirable way, allowing crowdfunding to be used to reward hackers for disclosing the secret
information of their victims [5].

The cryptographic community has also recently spent considerable effort finding protocols that will remain
secure in the face of adversaries with quantum computers. If the non-interactive zero-knowledge classes were
contained in BQP, it would imply that cryptographic protocols using such proofs could not be made resilient
to such quantum adversaries.

2 Oracle Separation Between SZK and BQP

Aaronson [1] proved the following result:

Theorem 2.1. There exists an oracle A such that SZKA 6⊆ BQPA.

Our own proofs follow a similar structure and rely on some of Aaronson’s lemmas, so we begin by recalling
a few key details of his proof. He begins with a lower bound for the quantum query complexity of the Collision
Problem. The problem is defined as follows.

Definition 2.1 (Collision Problem). Let n be an integer and X : {1, ..., n} → {1, ..., n}, represented in
the standard way as a list of outputs. Suppose either X is one-to-one (that is, each element of {1, ..., n} is
output for exactly one input) or X is r-to-one1 for a fixed r ≥ 2 (that is, each element of {1, ..., n} is output
for exactly r inputs or not at all.) Then given the ability to query X, the Collision Problem Colrn is to accept
if X is one-to-one and reject if X is r-to-one.

Aaronson then shows the following result, which we present without proof. Q2(¡) represents the (bounded
error) quantum query complexity of the problem, defined as the number of bits of the input that the algorithm
must examine.

Lemma 2.2. Q2

(
Col2n

)
= Ω

(
n1/5

)
.

Kutin [6] proves a stronger version of the collision lower bound, Ω
(
(n/r)1/3

)
, that also applies when

r 6= 2. (This result is also a strengthening of the result of Shi [10], which gives the same bound but requires
a larger output set for the function.) From either result, a diagonalization can be performed to produce the
desired oracle separation.

3 Oracle Separation Between NIPZK and BQP

We now prove the following new result:

Theorem 3.1. There exists an oracle A such that NIPZKA 6⊆ BQPA.

It suffices to demonstrate a NIPZK algorithm for Col2n. The algorithm, inspired by the algorithm for
uniformity testing given by Malka [7], proceeds as follows. The prover divides the shared random string into
two strings r1 and r2, each of length n. For each ri, it chooses uniformly a string xi with X(xi) = ri. It
then sends the chosen xi to the verifier. The verifier accepts if X(xi) = ri for both i.

We now prove the algorithm is NIPZK. First, we prove its completeness. If X is one-to-one, then its
image equals its codomain, and so the xi can always be selected to be valid, regardless of the ri. Thus the
verifier will always accept any one-to-one function.

Next, we prove its soundness. If X is two-to-one, then half of its codomain is not in its image. Thus,
with probability 3

4 , at least one of r1 or r2 is not in the image of X. Thus, with probability 3
4 , the prover

cannot select xi that the verifier will accept. Thus the soundness error is 1
4 .

Next, we prove its perfect zero-knowledge property. The simulator can simply randomly pick two inputs
x1 and x2, then run them through X to get appropriate ri. Since the xi are selected uniformly, when X is
one-to-one the ri are also uniformly distributed. Furthermore, for those ri, there is only one possible pair
of xi; thus the simulator can exactly recreate the distribution over inputs to the verifier. From there, it can
simply perfectly simulate any verifier on those inputs.

Thus Col2n ∈ NIPZK, and the theorem follows as above.

1It is sufficient for our result to restrict the problem to the r = 2 case.

2



4 Conclusion

We constructed a NIPZK query algorithm for the collision problem. Using this algorithm and the quantum
query lower bound on the collision problem we have demonstrated the existence of an oracle relative to
which NIPZK 6⊆ BQP. This result has applications to the quantum-resistance of cryptography and cryp-
tocurrency, where algorithms occasionally rely on non-interactive zero-knowledge proof protocols. Our result
suggests that the use of those proofs does not introduce vulnerabilities into those algorithms in the pres-
ence of a quantum adversary. The next step would be to extend this oracle separation into an algebraic
oracle separation [2], which would rule out a wider array of proof techniques and give additional evidence
that NIPZK 6⊆ BQP.

References

[1] Scott Aaronson. “Quantum Lower Bound for the Collision Problem”. In: Proceedings of the Thiry-
fourth Annual ACM Symposium on Theory of Computing. STOC ’02. Montreal, Quebec, Canada,
2002, pp. 635–642. isbn: 1-58113-495-9. doi: 10.1145/509907.509999. url: http://doi.acm.org/
10.1145/509907.509999.

[2] Scott Aaronson and Avi Wigderson. “Algebrization: A New Barrier in Complexity Theory”. In: ACM
Trans. Comput. Theory 1.1 (Feb. 2009), 2:1–2:54. issn: 1942-3454. doi: 10.1145/1490270.1490272.
url: http://doi.acm.org/10.1145/1490270.1490272.

[3] Oded Goldreich. Foundations of Cryptography: Volume 1, Basic Tools. Cambridge University Press,
2007.

[4] Kristiyan Haralambiev. “Efficient Cryptographic Primitives for Non-interactive Zero-knowledge Proofs
and Applications”. PhD thesis. 2011. isbn: 978-1-124-80794-2.

[5] Ari Juels, Ahmed Kosba, and Elaine Shi. “The Ring of Gyges: Investigating the Future of Criminal
Smart Contracts”. In: Proceedings of the 2016 ACM SIGSAC Conference on Computer and Commu-
nications Security. CCS ’16. Vienna, Austria, 2016, pp. 283–295. isbn: 978-1-4503-4139-4.

[6] Samuel Kutin. “Quantum Lower Bound for the Collision Problem with Small Range”. In: Theory
of Computing 1.2 (2005), pp. 29–36. doi: 10 . 4086 / toc . 2005 . v001a002. url: http : / / www .

theoryofcomputing.org/articles/v001a002.

[7] Lior Malka. “How to Achieve Perfect Simulation and a Complete Problem for Non-interactive Perfect
Zero-Knowledge”. In: J. Cryptol. 28.3 (July 2015), pp. 533–550. issn: 0933-2790. doi: 10 . 1007 /

s00145-013-9165-6. url: http://dx.doi.org/10.1007/s00145-013-9165-6.

[8] N. David Mermin. Quantum computer science: an introduction. Cambridge University Press, 2007.

[9] Andrew Miller et al. “Nonoutsourceable Scratch-Off Puzzles to Discourage Bitcoin Mining Coalitions”.
In: Proceedings of the 22nd ACM SIGSAC Conference on Computer and Communications Security.
CCS ’15. Denver, Colorado, USA, 2015, pp. 680–691. isbn: 978-1-4503-3832-5. doi: 10.1145/2810103.
2813621. url: http://doi.acm.org/10.1145/2810103.2813621.

[10] Yaoyun Shi. “Quantum lower bounds for the collision and the element distinctness problems”. In: The
43rd Annual IEEE Symposium on Foundations of Computer Science, 2002. Proceedings. IEEE. 2002,
pp. 513–519.

3

http://dx.doi.org/10.1145/509907.509999
http://doi.acm.org/10.1145/509907.509999
http://doi.acm.org/10.1145/509907.509999
http://dx.doi.org/10.1145/1490270.1490272
http://doi.acm.org/10.1145/1490270.1490272
http://dx.doi.org/10.4086/toc.2005.v001a002
http://www.theoryofcomputing.org/articles/v001a002
http://www.theoryofcomputing.org/articles/v001a002
http://dx.doi.org/10.1007/s00145-013-9165-6
http://dx.doi.org/10.1007/s00145-013-9165-6
http://dx.doi.org/10.1007/s00145-013-9165-6
http://dx.doi.org/10.1145/2810103.2813621
http://dx.doi.org/10.1145/2810103.2813621
http://doi.acm.org/10.1145/2810103.2813621

	1 Introduction
	2 Oracle Separation Between SZK and BQP
	3 Oracle Separation Between NIPZK and BQP
	4 Conclusion

";"""date"",""2019-07-09T00:47:49Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2019-07-09T00:47:49Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016) kpathsea version 6.2.2""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2019-07-09T00:47:49Z""
""created"",""2019-07-09T00:47:49Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-07-09T00:47:49Z""
""resourceName"",""1907.03205""
""Author"",""""
""producer"",""pdfTeX-1.40.17""
""pdf:docinfo:producer"",""pdfTeX-1.40.17""
""pdf:unmappedUnicodeCharsPerPage"",""6"",""9"",""2""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2019-07-09T00:47:49Z""
""Last-Modified"",""2019-07-09T00:47:49Z""
""dcterms:modified"",""2019-07-09T00:47:49Z""
""title"",""""
""Last-Save-Date"",""2019-07-09T00:47:49Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2019-07-09T00:47:49Z""
""meta:save-date"",""2019-07-09T00:47:49Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016) kpathsea version 6.2.2""
""Content-Length"",""293662""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""3""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""3003"",""3053"",""2626""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-07-09T00:47:49Z""
";https://scholar.google.ch/scholar?start=810&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098734-34;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;… NO CONTEXTO DO BLOCKCHAIN E DOS SMART CONTRACTS RESIGNIFYING TRUST IN THE CONTEXT OF BLOCKCHAIN AND SMART CONTRACTS;W Engelmann, AH Klein ; Duc In AltumCadernos de Direito, 2020  faculdadedamas.edu.br;;"… 12, nş 26, jan-abr. 2020. | 87 RESSIGNIFICANDO A CONFIANÇA NO CONTEXTO DO

BLOCKCHAIN E DOS SMART CONTRACTS RESIGNIFYING TRUST IN THE CONTEXT OF

BLOCKCHAIN AND SMART CONTRACTS … Confiança. Blockchain. Smart Contracts. Abstract …";Autres articles;;[PDF] faculdadedamas.edu.br;http://faculdadedamas.edu.br/revistafd/index.php/cihjur/article/viewFile/1221/920;"
Revista Duc In Altum Cadernos de Direito, vol. 12, nÂş 26, jan-abr. 2020. | 87 

 
 

RESSIGNIFICANDO A CONFIANÇA  
NO CONTEXTO DO BLOCKCHAIN  E DOS 

SMART CONTRACTS 
RESIGNIFYING TRUST IN THE CONTEXT  

OF BLOCKCHAIN AND SMART CONTRACTS 
 

Wilson Engelmann1 
UNISINOS - RS 

Arthur Henrique Klein2 
UNISINOS - RS 

 

Resumo 

O presente artigo tem como objetivo debater aspectos referentes a forma com 
que o sistema jurĂ­dico-social vem absorvendo as novas tecnologias que alteram 
substancialmente o formato com que os negĂłcios sĂŁo realizados. Baseados num 
modelo descentralizado e autĂ´nomo, sem ingerĂŞncia de ĂłrgĂŁos pĂşblicos e finan-
ceiros intermediadores, a difusĂŁo dessas tecnologias encontra respaldo num 
fenômeno jå identificado por Luhmann na dÊcada de 60, baseado na confiança, 
que objetiva auxiliar a resolução de problemas decorrentes de uma sociedade 
hipercomplexa, como a contemporânea. Plataformas como o Blockchain vem 
ganhando cada vez mais relevância no cenårio mundial, solidificando uma ten-
dĂŞncia que pugna por mais por transparĂŞncia e confiabilidade no que diz respeito 
ao tráfego de dados e informações digitais pela internet. Os ‘smart contracts’, por 
sua vez, trazem ao cenårio jurídico uma inovação que tem como principal mote a 
eficiência e a agilidade quando da identificação de eventuais intercorrências na 

                                                
1 PĂłs-Doutor em Direito PĂşblico-Direitos Humanos pelo Centro de Estudios de 
Seguridad (CESEG), da Facultad de Derecho da Universidade de Santiago de 
Compostela, na Espanha; Coordenador Executivo, Professor e Pesquisador do 
Mestrado Profissional em Direito da Empresa e dos NegĂłcios; Professor e 
Pesquisador do Programa de Pós-Graduação em Direito - Mestrado e 
Doutorado, ambos da UNISINOS; Bolsista de Produtividade em Pesquisa do 
CNPq; LĂ­der do Grupo de Pesquisa JUSNANO, credenciado junto ao CNPq; e-
mail: wengelmann@unisinos.br 
2 Mestre em Direito e aluno nĂŁo regular de Doutorado do Programa de PĂłs-
Graduação em Direito da Universidade do Vale do Rio dos Sinos/RS. Pós-
Graduado em Direito Empresarial, Advogado. 



88 | Revista Duc In Altum - Cadernos de Direito, vol. 12, nÂş 26 jan-abr. 2020. 

 
relação entre os contratantes, buscando soluçþes råpidas e eficazes para as partes 
envolvidas, na tentativa de evitar desnecessåria judicialização. A partir do mÊtodo 
sistĂŞmico-construtivista e da pesquisa bibliogrĂĄfica em documentos que tratam 
da matÊria e as publicaçþes disponíveis no Portal de Periódicos da CAPES, se 
verificou que a “confiança” ressignificada, como um “protocolo digital de confi-
ança”, poderá ser o elo fundamental para ligar a tecnologia do blockchain, as 
clĂĄusulas dos contratos inteligentes e os contratantes, em um mundo contratual 
totalmente virtualizado. 

Palavras-chaves 

Inovaçþes Tecnológicas. Quarta Revolução Industrial. Confiança. Blockchain. 
Smart Contracts. 

 

Abstract 

This article aims to discuss aspects related to the way in which the social and legal system has 
been absorbing new technologies that substantially change the way businesses are conducted. 
Based on a decentralized and autonomous model, without interference from intermediary public 
and financial agencies, the diffusion of these technologies are supported by a phenomenon already 
identified by Luhmann in the 60's, based on trust, which aims to help solving problems arising 
from of a hypercomplex society, as the contemporary. Platforms such as Blockchain have become 
increasingly relevant on the world scenario, solidifying a trend that is pushing for more transpar-
ency and reliability with respect to digital data and information traffic over the Internet. 'Smart 
contracts' on the other hand, bring to the legal scenario an innovation that has as its main 
motive efficiency and agility when identifying any complications in the relationship between 
contractors, seeking quick and effective solutions for the parties involved in the attempt avoid 
unnecessary judicialization. From the systemic-constructivist method and the bibliographic 
research in documents dealing with the subject and the publications available on the CAPES 
Journal Portal, it was found that the resignified “trust” as a “digital protocol of trust” may be 
the link fundamental to linking blockchain technology, smart contract clauses, and contractors 
in a fully virtualized contract world. 

Keywords 

Technological Innovations. Fourth Industrial Revolution. Trust. Blockchain. Smart Contracts. 

 

 

 



Revista Duc In Altum Cadernos de Direito, vol. 12, nÂş 26, jan-abr. 2020. | 89 

 
1 INTRODUÇÃO 

 
Os avanços e as inovaçþes tecnológicas impþem ao Direito 

um desafio que surpreende aos mais audaciosos cientistas dos 
sĂŠculos XIX e XX. A necessidade do Direito permear ĂĄreas cujos 
conhecimentos tÊcnicos limitam a capacidade de aferição dos riscos 
sociais e ambientais de uma forma jamais imaginĂĄvel. 

A lentidĂŁo e a burocracia dos processos e procedimentos 
que visam regrar ou regulamentar as atividades potencialmente 
lesivas à sociedade comprometem sobremaneira a efetiva atuação 
jurisdicional, que se vĂŞ, muitas vezes, Ă s margens do processo 
evolutivo. Se por um lado eles visam assegurar segurança e 
previsibilidade; por outro, criam obståculos à modernização 
jurídica, especialmente para alcançar aos atos jurídicos agilidade e 
flexibilidade, caracterĂ­sticas que se encontram no centro do mundo 
digitalizado. 

A necessidade de existĂŞncia de normas formais, fenĂ´meno 
metodolĂłgico tĂ­pico do direito brasileiro, com forte influĂŞncia de 
Pontes de Miranda, contradiz-se a uma nova e moderna forma de 
utilização e mercantilização, descentralizada e independente, 
proveniente de tecnologias disseminadas, sem intervençþes ou 
intermediaçþes do poder público ou organização específicas. Isso 
enfatiza um modelo que ĂŠ baseado num mote principal, qual seja, a 
confiança, fenômeno jå identificado por Luhmann na dÊcada de 60. 

As imersĂľes tecnolĂłgicas advindas da robĂłtica, da 
inteligĂŞncia artificial, autonomia veicular, impressĂŁo em 3D, 
nanotecnologia, biotecnologia, armazenamento de energia, 
computação quântica e criação de novos meios de mercantilização, 
atravĂŠs de moedas digitais, enfatizam a complexidade do sistema 
moderno, e, por conseguinte, os desafios do Direito no 
enfrentamento dos impactos na sociedade e no meio ambiente 
como um todo. As contribuiçþes e perspectivas trazidas por Klaus 
Schwab, fundador do FĂłrum EconĂ´mico Mundial, destacam os 
desafios da sociedade na era pĂłs-moderna no enfrentamento 
conjunto – governos, empresas, universidades e sociedade civil – 



90 | Revista Duc In Altum - Cadernos de Direito, vol. 12, nÂş 26 jan-abr. 2020. 

 
para entendimento das tendĂŞncias emergentes, surgidas em razĂŁo 
das incertezas que rodeiam o desenvolvimento e a adoção de 
tecnologias que ele denomina de Quarta Revolução Industrial.   

O dinamismo, a velocidade e a amplitude dos avanços 
tecnológicos e as multialteraçþes dos comportamentos sociais, 
impulsionados principalmente pela instantaneidade de acesso a 
informaçþes e compartilhamento de conhecimento, impþe ao 
sistema jurídico um novo enfoque de sua atuação, na medida em 
que o moroso processo de criação de regras não acompanha a 
magnitude e a volatilidade das transformaçþes.  

O objetivo geral deste artigo serĂĄ: estudar, a partir de 
algumas contribuições da “confiança”, de Niklas Luhmann, para a 
configuração do mundo digital estruturado a partir do Blockchain. 
Como objetivos especĂ­ficos se desenham: a) conhecer algumas 
características da denominada Quarta Revolução Industrial; b) 
observar a confiança (Luhmann) no contexto de uma sociedade 
hipercomplexa; c) conhecer o Blockchain e os smart constracts no 
cenário do “protocolo de confiança”. Nesse contexto, este artigo 
pretende responder ao seguinte problema: sob quais condiçþes as 
estruturas tecnológicas do Blockchain e a construção dos smart 
constracts por meio delas poderĂĄ ressignificar ou mesmo suprimir a 
confiança, tal como concebido por Luhmann? 

  Se utilizarĂĄ a pesquisa bibliogrĂĄfica em documentos que 
tratam da matÊria e as publicaçþes disponíveis no Portal de 
PeriĂłdicos da CAPES, a partir da perspectiva metodolĂłgica 
sistĂŞmico-construtivista, para observar alguns movimentos gerados 
no panorama da Quarta Revolução Industrial e o posicionamento 
de algumas caracterĂ­sticas do Blockchain e dos smart contracts. Sobre a 
perspectiva metodolĂłgica construtivista Luhmann3 ensina que:  

 
[...] observada desde la posiciĂłn construc-
tivista, la funciĂłn de la medotologĂ­a no 
consiste Ăşnicamente en asegurar una des-
cripciĂłn correcta (no errĂłnea) de la reali-

                                                
3 LUHMANN, Niklas. La sociedad de la sociedad. MĂŠxico: Herder, 2007, p. 22. 



Revista Duc In Altum Cadernos de Direito, vol. 12, nÂş 26, jan-abr. 2020. | 91 

 
dad. MĂĄs bien se trata de formas refinadas 
de producciĂłn y tratamiento de la informa-
ciĂłn internas al sistema. Esto quiere decir: 
los mĂŠtodos permiten a la investigaciĂłn 
cientĂ­fica sorprenderse a sĂ­ misma. Para eso 
se vuelve imprescindible interrumpir el 
continuo inmediato de realidad y conoci-
miento del cual proviene la sociedad.  
 

O mĂŠtodo sistĂŞmico-construtivista considera a realidade 
como uma construção de um observador, analisando todas as 
peculiaridades implicadas na observação, partindo de uma 
observação complexa de segunda-ordem, pressupondo reflexþes 
que sĂŁo estabelecidas a partir de um conjunto de categorias 
teĂłricas, prĂłprias da Matriz PragmĂĄtico-SistĂŞmica4, que guardam 
uma coerĂŞncia teĂłrica auto-referencial. Trata-se de uma estratĂŠgia 
autopoiÊtica de reflexão jurídica sobre as próprias condiçþes de 
produção de sentido, bem como as possibilidades de compreensão 
das múltiplas dinâmicas comunicativas diferenciadas em um 
ambiente complexo, como ĂŠ o gerado pelas novas tecnologias, em 
um contexto de um novo constitucionalismo, que se caracteriza 
pela fragmentação, e recebe os reflexos da globalização.  

TambĂŠm se utilizarĂĄ a anĂĄlise funcional, proposta por 
Luhmann5, considerando que ela relaciona a intenção de 
compreender o existente como contingencial e o que for diferente 
como comparåvel. Em outros termos, problema e solução não são 
uma relação que seja um fim em si mesma, mas, antes, serve como 
fio condutor de perguntas por possibilidades e equivalĂŞncias 
funcionais. Nas palavras de Luhmann:  

 
El anĂĄlisis funcional utiliza el proceso del 

                                                
4 Rocha, Leonel Severo. Epistemologia jurĂ­dica e democracia. 2. ed. SĂŁo Leopoldo: Ed. 
UNISINOS, 2003, p. 100. 
5 LUHMANN, Niklas. Sociedad y sistema: la ambición de la teoria. Tradução de 
Santiago LĂłpez Petit y Dorothee Schmitz. Barcelona: PaidĂłs, 1990. 



92 | Revista Duc In Altum - Cadernos de Direito, vol. 12, nÂş 26 jan-abr. 2020. 

 
relacionar com el fin de comprender lo 
existente como contingente, y lo distinto 
como comparable. Relaciona lo dado, sean 
estados o sean acontecimientos, con pun-
tos de vista del problema e intenta hacer 
comprensible y concebible que el proble-
ma pueda ser solucionado de esta manera 
o de otra. La relaciĂłn entre problema y so-
luciĂłn del problema no es aquĂ­ considerada 
como un fin en sĂ­ mismo; mĂĄs bien sirve 
como hilo conductor en la bĂşsqueda de 
equivalĂŞncias funcionales.6 
 

Para tanto, o artigo serĂĄ dividido em trĂŞs capĂ­tulos, confor-
me se verå a seguir, buscando traçar algumas consideraçþes iniciais 
sobre a temåtica apresentada, chamando a atenção para a årea do 
Direito, especialmente a questĂŁo regulatĂłria. 

 
2 OS DESAFIOS DA DENOMINADA QUARTA 
REVOLUÇÃO INDUSTRIAL  
 

A velocidade de inovação em termos de desenvolvimento 
cientĂ­fico e tecnolĂłgico e a ruptura dos paradigmas usuais atĂŠ entĂŁo 
utilizados pelo Direito, impĂľe aos operadores uma nova visĂŁo 
acerca da forma com que a efetividade jurisdicional atingirĂĄ o meio 
social e permitirĂĄ que as novas tĂŠcnicas garantam e resguardem a 
integridade dos usuĂĄrios. 

Tema amplamente difundido por Klaus Schwab em seu 
livro intitulado A Quarta Revolução Industrial traz ao intÊrprete alguns 
dos desafios e das perspectivas que a atual e as próximas geraçþes 
terão que enfrentar no processo de adaptação as mutaçþes 
efĂŞmeras, que ganham cada vez maior velocidade, atingindo de 
forma direta o comportamento social global. 

                                                
6 LUHMANN, Niklas. Sociedad y sistema: la ambición de la teoria. Tradução de 
Santiago LĂłpez Petit y Dorothee Schmitz. Barcelona: PaidĂłs, 1990, p. 131. 



Revista Duc In Altum Cadernos de Direito, vol. 12, nÂş 26, jan-abr. 2020. | 93 

 
Uma provocação social trazida pelos avanços tecnológicos 

diz respeito a desigualdade exacerbada ocasionada pela falta de 
acesso de grande parte da população aos benefícios advindos do 
progresso cientĂ­fico. Este desafio nĂŁo ĂŠ atual, pelo contrĂĄrio, a 
busca pela igualdade social sempre foi um martĂ­rio para todas as 
civilizaçþes. Todavia, ao que se verifica, as pessoas que num futuro 
prĂłximo nĂŁo tenham acesso a internet deixarĂĄ de desfrutar das 
benesses trazidas pelo desenvolvimento social, podendo aumentar 
sobremaneira o abismo da segregação social, ora jå existente. 

Somente para se ter uma ideia do deslocamento social, a 
segunda revolução industrial ainda precisa ser vivida por 17% da 
população mundial, pois quase 1,3 bilhão de pessoas ainda não tem 
acesso a eletricidade. O mesmo tambĂŠm aplica-se a terceira 
revolução industrial, na medida em que mais da metade da 
população mundial, cerca de 4 bilhþes de pessoas, ainda vivem em 
paĂ­ses em desenvolvimento, sem acesso a internet7. 

Schwab classifica as megatendĂŞncias relacionadas as 
inovaçþes e tecnologias que consolidarão a quarta revolução 
industrial atravĂŠs de trĂŞs categorias: fĂ­sicas, digitais e biolĂłgicas. 

A primeira ĂŠ mais fĂĄcil de enxergarmos por causa da sua 
natureza tangĂ­vel, veĂ­culos autĂ´nomos (incluindo caminhĂľes, 
drones, aviĂľes e barcos), impressĂľes em 3D (impressĂľes camada 
sobre camada que atualmente se limitam Ă s indĂşstrias automotivas, 
aeroespaciais e mĂŠdicas, mas que num futuro incluirĂŁo 
componentes eletrĂ´nicos integrados, tais como placas de circuito e 
atÊ mesmo cÊlulas e órgãos humanos), robótica avançada (avanços 
do sensores que capacitam os robĂ´s a compreender e responder 
melhor ao seu ambiente usando inteligĂŞncia artificial para dar 
respostas alĂŠm das programadas) e novos materiais (mais leves, 
fortes, recicláveis e adaptáveis – materiais inteligente com 
autorreparação e autolimpeza, metais com memória que retomam 
suas formas originais, cerâmicas e cristais que transformam pressão 
em energia. Por exemplo, os modernos nanomateriais como o 

                                                
7 Idem, p. 17. 



94 | Revista Duc In Altum - Cadernos de Direito, vol. 12, nÂş 26 jan-abr. 2020. 

 
grafeno8, que Ê cerca de 200 vezes mais forte que o aço, milhþes de 
vezes mais fino que um cabelo humano e um eficiente condutor de 
calor e eletricidade e o grafeno9, tido como mais forte e flexĂ­vel do 
que o produto derivado do grafite). 

Jå com relação as inovaçþes digitais, uma das principais 
promessas de avanço diz respeito da “internet de todas as coisas”. 
A intensidade e o ritmo acelerado com que cada vez mais as coisas 
do mundo fĂ­sico se conectam com as redes virtuais, influenciando 
de maneira direta o cotidiano social, nas mais amplas esferas 
(econômicas, sanitårias, segurança), trazem consigo o dever dos 
operadores de direito revisitarem seus conceitos e utilizarem a 
inovação como forma de dar efetividade a sua atuação. 

Segundo estudo publicado em agosto de 2019 pela Revista 
Forbes, entre 2019 e 2022 o volume de trĂĄfego nas redes globais 
vai ultrapassar a soma de todos os anos de internet entre 1984 e 
2016. SerĂŁo mais 12 bilhĂľes de dispositivos habilitados para 
conexĂŁo mĂłvel e IoT (Internet das Coisas). Em outras palavras, 
mais trĂĄfego serĂĄ criado nestes trĂŞs anos do que nos 32 anos 
anteriores juntos10.  

Sensores menores, mais baratos e inteligentes estĂŁo sendo 
instalados em roupas e acessĂłrios, casas, cidades, redes de 
transportes e energia, bem como nos processos de fabricação11. A 
possibilidade de rastreio em tempo real dos transportes de 

                                                
8 Grafeno ĂŠ tĂŁo forte e elĂĄstico que as fibras de uma teia de aranha revestida de 
grafeno poderiam conter um aviĂŁo em queda, afirma o fabricante. 
https://revistagalileu.globo.com/Tecnologia/noticia/2018/08/cara-e-
maravilhosa-conheca-primeira-jaqueta-de-grafeno-do-mundo.html. 21/08/2018 - 
13H44/. Acesso em 14.ago.2019. 
9 Mais forte e flexĂ­vel do que o produto derivado do grafite, o borofeno chega 
para revolucionar sensores e baterias. 
https://epocanegocios.globo.com/Tecnologia/noticia/2019/04/adeus-grafeno-
conheca-o-novo-material-queridinho-dos-cientistas.html. Acesso em 
14.ago.2019. 
10 25 anos de Revolução. E ela estå só começando. REVISTA FORBES. 70 ed. São 
Paulo, p. 61. Ago.2019. 
11 SCHWAB, idem, p. 27. 

https://epocanegocios.globo.com/Tecnologia/noticia/2019/04/adeus-grafeno-conheca-o-novo-material-queridinho-dos-cientistas.html
https://epocanegocios.globo.com/Tecnologia/noticia/2019/04/adeus-grafeno-conheca-o-novo-material-queridinho-dos-cientistas.html


Revista Duc In Altum Cadernos de Direito, vol. 12, nÂş 26, jan-abr. 2020. | 95 

 
encomendas atingirĂĄ de forma direta a toda cadeia produtiva, desde 
os insumos atĂŠ os produtos finais. 

A revolução digital afetarå a forma de envolvimento e 
colaboração entre indivíduos e instituiçþes. O blockchain, muitas 
vezes descrito como um “livro-razão distribuído”, é um protocolo 
seguro no qual uma rede de computadores verifica de forma 
coletiva uma transação antes de registrå-la e aprovå-la. A tecnologia 
que cria o blockchain cria confiança, permitindo que pessoas que não 
se conheçam, sem nenhuma base subjacente de fidúcia, colaborem 
sem ter que passar por uma base central neutra, ou seja, um 
depositĂĄrio ou um livro contĂĄbil central. Em essĂŞncia, o blockchain ĂŠ 
um livro contĂĄbil compartilhĂĄvel, programĂĄvel, criptograficamente 
seguro e, portanto, confiĂĄvel; ele nĂŁo ĂŠ controlado por nenhum 
Ăşnico usuĂĄrio, podendo ser inspecionado por todos12. 

Em que pese atualmente o blockchain ainda esteja muito 
atrelado ao Bitcoin (primeira criptomoeda), a perspectiva ĂŠ que ele 
futuramente seja utilizado para registro de ampla natureza, como 
nascimentos e Ăłbitos, tĂ­tulos de propriedade, certidĂľes de 
casamento, diplomas escolares, seguros das mais variadas espĂŠcies, 
procedimentos mĂŠdicos e votos, na medida em que quaisquer tipos 
de transaçþes/registros podem ser transformados em códigos. 

A utilização da confiança com base para a realização de 
negócios vem ganhando força no atual cenårio econômico e social. 
Prova disso são as empresas de hospedagem/locação de imóveis, 
que não possuem nenhum imóvel (Airbnb), de prestação de 
serviços de transportes de passageiros, que não possuem qualquer 
frota (Uber), de interação social, que não criam qualquer conteúdo 
(Facebook) e de comĂŠrcio varejista, mais valiosa do mundo, que 
nĂŁo possuem nenhum estoque (Alibaba)13. 

Por fim, as inovaçþes no campo da biologia, trazidas por 
Schwab, ganham ĂŞnfase no campo da genĂŠtica, em especial com 

                                                
12 Ibidem. 
13 GOODWIN, Tom, “https://techcrunch.com/2015/03/03/in-the-age-of-
disintermediation-the-battle-is-all-for-the-customer-interface/, TechCrunch. 
Acesso em 21.ago.2019. 



96 | Revista Duc In Altum - Cadernos de Direito, vol. 12, nÂş 26 jan-abr. 2020. 

 
relação a biologia sintÊtica, que, na acepção do autor, oferecerå a 
capacidade de criar organismos personalizados, escrevendo o DNA 
deles, causando impacto profundo e imediato nĂŁo somente na 
medicina, mas tambÊm na agricultura e na produção de 
biocombustíveis. A edição biológica pode ser aplicada a 
praticamente quaisquer tipos de cÊlulas, permitindo a criação de 
plantas ou animais geneticamente modificados, bem como alterar 
as cĂŠlulas de organismos adultos, incluindo as cĂŠlulas de seres 
humanos. A lista das possíveis aplicaçþes Ê virtualmente 
interminĂĄvel, - que vĂŁo desde a capacidade de modificar os animais 
para que eles possam ser criados com um regime alimentar mais 
econômico ou mais bem adaptado às condiçþes locais atÊ a criação 
de plantaçþes capazes de resistir a temperaturas extremas ou 
secas.14 

A perspectiva de atuação das inovaçþes biológicas no 
campo da reprodução humana, atravÊs de edição genÊtica e 
manipulação do genoma, como, por exemplo, bebês projetados 
com características particulares ou resistentes a uma doença 
especĂ­fica, traz Ă  sociedade temas cujo conhecimento e 
consequĂŞncias nĂŁo podem ser prontamente identificadas. Os 
desafios sociais, mĂŠdicos, ĂŠticos e psicolĂłgicos precisam ser 
amplamente abordados, sob pena de velejarmos em ĂĄguas 
turbulentas, cujos resultados podem nos afastar do destino 
almejado. 

Um relatĂłrio do FĂłrum EconĂ´mico Mundial, publicado em 
setembro de 2015, identificou 21 pontos de inflexĂŁo15 que 
nortearĂŁo o futuro hiperconectado e digital: 

 
 
 
 
 
 

                                                
14 SCHWAB, idem, p. 29-30. 
15 Momentos em que certas mudanças tecnológicas chegam à sociedade. 



Revista Duc In Altum Cadernos de Direito, vol. 12, nÂş 26, jan-abr. 2020. | 97 

 
PONTOS DE INFLEXÃO ESPERADOS ATÉ 202516 

 
10% das pessoas com roupas conectadas Ă  internet 91,2% 

90% das pessoas com armazenamento ilimitado e 
gratuito (financiado por propagandas publicitĂĄrias) 

91,0% 

1 trilhĂŁo de sensores conectados Ă  internet 89,2% 

O primeiro farmacĂŞutico robĂłtico dos EUA 86,5% 

10% dos Ăłculos de leitura conectados Ă  internet 85,5% 

80% das pessoas com presença digital na internet 84,4% 

Produção do primeiro carro impresso em 3D 84,1% 

O primeiro governo a substituir o censo por fontes de 
big-data 

82,9% 

O primeiro telefone celular implantĂĄvel e disponĂ­vel 
comercialmente  

81,7% 

5% dos produtos aos consumidores impressos em 3D 81,1% 

90% da população com smartphones 80,7% 

90% da população com acesso regular à internet 78,8% 

Carros sem motorista chegarĂŁo a 10% de todos os 
automĂłveis em uso nos EUA 

78,2% 

O primeiro transplante de um fĂ­gado impresso em 3D 76,4% 

30% das auditorias corporativas realizadas por IA 75,4% 

Primeira arrecadação de impostos atravÊs de um 
blockchain 

73,1% 

Mais de 50% do trĂĄfego da internet voltado para os 
utilitĂĄrios e dispositivos domĂŠsticos  

69,9% 

Globalmente, mais viagens/trajetos por meio da 
partilha do que em carros particulares  

67,2% 

A primeira cidade sem semĂĄforos com mais de 50.000 
pessoas 

63,7% 

10% do produto interno bruto mundial armazenado 
pela tecnologia blockchain 

57,9% 

A primeira mĂĄquina de IA de um conselho de 
administração 

45,2% 

 

                                                
16 SCHWAB, idem, p. 34. 



98 | Revista Duc In Altum - Cadernos de Direito, vol. 12, nÂş 26 jan-abr. 2020. 

 
Em que pese passados 4 anos da apresentação do relatório 

no FĂłrum EconĂ´mico Mundial, atualmente denota-se que muitas 
das perspectivas Ă  ĂŠpoca vĂŞm se concretizando, como, por 
exemplo, o nĂşmero expressivo e crescente de pessoas que tĂŞm 
acesso à internet, chegando a 53% da população mundial, segundo 
dados publicados pela ONU no final de 201817. Isso significa um 
incremento de mais de 10% se comparados com os dados 
publicados pela União Internacional das Telecomunicaçþes (UIT) 
no ano de 2015. Outros exemplos do cumprimento das 
perspectivas tecnológicas podem ser encontrados na utilização do 
blockchain por grandes empresas com o intuito de otimizar sua 
produção e, por conseguinte, aumentar sua lucratividade18. 

 
3 - A CONFIANÇA (LUHMANN) NO CONTEXTO DE UMA 
SOCIEDADE HIPERCOMPLEXA  

 
Transcendendo os benefícios advindos das inovaçþes 

tecnolĂłgicas, a sociologia e as demais ĂĄreas das humanas, em 
especial a ciĂŞncia jurĂ­dica, aqui entendidas no mais amplo sentido, 
legislativo, executivo e judiciĂĄrio, inclusive no cenĂĄrio 
supranacional, sĂŁo desafiadas a buscarem alternativas para controle 
e regulação das novas atividades desenvolvidas e disponibilizadas à 
população. 

Um traço comum inerente aos avanços tecnológicos 
contemporâneos diz respeito a forma descentralizada e 
independente que essas tecnologias estĂŁo sendo disseminadas, sem 
intervençþes ou intermediaçþes do poder público ou organização 

                                                
17 https://nacoesunidas.org/mais-da-metade-da-populacao-mundial-ainda-nao-
tem-acesso-a-internet/. Acesso em 25.ago.2019 
18 Organizaçþes como Fedex, Walmart, NestlÊ e Amazon estão realizando testes 
para implementar a tecnologia em seus serviços. O Walmart, por exemplo, 
trabalha em parceria com a IBM desde 2016 para otimizar suas atividades com o 
uso do blockchain. Graças à tecnologia de registro digital, o tempo de 
rastreamento para o fornecimento de mangas para a multinacional diminuiu de 7 
dias para apenas 1. https://exame.abril.com.br/tecnologia/blockchain-entenda-
o-que-e-e-quais-sao-as-principais-aplicacoes/. Acesso em 25.08.2019. 

https://nacoesunidas.org/mais-da-metade-da-populacao-mundial-ainda-nao-tem-acesso-a-internet/
https://nacoesunidas.org/mais-da-metade-da-populacao-mundial-ainda-nao-tem-acesso-a-internet/


Revista Duc In Altum Cadernos de Direito, vol. 12, nÂş 26, jan-abr. 2020. | 99 

 
especĂ­ficas. Isso enfatiza um modelo que ĂŠ baseado num mote 
principal, qual seja, a confiança.  

Os elementos da sociologia estudados por Luhmann, que 
tem como lastro a confiança para construção de uma teoria social, 
podem servir de âmago para a busca de soluçþes de conflitos 
decorrentes de uma sociedade hipercomplexa, onde as mutaçþes 
efêmeras trazem inseguranças e incertezas perante a atual e as 
próximas geraçþes, tanto quanto as suas abrangências e resultados.  

Luhmann enfatiza que os sistemas sociais possuem a 
função de apreensão e diminuição da complexidade. “Servem para 
a mediação entre a extrema complexidade do mundo e a 
capacidade muito menor, dificilmente alterĂĄvel por razĂľes 
antropológicas, do homem para a elaboração consciente da 
vivência”19. 

Tomando como definição de complexidade a “totalidade 
dos acontecimentos possíveis”, se pressupõe aos sistemas sociais 
um redutor de complexidade fundamental, um mecanismo bĂĄsico 
que faça uma prÊ-seleção das possibilidades20. Esse redutor 
comunicativo ĂŠ o sentido, que  

 
[...] constitui-se apenas no horizonte do 
mundo como identidade com referĂŞncia 
realizĂĄvel a outras possibilidades. Sentido ĂŠ 
seleção a partir de outras possibilidades; Ê, 
portanto, ao mesmo tempo, referĂŞncia a 
outras possibilidades. O donde da seleção, 
a complexidade reduzida, permanece 
preservado no sentido. [...] O sentido serve 
para a apreensão e redução da 

                                                
19 LUHMANN, Niklas. “Sociologia como teoria dos sistemas sociais”. In: 
Santos, JosĂŠ Manuel (org). O pensamento de Niklas Luhmann. CovilhĂŁ, Portugal: 
Universidade da Beira Interior, 2005, p. 80. 
20 MOTA, Rodrigo. Confiança e complexidade social em Niklas 

Luhmann. PLURAL, Revista do Programa de Pós‐Graduação em 

Sociologia da USP, São Paulo, v. 23, n. 2, 2016, p. 182‐197. 



100 | Revista Duc In Altum - Cadernos de Direito, vol. 12, nÂş 26 jan-abr. 2020. 

 
complexidade do mundo e, sĂł assim, serve 
para a orientação da vivência e da ação21. 

 
Para Luhmann22, o problema fundamental da sociologia ĂŠ a 

complexidade e a consequente tentativa humana de reduzi-la. Com 
isto em mente, o sociĂłlogo alemĂŁo observou como um elemento 
fundamental do cotidiano humano, a confiança, consiste exatamente 
em um mecanismo de redução de complexidade23. 

Tratando do tema complexidade social como problema 
fundamental, Luhmann publica, em 1968, o livro Vertrauen: Ein 
Mechanismus der Reduktion sozialer Komplexität (Confiança: um 
mecanismo de redução da complexidade social) na tentativa de 
oferecer uma definição clara do que Ê o fenômeno da confiança, 
utilizando sua nascente Systemtheorie como ponto de vista.  

Luhmann afirma que “são caos e medo paralisante as 
únicas alternativas à confiança”24. O fator fundamental para o qual 
se faz necessåria a confiança entre os indivíduos Ê a imprevisibilidade do 
comportamento dos outros. Esta imprevisibilidade foi conceituada por Parsons e 
retomada por Luhmann através do teorema da “dupla contingência” (double 
contingency em Parsons; doppelte Kontingenz em Luhmann), conceito 
necessårio para dar conta da possibilidade de interação entre os 
indivĂ­duos, e da possibilidade da prĂłpria ordem social. A 
consciĂŞncia desta dupla contingĂŞncia ĂŠ uma forma direta dos 

                                                
21 LUHMANN, Niklas. “Sociologia como teoria dos sistemas sociais”. In: 
Santos, JosĂŠ Manuel (org). O pensamento de Niklas Luhmann. CovilhĂŁ, Portugal: 
Universidade da Beira Interior, 2005, p. 79. 
22 LUHMANN, Niklas. “Sociologia como teoria dos sistemas sociais”. In: 
Santos, JosĂŠ Manuel (org). O pensamento de Niklas Luhmann. CovilhĂŁ, Portugal: 
Universidade da Beira Interior, 2005, p. 85-86. 
23 MOTA, Rodrigo. Confiança e complexidade social em Niklas 

Luhmann. PLURAL, Revista do Programa de Pós‐Graduação em 
Sociologia da USP, SĂŁo Paulo, v. 23, n. 2, 2016, p. 188. 
24 LUHMANN, Niklas. Confianza. Introdução de Darío Rodríguez Mansilla. 
RubĂ­ (Barcelona): Anthropos Editorial; MĂŠxico: Universidad Iberoamericana; 
Santiago de Chile: Instituto de SociologĂ­a. PontifĂ­cia Universidad CatĂłlica de 
Chile, 2005, p. 21. 



Revista Duc In Altum Cadernos de Direito, vol. 12, nÂş 26, jan-abr. 2020. | 101 

 
indivĂ­duos vivenciarem a complexidade social, e por isso se fazem 
necessĂĄrios mecanismos que diminuam estas contingĂŞncias, prĂŠ-
selecionem as possibilidades de açþes dos indivíduos e, 
consequentemente, reduzam a variedade de comportamentos 
esperados possíveis25. “Através da existência de um alter ego, o 
ambiente dos seres humanos torna-se o mundo da humanidade”26. 

No ato de confiar, a complexidade do mundo futuro ĂŠ 
reduzida. O agente cheio de confiança se engaja como se no futuro 
sĂł houvessem algumas determinadas possibilidades. Ele define seu 
presente futuro num futuro presente.27 Ele faz aos outros seres 
humanos a oferta de um determinado futuro em um futuro 
comum, que nĂŁo segue se resignando ao passado comum, mas que 
ao invÊs disso abrange algo novo. Familiaridade e confiança são, 
portanto, meios complementares de absorção de complexidade, e, 
como passado e futuro, atados um ao outro28. 

As garantias mais concretas, que dão um ar de proteção à 
situação na qual o indivíduo que confia se encontra, jazem na ideia 
de que o indivíduo, objeto da confiança, deseje, por qualquer razão, 
o prolongamento do relacionamento e, portanto, tema as sançþes 
implícitas para a ocasião em que este deseje quebrar a confiança 

                                                
25 MOTA, Rodrigo. Confiança e complexidade social em Niklas 

Luhmann. PLURAL, Revista do Programa de Pós‐Graduação em 
Sociologia da USP, SĂŁo Paulo, v. 23, n. 2, 2016, p. 188-9. 
26 LUHMANN, Niklas. Confianza. Introdução de Darío Rodríguez Mansilla. 
RubĂ­ (Barcelona): Anthropos Editorial; MĂŠxico: Universidad Iberoamericana; 
Santiago de Chile: Instituto de SociologĂ­a. PontifĂ­cia Universidad CatĂłlica de 
Chile, 2005, p. 25. 

27 MARIÑEZ SÁNCHEZ, César David. La confianza: aproximaciones teóricas y 
propuesta sistémica para su abordaje en las ciencias sociales. In: Século XXI – 

Revista de Ciências Sociais, v. 2, n. 1, p.168-199, jan./jun. 2012. 

28 LUHMANN, Niklas. Confianza. Introdução de Darío Rodríguez Mansilla. 
RubĂ­ (Barcelona): Anthropos Editorial; MĂ";"""date"",""2020-05-09T02:13:45Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""BORBA, Bruna Estima. Responsabilidade TributĂĄria, entre a Liberdade e a Lei.""
""xmp:CreatorTool"",""MicrosoftÂŽ Word 2016""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dc:creator"",""Nome do autor""
""language"",""pt""
""dcterms:created"",""2020-05-09T02:13:45Z""
""Last-Modified"",""2020-05-09T02:13:45Z""
""dcterms:modified"",""2020-05-09T02:13:45Z""
""dc:format"",""application/pdf; version=1.5""
""title"",""BORBA, Bruna Estima. Responsabilidade TributĂĄria, entre a Liberdade e a Lei.""
""Last-Save-Date"",""2020-05-09T02:13:45Z""
""pdf:docinfo:creator_tool"",""MicrosoftÂŽ Word 2016""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2020-05-09T02:13:45Z""
""meta:save-date"",""2020-05-09T02:13:45Z""
""pdf:encrypted"",""false""
""dc:title"",""BORBA, Bruna Estima. Responsabilidade TributĂĄria, entre a Liberdade e a Lei.""
""modified"",""2020-05-09T02:13:45Z""
""Content-Length"",""540651""
""pdf:hasMarkedContent"",""true""
""Content-Type"",""application/pdf""
""pdf:docinfo:creator"",""Nome do autor""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Nome do autor""
""dc:language"",""pt-BR""
""meta:author"",""Nome do autor""
""meta:creation-date"",""2020-05-09T02:13:45Z""
""created"",""2020-05-09T02:13:45Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""33""
""Creation-Date"",""2020-05-09T02:13:45Z""
""resourceName"",""920""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""2075"",""2353"",""2068"",""2133"",""1951"",""1749"",""2180"",""2214"",""2192"",""1727"",""1552"",""2173"",""1895"",""2270"",""2240"",""2058"",""2171"",""2234"",""2210"",""2379"",""2064"",""1981"",""1763"",""2266"",""2460"",""2094"",""2090"",""2193"",""2302"",""1892"",""1426"",""1558"",""1353""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""Author"",""Nome do autor""
""producer"",""MicrosoftÂŽ Word 2016""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""MicrosoftÂŽ Word 2016""
""pdf:docinfo:created"",""2020-05-09T02:13:45Z""
";https://scholar.google.ch/scholar?start=580&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098751-77;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Richtiger Einsatz verspricht den Erfolg;C Meinel, T Gayvoronskaya ; Blockchain, 2020  Springer;;"… Verbindung zu Informationen außerhalb der Blockchain erlangen können, werden so genannte

Oracles eingesetzt … wird für den Umtausch von US-Dollar in BTC ein Oracle für die … früher Oraclize)

bietet einen solchen Service für die Verbindung von Blockchain-basierten DApps …";Autres articles;;null;;;;https://scholar.google.ch/scholar?start=620&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098813-212;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Jugglingswap: Scriptless atomic cross-chain swaps;O Shlomovits, O Leiba ; arXiv preprint arXiv:2007.14423, 2020  arxiv.org;;"… Crypto Asset Exchange: Several types of exchange methods exist, most of them are used in

practice … such as expiry time transactions and (4) requires a new implementation for every

blockchain added … 3.3 is a Juggling protocol according to definition 6 in the random oracle model …";Cité 1 fois;Les 2 versions;[PDF] arxiv.org;https://arxiv.org/pdf/2007.14423;"
JugglingSwap: Scriptless Atomic Cross-Chain
Swaps

Omer Shlomovits, Oded Leiba

KZen Research

Abstract. The blockchain space is changing constantly. New chains are
being implemented frequently with different use cases in mind. As more
and more types of crypto assets are getting real world value there is an
increasing need for blockchain interoperability. Exchange services today
are still dominated by central parties which require custody of funds.
This trust imposes costs and security risks as frequent breaches testify.
Atomic cross-chain swaps (ACCS) allow mutual distrusting parties to se-
curely exchange crypto assets in a peer-to-peer manner while preserving
self-custody. Fundamental ACCS protocols [40,29] leveraged the script-
ing capabilities of blockchains to conditionalize the transfer of funds
between trading parties. Recent work [42,36] showed that such proto-
cols can be realized in a scriptless setting. This has many benefits to
blockchains throughput, efficiency of swap protocols and also to fungi-
bility and privacy. The proposed protocols are limited to blockchains
supporting either Schnorr or ECDSA signatures that are sharing the
same elliptic curve parameters.
In this work we present JugglingSwap, a scriptless atomic cross-chain
swap protocol with a higher degree of interoperability. We weaken the
assumptions about blockchains that can be included in the ACCS proto-
col, and only require that (1) a threshold variant exists to the underlying
digital signature scheme and (2) it is based on the elliptic curve discrete
logarithm problem (ECDLP). The fair exchange is achieved by a grad-
ual release of secrets. To achieve this we use a new building block we
call Juggling : a public key verifiable encryption [15] scheme to transfer
segments of secret shares between parties, which can also be of separate
interest. Juggling is then tailored to a specific private key management
system design with threshold signatures security.

1 Introduction

1.1 Background

The problem of fair exchange is how two mutually distrusting parties can jointly
exchange digital assets such that each party receives the other party’s input or
neither does. There exist a variety of fair exchange protocols in the literature,
all with their own specifications and system model. We divide fair exchange
protocols to three categories:

ar
X

iv
:2

00
7.

14
42

3v
1 

 [
cs

.C
R

] 
 2

8 
Ju

l 2
02

0



2 Omer Shlomovits, Oded Leiba

– Trusted Third Party: fair exchange becomes trivial if both parties can agree
on a mutual trusted third party. The parties will send the trusted party
the digital assets. The trusted party will verify correctness and redistribute
to the counterparty. To make it a more scalable solution there is a line of
research to design optimistically fair protocols, such that the trusted third
party gets involved only in case of disputes which are assumed to be rare
[6,30,38].

– Gradual Release of Secrets: This method achieves partial fairness such that
one party can get advantage over the other party but this advantage is
polynomially bounded. The idea is to enable each party to release their
secret bit by bit in alternation [14].

– Monetary Penalties: parties are incentivized to complete the protocol fairly,
and if one party receives its output but aborts before the other party does,
the cheating party will have to pay a penalty [25,32,33].

Focusing on blockchains, fair exchange is a precursor for escrow protocols with
cryptocurrencies [25], markets, auctions, games [32] and atomic cross-chain swaps
(ACCS). An ACCS is a task in which multiple parties wish to exchange digital
assets from possibly distinct blockchains, in such a manner where all parties
receive their desired output from another party, or neither does. In this paper
we consider specifically the two-party setting.
Blockchains are decentralized by nature, therefore a core challenge is to design
protocols without a single point of failure in the form of a trusted third party
which takes full custody of users’ funds. Early ACCS protocols leveraged the
blockchain itself as a decentralized trusted party that can lock and release funds
according to pre-programmed rules. The first successful atomic cross-chain swap
construction is credited to TierNolan [40]. It leverages Bitcoin-like script for cre-
ating conditional transactions by the two exchanging parties: each party locks
its funds such that the counterparty can spend them by using the preimage
of an agreed hash value. When one party spends a transaction, it reveals the
secret to the other party which can use it to spend the other conditional trans-
action on the other blockchain. There is also a timeout after which the funds
can be refunded if not redeemed by the counterparty. Such conditional spending
is termed Hashed Timelock Contract (HTLC) and has been specified and ex-
tended in [43] and [46]. Herlihy in [29] has formalized the theory of such atomic
cross-chain swaps. Poelstra [42] has introduced the notion of scriptless scripts
and described how to achieve atomic swaps without the need of explicit scripting
within transactions. Instead, Schnorr signatures [44] are used: the spending of a
transaction reveals a secret merely by the unlocking signature itself, and only to
the counterparty. This has many benefits to blockchains throughput, efficiency
of swap protocols and also to fungibility and privacy. Malavolta et al. [36] has
extended this technique to ECDSA. The latter two studies have opened the
door for scriptless atomic cross-chain swaps for a variety of existing blockchains.
However, they are still limited to blockchains which support either Schnorr or
ECDSA signatures that share the same elliptic curve parameters, namely - the
same group generated from the same fixed generator.



JugglingSwap: Scriptless Atomic Cross-Chain Swaps 3

1.2 Our Contribution

Our solution, the JugglingSwap ACCS protocol, is based on gradual release of
secrets. We observe that there are two ways to transfer value in a blockchain:

– A transaction backed by a digital signature.
– A transfer of a secret key.

To the best of our knowledge, all existing exchange methods use the first
method. The first method naturally has more constraints to it: either it depends
on the scripting capabilities of the underlying blockchain [29,40,46] or on specific
mechanics of the underlying signature scheme [42,36]. The second method is
purely cryptography-dependent with small variance between blockchains and
thus can fit and be reused for many chains architectures.
The vast majority of blockchains tie funds to key pairs of an elliptic curve group
where the elliptic curve discrete logarithm problem (ECDLP) is considered hard.
Exchanging between two chains in that case comes down to encrypting the secret
key with the other party’s public key. The two problems that arise:

1. When one party transfers a secret key to a second party it does not lose
knowledge of this secret key. The transfer is like a ”copy” whereas in a
transaction based swap the transfer is like a ”cut”: the sending party loses
access to the funds. The undesired result is that both sending and receiving
parties can use the secret key at the end of the transfer.

2. The exchange is not fair. The first to send the encryption will risk the other
party to not complete the protocol.

We address these issues in the following way: first, we add a layer of threshold
cryptography for secret key management. The cross-chain interoperability re-
mains and we get better security. We start our protocol assuming that each of
the two trading parties, the owners, has a joint two-out-of-two ({2, 2}) address
with the same centralized provider.
Second, we introduce and use a new building block we call Juggling : a novel
verifiable encryption [15] construction for transferring segments of a discrete
logarithm. It allows a prover to encrypt a secret in parts and prove that each
resulting ciphertext is indeed an encryption of a segment of a secret key of some
known public key, under some known encryption key.
Combining these two building blocks, the ACCS protocol goes as follows:

1. The two owners and the provider generate two {3, 3} addresses: one on each
of the two blockchains. Each party keeps a local secret key share.

2. Each owner deposits funds into the {3, 3} address of its source blockchain.
3. The two owners start executing two interleaving Juggling protocols, in order

to achieve a partial fair exchange of their respective secret shares of the
two {3, 3} addresses. In other words - they gradually release their secret
shares, segment by segment. Eventually both owners hold 2 shares of their
counterparty’s {3, 3} address and only 1 share of their own {3, 3} address.

4. Each owner co-signs with the provider in order to withdraw the funds from
the counterparty’s {3, 3} address to its own wallet.



4 Omer Shlomovits, Oded Leiba

During the execution of the Juggling protocol (step 3), in case one party
decides to cheat, the maximal advantage is to be one segment ahead. For small
enough segment bit size this is acceptable. The provider’s role can theoretically
be played by a trusted execution environment (TEE).
The resulting ACCS protocol is scriptless. The blockchain footprint of our method
is between one to two regular transactions on each blockchain. Therefore, it offers
similar benefits as the ACCS protocols in [42,36] in terms of improved blockchain
throughput and more efficient swaps (cheaper than their script-dependant alter-
natives), as well as in fungibility and privacy. On top of that, because Juggling
is applicable on arbitrary groups, JugglingSwap has weak assumptions on the
participating blockchains: it only requires that (1) a threshold variant exists for
the underlying signature algorithm and (2) it is based on ECDLP. Therefore,
the set of pairs of blockchains supported by our protocol strictly contains the
set of possible pairs by prior art, so it offers a higher degree of interoperability.
Finally, We believe that the Juggling protocol can be of separate interest and
used as a building block for other constructions as well.

1.3 Related Work

Gradual Release of Secrets: The notion of partial fairness, originated in
[9,21], was proposed as a way to overcome the impossibility result of perfect
fairness in a setting without a trusted third party [17]. Several protocols, such
as [12,19], were built on top of this security notion. Previous works are mainly
focused on bit by bit release of either the secret itself or a digital signature from
the secret and are not generalizable to elliptic curves DLog. Our protocol is
aimed for gradually releasing a ciphertext encrypting an EC-DLog, where the
encryption correctness is publicly verified for every segment and segment size is
configurable.

Crypto Asset Exchange: Several types of exchange methods exist, most of
them are used in practice today. In centralized-custodial exchanges (e.g. [2]), the
exchange is a trusted third party. Funds are deposited to the exchange platform,
trading is done within the platform and finally the funds can be withdrawn to
a private wallet. From the moment of the deposit and until the withdrawal the
funds are owned by the exchange which at any moment can be hacked, stop
working or become malicious and steal all the funds currently held by the plat-
form.
Centralized but non-custodial trading systems (e.g. [4]) are platforms that guar-
antee security before and after the trade but not in the middle: after funds have
been sent to the system by the user and before they are returned, the user must
trust the trading platform, which again can be hacked, suffer denial of service
(DoS) or become malicious and steal the funds. The presence of such a single
point of trust clearly does not match well the decentralized nature of blockchain
technology.
Another form of exchange is decentralized exchanges (or ”DEXes”, e.g. [1,5]).



JugglingSwap: Scriptless Atomic Cross-Chain Swaps 5

These are trustless platforms that settle trades on the blockchain. They can suf-
fer from security issues such as frontrunning and transaction reordering [7,18].
The on-chain trading makes scalability another issue. Lastly, as they typically
utilize smart contracts, they are limited to support only the assets of the specific
blockchain the contracts are deployed on.
Tesseract [8] is using Intel SGX enclave as a trusted execution engine to provide
a better trusted centralized custodial exchange. The problem with this method
is that SGX can suffer from security vulnerabilities as shown recently [47]. Ar-
wen’s [28] protocol offers centralized non-custodial approach based on building
blocks that are used in the Lightning network protocol [43], namely an escrow
service with off-chain trading and on-chain settlement. The problems with this
protocol are the same as the problems with the Lightning network, for exam-
ple: (1) limited capacity, (2) an exchange needs to have many coins tied up to
escrow channels, (3) fits only blockchains with specific features such as expiry
time transactions and (4) requires a new implementation for every blockchain
added.

2 Preliminaries

Here we provide high level informal definitions for Threshold Signatures, Veri-
fiable Encryption and Bulletproofs range proofs. For a more detailed treatment
we refer to the original papers.

2.1 Threshold Signatures

Let S=(Key-Gen, Sign, Ver) be a signature scheme. Following [24] A {t, n}-
threshold signature scheme T S for S is a pair of protocols (Thresh-Key-Gen,
Thresh-Sign) for the set of parties P1, ..., Pn. Thresh-Key-Gen is a distributed
key generation protocol used by the players to jointly generate a pair (Q, x) of
public/private keys on input a security parameter 1Îť . At the end of the protocol,
the private output of party Pi is a value xi such that the values (x1, ..., xn) form
a {t, n}-threshold secret sharing of x. The public output of the protocol contains
the public key Q. Public/private key pairs (Q, x) are produced by Thresh-Key-
Gen with the same probability distribution as if they were generated by the Key-
Gen protocol of the regular signature scheme S. Thresh-Sign is the distributed
signature protocol. The private input of Pi is the value xi. The public inputs
consist of a message m and the public key Q. The output of the protocol is a value
sig ∈Sign(m,x). The verification algorithm for a threshold signature scheme is,
therefore, the same as in the regular centralized signature scheme S

Definition 1. We say that a (t, n)-threshold signature scheme T S =(Thresh-
Key-Gen,Thresh-Sign) is unforgeable, if no malicious adversary who corrupts
at most t− 1 players can produce, with non-negligible (in λ) probability, the
signature on any new (i.e., previously unsigned) message m, given the view of



6 Omer Shlomovits, Oded Leiba

the protocol Thresh-Key-Gen and of the protocol Thresh-Sign on input messages
m1, ...,mk which the adversary adaptively chose.

This is analogous to the notion of existential unforgeability under chosen message
attack as defined by [26]. Notice that now the adversary does not just see the
signatures of k messages adaptively chosen, but also the internal state of the
corrupted players and the public communication of the protocols.
We call the special case of t = n, namely a protocol which allows a group
of signers to produce a short, joint signature on a common message where all
participants are required to be honest, a multi-signature.

2.2 Verifiable Encryption

Loosely speaking, verifiable encryption [15] for a relation R is a protocol that
allows a prover to convince a verifier that a given ciphertext is an encryption
under a given public key of a value ω such that (δ, ω) ∈ R for a given δ.
Let (Gen, Enc, Dec) be a public key encryption scheme, and let (pk, sk) be a key
pair. A verifiable encryption scheme proves that a ciphertext encrypts a plaintext
satisfying a certain relationR. The relationR is defined by a generator algorithm
G′ which on input 1λ outputs a description Ψ = Ψ [R,W, ∆] of a binary relation
R on W×∆. We require that the sets R,W and ∆ are easy to recognize (given
Ψ). For δ ∈ ∆, an element ω ∈ W such that (δ, ω) ∈ R is called a witness for
δ. The idea is that the encryptor will be given a value δ, a witness ω for δ, and
then encrypts ω yielding a ciphertext ψ. After this, the encryptor may prove to
another party that ψ decrypts to a witness for δ. In carrying out the proof, the
encryptor will of course need to make use of the random coins that were used by
the encryption algorithm: we denote by Enc’(pk, m) the pair (ψ, coins), where
ψ is the output of Enc(pk,m) and coins are the random coins used by Enc to
compute ψ. In such a proof system, the (honest) verifier will output 0 or 1, with 1
signifying accept. We require that the proof system is sound, in the sense that if a
verifier accepts a proof, then with overwhelming probability, ψ indeed decrypts to
a witness for δ. However, it is convenient, and adequate for many applications, to
take a more relaxed approach: instead of requiring that ψ decrypts to a witness,
we only require that a witness can be easily reconstructed from the plaintext
using some efficient reconstruction algorithm. Such an algorithm recon takes as
input a public key pk, a relation description Ψ = Ψ [R,W, ∆], an element δ ∈ ∆,
and a message m ∈ Mpk ∪ {reject}, and outputs ω ∈ W ∪ {reject}.

Definition 2. A proof system (P,V), together with mutually compatible encryp-
tion scheme (Gen,Enc,Dec), relation generator G′, and reconstruction algo-
rithm recon , form a verifiable encryption scheme, if Correctness, Soundness
and Special honest-verifier zero knowledge properties hold as defined in [15].

2.3 Bulletproofs Range Proofs

Range proofs are proofs that a secret value, which has been encrypted or commit-
ted to, lies in a certain interval. Range proofs do not leak any information about



JugglingSwap: Scriptless Atomic Cross-Chain Swaps 7

the secret value, other than the fact that they lie in the interval. Bulletproofs [13]
can be used as an efficient instantiation of range proofs and work on Pedersen
commitments [41]. Formally, let group element V be a Pedersen commitment
to value v using randomness r. The proof system will convince the verifier that
v ∈ [0, .., 2n − 1]. Bulletproofs are based on Inner Product Argument and main-
tain perfect completeness, perfect special honest verifier zero-knowledge, and
computational witness extended emulation, defined in [13].

3 The Juggling Protocol

3.1 Specification and Definitions

Let G be an elliptic curve group of prime order q with base point (generator) G.
Party Pi knows discrete log (DLog) xi such that Qi = xiG.

Definition 3. m-Segmentation of x is the division of x to m segments [x]k|mk=1

such that x =
∑
k fk[x]k where fk = 2(k−1)l for segment length in bits l.

Definition 4. We say that a proof is a proof of correct encrypted k-segment
if it is a publicly verifiable zero knowledge proof for encryption scheme {Gen,Enc,
Dec}, public key Y , value δ, relation R, ciphertext ck and parameters k,m such
that ck = Enc(Y, [x]k) is the encryption of [x]k using public key Y , where [x]k is
the k’th segment of m-Segmentation of a witness ω = x such that (δ, ω) ∈ R.

Definition 5. A proof system (P,V), together with mutually compatible encryp-
tion scheme (Gen,Enc,Dec) and parameter m is a Segmented-Verifiable En-
cryption (S-VE) if (a) it is a VE for witness ω and (b) the witness can be
m-Segmented such that for each segment k the prover can prove correct encrypted
k-segment for the same witness ω.

Definition 6. Juggling protocol is S-VE implementation where the witness is
an elliptic curve DLog and segment encryptions and proofs are being released
serially.

It is assumed that there exists a PKI such that all public keys are registered. If
it is not the case, all participants will add a setup phase for key pairs generation
and registration.

3.2 Auxiliary Proofs

All proofs are for public EC parameters G, q, G.

Proof of EC-DDH membership: This is a proof of membership that a tuple
is an Elliptic Curve Decisional Diffie Hellman (DDH) tuple: (G, xG, yG, xyG).
This proof is an adaptation of the proof in [16] for elliptic curves. Proof for the
following relation: the witness is ω = x, the statement is δ = (G1, H1, G2, H2).
The relation R outputs 1 if H1 = xG1 and H2 = xG2.

The protocol works as follows:



8 Omer Shlomovits, Oded Leiba

1. The prover sends a1 = ιG1 and a2 = ιG2 to the verifier with ι ∈R Zq
2. The verifier sends a random challenge e ∈R Zq
3. The prover responds with r = α− xe
4. The verifier checks that a1 = rG1 + eH1 and a2 = rG2 + eH2

See [16] for the formal proof.

Proof of correct encryption: This is a proof of knowledge that a pair of
group elements {D,E} form a valid homomorphic ElGamal encryption (”in the
exponent”) [45] using public key Y . Specifically, the witness is ω = (x, r), the
statement is δ = (G, Y,D,E). The relationR outputs 1 if D = xG+rY , E = rG.

1. The prover chooses s1, s2, computes A1 = s1G,A2 = s2Y,A3 = s2G and
sends to the verifier T = A1 +A2, A3.

2. The verifier picks a challenge e.
3. The prover computes z1 = s1 + ex and z2 = s2 + er.
4. The verifier accepts if z1G+ z2Y = T + eD and z2G = A3 + eE.

Proof of correct encryption of DLog: This is a version of the previous
proof where we also know public key Q and want to prove that {D,E} is ho-
momorphic ElGamal encryption that encrypts the DLog of Q, specifically. This
is a proof for the following relation: the witness is ω = (x, r), the statement is
δ = (G, Y,Q,D,E). The relation R outputs 1 if Q = xG, D = xG+rY , E = rG.
To prove this the prover needs (a) to prove knowledge of the DLog of Q in base
G and (b) to prove that (G,E, Y,D − Q) is a DDH tuple. The proof can be
optimized by using the same challenge as follows:

1. The prover chooses s1, s2, computes A1 = s1G,A2 = s2Y,A3 = s2G and
sends A1, A2, A3 to the verifier.

2. The verifier picks a challenge e.
3. The prover computes z1 = s1 + ex and z2 = s2 + er.
4. The verifier accepts if z1G = A1 + eQ and z2G = A3 + eE and z2Y =
A2 + e(D −Q).

The protocols can become non-interactive using Fiat-Shamir transform. Both
Constructions: proof of correct encryption and proof of correct Encryption of
DLog are Sigma protocols [27] with straight forward security proofs. We provide
the proofs in Appendix A.

3.3 Construction

We observe that S-VE can be implemented using an encryption scheme with
homomorphic properties. We choose homomorphic ElGamal encryption as the
base encryption scheme [45]. Figure 1 shows a sequence diagram of the protocol.



JugglingSwap: Scriptless Atomic Cross-Chain Swaps 9

1. Key Generation:

For EC parameters G, q, G and security parameter Îť every party chooses
random y ∈ Zq for secret key and computes Y = yG for public key. All
public keys are registered.

2. Encryption:

Upon input (x,Q, Y ) where Q,Y are public keys and x is a secret key
such that Q = xG the encryptor (interchangeably will be called the
prover, depends on operation) divides x to m equal segments (last seg-
ment can be padded with zeros). The segments [x]k|mk=1 should be small
enough to allow extraction of [x]k from [x]kG in polynomial time in the
security parameter.
(a) For every segment k: the encryptor computes the homomorphic El-

Gamal encryption : {Dk, Ek} = {[x]kG + rkY, rkG} for random
rk.

(b) The encryptor publishes Dk|mk=1 together with m Bulletproofs ([13],
non-interactive zero knowledge range proofs) proving that every Dk

is a Pedersen commitment [41] with value smaller than 2l (*).
(c) The encryptor publishes E =

∑
k fkEk and plays the prover in proof

of correct encryption of DLog (3.2) with witness (x,
∑
k fkrk) and

statement (G, Y,Q,D,E), where D =
∑
k fkDk.

(d) An encryption for a segment [x]k will be full once the encryptor pub-
lishes Ek of this segment together with a proof of correct encryption
(3.2).

3. Decryption:

Given a secret key y, for every pair {Dk, Ek}, [x]k can be decrypted
by extracting [x]k from Dk − yEk = [x]kG using algorithm for break-
ing DLog. After all m segments are decrypted x =

∑
k fk[x]k can be

reconstructed.
(*) Except to the MSB segment which is tightly bounded to the l most

significant bits of q.

Juggling Scheme

3.4 Security Analysis

In this section we show that the construction is following the specifications.

Lemma 1. If DDH is hard relative to G, then the scheme {Key Generation,
Encryption, Decryption} is CPA-secure encryption scheme.

Proof sketch: ElGamal encryption in the exponent, like standard ElGamal en-
cryption is CPA-secure under DDH [31,45]. {Dk, Ek} is ElGamal encryption in



10 Omer Shlomovits, Oded Leiba

for  in 

rp    RangeProof.Prove( )

 
 

 ProofOfCorrectEncryptionOfDLog.Prove(( ), ( ))

, , , rp

assert RangeProof.Verify(rp , , ) 

assert ProofOfCorrectEncryptionOfDLog.Verify( , ( ))

for  in 

assert ProofOfCorrectEncryption.Verify( , ( ))
 DLog( )

for  in 

 ProofOfCorrectEncryption.Prove(( ), ( ))

, 

Fig. 1. The Juggling protocol sketch. Here P is the encryptor/prover, and V is
the decryptor/verifier. Proofs and encryptions are being released serially by P , where
after each iteration they are being verified and decrypted by V .
Note: when both parties fulfill both roles (each encrypting its own secret), these itera-
tions can interleave: the first party receiving the k’th segment will then send back its
own k’th segment.



JugglingSwap: Scriptless Atomic Cross-Chain Swaps 11

the exponent with randomness rk. Because the randomness rk is changed for
every encryption k ∈ {1, ..,m} the different encryptions are unrelated.

Lemma 2. The proof system {P,V} in Encryption protocol together with ho-
momorphic ElGamal encryption scheme is a proof of correct encrypted k-segment
of DLog of Q, with parameters k, m, Y and security parameter Îť.

Proof sketch: The proof system consists of 2m+ 1 proofs given in a specific
order and correspond to gradual release of the ciphertext:

1. m Bulletproofs.
2. Proof of correct encryption of DLog.
3. Proof of correct encryption for first segment
4. ...
5. Proof of correct encryption for the m’th segment

the order of the last m proofs can be different and it is easy to show that it
does not effect security.
The security proof shows that only m + 2 proofs are needed to proof correct
encrypted k-segment. Specifically, for segment k there is no use for the m − 1
proofs of correct encryption for the other segments.
Correctness: This part of the proof is where we need range proofs, which are ef-
ficiently instantiated by Bulletproofs. To intuitively understand why, let us first
describe a possible attack and why bulletproofs can mitigate it. Proof of correct
encryption for the k’th segment proves to the verifier that {Dk, Ek} is homo-
morphic ElGamal encryption using public key Y . The general proof of correct
encryption proves to the verifier a statement about the shifted sum (

∑
k fk) of

the Dk’s and Ek’s. Namely, that {D,E} is Homomorphic ElGamal encryption
of x under public key Y . A simple attack would be to encrypt biased segments
such that the shifted sum will remain the same but each segment encryption will
be decrypted wrong. W.l.o.g let us change only two segments: for segment k to
encrypt the point vk = ukG = [x]kG+bkG = [x]kG+f−1k G and for segment k+1
to encrypt the point vk+1 = uk+1G = [x]k+1G+bk+1G = [x]k+1G−f−1k+1G. After
decryption, value extraction and segment summation the result would remain
the same and equal to x but both segment encryptions {Dk, Ek}, {Dk+1, Ek+1}
would have extracted to wrong values. In particular the k’th segment will be
extracted to [x]k + f−1k 6= [x]k. The implication of such attack is that if a prover
aborts in the middle of the gradual release, then the decryptor will remain with
nothing while it was expected that it will have all the already published segments
of the secret. We now show how assuming Bulletproof security prevents this spe-
cific attack and then generalize it to all possible changes to encrypted segments
[x]k|mk=1. In our attack there are four cases: one case where both uk, uk+1 are in
range [0, ..., 2l − 1] and three cases where at least one of uk, uk+1 are not in the
range [0, ..., 2l − 1]. For the last three cases it is easy to see that at least one
Bulletproof range proof will not verify with high probability. For the first case
in order for the proof of correct Encryption of DLog to pass we require the sum
bkfk + bk+1fk+1 = nq, to equal a multiple of q, the order of the curve. Every



12 Omer Shlomovits, Oded Leiba

option other than n = 0 and bk = bk+1 = 0 will result in at least one of bk, bk+1

out of range [0, ..., 2l − 1] with high probability.
We are now ready to generalize this argument:
Claim 1. For any k segment ciphertext not in the form [x]k + bk with bk inde-
pendent of [x]k verification will pass with negl(Îť) probability.
Proof: Assuming correctness of m bulletproofs, proof of correct encryption of
DLog and proof of correct encryption of k segment, if the k’th ciphertext is of
different form it means that at least one other segment must encrypt an ad-
ditional compensating element in the k’th segment to cancel the change. This
additional element would have cause the range proof for this segment to fail with
probability 1− negl(λ).
Claim 2. For any k segment ciphertext in the form [x]k + bk , if bk 6= 0 verifi-
cation will pass with negl(Îť) probability.
Proof: The following must hold:

∑
k bkfk = nq If bk 6= 0 for some k at least

one of the bk’s will lead to uk = [x]k + bk > 2l. Assume to the contrary that
for all k: bk < 2l − [x]k and q =

∑
k bkfk. Combining this equations we get

x <
∑
k 2lfk − q. We assume for simplicity that the most significant segment of

q is all-ones. Usually this will restrict the secret key to a very small number such
that for random secret key there is negligible probability that the equation will
hold. If the secret key is not chosen randomly or if we want to make the prob-
ability lower we can simply use secret keys with most significant bit fixed and
equal to 0 (This will not effect security, see discussion in [34] on using secret key
x < q/3). This can be also proven in Encryption time by providing a range proof
on {D,E}. Now the most significant segment can be range proofed to be in the

range [0, ..., 2l−1− 1] such that 2ml−1 +
∑m−1
k=1 2lfk − q is negative and therefore

assuming bulletproof security, this is possible with only negl(Îť) probability.

Soundness: Soundness comes from the soundness of proof of correct encryp-
tion of DLog. There exist algorithm A that given Q and two transcripts of this
proof with two different challenges e 6= e′ outputs ω = x such that Q = xG. This
is enough because algorithm A′ for soundness of the proof of correct encrypted
k-segment of DLog Q can use A and output the k’th segment of the result.

Special honest verifier ZK: All three types of proofs: bulletproof, proof of cor-
rect encryption of DLog and proof of correct encryption have the special HVZK
security property, meaning there exist a simulator S that can output computa-
tional indistinguishable distribution by calling the special HVZK simulators of
the underlying relevant proofs.

Theorem 1. Assuming DDH is hard in G construction 3.3 is a Juggling protocol
according to definition 6 in the random oracle model.

Proof sketch: The proofs of correct encryption combined form a VE of witness x
and DLog relation (Q, x) ∈ R if Q = xG. The prover cannot change witness from
the range proof to the proof of correct encryption of DLog since otherwise the
prover would have broken the binding property of Dk as a commitment, which



JugglingSwap: Scriptless Atomic Cross-Chain Swaps 13

is equivalent to finding the DLog of Y which assume to be hard. Same is true
for changing witness from proof of correct encryption of DLog to the proofs of
correct encryption. Property 2 of S-VE definition holds because Lemma 2 is true
for all k in the m-Segmentation of x. Assuming DDH is hard: The encryption
scheme is CPA secure (lemma 1) and bulletproof is zero knowledge range proof
([13] Definition 13).

4 Atomic Cross-Chain Swap Protocol

4.1 Background

Without many exceptions, all blockchains today are using a digital signature
algorithm that has an existing variant for threshold signing. Most dominant are
ECDSA and Schnorr based signatures (including EdDSA) [11,34,20,23,35,37,22].
In add";"""date"",""2020-09-30T04:42:24Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2020-09-30T04:42:24Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016) kpathsea version 6.2.2""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2020-09-30T04:42:24Z""
""created"",""2020-09-30T04:42:24Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-09-30T04:42:24Z""
""resourceName"",""2007.14423""
""Author"",""""
""producer"",""pdfTeX-1.40.17""
""pdf:docinfo:producer"",""pdfTeX-1.40.17""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""2"",""1"",""0"",""4"",""0"",""2"",""9"",""0"",""1"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""14""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2020-09-30T04:42:24Z""
""Last-Modified"",""2020-09-30T04:42:24Z""
""dcterms:modified"",""2020-09-30T04:42:24Z""
""title"",""""
""Last-Save-Date"",""2020-09-30T04:42:24Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2020-09-30T04:42:24Z""
""meta:save-date"",""2020-09-30T04:42:24Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016) kpathsea version 6.2.2""
""Content-Length"",""711693""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""23""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""2025"",""2838"",""2549"",""2554"",""2405"",""2540"",""2037"",""1750"",""1660"",""656"",""2538"",""2529"",""2186"",""1948"",""474"",""369"",""2338"",""2543"",""2486"",""2149"",""2901"",""2770"",""1582""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-09-30T04:42:24Z""
";https://scholar.google.ch/scholar?start=760&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098738-49;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Simulation tools for analyzing business processes;A Dzurak, L Morello, M Laucht, A Mitson ; Natural Sciences …, 2020  scholarchain.eu;;"… and blockchain. 2017. [23] Sadiq Shazia Wasim, Governatori Guido, Namiri Kioumars. Modeling

Control Objectives for Business Pro-cess Compliance. In: Lecture Notes in Computer Science,

vol. 4714: :149–164Springer; 2007. [24] Buterin V. Ethereum and Oracles, https://blog …";Autres articles;;null;;;;https://scholar.google.ch/scholar?start=590&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098835-265;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;[PDF][PDF] The Scope of Artificial Intelligence Manipulation on Social Media: Rising Privacy Concerns;V Singh ; Redesigning and Reimagining Libraries in New …  researchgate.net;;"… wired. com/story/wired-guide-personal-data- collection/. 2 Oracle, Transformational Technologies:

Today: How IoT, AI and blockchain will revolutionise the business, ORACLE (2018), http://www.

oracle. com/us/solutions/cloud/tt-technologies- white-paper-4498079. pdf …";Les 2 versions;Version HTML;[PDF] researchgate.net;https://www.researchgate.net/profile/Sunusi_Hussaini2/publication/348480692_Redesigning_and_Reimagining_Libraries_in_New_Technological_Era/links/60009dce92851c13fe0e0581/Redesigning-and-Reimagining-Libraries-in-New-Technological-Era.pdf#page=313;;;https://scholar.google.ch/scholar?start=810&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098787-157;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Model Checking Bitcoin and other Proof-of-Work Consensus Protocols;M DiGiacomo;Castillo, Y Liang, A Pal…  … on Blockchain  …, 2020  ieeexplore.ieee.org;;"… All parties are allowed the same number of queries to a PoW oracle, for the PoW … This causes

a change in both the parameter f and the behavior of the cryptocurrency within the backbone … Still,

their rational attacker model does not account for incentives outside of blockchain …";Autres articles;;[PDF] arxiv.org;https://arxiv.org/pdf/2007.08644;"
Model Checking Bitcoin and other Proof-of-Work Consensus Protocols

Max DiGiacomo-Castillo∗, Yiyun Liang†, Advay Pal ‡, John C. Mitchell §

Department of Computer Science, Stanford University
Email: ∗maxdigi@stanford.edu, †isaliang@stanford.edu, ‡advaypal@stanford.edu, §jcm@stanford.edu

Abstract—The Bitcoin Backbone Protocol [GKL15] is
an abstraction of the bitcoin proof-of-work consensus
protocol. We use a model-checking tool (UPPAAL-
SMC) to examine the concrete security of proof-of-
work consensus by varying protocol parameters and
using an adversary that leverages the selfish mining
strategy introduced in [GKL15]. We provide insights
into modeling proof-of-work protocols and demon-
strate tradeoffs between operating parameters. Apply-
ing this methodology to protocol design options, we
show that the uniform tie-breaking rule from [ES18]
decreases the failure rate of the chain quality property,
but increases the failure rate of the common prefix
property. This tradeoff illustrates how design decisions
affect protocol properties, within a range of concrete
operating conditions, in a manner that is not evident
from prior asymptotic analysis.

1. Introduction

Bitcoin is widely used, with a current market
capitalization of over 120 billion USD. Given the
massive level of economic activity and the potential
for future growth, it is natural to ask: how confident
can we be in the security and reliability of this
system and its variants? While practical experience
suggests that Bitcoin and related systems are robust
against various kinds of misuse, their security rest
on a combination of features whose interactions are
not fully understood. For example, could advances
in computing change the balance of power between
honest miners and adversaries?

Initial studies of blockchain security [GKL15;
LG20] have proved some fundamental relationships
involving security parameters and the probabilities of

desired properties. In this paper, we develop a formal
model based on the Bitcoin Backbone Protocol
abstraction [GKL15] and use a statistical model
checking tool (UPPAAL-SMC) to study its security.
We focus on how the properties of the backbone
protocol vary as a function of concrete parameters,
in a network where an adversary is capable of selfish
mining (delaying the release of malicious blocks).

The main contributions of this paper are:

• We demonstrate a way to model the backbone pro-
tocol in the presence of a selfish-mining adversary.

• We quantitatively analyze a concrete trade-off
between different security properties, based on how
honest miners act on receiving new blocks.

• We demonstrate how the failure rate of the back-
bone properties vary with different values of f ,
where f is the probability that at least one honest
party mines a block in a round, a parameter that
is different for different cryptocurrencies.

The paper is divided into the following sections.
In Section 2, we provide an overview of the Bit-
coin Backbone Protocol, which is the basis for our
UPPAAL-SMC model. In Section 3 we describe
how we model the backbone protocol using the
tool. In Section 4 we describe our results. Finally,
Section 5 provides an overview of related work,
Section 6 outlines potential future work, and Section
7 concludes.

2. Overview of the Backbone Protocol

The Bitcoin Backbone Protocol was introduced
in [GKL15] and subsequently improved in [GKL16;

ar
X

iv
:2

00
7.

08
64

4v
1 

 [
cs

.C
R

] 
 1

6 
Ju

l 2
02

0



LG20]. The aim of the backbone protocol is to
analyze the core mechanisms of proof-of-work con-
sensus protocols and provide more detailed secu-
rity guarantees than those provided by Nakamoto’s
whitepaper [Nak08]. The protocol captures key ele-
ments of Bitcoin and related Proof-of-Work (PoW)
consensus protocols that are use in other blockchains.

The protocol represents time as a series of
discrete rounds, each short enough so that the prob-
ability of any party completing the work needed to
write a new block is low. Each round proceeds as
follows:

1) Start: Each miner starts the round with a pre-
ferred current chain.

2) Check: Each miner begins the round by check-
ing for new chains.

3) Adopt: Each honest miner adopts the best chain
visible to it, using a selection criteria that is
defined by the blockchain.

4) Mine: Each miner queries a cryptographic hash
function. If they probabilistically succeed with
proof of work in this round, they append a block
to their chain.

5) Broadcast: Any miner that modifies its local
chain will broadcast its new chain to other
parties.

In modeling the backbone protocol, a party may
be designated as honest or adversarial. Honest parties
will immediately share blocks they find, and select
their chain based on the protocol’s designated chain
selection algorithm. They will not deviate from the
steps outlined above.

The protocol adversary represents a possible
coalition of malicious miners. The adversary is there-
fore able to query the cryptographic hash function
and produce blocks, with a success probability per
round that may differ from a single honest miner.
In addition, a possible network advantage of the
adversary is represented by allowing the adversary
to inject messages into any miner’s input channel
and reorder any input channel at will.1 The adversary
can also select a preferred chain arbitrarily (rather

1. We use ”input channel” to mean the same thing as ”RE-
CEIVE()” from [GKL15].

than using the honest selection criteria given in step
3 above) and withhold blocks in order to transmit
them at a later round.

In [GKL15], the authors make certain assump-
tions about the system:

• The protocol is executed by a fixed number of
parties n.

• Parties do not know the source of messages.
• All messages are delivered by the end of a round.2

• All parties involved are allowed the same number
of queries to a cryptographic hash function, for the
PoW computation.

The protocol parameters from [GKL15] that are
relevant to our work are shown in Figure 1; the
reader may consult [GKL15] for further detail.

Îť: security parameter
n: number of parties
t: number of parties controlled by the adversary
f : probability at least one honest party finds a PoW in a round
Îľ: concentration of random variables in typical executions
Âľ: proportion of blocks in honest chains that were mined by honest parties
k: number of blocks for common prefix
`: number of blocks for chain quality
s: rounds for chain growth property
τ : chain growth parameter

Figure 1: Positive integers n, t, s, `, k; positive reals
f, ε, µ, τ, λ, with f, ε, µ ∈ (0, 1).

If the modeling assumptions listed above hold
and the majority of parties are honest, the behavior
of the protocol can be described using the concept
of typical execution, introduced in [GKL15]. By
definition, a typical execution is a sequence of rounds
in which the random variables are close to their
expected values. A straightforward calculation shows
that a typical execution occurs with probability 1−
e−Ω(ε2λf).

The desired properties of the backbone protocol
are:

• Chain Quality: Chain quality is the proportion of
honest blocks in the chain of an honest participant.
A subsection of ` blocks in a honest chain will
have at least Âľ` blocks that were mined by honest
parties. Note that ` ≥ 2λf for provable security.

2. This assumption is for the synchronous model of [GKL15].



• Common Prefix: The common prefix property holds
if honest parties that prune k blocks from their
chain share a common view with another honest
party. In a typical execution the common prefix
holds for k ≥ 2λf.

• Chain Growth: The chain growth property mea-
sures how quickly the chains of honest parties grow.
Given that τ = (1 - ε)f, honest chains grow at least
as fast as τ · s in a typical execution. Note that s
≥ λ.

The authors of [GKL15] show that if these
properties hold, then persistence and liveness, which
are crucial to the robustness of the system, also hold.
Persistence states that once a transaction reported
by an honest party becomes ‘deep enough’ in a
blockchain, it is present in the chain of every other
honest party at the same position. Liveness states
that any transaction that comes from an honest party,
and is provided to all other honest parties, will be
inserted into all honest ledgers. The authors note that
persistence and liveness are not proof that Bitcoin
meets all of its objectives, as the analysis assumes
the number of parties is fixed and there is an honest
majority.

[GKL15] also provides a similar analysis for a
network setting which is not highly synchronous,
meaning there is an upper bound on the amount of
rounds a message takes to be delivered. We omit a
discussion of this because it is beyond the scope of
our study, but extending our analysis to this model
remains a potential direction for future work.

3. Modeling the Backbone Protocol

In this section we introduce our model checking
formalism of the backbone protocol. We first define
the following for each participant in the protocol:

• Input channel: Chains from other participants will
be sent to a participant’s input channel.

• Output channel: When a participant successfully
mines a block, it sends its newly mined block to
its output channel, to be broadcasted to the rest of
the network.

Algorithm 2: Honest Mining
Input: Honest miner m
check input channel and update bestBlock[m]
if Mining success then

create newBlock
publish newBlock with newBlock 7→ bestBlock[m]
set bestBlock[m] = newBlock

Algorithm 3: Adversarial Mining
Input: Adversarial miner a
decide strategy and update arbitraryBlock[a]
if advMiningSuccess then

create badBlock 7→ arbitraryBlock[a]
publish badBlock or keep private

route published and private blocks to honest miners, at will

We now present how honest and adversarial
participants are modeled in the protocol. Honest
participants are modeled by Algorithm 2 (above),
and the adversary is modeled by Algorithm 3 (above).

As shown in Algorithm 2, bestBlock is a global
array that stores the head of each miner’s blockchain.
At the beginning of each round, an honest miner
checks its input channel, checking its local chain
against any chains published in the network. The
miner then attempts to mine a block. If mining was
successful, a new block will be created and published
to the rest of the network. The miner will also update
its local blockchain by appending its newly-mined
block.

In contrast to Algorithm 2, Algorithm 3 allows
an adversarial miner to decide the best strategy to
use in the current round, and keep blocks private 3.

In the first execution round, everyone adopts
the genesis block. In all subsequent rounds, honest
participants select their block by referring to their
input channels. The adversary may select their block
arbitrarily.

Figure 2 shows how the input and output channels
are updated at each round. Assume A, B, and C are
honest miners and A successfully mined a block in
the most recent round. Participant A will send its
block to its output channel. The block is then sent
to the input channel of all other participants on the
network. In the following round, the honest parties

3. Private blocks are not broadcasted to other miners.



Figure 2: Participant A broadcasts a block

Figure 3: Example of an adversary reorganizing an
input channel. BH is a block mined by an honest
party and BA was mined by the adversary.

will check their input channels and use a selection
algorithm to determine whether to adopt A’s block.

In the presence of an adversary, input channels
can be manipulated. The adversary can standby until
all honest parties have completed mining. This allows
the adversary to maximize the amount of information
they can account for when deciding their propagation
strategy.

When all honest miners have completed a round,
the adversary checks each participant’s output chan-
nel for blocks and set the order of blocks on each
honest input channel (Figure 3). By default, honest
parties will adopt the first chain they receive when
encountering chains of equal length. This allows the
adversary to rearrange input channels to win head-
to-head ties. The adversary also decides whether or
not to share blocks they have mined with honest
participants.

At the end of this process, the output channels
of each participant will include any blocks not sent
to the input channels by the adversary, but mined by
honest participants in the most recent round. At this

point all parties have attempted to solve the PoW,
and been informed of all blocks found in the most
recent round. The participants continue the process
above for a finite-amount of rounds.

3.1. Differences from Backbone Protocol

We now review the key ways that our UPPAAL-
SMC model differs from the backbone protocol.
• Parties: We model the adversary as one party. The

adversary has a mining power of Îą and the honest
parties collectively have a mining power of (1-Îą).
This is equivalent to [GKL15], where the adversary
controls a subset of honest parties.

• Transactions: We omit the inclusion of transactions
in blocks. This does not affect the outcome of the
backbone properties.

• Mining: Our mining process relies on probabilistic
transitions to either a success or failure state. This
avoids modeling hash functions. Our work does
not account for honest mining pools or a single
party mining multiple blocks in one round.

• Message Propagation: We assume that all messages
will be delivered at the end of a round. This means
no blocks are sent or received during the mining
phase of a round.

• Non-Determinism: Whereas the Bitcoin Backbone
Protocol quantifies over all possible adversaries,
we only model a selfish mining adversary. This
is because UPPAAL-SMC does not handle non-
determinism.

4. Results and Analysis

We now introduce the results we obtained.
UPPAAL-SMC simulates many runs of our system,
and then computes the probability of a property
holding. We use a 95% confidence interval. This
means that 95% of the time the true probability of a
failure event is within Âą0.05 of the value computed.

4.1. Fork Resolution Rules

In Bitcoin, when honest miners receive multiple
longest chains, they adopt the one they received first.



40 70 100 130 160
0

0.2

0.4

0.6

0.8

1

Blocks for chain quality (`)

Fa
ilu

re
R

at
e

Uniform Tie Breaking
First-Received Rule

Figure 4: Failure rate of chain quality given two fork
resolution rules

We refer to this fork resolution rule as the “First-
Received Rule”. Under the first-received rule, a well
connected adversary can gain a large advantage. If
they are able to route their blocks quickly, more
parties will adopt their chain. The assumption in
[GKL15] is that all honest participants, except for
one, will adopt the adversary’s preferred block in
the case of a fork. We also make this assumption.

We begin by testing uniform tie breaking, an
alternative where an honest party adopts one longest
chain at random. This modification can limit the
network advantage that an adversary can obtain. No
matter the adversary’s propagation strategy, uniform
tie breaking will cause about 50% of parties to adopt
the block preferred by the adversary.

For each resolution rule, we use our model to
measure the probability of each backbone property
failing. For the following experiments, we let n =

8, Îą = 0.33, f = 0.02, and Âľ = 0.39. Like [GKL15],
we assume f ≈ 0.02 for Bitcoin.

In agreement with [SSZ15], we find that the fail-
ure rate of the chain quality property is consistently
lower when uniform tie breaking is used (Figure
4). Still, the failure rate under both resolution rules
decreases towards zero for large `. Large ` means a
longer subsection of blocks is checked against the
chain quality property, and prevents the adversary
from breaking the property by mining more blocks
than expected over a short time period.

We extend the work of [SSZ15] and test uniform

4 6 8 10
0

0.2

0.4

0.6

0.8

1

Blocks for common prefix (k)

Fa
ilu

re
R

at
e

Uniform Tie Breaking
First-Received Rule

Figure 5: Failure rate of common prefix given two
fork resolution rules

50 100 150 200 250
0

0.2

0.4

0.6

0.8

1

Expected blocks (τ · s)

Fa
ilu

re
R

at
e

Uniform Tie Breaking
First-Received Rule

Figure 6: Failure rate of chain growth given two fork
resolution rules

tie breaking against the common prefix and chain
growth properties. Our results show that uniform tie
breaking, assuming the adversary follows the selfish
mining strategy we implemented, has a negative
impact on the common prefix of honest blockchains
(Figure 5).

Under uniform tie breaking, the selfish mining
strategy from [GKL15] is similar to the common pre-
fix attack described in [KP15]. Because uniform tie
breaking roughly splits the honest participants onto
two competing chains, our selfish mining attacker
produces long forks with higher probability. Forks
are caused when the adversary releases a private
block or two honest parties find a block in the same
round. The forks take longer to resolve, on average,
because the parties equally mine on each branch.



We believe this is a practical implementation
of a common prefix attack because it is not clear
how an adversary could consistently force honest
participants to equally mine on competing chains
otherwise. Given that blocks are spread using a
gossip protocol, equally dividing the network onto
different chains would be difficult.

In [KP15], the authors state that uniform tie
breaking would not help against their common prefix
attack. They did not realize the rule could make
long-forks attacks easier to execute. Our adversary
follows the selfish mining strategy from [GKL15]
and lets uniform tie breaking do the rest. This
suggests that protocol modifications to Bitcoin may
have unintended consequences when only measured
against one property of the backbone.

The chain growth property is also used to com-
pare each resolution rule. We find that over long
periods the difference in performance between the
two fork resolution rules with respect to chain growth
is negligible (Figure 6).

4.2. Calibrating f for security and speed

Recall that f is the probability that at least one
honest party finds a PoW solution in a round. The
importance of calibrating f is made clear by Garay
et al [GKL15]. If the PoW puzzle is too difficult (f is
too small) then chain growth suffers. Too few blocks
are produced by honest parties, so liveness is hurt.
If the PoW puzzle is too easy (f is too large), then
the common prefix suffers. There are not enough
rounds where only one party finds a PoW solution,
so persistence suffers.

Fluctuations in f can be caused by variations in
the network’s hash rate or propagation speed. To keep
f in a small range, Bitcoin applies a PoW difficulty
adjustment every 2016 blocks. The difficulty of PoW
is increased or decreased depending on the network’s
hash rate. If the hash rate increases, then more blocks
are produced within a round (f increases). If the hash
rate decreases, then less blocks are produced within
a round (f decreases). Bitcoin adjusts its difficulty
so that blocks, on average, are produced every 10

minutes. Assuming a full round of propagation takes
up to 20 seconds, adjustments keep f between 2-3%
[GKL15]. Note that this only accounts for changes
in the network’s hash rate.

40 80 120 160 200 240 280
0

0.2

0.4

0.6

0.8

1

`

Fa
ilu

re
R

at
e

f = 0.01
f = 0.08
f = 0.15
f = 0.30
f = 0.50
f = 0.80

Figure 7: Failure rate of chain quality for various f

2 4 6 8 10 12
0

0.2

0.4

0.6

0.8

1

k

Fa
ilu

re
R

at
e

f = 0.01
f = 0.08
f = 0.15
f = 0.23
f = 0.30
f = 0.39
f = 0.48
f = 0.60

Figure 8: Failure rate of common prefix for various
f

Changes in block propagation speed are not
considered. Since a round is a period of complete
block propagation, f is subject to change when
network speeds change. In Bitcoin, block propagation
speeds have rapidly increased over the last few years
[Neu20]. For example, the time for a block to reach
99% of nodes has decreased from 11 seconds to 2
seconds.4 It follows that f , a key parameter, has de-
creased as well. Because f can change unexpectedly,

4. Over the period from 2017 to 2020.



2 3 4 5 6 7 8 9 10
0.25

0.5
0.75

0

0.5

1

k
f

Fa
ilu

re
R

at
e

Figure 9: Overview of parameter space for common
prefix property

measuring a cryptocurrency’s behavior over a range
of f values is important.

For the following experiments, we let n = 8, Îą =

0.33, and Âľ = 0.39. Over a range of f values, we
find that Bitcoin has very different security properties.
For smaller values of f , the failure rate of the chain
quality and common prefix properties converge faster
(Figures 7, 8, 9). When the failure rate of chain
quality converges faster, then we can look at a
shorter length of blocks and be confident there are Âľ`
honest blocks. When the common prefix converges
faster, we can wait for less block confirmations and
be confident that double spending will not occur.
While these behaviors help with security, they do not
help with transaction processing speed. To improve
transaction processing speed, a cryptocurrency must
increase its block generation rate [KP15].

Decreasing block generation times provide an
opportunity for increased transaction throughput. If
a cryptocurrency can improve its block propagation
speed enough, then the block generation rate can be
decreased such that f stays constant. The behavior
of the chain quality and common prefix properties
will be the same, but blocks and transactions will
be produced more rapidly.

In the case of Bitcoin, this raises a question:
should cryptocurrencies aim for idealogical or secu-
rity based consistency? While Bitcoin block genera-
tion rate is kept at 10 minutes, this does not guarantee

consistency from the backbone perspective. Bitcoin,
from the perspective of the backbone protocol, has
changed greatly over the last few years.

5. Related Work

[Cha+15] and [FC18] use UPPAAL SMC to
model Bitcoin, but do not build off the backbone pro-
tocol. [Cha+15] analyzes double spending, whereas
[FC18] analyzes an Andresen attack. Neither model
chain quality or chain growth.

[Ger+16] provide a framework for modeling
the security of PoW blockchains using a Markov
Decision Process. They also show that selfish mining
is not always a rational strategy. Still, their rational
attacker model does not account for incentives out-
side of blockchain. For example, an attacker may
lose bitcoin during an attack, but have a payoff in
USD. 5

In [SSZ15] the authors measure the effects of
uniform tie breaking on the profit threshold for
selfish mining. By looking at the revenue of the
adversary, [SSZ15] implicitly measures the chain
quality property from [GKL15]. Their results showed
that uniform tie breaking limited the power of
strongly communicating attackers, but enhanced the
power of poorly communicating attackers. Still, no
work was done to directly measure the effects of
this modification on the common prefix and chain
growth properties.

6. Future Work

Some avenues for future work are:

• Other adversarial strategies: Our model can be
used to model other adversarial strategies, besides
selfish mining.

• Delay-bounded model: Our model can be ex-
tended to the delay-bounded version of the back-
bone protocol, where rounds are not highly syn-
chronous, but there is a bound on the time it takes
for messages to be delivered.

5. Through financial derivatives or increased market share.



• Honest Mining Pools: Our work assumes all
honest parties have the same hashing capabilities.
In reality, different parties and pools have different
hashing capabilities. Future work could account for
this. This would capture the importance of certain
parties in terms of block propagation. For example,
it would be more beneficial for a selfish miner to
quickly relay his block to a large mining pool than
to a single miner with a negligible percentage of
the total hash rate

7. Conclusion

This paper presents a case-study of model check-
ing PoW cryptocurrencies using the Bitcoin Back-
bone Protocol as a foundation. We show how to
model the protocol using Statistical Model Checking
tools, and identify concrete security properties of
the protocol. We use the model to demonstrate
how design decisions can impact different concrete
backbone protocol properties in different ways, in
a manner that is not obvious from prior asymptotic
analysis.

This paper attempts to explain the value of
applying the foundation introduced by [GKL15]
to practice. The experiments above map out the
effectiveness of a selfish mining strategy against
various deployment parameters. By doing this, we
are able to derive results that lay a direction for
further work in the design and analysis of PoW
protocols.

8. Acknowledgments

The authors thank Marco Patrignani (Stanford
University) and Avradip Mandal, Hart Montgomery,
Arnab Roy (Fujitsu Laboratories of America Inc.) for
their assistance and insight in formulating the ideas
underlying our model and results. The authors thank
the Office of Naval Research for support through
grant N00014-18-1-2620, Accountable Protocol Cus
tomization.

References

[Nak08] Satoshi Nakamoto. Bitcoin: A Peer-to-
Peer Electronic Cash System. Dec. 2008.
URL: https://bitcoin.org/bitcoin.pdf.

[Cha+15] Kaylash Chaudhary et al. “Modeling
and Verification of the Bitcoin Protocol”.
In: Electronic Proceedings in Theoreti-
cal Computer Science 196 (Nov. 2015),
pp. 46–60.

[GKL15] Juan Garay, Aggelos Kiayias, and Nikos
Leonardos. “The Bitcoin Backbone Pro-
tocol: Analysis and Applications”. In:
Advances in Cryptology - EUROCRYPT
2015. Lecture Notes in Computer Sci-
ence. Springer, 2015, pp. 281–310.

[KP15] Aggelos Kiayias and Giorgos Pana-
giotakos. “Speed-Security Tradeoffs in
Blockchain Protocols”. In: IACR Cryptol-
ogy ePrint Archive 2015 (2015), p. 1019.

[SSZ15] Ayelet Sapirshtein, Yonatan Sompolin-
sky, and Aviv Zohar. “Optimal Selfish
Mining Strategies in Bitcoin”. In: Finan-
cial Cryptography. 2015.

[GKL16] Juan A. Garay, Aggelos Kiayias, and
Nikos Leonardos. “The Bitcoin Back-
bone Protocol with Chains of Variable
Difficulty.” In: IACR Cryptology ePrint
Archive (2016), p. 1048.

[Ger+16] Arthur Gervais et al. “On the se-
curity and performance of proof of
work blockchains”. In: Proceedings of
the 2016 ACM SIGSAC conference on
computer and communications security.
2016, pp. 3–16.

[ES18] Ittay Eyal and Emin Gün Sirer. “Ma-
jority is not enough: bitcoin mining is
vulnerable”. In: Communications of the
ACM 61.7 (June 2018), pp. 95–102.

[FC18] Ansgar Fehnker and Kaylash Chaudhary.
“Twenty Percent and a Few Days – Op-
timising a Bitcoin Majority Attack”. In:
NASA Formal Methods. Springer Inter-
national Publishing, 2018, pp. 157–163.

https://bitcoin.org/bitcoin.pdf


[LG20] Jing Li and Dongning Guo. “Continuous-
Time Analysis of the Bitcoin and
Prism Backbone Protocols”. In:
arXiv:2001.05644 [cs] (Jan. 2020).

[Neu20] Till and Neudecker. DSN Bitcoin Mon-
itoring. 2020. URL: https://dsn.tm.kit.
edu/bitcoin/index.html.

https://dsn.tm.kit.edu/bitcoin/index.html
https://dsn.tm.kit.edu/bitcoin/index.html


9. Modeling the Bitcoin Backbone Pro-
tocol in UPPAAL

In this section, we provide details on how
we modeled the Bitcoin Backbone Protocol with
UPPAAL-SMC.

9.1. Global Declarations

To model the backbone protocol, we designed
three custom data structures: Block, Global Ledger,
and Diffusion.

Declaration 4: Block
typedef struct {

int[0, node max] id;
int[0, total run time] rd;
int parent;
int block num;
int length;
bool sent to[node max];
int[0, 1] is private;
int num adv blocks;
} Block;

Declaration 5: Global Ledger
typedef struct {

Block blockchain[block max];
int best block[node max];
int max len;
} Global Ledger;

Declaration 6: Diffusion
typedef struct {

int receive[node max][node max];
int receive len[node max];
int to be diffused[node max];
int[0, node max] to be diffused len;
} Diffusion;

Declaration 4 shows the structure of a block in
our model. Each block has an unique identifier, a

round number (indicating the round it was created
in), a parent id that indicates the previous block in
the chain, and a block number indicating the number
of blocks ever created at the time of its creation.
Each block also stores information such as its depth
from the genesis block, an array of participants that
the block was sent to, a flag indicating whether it is
held private, and the number of blocks created by
adversaries in its chain.

Declaration 5 shows the structure of the global
blockchain ledger. Global ledger keeps track of
every block created in the network with blockchain[].
Miners maintain their local chain by pointing to a
block in best block[]. Finally, max len tracks the
length of the longest chain(s) in the network.

Declaration 6 shows the structure of the diffusion
model. Diffusion models the diffusion functionality
used in the backbone protocol. A 2D array, mimick-
ing the RECEIVE() tape from the backbone, is used
to keep track of block propagation.

9.2. Honest and Adversarial Parties

As shown in in Figure 10 and Figure 11, we
modeled honest parties and the adversary separately.
Each state diagram consists of five non-trivial states:

1) Start: the start state of each round
2) End: the end state of each round
3) Protocol Failure: indicates a failure of one of

the backbone properties
4) No Block: indicates a party’s mining outcome

is unsuccessful
5) Found Block: indicates a party’s mining out-

come is successful

Each round begins at the start state and ends at
the end of round state. The protocol failure state
represents a failure in the backbone protocol. The
no block and found block states correspond to a
miners PoW outcome in the current round.

We note features of the state diagrams:

• One or more backbone property is verified at
the end of each round. In this example, the
expression check common prefix will force



a miner to enter the failure state when the
common prefix is broken.

• The probability that at least one honest party
succeeds in finding a PoW solution in a round
(f ), is captured with probabilistic edges. A
weight assigned to each edge is used to vary f .

• The synchronization channels mine! and mine?
prevent miners from starting a new round before
everyone has finished the previous round.

Figure 10: An honest party’s state diagram

Figure 11: The adversary’s state diagram

9.3. Property Checking Algorithms

At the end of each round, we check each honest
chain against one or more of the backbone properties.
If a party’s chain does not satisfy the backbone
property, the party enters the failure state of the
model. UPPAAL will terminate and consider this
run a failure.

We illustrate how property is checked:

• Common Prefix: Common prefix checks that
the block k deep in an honest chain is in every
other honest chain. This search is pruned by ig-
noring parties that point to the same best block.
This means they have identical chains.

• Chain Quality: Chain quality is checked by
counting the blocks in honest chains that were
contributed by honest parties. The share of these
contributions over any set of ` blocks should
be at least Âľ`.

• Chain Growth: Chain growth is checked by
iterating over the blocks of an honest chain
until a block s rounds or older is found. Chain
growth is satisfied if at least τ · s blocks were
found in this time frame.

9.4. Selfish Mining

As shown in Table 6, each block has a data field
is private. Our adversary deterministically chooses
whether to keep their blocks private. There are two
cases:

1) If the adversary’s private chain is at least one
block ahead of the longest honest chain, it will
release one block from its private chain for
every honest block that is published.

2) When the adversary’s private branch is depleted,
it will return to mining on the public branch.


";"""date"",""2020-07-20T01:23:12Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2020-07-20T01:23:12Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016) kpathsea version 6.2.2""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2020-07-20T01:23:12Z""
""created"",""2020-07-20T01:23:12Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-07-20T01:23:12Z""
""resourceName"",""2007.08644""
""Author"",""""
""producer"",""pdfTeX-1.40.17""
""pdf:docinfo:producer"",""pdfTeX-1.40.17""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""9"",""3"",""0"",""3"",""1"",""1"",""0"",""0"",""0"",""2""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2020-07-20T01:23:12Z""
""Last-Modified"",""2020-07-20T01:23:12Z""
""dcterms:modified"",""2020-07-20T01:23:12Z""
""title"",""""
""Last-Save-Date"",""2020-07-20T01:23:12Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2020-07-20T01:23:12Z""
""meta:save-date"",""2020-07-20T01:23:12Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016) kpathsea version 6.2.2""
""Content-Length"",""394895""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""11""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""2918"",""3223"",""3164"",""2484"",""2332"",""2501"",""2712"",""2781"",""221"",""2300"",""1576""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-07-20T01:23:12Z""
";https://scholar.google.ch/scholar?start=700&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098734-33;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Appending Atomically in Byzantine Distributed Ledgers;V Cholvi, AF Anta, C Georgiou, N Nicolaou… ; arXiv preprint arXiv …, 2020  arxiv.org;;"… Although such a recent popular- ity is primarily due to the explosive growth of numerous

crypto-currencies, there are many … The weakest aspect of blockchain oracles is trust, since the

outcome or actions of a smart contract will be as reliable as the data provided by the oracle …";Autres articles;;[PDF] arxiv.org;https://arxiv.org/pdf/2002.11593;"
ar
X

iv
:2

00
2.

11
59

3v
1 

 [
cs

.D
C

] 
 2

6 
Fe

b 
20

20

Appending Atomically in

Byzantine Distributed Ledgers⋆

Vicent Cholvi1, Antonio Fernández Anta2, Chryssis Georgiou3,
Nicolas Nicolaou4, and Michel Raynal5,6

1 Universitat Jaume I, Spain
vcholvi@uji.es

2 IMDEA Networks Institute, Spain
antonio.fernandez@imdea.org
3 University of Cyprus, Cyprus

chryssis@cs.ucy.ac.cy
4 Algolysis Ltd, Cyprus
nicolas@algolysis.com

5 Univ. Rennes IRISA, France
michel.raynal@irisa.fr

6 Dept. of Computing, Polytechnic Univ., Hong Kong

Abstract. A Distributed Ledger Object (DLO) is a concurrent object
that maintains a totally ordered sequence of records, and supports two
basic operations: append, which appends a record at the end of the se-
quence, and get, which returns the sequence of records. In this work we
provide a proper formalization of a Byzantine-tolerant Distributed Ledger
Object (BDLO), which is a DLO in a distributed system in which pro-
cesses may deviate arbitrarily from their indented behavior, i.e. they may
be Byzantine. Our formal definition is accompanied by algorithms to im-
plement BDLOs by utilizing an underlying Byzantine Atomic Broadcast
service.
We then utilize the BDLO implementations to solve the Atomic Ap-
pends problem against Byzantine processes. The Atomic Appends prob-
lem emerges when several clients have records to append, the record of
each client has to be appended to a different BDLO, and it must be
guaranteed that either all records are appended or none. We present
distributed algorithms implementing solutions for the Atomic Appends
problem when the clients (which are involved in the appends) and the
servers (which maintain the BDLOs) may be Byzantine.

Keywords: Distributed Ledger Object ¡ Byzantine Faults ¡ Atomic Ap-
pends

⋆ This work was co-funded by the European Regional Development Fund and the
Republic of Cyprus through the Research Promotion Foundation (Project: POST-
DOC/0916/0090), by research funds from the University of Cyprus (CG-RA2020), by
the Spanish grant TIN2017-88749-R (DiscoEdge), the Region of Madrid EdgeData-
CM program (P2018/TCS-4499), the NSF of China grant 61520106005, and by the
Spanish Ministerio de Educación Cultura y Deporte under grant PRX18/00163.

http://arxiv.org/abs/2002.11593v1


2 V. Cholvi, A. Fernández Anta, C. Georgiou, N. Nicolaou, and M. Raynal

1 Introduction

There has been a great interest recently in the so-called crypto-technologies
(e.g., blockchain systems [18]), and distributed ledger technology (DLT) in gen-
eral [24], which are becoming very popular and are expected to have a high
impact in multiple aspects of our everyday life. Although such a recent popular-
ity is primarily due to the explosive growth of numerous crypto-currencies, there
are many applications of this core technology that are outside the financial in-
dustry. These applications arise from leveraging various useful features provided
by distributed ledgers, such as a decentralized information management, im-
mutable record keeping for possible audit trail, robustness, availability, security,
and privacy (see, for instance, [13,19,23,5]). However, there are many different
blockchain systems, and new ones are proposed almost everyday. Hence, it is
extremely unlikely that one single DLT or blockchain system will prevail. This
is forcing the DLT community to accept that it is inevitable to come up with
ways to make blockchains interconnect and interoperate.

In that direction, the work in [4] proposed a formal definition of a reliable con-
current object, termed Distributed Ledger Object (DLO), which tries to convey
the essential elements of blockchains. In particular, a DLO maintains a sequence
of records, and has only two operations, append and get. The append oper-
ation is used to add a new record at the end of the sequence, while the get

operation returns the sequence. Using the above-mentioned formalism, in [8] the
authors initiated the study of systems formed by multiple DLOs that interact
among each other. Namely, they defined the Atomic Appends problem, in which
several clients have records to append, the record of each client has to be ap-
pended to a different DLO, and it must be guaranteed that either all records are
appended or none. Consider, for example, two clients A and B where the one, say
A, buys a car from B. Record rA includes the transfer of the car’s digital deed
from B to A, and rB includes the transfer from A to B the agreed amount in
some digital currency c. DLOA is a ledger maintaining digital deeds and DLOB

maintains transactions in the digital currency c. So, while the two records are
mutually dependent, they concern different DLOs, hence the Atomic Append
problem requires that either record rA is appended in DLOA and record rB is
appended in DLOB or none of the records are appended in the corresponding
DLOs.

In [8] the clients were assumed to be selfish and rational [21], and could have
different incentives for the different outcomes. Additionally, it was assumed that
they could fail by crashing, which makes solving the problem more challenging.
The authors showed that for some cases the existence of an intermediary is
necessary for the problem solution, and proposed the implementation of such
intermediary over a specialized blockchain (termed Smart DLO, SDLO), also
showing how this can be used to solve the Atomic Appends problem even in
an asynchronous, client competitive environment, in which all the clients may
crash.



Appending Atomically in Byzantine Distributed Ledgers 3

Related Work: The Atomic Appends problem we describe above is very related
to the multi-party fair exchange problem [9], in which several parties exchange
commodities so that everyone gives an item away and receives an item in re-
turn. However, the proposed solutions for this problem rely on cryptographic
techniques [14,17] and are not designed for distributed ledgers.

Among the first problems identified involving the interconnection of
blockchains was the Atomic Cross-chain Swap [10], which can also be seen as a
version of the fair exchange problem. In this case, two or more users want to ex-
change assets (usually cryptocurrency) in multiple blockchains. Herlihy [10] has
formalized and generalized atomic cross-chain swaps beyond one-to-one paths,
and shows how multiple cross-chain swaps can be achieved if the transfers form
a strongly connected directed graph. Herlihy proves that the best strategy, in
Game Theoretic sense, for the users is to follow the proposed algorithm, and that
someone that follows it will never end up worst than at the start. Unfortunately,
these guarantees do not hold if the system is asynchronous.

Unlike in most blockchain systems, in Hyperledger Fabric [2,3] it is possible
to have transactions that span several blockchains (blockchains are called chan-
nels in Hyperledger Fabric). This allows solving the atomic cross-chain swap
problem using a third trusted channel or a mechanism similar to a two-phase
commit [3]. Additionally, these solutions do not require synchrony from the sys-
tem. The ability of channels to access each other’s state and interact is a very
interesting feature of Hyperledger Fabric, very in line with the techniques we as-
sume from advanced distributed ledgers in this paper. Unfortunately, they seem
to be limited to the channels of a given Hyperledger Fabric deployment.

There are other blockchain systems under development that, like Hyperledger
Fabric, will allow interactions between the different chains, presumably with
many more operations than atomic swaps. Examples are Cosmos [12] or PolkaDot
[22]. These systems will have their own multi-chain technology, so only chains in
a given deployment can initially interact, and other blockchain will be connected
via gateways.

The practical need of blockchain systems to access the outside world to re-
trieve data (e.g., exchange rates, bank account balances) has been solved with
the use of blockchain oracles. These are relatively reliable sources of data that can
be used inside a blockchain, typically in a smart contract. The weakest aspect of
blockchain oracles is trust, since the outcome or actions of a smart contract will
be as reliable as the data provided by the oracle. As of now, it seems there is
no good solution for this trust problem, and blockchains have to rely on oracle
services like Oraclize [20].

Contributions: Contrary to what was assumed in [4,8] (i.e., both clients and
servers can only fail by crashing), in existing blockchain systems, both the servers
(e.g., miners) and the clients (e.g., users) could be acting maliciously. To this
respect, in this work we present implementations where both the clients and the
servers can be Byzantine, i.e., we present implementations of Byzantine-tolerant
linearizable DLOs. Our contributions are as follows:



4 V. Cholvi, A. Fernández Anta, C. Georgiou, N. Nicolaou, and M. Raynal

– We provide a formalization of Byzantine-tolerant Distributed Ledger Objects
– BDLOs (Sect. 2).

– We present and prove the correctness of algorithms that implement a lin-
earizable BDLO (Sect. 3) in an asynchronous setting (enriched with a Byzan-
tine Atomic Braoadcast service) in which up to f servers can fail, and
(i) an unbounded number of clients can fail (Sect. 3.1); or (ii) only a bounded
number t of clients can fail (Sect. 3.2). In the second case we can prevent
spurious records to be appended by malicious clients without the need of
any additional mechanism.

– We provide a definition of the Atomic Appends problem in a system with
Byzantine failures (Sect. 2).

– We present and prove how the above algorithms implementing BDLOs can
be combined and adapted to solve the Atomic Appends problem (Sect. 4).
(i) First, we build a Smart BDLO (SBDLO, first presented in [8] for toler-
ating crashes) to aggregate and coordinate the append of multiple records
(Sect. 4.1). The SBDLO is implemented with a set N of n ≥ 2t+ 1 servers
up to which at most t can fail. The BDLOs on which the Atomic Appends is
applied are implemented as BDLOs with a bounded number t of Byzantine
clients, so it is guaranteed that only if at least one correct process in N

appends in them, the append takes place.
(ii) Then, we show how the problem can be solved by replacing the SBDLO
with a “regular” BDLO and the use of a set N of at least 2t+1 “helper” pro-
cesses, of which at most t can fail (Sect. 4.2). These processes monitor (by
periodic get operations) the BDLO for new Atomic Appends operations.
Once matching Atomic Appends records are observed, the helper processes
perform the append operations to the corresponding BDLOs.

2 Model and Definitions

Distributed Ledger Objects: A Distributed Ledger Object (DLO) is a con-
current object that stores a totally ordered sequence of records (initially empty).
A DLO L supports two operations, L.append(r) and L.get(), which append a
new record r to the sequence and return the whole sequence, respectively [4]. A
record is a triple r = 〈τ, p, v〉, where p is the identifier of the process that created
record r, v is the data of the record drawn from an alphabet Σ, and τ is a unique
record identifier from a set T (e.g., the cryptographic hash of 〈p, v〉). The DLO
is implemented by a set of servers that collaborate running a distributed algo-
rithm. The DLO is used by a set of clients that access it by invoking append

and get operations, which are translated into request and response messages
exchanged with the servers. An execution is a sequence of invocation and re-
turn events, starting with an invocation event. An operation π is complete in
an execution ξ, if both the invocation and matching return of π appear in ξ.
We say that an operation π1 precedes an operation π2, or π2 succeeds π1, in an
execution ξ if the return event of π1 appears before the invocation event of π2 in
Ξ; otherwise the two operations are concurrent. In this work we focus on lineariz-
able DLOs [4]. Informally, under linearizability, the append and get operations



Appending Atomically in Byzantine Distributed Ledgers 5

appear as if they occur instantaneously, which yields a total order among them.
This order must respect real-time ordering, and be consistent with the semantics
of operations: no get() preceding append(r) returns a sequence with r, and all
get operations that succeed append(r) do. By default any client can append
records or access the state of a DLO with get. However, if convenient, we may
assume that the set of clients that can issue (append and get) operations is
restricted. For instance, we assume that only the creator r.p of a record r can
append the record in a DLO L, or restrict append operations to a predefined
set of clients N .

Failure Model: In this work we assume that processes (servers and clients)
can fail arbitrarily, i.e., we assume that failures are Byzantine. Specifically, we
assume a Byzantine system in which up to f servers can fail arbitrarily and
that the total number of servers is at least 3f + 1. For clients we consider two
cases: (i) any number of clients can be Byzantine; (ii) up to t clients can be
Byzantine. We assume that each process p (client or server) has a pair of public
and private keys, and a cryptographic certificate containing its public key. These
certificates are generated by a reliable authority, so we discard the possibility
of spurious or fake processes (there cannot be Sybil attacks), and have been
distributed to all the processes that may interact with each other. Hence, we also
assume that the messages sent by any process (server or client) are authenticated,
so that messages corrupted or fabricated by Byzantine processes are detected
and discarded by correct processes [7]. Communication channels between correct
processes are reliable but asynchronous.

Byzantine-tolerant DLO: The first aim of this paper is to propose algorithms
that implement a linearizable DLO L in Byzantine systems. Since Byzantine
clients and servers can behave arbitrarily, we define the properties that a DLO
must satisfy adapted to Byzantine systems. In particular, since Byzantine pro-
cesses may return any arbitrary sequence or append any record, the properties
only consider the actions of correct processes.

– Byzantine Completeness (BC): All the get and append operations invoked
by correct clients eventually complete.

– Byzantine Strong Prefix (BSP): If two correct clients issue two L.get() op-
erations that return record sequences S and S′ respectively, then either S is
a prefix of S′ or vice-versa.

– Byzantine Linearizability (BL): Let G be the set of all complete get op-
erations issued by correct clients. Let A be the set of complete append

operations L.append(r) such that r ∈ S and S is the sequence returned by
some operation L.get() ∈ G. Then linerizability holds with respect to the
set of operations G∪A. This property is similar to the one described in [16]
for registers.

In the remainder we say that a DLO is Byzantine Tolerant if it satisfies the
properties BC, BSP, and BL in a Byzantine system. We will be referring to a
Byzantine-tolerant DLO by BDLO.



6 V. Cholvi, A. Fernández Anta, C. Georgiou, N. Nicolaou, and M. Raynal

Observe that it is possible that some append operations issued by Byzan-
tine processes might not be distinguished by correct processes. To this respect,
we consider the notion of effective appends. To add a record r to a BDLO, a
Byzantine process pk can invoke append(r), in which case it behaves as if it
was correct. It can also attempt to add a record to the BDLO without explicitly
invoking an append(). To this end, it can send underlying messages which, from
the point of view of the correct processes, simulate an invocation of append(r).
It can also intertwine several such insertion of records to the BDLO. Such at-
tempts to add records, without invoking the operation append() may or not
succeed. We say that such an attempt constitutes an effective append if no cor-
rect process can distinguish it from a correct invocation of append(). Hence an
effective append adds a record to the BDLO. We study this issue in Section 3.

Multiple DLOs (MDLO) and Multiple BDLOs (MBDLO): A Multi-
Distributed Ledger Object M, termed MDLO, consists of a collection D of
(heterogeneous linearizable) DLOs and supports the following operations: (i)
M.getp(L), and (ii) M.appendp(L, r) [8]. The get operation returns the se-
quence of records L.S, where L ∈ D. Similarly, the append operation appends
the record r to the end of the sequence L.S, where L ∈ D. From the locality
property of linearizability [11] it follows that a MDLO is linearizable, if it is
composed of linearizable DLOs. Multiple BDLOs, termed MBDLO, are defined
similarly over a collection of BDLOs (i.e., Byzantine-tolerant DLOs)7.

The Atomic Appends Problem: Following [8], we define the Atomic Appends
problem, termed AtomicAppends, that captures the properties we need to sat-
isfy when multiple operations attempt to append dependent records on different
BDLOs of an MBDLO. Intuitively, AtomicAppends is analogous to the atomic
cross-chain swap [10] in a MBDLO. In the crash failure model considered in [8],
informally AtomicAppends requires that either all records will be appended on
the involved BDLOs or none. However, in the Byzantine failures model it is
impossible from preventing a faulty client to append its record without coordi-
nation with the rest of clients. Hence, the Atomic Appends problem has to be
redefined for this failure model.

We say that a record r depends on a record r′, if r may be appended on its
intended BDLO, say L, only if r′ is appended on a BDLO, say L′. Two records,
r and r′, are mutually dependent, if r depends on r′ and r′ depends on r.

Definition 1 (2-AtomicAppends). Consider two clients, p and q, with mu-
tually dependent records rp and rq. We say that records rp and rq are appended
atomically in BDLO Lp and BDLO Lq, respectively, when:

– AA-safety (AAS): The record (say rp wlog) of a correct client (p) is appended
(in Lp) only if the record of the other client (q, which may be correct or not)
is also appended (in Lq).

7 Note that we do not restrict whether the BDLOs in the MBDLO are implemented
by common servers, or each BDLO is implemented by different servers, as long as
the total number of servers and the bound on how many can fail is respected.



Appending Atomically in Byzantine Distributed Ledgers 7

– AA-liveness (AAL): If both p and q are correct, then both records are ap-
pended eventually.

As mentioned above, it is not possible to prevent a faulty client q from ap-
pending its record rq even if the correct client p does not. What the safety
property AAS guarantees is that the opposite cannot happen. This is analogous
of the property in atomic cross-chain swaps [10] that a correct process cannot
end up worse than at the beginning. For instance, when the records represent
the transfer of assets between p and q, if a faulty client appends its record it is
transferring its asset possibly without receiving anything in exchange.

An algorithm solves the 2-AtomicAppends problem under a given system, if
it guarantees the safety and liveness properties AAS and AAL of Definition 1 in
every execution of the system. Since we consider Byzantine failures, our system
model with respect to the Atomic Appends problem is such that the correct
processes want to proceed with the append of the records (to guarantee liveness
AAL), while the Byzantine processes may try to get correct clients to append
(to prevent safety AAS).

The k-AtomicAppends problem, for k ≥ 2, is a generalization of the 2-
AtomicAppends that can be defined in the natural way (k clients, with k mu-
tually dependent records, to be appended to up to k BDLOs.) From this point
onwards, we will focus on the 2-AtomicAppends problem, and when clear from
the context, we will refer to it simply as AtomicAppends.

Byzantine Atomic Broadcast: In the algorithms we propose in this paper
for implementing BDLOs, we use a Byzantine Atomic Broadcast (BAB) service
for the server communication [6,7,15], that satisfies the properties of validity,
agreement, integrity, and total order, defined as follows:

– Validity: if a correct server BAB-broadcasts a message, then it will eventually
BAB-deliver it.

– Agreement : if a correct server BAB-delivers a message, then all correct
servers will eventually BAB-deliver that message.

– Integrity: a message is BAB-delivered by each correct server at most once,
and only if it was previously BAB-broadcast.

– Total Order : the messages BAB-delivered by correct servers are totally or-
dered; i.e., if any correct server BAB-delivers message m before message m′,
then every correct server must do it in that order.

Note that the work in [4] utilized a crash-tolerant Atomic Broadcast (AB)
service to implement a crash-tolerant DLO. The properties assumed here for the
BAB service are similar to their counterpart in the AB service, but applied only
to correct processes (since in the AB service processes stop when they fail, these
properties could be satisfied by the whole set of processes). It is important to
mention that it is not enough to replace the AB service with a BAB service in
the algorithms of [4] to implement a Byzantine DLO, and ensure the satisfaction
of properties BC, BSP, and BL. Therefore, we need to introduce some additional
machinery.



8 V. Cholvi, A. Fernández Anta, C. Georgiou, N. Nicolaou, and M. Raynal

Code 1 API to the operations of a BDLO L, executed by Client p
1: Init: c← 0
2: function L.get( )
3: c← c+ 1
4: send request (c, p, get) to at least 2f + 1 different servers
5: wait resp. (c, i, getResp, S) from f + 1 different servers with the same sequence S
6: return S
7: function L.append(r)
8: c← c+ 1
9: send request (c, p, append, r) to at least 2f + 1 different servers

10: wait resp. (c, i, appendResp, ack) from f + 1 different servers
11: return ack

Code 2 Algorithm u-ByDL: Byzantine-tolerant DLO; Code for Server i

1: Init: Si ← ∅
2: receive (c, p, get) from process p
3: BAB-broadcast(c, p, get, i)

4: upon (BAB-deliver(c, p, get, j)) do
5: if ((c, p, get, -) has been BAB-delivered f + 1 times from different servers) then

6: send resp. (c, i, getResp, Si) to p

7: receive (c, p, append, r) from process p
8: BAB-broadcast(c, p, append, r, i)

9: upon (BAB-deliver(c, p, append, r, j)) do
10: if (r /∈ Si) and
11: ((c, p, append, r, -) has been BAB-delivered from f + 1 different servers) then

12: Si ← Si‖r
13: send resp. (c, i, appendResp, ack) to p

3 Algorithms for Byzantine-tolerant DLOs

In this section, we introduce algorithms for implementing Byzantine-tolerant
DLOs. First, we assume that that there is no bound on the number of clients
that can fail (Section 3.1). However, if all clients can be Byzantine, then there is
no way to prevent a client from appending a meaningless record (unless we as-
sume that servers are clairvoyants, in the sense of detecting such records simply
by checking them). In other words, effective appends are possible (cf. Sect. 2).
Thus, in Section 3.2 we assume that there is a bound t on the maximum number
of clients that can fail, and provide the algorithms that implement the corre-
sponding DLOs. In that case, we detect the meaningless records by requesting
an append operation to be issued by, at least, t + 1 clients; hence, effective
appends can be prevented.

3.1 Unbounded Number of Byzantine Clients

Client Algorithm: The algorithm executed by a client that invokes a get or
append operation on a DLO L is presented in Code 1. An operation starts with
the invocation (event) of the corresponding function in Code 1, and it ends
when the matching return instruction is executed (return event). A Byzantine
client p may not follow Code 1 (as it may behave arbitrarily) but still be able
to append a record r in the ledger (with an effective append). So, some correct
client may obtain, in the response to a get operation, a sequence that contains
a record r appended by a Byzantine client.



Appending Atomically in Byzantine Distributed Ledgers 9

When an operation is invoked, a correct client increments a local counter and
then sends operation requests to a set of at least 2f + 1 servers, to guarantee
that at least f+1 correct servers receive it. A get operation completes when the
client receives f +1 consistent replies and an append completes when the client
receives f + 1 replies from different servers. Both cases guarantee the response
from at least one correct server.
Server Algorithm: The algorithm executed by the servers is presented in
Code 2. We denote it Algorithm u-ByDL (from unbounded Byzantine Dis-
tributed Ledger). The algorithm uses the Byzantine Atomic Broadcast service
to impose a total order in the messages shared among the servers. Operations
received from clients are BAB-broadcast using this service, which are eventually
BAB-delivered. An operation is processed by a server only when it has been
BAB-delivered f + 1 times (sent by different servers). This implies that at least
one correct server sent it. The properties of the BAB service guarantee that all
correct servers receive the same sequence of messages BAB-delivered, and hence
process the operations at the same point, maintaining their states consistent.

Theorem 1. Algorithm u-ByDL implements a linearizable Byzantine Tolerant
Distributed Ledger Object.

Proof. To proof the correctness of the algorithm we need to show that it satisfies
both the liveness property BC and the safety properties BSP and BL.

Liveness: The algorithm guarantees the liveness property BC with respect to
the failure model we assume. More precisely, each correct client sends requests to
2f +1 servers for an operation π and waits for f +1 servers to reply. Given that
the channels are reliable and up to f servers may fail (and thus not reply) then at
least f+1 correct servers will eventually receive and BAB-broadcast the request
from π. According to the BAB-Valitidy property, each message broadcasted by
a correct server will eventually be BAB-delivered. Furthermore, by the BAB-
Agreement property, all correct servers will eventually BAB-deliver the messages
broadcasted by correct servers. Thus, at least f+1 correct servers will deliver at
least f+1 messages broadcasted by the correct client. Those servers will reply to
operation π, and hence the client will receive at least f+1 replies and terminate.

Safety: To prove safety we need to show that any execution of our algorithm
satisfies properties BSP and BL.
BSP: Byzantine Strong Prefix (BSP) requires that if two get operations from
two correct clients return sequences S and S′ resp., then either S is a prefix of
S′ or S′ is a prefix of S. To derive contradiction let as assume that S is not a
prefix of S′. Let S = r1r2 . . . rn and S′ = r′1r

′
2 . . . r

′
m with m ≥ n. As S′ is not

a prefix of S, then ∃ri in S, for 1 ≤ i ≤ n s.t. ri 6= r′i. From the algorithm it
follows that the get operations received S and S′ from at least one correct server
as each get operations waits for f + 1 different servers to reply with the same
sequence. Let s be the correct server that sent S and s′ be the correct server
that replied with S′. Before appending a record rj in its local ledger, a correct



10 V. Cholvi, A. Fernández Anta, C. Georgiou, N. Nicolaou, and M. Raynal

server needs to wait for f+1 messages that contain rj to be BAB-delivered. This
guarantees that at least a single correct server received the request for appending
rj and BAB-broadcasted that record. According however to BAB-Agreement if
s BAB-delivers rj then s′ will BAB-deliver rj as well. Furthermore, for each
record rk, for 1 ≤ k ≤ j, that is BAB-delivered in s will also BAB-delivered in
s′ and according to the BAB-Total Order those records will be delivered in the
same order in both correct servers. This can be seen with a simple induction.
The first record of S, r1, will be BAB-delivered to both servers s and s′ (by
BAB-Agreement property). Record r2 will be BAB-delivered after r1 in s. By
BAB-Agreement property r2 will be BAB-delivered to s′ as well and by BAB-
Total Order r2 cannot be delivered before r1. So by the delivery of r2 to s and
s′, both servers contain the sequence r1r2. Suppose this is true up to record rk,
for k < n, i.e. both servers contain sequence r1 . . . rk after the BAB-delivery of
rk. As noted before, record rk+1 will be BAB-delivered to both servers s and s′

and by the total order property rk+1 cannot be delivered before any record rj ,
with j ≤ k. Thus, after the BAB-delivery of rk+1 both servers will contain the
sequence r1 . . . rk, rk+1. By the induction it follows that, after the BAB-delivery
of rn to both s and s′, they contain sequences r1 . . . rn. However this is sequence
S. Furthermore any record rm, for m > n, that is BAB-delivered to s′ will be
placed after rn in its local sequence. Thus, S is a prefix of S′ and that contradicts
our initial assumption. With similar reasoning we may show that if S is longer
than S′ then S′ be a prefix of S.

BL: Finally, Byzantine Linearizability (BL) requires that: (i) append operations
are ordered with respect to all other operations, (ii) if a get operation returns a
sequence that contains a record rj then an append(rj) operation preceded that
get, and (iii) if a get operation completes before the invocation of another get
operation, i.e. get1 → get2, then get1 returns a sequence S1 that is a prefix
of the sequence returned by get2, say S2. The total ordering of the append

operations is ensured by the BAB service. In particular, if append(r1) happens
before append(r2), i.e. append(r1) → append(r2), and both are executed by
correct processes, then they will send the append message to 2f + 1 servers,
out of which at least f + 1 correct servers will receive and BAB-broadcast the
append. Each correct server will BAB-deliver those appends by BAB-Validity
nad BAB-Agreement properties. Thus, each correct server will BAB-deliver at
least f + 1 messages for both records and will reply to the operations. Since
append(r1) → append(r2) then there exists a correct server that replies to
append(r1) before terminating. That server added r1 in its sequence before
receiving, and thus appending r2. Therefore, by BAB-Total Order all the correct
servers will append r1 before r2 in their local sequences, proving this way (i). As
for point (ii) a get operation obtains a sequence that contains a record r only
if that sequence is received from at least a single correct server s. Thus, since
s appended r in its sequence then an append(r) operation must have executed
before or concurrently with the get operation. Finally, for two operations get1

and get2, s.t. get1 → get2, it holds that the correct server, say s, that replies
to get1 has delivered and replied to all append operations with records in S1



Appending Atomically in Byzantine Distributed Ledgers 11

Code 3 Algorithm b-ByDL: Byzantine-tolerant BDLO with bounded number of
Byzantine clients; Code for processing the append operation at Server i

1: Init: Si ← ∅
2: receive (c, p, append, r) from process p
3: BAB-broadcast(c, p, append, r, i)

4: upon (BAB-deliver(c, p, append, r, j)) do
5: if (r ∈ Si) then

6: send response (c, i, appendResp, ack) to p
7: else

8: if ((c, -, append, r, -) has been BAB-delivered from f + 1 different servers
9: and received from a set C of t + 1 different clients) then

10: Si ← Si‖r
11: send response (c, i, appendResp, ack) to all q ∈ C

before BAB-delivering f+1 messages BAB-broadcasted for get1. Since, get1 →
get2, the message for get2 will be BAB-delivered to s after the the delivery of
the message of get1 at s. Since s is a corect server, then by BAB-Agreement
and BAB-Total Order, all the correct servers will BAB-deliver the messages
from get1 before the messages from get2. It holds also, that all the correct
servers delivered all the records appended before get1, before the delivery of
the messages from get2 as well. Thus, get2 will receive a sequence S2 longer or
the same size as S1. From the proof of BSP though it follows that S1 is a prefix
of S2 and that completes the proof. ⊓⊔

3.2 Bounded Number of Byzantine Clients

Observe that DLOs are oblivious to the syntax and semantics of the records they
hold [4]. Hence, in general (and in particular in Section 3.1), we do not care about
the records appended by Byzantine clients. Hence, the above algorithm does not
pre";"""date"",""2020-02-27T02:17:35Z""
""pdf:PDFVersion"",""1.4""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.4""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""xmp:CreateDate"",""2020-02-26T21:17:35Z""
""modified"",""2020-02-27T02:17:35Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""xmp:ModifyDate"",""2020-02-26T21:17:35Z""
""pdf:docinfo:creator"",""""
""meta:author"",""""
""meta:creation-date"",""2020-02-27T02:17:35Z""
""created"",""2020-02-27T02:17:35Z""
""xmp:About"",""uuid:ddf64c72-9123-11f5-0000-70da82e63e76""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-02-27T02:17:35Z""
""resourceName"",""2002.11593""
""Author"",""""
""producer"",""dvips + GPL Ghostscript GIT PRERELEASE 9.22""
""pdf:docinfo:producer"",""dvips + GPL Ghostscript GIT PRERELEASE 9.22""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""4"",""0"",""0"",""0"",""1"",""1"",""0"",""1"",""4"",""9"",""14"",""4"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2020-02-27T02:17:35Z""
""Last-Modified"",""2020-02-27T02:17:35Z""
""dcterms:modified"",""2020-02-27T02:17:35Z""
""title"",""""
""xmpMM:DocumentID"",""uuid:ddf64c72-9123-11f5-0000-70da82e63e76""
""Last-Save-Date"",""2020-02-27T02:17:35Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2020-02-27T02:17:35Z""
""meta:save-date"",""2020-02-27T02:17:35Z""
""Content-Length"",""248859""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""17""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""1899"",""2682"",""2840"",""2606"",""2566"",""2679"",""2518"",""2133"",""2670"",""2950"",""2294"",""2247"",""2358"",""2561"",""2143"",""3056"",""2080""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-02-27T02:17:35Z""
";https://scholar.google.ch/scholar?start=580&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098720-3;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;[HTML][HTML] Enhancing IoT Security with Blockchain;C Liu ;2020 search.proquest.com;;"… ity on governing decentralized networks makes it especially suitable for designing a self-managing

system on IoT devices. Cryptocurrency, the signature blockchain application however, cannot

be directly applied to the IoT-based E-commerce. For example, the iconic Bit …";Autres articles;;[HTML] proquest.com;https://search.proquest.com/openview/2206bbce804c3cc2a9157f900b3aeedd/1?pq-origsite=gscholar&cbl=44156;;;
1619098870-341;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;[PDF][PDF] Enabling Untraceable Anonymous Payments in the Lelantus Protocol;A Jivanyan, S Noether ;2020 lelantus.io;;"… protocol that is secure and special honest-verifier zero-knowledge in the random oracle model

using … Random oracles are practical: A paradigm for designing efficient protocols … In 2018 Crypto

Valley Conference on Blockchain Technology (CVCBT), pages 116–119, June 2018 …";Cité 2 fois;;[PDF] lelantus.io;https://lelantus.io/enabling-untraceable-anonymous-payments.pdf;"
Enabling Untraceable Anonymous Payments in the Lelantus Protocol

Aram Jivanyan1 and Sarang Noether2

1 Zcoin
aram@zcoin.io

https://zcoin.io
2 Monero Research Lab

sarang.noether@protonmail.com

https://getmonero.org

Abstract. We provide an update to the Lelantus protocol to enable untraceable direct anonymous payments.

Keywords: Lelantus, One-out-of-Many Proofs, Double-blinded commitments

1 Introduction

One of the major issues of the Lelantus protocol [3] is one of traceability in direct anonymous transfers. In such
scenarios, the sender can observe transactions and detect when a coin (represented as a commitment) is later spent
by the receiver. As this presents a notable security problem, one workaround requires the recipient to spend a newly-
received coin and mint a new coin to itself to remove this tracing. Although this approach mitigates the traceability
issue, it requires an additional transaction, increasing the space required on the blockchain, overall verification time,
and delay before the coin can be used. This approach may also introduce timing data that an observer could use to
form heuristics about spending behavior and reduce practical anonymity.

We describe a protocol upgrade intended to mitigate this issue in a more efficient and secure way.

2 Background

In order to support this protocol upgrade we have to modify how Lelantus coin serial numbers are generated. Next
we heavily utilize cryptographic proofs of representation as described below.

2.1 Coin Serial Numbers and Spending Keys

In Lelantus, coins are represented by double-blinded commitments of the form C = gShV1 h
R
2 in a prime-order group

G. Here S is the coin’s serial number generated by hashing a unique public key Q = gq, V is the value of the coin, and
R is a Pedersen blinder. During a spend transaction, the coin’s public key Q is revealed to compute the serial number
S, which is published as part of the transaction; further, the spender signs the entire transaction with q to prove
ownership of the coin. The public key Q enables all network participants to both compute the serial number (which
is required for verification of the spend transaction) and verify the transaction signature. This prevents previously-
known burning attacks where a malicious interloper who controls network messages can intercept an honest spend,
mint a coin with the same serial number, and spend it [5]; in our construction, the attacker would be unable to sign
with q, and the burn attempt would be rejected by the network. Note that in the original Zerocoin protocol, this
situation does not arise since the protocol does not support direct anonymous transfers [4].

A tracing problem arises in the case of direct payments, where a Diffie-Hellman exchange is used to generate Q.
This exchange ensures that the recipient, and not the sender, can recover the private key q corresponding to the
coin. However, because the sender knows the public key Q, it can observe transactions until it sees this public
key later revealed in another transaction. At this point, the sender knows the coin has been spent. Note that in



the original Zerocoin protocol, this situation does not arise since the protocol does not support direct anonymous
transfers [4].

We propose to modify this scheme and redefine the serial number. Using the same commitment format, we consider
gS to be the serial number, where the spender must now sign the transaction with S directly. During a spend
transaction, gS is publicly revealed and used to verify the transaction signature.

It is important to mention that enabling efficient batch verification using this construction is still possible.

2.2 Proof of Knowledge of a Representation

Consider a group G of prime order p and n generators g1, g2, . . . , gn. A representation of the element z against the
generators g1, g2, . . . , gn is the vector (s1, s2, . . . , sn) such that z = gs11 g

s2
2 ¡ ¡ ¡ gsnn . Below we describe a protocol for

proof of representation for arbitrary values n, referred to as a generalized Schnorr proof of knowledge.

Formally, such a proof of representation is a zero-knowledge argument for the following relation:

R = {g1, g2, . . . , gn ∈ G, y ; s1, s2, . . . , sn ∈ Zp | y = gs11 g
s2
2 ¡ ¡ ¡ gsnn }

The protocol is depicted in Figure 1. Verifying the completeness of the protocol is straightforward. It can be converted
into a non-interactive protocol that is secure and special honest-verifier zero-knowledge in the random oracle model
using the Fiat-Shamir heuristic [1].

Prover(g1, g2, . . . , gn, y, (s1, s2, . . . , sn)) Verifier(g1, g2, . . . , gn, y)
Computes

x1, x2, . . . , xn,←R Zp u
u = gx11 gx22 . . . gxnn ∈ G −−−−−−−→

x← {0, 1}λ
←−−−−−−−−−

t1 = x1 − x · s1 ∈ Zp
t2 = x2 − x · s2 ∈ Zp

...

tn = xn − x · sn
s1,s2,...,sn−−−−−−−→ Accepts if and only if

u = yxgt11 gt22 ¡ ¡ ¡ gtnn

Fig. 1. Generalized Schnorr proof of knowledge

3 Direct Anonymous Payments

In order to ensure proper authentication for a spend of the coin C = gShV1 h
R
2 , the coin owner should exclusively

possess the secret values S, V, and R. A spend transaction reveals the serial number gS and provides a valid signature
using S. Our goal is to develop a protocol that ensures that only the recipient can recover both S and gS , which
ensures that the sender cannot watch for a known serial number to trace later transactions.

In Figure 2 below we describe such a protocol. Note that we assume a recipient generates a new address for each
such transaction, and that the sender is assumed to transmit the secret values y and V to the recipient. This can be
done either through a secure side channel, or by encrypting them with a recipient public key and including them in
the transaction.

Notice also the requirement for the recipient to include a Schnorr proof of representation of the point Q with respect
to generators g and h2; without this, it is not possible to verify that the resulting coin commitment is constructed
using fixed public generators with no discrete logarithm relationship.

2



Sender Recipient

Samples x, r ←R Zp

Computes new public address Q = gxhr2

Generates a Schnorr proof P on the point Q
Q,P

←−−−−−−−
Verifies P

Samples y ←R Zp

Creates the output coin C = QyhV1 (= gxyhV1 hry2 )

Generates a range proof with respect to the
generators Q and h1

C,Q, P are published to the blockchain y, V
−−−−−−−→

Reveals the coin serial number gxy

Generates the Spend proof for the coin

Signs the transaction with the private key xy

Fig. 2. Minting new coin for dedicated recipient

4 Generating a Balance Proof

This construction requires modification of the transaction balance proof generation process described in [3]. Assume
a transaction spends Nold input coins and outputs Nnew coins CO,1, . . . , CO,Nnew

. Each output coin CO,i is associated
with the address Qi, which is published on the blockchain with the transaction. The balance proof generation steps
are the following:

1. The sender takes all output coins, the net output value VOUT , the transaction fee f and the common challenge
value x used for ÎŁ-proofs constructions, and computes the following element:

A : = (CO,1 ¡ . . . ¡ CO,Nnew)x
m

¡ h(VOUT+f)xm

1 =

= Qy1x
m

1 . . . Q
yNnewx

m

Nnew
h
(VOUT+VO,1+...+VO,Nnew+f)xm

1

2. Takes the elements zV 1, . . . , zVNold
, zR1, . . . , zRNold

and {Comm(0, ρtk, τ
t
k + γtk)}m−1

k=0 from the corresponding ÎŁ-
proof transcripts (for more details we refer to the original paper [3]) and computes the element:

B : = Comm(0; zV 1 + . . .+ zV Nold
, zR1 + . . .+ zRNold

) ¡
Nold∏
t=1

(m−1∏
k=0

(h
Îłt
k

2 · Comm(0; ρtk, τ
t
k))x

k
)

= h
(VI1+¡¡¡VIold)x

m

1 h
∑old

t=1(RIt¡xm+
∑m−1

k=0 Îłt
k¡x

k)
2

If the transaction balance holds, the h1 exponents in A and B will cancel:

A

B
= Qy11 Q

y2
2 . . . Q

yNnew

Nnew
hY2 (1)

3



where

Y = −
old∑
t=1

(
RIt ¡ xm +

m−1∑
k=0

γtk ¡ xk
)

Now observe that to provide a balance proof, it is sufficient for the transaction owner to prove knowledge of the
exponent values y1, y2, . . . , ynew and Y in Equation 1 with respect to the generators Q1, Q2, . . . , Qnew and h2. Given
that these generators are public, the sender can provide a proof of representation of the value A

B with respect to the
generators Q1, . . . , Qnew, h2, which then can be publicly verified by all network participants.

5 Performance

This protocol change produces tradeoffs in storage and computational efficiency compared to [3].

1. This construction requires each new minted coin to be explicitly associated with the recipient address Q along
with its proof of representation with respect to the generators g and h1. Hence each minted coin will be composed
of the commitment C, the address Q and corresponding proof of representation P . This requires an additional
group element and two additional scalars per mint.

2. The payment system implies that the coin private data is communicated with the recipient either through a
secure side channel or directly on the blockchain. In the latter case, the sender encrypts all private coin data
with the recipient’s public key and includes this in the transaction. In our new construction, this private data is
the elements y and V ; in [3] it is y, V , and R. The reduction in space depends on the method used to encrypt
these values to the recipient.

3. Balance proofs (which are composed of a single proof of representation) will require an additional Nnew−1 group
elements. For a transaction with a single output, there is no additional overhead.

4. Range proofs in this construction are produced using standard Pedersen commitments, instead of the double-
blinded commitments in the original protocol. When using Bulletproofs [2], this is a reduction in storage of a
single group element.

We note that batch verification of spend proofs is still possible with our updated construction.

6 Further Work

The construction presented here mitigates the tracing problem present in the original Lelantus transaction protocol.
However, it requires a recipient to present fresh address data to senders for each transaction. It is desirable for a
recipient to publish a single address such that senders can derive ephemeral one-time addresses as needed. However,
securely designing such a construction that is resistant to tracing remains an open task.

Finally, this construction is informal and lacks a security analysis.

References

1. Mihir Bellare and Phillip Rogaway. Random oracles are practical: A paradigm for designing efficient protocols. In Proceedings
of the 1st ACM Conference on Computer and Communications Security, CCS ’93, pages 62–73, New York, NY, USA, 1993.
ACM.

2. B. Bünz, J. Bootle, D. Boneh, A. Poelstra, P. Wuille, and G. Maxwell. Bulletproofs: Short proofs for confidential transactions
and more. In 2018 IEEE Symposium on Security and Privacy (SP), pages 315–334, May 2018.

3. Aram Jivanyan. Lelantus: Towards confidentiality and anonymity of blockchain transactions from standard assumptions.
Cryptology ePrint Archive, Report 2019/373, 2019. https://eprint.iacr.org/2019/373.

4



4. I. Miers, C. Garman, M. Green, and A. D. Rubin. Zerocoin: Anonymous distributed e-cash from Bitcoin. In 2013 IEEE
Symposium on Security and Privacy, pages 397–411, May 2013.

5. T. Ruffing, S. A. Thyagarajan, V. Ronge, and D. Schroder. Burning Zerocoins for fun and for profit - a cryptographic
denial-of-spending attack on the Zerocoin protocol. In 2018 Crypto Valley Conference on Blockchain Technology (CVCBT),
pages 116–119, June 2018.

5


";"""date"",""2019-10-03T05:37:48Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""6"",""4"",""0""
""pdf:PDFVersion"",""1.5""
""xmp:CreatorTool"",""TeX""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dcterms:created"",""2019-10-03T05:37:48Z""
""language"",""en""
""Last-Modified"",""2019-10-03T05:37:48Z""
""dcterms:modified"",""2019-10-03T05:37:48Z""
""dc:format"",""application/pdf; version=1.5""
""Last-Save-Date"",""2019-10-03T05:37:48Z""
""pdf:docinfo:creator_tool"",""TeX""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2019-10-03T05:37:48Z""
""meta:save-date"",""2019-10-03T05:37:48Z""
""pdf:encrypted"",""false""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017) kpathsea version 6.2.3""
""modified"",""2019-10-03T05:37:48Z""
""Content-Length"",""272263""
""pdf:hasMarkedContent"",""false""
""Content-Type"",""application/pdf""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017) kpathsea version 6.2.3""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""trapped"",""False""
""meta:creation-date"",""2019-10-03T05:37:48Z""
""created"",""2019-10-03T05:37:48Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""5""
""Creation-Date"",""2019-10-03T05:37:48Z""
""resourceName"",""enabling-untraceable-anonymous-payments.pdf""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""2609"",""2350"",""1388"",""2695"",""371""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""producer"",""pdfTeX-1.40.18""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""pdfTeX-1.40.18""
""pdf:docinfo:created"",""2019-10-03T05:37:48Z""
";https://scholar.google.ch/scholar?start=890&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098774-128;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Separating two-round secure computation from oblivious transfer;B Applebaum, Z Brakerski, S Garg, Y Ishai… ; 11th Innovations in …, 2020  drops.dagstuhl.de;;"… chosen (or sampled) input. In other words, the new protocol ?? only makes queries

to (OT1, OT2) which are essentially random oracles. Therefore, ?? securely computes

g in the random oracle model. However, it follows from …";Cité 2 fois;Les 6 versions;[PDF] dagstuhl.de;https://drops.dagstuhl.de/opus/volltexte/2020/11756/pdf/LIPIcs-ITCS-2020-71.pdf;"
Separating Two-Round Secure Computation from
Oblivious Transfer
Benny Applebaum
Tel-Aviv University, Israel
bennyap@post.tau.ac.il

Zvika Brakerski
Weizmann Institute of Science, Rehovot, Israel
zvika.brakerski@weizmann.ac.il

Sanjam Garg
UC Berkeley, CA, USA
sanjamg@berkeley.edu

Yuval Ishai
Technion – Israel Institute of Technology, Haifa, Israel
yuvali@cs.technion.ac.il

Akshayaram Srinivasan
UC Berkeley, CA, USA
akshayaram@berkeley.edu

Abstract
We consider the question of minimizing the round complexity of protocols for secure multiparty
computation (MPC) with security against an arbitrary number of semi-honest parties. Very recently,
Garg and Srinivasan (Eurocrypt 2018) and Benhamouda and Lin (Eurocrypt 2018) constructed such
2-round MPC protocols from minimal assumptions. This was done by showing a round preserving
reduction to the task of secure 2-party computation of the oblivious transfer functionality (OT).
These constructions made a novel non-black-box use of the underlying OT protocol. The question
remained whether this can be done by only making black-box use of 2-round OT. This is of theoretical
and potentially also practical value as black-box use of primitives tends to lead to more efficient
constructions.

Our main result proves that such a black-box construction is impossible, namely that non-black-
box use of OT is necessary. As a corollary, a similar separation holds when starting with any 2-party
functionality other than OT.

As a secondary contribution, we prove several additional results that further clarify the landscape
of black-box MPC with minimal interaction. In particular, we complement the separation from 2-
party functionalities by presenting a complete 4-party functionality, give evidence for the difficulty of
ruling out a complete 3-party functionality and for the difficulty of ruling out black-box constructions
of 3-round MPC from 2-round OT, and separate a relaxed “non-compact” variant of 2-party
homomorphic secret sharing from 2-round OT.

2012 ACM Subject Classification Theory of computation → Computational complexity and cryp-
tography; Theory of computation → Cryptographic protocols

Keywords and phrases Oracle Separation, Oblivious Transfer, Secure Multiparty Computation

Digital Object Identifier 10.4230/LIPIcs.ITCS.2020.71

Funding Benny Applebaum: Supported by the European Union’s Horizon 2020 Programme (ERC-
StG-2014-2020) under grant agreement no. 639813 ERC-CLC, and the Check Point Institute for
Information Security.
Zvika Brakerski: Supported by the Binational Science Foundation (Grant No. 2016726), and by the
European Union Horizon 2020 Research and Innovation Program via ERC Project REACT (Grant
756482) and via Project PROMETHEUS (Grant 780701).
Sanjam Garg: Supported in part from AFOSR Award FA9550-19-1-0200, AFOSR YIP Award, NSF
CNS Award 1936826, DARPA and SPAWAR under contract N66001-15-C-4065, a Hellman Award

Š Benny Applebaum, Zvika Brakerski, Sanjam Garg, Yuval Ishai, and Akshayaram Srinivasan;
licensed under Creative Commons License CC-BY

11th Innovations in Theoretical Computer Science Conference (ITCS 2020).
Editor: Thomas Vidick; Article No. 71; pp. 71:1–71:18

Leibniz International Proceedings in Informatics
Schloss Dagstuhl – Leibniz-Zentrum für Informatik, Dagstuhl Publishing, Germany

mailto:bennyap@post.tau.ac.il
mailto:zvika.brakerski@weizmann.ac.il
mailto:sanjamg@berkeley.edu
mailto:yuvali@cs.technion.ac.il
mailto:akshayaram@berkeley.edu
https://doi.org/10.4230/LIPIcs.ITCS.2020.71
https://creativecommons.org/licenses/by/3.0/
https://www.dagstuhl.de/lipics/
https://www.dagstuhl.de


71:2 Separating Two-Round Secure Computation from Oblivious Transfer

and research grants by the Okawa Foundation, Visa Inc., and Center for Long-Term Cybersecurity
(CLTC, UC Berkeley). The views expressed are those of the authors and do not reflect the official
policy or position of the funding agencies.
Yuval Ishai: Supported by ERC Project NTSC (742754), NSF-BSF grant 2015782, BSF grant
2018393, and a grant from the Ministry of Science and Technology, Israel and Department of Science
and Technology, Government of India.
Akshayaram Srinivasan: Supported in part from AFOSR Award FA9550-19-1-0200, AFOSR YIP
Award, NSF CNS Award 1936826, DARPA and SPAWAR under contract N66001-15-C-4065, a
Hellman Award and research grants by the Okawa Foundation, Visa Inc., and Center for Long-Term
Cybersecurity (CLTC, UC Berkeley). The views expressed are those of the authors and do not
reflect the official policy or position of the funding agencies.

Acknowledgements We thank Iftach Haitner, Mohammad Mahmoody, and Rotem Tsabary for
helpful discussions.

1 Introduction

Secure multiparty computation (MPC) allows mutually distrusting parties to compute a
joint function f of their private inputs without revealing anything more than the output to
each other.

In this paper we consider the simplest setting for MPC with no honest majority, namely
MPC with an arbitrary number of corrupted parties. We focus on the semi-honest (aka
passive) security model, where corrupted parties follow the protocol but try to (jointly) learn
additional information on inputs of uncorrupted parties from the messages they observe. We
also assume that the parties can communicate over secure point-to-point channels and that
corruptions are non-adaptive (i.e., the set of corrupted parties is fixed before the protocol’s
execution). All of the above assumptions make negative results stronger.

The design and analysis of MPC protocols crucially rely on the notion of secure reductions.
In particular, classical completeness results [54, 34] have shown that the problem of securely
computing a general n-party functionality f efficiently reduces to the problem of securely
computing the elementary finite 2-party Oblivious Transfer (OT) functionality [51, 26].
(Similar results have been proven for active adversaries as well [44, 43].) Perhaps surprisingly,
for 2-party secure computation (2PC), Yao’s reduction is round preserving. That is, it incurs
no overhead in the round complexity. It additionally requires the parties to make a black-box
use of any pseudorandom generator (PRG).

I Theorem 1 (Round-optimal 2PC [54]). Every 2-party functionality g admits an MPC
protocol that only makes parallel calls to an OT oracle and a black-box use of a PRG.

In more detail, the OT functionality FOT involves two parties referred to as Receiver and
Sender. The functionality takes a bit x from the Receiver and a pair of bits (more generally,
strings) (m0, m1) from the Sender, and delivers to the Receiver the message mx. This is
done while hiding m1−x from the Receiver and hiding x from the Sender.

Yao’s reduction makes a single round of parallel calls to FOT.1 Using a suitable composition
theorem for MPC in the semi-honest model (see, e.g., [20, 33]), this can be securely replaced
by parallel invocations of any OT protocol, namely a secure 2-party protocol for FOT. The

1 If both parties should receive an output, the reduction uses parallel OTs in both directions, where each
party acts both as a Sender and as a Receiver.



B. Applebaum, Z. Brakerski, S. Garg, Y. Ishai, and A. Srinivasan 71:3

resulting construction of 2-party MPC from a 2-party OT protocol is black-box.2 This means
that the MPC protocol does not depend on the code of the underlying OT protocol, and
moreover the security proof is black-box in the sense that any adversary “breaking” the
MPC protocol can be used as a black-box to break the OT protocol. Instantiating with
one of several natural known 2-round OT protocols (whose existence follows from standard
intractability assumptions), we get a 2-round 2-party MPC protocol, which is clearly optimal.

Round Complexity in the Multiparty Setting. In contrast to the 2-party setting, progress
on the round complexity of general MPC has been slow and some of the questions still remain
unanswered. As already mentioned, the completeness of OT in the multiparty setting was
first established by Goldreich, Micali, and Wigderson (GMW) [34]. However, their reduction
suffered from large round complexity (proportional to the circuit depth of the target function).
The question of achieving a constant-round protocol has been considered by Beaver, Micali,
and Rogaway [12], who extended Yao’s garbled circuit technique to the multiparty setting.
Combined with the GMW result, this yields a reduction to OT with constant overhead in
the round complexity.

I Theorem 2 (Constant-round MPC [34, 12]). Every n-party functionality admits a constant-
round protocol, making black-box use of a PRG, given an oracle access to FOT.

In more concrete terms, the most round-efficient current MPC protocol that makes a
black-box use of a 2-round OT protocol requires 4 rounds of interaction [1]. The above
results left a gap between the round complexity of 2PC and MPC protocols. In a recent
breakthrough, this gap was partially closed.

I Theorem 3 (2-round MPC from minimal assumption [31, 13]). Suppose a 2-round OT
protocol exists. Then every n-party functionality admits a 2-round MPC protocol.

The theorem settles the high-order bit about the minimal assumptions needed for 2-round
MPC by showing that 2-round OT is sufficient. (Being a special case of 2-round MPC, it is
clearly necessary.) However, quite surprisingly, the MPC protocol in these works inherently
makes use of the code of the underlying OT protocol. This situation is quite rare in the
context of MPC protocols and in cryptography in general (see Section 1.2), and it is not
clear whether this non-black-box use of OT is inherent. This calls for the following natural
question:

Is it possible to reduce general n-party MPC to a 2-party OT protocol in a round-
preserving black-box way? In particular, is there a black-box construction of 2-round
MPC from 2-round OT?

The above question is not only of a theoretical interest, but is also potentially relevant to
practice. Indeed, black-box use of cryptographic primitives tends to lead to more efficient
constructions. The goal of obtaining efficient 2-round MPC protocols is very well motivated,
since such protocols have qualitative advantages over similar protocols with a bigger number of
rounds. Indeed, in a 2-round MPC protocol, each party can send its first-round messages and
then go offline until all second-round messages are received and the output can be computed.
Moreover, the first-round messages can be potentially reused for several computations in
which a party’s input remains unchanged. This is analogous to the qualitative advantage of
public-key encryption over interactive key agreement.

2 The notion of a black-box construction used in this paper (also referred to as a black-box reduction)
corresponds to the notion of a fully black-box reduction in the taxonomy of [52].

ITCS 2020



71:4 Separating Two-Round Secure Computation from Oblivious Transfer

In this paper, we will provide a negative answer to the above question, showing that
there is a real gap between the power of round-preserving black-box (RPBB) reductions and
round-preserving non-black-box reductions. Our findings also reveal a rich and somewhat
unexplored world of cryptographic protocols that use a minimal amount of interaction. We
will exhibit some of the black-box and non-black-box connections among these primitives
and relate them to standard ones.

1.1 Our Results
We now give a more detailed account of our results.

1.1.1 Separating 3-Party Functionalities from 2-Party Functionalities
Our first result shows that 2-round MPC protocols cannot be based on 2-round OT in a
black-box way. In fact, we show that even 3-party computation of fairly simple functionalities
is unachievable via black-box use of 2-round OT.

I Theorem 4 (Main Result). There exists a 3-party functionality f that cannot be securely
computed by a 2-round protocol with black-box use of 2-round OT.

We note that we do not just rule out round-preserving reductions to the ideal-OT
functionality, but rather rule out all such black-box constructions from an OT protocol.
(Indeed, much of the technical work is devoted to coping with the latter model; see Section 2.)
Moreover, the theorem holds even for constructions in the private-channel setting (where
each pair of parties is connected via a private channel), and even when the parties have an
access to a public common reference string (CRS), and to a random oracle.

1.1.2 A Complete 4-Party Functionality
OT turns out to be incomplete for MPC under RPBB reductions. Given this state of affairs,
one may try to prove a completeness result for some other finite functionality. We show that
this is indeed possible. Specifically, let (3, 4)−MULTPlus denote the 4-party functionality
that takes a pair of bits (xi, zi) from each of the first three parties (and no input from the
fourth party) and delivers the value x1x2x3 +z1 +z2 +z3 to all four parties where addition and
multiplication are over the binary field. We prove that (3, 4)−MULTPlus is MPC-complete
under RPBB reductions. (Related results have been proved in other settings [18, 28].) In
fact, we prove an “ideal-oracle” completeness result just like in Yao’s theorem.

I Theorem 5 (Round Optimal MPC from Finite Ideal Functionality). Every n-party function-
ality f can be realized using parallel calls to a (3, 4)−MULTPlus oracle and a black-box use
of a PRG.

It’s worth noting that (3, 4)−MULTPlus is related to the standard 2-party OT functionality.
In general, for d ≤ p, let (d, p)−MULTPlus denote the p-party functionality in which each
of the first d parties holds an input (xi, zi) and the product-sum

∏
i xi +

∑
i zi is delivered

to all p parties. Then, standard 2-party OT is equivalent (under RPBB reductions) to
(2, 2)−MULTPlus.3

3 First observe that the receiver’s output in OT can be written as m0 + x(m1 −m0) where addition and
multiplication are over the binary field. Therefore, we can implement OT based on (2, 2)−MULTPlus by
letting the receiver (resp., sender) play the role of the first party (resp., second party) with inputs x1 = x



B. Applebaum, Z. Brakerski, S. Garg, Y. Ishai, and A. Srinivasan 71:5

1.1.3 The Land of Three-Party Functionalities
The finite (3, 4)−MULTPlus therefore stands at the entry point to the general MPC mainland.
Across the ocean, lies the island of two party functionalities (including the complete OT)
and one cannot cross it in a black-box round-preserving vessel. We move on and explore the
mysterious land of three party functionalities.

Given the incompleteness of 2-party functionalities and the completeness of four party
functionalities (under round-preserving BB reductions), it is natural to ask whether 3-party
functionalities are complete. We show that the answer to this question is related to a
well-known open problem in information-theoretic cryptography.

I Question 6 ([41]). Does every finite function admit a degree-2 statistical randomized
encoding?

A randomized encoding (RE) of a function [41, 6] f(x) is a randomized function f̂(x; r) that,
in addition to the input x, takes an additional random input r. For any input x, the random
variable f̂(x), induced by a random choice of r, should reveal the value of f(x) and hide
everything else. The power of REs stems from the fact that even complicated functions
can be encoded by simple encoding. In the context of MPC, it is known that every finite
function can be encoded by a function f̂(x; r) that each of its outputs can be written as a
degree-3 polynomial over the indeterminates (x, r). While some negative results are known
for perfectly-private degree-2 encodings [41], the feasibility of statistically-private degree-2
encodings (that are allowed to have a small non-zero privacy error) has remained open for
almost 20 years. (See also the surveys [40, 3].) We relate this longstanding open problem to
the completeness of 3-party functionalities under RPBB reductions.

I Proposition 7. A positive answer to Question 6 implies that every n-party finite functional-
ity g can be realized using parallel calls to an oracle that implements the 3-party functionality
(2, 3)−MULTPlus.

The proposition implies that we cannot rule out the completeness of 3-party functionalities
without ruling out the existence of general degree-2 (statistical) randomized encoding. Similar
barriers have been established in the context of degree-2 cryptographic hash functions [5]. We
note that the completeness of (2, 3)−MULTPlus follows even from the existence of general
degree-2 fully-secure multiparty randomized encoding [4] – a seemingly weaker variant of RE
whose existence is also open. (See the discussion in [4].)

External output functionalities. The (2, 3) −MULTPlus is a special case of an external-
output 3-party functionality. Formally, let g(x, y) be a 2-party functionality. The external
version of g, is the 3-party functionality fg that takes x from Alice, y from Bob and delivers
g(x, y) to Alice and Bob, and to Carol who holds no input.4 Two-round protocols for

and a random bit z1 (resp., x2 = m1 −m0 and z2 = m0). The receiver gets the required output (by
subtracting z1 from the output of the (2, 2)−MULTPlus), and the sender learns noting (since it receives
a random bit). In the other direction, first observe that the one-sided variant of (2, 2) −MULTPlus,
where only the first party has to learn the value x1x2 + z1 + z2, is RPBB-reducible to OT. Indeed, let
player 1 (resp., player 2) play the role of the receiver (resp., sender) with inputs x = x1 (resp., m0 = z2
and m1 = z2 +x2), and set the output of player 1 to be the output of the OT plus z1. Next, observe that
standard (2, 2)−MULTPlus can be constructed by making two parallel calls to the one-sided variant.

4 In fact, for all of our purposes, an even weaker version suffices. In this relaxed version, all parties are
allowed to learn the output (for purposes of privacy), but only Carol is required to learn it (for purposes
of correctness). Since this leads to a cumbersome definition, we stick to the simpler version described
above.

ITCS 2020



71:6 Separating Two-Round Secure Computation from Oblivious Transfer

such functionalities turn out to have interesting properties. Specifically, at the core of our
main impossibility result (Theorem 4), lies the following constructive theorem for external
functionalities.

I Theorem 8 (Conversion Theorem). Let g(x, y) be a 2-party functionality. The external
version of g is the 3-party functionality fg that takes x from Alice, y from Bob and delivers
g(x, y) to Alice and Bob, and to Carol who holds no input.

Suppose that the functionality fg can be securely computed in 2 rounds by making a
black-box use of 2-round OT over private channels. Then, fg can be securely implemented
over random inputs given only an access to a Random Oracle over private channels. Moreover,
in the resulting protocol Carol sends no message and so it yields a two-party protocol for
computing g over random inputs given only an access to a Random Oracle.

Haitner et al. [36] showed that any 2-party functionality that can be securely realized in the
Random Oracle (RO) model is trivial in the sense that it admits an unconditional 2-party
protocol over random inputs with security against computationally-unbounded adversaries.
As a corollary, we derive the following stronger version of Theorem 4.

I Corollary 9. Every external functionality fg that is based on a non-trivial 2-party func-
tionality f cannot be computed by a 2-round protocol that makes a black-box use of 2-round
OT even in the private-channel setting.

A notable example for such a non-trivial 2-party functionality is the AND functionality [21, 46].
Corollary 9 is tight in terms of round complexity. With one additional round, fg can

be black-box reduced to 2-round OT. (Specifically, one can use Yao’s theorem to pass the
value of f(x, y) to Alice and Bob in two rounds, and then exploit the additional round to
send this value to Carol.) The 2-party completeness of OT (Theorem 1) also implies that
Corollary 9 holds when the OT functionality is replaced by an arbitrary 2-party functionality
h(x, y). Overall, we get a separation between all 2-party functionalities and all external
functionalities fg whose underlying g is non-trivial.

Relation with homomorphic secret sharing. Two-round MPC for extended-output func-
tionalities can be seen as closely related to the problem of homomorphic secret sharing
(HSS) [16, 18]. HSS is the secret-sharing analogue of fully homomorphic encryption. A
(2-party) HSS scheme allows local computation of a function g(x, y) on independently shared
inputs x and y, where the output g(x, y) can be decoded from the pair of output shares. The
standard notions of HSS require either additive decoding over a group or, more generally, that
the output shares be compact in the sense that they are shorter than the inputs. A natural
variant is to replace compactness by the requirement that the pair of output shares give no
information except g(x, y), even from the point of view of one of the input holders. This
security requirement is easily obtained from additive HSS via a simple additive refreshing of
the output shares. This flavor of non-compact HSS easily implies (in a black-box way) a
2-round external output protocol for g (in the private-channel setting), which by Corollary 9
can be separated from 2-round OT. On the other hand, a non-black-box construction of
non-compact HSS from 2-round OT follows from [31, 28].

1.2 Discussion
In this section we give some further perspective on our results and some future research
directions which they motivate.



B. Applebaum, Z. Brakerski, S. Garg, Y. Ishai, and A. Srinivasan 71:7

1.2.1 Why is the multiparty setting different than the 2-party setting?
It is instructive to reconsider the round complexity of MPC in light of our results. Protocols
with low round complexity are based on two types of reductions.
1. A degree reduction that takes a general n-party functionality f and reduces it (via

RPBB reduction) to a degree-d functionality for a constant d. Specifically, the standard
machinery of randomized-encoding leads to degree 3. In the special case of two parties,
we can trivially reduce the degree down to 2, and so we get a degree reduction to
d = min(3, n).

2. A player reduction that takes an n-party functionality of degree d and reduces it to the
(d, p)–MULTPlus functionality. We show that p can be dropped down to d + 1 and, in
any case, it is no larger than n, leading to an expression of the form p = min(d + 1, n).

In the special case of two parties n = 2 we get an RPBB-reduction to (2, 2)–MULTPlus
which is equivalent to OT. For large n’s, this leads to the completeness of (3, 4)–MULTPlus
(Theorem 5). In order to prove that OT is complete (under RPBB-reductions) we have
to bypass two barriers: A Degree barrier (prove completeness of degree 2 functionalities)
and a Player reduction barrier (reducing the 3-party functionality (2,3)–MULTPlus to (2,2)–
MULTPlus). While the first barrier is well-known, the second one appears to be new to this
work. Clearly, both barriers are bypassed by non-black-box techniques (Theorem 3). We
show that this is inherent for the second “player reduction” barrier, and leave the possibility
of breaking the degree-barrier via RPBB-reduction open.

1.2.2 On the Role of Non-Black-Box Constructions in Cryptography
Our main result provides a very natural example of a pair of cryptographic primitives for
which a non-black-box construction of one from the other exists but a black-box construction
can be ruled out. Thus, our work further demonstrates the essential role of non-black-box
techniques in cryptography.

To give some historical perspective, following the seminal result of Impagliazzo and
Rudich [39] and subsequent works on black-box separations in cryptography [53, 32, 52], the
question of finding a pair of “natural” cryptographic primitives for which a non-black-box
reduction is provably necessary has been put forward as a desirable but elusive goal.5 For
some of the conjectured candidate examples, such as constructing “malicious OT” from “semi-
honest OT,” black-box constructions were subsequently found [35]. However, in recent years
several such provable examples emerged. We survey some of the most notable ones below.

Non-interactive commitments from OWFs: Mahmoody and Pass [48] showed that non-
interactive commitments cannot be constructed from so-called “hitting-OWFs” in a
black-box manner, even though a non-black-box construction was previously shown [10].
One nice feature of this example is that a non-interactive commitment is a very basic
primitive. However, in comparison hitting-OWFs have found little other applications in
cryptography. Furthermore, the separation here is intuitively weak since knowing the
circuit size of the OWF enables a black-box construction. This is contrasted with the
non-black-box constructions of 2-round MPC from OT [31, 13], which make an essential
use of the full code of the OT protocol.

5 The question is informal due to the subjective nature of the term “natural primitive.” It should not be
confused with the question of black-box vs. non-black-box simulation, for which Barak’s breakthrough
non-black-box simulation technique [8] gave the first such natural examples.

ITCS 2020



71:8 Separating Two-Round Secure Computation from Oblivious Transfer

Two-round OT extension: Beaver gave a construction of two-round OT extension [11]
making a non-black-box use of one-way functions. This construction can be cast in the
OT-hybrid model. However, very recently, Garg et al. [29] showed that a back-box variant
of such a constriction is impossible. They showed that such constructions are not possible
even when black-box use of a random oracle (and not just a one-way function) is allowed.
One limitation of this example is that the separation is only proved for protocols in the
OT-hybrid model.
IBE from CDH (or Generic Groups): In a recent result, DĂśttling and Garg [24] show that
Identity-Based Encryption (IBE) can be realized under the Computational Diffie-Hellman
(CDH) assumption, while black-box constructions of the same had been previously ruled
out [15, 50]. However, in this case both the positive and the negative result use strong
“structured” primitives.
In another very related example, DĂśttling and Garg [23] showed a generic non-black-box
construction of hierarchical-IBE from IBE but we can expect a black-box impossibility
for the same using techniques from [15].6
Constructions of IO: In a very recent work, Garg et al. [30] showed that indistinguishability
obfuscation (IO) [27] cannot be constructed from compact functional encryption (FE) in
a black-box manner, even though non-black-constructions achieving this were already
known [14, 2].
Secret-Key FE vs Public-Key FE : In a recent work, Kitagawa et al. [45] showed that
public-key FE can be constructed from secret-key FE in a non-black-box manner, even
though black-box positive constructions had been previously ruled out [7].

In comparison with the above works, our main result has the advantage that it considers
two very natural and simple primitives. Our separation lives entirely in the “passive adversary”
world, and does not depend on the input domain being super-polynomial. For instance, our
separation is also meaningful for MPC with a uniform input distribution over a constant-size
domain. Thus, it is arguably similar in spirit to the Impagliazzo-Rudich separation of
key agreement from one-way functions [39], except that in the latter case no analogous
non-black-box construction is known.

1.3 Open Problems
While we settle the main open question concerning black-box round-optimal MPC, our work
leaves several interesting directions for future research. We highlight a few below, focusing
on our current setting of semi-honest security with no honest majority.

3-round MPC from black-box OT. Our main result rules out 2-round MPC protocols
making a black-box use of 2-round OT. On the other hand, a previous result of Ananth
et al. [1] shows that such 4-round protocols exist. What about 3-round protocols? In
the full version of the paper, we give evidence that extending our negative result to the
3-round case would require settling Question 6 in the negative. This barrier does not seem
to apply to 3-round protocols in which the first round messages do not depend on the
inputs, or alternatively 2-round protocols with a public-key infrastructure (PKI) setup.
Black-box use of stronger primitives. Can our negative result be bypassed by
replacing OT with stronger or more structured primitives? It is known that 2-round MPC
can make black-box use of different flavors of multi-key homomorphic encryption [49, 22]

6 Even though we expect such an impossibility to hold, we are not aware of a work that gives a full proof
of this claim.



B. Applebaum, Z. Brakerski, S. Garg, Y. Ishai, and A. Srinivasan 71:9

or homomorphic secret sharing [17, 18]. However, this is almost immediate from the
definitions of such primitives. Using simpler structured primitives, such as a “DDH-
hard” group or a generic group, we have black-box 2-round protocols that require a PKI
setup [28]. Can we get similar group-based constructions in the plain model? Alternatively,
can the separation be bypassed by using stronger variants of 2-round OT, such as OT
with high information rate [25] or OT with a stronger notion of receiver privacy [42]?
Minimal complete primitive for 2-round MPC. We have shown the existence of a
4-party functionality such that general MPC reduces to parallel calls to this functionality
without further interaction. We have also ruled out such a 2-party functionality. This
leaves open the 3-party case. As in the case of 3-round MPC from 2-round OT, we can
show that proving a negative result would require settling Question 6 in the negative.
Standard MPC vs. client-server MPC. Our main negative result automatically
carries over to the stronger client-server model for MPC, where n clients interact with n

servers who have no inputs or outputs. It is known that 2-round client-server MPC can
be constructed in a non-black-box way from standard 2-round MPC [28]. Whether such
a black-box construction exists remains open.

2 Technical Overview

In this section, we give a high-level overview of our techniques in proving the main result
(Theorem 4). To keep the exposition simple, we restrict ourselves to proving the impossibility
result for securely computing external-AND.

External-AND Functionality. Let us denote the three parties by (P1, P2, P3). The private
input of P1 is a bit x, the private input of P2 is a bit y and P3 does not have any private
inputs. The functionality f× outputs x · y to all the parties. Specifically, f×(x, y,⊥) = x · y.

Main Idea. To prove the impossibility result, we define a set of oracles such that 2-
round oblivious transfer exists with respect to these oracles, but there exists no 2-round,
semi-honest protocol for securely computing f×. This is sufficient to rule out a black-box
transformation from 2-round oblivious transfer to 2-round, 3-party semi-honest protocols
for general functionalities. Below, we describe these oracles (throughout this overview, sec
denotes the security parameter):

OT1 is a random length tripling function that takes in the receiver’s choice bit b ∈ {0, 1}
and its random tape r ∈ {0, 1}sec and outputs the receiver’s message otm1.
OT2 is a random length tripling function that takes in the receiver’s message otm1, the
sender’s inputs m0, m1 ∈ {0, 1}, its random tape s ∈ {0, 1}sec and outputs the sender’s
message otm2.
OT3 is a function that takes the transcript (otm1, otm2) along with (b, r) as input
and outputs mb if there exists unique (m0, m1, s) for which OT1(b, r) = otm1 and
OT2(otm1, m0, m1, s) = otm2. Otherwise, it outputs ⊥.

As observed by [37], the oracles (OT1, OT2, OT3) naturally give rise to a 2-round oblivious
transfer protocol. Specifically, letting b, r denote the input/randomness of the receiver, and
letting (m0, m1), s denote the input/randomness of the sender, the protocol proceeds as
follows: The receiver sends otm1 = OT1(b, r) to the sender, who responds with otm2 =
OT2(otm1, m0, m1, s), allowing the receiver to output the value OT3(otm1, otm2, b, r).

In this work, we prove that the existence of a 2-round protocol for external-AND w.r.t.
(OT1, OT2, OT3) implies a two-party protocol for computing g(x, y) = x ¡ y in the random
oracle model. (Note that";"""date"",""2019-12-17T10:02:56Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""Separating Two-Round Secure Computation from Oblivious Transfer""
""xmp:CreatorTool"",""LaTeX with lipics-v2019.cls and hyperref.sty""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""LIPIcs, Vol.151, ITCS 2020; Copyright (C) Benny Applebaum, Zvika Brakerski, Sanjam Garg, Yuval Ishai, and Akshayaram Srinivasan; licensed under Creative Commons License CC-BY""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with lipics-v2019.cls and hyperref.sty""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""Separating Two-Round Secure Computation from Oblivious Transfer""
""modified"",""2019-12-17T10:02:56Z""
""cp:subject"",""LIPIcs, Vol.151, ITCS 2020; Copyright (C) Benny Applebaum, Zvika Brakerski, Sanjam Garg, Yuval Ishai, and Akshayaram Srinivasan; licensed under Creative Commons License CC-BY""
""pdf:docinfo:subject"",""LIPIcs, Vol.151, ITCS 2020; Copyright (C) Benny Applebaum, Zvika Brakerski, Sanjam Garg, Yuval Ishai, and Akshayaram Srinivasan; licensed under Creative Commons License CC-BY""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""Benny Applebaum, Zvika Brakerski, Sanjam Garg, Yuval Ishai, Akshayaram Srinivasan""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.20 (TeX Live 2019) kpathsea version 6.3.1""
""meta:author"",""Benny Applebaum, Zvika Brakerski, Sanjam Garg, Yuval Ishai, Akshayaram Srinivasan""
""trapped"",""False""
""meta:creation-date"",""2019-12-17T10:02:56Z""
""created"",""2019-12-17T10:02:56Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-12-17T10:02:56Z""
""resourceName"",""LIPIcs-ITCS-2020-71.pdf""
""Author"",""Benny Applebaum, Zvika Brakerski, Sanjam Garg, Yuval Ishai, Akshayaram Srinivasan""
""producer"",""pdfTeX-1.40.20""
""pdf:docinfo:producer"",""pdfTeX-1.40.20""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""1"",""2"",""4"",""2"",""2"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""Keywords"",""Oracle Separation, Oblivious Transfer, Secure Multiparty Computation""
""access_permission:modify_annotations"",""true""
""dc:creator"",""Benny Applebaum, Zvika Brakerski, Sanjam Garg, Yuval Ishai, Akshayaram Srinivasan""
""dcterms:created"",""2019-12-17T10:02:56Z""
""Last-Modified"",""2019-12-17T10:02:56Z""
""dcterms:modified"",""2019-12-17T10:02:56Z""
""title"",""Separating Two-Round Secure Computation from Oblivious Transfer""
""Last-Save-Date"",""2019-12-17T10:02:56Z""
""pdf:docinfo:keywords"",""Oracle Separation, Oblivious Transfer, Secure Multiparty Computation""
""pdf:docinfo:modified"",""2019-12-17T10:02:56Z""
""meta:save-date"",""2019-12-17T10:02:56Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.20 (TeX Live 2019) kpathsea version 6.3.1""
""Content-Length"",""529820""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Benny Applebaum, Zvika Brakerski, Sanjam Garg, Yuval Ishai, Akshayaram Srinivasan""
""dc:subject"",""Oracle Separation, Oblivious Transfer, Secure Multiparty Computation""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""18""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""2842"",""2951"",""3107"",""2693"",""3326"",""2975"",""3111"",""2992"",""3085"",""1805"",""3197"",""3280"",""3403"",""3328"",""3410"",""3622"",""3647"",""1085""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""Oracle Separation, Oblivious Transfer, Secure Multiparty Computation""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-12-17T10:02:56Z""
";https://scholar.google.ch/scholar?start=670&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098861-330;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;[PDF][PDF] FRAMEWORK TO INCREASE TRACEABILITY OF BUILT ASSETS;A BLOCKCHAIN, S CONTRACT;BASED 2020 wvvw.easychair.org;;"The UK Government's review of Building Regulations and Fire Safety 2018 identified a 
series of failings in the construction sector including ambiguous and inconsistent regulations 
and standards; lack of clarity of roles and responsibilities; lack of enforcement of regulations …";Les 5 versions;Version HTML;[PDF] easychair.org;https://wvvw.easychair.org/publications/preprint_download/KTgJ;;;https://scholar.google.ch/scholar?start=870&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098725-13;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Blockchain technology as an innovation strategy for competitive advantage by Kenya Redcross society;A Mohamud ;2020 erepository.uonbi.ac.ke;;"… book named Bitcoin, a peer-to-peer, open-source crypto-currency developed and launched by

Nakamoto Satoshi in 2009 (Nakamoto, 2009) … agreement among parties, which is uploaded and

coded to the blockchain … verified by a system called “oracles” (Swan, 2015, 25) …";Les 2 versions;Version HTML;[PDF] uonbi.ac.ke;http://erepository.uonbi.ac.ke/bitstream/handle/11295/153868/Mohamud_Blockchain%20technology%20as%20an%20innovation%20strategy%20for%20competitive%20advantage%20by%20Kenya%20Redcross%20society.pdf?sequence=1;"
BLOCKCHAIN TECHNOLOGY AS AN INNOVATION 

STRATEGY FOR COMPETITIVE ADVANTAGE BY KENYA 

REDCROSS SOCIETY 

 

 

 

ALI ABDULNASSIR MOHAMUD 

 

 

 

A RESEARCH PROJECT SUBMITTED IN PARTIAL 

FULFILMENT OF REQUIREMENTS FOR AWARD OF THE 

DEGREE OF MASTER OF BUSINESS ADMINISTRATION, 

SCHOOL OF BUSINESS, UNIVERSITY OF NAIROBI 

 

 

2020 



 
 

ii 
 

DECLARATION 

I, the undersigned declare that this research project is my original work and has not 

been presented to any other institution or forum for any other award before this 

declaration. 

Signed…………………………                     Date…………………………..               

Ali Abdulnassir Mohamud  

D61/86846/2016 

 

 

SUPERVISOR’S APPROVAL 

This project has been submitted for examination with my approval and advice as the 

University Supervisor. 

Signed………………………….                                Date…………………………….. 

Prof. Zachary B. Awino 

Professor of Strategy, Innovation and Performance Management 

School of Business 

University of Nairobi. 

 

 

 



 
 

iii 
 

DEDICATION 

I dedicate this thesis to my loving family, my lovely wife Shukri Ali Musa and our 

children, son Hamza and newborn daughter Halima for their unwavering support, 

motivation, and patience all through this journey. May Allah bless them. 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 



 
 

iv 
 

ACKNOWLEDGEMENT 

First, I want to thank Almighty Allah the most beneficiary the most merciful for 

blessing me with good health and helping me reach this point. Secondly, I sincerely 

appreciate my family Dad, Mum, and siblings for pushing me all through. To my wife 

and children for their encouragement, patience, and full support they gave me during 

my study. Without whom this would not be possible. 

Much appreciation and gratitude goes out to my Supervisor Prof. Zachary B. Awino for 

guiding me, dedicating his time to the completion of this Research Project, without 

whom this completion would not be possible. 

I would like to thank the Management, staff, and everyone who assisted in one way or 

the other at Kenyaredcross Society and for allowing me to research their noble 

organization. Special thank you to Orimba, Priyanka, Jackie, and Hussein for their 

input. 

 

 

 

 

 

 

 



 
 

v 
 

ABSTRACT 

This study aims at establishing how blockchain technology as an innovation strategy 

provides a competitive advantage for Kenyaredcross Society. This research employed 

a descriptive case study research whereby an interview guide was used to collect 

primary data. Data from the interview guide was analyzed down by using content 

analysis. The response rate was 66% with four out of the six responses on the questions 

issued.  The research covered three main departments from KRCS namely ICHA, 

Disaster Operations, and ICT. The major limitation of the study was due to the 

Covid_19 Pandemic face to face interviews were not possible due to social distancing 

and busy schedules by the respondents. The study found out that the pros of using 

Blockchain technology exceeded the cons and thus recommended the use of the 

technology but with enough planning and strategizing before embarking on it because 

it was very expensive and required a lot of funding and resources to be sustainable. The 

study noted that Blockchain brought transparency and trust to the donors.



 
 

vi 
 

TABLE OF CONTENTS 

DECLARATION ........................................................................................................ ii 

DEDICATION ........................................................................................................... iii 

ACKNOWLEDGEMENT ......................................................................................... iv 

ABSTRACT.................................................................................................................. v 

ABBREVIATIONS AND ACRONYMS................................................................... ix 

CHAPTER ONE: INTRODUCTION ........................................................................ 1 

1.1 Background of the Study ...................................................................................... 1 

1.1.1 Concept of Blockchain Technology .......................................................................... 2 

1.1.2 Innovation Strategy ................................................................................................... 3 

1.1.3 Industry Competitive Dynamics ............................................................................... 4 

1.1.4 Competitive Advantage ............................................................................................ 5 

1.1.5 Humanitarian Organizations in Kenya ...................................................................... 6 

1.1.6 Kenya Red-Cross Society ......................................................................................... 7 

1.2 Research Problem .............................................................................................. 8 

1.3 Research Objective ............................................................................................. 10 

1.4 Value of the Study .............................................................................................. 10 

CHAPTER TWO: LITERATURE REVIEW......................................................... 11 

2.1 Introduction ...................................................................................................... 11 

2.2 Theoretical Foundation ................................................................................... 12 

2.2.1 Knowledge-Based Theory....................................................................................... 12 

2.2.2 Systems Theory ....................................................................................................... 13 

2.3 Digital Ledger and Competitive Advantage....................................................... 14 

2.4 Smart Contracts and Competitive Advantage .................................................... 15 

2.5 Permission Block Chains and Competitive Advantage...................................... 16 

2.6 Transaction Validation and Competitive Advantage ......................................... 16 

2.7 Empirical Studies and Knowledge Gaps ............................................................ 17 



 
 

vii 
 

CHAPTER THREE: RESEARCH METHODOLOGY ........................................ 20 

3.1 Introduction ........................................................................................................ 20 

3.2 Research Design ................................................................................................. 20 

3.3 Data Collection ................................................................................................... 21 

3.4 Data Analysis ..................................................................................................... 22 

CHAPTER FOUR: DATA ANALYSIS, RESULTS AND DISCUSSION ........... 23 

4.1 Introduction ........................................................................................................ 23 

4.2 Response Rate .................................................................................................... 24 

4.3 Blockchain Technology Implementation as an Innovation Strategy ................. 24 

4.3.1 Innovation Strategies .............................................................................................. 26 

4.3.2 Blockchain Technology and Competitive Advantage ............................................. 27 

4.4 BlockChain as Center of Innovation .................................................................. 28 

4.5 Blockchain Conveyance to Donors .................................................................... 30 

4.6 Vital Reason for BlockChain ............................................................................. 31 

4.7. Focused Pros of BlockChain Technology ................................................................. 32 

4.8. Cons of Blockchain Development ............................................................................ 33 

4.9 Discussion .......................................................................................................... 34 

CHAPTER FIVE: SUMMARY, CONCLUSION, AND 

RECOMMENDATIONS…………………………………………………………...37 

5.1 Introduction ........................................................................................................ 37 

5.2 Summary of Findings ......................................................................................... 38 

5.3 Conclusion .......................................................................................................... 41 

5.4 Implications of the Study ................................................................................... 43 

5.5 Recommendations .............................................................................................. 44 

5.6 Limitations of the Study ..................................................................................... 45 



 
 

viii 
 

5.7 Suggestions for Further Research ...................................................................... 46 

REFERENCES .......................................................................................................... 48 

APPENDICES ............................................................................................................ 52 

APPENDIX I: Interview Guide ................................................................................... 52 

APPENDIX II: Data Collection Letter of Reference .................................................. 54 

 

 

 

 

 

 

 

 

 

 

 

 



 
 

ix 
 

ABBREVIATIONS AND ACRONYMS 

CTP                            Cash Transfer Program 

DM   Disaster Management 

GOK   Government of Kenya 

ICHA   International Center for Humanitarian Affairs 

ICRC                          International Committee of Redcross 

ICT   Information Communication Technology 

IFRC                          International Federation of the Redcross 

KBV   Knowledge-Based Theory  

KEMSA  Kenya Medical Supplies Authority 

KNBS   Kenya National Bureau of Statistics 

KRCS   Kenya Red Cross Society  

M&E   Monitoring and Evaluation 

MEAL             Monitoring, Evaluation, Accountability, and Learning 

MSF                            MÊdecins Sans Frontières 

NGOs   Non-Governmental Organizations 

POC   Proof of Concept 



 
 

x 
 

PR   Public Relation 

RBV   Resource-Based View  

UNHCR  United Nations High Commissioner for Refugees 

UNICEF  United Nation International Children's Emergency Fund 

 

              



 
 

1 
 

CHAPTER ONE: INTRODUCTION 

1.1 Background of the Study 

The extremely dynamic nature of the humanitarian supply chain owing to the need for 

transparency coupled with the ever-increasing number of charity based non-

governmental organization presupposes the need for humanitarian organizations to 

adopt strategies that assure their competitiveness and overall sustainability in the 

dynamic environment (Williams, 2015). Reinforcing transparency in the supply chain 

can improve operations among humanitarian organizations and enhance their 

competitive advantage by enabling evidence-based management and interventions, 

accurate and effective decision making, and increasing accountability. Blockchain 

technology, through the provision of a publicly visible ledger, enhances transparency 

in humanitarian supply chains. It’s also used as an information platform for tracing the 

use, origins, and humanitarian supplies’ destination.  

Various schools of thought can be used to explain creativity and innovation as critical 

in achieving sustainable competitive advantage among global firms Pinto and Morris 

(2007). They support the adoption of new technologies including the use of blockchain 

technology to improve creativity and innovation in the management of global firms 

(Bondarouk & Olivas-Lujan, 2013). According to Curado (2006), the knowledge-based 

theory (KBV) argues that a firm considers knowledge as the most strategically 

significant resource of a firm. Knowledge-based resources are not easy to imitate since 

they are socially complex as well as diverse in nature. Sustained innovation is giving 

individuals opportunities to learn how to come up with innovative ideas collectively, 

and a sense of purpose to manage their skills throughout the organization and teaching 

them how to recognize opportunities (Bondarouk & Olivas-Lujan, 2013).  



 
 

2 
 

Kenya Redcross Society was created by an Act of parliament (Chapter 256 Laws of 

Kenya). It remains a leading humanitarian organization in Kenya, East Africa, and 

Africa as a whole. KRCS roles include disaster mitigation, blood donation and first aid 

service, emergency response, and health. Humanitarian organizations in Kenya 

operating in disaster situations include KRCS, UNICEF, and UNHCR. KRCS crisis 

readiness and response team is in charge of disaster management through the planning 

of disaster response mechanisms and mitigation. UNICEF is a world pioneer in the 

acquisition of provisions for children. UNHCR tasked to ensure settlement of displaced 

people around the world. This study aims at discussing blockchain technology in the 

humanitarian sector (i.e. KRCS) because previous studies conducted on blockchain 

were concerning the private and public sectors. 

1.1.1 Concept of Blockchain Technology  

According to Bisoux (2018), blockchain can be portrayed as a morally driven record of 

financial transactions that may change to record any cash related trading and also 

everything in that regard. Blockchain advancement joins a creating once-over of 

records, called blocks, which are associated using cryptography and each block contains 

a cryptographic hash of the past block. Blockchain development models are timestamp 

and fuse trade data. 

As demonstrated by Zhao et al. (2018), in light of the blockchain advancement, the 

blocks attached to system data cannot be penetrated or changed. This is because it is an 

open, wide record that can record trading among two get-togethers gainfully or in a 

certain and enduring technique. To use it as a scattered record, blockchain customarily 

had to be administered by a framework sticking to a tradition between center 

correspondences and adopted new blocks. 



 
 

3 
 

Bisoux (2018) found that once recorded, the data in some irregular blocks can't be 

balanced retroactively without change of each ensuing block, which requires unity of 

the structure’s larger part. Verily, it is important that regardless of the way that 

blockchain records are not unalterable, blockchains may be seen as secure by plan and 

embodies a passed on enlisting system with high byzantine adjustment to non-basic 

disappointment. The blockchain advancement is organized in a way that it supports 

trades, which are constant and can't be deleted easily. 

1.1.2 Innovation Strategy 

The concept of innovation strategy refers to unique and new programs that 

organizations use to formulate, implement, and evaluate their policies and procedures 

to achieve sustainable competitive advantage. Innovation strategy also encourages or 

enables organizations to come up with new advancements in technology to better 

compete in the market. This includes the use of unique and rare resources in terms of 

human resources and other assets to achieve long term goals and objectives (Kasahara, 

2015).  

Innovation strategy plans include the use of new and unique game plans by global firms 

to help them position the company in its chosen market arena, compete successfully as 

well as please their customers and achieve good business performance in terms of 

profitability. The adoption of innovative and creative course of action and programs is 

also part of strategic management. Innovative and creative strategies can also help 

organizations analyze their external and internal environment, allocate resources 

effectively, and achieve their set goals within timeline and budget (Nicholson, 2017). 

 



 
 

4 
 

Innovation strategic plans usually result in the long term or sustainable long-term 

business success. This is because innovative strategy plans involve identifying and 

defining the organization’s long-range direction, business domain, key result areas, 

broad objectives, and supporting shared values. Through innovative strategy practices, 

global firms find a means of communicating to stakeholders its long-term goals, desired 

vision, organizational culture, values, and actions which result in sustainable 

competitive advantage (Bondarouk and Olivas-Lujan, 2013). 

1.1.3 Industry Competitive Dynamics 

Competitive dynamics are referred to as what organizations do in a competitive 

environment to counter what the competition is doing. Specific competitive 

achievement is a key pointer of competitive dynamics as each organization passes these 

actions to enhance its competitive advantage as compared to its competitors. Donors 

don’t necessarily hand the funding to agencies they have to work for it to be awarded. 

According to Michael Porter’s model, it is important to determine how organizations 

compete with each other, humanitarian agencies in this context play a major role. In the 

humanitarian sector, there is a lot of competition between agencies on which they were 

given donations and funding through a competitive process. This is determined by 

proposal writing to the donor and track record of work previously done by the agency. 

The Kenya Redcross is ahead of the pack because it does not rely on the normal 

humanitarian donor funding to run its day-to-day affairs. KRCS has come up with 

various businesses created and run by it and all profits go to the humanitarian agency 

to enhance its work of alleviating human suffering. These businesses are for example 

BOMA hotels, Switch T.V, Emergency ambulance services, First aid, and Hospitality 

schools. 



 
 

5 
 

1.1.4 Competitive Advantage 

Competitive advantage refers to how a firm contends in a specific business and gains 

by purposely choosing a distinctive set of activities. As per Porter (1980), a firm can 

achieve two fundamental kinds of competitive advantage low cost or differentiation. 

Porter's model of Competitive advantage recommends that a firm’s situation inside an 

industry was a factor in achieving competitive advantage. Choosing the scope of the 

firm’s exercises can play an intense role in deciding competitive advantage since it 

plans to build up a beneficial and manageable position against the powers that decide 

your industry rivalry. 

The two main sources of sustainable competitive advantage as anchored in the 

Resource-Based View (RBV) theory include capabilities and assets (Porter, 1980). 

Assets are different from capabilities whereby as opposed to assets, a monetary value 

cannot be attached to capabilities as can equipment and physical plant, and are so 

intensely entrenched in the organizational practices and routines that they can't be 

imitated or traded. Capabilities denote the cord that holds together assets and makes it 

possible for them to be advantageously deployed, assets refer to the accumulated 

resource endowments (Day, 1993).  

Strategic choices that a firm can seek after to achieve a competitive advantage hand for 

development may comprehensively be classified into serious, defensive, joint endeavor, 

and a combination of strategies (David, 2001). In a competitive environment, firms pick 

strategies that can give them an outcome competitive advantage. The main aim of a 

competitive strategy for a business is to discover a situation where the firm can best 

safeguard itself against external competitive forces or influence them in its favor. 

 



 
 

6 
 

1.1.5 Humanitarian Organizations in Kenya 

These are associations that are non-profit and sometimes non-governmental or private 

and which provide services to the most vulnerable in society. The humanitarian 

organizations focus on the most defenseless and most victims of the danger of disease, 

refugees, and also displaced people. Their capacity incorporates a range of exercises, 

including readiness, plan, obtainment, financing, transporting, repositioning, following, 

and custom flexibility (Oloruntoba and Gray, 2006). 

Compassionate association includes segments, for example, fund, acquirement, 

transportation, warehousing, stock administration, offering and hold offering, 

announcing, and responsibility to address crisis needs. It includes a stream of help from 

the benefactor to the recipients. Similarly, the helpful association includes parts, for 

example, ""fund, obtainment, transportation, warehousing, stock administration, and 

military hold-offering, reporting, and accountability to address crisis needs.” (Mbohwa, 

2006).   

Humanitarian organizations in Kenya operating in disaster situations include KRCS, 

UNICEF, and UNHCR. KRCS crisis readiness and response team is in charge of 

disaster management through the planning of disaster response mechanisms and 

mitigation. UNICEF is a world pioneer in the acquisition of provisions for children. 

UNHCR is mandated to ensure the settlement of displaced people around the world. 

Humanitarian operation is divided into the developmental and emergency sectors. The 

development sector includes activities that occur over a long period while the 

emergency sector deals with short term activities mainly during disasters (Oloruntoba 

and Gray, 2006). 



 
 

7 
 

1.1.6 Kenya Red-Cross Society 

The Kenya Redcross Society was founded in 1965 as one of the many International Red 

Cross and Red Crescent Movement societies around the world. KRCS mostly works 

with other agencies to make sure all human being's rights are respected as well as 

prevent and alleviate all human suffering in society. The institution manages numerous 

activities all aimed at creating awareness of the Kenyan population about the current 

problems that they face. The organization's roles include disaster mitigation, blood 

donation, and first aid service, emergency services, and health (www.redcross.or.ke). 

Application and use of blockchain technology-assisted KRCS on its mandate of 

alleviating human suffering. This technology allowed the organization to provide 

digitized, decentralized financial transactions competitively. By less funding, 

humanitarian organizations are sourcing funds in other ways than to rely on the 

traditional means of donor funding to remain competitive. This assisted to reduce 

corruption cases in the KRCS financial transactions, keep track of digital currency 

transactions without central recordkeeping, and remain competitive among other Red 

Cross Societies in Africa. 

Kenya Redcross Society was created by an Act of parliament (Chapter 256 Laws of 

Kenya). Kenya Redcross remains a leading humanitarian organization and first in 

Kenya, East Africa, and Africa as a whole. This is clear with the expectation and 

confidence bestowed on it by the communities living in Kenya. At the national level, 

operations are run by a management team led by the Secretary-General while at the 

regional level by a board and day to day activities directed by a Regional Manager. 

(www.redcross.or.ke). 

 

http://www.redcross.or.ke/
http://www.redcross.or.ke/


 
 

8 
 

1.2 Research Problem 

According to Zhao et al. (2018), the application of blockchain technology is emerging 

nearly in every industry in the market and innovative strategy application is not an 

exception. Notably, the main aim of using blockchain technology as an innovative 

strategy is to give organizations a sustainable competitive advantage. Organizations use 

blockchain technology to continually align their internal capabilities with the demands 

of the dynamic external environment.  

There is indeed a relationship between the technology application and the achievement 

of long-term success by global firms. The innovative strategy involves environmental 

scanning and analysis, strategy formulation, strategic choice, strategy implementation, 

and strategy evaluation (Kasahara, 2015).  Bisoux (2018) investigated the link between 

blockchain technology innovative strategy and competitive advantage but his findings 

were limited by both context and scope.  

The Kenya Redcross Society was founded in 1965 as one of the many International Red 

Cross and Red Crescent Movement societies around the world. KRCS mostly works 

with other agencies to ensure human being’s rights are respected as well as prevent and 

alleviate all human suffering in society. The organization's roles include disaster 

mitigation, blood donation, and first aid service, emergency services, and health 

(www.redcross.or.ke). Other agencies include UNICEF a pioneer in the acquisition of 

provisions and rights for children. UNHCR mandated to ensure settlement of displaced 

people and refugees from different countries. 

 

 

http://www.redcross.or.ke/


 
 

9 
 

In New York, Santos-Álarez and García-Merino (2011) studied “managerial cognition 

and innovative strategy: rethinking internationalization strategies” and found that 

managers are seeking technologies that improve their organization's entry point on the 

diffusion of the innovation adoption curve. Blockchain technology is providing this to 

many organizations around the globe and improving financial management and 

corporate governance of companies.  

Cambridge Massachusetts study on “using blockchain to protect personal data” by 

Zyskind, Nathan and Pentland (2015), established that the application of blockchain 

technology associated with organizations have proper and effective governance without 

managers or employees because blockchain technology can allow an organization to 

run completely by autonomous computer software, whereby trust among actors is 

established cryptographically.  

Kaburu (2011) analyzed the importance of blockchain technology at Kenya medical 

supplies agencies (KEMSA) and employed case study research design and content 

analysis to analyze the participant’s responses. The study established that blockchain 

technology is highly secure with limited malpractice and well observed at the high end 

of a firm. The research concluded blockchain technology is important in keeping and 

tracking records of medical supplies companies in Kenya. 

Odongo (2014) researched the effects of blockchain in Kenya institutions focusing on 

Kisumu County. Results established the importance of blockchain management and its 

function in an organization and the benefits were more than its challenges. The study 

concluded that blockchain technology is useful in tracking ledgers and reports from 

various departments in an organization and it is hard for one to amend transactions 

hence keeping the information open with high-secured source and storage. 



 
 

10 
 

Moreover, no studies have been done locally to show the relevance of blockchain 

technology in developing strategic plans for humanitarian institutions. This study filled 

this gap by providing research-based findings on the relationship between blockchain 

technology as an innovation strategy for competitive advantage in the case of KRCS. 

The study, therefore, attempted to answer the question; does blockchain technology as 

an innovation strategy provides a competitive advantage for KRCS? 

1.3 Research Objective 

To establish how Blockchain technology as an innovation strategy provides a 

competitive advantage for Kenya Red-Cross Society. 

1.4 Value of the Study 

Expectations are that the results of the study has benefitted several stakeholders 

including top leadership and management of Kenya Redcross Society, the employees 

within Kenya Redcross Society, the policymakers as well as the academicians and 

government agencies. The study findings has provided top leadership and management 

of Kenya Redcross Society with an opportunity to learn how to use blockchain models 

in promoting competitive advantage. 

Moreover, the study findings has helped different policymakers to adopt the best 

innovative strategy policies after careful consideration of the various application of 

blockchain technology. The study has also allowed academicians to conduct further 

studies on the relationship between blockchain technology as an innovative strategy 

and competitive advantage practices. Notably, the study findings is acting as a reference 

point in future studies related to the topic of the study.   

 



 
 

11 
 

  CHAPTER TWO: LITERATURE REVIEW 

2.1 Introduction 

The literature review focuses on theoretical and empirical literature with the study’s 

conceptualization. This chapter enumerates the literature and theoretical underpinnings 

by identifying and discussing theories relevant to the linkage between blockchain 

technology as an innovative strategy and competitive advantage within the Red-Cross 

Society. The empirical review is presented from both international and local 

perspectives. 

This chapter looked at how blockchain works and what aspects of it bring competitive 

advantage to Kenya Redcross Society. The researcher has expounded by explaining 

digital ledger and what it entails, as well as smart contracts, permission blockchains, 

and transaction validation. All these entities of blockchain increase the competitive 

advantage of Kenya Redcross Society and its functions. 

A lot of research has been done on Blockchain as a topic but most if not all of them 

have only covered the corporate sectors, parastatals, private sector, and government 

agencies but none has been done on humanitarian organizations. This paper discussed 

how blockchain gave Kenya Redcross Society an innovative and competitive advantage 

over all other humanitarian agencies. 

 

 

 

 



 
 

12 
 

2.2 Theoretical Foundation 

The theories under consideration include the knowledge-based theory as well as 

systems theory to explain and establish the linkage between blockchain technology as 

an innovative strategy and competitive advantage within various global organizations. 

2.2.1 Knowledge-Based Theory 

According to Curado (2006), the information based hypothesis (KBV) of the 

organization emphasizes on learning as the biggest asset of a firm. The advocates of the 

hypothesis contended that learning-based assets are difficult to emulate since they are 

socially perplexing and also heterogeneous. It is the information, encounters, and 

abilities of the representatives that enable the firm to have the high supported upper 

hand and predominant corporate execution in the general public.  

Knowledge-based theory recognized the different capabilities and special 

characteristics of workers in society. A good example of the theory’s application is the 

information technologies that help global firms to synthesize and improve. They also 

speed up extensive scale intra-and between a firm’s information, administration, and 

frameworks. Critically, some individuals contend that the learning-based perspective 

of the firm is an augmentation of the asset-based hypothesis (Curado, 2006).  

Grant (1996) noticed that the firm learning is installed and helped through numerous 

substances and models. For instance, there is the hierarchical culture, innovation, 

corporate strategies, schedules, and additionally the firm personalities and frameworks. 

The information-based hypothesis is connected with the asset-based perspective of the 

firm (RBV) which bolster the requirement for the utilization of learning and accessible 

assets to enable the firm to accomplish an upper hand in the public domain. 

 



 
 

13 
 

The condition of most information-based assets is unclear and it changes, taking into 

account unusual advancement through way reliance and causal vagueness, which are 

the premise of the component for monetary lease creation in the learning-based 

perspective of the firm (Kirsimrja and Aino, 1990). In this manner, global firms ought 

to consider information as the most imperative vital asset around the globe.  

2.2.2 Systems Theory 

According to Malecic (";"""date"",""2021-01-21T13:23:21Z""
""pdf:PDFVersion"",""1.6""
""xmp:CreatorTool"",""MicrosoftÂŽ Word 2013""
""pdf:docinfo:title"",""Blockchain technology as an innovation strategy for competitive advantage by Kenya Redcross society""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""false""
""subject"",""Blockchain technology as an innovation strategy for competitive advantage by Kenya Redcross society
""
""language"",""en""
""dc:format"",""application/pdf; version=1.6""
""pdf:docinfo:creator_tool"",""MicrosoftÂŽ Word 2013""
""access_permission:fill_in_form"",""false""
""pdf:encrypted"",""true""
""dc:title"",""Blockchain technology as an innovation strategy for competitive advantage by Kenya Redcross society""
""xmp:CreateDate"",""2020-12-08T15:38:49Z""
""modified"",""2021-01-21T13:23:21Z""
""cp:subject"",""Blockchain technology as an innovation strategy for competitive advantage by Kenya Redcross society
""
""pdf:docinfo:subject"",""Blockchain technology as an innovation strategy for competitive advantage by Kenya Redcross society
""
""pdf:hasMarkedContent"",""true""
""xmp:ModifyDate"",""2021-01-21T16:23:21Z""
""pdf:docinfo:creator"",""Mohamud,Ali""
""meta:author"",""Mohamud,Ali""
""meta:creation-date"",""2020-12-08T12:38:49Z""
""created"",""2020-12-08T12:38:49Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-12-08T12:38:49Z""
""resourceName"",""Mohamud_Blockchain%20technology%20as%20an%20innovation%20strategy%20for%20competitive%20advantage%20by%20Kenya%20Redcross%20society.pdf""
""Author"",""Mohamud,Ali""
""producer"",""MicrosoftÂŽ Word 2013""
""pdf:docinfo:producer"",""MicrosoftÂŽ Word 2013""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""dc:description"",""Blockchain technology as an innovation strategy for competitive advantage by Kenya Redcross society
""
""Keywords"",""This study aims at establishing how blockchain technology as an innovation strategy provides a competitive advantage for Kenyaredcross Society. This research employed a descriptive case study research whereby an interview guide was used to collect primary data. Data from the interview guide was analyzed down by using content analysis. The response rate was 66% with four out of the six responses on the questions issued. The research covered three main departments from KRCS namely ICHA, Disaster Operations, and ICT. The major limitation of the study was due to the Covid_19 Pandemic face to face interviews were not possible due to social distancing and busy schedules by the respondents. The study found out that the pros of using Blockchain technology exceeded the cons and thus recommended the use of the technology but with enough planning and strategizing before embarking on it because it was very expensive and required a lot of funding and resources to be sustainable. The study noted that Blockchain brought transparency and trust to the donors."",""This study aims at establishing how blockchain technology as an innovation strategy provides a competitive advantage for Kenyaredcross Society. This research employed a descriptive case study research whereby an interview guide was used to collect primary data. Data from the interview guide was analyzed down by using content analysis. The response rate was 66% with four out of the six responses on the questions issued. The research covered three main departments from KRCS namely ICHA, Disaster Operations, and ICT. The major limitation of the study was due to the Covid_19 Pandemic face to face interviews were not possible due to social distancing and busy schedules by the respondents. The study found out that the pros of using Blockchain technology exceeded the cons and thus recommended the use of the technology but with enough planning and strategizing before embarking on it because it was very expensive and required a lot of funding and resources to be sustainable. The study noted that Blockchain brought transparency and trust to the donors.""
""access_permission:modify_annotations"",""false""
""dc:creator"",""Mohamud,Ali""
""description"",""Blockchain technology as an innovation strategy for competitive advantage by Kenya Redcross society
""
""dcterms:created"",""2020-12-08T12:38:49Z""
""Last-Modified"",""2021-01-21T13:23:21Z""
""dcterms:modified"",""2021-01-21T13:23:21Z""
""title"",""Blockchain technology as an innovation strategy for competitive advantage by Kenya Redcross society""
""xmpMM:DocumentID"",""uuid:2d8d8f4c-fa1e-4597-bd50-71989e0830da""
""Last-Save-Date"",""2021-01-21T13:23:21Z""
""pdf:docinfo:keywords"",""This study aims at establishing how blockchain technology as an innovation strategy provides a competitive advantage for Kenyaredcross Society. This research employed a descriptive case study research whereby an interview guide was used to collect primary data. Data from the interview guide was analyzed down by using content analysis. The response rate was 66% with four out of the six responses on the questions issued. The research covered three main departments from KRCS namely ICHA, Disaster Operations, and ICT. The major limitation of the study was due to the Covid_19 Pandemic face to face interviews were not possible due to social distancing and busy schedules by the respondents. The study found out that the pros of using Blockchain technology exceeded the cons and thus recommended the use of the technology but with enough planning and strategizing before embarking on it because it was very expensive and required a lot of funding and resources to be sustainable. The study noted that Blockchain brought transparency and trust to the donors.""
""pdf:docinfo:modified"",""2021-01-21T13:23:21Z""
""meta:save-date"",""2021-01-21T13:23:21Z""
""Content-Length"",""1347566""
""Content-Type"",""application/pdf""
""xmp:MetadataDate"",""2021-01-21T16:23:21Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Mohamud,Ali""
""dc:language"",""en-US""
""pdf:producer"",""MicrosoftÂŽ Word 2013""
""dc:subject"",""This study aims at establishing how blockchain technology as an innovation strategy provides a competitive advantage for Kenyaredcross Society. This research employed a descriptive case study research whereby an interview guide was used to collect primary data. Data from the interview guide was analyzed down by using content analysis. The response rate was 66% with four out of the six responses on the questions issued. The research covered three main departments from KRCS namely ICHA, Disaster Operations, and ICT. The major limitation of the study was due to the Covid_19 Pandemic face to face interviews were not possible due to social distancing and busy schedules by the respondents. The study found out that the pros of using Blockchain technology exceeded the cons and thus recommended the use of the technology but with enough planning and strategizing before embarking on it because it was very expensive and required a lot of funding and resources to be sustainable. The study noted that Blockchain brought transparency and trust to the donors."",""This study aims at establishing how blockchain technology as an innovation strategy provides a competitive advantage for Kenyaredcross Society. This research employed a descriptive case study research whereby an interview guide was used to collect primary data. Data from the interview guide was analyzed down by using content analysis. The response rate was 66% with four out of the six responses on the questions issued. The research covered three main departments from KRCS namely ICHA, Disaster Operations, and ICT. The major limitation of the study was due to the Covid_19 Pandemic face to face interviews were not possible due to social distancing and busy schedules by the respondents. The study found out that the pros of using Blockchain technology exceeded the cons and thus recommended the use of the technology but with enough planning and strategizing before embarking on it because it was very expensive and required a lot of funding and resources to be sustainable. The study noted that Blockchain brought transparency and trust to the donors.""
""access_permission:assemble_document"",""false""
""xmpTPg:NPages"",""64""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""308"",""632"",""271"",""880"",""1073"",""2975"",""2695"",""593"",""734"",""183"",""1849"",""1819"",""1690"",""1868"",""1788"",""1710"",""1734"",""1598"",""1865"",""1603"",""1261"",""1802"",""1854"",""1708"",""1397"",""1812"",""1362"",""1574"",""1978"",""1606"",""1571"",""1598"",""1165"",""1659"",""1825"",""1857"",""1468"",""1439"",""1615"",""1692"",""1729"",""1408"",""1939"",""1534"",""1613"",""1948"",""1315"",""1559"",""1879"",""1949"",""1875"",""1887"",""1401"",""1846"",""1665"",""1632"",""951"",""1287"",""1302"",""1391"",""796"",""875"",""476"",""56""
""access_permission:extract_content"",""false""
""access_permission:can_print"",""false""
""meta:keyword"",""This study aims at establishing how blockchain technology as an innovation strategy provides a competitive advantage for Kenyaredcross Society. This research employed a descriptive case study research whereby an interview guide was used to collect primary data. Data from the interview guide was analyzed down by using content analysis. The response rate was 66% with four out of the six responses on the questions issued. The research covered three main departments from KRCS namely ICHA, Disaster Operations, and ICT. The major limitation of the study was due to the Covid_19 Pandemic face to face interviews were not possible due to social distancing and busy schedules by the respondents. The study found out that the pros of using Blockchain technology exceeded the cons and thus recommended the use of the technology but with enough planning and strategizing before embarking on it because it was very expensive and required a lot of funding and resources to be sustainable. The study noted that Blockchain brought transparency and trust to the donors."",""This study aims at establishing how blockchain technology as an innovation strategy provides a competitive advantage for Kenyaredcross Society. This research employed a descriptive case study research whereby an interview guide was used to collect primary data. Data from the interview guide was analyzed down by using content analysis. The response rate was 66% with four out of the six responses on the questions issued. The research covered three main departments from KRCS namely ICHA, Disaster Operations, and ICT. The major limitation of the study was due to the Covid_19 Pandemic face to face interviews were not possible due to social distancing and busy schedules by the respondents. The study found out that the pros of using Blockchain technology exceeded the cons and thus recommended the use of the technology but with enough planning and strategizing before embarking on it because it was very expensive and required a lot of funding and resources to be sustainable. The study noted that Blockchain brought transparency and trust to the donors.""
""access_permission:can_modify"",""false""
""pdf:docinfo:created"",""2020-12-08T12:38:49Z""
";https://scholar.google.ch/scholar?start=560&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098782-147;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Behavioral simulation for smart contracts;SM Beillahi, G Ciocarlie, M Emmi, C Enea ; Proceedings of the 41st ACM …, 2020  dl.acm.org;;"… to simulation. We then leverage off-the-shelf learning algorithms [54] by providing

an oracle to evaluate candidate expressions against pairs of states, ie, by executing

such expressions on the blockchain. To verify candidate …";Cité 5 fois;;[PDF] irif.fr;https://www.irif.fr/~cenea/papers/pldi20sc.pdf;"
Behavioral Simulation for Smart
Contracts

Sidi Mohamed Beillahi∗
UniversitĂŠ de Paris, IRIF, CNRS

Paris, France
beillahi@irif.fr

Gabriela Ciocarlie
SRI International
New York, USA

gabriela.ciocarlie@sri.com

Michael Emmi
SRI International
New York, USA

michael.emmi@gmail.com

Constantin Enea
UniversitĂŠ de Paris, IRIF, CNRS, Institut Universitaire de

France (IUF)
Paris, France
cenea@irif.fr

Abstract
While smart contracts have the potential to revolutionize
many important applications like banking, trade, and supply-
chain, their reliable deployment begs for rigorous formal
verification. Since most smart contracts are not annotated
with formal specifications, general verification of functional
properties is impeded.

In this work, we propose an automated approach to verify
unannotated smart contracts against specifications ascribed
to a few manually-annotated contracts. In particular, we
propose a notion of behavioral refinement, which implies in-
heritance of functional properties. Furthermore, we propose
an automated approach to inductive proof, by synthesizing
simulation relations on the states of related contracts. Em-
pirically, we demonstrate that behavioral simulations can be
synthesized automatically for several ubiquitous classes like
tokens, auctions, and escrow, thus enabling the verification
of unannotated contracts against functional specifications.

CCS Concepts: • Software and its engineering → For-
mal software verification; • Theory of computation→

Automated reasoning.

Keywords: Blockchain, Smart contracts, Refinement, Simu-
lation

∗This work was conducted during an internship at SRI International.

Permission to make digital or hard copies of all or part of this work for
personal or classroom use is granted without fee provided that copies
are not made or distributed for profit or commercial advantage and that
copies bear this notice and the full citation on the first page. Copyrights
for components of this work owned by others than the author(s) must
be honored. Abstracting with credit is permitted. To copy otherwise, or
republish, to post on servers or to redistribute to lists, requires prior specific
permission and/or a fee. Request permissions from permissions@acm.org.
PLDI ’20, June 15–20, 2020, London, UK
Š 2020 Copyright held by the owner/author(s). Publication rights licensed
to ACM.
ACM ISBN 978-1-4503-7613-6/20/06. . . $15.00
https://doi.org/10.1145/3385412.3386022

ACM Reference Format:
Sidi Mohamed Beillahi, Gabriela Ciocarlie, Michael Emmi, and Con-
stantin Enea. 2020. Behavioral Simulation for Smart Contracts.
In Proceedings of the 41st ACM SIGPLAN International Conference
on Programming Language Design and Implementation (PLDI ’20),
June 15–20, 2020, London, UK. ACM, New York, NY, USA, 17 pages.
https://doi.org/10.1145/3385412.3386022

1 Introduction
Smart contracts are programs that execute on cryptograph-
ically-secure distributed ledgers, i.e., blockchains, to perform
trackable and irreversible transactions. As they offer auton-
omy for arbitrarily-complex transactions between multiple
parties, smart contracts are already powering a sizable econ-
omy: applications include banking [4], insurance [2], auction,
trade, and supply chain. This rapid adoption has been closely
followed by exploitation, including millions of US dollars
lost due to vulnerabilities in smart contract code [1, 3, 5].
Formal verification has the potential to mitigate such ex-

ploitation significantly. However, scaling verification efforts
to a large number of smart contracts is an important chal-
lenge. In particular, while specifications that are specialized
to each individual smart contract are useful for proving cus-
tomized functional properties [55], generic specifications that
can be applied to large classes of smart contracts would facil-
itate verifying contracts en masse. Ideally, the specification
for a given class of smart contracts could be written once,
and reused for the verification of each contract of that class.

Truly generic specifications must be sufficiently weak so
that every correct contract in the given class adheres to its
functional properties. Moreover, truly generic specifications
must be independent from the state variables of any partic-
ular contract, since the state variables of other contracts in
the same class generally differ in name, number, and type.
Such generic specifications are however unsuited for existing
verification tools like solc-verify [36] and VerX [55], which
suppose that input contracts are annotated with expressions
that refer to state variables, e.g., pre- and post-conditions.

https://www.acm.org/publications/policies/artifact-review-badging
https://doi.org/10.1145/3385412.3386022
https://doi.org/10.1145/3385412.3386022


PLDI ’20, June 15–20, 2020, London, UK Sidi Mohamed Beillahi, Gabriela Ciocarlie, Michael Emmi, and Constantin Enea

This poses a scalability problem since deriving such annota-
tions for each contract from class-wide generic specifications
would be a manual labor-intensive process.

In this work, we address this scalability challenge and
introduce an approach for verifying unannotated smart con-
tracts via automated semantic comparison against annotated
smart contracts. Our approach is motivated by the insight
that many of the smart contracts instantiated on popular
blockchains (e.g., Ethereum [72]) are variations on a rela-
tively small number of canonical contracts and libraries im-
plementing concepts like tokens, ownership, auctions, and
escrow. Intuitively, many of these variations obey the princi-
ple of substitutability [43], meaning that they adhere to the
functional properties captured by the annotations of their
canonical counterparts.

With a notion of comparison that implies substitutability,
we can thus amortize the cost of manually annotating these
canonical contracts by verifying a vast number of unanno-
tated contracts. Our notion of behavioral refinement relates
the input-output behavior of contracts’ transactions, i.e., pa-
rameters and effects on storage, ignoring internal details
like local memory and control flow. By proving that a given
contract is a behavioral refinement of another, we guarantee
the inheritance of behavioral properties, and in particular
that the effects of any sequence of transactions obeys its
canonical counterpart’s functional properties.

Establishing behavioral refinement for unbounded transac-
tion sequences relies on induction. Akin to inductive invari-
ants for safety properties, proofs of behavioral refinement
use induction hypotheses called simulation relations [46].
Essentially, a behavioral simulation relation identifies states
of two contracts such that initial states are related; the same
transaction applied to related states yields related states and
identical effects; and related states are observationally equiv-
alent, i.e., any function applied to both yields identical values.
While simulation relations are known to be incomplete for
establishing refinement [45], they have the advantage of
guaranteeing inheritance of its canonical counterpart’s hy-
perproperties [8, 10]. Hyperproperties [19], described as sets
of sets of behaviors (as opposed to standard safety/liveness
properties which can be thought of as sets of behaviors),
capture many interesting security properties, e.g., the classic
noninterference [32], which are relevant in the context of
smart contracts [34, 65].
Accordingly, our automated verification approach boils

down to the synthesis of behavioral simulation relations in
two steps: a passive learning step generates candidate sim-
ulation relations, and a deductive verification step checks
the validity of each candidate. Candidate generation can be
demand-driven according to counterexample guided induc-
tive synthesis [61], e.g., initially proposing the trivial simula-
tion relating each pair of contract states, and incrementally
proposing candidates which rule out spurious counterexam-
ples from prior validation steps. In this work, we consider

a simplification which suffices empirically: generating and
validating one single candidate simulation.

To generate candidate simulation relations, we adopt a
paradigm of learning from examples [47]. In this work, we
consider only passive learning, which assumes that the set of
examples is fixed a priori, as opposed to being generated on
learner demand. In the context of simulation, an example is
a pair of states, i.e., one state of each contract: positive exam-
ples are pairs of states which must be similar, and negative
examples are pairs which must not be similar. To generate ex-
amples, we consider sequences of transactions, executed on
a blockchain, starting from the initial states of each contract.
Intuitively, negative examples correspond to pairs of states
which yield distinct observations, and positive examples cor-
respond to pairs of states reached by identical transaction
sequences, unless such a pair yields distinct observations,
in which case it is a counterexample to simulation. We then
leverage off-the-shelf learning algorithms [54] by providing
an oracle to evaluate candidate expressions against pairs of
states, i.e., by executing such expressions on the blockchain.

To verify candidate simulation relations, we adopt a notion
of product programs inspired by relational verification [13].
In particular, we generate an auxiliary simulation-checking
contract whose verification implies the validity of a given
simulation relation. Intuitively, for each function f of the
given unannotated contract, the simulation-checking con-
tract provides a function which executes f in lockstep with
its canonical contract’s counterpart. Besides asserting the
equality of effects and return-values, this function includes
the candidate simulation as pre- and post-conditions, ulti-
mately implying inductiveness. We verify the simulation-
checking contract using an existing verifier [36], which trans-
lates Solidity smart contracts to Boogie programs [11], and
ultimately to satisfiability modulo theories (SMT) queries.

Empirically, we validate our approach by collecting dozens
of Solidity-language smart contracts, identifying canonical
contracts for several classes, annotating and verifying these
canonical contracts with precise formal specifications, and
synthesizing simulation relations from multiple variations
of each class. Our implementation can correctly synthesize
nontrivial simulation relations for many classes, and inte-
grates off-the-shelf tools for example-guided learning and
Solidity verification.

In summary, this work makes the following contributions:

• We demonstrate an application of behavioral simula-
tion to smart contracts (§3-4).

• We develop an algorithm for synthesizing behavioral
simulation relations (§5-6).

• We develop a smart contract benchmark suite includ-
ing variations of identified canonical contracts (§8).

• We evaluate our approach, verifying functional prop-
erties for dozens of unannotated smart contracts (§9).



Behavioral Simulation for Smart Contracts PLDI ’20, June 15–20, 2020, London, UK

Aside from the aforementioned technical sections, we outline
our approach in Section 2, and discuss related work and
conclusions in Sections 10 and 11.

2 Overview
In this section, we overview the methodology formalized
in Sections 3-6 for synthesizing behavioral simulations. We
illustrate behavioral refinement on a running example (§2.1),
describe behavioral simulation for proving refinement (§2.2),
and demonstrate synthesis on the running example (§2.3).

2.1 Motivation
We illustrate the concept of behavioral refinement on two
contracts implementing an auction (written in the Solidity
language of Ethereum), which are partially listed in Figure 1.
These excerpts focus on the initialization and the bidding
parts of an auction. The contract RefAuction1 plays the role
of an annotated canonical implementation of an auction (we
omit the exact postconditions for brevity) while Auction is
a particular variation. We generally refer to canonical im-
plementations as reference (smart) contracts while variations
like Auction are called simply (smart) contracts.

The fields of RefAuction store information about the ben-
eficiary and the ending time of the auction, the current high-
est bidder and its bid, and the bids of previous highest bidders
(the owners of these bids have the right to reclaim them at
any point during the auction – for brevity, this functional-
ity is excluded from these excerpts). While the constructor
initializes the beneficiary and the ending time of the auc-
tion, the bid function allows a participant to pose a new
bid which is accepted only if it is bigger than the current
highest bid and the timeout did not expire. Otherwise, the
bid function has no effect on the state of the contract – if the
condition inside a require statement fails, the invocation is
reverted and is semantically equivalent to skip. This contract
also contains several functions that allow to read its fields,
in particular a bid that has been superseded by a higher one
(function PendingReturns) and the highest bid.

The contract Auction is a variation that changes the rep-
resentation of the auction ending time decomposing it into
an auction start time and a bidding duration. The handling of
revert conditions in the bid function is syntactically distinct,
but semantically equivalent to the require in RefAuction.

Despite syntactic and state representation differences, ev-
ery sequence of transactions calling methods of Auction has
the same effect as if they were calling RefAuction instead.
This relationship can be stated as Auction being a behav-
ioral refinement of RefAuction, i.e., that its behaviors are
subsumed by RefAuction. We use the term behavior to refer
to a summary of the inputs and outcomes, e.g., return values,
of a sequence of invocations.

1Extracted from the documentation page of Solidity [62].

Behavioral refinement is consistent with Liskov’s substi-
tutability principle [43], i.e., any contract can be replaced
with any of its refinements in any context, as long as a behav-
ior records all the outcomes (effects) which are observable
in a context. For the sake of this example, we will focus on
return values. Other observable effects which are relevant in
a Blockchain environment, e.g., changes on the state of other
contracts or Blockchain global variables like the balances of
external accounts, are discussed in Section 3.

For instance2,
constructor(5, a) · bid(b, 20) · bid(c, 30) · HighestBid() ⇒ 30
constructor(5, a) · bid(b, 20) · bid(c, 10) ⇒ ⊥ · HighestBid() ⇒ 20

are two possible behaviors of Auction which are also pos-
sible when calling methods of RefAuction instead (we use
the⊥ return value to signal a reverted bid invocation). More
generally, refinement holds because the conditions under
which a new bid is accepted are semantically the same even
though the two contracts use different representations of the
ending time. The constructors of these contracts ensure that
the two representations are “consistent” in the sense that

auctionEnd = auctionStart + biddingTime (1)

which implies that the timing conditions in function bid are
equivalent. Note that even though bid has no return value,
using different conditions for accepting a bid would have
been “observable” because of the “getter” method that allows
to read the highest bid at any point during an execution.

2.2 Behavioral Simulation Relations
Establishing refinement usually relies on an induction argu-
ment based on a (behavioral) simulation relation, which in
our context, is a relation between the states of the two con-
tracts supporting a proof that the reference contract mimics
every method invocation of the other contract. The simula-
tion relation supporting such a proof is defined as follows
(the fields of Auction are prefixed by # to distinguish them
from fields of the reference auction having the same name):

Sim
def
= auctionStart + biddingTime = auctionEnd (2)

∧ #beneficiary = beneficiary ∧ #highestBidder = highestBidder

∧ #highestBid = highestBid ∧ #pendingReturns = pendingReturns

This states that the fields recording bids and the beneficiary
are the same in the two contracts (pendingReturns fields
are equal when they have the same mappings), while the
fields concerning the ending time are related as mentioned
above (Equation 1). Environment (global) variables like now
are assumed to be equal in any two states related by Sim. This
models the fact that the two contracts refine one another
when embedded in the same context (where the environment
variables evolve in the same way). To simplify the technical

2For bid invocations, the caller identity and the amount of Ether it sends
are written as explicit arguments, and the return value of an invocation
(e.g., to HighestBid()) is written after ⇒. Also, we use small cap letters a,
b, c to represent values of type address.



PLDI ’20, June 15–20, 2020, London, UK Sidi Mohamed Beillahi, Gabriela Ciocarlie, Michael Emmi, and Constantin Enea

// @notice invariant ...

contract RefAuction {

uint public auctionEnd, highestBid;

address payable public beneficiary;

address public highestBidder;

mapping(address => uint) pendingReturns;

// @notice postcondition ...

constructor(uint _bidTime, address payable _benefic) public {

beneficiary = _benefic;

auctionEnd = now + _bidTime;

}

// @notice postcondition ...

function bid() public payable {

require(now <= auctionEnd && msg.value > highestBid);

if (highestBid != 0)

pendingReturns[highestBidder] += highestBid;

highestBidder = msg.sender;
highestBid = msg.value;

}

// @notice postcondition ...

function PendingReturns() public view returns (uint) {

return pendingReturns[msg.sender];
}

// @notice postcondition ...

function HighestBid() public view returns (uint) {

return highestBid;

}

}

contract Auction {

uint public auctionStart, biddingTime, highestBid;

address payable public beneficiary;

address public highestBidder;

mapping(address => uint) pendingReturns;

constructor(uint _bidTime, address payable _benefic) public {

beneficiary = _benefic;

auctionStart = now;
biddingTime = _bidTime;

}

function bid() public payable {

if (now > auctionStart + biddingTime || msg.value <= highestBid)

revert();
if (highestBidder != address(0))
pendingReturns[highestBidder] += highestBid;

highestBidder = msg.sender;
highestBid = msg.value;

}

function PendingReturns() public view returns (uint) {

return pendingReturns[msg.sender];
}

function HighestBid() public view returns (uint) {

return highestBid;

}

}

Figure 1. A canonical auction contract (left) and a variation (right), omitting withdrawal, auction-ending, and other view
functions. Implicit variables now, msg.value, and msg.sender yield block timestamps, Ether sent, and callers’ addresses.

exposition, we omit them from simulation relations. Also,
in this section, we ignore the issues related to bid being a
payable function which transfers Ether.

The initial states of the two contracts (produced after exe-
cuting the constructor) are obviously related by Sim and also,
given any two states (of Auction and RefAuction, respec-
tively) related by Sim, executing an arbitrary invocation in
Auction can be mimicked by an invocation in RefAuction
of the same method with the same arguments and return
values. Moreover, the states reached at the end of the two
invocations are again related by Sim. The latter enables an
extension of this proof to an arbitrary number of invocations.

The existence of this simulation relation implies that Auction
is a behavioral refinement of RefAuction, which implies
that it satisfies any property of RefAuction characterizing
its behaviors. Even more, since the simulation relates the
states of the two contracts, it also supports deriving valid-
by-construction inductive invariants or pre/post-condition
annotations for methods. For instance, an inductive invari-
ant of a reference contract (that holds before and after ev-
ery method invocation) can be used to define a valid-by-
construction inductive invariant for any contract that it sim-
ulates. In the context of our running example, the following
inductive invariant of the reference auction

Inv
def
= ∀i .pendingReturns[i] ≤ highestBid

implies that Sim ∧ Inv is an inductive invariant for Auction.

2.3 Simulation Relation Synthesis
We propose methodology for synthesizing such simulation
relations automatically that consists of two parts: a learn-
ing procedure for guessing simulation relation candidates
from examples (§2.3.1), and using deductive verification for
establishing the validity of the inferred candidates (§2.3.2).

2.3.1 Learning Simulations FromExamples. To gener-
ate candidate simulation relations we use a procedure based
on learning from examples, where the goal is learning a (first-
order) formula that “separates” a set of positive examples
from a set of negative examples, i.e., satisfied by all positive
examples and falsified by all negative ones. In our context,
examples are pairs of states of the contract and reference con-
tract, respectively. The positive examples must be included
in any simulation relation while the negative ones must be
excluded from any simulation. Classifying examples as posi-
tive or negative enables the re-use of any existing learning
algorithm that can produce formulas separating between the
two, e.g., [27, 28, 54, 57, 59].
The positive examples are pairs of states obtained by ex-

ecuting the same sequence of invocations (with the same
arguments) from the initial state of both the contract and
the reference contract. Such pairs of states are necessar-
ily included in every simulation under the assumption that
contracts are deterministic, which roughly, means that the
state reached by a contract when executing a sequence of
invocations is unique. These two auction contracts satisfy
this determinism assumption (this is rather straightforward



Behavioral Simulation for Smart Contracts PLDI ’20, June 15–20, 2020, London, UK

when the global variable now is assumed to be a constant;
otherwise, it is required that any modification of the envi-
ronment variable now is modeled explicitly as an invocation
to a fictitious method – see Section 3 for more details). For
instance, the following pair of states is obtained by running
constructor(2, a) ¡ bid(b, 10) ¡ bid(c, 20) in both contracts
(we write only the keys of pendingReturns that changed
with respect to the initial state):

Š­­­­­­­­­



beneficiary = a
now = 0

auctionStart = 0
biddingTime = 2
highestBid = 20
highestBidder = c

pendingReturns[b] = 10


,



beneficiary = a
now = 0

auctionEnd = 2

highestBid = 20
highestBidder = c

pendingReturns[b] = 10



ÂŞÂŽÂŽÂŽÂŽÂŽÂŽÂŽÂŽÂŽÂŹ
(3)

We generate positive examples by enumerating invocation
sequences and producing the pairs of states reached by exe-
cuting them in the two contracts.
The definition of negative examples relies on a relation

between states which compares return values of read-only
methods. As a base case, a negative example is any pair
of states that are distinguished by a read-only method, i.e.,
invoking this method on each of the two states results in
different return values. For instance, the following pair of
states are distinguished by the HighestBid method:

Š­­­­­­­­­



beneficiary = a
now = 0

auctionStart = 0
biddingTime = 2
highestBid = 20
highestBidder = c

pendingReturns[b] = 10


,



beneficiary = a
now = 0

_auctionEnd = 2

highestBid = 30
highestBidder = b



ÂŞÂŽÂŽÂŽÂŽÂŽÂŽÂŽÂŽÂŽÂŹ
(4)

The first state is obtained by calling constructor(2, a) ¡
bid(b, 10) ¡ bid(c, 20) in the Auction contract while the sec-
ond one is obtained by calling constructor(2, a)¡bid(b, 30)¡
bid(c, 20) in the reference auction. The difference between
the two sequences, i.e., the argument to the second bid, is
written in bold font (the last bid in the reference auction
sequence is not accepted because it is smaller than the pre-
vious one). Such pairs of states should be excluded from
any simulation relation because otherwise, the reference
contract cannot mimic the invocation of that particular read-
only method in the other contract. Going further, any pair
of states from which executing the same sequence of in-
vocations leads to states that are distinguishable by some
read-only method is also a negative example (this again re-
lies on the assumption that contracts are deterministic). For
instance, the predecessors of the pair of states in (4), reached
before making the last bid (i.e., bid(c, 20)), which is the same
in both contracts, is such an example:

Š­­­­­­­



beneficiary = a
now = 0

auctionStart = 0
biddingTime = 2
highestBid = 10
highestBidder = b


,



beneficiary = a
now = 0

_auctionEnd = 2

highestBid = 30
highestBidder = b



ÂŞÂŽÂŽÂŽÂŽÂŽÂŽÂŽÂŹ

contract SimulationCheck is Auction, ReferenceAuction {

// @notice postcondition Sim
constructor(uint _biddingTime, address payable _beneficiary)

Auction(_biddingTime, _beneficiary)

ReferenceAuction(_biddingTime, _beneficiary) public { }

// @notice precondition Sim
// @notice postcondition Sim
function checkBid() public payable {

r0 = Auction.bid();

r1 = ReferenceAuction.bid();

assert (r0 == r1);

}

}

Figure 2. Validating the simulation relation Sim.

As we hinted above, negative examples can also be iden-
tified based on invocation sequences, in this case two dis-
tinct ones. Therefore, their generation is oblivious to state
representations and based on an enumeration of pairs of
invocation sequences.

Note that Sim in Equation 2 is indeed a separator between
the examples described above.

2.3.2 Verifying Simulation Relations. To verify that a
simulation candidate is indeed valid we rely on deductive
verification.We generate a simulation-checking contract with
one function for each of the functions common to the input
contracts, invoking each version in turn. Figure 2 lists an
excerpt of this contract for our running example. The inheri-
tancemechanism ensures that each state of SimulationCheck
is a disjoint union of a state of Auction and RefAuction, re-
spectively. The simulation-checking contract lists the given
candidate simulation relation, in this case Sim in Equation 2,
as both a pre- and post-condition to each function (as well
as a post-condition of the constructor), and asserts that both
versions of each function yields the same results. Sim is a
valid simulation relation if all the pre/post-conditions and
assertions are satisfied by SimulationCheck.
This deductive verification step completes the proof that

Auction is a behavioral refinement of RefAuction and that
it inherits all its behavioral properties, e.g., a bid is accepted
only if it is bigger than every previous bid.

3 Behavioral Refinement
The formalization of behavioral refinement between con-
tracts relies on a simple yet universal model of computation,
namely labeled transition systems. A labeled transition sys-
tem (LTS)A = (Q, Σ, s0,δ ) over the possibly-infinite alphabet
Σ is a possibly-infinite setQ of states with initial state s0 ∈ Q ,
and a transition relation δ ⊆ Q × Σ ×Q . The ith symbol of a
sequence τ ∈ Σ∗ is denoted τi , and ϵ is the empty sequence.
An execution of A is an alternating sequence of states and
transition labels (also called actions) ρ = s0,a0, s1 . . . ak−1, sk
for some k > 0 such that δ (si ,ai , si+1) for each 0 ≤ i < k .



PLDI ’20, June 15–20, 2020, London, UK Sidi Mohamed Beillahi, Gabriela Ciocarlie, Michael Emmi, and Constantin Enea

We write si
ai ...aj−1
−−−−−−−→A sj as shorthand for the subsequence

si ,ai , ..., sj−1,aj−1, sj of ρ. (in particular si
Ďľ
−→ si ). The pro-

jection τ |Γ of a sequence τ is the maximum subsequence of
τ over the alphabet Γ. This notation is extended to sets of
sequences as usual. A trace of A is the projection ρ |Σ of an
execution ρ of A. The set of traces of an LTS A is denoted by
T (A). An LTS is deterministic if for any state s and sequence
τ ∈ Σ∗, there is at most one state s ′ such that s

τ
−→ s ′.

A contract is interpreted as an LTS whose traces represent
sequences of invocations to the contract’s methods together
with their inputs and observable outcomes. A typical ex-
ample of an observable outcome is the return value, which
can be read through invocations from other contracts. Other
examples include effects like gas consumption, changes on
the state of other contracts, changes on Blockchain global
variables like the balances of external accounts, etc. To sim-
plify the technical exposition, we will mostly focus on return
values but this is not a limitation. This LTS interpretation
is used to formalize and reason about the soundness of our
methodology. It is not intended to be constructed explicitly.

Essentially, the states of the LTS are composed of an inter-
nal part represented as assignments to the contract’s fields
and the balance of the address at which the contract is de-
ployed, and an environment part represented as assignments
to environment variables, e.g., now in Figure 1, which in-
fluence the contract’s behavior. The transitions represent
invocations to the contract’s methods or updates of the en-
vironment variables, e.g., increasing the value of now3. The
labels record method names, arguments, and observable out-
comes. For uniformity, updates of environment variables are
modeled as invocations to some fictitious methods.
Formally, an invocation label m(ÂŽu) is a method name m

along with a vector ÂŽu of argument values. An operation label
ℓ =m(®u) ⇒ v is an invocation labelm(®u) along with a return
value v . We assume a fixed, but unspecified, domain Vals
of argument or return values. Vals includes a distinguished
return value ⊥ associated to invocations that revert. We use
inv(ℓ) to refer to the invocation label in an operation label ℓ.
This notation is extended to sequences or sets of operation
labels as expected. An interface ÎŁ is a set of operation labels
over a finite set of method names. We use Σ✓ to denote the
subset of Σ that excludes operation labels with ⊥ as a return
value, andMeths(ÎŁ) to denote the method names in ÎŁ.

Definition 3.1. A (smart) contract is an LTSC = (Q, Σ, s0,δ )
over an interface ÎŁ.

Example 3.2. Figure 3 pictures a fragment of the LTS inter-
pretation of RefAuction. This LTS contains an initial state

3This LTS can be thought of as a composition between an LTS defining the
evolution of the variables controlled by the contract and an LTS defining
the evolution of the environment variables (whose states are valuations
of these variables). The states of the two LTSs share the valuation of the
environment variables (read by the first LTS and updated by the second).

Initial 
state: 

now = 0

beneficiary = d 
_auctionEnd = 10 

… 

beneficiary = a 
_auctionEnd = 5 

… 

constructor(10, d)

constructor(5, a)

bid(b, 20)

bid(c, 30)

highestBidder = b 
highestBid = 20 

balance[this] = 20 
… 

highestBidder = c 
highestBid = 30 

balance[this] = 30 
… 

bid(b, 20) => ⊥
HighestBid() => 30

add_now(7)

now = 7 
…

bid(c, 10) => ⊥

Figure 3. A fragment of the LTS interpretation of
RefAuction. Boxes represent states and arrows represent
transitions. The representation of states emphasizes the fields
changed by the incoming transition.

from where a number of transitions corresponding to con-
structor invocations are enabled. These different transitions
correspond to different sets of arguments passed to the con-
structor. As mentioned above, a state of this LTS consists of a
valuation of all the fields of RefAuction, e.g., beneficiary
and _auctionEnd, the balance of the address at which this
contract is deployed, written as balance[this], and the en-
vironment variable now. Invocations that revert, e.g., bidding
10 when the highest bid is 20, marked using the ⊥ return
value, or invocations to read-only methods like HighestBid
are represented as ";"""date"",""2021-02-19T18:56:51Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""Behavioral Simulation for Smart Contracts""
""xmp:CreatorTool"",""LaTeX with acmart 2020/02/08 v1.69 Typesetting articles for the Association for Computing Machinery and hyperref 2018/02/06 v6.86b Hypertext links for LaTeX""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""-  Software and its engineering  ->  Formal software verification.-  Theory of computation  ->  Automated reasoning.""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with acmart 2020/02/08 v1.69 Typesetting articles for the Association for Computing Machinery and hyperref 2018/02/06 v6.86b Hypertext links for LaTeX""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""Behavioral Simulation for Smart Contracts""
""modified"",""2021-02-19T18:56:51Z""
""cp:subject"",""-  Software and its engineering  ->  Formal software verification.-  Theory of computation  ->  Automated reasoning.""
""pdf:docinfo:subject"",""-  Software and its engineering  ->  Formal software verification.-  Theory of computation  ->  Automated reasoning.""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""Sidi Mohamed Beillahi, Gabriela Ciocarlie, Michael Emmi, and Constantin Enea""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.19 (TeX Live 2018) kpathsea version 6.3.0""
""meta:author"",""Sidi Mohamed Beillahi, Gabriela Ciocarlie, Michael Emmi, and Constantin Enea""
""trapped"",""False""
""meta:creation-date"",""2021-02-19T18:56:51Z""
""created"",""2021-02-19T18:56:51Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2021-02-19T18:56:51Z""
""resourceName"",""pldi20sc.pdf""
""Author"",""Sidi Mohamed Beillahi, Gabriela Ciocarlie, Michael Emmi, and Constantin Enea""
""producer"",""pdfTeX-1.40.19""
""pdf:docinfo:producer"",""pdfTeX-1.40.19""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""62"",""6"",""0"",""11"",""6"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""Keywords"",""Blockchain, Smart contracts, Refinement, Simulation""
""access_permission:modify_annotations"",""true""
""dc:creator"",""Sidi Mohamed Beillahi, Gabriela Ciocarlie, Michael Emmi, and Constantin Enea""
""dcterms:created"",""2021-02-19T18:56:51Z""
""Last-Modified"",""2021-02-19T18:56:51Z""
""dcterms:modified"",""2021-02-19T18:56:51Z""
""title"",""Behavioral Simulation for Smart Contracts""
""Last-Save-Date"",""2021-02-19T18:56:51Z""
""pdf:docinfo:keywords"",""Blockchain, Smart contracts, Refinement, Simulation""
""pdf:docinfo:modified"",""2021-02-19T18:56:51Z""
""meta:save-date"",""2021-02-19T18:56:51Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.19 (TeX Live 2018) kpathsea version 6.3.0""
""Content-Length"",""1226151""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Sidi Mohamed Beillahi, Gabriela Ciocarlie, Michael Emmi, and Constantin Enea""
""dc:language"",""en""
""dc:subject"",""Blockchain, Smart contracts, Refinement, Simulation""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""17""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""3939"",""5360"",""4947"",""4270"",""4624"",""5007"",""4466"",""4539"",""4270"",""4889"",""4656"",""4807"",""4485"",""5401"",""7241"",""7121"",""994""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""Blockchain, Smart contracts, Refinement, Simulation""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2021-02-19T18:56:51Z""
";https://scholar.google.ch/scholar?start=690&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098857-319;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;[PDF][PDF] Attacking threshold wallets;JP Aumasson, O Shlomovits ; eprint.iacr.org;;"… TSS is indeed the main building block of threshold wallets, which distribute signing rights across

multiple parties when issuing blockchain transactions … To simplify, we first set h2 = 1. Now we

are left with the following problem: You give an oracle the values a, n … In CRYPTO, 2017 …";Cité 1 fois;Les 2 versions;[PDF] iacr.org;https://eprint.iacr.org/2020/1052.pdf;"
Attacking Threshold Wallets∗

JP Aumasson†1 and Omer Shlomovits2

1Taurus Group, Switzerland
2ZenGo X, Israel

Abstract

Threshold wallets leverage threshold signature schemes (TSS) to distribute signing
rights across multiple parties when issuing blockchain transactions. These provide greater
assurance against insider fraud, and are sometimes seen as an alternative to methods us-
ing a trusted execution environment to issue the signature. This new class of applications
motivated researchers to discover better protocols, entrepreneurs to create start-up com-
panies, and large organizations to deploy TSS-based solutions. For example, the leading
cryptocurrency exchange (in transaction volume) adopted TSS to protect some of its
wallets.

Although the TSS concept is not new, this is the first time that so many TSS imple-
mentations are written and deployed in such a critical context, where all liquidity reserves
could be lost in a minute if the crypto fails. Furthermore, TSS schemes are sometimes
extended or tweaked to best adapt to their target use case—what could go wrong?

This paper, based on the authors’ experience with building and analyzing TSS technol-
ogy, describes three different attacks on TSS implementations used by leading organiza-
tions. Unlike security analyses of on-paper protocols, this work targets TSS as deployed
in real applications, and exploits logical vulnerabilities enabled by the extra layers of
complexity added by TSS software. The attacks have concrete applications, and could for
example have been exploited to empty an organization’s cold wallet (typically worth at
least an 8-digit dollar figure). Indeed, one of our targets is the cold wallet system of the
biggest cryptocurrency exchange (which has been fixed after our disclosure).

1 Introduction

Threshold signature schemes (TSS) enable a group of parties to collectively issue a signature
without exposing the secret signing key. In a (t, n)-threshold scheme, t < n, there are n
parties holding distinct key shares and any subset of t parties can issue a valid signature.
Furthermore, in practice TSS is often augmented with distributed key generation (DKG) and
reshare (refresh share, a.k.a. share rotation) protocols.

More than 30 years after Desmedt’s introduced [Des87] of the idea of threshold signing, and
15-20 years after significant progress in threshold signature construction [Sho00, aK01, MR01,
BLS04], blockchain applications have sparked a renewed interested in threshold signing, with

∗This research was previously presented at Black Hat USA 2020 under the title Multiple Bugs in Multi-Party
Computation: Breaking Cryptocurrency’s Strongest Wallets.

†Part of this work was done while the author was with Kudelski Security.

1



a fair amount of research [BDN18, GG18, DKLas18, DKLas19, DKO+19, GRSB19, Cs19,
SA19, CCL+19, CCL+20, KG20, CMP20, GG20b] (and many more).

Being often motivated by blockchain applications, where the most common signing scheme
(in transaction volume) in blockchain applications is ECDSA secp256k1, followed by Ed25519,
recent works lead to more efficient threshold signing schemes for Schnorr-like signatures (such
as EdDSA) and even ECDSA signatures. Some recent projects, including Ethereum 2, are
using BLS signatures, which make TSS relatively easy to construct thanks to their aggregation
properties.

TSS is indeed the main building block of threshold wallets, which distribute signing rights
across multiple parties when issuing blockchain transactions. These parties typically combine
systems controlled by different persons or teams, different software platforms, different cloud
providers, different on-premise of cloud hardware module (such as cloud HSM services), in
order to minimize the risks of insider fraud and external attacks. TSS is sometimes seen as an
alternative to methods using a trusted execution environment to issue the signature, and the
only way to significantly increase the security assurance when no TEE or dedicated hardware
is available (though, as noted above, TSS is sometimes used in combination with HSMs).

Organizations with a need for high-assurance wallets are for example cryptocurrency ex-
changes and regulated financial organizations (banks tend to prefer self-hosted solutions in
order to minimize the exposure of their activity to third parties, such as cloud providers),
who often manage digital assets worth hundreds of millions of dollars. TSS and other multi-
party computation-based solutions offer a viable technological building block to help protect
these assets, although their complexity and alleged lack of maturity is sometimes pointed out.
For example, the leading cryptocurrency exchange (in transaction volume) adopted TSS to
protect some of its wallets. One of the attacks described in this paper actually targets this
deployment.

This paper first describes an example of deployment and attack model found in practice,
then presents three different attacks on TSS implementations used by leading organizations.
Our attacks targets TSS as deployed in real applications, and exploit logical vulnerabilities
enabled by the extra layers of complexity added by TSS software. The attacks have concrete
applications, and could for example have been exploited to empty an organization’s cold wallet
(they have not, at least not by us). We conclude with recommendations to prevent similar
problems.

All the attacks described have been disclosed, fixed, and our understanding is that the
software in production has been updated as well.

2 Threshold Wallets in Practice

This section briefly describes a typical deployment architecture and the related threat model,
in the context of a cryptocurrency exchange. This example is based on our observations, but
omits a lot of details, and makes some assumptions on the exchange’s funds pooling model
(which varies from one exchange to another).

A cryptocurrency exchange runs an infrastructure to manage access to its liquidity (hot
and cold wallets), and allows its user to perform various transactions, including operations
via internal order books managed by a matching engine. Hot wallets retain a little part of the
funds, be it “nostro” funds or customer funds for which the exchange acts as a custodian. Hot
wallets are therefore less protected than cold wallets, be it procedurally and technologically.

2



Cold wallets, in contrast, hold most of the funds and are sometimes fully airgapped, thus
requiring a manual procedure to issue a transaction. Whether airgapped or not, cold wallet
transactions usually require the approval of several teams or sites, and TSS is the tool of
choice to perform it cryptographically.

An exchange would deploy TSS in order to avoid a single point of failure, whether this
point would be fully virtual (pure software) or a TEE. By distributing trust, TSS addresses
the risk of stolen funds, be it by an insider of an external attacker. TSS also partially addresses
the risk of lost founds through loss of access to signing capabilities, and aims to reduce DoS
risks. The risk of fund theft is also partially addressed during the key ceremony, or equivalent
process, during which the key is established (for example via DKG) and back-ups are created
and stored.

Figure 1: Example TSS deployment for hot and cold wallets.

Figure 1 illustrates two example deployments of TSS, as part of hot or cold wallets:

• Hot wallet with TSS: On the left hand, a user and the exchange have first run a
two-party key generation protocol, resulting with the user getting a share sk1 and the
exchange a share sk2. The user deposits funds to the address associated with the key
and from that point can initiate orders. Each order comes with a signature generated by
running a two-party signing protocol, and thus requires the validation of the exchange
(for example by applying business rules, AML rules, and so on).

• Cold wallet with TSS: On the right hand, a 2-of-3 TSS scheme is deployed in order to
ensure that any transaction issued from the cold wallet is approved from two authorized
systems, from different locations and managed by different IT teams. Key shares have
been previously generated via a distributed key generation protocol during a dedicated
procedure with adequate oversight, during which recovery values have been created.

In both cases, the TSS protocol can be augmented with a share refresh mechanism (proactive
security), to regularly update the value of the shares.

TSS must therefore defend against abuse from a user, and against a malicious exchange
site, be it from an insider attacker or external compromise. The typical network adversarial
model is usually realistic, we will therefore consider attackers that can intercept and modify
transmitted data.

3



Internally, TSS uses cryptographic primitives and subprotocols that are relatively com-
plex and uncommon in real-world applications: verifiable secret sharing (often Feldman’s),
homomorphic encryption (often Paillier’s), commitments, and zero-knowledge proofs.

TSS protocols performs multiple rounds of interactive communication, where parties typ-
ically validate the correctness of each round. Indeed, assuming that an attacker can com-
promise any of the parties, a party cannot assume anything about the correctness of the
messages received. This means that for any message sent, the sender needs to attach a proof
that the message was computed according to the protocol. One common way of doing it is
using zero-knowledge proofs, some of which are tailored to prove statements on particular
messages in the protocol.

Finally, in addition to potential protocol attacks, TSS deployments may suffer from im-
plementation flaws, be it logical bugs coming from a misimplementation of the protocol, or
software flaws resulting for example from parsing bugs. The software used in real applica-
tions can be an in-house implementation, potentially relying on existing open-source code, or
a commercial solution.

3 The Forget-And-Forgive Attack

3.1 The Target: Multi-Party Reshare

This attack targets the reshare protocol added to an implementation of the key generation
and threshold signature from [GG18].

Such key share refresh operation primarily aims to prevent an attacker to consecutively
compromise all systems and ultimately recover the full private key The associated protocol
would be run at regular time intervals, while maintaining access to the funds locked under
the joint public key.

Interestingly, the reshare protocol implemented is not described in [GG18], and we did not
find in the literature any practical reshare protocol in the dishonest majority setting, which
is the adversary model considered in [GG18].

The protocol in the code is based on verifiable secret sharing (VSS), and it can be sketched
as follows under a (t, n) threshold setting (note that after the protocol, n′ parties hold the
shares, where these new parties may be different from the old ones):

1. t+1 old parties transforms their Shamir-linear secret sharing into additive secret sharing
sk = w1 + ... + wt+1 where sk is the distributed secret key, unknown to all, and wi is
the secret share of sk that each old party P 0

i knows.

2. Each P 0
i samples a random polynomial, taking its degree zero coefficient to be wi.

3. Each P 0
i broadcasts commitment vector to the coefficients (as required by VSS).

4. Each P 0
i sends to each of the n′ − 1 new parties a secret share sampled as a point on

the random polynomial.

5. Each new party Pj verifies the secret shares using the VSS commitments and takes the
sum of the secret shares to be its new secret.

6. The new parties check that the old public key equals the new public key.

4



7. If all checks passed the party erases the old secret share wi and keeps only the new
secret w′

i.

We note that new parties are also generating new Paillier keys and verify them, however this
is less relevant to the attack.

3.2 The Attack

The attack aims to prevent parties running the reshare protocol from holding valid shares
(both from the old and new set), and therefore prevent them from collectively issue transac-
tions, thereby locking the group of parties out of their wallet.

Under the adversary model considered by the paper and implementation, we are allowed
to corrupt t out of the t+1 old parties running the protocol. For example, in a (3, 5) threshold
setup, our attack would corrupt three parties.

In the attack, a corrupted old party will send “bad” secret shares to some parties of the
n′ parties, and “good” secret shares to the others, where “good” means that it will pass the
validation at step 5, and “bad” means that it won’t. Non-corrupted parties will then act as
follows, upon receiving the attacker’s shares:

• The new parties that got “good” shares will continue the protocol and will finish it
successfully, therefore overwriting their old secret share with a new one.

• The new parties that got “bad” secret shares will abort the protocol and will keep their
old secret share.

Old secret shares and new secret shares combined are not additive shares of sk anymore, hence
cannot be used to issue a signature. The attacker effectively deleted the secret shares for one
of the subsets. On the implementation analyzed, the attack will work because participants
will not check that all VSS verifications succeeded prior to erasing their local shares.

3.3 Exploitation

The goal of an attacker could be to fully eliminate the capability to issue a transaction, by
performing the attack on consecutive runs of the reshare protocol in a way that the honest
parties cannot reach the required threshold. If the organization has insufficient back-up, the
attacker could blackmail the exchange.

Note that the attack can be extended to the setting where no single party is corrupted,
but where instead a network attacker corrupts carefully selected messages in order to itera-
tively minimize the capability to issue a valid signature. In the case of cold wallets, where
transactions do not occur frequently, the attack might take some time to be detected, thereby
allowing the attacker to corrupt multiple iterations of the reshare protocol in order to ulti-
mately lock the organization out of its wallet.

3.4 Mitigation

To prevent the attack, and more generally to prevent the associated class of attacks leveraging
failed VSS validations, a “blame phase” must be introduced in the protocol in order to identify
failures (accidental or malicious). This was observed in classical works on distributed key
generation (see the “complaints” broadcast in [GJKR07, Fig.2]).

5



If the blame phase observes a dishonest majority, then there is not much to do besides
aborting the protocol before rewriting the secret. Therefore the solution is to add another
round of communication in which parties can ask the other honest parties to abort the protocol
before deletion of the key material.

The maintainers who implemented the fix described it as follows: “a final round has been
added to the re-sharing protocol where the new committee members send ACK messages to
members of both the old and new committees. Each participant must receive ACK messages
from n members of the new committee (excluding themselves) before they save any data to
disk.”

4 The Lather, Rinse, Repeat Attack

4.1 The Target: Two-Party Reshare

This attack targets an implementation of two-party ECDSA [Lin17] aimed for commercial
deployment and thus production usage. As in general TSS, a secure deployment of wallets
with two-party signature requires period share refresh, for example after every transaction.
This is conceptually similar to our first scenario (that of the Forget-and-Forgive attack), but
the underlying protocol is different.

4.2 The Attack

The attack allows one of the two participants to extract information on the other participant’s
key share, and ultimately to sign transactions without involving the second party, thereby
defeating the purpose of the protocol.

The vulnerability targets the following part of the reshare protocol, where the values
updated are a party’s Paillier keypair, and the other party’s ciphertext encrypted the first
party’s key share using their Paillier public key. The steps are the following, between parties
Alice (the prover, initially owning the share x1)and Bob (the verifier, owning x2):

1. Alice generates a new Paillier keypair

2. Alice sends a new ciphertext c′ = Enc(x′1) under the new Paillier key, encrypting the
new share x′1 = x1 + r, where x1 is the old share and r a random value.

3. Alice proves in zero knowledge to Bob that there is a linear relation between the value
encrypted in the new ciphertext and the value encrypted in the old ciphertext, that is,
Alice proves that c′ = c ⊕ Enc(r), where c = Enc(x1) is a ciphertext of the old share
under the old Paillier key.

The problem is in this last step, where Alice proves a statement about c′. The zero-knowledge
proof implementated seems to be taken from [Bou00, Appendix A] (refering general forms
in [CM99, BT99]), which notes the following about the two moduli n1 and n2: “ Let n1 be a
large composite number whose factorization is unknown by Alice and Bob, and n2 be another
large number, prime or composite whose factorization is known or unknown by Alice.”

In the implementation analyzed, however, Alice knows both factorizations of n1 (old n)
and n2 (new n), and can leverage this to cheat: Alice can convince Bob that the new Paillier
ciphertext is an encryption of any value chosen by the prover, which gives Alice an oracle to
learn bits of x2.

6



After some experimentation with the code, we found the right constants to enable the
attacker to transform to any x′1. In a correct execution, the new secret share of Alice should
have been x′1 = x1 + r, where r is a result of a coin flip protocol. For our attack we augment
the new secret share to be x′′1 = x′1 + k · q such that |ni| − q ≤ x1 + k · q < |ni| where q is the
curve’s order.

After Bob homomorphically combines x′′1 with its own rotated secret share x′2 = x2−r, the
randomness r cancels out and we are left with a ciphertext that contains x12 = x1 + x2 + kq.
As part of [Lin17] signing protocol, Bob sends this ciphertext to Alice who decrypts it and
reduces it mod q operation. The decryption, done first, involves a mod ni reduction, which
under correct execution is guaranteed to not change the value (using the range proof we just
bypassed). This gives us the following oracle:

• If x2 < ni− kq−x1, the mod ni will not change the decrypted value and the eventual
signature verification will return true

• If x2 > ni − kq − x1, the decrypted value will be changed due to a single mod ni and
the eventual signature verification will return false

This oracle gives Alice (the attacker) roughly one bit of x2. To learn more information about
x2 the reshare-sign pair of protocols must be run again. Since in each run the value ni is
changing, the oracle will give us a new equation on the value of x2. To conduct the full
attack, many such reshare-sign runs are required. Optimally, if each run leaks one new bit of
information, the number of runs is the bit size of x2.

4.3 Exploitation

The exploitation scenario is quite straightforward: one of the two parties will gain privilege
to sign without approval of the second after running sufficiently many rounds of reshare. We
did not perform a detailed analysis of the expected number of attempts and of the optimal
share recovery method, but these are clearly practical.

For example, in the case of of a hot wallet with approval rights shared between a user and
an exchange (as in our example in §2), a compromised exchange could perform the attack in
parallel against a multitude of users in order to steal all of users’ funds without their approval,
thereby circumventing the security guarantees promised by the two-party signing.

4.4 Mitigation

Although a quick fix would be to implement some kind of rate limiting and error detection,
a real fix must address the problem as its root, namely the protocol. We suggest to use the
proof in [CGM16, §4.2] but with composite groups instead of prime ones. However, this will
probably be less efficient than simply repeating the relevant steps from [Lin17] two-party
protocol which is what the library maintainers resolved to as solution, changing drastically
the reshare protocol. In the updated version, Alice and Bob run a coin flip to change their
secret shares and repeat the zero knowledge proofs from two party Key Generation protocol.
The performance of this new protocol is thus similar to the two party key generation, which
is much slower than the initial reshare protocol.

7



5 The Golden Shoe Attack

5.1 The Target: MtA Share Conversion

This attack targets an implementation of the threshold ECDSA scheme from [GG18], but a
different one than the one attacked in §3, and a different subprotocol.

The vulnerability lies in the share conversion subprotocol [GG18, §3], a two-party protocol
that transforms secret multiplicative inputs to secret additive inputs. That is, if Alice holds
a and Bob holds b such that the shared secret is x = ab mod q, the protocol determines ι, β
that satisfy α + β = x. This kind of protocol is commonly refered to “MtA” (multiplicative
to additive) in specifications and implementations.

Furthermore, the MtA protocol requires zero-knowledge proofs [GG18, Ap.A], so that each
party demonstrates the validity of its message. The attack description below reuses notations
from that paper.

5.2 The Attack

5.2.1 The Missing Validation

As part of the zero-knowledge proofs setup, each party (acting as verifier) must generate an
auxiliary RSA modulus Ñ and two random values h1, h2. These values must be publicly
verifiable and tested, as the paper notes.

However, in the code, those values are not tested by the receiving party acting as the
prover. This can be exploited to let a single party extract the secret shares of all other parties
and effectively the full private key during a single threshold signature generation.

The values Ñ , h1, h2 must satisfy to certain properties, as described in [FO97, §3] under
“setup procedure” and in [MR01, SS6.2] under strong RSA. Some of the properties ensure
the proof’s soundness (verifier is motivated to choose them correctly), however there is one
condition that is crucial to ensure zero knowledge. Quoting [MR01]:

Zero knowledge requires that discrete logs of h1, h2 relative to each other modulo
Ñ exist (i.e. that h1, h2 generate the same group).

Moreover, [GG18] explicitly says that Ñ , h1, h2 must be proven correct to the receiver.
However, when during key generation a party receives these values from other parties, not

a single test is implemented. The receiving party simply trusts the tests done by the sender
and saves the values in memory, which is kind of the same problem as client-side validation in
web applications. A malicious sender can therefore send any Ñ , h1, h2 she wants. Note that
previous papers describe the tests/proofs to be made or assume these values are generated
by a trusted third party.

5.2.2 How the Attack Works

We now explain how to exploit the absence of proofs. We first note that in our attack the
signing will not fail. In fact, it is extremely hard (impossible) to choose the values in a way
that will fail signing.

We will focus on the first range proof [GG18, SSA.1] because this is the simplest. In this
range proof, the receiver that got the spoofed Ñ , h1, h2 is now the prover and the sender

8



becomes the verifier. This proof is done for each pair of parties. Therefore a single verifier
can repeat the attack with all other signing parties.

In the first step of the range proof, the prover computes z = hm1 h
ρ
2 mod Ñ where m is

the secret share of the prover and ρ is random number the prover generates. z is sent to
the verifier. The prover basically send a Pedersen commitment in a group of unknown order.
(See [LN18, SS6.2.4], which uses almost identical proof but describes it in terms of Pedersen
commitments.).

If the values are proven to be chosen according to the protocol this is indeed a correct
commitment and breaking it is hard as breaking discrete log. However, if we are allowed to
choose Ñ , h1, h2 as we wish, we can make the commitment insecure. To simplify, we first set
h2 = 1. Now we are left with the following problem: You give an oracle the values a, n, which
correspond to h1, Ñ , and get a value b, corresponding to z, such that b = ax mod n. We need
to find x (which is the secret share of the proving party).

The easiest way to solve that problem is to choose n to be very large such that ax is
computed over the integers. In that case by trial and error (checking ay smaller than or
larger than the given b for different values of y) we can recover the prover secret share in 256
trials.

A somewhat more complex solution (however, completely achievable) is to choose n to
be a composite with small prime factors: Then we can use Polling-Hellman and field sieve
algorithm on each factor (see [KL14, Ch.9]). This problem is extremely parallelizable. In fact,
the breaking of Moscow voting system [GG20a] follows the same type of attack—computing
discrete log for small primes.

5.3 Exploitation

To exploit the attack in a realistic setting, an attacker must control at least one of the parties
and can then perform the attack against each of the other participants. It can then recover
shares of other parties and ultimately single-handedly issue unauthorized transactions.

Note that wallet systems of exchanges and other critical organizations, there are often
several layers of defenses, including systems to filter unauthorized transactions. These may
use address blacklist/whitelist systems, AML scoring, rules on metadata, etc. However, an
attacker familiar with these may still circumvent the control mechanisms.

5.4 Mitigation

The fix is simple: Ñ , h1, h2 must be validated on the receiving end. For Ñ , the sender must
attach a proof that Ñ is a valid RSA modulus from two safe primes. There are various ways
to prove it, the latest is from [GRSB19] (see [LN18] on the recommended parameters to use).
For h1, h2 there is a nice trick in [FO97]: pick h1 at random and h2 = hÎą1 and prove to the
receiver the knowledge of Îą with respect to h1, h2.

The affected software was patched by adding the required proofs, and users were required
to upgrade their application. CVE-2020-12118 was assigned.

6 Recommendations

Relatively simple protocols establishing a secure channel, such as TLS and SSH, and imple-
mentations thereof, had many issues of variable severity, often discovered years after their

9



first deployment. It’s therefore prudent to assume that complex multi-round protocols in-
volving advanced primitives are not completely bug-free, be it in terms of protocol attacks or
implementation vulnerabilities.

In order to minimize the risk, an organization creating and deploying such protocols may
consider the following recommendations:

• Create implementations whose code closely follows the specifications on paper, refering
to specific sections or lines via source code comments, and using similar notation and
variable names. This facilitates validation, testing, and auditing of the code.

• Closely pay attention to all the constraints described in the paper, especially when
it’s about proofs of correctness. Sometimes such constraints are only loosely defined,
and another paper is refered. Sometimes the constraints are implicit and considered
“obvious” by the authors, or mentionned somewhere else in the paper.

• Identify any gaps between on-paper and real deployment, in terms of adversarial model,
trust assumptions, communication synchronicity, and so on.

• Ensure that there are controls to validate proper execution of the protocol and correct-
ness of the values received.

• Upon abort of the protocol, make sure that it gracefully fails and that no data is leaked
(unlike in our second attack).

• Be careful when composing different protocols, either sequentially or as subprotocols

• When performing security audits, you may consider hiring different teams for the pure
cryptographic/protocol aspects, and for the code safety. Prefer teams demonstrating
concrete experience with the protocol to be audited, and ideally people who already
wrote similar code.

References

[aK01] Ivan Damg̊ard and Maciej Koprowski. Practical threshold RSA signatures with-
out a trusted dealer. In EUROCRYPT, 2001. https://iacr.org/archive/

eurocrypt2001/20450151.pdf.

[BDN18] Dan Boneh, Manu Drijvers, and Gregory Neven. Compact multi-signatures for
smaller blockchains. In ASIACRYPT, 2018.

[BLS04] Dan Boneh, Ben Lynn, and Hovav Shacham. Short signatures from the Weil
pairing. J. Cryptology, 17, 2004.

[Bou00] Fabrice Boudot. Efficient proofs that a committed number lies in an interval. In
EUROCRYPT, 2000. https://www.iacr.org/archive/eurocrypt2000/1807/

18070437-new.pdf.

[BT99] Fabrice Boudot and Jacques Traoré. Efficient publicly verifiable secret sharing
schemes with fast or delayed recovery. In ICICS, 1999.

10

https://iacr.org/archive/eurocrypt2001/20450151.pdf
https://iacr.org/archive/eurocrypt2001/20450151.pdf
https://www.iacr.org/archive/eurocrypt2000/1807/18070437-new.pdf
https://www.iacr.org/archive/eurocrypt2000/1807/18070437-new.pdf


[CCL+19] Guilhem Castagnos, Dario Catalano, Fabien Laguillaumie, Federico Savasta, and
Ida Tucker. Two-party ECDSA from hash proof systems and efficient instanti-
ations. Cryptology ePrint Archive, Report 2019/503, 2019. https://eprint.

iacr.org/2019/503.

[CCL+20] Guilhem Castagnos, Dario Catalano, Fabien Laguillaumie, Federico Savasta, and
Ida Tucker. Bandwidth-efficient threshold EC-DSA. Cryptology ePrint Archive,
Report 2020/084, 2020. https://eprint.iacr.org/2020/084.

[CGM16] Melissa Chase, Chaya Ganesh, and Payman Mohassel. Efficient zero-knowledge
proof of algebraic and non-algebraic statements with applications to privacy pre-
serving credentials. In CRYPTO, 2016.

[CM99] Jan Camenisch and Markus Michels. Proving in zero-knowledge that a number is
the product of two safe primes. In EUROCRYPT, 1999.

[CMP20] Ran Canetti, Nikolaos Makriyannis, and Udi Peled. UC non-interactive, proactive,
threshold ECDSA. Cryptology ePrint Archive, Report 2020/492, 2020. https:

//eprint.iacr.org/2020/492.

[Cs19] Daniele Cozzo and Nigel P. smart. Sharing the LUOV: Threshold post-quantum
signatures. Cryptology ePrint Archive, Report 2019/1060, 2019. https://

eprint.iacr.org/2019/1060.

[Des87] Yvo Desmedt. Society and group oriented cryptography: A new concept. In
CRYPTO, 1987.

[DKLas18] Jack Doerner, Yashvanth Kondi, Eysa Lee, and abhi shelat. Secure two-party
threshold ECDSA from ECDSA assumptions. Cryptology ePrint Archive, Report
2018/499, 2018. https://eprint.iacr.org/2018/499.

[DKLas19] Jack Doerner, Yashvanth Kondi, Eysa Lee, and abhi shelat. Threshold ECDSA
from ECDSA assumptions: The multiparty case. Cryptology ePrint Archive,
Report 2019/523, 2019. https://eprint.iacr.org/2019/523.

[DKO+19] Anders Dalskov, Marcel Keller, Claudio Orlandi, Kris Shrishak, and Haya Shul-
man. Securing DNSSEC keys via threshold ECDSA from generic MPC. Cryptol-
ogy ePrint Archive, Report 2019/889, 2019. https://eprint.iacr.org/2019/

889.

[FO97] Eiichiro Fujisaki and Tatsuaki Okamoto. Statistical zero knowledge protocols to
prove modular polynomial relations. In CRYPTO, 1997.

[GG18] Rosario Gennaro and Steven Goldfeder. Fast multiparty threshold ECDSA with
fast trustless setup. In ACM SIGSAC Conference on Computer and Communica-
tions Security, 2018.

[GG20a] Pierrick Gaudry and Alexander Golovnev. Breaking the encryption scheme of the
Moscow internet voting system. In Joseph Bonneau and Nadia Heninger, editors,
Financial Cryptography and Data Security, 2020.

11

https://eprint.iacr.org/2019/503
https://eprint.iacr.org/2019/503
https://eprint.iacr.org/2020/084
https://eprint.iacr.org/2020/492
https://eprint.iacr.org/2020/492
https://eprint.iacr.org/2019/1060
https://eprint.iacr.org/2019/1060
https://eprint.iacr.org/2018/499
https://eprint.iacr.org/2019/523
https://eprint.iacr.org/2019/889
https://eprint.iacr.org/2019/889


[GG20b] Rosario Gennaro and Steven Goldfeder. One round threshold ECDSA with
identifiable abort. Cryptology ePrint Archive, Report 2020/540, 2020. https:

//eprint.iacr.org/2020/540.

[GJKR07] Rosario Gennaro, Stanislaw Jarecki, H";"""date"",""2020-08-31T15:49:56Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2020-08-31T15:49:56Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.21 (TeX Live 2020) kpathsea version 6.3.2""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2020-08-31T15:49:56Z""
""created"",""2020-08-31T15:49:56Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-08-31T15:49:56Z""
""resourceName"",""1052.pdf""
""Author"",""""
""producer"",""pdfTeX-1.40.21""
""pdf:docinfo:producer"",""pdfTeX-1.40.21""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""2"",""2"",""5"",""8"",""6"",""6"",""0"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2020-08-31T15:49:56Z""
""Last-Modified"",""2020-08-31T15:49:56Z""
""dcterms:modified"",""2020-08-31T15:49:56Z""
""title"",""""
""Last-Save-Date"",""2020-08-31T15:49:56Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2020-08-31T15:49:56Z""
""meta:save-date"",""2020-08-31T15:49:56Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.21 (TeX Live 2020) kpathsea version 6.3.2""
""Content-Length"",""376853""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""12""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""2329"",""3058"",""1996"",""2434"",""2409"",""2471"",""2533"",""2359"",""2587"",""2077"",""2160"",""1388""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-08-31T15:49:56Z""
";https://scholar.google.ch/scholar?start=860&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098747-61;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Le offerte iniziali e gli scambi di cripto-attivitŕ (Initial Offers and Exchanges of Crypto-Assets);V Villanueva Collao ; CONSOB, Le offerte iniziali e gli scambi di …, 2020  papers.ssrn.com;;"… interessante che tutte queste tecnologie, operano attraverso lo sfruttamento di Oracles (nel

linguaggio … allo stato noti, di circuiti per la negoziazione di crypto- asset? Sě. Tuttavia, occorre

sottolineare - specialmente nelle DTL totalmente decentralizzate, tipo blockchain - che nell …";;null;null;;;;https://scholar.google.ch/scholar?start=610&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098795-172;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Running Transactional Business Processes with Blockchain's Smart Contracts;A Brahem, N Messai, Y Sam, S Bhiri… ; … Conference on Web …, 2020  ieeexplore.ieee.org;;"… In more details, oracles forward a request from external application to the SC via a Solidity event

and … iv) We add also endorsement for events in the “Oracle SC” to … V. RELATED WORK Recent

works use the blockchain as a coordination mech- anism to implement the control flow …";Autres articles;;[PDF] archives-ouvertes.fr;https://hal.archives-ouvertes.fr/hal-03046990/document;"
HAL Id: hal-03046990
https://hal.archives-ouvertes.fr/hal-03046990

Submitted on 8 Dec 2020

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L’archive ouverte pluridisciplinaire HAL, est
destinĂŠe au dĂŠpĂ´t et Ă  la diffusion de documents
scientifiques de niveau recherche, publiĂŠs ou non,
émanant des établissements d’enseignement et de
recherche français ou Êtrangers, des laboratoires
publics ou privĂŠs.

Running transactional business processes with
blockchain’s smart contracts

Amina Brahem, Nizar Messai, Yacine Sam, Sami Bhiri, Thomas Devogele,
Walid Gaaloul

To cite this version:
Amina Brahem, Nizar Messai, Yacine Sam, Sami Bhiri, Thomas Devogele, et al.. Running transac-
tional business processes with blockchain’s smart contracts. ICWS 2020: IEEE International Confer-
ence on Web Services, Oct 2020, Beijing (online), China. pp.89-93, �10.1109/ICWS49710.2020.00019�.
�hal-03046990�

https://hal.archives-ouvertes.fr/hal-03046990
https://hal.archives-ouvertes.fr


Running Transactional Business Processes with Blockchain’s Smart Contracts

Amina Brahem1,2∗, Nizar Messai1†, Yacine Sam1‡, Sami Bhiri2§, Thomas Devogele1¶, Walid Gaaloul3‖
1LIFAT, University of Tours, Tours, France

2OASIS, National Engineering School of Tunis, University Tunis El Manar, Tunis, Tunisia
3Telecom SudParis, UMR 5157 Samovar, University Paris-Saclay, Paris, France

Email: ∗ brahem.amina@gmail.com, †‡¶firstname.lastname@univ-tours.fr, §sami.bhiri@gmail.com,
‖ walid.gaaloul@telecom-sudparis.eu

Abstract—Smart Contracts (SC for short) are gaining mo-
mentum as a suitable technology for ensuring trusted execution
of Business Processes (BP for short) in open environment.
Nevertheless, the transactional semantics of SC which follow
ACID transactions are not appropriate for BP characteristics.
Indeed, it is admitted that ACID transactions are limited
to cope with complex control structure and long running
execution of BP. Transactional Business Processes (TBP for
short) have emerged as an extension to ACID models to
overcome these limits. A TBP ensures transactional reliability
of advanced transactions having a control structure as complex
as for BP. In this paper, we propose an approach that builds on
SC and extends them to implement TBP. We extend Caterpillar,
an existing BP execution engine developed on top of Ethereum,
to implement our approach and support the execution of TBP.

Keywords-Business Processes; Transactional Business Pro-
cesses; Open and untrusted environment; Blockchain; Smart
Contracts.

I. INTRODUCTION

The advent of the Blockchain technology with its two
generations created in last years a huge amount of interest
across various industries and academic communities due
to its mechanisms to ensure trust in open and distributed
execution environments . The first generation of blockchain
allows only sending and receiving monetary values of
cryptocurrencies such as the Bitcoin. While the second
generation, also called the Smart Contracts (SC) blockchain,
enables more complex applications like a valid car sale,
a loan assessment, voting or health care tracking. A SC
is simply a program enforcing the terms of the agreement
between untrusted parties.

SC are gaining momentum as a suitable technology for
ensuring trusted execution of Business Processes (BP for
short) and BP collaborations in open environment [1], [2].
Nevertheless, the transactional semantics of SC are the same
as in ACID models [3], [4]. Consequently, we argue that
bare SC are limited to support transactional requirements of
BP executions. Indeed, it is admitted that ACID transactions
are limited to cope with complex control structure and long
running execution of BP [5], [6]. Besides, the rollback
mechanism in BP is not as obvious as for conventional
database operations.

Transactional Business Processes (TBP for short) [6],
[7] have emerged as an extension to ACID transactions to
overcome these limits. More precisely, TBP bring together
Business Processes and Advanced Transactional Models [5],
[8]. For the former, they ensure transactional correctness. For
the latter, they support large flow-based applications having
complex control structure. A TBP defines a transactional
flow on top of the control flow. The transactional flow
englobes transactional properties of the BP activities (pivot,
compensatable, retriable) and transactional mechanisms. The
latter include recovery mechanisms such as compensation
as backward recovery and alternatives as forward recovery.
This definition of the transactional flow was largely inspired
from one of the Advanced Transaction Models which is the
Flexible Transactional Model [5].

In this paper, we propose an approach that builds on SC
and extends them to implement TBP. We extend Caterpillar
[9], an existing BP execution engine developed on top of
Ethereum, to implement our approach and support the exe-
cution of TBP. Caterpillar takes a Business Process Model
Notation (BPMN) 2.0 1 specification as input and generates
the corresponding control flow in a SC.

Our approach implements a TBP where its control flow
is given as input and its transactional flow follows the
Flexible Transactional Model principles. The generated SC
implements both the control flow and the transactional flow.

For the implementation of our approach, we use scenarios
related to touristic trip planning.

The remainder of this paper is structured as follows. A
motivating scenario is presented in Section 2. In Section 3,
we introduce background concepts. We detail our approach
in Section 4. Section 5 discusses the related work. Finally,
we conclude in Section 6.

II. MOTIVATING SCENARIO

We consider a motivating scenario of a tourist who wants
to order a personalized package for her/his visit to the
Château of Tours 2. However, the choices offered to the
tourist in terms of the “ways” to visit the châteaux are

1BPMN 2.0 standard definition: https://www.omg.org/spec/BPMN/2.0
2https://www.loirevalley-france.co.uk/loire-chateaux



Figure 1. Personalized touristic package ordering process. In colors: the transactional flow

limited. She/he either buys individual tickets or chooses
one of the very few predefined packages at the available
web sites and which may not entirely reach her preferences.
As a matter of fact, offering a customized or personalized
service is a concept which is more and more used in the
domain of tourism, especially in trip planning [10]. Here, we
model a scenario of a tourist who wants to visit the châteaux
“along the river of the Cher” and thus designs and buys her
personlized package. She enters order for a personnalized
package (EOPP). She selects the châteaux that she wants
to be included in the package such as the “château of Vil-
landry” (SCVil), the “château of Chenonceau” (SCChe) and
the “château of Valençay” (SCVal). Then, after confirming
her choice of the package (CCP), she pays using one of
the available payment methods: credit card (PCC) or paying
on-the-spot (POS).

If we try to add a valid transactional flow to the presented
model according to transactional semantics in the Flexible
Transactional Model (see Figure. 1), when PCC fails, POS
will be activated as an alternative and the process ends in a
consistent state given the fact that POS always terminates
successfully. The transactional flow contains as well the
following failure recovery mechanisms: (i) in case of failure
of CCP, the work already done has to be compensated, i.e.,
selection of the package components as well as EOPP;
(ii) if SCVil fails, it will cancel the other tasks running in
parallel or compensate them if they have already completed
their work.

To motivate our choices of the used technologies, first,
the present scenario involves multiple participants, i.e., the
tourist and payment services. Thus, we are in the case of a
distributed execution where there is a need for trust and here
comes our choice of SC technology that alleviates the need
for a central orchestrator and ensures trust. For (partial) fail-
ure handling and ensuring transactional correctness, we use
the transactional mechanisms embedded in the transactional
business processes, particularly in the flexible transactional
model. In the next section, we give an overview of principal

concepts related to our work.

III. BACKGROUND CONCEPTS

A. Blockchain and Smart contracts

A blockchain [11] is a distributed ledger where data is
organized in sequence of blocks equivalent to containers
of transactions. The blockchain network is maintained by
independent computers referred to as nodes or peers that do
not know or trust each other but can connect and cooperate
to validate transactions executed on the blockchain. After
validation, peers record, share and synchronize transactions
in their respective electronic ledgers. The first generation
of blockchain allows only sending and receiving monetary
values (e.g., Bitcoin).

In the SC blockchain, meanwhile, a transaction allows
more complex operations such as the creation of a SC
and stores the results of function calls in SC. A SC can
be defined as a computer program enforcing the terms of
the agreement between untrusted parties about a valid car
sale or a loan assessment or voting or health care tracking,
etc. Any user can create a SC by posting a transaction
in the Blockchain. Once created, the contract is assigned
to a unique address (a secure identifier) used to interact
with that particular contract [12]. A SC is written in a SC-
specific programming languages like Solidity for Ethereum.
It is then compiled into ‘bytecode’ that is read and run on
the ‘ethereum virtual machine’ (EVM). A SC can define
multiple entry points of execution (function calls). After a
contract finishes processing a message it receives, it can send
back a return value to the sender. The contract’s state will
then be updated accordingly.

SC cannot exchange data with off-chain world directly.
Henceforth, Oracles are of common use in this case. Oracles
are real-time data feeds that act as mediator between SC and
external world. In more details, oracles forward a request
from external application to the SC via a Solidity event and
receive corresponding response via a contract function call.



We can trust the entire system of the blockchain because,
first, everyone in the blockchain keeps a (partial or full) copy
of the chain and can check what is exactly happening in
the blockchain. Furthermore, transactions on the blockchain
are agreed i.e., a transaction is accepted when the majority
of the network have a concensus on its validity. Finally,
transactions are immutable, they cannot be revoked and state
changes cannot be undone. Trust in the correct execution
of SC extends directly from regular transactions since their
creation function calls result from blockchain transactions.

B. Transactional Processes

The transactional approach initially emerged in the con-
text of database management systems with ACID models.
The attractiveness of this approach is due to its simplicity
and systematic way to handle failures. This lead to its
adoption to the context of flow-based applications. However,
ACID models turned to be restrictive to support such appli-
cations [5], [6]. The latter may have more complex control
structure than a simple sequence of read/write operations and
a long running execution. Besides, the rollback mechanism
is not as obvious as for conventional database operations.

Advanced Transaction Models (ATM)

ATM extend the definition of flat ACID transactions.
They relax the atomicity property to define instead the
“failure atomicity” or partial failure of a process activity
[8]. In addition, they relax isolation property to allow high
inter-process concurrency handling and compensation as
backward recovery.

Later appeared the Flexible Transactional Model (FTM)
[5] which implements many transactional mechanisms at one
time. The FTM is appropriate to business processes with
complex control structure. It includes many transactional
mechanisms: (i) it allows failure atomicity; (ii) it permits
alternatives as forward recovery ; (iii) compensation as
backward recovery and (iv) assigns termination properties
to process activities (compensatable, pivot, retriable). Let’s
come back to our motivating scenario illustrated in Figure.
1:

• SCVil is compensatable which means that its undesir-
able effects can be reversed after completion through
the execution of its compensation activity. The latter is
an additional activity that serves to reverse the effects
of the main compensatable activity.

• CCP is pivot, i.e., it (a) completes successfully or
(b) fails and compensate the work already done. Once
completed successfully, it is a no-return point in the BP
execution.

• POS is retriable, i.e., it will surely terminate
with success after a certain number of
{failure → reactivation} attempts.

• An activity can be also effect-free when it is considered
that its completion has no effect to be compensated.

Transactional Business Processes (TBP)

Transactional Business Processes (TBP for short) bring
together business processes and Advanced Transactional
Models [6], [7]. For the former, they ensure transactional
correctness. For the latter, they support large flow-based
applications with having complex control structure. A TBP
has two perspectives: the control flow and the transactional
flow. The control flow describes the order in which process
activities are activated as well as an execution preference
order among alternatives.

The transactional flow englobes a set of transactional
properties assigned to business process activities. Transac-
tional properties are the equivalent of termination properties
in the FTM, i.e., compensatable, pivot and retriable. The
transactional flow describes as well the different trans-
actional mechanisms to enable a BP either to complete
successfully or fail ”properly”. Following an activity failure,
the transactional flow: (i) tries first to execute an alternative
if it exists; (ii) otherwise in case of a fatal failure (i.e., no
alternative) causing the overall BP failure it compensates the
work already done and (iii) cancel all running executions in
parallel.

In the next Section, we present the proposed approach
consisting in extending bare SC to support the execution of
Transactional Business Processes.

IV. SMART CONTRACT-BASED TRANSACTIONAL
BUSINESS PROCESS: DESIGN PRINCIPLES

Our approach builds on an existing BPM system devel-
oped on top of Ethereum plateform called Caterpillar [9].
Caterpillar takes a BPMN 2.0 specification as input and
generates the corresponding control flow in a SC.

We extend Caterpillar in order to implement in addition
the transactional flow. Our approach implements a Trans-
actional Business Process (TBP) where its control flow
is given as input and its transactional flow follows the
Flexible Transactional Model principles. The generated SC
implements both the control flow (Section IV-A) and the
transactional flow (Section IV-B).

A. Implementing the control flow

Caterpillar logic for implementing the control flow relies
on simulating the token game and defining treatment to
execute for each state of an activity’s life cycle [1]. The
life cycle of a process activity is: enabled → started →
completed.

To do so, Caterpillar uses a Solidity code generator called
“BPMN-to-Solidity template” that generates the Solidity
code of the called “Process SC” from a given BPMN
specification. Depending on the position of the token in
the process, the template generates predefined functions to
execute in the “Process SC”.



Caterpillar uses as well a second Solidity code generator
which is the “Oracle-to-Solidity template”. This template
produces the code of the “Oracle SC”. The Oracle SC is
associated to the Process SC and handles the interaction of
the latter with external users and applications. For instance,
it publishes a Solidity event in the Ethereum log when a
user task is started. It also can read data from the Process
SC to return to the external user.

B. Implementing the transactional flow

We build on the logic of Caterpillar tool to implement the
transactional flow. First, we assign transactional properties
to process activities and enrich process activities life cycles
with transactional states in order to model their transac-
tional properties. Then, we modify the Solidity code gen-
eration templates (BPMN-to-Solidity and Oracle-to-Solidity
templates) in a way that, depending on the transactional
properties of the activity, the templates generate functions
to execute for each of the transactional states.

1) Extending activity life cycle: Each process activity has
one or many transactional properties, i.e., pivot, compensat-
able and retriable. The only termination state of an activity in
Caterpillar is completed. We add in addition four other pos-
sible termination states which are aborted, cancelled, failed
and compensated which we call transactional termination
states.

A pivot activity (Figure. 2a) (similarly to compensatable
and retriable activities) is initially at the state enabled.
Then, some event may occur and lead to an early abortion
(state aborted) or nothing happens and the activity is started.
During its execution, an activity can be cancelled. There are
next two possibilities: (a) the activity completes successfully
and reaches the state completed; (b) it fails and meets the
state failed. In addition to that, a compensatable activity
effect could be compensated (Figure. 2b). Whereas a retri-
able activity can be reactivated after failure via the retry()
transition (Figure. 2c). Finally, an activity can combine
two transactional properties like being compensatable and
retriable (see Figure. 2d).

2) Implementing transactional mechanisms: We bring the
following modifications to the Solidity code generation tem-
plates. In this way, the “Process S.C” and the “Oracle S.C”
are enriched to implement the transactional mechanisms
upon the extended life cycle:

(i) We define for each process task called ActivityName,
a state vector named StateVector ActivityName to capture
the activity state’s evolution in the “Process S.C”. StateVec-
tor ActivityName is a bit array where each bit encodes a
different state that an activity can reach. A bit array is
encoded as a 256-bits unsigned integer, which is the default
word size in the Ethereum Virtual Machine.

(ii) We generate functions corresponding to the four trans-
actional termination states. For instance, a function called
ActivityName fail() is generated. This function handles

the activity’s subsequent behavior in case it fails. Similar
functions are defined in the case of an activity’s abortion,
cancellation and compensation.

(iii) We implement the transitions (abort(), cancel(), com-
plete(), fail() and retry()) which allow the activity to move
from one state to another as functions in the “Process S.C”.
These functions update the value of activities state vectors.

(iv) We add also endorsement for events in the “Oracle
SC” to abort, compensate or cancel an activity.

Due to lack of space, we do not provide a de-
scription of the implementation of the approach. We
host the source code at https://github.com/TBP-BE/
TransactionalBP-BlockchainExecution. The source code
repository contains as well the code generated for the
motivating scenario in Section II of ordering a personalized
package.

V. RELATED WORK

Recent works use the blockchain as a coordination mech-
anism to implement the control flow of collaborative pro-
cesses. The current process state is stored on the chain and
the execution of the next process task depends on the process
data shared among the network peers.

In [13], a runtime verification mechanism is developed
to verify running choreographies of process instances on
top of Bitcoin blockchain. The approach is applicable only
to standard Bitcoin network transactions like Pay-to-Script-
Hash, over and above, it does not address fault management
and recovery. Authors make some propositions like the
participant that starts the process execution can intercept the
process token and collect it if something goes wrong with
the process execution.

In [1], authors present an approach to enable the mon-
itoring and execution of collaborative processes using
blockchain’s SC. The approach is based on a translator
taking as input the business process model in Business
Process Model Notation (BPMN) and generates the corre-
sponding contract according to specific BPMN-to-Solidity
code transformation rules. A tool named Caterpillar [9]
is derived from the approach in [1]. It is an open-source
Blockchain-based business process execution engine that
translates the business processes modeled in BPMN into
SC written in Solidity programming language. Caterpillar
supports also the execution of collaborative processes.

In a more recent work [14], authors start from a declara-
tive input (XML) and propose a set of transformation rules
to convert touristic itineraries presented in XML to SC.

However, the proposed approaches [1], [14] as well as the
existing tools like Caterpillar [9] handle only the workflow
execution of business processes without taking into consider-
ation the case of task failures and the subsequent behaviour
of the business process in such cases.

https://github.com/TBP-BE/TransactionalBP-BlockchainExecution
https://github.com/TBP-BE/TransactionalBP-BlockchainExecution


(a) Pivot activity life cycle (b) Compensatable activity life cycle

(c) Retriable activity life cycle (d) Compensatable and retriable activity life cycle

Figure 2. Activity life cycle according to the different transactional properties. [6]

VI. CONCLUSION

Motivated by the opportunities offered by the technology
of SC to enable the trusted and decentralized execution of
BP in open environments and the TBP to handle failures
and ensure the transactional correctness of BP executions,
we propose an approach that builds on SC and extends them
to implement TBP. Our approach implements a TBP where
its control flow is given as input and its transactional flow
follows the FTM principles. The transactional flow englobes
the transactional properties assigned to process activities as
well as a set of transactional mechanisms (compensation and
enabling alternatives).

In order to implement our approach, we extend an existing
blockchain-based BPM system named Caterpillar in order to
support the execution of TBP. Caterpillar generates only the
control flow of input BPMN models. We mainly modified
the Solidity code generation “templates” of the tool in order
to implement in addition the transactional flow.

We consider the present work as a first step to providing
a blockchain-based execution environment for TBP. An
avenue for future work is to examine the cost of execution
of our approach especially in case of large BPs. Finally,
we intend to consider permissioned blockchains since they
ensure better performance and privacy and (arguably) lower
operational costs.

REFERENCES

[1] I. Weber, X. Xu, R. Riveret, G. Governatori, A. Ponomarev,
and J. Mendling, “Untrusted business process monitoring and
execution using blockchain,” in International Conference on
Business Process Management. Springer, 2016, pp. 329–347.

[2] J. Mendling, I. Weber, W. V. D. Aalst, J. V. Brocke, C. Caban-
illas, F. Daniel, S. Debois, C. D. Ciccio, M. Dumas, S. Dust-
dar et al., “Blockchains for business process management-
challenges and opportunities,” ACM Transactions on Manage-
ment Information Systems (TMIS), vol. 9, no. 1, p. 4, 2018.

[3] R. Hull, V. S. Batra, Y.-M. Chen, A. Deutsch, F. F. T.
Heath III, and V. Vianu, “Towards a shared ledger business
collaboration language based on data-aware processes,” in

International Conference on Service-Oriented Computing.
Springer, 2016, pp. 18–36.

[4] T. T. A. Dinh, R. Liu, M. Zhang, G. Chen, B. C. Ooi, and
J. Wang, “Untangling blockchain: A data processing view of
blockchain systems,” IEEE Transactions on Knowledge and
Data Engineering, vol. 30, no. 7, pp. 1366–1385, 2018.

[5] H. Schuldt, G. Alonso, C. Beeri, and H.-J. Schek, “Atomicity
and isolation for transactional processes,” ACM Transactions
on Database Systems (TODS), vol. 27, no. 1, pp. 63–116,
2002.

[6] S. Bhiri, W. Gaaloul, C. Godart, O. Perrin, M. Zaremba, and
W. Derguech, “Ensuring customised transactional reliability
of composite services,” Journal of Database Management
(JDM), vol. 22, no. 2, pp. 64–92, 2011.

[7] J. El Hadad, M. Manouvrier, and M. Rukoz, “Tqos: Trans-
actional and qos-aware selection algorithm for automatic
web service composition,” IEEE Transactions on Services
Computing, vol. 3, no. 1, pp. 73–85, 2010.

[8] M. Rusinkiewicz and A. Sheth, “Specification and execution
of transactional workflows,” in IN MODERN DATABASE
SYSTEMS: THE OBJECT MODEL, INTEROPERABILITY,
AND. Citeseer, 1994.

[9] O. López-Pintado, L. GarcĹ́a-Bañuelos, M. Dumas, I. Weber,
and A. Ponomarev, “Caterpillar: A business process execution
engine on the ethereum blockchain,” Software: Practice and
Experience, vol. 49, no. 7, pp. 1162–1193, 2019.

[10] M. Boulakbech, N. Messai, Y. Sam, and T. Devogele, “Visual
configuration for restful mobile web mashups,” in 2017 IEEE
International Conference on Web Services (ICWS). IEEE,
2017, pp. 870–873.

[11] S. Underwood, “Blockchain beyond bitcoin,” Communica-
tions of the ACM, vol. 59, no. 11, pp. 15–17, 2016.

[12] C. Dannen, Introducing Ethereum and Solidity. Springer,
2017.

[13] C. Prybila, S. Schulte, C. Hochreiner, and I. Weber, “Run-
time verification for business processes utilizing the bitcoin
blockchain,” Future Generation Computer Systems, 2017.

[14] A. Brahem, N. Messai, Y. Sam, S. Bhiri, T. Devogele, and
W. Gaaloul, “Blockchain’s fame reaches the execution of
personalized touristic itineraries,” in 2019 IEEE 28th Inter-
national Conference on Enabling Technologies: Infrastructure
for Collaborative Enterprises (WETICE). IEEE, 2019, pp.
186–191.


";"""date"",""2020-08-05T05:50:50Z""
""pdf:PDFVersion"",""1.4""
""pdf:docinfo:title"",""Running transactional business processes with blockchain's smart contracts""
""xmp:CreatorTool"",""HAL""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""Computer Science [cs]/Other [cs.OH]""
""language"",""en""
""dc:format"",""application/pdf; version=1.4""
""pdf:docinfo:creator_tool"",""HAL""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""Running transactional business processes with blockchain's smart contracts""
""modified"",""2020-08-05T05:50:50Z""
""cp:subject"",""Computer Science [cs]/Other [cs.OH]""
""pdf:docinfo:subject"",""Computer Science [cs]/Other [cs.OH]""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""Amina Brahem, Nizar Messai, Yacine Sam, Sami Bhiri, Thomas Devogele, Walid Gaaloul""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.20 (TeX Live 2019) kpathsea version 6.3.1""
""meta:author"",""Amina Brahem, Nizar Messai, Yacine Sam, Sami Bhiri, Thomas Devogele, Walid Gaaloul""
""trapped"",""False""
""meta:creation-date"",""2021-03-31T12:20:02Z""
""created"",""2021-03-31T12:20:02Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2021-03-31T12:20:02Z""
""resourceName"",""document""
""Author"",""Amina Brahem, Nizar Messai, Yacine Sam, Sami Bhiri, Thomas Devogele, Walid Gaaloul""
""producer"",""PDFLaTeX""
""pdf:docinfo:producer"",""PDFLaTeX""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""2"",""0"",""0"",""0"",""0""
""Keywords"",""Blockchain, Open and untrusted environment, Transactional business processes, Business processes, Smart contracts""
""access_permission:modify_annotations"",""true""
""dc:creator"",""Amina Brahem, Nizar Messai, Yacine Sam, Sami Bhiri, Thomas Devogele, Walid Gaaloul""
""dcterms:created"",""2021-03-31T12:20:02Z""
""Last-Modified"",""2020-08-05T05:50:50Z""
""dcterms:modified"",""2020-08-05T05:50:50Z""
""title"",""Running transactional business processes with blockchain's smart contracts""
""Last-Save-Date"",""2020-08-05T05:50:50Z""
""pdf:docinfo:keywords"",""Blockchain, Open and untrusted environment, Transactional business processes, Business processes, Smart contracts""
""pdf:docinfo:modified"",""2020-08-05T05:50:50Z""
""meta:save-date"",""2020-08-05T05:50:50Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.20 (TeX Live 2019) kpathsea version 6.3.1""
""Content-Length"",""426970""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Amina Brahem, Nizar Messai, Yacine Sam, Sami Bhiri, Thomas Devogele, Walid Gaaloul""
""dc:subject"",""Blockchain, Open and untrusted environment, Transactional business processes, Business processes, Smart contracts""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""6""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""970"",""4255"",""3532"",""4541"",""4831"",""3830""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""Blockchain, Open and untrusted environment, Transactional business processes, Business processes, Smart contracts""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2021-03-31T12:20:02Z""
";https://scholar.google.ch/scholar?start=720&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098831-255;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;[HTML][HTML] Cryptographic Primitives that Resist Backdooring and Subversion;S Mazaheri ;2020 tuprints.ulb.tudarmstadt.de;;"… practically allows a hash function construction to replace a random oracle is referred … as the number

of the adversary's query switches between the backdoor oracles remains logarithmic … These attacks

are formalized by Bellare, Paterson, and Rogaway (CRYPTO 2014) as attacks …";Autres articles;;[HTML] tu-darmstadt.de;https://tuprints.ulb.tu-darmstadt.de/id/eprint/14550;;;https://scholar.google.ch/scholar?start=800&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098765-104;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Bot Contracts;DR Gerhardt, D Thaw ; Ariz. L. Rev., 2020  HeinOnline;;"… the future-ie, the de- identification-re-identification arms race.""). 43. See, eg, Doug

Fredrick, Down the Rabbit Hole: Cryptocurrency & Blockchain, Wis. LAw., Mar. 2019,

at 22, 28-29 (""The sequential nature of blockchain networks …";Autres articles;;[PDF] arizonalawreview.org;https://arizonalawreview.org/pdf/62-4/62arizlrev877.pdf;"
BOT CONTRACTS 

Deborah R. Gerhardt & David Thaw* 

In this Article, we explain why the transactions commonly known as “smart 

contracts” are better understood as “bot contracts.” Taking an interdisciplinary 

approach, we show why the “smart contracts” moniker is misdescriptive in two 

important ways. First, these transactions are automated, not smart. Second, they do 

not afford parties many enforcement rights and defenses that one expects from 

common law contractual relationships. To fully understand these transactions, it is 

important to appreciate how the term “smart contracts” differs from what the 

technology delivers.  

 

Our review of the technology explains that these transactions have tremendous 

practical utility in reducing risk and avoiding the uncertainty and expense of seeking 

judicial enforcement. However, the electronic processes that occur in this category 

are not smart in the sense of being thoughtful, creative, or even amenable to change. 

They are programmed to follow preset instructions and execute automatically. Once 

the conditions for performance under a smart contract occur, performance cannot 

be stopped. Because these transactions are automated, they lack features and 

defenses available to those who enter into typical contractual relationships. 

Common law contracts are sets of promises or obligations that may be enforced by 

a court. However, once a smart contract is set in motion, no person or court can 

reverse the transaction. In this way, smart contracts differ fundamentally from 

traditional contracts because they leave no room for judicial intervention. By 

design, they evade the risk of what a court may do in fashioning a remedy. Courts 

have no power to set the transaction aside if it was induced by fraud or if another 

 
 *  Deborah R. Gerhardt is the Reef C. Ivey II Excellence Fund Term Professor 

of Law at the University of North Carolina, Chapel Hill. David Thaw is an Associate Research 

Professor of Law, an Assistant Research Professor of Computing & Information at the 

University of Pittsburgh, an Affiliated Fellow of the Information Society Project at Yale Law 

School, and Faculty Director and Founder of the CyREN Laboratory. Beginning in 2019, 

Professor Thaw has been on research leave leading the Obnostic Project, a distributed 

computational platform based on the fundamental science underlying blockchain technology. 

Professor Thaw receives no compensation, other than his faculty salary, for his work on this 

paper, and the paper neither is funded nor influenced by Obnostic LLC or any of its affiliates. 

The Authors are grateful to Douglas Baird, Michael Malloy, and the participants at KCON 

2020 for helpful feedback. We are also grateful to Taylor Townes and Chandler Martin for 

excellent research assistance. 



878 ARIZONA LAW REVIEW [VOL. 62:877 

common law defense would, under other circumstances, render the transaction void 

or voidable. Although the term “smart contract” appears to have taken hold, we 

propose that these transactions are better thought of as “bot” or “automated” 

agreements. Reframing these transactions in this way would reset expectations in 

line with what the technology can deliver. Adopting this more encompassing 

terminology will send a strong informational signal that avoids misrepresenting the 

abilities of these agreements by more accurately communicating that they execute 

automatically and eliminate both the risks and benefits that accompany traditional 

common law contracts. 

INTRODUCTION ..................................................................................................... 878 

I. DEFINING FEATURES OF COMMON LAW CONTRACTS ........................................ 879 

II. HOW SMART CONTRACTS WORK ..................................................................... 881 
A. Blockchain Basics ...................................................................................... 881 
B. Brief History of Blockchain Technology ................................................... 883 

1. The DVT Concept and the Development of Blockchain ........................ 884 
a. “Blockchain 1.0”: Static Digital Tokens ............................................ 885 
b. “Blockchain 2.0”: Executable Agreements (“Smart Contracts”) ....... 888 

C. Present Smart Contract Limitations............................................................ 891 

III. CONSEQUENCES OF “SMART” CONTRACTING ARE BETTER UNDERSTOOD AS 

“BOT” CONTRACTING .................................................................................. 892 
A. The Elimination of an Enforcement Authority ........................................... 892 
B. Smart Contracts Neutralize Contract Legal Defenses ................................ 895 
C. The Benefits of Bot Contracts .................................................................... 898 
D. Future Developments ................................................................................. 899 

CONCLUSION ........................................................................................................ 902 

INTRODUCTION 

The term “smart contracts” seems to have taken on a life of its own. The 

moniker was coined by a computer scientist to describe software that worked like a 

vending machine.1 In the following decades, its meaning has snowballed to the point 

where the term has picked up power and meaning that extends beyond what the 

technology offers. To understand these transactions, one must consider how smart 

contracts differ from common law contracts. 

Smart contracts occur when two people tell software to conduct an activity. 

Unlike a traditional common law contract, in which offer and acceptance of mutual 

promises occur, entering into a smart contract is like standing with a friend and 

agreeing to press the button that unlocks your car doors. Once you both press the 

button, there is no turning back. The software sends a signal. The car will unlock. 

Pressing the button again can cause the car to lock, but it will not change the first 

unlocking. Smart contracts work in the same way. Two people may decide to 

complete a sale if a certain condition (analogous to pressing the lock button) occurs, 

 
 1. Roberto Pardolesi & Antonio Davola, What Is Wrong in the Debate About 

Smart Contracts 1 (Feb. 21, 2019) (unpublished manuscript), 

https://ssrn.com/abstract=3339421 or http://dx.doi.org/10.2139/ssrn.3339421. 



2020] BOT CONTRACTS 879 

the instructions are sent, and the transaction will perform. Once the triggering 

conduction happens, formation of the contract cannot be stopped or undone. For this 

reason, the term “smart contracts” is technically misdescriptive in two ways. The 

electronic processes that fit in this category are not smart. They do not think, create, 

or choose. Rather, they are programmed, not to think, but to follow preset 

instructions. And strictly speaking, they are not contracts. Common law contracts 

are sets of promises or obligations that may be enforced at law. Once a smart contract 

is set in motion, no person or court can reverse the transaction. Like electronic door 

locks, smart contracts can add tremendous value and efficiency by minimizing 

effort, error, and risk.2 

In this Article, we illustrate how these automated transactions challenge the 

foundational notions of contract law and have important implications for parties 

considering what type of platform to select for their transactions. Part I identifies 

basic features that separate enforceable contracts from other promises. Part II 

summarizes the technology that enables private actors to enter smart contracts. Once 

that foundation is set, it becomes clear that smart contracts lack several features of 

common law contracts. These features are identified in Part III. Most notably, smart 

contracts leave no room for judicial intervention. By design, they eliminate the 

uncertainty of what a court may do in fashioning a remedy. They are, therefore, not 

the kinds of transactions for which a court can provide a remedy or order the parties 

to do anything. Courts have no power to set the transaction aside if it is based on 

fraud or if a common law defense would, under other circumstances, provide a 

reason to void the transaction. For all of these reasons, the agreements known as 

“smart contracts” offer a mix of benefits and challenges which are obscured by their 

common name. Although the term “smart contract” appears to have taken hold, we 

suggest that these transactions are better thought of as “bot” or “automated” 

contracts because of the many ways they differ from traditional contracts that come 

with a host of common law remedies and a set of expectations that automated 

transactions are designed not to provide. 

I. DEFINING FEATURES OF COMMON LAW CONTRACTS 

A basic tenet of contract law is that only a subset of mutual decisions and 

exchanged promises amount to enforceable contracts.3 The law of contracts defines 

these boundaries.4 Contracts that are bargained exchanges between adult actors with 

the capacity to enter into agreements are protected by contract law.5 Although they 

are private agreements, they emanate an aura of authority arising out of the accepted 

notion that courts will enforce them. Not all promises fall within this boundary. The 

 
 2. Smart contracts purport to bring together the advantages of a self-executing 

contract with the customization options of traditional common law contractual drafting. 

Furthermore, they reduce resolution costs by largely removing enforcement from the 

equation. However, as this Article addresses, these advantages are not always present and not 

all smart contracts deliver on the full promises of traditional common law contracts. 

 3. See RESTATEMENT (SECOND) OF CONTRACTS § 1 (AM. L. INST. 1981) (“A 

contract is a promise or a set of promises for the breach of which the law gives a remedy, or 

the performance of which the law in some way recognizes as a duty.”). 

 4. See generally id. 

 5. See id. § 12. 



880 ARIZONA LAW REVIEW [VOL. 62:877 

possibility of court intervention to identify and enforce an agreement is an important 

element in defining this boundary between enforceable contracts and unenforceable 

promises or agreements. Professor Joseph Perillo begins his contracts treatise with 

a discussion on the difficulty of defining a contract.6 But all the competing 

definitions share a common theme. They embrace the understanding that “[e]very 

contract involves at least one commitment that has legal consequences.”7 In its very 

first section, the Restatement (Second) of Contracts uses this notion in defining a 

contract. The Restatement provides that “[a] contract is a promise or a set of 

promises for the breach of which the law gives a remedy, or the performance of 

which the law in some way recognizes as a duty.”8 The Uniform Commercial Code 

confirms this basic foundation, noting that even if an agreement is missing a key 

term, it still may be considered a contract if “there is a reasonably certain basis for 

giving an appropriate remedy.”9 In other words, an agreement will be deemed a 

contract only if, by its terms, a neutral arbiter can identify and award a remedy. 

The common law tradition developed the requirement that a set of promises 

rises to the level of a contract only if a court can enforce it. For example, if a set of 

promises is not sufficiently definite for a court to intervene and provide a remedy, it 

will not be deemed an enforceable contract. Professor Samuel Williston explains 

that “[i]t is a necessary requirement that an agreement, in order to be binding, must 

be sufficiently definite to enable the courts to give it an exact meaning.”10 State 

courts similarly rely on the possibility of judicial enforcement as a metric for 

determining whether a contract exists. For example, the Alabama Supreme Court 

opined that “any contract must express all terms essential to the transaction with 

definiteness sufficient to enable a court to enforce the parties’ agreement.”11 A 

court’s ability to identify contractual obligations and fashion a remedy is essential 

to determining whether expressions and conduct fit within the sets of promises the 

law recognizes as contracts. 

This basic existential notion is not unique to the United States. The United 

Nations Convention on Contracts for the Sale of Goods indicates that it is not 

intended to address whether an agreement constitutes a valid contract.12 

 
 6. JOSEPH M. PERILLO, CALAMARI AND PERILLO ON CONTRACTS § 1.1, at 1 (7th 

ed. 2014) (“No entirely satisfactory definition of the term ‘contract’ has ever been devised. 

The difficulty of definition arises from the diversity of the expressions of assent which may 

properly be denominated ‘contracts’ and from the various perspectives from which their 

formation and consequences may be viewed.”). 

 7. Id. 

 8. RESTATEMENT (SECOND) OF CONTRACTS § 1 (AM. L. INST. 1981). 

 9. U.C.C. § 2-204(3) (AM. L. INST. & UNIF. L. COMM’N 1977) (“Even though 

one or more terms are left open a contract for sale does not fail for indefiniteness if the parties 

have intended to make a contract and there is a reasonably certain basis for giving an 

appropriate remedy.”). 

 10. 1 SAMUEL WILLISTON, A TREATISE ON THE LAW OF CONTRACTS § 4:21, at 634 

(Richard A. Lord ed., 4th ed. 2007). 

 11. Capmark Bank v. RGR, LLC, 81 So. 3d 1258, 1268 (Ala. 2011) (emphasis 

added) (quoting Macon Cty. Greyhound Park v. Knowles, 39 So. 3d 100, 108 (Ala. 2009)). 

 12. United Nations Convention on Contracts for the International Sale of Goods 

art. 4(a), Apr. 11, 1980, 1489 U.N.T.S. 3 (“This Convention governs only the formation of 

 



2020] BOT CONTRACTS 881 

Accordingly, the entire convention is premised on the notion that one or more 

tribunals may enforce agreements within its scope.13 

II. HOW SMART CONTRACTS WORK 

Evaluating the ability of smart contracts to implement the requirements of 

common law contract doctrine first requires some basic understanding of blockchain 

technologies, their history, and the development of the technologies currently 

referred to as “smart contracts.” This is particularly important because we are 

considering an emerging technology, the limitations (and abilities) of which 

continue to evolve over time. This Part begins with some “Blockchain Basics,” 

followed by a contextual overview of the history of blockchain technologies and the 

rise of smart contracts. It concludes by contextualizing the current abilities of smart 

contracts to fulfill contract doctrinal requirements. In particular, we focus on two 

apparent deficiencies: the implied right of parties to breach and the legal requirement 

of capacity. 

A. Blockchain Basics 

The technologies we collectively refer to as “blockchain” are a system for: 

(1) distributing work; and (2) coordinating that work across many computers 

connected by a network (usually the public Internet). This structure enables the 

coordination of distributed work without the need for a single centralized authority. 

Since this process heavily involves “verifying work” and need not necessarily use a 

“chain” style data structure,14 we refer to these technologies collectively as 

“Distributed Verification Technologies” (“DVTs”).15 This Section gives a brief 

 
the contract of sale and the rights and obligations of the seller and the buyer arising from such 

a contract. In particular, except as otherwise expressly provided in this Convention, it is not 

concerned with: (a) the validity of the contract or of any of its provisions or of any usage.”). 

 13. See Jarno Vanto, Attorneys’ Fees As Damages in International Commercial 

Litigation, 15 PACE INT’L L. REV. 203, 218 (2003) (“[T]he preamble to the Convention 

provides: ‘Being of the opinion that the adoption of uniform rules which govern contracts for 

the international sale of goods and taking into account the different social, economic and legal 

systems . . . .’ This means that, at least on a symbolic level, the Convention takes into account 

different legal systems and consequently also the different outcomes they may produce.” 

(citation omitted)). 

 14. The data stored in a “blockchain” is an ordinal list of data points. See SATOSHI 

NAKAMOTO, BITCOIN: A PEER-TO-PEER ELECTRONIC CASH SYSTEM 2 (2008), 

https://bitcoin.org/bitcoin.pdf. More advanced data structures, such as variations on binary 

tree structures, can be expressed mathematically as combinations of linked lists. Accordingly, 

any data that can be expressed in a data structure of an abstract “list” type can therefore be 

expressed in a data structure of an abstract “tree” type. Similar analysis can be applied to 

other structures, such as matrices. See generally THOMAS H. CORMEN ET AL., INTRODUCTION 

TO ALGORITHMS, chs. 3, 5–6, 10 (3d ed. 2009). 

 15. “Distributed Verification Technologies” is both more accurate and more 

usefully descriptive than the common business term “Distributed Ledger Technologies” for 

two reasons. First, the concept of a “ledger” implies a linked-list style data structure, which 

in addition to being only the prototype version of blockchain implementations, is also a 

comparatively highly inefficient data structure and thus is unlikely to be dominant (if even 

used) in the long-term. Second, the term “ledger” fails to capture the key element that 

 



882 ARIZONA LAW REVIEW [VOL. 62:877 

overview of “Blockchain Basics,” and the following Section provides greater detail 

on the history and implementation of blockchain-based technology known as “smart 

contracts.” 

Such “peer-to-peer”16 coordination is what enables the concept of 

“electronic cash” as bearer instruments—by arbitrarily distributing the verification 

of whether or not a particular cryptographic “token” properly belongs in a given 

“wallet.” These “consensus” mechanism, blockchain-based cryptocurrencies allow 

those cryptographic tokens to become effective bearer instruments because no 

“owner” or “recipient” of a given token must depend on any specific or centralized 

party to confirm the validity of their “instrument” (token), but rather can look to the 

net product of the peer-to-peer system for such confirmation. 

The peer-to-peer system, or consensus mechanism, can be implemented in 

a variety of different ways. Generally speaking, it comprises a data structure and an 

algorithm for community verification of modifications to the information stored in 

that data structure. In the context of most commonly used cryptocurrencies in 2020, 

the data structure usually comprises a singly linked list or public “ledger” of 

transaction history. Likewise, current blockchain implementations generally use a 

consensus algorithm that ensures a certain percentage of total “nodes” 

(computational participants17) in the network “agree” that a change should take place 

and ensures the accuracy of the ledger.18 The threshold required for verification of 

an ownership transfer generally is sufficiently high that the cost of a “takeover” 

 
facilitates distributed work—the verification process—and thus, we recommend that DVT is 

a superior term to describe this class of emerging technologies. See generally Usha R. 

Rodrigues, Law and the Blockchain, 104 IOWA L. REV. 679, 697 (2019) (“Blockchain 

technology, also called distributed ledger technology (‘DLT’), offers four primary and related 

benefits: it is decentralized, it is transparent, it is (or at least can be) anonymous, and it is 

nearly impossible to manipulate.”); GARRICK HILEMAN & MICHEL RAUCHS, CAMBRIDGE CTR. 

FOR ALT. FIN., GLOBAL BLOCKCHAIN BENCHMARKING STUDY 24 (2017), 

https://www.jbs.cam.ac.uk/faculty-research/centres/alternative-finance/publications/global-

blockchain/#.X0f4EdNKhQI (“In general, the term ‘distributed ledger technology’ refers to 

all initiatives and projects that are building systems to enable the shared control over the 

evolution of data without a central party, with individual systems referred to as ‘distributed 

ledgers.’ If one wants to describe a system that has global data diffusion and/or uses a data 

structure of chained blocks, one should call it a ‘blockchain.’ However, ‘blockchain 

technology’ and ‘distributed ledger technology’ are still commonly used interchangeably 

despite attempts to semantically separate them by their different underlying architectures.”). 

 16. The term “peer-to-peer” is a slight misnomer in this context in the sense that 

most current implementations of blockchain technologies implement tiered peering systems, 

rather than true fully peer-to-peer systems. However, for the purposes of this Article’s 

audience, the term is usefully descriptive. 

 17. Often (but not always) individual “general purpose computers” or PCs, depend 

on the particular blockchain implementation. In certain blockchains, such as the well-known 

Bitcoin blockchain, the nature of the computations involved lend themselves to Application 

Specific Integrated Circuits (“ASICs”), and thus, the “nodes” in that regard may comprise 

highly specialized hardware instead of desktop or laptop PCs or servers running software as 

a background process. 

 18. See generally Sarwar Sayeed & Hector Marco-Gisbert, Assessing Blockchain 

Consensus and Security Mechanisms Against the 51% Attack, APPLIED SCIS., Apr. 2019. 



2020] BOT CONTRACTS 883 

attack,19 or inserting enough nodes to force an unauthorized transfer, will exceed the 

benefit of the value that can be obtained from the unauthorized transactions executed 

as a function of the “takeover.” 20 

Thus, the key basic concept of blockchain technology is not necessarily so 

much about currency as it is about verification. This concept of distributed 

verification, of course, is a natural model for financial transactions like payments. 

This model has extensions far beyond mere currency exchanges21 and, as this Article 

explores, may be a substitute for traditional common law contract dispute resolution. 

B. Brief History of Blockchain Technology 

The concept of blockchain was first proposed in a 2008 paper titled Bitcoin: 

A Peer-to-Peer Electronic Cash System and published under the pseudonym Satoshi 

Nakamoto.22 The paper proposed a solution for authenticating digital transactions 

without the need for a centralized authority. It articulated a series of proofs for a 

cash-like electronic commerce system that could be maintained by an arbitrarily 

distributed network with no centralized verification.23 These proofs showed that a 

distributed verification algorithm, or “consensus” mechanism, could prevent the 

double spending of digital assets. The “double spend problem” occurs when digital 

tokens—which can be copied flawlessly—are used to represent value. Because such 

tokens can be copied flawlessly, any given token, i.e., any digital monetary 

instrument, could be used twice or more, and the payee would have no mechanism 

of determining which was the original. The consensus mechanism distributes the 

verification of payments across many different computers, forming a so-called 

“digital ledger” that verifies the authenticity and provenance of payments before 

 
 19. This bears some conceptual similarity to a hostile takeover in the sense that at 

least some majority control will usually be required to execute the attack. However, given the 

fact that only a currency acquisition (as opposed to productive assets of a company) can be 

acquired, such an attack would at best only be a speculative investment in the cryptocurrency 

context and one that is extremely unlikely to be profitable since the market almost certainly 

would rapidly devalue a cryptocurrency compromised in that fashion. 

 20. See JOSHUA A. KROLL ET AL., THE ECONOMICS OF BITCOIN MINING, OR BITCOIN 

IN THE PRESENCE OF ADVERSARIES 12 (2013), 

https://www.econinfosec.org/archive/weis2013/papers/KrollDaveyFeltenWEIS2013.pdf 

(“As a cartel must outmine the entire Bitcoin network and thus outspend the entire Bitcoin 

network for as long as it would remain a cartel, we believe it is very unlikely that a cartel 

could double-spend enough to recover the cost of the attack.”). But cf. Sayeed & Marco-

Gisbert, supra note 18, at 9 (assessing this probability differently and stating that “majority 

hash attacks have been a serious problem in recent times”). The Authors disagree with that 

assessment in that Sayeed and Marco-Gisbert’s analysis is context-dependent on specific 

market conditions, rather than inherent to the scientific design, and thus seems unlikely to 

apply to the general case. Kroll et al.’s analysis is more consistent with the Authors’ analysis. 

See KROLL ET AL., supra. 

 21. See generally DAVID THAW & WILL KANG, OBNOSTIC: AN OBJECT-AGNOSTIC 

“GENERAL PURPOSE BLOCKCHAIN” (2019), https://47b16f07-4bfb-43f2-9be9-

5c47db516f53.filesusr.com/ugd/b86d62_2da0ae7bb43d40a08ca0e7b2926a1647.pdf; U.S. 

Provisional Utility Patent Application No. 62/792,381 (filed Jan. 15, 2019). 

 22. NAKAMOTO, supra note 14. 

 23. Id. 



884 ARIZONA LAW REVIEW [VOL. 62:877 

settlement, and thereby prevents “double spending.”24 Nakamoto’s paper called the 

hypothetical system Bitcoin. The Bitcoin system prototype was deployed worldwide 

soon after the paper’s publication25 and gave rise to the name of the asset currently 

traded worldwide under the symbol “BTC.”26 The Bitcoin system prototype was 

deployed worldwide soon thereafter.  

Nakamoto’s paper and subsequent implementation of the first Bitcoin 

prototype in 2009 became the foundation of the blockchain concept. Together the 

paper and implementation proved the viability of DVTs (more commonly referred 

to as “Distributed Ledger Technologies”).27 More concisely, DVTs are distributed 

networks for maintaining consensus about data and making decisions regarding 

operations. They distribute computational work to maintain agreement about the 

answers to a set of questions without the need for intervention or verification by a 

centralized authority. 

Some background and history on the concept of blockchain (or DVTs) will 

be instructive to help contextualize the examples in which we apply common law 

contract doctrine to current implementations of smart contracts. 

1. The DVT Concept and the Development of Blockchain 

Much of blockchain’s success is attributed to its distributed nature, 

specifically the ability to maintain “trust” in the origin and ownership of digital 

objects without the need to rely on a centralized authority.28 This concept of 

distributed verification, or “consensus,” is the core of the blockchain concept. It 

comprises two essential elements: (1) a distributed data structure to maintain 

information;29 and (2) a consensus mechanism (algorithm) to govern and prove the 

authenticity of work performed by nodes participating in the distributed network.30 

The distributed data structure allows the DVT to work across many computers 

around the world without needing any one single computer or “central authority” to 

 
 24. Id. 

 25. Eric D. Chason, How Bitcoin Functions as Property Law, 49 SETON HALL L. 

REV. 129, 131 (2018) (“Barely two months [after Nakamoto’s paper was published], in early 

January 2009, Bitcoin ‘went live’ with the creation of the first units of Bitcoin.”). 

 26. Id. at 132–33. 

 27. “Distributed Ledger Technologies” (“DLTs”) is, by far, a more commonly 

accepted term for the group of technologies used in cryptocurrencies and smart contract 

platforms. Although not the primary subject of this Article, we note that this term is 

technologically limiting in that it only contemplates globally maintained ledgers, as opposed 

to the larger category of efforts enabled by this technology—the ability to make coordinated 

decisions without the need for a firm or other centralized authority. In this context, 

“Distributed Verification Technologies” is a much more usefully descriptive term, and also 

better identifies why future technologies may have more ability to implement the guarantees 

of common law contracts. See infra Sections II.A–B. 

 28. See generally SHAWN S. AMUIAL ET AL., THE BLOCKCHAIN: A GUIDE FOR 

LEGAL AND BUSINESS PROFESSIONALS § 1:2 (2016). 

 29. See NAKAMOTO, supra note 14, at 3. 

 30. See id. at 4, 8. 



2020] BOT CONTRACTS 885 

coordinate the participants.31 The system enables the participants to maintain 

“consensus,” a term which represents the algorithmic process by which the 

computers participating in a given blockchain reach “agreement” regarding a 

specific data point, e.g., whether or not a transaction occurred or who owns a 

particular portion of a given Bitcoin.32 

A DVT is capable of maintaining consensus regarding data without an 

agreed upon common authority. DVTs thus can enable collective “answering of 

questions” and maintenance of data records. DVTs also provide the data structure 

which stores (or links to) the data they authenticate.33 The combination of these two 

items together—a distributed verification network and a distributed data structure—

forms the DVT itself. 

a. “Blockchain 1.0”: Static Digital Tokens 

The Bitcoin blockchain was the first example of a DVT. It encapsulates the 

idea of the “Blockchain 1.0” concept—a distributed verification of static tokens. The 

Bitcoin tokens (“BTCs”) are, quite literally, static cryptographic tokens which can 

be exchanged among “owners” via a provably hard34 public key cryptographic 

system. The public–private keypair cryptographic system prevents unauthorized 

transfers, and the Bitcoin network (the DVT) maintains a “ledger” of all Bitcoin 

transactions since the network’s inception, preventing duplication of the tokens.35 

 
 31. The coordination function, rather, is distributed across the entire network. 

Interestingly, this structure parallels work on the Theory of the Firm in economics, and some 

scholars have suggested that a similar concept can be used to create decentralized 

organizations, sometimes referred to as Distributed Autonomous Organizations (“DAOs”). 

Kevin Werbach & Nicolas Cornell, Contracts Ex Machina, 67 DUKE L.J. 313, 337 (2017) (“If 

a corporation is simply a nexus of contracts, why not encode those agreements into digital 

self-enforcing agreements? A DAO could have stock ownership, corporate governance rules, 

payroll arrangements, and virtually all of the economic trappings of a modern corporation, all 

running automatically in a completely distributed manner.”). 

 32. See NAKAMOTO, supra note 14, at 8. 

 33. See id. at 5. 

 34. “Provably hard” is a term of art in computer science and related fields which 

refers to the computational complexity, or “difficulty,” of solving a certain type of problem. 

It generally refers to the time it takes to solve such a problem through “brute force” guessing, 

expressed as a function of the number of guesses required to find a working solution. Since, 

technically speaking, a brute force mechanism has equal probability of being successful on 

the first try (a trivially short period of time) or on the last possible try (an extremely unlikely 

result), mathematical equations are instead used to express the “average case.” This concept 

of an “average case,” i.e., average time to guess, focuses not on a specific amount, but rather 

the degree of difficulty of the equation which models the “average” number of guesses. The 

result divides difficulty into categories, such as “constant time,” “linear time,” “polynomial 

time,” “exponential time,” “factorial time,” and so on. With classical (non-quantum) 

computers, problems that require more than polynomial time to brute force generally are 

considered to be “hard” because the combined computational power of all computers on earth 

is insufficient to solve such problems in reasonable time (less than mill";"""date"",""2020-11-10T17:41:20Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.7""
""xmp:CreatorTool"",""MicrosoftÂŽ Word for Office 365""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dc:creator"",""Pryor, Carissa - (carissapryor)""
""language"",""en""
""dcterms:created"",""2020-11-10T17:41:20Z""
""Last-Modified"",""2020-11-10T17:41:20Z""
""dcterms:modified"",""2020-11-10T17:41:20Z""
""dc:format"",""application/pdf; version=1.7""
""xmpMM:DocumentID"",""uuid:BB666D13-0DB2-4773-8924-C4955A979ECC""
""Last-Save-Date"",""2020-11-10T17:41:20Z""
""pdf:docinfo:creator_tool"",""MicrosoftÂŽ Word for Office 365""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2020-11-10T17:41:20Z""
""meta:save-date"",""2020-11-10T17:41:20Z""
""pdf:encrypted"",""false""
""xmp:CreateDate"",""2020-11-10T10:41:20Z""
""modified"",""2020-11-10T17:41:20Z""
""Content-Length"",""397186""
""pdf:hasMarkedContent"",""true""
""Content-Type"",""application/pdf""
""xmp:ModifyDate"",""2020-11-10T10:41:20Z""
""pdf:docinfo:creator"",""Pryor, Carissa - (carissapryor)""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Pryor, Carissa - (carissapryor)""
""dc:language"",""en-US""
""meta:author"",""Pryor, Carissa - (carissapryor)""
""pdf:producer"",""MicrosoftÂŽ Word for Office 365""
""meta:creation-date"",""2020-11-10T17:41:20Z""
""created"",""2020-11-10T17:41:20Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""26""
""Creation-Date"",""2020-11-10T17:41:20Z""
""resourceName"",""62arizlrev877.pdf""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""2773"",""3584"",""3564"",""3629"",""3643"",""3911"",""3638"",""3181"",""3877"",""4059"",""3622"",""3723"",""3495"",""3758"",""3862"",""3380"",""3921"",""3769"",""3727"",""3730"",""3548"",""3676"",""3471"",""3510"",""3391"",""2282""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""Author"",""Pryor, Carissa - (carissapryor)""
""producer"",""MicrosoftÂŽ Word for Office 365""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""MicrosoftÂŽ Word for Office 365""
""pdf:docinfo:created"",""2020-11-10T17:41:20Z""
";https://scholar.google.ch/scholar?start=650&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098720-10;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Conceptualizations of the controller in permissionless blockchains;M Schellekens ; J. Intell. Prop. Info. Tech. & Elec. Com. L., 2020  HeinOnline;;"… Finally, there are so-called oracles. They provide information that is not yet readily available

in the blockchain … The BBC then acts as an oracle for the blockchain. 18 A distinction can

be made between the infrastructure level and the application level …";Autres articles;;[PDF] jipitec.eu;https://www.jipitec.eu/issues/jipitec-11-2-2020/5099/blockchain_pdf.pdf;"
Conceptualizations of the controller in permissionless blockchains

2020215 2

Conceptualizations of the controller 
in permissionless blockchains
by Maurice Schellekens*

Š 2020 Maurice Schellekens

Everybody may disseminate this article by electronic means and make it available for download under the terms and 
conditions of the Digital Peer Publishing Licence (DPPL). A copy of the license text may be obtained at http://nbn-resolving.
de/urn:nbn:de:0009-dppl-v3-en8.

Recommended citation: Maurice Schellekens, Conceptualizations of the controller in permissionless blockchains, 11 (2020) 
JIPITEC 215 para 1.

Keywords:  Controller; Blockchain; permissionsless Blockchain; GDPR

blockchain. These conceptualizations give different 
perspectives on the relations between the actors in 
a blockchain that are potential controllers. The arti-
cle identifies who is most likely to be the controller in 
the different conceptualizations and gives indications 
about the extent to which the controllers are able to 
exercise their responsibilities.  A problem is that an 
adequate exercise of responsibility requires coordi-
nation within the blockchain. However, the system 
that normally takes care of coordination in a permis-
sionless blockchain – the crypto-economic incentive 
system – is at present not able to provide adequate 
data protection. 

Abstract:  The relationship between block-
chain and the General Data Protection Regulation 
(hereinafter GDPR) is often described as problematic.  
This article addresses one of the problems blockchain 
faces: who is/are the controller(s) in a blockchain con-
text? This article demonstrates that it is particularly 
difficult to identify the controller in blockchain appli-
cations that are integrated in the core code of a per-
missionless blockchain. The P2P character of block-
chains, with its broad distribution of responsibilities, 
makes it difficult to ascertain who is able to deter-
mine purposes and means of the processing of data. 
In order to structure the discussion, this article devel-
ops three conceptualizations of cooperation within a 

A. Introduction 

1 Blockchain is a distributed ledger that introduces a 
new way of processing data.   Data on a blockchain 
are immutable and storage is independent from the 
intermediaries, involved in managing the blockchain. 
There is a – currently unproven - promise of new 
business models and innovation.

2 Blockchain’s relationship with the GDPR is tense, not 
least because it is difficult to establish accountability 
in a blockchain. Blockchain’s horizontal character 
is laid out to minimize the influence of individual 
administrators within the blockchain.

3 The dilution of influence makes it difficult to 
pinpoint who determines purposes and means of data 
processing, in other words, who is the controller.

4 This article seeks to bring the discussion regarding 
accountability a step further by discerning three 
ways of conceptualizing the relations or cooperation 
between the actors in a blockchain context. 

5 This article proceeds as follows. In the next 
section, blockchain technology will be explained 
for the purposes of this article. The following 
section analyses controllership and presents the 
conceptualizations of the relations amongst relevant 
actors. The fourth section is the conclusion.



2020

Maurice Schellekens

216 2

B. Blockchain technology 

I. Distributed database

6 A blockchain is in essence a distributed database, i.e. 
a database of which multiple copies exist. Every copy 
is stored on a computer within a network (a node) 
and each node has an administrator. If new data or 
transactions are added to the blockchain, they are 
first collected in a so-called block and are then en 
bloc appended to the end of the existing blockchain. 
The newly added block has a pointer (a hash) linking 
it to the last block in the existing chain. 

7 The Bitcoin blockchain is the architype blockchain 
and this has shaped how we see a blockchain. The 
basic processes of the Bitcoin blockchain are adopted 
in other blockchains, such as Ethereum. The Bitcoin 
blockchain was first described in Satoshi Nakamoto’s 
paper of 2008, entitled: “Bitcoin: A Peer-to-Peer 
Electronic Cash System”. 1 In his paper, Nakamoto 
identifies the immutability of the data that the 
blockchain contains as its core characteristic. Here, 
“immutability” means that once data has been added 
to the blockchain, it can no longer be changed or 
deleted from the blockchain, not even by the 
administrator of a node who added the data to the 
block. The reason Nakamoto strives for immutability 
is to obviate trust in the administrator or any other 
actor that may persuade the administrator to alter 
or remove data from the database. Nakamoto’s paper 
appeared during the financial crisis of 2008 when 
trust in banks was at a low point. Bitcoin, which is 
a crypto-currency, was meant to create internet 
money that could function without an intermediary, 
like a bank. All previous attempts at creating 
internet money needed an intermediary to prevent 
double spending. The Bitcoin blockchain claims to 
have made trust in intermediaries redundant. The 
questions regarding whether a blockchain really 
succeeds in doing so and whether that is a useful 
property at all, will not be addressed here. This 
section of the article focuses on the question of 
how immutability of the contents of the database 
is realized.

8 A first means to create immutability is redundancy. 
As stated above, there exist multiple copies of the 
database under the control of various administrators. 
Redundancy reduces the dependence on each 
individual node administrator. In ways that will 

* Senior researcher at Tilburg Institute for Law, Technology, 
and Society, Tilburg University.

1 Satoshi Nakamoto, ‘Bitcoin: A Peer-to-Peer Electronic Cash 
System’ [2008] 1 <https://bitcoin.org/bitcoin.pdf> accessed 
6 June 2019.

become apparent below, an alteration or deletion 
of data on the blockchain by one administrator will 
not affect what is seen as the valid blockchain.

9 A second means to create immutability is reliance on 
crypto-economic incentives. There are positive and 
negative incentives to make the administrators of 
nodes play by the rules of the game (i.e. the protocol). 
A positive incentive is that an administrator can earn 
bitcoins by playing by the rules. A negative incentive 
is that an administrator first has to invest (for 
example in computer equipment and electricity) in 
order to be able to earn bitcoins. If the administrator 
does not adhere to the protocol, his investment will 
be in vain.

10 The redundancy and crypto-economic incentives 
work towards immutability of the contents of the 
blockchain in ways that will become apparent below. 
At the same time, the existence of multiple copies 
(or perhaps better versions) of the database creates 
a new problem, namely the risk that they will exhibit 
differences in the data they register. In other words, 
there is a need to sync the versions. This requires 
coordination within the blockchain. A traditional 
way to create such coordination is to designate one 
database as the master and all other databases as 
the slaves that have to follow the master at all times. 
This would however re-introduce centralization, 
dependence on the master database, and trust in its 
administrator, which Nakamoto deems undesirable. 
So the challenge is to create coordination while 
maintaining decentralization. A first step in creating 
coordination is the definition of what counts as the 
valid blockchain; this is defined as the longest chain 
consisting purely of valid blocks. How a valid block 
is defined will become apparent below. 

11 The way in which new blocks are added to the 
blockchain elucidates how the coordination can 
be achieved while maintaining decentralization.2 
During a period of about ten minutes, each node 
collects new transactions (new data to be added to 
the blockchain) and places them in a candidate-block. 
Each node prepares his own candidate block. He 
checks all incoming transactions on double spending 
by comparing the transactions to the contents of the 
blockchain. The node includes in his candidate-block 
a reference to the last block of what he thinks is the 
longest existing chain. At the end of the ten-minute-
period, the candidate blocks are finalized and the 
nodes start solving a cryptographic puzzle based on 
their candidate blocks. They compete against each 
other to be the first to solve their puzzle. The first 
node to solve his cryptographic puzzle, sends his 
Proof-of-Work (i.e. the proof he solved his puzzle) 
to all the other nodes, who then verify that our node 

2 Andreas M Antonopoulos, Mastering Bitcoin: Programming the 
Open Blockchain (O’Reilly Media 2017) ch 2.



Conceptualizations of the controller in permissionless blockchains

2020217 2

solved his cryptographic puzzle. If they are satisfied 
that he did so, they accept the candidate block of 
the winner as the new block that they add to the 
blockchain. An administrator does so by including 
a reference to this block in his new candidate block. 
In other words, an administrator indicates what 
the valid chain is by building on it. The duration 
of the ten minute period derives from the time it 
costs with the most advanced computers to solve 
the cryptographic puzzle. So, while a node is solving 
the crypto-graphic puzzle based on his candidate 
for the n-th block (costing about ten minutes), he 
is already collecting new transactions for his (n+1)
th block during the same ten minutes. Once some 
node has found proof-of-work for the n-th block, 
immediately a new competition starts for proof-of-
work of the (n+1)th block. A valid block is a block for 
which proof-of-work exists and that contains only 
valid transactions. Each node has written a sort of 
cheque to itself into its candidate block and only 
the winning node can cash in on this cheque, since 
only its own block is added to the blockchain that is 
considered valid.

12 This all creates a blockchain that is immutable in the 
sense described above. This can be seen as follows. 
Suppose that a node changes the contents of an old 
block somewhere in the middle of the chain. Then, 
the proof-of-work of this block is no longer valid and 
also the reference in the subsequent block to the 
modified block is no longer correct. This means that 
the chain of our node is broken. It is no longer the 
longest chain and will be ignored by the other nodes: 
they can only earn bitcoins by building on the longest 
chain. So, changing data in an old block is strongly 
discouraged. It disqualifies the administrator for 
meaningful participation in the blockchain.

13 The above describes how the bitcoin blockchain 
works. The Bitcoin blockchain is a so-called 
permissionless blockchain. This means that 
everybody can become a node mining for a reward. 
Nobody needs “admission” to become a node.
Permissionless blockchains work with crypto-
economic incentives of which the above are an 

example.3 A node is not bound by contract or another 
legal instrument. Another example of a blockchain 
with miners is Ethereum 1.0.

II. Proof-of Stake

14 Although the Bitcoin blockchain is sometimes seen 
as an outlier in its rejection of legal instruments as 
sources of trust, other more mainstream or business 
oriented blockchains, such as Ethereum, work with 
the same technical concept.4 Ethereum has until now 
relied on Proof-of-Work, just as Bitcoin. However, 
Proof-of-Work exhibits certain shortcomings in 
terms scalability and sustainability. Therefore, 
Ethereum seeks to switch to an alternative technical 
concept, Proof-of-Stake. Where miners commit 
computer equipment and electricity, validators in 
Ethereum 2.0 commit Ether, i.e. the cryptocurrency 
of Ethereum. Under the envisaged Proof-of-Stake 
mechanism, the next block to add is chosen through 
voting. The vote of a validator is weighed according 
to the amount of Ether he has committed (the stake). 
Since the validators cannot trust each other and 
since they communicate over an unsafe network (the 
internet), fraud is a problem.5 This requires Ethereum 
to take measures to prevent fraud, to detect it and 
to redress it, e.g. by finding ways to automatically 
“slash” the stake of fraudulent validators. Even 
though Ethereum has often announced dates at 
which the switch to Proof-of-Stake would take place, 

3 There are also so-called permissioned blockchains. In 
order to become a node in a permissioned blockchain a 
person needs to be admitted. Sometimes a central party is 
charged with admissions. It can also be that the collective 
of existing node administrators decides about new 
admissions. A permissioned blockchain can also work with 
crypto-economic incentives. It may however be that such a 
blockchain works with a simpler coordination mechanism, 
such as a round-robin system; each node in turn delivers a 
new block (BitFury Group in collaboration with Jeff Garzik, 
‘Public versus Private Blockchains. Part 1: Permissioned 
Blockchains’, White Paper, 20 October 2015 (Version 1.0), 5). 
In the latter case, it is also easy to accommodate a procedure 
to modify the contents of old blocks. This is the reason that 
some do not consider these permissioned blockchains to be 
blockchains at all.

4 Alyssa Hertig, ‘How Ethereum mining works’ (Ethereum 
101) <https://www.coindesk.com/learn/ethereum-101/
ethereum-smart-contracts-work> accessed 4 May 2020.

5 In this context, inter alia the nothing-at-stake attack, the 
long range attack and an attack by a cartel can be mentioned. 
See Vlad Zamfir, ‘The history of Casper’ (Ethereum blog, 
6 December 2016) ch 1,2 and 5. <https://blog.ethereum.
org/2016/12/06/history-casper-chapter-1/> accessed 4 
May 2020.



2020

Maurice Schellekens

218 2

the switch has – at the moment of writing – not 
materialized and Proof-of-Work remains relevant 
for the time being.

III. Smart contracts

15 Above we considered that data (e.g. bitcoin 
transactions) are stored on a blockchain. In the 
(permissionless) blockchain Ethereum, users can 
place code on the blockchain. The code placed on the 
blockchain is immutable in the same way that data 
on the blockchain are immutable.6 Moreover, the 
code can be executed by the nodes if some (other) 
user seeks to do so. For example, a hotel may place 
code on a blockchain that opens an IoT hotel room 
door after the code has checked that the hotel guest 
has paid for the night.7 Such code is called a smart 
contract.8 One must however bear in mind that a 
smart contract is simply code. It is not said that the 
code forms a contract in the legal sense, even though 
many applications, such as the example above, are in 
a domain that is reminiscent of contracts. It is also 
not said that a smart contract is smart in the sense 
that it uses artificial intelligence or something along 
the same lines. The example above is illustrative 
again. The smart contract may typically function as 
a trusted middle man.

IV. ICOs

16 A popular application of permissionless blockchains 
is an Initial Coin Offering (hereinafter ICO). It is a 
means of crowdfunding whereby newly issued 
tokens are sold to investors or speculators in 

6 In order to address concerns about the immutability 
of smart contracts, the function ‘delegatecall’ has been 
developed. A call of an undesired smart contract can be 
relayed to another contract. Merunas Grincalaitis, ‘Can 
a Smart Contract be upgraded/modified? Is CPU mining 
even worth the Ether? The Top questions answered here…’, 
(Medium, 6 February 2018) <www.medium.com> accessed 6 
June 2019.

7 Vitalik Buterin, ‘DAOs, DACs, DAs and More: An Incomplete 
Terminology Guide’ (Ethereum Blog, 6 May  2014) <https://
blog.ethereum.org/2014/05/06/daos-dacs-das-and-more-
an-incomplete-terminology-guide/> accessed 21 October 
2019.

8 Term coined by Szabo in: Nick Szabo, ‘Smart Contracts: 
Building Blocks for Digital Markets’, 1996 <http://www.fon.
hum.uva.nl/rob/Courses/InformationInSpeech/CDROM/
Literature/LOTwinterschool2006/szabo.best.vwh.net/
smart_contracts_2.html> accessed 6 June 2019. It predates 
blockchain.

exchange for legal tender or cryptocurrencies.9 
Most ICOs are built on the Ethereum platform. 
This platform is popular, since an ICO can easily be 
programmed as an Ethereum smart contract and the 
standardization of certain aspects of tokens within 
Ethereum allows for the tradability of the tokens.10 
There are various types of tokens that can be issued. 
Usually a distinction is made between utility tokens 
and equity tokens.11 A utility token gives the holder 
the right to buy in the future certain products or 
services from the issuer. This is typically the product 
or service developed with the capital that the ICO 
yields. An equity token gives the holder certain 
rights that can be exercised against the issuing 
company, such as a right to profits generated or a 
share in the residual value if and when the company 
is liquidated. Although this article is not the place 
to discuss whether an ICO is subject to financial 
regulations, it can be said that some ICOs will indeed

9 Patrick Schueffel, ‘The Concise Fintech Compendium’, 
(School of Management Fribourg (HEG-FR)), <https://web.
archive.org/web/20180425130029/http://www.heg-fr.ch/
FR/HEG-FR/Communication-et-evenements/evenements/
Documents/Schueffel2017_The-Concise-FINTECH-
COMPENDIUM.PDF> accessed 4 May 2020, gives a more 
restrictive definition: ‘An ICO is an unregulated means of 
crowdfunding applied by cryptocurrency businesses as an 
alternative to the rigorous and regulated capital-raising 
process required by venture capitalists, banks, or stock 
exchanges. In an ICO a percentage of the newly issued 
cryptocurrency is sold to investors in exchange for legal 
tender or other cryptocurrencies such as Bitcoin.’

10 Almost 57% of ICOs builds on Ethereum smart contracts. 
Almost 30% of the ICOs works with a dedicated 
blockchain for the ICO. Source: <https://web.archive.org/
web/20171230074510/https://icowatchlist.com/blog/ico-
market-research-leading-blockchain-platforms-2017/> 
accessed 4 May 2020. Gianni Fenu, Lodovica Marchesi, 
Michele Marchesi and Roberto Tonelli, ‘The ICO Phenomenon 
and Its Relationships with Ethereum Smart Contract 
Environment’ [2018] IEEE <https://www.researchgate.
net/publication/324099008_The_ICO_phenomenon_
and_its_relationships_with_ethereum_smart_contract_
environment/link/5db84e6ca6fdcc2128eb86e1/download> 
accessed 3 May 2020. Romi Kher, Siri Terjesen and Chen 
Liu, ‘Blockchain, Bitcoin, and ICOs: a review and research 
agenda’ [2019] Small Bus Econ, Springer <https://doi.
org/10.1007/s11187-019-00286-y> accessed 3 May 2020.

11 J. Baukema, ‘Initial Coin Offerings (ICO’s): crowdfunding 
2.0?’ (2018) (3) Tijdschrift voor financieel recht, 113 
<https://www.vandoorne.com/globalassets/documenten--
bijlagen/publicaties/2018/j.-baukema---icos.pdf> accessed 
4 May 2020.



Conceptualizations of the controller in permissionless blockchains

2020219 2

be caught by such regulation.12 This is relevant for 
the discussion about data protection below, since it 
can trigger KYC and AML obligations.13 

V. Actors in a blockchain

17 Many actors are involved in blockchains. For the 
purpose of this article the following are discerned.  
The core developers develop the code that constitutes 
the blockchain. There are administrators of nodes. 
In the description above they solve cryptographic 
puzzles, they store a version of the entire 
blockchain and check transactions. Often these 
tasks are however divided over two types of node 
administrators. On the one hand, there are miners 
who solve cryptographic puzzles or validators who 
vote, and on the other hand, there are administrators 
of so-called full nodes: they store an entire copy of 
the blockchain and check transactions. Users are the 
actors that place transactions or smart contracts on 
the blockchain. Finally, there are so-called oracles. 
They provide information that is not yet readily 
available in the blockchain. For example, if two 
parties bet via a blockchain on the temperature 
in London tomorrow the blockchain may derive 
information about the temperature from the website 
of the British Broadcasting Corporation (BBC). The 
BBC then acts as an oracle for the blockchain.

18 A distinction can be made between the infrastructure 
level and the application level. At the infrastructure 
level, you find the core code that constitutes the 
blockchain. At the application level you find smart 
contracts, i.e. user inserted code. However, this 
distinction is marred somewhat by the fact that 
a cryptocurrency is infrastructure level (coded 
by the core developers and needed to make the 
consent mechanism function), but it feels like an 
application as well. For those making payments 
with Bitcoin, it clearly functions as an application. 
A permissionless blockchain is always public. This 
means that everybody can read the data or smart 
contracts stored on the blockchain. 

C. Blockchain and the GDPR

19 The GDPR is applicable to the processing of personal 
data. For an analysis of blockchains, this implies that 
relevant instances of processing of personal data 
need to be identified and asked whether the data

12 Baukema (n 12) 119-120.

13 Baukema (n 12) 120 mentions the example of an issuer of 
tokens that can be found to be an investment institution.

involved are personal data for the actors who are 
potential controllers. Subsection C.I below addresses 
these questions.            

20 In literature, it is argued that the GDPR is unfit for 
application to blockchains.14 Blockchain’s peer-to-
peer character would not sit well with the conceptual 
idea about processing of data underlying the GDPR, 
namely the idea of a centralized database with a clear 
administrator. Hereinafter in subsections C.II and 
C.III, this article will investigate how blockchain’s 
P2P character relates to who should be considered 
data controller and data processor. 

I. Personal data

21 Participation in the Bitcoin blockchain happens 
via digital signatures, a pair of private and public 
keys.  The public keys of those participating in a 
transaction are stored in the public blockchain. To 
prevent more than two transactions being linked 
together, participants change their digital signature 
as often as possible.15 This should make it difficult 
for a party to be singled out in the blockchain and 
identified by combination with other information. 
This may even be effective, unless a party seeking 
identification has very powerful analysis tools. 
Typically, only law enforcement and security 
services would be in a position where motive, and 
analytical capacity come together to engage in such 
an identification endeavor. Nonetheless, it cannot 
be excluded that also other parties, and especially 
potential controllers such as users and full nodes, 
can arrive at an identification. 

22 First, a user who engages in a transaction with 
another party may know the identity of the other 
party or at least have background information 
that makes identification more likely. After all, 
transactions do not take place in complete social 
vacuum.  

23 Second, full nodes do receive the transactions via 
the internet. This gives access to IP addresses from 
which transactions are sent. Usually a full node will 
not be able to infer an identity from an IP address. 
Since the decision of the CJEU in the Breyer case, it 
is clear that information available to a third party 
may come in the ambit of means reasonably likely to 
be used, unless the effort needed to access it would 
be disproportionate and “the risk of identification 

14 Meyer (n 1). Finck (n 1) 88.

15 The transaction in which a ‘bitcoin’ is received is linked to 
the transaction in which it is spent again.



2020

Maurice Schellekens

220 2

appears in reality to be insignificant”.16 Given that 
illegal content may be stored on a blockchain e.g. 
via a bitcoin transaction,17 a full node can have an 
interest in knowing who placed illegal information 
on the full node’s system. This would require 
cooperation from an internet provider who can link 
the IP address to an identity legally. A claim to obtain 
personally identifying information of the person 
who placed the content on the blockchain from 
the pertinent Internet Provider has a good chance 
of being found proportional.18 The immutability 
of the blockchain makes removal of content from 
the blockchain extremely costly for the full node. 
Therefore, being able to address the uploader is an 
important means to prevent or discourage illegal 
content upload from re-occurring in the future.

24 Above, it was indicated that an issuing company in 
an ICO may be required to collect KYC-information 
and in practice, KYC information is indeed 
collected.19 KYC obligations require identification 
of the customer or its beneficial owner.20 Given 
the smaller amounts that can be paid into an ICO, 
the customer or the beneficial owner will often be 
a natural person. Therefore, KYC information will 
often consist of personal data.

16 Case C-582/14, Patrick Breyer v Bundesrepublik 
Deutschland, ECLI:EU:C:2016:779, para 46.

17 Roman Matzutt, Jens Hiller, Martin Henze, Jan Henrik 
Ziegeldorf, Dirk Mullmann, Oliver Hohlfeld, and Klaus 
Wehrle, ‘A Quantitative Analysis of the Impact of Arbitrary 
Blockchain Content on Bitcoin’, to appear in Proc. 22nd 
International Conference on Financial Cryptography 
and Data Security 2018. Proceedings to be published via 
Springer LNCS: <http://www.springer.de/comp/lncs/
index.html>, <https://www.comsys.rwth-aachen.de/
fileadmin/papers/2018/2018_matzutt_bitcoin-contents_
preproceedings-version.pdf> accessed 4 May 2020.

18 Case C275/06, Productores de MĂşsica de EspaĂąa (Promusicae) 
v TelefĂłnica de EspaĂąa SAU, ECLI:EU:C:2008:54, para 70. 

19 See <www.topicolist.com> accessed 7 May 2020.

20 Art. 13 Directive (EU) 2018/843 of the European Parliament 
and of the Council of 30 May 2018 amending Directive (EU) 
2015/849 on the prevention of the use of the financial 
system for the purposes of money laundering or terrorist 
financing, and amending Directives 2009/138/EC and 
2013/36/EU [2018] OJ L156/43.

II. The data controller

25 The GDPR defines the controller as the person 
who “determines the purpose of and means for 
processing personal data”.21 In a blockchain context, 
often a central party can be distinguished who is 
responsible for offering a service. This party will 
also be considered to be the controller within the 
meaning of the GDPR, assuming that the service 
includes the processing of personal data. This party 
chooses the purpose (the service) and the means 
(e.g. a smart contract). For example, if a company 
collecting capital via an ICO uses a smart contract 
to code the ICO, it can itself be regarded as the 
controller since it determines purpose (ICO) and 
means (blockchain-based smart contract). If KYC 
obligations apply to the ICO, the issuing company 
processes the data that need to be collected. If a 
custom made blockchain is used for the ICO (which 
is rather the exception) in essence the same holds. 
Another example is an insurer that offers a form to 
claim for damages through a smart contract.22 The 
insurer is responsible for the processing of personal 
data in the completed forms. An oracle that provides 
personal data to a smart contract will generally 
also be considered responsible for the delivery of 
personal data. Whoever offers a service will usually 
be apparent from the service on offer. For example, 
the person who presents himself as a service 
provider in a smart contract. If a service is offered 
anonymously, the identification of who is offering 
the service needs to look at other elements. Whoever 
has placed the smart contract on the blockchain 
could be an indication of this. Although blockchain 
considers decentralization to be of paramount 
importance, it is often possible to identify a central 
party that can function as a controller, in particular 
where the application is coded in Ethereum smart 
contracts.

1. More challenging cases

26 If the “application” is part of the core code, it is more 
challenging to find out who the controller is. Who is 
the controller of bitcoin transactions for example? 
The core developers are responsible for the code that 
constitutes the blockchain and its native

21 Art. 4 sub 7 Regulation (EU) 2016/679 of the European 
Parliament and of the Council of 27 April 2016 on the 
protection of natural persons with regard to the processing 
of personal data and on the free movement of such data, 
and repealing Directive 95/46/EC (General Data Protection 
Regulation) [2016] OJ L 119/1.

22  Example borrowed from CNIL, Blockchain. Premiers ĂŠlĂŠments 
d’analyse de la CNIL (Sept. 2018).



Conceptualizations of the controller in permissionless blockchains

2020221 2

cryptocurrency. They are however not involved in 
the day-to-day running of the blockchain. We will 
consider their role below. 

27 That leaves us with the users and the administrators of 
nodes as potential data controllers in permissionless 
blockchains. However, it is not so easy to see who 
amongst them is a data controller and why. It 
depends very much on how their roles and mutual 
relations are perceived. Hereinafter, we discern 
three conceptualizations that represent three 
alternative views on permissionless blockchains 
and on the relationships amongst the main actors 
involved in the operation of the blockchain. 
The conceptualizations help to unravel some of 
the confusion that exist around permissionless 
blockchains and controllership under the GDPR. 
In a first conceptualization, the emphasis is on the 
users that together form a P2P network. In a second 
conceptualization, the full nodes together offer a 
service, and in in the third conceptualization each 
full node is seen as an individual service provider. 

a) The users form a P2P 
network with each other

(aa) What is the conceptualization?

28 This conceptualization closely follows the 
argumentation of Nakamoto. Users deal with each 
other without reliance on potentially untrustworthy 
intermediaries. If A pays bitcoins to B, A and B deal 
with each other directly. The administrators of 
automated nodes in between are discarded from the 
picture. The system of crypto-economic incentives 
ensures that the administrators individually 
cannot influence the global state of the blockchain. 
Their involvement is of a passive nature. They 
provide technical support to the functioning of the 
blockchain. They blindly execute the protocols of 
the blockchain. 

(bb) How does it map to the GDPR?

29 A user sends data to the blockchain that are then 
further processed within the blockchain. The user 
instigates the initial sending of the data and is 
therewith controller of this initial transmission.23 

23 Compare Case C40/17, Fashion ID GmbH & Co. KG v 
Verbraucherzentrale NRW e.V.  [2018] ECLI:EU:C:2018:1039. 
The Fashion ID case concerns a Facebook like-button on a 
webpage, causing data about visitors to the website to be 
sent to and further processed by Facebook, irrespective of 
whether the visitors pressed the button. The question was 

An  interesting question is whether there are 
circumstances under which the GDPR considers the 
user (A in the example above) also as the controller of 
processing that occurs subsequent to transmission, 
i.e. when the data are with the administrators? The 
strongest argument for the user as a controller 
is that he chooses to use a certain blockchain or 
blockchain application. Therewith he also chooses 
the processing of data that flows from his choice. 
This is in line with the conclusion of AG Bot in the 
Wirtschaftsakademie case. Bot indicates that a 
Facebook fan page administrator should be seen as a 
controller, because he makes the processing possible 
by creating and operating the fan page,24 even though 
he may foremost be seen as a user of Facebook.25 It 
is also in line with the guidance document of the 
French CNIL where it says: “les participants, qui ont 
un droit d’écriture sur la chaîne et qui décident de 
soumettre une donnĂŠe Ă  la validation des mineurs 
peuvent ĂŞtre considĂŠrĂŠs comme responsables de 
traitement.”26 The CNIL seems to have thought in this 
context primarily of a user a";"""date"",""2020-08-27T21:07:04Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.6""
""xmp:CreatorTool"",""Adobe InDesign 15.1 (Windows)""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dcterms:created"",""2020-08-27T20:55:31Z""
""language"",""en""
""Last-Modified"",""2020-08-27T21:07:04Z""
""dcterms:modified"",""2020-08-27T21:07:04Z""
""dc:format"",""application/pdf; version=1.6""
""xmpMM:DocumentID"",""uuid:4afc43cc-af93-4a3d-9513-c855be37c9c9""
""Last-Save-Date"",""2020-08-27T21:07:04Z""
""pdf:docinfo:creator_tool"",""Adobe InDesign 15.1 (Windows)""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2020-08-27T21:07:04Z""
""meta:save-date"",""2020-08-27T21:07:04Z""
""pdf:encrypted"",""false""
""xmp:CreateDate"",""2020-08-27T22:55:31Z""
""modified"",""2020-08-27T21:07:04Z""
""Content-Length"",""303184""
""pdf:hasMarkedContent"",""true""
""Content-Type"",""application/pdf""
""xmp:ModifyDate"",""2020-08-27T23:07:04Z""
""xmp:MetadataDate"",""2020-08-27T23:07:04Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""pdf:producer"",""Adobe PDF Library 15.0""
""meta:creation-date"",""2020-08-27T20:55:31Z""
""created"",""2020-08-27T20:55:31Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""13""
""Creation-Date"",""2020-08-27T20:55:31Z""
""resourceName"",""blockchain_pdf.pdf""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""3268"",""5378"",""4919"",""5083"",""4792"",""4905"",""5204"",""4992"",""5446"",""5047"",""5203"",""5085"",""760""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""producer"",""Adobe PDF Library 15.0""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""Adobe PDF Library 15.0""
""pdf:docinfo:created"",""2020-08-27T20:55:31Z""
";
1619098800-185;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Resource pools and the cap theorem;A Lewis;Pye, T Roughgarden  arXiv preprint arXiv:2006.10698, 2020  arxiv.org;;"… explicitly in the blockchain being modeled, and is a mathemati- cal abstraction that allows for

the … each user to be a com- puting device with access to certain external oracles and function-

alities … state and the set of permissions they have been given by the permitter oracle O. The …";Cité 4 fois;Les 2 versions;[PDF] arxiv.org;https://arxiv.org/pdf/2006.10698;"
ar
X

iv
:2

00
6.

10
69

8v
1 

 [
cs

.D
C

] 
 1

8 
Ju

n 
20

20

Resource Pools and the CAP Theorem

Andrew Lewis-Pye
a.lewis7@lse.ac.uk

Department of Mathematics, London School of
Economics
London

Tim Roughgarden∗

tim.roughgarden@gmail.com
Columbia University

New York

ABSTRACT

Blockchain protocols differ in fundamental ways, including theme-
chanics of selecting users to produce blocks (e.g., proof-of-work vs.
proof-of-stake) and themethod to establish consensus (e.g., longest
chain rules vs. BFT-inspired protocols). These fundamental differ-
ences have hindered “apples-to-apples” comparisons between dif-
ferent categories of blockchain protocols and, in turn, the develop-
ment of theory to formally discuss their relative merits.

This paper presents a parsimonious abstraction sufficient for
capturing and comparing properties of many well-known permis-
sionless blockchain protocols, simultaneously capturing essential
properties of both proof-of-work and proof-of-stake protocols, and
of both longest-chain-type and BFT-type protocols.Our framework
blackboxes the precise mechanics of the user selection process, al-
lowing us to isolate the properties of the selection process which
are significant for protocol design.

We illustrate our framework’s utility with two results. First, we
prove an analog of the CAP theorem from distributed computing
for our framework in a partially synchronous setting. This theo-
rem shows that a fundamental dichotomy holds between proto-
cols (such as Bitcoin) that are adaptive, in the sense that they can
function given unpredictable levels of participation, and protocols
(such as Algorand) that have certain finality properties. Second, we
formalize the idea that proof-of-work (PoW) protocols and non-
PoW protocols can be distinguished by the forms of permission
that users are given to carry out updates to the state.

CCS CONCEPTS

• Theory of computation;

KEYWORDS

blockchains, cryptocurrencies, distributed computing, CAP theo-
rem

1 INTRODUCTION

The task of a permissionless blockchain protocol is to establish con-
sensus for message ordering over a network of users. This job is
made difficult by the fact that, being subject to the laws of physics,
the underlying communication networkmust have latency, i.e. broad-
cast messages will necessarily take time to travel over the network
of users. As a consequence of this latency, malicious users may
purposely cause the order in which messages are first seen to be
different for different honest users, and some differences in order-
ing will anyway be an honest consequence of varying propagation
times between different nodes of the network [9].

∗Supported in part by NSF Award CCF-1813188, ARO grant W911NF1910294, and a
grant from the Columbia-IBM Center for Blockchain and Data Transparency.

Network latency is especially problematic when we work at
the level of individual transactions, which may be produced at a
rate which is high compared to network latency. For this reason
it is standard practice to collect transactions together into blocks,
which can then be produced at a rate which is much lower com-
pared to network latency. Given that we are working in a permis-
sionless setting, the basic question then becomes, “Who should
produce the blocks?”. This question is answered differently by dif-
ferent protocols. Three running examples, which we shall use for
reference in this paper, are:

• Bitcoin;
• Snow White;
• Algorand.

Of course, Bitcoin [16] is the best known proof-of-work (PoW)
protocol, and is also a longest chain protocol. This means that forks
may occur in the blockchain, but that honest miners will build on
the longest chain. At a high level, Snow White [1] might be seen
as a proof-of-stake (PoS) version of Bitcoin – it is also a longest
chain protocol, but now miners are selected with probability pro-
portional to their stake in the currency, rather than their hashing
power. We use Algorand [8] as an example of a ‘BFT’ protocol.1

This means that users are selected, and asked to carry out a con-
sensus protocol designed for the permissioned setting. So users are
not only asked to produce blocks, but also other objects, such as
votes on blocks. Algorand is also a PoS protocol.

Such fundamental differences between competing blockchain
protocols have hindered “apples-to-apples” comparisons between
them, and a majority of the research-to-date has focused on the
analysis of specific protocols (or narrow classes of protocols). Our
goal here is to complement existing work on protocol-specific anal-
ysis with a mathematical framework for formally discussing the
relative merits of protocols of very different types.

The first and main aim of this paper is to develop amodel for the
analysis of permissionless blockchain protocols that blackboxes
the precise mechanics of the user selection process, allowing us to
isolate the properties of the selection process that are significant,
and to make comparisons between blockchain protocols of differ-
ent types. Section 2 describes a framework of this kind, according
to which protocols run relative to a resource pool. This resource
pool specifies a balance for each user over the duration of the pro-
tocol execution (such as hashrate or stake), which may be used in
determining which users are permitted to make publications up-
dating the state.

1By ‘BFT protocols’ we shall (informally) mean either: (a) Consensus protocols which
are defined in the permissioned setting in order to deal with byzantine faults, or (b)
Consensus protocols which work in the permissionless setting by importing protocols
of type (a).

http://arxiv.org/abs/2006.10698v1


Andrew Lewis-Pye and Tim Roughgarden

With this framework in place, we then turn our attention to con-
sider how properties of the resource pool may influence the func-
tionality of the resulting protocol. In Sections 3 and 4, we will be
concerned with the distinction between scenarios in which the size
of the resource pool is known (e.g. PoS), and scenarios where the
size of the resource pool is unknown (e.g. PoW). We refer to these
as the sized and unsized settings, respectively. We will find that the
choice of setting is intimately related to a fundamental tradeoff for
permissionless blockchain protocols, which can be viewed as an
analog of the CAP theorem from distributed computing [12] for
our framework: In a partially synchronous setting, a protocol can-
not deliver finality for block confirmations while at the same time
being adaptive, in the sense that it remains live without knowledge
of the size of the resource pool.2

In Section 5 we will examine a fundamental distinction between
PoW and non-PoW protocols, which concerns the forms of per-
mission that users are given to carry out updates to the state. We
formalize the idea that, under quite general conditions, PoW pro-
tocols are distinguished by their ability to allow the broadcast of
specific blocks (and other objects), rather than granting permission
to broadcast any object from a large class (such as any valid block
extending a given position in the blockchain). Historically, this is
one of the distinctions between PoW and PoS that has received the
most attention in the literature [2].

1.1 Finality and Adaptivity

Our main impossibility result, which appears in Section 4, con-
cerns notions of ‘finality’, ‘adaptivity’, ‘security’, and ‘liveness’. Be-
fore defining these terms, it is useful to consider how these notions
relate to another informal division that is often drawn in the cryp-
tocurrency community and in the literature [2], between ‘longest
chain’ type protocols such as Bitcoin and Snow White on the one
hand, and so called ‘BFT’ protocols such as Algorand [8] and Ten-
dermint [3] on the other.

Roughly speaking, the term ‘longest chain’ is normally applied
to protocols which are derived from Bitcoin, and which work by
having miners select a fork of the blockchain to build on, which is
defined in terms of some sort of scoring function for chains. The
selected chain might be the one with the most PoW attached, or it
might be the longest, or it might be defined by an inductive process
that counts the number of descendants, as in the GHOST protocol
[20]. BFT protocols, on the other hand, work by selecting a subset
of users and having them carry out a more traditional consensus
protocol which is defined for the permissioned setting. The terms
‘BFT’ and ‘longest chain’ are thus descriptive of where protocols
come from, but don’t yet formally define classes of protocols in a
way that allows us to analyse the differences between them and
prove results contrasting the performance of these classes of pro-
tocols in a broad sense.

The informal idea is that there is a trade-off. While BFT pro-
tocols potentially offer finality (whatever that should mean), this
comes with the price that the protocol will stall if participation lev-
els drop. In Algorand, for example, committees of users are selected

2Our impossibility result contrasts with previous works that prove positive re-
sults about the liveness and consistency properties of the Bitcoin protocol in more
strongly synchronous settings (such as synchronous networks [11] and networks with
bounded message delays [11, 13, 17, 19]).

in rounds, and block confirmation requires a certain proportion of
committee members to contribute signatures. If participation lev-
els drop to a point where insufficiently many signatures are being
produced for each block, then the process of block confirmation
will come to a standstill. Longest chain protocols such as Bitcoin,
on the other hand, do not deliver finality but are adaptive, in the
sense that they naturally adjust and remain live in the face of fluc-
tuating levels of participation.

In order to make this trade-off precise, we must decide how to
formalize ‘finality’ and ‘adaptivity’. First, let us consider finality.
To define this notion, we focus on differentiating the settings (e.g.,
the degree of assumed synchrony) in which protocols are secure,
meaning that block confirmation can be relied on. Bitcoin andmost
other longest chain-type protocols will not be considered to have
finality, because block confirmation can only be relied on assuming
the ongoing participation of a large fraction of honest users: Block
confirmation is not secure against unbounded network partitions
[17]. Algorand and most BFT-type protocols will have finality be-
cause there is essentially zero chance that confirmed blocks will be
rolled back, even in the event that honest users cease to participate
after the block has been confirmed, e.g. due to an extended period
of network failure. Section 3 formalizes this distinction and our
finality notion in terms of security in a partially synchronous set-

ting. The distinction between synchronous and partially synchro-
nous settings is standard when working with permissioned proto-
cols [10]; see Section 2 for the definitions.

Next, let us consider adaptivity. Recall that, according to our
framework, protocols run relative to a resource pool. This resource
pool specifies a balance for each user over the duration of the pro-
tocol execution (such as hashrate or stake), which may be used in
determining which users are permitted to make publications up-
dating the state. So Bitcoin will be modeled as running relative to
a resource pool that specifies the hashrate of each user over the du-
ration of the protocol execution, and users with greater hashrate
will be more likely to be selected for block production. In Section
3, we will formally define adaptivity in terms of the information
about the resource pool that is available to the protocol. First, we
will define the unsized setting, so as to formalize contexts in which
the total size of the resource pool is information which is not avail-
able to the protocol. With this definition in place, and once we
have formalized the notion of ‘liveness’ – roughly, liveness is the
property that with high probability the set of confirmed blockswill
grow over time – we will then be able to define adaptive protocols
as those which are live in the unsized setting.3 Adaptive protocols
are thus those which are like Bitcoin—not necessarily in an opera-
tional sense, but in the sense that they are live even when the total
size of the resource pool is unknown to the protocol.

1.2 The tradeoff between adaptivity and
finality.

With these definitions in place, we will then be able to formally
prove Theorem 4.1 below, which can be seen as an analog of the
CAP Theorem [12] from distributed computing for our framework.

3One might want a protocol to satisfy stronger notions of liveness, such as quanti-
tative lower bounds on chain growth or chain quality (as in e.g. [11, 17]). The fact
that we work with such a weak notion of liveness only strengthens our impossibility
result.



Resource Pools and the CAP Theorem

Roughly speaking, ‘security’ in our framework corresponds to ‘atomic
consistency’ in the framework inwhich theCAPTheorem is proved
in [12], and ‘liveness’ corresponds to ‘availability’. These corre-
spondences are not exact, however. While availability requires a
response even during extended periods of asynchrony, our defini-
tion of liveness explicitly rules out the requirement that new con-
firmed blocks should be produced under such conditions. The key
observation in the proof of Theorem 4.1 is that, in the unsized set-
ting, extended periods of asynchrony cannot be distinguished from
a waning resource pool. Liveness therefore forces the production
of new confirmed blocks during appropriately chosen periods of
asynchrony. Liveness and security are thus incompatible in the par-
tially synchronous and unsized setting, while the same is not true
in the partially synchronous and sized setting.

Theorem 4.1 (Impossibility Result). No protocol is both adap-

tive and has finality.

This result establishes a simple dichotomy for permissionless
blockchain protocols. A protocol can be adaptive or it can have fi-
nality, but not both. It also draws a clean and formal line between
longest chain protocols such as Bitcoin and Ethereum [4], or PoS
implementations such as Snow White [1] on the one hand, and
BFT protocols such as Algorand, Casper FFG and PoS implementa-
tions of Tendermint or Hotstuff [21] on the other.While the former
group are all adaptive, the latter group all have finality.

Another interesting conclusion that can be drawn from Theo-
rem 4.1 concerns PoW protocols. PoS protocols are generally best
modeled using the sized setting, while PoW protocols are generally
best modeled using the unsized setting—the total stake is typically
information which is available to a protocol from the beginning of
its execution, while the amount of computational power used to
provide PoW can vary over time in an unpredictable way. To the
extent that PoW protocols must operate in an unsized setting (and
guarantee liveness), Theorem 4.1 implies that they cannot have fi-
nality.4

1.3 Related Work

The novel feature of Bitcoin that distinguishes it from previous
consensus protocols is that it is permissionless, i.e. it establishes
consensus between a set of users that anybody can join, with as
many identities as they choose in any given role. This paper can
be seen as a step towards developing a formal framework for the
analysis of permissionless protocols akin to the extensively devel-
oped one for permissioned protocols [15]. The study of byzantine
fault tolerant (BFT) consensus protocols in the permissioned set-
ting dates back at least to 1980 [14, 18]. Among those BFT protocols
of interest to us here, we can distinguish two forms:

(1) The oldest relevant form of BFT protocol is aimed at solving
the ‘Byzantine Generals Problem’ [14, 18]. The task here is
to reach consensus on a single yes/no decision. In applying
these methods to the blockchain setting, one approach, as
employed by Algorand, is to run such a BFT protocol for
each in a sequence of proposed blocks, until consensus is

4The continual adjustment of the difficulty parameter in Bitcoin can be viewed as an
attempt to maintain an approximation of the sized setting in a fundamentally unsized
setting. See Section 6.2 for further discussion.

reached for each block as to whether it should be included
in the blockchain. A drawback of this approach is that posi-
tive or negative consensus has to be reached for one block at
a time. A large number of rounds of communication may be
required before agreement is reached, giving a correspond-
ing negative impact on confirmation times.

(2) Perhaps more appropriate for the blockchain setting, since
they are designed to achieve essentially the same task as per-
missionless blockchain protocols but in the permissioned
setting, are BFT protocols designed for the purpose of state
machine replication (SMR) [6, 7]. The task of such protocols
is for a set of distributed users to agree on an order of execu-
tion for an ever growing list of client-initiated service com-
mands – replace ‘client-initiated service commands’ with
‘transactions’, and this is precisely the aim of permission-
less blockchain protocols. The advantage of this approach
is that it allows for considerably simpler protocols, which
might only require two or three rounds of communication
per block.

The CAP theorem is one of the most celebrated theorems in the
distributed computing literature. The theorem proved by Gilbert
and Lynch [12] is a formal version of a conjecture due to Brewer,
which is made in the context of distributed web services. The the-
orem establishes an impossibility result: It is impossible for such
a distributed service to simultaneously achieve the three desirable
properties of consistency, availability, and partition tolerance. For
formal definitions of these terms we refer the reader to [12] and
[15]. The relationship between the CAP Theorem and Theorem 4.1
was briefly discussed in Section 1.2, and we shall expand on this
discussion in Section 4.

2 THE FRAMEWORK

2.1 Predetermined and undetermined variables

Our aim here is to establish a framework for analysing permission-
less blockchain protocols that blackboxes the precise mechanics of
the user selection process. This will allow us to prove impossibility
results, and to isolate the properties of the selection process that
are significant, in the sense that they impact the way in which the
protocol must be designed, or influence properties of the resulting
protocol (such as security in a range of settings).

In order to define properties such as liveness and security later
on, it will be convenient to consider protocols that are specified rel-
ative to a finite set of initially defined parameters. For Algorand to
run securely, for example, one must first decide how long the pro-
tocol is to run for, and then choose committee sizes accordingly.
The duration of the execution is therefore required as a parameter
of the protocol. Variables that are specified before the execution of
the protocol as parameters, or which take the same value for all ex-
ecutions of the protocol, are referred to as predetermined. Variables
(such as the number of users) that are not predetermined, will be
referred to as undetermined.

2.2 The users

We consider settings in which protocols are executed by an un-
determined set of pseudonymous users, this set being of undeter-
mined size. Each user is given access to a signature scheme, and



Andrew Lewis-Pye and Tim Roughgarden

controls a set of public keys by which they will be known to other
users. We use the variable U to range over users, while U will be
used to range over public keys – each user may have many public
keys. Amongst all users, there is one who is distinguished as the
adversary and who controls an undetermined set of public keys.
Users other than the adversary are referred to as honest.

We will suppose that each user is a deterministic computing de-
vice, which has amongst the actions it can perform calls to certain
oracles, as well as certain external functionalities such as the abil-
ity to broadcast messages. The protocol specifies an instruction set,
which is a program which is run by every user, other than the ad-
versary. The adversary can follow any program of their choosing.

While we might think of the set of users as forming a network
over which messages can propagate, in order to keep things as sim-
ple as possible, we shall not make the network explicit in our frame-
work. Users simply have the ability to broadcast messages. Once a
message is broadcast by a public key belonging to a given user, it
may subsequently be delivered to other users at different stages of
the execution.

2.3 Network failures

We suppose that protocols are specified to run for a predetermined
sequence of timeslots, each timeslot being of predetermined length.
The appropriate length of these timeslots depends on the protocol
to be modeled. For many PoS protocols, an appropriate length is
slightly more than the network latency, i.e. the time it takes a block
to propagate the network. (Thus, each user might carry out many
instructions during a single timeslot.) We will see that PoW pro-
tocols might be better modeled using very short timeslots. In any
case, the sequence of timeslots is called the duration D. At the be-
ginning of each timeslot in the duration, broadcast messages may
be delivered to various users. The message state relative to a given
user is the set of all broadcast messages which have been delivered
to them. The message state for a given user is therefore monotoni-
cally increasing over time. In order to be broadcast, a message must
be valid, meaning that it must have a certain structure and that cer-
tain other conditions, expanded on below, are also satisfied.

For example, if modeling Bitcoin or Snow White, a user’s mes-
sage state will be the set of (valid) blocks that have been delivered
to them. Thus the message state will not, in general, be a single
chain of blocks. For Algorand, a user’s message state will be all
those messages which have been delivered to them, which are ei-
ther valid blocks, or else the signed messages of committee mem-
bers exchanged while reaching consensus on blocks.

It is standard in the distributed computing literature to consider
a variety of synchronous, partially synchronous, or asynchronous
settings, in which users may or may not have clocks which are
almost synchronised, or run at varying speeds, and where mes-
sage delivery might be reliable or subject to various forms of fail-
ure. For the sake of simplicity, we will suppose here that users’
clocks are synchronised – while this might seem like a strong as-
sumption, this only strengthens our impossibility result. We will,
though, allow for periods of network failure, during which the ad-
versary is able to control message delivery. In order to formalize
this, we will suppose that the duration is divided into intervals that
are labelled either synchronous or asynchronous (meaning that each

timeslot is either synchronous or asynchronous). We will suppose
that, during synchronous intervals, message delivery time is proba-
bilistically distributed for each pair of users. During asynchronous
intervals, we suppose that the adversary is able to interfere with
message delivery as they choose, i.e. the adversary can leave mes-
sages to be delivered in a probabilistic fashion as normal, can cause
undelivered messages to be delivered early, or can stop messages
being delivered at all for the duration of the asynchronous inter-
val. (Though we can always assume that a message broadcast by
a user is in effect delivered instantaneously to that user.) We then
distinguish two synchronicity settings. In the synchronous setting
it is assumed that there are no asynchronous intervals during the
duration, while in the partially synchronous setting there may be
undetermined asynchronous intervals.

2.4 The structure of the blockchain

Amongst all broadcast messages, there is a distinguished set re-
ferred to as blocks, and one block which is referred to as the gene-
sis block. Unless it is the genesis block, each block B has a unique
parent block Par(B), which must be uniquely specified within the
block message. Each block is produced by a single user, Miner(B),
but may contain other broadcast messages which have been pro-
duced by other users. No block can be broadcast by U := Miner(B)

at a point strictly prior to that at which its parent has been deliv-
ered to U. Par(B) is defined to be an ancestor of B, and all of the
ancestors of Par(B) are also defined to be ancestors of B. If B is not
the genesis block, then it must have the genesis block as an ances-
tor. At any point during the duration, the set of broadcast blocks
thus forms a tree structure. If M is a message state, then we shall
say that it is downward closed if it contains the parents of all blocks
in M . By a leaf of M , we shall mean a block in M which is not a
parent of any block inM . IfM is downward closed and contains a
single leaf, then we shall say thatM is a chain.

2.5 The resource pool

Protocols are run relative to a (predetermined or undetermined)
resource pool, which in the general case is a function R : U ×D ×

M → R≥0, where U is the set of public keys, D is the duration
andM is the set of all possiblemessage states. So R can be thought
of as specifying the resource balance of each user at each timeslot
in the duration, possibly relative to a given message state. For a
PoW protocol like Bitcoin, the resource balance of each public key
will be their (relevant) computational power at the given timeslot
(which is generally independent of any message state). For PoS pro-
tocols, such as Snow White and Algorand, however, the resource
balance will be fully determined by ‘on-chain’ information, i.e. in-
formation recorded in the message state M . Generally, a chain of
blocksC ⊆ M will first be selected. SoC might be the longest chain,
or the longest chain of blocks that have been approved by commit-
tee members. Then R(U, t ,M) will be some function of U’s stake as
recorded by the blocks in C .5

5The details here will depend on the specific protocol. It’s standard to insist that a
user has had stake in the currency recorded for a certain number of timeslots before
they are allowed to produce blocks, for example. So U’s resource balance might be
their stake according to C or some initial segment of C , or else 0 if U has not been
recorded as having non-zero stake for sufficient time.



Resource Pools and the CAP Theorem

By the total resource balance T , wemean the sum of the resource
balances of all public keys; this is the function T : D×M → R≥0
defined by T (t ,M) =

∑
U R(U, t ,M). It should be noted that the

resource pool is a variable, meaning that a given protocol may be
expected to be live and secure with respect to a range of resource
pools.

2.6 The sized and unsized settings

Just as we considered two synchronicity settings earlier, we also
consider two resource settings. The basic idea is that in the sized set-
ting, the total resource balance is information which is available to
the protocol (and the permitter, as described in Section 2.7), while
in the unsized setting it is not. The precise details are as follows.

The unsized setting. For the unsized setting, R (and hence T ) is
undetermined, with the only restrictions being:

(1) R will be a function fromU×D ×M to R≥0 satisfying the
requirement that, at all timeslots in the duration, the total
resource balance belongs to a fixed interval [I0, I1], where
I0 > 0 is sufficiently small and I1 > I0 is sufficiently large.6

(2) There may also be bounds placed on the resource balance
of the adversary.

We shall refer to the set of all resource pools satisfying these
restrictions as the possible resource pools, and in Section 3 we shall
define a protocol to be live if it is live for all possible resource pools.

The sized setting. For the sized setting, the total resource balance
T is a predetermined function T : D ×M → R≥0.

The basic idea is that PoS protocols will generally be best
modeled using the sized setting, while PoWprotocols are best mod-
eled using the unsized setting, since one does not know the total
resource balance (e.g., total hashrate in each timeslot) in advance.
There are some nuanced considerations, however. With a PoS pro-
tocol, for example, onemight not be able to predict accuratelywhat
percentage of the stake will actually come online and broadcast as
requested by the protocol. So there may be situations in which it
is appropriate to define the resource balance in terms of the online
or contributing stake, and where it should be recognised that only
partial information will be available concerning the total resource
balance. Equally, there may be contexts in which good bounds can
be given on the total resource balance over the duration for the
PoW case. The example of Bitcoin will be discussed further in Sec-
tion 6.

2.7 The permitter oracle

In order to specify how the resource pool is to be used, we shall
make use of the notion of a permitter oracle. This is the most crit-
ical part of the model, and is the part that blackboxes user selec-
tion, since it is the permitter oracle that grants permission to broad-
cast valid messages. The permitter oracle need not be implemented

6We consider resourcepools with range restricted to the fixed interval [I0, I1] because
it turns out to be an overly strong condition to require a protocol to be livewithout any
further conditions on the total resource balance, beyond the fact that it is a function
to R≥0 . We wish to be able to talk about Bitcoin as live in the unsized setting, for
example, but liveness will certainly fail if R is the constant 0 function, or if the total
resource balance decreases sufficiently quickly over time.

explicitly in the blockchain being modeled, and is a mathemati-
cal abstraction that allows for the discussion and comparison of
blockchains of very different types. It is designed to be as simple
as possible, subject to this goal.

As described in Section 2.2, we consider each user to be a com-
puting device with access to certain external oracles and function-
alities. At any given timeslot t ∈ D, a user’s state is entirely spec-
ified by the set of public keys they control, the protocol parame-
ters, their message state and the set of permissions they have been
given by the permitter oracle O. The protocol P = (I, O) is then
a pair, where the instruction set I is a set of deterministic and effi-
ciently computable instructions, which specifies precisely what ac-
tions honest users should carry out at each timeslot, as a function
of the timeslot and their state at that timeslot. The instructions of
the protocol are therefore a function of the timeslot, the keys con-
trolled by the user, the protocol parameters, their message state,
and the set of permissions they have been given by the permitter.

One of the external functionalities each user has is the ability to
broadcast valid messages. Amongst the conditions required for va-
lidity is that the public key responsible for the broadcast has been
given permission by the permitter oracle O, which is an oracle to
which users have access. We thus suppose that users can make ‘re-
quests’ to the permitter, of the form (U,M, t ′,A), where U is a public
key under their control,M is a possible downward closed message
state, t ′ is a timeslot, and where A is some (possibly empty) extra
data. Given a request of this form, the permitter may then respond
by giving them permission to broadcast certain messages. The re-
sponse of the permitter to a request (U,M, t ′,A)will be assumed to
be a probabilistic function of the protocol parameters, the actual
timeslot t , the previous requests made by U, the tuple (U,M, t ′,A),
and of the user’s resource level R(U, t ′,M).7

The conditions we have described above non-trivially restrict
what the permitter can do. For example, consider the unsized set-
ting, and suppose that the total resource pool (e.g., total hashrate)
cannot be deduced from the protocol parameters, t , previous re-
quests made by U, the tuple (U,M, t ′,A), and the user’s resource
level R(U, t ′,M). In this case, the framework requires that the re-
sponse of the permitter be independent of the total resource pool.
(Whereas in the sized setting, if the total resource pool can be
deduced from the broadcast state M , the permitter is no";"""date"",""2020-06-19T00:49:05Z""
""pdf:PDFVersion"",""1.4""
""pdf:docinfo:title"",""Resource Pools and the CAP Theorem""
""xmp:CreatorTool"",""LaTeX with acmart 2020/04/30 v1.71 Typesetting articles for the Association for Computing Machinery and hyperref 2016/06/24 v6.83q Hypertext links for LaTeX""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""-  Theory of computation; ""
""language"",""en""
""dc:format"",""application/pdf; version=1.4""
""pdf:docinfo:creator_tool"",""LaTeX with acmart 2020/04/30 v1.71 Typesetting articles for the Association for Computing Machinery and hyperref 2016/06/24 v6.83q Hypertext links for LaTeX""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""Resource Pools and the CAP Theorem""
""xmp:CreateDate"",""2020-06-18T20:49:05Z""
""modified"",""2020-06-19T00:49:05Z""
""cp:subject"",""-  Theory of computation; ""
""pdf:docinfo:subject"",""-  Theory of computation; ""
""pdf:hasMarkedContent"",""false""
""xmp:ModifyDate"",""2020-06-18T20:49:05Z""
""pdf:docinfo:creator"",""Andrew Lewis-Pye and Tim Roughgarden""
""meta:author"",""""
""meta:creation-date"",""2020-06-19T00:49:05Z""
""created"",""2020-06-19T00:49:05Z""
""xmp:About"",""uuid:39a3d69d-e9e3-11f5-0000-779b53376317""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-06-19T00:49:05Z""
""resourceName"",""2006.10698""
""Author"",""""
""producer"",""dvips + GPL Ghostscript GIT PRERELEASE 9.22""
""pdf:docinfo:producer"",""dvips + GPL Ghostscript GIT PRERELEASE 9.22""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""1"",""0"",""0"",""1"",""1"",""0"",""0"",""0""
""Keywords"",""blockchains, cryptocurrencies, distributed computing, CAP theorem""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2020-06-19T00:49:05Z""
""Last-Modified"",""2020-06-19T00:49:05Z""
""dcterms:modified"",""2020-06-19T00:49:05Z""
""title"",""Resource Pools and the CAP Theorem""
""xmpMM:DocumentID"",""uuid:39a3d69d-e9e3-11f5-0000-779b53376317""
""Last-Save-Date"",""2020-06-19T00:49:05Z""
""pdf:docinfo:keywords"",""blockchains, cryptocurrencies, distributed computing, CAP theorem""
""pdf:docinfo:modified"",""2020-06-19T00:49:05Z""
""meta:save-date"",""2020-06-19T00:49:05Z""
""Content-Length"",""281248""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:language"",""en""
""dc:subject"",""blockchains, cryptocurrencies, distributed computing, CAP theorem""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""12""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""4724"",""5973"",""5502"",""5830"",""5812"",""5763"",""5107"",""5436"",""5235"",""5626"",""6418"",""5413""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""meta:keyword"",""blockchains, cryptocurrencies, distributed computing, CAP theorem""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-06-19T00:49:05Z""
";https://scholar.google.ch/scholar?start=730&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098839-277;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;[PDF][PDF] On the Security of a Practical Constant-Size Ring Signature Scheme.;J Zhang, W Bai, Z Jiang ; IJ Network Security, 2020  isrc.ccs.asia.edu.tw;;"… However, the public verifiability and decentra- tion of blockchain transaction often do not provide

the … CP Rangan and D. Das, “Constant size ring signature without random oracle,” in Pro … and J.

Groth, “Ring signa- tures of sublinear size without random oracles,” in International …";Cité 1 fois;Les 3 versions;[PDF] asia.edu.tw;http://isrc.ccs.asia.edu.tw/~vdoi/upload/JID190002/2019/1816-3548-2019-00036.pdf;"
International Journal of Network Security, First Online July 8, 2019 (VDOI: 1816-3548-2019-00036) 1

On the Security of a Practical Constant-Size
Ring Signature Scheme

Jianhong Zhang1, Wenle Bai1,2, and Zhengtao Jiang1,3,4

(Corresponding author: Weile Bai)

School of Electronic and Information Engineering, North China University of Technology 1

Beijing 100144, China

(Email: bwl@ncut.edu.cn)

Guangxi Key Laboratory of Cryptography and Information Security2

Guangxi Key Lab of Multi-source Information Mining & Security3

School of Electronic and Information Engineering, China Communication University4

(Received June 15, 2018; Revised and Accepted Nov. 2, 2018; First Online July 8, 2019)

Abstract

Due to decentration and anonymity, ”bitcoin” cryptocur-
rency is widely paid attention. However, it only furnishes
pseudo-anonymity instead of authentic anonymity. As an
anonymous technique, ring signature is a candidate to
provide authentic anonymity in cryptocurrency [2]. How-
ever, in most of existing ring signatures, the length of
signature grows linearly with the size of the ring. To
construct constant-size signature, Qin et al. recently pro-
posed a practical constant-size ring signature scheme, and
claimed that their scheme can provide unforgeability and
anonymity which are two basic security requirments of
ring signature. Unfortunately, in this letter, we show
that their scheme is insecure against unforgeability attack
and anonymity attack. Finally, the two detail attacks are
given.

Keywords: Anonymity; Constant-Size Ring Signature;
Security Attack; Unforgeability

1 Introduction

As a decentralized distributed public ledger, blockchain
can furnish trust to operations between unrelated par-
ties, without requiring the collaboration of a trusted third
party. However, the public verifiability and decentra-
tion of blockchain transaction often do not provide the
strong security and privacy properties required by the
users. It can only provide pseudonymity instead of true
anonymity. In cryptocurrency, ring signature, stealth ad-
dress, and zero-knowledge proof are several cryptographic
techniques which can achieve privacy protection for trans-
action entities.

In particular, ring signature can often been used to
protect the identity anonymity of the user. To provide
real anonymity of transaction party, ring signature is ap-

plied to conceal the origin of a transaction in the ‘Monero’
cryptocurrency. For the perspective of the outsider, it can
not distinguish who is the actual sponsor of transaction.

In 2001, a novel anonymous signature conception [14]
was invented by Rivest, Shamir and Tauman, it was
named as ring signature since the structure of signa-
ture generation looks like a ring. Like group signature,
a user is allowed to produce a signature on behalf of the
whole group without the cooperation of the other users of
the group in ring signature. Anonymity and unforgeabil-
ity [1, 3, 7, 9, 11] are two basic properties of a secure ring
signature. Anonymity can guarantee the identity privacy
of the actual signer. Unforgeability can ensure the secu-
rity of signature algorithm since it can prevent an adver-
sary from forging a signature of new message m. These
properties make that ring signature has very important
application such as anonymous authentication in VANET.
However, most of the existing ring signature schemes ex-
ist a common flaw: “The length of ring signature is linear
with the size of the ring.”. Therefore, the larger the ring
size is, the longer the length of ring signature is.

To reduce the length of ring signature, Chandran et al.
presented the first sub-linear length ring signature [5] in
the standard model by utilizing private information re-
trieval technique. However, the security of their scheme
builds on the composite-order bilinear group which is in-
efficient. Later on, Ghadafi constructed a sub-linear size
ring signature in the prime-order setting [8].

There only exist two constant-size ring signature
schemes so far. One is Dodis et al.’s anonymous iden-
tification scheme [6] which is based on strong RSA prob-
lem, the other is Bose et al.’s ring signature [4] which
is based on two Diffie-Hellman assumption. Neverthe-
less, the two scheme is inefficient in practice since the
scheme in [6] makes use of the strong RSA based instan-
tiation which uses quite complex ÎŁ- protocols, and the
scheme in [4] is based on the q-strong Diffie- Hellman



International Journal of Network Security, First Online July 8, 2019 (VDOI: 1816-3548-2019-00036) 2

Table 1: Notions

Notions Implication

G ,GT : two groups with the same order q
e : A bilinear pairing map
PPT: Probability polynomial time
DLP: discrete logarithm problem
ACC : A dynamic accumulator
PPT: the probabilistic polynomial time
H0, H1: two cryptographic hash functions
(xi, PKi): public-private pair of user i

(q-SDH) assumption and the symmetric external Diffie
Hellman (SXDH) assumption via the Boneh- Boyen sig-
nature scheme. These techniques make the two schemes
less efficient in practice.

Our contributions: Recently, based on the discrete log-
arithm problem (for short, DLP) assumption, Qin et
al. proposed a practical constant-size ring signature
scheme [17]. Their construction is very simple and ef-
ficient. And they claimed that their scheme can pro-
vide security proof of unforgeability and anonymity.
Unfortunately, in this work, we find that their scheme
is insecure by analyzing the security of Qin et al.’s
scheme. Their scheme suffers from two security flaws.
One is that it exists universal forgeability, namely,
any one can forge a signature on arbitrary a mes-
sage; The other is that it can not achieve anonymous
prevention of real signer’s identity. Finally, the detail
attacks are given.

2 Preliminaries

In this work, we make use of bilinear map technique to
construct our scheme. To make our paper self-contained,
we will introduce some necessary cryptographic back-
ground which is related to bilinear map . And they are
also the basis of achieving the security of our proposed
scheme.

2.1 Bilinear Maps [10,15,16]

Let G1 and G2 be two multiplicative cyclic groups of the
same prime order q, g be a generator of group G1. A
bilinear map e : G1 × G1 → G2 is a map that for all
g, h ∈ G1 and a, b ∈R Z∗q , e(ga, hb) = e(g, h)ab. And
there exists a computable algorithm that can efficiently
compute e and e(g, g) 6= 1.

2.2 Accumulator

Definition 1. An accumulator is a tuple (Xχ, Fχ), where
χ ∈ N , N is the set of positive integers. Xχ is called the
value domain of the accumulator, and Fχ is a collection of
pairs of functions such that each (f, y) ∈ Fχ is defined as

f : Uf ×Xf → Uf for some Xχ ⊆ Xext
f , and y : Uf → Uy

is a bijective function where Uf and Uy denote the value
domain of functions f and y respectively. In addition, an
accumulator should satisfy the following properties.

1) Efficient generation. There exists an efficient algo-
rithm that takes as input a security parameter χ
and outputs a random element (f, y) ∈R Fχ, pos-
sibly together with some auxiliary information. And
in the following sections, we denote the algorithm by
ACC.Gen.

2) Quasi-commutativity. For every χ ∈ N, (f, y) ∈
Fχ, u ∈ Uf , x1, x2 ∈ Xχ : f(f(u, x1), x2) =
f(f(u, x2), x1). For any χ ∈ N , (f, y) ∈
Fχ and X = {x1, x2, · · · , xn} ⊂ Xχ, we call
y(f(f(u, x1), ¡ ¡ ¡ , xn)) the accumulated value of the
set X over u. Due to quasi-commutativity, the value
y(f(f(u, x1), ¡ ¡ ¡ , xn)) is independent of the order of
xi and is denoted by f(u,X).

3) Efficient Evaluation. For every (f, y) ∈ Fχ, u ∈
Uf and X ⊂ Xχ with polynomially-bound size:
y(f(u,X)) is computable in time polynomial in χ,
and we use ACC.Eval to represent the process of
computing the accumulated value. Also, there is a
witness w meaning that some variable x has been ac-
cumulated within v = f(u,X) iff f(w, x) = v, and
we use ACC.Wit to denote computing the witness w.

For simplicity, in the context, we adopt the accumu-
lator in [13]. Namely, the functions (f, y) is defined as
follows:

f : (β, x)→ β(x+ d), y : x→ x

where d ∈ Zq and β ∈ Zq, and y(x) = x is an identity
function. For this accumulator, we have f(β,X) = β(x1+
d) ¡ ¡ ¡ (xn + d) for a set X = {x1, x2, ¡ ¡ ¡ , xn}.

Obviously, all the above three properties in Definition 1
are satisfied.

2.3 Ring Signature Definition

A ring signature scheme is a tuple (Setup, Gen, Sign,
Verify) of PPT algorithms, where each of them means
generating a key pair, signing a message, and verifying the
signature for the message using the corresponding public
keys, respectively. Formally they are described as follows.

1) Setup(1l). It takes as input a security parameter l,
and outputs the system parameters params.

2) Gen(params, i). It inputs the identity information i
of a user and params, and outputs a public key PKi

and a private key SKi for each member i.

3) Sign(SK,m,R). The signer outputs a signature δ
on a message m with respect to a ring R using the
signing key SKi. We assume that the number of
public keys in the ring |R| > 2, and there is exactly
one public key in R corresponding to the signing key
SKi, and all the keys in R are generated by Gen.



International Journal of Network Security, First Online July 8, 2019 (VDOI: 1816-3548-2019-00036) 3

4) Verify(δ,m,R). The verifier can be anyone, including
the adversary, who verifies the signature on a mes-
sage m with respect to the ring R. If the verifier
accepts the signature, then the algorithm returns 1;
otherwise, returns 0.

3 Reviews of Qin et al.’s
Constant-Size Ring Signature

To achieve constant-length ring signature, Qin et al. pro-
posed a practical constant-size ring signature (for short,
PCRS) in [17]. The PCRS scheme consists of four algo-
rithms. We will briefly review their algorithms. Please
the interesting readers refer to [17] for the detail. For
convenience, the used notations in the following parts are
summarized in Table 1.

3.1 System Initialization

Taking a security parameter Îť as input, it outputs two
cyclic groups G1 and GT with the same prime order p,
and the discrete logarithm problem in G1 is hard. Let g
be a generator of group G1 and e : G1 × G1 → GT be a
bilinear pairing map. H0 and H1 are hash functions which
satisfy H0 : {0, 1}∗ → Zq and H1 : {0, 1}∗ → Zq, where q
is also a prime which satisfies q|p − 1. For each user i ∈
{1, ¡ ¡ ¡ , n}, it chooses xi as its private key and calculates
public key PKi = gxi . Let R denote the public key list of
n users,namely R = {PK1, ¡ ¡ ¡ , PKn}. Let AAC denote
an accumulator, refer to [17] for the detail. And then we
invoke AAC.Gen to produce f : (β, x)→ β(x+d) and the
corresponding Ppub = gd. Finally, the system parameter
Param = {G1,GT , e, p, q, g, f, Ppub, H0, H1}.

3.2 Signing

Let L = {H0(PKi)}ni=1 and L′ = {H0(PKi)}ni=1,i6=s.
Given a public key list R = {PK1, PK2, ¡ ¡ ¡ , PKn} and
system parameter Param, to produce a signature on mes-
sage m, a user s with public-private key pair (xs, PKs)
executes the following steps:

1) First, it calculates V = ACC.Eval(f, L) and W =
ACC.Wit(f, L′). Note that V = W (H0(PKs) + d).

2) Next, it uniformly samples r ∈ Zq to calculate U =
W + r and PU = gU .

3) Pick k1, k2 ∈ Zq at random to calculate
∏

=
e(g, PU )−k1e(Ppub, g)k2e(R′, g) where e(R′, g) =∏n
i=1,i6=s e(PKi, g).

4) And it calculates

c = H1(m||V ||Ppub||PU ||
∏
||R)

where R = {PK1, ¡ ¡ ¡ , PKn}.

5) Finally, it computes

s1 = k1 + cH0(PKs)

s2 = k2 + cr

s3 = crH0(PKs)− xs.

6) The resultant ring signature is δ =
(c, Ppub, PU , V, s1, s2, s3)

3.3 Verifying

Given a message m and its ring signature δ =
(c, Ppub, PU , V, s1, s2, s3) as well as public key list R, a
verifier can conduct the following procedure. First, it cal-
culates

q′ = e(g, PU )−s1e(Ppub, g)s2e(g, g)s3e(Ppub, PU )−c

¡e(g, gV )ce(R, g).

And then it checks whether c
?
= H1(m||V ||Ppub||PU || q′

||R). If it holds, then the signature is accepted; otherwise,
refuse it.

4 Security Analysis

Recently, based on the DLP problem, Qin et al. proposed
a PCRS scheme. Their scheme is more efficient than the
existing two constant size ring signature schemes in terms
of computational cost. At the same time, they also claim
that their scheme can achieve anonymity of the signer’s
identity and provide perfect zero knowledge for the ver-
ifier. By analyzing the security of their scheme, we find
that their scheme does not achieve anonymity. Given a
ring signature δ, a verifier can know which signer produce
the signature δ. Furthermore, given two ring signatures
δ and δ′, the verifier can know whether the two ring sig-
natures are from the same signer. The detail attacks are
given as blow.

4.1 Attack on Anonymity

Given a ring signature δ = (c, Ppub, PU , V, s1, s2, s3) on
message M , an attack A first computes

Π = e(g, PU )−s1e(Ppub, g)s2e(g, g)s3

·e(Ppub, PU )−ce(g, gV )ce(R, g)

c = H1(m||V ||Ppub||PU ||q′)

For j = 1 to n
{

1) It computes k̄1 = s1 − c ·H0(PKj);

2) And then it computes s2H0(PKj)−s3 = k2H0(PKj)
+ xs;

3) And it checks

e(Ppub, PKj) · (Π′·e(PKj ,g)
e(R,g) · e(g, PU )k̄1)H0(PKj)

?
= e(Ppub, g)s2H0(PKj)−s3 (1)



International Journal of Network Security, First Online July 8, 2019 (VDOI: 1816-3548-2019-00036) 4

4) If Equation (1) holds, it breaks it.

}

If j ≤ n then it outputs the identity index j of the real
signer. Otherwise, it outputs False.

We will show that our attack is valid since if the real
signer’s public key is PKs, we can obtain the following
relation

k1 = s1 − c ·H0(PKs) (2)

s2H0(PKs)− s3 = k2H0(PKs) + crH0(PKs)

−crH0(PKs) + xs

= k2H0(PKs) + xs (3)

Thus, we have

e(Ppub, g)s2H0(PKs)−s3 = e(Ppub, g)k2H0(PKs)+xs

m
e(Ppub, g)s2H0(PKs)−s3 = e(Ppub, g)k2H0(PKs)e(Ppub, PKs)

m

e(Ppub, g)s2H0(PKs)−s3 = (
Π ¡ e(g, PU )k1

e(R′, g)
)H0(PKs)

¡ e(Ppub, PKs)

m

e(Ppub, g)s2H0(PKs)−s3 = (
Π ¡ e(g, P k1U ¡ PKs)

e(R, g)
)H0(PKs)

e(Ppub, PKs).

It means that the real signer’s public key PK must
satisfy Equation (1). Thus our attack is valid.

The reason to produce such attack is that random num-
ber k1 in signing phase can be recovered by making use of
the hash value of m||V ||Ppub||Π||R and the actual signer’s
identity PKs. At the same time, s2 and s3 in the ring
signature exist a certain relevance. It makes that the re-
lation s2H0(PKs) − s3 = k2H0(PKs) + xs holds. Thus,
it reveals the relevant identity information of the actual
signer.

4.2 Attack on Unforgeability

For a ring signature, unforgeability should be a very im-
portant property, namely, it is difficulty to forge a ring
signature on a new message m∗. The property ensures
that ring signature can provide stronger unforgeability.
Unfortunately, by analyzing the security of their scheme,
we show that Qin et al.’s ring signature scheme also does
not satisfy unforgeability. The detail attack is given as
below.

1) Let m∗ be a forged message. L = {PK1, · · · , PKn}
is a public key list.

2) First, the attacker picks a random number ι ∈ Zq to
calculate P ∗U = gα.

3) Then, it chooses three random numbers r1, r2, r3 ∈
Z3
q to calculate

Π∗ = e(g, P ∗U )−r1e(Ppub, g)r2e(g, g)r3e(R, g)

where e(R, g) =
∏n
j=1 e(PKj , g).

4) Next , it randomly selects v ∈ Zq to set V ∗ = v, and
computes c∗ = H1(m∗||V ∗||Ppub||P ∗U ||Π∗||R), where
R =

∏n
j=1 PKj .

5) Subsequently, the attacker sets s∗1 = r1, s∗2 = r2+α·c∗
and s∗3 = r3 − V ∗ · c∗.

6) Finally, the resultant ring signature on message m∗

is δ∗ = (c∗, Ppub, P
∗
U , V

∗, s∗1, s
∗
2, s
∗
3).

In the following, we show that the above forged signa-
ture δ∗ is valid, that is to say, it can pass the verification
checking. Because

Π′ = e(g, P ∗U )−s
∗
1e(Ppub, g)s

∗
2e(g, g)s

∗
3e(Ppub, P

∗
U )−c

∗

e(g, gV
∗
)c
∗
e(R, g)

= e(g, gα)−r1e(Ppub, g)r2+αc∗e(g, g)r3−V
∗c∗

e(Ppub, g
α)−c

∗
e(g, gV

∗
)c
∗
e(R, g)

= e(g, gα)−r1e(Ppub, g)r2e(g, g)r3e(R, g)

c∗ = H1(m∗||V ∗||Ppub||P ∗U ||Π∗||R).

It means that our forged ring signature is valid since
it can pass the verification equation. Thus, Qin et al.’s
scheme is insecure. Any one can forge a ring signature on
arbitrary a mesasage. Thus, our attack is valid.

In the following, we analyze the reason to lead to
forgery attack. For the verification algorithm of the ring
signature, we can find that any one can calculate Π′ by
random choosing (s1, s2, s3, c, PU , V ). Essentially, Π′ is
irrelevant to the hash value c since Π′ can be computed
without c by choosing the appropriate (s1, s2, PU , V, s3).
Thus, the main reason to produce such attack is that the
generation of Π is independent of hash value c. c can not
restrain the generation of Π.

5 Conclusions

In this letter, we analyze the security of Qin et al.’s PCRS
scheme, and show that their scheme is insecure. It can
not achieve two security properties of ring signature: un-
forgeability and anonymity. In their scheme, any one
can forge a ring signature on arbitrary a message, and
given a ring signature δ, the verifier can know who is the
actual signer. Finally, our analysis is confirmed thought
two concrete attacks, the corresponding reasons to pro-
duce such attacks are given. It is our future work how to
design a secure and practical ring signature scheme with
constant-size.



International Journal of Network Security, First Online July 8, 2019 (VDOI: 1816-3548-2019-00036) 5

Acknowledgments

This research was was supported by Beijing Munici-
pal Natural Science Foundation (Nos.4162020), Guangxi
Key Laboratory of Cryptography and Information Se-
curity (No.GCIS201710) and Research Fund of Guangxi
Key Lab of Multi-source Information Mining & Security
(No.MIMS16-01).

References

[1] M. Bellare and G. Neven, “Multi-signatures in the
plain publickey model and a general forking lemma,”
in Proceedings of the 13th ACM Conference Com-
puter and Communications Security, pp. 390-399,
2006.

[2] E. Ben-Sasson, A. Chiesa, C. Garman, M. Green, I.
Miers, E. Tromer and M. Virza, “Zerocash: Decen-
tralized anonymous payments from bitcoin,” in Pro-
ceedings of IEEE Symposium on Security and Pri-
vacy (SP’14), pp. 459–474, May 2014.

[3] D. Bleichenbacher and U. Maurer, “On the efficiency
of one-time digital signatures,” in International Con-
ference on the Theory and Application of Cryp-
tology and Information Security (ASIACRYPT’96),
pp. 176–180, June 2008.

[4] P. Bose and C. P. Rangan and D. Das, “Constant
size ring signature without random oracle,” in Pro-
ceedings of the 20th Australasian Conference Infor-
mation Security and Privacy, pp. 230–247, July 2015.

[5] N. Chandran, A. Sahai and J. Groth, “Ring signa-
tures of sublinear size without random oracles,” in
International Colloquium on Automata, Languages,
and Programming (ICALP’07), pp. 423–434, vol.
4596, June 2007.

[6] Y. Dodis, A. Kiayias, A. Nicolosi, and V. Shoup,
“Anonymous identification in ad hoc groups,” in Pro-
ceedings International Conference Theory and Appli-
cation Cryptographic Techniques, pp. 609–626, 2004.

[7] R. Ehmet, L. Z. Deng, Y. Y. Zhang, and J. W. Zeng,
“Multi-proxy multi-signature without pairing from
certificateless cryptography,” International Journal
of Network Security, vol. 20, no. 3, pp. 403–413, 2018.

[8] E. M. Ghadafi, “Sub-linear blind ring signatures
without random oracles,” in Proceedings of the 14th
IMA International Conference Cryptography and
Coding (IMACC’13), pp. 304–323, Dec. 2013.

[9] S. Goldwasser, C. Rackoff and S. Micali, “The knowl-
edge complexity of interactive proof systems,” in
SIAM Journal on Computing, pp. 186–208, 1989.

[10] M. S. Hwang and I. C. Lin, Introduction to Informa-
tion and Network Security (6ed, in Chinese), Taiwan:
McGraw Hill, 2017.

[11] M. S. Hwang and C. Y. Liu, “Authenticated encryp-
tion schemes: Current status and key issues,” Inter-
national Journal of Network Security, vol. 1, no. 2,
pp. 61–73, 2005.

[12] M. S. Hwang, S. F. Tzeng, C. S. Tsai, “General-
ization of proxy signature based on elliptic curves”,

Computer Standards & Interfaces, vol. 26, no. 2, pp.
73–84, 2004.

[13] L. Nguyen, “Accumulators from bilinear pairings and
applications,” in The Cryptographers Track at the
RSA Conference (CT-RSA’05), pp. 275–292, 2005.

[14] R. Rivest, A. Shamir, and Y. Tauman, “How to leak
a secret,” in International Conference on the The-
ory and Application of Cryptology and Information
Security, pp. 552–565, vol. 2248, June 2001.

[15] J. H. Zhang and Q. C. Dong, “Efficient id-based pub-
lic auditing for the outsourced data in cloud storage,”
Information Sciences, vol. 343-344, no. 2, pp. 1–14,
2016.

[16] J. H. Zhang, P. Y. Li, and M. Xu, “On the security
of a mutual verifiable provable data auditing in pub-
lic cloud storage,” International Journal of Network
Security, vol. 19, no. 4, pp. 605–612, 2017.

[17] Y. L. Zhao, M. J. Qin and Z. J. Ma, “Practical
constant-size ring signature,” Journal of Computer
Science and Technology, vol. 33, no. 3, pp. 533-541,
2018.

Biography

Jianhong Zhang received his Ph.D. degrees in Cryptog-
raphy from Xidian University, Xian, Shanxi, in 2004 and
his M.S. degree in Computer Software from Guizhou Uni-
versity, Guiyang, Guizhou, in 2001. He was engaging in
postdoctoral research at Peking University from October
2005 to December 2007. He has been an Assistant Pro-
cessor of College of Sciences, North China University of
Technology, Beijing China, since 2001. His research inter-
ests include computer networks, cryptography, electronic
commerce security, computer software.

Wenle Baig received his Ph.D. degrees in Communi-
cation Networking from Beijing University of Posts and
Telecommunications; , Beijing, in 2006 and his M.S.
degree in Computer Software from Beijing University
of Posts and Telecommunications,Beijing in 2001. He
has been an Assistant Processor of College of Sciences,
North China University of Technology, Beijing China,
since 2001. His research interests include computer net-
works, cryptography, electronic commerce security, com-
puter software.

Zhengtao Jiang received his Ph.D. degrees in Cryp-
tography from Xidian University, Xian, Shanxi, in 2005
and his M.S. degree in School of Mathematics from Cen-
tral South University, Changsha, Hunan, in 2002. He
was engaging in postdoctoral research at Beihang Uni-
versity from October 2008 to December 20010. He has
been an Assistant Processor of School of Computer Sci-
ence, China Communication University, Beijing China,
since 2001. His research interests include computer net-
works, cryptography, electronic commerce security, com-
puter software.


";"""date"",""2019-12-13T05:00:47Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""1"",""17"",""10"",""0""
""pdf:PDFVersion"",""1.5""
""xmp:CreatorTool"",""TeX""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dcterms:created"",""2019-12-13T05:00:47Z""
""language"",""en""
""Last-Modified"",""2019-12-13T05:00:47Z""
""dcterms:modified"",""2019-12-13T05:00:47Z""
""dc:format"",""application/pdf; version=1.5""
""Last-Save-Date"",""2019-12-13T05:00:47Z""
""pdf:docinfo:creator_tool"",""TeX""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2019-12-13T05:00:47Z""
""meta:save-date"",""2019-12-13T05:00:47Z""
""pdf:encrypted"",""false""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is MiKTeX-pdfTeX 2.9.6668 (1.40.19)""
""modified"",""2019-12-13T05:00:47Z""
""Content-Length"",""271245""
""pdf:hasMarkedContent"",""false""
""Content-Type"",""application/pdf""
""PTEX.Fullbanner"",""This is MiKTeX-pdfTeX 2.9.6668 (1.40.19)""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""trapped"",""False""
""meta:creation-date"",""2019-12-13T05:00:47Z""
""created"",""2019-12-13T05:00:47Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""5""
""Creation-Date"",""2019-12-13T05:00:47Z""
""resourceName"",""1816-3548-2019-00036.pdf""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""3750"",""3816"",""3132"",""3241"",""4454""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""producer"",""MiKTeX pdfTeX-1.40.19""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""MiKTeX pdfTeX-1.40.19""
""pdf:docinfo:created"",""2019-12-13T05:00:47Z""
";https://scholar.google.ch/scholar?start=820&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098844-284;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;[PDF][PDF] Engineering Trust-aware Decentralized Applications with Distributed Ledgers;M Müller, N Ostern, SR Garzon, A Küpper ; researchgate.net;;"… Blockchain and distributed ledger technologies promise to solve trust issues in dApps … A blockchain

is a specific type of a distributed ledger, where transactions are grouped into blocks. While Bitcoin

was the first inception of the concept, many other technical solutions emerged …";Autres articles;Version HTML;[PDF] researchgate.net;https://www.researchgate.net/profile/Marcel_Mueller35/publication/347239262_Engineering_Trust-aware_Decentralized_Applications_with_Distributed_Ledgers/links/5fd8b993a6fdccdcb8caf7d3/Engineering-Trust-aware-Decentralized-Applications-with-Distributed-Ledgers.pdf;;;https://scholar.google.ch/scholar?start=830&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098791-162;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;EOSFuzzer: Fuzzing EOSIO Smart Contracts for Vulnerability Detection;Y Huang, B Jiang, WK Chan ; arXiv preprint arXiv:2007.14903, 2020  arxiv.org;;"… assets of end users or to enforce the negotiation and execution of agreements among peers

participating in the blockchain platform … The test oracles to detect forged transfer notification is

as follows: TransferCalled & !CheckRecipient The TransferCalled sub-oracle is to …";Autres articles;;[PDF] arxiv.org;https://arxiv.org/pdf/2007.14903;"
EOSFuzzer: Fuzzing EOSIO Smart Contracts for  
Vulnerability Detection*# 

Yuhe Huang 
School of Computer Science and 

Engineering 
Beihang University  

Beijing, China 
huangyuhe@buaa.edu.cn 

Bo Jiang†  
School of Computer Science 

and Engineering 
Beihang University  

Beijing, China 
jiangbo@buaa.edu.cn 

W.K. Chan 
Department of Computer Science 

City University of Hong Kong 
Hong Kong  

wkchan@cityu.edu.hk 

 

ABSTRACT 
EOSIO is one typical public blockchain platform. It is scalable in 
terms of transaction speeds and has a growing ecosystem supporting 
smart contracts and decentralized applications. However, the 
vulnerabilities within the EOSIO smart contracts have led to serious 
attacks, which caused serious financial loss to its end users. In this 
work, we systematically analyzed three typical EOSIO smart contract 
vulnerabilities and their related attacks. Then we presented 
EOSFuzzer, a general black-box fuzzing framework to detect 
vulnerabilities within EOSIO smart contracts. In particular, 
EOSFuzzer proposed effective attacking scenarios and test oracles 
for EOSIO smart contract fuzzing. Our fuzzing experiment on 3963 
EOSIO smart contracts shows that EOSFuzzer is both effective and 
efficient to detect EOSIO smart contract vulnerabilities with high 
accuracy.  

CCS CONCEPTS 
• Security and privacy → Software and application security; 
• Software and its engineering → Software testing and debugging; 

KEYWORDS 
Fuzzing, Smart contract, Vulnerability detection, Blockchain 

1 Introduction  
The blockchain technology is proposed as a value transfer 

network among peers with limited trust. Currently, the blockchain 
technology has evolved as a trust machine with which untrusted 
peers can cooperate with each other. Most of the current blockchain 
platforms supports smart contracts with which developers can build 
Decentralized Applications (DApps). Among them, the ecosystem of 
EOSIO platform is growing steadily. The types of DApps range from 
game, gambling, decentralized exchanges, tools, microblogging, etc.  

However, the vulnerabilities within EOSIO smart contracts have 
led to non-trivial financial loss to its end users. For example, the 
random number generation vulnerabilities within the EOSIO 
gambling games (including EOSBet, EOSCast, FFGame, EOSDice, 

EOSWin, etc.) have led to the loss of around 170K EOS tokens [28]. 
The Fake EOS Transfer vulnerability within the EOSCast smart 
contract has led to the loss of around 60K EOS tokens [26]. The 
Forged Transfer Notification vulnerability within EOSBet has led to 
the loss of 140K EOS tokens [27]. Based on the price of the EOS 
tokens (about $5 on average) at the time of the attack, the 
accumulated amount of loss by these three vulnerabilities alone was 
around 1.9 million worth of USD. Therefore, building effective 
vulnerability detection tools for EOSIO smart contracts is valuable. 
However, no existing fuzzing tool is available to detect EOSIO smart 
contract vulnerabilities. 

Different from the fuzzing of the Ethereum smart contracts, there 
are two main challenges with the fuzzing of EOSIO smart contracts. 
First, the EOSIO smart contracts adopt a unique EOS token transfer 
and notification mechanism through the eosio.token system smart 
contract, which can lead to distinctive EOSIO smart contracts 
vulnerabilities. To effectively trigger such vulnerabilities, we must 
design new attacker agents to trigger such vulnerabilities as well as 
new test oracles to precisely detect such vulnerabilities. Second, 
EOSIO smart contracts are executed by the WASM virtual machine, 
which supports different bytecode instruction sets from EVM. 
Furthermore, new types of vulnerabilities will continue to emerge 
with the development of EOSIO platform. Therefore, we must design 
the instrumentation scheme within the WASM VM in a general way 
to capture adequate information to support the detection of different 
types of EOSIO smart contract vulnerabilities. 

In this work, we proposed EOSFuzzer, a general blackbox fuzzing 
framework to detect vulnerabilities within EOSIO smart contracts. 
EOSFuzzer includes a fuzzing input generator, a fuzzing executor, an 
instrumented Wasm VM, and a vulnerability detection engine. The 
fuzzing input generator can generate inputs based on the ABIs of the 
smart contracts and realize specific attacking scenarios with the agent 
smart contracts. The fuzzing executor can efficiently execute the 
generated inputs against the smart contract under fuzzing. The 
instrumented Wasm VM will collect opcode execution, API 
invocation and other execution information valuable for general 
vulnerability detection. Finally, the vulnerability detection engine 
implements the proposed test oracles to report vulnerabilities. Our 
experiment on 3963 smart contracts showed that EOSFuzzer is 
effective to detect vulnerabilities within EOSIO smart contracts with 
high accuracy. In particular, we have successfully mounted attacks 
on smart contracts without source code using EOSFuzzer to make a 
bet without spending any EOS in our case study. 

* This research is supported in part by the National Key R&D Program of China 
under Grant 2019YFB2102400, NSFC (project no. 61772056),, the GRF of 
Research Grants Council (project no. 11214116, 11200015, and 11201114). 

#  EOSFuzzer is Open Sourced. https://github.com/gongbell/EOSFuzzer 
† All correspondence should be addressed to Bo Jiang. E-Mail: 

gongbell@gmail.com. 



                                                                                                                                                                             Yuhe Huang, Bo Jiang, and W.K. Chan 

 2 

The contributions of this work are three-fold. First, to the best of 
our knowledge, this work proposes the first fuzzing framework for 
detecting security vulnerabilities within EOSIO smart contracts. 
Second, the work proposes effective attacking scenarios and the 
corresponding test oracles that can trigger and detect typical 
vulnerabilities within EOSIO smart contracts with high accuracy. 
Third, we have systematically evaluated EOSFuzzer with a fuzzing 
experiment on real world EOSIO smart contracts, and EOSFuzzer 
has effectively identified more than 450 vulnerabilities within 
EOSIO smart contracts. 

The organization of the remaining sections is as follows. In 
Section 2, we will present the basics of WebAssembly (Wasm), 
EOSIO platform and EOSIO smart contracts. Then in Section 3, we 
will present 3 typical vulnerabilities of EOSIO smart contracts. In 
section 4, we will present the design of our EOSFuzzer framework in 
detail. After that, we will perform a comprehensive experimental 
study to evaluate the effectiveness and efficiency of EOSFuzzer in 
terms of vulnerability detection in Section 5. Then we present case 
studies about successful attacks on EOSIO smart contracts with 
EOSFuzzer in Section 6. Finally, we present related works, 
acknowledgements, and conclusions in Section 7, 8, and 9. 

2 Background  
In this section, we provide background knowledge on 

WebAssembly, EOSIO platform, and the EOSIO smart contracts. 

2.1 The WebAssembly 
WebAssembly (Wasm for short) [32] is a binary instruction 

format for a stack-based virtual machine. Wasm is designed as a 
portable target for compilation of high-level languages like 
C/C++/Rust, enabling deployment on the web for client and server 
applications. Wasm is designed to be fast, safe, and ease of 
debugging. And it can be easily embedded in both web and non-web 
execution environment. The EOSIO platform also adopts Wasm VM 
for executing its smart contract. 

2.2 EOSIO Platform and EOSIO Smart Contracts 
EOSIO platform is an open source public blockchain platform 

that focuses on the scalability of transaction speed. The EOS is not 
only the token of EOSIO platform, but it also represents the stake 
hold by its owners. The EOSIO platform adopts the Delegated Proof 
of Stake (DPoS) protocol for making consensus, which is much more 
scalable than the Proof of Work (PoW) consensus protocol used by 
other platforms such as Bitcoin. The computing resources is also 
distributed according to the EOS tokens owned by the users. 
Moreover, EOSIO platform has set an upper limit on the execution 
time of each transaction. Exceeding the resource limit will lead to the 
rollback of the transaction with exceptions.  

The features and characteristics of the EOSIO blockchain 
platform are designed to be flexible such that they can be modified to 
suit specific business requirement. Core blockchain features such as 
consensus, fee schedules, account creation and modification, token 
economics, etc., are implemented inside system smart contracts [30], 
which are deployed on the EOSIO blockchain platform. For example. 
The eosio.token system smart contract [24] defines the structures and 

actions allowing users to issue and transfer tokens on EOSIO based 
blockchains. The management of the EOS token is also performed by 
eosio.token system smart contract. 

Smart contracts are programs running on the blockchain platform 
to help manage the assets of end users or to enforce the negotiation 
and execution of agreements among peers participating in the 
blockchain platform. The smart contracts [29] deployed on EOSIO 
platform contain two parts: the WebAssembly bytecode and the 
Application Binary Interface (ABI). The smart contract source code 
is compiled into Wasm bytecode for execution within the Wasm VM. 
And the ABIs describe the public interfaces of the smart contract to 
interact with.  

Every EOSIO smart contract must provide an apply function as 
the entrance function to handle actions. The apply function will listen 
to all incoming actions and invoke the corresponding action handler 
functions accordingly. For example, the transfer function of a smart 
contract is usually used to handle transfer actions related to the 
contract [31]. 

The apply function uses the receiver, code, and action input 
parameters as filters to map the actions to the corresponding 
functions to handle [25]. The receiver is the account currently 
executing code. The code is the account that the action was originally 
sent to. And the action is the name of the action. It is important to 
understand the difference between code and receiver. To be specific, 
code is always the first receiver of the action, while receiver is the 
account currently executing the action. During the execution of a 
smart contract it may forward the action received to other account 
with the require_recipient() function. The code and action 
parameters of the apply function are also forwarded to the new 
contract. As a result, the receiver has changed to the newly notified 
contract, but the code stays the same. 

3 Security Bugs in EOSIO Smart Contracts 
In this section, we will briefly review the security bugs in EOSIO 

smart contracts. 

3.1 Fake EOS Transfer 
Table  1. The EOSBet Contract with Fake EOS Transfer 

Vulnerability 

1 … 
2 //The apply function 
3 void apply(uint64_t receiver, uint64_t code, uint64_t action){ 
4 auto self = receiver; 
5 if (code == self || code == N(eosio.token) || action == N(onerror)){ 
6 TYPE thiscontract (self); 
7 switch( action ) { 
8 EOSIO_API(TYPE, MEMBERS) 
9 }}} 

 
In the expected scenario, an EOSIO smart contract will only 

accept EOS transferred via the eosio.token system contract. If the 
contract under attack is vulnerable in that it does not check the code 
is eosio.token when the action is transfer within its apply function, an 
attacker may call the transfer function within the contract directly to 



EOSFuzzer: Fuzzing EOSIO Smart Contracts for Vulnerability Detection                                   

fake an EOS transfer. As a result, the vulnerable contract may 
wrongly consider that the attacker has transferred EOS to it. 

As shown in Table  1, within the apply function of the EOSBet 
contract, it only checks whether the code is the contract itself or 
eosio.token, but it does not check whether the action transfer is 
originally sent to the eosio.token system smart contract. As a result, 
an attacker contract may directly call the transfer function of the 
vulnerable contract to make a bet without spending any EOS. 

Table  2. Attacker Contract of the Fake EOS Transfer 
Vulnerability 

1 class hackcontract : public eosio::contract { 
2 … 
3 void hack(account_name self, eosio::asset quantity, std::string 

memo) {  
4 eosio::action( 
5 eosio::permission_level{_self, N(active)}, 
6 N(eosbet), 
7 N(transfer), 
8 std::make_tuple(self, N(eosbet), quantity, memo)).send(); 
9 }}; 
 
As shown in Table  2, a hacker can use the attacker contract to 

exploit the fake EOS transfer vulnerability. The attack is simple: it 
directly performs an inline call to the transfer function of EOSBet.   

Table  3. The Fix of the Fake EOS Transfer Vulnerability 

1 … 
2 //The apply function 
3 void apply(uint64_t receiver, uint64_t code, uint64_t action){ 
4 auto self = receiver; 
5 if( code == self || code == N(eosio.token) || action == N(onerror)){ 
6 if( action == N(transfer) ){ 
7 eosio_assert( code == N(eosio.token), ""Must transfer EOS""); 
8 } 
9 … 
 
As shown in Table  3, The recommended way to fix the 

vulnerability is to add a check in the apply function to ensure 
eosio.token was the original receiver of the transfer action (line 6 and 
7). In another word, when the action is transfer, the code must be 
eosio.token. 

3.2 Forged Transfer Notification 
When the transfer function of a contract is called, a smart contract 

may never check the destination (i.e., to) of the transfer.  However, 
this is vulnerable since the smart contract may just receive a 
notification of a transfer to another contract rather than to itself. 

During a normal EOS transfer, a receiver contract can choose to 
forward the transfer notification to other accounts through 
require_recipient (i.e. send a carbon copy of the transfer action). 
During a forged transfer notification attack [22], the attacker controls 
two accounts A and B. Then the attacker initializes the attack by 
transferring EOS from A to B through the system contract 
eosio.token. When the transfer is successful, both A and B will 
receive transfer notification. However, the contract deployed within 

account B can deliberately forwards the transfer notification to 
another contract (eosbetcasino in this example) with the 
require_recipient function in order to mislead it as shown in Table  4.  

Table  4. The Attacker Code to Send Forged Transfer 
Notification 

1 class contractB : public eosio::contract { 
2 public: 
3 contractB(account_name self) : eosio::contract(self) {} 
4 void transfer(uint64_t sender, uint64_t receiver) { 
5 require_recipient( N(eosbetcasino)); 
6 } 
7 }; 
 
As shown in Table  5, the eosbetcasino is vulnerable in that it 

does not check whether the destination (i.e., data.to) of EOS transfer 
is itself within its transfer function. Then, it may wrongly consider 
that it has received the EOS. As a result, it may wrongly credit the 
attacker account A, who in fact has sent nothing to eosbetcasino.  

Table  5. The Smart Contract eosbetcasino 

1 class eosbetcasino : public eosio::contract { 
2 public: 
3 void transfer(uint64_t sender, uint64_t receiver) { 
4 auto data = unpack_action_data<st_transfer>(); 
5 if (data.from == _self) //no check for data.to 
6 return; 
7 doSomething(); 
8 } 
9 }; 
 
As shown in Table  6, the fix of the forged transfer notification 

vulnerability is to simply check the destination of the transfer (line 5). 
If the destination of the EOS transfer is not the current contract, then 
the contract should directly ignore the transfer notification.  

Table  6. The Fix of the Forged Transfer Notification 
Vulnerability 

1 class eosbetcasino : public eosio::contract { 
2 public: 
3 void transfer(uint64_t sender, uint64_t receiver) { 
4 auto data = unpack_action_data<st_transfer>(); 
5 if (data.from == _self || data.to != _self) 
6 return; 
7 doSomething(); 
8 } 
9 }; 
 

3.3 Block Information Dependency 
Due to the lack of source of randomness, an EOSIO smart 

contract may rely on the block information such as 
tapos_block_prefix and tapos_block_num to generate random 
numbers, which may in turn determine the transfer of EOS or the 
winner of a lottery. However, the tapos_block_prefix and 
tapos_block_num are not reliable source of randomness, because they 



                                                                                                                                                                             Yuhe Huang, Bo Jiang, and W.K. Chan 

 4 

can be directly calculated from ref_block_num, which is the id of the 
last irreversible block by default.  

A gambling contract may use deferred action to determine the 
winner of a lottery. In such scenario, the reference block is the block 
just before the block making the bet. Therefore, when a smart 
contract uses tapos_block_prefix and tapos_block_num directly for 
random generation, the random number generated can be predicted.  

As shown in Table  7, the EOSDice smart contract [28] uses the 
tapos_block_prefix, tapos_block_num, current_time, account_name, 
game_id, pool_eos for random number generation. Unfortunately, it 
turns out all these variables can be determined before taking the bet. 
The account_name (name of the contract), game_id, and pool_eos 
(balance of the current contract) are trivial to get. The current_time 
refers to the timestamp when determine the winner of the lottery, 
which is the sum of the timestamp of making the bet and the delay 
time of the deferred action. As a result, all variables used for random 
number generation can be computed before making the bet. Finally, 
the attackers successfully calculated the random number and won 
2,545 EOS through the lottery, which was about $13,500. 

Table  7. EOSDice Contract with Block Info. Dependency 
Vulnerability 

1 uint8_t random(account_name name, uint64_t game_id){ 
2 … 
3 auto mixd = tapos_block_prefix() * tapos_block_num() + 

name + game_id - current_time() + pool_eos.amount; 
4 const char *mixedChar = reinterpret_cast<const char *>(&mixd); 
5 checksum256 result; 
6 sha256((char *)mixedChar, sizeof(mixedChar), &result); 
7 uint64_t random_num = *(uint64_t *)(&result.hash[0]) + 

*(uint64_t *)(&result.hash[8]) + *(uint64_t *)(&result.hash[16]) 
+ *(uint64_t *)(&result.hash[24]); 

8 return (uint8_t)(random_num % 100 + 1); 
9 } 
 

4 The Design of EOSFuzzer 
 

 

Fig. 1 The Workflow of EOSFuzzer 

In this section, we will first present an overview of the 
EOSFuzzer. Then we will discuss each component of the EOSFuzzer 
in detail. 

4.1 Overview of EOSFuzzer 
As shown in Fig. 1, the general workflow of EOSFuzzer mainly 

consists four steps. First, EOSFuzzer performs static analysis on the 
ABI (application binary interface) and the bytecode of the smart 
contract under test. The static analysis step outputs the data types of 
the arguments for each ABI interface as well as a candidate string 
pool for string data type and memo parameter. Second, the 
EOSFuzzer performs input generation to generate fuzzing inputs for 
each ABI interfaces based on the static analysis result. Meanwhile, 
the EOSFuzzer will also use deployed attacker agent contracts to 
generate attacking scenarios for triggering specific vulnerabilities. 
Third, the EOSFuzzer performs fuzzing on the smart contract under 
analysis within the testnet through the cleos tool [23]. Note that the 
testnet is an instrumented EOSIO platform with smart contracts 
deployed on it. Through instrumentation, the execution information 
of the smart contract under analysis will be recorded into the 
execution log. Fourth, the EOSFuzzer will perform vulnerability 
analysis based on our proposed test oracles. 

4.2 The Input Generator 
The input generator is responsible for generating the inputs for the 

ABI interfaces of EOSIO smart contracts as well as generating the 
attacking scenarios with the attacker agents. The final inputs for 
fuzzing are the interleaved ABI invocations and the attack scenarios. 

Generating Inputs for Different Data Types. The ABI 
interfaces for EOSIO smart contracts are in JSON format. Therefore, 
our tool parses the JSON file to extract the data type for each 
parameter. Then EOSFuzzer generates inputs for each data type and 
concatenates them to build the final input for invoking the ABI 
interfaces. 

The primitive numeric data types include the 8-, 16-, 32-, and 64-
bit integer and unsigned integer types as well as the 32- and 64-bit 
float-point types. For those data types, EOSFuzzer can randomly 
generate the maximum, or the minimum, or a random value within 
the input domain.  

For the Boolean data type, the input generation algorithm will 
random return true (1) or false (0) values. For the string data type, 
our input generation algorithm will first build a candidate pool of 
strings with static analysis. More specifically, EOSFuzzer will iterate 
the data areas defining the constant data and collect all constant 
strings in the area as a pool of candidate strings. Then the EOSFuzzer 
will randomly return a string from the candidate pool for a string 
parameter during input generation. 

For the asset data type, the algorithm will return random number 
of EOS tokens. For the symbol data type, the algorithm will only 
return the type EOS. In another word, we will mainly target at smart 
contract functions related to EOS token rather than other tokens. 

The name data type represents the name of smart contracts. 
Currently, our tool will return the name of the smart contract under 
test as input for the parameter of name data type. Similarly, for the 
public_key data type, we will return the address of the current smart 
contract under test. This is because many of the ABIs are only 



EOSFuzzer: Fuzzing EOSIO Smart Contracts for Vulnerability Detection                                   

authorized to work on the current smart contract under test. The use 
of the name and public_key of other relevant smart contracts may 
further require the analysis of the relationships among smart 
contracts within a project, which we left as a future work. 

For the array data type, our algorithm will iteratively generate 
inputs for its members of primitive data type. For struct data type, 
our algorithm will iteratively generate inputs for each of its members. 
If its member is of struct data type, the algorithm will also proceed 
recursively until primitive types are encountered. 

For each smart contract, the input generation algorithm will 
generate one test suite containing a set of test cases. Each test case is 
a combination of ABI function invocations and attacking interactions 
(from the agent contracts) to the smart contract under fuzzing. The 
number of function invocations and attacking interactions within a 
test case is of random length and can be configured within 
EOSFuzzer.  

Generating Seeds for the Memo Parameter. The memo 
argument is an argument used in the transfer function. Based on our 
analysis, we found that the sender and the receiver may use a memo 
argument of string type to confirm and guard a transfer action. To 
generate seeds for the memo parameter, our algorithm will perform 
static analysis on the smart contract under test to extract the strings 
used in the transfer function.  

Table  8. The Static Analysis to Extract Candidate Memo Strings 

1 vector<string> getMemoStrings(vector wast, string param) { 
2 vector<string> memos 
3 set<string> offsets 
4 for func in all functions with signature like param 
5 for instruction contains “""i32.const""” { 
6 extract offset from instruction 
7 offsets.insert(offset) 
8 }  
9 for offset in offsets  
10 foreach instruction in data area contains offset { 
11 extract string from instruction 
12 memos.insert(string) 
13 } 
14 return memos 
15 } 
 
As shown in Table  8, the function getMemoStrings extracts the 

candidate strings that may be used to compare with the memo 
argument within the transfer function. The wast parameter is the 
WebAssembly text format of the smart contract under fuzzing. 
EOSFuzzer uses the wasm2wat tool [33] to translate wasm bytecode 
to wast representation. The param is a string representing the data 
types of the return value and parameters of the transfer function (i.e., 
the string “(param i32 i64 i64 i32 i32)”). At line 4, the algorithm 
iterates all functions with signatures like the transfer function (i.e., 
having the same type of parameters and return value). Within each 
function, it iterates each instruction containing the use of constant 
values in the code (i.e., containing i32.const), and it extracts the 
offset of the corresponding constant variable in such functions (line 4 
to 7). Finally, the algorithm iterates the data areas defining the 

constant data, locates the string corresponding to the offset (if it is of 
type string), and saves it in the vector memos as candidates for the 
memo parameter (line 9 to 12). 

When there are functions with the same signature as the transfer 
function or when there are other constant strings used in the transfer 
function which are not related with memo parameter, the analysis 
may become imprecise. However, our analysis with the open source 
contracts showed that the memos vector only contains small number 
of irrelevant candidates, which is still effective for fuzzing. 

The Design of Attacker Agents for Faked EOS Transfer. A 
safely written smart contract will check the code is eosio.token when 
the action is transfer within the apply function. Therefore, to trigger 
the fake EOS transfer vulnerability, we used an attacker contract 
called fakeTransferAgent to invoke the transfer function of the smart 
contract under fuzzing with code different from eosio.token. The 
invocation involves two scenarios and both are performed within the 
transfer function of the fakeTransferAgent. One is to invoke the 
transfer function with code equal to the receiver (i.e. the contract 
under fuzzing) while the other is to invoke the transfer function with 
code different from both the receiver and eosio.token. As a result, the 
agent contract will perform two possible attacks on the smart contract 
under fuzzing.  

One attack is to perform an inline function call to the transfer 
function of the smart contract under fuzzing. In another word, our 
tool deliberately avoids using the eosio.token contract to perform the 
transfer action. In this attack, the code is equal to receiver (i.e., the 
smart contract under fuzzing).  

The other kind of attack is to first use the cleos tool to call the 
transfer function of the fakeTransferAgent smart contract. Then, the 
fakeTransferAgent smart contract will forward the action to the smart 
contract under fuzzing through require_recipient. In this way, the 
smart contract under fuzzing will receive an transfer action with code 
equal to fakeTransferAgent, which is different from both eosio.token 
and itself (the receiver). 

Finally, if the transfer function of smart contract under fuzzing is 
successfully triggered by the attack, it will be considered vulnerable. 

The Design of the Attacker Agents for Forged Transfer 
Notification. To effectively trigger the forged transfer notification 
vulnerability, we designed a notifier agent contract to mount the 
attack. To initiate the attack, EOSFuzzer will first send some EOS to 
the notifier contract through the eosio.token smart contract.  The 
notifier contract in turn will forward the transfer action to the smart 
contract under fuzzing through the require_recipient() function. 
Finally, the vulnerability detection module of EOSFuzzer will 
analyze the behavior of the smart contract under fuzzing on receiving 
the notification to determine whether it is vulnerable or not. 

4.3 The Fuzzing Execution Engine 
Having generated the inputs for fuzzing the smart contracts, the 

fuzzing execution engine is responsible for executing the inputs 
against the EOSIO smart contract. The fuzzing execution engine 
makes use of the cleos tool to interact with the smart contract. Within 
our design, the EOSFuzzer creates a pipe to communicate with the 
cleos process. It invokes the push action command of cleos tool to 



                                                                                                                                                                             Yuhe Huang, Bo Jiang, and W.K. Chan 

 6 

interact with the ABI interfaces of the smart contract under fuzzing 
or with the agent contracts.  

For each smart contract, the input generation algorithm will 
generate a set of test cases. Each test case is a combination of ABI 
function invocations and attacking interactions (from the agent 
contracts) to the smart contract under fuzzing. When a test case 
finishes execution, EOSFuzzer will reset the testnet. On the one hand, 
resetting the testnet will lead to extra time cost. On the other hand, 
resetting the testnet will make the debugging easier since the 
execution trace is shorter. In this way, we want to make a tradeoff 
between fuzzing efficiency and debuggability after fuzzing.  

When the execution of test cases ends, EOSFuzzer will start 
reading the instrumentation logs generated during execution and 
invoke the vulnerability detection module to analyze and report the 
vulnerability detection results.  

4.4 Wasm VM Instrumentation 
To support the extensible analysis of vulnerabilities, we must 

carefully instrument the Wasm VM to collect information about 
opcodes and operands invoked during execution. This includes those 
control-flow related opcode, the unary opcode, the binary opcode, 
and their operands. Whenever an opcode is executed, the 
instrumentation will generate a line recording the opcode, the 
operands, and the results (if there is any) within the opcode log file. 
Although not all information within the opcode log file are used for 
detecting the vulnerabilities studied in this work, the instrumentation 
log is design to be general for the analysis of new vulnerabilities in 
the future.  

In particular, the CallIndirect opcode is instrumented because 
each invocation of the execute_action within the apply function will 
lead to the execution of CallIndirect opcode. Therefore, this opcode 
implies the invocation of an ABI function within the smart contract 
under test. Furthermore, we have also instrumented the Wasm API 
interface implementation code to collect information on whether the 
block information is queried during smart contract execution. To be 
specific, we have instrumented the tapos_block_num() and the 
tapos_block_prefix() functions.  

Finally, we have also instrumented the transfer function of 
eosio.token system smart contract, which is used in EOSIO platform 
for EOS transfer. Instrumenting this function will help us understand 
whether EOS transfer actually happened during smart contract 
execution. 

4.5 Test Oracles for Vulnerability Detection 
In this section, we present the test oracles for vulnerability 

detection. 
Fake EOS Transfer. To trigger the fake EOS transfer 

vulnerability, we used an attacker contract called fakeTransferAgent 
to perform two possible actions within its own transfer function. One 
is to directly perform an inline function call to the transfer function 
of the smart contract under fuzzing while the other is to forward a 
transfer action to the smart contract under fuzzing with 
require_recipient. 

The test oracle to detect the fake EOS transfer vulnerability under 
the designed attacking scenarios is:  

CanReceiveEOS & TransferCalled 
The CanReceiveEOS test oracle is to check whether the smart 

contract can receive EOS rather than other tokens. During our 
implementation, we send some EOS to the smart contract under 
fuzzing through the eosio.token contract, and then we check whether 
the transfer function of the smart contract is invoked. Because at least 
two member functions will be called during the attacking scenario 
(i.e., the transfer function of eosio.token and the transfer function of 
the smart contract under fuzzing), EOSFuzzer will check whether the 
CallIndirect opcode has been executed at least 2 times within its 
implementation accordingly. 

The TransferCalled test oracle is to check whether the transfer 
function of the smart contract under fuzzing can be successfully 
triggered by the fakeTransferAgent. Similar to CanReceiveEOS, 
EOSFuzzer checks whether the CallIndirec";"""date"",""2020-08-05T15:00:00Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.3""
""pdf:docinfo:title"",""Microsoft Word - EOSFuzzer-2.1-arxiv.docx""
""xmp:CreatorTool"",""Word""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dcterms:created"",""2020-08-05T15:00:00Z""
""language"",""en""
""Last-Modified"",""2020-08-05T15:00:00Z""
""dcterms:modified"",""2020-08-05T15:00:00Z""
""dc:format"",""application/pdf; version=1.3""
""title"",""Microsoft Word - EOSFuzzer-2.1-arxiv.docx""
""Last-Save-Date"",""2020-08-05T15:00:00Z""
""pdf:docinfo:creator_tool"",""Word""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2020-08-05T15:00:00Z""
""meta:save-date"",""2020-08-05T15:00:00Z""
""pdf:encrypted"",""false""
""dc:title"",""Microsoft Word - EOSFuzzer-2.1-arxiv.docx""
""modified"",""2020-08-05T15:00:00Z""
""Content-Length"",""672693""
""pdf:hasMarkedContent"",""false""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""meta:creation-date"",""2020-08-05T15:00:00Z""
""created"",""2020-08-05T15:00:00Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""12""
""Creation-Date"",""2020-08-05T15:00:00Z""
""resourceName"",""2007.14903""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""5375"",""6066"",""4702"",""5351"",""6336"",""6753"",""6087"",""5164"",""5576"",""6634"",""6977"",""3520""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""producer"",""macOS 版本10.15.5（版号19F101） Quartz PDFContext""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""macOS 版本10.15.5（版号19F101） Quartz PDFContext""
""pdf:docinfo:created"",""2020-08-05T15:00:00Z""
";https://scholar.google.ch/scholar?start=710&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098853-308;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;[PDF][PDF] THE BLOCKHAIN TECHNOLOGY AND ITS APPLICATIONS IN THE FINANCIAL SECTOR;A Krause ;2020 eresearch.siam.edu;;"… (Nakamoto, 2008). Bitcoin and other cryptocurrency have been viewed with suspicion from the

majority of … if part of the function. This event can be either a triggered transaction or information

received. External events (outside the blockchain) can also be included with ""Oracles"" …";;;[PDF] siam.edu;https://e-research.siam.edu/wp-content/uploads/2021/02/MBA-2020-IS-The-blockchain-technology-and-its-applications-in-the-financial-sector.pdf;"
 
 

THE BLOCKHAIN TECHNOLOGY AND ITS APPLICATIONS IN THE FINANCIAL 
SECTOR 

 

 
 
 
 
 
 

Arnold Krause 
ID: 6217190071 

 
 

 
 

 
 

 
SUBMITTED AS A PARTIAL FULFILLMENT REQUIRED FOR 

THE MASTER OF BUSINESS ADMINISTRATION DEGREE 
INTERNATIONAL PROGRAM, GRADUATE SCHOOL OF BUSINESS, 

SIAM UNIVERSITY, BANGKOK, THAILAND 
 

2020 







ACKNOWLEDGEMENT 

 
In this section, I would like to express my gratitude to Dr. Tanakorn Limsarun, advisor and Dr. Dr. 
Jomphong Mongkhonvanit, Dean, Graduate School of Business, Siam University, Bangkok, 
Thailand for them thoughtful and caring supervision by menas of his educational excellence. I am 
most grateful to them especially for them deep understanding of the Independent Study and his 
good commumication skills. 
 
 
      Name Arnold Krause      
         Date 17.08.2020 

 
 
 
 
 
 
 
 
 
 
 
 

 

 



CONTENTS 
 

ABSTACT          A 
ACKNOWLEDGEMENT        C 
CONTENTS          D 
LIST OF FIGURES         E 
CHAPTER 
1 Introduction 
 1.1 Research Background 
 1.2 Research Problem 
 1.3 Research Objective 
 1.4 Research Scope 
 1.5 Research Significance 
2. Literature Review 
 2.1 Distributed Ledger Technology (DLT) 
 2.2 Blockchain  
 2.3 Smart Contracts 
 2.4 Applications in the financial sector 
3. Findings 
4. Conclusion  

 

 

 

 



LIST OF FIGURES 
 
Figure 
Figure 1: Centralized vs Distributed ledger  
Figure 2: Chained blocks  
Figure 3: Model used as a guideline for this research 

 

 
 

 
 

  



1.  Introduction 

1.1. Research Background 

After the rapid price increase and hype of Bitcoin in 2017 it´s well-known by most people. 

Bitcoin is a digital method of payment, also known as cryptocurrency. Bitcoin´s all-time high of 

19,783.06 USD was reached on 17 December 2017.  So far, this value has not been reached again. 

Currently the price is around 9,000 USD. Beside bitcoin there are now over a thousand other 

cryptocurrencies with similar or different concepts. (CoinMarketCap, 2020).  

But even more interesting is the technology behind these cryptocurrencies, which called 

blockchain. This technology was first described of Satoshi Nakamoto 2008 in his White Paper 

„Bitcoin: A Peer-to-Peer Electronic Cash System“. The word blockchain was only paraphrased in 

his work and developed much later with increasing popularity of Bitcoin´s functionality. With 

Bitcoin it has been possible for the first time to make digital transfers, which are carried out by a 

decentral distributed peer-to-peer network and confirmed by a special consensus mechanism. All 

is managed without the need for a trusted central authority, that legitimizes the transactions. At that 

time, this was a unique development compared to the other payment methods in the financial sector. 

(Nakamoto, 2008). 

Bitcoin and other cryptocurrency have been viewed with suspicion from the majority of 

the financial sector since the start. In contrast, interest in blockchain technology in the financial 

sector has increased continuously since 2013 (Cognizant, 2016). This can be demonstrated through 

the strong annual worldwide increase of venture-capital in FinTechs. A study published in March 

2016 by KPMG and CB Insights confirms this statement. In 2015, a new record of 474 million US 

Dollar has been reached after 299 million US Dollar (2014), 80 million US Dollar (2013) and 1 

million US Dollar in 2012. Together, this results in a total investment sum of over one billion US 

dollars (CB Insights & KPMG, 2016). 

1



The foundation of the R3 consortium also shows the great interest in blockchain 

technology. This association is concerned with the development of a blockchain platform for 

various application scenarios. These include a platform for the capital market or the trade financing. 

Members of the R3 consortium include global players from the finance sector such as the BNB or 

Deutsche Bank. Currently, a total of 300 partners from all over the world are involved in this project 

(R3, 2020). In summary, it can be seen that there is an increasing interest in the market for 

blockchain technology but not for bitcoin itself. Developments in this area should therefore be 

closely monitored by all competitors in the financial sector. In order not to lose ground in the highly 

competitive environment. 

1.2. Research Problem 

The development in the FinTech industry is running rapidly. This is shown by a study 

published by comdirect. There are more and more new FinTech start-ups. In Germany 127 new 

start-ups in this sector were only founded in 2018. The year before there were 118 newly founded 

companies. Looking at the total market, there are already almost 900 start-ups in the FinTech sector 

(as of September 2019).  

If you look more detail at the areas these start-ups are involved in, blockchain ranks among 

the top 5 and has a growth rate of 111% since 2017. The amount of venture capital invested is also 

increasing year by year. One third of the total global venture capital is invested in the financial 

sector. In 2019, more has already been invested than in 2018. By September 2019, a total of EUR 

1.289 billion have been invested. This trend can also be observed in other countries (comdirect, 

2019).  

The problem that exists is to get an overview of what exactly these FinTech start-ups are 

doing in the blockchain area. How can they be divided into more detailed categories and what is 

the state of development in 2020? It is also important to find out why the interest in this area is 

increasing so much. What benefits do companies in the financial sector expect from their 

2



developments in this area? Due to the rapid progress, a few year-old publications can no longer 

reflect the current state of the market and provide an outdated picture. 

1.3. Research Objective 

The main objective of this research is to identify the useful applications of blockchain for 

the finance sector. This research first intends an overview how blockchain and the underlying 

Distributed Ledger Technology work. Also, an overview on the blockchain based Smart Contracts 

is given. The possible advantages of implementing the various technological for the financial sector 

are described. This paper uses a documentary research to examine the relationships and 

implications between the keywords. 

 

Research questions: 

• What is blockchain and it´s underlying Distributed Ledger Technology?  

• What are blockchain based Smart Contracts and how they operate? 

• Which are the advantages of an implementation? 

• What are useful applications for the finance sector?  

1.4. Research Scope 

The target group of this paper is primarily the people in the financial sector, who want to 

get an overview of the possible effects on the sector and the use cases from the blockchain 

technology. The digital transformation, which also includes the blockchain technology in the 

finance affects a large number of employees. Therefore, progress should always be closely 

monitored in order to take necessary steps in time. 

 

 

3



1.5. Research Significance  

The expected scientific finding is that there are a lot of potential applications in the finance 

sector of the blockchain technology. They can make a significant contribution to reducing cost, 

processing times and improving quality in the finance sector. In addition, the focus will be also on 

improving the customer experience in order to retain customers in the long term through customer 

satisfaction. The challenge for the finance sector will be to implement the applications from other 

companies to their own digital landscape or to modify existing solutions in order to be prepared for 

the future. 
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

4



2. Literature Review 

2.1. Distributed Ledger Technology (DLT) 

The term Distributed Ledger or Distributed Ledger Technology (DLT) is a frequently used 

way to describe the blockchain in the financial sector. The term DLT is sometimes even equated 

with the blockchain. This is actually incorrect (Bashir, 2018). This chapter first explains what 

exactly a DLT is and then uses the term to explain the blockchain in the following chapter. In 

practice, there is no standard definition for blockchain and DLT due to the topicality of the subject.  

The DLT is practically the underlying technology of the Blockchain. A distributed ledger 

is, as the name suggests, essentially a database that is shared and distributed among all participants 

through a network. Each participant has its own copy of the database, which is identical to all other 

participants. To ensure that each participant has the same version of the database, the update is 

carried out according to specific rules. All changes in the ledger are saved to all users' copies of the 

DLT in a few moments. It is therefore practically an identical digital version of a database stored 

in a decentralized system or network. What exactly is stored in this database can be very different. 

In the case of Bitcoin, for example, it is the transactions of the participants (UK Government, 2016). 

To understand the difference between a centralized and a decentralized database or ledger, 

we will now compare them.  The figure 1 shows a direct comparison. 

 

Figure 1: Centralized vs Distributed ledger (Yaqoob, 2019) 

5



In the central system, it is clearly visible how a dependency on a single central instance 

exists. Countless examples of this can be found in daily use. One of these examples is making a 

simply bank transfer. Person A wants to transfer money to person B. Both persons are registered at 

the same bank. Although nowadays only a few digits on the respective accounts are changed 

digitally, here the bank always acts as the central authority for this transaction. The bank is 

responsible for executing transaction and managing the bank accounts of their clients. This means 

that a trustworthy authority is always needed as an intermediary to carry out the transfer from 

person A to person B (Drescher, 2017). 

In the decentralised system, it is clear that there is no difference between the participants. 

All participants are practically connected to each other without a central instance as mediator. Each 

participant has the same rights in the network. This makes it possible to exchange data without a 

middleman. How to manage a distributed ledger successful without the existence of a trustworthy 

instance is part of the blockchain (Drescher, 2017).  

The distributed ledger is one part of the content from a “block”. Several entries can be part 

of one block. New blocks are added individually and one after the other after a fixed time interval. 

This time interval depending on the blockchain application. Bitcoin has for example an interval of 

around 10 minutes for each block. The new blocks are chained to the old blocks using a 

cryptographic procedure. This is called a ""blockchain"" (Hosp, 2019).  

 There are a number of elements from the DLT that can be useful for the financial sector. 

These include the execution of transactions without an intermediary, having an always up-to-date 

and identical version of the database for all participants. Due to the distribution of the database 

backups are unnecessary. 

  

6



2.2. Blockchain 

There are several reasons to explain the function of the blockchain by using a Bitcoin 

transaction. Firstly, most people are familiar with Bitcoin. Secondly, as already mentioned, Bitcoin 

is one of the first blockchain applications. The use of the approach based on a Bitcoin transaction 

also offers a practical and therefore clear explanation.  

To sending Bitcoins from sender A to receiver B. Sender A triggers the transaction with B 

as receiver. The transaction is then entered in a block. The block where all transactions are stored 

is distributed to the participants in the network. The participants confirm the transaction and the 

block is added to the blockchain. The transaction is completed and B received his money. The 

wallet is a requirement for triggering a transaction. A wallet is practically a digital purse. It is used 

to send and receive Bitcoins. It is usually based on a graphical user interface. This makes sending 

and managing Bitcoins relatively user-friendly (Berentsen & Schär, 2017).  

There are many different websites or apps to create a wallet. On the website 

(https://coin.space), for example, you can create your own Bitcoin wallet in a few minutes.  While 

creating the wallet the user gets a key with which he gets access to his wallet and he also gets an 

address to receive Bitcoins. 

 

Hash function 

To understand how a blockchain works, the meaning of ""hash functions"" and ""hash values"" 

must be explained, because they are important for the security of blockchains (Berentsen & Schär, 

2017).  

A hash value is the result calculated by a hash function. The hash function is practically a 

small and simple computer program. The input can be any data or information. The output is the 

result of the function. It is always an alphanumeric with a fixed length. The special feature of a 

hash value is that the same output always occurs with the same input. So, the equality of huge data 

7



sets can be compared very quickly. It is also impossible to calculate the input from the output 

(Drescher, 2017).   

For each transaction an individual hash value is calculated. These hash values were but 

together and build a single hash value. This hash value is called ""Merkle Root"" and is stored in the 

block. If this hash value changes, it can be concluded quick that at least one or more of the 

transactions have been manipulated (Berentsen & Schär, 2017).  

Hash finding and chaining of the block 

The hash finding with Bitcoin can be compared to a puzzle made up of several parts. Only 

when all parts fit together, the puzzle is solved. The solution follows on the basis of trial and error. 

All parts form the hash values result in a single hash, which is called a ""block hash"". This block 

hash is formed simplified from the following parts: 

• Hash of the previous block  

• Hash of all transactions (Merkle Root) 

• Nonce 

The nonce is a freely selectable number. In contrast to the other parts, it can be changed. The 

nonce is therefore the only variable data that can influence the value of the block hash. From the 

entire given data, a single hash value is formed as output, which is located in the following block. 

The previous block hash results from the solution of the puzzle of the last block. For this hash value 

there are specifications for the number of consecutive zeros at the beginning of the hash value. This 

allows the difficulty to be adjusted. The so-called ""miners"" are responsible for solving these tasks. 

They try to find the correct nonce by testing individual numbers in order to obtain the required hash 

value. Computing power is necessary for this task. The higher the power the higher the chance to 

find the right solution. If a miner now finds a solution for the nonce, he communicates his result to 

the other participants. In contrast checking the nonce is possible in a few seconds. If the other 

participants confirm the result, the block will be added to the blockchain. This means that the 

8



transactions are also considered confirmed. For finding the right nonce the miner receives a reward 

in the form of Bitcoins. The miners are the ones who make it possible to confirm the transactions 

without an intermediary. There are also other concepts possible to confirm entries or transactions. 

(Drescher, 2017; Nakamoto, 2008). 

 

 
Figure 2: Chained blocks (Wander, 2013) 

If you change for example one or more transactions in block 10, a new value for the block 

hash is automatically generated. However, this hash value no longer meets the specifications for 

the number of zeros. A new nonce would have to be found for block 10 to get the right number of 

zeroes in the hash again. This creates a new block hash that does not match the stored block hash 

in the following block. This in turn affects the block hash of all subsequent blocks. Therefore, all 

consecutive blocks must be recreated. For example, these would be blocks 11 and 12. To recalculate 

all these blocks requires so much computing power that this is practically impossible. This security 

against manipulation is an additional reason, which makes blockchain so interesting for the 

financial sector (Berentsen & Schär, 2017).   

2.3. Smart Contracts 

This chapter will explain how the term ""Smart Contracts"" is currently understood in the 

context of blockchain technology. Smart Contracts are an extremely useful part of blockchains and 

9



have high potential for the finance sector. A scientifically standard definition of the term does not 

exist at this time. Therefore, different definitions are used for this work.  

In the Gabler Wirtschaftslexikon the following definition can be found for this topic: 

“A Smart Contract is a software-based contract in which a wide variety of contract 

conditions can be stored. During the course of the contract, certain linked actions (e.g., 

disbursements) can be executed automatically if there is a corresponding trigger (e.g., 

fulfillment of contract conditions)”. (Mitschele, 2018) 

The Technologie Stiftung Berlin defines a Smart Contract in this way: 

“Smart Contracts are automatically executable programs that build on the block chain and 

map predefined transaction rules in the program code. A transaction that runs via a Smart 

Contract is automatically executed if all parties involved fulfill the previously defined 

conditions. This eliminates the need for a central, intermediate instance, especially if the 

parties involved do not know and therefore do not trust each other, and also reduces 

transaction costs”.  (Voshmgir, 2016) 

These definitions contain the most important aspects for understanding the term from today's 

perspective. A Smart Contract is a contract written as software program. The contractual conditions 

of all parties are clearly represented in the software and written as program code. These programs 

run on the blockchain and do not require a central instance for contract execution. If all parties to 

the contract fulfil their obligations, the Smart Contract registers this. It then automatically fulfils 

the event specified in the contract. It is also possible that the parties involved do not know each 

other. The classic writing of a contract on paper becomes redundant. The human being is only 

responsible for writing the program code and storing it in the blockchain. These program codes are 

based on the principle of if-then functions. It is defined in advance in the Smart Contract which 

conditions must be fulfilled and which event this fulfils. These if-then functions are also easy for 

humans to understand, as they follow a logical pattern (Tittlus, 2018). 

10



To understand the functioning of Smart Contracts in detail, it is important to know the step-by-

step process. The process is typically divided into these four different steps:  

• Step 1: Pre-defined contract 

• Step 2: Events 

• Step 3: Contract execution and value transfer 

• Step 4: Settlement 

Step 1: At the beginning, the contract contents of all parties are clearly defined. 

These contract contents (if-then functions) are then formulated in a program code. Once 

programming is complete and all parties involved have agreed, the Smart Contract can be integrated 

into the blockchain. Ensure that the program code is correctly formulated before it´s integrated to 

the blockchain. It is not possible to change it afterwards, because the blockchain is unchangeable.  

Step 2: Events that happen cause the Smart Contract to be triggered. This is done by fulfilling the 

if part of the function. This event can be either a triggered transaction or information received. 

External events (outside the blockchain) can also be included with ""Oracles"". Oracles are programs 

that provide information for the Smart Contract. The temperature outside could be such external 

event.   

Step 3: The conditions defined in the smart contract. After the event happens the condition part of 

the function is executed automatically. This is followed by a transfer of data on the blockchain. An 

example would be a transfer of some virtual currency.  At the same time the next step is initiated. 

Step 4: There are two different variants for the processing. A settlement is made between directly 

on the blockchain (on-chain) or settlement outside the blockchain (off-chain)  

(Ferenzy, French & Silverberg, 2016; Hofmann, Strewe & Bosia, 2017; Swanson, 2015). 

  

11



2.4. Applications in the financial sector 

So, there can be a lot of advantages by using DLT, Blockchain and Smart Contracts. These 

advantages can be transferred to potential applications for the financial sector. Two major areas of 

application are described in detail in this chapter. Summing up from the previous chapters, there 

are the following advantages from a blockchain implementation: 

• Each transaction or entry is securely documented and transparent for all parties involved. 

Updates are only possible if everyone agrees. Stored data is therefore accurate, transparent 

and consistent. They can be accessed by all authorized persons. The modification of a 

single transaction record would require the modification of all subsequent records and the 

approval of the entire network.  

• Security is a major advantage. Transactions must be agreed upon by all parties before they 

are recorded. Once the approval process is complete, the transaction is encrypted and 

linked to the previous transaction. The information stored in a network of computers, 

which makes it impossible for hackers to compromise transaction data.  

• On more advantage of blockchain is the traceability. An insight into historical transaction 

data can help to verify the authenticity and prevent fraud.  

• The blockchain and smart contracts enable more speed in traditional business transactions. 

Anyone who uses classic contracts and processes knows about the duration and error-

proneness of complex transactions involving many parties. Errors often result in long 

delays or legal proceedings. It becomes easier to trust each other, so that clearing and 

settlement can take place more quickly. 

• In fact, a significant reduction in costs for administration as well as internal and external 

financial transactions and reporting is also expected. Those who rely on the block chain do 

not need so many third parties or other entities to provide guarantees. Trust in the trading 

partner no longer plays a role, you can fully rely on the block chain data. 

12



Know Your Customer  

For companies in the financial sector it’s very important to know their business partners 

and customers. This is where the Know Your Customer (“KYC”) process comes into action. 

Requests for this process can currently take up to 50 days and can lead to significant delays. 

Because it can take so long to verify a new customer, this also has an increasingly negative impact 

on the customer experience. The KYC process is highly regulated, which makes it extremely 

complex. The penalties for violations can also be enormous. According to a survey by Thomson-

Reuters, a bank spends an average of ÂŁ40 million per year for compliance with KYC guidelines. 

Some banks even come up with amounts of 300 million pounds.  The constant changes and the 

internationally varying regulations make it increasingly difficult for banks to comply with the rules.  

The process could be greatly improved with a blockchain application. As soon as a bank 

carries starts a KYC audit on a new customer, it can store the all documents, on the blockchain. 

These documents can then be used by other banks and other organizations. Other banks and 

organizations don´t need to repeat the KYC process. This can save valuable time and significantly 

reduce costs. Because the documents are stored in the blockchain they get manipulation-safe and 

traceable. So, the blockchain offers an optimal solution for this. The customer would have the 

advantage that he only needs to do his authentication once. All other companies would just access 

the previous stored data.  

According to a report by Goldman-Sachs, the banking sector can achieve a 10% reduction 

for the employees involved with the KYC process. This corresponds to an annual cost saving of 

around 160 million dollars. The report also says that the amount of funds allocated to employee 

training for KYC would be reduced by 30%. The total operational cost savings are estimated at 

approximately $2.5 billion (Shumsky 2019). 

  

13



Money transfer national and international 

The transfer of money is a major task in the finance sector. The prices for the transfer of 

money vary widely. Depending on the region and service provider, different prices are possible. In 

the European Union the SEPA platform is widely used for the money transfer. This platform is used 

by all banks in Europe that have the Euro as their national currency. Due to a regulation of the 

European Union, cross-border payments in the European Union are subject to the same fees as 

regular domestic transfers. Usually banks do not charge any fees for transfers within the euro 

countries (European Commission, 2009).  

The other case is if a transfer is made to a non-European country. The fees increase 

significantly. The average fee for a transfer of 200 US dollars is 7.14%. According to the World 

Bank, 574 Billion USD was sent in remittances globally in 2016. Although the fees have been 

falling since 2011, they are still very high (Chow, 2018). The largest provider of cross-border 

payments worldwide is Western Union. Transfer with Wester Union normally take up to two days. 

The top three countries for cross-border payments are India, China and the Philippines (Wikipedia, 

2020).  

Another problem is that many people today don’t have access to a bank account. According 

to a Forbes report, 1.7 billion adults do not have a bank account. China leads the statistics with 224 

million people. This makes them rely on overpriced services from companies like Wester Union 

(McCarthy, 2018). 

The fees and the transfer time could be drastically reduced with the help of the blockchain. 

Also, a solution would be found for those who do not have a bank account, but still want to transfer 

money quickly and easily. This would be possible with the help of a blockchain application. For 

example, the company ripple says that it´s blockchain solution reduces 33% of the operating costs 

during the international payment process. It also makes it possible to complete the process in a few 

seconds (Shumsky 2019). 

14

https://www.forbes.com/sites/niallmccarthy/


It could be possible that the central banks issue a digital currency via the blockchain. Many 

states and central banks are already thinking about such a digital currency. One of them is the 

European Central Bank which is playing with the idea of introducing a digital Euro. The money 

transfer would then simply go through the blockchain. Access to your wallet would then be easy 

via the password of your wallet. This wallet can be made available as an app or via a website. That 

will provide also a solution for people without bank accounts. With the help of the blockchain even 

micro transactions are possible. The average fee for such a micro transaction is only 0.01 US Dollar. 

This makes even offering articles in the cent range profitable. For example, single newspaper 

articles for a few cents, which are sold online. With this transaction fee it would be possible to 

make a turn over, even the price for the article is so low. The customer could buy only the articles 

he wants and don’t need a subscription (Varma 2019). 

3. Findings 

 

 

 

 

 

 

 

 

 

 

 

 

 

Figure 3: Model used as a guideline for this research 

Distributed 
Ledger 

Technology 
Technology 

 

Smart Contracts 
 

Applications in 
the financial 
sector 

Blockchain 

15



According to the study by comdirect, many newly founded start-ups in the Fintech sector 

were involved in the blockchain sector. It is the fastest growing area among the FinTechs 

(comdirect, 2019). In order to understand the possible applications and advantages of implementing 

the blockchain in the financial sector, it is necessary to get a technical background. This often 

involves the terms Distibuted Ledger Technology and Smart Contracs. Distibuted ledger 

technology is often used as a synonym for the blockchain. However, this is not the correct approach 

(Bashir, 2018). Distributed ledger technology is practically one major part of the technical 

framework for the blockchain. The main factor here is that it is a distributed database. The 

blockchain is based on the principle of distributed data (UK Government, 2016). In addition, the 

stored data is chained with hash functions. This leads to one of the most important advantages of 

the blockchain, which is the manipulation-safe storage of data and transactions (Berentsen & Schär, 2017).  

An important element of the blockchain are also the Smart Contracts, which make it 

possible to digitalize contracts and to let the conditions expire automatically (Tittlus, 2018). All this 

technologies and developments are incorporated in these start-ups and lead to a wide variety of applications.  

Two of these popular fields of application are the Know Your Customer Process (KYC) 

and the money transfer nationally or internationally. For these fields of application there are smart 

solutions. With these solutions not only the company’s profit, also the customers have a lot of 

benefits. Many of these applications are still concepts and ideas. Really fully market-ready 

applications do not exist at this time (Shumsky 2019; Varma 2019). 

4. Conclusion 

This work addresses primarily companies and their employees in the financial sector. They 

should get an overview of what is behind the technology, what advantages it offers and what use 

cases are possible. Since this is a very current topic and an extremely interesting one for start-ups 

in the financial sector, companies should try to keep an eye on current developments (comdirect, 

2019). It would make sense for companies to analyze their own processes for the use of the block 

16



chain. The result should be to find applications where such an implementation of distributed ledger, 

blockchain or smart contracts could be worthwhile. 

The advantages of an implementation are mainly on the side of the companies, but also 

customers could benefit from it. This is illustrated by the example of the large number of customers 

without access to a bank account (McCarthy, 2018). At the moment, they still depend on the service 

of companies like Western Union. Where they pay horrendous fees and take several days to transfer 

the money (Chow, 2018; Wikipedia 2020).  

The customers can for example also benefit from the development in the KYC sector. They 

don´t have to re-identify themselves with the scan of their ID card on every platform again. It is 

simply enough to have their data record stored on a blockchain platform. It is simply enough to 

store a unique data record on the blockchain. The time saved during verification is also an advantage 

for the customer (Shumsky 2019). 

Based on this work, further applications could be selected and companies already working 

on platforms and solutions could be contacted. A well-known platform in development is for 

example the one of the R3 consortium. About 300 companies are involved, including global players 

in the finance sector like Deutsche Bank or BNP Paris. This definitely speaks for the interest of the 

blockchain technology in the financial sector (R3, 2020).  

Because we are still at a very early stage of this development, the topic should be taken 

slowly. Currently 87% of the companies researching blockchain are in the early stage of 

development. Only 3% are in the final stage and actually use the technology. Really big 

development steps are not to be expected immediately. However, it is assumed that blockchain will 

be suitable for mass production";"""date"",""2021-02-06T05:30:26Z""
""pdf:PDFVersion"",""1.7""
""xmp:CreatorTool"",""MicrosoftÂŽ Word 2019""
""pdf:docinfo:title"",""The blockchain technology and its applications in the financial sector""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""Major: International Business Managment
Degree:	Master of Business Administration (International Program)
Academic: 2020""
""language"",""en""
""dc:format"",""application/pdf; version=1.7""
""pdf:docinfo:creator_tool"",""MicrosoftÂŽ Word 2019""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""The blockchain technology and its applications in the financial sector""
""xmp:CreateDate"",""2021-02-06T11:30:34Z""
""modified"",""2021-02-06T05:30:26Z""
""cp:subject"",""Major: International Business Managment
Degree:	Master of Business Administration (International Program)
Academic: 2020""
""pdf:docinfo:subject"",""Major: International Business Managment
Degree:	Master of Business Administration (International Program)
Academic: 2020""
""pdf:hasMarkedContent"",""true""
""xmp:ModifyDate"",""2021-02-06T12:30:26Z""
""pdf:docinfo:creator"",""Arnold Krause 6217190071""
""meta:author"",""Arnold Krause 6217190071""
""meta:creation-date"",""2021-02-06T04:30:34Z""
""created"",""2021-02-06T04:30:34Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2021-02-06T04:30:34Z""
""resourceName"",""MBA-2020-IS-The-blockchain-technology-and-its-applications-in-the-financial-sector.pdf""
""Author"",""Arnold Krause 6217190071""
""producer"",""MicrosoftÂŽ Word 2019""
""pdf:docinfo:producer"",""MicrosoftÂŽ Word 2019""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""dc:description"",""Major: International Business Managment
Degree:	Master of Business Administration (International Program)
Academic: 2020""
""Keywords"",""Distributed Ledger Technology (DLT); Blockchain; Smart Contract; Applications in the financial sector"",""Distributed Ledger Technology (DLT); Blockchain; Smart Contract; Applications in the financial sector""
""access_permission:modify_annotations"",""true""
""dc:creator"",""Arnold Krause 6217190071""
""description"",""Major: International Business Managment
Degree:	Master of Business Administration (International Program)
Academic: 2020""
""dcterms:created"",""2021-02-06T04:30:34Z""
""Last-Modified"",""2021-02-06T05:30:26Z""
""dcterms:modified"",""2021-02-06T05:30:26Z""
""title"",""The blockchain technology and its applications in the financial sector""
""xmpMM:DocumentID"",""uuid:7E28E134-99F1-4A51-B5CF-58D0FE550D13""
""Last-Save-Date"",""2021-02-06T05:30:26Z""
""pdf:docinfo:keywords"",""Distributed Ledger Technology (DLT); Blockchain; Smart Contract; Applications in the financial sector""
""pdf:docinfo:modified"",""2021-02-06T05:30:26Z""
""meta:save-date"",""2021-02-06T05:30:26Z""
""Content-Length"",""631839""
""Content-Type"",""application/pdf""
""xmp:MetadataDate"",""2021-02-06T12:30:26Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Arnold Krause 6217190071""
""dc:language"",""en-US""
""pdf:producer"",""MicrosoftÂŽ Word 2019""
""dc:subject"",""Distributed Ledger Technology (DLT); Blockchain; Smart Contract; Applications in the financial sector"",""Distributed Ledger Technology (DLT); Blockchain; Smart Contract; Applications in the financial sector""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""25""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""301"",""0"",""0"",""491"",""414"",""156"",""1985"",""2081"",""1404"",""653"",""1561"",""1916"",""1929"",""2024"",""1402"",""2203"",""1736"",""2030"",""1968"",""2044"",""1216"",""2290"",""2203"",""2232"",""2294""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""meta:keyword"",""Distributed Ledger Technology (DLT); Blockchain; Smart Contract; Applications in the financial sector"",""Distributed Ledger Technology (DLT); Blockchain; Smart Contract; Applications in the financial sector""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2021-02-06T04:30:34Z""
";https://scholar.google.ch/scholar?start=850&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098853-306;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;[LIVRE][B] Cryptocurrency and Blockchain Technology;S Corbet, A Urquhart, L Yarovaya ;2020 books.google.com;;"… What is the Bitcoin mining process? What is crypto-transactions? Moreover, the

blockchain is not only about Bitcoin … 2.5.1 Scalability Among the technical problems

of blockchain, we overview scalability and oracle problem …";Cité 2 fois;Les 2 versions;null;;;;https://scholar.google.ch/scholar?start=850&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098782-144;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Context-based smart contracts for appendable-block blockchains;HC Nunes, RC Lunardi, AF Zorzo… ; … and Cryptocurrency …, 2020  ieeexplore.ieee.org;;"… If an error is returned, then the transaction is discarded, and no alteration is applied to the

blockchain. The approach shown in Figure 2, allows to use the EVM developed by the

Ethereum Foundation … The cryptocurrency, Ether, is intrinsic to the EVM …";Cité 4 fois;Les 5 versions;[PDF] arxiv.org;https://arxiv.org/pdf/2005.00895;"
Context-based smart contracts for
appendable-block blockchains

Henry C. Nunes∗, Roben C. Lunardi∗†, Avelino F. Zorzo∗, Regio A. Michelin‡ and Salil S. Kanhere‡
∗Pontifical Catholic University of Rio Grande do Sul (PUCRS) - Porto Alegre, Brazil

†Federal Institute of Rio Grande do Sul (IFRS) - Porto Alegre, Brazil
‡University of New South Wales (UNSW) - Sydney, Australia

E-mail: {henry.nunes,roben.lunardi}@edu.pucrs.br, avelino.zorzo@pucrs.br, {regio.michelin,salil.kanhere@unsw.edu.au}

Abstract—Currently, blockchain proposals are being adopted
to solve security issues, such as data integrity, resilience, and non-
repudiation. To improve certain aspects, e.g., energy consumption
and latency, of traditional blockchains, different architectures,
algorithms, and data management methods have been recently
proposed. For example, appendable-block blockchain uses a
different data structure designed to reduce latency in block and
transaction insertion. It is especially applicable in domains such
as Internet of Things (IoT), where both latency and energy are
key concerns. However, the lack of some features available to
other blockchains, such as Smart Contracts, limits the application
of this model. To solve this, in this work, we propose the use
of Smart Contracts in appendable-block blockchain through a
new model called context-based appendable-block blockchain.
This model also allows the execution of multiple smart contracts
in parallel, featuring high performance in parallel computing
scenarios. Furthermore, we present an implementation for the
context-based appendable-block blockchain using an Ethereum
Virtual Machine (EVM). Finally, we execute this implementation
in four different testbed. The results demonstrated a performance
improvement for parallel processing of smart contracts when
using the proposed model.

Index Terms—IoT, Blockchain, context-based, smart contracts.

I. INTRODUCTION

Distributed applications, such as distributed databases [1],
have existed for a long time. However, they are dependent on
an assumption of trust, i.e. nodes that compose the environ-
ment are honest. Alternatively, trust can be delegated to a third
party that can assure that the environment is trustable. One
such third party is a certificate authority [2] that can assure
the identity of the nodes. The blockchain concept changed
this scenario, ensuring the robust execution of a deployed
application even if some of the participating nodes misbehave
or become unavailable. Blockchain also offers other benefits,
including audibility, transparency, and the possibility to have
decentralized applications (dApps). The combination of those
benefits allows to use blockchain in multiple domains, such as
financial operations [3], supply chain [4], Internet of Things
(IoT) [5], health care [6], smart vehicles [7], smart cities [8]
and others [9].

However, a number of challenges need to be addressed
before the widespread uptake of this technology. Zheng et
al. [3] highlight several such challenges, including scalability
and privacy leakage. Furthermore, two key challenges that are

specifically relevant to IoT applications are high latency [10]
and high energy consumption from some consensus algorithms
[11]. They are relevant because of the high amount of gener-
ated data, the need for low latency for specific applications,
and the hardware constraints on most IoT devices.

SpeedyChain [12] [13] [14], which uses the appendable-
block blockchain model, was specifically proposed to address
these issues by employing a different block structure and
network architecture. The block structure allows the insertion
of multiple transactions in the blockchain at the same time,
and the network architecture uses the concept of gateways that
allows higher performance devices to process transactions in
the blockchain [13]. Moreover, it uses the practical byzantine
fault tolerance (PBFT) consensus algorithm for achieving
energy efficiency [11]. Michelin et al. [12] demonstrated
promising performance improvements by adopting Speedy-
Chain for storing and managing sensor data collected from
smart vehicles in the context of smart city applications.

Smart contracts can benefit from the appendable-blocks
blockchain model used in SpeedyChain. In specific scenarios,
the insertion of transactions in parallel can increase the per-
formance of smart contracts. Moreover, the addition of smart
contracts gives flexibility to applications that can work on top
of SpeedyChain. For example, smart contracts can be used to
help in IoT security in the following ways [5]: (i) providing
an IoT update service; (ii) allowing a marketplace between
devices; (iii) management and control of an IoT network; and
(iv) delegated processing and workload balancing.

Due to those benefits, in this work, we propose a model
to provide the smart contracts capability on the Speedy-
Chain architecture, called context-based for appendable-block
blockchain. The model works by isolating a group of smart
contracts - from the same context - in a single block. Each
group can receive transactions independently - in parallel - to
the other groups , thus increasing performance. To validate our
model, we present an evaluation focused on delegated process-
ing for route calculation based on GPS data for IoT devices.
Although we apply the context-based smart contracts model to
one specific blockchain technology, the ideas presented in this
paper can be generalized and used in different architectures.

This work is divided as follows. Section II discusses the
background concepts to understand our proposed model and
its implementation. In Section III we establish the context-

ar
X

iv
:2

00
5.

00
89

5v
1 

 [
cs

.C
R

] 
 2

 M
ay

 2
02

0



based smart contracts model. Section IV discusses the changes
to SpeedyChain to include our context-based model. Section
V define our experiment and discuss the results. Finally, final
considerations and future work are presented in Section VI.

II. BACKGROUND

This section presents the background required to understand
the model of smart contracts for appendable-block blockchain.
Therefore, we discuss different concepts used to build the
model proposed in this paper. First, we present the functions
used in the paper, followed by immutable-block blockchain
structure, main appendable-block blockchain concepts, and the
adopted smart contracts definition.

A. Mathematical functions

The functions we use throughout these paper are:
• We will use function p to extract element e from a tuple

using a lambda function as presented in equation 1:

pe(tuple) = (λ(T1, ..., Te, ...Tn)→ Te) (1)

As an example for (1), considering t = (1, 6, 3) the
operations p1(t), p2(t) and p3(t) will result in 1, 6 and
3 respectively.

• We will use H(x) as a hash function that can receive any
sequence of bits x as input and output another sequence
of bits [15]. The specific H(x) function used here will
be abstracted. Proprieties of a good hash function, as
collision-free, pseudo-randomness and unpredictability
will just be assumed as true.

• The PK function receives a digital signature as input
and returns the public key from an asymmetric cryptog-
raphy scheme. For this work, we consider a cryptography
scheme in which you can recover a public key directly
from a digital signature [16].

B. Immutable-Block Blockchain

A blockchain is a distributed ledger that permanently stores
all transactions that brought the system to the current state
[17]. Transactions are stored in blocks, once a block is added
to the blockchain it is immutable, hence we call this type of
blockchain an immutable-block blockchain. It is distributed
because the system will work based on a Peer-to-Peer (P2P)
network [18], in which each node in the blockchain network
will maintain a local copy of the blockchain.

The system state is changed by one node using the con-
sensus algorithm to add new blocks. That causes all nodes
to change their local copy of the system state. The algorithm
works as a pre-agreement of how the system can progress, it
helps all nodes to converge to the same system state despite
some nodes malfunctioning or acting in a malicious way.
There are multiple consensus algorithms, like Proof of Work
(PoW) [17], Proof of Stake (PoS) [19] and Practical Byzantine
Fault Tolerance (PBFT) [20]. The consensus algorithm will be
abstracted in this work to the function performConsensus
that returns true if a proposed block is authorized to be

added to the blockchain or false otherwise. More details about
consensus are discussed in [14].

The behavior of individual nodes is not presumed as correct
or honest. The consensus algorithm guarantee that even if
part of the nodes work maliciously or incorrectly, the data
inserted in the blockchain can be trusted, and the system will
work correctly. This feature is one of the major benefits of
the blockchain. There are other benefits such as auditability
[21], since all transactions are stored as a ledger the current
state can be audited at any time; resilience [21], as a result
of blockchain, is distributed in a P2P network, in the event of
fault of any node, the blockchain continues working.

C. Appendable-Block Blockchain

The immutable-block blockchain is nowadays the most
used data architecture in blockchains. It is used in impor-
tant data ledger technologies such as Ethereum [22], Bitcoin
[17] and Hyperledger Fabric [23]. However, there are other
architectures proposed by industry, like the Tangle architecture
proposed by IOTA [24], and by academia, as SpeedyChain
[13], whose data structure is relevant to this work.

SpeedyChain is designed for the context of IoT, where
devices usually have low computing power and limited storage
capacity. This limits the capability to use a blockchain because
of the necessity to store the blockchain in the nodes and the
computing power required for some consensus algorithms such
as PoW. Furthermore, high communication latency is a key
factor in some IoT applications, which is another limiting
factor in the use of blockchain in this case. To mitigate
these problems, SpeedyChain proposes:(i) to use gateways
with more processing power and storage to work as blockchain
full nodes, while other IoT devices have to connect to those
gateways to access the blockchain. This removes the burden
of maintaining a full node for limited IoT devices; and
(ii), a mutable blocks architecture, referenced as appendable-
block blockchain, where blocks can be expanded with new
transactions. This approach allows the blockchain to expand
appending transaction in multiple blocks in parallel, while
immutable-block blockchain can insert new transactions just
by the introduction of a new block [13] [12] [14].

Formally, a generalization of the appendable-
block blockchain architecture has a set of n nodes
N = {N1, ..., Nn}. Nodes are gateways and IoT devices
that generate data. Each {Ni} has a pair of public/secret
keys (NPKi, NSKi) respectively from an asymmetric
cryptography scheme, where the public keys are accessible to
every participant of the blockchain [14].

The data structure in an appendable-block blockchain is
a non-empty set BC of blocks. Each block is a tuple
(BH,BL). BL, named block ledger, is a set of transactions
that can be incremented as necessary and linked to a BH .
The BH , named block header, is another tuple composed
of (ParentHash,NPKi, T ) with meta-data about the block.
Those fields are:



• ParentHash is the result of H(BH) of the block
inserted in the blockchain before this one. It works as
a pointer to the previous block.

• NPKi is the public key of a member of the set N , only
one block can have a specific NPKi. To enforce that the
@x |x, b ∈ BC ∧ p2(p1(x)) = p2(p1(b)) post-condition
must be respected. The node that has the NSKi to the
NPKi of a block is said to be the block owner, and only
that node can append new transactions to that block.

• T is the first transaction inserted in a block and the
only one to be part of the block header, furthermore,
this transaction is the first transaction signed by a pair
of public/secret keys, the public key is the NPKi value.

The BC set will form a hash-linked list of blocks B
connected by their ParentHash in the BH .

A transaction withholds data generated by the nodes, the
data content depends on the application and context. In the
appendable-block blockchain a transaction is represented as a
tuple of (Data, PT, Sig), where: Data is specific to the node
generating data through the creation of the transaction; PT is
a the hash of the previous transaction inserted in the block, it
works as a hash-link connecting the transactions in the block.
If it is the first transaction in the block, then it will refer to
the hash of the BH; and Sig is a digital signature from the
node originating the Data [14].

Before presenting how appendable-block blockchain adds
new blocks and appends transactions, we present the auxiliary
functions newBlock as shown in Equation 2, which summa-
rizes the creation of a new block filling the necessary fields,
and function lB (Equation 3) , which returns a block that has
no other block with the ParentHash in the header pointing
to it. In practice, it is the last block created in the blockchain.

newBlock(T,BC) =
((H(p1(lB(BC))), PK(p3(T )), T ), {})

(2)

lB(BC) = x|x ∈ BC∧
(@y ∈ BC ∧ p1(p1(y)) = H(p1(x)) ∧ x 6= y)

(3)

To add a new block to the blockchain, function
addB(BC, T ) (Equation 4) is used. It creates a new block
for a node and appends the new block to the blockchain if
there is no other block with the same NPK as the transaction
signature public key PK(p3(T )). The predicate uniqueBlock
(Equation 5) guarantees this requirement.

addB(BC, T )=


BC ∪ newBlock(T,BC),
if uniqueBlock

BC, otherwise

(4)

uniqueBlock = @x.x∈BC∧ p2(p1(x))=PK(p3(T )) (5)

New transactions are generated by nodes with new Data to
be inserted in the blockchain. This operation is performed only
if the node’s public key (NPKi) is present in a block header

BH . Function appendT (Equation 6) specify the insertion of
a new transaction T in a block B that has a public key equal
to the public key used in the transaction signature.

appendT (BC, T )=


(BC −B) + updateB(B, T ),
if p2(T ) = PreTHash(B)

BC, otherwise

(6)

updateB (Equation 7) is an auxiliary function to generate
an updated block where transaction T is appended. Function
PreTHash (Equation 8) returns the hash of a previous
transaction appended to the block or the block B header hash.
This hash will be used to check if a transaction is pointing to
the PT field of the last transaction inserted to the block.

updateB(B, T ) = (p1(B), p2(B) ∪ T ) (7)

PreTHash(B) =

{
H(p1(B)), if |p2(B)| = 0
H(lastT (B)), otherwise (8)

Algorithm 1 shows how the main operation works on this
model for the insertion of new transactions in a continuous
way. The mempool consists of a set of transactions submitted
to the blockchain by multiple nodes, but not yet appended to
the blockchain, this mempool is shared by all nodes. Function
poll, on the mempool, returns one transaction of the set.
Before processing a new transaction, it checks if a block with
the public key of the signer exists through function exists
(line 6); if not, a new block is processed by the consensus
algorithm (line 7) and if approved, a new block is inserted
and broadcast to the network (lines 9 and 10). Otherwise, the
proposed transaction is processed by the consensus algorithm
(line 12) and if accepted, it is appended to the block owned
by the transaction signer (more details about this algorithm is
described in [14]).

Algorithm 1 Main operation for Appendable-block
Blockchain

1: Result: BC //Updated state
2: Input: mempool, BC //Original state
3:
4: while (True) do
5: T = poll(MemPool)
6: if (!exists(PK(p3(T)))) then
7: ConsensusResponse = performConsensus(B)
8: if (ConsensusResponse) then
9: broadcast(B)

10: BC = addB(BC, T)
11: end if
12: else
13: ConsensusResponse = performConsensus(T)
14: if (consensusResponse) then
15: broadcast(T)
16: BC = appendT(BC, T)
17: end if
18: end if
19: end while



D. Smart contracts

There are different models for smart contracts implemen-
tation in blockchains. One of these models is the one used
by Ethereum [25]. In Ethereum, smart contracts are stored
in the blockchain as special transactions. Those transactions
are bytecode that can be processed by the Ethereum Virtual
Machine (EVM). Each node in the Ethereum network has an
EVM. Calls, like a program call, for a smart contract, are
appended to the blockchain as transactions. The transaction
contains the bytecode, representing the program call, to be
processed in the context of a specific smart contract.

Throughout this work, we will refer to a generic virtual
machine as a function VM , which works similarly to the
EVM [22], i.e., VM(S,Data) = S′. VM receives two inputs:
Data, which is the bytecode with operations for the virtual
machine; and, S, which is a pointer to a data structure that
contains a state for the virtual machine and multiple smart
contracts. The output for the VM function is a reference
to new state S′, based on the modifications that the Data
incurred. We store different states in a Merkle Patricia Trie
[25]. A new S with no modifications is refereed as the constant
newS.

III. CONTEXT-BASED MODEL

This section presents the context-based model for extending
the appendable-block blockchain architecture with the smart
contracts capability. In this model, each block can hold a
block state, which is a data structure capable of holding a
mapping from an address to a smart contract state and code.
Remember from the previous section that we use as a reference
for the data structure a Merkle Patricia Trie [25]. Aside from
these new blocks with this capability to hold the block state,
the blocks that carry just data from nodes, as presented in
appendable-block blockchain (see Section II-C) still exist.
During the creation of a new block it is decided which type
of block will be created: a pure data block, which will carry
just data; or, a block with context, which will hold a state.

Figure 1 presents an overview of the model. In the figure,
three blocks are presented, only blocks B− 1 and B+1 hold
smart contracts, identified by the absence of a block PKi.
Therefore they are blocks with context. While block B is
a pure data block, identified by the presence of a PKi. A
context can have smart contracts, those smart contracts are
isolated from other block context and can only interact with
smart contracts in the same block, thus this model is called
context-based model. In Figure 1, Smart Contract I can interact
with Smart Contract II and III, this includes making a call to
the other smart contracts, changing their states and querying
information. Smart Contract IV, in block B+1, cannot interact
with Smart Contract I, II and III in any form. A blockchain
that adopts the proposed model can have any amount of blocks
with context. The transactions stored in those blocks will carry
a bytecode that represents a call for a smart contract or a
command to create a new smart contract.

All the functions in an appendable-block blockchain work
exactly as previously presented in Section II-C, unless

ParentHash ∅

Transaction 0

Transaction 1

Transaction 2

Transaction n

...

Context Block B-1

BH B-1

Block B-1

ParentHash PK i

BH B

Block B

ParentHash ∅

Context Block B+1

BH B+1

Block B+1

SMART CONTRACT I

SMART CONTRACT II

SMART CONTRACT III

SMART CONTRACT IV

SMART CONTRACT V

Context Block B-1 Context Block B+1

Transaction 0

Transaction 1

Transaction 2

Transaction n

...

Transaction 0

Transaction 1

Transaction 2

Transaction n

...

Fig. 1. Smart contracts and Block context

stated otherwise. The elements of the tuple (BH, BL)
representing the blockchain are different. BH is a
tuple (ParentHash, Index,NPK,CTransaction) where
ParentHash and NPK work as in the appendable-block
architecture, although when the block has a context the value
of NPK will be equal to ∅, because there is no block owner or
restriction of devices who can operate in a block. The Index
field is a natural number whose value corresponds to the
order of blocks created in the blockchain. The CTransaction
field stores a committed transaction, it is different from a
transaction. A node can check if a block B has a context by
using function HasContext (Equation 9), and get a specific
block by the index using function getBlock(Equation 10).

HasContext(B) =

{
true if P3(P1(B)) = ∅
false if P3(P1(B)) 6= ∅ (9)

getBlock(Index) = x|x ∈ BC ∧ P2(x) = Index (10)

A committed transaction is defined as a tuple
(Data, Sig, PT,BlockState), it is originated from a
transaction that was processed by a node. The tuple fields
are:
• Data is a binary sequence that depending on the block

type will be treated differently. If it is a pure data block,
then Data represents data generated by a node, which
will not be processed as bytecode. If it is a block with a
block state, then it is a bytecode that will be inserted as
an input in the VM function.

• Sig is the digital signature of the transaction that gener-
ated this committed transaction.

• PT is the hash value of the previous inserted committed
transaction or the block header if it is the second com-
mitted transaction inserted the value will be the hash of
BH .



• BlockState is a pointer to a data structure holding
the block state, as the Merkle Patricia Trie. The last
committed transaction in the block has the most updated
state, its value is generated by VM .

When a Data transaction includes bytecode to a block with
context, it will be processed by function VM (Equations 11).
For that, Data and BlockState of the last inserted committed
transaction in the block are inserted as input in the VM
function, the resulting pointer to a new state will be attached
to a new committed transaction in the BlockState field. S′

is a pointer to the resulting state, S is the original BlockState
and NewS is an empty BlockState.

VM(S,Data) =

{
S′ if S 6= ∅
VM(NewS,Data) if S = ∅ (11)

A node that wants to operate on the blockchain will create a
transaction for that operation. The transaction is composed of
(Data, ToBlock, Sig, PT,OPCode), where the fields previ-
ously described in committed transactions are the same, the
ToBlock represents the destiny block where this transaction
is to be processed. If the ToBlock value is equal to ∅ and
OPCode is a specific value, then the transaction intention
is to create a new block with a context or a pure data block.
OPCode is an integer that represents a code for the transaction
intention, where 1 means the transaction is to create a new pure
data block, 2 means the transaction is to create a new block
with a context, and 3 means it is a transaction to be appended
in a block.

Two functions will be used to summarize the block creation,
when OPCode is 1 or 2: Function NewCBlock (Equation
12), which creates a new block with a context starting from
a newS; and, function NewPDBlock (Equation 14), which
creates a new pure data block.

newCBlock(T,BC) =
((H(p1(lB(BC))), p2(p1(lB(BC))) + 1, ∅, NCTC), {})

(12)

NCTC = (P1(T ), p3(T ), p4(T ), V M(∅, P1(T ))) (13)

newPDBlock(T,BC) = ((H(p1(lB(BC))),
p2(p1(lB(BC))) + 1, PK(p3(T )), NCTPD), {}) (14)

NCTPD = (P1(T ), p3(T ), p4(T ), ∅) (15)

A transaction that has OPCode 3 will be appended to a
block. However, the transaction appended is treated differently
if the intention is to append a transaction in a pure data block
or a block with context. The CTC function (Equation 16)
creates a committed transaction to be appended in a block
with a context. On the other hand, function CTPD (Equation
17) will create a transaction to a pure data block.

CTC(T,B) =


(P1(T ), p3(T ), p4(T ),
V M(p4(lastCT (B)))),
if p4(T ) = preCTH(B)

B, otherwise

(16)

CTPD(T,B)=


(P1(T ), p3(T ), p4(T ), ∅, P1(T )))
if p4(T ) = preCTH(B)

B, otherwise

(17)

preCTH(B) =

 H(p1(B)), if |p2(B)| = 0

H(lastCT (B)), otherwise
(18)

lastCT (B) =
x |x ∈ p2(B) ∧ (@y|y ∈ p3(B) ∧ p3(y) = H(x))

(19)

The functions in equations 16 and 17 are used in function
AppendT (Equation 20), which directs a transaction to the
correct function type by their OPCode and updates BC.

AppendT (BC, T ) =



(BC −B) ∪ CTC(T,B)
if HasContext(B) = true

(BC −B) ∪ CTPD(T,B)
if p3(B) = PK(p3(T ))

BC, otherwise

(20)

B = getBlock(P2(T )) (21)

The algorithm for the main operation for this model is
presented in Algorithm 2. In the algorithm, memPool works
exactly like presented in Section II. Line 6 checks if the
transaction being processed wants to append a new transaction
to the blockchain (OPCode 3) and if the destination block
exists. If both are true, then the transaction is processed by
the consensus algorithm and appended using the appendT
function (line 10). When the destination block does not exist,
then a transaction creates a new block with a context (line
11). It checks the OPCode value is equal to 2 and if the
destination block is equal to emptyset, case both conditions
are true then a new block will be created (line 15) after begin
processed by the consensus algorithm. Finally (line 16), the
algorithm checks if the transaction is to create a new pure
data block (OPCode 1). If so, then it is checked if there is
no other block with the same public key as the signature, then
it proceeds to create a new pure data block (line 20).

IV. IMPLEMENTATION

The implementation of the model should be easy to maintain
and also easy to incorporate into the existing blockchain
technology, in this paper into SpeedyChain. Taking that into
consideration, we designed an ideal node architecture (see



Algorithm 2 Main operation for appendable-block blockchain
with context-based model

1: Result: BC //Updated state
2: Input: memPool, BC //Original state
3:
4: while (True) do
5: T = poll(memPool)
6: if (exists(p2(T)) AND p4(T) = 3) then
7: ConsensusResponse = performConsensus(T)
8: if (consensusResponse) then
9: broadcast(T)

10: BC = appendT(BC, T)
11: end if
12: else if (p2(T) = ∅ AND p4(T) = 2 ) then
13: ConsensusResponse = performConsensus(B)
14: if (ConsensusResponse) then
15: broadcast(B)
16: BC = newCBlock(T, BC)
17: end if
18: else if (!exists(PK(p3(T))) AND p4(T) =1) then
19: ConsensusResponse = performConsensus(B)
20: if (ConsensusResponse) then
21: broadcast(B)
22: BC = newPDBlock(T, BC)
23: end if
24: end if
25: end while

Figure 2). Three new components are inserted in the Speedy-
Chain framework: Interface EVM (1), which is an interface
in the SpeedyChain to communicate, through an inter-process
communication protocol (2), with an internal EVM (3).

Interface 
EVM (1)

SpeedyChain(2)

Blockchain Interface

EVM (3)

Fig. 2. EVM and SpeedyChain

The process to run a smart contract starts with a new
proposed transaction, which for this explanation contains a
bytecode. We assume that all fields of the transaction and the
blockchain are correct to receive this generic transaction. As
presented in the model, Section III, this transaction targets an
existing block. From this block, the last state is extracted and
together with the bytecode is passed to the Interface EVM
inside the SpeedyChain.

Interface EVM wraps both datas in a JavaScript Object
Notation (JSON) format, which is then sent through an inter-
process to the EVM. After sending the JSON, it awaits a return
from the EVM with a result. The EVM receives the JSON with

the state and bytecode. It changes the virtual machine state to
the state received and using the bytecode as input process
the request, which yields a resulting bytecode and an updated
state. Both are wrapped in a new JSON object and sent as a
response to Interface EVM. An error message is sent, if there
is any problem when running the smart contract.

The results are unwrapped by the Interface EVM and
handed to the blockchain, which will use the updated state
to create a committed transaction as described in Section III.
If an error is returned, then the transaction is discarded, and
no alteration is applied to the blockchain.

This approach allows using the EVM developed by the
Ethereum Foundation. It is implemented in Golang and could
not be integrated internally with the SpeedyChain, imple-
mented in Python. The use of that EVM implementation is
important for maintainability. Any further update and mod-
ification by Ethereum Foundation in the EVM’s operations
would be inherited in our solution.

V. EVALUATION

In order to evaluate context-based smart contracts in
appendable-block blockchains, we applied our solution in four
testing scenarios (see Table I). Every scenario was performed
on a Virtual Machine (VM) with 4-core processor, 16GB
of memory and 64MB of graphics memory running Ubuntu
18.04 operating system using a Virtual Box hypervisor over
a Macbook Pro with 2.3 GHz 8-Core Intel Core i9 processor,
32GB DDR4 memory.In order to create a container-based
network to emulate network equipment and gateways and
devices the Core Emulator [26] was used. For all scenarios, a
network with ten gateways was simulated (see Figure 3).

TABLE I
EVALUATED SCENARIOS

Scenario Description

A Sequential execution of 1,000 smart contracts without
external load

B

Sequential execution of 1,000 smart contracts with an
additional load of 50 devices per gateway and 100
transactions per device, i.e., 5,000 transactions per
gateway and 50,000 transactions in total

C 10 parallel context with 100 smart contracts transactions
per context (1,000 in total) without external load

D

10 parallel context with 100 smart contracts transaction
per context (1,000 in total) with an additional load of
50 devices per gateway and 100 transactions per device,
i.e., 5,000 transactions per gateway and 50,000 transactions
in total

Scenario A was performed to establish a baseline for
smart contracts execution in appendable-block blockchains.
One hundred smart contracts operations were executed to
compute the distance between a device and a target using GPS
information. We simulated ten devices with sequential compu-
tation of smart contracts operations (total of 1,000 sequential
transactions) in the same gateway. Similarly to Scenario A,
Scenario B performed the same number of sequential smart
contracts computations, however, with an extra load of normal
type of transactions in every gateway. A normal transaction in



Gw1 Gw2 Gw3 Gw4 Gw5 Gw6

Gw7 Gw8 Gw9 Gw10

n1 n2 n3

n4 n5

IoT	GPS

n6

IoT	GPS IoT	GPS IoT	GPS IoT	GPS IoT	GPS

IoT	GPS IoT	GPS IoT	GPS IoT	GPS

Fig. 3. Emulated gateways architecture

this experiment is a random input of data in a pure data block.
The load was simulated through the insertion of 50 devices and
100 “normal” transactions produced by each device. In total,
50,000 additional “normal” transactions it were simulated.
These transactions were produced by 500 devices.

Different from previous described scenarios, Scenario
C used the proposed context-based smart contracts in
appendable-block blockchains. To do that, this scenario con-
sidered ten devices connected to ten different gateways and
requesting 100 smart contracts operations (1,000 operations,
the same computations as in A and B) in parallel, without
any extra load in the gateways. Similarly to C, Scenario D
adopted context-based smart contracts, with the same number
of transactions operations as C, but with the same extra load
present in B.

A. Metrics

In order to perform an evaluation of the proposed context-
based smart contracts in SpeedyChain, metrics called T1, T2,
T3, T4, T5, and T6 were used:
• T1: Time to perform consensus, insert a new block (first

time that device is connected) and replicate it to all
gateways;

• T2: Time to add and replicate a device block to all
gateways (after consensus);

• T3: Time to perform consensus, insert a new special
block for smart contracts and update EVM with the new
smart contract bytecode;

• T4: Time to insert a transaction in the blockchain;
• T5: Time to run a smart contract in the EVM and update

the blockchain;
• T6: Time to run all smart contracts evaluated (1,000

contracts operations).
All metrics are represented by an average time of ten

repetitions for each scenario. A confidence level of 95% was
achieved.

B. Results

Context-based smart contracts execution can impact the
consensus algorithms (T1) as presented in Table II. We c";"""date"",""2020-05-05T01:20:25Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2020-05-05T01:20:25Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016) kpathsea version 6.2.2""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2020-05-05T01:20:25Z""
""created"",""2020-05-05T01:20:25Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-05-05T01:20:25Z""
""resourceName"",""2005.00895""
""Author"",""""
""producer"",""pdfTeX-1.40.17""
""pdf:docinfo:producer"",""pdfTeX-1.40.17""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""5"",""4"",""5"",""0"",""0"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2020-05-05T01:20:25Z""
""Last-Modified"",""2020-05-05T01:20:25Z""
""dcterms:modified"",""2020-05-05T01:20:25Z""
""title"",""""
""Last-Save-Date"",""2020-05-05T01:20:25Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2020-05-05T01:20:25Z""
""meta:save-date"",""2020-05-05T01:20:25Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016) kpathsea version 6.2.2""
""Content-Length"",""452728""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""9""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""4881"",""4780"",""3816"",""4354"",""3560"",""3936"",""3309"",""4915"",""5123""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-05-05T01:20:25Z""
";https://scholar.google.ch/scholar?start=690&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098751-72;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Constant-Size Lattice-Based Group Signature with Forward Security in the Standard Model;S Canard, A Georgescu, G Kaim… ; … Conference on Provable …, 2020  Springer;;"… (PQCrypto 19) in the random oracle model, following the classical framework of encrypt-then … Our

starting point is the group signature of Katsumada and Yamada (Eurocrypt 19) which replaces

NIZK by attribute-based signatures (ABS), thus removing the need for random oracles …";Autres articles;;[PDF] archives-ouvertes.fr;https://hal.archives-ouvertes.fr/hal-03038560/file/LBGroupSignFS.pdf;"
HAL Id: hal-03038560
https://hal.archives-ouvertes.fr/hal-03038560

Submitted on 3 Dec 2020

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L’archive ouverte pluridisciplinaire HAL, est
destinĂŠe au dĂŠpĂ´t et Ă  la diffusion de documents
scientifiques de niveau recherche, publiĂŠs ou non,
émanant des établissements d’enseignement et de
recherche français ou Êtrangers, des laboratoires
publics ou privĂŠs.

Constant-Size Lattice-Based Group Signature with
Forward Security in the Standard Model

SĂŠbastien Canard, Adela Georgescu, Guillaume Kaim, Adeline Roux-Langlois,
Jacques TraorĂŠ

To cite this version:
SĂŠbastien Canard, Adela Georgescu, Guillaume Kaim, Adeline Roux-Langlois, Jacques TraorĂŠ.
Constant-Size Lattice-Based Group Signature with Forward Security in the Standard Model. ProvSec
2020 - the 14th International Conference on Provable and Practical Security, Nov 2020, Singapore /
Virtual, Singapore. pp.24-44, �10.1007/978-3-030-62576-4_2�. �hal-03038560�

https://hal.archives-ouvertes.fr/hal-03038560
https://hal.archives-ouvertes.fr


Constant-size Lattice-Based Group Signature
with Forward Security in the Standard Model ?

Sébastien Canard1, Adela Georgescu2,3, Guillaume Kaim1,2,
Adeline Roux-Langlois2 and Jacques Traoré1

1 Orange Labs, Applied Crypto Group, Caen, France
2 Univ Rennes 1, CNRS, IRISA

3 Department of Computer Science, University of Bucharest

Abstract. One important property of group signatures is forward-secur-
ity, which prevents an attacker in possession of a group signing key to
forge signatures produced in the past. In case of exposure of one group
member’s signing key, group signatures lacking forward-security need to
invalidate all group public and secret keys (by re-initializing the whole
system) but also invalidate all previously issued group signatures. Most
of the existing forward-secure group signatures (FS-GS) are built from
number-theoretic security assumptions which are vulnerable to quan-
tum computers. The only post-quantum secure FS-GS scheme is built
from lattices by Ling et al. (PQCrypto 19) in the random oracle model,
following the classical framework of encrypt-then-prove, thus using non-
interactive zero-knowledge (NIZK) proofs. In this work, we achieve the
first FS-GS from lattices in the standard model. Our starting point is
the group signature of Katsumada and Yamada (Eurocrypt 19) which
replaces NIZK by attribute-based signatures (ABS), thus removing the
need for random oracles. We first modify the underlying ABS of Tsabary
(TCC 17) to equip it with forward-security property. We then prove that
by plugging it back in the group signature framework of Katsumada
and Yamada (Eurocrypt 19), we can design a FS-GS scheme secure in
the standard model with public key and signature size constant in the
number of users. Our constant size is achieved by relying on complexity
leveraging, which further implies relying on the subexponential hardness
of the Short Integers Solution (SIS) assumption.

1 Introduction

Group signatures were introduced as a new type of signatures by Chaum and van
Heyst [CvH91] in 1991 and they were designed to allow only members of a group
to sign messages while the identity of the signer remains hidden for the verifier
(anonymity). The latter can only ensure that a member belonging to the group
has signed the message. Moreover this property guarantees the unlinkability as

? This paper is an extended version of the article published in the Proceedings of
ProvSec 2020, LNCS 12505, Springer-Verlag, which is available online at https:

//doi.org/10.1007/978-3-030-62576-4_2

https://doi.org/10.1007/978-3-030-62576-4_2
https://doi.org/10.1007/978-3-030-62576-4_2


well, preventing anyone to detect that two group signatures have been generated
by the same group member. Nevertheless, if necessary, the signature can be
opened by an entity called group manager who holds some secret information
and reveals the identity of the signer (traceability). These features make group
signatures very useful for real life applications including e-commerce systems,
anonymous online communications and trusted hardware attestations.

From their beginning until now, a great variety of constructions for group
signatures have been proposed, addressing different needs: in the random or-
acle model [CL04,BBS04] or standard model [BW06,Gro07], supporting static
groups [BMW03], dynamic groups [BSZ05] or partially dynamic groups and con-
structions based on different theoretical assumptions such as RSA [ACJT00], or
pairings [BBS04] for standard assumptions.

As for post-quantum constructions, there is a vast literature concerning
group signatures based on lattices, some of them being designed to support
most of the important properties listed above. Among them there are group sig-
natures in the static model [GKV10,CNR12,LLLS13,NZZ15,LNW15,LLNW16],
[LNWX18,BCN18,dPLS18], in the dynamic model where users have the flexi-
bility to join and leave the group [LNWX17], achieving partially dynamicity by
means of verifier-local revokability [LLNW14] (where new users can not join the
group but they can leave it being revoked), or using other tools to achieve par-
tial dynamicity [LLM+16,LMN16]. Concerning the random oracle model (ROM)
and the standard model, all of the existing lattice-based group signature schemes
are in the ROM except the construction by Katsumata and Yamada [KY19]. We
can further notice that the recent construction of non-interactive zero-knowledge
proof of knowledge (or NIZKPoK or NIZK) for all NP from [PS19] combined
with [BMW03] can be adapted in a group signature scheme in the standard
model in a straightforward manner (but very inefficiently as we explain in the
next subsection).

Forward-security [Son01,NHF09,LY10] is an important additional security
property sometimes considered in group signature constructions. Concerning lat-
tices, to the best of our knowledge there is one such construction in the ROM
model [LNWX19]. This property cuts the time into periods t and prevents at-
tackers from forging group signatures pertaining to past time periods t′ < t, even
if a secret group signing key is revealed at the current time period. As explained
in Song [Son01], in the context of group signatures, exposure of secret signing
keys is more damaging since an adversary being in the possession of a member’s
group signing key can produce signatures on behalf of the whole group, but still
remaining anonymous. As a consequence, all the public and secret keys of the
group need to be regenerated and all previously generated group signatures have
to be rendered invalid. We note that the solution to these problems is adding
a forward-secure mechanism to group signatures as was previously done first
for key exchange protocols ([Gün89],[DvOW92]) and then for digital signatures
([BM99],[IR01]), symmetric-key encryption ([BY03]) and public key encryption
systems ([CHK03]). This property aims to protect past use of private keys even
if an adversary breaks-in at the current moment of time. When entering a new

2



time period t, a new secret key related to t is computed from the previous secret
key related to t − 1 through a one-way key evolution algorithm, the latter one
being deleted promptly afterwards.

1.1 Our contribution

Our main achievement in this paper is a lattice-based forward-secure group sig-
nature scheme without NIZK in the standard model with public key and sig-
nature size constant (independent) on the number of users. We note that this
is the first of its kind in the standard model as the only existing construction
[LNWX19] for group signatures from lattices achieving forward-security is in the
random oracle model. Our group signature corresponds to the transformation of
the lattice-based group signature from [KY19] using the idea from [LNWX19]
to obtain forward-security.

The main building block of our transformation is a lattice-based forward-
secure attribute-based signature scheme (FS-ABS) that we introduce later in
this paper as a novelty. We mention that there is a previous general construction
of FS-ABS due to [YLH+12] which combines the general primitive of credential
bundles (which can be instantiated with forward-secure digital signatures) and
non-interactive witness-indistinguishable (NIWI) proofs. Using this framework
one can achieve lattice-based FS-ABS as long as one can build forward-secure
digital signature and NIWI from lattices, but, to the best of our knowledge, there
is no construction in the lattice-settings for any of them. Therefore, we believe
that our construction of lattice-based FS-ABS is of self-interest.

We mention that our group signature scheme satisfies CCA-selfless-anonymity
(inherited from the base group signature scheme of [KY19]), a relaxation of the
CCA-full-anonymity, since the adversary is not in possession of all the secret
keys: he is missing the secret keys of the two members, whose identities compose
the challenge. As for the traceability property, we show that our scheme achieves
forward-secure traceability.

As already explained in [KY19], group signatures from lattices in the stan-
dard model can be achieved also by using the recent proposal for NIZK for all
NP from LWE [PS19] (published shortly after [KY19]) instead of the ABS. The
difference is that the ABS that we employ in our group signature scheme relies
only on the hardness of SIS, avoiding the potentially stronger LWE assump-
tion on which the NIZK mentioned above relies, leading to a potentially heavier
group signature construction. Another drawback of a potential instantiation of
group signatures using [PS19] is that the latter one relies on fully homomorphic
encryption for evaluating circuits making it very costly in time efficiency.

1.2 Overview of the building blocks for our construction

In order to have all the elements needed to give a technical overview of our
scheme, we start by describing three existing constructions: the group signa-
ture scheme of [KY19], the ABS proposed by Tsabary [Tsa17], and finally, the
forward-secure mechanism of the group signature construction of [LNWX19].

3



Group Signature Scheme without NIZK. The starting point of our work is
the recent lattice-based group signature scheme without NIZK in the standard
model [KY19]. Previous to this construction, all works on group signatures were
relying on the Sign-Encrypt-Prove framework defined by Bellare, Micciancio and
Warinschi [BMW03]. In this framework, to sign a message M , a user encrypts
both his certificate received from the group manager and a digital signature on
M . Finally, he proves in non-interactive zero-knowledge that every element is
well formed. Until recently (2019), constructing NIZK from lattices for any NP
language was a long-standing open problem and by that time Katsumata and Ya-
mada [KY19] proposed a group signature scheme that by-passed the utilization
of NIZK by replacing it with indexed attribute-based signature scheme (ABS).
Their idea is based on the fact that for group signatures the needed NIZK is
in the common reference string (CRS) model and, in the context of group sig-
natures, it resembles to designated-prover NIZK (DP-NIZK) where there is a
proving key kP that needs to be kept secret (and thus is not known to the veri-
fier, assuring zero-knowledge) and a verification key kV which is public. Anyway,
simply replacing NIZK in the CRS model with DP-NIZK is not enough since it
trivially breaks anonymity. The breakthrough idea of Katsumata and Yamada
was to view ABS as DP-NIZK. In attribute-based signatures, a signer with an
attribute x is provided a secret key skx from the authority and can anonymously
sign a message associated with a policy C using his secret key, if and only if, his
attribute satisfies the policy C. In particular, the signature hides the attribute
(anonymity) and users can not collude to pull their attributes together if none
of the attributes satisfies the policy associated to the message (unforgeability).
Now, an ABS can be seen as a DP-NIZK by the following association: the at-
tribute x is seen as a witness w and the ABS signing key skx can be set as the
proving key kP of the DP-NIZK. Thus proving that w is a valid witness to a
statement s i.e. (s, w) ∈ R for the NP relation R resorts to, firstly prepare a
circuit Cs(w) = R(s, w) that has the statement s hard-wired into it, secondly
sign a message associated with the policy Cs using the proving key kP = skx and
finally output the signature as the NIZK proof π. Anonymity and unforgeability
of the ABS assure the zero-knowledge property and soundness respectively.

Having shown a way of substituting the NIZK with ABS, it remains to in-
dicate how to use ABS to construct group signature. We briefly explain, in the
following, the general framework from [KY19]. The group manager issues for
user i a key Ki of a secret key encryption (SKE) scheme and an ABS signing
key ski||Ki where i||Ki is seen as an attribute. To sign a message M , the group
member i encrypts his identity under Ki obtaining cti = SKE.Enc(Ki, i) and cre-
ates an attribute-based signature for some policy Ccti which serves as a NIZK
proof of the fact that cti encrypts the identity. The circuit Ccti has the statement
cti hardwired such that Ccti(i||Ki) := (i = SKE.Dec(Ki, cti)). The traceability
property of the group signature holds from unforgeability of ABS and anonymity
holds from anonymity of the ABS and semantic security of the SKE.

As for the instantiation of the ABS from lattices, [KY19] gives two possible
solutions: the first one uses the ABS proposed by Tsabary [Tsa17] proven secure

4



under the SIS assumption and the second one is an indexed ABS designed by
them, relying also on the SIS assumption. The need for the second construction
is explained by the problems encountered when trying to plug the first construc-
tion into a group signature. Tsabary’s scheme achieves selective unforgeability
which is not enough for security purposes of group signatures. Adaptiveness is
the required property and can be easily achieved via complexity leveraging with
the drawback that this approach requires a subexponential security loss. We re-
mark that in [KY19] they emphasize that they don’t really need adaptiveness but
rather something complementary to selectiveness called co-selective unforgeabil-
ity. Unfortunately, we can not achieve this property directly, without complexity
leveraging (see section 3.3 for more details). The two different ABS constructions
give two different group signature schemes with the following properties:

(i) Tsabary’s ABS gives rise to a group signature scheme with public key and
signature size constant (independent) in the number of users and whose
security relies on the hardness of LWE with polynomial approximation factor
and subexponential hardness of SIS with polynomial approximation factor.

(ii) The second ABS gives rise to a group signature scheme with public key
and signature size linear in the number of users whose security relies on the
hardness of LWE and SIS with polynomial approximation factors.

Attributed Based Signature from Constrained Signature of Tsabary.
The main building block of our group signature is an Attribute Based Signature
scheme. In the following we briefly explain the ABS developped in Tsabary’s
paper. First of all, the construction in Tsabary’s paper is not really an attribute-
based signature but rather a key-policy constrained signature or simply con-
strained signature. We note that the other flavour of constrained signatures, as
defined in [Tsa17], called message-policy constrained signature is equivalent to
attribute-based signatures. In constrained signatures, a signing key skf is as-
sociated with a policy f : {0, 1}∗ → {0, 1}, called the constraint, and a key
skf can sign a message x ∈ {0, 1}∗ only if the message satisfies the policy i.e.
f(x) = 0. In attribute-based signatures each key is associated with an attribute
x ∈ {0, 1}∗ and a key skx can sign a policy f only if the attribute satisfies
the policy i.e. f(x) = 0. A constrained signature can be easily transformed into
an attribute-based signature using universal circuits (which we denote Ux) as
briefly explained in [KY19] (but not done there), transformation that we apply
in Section 3 and that we sketch below.

The ABS scheme (as well as the original constrained signature of [Tsa17])
is built from lattice trapdoors. The verification key vk consists of a uniformly

sampled matrix
−→
A = [A1‖...‖A`] ∈ Zn×(m×`)

q (with ` the input size of the
circuit C) and a close to uniform matrix A ∈ Zn×pq while the master signing
key msk is a trapdoor for A denoted A−1

Îł0 . The signing key skxi is associated to
an user i (we prefer the simplified version of this notation even though it would
be clearer to use skUxi as notation) and to an universal circuit Uxi (which has
the attribute hard-wired and takes as input the policy (circuit) and a message).

The secret key skxi is a trapdoor [A‖Axi ]
−1
Îł where Axi =

−→
A ¡HUxi

∈ Zn×mq is

5



computed from
−→
A and Uxi using the function EvalF. This function, associated

with a function EvalFX, allows to compute HUxi
= EvalF(Uxi ,

−→
A), and HUxi ,x

=

EvalFX(Uxi ,x,
−→
A) both in Z(`m)×m and of bounded norm such that (

−→
A−x⊗G)·

HUxi ,x
=
−→
A ¡HUxi

−Uxi(x)G mod q, where G is the gadget matrix. Then, the

manager can easily generate the secret key skxi using it’s own trapdoor A−1
Îł0 . A

valid signature for a messageM , a circuit C and an attribute xi is a short vector σ

such that [A‖
−→
A−xi⊗G]·σ = 0 mod q. We note that for every tuple (C,M, xi),

a trapdoor [A‖
−→
A−xi⊗G]−1

γ′ can be derived from [A‖
−→
A−Uxi(C,M)G]−1

γ′ when
Uxi(C,M) = C(xi) = 0.

We remark that, at this stage, the unforgeability of the ABS can be eas-
ily broken, as explained in [KY19] because the message is not bounded to the
signature (both signature and verification just ignore the message) and a valid
signature for a pair of policy and message (C,M) is also valid for (C,M ′) for
M 6= M ′. Therefore, in the security game, we can not allow signature queries
and following the idea of [KY19], we use the fact that a scheme that is unforge-
able only when the adversary can not make signature queries can be generically
transformed into a scheme that is unforgeable even when the adversary is al-
lowed to make signature queries. In short, the idea in [KY19] is to answer the
signing queries using the secret key of a dummy user which does not exist in
the real system. We will need to partition the set of all possible message-policy
pairs into a challenge set and a controlled set (using admissible hash functions)
with the hope that the adversary asks queries that fall into the controlled set to
which the challenger can answer with the help of the dummy key. We also hope
that the attacker outputs a forgery in the challenge set to allow the simulator
to solve a hard problem.

Forward Secure Group Signature of [LNWX19]. Recall that for achieving
forward-secure group signature, one needs a one-way key evolving mechanism
for deriving secret keys for every period of time. Let us now briefly explain this
mechanism following the idea of [LNWX19]. Let T = 2d be the total number
of time periods, the time periods are represented in a binary tree, where each
time period is a leaf of the tree. Each user secret key for a time period t is then
associated with a sub-tree of depth d which uniquely defines the time period
t. Let z be a binary string (corresponding to a time period) of lenth dz. The
set Nodes(t←T−1) contains nodes for which bases (trapdoors) are derived at a
current period of time t and which allow to compute subsequent keys in the
key update algorithm using the bonsai tree technique [CHKP10]. Each user
will have associated a matrix corresponding to period time z ∈ Nodes(t←T−1):

Axi,z = [A‖Axi‖T
z[1]
1 ‖· · · ‖Tz[dz ]

dz
] where the last dz matrices corresponding to

the bits of dz are public. Therefore, the group signing key of user i at time t is
{Si||z, z ∈ Nodes(t←T−1)} which satisfies Axi,z ·Si||z = 0 mod q. The user is then
able to compute all possible Si||t by employing Si||z if z is an ancestor of t where
t is the binary representation of a period of time. The basis delegation technique

6



allows users to compute trapdoor matrices for all the descendent nodes in the
set Nodes(t←T−1) and therefore to compute all the subsequent signing keys.

1.3 Our construction

We are now able to better explain our contribution. We start from the con-
strained signature of Tsabary, we transform it in an ABS (according to [KY19]
suggestion) as previously explained, we equip it with forward-security (following
the mechanism of [LNWX19]), then plug it into the group signature of [KY19].
Thus we achieve the first forward-secure group signature from lattices without
NIZK in the standard model having public key and signature size independent of
the number of users for which we managed to prove forward-secure traceability
and CCA-selfless anonymity. The drawback is that the security assumption on
which the GS scheme relies is SIS with subexponential hardness.

Our main building block is then a forward secure Attribute Based Signature
which is built using the idea from [LNWX19] having as starting point Tsabary’s
constrained signature. As explained in [LNWX19], the advantage of this method
is that it incurs only logarithmic dependency on T . Therefore our construction
achieves signature size and public key size constant in N and logarithmic in T .
We note that [LNWX19] applied it directly for building forward-secure group
signature (FS-GS) while we need to apply it first on our ABS to get forward-
secure attribute-based signatures (FS-ABS). Indeed, in an encrypt-then-prove
paradigm for group signatures, the transformation of [LNWX19] into a forward
secure group signature is independent of the encryption scheme and of the NIZK
scheme used to prove the membership. This is because the group secret key of a
user does not appear as input in the NIZK proof but is embedded in a ciphertext
on which the proof is performed. Instead, the paradigm on which we build our
construction uses an ABS to prove that the user belongs to the group, and the
ABS secret key is a direct component of the group secret key of a user. This
means that if we want to update the group secret key of a user, we need to
update the ABS secret key as well.

From this observation and the fact that the ABS built by Tsabary [Tsa17]
is based on lattice trapdoors which fit perfectly with bonsai trees, we can then
adapt the forward security mechanism of [LNWX19] to the ABS derived from
[Tsa17], and use the resulting ABS to get forward-secure group signature scheme.
We note that if we try to apply the same technique for the second ABS from
[KY19] (also built from lattice trapdoors) we can not get forward-security. The
problem is that the design of ABS forces us to keep the initial secret key derived
by the master authority for every user in order to be able to compute all the
other subsequent keys for the following periods of time. This means that an
adversary who gains access to a secret key for a certain period of time, would be
able to compute the secret keys for all periods of time (including previous ones).

The main difficulty encountered when trying to add forward security to the
ABS derived from [Tsa17] is then the way to deal with the trapdoors for each
of the time periods. This includes the trapdoors considered in the ABS con-
struction as well as in the simulation. Moreover this modification induces a new

7



time parameter t, that has to be handled in the unforgeability proof. Indeed,
the construction of [Tsa17] has been designed to only consider a fixed matrix

A and a vector of matrices
−→
A linked to the attribute to generate and verify

signatures. But now we add log t additional matrices in order to integrate the
time parameter, in a similar way to [LNWX19]. This transformation implies that
the secret keys have to be modified according to the time period considered. It
means that a trapdoor update mechanism needs to be built from the trapdoor
construction of Tsabary, using tools introduced in the bonsai tree mechanism
[CHKP10], and the time component has to be dealt with in the different queries
from the simulation-based proof.

Finally, as we apply forward-secure property to an attribute-based construc-
tion in our case, we also have to handle an additional component which is the
attribute. A naive adaptation from the transformation of [LNWX19] (on a group
signature) to our construction (an attribute based signature) would not be se-
cure. Indeed, we have to deal with two types of trapdoor: the trapdoor inherent
to the ABS construction derived from [Tsa17], and the trapdoors given by the
matrices linked to the time parameter. In the security proof of the ABS scheme,
we need to simulate these two types of trapdoors according to each other, and
according to the time period considered, in order to be able to answer all the
queries of an attacker. At the same time, we expect all these trapdoors to vanish
when the forgery of the attacker is outputted, in order to be able to conclude
the simulation and then to argue about the security reduction getting a solution
to a hard problem.

Related work. The only previous work on forward-secure group signature
schemes from lattices is the work of [LNWX19] in the random oracle model using
NIZK achieving signature size Õ(Ν(log N + log T )) and group public key size
Õ(Ν2(log N + log T )). Our scheme is constant in the number of group members
and logarithmic in the number of time periods i.e. Õ(Νlog T ) and group public
key size Õ(Ν2log T ). Their scheme satisfies full-anonymity and forward-secure
traceability under SIS and LWE hardness.

Open problems. One open problem would be to achieve a group signature
scheme with the same properties without relying on complexity leveraging (that
we need to employ in the underlying ABS). Another open problem would be to
upgrade the anonymity property from selfless anonymity to full anonymity.

2 Preliminaries

2.1 Lattices and trapdoors

In this paper we use several values defined as follows: Îť is the security parameter
and n, m and q ≥ 2 are integers such that n = poly(λ) and m ≥ nd log qe. The
discrete Gaussian distribution DZm,τ over Zm with parameter τ is the distribu-

tion where the probability of all x is proportional to e−π‖x‖/τ
2

. The norm of a

8



matrix A = [a1, . . . ,am] ∈ Zn×mq , is denoted ‖A‖= maxj‖aj‖, j ∈ [m], and it is
the maximum of the Euclidean norm of its vectors.

Lattices. For a matrix A ∈ Zn×mq and u ∈ Znq that admits a solution to the

equation A ·x = u mod q, define the m-dimensional lattice: Λ⊥(A) = {x ∈ Zm :
A · x = 0 mod q} ⊆ Zm, and the coset Λ⊥u (A) = {x ∈ Zm : A · x = u mod q}.

We briefly remind the SIS assumption and its hardness.

Definition 1 (SISn,q,B,m). Given a uniformly chosen matrix A ∈ Zn×mq , find
nonzero integer vector s ∈ Zm such that ‖s‖∞≤ B and A · s = 0 mod q. SISn,q,B,m
is hard if for any adversary A, the probability to solve SIS is negligible, i.e. it
is bounded by negl(Îť). SISn,q,B,m is sub-exponentially hard if the probability to
solve SIS is bounded by 2−O(nε) · negl(λ) for some constant 0 < ε < 1.

Trapdoors. For all v ∈ Znq , A−1
Îł0 (v) is the random variable with discrete gaus-

sian distribution DZm,γ0 conditioned on A ·A−1
Îł0 (v) = v mod q. A Îł0-trapdoor

for A allows a procedure that can sample from A−1
Îł0 (v) in time poly(n,m, log q)

for any v ∈ Znq . By overloading notation we denote a γ0-trapdoor for A by A−1
Îł0 .

We define the gadget matrix G based on the vector g ∈ Zkq whose entries are

the power of two gt := [1 2 4 · · · 2k−1] and k = dlog qe. The matrix G is
the diagonal concatenation of g n times, i.e. G = g ⊗ In ∈ Zn×nkq .

Lemma 1 (Trapdoor generation [Ajt96,MP12]). There exists an efficient
procedure, that we call TrapGen(1n, 1m, q), with an efficiently computable value
m0 = O(n log q) such that for all m > m0 outputs a pair (A,A−1

Îł0 ), where
A ∈ Zn×mq is at negligible distance from uniform and A−1

Îł0 is a Îł0-trapdoor for

A with Îł0 = O(
√
n log q log n).

Lemma 2 (Leftover Hash Lemma [HILL99]). Let m,n, q > 1 be integers

such that m > 4n log q and q prime. Let A
$←− Zm×nq , r

$←− {0, 1}m, then (A,Ar)
is at negligible statistical distance from uniform distribution on Zm×nq × Znq .

2.2 Delegation functions

During different time periods, a signer will need to delegate some lattice trapdoor
from a previous period to a next one. We make use of the following lemmas.

Lemma 3 (Trapdoor extension [ABB10,MP12]). Let ∈ Zn×mq be a ma-
trix with trapdoor M−1

γ and N ∈ Zn×pq a matrix such that M = NS mod q where
S ∈ Zp×mq with s1(S) its largest singular value. Then we can use (M−1

Îł ,S) to

sample from N−1
γ′ for any γ′ ≥ γ · s1(S).

Lemma 4 ([CHKP10, Lemma 3.2]). There is a deterministic polynomial-
time algorithm ExtBasis with the following properties: given an arbitrary A ∈
Zn×mq whose columns generate the entire group Znq , an arbitrary basis S ∈ Zm×m

of Λ⊥(A), and an arbitrary Ā ∈ Zn×m̄q , ExtBasis(S,A′ = A‖Ā) outputs a basis

S′ of Λ⊥(A′) ⊆ Zm+m̄ such that ‖S̃′‖= ‖S̃‖. Moreover the same holds even for
any permutation of the columns of A′.

9



There exists a function RandBasis developed by [CHKP10], which verifies
the following lemma:

Lemma 5 ([CHKP10, Lemma 3.3]). Let S be a basis of a m-dimensional
integer lattice Λ and a parameter s ≥ ‖S̃‖·ω(

√
log n). The algorithm

RandBasis(S, s) outputs a new basis S′ of Λ such that, with overwhelming prob-
ability, S′ verifies ‖S′‖6 s ·

√
m. Moreover, for any two basis S0,S1 of the same

lattice and any s > max{‖S̃0‖, ‖S̃1‖}·ω(
√

log n), the outputs of RandBasis(S0, s)
and RandBasis(S1, s) are within negl(n) statistical distance.

We further need an important property of lattice trapdoors ([ABB10],[MP12]):

Lemma 6. For A ∈ Zn×pq and R ∈ Zp×mq with m = ndlog qe, one can compute
[A‖AR + G]−1

Îł for Îł = O(
√
mp ‖R‖∞).

2.3 Evaluation functions

In order to generate or check the validity of a signature, we need to execute
some evaluation of a function with a set of lattices as input. The output of this
evaluation is 1 if the function evaluated on an attribute x is not valid and 0 if
the evaluation is correct. We use the notations and definition of the evaluation
functions developed by Tsabary [Tsa17]. Moreover we denote [x1G|¡ ¡ ¡ |x`G] by
x⊗G with x = (x1, · · · , x`) ∈ {0, 1}`.

Theorem 1 ([Tsa17, Theorem 2.7]). There exist efficient deterministic al-
gorithms EvalF and EvalFX such that for all n, q, ` ∈ N, m = ndlog qe, and for

any sequence of matrices
−→
A = (A1, · · · ,Al) ∈ (Zn×mq )`, for any depth d boolean

circuit f : {0, 1}` → {0, 1} and for every x = (x1, · · · , x`) ∈ {0, 1}`, the outputs

Hf = EvalF(f,
−→
A), and Hf,x = EvalFX(f,x,

−→
A) are in Z(`m)×m and it holds that

‖Hf‖∞, ‖Hf,x‖∞6 (2m)d and (
−→
A − x⊗G) ·Hf,x =

−→
A ·Hf − f(x)G mod q.

As in [KY19], we employ secret key encryption (SKE) and one-time
signature (OTS), both from lattices, in order to build our group signature
scheme. We use the SKE scheme based on LWE from [KY19], which is a secret
key variant of [Reg05] and the OTS scheme from [Moh10]

2.4 Secret Key Encryption (SKE) from LWE

In this subsection we present the secret key encryption scheme from LWE defined
by [KY19]. Recall that we need SKE for our both proposals for group signature
scheme. The SKE scheme described below is IND-CPA secure and has a decryp-
tion circuit with O(log Îť)-depth. We mention that for the security of the group
signature schemes that we presented in this paper, we need IND-CCA security
which can be achieved from IND-CPA security and message authentication codes
(MAC) scheme by a generic construction as explained in [KY19].

The SKE scheme below is a secret key variant of the Regev’s scheme [Reg05].
The parameters of the s";"""date"",""2020-12-03T14:11:36Z""
""pdf:PDFVersion"",""1.4""
""pdf:docinfo:title"",""Constant-Size Lattice-Based Group Signature with Forward Security in the Standard Model""
""xmp:CreatorTool"",""HAL""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""Computer Science [cs]/Cryptography and Security [cs.CR]""
""language"",""en""
""dc:format"",""application/pdf; version=1.4""
""pdf:docinfo:creator_tool"",""HAL""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""Constant-Size Lattice-Based Group Signature with Forward Security in the Standard Model""
""modified"",""2020-12-03T14:11:36Z""
""cp:subject"",""Computer Science [cs]/Cryptography and Security [cs.CR]""
""pdf:docinfo:subject"",""Computer Science [cs]/Cryptography and Security [cs.CR]""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""SĂŠbastien Canard, Adela Georgescu, Guillaume Kaim, Adeline Roux-Langlois, Jacques TraorĂŠ""
""PTEX.Fullbanner"",""This is MiKTeX-pdfTeX 4.0.1 (1.40.21)""
""meta:author"",""SĂŠbastien Canard, Adela Georgescu, Guillaume Kaim, Adeline Roux-Langlois, Jacques TraorĂŠ""
""trapped"",""False""
""meta:creation-date"",""2021-04-22T08:47:10Z""
""created"",""2021-04-22T08:47:10Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2021-04-22T08:47:10Z""
""resourceName"",""LBGroupSignFS.pdf""
""Author"",""SĂŠbastien Canard, Adela Georgescu, Guillaume Kaim, Adeline Roux-Langlois, Jacques TraorĂŠ""
""producer"",""PDFLaTeX""
""pdf:docinfo:producer"",""PDFLaTeX""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""2"",""1"",""0"",""0"",""6"",""13"",""0"",""4"",""25"",""34"",""20"",""19"",""0"",""0"",""6"",""18"",""48"",""33"",""7"",""49"",""0"",""3"",""5"",""4"",""14"",""24"",""0"",""0"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""SĂŠbastien Canard, Adela Georgescu, Guillaume Kaim, Adeline Roux-Langlois, Jacques TraorĂŠ""
""dcterms:created"",""2021-04-22T08:47:10Z""
""Last-Modified"",""2020-12-03T14:11:36Z""
""dcterms:modified"",""2020-12-03T14:11:36Z""
""title"",""Constant-Size Lattice-Based Group Signature with Forward Security in the Standard Model""
""Last-Save-Date"",""2020-12-03T14:11:36Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2020-12-03T14:11:36Z""
""meta:save-date"",""2020-12-03T14:11:36Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is MiKTeX-pdfTeX 4.0.1 (1.40.21)""
""Content-Length"",""728887""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""SĂŠbastien Canard, Adela Georgescu, Guillaume Kaim, Adeline Roux-Langlois, Jacques TraorĂŠ""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""31""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""1039"",""2150"",""2863"",""2579"",""2897"",""2832"",""2620"",""2747"",""2374"",""2207"",""2159"",""1722"",""2015"",""2414"",""2249"",""2366"",""1518"",""1740"",""2406"",""2349"",""2282"",""1748"",""2183"",""2010"",""2166"",""2408"",""2365"",""2184"",""2591"",""2823"",""815""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2021-04-22T08:47:10Z""
";https://scholar.google.ch/scholar?start=620&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098734-31;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;[CITATION][C] Blockchain. Ein alternatives Datenbanksystem?: Vergleich und Evaluation der verschiedenen Datenbanksysteme;T Todd ;2020 GRIN Verlag;;null;Autres articles;;null;;;;https://scholar.google.ch/scholar?start=580&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098875-353;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;[PDF][PDF] Coin Tossing with Lazy Defense: Hardness of Computation Results.;HA Khorasgani, HK Maji, M Wang ; IACR Cryptol. ePrint Arch., 2020  eprint.iacr.org;;"… Without this new perspective, one can only argue an insecurity of 1/??(d2 ) = O(1/d), which is

too small to imply anything consequential for coin-tossing in the random oracle model. Maji and

Wang [MW20] (to appear in CRYPTO–2020) use our proof technique and the potential …";Cité 4 fois;;[PDF] iacr.org;https://eprint.iacr.org/2020/131.pdf;"
Coin-tossing with Lazy Defense

Hamidreza Amini Khorasgani Hemanta K. Maji Mingyuan Wang

Abstract

There is a significant interest in securely computing functionalities with guaranteed output
delivery, a.k.a., fair computation. For example, consider a 2-party n-round coin-tossing protocol
in the information-theoretic setting. Even if one party aborts during the protocol execution,
the other party has to receive her outcome. Towards this objective, every round, the sender
of that round’s message, preemptively prepares a defense coin, which is her output if the other
party aborts prematurely. Cleve and Impagliazzo (1993), Beimel, Haitner, Makriyannis, and
Omri (2018), and Khorasgani, Maji, and Mukherjee (2019) show that a fail-stop adversary can
alter the distribution of the outcome by Ω(1/

√
n). This hardness of computation result for

the representative coin-tossing functionality (using a partition argument) extends to the fair
evaluation of any functionality whose output is not apriori fixed and honest parties are not in
the majority.

However, there are natural scenarios in the delegation of computation where it is infeasible for
the parties to update their defenses during every round of the protocol evolution. For example,
when parties delegate, say, their coin-tossing task to an external server, due to high network
latency, the parties cannot stay abreast of the progress of the fast protocol running on the server
and keep their defense coins in sync with that protocol. Therefore, this paper considers lazy
coin-tossing protocols, where parties update their defense coins only a total of d times during the
protocol execution. Is it possible that using only dďż˝ n defense coin updates, a fair coin-tossing
protocol is robust to O(1/

√
n) change in their output distribution?

Our work highlights the necessity to distinguish protocols with publicly-measurable defense
update strategies and protocols with private defense update strategies. In a publicly-measurable
defense strategy, the decision of a party to update her defense coin depends solely on the public
transcript of the two-party protocol. On the other hand, in a protocol with private defense
strategy, the adversary cannot predict with certainty the partial transcripts where the honest
party updates her defense coins. That is, the decision to update one’s defense coin non-trivially
depends on the party’s private randomness.

Our work, for publicly-measurable defense update strategies, proves that a fail-stop adversary

can bias the outcome distribution of a coin-tossing protocol by Ω
(

1/
√
d
)

, a qualitatively better

attack than the previous state-of-the-art when d = o(n). We emphasize that the rounds where
parties calculate their defense coins need not be apriori fixed; they may depend on the protocol’s
evolution itself. This hardness of computation results extends to the fair evaluation of any
functionality (possibly, stateful and with inputs) whose output has entropy and the honest parties
are not in a majority. Finally, we translate this fail-stop adversarial attack into new black-box
separation results.

To complement this hardness of computation result, our paper presents a coin-tossing pro-
tocol with a private defense update strategy. This protocol uses d = n1−λ defense updates (in
expectation) to achieve O(1/

√
n) robustness, where Îť is an appropriate positive constant.

The proof relies on an inductive argument using a carefully crafted potential function to
precisely account for the quality of the best attack on coin-tossing protocols. Previous approaches
fail when the protocol evolution reveals information about the defense coins of both the parties,
which is possible in lazy coin-tossing protocols. Technically, the potential function enables the
characterization of a “data processing inequality” that holds for communication protocols only;
and not for arbitrary distributions in general.



1 Introduction

Guaranteed output delivery is a desirable attribute of secure computation protocols. Secure com-
putation of functionalities with guaranteed output delivery, a.k.a., fair computation, ensures that
even if a party aborts during the execution of the protocol, the other party still obtains her output.
Defining security and constructing secure protocols in this setting for general functionalities has
been a field of highly influential research [Cle86, CI93, GHKL08, GK10, BLOO11, ALR13, Ash14,
Mak14, ABMO15]. The security requirements of fair computations are extraordinarily stringent,
and understanding the limits of achievable security for various models of adversarial power is a
fundamental research problem.

The information-theoretic setting, where parties have unbounded computational power, achiev-
ing security even against fail-stop adversaries, i.e., adversarial parties follow the protocol honestly
and sometimes abort the computation prematurely to change the final output distribution, the
characterization of achievable security for various functionalities is already sufficiently sophisticated.
For example, if the adversary can corrupt a majority of the parties in an n-round fair computation
protocol for a functionality whose output is not apriori fixed, then the adversary can change the
protocol’s output distribution by Ω(1/

√
n) [CI93, BHMO18, KMM19]. This work delves further

into this line of research and analyzes of the impact of the attributes of interactive protocols on
achievable security in fair computation. This work studies the 2-party fair coin-tossing functionality
as a representative fair computation task, and the hardness of computation result in this context
shall lift to any arbitrary fair computation of multi-party functionalities where honest parties are
not in the majority using a partition argument.

This paper motivates and makes a case for a more fine-grained characterization of how honest
parties prepare to defend against an adversarial party who aborts during the protocol execution.
We motivate this study using the representative task of delegating the task of secure coin-tossing
protocols.

Alice

Bob

Cloud Service
Coin-tossing Protocol Progression

of Time

Alice’s Process

Bob’s Process

Signaling the attack

Alice’s Process’ intermediate local state

Bob’s Process’ intermediate local state

DDOS Attack

on Alice by Bob

Figure 1: Illustration of Alice and Bob delegating their coin-tossing task to a cloud service when
the honest party is vulnerable to a DDOS attack.

Representative Motivating Problem. Refer to Figure 1 for the discussion below. Alice and
Bob are interested in upgrading their local private independent randomness into shared random coins
for a time-sensitive application (for example, auctions, lotteries); each coin is heads (independently)
with probability X0. Instead of undertaking this interactive task themselves, they delegate it to a

2



cloud computing environment. This cloud computing environment spawns two processes to generate
each shared coin (one on behalf of Alice and one on behalf of Bob) and runs one instance of an
n-round 2-party coin-tossing protocol between these two processes. Delegating this task to a cloud
environment allows choosing an enormous value of n because the communication between the two
processes shall be significantly-fast; consequently, the protocol has the potential of achieving higher
security. Alice provides the private random coins for Alice’s process, and Bob provides the private
random coins for Bob’s process. Upon the protocol’s completion, Alice’s process reports its output
back to Alice and, likewise, Bob’s process reports its output back to Bob.

However, there is a threat that the adversary, based on its process’ signal, launches a DDOS
attack on the honest party, interrupting all communication between her and her process. This attack
may result in the complete loss of the computation because the DDOS attack may only get resolved
after the time-sensitive application’s deadline has passed. The processes defend against the complete
loss of their computation by reporting back their intermediate local state every t rounds to safeguard
their computation’s partial progress. Ideally, one would like to set t = 1 to keep Alice/Bob abreast
of the coin-tossing protocol’s progress. Reporting back frequently to Alice/Bob introduces network
latency that is multiple orders of magnitude larger than the coin-tossing protocol’s low latency
(see, for example, https://gist.github.com/hellerbarde/2843375). Inevitably, by the time Alice/Bob
receive their defense coin, the coin-tossing protocol would have already progressed significantly
ahead. Consequently, only large values of t are achievable.

Given n, t, and X0, the insecurity of any coin-tossing protocol instance is the maximum change
in the output distribution that the adversary causes by blocking the communication between the
honest party and her process. In this scenario, the following questions are but natural. How much
insecurity (as a function of n, t, and X0) should Alice and Bob anticipate? Equivalently, given a
particular tolerance for security failure, how frequently should Alice and Bob update their defense
coins? More fundamentally, what if t was randomized and chosen by a process based on her private
randomness?

Looking ahead. We distinguish between two forms of defense update strategies (a) publicly-
measurable, and (b) private strategies. Before proceeding further, it is instructive to highlight
the difference between these two strategies. In a publicly-measurable defense update strategy, the
decision to update a party’s defense coin in a particular round depends solely on the public transcript
of the protocol. For example, given a partial transcript of the protocol, one can compute with
certainty whether a party shall update her defense coin or not. We emphasize that the updates
need not take place at apriori fixed rounds. The defense update round may possibly depend on the
protocol evolution; nevertheless, it depends solely on the protocol evolution.

On the other hand, a private defense update strategy relies on its entire view (the public tran-
script and private randomness) to determine whether to update her defense coin. So, for instance,
it is possible that, given the protocol evolution, the adversarial party may only be able to compute
the probability that the honest party updates her defense in that particular round.

All previous works [CI93, BHMO18, KMM19] study publicly-measurable defense update strate-
gies and for the particular case of t = 1. They prove that the insecurity in the coin-tossing protocol
mentioned above (qualitatively) behaves as X0(1−X0)√

n
. These bounds leave open the possibility that

one might increase the time t between updating defenses (a.k.a., parties lazily update their defenses)
without sacrificing the security of the protocol. Existing proof techniques break down entirely when
the evolution of the coin-tossing protocol between consecutive updates of Alice’s and Bob’s defense
coins reveals information about both of their defense coins, which is indeed possible for t > 2 (see
Figure 5 for a concrete example). To circumvent this challenge, we introduce a new inductive proof

strategy demonstrating that the insecurity is at least X0(1−X0)√
n/t

, a qualitatively better lower bound

3

https://gist.github.com/hellerbarde/2843375


when t = ω(1). Note that d := n/t, referred to as the defense complexity of the protocol, is the total
number of defense coins received by Alice and Bob during the protocol execution. In general, we
demonstrate that the defense complexity of the protocol, not the round complexity, is key to deter-
mining the insecurity of a coin-tossing protocol with publicly-measurable defense update strategies.
In particular, our result implies that a high round-complexity coin-tossing protocol is vulnerable if
parties do not frequently update their defense coins.

To complement this result, we present a coin-tossing protocol with private defense update strat-
egy with defense complexity d = n1−λ (except with exponentially low probability) that achieves
1/
√
n-insecurity, where Îť is a positive constant.
A technical bottleneck. Consider a coin-tossing protocol with publicly-measurable defense

update strategy. The approach of Cleve and Impagliazzo [CI93] (and other similar techniques [BHMO18,
KMM19]) encounters the following bottleneck. One can interpret any coin-tossing protocol as a
Doob’s martingale with respect to the filtration induced by the information exposed until the rounds

where parties update their defense coins. Although there exists an Ω
(

1/
√
d
)

gap in this martingale,

the technique of Cleve and Impagliazzo [CI93] fails to materialize this gap in the martingale into a
fail-stop attack on the coin-tossing protocol. Their transference argument crucially relies on the fact
that the message recipient’s expected defense coin does not change during the information exposure.
In a lazy coin-tossing protocol, the information exposure spans multiple rounds in the coin-tossing
protocol involving messages from both the parties. These messages in the protocol may divulge
information about the defense coins of both parties as well. Consequently, the crucial invariant that
Cleve and Impagliazzo [CI93] rely upon does not hold for coin-tossing protocols with lazy defense.
Section 1.1 further elaborates on the subtlety of this technical challenge.

The case of private defense update strategies. Our work complements our hardness of
computation results by presenting a coin-tossing protocol with a private defense update strategy that
is robust to 1/

√
d change in the output distribution using only d1−λ defense updates, where λ is an

appropriate positive constant. Section 6 presents this protocol. Private defense strategies have the
benefit that the adversarial party cannot determine whether the honest party updated her defense
coin in a particular round or not. However, the decision to update the defense coin in a round by
the honest party depends deterministically on her private view, i.e., the public trancript and private
randomness.

Subsequent success story. Maji and Wang [MW20] use our proof technique and the potential
function to extend the hardness of computation result in this work to the random oracle model. This
extension implies the qualitative optimality of the security achieved by the coin-tossing protocol of
Blum [Blu82] and Cleve [Cle86] that uses one-way functions in a black-box manner, thus positively
resolving a longstanding open problem.

Extensions: Our Potential Argument and Data processing Inequality. We guide
the discussion on this topic using the representative example of fair coin-tossing protocols with
publicly-measurable defense update strategy. Suppose the adversary knows that the honest party
just updated her defense in round r, and shall next update her defense only at a later round r′.1

When should the adversary attack?
Data processing inequality suggests, that the adversary should wait until just before the round

r′ to perform the most devastating attack. Formally, suppose the state of the protocol at the end of
round-r is S. It evolves to states S1, S2, . . . , Sk with probability p1, p2, . . . , pk just before round r′.
Let Φ(S) ∈ R represent (the “quality” of) the best attack when the protocol has state S. Similarly,
for 1 6 i 6 k, ÎŚ(Si) represents the best attack when the protocol has state Si. So, the expected
quality of the attack when waiting is

∑k
i=1 pi ¡Ό(Si) = E[Ό(Si)]. Consequently, the potential function

1We emphasize that the round r′ might be random variable depending on the evolution of the protocol.

4



has to respect the following inequality.

ÎŚ(S) = ÎŚ(E[Si]) > E[ÎŚ(Si)].

Our work introduces the potential function Φ(x, a, b) := x(1−x)+(x−a)2+(x−b)2.Interestingly,
this potential function is not convex, and, in general, the inequality above is false. However,
our work shows that, it satisfies the inequality above if the state S evolves into the states Si’s
via a communication protocol. This innovation of using a potential function Ό(¡) to control the
performance of an adversary’s attack in communication protocols is an entirely new approach to
such problems in the information-theoretic model.

The subsequent work of [MW20] leverages our potential function to lift our attack from the
information-theoretic world to their information-theoretic random oracle model. We believe that, in
general, our potential function can serve as a conduit to lift information-theoretic attack on protocols
to an appropriate relativized setting. For example, there are several open oracle-separation problems
(like, separating optimal fair coin-tossing from public-key agreement) such that their corresponding
problem in the information-theoretic setting is already resolved.

1.1 Discussion on Previous Approaches

Consider a 2-party n-round coin-tossing protocol such that the probability of the outcome being 1
is X0, and the probability of the outcome being 0 is 1 −X0. Let X = (X0, X1, . . . , Xn) represent
the Doob’s martingale corresponding to this protocol where Xi represents the expected outcome
conditioned on the first i messages of the transcript. Note that Xn ∈ {0, 1}, because at the end of
the protocol, both parties agree on the outcome being 0 or 1 with certainty. Previous works [CI93,
KKR18, BHMO18, KMM19] prove the existence of a (randomized) round τ ∈ {1, 2, . . . , n} such

that the expected magnitude of the gap |Xτ −Xτ−1| is Ω
(
X0(1−X0)√

n

)
. We clarify that the round τ

being randomized implies that it can depend on the partial transcript generated during the protocol.
Such a round τ , intuitively, is susceptible to attacks because there is a significant gap between the
knowledge of the two parties regarding the (expected) outcome of the protocol. [BHMO18] has the
additional advantage that the attack is efficient for multiple parties.

In fair coin-tossing protocols [Cle86, CI93, GHKL08] (i.e., coin-tossing protocols with guaranteed
output delivery), if one of the parties aborts prematurely, then the other party still has to output
0 or 1. Intuitively, the two parties carry defense coins, which they regularly update as the protocol
progresses. If a party aborts, then the other party outputs her defense coin. Without loss of
generality, one can assume that the parties update their defense coin as part of their next message
computation in the protocol execution. For example, without loss of generality, assume that Alice
plays the role of the party that sends the first message in the coin-tossing protocol. Then, Alice
updates her defense coin every odd round, and Bob updates his defense coin every even round.

A crucial property of information-theoretic protocols is the following. The expectation of Alice’s
defense coin (conditioned on the partial transcript) does not change after Bob sends the next message
in the protocol, and (likewise) the expectation of Bob’s defense coin does not change after Alice
sends the next message in the protocol. For example, the expected value of Bob’s defense coin
immediately before and after Alice sends her message in round 3 is the same. Previous works
consider the message exposure filtration {∅, T } = M0 ⊆ M1 ⊆· · · ⊆ Mn = 2T corresponding to the

protocol.2 They identify the susceptible (randomized) round τ witnessing an Ω
(
X0(1−X0)√

n

)
gap in

2The set T represents the set of all possible transcripts in the protocol. The set 2T represents the set of all possible
subsets of T .

5



Rounds

1

2

3

4

5

6

n

...

Defense
Rounds

i3

i2

i1

F1 F2 F3 F4

τ τ ′

•

•

•

••

•

Figure 2: The tree represents the protocol tree of the coin-tossing protocol. Gray dotted lines
represent the n rounds of the protocol. The dashed lines represent the d = 3 defense rounds. Any
complete protocol execution (root to leaf path in the tree) encounters the defense rounds i1, i2,
and i3 in that particular order. For example, we consider two transcripts τ and τ ′, and illustrate
that they encounter i1, i2, and i3 in that order. The σ-fields F1, F2, and F3 expose messages till
encountering i1, i2, and i3, respectively. The σ-field F4 reveals the entire protocol transcript.

the martingale. Next, they use this round τ as a template to identify a fail-stop attack on the coin-

tossing protocol and change the output distribution by Ω
(
X0(1−X0)√

n

)
. This transference crucially

relies on the fact that the expectation of the defense coin of the receiver in round τ immediately
before and after the τ -th message is identical.

Now consider the scenario where parties update their defense coins lazily. Suppose the parties
update their defenses in rounds 1 6 i1 < i2 < ¡ ¡ ¡ < id 6 n. We clarify that the rounds {i1, i2, . . . , id}
can be randomized as well, i.e., they depend on the partial transcripts during the protocol execution,
refer to Figure 2. Furthermore, note that the parity of the round ik implicitly identifies the party
updating her defense coin. The randomized defense rounds are very natural to consider. For
example, continuing the motivating example from the introduction, the next message computation
of a delegated protocol may depend on the partial transcript of the delegated protocol. If, for
instance, the protocol evolves into a state where the next-message-generation becomes extremely
time consuming for the processes of the cloud, then Alice and Bob can use this opportunity to
reduce their lag in the knowledge of the protocol’s evolution.

Suppose one considers the message exposure filtration {∅, T } = M0 ⊆M1 ⊆· · · ⊆Mn = 2T , then
the fail-stop attack shall ensure that the output distribution changes only by Ω(X0(1−X0)/

√
n).

On the other hand, one can instead consider the filtration {∅, T } = F0 ⊆ F1 ⊆ · · · ⊆ Fd ⊆
Fd+1 = 2T , where Fk (for 1 6 k 6 d) corresponds to exposing all the protocol messages up to
(the randomized) round ik, and Fd+1 represents exposing the full transcript. We emphasize that

6



the σ-field Fk may simultaneously expose multiple rounds of messages sent by both the parties in
addition to the messages already exposed by Fk−1. Let Y = (Y0 = X0, Y1, . . . , Yd, Yd+1) represent
the martingale such that Yk is the expectation of the outcome conditioned on the first ik messages
in the protocol. Note that Yd+1 is the expected outcome at the end of the protocol and, therefore,
we have Yd+1 ∈ {0, 1}.

Indeed, by applying [CI93, KKR18, BHMO18, KMM19], there exists a τ ∈ {1, 2, . . . , d, d+ 1}
for this filtration such that the gap in parties’ knowledge of the outcome between rounds iτ−1 and

iτ is Ω
(
X0(1−X0)/

√
d
)

. However, the transference of τ into a fail-stop attack on the coin-tossing

protocol fails. This failure is attributable to the fact that the expectation of the defense coins of both
parties may change between rounds iτ−1 and iτ because Fτ may expose messages by both parties
in addition to the messages already exposed by Fτ−1 (refer to Figure 5 and Figure 6 for concrete
examples).

Towards resolving this impasse, we employ a new potential function enabling an inductive proof
for this problem; generalizing the approach of Khorasgani et al. [KMM19]. This new proof consid-
ers the message exposure filtration {∅, T } = M0 ⊆ M1 ⊆ · · · ⊆ Mn = 2T while, simultaneously,
ensuring a fail-stop attack on (information-theoretic) coin-tossing protocols that changes their out-

put distribution by Ω
(
X0(1−X0)/

√
d
)

. Finally, these attacks naturally translate into black-box

separation results for (appropriately restricted-versions of) fair coin-tossing protocols as considered
in [DLMM11, HOZ13, DMM14].

Subsequent work. Maji and Wang [MW20] use our proof strategy and the potential function
to extend our result to coin-tossing protocols in the random oracle model. En route, they also
simplify the proof of our hardness of computation result.

Black-box separation. Several highly influential works [IR89, RTV04, BBF13] undertake the
nuanced task of precisely defining black-box separation and its subtle variations. In our context, we
rely on the fully black-box separation as introduced by Reingold, Trevisan, and Vadhan [RTV04].

Understanding whether one cryptographic primitive can be black-box constructed from another
primitive is a fundamental problem in theoretical cryptography [Rud92, Sim98, Rud88, KSS00,
KSS11, MM11, GKM+00, GMR01, GT00, GGK03, GGKT05, GMM07, BPR+08, Vah10, KSY11,
MMP14a, MMP14b, MMN+16, MM16, GMM17, GMMM18]. However, the most relevant works for
our context are those of [DLMM11, HOZ13, DMM14] that demonstrate the separation of optimal
fair coin-tossing from one-way functions under certain restrictions of the coin-tossing protocols.
Substituting the result of [CI93] with our Theorem 1 directly extends the black-box separations of
[DLMM11, HOZ13, DMM14] to coin-tossing protocols with lazy defense.

1.2 Our Contributions

A 2-party (n, d)-coin-tossing protocol with bias-X0 is an n-round 2-party coin-tossing protocol (with
output {0, 1}) such that the expected outcome of the protocol is X0, and parties update their defense
coins in d rounds. The defense complexity d is a function of the round complexity n. Furthermore,
the decision of a party to update her defense coin may depend on the partial transcript of the
protocol itself. A protocol is Îľ-unfair if there exists a fail-stop strategy for one of the parties to
deviate the output distribution of the honest party by Îľ in statistical distance. Our main result is
the following theorem.

Theorem 1 (Attacks on Coin-Tossing Protocol with Lazy Defense). There exists a universal positive
constant c, such that for any X0 ∈ [0, 1] and 2-party (n, d)-coin-tossing protocol with bias-X0 is (at
least) c ·X0(1−X0)/

√
d-unfair.

7



Before our result, we knew that 2-party (n, n)-coin-tossing protocol with bias-X0 is Ω(X0(1−X0)/
√
n)

unfair [CI93, BHMO18, KMM19]. Our work, motivated by interesting cryptographic applications
discussed in the introduction, decouples the round complexity and the defense complexity of coin-
tossing protocols for a more fine-grained study of fair coin-tossing functionalities. We show that
the defense complexity, not the round complexity, of coin-tossing protocols determines the security
of coin-tossing protocols. For example, a coin-tossing protocol with high round complexity but a
small defense complexity shall be very unfair. In particular, when d = o(n) it is impossible for an
n-round coin-tossing protocol to be O(1/

√
n)-unfair, for a constant X0 ∈ (0, 1).

Finally, this fail-stop attack on coin-tossing protocols in the information theoretic setting trans-
lates into black-box separation [IR89, RTV04] results. Existing techniques leverage the fail-stop
attack of Theorem 1 to rule out the construction of fair coin-tossing protocols by using one-way
functions in a black-box manner for a broad class of protocols.

Corollary 2 (Black-box Separation). There exists a universal positive constant c such that, for
any X0 ∈ [0, 1], there is no construction of a 2-party (n, d)-coin-tossing protocols with bias-X0 that
is < c ·X0(1−X0)/

√
d-unfair and uses one-way functions in a black-box manner (restricted to the

classes of protocols considered by [DLMM11, HOZ13, DMM14]).

When d = o(n), our corollary provides new black-box separation results that do not follow from
prior techniques.

Comparison with subsequent work. Maji and Wang [MW20] use our proof technique and
potential function to prove the black-box separation of Corollary 2 for all coin-tossing protocols.
In our work, Corollary 2 uses existing techniques to lift our hardness of computation result of
Theorem 1, which is in the information-theoretic setting, into a black-box separation result for
coin-tossing protocols if the protocol satisfies the restrictions of [DLMM11, HOZ13, DMM14]. On
the other hand, Maji and Wang [MW20] directly extend Theorem 1 to the random oracle model,
which translates into a black-box separation result for arbitrary coin-tossing protocols without any
restrictions.

1.3 Technical Overview

Our proof proceeds by induction on the defense complexity d of the coin-tossing protocol to lower
bound the performance of the best fail-stop attack on the protocol. The proof of the inductive step
for this result proceeds by another induction on the number of rounds m until the first time a party
updates her defense coins. In particular, this second-level induction crucially avoids degrading the
estimate of the best fail-stop attack’s performance on the coin-tossing protocol as a function of
m. In effect, the quality of the fail-stop attack depends only on d and is insensitive to the round
complexity n of the protocol, thus circumventing the hurdles encountered by previous works.

1.3.1 Score Function & Inductive Hypothesis

Consider any n-round coin-tossing protocol π with bias-X0 and defense complexity d, the inductive
argument maintains a lower bound to the performance of the best cumulative attack possible on this
coin-tossing protocol.

For any stopping time3 τ in the protocol, we associate a score to τ measuring its susceptibility
to fail-stop attacks. For a partial transcript v ∈ τ , its contribution to the score is the sum of the
change in the output distribution that Alice can cause by aborting at that partial transcript, and
the change in the output distribution that Bob can cause by aborting at that partial transcript.

3A stopping time in a protocol is a set of prefix-free partial transcripts.

8



We emphasize that the same partial transcript v ∈ τ may contribute to both Alice and Bob’s
attacks. Explicitly, the two possible attacks are as follows. The sender of the message can abort
after generating (but not sending) the last message of the partial transcript v. The receiver may
abort immediately after receiving the last message of the partial transcript v. Both these fail-stop
strategies may be effective attacks in the scenario of coin-tossing protocols with lazy defense. The
score of a stopping time τ is the sum of all the contributions of v ∈ τ . The optimal score associated
with a protocol π, represented by Opt(π), is the maximum score achievable by a stopping time in
that protocol.

Using induction on d, we prove that, for any protocol π with bias-X0 and defense complexity d,

Opt(π) > Γ2d ·X0(1−X0),

where Γi = 1√
(
√
2+1)(i+2)

(refer to Theorem 4). We remark that, indeed, it is possible to tighten the

constants involved in the lower bound with a more careful analysis; however, such a tighter analysis
does not qualitatively improve the bound.4

1.3.2 Base Case: d = 0

In the case when the defense complexity of π is d = 0, parties begin with their respective default
defense coins and never update them. Irrespective of the round complexity n, our objective is to
demonstrate a fail-stop attack on the (n, d = 0)-coin-tossing protocol with bias-X0 that changes the
output distribution of the honest party by Ω(X0(1−X0)) statistical distance. Note that obtaining
an attack whose effectiveness does not degrade with the round complexity n even for this simple
case cannot be obtained from previous techniques [CI93, BHMO18, KMM19] (refer to the protocol
in Figure 5).

We proceed by induction on the round complexity n. Consider the base case of n = 1, a
one-round protocol where Alice sends the first message in the protocol. Section 4.1.1 proves that
Opt(π) > X0(1−X0).

The inductive step for n > 2 is the non-trivial part of the proof. The case of n = 2 is representa-
tive enough to highlight all the key ideas to handle any general n > 2. Alice and Bob have defense
coins such that their respective expected values are DA

0 and DB
0 before the protocol began. Alice

sends the first message in the protocol, and Bob sends the second message in the protocol. Suppose
the first message sent by Alice is M1 = i, which happens with probability p(i). Conditioned on the

first message being M1 = i, the expected value of (a) the outcome be x
(i)
1 , (b) Alice’s defense coin

be d
A,(i)
1 , and (c) Bob’s defense coin be DB

0 . By aborting at the message M1 = i, we obtain the
following contribution to the score5 ∣∣∣x(i)1 − d

A,(i)
1

∣∣∣+
∣∣∣x(i)1 −D

B
0

∣∣∣.
By deferring the attack to the residual (n − 1) round protocol conditioned on ";"""date"",""2021-02-04T15:49:31Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2021-02-04T15:49:31Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.21 (TeX Live 2020) kpathsea version 6.3.2""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2021-02-04T15:49:31Z""
""created"",""2021-02-04T15:49:31Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2021-02-04T15:49:31Z""
""resourceName"",""131.pdf""
""Author"",""""
""producer"",""pdfTeX-1.40.21""
""pdf:docinfo:producer"",""pdfTeX-1.40.21""
""pdf:unmappedUnicodeCharsPerPage"",""3"",""0"",""1"",""9"",""5"",""8"",""4"",""0"",""31"",""45"",""56"",""15"",""1"",""49"",""8"",""40"",""102"",""75"",""104"",""37"",""6"",""15"",""24"",""42"",""169"",""37"",""0"",""0"",""0"",""0"",""0"",""9"",""7"",""38"",""52"",""28""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2021-02-04T15:49:31Z""
""Last-Modified"",""2021-02-04T15:49:31Z""
""dcterms:modified"",""2021-02-04T15:49:31Z""
""title"",""""
""Last-Save-Date"",""2021-02-04T15:49:31Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2021-02-04T15:49:31Z""
""meta:save-date"",""2021-02-04T15:49:31Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.21 (TeX Live 2020) kpathsea version 6.3.2""
""Content-Length"",""543211""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""36""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""3325"",""2508"",""3767"",""3627"",""3229"",""1988"",""3139"",""3143"",""2754"",""2690"",""2284"",""2539"",""2736"",""2914"",""2163"",""1721"",""2023"",""2049"",""1980"",""2295"",""1894"",""2822"",""1723"",""1349"",""908"",""194"",""2711"",""2684"",""2610"",""2706"",""1209"",""1121"",""642"",""1173"",""1851"",""1227""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2021-02-04T15:49:31Z""
";https://scholar.google.ch/scholar?start=900&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098720-9;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Blockchain technology-enabled supply chain systems and supply chain performance: a resource-based view;ML Nandi, S Nandi, H Moya, H Kaynak ; Supply Chain Management …, 2020  emerald.com;;"… For example, Oracle joined the Hyperledger consortium to take advantage of the consortium's …

Likewise, SAP organized the SAP BlockChain Consortium with its technology partners and …

Development of micro-technology devices such as “crypto anchors” and “crypto seals” by …";Cité 8 fois;;null;;;;
1619098870-345;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;[PDF][PDF] A BLOCKCHAIN-BASED APPROACH TO PREVENT HIDDEN CONTAGION OF COVID-19;SA Arani, MRI Nawab, MT Rahman, M Zaman ; Compiler, 2020  researchgate.net;;"… Besides discussing the existing blockchain-based cryptocurrency technology and general features

of blockchain, [16] also describes the non- financial sectors where DLT … in Oracle Blockchain Quick

Start A practical approach to implementing blockchain in your enterprise …";Autres articles;;[PDF] researchgate.net;https://www.researchgate.net/profile/Md_Rashed_Ibn_Nawab/publication/345312654_A_BLOCKCHAIN-BASED_APPROACH_TO_PREVENT_HIDDEN_CONTAGION_OF_COVID-19/links/5fa4c53a92851cc28698df28/A-BLOCKCHAIN-BASED-APPROACH-TO-PREVENT-HIDDEN-CONTAGION-OF-COVID-19.pdf;;;https://scholar.google.ch/scholar?start=890&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098791-168;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;WOTS-S: A Quantum Secure Compact Signature Scheme for Distributed Ledger;F Shahid, A Khan, SUR Malik, KKR Choo ; Information Sciences, 2020  Elsevier;;"… Furthermore, we also provide formal security proof in the random oracle model … scheme (ECDSA),

Hash algorithm (ETHash), Transaction verification delay reduced to few seconds, Limited scope

(not developed primarily as a cryptocurrency but as … [26], Blockchain-based, ECDSA …";Cité 2 fois;Les 6 versions;[PDF] researchgate.net;https://www.researchgate.net/profile/Abid_Khan11/publication/341297443_WOTS-S_A_Quantum_Secure_Compact_Signature_Scheme_for_Distributed_Ledger/links/5eb9bd88299bf1287f7fb2f8/WOTS-S-A-Quantum-Secure-Compact-Signature-Scheme-for-Distributed-Ledger.pdf;;;https://scholar.google.ch/scholar?start=710&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098853-304;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;[PDF][PDF] A REVIEW ON BLOCKCHAIN TECHNOLOGY;P Gupta, D Chahal ; irjmets.com;;"… Keywords: Block chain, Crypto currency, Distributed, Ledger. I. INTRODUCTION … Blockchain

is now popularly being used among many companies to secure the data. Companies like

Microsoft, Oracle, IBM, amazon are providing free souces for blockchain …";;;[PDF] irjmets.com;https://irjmets.com/rootaccess/forms/uploads/a-review-on-blockchain-technology.pdf;"
                                                                                      e-ISSN: 2582-5208 
International Research Journal of Modernization in Engineering Technology and Science 

  Volume:02/Issue:04/April-2020                                                                                   www.irjmets.com       

www.irjmets.com                  @International Research Journal of Modernization in Engineering, Technology and Science 

 [864] 
 

A REVIEW ON BLOCKCHAIN TECHNOLOGY 

Priyanshi Gupta
*1

, Dr. Deepak Chahal
*2 

*1
Student, Department of IT, Jagan Institute of Management Studies, Sector -05, Rohini,  New Delhi. India. 

*2
Professor, Department of IT, Jagan Institute of Management Studies, Sector -05, Rohini,  New Delhi. India. 

ABSTRACT 

The first person to work on a cryptographically secured chain of blocks was illustrated in1991 by 

Stuart Haber and W. Scott Stornetta. They wanted to execute a system where a document time 

count cannot be fortified. The first Blockchain was visualized by Satoshi Nakamoto in 2008. 

Nakamoto enhances the design efficiently by using the Hashcash method to time count the no of 

blocks without necessitating them that to be signed to reduce the size with which block to be 

added to the block or not. Nakamoto executed the design as a part of the cryptocurrency bitcoin, 

where it serves as a public ledger for all arrangements on the network. In this paper, we are going 

to learn more in about Blockchain, the working of Blockchain, and how it is modernized the 

whole world. 

Keywords: Block chain, Crypto currency, Distributed, Ledger. 

I. INTRODUCTION 

A blockchain is resistant to tampering of data. It is ""a diffusion ledger that can record the transactions between two-

person efficiently and in a permanent way [1].Being in the 21st century, get all the things done through the internet 

nowadays is very common. Whether shopping, any online transaction, buying, and selling or whatnot. 

Just enter your private information such as when you are shopping, to buy a product you must fill your banking 

details which are considered private information but you are sharing that private information for your convenience, 

to buy the product. 

As we all know the data or our information may get compromised from a third party. The secured place always 

become successful in inviting more person. And today, securing information has become the most important work to 

perform. Blockchain is introduced to make your data private and secure. It is introduced for making data more 

secure and confidential. And it also kept the record of previous transactions. 

II. EVOLUTION OF BLOCKCHAIN 
The Blockchain first conceptualized in 2008 by „Satoshi Nakamoto‟ in his paper about bitcoin. Blockchain is 

evolved from Blockchain 1.0 to Blockchain 2.0 to blockchain 3.0 and now blockchain 4.0. 

Blockchain technology nowadays becoming very popular and in trend, as it is evolving very fast. 

Blockchain 1.0 is generated for cryptocurrency and bitcoin by Satoshi Nakamoto in 2008 and then by Ryan Fugger 

in 2012 for cash for the internet.  

Blockchain 2.0,evoluted in 2015, ethernum and hyper ledger blockchain is used for smart contracts, to avoid fraud, 

to reduce the cost of verification and execution as it is time-saving. And also for automatically verify the documents 

and perform further tasks. 

http://www.irjmets.com/


                                                                                      e-ISSN: 2582-5208 
International Research Journal of Modernization in Engineering Technology and Science 

  Volume:02/Issue:04/April-2020                                                                                   www.irjmets.com       

www.irjmets.com                  @International Research Journal of Modernization in Engineering, Technology and Science 

 [865] 
 

Blockchain 3.0 evolution in2017, Cardano and iota is being used for decentralization. Dapp (Decentralized App) 

which is an open-source is used for prevention for DDOS attacks. 

Nowadays blockchain 4.0 is in trend. 

III. WHAT IS BLOCKCHAIN 

Firstly, we must know about a block, what is a block? So block is a database consisting of timestamp, previous hash, 

Merkle root, block id in the header and its body consisting of details or data. What kind of data does blockchain 

consist is another question arises. So the block can store transaction details, asset details, contract details, identities 

and many more as data. 

Now, Blockchain has the potential to revolutionize the digital world, the internet world, by enabling a distributed 

consensus where every online transaction can be verified in future, it is a chain of blocks, as a block contains the 

previous hash in its header that previous hash is nothing but an address to the previous block so the first block in 

blockchain considered as a genesis block (genesis a name taken from bible that means first). And every block has its 

id which is unique for all and how much bigger the data it contains the output is always the same length. 

And if the data in a block is changed then the block id is also changed and previous hash id is also get changed in its 

followed by block so to make changes when there are increased in number of blocks get harder to change and hence 

it is considered to be more secure. 

 
Fig 1: Uses of Blockchain 

 

IV. WORKING OF BLOCKCHAIN 

Distributed consensus is very crucial in the blockchain. The blockchain network is not centralized, it is a 

decentralized network for making network secured, trusted, shared and authenticated. So in a decentralized network, 

each participant is connected to every participant for their blockchains and is also connected. If the transaction in the 

block is added in one participant that data will have to send all other participating nodes provide it consensus before 

the nodes are getting the transaction, and then verify the transactions and after this process, the block will be adding 

to every participating‟s nodes blockchain. 

After the block is added to every participating node then only the transaction is considered as completed. 

Blockchain can not be implemented in retail sectors such as ticket booking on the railway. 

http://www.irjmets.com/


                                                                                      e-ISSN: 2582-5208 
International Research Journal of Modernization in Engineering Technology and Science 

  Volume:02/Issue:04/April-2020                                                                                   www.irjmets.com       

www.irjmets.com                  @International Research Journal of Modernization in Engineering, Technology and Science 

 [866] 
 

V. TYPES OF BLOCKCHAIN 
 There are types of the blockchain are as follows: 

 A public blockchain is the first type of blockchain where everyone can access it publically, its an open-source 

and it is not centralized. It needs a distributed consensus for building trust. 

 Private blockchain is another type of blockchain in this kind of blockchain members are trusted and it is 

restricted in one organization as the admission is restricted. 

 Federated blockchain is another kind of blockchain that is very fast and scalable. In this blockchain, the 

admission is restricted and its id been operated under the leadership of the group. 

 

VI. NEED OF BLOCKCHAIN 

Living life in the digital world, we rely on third entities for security and confidentiality. 

Third-party can be compromised, cracked or hacked, so to eliminate or replace the third party by blockchain helps to 

make your data secure and private. Integrity of data refers to protecting information from falsely being modified by 

an unauthorized party. Information is valuable only if it is correct, tampered information could prove costly to both 

the sender and the receiver party [2]. 

Some of needs are given below: 

 Database maintains a continuous growing list of data records and transactions to make them more secure 

blockchain is used so that no one can make changes in the record and those records can not be compromised. 

 To decentralized the centralized system because in centralized architecture it created many issues. 

 In the case of the server down, data can not be assessed. 

 And in a centralized system, there is a threat of DDOS attack which can be prevented by making the system 

decentralized through blockchain and preventing the whole data from being compromised and erased. 

 It also needs the secured payment gateway for the transaction of money from one account to another account, so 

that no third party can take the information of banking details of one's party and makes it compromised. 

 It is also needed for banking, shopping or for booking a ride, as it always eliminates the third party and replaces 

it. 

 The records can be verified in the future whenever it comes to use and saves time and cost. 

 It trusts on single intermediaries. 

 The whole thing is done through blockchain, as blockchain makes its blockchain network which is efficient, not 

that expensive and not vulnerable so that every possible transaction can be easily identified and verified in 

future when there is a need because it contains the chain to keep the record of all transactions and to make 

changes in it is not an easy task. 

VII. BENEFITS OF BLOCKCHAIN 

Everyone wants that their data is secured and not compromised. But with the increase in the use of the internet and 

having a lot of data it can be troubled for managing the data as the data volume is increased nowadays and to handle 

is a big difficulty for everyone. Given below are benefits: 

 There is a need for blockchain to make your data secure and provide authenticity. 

 It empowers cryptocurrency. 

 It has become a revolutionary change in this era of technology where everything relies on the internet and 

getting things done in just seconds, blockchain makes its own blockchain network for security and privacy of 

data and eliminates the need of third party. 

http://www.irjmets.com/


                                                                                      e-ISSN: 2582-5208 
International Research Journal of Modernization in Engineering Technology and Science 

  Volume:02/Issue:04/April-2020                                                                                   www.irjmets.com       

www.irjmets.com                  @International Research Journal of Modernization in Engineering, Technology and Science 

 [867] 
 

 It also ensures authenticity like when you chat on social media how you ensure that no one is peeking in your 

chat. Is it secured or not? 

 Blockchain ensures security by giving the authentication. 

 On buying Products blockchain ensures the products are not duplicate. 

 It focuses not only on banking sectors but also in the medical field and many more areas. 

 

VIII. CONCLUSION 

A focus is made on machines as machines cannot be understood by verbal communication it forms abstractions and 

concepts [3]. Blockchain is a revolution in the digital world which is introduced for cryptocurrency, to secure the 

transaction from one country to another but now cryptocurrency is banned in certain countries. Blockchain is now 

popularly being used among many companies to secure the data. Companies like Microsoft, Oracle, IBM, amazon 

are providing free souces for blockchain. It is being using in larger areas such as in real estate, healthcare field, in 

the educational field, banking sectors, vehicle registration and many more. To keep the track of the previous data 

and maintain the blocks of data and make it private, secure, trusted and authenticated. Blockchain is now in trend 

and a change in this era of the digital world for security. 

IX. REFERENCES 

[1] Singhal A. et al. Blockchain: An Innovative Technology, International Journal of Scientific Research and 

Engineering Development, Volume 2 Issue  6, Nov- Dec 2019. 

[2] Varyani Y. et al. A Survey on Cryptography, Encryption and Compression Techniques, International 

Research Journal of Engineering and Technology (IRJET), Volume: 06 Issue: 11 | Nov 2019. 

[3] L. Kharb et al (2019) “Brain Emulation Machine Model for Communication” in International Journal of 

Scientific & Technology Research (IJSTR). pp 1410-1418. 

 

http://www.irjmets.com/

";"""date"",""2020-04-24T16:23:38Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.5""
""xmp:CreatorTool"",""MicrosoftÂŽ Word 2010""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dc:creator"",""aakankshac""
""language"",""en""
""dcterms:created"",""2020-04-24T16:23:38Z""
""Last-Modified"",""2020-04-24T16:23:38Z""
""dcterms:modified"",""2020-04-24T16:23:38Z""
""dc:format"",""application/pdf; version=1.5""
""Last-Save-Date"",""2020-04-24T16:23:38Z""
""pdf:docinfo:creator_tool"",""MicrosoftÂŽ Word 2010""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2020-04-24T16:23:38Z""
""meta:save-date"",""2020-04-24T16:23:38Z""
""pdf:encrypted"",""false""
""modified"",""2020-04-24T16:23:38Z""
""Content-Length"",""424282""
""pdf:hasMarkedContent"",""false""
""Content-Type"",""application/pdf""
""pdf:docinfo:creator"",""aakankshac""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""aakankshac""
""dc:language"",""en-US""
""meta:author"",""aakankshac""
""meta:creation-date"",""2020-04-24T16:23:38Z""
""created"",""2020-04-24T16:23:38Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""4""
""Creation-Date"",""2020-04-24T16:23:38Z""
""resourceName"",""a-review-on-blockchain-technology.pdf""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""3321"",""2794"",""3745"",""2230""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""Author"",""aakankshac""
""producer"",""MicrosoftÂŽ Word 2010""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""MicrosoftÂŽ Word 2010""
""pdf:docinfo:created"",""2020-04-24T16:23:38Z""
";https://scholar.google.ch/scholar?start=850&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098813-214;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;SafeComp: Protocol For Certifying Cloud Computations Integrity;E Shishkin, E Kislitsyn ; arXiv preprint arXiv:2005.10786, 2020  arxiv.org;;"… a solution is found and verified, a smart-contract has an amount of cryptocurrency on its … distributed

file system may be used [2]. A smart-contract could use an oracle technology to … Due to time

constraints, we have chosen not implement the protocol logic on a real blockchain …";Autres articles;;[PDF] arxiv.org;https://arxiv.org/pdf/2005.10786;"
ar
X

iv
:2

00
5.

10
78

6v
2 

 [
cs

.C
R

] 
 2

2 
M

ay
 2

02
0

SafeComp: Protocol For Certifying

Cloud Computations Integrity

Evgeny Shishkin1

Evgeny Kislitsyn1,2

1InfoTeCS, Advanced Research Department, Russia
2Moscow State University, Department of Mathematics and Mechanics, Russia

evgeny.shishkin@infotecs.ru

evgeny.kislitsyn@infotecs.ru

Abstract

We define a problem of certifying computation integrity performed by some remote
party we do not necessarily trust. We present a multi-party interactive protocol called
SafeComp that solves this problem under specified constraints. Comparing to the near-
est related work, our protocol reduces a proof construction complexity from O(n log n)
to O(n), turning a communication complexity to exactly one round using a certificate
of a comparable length.

Keywords: computation integrity; interactive proofs; computation certificates

1 Introduction

Suppose, a user needs to compute some complex heavyweight function C(x). It might
be necessary to possess a non-trivial computational resource to do that, for example, a
cluster of computational nodes. Chances are, the user does not have it. To compute
this function, the user asks some cloud service - a provider - to compute it for him. The
user supplies the provider with the function C(x) and some initial data d, asking to
compute C(d), and some time later the provider gives the result r. How can the user
be sure that the provided result r is correct?

There are many cases when a computation result can be verified easily. Consider
a sorting function that maps an arbitrary list of integers to a sorted list of the same
integers. We can check that the output list is sorted using a simple one-way scanning
function that ensures the sameness of input/ output list elements and their expected
order.

On the contrary, there are cases when it is hard or maybe even impossible to verify
a computation result without redoing the whole computation from scratch. Take a
problem of checking that there are no Hamiltonian cycles within a given graph. 1 If

1 Hamiltonian cycle is a cycle in a graph that traverse each vertex exactly once.

1

http://arxiv.org/abs/2005.10786v2


the provider gives you a founded Hamiltonian cycle, it is easy to check its correctness.
But what if the provider tells you that there are no such cycles: how would you ensure
that it tells you the truth?

Consider yet another problem: a model-checking of computer programs - the well-
known computationally hard problem. Suppose, the user supplies the provider with a
program and a list of properties it must respect, and asks if this really holds. Some time
later, the provider tells the user that a checking procedure did not find any deviations
from the specified properties. How would you check that: 1) the result is correct 2) the
result was not simply guessed (i.e. the computation was not halted until the result was
obtained)?

In modern practice, a user has to trust in provider’s integrity, rely on its market
authority. A computation result is signed with a public key of the provider linking
that trust to the obtained result. In this article, we present SafeComp: a multi-party
interactive protocol that solves the described problem technically, removing the necessity
to trust the authority of a cloud provider.

We still rely on a so-called trusted weak computing device, say, a smart-contract
residing on a public blockchain. This device plays a role of autonomous transparent
arbiter that is able to decide who is right and who is wrong in case of a dispute regarding
published computation results, and do that performing only a tiny fraction of the whole
computation.

Comparing to the nearest related work - TrueBit protocol - our protocol reduces proof
construction complexity from O(n log n) to O(n) and turning communication complexity
from O(log n) to exactly one round. This result is achieved by using a different proof
construction and verification procedure, while the proof length stays effectively the
same: O(n).

The article is structured in the following way: in Section 2 we define the problem
that our protocol is aiming to solve. In Section 3, we give a high-level overview of
SafeComp protocol. Section 4 describes a way of presenting user computation function
in a form that is appropriate to be used in the protocol. Section 5 contains a formal
description of SafeComp protocol. Section 6 is devoted to a security analysis of some
aspects of the protocol under clearly stated threat model. In Section 7, we discuss some
of the known attack vectors and features of the protocol. Our first experimental results
are discussed in Section 8. Section 9 contains the overview of related works in the field,
and comparison of SafeComp with other known protocols.

2 Problem Statement

We are looking for an efficient verification procedure that allows us to check computa-
tion integrity giving that the computation was performed by some not necessarily fully
trusted computing provider (or, simply, provider). Along with a computation result,
the provider constructs a certificate whose size reasonably correlates with computation
complexity. Using the certificate, we should be able to unambiguously check correctness
of the performed computation, and do that much faster than a full recomputation.

Definition 2.1. (Computation Certification Problem)
For an arbitrary function C : N → Result computable at a point d ∈ N, define com-
putable functions:

proof(C, d) → Result× Proofs

2



verify(C, d, r, prf) → {True, False}

where r ∈ Result is a result of computation under question, that is r
?
= C(d),

prf ∈ Proofs - a proof of computation integrity, also called certificate.

The following must hold:

1. verify(C, d, r, prf) = True ⇐⇒ C(d) = r

2. Computation complexity of proof(C, d) dependents on complexity of C linearly.

3. Computation complexity of verify is essentially smaller than complexity of proof
for any given function C, that is

lim
n→∞

vC(n)

eC(n)
= 0

where vC(n), eC(n) - asymptotic estimates of computation complexity of functions
verify and proof for the function C with input size n.

4. As complexity eC(n) increases, the size of prf grows linearly, that is

∃k∀n . |prf(n)| ≤ k · eC(n)

Probabilistic Certificate Verification

In our case, the requirement 1 turns out to be overly rigorous. We will use a weaker
requirement instead.

Definition 2.2. (Probabilistic Certificate Verification Criteria)
Consider the following events:

E0(λ) : proofλ(C, d) = 〈r, prfλ〉

E1(Îť) : verifyÎť(C, d, r, prfÎť) = True

E2 : C(d) = r

If functions proofÎť, verifyÎť satisfy:

lim
λ→∞

Pr[E0(Ν) ¡ E1(Ν) ¡ E2] = 1

where Îť is a parameter that can affect computational complexity of functions and the
size of a certificate, then we say that algorithms described above meet probabilistic
certificate verification criteria.

In other words, we are depicting not deterministic, but probabilistic method of
solving the defined problem, where some special parameter regulates the probability of
the desired outcome.

Interactivity

Some approaches aiming to solve the defined problem require a so-called interactiv-
ity, that is, a verification procedure is performed in several rounds of message passing
between a computing provider and a user. An upper bound on the number of message-
passing rounds is called communication complexity of a protocol. An interactive ap-
proach for solving the depicted problem is also called protocol for certifying outsourced
computations, or, cloud computations.

3



Trusted Weak Computing Device

Some certification protocols rely on a presence of some trusted party which is able to
perform simple computations in a verifiable way, but definitely not able to perform the
whole computation C(d).

For instance, such device may not be able to compute a factorial of some big number,
but still it could perform an addition of any two natural numbers, providing some kind
of proof of the result. If, say, we divide the whole computation of a factorial function
into smaller operations of addition, we could carry out the entire computation in a
verifiable manner.

Definition 2.1. (Trusted Weak Computing Device)
A device that is capable of certifying computations 2.1 for computable functions f
such that computational complexity of f(n) grows linearly with the size of input, i.e.
f(n) ∈ O(n), is called trusted weak computing device.

Secure enclaves [12] and blockchain smart-contracts [5] are examples of such devices.

Multi-party Protocol

A classical interpretation of the computation certification problem assumes that a com-
puting provider proves correctness of an obtained result to a user in some way, and the
user examines this proof. An interaction between two parties happens directly.

Our model of interaction is different: a user and the set of computing providers (or,
simply, providers) interact with each other using a Trusted Weak Computing Device
(TWCD) as a trusted verifiable intermediary. Several providers can run a computation
task in parallel on their own computing resources. A computation result and a proof
are then published within TWCD by some provider who has found a solution. Other
providers are able to re-check the result. If a disagreement arises, other providers would
be able to convince other parties that the result written in TWCD is faulty. Otherwise,
after a period of time, the published result is considered to be correct and a user receives
the solution to the published computation task. Such interaction model is called multi-
party protocol.

Problem Statement

In this article, we present a multi-party protocol for certifying cloud computations with
a probabilistic certificate verification criteria and a reliance on a trusted weak computing
device that is able to authenticate its users.

For ease of presentation, we consider a public blockchain smart-contract to play a
role of a trusted weak computing device. But one can imagine other devices being used.

3 Protocol Overview

In this section, we give a high-level overview of the protocol. Here we presume that a
user would like to compute the function C(x) in the point d, but do not have an ability
to do the whole computation.

1. A user transforms his computable function C into another function f such that
applying f to d n times, the result converges to C(d).

4



2. User publishes the function f and the point d in a smart contract. We assume
that the smart contract is accessible for multiple computing providers.

3. Once a provider receives the computation task f and the point d, he starts per-
forming the computation r = f(f(...f(d))) until the result converges to a fixpoint.
At the end of each iteration f(x), he also computes a hash ci := H(x◦ci−1). These
ci values form a sequence cert := 〈c1, ..., cn〉 This sequence is called a certificate
sequence (or, simply, a certificate).

The provider computes a certificate fingerprint hc := H(H(cert)) and a certificate
projection cp := 〈π(c1), π(c2), ..., π(cn)〉. The main idea behind introducing the
fingerprint is to give other providers ability to check their own certificates against
the computed one without publishing a certificate sequence in pure.

A certificate projection is needed to let other providers find the very first divergent
step of a computation in case of a fingerprint disagreement, and do that without
disclosing the certificate sequence in pure.

A certificate sequence plays a role of a secret value used in a later stage of the
protocol to establish a list of all fair providers that performed the verification of a
published result and a certificate, this is why we do not want to publish it in pure.

4. After finding a solution, one of the providers - we call him the solver - publishes the
solution r, the certificate fingerprint hc and the projection cp in a smart-contract.

5. Other providers that performed the computation, but found the solution later
than the solver, are able to check the published solution and the computation
work integrity by comparing certificate fingerprints. This group of providers is
called auditors.

6. In case of a disagreement, an auditor sends the number of a certificate part i from
which the divergence starts, the partial value ri−1 and certificate parts ci−1, ci.

7. Using the provided values i, ri−1, ci−1, ci the smart-contract arbiter ensures that
the published result or computation certificate is indeed wrong by performing only
a single computation step (details are in Section 5).

8. After some period of time, if no proofs of computation disintegrity has been pro-
vided, the published solution r is considered correct.

9. Each auditor sends the value H(H(cert) ◦ id) into the smart-contract. Here id
is a unique identifier of an auditor. This value plays a role of a proof that the
computation work has been done.

10. Finally, the solver sends the value s such that hc = H(s) into the smart-contract.
The list of fair auditors is then evaluated.

4 Iterative Computation

The protocol requires the computation to be prepared in an iterative form. An example
is shown on Fig.1: factorial function is implemented in two different ways: the standard
recursive form 1a and iterative form 1b.

If you consecutively compute the function factFP , starting at the point {N, 1} and
passing the evaluated result as a next point iteratively, then, after N iterations, the
function will converge to the value {0, N !}.

5



f a c t (0 ) −>
1 ;

f a c t (N) when N > 0 −>
N ∗ f a c t (N−1).

(a) Recursive implementation

factFP ({0 , Acc}) −>
{0 , Acc} ;

factFP ({N, Acc}) when N > 0 −>
{N − 1 , Acc ∗ N} .

(b) Iterative implementation

Fig. 1: Recursive vs. Iterative factorial implementation (Erlang)

The main difference between two implementations is that the first one (Fig.1a) com-
putes the result at once, while the second (Fig.1b) computes only a part of the whole
computation and returns that partial result. The computation can be continued by pass-
ing the partial result into the function again, and so on, until a fixpoint - the solution -
is found.

One can start feeling doubt whether it is always possible to transform an arbitrary
computable function C(x) into such form. The next theorem shows that not only it is
always possible, but can be done in several ways.

Theorem 1. For all functions C : N → N computable at some point d there exist
computable functions

inj : N → T, proj : T → N, F : T → T

such that
proj(fix F inj(d)) = C(d)

where fix : (T → T ) × N → T - an operator that calculates fixed point of a function
starting at a given point. That is,

fixF p = F (fixF p)

T - a finite set.

Proof. The proof is moved into Appendix 10. ďż˝

5 Protocol Specification

SafeComp protocol rely on availability of a trusted weak computing device. We take a
smart-contract as a practically viable form of such device. Parties - a user and providers
- communicate with each other by sending transactions into the smart-contract.

Lets us define a smart-contract state to be a set of its internal variables of some
type. Any transaction into a smart-contract can potentially change its state. Within
our specification effort, we use a concept of a current state and a next state of a variable
denoting the variable value before and after transaction processing respectively.

Notation

Np = {0 ... 2p − 1} - a set of natural numbers with a given upper bound
X,X ′ - a value of variable X before and after transaction processing

6



Variables Denotation

Id ∈ 2N ∪ {0} - a set of user identifiers. We use 0 to denote an undefined identifier.
r ∈ N - a computation result
s ∈ N - a certificate fingerprint
solver ∈ Id - an identifier of a provider who published a solution for the user’s task
V ∈ 2Id - a set of provider identifiers that managed to prove their verification work.
L ∈ 2Id - a set of participant identifiers that tried to compromise the protocol in

any way
P ⊆ Id × N - A set of pairs - identifier × proof - sent by parties pretending to be

considered as verifiers.

Input: User’s task f : N → N and an input data d ∈ N.
Output: 〈r, s, solver, V, L〉

Preliminary Setup

1. The User defines the function f and the initial point d. We discussed requirements
for C and f and their relation earlier.

2. Parties agree on some cryptographically secure hash function H : N → Nq, where
parameter q is taken according to recommendations for the hash-function.

3. The User constructs a computable function

F (〈x, c〉) := IF x == f(x) THEN 〈x, c〉ELSE 〈f(x),H(x ◦ c)〉

Here ◦ : N × N → N - some non-constant binary operation. Computation must
start at the point 〈d,H(d)〉

4. Parties agree on a function family πk : Nk → N
k
p, for k ≥ 1, such that

π1 : N → Np − some arbitrary hash-function (not required to be equal to H(x))

πk(〈c1, ..., ck〉) := 〈π1(c1), ..., π1(ck)〉, for k > 1

Henceforth, we omit k index because its value is clear from a context: it is a length
of a tuple argument.

5. A smart-contract must be published on a blockchain. The smart-contract should
give its users ability to:

• Publish a computational task F , initial data point d; the user request status
is set to “published”. For every new user request, the smart-contract allocates
a new set of state variables: 〈r, s, solver, V, L, P 〉, initially empty.

• For any published user request, receive a user request status and a computa-
tional task 〈F, d〉. If a request status is set to “completed”, then also receive a
certificate projection cp and a solution r. If a request status is set to “verified”,
then also receive values 〈r, s, solver, V, L〉

• For requests with status “published”, provide the solution rn, cn, cp, hc , such
that

F (〈rn, cn〉) = 〈rn, cn〉

cp := π(〈c1, ..., cn〉)

hc := H(H(〈c1, ..., cn〉))

7



Let u be an identifier of a provider that sent a solution - the solver. The
smart-contract checks that the pair 〈rn, cn〉 is indeed a fixpoint of F , in this
case the user request status is changed to “completed” and

solver′ = u ∧ r′ = rn

If the point 〈rn, cn〉 is not a fixpoint of F , the solution is declined, the user
request status does not change. In this case,

L′ = L ∪ {u}

• For user requests with status “completed”, refute the published solution by
providing the refutation data i, ci−1, ci, ri−1, such that

π(ci−1) = cp[i− 1]∧F (〈ri−1, ci−1〉) = 〈ri, ci〉 ∧ π(ci) = cp[i] (1)

ci+1 := H(ri ◦ ci) (2)

π(ci+1) 6= cp[i+ 1] (3)

Here cp[i] denotes an element of a tuple cp, residing on the position i.
Let u be an identifier of a provider that has sent a refutation. If the smart-
contract establishes the fact of refutation correctness, the user request status
is changed back to “published”. In this case,

L′ = L ∪ {solver} ∧ V ′ = V ∪ {u} ∧ solver′ = 0

• For user requests with status “completed”, provide a proof of computation
prf , such that:

prf := H(H(〈c1, ..., cn〉) ◦ id)

where id - a unique identifier of a provider. In this case,

P ′ = P ∪ {(id, prf)}

• For user requests with status “completed”, after verification period T has
elapsed, provide a secret s from a user with identifier solver, such that:

hc = H(s)

If the above does not hold, then the status is changed to “published” and

L′ = L ∪ {solver}

solver′ = 0

Otherwise, the status is changed to “verified”. In this case,

V ′ = V ∪ {x : (x, p) ∈ P ∧H(hc ◦ x) = p}

L′ = L ∪ {x : (x, p) ∈ P ∧H(hc ◦ x) 6= p}

Protocol Steps

1. A user publishes a computation request, providing F , d

8



2. Potential computing providers read computation requests with the status “pub-
lished” from the smart-contract and possibly start to compute F from the point
〈d,H(d)〉

3. A provider publishes a computed solution rn, cn, cp, hc in the smart-contract. We
call this provider the solver.

4. Other providers that were also performing computation, verify the published result
by comparing the value cp to their own.

• If values are different, then send a refutation data into the smart-contract.

• If values are the same, after verification period, send the proof of computation
into the smart-contract.

5. Last of all, the solver sends s, the hash of a certificate, into the smart-contract,
making it possible to find out all fair providers.

• In case of successful secret validation, the smart-contract constructs an out-
put: 〈r, s, solver, V, L〉

• Otherwise, the user request status is changed back to “published” and the
protocol goes back to step 2.

6 Protocol Security Analysis

Any participant of the protocol trying to break its functional properties is called in-
truder. We measure protocol security degree as a probability value of any undesirable
event - that is when functional properties of the protocol gets broken - within a given
intruder model.

Definition 6.1. (Intruder model M1)

• Finding a pre-image of a chosen hash-function H(x) is considered a computa-
tionally difficult task for an intruder.

• Intruder’s knowledge regarding user’s function f(x) implementation details is consi-
dered to be the same as of a user itself.

Definition 6.2. (Protocol Security Threats)

• Event E1 : Refutation of a correct solution.

• Event E2 : False proof of a solution verification.

Theorem 2. A refutation of a correct published solution (Event E1) is a computation-
ally difficult task for an intruder from M1.

Proof. To refute a published solution, the protocol requires providing such i, ci−1, ci,
ri−1 that

π(ci−1) = cp[i− 1] ∧ π(ci) = cp[i] ∧H(ri−1 ◦ ci−1) = ci (4)

F (〈ri, ci〉) = (ri+1, ci+1) ∧ π(ci+1) 6= cp[i+ 1] (5)

Suppose, F is a total function N × Nq → N - in practice, this is almost always not the
case, but let us take this assumption to simplify work for an intruder in our analysis.

9



In this case, it is easy to satisfy 5. The requirement could be fulfilled for almost any
point 〈r, c〉. Therefore, the main burden falls on the predicate 4.

Suppose that hash-functions have the following signatures: H : N → Nq, π : Nq →
Np. We also require H to be cryptographically secure. Then, a problem of finding values
satisfying the predicate 4 is reduced to the known problem of finding a pre-image by a
given image of a cryptographically secure hash-function, and is considered to be hard
for an intruder in M1 with appropriately chosen p, q values. ďż˝

Theorem 3. Submitting of false proof of verification for a published solution (event
E2) is computationally difficult task for any intruder from M1.

Proof. To prove a published solution verification work, the protocol requires a partici-
pant to provide the following value:

prf = H(s ◦ id)

Here, id is a unique identifier of a participant. Every unique id is allowed to publish
only a single prf as a proof. Additionally, we consider an intruder to know the following
values:

hc = H(s) (6)

prf i = H(s ◦ idi), for i = 1, 2, 3, ... (7)

Identifiers idi are also known to the intruder. Here, s = H(〈c1, c2, ...cn〉) is a fingerprint
of the certificate. A probability of finding the desired pre-image of s is:

Ps =
1

2q¡n
, где , q ≥ 64, n ≫ 103

Here, values for q - a hash-function image size, and n - a number of computation steps,
are specified according to practical considerations. So, in this case, an event E2 can be
considered to be highly improbable.

An intruder could make an attempt to find a collision in 6: find s′ such that
H(s′) = hc. But, in this case, with carefully selected operation ◦, a probability of
finding satisfying values for 7 with the founded collision s′ is also insignificant. �

Economic Incentives

Earlier, we have discussed some aspects of the protocol security relying on an assumption
that the protocol’s cryptographic components is secure enough. It is possible to enhance
reliability of the protocol even further by exploring the immanent feature of smart-
contracts: economic incentives for its users - a powerful tool for stimulating rational
parties strictly follow protocol rules.

In this paradigm, a stability of a protocol depends not only on security of crypto-
graphic mechanisms, but also on an incentive scheme consisting of penalties and pre-
miums for participants. We are not going to discuss this in deep, but give a high level
overview of such scheme in form of an extension to protocol steps.

1. User publishes a computation request in a smart-contract, supplying the request
with F , d and a cryptocurrency deposit Dr.

10



2. Providers read the request and start seeking a solution.

3. A provider who computed the solution first, publish his result in the smart-
contract, supplying the transaction with a cryptocurrency deposit Ds

4. Other providers verify the published result.

• If a divergence is found, one publishes a refutation in the smart-contract,
supplying the transaction with a cryptocurrency deposit Dp

• If no divergence is found, one sends a proof of computation in the smart-
contract, supplying the transaction with a cryptocurrency deposit Dw

At the end, when a solution is found and verified, a smart-contract has an amount
of cryptocurrency on its account equal to s = Dr + Ds + m ¡ Dp + n ¡ Dw where n
- number of participants successfully proved the computational work, m - number of
refuted solutions. The protocol output is a tuple: 〈r, s, solver, V, L〉, so the smart-
contract is able to redistribute funds s between a solver and fair auditors V , penalizing
bad actors from L.

7 Protocol Features

Some aspects of SafeComp protocol may cause difficulties in a practical implementation,
or even present attack vectors. Here, we discuss some of those issues and ways to
overcome them.

Transforming computation into iterative form. In theorem 1, it was shown that
a computation could be always presented in an iterative form and there are multiple
ways to do the transformation.

For example, in the work [19] the following approach is used: a user’s program is
compiled from high-level language into a byte-code of some virtual machine. Then, n
elementary steps of interpreter is taken as a single computation step. A state of the
interpreter - registers and memory - is then taken as a computation state. The next
step is executed starting from that interpreter state, and so on, until the solution is
computed.

We use a different approach: the user’s program is written in a so-called Continuation
Passing Style (CPS) [14], but instead of a tail call, the argument together with a tail
call function tag is returned as an intermediary result. Such representation achieves the
same technical result while may sometimes lead to more compact state representations
and does not rely on a special interpreter. A program’s source code can be automatically
transformed into CPS-style form [1], but we did not investigate this question in deep.

Divergent function F . Suppose someone places a divergent computation task in a
smart-contract. A computational provider will spend its computing resource, but will
never find a solution: an obvious loss for a provider.

There are some ways to overcome this difficulty:

• Implement a computational algorithm in a programming language that guarantees
termination. For example, any primitive recursive language gives such guarantee
by construction, and is expressive enough to develop nearly all practically inter-
esting algorithms [17].

11



In this case, a user sends not a byte-code, but a program source code P , written
in one of those languages. A provider then compiles P into f . If compilation is
successful, the provider is guaranteed that the computation is finite and can be
taken into work.

• Extend the protocol to support certification of partial computation results, i.e.
results that have not converged to a fixpoint, but is correct from a certificate
point of view. In this case, the longest result respecting the certificate integrity
check is considered to be a correct solution.

Bytecode size of F . It might be the case that the size of a function F or a point d is
greater than a maximum size of data unit of chosen blockchain platform.

Unfortunately, it is a fundamental limitation of the protocol. The following inequa-
tion must hold: |F |+ |d| ≤ Tmax, where Tmax - maximum size of data unit for a chosen
TWCD. In case of smart-contracts, if this condition does not hold, such transaction will
be declined.

Size of refutation. If a dispute against a published solution arises, a provider must
send a refutation data ci−1, ci, ri−1 into the smart-contract.

The point ri−1 represents an intermediary computing state. It might be the case
that the size of ri−1 is too big to be sent into the smart-contract. Unfortunately, it is
a fundamental limitation of the protocol. The following must hold: ∀r, |f(r)| ≤ Tmax,
where Tmax - maximum size of data unit for a chosen TWCD.

Certificate projection size. It might be the case that a certificate projection is
too big to be placed directly into a smart-contract or other chosen TWCD. At least
in case of smart-contracts, it is possible to use an external immutable storage to store
the projection there. For example, IPFS distributed file system may be used [3]. A
smart-contract could use an oracle technology to access the corresponding data [10].

8 Experimental Evaluation

In order to evaluate SafeComp protocol, we have implemented its logic and one user
computation task.

Due to time constraints, we have chosen not implement the protocol logic on a real
blockchain. We implemented the protocol using Erlang programming language and its
BEAM virtual machine instead. 2

As for the user task, we took UNSAT problem: the problem of determining that
there is no satisfying assignment for a Boolean formula. UNSAT problem is conjugated
to a famous NP-complete problem SAT [6], but unlike SAT, its solution can not be
checked in polynomial time in general case. Our choice is justified by the fact that an
algorithm for solving UNSAT problem has a direct practical application - a symbolic
model-checking of computer algorithms.

There are many algorithms for solving SAT/UNSAT problem, and it is known that
no one of them guarantees a working time better, than O(2n), where n - the number of
boolean variables in Boolean formula. Still, they are quite good in practice.

2 Our first attempts to implement the user task in Solidity (Ethereum blockchain) turned out to be highly
cumbersome activity due to limited expressive power of the language and limitations of a virtual machine.

12



We have chosen to implement one of the simplest such algorithms - DPLL [7]. There
are many DPLL implementations available, but in our case, we had to implement it in
an iterative form discussed in Section 4.

As for the input, passed into DPLL algorithm, we took an program equivalence
checking problem. Particulary, we check equivalence of programs where each program
implement a FIFO queue, but in different way (the problem is taken from [4]).

The problem is encoded in a Conjunctive Normal Form (CNF)formula d, such that
if DPLL(d) = Unsat, it means an equivalence of programs. Otherwise the algorithm
outputs a counter-example.

In this experiment, we were interested in the following:

1. How much the computation time of the function f will change between the usual
recursive form (T1) and its iterative form (T2).

2. How much a bytecode size of the function f will change between the usual recursive
(S1) and iterative (S2) forms.

3. What will be a number of iterations needed to get from the initial point to a
fixpoint of f (denoted as n); what will be a certificate size (Cf )?

4. What will be the greatest size of an intermediary function result f i(d) (denoted
as dmax), and the size of initial point d0?

Experiments were carried out on a computing node Intel Xeon Gold 6254 CPU
3.10GHz x 4 Cores, 16GB RAM; Execution environment: Erlang 20, ERTS 9.3.3.11,
running under Linux Fedora 29 OS.

d0 S1 S2 T1 T2 dmax Cf n

QueueInvar2 5703 2064 2272 0.1 0.4 42028 52992 1656

QueueInvar4 13707 2064 2272 193 423 170758 13145664 410802

Here T1, T2 is measured in seconds, d0, dmax, S1, S2, Cf - in bytes, n - number of itera-
tions.

Besides, we implemented the solution refutation step scenario consisting of the fol-
lowing steps:

1. The user task DPLL(x) presented in an iterative form is published together with
the initial data d.

The size of a user task S2 and its data d0 permits to send it into TW";"""date"",""2020-05-25T00:44:11Z""
""pdf:PDFVersion"",""1.4""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.4""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""xmp:CreateDate"",""2020-05-24T20:44:11Z""
""modified"",""2020-05-25T00:44:11Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""xmp:ModifyDate"",""2020-05-24T20:44:11Z""
""pdf:docinfo:creator"",""""
""meta:author"",""""
""meta:creation-date"",""2020-05-25T00:44:11Z""
""created"",""2020-05-25T00:44:11Z""
""xmp:About"",""uuid:6612eb3a-d63d-11f5-0000-943406915bab""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-05-25T00:44:11Z""
""resourceName"",""2005.10786""
""Author"",""""
""producer"",""dvips + GPL Ghostscript GIT PRERELEASE 9.22""
""pdf:docinfo:producer"",""dvips + GPL Ghostscript GIT PRERELEASE 9.22""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""2"",""0"",""4"",""1"",""28"",""12"",""7"",""6"",""2"",""0"",""0"",""0"",""0"",""0"",""0"",""19"",""7""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2020-05-25T00:44:11Z""
""Last-Modified"",""2020-05-25T00:44:11Z""
""dcterms:modified"",""2020-05-25T00:44:11Z""
""title"",""""
""xmpMM:DocumentID"",""uuid:6612eb3a-d63d-11f5-0000-943406915bab""
""Last-Save-Date"",""2020-05-25T00:44:11Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2020-05-25T00:44:11Z""
""meta:save-date"",""2020-05-25T00:44:11Z""
""Content-Length"",""241560""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""19""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""1782"",""2756"",""1659"",""2336"",""2527"",""1608"",""1798"",""1305"",""1819"",""2152"",""2399"",""2572"",""2113"",""2452"",""3007"",""2313"",""2334"",""1362"",""1346""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-05-25T00:44:11Z""
";https://scholar.google.ch/scholar?start=760&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098782-145;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Improved extension protocols for byzantine broadcast and agreement;K Nayak, L Ren, E Shi, NH Vaidya, Z Xiang ; arXiv preprint arXiv …, 2020  arxiv.org;;"… For example, practical blockchain systems typically achieve agreement on large (eg, 1MB) blocks …

the cryptographic primitives and the costs of state-of-the-art BB/BA oracle schemes can … hash

functions, it is common to model practical hash functions as random oracles, in which …";Cité 7 fois;Les 4 versions;[PDF] arxiv.org;https://arxiv.org/pdf/2002.11321;"
ar
X

iv
:2

00
2.

11
32

1v
3 

 [
cs

.C
R

] 
 5

 O
ct

 2
02

0

Improved Extension Protocols for Byzantine Broadcast and

Agreement ∗

Kartik Nayak1, Ling Ren2, Elaine Shi3, Nitin H. Vaidya4, and Zhuolun Xiang †5

1Duke University, kartik@cs.duke.edu
2, 5University of Illinois at Urbana-Champaign, {renling, xiangzl}@illinois.edu

3Cornell University, runting@gmail.com
4Georgetown University, nitin.vaidya@georgetown.edu

October 7, 2020

Abstract

Byzantine broadcast (BB) and Byzantine agreement (BA) are two most fundamental prob-
lems and essential building blocks in distributed computing, and improving their efficiency is
of interest to both theoreticians and practitioners. In this paper, we study extension proto-
cols of BB and BA, i.e., protocols that solve BB/BA with long inputs of l bits using lower
costs than l single-bit instances. We present new protocols with improved communication com-
plexity in almost all settings: authenticated BA/BB with t < n/2, authenticated BB with
t < (1 − ǫ)n, unauthenticated BA/BB with t < n/3, and asynchronous reliable broadcast and
BA with t < n/3. The new protocols are advantageous and significant in several aspects. First,
they achieve the best-possible communication complexity of Θ(nl) for wider ranges of input
sizes compared to prior results. Second, the authenticated extension protocols achieve optimal
communication complexity given the current best available BB/BA protocols for short mes-
sages. Third, to the best of our knowledge, our asynchronous and authenticated protocols in
the setting are the first extension protocols in that setting.

1 Introduction

This paper investigates extension protocols [17] for Byzantine broadcast (BB) and Byzantine agree-
ment (BA). The goal of BB is for some designated party (sender) to send its message to all parties
and let them output the same message, despite some malicious parties that may behave in a
Byzantine fashion. The goal of BA is to let all parties each with an input message output the same
message. We are interested in designing efficient BB/BA protocols with long messages since such

∗Elaine Shi is supported in part by NSF award 1561209, and part of the work was done when the author was
a long-terms visitor in Simons Institute for the “Proofs, Consensus, and Decentralizing Societ” program. Nitin H.
Vaidya is supported in part by NSF award 1849599. Kartik Nayak and Ling Ren are supported in part by a VMware
early career faculty grant.

†Lead author.

1

http://arxiv.org/abs/2002.11321v3


Threshold Model Problem
Communication

Complexity

Input range l
to reach optimality

Reference

t < n/2 sync. agreement/broadcast
O(nl + nB(k) + kn3)
O(nl +A(k) + kn2) 2

Ω(n3 + kn2)
Ω(n2 + kn)

[17, 18]
This paper

t < n sync. broadcast O(nl + B(nk) + n2B(n log n)) Ω(n5 log n+ kn4 log n) [17, 18]

t < (1− ε)n sync. broadcast O(nl + B(k) + kn2 + n3) Ω(n2 + kn) This paper

t < n/3 async.
agreement
reliable broadcast

O(nl +A(k) + kn2)
O(nl + B(k) + kn2)

Ω(kn)
Ω(kn)

This paper

This paper

Table 1: Cryptographically Secure Extension Protocols for Byzantine Agreement and Broadcast

protocols are widely used as building blocks for other distributed systems such as multi-party com-
putation [34] and permissioned blockchain [26]. For example, practical blockchain systems typically
achieve agreement on large blocks (e.g., 1MB).

A straightforward solution for BB/BA with l-bit long messages is to invoke the single-bit BB/BA
oracle l times. This approach will incur at least Ω(n2l) communication complexity where n is the
number of parties, because any deterministic single-bit BB/BA has cost Ω(n2) due to a lower bound
in [12]. Another tempting solution is to run BB/BA on the hash digest and let parties disseminate
the actual message to each other. However, if a linear fraction of parties can be Byzantine (which
is the typical assumption), they can each ask all honest parties for the long message, again forcing
the communication complexity to be Ω(n2l).

It turns out that non-trivial techniques are needed to get better than Ω(n2l) or to achieve the op-
timal communication complexity of O(nl). These are known in the literature as extension protocols,
which construct BB/BA with long input messages using a small number of BB/BA primitives for
short messages. In this paper, we focus on the authenticated setting where cryptographic techniques
are used. Table 1 summarizes the most closely related works and our new results on authenticated
extension protocols. (In Appendix C, we will present some improvements to unauthenticated ex-
tension protocols.) In Table 1, n is the number of parties, t is the maximum number of Byzantine
parties, l is the length of the input, A(l) is the communication cost of l-bit BA oracle, and B(l) is
the communication cost of l-bit BB or reliable broadcast oracle. Here we describe the related works
in the table. Let kh denote output size of the collision-resistant hash function. For both Byzantine
broadcast and agreement in the synchronous setting under t < n/2, recent work proposes crypto-
graphically secure extension protocols with communication cost O(nl+nB(kh)+n3kh) [17, 18]. For
the case of t < n, the state-of-the-art cryptographically secure BB extension protocols have com-
munication complexity O(nl + B(nkh) + n2B(n log n)) [17, 18]. There exist information-theoretic
authenticated protocols [16, 10] but they have worse communication complexity than cryptographic
ones. To the best of our knowledge, there exist no extension protocols in the authenticated and
asynchronous setting when the paper is written 1.

Contributions. Table 1 also presents our improved protocols in the respective settings. Several
cryptographic primitives have been employed in our work and prior works. To make the communi-
cation costs comparable, we assume that the output length of the involved cryptographic building
blocks are on the same order, and are all represented by k. We will justify this decision in Section 3.

All our protocols achieve the optimal communication complexity O(nl) for wider ranges of input
sizes (see Table 1 above for authenticated protocols and Table 2 in Appendix C for unauthenticated

1A concurrent work [23] independently developed an extension protocol for validated Byzantine agreement in the
authenticated and asynchronous setting.

2Our cryptographic BB extension protocol can achieve O(nl + B(k) +A(1) + kn
2) in Appendix B.

2



protocols). In particular, our synchronous and authenticated protocols achieve O(nl) communica-
tion complexity when the input size is at least l = Ω(n2+kn). For comparison, state-of-art protocol
in the literature require a factor of n larger input size for the t < n/2 case, and a factor of n3 log n
larger input size for n/2 ≤ t < (1 − ε)n where ε is a constant. But a limitation of our protocol
is that it cannot achieve O(nl) communication if Îľ = o(1). As for the round complexity, all our
extension protocols only adds O(1) communication rounds, except the one for t < n/2 which adds
O(t) rounds. All our protocols only invoke the BB/BA oracle O(1) times.

In addition to reaching optimality under smaller input size, our authenticated extension proto-
cols have the following advantages.

• The communication complexity of our BA extension protocols is very close to the lower bound
Ω(nl+A(k)+n2). In addition, under the current best BA primitives for short messages, they
achieve best-possible communication complexity. In order to improve upon our extension
protocols, one must invent BA primitives for short messages with cost o(kn2), which seems
challenging as we discuss in Section 4.3.

• Our protocols can be easily adapted to the asynchronous setting. To the best of our knowledge,
these are the first asynchronous authenticated extension protocols. 3

• Their simplicity makes our protocols less error-prone and more appealing for practical adop-
tion. On this note, in deriving our results, we discover a flaw in the prior best protocol [17, 18]
and we provide a simple fix (Appendix D).

2 Related Work

Timing and setup assumptions. With different security assumptions on the adversary and timing
assumptions, Byzantine broadcast and agreement can be solved for different thresholds of the
Byzantine parties. For the timing assumptions, protocols under both synchrony and asynchrony
have been studied. If a trusted setup like public-key infrastructure (PKI) exists, it is called the
authenticated setting; otherwise, it is the unauthenticated setting. In the synchronous setting,
BB/BA can be solved under t < n/3 without authentication [21]; with authentication, BA can be
solved under t < n/2 and BB can be solved under t < n [21, 13, 31]. In the asynchronous setting,
BB is impossible; BA (randomized) and reliable broadcast can be solved under t < n/3 with or
without authentication [7, 8].

Previous extension protocols. Table 1 summarizes the two most closely related works on authen-
ticated extension protocols. Here, we mention several other ones. Cachin and Tessaro [9] adapt
Bracha’s broadcast [7] to handle l-bit long messages with communication cost O(nl + khn

2 log n).
Their method partially inspired our work; but their method does not seem to apply to general
protocols and hence does not yield an extension protocol. Related unauthenticated extension pro-
tocols are summarized in Table 2 in Appendix C. Liang and Vaidya [22] propose the first optimal
error-free BB and BA with communication complexity O(nl+(n2

√
l+n4)B(1)) for the synchronous

case. Patra [30] improves the communication complexity to O(nl + n2B(1)) under synchrony and
also extended the protocols to asynchrony with increased communication complexity (see Table 2).

State-of-the-art oracle schemes. To better interpret the improvements we obtained for extension
protocols, we provide a summary of the state-of-the-art broadcast and agreement protocols that can

3Asynchronous unauthenticated protocol exist and they can be used in the authenticated setting, but the cost
would be much higher than our new protocols (refer to Table 2 in Appendix C.)

3



be used as the oracle in our extension protocol. Since our extension protocols are all deterministic,
we focus on deterministic solutions for the most part of the paper, except for asynchronous BA where
randomization is necessary. The best deterministic solution to authenticated BB for t < n is the
classic Dolev-Strong [13] protocol. After applying multi-signatures, the communication complexity
to broadcast k bits is B(k) = Θ((k + ks)n

2 + n3) where ks is the signature size. The Dolev-Strong
protocol can also be modified to solve authenticated BA for the t < n/2 case (BA is impossible
if t ≥ n/2). Using an initial all-to-all round with multi-signature to simulate the sender, the
communication complexity remains as A(k) = Θ((k+ ks)n

2 + n3). In the unauthenticated setting,
only t < n/3 Byzantine parties can be tolerated and Berman et al. [4] achieves B(1) = A(1) = Θ(n2)
(when t = Θ(n)), matching the lower bound on communication complexity.

In the asynchronous setting, Bracha’s reliable broadcast [7] is deterministic and has commu-
nication complexity B(1) = O(n2). Randomization is necessary for asynchronous BA given the
FLP impossibility [15]. State-of-art protocols rely on “common coins” to provide shared random-
ness but are deterministic otherwise. The most efficient unauthenticated asynchronous BA [27]
achieves expected communication complexity A(1) = O(n2) assuming a common coin oracle. The
most efficient authenticated asynchronous BA [1] achieves expected communication complexity
A(k) = O((k + ks)n

2) and provides a construction for the common coin oracle.

Coding schemes in consensus systems. Several works have taken advantage of coding schemes in
practical fault-tolerant consensus systems. HoneyBadgerBFT [26] and BEAT [14] use the reliable
broadcast proposed by Cachin and Tessaro [9] as a component for broadcasting blocks efficiently.
Recent works also apply erasure coding to crash-tolerant systems like Paxos [28] and Raft [33].

3 Preliminaries

We consider n parties P1, ..., Pn connected by a reliable, authenticated all-to-all network, where up
to t parties may be corrupted by an adversary A and behave in a Byzantine fashion. We consider
both the synchronous model, where there exists a known upper bound on the communication
and computation delay, and the asynchronous model, where such an upper bound does not exist.
We consider a static adversary which decides the set of corrupted parties at the beginning of
the execution. We denote parties that are not corrupted by the adversary as honest parties.
Two types of the adversary are considered: a computationally bounded adversary is considered
in cryptographically secure protocols and a computationally unbounded adversary is considered
in the error-free protocols. Our cryptographically secure protocols additionally assume a trusted
setup for a public key infrastructure (PKI) and cryptographic accumulators (see Section 3.1). The
communication complexity [35] of the protocol is measured by the worst-case or expected number
of bits transmitted by the honest parties according to the protocol specification over all possible
executions under any adversary strategy. Here, we provide the formal definition of Byzantine
broadcast (BB) and Byzantine agreement (BA).

Definition 1 (Byzantine Broadcast). A protocol for a set of parties P = {P1, ..., Pn}, where a
distinguished party called the sender Ps ∈ P holds an initial l-bit input m, is a Byzantine broadcast
protocol tolerating an adversary A, if the following properties hold

• Termination. Every honest party outputs a message.
• Agreement. All the honest parties output the same message.
• Validity. If the sender is honest, all honest parties output the message m.

4



Definition 2 (Byzantine Agreement). A protocol for a set of parties P = {P1, ..., Pn}, where
each party Pi ∈ P holds an initial l-bit input mi, is a Byzantine agreement protocol tolerating an
adversary A, if the following properties hold

• Termination. Every honest party outputs a message.
• Agreement. All the honest parties output the same message.
• Validity. If every honest party Pi holds the same input message m, then all honest parties
output the message m.

For cryptographically secure protocols and randomized protocols, the above properties hold
except for a negligible probability in the security parameter. For brevity, our theorem statements
will not mention this explicitly.

3.1 Primitives

In this section, we define several primitives that will be used in our extension protocols. Our
extension protocols use standard coding and cryptographic schemes from the literature, such as
linear error correcting codes, muti-signature schemes and cryptographic accumulators.

Linear error correcting code [32]. We will use standard Reed-Solomon (RS) codes [32] in our
protocols, which is a (n, b) RS code in Galois Field F = GF (2a) with n ≤ 2a − 1. This code
encodes b data symbols from GF (2a) into codewords of n symbols from GF (2a), and can decode
the codewords to recover the original data.

• ENC. Given inputsm1, ...,mb, an encoding function ENC computes (s1, ..., sn) = ENC(m1, ...,mb),
where (s1, ..., sn) are codewords of length n. By the property of the RS code, knowledge of
any b elements of the codeword uniquely determines the input message and the remaining of
the codeword.

• DEC. The function DEC computes (m1, ...,mb) = DEC(s1, ..., sn), and is capable of tolerating
up to c errors and d erasures in codewords (s1, ..., sn), if and only if n − b ≥ 2c + d. In our
protocol, We will invoke DEC with specific values of c, d satisfying the above relation, and DEC

will return correct output.
In our extension protocols, we will use the above RS codes with n equal the number of all parties,
and b equal the number of honest parties, i.e., b = n− t.

Multi-signatures [6]. Multi-signature scheme can aggregate n signatures into one signature, there-
fore reduce the size of signatures. Given n signatures σi = Sign(ski,m) on the same message m
with corresponding public keys pki for 1 ≤ i ≤ n, a multi-signature scheme can combine the n
signatures above into one signature Σ where |Σ| = |σi|. The combined signature can be verified by
anyone using a verification function Ver(PK,ÎŁ,m,L), where L is the list of signers and PK is the
union of n public keys pki.

Cryptographic accumulators [2, 11]. We present the definition of cryptographic accumulators
proposed by Barić and Pfitzmann [2]. Intuitively, the cryptographic accumulator constructs an
accumulation value for a set of values and can produce a witness for each value in the set. Given
the accumulation value and a witness, any party can verify if a value is indeed in the set. Formally,
given a parameter k, and a set D of n values d1, ..., dn, an accumulator has the following components:

• Gen(1k, n): This algorithm takes a parameter k represented in unary form 1k and an accumula-
tion threshold n (an upper bound on the number of values that can be accumulated securely),

5



returns an accumulator key ak. This step is run by a trusted dealer, so the accumulator key
ak is known to all parties.

• Eval(ak,D): This algorithm takes an accumulator key ak and a set D of values to be accu-
mulated, returns an accumulation value z for the value set D.

• CreateWit(ak, z, di): This algorithm takes an accumulator key ak, an accumulation value z
for D and a value di, returns ⊥ if di /∈ D, and a witness wi if di ∈ D.

• Verify(ak, z, wi, di): This algorithm takes an accumulator key ak, an accumulation value z
for D, a witness wi and a value di, returns true if wi is the witness for di ∈ D, and false
otherwise.

For simplicity, our definition of the cryptographic accumulator above omits the auxiliary infor-
mation aux that appears in the standard definition [2] because the bilinear accumulator we will use
does not use aux. We also assume that the function Eval is deterministic, which is the case with
the bilinear accumulator. We give the detailed description of the bilinear accumulator [29, 19] in
Appendix A. The bilinear accumulator satisfies the following property.

Lemma 1 (Collision-free accumulator [29]). The bilinear accumulator is collision-free. That is, for
any set size n and any probabilistic polynomial-time adversary A, there exists a negligible function
negl(¡), such that

Pr

[

ak ← Gen(1k, n), ({d1, ..., dn}, d′, w′)← A(1k, n, ak), z ← Eval(ak, {d1, ..., dn}) :
(d′ /∈ {d1, ..., dn}) ∧ (Verify(ak, z, w′, d′) = true)

]

≤ negl(k)

To better understand the definition of the cryptographic accumulator, it is helpful to note that
the Merkle tree [25] is a cryptographic accumulator, where the accumulator key ak is the hash
function, the accumulation value z is the Merkle tree root, and the witness w is the Merkle tree
proof. We will use the bilinear accumulator [29, 19] instead of Merkle tree in our protocols, since
the witness size of the Merkle tree is logarithmic in the number of values whereas the witness size
of the bilinear accumulator is a constant. On the other hand, the bilinear accumulator requires
a trusted dealer, which is a stronger trust assumption than public key infrastructure (PKI). The
trusted dealer needs to know an upper bound on |D|, i.e., the number of items accumulated (see the
construction in Appendix A). In our protocols, |D| always equals the number of parties n. Hence,
the trusted setup (both the PKI and the accumulator) can be reused across invocations if the parties
participating in the extension protocol do not change. If a trusted dealer for accumulators cannot
be assumed, our protocol can use Merkle tree as the accumulator; in that case, the O(kn2) term
in the communication complexity becomes O(kn2 log n) and our protocol still has an advantage
(albeit smaller) over prior art.

Normalizing the length of cryptographic building blocks. Let Îť denote the security parameter,
kh = kh(Îť) denote the hash size, ks = ks(Îť) denote the (multi-)signature size, ka = ka(Îť) denote
the size of the accumulation value and witness of the accumulator. Further let k = max(kh, ks, ka);
we assume k = Θ(kh) = Θ(ks) = Θ(ka) = Θ(Ν) This assumption is reasonable since the signature
scheme and accumulator scheme with the shortest output length are both based on pairing-friendly
curves, which are believed to require Θ(Ν) bits for Ν-bit security given the state-of-the-art attack
[20]. As for hash functions, it is common to model them as random oracles, in which case Îť-bit
security requires Θ(Ν)-bit hash size. Therefore, throughout the paper, we can use the same variable
k to denote the hash size, signature size and accumulator size for convenience.

6



4 Cryptographically Secure Extension Protocols under t < n/2

Faults

In this section, we design cryptographically secure extension protocols with improved communi-
cation complexity for the synchronous and authenticated setting with t < n/2 faults. We start
by presenting some building blocks that will be frequently used in all our authenticated proto-
cols. Then, we give an extension protocol for synchronous BA with communication complexity
O(nl +A(k) + kn2). Under synchrony, this also implies a BB protocol with t < n/2 and the same
communication complexity, by first having the sender send the message to all parties and then
performing a Byzantine agreement [24]. In Appendix B, we show another extension protocol for
t < n/2 BB with communication complexity O(nl+B(k)+A(1)+kn2). The protocols are adapted
to the asynchronous case in Section 6. At the end of this section, we discuss the small gap between
our BA protocol and a simple lower bound on BA with long messages.

4.1 Building Blocks: Encode, Distribute and Reconstruct

We first define three subprotocols Encode, Distribute and Reconstruct that will be used as
building blocks for our cryptographically secure extension protocols, listed in Figure 1.

• Encode first divides a message m into b blocks, then compute n coded values (s1, ..., sn) using
RS codes (defined in Section 3), and attaches an index j for each value sj. The purpose of
Encode is to introduce resilience by encoding the message into fault-tolerant coded values –
after applying Encode to a message m, even if n − b coded values in (s1, ..., sn) are erased,
one can recover the message from the remaining coded values.

• Distribute computes a witness wj for each indexed value 〈j, sj〉 in the input set, and sends the
j-th value with its witness to party j. The purpose of Distribute is to distribute the values
in a robust yet efficient manner – if at least one honest party that has the correct message
m (the accumulation value z of m is correct) invokes Distribute, then it is guaranteed that
any honest party j receives and accepts the j-th value sj of m, thanks to the witness wj sent
together with the value.

• Reconstruct first removes any invalid value sj that cannot be verified by witness wj and the
accumulation value z, and then decode the message m using RS code (defined in Section 3)
from the remaining values with at most d0 values being removed. The purpose of Reconstruct
is to recover the message, despite the presence of at most d0 corruptions in the value, which
will be detected by the accumulator scheme and thus erased.

Our extension protocols in Sections 4 and 5 will use Encode at the beginning of the protocol
to encode the input message to coded values, use Distribute in the middle to let every party
distribute their coded values with the witnesses, and use Reconstruct to reconstruct the original
input message after receiving the coded values.

Lemma 2. For any message m, let z = Eval(ak, Encode(m, b)). The adversary cannot find m′ 6= m
such that z = Eval(ak, Encode(m′, b)) except for negligible probability in k.

Proof. Let D = Encode(m, b) and D′ = Encode(m′, b). By the RS code, the same codewords
correspond to the same message. Thus, if m 6= m′, we have D 6= D′, i.e., there exists d′ = 〈i, si〉
such that d ∈ D and d′ 6∈ D′. However, under the accumulation value z = Eval(ak,D′)), a witness
for d = 〈i, si〉 6∈ D′ exists. Due to Lemma 1, this happens with negligible in k probability.

7



• Encode(m, b)

Input: a message m, a number b

Output: n coded values s1, ..., sn

Divide m into b blocks evenly, m1, ...,mb, each has l/b bits where l is the length of m.
Compute (s1, ..., sn) = ENC(m1, ...,mb) using RS codes, where ENC is defined in Section
3.1. Add an index to every value in (s1, ..., sn), i.e., D = (〈1, s1〉, ..., 〈n, sn〉), and return
D.

• Distribute(D, ak, z)
Input: a set of indexed values D = (〈1, s1〉, ..., 〈n, sn〉), an accumulator key ak, an
accumulation value z

Compute wj = CreateWit(ak, z, 〈j, sj〉) for every 〈j, sj〉 ∈ D. Send (sj, wj) to party Pj

for every j ∈ [n].

• Reconstruct(S, ak, z, d0)
Input: S = ((〈1, s1〉, w1), ..., (〈n, sn〉, wn)) where each (〈i, si〉, wi) is a pair of indexed
value and witness, an accumulator key ak, an accumulation value z, a number d0

Output: a message m

For every j ∈ [n], if Verify(ak, z′, wj , 〈j, sj〉) = false, let sj = ⊥. Apply DEC on the
codewords (s1, ..., sn) with c = 0 and d = d0, where DEC is defined in Section 3.1. Return
m = m1|...|mb where m1, ...,mb are the data returned by DEC.

Figure 1: Building Blocks

4.2 Byzantine Agreement under < n
2
faults

The protocol Synchronous Crypto. n
2 -BA is presented in Figure 2. In the protocol, let t denote

the maximum number of Byzantine parties, and let b = n− t. We briefly describe each step of the
protocol. First, each party encodes its message using RS codes and computes the accumulation
value for the set of coded values. With a deterministic Eval, any honest party with the same
accumulator key and set will produce the same accumulation value. The RS codes can recover the
message with up to t coded values being erased, and the accumulation value uniquely corresponds
to the set of coded values and equivalently the original message (Lemma 2). Then every party runs
an instance of k-bit Byzantine agreement with the accumulation value as the input. After the above
agreement terminates, each party checks whether the agreement output matches its accumulation
value, and inputs the result to an 1-bit Byzantine agreement instance. If the above agreement
outputs 0, all parties output ⊥ and abort. If the above agreement outputs 1, then at least one
honest party has the accumulation value zi matching with the agreement output z, and every honest
party will agree on the message corresponding to z. Then in Distribute, all parties send the j-th
coded value to party Pj. After that, each honest party Pj will send a valid j-th coded value to all
other parties, from which the correct message can be obtained in Reconstruct. One nice property
of our protocol is that, if at least one honest party with message m invokes Distribute, then all
honest parties can obtain m from Reconstruct (see the proof of Lemma 4). We prove the validity

8



Input of every party Pi: An l-bit message mi

Primitives: Byzantine agreement oracle, cryptographic accumulator with Eval, CreateWit,
Verify

Protocol for party Pi:

1. Compute Di = (〈1, s1〉, ..., 〈n, sn〉) = Encode(mi, b). Compute the accumulation value
zi = Eval(ak,Di). Input zi to an instance of k-bit BA oracle.

2. When the above BA outputs z, if z = zi, set happyi = 1, otherwise set happyi = 0.
Input happyi to an instance of 1-bit Byzantine agreement oracle.

3. • If the above BA outputs 0, output oi = ⊥ and abort.

• If the above BA outputs 1 and happyi = 1, invoke Distribute(Di, ak, z).

4. For the set of pairs {(si, wi)} received from the previous step, if there exists a pair
(si, wi) such that Verify(ak, z, wi, 〈i, si〉) = true, then send (si, wi) to all other parties.

5. If happyi = 1, set oi = mi. Otherwise, let (sj , wj) be the message received from
party Pj from the previous step and Si = ((〈1, s1〉, w1), ..., (〈n, sn〉, wn)), and set oi =
Reconstruct(Si, ak, z, t).

6. Output oi.

Figure 2: Protocol Synchronous Crypto. n
2 -BA

and agreement properties and analyze the communication complexity below.

Lemma 3. If every honest party has the same input message mi = m, all honest parties output
the same message m.

Proof. If all honest parties have the same input message mi = m, they compute and input the
same accumulation value z to the instance of Byzantine agreement in step 1. Then in step 2, the
BA outputs z by the validity condition, and any honest party sets happyi = 1. Therefore, every
honest party Pi inputs 1 to the 1-bit Byzantine agreement oracle in step 2. By the validity of the
Byzantine agreement oracle, the agreement will output 1. Then any honest party Pi sets oi = m
in step 5 since happyi = 1. Hence, all honest parties output m when the protocol terminates.

Lemma 4. All honest parties output the same message.

Proof. If the Byzantine agreement in step 3 outputs 0, then all honest parties output the same
message ⊥. If the agreement agreement in step 3 outputs 1, then by the validity of the Byzantine
agreement, some honest party Pi must input 1 and thus has zi = z. By Lemma 2, any honest party
Pi with happyi = 1 has the identical message m corresponding to z, and sets the output to be m
at step 5. In step 3, any honest party Pi with happyi = 1 invokes Distribute to compute witness
wj for each index value 〈j, sj〉, and sends the valid (sj , wj) pair computed from message m to party
Pj for every Pj . By Lemma 1, the Byzantine parties cannot generate a different pair (s′j, w

′
j) that

can be verified. Therefore, in step 4, every honest party Pj receives at least one valid (sj , wj) pair,
and forwards it to all other parties. Since there are at least b = n− t honest parties, in step 5, each
honest party will receive at least b valid coded values. In Reconstruct, using the accumulation

9



value associated with the coded value, any party Pi can detect the corrupted values and remove
them. By the property of RS codes, any honest party Pi with happyi = 0 is able to recover the
message m, and any honest party Pi with happyi = 1 already has the message m. Therefore all
honest parties outputs m.

Theorem 1. Protocol Synchronous Crypto. n
2 -BA satisfies Termination, Agreement and Validity,

and has communication complexity O(nl+A(k) + kn2).

Proof. Termination is clearly satisfied. By Lemma 4, agreement is satisfied. By Lemma 3, validity
is satisfied.

Step 1 has cost A(k), where k is the size of the cryptographic accumulator. Step 2 has
cost A(1) ≤ A(k). Step 3 has cost O(nl + kn2), since each honest party invokes an instance
of Distribute, which leads to an all-to-all communication with each message of size O(l/b+ k) =
O(l/n + k). For step 4, it also has cost O(nl + kn2) similarly as step 3. Hence the total cost is
O(nl +A(k) + kn2).

4.3 Lower Bound on BA for Long Messages

Let A(l) denote the communication complexity in bits of the best possible deterministic protocol
for Byzantine agreement with l-bit inputs, n parties, and up to t = Θ(n) faulty parties. We show a
straightforward lower bound that A(l) = Ω(nl +A(k) + n2) for l ≥ k by combining several known
lower bounds in the literature.

Theorem 2. A(l) = Ω(nl +A(k) + n2) for l ≥ k.

Proof. The proof combines several simple lower bounds known in the literature.
First of all, A(l) = Ω(nl) according to [16]. We briefly mention the proof idea from [16] for

completeness. Let a set A of n− t parties have input m and a set B of the rest t parties have input
m′ 6= m. In scenario 1, let parties in B be Byzantine but behave as if they are honest. Then by
the validity condition, all parties in A will output m. In scenario 2, let parties in B be honest. To
parties in A, the scenario 2 is indistinguishable from scenario 1, and thus they will output m. By
the agreement condition, parties in B also need to output m. Therefore each party in B needs to
learn the message m, which leads to a lower bound on the communication cost of Ω(tl) = Ω(nl).

Secondly, since A(l) denotes the communication complexity of a BA oracle with l-bit inputs, it
is clear that A(l) ≥ A(k) for l ≥ k.

Finally, according to [12], Ω(n2) is a lower bound on the communication complexity for any
deterministic Byzantine agreement protocol tolerating t = Θ(n) faults (even for single-bit inputs).
Thus, A(l) ≥ A(1) = Ω(n2).

The above lower bounds together imply a low";"""date"",""2020-10-07T03:37:51Z""
""pdf:PDFVersion"",""1.4""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.4""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""xmp:CreateDate"",""2020-10-06T23:37:51Z""
""modified"",""2020-10-07T03:37:51Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""xmp:ModifyDate"",""2020-10-06T23:37:51Z""
""pdf:docinfo:creator"",""""
""meta:author"",""""
""meta:creation-date"",""2020-10-07T03:37:51Z""
""created"",""2020-10-07T03:37:51Z""
""xmp:About"",""uuid:06a6c542-406b-11f6-0000-0050aa6e26d4""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-10-07T03:37:51Z""
""resourceName"",""2002.11321""
""Author"",""""
""producer"",""dvips + GPL Ghostscript GIT PRERELEASE 9.22""
""pdf:docinfo:producer"",""dvips + GPL Ghostscript GIT PRERELEASE 9.22""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""2"",""11"",""20"",""12"",""1"",""6"",""2"",""4"",""12"",""8"",""2"",""0"",""0"",""0"",""7"",""8"",""0"",""0"",""2"",""3"",""1"",""1"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2020-10-07T03:37:51Z""
""Last-Modified"",""2020-10-07T03:37:51Z""
""dcterms:modified"",""2020-10-07T03:37:51Z""
""title"",""""
""xmpMM:DocumentID"",""uuid:06a6c542-406b-11f6-0000-0050aa6e26d4""
""Last-Save-Date"",""2020-10-07T03:37:51Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2020-10-07T03:37:51Z""
""meta:save-date"",""2020-10-07T03:37:51Z""
""Content-Length"",""360678""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""29""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""2077"",""3268"",""3061"",""3138"",""2690"",""3004"",""2844"",""2246"",""2297"",""2624"",""2054"",""3336"",""2748"",""1860"",""2045"",""2642"",""2329"",""2274"",""2259"",""2371"",""2104"",""2117"",""2957"",""2001"",""2874"",""2086"",""2524"",""1744"",""1569""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-10-07T03:37:51Z""
";https://scholar.google.ch/scholar?start=690&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098782-142;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Improved Security Proof for the Camenisch-Lysyanskaya Signature-Based Synchronized Aggregate Signature Scheme;CL Signature;Based  Information Security and Privacy: 25th Australasian …, 2020  Springer;;"… The Camenisch-Lysyanskaya signature scheme in CRYPTO 2004 is a useful building block to …

For instance, we consider a blockchain protocol that records several signed transactions in each

new … One is constructed in the ran- dom oracle model and the other is constructed in …";Autres articles;;null;;;;https://scholar.google.ch/scholar?start=690&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098769-113;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Blockchain security: A survey of techniques and research directions;J Leng, M Zhou, LJ Zhao, Y Huang… ; IEEE Transactions on …, 2020  ieeexplore.ieee.org;;"… Oracle View Fraud Detection • Monitoring & Profiling • Access Controls • Violation Detection • Audit

& Behavior Analysis Data Security • Access Controls … B. Implementation security of blockchain Apart

from the well-known cryptocurrency and blockchain-based Fintech …";Cité 2 fois;Les 2 versions;null;;;;https://scholar.google.ch/scholar?start=660&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098765-107;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Proposal for a Comprehensive (Crypto) Asset Taxonomy;T Ankenbrand, D Bieri, R Cortivo… ; … on Blockchain …, 2020  ieeexplore.ieee.org;;"… D. CryptoKitties CryptoKitties (see Appendix E), as the last example from the crypto space, are

collectible digital representations of cats created on the Ethereum blockchain … being the supreme

organ of a stock corporation, ie, acting as a qualitative oracle interface …";Cité 9 fois;Les 7 versions;[PDF] arxiv.org;https://arxiv.org/pdf/2007.11877;"
Proposal for a Comprehensive
(Crypto) Asset Taxonomy

Thomas Ankenbrand & Denis Bieri, Lucerne University of
Applied Sciences and Arts;

Roland Cortivo & Johannes Hoehener, Swisscom AG;
Thomas Hardjono, MIT Connection Science

July 24, 2020

Abstract—Developments in the distributed ledger technology have
led to new types of assets with a broad range of purposes.
Although some classification frameworks for common instru-
ments from traditional finance and some for these new, so-
called cryptographic assets already exist and are used, a holistic
approach to integrate both worlds is missing. The present paper1

fills this research gap by identifying 14 attributes, each of which is
assigned different characteristics, that can be used to classify all
types of assets in a structured manner. Our proposed taxonomy,
which is an extension of existing classification frameworks,
summarises these findings in a morphological box and is tested
for practicability by classifying exemplary assets like cash and
bitcoin. The final classification framework can help to ensure that
the various stakeholders, such as investors or supervisors, have a
consistent view of the different types of assets, and in particular
of their characteristics, and also helps to establish standardised
terminology.

I. INTRODUCTION

Since the inception of the Bitcoin network in the year 2009,
the space for cryptographic assets has developed rapidly.
The continuing technological innovation in the underlying
distributed ledger technology could consequently lead to an
increasing transformation of traditional financial markets into
crypto-based markets. Although different asset classification
frameworks exist for both worlds, a holistic approach merging
both traditional finance and the crypto economy is still lacking.
This poses a challenge to the various stakeholders such as
investors or regulators in retaining an overview of existing
assets of different types and, in particular, of their design and
individual characteristics. In order to fill this lack of research,
we propose a taxonomy for the systematic classification of all
types of assets, be it of physical, digital or tokenised nature.

II. LITERATURE REVIEW

The characteristics and properties of the most common types
of financial instruments such as stocks, bonds, and derivatives
have been the subject of research for some time, not only
in the academia, but also in the industry. Therefore, a wide
range of publications exist that deal with the functioning of
these different instruments in a structured way.

One framework defining the structure and format for the
classification of financial instruments (CFI) was first proposed
by the International Organization for Standardization (ISO)
in the year 1997. The last revised version of the framework is

1Our research is part of the FinTech programme supported by Finnova,
Inventx, Swiss Bankers Prepaid Services, and Swisscom.

called ISO 10962:2019 and was published by ISO in 2019. It
seeks to provide a standard for identifying the type of financial
instrument and its main high-level features in the form of
specific codes consisting of six alphabetical characters, and
should thus help to standardise country and institution-specific
terminology in relation to financial instruments [1]. The first
character of the CFI code indicates the main category of
financial instruments. These include equities, collective
investment vehicles, debt instruments, different types of
derivatives, and others.2 The second character of the CFI code
indicates multiple subclasses in a given main category, called
groups. Equities, for example, are divided into the groups
common/ordinary shares, preferred/preference shares, and
common/ordinary convertible shares, among other groups.
The last four characters of the CFI code define the specific
attributes of a financial instrument and depend on the group
to which the asset is allocated. For financial instruments
in the group common/ordinary shares from the “equities”
main category, relevant attributes include voting rights,
ownership, payment status, and form. These attributes come
with predefined possible values that determine the final code
of a financial instrument [1]. For other groups such as bonds
from the “debt instruments” category, alternative attributes,
e.g., the type of interest or guarantee, are of relevance.

A second framework for classifying financial instruments is
proposed by Brammertz and Mendelowitz [2]. Their so-called
ACTUS taxonomy is based on the specific nature of financial
contracts and in particular on their cash flow profiles and seeks
to create a global standard for the consistent representation
of financial instruments. It distinguishes between financial
contracts, which in turn are split into the subcategories
of basic contracts and combined/derivatives contracts on
the one hand, and credit enhancement on the other. Basic
contracts consist of fixed income and index-based products,
whereas combined/derivative contracts comprise symmetric
financial products, options, and securitisation products.
The second main category of the ACTUS taxonomy, i.e.,
credit enhancement, includes guarantee contracts, collateral
contracts, margining contracts, and repurchase agreements.
The standard is implemented on the SolitX platform with
a technical API layer and DLT adapter for transaction
systems and accounting, and in the AnalytX architecture for
risk management analysis, simulations, asset and liability
management, and business planning [3].

The standards proposed by [1] and [2] show that sophisticated
classification frameworks for traditional financial assets exist,
which are used in practice. For cryptographic assets, on
the contrary, the characteristics of many tokens in various
respects, for example in terms of regulation, utility or
valuation, were and are still largely ambiguous and hard to
measure. Several initiatives from governments, the academia,
and the industry have sought to reduce these uncertainties

2For a detailed description of each category, see [1].

1

ar
X

iv
:2

00
7.

11
87

7v
1 

 [
q-

fi
n.

G
N

] 
 2

3 
Ju

l 2
02

0



by systematically structuring the hundreds of existing tokens
based on predefined criteria.

The Swiss Financial Market Supervisory Authority (FINMA),
for example, issued guidelines for enquiries regarding the
regulatory framework for initial coin offerings in early 2018,
in which it distinguishes between three types of tokens, i.e.,
payment tokens, utility tokens, and asset tokens, based on
the underlying economic purpose [4]. Whether a particular
token is a financial instrument and thus would be subject
to certain laws and regulations depends on its economic
function and the rights associated with it. Other jurisdictions,
such as the European Union, Israel, Malta, and the United
Kingdom, follow a similar classification approach, although
their terminologies differ to some extent [5]. Additionally,
some jurisdictions follow the approach that the three main
types of tokens are not necessarily mutually exclusive. Rather,
there are also hybrid forms that share characteristics of two
or three main types. Accordingly, particular cryptographic
assets could thus, for example, have certain characteristics of
both payment and utility tokens.

In April 2019, the U.S. Securities and Exchange Commission
(SEC) through its strategic hub for financial innovation,
FinHub, published guidelines to determine whether a digital
asset, which may be a cryptographic asset, is an investment
contract, i.e. an agreement whereby one party invests money
in a common enterprise with the expectation of receiving a
return on investment. This assessment is done by applying
the so-called Howey test. If an investment agreement exists,
the digital asset is classified as a security and therefore U.S.
federal securities laws apply and must be considered by issuers
and other parties involved in, for example, the marketing,
offering, sale, resale or distribution of the respective asset [6].
Other jurisdictions, e.g., Ireland, follow a similar approach of
classifying cryptographic assets based on their qualification as
a security [7]. However, the Howey Test is to be understood
less as a classification framework but more as a decision aid
as to whether a cryptographic asset represents a security or not.

An academically based classification framework for
cryptographic assets, which goes beyond the legal perspective
and also takes technological and economic aspects, among
others, into account was carried out by Oliveira et al. [8]. By
applying a design science research approach, including 16
interviews with representatives of projects with blockchain-
based token systems, the paper derives a token classification
framework for cryptographic assets that can be used as
a tool for better informed decision making when using
tokens in blockchain applications. Their final classification
framework consists of the 13 attributes class, function,
role, representation, supply, incentive system, transactions,
ownership, burnability, expirability, fungibility, layer, and
chain, each of which include a set of defined characteristics.

A similar framework was developed by Ballandies et al.

[9]. The authors established a classification framework
for distributed ledger systems consisting of a total of 19
descriptive and quantitative attributes with four dimensions
(distributed ledger, token, action, and type). The attributes
comprise the distributed ledger type, origin, address
traceability, Turing completeness, and storage in the
distributed ledger dimension, underlying, unconditional
creation, conditional creation, transferability, burn, and supply
in the token dimension, action fee, read permission, and
actor permission in the action dimension, and fee, validate
permission, write permission, proof, and type in the consensus
dimension. The framework was derived from feedback from
the blockchain community.

Three further classification frameworks for cryptographic
assets that were strongly driven by the industry are those
proposed by the consulting firm MME, the International
Token Standardization Association (ITSA), and the Ethereum
Enterprise Alliance (EEA).

The framework by MME was published in May 2018 and
focuses on the legal properties and risk assessment of
cryptographic assets. The paper’s resulting classification is
based on a token’s function or main use, alongside other
criteria such as the existence of a counterparty, as well as its
type and/or the underlying asset or value. The final archetypes
of cryptographic assets are native utility tokens, counterparty
tokens, and ownership tokens, which are each subject to
additional subcategories of token types [10].

The International Token Classification (ITC) framework by
the ITSA comprises an economic, technological, legal, and
regulatory vertical each containing a set of subdimensions
with different attributes. The economic and technological
verticals include three subdimensions each, which refer to
a token’s economic purpose, its target industry, and the
way of distribution, and the technological setup, consensus
mechanism, and technological functionality, respectively. The
legal vertical includes the two subdimensions legal claim
and issuer type, whereas the regulatory vertical focuses
on assessing a tokens regulatory status in the US, China,
Germany, and Switzerland. Over all verticals, a total of
twelve subdimensions are defined, though ITSA plans to
define further subdimensions in the future. Concerning
the evaluation of these individual subdimensions, as of
September 2019, the ITC framework already provided
detailed information on four of the twelve subdimensions,
namely for the economic purpose, industry, technological
setup, and legal claim. The classification into these four
subdimensions was compiled in a database covering more
than 800 cryptographic tokens. Besides the classification
framework and the corresponding database, the ITSA also
introduced a nine digit unambiguous identifier for each token,
the so-called International Token Identification Number, short
ITIN [11].

2



The third industry-driven framework for classifying crypto-
graphic tokens was published by the EEA in November 2019.
Their proposed Token Taxonomy Initiative (TTI) distinguishes
between five characteristics a token can possess. The first
characteristic is the token type and refers to whether a token
is fungible or non-fungible. The second characteristic, the
token unit, distinguishes between the attribute of being either
fractional, whole or singleton and indicates whether a token is
subdivisible or not. The value type, as the third characteristic,
can assume the attribute of being either of an intrinsic value,
i.e., the token itself is of value (e.g., bitcoin), or a reference
value, i.e., the token value is referenced elsewhere (e.g.,
tokenised real estate). Characteristic four, the representation
type, comprises the attribute of being common or unique.
Common tokens, on the one hand, share a single set of
properties, are not distinct from one another and are recorded
in a central place. Unique tokens, on the other hand, have
unique properties and their own identity, and can be traced
individually. The fifth and last characteristic is the template
type and classifies tokens as either single or hybrid and refers
to any parent/child relationship or dependencies between to-
kens. Unlike single tokens, hybrid tokens combine parent and
child tokens in order to model different use cases. In addition,
the TTI provides measures in order to promote interoperability
standards between different blockchain implementations [12].

III. THE (CRYPTO) ASSET TAXONOMY

Building on the literature review in Chapter II, this chapter
proposes a holistic framework for the classification of
assets. Unlike existing classification frameworks, our asset
taxonomy aims to classify all existing types of assets, i.e.,
assets from both traditional finance as well as the crypto
economy, based on their formal characteristics. Furthermore,
the taxonomy introduces a terminology that is suitable for
both traditional and the crypto assets. A morphological
box is chosen as the methodological approach in order to
be able to take the multi-dimensionality of the matter into
account. The taxonomy is illustrated in Appendix A. In
total, we identify 14 different attributes based on which
all types of assets can be classified. They include claim
structure, technology, underlying, consensus/validation
mechanism, legal status, governance, information complexity,
legal structure, information interface, total supply, issuance,
redemption, transferability, and fungibility, with each attribute
comprising a set of at least two characteristics. Note that
certain attributes in the frameworks discussed in Chapter
II subsume some of the attributes presented here. Hence,
our 14 attributes factorize these superordinate attributes to
make them universally applicable. Table I breaks down the
14 attributes in terms of their inclusion in the publications
discussed in Chapter II. The first column shows the attribute
labels of the taxonomy we propose. Column two to ten refer
to the publications discussed, where an “x” indicates that
the corresponding attribute is either explicitly or implicitly
considered in the classification framework given in row one.
Note that the terminology regarding a particular attribute

differs across these publications, for example, because they
focus on different types of assets. The terminology we propose
generalises these terms to ensure compatibility across all types
of assets, thus creating a common linguistic understanding.
Also note that due to the extension of the taxonomy to
traditional assets, some DLT-specific attributes/characteristics
in the publications discussed are summarised or generalised,
while new attributes/characteristics were added in order to
enable the mapping of traditional asset types. Overall, Table
I shows that each of the existing frameworks covers certain
attributes determined by the specific focus or objective of
the publication. The framework of FINMA [4], for example,
focuses on regulatory aspects, and thus predominantly
includes corresponding attributes, i.e., claim structure, legal
status, and legal structure. Other frameworks, for example the
one published by the EEA [12], focus more on technological
aspects or the design of token features. Overall, none of the
frameworks discussed in Chapter II covers the full range of
formal attributes identified in our taxonomy. However, our
taxonomy is generally confirmed by the existing literature,
as each attribute is considered in at least one of the existing
classification frameworks. The degree of agreement with
the classification framework we propose varies, however.
While the publication of ISO [1] covers four attributes of our
taxonomy, the publications of Oliveira et al. [8] and Ballandies
et al. [9] cover ten. There are also differences in coverage
from an attribute perspective. While the underlying of an
asset is of relevance in all frameworks analysed, the attributes
information interface and fungibility are only covered by
two. The taxonomy we propose therefore goes further than
the existing classification frameworks, firstly because it is
independent of the type of assets to be classified and secondly
because it contains additional attributes and characteristics.
Since some of these attributes and characteristics are not
intuitively clear, they are explained in more detail in the
following:

Claim structure: Does the asset represent a claim, i.e., a
demand for something due or believed to be due [13]?

– No claim(s): The asset does not represent any kind of
claim.

– Flexible claim(s): The asset represents certain claims, the
possession or exercise of which can depend on certain
conditions (e.g., catastrophe bonds).

– Fixed claim(s): The asset represents claims which can
neither be restricted nor restrained under any condition
(e.g., fixed income).

Technology: Which technology is the asset based on?
– Physical: The asset exists in a physical form (e.g., gold

bullion).
– Digital: The asset exits in a digital form, but is not based

on the distributed ledger technology (e.g., electronic
share).

– Distributed ledger technology: The asset is based on the
distributed ledger technology, structured either as a native

3



Table I: Coverage of the 14 attributes in existing classification frameworks

Attribute ISO
[1]

B.&M.
[2]

FINMA
[4]

O. et al.
[8]

B. et al.
[9]

MME
[10]

ITSA
[11]

EEA
[12]

Claim structure x x x x x x
Technology x x x x x x
Underlying x x x x x x x x
Consensus/Validation mechanism x x x
Legal status x x x x
Governance x x x
Information complexity x x x
Legal structure x x x x
Information interface x x
Total supply x x x x
Issuance x x x x
Redemption x x x x
Transferability x x x x x
Fungibility x x

token, i.e., a token that is native to a specific blockchain,
or as a protocol token, i.e., a token issued on an existing
blockchain protocol [8] such as, for example, ERC-20 or
ERC-721 tokens for the Ethereum blockchain.

Underlying: Which underlying or collateral is the asset’s
value based on?

– No underlying: The asset’s value is not a derivative of an
underlying asset (e.g., bitcoin).

– Company: The asset’s value represents a stake in a
company (e.g., equity).

– Bankable asset: The asset’s value represents a bankable
asset, i.e., an asset that can be deposited in a bank or
custody account (e.g., fiat currencies).

– Cryptographic asset: The asset’s value represents a cryp-
tographic asset, i.e., an asset based on the distributed
ledger technology (e.g., derivative of a cryptographic
asset).

– Tangible asset: The asset is in a physical form [14] (e.g.,
real estate).

– Contract: The asset’s value represents a contract (e.g.,
license agreement).

Consensus-/Validation-mechanism: How is the agreement on
the finality (e.g., property rights or ownership transfer) of the
asset reached?

– Instant finality: Consensus is final. Mechanisms that
typically, but not necessarily, belong to the deterministic
type are, for example, notary services or qualified written
form.

– Probabilistic finality: Consensus is not final, but reached
with a certain level of confidence. Mechanisms that
typically, but not necessarily, belong to the probabilistic
type are, for example, proof-of-work or proof-of-stake.

Legal status: What is the regulatory framework governing the
asset?

– Regulated: There are regulatory requirements for the
issuance, redemption and governance of the asset.

– Unregulated: There is no specific regulatory framework
for the issuance, redemption and governance of the asset.

Governance: In which way is the asset governed?
– Centralised: The asset is governed by an authoritative

party or consortium.
– Decentralised: The asset is governed without centralised

control (e.g., certain types of cryptographic assets such
as bitcoin).

Information complexity:3 What type of information complex-
ity is associated with the asset?

– Value: The asset represents a specific value (e.g., curren-
cies).

– Contract: The asset encompasses conditional information
in addition to its value (e.g., coupon bonds or DLT-based
smart contracts4).

– Turing completeness: The asset is based on a Turing-
complete (ÂŤuniversally programmableÂť) computational
model (e.g., Ethereum).

Legal structure: What is the legal form of the asset?
– No legal structure: There is no legal structure governing

the asset.
– Foundation: The asset is governed by a foundation/ trust

structure.
3Note that the characteristics of this attribute build on each other, i.e., each

characteristic contains additional information compared to the previous one.
4Note that such (smart) contracts, as in the case of bitcoin, are not

necessarily based on a Turing-complete system.

4



– Note/bond: The asset is structured as a note or bond.
– Share: The asset is structured as a share.
– Other5: The asset has an alternative legal structure (e.g.,

central bank money).

Information interface: How does the asset receive and/or
send relevant information?

– No interface: The asset has no kind of information
interface.

– Qualitative: The asset manages relevant information in-
directly through an authorised instance (e.g., general
assembly).

– Quantitative: The asset manages relevant information
from authorised sources automatically (e.g., IoT sources
or oracle interfaces in the case of DLT-based smart
contracts).

Total supply: To which limit can the asset be generated?
– Fixed: The total supply of the asset is fixed.
– Conditional: The total supply of the asset is dependent

on predefined conditions.
– Flexible: The total supply of the asset is managed flexibly

by authorised parties.

Issuance: How is the asset generated?
– Once: After an initial issuance, no additional units of the

asset are issued.
– Conditional: Additional units of the asset are issued

once predefined conditions are met (e.g., newly issued
cryptographic assets through mining).

– Flexible: Additional units of the asset can be issued
flexibly by authorised parties (e.g., increase in share
capital).

Redemption: How is the number of outstanding assets re-
duced?

– No redemption: The number of outstanding assets cannot
be reduced.

– Fixed: The reduction of the number of outstanding assets
follows a predefined protocol.

– Conditional: The reduction of the number of outstanding
assets is initiated once predefined conditions are met.

– Flexible: The reduction of the number of outstanding
assets can be carried out flexibly by authorised parties
(e.g., share buyback).

Transferability: Can the asset’s ownership be transferred to
another party?

– Transferable: The asset’s ownership can be transferred to
another party.

– Non-transferable: The asset’s ownership cannot be trans-
ferred to another party, for example, by sale or giveaway
(e.g., some types of registered securities).

5The characteristic “Other” subsumes the broad range of alternative legal
structures for reasons of simplicity and practicability.

Fungibility: Can the asset be interchanged with another asset
of the same type?

– Fungible: The asset is substitutable with another asset of
the same type.

– Non-fungible: The asset is not substitutable with another
asset of the same type (e.g., artwork).

IV. CLASSIFICATION EXAMPLES

This subchapter seeks to test the above-mentioned taxonomy
with selected examples. First, the taxonomy is used to compare
cash to bitcoin, as both are intended means of payment6.
This comparison is followed by the classification of Ether,
a utility token, Crowdlitoken, an asset token, CryptoKitties,
and a traditional share.

A. Comparison between Cash and Bitcoin

As both cash and bitcoin follow the purpose of a means of pay-
ment, both assets share certain similarities (see Appendix B).
Neither cash, in the case of a fiat money system, nor bitcoin
have a direct underlying asset. The value of the two assets is
rather based on the public’s trust in the issuer of the currency
or in the underlying technological protocol, respectively. There
is also no oracle interface, i.e. no specific source that interacts
(e.g., directly provides information) with cash or bitcoin. Since
both assets are designed as cash equivalents, their units are
transferable from one party to another and individual units are
interchangeable. Besides these commonalities there are some
significant differences. While cash represents a certain value
which depends on the denomination, bitcoin is of contractual
type as it is transferred via smart contracts in the Bitcoin-
script which is not Turing-complete. Bitcoin is furthermore not
subject to any type of legal claim and has no legal structure.
In contrast, cash is regulated as legal tender under national
law. Since cash is of physical form, consensus on its state
is given deterministically by the owner of the asset. Bitcoin,
on the contrary, is a digital representation of value based on
the distributed ledger technology. It is the native token of the
Bitcoin blockchain, the consensus of which is based on the
proof-of-work mechanism and thus finality of the system is not
guaranteed but only probabilistic. This implies a decentralised
governance of the asset, which is in contrast to the centralised
governance of cash by central banks. Both assets also differ
in terms of their total supply as well as in their ways to
manage the number of outstanding units. While the maximum
supply of bitcoin is fixed at 21 million units, there is no such
restriction for cash. The issuance of additional units of bitcoin
is conditional on the mining of new blocks and reducing the
number of outstanding units is not possible7. The issuance
and redemption of cash, on the contrary, is handled flexibly
by central banks.

6Bitcoin is often considered to be a store of value, but the original intention
is to provide an alternative means of payment.

7It is possible to send units of bitcoin, or other cryptographic assets, to
an address without a known private key, so that these units are no longer
accessible. However, this does not reduce the number of total units in the
system.

5



B. Ether

Ether (see Appendix C), which is classed as a utility token, is
the native token of the Turing-complete Ethereum platform
which is governed by the Ethereum Foundation located in
the Crypto Valley. The token itself is unregulated. Although
multiple decentralised systems which can act as a quantitative
oracle interface for the platform exist, there are no legal claims
and no underlyings associated with the token. Consensus on
the Ethereum platform is, at the time of writing, achieved
based on the proof-of-work mechanism, and therefore is of
a probabilistic nature. As a consequence, the governance of
the token is decentralised. Like with bitcoin, the issuance of
Ether tokens is conditional on the creation of new blocks, i.e.,
when miners get awarded with newly mined units, and the
destruction of existing units is not possible. However, currently
the total supply of Ether is not limited. All Ether tokens are
transferable between parties and are fungible.

C. Crowdlitoken

Crowdlitokens (see Appendix D) are classed as asset tokens
and are tokenised real estate bonds, regulated under the
existing law. They are issued on the Ethereum Blockchain
under the ERC-20 standard and represent a contract including
fixed claims (e.g., voting and interest payment). The token
value is derived from the fundamental value of the issuing
company, and only indirectly by its real estate portfolio. Due to
the underlying distributed ledger technology, consensus on the
state of the tokens is not final but only probabilistic. Crowdl-
itokens are structured as notes/bonds. They are governed in a
centralised manner through a qualitative oracle interface since
token holders are allowed to vote on changes proposed by the
management. They can be issued and burnt (e.g., through token
buybacks) flexibly by the corresponding company, implying a
flexible token supply. The Crowdlitoken is both transferable
and fungible, whereby only persons who have successfully
completed the KYC/AML audits can subscribe to the bonds
and exercise all rights relating to them.

D. CryptoKitties

CryptoKitties (see Appendix E), as the last example from
the crypto space, are collectible digital representations of cats
created on the Ethereum blockchain. The corresponding smart
contracts can generate over four billion variations of phe-
notypes and genotypes (CryptoKitties, 2019). CryptoKitties
neither represent claims against a counterparty, nor a specific
underlying. They are non-fungible - every cat is unique - but
transferable ERC-721 tokens, without any regulatory or legal
governance. Although the front-end as a traditional web app
is managed by the development team, the token’s governance,
e.g., ownership, is decentralised. Since consensus of the un-
derlying Ethereum protocol is reached via a proof-of-work
mechanism, the finality of the state of a CryptoKitties token
is probabilistic. Also, there is no oracle interface related to
CryptoKitties tokens. The creation of additional units is done
by breeding two CryptoKitties, resulting in a new unique kitty,
represented by a newly issued unique token, while destroying

a unit is not possible. The corresponding smart contract allows
for a total limit of around four billion cats that can be bred,
implying a fixed total supply.

E. Traditional Share

Traditional shares (see Appendix F), as the one example from
traditional finance, are either physical or digital in nature and
represent a contract including fixed claims (e.g., voting and/or
profit participation) against a counterparty, with its fundamen-
tal value also representing the underlying of the asset. Shares,
as a legal form, are governed in a centralised manner and
are subject to the existing law (e.g., national corporate law),
with the general assembly of shareholders being the supreme
organ of a stock corporation, i.e., acting as a qualitative oracle
interface. Consensus on the state of a share is deterministically
given by the share registry. The creation of new shares as well
as the reduction in share capital, for example through share
buybacks, is left to the general assembly of the corporation.
As a consequence, the total supply of traditional shares is
flexible. Shares are typically transferable, with exceptions such
as restricted shares, and fungible, i.e., substitutable with other
shares of the same company.

V. CONCLUSION

Various classification frameworks for traditional and cryp-
tographic assets already exist and are applied in practice.
However, a universal approach linking the two worlds has
not yet been developed. In this paper we fill this research
gap by proposing a taxonomy that extends existing classi-
fication frameworks. We identify 14 different attributes that
are supported by the existing literature and by which each
type of asset can be properly classified. These attributes
include the claim structure, technology, underlying, consensus-
/validation mechanism, legal status, governance, information
complexity, legal structure, information interface, total supply,
issuance, redemption, transferability, and fungibility. With the
help of a morphological box, various possible characteristics
that an asset can have are identified and assigned to these
attributes. In this way, our taxonomy bridges the gap between
physical, digital, and cryptographic assets, where sometim";"""date"",""2020-07-24T00:37:31Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2020-07-24T00:37:31Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016) kpathsea version 6.2.2""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2020-07-24T00:37:31Z""
""created"",""2020-07-24T00:37:31Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-07-24T00:37:31Z""
""resourceName"",""2007.11877""
""Author"",""""
""producer"",""pdfTeX-1.40.17""
""pdf:docinfo:producer"",""pdfTeX-1.40.17""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2020-07-24T00:37:31Z""
""Last-Modified"",""2020-07-24T00:37:31Z""
""dcterms:modified"",""2020-07-24T00:37:31Z""
""title"",""""
""Last-Save-Date"",""2020-07-24T00:37:31Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2020-07-24T00:37:31Z""
""meta:save-date"",""2020-07-24T00:37:31Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016) kpathsea version 6.2.2""
""Content-Length"",""1474053""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""10""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""5182"",""5117"",""5319"",""2886"",""4449"",""4947"",""77"",""74"",""87"",""2619""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-07-24T00:37:31Z""
";https://scholar.google.ch/scholar?start=650&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098844-281;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Light-weight verification of cryptographic API usage;W Xing ;2020 uwspace.uwaterloo.ca;;"… 6 Page 18. Chapter 3 Crypto Checker Type System … We forego a soundness proof for this type

system and instead rely on a standard type lattice and extended subtyping checks, which has

been successfully used for other systems [17]. 3.2 Crypto Checker …";Autres articles;Version HTML;[PDF] uwaterloo.ca;https://uwspace.uwaterloo.ca/bitstream/handle/10012/16555/Xing_Weitian.pdf?sequence=3;"
Light-weight verification of
cryptographic API usage

by

Weitian Xing

A thesis
presented to the University of Waterloo

in fulfillment of the
thesis requirement for the degree of

Master of Applied Science
in

Electrical and Computer Engineering

Waterloo, Ontario, Canada, 2020

Š Weitian Xing 2020



Author’s Declaration

This thesis consists of material all of which I authored or co-authored: see Statement of
Contributions included in the thesis. This is a true copy of the thesis, including any required
final revisions, as accepted by my examiners.

I understand that my thesis may be made electronically available to the public.

ii



Statement of Contributions

Weitian Xing is the sole author for Chapters 1, 2, and 7. They are written under the
supervision of Professor Werner Dietl, and are not yet published.

Chapter 3 of the thesis introduces a type system aiming at preventing the use of forbidden
cryptographic algorithms and providers at compile time. It is co-authored with Yuanhui
Cheng and Werner Dietl and not yet published. Chapters 4, 5, and 6 contain figures, tables,
and text from this unpublished paper.

iii



Abstract

A pluggable type system is a light-weight approach for compile-time program verification,
which provides more powerful types to both developers and compilers. Developers use
pluggable types to boost program understanding, while compilers leverage the new types
to enforce interesting properties, e.g., NullPointerException freedom. This thesis presents
a new type system, the Crypto Checker, to help developers prevent cryptographic APIs
misuse. In addition, this thesis presents the Property File Handler and the Network Request
Checker as two type system extensions. The Property File Handler performs type refinement
to Java Properties by reading property files at compile time, while the Network Request
Checker reports all the possible network requests to prevent potential information leakage
in Java and Android applications.

Using cryptographic APIs to encrypt and decrypt data, calculate digital signatures,
or compute hashes is error prone. Weak or unsupported cryptographic algorithms can
cause information leakage and runtime exceptions, such as a NoSuchAlgorithmException
in Java. Using the wrong cryptographic service provider can also lead to unsupported
cryptographic algorithms. Moreover, for Android developers who want to store their key
material in the Android Keystore, misused cryptographic algorithms and providers make
the key material unsafe. This thesis presents the Crypto Checker, a pluggable type system
that detects the use of forbidden algorithms and providers at compile time. For typechecked
code, the Crypto Checker guarantees that only trusted algorithms and providers are used,
and thereby ensures that the cryptographic APIs never cause runtime exceptions or use
weak algorithms or providers. The type system consists of an easy-to-understand type
qualifier hierarchy. The Crypto Checker is flexible and easy-to-use—it allows developers to
determine which algorithms and providers are permitted by writing specifications using
type qualifiers. We implemented the Crypto Checker for Java and evaluated it with 32
open-source Java applications (over 2 million LOC). We found 2 issues that cause runtime
exceptions and 62 violations of security recommendations and best practices. We also used
the Crypto Checker to analyze 65 examples from a public benchmark of hard security issues
and discuss the differences between our approach and a different static analysis in detail.

Malicious or unsafe applications collect and send users’ data to untrusted external
servers via network requests, e.g., HTTP and socket requests, which will cause information
leakage. Detecting the possible network requests on the source code level without running
the applications is a light-weight approach to solve the problem. Application stores that
have the source code of the uploaded apps can take advantage of this to ensure application
security. Security teams in companies also use similar technologies to guarantee compliance.
This thesis presents the Network Request Checker, a type system extension for Java to

iv



detect and report all the possible network requests to developers at compile time. The
Network Request Checker can be integrated into any other pluggable type system or be
seen as a stand-alone type system depending on developers’ needs. We evaluated this
type system with 6 real-world Java and Android applications and discuss the experimental
results.

To improve the Crypto Checker, the Network Request Checker, and other type systems’
precision, i.e., to obtain more valuable information from the program at compile time, this
thesis presents the Property File Handler, a type system extension that reads property
files to perform type refinement on Java Properties. When an application reads property
files, the Property File Handler will also try to load, store, and propagate the information
from property files. A simple type hierarchy is proposed to achieve this functionality. By
using the Property File Handler, we found and fixed a potential false negative with Java
Properties, while other static analysis tools, e.g., SonarSource, did not handle that code
correctly.

v



Acknowledgements

I would like to express my sincere appreciation to my supervisor, Professor Werner
Dietl, for his continuous support and guidance. He opened the door to a new world for
me. I would also like to thank my readers, Professor Arie Gurfinkel and Professor Mahesh
Tripunitara, for their time, questions, and feedback. I am also thankful to Professor Arie
Gurfinkel for his advice in project meetings. I thank my friends in the research group,
especially Tongtong Xiang and Lian Sun, for their help and for buying tons of Tim Hortons
with me. I thank my former URA, Yuanhui Cheng, for working on the Crypto Checker
with me.

vi



Dedication

This is dedicated to my parents who give me endless love, support, and encouragement.

vii



Table of Contents

List of Figures x

List of Tables xi

1 Introduction 1

1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 Thesis Contributions and Organization . . . . . . . . . . . . . . . . . . . . 2

2 Background 4

2.1 Type Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.2 Checker Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

3 Crypto Checker Type System 7

3.1 Type System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3.1.1 Type Qualifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3.1.2 Qualifier Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.1.3 Type Rules for Assignment and Pseudo-assignment . . . . . . . . . 12

3.2 Crypto Checker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.2.1 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.2.2 Flexibility of Defining Cryptographic Rules . . . . . . . . . . . . . . 15

3.2.3 Enforced Cryptographic Rules . . . . . . . . . . . . . . . . . . . . . 16

viii



4 Type System Extensions 17

4.1 Property File Handler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

4.1.1 Type System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

4.1.2 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

4.2 Network Request Checker . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

4.2.1 Type System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

4.2.2 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

5 Experiments 23

5.1 Case Studies with the Crypto Checker . . . . . . . . . . . . . . . . . . . . 23

5.1.1 Insecure Uses of Cryptographic APIs . . . . . . . . . . . . . . . . . 24

5.1.2 Android Keystore Case Study . . . . . . . . . . . . . . . . . . . . . 30

5.1.3 CRYPTOAPI-BENCH Case Study . . . . . . . . . . . . . . . . . . 31

5.2 Case Studies with the Network Request Checker . . . . . . . . . . . . . . . 32

6 Related Work 34

6.1 Algorithm Checking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

6.2 Provider Checking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

6.3 Java Properties Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

7 Conclusions and Future Work 37

7.1 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

7.2 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

References 39

ix



List of Figures

2.1 An example of the Nullness Checker. . . . . . . . . . . . . . . . . . . . . . 5

3.1 The basic qualifier hierarchy of the Crypto Checker . . . . . . . . . . . . . 11

3.2 The subtyping rules for two @AllowedAlgorithms or two @AllowedProviders 12

3.3 Workflow of the Crypto Checker. . . . . . . . . . . . . . . . . . . . . . . . 14

4.1 The qualifier hierarchy of the Property File Handler . . . . . . . . . . . . . 19

x



List of Tables

5.1 Case study statistics for standard Java applications . . . . . . . . . . . . . 25

5.2 Repository URLs of Java applications . . . . . . . . . . . . . . . . . . . . . 26

5.3 Repository URLs of Android applications . . . . . . . . . . . . . . . . . . . 27

5.4 Case study statistics for Java and Android applications . . . . . . . . . . . 33

xi



Chapter 1

Introduction

1.1 Motivation

Many developers are suffering from cryptographic APIs misuse: most developers are not
cryptography experts, which means that it is easy for them to make mistakes when the
documentation is not clear and easy enough. Some of the misuses, e.g., using weak
cryptographic algorithms, will not cause runtime exceptions, which makes the misuses hard
to be reproduced and fixed as the programs will not throw errors to alert the developers.
There are many security tools, both static and dynamic, created to detect weak cryptographic
algorithm misuses. But most of them cannot provide developers a convenient way to specify
custom security rules: some security tools hardcode security rules in their source code; for
the security tools that support custom rules, users always have to learn template models or
write sub checkers themselves. Furthermore, currently, there are no such tools for detecting
cryptographic algorithm providers, which is also important to avoid runtime exceptions and
make it possible for developers to specify the security providers they want to use. Because
static tools run at compile time, i.e., they do not put extra burdens on the runtime of the
program, we want to create a static tool which not only supports detecting both forbidden
cryptographic algorithms and providers but also offers developers the flexibility to indicate
their own security rules easily. A pluggable type system meets our requirements as 1) it
performs type checking at compile time, 2) its type qualifier can express developer-defined
security rules easily, and 3) it also improves program understanding.

Information leakage can cause major harm to applications and users: malicious applica-
tions collect and send the users’ or other applications’ information to untrusted external
servers by sending network requests, e.g., HTTP and socket requests. This helps attackers

1



learn more about applications. The leak of users’ sensitive data causes a loss of money.
We create a type system extension which can detect all the possible network requests at
compile time, so that developers can leverage this type system extension to perform security
and privacy checking when building applications. As a type system extension, it can be
used by any arbitrary type systems.

Property files in applications always store valuable information. For instance, to
enforce a common security standard and allow global reconfiguration easily, applications
save cryptographic parameters such as cryptographic algorithms and providers in project
property files. Similarly, the hostnames and ports for network requests are commonly stored
in property files. Thus, getting such information at compile time helps static analysis tools
perform more comprehensive and precise analysis. Unfortunately, the current existing static
analysis tools cannot handle property files, which introduces false positives, and even false
negatives. We create a type system extension that handles property files to provide more
compile-time constant values.

1.2 Thesis Contributions and Organization

The thesis contains the following main contributions:

Firstly, we present the Crypto Checker, which is a pluggable type system aimed at
ensuring that there are no uses of forbidden cryptographic algorithms and providers in a
program. For the Crypto Checker, we provide several pre-defined security rules for Java
and Android applications. We evaluate the Crypto Checker with over 2 million lines of code
and performed a case study with a comprehensive cryptographic APIs misuse benchmark.
See Chapter 3 for detailed information.

Secondly, we present the Property File Handler as a type system extension performing
flow-sensitive type refinement to enhance the compile-time constant value inference in
Chapter 4.1. The Property File Handler tries to read the programs’ property files and
propagates the values in the property files to Java properties. The Property File Handler
can collaborate with any Checker Framework based type system. The Crypto Checker and
the other type systems benefit from the Property File Handler as it improves precision and
reduces false positives.

Thirdly, we present the Network Request Checker, another type system extension that
reports all the possible network requests at compile time. The Network Request Checker
supports several popular network request libraries by default, and it can also be extended
easily to be compatible with more libraries. We evaluate the Network Request Checker

2



with 6 real-world Java and Android applications, and discuss the experimental results. See
Chapter 4.2 for detailed information.

The rest of the thesis is structured as follows: Chapter 2 discusses the basic knowledge
of type systems and the Checker Framework, which is the fundamental of the pluggable
type system and extensions presented in the thesis. Chapter 3 introduces the type system
and the implementation of the Crypto Checker. Chapter 4 describes two type system
extensions, the Property File Handler and the Network Request Checker. Chapter 5 talks
about case studies. Chapter 6 discusses the related work. Chapter 7 records possible future
work and concludes the whole thesis.

3



Chapter 2

Background

This chapter discusses the background knowledge that is needed to understand the thesis.

2.1 Type Systems

Type systems are always an important component of statically-typed programming languages
as the type systems provide a set of rules to the programs, which improves both the security
and the performance of the programs. To ensure developers follow the provided rules,
programming languages utilize type checking algorithms, which will report errors when the
rules are violated. After passing the type checking, guarantees of the correct use of the
types are given to the programs [34, 38, 46]. Compilers can also optimize the code after
knowing that the type rules are respected.

As a statically typed language, Java’s built-in type system is strong and helps prevent
many errors during compilation, e.g., as the following code is shown, assigning a string literal
to an integer type variable will cause an incompatible types error. This helps developers fix
errors at compile time.

int i = ""123""; // incompatible types error

However, Java’s built-in type system is not strong enough to find all kinds of errors at
compile time. For example, even though the Java compiler does not complain, developers
still may face NoSuchAlgorithmException and NoSuchProviderException when using Java
cryptographic APIs. We will discuss how to prevent these two exceptions in Chapter 3. To
make Java’s type system more powerful, the Checker Framework is introduced.

4



void foo(Object nn, @Nullable Object nbl) {

nn.toString(); // OK

nbl.toString(); // Error

}

Figure 2.1: An example of the Nullness Checker.

2.2 Checker Framework

The Checker Framework is a framework that enhances Java’s original type system to perform
extra type checking for interesting properties, e.g., null-pointer freedom and freedom of
certain taints [7, 10, 17, 21]. The pluggable type system and extensions presented in this
thesis are all built on the Checker Framework. For a specific property that passes pluggable
type checking, the Checker Framework gives users the guarantee that there will be no
runtime errors with this property. “Pluggable” here indicates that the type checking is
optional: Users can freely choose which type checking they want to perform at every
compilation. Also, the type annotations will be only validated at compile time, which will
not put extra burdens on the run time. Thus, pluggable type checking is light-weight and
flexible. The Checker Framework leverages Java type annotations which were introduced in
JDK 8 to achieve the Checker Framework’s core functionalities. Currently, the Checker
Framework supports both JDK 8 and 11. An example of the Checker Framework’s Nullness
Checker extracted from the Checker Framework Live Demo1 is shown in Figure 2.1. In
this example, developers use the annotation @Nullable provided by the Nullness Checker
to indicate that null can be passed as the argument to the parameter Object nbl. Thus,
nbl.toString() is a dangerous operation that may cause NullPointerException at run time
and should be avoided. The Nullness Checker will report this to developers at compile time.

The Checker Framework provides a good encapsulation of the Java’s internal compiler
APIs, i.e., for most of the time developers do not need to work with them. In addition, the
Checker Framework also provides default implementations which reduces the code efforts to
create a new checker, i.e., a new checker normally only needs to override some of the specific
methods to meet its need. Thus, even the developers who do not have deep knowledge
with type system and javac can easily create custom annotations and enforce certain type
rules. To design and develop a new pluggable type system, the following 5 components are
critical:

1http://eisop.uwaterloo.ca/live/

5

http://eisop.uwaterloo.ca/live/


• Type qualifiers and hierarchy. Each type system has at least one type qualifier and
one type hierarchy. You need to define the subtyping relationship among different
type qualifiers and the default type qualifier in the type system.

• Interface to the compiler. This is the entry point of the type checker. The command-
line options and the sub checkers can be indicated here.

• Type rules. Type rules represent type system semantics. The type checker will report
errors to developers when type rules are broken.

• Type introduction rules. For each of the type locations, type introduction rules
indicate the suitable type annotations to it. Developers can create a tree annotator
to express their own introduction rules.

• Dataflow rules. The Checker Framework performs flow-sensitive type refinement
following the provided dataflow rules. Chapter 4.1 gives an example of creating and
implementing dataflow rules.

The Checker Framework’s manual2 provides plenty of documentation that guides devel-
opers to get started and dive into. The Checker Framework’s community is also responsive
and friendly.

2https://checkerframework.org/manual/

6

https://checkerframework.org/manual/


Chapter 3

Crypto Checker Type System

Cryptographic APIs are hard to understand and use for developers who are not cryptogra-
phers [36], which causes significant security vulnerabilities. This thesis focuses on one aspect
of cryptographic API misuse: the inadvertent use of weak, unsupported, or disallowed
cryptographic algorithms or providers.

A key method to select cryptographic algorithms in Java is Cipher.getInstance(String

transformation)1. The transformation can be in one of two formats: ""algorithm/mode/pad-

ding"" or simply ""algorithm"". In the latter case, default mode and padding values will
be used. This method uses the installed providers, which offer the implementation of
algorithms and other security services, to find the implementation for the requested trans-
formation. Alternatively, developers can specify the provider via Cipher.getInstance(String

transformation, String provider).

A NoSuchAlgorithmException occurs when an algorithm that is unavailable in the envi-
ronment is requested [24]. This can be caused by a misspelling or an incorrect assumption
about the execution environment. For instance, Cipher.getInstance(""AESS/GCM/NoPadding"")
throws a NoSuchAlgorithmException at run time, because there is no ""AESS"" algorithm. The
Java cryptographic APIs could have used fixed enum constants to guarantee that only valid
algorithms, modes, and paddings are used. However, strings were likely chosen because
they allow much more flexibility in the evolution and customization of the APIs and their
independent implementation by hardware and software providers.

When specifying the provider, developers must use algorithms that are supported by this
provider. The following code compiles successfully, but throws a NoSuchAlgorithmException

1https://docs.oracle.com/javase/8/docs/api/javax/crypto/Cipher.html

7

https://docs.oracle.com/javase/8/docs/api/javax/crypto/Cipher.html


at run time since PKCS7PADDING is not a valid padding for the provider SunJCE. Developers
should use the BouncyCastle (BC) provider instead.

// runtime error

Cipher.getInstance(""AES/CBC/PKCS7PADDING"", ""SunJCE"");

For Android developers who want to store the key material in the Android Keystore, when
generating security keys, AndroidKeyStore needs to be used explicitly as the cryptographic
service provider. Otherwise, the Android Keystore system cannot protect the key material
from unauthorized use. Also, only a subset of algorithms is supported by the Android
Keystore, which means that a wrong algorithm will lead to a runtime exception. Currently,
there are no tools that enforce the security rules for the Android Keystore.

Similar to NoSuchAlgorithmException, NoSuchProviderException occurs at run time when
the requested provider does not exist in the environment. For example:

// runtime error

KeyPairGenerator.getInstance(""RSA"", ""WrongProvider"");

Unsupported algorithms or providers result in runtime exceptions, which can be hard to
reproduce and fix. Using weak algorithms is even worse, as applications continue to operate
and there will be no errors at compile or run time. Using weak algorithms may cause
the exposure of sensitive information [16]. Some common symmetric ciphers such as DES,
IDEA, and RC4 are considered very insecure, because their 64-bit keys are too short and
susceptible to brute-force attacks [2]. Similarly, hash functions MD5, MD4, SHA-1, and the
mode of operation ECB, are prone to vulnerabilities. The compiler will not warn against
using weak algorithms and, as there is no runtime exception when a weak algorithm is used,
an application can use weak algorithms for a long time. Therefore, finding the use of weak
cryptographic primitives at compile time is essential to protect sensitive information.

Many companies have security policies that specify what cryptographic algorithms
and providers must be used. Human code reviewers can easily miss the use of incorrect
algorithms and providers. Many static analysis tools have hard-coded security rules, which
makes them useless for this situation. Tools which support custom rules require writing
rules in some rule language, which is an additional learning effort and source of possible
errors.

In this chapter, we present the Crypto Checker, which validates the possible values used
for cryptographic algorithms and providers at compile time. It gives a strong guarantee
that no forbidden algorithms or providers are used in an application, which helps developers
keep sensitive information safe and avoids runtime exceptions. The Crypto Checker enforces

8



several default security rules of allowed algorithms and providers. Users can also indicate
their own rules to meet their particular requirements by adding type annotations, which is
very convenient and easy to understand.

Part of our work, weak algorithm detection, was inspired by the AWS Crypto Policy
Compliance Checker [30]. Our work provides security rules for the Android Keystore [5]
and supports provider checking. Furthermore, to handle the case that a program reads
cryptographic parameters from property files, we designed a Property File Handler that
performs type refinements for Java property file APIs. The Property File Handler will be
discussed in 4.1.

The Crypto Checker is a pluggable type system [8] built on the Checker Framework [17].
To the best of our knowledge, this is the first open-source static analysis tool providing a
comprehensive solution to ensuring the correct usage of both cryptographic algorithms and
providers at compile time. The source code is available on GitHub: https://github.com/
vehiloco/crypto-checker.

Overall, our contributions are:

• a type system to enforce the correct usage of algorithms and providers at compile
time (Section 3.1),

• an implementation of the type system for Java (Section 3.2.1),

• a flexible way to define custom security rules (Section 3.2.2),

• well-defined security rules for Java and Android applications (Section 3.2.3),

• a property file handler performing type refinement (Section 4.1), and

• case studies on 2 million LOC of Java and Android applications (Section 5.1).

Section 6 reviews related work and Section 7.1 concludes.

3.1 Type System

In this section, we present the Crypto Checker type system, which guarantees that only
allowed algorithms and providers are used. The presented ideas can be applied to any
language, but we use Java for examples. Section 3.1.1 describes the type qualifiers of the

9

https://github.com/vehiloco/crypto-checker
https://github.com/vehiloco/crypto-checker


type system. Section 3.1.2 discusses the qualifier hierarchy. Section 3.1.3 defines the type
rules for assignments and pseudo-assignments.

The type system performs a modular, conservative over-approximation of all possible
executions of a program. The type system reports a false positive when it cannot guarantee
a correct usage. In our case studies, there were no false positives.

3.1.1 Type Qualifiers

Type qualifiers are used to specify properties that cannot be expressed by the standard type
system [8,23]. Java’s type annotation syntax can be used to represent type qualifiers [44].
Developers use the annotations in source code to specify properties of the program. In
our type system, there are five type qualifiers: @AllowedAlgorithms, @AllowedProviders, and
@StringVal provide information about allowed algorithms, providers, and string values,
respectively; @Unknown and @Bottom complete the type lattice (see Section 3.1.2).

Type qualifiers @AllowedAlgorithms and @AllowedProviders record the permitted al-
gorithms and providers, in a String[] value annotation type element. For example,
@AllowedAlgorithms({""AES/GCM/NoPadding"", ""RSA""}) indicates that there are only two le-
gal cipher transformations, AES/GCM/NoPadding and RSA. Developers can also use regu-
lar expressions to make the type qualifiers more expressive. For example, @Allowed-

Algorithms({""HmacSHA(1|224|256)""}) expresses that algorithms HmacSHA1, HmacSHA224, and
HmacSHA256 are allowed. In addition, algorithm names in the Java Cryptography Architec-
ture (JCA) are case-insensitive [28]. Our type system also supports that—for example,
HMACSHA224 is equal to HmacSHA224 in the type system.

Type qualifier @StringVal expresses permitted String values, again as an String[] value

annotation type element. Most commonly, @StringVal is automatically determined for String
literals in the program. This constant value propagation is provided by the Constant Value
Checker [12] in the Checker Framework. For example, the String literal ""RSA"" has the type
qualifier @StringVal({""RSA""}). In contrast to @AllowedAlgorithms and @AllowedProviders,
@StringVal does not use regular expressions to describe possible values.

Type qualifier @Unknown is the top and default type qualifier in the type system. It
indicates that no information about the algorithm or provider is known. The type sys-
tem is conservative: when the type system cannot determine a more precise type, e.g.,
@AllowedAlgorithms or @AllowedProviders, the top type will be used. Type qualifier @Bottom

is the bottom type and is used internally by the type system; developers do not need to use
it explicitly.

10



@Unknown

@AllowedAlgorithms @AllowedProviders

@StringVal

@Bottom

Figure 3.1: The basic qualifier hierarchy of the Crypto Checker’s type system. Arrows
represent the subtyping relationships between types. For example, @Unknown is the supertype
of @AllowedAlgorithms and @AllowedProviders.

The type qualifiers are only used for String types in the program; uses on other types
are forbidden. For example, @Unknown int x is an illegal use of the type annotation.

3.1.2 Qualifier Hierarchy

These type qualifiers form an easy-to-understand qualifier hierarchy (type qualifier lattice),
which is shown in Figure 3.1. @AllowedAlgorithms and @AllowedProviders are subtypes of
@Unknown and supertypes of @StringVal, while @Bottom is the bottom type in the type system,
subtype of @StringVal.

When determining the subtyping relation between two @AllowedAlgorithms or two
@AllowedProviders type qualifiers, the String[] annotation type element also needs to
be considered. The following rule applies: for two types τ1 and τ2, τ1 is a subtype of τ2
if and only if the element value of τ2 contains the element value of τ1. To make it more
concrete, @AllowedAlgorithms({""a""}) is a subtype of @AllowedAlgorithms({""a"", ""b""}). Two
@StringVal’s subtyping relation is similar to the above rule [13]. Figure 3.2 also illustrates
the subtyping rules.

These subtyping rules are conservative but sound: it is computationally hard to de-
cide whether a regular expressions is subsumed by another regular expression, that is,
whether the set of strings accepted by two regular expressions are subsets. To resolve
this, our type system only checks whether the supertype literally contains all the values
in the subtype. For example, although the regular expression SHA−(256|512) matches SHA−256,
@AllowedAlgorithms({""SHA−(256|512)""}) is not a supertype of @AllowedAlgorithms({""SHA−256""})
while @AllowedAlgorithms({""SHA−256"", ""SHA−512""}) is.

11



A ⊆ B

@AllowedProviders(A) <: @AllowedProviders(B)

A ⊆ B

@AllowedAlgorithms(A) <: @AllowedAlgorithms(B)

Figure 3.2: The subtyping rules for two @AllowedAlgorithms or two @AllowedProviders.

For the subtyping relation between @StringVal and @AllowedAlgorithms, or @StringVal

and @AllowedProviders, our type system has the following rule: @StringVal is a subtype of
@AllowedAlgorithms or @AllowedProviders if and only if @StringVal’s element value matches
the regular expressions in @AllowedAlgorithms or @AllowedProviders. As the arguments to
@StringVal do not use regular expression, the type system simply needs to check whether
the regular expression matches the string value.

3.1.3 Type Rules for Assignment and Pseudo-assignment

The subtyping rules from Section 3.1.2 are used wherever the underlying programming
language type system performs subtype checks, in particular for assignments and pseudo-
assignments.

For normal assignments, the type system checks whether the type of the right-hand side
is a subtype of the left-hand side’s type. An example is demonstrated below. As discussed
before, @StringVal is the default type of String literals, and has the same element value
as the String literal. Hence, the String literal ""SHA-256"" has type @StringVal({""SHA-256""}).
As SHA-256 matches the regular expression SHA-(256|512), i.e., @StringVal({""SHA-256""}) is
a subtype of @AllowedAlgorithms({""SHA−(256|512)""}), this assignment typechecks.

@AllowedAlgorithms({""SHA−(256|512)""}) String algo;

algo = ""SHA−256""; // correct

In contrast, the following assignment check fails because type qualifier @StringVal({""SHA−384""})
is not a subtype of @AllowedAlgorithms({""SHA−(256|512)""}):
@AllowedAlgorithms({""SHA−(256|5";"""date"",""2020-12-06T06:53:22Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2020-12-06T06:53:22Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.21 (TeX Live 2020) kpathsea version 6.3.2""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2020-12-06T06:53:22Z""
""created"",""2020-12-06T06:53:22Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-12-06T06:53:22Z""
""resourceName"",""Xing_Weitian.pdf""
""Author"",""""
""producer"",""pdfTeX-1.40.21""
""pdf:docinfo:producer"",""pdfTeX-1.40.21""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2020-12-06T06:53:22Z""
""Last-Modified"",""2020-12-06T06:53:22Z""
""dcterms:modified"",""2020-12-06T06:53:22Z""
""title"",""""
""Last-Save-Date"",""2020-12-06T06:53:22Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2020-12-06T06:53:22Z""
""meta:save-date"",""2020-12-06T06:53:22Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.21 (TeX Live 2020) kpathsea version 6.3.2""
""Content-Length"",""1151517""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""53""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""248"",""281"",""408"",""2598"",""910"",""527"",""85"",""726"",""924"",""314"",""259"",""1613"",""2214"",""584"",""1246"",""1959"",""960"",""1589"",""2258"",""1588"",""2264"",""1640"",""1684"",""1570"",""1300"",""1798"",""1236"",""1251"",""1938"",""1132"",""1715"",""2001"",""1564"",""1393"",""2201"",""949"",""1228"",""1643"",""1677"",""1690"",""2196"",""2330"",""1711"",""564"",""1367"",""2242"",""366"",""1442"",""1217"",""1232"",""1663"",""1669"",""1799""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-12-06T06:53:22Z""
";https://scholar.google.ch/scholar?start=830&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098879-370;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;[PDF][PDF] Plumo: Towards Scalable Interoperable Blockchains Using Ultra Light Validation Systems;A Gabizon, K Gurkan, P Jovanovic, G Konstantopoulos… ;2020 docs.zkproof.org;;"… We assume a blockchain network where new blocks are chosen by BFT consensus executed

by a … FN16], which is a SNARK that allows for knowledge extraction in the presence of oracles …

A succinct non-interactive argument of knowledge for a relation R and an oracle family O …";Cité 2 fois;;[PDF] zkproof.org;https://docs.zkproof.org/pages/standards/accepted-workshop3/proposal-plumo_celolightclient.pdf;;;https://scholar.google.ch/scholar?start=910&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098795-177;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Bringing order to chaos: the case of collision-resistant Chameleon-Hashes;D Derler, K Samelin, D Slamanig ; IACR International Conference on …, 2020  Springer;;"… [36] have pointed out issues regarding the practicality of the concrete random-oracle model

instantiation 1 … Here, either the hash function to chain blocks in a blockchain or the hash functions

to aggregate transactions within single blocks (usually by means of a Merkle-tree) are …";Cité 4 fois;Les 2 versions;[PDF] iacr.org;https://eprint.iacr.org/2020/403.pdf;"
Bringing Order to Chaos: The Case of
Collision-Resistant Chameleon-Hashes

David Derler1, Kai Samelin2, and Daniel Slamanig3

1 DFINITY, Zurich, Switzerland
david@dfinity.org

2 TÜV Rheinland i-sec GmbH, Hallbergmoos, Germany
kaispapers@gmail.com

3 AIT Austrian Institute of Technology, Vienna, Austria
daniel.slamanig@ait.ac.at

Abstract. Chameleon-hash functions, introduced by Krawczyk and Ra-
bin at NDSS 2000, are trapdoor collision-resistant hash-functions para-
metrized by a public key. If the corresponding secret key is known, arbi-
trary collisions for the hash function can be efficiently found. Chameleon-
hash functions have prominent applications in the design of crypto-
graphic primitives, such as lifting non-adaptively secure signatures to
adaptively secure ones. Recently, this primitive also received a lot of at-
tention as a building block in more complex cryptographic applications
ranging from editable blockchains to advanced signature and encryption
schemes.
We observe that in latter applications various different notions of collision-
resistance are used, and it is not always clear if the respective notion
does really cover what seems intuitively required by the application.
Therefore, we revisit existing collision-resistance notions in the literature,
study their relations, and—using the example of the recent redactable
blockchain proposals—discuss which practical impact different notions of
collision-resistance might have. Moreover, we provide a stronger, and ar-
guably more desirable, notion of collision-resistance than what is known
from the literature. Finally, we present a surprisingly simple and efficient
black-box construction of chameleon-hash functions achieving this strong
notion.

1 Introduction

A chameleon-hash function (CH) is a trapdoor collision-resistant hash-function
parameterized by a public key. If the corresponding secret key is known, arbi-
trary collisions for the hash function, i.e., distinct messages m 6= m′ yielding the
same hash value h, can be efficiently found. Over the years, they have proven to
be a very useful tool in theory, as well as practice. Exemplary, CHs are used to
construct on/offline signatures [17,26,42], and to generically lift non-adaptively

ŠIACR 2020. This article is a minor revision of the version published by Springer-
Verlag available at https://doi.org/10.1007/978-3-030-45374-9_16.

mailto:david@dfinity.org?subject=Question About Your Paper 'Bringing Order to Chaos: The Case of Collision-Resistant Chameleon-Hashes'
mailto:kaispapers@gmail.com?subject=Question About Your Paper 'Bringing Order to Chaos: The Case of Collision-Resistant Chameleon-Hashes'
mailto:daniel.slamanig@ait.ac.at?subject=Question About Your Paper 'Bringing Order to Chaos: The Case of Collision-Resistant Chameleon-Hashes'
https://doi.org/10.1007/978-3-030-45374-9_16


secure signature schemes to adaptively secure ones (cf. [42]), see e.g., Hohen-
berger and Waters [35]. If CHs are tightly-secure, they are used to generically
construct tightly-secure signatures [12]. Likewise, CHs are used to generically
construct strong one-time signatures as shown by Mohassel [39], inspired by a
concrete construction from Pedersen commitments by Groth [30]. Zhang [46]
shows how to construct IND-CCA secure public-key encryption from tag-based
encryption (TBE) or identity-based encryption (IBE) and CHs. Bellare and Ris-
tov made the interesting discovery that chameleon-hashes and ÎŁ-protocols, i.e.,
three round public-coin honest-verifier zero-knowledge proofs of knowledge, are
equivalent [10,11]. CHs are also used to construct sanitizable signatures [3,14,15],
i.e., signatures where a designated entity can modify certain parts of a signed
message without invalidating the respective signature under controlled condi-
tions. Furthermore, CHs have been used by Steinfeld et al. [44] to extend Schnorr
and RSA signatures to the universal designated-verifier setting [43]. Also, dif-
ferent flavors of chameleon-hashing such as (hierarchical) identity-based [5,7] or
policy-based chameleon-hash functions [21,41] have been studied.

In a more applied setting, CHs have shown to be valuable to construct in-
tegrity measurement and remote attestation mechanisms (denoted chameleon
attestation) [2], and are used in vehicular ad-hoc networks (VANETs) [33] or
handover authentication in mobile networks [18]. More recently, CHs have been
used as a means to rewrite blocks in blockchains by replacing the hash function to
chain blocks and/or to hash transactions by chameleon-hashes [4,21], to which we
come back in Sect. 5. This brief discussion already shows that chameleon-hashes
are used in a wide spectrum of different applications requiring different strength
of the respective chameleon-hash. Consequently, authors often introduce some
ad-hoc notion of collision-resistance for their applications, or even ignore that
applications might require a stronger notion. Subsequently, we briefly discuss
the different notions which are most commonly found in the literature.

Formalizing Chameleon-Hashes. The concept of chameleon-hashing dates
back to the notion of trapdoor commitments introduced by Brassard et al. [13],
and was firstly coined chameleon-hashing by Krawczyk and Rabin [37] with an
instantiation based on the well-known trapdoor-commitment scheme by Peder-
sen [40]. Later, Ateniese and de Medeiros in [6] observed that the initial collision-
resistance notion (which we denote W-CollRes) is rather weak (it does not give
the adversary access to any collisions), and, more importantly, it is also satis-
fied by chameleon-hashes suffering from a key-exposure problem. Namely, when
seeing a single collision for some hash h, it allows to publicly extract the secret
trapdoor. Thus, any further guarantees are lost. While this is a desirable property
for the initial use in chameleon signatures [37], and is also sufficient for the lifting
compiler to adaptively secure signatures [42] (as no collision is ever revealed),
it is too weak for many other applications. The key-exposure freeness definition
in [6] is for the specific case of public-coin chameleon-hashing (where verifying
the chameleon-hash is essentially re-computing it). To address this, Ateniese et
al. [4] introduced a related notion called enhanced collision-resistance (which
we denote E-CollRes) for the generalized case of secret-coin chameleon-hashing



(which is the setting that we also consider). The latter notion allows the ad-
versary to see collisions, but it is not allowed to see any collision for the target
hash, i.e., the hash corresponding to the collision it computes. Hence, once a
single collision for a hash h is seen, an adversary can find arbitrary collisions
for that particular hash h. Recently, Khalili et al. [36] have pointed out issues
regarding the practicality of the concrete random-oracle model instantiation4,
proposed by Ateniese et al. in [4], and propose alternative constructions in the
standard model. In another work Camenisch et al. [15] proposed an alternative
collision-resistance notion which allows the adversary to see arbitrary collisions
also for the target hash, but not for the target message, i.e., the message used
in the collision output by the adversary has never been queried. In other words,
once a collision for a message m is seen, an adversary is allowed to find arbitrary
other hashes h′ with the queried messages. Arguably, this notion seems more
realistic as it is better compatible with practical applications (e.g., one can often
make the messages unique by appending a tag/nonce), and thus we denote it as
standard collision-resistance (or S-CollRes).

Motivation and Contribution. The previous discussion already illustrates
that there are many different collision-resistance notions. While this does not
necessarily point to an issue, we observe that it is not always clear whether the
respective notion does really cover what is required by the respective application.
Moreover, it is not clear if the last notion discussed above (S-CollRes) is already
the most desirable notion, or, if even stronger notions are achievable, and do have
practical relevance. Motivated by these observations, we provide the following
contributions:

Relations among Properties. We discuss the different security notions of chame-
leon-hashes, and rigorously study relations among them. Most importantly, we,
for the first time, clarify the picture of existing collision-resistance notions by
showing implications, and separations, (cf. Figure 1 for an overview). In the
course of showing separations, we also provide a construction of a chameleon-
hash satisfying the E-CollRes notion, which clearly demonstrates weaknesses of
this notion.

Stronger Notion. We find that the strongest existing collision-resistance notions,
i.e., E-CollRes and S-CollRes (which are incomparable), might still be too weak
for practical applications, see, e.g., Sect. 5. In particular, even if S-CollRes is
satisfied, the hash values might still be malleable leaving space for potential real-
world attacks. Consequently, we propose a stronger notion coined full collision-
resistance (or F-CollRes for short), which enforces that the adversary cannot
(except with negligible probability) output any new collisions and covers what
one intuitively expects from collision-resistance.

4 The requirement for an invertible encoding into the group introduces an enormous
efficiency penalty, and thus their instantiation is incomplete. Moreover, it is possible
that their schemes do meet our stronger definition of full collision-resistance, but we
neither prove nor disprove this statement here.



F-CollRes S-CollRes W-CollRes

E-CollRes

+

\ \

\\ \

Fig. 1. Relations between CH collision-resistance properties

Black-Box Construction. We present a simple black-box construction of a chame-
leon-hash function satisfying this strong F-CollRes notion. Considering the com-
plexity of existing constructions in [4, 36] which only achieve the weaker notion
of E-CollRes, this is somewhat surprising. To recall, the construction from Ate-
niese et al. [4] starts from a public-coin chameleon-hash function that satisfies
W-CollRes, uses an IND-CPA secure encryption scheme to encrypt the random-
ness of the chameleon-hash and then uses a true-simulation extractable (tSE)
NIZK [25], which is in turn based on a NIZK and an IND-CCA secure public-
key encryption scheme, to prove that the ciphertext is an encryption of the
randomness. The constructions from Khalili et al. [36], which avoid the afore-
mentioned issues with [4], are based on another new public-coin chameleon-
hash function that satisfies W-CollRes and then either uses Groth-Sahai NIZK
proofs [32] and the IND-CCA secure Cramer-Shoup encryption scheme [20] or a
succinct non-interactive argument of knowledge (SNARK). Both constructions
in [36] basically follow the generic template in [4]. In contrast, our black-box
construction of a F-CollRes chameleon-hash is constructed from perfectly correct
(multi-challenge) IND-CPA secure encryption, e.g., ElGamal encryption, and a
simulation-sound extractable non-interactive zero-knowledge proof (SSE-NIZK),
e.g., applying the compiler of Faust et al. [27] to a Fiat-Shamir transformed ÎŁ-
protocol. The basic idea is that the chameleon-hash is the encryption c of the
message m and the randomness of the chameleon-hash is a NIZK proof s.t. ei-
ther c correctly encrypts m under the pk of CH or one knows the secret key
sk corresponding to pk. Interestingly, already a perfectly-binding commitment
(without any hiding) is sufficient to achieve the F-CollRes notion, but instead a
multi-challenge IND-CPA secure encryption scheme as a perfectly-binding com-
mitment is used to additionally achieve the indistinguishability property of the
CH, i.e., that fresh and adapted hashes are indistinguishable, a notion that is
considered standard for chameleon-hashes.

Applications. We discuss how our stronger notion allows to strengthen the secu-
rity of existing applications and in particular will discuss what problems may be
caused by different notions of collision-resistance within recent applications to
redactable blockchains [4,21]. Here, either the hash function to chain blocks in a
blockchain or the hash functions to aggregate transactions within single blocks
(usually by means of a Merkle-tree) are replaced by a chameleon-hash function.



2 Preliminaries

Notation. With Ν ∈ N we denote our security parameter. All algorithms im-
plicitly take 1λ as an additional input. We write a ←r A(x) if the output of a
probabilistic algorithm A with input x is assigned to a and use a ← A(x) if A
is deterministic. An algorithm is efficient, if it runs in probabilistic polynomial
time (PPT) in the length of its input. All algorithms are PPT, if not explicitly
mentioned otherwise. If we want to make the random coins used by an algorithm
A explicit, we use the notation a ←r A(x; ξ). We write (a; ξ) ←r A(x), if we
need to access the random coins Ξ internally drawn by A. Most algorithms may
return a special error symbol ⊥ /∈ {0, 1}∗, denoting an exception. Returning out-
put ends execution of an algorithm or an oracle. To make the presentation in the
security proofs more compact, we occasionally use (a,⊥) ←r A(x) to indicate
that the second output is either ignored or not returned by A. If S is a finite
set, we write a ←r S to denote that a is chosen uniformly at random from S.
M denotes a message space of a scheme, and we generally assume that M is
derivable from the scheme’s public parameters or its public key. For a list we
require that there is an injective, and efficiently reversible, encoding, that maps
the list to {0, 1}∗. A function ν : N→ R≥0 is negligible, if it vanishes faster than
every inverse polynomial, i.e., ∀k ∈ N, ∃n0 ∈ N such that ν(n) ≤ n−k, ∀n > n0.

2.1 Building Blocks

We now present the building blocks we require. These include key-verifiable
multi-challenge IND-CPA (mcIND-CPA) secure public-key encryption schemes
Ω, digitall signature schemes Σ, and non-interactive zero-knowledge proofs Π.

Public-Key Encryption Schemes. Subsequently, we define public-key en-
cryption schemes.

Definition 1 (Public-Key Encryption Scheme). A public-key encryption
scheme Ω consists of five algorithms {PGΩ,KGΩ,Enc,Dec,KVfΩ}, such that:

PGΩ. The algorithm PGΩ outputs the public parameters of the scheme:

ppΩ ←r PGΩ(1λ).

It is assumed that ppΩ is an implicit input to all other algorithms.
KGΩ. The algorithm KGΩ outputs the key pair, on input ppΩ:

(skΩ, pkΩ)←r KGΩ(ppΩ).

Enc. The algorithm Enc gets as input the public key pkΩ, and a message m ∈M
to encrypt. It outputs a ciphertext c:

c←r Enc(pkΩ,m).



Expmc-IND-CPA
A,Ω (λ):

ppΩ ←r PGΩ(1λ)
(skΩ, pkΩ)←r KGΩ(ppΩ)
b←r {0, 1}
a←r AEnc′(pkΩ,·,·,b)(pkΩ)

where Enc′ on input pkΩ,m0,m1, b:
If m0 /∈M∨m1 /∈M∨ |m0| 6= |m1|:
c← ⊥

Else:
c←r Enc(pkΩ,mb)

return c
return 1, if a = b
return 0

Fig. 2. Multi-Challenge IND-CPA Security

Dec. The deterministic algorithm Dec outputs a message m ∈M∪{⊥} on input
skΩ, and a ciphertext c:

m← Dec(skΩ, c).

KVfΩ. The deterministic algorithm KVfΩ decides whether a given public key pkΩ

corresponds to a given secret key skΩ:

d← KVfΩ(pkΩ, skΩ).

Definition 2 (Correctness). A public key encryption scheme Ω is called cor-
rect, if for all security parameters λ ∈ N, for all ppΩ ←r PGΩ(1λ), for all
(skΩ, pkΩ)←r KGΩ(ppΩ), for all m ∈M, for all c←r Enc(pkΩ,m), we have that
m = Dec(skΩ, c) and that for all skΩ

′ we have that KVfΩ(pkΩ, skΩ
′) = 1 =⇒

m = Dec(skΩ
′, c).

Definition 3 (Multi-Challenge IND-CPA Security). A public-key encryp-
tion scheme Ω is multi-challenge IND-CPA secure (mcIND-CPA), if for any
PPT adversary A there exists a negligible function ν such that:∣∣∣Pr

[
ExpmcIND-CPA

A,Ω (λ) = 1
]
− 1/2

∣∣∣ ≤ ν(λ).

The corresponding experiment is depicted in Figure 2.

Bellare et al. have shown, via a hybrid argument, that mcIND-CPA is equivalent
to standard, i.e., “single-message”, IND-CPA [8]. We opted for using mcIND-CPA,
because it allows writing our proofs down more compactly, improving readability.

Digital Signature Schemes. Subsequently, we define signature schemes.

Definition 4 (Digital Signatures). A digital signature scheme ÎŁ consists of
four algorithms {PGÎŁ,KGÎŁ,SgnÎŁ,VrfÎŁ} such that:



PGÎŁ. The algorithm PGÎŁ outputs the public parameters

ppΣ ←r PGΣ(1λ).

We assume that ppÎŁ contains 1Îť and is implicit input to all other algorithms.
KGÎŁ. The algorithm KGÎŁ outputs the public and private key of the signer, where

Îť is the security parameter:

(skΣ, pkΣ)←r KGΣ(ppΣ).

SgnÎŁ. The algorithm SgnÎŁ gets as input the secret key skÎŁ and the message
m ∈M to sign. It outputs a signature:

σ ←r SgnΣ(skΣ,m).

VrfΣ. The deterministic algorithm VrfΣ outputs a decision bit d ∈ {0, 1}, indi-
cating if the signature σ is valid, w.r.t. pkΣ and m:

d← VrfΣ(pkΣ,m, σ).

Definition 5 (Correctness). A digital signature scheme ÎŁ is called correct, if
for all security parameters λ ∈ N, for all ppΣ ←r PGΣ(1λ), for all (skΣ, pkΣ)←r

KGΣ(ppΣ), for all m ∈M, VrfΣ(pkΣ,m,SgnΣ(skΣ,m)) = 1 is true.

We require existential unforgeability under adaptively chosen message attacks
(eUNF-CMA security). In a nutshell, unforgeability requires that an adversary
A cannot (except with negligible probability) come up with a signature for a
message m∗ for which the adversary did not see any signature before, even if
the adversary A is allowed to adaptively query for signatures on messages of its
own choice.

ExpeUNF-CMA
A,ÎŁ (Îť)

ppΣ ←r PGΣ(1λ)
(skΣ, pkΣ)←r KGΣ(ppΣ)
Q ← ∅
(m∗, σ∗)←r ASgn′Σ(skΣ,·)(pkΣ)

where Sgn′Σ on input skΣ and m:
σ ←r SgnΣ(skΣ,m)
set Q ← Q∪ {m}
return σ

return 1, if VrfÎŁ(pkÎŁ,m
∗, σ∗) = 1 ∧ m∗ /∈ Q

return 0

Fig. 3. Unforgeability



Definition 6 (Unforgeability). We say a digital signature scheme ÎŁ scheme
is unforgeable, if for every PPT adversary A, there exists a negligible function
ν such that:

Pr
[
ExpeUNF-CMA

A,ÎŁ (Îť) = 1
]
≤ ν(λ).

The corresponding experiment is depicted in Figure 3.

For Construction 1, we require that the size of signatures is independent of the
size of the signed messages.

Non-Interactive Proof Systems. Let L be an NP-language with associated
witness relation R, i.e., such that L = {x | ∃w : R(x,w) = 1}. A non-interactive
proof system allows to prove membership of some statement x in the language
L. More formally, such a system is defined as follows.

Definition 7 (Non-Interactive Proof System). A non-interactive proof sys-
tem Π for language L consists of three algorithms {PGΠ,PrfΠ,VfyΠ}, such that:

PGΠ. The algorithm PGΠ outputs public parameters of the scheme, where Ν is
the security parameter:

crsΠ ←r PGΠ(1λ).

PrfΠ. The algorithm PrfΠ outputs the proof π, on input of the CRS crsΠ, state-
ment x to be proven, and the corresponding witness w:

π ←r PrfΠ(crsΠ, x, w).

VfyΠ. The deterministic algorithm VfyΠ verifies the proof π by outputting a bit
d ∈ {0, 1}, w.r.t. to some CRS crsΠ and some statement statement x:

d← VfyΠ(crsΠ, x, π).

Definition 8 (Correctness). A non-interactive proof system is called correct,
if for all λ ∈ N, for all crsΠ ←r PGΠ(1λ), for all x ∈ L, for all w such that
R(x,w) = 1, for all π ←r PrfΠ(crsΠ, x, w), it holds that VfyΠ(crsΠ, x, π) = 1.

In the context of (zero-knowledge) proof-systems, correctness is sometimes also
referred to as completeness. In addition, we require two standard security notions
for zero-knowledge proofs of knowledge: zero-knowledge and simulation-sound
extractability. We define them analogously to the definitions given in [22].

Informally speaking, zero-knowledge says that the receiver of the proof π
does not learn anything except the validity of the statement.

Definition 9 (Zero-Knowledge). A non-interactive proof system Π for lan-
guage L is zero-knowledge, if for any PPT adversary A, there exists an PPT



ExpZero-Knowledge
A,Π,SIM (Ν)

(crsΠ, τ)←r SIM1(1λ)
b←r {0, 1}
b∗ ←r APb(·,·)(crsΠ)

where P0 on input x, w:
return π ←r PrfΠ(crsΠ, x, w), if R(x,w) = 1
return ⊥

and P1 on input x, w:
return π ←r SIM2(crsΠ, τ, x), if R(x,w) = 1
return ⊥

return 1, if b∗ = b
return 0

Fig. 4. Zero-Knowledge

simulator SIM = (SIM1,SIM2) such that there exist negligible functions ν1 and
ν2 such that∣∣∣∣Pr

[
crsΠ ←r PGΠ(1λ) : A(crsΠ) = 1]−

Pr
[
(crsΠ, τ)←r SIM1(1λ) : A(crsΠ) = 1

]∣∣∣∣ ≤ ν1(λ),

and that ∣∣∣Pr
[
ExpZero-Knowledge

A,Π,SIM (Ν) = 1
]
− 1/2

∣∣∣ ≤ ν2(λ),

where the corresponding experiment is depicted in Figure 4.

Simulation-sound extractability says that every adversary who is able to come
up with a proof π∗ for a statement must know the witness, even when seeing sim-
ulated proofs for adaptively chosen statements potentially not in L. Clearly, this
implies that the proofs output by a simulation-sound extractable proof-systems
are non-malleable. Note that the definition of simulation-sound extractability

ExpSimSoundExt
A,Π,E (Ν)

(crsΠ, τ, ζ)←r E1(1λ)
Q ← ∅
(x∗, π∗)←r ASIM(·)(crsΠ)

where SIM on input x:
obtain π ←r SIM2(crsΠ, τ, x)
Q ← Q∪ {(x, π)}
return π

w∗ ←r E2(crsΠ, ζ, x
∗, π∗)

return 1, if VfyΠ(x∗, π∗) = 1 ∧ R(x∗, w∗) = 0 ∧ (x∗, π∗) /∈ Q
return 0

Fig. 5. Simulation Sound Extractability



of [30] is stronger than ours in the sense that the adversary also gets the trap-
door Îś as input. However, in our context this weaker notion (previously also used
e.g. in [1, 25]) suffices.

Definition 10 (Simulation-Sound Extractability). A zero-knowledge non-
interactive proof system Π for language L is said to be simulation-sound ex-
tractable, if for any PPT adversary A, there exists a PPT extractor E = (E1, E2),
such that∣∣∣∣Pr
[
(crsΠ, τ)←r SIM1(1λ) : A(crsΠ, τ) = 1]−

Pr
[
(crsΠ, τ, ζ)←r E1(1λ) : A(crsΠ, τ) = 1

]∣∣∣∣ = 0,

and that there exist a negligible function ν so that

Pr
[
ExpSimSoundExt

A,Π,E (Ν)
]

= 1 ≤ ν(λ),

where the corresponding experiment is depicted in Figure 5.

3 Chameleon-Hashes, Revisited

In this section we present the formal framework for chameleon-hashes, their
security properties with a special focus on the collision-resistance notion and
then show relations and separations between the security properties.

3.1 Framework

We now present the framework for chameleon-hashes. We rely on the most recent
comprehensive framework by Camenisch et al. [15], which is, in turn, based upon
work done by Ateniese et al. and Brzuska et al. [4, 14].

Definition 11. A chameleon-hash CH is a tuple of five PPT algorithms (CHPG,
CHKG,CHash,CHCheck,CHAdapt), such that:

CHPG. The algorithm CHPG, on input a security parameter Îť outputs public
parameters of the scheme:

ppch ←r CHPG(1λ).

We assume that ppch is implicit input to all other algorithms.
CHKG. The algorithm CHKG, on input the public parameters ppch outputs the

private and public keys of the scheme:

(skch, pkch)←r CHKG(ppch).



CHash. The algorithm CHash gets as input the public key pkch, and a message
m to hash. It outputs a hash h, and some randomness r:5

(h, r)←r CHash(pkch,m).

CHCheck. The deterministic algorithm CHCheck gets as input the public key
pkch, a message m, randomness r, and a hash h. It outputs a bit d ∈ {0, 1},
indicating whether the hash h is valid:

d← CHCheck(pkch,m, r, h).

CHAdapt. The algorithm CHAdapt on input of a secret key skch, the message m,
new message m′, randomness r, and hash h outputs new randomness r′:

r′ ←r CHAdapt(skch,m,m
′, r, h).

Definition 12 (Correctness). A chameleon-hash is called correct, if for all
security parameters λ ∈ N, for all ppch ←r CHPG(1λ), for all (skch, pkch) ←r

CHKG(ppch), for all m ∈ M, for all (h, r) ←r CHash(pkch,m), for all m′ ∈ M,
we have for all r′ ←r CHAdapt(skch,m,m

′, r, h), that 1 = CHCheck(pkch,m,
r, h) = CHCheck(pkch,m

′, r′, h).

3.2 Indistinguishability

Indistinguishability requires that the randomness r does not reveal if it was
obtained through CHash or CHAdapt. Upon setup, a challenger generates a key
pair (skch, pkch) for CH (along with some public parameters), and draws a bit
b←r {0, 1}. The challenger initializes the adversary with the pkch and gives the
adversary access to a HashOrAdapt oracle, which allows the adversary to submit
two messages m, m′. Depending on the bit b, the challenger then either hashes
m′ directly (b = 0), of first hashes m, and then adapts m to m′ (b = 1). The
resulting hash/randomness pair (h, r) (or (h′, r′′) resp.) is the oracle’s output to
the adversary. The adversary’s objective is to guess the bit b. Note that all keys
are generated honestly and the adversary gets access to a collision-finding oracle
CHAdapt for arbitrary hashes, meaning that the adversary may also input hashes
generated by the HashOrAdapt-oracle. We stress that there may be scenarios
where indistinguishability is not required or even hindering.

Definition 13 (Indistinguishability). A chameleon-hash CH is indistinguish-
able, if for any PPT adversary A there exists a negligible function ν such that∣∣∣Pr[ExpInd

A,CH(λ) = 1]− 1/2
∣∣∣ ≤ ν(λ),

where the corresponding experiment is depicted in Figure 6.

5 We note that the randomness r is also sometimes called “check value” [4].



ExpInd
A,CH(Îť)

ppch ←r CHPG(1λ)
(skch, pkch)←r CHKG(ppch)
b←r {0, 1}
a←r AHashOrAdapt(skch,·,·,b),CHAdapt(skch,pkch,·,·,·)(pkch)

where HashOrAdapt on input skch,m,m
′, b:

(h, r)← CHash(pkch,m
′)

(h′, r′)← CHash(pkch,m)
r′′ ← CHAdapt(skch,m,m

′, r′, h′)
If r = ⊥ ∨ r′′ = ⊥, return ⊥
if b = 0:

return (h, r)
if b = 1:

return (h′, r′′)
return 1, if a = b
return 0

Fig. 6. CH Indistinguishability

Samelin and Slamanig recently introduced full indistinguishability [41], which,
in turn, generalizes the notion of strong indistinguishability by Derler et al. [21].
In their notion, the adversary is even allowed to generate the keys which are
used for hashing and adapting (in the strong version, the adversary only knows
all keys, but cannot generate them).

We do neither consider full nor strong indistinguishability as fundamental for
chameleon-hashes, but examine these notions to achieve a more complete picture
of the relations. The formal definitions of full and strong indistinguishability are
given in Appendix A, where we also prove that full indistinguishability is strictly
stronger than strong indistinguishability, which, in turn, is strictly stronger than
indistinguishability.

3.3 Collision-Resistance

In this section we revisit existing collision-resistance notions, introduce a stronger
and more desirable notion of collision-resistance dubbed full collision-resistance
(or F-CollRes for short) and discuss how these notions differ. The main idea be-
hind collision-resistance in general is to argue that an adversary that has no ac-
cess to the secret key skch cannot find any collisions, i.e,. pairs (m, r) and (m′, r′)
and hash value h s.t. CHCheck(pkch,m, r, h) = CHCheck(pkch,m

′, r′, h) = 1. In
the weakest case, the adversary has no access to any other collisions, whereas in
stronger notions the adversary is explicitly allowed to obtain collisions for arbi-
trary hashes via a CHAdapt′ oracle (we indicate these by using boxes).
We present all the different notions in Figure 7, where we indicate the differ-
ences in the winning conditions by using boxes. In all the experiments
the challenger generates a key pair (skch, pkch) honestly (along with some public
parameters) and the adversary is then initialized with pkch. We now discuss the



ExpW-CollRes
A,CH (Îť)

ppch ←r CHPG(1λ)
(skch, pkch)←r CHKG(ppch)

(m∗, r∗,m′∗, r′∗, h∗)←r A(pkch)

return 1, if CHCheck(pkch,m
∗, r∗, h∗) = 1 ∧

CHCheck(pkch,m
′∗, r′∗, h∗) = 1 ∧

m∗ 6= m′∗

return 0

ExpE-CollRes
A,CH (Îť)

ppch ←r CHPG(1λ)
(skch, pkch)←r CHKG(ppch)

Q ← ∅

(m∗, r∗,m′∗, r′∗, h∗)←r A
CHAdapt′(skch, ·, ·, ·, ·) (pkch)

where CHAdapt′ on input skch,m,m
′, r, h:

return ⊥, if CHCheck(pkch,m, r, h) 6= 1
r′ ←r CHAdapt(skch,m,m

′, r, h)
If r′ = ⊥, return ⊥
Q ← Q∪ {h}

return r′

return 1, if CHCheck(pkch,m
∗, r∗, h∗) = 1 ∧

CHCheck(pkch,m
′∗, r′∗, h∗) = 1 ∧

m∗ 6= m′∗ ∧ h∗ /∈ Q
return 0

ExpS-CollRes
A,CH (Îť)

ppch ←r CHPG(1λ)
(skch, pkch)←r CHKG(ppch)

Q ← ∅

(m∗, r∗,m′∗, r′∗, h∗)←r A
CHAdapt′(skch, ·, ·, ·, ·) (pkch)

where CHAdapt′ on input skch,m,m
′, r, h:

return ⊥, if CHCheck(pkch,m, r, h) 6= 1
r′ ←r CHAdapt(skch,m,m

′, r, h)
If r′ = ⊥, return ⊥
Q ← Q∪ {m,m′}

return r′

return 1, if CHCheck(pkch,m
∗, r∗, h∗) = 1 ∧

CHCheck(pkch,m
′∗, r′∗, h∗) = 1 ∧

m∗ 6= m′∗ ∧ m∗ /∈ Q
return 0

ExpF-CollRes
A,CH (Îť)

ppch ←r CHPG(1λ)
(skch, pkch)←r CHKG(ppch)

Q ← ∅

(m∗, r∗,m′∗, r′∗, h∗)←r A
CHAdapt′(skch, ·, ·, ·, ·) (pkch)

where CHAdapt′ on input skch,m,m
′, r, h:

return ⊥, if CHCheck(pkch,m, r, h) 6= 1
r′ ←r CHAdapt(skch,m,m

′, r, h)
If r′ = ⊥, return ⊥
Q ← Q∪ {(h,m), (h,m′)}

return r′

return 1, if CHCheck(pkch,m
∗, r∗, h∗) = 1 ∧

CHCheck(pkch,m
′∗, r′∗, h∗) = 1 ∧

m∗ 6= m′∗ ∧ (h∗,m∗) /∈ Q
return 0

Fig. 7. The ExpX-CollRes
A,CH experiment with X ∈ {W,E, S,F}.

differences of the single collision resistance notions, where in the weakest case
the adversary has no access to an CHAdapt′ oracle (which allows the adversary
to adaptively ask for collisions with messages and hashes of its own choice), but
in all other cases the adversary does. To vertically align the experiments, we
insert boxes for lines which are missing in one experiment but are
present in the other.

Weak Collision-Resistance (W-CollRes) [37]. The adversaryA wins, if it can
come up with a collision for the given public key.

Enhanced Collision-Resistance (E-CollRes) [4]. The adversary gets access
to a collision-finding oracle CHAdapt′, which outputs a collision for adver-
sarially chosen hashes, but also keeps track of each queried hash h using the
list Q. The adversary wins, if it comes up with a collision for the given public
key for an adverserially chosen hash h∗ never input to CHAdapt′.



Standard Collision-Resistance (S-CollRes) [15]. The adversary gets access
to a collision-finding oracle CHAdapt′, which outputs a collision for the ad-
versarially chosen hash, but also keeps track of each of the queried messages
m and m′, using the listQ. The adversary wins, if it comes up with a collision
for the given public key for an adversarially chosen h∗ for which the message
m∗ output by the adversary was never queried to the collision-finding oracle.

Full Collision-Resistance (F-CollRes). The adversary gets access to a collision-
finding oracle CHAdapt′, which outputs a collision for the adversarially cho-
sen hash, but also keeps track of each of the queried hash/message pair
(h,m) and (h,m′), using the list Q. The adversary wins, if it comes up with
a hash/message pair (h∗,m∗), for the given public key, never queried to or
output from the collision-finding oracle.6

Now, we formally define security with respect to all the collision-resistance no-
tions.

Definition 14 (X Collision-Resistance). A chameleon-hash CH offers X coll-
ision-resistance with X ∈ {W,E,S,F}, if for any PPT adversary A there exists
a negligible function ν such that

Pr[ExpX-CollRes
A,CH (λ) = 1] ≤ ν(λ),

where the corresponding experiment is depicted in Figure 7.

Discussion of the Notions. W-CollRes is the notion introduced in the first
work on chameleon-hashes by Krawczyk and Rabin [37] and essentially repre-
sents the binding notion of a trapdoor-commitment scheme. Note that due to
not giving access to a collision-finding oracle it gives no guarantees whatsoever
if the adversary sees a single collision for any hash computed for the given pub-
lic key.7 The E-CollRes notion has been introduced by Ateniese et al. [4] and
we note that there exists a definition in";"""date"",""2020-03-23T12:19:53Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2020-03-23T12:19:53Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is MiKTeX-pdfTeX 2.9.7338 (1.40.21)""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2020-03-23T12:19:53Z""
""created"",""2020-03-23T12:19:53Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-03-23T12:19:53Z""
""resourceName"",""403.pdf""
""Author"",""""
""producer"",""MiKTeX pdfTeX-1.40.21""
""pdf:docinfo:producer"",""MiKTeX pdfTeX-1.40.21""
""pdf:unmappedUnicodeCharsPerPage"",""3"",""0"",""1"",""0"",""0"",""14"",""2"",""2"",""19"",""13"",""21"",""19"",""53"",""6"",""4"",""19"",""11"",""36"",""31"",""36"",""7"",""38"",""26"",""47"",""4"",""7"",""16"",""1"",""0"",""0"",""36"",""36"",""15"",""13"",""29"",""57"",""26"",""38""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2020-03-23T12:19:53Z""
""Last-Modified"",""2020-03-23T12:19:53Z""
""dcterms:modified"",""2020-03-23T12:19:53Z""
""title"",""""
""Last-Save-Date"",""2020-03-23T12:19:53Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2020-03-23T12:19:53Z""
""meta:save-date"",""2020-03-23T12:19:53Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is MiKTeX-pdfTeX 2.9.7338 (1.40.21)""
""Content-Length"",""613606""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""38""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""2047"",""3038"",""2762"",""2346"",""1874"",""1316"",""1177"",""1724"",""1057"",""1339"",""1867"",""1902"",""1922"",""2615"",""1284"",""2480"",""2452"",""2003"",""2293"",""2138"",""1278"",""1258"",""1537"",""2345"",""2234"",""2264"",""2307"",""2512"",""2807"",""2669"",""1829"",""2249"",""1687"",""1710"",""1208"",""1211"",""1557"",""1952""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-03-23T12:19:53Z""
";https://scholar.google.ch/scholar?start=720&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098879-361;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Transparent SNARKs from DARK compilers;B Bünz, B Fisch, A Szepieniec ; … on the Theory and Applications of …, 2020  Springer;;"… This has been done on two occasions for the ZCash blockchain, involving elaborate “ceremonies”

to … The verifier may then query this oracle to evaluate the polynomial on arbitrary points of … concrete

efficiency is much worse due to the use of heavy-weight “crypto operations” over …";Cité 55 fois;Les 3 versions;[PDF] asz.ink;https://asz.ink/wp-content/uploads/2019/10/dark.pdf;"
Transparent SNARKs from DARK Compilers

Benedikt Bünz1

benedikt@cs.stanford.edu

Ben Fisch1

bfisch@cs.stanford.edu

Alan Szepieniec2

alan@nervos.org

1Stanford University, Findora Foundation
2Nervos Foundation

October 19, 2019

Abstract

We construct a new polynomial commitment scheme for univariate and multivariate
polynomials over finite fields, with public-coin evaluation proofs that have logarithmic
communication and verification cost in the number of coefficients of the polynomial.
The underlying technique is a Diophantine Argument of Knowledge (DARK), leverag-
ing integer representations of polynomials and groups of unknown order. Security is
shown from the strong RSA and the adaptive root assumption. Moreover, the scheme
does not require a trusted setup if instantiated with class groups. We apply this new
cryptographic compiler to a restricted class of algebraic linear IOPs in order to obtain
doubly-efficient public-coin IPs with succinct communication and witness-extended em-
ulation for any NP relation. Allowing for linear preprocessing, the online verifier’s work
is logarithmic in the circuit complexity of the relation.

In particular, we obtain quasi-linear prover time when compiling the IOP employed
in Sonic (MBKM, CCS 19). Applying the Fiat-Shamir transform in the random oracle
model results in a SNARK system with quasi-linear preprocessing, quasi-linear (on-
line) prover time, logarithmic proof size, and logarithmic (online) verification time for
arbitrary circuits. The SNARK is also concretely efficient with 7.8KB proofs (70× re-
duction over state of the art) and 75ms verification time for circuits with 1 million gates.
Most importantly, this SNARK is transparent : it does not require a trusted setup. We
also obtain zk-SNARKs by applying a variant of our polynomial commitment scheme
that is hiding and offers zero-knowledge evaluation proofs. This construction is the first
transparent zk-SNARK that has both a practical prover time as well as asymptotically
logarithmic proof size and verification time. We call this system Supersonic.

1 Introduction

Since the landmark discoveries of interactive proofs (IPs) [GMR85] and probabilistically
checkable proofs (PCPs) [BFLS91, ALM+92] in the 90s, there has been tremendous develop-
ment in the area of proof systems whereby a prover establishes the correct performance of an
arbitrary computation in a way that can be verified much more efficiently than performing
the computation itself. Such proof systems are succinct if they also involve induce a low
communication cost between the prover and the verifier, i.e., the transcript of the protocol
is much smaller than a witness to the computation. There are also zero knowledge variants
of these efficient proof systems, beginning with ZK-IPs [BGG+88] and ZK-PCPs [Kil92], in
which the computation may involve secret information and the prover demonstrates correct
performance without leaking the secrets. As a toy example, one could prove that a chess
position is winning for white without actually revealing the winning moves themselves. Gen-
eral purpose zero-knowledge proofs [GMW91] can be very expensive in terms of proof size
and verification time even for computations that would be easy to perform given the secret
inputs (e.g., by proving that one decrypted a file properly without leaking the key or the
plaintext). The same techniques that are used to build efficient proof systems for expensive
computations are also useful for making zero-knowledge proofs more practical.

In recent years, there has been a surge of industry interest in verifiable outsourced compu-
tation [WB15] (such as trustless cloud computing) as well as zero-knowledge proofs. In par-
ticular, blockchains use efficient zero-knowledge proofs as a solution for balancing privacy and

1



publicly-verifiable integrity: examples include anonymous transactions in ZCash [BCG+14,
Zca] and verifying Ethereum smart contracts over private inputs [Ebe]. In these applica-
tions, zero-knowledge proofs are posted to the blockchain ledger as a part of transactions
and nodes must verify many proofs in the span of a short period of time. Therefore, succinct-
ness and fast verification are necessary properties for the deployment of such proof systems.
Verifiable computation is also being explored as a scaling solution for blockhain transac-
tions [But16], and even as a way to entirely eliminate the need for maintaining historical
blockchain data [Lab18].

Following this pragmatic interest, there has also been a surge of research focused on
obtaining proof systems with better concrete efficiency characteristics: succinctness (the
proof size is sublinear in the original computation length T ), non-interactivity (the proof is
a single message), prover-scalability (proof generation time scales linearly or quasi-linearly in
T ), and verifier-scalability (verification time is sublinear in T ). Proof systems that achieve all
of these properties for general NP statementsare called SNARGs (“succinct non-interactive
arguments”). The proof is called an argument when it is only sound assuming the prover
is computationally bounded, i.e., computationally sound as opposed to statistically sound.
Succinct statistically sound proofs are unlikely to exist [GVW02, Wee05].

Currently, there are numerous constructions that achieve different tradeoffs between proof
size, proof time, and verification time, but also under different trust models as well as
cryptographic assumptions. Some constructions also achieve better efficiency by relying on
a preprocessing model in which a one-time expensive setup procedure is performed in order
to generate a compact verification key VK, which is later used to verify proof instances
efficiently. Somewhat unfortunately, the best performing proof systems to date (considering
proof size and verification time) require a trusted preprocessing. These are the pairing-based
SNARKs extending from GGPR [GGPR13, SBV+13, BCI+13, BCG+13, Gro16], which have
been implemented in numerous libraries [BCG+13, Bow16], and even deployed in live systems
such as the ZCash [Zca] cryptocurrency. The trusted setup can be performed via multi-party
computation (MPC) by a committee of parties, such that trust in only one of the parties is
sufficient. This has been done on two occasions for the ZCash blockchain, involving elaborate
“ceremonies” to engender public trust in the process [Wil16].

A proof system is called transparent if it does not involve any trusted setup. Re-
cent progress has yielded transparent proof systems for special types of computations: zk-
STARKs [BBHR19] generate zero-knowledge proofs of size O(log2 T ) for a uniform computa-
tion1, and the GKR protocol produces interactive proofs with communication O(d log T ) for
computations expressed as low-depth circuits of total size T and depth d [GKR08]. In both
cases, non-interactivity can be achieved in the random oracle model with the Fiat-Shamir
heuristic [FS87, CCH+19]. These transparent proof systems perform significantly worse
than SNARKs based on preprocessing. For computations expressed as an arithmetic circuit
of 1-million gates, STARKs [BBHR19] report a proof size of 600KB, whereas preprocess-
ing SNARKs achieve 200 bytes [Gro16]. Bulletproofs [BBB+18, BCC+16a] is a transparent
zero-knowledge proof system whose proofs are much smaller than those of STARK, but these
proofs have a verification time that scales linearly in the size of the circuit; for an arithmetic
circuit of one million gates the verification time is close to 1 minute, more than 1,000 times
more expensive than verifying a STARK proof for the same computation.

Another thread of research has produced proof systems that remove trust from the circuit
preprocessing step, and instead have a universal (trusted) setup: a one-time trusted setup
that can be reused for any computation [MBKM19, XZZ+19, Set19, GWC19]. All of these
systems build SNARKs by combining an underlying reduction of circuit satisfiability to prob-
abilistic testing of polynomials (with degree at most linear in the circuit size) together with
polynomial commitment schemes. In a polynomial commitment scheme, a prover commits to
a Âľ-variate polynomial f over F of degree at most d with a message that is much smaller than
sending all the coefficients of f . The prover can later produce a non-interactive argument
that f(z) = y for arbitrary z ∈ F¾ and y ∈ F. The trusted portion of the universal SNARK
is entirely confined to the polynomial commitment scheme’s setup. These constructions use
variants of the Kate et al. commitment scheme for univariate polynomials [KZG10], which
requires a trusted setup.

1A uniform computation is expressed as a RAM program P and a time bound T on the running time
of the program. While the size of P ’s description does affect the proof size, the clue is that the size of this
description does not scale with the time bound T .

2



1.1 Summary of contributions

Following the observations of the recent universal SNARK constructions [GWC19, MBKM19,
XZZ+19], SNARKs can be built from polynomial commitment schemes where all the trust
is confined to the setup of the commitment scheme. The main technical contribution of our
work is thus a new polynomial commitment scheme without trusted setup (i.e., a transpar-
ent polynomial commitment scheme), which we can use to construct transparent SNARKs.
The observation that transparent polynomial commitments imply transparent SNARKs was
also implicit in the recent works that build transparent SNARKs from multi-round classi-
cal PCPs, and specifically interactive oracle proofs of proximity (IOPPs) [BBHR18]. As a
secondary contribution, we present a framework that unifies all existing approaches to con-
structing SNARKs from polynomial commitments using the language of interactive oracle
proofs (IOPs) [RRR16, BCS16]. We view polynomial commitment schemes as a compiler
for Polynomial IOPs, and re-characterize the results of prior works as providing a variety of
Polynomial IOPs for NP.

New polynomial commitment scheme We construct a new polynomial commitment
scheme for Âľ-multivariate polynomials of degree d with optional zero-knowledge arguments
of knowledge for correct evaluation that have O(Âľ log d) size proofs and are verifiable in
O(Âľ log d) time. The commitment scheme requires a group of unknown order: two candidate
instantiations are RSA groups and class groups of an imaginary quadratic order. Using RSA
groups, we can apply the scheme to obtain universal preprocessing SNARKs with constant-
size setup parameters, as opposed to the linear-size parameters from previous attempts.
Using class groups, we can remove the trusted setup from trusted-setup SNARKs altogether,
thereby making them transparent. Our polynomial commitment scheme leverages the power
of integer commitments and Diophantine Arguments of Knowledge [Lip03]; accordingly, we
classify this tool (and others of its kind) as a DARK proof system.

Polynomial IOP formalism All SNARK constructions can be viewed as combining an
underlying information-theoretic statistically-sound protocol with a “cryptographic com-
piler” that transforms the underlying protocol into a succinct argument at the cost of
computational soundness. We define a Polynomial IOP as a refinement of algebraic lin-
ear IOPs [IKO07, BCI+13, BBC+19], where in each round of interaction the prover provides
the verifier with oracle access to a multivariate polynomial function of bounded degree. The
verifier may then query this oracle to evaluate the polynomial on arbitrary points of its
choice. The existing universal and transparent SNARK constructions provide a variety of
statistically-sound Polynomial IOPs for circuit satisfiability (or RAM programs, in the case
of STARKs); these are then cryptographically compiled using some form of a polynomial
commitment, typically using Merkle trees or pairing groups.

The linear PCPs underlying GGPR and its successors (i.e., based on QAPs and R1CS)
can also be transformed into Polynomial IOPs.2 This transformation helps highlight the fun-
damental paradigm shift between constructions of non-transparent non-universal SNARKs
that combine linear PCPs and linear-only encodings versus the more recent ones based on
polynomial commitments: given the lack of efficient3 linear function commitment schemes,
the compilation of linear PCPs necessarily involves a trusted preprocessing step that pres-
elects the verifier’s linear PCP queries, and hides them inside a linear-only encoding. This
linear-only encoding forces the prover to homomorphically output an (encoded) linear tran-
formation of the query, upon which the verifer performs several homomorphic checks (e.g.,
using pairings). The shift towards Polynomial IOPs, which can be compiled more directly
with efficient polynomial commitments, avoids the involvement of a trusted party to place
hidden queries in the preprocessing. The only potential need for non-transparent setup is in
the instantiation of polynomial commitment itself.

The precise definition of Polynomial IOPs as a central and standalone notion raises the
question about its exact relation to other IOP notions. We present a univariate Polynomial
IOP for extracting an indicated coefficient of a polynomial. Furthermore, we present a

2This observation was also implicit in the paper by Ben-Sasson et al. introducing the system
Aurora [BCR+19].

3Lai and Malavota [LM19] provide a n-dimensional linear-map commitment based on bilinear pairings,
extending techniques in functional commitments [LRY16], but verifying claimed evaluations of the committed
function on query points takes O(n).

3



univariate Polynomial IOP for proving that the inner product between the coefficient vectors
of two polynomials equals a given value. This proof system is of independent interest.
Together with an offline pre-processing phase during which the correctness of a multivariate
polynomial is ascertained, these two tools enable us to show that any algebraic linear IOP
can be realized with a multivariate Polynomial IOP.

Polynomial IOP compiler We present a generic compilation of any public-coin Poly-
nomial IOP into a doubly-efficient public-coin interactive argument of knowledge using an
abstract polynomial commitment scheme. We prove that if the commitment scheme’s evalu-
ation protocol has witness-extended emulation, then the compiled interactive argument has
this knowledge property as well. If the commitment scheme is hiding and the evaluation is
honest-verifier zero knowledge (HVZK), then the compiled interactive argument is HVZK
as well. Finally, public-coin interactive arguments may be cryptographically compiled into
SNARKs using the Fiat-Shamir heuristic.4

New SNARK without Trusted Setup The main practical outcome of this work is a
new transparent proof system (Supersonic) for computations represented as arbitrary arith-
metic circuits, obtained by cryptographically compiling the Polynomial IOPs underlying
Sonic [MBKM19] and PLONK [GWC19] using the DARK polynomial commitment scheme.
Supersonic improves the proof size by an order of magnitude over STARKs without compro-
mising on verification time. For one million gates, Supersonic’s proofs are just 7.8KB and take
around 75ms to verify. Using the notation OΝ(¡) to hide multiplicative factors dependent on
the security parameter Îť, STARKs have size and verification complexity OÎť(log2 T ) whereas
Supersonic has size and verification complexity OÎť(log T ). (The additional multiplicative
factors dependent on Îť are actually better for Supersonic as well). As a caveat, while the
prover time in Supersonic is asymptotically on par with STARKs (i.e., quasilinear in T ), the
concrete efficiency is much worse due to the use of heavy-weight “crypto operations” over
1200 bit class group elements in contrast to the light-weight FFTs and hash functions in
STARKs. Furthermore, Supersonic is not quantum-secure due to its reliance on groups of
unknown order, whereas STARKs are a candidate quantum-secure SNARK.

1.2 Related Work

Arguments based on hidden order groups Fujisaki and Okamoto [FO97] proposed
homomorphic integer commitment schemes based on the RSA group. They also provide
protocols to prove that a list of committed integers satisfy modular polynomial equations as
opening a commitment bit by bit. Damg̊ard and Fujisaki [DF02] patched the soundness proof
of that protocol and were the first to suggest using class groups of an imaginary quadratic
order as a candidate group of unknown order. Lipmaa drew the link between zero-knowledge
proofs constructed from integer commitment schemes and Diophantine complexity [Lip03],
coining the term Diophantine Arguments of Knowledge. Recently, Couteau et al. study
protocols derived from integer commitments specifically in the RSA group to reduce the
security assumptions needed; in the process they develop proofs for polynomial evaluation
modulo a prime π that is not initially known to the verifier, in addition to a proof showing
that an integer X lies in the range [a, b] by showing that 1 + 4(X − a)(b −X) decomposes
as the sum of 3 squares [CPP17].

Pietrzak [Pie19] developed an efficient proof of repeated squaring, i.e., proving that
x2T = y with O(log T ) proof size and verification time in order to build a conceptually
simple verifiable delay function [BBBF18] based on the RSW time-lock puzzle [RSW96].
Wesolowski [Wes19] improves on this result by proposing a single-round protocol to prove
correct repeated squaring in groups of unknown order with a constant size proof. Boneh et
al. [BBF19] observe that this protocol generalizes to arbitrary exponents (PoE) and develop
a proof of knowledge of an integer exponent (PoKE), as well as a zero-knowledge variant.
They use both PoE and PoKE to construct efficient accumulators and vector commitment
schemes.

4Security for Fiat-Shamir has been proven secure in the random oracle model for constant-round pro-
tocols, for multi-round protocols satisfying soundness against restoration attacks, and in some cases using
correlation-intractable hash functions [FS87, BCS16, KRR17, CCRR18, CCH+19].

4



Transparent polynomial commitments Whaby et al. constructed a transparent poly-
nomial commitment scheme [WTs+18] for multilinear polynomials by combining a ma-
trix commitment of Bootle et al. [BCC+16b] with the inner-product argument of Bünz et
al. [BBB+18]. For polynomials of degree d it has commitments of size O(

√
d) and evaluation

arguments with O(
√
d) communication. The FRI (Fast Reed Solomon IOPP) [BBHR18] and

DEEP-FRI [BSGKS19] protocols are also implicitly a transparent polynomial commitment
scheme that has O(Îť) size commitments and evaluation arguments with O(log2 d) commu-
nication. This connection is described in a recent manuscript by Matter Labs [VP19].

Polynomial IOP formalism In concurrent work Chiesa et al. [CHM+19] introduce an
information theoretic framework called algebraic holographic proofs (AHP). They also show
that with a polynomial commitment scheme an AHP can be compiled to a preprocessing
SNARK. The AHP framework is essentially equivalent to our Polynomial IOP framework.
In other concurrent work, Chiesa, Ojha, and Spooner show interesting connections between
algebraic holographic proofs and recursive proof composition. In the same work, the authors
develop an AHP-based transparent SNARK called Fractal [COS19].

2 Technical Overview

This technical overview provides an informal description of our key technical contribution:
a polynomial commitment scheme with logarithmic evaluation proofs and verification time.
The commitment scheme relies on four separate tools.

1. Integer encoding of polynomials Given a univariate polynomial f(X) ∈ Zp[X] the
prover first encodes the polynomial as an integer. Interpreting the coefficients of f(X) as
integers in5 [0, p), define f̂(X) to be the integer polynomial with these coefficients. The
prover computes f̂(q) ∈ Z for some large integer q ≥ p. This an injective map from
polynomials with bounded coefficients to integers and is also decodable: the coefficients
of f(q) can be recovered from the base-q expansion of f̂(q). For example, suppose that
f(X) = 2X3 + 3X2 + 4X + 1 ∈ Z5[X] and q = 10. Then the integer f(10) = 2341 encodes
the polynomial f(X) because its coefficients appear in the decimal expansion of f̂(10).

Note that this encoding is also additively homomorphic, assuming that q is sufficiently
large. For example, let g(X) = 4X3 +1X2 +3 such that ĝ(10) = 4103. Then f̂(10)+ ĝ(10) =
6444 = (ĝ+ f̂)(10). The more homomorphic operations we want to permit, the larger q needs
to be. The encoding additionally permits multiplication by polynomials (f̂(q) · qk is equal
to the encoding of f(X) ¡Xk).

2. Succint integer commitments The integer x← f̂(q) encoding a degree d polynomial
f(X) lies between qd and qd+1; in other words, its size is (d + 1) log2 q bits. The prover
commits to x using a succinct integer commitment scheme that is additively homomorphic.
Specifically, we use exponentiation in a group G of unknown order: the commitment is the
single group element gx for a base element g ∈ G specified in the setup. (Note that if the
order n of G is known then this is not an integer commitment; gx could be opened to any
integer x′ ≡ x mod n.)

3. Evaluation protocol The evaluation protocol is an interactive argument to convince
a verifier that C is an integer commitment to f̂(q) such that f(z) = y at a provided point
z ∈ Zp. The protocol must be evaluation binding : it should be infeasible for the prover to
succeed in arguing that f(z) = y and f(z) = y′ for y 6= y′. The protocol should also be an
argument of knowledge, which informally means that any prover who succeeds at any point
x must “know” the coefficients of the committed f .

As a warmup, we first describe how a prover can efficiently convince a verifier that C is a
commitment to an integer polynomial of degree at most d with bounded coefficients. Assume
for now that d = 2k − 1. The protocol uses a recursive divide-and-combine strategy. In each
step we split f(X) into two degree d′ = bd

2
c polynomials fL(X) and fR(X). The left half

fL(X) contains the first d′+ 1 coefficients of f(X) and the right half fR(X) the second, such

5The choice to represent the coefficients by integers in [0, p) optimizes for clarity, but later on we will in
fact choose a balanced set of representatives, i.e., [−p−1

2 ; p−1
2 ].

5



that f(X) = fL(X) + Xd′+1fR(X). The prover now commits to fL and fR by computing

CL ← gf̂L(q) and CR ← gf̂R(q). The verifier checks the consistency of these commitments by

testing CLC
qd
′+1

R = C. The verifier then samples random α ∈ Zp and computes C′ ← CαLCR,

which is an integer commitment to αf̂L(q) + f̂R(q). The prover and verifier recurse on the
statement that C′ is a commitment to a polynomial of degree at most d′, thus halving the
“size” of the statement. After log2(d + 1) rounds, the commitment C′ exchanged between
prover and verifier is a commitment to a polynomial of degree 0, i.e., to a scalar c ∈ Zp. So
C′ is of the form gĉ where ĉ is some integer congruent to c modulo p. The prover sends ĉ to
the verifier directly. The verifier checks that gĉ = C′ and also that ĉ < q.6

To also show that f(z) = y at a provided point z, the prover additionally sends yL =
fL(z) mod p and yR = fR(z) mod p in each round. The verifier checks consistency with the
claim, i.e., that yL + zd

′+1yR = y, and also computes y′ ← αyL + yR mod p to proceed to the
next round. (The recursive claim is that C′ commits to f ′ such that f ′(z) = y′ mod p.) In
the final round of recursion, the value of the constant polynomial in z is the constant itself.
So in addition to testing C = gĉ and ĉ < q, the verifier also checks that ĉ ≡ y mod p.

4. Outsourcing exponentiation for efficiency The evaluation protocol requires com-
municating only 2 group elements and 2 field elements per round. However, the verifier needs

to check that CLC
(qd
′+1)

R = C, and näıvely performing the exponentiation requires Ω(d · log q)
work. To reduce this workload, we employ a recent technique for proofs of exponentiation
(PoE) in groups of unknown order due to Wesolowski [Wes19] in which the prover computes
this exponentiation and the verifier verifies it in essentially constant time. This outsourcing
reduces the total verifier time (i.e., of the entire protocol) to a quantity that is logarithmic
in d.

3 Preliminaries

3.1 Assumptions

The cryptographic compilers make extensive use of groups of unknown order, i.e., groups for
which the order cannot be computed efficiently. Concretely, we require groups for which two
specific hardness assumptions hold. First the Strong RSA Assumption [BP97] which roughly
states that it is hard to take arbitrary roots of random elements. Secondly, the much newer
Adaptive Root Assumption [Wes19] which is the dual of the Strong RSA Assumption and
states that it is hard to take random roots of arbitrary group elements. Both of these
assumptions hold in generic groups of unknown order [DK02, BBF19].

Assumption 1 (r-Strong RSA Assumption). The r-Strong RSA Assumption sates that no
efficient adversary can at most compute rth roots a given random group element. Specifically,
it holds for GGen if for any probabilistic polynomial time adversary A:

Pr

u` = g ∧ ` 6= rk, k ∈ N :

G← GGen(λ)

g
$← G

(u, `) ∈ G× N← A(G, g)

 ≤ negl(λ) .

For r = 1, out definition is identical to the standard Strong RSA Assumption. Higher
values of r allows the adversary to take certain roots efficiently. For r = 2, the adversary
is efficiently able to take square roots. In class groups of imaginary quadratic order taking
square roots is easy. In rth order class groups taking rth roots is easy.

Assumption 2 (Adaptive Root Assumption). The Adaptive Root Assumption holds for
GGen if there is no efficient adversary (A0,A1) that succeeds in the following task. First,
A0 outputs an element w ∈ G and some st. Then, a random prime ` in Primes(Ν) is chosen
and A1(`, st) outputs w1/` ∈ G. For all efficient (A0,A1):

Pr

u` = w 6= 1 :

G $← GGen(λ)

(w, st)
$← A0(G)

`
$← Primes(λ)

u← A1(`, st)

 ≤ negl(λ) .

6In the full scheme, the verifier actually checks that ĉ < B for a bound B < q that depends on the field
size p and the polynomial’s maximum degree d

6



We additionally use two more assumptions, however both of them reduce to the Strong
RSA and the Adaptive Root Assumptions.

The first assumption states that computing the order for any element is hard. It reduces
to the Adaptive Root Assumption. Interestingly, it doesn’t necessarily hold for all candidate
groups of unknown order as we explain below. In particular it is important to exclude
elements of known order such as −1 from the candidate unknown order group Zn.

Assumption 3 (Order Assumption). The Order Assumption holds for GGen if for any
efficient adversary A:

Pr

w 6= 1 ∧ wι = 1 :

G $← GGen(λ)

(w, Îą)
$← A(G)

where |ι| < 2poly(Ν) ∈ Z
and w ∈ G

 ≤ negl(λ) .

Lemma 1. The Adaptive Root Assumption implies the Order Assumption.

Proof. We show that given an adversary AOrd that breaks the Order Assumption we can
construct with overwhelming probability AAR that breaks the Adaptive Root Assumption.
We run AOrd to get a w 6= 1 ∈ G and ι ∈ Z such that wι = 1. To construct AAR, AAR,0

outputs (w, Îą). The challenger generates a random challenge `. If gcd(`, Îą) = 1 then AAR,1

can compute β ← `−1 mod α and output u← wβ. By construction u` = w. The probability
that gcd(`, α) = 1 is overwhelming because gcd(`, α) 6= 1 =⇒ ` 6 |α. This happens with
negligible probability as ` is picked from a set of 2Îť primes and at most poly(Îť) distinct
primes can divide Îą.

We also define the Fractional Root Assumption, which states that for random group
elements g it is hard to find a tuple (u ∈ G, ι ∈ Z, β ∈ Z) such that uβ = gι. We say that
(u, ι, β) is a fractional root of g. Shoup[CS99] showed that for the unknown order group of
quadratic residues in Zn, where n is the composite of two strong primes, that the Fractional
Root Assumption reduces to just the Strong RSA Assumption.

Assumption 4 (r-Fractional Root Assumption). The r-Fractional Root Assumption
holds for GGen for any efficient adversary A:

Pr


uβ = gι ∧ β

gcd(ι, β)
6= rk, k ∈ N :

G $← GGen(λ)

g
$← G

(ι, β, u)
$← A(G, g)

where |Îą| < 2poly(Îť),
|β| < 2poly(Ν) ∈ Z,
and u ∈ G


≤ negl(λ) .

We say (ι, β, u) is a non power of r fractional root of g.
The Fractional Root Assumption reduces to the Order Assumption (and therefore to the

Adaptive Root Assumption) and the Strong RSA Assumption.

Lemma 2. The Adaptive Root Assumption and the r-Strong RSA Assumption imply the
r-Fractional Root Assumption

Proof. Given an adversary AFR that succeeds in breaking the Fractional Root Assumption
for GGen we can construct either an adversary ARSA for the Strong RSA Assumption or
an adversary AOrd that breaks the Order Assumption for GGen. As shown in Lemma 7 the
Order Assumption reduces to the Adaptive Root Assumption with overwhelming probability.

We first generate a group of unknown order G $← GGen(λ). Then we sample g
$← G as done

in the strong RSA security definition.
We now run the AFR on input G and g to generate a tuple (ι, β, u) such that uβ = gι.

Let γ = gcd(α, β) and α′ = α
Îł
∈ Z and β′ = β

Îł
∈ Z. Now either gι

′
= uβ

′
or gÎą

′
/uβ

′
is a non

trivial element of order Îł which would directly break the Order Assumption. In that case
we constructed AOrd that outputs (gÎą

′
/uβ

′
, Îł).

Now assume otherwise, i.e. gÎą
′

= uβ
′
. By construction gcd(α′, β′) = 1 and we can

efficiently compute integers a, b such that aα′ + bβ′ = 1. By assumption on AFR β′ is not
rk. Now let w ← uagb. Note that wα

′β′ = gα
′
. So either wβ

′
= g or wβ

′
/g is a non-trivial

element of order α′. The first case breaks the Strong RSA Assumption, as we can construct
ARSA that outputs (w, β), and the second breaks the Order Assumption.

7



Groups of unknown order. We consider two candidate groups of unknown order. Both
have their own upsides and downsides.

RSA Group. In the multiplicative group Z∗n of integers modulo a product n = p · q of
large primes p and q, computing the order of the group is as hard as factoring n. The Order
Assumption does not hold for Z∗n because −1 ∈ Z∗n can be easily computed and has order
two. This can be resolved though by working instead in the quotient group Z∗n/〈−1〉 ∼= QRn.
The downside of using an RSA group, or more precisely, the group of quadratic residues
modulo an RSA modulus, is that this modulus cannot be generated in a publicly verifiable
way without exposing the order, and thus requires a trusted setup.

Class Group. The class group of an imaginary quadratic order is defined as the quotient
group of fractional ideals by principal ideals of an order of a number field Q(

√
∆), with ideal

multiplication. A class group C`(∆) is fully defined by its discriminant ∆, which needs to
satisfy only public constraints such as ∆ ≡ 1 mod 4 and −∆ must be prime. As a result,
∆ can be generated from public coins, thus obviating the need for a trusted setup. A
group element can be represented by two integers strictly smaller (in absolute value) than
−∆, which in turn is on the same order of magnitude as RSA group elements for a similar
security level. We refer the reader to Buchmann and Hamdy’s survey [BH01] and Straka’s
accessible blog post [Str19] for more details.

Working in C`(∆) does present an important difficulty: there is an efficient algorithm due
to Gauss to compute square roots of arbitrary elements [BS96], and by repetition, arbitrary
power of two roots. As a result, such class groups cannot be used to commit to integers but
rather to dyadic rationals, which are rational numbers whose denominator is a power of two.
Additionally, the standard Strong RSA Assumption is broken if computing square roots is
easy. We therefore give a weakened version of Strong RSA which is believed to still hold
even if computing square roots is easy.

3.2 Interactive Arguments of Knowledge

Interactive";"""date"",""2019-10-19T20:01:53Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2019-10-19T20:01:53Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017) kpathsea version 6.2.3""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2019-10-19T20:01:53Z""
""created"",""2019-10-19T20:01:53Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-10-19T20:01:53Z""
""resourceName"",""dark.pdf""
""Author"",""""
""producer"",""pdfTeX-1.40.18""
""pdf:docinfo:producer"",""pdfTeX-1.40.18""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""8"",""26"",""34"",""16"",""5"",""11"",""32"",""19"",""8"",""13"",""38"",""18"",""24"",""5"",""19"",""71"",""28"",""3"",""0"",""12"",""37"",""12"",""34"",""15"",""2"",""2"",""3"",""16"",""1"",""0"",""0"",""0"",""0"",""0"",""13"",""59"",""46"",""26"",""23"",""21"",""21"",""3""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2019-10-19T20:01:53Z""
""Last-Modified"",""2019-10-19T20:01:53Z""
""dcterms:modified"",""2019-10-19T20:01:53Z""
""title"",""""
""Last-Save-Date"",""2019-10-19T20:01:53Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2019-10-19T20:01:53Z""
""meta:save-date"",""2019-10-19T20:01:53Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017) kpathsea version 6.2.3""
""Content-Length"",""708294""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""46""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""3221"",""4317"",""4029"",""3789"",""3544"",""3133"",""2898"",""3271"",""3344"",""2646"",""3174"",""3588"",""3095"",""3427"",""2709"",""3243"",""3048"",""3444"",""2929"",""3243"",""3515"",""3326"",""3096"",""3986"",""3561"",""2665"",""3247"",""3604"",""3382"",""3091"",""2723"",""3569"",""3330"",""3355"",""4064"",""4045"",""3955"",""1174"",""2463"",""3238"",""3643"",""3770"",""3289"",""3676"",""3523"",""1829""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-10-19T20:01:53Z""
";https://scholar.google.ch/scholar?start=910&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098879-367;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Traçabilitat de productes amb Blockchain i IoT;R Torrents Cunill, J Sánchez Laguna ;2020 upcommons.upc.edu;;"… Track&Trace: Producte desenvolupat per la companyia Oracle, la seva principal característica

és que hi han sabut escollir molt be la tecnologia blockchain i que a causa de la seva

experičncia han desenvolupat una tecnologia IoT molt ben estructurada …";;;[PDF] upc.edu;https://upcommons.upc.edu/bitstream/handle/2117/181279/memoria.pdf;"
    
            

        
        
        
        
        
            

                
                
                
                
                


                                  
                    
                        
                            
                                [image: UPC. Universitat Politècnica de Catalunya]
                            

                                                        
                            

                            
                                
                                    Usuari
                                    
                                

                            

                            
                                
                                                                        Contrasenya
                                    
                                

                            


                                                            
                                    
                                        
                                             
                                            
                                                Canvi i oblit de contrasenya                                             
                                        
                                    

                                

                                
                            
                                
                                    Entra
                                

                            


                                                    
                        


                        
                            
                                
                                    
                                                                        
                                

                            

                             

                            Tornar

                        



                        
                        
                        
                        

                        Altres mètodes d'autenticació

                        
                            	
                                        
                                            
                                                [image: sml_x509_authn_label]
                                                sml_x509_authn_label

                                            
                                        

                                    


                             

                        

                                        


                 

                
                     
                        Š UPC 
                        Universitat Politècnica de Catalunya ¡ BarcelonaTech
                    

                    
                        	Contacte
	Accessibilitat
	AvĂ­s legal


                    
                
            

        
        

        
        
        

        
        
        
        
        
        
        
        

        
        
    ";"""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""author"",""Universitat Politècnica de Catalunya""
""description"",""Universitat Politècnica de Catalunya""
""resourceName"",""memoria.pdf""
""language"",""ca""
""title"",""Inicia la sessiĂł""
""X-UA-Compatible"",""IE=edge""
""viewport"",""width=device-width, initial-scale=1.0, user-scalable=no""
""dc:title"",""Inicia la sessiĂł""
""Content-Encoding"",""UTF-8""
""Content-Type-Hint"",""text/html; charset=UTF-8""
""Content-Language"",""ca""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.ch/scholar?start=910&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098866-335;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Classical verification of quantum computations with efficient verifier;NH Chia, KM Chung, T Yamakawa ; Theory of Cryptography Conference, 2020  Springer;;"… Specifically, it only ensures the extractability in the setting where the statement is chosen

before making any query to the random oracle. To deal with this issue … 2.2 Quantum

Random Oracle Model. The quantum random oracle model …";Cité 4 fois;;null;;;;https://scholar.google.ch/scholar?start=880&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098800-182;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;[PDF][PDF] CROOT: Code-based Round-Optimal Oblivious Transfer;N Aragon, O Blazy, N Fournaise… ; Proceedings of the 17th …, 2020  scitepress.org;;"… Av. Albert Thomas, 87060 Limoges Cedex, France Keywords: Oblivious Transfer,

Code-based Crypto, Random-Oracle, Rank Metric. Abstract: In this paper, we present

a new functionality for 1-out-of-2 Oblivious Transfer. This …";Les 2 versions;Version HTML;[PDF] scitepress.org;https://www.scitepress.org/Papers/2020/97767/97767.pdf;"
CROOT: Code-based Round-Optimal Oblivious Transfer∗

Nicolas Aragon, Olivier Blazy, Neals Fournaise and Philippe Gaborit
UniversitĂŠ de Limoges, XLIM-DMI, 123, Av. Albert Thomas, 87060 Limoges Cedex, France

Keywords: Oblivious Transfer, Code-based Crypto, Random-Oracle, Rank Metric.

Abstract: In this paper, we present a new functionality for 1-out-of-2 Oblivious Transfer. This functionality lives be-
tween the classical and the weak-Oblivious Transfer ones. We motivate this functionality to adapt and prove a
formerly proposed (and retracted) framework that was shown to be unprovable with the classical OT function-
ality. Our functionality still remains reasonably close to natural expectation for Oblivious Transfer. Once our
global framework is proven in the new functionality, we propose two instantiations using recent code-based
candidates of the NIST post-quantum standardization process. We show that the resulting instantiations are
both efficient and secure. Our new functionality opens the way to round-optimal oblivious transfer instantia-
tions.

1 INTRODUCTION

The concept of Oblivious Transfer (OT) was intro-
duced by Rabin in 1981 (Rabin, 1981). In the simplest
form of the protocol, the 1-out-of-2 OT, a sender pos-
sesses two messages m0,m1 and a receiver chooses a
bit b. After a successful execution of the protocol, the
receiver obtains message mb while learning nothing
about m1−b and the sender does not know which of
the two messages has been requested. Such a scheme
has been shown to be complete (Kilian, 1988; Ishai
et al., 2008) in the sense that secure Multi-Party Com-
putation (MPC) can be obtained directly from it.

The work of (Canetti et al., 2002) motivated the
use of the Universal-Composability (UC) framework
of (Canetti, 2001) when constructing OT schemes. In-
deed, proving a scheme secure in the UC model guar-
antees that composing it in a larger protocol will pre-
serve security. As OT is regarded as a building block
for MPC and as such is ran under composition, it is
of importance to have it in the UC model. Another
important notion that divides many works in the area
of OT is the adversary corruption model which can
be static or adaptive. In the former model, corrupted
parties are decided at the start of the protocol while
adaptive security is a stronger model in which the ad-
versary can corrupt honest parties at any time during
the protocol. It captures better real-world scenarios
where corruption can happen at anytime e.g. if an
adversary acquires the control of a computer during

∗This work was partially funded by French DGA.

execution of the protocol.
Many OT instantiations have been proposed to

reach greater efficiency in terms of round, computa-
tion or communication costs (Naor and Pinkas, 2001;
Naor and Pinkas, 2005; Halevi and Kalai, 2012; Chou
and Orlandi, 2015). In (Horvitz and Katz, 2007),
the authors achieved the first round-optimal OT while
(Peikert et al., 2008) propose a general framework for
round-optimal UC-secure OT, both are in the static
setting. In the adaptive security model, (Blazy and
Chevalier, 2016; Blazy et al., 2017; Choi et al., 2013;
Garay et al., 2009; Barreto et al., 2017) proposals lack
efficiency and round-optimality.

In a recent work from (Byali et al., 2017), the au-
thors present the first round-optimal adaptively UC-
secure construction of OT relying on the Decisional
Diffie-Hellman (DDH) problem. Their approach is
closely related to that of (Peikert et al., 2008) but it
does not seem to be instantiable using post-quantum
hardness assumption. Our work follows up on this
in the sense that our framework can be instantiated,
as we show, from Rank Metric Codes-based crypto-
graphic schemes which are believed to be quantum-
computer resistant .

1.1 Related Work

Since the original paper (Rabin, 1981), several instan-
tiations of OT protocols have appeared in the litera-
ture, including proposals in the UC framework. Some
instantiations tried to achieve low communication

76
Aragon, N., Blazy, O., Fournaise, N. and Gaborit, P.
CROOT: Code-based Round-Optimal Oblivious Transfer.
DOI: 10.5220/0009776700760085
In Proceedings of the 17th International Joint Conference on e-Business and Telecommunications (ICETE 2020) - SECRYPT, pages 76-85
ISBN: 978-989-758-446-6
Copyright c© 2020 by SCITEPRESS – Science and Technology Publications, Lda. All rights reserved



costs (Peikert et al., 2008), while others like Choi et
al. (Choi et al., 2013; Blazy and Chevalier, 2015) pro-
posed a generic method to achieve Oblivious Trans-
fer with adaptive corruptions. However, among all
the existing articles, only the schemes from (Peikert
et al., 2008) (an ad-hoc construction based on lattices)
and (Blazy and Chevalier, 2015) (a generic construc-
tion relying on (Katz and Vaikuntanathan, 2009)), or
(Blazy et al., 2019) (a variant using (Benhamouda
et al., 2018)) are UC-Secure in a Post-Quantum set-
ting, and they rely on lattice-based cryptography. Un-
fortunately, the first construction only fulfills static se-
curity. The other one offers adaptive security, but re-
lies on standard-model lattice-based SPHF (Smooth
Projective Hash Functions) constructions with costly
decryption procedure (either with repetitions or a su-
per polynomial modulus)

Some code-based Oblivious Transfers exist like
(Kobara et al., 2008; Barreto et al., 2017), however
none of them managed to be proven in the UC setting
up to now.

1.2 Contributions

• First, we revisit a framework for round-optimal
OT already seen in the literature which requires a
certain property on the public keys. Informally,
given a random value T , it should not be pos-
sible to have two public keys of an asymmetric
encryption scheme pk0,pk1 satisfying the relation
T = pk0 ? pk1. To prove this framework adap-
tively UC-secure, we revise the classical ideal
functionality of OT.

• Secondly, we propose multiple instantiations of
this framework using rank metric code-based
encryption scheme (NIST competitors) such as
HQC (Aguilar Melchor et al., 2017a) and RQC
(Aguilar Melchor et al., 2017b) with performance
evaluation.

We thus propose the first construction of adap-
tively UC-secure round-optimal OT using quantum-
resistant hardness assumptions.

1.3 Organizations of the Paper

After recalling basic definitions in Section 2, we pro-
pose our revisited framework in Section 3. We then
propose a new functionality for Oblivious Transfer,
that is closer to real-life protocols, in Section 4 and
prove the security of the framework using it. Fi-
nally in Section 5, we instantiate this framework using
some code-based NIST candidates and show the effi-
ciency of the corresponding implementations in Sec-
tion 6.

2 PRELIMINARIES

2.1 Universal Composability

We are going to prove our protocol in the universal
composability framework. This framework was in-
troduced in (Canetti, 2001).

In the context of multi-party computation, one
wants several users Pi with inputs xi to be able to com-
pute a specific function f (x1, . . . ,xn) = (y1, . . . ,yn)
without learning anything except yi. This approach
was seen for example in Yao’s Millionaires’ prob-
lem (Yao, 1982), where two millionaires want to
know who is richer without revealing their respective
wealth. So here, xi is the wealth of the millionaire i,
and f simply returns which one is richer (in this spe-
cific case y1 = yi = yn).

Instead of following the classical approach which
aims to list exhaustively all the expected properties,
Canetti did something else and tried to define how a
protocol should ideally work.

For that, he divided the world into two spaces,
the real world, where the protocol is run with some
possible attack, and the ideal world where everything
would go smoothly. For a good protocol, it should be
impossible to distinguish the real world from the ideal
one.

In the ideal world there is an incorruptible entity
named the ideal functionality, to which players can
send their inputs privately, and then receive the corre-
sponding output without any kind of communication
between the players. This way the functionality can
be set to be correct, without revealing anything except
what is expected.

A protocol, in the real world with an adversary,
should create an execution similar to the one obtained
by the ideal functionality. This means that the com-
munication between the players should not give more
information than the functionality description, and its
output. In this case the protocol runs not really against
the adversary but against the environment who picks
the inputs given to the players, and obtains the out-
puts. After the interaction the environment should
output a bit saying whether he is in the real world.

The main constraint is that the adversary is now
free to interact with the environment whenever he
wants which prevents the simulator from rewind-
ing when needed. The adversary has access to the
communication between the players but not their in-
puts/outputs, while the environment has only access
to the inputs/outputs.

To prove that a protocol realizes the ideal func-
tionality, we consider an environment Z which can
choose inputs given to all the users and whose goal is

CROOT: Code-based Round-Optimal Oblivious Transfer

77



to distinguish in which case he receives outputs from
the real world execution with an adversary A , and in
which case they come from an ideal execution with an
ideal adversary S who interacts solely with the func-
tionality. Such protocol realizes the functionality if
for all polynomial adversary A , there exists a poly-
nomial simulator S such that no environment Z can
distinguish the real world from the ideal one with a
non-negligible probability.

In the adaptive corruption setting, the adversary
can get complete access to the private credentials and
the internal memory of an honest player, and then get
control of it, at any time.

More precisely, we will work in the UC frame-
work with joint state proposed by Canetti and Ra-
bin (Canetti and Rabin, 2003) (for the CRS). Infor-
mally, this allows different protocols to have some
common states while preserving their security. Ba-
sically for a given session identifier sid we also define
sub-session identifier ssid, and so we have a function-
ality, possibly generated on the fly, for each ssid.

2.2 Random Oracle

Our constructions will rely on the random oracle
model (Bellare and Rogaway, 1993), which can be
modelled in the UC framework as the FRO -hybrid
model. The random oracle functionality is presented
in Figure 1.

2.3 UC-secure Oblivious Transfer

The ideal functionality of an Oblivious Transfer (OT)
protocol is depicted in Figure 2. It is inspired
from (Choi et al., 2013; Abdalla et al., 2013; Byali
et al., 2017).

3 FRAMEWORK

We now introduce a framework to build Oblivious
Transfer protocols in the Random Oracle Model.

3.1 Star Product

To describe our framework, we need to use a Public-
Key Encryption scheme whose keys have the follow-
ing properties:
Definition 1 (Star Product). Let T be a random value,
(pk1,pk2) be two values lying in the public key space
of the considered PKE, and ? be on operation between
two elements of the public key space.

If pk1 ?pk2 = T , we want the following properties
:

• Sender Security. The Receiver must not be able
to know the secret keys associated to both of the
public keys

• Receiver Security. The Sender must not be able to
tell which secret key is know to the receiver

3.2 Framework

In figure 3, we present a framework from the earli-
est version of (Barreto et al., 2017), that we adapt
(in particular we add erasures at the critical steps1)
to achieve Practical Oblivious-Transfer. We present
later a new UC functionality in Figure 4 and show
this framework can achieve it. Erasure means we can
voluntarily remove a data from memory so that it’s
inaccessible in case of a corruption.

4 A NEW MODEL

The classical functionality for Oblivious Transfer has
been achieved in many cases, however it often artifi-
cially complicates the construction.

Inspired by the work of (Byali et al., 2017), we
present an ideal functionality for Oblivious Transfer
protocols in figure 4. Our framework which appears
to be similar as in the earliest version of (Barreto
et al., 2017), as shown in (Li and Micciancio, 2018),
cannot be proven UC-secure according to this func-
tionality due to a ""timing bug"".

In this paper, we propose a new functionality
more adapted to the real world. At a high level,
we propose to split the Receive element into two
parts. An (Emit,sid,ssid,Pi,Pj) which models that
the server is seen sending a message, and a new
(Receive,sid,ssid,Pi,Pj,s) which models the fact the
user receives and interprets the flow.

It should be noted that every protocol proven se-
cure in the classical OT functionality is also secure
in the one presented in Figure 4. In the other direc-
tion, every secure protocol within this functionality is
also a secure weak-Oblivious Transfer (Maurer and
Ribeiro, 2016)2.

1Without them it would not be possible to prove the
framework within our functionality, in particular in case of
the server corruption after its flow.

2This is trivial, as weak Oblivious Transfer do not re-
quire s in the Receive message, hence are encompassed by
Emit.

SECRYPT 2020 - 17th International Conference on Security and Cryptography

78



The Functionality FRO is parametrized by a range D , it keeps an initially empty list L of pairs of values (to
remember the calls):

• Upon receiving an input (sid,ssid,x) from a party Pi, if there is already a pair (x,h) stored in L, it

sets hx = h, otherwise it picks hx
$← D , and stores (x,hx) in L. In both cases, it replies to its activator

with (sid,ssid,hx).

Figure 1: Ideal Functionality for Random Oracle queries FRO.

The functionality F(1,2)-OT is parametrized by a security parameter Îť. It interacts with an adversary S and a
set of parties P1,. . . ,Pn via the following queries:

• Upon receiving an input (Send,sid,ssid,Pi,Pj,(m0,m1)) from party Pi, with mi ∈ {0,1}λ: record
the tuple (sid,ssid,Pi,Pj,(m0,m1)) and reveal (Send,sid,ssid,Pi,Pj) to the adversary S . Ignore further
Send-message with the same ssid from Pi.

• Upon receiving an input (Receive,sid,ssid,Pi,Pj,s) from party Pj, with s ∈ {0,1}: record the tuple
(sid,ssid,Pi,Pj,s), and reveal (Receive,sid,ssid,Pi,Pj) to the adversary S . Ignore further Receive-
message with the same ssid from Pj.

• Upon receiving a message (Sent,sid,ssid,Pi,Pj) from the adversary S : ignore the message if
(sid,ssid,Pi,Pj,(m0,m1)) or (sid,ssid,Pi,Pj,s) is not recorded; otherwise send (Sent,sid,ssid,Pi,Pj)
to Pi and ignore further Sent-message with the same ssid from the adversary.

• Upon receiving a message (Received,sid,ssid,Pi,Pj) from the adversary S : ignore the
message if (sid,ssid,Pi,Pj,(m0,m1)) or (sid,ssid,Pi,Pj,s) is not recorded; otherwise send
(Received,sid,ssid,Pi,Pj,ms) to Pj and ignore further Received-message with the same ssid from
the adversary.

Figure 2: Ideal Functionality for 1-out-of-2 Oblivious Transfer F(1,2)-OT.

4.1 Security Proof in this New
Functionality

Theorem 2. The framework explained in Figure 3
achieves the functionality presented in Figure 4 in the
ROM, under the security of the star product.

To prove this theorem, we exhibit a sequence of
games. The sequence starts from the real game, where
the adversary A interacts with real players and ends
with the ideal game, where we have built a simulator
S that makes the interface between the ideal function-
ality F and the adversary A . We prove the adaptive
version of the protocol. The proof of the static version
can be obtained by removing the parts related to adap-
tive version from the proof below. We denote as Pi the
sender (the server) and Pj the receiver (the user).

Essentially, one first send random values for T ,
and equivocate using the ROM if need be, then, un-
der the IND-CPA property of the Encryption scheme,
one can send dummy values for both ui. Finally at
the time of decryption, one can program the ROM so
that when queried a hash on Kb, one can deduce the
knowledge of skb and so decide that the queried s= b,
and use the ROM to lead to ms. This allows to simu-
late the Send,Emit,Receive-queries respectively to
the ideal functionality.

More details follow:

Game G0: This is the real game.

Game G1: In this game, the simulator generates
correctly every flow from the honest players, as
they would do themselves, knowing the inputs
(m0,m1) and s sent by the environment to the
sender and the receiver. In case of corruption, the
simulator can give the internal data generated on
behalf of the honest players.

Game G2: We first deal with honest senders Pi:
when receiving a commitment t,pk0, the simula-
tor, instead of computing the mask ub, for b = 0,1
with the key Kb, it chooses ub at random.
When queried on H2(Kb,sid), the ROM returns
ub⊕mb. This game is indistinguishable from the
previous one.
In case of corruption, everything has been erased.
This game is thus indistinguishable from the pre-
vious one under the ROM.

Game G3: We now deal with honest receivers Pj:
we replace all the commitments t,pk0 in Step 1
of the index query phase of honest receivers by
honestly generating pk0 and pk1 knowing their
respective secret keys sk0,sk1, and programming
the ROM so that T = pk0 ? pk1. We then store

CROOT: Code-based Round-Optimal Oblivious Transfer

79



Assuming a crs= H1,H2
Index query on b:
Receiver will generate two encryption keys knowing only one secret key skb

• Picks a random seed t, set T = H1(t,sid,ssid)

• For chosen b, run pkb = KeyGen(1k,crs)

• If b = 1, sets pk0 = T ⊕pk1

• Sends (t,pk0), keeps b,skb and erases the rest

Database input (m0,m1):
Sender will encrypt both messages m0,m1 under their respective keys

• Upon receiving (t,pk0)

• Regenerates pk1 = pk0⊕T with t,pk0

• For each b ∈ {0,1}
– Picks a random Kb ∈ {0,1}λ, queries K′b = H2(Kb,sid)

– Compute Cb = Encrypt(pkb,Kb;rb)

– Computes ub = mb⊕K′b
• Sends (u0,u1,C0,C1), erases everything afterwards

Data recovery:
Receiver recovers the wanted line mb

• Upon receiving (u1,u2,C0,C1)

• For the chosen b, computes Kb = Decrypt(skb,Cb)

• Recovers mb = ub⊕H2(Kb,sid)

Figure 3: A simple-OT achieving the Practical-OT Functionality.

(sk0,sk1).
Under the difficulty of distinguishing an honestly
generated T from a crafted one, this game is sim-
ilar to the precedent.
In case of corruptions, one reveals the valid skb
and erases the other one.

Game G4: We now deal with honest receivers Pj,
receiving: we simply recover mb by using the ap-
propriate skb as usual.

Game G5: We can now make use of the functional-
ity, which leads to the following simulator:

• when receiving a Send-message from the ideal
functionality, which means that an honest re-
ceiver has sent a first flow, the simulator gener-
ates secret keys, and programs the ROM so that
T is the star product of the associated public
keys, and sends the corresponding flow;

• after receiving the said flow (from an honest
or a corrupted sender) and a Emitted-message
from the ideal functionality, which means that
an honest receiver has sent an index query, the
simulator sends honest Cb and random ub, and
uses it to send the corresponding Emit-message
to the ideal functionality;

• when receiving (u0,u1,C0,C1) from the adver-
sary (a corrupted sender), the simulator uses
both sk0,sk1 to recover u0,u1. It uses them to
send a Receive-message to the ideal function-
ality.

• when receiving a Received-message from the
ideal functionality, together with ms, on behalf
of a corrupted receiver, from the extracted s, in-
stead of proceeding as the sender would do on
(m0,m1), the simulator proceeds on answering
us⊕ms when queried on H2(Kb,sid);

• when receiving a flow, generated by an honest
sender (by the simulator itself), the simulator
proceeds by answering randomly for every H2
queries

Any corruption before the end does not alter the
simulation, a corruption at the Receive phase re-
veals s, and alters one answer of the random ora-
cle... In all cases, a corruption is undetectable as
all traces of simulations are erased.

Remark.
It should be noted, that this split in the functional-
ity, avoids the trick used in various protocols (Garay

SECRYPT 2020 - 17th International Conference on Security and Cryptography

80



The functionality F(1,2)-Practical-OT is parametrized by a security parameter Îť. It interacts with an adversary S
and a set of parties P1,. . . ,Pn via the following queries:

• Upon receiving an input (Send,sid,ssid,Pi,Pj,(m0,m1)) from party Pi, with mi ∈ {0,1}λ: record
the tuple (sid,ssid,Pi,Pj,(m0,m1)) and reveal (Send,sid,ssid,Pi,Pj) to the adversary S . Ignore further
Send-message with the same ssid from Pi.

• Upon receiving an input (Emit,sid,ssid,Pi,Pj) from party Pj,: record the tuple (sid,ssid,Pi,Pj,wait)
and reveal (Emit,sid,ssid,Pi,Pj) to the adversary S . Ignore further Emit-message with the same ssid
from Pj.

• Upon receiving an input (Receive,sid,ssid,Pi,Pj,s) from party Pj, with s ∈ {0,1}: if
a (sid,ssid,Pi,Pj,wait) existed supersede it with the tuple (sid,ssid,Pi,Pj,s), and reveal
(Receive,sid,ssid,Pi,Pj) to the adversary S . Ignore further Receive-message with the same ssid from
Pj.

• Upon receiving a message (Sent,sid,ssid,Pi,Pj) from the adversary S : ignore the message if
(sid,ssid,Pi,Pj,(m0,m1)) or (sid,ssid,Pi,Pj,s) is not recorded; otherwise send (Sent,sid,ssid,Pi,Pj)
to Pi and ignore further Sent-message with the same ssid from the adversary.

• Upon receiving a message (Emitted,sid,ssid,Pi,Pj) from the adversary S : ignore the
message if (sid,ssid,Pi,Pj,(m0,m1)) or (sid,ssid,Pi,Pj,wait) is not recorded; otherwise send
(Emitted,sid,ssid,Pi,Pj) to Pj and ignore further Emitted-message with the same ssid from the ad-
versary.

• Upon receiving a message (Received,sid,ssid,Pi,Pj) from the adversary S : ignore the
message if (sid,ssid,Pi,Pj,(m0,m1)) or (sid,ssid,Pi,Pj,s) is not recorded; otherwise send
(Received,sid,ssid,Pi,Pj,ms) to Pj and ignore further Received-message with the same ssid from
the adversary.

Figure 4: Ideal Functionality for 1-out-of-2 Oblivious Transfer F(1,2)-Practical-OT.

et al., 2009; Abdalla et al., 2013; Blazy and Cheva-
lier, 2015), where they need an artificial first flow, to
encrypt a hiding mask.

5 INSTANTIATIONS

In this section we propose concrete instantiations of
the framework presented in Section 3 using the code-
based cryptosystems HQC (Aguilar Melchor et al.,
2017a) (Hamming metric) and RQC (Aguilar Mel-
chor et al., 2017b) (rank metric). We start by defin-
ing the star product of Section 3.1 for the chosen
cryptosystems and then discuss the possible band-
width/complexity tradeoffs.

5.1 High-level Details on the Security
When Instantiated with HQC or
RQC

In HQC and RQC, a public key pk consists of two
vectors (h,s) ∈ F2n, such that s = x+hy, where x and
y are of weight w. Thus we can write T as (T1,T2),
where Ti ∈ Fn and pk1 + pk2 = T ⇔ (h1 + h2 =
T1,s1 + s2 = T2).

To prove these instantiations of the framework are
secure, we need to assume that hi cannot be chosen by
the receiver during the Keygen operation. This can be
achieved by setting:

• h1 = H (T )

• h2 = h1 +T1

When receiving the public keys, the sender checks
that the hi were computed legitimately.

To prove the security of our instantiations, we
need to introduce the two following problems:

Problem 1 (Syndrome Decoding). Given a full-rank
matrix H ∈ F(n−k)×n, a syndrome s ∈ Fn−k and a
weight w, it is hard to find a vector x ∈ Fn of weight
lower than w such that Hx> 6 sT .

Problem 2 (Decisional SD Problem). On input
(H,s>) ∈ F(n−k)×n × F(n−k), the Decisional SD
Problem DSD(n,k,w) asks to decide with non-
negligible advantage whether (H,s>) came from the
SD(n,k,w) distribution or the uniform distribution
over F(n−k)×n×F(n−k).

These problems can be specialized for both the
Hamming metric and the rank metric: in the Ham-
ming metric, F=F while in the rank metric, F=Fqm .

CROOT: Code-based Round-Optimal Oblivious Transfer

81



Remark.
The HQC and RQC cryptosystem use a cyclic struc-
ture to reprensent matrices in a more compact way,
hence a matrix H ∈ F(n−k)×n can be represented by
an associated vector h ∈ Fn. We refer the reader to
(Aguilar Melchor et al., 2017a) and (Aguilar Melchor
et al., 2017b) for more details about this.
Proposition 3. Under the assumption that the Syn-
drome Decoding (respectively Rank Syndrome De-
coding) problem [1] is hard, the + operation is a
valid star product for the public keys of the HQC (re-
spectively RQC) cryptosystem.

Proof. Sender Security.
Finding two public keys pk1 and pk2 such that

pk1 + pk2 = T , knowing that h1 = H1(T ) and h2 =
h1 + T1, is equivalent to finding (x1,x2,y1,y2,s1,s2)
such that :

• s1 = x1 +h1y1
• s2 = x2 +h2y2
• s1 + s2 = T2

Where the weight of x1, x2, y1 and y2 is w, with w a
parameter of the cryptosystem.

Solutions to this system are also solutions of the
equation:

T2 = (x1 + x2)+h1y1 +h2y2

Which is an instance of the syndrome decoding prob-
lem 1 where:

• The parity check matrix matrix H is generated by
(1,h1,h2)

• The error vector is ((x1 + x2),y1,y2)

• The syndrome is T2

Hence we can reduce the problem of finding keys that
break the sender security in our instantiation to solv-
ing these particular instances of syndrome decoding.
Let A denote an adversary against these particular in-
stances. We are going to show that A can be used to
solve hard generic instances of syndrome decoding.

In the following, we are going to consider error
vectors of length 3n. The notation (w1,w2,w3) means
that the weight of a vector is w1 if we take the first n
coordinates, w2 if we take the following n, and w3 if
we take the last n.

Hamming Metric.
We want to solve a random syndrome decoding in-
stance (H,s,3w) where H ∈ F n×3n and s ∈ F n.

First, by remarking that random instances of
weight 3w and length 3n have, with good probabil-
ity, a solution of the form (w,w,w), we can reduce the
generic problem to these specific instances.

We then use A to build an adversary A ′ which, on
input (H,s), proceeds as follows:

• Sample a random vector e′ ∈ F 3n of weight
(w,0,0)

• Send (H,s+He′>) to A . Then:
– If A outputs a vector e′′ then output e′′− e′

– Else output /0

A returns error vectors that have their weight bounded
by 4w, which is below the Gilbert-Varshamov bound.
This ensures the uniqueness of the solution, which
means that e′′− e′ is indeed a solution to the instance
(H,s).

Rank Metric.
We want to solve a random rank syndrome decoding
instance (H,s,2w) where H ∈ Fn×2n

qm and s ∈ Fn
qm .

We use A to build an adversary A ′ which, on input
(H,s), proceeds as follows:

• Sample a random vector h2 ∈ Fn
qm

• Build H ′, the concatenation of H and the square
matrix generated by the vector h2. This results in
a n×3n matrix over Fqm .

• Sample a random vector e′ of weight (w,0,w)
• Send (H ′, s+H ′e′>) to A . Then:

– If A outputs a vector e′′ then output the first 2n
coordinates of e′′− e′

– Else output /0

In the rank metric A returns error vectors that have
their weight bounded by 2w, which is again below the
Gilbert-Varshamov bound. This ensures the unique-
ness of the solution, which means that e′′− e′ is in-
deed a solution to the instance (H,s).

From that we deduce that finding (pk1,sk1) and
(pk2,sk2) such that pk1 +pk2 = T reduces to finding
a solution to an instance of the syndrome decoding
problem.

Receiver Security.
To distinguish between a legitimately generated pub-
lic key and some (h,s) randomly sampled, the sender
would have to solve an instance of the decisional ver-
sion of the syndrome decoding problem, which is eas-
ily reduced to the search version.

SECRYPT 2020 - 17th International Conference on Security and Cryptography

82



Table 1: Bandwidth (in bytes) used by our instantiations of the OT framework.

Parameter Security level Receiver bandwidth Sender bandwidth
hqc-128-1 128 6274 12724
hqc-192-1 192 11022 22218
hqc-256-1 256 16002 32176
RQC-III 128 2388 9360

Table 2: Timings (in millions of cycles) of our instantiations of the OT framework.

Parameter Receiver (step 1) Sender Receiver (step 2)
hqc-128-1 0.20 0.67 0.45
hqc-192-1 0.35 1.18 0.76
hqc-256-1 0.53 1.85 1.20
RQC-III 0.52 1.51 3.24

1: Input: The 512-bit message to encrypt m, the se-
cret key sk

2: Output: A ciphertext C of m
3: (C1,shared_secret)⇐ Encaps(sk)
4: m′⇐ m⊕ shared_secret
5: return C =C1||m′

Figure 5: KEM to PKE conversion used in our implemen-
tation.

6 IMPLEMENTATION

6.1 Implementation Details

Since the HQC and RQC schemes are implemented
as KEM schemes instead of PKE schemes, we use the
conversion 5 to encrypt 512-bit messages. To decrypt,
we simply use the left part of C to recover the shared
secret and XOR it with the right part of C to recover
m.

6.2 Bandwidth and Performances

6.2.1 Bandwidth

Our implementation uses:

• 40 bytes to represent t and 64 bytes to represent
sid, hence a 104 bytes overhead over transmitting
the public key

• 128 bytes to represent (u1,u2) and 128 bytes of
overhead coming from the KEM to PKE conver-
sion, hence a 256 bytes overhead over transmit-
ting two ciphertexts

Using that we can compute the bandwidth used by
our instantiations for security levels 128, 192 and 256.
The results are described table 1. For RQC, we chose

to use the parameter RQC-III as a 128 bits of secu-
rity parameter to take into account the recent improv-
ments on algebraic attacks from (Bardet et al., 2019).

6.2.2 Performances

The most costly operations in the OT framework are
by far the KeyGen, Encrypt and Decrypt operations,
hence the performance of the Oblivious Transfer is re-
ally close to the performances of the HQC and RQC
schemes. The timings are shown table 2 and are given
in million of CPU cycles. The computations were per-
formed using an Intel® Core™ i5-7440HQ.

7 CONCLUSION

We revised the classical ideal functionality of Oblivi-
ous Transfer commonly used. Doing so, we were able
to prove a round-optimal and efficient framework to
be adaptively UC-secure.

We also provided concrete performance evalua-
tion of an implementation of this generic construction
using NIST competitors in the Post-Quantum Cryp-
tography Standardization Process. This shows those
quantum-resistant instantiations are both practical in
communication size but also in computation time.

Our new functionality opens the way to UC se-
cure Round-Optimal Oblivious Transfer with adap-
tive corruptions in a Post-Quantum setting assuming
reliable erasures. An open question, would then natu-
rally be, can we reduce the reliance on the random or-
acle model without conceding anything to efficiency.

CROOT: Code-based Round-Optimal Oblivious Transfer

83



ACKNOWLEDGMENTS

This work was supported in part by the French ANR
projects IDFIX (ANR-16-CE39-0004) and CBCrypt
(ANR-17-CE39-0007).

REFERENCES

Abdalla, M., Benhamouda, F., Blazy, O., Chevalier, C.,
and Pointcheval, D. (2013). SPHF-friendly non-
interactive commitments. In Sako, K. and Sarkar,
P., editors, ASIACRYPT 2013, Part I, volume 8269 of
LNCS, pages 214–234. Springer, Heidelberg.

Aguilar Melchor, C., Aragon, N., Bettaieb, S., Bidoux,
L., Blazy, O., Deneuville, J.-C., Gaborit, P., Per-
sichetti, E., and ZĂŠmor, G. (2017a). HQC. Techni-
cal report, National Institute of Standards and Tech-
nology. available at https://csrc.nist.gov/projects/
post-quantum-cryptography/round-1-submissions.

Aguilar Melchor, C., Aragon, N., Bettaieb, S., Bidoux,
L., Blazy, O., Deneuville, J.-C., Gaborit, P.,
and ZĂŠmor, G. (2017b). RQC. Technical re-
port, National Institute of Standards and Tech-
nology. available at https://csrc.nist.gov/projects/
post-quantum-cryptography/round-1-submissions.

Bardet, M., Briaud, P., Bros, M., Gaborit, P., Neiger, V.,
Ruatta, O., and Tillich, J.-P. (2019). An algebraic at-
tack on rank metric code-based cryptosystems. arXiv
preprint cs/1910.00810.

Barreto, P. S. L. M., David, B., Dowsley, R., Morozov, K.,
and Nascimento, A. C. A. (2017). A framework for ef-
ficient adaptively secure composable oblivious trans-
fer in the ROM. Cryptology ePrint Archive, Report
2017/993. http://eprint.iacr.org/2017/993.

Bellare, M. and Rogaway, P. (1993). Random oracles are
practical: A paradigm for designing efficient proto-
cols. In Denning, D. E., Pyle, R., Ganesan, R.,
Sandhu, R. S., and Ashby, V., editors, ACM CCS 93,
pages 62–73.";"""date"",""2020-07-31T04:59:26Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2020-07-31T04:59:26Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is MiKTeX-pdfTeX 2.9.6870 (1.40.19)""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2020-07-31T04:59:26Z""
""created"",""2020-07-31T04:59:26Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-07-31T04:59:26Z""
""resourceName"",""97767.pdf""
""Author"",""""
""producer"",""pdfTeX-1.40.19""
""pdf:docinfo:producer"",""pdfTeX-1.40.19""
""pdf:unmappedUnicodeCharsPerPage"",""1"",""1"",""2"",""1"",""2"",""4"",""27"",""2"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2020-07-31T04:59:26Z""
""Last-Modified"",""2020-07-31T04:59:26Z""
""dcterms:modified"",""2020-07-31T04:59:26Z""
""title"",""""
""Last-Save-Date"",""2020-07-31T04:59:26Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2020-07-31T04:59:26Z""
""meta:save-date"",""2020-07-31T04:59:26Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is MiKTeX-pdfTeX 2.9.6870 (1.40.19)""
""Content-Length"",""409030""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""10""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""3696"",""4056"",""3378"",""3363"",""2406"",""3106"",""3014"",""2445"",""4621"",""980""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-07-31T04:59:26Z""
";https://scholar.google.ch/scholar?start=730&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098897-401;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;I2C ?????? ???? ??? ?? ??? ?? ?? ??? ?? ????;???? ???? ??? ; ????????, 2020  dbpia.co.kr;;"… 57, Issue 2, pp. 206- 213, 2011. [ 5 ] John Adler, Ryan Berryhill, Andreas Veneris, Zissis Poulos,

Neil Veira, & Anastasia Kastania, ""Astraea: A Decentralized Blockchain Oracle,"" 2018 IEEE

International Conference on Internet of Things (iThings), pp. 1145-1152, 2018 …";Autres articles;;null;;;;https://scholar.google.ch/scholar?start=950&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098853-307;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;[PDF][PDF] Cryptopoly: Using Ethereum State Channels for Decentralized Game Applications;M Xu ;2020 monopoly.now.sh;;"… results of the smart contract, which makes the generation of random numbers usually

a task relegated to Oracle services (?Verifiable Randomness for Blockchain Smart

Contracts?) or through a different scheme. Since the core …";Autres articles;Version HTML;[PDF] now.sh;https://monopoly.now.sh/Cryptopoly.pdf;"Redirecting (308)

https://monopoly.vercel.app/Cryptopoly.pdf
";"""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""Content-Encoding"",""ISO-8859-1""
""resourceName"",""Cryptopoly.pdf""
""language"",""en""
""Content-Type"",""text/html; charset=ISO-8859-1""
";https://scholar.google.ch/scholar?start=850&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098844-283;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Prospero's Books: A Distributed Architecture for AI: Invited Extended Abstract;B Mishra ; Distributed Computing and Internet Technology: 16th …, 2020  Springer;;"… The signaling, in order to remain honest (eg, separating), may involve crypto-tokens and … and

stable pooling (non-separating) Nash Equilibrium when introduced into a society of human Oracles …

exactly the same manner independent of whether the sender is an Oracle or Imitator …";Autres articles;;null;;;;https://scholar.google.ch/scholar?start=830&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098729-21;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;International Journal On Consumer Law And Practice;AR Patil ;2020 opac.nls.ac.in;;"… According to the FSB these activities can be organized into five categories of financial services:

(a) payments, clearing, and settlement (eg Alipay, PayPal, blockchain and crypto currencies,

infrastructure for derivatives and securi- ties trading and settlement); b) deposits, lending …";Autres articles;Version HTML;[PDF] nls.ac.in;http://opac.nls.ac.in:8081/xmlui/bitstream/handle/123456789/121/IJCLP-Vol.%208-%202020.pdf?sequence=1;;;https://scholar.google.ch/scholar?start=570&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098884-375;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Limits to non-malleability;M Ball, D Dachman;Soled, M Kulkarni…  11th Innovations in …, 2020  drops.dagstuhl.de;;"… In more detail, a reduction R, is an algorithm that receives as input an algorithm A that solves

Problem 1 and uses it to solve Problem 2. Typically, R will only access A in an input/output manner

as a subroutine (also known as oracle access and denoted as RA) …";Cité 3 fois;Les 6 versions;[PDF] dagstuhl.de;https://drops.dagstuhl.de/opus/volltexte/2020/11765/pdf/LIPIcs-ITCS-2020-80.pdf;"
Limits to Non-Malleability
Marshall Ball
Columbia University, New York City, NY, USA
marshall@cs.columbia.edu

Dana Dachman-Soled
University of Maryland, College Park, MD, USA
danadach@umd.edu

Mukul Kulkarni1

University of Massachusetts Amherst, MA, USA
mukul@cs.umass.edu

Tal Malkin
Columbia University, New York City, NY, USA
tal@cs.columbia.edu

Abstract
There have been many successes in constructing explicit non-malleable codes for various classes of
tampering functions in recent years, and strong existential results are also known. In this work we
ask the following question:

When can we rule out the existence of a non-malleable code for a tampering class F?

First, we start with some classes where positive results are well-known, and show that when
these classes are extended in a natural way, non-malleable codes are no longer possible. Specifically,
we show that no non-malleable codes exist for any of the following tampering classes:

Functions that change d/2 symbols, where d is the distance of the code;
Functions where each input symbol affects only a single output symbol;
Functions where each of the n output bits is a function of n− logn input bits.

Furthermore, we rule out constructions of non-malleable codes for certain classes F via reductions
to the assumption that a distributional problem is hard for F , that make black-box use of the
tampering functions in the proof. In particular, this yields concrete obstacles for the construction of
efficient codes for NC, even assuming average-case variants of P 6⊆ NC.

2012 ACM Subject Classification Security and privacy→ Information-theoretic techniques; Security
and privacy → Mathematical foundations of cryptography; Security and privacy → Cryptography

Keywords and phrases non-malleable codes, black-box impossibility, tamper-resilient cryptogtaphy,
average-case hardness

Digital Object Identifier 10.4230/LIPIcs.ITCS.2020.80

Related Version Full version of this paper is available at https://eprint.iacr.org/2019/449.

Funding The views and conclusions contained herein are those of the authors and should not be
interpreted as necessarily representing the official policies, either express or implied, of ODNI,
IARPA, or the U.S. Government. The U.S. Government is authorized to reproduce and distribute
reprints for governmental purposes notwithstanding any copyright annotation therein.
Marshall Ball: M. Ball is supported by an IBM Research PhD Fellowship. This research is based upon
work supported in part by the Office of the Director of National Intelligence (ODNI), Intelligence
Advanced Research Projects Activity (IARPA) via Contract No. 2019-1902070006.
Dana Dachman-Soled: This work is supported in part by NSF grants #CNS-1933033, #CNS-1840893,

1 Part of this work was done when the author was studying at University of Maryland, USA

Š Marshall Ball, Dana Dachman-Soled, Mukul Kulkarni, and Tal Malkin;
licensed under Creative Commons License CC-BY

11th Innovations in Theoretical Computer Science Conference (ITCS 2020).
Editor: Thomas Vidick; Article No. 80; pp. 80:1–80:32

Leibniz International Proceedings in Informatics
Schloss Dagstuhl – Leibniz-Zentrum für Informatik, Dagstuhl Publishing, Germany

mailto:marshall@cs.columbia.edu
mailto:danadach@umd.edu
mailto:mukul@cs.umass.edu
mailto:tal@cs.columbia.edu
https://doi.org/10.4230/LIPIcs.ITCS.2020.80
https://eprint.iacr.org/2019/449
https://creativecommons.org/licenses/by/3.0/
https://www.dagstuhl.de/lipics/
https://www.dagstuhl.de


80:2 Limits to Non-Malleability

#CNS-1453045 (CAREER), by a research partnership award from Cisco and by financial assistance
award 70NANB15H328 from the U.S. Department of Commerce, National Institute of Standards
and Technology.
Tal Malkin: This research is based upon work supported in part by the Office of the Director
of National Intelligence (ODNI), Intelligence Advanced Research Projects Activity (IARPA) via
Contract No. 2019-1902070006.

1 Introduction

Since the introduction of non-malleable codes (NMC) by Dziembowski, Pietrzak, and Wichs
in 2010, there has been a long line of work constructing non-malleable codes for various
classes [43]. A plethora of upper bounds, explicit and implicit (to varying degrees), have been
shown for a wealth of classes of tampering functions. However, to our knowledge, relatively
little is known about when non-malleability is impossible. In this work, we initiate the study
of the limits to non-malleability.

Non-malleability for a class F is defined via the following “tampering” experiment:
Let f ∈ F denote a tampering function.

1. Encode message m using a (public) randomized encoding algorithm: c← E(m),
2. Tamper the codeword: c̃ = f(c),
3. Decode the tampered codeword (with public decoder): m̃ = D(c̃).

Roughly, the encoding scheme, (E,D), is non-malleable for a class F , if for any f ∈ F the
result of the above experiment, m̃, is either identical to the original message, or completely
unrelated. More precisely, the outcome of a F -tampering experiment should be simulatable
without knowledge of the message m (using a special flag “same” to capture the case of
unchanged message).

[43] showed that, remarkably, this definition is achievable for any F such that loglog|F| <
n − 2 · log(1/ε), where n is the length of the codeword (the input/output of functions in
F), and Îľ parameterizes the quality of simulation possible (see Definition 3). However the
definition is not achievable in general. It is easy to observe that if F is the class of all
functions, there is a trivial tampering attack: decode, maul, and re-encode. This same
observation rules out the possibility of efficient codes against efficient tampering, as this
attack only requires that decoding and outputting constants conditioned on the result is in
the tampering class. By a similar argument, the decoding function of a non-malleable code
with respect to the distribution formed by encoding a random one-bit message can be seen
as existence of hard decision problem for the tampering class. (This, in turn, informs us of
where to hope for unconditional constructions.)

In this work, we give a variety of impossibility results for non-malleable codes, in disparate
tampering regimes. We present 3 unconditional impossibility results for various classes, which
hold even for inefficient NMC. These impossibility results apply to classes that are simple and
natural extensions of classes with well-known and efficient NMC constructions. Additionally,
we rule out constructions of NMC for a wide range of complexity classes with security
reductions that are only given black-box access to the tampering function. This result is
more technically complex than the previous ones, and requires the introduction of a new
notion of fine-grained black-box reductions appropriate for the non-malleability setting, as
we explain below. This result allows us to study the minimal assumptions necessary for
achieving NMC for complexity classes contained in P (e.g., NC1), and to rule out such NMC
constructions (with black-box reductions) from minimal average-case hardness assumptions.



M. Ball, D. Dachman-Soled, M. Kulkarni, and T. Malkin 80:3

To our knowledge, the only previously-known impossibility results beyond the simple
observations above, are related to other variants of NMC. These include bounds on locality
of locally decodable and updatable NMC, bounds on continuous NMC, and impossibility of
“look-ahead” or “block-wise” NMC (which also follows from a simple observation). There are
also several bounds related to the rate of NMC. We discuss these and other related works in
Section 1.4. In contrast, our results hold regardless of rate. In fact, our lower bounds rule
out even message spaces of size two or three.

1.1 Strictly Impossible
We identify 3 tampering regimes where non-malleability is strictly impossible.

On tampering functions that change d/2 symbols, where d is the distance of the
code

It is common to present non-malleable codes as a strict relaxation of error-correcting codes
(ECC). It is easy to see that ECC are NMC against tampering that changes up to the allowed
fraction of symbols, but since NMC only require correctness of decoding in the absence of
errors, they can provide “security” for tampering functions that ECC cannot, in particular
functions that can modify most, or even all, symbols of the codeword. This suggests that we
could potentially construct NMC for tampering classes that are strictly larger than any class
for which ECC could exist. However, no such construction is known: all NMC results that
allow to modify more symbols, also require that the computation of the tampering function
is restricted in some way. In contrast, ECC do not place any restrictions on the tampering
adversary beyond the limit to the number of modified symbols.

In the current work we ask whether this trade-off is in fact necessary. Specifically, can we
construct NMC that allow for modifying more symbols of the codeword than ECC without
placing any other restrictions on the tampering? Note that for ECC it is known that if
the distance of the code is d, it is not possible to correct when d/2 symbols are modified,
but there are constructions that allow for error correction after arbitrary modification of at
most d/2− 1 symbols (e.g., Reed-Solomon ECC achieve this bound). Indeed, for the case
of potentially inefficient coding schemes, the above is tight: A coding scheme with distance
d implies error correction against d/2 − 1 errors. Thus, fixing a message space M and a
codeword space C, we consider the optimal ECC for this message and codeword space, which
has some distance d (and therefore can correct d/2− 1 errors). We then ask whether one
can construct a non-malleable code with message spaceM and codeword space C against
the class of functions that may arbitrarily tamper with d/2 codeword symbols.

We fully resolve our question. We show that for message space of size 2, non-malleable
codes that tolerate arbitrary modification of even up to d − 1 symbols are possible (via a
repetition code, see Section 3). On the other hand, for message space of size greater than 2,
it is impossible to construct non-malleable codes with distance d for tampering functions
that arbitrarily modify d/2 codeword symbols. This indicates that for message space larger
than 2, in order to obtain improved parameters beyond what is possible with error correcting
codes, imposing some additional restrictions on the tampering function is necessary.

On tampering functions where each input symbol affects at most one output
symbol

In their recent work, Ball et al. [17] presented unconditional NMC for the class of output-local
functions, where each output symbol depends on a bounded number of input symbols. As an
intermediate step, they also considered the class of functions that are both input and output

ITCS 2020



80:4 Limits to Non-Malleability

local. The class of input-local functions is the class of functions where each input symbol
affects a bounded number of output symbol. A natural question is whether non-malleable
codes can be constructed for the class of input-local functions, where for codeword length n,
each input bit affects ďż˝ n output bits.

In this work, we answer this question negatively in a very strong sense. We show that
even achieving NMC for 1-input local functions (where each input bit affects at most one
output bit) is impossible. In fact, our proof shows an even stronger result: the impossibility
holds even if each input symbol can only affect the same single output symbol. That is,
it is impossible to construct NMC for the tampering class that allows to change only one
codeword symbol in a way that depends on the input (while the other symbols may be
changed into constant values). Stated like this, this result can also be viewed as an extension
of our first result above on the maximum number of symbols that can be modified in a
non-malleable code.

On tampering functions where each output symbol depends on n− log(1/(4ε))
input symbols

Here we move on to consider achieving NMC for output-local tampering functions. The prior
work of [17] constructed efficient NMC for tampering functions with locality nc, for constant
c < 1. The size of the class of all output-local tampering functions (with locality sufficiently
smaller than n) is also bounded in size and therefore NMC for this class follow from the
existential results of [43]. A natural question is how large can the output-locality be?

We prove the impossibility of Îľ-non-malleable codes (see Definition 3) for the class of
(n − log(1/(4ε)))-output-local tampering functions. In addition to the above motivation,
parity over n bits is average-case hard for this class.1 Therefore, our impossibility result can
be viewed as a “separation” between average-case hardness and non-malleability, as it exhibits
a class for which we have average-case hardness bounds, but cannot construct non-malleable
codes for. Furthermore, the class F ′ constructed in our lower bound proof has size only
4n · 22n−log(1/(4ε)) , which in turn means that log log |F ′| = n− log(1/(4ε)) = n− log(1/ε) + 2.
On the other hand, the aforementioned result of Dziembowski et al. [43] shows existence of
an ε-non-malleable code for any class F such that log log |F| ≤ n − 2 log(1/ε). Thus, our
lower bound result is close to matching the existential upper bound.

Remark: deterministic vs. randomized decoding

The standard (and original) definition of NMC requires deterministic decoding and perfect
correctness, although some later work took advantage of randomized decoding.2 We note
that our lower bound for the class of input-local functions holds for standard schemes (with
deterministic decoding and perfect correctness). Our lower bound (with Îľ = 1

4n ) for the class
of n − log(n) output-local functions holds even for coding schemes that have randomized
decoding and perfect correctness. The lower bound for the class of functions that change d/2
symbols holds even for coding schemes with randomized decoding and imperfect correctness.

1 Note that, even arbitrary decision trees of depth n− 1 have no advantage in computing the parity of n
bits with respect to the uniform distribution. [22]

2 For the class of output-local functions (where each output depends on at most ` inputs) we have explicit
constructions with randomized decoding (and Îľ = negl(n)) for ` < n/ logn [17], whereasconstructions
with deterministic decoding are known for locality up to n1/2−ε for small ε. [28, 15].



M. Ball, D. Dachman-Soled, M. Kulkarni, and T. Malkin 80:5

1.2 Impossibility of Black-Box Security Reductions
In recent work, unconditional constructions of non-malleable codes for progressively larger
tampering classes, such as NC0 [17, 29, 15] and AC0 [29, 15], have been presented. In fact,
the construction of [15] remains secure for circuit depths as large as Θ(log(n)/ log log(n)).
Moreover, due to the impossibility of efficient NMC for all of P, extending their result
to obtain unconditional NMC for circuits with asymptotically larger depth would require
separating P from NC1, a problem that is well out of reach with current complexity-theoretic
techniques. However, rather than ruling out such constructions entirely, in this regime we
ask what are the minimal assumptions necessary for achieving non-malleable codes for NC1,
as well as other classes F that are believed to be strictly contained in P.

The above question was partially addressed by Ball et al. [18, 16] in their recent work,
where they presented a general framework for construction of NMC for various classes F in
the CRS model and under cryptographic assumptions. Instantiating their framework for NC1

yields a computational, CRS-model construction of 1-bit NMC for NC1, assuming there is a
distributional problem that is hard for NC1, but easy for P. Moreover, such distributional
problems for NC1 can be based on worst-case assumptions.3

In this work, we ask whether 1-bit non-malleable codes for NC1 in the standard (no-CRS)
model can be constructed from the assumption that there are distributional problems that
are hard for NC1 but easy for P. Recall that this assumption is minimal, since the decoding
function of a 1-bit non-malleable code for NC1 w.r.t. the distribution of random encodings of
1 bit messages yields such a distributional problem.

We provide a negative answer, showing that, under black-box reductions (restricting use
of the tampering function in the security proof to be black-box), this is impossible.

Specifically, we define a notion of black-box reductions for the setting of 1-bit non-
malleable codes (E,D) against a complexity class F to a distributional problem (Ψ, L) that
is hard for F . This type of reduction is required to use the “adversary” – i.e. the tampering
function in our setting – in a black-box manner, but is not restricted in its use of the
underlying assumptions. To motivate our new notion, we begin by recalling the notions of
reductions in complexity theory and cryptography, and how they are used.

Reductions in Complexity Theory

A reduction is a technique in complexity theory that is used to show that Problem 1 is as
hard as Problem 2. For example, the famous Cook-Levin theorem showed that SAT (Boolean
satisfiability) is as hard as any problem in NP, by showing a reduction from any problem in
NP to SAT. In more detail, a reduction R, is an algorithm that receives as input an algorithm
A that solves Problem 1 and uses it to solve Problem 2. Typically, R will only access A
in an input/output manner as a subroutine (also known as oracle access and denoted as
RA). When a reduction R uses a solver A in this way, R is known as a black-box reduction.
Intuitively, in this case, R does not care how A solves Problem 1, it just cares that A exhibits
the correct input-output behavior. Therefore, the reduction R should still be able to solve
Problem 2, even when A is computationally unbounded. In fact, in the Cook-Levin theorem,
only a single oracle query is made by the reduction to the algorithm solving SAT.

When is a reduction R between two problems useful? Note that if R is in a complexity
class that can solve Problem 2, then existence of such a reduction R is tautological, since R
can simply ignore its oracle and solve Problem 2 on its own (so no relationship is demonstrated

3 Assuming ⊕L/poly 6⊆ NC1 yields a distributional problem since randomized encodings for ⊕L/poly are
known to exist [13, 21, 41, 14].

ITCS 2020



80:6 Limits to Non-Malleability

about the relative hardness of the problems). This is why in the Cook-Levin theorem the
reduction is required to be polynomial time. Reductions are also useful since they allow us to
draw conclusions about the relationships between different complexity classes. For example,
using the Cook-Levin theorem, we conclude that if there exists a polynomial time algorithm
for solving SAT then there exists a polynomial time algorithm for all of NP (i.e. P = NP).
Note that there is actually a subtlety here: In order for the above to hold, we need that
whenever A is polynomial time, RA is also polynomial time. This holds trivially for the case of
polynomial time, since the class P is closed under composition. However, as we will see later,
this closure does not necessarily hold in some of the settings we consider. Many variations on
reductions beyond the setting of the Cook-Levin Theorem and NP-completeness have been
considered in complexity theory. For example, polynomial time reductions have no utility
when P is the object of study. Instead, the theory of P-completeness uses NC-computable
reductions to argue about whether or not problems in P can be parallelized. Another such
example is the theory of fine-grained complexity, which seeks to understand the exact (or,
more exact) complexity of problems in P. Fine-grained reductions allow one to argue that
a problem cannot be solved in, for example, O(n2−ε) time (for any ε > 0), by reduction
from another problem believed to require Ω(n2−o(1)) time. For this reasoning to hold, such a
fine-grained reduction must run in sub-quadratic time, and moreover it can make at most
no(1) queries to an oracle defined on instances of length n if it is to remain useful. As we will
see, this tension between the length of the inputs queried to the oracle and the number of
such queries will also be relevant in our setting.

Reductions in Cryptography

Reductions in cryptography are exactly like reductions in complexity theory. For example, the
seminal result of [54] proves by reduction that breaking a pseudorandom function (Problem 1)
is as hard as breaking a pseudorandom generator (Problem 2). In order to prove this, they
present a reduction R such that that given an algorithm A that breaks the constructed
pseudorandom function, RA breaks the underlying pseudorandom generator. Note that since
R only has oracle access to A, again R does not care how A works, as long as it exhibits
input-output behavior that qualifies it as a valid distinguisher between a pseudorandom and
random function. Thus, R is black-box. As before, R is only useful if it is polynomial time,
since otherwise R can break the pseudorandom generator on its own. Furthermore, we again
want to use the existence of the reduction to draw conclusions about the security relationship
between the pseudorandom function and the pseudorandom generator. Here we want to show
that if there exists a polynomial-time algorithm that breaks the pseudorandom function, then
there exists a polynomial-time algorithm that breaks the pseudorandom generator. Therefore,
we want it to be the case that whenever A is polynomial time, RA is also polynomial time.
This trivially holds, as before, since P is closed under composition. However, in the following
we will consider cases where this type of closure does not necessarily hold. For example,
when A and R are in NC1, RA may no longer be in NC1 (in fact RA could have depth up to
log2(n)). We therefore need to include a notion of closure under composition as one of the
requirements of a black-box reduction in our setting.

A fine-grained setting: Security reductions for non-malleable codes

What would a security reduction in the setting of non-malleable codes look like? In this case,
we want to show that breaking the non-malleable code (Problem 1) is as hard as breaking
distributional problem (Ψ, L) (Problem 2). Here, an algorithm that breaks the non-malleable



M. Ball, D. Dachman-Soled, M. Kulkarni, and T. Malkin 80:7

code simply consists of a tampering function f . A reduction R is provided black-box access
to the tampering function f and must use it to break the distributional problem (Ψ, L).
First, note that since we assume R is black-box, R is only allowed to use f as a subroutine
(gives it inputs and obtains its output), regardless of how f performs its computation. Thus,
as in all the cases discussed above, we require that Rf break the distributional problem
(Ψ, L), even in the case that f is not contained in F . Note that the distributional problem
(Ψ, L) is easy for polynomial-time. Therefore, for the reduction to be non-trivial, R must be
in a complexity class that does not contain P. Indeed, since we only assume that (Ψ, L) is
hard for F , R must be contained in F in order for us to draw any conclusions (otherwise, we
cannot rule out the possibility that R simply ignores its oracle and solves (Ψ, L) on its own).
Furthermore, as discussed above, the point of the reduction is to be able to conclude that if
there is a tampering function f in F that breaks the non-malleable code, then there exists
an algorithm in F that breaks the distributional problem (Ψ, L). Therefore, it is not enough
that R ∈ F , and we actually need that whenever f ∈ F , Rf ∈ F . We will then use the fact
that Rf breaks (Ψ, L) and is used to obtain a contradiction to the hardness of (Ψ, L) for F .

Overall, at a high level (skipping some technical details), we require two properties of a
black-box reduction R from (E,D) to (Ψ, L):

If the tampering function f succeeds in breaking the non-malleable code, the reduction,
Rf , should succeed, regardless of whether f ∈ F . This represents the fact that R uses f
in a black-box manner.
For any f ∈ F , Rf must also be in F , and in particular, R itself must be in F .
This represents the fact that the black-box reduction R should allow one to obtain a
contradiction to the assumption that (Ψ, L) is hard for F , in the case that (E,D) is
malleable by F .

Note that for arbitrary classes F (unlike the usual polynomial-time adversaries typically used
in cryptography), the fact that R ∈ F and f ∈ F does not necessarily imply that Rf ∈ F .
This introduces some additional complexity in our definitions and also requires us to restrict
our end results to classes F that behave appropriately under composition.

We present general impossibility results for constructing 1-bit non-malleable codes for a
class F from a distributional problem that is hard for F but easy for P. We present three
types of results: results ruling out security parameter preserving reductions for tampering
class F that behave nicely under composition; results ruling out “approximate” security
parameter preserving reductions for tampering class F with slightly stronger compositional
properties; and results ruling out non-security parameter preserving reductions for tampering
class F that are fully closed under composition. See Definitions 21, 22 and Lemmas 31, 35, 37
for the formal statements.

Briefly, security parameter preserving reductions have the property that the reduction only
queries the adversary (in our case the tampering function) on the same security parameter
that it receives as input. The security parameter preserving reductions have been used in
constructions of leakage resilient circuit compilers [11]. The notion of “approximate” security
parameter preserving reductions is new to this work. Such reductions are parameterized by
polynomial functions `(¡), u(¡) and on input security parameter n, the reduction may query
the adversary on any security parameter in the range `(n) to u(n). This notion is somewhat
less restrictive than a security parameter preserving reduction. Finally, in a non-security
parameter preserving reduction, the reduction receives security parameter n as input and
may query the adversary on arbitrary security parameter n′. Note that n′(n) must be in
O(nc) for some constant c, since the reduction must be polynomial time. This notion allows
us to rule out the most general type of black-box reduction discussed above.

ITCS 2020



80:8 Limits to Non-Malleability

We can instantiate the tampering class F from our generic lemma statements with various
classes of interest. Our results on security parameter preserving and approximate security
parameter preserving reductions apply to the class NC1 as a special case. Our result ruling
out non-security parameter preserving reductions applies to the class (non-uniform) NC as a
special case. See Corollaries 32, 36, 38 for the formal statements. As the proofs are already
quite involved, we make the simplifying assumption of deterministic decoding and perfect
correctness. However, this is not inherent to the proof and we expect the results to extend
to coding schemes with imperfect correctness and randomized decoding.

Do reductions for NMC take the above form?

So far, in the non-malleable codes setting, results have either been unconditional (e.g. [43, 4])
or have been based on polynomial-hardness assumptions (e.g. [64, 2]). The results that are
based on polynomial-hardness assumptions have all used black-box security reductions, in the
standard polynomial-time sense [69]. Our notion is new since it captures a fine-grained setting
where the underlying distributional problem is, in fact, easy for polynomial-time algorithms.
As discussed above, this is the minimal computational hardness assumption necessary to
construct non-malleable codes for classes F for which we cannot prove unconditionally that
P 6⊆ F . While this type of reduction implicitly arises in the work of [18], our work is the
first to formally define and explore this notion of fine-grained black-box reductions in a
cryptographic setting.

1.3 Technical Overview
In order to prove impossibility of constructing non-malleable codes in different scenarios,
we need to show that any such code is malleable. Recall that for single-bit messages,
non-malleability is equivalent to showing that when applying the tampering function to a
randomly generated encoding of a random bit, the decoded value flips with probability at
most 1/2 + negl(n). Thus, proving that something is malleable, corresponds to showing that
the decoded value flips with probability at least 1/2 + 1/ poly(n). We will use this fact in
the following exposition.

1.3.1 On tampering functions that change d/2 symbols, where d is the
distance of the code

We observe that for any coding scheme, there must be some message, x∗, such that every
encoding of that message is at most distance d/2 from something that is likely to decode to
something other than x∗. Our tampering function will only modify encodings of x∗, and it
will do so by moving each encoding to one of these nearby points that decodes differently. We
claim that if there are at least 3 messages in the message space, then the output of decoding
with the tampering function described above depends on the input message (and thus cannot
be simulated). Indeed, when starting with message x∗ (which is encoded, tampered, and
decoded) there must be some other message y∗ 6= x∗ that is not output a majority of the
times by this process. On the other hand, when starting with y∗, since the tampering does
not change anything in this case, correctness of decoding means that y∗ should be output a
majority of times.

This argument falls apart if there are only two possible messages, and in this case a
repetition code with a decoding that outputs a fixed value on invalid codewords is, in fact,
non-malleable with respect to tampering functions that can change up to n− 1 symbols.



M. Ball, D. Dachman-Soled, M. Kulkarni, and T. Malkin 80:9

1.3.2 On tampering functions where each input symbol affects at most
one output symbol

Consider any two codewords cx and cy corresponding to distinct messages, x and y. Now
consider any sequence of n codewords between cx and cy, made by altering one symbol at
a time. There must be two adjacent codewords, ci, ci+1, (differing on a single bit) in this
sequence that decode differently. Therefore, to tamper, simply output ci if the input is
an encoding of 0, and ci+1 otherwise. Because ci and ci+1 just differ on a single bit, the
tampering function has input locality 1.

1.3.3 On tampering functions where each output symbol depends on
n− log(1/(4ε)) input symbols

We begin by considering a simpler argument, that only rules out tampering functions of
output locality n − 1 (each output bit can depend on at most n − 1 input bits), where n
is the bit length of the codeword. To illustrate the idea in the locality n− 1 case, we also
assume that the decoding algorithm is deterministic. We consider two cases and show that
each case leads to a different tampering attack:

Case 1: Given the first n− 1 bits of the codeword, the codeword decodes to the same
bit b, regardless of whether the final bit is 0 or 1. In this case, the tampering function
contains a hardwired valid codeword encoding 0 and a valid codeword encoding 1. The
tampering function derives the bit b, given only the first n− 1 bits (since the decoded bit
b is independent of the final bit) and replaces the codeword with the hardwired encoding
of 1− b.
Case 2: Given the first n− 1 bits of the codeword, the codeword decodes to 0 if the final
bit is set to b and decodes to 1 if the final bit is set to 1− b. In this case, the tampering
function just flips the final bit, causing the decoding to flip.

The key observation is that we can extend the attacks for Cases 1 and 2 above to tampering
functions of output locality n− log(1/(4ε)). We will sketch the special case corresponding
to extending to Îľ = 1

4n (and locality (n − log(n))), to rule out non-malleable codes with
negligible error. Case 1 now corresponds to the case that, for a randomly generated codeword,
when the first n− log(n) bits of the codeword are fixed and the remaining log(n) bits are
set at random, the decoded value remains the same wi";"""date"",""2019-12-18T08:23:43Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""Limits to Non-Malleability""
""xmp:CreatorTool"",""LaTeX with lipics-v2019.cls and hyperref.sty""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""LIPIcs, Vol.151, ITCS 2020; Copyright (C) Marshall Ball, Dana Dachman-Soled, Mukul Kulkarni, and Tal Malkin; licensed under Creative Commons License CC-BY""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with lipics-v2019.cls and hyperref.sty""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""Limits to Non-Malleability""
""modified"",""2019-12-18T08:23:43Z""
""cp:subject"",""LIPIcs, Vol.151, ITCS 2020; Copyright (C) Marshall Ball, Dana Dachman-Soled, Mukul Kulkarni, and Tal Malkin; licensed under Creative Commons License CC-BY""
""pdf:docinfo:subject"",""LIPIcs, Vol.151, ITCS 2020; Copyright (C) Marshall Ball, Dana Dachman-Soled, Mukul Kulkarni, and Tal Malkin; licensed under Creative Commons License CC-BY""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""Marshall Ball, Dana Dachman-Soled, Mukul Kulkarni, Tal Malkin""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.20 (TeX Live 2019) kpathsea version 6.3.1""
""meta:author"",""Marshall Ball, Dana Dachman-Soled, Mukul Kulkarni, Tal Malkin""
""trapped"",""False""
""meta:creation-date"",""2019-12-18T08:23:43Z""
""created"",""2019-12-18T08:23:43Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-12-18T08:23:43Z""
""resourceName"",""LIPIcs-ITCS-2020-80.pdf""
""Author"",""Marshall Ball, Dana Dachman-Soled, Mukul Kulkarni, Tal Malkin""
""producer"",""pdfTeX-1.40.20""
""pdf:docinfo:producer"",""pdfTeX-1.40.20""
""pdf:unmappedUnicodeCharsPerPage"",""1"",""2"",""0"",""17"",""1"",""2"",""4"",""2"",""4"",""11"",""3"",""11"",""7"",""18"",""21"",""12"",""3"",""33"",""22"",""24"",""61"",""19"",""11"",""15"",""20"",""44"",""76"",""7"",""0"",""0"",""0"",""0""
""Keywords"",""non-malleable codes, black-box impossibility, tamper-resilient cryptogtaphy, average-case hardness""
""access_permission:modify_annotations"",""true""
""dc:creator"",""Marshall Ball, Dana Dachman-Soled, Mukul Kulkarni, Tal Malkin""
""dcterms:created"",""2019-12-18T08:23:43Z""
""Last-Modified"",""2019-12-18T08:23:43Z""
""dcterms:modified"",""2019-12-18T08:23:43Z""
""title"",""Limits to Non-Malleability""
""Last-Save-Date"",""2019-12-18T08:23:43Z""
""pdf:docinfo:keywords"",""non-malleable codes, black-box impossibility, tamper-resilient cryptogtaphy, average-case hardness""
""pdf:docinfo:modified"",""2019-12-18T08:23:43Z""
""meta:save-date"",""2019-12-18T08:23:43Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.20 (TeX Live 2019) kpathsea version 6.3.1""
""Content-Length"",""696043""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Marshall Ball, Dana Dachman-Soled, Mukul Kulkarni, Tal Malkin""
""dc:subject"",""non-malleable codes, black-box impossibility, tamper-resilient cryptogtaphy, average-case hardness""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""32""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""2732"",""3030"",""3144"",""3041"",""3301"",""3305"",""3436"",""2931"",""2985"",""3516"",""3202"",""2436"",""2082"",""2178"",""2586"",""1989"",""2310"",""2408"",""2696"",""2081"",""1311"",""2627"",""2699"",""1809"",""2877"",""2730"",""3117"",""3323"",""3621"",""3467"",""3660"",""2961""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""non-malleable codes, black-box impossibility, tamper-resilient cryptogtaphy, average-case hardness""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-12-18T08:23:43Z""
";https://scholar.google.ch/scholar?start=920&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098897-405;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;??????????????????;EC Tang ; ?????????????, 2020  airitilibrary.com;;"… ????????????????????????????????????????

?????????(blockchain) ????????????????????????(transparent …

???????????????????(interactive oracle proof) ????????? …";Autres articles;;null;;;;https://scholar.google.ch/scholar?start=950&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098778-139;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;WANA: Symbolic Execution of Wasm Bytecode for Cross-Platform Smart Contract Vulnerability Detection;D Wang, B Jiang, WK Chan ; arXiv preprint arXiv:2007.15510, 2020  arxiv.org;;"… detection tools can only support one blockchain platform. In this work, we present WANA, a cross-

platform smart contract vulnerability detection tool based on the symbolic execution of

WebAssembly bytecode. Furthermore, WANA proposes a set of test oracles to detect the …";Autres articles;;[PDF] arxiv.org;https://arxiv.org/pdf/2007.15510;"
WANA: Symbolic Execution of Wasm Bytecode for                     
Cross-Platform Smart Contract Vulnerability Detection*# 

` 

Dong Wang, Bo Jiang†  
School of Computer Science and Engineering 

Beihang University  
Beijing, China 

{wangdong, jiangbo}@buaa.edu.cn 

W.K. Chan 
Department of Computer Science 

City University of Hong Kong 
Hong Kong  

wkchan@cityu.edu.hk 

 

ABSTRACT 
Many popular blockchain platforms are supporting smart 
contracts for building decentralized applications. However, the 
vulnerabilities within smart contracts have led to serious financial 
loss to their end users. For the EOSIO blockchain platform, 
effective vulnerability detectors are still limited. Furthermore, 
existing vulnerability detection tools can only support one 
blockchain platform. In this work, we present WANA, a cross-
platform smart contract vulnerability detection tool based on the 
symbolic execution of WebAssembly bytecode. Furthermore, 
WANA proposes a set of test oracles to detect the vulnerabilities 
in EOSIO and Ethereum smart contracts based on WebAssembly 
bytecode analysis. Our experimental analysis shows that WANA 
can effectively detect vulnerabilities in both EOSIO and 
Ethereum smart contracts with high efficiency. 

CCS CONCEPTS 
• Security and privacy → Software and application security 

• Software and its engineering → Software verification and 
validation 

KEYWORDS 
Symbolic execution, WebAssembly, Smart contract, Wasm, 
Vulnerability detection, EOSIO, Ethereum  

1 Introduction  
The blockchain technology has enabled decentralized value 

transfer networks among parties with limited trust [15]. With the 
support of smart contracts, the developers can build Decentralized 
Applications (DApps) on top of the blockchain platforms such 
that untrusted parties can cooperate with each other. Popular 
DApps include blockchain games, Decentralized Finance (DeFi), 
online gambling, decentralized exchanges, wallets, supply chain 
management, logistics tracking, etc.  

The Ethereum [4] and EOSIO [29] are two of the most popular 
public blockchain platforms supporting smart contracts. However, 
the vulnerabilities within Ethereum and EOSIO smart contracts 
have led to financial loss to their end users. For EOSIO smart 
contracts, the Block Information Dependency vulnerability, the 
Fake EOS Transfer vulnerability and the Forged Transfer 
Notification vulnerability have led to the loss of around 380K 
EOS tokens [32][34] in total. The accumulated amount of loss by 
these vulnerabilities was around 1.9 million worth of USD at the 
time of attack. For the Ethereum smart contracts, the vulnerability 
in the DAO contract [23] led to the loss of $60 million. Also, the 
Freezing Ether and the Dangerous DelegateCall Vulnerability 
resulted in the loss of $60 million and the frozen of $150 million 
in terms of Ether [42][43], respectively.  

Therefore, effective vulnerability detection tools are needed to 
safeguard the ecosystem of blockchain platform. However, the 
vulnerability detection tools for EOSIO smart contract are still 
limited. Furthermore, existing smart contract vulnerability 
detection tools can only support one blockchain platform. Due to 
the diversity of blockchain platforms, a cross-platform 
vulnerability detection tool is desirable for practical use.  

WebAssembly (Wasm for short) [43] is a binary instruction 
format for a stack-based virtual machine. It is also adopted by the 
EOSIO blockchain platform for better efficiency and reliability. 
The Ethereum also plans to replace the EVM with Ethereum 
WebAssembly (EWasm) VM as the smart contract execution 
engine for Ethereum 2.0 [13][19]. As a result, the smart contracts 
on both the EOSIO and Ethereum platform will be compiled to 
WebAssembly for execution in the corresponding Wasm VM 
implementation. Therefore, a symbolic execution engine at the 
WebAssembly level has the potential to provide a common 
security analysis framework for EOSIO smart contract, Ethereum 
smart contract, and even for Web applications based on Wasm.  

In this work, we proposed WANA, a symbolic execution 
engine for Wasm bytecode to support cross-platform 
vulnerability ANAlysis. WANA can support the vulnerability 
detection of both EOSIO and Ethereum smart contracts. In our 
experiment on about 3960 EOSIO smart contracts, WANA 
effectively detected more than 400 vulnerabilities. Furthermore, 

* This research is supported in part by the National Key R&D Program of China 
under Grant 2019YFB2102400, and NSFC (project no. 61772056). 

# WANA is being Open Sourced. https://github.com/gongbell/wana 
† All correspondence should be addressed to Bo Jiang, gongbell@gmail.com. 



 2 

our case study showed that WANA can also effectively detect 3 
typical vulnerabilities for Ethereum smart contracts. 

The contribution of this work is three-fold. First, it presents 
the first cross-platform smart contract vulnerability detection 
framework based on the symbolic execution of Wasm bytecode. 
Second, it proposes a set of test oracles to detect the 
vulnerabilities within EOSIO and Ethereum smart contracts based 
on Wasm bytecode analysis. Third, the work has evaluated 
WANA on both EOSIO and Ethereum smart contracts for 
vulnerability detection, and WANA has effectively identified 
vulnerabilities in both EOSIO and Ethereum smart contracts with 
high efficiency. 

The organization of the remaining sections is as follows. In 
Section 2, we present the basics of Wasm, EOSIO smart contracts 
and Ethereum smart contracts. Then in Section 3, we review 
typical vulnerabilities of EOSIO and Ethereum smart contracts. 
In Section 4, we present the design of our WANA framework in 
detail. After that, we report a comprehensive experimental study 
to evaluate the effectiveness of WANA in terms of vulnerability 
detection on EOSIO smart contracts in Section 5. Then we present 
a case study to evaluate the vulnerability detection ability of 
WANA on Ethereum smart contracts in Section 6. In Section 7, 
we present successful attacks to smart contracts detected by 
WANA. Finally, in Section 8 and Section 9, we present the related 
works and conclusions. 

2 Background on Wasm and Smart Contracts 
In this section, we will briefly review background information 

on Wasm and smart contracts. 

2.1 The WebAssembly 
WebAssembly (Wasm for short) [43][44] is a binary 

instruction format for a stack-based virtual machine. The 
WebAssembly virtual machines can be embedded into Web 
browsers or Blockchain platforms for execution. Wasm is 
currently supported by the EOSIO blockchain platform. And the 
replacement of Ethereum VM (EVM) with Ethereum Wasm VM  
is planned to take place in Ethereum 2.0 [13][19].  

Wasm is designed as a portable target for compilation of high-
level languages like C/C++/Rust, enabling deployment on the 
web for client and server applications. Wasm is designed to be 
fast, safe, and debugging friendly. As a result, Wasm is widely 
supported by all major web browsers [43]. There are two 
equivalent and convertible representations for WebAssembly: the 
binary format (“.wasm” as suffix) and the text format (“.wast” as 
suffix). The Wasm code is used for execution while the Wast code 
is for ease of reading and editing by human. 

2.2 Background on EOSIO Smart Contracts 
EOSIO [24] is a public blockchain platform that focuses on 

the scalability of transactions. The EOSIO platform uses the 
Delegated Proof of Stake (DPoS) consensus protocol which is 
much more scalable than the Proof of Work (PoW) consensus 
protocol. The EOS token also represents the stake hold by its 
owners. The EOSIO platform supports smart contracts to enable 
developers to build DApps.  

On the EOSIO platform, there are two types of smart contracts. 
The first type is the system contracts, which are smart contracts 
deployed on the EOSIO platform by default to realize core 
blockchain features such as consensus, fee schedules, account 
creation, and token economics [40]. The eosio.token smart 
contract [31] is one such system smart contract which defines the 
data structures and actions enabling users to issue and transfer 
tokens on EOSIO based blockchains. The second type of smart 
contracts are user defined smart contracts deployed on the EOSIO 
platform [37] to realize specific business requirements. 

Each EOSIO smart contract must realize the apply function as 
the entry function to handle actions. All incoming actions are 
routed to the apply function [27], which will in turn dispatch the 
actions to corresponding handler functions for processing. To 
develop EOSIO smart contract, the recommended language is 
C++ [29]. The smart contract in C++ will be compiled into Wasm 
bytecode for execution on the EOSIO Wasm VM. The apply 
function has several parameters as input: receiver, code, and 
action. The receiver is the account currently processing the action. 
The code is the account that the action was originally sent to. The 
action is the id of the action. When a smart contract receives an 
action, it may forward the action to other contracts with the 
require_recipient() function. 

2.3 Background on Ethereum Smart Contracts 
On the Ethereum blockchain platform, there are external 

accounts (i.e., owned by human) and smart contract accounts [34]. 
Smart contract is responsible to manage the balance and the 
persistent private storage of the contract account. A transaction is 
a message sent from one account to another account. 
Conceptually, Ethereum [32] can be viewed as a transaction-
based state machine, where its state is updated on each transaction. 
When the target account of a transaction is a smart contract 
account, its code is executed and the payload is provided as input. 

In existing releases of Ethereum, the smart contract code is 
executed on the Ethereum Virtual Machine (EVM). Developers 
can write smart contracts using Solidity, a high-level 
programming language [38], which are then compiled into EVM 
bytecode. In the upcoming releases of Ethereum 2.0, EWasm VM 
is planned to replace EVM to serve as the smart contract 
execution engine [13][19]. In particular, EWasm is a restricted 
subset of Wasm to be used for contracts in Ethereum. For example, 
it eliminates non-deterministic behaviors during smart contract 
execution. 

3 Smart Contracts Vulnerabilities 
In this section, we will review smart contract vulnerabilities 

in EOSIO and Ethereum blockchain platforms.  

3.1 EOSIO Smart Contract Vulnerabilities 
We will present 3 typical EOSIO smart contract 

vulnerabilities detected by WANA in this section. 

3.1.1 Fake EOS Transfer 
In the EOSIO platform, a smart contract must send EOS 

tokens to another smart contract via the eosio.token system smart 
contract. The eosio.token system smart contract manages the EOS 



 

accounts of all smart contracts within its internal storage. During 
a transfer, the sender contract must call the transfer function of 
eosio.token system contract. Within the transfer function of 
eosio.token, the balances of the sender and receiver contract 
accounts will be adjusted accordingly. Meanwhile, eosio.token 
will call require_recipient() to notify both the sender and receiver 
contracts when performing the transfer.  

Within the apply function of a safe smart contract, it must 
ensure the original receiver (i.e., the code parameter of apply 
function) of the transfer action is eosio.token. However, if the 
contract under attack is vulnerable in that it does not check 
whether the code is eosio.token within its apply function when the 
action is transfer, an attacker may perform an inline call to its 
transfer function directly to fake an EOS transfer. As a result, the 
vulnerable contract may wrongly consider that the attacker has 
transferred EOS to it. The EOSBet [25] and EOSCast [26] are two 
such contracts with Fake EOS Transfer vulnerability, and both 
have suffered serious losses. 

 
1 #define EOSIO_ABI_EX( TYPE, MEMBERS ) 
2 extern ""C"" { 
3 void apply(uint64_t receiver, uint64_t code, uint64_t action){ 
4 auto self = receiver; 
5 if (code == self || code == N(eosio.token) || action == N(onerror)){ 
6 TYPE thiscontract (self); 
7 switch( action ) { 
8 EOSIO_API(TYPE, MEMBERS) 
9 }}}} 

Figure 1. The EOSBet Contract with Fake EOS Transfer 
Vulnerability 

 
As shown in Figure 1, within the apply function of the EOSBet 

contract, it only checks whether the code is the contract itself or 
eosio.token (line 5), but it does not check whether the code is 
eosio.token when the action is transfer. As a result, an attacker 
contract may directly call the transfer function of the vulnerable 
contract to make a bet without spending any EOS. 

As shown in Figure 2, the best practice to fix the vulnerability 
is to add a check in the apply function to ensure the transfer is 
performed via the eosio.token system contract (lines 6 and 7). In 
other words, when the action is transfer, the code must be 
eosio.token. 

 
1 #define EOSIO_ABI_EX( TYPE, MEMBERS ) 
2 extern ""C"" { 
3 void apply(uint64_t receiver, uint64_t code, uint64_t action){ 
4 auto self = receiver; 
5 if( code == self || code == N(eosio.token) || action == N(onerror)){ 
6 if( action == N(transfer) ){ 
7 eosio_assert( code == N(eosio.token), ""Must transfer EOS""); 
8 } 
9 … 

Figure 2. The Fix of the Fake EOS Transfer Vulnerability 

3.1.2 Forged Transfer Notification 
During a Forged Transfer Notification attack [24], the attacker 

controls two accounts: sender and notifier. The sender initializes 

the attack by transferring EOS to notifier via eosio.token. When 
the transfer is successful, both sender and notifier will receive 
transfer notification. However, the smart contract with account 
notifier can deliberately forward the transfer action to a victim 
contract C with the require_recipient() function, which is 
essentially a carbon copy of the transfer action. 

As shown in Figure 3, if the contract C fails to check whether 
the destination (i.e., data.to) of EOS transfer is itself within its 
transfer function, it may wrongly consider that it has actually 
received EOS from the sender rather than just a notification. As a 
result, it may wrongly credit the sender account, which in fact has 
sent nothing to C. The smart contract C is said to have the Forged 
Transfer Notification vulnerability [33]. 
 
1 class C : public eosio::contract { 
2 public: 
3 void transfer(uint64_t sender, uint64_t receiver) { 
4 auto data = unpack_action_data<st_transfer>(); 
5 if (data.from == _self) //no check for data.to 
6 return; 
7 doSomething(); 
8 } 
9 } 

Figure 3. The Smart Contract with Forged Transfer Notification 
Vulnerability 

As shown in Figure 4, a possible fix of the Forged Transfer 
Notification vulnerability is to check the destination of the 
transfer (line 5). If the destination of the EOS transfer is not the 
current contract, then the contract should directly ignore the 
transfer notification.  

1 class C : public eosio::contract { 
2 public: 
3 void transfer (uint64_t sender, uint64_t receiver) { 
4 auto data = unpack_action_data<st_transfer>(); 
5 if (data.from == _self  || data.to != _self) 
6 return; 
7 doSomething(); 
8 } 
9 } 

Figure 4. A Fix of the Forged Transfer Notification Vulnerability  

3.1.3 Block Information Dependency 
Reliable source of randomness is hard to obtain on blockchain 

platforms. Developers may be tempted to use the block 
information such as tapos_block_prefix and tapos_block_num to 
generate random numbers. The random numbers may be used to 
determine the transfer of EOS or the winner of a lottery. 
Unfortunately, the tapos_block_prefix and tapos_block_num are 
not reliable source of randomness because they can be directly 
calculated from ref_block_num, which is the id of the last 
irreversible block by default. A gambling contract may use a 
deferred action to determine the winner of a lottery. In such 
scenario, the reference block is the block just before the block 
making the bet. Therefore, when a smart contract uses 
tapos_block_prefix and tapos_block_num directly for random 
number generation, the number generated can be predicted.  



 4 

EOSRoyale [32] is an EOSIO smart contract with Block 
Information Dependency vulnerability. As shown in Figure 5, it 
uses the product of the block number and block prefix as the seed 
for random number generation (lines 7 to 9). Therefore, the 
variables used for random number generation can be computed 
before making the bet. As a result, the attackers successfully 
calculated the random number, won the gambling game, and 
received the prizes in EOS. 

1 class EOSRoyale: public eosio::contract { 
2 … 
3 void rand() { 
5 checksum256 result; 
7 auto mixedBlock = tapos_block_prefix()* tapos_block_num(); 
8 const char * mixedChar = (const char *)(&mixedBlock); 
9 sha256((char*)mixedChar, sizeof(mixedChar), &result); 

10 }        
11 } 

Figure 5. The EOSRoyale Contract with Block Information             
Dependency Vulnerability 

3.2 Ethereum Smart Contract Vulnerabilities 
The Ethereum smart contract vulnerabilities 

[2][6][8][9][11][12][16][17][22] have been extensively studied in 
previous works. In this section, we will briefly review three 
common types of Ethereum smart contract vulnerabilities 
supported by WANA. 

Greedy. A greedy smart contract can receive ether but it 
contains no functions to send ether to other accounts. Therefore, 
this kind of smart contract will freeze any ether sent to them. The 
second round of attack on Parity wallet vulnerability [42] was due 
to the fact that many smart contracts only relied on the parity 
wallet library to manage their ether through delegateCall(). When 
the parity library was changed to a contract through initialization 
and then killed by the attacker, all the ether within these wallet 
smart contracts relying on the parity library was frozen. 

Dangerous DelegateCall. The delegatecall is similar to a 
message call except that the code is executed with the data of the 
calling contract [34]. This is the way to implement the “library” 
feature in Solidity for code reuse. However, when the argument 
of the delegatecall is msg.data, an attacker can manipulate the 
msg.data so that the attacker can make a victim contract to call a 
specific function. This vulnerability resulted in the outbreaks of 
the first round of parity wallet attack [41]. The Wallet contract 
used a delegatecall with msg.data as its parameter. As a result, an 
attacker could call any public function of _walletLibrary. Then 
the attacker called the initWallet function of the _walletLibrary 
and became the owner the wallet contract. Finally, the attacker 
sent the ether in the wallet to his own address to finish the attack, 
which led to $30 million loss to the parity wallet users. 

Block Information Dependency. The Block Information 
Dependency vulnerability exists when an Ethereum smart 
contract uses the block timestamp or block number to determine 
a critical operation (e.g., sending ether or determining the winner 

of a lottery). Indeed, both block timestamp and block number are 
variables that can be manipulated by miners, so they cannot be 
used as reliable sources for critical operations. For example, the 
miner has the freedom to set the timestamp of a block within a 
small interval [36] in Ethereum. Therefore, if an Ethereum smart 
contract transfers ether based on timestamp, an attacker can 
manipulate the block timestamp to exploit the vulnerability. 

4 The Design of the WANA Framework 
In this section, we will present the design of the WANA 

symbolic execution framework for cross-platform smart contract 
vulnerability analysis. 

4.1 The Workflow of WANA 
The workflow of WANA is shown in Figure 6. The input of 

WANA is the Wasm bytecode. For EOSIO smart contract, the 
corresponding Wasm bytecode can be collected from the EOSIO 
public blockchain or compiled from EOSIO smart contract source 
code. For Ethereum smart contract written in Solidity, the 
corresponding bytecode can be generated from a solidity-to-
Wasm compiler.  

 
Figure 6 The Workflow of WANA 

First, the Wasm bytecode is parsed, loaded and initialized 
within our Wasm symbolic execution engine. As a result, the 
stack and memory of the symbolic execution engine are ready for 
execution. Second, the symbolic execution engine starts to 
traverse the paths of the Wasm code with symbolic input. During 
symbolic execution, the symbolic execution engine will invoke 
the Z3 [14] constraint solver to check and prune unsatisfiable 
paths along the way. Meanwhile, the execution information useful 
for vulnerability analysis are collected during symbolic execution. 
Third, WANA will perform vulnerability analysis based on the 
execution information collected during the symbolic execution 
process. When a vulnerability is detected, the corresponding 
report will be generated. Note that the step 2 and step 3 are 
iterative process, where the vulnerability analysis and symbolic 
execution will interleave with each other. The whole workflow 
ends when all the code has been traversed.  

Wasm Bytecode

1. Loading & Initialization

Loaded Wasm

3. Vulnerability Analysis

2. Symbolic Execution

Execution Information

Vulnerability Reports

Z3



 

4.2 The Symbolic Execution Engine  
Wasm supports 4 data types, including two integer data types 

and two float-point data types under IEEE 754 standard. The 
WANA symbolic execution engine supports all of them for 
analysis. 

WebAssembly programs are organized into modules [35], 
which are the units of deployment, loading, and compilation. For 
an EOSIO or Ethereum smart contract, the generated Wasm 
bytecode will correspond to one module. During the loading and 
initialization phase, the WANA symbolic execution engine will 
prepare the memories, tables, global variables and a stack as the 
execution environment for executing the Wasm instructions 
within a module. For a module, the exports component defines a 
set of exported functions and data structures that become 
accessible to the host environment once the module has been 
instantiated. In other words, the exported functions serve as the 
public interfaces for a Wasm module. Therefore, the WANA 
framework will start the symbolic execution by iterating each 
exported function.  

Among the exported functions, the apply function is the entry 
function to dispatch actions for EOSIO smart contracts. For the 
Ethereum smart contracts, the main function is the entry function 
for interacting with the Ethereum smart contract Application 
Binary Interfaces (ABIs). 

For each Wasm function invocation within the instructions in 
a module, WANA will first prepare a frame as its execution 
context, which includes arguments, local variables, return values, 
and references to its module. Then WANA will start symbolically 
executing the instructions within the code section of the function 
sequentially. The Wasm instructions mainly include the numeric 
instructions, memory instructions, control instructions, and 
function call instructions. WANA has realized 171 out of the 185 
instructions in the WebAssembly specification version 1.0 [43].  

For numeric instructions, WANA realizes the stack-based 
execution logic. The WANA symbolic execution engine will pop 
the operands, perform symbolic calculations, and push the result 
back to stack. All the numeric instructions on integer and floating-
point value types are supported. 

For control instructions, there are two kinds of branch 
instructions: unconditional branch (e.g., br) and conditional 
branch (e.g., br_if). The unconditional branch will directly jump 
to the label specified by the instruction argument to continue 
execution, which is useful to realize loops. However, when the 
depth of the loop grows, the symbolic execution engine may be 
very slow or trapped due to state explosion. Therefore, WANA 
set an upper bound to the depth of loops for each label during path 
exploration. For the instruction br_if, the execution will depend 
on the evaluation results of conditional expression. WANA will 
record the execution context for each branch and traverse each 
branch separately to realize path coverage. For each branch, the 
corresponding path constraint will be input to z3 [14] for 
constraint solving before traversing, which can improve the 
execution efficiency by pruning those infeasible paths.  

There are three types of memory manipulation instructions: 
load, store, and increasing the size of the memory. Wasm adopts 
a linear memory model with a contiguous, mutable array of raw 
bytes [43]. A program can load and store values from/to a linear 
memory at any byte address. Since there are many bit 
manipulation instructions on integer and float data types in Wasm, 
we choose to represent the integer and float data types with the 
bit-vector data type in z3. WANA uses 32-bit (64bit) bit-vector 
data types to represent 32-bit (64-bit) integer and float-point 
symbolic data types. Since byte array cannot store bit-vector and 
its expression, WANA uses a linear list to store the references of 
both concrete and symbolic values to emulate memory. 

In Wasm, there are two types of function calls: direct function 
calls and indirect function calls. For indirect function calls, Wasm 
VM has to first get an index from the top of the stack. Then the 
VM will use the index to get the real function address from a 
function table. There are 3 types of functions for calling directly: 
the other functions of the current Wasm module under analysis, 
the functions of other Wasm modules, the API functions of 
EOSIO. For the functions in the current Wasm module, WANA 
will step into the functions to continue symbolic execution. For 
the API functions or the functions in other modules, WANA still 
cannot support their symbolic executions. Therefore, WANA will 
randomly generate a concrete value based on the return type of 
the function, which may lead to sound but incomplete analysis. 
Modeling the functions in other contracts or the API functions 
may help improve WANA, which we left as a future work.  

4.3 The Vulnerability Detection Algorithm  
In this section, we will present the vulnerability detection 

algorithms for EOSIO and Ethereum smart contracts. 

4.3.1 Vulnerability Detection for EOSIO Smart Contracts 
Fake EOS Transfer. In general, to detect Fake EOS Transfer 

vulnerability, WANA checks whether there is a feasible path with 
code different from eosio.token that finally invokes the transfer 
function within the apply function.  

1 bool isFakeEOSTransfer() { 
2     if apply function is reachable 
3        if the apply function have 3 i64 parameters  

5 
          find all feasible paths P in apply function where code 
          is neither equal to eosio.token nor receiver  

6 label the code invoking transfer function as sink 
7           if there is any path in P reaching sink 
8          return true 
9     return false 

Figure 7. Algorithms Detecting Fake EOS Transfer 

The algorithm to detect Fake EOS Transfer is shown in Figure 
7. At line 2, WANA first checks whether the apply function is 
reachable. Then WANA further checks whether the apply 
function contains 3 64-bit integer parameters at line 3. The 3 64-
bit integer parameters correspond to the receiver, code, and action 
parameters. In lines 5, WANA performs symbolic execution 
within the apply function to find all feasible paths P where code 
is neither equal to eosio.token nor receiver. In line 6, WANA 



 6 

labels the wasm code invoking the transfer function as sink. 
Finally, it considers the contracts vulnerable if there are any paths 
in P reaching sink (line 7). Otherwise, the contract is not reported 
as vulnerable (line 8 to 9). 

WANA performs analysis on Wasm (i.e., binary format), but 
we use the WebAssembly text format (Wast) in the sequel of this 
section for ease of understanding. One possible Wast code pattern 
to compare the code parameter with eosio.token is shown in 
Figure 8. At line 3, the Wast code pushes $p1 (which represents 
the parameter code) to the stack. Then the Wast code pushes the 
64-bit integer corresponding to eosio.token to the stack (line 5). 
Then, the code and eosio.token are compared at line 6. Line 7 
represents the control flow branch when they are unequal and 
lines 9 to 11 represent the control flow segment when they are 
equal. The code paths in Figure 8 where code is not equal to 
eosio.token can be automatically identified during symbolic 
execution by adding the path constraint at the start: $p1 != 
encoding(“eosio.token”). 

1 … 
2 block $B2 
3   local.get $p1 //$p1 is code 
4 //6138663591592764928 is i64 encoding of eosio.token 
5   i64.const 6138663591592764928 //eosio.token 
6   i64.ne 
7   br_if $B2  //jump if not equal to eosio.token 
8   // branch where code equals to eosio.token 
9   i32.const 0   
10   local.set $l4 
11   br $B1 
12 end 

Figure 8. WAST Code Comparing Code and eosio.token 
 

The Wast code identifying the invocation of the transfer 
function is shown in Figure 9. At lines 2 to 5, the Wast code 
compares the action parameter with transfer. Note that “$p2” 
represents the action parameter and the 64-bit integer at line 4 
represents transfer. If the action equals to transfer (line 7), the 
Wast code will make preparations and call the transfer function 
(line 8 to 11). When detecting Fake EOS Transfer vulnerability, 
WANA uses the code pattern in Figure 9 to locate the code 
invoking transfer function (i.e., a sink). 

1  … 
2 local.get $p2 
3 //-3617168760277827584 is the i64 encoding of transfer 
4 i64.const -3617168760277827584   
5 i64.ne   
6 br_if $B10  //jump if not equal to transfer 
7 //equal to transfer, so preparing the invocation of transfer 
8 local.get $l3 
9 i32.const 0 
10 ... 
11 call $f162 //invoking transfer  
Figure 9. WAST Code Comparing Action and Invoking Transfer 

 

Forged Transfer Notification. When a smart contract 
receives a transfer notification, if it fails to check the destination 
(i.e., data.to) of EOS transfer is itself within its transfer function, 
a Forged Transfer Notification occurs.  

The algorithm to detect Forged Transfer Notification is shown 
in Figure 10. At line 2, WANA first performs concrete execution 
on the apply function with the action and code parameters fixed 
to transfer and eosio.token, respectively. The goal of concrete 
execution is to locate the position of the transfer function. During 
the concrete execution, if the Wasm instruction call_indirect is 
executed, WANA will consider the transfer function reachable 
(line 3). This is because the call_indirect is used in Wasm of 
EOSIO smart contract to invoke ABI functions and the action 
parameter is fixed to transfer at the start. The call_indirect 
instruction will pop a 32-bit integer as index into a table storing 
function addresses to get the address of the transfer function in 
Wasm. Then WANA will record the position of the transfer 
function within Wasm for follow-up analysis (line 4). 

1 bool isForgedTransferNotification() { 

2 
concrete execution of apply with action fixed to transfer 
and code equals to eosio.token. 

3       if transfer function is reachable:  
4          label the position pt of transfer function in Wasm  
5          label the variables or stack storing _self in transfer 
6          label the Wasm comparing _self and to in transfer as C 
7          symbolically executing the transfer function at pt 
8      if there is any path reaching C 
9            return false 
10          else  
11 return true 

Figure 10. Algorithms Detecting Forged Transfer Notification 

From lines 5 to 11, the WANA analyzes the Wasm bytecode 
of the function transfer. At line 5, WANA first labels the set of 
variables storing _self, which is usually read from $p0 (the first 
parameter of transfer) and stored in local variables or the stack. 
Then it continues to label the Wasm bytecode comparing _self (in 
local variables or stack) with to as C (line 6). The “to” can be read 
from $p2 (the third parameter of transfer) or from the action data 
returned by unpack_action_data(). Finally, WANA performs 
symbolic execution within the transfer function to traverse all 
possible paths starting from pt (line 7). If there is any path 
reaching C during symbolic execution, the smart contract is 
considered not vulnerable (line 8 and 9). If there is no path 
reaching C, the smart contract is considered containing Forged 
Transfer Notification vulnerability (line 11). 

Block Information De";"""date"",""2020-08-05T14:58:29Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.3""
""pdf:docinfo:title"",""Microsoft Word - ASE20-WANA-v2.1-arxiv.docx""
""xmp:CreatorTool"",""Word""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dcterms:created"",""2020-08-05T14:58:29Z""
""language"",""en""
""Last-Modified"",""2020-08-05T14:58:29Z""
""dcterms:modified"",""2020-08-05T14:58:29Z""
""dc:format"",""application/pdf; version=1.3""
""title"",""Microsoft Word - ASE20-WANA-v2.1-arxiv.docx""
""Last-Save-Date"",""2020-08-05T14:58:29Z""
""pdf:docinfo:creator_tool"",""Word""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2020-08-05T14:58:29Z""
""meta:save-date"",""2020-08-05T14:58:29Z""
""pdf:encrypted"",""false""
""dc:title"",""Microsoft Word - ASE20-WANA-v2.1-arxiv.docx""
""modified"",""2020-08-05T14:58:29Z""
""Content-Length"",""1058952""
""pdf:hasMarkedContent"",""false""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""meta:creation-date"",""2020-08-05T14:58:29Z""
""created"",""2020-08-05T14:58:29Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""12""
""Creation-Date"",""2020-08-05T14:58:29Z""
""resourceName"",""2007.15510""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""4602"",""6026"",""5226"",""5007"",""6167"",""5339"",""5410"",""4356"",""4707"",""5513"",""6512"",""917""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""producer"",""macOS 版本10.15.5（版号19F101） Quartz PDFContext""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""macOS 版本10.15.5（版号19F101） Quartz PDFContext""
""pdf:docinfo:created"",""2020-08-05T14:58:29Z""
";https://scholar.google.ch/scholar?start=680&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098738-48;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Transactional Scripts in Contract Stacks;S Cohney, DA Hoffman ; U of Penn, Inst for Law & Econ Research …, 2020  papers.ssrn.com;;"… 42 Wulf A. Kaal & Craig Calcaterra, Crypto Transaction Dispute Resolution, 73 … On the problems

caused by blockchain jargon, see Angela Walch, Blockchain's Treacherous Vocabulary … continue

with decentralized exchanges, and finally consider so-called “oracles.” We describe …";Cité 9 fois;Les 6 versions;[PDF] upenn.edu;https://scholarship.law.upenn.edu/cgi/viewcontent.cgi?article=3140&context=faculty_scholarship;"
University of Pennsylvania Carey Law School University of Pennsylvania Carey Law School 

Penn Law: Legal Scholarship Repository Penn Law: Legal Scholarship Repository 

Faculty Scholarship at Penn Law 

2020 

Transactional Scripts in Contract Stacks Transactional Scripts in Contract Stacks 

Shaanan Cohney 
University of Pennsylvania 

David A. Hoffman 
University of Pennsylvania Carey Law School 

Follow this and additional works at: https://scholarship.law.upenn.edu/faculty_scholarship 

 Part of the Artificial Intelligence and Robotics Commons, Banking and Finance Law Commons, 

Business Organizations Law Commons, Commercial Law Commons, Computer Law Commons, Contracts 

Commons, Internet Law Commons, and the Law and Economics Commons 

Repository Citation Repository Citation 
Cohney, Shaanan and Hoffman, David A., ""Transactional Scripts in Contract Stacks"" (2020). Faculty 
Scholarship at Penn Law. 2138. 
https://scholarship.law.upenn.edu/faculty_scholarship/2138 

This Article is brought to you for free and open access by Penn Law: Legal Scholarship Repository. It has been 
accepted for inclusion in Faculty Scholarship at Penn Law by an authorized administrator of Penn Law: Legal 
Scholarship Repository. For more information, please contact PennlawIR@law.upenn.edu. 

https://scholarship.law.upenn.edu/
https://scholarship.law.upenn.edu/faculty_scholarship
https://scholarship.law.upenn.edu/faculty_scholarship?utm_source=scholarship.law.upenn.edu%2Ffaculty_scholarship%2F2138&utm_medium=PDF&utm_campaign=PDFCoverPages
http://network.bepress.com/hgg/discipline/143?utm_source=scholarship.law.upenn.edu%2Ffaculty_scholarship%2F2138&utm_medium=PDF&utm_campaign=PDFCoverPages
http://network.bepress.com/hgg/discipline/833?utm_source=scholarship.law.upenn.edu%2Ffaculty_scholarship%2F2138&utm_medium=PDF&utm_campaign=PDFCoverPages
http://network.bepress.com/hgg/discipline/900?utm_source=scholarship.law.upenn.edu%2Ffaculty_scholarship%2F2138&utm_medium=PDF&utm_campaign=PDFCoverPages
http://network.bepress.com/hgg/discipline/586?utm_source=scholarship.law.upenn.edu%2Ffaculty_scholarship%2F2138&utm_medium=PDF&utm_campaign=PDFCoverPages
http://network.bepress.com/hgg/discipline/837?utm_source=scholarship.law.upenn.edu%2Ffaculty_scholarship%2F2138&utm_medium=PDF&utm_campaign=PDFCoverPages
http://network.bepress.com/hgg/discipline/591?utm_source=scholarship.law.upenn.edu%2Ffaculty_scholarship%2F2138&utm_medium=PDF&utm_campaign=PDFCoverPages
http://network.bepress.com/hgg/discipline/591?utm_source=scholarship.law.upenn.edu%2Ffaculty_scholarship%2F2138&utm_medium=PDF&utm_campaign=PDFCoverPages
http://network.bepress.com/hgg/discipline/892?utm_source=scholarship.law.upenn.edu%2Ffaculty_scholarship%2F2138&utm_medium=PDF&utm_campaign=PDFCoverPages
http://network.bepress.com/hgg/discipline/612?utm_source=scholarship.law.upenn.edu%2Ffaculty_scholarship%2F2138&utm_medium=PDF&utm_campaign=PDFCoverPages
https://scholarship.law.upenn.edu/faculty_scholarship/2138?utm_source=scholarship.law.upenn.edu%2Ffaculty_scholarship%2F2138&utm_medium=PDF&utm_campaign=PDFCoverPages
mailto:PennlawIR@law.upenn.edu


	

319	

Article	

Transactional	Scripts	in	Contract	Stacks	

Shaanan	Cohney†	and	David	A.	Hoffman††	

Introduction		............................................................................................................	319 
I.		Designing	Expensive,	Buggy	Scripts		........................................................	328 

A. How	(Commercial)	Coding	Works		...............................................	328 
B. An	Introduction	to	the	Blockchain	Platform		............................	331 
C. Ethereum	and	Scripting		....................................................................	335 
D. Coding	on	Ethereum		...........................................................................	340 
E. Summary		.................................................................................................	345 

II.		Transactional	Scripts	in	the	Real	World		..............................................	347 
A. Tokens		......................................................................................................	347 
B. Exchanges		...............................................................................................	350 
C. Oracles		......................................................................................................	353 

III.		Scripts	and	Stacks		.........................................................................................	357 
A. The	Canonical	Stack		............................................................................	360 
B. Tensions	Within	the	Stack		...............................................................	367 
C. Recapitulating	the	Canons:	Quoine	and	Non-Public		

Scripts		.......................................................................................................	383 
IV.		The	Future	of	the	Contract	Stack		...........................................................	384 

		INTRODUCTION			
In	early	2019,	a	group	of	people	founded	Edgeware,	a	blockchain-

based	 platform	designed	 to	 host	 software	 development.1	Edgeware	

 

†	 	 Ph.D.,	 Postdoctoral	 Research	Associate,	 Center	 for	 Information	Technology	
Policy,	Princeton	University.	Copyright	Š	2020	by	Shaanan	Cohney.	

††	 	Professor	of	Law,	University	of	Pennsylvania	Law	School.	We	thank	Alexander	
Altieri	 and	Chrissy	Pak	 for	 research	assistance,	 and	Yonathan	Arbel,	Bridget	Fahey,	
James	 Grimmelmann,	 Greg	 Klass,	 Raina	 Haque,	 Bob	 Hillman,	 Drew	 Hinkes,	 Cathy	
Hwang,	Gabe	Kaptchuk,	Max	Raskin,	Elizabeth	Pollman,	Gabe	Shapiro,	Jeremy	Sklaroff,	
Tim	Swanson,	Andrea	Tosato,	Alec	Webley,	Kevin	Werbach,	Tal	Zarsky,	Eyal	Zamir,	and	
participants	at	workshops	at	Alabama,	Penn,	and	Utah	for	comments.	This	work	was	
supported	in	part	by	grants	from	the	Ripple	Research	Fund	at	the	Wharton	School	and	
at	the	Princeton	Center	for	IT	Policy.	Copyright	Š	2020	by	David	A.	Hoffman.	
	 1.	 COMMONWEALTH	LABS,	EDGEWARE:	AN	ADAPTIVE	SMART-CONTRACT	BLOCKCHAIN	1	
(2019)	[hereinafter	EDGEWARE	WHITEPAPER],	https://arena-attachments.s3	



320	 MINNESOTA	LAW	REVIEW	 [105:319	

	

made	potential	users	a	deal:	if	they	agreed	to	temporarily	sequester	
some	cryptocurrency	(essentially,	placing	an	initial	investment	in	es-
crow),	they’d	gain	governance	rights	over	the	platform	at	a	later	date.2	
The	mechanism	for	that	investment	was	a	piece	of	carefully-audited	
software,	 called	 “Lockdrop,”	which	was	 deployed	 on	 a	 blockchain.3	
Lockdrop	seemed	to	embody	and	constitute	a	novel	contracting	tech-
nology,	written	in	a	programming	language	(Solidity)	that	didn’t	even	
exist	a	decade	ago.4	

By	July	of	2019,	investors	committed	nearly	$300,000,000	to	the	
project	using	Lockdrop.5	Then	someone	looked	with	particular	care	at	
the	following	piece	of	code:6		

	
assert(address(lockAddr).balance	==	msg.value);	
	
As	it	turns	out,	this	line	was	susceptible	to	a	software	hack	that	

would	have	permanently	impounded	investor	assets.7	Luckily,	the	er-
ror	was	discovered	before	it	caused	harm.	But,	as	the	coder	who	dis-
covered	the	vulnerability	put	it,	“smart	contracts	are	software.	Even	
carefully	audited,	well	 tested	 software	will	 (almost	always)	 contain	
bugs.	Therefore,	and	despite	our	best	efforts	.	.	.	Smart	contracts	will	
(almost	always)	contain	bugs!”8	The	question	we	ask	in	this	paper	is	
simple:	can	contract	 law	make	sense	of	 intractable	bugs	 in	 transac-
tional	code?	The	answer	is	likewise	simple:	yes.	

But	to	their	promoters,	even	buggy	“smart	contracts”	like	Lock-
drop	are	the	vanguard	of	a	revolution,	heralding	an	age	in	which	code	

 

.amazonaws.com/3850782/1928e31873075de95992d4987eb14a2e.pdf?15524	
32633	[https://perma.cc/J3GP-ERC4].	
	 2.	 See	id.	at	5	(“EDG	entitles	holders	both	staking	and	voting	rights	.	.	.	.”).	For	an	
introduction	to	cryptocurrencies,	see	Shaanan	Cohney,	David	Hoffman,	Jeremy	Sklaroff	
&	David	Wishnick,	Coin-Operated	Capitalism,	119	COLUM.	L.	REV.	591,	603–05	(2019).	
See	also	DAVID	FOX	&	SARAH	GREEN,	CRYPTOCURRENCIES	IN	PUBLIC	AND	PRIVATE	LAW	(2019).	
	 3.	 Certificate	 of	 Smart	 Contract	Audit	 for	 Edge-Lockdrop,	QUANTSTAMP	 (Apr.	 8,	
2019),	 https://arena-attachments.s3.amazonaws.com/4282493/a155dc84aa1dfba4	
cfd3dc6be1e1ebdc.pdf?1557965252	[https://perma.cc/UPC5-ZUPT].	
	 4.	 Id.	(noting	that	Lockdrop	used	Solidity	programming	language).	
	 5.	 Neil	McLaren,	Gridlock	(A	Smart	Contract	Bug),	MEDIUM	(July	1,	2019),	https://	
medium.com/@nmcl/gridlock-a-smart-contract-bug-73b8310608a9	 [https://perma	
.cc/V2G2-WT9L]	(“Edgeware’s	Lockdrop	smart	contract	has	processed	over	$900	mil-
lion	of	ETH	and	locked	up	over	$290	million.”).	
	 6.	 Id.	
	 7.	 If	the	attacker	designated	cryptocurrency	to	the	next	lock	address,	the	total	
balance	would	exceed	 the	amount	 sent	by	Lockdrop,	 causing	 the	 check	 to	 fail.	This	
would	freeze	the	sequestering	process	permanently	in	place.	
	 8.	 McLaren,	supra	note	5.	



2020]	 TRANSACTIONAL	SCRIPTS	 321	

	

will	depose	both	contract	theory	and	practice.9	Enthusiasts	argue	that	
when	 contracts	 are	 embodied	 and	 performed	 by	 code,	 contracting	
costs	(like	negotiation,	monitoring,	and	performance)	will	fall.	Better	
still,	parties	won’t	need	to	trust	each	other,	or	courts,	to	be	assured	
that	they’ll	get	what	they	bargained	for.	The	result:	“smart	contracts”	
are	offered	as	a	potential	solution	to	an	astounding	variety	of	business	
and	social	problems.	They	may	transform	insurance,10	financial	deriv-
atives,11	consumer	protection,12	corporate	governance,13	tax	 filing,14	
voting, 15 	supply	 chain	 management, 16 	bankruptcy, 17 	property	
rights,18	and	repossession	through	the	internet	of	things.19	But	there’s	

 

	 9.	 Cf.	Primavera	De	Filippi	&	Samer	Hassan,	Blockchain	Technology	as	a	Regula-
tory	Technology:	From	Code	Is	Law	to	Law	Is	Code,	FIRST	MONDAY	(Dec.	5,	2016),	https://	
firstmonday.org/ojs/index.php/fm/article/view/7113/5657	[https://perma.cc/	
2PX9-8C4K]	 (“What	makes	 the	blockchain	different	 from	other	 technologies	 is	 that	
smart	contracts	are	actually	meant	to	replace	legal	contracts.”);	Mark	Verstraete,	The	
Stakes	of	Smart	Contracts,	50	LOY.	U.	CHI.	L.J.	743,	743	(2019)	(“The	most	ardent	sup-
porters	of	smart	contracts	.	.	.	claim	that	smart	contracts	might	replace	large	swaths	of	
the	traditional	contract	system.”).	
	 10.	 Smart	Contracts:	10	Use	Cases	for	Business,	AMBISAFE,	https://ambisafe.com/	
blog/smart-contracts-10-use-cases-business	[https://perma.cc/S9WA-FHMM].	
	 11.	 See	generally	INT’L	SWAPS	&	DERIVATIVES	ASS’N,	LEGAL	GUIDELINES	FOR	SMART	DE-
RIVATIVES	 CONTRACTS:	 INTRODUCTION	 (2019),	 https://www.isda.org/a/MhgME/Legal-
Guidelines-for-Smart-Derivatives-Contracts-Introduction.pdf	[https://perma.cc/	
N5XN-J5KQ].	
	 12.	 See	 generally	 Joshua	 Fairfield,	Smart	 Contracts,	 Bitcoin	 Bots,	 and	 Consumer	
Protection,	71	WASH.	&	LEE	L.	REV.	ONLINE	35	(2014).	
	 13.	 Fiammetta	S.	Piazza,	Bitcoin	and	the	Blockchain	as	Possible	Corporate	Govern-
ance	Tools:	Strengths	and	Weaknesses,	5	PA.	ST.	J.L.	&	INT’L	AFFS.	262,	282–86	(2017).	
	 14.	 Valentine	P.	Vishnevsky	&	Viktoriia	D.	Chekina,	Robot	vs.	Tax	Inspector	or	How	
the	Fourth	Industrial	Revolution	Will	Change	the	Tax	System:	A	Review	of	Problems	and	
Solutions,	4	J.	TAX	REFORM	6,	20	(2018).	
	 15.	 See	Tsui	S.	Ng,	Blockchain	and	Beyond:	Smart	Contracts,	A.B.A.	BUS.	L.	TODAY	
(Sept.	28,	2017),	https://www.americanbar.org/groups/business_law/publications/	
blt/2017/09/09_ng	 [https://perma.cc/MD66-A7V4]	 (“Governments	may	 use	 smart	
contracts	to	manage	.	.	.	e-voting.”).	
	 16.	 See	generally	Horst	Treiblmaier,	The	Impact	of	the	Blockchain	on	the	Supply	
Chain:	 A	 Theory-Based	 Research	 Framework	 and	 a	 Call	 for	 Action,	 23	 SUPPLY	CHAIN	
MGMT.	INT’L	J.	545	(2018).	
	 17.	 See	generally	Alan	Rosenberg,	Automatic	Contracts	and	the	Automatic	Stay:	A	
Primer	on	“Smart	Contracts”	in	Bankruptcy,	38	AM.	BANKR.	INST.	J.	18	(2019).	
	 18.	 See,	e.g.,	Michael	Casey,	Could	Blockchain	Technology	Help	the	World’s	Poor?,	
WORLD	ECON.	F.	AGENDA	(Mar.	9,	2016),	https://www.weforum.org/agenda/2016/03/	
could-blockchain-technology-help-the-worlds-poor	[https://perma.cc/4U9N-4S2F].	
	 19.	 For	the	canonical	description,	see	Jeremy	M.	Sklaroff,	Comment,	Smart	Con-
tracts	and	the	Cost	of	Inflexibility,	166	U.	PA.	L.	REV.	263,	271–78	(2017).	



322	 MINNESOTA	LAW	REVIEW	 [105:319	

	

more.	Jurisprudence—in	the	sense	of	the	fundamental	utility	of	con-
tract	doctrine—is	on	the	chopping	block.20	For	many,	smart	contracts	
are	the	first	transformative	legal	innovation	of	the	millennium.21	

Perhaps	 inevitably,	 “smart	 contracts,”	 a	 term	 that	 connotes	
money,	 computers,	 and	modernity,	 has	 invited	 a	 stampede	 of	 com-
mentators	to	speculate	about	a	wide	variety	of	possible	contracting	
technologies.22	Many	marvel	at	the	innovation	as	some	kind	of	utopian	
simulacra: 23 	an	 immutable, 24 	transparent	 exchange, 25 	occurring	

 

	 20.	 For	a	 lucid	review,	see	generally	Marco	Dell’Erba,	Demystifying	Technology:	
Do	Smart	Contracts	Require	a	New	Legal	Framework?	Regulatory	Fragmentation,	Self-
Regulation,	Public	Regulation,	U.	PA.	J.L.	&	PUB.	AFFS.	(forthcoming	2020),	https://pa-
pers.ssrn.com/sol3/papers.cfm?abstract_id=3228445	[https://perma.cc./48NP	
-CWX7].	
	 21.	 See,	e.g.,	Alexander	Savelyev,	Contract	Law	2.0:	“Smart”	Contracts	as	the	Begin-
ning	of	the	End	of	Classic	Contract	Law,	26	INFO.	&	COMMC’N	TECH.	L.	116	(2017);	see	also	
What	is	Ethereum?,	ETHERSCRIPTER,	https://etherscripter.com/what_is_ethereum.html	
[https://perma.cc/LV8P-6BJD]	 (describing	 popular	 smart	 contract	 Ethereum	 as	 “a	
new	kind	of	law”	that	can	be	“perfectly	observed	and	enforced”).	
	 22.	 The	fish	rots	from	the	head.	See	NICK	SZABO,	SMART	CONTRACTS:	BUILDING	BLOCKS	
FOR	 DIGITAL	 MARKETS	 1	 (1996),	 http://www.truevaluemetrics.org/DBpdfs/Block-
Chain/Nick-Szabo-Smart-Contracts-Building-Blocks-for-Digital-Markets-1996-14591	
.pdf	 [https://perma.cc/6BAR-V45A]	(defining	smart	contracts	as	“a	set	of	promises,	
specified	in	digital	form,	including	protocols	within	which	the	parties	perform	on	these	
promises”).	In	recent	years,	Szabo	has	vociferously	defended	the	term.	See,	e.g.,	Nick	
Szabo	 (@NickSzabo4),	 TWITTER	 (Oct.	 14,	 2018,	 6:38	 PM),	 https://twitter.com/	
NickSzabo4/status/1051603179526270976	[https://perma.cc/5HC7-D95Z]	(“‘Smart	
contract’	is	a	very	useful	concept	&	phrase.	‘Smart’	as	in	‘smart	phone’	(shorthand	for	
computerized	phone),	‘contract’	meaning	it	does	some	important	things	we	previously	
relied	on	contracts	to	do	for	our	deals,	especially	controlling	assets	&	incentivizing	per-
formance.”).	
	 23.	 Frank	Pasquale,	A	Rule	of	Persons,	Not	Machines:	The	Limits	of	Legal	Automa-
tion,	87	GEO.	WASH.	L.	REV.	1,	24–25	(2019).	
	 24.	 Jeffrey	M.	Lipshaw,	The	Persistence	of	“Dumb”	Contracts,	2	STAN.	J.	BLOCKCHAIN	
L.	&	POL’Y	1,	24	(2019)	(stating	that	the	key	characteristics	of	smart	contracts,	“in	ad-
dition	to	consensus,	include	immutability	and	finality	from	the	time	they	are	created	
and	going	forward”).	
	 25.	 Adam	J.	Kolber,	Not-So-Smart	Blockchain	Contracts	and	Artificial	Responsibil-
ity,	21	STAN.	TECH.	L.	REV.	198,	208	(2018)	(“Since	Ethereum	smart	contracts	consist	of	
particular	computer	code	on	a	decentralized	blockchain,	it	is	easy	to	verify	program	
execution.”).	



2020]	 TRANSACTIONAL	SCRIPTS	 323	

	

through	“consensus,”	that	is	“self-executing”26	or	“automated.”27	With	
that	capacious	definition	in	mind,	is	the	chip	in	your	Visa	Card	part	of	
a	smart	contract	network?	The	code	comprising	the	Venmo	App?	Your	
Metrocard?28	If	we	can’t	understand	 the	scope	of	 this	phenomenon,	
how	can	we	fairly	evaluate	the	risk	it	poses,	or	the	benefits	it	promises,	
to	our	commercial	and	social	life?	

Smart	contracts’	flabby	meaning	is	not	this	Article’s	precise	tar-
get.29	Rather	we	offer	a	focused	description	of	the	most	celebrated	as-
pect	of	the	underlying	technology	and	its	relationship	to	legal	order.	
We’ll	 start	by	 introducing	 a	new	 term	 that	we	 think	 captures	what	
most	people	in	this	field	think	of	when	they	consider	“smart	contracts”	
as	 they	are	currently	deployed.	We	name	and	describe	 the	 transac-
tional	 script.30	Here	 is	 a	 parsimonious	 definition	 (that	we’ll	 unpack	
later):31	

A	transactional	script	is	a	persistent	piece	of	software	residing	on	
a	public	blockchain.	When	executed	as	a	part	of	an	exchange,	the	code	
effectuates	a	consensus	change	to	the	state	of	a	ledger.	

 

	 26.	 Professors	Kevin	Werbach	and	Nicolas	Cornell	argue	that	smart	contracts	are	
distinctive	because	“juridical	forums	are	powerless	to	stop	the	execution	of	smart	con-
tracts—there	 is	no	 room	 to	bring	an	action	 for	breach	when	breach	 is	 impossible.”	
Kevin	Werbach	&	Nicolas	Cornell,	Contracts	Ex	Machina,	67	DUKE	L.J.	313,	332	(2017);	
see	also	Amy	 J.	 Schmitz	&	Colin	Rule,	Online	Dispute	Resolution	 for	 Smart	Contracts,	
2019	J.	DISP.	RESOL.	103,	106,	107,	113	(describing	smart	contracts	as	“self-enforcing,”	
“self-governing,”	and	with	“no	ambiguity	around	the	parties’	obligations”).	
	 27.	 Christopher	D.	 Clack,	Vikram	A.	 Bakshi	&	 Lee	Braine,	 Smart	 Contract	 Tem-
plates:	Foundations,	Design	Landscape	and	Research	Directions	2	(Mar.	15,	2017)	(un-
published	manuscript),	ARXIV:	1608.00771;	see	also	Max	Raskin,	The	Law	and	Legality	
of	Smart	Contracts,	1	GEO.	L.	TECH.	REV.	305,	309	(2017)	(“A	smart	contract	is	an	agree-
ment	whose	execution	is	automated.”).	
	 28.	 See	Kolber,	supra	note	25.	
	 29.	 Cf.	 Ed	 Felten,	 Smart	 Contracts:	 Neither	 Smart	 nor	 Contracts?,	 FREEDOM	 TO	
TINKER	(Feb.	20,	2017),	https://freedom-to-tinker.com/2017/02/20/smart-contracts	
-neither-smart-not-contracts	[https://perma.cc/NZ2Q-GFHE].	
	 30.	 For	a	definition	of	smart	contracts	that	tracks	with	our	transactional	script,	
see	 Carla	 L.	 Reyes,	 If	 Rockefeller	Were	 a	 Coder,	 87	 GEO.	WASH.	L.	REV.	 373,	 383–84	
(2019),	which	states	that:		

The	term	“smart	contract”	refers	to	decentralized	computer	code	that	runs	
on	a	DLT	protocol	and	manifests	some	combination	of	the	following	charac-
teristics:	exerts	some	control	over	assets	digitally	recorded	on	a	DLT	proto-
col,	takes	some	action	upon	receipt	of	specified	data,	is	often,	but	not	always,	
part	of	a	DLT-based	application,	guarantees	execution,	and	writes	the	result-
ing	 state	 change	 from	 the	 operation	 of	 the	 smart	 contract	 into	 the	 DLT’s	
ledger.	

	 31.	 Cf.	Peter	G.L.	Hunn,	Smart	Contracts	as	Techno-Legal	Regulation,	7	J.	ICT	STAND-
ARDIZATION	269,	275	(2019)	(focusing	on	“a	deterministic	state	machine”	and	a	“con-
sensus	protocol”	that	provides	agreement	“on	the	same	sequence	of	operations”).	



324	 MINNESOTA	LAW	REVIEW	 [105:319	

	

We	stress	that	our	focus—for	the	moment—is	narrower	than	all	
digitized	exchanges,32	or	even	all	deals	accomplished	through	block-
chain-style	ledgers.33	That	is,	transactional	scripts	sit	at	the	core	of	the	
rapidly	expanding	group	of	things	called	“smart	contracts,”	but	do	not	
encompass	 the	 whole	 field.	 Crucially,	 transactional	 scripts	 are	 ex-
changes	that	operate	in	public—indeed,	they	are	valuable	in	large	part	
because	their	resolution	must	be	agreed	to	by	multiple	different	enti-
ties,	jointly	operating	on	an	operating	system	with	fixed	and	translu-
cent	rules.	

Transactional	scripts	are	a	striking	legal	innovation	and	much	of	
the	current	interest	in	smart	contracts	in	fact	regards	them.34	But	law	
(and	lawyers’)	role	in	the	creation	and	execution	of	scripts	is	unclear.	
Even	 apart	 from	 the	 performative	 techno-libertarian	 claims	 about	
law’s	abnegation,	many	scripting	projects	are	missing	many	of	the	ac-
coutrements	 of	 transactional	 law.	 More	 plainly	 put,	 currently	 de-
ployed	transactional	scripts—those	that	are	exposing	real	people	to	
financial	and	personal	risks—often	rely	on	the	code	alone	as	their	pri-
mary	risk-allocation	mechanism.	And	the	code	errs.	

In	the	Edgeware	project,	none	of	the	governance	promises	were	
expressed	 in	 a	 natural	 language	 “contract”	 as	 we	 understand	 that	
term,	even	in	the	digital	sphere,	as	 in	a	click-wrap	agreement.	They	
existed	rather	in	a	“white	paper”—a	self-published	document	with	no	

 

	 32.	 For	a	tremendous	survey	of	digitized	exchanges,	see	Harry	Surden,	Computa-
ble	Contracts,	46	U.C.	DAVIS	L.	REV.	629	(2012).	Surden	discusses	“autonomous	comput-
able	contracting”	only	briefly.	Id.	at	694–95.	
	 33.	 The	 reader	 would	 benefit	 from	 reading	 the	 following	 excellent	 works	 on	
scripts	 (broadly	 defined):	 Sklaroff,	 supra	 note	 19;	 J.G.	 Allen,	Wrapped	 and	 Stacked:	
“Smart	Contracts”	and	the	 Interaction	of	Natural	and	Formal	Language,	14	EUR.	REV.	
CONT.	L.	307	(2018);	Werbach	&	Cornell,	supra	note	26;	Karen	E.C.	Levy,	Book-Smart,	
Not	Street-Smart:	Blockchain-Based	Smart	Contracts	and	the	Social	Workings	of	Law,	3	
ENGAGING	SCI.	TECH.	&	SOC’Y	1	(2017);	James	Grimmelmann,	All	Smart	Contracts	Are	Am-
biguous,	2	 J.L.	&	INNOVATION	1	 (2019);	PRIMAVERA	DE	FILIPPI	&	AARON	WRIGHT,	BLOCK-
CHAIN	AND	THE	LAW:	THE	RULE	OF	CODE	(2018);	Jonathan	Rohr,	Smart	Contracts	in	Tradi-
tional	Contract	Law,	or:	The	Law	of	the	Vending	Machine,	67	CLEV.	ST.	L.	REV.	67	(2019);	
Edmund	Schuster,	Cloud	Crypto	Land,	MOD.	L.	REV.	(forthcoming	2020)	(manuscript	at	
23–25),	https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3476678	[http://	
perma.cc/YAY3-TA63].	
	 34.	 See	Global	Smart	Contracts	Market,	MKT.	RSCH.	FUTURE,	https://www.market-
researchfuture.com/reports/smart-contracts-market-4588	[https://perma.cc/F3DN-
L98D]	(“The	global	smart	contracts	market	 is	expected	 to	reach	approximately	300	
USD	Million	by	the	end	of	2023	.	.	.	.”);	cf.	Venture	Capital	Firms	Go	Deep	and	Wide	with	
Blockchain	 Investments,	 DIAR	 (Oct.	 1,	 2018),	 https://diar.co/volume-2-issue-39	
[https://perma.cc/V6Q2-ZLVR]	(“[I]n	just	.	.	.	three	quarters	of	2018,	blockchain	and	
crypto	 companies	 have	 raised	 nearly	 3.9Bn	 through	 traditional	 VC—280%	 more	
[than]	last	year	.	.	.	.”).	



2020]	 TRANSACTIONAL	SCRIPTS	 325	

	

standard	form	and	untested	legal	effect.35	That	white	paper	states	that	
users	will	receive	“[d]ownside	protection”	in	the	case	of	a	“malicious	
attack	 or	 exploit,”	 and	describes	 the	 lockdrop	 contract	 as	 a	 failsafe	
technique.36	Moreover,	the	promoters	suggest	that	it	would	be	impos-
sible	 to	 falsely	 claim	 ownership	 for	 an	 address.37 	Needless	 to	 say,	
these	representations	do	not	match	the	reality	of	what	the	buggy	code	
delivered.	But,	equally	obviously,	since	the	code	was	public,	its	latent	
errors	 were	 also	 theoretically	 knowable,	 at	 least	 to	 sophisticated	
counterparties.	

Other	examples	of	coding	errors	and	oversights	abound—includ-
ing	the	now	infamous	DAO	hack,	which	we	will	discuss	later.38	In	many	
cases,	the	losers	of	coding	errors	have	paid	off	the	winners	to	undo	
transactions.39	Such	settlements	occur	in	the	very	indistinct	shadow	
of	law:	there	isn’t	a	body	of	cases	that	directly	address	the	question	of	
what	happens	when	transactional	scripts	go	wrong.40	The	academic	
literature	too	has	largely	downplayed	the	role	and	capabilities	of	law	
in	resolving	transactional	scripts	gone	wrong.41		

Even	the	most	sophisticated	treatments	in	the	literature	largely	
focus	 on	 what	 happens	 when	 scripts	 accomplish	 their	 promised	
aims.42	Some	argue	that	the	technology	is	simply	incapable	of	the	sorts	
of	error	that	law	cares	about:	the	“[c]ode	typically	entails	no	ambigu-
ity,	and	no	variant	interpretation	is	possible.”43	Others	lament	that	be-
cause	the	blockchain	code	is	self-contained,	it	contains	no	place	within	
 

	 35.	 EDGEWARE	WHITEPAPER,	supra	note	1,	at	9–15.	
	 36.	 Id.	at	6–7.	
	 37.	 Id.	at	11–12	(“Upon	inspection	[of	the	transaction	hash],	a	verifier	should	have	
enough	proof	that	if	the	owner	of	the	.	.	.	account	did	not	also	own	the	recipient	Edge-
ware	account	(represented	as	the	target	address	.	.	.	),	then	they	would	not	issue	such	
a	transaction.”).	
	 38.	 See	infra	text	accompanying	notes	276–79.	
	 39.	 The	 literature	has	noted	 that	often	 firms	price	bug	bounties	 too	 low	when	
compared	with	their	after-market	(and	illegitimate)	use.	Lorenz	Breidenbach,	Philip	
Daian,	Florian	Tramer	&	Ari	Juels,	Enter	the	Hydra:	Towards	Principled	Bug	Bounties	
and	Exploit-Resistant	Smart	Contracts,	27	PROC.	USENIX	SEC.	SYMP.	1335,	1335	(2018).	
It	 is	difficult	to	know	how	common	self-help	is	 in	the	world	of	transactional	scripts.	
Victims	have	little	incentive	to	publicize	their	failure	to	write	better	code,	while	suc-
cessful	attackers	may	wish	to	avoid	public	renown	(if	not	the	tax	authorities).	
	 40.	 See,	 e.g.,	 Lauren	Henry	Scholz,	Algorithmic	Contracts,	 20	STAN.	TECH.	L.	REV.	
128,	141	(2017)	(discussing	the	application	of	contract	and	agency	law	to	algorithmic	
contracts	and	noting	lack	of	caselaw).	
	 41.	 Cf.	Dell’Erba,	supra	note	20	(manuscript	at	21)	(“It	could	be	that	there	may	be	
a	bug	in	the	code	or	that	the	parties	may	reconsider	what	they	want.”).	
	 42.	 Compare	Werbach	&	Cornell,	 supra	note	26,	at	350–64	(things	going	well),	
with	id.	at	365–67	(not	as	well).	
	 43.	 Wulf	A.	Kaal	&	Craig	Calcaterra,	Crypto	Transaction	Dispute	Resolution,	73	BUS.	
LAW.	109,	136	n.94	(2017–2018).	



326	 MINNESOTA	LAW	REVIEW	 [105:319	

	

it	for	“default	law”	to	exist.44	Worse,	even	if	there	are	places	for	law’s	
tools	to	have	purchase,	jurists	“may	not	be	able	to	hypothesize	a	rea-
sonable	human’s	interpretation	of	a	given	smart	contract.”45	

Such	handwaving	is	an	unwarranted,	and	ultimately	unworkable,	
surrender	of	the	law’s	role	in	adjudicating	disputes.	Code	that	embod-
ies	 commercially-significant	 scripts	will	 inevitably	 contain	ambigui-
ties,	and	disappointed	parties	will	ask	judges	to	adjudicate	their	rights.	
At	the	basic	level,	as	James	Grimmelmann	has	recently	observed,	the	
“meaning	of	any	specific	program	rests	on	a	foundation	of	some	prior	
agreement	about	how	to	interpret	some	larger	class	of	programs.”46	
He	concludes	that	while	there	may	be	fewer	superficial	examples	of	
interpretative	gaps	in	formal	code,	“when	the	bottom	drops	out,	it	can	
really	drop	out.”47	It’s	then	that	law	will	be	asked	to	step	in	and	pro-
vide	rational	and	predictable	solutions,	which	will	almost	certainly	be	
developed	by	analogy	to	off-chain	exchanges.	

But	analogies	can	deceive.	Whereas	scholars	and	jurists	who	con-
front	questions	about	ordinary	written	contracts	have	a	deep	working	
knowledge	of	how	such	exchanges	function,	transactional	scripts	are	
functionally	innovative	and	the	legal	community	has	yet	to	coalesce	
around	even	a	basic	understanding	of	what	they	are,	 let	alone	what	
they	do.	What’s	needed,	then,	is	a	working	knowledge	of	the	ways	in	
which	the	vocabulary	and	functioning	of	the	code	itself	can	create	dis-
connects	 between	 the	 intent	 of	 the	 humans	 coding	 transactional	
scripts	 and	 the	 code’s	 function.48	Describing	 the	 plumbing	 of	 these	
phenomena	is	the	first	contribution	of	this	Article,	and	occupies	Part	
I.	We	make	two	fundamental	observations.		

First,	the	software	language	development	environment	of	almost	
all	extant	 transactional	scripts	has	 features	 (and	entails	uncommon	
practices)	which	make	coding	errors,	and	gaps	between	coders’	intent	

 

	 44.	 Usha	R.	Rodrigues,	Law	and	the	Blockchain,	104	IOWA	L.	REV.	679,	682	(2019)	
(“Because	the	smart	‘contract’	is	code	alone,	there	is	no	gap,	in	the	sense	of	an	entry	
point,	for	the	law	to	step	in	to	fill.”).	
	 45.	 Kaal	&	Calcaterra,	supra	note	43,	at	136;	Schmitz	&	Rule,	supra	note	26,	at	103	
(“Those	with	 no	 coding	 background	 cannot	 easily	 interpret	 a	 smart	 contract	 in	 its	
rawest	form.”).	
	 46.	 Grimmelmann,	supra	note	33,	at	12.	
	 47.	 Id.	at	20	(“The	relevant	community	can	redefine	the	programming	language	
in	a	way	that	radically	alters	the	meaning	of	programs	written	in	it.”).	
	 48.	 On	the	problems	caused	by	blockchain	jargon,	see	Angela	Walch,	Blockchain’s	
Treacherous	Vocabulary:	One	More	Challenge	for	Regulators,	J.	INTERNET	L.,	Aug.	2017,	
at	1.	



2020]	 TRANSACTIONAL	SCRIPTS	 327	

	

and	expression,	both	likely	to	occur	and	difficult	to	resolve.49	Second,	
the	 dominant	 platform	 for	 scripts—Ethereum—assesses	 a	 tax	 on	
complex	programs.	This	fee	makes	transactional	scripts	unsuited	for	
many	knotty	contracting	problems,	unless	their	drafters	make	parts	
of	the	code	non-public,	thus	stripping	scripts	of	much	of	what	makes	
them	an	elegant	solution	to	problems	of	trust	in	exchange.	

With	a	better	grasp	of	how	scripts	operate,	Part	II	uses	case	ex-
amples	 to	 argue—contrary	 to	 the	 dominant	 account—that	 these	
scripts	 fail	 in	ways	that	are	 legible	to	traditional	contractual	 frame-
works.	Put	simply,	they	fail	to	accomplish	their	parties’	intent.	Those	
examples	start	with	“tokens”	issued	in	“initial	coin	offerings,”	continue	
with	decentralized	exchanges,	and	finally	consider	so-called	“oracles.”	
We	describe	both	the	coded	and	natural	language	promises	accompa-
nying	 these	projects.	Each	such	category	of	 transactional	 script	has	
been	 touted	 as	 a	 revolutionary	 financial	 innovation.	 Each,	 as	 we’ll	
show,	have	already	produced	errors	with	real	legal	consequences.		

In	Part	III,	we	ask	how	law	ought	to	respond	to	the	sorts	of	prob-
lems	occasioned	by	such	systematic	failures	of	transactional	scripts.	
We	 argue	 that	 the	 layering	 of	 transactional	 script	 and	 natural	 lan-
guage	promise	is	best	understood	as	producing	a	contract	stack.	Con-
tract	stacks	are	inevitable	when	parties	come	together	to	accomplish	
commercial	ends,	even	if	they	try	their	hardest	to	make	the	code	the	
final	 answer	 to	 all	 their	 problems.	 Collecting	 the	 meager	 extant	
caselaw,	and	deploying	old	fashioned	rules	of	interpretation,	we	offer	
a	novel	framework	through	which	courts	ought	to	compile	such	stacks	
and	thus	make	sense	of	these	new	forms	of	commercial	exchange.		

The	framework	we	offer,	though	focused	on	the	scripted	ecosys-
tem	of	the	moment,	has	general	application.	Future	iterations	of	digit-
ized	 transactions,	whether	using	blockchain	or	 other	 forms	of	 soft-
ware,	 will	 require	 courts	 to	 make	 sense	 of	 gaps	 between	 natural	
language	 promises	 and	 coded	 executions.	 Our	 approach	 brings	 old	
principles	of	common	law	to	bear	on	the	problems	that	the	next	gen-
eration	of	contract	practitioners	and	academics	will	face.	

 

	 49.	 See	Elaine	Ou,	Blockchain	Is	Littered	with	‘Smart’	Contracts	Gone	Bad:	Opinion,	
INS.	 J.	 (Nov.	 16,	 2017),	 https://www.insurancejournal.com/news/international/	
2017/11/16/471387.htm	[https://perma.cc/P5MF-67N3].	



328	 MINNESOTA	LAW	REVIEW	 [105:319	

	

I.		DESIGNING	EXPENSIVE,	BUGGY	SCRIPTS			
We	begin	with	a	precise	account	of	the	creation	and	function	of	

transactional	scripts.	To	the	extent	that	the	discussion	requires	strug-
gling	with	new	jargon,	our	petard	has	been	well-hoisted.50	Our	goal	is	
not	merely	to	demystify	this	technology,	but	also	the	world	and	social	
practices	of	coders	whose	work	increasingly	matters	to	law	and	trans-
actional	practice.	We	make	two	primary	contributions.	First,	we	try	to	
explain	why	code	is	intrinsically	buggy.	Second,	we	offer	some	reasons	
to	 be	 skeptical	 about	 scripts’	 innate	 ability	 to	 simultaneously	 solve	
problems	of	trust,	complexity	and	automation	of	deals.	

	We	 start	with	 the	 functional	 question	of	how	coders	 go	 about	
their	work.	

A. HOW	(COMMERCIAL)	CODING	WORKS	
The	process	of	taking	a	programmer’s	intent	from	code	to	execu-

tion	involves	multiple	steps,	each	of	which	can	and	does	introduce	er-
ror.	Just	as	when	law	firms	draft	contracts,	programming	progresses	
in	 pieces	 and	 through	 teams. 51 	Programming	 teams	 typically	 start	
with	a	human-driven	goal.	They	then	choose	a	language	in	which	to	
code.	Typically,	coders	will	choose	a	high-level	language	that	abstracts	
away	the	details	of	the	machine’s	hardware	and	allows	programming	
in	syntax	closer	to	natural	language.	

Transactional	 scripts	 are	 commonly	 coded	 in	 Solidity,	 the	 lan-
guage	conceived	alongside	of,	and	for	use	on,	Ethereum,	the	platform	
on	which	most	scripts	operate.52	It	is	syntactically	similar	to	the	pop-
u";"""date"",""2020-12-02T18:40:10Z""
""pdf:PDFVersion"",""1.7""
""xmp:CreatorTool"",""Appligent AppendPDF Pro 6.3""
""pdf:docinfo:title"",""Transactional Scripts in Contract Stacks""
""Appligent"",""AppendPDF Pro 6.3 Linux 64 bit Aug 30 2019 Library 15.0.4""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""language"",""en""
""dc:format"",""application/pdf; version=1.7""
""pdf:docinfo:creator_tool"",""Appligent AppendPDF Pro 6.3""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""Transactional Scripts in Contract Stacks""
""xmp:CreateDate"",""2020-12-02T10:40:10Z""
""modified"",""2020-12-02T18:40:10Z""
""pdf:hasMarkedContent"",""true""
""xmp:ModifyDate"",""2020-12-02T10:40:10Z""
""pdf:docinfo:creator"",""Shaanan Cohney and David A. Hoffman""
""meta:author"",""Shaanan Cohney and David A. Hoffman""
""meta:creation-date"",""2020-12-02T18:40:10Z""
""created"",""2020-12-02T18:40:10Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-12-02T18:40:10Z""
""resourceName"",""viewcontent.cgi""
""Author"",""Shaanan Cohney and David A. Hoffman""
""producer"",""Prince 12.5 (www.princexml.com)""
""pdf:docinfo:producer"",""Prince 12.5 (www.princexml.com)""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""access_permission:modify_annotations"",""true""
""dc:creator"",""Shaanan Cohney and David A. Hoffman""
""dcterms:created"",""2020-12-02T18:40:10Z""
""Last-Modified"",""2020-12-02T18:40:10Z""
""dcterms:modified"",""2020-12-02T18:40:10Z""
""pdf:docinfo:custom:Appligent"",""AppendPDF Pro 6.3 Linux 64 bit Aug 30 2019 Library 15.0.4""
""title"",""Transactional Scripts in Contract Stacks""
""xmpMM:DocumentID"",""uuid:6efa13af-aff8-11b2-0a00-2042e7000000""
""Last-Save-Date"",""2020-12-02T18:40:10Z""
""pdf:docinfo:modified"",""2020-12-02T18:40:10Z""
""meta:save-date"",""2020-12-02T18:40:10Z""
""Content-Length"",""1823499""
""Content-Type"",""application/pdf""
""xmp:MetadataDate"",""2020-12-02T10:40:10Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Shaanan Cohney and David A. Hoffman""
""dc:language"",""en""
""pdf:producer"",""Prince 12.5 (www.princexml.com)""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""69""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""1260"",""2931"",""2756"",""3288"",""2895"",""3219"",""3206"",""3128"",""2726"",""2459"",""2887"",""3154"",""2687"",""3226"",""2644"",""3001"",""2437"",""3659"",""3314"",""3044"",""2803"",""3308"",""3125"",""826"",""2306"",""2899"",""3291"",""2849"",""2761"",""1994"",""2408"",""2615"",""2872"",""3088"",""3099"",""2288"",""1868"",""3162"",""3176"",""2319"",""2392"",""2850"",""2592"",""2297"",""2851"",""2244"",""3187"",""3099"",""2950"",""2605"",""2812"",""2860"",""2706"",""3055"",""3198"",""3225"",""770"",""2843"",""2899"",""2502"",""3204"",""2214"",""1738"",""2992"",""3158"",""2914"",""3047"",""2933"",""1603""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-12-02T18:40:10Z""
";https://scholar.google.ch/scholar?start=590&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098822-233;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Tightly-secure two-pass authenticated key exchange protocol using twin Diffie–Hellman problem;R Zeng, L Wang ; IET Information Security, 2020  IET;;"… In CRYPTO 2018, Gjřsteen and Jager proposed a tightly-secure authenticated key

exchange (AKE) protocol … Page 2. these instances in all fresh oracles, respectively

(since every fresh oracle is possible to be a challenge oracle) …";Autres articles;;[HTML] wiley.com;https://ietresearch.onlinelibrary.wiley.com/doi/full/10.1049/iet-ifs.2020.0047;;;https://scholar.google.ch/scholar?start=780&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098897-404;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;BASE32-KODIERUNG;B BUNNY ; Springer;;"… andere Informationen. BLOCKCHAIN AS A SERVICE [BAAS] (engl.). Von Microsoft, Oracle und

anderen Firmen offerierte Lösung, um Blockchain in Firmen aufzubauen, ohne sich um die

Grundlagen kümmern zu müssen. BLOCKCHAIN SECURITY (engl.). Übsg …";;null;null;;;;https://scholar.google.ch/scholar?start=950&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098818-229;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Efficient and Secure Implementation of BLS Multisignature Scheme on TPM;M Hedabou, YS Abdulsalam ; 2020 IEEE International …, 2020  ieeexplore.ieee.org;;"… With the use of any cryptocurrency wallets, the best mea- sures for securing cryptographic keys

is … The security of the protocol was proven in the random oracle model under the static … In lights

of quantum attacks and the possibility of quantum breaches on blockchain networks, [8 …";Autres articles;;null;;;;https://scholar.google.ch/scholar?start=770&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098866-337;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Practical escrow protocol for bitcoin;X Yang, WF Lau, Q Ye, MH Au, JK Liu… ; IEEE Transactions on …, 2020  ieeexplore.ieee.org;;"… Bob can publish (T,?) on the blockchain to receive the bitcoins … Camenisch and Damgard proposed

a construction without random oracle [5] while Camenisch and Shoup [6] proposed … first verifiably

encrypted signature scheme without random oracles from Water's signature [12 …";Cité 1 fois;Les 2 versions;null;;;;https://scholar.google.ch/scholar?start=880&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098875-352;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;How to dynamically incentivize sufficient level of IoT security;J Su, M Bartholic, A Stange, R Ushida… ; … Conference on Financial …, 2020  Springer;;"… In: Menezes, A. (ed.) CRYPTO 2007 … https://doi.org/10.1007/978-3-540-74143-5_4. 6. Cao, N.,

O'Neill, A., Zaheri, M.: Toward RSA-OAEP without random oracles … https://doi.org/10.1007/978-

3-030-45374-9_10. 7. Finck, M.: Blockchain Regulation and Governance in Europe …";Cité 3 fois;Les 2 versions;null;;;;https://scholar.google.ch/scholar?start=900&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098879-364;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;????????;??? ???? ??? ???? ???? ??? ; ?????????  infocommjournal.com;;"… lost in transfer? ????????stack size limit??? Blockchain ????????????????

?unpredictable … ??????????? ???????????????????

????????????????????? ?????????Oracle [41] ?RealityKeys [42 …";Autres articles;;[PDF] infocomm-journal.com;http://www.infocomm-journal.com/cjnis/CN/article/downloadArticleFile.do?attachType=PDF&id=170344;;;https://scholar.google.ch/scholar?start=910&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098787-155;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;La responsabilité civile des acteurs du contrat intelligent;C Francčs ;2020 papyrus.bib.umontreal.ca;;"… Aoűt 2017, no 3 (26 juillet 2017): 6?9. 5 Communément appelées aussi Ť crypto monnaies ť :

Bitcoin … contractantes, le programmeur, l'auditeur, l'oracle, les avocats27, etc … 26Aaron WRIGHT

et Primavera DE FILIPPI, Ť Decentralized Blockchain Technology and the Rise of Lex …";Autres articles;Version HTML;[PDF] umontreal.ca;https://papyrus.bib.umontreal.ca/xmlui/bitstream/handle/1866/23937/Frances_Clemence_2019_memoire.pdf?sequence=2;"
 

 

UniversitĂŠ de MontrĂŠal 
 
 
 
 
 
 
 

La responsabilitĂŠ civile des acteurs du contrat intelligent 
 
 
 
 
 

par  

ClÊmence Francès 

 

 

 

  
FacultĂŠ de Droit 

 
 
 
 
 
 

MĂŠmoire prĂŠsentĂŠ Ă  la FacultĂŠ des ĂŠtudes supĂŠrieures 
en vue de l’obtention du grade de Maitrise 

en Droit des Technologies de l’Information (LL.M) 
 
 
 
 
 

AoĂťt, 2019 
 
 
 
 
 

Š ClÊmence Francès, 2019



 

i 

 

RĂŠsumĂŠ 
 

 

Les contrats intelligents sont des programmes informatiques qui s’exécutent d’eux-

mêmes dès lors que certaines conditions, dÊterminÊes au prÊalable par les parties, sont remplies. 

Ce type de contrat est rÊcemment entrÊ dans une nouvelle ère suite à la dÊmocratisation des 

cryptomonnaies, notamment le Bitcoin et sa technologie sous-jacente ; la chaĂŽne de blocs. Celle-

ci se dĂŠfinit comme un registre virtuel rĂŠpertoriant des historiques de transactions, permettant 

entre autres de réaliser des transferts d’actifs de pair à pair, sans intermédiaire. Désormais, la 

chaÎne de blocs est aussi capable de servir de support au contrat intelligent, ce qui soulève de 

nouvelles problĂŠmatiques juridiques.    

 

En raison de sa nature, il est possible que le contrat intelligent puisse causer un prĂŠjudice 

en cas de mauvaise ou de non-exĂŠcution. Le prĂŠsent mĂŠmoire consiste Ă  dĂŠterminer 

l’applicabilité du régime de responsabilité civile à ce type de contrat, au regard des dispositions 

du Code civil du QuĂŠbec et de la Loi concernant le cadre juridique des technologies de 

l’information.    

 

 

Mots-clés : Chaine de blocs – Contrats intelligents – Responsabilité – Dommage – Contrats – 

Intelligence artificielle  

  



 

ii 

 

Abstract 
 

Smart contracts are computer programs that run on their own when conditions, previously 

determined by the parties, are met. This type of contract has recently entered a new era following 

the democratization of cryptocurrencies, especially Bitcoin and its underlying technology; the 

Blockchain. It’s a virtual register listing transaction history, making it possible, among other 

things, to carry out asset transfers from peer to peer without any intermediary. Now, the 

blockchain is also able to support smart contracts, which raises new legal issues. 

 

Due to its nature, it is possible that the smart contract may cause damage in case of bad or 

non-performance. The purpose of this paper is to determine the applicability of the civil liability 

regime to this type of contract, in light of the provisions of the Civil Code of Quebec and the Act 

to establish a legal framework for information technology. 

 

 

Keywords: Blockchain – Smart contract – Liability – Damage – Contracts – Artificial 

Intelligence  



 

iii 

Table des matières 
RĂŠsumĂŠ ......................................................................................................................................... i 

Abstract ....................................................................................................................................... ii 

Table des matières ...................................................................................................................... iii 

Liste des figures .......................................................................................................................... v 

Liste des sigles et abrĂŠviations ................................................................................................... vi 

Introduction ................................................................................................................................. 1 

I. Le contrat intelligent ........................................................................................................... 8 

A. La formation du contrat intelligent ................................................................................. 8 

1. La chaine de blocs : une technologie de stockage et de transmission d’informations 

ou de transactions ................................................................................................................ 9 

a. La construction d’une chaine de blocs .................................................................. 11 

b. DiffĂŠrents types et usages de la chaine de blocs ................................................... 17 

2. Un contrat Ă  exĂŠcution automatique ......................................................................... 25 

a. DĂŠfinition et applications du contrat intelligent .................................................... 26 

b. Les apports de la chaine de blocs au contrat intelligent sur le plan juridique ...... 31 

B. Les acteurs du contrat intelligent .................................................................................. 37 

1. Contrat intelligent et statut juridique ........................................................................ 38 

a. La qualification juridique du contrat intelligent ................................................... 38 

b. Règlementation et contrat intelligent .................................................................... 45 

2. Les intervenants Ă  la rĂŠalisation du contrat intelligent .............................................. 50 

a. Les principaux intervenants au contrat intelligent ................................................ 50 

b. L’Oracle : un frein à la décentralisation ? ............................................................. 59 

II. Le partage de responsabilité en cas de mauvaise exécution d’un contrat intelligent ........ 61 

A. Dans le cas d’un dommage causé par une erreur survenue lors de la mise en place du 

contrat intelligent .................................................................................................................. 63 

1. L’engagement de la responsabilité des parties dans le contrat intelligent ................ 64 

a. L’exemple de la machine distributrice .................................................................. 64 

b. La responsabilitĂŠ des cocontractants du contrat intelligent .................................. 69 

2. L’engagement de la responsabilité du programmeur ou de l’auditeur ..................... 72 



 

iv 

a. L’engagement de la responsabilité du programmeur dans le contrat intelligent .. 72 

b. Le cas d’un contrat intelligent validé par un auditeur ........................................... 81 

B. Dans le cas d’un dommage causé par une erreur d’exécution du contrat intelligent .... 84 

1. L’engagement de la responsabilité de l’oracle dans le contrat intelligent ................ 85 

a. Dans le cas où l’oracle donne une information erronée ........................................ 86 

b. Le cas d’une entente réalisée entre les parties et l’oracle ..................................... 91 

2. Les solutions envisageables pour l’encadrement juridique du contrat intelligent .... 94 

a. Vers quel type de règlementation pour le contrat intelligent ? ............................. 95 

b. La solution de l’ajout de clauses contractuelles dans le contrat intelligent .......... 96 

Conclusion ................................................................................................................................ 99 

Bibliographie ........................................................................................................................... 104 

Table de la jurisprudence ........................................................................................................ 110 

Table de la lĂŠgislation ............................................................................................................. 112 

 

 



 

v 

Liste des figures  
Figure 1. Le processus d’envoi d’une transaction via la chaine de blocs ............................ 12 

Figure 2. La formation d’une chaine de blocs ...................................................................... 15 

Figure 3. Arbre de dĂŠcision entre les diffĂŠrents types de chaines de blocs .......................... 21 

Figure 4. Plusieurs applications dĂŠcentralisĂŠes sur une plateforme Ethereum ..................... 24 

Figure 5. Exemple de codage simplifié d’un contrat de vote sur le logiciel EtherScripter .. 53 

Figure 6. Schéma simplifié d’un contrat intelligent dans le cas d’un testament .................. 57 

Figure 7. L’exemple de la machine distributrice en tant que contrat intelligent .................. 65 

Figure 8. Exemple d’une procédure d’audit intégrée au contrat intelligent ......................... 82 

  

  



 

vi 

Liste des sigles et abrĂŠviations  
 

Termes relatifs à la lÊgislation et à la règlementation :  

 

al. : AlinĂŠa 

art. : Article 

C.c.Q. : Code civil du QuĂŠbec 

etc. : Et cĂŚtera 

L.C. : Lois du Canada (depuis 1987) 

L.C.C.J.T.I. : Loi concernant le cadre juridique des technologies de l’information 

L.Q. : Lois du QuĂŠbec (depuis 1969) 

L.R.C. : Lois rĂŠvisĂŠes du Canada (depuis 1985) 

L.R.Q. : Lois refondues du QuĂŠbec (depuis 1977) 

no. : NumĂŠro 

R.G.P.D. : Règlement gÊnÊral sur la protection des donnÊes 

U.E. : Union EuropĂŠenne 

 

Termes relatifs Ă  la jurisprudence :  

 

C.A. : Cour d’appel (du Québec) 

C.Q. : Cour du QuĂŠbec 

C.S. : Cour supĂŠrieure 

QCCA : Cour d’appel du Québec 

QCCQ : Cour du QuĂŠbec 



 

vii 

QCCS : Cour supĂŠrieure du QuĂŠbec 

R.C.S. : Recueils de la Cour suprĂŞme du Canada 

R.D.I. : Recueils de droit immobilier 

R.R.A. : Recueils de droit en responsabilitĂŠ et assurance 

 

Revues juridiques et technologiques : 

 

C.P.I. : Cahiers de propriĂŠtĂŠ intellectuelle 

R. de. J. : Revue de jurisprudence 

R. du. B. : Revue du barreau du QuĂŠbec 

R.D.J. : Revue de droit juridique 

R.J.T. : Revue juridique ThĂŠmis 

R.L.D.I : Revue Lamy droit de l’immatériel 

SSRN Electronic Journal : Social Science Research Network Electronic Journal 

 

Termes relatifs aux technologies de l’information :  

 

D.A.p.p. : Data Acquisition and Processing Program 

D.L.T. : Distributed Ledger Technology 

I.C.O. : Initial Coin Offering 

 

Autres termes : 

I.S.D.A. : International Swaps and Derivates Associations 

I.R.D.A.: Institut de recherche de droit des affaires 



 

 1 

Introduction 
 

La technologie de la chaine de blocs1 suscite depuis quelques annĂŠes une grande curiositĂŠ, 

que ce soit par les particuliers, les entreprises, ou encore les États. Si elle est parfois présentée 

comme « la machine de confiance qui, au-delà du Bitcoin, pourrait changer le monde »2, d’autres 

l’envisagent au mieux comme un effet de mode ou au pire comme un « grand mensonge »3.  

 

Aujourd’hui la confiance présente dans les transactions entre acteurs repose principalement sur 

un système centralisÊ. En effet les acteurs placent leur confiance dans une entitÊ reconnue par 

tous (le notaire, l’État, une institution bancaire, etc). Le tiers de confiance choisi par les acteurs 

est alors le seul à pouvoir modifier ou mettre à jour le registre de transactions qu’il détient afin 

de garantir la sécurité et limiter la fraude4. Avec l’apparition des monnaies virtuelles5, on a 

constatÊ que le règlement des transactions pouvait se faire de manière dÊcentralisÊe, et ce grâce 

Ă  la technologie de la chaine de blocs. Comme le mentionne Drescher dans son ouvrage6, ce qui 

suscite l’intérêt grandissant pour la chaine de blocs, c’est cette possibilité de désintermédiation 

des transactions : 

 

ÂŤ The relation between purely distributed peer-to-peer systems to the blockchain is that 

the former uses the latter as a tool to achieve and maintain integrity. Hence, the argument 

that explains the excitement about and the potential of the blockchain is: Purely distributed 

 
1 La chaine de blocs est définie par l’institut Blockchain France comme « une technologie de stockage et de 
transmission d’informations, transparente, sécurisée, et fonctionnant sans organe central de contrôle ». Définition 
disponible sur le site https://blockchainfrance.net/decouvrir-la-blockchain/c-est-quoi-la-blockchain/. Les auteurs 
utilisent communĂŠment la traduction anglaise ÂŤ blockchain Âť pour dĂŠsigner cette technologie. Dans ce travail, nous 
utiliserons le terme de ÂŤ chaine de blocs Âť. 
2 The Economist, “The Trust Machine, How the technology behind bitcoin could change the world”, 31 octobre, 6 
novembre 2015, n° 44.  
3 Nouriel NOURIBI, ÂŤ Le grand mensonge de la blockchain Âť, Project Syndicate, 15 octobre 2018  
4 Côme BERBAIN, « La blockchain : concept, technologies, acteurs et usages », Annales des Mines - Realites 
industrielles Août 2017, no 3 (26 juillet 2017): 6‑9. 
5 CommunĂŠment appelĂŠes aussi ÂŤ crypto monnaies Âť : Bitcoin, Ethereum, Ripple, Litecoin, Dash, etc. 
6 Daniel DRESCHER, Blockchain basics. Berkeley, CA : Apress, 2017. 



 

2 

peer-to-peer systems have a huge commercial potential as they can replace centralized 

systems and change whole industries due to disintermediation. Âť7 

 

La première utilisation d’une chaine de blocs, et aujourd’hui la plus connue, est apparue en 2009 

avec la cryptomonnaie Bitcoin8. Connus sous le pseudonyme de Satoshi Nakamoto9, le ou les 

initiateurs de ce rĂŠseau avaient pour intention de crĂŠer une monnaie qui puisse contourner le 

système bancaire et plus largement le domaine financier qui avait perdu en crÊdibilitÊ depuis la 

crise financière de deux mille huit10 dans le but de contourner le problème de la double 

dĂŠpense comme le mentionne son crĂŠateur lors de la description de son invention11 : 

 

ÂŤ What is needed is an electronic payment system based on cryptographic proof instead 

of trust, allowing any two willing parties to transact directly with each other without the 

need for a trusted third party. Transactions that are computationally impractical to 

reverse would protect sellers from fraud, and routine escrow mechanisms could easily 

be implemented to protect buyers. Âť - Satochi Nakamoto. 

 

Cette cryptomonnaie repose sur un système de transactions enregistrÊes sur un grand livre de 

compte accessibles Ă  tous sur le rĂŠseau : une chaine de blocs. Pour utiliser ce rĂŠseau, il suffit 

pour un utilisateur d’accéder à un logiciel, de se créer un compte, et d’échanger sa monnaie 

traditionnelles (dollars, euros ou autres) contre des bitcoins afin de pouvoir commencer les 

transactions12. Il peut conserver ou utiliser ses bitcoins à partir d’une « adresse », c’est-à-dire 

une chaine de caractères qui correspond en quelque sorte à un numÊro de compte, auquel sont 

associĂŠs une clĂŠ privĂŠe qui permet Ă  son dĂŠtenteur de dĂŠpenser les bitcoins, et une clĂŠ publique 

 
7 Ibid. 
8« Unité monétaire d'un système de paiement virtuel permettant à une communauté d’utilisateurs d’échanger entre 
eux des biens et des services sur Internet Âť https://www.larousse.fr/dictionnaires/francais/bitcoin/10911016 
9 Consulter le site https://fr.wikipedia.org/wiki/Satoshi_Nakamoto 
10 Consulter le site https://www.thecanadianencyclopedia.ca/fr/article/recession-of-200809-in-canada 
11Satochi NAKAMOTO, ÂŤ Bitcoin : A Peer-to-Peer Electronic Cash System Âť. En ligne : 
https://bitcoin.ord/bitcoin.pdf 
12 Pierre-Henri FAURE, « Le bitcoin peut-il être assimilé à une monnaie ? Un examen à partir des différentes grilles 
de lecture de la science ĂŠconomique Âť (2016), https://hal.archives-ouvertes.fr/hal-01337694. 



 

3 

destinée à recevoir des paiements13. Une fois la transaction validée par l’ensemble du réseau à 

l’aide de la résolution de calculs cryptographiques complexes, elle est ajoutée sur la chaine de 

blocs.  

 

A ses dĂŠbuts, la chaine de blocs ĂŠtait uniquement considĂŠrĂŠe comme la technologie supportant 

le rÊseau bitcoin14 mais il ne fallut que très peu de temps pour voir Êvoluer la chaine de blocs 

vers d’autres utilisations que les cryptomonnaies, tel que le stockage sécurisé de dossiers 

sensibles, ou encore la création de contrats intelligents, notamment à l’aide de la plateforme 

Ethereum ; une autre crypomonnaie permettant, en plus du transfert d’actifs, de mettre en place 

ce nouveau type de contrats. C’est précisément sur cette forme d’utilisation de la chaine de 

blocs, Ă  savoir la crĂŠation de contrats intelligents, que ce mĂŠmoire portera.  

 

En 1997, le cryptographe amĂŠricain Nick Szabo publiait un article intitulĂŠ ÂŤ The idea of Smart 

Contracts »15 où il développait l’idée des contrats intelligents, à savoir des clauses contractuelles 

traduites dans des programmes informatiques. Pour expliquer son idée, il donne l’exemple de la 

machine distributrice ; un contrat qui s’exécute de façon automatisée et sans intermédiaire16. En 

effet, nous verrons que la machine distributrice est un contrat intelligent. Pour reprendre la 

définition officielle de l’entité Blockchain Partner, une société de conseil et de recherche sur les 

technologies de la chaine de blocs, les contrats intelligents sont : 

 

ÂŤ Des programmes autonomes qui, une fois dĂŠmarrĂŠs, exĂŠcutent automatiquement des 

conditions dĂŠfinies au prĂŠalable et inscrites dans la chaine de blocs. Ils fonctionnement 

comme toute instruction conditionnelle de type « if – then » (si telle condition est vérifiée, 

alors telle conséquence s’exécute) »17.  

 
13 En consultation sur le site https://bitcoin.fr/Qu-est-ce-que-Bitcoin/ 
14 Ce site monte le rĂŠseau bitcoin en temps rĂŠel : https://www.blockchain.com/explorer 
15 Nick SZABO, “The idea of smart contracts”. Nick Szabo’s Papers and Concise Tutorials, 1997, vol. 6. 
16 Ibid. 
17 Définition issue du site officiel de l’entité Blockchain Partner : https://blockchainfrance.net/nos-experts-
blockchain/ 



 

4 

 

Dans notre quotidien nous contractualisons sans mĂŞme nous en rendre compte. Cette 

technologie permet aux cocontractants de réaliser des transactions de façon anonyme s’ils le 

souhaitent et sans intermĂŠdiaire18. Un contrat intelligent peut ĂŞtre enregistrĂŠ sur une chaine de 

blocs, ce qui permet de rendre non modifiable le contrat (du moins plus difficilement), et les 

termes du contrat sont alors protÊgÊs selon le système de vÊrification intrinsèque à la chaine de 

blocs19 comme nous le verrons ci-après20. Ainsi, mettre en place des contrats intelligents pourrait 

réduire le risque de fraude, les coûts d’exécution et de suivi, mais surtout en faciliter l’exécution 

puisque celle-ci devient entièrement autonome. En effet, l’automatisation constitue l’une des 

force de ce type de contrat puisqu’elle permet de limiter le risque d’erreur humaine dans 

l’exécution des clauses contractuelles, et donc limiterait le risque de contentieux. Aussi, la 

résiliation d’un contrat intelligent reposant sur la chaîne de blocs est théoriquement impossible, 

sauf si le motif de rupture a ĂŠtĂŠ prĂŠalablement envisagĂŠ et codifiĂŠ dans le contrat ; ce qui permet 

de limiter les révocations injustifiées. Cependant, comme toute autre technologie, celle-ci n’est 

pas parfaite et nous verrons qu’elle présente certaines failles. Par exemple, la difficile résiliation 

prĂŠsentĂŠe comme un avantage pour certains, sera considĂŠrĂŠe comme un inconvĂŠnient, 

notamment si les parties souhaitent modifier les termes du contrat.  

 

Aux États-Unis, certains états21 ont récemment choisi d’adopter quelques dispositions légales 

pour le contrat intelligent. Par exemple l’art. 47-10-201 al. 2 du Tennessee Code22 définit le 

ÂŤ smart contract Âť comme :  

 

 
18 Alexander SAVELYEV, « Contract Law 2.0: “Smart” Contracts as the Beginning of the End of Classic Contract 
Law Âť, (2017) 
19 Vincenzo MORABITO, ÂŤ Smart Contracts and Licensing Âť, dans Business Innovation Through Blockchain, 
Springer International Publishing AG 2017, c. 6, p. 121. 
20 Se référer au paragraphe 1.a de la première partie : la construction d’une chaine de blocs.  
21 Notamment le Tennessee, l’Arizona, l’Ohio. 
22 Tenn. Code Ann. § 47-10-201 (Lexis Advance through the 2018 Regular Session) 



 

5 

ÂŤ An event-driven computer program, that executes on an electronic, distributed, 

decentralized, shared, and replicated ledger that is used to automate transactions, 

including, but not limited to, transactions that: (A)  Take custody over and instruct transfer 

of assets on that ledger; (B)  Create and distribute electronic assets; (C)  Synchronize 

information; or (D)  Manage identity and user access to software applications. Âť. 

 

Ce qui rend ce type de contrat intelligent innovant et diffĂŠrent de la machine distributrice que 

mentionne Nick Szabo23, c’est que les cocontractants peuvent user de la technologie de la chaine 

de blocs pour tenter de rendre le contrat plus sĂŠcurisĂŠ et non modifiable. En effet, nous verrons 

dans ce mĂŠmoire que certains contrats intelligents utilisent la cryptographie via la chaine de 

blocs, d’autres non24. Dans certains cas, pour s’exécuter, le contrat intelligent aura besoin 

d’intégrer une variable externe et les répercussions de son exécution sera implémenté à la chaine 

de blocs. Dans l’exemple d’un contrat intelligent programmé pour mettre en place une assurance 

en cas de retard d’avion, le contrat aura besoin d’aller chercher la variable externe qui 

déclenchera le contrat, à savoir les horaires d’arrivées sur le site officiel de la compagnie 

aérienne concernée ; c’est le rôle de l’oracle qui intégrera l’information extérieure à la chaine 

de blocs et permettra au contrat, lié à cette dernière, de s’exécuter25. Nous y reviendrons lorsque 

nous aborderons les diffĂŠrents intermĂŠdiaires dans le contrat intelligent.  

 

L’avènement de la technologie de la chaine de blocs et des registres distribués a mis en lumière 

les opportunitĂŠs que peuvent apporter les contrats intelligents. Nous prenons le parti de traiter 

principalement, dans ce mĂŠmoire, des contrats intelligents qui reposent sur une chaine de blocs 

car ils sont une rÊalitÊ qui soulève de nouvelles questions juridiques que les contrats intelligents 

classiques ne posaient pas. Comme le font remarquer Wright et De Filippi, les utilisations du 

contrat intelligent ne cessent d’évoluer :  

 

 
23 Nick SZABO, prĂŠc.. note 15 
24 Cette distinction est expliquée en partie I. À noter que nous évoquerons exclusivement les contrats intelligents 
utilisant la cryptographie, Ă  la diffĂŠrence des contrats intelligents classiques tels que la machine distributrice. 
25 ANTONOPOULOS, Andreas M. et WOOD, Gavin. “Mastering ethereum: building smart contracts and dapps.” 
O'Reilly Media, 2018. 



 

6 

ÂŤ To date, smart contracts have mostly been created to automatically execute derivatives, 

futures, swaps, and options. Yet, they are also being used to facilitate the sale of goods 

between unrelated people on the Internet without the need for a centralized 

organization. Âť26 

 

Au regard de l’émergence considérable de ce type de technologie de plus en plus complexe et 

pouvant prendre des dĂŠcisions autonomes, les tribunaux ne se sont pas encore positionnĂŠs sur la 

question de savoir s’il devient nécessaire, en cas de dommage causé, de faire évoluer le droit ou 

s’il est possible de l’appliquer en l’état. En effet, en cas de litige concernant un contrat 

traditionnel, les juges se tournent normalement vers les clauses inscrites dans le contrat. Or dans 

un contrat intelligent, ces clauses sont ĂŠcrites sous la forme de donnĂŠes numĂŠriques. Dans sa 

dĂŠcision, le juge doit non seulement prendre en compte les composantes purement 

technologiques du contrat, mais aussi dĂŠterminer les principes du droit applicables au cas 

d’espèce. Pour les juges, l’un des principaux défis à relever est la question de la responsabilité 

lorsque la chaÎne de blocs ou un contrat intelligent est impliquÊ. Leur caractère dÊcentralisÊ, 

c’est-à-dire sans intermédiaire ni gouvernance, soulève la question de savoir à qui revient la 

responsabilité en cas de litige. À première vue, puisqu’une multitude d’agents ont le contrôle de 

la chaĂŽne de blocs, personne ne peut ĂŞtre tenu responsable, ce qui constitue une position juridique 

difficilement tenable.  

 

Notre ĂŠtude consistera, dans un premier temps, Ă  dĂŠfinir le contrat intelligent ainsi que la chaine 

de blocs, technologie sur laquelle celui-ci peut ĂŞtre implĂŠmentĂŠ. Dans un second temps, nous 

nous pencherons exclusivement sur les principes de responsabilitĂŠ civile applicables aux cas de 

dommages causés par la mauvaise exécution ou l’inexécution d’un contrat intelligent. En effet, 

plusieurs acteurs peuvent prendre part à l’élaboration d’un contrat intelligent : les parties 

contractantes, le programmeur, l’auditeur, l’oracle, les avocats27, etc. Cette énumération non 

 
26Aaron WRIGHT et Primavera DE FILIPPI, ÂŤ Decentralized Blockchain Technology and the Rise of Lex 
Cryptographia », SSRN Electronic Journal, 2015, https://doi.org/10.2139/ssrn.2580664. À noter que le terme de 
ÂŤ registre dĂŠcentralisĂŠ Âť est utilisĂŠ pour la chaine de blocs dans le sens oĂš les donnĂŠes ĂŠchangĂŠes ne transitent pas 
par une seule entité ou ordinateur central et sont enregistrées dans des blocs stockés au sein d’une chaine.  
27 Nous ne mentionnerons pas la responsabilitĂŠ des avocats dans ce mĂŠmoire car le droit positif relatif Ă  la 
responsabilité professionnelle s’appliquera en cas de manquement. 



 

7 

exhaustive constitue les intermédiaires susceptibles d’être responsables d’un préjudice subi par 

un cocontractant ou un tiers dans le cadre d’un contrat intelligent. 

 

Dans un premier temps nous prĂŠsenterons les technologies de la chaine de blocs et du contrat 

intelligent (lorsqu’il est associé à cette dernière) dans leur aspect technique. Puis nous 

dĂŠterminerons le droit applicable au QuĂŠbec au regard du Code civil du QuĂŠbec et de la Loi 

concernant le cadre juridique des technologies de l’information. Pour cela, l’émission de 

différentes hypothèses permettra répondre à la question de savoir si, à défaut d’un cadre 

juridique clairement ĂŠtablit au sujet des contrats intelligents, le droit positif serait applicable en 

termes de responsabilité des intermédiaires participants à l’élaboration du contrat intelligent.  

  



 

8 

 

I. Le contrat intelligent 
 

Les chaines de blocs et les contrats intelligents ne sont que le résultat de l’évolution de 

technologies prÊexistantes. Si la chaine de blocs a pris son essor en partie grâce à la monnaie 

numérique bitcoin28, elle est aujourd’hui envisagée par les entreprises, les États, ou même les 

particuliers, pour d’autres utilisations que le transfert d’actifs comme, par exemple, la traçabilité 

de produits alimentaires29. Le contrat intelligent30, et la possibilité d’intégration de ses 

rĂŠpercussions sur une chaine de blocs, permet de crĂŠer des programmes autonomes qui exĂŠcutent 

les termes d’un contrat, sans nécessiter d’intervention humaine une fois déclenchés31. Afin de 

mieux cerner le contexte dans lequel ceux-ci ĂŠvoluent, il semble nĂŠcessaire, dans les cas oĂš les 

parties décident d’associer le contrat intelligent à une chaine de blocs, de connaitre le 

fonctionnement et les apports de cette nouvelle technologie aux contrats intelligents. Nous 

identifierons ensuite les acteurs intervenants dans l’élaboration d’un contrat intelligent et nous 

intĂŠresserons Ă  sa formation pour connaitre les enjeux technologiques et juridiques que 

l’utilisation du contrat intelligent implique, notamment en termes de responsabilité.  

 

A. La formation du contrat intelligent 

 

C’est en grande partie en raison de la popularité du réseau Bitcoin que la chaine de blocs32, 

technologie de stockage et de transmission d’informations ou de transactions33, s’est faite 

 
28 Satoshi NAKAMOTO, prĂŠc., note 11  
29 Le géant de la distribution Walmart aux Etats-Unis, a décidé d’assurer, d’ici septembre 2019, la traçabilité des 
fruits et légumes avec l’aide de la technologie blcokchain. Plus de précisions en ligne sur le site 
https://www.placecrypto.fr/blockchain/walmart-mise-sur-la-blockchain-pour-ameliorer-la-tracabilite-des-fruits-
et-legumes-10972/ 
30 Le terme anglophone de ÂŤ Smart Contract Âť est aussi souvent utilisĂŠ par les auteurs pour dĂŠcrire cette technologie. 
31 Consulter le site https://blockchainfrance.net/decouvrir-la-blockchain/c-est-quoi-la-blockchain/ 
32 Pour rappel, la chaîne de blocs est une technologie de stockage et de transmission d’informations, transparente, 
sécurisée, et fonctionnant sans organe central de contrôle (définition de l’Institut Blockchain France). 
33 Côme BERBAIN, « La blockchain : concept, technologies, acteurs et usages », Annales des Mines - Réalités 
industrielles Août 2017, no 3 (26 juillet 2017): 6‑9. 



 

9 

connaitre. Rappelons que celle-ci ne se limite pourtant pas Ă  la transaction monĂŠtaire, et peut 

aussi servir d’infrastructure pour les contrats intelligents. Afin de mieux envisager les 

problÊmatiques nouvelles que soulève ce type de contrat lorsque liÊ à une chaÎne de blocs, nous 

décrierons les enjeux qu’apportent la chaîne de blocs au contrat intelligent, puis nous verrons 

en quoi cette technologie offre une plateforme intĂŠressante pour le contrat intelligent et quelles 

en sont les limites associĂŠes.  

 

1. La chaine de blocs : une technologie de stockage et de transmission 

d’informations ou de transactions 

 

La chaine de blocs est assimilĂŠe Ă  un registre34, rĂŠpertoriant un historique de transactions ou 

d’informations, de façon transparente, sécuritaire, et dans plusieurs cas, accessible à tous35. Les 

transactions sont validĂŠes puis enregistrĂŠes sous forme de blocs, qui se lient les uns et autres 

chronologiquement36. Bien qu’elle soit présentée par certains comme une « révolution 

blockchain »37, on s’aperçoit que cette technologie n’est pas parfaite et soulève plusieurs 

questions, aussi bien sur le plan technique que juridique38. Afin de mieux comprendre les enjeux 

et les dÊbats que soulèvent actuellement la technologie de la chaÎne de blocs, il est important de 

comprendre pourquoi certains auteurs39 sont si rĂŠfractaires Ă  cette technologie.  

 

 
34 Souvent mentionnĂŠ par les auteurs par le terme de ÂŤ ledger Âť en anglais. 
35 Nous verrons qu’il existe trois différents types de chaînes de blocs (privée, publique et de consortium) et que 
c’est dans le cadre de l’utilisation d’une chaine de blocs publique que les données sont accessibles à tous. 
36 SILLABER, Christian et WALTL, Bernhard. Life cycle of smart contracts in blockchain ecosystems, 2017, vol. 
41, no 8, p. 497-500. 
37 Philippe RODRIGUEZ, ""La rĂŠvolution blockchain: algorithmes ou institutions, Ă  qui donnerez-vous votre 
confiance?"", 2017. 
38 Plusieurs questions sont mises en avant, tant sur l’impact écologique de la chaine de blocs, que sur la protection 
des données personnelles, ou l’identité numérique. 
39 Notamment au regard de l’inaltérabilité de certains contenus ; VOGEL, Nick. « The Great Decentralization: 
How Web 3.0 Will Weaken” Copyrights. J. Marshall Rev. Intell. Prop. L., 2015, vol. 15, p. 136. 



 

10 

Sur le plan juridique, pour Primavera de Filippi40, la chaine de blocs soulève des questions de 

responsabilitĂŠ et de rĂŠgulation face Ă  ces nouvelles organisations dĂŠcentralisĂŠes qui sont gĂŠrĂŠes 

de façon autonome par les individus. En effet, qui est responsable dans le cadre d’une 

organisation qui n’a pas d’administrateur41? Nous verrons que la chaine de blocs rend plus 

difficile l’attribution des responsabilités en raison de l’anonymat de ses utilisateurs, mais 

complique aussi le blocage des opĂŠrations en raison de son fonctionnement autonome.  

 

Ensuite, il est certain que, sur le plan Êcologique, la chaÎne de blocs a encore des progrès à faire. 

Par exemple, la cryptomonnaie Bitcoin, dont le cours ne cesse d’augmenter depuis sa création42, 

est pilotĂŠe par un algorithme q";"""date"",""2020-02-12T21:48:22Z""
""pdf:PDFVersion"",""1.3""
""pdf:docinfo:title"",""Frances_Clemence_2019_memoire""
""xmp:CreatorTool"",""Word""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""fr""
""dc:format"",""application/pdf; version=1.3""
""pdf:docinfo:creator_tool"",""Word""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""Frances_Clemence_2019_memoire""
""modified"",""2020-02-12T21:48:22Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""ClĂŠmence FRANCES""
""meta:author"",""ClĂŠmence FRANCES""
""meta:creation-date"",""2020-02-12T21:48:22Z""
""created"",""2020-02-12T21:48:22Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-02-12T21:48:22Z""
""resourceName"",""Frances_Clemence_2019_memoire.pdf""
""Author"",""ClĂŠmence FRANCES""
""producer"",""macOS Version 10.14.6 (assemblage 18G103) Quartz PDFContext""
""pdf:docinfo:producer"",""macOS Version 10.14.6 (assemblage 18G103) Quartz PDFContext""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""ClĂŠmence FRANCES""
""dcterms:created"",""2020-02-12T21:48:22Z""
""Last-Modified"",""2020-02-12T21:48:22Z""
""dcterms:modified"",""2020-02-12T21:48:22Z""
""title"",""Frances_Clemence_2019_memoire""
""Last-Save-Date"",""2020-02-12T21:48:22Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2020-02-12T21:48:22Z""
""meta:save-date"",""2020-02-12T21:48:22Z""
""Content-Length"",""1498211""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""ClĂŠmence FRANCES""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""121""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""338"",""1218"",""1020"",""3416"",""1433"",""856"",""689"",""831"",""2529"",""2503"",""2210"",""2226"",""2486"",""2721"",""828"",""2463"",""2298"",""2868"",""2201"",""1210"",""2697"",""2432"",""2055"",""2927"",""2161"",""2508"",""2859"",""2144"",""1074"",""2708"",""2293"",""1292"",""2371"",""1927"",""2207"",""2737"",""2772"",""2075"",""2361"",""2622"",""2111"",""2177"",""2357"",""2854"",""1941"",""2493"",""2655"",""2488"",""2979"",""2392"",""2421"",""2289"",""2544"",""2851"",""2244"",""2274"",""2365"",""2105"",""2059"",""1601"",""1215"",""1981"",""2341"",""2188"",""1307"",""2524"",""2140"",""2152"",""2089"",""1812"",""1856"",""1709"",""1331"",""2320"",""2640"",""2185"",""2515"",""2665"",""2496"",""1959"",""2993"",""2352"",""2742"",""2230"",""2143"",""2886"",""2704"",""3126"",""1848"",""1054"",""2276"",""2516"",""2006"",""1686"",""2051"",""2197"",""2338"",""3509"",""2022"",""2114"",""2646"",""2529"",""2166"",""2514"",""2713"",""1743"",""2203"",""2759"",""2518"",""2502"",""890"",""1444"",""1536"",""1729"",""1896"",""1957"",""1488"",""1119"",""1016"",""960"",""738""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-02-12T21:48:22Z""
";https://scholar.google.ch/scholar?start=700&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098844-282;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;An efficient and provable certificate-based proxy signature scheme for IIoT environment;GK Verma, BB Singh, N Kumar, MS Obaidat, D He… ; Information …, 2020  Elsevier;;"… To deploy on energy trading, Aitzhan and Svetinovic [2] proposed an attestation method by

integration of blockchain, multi-signature and … These oracles are queried by the attackers. (a).

CB-ParGen(.)-Oracle: Challenger CH runs the oracle and obtains ? and secret key of CO …";Cité 5 fois;Les 3 versions;null;;;;https://scholar.google.ch/scholar?start=830&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098756-86;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Sklepanje pogodb s tehnologijo veriženja podatkovnih blokov;T ?opar ;2020 repozitorij.unilj.si;;"… Introduction of the master's thesis presents the historical developments of the blockchain

technology and its role in the emergence of cryptocurrencies. It describes how the technology

works and emphasises the importance of oracles, which have to act in the name of a smart …";Autres articles;En cache;null;;;;https://scholar.google.ch/scholar?start=630&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098782-149;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Post-quantum verification of Fujisaki-Okamoto;D Unruh ; International Conference on the Theory and …, 2020  Springer;;"… This is, on a high level, how crypto proofs in qRHL are done (modulo many concrete details) …

One highly important feature in more advanced cryptographic definitions and proofs are oracles.

Roughly speaking, an oracle is a program O that is given as an argument to another …";Cité 1 fois;Les 3 versions;[PDF] iacr.org;https://eprint.iacr.org/2020/962.pdf;"
Post-Quantum Verification of Fujisaki-Okamoto

Dominique Unruh
University of Tartu

August 6, 2020

Abstract

We present a computer-verified formalization of the post-quantum security proof of the
Fujisaki-Okamoto transform (as analyzed by Hövelmanns, Kiltz, Schäge, and Unruh,
PKC 2020). The formalization is done in quantum relational Hoare logic and checked
in the qrhl-tool (Unruh, POPL 2019).

Contents

1 Introduction 1

2 Quantum Relational Hoare Logic 5
2.1 Quantum While Language . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2 qRHL Judgements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3 Reasoning in qRHL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.4 The qrhl-tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3 Fujisaki-Okamato à la HKSU 12
3.1 Transformation Punc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.2 Transformation T . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.3 Transformation U6⊥m . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

4 Formalizing HKSU – The Specification 17

5 Formalizing HKSU – The Proof 23

A Axioms about the adversary 27

B O2H Theorem 30
B.1 The theorems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
B.2 Tactics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

1 Introduction

In this paper, we present the first formal verification of the post-quantum security of the
Fujisaki-Okamoto transform.

Cryptographic security proofs tend to be complex, and, due to their complexity, error prone.
Small mistakes in a proof can be difficult to notice and may invalidate the whole proof. For
example, the proof of the OAEP construction [8] went through a number of fixes [19, 20, 34]
until it was finally formally proven in [5] after years of industrial use. The PRF/PRP switching
lemma was a standard textbook example for many years before it was shown that the standard

1



proof is flawed [10]. And more recently, an attack on the ISO standardized blockcipher mode
OCB2 [25] was found [24], even though OCB2 was believed to be proven secure by [31].

While a rigorous and well-structured proof style (e.g., using sequences of games as advocated
in [10, 35]) can reduce the potential for hidden errors and imprecisions, it is still very hard to
write a proof that is 100% correct. (Especially when proof techniques such as random oracles
[13] or rewinding [42, 45] are used.) And especially if a mistake in a proof happens in a step
that seems very intuitive, it is quite likely that the mistake will also not be spotted by a reader.

This problem is exacerbated in the case of post-quantum security (i.e., security against
quantum adversaries): Post-quantum security proofs need to reason about quantum algorithms
(the adversary). Our intuition is shaped by the experience with the classical world, and it is
easy to have a wrong intuition about quantum phenomena. This makes it particularly easy for
seemingly reasonable but incorrect proof steps to stay undetected in a post-quantum security
proof.

In a nutshell, to ensure high confidence in a post-quantum security proof, it is not sufficient to
merely have it checked by a human. Instead, we advocate formal (or computer-aided) verification:
the security proof is verified by software that checks every proof step. In this paper, we present
the first such formal verification, namely of a variant of the Fujisaki-Okamoto transform [18] as
analyzed by Hövelmanns, Kiltz, Schäge, and Unruh [23].

Post-quantum security. Quantum computers have long been known to be a potential threat
to cryptographic protocols, in particular public key encryption. Shor’s algorithm [33] allows
us to efficiently solve the integer factorization and discrete logarithm problems, thus breaking
RSA and ElGamal and variants thereof. This breaks all commonly used public key encryption
and signature schemes. Of course, as of today, there are no quantum computers that even
come close to being able to execute Shor’s algorithm on reasonable problem sizes. Yet, there is
constant progress towards larger and more powerful quantum computers (see, e.g., the recent
breakthrough by Google [3]). In light of this, it is likely that quantum computers will be able
to break today’s public key encryption and signature schemes (and possibly other kinds of
cryptosystems) in the foreseeable future. Since the development, standardization, and industrial
deployment of a cryptosystem can take many years, we need to develop and analyze future
post-quantum secure protocols already today. One important step in this direction is the NIST
post-quantum competition [29] that will select a few post-quantum public-key encryption and
signature schemes for industrial standardization.

Quantum random oracles. One important proof technique in cryptography are random oracles
[9]. In a proof in the random oracle model, we idealize hash functions by assuming that every
hash function is simply a uniformly random function. (All algorithms including the adversary get
oracle access to that function.) Based on this assumption, security proofs become considerably
simpler. In some cases, we only know security proofs in the random oracle model. Of course, this
comes at a cost: This assumption is an idealization; concluding that a protocol that is secure in
the random oracle model is also secure using a real-world hash function is merely a heuristic
argument. (And this heuristic is known to be false in certain contrived cases, e.g., [15].)

As first explicitly pointed out by [13], in the quantum setting, the random oracle becomes
more involved: To get a realistic modeling, the adversary needs to be given superposition access
to the random oracle, i.e., the adversary can evaluate the random oracle/hash function in a
quantum superposition of many possible inputs. Due to this, quantum random oracle proofs
are much harder than in the classical setting. In particular, lazy sampling (where we pick each
output of the random oracle on demand when it is queried) does not work since all inputs can be
queried simultaneously on the first query. Nonetheless, for a number of special cases, there are
proof techniques for the quantum random oracle model (QROM). For example, 2q-wise functions
[47], semi-constant distributions [47], small range distribution [46], oracle indistinguishability

2



[46], and the one-way to hiding (O2H) theorem [44], just to mention a few.1

Of importance for this paper is the O2H theorem which exists in a number of variants (e.g.,
[1, 40, 41, 44]). The O2H theorem tells us – very roughly – that the probability of noticing
whether a specific output H(x) of the random oracle has been changed (“reprogrammed”) can
be bounded in terms of the probability of guessing that input x. This technique is used in a
number of QROM proofs, in particular those for the FO transform described next.

Fujisaki-Okamoto. A common approach for constructing public key encryption schemes is
the Fujisaki-Okamoto (FO) transform [18] or a variant thereof. The FO transform takes a
public-key encryption scheme with some weak passive security notion (such as IND-CPA or
one-way security) and transforms it into an actively secure public-key encryption or KEM2

scheme (IND-CCA security). On a very high level, instead of executing the encryption algorithm
with true randomness, the FO transform hashes the plaintext and uses the resulting hash value
as the randomness for the encryption algorithm. This removes some of the flexibility the attacker
has when constructing fake ciphertexts and makes chosen-ciphertext attacks impossible. The
advantage of the FO transform is that it gets us IND-CCA security at no or almost no increase in
ciphertext size or computational cost. The disadvantage is that the FO transform is only proven
in the random oracle model, which means that there is a heuristic element to its security proof.
Due to its high efficiency, the FO transform or some variations thereof is used in basically all
public key encryption candidates in the NIST competition. Because of this, it is very important
to understand the post-quantum security of the FO transform. However, due to the intricacies of
the quantum random oracle model, proving the security of the FO transform is not as easy as in
the classical setting. The first positive result was made by Ebrahimi Targhi and Unruh [36] who
proved the security of an FO variant that includes one more hash value in the ciphertext. This
additional hash had no obvious advantages but was required for their proof technique.3 That
result was adapted by [21] to several other FO variants, but still using an additional hash. ([21]
also gives an excellent overview over the different FO variants, even if the security results are
not state-of-the-art any more.) The first result to prove post-quantum security of FO without
an additional hash was given by Saito, Xagawa, and Yamakawa [32]. To achieve this, they
introduced a new intermediate security notion called “disjoint simulatability”. However, [32]
relies on the assumption that the underlying passively-secure encryption scheme has perfect
correctness, i.e., the probability of incorrectly decrypting honestly generated ciphertexts is zero.
Unfortunately, this is not the case with typical lattice-based encryption schemes (they have a
negligible failure probability), making the results of [32] inapplicable to many relevant encryption
schemes such as, to the best of our knowledge, all lattice-based NIST candidates. This situation
was resolved by Hövelmanns, Kiltz, Schäge, and Unruh [23] who show the security of an FO
variant (without additional hash) that is secure even in the presence of decryption failures. (This
result is the one we formalize in this work. We will refer to [23], specifically to the part concerned
with the FO transformation, as HKSU in the following.)

Formal verification of cryptography. As mentioned above, a state-of-the-art approach for
writing cryptographic security proofs are sequences of games. This approach is also well suited

1However, these do not and cannot cover all situations handled by classical proof techniques. Ambainis,
Rosmanis, and Unruh [2] show that in some cases, protocols that are secure in the classical ROM are insecure in
the QROM.

2A KEM, key encapsulation scheme, differs from an encryption scheme in that it does not allow us to encrypt
an arbitrary message but instead encrypts a uniformly random message. Raw public key encryption schemes are
almost always combined with symmetric encryption schemes to build hybrid encryption schemes. In these, the
public key scheme is only used to encrypt a random key anyway, so a KEM is sufficient. (See [17] for more on
this.) Hence KEMs and public key encryption schemes are equivalent for most practical purposes.

3Having the additional hash allows us to define an extraction algorithm that inverts the hash in order to recover
the randomness used by the encryption algorithm. In the classical setting this is not necessary because we can
simply observe the list of oracle queries performed by the adversary.

3



for formal verification. A number of frameworks/tools use this approach for verifying classical
cryptography: CryptoVerif [12], CertiCrypt [6], EasyCrypt [4], FCF [30], CryptHOL [7], and
Verypto [11]. CryptoVerif tries to automatically determine a sequence of games by using a set
of fixed rewriting rules for games. This has the advantage of reducing user effort, but it also
means that the framework is more limited in terms of what game transformations are possible.
In contrast, the other frameworks require the user to explicitly specify the games that constitute
the security proof (as is done in a pen-and-paper proof), and to additionally provide justification
for the fact that two consecutive games are indeed related as claimed. This justification will
often be considerably more detailed than in a pen-and-paper proof where the fact that two
slightly different games are equivalent will often be declared to be obvious.

One approach for proving the relationship of consecutive games is to give a proof in relational
Hoare logic. Relational Hoare logic is a logic that allows us to express the relationship between
two programs by specifying a relational precondition and a relational postcondition. A relational
Hoare judgment of the form {A} ccc ∟ ddd {B} intuitively means that if the variables of the programs
ccc and ddd are related as described by the precondition A before execution, and we execute ccc and ddd,
then afterwards their variables will be related as described by B. A very simple example would
be {x1 ≤ x2}x← x+ 1 ∼ x← x+ 1 {x1 ≤ x2}. This means that if the variable x in the left
program is smaller-equal than in the right one, and both programs increase x, then x in the left
program will still be smaller-equal than in the right one. As this example shows, relational Hoare
logic can express more complex relationships than simple equivalence of two games. This makes
the approach very powerful. To reason about cryptography, one needs a variant of relational
Hoare logic that supports probabilistic programs. Such a probabilistic relational Hoare logic
(pRHL) was developed for this purpose by Barthe, Grégoire, and Zanella Béguelin [6]. Both
CertiCrypt [6] and its popular successor EasyCrypt use pRHL for proving the relationship
between cryptographic games.

Formal verification of quantum cryptography. When considering the verification of post-
quantum cryptography, one might wonder whether the tools developed for classical cryptography
may not already be sufficient.4 Unfortunately, this is not the case. The soundness of the existing
tools is proven relative to classical semantics of the protocols and of the adversary. In fact, at
least for EasyCrypt and CryptHOL, Unruh [43] gave an explicit example of a protocol5 which
can be shown secure in EasyCrypt and CryptHOL but which is known not to be secure against
quantum adversaries. For the purpose of verifying quantum cryptography, Unruh [43] introduced
a generalization of pRHL, quantum relational Hoare logic (qRHL) that allows to prove relational
statements about quantum programs. (We will describe qRHL in more detail in Section 2.)
Unruh [43] also developed a tool qrhl-tool for reasoning in qRHL for the purpose of verifying
quantum cryptography. However, except for a toy example, the post-quantum security of a very
simple encryption scheme6, to the best of our knowledge, no post-quantum security proof has
been formally verified before this work. qrhl-tool uses a hybrid approach: Reasoning about
qRHL judgments is hardcoded in the tool, but verification conditions (i.e., auxiliary subgoals,
e.g., implications between invariants) are outsourced to the theorem prover Isabelle/HOL [28].

Our contribution. In this work, we formally verified the security proof of the FO transformation
from HKSU [23].7 The FO-variant analyzed by HKSU is a state-of-the-art construction for

4For actual quantum protocols where honest participants use quantum communication, this is clearly not the
case because the protocol itself cannot be described in the tool.

5The CHSH game [16] which is a simple case of a multi-prover proof system.
6One-time IND-CPA security of the symmetric encryption scheme Enc(k,m) := G(k)⊕m.
7To be precise, we formalize the security proof from the February 2019 version [22] of [23]. The proof has

been improved upon in later revisions of the paper. In particular, the requirement of injective encryption (see
footnote 13) has been removed. We formalized the earlier version of the proof since the formalization was already
under way when the proof was updated. Their new proof does not use substantially different techniques, and

4



building efficient public-key encryption schemes, and can be applied to many of the NIST
submissions to get IND-CCA secure encryption schemes (e.g., Frodo [26] or Kyber [14]).

Our formalization follows the overall structure of HKSU (i.e., it uses roughly the same
games) but introduces many additional intermediate games. (Altogether, our proof defines 136
programs, which covers games, oracles, and explicitly constructed adversaries in reductions.)
The formalization has 3455 lines of proof in qRHL and 1727 lines of proof in Isabelle/HOL for
auxiliary lemmas. (Not counting comments and blank lines or files autogenerated by search &
replace from others.) We mostly follow the structure of HKSU (but in many places we need to
do some adjustments to achieve the level of rigor required for formal verification). In the process,
we identified a few best practices for doing proofs in qrhl-tool that we list in Section 2.4.

We furthermore extended the qrhl-tool with a tactic o2h that implements an application of
the Semiclassical O2H Theorem [1]. This is needed in HKSU, but the O2H Theorem is often in
post-quantum crypto proofs, so we expect this addition to be very useful for future verifications,
too. (See Appendix B for details.)

Organization. In Section 2, we review qRHL and the qrhl-tool. In Section 3, we review
the result and part of the proof from HKSU. In Section 4, we go through the parts of the
formalization that make up the specification of the main result. In Section 5, we discuss the
formal proof. The source code of the formalization is provided in [37].

2 Quantum Relational Hoare Logic

In this section, we give an overview of quantum relational Hoare logic (qRHL). We will not give
formal definitions or a set of reasoning rules. For these, refer to [43]. Instead, our aim is to give
an intuitive understanding of the logic that allows to understand (most of) the reasoning steps
in our formalization.

2.1 Quantum While Language

qRHL allows us to reason about the relationship between quantum programs (that encode
cryptographic games). The programs are written in a simple while language that has the
following syntax (where ccc and ddd stand for programs):

ccc,ddd := skip (no operation)

ccc;ddd (sequential composition)

x← e (classical assignment)

x
$← e (classical sampling)

if e then ccc else ddd (conditional)

while e do ccc (loop)

q1 . . .qn
q← e (initialization of quantum registers)

apply e to q1 . . .qn (quantum application)

x←measure q1 . . .qn with e (measurement)

{local V ; ccc} (local variable declaration)

The language distinguishes two kinds of variables, quantum and classical. In the above syntax,
classical variables are denoted by x and quantum variables by q. The command x← e evaluates
the expression e (which can be any well-typed mathematical expression involving only classical

we believe that formalizing their new proof in qRHL would not pose any challenges different from the ones
encountered in this work. However, since their new proof is an almost complete rewrite (i.e., a different proof), it
is not possible to simply update our formalization. Instead, a new development from scratch would be needed.

5



variables) and assigns the value to x. In contrast x
$← e evaluates e which is supposed to

evaluate to a distribution D, and then samples the new value of x according to D. If- and
while-statements branch depending on a classical expression e.

To initialize quantum variables, we use q1 . . .qn
q← e. Here e is evaluated to return a quantum

state (i.e., a classical expression returning the description of a quantum state). Then q1 . . .qn

are jointly initialized with that state. E.g., we can write q
q← |x〉 (where x is a classical bit

variable) to initialize a quantum bit q.
Given an expression e that computes a unitary U , we use apply e to q1 . . .qn to apply U

jointly to q1 . . .qn. E.g., apply CNOT to q1q2.
x←measure q1 . . .qn with e evaluates e to get a description of a measurement, measures

q1 . . .qn jointly with that measurement and assigns the result to x. Typically, e might be
something like computational_basis, denoting a computational basis measurement.

Finally, {local V ; ccc} declares the variables V as local inside ccc. (This is an extension of the
language from [39].)

2.2 qRHL Judgements

Recall from the introduction that in relational Hoare logics, judgments are of the form
{A} ccc ∟ ddd {B} where ccc,ddd are programs, and A,B are relational predicates (the pre- and postcon-
dition). In particular, {A} ccc ∟ ddd {B} means that if the variables of ccc,ddd (jointly) satisfy A before
execution, then they (jointly) satisfy B after execution.8

Predicates. The same idea is used in qRHL but the concept of predicates becomes more complex
because we want to express something about the state of quantum variables. In fact, predicates
in qRHL are subspaces of the Hilbert space of all possible states of the quantum variables of the
two programs. We will illustrate this by an example:

Say q is a quantum variable in the first program ccc. We refer to q as q1 to distinguish it from
a variable with the same name in program ddd. Say we want to express the fact that q1 is in state
|+〉. That means that the whole system (i.e., all quantum variables together), are in a state of
the form |+〉q1 ⊗ |Ψ〉vars where vars are all other variables (of ccc and ddd), except q1. The set of
all states of this form forms a subspace of the Hilbert space of all possible states of the quantum
variables. Thus A := {|+〉q1 ⊗ |Ψ〉vars : |Ψ〉 ∈ Hvars} (with Hvars denoting the corresponding
Hilbert space) is a subspace and thus a valid predicate for use in a qRHL judgment. For example,
we could then write {A}apply X to q ∼ skip {A} to express the fact that, if q is in state |+〉
in the left program, and we apply X (a quantum bit flip) to q, then afterwards q is still in
state |+〉. Of course, writing A explicitly as a set is very cumbersome. (And, in the setting of
formal verification, one would then have no syntactic guarantees that the resulting set is indeed
a valid predicate.) Instead, we have the shorthand span{|+〉}»q1 to denote the above predicate
A. (More generally, SÂťq1 . . .qn means that q1 . . .qn are jointly in a state in S.)

We can build more complex predicates by combining existing ones. E.g., if A,A′ are predicates,
then A ∊ B is a predicate that intuitively denotes the fact that both A and B hold. And A + B,
the sum of two subspaces is somewhat akin to a disjunction of predicates. Or given an operator
D (e.g., a unitary or a projector), D ¡A is a predicate, too. (D ¡A is the pointwise multiplication
of the vectors in A with D.) These predicates have less clear intuitive meanings but may arise
from applying certain reasoning rules.

We will also often have to compare predicates. A ⊆ B means that A is a subspace of B for all
values of the classical variables. Intuitively, this means A implies B.

8There is a subtlety here: Since the two programs are not jointly executed (they live in separate worlds, so
to say) there is no obvious notion of the joint distribution or state of the programs after execution. Thus the
definition of the meaning of {A} ccc ∟ ddd {B} is a bit more complicated than presented here. We refer to [43] for a
formal exposition.

6



Predicates with classical variables. In most cases, however, we do not only have quantum
variables, but also classical variables. Especially in a post-quantum cryptography setting, the
majority of variables in a predicate tends to be classical. Support for classical variables in qRHL
predicates is straightforward: A predicate A can be an expression containing classical variables.
Those are then substituted with the current values of those variables, and the result is a subspace
that describes the state of the quantum variables as explained above. For example, we can write
the predicate span{|x2〉}»q1. This would mean that q1 (a qubit in the left program) is in state
|x2〉.

This already allows us to build complex predicates, but it is rather inconvenient if we want
to express something about the classical variables only, e.g., if we want to express that x1 = x2

always holds. To express such classical facts, we use an additional shorthand: Cla[b] is defined to
be H (the full Hilbert space) if b = true, and defined to be 0 (the subspace containing only 0) if
b = false. Why is this useful? Consider the predicate Cla[x1 = x2]. If x1 = x2, this evaluates
to Cla[true] = H. Since H contains all possible states, the state of the quantum variables will
necessarily be contained in Cla[true], hence the predicate is satisfied. If x1 6= x2, Cla[x1 = x2]
evaluates to Cla[false] = 0, and the state of the quantum variables will not be contained in
Cla[false], hence the predicate will not be satisfied. Thus, Cla[x1 = x2] is satisfied iff x1 = x2;
the state of the quantum variables does not matter. In general Cla[e] allows us to translate any
classical predicate e into a quantum predicate. (And this predicate can then be combined with
quantum predicates, e.g., Cla[x1 = x2] ∩ span{|+〉}»q1.)

Quantum equality. One very important special case of predicates are equalities. We will often
need to express that the variables of the left and right programs have the same values. We
have already seen how to do this for classical variables. For quantum variables, the situation
is more complex. We cannot write Cla[q1 = q2], this is not even a meaningful expression
(inside Cla[. . .], only classical variables are allowed). Instead, we need to define a subspace
that in some way expresses the fact that two quantum variables are equal. The solution
proposed in [43] (and that is shown there to be the only possibility if we expect certain natural
laws to hold) is: Let q1 ≡quant q2 denote the subspace of all states that are invariant under
exchanging q1 and q2 (i.e., invariant under applying a swap operation). Then q1 ≡quant q2 is
a quantum predicate (but not a Boolean expression, notwithstanding the suggestive notation).
And – this is less easy to see but shown in [43] – q1 ≡quant q2 does indeed capture the idea
that q1 and q2 have the same value in a meaningful way. We can now write, for example,
Cla[x1 = x2] ∩ (q1 ≡quant q2) to denote the fact that the variables x (classical) and q (quantum)
have the same value in both programs. In particular, if ccc only contains those two variables, we
have

{
Cla[x1 = x2] ∩ (q1 ≡quant q2)

}
ccc ∟ ccc

{
Cla[x1 = x2] ∩ (q1 ≡quant q2)

}
. What if there are

more quantum variables? The advantage of the quantum equality is that we hardly ever need
to recall the actual definition in terms of swap invariance. All we need to remember is that
q1 ≡quant q2 is a quantum predicate/subspace that intuitively encodes equality of q1 and q2.

If we have more than two variables that we wish to compare, q
(1)
1 . . .q

(n)
1 ≡quant q

(1)
2 . . .q

(n)
2

can be defined analogously. It intuitively means that the variable tuple q
(1)
1 . . .q

(n)
1 in the first

program has the same state as q
(1)
2 . . .q

(n)
2 in the second program.

There are, however, a few pitfalls and subtleties that one should be aware of:
• While q1 ≡quant q

′
1 (comparison of two variables in the left program) is well-defined, it

lacks a clear intuitive meaning. The idea that quantum equality implies the equality of the
states of the variables only works if all the variables on the lhs (left hand side) of ≡quant

are from the left program, and all the variables on the rhs (right hand side) are from the
right one. (Or vice versa.)

• q1 ≡quant q2 implies more than just equality between q1 and q2. It additionally means
that q1 and q2 are not entangled with any other variables. There is no way to express
equality between variables that may be entangled with other variables not occurring in the

7



quantum equality.
• While classical equality satisfies the rule that (x1,y1) = (x2,y2) is equivalent to x1 =
x2∧y1 = y2, this is not the case for quantum equality. In fact, (q1 ≡quant q2)∩(q′1 ≡quant q

′
2)

implies (is a subset of) q1q
′
1 ≡quant q2q

′
2 but not vice versa. (This should not come as a

total surprise given the previous point: (q1 ≡quant q2)∩ (q′1 ≡quant q
′
2) implies that q1 and

q2 are not entangled, while q1q
′
1 ≡quant q2q

′
2 allows them to be entangled with each other,

just not with other variables.)

The most common form of predicate that we will see is A= := Cla[x
(1)
1 = x

(1)
2 ∧ ¡ ¡ ¡ ∧ x

(1)
1 = x

(1)
2 ]∊

(q
(1)
1 . . .q

(m)
1 ≡quant q

(1)
2 . . .q

(m)
2 ). In fact, if both sides have the same program ccc (and ccc contains

no variables besides the ones mentioned in A=), then {A=} ccc ∟ ccc {A=} holds. Intuitively, this
means: if the inputs of two programs are equal, the outputs are equal.

2.3 Reasoning in qRHL

To derive qRHL judgments, one will hardly ever go directly through the definition of qRHL
itself. Instead one derives complex qRHL judgments from elementary ones. For example, to
derive the elementary {Cla[x1 = 0]}x← x + 1 ∼ skip {Cla[x1 = 1]}, we use the Assign1 rule
[43] that states

{
B{e1/x1}

}
x← e ∼ skip

{
B
}

. (Here e1 is the expression e where all variables
y are replaced by y1. And B{e1/x1} means every occurrence of x1 in B is replaced by e1.) With
B := Cla[x1 = 1], we get from Assign1:

{
Cla[x1 + 1 = 1]

}
x← e ∼ skip

{
Cla[x1 = 1]

}
. Since

x1 + 1 = 1 is logically equivalent to x1 = 1 (assuming the type of x is, e.g., integers or reals), this
statement is equivalent to {Cla[x1 = 0]}x← x + 1 ∼ skip {Cla[x1 = 1]}. (This is an example
of reasoning in the “ambient logic”: Besides application of qRHL rules, we need to use “normal”
mathematics to derive facts about predicates. This is external to qRHL itself.)

One can then combine several judgments into one, using, e.g., the Seq rule: “If {A} ccc ∼ ddd {B}
and {B} ccc′ ∼ ddd′ {C} holds, then {A} ccc; ccc′ ∼ ddd;ddd′ {C} holds.” For example, once we have de-
rived {Cla[true]}x← 1 ∼ skip {Cla[x1 = 1]} and {Cla[x1 = 1]} skip ∼ y← 1 {Cla[x1 = y2]}
(using the Assign1 rule and its rhs variant Assign2), we conclude using Seq that
{Cla[true]}x← 1 ∼ y← 1 {Cla[x1 = y2]}. (We use here implicitly that x ← 1; skip is the
same as x← 1 and analogously for skip;y← 1.)

We will not give the full list of rules here, see [43] and the manual of [38] for a comprehensive
list.

One common approach to prove more complex qRHL judgments is backward rea-
soning: One starts by stating the judgment one wants to prove, say G1 :=
{Cla[true]}x← 1 ∼ y← 1 {Cla[x1 = y2]}. Then one applies one qRHL rule to the very last
statement on the left or right, say y← 1. By application of the Seq and Assign2 rule, we see
that G2 := {Cla[true]}x← 1 ∼ skip {Cla[x1 = 1]} implies G1. So we have reduced our current
goal to showing G2. (Using a reasoning step that can be fully automated.) By application of
Seq and Assign1, we see that G3 := {Cla[true]} skip ∟ skip {Cla[1 = 1]} implies G2. So our
new proof goal is G3. And finally, G3 is implied by G4 :=

(
Cla[true] ⊆ Cla[1 = 1]

)
. So our final

goal is G4 which is a trivial statement in ambient logic because 1 = 1 is true. Hence the proof
concludes and G1 holds. The advantage of this approach is that it is fully mechanical in many
cases, e.g., for sequences of assignments and applications of unitaries. The proof tool qrhl-tool
(see the next section) follows exactly this approach.

So far, we have gotten a glimpse how to derive qRHL judgments. In a cryptographic
proof, however, we are interested not in qRHL judgments but in statements about probabilities.
Fortunately, we can derive those directly from a qRHL judgment using the QrhlElimEq rule.
It states (somewhat simplified): Assuming X and Q are all the variables occurring in ccc,ddd, then{
Cla[X1 = X2] ∩ (Q1 ≡quant Q2)

}
ccc ∟ ddd

{
Cla[e1 =⇒ f2]

}
implies Pr[e : ccc] ≤ Pr[f : ddd]. (Here

Pr[e : ccc] denotes the probability that the Boolean expression e is true after executing ccc, and
analogously Pr[f : ddd].) A variant of the rule (with ⇐⇒ instead of =⇒ ) allows us to derive an

8



equality of probabilities. Thus to derive an inequality or equality of probabilities of program
outcomes, we convert it into a qRHL proof goal with QrhlElimEq, and then use the reasoning
rules of qRHL to derive that qRHL judgment. This is, on a high level, how crypto proofs in
qRHL are done (modulo many concrete details).

2.4 The qrhl-tool

While reasoning using qRHL in pen-and-paper proofs is possible in ";"""date"",""2020-08-06T14:15:53Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2020-08-06T14:15:53Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.20 (TeX Live 2019/Debian) kpathsea version 6.3.1""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2020-08-06T14:15:53Z""
""created"",""2020-08-06T14:15:53Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-08-06T14:15:53Z""
""resourceName"",""962.pdf""
""Author"",""""
""producer"",""pdfTeX-1.40.20""
""pdf:docinfo:producer"",""pdfTeX-1.40.20""
""pdf:unmappedUnicodeCharsPerPage"",""1"",""0"",""0"",""0"",""0"",""11"",""9"",""26"",""1"",""1"",""1"",""7"",""29"",""28"",""13"",""4"",""2"",""19"",""2"",""6"",""1"",""0"",""2"",""5"",""8"",""35"",""0"",""0"",""0"",""7"",""0"",""0"",""0"",""0"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2020-08-06T14:15:53Z""
""Last-Modified"",""2020-08-06T14:15:53Z""
""dcterms:modified"",""2020-08-06T14:15:53Z""
""title"",""""
""Last-Save-Date"",""2020-08-06T14:15:53Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2020-08-06T14:15:53Z""
""meta:save-date"",""2020-08-06T14:15:53Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.20 (TeX Live 2019/Debian) kpathsea version 6.3.1""
""Content-Length"",""648547""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""36""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""1509"",""3729"",""3984"",""3910"",""2636"",""3335"",""3693"",""3357"",""3099"",""3247"",""3088"",""2654"",""2322"",""3206"",""2617"",""2414"",""2210"",""2832"",""2923"",""2921"",""2903"",""2483"",""2336"",""3447"",""2797"",""890"",""2649"",""1566"",""1909"",""2246"",""3369"",""1445"",""1678"",""2281"",""2723"",""1383""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-08-06T14:15:53Z""
";https://scholar.google.ch/scholar?start=690&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098892-393;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Extracting randomness from extractor-dependent sources;Y Dodis, V Vaikuntanathan, D Wichs ; … on the Theory and Applications of …, 2020  Springer;;"… In more detail, we assume the seed is chosen randomly, but the source can make arbitrary oracle

queries to the extractor with the given seed before outputting a sample … The probability that

\(\mathcal {S}\) queries its oracle on the value x that it outputs is negligible. 2 …";Cité 2 fois;Les 5 versions;[PDF] nsf.gov;https://par.nsf.gov/servlets/purl/10165162;"
Extracting Randomness from
Extractor-Dependent Sources

Yevgeniy Dodis1, Vinod Vaikuntanathan2(B), and Daniel Wichs3,4(B)

1 NYU, New York, USA
2 MIT, Cambridge, USA
vinod.nathan@gmail.com

3 Northeastern University, Boston, USA
danwichs@gmail.com

4 NTT Research Inc., East Palo Altos, USA

Abstract. We revisit the well-studied problem of extracting nearly uni-
form randomness from an arbitrary source of sufficient min-entropy.
Strong seeded extractors solve this problem by relying on a public ran-
dom seed, which is unknown to the source. Here, we consider a setting
where the seed is reused over time and the source may depend on prior
calls to the extractor with the same seed. Can we still extract nearly uni-
form randomness?

In more detail, we assume the seed is chosen randomly, but the source
can make arbitrary oracle queries to the extractor with the given seed
before outputting a sample. We require that the sample has entropy and
differs from any of the previously queried values. The extracted output
should look uniform even to a distinguisher that gets the seed. We con-
sider two variants of the problem, depending on whether the source only
outputs the sample, or whether it can also output some correlated public
auxiliary information that preserves the sample’s entropy. Our results are:
Without Auxiliary Information: We show that every pseudo-random
function (PRF) with a sufficiently high security level is a good extractor
in this setting, even if the distinguisher is computationally unbounded.
We further show that the source necessarily needs to be computationally
bounded and that such extractors imply one-way functions.
With Auxiliary Information: We construct secure extractors in this
setting, as long as both the source and the distinguisher are computa-
tionally bounded. We give several constructions based on different inter-
mediate primitives, yielding instantiations based on the DDH, DLIN,
LWE or DCR assumptions. On the negative side, we show that one can-
not prove security against computationally unbounded distinguishers in
this setting under any standard assumption via a black-box reduction.
Furthermore, even when restricting to computationally bounded distin-
guishers, we show that there exist PRFs that are insecure as extractors
in this setting and that a large class of constructions cannot be proven
secure via a black-box reduction from standard assumptions.

1 Introduction

Extracting Randomness. Randomness is an important ingredient in many
algorithmic tasks, and is especially crucial in cryptography. Indeed, much of
cŠ International Association for Cryptologic Research 2020
A. Canteaut and Y. Ishai (Eds.): EUROCRYPT 2020, LNCS 12105, pp. 313–342, 2020.
https://doi.org/10.1007/978-3-030-45721-1_12

http://crossmark.crossref.org/dialog/?doi=10.1007/978-3-030-45721-1_12&domain=pdf
https://doi.org/10.1007/978-3-030-45721-1_12


314 Y. Dodis et al.

cryptography relies on the assumption that parties can sample uniformly ran-
dom bits. However, most natural sources of randomness are imperfect and not
uniformly random. This motivates the study of randomness extraction, whose
goal is to extract (nearly) uniform randomness from imperfect sources.

Ideally, we would have a deterministic function Ext that converts an imper-
fect source of randomness X into a (nearly) uniformly random output Ext(X).
Furthermore, such an extractor should work for all sources of randomness X
having a sufficiently large amount of (min-)entropy. Unfortunately, this is easily
seen to be impossible, even if we only want to output 1 bit [CG85]: for every
extractor function Ext, there is a source X that has almost full min-entropy yet
the output of Ext(X) is completely fixed.

There have been two broad lines of work to get around this. The first
line of work designs extractors for restricted types of sources X that satisfy
additional requirements beyond just having entropy (see e.g., [von51,CGH+85,
Blu86,LLS89,CG85,TV00,BST03,BIW04,CZ16]). While this is an important
research direction, we often know very little about natural sources of random-
ness and they may fail to satisfy the imposed requirements. The second line of
work considers (strong) seeded extractors [NZ93,NZ96], where the extractor is
given a public uniformly random seed S, which is independent of the source
X, and we require that the extracted output Ext(X;S) is close to uniform even
given the seed S.

Extractor-Dependent Sources. In this work, we consider a seeded extrac-
tor and envision a scenario where a single uniformly random seed S is chosen
once and then is reused over time by many different users and/or applications
to extract randomness from various “natural” sources of entropy. For example,
the seed S could be a part of a system random number generator (RNG) that
extracts randomness from physical sources of entropy, such as the timing of
interrupts etc. If the sources are truly independent of the seed S, then stan-
dard (strong) seeded extractors suffice to guarantee that the extracted outputs
are nearly uniform. However, since the seed S is continuously reused, past out-
puts of the extractor will make their way back into “nature” and may affect
the sources in the future. For example, interrupts may depend on processes that
themselves rely on previous outputs of the extractor. Furthermore, since we can-
not assume that all users/applications use the extractor securely, we have to
allow for the possibility that some of the prior calls to the extractor were made
on arbitrary samples that may not have any entropy. Unfortunately, if the source
can depends on prior calls to the extractor with the same seed S, we violate the
condition that the source is independent of the seed and can no longer rely on
the security of standard seeded extractors. We emphasize that, although the seed
S is public, the sources are not fully adversarial and not arbitrarily dependent
on S. (A restriction of this sort is of course necessary to circumvent the obvious
impossibility result.) Instead, we assume that the sources can only depend on
prior calls to the extractor with the given seed S, but are otherwise indepen-
dent of S. We call such sources “extractor-dependent”. Can we design extractors



Extracting Randomness from Extractor-Dependent Sources 315

for extractor-dependent sources (ED-Extractors) that manage to extract nearly
uniform randomness in this setting?

Defining the Problem. We now specify the problem in more detail. Our goal
is to design a seeded extractor EDExt that extracts randomness from extractor-
dependent sources. We consider a setting where a seed S is chosen uniformly at
random. A source SEDExt(¡,S) gets oracle access to the extractor with the seed S
and outputs a sample X along with some public auxiliary information AUX. We
say that such a source S is a legal extractor-dependent source of entropy Îą if two
conditions hold: (1) the (conditional min-entropy) of X given S,AUX is at least
Îą, and (2) the source never queries the oracle on the value X that it outputs. An
Îą-ED-Extractor needs to ensure that for all legal extractor-dependent sources
of entropy Îą, the output EDExt(X,S) is indistinguishable from uniform, even
given the seed S and the auxiliary information AUX.

Discussion on the Legality Conditions. We motivate the reason behind
the two legality conditions imposed by the definition.

Firstly, just like for standard (seeded) extractors, we need to assume that X
has a sufficient level of entropy even conditioned on AUX in order to extract ran-
domness from it. In our case, the source also has access to the oracle EDExt(¡, S)
with a random seed S, but we want the entropy to come from the internal ran-
domness of the source rather than from the seed S since the latter is public and
known to the distinguisher. Therefore, it is natural to also condition on S.

The second condition is clearly necessary: without it we could define a source
that queries the oracle on random values and outputs the first such value on
which the extracted output starts with a 0. Such a source would have almost full
entropy, yet the extracted output would be easily distinguishable from uniform.
Moreover, this condition is also reasonable when modeling our intended scenario
since the sample should have entropy even given all the prior extractor calls that
influenced nature, and therefore it should differ from all of them.

In particular, the two legality conditions include the following simpler sub-
class of sources, which already intuitively captures our intended scenario. Con-
sider sources S = (S1,S2) that consists of two components. The first component
SEDExt(¡,S)
1 makes arbitrary oracle calls to the extractor and models the influ-

ence that these calls have on nature; it outputs some value state. The second
component S2(state) then outputs X,AUX without making any further oracle
queries and captures the entropic process that produces the sample. The only
condition we impose is that, for every possible fixed value of state, the entropy
of X conditioned on AUX when they are sampled according to S2(state) should
be at least Îą. If Îą is large enough then S satisfies both of the previous legality
conditions. In particular, S1 could not have queried the oracle on X since the
entropy of X comes only from the random coins of S2 that are unknown to S1.

Discussion on Auxiliary Info. Our default definition allows the source to
output some public auxiliary info AUX that can be correlated with the sample
X as long as it preserves its (average conditional min-)entropy. It is natural that
some such information may be public (e.g., the source X denotes the timing of



316 Y. Dodis et al.

interrupts, but the adversary can learn some auxiliary info AUX denoting the
high-order bits of such timings by interacting with the system). We also consider
a weaker setting without auxiliary info, where we don’t have AUX. In the case
of standard seeded extractors, it turns out that there is not much difference
between a setting with auxiliary info and without [DORS08]. However, as we
will see, there is a significant difference between the two settings when it comes
to ED-Extractors.

Prior Work. The work of Coretti et al. [CDKT19] initiates the study of
extracting from extractor-dependent sources in the special case where the
extractor is a random oracle. While their definition is specifically tailored to
the random-oracle model, our definition can be seen as the natural extension
of it to the standard model. In particular, they consider the setting where
O(¡) = EDExt(¡, S) is a truly random function. They show that this is an ι-
ED-Extractor for any super-logarithmic entropy Îą, as long as the source only
makes polynomially many queries, but even if the distinguisher is computation-
ally unbounded and can see the entire truth table of the oracle. This gives
us heuristic evidence that a “good” cryptographic hash function is an ED-
Extractor in the standard model even against computationally unbounded dis-
tinguishers (as long as the source is computationally bounded). The main open
question is therefore whether we can construct ED-Extractors under standard
computational assumptions.

1.1 Our Results

We give positive and negative results for ED-Extractors with and without
auxiliary info.

Without Auxiliary Info. On the positive side, we show that any pseudo-
random function (PRF) with a sufficiently high security level is a good
ED-Extractor without auxiliary info. In particular, assuming the existence of sub-
exponentially secure one-way functions, there exist Îą-ED-Extractors with any
output size m for entropy α = m + ω(log λ), where λ is the security parame-
ter. Furthermore, such extractors achieve security even against computationally
unbounded distinguishers, as long as the source runs in polynomial time. If we only
want security against polynomial-time distinguishers, we can allow the output size
to grow to an arbitrary polynomial m while only requiring entropy ι = ΝΊ(1).

On the negative side, we show that ED-Extractors imply one-way functions
and therefore cannot be constructed unconditionally. This holds even without
auxiliary info, even if we require that the source has almost full entropy, and
even if the extractor outputs only 1 bit. Furthermore, we show that such ED-
Extractors cannot exist for computationally unbounded sources.

With Auxiliary Info. We construct ED-Extractors in the setting with auxil-
iary info under standard assumptions. In particular, we give three constructions.

– The first construction relies on (adaptively secure) constrained PRFs [BGI14,
KPTZ13,BW13] for NC1 constraints. These can be instantiated under the



Extracting Randomness from Extractor-Dependent Sources 317

sub-exponential security of either the learning with errors (LWE) [BV15]
or the Decisional Diffie-Hellman Inversion (DDHI) assumption in arbitrary
prime-order groups (without requiring pairings) [AMN+18].1

– The second construction relies on shift-hiding shiftable functions [PS18],
which can be seen as a type of constraint-hiding constrained PRFs, and can
be instantiated under LWE without requiring sub-exponential security.

– The third construction relies on lossy functions and can be instantiated under
any of: decisional Diffie-Hellman (DDH), decisional-linear (DLIN), LWE, or
decisional composite residuosity (DCR) assumptions.

In all cases, we prove security against polynomial-time sources and distinguish-
ers. Our Îą-ED-Extractors can have arbitrarily large polynomial input size n and
output size m, and require entropy ι = ΝΊ(1).

Note that, in the setting without auxiliary info, we achieved security even
against computationally unbounded distinguishers. Furthermore, the random-
oracle based result of [CDKT19] heuristically suggests that good cryptographic
hash functions achieve security against computationally unbounded distinguish-
ers even in the auxiliary info setting. However, our constructions in the auxiliary
info setting from standard assumptions only achieve security against polynomial-
time distinguishers. Unfortunately, we show that this is inherent. In particular,
we show that in the auxiliary info setting, one cannot prove the security of
any ED-Extractor against computationally unbounded distinguishers under any
standard assumption via a black-box reduction.

Furthermore, our instantiations in the auxiliary info setting rely on “crypto-
mania” assumptions (known to imply public-key encryption) rather than one-
way functions, and we ask whether this is necessary. While we do not resolve this
question, we give some evidence that the two settings necessitate substantially
different constructions. Firstly, one may be tempted to conjecture that every
PRF is also a good ED-Extractor even in the auxiliary info setting. We show
that this is not the case: there exist PRFs that are insecure as ED-Extractors
in the auxiliary info setting even for very high levels/rates of entropy Îą. More-
over, we show that a large class of natural PRFs (e.g., the Naor-Reingold PRF)
cannot be proven to be secure ED-Extractors in the setting of auxiliary info via
a black-box reduction from any standard assumption.

1.2 Our Techniques

ED-Extractors without Auxiliary Info from PRFs. Our first result
shows that every PRF is already a good ED-Extractor in the setting without
auxiliary info. In particular, the seed of the extractor is the PRF key and the
extractor just evaluates the PRF on the sample X. The main difficulty in prov-
ing ED-Extractor security is that the distinguisher gets the seed of the ED-
Extractor, but PRF security only holds if the key is never revealed. Our insight
1 The DDHI assumption in a cyclic group G of order q with generator g states that,

given any polynomially many values of the form (g, ga, ga2
, . . . , gaL

) where a ← Zq,
the value g1/a is computationally indistinguishable from uniform.



318 Y. Dodis et al.

is to design a reduction that never calls the distinguisher – indeed, this allows
us to prove security even for computationally unbounded distinguishers.

Let’s start with the case where the PRF/Extractor only outputs 1 bit. If
the extracted output is statistically far from uniform given the seed, it means
that it is biased towards either 0 or 1, but the direction of the bias is unknown
and may be different for each seed. Consider running the source S twice with
independent randomness, while giving it oracle access to the PRF/Extractor
with the same random key/seed. Let X0,X1 be the samples that the two runs
output respectively. Then the PRF/Extractor evaluations on those samples are
more likely to agree than disagree, since they are biased in the same direction.
But the legality conditions ensure that X0,X1 were never queried during either
of the two runs and are different from each other (since each run cannot query
its own output and the output of the other run should have enough entropy to
be unpredictable). So, given oracle access to the PRF, we can use the source S
to find two values X0,X1 that we haven’t yet queried, but if we then proceed to
query the PRF on them, the outputs are noticeably more likely to agree than
disagree. This cannot be the case given oracle access to a random function, and
therefore allows us to distinguish the two and break PRF security. The analysis
extends to a larger output size m, but the advantage of the reduction shrinks by a
factor of 2−m. Therefore, we need very secure PRFs that cannot be distinguished
from random functions with advantage better than negl(λ)2−m, which requires
sub-exponential security assumptions.

Note that the above argument completely breaks down in the setting with
auxiliary info. The problem is that now the direction of the bias can be different
for each choice of the key/seed and the auxiliary info. But the two independent
runs of the source S are unlikely to produce the same auxiliary info and hence
we cannot argue that the bias would go in the same direction. Indeed, we show
that there are PRFs that are completely insecure as ED-Extractors in the setting
with auxiliary info.

ED-Extractors imply One-Way Functions. We show that ED-Extractors
cannot exist if the source is allowed to be computationally unbounded. This holds
even in the setting without auxiliary info, even if we only consider polynomial-
time distinguishers, even if we require that the source has almost full entropy,
and even if the extractor outputs only 1 bit. The high level idea is that a com-
putationally unbounded source S with oracle access to the function EDExt(¡, S)
can learn the function sufficiently well to predict its output on a random value
with high probability. It can then sample a random X subject to predicting that
EDExt(X,S) = 0, without querying the extractor on X. This is a legal source
with almost full entropy, yet the extractor output is highly biased towards 0.
We extend the above argument to showing that such extractors imply one-way
functions.

ED-Extractors with Auxiliary Info from Constrained PRFs. We
construct ED-Extractors in the setting with auxiliary info, using constrained
pseudorandom functions (C-PRF). A C-PRF allows us to constrain a PRF key



Extracting Randomness from Extractor-Dependent Sources 319

k on some constraint function C to yield a constrained key, denoted k{C}. The
constrained key allows us to evaluate the PRF on all points x such that C(x) = 0.
However, given the constrained key k{C}, the PRF outputs at all points x for
which C(x) = 1 look random. We need to rely on adaptively secure constrained
PRFs, where the adversary can choose the constraint C after seeing some PRF
outputs.

Our construction of ED-Extractors uses a constrained PRF and a standard
(seeded) randomness extractors Ext. The seed of the ED-Extractor is a con-
strained PRF key k{CS,U}, with the constraint CS,U (X) that outputs 1 (i.e.,
prevents evaluation) on all points X such that Ext(X;S) = U , where S,U are
chosen randomly. We choose the output size of the extractor to be � = ω(log λ)
and therefore the key is constrained on a negligible fraction of points. On input
X, the ED-Extractor checks if CS,U (X) = 1, in which case it outputs some fixed
dummy value, and otherwise it uses the seed k{CS,U} to evaluate the PRF on X.

To argue ED-Extractor security, we consider a source SEDExt(¡,k{CS,U }) that
gets oracle access to the ED-Extractor with a random seed k{CS,U} and out-
puts X,AUX. A distinguisher D then gets the seed k{CS,U} together with AUX
and the extracted output R = EDExt(X, k{CS,U}). We first argue that this
is statistically indistinguishable from giving the source S oracle access to the
unconstrained PRF and setting R to be the output of the PRF with the uncon-
strained key on X (since the probability that any of the queries of S or its
output lie in the constrained set is negligible). Now, instead of giving the distin-
guisher D the constrained key k{CS,U} where U is uniform, we give it the key
k{CS,Ext(X;S)} which is constrained on X. This is statistically indistinguishable
since X has entropy even conditioned on AUX and is sampled independently
of S; therefore Ext(X;S) is close to uniform even given AUX. But now we can
switch R from the output of the PRF on X to uniform, and this is computation-
ally indistinguishable even given the constrained PRF key k{CS,Ext(X;S)} since
it is constrained on X (and we know that the source didn’t query the oracle on
X). This shows that the extracted output is indistinguishable form uniform even
given the ED-Extractor seed and the auxiliary info. (The above proof outline
conveys the intuition but is slightly oversimplified and ignores some subtleties;
see the full proof for details).

Since standard extractors can be evaluated in NC1, we only need constrained
PRFs for NC1 circuits. Fortunately, we have such constructions from the LWE
and DDHI assumptions [BV15,AMN+18]. However, they only achieve selective
security, where the constrained circuit needs to be chosen ahead of time before
any PRF outputs are given out, while we need adaptive security. We can get
this via standard complexity leveraging at the cost of having to assume the
sub-exponential security of the LWE and DDHI assumptions.

Additional Constructions (in the full version). We give two alter-
nate constructions of ED-Extractors in the setting with auxiliary info. The first
uses shift-hiding shiftable functions [PS18], which can be instantiated from stan-
dard LWE, without needing complexity leveraging. The construction and proof



320 Y. Dodis et al.

of security differ substantially from the one above. The second one uses lossy
functions, which are essentially equivalent to lossy trapdoor functions (LTDFs)
[PW08] without requiring a trapdoor. The construction can be instantiated from
several different assumptions (DDH,DLIN,LWE,DCR). Both constructions are
omitted from this proceedings version due to lack of space; please see the full
version [DVW19].

Not all PRFs are ED-Extractors with Aux Info. We construct PRFs,
which fail to be good extractors in the setting of auxiliary info. For example,
consider a PRF which first hashes the input x into a small digest using a collision-
resistant hash function and then applies another PRF on the output. Consider
a source that chooses a random x and sets the auxiliary info to be the hash of x.
Since the hash is small, this does not reduce the entropy of x by much. However,
if the distinguisher is given the PRF key (which is the ED-Extractor seed) and
the auxiliary info, it can compute the PRF on x and therefore easily distinguish
it from uniform. In this example, the auxiliary info reduces the entropy of x by
some small super-logarithmic amount. We give an even more dramatic example
of this type using fully-homomorphic encryption (FHE) where the auxiliary info
reduces the entropy of x by only 1 bit.

Black-Box Separation Results. Lastly, we give two black-box separation
results showing that, in the auxiliary info setting, one cannot prove security (via
a black-box reduction under a standard assumption) against computationally
unbounded distinguishers or for certain natural classes of constructions. Our
results rely on the framework of [Wic13] and rely on the fact that the ED-
Extractor definition is expressed as a two-stage game where the attacker consists
of two components (the source and the distinguisher) that cannot communicate.
This allows us to give black-box separations showing that, in certain cases, we
cannot prove security under any standard assumption which is in the form of a
single-stage game between a challenger and a single stateful adversary.

1.3 Additional Related Work

RNGs. Our scenario is partially motivated by the problem of extracting ran-
domness from physical sources as part of a system Random Number Generator
(RNG). We note that extracting randomness is only one component of a good
RNG; see e.g., [BH05,DPR+13,DSSW14,GT16,Hut16,CDKT19] for works that
formally deal with the broader problem of RNG design.

Universal Computational Extractors (UCE). The notion of universal
computational extractors (UCE) [BHK13,ST17] was originally proposed as a
way of capturing “random-oracle like” security properties of hash functions via
a standard-model definition. While the format of the UCE definition is also
given in terms of an extraction game with a source and a distinguisher, there are
major differences between the UCE definition and that of ED-Extractors, both
in terms of their syntactic structure, but also more conceptually in terms of what
they aim to capture. The key such difference is that the notion of legal source is



Extracting Randomness from Extractor-Dependent Sources 321

defined in the “ideal model”, and permits sources which only have computational
unpredictability in the “real” model (say, conditioned on the auxiliary informa-
tion).2 In contrast, this work only aimed to capture a smaller class of sources
that have entropy even in the “real model”, but could depend of the previous
extractor output.

Unfortunately, it is known that even the weakest form of UCE security can-
not be achieved under standard assumptions (via black-box reductions; this indi-
rectly follows from [Wic13]), while our work shows that ED-Extractors can. It
remains an interesting open problem whether ED-Extractors can be used in place
of UCEs to get any broader cryptographic applications beyond the immediate
ones of extracting randomness.

Low-Complexity Samplers. Introduced by Trevisan and Vadhan [TV00] and
later extended by [KRVZ11], these seedless extractors assume that the entropy
source producing input X is unable to run the extractor even once. In contrast,
our sampler can be much slower than the extractor, but we use a seed and
give the sampler oracle access to the extractor, before releasing the seed to the
distinguisher.

Seed-Dependent condensers. This approach, formalized by Dodis, Risten-
part and Vadhan [DRV12], relaxes the security guarantees of the randomness
extractor to only ensure that the output of the condenser is almost full entropy,
but not necessarily close to uniform. In this sense it is weaker than ED-Extractors.
However, the sampler is given the actual seed, which is stronger than our setting.
Interestingly, the availability of auxiliary information also played a crucial role in
the constructions of seed-dependent condensers from standard assumptions.

2 Preliminaries

When X is a distribution, or a random variable following this distribution, we
let x ← X denote the process of sampling x according to the distribution X. If
X is a set, we let x ← X denote sampling x uniformly at random from X.

Let X,Y be random variables with supports SX , SY , respectively. We define
their statistical difference as

SD(X,Y ) =
1
2

∑

u∈SX∪SY

|Pr[X = u] − Pr[Y = u]| .

The min-entropy of a random variable X is H∞(X) = − log(maxx Pr[X =
x]). Following Dodis et al. [DORS08], we define the (average) conditional min-
entropy of X given Y as: H∞(X|Y ) = − log

(
Ey←Y

[
2−H∞(X|Y =y)

])
. Note that

H∞(X|Y ) = k iff the optimal strategy for guessing X given Y succeeds with
probability 2−k.

2 Somewhat confusingly, this is true even for so called “UCEs for statistically unpre-
dictable sources”.



322 Y. Dodis et al.

Lemma 1. For any random variables X,Y where Y is supported over a set
of size T we have H∞(X|Y ) ≤ H∞(X) − log T .

Definition 1 ((Strong, Average-Case) Seeded Extractor [NZ96]). We
say that an efficient function Ext : {0, 1}n × {0, 1}d → {0, 1}� is an (α, ε)-
extractor if for all random variables (X,Z) such that X is supported over {0, 1}n

and H∞(X|Z) ≥ α we have SD((Z, S,Ext(X;S)), (Z, S, U�)) ≤ ε where S,U� are
uniformly random and independent bit-strings of length d, ďż˝ respectively.

Theorem 1 ([ILL89]). There exist (Îą, Îľ)-extractors with input length n and out-
put length � as long as α ≥ � + 2 log(1/ε).

Definition 2 ((Strong, Average-Case) Two-Source Extractor [CG88]).
We say that an efficient function 2Ext : {0, 1}n × {0, 1}n → {0, 1}m is
an (e1, e2, δ)-strong 2-source extractor if for all random variables (X1,X2, Z)
such that X1,X2 are independent conditioned on Z and H∞(X1|Z) ≥ e1,
H∞(X2|Z) ≥ e2 we have SD((Z,X2, 2Ext(X1;X2)), (Z,X2, Um)) ≤ δ where Um

is a uniformly string of length m.

Theorem 2 ([Raz05]). For any polynomial input length n = poly(Îť), any e1 =
ΝΊ(1) and any e2 = (1/2 + Ί(1))n, there exist (e1, e2, δ)-extractor with input
length n, output length m = λΩ(1) and error δ = 2−λΩ(1)

.

Definition 3. The collision probability of a random variable A is defined as
Col(A) = Pr[a = a′ : a ← A, a′ ← A]. The conditional collision probability of
A given B is defined as Col(A|B) = Pr[a = a′ : b ← B, a ← (A|B = b), a′ ←
(A|B = b)].

Claim 1 (Statistical Distance vs Collision Probability [IZ89]). Let A be
a random variable supported over {0, 1}m such that SD(A,Um) ≥ ε, where Um

is uniform over {0, 1}m. Then Col(A) ≥ 1
2m (1 + 4Îľ2).

Furthermore, let A,B be correlated random variables, where A is supported
over {0, 1}m and

SD((A,B), (Um, B)) ≥ ε.

Then Col(A|B) ≥ 1
2m (1 + 4Îľ2).

Learning with Errors. The (n,m, q, χ) LWE assumption states that (A, sA + e)
is computationally indistinguishable from (A, u) where A ← Z

n×m
q , s ← Z

n
q ,

e ← χm and u ← Z
m
q . Throughout this work, the LWE assumption (without

qualification), refers to assuming that there exists some n = poly(λ), some q ≥
2ΝΊ(1)

and some distribution χ over Z which is poly(λ) bounded such that the
(n,m, q, χ) assumption holds for all m = poly(λ). This is implied by the hardness
of worst-case lattice problems with sub-exponential approximation factors.

Definition 4 (Pseudorandom Function (PRF) [GGM84]). A polynomial-
time function F : {0, 1}� × {0, 1}n → {0, 1}m with key length � = �(λ), input



Extracting Randomness from Extractor-Dependent Sources 323

length n = n(Îť) and output length m = m(Îť) is a PRF if for any polynomial-time
attacker A there exists some negligible function Îź(Îť) = negl(Îť) such that

| Pr[AF (k,·)(1λ) = 1] − Pr[AO(·)(1λ) = 1] | ≤ μ(λ).

where we choose k ← {0, 1}� and O : {0, 1}n → {0, 1}m is a uniformly random
function. We say that the PRF has security level σ = σ(λ) if μ(λ) ≤ 1/σ(λ).

Definition 5 (Constrained PRFs (CPRF) [BGI14,KPTZ13,BW13]). A
CPRF for a class of constraints C = {CÎť} consists of two polynomial-time algo-
rithms (F,Constrain) where:

– y = F (k, x) is a deterministic polynomial-time function that takes as input
a key k (either constrained or unconstrained) and a value x ∈ {0, 1}n and
outputs y ∈ {0, 1}m for some polynomial length parameters n = n(Ν),m =
m(Îť) in the security parameter Îť.

– k{C} ← Constrain(k,C) takes as input a key k ∈ {0, 1}λ and a constraint
C : {0, 1}n → {0, 1} with C ∈ Cλ. It outputs a constrained key, denoted
k{C}.

We require that the scheme satisfies a correctness and a security property defined
below:

Correctness: We require that no adversary can find an input which is not con-
strained, yet the constrained key disagrees with the original key. More con-
cretely, consider the following game between a stateful adversary A and a
challenger:
– The adversary A(1λ) chooses C ∈ Cλ.
– The challenger chooses k ∈ {0, 1}λ and k{C} ← Constrain(k,C).
– The adversary AF (k,·)(k{C}) gets the constrained key k{C} and oracle

access to F (k, ¡). It outputs a value x ∈ {0, 1}n.
We require that, in the context of the abov";"""date"",""2020-04-17T04:01:04Z""
""pdf:PDFVersion"",""1.6""
""xmp:CreatorTool"",""Springer""
""pdf:docinfo:title"",""Extracting Randomness from Extractor-Dependent Sources""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""Advances in Cryptology – EUROCRYPT 2020, doi:10.1007/978-3-030-45721-1_12""
""pdfa:PDFVersion"",""A-2b""
""xmpMM:History:Action"",""converted"",""converted""
""language"",""en""
""dc:format"",""application/pdf; version=""""A-2b"""""",""application/pdf; version=1.6""
""pdf:docinfo:custom:robots"",""noindex""
""pdf:docinfo:creator_tool"",""Springer""
""access_permission:fill_in_form"",""true""
""xmpMM:History:When"",""2020-04-17T09:30:07Z"",""2020-04-17T09:31:04Z""
""pdf:encrypted"",""false""
""dc:title"",""Extracting Randomness from Extractor-Dependent Sources""
""xmp:CreateDate"",""2020-04-17T09:28:01Z""
""modified"",""2020-04-17T04:01:04Z""
""cp:subject"",""Advances in Cryptology – EUROCRYPT 2020, doi:10.1007/978-3-030-45721-1_12""
""xmpMM:History:SoftwareAgent"",""pdfToolbox"",""pdfToolbox""
""pdf:docinfo:custom:CrossMarkDomains[1]"",""springer.com""
""robots"",""noindex""
""pdf:docinfo:subject"",""Advances in Cryptology – EUROCRYPT 2020, doi:10.1007/978-3-030-45721-1_12""
""pdf:hasMarkedContent"",""false""
""xmpMM:History:InstanceID"",""uuid:22cf17b9-4507-4ec8-8654-4b2b02f919d1"",""uuid:ad969984-fba2-43aa-a7b4-f03ab1d3831d""
""xmp:ModifyDate"",""2020-04-17T09:31:04Z""
""pdf:docinfo:creator"",""Yevgeniy Dodis ""
""meta:author"",""Yevgeniy Dodis "",""Vinod Vaikuntanathan "",""Daniel Wichs ""
""meta:creation-date"",""2020-04-17T03:58:01Z""
""pdf:docinfo:custom:CrossmarkMajorVersionDate"",""2010-04-23""
""created"",""2020-04-17T03:58:01Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-04-17T03:58:01Z""
""resourceName"",""10165162""
""pdfaid:part"",""2""
""pdf:docinfo:custom:CrossMarkDomains[2]"",""springerlink.com""
""pdf:docinfo:custom:doi"",""10.1007/978-3-030-45721-1_12""
""pdf:docinfo:custom:CrossmarkDomainExclusive"",""true""
""Author"",""Yevgeniy Dodis "",""Vinod Vaikuntanathan "",""Daniel Wichs ""
""CrossmarkDomainExclusive"",""true""
""doi"",""10.1007/978-3-030-45721-1_12""
""pdf:unmappedUnicodeCharsPerPage"",""1"",""0"",""0"",""0"",""0"",""0"",""1"",""0"",""5"",""13"",""4"",""10"",""0"",""12"",""15"",""12"",""26"",""20"",""14"",""42"",""4"",""21"",""23"",""4"",""20"",""23"",""16"",""0"",""0"",""0""
""dc:description"",""Advances in Cryptology – EUROCRYPT 2020, doi:10.1007/978-3-030-45721-1_12""
""access_permission:modify_annotations"",""true""
""dc:creator"",""Yevgeniy Dodis "",""Vinod Vaikuntanathan "",""Daniel Wichs ""
""description"",""Advances in Cryptology – EUROCRYPT 2020, doi:10.1007/978-3-030-45721-1_12""
""dcterms:created"",""2020-04-17T03:58:01Z""
""Last-Modified"",""2020-04-17T04:01:04Z""
""dcterms:modified"",""2020-04-17T04:01:04Z""
""title"",""Extracting Randomness from Extractor-Dependent Sources""
""xmpMM:DocumentID"",""uuid:3ed2177c-752f-4ff8-b32d-60c3bab7684a""
""Last-Save-Date"",""2020-04-17T04:01:04Z""
""CrossMarkDomains[1]"",""springer.com""
""pdf:docinfo:modified"",""2020-04-17T04:01:04Z""
""meta:save-date"",""2020-04-17T04:01:04Z""
""Content-Length"",""452149""
""Content-Type"",""application/pdf""
""xmp:MetadataDate"",""2020-04-17T09:31:04Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Yevgeniy Dodis "",""Vinod Vaikuntanathan "",""Daniel Wichs ""
""pdfaid:conformance"",""B""
""dc:language"",""EN""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""30""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""2346"",""2796"",""2841"",""2537"",""2724"",""2721"",""2773"",""2600"",""2165"",""2021"",""2029"",""1923"",""2636"",""2363"",""2330"",""2124"",""2132"",""1136"",""2052"",""2405"",""2517"",""2297"",""2455"",""2897"",""2752"",""2505"",""2356"",""2718"",""2802"",""1602""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""CrossMarkDomains[2]"",""springerlink.com""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-04-17T03:58:01Z""
""CrossmarkMajorVersionDate"",""2010-04-23""
";https://scholar.google.ch/scholar?start=940&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098729-23;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Compact storage of superblocks for nipopow applications;K Karantias, A Kiayias, D Zindros ; Mathematical Research for Blockchain …, 2020  Springer;;"… It follows directly from the Random Oracle model that \(\Pr [B \text { is a } \mu \text

{-superblock}|B \text { is a valid block}] = 2 … inclusive blockchain protocol changes in practice … Bellare,

M., Rogaway, P.: Random oracles are practical: a paradigm for designing efficient protocols …";Cité 6 fois;Les 5 versions;[PDF] allquantor.at;https://allquantor.at/blockchainbib/pdf/karantias2019compact.pdf;"
Compact Storage of Superblocks
for NIPoPoW Applications

Kostis Karantias1, Aggelos Kiayias2,4,
Nikos Leonardos3, and Dionysis Zindros3,4

1 University of Ioannina 2 University of Edinburgh
3 University of Athens 4 IOHK

Abstract. Blocks in proof-of-work (PoW) blockchains satisfy the PoW
equation H(B) ≤ T . If additionally a block satisfies H(B) ≤ T2−µ,
it is called a Âľ-superblock. Superblocks play an important role in the
construction of compact blockchain proofs which allows the compression
of PoW blockchains into so-called Non-Interactive Proofs of Proof-of-
Work (NIPoPoWs). These certificates are essential for the construction
of superlight clients, which are blockchain wallets that can synchronize
exponentially faster than traditional SPV clients.
In this work, we measure the distribution of superblocks in the Bitcoin
blockchain. We find that the superblock distribution within the block-
chain follows expectation, hence we empirically verify that the distribu-
tion of superblocks within the Bitcoin blockchain has not been adversar-
ially biased. NIPoPoWs require that each block in a blockchain points to
a sample of previous blocks in the blockchain. These pointers form a data
structure called the interlink. We give efficient ways to store the interlink
data structure. Repeated superblock references within an interlink can
be omitted with no harm to security. Hence, it is more efficient to store a
set of superblocks rather than a list. We show that, in honest executions,
this simple observation reduces the number of superblock references by
approximately a half in expectation. We then verify our theoretical result
by measuring the improvement over existing blockchains in terms of the
interlink sizes (which we improve by 79%) and the sizes of succinct NIPo-
PoWs (which we improve by 25%). As such, we show that deduplication
allows superlight clients to synchronize 25% faster.

1 Introduction

Bitcoin [20] and other blockchains which use the same backbone consen-
sus mechanism [12] use Simple Payment Verification (SPV) to shorten
the synchronization time for lightweight clients, where the clients need
to download block headers instead of whole blocks. Recently, a line of
work has introduced superlight clients, which do not require all block-
chain headers to be downloaded, but, rather, only a sample of them. This
sample consists of blocks which happen to achieve a higher difficulty than
the required one, and are thus termed superblocks.

1



By sampling the superblocks of a chain, short proofs about a block-
chain can be created, which allow a client to synchronize with the longest
blockchain without downloading all blocks. These so-called proofs of proof-
of-work contain only a small number of cleverly chosen superblocks which
compact the proof-of-work of the blockchain into a succinct string, while
maintaining the same security level as SPV clients. However, while the
protocol has even been deployed in practice, the distribution of superblocks
within a blockchain has not been previously measured. In this paper, we
provide measurements of this distribution for the Bitcoin blockchain.

In order for superblock sampling to work, it is necessary that each
block contains, in addition to the standard pointer to its previous block,
a few select pointers to some preceding superblocks. These pointers are
organized in a special data structure, the interlink. For relevant applica-
tions such as superlite clients and cross-chain transfers, it is critical that
the interlink structure is compact. We measure the size of the interlink
structure and provide a simple novel optimization which can bring down
its size to less than a half. We then study the impact of this improvement
on the size of proofs of proof-of-work.
Related work. Superblocks were first observed to exist in [19]. The in-
terlink data structure was put forth in [15], where it was also observed
that it can be organized into a Merkle tree. Interlinks containing all the
blocks of the blockchain have been proposed in [4]. Superblock interlinks
have been included from genesis in cryptocurrencies such as ERGO [8]
and nimiq [9]. Complete blockchain interlinks have been proposed for
Ethereum [6]. Nimiq and ERGO have independently applied interlink
deduplication in practice to save space [5,8]. In [16], the consumption of
the interlink data to construct Non-Interactive Proofs of Proof-of-Work
was presented and concrete numbers were given about the sizes of such
proofs. They also presented a way to construct such a structure without
a soft or hard fork, but a backwards compatible velvet fork, which was
later explored in [24]. Bitcoin Cash has been velvet forked in this man-
ner [13]. Beyond superlight clients, another application of NIPoPoWs are
cross-chain transfers [17] between proof-of-work blockchains. Comparable
constructions have also appeared for proof-of-stake blockchains [14].
Our contributions. The contributions of this paper are summarized as
follows:

1. We measure superblock distributions in Bitcoin. We observe that the
distribution of superblocks follows expectation, indicating there are no
ongoing or historical attempts to bias the distribution of superblocks

2



(so-called badness attacks [16]). We are the first to collect any empir-
ical measurements of superblocks on real blockchains.

2. We describe the simple but important optimization in regards to the
way blocks are compactly stored in an interlink tree by observing that
duplicate pointers can be removed without harming security. As such,
we construct interlink block sets instead of interlink block lists.1

3. We prove that our optimization reduces the number of pointers in
each interlink by a half in expectation.

4. We evaluate our improvement on the Bitcoin blockchain and collect
empirical data regarding the performance of our improvement, includ-
ing concrete sizes of NIPoPoWs built. We experimentally demonstrate
that our optimization reduces interlink vector sizes by 79% on aver-
age and the already very succinct NIPoPoW certificates by 25% on
average.

2 Superblocks and proofs-of-proofs

Blocks generated in proof-of-work [11] systems must satisfy the proof-
of-work equation H(B) ≤ T where T denotes the mining target [3]
and B denotes the block contents, which is a triplet including a rep-
resentation of the application data and metadata, a nonce, and a refer-
ence to the previous block by its hash. The function H is a hash func-
tion, modelled as a random oracle [2], which outputs Îş bits, where Îş is
the security parameter of the protocol and T < 2Îş. It sometimes hap-
pens that some blocks satisfy a stronger version of the equation [15],
namely that H(B) ≤ T2−µ for some µ ∈ N. Such blocks are called µ-
superblocks [16]. It follows directly from the Random Oracle model that
Pr[B is a µ-superblock|B is a valid block] = 2−µ. Note that if a block is
a µ-superblock for some µ > 0, then it is also a (µ − 1)-superblock. We
denote the maximum µ of a block B its level(B) = blg(T )− lg(H(B))c.

The count of superblocks in a chain decreases exponentially as Âľ in-
creases. If a blockchain C generated in an honest execution has |C| blocks,
it only has 2−µ|C| superblocks of level µ in expectation. Hence, the to-
tal number of levels is lg(|C|) in expectation. It has been theoretically
posed that the distribution of superblocks can be adversarially biased in
so-called “badness” attacks [16] in which an adversary reduces the den-
sity of superblocks of a particular level within a blockchain. However,
the actual distribution of superblocks in currently deployed blockchains

1 The deduplication optimization has already been discovered and deployed indepen-
dently by the Nimiq and the ERGO blockchains [5,8], but with no further analysis.

3



has not been measured. Therefore, it was previously unknown whether
such attacks are taking place in the wild. In this paper, we make em-
pirical measurements of superblock distributions and observe that they
follow the expectation. Hence, we conclude that widespread badness at-
tacks have not occurred in practice, confirming previous suspicions that
such attacks are costly to mount.

For any block B, it is useful to be able to refer to its most recent
preceding ¾-superblock for any ¾ ∈ N. In addition, it is useful to include
this reference within the contents of the block to which proof-of-work is
being applied so that the miner proves that she had knowledge of the
preceding superblock when B was generated. For this purpose, it has
been recommended [16] that for each block B, instead of including only
a pointer to the previous block, lg(|C|) pointers will be included, one for
each level Âľ pointing to the most recent Âľ-superblock preceding B. Hence,
under this modification, every block contains a pointer to its most recent
0-superblock ancestor, its most recent 1-superblock ancestor, and so on,
of which there are lg(|C|). These pointers change the blockchain into a
block skiplist [22,21].

These lg(|C|) pointers per block are called the interlink. One way to
include them is to replace the previd pointer, which in typical blockchains
points to the previous block hash, with the interlink list of block hashes
to be included verbatim in the block header. Alternatively, the interlink
list of hashes can be organized into a compact data structure such as a
Merkle tree [18] containing one leaf per superblock level Âľ. The number
of leafs in this Merkle tree is lg(|C|) and its height is lg lg(|C|). Hence,
proofs-of-inclusion in this Merkle tree are of size Θ(lg lg(|C|)). The root
of this Merkle tree can be included in the block header, replacing previd.
This is done in blockchains adopting interlinking from genesis or through
a hard fork [9,8].

More commonly, to avoid modifying the block header format, the
interlink Merkle tree root can be included in the block’s application data.
In this case, the root of the Merkle tree appears as auxiliary data within a
particular transaction which is included in the block. If the miners of the
blockchain are aware of the interlink, then it can be required that they
included it in their coinbase transaction. The veracity of the interlink
data does not need to be verified when it is included in a block, as invalid
or malicious data in the interlink does not harm security. Hence, it is
possible to include the interlink data in a user transaction. In this case,
the transaction which includes the root of the interlink is called a velvet
transaction and its inclusion is termed a user-activated velvet fork [13].

4



In practice, this transaction is implemented using an OP_RETURN [1]
committing to the Merkle tree root containing the interlink list in its
leafs. User-activated velvet forks allow the adoption of a new rule without
requiring miners to upgrade their software or be aware of the change, and
are hence backwards-compatible.

It is useful to be able to prove that a block B contains a pointer to a
particular ancestor B′ in its interlink. This statement is proven by a full
node who holds all blockchain data, the prover P , to a superlight verifier
V who holds only the header of block B. This proof is straightforward.
The header of block B contains the Merkle tree root of the transactions
tree mtr1 and is hence known to V . First, a Merkle tree proof-of-inclusion
π1 proves that mtr1 contains the velvet transaction tx. The velvet trans-
action tx commits to auxiliary data which includes the interlink Merkle
tree root mtr2. Secondly, another Merkle tree proof-of-inclusion π2 proves
that mtr2 contains the hash of B′. While we cannot improve the size of
π1, in this paper we describe the improvement in the size of π2.

Superblock pointers can be used to traverse the blockchain from the
tip back to Genesis in a manner which skips some unnecessary interme-
diary blocks and includes others. The idea is to convince a superlight
verifier V , which only has access to the Genesis block, that a particular
blockchain is the longest one without presenting all block headers. Blocks
of interest that are part of the longest chain can then be revealed to V in
order to convince them that a particular transaction has been confirmed.
In order to do that, P finds a succinct sample of blocks and places it
in chronological order. That sample is chosen such that each next block
within the sample contains a pointer to its immediate ancestor within the
sample by a commitment in the interlink vector. The prover P sends each
block of the sample to V , along with a proof-of-inclusion for the respective
pointer. The verifier V can check if the correct pointer has been included.
By cleverly choosing which blocks to collect, a full node can prove to a su-
perlight node that the currently adopted longest blockchain is the claimed
one without presenting the whole blockchain. Hence, instead of transmit-
ting data linear in the chain size Θ(|C|) as SPV clients do, it is sufficient to
transmit succinct certificates which are only of size Θ(poly log(|C|)). Such
certificates are called Non-Interactive Proofs of Proof-of-Work [16]. In
this paper, we are not concerned about the mechanism by which the NI-
PoPoWs protocol samples blocks, but only the number of blocks in these
samples and the sizes of their proofs-of-inclusion, which we optimize here.

The NIPoPoWs protocol is parameterized by a security parameter m.
The number of blocks |π| in a given Non-Interactive Proof of Proof-of-

5



Work sample is as follows. For each superblock level ¾ ∈ N, consider the
blocks in the honestly adopted blockchain C. Among these, some are of
level µ, so denote the count of µ-level superblocks in C as |C↑µ |. If |C↑µ | ≥
m, then we call Âľ an included level. Consider the maximum included level
max µ. It has been proven [16] that max µ = lg(|C|)− lg(m). The proof π
contains 1.5m blocks for the maximum included level and m additional
blocks for each lower level in expectation. Hence the number of blocks in
a NIPoPoW is |π| = 1.5m + mmax µ = 1.5m + m(lg(|C|) − lg(m)). For
each of these blocks, the proof contains the block hash and the respective
proofs-of-inclusion for the pointer to the preceding ancestor. In this paper,
we optimize the size of these proofs-of-inclusion, which gives a direct
improvement to the size of such proofs π. We note that, in our proposed
construction, we do not decrease the number of required blocks in π, only
the bytes that need to be transmitted for it on the network.

The size of these proofs is critical. As the majority of the time needed
for mobile wallets to perform the initial synchronization with the network
is spent on downloading block headers from the network, bringing down
the proof size directly improves the performance of superlight clients. In
the context of cross-chain transfers [17], these proofs are posted and per-
sistently stored in smart contracts [7,23] within blockchains which func-
tion as SPV verifiers for other blockchains [10]. Improving their size has
direct financial impact on the protocol, as a larger size incurs a larger gas
cost for storage purposes in case such proofs are stored within Ethereum.

3 Superblock distributions in deployed cryptocurrencies

We measured the superblock distribution in the mainnet Bitcoin block-
chain. Our results are illustrated in Figure 1. As expected, half the block-
chain blocks are 1-superblocks, 1/4 of blocks are 2-superblocks and gen-
erally approximately 2−µ of the blockchain blocks are µ-superblocks. The
horizontal axis denotes the block height, while the vertical axis denotes
the superblock density with respect to the variable difficulty target of
each block, in logarithmic scale.

We performed these measurements as follows. We downloaded the
whole bitcoin blockchain from the Genesis block up to the current tip
of the blockchain (at the time of writing 563,451). We then plotted the
density for each level Âľ = 0 . . . 6. For the particular level, we traversed
the blockchain using a sliding window of 1000(2Âľ) + 1 blocks. Within
that sliding window, we measured how many blocks of level Âľ exist, and
plotted the ratio of the count of these superblocks within the window to

6



0 100000 200000 300000 400000 500000
block height

2−6

2−5

2−4

2−3

2−2

2−1

20

su
pe

rb
lo

ck
de

ns
ity

0-superblocks
1-superblocks
2-superblocks
3-superblocks
4-superblocks
5-superblocks
6-superblocks

Fig. 1: Distribution of block levels in Bitcoin. Superblocks are with respect
to variable difficulty targets. Shaded area indicates ¹1σ.

the window size. The plot for level 0 is flat, as all blocks are 0-superblocks.
The high-frequency erratic behavior is due to the probabilistic nature of
block generation. We conjecture that lower frequency patterns, especially
those aligned between multiple levels, are due to difficulty adjustment
which incorrectly predicted the underlying computational power for a
given epoch (e.g., due to rapidly changing costs in mining hardware or
cryptocurrency prices).

4 Interlinks as sets of superblocks

In superblock-enabled blockchains, the interlink vector stored in each
block B contains one pointer per superblock level Âľ, namely a pointer
to the most recent superblock preceding B of the respective level Âľ. This
construction, known as an interlink list, is realized by inductively updat-
ing the interlink of the previous block, as shown in Algorithm 1. The al-
gorithm works as follows. Trivially, genesis has an empty interlink vector,
which forms our inductive basis. Given a newly mined block B′ which

7



already has an interlink vector (the inductive hypothesis), we wish to
construct the interlink vector to be included in the next block, which will
point to B′ itself as well as some of the blocks that B′ points to. This is
done by inspecting the existing interlink, B′.interlink, and constructing a
new interlink interlink by replacing all the entries in B′.interlink that are
of level less than or equal to that of B′ with B′ itself.

Algorithm 1 updateInterlink
1: function updateInterlink(B′)
2: interlink← B′.interlink
3: for µ = 0 to level(B′) do
4: interlink[µ]← H(B′)
5: end for
6: return interlink
7: end function

Algorithm 2 Our proposed algorithm, updateInterlinkSet
1: function updateInterlinkSet(B′)
2: interlinkSet← {H(B′)}
3: for H(B) ∈ B′.interlink do
4: if level(B) > level(B′) then
5: interlinkSet← interlinkSet ∪ {H(B)}
6: end if
7: end for
8: return interlinkSet
9: end function

Here, we make the simple observation that the interlink structure
constructed in this manner often contains duplicate pointers. In fact, as
we will show, most of the interlink pointers are duplicate. Space can be
saved by constructing an interlink set instead. This construction is shown
in Algorithm 2. The algorithm returns the exact same data structure as
Algorithm 1, but with duplicates removed. The algorithm operates as
follows. Given an existing interlink set, B′.interlinkSet, it produces a new
set interlinkSet which contains B′ and all the same blocks as B′.interlinkSet
with the exception of those that are of equal or inferior superblock level to
B′. Naturally, when this interlink set is to be committed to a Merkle tree,
it must be ordered in a canonical matter (for example, by increasing block

8



level) so that its root can be deterministically reproduced and detected.
This canonical ordering may now not be trivial as was in the case for
interlink lists and must be specified by the implementation.

We remark that it does not matter for security purposes whether
duplicates are removed. The reason is that the prover has access to the
whole list of blocks references within the interlink Merkle tree, and hence
can choose the one it needs. On the other hand, the verifier only needs
to ensure that the claimed superblock level is attained, but this can be
done directly by inspecting the hash sent to it by the prover.

We now analyze the savings attained by the above method. We first
analyze the savings in a thought experiment of an ideal, deterministic
execution of the blockchain protocol. While this setting is not realistic,
it provides good intuition about the interlink structure. Subsequently, we
analyze the real probabilistic blockchain protocol. Consider a blockchain
of n blocks.

Definition 1 (Interlink mask). Define the interlink mask of a block B
to be the bitstring containing one bit per superblock level Âľ. At the position
Âľ, the bitstring contains a 1 if the most recent Âľ-superblock ancestor of
B differs from the most recent (Âľ+ 1)-superblock ancestor of B, or if no
(Âľ+ 1)-superblock ancestor exists. Otherwise, it contains a 0.

This mask contains a 0 at the position of duplicates which can be
eliminated. To measure the efficiency of our optimization scheme, we wish
to count how many 0s are contained in the interlink mask of a given
block. Consider, for example, the block highlighted with a dashed border
in Figure 2. Its interlink vector will have an interlink mask of 0101. The
first 0 is due to the previous block which happened to be a 1-superblock.
The latter 0 is due to the most recent 3-superblock overshadowing the
preceding 2-superblock.

In our deterministic thought experiment, consider a blockchain which
grows as illustrated in Figure 2. In this blockchain, every block is a 0-
superblock, every other block is a 1-superblock, every fourth block is a
2-superblock and generally every 2Âľ-th block is a Âľ-superblock. In this
thought experiment, the interlink mask behaves like a binary number
which is increased by 1 after every block is generated. As such, it will be
a Âľ-digit binary number. As the process passes through all Âľ-digit binary
numbers, the number of 0s and 1s is on average equal. Hence, the savings
obtained in the deterministic case are exactly 50%.

9



0 0 0 0 0 00

22

1 1 1 1

3

0

4

Fig. 2: A thought experiment of a deterministically generated blockchain

Algorithm 3 The Turing Machine modeling interlink generation.
1: function run(tape)
2: µ← 0
3: while true do
4: b

$← {0, 1}
5: if b = 1 then
6: tape[µ]← 1
7: return
8: end if
9: tape[µ]← 0
10: µ← µ+ 1
11: end while
12: return tape
13: end function

Consider now the probabilistic setting of a real blockchain in an hon-
est execution, where each block generated has an independent probability
of belonging to a given level. The process of block generation can be mod-
elled precisely as follows. Consider the Turing Machine illustrated in Al-
gorithm 3. We begin with a one-sided infinite tape filled with the special
symbol t. We then run the machine illustrated in Algorithm 3 repeat-
edly over the same tape n times. Once we have completed the n runs, the
tape contains a binary string, which follows the same distribution as the
interlink mask of the nth block of a blockchain. Each run of Algorithm 3
corresponds to a generation of a block. The algorithm begins at the posi-
tion Âľ = 0 of the tape. It flips a fair coin b. If the coin turns out to be 1,
the machine writes 1 to the current position of the tape and exits. This is
the event that the block generated has level exactly 0. Otherwise, if the
coin b is a 0, then the block generated has level above 0, and so the first

10



position of the interlink mask will be overwritten by a 0. The machine
then advances and continues to flip coins and overwriting the tape with
0s until a 1 coinflip is attained, at which point it writes a 1 and halts. The
probability of the machine halting at position µ or later is 2−µ, modeling
the probability of a block being a Âľ-superblock. The machine overwrites
with 0 the positions in the tape which are of inferior level compared to
the block level it will generate at the given run. This is the same process
by which superblocks of higher level overshadow preceding superblocks of
lower levels by occupying their space with duplicate pointers that can be
eliminated.

Let Bn
¾ ∈ {0, 1} denote the random variable containing the value of

the Âľth digit after n such runs. We have that:

Pr[Bn
Âľ = 1] =

n∑
i=1

2−µ
n∏

j=i+1

µ−1∑
µ′=1

2−µ′ =
n∑
i=1

2−µ
n∏

j=i+1
(1− 21−µ) =

n∑
i=1

2−µ(1− 21−µ)n−(i+1)+1 = 1
2(1− (1− 21−µ)n)

Let Bn denote the number of 1s in the interlink mask after n runs.
Its expectation is then

E[Bn] = E[
∞∑
Âľ=1

Bn
Âľ ] =

∞∑
Âľ=1

1
2(1− (1− 21−µ)n) = 1

2

n∑
i=1

(−1)i+1
(
n

i

)
2i

2i − 1

We will now show that the savings from the interlink set technique
are significant, specifically that E[Bn] < 1

2 lg(n) +O(1).

Lemma 1. For any integers i > 0 and k ≥ 0,

2i
2i − 1 = 1

2(k+1)i − 2ki
+

k∑
j=0

2−ij

Proof. The left-hand side is an infinite geometric series:

∞∑
j=0

(2−i)j = 2i
2i − 1

We can split it up at some arbitrary index k ≥ 0:

11



∞∑
j=0

(2−i)j =
k∑
j=0

2−ij +
∞∑

j=k+1
(2−i)j

Applying the formula for geometric series sum from j = k + 1 to ∞
on the second term, we obtain:

k∑
j=0

2−ij +
∞∑

j=k+1
(2−i)j =

k∑
j=0

2−ij + 2−i(k+1)

1− 2−i =
k∑
j=0

2−ij + 1
2i(k+1) − 2ik

Lemma 2. For any positive integers n and k = dlg(n)e,

−
n∑
i=1

(−1)i
(
n

i

)
k∑
j=0

2−ij < lg(n) + 2

Proof.

−
n∑
i=1

(−1)i
(
n

i

)
k∑
j=0

2−ij = k + 1−
k∑
j=0

n∑
i=0

(−1)i
(
n

i

)
2−ij

= k + 1−
k∑
j=0

n∑
i=0

(
n

i

)
(−2−j)i

= k + 1−
k∑
j=0

(1− 2−j)n < lg(n) + 2

Lemma 3. For any positive integer n and k = dlg(n)e,

−
n∑
i=1

(−1)i
(
n

i

)
1

2(k+1)i − 2ki
< e

12



Proof.

−
n∑
i=1

(−1)i
(
n

i

)
1

2(k+1)i − 2ki
≤

n∑
i=1

(
n

i

)
1

2(k+1)i − 2ki

=
n∑
i=1

(
n

i

)
1

2ki(2i − 1)

≤
n∑
i=1

(
n

i

)
1

2ki

≤
n∑
i=0

(
n

i

)
1
ni

= (1 + 1
n

)n < e

Theorem 1 (Savings). E[Bn] < 1
2(lg(n) + 2 + e).

Proof.

E[Bn] = −1
2

n∑
i=1

(−1)i
(
n

i

)
2i

2i − 1

= 1
2((−

n∑
i=1

(−1)i
(
n

i

)
k∑
j=0

2−ij) + (−
n∑
i=1

(−1)i
(
n

i

)
1

2(k+1)i − 2ki
))

<
1
2((lg(n) + 2) + e)

We obtain that E[Bn] < 1
2(lg(n) + 2 + e). Therefore the expected

savings are lg(n)−E[Bn] > 1
2(lg(n)− 2− e). Solving 1

2(lg(n)− 2− e) > 0
we obtain that n > 26 is sufficient for savings to exist. We conclude that
the interlink set method performs better for blockchains with more than
26 blocks.

5 Empirical analysis of improvement

In order to empirically assess the space efficiency of our improvement, we
measured the size of the interlink data structure in the case of interlink

13



lists, the previously proposed format, and in the case of interlink sets, our
newly proposed format. We performed our measurements on the mainnet
for both Bitcoin and Litecoin. Our results are illustrated in Figure 3 and
are similar for both of these coins. The figures assume that both coins
have been velvet forked from their genesis blocks to include the particu-
lar interlink vector format. This is indicative of the future performance
of velvet forking each blockchain to add the respective interlink vector
format.

The new data structure format yields savings of approximately 79%
on average. Based on the theoretical analysis of Section 4, we expect to
see approximately an improvement of 50% in this structure. The extra
29% is due to the historical explosion of difficulty in the mining power
in both cryptocurrencies. The increased difficulty causes a lower variable
difficulty target, meaning that the lowest portions of the superblock levels
remain unoccupied, but are still accounted for in the interlink vector list
approach.

Based on the sizes attained in the interlink vector of the Bitcoin block-
chain, we organized the interlink vector into Merkle trees for both the list
and the set structure and created proofs-of-inclusion of which we mea-
sured the size. The sizes of the inclusion proofs for the two constructions
are illustrated in Figure 4, while the percentile savings are illustrated in
Figure 5.

Interlink size Proof-of-inclusion size NIPoPoW size
blockhashes bytes hashes bytes KB

Interlink lists 43.12 1380 5.7 183 65.7
Interlink sets 9.04 289 3.6 116 49

Table 1: A comparison of the two interlink constructions in terms of size.

We summarize the savings of our construction in Table 1. The table
was constructed by inspecting the Bitcoin blockchain at the time of writ-
ing. The interlink size column shows the average interlink vector size, in
the number of block hashes and in concrete bytes assuming the SHA256
function is used (as in Bitcoin). The proof-of-inclusion size column shows
the average size of a Merkle proof-of-inclusion, in the number of hashes
and in bytes, when the interlink vector is compacted into a Merkle tree
using SHA256. Finally, the NIPoPoW size column shows the size of a

14



0 100000 200000 300000 400000 500000
block height

10

20

30

40

50

60

#
of

bl
oc

k
id

s
in

in
te

rli
nk

ve
ct

or

Block List
Block Set

(a) Bitcoin

0 200000 400000 600000 800000 1000000 1200000 1400000
block height

10

20

30

40

50

60

#
of

bl
oc

k
id

s
in

in
te

rli
nk

ve
ct

or

Block List
Block Set

(b) Litecoin

Fig. 3: A comparison of interlink vector sizes for interlink block lists and
interlink block sets in two popular blockchains (lower is better)

15



0 100000 200000 300000 400000 500000
block height

2.5

3.0

3.5

4.0

4.5

5.0

5.5

6.0

#
of

bl
oc

k
id

s
in

in
te

rli
nk

in
cl

us
io

n
pr

oo
f

Block List
Block Set

Fig. 4: A comparison of a proof-of-inclusion size in the case of interlink
block lists and interlink block sets in Bitcoin (lower is better)

NIPoPoW in kilobytes (excluding the last k blocks of the chain which
must be sent verbatim irrespectively of which synchronization protocol is
used). The NIPoPoW sizes are calculated assuming Bitcoin had included
the respective interlink Merkle tree root in their headers since genesis. We
measured the size of suffix-proof NIPoPoWs based on the recommended
parameter m = 15 [16] assuming a chain size of |C| = 563,451. The
number of blocks in a NIPoPoW is (m(lg |C| − lgm) + 1.5m) = 250 in
expectation. For the final size calculation of the NIPoPoW, we included
all the data required: The proofs-of-inclusion (based on the size given on
the previous column) and the block headers needed (80 bytes per block).
Our results indicate 79% savings in the interlink sizes and 25% savings
in the NIPoPoW sizes.

16



0 100000 200000 300000 400000 500000
block height

15

20

25

30

35

40

45

50
in

te
rli

nk
in

cl
us

io
n

pr
oo

fs
av

in
gs

(%
)

Fig. 5: Percentile savings of the block set construction compared to the
block list construction.

References

1. Massimo Bartoletti and Livio Pompianu. An analysis of Bitcoin OP_RETURN
metadata. In International Conference on Financial Cryptography and Data Se-
curity, pages 218–230. Springer, 2017.

2. Mihir Bellare and Phillip Rogaway. Random oracles are practical: A paradigm
for designing efficient protocols. In V. Ashby, editor, ACM CCS 93, pages 62–73.
ACM Press, November 1993.

3. Joseph Bonneau, Andrew Miller, Jeremy Clark, Arvind Narayanan, Joshua A.
Kroll, and Edward W. Felten. SoK: Research perspectives and challenges for
bitcoin and cryptocurrencies. In 2015 IEEE Symposium on Security and Privacy,
pages 104–121. IEEE Computer Society Press, May 2015.

4. Benedikt BĂźnz, Lucianna Kiffer, Loi Luu, and Mahdi Zamani. FlyClient: Super-
Light Clients for Cryptocurrencies. Cryptology ePrint Archive, Report 2019/226.
https://eprint.iacr.org/2019/226, 2019.

5. Sven Buschbeck. Nimiq developer reference. Available at: https://nimiq-
network.github.io/developer-reference/chapters/block.html#interlink,
2018.

6. Vitalik Buterin. EIP 210: Blockhash refactoring. Technical report, Feb 2017.
7. Vitalik Buterin et al. A next-generation smart contract and decentralized appli-

cation platform. white paper, 2014.

17

https://eprint.iacr.org/2019/226
https://nimiq-network.github.io/developer-reference/chapters/block.html#interlink
https://nimiq-network.github.io/developer-reference/chapters/block.html#interlink


8. Alexander Chepurnoy, Dmitry Meshkov, Ilya Oskin, Mike Aksarin, Andrey An-
dreev, Alexander Slesarenko, Denys Zadorozhnyi, and Guillermo Manzanares.
Ergo. Available at: https://ergoplatform.org, 2018.

9. Elion Chin, Philipp von Styp-Rekowsky, and Robin Linus. Nimiq. Available at:
https://nimiq.com, 2018.

10. Georgios Christoglou. Enabling crosschain transactions using NIPoPoWs. Master’s
thesis, Imperial College London, 2018.

11. Cynthia Dwork and Moni Naor. Pricing via processing o";"""date"",""2019-12-11T23:48:01Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2019-12-11T23:48:01Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.19 (TeX Live 2018) kpathsea version 6.3.0""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2019-12-11T23:48:01Z""
""created"",""2019-12-11T23:48:01Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-12-11T23:48:01Z""
""resourceName"",""karantias2019compact.pdf""
""Author"",""""
""producer"",""pdfTeX-1.40.19""
""pdf:docinfo:producer"",""pdfTeX-1.40.19""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""2"",""0"",""2"",""0"",""1"",""18"",""0"",""1"",""15"",""31"",""25"",""0"",""0"",""0"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2019-12-11T23:48:01Z""
""Last-Modified"",""2019-12-11T23:48:01Z""
""dcterms:modified"",""2019-12-11T23:48:01Z""
""title"",""""
""Last-Save-Date"",""2019-12-11T23:48:01Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2019-12-11T23:48:01Z""
""meta:save-date"",""2019-12-11T23:48:01Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.19 (TeX Live 2018) kpathsea version 6.3.0""
""Content-Length"",""1328311""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""18""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""2092"",""2306"",""2132"",""2311"",""2385"",""2240"",""1136"",""1432"",""2082"",""1116"",""1158"",""439"",""656"",""1866"",""356"",""904"",""1235"",""2373""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-12-11T23:48:01Z""
";https://scholar.google.ch/scholar?start=570&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098813-213;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Livestock Welfare by Means of an Edge Computing and IoT Platform;M Öztürk, RS Alonso, Ó García… ; … Symposium on Ambient …, 2020  Springer;;"… benefits in terms of security, traceability and data integrity, due to the characteristics provided

by the elements associated with the Distributed Ledger Technologies of the Global Edge

Computing Architecture, including the blockchain itself and the Crypto-IoT boards and oracles …";Autres articles;;null;;;;https://scholar.google.ch/scholar?start=760&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098791-170;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Blockchain meets cloud computing: a survey;K Gai, J Guo, L Zhu, S Yu ; IEEE Communications Surveys & …, 2020  ieeexplore.ieee.org;;"… The success of blockchain in cryptocurrency leads a tide of blockchain-based digital currency

or … IBM BaaS is attempting to provide services for vehicular systems [39]; Oracle BaaS is … Microsoft

Azure [41] is a cloud platform that provides the fast blockchain deployment, which …";Cité 16 fois;Les 3 versions;null;;;;https://scholar.google.ch/scholar?start=710&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098800-186;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Bypassing non-outsourceable proof-of-work schemes using collateralized smart contracts;A Chepurnoy, A Saxena ; … Conference on Financial Cryptography and Data …, 2020  Springer;;"… Another threat, especially for new cryptocurrencies are potential Goldfinger attacks using hosted

mining services to rent mining power in order to mine (or attack) a cryptocurrency [2] … In P2Pool,

this oracle is implemented using another blockchain, while in …";Cité 1 fois;Les 4 versions;[PDF] iacr.org;https://eprint.iacr.org/2020/044.pdf;"
Bypassing Non-Outsourceable Proof-of-Work
Schemes Using Collateralized Smart Contracts

Alexander Chepurnoy1,2, Amitabh Saxena1

1 Ergo Platform
{kushti}@protonmail.ch, {amitabh123}@gmail.com

2 IOHK Research
{alex.chepurnoy}@iohk.io

Abstract. Centralized pools and renting of mining power are considered
as sources of possible censorship threats and even 51% attacks for de-
centralized cryptocurrencies. Non-outsourceable Proof-of-Work schemes
have been proposed to tackle these issues. However, tenets in the folk-
lore say that such schemes could potentially be bypassed by using es-
crow mechanisms. In this work, we propose a concrete example of such a
mechanism which is using collateralized smart contracts. Our approach
allows miners to bypass non-outsourceable Proof-of-Work schemes if the
underlying blockchain platform supports smart contracts in a sufficiently
advanced language. In particular, the language should allow access to the
PoW solution. At a high level, our approach requires the miner to lock
collateral covering the reward amount and protected by a smart contract
that acts as an escrow. The smart contract has logic that allows the pool
to collect the collateral as soon as the miner collects any block reward.
We propose two variants of the approach depending on when the collat-
eral is bound to the block solution. Using this, we show how to bypass
previously proposed non-outsourceable Proof-of-Work schemes (with the
notable exception for strong non-outsourceable schemes) and show how
to build mining pools for such schemes.

1 Introduction

Security of Bitcoin and many other cryptocurrencies relies on so called Proof-of-
Work (PoW) schemes (also known as scratch-off puzzles), which are mechanisms
to reach fast consensus and guarantee immutability of the ledger. Security of such
consensus mechanisms is based on the assumption that no single entity controls a
large part of the mining power. For example, if a single entity controls 33% then
it can earn unproportionally more rewards using selfish mining [1], and with more
than 50% an adversary can do double spending or filter out certain transactions.
However, individually, it is more beneficial for a miner to join a pool despite the
fact that it is detrimental to the system as a whole since it causes concentration of
mining power. Another threat, especially for new cryptocurrencies are potential
Goldfinger attacks using hosted mining services to rent mining power in order to
mine (or attack) a cryptocurrency [2]. Non-outsourceable scratch-off puzzles have



been proposed to address these issues [3,4], whose primary goal is to discourage
pooled mining. Such approaches require reward spending to depend on some
trapdoor information used in solution generation. A notable example of a real
world implementation of this idea is Ergo [5], whose PoW, Autolykos [6], is based
on [4]. In this work, we describe how to bypass the non-outsourceability of many
such schemes, including Ergo. While our solution bypasses non-outsourceability,
which gives the ability to form pools, we still retain a level of decentralization
in our solution. In particular, our approach retains the censorship resistance
property of non-outsourceable puzzles (see Section 2.2 for details.

The rest of the paper is organized as follows. Section 2 contains an overview
of the current state of affairs in proof of work schemes and pooled mining along
a high level overview of non-outsourceable puzzles. Section 3 describes one ap-
proach for creating mining pools in many types of non-outsourceable puzzles,
specifically those of [4]. Section 4 describes another approach that covers a wider
range of puzzles [4,3]. We conclude the paper in Section 5 along with pointers
for future research.

2 Background

2.1 Proofs of Work

We first describe the vanilla PoW mechanism used in Bitcoin. A miner collects
a number of unconfirmed transactions and builds a Merkle tree on top of them.
The digest of this tree, denoted t here, is stored in a section of the block called
the block header, which also includes the hash of the previous block’s header
h and a random string n called the nonce. We use the term m to denote the
puzzle made of the concatenation of the Merkle tree digest and the hash of the
previous block. That is, m = t‖h and then the header is of the form m‖n. The
solution is also determined by another parameter Îť > 1, called the difficulty.
Let H be a collision resistant hash function with output of 256 bits. The header
m‖n is considered a valid solution if H(m‖n) ≤ 2256/λ. A miner repeatedly tries
different values of n (and possibly m) until a solution is found. Since H is like
a random oracle, the probability of finding a solution in one attempt is 1/Îť. All
PoW systems use the above idea of finding a value from a uniform distribution
that falls within some narrower range based on the difficulty parameter.

2.2 Pooled Mining

Bitcoin allows mining pools, which roughly work as follows. The pool distributes
work based on a some m that it decides. Each miner tries to find a solution for
the given m and any solution found is sent to the network. A miner actually tries
to find a share, which is like a solution but with reduced difficulty (also decided
by the pool). Some of the shares may also be real solutions, which result in valid
blocks. A miner gets paid by the number of shares submitted. This is possible
because the Bitcoin PoW puzzle is a scratch-off puzzle [3], a type of PoW puzzle



that can be processed in parallel by multiple non-communicating entities with
an appropriate reduction in search time.

The pool generates the potential block candidates as if it was solo mining, and
then distributes that candidate to its miners for solving, which can be considered
workers for the pool. The shares have no actual value and are just an accounting
tool used by the pool to keep track of the work done by each worker. The
key observation with pools is that miners do work for some other entity who
then distributes the rewards back to the workers. Since the pool selects the
transactions that are to be included, this gives the pool greater control over the
entire blockchain network. We define this using three levels of (de)centralization
that a pool may operate at.

1. Level 1 (Centralized): The pool operator defines both m and the reward
address. Thus, a pool operator has full control over which transactions are
included (censorship) and also carries the risk of losing the rewards.

2. Level 2 (Censorship Resistant): The pool operator does not define m but
collects the rewards. This is resistant to censorship but still carries the risk
of losing the rewards.

3. Level 3 (Decentralized): There is no centralized pool operator but rather
another decentralized oracle that emulates the pool operator and rewards are
automatically given to the participants based on the shares they submitted
(see P2Pool [7] for Bitcoin and SmartPool [8] for Ethereum). In P2Pool, this
oracle is implemented using another blockchain, while in SmartPool, it is
implemented using a smart contract.

The following table summarizes the concepts.

Pool level Censorship Reward theft risk Example
L1 (Centralized) Yes Yes BTC.com
L2 (Censorship Resistant) No Yes ErgoPool (this work)
L3 (Decentralized) No No SmartPool[8], P2Pool [7]

The primary issue with pools is that they increase the potential of transaction
censorship and 51 percent attacks. One way to address this issue is to disallow
pools entirely. This is what non-outsourceable puzzles aim to achieve, and Ergo
is the first practical implementation of such puzzles [5]. Thus, such puzzles are
designed to provide the same level of security as an L3 pool.

We, however, note that disallowing pools entirely comes with its own set of
problems. For instance, at Ergo launch, the difficulty went up so quickly that
miners with single GPUs could not find any blocks in a reasonable time. Since
Ergo does not allow pools, such miners had no incentive to continue mining.
In fact, this research was motivated from the need to create a mining pool for
Ergo. However, we also want our solution to retain the security offered by lack
of pools, that is, resistance to censorship and 51% attacks.

Our solution is based on the observation that another way to address cen-
sorship and 51 percent attacks is to have pools operate at levels L2 or L3, where



these issues are not present. Thus, not only can we have decentralization in min-
ing but also have all the benefits of pools (such as regular income for miners
and thereby, stronger network). Our solution is designed for L2 but can also be
trivially extended to operate at L1. Additionally, it may be possible to extend
it to L3 using approaches similar to SmartPool or P2Pool, which we leave as a
topic for further research.

2.3 Non-Outsourceable Puzzles

We start with overviewing (non-)outsourceability definitions in existing litera-
ture expressed in different works, such as Non-outsourceable Scratch-Off Puz-
zles [3], 2-Phase Proof-of-Work (2P-PoW) [9], PieceWork [4], Autolykos [6]. The
details of these approaches are described in Sections 3 and 4. However, at a high
level, all these approaches can be broadly classified into two categories.

In the first one [6,4,9], which we call Type 1, a PoW scheme is considered
non-outsourceable if it is not possible to iterate over the solution space without
knowing some trapdoor information (such as a secret key) corresponding to some
public information (such as a public key) contained in the block header, with
block rewards locked by that trapdoor information. The reasoning here is that
in order to send the reward to a pool’s address, each miner must know the secret
corresponding to that address. However, a pool does not trust miners and so will
not give the secret away to them.

In the other category [3], called Type 2, a PoW scheme is considered non-
outsourceable if for any solved block, a miner can generate another block effi-
ciently with non-negligible probability. The motivation behind this definition is
that a miner can get paid for shares by trying to generate a block that pays the
reward to the pool. In case of successful block generation, however, the miner
could generate and broadcast another block that sends the reward to the miner
instead of the pool. We further classify Type 2 into weak if the identity of the
miner stealing the rewards can be ascertained and strong if the identity remains
secret.

At a technical level, both Type 1 and 2 approaches rely on a miner’s ability
to steal the pool’s rewards. The difference lies in the way this occurs. In Type
1 schemes, the miner is able to steal the reward after the block gets finalized.
In Type 2, the reward can only be stolen before a block is finalized into the
blockchain.

We note that all Type 2 schemes have an inherent problem that allows ma-
licious actors to flood the network with a large number of valid but distinct
solutions, thereby causing network partitions and instability. This causes the
network to converge very slowly or result in several forks. Hence, we don’t con-
sider Type 2 schemes to be robust in reaching consensus, thereby making them
impractical in the real world. We call this the forking attack. Strong Type 2
schemes are even more prone to this attack because there is no fear of detection.

In this work, we bypass the non-outsourceability of all Type 1 and weak Type
2 schemes assuming that their platforms support some minimal smart contract
capability. The following table summarizes this.



Puzzle type Thief’s identity When rewards stolen Forking attack Bypassed
1 revealed after block acceptance no yes
2 (weak) revealed before block acceptance yes yes
2 (strong) secret before block acceptance yes no

2.4 Execution Context in Smart Contracts

To give understanding of how a smart contract can bypass non-outsourceability,
we first explain what kind of data the contract can access.

In PoW currencies, a block contains a compact section called the header,
which is enough to verify the PoW solution and check integrity of other sections
(such as block transactions).

Execution context is what is available to a contract during execution. Con-
sidering UTXO-based cryptocurrencies, such as Bitcoin and Ergo, we can think
about following components of the execution context. At the bare minimum, the
first level, the smart contract should have access to the contents of the UTXO it
is locking (i.e., its monetary value and any other data stored in it). At the second
level, the smart contract may additionally have access to the spending transac-
tion, that is, all its inputs and outputs. At the third level, the smart contract
may have access to block header data in addition to the data at the second level.
For example, in Ergo, the last ten block headers and also some parts of the next
block header (which are known in advance before the next block is mined) are
also available in the execution context. Finally, at the fourth level, the execution
context may contain the entire block with all sibling transactions. Note that
since the execution context must fit into random-access memory of commodity
hardware, accessing the full blockchain is not a realistic scenario. The following
table summarizes possible execution context components.

Context level UTXO Transaction Header Block Example
C1 Yes No No No Bitcoin [10]
C2 Yes Yes No No –
C3 Yes Yes Yes No Ergo [5]
C4 Yes Yes Yes Yes –

3 Pooled Mining in Type 1 Puzzles

In a nutshell, Type 1 puzzles use a combination of two approaches: (1) The first
approach is to replace the hash function with a digital signature (i.e., use public-
key cryptography instead of symmetric key cryptography for obtaining the final
solution) and (2) The second approach is to tie the public key to the rewards.

3.1 Using Public-Key Cryptography

The method requires a randomized signature scheme that is strongly unforgeable
against adaptive chosen message attacks (s-UFCMA) and outputs signatures



uniformly spread over some range irrespective of how the signer behaves. Schnorr
signature is one such scheme [11].

A candidate block header is constructed using transactions as in Bitcoin along
with a public key p. A valid block header is a candidate block header along with
a signature d that (1) verifies with this public key and (2) satisfies the difficulty
constraints as before (i.e., is less than a certain value). The difficulty parameter
is automatically adjusted as in Bitcoin.

One real-world implementation of this concept is Autolykos [6], the PoW
algorithm of Ergo [5]. Autolykos uses a variation of Schnorr signatures [11],
where the goal of a miner is to output d such that d < 2256/Îť and Îť is the
difficulty parameter. The value d is to be computed as follows. First compute
r = H(m‖n‖p‖w) where m is the transactions digest, n is a nonce, p is a public
key (an elliptic curve group element) and w is an ephemeral public key that
should never be reused in two different blocks. Let x be the corresponding private
key of w. Compute d = xr − s, where s is the private key corresponding to p.

3.2 Tying Public-Key to Rewards

The second technique in making a Type 1 pool-resistant scheme is to tie the
rewards to the public key p contained in the block solution. That is, the platform
enforces that any mining rewards are protected by the statement prove knowledge
of secret key corresponding to the public key p (from the block solution)

We consider Ergo as an example here. Rather than enforcing this logic within
the protocol, Ergo uses smart contracts to enforce it. In particular, this rule is
enforced in a so called Emission box3, a UTXO which contains all the ergs
(Ergo’s primary token) that will ever be emitted in rewards. The box is protected
by a script that enforces certain conditions on how the rewards must be collected.
In particular, it requires that a reward transaction has exactly two outputs,
such that the first is another emission box containing the remaining ergs and
the second is a box with the miners reward protected with the following script:
prove knowledge of the discrete logarithm (to some fixed base g) of group element
p AND height is greater than or equal to the box-creation height plus 720. This
is possible because Ergo’s (level C3) context includes the block solution.

The above approach ensures that the private key used for finding the block
solution is also needed for spending the rewards. Consequently, anyone who
finds a block also has the ability to spend those rewards. If we try to create
any standard type of pool, we find that anyone having the ability to find a
solution also has the ability to spend (i.e., steal) the reward. In fact, any standard
pool must share the same private key among all participants, thereby making
it impossible to determine the actual spender. This restriction also applies to
decentralized schemes such as P2Pool and SmartPool because they both require
that rewards be sent to addresses not under the miner’s control.

3 A box is just a fancy name for a UTXO. We will use these two terms interchangeably.



3.3 Creating a Mining Pool

We now describe a pooling strategy for bypassing any Type 1 scheme, provided
that the underlying smart contract language supports context level C3 or higher
(see Section 2.4). Hence one way to mitigate our method would be to restrict
the smart contract language to level C2 or lower. Our concrete implementation
uses Ergo as the underlying platform, which supports C3 context.

We will follow the pay-per-share approach, where the reward is distributed
among the miners based on the number of shares they submitted since the last
payout. Our pool is designed to operate at centralization level L2, where the
pool only collects the rewards but does not select transactions (see Section 2.2).
Hence, it provides resistance against censorship and does not encourage 51%
attacks that are possible at L1. Note that the pool could also operate at L1 by
creating miner-specific blocks using pair-wise shared public keys. However, this
increases computational load on the pool and overall network usage, thereby
reducing efficiency.

Basic variant: We first describe a basic version that is insecure, and thereby
does not work in practice. We then incrementally enhance this version to patch
the vulnerability to obtain the full version.

The key observation in our approach is that in a valid share, the reward need
not necessarily be sent directly to the pool’s address. What is actually necessary
is that an amount equivalent to the reward is sent to the pool’s address. This
simple observation allows us to create a pool with the following rules:

1. Each miner can send the reward to his own public key p, whose secret key
only he knows (reward transaction).

2. The block must also have another transaction sending the same amount as
the reward to the pool address (pool transaction).

A valid share is a solution to a block with the above structure. A miner can
efficiently prove that a share is valid without having to send the entire block to
the pool. It can simply send the pool transaction along with the Merkle proof
that validates that the transaction [12]. A pool operator collects such shares
(along with the proofs) and any funds thus received when a block is solved
are distributed among the miners using the pay-per-share algorithm. To ensure
that miners generate valid blocks, the pool randomly asks miners to provide full
blocks corresponding to some of their shares and penalize those who cannot.

One drawback of this is that each miner must have sufficient collateral to
cover the reward amount at any time, even though the reward becomes spendable
only after a ‘cooling-off period’ (720 blocks in Ergo). Thus, there is a minimum
period during which the collateral is spent but the reward is locked and cannot
be used as further collateral. Therefore, for uninterrupted mining, each miner
must keep the reserved amount of at least 2 rewards (possibly more depending
on the expected time to find a block).

To overcome this drawback, a pool may provide incentives such as allowing
the miner to keep a fraction of the reward (example for the current reward of
67.5 ergs in Ergo, the pool may require only 65 ergs to be sent to it).



The broadcast attack: Let Alice be a miner with public key alice. If
such a system is used in, say Bitcoin, then the system becomes insecure. Once
the pool-paying transaction is publicized, anyone (not necessarily Alice) may
broadcast it (possibly by using it as their own pool transaction).

Enhanced variant: The enhanced protocol mitigates the above attack. This
is possible because ErgoScript allows us to use the block solution in the context,
using which we can secure the pool transaction as follows. Instead of paying to
the pool from an arbitrary box (or boxes), Alice will instead store this collateral
in a special box protected by the following script:

minerPubKey == alice

A box with this script does not require a signature because the above state-
ment only fixes the miner’s public key to alice and does not enforce any other
spending condition. Thus, anyone can create a transaction spending this box.
However the transaction is valid only if the block that includes it is mined by
Alice. This ensures that the box can only be spent if and when Alice mines a
block. Alice creates her pool transaction using this box as input and submits her
shares and proofs to the pool as before. She need not even use a private channel
for this purpose and can broadcast this publicly. This enables the possibility of
L3 decentralization level that requires public shares [7,8] (see Section 2.2).

The above variant prevents the broadcast attack because knowing the pool
transaction does not help the attacker in any way (since anyone can create
that transaction without Alice’s help). An attacker might try to spend Alice’s
collateral in a transaction paying to some address other than the pool address.
However, Alice will discard such transactions when creating a candidate block
and only include her pool paying transaction that spends the collateral. In the
worst case, if Alice does not check for others spending her collateral, the mined
block will still include her own pool-paying transaction double-spending the same
collateral, thereby making the entire block invalid.

Full variant: Observe that the above collateral box is not spendable until
Alice actually mines a block. Depending on her hardware and the global hash
rate, this may take a very long time, and her funds will be stuck till then. We
would like Alice to be able to withdraw her collateral at any time she decides
to stop participating in the pool. This can be done as follows. Alice first sets
another public key aliceWithdraw that she will use to withdraw the collateral
(it is possible to keep aliceWithdraw = alice). The modified script is:

(minerPubKey == alice) || aliceWithdraw

The first condition, minerPubKey == alice, ensures that when used to fund
the pool output, the miner must be Alice as in the enhanced variant. The second
condition, bob, ensures that the coins are not stuck till Alice finds a block,
because it allows Alice may withdraw the collateral at any time. Alice should
fund the pool transaction by satisfying only the first condition and never the
second condition, otherwise the broadcast attack becomes possible. The second
condition is be used only for withdrawing collateral.



Note that the above allows everyone to create a transaction spending Alice’s
collateral box as long as Alice mines the transaction. Alice may have more than
one collateral box protected by identical scripts. Thus, an attacker may try to
spend Alice’s box that is not used in the pool funding transaction. Of course,
Alice should not include such transactions in her block. This requires Alice to
implement additional checks. An easier solution is for Alice to use another public
key, aliceLock, as below to ensure that only she can create a valid transaction.

((minerPubKey == alice) && aliceLock) || aliceWithdraw

The above broadcast attack mitigation strategy requires C3 context level (i.e.,
access to minerPubKey) and will not work in lower levels. One may envisage a
hiding strategy at C2 context level, where the pool transaction is not revealed
in a share (only a commitment is revealed). The actual transaction is revealed
only if a block is found or when a miner later proves to the pool that the
shares were correct. However, this is also insecure. First note that there are two
types of broadcast attacks. The first is the leak-from-share attack. The second
is the leak-from-orphaned-block attack, where the transaction is extracted from
a mined block that ends up getting orphaned. The hiding strategy mitigates the
first attack but not the second.

Weak Broadcast security: We can obtain a weaker form of broadcast
security for C2 context level by assuming a trusted pool as follows. A pool-paying
transaction is created as before by spending some arbitrary input and paying to
the pool address. The miner sends the shares along with the proofs to the pool
over a private channel. The pool is trusted not to misuse the transaction. This
addresses the leak-from-share attack. To address the leak-from-orphaned-block
attack, the following strategy is used. Assume that the box funding the pool
transaction contains a unique identifier of Alice (such as her public key) and a
script that enforces any spending transaction to pay the pool. Lets us call this
Alice’s funding box. The pool then enforces the following rules internally.

1. Any transaction it receives from Alice’s funding box that was not mined by
Alice is considered irregular.

2. Any irregular transaction using Alice’s funding box is not considered for pool
reward disbursement and the funds are refunded back to Alice.

It is possible for everyone to verify that a given pool transaction is irregular
if everyone knows Alice’s public key. Thus, a pool cannot deny the existence
of an irregular transaction. Refunds can also be made verifiable in many ways,
such as by requiring the pool to create another funding box for Alice, which can
be publicly verified. We can additionally require that the new funding box be
created in a transaction that consumes the irregular transaction’s output.

4 Pooled Mining with Type 2 Puzzles

In Type 2 puzzles, a miner can produce (with non-negligible probability) an
alternative block for the same PoW solution [3]. For concreteness, we will use



public key cryptography to illustrate this, as we did for Type 1 puzzles. However,
our approach will work for any other implementation of such puzzles.

Recall that a Type 1 puzzle comprises of two steps: (1) embedding a public
key p in the block header, whose private key is needed in generating the solution,
and (2) tying the block rewards to p. A Type 2 puzzle can be considered a
variation of a Type 1 puzzle, where Step 1 remains the same but Step 2 is
modified so that the block rewards are not tied to p but instead to another public
key a that is certified by p. In other words, the complete solution is defined using
a tuple (p, a, certp(a)), where certp(a) is a signature on a that verifies with p.

The rationale behind non-outsourceability is that a cheating miner knowing
the private key of p can steal the reward as follows. When claiming shares, the
miner behaves correctly. That is, it constructs the block so that rewards go to
the pool public key a. However, if a real solution is found, the rewards are sent
to the miner public a′ by creating a certificate certp(a′). Thus, as in Type 1
puzzles, the pool risks losing rewards if it shares secrets with miners.

Watermarking: In the basic Type 2 scheme, a pool can make it possible to
identify stolen rewards by publicly fixing a watermark identifying its blocks in
advance [3]. A watermark in this context is something that is preserved even if
the pool key a is replaced by the miner key a′. A few examples are the certifying
key p or, say, half the bits of the nonce. If such a watermark is used then it
becomes possible to identify the cases when the block rewards are stolen.

Strong Type 2 puzzles: In the above design, it is possible to determine
when the rewards are stolen. For instance, using the public key p as a watermark,
a pool may declare in advance that for a given p, it only considers the pair (p, a)
as valid and any other pair (p, a′) indicates a theft. The stronger variant of Type
2 puzzles replaces signatures with zero knowledge proofs so that the two cases
(block rewards stolen or not) become indistinguishable. Any Type 2 puzzle that
is not strong is called weak.

We describe a smart contract that bypasses both Type 1 and (weak) Type 2
schemes. For sake of brevity, however, we only describe the Type 2 solution here.
Recall that for such schemes, it is possible to detect when a particular watermark
is being used in the block. In our approach, this watermark is attached to the
miner instead of the pool. Thus, the pool with share pair-wise watermarks with
every miner. Similar to the previous approach, we will also require the miner to
lock some collateral that can be used by the pool to cover any rewards taken by
the miner. We also require the smart contract language to make available in the
execution context the block solutions for not only the current block header but
also the last L block header prior to the current one.

Then a weak Type 2 scheme can be bypassed as follows. In order to partici-
pate in the pool, Alice creates an unspent box that locks collateral with the guard
script: payable to pool public key if at least one of the last L headers contains
the watermarked solution. The same solution will also work for Type 1 schemes
there because the block header cannot be efficiently altered without also altering
the embedded public key. In ErgoScript, for example, this can be implemented
as: poolPubKey && lastHeaders.exists( .minerPubKey == alice).



The method exists of lastHeaders takes as input another method, say f ,
that takes as input an header and outputs a Boolean. The method f is applied
to every element of lastHeaders and the output of exists is the OR of the
outputs of f . In this case, f outputs true if the miner public key in the header
is Alice’s public key.

A miner is permitted to send the reward to any chosen address, since as soon
as a valid block is generated, the collateral becomes spendable by the pool. One
way the miner can try to save the collateral is to generate L blocks after the one
with the watermark, but this case is unlikely for a pool user if L is big enough.
In Ergo, for example, L = 10, and the chance to generate 11 consecutive blocks
is very small [10].

Note that the above script locks the collateral until Alice find a block, which
may never happen. Hence, as in the Type 1 case, we need to allow Alice to
withdraw collateral if she desires. However, the solution used in Type 1 (i.e.,
simply appending ‘|| aliceWithdraw’) will not work here because the pool
does not immediately get the collateral when Alice gets the reward, but rather
after at most L blocks. If we allow Alice to withdraw the collateral at any time,
the she can withdraw it in the same block as the reward. One solution would be
to allow Alice to withdraw the collateral only after some fixed height H, while
her participation in the pool using this collateral ends at height H − L, after
which she must use new collateral. For simplicity, we skip this deadline condition
for withdrawing the collateral by the miner in case a block is not found for a
long time. However, a real world implementation must consider this.

5 Conclusion and Further Work

Non-outsourceable puzzles have been proposed as a possible workaround for
attacks that arise due to pool formation in PoW blockchains. Such solutions
fall into two broad categories: Type 1, where the reward is directly bound to
some trapdoor information used for generating the block solution (and thus,
that information is needed while spending), and Type 2, where the reward is
indirectly bound to the trapdoor information via a certificate. Type 2 schemes
can be further classified into weak, where the identity of the miner is revealed,
and strong, where the identity remains hidden.

In this paper we proposed two approaches to bypass non-outsourceability
of Type 1 and weak Type 2 schemes to create mining pools, thereby ‘breaking’
them. Our pools operates at level L2 (censorship resistance), where the pool does
not control transactions to be included in blocks but only colle";"""date"",""2020-01-15T16:12:39Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2020-01-15T16:12:39Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017/Debian) kpathsea version 6.2.3""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2020-01-15T16:12:39Z""
""created"",""2020-01-15T16:12:39Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-01-15T16:12:39Z""
""resourceName"",""044.pdf""
""Author"",""""
""producer"",""pdfTeX-1.40.18""
""pdf:docinfo:producer"",""pdfTeX-1.40.18""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""4"",""0"",""0"",""0"",""3"",""0"",""0"",""0"",""4"",""0"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2020-01-15T16:12:39Z""
""Last-Modified"",""2020-01-15T16:12:39Z""
""dcterms:modified"",""2020-01-15T16:12:39Z""
""title"",""""
""Last-Save-Date"",""2020-01-15T16:12:39Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2020-01-15T16:12:39Z""
""meta:save-date"",""2020-01-15T16:12:39Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017/Debian) kpathsea version 6.2.3""
""Content-Length"",""257369""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""13""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""2165"",""2404"",""2410"",""2619"",""2039"",""2545"",""2622"",""2650"",""2551"",""2838"",""2506"",""2602"",""417""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-01-15T16:12:39Z""
";https://scholar.google.ch/scholar?start=730&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098835-270;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Protocols for Connecting Blockchains with Off-Chain Systems;F Zhang ;2020 search.proquest.com;;"… them to consume off-chain data (eg, stock quotes). External data must be pushed to the

blockchain by an oracle before they can be used by a smart contract. Oracles are of vital

importance to the trustworthiness of smart contracts—if they can be …";Autres articles;;[PDF] cornell.edu;https://ecommons.cornell.edu/xmlui/bitstream/handle/1813/103042/Zhang_cornellgrad_0058F_12161.pdf?sequence=1;"
PROTOCOLS FOR CONNECTING BLOCKCHAINS
WITH OFF-CHAIN SYSTEMS

A Dissertation

Presented to the Faculty of the Graduate School

of Cornell University

in Partial Fulfillment of the Requirements for the Degree of

Doctor of Philosophy

by

Fan Zhang

August 2020



Š 2020 Fan Zhang

ALL RIGHTS RESERVED



PROTOCOLS FOR CONNECTING BLOCKCHAINS WITH OFF-CHAIN

SYSTEMS

Fan Zhang, Ph.D.

Cornell University 2020

Smart contracts are programs that execute on blockchains. Their strong secu-

rity properties (e.g., transparency, tamper-resistance, and censorship-resistance)

have attracted significant attention and investment ($31B via ICOs as of 2019),

but most of their real-world uses, such as tokens, exercise little of smart con-

tracts’ potential power. A key reason is a disconnection from the real world:

There is currently no secure, decentralized way to faithfully convey real-world

states to blockchains. Worse yet, smart contracts inherit blockchains’ lack of

confidentiality and poor efficiency.

This thesis introduces solutions to these problems by connecting blockchains

with off-chain systems. The systems presented in this thesis advance the state

of the art of smart contract capabilities. Specifically, this thesis explores three

research directions: (1) authenticated data oracles that enable faithful represen-

tation of real-world states on blockchains. (2) decentralized secret storage that

endows smart contracts with privacy by storing secrets and performing com-

putation in off-chain committees. (3) resource-efficient consensus that achieves

Proof of Work style consensus while avoiding wasteful computation. Beyond the

scholarly contributions, several works in this thesis have seen industry adoption.



BIOGRAPHICAL SKETCH

Fan Zhang received his B.S. in Electronic Engineering from Tsinghua University

in 2014. Since then, he has pursued a Ph.D. in Computer Science at Cornell Uni-

versity under the supervision of Prof. Ari Juels. He is a member of IC3 (Initiative

of Cryptocurrencies and Contract) and an IBM Ph.D. Fellow for 2018–2020. His

research interest is in the security of decentralized systems, in particular those

enabled by blockchains and trusted execution environments (TEEs). In this line

of work, Fan has made various types of contribution, including pioneering the

study of fusing TEEs and blockchains, developing novel decentralized crypto-

graphic protocols with orders-of-magnitude better performance, and impacting

broader community by releasing open source tools and setting up public services.

Several of his works have been adopted by industry.

iii



This thesis is dedicated to my family, including Pixie “Pipi” Lian, the cat.

iv



ACKNOWLEDGEMENTS

When applying to grad school many years back, I had a tough time calculating

whether pursuing a Ph.D. degree would be optimal. In retrospect, my calculation

was mostly naĂŻve (e.g., I figured a Ph.D. would mean a better salary but I forgot

to calibrate for faculty jobs), but somehow I made the right choice—I could not

be more grateful for the memorable six years at Cornell and Cornell Tech.

First and foremost, I have been incredibly lucky to have Ari Juels as my

Ph.D. advisor. His constant, patient, constructive advice and guidance led me

to who I am. I have learned so much—from how to articulate and present

ideas, to how to cultivate a research vision, and to many things outside research.

Above all, I am especially grateful for his initiatives and guidance on transferring

research to real-world adoption. Those experiences not only helped me achieve

broader impact, but also reinforced my brief in academia as a venue to achieve

meaningful real-world impact, which is the ultimate reason for me to stay in

academia. Ari has been and will continue to be my role model as a researcher,

advisor, and colleague.

I have also been extremely fortunate to have Elaine Shi, Tom Ristenpart, and

Rafael Pass as my thesis committee members. Working with them and being

exposed to ideas and perspectives from their areas of expertise have played a

central role in the development of my research interests and values. They have

always been great supporters throughout my Ph.D. study.

This thesis would not have been possible without my co-authors and col-

leagues who directly or indirectly contributed to this research. The list is long

and I will surely miss many who made an indispensable contribution. Never-

theless, I would like to thank my external collaborators: Andrew Low, Dawn,

Jernej, Raymond, Lun (Berkeley), Andrew Miller (UIUC), Florian (Stanford),

v



Mike (UNC), Ahmed, Yupeng (UMD), as well as my colleagues and friends at

Cornell: Andreas, Antonio, Bijeeta, Congzhen Deepak, Ethan, Fabian, Ge, Ian,

Iddo, Ittay, Jasleen, Julia, Kyle, Lei, Lorenz, Longqi, Lucy, Mahimna, Nirvan,

Paul, Phil, Steven, Tyler, Xiao, Yan, Yin, Yiqing, Yuhang Ma, Yuhang Zhao, and

others for making my Ph.D. experience memorable.

My Ph.D. experience has been made unique by Cornell Tech with its beautiful,

quiet campus just across the East River from Manhattan, and the brilliance and

diversity of its residents, which is also why I love New York City. Thanks for

founding Cornell Tech!

Last but not least, I would like to thank my family. My parents have provided

unconditional love and support throughout my life and have always encouraged

me to be brave to challenge myself and to make a positive impact on the world.

I want to especially thank my wife, Zhen Lian, who has been my best friend,

closest colleague (she is also a Ph.D. student at Cornell Tech), and occasionally

best therapist. I want to thank her for always having a clear and logical mind,

for helping me navigate through many complex situations, and for urging me to

adopt a healthier lifestyle and many more. Her support and help are essential

to all my success. Finally, my cat has provided more soothing power than any

two-legged objects.

vi



TABLE OF CONTENTS

Biographical Sketch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iii
Dedication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iv
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . v
Table of Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii
List of Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix
List of Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . x

1 Introduction 1
1.1 Protocols for authenticated data oracles . . . . . . . . . . . . . . . 3
1.2 Protocols for decentralized secret storage . . . . . . . . . . . . . . 6
1.3 Protocols for resource-efficient mining . . . . . . . . . . . . . . . . 7
1.4 Thesis organization . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2 Town Crier: An Authenticated Data Feed for Smart Contracts 9
2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.3 Architecture and Security Model . . . . . . . . . . . . . . . . . . . 18
2.4 TC Protocol Overview . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.5 Two Key Security Properties . . . . . . . . . . . . . . . . . . . . . . 26
2.6 Town Crier Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.7 TC Implementation Details . . . . . . . . . . . . . . . . . . . . . . 38
2.8 Security Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
2.9 Experiments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
2.10 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
2.11 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
2.12 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

3 DECO: Liberating Web Data Using Decentralized Oracles for TLS 56
3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
3.2 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
3.3 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
3.4 The DECO protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
3.5 Proof generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
3.6 Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
3.7 Implementation and Evaluation . . . . . . . . . . . . . . . . . . . . 103
3.8 Legal and Compliance Issues . . . . . . . . . . . . . . . . . . . . . 108
3.9 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
3.10 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

vii



4 CHURP: Dynamic-Committee Proactive Secret Sharing 112
4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
4.2 Model and Assumptions . . . . . . . . . . . . . . . . . . . . . . . . 118
4.3 Overview of CHURP . . . . . . . . . . . . . . . . . . . . . . . . . . 123
4.4 Efficient Bivariate 0-Sharing . . . . . . . . . . . . . . . . . . . . . . 129
4.5 CHURP Protocol Details . . . . . . . . . . . . . . . . . . . . . . . . 132
4.6 CHURP Implementation & Evaluation . . . . . . . . . . . . . . . . 148
4.7 Point-to-Point Technique Details . . . . . . . . . . . . . . . . . . . 155
4.8 Applications in Decentralized Systems . . . . . . . . . . . . . . . . 161
4.9 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164

5 REM: Resource-Efficient Mining for Blockchains 168
5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
5.2 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
5.3 Overview of PoUW and REM . . . . . . . . . . . . . . . . . . . . . 177
5.4 Tolerating Compromised SGX Nodes . . . . . . . . . . . . . . . . . 181
5.5 Implementation Details . . . . . . . . . . . . . . . . . . . . . . . . . 191
5.6 Waste Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203
5.7 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226
5.8 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230

6 Conclusion and future directions 232

A Town Crier 236
A.1 Formal Modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236
A.2 Proofs of Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239
A.3 Applications and Code Samples . . . . . . . . . . . . . . . . . . . . 245

B DECO 252
B.1 Protocols details for GCM . . . . . . . . . . . . . . . . . . . . . . . 252
B.2 Security proofs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255
B.3 Details on Key-Value Grammars and Two-Stage Parsing . . . . . 261

C CHURP 267
C.1 Security Proof for Opt− CHURP . . . . . . . . . . . . . . . . . . . . 267
C.2 CHURP Pessimistic paths . . . . . . . . . . . . . . . . . . . . . . . 270
C.3 The Static Setting: Improved PSS . . . . . . . . . . . . . . . . . . . 275
C.4 Changing the threshold . . . . . . . . . . . . . . . . . . . . . . . . 278

D REM 281
D.1 Tolerating Compromised SGX Nodes: Details . . . . . . . . . . . . 281

Bibliography 288

viii



LIST OF TABLES

2.1 TC enclave response time. . . . . . . . . . . . . . . . . . . . . . . . 47

3.1 Run time of DECO protocols. . . . . . . . . . . . . . . . . . . . . . 104
3.2 Run time of the proof-generation phase. . . . . . . . . . . . . . . 106

4.1 Notation used in CHURP. . . . . . . . . . . . . . . . . . . . . . . . 136
4.2 Summary of protocol performance. . . . . . . . . . . . . . . . . . 145
4.3 Performance comparison of on-chain communication methods. . 155
4.4 Comparison of Proactive Secret Sharing (PSS) schemes . . . . . . 165

ix



LIST OF FIGURES

2.1 Basic Town Crier architecture. . . . . . . . . . . . . . . . . . . . . 19
2.2 Data flows in datagram processing. . . . . . . . . . . . . . . . . . 24
2.3 Formal abstraction for SGX execution. . . . . . . . . . . . . . . . . 25
2.4 Hybrid TCB in TC. . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.5 Offline verification of SGX attestation. . . . . . . . . . . . . . . . . 31
2.6 TC contract CTC reflecting fees. . . . . . . . . . . . . . . . . . . . . 34
2.7 The Town Crier RelayR. . . . . . . . . . . . . . . . . . . . . . . . 35
2.8 The Town Crier Enclave progencl. . . . . . . . . . . . . . . . . . . . 36
2.9 Money Flow for a Delivered Request. . . . . . . . . . . . . . . . . 37
2.10 Components of TC Server. . . . . . . . . . . . . . . . . . . . . . . . 40
2.11 Throughput on a single SGX machine. . . . . . . . . . . . . . . . . 49

3.1 The oracle functionality. . . . . . . . . . . . . . . . . . . . . . . . . 67
3.2 An overview of the workflow in DECO. . . . . . . . . . . . . . . . 71
3.3 Demonstration of context-integrity attacks. . . . . . . . . . . . . . 75
3.4 The protocol of three-party handshake. . . . . . . . . . . . . . . . 77
3.6 The 2PC-HMAC protocol. . . . . . . . . . . . . . . . . . . . . . . . 83
3.7 The DECO protocol. . . . . . . . . . . . . . . . . . . . . . . . . . . 87
3.8 An example of confidential binary option using DECO. . . . . . . 99
3.9 An example of age proof. . . . . . . . . . . . . . . . . . . . . . . . 102
3.10 An example of verifiable claims of price discrimination. . . . . . 103

4.1 An illustration of a handoff between two committees. . . . . . . . 118
4.2 An illustration of an epoch. . . . . . . . . . . . . . . . . . . . . . . 119
4.3 An example of the handoff protocol. . . . . . . . . . . . . . . . . . 127
4.4 The specification of (2t, 2t + 1)-UnivariateZeroShare. . . . . . . . . 130
4.5 The specification of (t, n)-BivariateZeroShare. . . . . . . . . . . . . 131
4.6 CHURP protocol tiers. . . . . . . . . . . . . . . . . . . . . . . . . . 135
4.7 Opt-ShareReduce between the committees C and C ′. . . . . . . . . 140
4.8 Opt-Proactivize updates the reduced shares. . . . . . . . . . . . . . 143
4.9 The specification of Opt-ShareDist. . . . . . . . . . . . . . . . . . . 144
4.10 Latency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
4.11 Off-chain communication overhead. . . . . . . . . . . . . . . . . . 152
4.12 Tradeoff in latency vs. message transmission cost. . . . . . . . . . 161

5.1 Architecture overview of REM. . . . . . . . . . . . . . . . . . . . . 181
5.6 Miner loop. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192
5.7 REM toolchain. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
5.8 PoUW Runtime. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
5.11 REM block structure. . . . . . . . . . . . . . . . . . . . . . . . . . . 201
5.12 REM Overhead. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202
5.14 Summary of revenue analysis result. . . . . . . . . . . . . . . . . . 212

x



CHAPTER 1

INTRODUCTION

One of the most fundamental challenge in computer science is to implement

fault-tolerant services, namely systems that remain functional and secure even

some participants in the system behave maliciously. Towards this goal, Byzantine

Fault Tolerance (BFT) [173] has been studied for decades. However, traditional

BFT-based protocols only work in a closed setting where the number of partic-

ipants in the system, as well as their identities, are known. This requirement

is quite limiting, and in particular these protocols cannot be used in a open

and permissionless setting where participants are free to join and leave at any

time. How to achieve strong fault-tolerance in a permissionless setting remains

unknown, until Nakamoto’s now celebrated blockchain protocol [190].

Blockchains realize a simple but powerful abstraction: a public append-only

ledger that functions in a fully “decentralized” fashion 1. This new capability

gives rise to an array of new applications. Most excitingly, blockchains enable

smart contracts (e.g., Ethereum [64]), which are stateful programs executed by the

blockchain network. Smart contracts can realize arbitrarily complex logic, and

they inherit strong security guarantees from the underlying blockchain, such

as transparency, tamper-resistance, and censorship-resistance. In other words,

smart contracts are a general method to implement fault-tolerant services in a

decentralized setting. These nice properties make smart contracts an appealing

solution to a wide range of real-world challenges. Proponents predict that smart

contracts will transform areas as diverse as finance, supply chain management,

1Unfortunately the term “decentralization” has been heavily overloaded and has inconsistent
and vague meanings, e.g., as argued in [245]. Throughout this thesis, we use the term to denote
that a given system or protocol does not rely on a central authority.

1



health care, and many more [122, 52, 240].

However, despite the widespread interest and significant investment (e.g.,

more than $3.8 billion in VC investment [102] has been made to blockchain star-

tups as of 2019), most of their real-world uses, such as tokens, exercise little of

smart contracts’ potential power. A key reason is that many envisioned applica-

tions demand fundamentally more than what a blockchain can offer (recall that

a blockchain is merely a public append-only ledger). For example, envisioned appli-

cations as diverse as financial contracts, decentralized identity management, and

even betting require reliable access to authenticated data about the real world,

but this is currently no secure, decentralized way to establish authenticated chan-

nels between smart contracts and existing off-chain data sources (e.g., websites).

Moreover, while smart contracts inherit the strong security guarantees from the

underlying blockchains, they also inherit fundamental limitations: they cannot

provide any privacy and suffer from limited performance.

A promising direction to overcome these limitations is to combine on-chain

computation with off-chain protocols (e.g., multiparty computation (MPC) and

trusted execution environments (TEE)). However, how to design, model, and

analyze heterogeneous systems that span blockchains and off-chain components

with disparate security properties is the main technical challenge this thesis tackled.

This thesis explores principled composition of on-chain and off-chain compo-

nents that lead to provably secure, efficient, and decentralized systems.

This thesis advances the state of the art of smart contract capabilities by

filling in basic yet missing blockchain needs. Specifically, this thesis explores

three research directions: (1) authenticated data oracles that enable the faithful

representation of real-world states on blockchains. We present Town Crier and

2



DECO, two systems that can convert widely deployed TLS-enabled data sources

to authenticated data feeds. (2) decentralized secret storage that endows smart

contracts with privacy by storing secrets and performing computation in off-

chain committees. We present CHRUP, the first practical churn-robust secret-

sharing protocol that achieves orders-of-magnitude performant improvement

over prior works. (3) resource-efficient consensus by Proof of Useful Work. We

present REM, a system that leverage trusted execution environments (TEEs) to

realize PoW-like consensus protocol while avoiding wasteful computation.

Industry adoption. Beyond the scholarly contributions, several systems in

this thesis has been adopted commercially. Town Crier (Chapter 2) and DECO

(Chapter 3) have been licensed by ChainLink (https://chain.link) to build

decentralized oracle networks. CHURP (Chapter 4) is on the product roadmap

of Oasis Labs (https://www.oasislabs.com) as a potential key management

solution.

The following are further summaries of our contributions.

1.1 Protocols for authenticated data oracles

Many envisioned smart contract use cases (e.g., financial instruments) require

them to consume off-chain data (e.g., stock quotes). External data must be pushed

to the blockchain by an oracle before they can be used by a smart contract. Oracles

are of vital importance to the trustworthiness of smart contracts—if they can be

tampered with, blockchains’ guarantees of tamper-resistance is meaningless; if

they’re controlled by a central party, blockchain’s decentralization promise is

negated. Moreover, oracles are natural attack targets. A recent exploit [197] of er-

3

https://chain.link
https://www.oasislabs.com


rors in the price oracle used by Synthetix (a decentralized exchange) allowed the

hacker to gain 1,000x profits equalling $1 billion in less than an hour. Therefore,

trustworthy oracles are a cornerstone to the smart contract ecosystem and a key

missing component to realize the envisioned applications.

The main challenge in building oracles is to achieve strong authenticity and

privacy guarantees while maintaining backward compatibility with existing data

sources. Ample authenticated data are already readily available through secure

(i.e., HTTPS) websites and APIs, but deployed secure protocols—Transport Layer

Security (TLS)—is incompatible with how oracles are supposed to work, as TLS

does not guarantee authenticity for relayed data. As a result, existing oracle

designs either cannot prove authenticity (i.e., one must trust the oracle for that)

or require changing how millions of deployed websites release data, which will

incur a high adoption cost.

The first two chapters of this thesis present protocols that address this chal-

lenge. While two systems explore different tradeoffs, they both enable smart

contracts to securely use existing TLS-enabled data sources without any modifica-

tions to existing data sources.

1.1.1 Town Crier (TC)

TC draws upon recent advances in trusted computing: Intel SGX [185, 32, 146]

provides a CPU-based trusted execution environment (TEE) that aims to provide

integrity and confidentiality guarantees to computation performed on a computer

where all the privileged software (e.g., kernel) is potentially malicious.

4



TC has a hybrid architecture with a smart contract front-end and a TEE

backend. Essentially, the TC backend terminates TLS sessions in a TEE and signs

the payload using a secret key generated in the TEE.

TC is one of the first systems that employ a hybrid trusted computing base

(TCB) that spans smart contracts and TEEs, which introduced modeling and

design challenges. One of our contributions is a formal model of TC that captures

not only traditional security properties (i.e., authenticity), but also economic

safety properties (e.g., TC will not run out of money and that an honest user will

not pay excessive fees) uniquely induced by the monetary cost associated with

smart contract execution. We also proposed techniques to minimize the size of

hybrid TCBs that can be applied to other TEE-blockchain systems as well.

Town Crier also supports confidentiality. It enables private data requests

with encrypted parameters. Additionally, in a generalization that executes smart-

contract logic within Town Crier, the system permits secure use of user credentials

to scrape access-controlled online data sources.

1.1.2 DECO

The use of TEEs in TC enables performant and powerful features that are oth-

erwise unachievable (e.g., complex post-processing of TLS data). Nonetheless,

it also introduces reliance on TEE security that may be undesirable for some

applications.

To this end, we explored a different trust model without TEEs and developed

DECO, a three-party cryptographic protocol between a user, an oracle, and a TLS

5



server. DECO allows the user to prove facts about her TLS sessions (with the

server) to the oracle in a privacy-preserving fashion.

DECO draws on latest advances in Multiparty Computation (MPC) and

zero-knowledge proofs (ZKPs). The novelty of DECO lies in achieving practical

performance while not requiring any changes on the server side. To this end,

DECO employs several novel cryptographic techniques. DECO introduces a

three-party TLS handshake protocol that secret-share the session keys between

the oracle and user, as well as highly optimized zero-knowledge proofs that

allow the user to prove fine-grained statements about her session data efficiently.

1.2 Protocols for decentralized secret storage

Blockchains can’t store secrets, which deprives smart contracts of privacy and, as

a consequence, the ability to use cryptography—e.g., a smart contract can’t issue

digital signatures because the blockchain can’t store the secret signing key.

One idea is to delegate the storage of secrets to off-chain committees using Secret

Sharing (SS) [229], or better yet, Proactive Secret Sharing (PSS) [145]. However,

most of the existing PSS protocols assume a static committee that runs against the

open-membership nature of blockchains. In permissionless blockchains, nodes

may freely join and leave the system at any time. In permissioned blockchains,

only authorized nodes can join, but nodes can fail and membership change.

Either way, secret sharing for blockchains must support committee membership

changes, i.e., dynamic committees. Under node churn, existing PSS is either inse-

cure (i.e., leaks the secret to the adversary) or incur prohibitive communication

costs.

6



In this thesis, we present CHURP, a dynamic-committee PSS with a very

low communication complexity. CHURP employed several novel secret-sharing

techniques to reduce communication complexity: a new zero-sharing protocol

for efficient proactivization, dimension-switching to safeguard the secret in

committee handoffs, and hedging techniques for trusted setup failures. CHURP

achieves an O(n2) improvement of communication complexity over the state of

the art [226], and concretely at least 1000x less communication overhead for a

committee of hundreds of nodes.

CHURP enables a wide range of applications requiring maintaining secrets

in a decentralized system, such as decentralized key management, decentralized

identity, auditable access control, committee-based consensus, and decentralized

secure multiparty computation (MPC).

1.3 Protocols for resource-efficient mining

One of the core blockchain innovations is the first permissionless consensus pro-

tocol, known as the Nakamoto consensus [190]. It uses cryptographic puzzles

(solutions to which are called Proofs of Work or PoW) to prevent Sybil attacks.

The cost, however, is the computation wasted searching for PoWs (aka mining),

which serve no useful purpose beyond consensus. The arm race in mining has led

to enormous monetary and environmental costs: the Bitcoin network consumes

as much electricity as the entire Israel as of May, 2020 [103].

Can we design puzzles differently such that their solutions are useful? To

this end, I developed Proofs of Useful Work, or PoUW. To search for a PoUW,

miners perform useful computation (e.g., scientific experiments, pharmaceuti-

7



cal discovery) in TEEs. Each unit of work done grants the miner a small and

dynamically calibrated probability to discover a PoUW. The design challenge is

to find fair, robust, and efficient ways to measure the amount of work done in

TEEs. I designed efficient binary analysis algorithms that can reliably count CPU

instructions while TEE programs execute. The rest of the protocol is essentially

the same as Nakamoto’s. Therefore PoUW inherits all the desired properties of

PoW but avoids energy waste.

1.4 Thesis organization

The rest of this thesis is organized in five chapters covering works from [257,

260, 182, 259] done in collaboration with Ethan Cecchetti, Kyle Croman, Robert

Escriva, Ittay Eyal, Steven Goldfeder, Ari Juels, Andrew Low, Harjasleen Malvai,

Sai Krishna Deepak Maram, Robbert Van Renesse, Elaine Shi, Dawn Song, Lun

Wang, and Yupeng Zhang.

Chapter 2 and Chapter 3 presents Town Crier and DECO, respectively, two

data oracle protocols for TLS with different trust assumptions and performance

profiles. Chapter 4 presents CHURP, a protocol for churn-robust secret shar-

ing. Chapter 5 presents REM and its Proof of Useful Work (PoUW) proto-

col that achieve a PoW-style consensus without wasting computation power.

Lastly, Chapter 6 concludes the thesis with a discussion of future research direc-

tions.

8



CHAPTER 2

TOWN CRIER: AN AUTHENTICATED DATA FEED FOR SMART

CONTRACTS

2.1 Introduction

Smart contracts are computer programs that autonomously execute the terms

of a contract. For decades they have been envisioned as a way to render legal

agreements more precise, pervasive, and efficiently executable. Szabo, who

popularized the term “smart contract” in a seminal 1994 essay [238], gave as an

example a smart contract that enforces car loan payments. If the owner of the car

fails to make a timely payment, a smart contract could programmatically revoke

physical access and return control of the car to the bank.

Cryptocurrencies such as Bitcoin [190] provide key technical underpinnings

for smart contracts: direct control of money by programs and fair, automated

code execution through the decentralized consensus mechanisms underlying

blockchains. The recently launched Ethereum [250, 64] supports Turing-complete

code and thus fully expressive self-enforcing decentralized smart contracts—a

big step toward the vision of researchers and proponents. As Szabo’s example

shows, however, the most compelling applications of smart contracts—such as

financial instruments—additionally require access to data about real-world state

and events.

Data feeds (also known as “oracles”) aim to meet this need. Very simply,

data feeds are contracts on the blockchain that serve data requests by other

contracts [64, 250]. A few data feeds exist for Ethereum today that source data

9



from trustworthy websites, but provide no assurance of correctly relaying such

data beyond the reputation of their operators (typically individuals or small

entities). HTTPS connection to a trustworthy website would seem to offer a

solution, but smart contracts lack network access, and HTTPS does not digitally

sign data for out-of-band verification. The lack of a substantive ecosystem of

trustworthy data feeds is frequently cited as critical obstacle to the evolution of

Ethereum and decentralized smart contracts in general [135].

Town Crier. We introduce a system called Town Crier (TC) that addresses this

challenge by providing an authenticated data feed (ADF) for smart contracts. TC

acts as a high-trust bridge between existing HTTPS-enabled data websites and the

Ethereum blockchain. It retrieves website data and serves it to relying contracts

on the blockchain as concise pieces of data (e.g. stock quotes) called datagrams.

TC uses a novel combination of Software Guard Extensions (SGX), Intel’s recently

released trusted hardware capability, and a smart-contract front end. It executes

its core functionality as a trusted piece of code in an SGX enclave, which protects

against malicious processes and the OS and can attest (prove) to a remote client

that the client is interacting with a legitimate, SGX-backed instance of the TC

code.

The smart-contract front end of Town Crier responds to requests by contracts

on the blockchain with attestations of the following form:

“Datagram X specified by parameters params is served by an HTTPS-enabled

website Y during a specified time frame T.”

A relying contract can verify the correctness of X in such a datagram assuming

10



trust only in the security of SGX, the (published) TC code, and the validity of

source data in the specified interval of time.

Another critical barrier to smart contract adoption is the lack of confidential-

ity in today’s ecosystems; all blockchain state is publicly visible, and existing

data feeds publicly expose requests. TC provides confidentiality by supporting

private datagram requests, in which the parameters are encrypted under a TC

public key for ingestion in TC’s SGX enclave and are therefore concealed on the

blockchain. TC also supports custom datagram requests, which securely access

the online resources of requesters (e.g. online accounts) by ingesting encrypted

user credentials, permitting TC to securely retrieve access-controlled data.

We designed and implemented TC as a complete, highly scalable, end-to-end

system that offers formal security guarantees at the cryptographic protocol level.

TC runs on real, SGX-enabled host, as opposed to an emulator (e.g. [46, 227]).

We plan to launch a version of TC as an open-source, production service atop

Ethereum, pending the near-futur";"""date"",""2020-07-31T02:05:16Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2020-07-31T02:05:16Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.21 (TeX Live 2020) kpathsea version 6.3.2""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2020-07-31T02:05:16Z""
""created"",""2020-07-31T02:05:16Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-07-31T02:05:16Z""
""resourceName"",""Zhang_cornellgrad_0058F_12161.pdf""
""Author"",""""
""producer"",""pdfTeX-1.40.21""
""pdf:docinfo:producer"",""pdfTeX-1.40.21""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""1"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""1"",""4"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""3"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""1"",""0"",""0"",""0"",""0"",""3"",""0"",""0"",""0"",""0"",""1"",""0"",""0"",""0"",""0"",""1"",""1"",""0"",""0"",""0"",""0"",""0"",""0"",""2"",""0"",""2"",""0"",""0"",""0"",""8"",""1"",""0"",""3"",""2"",""2"",""0"",""13"",""0"",""0"",""1"",""19"",""22"",""17"",""0"",""0"",""1"",""7"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""3"",""0"",""1"",""0"",""2"",""0"",""9"",""7"",""8"",""2"",""0"",""10"",""2"",""0"",""0"",""2"",""7"",""3"",""10"",""8"",""22"",""17"",""8"",""44"",""44"",""3"",""0"",""10"",""7"",""0"",""0"",""0"",""0"",""0"",""2"",""5"",""3"",""2"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""1"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""1"",""0"",""0"",""2"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""2"",""0"",""2"",""0"",""2"",""0"",""0"",""0"",""8"",""0"",""6"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""2"",""0"",""1"",""0"",""1"",""1"",""0"",""0"",""0"",""0"",""0"",""0"",""7"",""3"",""9"",""0"",""0"",""0"",""0"",""8"",""5"",""2"",""0"",""8"",""4"",""24"",""16"",""10"",""11"",""12"",""22"",""1"",""26"",""42"",""4"",""0"",""2"",""10"",""2"",""2"",""9"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2020-07-31T02:05:16Z""
""Last-Modified"",""2020-07-31T02:05:16Z""
""dcterms:modified"",""2020-07-31T02:05:16Z""
""title"",""""
""Last-Save-Date"",""2020-07-31T02:05:16Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2020-07-31T02:05:16Z""
""meta:save-date"",""2020-07-31T02:05:16Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.21 (TeX Live 2020) kpathsea version 6.3.2""
""Content-Length"",""1587772""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""322""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""213"",""30"",""1220"",""741"",""66"",""1569"",""1117"",""1709"",""1598"",""386"",""2060"",""1650"",""1655"",""1433"",""1335"",""1288"",""1429"",""1401"",""1116"",""1251"",""1422"",""1551"",""1452"",""1557"",""1328"",""1438"",""1447"",""1658"",""1202"",""1047"",""1331"",""1165"",""1022"",""1407"",""1012"",""1391"",""1230"",""1503"",""1035"",""1451"",""1288"",""1166"",""794"",""1119"",""1104"",""1104"",""1183"",""1001"",""1086"",""1315"",""921"",""1436"",""1369"",""1179"",""1324"",""1291"",""1435"",""1597"",""1284"",""1066"",""1372"",""1215"",""1227"",""1414"",""1392"",""859"",""1272"",""1392"",""1321"",""1505"",""1339"",""1361"",""1057"",""1251"",""1210"",""1586"",""1440"",""1433"",""1340"",""1042"",""1143"",""1157"",""1204"",""1237"",""1464"",""1069"",""995"",""1588"",""1289"",""1470"",""1360"",""1206"",""1331"",""1152"",""1287"",""1205"",""1274"",""1608"",""1194"",""1261"",""1341"",""1284"",""1344"",""1198"",""1400"",""1248"",""1327"",""1377"",""1166"",""1247"",""1544"",""1200"",""1422"",""1118"",""1426"",""1228"",""1251"",""1393"",""1347"",""1260"",""1564"",""746"",""1285"",""1151"",""1374"",""1536"",""1337"",""1201"",""1101"",""1230"",""1382"",""1245"",""1462"",""1142"",""1444"",""1165"",""1370"",""1140"",""1144"",""1271"",""1466"",""1573"",""1268"",""1385"",""1178"",""1019"",""1098"",""1229"",""1276"",""1317"",""1282"",""1490"",""1445"",""1308"",""1352"",""1252"",""1425"",""1362"",""1375"",""1223"",""1623"",""993"",""1015"",""1402"",""1498"",""1406"",""1319"",""1224"",""1297"",""1486"",""1081"",""1205"",""1275"",""1340"",""1461"",""1664"",""1566"",""114"",""1297"",""1602"",""1508"",""1311"",""1083"",""1364"",""1610"",""1491"",""1177"",""1251"",""1543"",""1286"",""1507"",""1302"",""1288"",""1311"",""883"",""1157"",""1138"",""1421"",""904"",""894"",""1252"",""1278"",""1167"",""1363"",""1409"",""1200"",""1367"",""1426"",""1103"",""1605"",""1324"",""1227"",""860"",""1379"",""1228"",""1419"",""1462"",""1319"",""993"",""1084"",""1237"",""1180"",""1245"",""681"",""1426"",""1441"",""1336"",""1241"",""954"",""1193"",""1158"",""1124"",""712"",""1394"",""1410"",""1495"",""1311"",""1239"",""1413"",""1459"",""1188"",""622"",""1431"",""1627"",""1532"",""845"",""1065"",""1426"",""1357"",""1455"",""1306"",""1288"",""1471"",""1413"",""1380"",""1072"",""1468"",""1522"",""1097"",""843"",""1417"",""497"",""938"",""1215"",""1258"",""1159"",""1165"",""1345"",""1201"",""1269"",""1386"",""880"",""1067"",""1310"",""1271"",""863"",""1304"",""769"",""1338"",""1065"",""1253"",""1337"",""1155"",""1261"",""1298"",""1375"",""1452"",""1067"",""1273"",""1398"",""1364"",""1187"",""1331"",""1093"",""991"",""992"",""1348"",""727"",""1250"",""1205"",""1572"",""1616"",""1663"",""1646"",""1560"",""1701"",""1664"",""1551"",""1622"",""1680"",""1605"",""1633"",""1701"",""1711"",""1700"",""1530"",""1562"",""1541"",""1479"",""1442"",""1664"",""553""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-07-31T02:05:16Z""
";https://scholar.google.ch/scholar?start=810&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098822-239;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;[PDF][PDF] An Efficient Two Factor User Authentication and Key Exchange Protocol for Telecare Medical Information System;F Sherali, S Falah ; Computer Science, 2020  ijmcs.futureintech.net;;"… In this scheme, we propose to bring together the advance of both the crypto and IR community

[3, 4, 5] to … We prove its security in the random oracle model ROM under the fact that the BDH

problem is … Let h1 and h2 be random oracles from {0, 1}? to Gx and from Gy to {0, 1}n …";Autres articles;;[PDF] future-in-tech.net;http://ijmcs.future-in-tech.net/15.4/R-Fairooz.pdf;"
International Journal of Mathematics and
Computer Science, 15(2020), no. 4, 1015–1027

b b

M
CS

An Efficient Two Factor User Authentication
and Key Exchange Protocol for Telecare

Medical Information System

Fairouz Sherali, Sarhan Falah

Education College for Girls
University of Kufa

Najaf Governorate, Iraq

email: fairoozm.jaafar@uokufa.edu.iq, falahh.sarhan@uokufa.edu.iq

(Received July 16, 2020, Accepted August 27, 2020)

Abstract

Telecare medical information system (TMIS) is substantially desir-
able to patients by allowing them to remotely access medical services.
Authentication schemes for TMIS try to ensure secure and autho-
rized access. Recently, some smart card-based password authentica-
tion schemes have been proposed, but privacy is not duly addressed. In
this paper, we propose a key agreement technique for a medical server
environment to overcome the limitations of the existing schemes. In
the proposed scheme, we suggest bringing together the advance of both
the crypto and Information Retrieval (IR) community to enhance the
health-care process between patients and doctors by supporting an ef-
ficient communicating platform on the internet which overcomes some
drawbacks in traditional health-care services. However, to keep pa-
tient medical data confidential against untrusted patients, we apply
cryptographic methods by disclosing the data decryption key only to
authorized patients and doctors to retrieve medical files containing
certain keywords. We show that the proposed scheme is secure in
the random oracle model (ROM) under the Bilinear Diffie-Hellman
Problem BDHP.

Keywords and phrases: Telecare medicine information system (TMIS);
Information Retrieval; Authentication; Bilinear Diffie-Hellman Problem.
AMS (MOS) Subject Classifications:
ISSN 1814-0432, 2020, http://ijmcs.future-in-tech.net



1016 F. Sherali, S. Falah

1 Introduction

At this time, people are accessing different services and applications through
the Internet. For instance, they use different electronic devices like com-
puters and mobile phones to get access to a remote server from anywhere
and anytime through a public channel. Nowadays, low cost mobile devices
and internet services make electronic health care and telemedicine services
available directly to the user (patient). With electronic health care, users are
able to get different healthcare services without visiting the healthcare center
physically, but through the Internet. The traditional clinical medical service
system can often be replaced by electronic health care, distance nursing, and
home watching facility[1]

Telecare medical information system (TMIS)[2] has become an available
choice for users or patients to get remote healthcare services conveniently.
As we are moving from paper-based patients records to electronic patients
records, the telecare medical information system provides easy access to elec-
tronic records for remote patients. Despite the advantages of TMIS, several
issues should be addressed before users or patients can adopt it. First, the
TMIS is vulnerable to different attacks because these systems are constructed
on public networks. Secondly, private information and medical history of pa-
tients are supposed to be maintained carefully by TMIS and be kept secret in
messages transferred among all entities to prevent users’ privacy from being
revealed. Thus, a secure technique is required to protect the communication
process in TMIS and reduce the adversary threat. The remote authentication
protocol is a promising way to protect patients and TMIS from attackers in
different information systems. We propose a new two-factor user authenti-
cation scheme for medical storage services to resolve the above issues.
In this paper, we show that many of the two-factor authentication schemes
are not secure against an off-line dictionary attack and fail to provide the re-
vocation of lost/stolen disguised smart card. To overcome these drawbacks,
we suggest an improved scheme to achieve an efficient authentication phase
using a secure searchable keyword as a password-based authentication. In
this scheme, we propose to bring together the advance of both the crypto
and IR community [3, 4, 5] to construct a novel authentication scheme to
overcome the security drawbacks. Also, we apply cryptographic methods by
disclosing the data decryption key only to authorized patients and doctors
to retrieve medical files containing certain keywords. Furthermore, we show
that the proposed scheme is secure in the random oracle model (ROM).
In 1981, Lamport [6] presented a password-based authentication technique in



An Efficient Two Factor User Authentication and ..... 1017

which the TMIS server saved all the passwords into a password table. Later,
this topic has become popular among researchers [7, 8]. These techniques
are susceptible to stolen-verifier attacks. Dictionary attacks may guess a
password list with low entropy. In other words, password-based authenti-
cation fails to withstand the password-guessing attacks. To overcome these
problems, traditional password authentications have been combined with the
smart cards to form a two-factor-based authentication scheme. Two-factor
authentication requires a legal user to have both valid factors: password and
card. The authentication procedure would fail if either of the two factors was
invalid. With the support of the two-factor authentication, users and TMIS
servers can be authenticated by each other. A session key will be shared
between users and TMIS servers for securing communication after the au-
thentication phase. The session key can preserve the privacy of the user’s
personal information during communication operation over public networks
[9]. Recently, researchers presented various authentication schemes to pro-
vide efficient health services for remote users and patients in TMIS. Wu et
al. [10] proposed an efficient authentication scheme for TMIS, which used
passwords and smart cards to construct a two-factor-based remote authenti-
cation scheme for TMIS. The scheme is better than the previously presented
schemes for low computing devices by adding the precomputing stage. Chen
et al. [11] proposed a dynamic ID-based authentication scheme which pro-
tects user anonymity and is less costly. Jiang et al.[12] proposed an authenti-
cation scheme that achieved patient anonymity. Also, Lin[13] observed that
user identity is disclosed under the dictionary attack and the password can be
inferred with the stolen smart card in the Chen et al. scheme. He suggested
an enhanced scheme which efficiently withstands the dictionary attack and
protects anonymity. Xu et al.[14] proposed a two-factor authentication key
agreement scheme using ECC. As a new direction, biometric keys can main-
tain the uniqueness feature because they can neither be forged nor estimated
easily. Therefore, biometric keys have been widely used in authentication
protocols [15].



1018 F. Sherali, S. Falah

2 Preliminaries

In this section, we present some necessary concepts needed in this work.

2.1 Complexity assumptions

Here, we review the definition of the Bilinear Diffie-Hellman (BDH) problem
associated with the bilinear pairings [16].

Definition 2.1. (BDH Problem) Let Gx, Gy be two groups of prime order
r, v be a generator of Gx, ê : Gx × Gx → Gy be an admissible bilinear map
and AR be an attacker algorithm. The BDH problem in (Gx, Gy, ê) is as fol-
lows: Given (v, va, vb, vc) for some a, b, c ∈ Zn, compute ê(v, v)abc ∈ Gy. An
algorithm AR has advantage in solving BDH in Gy if Pr[AR(v, va, vb, vc) =
ê(v, v)abc] ≥ ǫ.

2.2 Random oracles

In our scheme, we use asymmetric encryption and three cryptographic hash
functions h1 : {0, 1}∗ → Gx and h2 : Gy → {0, 1}logr, where h1 and h2

are random oracles[17], and select one hash function h3 to secure the ID of
patient. The cryptographic one-way hash function is irreversible and it de-
mands less execution time for encryption/decryption algorithms. Therefore,
our proposed scheme is efficient.

3 Problem formulation

Our scheme involves three different entities: patients, doctors, and medical
servers. We suppose that these entities are semi-honest and do not collude
with each other to skip the security measures.
- Patient P : this entity has a collection of medical filesMF= {mf1, mf2, ..., mfn},
which are encrypted using a standard symmetric algorithm like AES. To al-
low the searching capability over the encrypted medical files for effective data
utilization, the patient, in an off-line stage before uploading, will first encrypt
keyword set Kw extracted from MF. Patient uploads both the Kw and the
encrypted medical files to the medical server.
- Doctor D: this entity is an authorized user to access the medical files of the
patient. With l query keywords, the authorized doctor can create a trapdoor
Td through search control mechanisms to retrieve the encrypted record from



An Efficient Two Factor User Authentication and ..... 1019

the server. Then, the doctor can decrypt the medical files with the shared
secret key.
- Medical Server MS: the server stores the encrypted keywords and the en-
crypted medical files for the patient. Upon receiving the trapdoor Td from
the Doctor, the server searches over the keyword set and retrieves the corre-
sponding set of the encrypted medical files.

4 Outline of the proposed scheme

Initially, the patients P and the medical servers MS are enrolled with the
medical service registration center. Patient authentication is verified by the
smart card SMC and only the authentic patients can log into the system.
MS also checks the authenticity of the patient with respect to the received
login message. The medical server sends a reply-message to the patient
after verification of authentication. Then, the patient checks the authenticity
of the MS based on the received message. On the other hand, to retrieve
only the medical records containing keyword Kw, the doctor computes the
trapdoor Td and sends it to theMS. The scheme includes four phases, namely,
Registration phase, Login phase, Authentication phase and Doctor phase.

I. Registration phase
Step 1. Patient P chooses a keyword of his choice, P encrypts kw us-
ing the key generation algorithm and keyword encryption algorithm as
follows:
-The medical server provider MSP and patient P run key generation al-
gorithm, the algorithm takes the large security parameters ¾1, ¾2 ∈ Z+

to generate a prime number r, selects a random generator V of G1,
selects a random ι, γ, β ∈ Zr as private keys for P , MS and D respec-
tively, computes the corresponding public keys PPub = V Îą,MSPub =
V γ and DPub = V β for P , MS, and D respectively.
- As mentioned before we use a public key encryption algorithm to
encrypt keywords, the patient runs the keyword encryption algorithm
using a public key PPub to encrypt kw, Ckw = h2(ê(DPub, h1(Kw)α)).
- P sends the registration request with encrypted keyword Cwk, the
identity of patient IDp and encrypted medical record MF to MSP via
secure channel.
Step 2. Upon receiving the P’s request, MSP verifies whether IDp
is previously registered or not. If IDp is already registered, MSP
asks for a new identity. Otherwise, MSP computes K = h3((ID

Îł
P )).



1020 F. Sherali, S. Falah

Then MSP personalizes smart card SMC by embedding the parameters
{Cwk, K,MSPub, h3(.)} and returns SMC to P via a secure channel.
SMC stores IDp in registered patients’ database.
Step 3. P computes K = h3((ID

Îą
P )), X1 = h3(K||Kw) and Z =

X1||Cwk then stores Cwk, Îą and X1 into the smart card

II. Login phase: a registered patient with a valid smart card generates the
login message and submits the login message to the server as follows:
Step 1. patient P inserts the smart card SMC into the card reader and
inputs Kw and IDp.
Step 2. SMC computes KK = h3((IDP ))

P . X2 = h3(KK||Kw) and
CKw, SMC verifies Z = X2||CKw. If the verification does not hold,
SMC terminates the session. Otherwise, SMC selects a random prime
number nP , and computes K1 = h3(IDP ||KK||CKw||TP )

MSPub where
TP is the current timestamp. Finally, SMC submits K1 and TP as a
message to MS.

III. Authentication phase: patient and server mutually authenticate each
other and establish a session key as follows:
Step 1. Upon receiving T1 at time T́P , MSP checks whether the con-
dition T́P − TP holds. If the condition holds, MSP verifies KSPriv

1 mod
r = h3(ID||KK||nP ||Ckw||TP ), If the verification holds, MSP considers
P as an authorized patient. Then MSP computes TPs = TP ⊕ Ts and
the session key Skey = h(TPs||nP ||Ckw). Finally, MS responds with TPs

and Skey.

Step 2. Upon receiving TPs and Skey at time T́s, SMC verifies T́s−Ts ≤
△T . If the verification holds, MS computes the session key Śkey =

h3(TPs||nP ||Ckw). Then MS verifies Śkey = Skey. If the verification
holds, P considers Skey as the session key and MS as an authorized
server

IV. Doctor Phase: this phase includes two algorithms, Trapdoor algorithm
and keyword check algorithm. In the first algorithm, D takes a private
key β and a keyword Td to compute trapdoorTd as Td=h2(ê(PPub, h1(Td)

β)).
Then, D submits the trapdoor to the medical server. The keyword
check algorithm is executed by the MSP, it takes an encrypted key-
word Ckw, and a trapdoor Td as inputs, and outputs 1 or 0. The
algorithm outputs 1 if Kw=Td, and 0 otherwise. If the output is 1,
MSP considers that D as an authorized doctor.



An Efficient Two Factor User Authentication and ..... 1021

5 Security and performance analysis of the

proposed schemes

5.1 Informal security analysis

Here, we have discussed the security strength of the proposed scheme against
possible attacks. The security features of other existing schemes are com-
pared with the proposed scheme.

I. User Anonymity: the patient IDP is protected under the security of
secret key of MS and P . To know the IDP from the data stored in
the smart card, an attacker should know the keyword Kw and the
secret key Îą and Îł of the patient and the server respectively, only a
registered MS knows the secret key of the server. Therefore, only the
authentic server may compute the patient’s identity. The timestamp
Tp is different for each session. This ensures different login messages
for each session. Thus, an attacker cannot relate between any two-
login messages. Anonymity and Unlinkability make communication
completely private.

II. Man-in-The-Middle-Attack: in this attack, an attacker pretends as a
medical server to the patient P and as a patient to the medical server
MS. He needs to be authenticated by both P and MS. However, the
attacker cannot be authenticated by the medical server without the
validity of P ’s keyword α and the attacker cannot be authenticated by
the patient without MS’s secret key γ. This shows that the scheme
resists man-in-the-middle attack.

III. Off-Line Dictionary Attack: an attacker may target the SMC to guess
the keyword. The keyword is associated with the following values Z =
X1||Cwk whereX1 = h3((IDP ))

α||Kw and Cwk = h2(ê(DPub, h1(Kw)α)).
However, the attacker needs to know IDp, Kw, and the secret key Îą.
Again, it is hard to know the secret key Îą and the patient IDp to obtain
the keyword Kw by the attacker.

IV. Replay Attacks: the scheme uses the current timestamp in every session
to prevent the replay attacks. An attacker tries to intercept message
〈K1, TP 〉 of the login. If the attacker replays a previous message by
resubmitting to the medical server or the patient, the medical server
or the patient will detect the attack immediately when the freshness



1022 F. Sherali, S. Falah

of the timestamps will be verified. If the attacker wants to construct a
valid message, he needs to know the secret key Îą, the random number
nP and IDp. However, attacker cannot get them. Hence the proposed
scheme has abilities to withstand replay attack.

V. Impersonation Attack: once attacker At intends to launch a patient
or server impersonation attack, he/she must compute the valid value
of Ḱ1 = h3(IDP ||ḰK||Ckw||TP )

MSPub. An attacker couldn’t compute
ḰK for many reasons: (1) attacker could not compute ḰK, because
he did not know the secret keys Îą and Îł of the patient and medi-
cal server respectively. (2) Neither the keyword nor IDp is known by
the attacker. Thus, an attacker cannot compute Ḱ1. Therefore, the
improved protocol can resist impersonation attacks.

VI. Stolen Smart Card Attacks: we suppose that a smart card is stolen by
an attacker and he can extract all stored information (Cwk, K,MSPub, X1)
from the stolen smart card and try to generate a valid login mes-
sage using these parameters. Where X1 = h3(K||Kw) and Ckw =
h2(ê(DPub, h1(Kw)α)). The adversary may try to compute the secret
embedded parameters from the extracted information of SMC. How-
ever, it is difficult to disclose any information from hash values. There-
fore, the proposed scheme avoids smart card stolen attack.

VII. Mutual Authentication: the medical server authenticates the patient
by extracting KK. The computation of KK needs h3((IDP ))

Îą which
requires the patient’s secret key. On the other hand, the medical server
is verified by the Patient with h3(Tps||np||Ckw). Because an attacker
doesn’t have the secret key of MS, he cannot calculate the session key
Śkey correctly. Therefore, the mutual authentication between the med-
ical server and the patient is achieved in this scheme.

VIII. Privileged-Insider Attacks: a user sends Ckw = h2(ê(DPub, h1(Kw)α))
to the MS in the registration phase. An insider patient of the trusted
MS may behave like an attacker At and the registration message of the
patient can be recorded by At during the registration of the patient
P . Furthermore, we assume that At can access all secret information
of SMC. In this scheme, no Kw related parameters are stored in MS’s
database. Hence, extracting theKw from Ckw without exact knowledge
of the key Îą is a very hard problem. For that reason, a privileged insider
cannot pretend the patient P to log into the MS because the At does
not know Kw. As a result, the proposed scheme resists insider attacks.



An Efficient Two Factor User Authentication and ..... 1023

5.2 Security proof

In this section, we show that the proposed protocol is secure in the formal
security model. We prove its security in the random oracle model ROM under
the fact that the BDH problem is computationally infeasible to be solved.

To analyze the security of the proposed method, we provide the following
theorem, which shows that the proposed method is semantically secure under
the BDH assumption:

Theorem 5.1. Let h1 and h2 be random oracles from {0, 1}∗ to Gx and from
Gy to {0, 1}n, respectively. Suppose At is an attacker that has the advantage
Îľ against the proposed protocol. Suppose At makes qh2 > 0 hash function
queries to h2. Then, there is an algorithm C that solves the Bilinear Diffie-
Hellman Problem with the advantage at least ξ́ = 2ξ

qh2

.

Proof. C is given σ ∈ {0, 1}logq, θ0 = V, θ1 = V ι, θ2 = V β, θ3 = V γ where
ι, β, γ are random numbers in Zq. The goal is to output G = é(V, V )ιβγ ∈
Gy. Let V be the solution to the BDHP. C finds G by interacting with the
adversary as follows:
KeyGen: C sends (θ0, θ1) as the public key to At
h1-queries: C maintains a list of tuples called h1-list, in which each entry
is a tuple of the form 〈σj , δj〉. The list is initially empty. When At queries
h1 at a point of σi, C checks if σi = σj where σj already appears on h1-list.
If so, C answers At with h1(σi) = δj . Otherwise, C picks a random element
λ ∈ Zq, computes δj = θ2 ∗ V λ = V β ∗ V λ, adds the tuple 〈σi, δi〉 to h1- list,
and answers At with h1(σi) = δi.
h2-queries: C maintains a list of tuples called h2-list, in which each entry is
a tuple 〈ǫj, τj〉. The list is initially empty. When At queries h2 at a point of
ÇŤi, C checks if ÇŤi = ÇŤj where ÇŤj already appears on h2-list. If so, C answers
At with h2(ǫi) = τj . Otherwise, C picks a random string τi ∈ {0, 1}n, adds
the tuple 〈ǫi, τi〉 to h2-list, and answers At with hi(ǫi) = τi.
Challenge: At outputs two keywords σ0 and σ1 on which it wishes to be
challenged. C randomly picks b ∈ {0, 1} and gives θ1 to At.
Since C is given θ0, θ1, θ2, and θ3 as part of the BDH challenge, C creates the
secure keyword by executing the keyword encryption algorithm and sends
the challenge to At,
σb = h2(é(h1(σ), θ1)

Îł)
= h2(é(h1(σ), V

Îą)Îł)
= h2(é(V

β ∗ V λ, V α)γ)
= h2(é(V

β+Ν, V ι)γ)
= h2(é(V, V )ιγ(β+Ν))



1024 F. Sherali, S. Falah

Hence, θ1 is a valid keyword for σb as required.
Guess: At outputs its guess b́ ∈ {0, 1} for b. C picks a random pair 〈ǫi, τi〉
from h2-list and outputs ÇŤii as the solution to the given instance of BDHP.
Now, we complete the proof of the above theorem, we show that C correctly
outputs M with the probability at least 2Îľ/q. Let v be the event that At
issues a query for z. If −v, we know that the decryption of the ciphertext is
independent of Ats view. Let pr[b = b́] be the probability that At outputs
the correct result, therefore, in the real attack pr[b = b́| − v] = 1

2
Since At

has the advantage ε, pr[b = b́| − v]− 1
2
| ≥ ε. Based on the following formula,

we know pr[v] ≥ 2ε:
Pr[b = b́] = Pr[b = b́| − v]Pr[−v] + Pr[b = b́|v]Pr[v] ≤ 1

2
Pr[−v] + Pr[v] =

1
2
+ 1

2
Pr[v],

Pr[b = b́] ≥ Pr[b = b́| − v]Pr[−v] = 1
2
Pr[−v] = 1

2
− 1

2
Pr[v].

Therefore, we have Pr[v] ≥ 2ε in the real attack. That is to say, At will
issue a query for τ with the probability at least 2ε. C will choose the correct
pair with the probability at least 1

qh2

and thus, Cproduces the correct answer

with the probability at least ξ́ = 2ξ
qh2

as required.

6 Performance comparisons

Here, we compare our method with the related recent existing schemes. The
performance of the proposed scheme is compared with the [18, 19, 20, 21,
23, 22, 24, 25, 26] concerning their securities. In this scheme, the keyword
is protected using the secret key and random oracle hash function under the
Bilinear Diffie-Hellman Problem BDHP. A secret key is embedded in a smart
card; it is required to extract theKw from SMC. The comparison is presented
in Table 1. In this table, we consider different attacks and compare our
scheme with the related mentioned schemes. According to informal security
analysis, it has been observed that the proposed scheme withstands all the
different known attacks.

7 Conclusion

In this paper, we have first revisited a series of two-factor authentication
schemes and shown that they are not secure against the off-line dictionary at-
tack. To cope with the aforementioned defects, we have proposed a novel and



An Efficient Two Factor User Authentication and ..... 1025

Table 1: Comparison with respect to security features.
[18] [19] [20] [21] [23] [22] [24] [25] [26] Our

User anonymity × √ √ × × √ √ × √ √

Off-line dictionary attack
√ √ √ √ √ √ √ √ √ √

Replay attacks × × √ √ √ √ √ √ √ √

Impersonation on attack × √ √ √ × √ √ × √ √

Stolen smart card attacks × √ √ √ √ √ √ √ √ √

Mutual authentication × √ √ × √ √ √ × √ √

Privileged insider attacks
√ √ √ × √ √ × × × √

secure authentication scheme using a searchable encrypted keyword, which
possesses high security properties to protect the valid patient against attacks
and helps the doctor to retrieve medical files containing such encrypted key-
words. The protocol is proved secure in the random oracle model. The pro-
posed method is efficient and practical compared with other existing schemes.
Comprehensive security analysis shows that the robustness of the proposed
method is more secure than other related schemes.

References

[1] S. H. Li, C. Y. Wang, W. H. Lu, Y. Y. Lin, D. C. Yen, ”Design and
implementation of a telecare information platform,” J. Med. Syst., 36,
no. 3, (2012), 1629–1650.

[2] E. Kyriacou et al., ”Multi-purpose HealthCare Telemedicine Systems
with mobile communication link support,” 2003. Accessed: Apr. 14,
2020. [Online]. Available:
http://www.biomedical-engineering-online.com/content/2/1/7.

[3] F. S. Ali, H. N. Saad, F. H. Sarhan, B. Naaeem, ”Enhance manet us-
ability for encrypted data retrieval from cloud computing,” Indones. J.
Electr. Eng. Comput. Sci., 18, no. 1, (2019), 64–74.

[4] F. S. Ali, S. F. Lu, ”Public Key Encryption with Conjunctive Field Free
Keyword Search Scheme Indexing terms, 15, no. 14, (2016), 7423–7434.

[5] F. S. Ali, S. Lu, ”Searchable encryption with conjunctive field free key-
word search scheme,” Proc. 2016 Int. Conf. Netw. Inf. Syst. Comput.,
ICNISC 2016, (2017), 260–264.



1026 F. Sherali, S. Falah

[6] L. Lamport, ”Password Authentication with Insecure Communication,”
Commun. ACM, 24, no. 11, (1981), 770–772.

[7] Q. Jiang, F. Wei, S. Fu, J. Ma, G. Li, A. Alelaiwi, ”Robust extended
chaotic maps-based three-factor authentication scheme preserving bio-
metric template privacy,” Nonlinear Dyn., 83, no. 4, (2016), 2085–2101.

[8] D. Wang, P. Wang, ”Two Birds with One Stone: Two-Factor Authen-
tication with Security beyond Conventional Bound,” IEEE Trans. De-
pendable Secur. Comput., 15, no. 4, (2018), 708–722.

[9] Y. Zhao, S. Li, L. Jiang, ”Secure and Efficient User Authentication
Scheme Based on Password and Smart Card for Multiserver Environ-
ment,” 2018.

[10] Z.-Y. Wu, Y.-C. Lee, F. Lai, H.-C. Lee, Y. Chung, ”A Secure Authen-
tication Scheme for Telecare Medicine Information Systems,” J. Med.
Syst., 36, no. 3, (2012), 1529–1535.

[11] H. M. Chen, J. W. Lo, C. K. Yeh, ”An efficient and secure dynamic ID-
based authentication scheme for telecare medical information systems,”
in Journal of Medical Systems, 36, no. 6, (2012), 3907–3915.

[12] Q. Jiang, J. Ma, Z. Ma, G. Li, ”A privacy enhanced authentication
scheme for telecare medical information systems,” J. Med. Syst., 37,
no. 1, (2013), 1–8.

[13] H. Y. Lin, ”On the security of a dynamic ID-based authentication
scheme for telecare medical information systems,” J. Med. Syst., 37,
no. 2, (2013), 1–5.

[14] X. Xu, P. Zhu, Q. Wen, Z. Jin, H. Zhang, L. He, ”A secure and efficient
authentication and key agreement scheme based on ECC for telecare
medicine information systems,” J. Med. Syst., 38, no. 1, (2014), 9994.

[15] G. Panchal, D. Samanta, S. Barman, ”Biometric-based cryptography for
digital content protection without any key storage,” Multimed. Tools
Appl., 78, no. 19,(2019), 26979-27000.

[16] D. Boneh, M. Franklin, ”Identity-based encryption from the weil pair-
ing,” Lect. Notes Comput. Sci. (including Subser. Lect. Notes Artif.
Intell. Lect. Notes Bioinformatics), 2139, LNCS, no. 3, (2001), 213–
229.



An Efficient Two Factor User Authentication and ..... 1027

[17] M. Bellare, P. Rogaway, ”Random Oracles are Practical: A Paradigm
for Designing EEcient Protocols,” ACM, 1993.

[18] M. C. Chuang, M. C. Chen, ”An anonymous multi-server authenticated
key agreement scheme based on trust computing using smart cards and
biometrics,” Expert Syst. Appl., 41, (2014), 1411–1418.

[19] D. Mishra, A. K. Das, S. Mukhopadhyay, ”A secure user anonymity-
preserving biometric-based multi-server authenticated key agreement
scheme using smart cards, Expert Syst. Appl., 41, no. 18, (2014), 8129–
8143.

[20] R. Amin, G. P. Biswas, A Novel User Authentication and Key Agree-
ment Protocol for Accessing Multi-Medical Server Usable in TIMS, J.
Med. Syst., 39, no. 3, (2015), 33.

[21] H. Lin, F. Wen, C. Du, ”An Improved Anonymous Multi-Server Authen-
ticated Key Agreement Scheme Using Smart Cards and Biometrics,”
Wirel. Pers. Commun., 84, no. 4, (2015), 2351–2362.

[22] A. Irshad, S. A. Chaudhry, S. Kumari, M. Usman, K. Mahmood, M. S.
Faisal, ”An improved lightweight multiserver authentication scheme,”
Int. J. Commun. Syst., 30, no. 17, (2017), e3351.

[23] Y. Lu, L. Li, X. Yang, Y. Yang, ”Robust Biometrics Based Authentica-
tion and Key Agreement Scheme for Multi-Server Environments Using
Smart Cards,” PLoS One, 10, no. 5, (2015), e0126323.

[24] R. Ali, A. K. Pal, ”Three-Factor-Based Confidentiality-Preserving Re-
mote User Authentication Scheme in Multi-server Environment,” Arab.
J. Sci. Eng., 42, no. 8, (2017), 3655–3672.

[25] C. Wang, X. Zhang, Z. Zheng, ”Cryptanalysis and improvement
of a biometric-based multi-server authentication and key agreement
scheme,” PLoS One, 11, no. 2, (2016), e0149173.

[26] S. Barman, A. K. Das, D. Samanta, S. Chattopadhyay, J. J. P. C. Ro-
drigues, Y. Park, ”Provably Secure Multi-Server Authentication Proto-
col Using Fuzzy Commitment,” IEEE Access, 6, (2018), 38578–38594.


";"""date"",""2020-08-27T03:23:22Z""
""pdf:unmappedUnicodeCharsPerPage"",""2"",""0"",""0"",""0"",""0"",""0"",""2"",""0"",""8"",""2"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.4""
""xmp:CreatorTool"",""dvips(k) 5.999 Copyright 2019 Radical Eye Software""
""pdf:docinfo:title"",""R-Fairooz.dvi""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dcterms:created"",""2020-08-27T03:23:22Z""
""language"",""en""
""Last-Modified"",""2020-08-27T03:23:22Z""
""dcterms:modified"",""2020-08-27T03:23:22Z""
""dc:format"",""application/pdf; version=1.4""
""title"",""R-Fairooz.dvi""
""xmpMM:DocumentID"",""uuid:28f874da-ea70-11ea-0000-7e0a3c731484""
""Last-Save-Date"",""2020-08-27T03:23:22Z""
""pdf:docinfo:creator_tool"",""dvips(k) 5.999 Copyright 2019 Radical Eye Software""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2020-08-27T03:23:22Z""
""meta:save-date"",""2020-08-27T03:23:22Z""
""pdf:encrypted"",""false""
""dc:title"",""R-Fairooz.dvi""
""xmp:CreateDate"",""2020-08-26T20:23:22Z""
""modified"",""2020-08-27T03:23:22Z""
""Content-Length"",""130957""
""pdf:hasMarkedContent"",""false""
""Content-Type"",""application/pdf""
""xmp:ModifyDate"",""2020-08-26T20:23:22Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""pdf:producer"",""MiKTeX GPL Ghostscript 9.25""
""meta:creation-date"",""2020-08-27T03:23:22Z""
""created"",""2020-08-27T03:23:22Z""
""xmp:About"",""uuid:28f874da-ea70-11ea-0000-7e0a3c731484""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""13""
""Creation-Date"",""2020-08-27T03:23:22Z""
""resourceName"",""R-Fairooz.pdf""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""1571"",""2363"",""1972"",""1619"",""1910"",""1773"",""1777"",""2100"",""1865"",""1716"",""1548"",""1689"",""1616""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""producer"",""MiKTeX GPL Ghostscript 9.25""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""MiKTeX GPL Ghostscript 9.25""
""pdf:docinfo:created"",""2020-08-27T03:23:22Z""
";https://scholar.google.ch/scholar?start=780&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098826-243;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;The usefulness of sparsifiable inputs: how to avoid subexponential io;T Agrikola, G Couteau, D Hofheinz ; IACR International Conference on …, 2020  Springer;;"… T. Agrikola, G. Couteau and D. Hofheinz—Supported by ERC Project PREP-CRYPTO 724307 …

a uniformly random assignment of an element of S to the variable x. The notation \(\mathcal {A}

^{\mathcal {O}}\) indicates that the algorithm \(\mathcal {A} \) is given oracle access to …";Cité 1 fois;Les 5 versions;[PDF] semanticscholar.org;https://pdfs.semanticscholar.org/8d08/c58ee051c2a035b66de33df407a639891380.pdf;"
The Usefulness of Sparsifiable Inputs:
How to Avoid Subexponential iO

Thomas Agrikola1 Geoffroy Couteau2 Dennis Hofheinz3

1Karlsruhe Institute of Technology (KIT), Germany
2IRIF, Paris-Diderot University, CNRS, France

3ETH Zurich, Switzerland

May 12, 2020



Introduction

Indistinguishability obfuscation (IO) is a method to transform a
program into an unintelligible one maintaining the original functionality.

P1 ≡ P2

iO(P1) ≈ iO(P2)

iO iO

Introduction Recap Doubly probabilistic IO Applications Conclusion 1/15



Applications of iO

iO

[G
G

H
R

S
+

1
3

]
F

u
n

ct
io

n
a

l
en

cr
yp

ti
o

n

[C
sW

19;
A

C
IJS20]

Succinct

adaptive
M

P
C

[SW14]

Deniableencryption

[CLTV15]

Fully

homomorphic

encryption

[D
H

R
W

16
]

Sp
oo

ky
en

cr
yp

ti
on

[D
N

1
8

]
U

n
iversa

l
p

ro
xy

re-en
cryp

tio
n

[B
G

I16]

H
om

om
orphic

secret
sharing

[FHHL18]

Graded encodingschemes

[KLW15]
IO for Turing

machines

I We can build almost
anything from iO.

I But what can we do
from polynomial iO?

poly reduction to iO

subexp reduction to iO

Introduction Recap Doubly probabilistic IO Applications Conclusion 2/15



Applications of iO

iO

[G
G

H
R

S
+

1
3

]
F

u
n

ct
io

n
a

l
en

cr
yp

ti
o

n

[C
sW

19;
A

C
IJS20]

Succinct

adaptive
M

P
C

[SW14]

Deniableencryption

[CLTV15]

Fully

homomorphic

encryption

[D
H

R
W

16
]

Sp
oo

ky
en

cr
yp

ti
on

[D
N

1
8

]
U

n
iversa

l
p

ro
xy

re-en
cryp

tio
n

[B
G

I16]

H
om

om
orphic

secret
sharing

[FHHL18]

Graded encodingschemes

[KLW15]
IO for Turing

machines

I We can build almost
anything from iO.

I But what can we do
from polynomial iO?

poly reduction to iO

subexp reduction to iO

Introduction Recap Doubly probabilistic IO Applications Conclusion 2/15



Related work on removing subexp. IO

I Previous approaches to avoid subexponential reductions to iO:
replace iO with functional encryption, [GS16; GPSZ17; LZ17;
KLMR18]

I short signatures
I universal samplers
I non-interactive multiparty key exchange
I trapdoor one-way permutations
I multi-key functional encryption
I . . .

I But the supported operations are relatively restricted

Introduction Recap Doubly probabilistic IO Applications Conclusion 3/15



Related work on removing subexp. IO

I Previous approaches to avoid subexponential reductions to iO:
replace iO with functional encryption, [GS16; GPSZ17; LZ17;
KLMR18]

I short signatures
I universal samplers
I non-interactive multiparty key exchange
I trapdoor one-way permutations
I multi-key functional encryption
I . . .

I But the supported operations are relatively restricted

Introduction Recap Doubly probabilistic IO Applications Conclusion 3/15



Applications of iO

iO

[G
G

H
R

S
+

1
3

]
F

u
n

ct
io

n
a

l
en

cr
yp

ti
o

n

[C
sW

19;
A

C
IJS20]

Succinct

adaptive
M

P
C

[SW14]

Deniableencryption

[CLTV15]

Fully

homomorphic

encryption

[D
H

R
W

16
]

Sp
oo

ky
en

cr
yp

ti
on

[D
N

1
8

]
U

n
iversa

l
p

ro
xy

re-en
cryp

tio
n

[B
G

I16]

H
om

om
orphic

secret
sharing

[FHHL18]

Graded encodingschemes

[KLW15]
IO for Turing

machines

I We can build almost
anything from iO.

I But what can we do
from polynomial iO?

poly reduction to iO

subexp reduction to iO

piO abstraction

Introduction Recap Doubly probabilistic IO Applications Conclusion 4/15



Applications of iO

iO

[G
G

H
R

S
+

1
3

]
F

u
n

ct
io

n
a

l
en

cr
yp

ti
o

n

[C
sW

19;
A

C
IJS20]

Succinct

adaptive
M

P
C

[SW14]

Deniableencryption

[CLTV15]

Fully

homomorphic

encryption

[D
H

R
W

16
]

Sp
oo

ky
en

cr
yp

ti
on

[D
N

1
8

]
U

n
iversa

l
p

ro
xy

re-en
cryp

tio
n

[B
G

I16]

H
om

om
orphic

secret
sharing

[FHHL18]

Graded encodingschemes

[KLW15]
IO for Turing

machines

I We can build almost
anything from iO.

I But what can we do
from polynomial iO?

poly reduction to iO

subexp reduction to iO

piO abstraction

Introduction Recap Doubly probabilistic IO Applications Conclusion 4/15



Probabilistic IO

iO compiles programs into
unintelligible ones, while

preserving their functionality.

piO compiles randomized
programs into deterministic
unintelligible ones, while

preserving their functionality.

P iO(P)
iO

x

P(x)

x

P(x)

P1 ≡ P2

iO(P1) ≈ iO(P2)

iO iO

functionally
equivalent

P piO(P)
piO

x

P(x ; r)

x

P(x ; r ′)

P1 ≈ P2

piO(P1) ≈ piO(P2)

piO piO

deterministic

“functionally
indistinguishable”

Introduction Recap Doubly probabilistic IO Applications Conclusion 5/15



Probabilistic IO

iO compiles programs into
unintelligible ones, while

preserving their functionality.

piO compiles randomized
programs into deterministic
unintelligible ones, while

preserving their functionality.

P iO(P)
iO

x

P(x)

x

P(x)

P1 ≡ P2

iO(P1) ≈ iO(P2)

iO iO

functionally
equivalent

P piO(P)
piO

x

P(x ; r)

x

P(x ; r ′)

P1 ≈ P2

piO(P1) ≈ piO(P2)

piO piO

deterministic

“functionally
indistinguishable”

Introduction Recap Doubly probabilistic IO Applications Conclusion 5/15



Probabilistic IO

iO compiles programs into
unintelligible ones, while

preserving their functionality.

piO compiles randomized
programs into deterministic
unintelligible ones, while

preserving their functionality.

P iO(P)
iO

x

P(x)

x

P(x)

P1 ≡ P2

iO(P1) ≈ iO(P2)

iO iO

functionally
equivalent

P piO(P)
piO

x

P(x ; r)

x

P(x ; r ′)

P1 ≈ P2

piO(P1) ≈ piO(P2)

piO piO

deterministic

“functionally
indistinguishable”

Introduction Recap Doubly probabilistic IO Applications Conclusion 5/15



Probabilistic IO

iO compiles programs into
unintelligible ones, while

preserving their functionality.

piO compiles randomized
programs into deterministic
unintelligible ones, while

preserving their functionality.

P iO(P)
iO

x

P(x)

x

P(x)

P1 ≡ P2

iO(P1) ≈ iO(P2)

iO iO

functionally
equivalent

P piO(P)
piO

x

P(x ; r)

x

P(x ; r ′)

P1 ≈ P2

piO(P1) ≈ piO(P2)

piO piO

deterministic

“functionally
indistinguishable”

Introduction Recap Doubly probabilistic IO Applications Conclusion 5/15



Why does piO require subexponential iO?

I Programs are only required to be “functionally indistinguishable”

I Captures a vast class of programs, e.g.

P1(x ; r)

return Enc(pk, x ; r)
≈

P2(x ; r)

return Enc(pk, 0; r)

I Strategy due to Canetti et al., [CLTV15]:
I derive random coins from input x via PRF(K , x)

r := PRF(x)

return P(x ; r)

iO piO(P)

I use iO to obfuscate this deterministic program

Introduction Recap Doubly probabilistic IO Applications Conclusion 6/15



Why does piO require subexponential iO?

I Programs are only required to be “functionally indistinguishable”

I Captures a vast class of programs, e.g.

P1(x ; r)

return Enc(pk, x ; r)
≈

P2(x ; r)

return Enc(pk, 0; r)

I Strategy due to Canetti et al., [CLTV15]:
I derive random coins from input x via PRF(K , x)

r := PRF(x)

return P(x ; r)

iO piO(P)

I use iO to obfuscate this deterministic program

Introduction Recap Doubly probabilistic IO Applications Conclusion 6/15



Why does piO require subexponential iO?

I Programs are only required to be “functionally indistinguishable”

I Captures a vast class of programs, e.g.

P1(x ; r)

return Enc(pk, x ; r)
≈

P2(x ; r)

return Enc(pk, 0; r)

I Strategy due to Canetti et al., [CLTV15]:
I derive random coins from input x via PRF(K , x)

r := PRF(x)

return P(x ; r)

iO piO(P)

I use iO to obfuscate this deterministic program

Introduction Recap Doubly probabilistic IO Applications Conclusion 6/15



Why does piO require subexponential iO?

I Programs are only required to be “functionally indistinguishable”

I Captures a vast class of programs, e.g.

P1(x ; r)

return Enc(pk, x ; r)
≈

P2(x ; r)

return Enc(pk, 0; r)

I Strategy due to Canetti et al., [CLTV15]:
I derive random coins from input x via PRF(K , x)

r := PRF(x)

return P(x ; r)

iO piO(P)

I use iO to obfuscate this deterministic program

Introduction Recap Doubly probabilistic IO Applications Conclusion 6/15



Construction of piO due to Canetti et al., [CLTV15]

P1(x ; r)

return Enc(pk, x ; r)
≈

P2(x ; r)

return Enc(pk, 0; r)

Example:

r := PRF(x)

return P(x ; r)

piO construction:

I But iO security can only be applied if circuits behave fully
identically

I in our example, P1 and P2 behave very differently

 direct (polynomial) reduction to iO won’t work

I Use a “one-input-at-a-time” hybrid argument for all possible inputs
I this includes the randomness

 Our goal: reduce number of hybrids to a polynomial amount

Introduction Recap Doubly probabilistic IO Applications Conclusion 7/15



Construction of piO due to Canetti et al., [CLTV15]

P1(x ; r)

return Enc(pk, x ; r)
≈

P2(x ; r)

return Enc(pk, 0; r)

Example:

r := PRF(x)

return P(x ; r)

piO construction:

I But iO security can only be applied if circuits behave fully
identically

I in our example, P1 and P2 behave very differently

 direct (polynomial) reduction to iO won’t work

I Use a “one-input-at-a-time” hybrid argument for all possible inputs
I this includes the randomness

 Our goal: reduce number of hybrids to a polynomial amount

Introduction Recap Doubly probabilistic IO Applications Conclusion 7/15



Construction of piO due to Canetti et al., [CLTV15]

P1(x ; r)

return Enc(pk, x ; r)
≈

P2(x ; r)

return Enc(pk, 0; r)

Example:

r := PRF(x)

return P(x ; r)

piO construction:

I But iO security can only be applied if circuits behave fully
identically

I in our example, P1 and P2 behave very differently

 direct (polynomial) reduction to iO won’t work

I Use a “one-input-at-a-time” hybrid argument for all possible inputs
I this includes the randomness

 Our goal: reduce number of hybrids to a polynomial amount

Introduction Recap Doubly probabilistic IO Applications Conclusion 7/15



Construction of piO due to Canetti et al., [CLTV15]

P1(x ; r)

return Enc(pk, x ; r)
≈

P2(x ; r)

return Enc(pk, 0; r)

Example:

r := PRF(x)

return P(x ; r)

piO construction:

I But iO security can only be applied if circuits behave fully
identically

I in our example, P1 and P2 behave very differently

 direct (polynomial) reduction to iO won’t work

I Use a “one-input-at-a-time” hybrid argument for all possible inputs
I this includes the randomness

 Our goal: reduce number of hybrids to a polynomial amount

Introduction Recap Doubly probabilistic IO Applications Conclusion 7/15



Main tool – Extremely lossy functions

I Extremely lossy functions (ELFs) due to Zhandry, [Zha16] offer two
indistinguishable modes:

injective mode
image size exponential

extremely lossy mode
image size polynomial

I exist from exponential DDH

I We believe that some sort of (sub)exponential assumption is
inherent for probabilistic iO

I ELFs can be used to push this subexponentiality to a much more
well-understood assumption

Introduction Recap Doubly probabilistic IO Applications Conclusion 8/15



Main tool – Extremely lossy functions

I Extremely lossy functions (ELFs) due to Zhandry, [Zha16] offer two
indistinguishable modes:

injective mode
image size exponential

extremely lossy mode
image size polynomial

I exist from exponential DDH

I We believe that some sort of (sub)exponential assumption is
inherent for probabilistic iO

I ELFs can be used to push this subexponentiality to a much more
well-understood assumption

Introduction Recap Doubly probabilistic IO Applications Conclusion 8/15



Main tool – Extremely lossy functions

I Extremely lossy functions (ELFs) due to Zhandry, [Zha16] offer two
indistinguishable modes:

injective mode
image size exponential

extremely lossy mode
image size polynomial

I exist from exponential DDH

I We believe that some sort of (sub)exponential assumption is
inherent for probabilistic iO

I ELFs can be used to push this subexponentiality to a much more
well-understood assumption

Introduction Recap Doubly probabilistic IO Applications Conclusion 8/15



First try

P1(x ; r)

return Enc(pk, x ; r)
≈

P2(x ; r)

return Enc(pk, 0; r)

Example:

x = ELF(x)

r := PRF(x)

return P(x ; r)

I First try: reduce number of hybrids by applying the ELF on the
input x

I But pre-processing the program input x with an ELF will not
preserve the expected functionality of the circuit

Introduction Recap Doubly probabilistic IO Applications Conclusion 9/15



First try

P1(x ; r)

return Enc(pk, x ; r)
≈

P2(x ; r)

return Enc(pk, 0; r)

Example:

x = ELF(x)

r := PRF(x)

return P(x ; r)

I First try: reduce number of hybrids by applying the ELF on the
input x

I But pre-processing the program input x with an ELF will not
preserve the expected functionality of the circuit

Introduction Recap Doubly probabilistic IO Applications Conclusion 9/15



Our observation

I Common ground for many applications of piO:

D(m)

piO(P)

x
inputs x come from
distributions D(m)

I e.g., D(m) outputs encryptions of m,
or, D(¡) samples public encryption keys.

I Approach: reduce number of hybrids by applying the ELF on the
random tape of D to sparsify inputs

Introduction Recap Doubly probabilistic IO Applications Conclusion 10/15



Our observation

I Common ground for many applications of piO:

D(m)

piO(P)

x
inputs x come from
distributions D(m)

I e.g., D(m) outputs encryptions of m,
or, D(¡) samples public encryption keys.

I Approach: reduce number of hybrids by applying the ELF on the
random tape of D to sparsify inputs

Introduction Recap Doubly probabilistic IO Applications Conclusion 10/15



Our observation

I Common ground for many applications of piO:

D(m)

piO(P)

x
inputs x come from
distributions D(m)

I e.g., D(m) outputs encryptions of m,
or, D(¡) samples public encryption keys.

I Approach: reduce number of hybrids by applying the ELF on the
random tape of D to sparsify inputs

Introduction Recap Doubly probabilistic IO Applications Conclusion 10/15



Doubly-Probabilistic IO

I Our framework: doubly-probabilistic IO (dpiO)

D(m)

piO(P)

x

dpiOD(P)

D(m)

crs

auxx

1-source dpiO

CRS model

compiled
input sampler

certifies that
x is valid

obfuscation
depends on

input sampler D

dpiOD(P)

crs

D(m1)

aux1x1

D(m2)

aux2x2

2-source dpiO

CRS model

compiled
input sampler

certifies that
x is valid

obfuscation
depends on

input sampler D

Introduction Recap Doubly probabilistic IO Applications Conclusion 11/15



Doubly-Probabilistic IO

I Our framework: doubly-probabilistic IO (dpiO)

D(m)

piO(P)

x

dpiOD(P)

D(m)

crs

auxx

1-source dpiO

CRS model

compiled
input sampler

certifies that
x is valid

obfuscation
depends on

input sampler D

dpiOD(P)

crs

D(m1)

aux1x1

D(m2)

aux2x2

2-source dpiO

CRS model

compiled
input sampler

certifies that
x is valid

obfuscation
depends on

input sampler D

Introduction Recap Doubly probabilistic IO Applications Conclusion 11/15



Doubly-Probabilistic IO

I Our framework: doubly-probabilistic IO (dpiO)

D(m)

piO(P)

x

dpiOD(P)

D(m)

crs

auxx

1-source dpiO

CRS model

compiled
input sampler

certifies that
x is valid

obfuscation
depends on

input sampler D

dpiOD(P)

crs

D(m1)

aux1x1

D(m2)

aux2x2

2-source dpiO

CRS model

compiled
input sampler

certifies that
x is valid

obfuscation
depends on

input sampler D

Introduction Recap Doubly probabilistic IO Applications Conclusion 11/15



Doubly-Probabilistic IO

I Our framework: doubly-probabilistic IO (dpiO)

D(m)

piO(P)

x

dpiOD(P)

D(m)

crs

auxx

1-source dpiO

CRS model

compiled
input sampler

certifies that
x is valid

obfuscation
depends on

input sampler D

dpiOD(P)

crs

D(m1)

aux1x1

D(m2)

aux2x2

2-source dpiO

CRS model

compiled
input sampler

certifies that
x is valid

obfuscation
depends on

input sampler D

Introduction Recap Doubly probabilistic IO Applications Conclusion 11/15



Doubly-Probabilistic IO

I Our framework: doubly-probabilistic IO (dpiO)

D(m)

piO(P)

x

dpiOD(P)

D(m)

crs

auxx

1-source dpiO

CRS model

compiled
input sampler

certifies that
x is valid

obfuscation
depends on

input sampler D

dpiOD(P)

crs

D(m1)

aux1x1

D(m2)

aux2x2

2-source dpiO

CRS model

compiled
input sampler

certifies that
x is valid

obfuscation
depends on

input sampler D

Introduction Recap Doubly probabilistic IO Applications Conclusion 11/15



Construction

(x1, aux1)
valid wrt. D?

(x2, aux2)
valid wrt. D?

return ⊥

r := PRF(x1, x2)

return
P(x1, x2; r)

no

no

yes

yes

iO dpiOD(P) dpiOD(P)

D(m1)

x1 := D(m1; ELF(r1))

aux1 ← “NIZK-proof”

return (x1, aux1)

D(m1; r1)

aux1x1

D(m2)

x2 := D(m2; ELF(r2))

aux2 ← “NIZK-proof”

return (x2, aux2)

D(m2; r2)

aux2x2 number of valid inputs
only polynomial
when ELF is lossy

(we need that number
of possible mi is small)

Introduction Recap Doubly probabilistic IO Applications Conclusion 12/15



Construction

(x1, aux1)
valid wrt. D?

(x2, aux2)
valid wrt. D?

return ⊥

r := PRF(x1, x2)

return
P(x1, x2; r)

no

no

yes

yes

iO dpiOD(P) dpiOD(P)

D(m1)

x1 := D(m1; ELF(r1))

aux1 ← “NIZK-proof”

return (x1, aux1)

D(m1; r1)

aux1x1

D(m2)

x2 := D(m2; ELF(r2))

aux2 ← “NIZK-proof”

return (x2, aux2)

D(m2; r2)

aux2x2 number of valid inputs
only polynomial
when ELF is lossy

(we need that number
of possible mi is small)

Introduction Recap Doubly probabilistic IO Applications Conclusion 12/15



Construction

(x1, aux1)
valid wrt. D?

(x2, aux2)
valid wrt. D?

return ⊥

r := PRF(x1, x2)

return
P(x1, x2; r)

no

no

yes

yes

iO dpiOD(P) dpiOD(P)

D(m1)

x1 := D(m1; ELF(r1))

aux1 ← “NIZK-proof”

return (x1, aux1)

D(m1; r1)

aux1x1

D(m2)

x2 := D(m2; ELF(r2))

aux2 ← “NIZK-proof”

return (x2, aux2)

D(m2; r2)

aux2x2 number of valid inputs
only polynomial
when ELF is lossy

(we need that number
of possible mi is small)

Introduction Recap Doubly probabilistic IO Applications Conclusion 12/15



Construction

(x1, aux1)
valid wrt. D?

(x2, aux2)
valid wrt. D?

return ⊥

r := PRF(x1, x2)

return
P(x1, x2; r)

no

no

yes

yes

iO dpiOD(P) dpiOD(P)

D(m1)

x1 := D(m1; ELF(r1))

aux1 ← “NIZK-proof”

return (x1, aux1)

D(m1; r1)

aux1x1

D(m2)

x2 := D(m2; ELF(r2))

aux2 ← “NIZK-proof”

return (x2, aux2)

D(m2; r2)

aux2x2 number of valid inputs
only polynomial
when ELF is lossy

(we need that number
of possible mi is small)

Introduction Recap Doubly probabilistic IO Applications Conclusion 12/15



Leveled Homomorphic Encryption

I LHEL = (Gen,Enc,Dec,Eval) is a LHE scheme for depth-L
circuits C , if

I (Gen,Enc,Dec) is a PKE scheme, and

I Eval allows to homomorphically evaluate depth-L circuits on
ciphertexts

m1 m2

c1 c2

Enc Enc

EvalC C

=Dec

Introduction Recap Doubly probabilistic IO Applications Conclusion 13/15



Leveled Homomorphic Encryption

I LHEL = (Gen,Enc,Dec,Eval) is a LHE scheme for depth-L
circuits C , if

I (Gen,Enc,Dec) is a PKE scheme, and

I Eval allows to homomorphically evaluate depth-L circuits on
ciphertexts

m1 m2

c1 c2

Enc Enc

EvalC C

=Dec

Introduction Recap Doubly probabilistic IO Applications Conclusion 13/15



Leveled Homomorphic Encryption

I LHEL = (Gen,Enc,Dec,Eval) is a LHE scheme for depth-L
circuits C , if

I (Gen,Enc,Dec) is a PKE scheme, and

I Eval allows to homomorphically evaluate depth-L circuits on
ciphertexts

m1 m2

c1 c2

Enc Enc

EvalC C

=Dec

Introduction Recap Doubly probabilistic IO Applications Conclusion 13/15



Leveled Homomorphic Encryption

I LHEL = (Gen,Enc,Dec,Eval) is a LHE scheme for depth-L
circuits C , if

I (Gen,Enc,Dec) is a PKE scheme, and

I Eval allows to homomorphically evaluate depth-L circuits on
ciphertexts

m1 m2

c1 c2

Enc Enc

EvalC C

=Dec

Introduction Recap Doubly probabilistic IO Applications Conclusion 13/15



Leveled Homomorphic Encryption

I LHEL = (Gen,Enc,Dec,Eval) is a LHE scheme for depth-L
circuits C , if

I (Gen,Enc,Dec) is a PKE scheme, and

I Eval allows to homomorphically evaluate depth-L circuits on
ciphertexts

m1 m2

c1 c2

Enc Enc

EvalC C

=Dec

Introduction Recap Doubly probabilistic IO Applications Conclusion 13/15



Application LHE/FHE

I LHE construction due to Canetti et al., [CLTV15]

I one NAND gate is evaluated as follows:

a1 := Decsk1
(C1)

a2 := Decsk1
(C2)

return Encpk2
(a1∧a2)

Eval∧

Encpk1
(m1) Encpk1

(m2)

C1 C2

piO

use compiled input samplers

produce output with
compiled input sampler

for next level

Introduction Recap Doubly probabilistic IO Applications Conclusion 14/15



Application LHE/FHE

I LHE construction due to Canetti et al., [CLTV15]

I one NAND gate is evaluated as follows:

a1 := Decsk1
(C1)

a2 := Decsk1
(C2)

return Encpk2
(a1∧a2)

Eval∧

Encpk1
(m1) Encpk1

(m2)

C1 C2

piO

use compiled input samplers

produce output with
compiled input sampler

for next level

Introduction Recap Doubly probabilistic IO Applications Conclusion 14/15



Application LHE/FHE

I LHE construction due to Canetti et al., [CLTV15]

I one NAND gate is evaluated as follows:

a1 := Decsk1
(C1)

a2 := Decsk1
(C2)

return Encpk2
(a1∧a2)

Eval∧

Encpk1
(m1) Encpk1

(m2)

(C1, aux1) (C2, aux2)

dpiOEncpk1

use compiled input samplers

produce output with
compiled input sampler

for next level

Introduction Recap Doubly probabilistic IO Applications Conclusion 14/15



Conclusion

iO

[G
G

H
R

S
+

1
3

]
F

u
n

ct
io

n
a

l
en

cr
yp

ti
o

n

[C
sW

19;
A

C
IJS20]

Succinct

adaptive
M

P
C

[SW14]

Deniableencryption

[CLTV15]

Fully

homomorphic

encryption

[D
H

R
W

16
]

Sp
oo

ky
en

cr
yp

ti
on

[D
N

1
8

]
U

n
iversa

l
p

ro
xy

re-en
cryp

tio
n

[B
G

I16]

H
om

om
orphic

secret
sharing

[FHHL18]

Graded encodingschemes

[KLW15]
IO for Turing

machines

I We can build almost
anything from iO.

I But what can we do
from polynomial iO?

I And what can we do
from polynomial iO
and ELFs?

poly reduction to iO

subexp reduction to iO

piO abstraction

subexp iO plus ELF

Introduction Recap Doubly probabilistic IO Applications Conclusion 15/15



Conclusion

iO

[G
G

H
R

S
+

1
3

]
F

u
n

ct
io

n
a

l
en

cr
yp

ti
o

n

[C
sW

19;
A

C
IJS20]

Succinct

adaptive
M

P
C

[SW14]

Deniableencryption

[CLTV15]

Fully

homomorphic

encryption

[D
H

R
W

16
]

Sp
oo

ky
en

cr
yp

ti
on

[D
N

1
8

]
U

n
iversa

l
p

ro
xy

re-en
cryp

tio
n

[B
G

I16]

H
om

om
orphic

secret
sharing

[FHHL18]

Graded encodingschemes

[KLW15]
IO for Turing

machines

I We can build almost
anything from iO.

I But what can we do
from polynomial iO?

I And what can we do
from polynomial iO
and ELFs?

poly reduction to iO

subexp reduction to iO

piO abstraction

subexp iO plus ELF

Introduction Recap Doubly probabilistic IO Applications Conclusion 15/15


	Introduction
	Recap
	Doubly probabilistic IO
	Applications
	Conclusion

";"""date"",""2020-05-12T08:57:32Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with Beamer class""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with Beamer class""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2020-05-12T08:57:32Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016/Debian) kpathsea version 6.2.2""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2020-05-12T08:57:32Z""
""created"",""2020-05-12T08:57:32Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-05-12T08:57:32Z""
""resourceName"",""c58ee051c2a035b66de33df407a639891380.pdf""
""Author"",""""
""producer"",""pdfTeX-1.40.17""
""pdf:docinfo:producer"",""pdfTeX-1.40.17""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""2"",""2"",""8"",""8"",""2"",""2"",""1"",""1"",""1"",""1"",""5"",""5"",""5"",""5"",""6"",""6"",""6"",""6"",""4"",""4"",""4"",""2"",""2"",""3"",""3"",""3"",""1"",""1"",""1"",""1"",""1"",""0"",""0"",""0"",""0"",""3"",""3"",""3"",""3"",""3"",""2"",""2"",""2"",""3"",""3""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2020-05-12T08:57:32Z""
""Last-Modified"",""2020-05-12T08:57:32Z""
""dcterms:modified"",""2020-05-12T08:57:32Z""
""title"",""""
""Last-Save-Date"",""2020-05-12T08:57:32Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2020-05-12T08:57:32Z""
""meta:save-date"",""2020-05-12T08:57:32Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016/Debian) kpathsea version 6.2.2""
""Content-Length"",""436370""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""47""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""221"",""220"",""447"",""447"",""390"",""390"",""461"",""461"",""410"",""410"",""410"",""410"",""385"",""385"",""385"",""385"",""480"",""480"",""480"",""480"",""425"",""425"",""425"",""310"",""310"",""308"",""308"",""308"",""378"",""378"",""378"",""378"",""378"",""401"",""401"",""401"",""401"",""269"",""269"",""269"",""269"",""269"",""310"",""310"",""331"",""510"",""510""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-05-12T08:57:32Z""
";https://scholar.google.ch/scholar?start=790&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098756-85;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;A Nexus of Smart Contracts? Gesellschaftsrechtspraxis und-theorie im Spiegel der Blockchain;F Möslein ; Festschrift für Christine Windbichler zum 70 …, 2020  degruyter.com;;"… 56 De Filippi/Wright Blockchain and the Law, 2018, 135; näher unter https://otonomos … „oracles“

als Schnittstelle zur Realität den Bedingungseintritt prüfen.63 Einzelne Klauseln sind als

dezentrale Applikationen (Dapp) auf Plattformen wie Ethereum hinterlegt64 und lassen sich …";;null;null;;;;https://scholar.google.ch/scholar?start=630&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098875-356;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Lower bounds on the time/memory tradeoff of function inversion;D Chawin, I Haitner, N Mazor ; Theory of Cryptography Conference, 2020  Springer;;"… We study time/memory tradeoffs of function inversion: an algorithm, ie, an inverter, equipped

with an s-bit advice on a randomly chosen function \(f:[n] \mapsto [n]\) and using q oracle queries

to f, tries to invert a randomly chosen output y of f, ie, to find \(x\in f^{-1}(y)\). Much …";Cité 1 fois;Les 4 versions;[PDF] tau.ac.il;http://www.cs.tau.ac.il/~iftachh/papers/TimeMemTO/TimeMemTO.pdf;"
Lower Bounds on the Time/Memory Tradeoff of
Function Inversion

Dror Chawin∗ Iftach Haitner∗† Noam Mazor∗

October 16, 2020

Abstract
We study time/memory tradeoffs of function inversion: an algorithm, i.e., an inverter,

equipped with an s-bit advice on a randomly chosen function f : [n] 7→ [n] and using q or-
acle queries to f , tries to invert a randomly chosen output y of f , i.e., to find x ∈ f−1(y).
Much progress was done regarding adaptive function inversion—the inverter is allowed to make
adaptive oracle queries. Hellman [IEEE transactions on Information Theory ’80] presented an
adaptive inverter that inverts with high probability a random f . Fiat and Naor [SICOMP ’00]
proved that for any s, q with s3q = n3 (ignoring low-order terms), an s-advice, q-query variant
of Hellman’s algorithm inverts a constant fraction of the image points of any function. Yao
[STOC ’90] proved a lower bound of sq ≥ n for this problem. Closing the gap between the
above lower and upper bounds is a long-standing open question.

Very little is known for the non-adaptive variant of the question—the inverter chooses its
queries in advance. The only known upper bounds, i.e., inverters, are the trivial ones (with
s+q = n), and the only lower bound is the above bound of Yao. In a recent work, Corrigan-Gibbs
and Kogan [TCC ’19] partially justified the difficulty of finding lower bounds on non-adaptive
inverters, showing that a lower bound on the time/memory tradeoff of non-adaptive inverters
implies a lower bound on low-depth Boolean circuits. Bounds that, for a strong enough choice
of parameters, are notoriously hard to prove.

We make progress on the above intriguing question, both for the adaptive and the non-
adaptive case, proving the following lower bounds on restricted families of inverters:
Linear-advice (adaptive inverter). If the advice string is a linear function of f (e.g., A×f ,

for some matrix A, viewing f as a vector in [n]n), then s+q ∈ Ω(n). The bound generalizes
to the case where the advice string of f1 + f2, i.e., the coordinate-wise addition of the
truth tables of f1 and f2, can be computed from the description of f1 and f2 by a low
communication protocol.

Affine non-adaptive decoders. If the non-adaptive inverter has an affine decoder—it out-
puts a linear function, determined by the advice string and the element to invert, of the
query answers—then s ∈ Ω(n) (regardless of q).

Affine non-adaptive decision trees. If the non-adaptive inversion algorithm is a d-depth
affine decision tree—it outputs the evaluation of a decision tree whose nodes compute a
linear function of the answers to the queries—and q < cn for some universal c > 0, then
s ∈ Ω(n/d log n).

Keywords: Function inverters; random functions, time/memory tradeoff.
∗School of Computer Science, Tel Aviv University. Emails: quefumas@gmail.com,iftachh@cs.tau.ac.il,noammaz@gmail.com.

Research supported by ERC starting grant 638121 and Israel Science Foundation grant 666/19.
†Member of the Check Point Institute for Information Security.



Contents
1 Introduction 1

1.1 Our Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Additional Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2 Our Technique 6
2.1 Linear-advice Inverters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2 Non-adaptive Inverters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

3 Preliminaries 10
3.1 Notation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.2 Matrices and Linear Spaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.3 Random Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.4 Additional Inequalities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

4 Linear-advice Inverters 15
4.1 Additive-advice Inverters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

5 Non-adaptive Inverters 18
5.1 Affine Decoders . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
5.2 Affine Decision Trees . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24



1 Introduction
In the function-inversion problem, an algorithm, inverter, attempts to find a preimage for a

randomly chosen y ∈ [n] of a random function f : [n]→ [n]. The inverter is equipped with an s-bit
advice on f , and may make q oracle queries to f . Since s lowerbounds the inverter space complexity
and q lowerbounds the inverter time complexity, it is common to refer to the relation between s
and q as the inverter’s time/memory tradeoff. The function-inversion problem is central to both
theoretical and practical cryptography. On the theoretical end, the security of many systems relies
on the existence of one-way functions. While the task of inverting one-way functions is very different
from that of inverting random functions, understanding the latter task is critical towards developing
lower bounds on the possible (black-box) implications of one-way functions, e.g., Impagliazzo and
Rudich [17], Gennaro et al. [13]. But advances on this problem (at least on the positive side, i.e.,
inverters) are likely to find practical applications. Indeed, algorithms for function inversion are
used to expose weaknesses in existing cryptosystems.

Much progress was done regarding adaptive function inversion—the inverter may choose its
queries adaptively (i.e., based on answers for previous queries). Hellman [16] presented an adaptive
inverter that inverts with high probability a random f . Fiat and Naor [11] proved that for any
s, q with s3q = n3 (ignoring low-order terms), an s-advice q-query variant of Hellman’s algorithm
inverts a constant fraction of the image points of any function. Yao [25] proved a lower bound of
s · q ≥ n for this problem. Closing the gap between the above lower and upper bounds is a long-
standing open question. In contrast, very little is known about the non-adaptive variant of this
problem—the inverter performs all queries at once. This variant is interesting since such inverter
is likely be highly parallelizable, making it significantly more tractable for real world applications.
The only known upper bounds for this variant, i.e., inverters, are the trivial ones (i.e., s+ q = n),
and the only known lower bound is the above bound of Yao [25]. In a recent work, Corrigan-Gibbs
and Kogan [8] have partially justified the difficulty of finding lower bounds on this seemingly easier
to tackle problem, showing that lower bounds on non-adaptive inversion imply circuit lower bounds
that, for strong enough parameters, are notoriously hard (see further details in Section 1.1.3).

1.1 Our Results
We make progress on this intriguing question, proving lower bounds on restricted families of

inverters. To state our results, we use the following formalization to capture inverters with a
preprocessing phase: such inverters have two parts, the preprocessing algorithm that gets as input
the function to invert f and outputs an advice string a, and the decoding algorithm that takes as
input the element to invert y, the advice string a, and using restricted query access to f tries to
find a preimage of y. We start with describing our bound for the time/memory tradeoff of linear-
advice (adaptive) inverters, and then present our lower bounds for non-adaptive inverters. In the
following, fix n ∈ N and let F be the set of all functions from [n] to [n].

1.1.1 Linear-advice Inverters

We start with a more formal description of adaptive function inverters.

Definition 1.1 (Adaptive inverters, informal). An s-advice, q-query adaptive inverter is a deter-
ministic algorithm pair C := (Cpre,Cdec), where Cpre : F → {0, 1}s, and C

(¡)
dec : [n]× {0, 1}

s → [n] is
a q-query algorithm. We say that C inverts F with high probability if

1



Pr
f←F

a:=Cpre(f)

 Pr
x←[n]

y:=f(x)

[
Cf
dec(y, a) ∈ f−1(y)

]
≥ 1/2

 ≥ 1/2.

It is common to refer to a (:= Cpre(f)) as the advice string. In linear-advice inverters, the
preprocessing algorithm Cpre is restricted to output a linear function of f . That is, Cpre(f1) +
Cpre(f2) = Cpre(f1 + f2), where the addition f1 + f2 is coordinate-wise with respect to an arbitrary
group over [n], and the addition Cpre(f1) + Cpre(f2) is over an arbitrary group that contains the
image of Cpre. An example of such a preprocessing algorithm is Cpre(f) := A×f , for A ∈ {0, 1}s×n,
viewing f ∈ F as a vector in [n]n. For such inverters, we present the following bound.

Theorem 1.2 (Bound on linear-advice inverters). Assume there exists an s-advice q-query inverter
with linear preprocessing that inverts F with high probability. Then s+ q · log n ∈ Ω(n).

We prove Theorem 1.2 via a reduction from set disjointness, a classical problem in the study
of two-party communication complexity. The above result generalizes to the following bound that
replaces the restriction on the decoder (e.g., linear and short output) with the ability to compute
the advice string of f1 + f2 by a low-communication protocol over the inputs f1 and f2.

Theorem 1.3 (Bound on additive-advice inverters, informal). Assume there exists a q-query in-
verter C := (Cpre, ¡) and an s-bit communication two-party protocol (P1,P2) such that for every
f1, f2 ∈ F , the output of P1 in (P1(f1),P2(f2)) equals with constant probability to Cpre(f1 + f2).
Then s+ q · log n ∈ Ω(n).

The above bound indeed generalizes Theorem 1.2: a preprocessing algorithm of the type required
by Theorem 1.2 immediately implies a two-party protocol of the type required by Theorem 1.3.

1.1.2 Non-adaptive Inverters

In the non-adaptive setting, the decoding algorithm has two phases: the query selection algo-
rithm that chooses the queries as a function of the advice and the element to invert y, and the
actual decoder that receives the answers to these queries along with the advice string and y.

Definition 1.4 (Non-adaptive inverters, informal). An s-advice, q-query non-adaptive inverter is
a deterministic algorithm triplet of the form C := (Cpre,Cqry,Cdec), where Cpre : F → {0, 1}s,
Cqry : [n] × {0, 1}s → [n]q and Cdec : [n] × {0, 1}s × [n]q → [n]. We say that C inverts F with high
probability if

Pr
f←F

a=Cpre(f)

 Pr
x←[n]

y=f(x)

v=Cqry(y,a)

[
Cdec(y, a, f(v)) ∈ f−1(y)

]
≥ 1/2

 ≥ 1/2.

Note that the query vector v is of length q, so the answer vector f(v) contains q answers.
Assuming there exists a field F of size n (see Remark 1.7), we provide two lower bounds for such
inverters.

2



Affine decoders. The first bound regards inverters with affine decoders. A decoder algorithm
Cdec is affine if it computes an affine function of f ’s answers. That is, for every image y ∈ [n] and
advice a ∈ {0, 1}s, there exists a q-sparse vector ιa

y ∈ Fn and a field element βa
y ∈ F such that

Cdec(y, a, f(Cqry(y, a))) = ⟨αa
y, f⟩ + βa

y for every f ∈ F . For this type of inverters, we present the
following lower bound.

Theorem 1.5 (Bound on non-adaptive inverters with affine decoders, informal). Assume there
exists an s-advice non-adaptive function inverter with an affine decoder, that inverts F with high
probability. Then s ∈ Ω(n).

Note that the above bound on s holds even if the inverter queries f on all inputs. While
Theorem 1.5 is not very insightful for its own sake, as we cannot expect a non-adaptive inverter to
have such a limiting structure, it is important since it can be generalized to affine decision trees,
a much richer family of non-adaptive inverters defined below. In addition, the result should be
contrasted with the question of black-box function computation, see Section 1.2.4, for which linear
algorithm are optimal. Thus, Theorem 1.5 highlights the differences between these two related
problems.

Affine decision trees. The second bound regards inverters whose decoders are affine decision
trees. An affine decision tree is a decision tree whose nodes compute an affine function, over F, of
the input vector. A decoder algorithm Cdec is an affine decision tree, if for every image y ∈ [n],
advice a ∈ {0, 1}s and queries v = Cqry(y, a), there exists an affine decision tree T y,a such that
Cdec(y, a, f(v)) = T y,a(f) (i.e., the output of T y,a on input f) for every f ∈ F . For such inverters,
we present the following bound.

Theorem 1.6 (Bounds on non-adaptive inverters with affine decision-tree decoders). Assume there
exists an s-advice q-query non-adaptive function inverter with a d-depth affine decision-tree decoder,
that inverts F with high probability. Then the following hold:

• q < cn, for some universal constant c, =⇒ s ∈ Ω(n/d log n).

• q ∈ n1−Θ(1) =⇒ s ∈ Ω(n/d).

That is, we pay a factor of 1/d comparing to the affine decoder bound, and the bound on s only
holds for not too large q. Affine decision trees are much stronger than affine decoders, since the
choice of the affine operations it computes can be adaptively dependent on the results of previous
affine operations. For example, a depth d affine decision tree can compute any function on d linear
combinations of the inputs. In particular, multiplication of function values, e.g., f(1) ¡ f(2), which
cannot be computed by an affine decoder, can be computed by a depth two decision tree. We note
that an affine decision tree of depth q can compute any function of its q queries. Unfortunately,
for d = q, our bound only reproduces (up to log factors) the lower bound of Yao [25].

Remark 1.7 (Field size). In Theorems 1.5 and 1.6, the field size is assumed to be exactly n (the
domain of the function to invert). Decoders over fields smaller than n are not particularly useful,
since their output cannot cover all possible preimages of f . Our proof breaks down for fields of size
larger than n, since we cannot use linear equations to represent the constraint that the decoder’s
output must be contained in the smaller set [n].

3



1.1.3 Applications to Valiant’s Common-bit Model

Corrigan-Gibbs and Kogan [8] showed that a lower bound on the time/memory tradeoff of
strongly non-adaptive function inverters—the queries may not depend on the advice—implies a
lower bound on circuit size in Valiant’s common-bit model [22, 23]. Applying the reduction of [8]
with Theorem 1.6 yields the following bound: for every n ∈ N for which there exits an n-size field
F, there is an explicit function f : Fn 7→ Fn that cannot be computed by a three-layer circuit of the
following structure:

1. It has o(n/d logn) middle layer gates.

2. Each output gate is connected to n1−Θ(1) inputs gates (and to an arbitrary number of middle-
layer gates).

3. Each output gate computes a function which is computable by a d-depth affine decision tree
in the inputs (and depends arbitrarily on the middle layer).

In fact, our bound yields that such circuits cannot even approximate f so that every output gate
outputs the right value with probability larger than 1/2, over the inputs.

1.2 Additional Related Work
1.2.1 Adaptive Inverters

Upper bounds. The main result in this setting is the s-advice, q-query inverter of Hellman
[16], Fiat and Naor [11] that inverts a constant fraction of the image of any function, for any s, q
such that s3q = n3 (ignoring low-order terms). When used for random permutations, a variant on
the same idea implies an optimum inverter with s ¡ q = n. The inverter of Hellman, Fiat and Naor
has found application to practical cryptanalysis, e.g., Biryukov and Shamir [5], Biryukov et al.
[6], Oechslin [19].

Lower bounds. A long line of research (Gennaro et al. [13], Dodis et al. [10], Abusalah et al.
[1], Unruh [21], Coretti et al. [7], De et al. [9]) provides lower bounds for various variations on the
classical setting, such as that of randomized inversion algorithms that succeed on a sub-constant
fraction of functions. None of these lower bounds, however, manage to improve on Yao’s lower
bound of s · q = n, leaving a large gap between this lower bound and Hellman, Fiat and Naor’s
inverter.

1.2.2 Non-adaptive Inverters

Upper bounds. In contrast with the adaptive case, it is not clear how to exploit non-adaptive
queries in a non trivial way. Indeed, the only known inverters are the trivial ones (roughly, the
advice is the function description, or the inverter queries the function on all inputs).

Lower bounds. Somewhat surprisingly, the only known lower bound for non-adaptive inverters
is Yao’s, mentioned above. This defies the basic intuition that this task should be easier than
the adaptive case, due to the extreme limitations under which non-adaptive inverters operate.
This difficulty was partially justified by the recent reduction of Corrigan-Gibbs and Kogan [8]

4



(see Section 1.1.3) that implies that a strong enough lower bound on even strongly non-adaptive
inverters, would yield a lower bound on low-depth Boolean circuits that is notoriously hard to
prove.

1.2.3 Relation to Data Structures

The problem of function inversion with advice may also be phrased as a problem in data
structures, where the advice string serves as a succinct data structure for answering questions
about f . In particular, it bears strong similarity to the substring search problem using the cell-
probe model [26]. This is the task of ascertaining the existence of a certain element within a large,
unsorted database, using as few queries to the database and as little preprocessing as possible.
Upper and lower bounds easily carry over between the two problems, a connection which was made
in Corrigan-Gibbs and Kogan [8], where it was used to obtain previously unknown upper bounds
on substring search.

1.2.4 Index Coding and Black-box Function Computation

A syntactically related problem to function inversion is the so-called black-box function compu-
tation: an algorithm tries to compute f(x), for a randomly chosen x, using an advice of length s
on f , and by querying f on q inputs other than x. Yao [24] proved that s · q ≥ n, and presented a
linear, non-adaptive algorithm that matches this lower bound.

A much-researched special case of this problem is known as the index coding problem [4],
originally inspired by information distribution over networks. In this setting, a single party is in
possession of a vector f , and broadcasts a short message a such that n different recipients may
each recover a particular value of f , using the broadcast message and knowledge of certain other
values of f , as determined by a knowledge graph. The analogy to non-adaptive black-box function
computation is obvious when considering a as the advice string, and the access to various values
of f as queries. While Yao’s bound on the time/memory tradeoff also holds for the index coding
problem, other lower bounds, some of which consider “linear” algorithms [4, 15, 18, 14, 3], do not
seem to be relevant for the function inversion problem.

Open Questions
The main challenge remains to gain a better understanding on the power of adaptive and non-

adaptive function inverters. A more specific challenge is to generalize our bound on affine decoders
and decision trees to affine operations over arbitrary (large) fields.

Paper Organization
A rather detailed description of our proof technique is given in Section 2. Basic notations,

definitions and facts are given in Section 3, where we also prove several basic claims regarding
random function inversion. The bound on linear-advice inverters is given in Section 4, and the
bounds on non-adaptive inverters are given in Section 5.

5



2 Our Technique
In this section we provide a rather elaborate description of our proof technique. We start with

the bound on linear-advice inverters in Section 2.1, and then in Section 2.2 describe the bounds for
non-adaptive inverters.

2.1 Linear-advice Inverters
Our lower bound for inverters with linear advice (and its immediate generalization to additive-

advice inverters) is proved via a reduction from set disjointness, a classical problem in the study
of two-party communication complexity. In the set disjointness problem, two parties, Alice and
Bob, receive two subsets, X and Y ⊆ [n], respectively, and by communicating with each other try
to determine whether X ∩ Y = ∅. The question is how many bits the parties have to exchange
in order to output the right answer with high probability. Given an inverter with linear advice,
we use it to construct a protocol that solves the set disjointness problem on all inputs in Q :=
{X ,Y ⊆ [n] : |X ∩ Y| ≤ 1} by exchanging s + q · log n bits. Razborov [20] proved that to answer
with constant success probability on all input pairs in Q, the parties have to exchange Ω(n) bits.
Hence, the above reduction implies the desired lower bound on the time/memory tradeoff of such
inverters.

Fix a q-query s-advice inverter C := (Cpre,Cdec) with linear advice, and assume for simplicity
that C’s success probability is one. The following observation immediately follows by definition: let
af := Cpre(f) and ag := Cpre(g) be the advice strings for some functions f and g ∈ F , respectively.
The linearity of Cpre yields that a := af +ag = Cpre(f + g). That is, a is the advice for the function
f + g (all additions are over the appropriate groups). Given this observation, we use C to solve
set disjointness as follows: Alice and Bob (locally) convert their input sets X and Y to functions
fA and fB respectively, such that for any x ∈ X ∊ Y it holds that f(x) := (fA + fB)(x) = 0, and
f(x) is uniform for x /∈ X ∊ Y. Alice then sends aA := Cpre(fA) to Bob who uses it to compute
a := Cpre(f) = aA+Cpre(fB). Equipped with the advice a and the help of Alice, Bob then emulates
Cdec(0, a) and finds x ∈ f−1(0), if such exists. Since f is unlikely to map many elements outside of
X ∩Y to 0, finding such x is highly correlated with X ∩Y ̸= ∅. In more details, the set disjointness
protocol is defined as follows.

Protocol 2.1 (Set disjointness protocol Π = (A(X ),B(Y))).

1. A samples fA ∈ F by letting fA(i) :=

{
0 i ∈ X
∟ [n] otherwise.

2. B samples fB ∈ F analogously, with respect to Y.

− Let f := fA + fB.

3. A sends aA := Cpre(fA) to B, and B sets a := aA + Cpre(fB). 1

4. B emulates Cf
dec(0, a) while answering each query r that Cdec makes to f as follows:

(a) B sends r to A.
1If the inverter is only assumed to have additive advice, this step is replaced with the parties interacting in the

guaranteed protocol for computing the advice for f from the descriptions of fA and fB.

6



(b) A sends wA := fA(r) back to B.
(c) B replies w := wA + fB(r) to Cdec (as the value of f(r)).

− Let x be Cdec’s answer at the end of the above emulation.

5. The parties reject if x ∈ X ∊ Y (using an additional Θ(log n) bits to find it out), and accept
otherwise.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

The communication complexity of Π is essentially s+ q ¡ log n. It is also clear that the parties
accept if X ∩Y = ∅. For the complementary case, by construction, the intersection point of X ∩Y
is in f−1(0). Furthermore, since f(i) is a random value for all i /∈ X ∩Y, with constant probability
only the intersection point is in f−1(0). Therefore, the protocol is likely to answer correctly also in
the case that |X ∊ Y| = 1.

2.2 Non-adaptive Inverters
We focus on inverters with an affine decoder, and discuss the extension to affine decision tree

decoders in Section 2.2.1. The proof follows by bounding the success probability of zero-advice
inverters—the preprocessing algorithm outputs an empty string. In particular, we prove that the
success probability of such inverters is at most 2−Ω(n). Thus, by a union bound over all advice
strings, in order to invert F with high probability, the advice string of a general (non-zero-advice)
inverter has to be of length Ω(n).2 Let C := (Cqry,Cdec) be a zero-advice q-query non-adaptive
inverter with an affine decoder. Let F be a random element of F , and for i ∈ [n], let Yi be
a randomly and independently selected element of [n]. Let Xi := Cdec(Yi, F (Cqry(Yi))), i.e., C’s
answer on challenge Yi, and let Zi be the indicator for {F (Xj) = Yj} for all j ∈ [i], i.e., the event
that C answers the first i challenges correctly. We prove the bound by showing that for some
m ∈ Θ(n) it holds that

Pr [Zm] ∈ 2−Ω(m) (1)

Note that Equation (1) bounds the probability that C inverts m random elements drawn from [n]
(where some of them might have no preimage at all), whereas we are interested in bounding the
probability that C inverts a random output of F . Yet, since F is a random function, its image
covers with very high probability a constant fraction of [n], and thus Equation (1) can be easily
manipulated to derive that

Pr
f←F

 Pr
x←[n]

y=f(x)

v=Cqry(f,y)

[
Cdec(y, f(v)) ∈ f−1(y)

]
≥ 1/2

 < 2−Ω(m) = 2−Ω(n) (2)

Hence, in order to invert a random function with high probability, a non-zero-advice inverter has
to use advice of length Ω(n).

We prove Equation (1) by showing that for every i ∈ [m] it holds that

Pr [Zi | Zi−1] < 3/5 (3)
2This first part of the proof is rather standard, cf., Akshima et al. [2].

7



That is, for small enough i, the algorithm C is likely to fail on inverting the ith challenge, even
when conditioned on the successful inversion of the first i− 1 challenges. We note that it is easy to
bound Pr [Zi | Zi−1] for zero-query inverters. The conditioning on Zi−1 roughly gives Θ(i) bits of
information about F . Thus, this conditioning gives at most one bit of information about F−1(Yi),
and the inverter does not have enough information to invert Yi. When moving to non-zero-queries
inverters, however, the situation gets much more complicated. By making the right queries, that
may depend on Yi, the inverter can exploit this “small” amount of information to find the preimage
of Yi. This is what happens, for instance, in the adaptive inverter of Hellman [16]. Hence, for
bounding Pr [Zi | Zi−1], we critically exploit the assumption that C is non-adaptive and has an
affine decoder. In particular, we bound Pr [Zi | Zi−1] by translating the event Zi into an affine
system of equations and then use a few observations about the structure of the above system to
derive the desired bound. These equations will have the form M ×F = V , viewing F as a random

vector in [n]n, for M :=

(
Mi−1

Mi

)
and V :=

(
V i−1

V i

)
, such that:

1. Mi−1 is a deterministic function of (X<i, Y<i) and Mi is a deterministic function of Yi, letting
X<i stand for (X1, . . . , Xi−1) and likewise for Y<i.

2. The event M i−1×F ′ = V i−1 is the event
∧

j<i {(F ′(Xj) = Yj) ∧ (Cdec(Yj , F
′(Cqry(Yj))) = Xj)},

for F ′ being a uniform, and independent, element of F .
(In particular, M i−1 × F = V i−1 implies that Zi−1 holds, and binds the value of (X<i, Y<i)
to V i−1.)

3. The event M i × F ′ = V i is the event {Cdec(Yi, F
′(Cqry(Yi))) = Xi}.

(In particular, M i × F = V i binds the value of Xi to V i.)

The above M and V are defined as follows: assume for ease of notation that C has a linear, and
not affine, decoder. That is, for every y ∈ [n] there exists a (q-sparse) vector ιy ∈ Fn such that
⟨αy, F ⟩ = Xy. By definition, for every j < i:

1. ⟨αYj , F ⟩ = Xj .

Conditioning on Zi−1 further implies that for every j < i:

2. F (Xj) = Yj .

Let ℓ := 2i − 2, and let Mi−1 ∈ Fℓ×n be the (random) matrix defined by Mi−1
2k−1 := αYk

and
Mi−1

2k := eXk
, letting ej being the unit vector (0j−1, 1, 0n−j). Let V i−1 ∈ Fℓ be the (random) vector

defined by V i−1
2k−1 := Xk and V i−1

2k = Yk. By definition, the event Zi−1 is equivalent to the event
Mi−1 × F = V i−1. The computation C makes on input Yi can also be described by the linear

equation ⟨αYi , F ⟩ = Xi. Let M :=

(
Mi−1

ÎąYi

)
and V :=

(
V i−1

Xi

)
. We make use of the following

claims (see proofs in Section 3.2).

Definition 2.2 (Spanned unit vectors). For a matrix A ∈ Fa×n, let E(A) :=
{j ∈ [n] : ej ∈ Span(A)}, for Span(A) being the (linear) span of A’s rows.

8



That is, E(A) is the set of indices of all unit vectors spanned by A. It is clear that |E(A)| ≤
rank(A) ≤ min {a, n}. The following claim states that for j /∈ E(A), knowing the value of A × F
gives no information about Fj .

Claim 2.3. Let A ∈ Fa×n and v ∈ Im(A). Then for every j ∈ [n] \ E(A) and y ∈ [n], it holds that
Prf←[n]n [fj = y | A× f = v] = 1/n.

The second claim roughly states that by concatenating a c-row matrix to a given matrix A, one
does not increase the spanned unit set of A by more than c elements.

Claim 2.4. For every A ∈ Fℓ×n there exists an ℓ-size set SA ⊆ [n] such that the following holds:

for every B ∈ Fc×n there exists a c-size set SB ⊆ [n] such that E
(

A
B

)
⊆ SA ∪ SB.

For bounding Pr [Zi | Zi−1] using the above observations, we write

Pr [Zi | Zi−1] = Pr [Zi ∧Xi ∈ E(M) | Zi−1] + Pr [Zi ∧Xi /∈ E(M) | Zi−1] (4)

and finish the proof by separately bounding the two terms of the above equation. Let H :=
(Xi, Y≤i,M, V ). We first note that

Pr [Zi ∧Xi /∈ E(M) | Zi−1] ≤ Pr [Zi | Xi /∈ E(M), Zi−1] (5)
= E

(xi,y≤i,m,v)←H|Xi /∈E(M),Zi−1

[Pr [F (xi) = yi | m× F = v, Y≤i = y≤i]]

= E
(xi,y≤i,m,v)←H|Xi /∈E(M),Zi−1

[Pr [F (xi) = yi | m× F = v]]

= 1/n.

The first equality holds by definition of Zi−1, the second equality since F is independent of Y ,
and the last one follows by Claim 2.3. For bounding the left-hand term of Equation (4), let S and
T be the ℓ-size set and the index guaranteed by Claim 2.4 for the matrices Mi−1 and vector αYi ,
respectively. Compute,

Pr [Zi ∧Xi ∈ E(M) | Zi−1] ≤ Pr [Yi ∈ F (E(M)) | Zi−1] (6)
≤ Pr [Yi ∈ F (S ∪ {T}) | Zi−1]

≤ Pr [Yi ∈ F (S) | Zi−1] + Pr [Yi = F (T ) | Zi−1] .

The second inequality is by Claim 2.4. Since F (S) is independent of Yi, it holds that

Pr [Yi ∈ F (S) | Zi−1] ≤ |S| /n = ℓ/n (7)

Bounding Pr [Yi = F (T ) | Zi−1] is more involved since T might depend on Yi.3 Yet since f is a
random function, a simple counting argument yields that for any (fixed and independent of f)
function g:

Pr
f←F

[
Pr

y←[n]
[y = f(g(y))] ≥ 1/2

]
≤ n−n/3 (8)

3Indeed, this dependency between the queries to f and the value to invert is exactly what makes (efficient) inversion
by adaptive inverters possible.

9



Let H := (X<i, Y<i), and for h = (x<i, y<i) ∈ Supp(H) compute

Pr
f←F |Zi−1,H=h

[Pr [Yi = f(T ) | H = h] ≥ 1/2] (9)

≤ 1

Pr [H = h,Zi−1 | Y<i = y<i]
¡ Pr
f←F |Y<i=y<i

[Pr [Yi = F (T ) | H = h] ≥ 1/2]

=
1

Pr [H = h,Zi−1 | Y<i = y<i]
¡ Pr
f←F

[Pr [Yi = F (T ) | H = h] ≥ 1/2]

≤ 1

Pr [H = h,Zi−1 | Y<i = y<i]
· n−n/3

≤ nn/4 · n−n/3 ∈ o(1).

The first equality holds since F is independent of Y . The second inequality holds by Equa-
tion (8), noting that under the conditioning on H = h, the value of T is a deterministic function of
Yi. The third inequality holds since for not too big i, Pr [H = h,Zi−1 | Y<i = y<i] ≥ n−n/4, since
this probabilistic event is essentially a system of linear equations over a randomly selected vector.
Since the above holds for any h, we conclude that Pr [Yi = F (T ) | Zi−1] ≤ 1/2 + o(1). Putting it
all together, yields that Pr [Zi | Zi−1] < 1/n+ ℓ/n+ 1/2 + o(1) < 3/5, for not too large i.

2.2.1 Affine Decision Trees

Similarly to the affine decoder case, we prove the theorem by bounding Pr [Zi | Zi−1] for all
“not too large i”. Also in this case, we bound this probability by translating the conditioning on
Zi−1 into a system of affine equations. In particular, we would like to find proper definitions for

the matrix M =

(
Mi−1

Mi

)
and vector V =

(
V i−1

V i

)
, functions of (X≤i, Y≤i), such that conditions

1–3 mentioned in the affine decoder case hold.
We achieve these conditions by adding for each j < i an equation for each of the linear compu-

tations done in the decision tree that computes Xj from Yj . The price is that rather than having
Θ(i) equations, we now have Θ(d ¡ i), for d being the depth of the decision";"""pdf:unmappedUnicodeCharsPerPage"",""1"",""0"",""0"",""0"",""0"",""1"",""0"",""0"",""0"",""0"",""0"",""0"",""4"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""12"",""0"",""0"",""0"",""4"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.5""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dcterms:created"",""2020-10-16T17:27:43Z""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""Content-Length"",""263145""
""pdf:hasMarkedContent"",""false""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""meta:creation-date"",""2020-10-16T17:27:43Z""
""created"",""2020-10-16T17:27:43Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""31""
""Creation-Date"",""2020-10-16T17:27:43Z""
""resourceName"",""TimeMemTO.pdf""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""2527"",""746"",""3066"",""2175"",""2698"",""2295"",""2332"",""2375"",""2151"",""2212"",""1684"",""2121"",""2218"",""2065"",""1267"",""949"",""2223"",""1962"",""1824"",""2505"",""2210"",""1455"",""1292"",""1368"",""1594"",""1537"",""2144"",""1649"",""1654"",""2314"",""905""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""producer"",""XeTeX 0.99998""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""XeTeX 0.99998""
""pdf:docinfo:created"",""2020-10-16T17:27:43Z""
";https://scholar.google.ch/scholar?start=900&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098884-380;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;KVaC: Key-Value Commitments for Blockchains and Beyond;S Agrawal, S Raghuraman ; International Conference on the Theory and …, 2020  Springer;;"… and VCs have applications to verifiable databases with updates, interactive oracle proofs, etc …

Todd [27] first proposed the idea of a “stateless” blockchain where nodes participate in … commitment

scheme \(\mathsf {KVaC}\), one can build an account-based cryptocurrency where a …";Cité 1 fois;Les 2 versions;[PDF] iacr.org;https://eprint.iacr.org/2020/1161.pdf;"
KVaC: Key-Value Commitments for Blockchains and Beyond

Shashank Agrawal∗ Srinivasan Raghuraman†

October 5, 2020

Abstract

As blockchains grow in size, validating new transactions becomes more and more
resource intensive. To deal with this, there is a need to discover compact encodings
of the (effective) state of a blockchain — an encoding that allows for efficient proofs of
membership and updates. In the case of account-based cryptocurrencies, the state can be
represented by a key-value map, where keys are the account addresses and values consist
of account balance, nonce, etc.

We propose a new commitment scheme for key-value maps whose size does not grow
with the number of keys, yet proofs of membership are of constant-size. In fact, both
the encoding and the proofs consist of just two and three group elements respectively
(in groups of unknown order like class groups). Verifying and updating proofs involves
just a few group exponentiations. Additive updates to key values enjoy the same level of
efficiency too.

Key-value commitments can be used to build dynamic accumulators and vector com-
mitments, which find applications in group signatures, anonymous credentials, verifiable
databases, interactive oracle proofs, etc. Using our new key-value commitment, we pro-
vide the most efficient constructions of (sub)vector commitments to date.

∗Western Digital Research, shashank.agraval@gmail.com.
†Visa Research, srirag@mit.edu.



1 Introduction

Cryptocurrency space has grown quite rapidly since the introduction of Bitcoin [bit] about a
decade ago. The state of several leading cryptocurrencies like Ethereum [ethb], Ripple [Rip],
EOS [EOS] and Stellar [Maz15] can be represented by a key-value map M where keys are
the public addresses of users and values are the attributes associated with them (balance
amount, nonce, etc.). When Alice generates a transaction tx to transfer an amount x from
her public key pk to Bob, the map M is used to check if pk has a balance of at least x. On
confirmation of tx, balance of Alice and Bob (along with other bookkeeping information) is
updated in M.

In a cryptocurrency network, every node is expected to verify and store the state of the
system. As the number of users increase and new accounts are created, the size of the key-
value map grows, and the resource cost of running a node increases. This drives a large
proportion of users to rely on third parties to inform them of the state of the system, severely
limiting the amount of decentralization in the network [PT, Dry19, CPZ18]. To provide some
context, Ethereum has over 70 million accounts now [etha] even though its not very widely
used (5-10 transactions per second [ethc]). Upcoming currencies like Libra [lib] can have a
much higher throughput and are expected to have billions of accounts.

Key-value commitments. In this paper, we initiate a formal study of key-value commit-
ments (KVC). These commitments allow one to produce succinct encodings of key-value maps
that are amenable to both efficient membership proofs and additive updates.1 We propose a
new KVC KVaC (pronounced ‘quack’) in groups of unknown order, such as an RSA group or
a class group [BH01], with the following properties:

• Succinct encoding. Commitment value consists of just two group elements irrespective of
the number of items (key-value pairs) committed. If class groups of quadratic imaginary
order targeting 100-bit security are used, then the commitment size would be 4096 bits
or about half a kilobyte [HM00].

• Succinct proofs & fast verification. A proof to show that a certain item is in the
commitment consists of just three group elements and only five exponentiations are
required to verify a proof.

• Fast updates. Inserting new items to the map, updating values of existing items (ad-
ditive updates), and updating membership proofs when items are added/changed can
all be done quite efficiently — at most four exponentiations are required in any case.
Furthermore, to update the value of an item, its existing value is not needed.

• Trustless set-up. If class groups are used as the underlying group here, then the encoding
scheme could be bootstrapped in a trustless manner.

• Aggregation & batching. Multiple proofs can be aggregated to the size of a single proof
and verified in the same amount of time as a single proof.

We prove the security of our construction under the RSA assumption in the random oracle
model or the strong RSA assumption in the standard model.

1We do not intend key-value commitments to provide any sort of hiding for the keys or values committed,
similar to how vector commitments do not intend to hide the vector elements [CF13].

2



Vector commitments & accumulators. KVCs can be used to construct and improve upon well-
studied cryptographic primitives like accumulators [Bd94, CL02, Ngu05, CHKO08, BCD+17]
and more recent ones like (sub)vector commitments (VC) [CF13, KSS+16, LRY16, CPZ18,
BBF19, LM19]. Accumulators are used in group signatures, anonymous credentials, compu-
tation on authenticated data, decentralized bulletin boards, etc., and VCs have applications
to verifiable databases with updates, interactive oracle proofs, etc.

VCs have been used to build accumulators [CF13] and vice versa [BBF19]. We show
how to build both of them from KVCs. In particular, we provide the first VC scheme where
both public parameters and proofs consist of a constant number of group elements, the public
parameters do not restrict the number of elements that could be committed to, and all the VC
algorithms require a constant number of group operations. Furthermore, the proofs can be
batched to produce constant-size subvector openings. We also show how to build a dynamic
accumulator from an (insert-only) KVC whose efficiency matches with the state-of-the-art.
Thus, KVCs can be seen as a more general and flexible primitive.

We discuss our work in connection to VCs and accumulators in more depth in the following
section.

1.1 Applications

Stateless validation of cryptocurrencies. Todd [PT] first proposed the idea of a “state-
less” blockchain where nodes participate in transaction validation without storing the entire
state of the ledger, but rather only a short commitment to the state. Using our new key-
value commitment scheme KVaC, one can build an account-based cryptocurrency where a
node needs to store only two group elements (the commitment) to validate transactions. In
the new currency, an account is represented by a key-value pair where key is a public key for
a signature scheme (or a hash of it) and value consists of the account balance and a counter.
(The counter helps to prevent replay attacks.) Suppose Alice has an account represented by
(pk, (v||ct)) and she wants to transfer an amount b to a public key pk?. She will generate a
transaction tx = (pk, σ, v, ct, b, pk?, π) where σ is a signature on (v, ct, b, pk?, π) under pk and
π is a proof of the membership of (pk, (v||ct)) in the commitment.

A validator node, holding a commitment C, checks if σ is a valid signature, π is a valid
proof w.r.t. C, and b is at most v. If all the checks pass, it updates the commitment using
the efficient update algorithm Update of KVaC. The validator first executes Update with
(pk,−b||1) and C to produce a new commitment C ′ that reflects the change to Alice’s account,
and then executes Update with (pk?, b||0) and C ′ to produce the final commitment C ′′ that
reflects the changes to both the accounts. Here, KVaC’s ability to update the value associated
with pk? without the knowledge of the original is very useful, otherwise senders would have
to keep track of receivers’ balances too.

Every time the commitment value changes, users need to update their proofs so that they
remain valid. This puts some additional burden on users as they have to sync up with the
blockchain frequently, which brings up a natural question: can the information required to
update proofs be sublinear in the number of updates made? Unfortunately, this does not
seem to be the case because the new and old values of commitment can be used to find out
what updates have been made. Specifically, the lower bound of Camacho and Hevia can be
extended to our setting as well [CH10].

Use of KVCs in blockchain also adds some extra overhead of generating and transmitting
proofs, but they can be batched together and only one proof needs to be stored with a block.

3



Vector commitments. Vector commitments (VC) [LY10, CF13] allow one to commit to
an ordered sequence of values in such a way that one can later open the commitment at
specific positions. Catalano and Fiore [CF13] also consider updates to individual values and
corresponding updates to proofs. The constructions of Catalano and Fiore, and those of
Chepurnoy et al. [CPZ18] proposed later, have public parameters that scale linearly with the
size of the vector. Though they suggest a way to cut down the parameters to a constant, it
makes the cost of VC algorithms linear in the size of the vector.

Boneh et al. [BBF19] take a different approach to build VCs. They provide a trans-
formation from their accumulator construction which supports both membership and non-
membership proofs. Though their construction does not put any restriction on the length of
the vector, the vector elements are accumulated bit by bit. So the number of group operations
required to insert new elements, generate membership proofs, etc. is linear in the bit-size of
vector elements. Updates to values are not explicitly discussed but one could infer that it
would have a similar cost. Lastly, their proofs contain seven group elements.

KVCs can be used to build a VC in a straightforward way, with keys playing the role of
indices. Our KVC leads to a VC where the public parameters are of constant size, there is
no restriction on the number of elements that could be committed, and proofs consist of just
three group elements. Further, all the VC algorithms require a constant number of group
operations. This improves upon all the known constructions.

Subvector commitments. Lai and Malavolta [LM19] recently proposed the notion of
subvector commitments (SVC). An SVC allows one to open a committed vector at a set of
positions, where the opening size is independent of length of the committed vector and the
number of positions to be opened. They show that the proofs (or openings) of Catalano and
Fiore [CF13] can be extended for multiple elements without losing the succinctness. However,
this also means that they inherit the limitations of Catalano and Fiore’s constructions.

Membership proofs of our KVC can be batched, resulting in an SVC with succinct sub-
vector openings — but without linear growth in public parameters.

Accumulators. Accumulators are a very well-studied cryptographic primitive with nu-
merous applications. They can be based on RSA groups [Bd94, CL02], Merkle hash trees
[CHKO08], or bilinear maps [Ngu05]. See Baldimtsi et al. [BCD+17] for a thorough discus-
sion of different types of accumulators and modular conversions between them. We show
how to build a dynamic positive accumulator from an (insert-only) KVC whose efficiency
matches with the state-of-the-art. (All accumulator algorithms need a constant number of
group operations.) A dynamic accumulator supports both additions and deletions, and a
positive one supports membership proofs.

1.2 More on Related Work

Comparison with Boneh et al. While Boneh et al.’s VC construction [BBF19] is novel
and efficient, their technique inherently works bit-by-bit. (They also discuss how to build
KVCs from VCs.) The exponent is always a subset product of elements corresponding to the
bits set to 1. It is not clear how to get rid of this restriction. This limitation also translates to
updates as one would have to know which bits would have to be flipped from 0 to 1 and 1 to
0. This cannot be done simply using the knowledge of update value. Our construction takes
a completely different approach by encoding the values directly as a linear function, which
allows us to get past the bit-by-bit issues as well as handle updates while being oblivious

4



to prior value (very important for blockchain applications). Our KVC algorithms involve
constant number of group operations as opposed to linear in bit-length; the constants are
small (between three and five); and, our proof size is three as opposed to seven.

Recent work. Lately, vector commitments has been a very active area of research. Several
new constructions have been proposed. We discuss a few of them here.

Campanelli et al. [CFG+20] study aggregation for subvector commitments. They in-
troduce new incremental aggregation and disaggregation properties for SVCs. Incremental
aggregation allows one to merge different subvector openings into a single concise opening,
and to further aggregate merged openings (without knowing the entire committed vector).
Disaggregation allows one to ‘break down’ openings into openings of subvectors. Campanelli
et al. point out that though a form of aggregation is already present in the VC of Boneh et
al. [BBF19], it can be performed only once. They construct new VC schemes where openings
can be aggregated an unbounded number of times.

Campanelli et al. provide two constructions with constant-size public parameters, a CRS
in their case. However, the CRS needs to be ‘specialized’ for a length n before it can be used
for commitment. The first construction, based on Boneh et al. [BBF19], has a dependence
on the bit-length of elements. Verification in the second construction, based on Catalano and
Fiore [CF13], requires generation of n primes (unless they are already stored). Furthermore,
Campanelli et al. do not consider updates to vector elements. Our KVC construction, on
the other hand, can be used to build a VC that does not restrict the number of elements
in a commitment and allows them to be updated. However, like Boneh et al., we can only
support one-hop aggregation (we do not know how to further aggregate aggregated proofs).

Pointproofs [GRWZ20] study aggregatable VCs in the cross-commitment setting. Proofs
for subvectors of multiple commitments can be aggregated by any third party into a single
proof for the multiple subvectors. When applied to smart contracts storage, Pointproofs
reduces validators’ storage requirements considerably. While Pointproofs have very short
proofs, the public parameters are linear in the length of the vector. The scheme relies on
a q-type assumption in a bilinear group. Further, in order to prove security of aggregation,
they need to work in the algebraic group model.

Tomescu et al. [TAB+20] also study aggregatable subvector commitment and give an
efficient construction in prime-order groups from constant-sized polynomial commitments.
(They also provide a detailed and extensive overview of the literature.) Their public param-
eters also depend on the length of the vector though. They discuss how to build a stateless
cryptocurrency from their VC but the number of users n that need to be supported must be
known in advance.

1.3 Organization

We first provide a technical overview of our construction (Section 2). We discuss two inter-
mediate steps to building a KVC: an insert-only KVC that allows insertion of new items but
no updates to existing ones, and an increment-only KVC that allows incrementing the values
corresponding to keys but no inserts (it is assumed that all keys are initialized with value 0).

In Section 3, we describe the notation used in the paper, define key-value commitments
formally, and state the assumptions we need to prove security. In Sections 4 and 5, we build
an insert-only KVC and a full KVC, respectively. We show how the former can be used to
build accumulators and the latter naturally lends itself to vector commitments. Finally, in
Section 6, we show how to batch membership proofs together.

5



We provide a formal description of the increment-only KVC in Appendix B.

2 Overview

In this section, we provide a technical overview of our construction of key-value commitments.
Informally, a key-value commitment allows one to commit to a key-value map in such a way
that it is later possible to open the commitment with respect to any specific key. To motivate
our construction, we build up to it in three steps.

2.1 Insert-only

We begin by describing an insert-only key-value commitment construction. By insert-only,
we mean that we only insert key-value pairs into the commitment and do not the update
the value corresponding to a key. Our key-value commitment C to the key-value map M =
{(ki, vi)}i∈[q] ⊆ K × V takes the form

CM =
(
g
∑

i∈[q] vi
∏

j∈[q]\{i} zj , g
∏

i∈[q] zi
)
,

where zi are random strings2 corresponding to the keys ki. The crucial observation here is
that the exponent in the first element of the commitment, namely g

∑
i∈[q] vi

∏
j∈[q]\{i} zj , is a

linear function of the values vi. The proof corresponding to a key km ∈ KM would be

Λkm =
(
g
∑

i∈[q]\{m} vi
∏

j∈[q]\{i,m} zj , g
∏

i∈[q]\{m} zi
)

which is essentially the key-value commitment of all the other key-value pairs in M. Let
us assume that the strings zi can be publicly generated from the keys ki, say by some hash
function3. Then, the verification of the proof Λkm for a key-value pair (km, vm) would simply
be the following checks:

Λzmkm,1 · Λ
vm
km,2

=
(
g
∑

i∈[q]\{m} vi
∏

j∈[q]\{i,m} zj
)zm
¡
(
g
∏

i∈[q]\{m} zi
)vm

= g
∑

i∈[q]\{m} vi
∏

j∈[q]\{i} zj ¡ gvm
∏

i∈[q]\{m} zi

= g
∑

i∈[q] vi
∏

j∈[q]\{i} zj

= CM,1

and

Λzmkm,2 =
(
g
∏

i∈[q]\{m} zi
)zm

= g
∏

i∈[q] zi

= CM,2

Note that the above design also describes a procedure to insert a key-value pair into the
commitment. To insert a new pair (kq+1, vq+1) into M, we set

CM′ =
(
C
zq+1

M,1 ¡ C
vq+1

M,2 , C
zq+1

M,2

)
2The precise requirement on {zi} will be described later.
3We will actually not require any private randomness in {zi}, just that there is some concise representation

of them. This will be clear from the fact that we publish the key for the hash function to enable its public
evaluation.

6



where M′ = M∪ {(km+1, vm+1)}. Furthermore, the proof Λkq+1 corresponding to the key
kq+1 would be CM.

We also have a straightforward way to update proofs for the existing keys when a new
key-value pair is inserted. For instance, on inserting (kq+1, vq+1), we can update the proof
Λkm corresponding to the key km with the help of the update information (kq+1, vq+1) as
follows:

Λ′km =
(

Λ
zq+1

km,1
· Λvq+1

km,2
,Λ

zq+1

km,2

)
.

One can easily check that the modified proof would be successfully verified.
The final piece of the puzzle is key binding, i.e., it must be computationally infeasible for

an adversary to produce a proof corresponding to a key k that verifies for a key-value pair
(k, v) which is not in the key-value commitment. We analyze this as follows. Suppose an
adversary comes up with a key-value pair (k, v) and a proof Λk = (Λk,1,Λk,2) corresponding
to the key k. Let us assume that k ∈ KM (the other case is easier to handle). Let m denote
the index of the key k in the mapM, i.e., let k = km. Let zm be the string corresponding to
km. We will, for reasons that will be clear shortly, require that zm be an odd string. Let vm
be the value corresponding to the key km in the commitment and let Λkm = (Λkm,1,Λkm,2)
be the corresponding proof. We first check that

Λzmk,2 = CM,2.

Suppose that the check passes. Then, with overwhelming probability,

Λk,2 = g
∏

i∈[q]\{m} zi = Λkm,2.

This is because, otherwise,

Îą =
Λk,2

Λkm,2
6= Âą1

is a non-trivial zmth root of unity. We know that such elements are hard to find without
knowing the order of the group. In particular, this means that we have computed the order
of the non-trivial element Îą.

We now proceed to the second and final check. We check that

Λzmk,1 · Λ
v
k,2 = CM,1.

Note that
Λzmkm,1 · Λ

vm
km,2

= CM,1.

and, with overwhelming probability, Λk,2 = Λkm,2. Hence(
Λk,1

Λkm,1

)zm
= Λvm−vkm,2

.

We only care about the case vm 6= v. Note that setting

β =
Λk,1

Λkm,1

and
γ = Λvm−vkm,2

7



we have found β, a zmth root of a non-trivial element γ, which should be hard to find in
groups of unknown order.

Formally, we can show that if the RSA assumption holds, then computing β is indeed
hard. This can be seen as follows. The exponent of g in Λkm,2 contains numbers that are
coprime to zm. Furthermore, we will choose {zi} to be larger than the permitted value space,
which ensures that vm − v is also coprime to zm. Thus, if one can compute β, which is a
zmth root of γ, we can actually compute a zmth root of g through an application of Shamir’s
trick, which would break the RSA assumption.

2.2 Increment-only

We next describe an increment-only key-value commitment construction. By increment-only,
we mean that values corresponding to all keys are initialized to 0 and we can just update
them by some amount δ every time. We propose that our commitment C to a key-value map
M = {(ki, vi)}i∈[q] ⊆ K × V takes the form

CM = g
∏

i∈[q] z
vi
i ,

where zi are random primes corresponding to the keys ki. Let us assume that the strings zi
can be publicly generated from the keys ki, say by some hash function.

This construction is reminiscent of the RSA-based accumulator construction of Li et al.
[LLX07] and Boneh et al. [BBF19]. The proof corresponding to a key km ∈ KM would need
to consist of two parts, one to show that the exponent of zm is at least vm and one to show
that it is at most vm. The first part of the proof would be

Λkm,1 = g
∏

i∈[q]\{m} z
vi
i ,

which is essentially the key-value commitment of all the other key-value pairs in M. It can
be used to show that the exponent of zm is at least vm by verifying that

Λz
vm
m
km,1

= CM.

The second part of the proof uses the idea from Li et al. [LLX07] and Boneh et al.
[BBF19] that was used to build non-membership proofs. Basically, we would like to show
that zm is coprime to

∏
i∈[q]\{m} z

vi
i . This can be done by leveraging Bezout coefficients

a, b ∈ Z such that

a ¡ zm + b ¡
∏

i∈[q]\{m}

zvii = 1.

2.3 Putting it all together

We re-examine the insert-only key-value commitment, namely,

CM =
(
g
∑

i∈[q] vi
∏

j∈[q]\{i} zj , g
∏

i∈[q] zi
)

and
Λkm =

(
g
∑

i∈[q]\{m} vi
∏

j∈[q]\{i,m} zj , g
∏

i∈[q]\{m} zi
)
.

The exponent of the first component of CM is linear in the values that are being committed.
Thus, in order to change the value corresponding to key km by δ, it is enough to perform the
following operation:

CM′,1 = CM,1 · gδ·
∏

i∈[q]\{m} zi .

8



This means that one only needs to know the index m4 and δ in order to perform an update
on the value corresponding to the key km in the commitment. Let

β = g
∏

i∈[q]\{m} zi .

Firstly, note that β can be generated publicly. However, one would have to generate all
the zi for i ∈ [q] \ {m} (or retrieve it from some persistent storage) and then perform q − 1
exponentiations, making it a computationally intensive task. However, notice that

Λkm,2 = β.

Thus, if we assume that the party involved in the update of the mth element has access to
Λkm , we can assume that we have access to β and we do not have to recompute it every time
an update is issued. However, we would like to overcome this limitation. For instance, in the
case of a blockchain, a sender who wants to send another user some funds will not be able to
update the key-value commitment to reflect the changes in the recipient’s account efficiently
unless they have access to the proof of the recipient.

Let us turn to the proofs. Note that if we perform an update at index m, the proof corre-
sponding to the key km does not change. For n 6= m, we can update the proof corresponding
to the key kn by performing the following operation:

Λkn,1 = Λkn,1 · g
δ¡
∏

j∈[q]\{m,n} zj .

Let
Îł = g

∏
j∈[q]\{m,n} zj .

Again, note that Îł can be generated publicly but it would be a computationally intensive
task. The situation is even worse here because Îł cannot be computed efficiently from any
other information that is available as that would amount to taking zmth roots of elements.

The construction we propose now circumvents all of these issues. It gets rid of indices and
allows for efficient updates of the key-value commitment and proofs. Moreover, we can do so
without involving the party (their proof) whose value is being modified. Our commitment C
to the key-value map M = {(ki, vi)}i∈[q] ⊆ K × V takes the form

CM =

(
g(

∑
i∈[q] vi

∏
j∈[q]\{i} zj)¡

∏
i∈[q] z

ui
i , g

∏
i∈[q] z

ui+1
i

)
,

where ui denotes the number of updates made to the value corresponding to the key ki.
With this form, insertion can be carried out in exactly the same way as in the case of the
insert-only construction.

More interestingly, if CM′ denotes the new commitment value after changing the value
corresponding to key km by δ, then

CM′,1 = CzmM,1 · g
δ¡zu

′
m

m
∏

i∈[q]\{m} z
ui+1
i

= CzmM,1 ¡ g
δ¡zum+1

m
∏

i∈[q]\{m} z
ui+1
i

= CzmM,1 ¡ g
δ¡
∏

i∈[q] z
ui+1
i

= CzmM,1 ¡ C
δ
M,2,

4While this is already pretty good, we ideally would like to get rid of the notion of an index and carry out
an update just knowing the key km. We do achieve this in our construction.

9



where u′m = um + 1 denotes the (new) total number of updates for key km. Note how using
the number of updates {ui} in the exponents of the {zi} lets us perform an update without
having to compute values akin to β (and γ while updating proofs) which have to miss some
{zi} in the exponent, rendering their computation inefficient.

In fact, it is now easy to see that

CM′ =
(
CzmM,1 ¡ C

δ
M,2, C

zm
M,2

)
.

Thus, an update works exactly how an insert would and this is an important property our
constructions enjoys that we will come back to later in seeing how this primitive fits into
the blockchain setting. It can also be easily deduced now that this design has a very similar
consequence on enabling update to proofs efficiently. In particular, recall that updating the
values corresponding to keys and inserting a new key have similar effect. Since we know how
to update proofs following an insert, we can update them in exactly the same way on an
update to some value.

To prove key-binding, it will be crucial for a verifier to know precisely the number of
updates that have been performed on the value corresponding to the key for which a proof is
provided. If verifier is not aware of this, it is possible for an attacker to generate a “fake” proof
and break key-binding. Indeed, the number of updates made to the values corresponding to
each key is public in the blockchain setting, but we would not want parties to store this
information as it grows linearly with the number of key-value pairs that are inserted into the
commitment.

For this purpose, we can include in the commitment CM an increment-only key-value
commitment that stores the number of updates performed on each key. During verification,
proofs would now have to contain a proof for the right number of updates that have been
performed in addition to the proof for the value itself. In this way, the verifying party need not
store the number of updates that have been made to the values corresponding to each of the
keys. The final step is to observe that the second component of the key-value commitment,
CM,2, essentially acts as an increment-only key-value commitment for the number of updates.
Thus, we do not need to add anything else to CM.

3 Preliminaries

3.1 Notation

For n ∈ N, let [n] = {1, 2, . . . , n}. Let Ν ∈ N denote the security parameter. Let |b| denote
the bit-length of b ∈ N. Let Primes denote the set of integer primes and Primes(Ν) denote
the set of integer primes less than 2Îť. Symbols in boldface such as a denote vectors. By ai
we denote the i-th element of the vector a. For a vector a of length n ∈ N and an index
set I ⊆ [n], we denote by a|I the sub-vector of elements ai for i ∈ I induced by I. By
poly(¡), we denote any function which is bounded by a polynomial in its argument. An
algorithm T is said to be PPT if it is modeled as a probabilistic Turing machine that runs in
time polynomial in Îť. Informally, we say that a function is negligible, denoted by negl, if it
vanishes faster than the inverse of any polynomial. If S is a set, then x ←$ S indicates the
process of selecting x uniformly at random from S (which in particular assumes that S can
be sampled efficiently). Similarly, x←$ A(·) denotes the random variable that is the output
of a randomized algorithm A.

10



3.2 Key-Value Commitments

Informally, a key-value commitment allows one to commit to a key-value map in such a way
that it is later possible to open the commitment with respect to any specific key. We require
a key-value commitment to be concise in the sense that the size of the commitment string C
is independent of the size of the map. Furthermore, it must be possible to update the map,
by either adding new key-value pairs or updating the value corresponding to an existing key.

We set up the following notation for a key-value map: A key-value map M ⊆ K × V
is a collection of key-value pairs (k, v) ∈ K × V. Let KM ⊆ K denote the set of keys for
which values have been stored in the map M. We define a key-value commitment KVC as a
non-interactive primitive that can be formally described via the following algorithms:

• (pp, C) ←$ KeyGen(1λ): On input the security parameter λ, the key generation algo-
rithm outputs some public parameters pp (which implicitly define the key space K and
value space V) and the initial commitment C to the empty key-value map. All other
algorithms have access to the public parameters.

• (C,Λk, upd)← Insert(C, (k, v)): On input a commitment string C and a key-value pair
(k, v) ∈ K × V, the insertion algorithm outputs a new commitment string C, a proof
Λk (that v is the value corresponding to k), and update information upd.

• (C, upd) ← Update(C, (k, δ)): On input a commitment string C, a key k ∈ K and
an update value δ5, the update algorithm outputs an updated string C and update
information upd. Note that this algorithm does not need the value corresponding to
the key k.

• Λk ← ProofUpdate(k,Λk, upd): On input a key k ∈ K, a proof Λk for some value
corresponding to the key k and update information upd, the proof update algorithm
outputs an updated proof Λk.

• 1/0 ← Ver(C, (k, v),Λk): On input a commitment string C, a key-value pair (k, v) ∈
K× V and a proof Λk, the verification algorithm either outputs 1 (denoting accept) or
0 (denoting reject).

For correctness, we require that for all Ν ∈ N, for all honestly generated public parameters
pp ←$ KeyGen(1λ), if C is a commitment to a key-value map M, obtained by running a
sequence of calls to Insert and Update, Λk is a proof corresponding to key k for any k ∈ KM,
generated during the call to Insert and updated by appropriate calls to ProofUpdate, then
Ver(C, (k, v),Λk) outputs 1 with probability 1 if (k, v) ∈M.

To present the requirement formally, we define a correctness game. We have an adversary
in this game to capture the arbitrary order in which inserts and updates can be applied to a
commitment. We do not provide it any capability to do something beyond that.

5We assume updates are additive, i.e., updating a value v by δ amounts to changing v to v + δ.

11



Definition 1. For a key-value commitment KVC and an adversary A, we define a random
variable Gcorrect

KVC,Îť,A through a game between a challenger CH and A as follows:

Gcorrect
KVC,Îť,A :

1. CH samples (pp, C) ←$ KeyGen(1λ) and sends them to A. CH also maintains its own
state comprising a key-value map M⊆ K×V initialized to the empty map, a key-proof
map P initialized to the empty map, and the initial commitment value C.

2. A issues queries of one of the following forms:

• (Insert, (k, v)): CH checks if M contains a tuple of the form (k, ·). If so, CH re-
sponds with ⊥. If not, CH updatesM toM∪{(k, v)} and executes Insert(C, (k, v))
to obtain a new commitment C, along with Λk and upd. CH then updates P to
P ∪ {(k,Λk)}.
• (Update, (k, δ)): CH checks if M contains a tuple of the form (k, v). If not, CH

responds with ⊥. If so, CH updatesM to (M∪{(k, v+δ)})\{(k, v)} and executes
Update(C, (k, δ)) to obtain a new commitment ";"""date"",""2020-10-05T21:57:58Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2020-10-05T21:57:58Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017) kpathsea version 6.2.3""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2020-10-05T21:57:58Z""
""created"",""2020-10-05T21:57:58Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-10-05T21:57:58Z""
""resourceName"",""1161.pdf""
""Author"",""""
""producer"",""pdfTeX-1.40.18""
""pdf:docinfo:producer"",""pdfTeX-1.40.18""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""9"",""0"",""0"",""31"",""9"",""16"",""16"",""4"",""0"",""2"",""8"",""21"",""16"",""9"",""27"",""45"",""28"",""26"",""7"",""14"",""27"",""60"",""29"",""26"",""14"",""77"",""0"",""0"",""3"",""6"",""8"",""37"",""47"",""25""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2020-10-05T21:57:58Z""
""Last-Modified"",""2020-10-05T21:57:58Z""
""dcterms:modified"",""2020-10-05T21:57:58Z""
""title"",""""
""Last-Save-Date"",""2020-10-05T21:57:58Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2020-10-05T21:57:58Z""
""meta:save-date"",""2020-10-05T21:57:58Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017) kpathsea version 6.2.3""
""Content-Length"",""454583""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""36""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""1222"",""2680"",""3092"",""3101"",""3147"",""1727"",""1575"",""1937"",""2091"",""2662"",""2260"",""1882"",""2111"",""2503"",""2331"",""1608"",""1475"",""822"",""1509"",""687"",""2101"",""1273"",""1345"",""980"",""1493"",""1107"",""2475"",""1279"",""2235"",""2124"",""2386"",""2391"",""1035"",""1945"",""1102"",""1212""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-10-05T21:57:58Z""
";https://scholar.google.ch/scholar?start=920&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098835-263;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Multi-Replica and Multi-Cloud Data Public Audit Scheme Based on Blockchain;X Yang, X Pei, M Wang, T Li, C Wang ; IEEE Access, 2020  ieeexplore.ieee.org;;"… We prove the security of the scheme based on the CDH and DL assumptions under the random

oracle model … E. BLOCKCHAIN Blockchain is famous for its outstanding performance in various

cryptocurrency systems (such as bitcoin [48] and Ethereum [49]) …";Cité 2 fois;;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/6287639/8948470/09159563.pdf;"
		
	";"""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""dc:title"",""IEEE Xplore Full-Text PDF:""
""Content-Encoding"",""UTF-8""
""resourceName"",""09159563.pdf""
""language"",""es""
""Content-Length"",""2565""
""title"",""IEEE Xplore Full-Text PDF:""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.ch/scholar?start=810&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098844-288;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;[PDF][PDF] Self-executing Contracts from the perspective of the selected Polish regulations and the future potential prevalence of 'Smarter'Contracts;R Prabucki ; The Journal of The British Blockchain …, 2020  jbba.scholasticahq.com;;"… G. Wood, co-founder of Ethereum, called this: “a general implementation of such a crypto-law

system” [6, 7, 8, 9, 10, 11]. 3. DLT and smarter contracts … Collecting important information from

outside the blockchain is possible due to connectors called “Oracles” [15] …";Autres articles;Version HTML;[PDF] scholasticahq.com;https://jbba.scholasticahq.com/article/12720.pdf;"
  
  

The	
  JBBA	
  	
  |	
  	
  Volume	
  3	
  |	
  	
  Issue	
  2	
  	
  |	
  	
  2020	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  Published	
  Open	
  Access	
  under	
  the	
  CC-­‐‑BY	
  4.0	
  Licence	
  
	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
   	
  

1	
  

  

 PEER Reviewed RESEARCH 
 

 OPEN ACCESS 
                                                                                                                            ISSN Online: 2516-3957 

                                                                                                                       ISSN Print: 2516-3949 
https://doi.org/10.31585//jbba-3-2-(3)2020 

Self-executing Contracts from the perspective  
of the selected Polish regulations and the future  
potential prevalence of ‘Smarter’ Contracts  
Rafał Tomasz Prabucki 
Centre for Legal Problems of Technical Issues and New Technologies, University of Opole, Poland  
 
Correspondence:  rprabucki@uni.opole.pl 
Received: 24 February 2020   Accepted: 15 April 2020   Published: 30 April 2020 
 
Abstract 
For some time now, blockchain technology has been used for many purposes all over the world. The question arises – how do we 
regulate proving facts in a dispute between agreement parties when they use self-executing contracts? The answer to this question is 
explored in this research in the context of civil issues. Furthermore, the Polish law has introduced a new tool in the form of a ‘contract 
of evidence’ (similar to the parol evidence rule) which may increase the popularity of smart contracts. The research methodology is 
based on the analysis of the two existing regulations from the Civil Procedure Code and the Commercial Code. Moreover, legal 
scientific studies that indicate the risks associated with using self-executing contracts in such a way will be analysed. All efforts have 
been taken to obtain conclusions regarding the future of this type of solution in Poland and Polish smart cities. 
 

Keywords: contract of evidence, Polish law, blockchain, smart contracts, evidence law 
 

JEL Classifications: K10, K12, K15, K20, K24, K40 
 

 
 
1.   Introduction and methodology 

For the last few years, smart contracts have become the 
subject of increasing interest of political decision-makers, 
among others, who obviously show strong interest in this 
kind of novelty, but what is more important in this case is 
that, at the same time, they are undertaking the necessary 
measures to introduce legal regulations connected with it. 
The Polish Institute of Justice has commissioned a 
scientific report which, despite the fact that it does not 
directly address the issue of the idea of smart contracts, 
indicates, due to the questions related to blockchain 
technology, that such an element of development of this 
technology exists and is a subject of interest of legislators 
of various countries. The analysis of sources cited for the 
purpose of this report shows that at least four European 
countries have presented concrete proposals for legal 
definitions for this concept. In the United States, in turn, at 
least four states have developed new juridical categories, 
including smart contracts [1].  

Such a keen interest of policy makers in this matter should not 
come as a surprise. Scientific debates, which include the word 
“smart contract”, are not limited only to areas such as 
mathematics, computing and engineering but also covered the 
fields connected with energy and social science discussions. 
The countries that are at the forefront of scientific 
publications on smart contracts are first and foremost the ones 

which have officially developed or are observing and planning 
to develop a possible kind of regulation for the blockchain 
industry. Among these are countries such as the United States, 
China, the Russian Federation, South Korea and the United 
Kingdom. Poland is not listed [2].  

This work aims at catching up on this issue by drawing 
attention to the recent amendment to the Civil Code, which 
introduced a contract of evidence into Polish law. In 
accordance with the recommendations appearing in the 
literature dealing with the issue of smart contracts, the work 
first of all assumes the approximation of the diversity of 
approaches in defining smart contracts. 

2.   Theoretical foundations of smart contracts  
and links to blockchain 

The original source of knowledge about smart contracts are 
works from the 1990s. Thanks to Nick Szabo, his essays and 
scientific papers, the term “smart contract” has penetrated 
the legal world. This is not the only issue that should be 
brought closer to the work of a computer scientist and 
lawyer. Szabo also refers to the so-called “micropayments” in 
his works. Both phrases were supposed to help outline the 
predicted changes in the law of obligations, which were to 
appear and spread due to technological progress. The 
Internet, through its protocols, revolutionised the 



  
  

The	
  JBBA	
  	
  |	
  	
  Volume	
  3	
  |	
  	
  Issue	
  2	
  	
  |	
  	
  2020	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  Published	
  Open	
  Access	
  under	
  the	
  CC-­‐‑BY	
  4.0	
  Licence	
  
	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
   	
  

2	
  

  

transmission of information across the globe. It has become 
possible to draw up a theoretical protocol for the 
declarations of will and knowledge that make up the 
agreement. N. Szabo defines smart contract as “Smart 
contract is a computerised transaction protocol that executes 
the terms of a contract”. Furthermore, he added that “the 
general objectives are to satisfy common contractual 
conditions (such as payment terms, liens, confidentiality, and 
even enforcement), minimize exceptions both malicious and 
accidental, and minimize the need for trusted intermediaries. 
Related economic goals include lowering fraud loss, 
arbitrations and enforcement costs, and other transaction 
costs” [3]. 

The second element, which is very significant, contains 
micropayments. For their application, N. Szabo identified 
specific markets, such as the electricity market, where 
complicated contracts and the need for constant invoicing are 
major problems. In the context of micropayments, however, 
the researcher refers to intelligent agents [4]. Vincenzo 
Morabito notes that there is, in the context of their theoretical 
assumptions, a lot of convergence between smart agents 
derived from the concept of software agents and smart 
contracts and there is even a convertible application of both 
concepts. These coincidences also strongly emphasise the 
modern relationship of smart contracts with Distributed 
Ledger Technology (DLT), which has the potential to facilitate 
business models based on micropayments [5]. It is necessary to 
mention that the dissemination of the idea of smart contracts 
occurred after the launch of bitcoin, the first cryptocurrency. 
Moreover, Vitalik Buterin added an opportunity to his idea of 
cryptocurrency, which is the possibility of creating smart 
contracts in blocks. The language in which it could be created 
was the programming language of Solidity. Blockchain of this 
type was called the “new generation”, due to the 
implementation of the virtual machine. The Ethereum not 
only recorded the information about the trading of 
transactions of Ether (payments token) but also enabled 
creating computer programs which were aimed to automate 
this kind of trading. BT allowed to secure smart contracts 
accordingly. Furthermore, when smart contracts are recorded 
in blocks of chains, they are difficult either to sabotage or to 
edit the conditions they contain. G. Wood, co-founder of 
Ethereum, called this: “a general implementation of such a 
crypto-law system” [6, 7, 8, 9, 10, 11].  

3.   DLT and smarter contracts 

However, smart contracts in the Ethereum blockchain are not 
free from defects and certain restrictions. Working in this 
environment is based on careful selection of programming 
code due to the fee for using a virtual machine with a token 
called “Gas”. In consequence, the price that must be paid for 
purchasing Ethereum tokens can make creating certain smart 
contracts unprofitable. It is not only about the price of the 
Ether token but also about the number of Gas tokens that 
have to be paid to run the program [6]. Moreover, it should be 
emphasised that participation in an open blockchain is allowed 
to anyone. So it may happen that dishonest persons may 

appear or even smart contracts can be created to secure parties 
who have contracted a service which is classified as a criminal 
offence in a given legal system. 

However, smart contracts are also possible to be carried out in 
closed blockchain solutions as well as blockchain-like solutions 
(e.g. Corda), which can be easily entered within the name 
range of DLT. New technological possibilities and solutions 
also increase the range of possible combinations in terms of 
operation. Rory Unsworth proposes to add the term “smarter 
contracts” to the scientific discussion and suggests that this 
term includes split and hybrid smart contract models. The 
author of this classification also emphasises that “smarter” is 
not related to the fact that these solutions are better, as the 
ones described by N. Szabo equally qualify for this name. In 
order to define smarter contracts, it is necessary to call them 
self-executing contracts. The hybrid model adds human factor 
as supervising the operation of the contract in certain 
situations. The split model, on the other hand, serves to 
combine certain expressions of language, which is 
understandable to people but also connects with the activities 
of a smart contract. These concepts expand the business 
application of the individual models and order the chaos in 
theoretical deliberations on the law and the future of self-
executing contracts [12, 13, 14]. 

It is also important to signal that the flywheel of self-executing 
contracts is the incoming data, which triggers subsequent 
elements of the contract after the relevant facts have occurred. 
Collecting important information from outside the blockchain 
is possible due to connectors called “Oracles” [15]. 

It seems that it is the possibility to collect data that puts self-
executing contracts high in the hierarchy of essential elements 
that will shape our world in the era of the Internet of 
Everything (IoE). The future that awaits us will surely also 
bring a question about where the data for self-executing 
contracts are drawn from and whether they can be trusted. 
However, before this happens, it is important to pay attention 
to certain possibilities and issues concerning obstacles of legal 
nature [15]. 

It should not be forgotten that a contract is still – in the 
traditional sense – not only a set of commitments but also a 
scenario designed according to certain regulations with 
mechanisms that are adapted to certain situations [16].  

4.   Contract automation in Polish legal scholarship 

N. Szabo, in his theory, compares smart contracts to vending 
machines. In the Polish school of academic thought, this 
problem was raised by Ernest Till in 1900. According to these 
general demands, vending machines are an offer addressed to 
the general public. Due to the lack of words or letters, the 
whole state of affairs can be considered as the content. The 
conclusion of a contract occurs when both parties correctly 
demonstrate their willingness to join through appropriate 
behaviour. an inserted coin generates the information for the 



  
  

The	
  JBBA	
  	
  |	
  	
  Volume	
  3	
  |	
  	
  Issue	
  2	
  	
  |	
  	
  2020	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  Published	
  Open	
  Access	
  under	
  the	
  CC-­‐‑BY	
  4.0	
  Licence	
  
	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
   	
  

3	
  

  

exhibitor of the vending machine of joining the offer by the 
other party. When it comes to smart contracts, the transfer of 
the relevant token(s) will be considered as silent provision of 
services, which the creator of the smart contract has required. 
This moment will be considered as a contract entry. It is worth 
noticing that the difference between displaying such articles as, 
e.g., newspapers and bread in front of the shop and a vending 
machine was also noticed. In the former case, E. Till 
emphasises that a person coming up with an offer, that is, a 
bidder, gives himself a certain freedom in order to secure his 
right to make decisions on the execution of the contract. As in 
the case of the hybrid model, there still remains some scope for 
human action [17]. 

It probably never occurred to E. Till that similar mechanisms 
would appear on the line of much more complicated 
contracts. That is why Robert Herian calls the vending 
machine theory “elegant”, but he criticises it for the 
probability of a defect occurrence, meaning that it looks well 
until it works without problems [15].   

A contemporary concept of smart contracts in Polish legal 
scholarship is presented by Dariusz Szostek. His approach is 
based on a list of legal definitions from other countries and 
their comparison. The author draws attention to three 
examples from Malta, Belarus and the state of Arizona. As 
the most advanced, mature and adequate to the technical 
reality, D. Szostek indicates the definition which was 
constructed for the needs of Maltese law. According to this 
definition “smart contract” means a form of innovative 
technology arrangement consisting of: (a) a computer 
protocol and/or (b) an agreement concluded entirely or 
partly in an electronic form, which is automatable and 
enforceable by the execution of computer code, although 
some parts may require human input and control and which 
may also be enforceable by ordinary legal methods or by a 
mixture of both [18]. 

In terms of the technical and theoretical elements of smart 
contracts cited above, the legislator’s approach in such a 
direction as to take account of the issues of computer 
protocols and the electronic nature of the contract, together 
with a general outline of some of its features, shows a high 
degree of sophistication and is a sign of maturity. In both 
examples presented by D. Szostek – the one of the state of 
Arizona and another one of Belarus – references to BT and 
DLT terminology dominated. The use of blockchain-related 
concepts complicates the definition unnecessarily, making it 
incomprehensible to a person who does not deal with it on a 
daily basis. Moreover, a strong reference to the medium seems 
to be a significant limitation in the creation of this technology 
in the future [13, 18, 19]. 

The choice of D. Szostek expands the debate about smart 
contracts. The Maltese legal definition has several significant 
advantages: 

• It emphasises the aspect of the legal act and the means of 
electronic communication, not the medium. 

• It leaves space for the split and hybrid models.  

• It proposes an additional scope of the name which does 
not refer to the term of the contract. 

Moreover, the definition of diversity of the use of smart 
contracts is that it creates a technological neutrality, which can 
be adopted and put into long-term use without changes to this 
jury category. The Maltese legislator does not use the 
terminology which is characteristic for DLT; what is more, the 
Maltese legislator proposes two concepts of smart contract, 
one of these is not related to the sphere of obligations. As a 
result, a scenario in which a smart contract can appear in the 
state’s actions is not excluded but is taken into consideration; 
at the same time, a new situation is created in which smart 
contracts can appear in an entirely different sphere, that is, in 
the sphere of public authority. 

In the first place, the smarter contracts and its further 
development will have a significant impact on the civil law 
sphere. It should be noted that two main points are specified 
within the civil law sphere according to the European Union 
(EU) report and these are as follows [20]: 

• Smart legal contracts are smart contracts on a blockchain 
that represent – or that would like to represent – a legal 
contract, along with the issues that are involved. 

• Smart contracts with legal implications are 
artefacts/constructs based on smart technologies that 
clearly have legal implications. 

Therefore, it should not come as a surprise that the emergence 
of self-executing contracts in practice implies not only the 
need to create legal definitions but also changes in other legal 
acts. The problem is not only the legal framework of a certain 
relationship in which a program written in programming code 
may not fit but also the programming language and the way in 
which certain processes work, as these are the factors which 
the court may not understand. Moreover, it should be 
assumed that some changes still appear as new ones in 
numerous works and approach to smart contracts (jellyfish 
theory). It is also important to point out that not only the 
consequences of the regulations being created are important 
but also unplanned changes that are difficult to predict [9, 12, 
13, 15].  

5.   Legislative tendencies and Polish regulations 

The emergence of smart contracts is causing various reactions 
of law-making nature worldwide. Mainly the acts of BT 
regulation are introduced, but the example of the Russian 
Federation shows that changes are constantly made to 
legislative acts. Russia, like other progressive countries, has 
created a legal definition of smart contracts as well. The 
content of this definition in full wording is as follows: “an 
electronic contract, whose rights and obligations are executed 
automatically in a distributed register of digital transactions in 



  
  

The	
  JBBA	
  	
  |	
  	
  Volume	
  3	
  |	
  	
  Issue	
  2	
  	
  |	
  	
  2020	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  Published	
  Open	
  Access	
  under	
  the	
  CC-­‐‑BY	
  4.0	
  Licence	
  
	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
   	
  

4	
  

  

a sequence strictly defined by such a contract and after the 
circumstances have occurred” [1, 21]. 

The introduction of this juridical concept into the Russian legal 
system has resulted in changes to the Civil Code. It not only did 
add many elements such as “Internet”, “electronic” and 
“digital”, but the section on contracts was extended with a new 
paragraph: “A contract may provide for the performance of an 
obligation under the contract after certain circumstances have 
occurred which were not covered by the will of the party, but 
were defined at the time of the conclusion of the contract by the 
terms of the transaction concluded in an information system 
(automated performance). Only the parties to the agreement 
may call for the performance of such an obligation”. This 
content indicates that it was created to secure the most 
important element of self-executing contracts – automation. 
The legislator has thus introduced a new optional element of the 
contract – automated performance of an obligation [1, 21–23]. 

Another example of solution is the one called “Singapore”. In 
this case, the legislator amended the Evidence Law Act. 
Although the name of the concept of smart contract is not 
mentioned at all, there is a definition of electronic recording. 
In addition, the institution of presumptions in relation to 
electronic records was created, and the main purpose of this 
kind of legal institution is to instruct the court how to evaluate 
evidence [24]. 

In Poland, despite the proposal of amendment of the 
Commercial Companies Code and the introduction of DLT by 
introducing a clause in joint-stock companies and stock 
companies that “the register of shareholders is maintained in 
an electronic form, which may take the form of a distributed 
and decentralized database”, as it can be used in running the 
company, which will imply proving certain facts in the future 
with the need to refer to DLT elements, including what smart 
contracts are and what they are meant for. In the case of 
tokenisation, the question of a “document” also arises [25]. In 
general, the court will have to check whether the solution used 
in the DLT can be treated as a document. Additionally, the 
court will also be obliged to verify in which DLT solution the 
data was saved. This issue of legal value blockchain will need 
to be examined based on eIDAS regulations [20]. 

No simultaneous attempt has been made in Poland in order to 
amend the Civil Code or the Civil Procedure Code. At present, 
there is no separate act in Poland which would regulate the 
issues of the law of evidence. It is worth noticing that for the 
period of time that self-executing contracts started to become 
more and more popular, there has been a change introduced in 
the Polish legal system affecting the practice of using smart 
contracts. It is the contract of evidence that is similar to the 
common law parol evidence rule. 

6.   Contract of evidence 

A new institution in Polish law, based on parol evidence law, 
was established, and it can be presented in the following 
points [26]: 

• It refers to the contractual relationship. 

• It is addressed to entrepreneurs. 

• It excludes certain means of proof. 

In the context of the consideration of a smart contract, this 
judicial institution does not permit any agreement that restricts 
the court’s ability to admit evidence or any possibility that 
could impose its assessment. As a result, it is neither possible 
to create new, and especially unknown to the procedural law, 
means (sources) and methods of evidence nor can specific 
evidence, special evidentiary power or any other extraordinary 
procedural significance be given priority. It is also not allowed 
to change the function of factual and legal presumptions and 
other rules of taking evidence. In conclusion, the parties 
cannot influence the free assessment of evidence [26]. 

Taking other aspects into account, it should be noted that the 
permitted exclusion of evidence may consist in prohibiting the 
use of certain types of evidence (e.g. evidence from witness 
statements, expert opinions, documents, etc.) or specific 
evidence, individualised by their exact description (e.g. 
evidence from a specific document, from specific witnesses, 
from specific expert opinions, etc.). The exclusion may also 
depend on the ban on proving specific circumstances, as, e.g., 
specific facts that normally are subject to the statement of the 
court (subject of evidence) [26]. 

So there are elements that can be used in the context of this 
institution and smart contracts. Knowing a specific expert, 
who, in his opinions, is not very reliable in presenting the 
issues of our smart contract; nothing stands in the way of 
excluding him by means of a contract of evidence; it can be 
orally submitted before the court. It is not possible to instruct 
the court to use, for example, the presumption of electronic 
recording, as presented above, by means of this evidence 
contract. The very limited institution of parol evidence law 
under Polish law seems to be neither particularly restrictive 
nor particularly supportive of the development of the use of 
smart contracts. It is possible that further adoption of the 
patterns of Anglo-American solutions will result in the 
appearance of new models. This situation seems more than 
likely as the entry into the IoE era will generate the need to 
expand this institution. 

7.   Smart city in Poland and smart(er) contracts 

IoE is an important element of the difficult-to-define concept 
of the smart city, where in a nutshell, ubiquitous technology 
makes life easier for the digital society. It is worth underlining 
that the “smart” element of this concept, i.e. technology, may 
have undesirable consequences in the sphere of contracts for 
the legal awareness of smart city residents. The point is that 
people may not understand if and when they create legally 
binding contracts, or they may not understand their rights and 
obligations under their contracts. Technology saturation also 
depends on experts. Therefore, it seems reasonable to appeal 
to scientists for smart solutions, which will also be user-



  
  

The	
  JBBA	
  	
  |	
  	
  Volume	
  3	
  |	
  	
  Issue	
  2	
  	
  |	
  	
  2020	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  Published	
  Open	
  Access	
  under	
  the	
  CC-­‐‑BY	
  4.0	
  Licence	
  
	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
   	
  

5	
  

  

friendly and will take into account the dominant role of law in 
the sphere of contracts [23, 27].  

There is also an important comment to be made in this area. 
Kevin Werbach and Nicolas Cornell noticed that self-
executing contracts shift the focus of the remedy from 
execution to return [27]. However, it remains an open question 
whether it is a smart contract or a modern civil law turnover, 
with its tendency to accelerate access to, e.g., a service which 
implies an approach that gravity of the remedy is shifted. What 
really seems to change due to smarter contracts is definitely 
increasing formalism. The open question is how it will relate to 
human mess and human mistakes. Even in the most 
developed society functioning in a very advanced smart city, 
this problem will never be eliminated [27, 29].  

In the context of the smart problem and technology-saturated 
contracts in terms of the smart city, there are also several other 
problems which are very significant: 

• The development of smart contracts in a smart city requires 
a discussion about the adherent way of entering into 
contracts, which seems to be the natural direction in the 
sphere of citizen’s activity in the city (entering the public 
transport vehicle, parking in the paid parking zone etc.)[29]. 

• Due to the international character of various corporations 
that offer smart contracts, the role of international private 
law, as well as establishing the proper international 
jurisdiction of the contract, seems to be very important [27, 
30]. 

• The concepts of machine-to-machine contracts and the role 
of man who drives, for example, an autonomous electric 
vehicle that needs recharging batteries once in a while are 
also still discussed. 

At the moment of writing the article in Poland, the authorities 
of one of the voivodeships officially admitted that they use 
DLT solutions. After preparing and submitting a request for 
access to public information to the Marshal’s Office of the 
Warmińsko-Mazurskie voivodeships, a representative of the 
authorities has admitted that they use utility tokens called 
“CoperniCoin”, which are assigned to the Waves token. The 
representative denied that the process of issuing took place in 
the framework of smart contracts and that smart contracts 
were used in the framework of CoperniCoins trading. 
Moreover, he noted that it is the designated employee who 
distributes the tokens as part of the region’s promotional 
activities and that, until 18 December 2019, 101 CoperniCoin 
tokens were in circulation. Due to the lack of a legal definition 
of smart contracts, it is difficult to question or criticise such an 
approach, and it should be considered as correct. However, it 
is the irrefutable evidence that the popularity of DLT solutions 
will increase [31].  

8.   Conclusion 

In conclusion, it should be noted that further dynamic 
development of the DLT can contribute to a greater interest 
of policy makers in smart contracts. It seems that it depends a 
lot on the significant factor which is the factor of power 
activity, in other words, it depends a lot on people who are in 
power and also on influencial persons who can contribute to 
increasing science’s participation in the study of this novelty. It 
should be regarded as positive that the approval of the paper 
to smart contract in the Code of Commercial Companies is 
allowed. It seems worrying that there are no indications 
concerning the evidential issues connected with the 
introduction of this type of solution. The most visible change 
that can be transferred into the practice of smart contracts is 
the contract of evidence, but its possibilities are significantly 
limited. 

Certainly, in the context of the digital society functioning in 
smart city, it should be perceived positive that the contract of 
evidence does not apply to the entrepreneur-consumer 
re";"""date"",""2020-04-30T12:23:29Z""
""pdf:PDFVersion"",""1.3""
""xmp:CreatorTool"",""Word""
""pdf:docinfo:title"",""Microsoft Word - Article 3 - RTP.docx""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.3""
""pdf:docinfo:creator_tool"",""Word""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""Microsoft Word - Article 3 - RTP.docx""
""xmp:CreateDate"",""2020-04-30T12:22:32Z""
""modified"",""2020-04-30T12:23:29Z""
""pdf:hasMarkedContent"",""false""
""xmp:ModifyDate"",""2020-04-30T13:23:29Z""
""meta:creation-date"",""2020-04-30T12:22:32Z""
""created"",""2020-04-30T12:22:32Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-04-30T12:22:32Z""
""resourceName"",""12720.pdf""
""producer"",""Mac OS X 10.10.5 Quartz PDFContext""
""pdf:docinfo:producer"",""Mac OS X 10.10.5 Quartz PDFContext""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dcterms:created"",""2020-04-30T12:22:32Z""
""Last-Modified"",""2020-04-30T12:23:29Z""
""dcterms:modified"",""2020-04-30T12:23:29Z""
""title"",""Microsoft Word - Article 3 - RTP.docx""
""xmpMM:DocumentID"",""uuid:6b330d74-17ad-ed4c-8d88-4d233dc5e75f""
""Last-Save-Date"",""2020-04-30T12:23:29Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2020-04-30T12:23:29Z""
""meta:save-date"",""2020-04-30T12:23:29Z""
""Content-Type"",""application/pdf""
""xmp:MetadataDate"",""2020-04-30T13:23:29Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""pdf:producer"",""Mac OS X 10.10.5 Quartz PDFContext""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""7""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""4865"",""6496"",""6119"",""6362"",""5602"",""4972"",""1522""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-04-30T12:22:32Z""
";https://scholar.google.ch/scholar?start=830&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098831-253;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Simulation extractable versions of Groth's zk-SNARK revisited;K Baghery, Z Pindado, C Rŕfols ; International Conference on Cryptology …, 2020  Springer;;"… 3 Simulation Extractability Without Random Oracles … Google Scholar. 4. Bowe, S., Gabizon, A.:

Making groth's zk-SNARK simulation extractable in the random oracle model … Google Scholar.

9. Kosba, AE, Miller, A., Shi, E., Wen, Z., Papamanthou, C.: Hawk: the blockchain model of …";Cité 2 fois;;null;;;;https://scholar.google.ch/scholar?start=800&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098818-224;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Learning to encode and classify test executions;F Tsimpourlas, A Rajan, M Allamanis ; arXiv preprint arXiv:2001.02444, 2020  arxiv.org;;"… 2. Test oracles for industrial case studies - Realistic programs with complex behaviours and input

data … Other test oracle work that use NNs is not used in the comparison as they do not … 1. Ethereum

[4] is an open-source software platform based on blockchain technology, which …";Cité 2 fois;Les 3 versions;[PDF] arxiv.org;https://arxiv.org/pdf/2001.02444;"
Learning to Encode and Classify Test Executions
Foivos Tsimpourlas

University of Edinburgh

F.Tsimpourlas@sms.ed.ac.uk

Ajitha Rajan

University of Edinburgh

arajan@ed.ac.uk

Miltiadis Allamanis

Microsoft Research

miallama@microsoft.com

ABSTRACT
The challenge of automatically determining the correctness of test

executions is referred to as the test oracle problem and is one of the

key remaining issues for automated testing. The goal in this paper

is to solve the test oracle problem in a way that is general, scalable

and accurate.

To achieve this, we use supervised learning over test execution

traces. We label a small fraction of the execution traces with their

verdict of pass or fail. We use the labelled traces to train a neu-

ral network (NN) model to learn to distinguish runtime patterns

for passing versus failing executions for a given program. Our ap-

proach for building this NN model involves the following steps, 1.

Instrument the program to record execution traces as sequences of

method invocations and global state, 2. Label a small fraction of the

execution traces with their verdicts, 3. Designing a NN component

that embeds information in execution traces to fixed length vectors,

4. Design a NN model that uses the trace information for classi-

fication, 5. Evaluate the inferred classification model on unseen

execution traces from the program.

We evaluate our approach using case studies from different appli-

cation domains - 1. Module from Ethereum Blockchain, 2. Module

from PyTorch deep learning framework, 3. Microsoft SEAL en-

cryption library components, 4. Sed stream editor, 5. Value pointer

library and 6. Nine network protocols from Linux packet identifier,

L7-Filter. We found the classification models for all subject pro-

grams resulted in high precision, recall and specificity, over 95%,

while only training with an average 9% of the total traces. Our ex-

periments show that the proposed neural network model is highly

effective as a test oracle and is able to learn runtime patterns to

distinguish passing and failing test executions for systems and tests

from different application domains.

ACM Reference Format:
Foivos Tsimpourlas, Ajitha Rajan, and Miltiadis Allamanis. 2020. Learning

to Encode and Classify Test Executions. In Proceedings of ACM Conference
(Conference’17). ACM, New York, NY, USA, 12 pages. https://doi.org/10.1145/

nnnnnnn.nnnnnnn

1 INTRODUCTION
As the scale and complexity of software increases, the number of

tests needed for effective validation becomes extremely large, slow-

ing down development, hindering programmer productivity, and

Permission to make digital or hard copies of all or part of this work for personal or

classroom use is granted without fee provided that copies are not made or distributed

for profit or commercial advantage and that copies bear this notice and the full citation

on the first page. Copyrights for components of this work owned by others than ACM

must be honored. Abstracting with credit is permitted. To copy otherwise, or republish,

to post on servers or to redistribute to lists, requires prior specific permission and/or a

fee. Request permissions from permissions@acm.org.

Conference’17, July 2017, Washington, DC, USA
Š 2020 Association for Computing Machinery.

ACM ISBN 978-x-xxxx-xxxx-x/YY/MM. . . $15.00

https://doi.org/10.1145/nnnnnnn.nnnnnnn

ultimately making development costly [11]. The need for large num-

bers of tests is magnified in agile software development practices,

like Continuous Integration (CI) and Test-Driven Development

(TDD), that require extensive testing to be performed [22]. To make

testing faster, cheaper and more reliable, it is desirable to automate

as much of the process as possible.

One of the biggest hurdles in test automation is the test oracle -
“a procedure that distinguishes between the correct and incorrect

behaviours of the System Under Test (SUT)” [13]. Literature refers

to the challenge of automatically determining the correctness of

test executions as the test oracle problem and acknowledges it as

one of the key remaining issues for automated testing [13]. Recent

surveys on the test oracle problem [13, 26, 28] show that existing

techniques based on formal specifications, metamorphic relations

and independent program versions are not widely applicable and

difficult to use in practice.

Key Idea. In this paper, we explore supervised machine learn-

ing to infer a test oracle from labelled execution traces of a given

system. In particular, we use neural networks (NNs), well suited

to learning complex functions, to design the test oracles. We be-

lieve NNs would be a good fit as they can help understand the

runtime patterns of a system that indicate correct versus incorrect

executions. Previous work exploring the use of NNs for test oracles

has been in a restricted context – applied to very small programs

with primitive data types, and only considering their inputs and

outputs [24, 33]. Dynamic execution data and program state has not

been considered by existing NN-based approaches. Recent work

using NNs over programs to predict method or variable names and

detecting name-based bug patterns [9, 31] relies on static program

information, namely, embeddings of the Abstract Syntax Tree (AST)

or source code. Our proposed approach is the first attempt at using

dynamic execution trace information in NN models for classifying
program executions.

Our approach for inferring a test oracle has the following steps,

(1) Instrument a program to gather execution traces as sequences

of method invocations and the final global state.

(2) Label a small fraction of the traces with their classification

decision.

(3) Design a NN component that embeds the execution traces

to fixed length vectors.

(4) Design a NN component that uses the line-by-line trace

information to classify traces as pass or fail.

(5) Train a NN model that combines the above components and

evaluate it on unseen execution traces for that program.

The novel contributions in this paper are in Steps 3, 4 and 5. Ex-

ecution traces from a program vary widely in their length and

information. We propose a technique to encode and summarise the

information in a trace to a fixed length vector that can be handled

by a NN. We then design and train a NN to serve as a test oracle.

ar
X

iv
:2

00
1.

02
44

4v
1 

 [
cs

.S
E

] 
 8

 J
an

 2
02

0

https://doi.org/10.1145/nnnnnnn.nnnnnnn
https://doi.org/10.1145/nnnnnnn.nnnnnnn
https://doi.org/10.1145/nnnnnnn.nnnnnnn


Conference’17, July 2017, Washington, DC, USA Foivos Tsimpourlas, Ajitha Rajan, and Miltiadis Allamanis

Labelled execution traces. Effectively learning a NN classi-

fier for a SUT that distinguishes correct from incorrect executions

requires labelled data with both passing and failing examples of

traces. Given a SUT and a test suite, we gather execution traces

corresponding to each of the test inputs in the test suite with our

instrumentation framework. We require a small fraction of the over-

all execution traces to be labelled. We hypothesize that the time

invested in labelling a small proportion of the traces is justified

with respect to the benefit gained in automatically classifying the

remaining majority of traces. In contrast, with no classifier, the de-

veloper would have had to specify expected output for all the tests,

which is clearly more time consuming than the small proportion of

tests we need labelled. It is common for case studies to have many

passing test inputs but only a limited number of failing tests. To

address this imbalance in training, we generate failing traces by

mutating the existing code with common bugs. Test inputs that

were labelled with passing traces through the original code will be

labelled with failing traces through the mutated code if the output

deviates from the expected output.

NN Architecture. An execution trace in our approach com-

prises multiple lines, with each line containing information on a

method invocation or the global state. Our architecture for encod-

ing and classifying an execution trace uses multiple components:

(1) Value encoder for encoding values within the trace line to a

distributed vector representation, (2) Trace encoder encoding trace

lines within a variable-length trace to a single vector, and (3) Trace

Classifier that accepts the trace representation and global variable

values and classifies the trace. The components in our architec-

ture is made up of LSTMs, one-hot encoders, and a multi-layer

perceptron.

Case Studies.We evaluate our approach using 15 subject pro-

grams and tests from different application domains - a singlemodule

from Ethereum project [4], a module from Pytorch [29], two differ-

ent components within Microsoft SEAL encryption library [32], a

smart pointer library [2], a Linux stream editor [1] and 9 network

protocols from L7-filter [3]. We found our approach for designing a

NN classification model was feasible and effective for each of these

programs. We achieved high accuracies in detecting both failing

and passing traces, with an average precision of 97% and recall of

98%. Only a small fraction of the overall traces (average 9%) needed

to be labelled for training the classification models.

In summary, the paper makes the following contributions:

• Given a SUT and its test inputs, we provide a framework

that instruments the SUT and gathers test execution traces

as sequences of method invocations and final global state.

• A NN component for encoding variable-sized execution

traces into fixed length vectors.

• A NN for classifying the execution traces as pass or fail.

• We provide empirical evidence that this approach yields

effective test oracles for programs and tests from different

application domains.

2 BACKGROUND
When a test oracle observes a test execution, it returns a test verdict,

which is either pass or fail, depending on whether the observations

match expected behaviour. A test execution is execution of the SUT

with a test input. The importance of oracles as an integral part of

the testing process has been a key topic of research for over three

decades. We distinguish four different kinds of test oracles, based on

the survey by Barr et al. in 2015 [13]. The most common form of test

oracle is a specified oracle, one that judges behavioural aspects of the
system under test with respect to formal specifications. Although

formal specifications are effective in identifying failures, defining

and maintaining such specifications is expensive and also relatively

rare in practice. Implicit test oracles require no domain knowledge

and are easy to obtain at practically no cost. However, they are

limited in their scope as they are only able to reveal particular

anomalies in program executions like buffer overflows, segmen-

tation faults, deadlocks. Derived test oracles use documentations

or system executions, to judge a system’s behaviour, when spec-

ified test oracles are unavailable. However, derived test oracles,

like metamorphic relations and inferring invariants, is either not

automated or it is inaccurate and irrelevant making it a challenge

for practical use.

For many systems and much of testing as currently practised in

industry, the tester does not have the luxury of formal specifications

or assertions or even automated partial oracles [18, 19]. Statistical

analysis and machine learning techniques provide a useful alter-

native for understanding software behaviour using data gathered

from a large set of test executions.

2.1 Machine Learning for Software Testing
Briand et al. [15], in 2008, presented a comprehensive overview

of existing techniques that apply machine learning for addressing

testing challenges. Among these, the closest related work is that

of Bowring et al. in 2004 [14]. They proposed an active learning

approach to build a classifier of program behaviours using a fre-

quency profile of single events in the execution trace. Evaluation

of their approach was conducted over one small program whose

specific structure was well suited to their technique. Machine learn-

ing techniques have also been used in fault detection. Brun and

Ernst, in 2004 [16], explored the use of support vector machines

and decision trees to rank program properties, provided by the user,

that are likely to indicate errors in the program. Podgurski et al.,

in 2003 [30], use clustering over function call profiles to determine

which failure reports are likely to be manifestations of an underly-

ing error. A training step determines which features are of interest

by evaluating features that enable a model to distinguish failures

from non-failures, The technique does not consider passing runs.

In their experiments, for most clusters, the cluster contains failures

resulting from a single error.

More recently, Almaghairbe et al. [8] proposed an unsupervised

learning technique to classify unlabelled execution traces of simple

programs. They gather two kinds of execution traces, one with

only inputs and outputs, and another that includes the sequence of

method entry and exit points, with only method names. Arguments

and return values are not used. They use agglomerative hierarchical

clustering algorithms to build an automated test oracle, assuming

passing traces are grouped into large, dense clusters and failing

traces into many small clusters. They evaluate their technique on 3

programs from the SIR repository [17]. The proposed approach has

several limitations. They only support programs with strings as

inputs. They do not consider correct classification of passing traces.



Learning to Encode and Classify Test Executions Conference’17, July 2017, Washington, DC, USA

The accuracy achieved by the technique is not high, classifying

approximately 60% of the failures. Additionally, fraction of outputs

that need to be examined by the developer is around 40% of the total

tests, which is considerably higher than the labelled data used in our

approach. We objectively compared the accuracy achieved by the

hierarchical clustering technique against our approach using 15 case

studies, discussed in Section 5.We found that our approach achieves

significantly higher accuracy in classifying program executions

across all case studies.

Existing work using execution traces for bug detection has pri-

marily been based on clustering techniques. Neural networks, es-

pecially with deep learning, have been very successful for complex

classification problems in other domains like natural language pro-

cessing, speech recognition, computer vision. There is limited work

exploring their benefits for software testing problems.

Neural Networks for Test Oracles. NNs were first used by Vanmali

et al. [33] in 2002 to simulate behaviour of simple programs using

their previous version, and applied this model to regression testing

of unchanged functionalities. Aggarwal et al. [5] and Jin et al. [24]

applied the same approach to test a triangle classification program,

that computes the relationship among three edge inputs to deter-

mine the type of triangle. The few existing approaches using NNs

have been applied to simple programs having small I/O domains.

The following challenges have not been addressed in existing work,

1. Training with test execution data and their vector representation

– Existing work only considers program inputs and outputs that

are of primitive data types (integers, doubles, characters). Test data

for real programs often use complex data structures and data types

defined in libraries. There is a need for techniques that encode such

data. In addition, existing work has not attempted to use program

execution information in NNs to classify tests. Achieving this will

require novel techniques for encoding execution traces and design-

ing a NN that can learn from them.

2. Test oracles for industrial case studies - Realistic programs with

complex behaviours and input data structures has not been previ-

ously explored.

3. Effort for generating labelled training data - Training data in

existing work has been over simple programs, like the triangle clas-

sification program, where labelling the tests was straightforward.

Generating labelled data for failing tests has not been previously

addressed. Additionally, the proportion of labelled test data to total

number of tests needed and its effect on model prediction accuracy

has not been systematically explored.

Deep Learning for Software Testing. The performance of neural

networks as classifiers was boosted with the birth of deep learn-

ing in 2006 [20]. Deep learning methods have not been explored

extensively for software testing, and in particular for the test oracle

problem. Recently, a few techniques have been proposed for auto-

matic pattern-based bug detection. For example, Pradel et al. [31]

proposed a deep learning-based static analysis for automatic name-

based bug detection and Allamanis et al. [6] used graph-based

neural static analysis for detecting variable misuse bugs. In addi-

tion to these techniques, several other deep learning methods for

statically representing code have been developed [7, 10]. We do

not discuss these further since we are interested in execution trace

classification and in NNs that use dynamic trace information rather

than a static view of the code.

Embedding Execution Traces for Neural Networks. One of the

main contributions in this paper is an approach for embedding

information in execution traces as a fixed length vector to be fed

into the neural network. There is limited work in using representa-

tions of execution traces. Wang et al. [34] proposed embeddings of

execution traces in 2017. They use execution traces captured as a

sequence of variable values at different program points. A program

point is when a variable gets updated. Their approach uses recurrent

NNs to summarise the information in the execution trace. Embed-

ding of the traces is applied to an existing program repair tool. The

work presented byWang et al. has several limitations - 1. Capturing

execution traces as sequences of updates to every variable in the

program has an extremely high overhead and will not scale to large

programs. The paper does not describe how the execution traces are

captured, they simply assume they have them. 2. The approach does

not discuss how variables of complex data types such as structs,

arrays, pointers, objects are encoded. It is not clear if the traces only

capture updates to user-defined variables, or if system variables are

also taken into account. 3. The evaluation uses three simple, small

programs (eg. counting parentheses in a string) from students in an

introductory programming course. The complexity and scale of real

programs is not assessed in their experiments. Their technique for

capturing and directly embedding traces as sequences of updates

to every variable is infeasible in real programs. Our approach cap-

tures and embeds traces as sequences of method invocations and

updates to global variables, which scales better than tracking every

program variable. We have implemented our instrumentation in

the LLVM compiler framework that is language agnostic and scales

to industry-sized programs. We support all types of variables and

objects, including system defined variables.

3 APPROACH
Our approach for building an automated test oracle for classifying

execution traces has the following steps,

Step 1: Instrument the SUT to gather traces when executing the

test inputs.

Step 2: Preprocess the traces to prune unnecessary information.

Step 3: Encode the preprocessed traces into vectors that can be

accepted by the neural network.

Step 4: Design a NN model that takes as input an encoded trace,

and outputs a verdict of pass or fail for that trace.

Figure 1a illustrates the steps in our approach, with the bottom half

of the figure depicting steps 3 and 4 for any given preprocessed

trace from step 2. We discuss each of the steps in the rest of this

Section.

3.1 Instrument and Gather Traces
For every test input executed through the SUT, we aim to collect

an execution trace as a sequence of method invocations, where we

capture the name of the method being called, values and data types

of parameters, return values and their types, and, finally, the name

of the parent method in the call graph. We also capture a snapshot

of the final global state before execution terminates. We find gather-

ing further information, eg. updates to local variables within each



Conference’17, July 2017, Washington, DC, USA Foivos Tsimpourlas, Ajitha Rajan, and Miltiadis Allamanis

(a) Gathering traces, encoding them, and using NNs to classify them.

(b) Encoder 1 representing a single line within an execution
trace as a vector containing function caller, callee names, ar-
guments and return values.

Figure 1: High-level architecture of our approach and Encoder 1 description.

Figure 2: Encoder 2 representing a sequence of trace lines
and global state as a single vector.

method, incurs a significant overhead and is difficult to scale to

large programs. To gather this information we use the middleware

of LLVM [27] and instrument the intermediate representation (IR)

of programs. Working at LLVM’s IR allows our implementation to

be language-agnostic. LLVM provides front-end support for multi-

ple programming languages, such as C/C++, CUDA, Haskell, Swift,

Rust among others, along with numerous libraries for optimisation

and code generation.

To perform the instrumentation, we traverse the SUT, visiting

each method. Every time a method invocation is identified, code is

injected to trace the caller-callee pair, the arguments and the return

values. At the end of the program, code is inserted to capture the

final values of all the global variables.

Each trace can be considered to have two parts: 1. a sequence

of method invocations and 2. the final global state. The first part

of the trace comprises multiple lines, each line being a tuple (np ,

nc , r , a ) that represents a single method invocation within the

sequence having:

• The names of the caller (parent) np and called nc functions.
• Return values r of the call, if any.
• Arguments passed a , if any.

The order of method invocations in the sequence is the order in

which they complete and return to the calling point. We support

all variable types including primitive types (such as int, float,
char, bool), composite data types (such as structs, classes, arrays)

defined by a user or library, and pointers for return and argument

values. Structs and classes are associated with a sequence of values

for their internal fields. We instrument these data structures in a

depth first fashion, until all primitive types are traced. For pointers,

we monitor the values they refer to.

The second part of the trace represents the final global state

before termination and contains the values of all global variables.

Primitive types have a single value, encoded as a number. For com-

plex types, like a class object, the variable is associated with a

sequence of values, for the internal fields.

3.2 Labelled Passing and Failing Traces
We execute the instrumented program with each test input in the

test suite to gather a set of traces. A subset of the traces is la-

belled and used in training the classification model, discussed in

Section 3.4. For the subject programs in our experiment, expected

output is provided with the tests and we use that for labelling the

trace. It is worth noting that in our approach, the developer will

only need to provide expected outputs for a small proportion of tests
rather than the whole test suite. In current practices, the developer

or tester provides expected outputs for the whole test suite which is

considerably more effort than the 5 - 10% we require. In the absence

of expected output in tests, how will tests be labelled is a common

question. Answering this question will depend on what is currently

being done by the developer or organisation for classifying tests as

pass or fail. Our approach will entail applying the same practice to

labelling, albeit to a significantly smaller proportion of tests.

We also find that some programs are only accompanied by pass-

ing tests. To avoid an imbalanced training set with only passing

traces, we generate failing execution traces by running the orig-

inally passing tests through buggy implementations, generated

using code mutations. We ensure that only traces from buggy imple-

mentations whose outputs differ from expected outputs are marked

as failing. This avoids the problem of equivalent mutations. We

apply the following mutations representing some common bug

patterns [23, 31]:

(1) Logical connector replacement applied to {&&, | |, !}.
(2) Relational operator replacement applied to

{<, >,==, <=, >=, ! =}.

(3) Argument swapping in function calls.

(4) Scalar variable replacement.

(5) Loop boundary value replacement.



Learning to Encode and Classify Test Executions Conference’17, July 2017, Washington, DC, USA

To avoid data leakage in our experiment in Section 4, we ensure

that expected output is removed from the traces. We also remove

exceptions, assertions and any other information in the program

or test code that may act as a test oracle. This is further discussed

in Section 4.1.

3.3 Preprocessing
The execution traces gathered with our approach include informa-

tion on methods declared in external libraries, called during the

linking phase. To keep the length of the traces tractable and rele-

vant, we preprocess the traces to only keep trace lines for methods

that are defined, i.e. have a function body, in the module (which may

be included from other files), and remove trace lines for declared

functions that are not defined, but simply linked to later.

For method invocations within loops, a new trace line is created

for each invocation of the same method within the loop. For loops

with large numbers of iterations, this can lead to redundancy when

the method is invoked with similar arguments and return values.

We address this potential redundancy issue by applying average

pooling to trace lines with identical caller-callee methods within

loops. No preprocessing is applied to global variables in the trace.

3.4 Neural Network Model
In this step, we perform the crucial task of designing a neural net-

work that learns to classify the pre-processed traces as passing or

failing. Shape and size of the input traces vary widely, and this

presents a challenge when designing a NN that accepts fixed length

vectors summarizing the traces. To address this, our network com-

prises three components that are trained jointly and end-to-end:

1. a ValEnc that encodes values (such as the values of arguments

and return values) into DV -dimensional distributed vector repre-

sentations, shown within Encoder 1 in Figure 1b, 2. a TrEnc that

encodes variable-sized traces into a single DT -dimensional vector,

shown as Encoder 2 in Figure 1a, and finally, 3. a TraceClassifier

that accepts the trace representation and the global variable values

for state and predicts whether the trace is passing or failing. The

Multi-layer Perceptron in Figure 1a represents the TraceClas-

sifier . We describe each component in detail in the rest of this

section.

Encoding Values Values within the trace provide useful indi-

cations about classifying a trace. However, values — such as ints,

structs, and floats — vary widely in shape and size. We, therefore,

design models that can summarize variable-sized sequences into

fixed-length representations. In the machine learning literature, we

predominantly find three kinds of models that can achieve this: re-

current neural networks (RNNs), 1D convolutional neural networks

(CNN) and transformers. In this work, we employ LSTMs [21] — a

commonly used flavour of RNNs. Testing other models is left as fu-

ture work. At a high-level RNNs are recurrent functions that accept

a vector ht of the current state and an input vector xt and compute

a new state vector ht+1 = RNN (xt , ht ) which “summarizes” the

sequence of inputs up to time t . A special initial state h0 is used at

t = 0.

To encode a value v , we decompose it into a sequence of primi-

tives v = [p0,p1, ...] (integers, floats, characters, etc.). Each primi-

tive pi is then represented as a binary vector bi = e(pi ) containing

its bit representation padded to the largest primitive data type of

the task. For example, if int64 is the largest primitive then all bi s
have dimensionality of 64. This allows us to represent all values

(integers, floats, strings, structs, pointers, etc.) as a unified sequence

of binary vectors. We encode v into a DV -dimensional vector by

computing

ValEnc(v) = LSTMv (e(pL)L ,ValEnc([p0,p1, ...,pL−1])),
where LSTMv is the LSTM that sequentially encodes the bi s. Note
that we use the same ValEnc for encoding arguments, return values

and global variables, as seen in Figures 1b and 2. The intuition

behind this approach is that the bits of each primitive can contain

valuable information. For example, the bits corresponding to the

exponent range of a float can provide information about the order

of magnitude of the represented number, which in turn may be able

to discriminate between passing and failing traces.

Representing a Single Trace Line Armed with a neural net-

work component that encodes values, we can now represent a

single line (np , nc , r , a ) of the trace. To do this, we use ValEnc

to encode the arguments a and the return value r . We concatenate

these representations along with one-hot representations of the

caller and callee identities, as shown in Figure 1b. Specifically, the

vector encoding ti of the ith trace line is the concatenation

ti =
[
ValEnc(a),ValEnc(r ), 1Hot(np ), 1Hot(nc )

]
,

where 1Hot is a function that takes as input the names of the

parent or called methods and returns a one-hot vector that uniquely

encodes that method name. For methods that are rare (appear fewer

thankmin times) in our data, 1Hot collapses them to a single special

UNK name. This is similar to other machine learning and natural

language processing models and reduces sparsity often improving

generalization. The resulting vector ti has size 2DV + 2k where k
is the size of each one-hot vector.

Encoding Traces Now that we have built a neural network

component that encodes single lines within a trace, we design

TrEnc that accepts a sequence of trace line representations t0...tN
and summarizes them into a single DT -dimensional vector. We use

an LSTM with a hidden size DT , and thus

TrEnc(t0...tN ) = LSTMtr (tN,TrEnc(t0...tN−1)) ,
where LSTMtr () is an LSTM network that summarizes the trace

line representations.

Encoding Global State We encode the final values of global

variables in each trace. Assuming global variables Đ´0, ...,Đ´M , we

first encode them using ValEnc and then summarize the global

state into a single vector

rG = Pool(ValEnc(Đ´0), ...ValEnc(Đ´M )),
where Pool is a permutation-invariant pooling function and rG is a

DV -sized vector. In this work, we usemax pooling (i.e. element-wise

maximum). Note that the permutation invariance is a necessary

design requirement since the representation of the global state

should be invariant to the ordering of the global variables. Figure 2

shows TrEnc along with global state encoding.

Classifying Traces With the neural network components de-

scribed so far we have managed to encode traces into fixed length

vector representations. The final step is to use those computed rep-

resentations to make a classification decision. We treat failing traces



Conference’17, July 2017, Washington, DC, USA Foivos Tsimpourlas, Ajitha Rajan, and Miltiadis Allamanis

as the positive class and passing traces as the negative class since

detecting failing runs is of more interest in testing. We compute

the probability that a trace is failing as

P(fail) = TraceClassifier([TrEnc(t0...tN ), rG ]),

where the input of TraceClassifier is the concatenation of the two

vectors. Our implementation of TraceClassifier is a multilayer

perceptron (MLP) with sigmoid non-linearities and a single output,

which can be viewed as the probability that the trace is a failing

trace. It follows that P(pass) = 1 − P(fail).
Training and Implementation Det";"""date"",""2020-01-09T01:45:56Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""Learning to Encode and Classify Test Executions""
""xmp:CreatorTool"",""LaTeX with acmart 2019/08/05 v1.63a Typesetting articles for the Association for Computing Machinery and hyperref 2016/06/24 v6.83q Hypertext links for LaTeX""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with acmart 2019/08/05 v1.63a Typesetting articles for the Association for Computing Machinery and hyperref 2016/06/24 v6.83q Hypertext links for LaTeX""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""Learning to Encode and Classify Test Executions""
""modified"",""2020-01-09T01:45:56Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""Foivos Tsimpourlas, Ajitha Rajan, and Miltiadis Allamanis""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016) kpathsea version 6.2.2""
""meta:author"",""Foivos Tsimpourlas, Ajitha Rajan, and Miltiadis Allamanis""
""trapped"",""False""
""meta:creation-date"",""2020-01-09T01:45:56Z""
""created"",""2020-01-09T01:45:56Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-01-09T01:45:56Z""
""resourceName"",""2001.02444""
""Author"",""Foivos Tsimpourlas, Ajitha Rajan, and Miltiadis Allamanis""
""producer"",""pdfTeX-1.40.17""
""pdf:docinfo:producer"",""pdfTeX-1.40.17""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""2"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""Foivos Tsimpourlas, Ajitha Rajan, and Miltiadis Allamanis""
""dcterms:created"",""2020-01-09T01:45:56Z""
""Last-Modified"",""2020-01-09T01:45:56Z""
""dcterms:modified"",""2020-01-09T01:45:56Z""
""title"",""Learning to Encode and Classify Test Executions""
""Last-Save-Date"",""2020-01-09T01:45:56Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2020-01-09T01:45:56Z""
""meta:save-date"",""2020-01-09T01:45:56Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016) kpathsea version 6.2.2""
""Content-Length"",""2479360""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Foivos Tsimpourlas, Ajitha Rajan, and Miltiadis Allamanis""
""dc:language"",""en""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""12""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""5342"",""5936"",""5769"",""3676"",""5536"",""5325"",""4987"",""168"",""5047"",""5361"",""5296"",""2172""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-01-09T01:45:56Z""
";https://scholar.google.ch/scholar?start=770&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098866-333;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Pointproofs: aggregating proofs for multiple vector commitments;S Gorbunov, L Reyzin, H Wee, Z Zhang ; Proceedings of the 2020 ACM …, 2020  dl.acm.org;;"… To validate each block, participants in the blockchain protocol (so-called “validators”) need to

have access to the variables used during the relevant transactions … 2010 Page 5. only via oracle

queries. We will use two random oracles H and H?, both with output space Zp …";Cité 10 fois;Les 2 versions;[PDF] iacr.org;https://eprint.iacr.org/2020/419.pdf;"
Pointproofs:
Aggregating Proofs for Multiple Vector Commitments

Sergey Gorbunov2, Leonid Reyzin1,3, Hoeteck Wee4,5, and Zhenfei Zhang1

1Algorand
2University of Waterloo

3Boston University
4CNRS, ENS, PSL

5NTT Research

August 25, 2020

Abstract

Vector commitments enable a user to commit to a sequence of values and provably reveal one or
many values at speci�c positions at a later time. In this work, we construct Pointproofs— a new vector
commitment scheme that supports non-interactive aggregation of proofs across multiple commitments.
Our construction enables any third party to aggregate a collection of proofs with respect to di�erent,
independently computed commitments into a single proof represented by an elliptic curve point of
48-bytes. In addition, our scheme is hiding: a commitment and proofs for some values reveal no
information about the remaining values.

We build Pointproofs and demonstrate how to apply them to blockchain smart contracts. In our
example application, Pointproofs reduce bandwidth overheads for propagating a block of transactions
by at least 60% compared to prior state-of-art vector commitments.

Pointproofs are also e�cient: on a single-thread, it takes 0.08 seconds to generate a proof for 8
values with respect to one commitment, 0.25 seconds to aggregate 4000 such proofs across multiple
commitments into one proof, and 23 seconds (0.7 ms per value proven) to verify the aggregated proof.

1 Introduction

Vector commitments [LY10, CF13] allow a commi�er to commit to a vector ofN values and then selectively
reveal elements of the commi�ed vector, proving that they correspond to the original commitment. Vector
commitments are used to reduce storage costs in a variety of applications, described in more detail below:
instead of storing a vector of values, one can store only the commitment and receive the values together
with their proofs as needed. Vector commitments allow applications to trade oďż˝ storage (of all values) for
bandwidth (taken up by revealed values and proofs).

To make the tradeo� between storage and bandwidth more a�ractive, we need to reduce the proof size.
Because individual proofs need to be cryptographically hard to forge, their sizes cannot be reduced too far.
Instead, the savings come from having a single short proof for multiple revealed values. �e shortest such
proofs in the literature are provided by the so-called subvector commitments of Lai and Malavolta [LM19,

1



reference pp opening group Same-Commitment Cross-Commitment
Aggregatable Aggregatable

[LM19, Fig 1] O(N) 256 B class group
[LM19, Fig 2] O(N2) 48 B bilinear
[BBF19] O(1) 1312 B class group X
[CFG+20, 5.1] O(1) 1024 B class group X
[CFG+20, 5.2] O(1) 512 B class group X
[TAB+20] O(N) 48 B bilinear X
this work O(N) 48 B bilinear X X

Table 1: Summary of subvector commitments with constant-size commitments and openings to subvectors
at 128-bit security level. (See Table 3 for an explanation of the numbers.)

Section 5.2]: a proof takes up only 48 bytes (for typical parameter values at conjectured 128-bit security)
regardless of how many elements of the vector are being revealed.1

In many distributed applications, the commitments, values, and proofs come from multiple sources
that are not even aware of each other’s data. �is presents two problems that are not solved by subvector
commitments:

• there is no single entity that can produce a single proof for all the values;

• proofs need to be with respect to multiple di�erent commitments.

For instance, consider a blockchain that contains information on multiple accounts. Each account,
controlled by a di�erent user, is associated with a memory that consists of multiple variables. �e memory
may, for example, store the values of variables in a smart contract. To validate each block, participants
in the blockchain protocol (so-called “validators”) need to have access to the variables used during the
relevant transactions. One solutions is to have validators store all the variables locally. However, to save
on storage, we may instead apply commitments, and ask account holders to commit to the values of their
variables. During the relevant transaction, account holders would produce proofs for the relevant values.
Our goal is to save on bandwidth required for these proofs to reach validators, while enabling solutions
that do not rely on central parties or additional interaction.

We construct Pointproofs—an e�cient commitment scheme with small commitments and proofs.
Using Pointproofs, a user can independently commit to her variables and provide short proofs for any
subset of them. Moreover, any third party can non-interactively aggregate multiple proofs with respect to
di�erent commitments into a single short proof.

We note that dynamic aggregation for a single commitment gives, in particular, subvector commit-
ments. Such same-commitment aggregation was explored by Boneh, Bünz, and Fisch [BBF19] and (in work
independent of ours) by Tomescu et al. [TAB+20], who showed how to aggregate proofs for elements of a
vector into a single proof for a subvector. Aggregation of [BBF19] was extended to incremental aggregation
(which allows aggregation of already aggregated proofs) by Campanelli et al. [CFG+20]. To the best of
our knowledge, there have been no schemes that can aggregate proofs across multiple commitments; see
Table 1 for a summary of prior constructions.

1Observe that the length of 48 bytes is very close to the information-theoretic minimum of 32 bytes necessitated by the
birthday bound for 128-bit security.

2



1.1 Our Contributions

First, we formalize aggregatable vector commitments in the cross-commitment se�ing (Section 3). For
functionality, we require that proofs for individual elements of a single vector commitment can be
aggregated by any third party into a single proof for the subvector, and proofs for subvectors of multiple
commitments can be aggregated by any third party into a single proof for the multiple subvectors. We also
consider hiding while still supporting the aggregation property.

Next, we add same-commitment and cross-commitment aggregation to the vector commitments of
[LY10] to construct Pointproofs (Section 4). Our proof is a single point on a pairing-friendly curve (48
bytes at 128-bit security), whether for a single value, a subvector of values for a single commitment, or
a set of subvectors for multiple commitments. Our construction easily extends to support full hiding
of the commi�ed values at the cost of an additional exponentiation and no increase in commitment or
proof sizes. While the authors of [CF13, Section 3] point out that hiding in vector commitments can be
achieved generically by adding an inner layer of hiding commitments to individual values, this approach
does not automatically extend to aggregatable vector commitments, because proofs for the inner layer are
not automatically aggregatable.

We provide a design overview for applying Pointproofs to reduce storage requirements for blockchains
(Section 5). We speci�cally focus on smart contracts. Consider a smart contract with multiple variables.
�e current values (m1, . . . ,mN ) of all the variables in a given contract are commi�ed to a single vector
commitmentC , one commitment per contract. To transact with the contract, one provides a 48-byte proof
π̂ of the current values of the variables needed for the transaction, which are then (optionally) updated
as a result of the transaction. When there are multiple smart contracts, cross-commitment aggregation
allows us to compress multiple proofs π̂1, . . . , π̂` into a single 48-byte proof π. �is essentially eliminates
the bandwidth overhead due to proofs in a proposed block, which, depending on the se�ing, can take up
more bandwidth than the values being proven.

When applied to smart contracts storage, Pointproofs can be used to reduce validators’ storage
requirements to 4.5 GB for 108 accounts while adding only 31 KB per block overhead for 1000 transactions
(assuming one open value per transaction). Alternative approaches to smart contracts require either (a)
extensive storage from validators (TBs), (b) a central entity to generate proofs for all users, or (c) introduce
at least an additional 60% bandwidth overhead per block. (See Section 5.2 for a more detailed comparison.)

We implement Pointproofs and show that Pointproofs are e�cient to produce, aggregate, verify, and
update for real-time use. We release our code to open source under the MIT license on GitHub [Alg20b].
In our benchmarks for a commitment for 1000 variables of a smart contract at 128-bit security level, a user
can produce a subvector proof for an arbitrary subset of variables (touched by a particular transaction) in
54-123ms; a block proposer can cross-commitment aggregate all these proofs, at the cost of about .07ms
per proof; a validator who stores commitments can verify the aggregated proofs in a block at the cost of
0.7–1.9ms per value veri�ed, and update commitments to re�ect new values of the variables (which change
in response to the transaction execution) at the cost of .0.2–0.3ms per variable updated (numerical ranges
are due to variations in the number of commitments and values proven per commitment).
Summary of Contributions. To summarize, our contributions are as follows:

• We formalize aggregatable vector commitments in the cross-commitment se�ing. We also formalize
the hiding property while also supporting aggregation.

• We construct Pointproofs based on bilinear groups and prove their security (in the algebraic group
and random oracle models).

3



• We show how to apply Pointproofs to smart-contract-based transactions on blockchains and
evaluate them compared to alternative solutions.

• We build Pointproofs and evaluate their performance for various parameters.

We envisage that there will be multiple possible applications for cross-commitment aggregation of
proofs. Just like signature aggregation can be bene�cial to compress multiple signatures produced by
di�erent users into a short signature—with applications ranging from sensor networks [AGH10] to internet
routing [BGR12] to consensus [DGNW20]—proof aggregation can help whenever multiple commi�ed
values produced by di�erent users are revealed. One can imagine many se�ings in which multiple
users or entities independently commit to their databases of records (e.g., public keys, healthcare records,
transactions, etc.) and concurrently produce proofs to reveal several commi�ed values. Cross-commitment
aggregation can be applied to save on bandwidth in such se�ings.

1.2 Related Work

�e idea of using commitments to trade storage for bandwidth in the context of blockchains has appeared
in multiple works in varying levels of detail, including [ST99, Mil12, Whi15, Tod16, But17, Dra17, RMCI17,
CPZ18, BBF19]. �e improvement of pu�ing multiple proofs together to save bandwidth in this context has
also appeared in a number of works, including [RMCI17, LM19, BBF19, CFG+20]. �ird-party aggregation
in blockchains has been explored more for signatures than for commitments [DGNW20]. Aggregating
commitment proofs is a natural counterpart to aggregating signatures.

�ere is a long line of work on authenticated data structures in general (going back at least to [Mer88])
and vector commitments speci�cally (�rst formalized in [LY10, CF13]). Constant-size proofs for a subvector
of values were also achieved in [KZG10, �a19]; unfortunately, the binding notion de�ned in [KZG10,
Section 3.4] is not strong enough to preclude openings to two inconsistent subvectors (this work was later
extended by [TAB+20] to achieve the necessary binding notion).

In Table 1, we compare our scheme to other subvector commitment commitments. Because of our
focus on constant-size proofs for multiple values, we omit vector commitment schemes that do not have
this feature [LY10, CF13, LRY16, CPZ18].2

�e starting point for our commitments is the scheme of Libert and Yung [LY10]. We simply augment
it with aggregation algorithms for proofs within the same commitment and across multiple commitments.
Our scheme, like the scheme of [LY10], requires public parameters whose size is linear in the size of the
commi�ed vector. Our public parameters are easy to keep short because of cross-commitment aggregation:
we can split up a long vector into shorter ones and simply aggregate the proofs (although this approach
increases the total size of the commitments, which cannot be aggregated).

Like the scheme of [LY10], our scheme relies on a q-type assumption. In order to prove security of
aggregation, we have to work in the algebraic group model and the random oracle model (see Section 2).
We can reduce these assumptions by lowering e�ciency and/or security requirements (see Appendices A
and B).

Following the work of Libert and Yung, there has been a long line of work on pairing-based vector
commitments, including [CF13, LRY16, LM19], and a parallel line of work on polynomial commitments
(starting with [KZG10]; see [BM+19] for an overview). None of these address aggregation. In Appendix C

2We note that Libert et al. [LRY16] describe an accumulator with a constant-size membership witnesses for multiple values;
in order to convert such an accumulator to a subvector commitment (using the conversion of [BBF19]), it would need to also
support constant-size nonmembership witnesses for multiple values.

4



we show that recent (independent of ours) construction of polynomial commitments with batch opening
by Boneh et al. [BDFG20] also gives vector commitments with aggregation, but with lower e�ciency than
our construction.

In a recent (and independent of ours) work, Campanelli et al. [CFG+20] introduced incremental
aggregation for proofs, which allows unbounded aggregation of already aggregated proofs (e�ectively
making aggregation an associative operation). �ey achieve it for same-commitment aggregation by
modifying hidden-order group constructions of [LM19, BBF19]. Our aggregation is not associative.3
In another recent (and independent of ours) work, Tomescu et al. [TAB+20] proposed pairing-based
commitments with same-commitment aggregation based on the work of [KZG10]; in their scheme, public
parameters needed to verify and update proofs are short.

1.3 Technical Overview of Our Scheme

Our starting point is a pairing-based vector commitment of Libert and Yung [LY10]; the novelty of our
work lies in the aggregation algorithms.

Let (G1,G2,GT ) be a bilinear group of prime order p, along with a pairing e : G1 × G2 → GT and
generators g1, g2, gT = e(g1, g2) for G1,G2,GT respectively. Let ι ∈ Zp be a secret value (known to no
one a�er the initial generation of public parameters). �e public parameters are given by 2N − 1 values
in G1, N values in G2, and one value in GT (which can be easily computed from the others):

gÎą1 , . . . , g
ÎąN

1 , gÎą
N+2

1 , . . . , gÎą
2N

1 ; gÎą2 , . . . , g
ÎąN

2 ; gÎą
N+1

T .

It is important that gÎąN+1

1 is missing in the public parameters.
A commitment to a vector m = (m1, . . . ,mN ) ∈ ZNp is given by raising g1 to a polynomial with

coe�cients given by m (no constant term), evaluated at ι:

C := g
∑N
i=1miÎą

i

1

To reveal mi, the commi�er computes a proof, which has a similar polynomial, but without mi, and with
a shi� so that mi, if it were present, would be the coe�cient of ιN+1 instead of ιi:

πi := g
∑
j 6=imjÎą

N+1−i+j

1 =
(
C/gmiÎą

i

1

)αN+1−i

�e proof can be veri�ed using

e(C, gÎą
N+1−i

2 )
?
= e(πi, g2) · gα

N+1mi
T

Indeed, Libert and Yung [LY10] show that under a q-type assumption, the scheme is binding: namely,
it is hard to �nd a commitment C along with proofs (m0

i , π
0), (m1

i , π
1) with m0

i 6= m1
i satisfying the

above veri�cation equation. �e intuition for binding is quite simple. Note that the adversary does not get
gÎą

N+1

1 , and therefore the coe�cient of αN+1 in the exponent of π, even if adversarially produced, should
be 0. Comparing coe�cients of gιN+1

T on both sides of the veri�cation equation, we have that mi on the
right-hand-side of the veri�cation equation must match mi in C .

3It may be possible to augment our scheme to allow aggregation of already-aggregated proofs for both same-commitment and
cross-commitment cases, using the same hash-and-exponentiate approach as described below for aggregation (this would require
a careful choice of hash inputs and a new security proof). �is approach, even if secure, would not quite achieve associativity, as
the veri�er would need to know the sequence of aggregations.

5



Aggregation: �rst idea. Now, suppose the commi�er would like to reveal multiple values {mi : i ∈ S}
(where S ⊆ [N ]) for a single commitment C via a very short proof πS . A natural idea is to take

πS =
∏
i∈S

πi

which can in turn be veri�ed using

e

(
C,
∏
i∈S

gÎą
N+1−i

2

)
?
= e(πS , g2) · g

ÎąN+1
∑
i∈Smi

T

It is easy to see that this scheme is insecure, in that an adversary can commit to (m1,m2) = (1, 3) and then
provide a valid proof revealing (m1,m2) = (2, 2) for S = {1, 2}. Indeed, if we compare the coe�cients
of gÎąN+1

T on both sides of the veri�cation equation, it is easy to see that the adversary is only bound to∑
i∈Smi and not all of the values {mi : i ∈ S}. More generally, we need to prevent a�acks against

inconsistent reveals for possibly two di�erent sets, so that an adversary cannot, for example, “prove” that
(m1,m2) is (1, 3) and (m2,m3) is (2, 1).
Handling same-commitment aggregation. To get around these a�acks, we introduce additional
“random” scalars ti into the veri�cation equation:

e

(
C,
∏
i∈S

gÎą
N+1−iti

2

)
?
= e(πS , g2) · g

ÎąN+1
∑
i∈Smiti

T

and compute the aggregate proof πS by πS =
∏
i∈S π

ti
i . �e scalars ti are computed by applying a hash

function H on some carefully chosen inputs depending on C, S, {mi : i ∈ S}. We note that a similar idea
appears in the context of aggregating signatures [BDN18].

To get an intuition for how introducing random scalars yields binding, let us once again look at the
coe�cient of gιN+1

T on both sides of the veri�cation equation. Now, the adversary is bound to
∑

i∈Smiti.
A standard argument tells us that for any {mi : i ∈ S} 6= {m′i : i ∈ S}, we have

Pr
[∑
i∈S

miti =
∑
i∈S

m′it
′
i

]
= 1/p

where the probability is over random ti ← Zp. �erefore, if the ti’s are indeed random, then the adversary
is also bound to {mi : i ∈ S}.

To formalize this intuition, we �rst need to model the hash function H as a random oracle [BR93] so
that we can carry out the above probabilistic argument. Furthermore, we need to restrict the adversary to
the so-called algebraic group model [FKL18] (see Section 2 for details), so that we can express adversarially
generated commitments C in terms of public parameters.
Handling cross-commitment aggregation. Now, suppose we have a collection of commitments Cj to
mj = (mj,1, . . . ,mj,N ), along with proofs π̂j for mj [Sj ], each satisfying

e

(
Cj , g

∑
i∈Sj

αN+1−itj,i

2

)
= e(π̂j , g2) · g

ÎąN+1
∑
i∈Sj

mj,itj,i

T

We can again multiply these equations together to obtain:

∏
j

e

(
Cj , g

∑
i∈Sj

αN+1−itj,i

2

)
= e

∏
j

π̂j , g2

 ¡ gιN+1
∑
j

∑
i∈Sj

mj,itj,i

T

6



For the same reason as before, this approach alone does not yield a secure scheme. Instead, we will
need to introduce additional random scalars t′j and use the following aggregate veri�cation equation:

∏
j

e

(
Cj , g

∑
i∈Sj

αN+1−itj,i

2

)t′j
?
= e(π, g2) · g

ÎąN+1
∑
j

∑
i∈Sj

mj,itj,it
′
j

T

where the aggregated proof π :=
∏
j π̂

t′j
j .

2 Preliminaries

Notation Given a (column) vector v = (v1, . . . , vN ), we use v[S] := (vi, i ∈ S) to denote the subvector
indexed by S, and v[−i] to denote v[[N ] \ {i}], i.e., v with vi deleted. For a positive integer N , we denote
the set {1, . . . , N} by [N ].
�eAlgebraic GroupModel (AGM) �e algebraic group model [FKL18] lies between the standard model
and the widely-used generic group model. In AGM, we consider only so-called algebraic adversaries. Such
adversaries have direct access to group elements and, in particular, can use their bit representation, like
in the standard model. However, these adversaries are assumed to output new group elements only
by applying the group operation to received group elements (like in the generic group model). �is
requirement is formalized as follows. Suppose an adversary is given group elements X1, . . . , XN ∈ G1.
�en, for every group element Z ∈ G1 that the adversary outputs, it must also output z1, . . . , zN ∈ Zp
such that Z =

∏N
i=1X

zi
i .

Security Assumption Let G1,G2,GT be multiplicative groups of prime order p with a nondegenerate
bilinear pairing e : G1 ×G2 → GT . Fix generators g1, g2, and gT := e(g1, g2) for the three groups.

We assume that the following variant of weak bilinear Di�e-Hellman exponent problem `-wBDHE∗ (see
[BBG05, BGW05, CKS09] for similar problems for symmetric pairings) is hard:

Input: gÎą1 , g
(Îą2)
1 , . . . , g

(Îą`)
1 ,

g
(Îą`+2)
1 , . . . , g

(Îą3`)
1 ,

gÎą2 , g
(Îą2)
2 , . . . , g

(Îą`)
2 ,

for α $← Zp

Compute: g(Îą
`+1)

1

�e advantage Adv`-wBDHE∗
G1×G2

(A) of an adversary A is de�ned as its probability in solving this problem.
As shown in [BBG05] (for a slight variant), the assumption holds in the generic bilinear group model.
Concretely, for the BLS12-381 pairing-friendly curve with ` = 32, the best a�ack has complexity 2112

[Che06] (more generally, roughly
√
p/`).

�e Random Oracle Model (ROM) Our security proofs are in the random oracle model, formalized in
[BR93]: we model a cryptographic hash function as a truly random function, accessible to all parties only
via oracle queries. We will use two random oracles H and H ′, both with output space Zp.

7



3 De�ning Vector Commitments with Aggregation

We de�ne aggregatable vector commitments in two steps: �rst, we consider aggregation of proofs for a
single commitment; then, we discuss aggregating such same-commitment aggregated proofs into a single
cross-commitment proof.

3.1 Same-Commitment Aggregation

A vector commitment with same-commitment aggregation for message spaceM consists of the following
polynomial-time algorithms Setup,Commit,UpdateCommit,Aggregate,Verify:

• pp ← Setup(1λ, 1N ). Outputs public parameters that will be used by all parties to commit to
message vectors of length N (inputs are given in unary to allow for running time polynomial in
Ν and N ). �e public parameters will be provided as an implicit input to the remaining algorithms,
including the adversary in the security de�nition. Even though the parameters are public, their
generation may involve secret randomness that should not be known to the adversary. How
to generate parameters in a trustworthy manner (which is crucial for security) depends on the
application.

• C ← Commit(m; r). Takes as input a vector m ∈ MN along with randomness r and outputs a
commitment C .

• C ′ ← UpdateCommit(C, S,m[S],m′[S]). Takes as input a commitment C and updates the
positions in S from m[S] to m′[S] to produce a new commitment C ′.

• πi ← Prove(i,m, r). Takes as input an index i ∈ [N ] and (m, r) used in Commit and outputs a
proof πi.

• π̂ ← Aggregate(C, S,m[S], {πi : i ∈ S}). Takes as input a commitmentC , a set of indices S ⊆ [N ]
with the corresponding proofs {πi : i ∈ S} (computed using Prove) and outputs an aggregated
proof π̂.

• b← Verify(C, S,m[S], π̂). Takes as input a commitment C , a set of indices S ⊆ [N ] along with an
aggregated proof π̂, and outputs whether C is a commitment to a message vector consistent with
m[S].

For simplicity of presentation and without loss of generality, we assume that Verify always operates
on aggregated proofs, even for a set of size 1. It should be noted that there may be more e�cient ways to
compute an aggregated proof than via several invocations of Prove followed by a single Aggregate; these
e�ciency improvements, while helpful for performance, do not a�ect our de�nitions. Similarly, there may
be more e�cient ways than invoking Prove to update existing proofs when commitments are updated; we
do not formally de�ne proof updates as a separate algorithm here.
Correctness of opening. For all λ,N,m ∈MN , S ⊆ [N ], we have

Pr


pp← Setup(1λ, 1N )
C ← Commit(m; r)
πi ← Prove(i,m, r), ∀i ∈ S
π ← Aggregate(C, S,m[S], {πi : i ∈ S})
Verify(C, S,m[S], π̂) = 1

 = 1

8



Correctness of updates. For all λ,N,m,m′ ∈ MN , S ⊆ [N ], r such that m[[N ] \ S] = m′[[N ] \ S′],
we have:

UpdateCommit(Commit(m; r), S,m[S],m′[S]) = Commit(m′; r)

Note that in our de�nition, updates are deterministic. Other de�nitions are also possible. See
Section 3.3 for further discussion.
Binding. For every N and every adversary running in time polynomial in Ν, the probability of �nding

C, (π̂0, S0,m0[S0]), (π̂1, S1,m1[S1])

such that

• Verify(C, Sb,mb[Sb], π̂b) = 1 for both b = 0 and b = 1;

• m0[S0 ∩ S1] 6= m1[S0 ∩ S1]

(assuming parameters generated by Setup(1Îť, 1N )) is negligible in Îť.
One can also consider a weaker notion of binding, in which the commitment C must be honestly

computed by Commit (on some, possibly adversarially chosen, messages) rather than chosen arbitrarily
by the adversary. �is notion o�en su�ces in blockchain applications. See Appendix B for details.

3.2 Cross-commitment aggregation

Cross-commitment aggregation adds two algorithms to aggregate proofs across ` commitments :

• π ← AggregateAcross({Cj , Sj ,mj [Sj ], π̂j }j∈[`]) Takes as input a collection ({Cj , Sj ,mj [Sj ] }j∈[`])
along with the corresponding same-commitment-aggregated proofs { π̂j }j∈[`] (computed using
Aggregate) and outputs an aggregated proof π.

• b ← VerifyAcross({Cj , Sj ,mj [Sj ] }j∈[`], π). Takes as input a collection ({Cj , Sj ,mj [Sj ] }j∈[`])
along with a cross-commitment-aggregated proof π, and checks that Cj is a commitment to a
message vector consistent with mj [Sj ] for all j ∈ [`].

We require the same correctness of opening as before, extended to cross-commitment aggregation in
a natural way.

�e binding property also extends naturally: to win, the adversary now needs to �nd

{Cbj }j∈[`b] and (πb, {Sbj ,mb[Sbj ] }j∈[`b]) for b = 0 and b = 1

such that

1. VerifyAcross({Cbj , Sbj ,mb
j [S

b
j ] }j∈[`b], πb) = 1 for both b = 0 and b = 1

2. ∃j0 ∈ [`0], j1 ∈ [`1] : m0
j0 [S0

j0 ∊ S
1
j1 ] 6= m1

j1 [S0
j0 ∊ S

1
j1 ] and C0

j0 = C1
j1 .

As a sanity check, observe that for the special case `0 = `1 = 1, the winning condition stipulates that
j0 = j1 = 1 and C0

1 = C1
1 , matching same-commitment binding, except with VerifyAcross in place of

Verify.
As part of binding, we also need to make sure that a cross-commitment aggregated proof cannot be

used to prove an opening that is inconsistent with a same-commitment opening. Formally, this means this
that for the case of `0 = 1, we allow the adversary to win also if Verify(C0

1 , S
0
1 ,m

0
1[S

0
1 ], π0) = 1, even if

VerifyAcross({C0
1 , S

0
1 ,m

0
1[S

0
1 ]}, π0) = 0.

9



3.3 Hiding

Vector commitments optionally include the hiding property, which we now de�ne. For this paper, we
consider simulation-based statistical security, which stipulates that there exists an e�cient randomized
simulator (Setup∗,Commit∗,Prove∗) with the following properties. Setup∗ outputs pp and a trapdoor
td. Commit∗(; r) takes no inputs except randomness, and outputs a random fake commitment C . Prove∗,
given the trapdoor, an r used to produce a fake C , an index i, and a valuemi, produces a fake proof π. �e
main idea of the de�nition is that fake proofs are statistically indistinguishable from real ones, even given
the commitments, and even if the commi�ed messages are chosen adversarially. �is indistinguishability is
de�ned below. �e intuition is that since fake commi�ing and fake proving doesn’t involve any messages
but the one being proven, it follows that fake commitments and proofs leak no information about other
messages, and therefore, by indistinguishability, neither do real ones. �is intuition is formalized below
via a standard oracle-based de�nition.

Let a stateful real oracle O-real(pp) take two types of queries: a query mj chooses a random rj
and returns Commit(m;rj), while a query (j, i) returns Prove(i,mj , rj). Let a stateful simulated oracle
O-sim(pp, td) respond to the same types of queries as follows: a query mj chooses a random rj and runs
Commit∗(; rj) to get a random fake commitment, while a query (j, i) returns Prove∗(td, rj , i, (mj)i).
Crucially for the hiding property, Commit∗ gets no information about mj , while Prove∗ gets (mj)i but no
information about mj [−i].

�e hiding property states that for every stateful computationally unbounded adversary A, the
following two distributions are at most negligibly far:

[
pp← Setup(1λ, 1N );

output AO-real(pp)

]
,

[
(pp, td)← Setup∗(1λ, 1N );

output AO-sim(pp,td)

]
Note that even though the hiding de�nition does not explicitly refer to aggregated proofs as computed

using Aggregate, it does imply a meaningful security guarantee for aggregated proofs, because they are
results of public computations on existing proofs. For example, an adversary who sees m2,m3 along with
an aggregated proof π{2,3} learns nothing about m1,m4, because the inputs to the aggregation algorithm
include only π2, π3, m2, and m3.

Our updates are de�ned to be deterministic, and thus reveal the relationship between the pre- and post-
update commi�ed vectors. One can additionally de�ne a rerandomization algorithm that, when performed
a�er a deterministic update, will hide this relationship. Our scheme supports such rerandomization (see
Section 4.5). We do not formally address this hiding property.

4 Our Construction

Understanding intuition behind our scheme, described in Section 1.3, will help make sense of the formal
details presented in this section. We use the notation (including pairing groups of order p and random
oracles H,H ′) from Section 2.

Our message spaceM is Zp; we can handle general message spaces {0, 1}∗ by hashing to Zp using a
collision-resistant hash function.

10



4.1 Same-Commitment Aggregation

Here, both Commit and Prove are deterministic.

• Setup(1λ, 1N ). Samples α← Zp and outputs

ga1 = (gÎą1 , . . . , g
ÎąN

1 ),

g
αNa[−1]
1 = (gÎą

N+2

1 , . . . , gÎą
2N

1 ),

ga2 = (gÎą2 , . . . , g
ÎąN

2 )

where
a := (Îą, Îą2, . . . , ÎąN )

In fact, it is su�cient for the prover to hold ga1 , g
αNa[−1]
1 and for the veri�er to hold ga2 , gι

N+1

T =

e(gÎą1 , g
ÎąN
2 ).

Note that Îą must never be known to the adversary.

• Commit(m), for m ∈ ZNp . Outputs

C := gm
>a

1 = g

∑
i∈[N ]miι

i

1

• UpdateCommit(C, S,m[S],m′[S]). Outputs

C ′ := C · g(m
′[S]−m[S])>a[S]

1 = C ¡ g
∑
i∈S(m

′
i−mi)αi

1

• Prove(i,m). Outputs

πi := g
αN+1−im[−i]>a[−i]
1 = g

∑
j∈[N ]−{i}mjα

N+1−i+j

1

Note that anyone can compute gÎą
N+1−ia[−i]

1 for all i ∈ [N ] given pp. If a value mj at index j 6= i

changes m′j , a proof can be updated in a way similar to a commitment: π′ := π · g
(m′j−mj)αN+1−i+j

1 .
If mi changes, then the proof π need not be updated (but the commitment C does).

• Aggregate(C, S,m[S], {πi : i ∈ S}). Outputs

π̂ :=
∏
i∈S

πtii

where
ti = H(i, C, S,m[S])

• Verify(C, S,m[S], π̂). Checks that

e

(
C, g

∑
i∈S ι

N+1−iti
2

)
?
= e(π̂, g2) · g

ÎąN+1
∑
i∈Smiti

T

where ti is the same as in Aggregate.

11



Implementation and E�ciency. We now discuss a few implementation details. We summarize the
performance of our scheme (including algorithms from Section 4.2) in Table 2.

• Setup can be performed securely and e�ciently via a large-scale distributed computation, similar to
[BGM17], but simpler because of the structure of the parameters [Suh19]. �e �rst party chooses ι1

and generates its own public parameters according to Setup; each subsequent party i, in sequence,
chooses a secret Îąi and raises each el";"""date"",""2020-08-25T20:25:44Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2020-08-25T20:25:44Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.19 (TeX Live 2018) kpathsea version 6.3.0""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2020-08-25T20:25:44Z""
""created"",""2020-08-25T20:25:44Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-08-25T20:25:44Z""
""resourceName"",""419.pdf""
""Author"",""""
""producer"",""pdfTeX-1.40.19""
""pdf:docinfo:producer"",""pdfTeX-1.40.19""
""pdf:unmappedUnicodeCharsPerPage"",""9"",""12"",""12"",""19"",""26"",""45"",""33"",""15"",""30"",""22"",""21"",""24"",""27"",""44"",""44"",""62"",""42"",""15"",""14"",""20"",""4"",""14"",""14"",""7"",""7"",""2"",""5"",""25"",""20"",""34"",""12"",""25"",""6""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2020-08-25T20:25:44Z""
""Last-Modified"",""2020-08-25T20:25:44Z""
""dcterms:modified"",""2020-08-25T20:25:44Z""
""title"",""""
""Last-Save-Date"",""2020-08-25T20:25:44Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2020-08-25T20:25:44Z""
""meta:save-date"",""2020-08-25T20:25:44Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.19 (TeX Live 2018) kpathsea version 6.3.0""
""Content-Length"",""653672""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""33""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""2070"",""2617"",""3402"",""3236"",""2543"",""2049"",""2017"",""2155"",""2070"",""2588"",""920"",""2114"",""1346"",""1333"",""2008"",""1644"",""1841"",""2550"",""2701"",""1769"",""2784"",""1986"",""2139"",""2154"",""2384"",""2640"",""2020"",""1170"",""1531"",""2062"",""1422"",""1045"",""597""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-08-25T20:25:44Z""
";https://scholar.google.ch/scholar?start=880&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098848-299;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;[CITATION][C] New Constructions of Traceable Range Proofs: Towards Multiple Regulation and Joint Regulation.;W Li, L Chen, X Lai, X Zhang, J Xin ; IACR Cryptol. ePrint Arch., 2020;;null;Autres articles;;null;;;;https://scholar.google.ch/scholar?start=840&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098747-66;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;[PDF][PDF] ?????? ??? ??????????? ??? Blockchain ??? ????? ???? ??? ?? ?????????? ???? ?????????? ??????? ?????????? ?????? ??????? ??? ???????????? ????????;? ????????????? ;2020 dspace.lib.ntua.gr;;"… ???????? ?? ???????????? ??? Blockchain, ???? ???? ?? ??? ?????? ?? ????????. ??????, ???

??? ??????????? ?? ?? ???? ??? ??? ?????? ??? ????????? ??? ??????? ?? ??????????? ??

?????????? Web Services (?????? ?? oracles), ??? ?? ????????? ?? …";Autres articles;Version HTML;[PDF] ntua.gr;https://dspace.lib.ntua.gr/xmlui/bitstream/handle/123456789/52226/%CE%A4%CE%B5%CF%87%CE%BD%CE%BF-%CE%9F%CE%B9%CE%BA%CE%BF%CE%BD%CE%BF%CE%BC%CE%B9%CE%BA%CE%AC%20%CE%A3%CF%85%CF%83%CF%84%CE%AE%CE%BC%CE%B1%CF%84%CE%B1%20-%20%CE%94%CE%B9%CF%80%CE%BB%CF%89%CE%BC%CE%B1%CF%84%CE%B9%CE%BA%CE%AE%20%CE%95%CF%81%CE%B3%CE%B1%CF%83%CE%AF%CE%B1%20%CE%A7%CE%BF%CE%BD%CE%B4%CF%81%CE%BF%CE%B3%CE%B9%CE%AC%CE%BD%CE%BD%CE%B7%20%CE%95%CF%85%CE%B8%CF%85%CE%BC%CE%AF%CE%BF%CF%85%20v.4.6.1-FINAL.pdf?sequence=1;;;https://scholar.google.ch/scholar?start=610&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098884-374;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;[PDF][PDF] Watermarking Public-key Cryptographic functions;A Samari ;2020 di.uoa.gr;;"… may be suitable, but not only, for a realization on top a blockchain system and … Unremovability:

No PPT adversary A after querying the Challenge, Corrupt and Detect oracles, should be … the

marked circuits that the adversary has received by issuing queries to the Corrupt oracle …";;;[PDF] uoa.gr;https://www.di.uoa.gr/sites/default/files/documents/grad/phdbook/Aikaterini%20Samari.pdf;;;https://scholar.google.ch/scholar?start=920&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098813-215;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Echidna: effective, usable, and fast fuzzing for smart contracts;G Grieco, W Song, A Cygan, J Feist… ; Proceedings of the 29th …, 2020  dl.acm.org;;"… Rather than relying on a fixed set of pre-defined bug oracles to detect vulnerabilities during fuzzing

campaigns, Echidna supports three types of proper- ties: (1) user-defined … Execution on the

Ethereum blockchain requires use of gas, which has a price in cryptocurrency …";Cité 8 fois;;[PDF] researchgate.net;https://www.researchgate.net/profile/Josselin-Feist/publication/343048222_Echidna_effective_usable_and_fast_fuzzing_for_smart_contracts/links/5f7d8e26458515b7cf6c70fc/Echidna-effective-usable-and-fast-fuzzing-for-smart-contracts.pdf;;;https://scholar.google.ch/scholar?start=760&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098839-273;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;[PDF][PDF] Efficient traceable ring signature scheme without pairings;K Gu, X Dong, L Wang ; Advances in Mathematics of …, 2020  aimsciences.org;;"… in Crypto 92) … Setup, (T RK, pkR, spk) ?System-Setup(1k), and then T RK and pkR are passed

to A. (2)Queries: A makes queries to the following oracles for polynomially many times: •

Register-User Key(): Given the public parameters T RK, the oracle out- puts the …";Cité 13 fois;Les 3 versions;[PDF] aimsciences.org;https://www.aimsciences.org/article/exportPdf?id=5bc02268-e856-4b6d-88e3-6c16820e1c1b;;"""X-Parsed-By"",""org.apache.tika.parser.EmptyParser""
""resourceName"",""exportPdf""
""language"",""""
""Content-Type"",""multipart/form-data; charset=utf-8""
";https://scholar.google.ch/scholar?start=820&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098853-310;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Non-repudiation storage and access control scheme of insurance data based on blockchain in IPFS;J Sun, X Yao, S Wang, Y Wu ; IEEE Access, 2020  ieeexplore.ieee.org;;"… J. Sun et al.: Non-Repudiation Storage and Access Control Scheme of Insurance Data Based

on Blockchain in IPFS … key sk, at this time, the adversary A just know the public key pk, and mk

is only known by the challenge C. • Phase1: The adversary A queries Trap oracle for a …";Cité 3 fois;;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/6287639/8948470/09174837.pdf;"
		
	";"""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""dc:title"",""IEEE Xplore Full-Text PDF:""
""Content-Encoding"",""UTF-8""
""resourceName"",""09174837.pdf""
""language"",""es""
""Content-Length"",""2565""
""title"",""IEEE Xplore Full-Text PDF:""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.ch/scholar?start=850&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098888-382;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Blockchain-Based Juridical AI Registration System;MG Jeon, C Hwang, HS Na ; Journal of Digital Convergence, 2020  koreascience.or.kr;;"… (2018. June). Do you need a Blockchain?. 2018 Crypto Valley Conference on Blockchain

Technology (CVCBT), 45-54. [13] H. Tang, Y. Shi & P. Dong. (2019 … [14] BK Kwon. (2019).

Commercial Blockchain, What is Different … [15] HashNet(Online). Oracle problem in Blockchain …";Autres articles;Version HTML;[PDF] koreascience.or.kr;https://www.koreascience.or.kr/article/JAKO202015762902709.pdf;"
블록체인 기반 AI 법인 등록제

전민규1, 황지연1, 나현숙2*

1숭실대학교 컴퓨터학부 학생, 2숭실대학교 컴퓨터학부 교수

Blockchain-Based Juridical AI Registration System

MinGyu Jeon1, Chiyeon Hwang1, Hyeon-Suk Na2*

1Student, School of Computer Science and Engineering, Soongsil University
2Professor, School of Computer Science and Engineering, Soongsil University

요  약  AI 기술이 고도화됨에 따라 국내외에서 AI 로봇에 대한 법적 지위 및 규제 문제, 로봇등록제의 필요성이 대두되

고 있다. AI 로봇의 형태 및 활동범위는 더 이상 한 국가내에 놓여진 하드웨어에 머물지 않을 것이므로, AI 로봇에 대한 

정의 및 규제는 소프트웨어를 포함시킨 포괄적 개념으로 확장되어야하며, 이들에 대한 정보도 국제적으로 각국 정부가 

안전하게 관리하고 공유할 수 있는 형태로 정의되어야한다. 본 연구는 이러한 관점에서 ‘AI 로봇’을 하드웨어와 소프트

웨어를 포괄하는 AI 법인이라는 개념으로 확장시키고, (가칭) Juridical AI Chain이라는 허가형 블록체인을 이용해 AI 

법인 등록제를 운영하는 방안을 제시한다. 블록체인은 각국 정부기관들의 관리 및 공유가 가능한 분산형 공유 장부이므

로, 블록체인 기반 등록제의 운영은 AI 로봇의 상용화가 초래할 범세계적 문제들에 효과적으로 대처할 수 있는 방안이 

될 것이다.

주제어 : 블록체인, 인공지능, 로봇 규제, 정보시스템, 법인

Abstract  With the advancement of AI technology, legal status and regulation issues for AI robots, and 

the necessity of a robot registration system are emerging. Since the shape and activity area of AI robots 

will no longer be limited to hardware in one country, the definition and regulation of AI robots should 

be expanded to a comprehensive concept including software, and information about them should be 

securely managed and shared by governments around the world. From this perspective, we extend 'AI 

robot' to the concept of Juridical AI encompassing hardware and software, and propose a method to 

operate the Juridical AI registration system using a permissioned blockchain called Juridical AI Chain. 

Since blockchain is an internationally distributed database, operating such AI registration system based 

on the blockchain will be a way to effectively cope with the global problems caused by the 

commercialization of AI robots.

Key Words : Blockchain, Artificial Intelligence, Robot regulation, Information System, Corporation

*A preliminary version of this paper was presented at The KIPS Fall Conference 2019, and the work was supported by the 

National Research Foundation of Korea(NRF) grant (No. 2016R1D1A1B03931879).

*Corresponding Author : Hyeon-Suk Na(hsnaa@ssu.ac.kr)

Received February 12, 2020 Revised   April 28, 2020

Accepted May 20, 2020 Published May 28, 2020

Journal of Digital Convergence

Vol. 18. No. 5, pp. 17-23, 2020
ISSN 2713-6434 / eISSN 2713-6442

https://doi.org/10.14400/JDC.2020.18.5.017



디지털융복합연구 제18권 제5호18

1. 서론

2017년 2월 EU 본회의는 ‘로봇과 AI의 법적 지위, 개

발, 활용에 대한 결의안’을 통과시켰는데, 로봇 제작자와 

사용자를 위한 법적·윤리적 표준을 마련하고 해당 업무

를 총괄할 EU 로봇담당국을 신설할 것을 촉구했다. 또한 

로봇이 인간에게 위협을 가하지 않도록 제작자가 ‘로봇3

원칙’ 및 ‘킬스위치’(비상시 로봇을 즉각 멈출 수 있는)를 

탑재할 것을 권고했다[1-4]. 이는 로봇 개발자, 생산자, 

사용자의 행위에 대한 가이드라인과 법제도적 규제 외에

도 기술적 프레임워크, 아키텍처 및 알고리즘에 대한 규

제 필요성도 강조한 것이다. 같은 해 7월 국내에서는 ‘로

봇기본법안’이 발의되었는데, 로봇 설계자․제조자․사용자

가 준수해야 할 윤리 원칙을 규정하고, 로봇소유자는 관

할 시·도에 로봇을 등록하고 산업통상자원부장관은 효율

적 로봇등록 및 관리를 위해 정보시스템을 구축하는 ‘로

봇등록제’를 제안하고 있다[4-6].

세계 각국이 이렇게 로봇규제 및 제도 마련에 분주하

지만, 이들 규제와 제도는 하드웨어로서의 로봇, 국내문

제의 해결에만 국한되어 있다는 한계가 있다. AI 로봇의 

형태 및 활동영역은 더 이상 국경과 하드웨어의 범주로 

규정할 수 없는 상황에서, AI 로봇에 대한 정의 및 규제

는 소프트웨어를 포함하는 개념으로 확장되어야 하며 국

제적인 AI 로봇 정보시스템도 준비되어야 한다. 

본 연구는 이러한 관점에서 ‘AI 로봇’을 하드웨어와 소

프트웨어를 포괄하는 AI 법인이라는 개념으로 확장시키

고, 기능적 복잡성에 따라 UnitAI와 AI 법인으로 분류한

다. 또한 각국 정부간 AI 정보 공유·공조를 위해 허가형 

블록체인-(가칭) Juridical AI Chain (또는 JAC)- 구축

과 AI 법인 등록제 운영을 제안하며, 운영의 절차 및 방

법론도 제시한다. 

블록체인 기반 AI 법인 등록제의 강점은 다음과 같다. 

첫째, AI 정보는 각국 정부가 공동 관리, 공유하면서도 

시스템적 보안성 및 안정성을 가져야한다. 따라서 데이터 

위변조가 불가하고 단일 공격지점이 없는 블록체인은 AI 

정보를 가장 안전하게 관리할 수 있는 시스템을 제공한

다. 둘째, 등록정보의 유효성 검증과 각종 승인요청 기록

들은 블록체인에 기록되므로, 악용하는 사용자 및 시스템

에 대한 추적, 통제가 가능하며, AI를 이용한 각종 국제 

범죄들에 효과적으로 대처할 수 있다. 셋째, 분산형 공유 

장부인만큼, 특정 국가에서 AI를 군사적․경제적 목적으로 

악용하거나 조작할 위험도 미연에 예방할 수 있다.

2장에서 AI 로봇 관련 국내외 규제 및 법제화 현황, 

국내에서 발의된 로봇등록제 법안의 내용을 요약하고, 3

장및 4장에서는 허가형 블록체인 JAC를 이용해 AI 법인 

등록제를 운영할 수 있는 절차 및 방법을 기술한다. 5장

에서는 본 연구의 의의와 한계를 논한다.

2. AI 로봇 관련 국내외 동향

2.1 자율주행차

국내외에서 AI 관련 기술의 발전과 상용화, 법제화가 

가장 빠르게 진행되고 있는 분야는 자율주행차이다. 자율

주행차는 자율주행의 기술 단계별 안전기준과 검증기준 

마련뿐만 아니라, 자율주행 시 운행주체에 대한 정의, 교

통사고 발생 시 민형사상 책임 문제, 보험 제도, 개인정보 

수집과 이용에 관한 문제 등이 종합적으로 검토되어야 

한다[7,8]. 미국, 영국, 일본 등에서는 자율주행차의 시험

운행에 대한 안전규제와 운행규정, 보험 규정 및 교통사

고 시 책임 소재 문제에 대한 법제도를 마련하고 있다[7]. 

국내에서도 2016년부터 ‘자율주행차의 법적지위나 임시

운행허가를 위한 근거조항’을 시행하고 있고, 2020년 1

월 레벨3 (부분 자율주행) 자율주행차의 안전기준 제정, 

2021년 레벨3 출시, 2024년 레벨4 (조건부 완전 자율주

행) 시범 운행과 완전자율을 위해 법․제도․인프라 완비의 

계획을 갖고 있다[9,10].

2.2 EU의 AI 로봇법

2014년 EU 집행위원회는 ‘로봇법’ 프로젝트[1,3]의 

일환으로 로봇과 인간의 법률적 관계에 대한 ‘로봇규제 

가이드라인’을 도출했다. 자율주행차, 수술로봇, 로봇인

공기관, 돌봄로봇 등 4가지 로봇기술의 윤리적, 법률적 

분석을 통해, 인간의 건강과 안전, 소비자, 환경, 법적 책

임, 지식재산권, 개인정보보호, 로봇의 법적 인격 부여문

제 등의 이슈에 대한 논의를 담았으며, AI 로봇의 설계자․

제조자․사용자에 대한 윤리적․법제도적 규제뿐만 아니라 

기술적 프레임워크 또는 아키텍처 차원의 규제와 인증시

스템의 필요성을 제기했다[2,3].

2017년 본회의에서 통과된 ‘로봇과 AI의 법적 지위, 

개발, 활용에 대한 결의안’은 EU 로봇담당국 (로봇 제작

자 및 사용자를 위한 법적·윤리적 표준 마련과 해당 업무

를 총괄) 신설을 촉구하고, 로봇이 인간에게 위협을 가하

지 않도록 비상시 로봇을 즉각 멈출 수 있는 ‘킬스위치’를 

탑재해야 함을 권고하고[3], ‘로봇3원칙’-① 로봇은 인간

을 해칠 수 없다. ② 1항에 위배되지 않는 한 인간의 명



블록체인 기반 AI 법인 등록제 19

령에 복종한다. ③ 1항, 2항에 위배되지 않는 한 자기 스

스로도 지켜야 한다-를 규정했다[4].

2.3 로봇기본법

2017년 7월 박영선 의원을 대표로 로봇기본법이 발

의되는데, 로봇의 설계자․제조자․사용자가 준수해야 할 윤

리 원칙을 규정하고, 로봇소유자는 관할 시·도에 로봇을 

등록하고 산업통상자원부장관은 로봇등록정보의 효율적 

관리를 위한 정보시스템을 구축하도록 하는 ‘로봇등록제’ 

규정을 포함하고 있다[4-6]. 제23조는 로봇의 결함으로 

인한 생명·신체 또는 재산에 대한 손해에 대해 로봇제조

자의 손해배상책임을 규정하고 있고, 로봇제조자를 알 수 

없는 경우에는 로봇공급자가 그 책임을 부담하도록 하고 

있다. 제24조는 로봇설계자 및 제조자가 로봇사용자의 

권리를 보호하기 위한 기술적·관리적 방안을 고려하도록 

하고, 로봇사용자의 권익보호를 위하여 로봇사용과 관련

한 정보의 처리절차 등을 알기 쉽게 기재하고 설명하도

록 규정하고 있다[6].

3. 블록체인 기반 AI 법인 등록제

AI 프로그램을 내재한 모든 소프트웨어․서비스․하드웨

어․시스템은 그것이 수행하는 기능의 복잡성에 따라 

Unit AI 또는 Juridical AI로 나뉠 수 있는데, 여기서는 

모두 ‘시스템’ 또는 ‘AI 법인’으로 통칭한다. 

Fig. 1. Permissioned blockchain: Juridical AI Chain

UnitAI는 기본적이고 낮은 난이도의 기능을 담당하는 

최소 단위의 AI로서, 광학문자인식(OCR), 음성인식, 생

체인식, 최적 경로 탐색 등과 같이, 높은 성공률로 상용화

되어있는 기반 기술들을 지칭한다. Juridical AI는 순찰 

AI, 비서 AI, 소방수 AI, 쇼핑 AI, 자율주행차 등과 같이, 

여러 Unit AI들의 복합체로서 주어진 상황을 실시간으로 

판단하고 높은 난이도의 업무를 수행하도록 고도로 훈련

된 AI 시스템들을 말한다.

제안하는 AI 법인 등록제는 UnitAI와 Juridical AI에 

대한 정보를 Fig.1과 같은 허가형 블록체인 Juridical AI 

Chain(JAC)을 통해 등록, 관리, 통제하는 제도로서, 여

기서는 전체적인 체계만을 개괄하고, 자세한 절차, 방법, 

기술적 명세는 4장에서 기술한다.

3.1 허가형 블록체인 Juridical AI Chain

AI 법인 등록제를 블록체인 기반으로 운영하는 것은 

필연적인 선택인데, 보안성, 안전성, 국제적 분산 공유 장

부로서의 기능 때문이다. AI 법인 정보시스템에서는 시

스템의 안정성과 보안성이 매우 중요하다. 중앙 서버는 

단일 공격지점을 갖기 때문에 데이터 조작과 해킹에 취

약한 반면, 블록체인은 분산 공유 장부이므로 데이터 위

변조가 불가하고 단일 공격지점이 없어 시스템적 보안성

과 안정성이 높다. 또한 AI 기술이 고도화되고 상용화되

면 AI의 활동영역은 범세계적일 것이므로 인증 정보는 

국가간에 공동 관리·공유될 수 있어야 한다.

블록체인 JAC는 국제적 합의체에 의해 네트워크 참가

및 노드별 권한 설정을 할 수 있는 허가형 블록체인이어

야 하는데, AI 제작자, 정부, 사용자 등 네트워크 참가자

간의 권한 및 역할이 분명히 구분되어야하기 때문이다. 

개발사가 AI 로봇을 생성하고 정부의 승인을 요청하면, 

각국 정부는 승인 요청된 AI 로봇의 기능을 테스트 및 인

증하며, 정부간에도 인증 정보가 공유 및 합의되어야 한

다. 허가형 블록체인에서 트랜잭션을 승인, 검증하고 블

록을 생성하며 원장과 스마트 계약을 유지하는 역할을 

하는 피어(Peer) 노드[11]는 각국 정부가 운영해야 한다. 

3.2 AI 법인 등록제 구성원 및 역할

JAC 기반 AI 법인 등록제가 운영되는 체계는 Fig.2와 

같다. 구성원은 관리자인 각국 정부, AI 로봇을 제작하여 

정부에 허가 및 인증을 요청하는 개발 회사, JAC를 통해 

AI 법인이 인증된 것인지를 검증하는 사용자(가게, 인간, 

시스템 등)가 있다. 

각국 정부는 JAC의 피어 노드로서 블록체인 데이터의 

원장 및 스마트 계약을 지속적으로 업데이트하고 관리할 

의무가 있다. 또한 개발사에 의해 승인 요청된 AI 법인의 

기능을 검증한 후 JAC에서 유효화하는 절차를 담당한다.



디지털융복합연구 제18권 제5호20

Fig. 2. Juridical AI Registration System

AI 로봇 제작사는 JAC의 네트워크 노드로서 읽기의 

권한뿐만 아니라 AI 법인 객체를 생성할 수 있는 일부 쓰

기 권한을 부여받는다. 원칙적으로 누구나 AI 법인 개발

사의 권한을 요청해 얻을 수 있다. AI 로봇을 제작하고 

JAC에 AI 법인을 생성한 후, 정부에 AI 법인의 허가와 

인증을 요청하는 트랜잭션을 발신한다(4.1~4.2절 참고).

사용자는 가게, 인간, 기관은 물론이고 임의의 프로그

램 혹은 시스템이다. 예를 들어 자율주행차를 감시하는 

교통 감시 AI 또는 시스템이 사용자일 수 있다. 사용자는 

JAC를 통해 해당 AI 법인에 모든 정보-허가된 것인지, 

인증 받은 기능과 업데이트 이력, 버전 정보 등-를 확인

할 수 있다(4.3절 참고). 

4. 블록체인 기반 AI 로봇등록제 운영 

이제 JAC를 이용해 AI 법인을 등록, 인증, 통제하는 

절차와 방법, AI 법인의 인증 정보와 기술적 명세를 

Solidity 기반으로 살펴본다. 개방형1) 블록체인인 이더

리움용 Solidity 예시들은 허가받은 노드만이 참가하는 

허가형 블록체인 JAC에서 동일하게 구현 가능하다.

4.1 AI 법인의 생성 및 인증

AI 법인은 기술적 복잡도에 따라 Unit AI와 Juridical 

1) 개방형(public)/허가형(permissioned) 블록체인: 블록체인은 

개방형과 허가형으로 나뉘는데[12,13], 누구나 블록체인 네트

워크에 참여할 수 있으면 개방형, 운영자의 허가를 받아야만 

참여가능하면 허가형이다. 비트코인, 이더리움, 이오스 등 대중

에게 알려진 거의 모든 블록체인은 개방형이며, 금융, 유통 등

의 기업체가 사용하는 하이퍼레저 패브릭은 허가형 블록체인

이다[14].

AI로 나뉘고, JAC에 Fig. 3와 같은 구조체 배열로 저장

되며 구조체 형식은 Fig. 4와 Fig. 6과 같다. 개발사는 

JAC에 Unit AI 또는 Juridical AI를 생성할 수 있는데, 

둘 다 정부의 테스트를 거쳐 JAC에서 유효화(인증)되어

야만 사용될 수 있고, 이 트랜잭션에 의해 인증된 시각 

및 인증기관의 블록체인 주소도 기록된다.

  UnitAI_form[] public UnitAIs;

  JuridicalAI_form[]public JuridicalAIs;

Fig. 3. Array declaration for Unit AI and Juridical AI

4.1.1 Unit AI 

Unit AI는 기본적이고 낮은 난이도의 기능을 담당하는 

최소 단위의 AI 시스템으로서, 광학문자인식(OCR), 

음성인식, 생체인식, 최적 경로 탐색 등과 같이, 높은 

성공률로 상용화되어있는 기반 기술을 위한 범주이다. 

  struct UnitAI_form{

       bool testSuccess;

       string name;

       string description;

       address owner;       

       address tester;

       uint256 fee;

   }

Fig. 4. Structure declaration for Unit AI

Unit AI는 JAC에 [Fig. 4]와 같은 구조체로 저장된다. 

Solidity 언어로 기술된 구조체 각 범주들의 의미와 역할

은 다음과 같다.

(1) testSuccess: 정부의 테스트를 거쳐 사용 인증을 받

았는지 여부를 저장하는 변수이다. 개발회사가 Unit 

AI를 처음 생성할 때는 False 값을 가지며, 이 값이 

False인 한 해당 Unit AI는 사용할 수 없다. 정부가 

트랜잭션을 통해 이 값을 True로 변경해주면 유효화

되며, 이 값을 변경할 수 있는 권한은 인증을 담당하

는 정부 기관만이 갖는다.

(2) name: Unit AI의 이름을 저장하는 변수이다. 

(3) description: Unit AI의 버전과 설명이 저장된다. 

AI가 업데이트될 때마다 정부의 인증을 다시 거쳐야 

하며, 블록체인 상에 등록된 버전과 인증 받은 기능

에 대한 설명도 함께 업데이트되어야 한다. 따라서 



블록체인 기반 AI 법인 등록제 21

유효성 검증은 사용하려는 AI의 버전 및 기능이 유

효한지 대조하는 과정을 포함한다.

(4) owner: Unit AI 개발사의 블록체인 주소를 저장한다.

(5) tester: 인증을 위한 테스트를 시행한 정부 기관의 블

록체인 주소를 저장한다. 

(6) fee: Unit AI의 사용료를 정할 수 있다. fee가 0이면 

오픈 소스처럼 자유롭게 사용할 수 있으며, fee가 0

이 아니면 해당 Unit AI를 사용하여 서비스를 하거

나 Juridical AI에 포함시킬 때 fee를 지불해야한다. 

해당 fee는 owner에 저장되어있는 블록체인 주소로 

지급된다.

  mapping(address -> mapping(uint256 -> 

  bool)) Unitcerficiate; 

Fig. 5. Map declaration for system including Unit AI

[Fig. 5]에서 정의된 UnitCertificate는 Unit AI를 사

용하고 있는 시스템들을 관리하기 위해 이중 map 형태

로 저장한 배열이며 JAC 내에 전역변수로 저장된다. 어

떤 한 Unit AI를 내재한 시스템은, 내재한 Unit AI의 ID

값에 True를 매핑하고, 맵핑한 것은 다시 시스템의 블록

체인 주소와 맵핑되어 저장된다. 이것은 추후 해당 시스

템이 유효성 검증을 받을 때 검색에 활용된다.

4.1.2 Juridical AI

AI가 실생활에 활용되기 위해서는 다양한 Unit AI가 

융합된 형태가 필수적이다. 예를 들어 하나의 순찰 AI가 

가능하기 위해서는 범인의 얼굴을 인식하는 생체인식 

Unit AI와 로봇의 직립보행을 도와주는 Unit AI, 일정 

경로를 순찰할 수 있는 내비게이션 Unit AI가 결합되어

야 한다. Juridical AI는 순찰 AI, 비서 AI, 소방수 AI,  

쇼핑 AI, 자율주행차 등과 같이, 여러 Unit AI들의 복합

체로서 주어진 상황을 실시간으로 판단하고 높은 난이도

의 업무를 수행하도록 고도로 훈련된 AI 시스템들의 범

주이다. Unit AI들의 조합에 따라 다양한 Juridical AI가 

탄생할 수 있으며, 복잡한 활동을 수행하기 때문에 다양

한 법적 책임 문제가 발생할 수 있다. 따라서 Juridical 

AI는 법인으로서 등록되어 관리되고 제어되어야 하며, 

부품으로 참여한 모든 Unit AI의 리스트 또한 필요하다. 

JAC에 Fig. 6과 같은 구조체로 저장되는데, Unit AI

에 없던 항목들의 의미와 역할은 다음과 같다.

(1) UseAllowed: 대부분의 인증 받은 Juridical AI들은 

사용에 제한이 없지만, 군인이나 경찰 같은 특수한 

Juridical AI는 인증뿐만 아니라 사용 시에도 매번 정

부의 허가가 필요할 수 있다. 

(2) aiCombinations: Juridical AI는 하나 이상의 Unit 

AI를 이용할 수 있다. Juridical AI가 처음 생성될 

때, 이용되는 모든 Unit AI들의 ID를 이 배열에 입력

한다. 기존 Juridical AI에 새로운 Unit AI를 추가하

기 위해서는 정부의 테스트와 인증을 다시 받아야 하

고, 추가된 Unit AI의 ID가 이 배열에 추가된다. 

Juridical AI를 내재한 시스템이 업무 수행 전에 유

효성 검증 또는 임무수행 승인을 받을 때 

aiCombinations에 저장되어있는 Unit AI의 ID를 

통해 Unit AI를 검색하고, UnitCertificate에 시스

템의 주소가 해당 Unit AI를 사용하는 것으로 등록

되어있는지 확인하는 작업을 거친다.

  mapping(address -> mapping(uint256 -> 

  bool)) JuridicalCertificate; 

Fig. 7. Map declaration for system including Juridical AI

Fig. 7의 JuridicalCertificate는 UnitCertificate와 

같은 역할을 하는 배열이다. 여기에 저장되어있는 시스템

의 주소는 aiCombinations에 저장되어있는 Unit AI들

의 ID값과 시스템의 주소를 이용하여 UnitCertificate

에도 저장된다.

4.2 AI 법인의 테스트 및 인증

AI 법인의 인증 과정은 다음과 같다. 

- 개발사가 AI 법인을 JAC에서 생성한 후 정부의 테스트 

및 인증을 요청한다. AI 법인의 owner 변수에 개발자 

  struct JuridicalAI_form{

       bool testSuccess;

       bool UseAllowed;

       string name;

       string description;

       address owner;       

       address tester;

       uint256 fee;

       int[] aiCombinations;

   }

Fig. 6. Structure declaration for Juridical AI



디지털융복합연구 제18권 제5호22

혹은 제작사의 주소가 입력되어야하기 때문에, 정부의 

가이드라인을 따르지 않는 개발자와 제작사는 정부가 

인증 거부를 통해 통제할 수 있다.

- 테스트와 인증은 AI 법인의 목적에 부합하는 정부 기

관이 수행하는 것이 바람직하다. 예를 들어, 군집 드론 

주행 Juridical AI는 국방부에서, 자율주행차는 국토부

에서 담당해야 한다. 

- 인증받아 사용하던 AI 법인을 업데이트하기 위해서는 

다시 테스트와 인증을 받아야 한다. 이 경우, 버전과 

설명을 기입하는 description이나 aiCombinations

를 포함해 다른 변수들도 변경될 수 있다.

- 테스트를 통과하면 인증기관이 JAC를 통해 해당 법인

의 testSuccess를 True 값으로 변경함으로써 인증의 

효력을 갖게 되며, 이때 승인 시각과 승인 기관의 블록

체인 주소도 JAC에 자동으로 기록된다. 이러한 기록은 

블록체인을 통해 각국 정부는 물론이고 모든 네트워크 

노드에게 공유된다.

4.3 AI 법인의 행동 추적 및 체인 기록

JAC는 AI 법인 혹은 AI 법인을 내재한 시스템을 등록

하고 이들의 가상 세계에서의 행동을 기록함으로써 추적․

제어하려는 기술이다. 블록체인을 통해 물리적 세계에서

의 AI의 행동을 정확히 반영하고 통제하는 것은 불가능

한 일이다(오라클문제[15]). AI 법인의 생성, 테스트 요

청, 인증 결과, 업데이트 이력들은 앞에서 기술한 바와 같

이 JAC에 자동으로 기록되고 국제적으로 공유된다. 그 

외에 JAC에 상시적으로 기록되는 정보는 인증 유효성 검

증 이력이 있다. 이 기록은 AI가 언제 어떤 사용자를 위

해서 무슨 행동을 수행하려고 하였는지에 대한 정보를 

제공하므로, AI가 발생시킨 문제를 추적하고 해결하는데 

필수적이며 JAC를 통해 AI 법인의 가상 행동을 인증된 

범위로 제한, 통제하는 것을 가능케 한다.

사용자의 시스템(혹은 애플리케이션)이 JAC를 통해 

AI 법인 인증의 유효성을 검증하는 과정은 다음과 같다. 

먼저 시스템의 블록체인 주소, 사용하려는 Juridical AI

의 ID와 수행하려는 행동에 필요한 Unit AI의 ID들을 

JAC에 보낸다. 블록체인은 받은 정보를 통해 수행하려는 

행동과 해당 Juridical AI의 인증받은 기능 리스트가 일

치하는지를 aiCombinations를 통해서 확인한다. 

Juridical AI의 testSuccess가 True값을 갖는지, 해당 

시스템의 AI 코드의 버전과 Juridical AI에 description

에 저장되어 있는 버전이 일치하는지 확인하게 된다. 또

한 해당 시스템이 Juridical AI를 내재한 시스템으로 등록

되어 있는지를 JuridicalCertificate와 UnitCertificate

에서 시스템의 주소와 Juridical AI의 ID값을 이용하여 

검색하게 된다.

이러한 과정을 거친 후 해당 시스템이 활동을 수행할 

수 있는지에 대한 결과를 사용자의 시스템에게 돌려준다. 

이때 결과가 참이면 행동을 수행할 수 있다. 만약 결과가 

거짓이면 킬스위치 작동과 같은, AI의 행동을 제어할 수 

있는 하드웨어 혹은 소프트웨어적인 방법이 구현되어야 

한다. 

4.4 JAC 관리 및 운영

JAC는 Fig. 1과 같이 각국의 정부가 AI 법인과 그것

을 사용하는 사용자 및 시스템에 대한 데이터를 관리한

다. AI 법인의 테스트와 인증, 사용자 및 시스템 데이터

는 블록체인을 통해 각국의 정부기관들이 탈중앙적이고 

투명하게 공유하기 때문에 어떤 한 국가 혹은 기관이 임

의로 조작할 수 없다. AI 법인 생성과 인증 요청, 업데이

트 이력이 기록되므로 가이드라인을 따르지 않는 개발자

와 제작사는 정부가 인증 거부를 통해 통제할 수 있다. 

AI 법인의 유효성 검증 및 임무수행 승인을 요청한 기록

들도 블록체인에 저장되기 때문에 악용하는 사용자 및 

시스템에 대해서도 추적을 통해 통제 가능하다. 따라서 

AI 로봇을 이용한 각종 국제 범죄들에 효율적으로 대처

할 수 있으며, 특정 국가에서 군사적․경제적 목적으로 AI 

로봇을 악용하거나 조작하는 위험도 막을 수 있다.

5. 결률

본 연구에서는 머지않은 미래에 도입될 AI 로봇 규제

와 등록제의 운영을 허가형 블록체인 기반으로 수행하는 

AI 법인 등록제를 제안했다. AI 법인 개념을 도입하고, 

허가형 블록체인 Juridical AI Chain에 이들을 기록하

고 운영하는 절차 및 방법론도 제시했다. 보안성과 안전

성이 뛰어난 블록체인을 이용함으로써, 각국 정부가 AI 

정보를 공동으로 관리, 공유하면서도, 악용하는 사용자 

및 시스템에 대한 추적, 통제를 통해 각종 국제 범죄들에 

효과적으로 대처할 수 있는 방안이 된다. 

제안된 블록체인 기반 AI 법인 등록제가 실제로 도입

되고 상용화되기 위해서는 선행되어야 할 다양한 기술적 

요소들이 있다. 첫째, 각종 AI 로봇이 상용화될 수 있을 



블록체인 기반 AI 법인 등록제 23

만큼 충분히 학습되었는지 등에 대한 테스트 기준, 해당 

테스트를 자동화할 수 있는 방법이 필요하다. 둘째, AI 

법인이 시스템의 인증을 받지 못하였을 때 그 행동을 수

행하지 않는다는 (가칭) ‘AI 행동 원칙’이 모든 AI 로봇의 

하드웨어 또는 소프트웨어에 프로그래밍 되는 방법 및 

이에 대한 법적 윤리적 가이드라인이 함께 구체화되어야 

한다. 셋째, 블록체인 자체의 구조적 효율성 증가와 속도 

개선, 사용자의 이용 편의와 확장성 문제들이 더욱 깊이 

연구되어야한다.

REFERENCES

[1] Committee on Legal Affairs (2016). DRAFT REPORT 

with recommendations to the Commission on Civil 

Law Rules on Robotics(2015/2103(INL)). European 

Parliament.

[2] Y. J. Lim. (2017). Passing of the European Parliament 

‘RoboLaw’ Resolution and its Meaning. Korea Institute 

for International Economic Policy.

[3] W. T. Lee. (2016. June). European Union RoboLaw 

Project, KISO journal, 23, 29-32.

[4] S. R. Kim. (2018). Legal Tasks and Prospects of the 

Fourth Industrial Revolution and the AI Era. Journal of 

Law Review, 18(2), 21-57.

[5] M. S. Jang. (2018). A Study on Legal Issues in the Age 

of Artificial Intelligence(AI). Korea Legislation 

Research Institute.

[6] E. K. wang. (2017). A Study on the Robot Basic 

Legislation and Consumer Problem – focusing on 

reviewing the Robot Basic Bill. Journal of Gachon Law 

Review, 10(4), 79-116.

[7] H. R. Namgoong, Y. H. Won, S. J. Kang & W. S. Han. 

(2017. May). Comparison of National Legislations on 

Test Driving of Autonomous Cars and Policy 

Implications. Proc. of the Korea Technology 

Innovation Society. (pp. 489-497). KTIC.

[8] S. J. Kang, Y. H. Won & M. J. Kim. (2018. March). The 

Propose a Legislation Bill to Apply Autonomous Cars 

and the Study for Status of Legal and Political Issues. 

Communications of the Korea Technology Innovation 

Society, 21, 151-200.

[9] J. H. Kim. (2020). Ministry of Land, Infrastructure & 

Transport established the world’s first safety standard 

for partial autonomous cars. HelloT(Online). 

http://www.hellot.net/new_hellot/magazine/magazine

_read.html?code=202&sub=004&idx=49588

[10] M. An & Y. Park. (2019). Legal System of Blockchain 

and Domestic and Foreign Blockchain Legal System. 

Journal of Digital Convergence, 17(10), 67-75.

[11] Hyperledger Fabric(Online). Linux Foundation. 

https://www.hyperledger.org/projects/fabric

[12] K. WĂźst & A. Gervais. (2018. June). Do you need a 

Blockchain?. 2018 Crypto Valley Conference on 

Blockchain Technology (CVCBT), 45-54.

[13] H. Tang, Y. Shi & P. Dong. (2019. March). Public 

blockchain evaluation using entropy and TOPSIS. 

Expert Systems with Applications, 117, 204-210.

[14] B. K. Kwon. (2019). Commercial Blockchain, What is 

Different?. Posco Issue Report: Posco Research 

Institute.

[15] HashNet(Online). Oracle problem in Blockchain.

http://wiki.hash.kr/index.php/%EC%98%A4%EB%9D%B

C%ED%81%B4_%EB%AC%B8%EC%A0%9C

전 민 규(Mingyu Jeon) [학생회원]

․ 2017년 3월 ~ 현재: 숭실대학교 컴퓨

터학부 재학 중

․ 관심분야 : 블록체인, 4차산업, 경영학

․ E-Mail : mkjyong@naver.com

황 지 연(Chiyeon Hwang) [학생회원]

․ 2017년 3월 ~ 현재: 숭실대학교 컴퓨

터학부 재학 중

․ 관심분야 : 관심분야: 블록체인, 빅데

이터

․ E-Mail : ghkdwldus98@naver.com

나 현 숙(Hyeon-Suk Na)    [정회원]

․ 1993년 2월 : 서울대학교 수학과(이학

사)

․ 1995년 2월 : 포항공과대학교 수학과

(이학석사)

․ 2002년 2월 : 포항공과대학교 수학과

(이학박사)

․ 2001년 3월 ~ 2002년 8월 : 프랑스 

INRIA Post Doctor

․ 2003년 3월 ~ 현재 : 숭실대학교 컴퓨터학부 교수

․ 관심분야: 알고리즘, 계산기하학, 컴퓨터그래픽스

․ E-Mail : hsnaa@ssu.ac.kr


";"""date"",""2020-06-02T01:46:08Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.6""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dcterms:created"",""2020-06-02T01:46:06Z""
""language"",""ko""
""Last-Modified"",""2020-06-02T01:46:08Z""
""dcterms:modified"",""2020-06-02T01:46:08Z""
""dc:format"",""application/pdf; version=1.6""
""xmpMM:DocumentID"",""uuid:0f9685dc-08f9-44b8-a56b-e570488293da""
""Last-Save-Date"",""2020-06-02T01:46:08Z""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2020-06-02T01:46:08Z""
""meta:save-date"",""2020-06-02T01:46:08Z""
""pdf:encrypted"",""false""
""xmp:CreateDate"",""2020-06-02T10:46:06Z""
""modified"",""2020-06-02T01:46:08Z""
""Content-Length"",""433429""
""pdf:hasMarkedContent"",""false""
""Content-Type"",""application/pdf""
""xmp:ModifyDate"",""2020-06-02T10:46:08Z""
""xmp:MetadataDate"",""2020-06-02T10:46:08Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""pdf:producer"",""ezPDF Builder Supreme""
""meta:creation-date"",""2020-06-02T01:46:06Z""
""created"",""2020-06-02T01:46:06Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""7""
""Creation-Date"",""2020-06-02T01:46:06Z""
""resourceName"",""JAKO202015762902709.pdf""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""2321"",""2404"",""2019"",""1986"",""2385"",""2346"",""3062""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""producer"",""ezPDF Builder Supreme""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""ezPDF Builder Supreme""
""pdf:docinfo:created"",""2020-06-02T01:46:06Z""
";https://scholar.google.ch/scholar?start=930&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098884-379;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;[PDF][PDF] Peculiarities of blockchain tech use in international business and finance;A Makarenko, NV Shyriaieva ;2020 repository.kpi.kharkov.ua;;"… found that 53 out of 130 web merchants that accept cryptocurrency have routinely leaked …

governance issues through their participation in two of the largest blockchain consortia,

Hyperledger and EEA (Dell, Miscrosoft, Intel, IBM, FedEx, Oracle, JPMorgan Chase are …";;;[PDF] kpi.kharkov.ua;http://repository.kpi.kharkov.ua/bitstream/KhPI-Press/50949/3/Makarenko_Peculiarities_of_blockchain_2020.pdf;"
93 
 

*********************************************************************************** 

JEL Classification: O00; F230; F300 

Makarenko Anastasiya 

Assistant Professor of the International Business and Finance Department 

Shyriaieva Natalia 

Cand. Sc. (Tech.), Associate Professor of the International 

Business and Finance Department 

NTU “Kharkiv Polytechnic Institute” 

Kharkiv, Ukraine 

 

PECULIARITIES OF BLOCKCHAIN TECH USE IN INTERNATIONAL 

BUSINESS AND FINANCE 

 

In the research peculiarities of blockchain technologies use in international 

business and finance are considered. It seems that the Industry 4.0 touches all spheres of 

business environment as well as a government. To handle the blockchains the risks and 

benefits should be taken into consideration. 

Key words: blockchain, finance, international business, business environment.  

 

Distributed ledger technologies known as blockchain causes lots of excitement 

among tech-savvy businesses. Supporters of blockchain lay high hopes on the 

technology to gain an edge over rivals. In this paper we will consider opportunities that 

blockchain brings for international business and its drawbacks. The first known ledgers 

emerged 5,000-10,000 years ago in Mesopotamia and were used as markers of 

transactions to keep track of things like the crops prices [1]. Current blockchains are 

digital memory devices for recording and verifying transactions and terms of 

engagement.  

Blockchain can address a number of problems in international business and 

finance such as verification, transparency, paying for contributions to intellectual 

property, and efficiency of supply chains just to name a few. Currently the Danish 

shipping giant Maersk and IBM announced a joint venture to create a real-time digital 

ledger for global shipping. Walmart tracks its shipping with the blockchain. The 

technology is quite helpful in establishing origins and ownership, which is much needed 

in financial sector, i.e. audit. The cargo, transport, and shipping industry has long 

suffered from a lack of transparency with regard to the sourcing and timing of 

shipments, which public ledgers might be able to solve. Verification can also be helpful 

in real estate, hiring and running a background check before employment, and banking. 

Blockchain can help to spread the use of smart contracts, which are digital agreements 

that are automatically executed once a consensus on an event’s outcome is generated on 

a blockchain [2]. This makes them tamperproof and highly efficient. Such finance and 

banking industry giants as JPMorgan and Goldman Sachs are devoting resources into 



94 
 

research on smart contracts [2]. In trade finance smart contracts can help to speed up 

processes as users can attach internet of things (IoT) sensors to the shipment vehicles to 

monitor temperature and provide real-time updates that are automatically recorded in 

blockchain. Online feedback through blockchain records outcomes and enables both 

sides to reach a consensus about the condition of the delivery. If everything is 

satisfactory, the smart contract is cleared, and a transfer of money is triggered. Despite 

all the hype and obvious advantages of blockchain technology, not that many businesses 

are ready to implement it even in developed economies. In a Deloitte survey of 308 

senior executives at large U.S. companies, 39% of respondents had little or no 

knowledge about blockchain technology. A survey of more than 200 board-level, non-IT 

executives in the U.K. yielded similar results: about 40% said they do not fully 

understand the technology, and less than 10% believe their organizations have the 

necessary skill sets to adopt it [3]. Besides, the technology itself has one too many 

chinks in the armor. Although blockchain is widely viewed as unbreakable because 

advanced cryptographic techniques are used to encode the data and ensure that it is not 

altered, there are vulnerabilities to be exploited. Mostly, those are the most vaunted 

features for which the technology is being praised for, that might fail or have unintended 

consequences: private keys; software flaws; anonymity; high customization cost [4]. 
Private keys are such large numbers that majority of users have to write them down, and 

these notes are at high risk of being found by others. Besides, if private key is lost, an 

access to account is lost forever. Information is added to the blockchain with the 

software code, which can have flaws.  

Some researchers argue the blockchain systems provide pseudonymity rather than 

anonymity. That is because users in a blockchain system are disguised but still need to 

fully or partially identify themselves to interact outside the system. Princeton University 

researchers found that 53 out of 130 web merchants that accept cryptocurrency have 

routinely leaked end users’ identifiable data in the form of a cookie (also known as a 

session ID) [4]. Besides, anonymity is double-edged sword as it is appreciated by illegal 

transactions users. Many executives worry that large investments in the technologies 

will outpace the gains. Enterprise executives exploring blockchain can’t leave it solely 

to the technologists. These issues require industry expertise from stakeholders around 

the world. Many practitioners advise businesses should take up blockchain considering 

all its advantages and disadvantages. Use of the technology won’t bring solutions unless 

there is a strategy behind it. In creating a blockchain, organizations need to define the 

specific problem they are trying to solve. They must determine which transactions or 

interactions the blockchain should capture and who should have access to which 

portions. Companies should understand how to configure, design, and use blockchain 

technologies in unique ways. The strategy needs to be linked to the company’s unique 

capabilities and resources [1]. Business should review its existing resources and look for 

ways to leverage them with blockchain. In general, it’s advised to answer 3 questions 

before investing in blochchain implementation: what value will business offer, how 



95 
 

public will its blockchains be, what incentives will it offer to participate. Moreover, 

blockchain governance is still the unfinished business. We are witnessing unexpected 

user behaviors that become problematic to address without robust governance. 

Stakeholders need a mechanism for agreeing on which changes need to be made, when, 

how, and by whom. There is still notable reluctance to participate in development of 

open standards to govern the emerging technology. Only 20 of the Fortune 500 

corporations are considering governance issues through their participation in two of the 

largest blockchain consortia, Hyperledger and EEA (Dell, Miscrosoft, Intel, IBM, 

FedEx, Oracle, JPMorgan Chase are among them) [5]. Once these issues are taken care 

of and more businesses embracing the technology companies will find solutions to the 

current drawbacks. An independent QA firm could test software before it is put into 

use. Reducing the number of software flaws will be initiated. Some form of an on/off 

switch could be incorporated into the blockchain’s software. Potentially anyone seeking 

to use a given blockchain (and to be assigned public/private keys) must be vetted first, 

and a record of the owner and the private key must be kept in a secure location. 

Alternatively, all passwords could be stored in a company safe. If the owner of that 

digital wallet were unavailable, the password could be retrieved. 
In conclusion, architectural changes in value creation do not happen overnight. 

They will generate resistance from regulators and businesses worrying about their 
revenue models. Such fundamental costs as verifying the attributes of a transaction and 
the cost of exchanging value within a network will be reduced with widespread use of 
blockchain. But smooth functioning of the technology requires every key actor in an 
business environment to participate.  

 
References: 

1. What Problems will you Solve with Blockchain? Teppo Felin and Karim Lakhan. 
MIT Sloan Management Review. URL: https://sloanreview.mit.edu/article/what-
problems-will-you-solve-with-blockchain/ (Last accessed: 30.03.2019). 
2. Navigating the Next Wave of Blockchain Innovation: Smart Contracts Lin William 
Cong, interviewed by Frieda Klotz. MIT Sloan Management Review. URL: 
https://sloanreview.mit.edu/article/navigating-the-next-wave-of-blockchain-innovation-
smart-contracts/ (Last accessed: 02.04.2019). 
3. Preparing for a Blockchain Future. Michael Ferguson. MIT Sloan Management 
Review. URL: https://sloanreview.mit.edu/article/preparing-for-a-blockchain-future/ 
(Last accessed: 25.03.2019). 
4. Blockchain Isn’t as Unbreakable as You Think. Stuart Madnick MIT Sloan 
Management Review. URL: https://sloanreview.mit.edu/article/blockchain-isnt-as-
unbreakable-as-you-think/ (Last accessed: 03.04.2019). 
5. Unleashing the Power of Blockchain in the Enterprise.  Don Tapscott and Ricardo 
Viana Vargas. MIT Sloan Management Review. URL: 
https://sloanreview.mit.edu/article/unleashing-the-power-of-blockchain-in-the-
enterprise/ (Last accessed: 06.04.2019). 

https://sloanreview.mit.edu/article/navigating-the-next-wave-of-blockchain-innovation-smart-contracts/#article-authors
https://sloanreview.mit.edu/article/navigating-the-next-wave-of-blockchain-innovation-smart-contracts/#article-authors
https://sloanreview.mit.edu/article/preparing-for-a-blockchain-future/#article-authors
https://sloanreview.mit.edu/article/blockchain-isnt-as-unbreakable-as-you-think/#article-authors
https://sloanreview.mit.edu/article/unleashing-the-power-of-blockchain-in-the-enterprise/#article-authors
https://sloanreview.mit.edu/article/unleashing-the-power-of-blockchain-in-the-enterprise/#article-authors

";"""date"",""2021-02-11T08:03:43Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.7""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""language"",""en""
""Last-Modified"",""2021-02-11T08:03:43Z""
""dcterms:modified"",""2021-02-11T08:03:43Z""
""dc:format"",""application/pdf; version=1.7""
""Last-Save-Date"",""2021-02-11T08:03:43Z""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2021-02-11T08:03:43Z""
""meta:save-date"",""2021-02-11T08:03:43Z""
""pdf:encrypted"",""false""
""modified"",""2021-02-11T08:03:43Z""
""Content-Length"",""265779""
""pdf:hasMarkedContent"",""true""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""dc:language"",""ru-RU""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""3""
""resourceName"",""Makarenko_Peculiarities_of_blockchain_2020.pdf""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""2601"",""3471"",""3041""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""producer"",""iLovePDF""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""iLovePDF""
";https://scholar.google.ch/scholar?start=920&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098778-140;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;[PDF][PDF] An Analysis of p+ ? Attacks on Various Models of Schelling Game Based Systems;W GEORGE, CLE LESAEGE ; assets.pubpub.org;;"… Such oracles are important for reporting on-chain results of elections for prediction market

contracts, rainfall amounts for drought insurance contracts, etc … This process serves as an oracle

for blockchain applications that use these lists to gain information about whether …";Autres articles;Version HTML;[PDF] pubpub.org;https://assets.pubpub.org/33am50c6/51581340370715.pdf;;;https://scholar.google.ch/scholar?start=680&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098778-133;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Tight verifiable delay functions;N Döttling, S Garg, G Malavolta… ; … Conference on Security …, 2020  Springer;;"… This is in contrast with prior generic constructions (Boneh et al., CRYPTO 2018) that required

the … close to T (with any number of processors) in a black-box manner from random oracles (and

thus … is no black-box construction of a T-sequential VDF from a random oracle where the …";Cité 12 fois;Les 6 versions;[PDF] iacr.org;https://eprint.iacr.org/2019/659.pdf;"
Tight Verifiable Delay Functions

Nico Döttling1, Sanjam Garg2, Giulio Malavolta3, and Prashant Vasudevan2

1CISPA Helmholtz Center for Information Security
2UC Berkeley

3UC Berkeley & Carnegie Mellon University

Abstract

A Verifiable Delay Function (VDF) is a function that takes at least T sequential steps
to evaluate and produces a unique output that can be verified efficiently, in time essentially
independent of T . In this work we study tight VDFs, where the function can be evaluated
in time not much more than the sequentiality bound T .

On the negative side, we show the impossibility of a black-box construction from ran-
dom oracles of a VDF that can be evaluated in time T + O(T δ) for any constant δ < 1.
On the positive side, we show that any VDF with an inefficient prover (running in time
cT for some constant c) that has a natural self-composability property can be generically
transformed into a VDF with a tight prover efficiency of T + O(1). Our compiler intro-
duces only a logarithmic factor overhead in the proof size and in the number of parallel
threads needed by the prover. As a corollary, we obtain a simple construction of a tight
VDF from any succinct non-interactive argument combined with repeated hashing. This
is in contrast with prior generic constructions (Boneh et al, CRYPTO 2018) that required
the existence of incremental verifiable computation, which entails stronger assumptions and
complex machinery.

1 Introduction

Verifiable Delay Functions (VDFs), introduced by Boneh et al [BBBF18], is a recent crypto-
graphic primitive which allows one to put protocol parties on halt for a set amount of time.
VDFs are functions that are characterized by three properties. For a time parameter T , (i) it
should be possible to compute the function in sequential time T . Furthermore, a VDF should
be T -sequential in the sense that (ii) it should not be possible to compute such a function in
(possibly parallel) time significantly less than T . Finally, (iii) the function should produce a
proof π which convinces a verifier that the function output has been correctly computed. Such
a proof π should be succinct, in the sense that the proof size and the verification complexity are
(essentially) independent of T . These properties enable a prover to prove to the verifier that
a certain amount of time has elapsed, say, by computing the function on an input provided by
the verifier.

After the seminal work of Boneh et al. [BBBF18], VDFs have rapidly generated interest in
the community and several follow-up constructions have recently been proposed [Pie19, Wes18],
and there is active work in implementing and optimizing them for near-term practical use [Chi].
This is partially motivated by the large range of applications of this primitive. As an example,
VDFs can turn blockchains into randomness beacons – introducing a delay in the generation of
the randomness prevents malicious miners from sampling blocks adaptively to bias the outcome
of the beacon. VDFs are also useful as a computational time-stamp and have further applications
in the context of proofs of replications [ABBK16] and resource-efficient blockchains [Coh17].

1



One of the major efficiency metrics for a VDF is the prover’s computational complexity,
in relation to the time parameter T . This determines the time taken to evaluate a VDF by
an honest prover, and therefore the gap with respect to the best possible successful malicious
machine (which we bound to take time atleast T ). In the ideal case this gap is non-existent, i.e.,
the prover can compute the VDF in time exactly T without resorting to massive parallelization.
This work asks the following question:

When do VDFs with tight prover complexity exist?

Our Negative Result: Motivated by concerns about concrete efficiency, we first investigate
the possibility of black-box constructions of VDFs from other cryptographic primitives. In
particular, given the prevalence of strong and efficient candidates for simple cryptographic
primitives like one-way functions and collision-resistant hash functions (SHA256, for instance),
we would ideally like to use these as black-boxes to get similarly strong and efficient VDFs. As a
negative result, we show that it is impossible to construct a T -sequential VDF where the prover
runtime is close to T (with any number of processors) in a black-box manner from random
oracles (and thus one-way functions or collision-resistant hash functions).

Theorem 1.1 (Informal) There is no black-box construction of a T -sequential VDF from a
random oracle where the prover makes at most T + O(T δ) rounds of queries to the oracle for
some constant δ < 1.

Our Positive Result: On the other hand, we find that the natural generic non-blackbox
approach to constructing a VDF can actually be made tight. All known constructions of VDF
proceed by iteratively applying some function f to the given input – that is, computing f(x),
f(f(x)), and so on. A proof that this was done correctly is computed either afterwards or
during this computation. We show that, assuming a modest parallelism of the prover, we can
bootstrap any such VDF where the prover complexity may not be tight into a VDF where the
prover runtime matches the sequentiality bound T . More specifically, we construct VDFs that
can be computed in parallel time T +O(1) using O(log(T )) processors and space.

Our bootstrapping theorem consists of a compiler that transforms any VDF with a some-
what natural self-composability property into a VDF with a tight prover complexity. Roughly
speaking, we require that the evaluation of a VDF on time parameter T can be decomposed into
two (sequential) evaluations of the same VDF on parameters T1 and T2 such that T1 + T2 = T .
This is satisfied by all known VDF candidates. The resulting scheme is as secure as the under-
lying VDF. Furthermore, the transformation is practically efficient and simple to implement.

Theorem 1.2 (Informal) If there exists a self-composable VDF with a prover runtime bounded
by c ¡T for some constant c, then there exists a VDF with prover runtime bounded by T +O(1).

As our transformation mentioned above is black-box, Theorems 1.1 and 1.2 together rule out
black-box constructions from random oracles of a self-composable VDF where the prover makes
at most cT rounds of queries for some constant c. We highlight a few other interesting corollaries
of our theorem:

(1) Assuming the existence of an inherently sequential function and (not necessarily incremen-
tal) succinct non-interactive arguments [Kil92, Mic94], there exists a T -sequential VDF,
for any T , where the prover runs in time T using a poly-logarithmic number of processors.

This improves over generic constructions from prior work [BBBF18], which required incremental
verifiable computation [Val08, BCCT13], which is a stronger primitive.1 Next, we turn our

1Known constructions of incremental verifiable computation require succinct arguments with knowledge ex-
traction.

2



attention to specific number-theoretic constructions. In this context we improve the prover
efficiency of the construction of Pietrzak [Pie19], where the prover runs in time approximately
T +
√
T .

(2) Assuming the security of Pietrzak’s VDF, there exists a T -sequential VDF with prover
parallel runtime exactly T using loglog(T ) processors and space. The proof size is increased
by a factor of loglog(T ) and the verifier parallel complexity is unchanged.

Our result generalizes a prior work by Wesolowski [Wes18] which obtains a specific construction
of a tight VDF. We discuss the consequences of our bootstrapping theorem in greater detail in
Appendix A. Regarding the additional parallelism used by our prover, we stress that a log(T )
parallelism by the prover is also (implicitly) assumed by prior work: In the circuit model, even
computing a simple collision-resistant hash with security parameter Îť already requires at least
Îť (> log(T ) in our setting) parallel processors. Our compiler adds an extra logarithmic factor,
which is well in reach of modern GPUs.

1.1 Our Techniques

In this section we give a brief overview of the main ideas behind this work. To simplify the
exposition, we first discuss our bootstrapping theorem and then we give some intuition behind
our impossibility result.

Self-Composability and Weak Efficiency. In the standard syntax of VDFs, both the
output value y and the proof π are computed by a single function Eval. For the purposes of
this work, it is instructive to think of the algorithms which compute a VDF function values y
and proofs π as separate algorithms Comp and Prove: Comp takes as input the time parameter
T and an input x and outputs a function value y and auxiliary information Îą. On the other
hand Prove takes as input α and outputs a proof π. The first property that we assume for the
underlying VDF is weak-efficiency : On time parameter T , the Comp algorithm runs in time T
whereas Prove runs in time at most cT , for some constant c. While our argument is generic, for
the purpose of this outline we always assume that c = 1, i.e., it takes the same number of steps
to compute the function via (y, α)← Comp(T, x) and to compute the proof π ← Prove(α).

We also assume that the function Comp is self-composable. Namely, let that T = T1 +T2 for
any T1, T2 > 0. For any input x, we require that if (y1, ·)← Comp(T1, x), (y2, ·)← Comp(T2, y1)
and (y, ·)← Comp(T, x), then it holds that y2 = y. In other words, we require that the function
(y, ·)← Comp(T, x) can be computed in two smaller steps, where we feed the result of the first
step back into the function to obtain the actual output.

We argue that these are mild requirements for VDFs, in fact all of the recent constructions
fit into this paradigm and therefore can be used as input for our compiler. This includes the
more structured approach of repeated squaring over hidden order groups [Pie19, Wes18] and
even the straightforward combination of repeated hashing and succinct arguments [BBBF18].

Bootstrapping VDFs. In favor of a simpler presentation, throughout the following informal
discussion we assume that T = 2t, for some integer t. The more general case is handled in
the main body of the paper and follows with minor modifications. Recall that, by the self-
composability property, we can split the computation (y, α) ← Comp(2t, x) into two separate
blocks (y1, α1)← Comp(2t−1, x) and (y, α2)← Comp(2t−1, y1). Our main insight is that we do
not need to compute a proof π for the full trace of the computation, instead we can compute
two separate proofs for the corresponding subroutines. Then the final proof will consist of
the concatenation of the two proofs. More specifically, we will set π = (π1, π2), where π1 ←
Prove(α1) and π2 ← Prove(α2).

3



This modification allows us to leverage parallelism. To evaluate the function on input
x, one first computes (y1, α1) ← Comp(2t−1, x) in a single threaded computation. Once this
step is reached, the computation forks into two parallel threads: A thread S1 that computes
(y, α2) ← Comp(2t−1, y1) and a thread S2 which computes π1 ← Prove(α1). Note that by the
weak efficiency of the VDF, the runtime of the algorithm Prove is identical to that Comp(2t−1, x),
i.e., 2t−1 steps. It follows that S1 and S2 will terminate simultaneously. In other words, both y
and π1 will be available at the same time.

At this point only the computation of the proof π2 is missing. If we were to do it naively,
then we would need to add an extra 2t−1 steps to compute Prove(α2), after the computation of
(y, α2) ← Comp(2t−1, y1) terminates. This would yield a total computation time of T + T/2,
which is still far from optimal. However, observe that our trick has cut the original computation
overhead by a factor of 2. This suggest a natural strategy to proceed: We recursively apply the
same algorithm as above on Comp(2t−1, y1) and further split the proof π2 into two sub-proofs
for two equal-length chunks of computation. The recursion proceeds up to the point where the
computation of the function consists of a single step, and therefore there is no proof needed.
Note that this happens after t = log(T ) iterations. Since we spawn a new thread for each level
of the recursion, this also bounds the total amount of parallelism of the prover.

Our actual proof π now consists of ((y1, π1), . . . , (yt, πt)), i.e. the proof π consists of t compo-
nents. We verify π in the canonical way, that is, setting y0 = x we compute Vf(2t−i, yi−1, yi, πi)
for all 1 ≤ i ≤ t and accept if all verify and yt = y.

Black-Box Impossibility. We show that there cannot be a black-box construction of a VDF
from a random oracle if the overhead in computing the proof in the VDF is small. That is, if
the number of sequential rounds of queries that the algorithm Eval makes to the oracle is less
than T +O(T δ) for some constant δ < 1. Note that our transformation sketched above is itself
black-box, and thus our result also rules out black-box constructions of self-composable VDFs
with a constant-factor overhead in generating the proof.

The central idea behind the impossibility is observation that since the verification algorithm
Vf makes only a small number of queries, it cannot tell whether Eval actually made all the queries
it was supposed to. For simplicity, suppose that Eval makes exactly T sequential rounds of
queries, and that the sequentiality of the VDF guarantees that its output cannot be computed in
less than T rounds of queries. On input x, suppose Eval(x) = (y, π). Efficiency and completeness
of the VDF require that the verification algorithm Vf, making only poly(log(T )) queries to the
oracle, accepts when given (x, y, π). Whereas, soundness requires that the same Vf rejects when
given (x, y′, π′) for any y′ 6= y and any π′. We show that all of these cannot happen at the same
time while making only black-box use of the random oracle, if this oracle is the only source of
computational hardness.

Consider an alternative evaluation algorithm Eval that behaves the same as Eval except that
on one of the rounds of queries that Eval makes, instead of making the queries to the oracle, it
sets their answers on its own to uniformly random strings of the appropriate length. Otherwise
it proceeds as Eval does, and outputs whatever Eval would output. Now, unless the algorithm
Vf makes one of the queries that Eval skipped, it should not be able to distinguish between
the outputs of Eval and Eval. As these skipped queries are only a 1/T fraction of the queries
that Eval made, Vf, which only makes poly(log(T )) queries, catches them with only this small
probability. Thus, if Vf accepts the output (y, π) of Eval(x), then it should also mostly accept
the output (y′, π′) of Eval(x).

On the other hand, as Eval made less than T rounds of queries to the oracle, sequentiality
implies that y′ should be different from y (except perhaps with negligible probability). Thus,
with high probability, Vf accepts (y′, π′) where y′ 6= y, contradicting soundness.

4



1.2 Related Work

A related concept is that of Proofs of Sequential Work (PoSW), originally introduced by Mah-
moody, Moran, and Vadhan [MMV13]. A PoSW can be seen as a relaxed version of a VDF
where the output of the function is not necessarily unique: PoSW satisfy a loose notion of
sequentiality where the prover is required to perform at least ÎąT sequential steps, for some
constant ι ∈ [0, 1]. In contrast with VDFs, PoSWs admit efficient instantiations that make
only black-box calls to a random oracle [CP18, DLM19].

Time-lock puzzles [RSW96] allow one to hide some information for a certain (polynomial)
amount of time. This primitive is intimately related to sequential computation as it needs to
withstand attacks from massively parallel algorithms. Time lock-puzzles have been instantiated
in RSA groups [RSW96] or assuming the existence of succinct randomized encodings and of
a worst case non-parallelizable language [BGJ+16]. Time-lock puzzles can be seen as VDFs
with an additional encryption functionality, except that there is no requirement for an efficient
verification algorithm. In this sense the two primitives are incomparable.

Two constructions of tight VDFs were proposed in the seminal work of Boneh et al. [BBBF18],
one assuming the existence of incremental verifiable computation and the other from permu-
tation polynomials (shown secure against a new assumption). The latter scheme achieves
only a weak form of prover efficiency since it requires T parallel processors to be evaluated
tightly. Shortly after, two number theoretic constructions have been presented independently
by Pietrzak [Pie19] and Wesolowski [Wes18], based on squaring in groups of unknown order. In
their original presentation, neither of these schemes was tight as the prover required additional√
T and T/logT extra steps, respectively [BBF18].

However, Wesolowski [Wes18] later updated his paper with a paragraph that sketches a
method to improve the prover complexity of his construction from T +O(T/logT ) to T +O(1),
using techniques similar to the ones in our compiler. Our bootstrapping theorem can be seen
as a generalization of these techniques and can be applied to a broader class of constructions.
Finally we mention of a new VDF instance from supersingular isogenies [FMPS19] where the
validity of the function output can be checked without the need to compute any extra proof,
however the public parameters of such a scheme grow linearly with the time parameter T .

In a concurrent and independent work by Mahmoody et al. [MSW19], an impossibility result
is also shown. Compared to our result, their lower bound rules out the existence of blackbox
VDFs for a looser set of parameters (i.e., it is a more general result). In contrast with our work,
their paper does not contain any results on new instantiations of VDFs.

2 Verifiable Delay Functions

We denote by Ν ∈ N the security parameter. We say that a function negl is negligible if it
vanishes faster than any polynomial. Given a set S, we denote by s←$S the uniform sampling
from S. We say that an algorithm runs in parallel time T with with P -many processors if it
can be implemented by a PRAM machine with P parallel processors running in time T . We
say that an algorithm is PPT if it can be implemented by a probabilistic machine running in
time polynomial in Îť.

Here we recall the definition of verifiable delay functions (VDF) from [BBBF18].

Definition 2.1 (Verifiable Delay Function) A VDF V = (Setup,Gen,Eval,Vf) is defined
as the following tuple of algorithms.

Setup(1λ) → pp : On input the security parameter 1λ, the setup algorithm returns the public
parameters pp. By convention, the public parameters encode an input domain X and an

5



output domain Y.

Gen(pp)→ x : On input the public parameters pp, the instance generation algorithm sample a
random input x←$X .

Eval(pp, x, T ) → (y, π) : On input the public parameters pp, an input x ∈ X , and a time
parameter T , the evaluation algorithm returns an output y ∈ Y together with a proof π.
The evaluation algorithm may use random coins to compute π but not for computing y.

Vf(pp, x, y, π, T ) → {0, 1} : On input the public parameters pp, an input x ∈ X , an output
y ∈ Y, a proof π, and a time parameter T , the verification algorithm output a bit {0, 1}.

Efficiency. We require that the setup and the instance generation algorithms run in time
poly(Îť), whereas the running time of the verification algorithm must be bounded by poly(log(T ), Îť).
For the evaluation algorithm, we require it to run in parallel time exactly T . We also consider
less stringent notions of efficiency where its (parallel) running time is bounded by cT , for some
constant c.

Completeness. The completeness property requires that correctly generated proofs always
cause the verification algorithm to accept.

Definition 2.2 (Completeness) A VDF V = (Setup,Gen,Eval,Vf) is complete if for all Ν ∈
N and all T ∈ N it holds that

Pr

Vf(pp, x, y, π, T ) = 1

∣∣∣∣∣∣
pp← Setup(1λ)
x← Gen(pp)
(y, π)← Eval(pp, x, T )

 = 1.

Sequentiality. We require a VDF to be sequential in the sense that no machine should be
able to gain a noticeable speed-up in terms of parallel running time, when compared with the
honest evaluation algorithm.

Definition 2.3 (Sequentiality) A VDF V = (Setup,Gen,Eval,Vf) is sequential if for all Ν ∈
N and for all pairs of PPT machines (A1,A2), such that the parallel running time of A2 (with
any polynomial amount of processors in T ) is less than T , there exists a negligible function negl
such that

Pr

(y, ¡) = Eval(pp, x, T )

∣∣∣∣∣∣∣∣
pp← Setup(1λ)
(T, τ)← A1(pp)
x← Gen(pp)
y ← A2(pp, x, T, τ)

 = negl(Ν).

Soundness. For soundness we require that it is computationally hard to find two valid outputs
for a single instance of the VDF. Note that here we do not constrain the running time of the
adversary, except for being polynomial in Îť and T .

Definition 2.4 (Soundness) A VDF V = (Setup,Gen,Eval,Vf) is sound if for all Ν ∈ N and
for all PPT machines A there exists a negligible function negl such that

Pr

[
Vf(pp, x, y, π, T ) = 1 and (y, ·) 6= Eval(pp, x, T )

∣∣∣∣ pp← Setup(1λ)
(T, x, y, π)← A1(pp)

]
= negl(Îť).

6



3 A Bootstrapping Theorem for VDFs

In this section we propose a compiler that takes as input any weakly efficient VDF (that satisfies
some natural composability properties) and turns it into a fully-fledged efficient scheme. We first
characterize the exact requirements of the underlying VDF, then we describe our construction
and we show that it preserves all of the properties of the underlying scheme.

3.1 Building Block

We require that the underlying VDF can be composed with itself (possibly using different time
parameters) arbitrarily many times, without altering the function output, i.e., Eval(pp, ·, T1) ◦
Eval(pp, ¡, T2) = Eval(pp, ¡, T1 + T2). More concretely, we assume the existence of a VDF that
satisfies the following.

Definition 3.1 (Self-Composability) A VDF V = (Setup,Gen,Eval,Vf) is self-composable
if, for all pp in the support of Setup(1Ν), for all x ∈ X , all (T1, T2) bounded by a sub-exponential
function in Ν, we have that Eval(pp, x, T1 + T2) = Eval(pp, y, T2), where (y, ¡) = Eval(pp, x, T2).

Note that this also implies that the domain and the range of the function are identical, i.e., X =
Y. We stress that this property is satisfied by all known candidate VDF constructions [BBBF18,
Pie19, Wes18]. To characterize the second requirement, it is going to be useful to refine the
syntax of our primitive. We assume that the evaluation algorithm Eval(pp, x, T ) is split in the
following subroutines:

Eval(pp, x, T ) : On input the public parameters pp, and input x ∈ X , and a time parameter T ,
execute the subroutine (y, α)← Comp(pp, x, T ). Then compute π ← Prove(α) and return
(y, π).

This captures the compute-and-prove approach, where the prover evaluates some inherently
sequential function and then computes a short proof of correctness, potentially using some
information from the intermediate steps of the computation (Îą). Note that this refinement is
done without loss of generality since one can recover the original syntax by encoding the proof
π in the advice α and set the prove algorithm to be the identity function. We are now in the
position of stating the efficiency requirements of the input VDF.

Definition 3.2 (Weak Efficiency) A VDF V = (Setup,Gen,Eval,Vf) is weakly efficient if
there exists a function Ψ : N→ N and a non-negative constant c such that for all T ∈ N it holds
that 0 ≤ Ψ(T ) ≤ cT and Prove runs in parallel time Ψ(T ), where T is the parallel running time
of Eval(¡, ¡, T ).

Note that the total running time of the evaluation algorithm is bounded by (c + 1)T , for
some constant c. This condition is again met by all known VDF instances [BBBF18, Pie19,
Wes18], since they are all based on the compute-and-prove paradigm: Given a long sequential
computation, the corresponding proof π can be computed in parallel time at most linear in T
by using essentially any verifiable computation scheme.

3.2 Scheme Description

Let V = (Setup,Gen,Eval,Vf) be a weakly efficient and self-composable VDF and let Ψ be
the corresponding function such that, on input T , the running time of the subroutine Prove is
bounded by Ψ(T ). Our construction V = (Setup,Gen,Eval,Vf) is shown below.

7



Setup(1Îť) : Return Setup(1Îť).

Gen(pp) : Return Gen(pp).

Eval(pp, x, T ) : Set S to be the smallest non-negative integer such that S + Ψ(S) ≥ T .

(1) If S ≤ 1:

(a) Compute (y, α)← Comp(pp, x, T ).

(b) Return (y, ∅).
(2) Else:

(a) Compute (y, α)← Comp(pp, x, S).

(b) Spawn a parallel thread to compute π ← Prove(α).

(c) Compute (ỹ, L)← Eval(pp, y, T − S) in the main thread.

(d) Return (ỹ, (y, π) ∪ L).

Vf(pp, x, y, π, T ) :

(1) Parse π as ((y1, π1), . . . , (yn, πn)).

(2) Set S0 = T and y0 = x.

(3) For all 1 ≤ i ≤ n:

(a) Define Si to be the smallest integer such that Si + Ψ(Si) ≥ S0 −
∑i−1

j=1 Sj .

(b) Compute in parallel bi = Vf(pp, yi−1, yi, Si).

(4) Return (b1 ∧ · · · ∧ bn ∧ (y, ·) = Eval(pp, yn, T −
∑n

j=1 Sj)).

The setup and the instance generation algorithms are unchanged. The new evaluation
algorithm is defined recursively: On input some time T , the algorithm defines S to be the
smallest non-negative integer such that S + Ψ(S) ≥ T . Recall that the correctness of the
evaluation of the Comp algorithm on time parameter S can be proven in time Ψ(S), by the
weak efficiency condition of the VDF. Thus, S approximates from above the maximum amount
of computation that can be performed and proven within time T . The algorithm then branches,
depending on the value of S:

(1) S ≤ 1 : In this case the algorithm simply computes Comp(pp, x, T ) and outputs the result
of the computation, without computing a proof. Observe that since S = 1 it holds that
T ≤ (1 + c) , where c is the constant such that Ψ(S) ≤ cS. Thus the algorithm runs for
at most c+ 1 steps. This corresponds to the last step of the recursion.

(2) S > 1 : In this case the algorithm computes the underlying VDF on time parameter S
and outputs the resulting (y, α) ← Comp(pp, x, S). At this point the algorithm branches
in two parallel threads:

(a) The first thread computes the proof π ← Prove(α).

(b) The second thread calls the evaluation algorithm recursively on input (pp, y, T − S),
which returns an output ỹ and a list L.

The algorithm returns the function output ỹ and the list L augmented (from the left)
with the intermediate pair (y, π), i.e., (y, π) ∪ L.

8



The output of the computation consists of n pairs (y1, π1), . . . , (yn, πn), where n is the depth of
the recursion, and a function output ỹ. Each output-proof pair can be verified independently
and the correctness of the function output ỹ can be checked by recomputing at most c steps of
the VDF on input yn.

Note that the only parameter that affects the efficiency of the prover and the verifier and
the size of the proof is the depth of the recursion n. Intuitively, each step of the recursion slices
off a chunk of the computation without affecting the total runtime of the algorithm, until only
a constant number of steps is left. If S and Ψ(S) are not too far apart, then n can be shown to
be bounded by a poly-logarithmic factor in T . We give a pictorial representation of the steps
of the computation in Figure 1.

3.3 Analysis

The completeness of our scheme follows from the self-composability of the underlying VDF. In
the following we analyze the efficiency of our construction and we show that the properties of
the underlying VDF are preserved under self-composition.

Efficiency. Recall that S is always a non-negative integers and therefore each step of the
recursion is executed on input some integer ≤ T . Thus we can bound the size of each proof πi
by the size of the proof of the underlying VDF on time parameter T . It follows that the proof
size of our scheme is at most a factor n larger, where n is the depth of the recursion. In the
following we bound the depth of the recursion, thus establishing also a bound also on the proof
size. We begin by stating and proving the following instrumental lemma.

Lemma 1 Let Ψ : N → N be a function such that there exists a constant c such that for all
S ∈ N it holds that Ψ(S) ≤ cS. Fix an S0 ∈ N and define Si to be the smallest non-negative
integer such that Si + Ψ(Si) ≥ S0−

∑i−1
j=1 Sj. Then for all S0 ∈ N and for all i ≥ 0 it holds that

S0 −
∑i

j=1 Sj ≤ S0

(
c
c+1

)i
.

Proof 1 We prove the claimed bound by induction over i. For the base case i = 0 we have
S0 ≤ S0, which is trivial. For the induction step, recall that Si is defined to be the smallest
integer such that Si + Ψ(Si) ≥ S0 −

∑i−1
j=1 Sj. Since Ψ(Si) ≤ cSi, for some non-negative c, we

have that

Si + cSi ≥ S0 −
i−1∑
j=1

Sj

Si(c+ 1) ≥ S0 −
i−1∑
j=1

Sj

Si ≥
S0 −

∑i−1
j=1 Sj

c+ 1
.

9



By induction hypothesis, it follows that

S0 −
i∑

j=1

Sj = S0 −
i−1∑
j=1

Sj − Si

≤ S0 −
i−1∑
j=1

Sj −
S0 −

∑i−1
j=1 Sj

c+ 1

=
(S0 −

∑i−1
j=1 Sj)c

c+ 1

≤ S0

(
c

c+ 1

)i−1( c

c+ 1

)
= S0

(
c

c+ 1

)i
.

The bound on the depth of the recursion is obtained by observing that the i-th copy of the
evaluation algorithm is called on time parameter exactly T −

∑i
j=1 Sj , where Sj is defined as

above. Note that if T −
∑i

j=1 Sj ≤ 1, then the recursion always stops, since the condition
1 + Ψ(1) ≥ 1 is satisfied for all non-negative Ψ. If we set S0 = T and apply Lemma 1 we obtain
the following relation

T −
i∑

j=1

Sj ≤ T
(

c

c+ 1

)i
≤ 1.

Solving for i, we have that log( c+1
c )(T ) iterations always suffice for the algorithm to terminate.

This also implies a bound on the number of processors needed to evaluate the function. We
now establish a bound on the parallel runtime of the evaluation algorithm.

Lemma 2 Let V be a weakly efficient VDF. Then, for all pp in the support of Setup(1Îť), for
all x ∈ X , and for all T ∈ N, the algorithm Eval(pp, x, T ) terminates in at most T + c steps.

Proof 2 We first consider the main thread of the execution. Set S0 = T and define Si to be the
smallest integer such that Si+Ψ(Si) ≥ S0−

∑i−1
j=1 Sj. Observe that the main thread consists of n

applications of the algorithm Comp on time parameter Si, where n is the depth of the recursion,
and one application on input S0−

∑n
j=1 Sj. Thus, by the weak efficiency of V, the total running

time of the main thread is exactly

n∑
j=1

Sj + S0 −
n∑
j=1

Sj = S0 = T.

To bound the runtime of the parallel threads we bound the difference with respect to the amount
of steps needed for the main thread to terminate, starting from the moment the execution forks.
We show a bound assuming Ψ(S) = cS, which implies a bound for the general case since the
proving algorithm can only get faster. Consider the i-th recursive instance of the algorithm:
After computing (αi, yi) ← Comp(pp, xi, Si), the main thread proceeds by calling Eval on input
T − Si and spawns a new thread to compute a proof on input αi. As discussed above, we know
that the main thread will terminate within T − Si steps, thus all we need to do is bounding the
amount of extra steps needed for the computation of the proof. Note that we have

(Si − 1) + Ψ(Si − 1) < T

10



since we assumed that Si was the smallest integer that satisfies Si + Ψ(Si) ≥ T . Substituting,

(Si − 1) + Ψ(Si − 1) < T

Ψ(Si − 1) < T − Si + 1

c(Si − 1) < T − Si + 1

cSi − c < T − Si + 1

Ψ(Si) < T − Si + c+ 1

where Ψ(Si) is exactly the number of steps needed to compute πi. This holds for all recursive
instances of the algorithms and concludes our proof.

We remark that the extra c steps needed for our algorithm to terminate are due to the rounding
that happens when S does not divide T . For the common case where T is a power of 2 and
Ψ is the identity function, then T = 2S in all of the recursive calls of the algorithm and the
process terminates in exactly T steps. The verifier complexity is bounded by that of n parallel
calls to the verifier of the underlying VDF on input some time parameter ≤ T , where n is
poly-logarithmic i";"""date"",""2020-06-30T17:22:35Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""12"",""0"",""21"",""0"",""2"",""8"",""20"",""3"",""3"",""8"",""28"",""0"",""0"",""2"",""0""
""pdf:PDFVersion"",""1.5""
""xmp:CreatorTool"",""TeX""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dcterms:created"",""2020-06-30T17:22:35Z""
""language"",""en""
""Last-Modified"",""2020-06-30T17:22:35Z""
""dcterms:modified"",""2020-06-30T17:22:35Z""
""dc:format"",""application/pdf; version=1.5""
""Last-Save-Date"",""2020-06-30T17:22:35Z""
""pdf:docinfo:creator_tool"",""TeX""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2020-06-30T17:22:35Z""
""meta:save-date"",""2020-06-30T17:22:35Z""
""pdf:encrypted"",""false""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017) kpathsea version 6.2.3""
""modified"",""2020-06-30T17:22:35Z""
""Content-Length"",""327443""
""pdf:hasMarkedContent"",""false""
""Content-Type"",""application/pdf""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017) kpathsea version 6.2.3""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""trapped"",""False""
""meta:creation-date"",""2020-06-30T17:22:35Z""
""created"",""2020-06-30T17:22:35Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""18""
""Creation-Date"",""2020-06-30T17:22:35Z""
""resourceName"",""659.pdf""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""2637"",""3181"",""3100"",""3486"",""3098"",""1967"",""2575"",""1704"",""1833"",""1809"",""1930"",""2041"",""2249"",""1961"",""2400"",""2295"",""2932"",""1280""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""producer"",""pdfTeX-1.40.18""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""pdfTeX-1.40.18""
""pdf:docinfo:created"",""2020-06-30T17:22:35Z""
";https://scholar.google.ch/scholar?start=680&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098778-136;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Time-space tradeoffs and short collisions in merkle-damgĺrd hash functions;D Cash, A Drucker, H Wee ; Annual International Cryptology Conference, 2020  Springer;;"… We thank an anonymous reviewer at CRYPTO 2020 for suggesting an improvement to Theorem

8. Previously the theorem only gave a bound of … T)-AI adversary if \(\mathcal {A}_1\) outputs S

bits and \(\mathcal {A}_2\) issues T queries to its oracle (for any inputs and oracles) …";Cité 3 fois;Les 3 versions;[PDF] iacr.org;https://eprint.iacr.org/2020/770.pdf;"
Time-Space Tradeoffs and Short Collisions in
Merkle-Damg̊ard Hash Functions

Akshima1, David Cash1, Andrew Drucker1, and Hoeteck Wee2,3

1 University of Chicago,
akshima@uchicago.edu, davidcash@uchicago.edu, andy.drucker@gmail.com

2 CNRS, ENS and PSL
wee@di.ens.fr

3 NTT Research

Abstract. We study collision-finding against Merkle-Damg̊ard hashing
in the random-oracle model by adversaries with an arbitrary S-bit aux-
iliary advice input about the random oracle and T queries. Recent work
showed that such adversaries can find collisions (with respect to a random
IV) with advantage Ω(ST 2/2n), where n is the output length, beating
the birthday bound by a factor of S. These attacks were shown to be
optimal.
We observe that the collisions produced are very long, on the order of
T blocks, which would limit their practical relevance. We prove several
results related to improving these attacks to find shorter collisions. We
first exhibit a simple attack for finding B-block-long collisions achieving
advantage Ω̃(STB/2n). We then study if this attack is optimal. We show
that the prior technique based on the bit-fixing model (used for the
ST 2/2n bound) provably cannot reach this bound, and towards a general
result we prove there are qualitative jumps in the optimal attacks for
finding length 1, length 2, and unbounded-length collisions. Namely, the
optimal attacks achieve (up to logarithmic factors) on the order of (S +
T )/2n, ST/2n and ST 2/2n advantage. We also give an upper bound on
the advantage of a restricted class of short-collision finding attacks via
a new analysis on the growth of trees in random functional graphs that
may be of independent interest.

1 Introduction

This work considers the security of random-oracle-based hash functions against
preprocessing adversaries which have a bounded amount of arbitrary auxiliary
information on the random oracle to help them. Attacks in this model were first
considered by Hellman [11], who gave a heuristic time-space tradeoff for inverting
cryptographic functions. We would like to understand the power of these attacks
in the context of finding collisions in hash functions, and in particular, salted
hash functions based on the widely used Merkle-Damg̊ard paradigm.

Finding short collisions. In this work, we focus on understanding the best
attacks for finding short collisions, as motivated by real-world applications. Con-
cretely, we put forth and study the following conjecture:



STB conjecture: The best attack with time T and space S for finding col-
lisions of length B in salted MD hash functions built from hash functions
with n-bit outputs achieves success probability Θ((STB + T 2)/2n).

The birthday attack achieves O(T 2/2n), and we will describe an attack that
achieves O(STB/2n). Short of proving circuit lower bounds, we cannot hope to
rule out better attacks, except in idealized models, where we treat the underlying
hash function as a random oracle.

The AI-RO model. We use the auxiliary-input random oracle (AI-RO) model
introduced by Unruh [15], which was originally motivated by dealing with the
non-uniformity of adversaries that is necessary for some applications of the
random-oracle model [1]. In the AI-RO model, two parameters S, T are fixed,
and adversaries are divided into two stages (A1,A2): The first has unbounded
access to a random function h, and computes an S-bit auxiliary input (or advice
string) σ for A2. Then the second stage accepts σ as input, and gets T queries
to an oracle computing h, and attempts to accomplish some goal involving the
function h. We think of the adversaries as information-theoretic and ignore run-
time.

Salted-collision resistance of MD hash functions at the AI-RO model was first
studied by Coretti, Dodis, Guo and Steinberger (CDGS) [3]. They proved the
STB conjecture in the setting B = T , showing an attack with success probability
ST 2/2n and proving its optimality.

Our results in a nutshell. We study the STB conjecture in the AI-RO
model, studying both upper bounds (better attacks) and lower bounds (ruling
out better attacks). Our contributions are as follows:

– Upper bounds. We present an attack with success probability O(STB/2n).
The attack exploits the existence of expanding depth-B trees of size O(B)
in random functional graphs defined by h.

– Limitations of prior lower bounds. We show that the CDGS [3] techniques
cannot rule out attacks with success probability ST 2/N , even for B = 2.
In particular, the crux of the CDGS technique is a O(ST/N) bound in an
intermediate idealized model (that translates to an AI-RO bound with a
multiplicative loss of T ), and we provide a matching attack with B = 2 in
this intermediate model.

– A lower bound for B = 2. We present new techniques to prove the STB con-
jecture for B = 2 in the AI-RO model. That is, the optimal attack achieves
success probability Θ((ST + T 2)/N) for B = 2. This is the main technical
contribution of this work. Interestingly, this means that for B = 2, if the
space S ≤ T , then there is no better attack than the birthday attack!

– Bounding low-depth trees. We rule out the existence of expanding depth-B
trees of size Õ(B2) in random functional graphs, which shows that sim-
ple extensions of our attack cannot achieve success probability better than
STB/N .

2



1.1 Prior works

Collision-resistance in the AI-RO. We consider salted collision resistance
following Dodis, Guo and Katz [6], in order to rule out trivial attacks where
the adversary hardwires a collision on h. Assume, as we shall for the rest of the
paper, that the function has the form h : [N ]× [M ]→ [N ], where [N ] = [2n] and
[M ] = [2m], which we identify with {0, 1}n and {0, 1}m respectively. In salted
collision-resistance in the AI-RO model, the second-stage adversary gets as input
a random “salt” a ∈ [N ] (along with σ), and must find α 6= α′ ∈ [M ] such that
h(a, α) = h(a, α′). The prior work obtained a bound of O(S/N + T 2/N) on
the success probability of any adversary, which is optimal (their result actually
covers a wider parameter range and different forms of h that are not relevant
for our results here). These results were interestingly proven via compression
arguments [10,9], where it is shown that an adversary that is successful too
often can be used to compress uniformly random strings, which is impossible
(cf. [14] for other applications of encoding arguments in computer science and
combinatorics).

In order to better model in-use hash functions, the aforementioned work of
Coretti, Dodis, Guo and Steinberger examined salted-collision-finding against
an MD hash function built from a random oracle h [3]. In their setting the
first stage adversary works as before, but the second adversary only needs to
find a collision in the iterated MD function built from h, starting at a random
salt; We give precise definitions in the next section. That work showed that
finding these collisions is substantially easier, giving an attack and matching
lower bound of O(ST 2/N). This was surprising in a sense, as it shows there
exists an S = T ≈ 260 attack against a hash function with 180-bit output, well
below the birthday attack with T ≈ 290.

A closer look at this attack reveals that the collisions it finds are very long
(on the order of T blocks), so in our example the colliding messages each consist
of 260 blocks. While technically violating collision-resistance, this adversary is
not damaging in any widely-used application we are aware of, as the colliding
messages are several petabytes long. Addressing whether or not this attack, or
the lower bound, can be improved to find shorter collisions is the starting point
for our work.

The results of [3] did not use compression. Instead they applied a tightening
of the remarkable and powerful bit-fixing (or presampling) method of Unruh [15],
which we briefly recall here. In the bit-fixing random oracle (BF-RO) model, the
adversary no longer receives an advice string. Instead the first stage adversary
can fix, a priori, some bits P of the table of h. Then the rest of h is sampled, and
the second stage attempts to find a salted collision as before. Building on Unruh’s
results, Coretti et al. showed (very roughly) that a bound of O((T +P )T/N) on
the advantage of any adversary in the BF-RO implies a bound of O(ST 2/N) in
the AI-RO. Moreover, the BF-RO bound was very easily proved, resulting in a
simple and short proof.

3



1.2 This work

Motivated by real-world hash functions like SHA-256, where N = 2n = 2256,
M = 2512, we are interested in parameter settings with B ďż˝ T , such as S = 270,
T = 295 and B = 218, which corresponds to computing a 256-bit digest of
a 16MB message using SHA-256. Here, (ignoring constants) the CDG bound
is meaningless, since ST 2/N > 1, whereas the corresponding attack achieves
constant advantage when T = B ≈ 293, collisions which are several yottabytes
(= 1024 bytes) long.

We first observe that Hellman’s attack (or an easy modification of the attack
in [3]) can find length-B collisions with success probability roughly STB/N . We
make this formal in Section 3.

While the attack was easy to modify for short collisions, proving that it is
optimal is an entirely different matter with significant technical challenges. In
order to explain them, we recall the approach of [3] used to prove the O(ST 2/N)
bound for salted MD. They used a technical approach (with tighter parameters)
first developed by Unruh [15], which connects the AI-RO model to the bit-fixing
random oracle (BF-RO) model (we defer the definition to the next section).
Their work transfers lower bounds in the BF-RO model to lower bounds in the
AI-RO model.

We show that the BF-to-AI template inherently cannot give a lower bound
for finding short collisions, because finding short collisions in the BF-RO model
is relatively easy. That is, the lower bound of the form we would need for BF-
RO model simply does not hold. In the notation introduced above, we would
need to show that no adversary finding length-2 collisions can do better than
O((P + T )/N) advantage, but we give a simple attack in BF-RO model that
finds length-2 collisions with advantage Ω(PT/N). Thus another approach is
required.

Our lower bound technique. Given that the BF-to-AI technique cannot dis-
tinguish between short and long collision finding, we must find another approach.
There are two options from the literature: The previously-mentioned compres-
sion arguments, and another lesser-known but elegant method of Impagliazzo
using concentration inequalities.

Compression arguments which were previously observed [3] to be difficult
(or “intractable”) to apply to the setting of salted MD collision finding despite
working in the original non-MD setting [6]. Given that compression was already
difficult in this setting, it does not seem promising to extend it to the harder
problem of short collisions.

To address these difficulties, we introduce a new technique that first applies a
variant of the “constructive” Chernoff bound of Impagliazzo and Kabanets [13]
to prove time-space tradeoff lower bounds. The concentration-based approach to
time-space tradeoff lower bounds was, to our knowledge, first introduced by Im-
pagliazzo in an unpublished work, and then later elucidated in an appendix [12]
(there an older work of Zimand [17] is also credited). The high-level idea is to
first prove that any adversary (with no advice) can succeed on any fixed U ∈ [N ]

4



of Ω(S) of inputs with probability εΩ(S). (In some sense bounding every suffi-
ciently large “moment of the adversary”). The argument continues by applying
a concentration bound to the random variable that counts the number of win-
ning inputs for this adversary, showing that it wins on a O(Îľ)-fraction of inputs
except with probability 2−Ω(S). In a final elegant step, one shows that every
advice string is likely to be bad via a union bound over all possible 2S advice
strings, to get a final bound of Îľ.

The technique of Impagliazzo gives a direct and simple proof for the optimal
bound on inverting a random permutation. There are two issues in applying it
to short MD collisions however. First, as we formally show later, it provably fails
for salted MD hashing. The issue is that the adversary may simply succeed with
probability greater than ÎľS on some subsets U (see section 7), so the first step
cannot be carried out.

We salvage the technique by showing it is sufficient to bound the adversary’s
average advantage for random subsets U rather than all subsets. In the language
of probability, we use a concentration bound that only needs average of the
moments to be bounded by εΩ(S), rather than all of the moments; see Theorem 1.

So far we have been able to reduce the problem of proving a lower bound
in AI-RO model to the problem of bounding the probability that an adversary
with no advice can succeed on every element of a random subset of inputs. For
the problems we considered, even this appeared to be complicated. To tame
the complexity of these bounds, we apply compression arguments; Note that
we are only proving the simpler bound needed for the Impagliazzo technique,
but using compression, when previously compression was used for the problem
directly. Our variation has the interesting twist that we can not only compress
the random function (as other work did), but also the random subset U on which
the adversary is being run. This turns out to vastly simplify such arguments.

Applications of our technique. We first apply our technique to reprove
the O(ST 2/N) bound for (non-short) collision finding against salted MD hash
functions. We then turn to the question of short collisions. Proving a general
bound (perhaps O(STB/N)) for finding length-B collisions appears to be very
difficult, so we start by examining the first new case of B = 2.

We show that there are qualitative gaps between finding length-1 collisions,
length-2 collisions, and arbitrary-length collisions. Specifically, while for length-
1 collisions we have Îľ = O((S + T 2)/N), we show that length-2 collisions are
easier when S > T , as the optimal bound is O((ST + T 2)/N). For arbitrary-
length collisions there is another gap, where the optimal bound is O(ST 2/N).
Our bound for length-2 collisions uses our new compression approach used above.

It appears that we could, in principle, obtain similar bounds for other small
length bounds like 3 and 4, but these proofs would be too long and complex for
us to write down; Going to arbitrary length bounds seems to be out of reach,
but there is no inherent obstruction in applying our technique to the general
case with new ideas.

Bound for a restricted class of attacks. Given the difficulty of proving
the general case, we instead consider ruling out the class of attacks that gives

5



optimal attacks in the known cases. Roughly speaking, these attacks use auxiliary
information consisting of S collisions at well-chosen points in the functional
graph. In the online phase, the attack repeatedly tries to “walk” to these points
by taking one “randomizing” step followed by several steps with zero-blocks.

For this class of attacks, we show that the best choice of collision points
will result in Îľ = O(STB/N). This result requires carefully analyzing the size
of large, low-depth trees in random functional graphs, a result that may be of
independent interest.

1.3 Discussion

On the non-existence of non-uniform attacks. A common argument
against studying lower bounds for non-uniform attacks4 is that we have no non-
trivial examples of better-than-generic non-uniform attacks on real-world hash
functions like SHA,-1 and that the complexity of the non-uniform advice may
anyway be prohibitive. Our STB conjecture, if true, would explain the non-
existence of these attacks: for small B,S where SB ≤ T , non-uniform attacks
do not achieve any advantage over the birthday attack!

Other related work. In addition to Hellman’s seminal work, we mention that
time-space trade-offs and lower bounds for other problems, including inverting
random functions and permutations and problems in the generic-group model,
and other models have been investigated [7,16,5,4,2].

Acknowledgements. We thank an anonymous reviewer at CRYPTO 2020 for
suggesting an improvement to Theorem 8. Previously the theorem only gave a
bound of O(STB2/N). The first two authors were supported in part by NSF
CNS-1453132.

2 Preliminaries

Notation. For non-negative integers N, k we write [N ] for {1, 2, . . . , N} and(
[N ]
k

)
for the collection of size-k subsets of [N ]. For a set X, we write X+ for

tuples of 1 or more elements of X. Random variables will be written in bold,

and we write x
$← X to indicate that x is a uniform random variable on X.

Merkle-Damg̊ard (MD) hashing. We consider an abstraction of plain MD
hashing, where a variable-length hash function is constructed from a fixed-length
compression function that is modeled as a random oracle. For integers N,M
and a function h : [N ]× [M ]→ [N ], Merkle-Damg̊ard hashing is defined MDh :
[N ]× [M ]+ → [N ] recursively by MDh(a, α) = h(a, α) for α ∈ [M ], and

MDh(a, (α1, . . . , αB)) = h(MDh(a, (α1, . . . , αB−1)), αB)

for ι1, . . . , ιB ∈ [M ]. We refer to elements of [M ] as blocks.

4An AI-adversary with S bits of advice and T queries can be compiled into a circuit
of size roughly O(S + T ).

6



Game AI-CRh,a(A)

σ ← A1(h)

α, α′ ← Ah
2 (σ, a)

If α 6= α′ and MDh(a, α) = MDh(a, α′)
Then Return 1

Else Return 0

Game BF-CRh,a(B,L)

α, α′ ← BhL(a)
If α 6= α′ and MDhL(a, α) = MDhL(a, α′)

Then Return 1
Else Return 0

Fig. 1: Games AI-CRh,a(A) and BF-CRh,a(B,L).

2.1 Collision Resistance Definitions

We recall definitions for collision resistance against preprocessing and against
bit-fixing.

Auxiliary-input security. We formalize auxiliary-input security [15] for salted
MD hashing as follows.

Definition 1. For a pair of algorithms A = (A1,A2), a function h : [N ] ×
[M ]→ [N ], and a ∈ [N ] we define game AI-CRh,a(A) in Figure 1. We define the
auxiliary-input collision-resistance advantage of A against Merkle-Damg̊ard as

Advai-cr
MD (A) = Pr[AI-CRh,a(A) = 1],

where h
$← Func([N ]× [M ], [N ]), a

$← [N ] are independent.
We say A = (A1,A2) is an (S, T )-AI adversary if A1 outputs S bits and A2

issues T queries to its oracle (for any inputs and oracles). We define the (S, T )-
auxiliary-input collision resistance of Merkle-Damg̊ard, denoted Advai-cr

MD (S, T ),
as the maximum of Advai-cr

MD (A) taken over all (S, T )-AI adversaries A.

We note that in our formalization, the games in the figures are not random-
ized, but just defined for any h and a. In the definition we use the games to
define random variables by applying the game as a function to random variables
h and a. This has the advantage of being explicit about sample spaces when
applying compression arguments.

We also consider bounded-length collisions as follows.

Definition 2. We say a pair of algorithms A = (A1,A2) is an (S, T,B)-AI
adversary if A1 outputs S bits, A2 issues T queries to its oracle, and the outputs
of A2 each consist of B or fewer blocks.

We define the (S, T,B)-auxiliary-input collision resistance of MD, denoted
Advai-cr

MD (S, T,B), as the maximum of Advai-cr
MD (A) taken over all (S, T,B)-AI

adversaries A.

Bit-fixing security. We recall the bit-fixing model of Unruh [15]. When f :

X → Y is a function on some domain and range, and L is a list (xi, yi)
|L|
i=1 where

xi ∈ X and yi ∈ Y for all i ∈ 1, . . . , |L| and all the xi are distinct, we define fL

7



as follows:

fL(x) =

{
yi if ∃(xi, yi) ∈ L such that x = xi

f(x) otherwise.

In other words, L is a list of input/output pairs, and fL is just f , but with
outputs overwritten by the tuples in L.

Definition 3. Let h : [N ] × [M ] → [N ], and a ∈ [N ]. For an adversary B
and a list L of input/output pairs for h we define BF-CRh,a(B,L) in Figure 1.
We define the bit-fixing collision-resistance advantage of (B,L) against Merkle-
Damg̊ard as

Advbf-cr
MD (B,L) = Pr[BF-CRh,a(B,L) = 1],

where h
$← Func([N ]× [M ], [N ]), a

$← [N ] are independent.
We say (B,L) is an (P, T )-BF adversary if L has at most P entries and B

issues T queries to its oracle (for any inputs and oracles). We define the (P, T )-
bit-fixing collision resistance of MD, denoted Advbf-cr

MD (P, T ), as the maximum
of Advbf-cr

MD (B,L) taken over all (P, T )-BF adversaries (B,L).

As with AI security, we also consider bounded-length collision resistance
against BF adversaries.

Definition 4. We say (B,L) is an (P, T,B)-BF adversary if L has at most P
entries, B issues T queries to its oracle (for any inputs and oracles) and the
outputs of B each consist of B or fewer blocks. We define the (P, T,B)-bit-
fixing collision resistance of MD, denoted Advbf-cr

MD (P, T,B), as the maximum of
Advbf-cr

MD (B,L) taken over all (P, T,B)-BF adversaries (B,L).

Chernoff bounds. We will use the following variant of the Chernoff-type
bound proved by Impagliazzo and Kabanets [13]. It essentially says that if the
uth moments of a sum are bounded on average, then we can conclude the sum
is tightly concentrated, up to some dependence on u. Note that X1, . . . ,XN are
not assumed independent.

Theorem 1. Let 0 < δ < 1 and let X1, ¡ ¡ ¡ ,XN be 0/1 random variables,
X = X1 + ¡ ¡ ¡XN , and let U be an independent random subset of [N ] of size u.
Assume

Pr[
∧
i∈U

Xi] ≤ δu.

Then
Pr[X ≥ max{6δN, u}] ≤ 2−u.

In their original version, instead of a random set U it was required that the
first inequality hold for all sets U of size u (so all uth moments must be bounded).
It is easy to show that our weaker condition is still sufficient, and the proof of
this version is almost identical and given in the appendix (Section 9) only for
completeness.

We will also apply the following standard multiplicative Chernoff bound in
Section 8.

8



Theorem 2. Let 0 < δ < 1 and let X1, ¡ ¡ ¡ ,XN be independent 0/1 random
variables and put X = X1 + ¡ ¡ ¡XN . Then

Pr[X ≥ (1 + δ) · E[X]] ≤ exp

(
−δ2 · E[X]

2 + δ

)
.

3 Bounded-Length Auxiliary-Input Attack

Coretti et al [2] gave an Ω(ST 2) attack where the adversary gets S-bit advice
and T oracle queries to find (unbounded length) collisions against MDh. It is
easy to adapt the attack to find length B collisions with advantage Ω(STB).
We describe this attack and its analysis in the appendix (Section 10).

Theorem 3. For any positive integers S, T,B such that B ≤ T < N/4, STB ≤
N/2 and M ≥ N ,

Advai-cr
MD (S, T,B) ≥ STB − 96S

48N logN
.

4 Length 2 Collisions are Relatively Easy in the BF
Model

Unruh in [15] proved a remarkable general relationship between the AI-RO and
BF-RO models that was sharpened by Coretti et al. [2]. We recall their theorem
now, and then show that this method, when applied to salted MD hashing, is
insensitive to the length of collisions found and hence cannot give the improved
bound we seek in the AI-RO model. We note that the second part of this theorem
was not stated there, but follows exactly from their proof.

Theorem 4. For any positive integers S, T, P and γ > 0 such that P ≥ (S +
log γ−1)T ,

Advai-cr
MD (S, T ) ≤ 2Advbf-cr

MD (P, T ) + Îł.

Moreover, for any positive integer B,

Advai-cr
MD (S, T,B) ≤ 2Advbf-cr

MD (P, T,B) + Îł.

The following is a simple extension of an attack of [3], which shows that
finding even just length-2 collisions in the BF model is much easier than finding
length-1 collisions, and in fact is as easy as finding general length collisions.

Theorem 5. For all positive integers P, T such that PT ≤ 2N , there exists a
(P, T, 2)-BF adversary (B,L) such that

Advbf-cr
MD (B,L) ≥

(
1− 1

e

)
PT

2N
.

9



Proof. We construct a (P, T, 2)-BF adversary (B,L) to prove the theorem. We
assume P is even for simplicity of notation. To define the list L, let α, α′ ∈
[M ], a1, . . . , aP/2, y ∈ [N ] be some arbitrary points, and let L consist of the P
entries

((a1, Îą), y), ((a1, Îą
′), y), . . . ((aP/2, α), y), ((aP/2, α

′), y).

Adversary B does the following on input a and oracle hL: Let ι1, ¡ ¡ ¡ , ιT ∈ [M ]
be arbitrary distinct points. For j = 1, . . . , T , query (a, Îąj) to the oracle hL. If
the output is an element of {a1, . . . , aP/2}, then output colliding messages αj‖α
and αj‖α′.

We lower bound Advbf-cr
MD (B,L). Let E be the event that the output of some

query made by B is in the set {a1, . . . , aP/2}. Clearly, when E happens, our
adversary wins the game. Thus

Advbf-cr
MD (B,L) ≥ 1− Pr[¬E] ≥ 1−

(
1− P

2N

)T
≥ 1− e−PT/2N ≥

(
1− 1

e

)
PT

2N

where the last inequality holds because 0 ≤ PT
2N ≤ 1.

This adversary shows that applying Theorem 4 can at best give Advai-cr
MD (S, T, 2) =

O(ST 2/N), which we show to be suboptimal in Section 6, where using compres-
sion techniques we prove a bound of Õ (ST/N).

5 Unbounded Length Collision AI Bound

In this section we give a different proof of the O(ST 2) bound of Coretti et al.[2],
formalized as follows.

Theorem 6. For any positive integers S, T ,

Advai-cr
MD (S, T ) ≤ 192e(S + logN)T 2 + 1

N
.

Following Impagliazzo [13], we proceed by analyzing an adversary without
auxilliary input “locally.”

Definition 5. For a pair of algorithms A = (A1,A2) and positive integer u we
define

Advu-ai-cr
MD (A) = Pr[∀a ∈ U : AI-CRh,a(A) = 1],

where h
$← Func([N ]× [M ], [N ]), and U

$←
(
[N ]
u

)
are independent.

Lemma 1. For any positive integers S, T, u, and σ̂ ∈ {0, 1}S, let A = (A1,A2)
be an adversary where A1 always outputs σ̂, and A2 issues T queries to its oracle.
Then

Advu-ai-cr
MD (A) ≤

(
32euT 2

N

)u
.

10



This lemma is proved below. We first prove the theorem using the lemma.

Proof of Theorem 6. Let A = (A1,A2) be an (S, T )-AI adversary. We need to
bound Advai-cr

MD (A) as in the theorem. Call h easy for adversary A if

Pr[AI-CRh,a(A) = 1] ≥ 192e(S + logN)T 2

N
.

We will first show that h is unlikely to be easy for A, no matter how A1 computes
its S advice bits. Below, for each σ̂ ∈ {0, 1}S let Aσ̂ be A, except with A1

replaced by an algorithm that always outputs σ̂.
Fix some σ̂ ∈ {0, 1}S . For each a ∈ [N ] let Xa be an indicator random vari-

able for the event that AI-CRh,a(Aσ̂) = 1. By Lemma 1 we have Pr[
∧
a∈U Xa] ≤

δu for any u and δ = 32euT 2/N . Then by Theorem 1 with u = S + logN , we
have

Pr[h is easy for Aσ̂] = Pr[

N∑
a=1

Xa ≥ 192euT 2] ≤ 2−(S+logN).

Let E be the event that there exists σ̂ ∈ {0, 1}S such that h is easy for Aσ̂. By
a union bound over σ̂ ∈ {0, 1}S ,

Pr[E] ≤ 2S2−(S+logN) = 1/N.

Finally we have

Pr[AI-CRh,a(A) = 1] ≤ Pr[AI-CRh,a(A) = 1|¬E] + Pr[E]

≤ 192e(S + logN)T 2

N
+

1

N
.

The last inequality holds because for each h /∈ E,

Pr[AI-CRh,a(A) = 1] ≤ max
σ̂∈{0,1}S

Pr[AI-CRh,a(Aσ̂) = 1] ≤ 192e(S + logN)T 2

N
.

Since this holds for any (S, T )-AI adversary A, we obtain the lemma.

5.1 Proof of Lemma 1

Colliding chains. We start with some useful definitions and a simplifying
lemma.

Definition 6. Let h : [N ]× [M ]→ [N ]. A list of elements (x0, α0), . . . , (x`, α`)
from [N ] × [M ] is called an MD-chain (for h) when h(xi, αi) = xi+1 for i =
0, . . . , ` − 1. We say two chains (x0, α0), . . . (x`, α`) and (x′0, α

′
0), . . . (x′`′ , α

′
`′)

collide (for h) if h(x`, α`) = h(x′`′ , α
′
`′).

We will treat chains as strings (over [N ] × [M ]) and speak of prefixes and
suffixes with their usual meaning.

11



Lemma 2. Let C,C ′ be distinct non-empty colliding chains for h. Then C,C ′

contain prefixes C̃, C̃ ′ respectively, C̃ = (x0, α0), . . . (x`, α`) and C̃ ′ = (x′0, α
′
0), . . .

(x′`′ , α
′
`′), such that either (x`, α`) 6= (x′`′ , α

′
`′) or one of C̃, C̃ ′ is a strict suffix

of the other.

Proof. Induction on the maximum length of C,C ′. For length 1 this is obvious.
For the inductive step, suppose neither is a strict suffix of the other, and that
the final entries are equal. Then we can remove the final entries from both chains
to get two non-empty shorter chains and apply the inductive hypothesis.

Proof of Lemma 1. We prove the lemma by compression. Let U
$←
(
[N ]
u

)
and

h
$← Func([N ] × [M ], [N ]) be independent. Let A = (A1,A2) be an (S, T )-AI

adversary where A1 always outputs some fixed string σ̂. Observe that if, for all
a ∈ U, A2 never queries a point of h with input salt a′ ∈ U, a 6= a′ among
the T queries it makes for input a, and also that the chains produced for each
a are disjoint from the chains for a′, then it is relatively simple to carry out a
compression argument, by storing two pointers [T ] to compress an entry in [N ]
(which would translate to a bound of (T 2/N)u). But of course A might “cross
up” queries for the different salts. If we tried to prove a version of the lemma
for all U ⊆

(
[N ]
u

)
(as was done in the original context of the appendix in [12])

rather than a random U, then the adversary could be specialized for the set U ;
In Section 7 we give an attack that finds collisions of B = 2 for a fixed subset
with greater probability than the upper bound on the advantage of attacking a
random subset of same size.

Also, when we choose U at random, a fixed A can’t be specialized for the set,
and the “crossed up” queries between salts are unlikely. Formally, if A queries
a salt a′ ∈ U while attacking a ∈ U, we take advantage of this by compressing
an entry of the random set U when a crossed-up query occurs. Very roughly,
this requires a pointer in [T ] and saves a factor N/S (because we are omitting
one entry from an (unordered) set of size about S). The net compression is then
about ST/N per crossed-up query. The details are a bit more complicated, as
this compression actually experiences a smooth trade-off as more such queries
are compressed and the set shrinks. We handle the case when the chains for
a 6= a′ intersect via a simpler strategy that also results in ST/N factors.

Once the crossed-up queries are handled, the proof effectively reduces to the
simpler case without crossed-up queries.

Proof. For the rest of the proof we fix some A = (A1,A2), where A1 always
outputs some fixed σ̂. Let

G = {(U, h) | ∀a ∈ U : AI-CRh,a(A) = 1} ⊆
(

[N ]

u

)
×H.

Let

Îľ = Advu-ai-crMD (A).

12



So |G| = Îľ
(
N
u

)
NMN . We define an injection

f : G → {0, 1}L

with L satisfying
2L(

N
u

)
NMN

≤
(

32euT 2

N

)u
.

Pigeonhole then immediately gives the bound on Îľ.
For (U, h) ∈ G, f(U, h) outputs an L-bit encoding, where L will be determined

below, of
(F,UFresh,Pred,Cases,Coll, h̃),

where the first output F is an integer between 1 and u, UFresh is a subset of U
of size F , Pred is a set of pointers, Cases is a list of elements in {1a, 1b, 2}, and
Coll is a list of pairs of pointers, and the last output h̃ is h but rearranged and
with some entries deleted. We now define these outputs in order.

Fresh salts and prediction queries. Fix some (U, h) ∈ G, and let U =
{a1, . . . , au}, where the ai are in lexicographic order. Let Qrs(ai) ∈ ([N ]× [M ])T

denote the queries A2 makes to its oracle when run on input (σ̂, ai). Let us abuse
notation by writing ai /∈ Qrs(aj) to mean that ai is not the first component of
any entry in Qrs(aj) (in other words, the salt ai is not queried when A2 runs on
aj).

We define UFresh ⊆ U inductively by

ai ∈ UFresh ⇐⇒ ∀1 ≤ j < i : aj ∈ UFresh =⇒ ai /∈ Qrs(aj).

The set UFresh trivially contains a1. For i > 1, ai ∈ UFresh if no prior salt in UFresh

causes A2 to query ai. Conversely, for any ai ∈ U \ UFresh, there is a prior salt
aj ∈ UFresh such that ai ∈ Qrs(aj).

Let us denote the size of UFresh by F , and let us write UFresh = {a′1, . . . , a′F }
where the a′j are in lexicographic order. From now on we will only need to deal
with the queries issued when the adversary is run on fresh salts. Let Qj = Qrs(a′j)
for j = 1, . . . , F and

QFresh = Q1‖ · · · ‖QF ∈ ([N ]× [M ])FT .

Going forward, we will sometimes use indices from [FT ] to point to queries in
QFresh and sometimes indices from [T ] to point to queries in Qj for some j.

For each a ∈ U \UFresh, there exists a minimum ta ∈ [FT ] such that QFresh[ta]
is a query with input salt a. We define Pred ⊆ [FT ], the prediction queries, to
be

Pred = {ta | a â";"""date"",""2020-06-22T22:54:25Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2020-06-22T22:54:25Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is MiKTeX-pdfTeX 2.9.6642 (1.40.19)""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2020-06-22T22:54:25Z""
""created"",""2020-06-22T22:54:25Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-06-22T22:54:25Z""
""resourceName"",""770.pdf""
""Author"",""""
""producer"",""pdfTeX-1.40.19""
""pdf:docinfo:producer"",""pdfTeX-1.40.19""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""3"",""1"",""0"",""2"",""8"",""2"",""4"",""14"",""23"",""38"",""13"",""21"",""51"",""28"",""16"",""6"",""6"",""3"",""8"",""2"",""39"",""53"",""7"",""30"",""14"",""38"",""37"",""45"",""66"",""25"",""5"",""37"",""19"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2020-06-22T22:54:25Z""
""Last-Modified"",""2020-06-22T22:54:25Z""
""dcterms:modified"",""2020-06-22T22:54:25Z""
""title"",""""
""Last-Save-Date"",""2020-06-22T22:54:25Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2020-06-22T22:54:25Z""
""meta:save-date"",""2020-06-22T22:54:25Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is MiKTeX-pdfTeX 2.9.6642 (1.40.19)""
""Content-Length"",""574329""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""36""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""2068"",""2344"",""2560"",""2500"",""2748"",""2102"",""1736"",""1832"",""1405"",""1459"",""1341"",""2179"",""1684"",""1774"",""1791"",""1780"",""1609"",""2017"",""1798"",""2354"",""2091"",""972"",""2029"",""1544"",""1826"",""1390"",""2066"",""1710"",""1736"",""1876"",""1534"",""2112"",""1977"",""1340"",""1178"",""376""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-06-22T22:54:25Z""
";https://scholar.google.ch/scholar?start=680&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098720-5;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;HotDAG: Hybrid consensus via sharding in the permissionless model;CX Zhou, QS Hua, H Jin ; International Conference on Wireless Algorithms …, 2020  Springer;;"… mathcal {H}\) is a cryptographic hash function (\(\mathcal {H}\) is modeled as random oracles

in the … For any identity chain, the probability of successful execution of a random oracle query

is … Google Scholar. 6. Yu, H., Nikolic, I., Hou, R., Saxena, P.: OHIE: blockchain scaling made …";Cité 1 fois;;null;;;;
1619098743-55;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Projekte und Einsatzbereiche der Blockchain-Technologie;C Meinel, T Gayvoronskaya ; Blockchain, 2020  Springer;;"… Ein dezentrales Teilnehmernetzwerk, Smart Contracts sowie Oracles können viele

Zwischenhändler ablösen … IBM und Maersk 31 präsentierten am 9. August 2018 ihre

Blockchain-basierte 32 Lösung für die Schifffahrts- und Logistikindustrie …";Autres articles;;null;;;;https://scholar.google.ch/scholar?start=600&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098848-292;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Orchestrating product provenance story: When IOTA ecosystem meets electronics supply chain space;S Suhail, R Hussain, A Khan, CS Hong ; Computers in Industry, 2020  Elsevier;;"… Rationale for adopting IOTA in the supply chain in contrast to mainstream Blockchain … In this regard,

Blockchain – an advanced Distributed Ledger Technology (DLT) works well to address these

challenges by linking fragmented and siloed SC events in an immutable audit trail …";Cité 12 fois;Les 6 versions;[PDF] arxiv.org;https://arxiv.org/pdf/1902.04314;"
Orchestrating Product Provenance Story: When IOTA Ecosystem
Meets The Electronics Supply Chain Space

Sabah Suhaila,˚, Rasheed Hussainb, Abid Khanc, Choong Seon Honga

aDepartment of Computer Science and Engineering, Kyung Hee University, South Korea.
bNetworks and Blockchain Lab, Innopolis University, Russia.

cDepartment of Computer Science, Aberystwyth University, United Kingdom.

Abstract

“Trustworthy data” is the fuel for ensuring transparent traceability, precise decision-making, and
cogent coordination in the Supply Chain (SC) space. However, the disparate data silos act as a
trade barrier in orchestrating the provenance of the product lifecycle; starting from the raw ma-
terials to end products available for customers. Besides product traceability, the legacy SCs face
several other problems including, data validation, data accessibility, security, and privacy issues.
Blockchain as one of the advanced Distributed Ledger Technology (DLT) addresses these challenges
by linking fragmented and siloed SC events in an immutable audit trail. Nevertheless, the challeng-
ing constraints of blockchain, including, but not limited to, scalability, inability to access off-line
data, vulnerability to quantum attacks, and high transaction fees necessitate a new mechanism to
overcome the inefficiencies of the current blockchain design. In this regard, IOTA (the third gener-
ation of DLT) leverages a Directed Acyclic Graph (DAG)-based data structure in contrast to linear
data structure of blockchain to bridge such gaps and facilitate a scalable, quantum-resistant, and
miner-free solution for the Internet of Things (IoT) in addition to the significant features provided
by the blockchain. Realizing the crucial requirement of traceability and considering the limitations
of blockchain in SC, we propose a provenance-enabled framework for the Electronics Supply Chain
(ESC) through a permissioned IOTA ledger. To identify operational disruptions or counterfeiting
issues, we devise a transparent product ledger constructed based on trade event details along with
timestamped sensory data to track and trace the complete product journey at each intermediary
step throughout the SC processes. We further exploit the Masked Authenticated Messaging (MAM)
protocol provided by IOTA that allows the SC players to procure distributed information while
keeping confidential trade flows, ensuring restrictions on data retrieval, and facilitating the integra-
tion of fine-grained or coarse-grained data accessibility. Our experimental results show that the time
required to construct secure provenance data aggregated from multiple SC entities takes on average

˚Corresponding author
Email addresses: sabah@khu.ac.kr (Sabah Suhail ), r.hussain@innopolis.ru (Rasheed Hussain),

abidkhan@comsats.edu.pk (Abid Khan), cshong@khu.ac.kr (Choong Seon Hong)

Preprint submitted to Elsevier May 14, 2020

ar
X

iv
:1

90
2.

04
31

4v
3 

 [
cs

.C
R

] 
 1

3 
M

ay
 2

02
0



3 seconds for a local node and 4 seconds for a remote node, which is justifiable. Furthermore, to
estimate the energy consumption by the IoT platform, we use Raspberry Pi 3B to ensure that the
energy consumption by the proposed scheme is admissible by resource-constrained devices.

Keywords: Blockchain, Distributed Ledger Technology, Internet of Things, Industrial Internet of
Things,, Industry 4.0, IOTA, Masked Authenticated Messaging, Provenance, Supply chain,
Trustworthy data.

1. Introduction

Electronics Supply Chain (ESC) revolves around an intricate and intensive process during which
raw materials or natural resources are transformed into circuit boards and electronic components,
integrated and assembled into end products, and ultimately made available to the customers. Such
a complex product evolution journey involving collaboration among multiple Supply Chain (SC)
participating entities, each performing different operations on a product (or its parts), may raise
several questions. For instance, how to identify the granular details of the underlying processes
such as who, when, what, where, and how the product was derived. To answer these questions, SCs
need a track and trace mechanism called provenance to construct a complete lineage of data about
products’ origin, production, modification, and custody process [1]. Provenance in SC can enable the
enterprises to choreograph their demand-supply circle, perform risk assessment, maximize revenues,
investigate reasons for product recalls, and forecast their future goals. Furthermore, provenance
ensures the integrity of data during data debugging, reconciliation, replication, decision making,
performance tuning, auditing, and forensic analysis [2, 3, 4, 5, 6]. However, procuring product
provenance data is an exhaustive task which gives rise to several other challenging issues concerning
the collection, distribution, accessibility, and security of data. For instance, (i) how to collate
provenance data from disparate data silos, complex data aggregation processes, and on-premise
operational practices and procedures, (ii) how to assure integrity, reliability, and resiliency of data,
(iii) how to ensure the distributed data accessibility and availability to legitimate participating
entities, and many more.

Due to the unavailability of a platform that can provide one-size-fits-all solution to orchestrate
product provenance story, it is hard to differentiate between reliable and counterfeit products. To
this end, the proliferation of counterfeit products deteriorates consumer trust and also causes repu-
tational damage to the company’s image. For instance, defense system manufacturers face difficulty
in detecting counterfeit items, as counterfeiters attempt to imitate materials, part numbers, and
serial numbers to simulate authentic parts [7]. Similarly, Integrated Circuits (ICs) counterfeiting
has been observed in many industrial sectors, including computers, telecommunications, and au-
tomotive electronics [8]. For example, in 2018 Orange County electronics distributor was charged
with selling counterfeit integrated circuits for military and commercial use [9]. To mitigate the risk

2



effectively across the SC, atomistic sources of risk are required that involves scrutinizing a restricted
part of the SC and is suitable for low-value and less complex components. Alternatively, holistic
sources of risk are required that involves a comprehensive analysis of the SC and is preferable for
high-value and complex components [10]. In both of these cases, contingency planning is required
to identify the root cause of operational disruption and to identify the fraudulent middleman.

The inception of Distributed Ledger Technology (DLT) solves SC challenges by facilitating
distributed, immutable, transparent, and fault-tolerant data aggregation across multiple entities
(both physical and digital) [11]. In this regard, the blockchain-based architecture is used as a
potential solution to fulfill the digital SC requirements in a plethora of SC use-cases (as discussed
in Table 1). Table 1 outlines the current research efforts that use blockchain-based solutions for SC
use-cases while considering their security aspects.

However, the current blockchain solutions lack many striking features such as scalability, of-
fline data accessibility, fee-less transactions, and quantum-immunity that are among the desirable
features in digital SC. To adequately address these limitations, IOTA [12] brings a transformation
in the third generation of DLT. Following a scalable and quantum-immune approach, it securely
accelerates tracking and tracing of multiple trade events in the SC even in the offline mode, and
consequently enhance provenance data construction to identify counterfeit products.

In this paper, we propose an IOTA-based framework for supporting provenance in the ESC.
By integrating the Masked Authenticated Messaging (MAM) protocol on top of IOTA (as shown
in Fig. 1), our proposed framework provides transparent traceability of data throughout the SC
ensuring trustworthy and quality data.

IOTA
Transport Layer

Masked Authenticated Messaging

Supply Chain Space

Application Layer

Service Layer

Figure 1: Abstract-level overview of the proposed framework.

The main contributions of this paper are summarized as follows.

• We present a technological evolution of the SC management system starting from legacy
systems to the state-of-art DLT. We also investigate the significance of integrating provenance
in the ESC and address the research gaps and highlight the key factors for adopting IOTA in
the SC in comparison to existing blockchain-based solutions.

• For product traceability, we propose an IOTA-based provenance framework that encapsulates
the diverse product story as provenance data at each intermediary process in the ESC. Such a

3



strategy solves the product counterfeiting issue in addition to the problem of fragmented and
asymmetric information. To address the security issues, the MAM channel is leveraged to
ensure confidential trade flow among competitors, to preserve data integrity, and to provide
fine-grained data access to the trusted SC players only.

• Finally, we evaluate and show that the proposed scheme in terms of attaching SC data to the
IOTA ledger and constructing provenance data by fetching data for varying payload sizes is
admissible for the ESC. Furthermore, we develop a proof-of-concept for the proposed scheme
on the Raspberry Pi 3B hardware platform to mimic the IoT-integrated ESC and analyze
the measured average time and energy consumption incurred during attaching and fetching
provenance data from the IOTA tangle which we find justifiable for resource-constrained IoT
devices deployed in the SC.

The rest of the paper is organized as follows. Section 2 surveys related work. Section 3 provides an
overview of IOTA, SC, and discusses the significance of integrating IOTA to support provenance in
SC. Section 4 introduces the system model and Section 5 describes the proposed IOTA framework
for the ESC. Section 6 presents the simulation results and discusses the security analysis of the
proposed approach. Finally, Section 7 concludes the paper with an outlook on future work.

4



Table 1: Current research efforts pertaining to blockchain-based solutions for SC use-cases and their security aspects.

SC Technical Challenges
SC Category Scheme D C I A S AC Audit T OFD IoT/IIoT BCID QI

Food/Agriculture [13] 3 3 3 3 a 7 7 7 7 a 7 7
[14] 3 3 3 3 7 7 7 7 7 7 7 7
[15] 3 3 3 3 3 3 3 7 7 3 3 7
[16] 3 3 3 3 a 7 7 7 7 3 3 7
[17] 3 3 3 3 7 7 7 7 7 a 7 7
[18] 3 3 3 3 7 7 7 7 7 a 7 7

Pharmaceutical/Healthcare [19] 3 3 3 3 3 7 7 7 7 7 a 7
[20] 3 3 3 3 7 a a 7 7 7 7 7
[21] 3 3 3 3 7 7 a 7 7 3 3 7

Electronics [22] 3 3 3 3 a 3 3 a 7 7 3 7
[23] 3 3 3 3 a a 7 a 7 3 7 7

Generic [24] 3 3 3 3 7 3 7 a 7 7 3 7
[25] 3 3 3 3 3 3 a 7 7 7 3 7
[26] 3 3 3 3 7 a 7 7 7 3 3 7
[27] 3 3 3 3 3 3 3 7 7 3 3 7

a=discussed but details are not provided.
D=Distributed, C=Confidentiality, I=Integrity, A=Availability, S=Scalability, AC=Access Control,
Audit=Auditability, T=Trust, OFD=Off-line data, BCID=Blockchain Implementation Details, QI=Quantum Immune.

5



2. Related Works

In this section, we discuss the existing solutions for SC.

2.1. Legacy Systems: Enterprise Software Solutions for SC

In literature, many works analyzed the limitations of ERP systems. For example, [28] discussed
the reasons for ERP dissatisfaction including, huge storage and networking requirements, training
overheads, business process re-engineering, and software-related customization tasks. [29] identi-
fied disadvantages of ERP such as privacy concerns, high cost of ERP software incurred during
the implementation, maintenance, upgrading, and time-consuming customization, to name a few.
Similarly, in [30], the authors discussed ERP system misfits (in terms of data, functional, and
output) that arise from incompatibilities between ERP packages and organizational requirements.
In addition to the aforementioned drawbacks, handling transactions in ERP systems are complex
and rampant because each organization maintains its own ledger. Due to this fact, information
discontinuity and desynchronization as a weak link may increase the possibility of human error or
fraud whereas reliance on a middleman for validation leads to inefficiencies.

2.2. Cloud-Based Solution for SC

In comparison to ERP systems, cloud-based solutions, for instance, Software as a Service–SaaS,
are plugged into SC to provide several benefits including fault tolerance, high availability, scalability,
flexibility, reduced overhead for users, reduced cost of ownership, on-demand services, etc. [31].
However, the adoption of cloud-based solutions may create new risks to the SC. For instance,
trusting a third-party platform to store confidential information related to SC system, applications,
and customer data can raise security and privacy issues [32, 33]. Similarly, storing data or sensor
values in a secure and confidential manner is still under question in cloud-based solutions. Hence,
introducing cloud-based solutions raise significant concerns about privacy, security, data integrity,
intellectual property management, audit trails, compatibility, and reliability [34, 35]. Moreover,
in case of a cloud service outage, all SC operations will have a catastrophic effect on the data
availability and ultimately deteriorate the overall performance of the system [36, 37].

2.3. DLT-Based Solution for SC

The imperative transition to adopt DLT in SC received significant attention in recent years as
a solution to many challenges stemmed from the existing legacy system and privacy issues due to
the multi-party access [38]. In this regard, the nascent technology of blockchain allows companies
to record every event within a SC on a distributed ledger that is shared among all participants, not
owned by anyone, solve important glitches in traceability, and record events in a secure, immutable,
and irrevocable way.

6



Blockchain has a very constructive role in SC from different perspectives. For instance, blockchain
can provide design decisions and solve technical challenges (as shown in Fig. 5) faced by SC. Fur-
thermore, blockchain-based architecture for SC that leverages public or private blockchain, can use
different platforms such as Ethereum, Hyperledger Fabric, and Ripple. Many promising blockchain-
enabled solutions have been proposed in literature where blockchain is leveraged in SC across dif-
ferent industries, for instance, food, agriculture, pharmaceutical, electronics SCs, to name a few. In
Table 1, we summarized technical blockchain-based solutions for various SC categories (application-
specific or generalized solutions) and associated shortcomings either in the context of the proposed
scheme or the blockchain in particular. In Industry 4.0, blockchain can automate processes among
IIoT, cyber-physical systems, and supply partners [39]. For example, [40] discusses the integration
of blockchain into the manufacturing industry for data integrity and resilience. Similarly, in [41],
the authors propose a block-chain based platform for small and medium manufacturing enterprises
(SMEs) to solve issues such as security, scalability, and big data problems.

In the following, we discuss non-technical works in literature that focus on the technical and
non-technical challenges of blockchain-based deployed systems in SCs, for example, in [42], the au-
thors highlight technical, educational, and regulatory challenges and barriers in agriculture and food
SCs. In [43], the authors discuss open research challenges in blockchain-based use-cases, including
the Internet of Medical Things (IoMT), healthcare data management, and SC management. Fur-
thermore, the authors of [44] also provide an overview of the challenges associated with blockchain
adoption and deployment for the health SC with a focus on pharmaceutical, Internet of Healthy
Things (IoHT), and public health. In [45], the authors discuss the factors that bring a positive
impact on blockchain-based ESC. Similarly, many other use cases are discussed in [46, 47, 48, 49].

Recently, various worldwide enterprises have played a significant role in providing blockchain-
based platforms for supporting friction-less traceability and transparency in SC, for instance, IBM’s
blockchain framework [50] has been adopted by Walmart, Nestle, Unilever, and other players in the
global Food Supply Chain (FSC) [51]. Other notable blockchain-enabled SC frameworks include
Hyperledger [52], skuchain [53], Provenance [54], Blockverify [55], Multichain [56], etc. However, the
proprietary and private blockchain-based solutions are unable to address the specific requirements
or needs in the public domain and portray blockchain as a black-box.

2.4. Limitations of Blockchain in SC

Most of the blockchain-based solutions adopted for SC theoretically cover advantages, poten-
tial challenges, and future directions [57, 58, 59, 60, 61]. However, the underlying constraints of
blockchain are overlooked by the current solutions. Among other constraints, quantum-resistance
and scalability are noteworthy. Ongoing efforts to address these potential issues are underway, for
instance, to meet the challenging requirement of quantum future, some of the emerging blockchain
solutions that already support post-quantum techniques are Quantum Resistant Ledger (QRL) [62],

7



Corda [63], Quantum-secured blockchain [64], and DL-for-IoT [65], etc. Solutions such as shard-
ing and off-chain are expected to solve the scalability problem of the blockchain. However, these
solutions have their own drawbacks. For instance, sharding requires to synchronize the running of
operations among different processes on different shards. Furthermore, the overheating of a targeted
single shard due to many cross-shard transactions is another problem that requires the ranking of
these transactions to prevent overloading of block producers on the target shard. Similarly, off-chain
solutions suffer from the following limitations: (i) introduce additional layers of complexity as the
protocols are built on the top of the blockchain, (ii) may face objection by government and busi-
ness communities due to their censorship-resistant nature. Directed Acyclic Graph (DAG)-based
blockchain design is another effort to overcome the scalability issue caused by the sequential chain-
based design of the traditional blockchain [66]. The authors of [67, 68, 69] provide a comparative
analysis of DAG-based blockchain schemes.

Many of current research works are assuming, though some with skepticism, that blockchain
technology will be adopted in the SC industry. For instance, some of their concerns are as follows:
considering the connection between physical and digital world, how to ensure the reliability of data
from SC entities and sensors [70], security concerns due to quantum computing and latency issues
with the increasing number of nodes in the network [71, 72], lack of privacy and Garbage In Garbage
Out (GIGO) problem [11], lack of information leading to existence of gray markets [66] and decision
paralysis due to information overload, etc. But paradoxically on the other side, solutions such as
[1, 59, 73, 57, 60, 74, 75] focus on the significance of using blockchain in SC. Overall, most of the
proposed schemes (discussed in Table 1) failed to address the potential current problem (such as
scalability) and future issues (such as quantum-resistance) of blockchain. Moreover, other technical
requirements of SC such as accessibility and auditability based on roles and access levels, are also
overlooked.

The common denominator among DLTs is their reliance on a distributed, decentralized peer-to-
peer network, and consensus mechanism. However, DLTs vary substantially in terms of the underly-
ing data structure, fault tolerance, and consensus approaches [76]. In addition to blockchain and its
different flavors, other well-known DLTs are tangle, hashgraph [77], sidechain, and holochains [78].
In [76], the authors provide a comparative analysis of DLTs, whereas, in [68], the authors compare
classical blockchain with DAG-based blockchain. Considering the primary challenge, i.e., scala-
bility, faced by blockchain-based solutions in SCs, we consider a DAG-based DLT, i.e., IOTA. In
comparison to other DLTs, IOTA exhibits quantum immune nature, provides off-line data accessi-
bility, and supports fee-less microtransactions that are important factors for future SCs. Some of
the striking features of IOTA DLT are discussed in Section 3.3.3.

8



2.5. Our Research Contributions

In the presence of the existing research, we highlight the main contributions of our work. This
research is aimed to highlight the current research gaps in SCs and propose a state-of-the-art
approach to resolve them. Though the existing blockchain-based solutions for SC has solved the
primitive problems associated with disjoint data fragments, third party dependency, data security,
and many other problems related to legacy systems. Nevertheless, there are still a few issues with
the existing solutions that need to be addressed. In this regard, our contributions include the
following key factors that are required to incorporate in a DLT-enabled SC.

Firstly, why the transition from the mainstream blockchain to IOTA is required? We adopt
IOTA DLT upon realizing the overlooked constraints of blockchain. For instance, scalability issues
particularly in case of growing participating entities; accessing data from freights in remote areas or
off-line mode; dealing with transaction fees, and finally reliance on the security of current crypto-
graphic primitives keeping in view the not-so-far arrival of quantum computers. The details about
such constraints are discussed in Section 3.3.3. Secondly, how to create transparency towards the
consumers? To win consumer trust, it is important to give them a sheer picture of the product
journey. We devise a mechanism that involves reconstructing a trustworthy product provenance
story, thus enabling customers to drive a real change. Thirdly, how to define customized data access
control rights? We use the MAM protocol to provide fine-grained data access privileges to facili-
tate the trade secrets of participating entities. Fourthly, how to identify counterfeit products? We
construct provenance data such that it includes complete information to identify the illegitimate or
defective item.

For illustrative purposes, we consider the example of mobile phones in ESC. While keeping
the underlying framework same, the proposed model is suitable for any commodity in ESC. Fur-
thermore, it can be customized to other non-electronics SCs (for example, food-agriculture, phar-
maceuticals) keeping in view the diverse requirements driven by their specific business needs and
additional information (e.g., expiry dates or any other precautionary measures). For instance,
food-agriculture, pharmaceuticals, or any other cold chain differs from ESC as they are subject to
sensitive temperature and environmental conditions necessary to maintain the quality of perishable
items in terms of temperature, humidity, etc. Similarly, ESC differs from other SCs based on qual-
ity testing, such as expiry period in case of cold chains are completely different from the warranty
period determined through failure testing/product life testing of electronic components. Other dif-
ferences include the packaging and assembling of components at various stages. Such requirements
of cold SCs can be facilitated through our proposed model by continuous monitoring and reporting
of the sensor data at frequent intervals to ensure the quality of products while allowing the inte-
gration of any optional information. Therefore, by tweaking the parameters based on the details of
the underlying SC case, the proposed framework can be applied to any other SC.

9



3. IOTA in SC: An Overview

In this section, we provide a quick overview of the key terms in IOTA and SC. We also emphasize
on using IOTA DLT in the SC.

3.1. IOTA

IOTA is a public, permissionless, and a distributed ledger that leverages directed acyclic graph
(DAG) data structure termed as tangle for storing interlinked but individual transactions exchanged
among peers [12]. Fig. 2 shows a tangle graph where each square-block represents a transaction/site
which is propagated by a node. Every new transaction attached to the tangle graph forms an edge
set. To create a transaction, a node (i) creates and signs a transaction with its private key, (ii)
use the Markov Chain Monte Carlo (MCMC) algorithm [79] to choose and validate two other
non-conflicting unconfirmed transactions (tips), and (iii) solve a cryptographic puzzle (known as
Hashcash [80]) to perform Proof of Work (PoW) for preventing Sybil attack. Transaction status
can be categorized as confirmed transactions (green nodes), uncertain transactions (red nodes), and
unconfirmed transactions or tips (grey nodes) as shown in Fig. 2. The revolutionary features of
IOTA including scalability, decentralization, zero transaction fee, speedy microtransactions, off-line
capability, and quantum security enables it to gain ground not only in Machine-to-Machine (M2M)
economy but also in application areas encompassing IIoT.

Confirmed Transaction

Tip/Unconfrimed Transaction

time

Uncertain Transaction

Edge

Site/TransactionB

A

E

F

D

C

G

I

H

Figure 2: Tangle graph illustrating transactions and edge set connecting transactions.

3.2. Supply Chain System

Supply chain encompasses coordination and collaboration among channel partners (suppliers, in-
termediaries, third-party service providers, and customers) for planning and managing of upstream
and downstream process-based activities such as the transformation of natural resources/raw ma-
terials, sourcing, procurement, production, conversion, and logistics [81]. Fig. 3 shows the primary
entities involved in the production of mobile phones in the ESC.

10



Warehouse

Retailer Customer

Manufactur ing Unit

SupplierRaw Producters

Silicone

Polypropylene
Rubber

Aluminium

Glass

Figure 3: Electronic supply chain showing participating players involved in supply chain processes.

3.3. Motivation: Integrating Provenance Support in the Electronics Supply Chain Through IOTA

SCs empower participants for collaborative commerce in a global value chain. A product (for
instance, mobile phone) journey from sand to hand, comprise of numerous chained phases during
which components are produced, sourced, refined, integrated, and assembled by multiple entities
ubiquitously. Nevertheless, numerous friction points thwart SCs from accomplishing their max-
imum potential, for instance, opaque mechanics of global commerce, complexity (upstream and
downstream), manual processes, and divergent standards. Furthermore, SCs are held back by
imperfect and asymmetric information as huge volumes of veracious data are inaccessible to the
SC players during cross-border trading resulting in communication gaps, increased costs, forfeited
data, erroneous data aggregation, scattered information, market failures, or absence of markets
at all. Therefore, it can be concluded that a sustainable SC stipulates two pivotal features to be
incorporated: (i) Product story (ii) Orchestrating episodes of product story.

3.3.1. Provenance: Product Story

To trace the audit trail of data, provenance plays a significant role in constructing a ""product
story"" throughout the SC. The product story (or product traceability) enables the seller-buyer pair
to trace the product from its inventory procurement process to its point of sale and hence provides
an efficient way for tackling counterfeits or determine liability in the event of faulty records. For

11



instance, upon scanning the Quick Response (QR) code, the consumer can look at the product
story.

3.3.2. IOTA: Orchestrating Episodes of Product Story

Relying solely on provenance to notch trustworthy data is not sufficient, therefore, to efficiently
and proactively systematize the product story in terms of provenance data, we collocate the product
story episodes in a tamper-proof product ledger perpetuated by IOTA. IOTA is a promising tech-
nology that could play an indispensable role in providing salient features desirable for SC including
decentralized, distributed, and interoperable data stream to consortium members. Furthermore, it
provides data auditability to identify accountable actors causing data contamination, reasonable
confidentiality and privacy of the trade flows, facilitating access control on immutable and trust-
worthy data. In essence, coalescing real-time provenance data through resource-constrained sensors
(such as track and trace of precise location information, transfer of custody, monitoring environ-
mental conditions or temperature fluctuations during storing and shipping product through GPS,
RFID tags, temperature sensors, humidity sensors, etc.) that can drive decision-making power
during risk mitigation forecasting.

3.3.3. Striking Features of IOTA

IOTA leads to a paradigm shift in the third generation of DLTs by providing a solution to the
challenging constraints encountered by the blockchain. In essence, the IOTA platform breaks out
the blockchain trilemma as it exhibits the following salient features essential to SC in contrast to
the blockchain.

1. Scalability: In the SC space, the transaction load is expected to increase based on actors
and activities in the network over time. Traditional blockchain runs into scaling snag as the
transactions and the validation of said transactions are siloed and often at odds with each
other. A permissioned blockchain has the potential to scale to a few hundred nodes [82],
which may affect the latency and throughput of the network. For instance, the processed
transactions per second (TPS) of the mainstream blockchain platforms like Bitcoin (7 TPS)
and Ethereum (15 TPS) is very limited because the blocks cannot be created simultaneously
due to a single linear chain of blocks [83]. To address the problem of scalability, [82, 84, 85] used
the concept of sharding single blockchain ledger i.e., processing of transactions is distributed
across multiple nodes in parallel. However, the block-less design of IOTA scales horizontally
can theoretically improve transaction efficiency and claims to resolve the problem of scalability
without any need to take care of global and local ledgers.

2. IOTA for IoT: Cost-effective miniaturized things or objects with storage, computational,
and networking capabilities are providing promising solutions to optimize myriad events of

12



track-and-trace in the supply cycle. Such synergistic integration of IoT and SC results in the
cyber-physical system concept of Industry 4.0 [86]. However, IoT-linked security crises may
breach the system security making it vulnerable to attacks, for instance, NotPetya, Stuxnet,
PyPi, ShadowPad, and many other SC attacks. To cope with such situations, IOTA provides
a high end-to-end security level called Masked Authenticated Messaging (MAM) protocol that
facilitates encrypted data communication and securely anchors it to the tangle in a quantum-
proof fashion. Moreover, through the MAM channel, access privileges can be tailored, thereby
making it a perfect platform to build tomorrow’s trade facilitation systems in SC.

3. Off-line transaction: IOTA supports the off-line capability for handling scenarios such
as information retrieval from remote areas and sensors on a container of a freighter ship
that loses connectivity during ocean transportation. This mechanism is called ""partitioning""
during which a tangle in IOTA can get branch off by creating an off-line cluster and back into
the network upon Internet connectivity, thereby securing the local transactions.

4. Speedy and zero-fee transactions without miners: Blockchain can be used for payments
in many notable application areas. However, PoW based blockchains [87] require transaction
fees due to the presence of miners and are not suitable for micropayments. Similarly, private,
permission-based blockchains are lightweight [88] but lack important properties for PoW based
blockchains, such as censorship resistance [89]. Unlike blockchains, IOTA is based on the
concept of users equal to validators. IOTA is free from miners i.e., all participants need to
contribute their computation power to maintain the network and hence does not charge any
transaction fee. Furthermore, by enabling transactions to be validated in parallel, IOTA has
the highest TPS among other distributed ledger.

Figur";"""date"",""2020-05-14T00:37:49Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2020-05-14T00:37:49Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016) kpathsea version 6.2.2""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2020-05-14T00:37:49Z""
""created"",""2020-05-14T00:37:49Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-05-14T00:37:49Z""
""resourceName"",""1902.04314""
""Author"",""""
""producer"",""pdfTeX-1.40.17""
""pdf:docinfo:producer"",""pdfTeX-1.40.17""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""163"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2020-05-14T00:37:49Z""
""Last-Modified"",""2020-05-14T00:37:49Z""
""dcterms:modified"",""2020-05-14T00:37:49Z""
""title"",""""
""Last-Save-Date"",""2020-05-14T00:37:49Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2020-05-14T00:37:49Z""
""meta:save-date"",""2020-05-14T00:37:49Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016) kpathsea version 6.2.2""
""Content-Length"",""1631777""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""47""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""2533"",""2740"",""2282"",""1161"",""692"",""2414"",""2942"",""2696"",""2826"",""1766"",""1522"",""2445"",""1718"",""2352"",""823"",""2566"",""1349"",""646"",""2592"",""1714"",""2374"",""1846"",""1926"",""2254"",""1680"",""1414"",""2011"",""1528"",""1112"",""1951"",""1218"",""1809"",""2699"",""2667"",""2527"",""2094"",""2007"",""1866"",""1934"",""1852"",""1840"",""2042"",""2034"",""1972"",""1937"",""1847"",""729""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-05-14T00:37:49Z""
";https://scholar.google.ch/scholar?start=840&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098804-192;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Demistificare gli smart contracts;AU Janssen, FP Patti ; Osservatorio del diritto civile e commerciale, 2020  rivisteweb.it;;"… la questione relativa alla gestione del rapporto a un soggetto terzo (un oracle). Ciň avvicine-

rebbe il funzionamento dello smart contract a quello di un contratto tradizionale. In merito agli

oracles, v. anche infra par. 6. 40 Cfr. AJ Kolber, Not-So-Smart Blockchain Contracts and …";Autres articles;;[PDF] academia.edu;https://www.academia.edu/download/64589608/Demistificare%20gli%20smart%20contracts.pdf;;;https://scholar.google.ch/scholar?start=740&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098751-73;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;???????????? ????????????? ???????? ????????? ??????? ????????? (?????-??????????) ?? ??????? ?????? ? ?????????? ?????;?? ???????? ; ????????????????????? ?????, 2020  elibrary.ru;;"… provisions of approaches to the legal regulation of network contracts (smart contracts) developed

in the new technological reality, taking into account the experience of foreign countries and the

Russian Federation that determine the acceptability of the use of blockchain in the …";Cité 1 fois;;null;;;;https://scholar.google.ch/scholar?start=620&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098765-110;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Designing Trustworthy Smart Contracts in International Trade Blockchains;RWH Bons ; German and Chinese Contributions to Digitalization, 2020  Springer;;"… the participants must somehow interact with the node to make the “real world” connections through

Oracles … Work is ongoing to include the main features offered by blockchain technology into the

framework, in … Bitcoin: Hacking coinbase, cryptocurrency's “Goldman Sachs.” Retri …";Autres articles;;null;;;;https://scholar.google.ch/scholar?start=650&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098809-204;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;[CITATION][C] Smart Contracts. Wesentliche rechtliche Aspekte, insbesondere bei Leistungsstörungen;TH Rodenberg ;2020 GRIN Verlag;;null;Autres articles;;null;;;;https://scholar.google.ch/scholar?start=750&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098888-381;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;[PDF][PDF] Enhancing Trust in Devices and Transactions of the Internet of Things;C Profentzas ;2020 core.ac.uk;;"… Several proposals focus on third parties that act as an Oracle [18] inside the blockchain … [18]

propose an Oracle for industrial … The current data providers (eg, Oracles) do not give a direct way

for a smart contract to include sensor readings and actuators as part of a transaction …";Autres articles;Version HTML;[PDF] core.ac.uk;https://core.ac.uk/download/pdf/326728301.pdf;"
Thesis for The Degree of Licentiate of Engineering

Enhancing Trust in Devices and Transactions of
the Internet of Things

Christos Profentzas

Department of Computer Science and Engineering
Chalmers University of Technology

Gothenburg, Sweden, 2020



Enhancing Trust in Devices and Transactions of the Internet of
Things
Christos Profentzas

Copyright Š Christos Profentzas, 2020.

Technical Report No 210L
ISSN 1652-876X
Department of Computer Science and Engineering
Chalmers University of Technology
SE-412 96 Gothenburg
Sweden

This thesis has been prepared using LATEX.
Printed by Chalmers Reproservice,
Gothenburg, Sweden 2020.



“I rebel; therefore I exist.”- A. Camus



iv



Enhancing Trust in Devices and Transactions of the Internet of
Things
Christos Profentzas
Department of Computer Science and Engineering
Chalmers University of Technology

Abstract

With the rise of the Internet of Things (IoT), billions of smart embedded devices
will interact frequently. These interactions will produce billions of transactions.
With IoT, users can utilize their phones, home appliances, wearables, or any
other wireless embedded device to conduct transactions. For example, a smart
car and a parking lot can utilize their sensors to negotiate the fees of a parking
spot. The success of IoT applications highly depends on the ability of wireless
embedded devices to cope with a large number of transactions. However, these
devices face significant constraints in terms of memory, computation, and
energy capacity.

With our work, we target the challenges of accurately recording IoT trans-
actions from resource-constrained devices. We identify three domain-problems:
a) malicious software modification, b) non-repudiation of IoT transactions, and
c) inability of IoT transactions to include sensors readings and actuators. The
motivation comes from two key factors. First, with Internet connectivity, IoT
devices are exposed to cyber-attacks. Internet connectivity makes it possible
for malicious users to find ways to connect and modify the software of a device.
Second, we need to store transactions from IoT devices that are owned or
operated by different stakeholders.

The thesis includes three papers. In the first paper, we perform an empirical
evaluation of Secure Boot on embedded devices. In the second paper, we
propose IoTLogBlock, an architecture to record off-line transactions of IoT
devices. In the third paper, we propose TinyEVM, an architecture to execute
off-chain smart contracts on IoT devices with an ability to include sensor
readings and actuators as part of IoT transactions.

Keywords: Internet of Things, Distributed Systems, Blockchain, Smart Con-
tracts, Embedded Systems, Secure Boot



vi



Acknowledgment

First, I would like to thank Lovisa for her love and her support. I would like
to thank my family and especially my mother for her support to carry on my
studies.

I would like to thank my supervisors Olaf and Magnus for their support and
effort to this thesis. I would like to thank the administrators Monica, Rebecca,
Marianne and Eva for their help. Finally, I would like to thank my colleagues
and especially Georgia, Hannah, Dimitris, Babis, Bastian, Thomas, Karl, Carlo
and Beshar that make Chalmers workplace a fun and interesting environment.

Funding sources. This work is supported by the Swedish Research Coun-
cil (VR) through the project “AgreeOnIT”, the Swedish Civil Contingencies
Agency (MSB) through the project “RIOT”, and the Vinnova-funded project
“KIDSAM”.

Christos Profentzas,
Gothenburg, May 2020

vii



viii



List of Publications

Appended publications

This thesis is based on the following publications:

[A] Christos Profentzas, Mirac Günes, Yiannis Nikolakopoulos, Olaf Land-
siedel, Magnus Almgren, “Performance of Secure Boot in Embedded
Systems”, Proceedings of the 1st International Workshop on Security
and Reliability of IoT Systems (SecRIoT), part of: IEEE International
Conference on Distributed Computing in Sensor Systems (DCOSS) 2019.

[B] Christos Profentzas, Magnus Almgren, Olaf Landsiedel, “IoTLog-
Block: Recording Off-line Transactions of Low-Power IoT Devices Using
a Blockchain”, Proceedings of the 44th IEEE Conference on Local Com-
puter Networks (LCN) 2019.

[C] Christos Profentzas, Magnus Almgren, Olaf Landsiedel, “TinyEVM:
Off-Chain Smart Contracts on Low-Power IoT Devices”, Accepted for
publication by the 40th IEEE International Conference on Distributed
Computing Systems (ICDCS) 2020.

ix



x



Contents

Abstract v

Acknowledgement vii

List of Publications ix

List of Figures xiii

List of Tables xv

1 Introduction 1
1.1 Motivation and Challenges . . . . . . . . . . . . . . . . . . . . . 2
1.2 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.2.1 Blockchain . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2.2 Smart Contract . . . . . . . . . . . . . . . . . . . . . . . 4
1.2.3 Security Properties . . . . . . . . . . . . . . . . . . . . . 5

1.3 Domain Problems . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3.1 Malicious Software Modification . . . . . . . . . . . . . 5
1.3.2 Non-Repudiation of IoT Transactions . . . . . . . . . . 6
1.3.3 Sensor Readings and Actuators as part of IoT Transactions 8

1.4 Research Questions . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.5 Scope and Delimitation . . . . . . . . . . . . . . . . . . . . . . 10
1.6 Thesis Contributions . . . . . . . . . . . . . . . . . . . . . . . . 10

1.6.1 Device Firmware Verification (Paper A) . . . . . . . . . 10
1.6.2 Recording IoT Transactions (Paper B) . . . . . . . . . . 11
1.6.3 Smart Contracts on Low-Power Devices (Paper C) . . . 12

1.7 Conclusions and Future Work . . . . . . . . . . . . . . . . . . . 12

2 Performance of Secure Boot in Embedded Systems 15
2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.2 Background and Definitions . . . . . . . . . . . . . . . . . . . . 17
2.3 Adversary Model . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.4 Systems Overview . . . . . . . . . . . . . . . . . . . . . . . . . 20

2.4.1 Software-based Secure Boot with U-Boot . . . . . . . . 20
2.4.2 Hardware Security for Secure Boot . . . . . . . . . . . . 22

2.5 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.5.1 Experimental Setup . . . . . . . . . . . . . . . . . . . . 23
2.5.2 Evaluation Results . . . . . . . . . . . . . . . . . . . . . 23

xi



xii CONTENTS

2.5.2.1 Software Mechanism of U-Boot . . . . . . . . . 24
2.5.2.2 TPM Hardware on BeagleBone . . . . . . . . . 25

2.5.3 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.6 Limitations and Discussion . . . . . . . . . . . . . . . . . . . . 26
2.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.8 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3 IoTLogBlock 29
3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.2 Overview and Background . . . . . . . . . . . . . . . . . . . . . 32

3.2.1 Contract Signing Protocols . . . . . . . . . . . . . . . . 32
3.2.2 Smart Contracts . . . . . . . . . . . . . . . . . . . . . . 33
3.2.3 Blockchains and Hyperledger . . . . . . . . . . . . . . . 33

3.3 Application Scenario and Adversary Model . . . . . . . . . . . 34
3.3.1 Application Scenario . . . . . . . . . . . . . . . . . . . . 34
3.3.2 Adversary Model . . . . . . . . . . . . . . . . . . . . . . 34

3.4 System Design . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.4.1 Design Overview . . . . . . . . . . . . . . . . . . . . . . 35

3.4.1.1 Node discovery and node interaction (1*) . . . 35
3.4.1.2 Interaction between nodes and the cloud . . . 35
3.4.1.3 Verification and storage in the cloud (2*, 3*) . 35

3.4.2 Setup: Deploying new Devices . . . . . . . . . . . . . . 36
3.4.3 Creating and Signing Transactions . . . . . . . . . . . . 36
3.4.4 Validation with the Smart Contract . . . . . . . . . . . 36
3.4.5 Register Transactions in the Blockchain . . . . . . . . . 37
3.4.6 Security Analysis . . . . . . . . . . . . . . . . . . . . . . 37

3.5 Experimental Evaluation . . . . . . . . . . . . . . . . . . . . . . 38
3.5.1 Implementation and Experimental Setup . . . . . . . . . 38
3.5.2 Evaluation of IoTLogBlock on the IoT Node . . . . . . 39
3.5.3 System Performance of IoTLogBlock. . . . . . . . . . . 42

3.6 Discussion and Limitations . . . . . . . . . . . . . . . . . . . . 42
3.7 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.8 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.9 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . . 45

4 TinyEVM 47
4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.2 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

4.2.1 Overview of Blockchains . . . . . . . . . . . . . . . . . . 49
4.2.2 Smart Contracts and the Ethereum Virtual Machine . . 50
4.2.3 Payment Channels . . . . . . . . . . . . . . . . . . . . . 50
4.2.4 Side-Chains . . . . . . . . . . . . . . . . . . . . . . . . . 51

4.3 TinyEVM Overview . . . . . . . . . . . . . . . . . . . . . . . . 51
4.3.1 Application Scenario: Smart Parking . . . . . . . . . . . 51
4.3.2 System Requirements . . . . . . . . . . . . . . . . . . . 52
4.3.3 System Challenges . . . . . . . . . . . . . . . . . . . . . 52
4.3.4 Threat Model . . . . . . . . . . . . . . . . . . . . . . . . 53

4.4 TinyEVM System Design . . . . . . . . . . . . . . . . . . . . . 53
4.4.1 On- and Off-Chain Transactions: Three Phases . . . . . 54



CONTENTS xiii

4.4.2 Customized Ethereum Virtual Machine . . . . . . . . . 55
4.4.3 On-Chain Smart Contract . . . . . . . . . . . . . . . . . 56
4.4.4 Off-Chain Smart Contract . . . . . . . . . . . . . . . . . 56
4.4.5 On-Chain Commit & Challenge Period . . . . . . . . . . 58

4.5 Security Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . 59
4.6 Performance Evaluation . . . . . . . . . . . . . . . . . . . . . . 59

4.6.1 Experimental Setup . . . . . . . . . . . . . . . . . . . . 60
4.6.2 Ethereum Virtual Machine on IoT Devices . . . . . . . 60

4.6.2.1 Memory Requirements . . . . . . . . . . . . . 60
4.6.2.2 Deployment Execution Time . . . . . . . . . . 62

4.6.3 Off-chain Payment Channels . . . . . . . . . . . . . . . 63
4.6.3.1 Memory Requirements. . . . . . . . . . . . . . 63
4.6.3.2 Cryptographic modules . . . . . . . . . . . . . 63
4.6.3.3 Energy consumption . . . . . . . . . . . . . . . 63

4.7 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
4.8 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
4.9 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . . 68

Bibliography 69



xiv CONTENTS



List of Figures

1.1 Parking Application Example . . . . . . . . . . . . . . . . . . . 2
1.2 Blockchain Structure . . . . . . . . . . . . . . . . . . . . . . . . 3

2.1 Boot Process of Embedded Systems . . . . . . . . . . . . . . . 17
2.2 U-Boot Configuration . . . . . . . . . . . . . . . . . . . . . . . 20
2.3 Boot Sequence with U-Boot . . . . . . . . . . . . . . . . . . . . 21
2.4 Secure Boot with a TPM . . . . . . . . . . . . . . . . . . . . . 22
2.5 The Evaluation of U-Boot . . . . . . . . . . . . . . . . . . . . . 24
2.6 Evaluation of Entire Boot Process . . . . . . . . . . . . . . . . 25

3.1 Car Rental Motivating Scenario . . . . . . . . . . . . . . . . . . 30
3.2 Signature Exchange Protocol . . . . . . . . . . . . . . . . . . . 32
3.3 Hyperledger Fabric Architecture . . . . . . . . . . . . . . . . . 34
3.4 Electric Current Drawn from Contract Signing Protocol . . . . 40
3.5 Off-line Transction Evaluation . . . . . . . . . . . . . . . . . . . 43

4.1 TinyEVM - Application Scenario . . . . . . . . . . . . . . . . . 52
4.2 TinyEVM - System Design . . . . . . . . . . . . . . . . . . . . 54
4.3 Memory Usage of Smart Contracts . . . . . . . . . . . . . . . . 61
4.4 Deploying Time of Smart Contracts . . . . . . . . . . . . . . . 62
4.5 Electric Current Drawn from Off-chain payments . . . . . . . . 66

xv



xvi LIST OF FIGURES



List of Tables

2.1 Secure Boot Terminology . . . . . . . . . . . . . . . . . . . . . 19
2.2 Secure Boot Hardware Specifications . . . . . . . . . . . . . . . 23
2.3 Verification Overhead of TPM . . . . . . . . . . . . . . . . . . . 26

3.1 Memory Footprint of IoTLogBlock . . . . . . . . . . . . . . . . 40
3.2 IoTLogBlock - Cryptographic Functions . . . . . . . . . . . . . 41
3.3 IoTLogBlock Energy Consumption . . . . . . . . . . . . . . . . 41

4.1 TinyEVM Specifications . . . . . . . . . . . . . . . . . . . . . . 55
4.2 Overview of Deployed Smart Contracts . . . . . . . . . . . . . . 64
4.3 Memory Footprint of TinyEVM . . . . . . . . . . . . . . . . . . 65
4.4 Energy Consumption of TinyEVM . . . . . . . . . . . . . . . . 65
4.5 Performance of Cryptographic Operations - TinyEVM . . . . . 66

xvii



xviii LIST OF TABLES



Part A

Introduction





Chapter 1

Introduction

In recent years, we have experienced the rapid development of major disruptive
technologies that have increased information processing and automation. One
of the most prominent technologies is the Internet of Things (IoT). With the
proliferation of IoT, billions of smart devices get connected and frequently
interact with each other and the cloud.

This connectivity will transform major parts of our society, driven by the
vast amount of data generated by connected devices. For example, a smart city
may provide smart parking applications by utilizing wireless sensors on parking
lots. In this example, a parking lot can interact with a vehicle to negotiate the
terms of parking fees. This scenario is part of a broad spectrum of applications
where smart sensors and actuators participate in billions of interactions.

In order to make these application scenarios successful, we need to investigate
two key factors. First, it is inevitable for IoT devices to be exposed to security
threats through Internet connections. For example, a malicious user can find
ways to connect to a device and modify its software. Software modifications are
especially critical in the context of IoT, as devices often control physical objects
such as the cooling system of a refrigerator, or the engine of a car. Ensuring the
integrity of the software is an essential property to enhance trust in IoT devices.
Second, we need to store billions of interactions produced by devices that are
owned or operated by different stakeholders. These interactions may be part
of several agreements and transactions. With different stakeholders in action,
each device needs to ensure a non-repudiation property of their transactions.
It is essential for the success of IoT applications that none of the stakeholders
can deny any transaction.

The remaining parts of the introduction are structured as follows. In
Section 1.1, we present the challenges related to IoT architecture. In Section 1.2,
we provide the necessary background on blockchains, smart contracts, and
security properties in the context of IoT. In Section 1.3, we provide the domain-
problems that motivated our work. In Section 1.4, we formulate the research
questions that we investigate in this thesis. In Section 1.5, we present the scope
of the thesis, and we formulate the research boundaries. In Section 1.6, we
present the contributions of the appended papers. Finally, in Section 1.7, we
conclude the introduction and present our future work.



2 CHAPTER 1. INTRODUCTION

Icons by flaticon (CC 3.0 BY)

IoT to IoT IoT to Backend

Cloud-Storage

1

2
3

Figure 1.1: The parking application scenario. 1) The car and the parking-lot
communicate via a short-range IoT protocol. 2) They reach an agreement for
the parking fee. 3) Later, at any time, they can submit the final state to the
cloud.

1.1 Motivation and Challenges

One useful feature of IoT systems is that cloud services may use Internet
connections to have access to sensor readings and actuators in remote locations.
Processing of sensor data can reveal valuable information, and often initiate
control signals to actuators. In IoT systems, it is typical to use low-cost
embedded devices with low-power consumption, able to operate autonomously
for years. These devices experience significant constraints in terms of memory,
energy, and computation capabilities. Moreover, embedded devices often have
tight latency requirements with real-time properties.

As motivation, we present an example in Figure 1.1. In this example, two
IoT devices interact with each other to negotiate parking fees. It is vital for IoT
devices to interact with a local context (e.g., sensor data) and, at a later time,
forward their interactions to the cloud where storage resources are abundant.
In this scenario, IoT devices are making their interactions into two phases.
In the first phase, IoT devices need to agree on the local conditions gathered
from sensor data to evaluate the value of an agreement. In the second phase,
IoT devices forward their interactions to the cloud, where the IoT application
ensures the agreement conditions have been fulfilled. However, IoT devices do
not trust each other, as they are commonly owned or operated by different
stakeholders. The different interests of the stakeholders increase the risk of
an inaccurate recording of IoT interactions. As these interactions may be
part of several IoT agreements and transactions, it is essential to record them
accurately.

The above scenario reveals a limitation of IoT devices to cope with a large
number of IoT transactions. There are three key proposals to address device
constraints. First, starting with the memory limitation, a way to address this
challenge is to allow IoT devices to forward their transactions to the cloud, where



1.2. BACKGROUND 3

Previous
Block

Transactions

Hash 

Transactions

Hash 
Previous

Block

Figure 1.2: The structure of a blockchain: each block is linked with the
previous block using its cryptographic hash value. Each block consists of
several transactions.

hardware resources are abundant. However, cloud models face a scalability
issue and fail to handle a large number of transactions. It is infeasible to send
billions of transactions from IoT devices to the cloud, without exhausting the
available bandwidth. Second, a way to overcome the bandwidth limitation
is the proposal of edge computing. With this model, we place edge devices
with enough computational resources closer to IoT devices. However, by using
multiple edge devices, we create a distributed network, which requires active
synchronization. It is infeasible to continuously communicate and synchronize
IoT devices to edge computing without depleting the energy resources of IoT
devices. Third, a way to overcome energy limitation is to allow IoT devices
to perform duty cycling. However, duty cycling leads to intermittent network
connections.

1.2 Background

This section provides an overview of the topics relevant to the thesis. First, we
discuss the properties of distributed ledger technology (the so-called blockchain)
relevant to the IoT applications and inherent challenges. Second, we intro-
duce the concept of smart contracts and how they enforce various financial
agreements. Finally, we review two major security properties in the context of
resource-constrained devices.

1.2.1 Blockchain

A blockchain is essentially a type of distributed ledger [1], where multiple
nodes keep replicated blocks of transactions as an append-only data structure.
The data structure is a linked list that chains together the next block by
using the cryptographic hash value of the previous block. The structure of a



4 CHAPTER 1. INTRODUCTION

blockchain is visualized in Figure 1.2. With this structure, it is trivial for each
node in the network to verify the validity of every new appended block. Any
change to an older block inherently invalidates all chained blocks. As blocks
are replicated over multiple nodes in the network, the nodes need to reach
a consensus regarding the order of the blocks. Several algorithms have been
proposed to reach a consensus in a blockchain, such as Proof of Work (PoW) [2],
Proof of Stake (PoS) [3], and Practical Byzantine Fault Tolerance (PBFT) [4].

For example, Bitcoin [2] uses a PoW algorithm. In this algorithm, every
node can participate in the consensus algorithm. A node in the network may
propose the next block by solving a probabilistic mathematical problem. When
a node solves the mathematical problem, it creates and broadcasts a new block
to the network for validation.

The increasing deployment of large-scale blockchains reveals several scalabil-
ity issues, for example, low transaction throughput [5–7]. The append-only data
structure creates an ever-growing blockchain which reaches large sizes in a short
period of time [8]. The number of transactions that the network can handle
is relatively small compared to traditional transaction systems. Currently,
the throughput is an order of tenth per second [5], compared to an order of
thousands when using traditional financial systems, such as credit cards. The
research community has proposed several ways to scale the blockchains, such
as sharding [9,10], consensus algorithm variations [1], trusted execution [11],
side-chains [12], payment channels [13,14], and payment networks [15,16].

In the context of IoT, we can identify three resource-intensive requirements
that make blockchains challenging to adopt in resource-constrained devices.
First, the consensus algorithms require extensive processing power from partici-
pating nodes. Second, participating nodes require sufficient network bandwidth
to broadcast each block. Third, the ever-growing blockchain requires sufficient
memory to store the complete data structure.

1.2.2 Smart Contract

A smart contract is an executable program replicated in a blockchain. The
primary use for a smart contract is the digital representation of financial
agreements between untrusted parties. The parties assign a public key to a
smart contract that anyone can use and send transactions to it through a
blockchain network. Smart contracts have variables to store their states in
a blockchain, and the execution of it may update the state of a blockchain.
Each node participating in the consensus process of a blockchain executes and
validates every smart contract. It is typical to use a Virtual Machine (VM)
and write a smart contract in a high-level programming language [17].

The current design of VMs for smart contracts assumes a sequential exe-
cution with no support for parallel or concurrent execution. Moreover, smart
contracts do not have access to data outside of a blockchain network, limiting
their ability to handle events of the real world. With the current design, in
order to include sensor data inside a smart contract, we need to use a third
party, the so-called Oracles [18]. We argue that Oracles, acting as third parties,
oppose the fundamental principle of blockchain to replace central authorities.

In the context of IoT, we can identify two main obstacles to adopt smart
contracts on IoT devices. First, smart contracts are written in high-level



1.3. DOMAIN PROBLEMS 5

languages which are commonly too memory-intensive for resource-constrained
devices. Second, the virtual machines of current blockchains do not provide
any opcode to handle sensor data or send signal to actuators.

1.2.3 Security Properties

The security of payment protocols is crucial for the success of many applications,
especially in IoT. In this thesis, we focus on two security properties of IoT
devices. First, we focus on the integrity [19] of the software running on the
embedded device. Second, we focus on the non-repudiation [19] property of
transactions between two or multiple untrusted parties, commonly found in
our application scenarios.

It is common for manufacturers of embedded devices to divide the boot
process into several steps due to memory constraints. Commonly, they divide
the boot process of embedded devices into three steps. First, the boot-ROM is
the initial software running when a device starts. Second, the boot-loader is
the software responsible for transferring control to the operating system. Third,
the operating system is the final software that starts the application(s) of the
device. We investigate Secure Boot [20], as a way to ensure the integrity of
software of all the above steps.

One way to achieve non-repudiation is to exchange cryptographic signa-
tures of a pre-agreed message such that either both parties or none obtain a
signed message. We use the term fair exchange to refer to the property of
signature exchange protocols where either both or none of the participants
obtain the cryptographic signature. A contract signing protocol allows two
or multiple parties to exchange signatures in a fair-way. We group the contract
signing protocols in three categories: protocols with an online Trusted Third
Party (TTP) [21], protocols without TTP (e.g., time commitments [22]), and
protocols with an off-line TTP (e.g., optimistic [23]).

1.3 Domain Problems

In this section, we introduce three domain-problems that motivate our work:
a) malicious software modification, b) non-repudiation of IoT transactions, and
c) inability of IoT transactions to include sensors readings and actuators.

1.3.1 Malicious Software Modification

In the first problem-domain, we encounter malicious modifications of the
software running on IoT devices. The possibility of these modifications decrease
the trust in the data produced by the sensors and actuators commonly found
in an IoT application.

Motivation. As the Internet of Things (IoT) brings connectivity to ev-
eryday objects, embedded devices get exposed to numerous cyber-attacks [24].
Device manufacturers commonly design their systems to work in isolation with
little exposure to Internet connections. With Internet connectivity, internal
structures, such as the firmware of the device, are now exposed to cyber-attacks
such as malicious software modifications. These modifications can remain



6 CHAPTER 1. INTRODUCTION

unnoticed for an extended period of time, which raises questions regarding the
trust in the data originating from the device.

For example, a possible malicious user can find ways to remotely connect
into an IoT device and replace the existing firmware with one containing
malicious code. The malicious code will be the first function to be executed
every time the device boots-up, prior to any security protection mechanism.
Therefore, any malicious activity of the device can remain hidden.

A common approach to detect software modifications is to ensure the
integrity of the software during the boot process, the so-called Secure Boot. It
is common to find Secure Boot inside a desktop computer [25]. However, in
the domain of embedded systems, it is quite rare.

Challenges. The process of Secure Boot in any device requires the ex-
tension of the system with additional software or hardware. The resource-
constrained devices need to overcome two significant overheads to adopt these
additional components. First, it requires an extension of the boot-up software
or hardware. This additional software or hardware increases the complexity of
the boot-up process, and it depletes the limited resources of the embedded de-
vice. Second, it introduces extra sequential steps in the boot-up process, which
delays the start-up time and may affect the usefulness of the user-application.

When it comes to embedded devices, we can find a broad range of devices.
This variety makes it hard to adopt any Secure Boot process uniformly. More-
over, IoT applications have different delay and response requirements. One
main challenge is to recognize and adopt the overheads introduced by Secure
Boot.

Related work. There is a large body of research in the field of Secure
Boot. Khalid et al. [26] discuss the difference between Secure and Trusted Boot,
and they further evaluate the performance overhead on FPGA boards. Lebedev
et al. [27] give examples of a remotely attested system using FPGA boards.

From the practitioner’s side, Google’s Chromium OS uses Verified Boot
to build a chain of trust [28]. Asokan et al. [29] focus on solutions regarding
firmware updates on large-scale IoT deployments. For resource-constrained
devices, Boot-IoT [30] proposes an authentication scheme for secure bootstrap-
ping. We can see the need for Secure Boot on different device sizes ranging
from consumer-level printers to industrial robots [31,32].

Open problems Even though researchers propose several methods to
ensure the integrity of device firmware, most of them have not been evaluated
on resource-constrained devices. Moreover, there are millions of connected
devices without any measure to verify the software they run. In most cases,
there is no way to update or change the software after the deployment of IoT
devices.

1.3.2 Non-Repudiation of IoT Transactions

In the second domain-problem, we focus on the challenges involved in ensuring
non-repudiation of IoT transactions. In our case, the non-repudiation property
would be violated if a completed IoT transaction is wrongly recorded or not
stored at all, or if a misbehaving node is not immediately reported.

Motivation. In a typical IoT application, small devices need to interact
frequently, producing billions of transactions that their stakeholders want to



1.3. DOMAIN PROBLEMS 7

store. In this case, the interacting IoT devices commonly do not trust each
other, as they are, for example, owned or operated by different stakeholders.
Moreover, the distributed nature of IoT applications makes it challenging to
record such interactions coming from distrusting nodes.

Blockchain technology, as described in Section 1.2, stores blocks of transac-
tions in the form of an immutable linked list. Moreover, blockchain promotes
a verifiable property of transactions in a network of untrusted parties. This
property makes the blockchain an ideal candidate for storing the billions of
transactions produced by IoT devices.

As motivation, we present an application in Figure 1.1, where one device
provides a service to another for an exchange of money. The small embedded
devices are limited in terms of the connectivity that they can establish. Thus, it
becomes infeasible to verify each transaction by contacting an online verification
service every time. It is more reasonable for the devices to interact off-line
using the online services only in case of a dispute. The devices can ensure a
non-repudiation property of their transactions by applying a contract signing
protocol to sign their transaction in a fair-way [33]. In this thesis, we are
motivated by the advances in the cryptographic capabilities of embedded
systems [34], and we identify new opportunities for applying cryptographic
protocols to sign IoT transactions.

Challenges. In order to operate a blockchain network with IoT nodes, we
face three key challenges. First, blockchain nodes require sufficient network
bandwidth to broadcast a large number of messages. Blockchains require
network bandwidths that is beyond the capacity of resource-constrained devices.
Even in the case of a broadband connection (e.g., 5G), its energy requirements
will deplete the battery of the device too quickly. Second, it is inevitable for
devices to off-load their transactions to the cloud as their storage capacity is
insufficient to store the complete blockchain. Third, nodes participating in a
blockchain network need to use heavy-cryptographic operations to verify each
block.

The resource limitations of IoT devices lead to three relaxations. First,
nodes need to operate, assuming intermittent network access. They need to
utilize edge connections to reach cloud-based blockchains. Second, nodes need
to act optimistically and create off-line transactions. In case of a conflict, they
should contact cloud services to resolve it. Third, nodes need to use lightweight
protocols to address device limitations in terms of memory, computation, and
energy consumption.

Related work. Recent studies on the affordability of cryptographic oper-
ations on embedded devices [35] [36] inspire the idea of utilizing a blockchain
in the context of IoT. However, current architectures focus on power-full de-
vices, and they overlook the limitations of the resource-constrained devices [37].
Several architectures [38] [39] identify the ability of blockchains to provide
data provenance. While other studies, such as AGasP [40] and Edgechain [41],
identify different applications of blockc";"""date"",""2020-07-11T06:29:40Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""Enhancing Trust in Devices and Transactions of the Internet of Things""
""xmp:CreatorTool"",""TeX""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""With the rise of the Internet of Things (IoT), billions of smart embedded devices will interact frequently.&lt;br /&gt;These interactions will produce billions of transactions.&lt;br /&gt;With IoT, users can utilize their phones, home appliances, wearables, or any other wireless embedded device to conduct transactions.&lt;br /&gt;For example, a smart car and a parking lot can utilize their sensors to negotiate the fees of a parking spot.&lt;br /&gt;The success of IoT applications highly depends on the ability of wireless embedded devices to cope with a large number of transactions.&lt;br /&gt;However, these devices face significant constraints in terms of memory, computation, and energy capacity.&lt;br /&gt;&lt;br /&gt;&lt;br /&gt;With our work, we target the challenges of accurately recording IoT transactions from resource-constrained devices. We identify three domain-problems: a) malicious software modification, b) non-repudiation of IoT transactions, and c) inability of IoT transactions to include sensors readings and actuators.&lt;br /&gt;The motivation comes from two key factors.&lt;br /&gt;First, with Internet connectivity, IoT devices are exposed to cyber-attacks.&lt;br /&gt;Internet connectivity makes it possible for malicious users to find ways to connect and modify the software of a device.&lt;br /&gt;Second, we need to store transactions from IoT devices that are owned or operated by different stakeholders.&lt;br /&gt;&lt;br /&gt;&lt;br /&gt;The thesis includes three papers. In the first paper, we perform an empirical evaluation of &lt;strong&gt;Secure Boot&lt;/strong&gt; on embedded devices.&lt;br /&gt;In the second paper, we propose &lt;strong&gt;IoTLogBlock&lt;/strong&gt;, an architecture to record off-line transactions of IoT devices.&lt;br /&gt;In the third paper, we propose &lt;strong&gt;TinyEVM&lt;/strong&gt;, an architecture to execute off-chain smart contracts on IoT devices with an ability to include sensor readings and actuators as part of IoT transactions.""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""TeX""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""Enhancing Trust in Devices and Transactions of the Internet of Things""
""modified"",""2020-07-11T06:29:40Z""
""cp:subject"",""With the rise of the Internet of Things (IoT), billions of smart embedded devices will interact frequently.&lt;br /&gt;These interactions will produce billions of transactions.&lt;br /&gt;With IoT, users can utilize their phones, home appliances, wearables, or any other wireless embedded device to conduct transactions.&lt;br /&gt;For example, a smart car and a parking lot can utilize their sensors to negotiate the fees of a parking spot.&lt;br /&gt;The success of IoT applications highly depends on the ability of wireless embedded devices to cope with a large number of transactions.&lt;br /&gt;However, these devices face significant constraints in terms of memory, computation, and energy capacity.&lt;br /&gt;&lt;br /&gt;&lt;br /&gt;With our work, we target the challenges of accurately recording IoT transactions from resource-constrained devices. We identify three domain-problems: a) malicious software modification, b) non-repudiation of IoT transactions, and c) inability of IoT transactions to include sensors readings and actuators.&lt;br /&gt;The motivation comes from two key factors.&lt;br /&gt;First, with Internet connectivity, IoT devices are exposed to cyber-attacks.&lt;br /&gt;Internet connectivity makes it possible for malicious users to find ways to connect and modify the software of a device.&lt;br /&gt;Second, we need to store transactions from IoT devices that are owned or operated by different stakeholders.&lt;br /&gt;&lt;br /&gt;&lt;br /&gt;The thesis includes three papers. In the first paper, we perform an empirical evaluation of &lt;strong&gt;Secure Boot&lt;/strong&gt; on embedded devices.&lt;br /&gt;In the second paper, we propose &lt;strong&gt;IoTLogBlock&lt;/strong&gt;, an architecture to record off-line transactions of IoT devices.&lt;br /&gt;In the third paper, we propose &lt;strong&gt;TinyEVM&lt;/strong&gt;, an architecture to execute off-chain smart contracts on IoT devices with an ability to include sensor readings and actuators as part of IoT transactions.""
""pdf:docinfo:subject"",""With the rise of the Internet of Things (IoT), billions of smart embedded devices will interact frequently.&lt;br /&gt;These interactions will produce billions of transactions.&lt;br /&gt;With IoT, users can utilize their phones, home appliances, wearables, or any other wireless embedded device to conduct transactions.&lt;br /&gt;For example, a smart car and a parking lot can utilize their sensors to negotiate the fees of a parking spot.&lt;br /&gt;The success of IoT applications highly depends on the ability of wireless embedded devices to cope with a large number of transactions.&lt;br /&gt;However, these devices face significant constraints in terms of memory, computation, and energy capacity.&lt;br /&gt;&lt;br /&gt;&lt;br /&gt;With our work, we target the challenges of accurately recording IoT transactions from resource-constrained devices. We identify three domain-problems: a) malicious software modification, b) non-repudiation of IoT transactions, and c) inability of IoT transactions to include sensors readings and actuators.&lt;br /&gt;The motivation comes from two key factors.&lt;br /&gt;First, with Internet connectivity, IoT devices are exposed to cyber-attacks.&lt;br /&gt;Internet connectivity makes it possible for malicious users to find ways to connect and modify the software of a device.&lt;br /&gt;Second, we need to store transactions from IoT devices that are owned or operated by different stakeholders.&lt;br /&gt;&lt;br /&gt;&lt;br /&gt;The thesis includes three papers. In the first paper, we perform an empirical evaluation of &lt;strong&gt;Secure Boot&lt;/strong&gt; on embedded devices.&lt;br /&gt;In the second paper, we propose &lt;strong&gt;IoTLogBlock&lt;/strong&gt;, an architecture to record off-line transactions of IoT devices.&lt;br /&gt;In the third paper, we propose &lt;strong&gt;TinyEVM&lt;/strong&gt;, an architecture to execute off-chain smart contracts on IoT devices with an ability to include sensor readings and actuators as part of IoT transactions.""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""Profentzas, C.""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.20 (TeX Live 2019) kpathsea version 6.3.1""
""meta:author"",""Profentzas, C.""
""trapped"",""False""
""meta:creation-date"",""2020-05-17T14:01:34Z""
""created"",""2020-05-17T14:01:34Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-05-17T14:01:34Z""
""resourceName"",""326728301.pdf""
""Author"",""Profentzas, C.""
""producer"",""PDFsharp 1.32.3057-g (www.pdfsharp.net) (Original: pdfTeX-1.40.20; modified using iTextSharp 4.1.6 by 1T3XT)""
""pdf:docinfo:producer"",""PDFsharp 1.32.3057-g (www.pdfsharp.net) (Original: pdfTeX-1.40.20; modified using iTextSharp 4.1.6 by 1T3XT)""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""Keywords"","" Smart Contracts,  Secure Boot, Internet of Things,  Distributed Systems,  Embedded Systems,  Blockchain, ""
""access_permission:modify_annotations"",""true""
""dc:creator"",""Profentzas, C.""
""dcterms:created"",""2020-05-17T14:01:34Z""
""Last-Modified"",""2020-07-11T06:29:40Z""
""dcterms:modified"",""2020-07-11T06:29:40Z""
""title"",""Enhancing Trust in Devices and Transactions of the Internet of Things""
""Last-Save-Date"",""2020-07-11T06:29:40Z""
""pdf:docinfo:keywords"","" Smart Contracts,  Secure Boot, Internet of Things,  Distributed Systems,  Embedded Systems,  Blockchain, ""
""pdf:docinfo:modified"",""2020-07-11T06:29:40Z""
""meta:save-date"",""2020-07-11T06:29:40Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.20 (TeX Live 2019) kpathsea version 6.3.1""
""Content-Length"",""1726280""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Profentzas, C.""
""dc:subject"","" Smart Contracts,  Secure Boot, Internet of Things,  Distributed Systems,  Embedded Systems,  Blockchain, ""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""104""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""213"",""328"",""33"",""2"",""1723"",""2"",""703"",""4"",""786"",""1"",""1310"",""2109"",""783"",""11"",""893"",""16"",""558"",""17"",""17"",""0"",""2114"",""1940"",""1595"",""2960"",""2465"",""2799"",""3032"",""2823"",""2235"",""2630"",""2998"",""2605"",""1284"",""23"",""11"",""0"",""296"",""0"",""1404"",""2930"",""1402"",""2912"",""2139"",""1605"",""1719"",""1256"",""1948"",""1297"",""1669"",""2264"",""2127"",""51"",""196"",""0"",""1241"",""2284"",""2351"",""1926"",""2555"",""1935"",""2360"",""2671"",""1798"",""2629"",""2819"",""1897"",""1769"",""2709"",""1768"",""2306"",""228"",""22"",""201"",""0"",""1657"",""2971"",""2201"",""2628"",""2618"",""1591"",""2607"",""1444"",""2254"",""2733"",""952"",""2613"",""2678"",""2490"",""1294"",""1745"",""2488"",""265"",""1975"",""1236"",""2918"",""2563"",""1521"",""2007"",""2155"",""2353"",""2092"",""2063"",""2154"",""627""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"","" Smart Contracts,  Secure Boot, Internet of Things,  Distributed Systems,  Embedded Systems,  Blockchain, ""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-05-17T14:01:34Z""
";https://scholar.google.ch/scholar?start=930&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098782-148;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;[CITATION][C] LIABILITY OF THE SMART CONTRACT DEVELOPER;D Roumpos;;;null;Autres articles;;null;;;;https://scholar.google.ch/scholar?start=690&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098804-197;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Make quantum indistinguishability great again;T Gagliardoni, J Krämer, P Struck ; arXiv preprint arXiv:2003.00578, 2020  arxiv.org;;"… (CRYPTO 2016) advanced the study of quantum secu- rity, for symmetric key encryption schemes …

from [5], while requiring the more involved compressed oracle technique by Zhandry [43 … More-

over they introduce a technique (based on Zhandry's compressed oracles) to record …";Cité 3 fois;;[PDF] arxiv.org;https://arxiv.org/pdf/2003.00578;"
ar
X

iv
:2

00
3.

00
57

8v
4 

 [
cs

.C
R

] 
 2

 M
ar

 2
02

1

Quantum Indistinguishability

for Public Key Encryption

Tommaso Gagliardoni1, Juliane Krämer2, and Patrick Struck2

1 Kudelski Security, Switzerland
firstname.lastname@kudelskisecurity.com
2 Technische Universität Darmstadt, Germany
{juliane,patrick}@qpc.tu-darmstadt.de

Abstract. In this work we study the quantum security of public key
encryption schemes (PKE). Boneh and Zhandry (CRYPTO’13) initiated
this research area for PKE and symmetric key encryption (SKE), al-
beit restricted to a classical indistinguishability phase. Gagliardoni et al.
(CRYPTO’16) advanced the study of quantum security by giving, for
SKE, the first definition with a quantum indistinguishability phase. For
PKE, on the other hand, no notion of quantum security with a quantum
indistinguishability phase exists.
Our main result is a novel quantum security notion (qIND-qCPA) for
PKE with a quantum indistinguishability phase, which closes the afore-
mentioned gap. We show a distinguishing attack against code-based
schemes and against LWE-based schemes with certain parameters. We
also show that the canonical hybrid PKE-SKE encryption construction
is secure, even if the underlying PKE scheme by itself is not. Finally,
we classify quantum-resistant PKE schemes based on the applicability
of our security notion and discuss concurrent and independent work.
Our core idea follows the approach of Gagliardoni et al. by using so-called
type-2 operators for encrypting the challenge message. At first glance,
type-2 operators appear unnatural for PKE, as the canonical way of
building them requires both the secret and the public key. However, we
identify a class of PKE schemes - which we call recoverable - and show
that for this class type-2 operators require merely the public key. More-
over, recoverable schemes allow to realise type-2 operators even if they
suffer from decryption failures, which in general thwarts the reversibility
mandated by type-2 operators. Our work reveals that many real-world
quantum-resistant PKE schemes, including most NIST PQC candidates
and the canonical hybrid construction, are indeed recoverable.

1 Introduction

The discovery of Shor’s [43] and Grover’s [27] quantum algorithms had a signif-
icant impact on cryptographic research. Shor’s algorithm in particular has the
potential to completely break most of the public key cryptosystems used nowa-
days. This led to the development of quantum-resistant cryptography,3 that is,

3 This type of cryptography is often called “post-quantum cryptography” [12].

http://arxiv.org/abs/2003.00578v4


cryptography that can run on non-quantum computers but should withstand
attackers equipped with quantum computing power. In recent years the research
efforts on quantum-resistant cryptography accelerated significantly due to the
standardization process initiated by the NIST [39].

Modern cryptography is based on the paradigm of provable security, which
is itself given in terms of a security notion, an adversarial model, and a security
proof. A widely used framework for defining security notions is the so-called
game-based security, which is presented as a game between two or more parties.4

In the case of encryption schemes these parties are: a challenger, represent-
ing the user of the scheme, and an adversary, representing an attacker against
the scheme. Any meaningful model for quantum-resistant schemes should entail
that the adversary has quantum computing power. Based on this, we can dif-
ferentiate between different models depending on the computing power of the
challenger. In the literature there are mainly two of these models that are taken
into account. In the first, the challenger remains fully classical, implying that
any communication between adversary and challenger is also classical (including
oracles provided by the challenger to the adversary), while the adversary retains
local quantum computing power. This is the model most often considered in
quantum-resistant cryptography, and it is also called QS1 [24] or Q1 [30]. In the
second case, the challenger also has quantum computing power, which enables
quantum communication between challenger and adversary. This stronger model
is sometimes called “superposition-attack security” [22], QS2 [24], or Q2 [30].

Boneh and Zhandry [15] initiated the study of QS2 security for cryptographic
primitives. For signature schemes, they give a security definition that allows
the adversary to query the signing oracle on a superposition of messages. For
public and symmetric key encryption (PKE and SKE) schemes, on the other
hand, they prove that simply allowing the adversary to query a superposition of
messages as challenge in a “natural” way gives an unachievable security notion
(fqIND-CPA). This is due to entanglement between the plaintext register and the
ciphertext register. They show how to exploit this entanglement to break this
security notion irrespectively of the used encryption scheme. To resolve this,
they propose another security notion (IND-qCPA) which allows the adversary
superposition queries in the CPA phase while the challenge messages in the IND
phase are restricted to be classical. This notion coincides with the traditional
QS1 security notion for PKE (as the adversary can simulate the encryption in
superposition using his local computing power and the public key), while for
SKE, this yields a notion of QS2 security - although the restriction to a classical
challenge in this case is clearly a shortcoming.

Gagliardoni et al. [25] overcame this shortcoming in the symmetric key case
by showing how to model a quantum challenge query, while keeping the resulting
security notion (qIND-qCPA) still achievable, yet stronger than IND-qCPA. At
the heart of their idea lies the use of so-called type-2 operators5 rather than so-

4 Other frameworks exist, such as simulation-based, but as a first approximation game-
based security notions are very convenient for their intuitivity and simplicity.

5 Also called minimal oracles in [31].

2



called type-1 operators when encrypting the challenge messages of the adversary.
Type-1 operators are the “canonical” way of implementing a classical function F
on a quantum superposition of input, by mapping the state |x, y〉 to |x, y ⊕F(x)〉,
thereby ensuring reversibility for any function F (reversibility being necessary
when defining non-measurement quantum operations). An important property of
type-1 operators is that they create entanglement between the input and output
registers. This is exactly the entanglement which Boneh and Zhandry exploit
to show that fqIND-CPA is unachievable. In contrast to these, type-2 operators
work directly on the input register, i.e., they map the state |x〉 to |F(x)〉. Only
reversible functions, for instance permutations, can be implemented as type-2
operators, while it is impossible to compute, say, an arbitrary one-way function
through a type-2 operator. Gagliardoni et al. observe that SKE schemes act as
permutations between the plaintext space and the ciphertext space, which allows
to implement the encryption algorithm as a type-2 operator. This, in turn, allows
to build a solid framework for QS2 security in the case of SKE.

In [25] the authors speculate that their techniques could be extended to
the public key case (PKE) as well. However, defining type-2 operators for PKE
schemes is much more involved than for SKE schemes. First, to achieve IND-CPA
security, PKE schemes are inherently randomised and the randomness is usually
erased in the process of decryption. Second, many constructions for quantum-
resistant PKE schemes, in particular lattice-based and code-based schemes, suf-
fer from a small probability of decryption failures, i.e., ciphertexts which do not
decrypt correctly. Given the above, at first glance it is unclear whether type-2
operators for PKE schemes are possible at all, as these two properties seem to
thwart the mandatory reversibility. Hence, QS2 security for the public key case
remained an open problem so far.

1.1 Our Contribution

We present a novel QS2 security notion6 for PKE, provide both achievability
results and separation to the QS1 security notion for many real-world schemes,
and give a general classification of PKE with respect to our security notion.

Our core focus is to extend the results from [25] to the public key scenario. We
first formalize the theory of type-2 encryption operators for PKE. For perfectly
correct schemes (i.e., schemes which do not suffer from the possibility of decryp-
tion failures) we define the type-2 operator to preserve a randomness register
in input and output. Even if such approach might look strange at first glance,
we show that this is the most natural way of defining type-2 operators for PKE
schemes. As a next step, we identify a class of PKE schemes (which we call recov-
erable) where decryption failures can always be avoided given knowledge of the
randomness used during encryption, regardless of the actual failure probability
of the decryption algorithm. We observe that most real-world partially correct
PKE schemes (including many quantum-resistant NIST candidates) are actually
of this type. Then, for schemes that are perfectly correct or recoverable, we show

6 See Appendix C for independent and concurrent work.

3



how to efficiently construct the type-2 encryption operator. Moreover, we show
that for recoverable schemes, this can be done by knowledge of the public key
only! This implies, perhaps surprisingly, that the adversary can implement effi-
ciently this type-2 operator already in the QS1 model. Such observation marks
a substantial difference from the symmetric key case, where the need for type-2
operators is dictated by necessity in order to cover exotic attack models. Thus,
the type-2 operator for these schemes can be realised without the secret key.

Using the theory of type-2 operators developed so far, we give a novel QS2
security notion for PKE, that we call quantum ciphertext indistinguishability
under quantum chosen plaintext attack (qIND-qCPA). For a new security notion
to be meaningful, two properties are required. First, it has to be achievable, and,
second, it has to differ from existing security notions.

We analyse several real-world PKE schemes in respect to our new qIND-qCPA
security notion. We show that the canonical LWE-based PKE scheme [41] can be
attacked, at least for certain parameters. The attack is similar to the “Hadamard
distinguisher” given in [25]. Moving on to code-based schemes, we observe that
some constructions encrypt the message using a one-time pad operation, which
again allows to exploit the distinguishing attack. As an example we show that
the code-based scheme ROLLO-II [10] is not qIND-qCPA secure.

However, in practice most real-world PKE schemes (including the NIST sub-
missions) are used as Key Encapsulation Mechanisms (KEM) in combination
with a SKE scheme, yielding a hybrid PKE-SKE construction. Looking at such
canonical hybrid construction then, we show that its qIND-qCPA security mostly
depends on the underlying SKE scheme, while the PKE scheme only needs to be
secure in the QS1 sense. Hence, even the code-based PKE scheme ROLLO-II,
which as a stand-alone PKE scheme is not qIND-qCPA-secure, can be used to
achieve qIND-qCPA security if combined with a qIND-qCPA-secure SKE scheme
via the hybrid construction, which is the default way of using it in practice.

Finally, we discuss the difficulty of defining type-2 operators (and the related
QS2 security notion) for arbitrary schemes that are neither perfectly correct nor
recoverable. We study the problem of their general classification and we identify
a class of schemes, that we call isometric, that allow to overcome such difficulty,
and we provide constructions and separation results.

1.2 The Motivation for QS2 Security

Defining security against quantum adversaries with superposition access to cer-
tain oracles requires some motivation. Sometimes, the resulting security notion
is already implicitly captured by the corresponding QS1 scenario (for example
in the case of quantum random oracles [13]). In other cases, for instance those
considered in [7, 29, 33], it might look like an artificial extension of the theory.

However, QS2 security extends quantum properties to types of attack scenar-
ios not covered in QS1, and at the same time “bridges” certain security notions
from the classical realm to schemes which are meant to run natively on a quan-
tum computer. Some of the reasons why QS2 notions are important to consider
are explained in detail in [24]. They basically boil down to five points.

4



1. To ensure that quantum-resistant classical schemes retain their security even
if executed on a quantum computer, possibly in complex environments or
protocols where composition should be taken into account.

2. To fix security proofs, where the sole QS1 security of certain underlying
building blocks is not enough to ensure that the whole proof goes through.
An example is the need of QS2-secure pseudorandom functions (QPRF) in
order to simulate a quantum random oracle [46], which is a QS1 concept.

3. To ensure the security of quantum protocols (i.e., meant to run natively
on a quantum computer and protect quantum data) when using classical
algorithms as building blocks. For example, [24] shows how it is possible to
build a secure symmetric quantum encryption scheme (falling into the so-
called QS3 domain) by using a qIND-qCPA symmetric classical encryption
scheme (QS2), but not necessarily a simple quantum-resistant (QS1) one.

4. To consider cases of code obfuscation; for example creating a quantum-
resistant PKE scheme by hardcoding a symmetric key into an obfuscated
encryption program (a technique known as whiteboxing [20]), which is then
distributed as a public key.

5. To cover cases of exotic quantum attacks. These include, for instance, quan-
tum fault injection attacks, where a classical device is subject to controlled
and artificial physical conditions that induce full or partial quantum be-
haviour of its hardware (“tricking” a classical device into being quantum,
like in the “frozen smart-card attack” presented in [25]); or cases where a
quantum computer is used to run a classical algorithm, but an adversary
manages to intercept the intermediate result of the computation before the
final measurement meant to produce a classical outcome.

In our specific case, our results follow from the core use of type-2 operators. This
kind of quantum operations is poorly studied in the quantum computing realm,
and might therefore look artificial for cryptographic use. In the present work
we make an effort to expand in a detailed way the formalization of such opera-
tors which, we stress, are only given for functions that are inherently invertible.
It is a well-known fact (see for example [25]) that implementing these opera-
tors for encryption schemes usually requires knowledge of the secret key. We do
not consider this to be a limitation because in the quantum setting, an honest
challenger equipped with the secret key could be allowed to generate particu-
lar ciphertext-encoding states which would be hard to compute for an external
party: it is therefore necessary to cover this distinction in the preparation of
ciphertext states, and type-2 operators do just that. Moreover, as we show in
the present work, for many natural PKE schemes, type-2 encryption operators
can actually be efficiently implemented by knowledge of the public key only.

1.3 Related Work

The study of quantum security under adversarial queries in superposition can be
traced back to works such as [13, 22, 45], which explore different settings where
this additional adversarial power has an impact on security. However, for the

5



case of signatures and encryption schemes, the first framework going beyond the
traditional QS1 paradigm was given in [15]. This paradigm was further extended
in [25] for symmetric key encryption schemes, and in [6] for MACs/signatures.

Regarding examples of exotic quantum attacks previously mentioned: it is
currently not known whether any of these are feasible at all, but as noted in [24]:
(1) if they are feasible, in some cases they do not even require a fully fledged quan-
tum computer (for example, in the attack from [25] it would be only necessary
to produce and detect a Hadamard superposition of messages); and (2) it is al-
ready known in the literature that these attacks can be devastating. For example,
related-key attacks [42], and superposition attacks against Even-Mansour [33],
Feistel networks [28, 32], block ciphers [7, 9], and HMAC constructions [29].

Qualitatively different, but technically very connected to the QS2 setting is
the fully quantum setting, or QS3 in short. This security domain encompasses se-
curity notions and constructions for schemes which are natively run on quantum
hardware. In the case of QS3 encryption, these are schemes which are meant to
protect quantum, rather than classical data. It turns out that many of the chal-
lenges in this area are shared with the QS2 case. In the computational security
setting, the first security notions have been provided in [17] for the CPA case,
and in [3] for the CCA1 and semantic security case. These results have been
further extended to the CCA2 setting in [5] for the symmetric case, and in [4]
for the public key case.

In concurrent and independent work, Chevalier et al. [19] propose alternative
QS2 security notions for encryption schemes. Their and our notion are incom-
parable, as also claimed in a recent work by Carstens et al. [18]. We discuss the
differences in more detail in Appendix C.

1.4 Organization of the Paper

Section 2 gives the required background for this work. In Section 3 we study
type-2 operators for PKE schemes, define recoverable schemes, and give our new
quantum security notion for those. Positive and negative results for real-world
PKE schemes are presented in Section 4. Finally, we refine the classification of
PKE schemes in terms of QS2 security in Section 5 and conclude with open
questions in Section 6.

2 Preliminaries

In the following, we use “classical” as meaning “non-quantum”. By algorithm or
procedure (classical or quantum) we mean a uniform family of circuits (classical
or quantum) of depth and width polynomial in the index of the family. We call
such index a security parameter, and we denote it by Îť (or 1Îť if written in unary
notation). We implicitly assume that all algorithms take 1Îť as a first input, so
we will often omit this. If a classical algorithm A is deterministic, we denote its
output y on input x as y := A(x), while if it is randomized we use y ← A(x); when
derandomizing an algorithm we look at the deterministic algorithm obtained

6



when considering explicitly the internal randomness r as an additional auxiliary
input, and we write y := A(x; r). We will also use x ← D to denote that an
element x is sampled from a distributionD; or we will write x $←−X if x is sampled
uniformly at random from a set X . We will call negligible a function that grows
more slowly than any inverse polynomial, and overwhelming a function which is
1 minus a negligible function. Finally, a‖b denotes concatenation of a and b.

2.1 Quantum Notation

We assume familiarity with the topic of quantum computing, but recall here the
basic required notation. For an in-depth discussion we refer to [38].

A quantum system, identified by a letter A, is represented by a complex
Hilbert space, which we denote by HA. If A is clear from the context, we write
H rather than HA. Pure states in a Hilbert space H are representatives of equiv-
alence classes of elements of H of norm 1. Mixed states, on the other hand, are
a more general representation of quantum states that takes entanglement with
external systems into account; they are elements of the density matrix opera-
tor space over H, that is, Hermitian positive semi-definite linear operators of
trace 1, denoted as D(H). We use the ket notation for pure states, e.g., |ϕ〉,
while mixed states will be denoted by lowercase Greek letter, e.g., ρ. Opera-
tions on pure states from A to B are performed by applying a unitary operator
U : HA → HB to the state, while the more general case of operations on mixed
states is described by superoperators of the form U : D(HA)→ D(HB)

The canonical way to compute a classical function F : X → Y on a super-
position of possible inputs

∑

x∈X αx |x〉 is through the so-called type-1 operator
for F described by:

U
(1)
F :

∑

x,y

αx,y |x, y〉 7→
∑

x,y

αx,y |x, y ⊕F(x)〉 .

This can always be implemented efficiently whenever F is efficient [38]. By lin-
earity, it is sufficient to specify just the behaviour on the basis elements, i.e.:

U
(1)
F : |x, y〉 7→ |x, y ⊕F(x)〉 .

If F is invertible, then there is another non-equivalent possible way to compute
F in superposition. This is done through the so-called type-2 operators, which
are defined as the unitary:

U
(2)
F : |x〉 7→ |F(x)〉 .

See Fig. 1 for an illustration of these different operators. Kashefi et al. [31] first
introduced type-2 operators using the term minimal oracles instead. They show
that these operators are strictly stronger by giving a problem which can be
solved exponentially faster with type-2 operators than with type-1 operators.
They also observe that the adjoint of the type-2 operator corresponds to the
type-2 operator of the inverse function F−1, which is (usually) not the case for
type-1 operators. Besides that, type-2 operators have been used by Gagliardoni
et al. [25] to define quantum security for secret key encryption schemes.

7



U
(1)
F

U
(2)
F

|x〉

|y〉

|x〉

|y ⊕ F(x)〉
|x〉 |F(x)〉

Fig. 1: Type-1 operator (left) and type-2 operator (right) for a function F .

2.2 Public Key Encryption

In this section we give the formal definition for public key encryption schemes
and the correctness of such schemes.

Definition 1 A public key encryption (PKE) scheme is a tuple (KGen, Enc, Dec)
of three efficient algorithms such that:

– KGen : N×R → P×S is the key generation algorithm which takes a security
parameter Îť and a randomness r as input, and returns a keypair consisting
of a public key pk and a secret key sk. If clear from the context, we will
denote it by (pk, sk)← KGen.

– Enc : P ×M×R → C is the encryption algorithm which takes a public key
pk, a message m, and a randomness r as input, and returns a ciphertext c.
It will be usually denoted by c ← Encpk(m) or c := Encpk(m; r).

– Dec : S × C → M is the (deterministic) decryption algorithm7 which takes
as input a secret key sk and a ciphertext c, and returns a message m. It will
be usually denoted by m := Decsk(c).

By P, S,M, C, and R, we denote the public key space, secret key space, message
space, ciphertext space, and randomness space, respectively.

We assume w.l.o.g. that the randomness space for key generation and encryption
are identical. Below we define two notions of correctness for PKE schemes.

Definition 2 (Perfectly Correct PKE) A PKE scheme ÎŁ = (KGen, Enc, Dec)
is perfectly correct if for any (pk, sk)← KGen, m ∈ M, and r ∈ R, it holds that

Decsk(Encpk(m; r)) = m .

Definition 3 ((1 − α)-Correct PKE [23]) A (1−α)-correct PKE scheme, or
PKE with decryption error Îą, is a PKE scheme ÎŁ = (KGen, Enc, Dec) such that,
for any m ∈M:

Pr
(pk,sk)←KGen

r←R

[Decsk(Encpk(m; r)) 6= m] ≤ α .

7 For simplicity here we only consider decryption with implicit rejection, that is, such
the output is a random value whenever the input is not a well-formed ciphertext
for the particular sk. The extension to explicit rejection decryption can be done for
example by adding a flag bit that marks the output as ⊥ whenever decryption fails.

8



3 Quantum Indistinguishability for PKE Schemes

In this section we extend the QS2 security notion of qIND-qCPA introduced for
SKE schemes in [25] to the public key case. This is much more complex than
the symmetric case, for the following reasons:

1. PKE schemes are randomised to achieve ciphertext indistinguishability;
2. when derandomizing the encryption procedure and considering the random-

ness as additional input, there might be collisions (different randomnesses
leading to the same ciphertext), hence ensuring reversibility of type-2 oper-
ators is not straightforward;

3. many existing schemes, such as lattice- or code-based NIST candidates, suffer
from a small decryption failure probability.

In particular, as we will see, there are two main consequences: (1) the inverse of
type-2 encryption operators is not generally a type-2 decryption operator; and
(2), most interestingly, many type-2 encryption operators can be built efficiently
by using only knowledge of the public key. The last point is crucial: it shows
that in the PKE case, type-2 encryption operators are much more natural than
in the SKE case, and for certain schemes they are actually already covered in
the usual notion of QS1 “post-quantum” security. We will also show that some
of these schemes are very relevant, such as the LWE-based scheme used as a
blueprint for many NIST submissions. In this section we will do the following:

1. First, we revisit and define formally type-1 operators for PKE, and we show
the difference between type-1 encryption and decryption (cf. Section 3.1).

2. We define type-2 encryption operators for perfectly correct PKE schemes,
and we show that they can be efficiently implemented with knowledge of
secret and public key (cf. Section 3.2).

3. We define what we call recoverable PKE schemes, i.e., schemes that admit
an efficient procedure to recover the message given randomness, ciphertext
and public key, without the secret key. We show that for such schemes the
‘canonical’ type-2 encryption operator can be built by only using the public
key, even if the scheme is not perfectly correct (cf. Section 3.3).

4. We define the qIND-qCPA security notion for any PKE scheme where one
can efficiently build the type-2 encryption operator. This includes in partic-
ular perfectly correct and recoverable schemes (cf. Section 3.4).

5. Finally, we discuss how to extend these results to the chosen ciphertext attack
(CCA) scenario (cf. Section 3.5).

3.1 Type-1 Operators for PKE

Recall that, for an arbitrary function f : X → Y, the corresponding type-1
operator is the “canonical” way of computing f on a superposition of input
through the unitary operator Uf : HX ⊗HY → HX ⊗HY defined by: Uf : |x, y〉 7→
|x, y ⊕ f(x)〉. Realising Uf is always efficient if f is efficiently computable.

9



Traditionally, when looking at (deterministic) encryption schemes, the type-1
operator for encryption has been defined as:

UEnc : |m, y〉 7→ |m, y ⊕ Enc(m)〉 .

This is the approach used in, e.g., [15] and [25]. However, in our case of PKE
schemes (which are generally randomized), we have to consider that encryp-
tion can be performed locally by the quantum adversary, who therefore has full
control not only on the randomness used for encryption (i.e., it is necessary to
explicitly derandomize the encryption procedure8), but also on the public key
used (i.e., it is theoretically possible to compute encryption for a superposi-
tion of different public keys). Therefore, the most general definition of a type-1
encryption operator would look like:

UEnc : |pk, r ,m, y〉 7→ |pk, r ,m, y ⊕ Encpk(m; r)〉 .

We argue that this is the most general and correct way to model the local com-
putational power of a quantum adversary, even in the QS1 case. However, for
ease of exposition (and also because it would go beyond the traditional mean-
ing of ciphertext indistinguishability), in the present work we do not consider
superpositions of public keys, as we assume that the public key to be attacked
is given to the adversary at the beginning of the security game. This leads us to
the following definition.

Definition 4 (Type-1 Encryption for PKE) Let ÎŁ = (KGen, Enc, Dec) be a
PKE scheme and let (pk, sk)← KGen. The type-1 encryption operator for pk is
the unitary defined by:

U
(1)
Encpk

: |r ,m, y〉 7→ |r ,m, y ⊕ Encpk(m; r)〉 .

Usually the public key is clear from the context, so we will omit that dependency

and just write U
(1)
Enc

. As usual, when there is no ambiguity, we identify the corre-
sponding superoperator acting on mixed states rather than pure states with the

same symbol U
(1)
Enc

: D(HR ⊗ HM ⊗ HC) → D(HR ⊗ HM ⊗ HC). By letting the
randomness be an input, Definition 4 allows to encrypt using a superposition
of randomnesses, which is fine in the case of the adversary generating cipher-
texts himself. Note also that the case of different randomnesses for each message
in superposition can be realised by using a single classical randomness and a
QS2-secure pseudorandom function [46], as shown by Boneh and Zhandry [15].

The type-1 decryption operator is defined analogously to Definition 4, but
with an important difference: the decryption algorithm does not take the ran-
domness used for encryption as input.

Definition 5 (Type-1 Decryption for PKE) Let ÎŁ = (KGen, Enc, Dec) be a
PKE scheme and let (pk, sk) ← KGen. The type-1 decryption operator for sk is
the unitary defined by:

U
(1)
Decsk

: |c, z〉 7→ |c, z ⊕ Decsk(c)〉 .
8 This is implicitly considered in [15] and [25], but not explicitly formalized.

10



As usual we denote it by U
(1)
Dec

, leaving the secret key understood, and when there
is no ambiguity with the same symbol we denote the superoperator acting on

mixed states also by U
(1)
Dec

: D(HC ⊗ HM)→ D(HC ⊗ HM).

Notice the difference in type-1 encryption and decryption acting on different
spaces: this is not surprising, as it is already known that the adjoint of a type-1
encryption operator is not, generally, a type-1 decryption operator. Notice also
how both operators are efficiently computable, because Enc and Dec are efficient

algorithms. The difference is that realising U
(1)
Dec

requires knowledge of the secret

key sk, while for realising U
(1)
Enc

it is sufficient to know the public key pk.

3.2 Type-2 Encryption for PKE

When defining type-2 encryption for PKE schemes, we have to remember that
defining these operators only makes sense for functions which are reversible. If a
PKE scheme is perfectly correct, then encryption is always reversible if seen as
a function of the plaintext, but not necessarily as a function of the randomness.
That is because it might be the case that for a given message different random-
nesses lead to the same ciphertext. In the context of security games, message
and randomness have very different roles anyway, as one is generally chosen by
the adversary, while the other is generally chosen by the challenger.

Ultimately, what we want is to define a type of unitary which generalizes
the case of arbitrary permutations from plaintext to ciphertext spaces (the same
approach as considered in [25]). In order to avoid the issue raised by random-
ness collisions, we will keep the auxiliary randomness register both in input and
output of the circuit. This ensures reversibility of the operator, because given a
certain ciphertext and a certain randomness, there is only one possible plaintext
which was mapped to that ciphertext (otherwise we would have a decryption
failure, and for now we are only considering perfectly correct schemes). So, if
the sizes of the plaintext space and the ciphertext space coincide, i.e., there is
no ciphertext expansion and thus dim(HM) = dim(HC), then we can define the
corresponding type-2 encryption operator as:

U
(2)
Enc

: |r ,m〉 7→ |r , Encpk(m; r)〉 ,

where, as usual, the public key pk is implicit in the definition of U
(2)
Enc

, i.e., it is
a parameter of the unitary operator in question.

In the more general case of message expansion, i.e., dim(HM) < dim(HC),
we use the same approach as in [25]: we introduce an auxiliary register in a
complementary space HC−M9 that ensures reversibility of the operation, and

9 We denote by HC−M a Hilbert space such that HM ⊗ HC−M is isomorphic to HC.
Notice that the opposite case, i.e., dim(HM) > dim(HC), cannot happen because it
would lead to collisions on the ciphertexts and thus introduce decryption failures.
Also notice that, as in [25], the case of adversarially-controlled ancilla qubits is left
as an open problem.

11



which is initialized to |0 . . . 0〉 during an honest execution to yield a co";"""date"",""2021-03-03T02:32:47Z""
""pdf:PDFVersion"",""1.4""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.4""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""xmp:CreateDate"",""2021-03-02T21:32:47Z""
""modified"",""2021-03-03T02:32:47Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""xmp:ModifyDate"",""2021-03-02T21:32:47Z""
""pdf:docinfo:creator"",""""
""meta:author"",""""
""meta:creation-date"",""2021-03-03T02:32:47Z""
""created"",""2021-03-03T02:32:47Z""
""xmp:About"",""uuid:4a6ad53b-b3e5-11f6-0000-048f56d73b1d""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2021-03-03T02:32:47Z""
""resourceName"",""2003.00578""
""Author"",""""
""producer"",""dvips + GPL Ghostscript GIT PRERELEASE 9.22""
""pdf:docinfo:producer"",""dvips + GPL Ghostscript GIT PRERELEASE 9.22""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""4"",""0"",""0"",""0"",""15"",""7"",""3"",""12"",""3"",""10"",""16"",""3"",""6"",""0"",""13"",""0"",""8"",""18"",""15"",""20"",""0"",""10"",""3"",""5"",""5"",""2"",""0"",""8"",""0"",""0"",""0"",""0"",""8"",""8"",""18"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2021-03-03T02:32:47Z""
""Last-Modified"",""2021-03-03T02:32:47Z""
""dcterms:modified"",""2021-03-03T02:32:47Z""
""title"",""""
""xmpMM:DocumentID"",""uuid:4a6ad53b-b3e5-11f6-0000-048f56d73b1d""
""Last-Save-Date"",""2021-03-03T02:32:47Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2021-03-03T02:32:47Z""
""meta:save-date"",""2021-03-03T02:32:47Z""
""Content-Length"",""477186""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""39""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""2200"",""2912"",""2750"",""2798"",""2636"",""2485"",""2326"",""1668"",""2326"",""2234"",""2447"",""2228"",""1627"",""2260"",""2054"",""2451"",""2137"",""2354"",""1662"",""1923"",""1833"",""1698"",""1901"",""2195"",""2158"",""2261"",""2520"",""2558"",""1291"",""1803"",""2461"",""2874"",""3046"",""2686"",""1477"",""1966"",""1979"",""2567"",""2454""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2021-03-03T02:32:47Z""
";https://scholar.google.ch/scholar?start=740&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098795-171;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;TinyEVM: Off-Chain Smart Contracts on Low-Power IoT Devices;C Profentzas, M Almgren… ; 2020 IEEE 40th …, 2020  ieeexplore.ieee.org;;"… While Oracles [4], [5], as a third-party information source, can supply verified data from

Internet-connected sources, there is no direct … Overall, we recognize a gap between high-level

blockchain architectures and the need for additional services and the capabilities of IoT devices …";Autres articles;;[PDF] chalmers.se;https://research.chalmers.se/publication/522775/file/522775_Fulltext.pdf;"
TinyEVM: Off-Chain Smart Contracts on Low-Power IoT Devices

Downloaded from: https://research.chalmers.se, 2021-04-28 12:32 UTC

Citation for the original published paper (version of record):
Profentzas, C., Almgren, M., Landsiedel, O. (2020)
TinyEVM: Off-Chain Smart Contracts on Low-Power IoT Devices
40th IEEE International Conference on Distributed Computing Systems: 507-518
http://dx.doi.org/10.1109/ICDCS47774.2020.00025

N.B. When citing this work, cite the original published paper.

research.chalmers.se offers the possibility of retrieving research publications produced at Chalmers University of Technology.
It covers all kind of research output: articles, dissertations, conference papers, reports etc. since 2004.
research.chalmers.se is administrated and maintained by Chalmers Library

(article starts on next page)



TinyEVM: Off-Chain Smart Contracts on Low-Power IoT Devices

Christos Profentzas∗, Magnus Almgren∗, Olaf Landsiedel†∗
∗Chalmers University of Technology, Gothenburg, Sweden

†Kiel University, Kiel, Germany
chrpro@chalmers.se, magnus.almgren@chalmers.se, ol@informatik.uni-kiel.de

Abstract—1With the rise of the Internet of Things (IoT),
billions of devices ranging from simple sensors to smart-phones
will participate in billions of micropayments. However, current
centralized solutions are unable to handle a massive number
of micropayments from untrusted devices.

Blockchains are promising technologies suitable for solv-
ing some of these challenges. Particularly, permissionless
blockchains such as Ethereum and Bitcoin have drawn the
attention of the research community. However, the increasingly
large-scale deployments of blockchain reveal some of their scal-
ability limitations. Prominent proposals to scale the payment
system include off-chain protocols such as payment channels.
However, the leading proposals assume powerful nodes with
an always-on connection and frequent synchronization. These
assumptions require in practice significant communication,
memory, and computation capacity, whereas IoT devices face
substantial constraints in these areas. Existing approaches also
do not capture the logic and process of IoT, where applications
need to process locally collected sensor data to allow for full
use of IoT micro-payments.

In this paper, we present TinyEVM, a novel system to
generate and execute off-chain smart contracts based on sensor
data. TinyEVM’s goal is to enable IoT devices to perform
micro-payments and, at the same time, address the device
constraints. We investigate the trade-offs of executing smart
contracts on low-power IoT devices using TinyEVM. We
test our system with 7,000 publicly verified smart contracts,
where TinyEVM achieves to deploy 93% of them without any
modification. Finally, we evaluate the execution of off-chain
smart contracts in terms of run-time performance, energy,
and memory requirements on IoT devices. Notably, we find
that low-power devices can deploy a smart contract in 215 ms
on average, and they can complete an off-chain payment in
584 ms on average.

Keywords-Internet of Things, Blockchain, Smart Contracts,
Payment Channels, Off-chain, Ethereum

I. INTRODUCTION

As the Internet of Things (IoT) becomes deeply inte-
grated into our daily lives, new opportunities emerge. For
example, cities nowadays embed sensors into parking lots
to measure occupation. This capability, in turn, allows for
new application scenarios, such as smart parking. Once a car
approaches an empty parking lot, the lot can automatically

1 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 promo-
tional 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.

inform the car about the hourly parking fees (based on
location, time, or other locally set parameters), and engage
in their payment when the car drives away. This scenario
belongs to a much more generic application setting where
the plethora of IoT devices are frequently interacting in
two phases. First, they agree on the conditions related
to an activity (e.g., the parking fees). Second, at a later
time, they are executing/ensuring these conditions have been
fulfilled (e.g., payment of the fees). A key challenge here is
that the two IoT devices ordinarily do not trust each other,
as they are, for example, owned or operated by different
entities.

A potential solution to this challenge, worth exploring, are
blockchains and their corresponding smart contracts [1], [2].
In principle, via a smart contract stored in a blockchain, a
vehicle, and a parking sensor could agree on hourly parking
fees, and at a later point in time, enforce the payment (e.g.,
through micropayments). However, blockchain technologies
and smart contracts of today assume powerful nodes that can
communicate and synchronize frequently. Ethereum [3], for
example, uses a virtual machine to execute smart contracts,
where clients need to connect to the blockchain both to
upload their transactions and to query for updates.

Contrary, the nodes in IoT networks face constraints in
energy, memory, and computation capabilities, making the
requirements of current state-of-the-art blockchain technolo-
gies an ill fit for the IoT ecosystem. For example, today’s
resource-constrained devices have some tens of kilobyte
memory, which is quickly exceeded by code and state
information of smart contracts. High bandwidth, always-on
connectivity with 4G or 5G, is infeasible in terms of energy
consumption and hardware costs for many applications that
shall operate for years on battery power. Moreover, cellular
network coverage is far from ubiquitously available. Energy-
efficient LPWAN technologies such as LoRa and SigFox, in
turn, do not provide the required bandwidth for direct on-line
transactions between a smart device and the cloud.

Furthermore, to allow IoT devices to play a central role
in future micro-services (e.g., smart parking), they must
be able to provide a local context (e.g., sensor data) for
the conditions related to the activity about to take place.
However, most smart contracts are not well designed to
handle input from the outside world. While Oracles [4], [5],
as a third-party information source, can supply verified data



from Internet-connected sources, there is no direct way for
a smart contract to trigger a sensor reading and actuator
setting on the IoT sensor-node. Overall, we recognize a gap
between high-level blockchain architectures and the need for
additional services and the capabilities of IoT devices.

To overcome these challenges, we design TinyEVM, a
novel architecture to execute off-chain smart contracts on
low-power IoT devices. We begin by revealing the design
challenges of an application scenario for payment channels
using off-chain smart contracts and introducing three novel
approaches. Firstly, we design the on- and off-chain smart
contracts considering the trade-offs between the device con-
straints and the off-chain protocol. We remove the need
for active synchronization of payment channels by using a
logical clock. Secondly, we customize the Ethereum Virtual
Machine (EVM) to run on resource-constrained IoT devices
with just a few kilobytes of memory. Thirdly, we extend
the EVM by introducing specific IoT opcodes to allow
smart contracts to directly interact with the sensors and
actuators of the local IoT device. Our goal is to enable smart
contracts written for EVMs to benefit from the large pool of
existing contracts and established toolchains for the design,
implementation, and verification of smart contracts.

To summarize, our contributions are as follows:

• We design and implement TinyEVM, an open-source2

system to enable and scale (micro)payments on low-
power IoT devices.

• We devise a virtual machine to execute off-chain smart
contracts on resource-constrained devices.

• We introduce the concept of specific IoT-opcodes to
unify the logic of interacting with sensors and actuators
inside a smart contract.

• We quantify the performance of TinyEVM in terms of
computation, delay, memory, and energy consumption.
Notably, we find that low-power devices (TI-CC2538)
can deploy a smart contract in 215 ms on average. The
node can complete an off-chain payment in 584 ms on
average.

• We finally provide a discussion of implementation
challenges and trade-offs regarding off-chain protocols
for resource-constrained devices.

Outline. We organize this paper with the following struc-
ture. In Section II, we provide the necessary background
for TinyEVM. In Section III, we provide an overview of
our application scenario and the design requirements. In
Section IV, we provide the system design of TinyEVM. In
Section V, we provide a security analysis of our design.
We present the evaluation results in Section VI. Finally, we
provide the related work in Section VII and the conclusion
in Sections VIII.

2https://github.com/chrpro/TinyEVM

II. BACKGROUND

In this section, we provide the essential background to
understand the concepts of Blockchains, Smart Contracts,
the Ethereum Virtual Machine, Payment Channels (PC), and
the Plasma framework.

A. Overview of Blockchains

A blockchain is a distributed ledger replicated by multiple
nodes and kept consistent via a consensus protocol. In
cryptocurrencies like Bitcoin and Ethereum, the protocol is
called mining. With mining, each node can create a new
state by solving a probabilistic mathematical puzzle.

As blockchains became popular, their scalability and per-
formance limitations became apparent [6], [7]. The research
community responded with several proposals to scale the
blockchains like sharding [8], [9], consensus algorithm vari-
ations [10], and trusted execution [5]. In this paper we focus
on three prominent proposals: (a) side-chains [11], (b) pay-
ment channels [12], [13], and (c) payment networks [14],
which we further described below.

B. Smart Contracts and the Ethereum Virtual Machine

Smart contracts are executable programs stored as byte-
code in the blockchain. They highly extend the use of
a blockchain as they can programmable change its state.
For example, with the so-called Ethereum Virtual Ma-
chine (EVM), each node participating in the consensus of
the blockchain executes the smart contracts on its local EVM
and validate the correctness of the created new state.

The EVM is a Quasi-Turing complete machine [3] to
execute state-transitions in the blockchain. The EVM is a
256-bit stack-based machine executing bytecode statements.
Each statement consists of an opcode, with 71 active (dis-
crete) opcodes at the time of writing. The machine avoids
an infinite execution of the bytecode by charging a fee
for each execution statement, the so-called gas. This fee
inhibits micro-payments to be affordable, which is why
payment channels have been suggested (see below). If a
smart contract runs out of gas in the middle of execution, it
is aborted.

The current design of EVM treats smart contacts as
sequential programs with no support for concurrency. More-
over, EVM does not allow smart contracts to have access to
data outside of the network, limiting their usefulness. For a
smart contract to include sensor data, current solutions use
services such as Oracles [4]. Oracles act as a third-party
information source, and supply verified data from Internet
sources. TinyEVM proposes a novel approach to include IoT
opcodes inside the EVM, where the smart contract can have
access to the sensors and actuators of the device.

C. Payment Channels

The fee(s) for each payment in the blockchain often makes
repeated micropayments unaffordable. Prominent proposals

2



to overcome this limitation are off-chain protocols like
payment channels (PC) [12], [13].

With PC, two parties can swiftly exchange small payments
and postpone updating the blockchain (avoiding the fees)
until they reach a final state. The parties pre-agree and sign a
smart contract, which locks a specific amount of money for a
specified period. Later, any participant can unlock the funds
by providing a final state signed by both participants within
the pre-agreed period. As such, the payment channel is a
combination of three distinct concepts: 1) multi-signature
addresses, 2) time-locks, and 3) hash-locks.

Multi-signature addresses require n-of-n signatures to
unlock its funds. The typical case is a 2-of-2 signature ad-
dress that requires the approval of both parties to unlock the
fund. A time-lock restricts the validity of the multi-signature
to a limited time. A hash-lock requires the revealing of the
pre-image of a secret hash value to consider a payment as
valid. The payment channel requires at least two on-chain
messages to the public blockchain. One message to open the
channel and lock the desired amount, including the hash-
locks and time-locks. Depending on the design, the channel
allows the owner to send messages to update the status or
extend the lock-period. With an open channel, two parties
perform off-chain payments by exchanging signatures. When
they reach the time to close the channel, they reveal the
secret-hash.

There are two main extensions of payment channels. First,
payment networks [12], [14] reuse existing user channels to
route payments off-chain. Second, state channels [15]–[17]
provide a general use of channels to store state changes for
any application. TinyEVM builds on the design concepts of
payment channels and adapts them to the specific require-
ments of IoT applications.

D. Side-Chains
Another proposal to scale blockchains is the idea of side-

chains [11], [18]. A typical side-chain system includes three
main components: 1) an on-chain smart contract, 2) side-
chain(s), and 3) an exit function.

The on-chain smart contract is published in the main-
chain, and it acts as a bridge between several side-chains.
The smart contract locks the funds in the main-chain that
the side-chains can circulate as off-chain tokens. The nodes
participating in the side-chain are responsible for maintain-
ing the side-chain. Each side-chain has a mechanism for
validating blocks and a fraud-proof mechanism. The fraud-
proof(s) is used by the users to report malicious users trying
to exit on the main-chain. The exit function allows off-chain
nodes to claim the tokens from the side-chain(s). Finally, any
node can challenge an exit request on the main-chain using
a fraud-proof.

III. TINYEVM OVERVIEW

This section describes the motivation behind TinyEVM.
First, we introduce a simple application scenario and the

Icons by flaticon (CC 3.0 BY)

IoT to IoT (802.15.4, BLE, TSCH…) IoT to Backend

Ethereum

1

2
3

Figure 1: The parking application scenario: 1) The vehicle
and the parking lot communicate via a short-range protocol.
2) They open an off-chain payments channel with an initial
deposit and perform offline payments. 3) A node can at
anytime submit a final state to the blockchain, in our case
Ethereum.

parties involved therein. Second, we present the system
requirements and challenges for low-power devices. Third,
we motivate our threat model based on the application
scenario.

A. Application Scenario: Smart Parking

Nowadays, smart parking lots equipped with sensors can
detect occupation, and they can interact with a vehicle
occupying a spot, for example, via low-power wireless tech-
nologies. We envision a marketplace where a car owner and a
parking company negotiate the terms of parking and perform
micropayments. For this, the car owner and the parking
company publish a template smart-contract to a blockchain,
which includes the necessary payment information.

When a vehicle approaches the parking lot, and the
devices come within range, the lot can initiate the smart
contract and create an off-chain payment channel with the
vehicle via low-power wireless technologies, see Figure 1.
The channel includes the common initial deposit of funds
by the vehicle. During the parking, they may do multiple
transactions and interactions, such as hourly payments or
updates on the payment rates based on the time of day. At
the end of the parking, they close the off-chain channel and
sign the final state, which the parking lot can publish to the
blockchain to claim the payment.

B. System Requirements

From the above scenario, we derive the following require-
ments for the application:

Sensor utilization: The parking lot would like to charge
the vehicle owner based on the location of the parking spot,
time of day, and possibly other locally relevant conditions,
such as the parking availability. Thus, prices can vary and
have to be agreed on, for example, via a smart contract.

Low latency: Both parties expect the whole process of
negotiating and charging for the parking to be automated and

3



take place in the order of seconds. For this reason, we fa-
vor short-range wireless communication for our application
scenario.

Low energy consumption: The parking service expects
to depend on cheap devices with long battery life-time. The
vehicle-owner expects a cheap device easily installed into a
regular car.

C. System Challenges

Beyond the challenge of designing a off-chain protocol,
we face other system challenges. To ensure compatibility
with off-the-shelf smart contracts and to be able to benefit
from the wide variety of tools for smart contract writing,
testing, and verification designed by the Ethereum commu-
nity, one key design goal of TinyEVM is to natively support
the Ethereum Virtual Machine (EVM) bytecode. However,
EVM is a 256-bit word-size virtual machine. This word-
size leads to two key challenges: (1) resource inefficiency
and (2) the complexity of executing 256-bit operations on a
32-bit machine.

First, from a resource perspective, the EVM does not
utilize the memory efficiently. All operations are based on
256-bit variables and addresses. As a result, every VM op-
code, even a simple addition, operates on 256-bit variables.
The main reason for this EVM specification was to ease
cryptographic operations like the Keecak256, which works
on 256-bit digests. However, the vast majority of variables
in a smart contract rarely reach values that require 256-bit
storage. Similarly, as our evaluation shows, smart contracts
do not reach a size in code or data that they would need
256-bit address space. The result is an inefficient memory
use that could prohibit their execution of smart contracts on
IoT devices.

The second challenge is the run-time overhead of the
virtual machine. The embedded hardware does not directly
support 256-bit operations. Instead, we have to emulate 256-
bit operations using a 32-bit micro-controller by implement-
ing custom libraries and, as a result, executing a single EVM
opcode requires in the order of hundreds of MCU cycles.
This inefficiency may further limit the potential of Ethereum
smart contracts on resource-constrained IoT devices.

D. Threat Model

In our scenario, we assume mutually-distrusting, rational
parties using a payment channel to exchange payments. The
threat model includes two potential threats and focuses on
the inability of nodes to revoke previous states of the pay-
ment channel. Notably, the node that receives the payment
faces the threat of the inability to report a misbehaving peer
before the contest period expires. On the other hand, the
node sending the payment faces the threat of the inability
to unlock her money from the channel.

The receiver expects a non-repudiation property of the
system. After several payments, none of the parties will be

Parking Sensor Smart Car Ethereum

Register 
Template

O
n-

Ch
ai

n
Sm

ar
t

Co
nt

ra
ct

Off-Chain 
Execution 

O
ff-

Ch
ai

n 
Sm

ar
t C

on
tr

ac
t

O
n-

Ch
ai

n 
Co

m
m

it(
s)

Public 
Address 
0x00

Smart Contract
Local Copy

New Payment 
Channel

On-Chain Commit(s)

Offline Payment(s)

Side-Chain(s)

1
2

3

Side-Chain(s)

Challenge Period

Sensor 
Data

Sign Final State

Close Channel

Side-Chain

Icons by flaticon (CC 3.0 BY)

Figure 2: The system includes three phases: 1) Publishing
the on-chain template smart contract. 2) Creating an off-
chain payment channel and signing (multiple) payments.
3) On-chain commit of a final state, which activates the
challenge period, and nodes can dispute with their local side-
chains.

able to deny the participation of the exchange. The parking
sensor will be able to claim the money from the blockchain
at any time for the time the car has stayed there. On the other
hand, the sender expects a finite property of the payment
channel, which means the channel eventually will close, and
the sender can reclaim any remaining money when it leaves.

IV. TINYEVM SYSTEM DESIGN

TinyEVM makes four design contributions: First, it sep-
arates the transactions of IoT applications into three high-
level phases: 1) The on-chain smart contract, 2) the off-
chain smart contract, and 3) the on-chain commit(s). Second,
TinyEVM customizes the Ethereum Virtual Machine (EVM)
to address the resource constraints of IoT devices while
staying compatible with the native EVM language. Third,
we introduce a template design for smart contracts and the
separation of on- and off-chain functionality. Fourth, we
extend smart contracts and the EVM with IoT opcodes to
interact with onboard IoT sensors and actuators. The new
opcodes allow IoT devices to include sensor data and sensor
actuation as a part of smart contract development.

4



Component EVM TinyEVM

Stack memory 256-bit 256-bit
Random access memory 8-bit 8-bit
Storage space 256-bit 8-bit

Operation opcodes 27 27
Smart contract opcodes 25 21
Memory opcodes 13 13
Blockchain opcodes 6 -
IoT opcodes - 1

Table I: Comparison of the original EVM and the TinyEVM
specifications. The word size of the stack and random access
memory remains the same. TinyEVM removes the opcodes
related to (on-)blockchain operation, it uses 8-bit side-chain
storage space, and it introduces new IoT-specific opcodes.

A. On- and Off-Chain Transactions: Three Phases

The deployment and execution of smart contracts include
three high-level phases, visible in Figure 2.

1) On-chain smart contract. A node publishes a smart-
contract as a template in the blockchain, which includes the
constructor for off-chain payment channels. The node makes
a deposit to be charged for parking services, which works as
an insurance in case of a dispute. This operation is similar
to the on-chain contract used in side-chains. The on-chain
smart contract serves as a bridge between the blockchain
and our off-chain payment channels.

2) Off-chain smart contract. The nodes use the template
to deploy a new off-chain payment channel using a unique
monotonic counter (logical clock) as an identifier. The off-
chain payment channels are locally generated smart contracts
that allow the use of sensor data. Nodes may use the
sensor readings, actuator interactions, or data received from
other IoT devices as a part of the smart contract. The
sensor data can range from weather conditions or device
location, combined with the knowledge about the occupation
of nearby parking spots – derived, for example, from the
LIDAR data of a modern car – which can be used to evaluate
and negotiate the parking fees. The nodes continue with
the signing and exchanging of off-line payments until they
close the payment channel. The nodes can open and close
an arbitrary number of payment channels, but limited to the
money deposited and locked in the on-chain smart contract.

3) On-chain commit. At any time, a node can exit from
an off-chain channel by publishing a final channel state or a
(side-chain) log of its local execution. Our commit function
checks the logical clock of the channel and the validity of
the signatures. In the case of a correct state, the new state
is appended to the tree of the on-chain smart contract. The
other node can challenge the state using the local log(s)
of the off-chain payments. Finally, there is an exit function
that a node can activate, which stops further updates from
off-chain channels. The activation of the exit function starts
the expiration period, and then it will dissolve the on-chain

smart contract and return any unspent money. During that
time, the other node can dispute the latest state and claim the
insurance money, as common for established side-chains.

B. Customized Ethereum Virtual Machine

We enable smart contracts on IoT devices by customizing
the Ethereum Virtual Machine (EVM) to meet the constraints
of IoT devices, especially in terms of device memory. In
Table I, we list the specifications of the original EVM
compared with our customized one. There are three types
of memory that a smart contract can use: 1) stack memory,
2) random-access memory, and 3) storage memory. We
achieve to meet the memory requirements without the loss
of functionality and compatibility of the IoT device.

The original EVM defines a 256-bit word machine, which
is not directly supported on a 16-bit or 32-bit micro-
controller. However, we keep the same word-size for com-
patibility reasons, and emulate a 256-bit word-size in our
implementation. This implementation allows us to use the
original Ethereum bytecode with no modifications. However,
the storage space is irrelevant for off-chain executions. These
operations are needed only for the main-chain. For the off-
chain computations, we utilize an 8-bit storage space to store
only the side-chain created by the IoT nodes.

We list the machine opcodes into five categories. First,
the operation opcodes define the necessary computations,
like addition and multiplication. The original EVM supports
27 operations, and TinyEVM supports all of them. Second,
the smart contract opcodes are related to smart contract exe-
cution like method calls, and returns. TinyEVM supports the
necessary operations except for the GAS operations. There is
no charging for the off-chain computations as all operations
are executed locally. Third, the memory opcodes are related
to operations on memory like store and load, and TinyEVM
supports all of them. Fourth, the blockchain opcodes are
used to get information from the blocks of the blockchain.
TinyEVM does not support any block-related opcode since
there is no access to the blockchain during local execution.
Finally, TinyEVM introduces a novel opcode for IoT sensor
data. This extension allows us to include sensor data inside
the smart contract.

We observed that the original EVM includes unused op-
code(s) that are not currently in use. Thus, we utilized one of
the unused opcodes to introduce the IoT sensor functionality.
In detail, we use the 0x0c undefined opcode to represent
the action of sensing or actuating on the device. Details,
such as which sensor to use and additional parameters are
given as options to the opcode. This allows us to include
arbitrary types of sensor data, and the TinyEVM hides the
implementation details from the user.

C. On-Chain Smart Contract

For our purposes, we assume that the entity providing a
service (e.g., the parking service) has published the parking

5



1 contract Template {
2 address[] PaymentChannels;
3 uint Balance;
4 address payable public Receiver;
5 uint Logical-Clock = 0;
6 MerkleSumTree Side-Chain-Root;
7
8 function CreatePaymentChannel (uint64 Money)

public {
9 newPaymentChannel = new PaymentChannel(

receiver, Money);
10 PaymentChannels.push(newPaymentChannel);
11 Logical-Clock += 1;
12 }
13 function OnChainCommit{...} //user specific
14 function Challenge{...} //user specific
15 }

Listing 1 : Factory Template in Solidity

1 contract PaymentChannel {
2 address payable public Sender;
3 address payable public Receiver;
4 uint public sensor_data;
5
6 constructor(address payable _recipient) public

payable {
7 sender = msg.sender;
8 recipient = _recipient;
9 assembly{

10 0x0c //IoT sensor opcode
11 sstore(0x0c) // Store sensor data
12 }
13 }
14 function close(uint amount, bytes memory

signature) public payable {
15 require(msg.sender == recipient);
16 require(isValidSignature(amount, signature));
17 recipient.transfer(amount);
18 selfdestruct(sender);
19 }
20}

Listing 2 : Payment Channel in Solidity

conditions as a smart contract template on the blockchain.
The template includes all rules that the two parties need
to create and use an off-chain payment channel. Upon
accepting the conditions, the user (e.g., the owner of the
car) locks the desired amount to be used for the services.
Alternatively, if both parties have to negotiate some details,
an additional negotiation phase is possible to construct the
template [19].

The template is a factory-smart-contract [20], which can
create and deploy child contracts dynamically, see Listing 1.
The child contracts in our scenario are the payment channels,
see Listing 2.

D. Off-Chain Smart Contract

The second phase in Figure 2 starts when both entities
come within range of their low-power wireless technologies,

e.g., a smart-car and smart-parking lot come within range.
The nodes exchange their sensor data and transactions via
a short-range protocol like TSCH [21] or BLE [22]. Please
note that the design of TinyEVM is agnostic to the specific
technology used. Both entities execute the bytecode of the
template to generate an off-chain payment channel. The
payment channel includes an ID and the sequence number,
which uniquely identifies each transaction on the channel.
The sequence number acts as a logical clock, which is
different from the real-time bound of the original concept
of payment channels. By using sequence numbers, we can
determine the causal order of the payments. With the casual
order, the channels can capture the order in which the
payments happens, but not the actual time that they occur.
The use of logical clocks loosens the requirements for
communication and synchronization.

Each device maintains a sequence number that uniquely
identifies each of its transactions by simply incrementing a
counter for each new transaction. The sequence number is
later used for verification and ensures that no device skips
reporting any transactions. With the off-chain payment chan-
nel, the two nodes can perform several off-chain payments
by exchanging signed transactions (using their low-power
wireless radios). The signed off-chain payments are stand-
alone artifacts that can claim money from the main-chain.
The signed payment includes information on the payment
channel ID and its unique counter, which makes it trivial to
verify the logical order. A node can report either the payment
or the final state of the channel, which aggregates all other
previous payments. Each execution of the payment channel
extends the local (side-chain) log of the node, which links
each state with the previous. The local (side-chain) log uses
the root published on the main-chain smart contract, which
allows verification of the logical order of the executions and
ensures that no transactions are omitted. The nodes use the
off-chain payment channel repetitively to perform several
payments until they close it. The total amount of payments
is limited by the funds locked in the main-chain.

E. On-Chain Commit & Challenge Period

At any time, a node can submit a signed final state of
a closed off-chain payment channel. The sequence number
of the channel allows the nodes to retrieve the money
asynchronously. The node can submit a state that happened
after the latest submit without providing the details of
the actual time that it happened. Every time the on-chain
contract receives a request, it verifies the signed states and
updates its sequence number to the highest that received.

The on-chain smart contract uses a Merkle-Sum-Tree [11],
which has the sum of the payments and the hash value. The
sum value is used as a validation condition along with the
hash value. This condition makes it possible for auditing the
sum of the payments. Each payment adds to the overall sum,
and if it exceeds the allowed range, the payment is invalid,

6



and the other node can claim the insurance money. In our
system, we further extend the validation condition with the
sequence numbers. Reporting a state with a higher sequence
number accumulates the changes of the previous states.

Finally, the sensor node can activate the exit function by
submitting a signed final state. This action restricts further
submission and starts the challenge period. The other node
can submit a transaction with a higher sequence number
value to claim the insurance money. As each transaction is
signed, it is not disputable.

V. SECURITY ANALYSIS

";"""date"",""2021-04-28T10:44:38Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""TinyEVM: Off-Chain Smart Contracts on Low-Power IoT Devices""
""xmp:CreatorTool"",""TeX""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""With the rise of the Internet of Things (IoT), billions of devices ranging from simple sensors to smart-phones will participate in billions of micropayments. However, current centralized solutions are unable to handle a massive number of micropayments from untrusted devices.&lt;br /&gt;&lt;br /&gt;Blockchains are promising technologies suitable for solving some of these challenges.&lt;br /&gt;Particularly, permissionless blockchains such as Ethereum and Bitcoin have drawn the attention of the research community.&lt;br /&gt;However, the increasingly large-scale deployments of blockchain reveal some of their scalability limitations. Prominent proposals to scale the payment system include off-chain protocols such as payment channels. However, the leading proposals assume powerful nodes with an always-on connection and frequent synchronization. These assumptions require in practice significant communication, memory, and computation capacity, whereas IoT devices face substantial constraints in these areas. Existing approaches also do not capture the logic and process of IoT, where applications need to process locally collected sensor data to allow for full use of IoT micro-payments.&lt;br /&gt;&lt;br /&gt;In this paper, we present TinyEVM, a novel system to generate and execute off-chain smart contracts based on sensor data.&lt;br /&gt;TinyEVM&#39;s goal is to enable IoT devices to perform micro-payments and, at the same time, address the device constraints.&lt;br /&gt;We investigate the trade-offs of executing smart contracts on low-power IoT devices using TinyEVM.&lt;br /&gt;We test our system with 7,000 publicly verified smart contracts, where TinyEVM achieves to deploy 93 % of them without any modification.&lt;br /&gt;Finally, we evaluate the execution of off-chain smart contracts in terms of run-time performance, energy, and memory requirements on IoT devices.&lt;br /&gt;Notably, we find that low-power devices can deploy a smart contract in 215 ms on average, and they can complete an off-chain payment in 584 ms on average.""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""TeX""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""TinyEVM: Off-Chain Smart Contracts on Low-Power IoT Devices""
""modified"",""2021-04-28T10:44:38Z""
""cp:subject"",""With the rise of the Internet of Things (IoT), billions of devices ranging from simple sensors to smart-phones will participate in billions of micropayments. However, current centralized solutions are unable to handle a massive number of micropayments from untrusted devices.&lt;br /&gt;&lt;br /&gt;Blockchains are promising technologies suitable for solving some of these challenges.&lt;br /&gt;Particularly, permissionless blockchains such as Ethereum and Bitcoin have drawn the attention of the research community.&lt;br /&gt;However, the increasingly large-scale deployments of blockchain reveal some of their scalability limitations. Prominent proposals to scale the payment system include off-chain protocols such as payment channels. However, the leading proposals assume powerful nodes with an always-on connection and frequent synchronization. These assumptions require in practice significant communication, memory, and computation capacity, whereas IoT devices face substantial constraints in these areas. Existing approaches also do not capture the logic and process of IoT, where applications need to process locally collected sensor data to allow for full use of IoT micro-payments.&lt;br /&gt;&lt;br /&gt;In this paper, we present TinyEVM, a novel system to generate and execute off-chain smart contracts based on sensor data.&lt;br /&gt;TinyEVM&#39;s goal is to enable IoT devices to perform micro-payments and, at the same time, address the device constraints.&lt;br /&gt;We investigate the trade-offs of executing smart contracts on low-power IoT devices using TinyEVM.&lt;br /&gt;We test our system with 7,000 publicly verified smart contracts, where TinyEVM achieves to deploy 93 % of them without any modification.&lt;br /&gt;Finally, we evaluate the execution of off-chain smart contracts in terms of run-time performance, energy, and memory requirements on IoT devices.&lt;br /&gt;Notably, we find that low-power devices can deploy a smart contract in 215 ms on average, and they can complete an off-chain payment in 584 ms on average.""
""pdf:docinfo:subject"",""With the rise of the Internet of Things (IoT), billions of devices ranging from simple sensors to smart-phones will participate in billions of micropayments. However, current centralized solutions are unable to handle a massive number of micropayments from untrusted devices.&lt;br /&gt;&lt;br /&gt;Blockchains are promising technologies suitable for solving some of these challenges.&lt;br /&gt;Particularly, permissionless blockchains such as Ethereum and Bitcoin have drawn the attention of the research community.&lt;br /&gt;However, the increasingly large-scale deployments of blockchain reveal some of their scalability limitations. Prominent proposals to scale the payment system include off-chain protocols such as payment channels. However, the leading proposals assume powerful nodes with an always-on connection and frequent synchronization. These assumptions require in practice significant communication, memory, and computation capacity, whereas IoT devices face substantial constraints in these areas. Existing approaches also do not capture the logic and process of IoT, where applications need to process locally collected sensor data to allow for full use of IoT micro-payments.&lt;br /&gt;&lt;br /&gt;In this paper, we present TinyEVM, a novel system to generate and execute off-chain smart contracts based on sensor data.&lt;br /&gt;TinyEVM&#39;s goal is to enable IoT devices to perform micro-payments and, at the same time, address the device constraints.&lt;br /&gt;We investigate the trade-offs of executing smart contracts on low-power IoT devices using TinyEVM.&lt;br /&gt;We test our system with 7,000 publicly verified smart contracts, where TinyEVM achieves to deploy 93 % of them without any modification.&lt;br /&gt;Finally, we evaluate the execution of off-chain smart contracts in terms of run-time performance, energy, and memory requirements on IoT devices.&lt;br /&gt;Notably, we find that low-power devices can deploy a smart contract in 215 ms on average, and they can complete an off-chain payment in 584 ms on average.""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""Profentzas, C., Almgren, M., Landsiedel, O.""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017) kpathsea version 6.2.3""
""meta:author"",""Profentzas, C., Almgren, M., Landsiedel, O.""
""trapped"",""False""
""meta:creation-date"",""2020-04-17T11:42:39Z""
""created"",""2020-04-17T11:42:39Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-04-17T11:42:39Z""
""resourceName"",""522775_Fulltext.pdf""
""Author"",""Profentzas, C., Almgren, M., Landsiedel, O.""
""producer"",""PDFsharp 1.32.3057-g (www.pdfsharp.net) (Original: pdfTeX-1.40.18; modified using iTextSharp 4.1.6 by 1T3XT)""
""pdf:docinfo:producer"",""PDFsharp 1.32.3057-g (www.pdfsharp.net) (Original: pdfTeX-1.40.18; modified using iTextSharp 4.1.6 by 1T3XT)""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""Keywords"","" Ethereum,  Smart Contracts, Internet of Things,  Blockchain,  Payment Channels,  Off-chain, ""
""access_permission:modify_annotations"",""true""
""dc:creator"",""Profentzas, C., Almgren, M., Landsiedel, O.""
""dcterms:created"",""2020-04-17T11:42:39Z""
""Last-Modified"",""2021-04-28T10:44:38Z""
""dcterms:modified"",""2021-04-28T10:44:38Z""
""title"",""TinyEVM: Off-Chain Smart Contracts on Low-Power IoT Devices""
""Last-Save-Date"",""2021-04-28T10:44:38Z""
""pdf:docinfo:keywords"","" Ethereum,  Smart Contracts, Internet of Things,  Blockchain,  Payment Channels,  Off-chain, ""
""pdf:docinfo:modified"",""2021-04-28T10:44:38Z""
""meta:save-date"",""2021-04-28T10:44:38Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017) kpathsea version 6.2.3""
""Content-Length"",""671179""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Profentzas, C., Almgren, M., Landsiedel, O.""
""dc:subject"","" Ethereum,  Smart Contracts, Internet of Things,  Blockchain,  Payment Channels,  Off-chain, ""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""13""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""728"",""4765"",""4546"",""4269"",""3869"",""4703"",""4115"",""4698"",""3262"",""4864"",""3149"",""4965"",""4279""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"","" Ethereum,  Smart Contracts, Internet of Things,  Blockchain,  Payment Channels,  Off-chain, ""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-04-17T11:42:39Z""
";https://scholar.google.ch/scholar?start=720&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098751-79;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Server-aided Revocable IBE with Identity Reuse;X Ma, D Lin ; The Computer Journal, 2020  academic.oup.com;;"… Encryption (IBE). Boneh and Franklin (BF) [2] proposed the first concrete IBE scheme

and proved the security in the random oracle model [3]. Afterwards, it has attracted

a significant amount of follow-up works [4–19]. Nowadays …";Autres articles;;null;;;;https://scholar.google.ch/scholar?start=620&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098747-68;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;[CITATION][C] AIS Electronic Library (AISeL);R Belchior, M Correia, A Vasconcelos;;;null;Autres articles;;null;;;;https://scholar.google.ch/scholar?start=610&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098747-63;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;A survey on ethereum systems security: Vulnerabilities, attacks, and defenses;H Chen, M Pendleton, L Njilla, S Xu ; ACM Computing Surveys (CSUR), 2020  dl.acm.org;;"… Some DApps issue their own cryptocurrency, called tokens, for purposes like Initial Coin Offering

(ICO … may be better addressed in the environment rather than by the Ethereum blockchain … including

ACM CCS, IEEE SP, NDSS, Usenix Secu- rity, Eurocrypt, Crypto, ACSAC, DSN …";Cité 70 fois;Les 7 versions;[PDF] arxiv.org;https://arxiv.org/pdf/1908.04507;"
1

A Survey on Ethereum Systems Security:
Vulnerabilities, Attacks and Defenses

Huashan Chen, Marcus Pendleton, Laurent Njilla, and Shouhuai Xu

Abstract—The blockchain technology is believed by many to
be a game changer in many application domains, especially
financial applications. While the first generation of blockchain
technology (i.e., Blockchain 1.0) is almost exclusively used for
cryptocurrency purposes, the second generation (i.e., Blockchain
2.0), as represented by Ethereum, is an open and decentralized
platform enabling a new paradigm of computing — Decentralized
Applications (DApps) running on top of blockchains. The rich
applications and semantics of DApps inevitably introduce many
security vulnerabilities, which have no counterparts in pure
cryptocurrency systems like Bitcoin. Since Ethereum is a new,
yet complex, system, it is imperative to have a systematic and
comprehensive understanding on its security from a holistic
perspective, which is unavailable. To the best of our knowledge,
the present survey, which can also be used as a tutorial, fills this
void. In particular, we systematize three aspects of Ethereum
systems security: vulnerabilities, attacks, and defenses. We draw
insights into, among other things, vulnerability root causes, attack
consequences, and defense capabilities, which shed light on future
research directions.

Index Terms—Blockchain, Ethereum, Security, Smart Con-
tract, Vulnerabilities, Attacks, Defenses

I. INTRODUCTION
The notion of blockchain was implicitly introduced in 2008

as the key underlying technique of the cryptocurrency known
as Bitcoin [1], which uses a transaction-centered model known
as unspent transaction outputs (UTXO). In this model, a
blockchain is a distributed and public ledger, which records
the payment transactions between parties over a peer-to-peer
(P2P) network. Unlike traditional digital cash systems [2], in
which there is a trusted third party (e.g., bank), there is no
trusted third party in a blockchain system in general and in
Bitcoin in particular. Bitcoin is often referred to as Blockchain
1.0 because it only offers payment services. The innovation
of the Bitcoin system is its consensus protocol, which allows
mutually distrusting nodes in a P2P network to eventually
reach a consensus on the outcome after executing payment
transactions. Unlike traditional consensus protocols [3], the
participants are from an open network and are incentivized by
the payment of Bitcoins (or BTCs), which are “mined” through
a clever cryptographic hash function known as Proof-of-Work
(PoW), an idea originally proposed as an anti-spam technique
[4].

Perhaps inspired by the success of Bitcoin as well as
the need to support semantically richer (than just payment)
applications, the notion of smart contracts has been introduced
H. Chen and S. Xu are with the Department of Computer Science,

University of Texas at San Antonio. M. Pendleton and L. Njilla are
with the U.S. Air Force Research Laboratory, Rome, NY. Correspondence:
shxu@cs.utsa.edu

to represent autonomous programs, leading to a new paradigm
of Decentralized Applications (DApps) that run on top of
blockchains and consist of many interacting smart contracts.
The Ethereum system was launched in 2015 to support smart
contracts, while offering its inherent cryptocurrency known as
Ether [5] and using an account-centered model (rather than
the UTXO model mentioned above). Ethereum has become
the de facto standard platform for DApps. At the moment
of writing, the market value of Ethereum is over US$31B
with approximately one million smart contracts executing on
top of the Ethereum blockchain [6], [7]. The success of
Ethereum ushers in Blockchain 2.0, which goes much beyond
the payment-centered Blockchain 1.0.
While Ethereum facilitates semantically richer applications

than Bitcoin, it also enlarges the threat surface, as evidenced
by the many high-profile attacks. One example is the DAO [8]
attack in year 2016, in which case an attacker exploited the so-
called reentrancy vulnerability (which will be detailed later)
to steal approximately US$60M. In July 2017, a vulnerability
in the Parity wallet contract caused the loss of US$31M [9].
In April 2018, the MyEtherWallet wallet fell victim to a
BGP and DNS hijacking attack, enabling the hacker to steal
approximately US$17M [10]. These attacks highlight that our
capabilities in securing the Ethereum system are limited. This
should not be taken as a surprise because Ethereum is a
new programming paradigm with DApps running on top of
blockchains with many autonomous contracts.
The motivation of the present survey is in three-fold of

researchers, practitioners, and students. From the standpoint
of a researcher who wants to investigate Ethereum security,
there is a need for a source of systematized treatment on the
problems related to Ethereum security. Despite the fact that
there have been some surveys, they did not offer a systematic
and comprehensive view on Ethereum vulnerabilities, attacks,
and defenses as we do. While referring to the related prior
work in Section I-B for details, we mention the following:
there is neither systematic understanding of the Ethereum
vulnerabilities that have been discovered, nor systematic un-
derstanding of their root causes; this may explain why there are
still a number of vulnerabilities that are completely open. From
the standpoint of a practitioner, there is a need for a source of
best practices and guiding principles. Industry has conducted
due diligence in summarizing many best practices [11], which
however may overwhelm practitioners. Therefore, it might be
more useful to have a small number of guiding principles that
are easier to adopt in practice. From the standpoint of a student
who wants to learn about Ethereum security, there is a need
for a succinct yet comprehensive and systematic source that
also offer references to materials of greater details.

ar
X

iv
:1

90
8.

04
50

7v
1 

 [
cs

.C
R

] 
 1

3 
A

ug
 2

01
9



2

A. Our contributions
We provide a systematic and comprehensive survey on

Ethereum systems security. It is systematic in the sense that
vulnerabilities, attacks, and defenses as well as the relation-
ships between them are accommodated. It is comprehensive
in the sense that it covers both the Ethereum platform via
a layered architecture and the environment in which the
Ethereum platform operates. In terms of vulnerabilities, we
enumerate 44 types of Ethereum vulnerabilities according to
the layers of the Ethereum architecture and the environment in
which Ethereum operates. Perhaps more importantly, we ana-
lyze and systematize the root causes of those vulnerabilities.
This allows us to provide insights into how to prevent some
Ethereum vulnerabilities and how to cope with the inevitable
vulnerabilities, including those that are largely open. Some of
our findings and insights are highlighted as follows:

1) Ethereum smart contracts introduce new kinds of vul-
nerabilities that do not have counterparts in traditional
paradigm of applications.

2) It is important to design more secure programming
languages and supporting tools for programmers to write
more secure smart contracts.

3) The vulnerabilities caused by the design and implemen-
tation of the Ethereum blockchain are harder to cope
with than vulnerabilities in the traditional paradigm.

4) The vulnerabilities in the Ethereum environment are
largely caused by human, usability, and networking
factors.

5) There are many vulnerabilities (e.g., outsourceable puz-
zle, 51% hashrate, and under-priced opcodes) that must
be tackled in order to adequately defend Ethereum or
blockchain-based DApp systems in general.

In terms of attacks, we systematize 26 attacks against
Ethereum according to the layers of the Ethereum architecture.
Perhaps more importantly, we relate these attacks to the
vulnerabilities and systematize the attack consequences. Some
of our findings are highlighted as follows:

1) The largest single-incident financial loss thus far was
caused by a denial-of-service (DoS) attack against the
Parity wallet. This attack disabled a library that is used
by many contracts and is therefore quite different from
traditional DoS attacks.

2) DApps running on top of blockchains are not fully
decentralized when they use centralized web interfaces,
even if the underlying blockchain is fully decentralized.

3) Ethereum application-layer attacks have caused the
largest financial losses.

In terms of defenses, we systematize 47 defenses into two
classes: proactive defenses, which aim to prevent attacks as
much as possible; and reactive defenses, which aim to cope
with the hidden vulnerabilities (i.e., their existence may not
be known to the defender). Perhaps more importantly, we
present a deeper analysis of the defenses according to (i) their
capabilities in mitigating the damages that can be incurred by
exploiting vulnerabilities, and (ii) the defense effort that has
been investigated to cope with each kind of vulnerabilities.
Some of our findings are highlighted as follows:

1) Industry has come up with a significant set of best
practices for guiding the development of smart contracts.
These best practices, if adequately executed, can indeed
avoid many vulnerabilities.

2) Existing proactive defenses can defend against attacks
that exploit many vulnerabilities; in contrast, existing
reactive defenses can only defend against attacks that
exploit a few vulnerabilities.

3) There are large discrepancies between levels of effort
and investment into different kinds of attacks (i.e., much
more investment into defending against high-profile at-
tacks than low-profile attacks).

4) Existing studies focus on defending against attacks that
attempt to exploit vulnerabilities in the DApp back-end
(i.e., smart contracts), but largely ignore the protection
of the DApp front-end (i.e., browser) and the interactions
between the front-end and the back-end.

Although the present paper focuses on the Ethereum system,
the aforementioned findings related to vulnerabilities, attacks
and defenses might be applicable to blockchain-based systems
in general. Moreover, we discuss some fundamental research
problems that must be adequately tackled in order to secure
and defend Ethereum and blockchain-based systems, includ-
ing:
1) There is a lack of deep understanding on the rigorously-

defined properties of blockchain-based systems.
2) There is a lack of deep understanding on the rigorous

analysis methodologies that are necessary and sufficient
for analyzing the desired properties of blockchain-based
systems.

3) There is a lack of deep understanding on the metrics that
are necessary and sufficient for analyzing the security
and risk of blockchain-based systems.

In order to improve readability and ease the reference to the
large number of vulnerabilities, we denote the vulnerabilities
by 1,… ,44, respectively. Similarly, we respectively denote
the attacks by 1,… ,26 and the defenses by 1,… , D47.Moreover, we use “i(j ,⋯)” to denote that attack iexploits vulnerabilities j and possibly others.
The preceding discussion justifies how the present paper

would adequately serve the needs of students and researchers.
For practitioners, we mention that we systematize the best
practices into a small number of principles that may be easier
to adopt in practice.

B. Related work
Table I highlights the relationship between the present

work and related prior surveys, which accommodate some
of vulnerabilities, attacks, defenses, and building-blocks. The
most closely related survey is Atzei et al. [12], which discussed
12 types of vulnerabilities, 9 attacks, and 3 defenses in the
context of Ethereum smart contracts (i.e. Blockchain 2.0). In
contrast, we present a much more systematic treatment, by
accommodating 44 types of vulnerabilities, 26 attacks, and
47 defenses. From a methodological standpoint, we further
discuss the root causes of vulnerabilities (e.g., the root cause of
the unchecked call return value vulnerability is the inconsistent



3

TABLE I: Comparison between surveys related to blockchain security and privacy.

Study
Vulnerabilities Attacks Defenses Building-blocks

Blockchain 1.0 Blockchain 2.0 Insights Blockchain 1.0 Blockchain 2.0 Insights Blockchain 1.0 Blockchain 2.0 Insights Cryptography Consensus
[12] 12 9 3

This work 44 ✓ 26 ✓ 47 ✓

[13] 20 6 5
[14] 11 11 30
[15] 22 ✓ 33 yes
[16] 10 ✓

[17] 27 ✓

[18] yes
[19], [20], [21], [22] yes

exception handling of Solidity). Moreover, we draw insights
from the perspectives of vulnerability, attack, and defense.

There are a number of surveys on blockchain security
and privacy which however have different perspectives than
ours. First, Li et al. [13] reviewed security of blockchain
technologies through the lens of 20 types of vulnerabili-
ties, 6 attacks, and 5 defenses, without distinction between
Blockchain 1.0 and 2.0 aspects. Similarly, Zhu et al. [14]
reviewed 11 smart contract vulnerabilities, 11 attacks against
blockchain data, and 30 defenses. On the contrary, we focus on
the Ethereum blockchain system by accommodating 44 types
of vulnerabilities, 26 attacks, and 47 defenses.

Second, Saad et al. [15] explored blockchains’ attack surface
in terms of cryptographic constructions, distributed system
architecture, and applications; they cover 22 attacks and 33
defenses in Blockchain 1.0 and 2.0, but not vulnerabilities.
Their survey is orthogonal to ours because (i) we focus on
the Ethereum system, rather than multiple implementations
of blockchains; (ii) we discuss vulnerabilities and their root
causes as well as the attacks exploiting them, rather than
attack surface; (iii) we provide insights into, and contrast, the
vulnerabilities at different layers of the Ethereum architecture.

Third, Harz et al. [16] discussed 10 smart contract verifi-
cation tools. Similarly, Angelo et al. [17] discussed 27 tools
for analyzing Ethereum smart contracts. On the contrary, we
focus on the defenses of the Ethereum systems security, rather
than purely on smart contracts.

Fourth, Zhang et al. [18] presented a comprehensive re-
view on Bitcoin-like transactions and the underlying (cryp-
tographic) mechanisms. Their review is geared towards the
abstract blockchain model for Bitcoin-like transactions (i.e.,
Blockchain 1.0); in contrast, we focus on the Ethereum
ecosystem, including the design and implementation of the
blockchain platform and DApps. There are surveys that focus
on Bitcoin and cryptocurrencies [23], [24], [25], which use
a transaction-centered model known as unspent transaction
outputs (UTXO). In contrast, we focus on Ethereum, which
uses an account-centered model.

Fifth, Orthogonal to the purpose of the present survey
and tutorial, there are several surveys purely on blockchain
consensus protocols [19], [20], [21], [22]. In contrast, we focus

on the overall Ethereum system.

C. Paper outline

Section II briefly reviews the Ethereum system and dis-
cusses the survey methodology. Section III presents the
44 Ethereum vulnerabilities according to the layers of the
Ethereum architecture and a deeper analysis of their root
causes. Section IV presents the 26 attacks against Ethereum
and a deeper analysis on their consequences. Section V
presents the 47 defenses, classified as proactive or reactive
and a deeper analysis on their capabilities and investments.
Section VI discuss future research directions towards securing
blockchain-based systems, including Ethereum as a special
case. Section VII conclude the present paper.

II. ETHEREUM REVIEW AND SURVEY METHODOLOGY
A. A brief review of the Ethereum system

Figure 1 highlights a 4-layer architecture of the Ethereum
blockchain, operates across these 4 layers. At the application
layer, Ethereum clients execute smart contracts, which are
associated to Ethereum accounts, in EVM. The data layer con-
tains the blockchain data structures. The consensus layer as-
sures a consistent state of the blockchain. Note that Ethereum
plans to replace its current use of Proof-of-Work (PoW)
with a Proof-of-Stake (PoS). The network layer formulates a
Ethereum peer-to-peer (P2P) network of nodes or clients such
that a node can always get the updated state of the blockchain
from some of the active nodes. The environment serves these
4 layers via a corresponding component: a web user interface
to interact with applications; databases for storing blockchain
data; cryptographic mechanisms for supporting the consensus
protocols; and Internet service for the network layer.
1) The application layer: Ethereum supports two types

of accounts: externally owned accounts (EOA) and contract
accounts. An EOA is used to keep a user’s funds in Wei,
which is the smallest subdenomination of Ether and is worth
10−18 Ether. An EOA is associated with, and addressed by,
a public key; access to an EOA is authenticated by showing
the ownership of the corresponding private key. In contrast, a



4

Application layer EVM

Consensus layer PoS PoW

Network layer

Data layer Block Event

Incentives

Account

E
n
v
ir
o
n
m

e
n
t

Information 
verification

Information
propagation

Transaction

Internet 
infrastructure 

Smart 
contract

Node 
discovery

User 
interface

Database

Cryptography

Fig. 1: Architecture of the Ethereum blockchain and its envi-
ronment in which the Ethereum blockchain runs.

contract account is associated with a piece of executable byte-
code (i.e., smart contracts), which defines some business logic
of interest. An EOA or contract account has a dynamic state,
which is defined by: (i) nonce, which tracks the number of
transactions that have been initiated by the owner of the EOA
or the number of contracts created by the contract account;
(ii) balance, which is the amount of Wei (i.e., 10−18 Ether)
owned by the EOA or contract account; (iii) storageRoot,
which is the hash of the root of the account’s storage data
structure trie that records a contract’s state variables associated
to the corresponding piece of bytecode (i.e., not applicable to
EOA); (iv) codeHasℎ, which is the hash value of a contract
account’s bytecode (i.e., not applicable to EOA). The state of
a blockchain is defined by the states of the accounts on the
blockchain.
Smart contracts are building-blocks of decentralized appli-

cations (DApps) running on top of the Ethereum blockchain.
A DApp often has a user interface as its front-end and some
smart contracts as its back-end. At the moment of writing,
2,497 DApps are running on top of Ethereum, including
finance, governance, gambling, exchange, and wallet appli-
cations [26]. Some DApps issue their own cryptocurrency,
called tokens, for purposes like Initial Coin Offering (ICO)
and exchanges. A Ethereum-based token is a special kind of
smart contract (e.g., ERC-20 [27]).

Smart contracts execute in EVMs, which are quasi-Turing-
complete machines using a stack-based architecture; the term
“quasi” means that the execution is limited by the amount of
gas offered by the transaction in question [28].

2) The data layer: A transaction is an interaction between
an EOA (called sender) and anther EOA or contract account
(called recipient). A transaction is specified by: (i) nonce,
which is a counter for tracking the total number of transactions
that have been initiated by the sender; (ii) recipient, which
specifies a transaction’s destination EOA or contract account;
(iii) value, which is the amount of money (unit: Wei) to be
transferred from the sender to the recipient (if applicable);
(iv) input, which is the bytecode or data corresponding to the
purpose of the transaction; (v) gasP rice and gasLimit, which
respectively specify the unit price and the maximum amount
of gas the sender is willing to pay the winning miner of a block
containing the transaction; (vi) (v, r, s), which is the Elliptic
Curve Digital Signature Algorithm (ECDSA) signature of the
sender. The execution of a transaction updates the states of the
accounts involved and therefore the state of the blockchain.

Figure 2 depicts the lifecycle of a transaction. (i) A sender

constructs a transaction and digitally signs it. (ii) The sender
submits the signed transaction to an Ethereum client via a
JSON-RPC call. (iii) The client validates the received trans-
action and broadcasts it to the Ethereum P2P network. (iv)
Any client that receives the transaction and is a miner adds
the transaction to its transaction pool. (v) A miner executes
a sequence of transactions chosen from its transaction pool,
formulates a new block, and updates the state of the blockchain
as follows. For a money-transfer transaction, the speci-
fied value is transferred from the sender’s EOA to the recipi-
ent’s EOA or contract account; for a contract-creation
transaction where input is a piece of bytecode, a new contract
account is created and is associated with the bytecode; for a
contract-invocation transaction where recipient is a
callee contract and input uniquely identifies the callee func-
tion (and possibly some associated arguments), the bytecode
associated to the callee contract account is loaded into the
EVM. (vi) The miner solves a PoW by finding a random nonce
such that the hash value of the block metadata in question is
smaller than a certain threshold, which reflects the difficulty
of creating a block. Unlike Bitcoin’s computation-intense PoW
[1], Ethereum uses a memory-intense puzzle called “Ethash”
[5]. (vii) Upon creating a block, the miner broadcasts it to the
Ethereum P2P network so that other clients can validate the
block. (viii) Upon validating a block, the client in question
appends the block to the blockchain.
Trie [5] is the data structure for storing Ethereum blockchain

data (e.g., account states). Like a Patricia tree [29], a trie stores
(key, value) pairs while facilitating search as follows: the path
from the root to a leaf node corresponds to a key and the
leaf node contains a value (e.g., the state of an account). As
illustrated in Figure 3, a block header may point to a state
trie, a transaction trie (for bookkeeping transaction data), and
a receipt trie (for bookkeeping the data related to the execution
of transactions). Each contract account corresponding to a leaf
or branch node on the state trie uses a separate storage trie
to bookkeep the persistent data of the contract; this storage
trie also use a (key, value) structure, where the position of
each slot corresponds to a key and the contract’s state variable
in each slot corresponds to a value. Note that an Ethereum
blockchain has a single state trie because the state of the
blockchain dynamically evolves.
3) The consensus layer: At the moment of writing,

Ethereum takes about 14 seconds to create a block, meaning
that multiple miners could create valid blocks simultaneously
and that there could be many stale blocks. Ethereum uses
a variant of the GHOST consensus protocol [30] to select
the “heaviest” branch as the main chain where the “heaviest”
branch is the sub-tree rooted at the fork in question and has
the highest cumulative block difficulty [31], [32], while noting
that stale blocks are not on the main chain.
Ethereum rewards not only the regular blocks on the main

chain, but also the stale blocks referred by a regular block.
As illustrated in Figure 4, an uncle block is a stale block
referenced by a regular block called nephew (via a dashed
arrow). The distance between two blocks is their height
difference on the tree. The miner of a regular block receives
one unit of “static block reward,” which is worthy of 2 Ethers



5

Tx A
(v, r, s)sign

Ethereum 

Network

Tx A

private key

User Interface (i) – (ii)

Tx A

EOA

create
RPC

Tx A

Transaction Pool

…
block i block i+1

Tx B Tx C Tx D

Tx C 

Tx A 

Tx D

block header 

block body

Txs

block header 

block body

validate

…

…Ethereum 

Client

storage code

EVM

Account

balance

stack bytecode
argument

set

Tx
nonce

recipient

value

gasLimit

gasPrice

input

transfer

load

copy

fetch

memory

p
ic

k

Blockchain

Tx A Tx A

Tx A Tx A

Mining (iv, vi)

execute

Transaction Execution (v) 

PoW

access send

Tx A

Tx A

broadcast

(iii, vii,viii)

Fig. 2: An illustration of the lifecycle of an Ethereum transaction.

state trie

…

…

Root

node

Account

nonce

balance

storageRoot

codeHash

storage trie

…

…

Root

node

accountaddr1

accountaddrn

slot0 value

slotn value

Contract

address owner;

uint reward;

hash

represent

stateRoot receiptsRoottransactionsRoot …

… … … …

Transactions trie Receipts trie

Block
header

…

Fig. 3: Storage structure of Ethereum blockchain.

at the time of writing. In order to incentivize referencing to
uncle blocks, the miner of a nephew regular block further
receives 1∕32 of the static block reward for a reference (and
for up to 2 references). The miner of the referenced uncle
block is rewarded with 1 − d∕8 of the static block reward,
where 1 ≤ d ≤ 6 is the distance between the uncle block and
the referencing nephew block. Miners of regular blocks also
receive the gas fee specified by the transactions in question.

1a 2b 3b 4b 5a

+5/8

2c

2a 3a 4a

+7/8

+1+(1/32)

6b

+1 +1 +1 +1+1+(2/32)

+6/8

6a

7a

+1

Regular block

Stale & Uncle blockStale block 

Regular & Nephew block

hash reference

Fig. 4: A sub-tree of an Ethereum blockchain (adapted from
[33]), where a value beneath a node is the total award to the
miner of the node (unit: static block reward).

4) The network layer: The Ethereum network is a structured
P2P network where each node (i.e., client) stores a copy of the
entire blockchain. For node discovery and routing purposes,
each node maintains a dynamic routing table of 160 buckets
and each bucket contains up to 16 entries of other nodes’ IDs,

IP address, UDP/TCP ports. Ethereum uses the RLPx protocol
[34], [35] to discover target clients and uses the Ethereum Wire
Protocol [36] to facilitate the exchange of Ethereum blockchain
information (e.g., transactions, blocks) between clients.
5) The environment: The Ethereum blockchain runs in

an environment, which naturally operates across the 4-layers
to provide respective services, namely: a web interface for
users to interact with the Ethereum blockchain; a database for
Ethereum clients to store the blockchain data; cryptographic
mechanisms for security purposes; and the Internet infras-
tructure to support blockchain networking and communication
among Ethereum nodes. We separate the Ethereum blockchain
architecture from the environment because attacks against the
Ethereum blockchain may come from the environment and
these attacks may be better addressed in the environment
rather than by the Ethereum blockchain, leading to a clean
and modular abstraction.

B. Survey methodology

1) Scope: Since our focus is on Ethereum security, we will
systematize the vulnerabilities of, the attacks against, and the
defenses for Ethereum. Since these aspects are related to the
programming language for writing smart contracts and the
client software, we focus on the widely-used Solidity and Geth
[37] as well as Parity [38], respectively.
2) Methodology: Our methodology can be characterized

as follows. First, we use a layered architecture to present
the Ethereum ecosystem, from the application down to the
data, the consensus, the network, and the environment layers.
This layered view allows us to describe matters at the most
appropriate layer.
Second, we consider security from three perspectives (i.e.,

vulnerabilities, attacks, and defenses) as well as the relation-
ships between them. For each vulnerability, we discuss, among
other things, its root cause and status (i.e., eliminated, can be
eliminated by best practice, or still open). For each attack,
we discuss, among other things, its cause, tactic, and direct
impact. For each defense, we discuss its mechanism and the
(hidden) vulnerabilities it aims to protect from exploitation.
We aim to provide insights into the design and implementation
of Ethereum as well as future research directions in order to
address the range of open problems.



6

III. VULNERABILITIES
Figure 5 highlights our classification of Ethereum vul-

nerabilities based on their location, cause, and status (i.e.,
eliminated vs. can be avoided by best practice vs. open). For
ease of reference, we denote the 44 types of vulnerabilities
as 1,… ,44, respectively. In what follows, we group them
according to location.

A. Vulnerabilities at the application layer
1) Reentrancy (1): This vulnerability was first observed

from the DAO attack [39]; its variants were later reported
in [40]. The vulnerability occurs when an external callee
contract calls back to a function in the caller contract before
the execution of the caller contract is completed (i.e., cyclic
calls in a sense). This allows the attacker to bypass the due
validity check until the caller contract is drained of Ether or
the transaction runs out of gas. The vulnerability is caused by:
(i) a contract’s control-flow decision relies on some of its state
variable(s) that should be, but are not, updated by the contract
itself before calling another (i.e., an external) contract [40];
and (ii) there is no gas limit when handing the control-flow
to another contract. The vulnerability can be prevented by one
of the following methods [41]: (i) assuring that a contract’s
state variables are updated before calling another contract;
(ii) introducing a mutex lock on the contract state to assure
that only the lock owner can change the state; (iii) using the
transfer method to send money to other contracts because this
method only forwards 2,300 gas to the callee contract.

2) Delegatecall injection (2): This vulnerability was first
observed from an attack against the Parity wallet [42]. In
order to facilitate code-reuse, EVM provides an opcode, DEL-
EGATECALL, for embedding a callee contract’s bytecode into
the bytecode of the caller contract as if it’s a piece of the
latter’s bytecode [43]. As a consequence, a malicious callee
contract can directly modify (or manipulate) the state variables
of the caller contract. This vulnerability is caused by the ability
that the state variables of a caller contract can be updated by
the bytecode of a callee contract. The vulnerability can be
completely prevented by declaring a contract that is meant to
be shared via the delegatecall as a library, which is stateless
[44].

3) Frozen Ether (3): This vulnerability was first observed
from another attack against the Parity wallet [45]. The vul-
nerability results from the ability of users to deposit their
money to their contract accounts with the inability to spend
their money from those accounts, effectively freezing their
money. The vulnerability is caused by [46]: (i) contracts not
providing any function for spending money relying on the
money-spending function of another contract (as a library)
and (ii) the callee contract (i.e., the library) being killed
accidentally or deliberately. The vulnerability can be prevented
by assuring that mission-critical functions, or money-spending
functions in this case, are not outsourced to another contract.

4) Upgradable contract (4): This vulnerability was first
discussed in [12]. The idea of contract upgrading was in-
troduced to mitigate the problem that smart contracts, once
deployed, cannot be modified even if they are later found to

have vulnerabilities. In order to allow contract upgrading, there
are two approaches: (i) splitting a contract into a proxy contract
and a logic contract such that developers can upgrade the
latter but not the former; and (ii) using a registry contract
to bookkeep the updated contracts. While effective, these
approaches introduce a new vulnerability: when the contract
developer is malicious, the updated (logic) contract can be
malicious. The vulnerability is caused by one contract being
able to call another contract, which can be malicious. This
vulnerability (i.e., unsecure contact updating) remains to be
an open problem.
5) DoS with unexpected revert (5): This vulnerability was

first reported in [41]. It occurs either when a transaction is
reverted due to a caller contract encountering a failure in
an external call, or the callee contract deliberately performs
the revert operation to disrupt the execution of the caller
contract. This vulnerability is caused by the execution of
a caller contract being reverted by a callee contract. This
vulnerability can be prevented by letting a recipient invoke
a transaction to “pull” ";"""date"",""2019-08-14T00:23:29Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2019-08-14T00:23:29Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016) kpathsea version 6.2.2""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2019-08-14T00:23:29Z""
""created"",""2019-08-14T00:23:29Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-08-14T00:23:29Z""
""resourceName"",""1908.04507""
""Author"",""""
""producer"",""pdfTeX-1.40.17""
""pdf:docinfo:producer"",""pdfTeX-1.40.17""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""5"",""0"",""129"",""2"",""0"",""0"",""0"",""0"",""5"",""15"",""0"",""8"",""0"",""0"",""0"",""0"",""4"",""0"",""0"",""0"",""1"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2019-08-14T00:23:29Z""
""Last-Modified"",""2019-08-14T00:23:29Z""
""dcterms:modified"",""2019-08-14T00:23:29Z""
""title"",""""
""Last-Save-Date"",""2019-08-14T00:23:29Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2019-08-14T00:23:29Z""
""meta:save-date"",""2019-08-14T00:23:29Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016) kpathsea version 6.2.2""
""Content-Length"",""1144185""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""29""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""5078"",""5136"",""4139"",""5497"",""3725"",""5618"",""3475"",""5857"",""5439"",""5491"",""5459"",""5480"",""5370"",""4783"",""4853"",""4645"",""5549"",""5679"",""4039"",""5171"",""5767"",""5570"",""5180"",""4610"",""2547"",""7620"",""7810"",""7538"",""2330""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-08-14T00:23:29Z""
";https://scholar.google.ch/scholar?start=610&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098861-325;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;New techniques in replica encodings with client setup;R Garg, G Lu, B Waters ; Theory of Cryptography Conference, 2020  Springer;;"… Damgĺrd, Ganesh, and Orlandi (CRYPTO' 19) [11] proposed a novel notion that we will call proof …

i \in [n]\). The attacker \(\mathcal {A} _1\) receives the encodings, makes some more oracles

queries before … whose job it is to output the encodings using the state plus oracle queries …";Cité 1 fois;Les 2 versions;[PDF] iacr.org;https://eprint.iacr.org/2020/617.pdf;"
New Techniques in Replica Encodings with Client Setup

Rachit Garg∗ George Lu† Brent Waters‡

September 21, 2020

Abstract

A proof of replication system is a cryptographic primitive that allows a server (or group of servers)
to prove to a client that it is dedicated to storing multiple copies or replicas of a file. Until recently, all
such protocols required fine-grained timing assumptions on the amount of time it takes for a server to
produce such replicas.

Damg̊ard, Ganesh, and Orlandi (CRYPTO’ 19) [11] proposed a novel notion that we will call proof
of replication with client setup. Here, a client first operates with secret coins to generate the replicas
for a file. Such systems do not inherently have to require fine-grained timing assumptions. At the
core of their solution to building proofs of replication with client setup is an abstraction called replica
encodings. Briefly, these comprise a private coin scheme where a client algorithm given a file m can
produce an encoding σ. The encodings have the property that, given any encoding σ, one can decode
and retrieve the original file m. Secondly, if a server has significantly less than n ¡ |m| bit of storage, it
cannot reproduce n encodings. The authors give a construction of encodings from ideal permutations
and trapdoor functions.

In this work, we make three central contributions.

• Our first contribution is that we discover and demonstrate that the security argument put forth by
[11] is fundamentally flawed. Briefly, the security argument makes assumptions on the attacker’s
storage behavior that does not capture general attacker strategies. We demonstrate this issue
by constructing a trapdoor permutation which is secure assuming indistinguishability obfuscation,
serves as a counterexample to their claim (for the parameterization stated).

• In our second contribution we show that the DGO construction is actually secure in the ideal
permutation model (or ideal cipher model) and the random oracle (or random function) model
from any trapdoor permutation when parameterized correctly. In particular, when the number of
rounds in the construction is equal to Ν ¡ n ¡ b where Ν is the security parameter, n is the number
of replicas and b is the number of blocks. To do so we build up a proof approach from the ground
up that accounts for general attacker storage behavior where we create an analysis technique that
we call “sequence-then-switch”.

• Finally, we show a new construction that is provably secure in the random oracle model. Thus
requiring less structure on the ideal function.

1 Introduction

In a proof of replication system [6, 5] , a user wants to distribute a file m and ensure that a server or group
of servers will dedicate the resources to storing multiple copies or replicas of it. That is, the server should
either receive or generate n replicas σ1, . . . , σn where the file m can be efficiently decoded from any single
replica. In the original notion of proofs of replication, a server could take a file m as input and independently

∗University of Texas at Austin. Email: rachit0596@gmail.com. Supported by NSF CNS-1908611, CNS-1414082, Packard
Foundation Fellowship, and Simons Investigator Award.
†University of Texas at Austin. Email: gclu@cs.utexas.edu. Supported by NSF CNS-1908611, CNS-1414082, Packard

Foundation Fellowship, and Simons Investigator Award.
‡University of Texas at Austin and NTT Research. Email: bwaters@cs.utexas.edu.

1



generate all the replicas σ1, . . . , σn. Later it could prove possession if challenged. Since the introduction of
this concept, several such solutions [24, 7, 17, 9, 16] have emerged.

However, in these solutions, there exist a tension that stems from the following attack. Consider a non-
compliant server that stores just a single copy of m. When challenged to prove possession of replicas, it
on the fly, generates σ1, . . . , σn using the legitimate generation algorithm and proceeds to prove replication
using the ephemeral values as though it were storing these replicas all along.

It is easy to see that achieving meaningful security against such an attack is impossible without imposing
a concrete time-bound between when a server is challenged and when it must answer. The setting of this
time-bound must be coupled with an understanding of how long it takes an honest system to retrieve the
replicas and produce a proof and balanced against how fast a highly provisioned server might take to produce
the replicas from scratch. This balancing act creates a certain tension in that more costly replica generation
will help security, but also imposes a higher burden on initiation. Moreover, other issues can arise in the
context of a more extensive system. For example, if audit challenges come out at a predictable time (e.g.,
daily), then a cheating server could start generating the response ahead of time.

To address these issues, Damg̊ard, Ganesh, and Orlandi [11] proposed a novel notion that we will call
proof of replication with client setup. In this notion, a client that wishes to store a file m will generate
replicas σ1, . . . , σn, along with a (short) public verification key vk. The system will have the properties that
(1) one can reconstruct the file from any replica along with the verification key, and (2) a server can prove
possession of the replicas to any client that holds the verification key. Unlike the previous systems, proof of
replication with client setup need not require fine-grained timing assumptions as a server will not be able
to regenerate the replicas from only the message m and vk. Indeed the security definition says (informally)
that any poly-time server that devotes significantly fewer resources than n times message length will not be
able to pass the possession test.

The solution proposed in [11] combines two high-level ingredients. The first is a proof of retrievability
system as proposed in prior work [27, 12, 8]. Roughly, if a server executes a proof of retrievability for
data d with a client, this means that now, the server was capable of reconstructing d. However, a proof of
retrievability in and of itself gives no guarantee about the amount of resources required to store d.

Second, the authors introduce a notion of a replica encoding. A replica encoding system consists of three
algorithms: (rSetup, rEnc, rDec). The setup algorithm on input, a security parameter Îş and the maximum
number of replicas n of a scheme, outputs a public and secret key pair as (pk, sk) ← rSetup(1κ, 1n). The
encoding algorithm takes as input the secret key and a message m to produce an encoding as y ← rEnc(sk,m).
Finally, the decoding algorithm takes as input an encoding y and the public key to retrieve the message
as m ← rDec(pk, y) or outputs ⊥ to indicate failure. The algorithms are randomized, and the encoding
procedure can be run multiple times to produce multiple encodings. The correctness of the scheme dictates
that if one encodes any message m under a secret key and then decodes it under the corresponding public
key, m will be decoded.

To capture security, we will consider a soundness game which uses a two-stage attacker (A1,A2). In the
first stage, A1 will be given a challenger-generated public key pk and reply with a message m. It is then given
n encodings generated by the challenger as y1, . . . , yn. The attacker outputs a state variable state, which
we will generally think of as being smaller than |m| ¡ n. At the second phase, the algorithm A2 is given the
input state and is tasked with outputting guesses ỹ1, . . . , ỹn. The security property intuitively states that if
the size of the storage |state| is significantly less than v ¡ |m|, then the number of i where yi = ỹi will be less
than v. That is, the attacker cannot do much better than simply storing a set of values yi.

Damg̊ard, Ganesh, and Orlandi showed how a natural compilation of existing proof of retrievability
schemes along with replica encodings gave way to proofs of storage with client setup. Also, they provided a
candidate construction for replica encodings from trapdoor permutations under the ideal cipher model and
the random oracle model. We turn our attention to these.

The DGO construction: We now outline (a slight variant of the) construction for [11], which is given
in the ideal permutation and the random oracle model. We remark that the DGO construction itself is an
adaptation of one of the “hourglass” schemes of van Dijk et al. [28]. The building blocks will consists of a
trapdoor permutation f, f−1, along with the ideal cipher T,T−1, and a random oracle H. We again let κ be

2



the security parameter and let Îť = Îť(Îş) be the output length of the trapdoor permutation as well as the
block length of an ideal permutation T : {0, 1}λ → {0, 1}λ. For pedagogical purposes, we will assume for
the sketch below that messages consist of Îť bits, but in our main body, we consider the more realistic case
of many block messages.

The setup algorithm simply chooses a TDP public/secret key pair as KeyGen(1Îş) outputs (pk, sk) where
KeyGen is the trapdoor permutation key generation algorithm. The public and secret key pair of the TDP
serve as the keypair of the replicated encoding scheme.

The encoding algorithm rEnc(sk,m) takes as input the TDP secret key and message m. It first chooses

a string ρ
R←− {0, 1}κ. It then initializes a value Y0 = m ⊕ H(ρ) where H is modeled as a random oracle

function. Then for j = 1 to r rounds it computes Yj = f−1(sk,T(Yj−1)) where r is the number of rounds,
which grows linearly with the number of replicas. The encoding is output as (Yr, ρ).

Finally, the decoding algorithm rDec(pk, y = (Yr, ρ)) recovers a message as follows. For setting j from
r − 1 down to 0 compute Yj = T−1(f(pk, Yj+1)). Then output m = Y0 ⊕ H(ρ).

The fact that the decoding step recovers the message follows straightforwardly from the correctness of
the trapdoor permutation and ideal permutation. We also observe that it is publicly computable since it
uses the public key and forward direction of the trapdoor permutation.

1.1 Our Contributions

We make three core contributions to this area:

1. Our first contribution is that we discover and demonstrate that the security argument put forth by [11] is
fundamentally flawed. The security argument makes implicit assumptions about an attacker’s behavior
which are not generally true. More specifically, in the security game applied to the DGO construction
(in the ideal permutation and random oracle model) an attacker works in two phases. The first stage
attacker A1 receives the replicas, can make several queries to the ideal permutation and then records
some state state of limited size. This state state is passed to a stage two attacker A2 which can
make further permutation queries and attempts to reconstruct the queries. In general a first stage
attacker can apply arbitrary strategies to breaking the scheme so long as it poly-time and state state
is sufficiently small. However, the proof argument of [11] assume that the ideal permutation queries
made by the attacker will be “uniquely stored”. Roughly, they will argue that a query output bit will
either be stored explicitly or not at all. This discounts the possibility of an attacker strategy such as
making several oracle queries and storing the XOR of all the outputs together.

We demonstrate that the above error manifests in a false theorem statement in [11]. The authors claim
that the scheme is secure for any trapdoor permutation (TDP) if r = Ν ¡ n rounds are applied when
doing n encodings of b blocks with security parameter Îť . (I.e. Claim the number of rounds does not
need to scale with b.) We provide an explicit counterexample to this claim in Section 7. We give a
TDP that is secure assuming indistinguishability obfuscation, but for which the scheme is attackable
using these parameters. The attacker strategy actually works by XORing several query values together
and is thus directly tied to the flaw in the security proof. There does not appear to be any simple
“fix” to the security argument of [11] as we will see that addressing general attacker storage strategies
comprises the core difficulty of proving security.

We also note that an explicit “partitioning assumption” appears in the security definition of [28] for
“hourglass schemes” where the authors conjecture (but do not prove) that it seems implausible that
mixing together two representations can give an advantage to an attacker. Although we do not do so
formally, we believe that our counterexample can be adapted to the work of [28] as well (at least if
one considered the scheme for general trapdoor permutations) and demonstrates the danger of making
assumptions that restrict adversarial strategies.

2. For our second contribution we show that the DGO construction is actually secure when parameterized
correctly. In particular, when the number of rounds is equal to Ν ¡n ¡ b. To do so we need to build up a
proof approach from the ground up that accounts for general attacker storage behavior. We first develop

3



an analysis technique that we call “sequence-then-switch”. We show how in this framework, we can
prove security against an attacker that arbitrarily assigns state. In particular, we show how to analyze
the security of a close variant of the [11] construction in the ideal permutation and random oracle model.
In addition, we give an explicit construction of a trapdoor permutation using indistinguishability
obfuscation which allows for an attack strategy not covered by their restricted model, showing the [11]
construction as given is in fact explicitly insecure against general adversaries.

3. The prior construction and proof relies on the ideal permutation model. A perhaps better goal would
be to have a construction secure in the random oracle or random function model as this assumes less
structure on the ideal object. Typically, this is dealt with by building a random permutation from
a function using a Feistel network and showing that this is “indifferentiable” in the indifferentiability
framework of Mauer et al. [21]. Prior works have shown this for 14 [19] and then 8 round Feistel [10].
However, Ristenpart, Shacham, and Shrimpton [26] show that the framework does not compose for
multi-round games. Since the above construction relies on a multi-round game, proof from an ideal
permutation cannot be reduced to a proof to an ideal function.

We give a new construction that relies only on the ideal function model and analyze its security.
Our construction uses the random function to embed a Feistel like structure into the construction.
However, instead of arguing in the indifferentiablity framework, we provide direct proof of security,
which bypasses any composability issues. In both proofs, we allow the attacker to assign its storage
arbitrarily.

1.2 Our Techniques

We begin by describing our analysis for the first construction using a TDP and ideal permutation. We
focus on the construction producing many replicas on a single block, as described in the introduction for
simplicity. Also, for simplicity, we consider the particular case where an attacker that asks for n replicas in
the first stage and wants to produce all n of these replicas, but we significantly less than n ¡ Ν storage. In
particular consider an adversary with state of length n ·λ−n ·ω(log κ) bits of storage for security parameter
Îş and block length Îť. Our central idea is to organize the proof into two parts where we first show that any
storage bounded A2 must make “sequential” oracle queries on at least one replica. Then we show that on
this particular replica, how one can swap out permutation output for another.

1. Sequentiality: In our security game, the challenger first creates n replicas of m. To create the i-th

replica by choosing ρi randomly. It sets Y
(i)
0 = m ⊕ H(ρi). Then for j = 1 to r rounds it computes

Y
(i)
j = f−1(sk,T(Y

(i)
j−1)). The encoding is output to A1 as (Y

(i)
r , ρi) for i ∈ [n]. The attacker A1 receives

the encodings, makes some more oracles queries before producing state of n · λ− n · ω(log κ) bits and
passing it to A2.

Let’s examine the behavior of A2 whose job it is to output the encodings using the state plus oracle
queries. We say that A2 “queries sequentially” on replica i if for all j ∈ [0, r − 1] it queries the oracle

T on Y
(i)
j before it queries the oracle on Y

(i)
j+1. (We will think of outputting the encoding Y

(i)
r at the

end as implicitly querying on the final value.) That is for A2 to query sequentially on replica i it must
both make all r + 1 oracle queries and make them in (relative) order. However, there could be many

other queries outside the replica chain interspersed between Y
(i)
j and Y

(i)
j+1.

We will first argue that except with negligible probability whenever A2 produces all the encodings,
it queries sequentially on at least one replica. Observe that we cannot hope to say that it queried
sequentially on all replicas as state could directly store several of the replica encodings, which allows
the algorithm to bypass any additional queries related to that replica.

To prove this, we first define and prove a useful matching pairs lemma. Consider an algorithm B that
takes as input a string advice of length n · λ − n · ω(log κ) and gets access to a string oracle access
to a randomly chosen permutation T(·),T−1 of block length λ. The goal of B is to provide n distinct
pairs (xi, yi) such that T(xi) = yi, but without querying the oracle a either xi nor yi. Thus B can

4



make several oracle queries on many values; however, once a query is made on some x, it spoils using
x as a value from one of the pairs. Note that to win in this game, B needs to produce the pairs— not
just distinguish them from random. Also observe that B can use advice to help it win this game. For
example, advice might encode the several pairs.

We prove that no attacker B that makes a polynomially bounded number of queries can win in this
game by a simple application of the union bound. Consider a fixed value of an advice string a — that
is a is fixed before the permutation is chosen. We show that the probability of B(a) winning is at most
poly(Îť)
2nÎť

. Then by the union bound the probability that there exists any string a which it could win with

is at most 2n·λ−n·ω(log κ) · poly(λ)
2nÎť

which is negligible in Îť.

Now we need to show that an attacker that wins but is not sequentially querying on any replica will
break our matching pairs game. We consider (A1,A2) that does this. Let’s think of the algorithm
pair as deterministic. (If they are randomized for each security parameter, we can fix their coins that
maximize success probability.) We construct an algorithm B along with the process of determining an
advice string that does this. Conceptually we can think of a preprocessing algorithm B′ that generates
the advice. B′ will first run A1, which makes several queries and then produce state. It then runs A2

on state. If A2 either did not produce all the replica encodings or it did sequentially query on some
replica i, then abort. However, if it did not make sequential queries on all replicas, then there must be

values j1, . . . , jn where A2 made an oracle query on Y
(i)
ji

(or f(pk, Y
(i)
ji

)), but had not yet made a query

on Y
(i)
ji−1. Let q1, . . . , qn be the indices of the queries (ordered chronologically) for which this occurs.

Note the number of queries A2 can make is polynomial in Îş, but in general, it could be much more
than r ¡ n ¡ Ν. The preprocessing algorithm will package its advice string as state along with j1, . . . , jn
and q1, . . . , qn. Importantly, the size of this information is bounded by lg(poly(Îş)) for some polynomial
poly since n, r, and the number of replicas is polynomially bounded. This means that if state is of size
n · λ− n · ω(log κ), then the advice string will be within n · λ− ω(log κ).

We now consider algorithm B, which receives the advice string. B will run A2 with the following
modifications. Suppose A2 makes its q-th query where q = qi for some i. This means that A2 is

querying on Y
(i)
ji

, but had not yet made a query on Y
(i)
ji−1. At this point B determines Y

(i)
ji−1 by

querying Y
(i)
1 = f−1(sk,T(Y

(i)
0 )) up to Y

(i)
ji−1 = f−1(sk,T(Y

(i)
ji−2)). It then submits (Y

(i)
ji−1, f(pk, Y

(i)
ji

)) as

one of its matching pairs noting that neither T(Y
(i)
ji−1) nor T−1(f(pk, Y

(i)
ji

)) were made before. It can
also continue to run A2 without making either of these queries to the oracles since it already knows
the answers to them. As this process proceeds, B will eventually recover n such pairs which breaks our
matching pairs lemma and arrives at a contradiction.

2. Switching:

Once sequentiality is established, we will proceed to argue that the adversary must still be sequential

with good probability even when we “switch” the random oracle output of some Y
(Îł)
j to a random

value only for A2, allowing us to embed a trapdoor permutation challenge.

In more detail, we now consider a new switched game that is almost equivalent to the prior one. In
the switched game the challenger first chooses r random values Ai,b ∈ {0, 1}Ν for j ∈ [1, r], b ∈ {0, 1}
along with a bit string x ∈ {0, 1}. It programs the oracle T such that Y

(Îł)
j = Ai,b. This game can be

shown to be almost equivalent to the previous one.

Next, we consider a game where the challenger answers queries according to a string x with A1,
but switches to using a string x′ (and keeps everything else the same) when responding to A2. The
challenger chooses the string x′ such that the output state given by A1 is the same as if the queries are
answered according to x′ in the first phase. The attacker is considered to win only if it would produce
sequential queries both for when x was used with A2 and when x′ was used with A2.

With high probability, such an x′ will exist from the fact that |state| ≤ n · λ− ω(log κ) and r is set to
be n ¡ Ν. We emphasize that to make this argument we do not make any further assumptions on how

5



A1 assigns state other than the bound on the size. We can then use the heavy row lemma [23] to argue
that if an attacker wins with probability ε in the previous game, it wins with probability ≈ ε in this
game. We note that the game takes exponential time to find such an x′, but this is not an issue as the
closeness lemma is information-theoretic.

Finally, in order to embed a TDP challenge, we need to move to a security game that can be efficiently
simulated. While it might take exponential time to find x′ from x above, we observe that this is not
necessary. Instead, we can embed the challenge from just knowing the shortest common prefix of x and
x′. Moreover, given x, we can simply guess what the prefix is with a 1

r loss. Thus we move to a final
game where the challenger simply chooses a random value j and a random permutation T in the first

phase and then replaces the oracle output of Y
(i)
j with a random R in the second phase. The attacker

wins if it queries f−1(sk, R). A simple reduction then shows that any attacker that wins in this game
breaks the TDP security.

1.2.1 Extending to the ideal function model

We can now return to our goal of building a secure construction by replacing the ideal permutation model
with a random oracle model. As argued earlier, doing so is desirable as an ideal function imposes less
structure and appears to be a less risky heuristic. Our solution will build upon the analysis principles
established above, but proving security involves more complications.

We begin by sketching out the encoding construction. In this setting, we will have a TDP in the domain
λ bits and use a random oracle T′ that outputs λ bits. We will use blocks of length 2λ, and for this sketch,
focus on the particular case where each replica consists of a single block message.

The setup algorithm again chooses a TDP public/secret key pair as KeyGen(1κ) → (pk, sk) as before.
The encoding algorithm rEnc(sk,m) takes as input the TDP secret key and message m ∈ {0, 1}2Ν. It first

chooses a string ρ
R←− {0, 1}κ. It then initializes values Y0 = L(m⊕H(ρ)) and Y1 = R(m⊕H(ρ)) where H is

a random oracle that produces an 2Îť bit output and L,R are functions that take the left and right halves.
Then on rounds j from 2 to r compute Yj from Yj−1 and Yj−2 as

Yj = f−1(sk, Yj−2 ⊕ T′(Yj−1)).

The replica encoding value is 2λ bits long and consists of the last two values as Yr−1||Yr. The decoding
algorithm rDec works backward down the Feistel structure to recover the message.

In this setting, we want to prove that in the security game, an attacker with n · 2λ− n · ω(log κ) cannot
produce n replica encodings. (The extra factor of two is solely due to blocks being 2Îť bits here.)

Our proof will follow in the same theme of showing that there must be a form of sequential querying made
on at least one replica. However, the new structure of the construction presents additional complications.
For example, we could imagine an attacker A1, which stores all the values Y ij for some j. This is possible
since storing these only take nÎť bits, and our assumption is only that the storage is less than 2nÎť bits.
On the one hand, it is unclear how the attacker can leverage storing all these values because one needs

consecutive values (e.g., Y
(i)
j , Y

(i)
j+1) to propagate further. And, storing n different consecutive pairs requires

2nÎť bits of storage. On the other hand, the attacker can store these means at the very least we need a new
notion of sequentiality.

For our new notion of sequentiality, we say that the queries to replica i meet our requirements if the

longest common subsequence of the queries made and Y
(i)
1 , Y

(i)
2 , . . . , Y

(i)
r is of length at least r−3. Intuitively,

this is close to our original notion but allows for a little skipping. To prove this form of sequentiality, we
invoke a random function analog of our matching pairs lemma from before. The reduction to matching pairs
follows in a similar spirit to before but requires a more nuanced case analysis.

Once that is in place, our proof proceeds analogously, but again with more nuances and complications
arising from the fact that we only can guarantee the weaker form of longest common subsequence.

1.2.2 The proposed construction is round optimal

We now consider the general case of a message having b blocks and give intuition that our construction is
round optimal up to constant factors. We construct a secure trapdoor permutation scheme from indistin-

6



guishability obfuscation which gives an insecure replica encoding scheme for any number of rounds /∈ Ω(b ·n)
(i.e. ∈ o(b ¡ n)). Incidentally, this also shows that the construction provided by [11], which claims to only
requires O(n) rounds, is insecure against general adversaries.

We provide the intuition for our construction by considering the ideal VBB notion of obfuscation. The
overall idea is to construct a trapdoor permutation family where we can amortize the ‘state’ space required
to invert multiple independent instances. We will consider our permutations to be on domain {0, 1}Îť. If we
assume we have VBB obfuscation, then consider a program that takes in b many inputs {yi}i∈b where yi ∈
{0, 1}λ and an advice string also in {0, 1}λ and outputs the preimages of the messages {xi = f−1(sk, yi)}i∈b
iff the advice string that was input was equal to

⊕
i∈b xi. The program has the secret key hardcorded and

simply computes xi and makes the check against the advice string and outputs {xi}i∈b if the check succeeds.
The VBB obfuscation of this program is then posted in the public parameters and provides a way for the
adversary to compress b ¡ Ν bits to Ν bits and still preserve information. Thus an adversary with outputting
r ¡ Ν bits can recompute the replica from storing o(b ¡ nΝ) information. This would violate the security if we
proved soundness for the same parameters as our scheme. A formal treatment is presented in Section 7.

1.3 Additional Prior Work

Proofs of Retrievability:
Proofs of retrievability guarantee to a verifier that a server is storing all of client’s data. The notion

was formalized in [20], where, in an audit protocol the verifier stores a (short) verification key locally and
interacts with the server to enforce accountability of the storage provider. If the server can pass an audit,
then there exists an extractor algorithm, that must be able to extract the file on interaction with the server.
There are different constructions for this primitive, [12, 27, 8]. The construction of [27] showed how to do
this in the random oracle model that allow public verifiability.

Proofs of Space: Proof of space are interactive protocols between a prover (server) and a verifier (client)
that guarantee that a prover has dedicated a specific amount of space. It guarantees that it would be more
expensive for a dishonest prover to deviate from the honest protocol. They were introduced in [14] and
have been further studied in [25, 1]. Compared to a proof of replicated storage, they have an additional
requirement of communication being succinct between a prover and verifier and are usually studied in the
public-key setting.

Other examples of works which are different from proofs of space but enforce storage requirements similar
to our soundness game on the prover are storage-enforcing commitments [18], hourglass scheme [28] and the
model of computation considered by [15].

Proofs of Replicated Storage:
The formal treatment of proofs of replicated storage was given by [11, 16, 9]. The idea was introduced

in [6, 5] where they proposed Filecoin, a decentralized storage network that performs consensus using proofs
of replication. Recently, [24, 17, 7, 9, 16] have given constructions for proof of replication using timing
assumptions (encoding process is much slower so that a server cannot replicate data on demand). On the
other hand, the scheme of [11] is not based on timing assumptions and considers the protocol with a client
setup. They introduce the notion of a replica encoding that can be combined with a public verifiable proof
of retrievability [27] to give a proof of replicated storage. Please see [11] for other related works such as proof
of data replication.

Hourglass Scheme:
Our constructions and the construction from [11] are reminiscent of the hourglass scheme of [28]. Our

construction in the ideal permutation model differs from the RSA based hourglass function of [28] in explicitly
ensuring that the encoding blocks are uniformly distributed by applying a random oracle H and increasing
the number of rounds suggested by their scheme. Because of our explicit encoding function, we do not need
to make a partitioning assumption in our security proof. The brief analysis of their scheme gives a similar
intuition to the security as used by [11] and gives a construction for the number of rounds independent of
the number of blocks. But as we see in Section 7, this intuition does not hold true for general adversaries.

7



Technique Similarities in literature:
Some of our techniques have a flavor that appears in the the study of pebbling strategies on random

oracle graphs and the memory hardness literature [15, 13, 3, 2, 4]. Pebbling strategies on random oracle
graphs look at the amount of resources (the list of random-oracle calls) made by the adversary and help in
proving complexity lower-bounds on the resources. Our notion of “sequentiality” is similar to the notion of
a legal “ex-post-facto pebbling” on a directed acyclic graph (see [4] for details). The reductions there are
proven using a core lemma which looks at a legal ex-post-facto pebbling given hints; Lemma 1 of [4, 15, 13]
which is similar to our core lemmas for proving sequentiality Lemma 1, Lemma 2. Interestingly, [2] considered
adversaries that can store secret shares of the random oracle queries (such as a xor) and introduced the notion
of an entangled pebbling game. They look at the resource of “Cumulative Memory Complexity (CMC)” and
constructed an example to show that such strategies can help the adversary reduce it’s resource requirement.
The followup work of [3] improved on their lower bounds results for any general adversarial strategy.

1.4 Concurrent Work

After completing ou";"""date"",""2020-09-21T23:06:24Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2020-09-21T23:06:24Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.20 (TeX Live 2019) kpathsea version 6.3.1""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2020-09-21T23:06:24Z""
""created"",""2020-09-21T23:06:24Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-09-21T23:06:24Z""
""resourceName"",""617.pdf""
""Author"",""""
""producer"",""pdfTeX-1.40.20""
""pdf:docinfo:producer"",""pdfTeX-1.40.20""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""7"",""7"",""1"",""0"",""10"",""3"",""7"",""20"",""3"",""9"",""10"",""10"",""12"",""14"",""26"",""35"",""3"",""9"",""25"",""21"",""37"",""40"",""14"",""8"",""26"",""13"",""25"",""32"",""53"",""10"",""24"",""42"",""53"",""44"",""34"",""17"",""15"",""14"",""43"",""10"",""22"",""13"",""29"",""27"",""14"",""2"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2020-09-21T23:06:24Z""
""Last-Modified"",""2020-09-21T23:06:24Z""
""dcterms:modified"",""2020-09-21T23:06:24Z""
""title"",""""
""Last-Save-Date"",""2020-09-21T23:06:24Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2020-09-21T23:06:24Z""
""meta:save-date"",""2020-09-21T23:06:24Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.20 (TeX Live 2019) kpathsea version 6.3.1""
""Content-Length"",""664194""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""52""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""2878"",""4252"",""3672"",""3665"",""3616"",""3644"",""3733"",""3518"",""2255"",""3103"",""2370"",""1820"",""1221"",""1750"",""1491"",""2472"",""2031"",""2451"",""1691"",""1722"",""2137"",""1970"",""2374"",""2030"",""1799"",""2093"",""1959"",""1652"",""2093"",""2480"",""2302"",""1983"",""1749"",""2281"",""3029"",""2050"",""2739"",""2343"",""1549"",""1688"",""2386"",""1186"",""1520"",""1193"",""1098"",""2380"",""2442"",""1828"",""2005"",""2508"",""2998"",""231""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-09-21T23:06:24Z""
";https://scholar.google.ch/scholar?start=870&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098839-274;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;[HTML][HTML] How to Tell When a Digital Technology Is Not Ready for You;J Crowcroft ; Patterns, 2020  Elsevier;;"… built on the blockchain, but you can have a blockchain without a cryptocurrency, and you … Finally,

a blockchain can implement smart contracts, ie, the ability to trigger small programs … For reference

and comparison, Oracle Database servers can handle millions of transactions per …";Autres articles;;[HTML] sciencedirect.com;https://www.sciencedirect.com/science/article/pii/S2666389920300015;;;https://scholar.google.ch/scholar?start=820&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098822-234;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;[PDF][PDF] IMPROVING PRIVACY AND SECURITY OF CLOUD DATA USING DIVISION AND REPLICATION OF DATA;P RAVALI, V SARALA, K RAMBABU ; shabdbooks.com;;"… 440-456. [5]X. Boyen, B. Waters, “Anonymous hierarchical identity-based encryption(without

random oracles),”inProc.CRYPTO, Santa Barbara, California, USA, August.2006, pp. 290-307.

Mukt Shabd Journal Volume IX, Issue IV, APRIL/2020 ISSN NO : 2347-3150 …";Autres articles;Version HTML;[PDF] shabdbooks.com;http://shabdbooks.com/gallery/493-april2020.pdf;"
IMPROVING PRIVACY AND SECURITY OF CLOUD 

DATA USING DIVISION AND REPLICATION OF DATA 

 

PALA RAVALI #1, V.SARALA#2, K.RAMBABU  #3 
 

#1
 MCA  Student, Master of  Computer Applications, 

D.N.R. College, P.G.Courses & Research Center, Bhimavaram, AP, India. 
 

#2
 Assistant Professor, Master of  Computer Applications,

 

D.N.R. College, P.G.Courses & Research Center, Bhimavaram, AP, India. 
 

#3
 Head & Assistant Professor, Master of  Computer Applications, 

D.N.R. College, P.G.Courses & Research Center, Bhimavaram, AP, India. 
 

 
ABSTRACT  

 

 As we as a whole realize that all the delicate information originate from far off areas will 

be put away in the brought together capacity medium and afterward attempt to get to the 

information from that incorporated extra room constrained by the cloud worker. It is confronting 

an issue like there is no security for the information regarding client approval and information 

verification from the unified stockpiling area. Henceforth we have to move for another capacity 

methodology like De-Centralized capacity of cloud information in which the frameworks that 

don't depend on a focal position, so we can ready to stay away from the conspiracy opposition by 

keeping up a Global Identifier. Here the term de-incorporated access implies conceding multi 

specialists to control the entrance for giving greater security to the touchy information. In this 

proposed proposition we attempt to build up another plan by including a worldwide identifier 

like Attribute Authority (AA) for giving access keys to the information clients who wish to get to 

the delicate data from the cloud worker. In this proposed work we attempt to utilize Composite 

Order Bilinear Groups plot for giving access office to the information clients and give greater 

security to the touchy information. By directing different analyses on our proposed model, our 

outcome unmistakably tells that our proposed framework is proficient to get to the information in 

a de-unified way by utilizing a worldwide identifier. 

 

Key Words: Centralized Storage, Authorization, Migrate, Composite Order Bilinear Groups 

Mukt Shabd Journal

Volume IX, Issue IV, APRIL/2020

ISSN NO : 2347-3150

Page No : 4776



  

I. INTRODUCTION 
 

 Cloud computing enables users to store their sensitive data into un trusted remotely cloud 

service providers to achieve scalable services on-demand. Prominent security requirements 

arising from this means of data storage and management include data security and privacy and 

require the use of strong encryption techniques with fine-grained access control for data security 

in cloud computing. Attribute-based Encryption (ABE) is an efficient encryption system with 

fine-grained access control for encrypting out-sourced data in cloud computing. With the 

emergence of sharing confidential corporate data on cloud servers, data are generated by several 

organizations, and access policies can be defined by several authorities. Single-authority ABE 

cannot meet the demands of decentralized distribution, and decentralizing multi-authority ABE 

have been proposed to solve those problems. 

 

           For basic Identity-based encryption (IBE) and ABE, all private keys are managed by an 

authorized centre. However, in practice, this will present a performance bottle-neck requiring 

evaluation due to the huge numbers of requests. In addition, concentrated attacks seem to be 

more easily from happening. Therefore, Hierarchical IBE (HIBE) [1-7] and Hierarchical ABE 

(HABE) [8-11] are now being used. HIBE and HABE are also called levelled multi-authority 

IBE and ABE. According to the main concept, the authorized centre is managed at different 

levels, and domains or users at higher levels can use their private keys to generate private keys 

for the domain or users at lower levels. HIBE or HABE, when applied at various levels, can 

solve the key distribution load problem. Because roots are ultimately trusted sources, authorized 

centres at each level are based on a single trusted root. In addition, system efficiency can be 

improved dynamically because identity authentication and key transmission can be performed 

locally. 

 

  In basic ABE systems, the information shared is always within one domain or 

organization. However, in reality, information such as drivers’ licenses and registration 

information in universities are organized by different government departments. The management 

of attributes and key distributions cannot be undertaken by the same attribute authority. 

Moreover, access strategies may be distributed based on attributes of different authorities. 

Mukt Shabd Journal

Volume IX, Issue IV, APRIL/2020

ISSN NO : 2347-3150

Page No : 4777



Therefore, levelled multi-authority ABE cannot meet distribution demands. Decentralizing 

multi-authority ABE is used to solve the access problem in which user attributes belong to 

different authorities. Those authorities differ from that for a leveled. In basic ABE systems, the 

information shared is always within one domain or organization. However, in reality, 

information such as drivers’ licenses and registration information in universities are organized by 

different government departments.  

 

 The management of attributes and key distributions cannot be undertaken by the same 

attribute authority. Moreover, access strategies may be distributed based on attributes of different 

authorities. Therefore, leveled multi-authority ABE cannot meet distribution demands. 

Decentralizing multi-authority ABE is used to solve the access problem in which user attributes 

belong to different authorities. Those authorities differ from that for a leveled multi-authorized 

ABE, for which the levelled multi-authority ABE has one trust root. There is no trust between 

organizations, and attribute management and key distribution always are performed separately 

from each other. For some specified work reasons such as sharing confidential corporate data on 

cloud servers, trust relationships can be made between organizations. Single-authority ABE 

primarily randomizes private keys, and the secret values are separated based on the part in the 

users’ private keys (referring to a different attribute), and decryption is performed by 

reconstructing the secret values. In Single-authority ABE, each user’s keys are generated using 

different random and secretly shared values such that keys generated for different users cannot 

be combined, which prevents collusion attacks. For decentralizing multi-authority ABE, the 

private keys of users can be generated by different authorities that do not communicate. Thus, 

the crucial technical challenge for decentralizing multi-authority ABE is constructing a secret-

sharing value to resist collusion attacks The Global Identifier (GID) and central authority 

originated to solve the resist collusion attacks.  

 

               All early schemes used central authority to deliver secret splitting, thereby assuring 

collusion resistant under circumstances wherein authorities do not trust one another. However, a 

central authority should be globally trustworthy. Therefore, in order to avoid the security 

weaknesses resulting from the use of central authorities, schemes that do not employ central 

authorities have been published. There is no reliance on single trust centres,  and although each 

Mukt Shabd Journal

Volume IX, Issue IV, APRIL/2020

ISSN NO : 2347-3150

Page No : 4778



authority distributes its own attributes and keys, they still need common support parameters for 

distribution by related organizations, or complicated trust relationships need to be formed 

between each authority. User’s GID is published globally in early schemes will breach the user 

privacy. In order to solve the question, some schemes used anonymous key issuing protocol to 

enhance user privacy, but the protocols usually are complex 

 

II. LITERATURE SURVEY 

 

In this section we will mainly discuss about the background work that is  carried out in 

order to prove the performance of our proposed Method. Now let us discuss about them in detail 

MOTIVATION 

 

1) PERM: Practical notoriety based boycotting without TTPS  

 

Creators: M. H. Au and A. Kapadia  

 

 A few clients may make trouble under the front of obscurity by, e.g., mutilating website 

pages on Wikipedia or posting profane remarks on YouTube. To forestall such maltreatment, a 

couple of mysterious accreditation plans have been suggested that deny access for getting into 

mischief clients while keeping up their obscurity to such an extent that no confided in outsider 

(TTP) is associated with the renouncement procedure. As of late we proposed BLACR, a without 

ttp plot that bolsters 'notoriety based boycotting' - the specialist co-op can score clients' unknown 

meetings (e.g., great versus unseemly remarks) and clients with lacking notoriety are denied get 

to. The significant downside of BLACR is the straight computational overhead in the size of the 

notoriety list, which permits it to help notoriety for just two or three thousand client meetings in 

handy settings.  

 

2) BLACR: sans ttp blacklistable unknown accreditations with notoriety  

 

Creators: M. H. Au, A. Kapadia, and W. Susilo  

 

Mukt Shabd Journal

Volume IX, Issue IV, APRIL/2020

ISSN NO : 2347-3150

Page No : 4779



 Unknown validation can give clients the permit to get into mischief since there is no 

dread of reprisal. As an obstacle, or intends to disavowal, different plans for responsible 

obscurity highlight a (conceivably appropriated) confided in outsider (TTP) with the ability to 

recognize or connect acting up clients. As of late, plans, for example, BLAC and PEREA 

demonstrated how mysterious disavowal can be accomplished without such TTPs—unknown 

clients can be denied in the event that they get into mischief, but no one can distinguish or 

connection such clients cryptographically. Regardless of being the best in class in unknown 

renouncement, these plans permit just an essential type of repudiation adding up to 'deny anyone 

with d or more mischievous activities' or 'disavow anyone whose joined mischief score is 

excessively high' (where mischievous activities are doled out a 'seriousness' score). We present 

BLACR, which altogether progresses unknown repudiation in three different ways: 1) It 

comprises a first endeavor to sum up notoriety based mysterious renouncement, where negative 

or positive scores can be relegated to mysterious meetings over numerous classes. Workers can 

square clients dependent on approaches, which determine a boolean mix of notorieties in these 

classes; 2) We present a weighted expansion, which permits the all out seriousness score to 

increase for various mischievous activities by a similar client; and, 3) We make a critical 

improvement in validation times through a method we call express path verification, which 

makes notoriety based mysterious disavowal functional.  

 

3) Constant-size powerful k-TAA  

 

Creators: M. H. Au, W. Susilo, and Y. Mu  

 

 Dynamic k-times mysterious confirmation (k-TAA) plans permit individuals from a 

gathering to be validated secretly by application suppliers for a limited number of times, where 

application suppliers can autonomously and progressively award or disavow get to right to 

individuals in their own gathering. In this paper, we build a powerful k-TAA conspire with 

existence complexities of O(log(k)) and a variation, wherein the verification convention just 

requires steady reality complexities at the expense of O(k) - estimated open key. We additionally 

portray some tradeoff issues between various framework attributes. We detail all the zero-

information evidence of-information conventions included and show that our development is 

Mukt Shabd Journal

Volume IX, Issue IV, APRIL/2020

ISSN NO : 2347-3150

Page No : 4780



secure in the arbitrary prophet model under the q-solid Diffie–Hellman supposition and q-

decisional Diffie–Hellman reversal presumption. We give a proof-of-idea usage, investigate its 

presentation, and show that our plan is down to earth.  

 

III. EXISTING METHODOLOGY 

  

 In the existing cloud servers, there was no concept like encryption of cloud data and also 

there was no facility like a global identifier like Attribute Authority (AA) for providing access 

keys for the data users who wish to access the sensitive information from the cloud server. The 

current cloud storage is almost centralized and all the data which is stored along with details of 

data owners and data users is clearly visible by the cloud server department, which is almost a 

big problem in the current cloud service providers. In the current cloud servers all the data can be 

viewed and accessed by anyone who is having an account access within the cloud, so that the 

data is not having integrity or security in terms of any modification or changes done by any user. 

Also in the current cloud servers there is no facility like multi authority data access for providing 

security in the cloud. 

 

LIMITATIONS OF THE EXISTING METHODOLOGY 

  

        The following are the limitation of existing system. They are as follows: 

1. All the existing schemes are limited to the single-owner model.  

2. All the current cloud servers has search in a normal manner under plain text model, but 

they don’t have any facility to search in a ENRYPTED manner 

3. There is no concept like multi authority which grants private and secret keys for 

downloading the file in a secure manner. 

4. The current cloud servers don’t have a facility to store the sensitive information under a 

de-centralized manner in which the access should lie in the hands of  separate individual 

departments. 

5. There is no term like global identifier for the existing cloud and there is no trust in the 

existing clouds. 

 

Mukt Shabd Journal

Volume IX, Issue IV, APRIL/2020

ISSN NO : 2347-3150

Page No : 4781



IV. PROPOSED  METHODOLOGY 

 

         We try to develop a new scheme by adding a global identifier like Attribute 

Authority (AA) for providing the data into multiple parts and then the data will be stored in a 

replicated manner in the cloud server.For accessing these replicated documents we need to 

request the global identifier to grant the access keys for the data users who wish to access the 

sensitive information from the cloud server. In this proposed work we try to use Composite 

Order Bilinear Groups scheme for providing access facility for the data users and provide more 

security for the sensitive data. This will try to grant security for the data and users by using multi 

authority model. Here the term multi authority means the data will been in the hands of attribute 

authority where AA1 will generate private key for encrypting the data before it gets stored in the 

cloud server and AA2 will generate secret key for the end users for using this to decrypt the data. 

ADVANTAGES OF THE PROPOSED SYSTEM 

 The following are the advantages of the proposed system. They are as follows: 

1. The proposed scheme is mostly multi owner model.  

2. The proposed model follows the search in a secure manner by restricting the open 

source access to the end users. 

3. The data will be stored in an encrypted manner rather than in the plain text manner. 

4. There is a concept like multi authority which grants private and secret keys for 

downloading the file in a secure manner. 

5. There is a term like global identifier for the proposed cloud which can greatly provide 

secure access of sensitive data in a decentralized manner. 

 

IV. IMPLEMENTATION STAGE 

 
 Implementation Stage is where the hypothetical structure is changed over into 

automatically way. In this stage we will partition the application into various modules and 

afterward coded for arrangement. The application is separated essentially into following 4 

modules. They are as per the following:  

Mukt Shabd Journal

Volume IX, Issue IV, APRIL/2020

ISSN NO : 2347-3150

Page No : 4782



1. Data Owner Module 

2. Authentication Center Module 

3. Cloud Server Module 

4. Data User 

 Now let us discuss about each and every module in detail as follows: 

 

1)  DATA OWNER MODULE 

 In this module, data owner has to register to Authentication Center and Authentication 

Center checks and authorizes the data owner login . Data owner browse the file , encrypt and 

upload file with its mac. Once uploaded the file all the authentication center must provide the 

storage access for the file store on the cloud. Data owner can also delete the file after the 

uploading of the file to the cloud. 

2)  AUTHENTICATION CENTER MODULE 

In this module Authentication Center checks user & owner login and authorizes the 

registration. Authentication center list all other sub-authentication centers and provide 

authorization (Activate OR Deactivate). Authentication center provides the storage access to 

cloud for every file uploaded by the data owner. 

      AA 1 

 In this module the AA1 shows all the private key requests from the users and generates. 

And also provides the storage access for the file uploaded by the data owner. 

      AA 2 

 In this module the AA2 shows all the public key requests from the users and generates. 

And also provides the storage access for the file uploaded by the data owner. 

 

3) CLOUD SERVER MODULE 

 

 Receive all files from the data owner and store all files, user details. Provide files to end 

user after verifying Private key and secret key provided by the authentication center. Maintain 

file transaction details and forward the file download request from the user to the authentication 

centre. 

 

Mukt Shabd Journal

Volume IX, Issue IV, APRIL/2020

ISSN NO : 2347-3150

Page No : 4783



4)  END USER MODULE 

 In this module end user has to register and login, and the user is authorized by the 

authentication center, user will request private key from the AA1 and the secret key from the 

AA2 to download the file from cloud server. 
  

 

V. EXPERIMENTAL REPORTS 

 

AA2 MAIN PAGE 

 
 

Figure. Represents the  AA2 Main Page 

 

DATA OWNER REGISTRATION PAGE 

 

 
Figure . Represents the  Data Owner Registration page 

 

 

Mukt Shabd Journal

Volume IX, Issue IV, APRIL/2020

ISSN NO : 2347-3150

Page No : 4784



DATA USER REGISTRATION 

 

 
 

Figure . Represents the  User Registration Page 

 

AUTHENTICATION CENTER CAN SEE BOTH AA’S STATUS 

 

 
 

Figure. Represents the  AA Centers Status 

 

 

Mukt Shabd Journal

Volume IX, Issue IV, APRIL/2020

ISSN NO : 2347-3150

Page No : 4785



VI. CONCLUSION 
 

 Decentralizing multi-authority ABE can take care of issues emerging from security 

prerequisites of sharing confidential corporate information on cloud workers. For decentralized 

multi-authority ABE plans with non-focal power, the plot safe can be fathomed utilizing the 

GID. Here the term de-incorporated access implies conceding multi specialists to control the 

entrance for giving greater security to the touchy information. In this proposed proposition we 

attempt to build up another plan by including a worldwide identifier like Attribute Authority 

(AA) for giving access keys to the information clients who wish to get to the delicate data from 

the cloud worker. In this proposed work we attempt to utilize Composite Order Bilinear Groups 

plot for giving access office to the information clients and give greater security to the touchy 

information. By directing different analyses on our proposed model, our outcome unmistakably 

tells that our proposed framework is proficient to get to the information in a de-unified way by 

utilizing a worldwide identifier. 

 

VII. REFERENCES 

[1]J. Horwitz,B. Lynn, “Towards hierarchical identity-based encryption“ in Proc.EUROCRYPT, 

Amsterdam, The Netherlands, April.2002, pp.466-481. 

 

[2]C. Gentry, A. Silverberg, “Hierarchical ID-based cryptography,”inProc.ASIACRYPT, 

Singapore, December. 2002, pp. 548-566. 

 

[3]D. Boneh, X. Boyen, “Efficient Selective-ID secure identity based encryption without random 

oracles,”inProc.EUROCRYPT, Interlaken, Switzerland, May.2004,pp. 223-238. 

 

[4]D. Boneh, X. Boyen, E. Goh, “Hierarchical identity based encryption with constant size 

ciphertext,”inProc.EUROCRYPT, Aarhus, Denmark, May.2005, pp. 440-456. 

 

[5]X. Boyen, B. Waters, “Anonymous hierarchical identity-based encryption(without random 

oracles),”inProc.CRYPTO, Santa Barbara, California, USA, August.2006, pp. 290-307. 

 

Mukt Shabd Journal

Volume IX, Issue IV, APRIL/2020

ISSN NO : 2347-3150

Page No : 4786



[6]B. Waters, “Dual system encryption: Realizing fully secure IBE and HIBE under simple 

assumptions,”inProc.CRYPTO,Santa Barbara, CA,August. 2009, pp.619-636. 

 

[7]A. Lewko, B. Waters, “New techniques for dual system encryption and fully secure HIBE 

with short ciphertexts,”inProc.TCC,Zurich, Switzerland, February.2010, pp. 455-579. 

 

[8]G. Wang, Q. Liu, J. Wu, “Hierarchical attribute-based encryption for fine-grained access 

control in cloud storage services,”inProc.CCS, Chicago,Illinois, USA, October.2010, pp. 735-

737. 

 

[9] G. Wang, Q. Liu, J. Wu,M. Guo, “Hierarchical attribute-based encryption and scalable user 

revocation for sharing data in cloud servers,”Computers&security, 30 (5), pp. 320-331, 

July.2011. 

 

[10]Zhiguo Wan, Jun’e Liu, Robert H. Deng, “HASBE: A Hierarchical attribute-based solution 

for flexible and scalable access control in cloud computing,”IEEE Transactions on Information 

Forensics and Security, 7(2),pp. 743-753, April.2012. 

 

[11] Q. Huang, L.Wang, Y.Yang, “DECENT: Secure and fine-grained data access controlwith 

policy updating for constrained IoT devices,”World Wide Web, 2017 (11), pp. 1-17, 2017. 

 

[12]A. Beimel, “Secure Schemes for secret sharing and key distribution[Ph.D. Thesis],”Haifa: 

Israel Institute of Technology, 1996. 

 

[13]D. Boneh, E. Goh, K. Nissim, “Evaluating 2-dnf formulas on 

ciphertexts,”inProc.TCC,Cambridge, MA, USA, February.2005, pp.325-341. 

 

[14]M. Chase, “Multi-authority attribute based encryption,”inProc.TCC, Amsterdam, The 

Netherlands, February.2007, pp. 515-534. 

Mukt Shabd Journal

Volume IX, Issue IV, APRIL/2020

ISSN NO : 2347-3150

Page No : 4787


";"""date"",""2020-08-24T06:13:09Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.4""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dcterms:created"",""2020-08-24T06:13:09Z""
""language"",""en""
""Last-Modified"",""2020-08-24T06:13:09Z""
""dcterms:modified"",""2020-08-24T06:13:09Z""
""dc:format"",""application/pdf; version=1.4""
""Last-Save-Date"",""2020-08-24T06:13:09Z""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2020-08-24T06:13:09Z""
""meta:save-date"",""2020-08-24T06:13:09Z""
""pdf:encrypted"",""false""
""modified"",""2020-08-24T06:13:09Z""
""Content-Length"",""340681""
""pdf:hasMarkedContent"",""false""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""meta:creation-date"",""2020-08-24T06:13:09Z""
""created"",""2020-08-24T06:13:09Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""12""
""Creation-Date"",""2020-08-24T06:13:09Z""
""resourceName"",""493-april2020.pdf""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""2180"",""2467"",""2707"",""1838"",""2503"",""2029"",""2038"",""1697"",""496"",""251"",""1952"",""1609""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""producer"",""PlotSoft PDFill 12.0""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""PlotSoft PDFill 12.0""
""pdf:docinfo:created"",""2020-08-24T06:13:09Z""
";https://scholar.google.ch/scholar?start=780&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098800-189;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;One-shot signatures and applications to hybrid quantum/classical authentication;R Amos, M Georgiou, A Kiayias… ; Proceedings of the 52nd …, 2020  dl.acm.org;;"… Our decentralized cryptocurrency construc- tion and its extensions share similarities with

blockchain construc- tions such as Bitcoin's mining using proof of work [36] as well as Ethereum's

concept of smart contracts [44] … The oracle is a combination of two oracles ??,??? where …";Cité 13 fois;Les 5 versions;[PDF] princeton.edu;https://www.cs.princeton.edu/~mzhandry/docs/papers/OSS.pdf;"
One-shot Signatures and Applications to Hybrid

Quantum/Classical Authentication

Ryan Amos∗1, Marios Georgiou†2, Aggelos Kiayias‡3, and Mark Zhandry§4

1,4Department of Computer Science, Princeton University
2Department of Computer Science, City University of New York

3University of Edinburgh & IOHK, UK
4NTT Research

Abstract

We define the notion of one-shot signatures, which are signatures where any secret key can be used
to sign only a single message, and then self-destructs. While such signatures are of course impossible
classically, we construct one-shot signatures using quantum no-cloning. In particular, we show that such
signatures exist relative to a classical oracle, which we can then heuristically obfuscate using known
indistinguishability obfuscation schemes.

We show that one-shot signatures have numerous applications for hybrid quantum/classical crypto-
graphic tasks, where all communication is required to be classical, but local quantum operations are
allowed. Applications include one-time signature tokens, quantum money with classical communica-
tion, decentralized blockchain-less cryptocurrency, signature schemes with unclonable secret keys, non-
interactive certifiable min-entropy, and more. We thus position one-shot signatures as a powerful new
building block for novel quantum cryptographic protocols.

Contents

1 Introduction 2
1.1 Motivating Example: Signature Tokens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Our Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3 Related Literature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.4 Notation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2 Equivocal Collision Resistant Hash Functions 9
2.1 Construction relative to a classical oracle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.2 Collision Resistance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.3 Equivocality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3 One-shot Chameleon Hash Functions 15
3.1 Uniformity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.2 Signature Delegation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

4 One-shot Signatures and Budget Signatures 18
4.1 From One-Shot Signatures to Budget Signatures . . . . . . . . . . . . . . . . . . . . . . . . . 19

∗rbamos@cs.princeton.edu
†mgeorgiou@gradcenter.cuny.edu
‡akiayias@inf.ed.ac.uk
§mzhandry@princeton.edu

1



5 Quantum Lightning and Quantum Money 21
5.1 Construction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
5.2 Primitive Smart Contracts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
5.3 Improvements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
5.4 Decentralized Cryptocurrency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

6 Ordered Signatures and Applications 23
6.1 Construction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
6.2 Key Evolving Signatures and Proof of Stake Blockchains . . . . . . . . . . . . . . . . . . . . . 25
6.3 Provably Secret Signing Keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
6.4 From Ordered Signatures to Delayed Signatures . . . . . . . . . . . . . . . . . . . . . . . . . . 27

7 Non-Interactive Proof of Quantumness and Min-Entropy 29
7.1 Proofs of Quantumness . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
7.2 Certifiable Min-Entropy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

1 Introduction

Quantum computing and quantum information promise to reshape the cryptographic landscape. In the near
term, quantum computers will be able to break much of the cryptography currently used today [Sho97],
with the field of post-quantum cryptography developing new alternative protocols. On the other hand,
quantum cryptography will leverage quantum communication to open new possibilities such as information-
theoretically secure key agreement [BB84], physically unclonable money [Wie83], and more.

Yet, even in a world full of quantum computers, classical cryptosystems and communication will still play
a fundamental role. The unclonability of quantum data, for example, means that tasks such as backing up
a quantum hard drive or forwarding a quantum email (while still keeping the original) will be impossible.
Even in a world where quantum computing is commonplace, it may be infeasible to run a quantum computer
in many computing environments, such as mobile or embedded devices. It may also be some time before our
communication infrastructure is updated to support the transfer of quantum data; besides, most data users
will care about is still classical, so it may seem as overkill to use quantum information to send such data.
With classical communication, however, most of the exciting developments from quantum cryptography
become unusable. This then leads to the following natural question:

When exchanging only classical information, can local quantum
computing still offer advantages over purely classical systems.

In some cases, the answer is certainly negative. For example, information-theoretic key agreement [BB84]
is impossible with classical communication, even if local quantum operations are allowed. Indeed, in quantum
key distribution, security is only obtained because the honest parties can detect if the adversary is eaves-
dropping; on the other hand, with classical communication, the adversary can listen to the communication
undetected. Another related example is information-theoretic key recycling [OH05, DPS05, GYZ17].

Hybrid quantum/classical cryptography. On the other hand, in an emerging field that we will call
hybrid quantum/classical cryptography — or hybrid quantum cryptography for short — it has been shown
that local quantum operations can yield an advantage in some settings. Recent work has shown how to
attain certifiable randomness expansion [BCM+18], which enables a classical client, for whom generating
true randomness is a notoriously difficult task, to verifiably outsource the generation of random bits to a
quantum computer, which can generate random bits easily. This task is closely related to the goal of quan-
tum supremacy — demonstrating that quantum computers can solve certain problems faster than classical
computers — which has recently gained much attention. Certifiable randomness has also been extended to
certifying arbitrary outsourced quantum operations, again using only a classical client [Mah18].

Given the importance of classical communication in a quantum world, we anticipate such hybrid protocols
to complement post-quantum and quantum cryptography and become a third pillar of active research at
the intersection of cryptography and quantum computing. Our goal in this work is therefore to provide new
foundational tools for this emerging area and develop novel applications.

2



1.1 Motivating Example: Signature Tokens

Consider the task of signature delegation: Alice wishes to allow Bob to sign a single message on her behalf.
Alice could just give Bob her secret key, but this would allow Bob to sign any number of messages. Alice
instead wants to give Bob enough information to ensure that Bob can subsequently sign a single arbitrary
message, without any further action on Alice’s part. Crucially, we want the message to only be decided after
Alice hands this information to Bob.

Of course, this task is impossible in a purely classical world, as Bob can re-use whatever information he
learned from Alice to sign any number of messages. One could hope that Alice could provide Bob with a
quantum signing token, which self-destructs after signing a message. By quantum no-cloning — which says
that general unknown quantum states cannot be copied — Bob cannot copy the token, and therefore can
only sign a single message. Indeed, Ben-David and Sattath [BDS16] show that such quantum signing tokens
are possible by building on ideas for public key quantum money [AC12].

No-cloning with only classical communication? But what if we insist on classical communication
between Alice and Bob1? How can we leverage the power of no-cloning, when any information Alice sends
to Bob can be copied unrestrictedly? It would seem that if Bob can derive a signing token from their
communication, he can simply copy the communication transcript to derive as many distinct signing tokens
as he would like.

The issue is actually very general, and is potentially problematic in any hybrid quantum protocol. After
all, quantum no-cloning and related concepts can be seen as the foundation for essentially all of the novel
features in quantum protocols. But now, what if we insist on only classical communication, relegating all
quantum operations to local computation? This means that any application of no-cloning applies to states
that the adversary constructed entirely on his own. How can we guarantee no-cloning, if the adversary
controls the entire process used to generate the state in the first place? Why can’t the adversary just run
the same process twice, generating two copies?

Perhaps surprisingly, we will demonstrate that with a single classical back-and-forth between Alice and
Bob, Alice can send Bob a single-use quantum signature token. In doing so, we demonstrate how to overcome
the difficulty outlined above and leverage no-cloning in a setting where all communication is classical.

A Toy Example. How is this possible? To illustrate how classical communication might be combined with
local no-cloning, we recall a basic scenario described by Zhandry [Zha19], which also underlies the recent
developments in certifiable randomness/quantum computation [BCM+18, Mah18]. Let H be a many-to-one
hash function that is collision-resistant against quantum attacks. First, generate a uniform superposition
of inputs. Next, compute the hash H in superposition and measure the result, obtaining a value y. The
original state collapses to the superposition |ψy〉 of all pre-images x of y.

Using the above procedure, it is easy to sample states |ψy〉. However, at the same time it is impossible
to sample two copies of the same |ψy〉, assuming the collision-resistance of H. Indeed, assume toward
contradiction that it were possible to generate two identical copies of |ψy〉. Then simply measure both
copies; each measurement will likely yield a different x, resulting in two distinct values mapping to the same
y, a contradiction.

A First Attempt. As a first attempt at a signature delegation protocol, we have Bob sample a pair
(|ψy〉 , y), and send the classical value y to Alice. Alice then signs y using some standard post-quantum
signature scheme, sending the resulting signature σ back to Bob. The result is that, with only classical
communication between Alice and Bob, Bob has arrived at a value (|ψy〉 , y, σ) that he cannot clone (due to
the collision resistance of H), nor can he sample on his own (due to needing Alice’s signature on y).

Of course, we have to also describe how (|ψy〉 , y, σ) can be used to sign a single message, but not
two. For general hash functions H, there is likely no meaningful way to accomplish this. For example,
if the hash function is collapsing [Unr16a], then having |ψy〉 is essentially no more useful than having a
single classical pre-image x. But of course a classical pre-image x cannot be used as a one-time signing
token, since it can be copied. Recent evidence suggests that typical post-quantum hash functions are likely
collapsing [Unr16a, LZ19].

1We will not even allow shared entanglement, which could be used in teleportation.

3



Toward a solution, we observe that our protocol so far bears resemblance to the chameleon signatures of
Krawczyk and Rabin [KR00]. Here, H is replaced with a special type of hash function, called a chameleon
hash. In such a hash function, Bob knows a trapdoor T which allows him to “open” the hash y to any message
m′ of his choosing. In particular, given y and any message m′, Bob can find an r′ such that H(m′, r′) = y.

We immediately see that chameleon hashing provides a partial solution to signature tokens. Indeed, Bob
can choose the hashing key H together with a secret trapdoor T , and send Alice any hash y, which Alice
then signs using her signing key. To sign a message m, Bob can then use the trapdoor to open y to any
message m, computing an r such that H(m, r) = y. Finally, Bob can then output (m, r, y, σ) as the signature
on m. The recipient will verify Alice’s signature on y and that H(m, r) = y.

This certainly works for delegating signatures. It is also mimics how signing authority is delegated in
practice, where instead of signing a hash, Alice would sign the a public key for Bob’s signature scheme. But
this standard delegation mechanism of course cannot provide the one-time property we are looking for, as it
is purely classical. Indeed, unforgeability relies on the collision resistance of H, which means Bob can break
unforgeability using his trapdoor. In particular, Bob can re-use his trapdoor as many times as he wishes,
opening y to any number of messages of his choice.

Our Solution: one-shot chameleon hashing. To remedy this issue, we imagine that Bob has a variant
of chameleon hash functions, where any given trapdoor can be used only a single time. Specifically, we
want that the hash function remains collision resistant even to Bob. In more detail, we define a one-shot
chameleon hash function as a hash function H with the following property: it is possible to first sample a
hash y together with a one-time quantum trapdoor |T 〉. Then, after seeing a message m, it is possible to
use the trapdoor |T 〉 to sample r such that H(m, r) = y. Importantly, anyone can sample a y, |T 〉 pair, and
H is collision resistant to everyone. This implies that once |T 〉 is used to compute r, it must self-destruct,
preventing further openings. This in particular implies that |T 〉 cannot be classical, else it could be copied
as many times as Bob would like.

Notice that all communication — namely y and σ — is classical. We also stress that we want H to be
a classical function. As such, Bob’s quantum operations are entirely local. What’s more, Bob is the only
party that is running a quantum computer; Alice can be purely classical.

Generalization: one-shot signatures. We can even abstract the protocol above slightly, to work with
a more general object called one-shot signatures. Here, anyone with a quantum computer can sample a
classical public key pk, together with quantum secret key |sk〉. Given |sk〉 and a message m, it is possible to
compute a classical signature r on m. Then anyone, knowing just the public key, can verify signatures. For
security, we require that it is infeasible to compute a tuple (pk,m0, r0,m1, r1) such that m0 6= m1, and r0

and r1 are valid signatures of m0,m1 respectively, with respect to the public key pk. We see that one-shot
chameleon hashing is just a special case of one-shot signatures where verification simply evaluates H(m, r),
and checks that the result is pk.

Remark 1. Note that one-time signatures — signatures whose security is only guaranteed when used to sign a
single message — are well known classically [Lam79], and can be built from the simplest tools in cryptography,
namely one-way functions. For one-time signatures, the signer should sign only a single message, else they
risk revealing their secret key. However, with one-time signatures, there is nothing actually preventing the
signer from signing two or more messages, if they decide it is advantageous to do so. With a one-shot
signature, in contrast, no matter what the signer does or what security he is willing to give up, he can only
ever sign a single message. This difference is the crucial feature of one-shot signatures.

At this point, it should be unobvious that one-shot signatures can even exist. After all, one-shot signatures
can be seen as an extremely strong variant of the quantum no-cloning theorem. The original no-cloning
theorem dealt with truly unknown quantum states, which were useless to anyone who did not know the
states, and therefore for whom no-cloning applied. Public key quantum money [Aar09] can be seen as a
strengthening, where no-cloning still holds even for parties that have the ability to verify the state. Even
this verifiable version of no-cloning has been notoriously difficult to achieve. Quantum lightning is then a
further strengthening, where no-cloning holds even for parties that devised the original state themselves; the
only existing construction is that of Zhandry [Zha19], which is based on new ad hoc hardness assumptions.

4



One-shot signatures can then be interpreted as yet a further strengthening of quantum lightning where the
un-clonable state has been endowed with the ability to sign a message. Given the difficulty in even achieving
the weaker forms of no-cloning, it is natural to wonder whether one-shot signatures are even possible.

1.2 Our Results

In this work, we explore applications similar to the above, where local quantum operations yield surprising
new protocols with classical communication. Our central building blocks will be one-shot signatures and
one-shot chameleon hash functions. Our results are as follows:

One-shot signatures and one-shot chameleon hashing (Sections 2,3,4). As our first contribution,
we give formal definitions for one-shot signatures and one-shot chameleon hashing.

We also construct one-shot chameleon hashing, and hence one-shot signatures. We observe that prior
work essentially constructs this object [ARU14], but only relative to a quantum oracle2, and there is no
known way to instantiate the oracle. We improve on this by demonstrating a classical oracle (but query-
able in superposition) relative to which we can build one-shot chameleon hashing and signatures. Even
finding a plausible classical oracle to build one-shot chameleon hashing exists is highly non-trivial. Our main
idea is to start from a hash function which is periodic. Such a function is certainly not collision resistant
against quantum attacks due to quantum period finding, but at least it is straightforward to show that
it gives rise to the chameleon property we need. We then recursively divide the set of pre-images of each
output into another periodic function. Importantly, we choose different periods for each set of pre-images
to avoid the overall function becoming periodic. In fact, we perform this recursive division several times,
each time using a different period for each set of pre-images. We demonstrate that this recursive structure
nevertheless preserves the chameleon property. We prove that our one-shot chameleon hashing is collision
resistant relative to this oracle using a modification of the polynomial method. Our classical oracle can then
heuristically be obfuscated using post-quantum indistinguishability obfuscation (e.g. [BGMZ18]) to yield a
plausible construction in the common reference string model.

Signature delegation. We then turn to applications. Many of our applications can be seen as applications
of our signature delegation mechanism above. We demonstrate that our signature delegation protocol works,
and can easily be delegated multiple times, with Bob delegating to Charlie, who delegates to Dana, etc. The
overall signature is the entire signature chain from Alice to the final signer.

Budget Signatures (Section 4). We can also delegate to pairs of public keys. Such delegation allows
us, for example, to construct budget signatures. Here, when signing a message, we specify a budget b > 0.
Each public key will come with a total budget B, and the security property is that Bob can sign any number
of messages, so long as the total budget remains less than B.

In our scheme, the public key for a total budget B will simply be the pair (pk, B) where pk is the public
key for a one-shot signature. To sign a message m with budget b at most the total budget B, simply sign
m using the one-shot secret key, using up the secret key. Alternatively, one can delegate to two budget
signature public keys pk0, pk1 with budgets B0, B1 respectively, where B0 + B1 ≤ B. To do so, simply sign
the concatenation of the two public keys. Those budget signatures can then be recursively used to sign with
budgets B0, B1. When verifying the signature relative to pk0, additionally verify the signature on pk0, pk1

relative to pk, as well as that B0 +B1 ≤ B. Since we know pk0 can only sign with budget up to B0 and pk1

can only sign with budget up to B1, this verification guarantees pk can only sign with budget total budget
up to B0 +B1 ≤ B. In typical usage, we imagine that to sign a message with budget b, we will first invoke
this delegation with B0 = b and B1 = B − b, and then sign m with respect to pk0, using the secret key in
the process. Further messages are signed with respect to pk1.

Remark 2. We note that with our delegation scheme, the size of signatures grows with the depth of the
delegation. For our budget signatures, this is potentially problematic if large numbers of messages, and hence
delegations, are expected, as it implies a large secret key and signature size. Similar limitations hold for
many of our protocols below based on our delegation mechanism. In this work, we will for the most part

2That is, an oracle which performs a quantum operation on its input state

5



ignore this issue. However, we observe that by using a (post-quantum) succinct non-interactive argument
of knowledge (SNARK) (e.g. [COS19]), one can prove knowledge of the long signature chain using a short
digest. This allows our budget signature scheme to have short signatures. Of course, in order to generate the
SNARK, one must remember the signature chain, and therefore the secret key must still be large. By using
a recursively composable SNARK, which allows for proving statements that include the SNARK verifier, we
can also compress the secret key of our scheme, by only ever remembering a SNARK of the signature chain.
We note that it is common to conjecture that SNARKs can be recursively composed for a polynomial number
of times [BSCTV14, Lab17], and a similar idea has been used to build cryptocurrency with a constant-sized
blockchain [Lab17]. Recursively composable SNARKs can also be used in our other delegation-based protocols
to compress key/signature sizes.

Quantum money with classical communication (Section 5). One-shot signatures readily yield public
key quantum money, where the mint has a public key that allows anyone to verify. Basically, the quantum
signing key |sk〉 for a one-shot signature serves as the quantum money state.

Using our signature delegation mechanism, we show how to send quantum money using only classical
messages. The mint’s public key will be the public key for a classical post-quantum signature scheme. To
mint a banknote with value V , the mint simply creates a secret key/public key pair (|sk〉 , pk) for a one-shot
signature scheme, and signs the pair (pk, V ) using it’s classical signature scheme to get signature σ. Sending
the note to someone simply invokes our delegation procedure. By combining with our budget signatures,
our quantum money scheme is also infinitely divisible, unlike existing constructions.

Decentralized blockchain-less cryptocurrency (Section 5.4). One-shot signatures also immediately
give rise to quantum lightning, yielding the first construction with provable security relative to a classical
oracle. As explained by Zhandry [Zha19], by combining with a suitable proof of work, quantum lightning
gives a decentralized cryptocurrency, where the double-spend problem is solved using no-cloning as opposed
to a blockchain. Zhandry’s scheme, however, requires quantum communication.

We combine our delegation scheme with proofs of work to give blockchain-less cryptocurrency using only
classical communication. The basic idea is that, to mint a new note, the miner generates a secret key/public
key pair for a one-shot signature scheme. Then the miner uses the public key as the challenge in a proof of
work. The completed proof of work and the key pair constitute the note. Spending the note just involves
our delegation mechanism, except that for the first transaction, the miner appends the proof of work to the
message he signs.

Ordered Signatures (Section 6). Here, when signing a message, one also specifies a tag t. The signing
key allows for signing any message, but the requirement is that messages can only be signed in order of
increasing t. That is, once a message is signed at tag t0, it then becomes impossible to sign a message at a
“past” tag t1 < t0.

Our construction is very simple: the public key will be the public key for a one-shot signature scheme.
To sign a message at tag t, simply construct a new one-shot signature public key/secret key pair (pk, |sk〉),
and delegate to the new public key. When signing to delegate, sign the entire public key/tag/message triple.
|sk〉 becomes the new secret key, and the signature consists of the entire signature chain from the original
public key to the latest public key. To verify, simply verify the signature chain, as well as verify that the
tags in the chain occur in increasing order. The idea is that, by the one-shot security of our signatures,
the only way to produce a new signature is to append to the signature chain. Therefore, once an adversary
produces a signature at tag t0, he has committed to all the signatures he will produce at tags t1 < t0. If he
tries to sign a different message at t1, this will constitute a fork in the chain, violating the one-shot security
property.

Ordered signatures allow one to provably destroy their signing key by signing a dummy message at time
∞. Or one can at provably update their key by dividing time into epochs, and signing a dummy message at
the end of an epoch to update to the next epoch.

Key-Evolving Signatures and Proof-of-Stake Blockchains (Section 6.2). Ordered signatures pro-
vide a first instantiation of key-evolving signatures in the erasure model. A key-evolving signature (KES),

6



(see e.g., [Fra06]) enables key updates at regular intervals (or per message) so that a key exposure incident
at a certain time cannot compromise the unforgeability of past periods. Instantiating KES classically is only
possible assuming erasures, i.e., that the party is capable of erasing its old private state after the update.
Applying ordered it is possible to obtain a KES in the non-erasure model, i.e., the setting where the adversary
may have access to past states.

This observation circumvents a standard model impossibility result and resolves an open question in
Proof-of-Stake (PoS) blockchain protocols, [BGK+18, CM19], regarding their security in the non-erasure
model: in these protocols, in order to solve the problem of “long range attacks” (see e.g., [But14, GKR18]).
key-evolving signatures are utilized to ensure that corruption of past keys cannot provide any advantage to
an attacker that corrupts old keys that used to be associated with a large percentage of stake but have since
been depleted. In the classical non-erasure model such corruption leads to a long range attack that can
break consistency (see e.g., [DPS19] where this is stated as a formal impossibility). Basing the proof-of-stake
operation on an ordered signature eliminates this attack vector and facilitates a secure PoS blockchain in
the non-erasure model.

Single-signer Signatures (Section 6.3). Here, the secret key is subject to quantum no-cloning, meaning
that at any time, only a single user is capable of signing with respect to a given public key. Our ordered
signatures readily give such single-signer signatures, by simply having the tag t be a counter, incremented
with each signature. Security is proved as follows: toward contradiction, if one could split a secret key into
two states such that each state is independently capable of signing, then it is impossible to guarantee any
order between the signatures produced by each state, breaking the underlying ordered signature.

Of course, this signing capability can be transferred by sending over the quantum secret key; our signa-
tures can also easily be transferred with only classical communication, again using our delegation mechanism.

We observe that single-signer signatures can be seen as yet a further strengthening of quantum no-
cloning. Whereas one-shot signatures endow the unclonable state with the functionality of signing messages,
the functionality can only be used a single time before the state self-destructs. Single-signer signatures
instead give the unclonable state the perpetual ability to sign an unlimited number of messages, but this
ability cannot be split amongst two parties.

Delay Signatures (Section 6.4). Adding proofs of sequential work (PoSW) to our ordered signature
construction, we obtain what we call delay signatures, where the signer must wait a certain amount of time
between signing messages.

As a potential application we imagine combining delay signatures with our quantum money scheme. The
result is that the mint can only mint new currency at a certain rate. This would prevent an untrusted
government from paying debts by simply minting unlimited money.

Proofs of quantumness (Section 7.1). One-shot signatures easily give rise to a proof of quantumness:
to prove quantumness, generate a public key for a one-shot signature scheme, and send it to the verifier.
The verifier then chooses and sends back a random message. Respond with a signature on the message. A
simple rewinding argument shows that any classical adversary that passes verification can be used to sign
two messages with respect to the same public key, violating one-shot security.

Interestingly, our proofs of quantumnes are public coin, meaning soundness holds even if the verifier’s
random coins are public. Such protocols can be made non-interactive using the Fiat-Shamir heuristic.
Prior protocols [BCM+18] are interactive and secret coin, and there is no obvious way to turn them into
non-interactive protocols.

Certifiable Randomness (Section 7.2). Our proofs of quantumness also immediately give rise certifiable
min-entropy, which is again public coin and can be made non-interactive with Fiat-Shamir. Again, prior
protocols required multiple rounds3.

3Though the prior protocols are able to achieve (statistically close to) uniform randomness. In contrast, as explained by
Zhandry [Zha19], any non-interactive protocol can never achieve uniform randomness. Our protocol achieves super-logarithmic
min-entropy.

7



1.3 Related Literature

Comparing our primitives with classical primitives. Most of the cryptographic notions in this work
can be thought of as “one-shot” versions of existing classical cryptographic primitives. One-shot chameleon
hash functions generalize the classic equivalent introduced by Krawczyk and Rabin [KR00]. Our one-shot
signatures are the one-shot analogue of one-time signatures by Lamport [Lam79] in the sense that one
not only is unwilling to generate a second signature but also he is unable to. Our chain of delegations,
our quantum money scheme and our ordered signatures use components from the Naor-Yung paradigm for
building full-blown signatures out of one-time signatures [NY89] and our budget signatures shares similarities
with Merkle signatures [Mer89].

Quantum Query Complexity. Our query complexity lower bound uses elements from Ambainis’s ad-
versary method [Amb02], as well as techniques for building public-key quantum money by Aaronson and
Christiano [AC12] and tokens for digital signatures by Ben-David and Sattath [BDS16]. Our construction of
equivocal hash functions relative to a classical oracle extends the pick-one trick by Ambainis et al. [ARU14]
and implies the existence of quantum lightning by Zhandry [Zha19]. Interestingly, unlike previous results, our
collision resistance lower bound is not based on the polynomial method [BBC+01]. The polynomial method
works well in proving indistinguishability between oracles but little can be done when it comes to search
problems. Indeed, proving that a function is collision resistant through indisting";"""date"",""2020-02-05T15:01:48Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2020-02-05T15:01:48Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.19 (TeX Live 2018) kpathsea version 6.3.0""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2020-02-05T15:01:48Z""
""created"",""2020-02-05T15:01:48Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-02-05T15:01:48Z""
""resourceName"",""OSS.pdf""
""Author"",""""
""producer"",""pdfTeX-1.40.19""
""pdf:docinfo:producer"",""pdfTeX-1.40.19""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""8"",""13"",""0"",""4"",""0"",""0"",""1"",""29"",""39"",""98"",""32"",""57"",""24"",""12"",""35"",""6"",""19"",""23"",""32"",""0"",""8"",""11"",""67"",""4"",""32"",""21"",""8"",""8"",""0"",""1"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2020-02-05T15:01:48Z""
""Last-Modified"",""2020-02-05T15:01:48Z""
""dcterms:modified"",""2020-02-05T15:01:48Z""
""title"",""""
""Last-Save-Date"",""2020-02-05T15:01:48Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2020-02-05T15:01:48Z""
""meta:save-date"",""2020-02-05T15:01:48Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.19 (TeX Live 2018) kpathsea version 6.3.0""
""Content-Length"",""536660""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""33""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""2043"",""3648"",""3921"",""4149"",""3939"",""3927"",""3806"",""3875"",""3108"",""3242"",""2719"",""1354"",""1867"",""3115"",""2128"",""2394"",""2986"",""3059"",""2652"",""2834"",""2919"",""3761"",""3225"",""1664"",""3224"",""3896"",""2248"",""3197"",""2800"",""2870"",""2956"",""2892"",""547""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-02-05T15:01:48Z""
";https://scholar.google.ch/scholar?start=730&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098822-231;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;[PDF][PDF] Lelantus: A New Design for Anonymous and Confidential Cryptocurrencies;A Jivanyan ; eprint.iacr.org;;"… Step 1: Transaction anonymity with fixed-value coins. Zerocoin, designed as an extension

to Bitcoin and similar cryptocurrencies[27], was one of the first anonymous cryptocurrency

propos- als to ensure high anonymity for the blockchain transactions …";Autres articles;;[PDF] iacr.org;https://eprint.iacr.org/2019/373.pdf;"
Lelantus: A New Design for Anonymous and Confidential
Cryptocurrencies

Aram Jivanyan

Zcoin
aram@zcoin.io

https://zcoin.io

Abstract. For cryptocurrency payments to be truly private, transactions have to have two
properties: confidentiality, i.e., hiding the transferred amounts, and anonymity, i.e. hiding the
identities of the sender and/or receiver in a transaction.
In this paper, we propose Lelantus, a new decentralized anonymous payment (DAP) protocol
that ensures confidential and anonymous blockchain transactions with small transaction sizes,
short verification times, and without requiring a trusted setup. It efficiently supports large
anonymity sets of size hundred thousand and beyond by providing logarithmic proof sizes and
efficient sub-linear verification time of the transactions. We implement Lelantus to measure
its performance and show that it is very efficient to support scalable privacy cryptocurrencies.
We also formally prove the security of the proposed protocol characterized by three security
properties referred to as ledger indistinguishability, transaction non-malleability, and balance.
Lelantus design concepts can be used in combination with the MimbleWimble and Confidential
Transactions protocols, two other popular blockchain privacy schemes for confidential trans-
actions. A hybrid scheme of Lelantus-MimbleWimble has been developed and implemented
into a fully-fledged privacy cryptocurrency in order to provide both confidentiality and strong
anonymity of blockchain payments.
As part of our protocol, we also introduce an extension of one-out-of-many proofs for general-
ized Pedersen commitments and provide formal security proofs for the proposed design, which
may be of own interest.

1 Introduction

The goal of this paper is to provide a novel practical transaction scheme which is based only on
standard cryptographic assumptions and does not require any trusted setup procedures, at the same
time efficiently supports strong anonymity and confidentiality properties for direct blockchain pay-
ments. We start by achieving transaction anonymity with a Zerocoin-like setup which is implemented
through one-out-of-many proofs as is discussed in [4]. Zerocoin is strictly limited to work with fixed
denominated coins which can be spend anonymously but without any ability of merging, splitting or
partially redeeming multiple coins in a confidential way. We extend this fundamental construction
in a few significant ways.
First, we extend Zerocoin coins with secret balances enabling the user to mint coins of arbitrary
values and later spent them anonymously into fresh new outputs of arbitrary values. Then we de-
velop a proprietary zero-knowledge balance proof mechanism to ensure that the transaction’s input
and output values sum up. The transaction balance proof leverages specific design properties of the
modified one-out-of-many protocol construction discussed in this paper. These properties enable to
extract encoded information about the spent inputs values necessary for proving the balance without
revealing the inputs origins. Our construction admits an arbitrary number of transaction inputs and
outputs without limitations. Next we introduce shielded addresses and enable the user to perform



direct anonymous payments where the transaction outputs can be spent only by the intended recip-
ient.
Further, we discuss a highly-efficient batch verification method that enables the network validators
verifying hundreds or even thousands of different transactions simultaneously by significantly low-
ering the average cost of a single transaction verification.
The resulting scheme has numerous advantages over the alternative secure payments protocols,
namely:

• It does not require any trusted setup processes and the protocol security is relying only on
standard and time-tested cryptographic assumptions.

• Provides strong anonymity of blockchain transactions by efficiently supporting large anonymity
sets of size 65536 and higher.

• Transactions support direct anonymous payments and an arbitrary number of input and output
coins. Shielded coins can be merged, split or redeemed in an anonymous and confidential way.

• The transaction communication complexity is logarithmic in the anonymity set size. The com-
putational complexity of transaction verification is sub-linear due to efficient batch verification
methods.

We also analyze and provide formal security proofs for our decentralized anonymous payment sys-
tem by using a robust security framework introduced by Zerocash[3]. Our paper discusses a novel
modification of a one-out-of-many proof system that works with generalized Pedersen commitments
and can be of independent interest. We provide complete formal security proofs of this construction’s
soundness, zero-knowledge and completeness properties.
Two major privacy cryptocurrency projects Zcoin[33] and Beam[36] have announced transition to
Lelantus and Lelantus-MW.

1.1 Overview and Intuition

Lelantus can be integrated with any blockchain-based currency, such as Bitcoin. To give a sense of
how Lelantus works, we outline our construction in four incremental steps starting from the original
Zerocoin construction.

Step 1: Transaction anonymity with fixed-value coins. Zerocoin, designed as an extension
to Bitcoin and similar cryptocurrencies[27], was one of the first anonymous cryptocurrency propos-
als to ensure high anonymity for the blockchain transactions. It enables users to transform their
base layer coins(e.g. Bitcoin) into shielded coins and later spend the shielded coin without revealing
its origin. When spent, a special zero-knowledge proof is generated convincing that the spent coin
is one of the previously minted shielded coins which was not already spent before. The set of all
shielded coins that the spent coin belongs to is referred to as an anonymity set. Intuitively, the size
of the anonymity set defines how strong is the guaranteed transaction anonymity. The bigger is the
anonymity set size, the stronger anonymity is archived for each spent coin. The original Zerocoin
construction[27] was based on the RSA accumulators and was not efficient from the communication
standpoint as each proof consisted of ∟25KB. It also required a trust toward the exploited RSA
parameters. In [4] authors presented a novel one-out-of-many proof protocol and also proposed an
efficient Zerocoin construction which does not require any trusted setup operations, supports signifi-
cantly smaller proof sizes and efficient computations compared to the original construction. Zerocoin
protocol consists of four algorithms (Setup, Mint, Spend, Verify) and can be implemented with help
of one-out-of-many proofs over the homomorphic Pedersen commitments [8] as described below.

2



1. Setup: Generates the public parameters of the underlying commitment scheme by specifying
the group G and fixing two generators g and h with no known discrete logarithm relation.

2. Mint: For minting a new coin, the user generates a unique coin serial number secret sn, and
then commits to sn using the Pedersen commitment scheme and a fresh blinding factor r: The
resulted coin C = Com(sn, r) is published to the blockchain and is added to the pool of all
previously minted coins {C0, C1, ...CN−1}. The coin serial number sn and the opening value r
are used later to spend the coin C.

3. Spend: The user parses the set of all previously minted coins {C0, C1, ...CN−1} and homomor-
phically substracts the serial number value sn from all these coins. This results in a new set of
commitments where one will obviously be opening to 0. Next the user generates a one-out-of-N
proof of knowledge of this secret commitment opening to 0 without revealing its index in the
referred set. The proof transcript and the coin’s serial number sn are published to the blockchain.

4. Verify: All network participants can take the revealed serial number sn and check that it does
not appear in any previous spend transaction. Next they can homomorphically subtract this
serial number from all coins in the pool and and then check the validity of the provided one-
out-of-N proof against this new composed set of commitments.

Step 2: Enabling to mint, merge, split and redeem coins of arbitrary values. As discussed,
Zerocoin makes transaction history private, but does not support payments of arbitrary values and
also can not enable direct anonymous payments. For ensuring both transaction confidentiality and
anonymity, our first step is to represent coins with generalized Pedersen commitments which commit
simultaneously to the coin’s serial number and its value. Next we support generic Spend transac-
tions which can spend multiple inputs anonymously and output multiple outputs by providing a
zero-knowledge balance proof that the transaction inputs and outputs sum up without revealing the
input coins origins or the coins amount.

Step 3: Enabling direct anonymous payments. We extend the protocol to support direct
anonymous payments which enable users to transfer a value confidentially to the targeted recipients
without any future ability for tracing the transferred coins. We introduce shielded addresses, which
are generated by the recipient and used by the sender for generating the output coins. Usage of
the shielded addresses helps to keep the serial number of the newly created coin private for the
sender and enables the recipient to spend the received coin anonymously. We prevent malleability
attacks on a spend transaction (e.g., malicious assignment by re-targeting the recipient address of
the transaction public output) by generating the coin serial numbers as public keys and require each
spend transaction to be signed with the corresponding witness.

Step 4: Performing batch verification of transaction proofs.The communication and com-
putational complexity of transactions are of extreme importance for the practicality and scalability
of the payment system. In our system, each spent coin requires a separate one-out-of-many proof
to be generated, in which communication complexity is only logarithmic of the anonymity set size
N and is highly efficient but the verification complexity is linear. It may take hundreds of millisec-
onds to verify a single spend proof within a set of a few dozen thousand commitments. In this
paper, we will illustrate important batch verification techniques that enable us to verify multiple
proofs in batches and lower the average cost of a single proof verification to dozens of milliseconds
within significantly large commitment sets. This makes our scheme performance very competitive
with other cutting-edge privacy payment approaches. The Table 1 illustrates how Lelantus compares
with other confidential payments protocols such as Monero, QuisQuis, Zerocoin and Zerocash. As
will be discussed in the Section 5, the reported performance can still be significantly improved, but
even the current implementation shows that for a typical 2-input, 2-output transaction our scheme

3



Table 1. Security properties and efficiency considerations for different privacy solutions. The Lelantus proof
sizes and performance numbers are measured for 2-inputs-2-output transactions computed by batch verifying
100 proofs.

Anonymity Trusted Security Proof Proving Verification
Set Size Setup Assumptions Size(Kb) Time(S) Time(ms)

Monero 11 No Well Studied 2.1 0.9 47
QuisQuis 16 No Well Studied 13 0.47 71
Zerocash 232 Yes Relatively New 1 1-10 8
Zerocoin 10000 Yes Well Studied 25 0.2 200
Lelantus1024 1024 No Well Studied 2.7 0.27 6.8*
Lelantus16384 16384 No Well Studied 3.9 2.35 10.2*
Lelantus65536 65536 No Well Studied 5.6 4.8 52*

provides much stronger anonymity than Monero or QuisQuis at the comparable computational and
communication cost. The proof sizes and verification times of SNARK-based constructions are hard
to beat but this unmatched performance, however, is expensively bought with having to require a
trusted setup and reliance on knowledge of exponent cryptographic assumptions. Lelantus provides
strong privacy and competitive performance while still relying on standard cryptographic assump-
tions and without requiring a trusted setup. At the same time, it offers orders of magnitude stronger
anonymity properties than Monero or QuisQuis while being also more efficient due to the smaller
transaction sizes and shorter verification times.

1.2 Related Works and Comparison

There are many cryptographic constructions which do offer blockchain payment privacy in the UTXO
model, such as Zerocash [3], Monero [34], QuisQuis,[10] and Zerocoin [27]. Zerocoin is one of the
pioneer technologies providing strong anonymity for Bitcoin transactions but this scheme was com-
putationally not efficient and supported only limited functionality without hiding the transaction
amounts and working only with fixed denominated coins. Monero and QuisQuis both enable direct
anonymous payments of arbitrary amounts, but they provide relatively weak anonymity guaranties.
The anonymity set size in Monero and QuisQuis transactions are 11 and 16 accordingly which is
small enough to make different tracking analysis attacks possible[40, 9]. Recent work [11–13] dis-
cusses efficient ring signature schemes which aim to improve both the anonymity and complexity of
Monero transactions. Unlike Monero or Quisquis, Zerocash supports large anonymity set in a very
efficient way, but this hard-to-beat efficiency and advanced privacy features come at the price of
reliance on relatively new cryptographic security assumption and a trusted setup procedure, which
necessitate the user’s trust in the correctness of this setup.
There is a significant amount of active research on the development of efficient zero-knowledge proof
systems. Currently numerous constructions achieve different tradeoffs between transaction proof
sizes, proving and verification times under different trust models and cryptographic assumptions.
From the verification complexity standpoint the most efficient proof systems to date are zk-SNARKs
[25, 26] which require a trusted setup processing, although the recent work in this direction can sup-
port universal and continually updateable trusted setup processes[18]. There have been also designed
powerful transparent zero-knowledge proof systems such are Bulletproofs [7], zk-STARKS [16], Au-
rora [17], Supersonic[19] and Halo[20]. Bulletproofs are ubiquitously used in private digital currency
systems[33, 36, 35, 34] for generating efficient range-proofs, but the computational or communication

4



complexity of these transparent schemes still seems to be beyond the practicality limit when applied
to the large-scale confidential payment applications.

1.3 Lelantus and MimbleWimble

MimbleWimble is another popular blockchain privacy protocol implemented by few privacy cryp-
tocurrency projects including Beam[36] and Grin[35]. In MimbleWimble design, the transaction
inputs and outputs are introduced through Pedersen commitments and this protocol uses the com-
mitment blinding factors of transaction inputs and outputs as private keys. Sender and receiver
must interact to construct a joint signature to authorize a transfer of funds. MimbleWimble enables
to aggregate all transactions within the block into one giant transaction resulting to significantly
smaller ledger. It also provides cut-through methods, in which all spent outputs cancel against cor-
responding inputs across the blockchain and helps to erase most of the blockchain history and shrink
the ledger size. However this design enables network observers to easily link the transaction inputs
and outputs and break the anonymity of users. This remains a major privacy drawback and in order
to overcome this limitation, Beam has designed a hybrid scheme of Lelantus and MimbleWimble
[37] which provides strong anonymity to MimbleWimble transactions by enabling transactions with
hidden origins. In this hybrid approach, users can create coins as generalized Pedersen commitments
which hide both the coin value and a unique serial number. These coins are added into the shielded
pool and can be spent anonymously using one-out-of-many proofs. The Spend process of the shielded
coin first reveals the coin’s serial number and outputs a fresh coin represented through a regular Ped-
ersen commitment. The provided zero-knowledge proof shows that the output coin encodes the same
value as the spent shielded coin without revealing its origin. This output coin can later participate
into a MimbleWimble-style transaction which spends regular coins and outputs either regular or
shielded coins by proving that the transaction is still balanced. This hybrid scheme will be deployed
by Beam[37]. Provided hybrid design simultaneously ensures strong anonymity and MimbleWim-
ble balance proofs, but still requires interaction between the sender and recipient for finalizing the
transaction. Beam also created a Mimblewimble Confidential Lelantus Asset scheme [38] similar to
the Confidential Assets proposal by Blockstream [39]. For more details on these constructions we
refer to the original papers [37, 38].

2 Cryptographic Background

We denote R = {x;w | LR} to be a binary relation for instances x and witnesses w where LR defines
the corresponding language; i.e LR = {x|w : (x,w) ∈ R}. A zero-knowledge proof for the relation R
means that the prover knows secret witness w, so that (x,w) ∈ LR where x is a public value. We
use x←−R T for sampling an element x uniformly at random from a set T . Let G be a cyclic group
of prime order p where the discrete logarithm problem is hard, and let Zp be its scalar field.

Generalized Pedersen Commitments: Let g and h be random generators of G whose dis-
crete logarithm relationship is unknown. A Pedersen commitment scheme [8] enables to commit
to m ∈ Zp by picking a random blinding factor r ∈ Zp and computing Com(m, r) = gmhr. Ped-
ersen commitment scheme is perfectly hiding which means it does not leak any information about
the committed value. It is also computationally strongly binding under the discrete logarithm as-
sumption which means the commitment can only be opened in one way. For more formal definitions
of these security properties and their security proofs we refer to [8]. The Pedersen commitment
scheme can be generalized for multiple messages, i.e. given n messages m1,m2, ...,mn and n + 1

5



independent generator points g1, g2, . . . , gn and h, one can create a commitment of the following
form Com(m1,m2, ¡ ¡ ¡mn; r) = gm1

1 gm2
2 ¡ ¡ ¡ gmn

n hr Generalized Pedersen commitment scheme is also
computationally strongly binding, perfectly hiding and retains cryptographic homomorphic proper-
ties. In our protocol design, we use a private case of generalized Pedersen commitment scheme which
is utilizes three different group generators g, h, f to commit to the given messages s and t by using
the blinding factor r as Commck(s, t, r) = gshtfr. For sake of simplicity we refer to this private case
of generalized Pedersen commitment scheme as double-blinded commitment.
Note: We will henceforth denote the Pedersen commitment for value m using randomness r as
Com(m, r). A double-blinded commitment using the values s, t and r is denoted as Comm(s, t, r).

One-out-of-many proofs for a commitment opening to zero: One-out-of-many proof is a
three step interactive proof of knowledge that one out of N public commitments {C0, . . . , CN−1} is
opening to 0. It has been first introduced in [4] and more efficient construction has been proposed in
[5] which significantly reduces the proof sizes and improves the proving complexity. In this paper we
introduce a modified version of one-out-of-many proofs for double-blinded commitments described
by three algorithms (Setupooon,Proveooon,Verooon) which is a proof of knowledge that the public list
of N double-blinded commitments {C0, . . . , CN−1} includes some Comm(0, v, r) which is a commit-
ment to 0. In the Appendix A, we provide the full description of our scheme and formally prove its
security in the same framework used in [4]. In Lelantus design we will use the non-interactive variant
of one-out-of-many proofs obtained through Fiat-Shamir heuristic [4] and the proof transcript of non-
interactive one-out-of-many proof with respect to the public list of commitments {C0, . . . , CN−1} is
denoted by πooon(C0, . . . , CN−1).

Bulletproofs: Bulletproofs are a zero-knowledge interactive proof systems defined by three al-
gorithms (Setupbp,Provebp,Verbp) for providing short and aggregatable range proofs [7]. Formally,
let v ∈ Zp and let C ∈ G be a Pedersen commitment to v using the randomness r. Then the proof
system will convince the verifier that the committed value v ∈ [0, 2n − 1]. We will denote the tran-
script of non-interactive range-proofs for the commitment C with respect to the generators g and h
and the specified range [0, 2n − 1] by πrange(C; g, h, n).

Proof of knowledge of discrete logarithm representation: A group element can be expressed
as the product of powers of certain generators which is called the DL representation of the el-
ement with respect to that generators [21]. A discrete logarithm representation (or DL-REP for
short) of h ∈ G with respect to the generators g1, . . . , gl ∈ G is the tuple (a1, . . . , al) ∈ Zlp where
h = ga11 ¡ ¡ ¡ g

al
l . Note that when l = 1, h is represented as h = ga11 . In this case finding the a1 having

only g1 and h is the discrete logarithm problem. Thus the discrete logarithm problem can be regarded
as the special case of the DL representation which contains only one term and it is easy to show
that finding a DL representation of h ∈ G with respect to the generators g1, . . . , gl ∈ G is at least as
hard as the DL problem[21]. Finding two different representations for some h ∈ G with respect to
the same generator points g1, . . . , gl is also at least as hard as the DL problem [21].An interactive
proof of knowledge of representation (also referred as generalized Schnorr proof of knowledge) is a

zero-knowledge argument for the relation R = {g1, . . . , gk ∈ G, y; a1, . . . , ak ∈ Zp | y =
∏k
i=1 g

ai
i }. It

satisfies to the completeness, special honest verifier zero-knowledge and special soundness properties
as is discussed in [21, 4]. We will denote the transcript of non-interactive proof of representation of
the value y with respect to given generators g1, . . . , gl πdlrep(y; g1, . . . , gk).

One-time strongly-unforgeable digital signatures: We use a digital signature scheme Sig =
(Setup,Ksig,SSig,VSig) described as follows.

6



• Setupsig(1λ) −→ ppsig. Given a security parameter λ, Setup samples public parameters ppsig.
• Ksig(ppsig) −→ (pksig, sksig) Given ppsig, Ksig samples a pair of verification and signing keys.
• Ssig(sksig,m) −→ σ. Given the key sksig, Ssig signs the message m to obtain a signature σ.
• Vsig(pksig,m, σ) −→ b. Given the verification key pksig, message m, and signature σ, Vsig outputs
b = 1 if the signature is valid for message m or b = 0 otherwise.

We require the signature scheme Sig to satisfy the security property of one-time strong unforgeabil-
ity against chosen-message attacks(SUF-1CMA security) [41].

Key-private public key encryptionWe also use a public-key encryption scheme defined as a
tuple of four algorithms Enc = (Setup,Kenc, Eenc,Denc) as follows.

• Setupenc(1λ) −→ ppenc. Given a security parameter λ, Setup samples public parameters ppenc..
• Kenc(ppenc) −→ (pkenc, skenc) Given ppenc, Kenc returns a pair of public and secret key.
• Eenc(pkenc,m) −→ σ. Given pkenc and a message m, Eenc encrypts m with the public key pkenc

to obtain a ciphertext c.
• Denc(skenc, c) −→ m. Given the secret key skenc and the ciphertext c encrypted under the corre-

sponding public key pkenc, Denc outputs m if decryption succeeds or null otherwise.

We require the encryption scheme Enc to be both IND-CCA and IK-CCA secure[24].

3 Lelantus Construction

Lelantus is a decentralized anonymous payment system allowing direct blockchain transactions with
hidden origins and amounts. In this section we provide overview of the underlying building blocks,
data structures and algorithms used in the proposed design, and also discuss its security properties.

3.1 Data Structures and Algorithms

Lelantus is exploiting the following data structures and algorithms.

Basecoin Ledger. Lelantus can be integrated with any blockchain-based currency (e.g. Bitcoin)
which is referred as the basecoin currency. The basecoin currency ledger L is the only data storage
used over the system to record both the basecoin and the confidential Mint and Spend transactions
introduced by Lelantus.

Addresses. Apart of the basecoin ledger addresses, Lelantus exploits special shielded addresses
to power direct anonymous payments. Each user can generate arbitrary number of new shielded ad-
dress pairs (addrsk, addrpk). For each address, the addrpk is the public component used for receiving
funds privately, and the addrsk is the private address used only by the address owner to spend the
received funds.

Coins. Coin encodes the abstract monetary value which is transferred through the private transac-
tions. Each coin is associated with

• A coin value v which is measured in basecoins and can be any integer from the system specified
range [0, vmax).

• A coin public address addrpk which indicates the coin transfer destination. The recipient proves
his ownership over the received coins through the corresponding secret address addrsk.

7



• A coin unique serial number sn. The serial number sn is revealed when the coin is spent and it
prevents possible double-spending of the coin.

• A coin commitment denoted as C. This is a double-blinded commitment encoding the coin serial
number sn and the coin value v and blinded by a randomly generated blinding factor r. The
coin commitment is published and stored on the ledger when the coin is created either through
the Mint or Spend transaction.

Private Transactions: Lelantus is introducing two new confidential transaction types to the ledger:

• Mint Transactions. A Mint transaction enables to move base layer coins into the shielded
layer where they can be further spend anonymously. Mint transaction creates a transaction
data txmint and records it on the ledger. The transaction data contains the new created coin
commitment associated with the provided basecoin value and the recipient public address among
other cryptographic information.

• Spend Transactions. A Spend transaction enables to merge, split or redeem previously generated
coins in an anonymous and confidential way. The transaction creates the transaction data txspend

and records it on the ledger. txspend contains the new created transaction output coins and all
required zero-knowledge cryptographic proofs.

Algorithms: Lelantus is a decentralized anonymous payment(DAP) system defined as a tuple of
polynomial-time algorithms:

∏
=(Setup, CreateAddress, Mint, Spend, Receive, Verify).

• Setup: This algorithm takes the security parameter λ and outputs all public parameters used
by different building blocks of the protocol including the commitment scheme, range proofs, one-
out-of-many proofs, public key encryption and digital signature algorithms. The setup process
does not require any trusted procedures.

• CreateAddress: This algorithm takes as input the public parameters pp and generates a new
shielded address pair (addrsk, addrpk).

• Mint: This algorithm takes as input the given public value and basecoin UTXOs which should
be minted and creates the mint transaction txmint.

• Spend: This algorithm takes the input coins which should be spent, the public recipient ad-
dresses and output coin values and generates the spend transaction txspend.

• Verify: This algorithm is used by network validators to check the validity of the txmint and
txspend transactions.

• Receive: This algorithm takes as input a secret address addrsk and scans the ledger to retrieve
all unspent coins sent to the corresponding public address.

We will give the detailed description of all algorithms in Section 4.

Anonymity Sets and List of Serial Numbers: For any given moment

• C-Pool denotes the list of all coin commitments generated by the Mint and Spend transactions.
In practice the set of all coin commitments can be logically split into multiple enumerated
anonymity sets of certain fixed length and each such set can be referred unambiguously by the
private transactions.

• S-Pool denotes the public list of all serial numbers which are revealed when coins are spent.

3.2 Security

For our design we use multiple cryptographic protocols including the proprietary one-out-of-many
proof scheme for double-blinded commitments and the transaction balance proof protocol. Following

8



to the security framework used to prove the security of the original one-out-of-many proof construc-
tion[4], we show that our proposed design for one-out-of-many proofs has perfect completeness,
perfect special-honest zero-knowledge and (m+ 1)-soundness in the sense defined and proven in the
Appendix A. For proving the knowledge soundness property of the transaction balance proof we use
the computational witness-extended emulation model as defined in [22] and used for example in [7].
Informally witness-extended emulation implies that whenever an adversary produces an accepting
proof transcript, then there exists an emulator producing an identically distributed proof with the
same probability of acceptance, but also the corresponding witness. We build a witness-extend em-
ulator for the transaction balance proof in the Appendix B.
In the Appendix C we discuss the security properties of our proposed DAP scheme with respect to
the security framework introduced by Zerocash [3]. This framework captures a realistic threat model
with powerful adversaries who are permitted to include malicious commitments into the commitment
pool, control the choice of transaction inputs or obtain the transactions data in advance. According
to [3], a decentralized anonymous payment system

∏
=(Setup, CreateAddress, Mint, Spend, Receive,

Verify) is secure, if it is Complete and satisfies the Ledger-Indistinguishability, Transaction
Non-Malleability and Balance properties. We will give precise definitions of these security prop-
erties and provide formal proof sketches for all three security properties in the Appendix C.

4 Algorithm Constructions

In this section we provide detailed description of the DAP scheme algorithms.

Setup: In our setup the public parameters pp are comprised of the corresponding public parameters
of the commitment scheme, range proof, one-out-of-many proof, the key-private public key encryp-
tion and digital signatures schemes. All this algorithms operate in the specified prime-order group G
with a scalar field Zp. Setup also samples a cryptographically secure hash function H : {0, 1}∗ −→ Zp.

Setup Algorithm
Inputs: Security parameter Îť.
Outputs: Public parameters pp, a cryptographic hash function H .

1. Choose a cryptographically secure hash function H : {0, 1}∗ → Zp and sample a prime order
group G with a scalar field Zp

2. Compute ppck = (g, h, f) as a tuple of three independent generators of G.
3. Compute the setup parameters of all cryptographic primitives used as design components:
pprp = Setupbp, ppooon = Setupooon, ppenc = Setupenc, ppsig = Setupsig.

4. Output pp = (G,Zp, ppck, pprp, ppooon, ppenc, ppsig) and H.

Note that one-out-of-many proofs are working with commitments generated with respect to ppck.
Also g is used as the fixed generator point in the ppsig and ppenc.

CreateAddress: In our setup we skip the description of the base layer addresses which are used to
transparently exchange base coins (e.g. Bitcoin) and only discuss how the shielded layer addresses
are generated and used for the confidential payments.

CreateAddress Algorithm
Inputs: Security parameter Îť, public parameters pp
Outputs: Address key pair (addrpk, addrsk)

9



1. Compute (P, k) = Kenc(ppenc)
2. Generate s, r ←−R Zp and compute Q = gsfr

3. Compute a proof of representation of the value Q with respect to the generators g and f :
πQ = πdlrep(Q; g, f)

4. Set addrpk = (P,Q, πQ) and addrsk = (k, s, r)
5. Output (addrpk , addrsk)

Mint: This algorithm generates the transaction data txmint which is used to initiate a Mint trans-
action.

Mint Algorithm
Inputs: Public parameters pp, coin value v ∈ [0, vmax), recipient public address addrpk
Outputs: Mint transac";"""date"",""2020-11-09T07:58:51Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""1"",""0"",""1"",""1"",""0"",""10"",""18"",""0"",""17"",""1"",""0"",""0"",""13"",""38"",""20"",""14"",""20"",""10"",""6"",""12"",""18"",""16"",""15"",""19"",""5""
""pdf:PDFVersion"",""1.5""
""xmp:CreatorTool"",""TeX""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dcterms:created"",""2020-11-09T07:58:51Z""
""language"",""en""
""Last-Modified"",""2020-11-09T07:58:51Z""
""dcterms:modified"",""2020-11-09T07:58:51Z""
""dc:format"",""application/pdf; version=1.5""
""Last-Save-Date"",""2020-11-09T07:58:51Z""
""pdf:docinfo:creator_tool"",""TeX""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2020-11-09T07:58:51Z""
""meta:save-date"",""2020-11-09T07:58:51Z""
""pdf:encrypted"",""false""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.20 (TeX Live 2019) kpathsea version 6.3.1""
""modified"",""2020-11-09T07:58:51Z""
""Content-Length"",""452306""
""pdf:hasMarkedContent"",""false""
""Content-Type"",""application/pdf""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.20 (TeX Live 2019) kpathsea version 6.3.1""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""trapped"",""False""
""meta:creation-date"",""2020-11-09T07:58:51Z""
""created"",""2020-11-09T07:58:51Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""30""
""Creation-Date"",""2020-11-09T07:58:51Z""
""resourceName"",""373.pdf""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""2773"",""2987"",""3554"",""3000"",""3216"",""3426"",""2456"",""2752"",""2702"",""2506"",""2650"",""1988"",""2502"",""1793"",""2831"",""3627"",""3165"",""2028"",""2358"",""2201"",""2629"",""1916"",""2513"",""3135"",""2389"",""2787"",""3277"",""2693"",""2995"",""2554""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""producer"",""pdfTeX-1.40.20""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""pdfTeX-1.40.20""
""pdf:docinfo:created"",""2020-11-09T07:58:51Z""
";https://scholar.google.ch/scholar?start=780&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098751-75;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Mize ?i provoc?ri privind activitatea auditorului în era Blockchain;N Farcane, D Deliu ; Audit Financiar, 2020  search.proquest.com;;"Page 1. Mize ?i provoc?ri privind activitatea auditorului în era Blockchain Nr. 1 (157)/2020 45

Audit financiar, XVIII, Nr. 1(157)/2020, 45-72 ISSN: 1583-5812; ISSN on-line: 1844-8801 Mize

?i provoc?ri privind activitatea auditorului în era Blockchain Prof. univ. dr …";Autres articles;;null;;;;https://scholar.google.ch/scholar?start=620&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098835-261;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;"The"" Patching"" Mentality";J Voas ; Computer, 2020  computer.org;;"… is a com- mitment scheme based on crypto gra- phic hash functions. 9 A commitment scheme

allows the sender to commit to a choice while hiding its selec- tions from other receivers. Commit-

ment schemes are widely used in Page 24. BLOCKCHAIN: FROM TECHNOLOGY TO …";Autres articles;;null;;;;https://scholar.google.ch/scholar?start=810&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098884-372;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;OurChain ??????;??? ; ???????????????????, 2020  airitilibrary.com;;"… chain technologies, eg the security issues of using the Oracle mechanism, the fork problem of

using simple payment verification proof (SPV proof) model, and the performance of using atomic

swap contract. Moreover, electronic wallet is the entry point of blockchain systems …";Autres articles;;null;;;;https://scholar.google.ch/scholar?start=920&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098734-32;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Blockchains from non-idealized hash functions;JA Garay, A Kiayias, G Panagiotakos ; Theory of Cryptography Conference, 2020  Springer;;"… Abstract. The formalization of concrete, non-idealized hash function properties sufficient to prove

the security of Bitcoin and related protocols has been elusive, as all previous security analyses

of blockchain protocols have been performed in the random oracle model …";Cité 1 fois;Les 3 versions;[PDF] allquantor.at;https://allquantor.at/blockchainbib/pdf/garay2019iterated.pdf;"
Blockchains from Non-Idealized Hash Functions

Juan A. Garay
Texas A&M University

garay@cse.tamu.edu

Aggelos Kiayias∗

University of Edinburgh
& IOHK

akiayias@inf.ed.ac.uk

Giorgos Panagiotakos
University of Edinburgh
giorgos.pan@ed.ac.uk

June 1, 2020

Abstract

The formalization of concrete, non-idealized hash function properties sufficient to prove the
security of Bitcoin and related protocols has been elusive, as all previous security analyses of
blockchain protocols have been performed in the random oracle model. In this paper we identify
three such properties, and then construct a blockchain protocol whose security can be reduced to
them in the standard model assuming a common reference string (CRS).

The three properties are: collision resistance, computational randomness extraction and iterated
hardness. While the first two properties have been extensively studied, iterated hardness has been
empirically stress-tested since the rise of Bitcoin; in fact, as we demonstrate in this paper, any
attack against it (assuming the other two properties hold) results in an attack against Bitcoin.

In addition, iterated hardness puts forth a new class of search problems which we term iterated
search problems (ISP). ISPs enable the concise and modular specification of blockchain protocols,
and may be of independent interest.

1 Introduction

Blockchain protocols, introduced by Nakamoto [45], are seen as a prominent application of the “proof
of work” (PoW) concept to the area of consensus protocol design. PoWs were initially introduced in the
work of Dwork and Naor [27] as a spam protection mechanism, and subsequently found applications
in other domains such as Sybil attack resilience [26] and denial of service protection [39, 4], prior to
their application to the domain of distributed consensus hinted at early on by Aspnes et al. [3].

A PoW scheme is typified by a proving algorithm, that produces a solution given an input instance,
as well as a verification algorithm that verifies the correctness of the witness with respect to the input.
The fundamental property of a PoW scheme is that the proving algorithm allows for no significant
shortcuts, i.e., it is hard to significantly make it more expedient, and hence any verified solution
implies an investment of computational effort on behalf of the prover. Nevertheless, this “moderate
hardness” property alone has been found to be insufficient for the utilization of PoWs in the context
of various applications and other properties have been put forth to complement it. These include: (i)
amortization resistance, which guarantees that the adversary cannot speed up the computation when
solving multiple PoW instances together, and (ii) fast verification, which suggests a significant gap
between the complexities of the proving and verification algorithms.

Despite the evolution of our understanding of the PoW primitive, as exemplified in recent works
(e.g., [1, 6, 13, 34]), there has been no definitive analysis of the primitive in the context of blockchain

∗Research partly supported by EU Project No.780477, PRIVILEDGE.

1



protocol security in the standard model. Intuitively, PoWs are useful in the consensus setting because
they make message passing (moderately) hard and hence generate stochastic opportunities for the
parties running the protocol to unify their view of the current state of the system. This fundamentally
relies on an assumption about the aggregate computational power of the honest parties, but not on
their actual number, in relation to the computational power of the parties that may deviate from
the protocol (the “Byzantine” parties)—a hallmark of the peer-to-peer setting Bitcoin is designed for.
Despite the fact that the Bitcoin blockchain has been analyzed formally [30, 48, 32, 5], the required
PoW properties have not been fully identified and most of the existing analysis has been carried out
in the random oracle (RO) model [10]. The same is true for a wide variety of other protocols in the
space, including [2, 40, 33].

We stress that despite the fact that the RO model has been widely used in the security analysis
of practical protocols and primitives, it has also received significant criticism. For example, Canetti et
al. [20] showed that there exist implementations of signatures and encryption schemes that are secure
in the RO model but insecure for any implementation of the RO in the standard model; Nielsen [46]
proved that efficient non-committing encryption has no instantiation in the standard model but a
straightforward implementation in the RO model, while Goldwasser and Kalai [38] showed that the
Fiat-Shamir heuristic [29] does not necessarily imply a secure digital signature, which is in contrast
with the result by Pointcheval and Stern [49] in the RO model.

It follows that it is critical to discover security arguments for blockchain protocols that do not
rely on the RO model. Note that we are looking for arguments as opposed to proofs since it is easy
to observe that some computational assumption would still be needed for deriving the security of a
blockchain protocol (recall that blockchain security cannot be inferred information theoretically as it
fundamentally requires at minimum the collision resistance of the underlying hash function). In fact,
the formalization of non-idealized, concrete hash function assumptions sufficient to prove security of
Bitcoin and related protocols has been identified as a “fascinating open question” [18].

Following the above, the main question that motivates the present work is the following:

Is it possible to prove the security of blockchain protocols in the standard model under non-
idealized assumptions about the underlying hash function?

Our results. In this paper we answer the above question in the positive, by identifying three properties
of a hash function family {Hk(¡)}k and then constructing a blockchain protocol whose security can be
reduced to these properties (together with NIZKs; see below) in the standard model.

The first property is collision resistance. Specifically, it should be hard for an adversary given a
random key k, to find two distinct messages m,m′ for which it holds Hk(m) = Hk(m

′). This property
is useful in the blockchain context, since intuitively collision resistance ensures that the hash-chain
maintained by the parties ensures the chronologically correct encoding of information.

The second property of the underlying hash function family is that it should be computational
randomness extracting (CRE). Specifically, there is a way to isolate a finite subset of the domain of the
hash function family so that for any given key k, the function Hk is a (weak) computational randomness
extractor. This property is useful in a few different ways in blockchain security. Firstly, it will help
for symmetry breaking, making sure that parties work concurrently on independent instances of the
underlying problem. Secondly, it will ensure that the problem instances generated by honest parties
(in the form of new blocks), will be sufficiently unpredictable in the eyes of the adversary. Regarding
the plausibility of a CRE hash function, note that pseudorandom functions (PRFs) are known to imply
weak computational randomness extractors [22], and assuming that a hash function implies a PRF is
a fairly standard assumption [7, 25, 42].

The third property asks for the iterative hardness of the underlying hash function as multiple pre-
images with near-zero hashes are stringed together in the form of a chain. This assumption is implicit

2



in the context of the Bitcoin protocol. In fact, as we show, an attack against iterative hardness would
result in an attack against the protocol (assuming a CRE hash function). This implies that there is
(monetary) incentive to break this assumption, which coupled with the the fact that no significant
attacks have been demonstrated in the context of the Bitcoin protocol, establishes iterated hardness
of the underlying hash (in this case SHA-256) as a plausible assumption.1

Armed with the above, we show a novel blockchain protocol whose security can be reduced to the
collision resistance, computational randomness extraction and iterative hardness of the underlying hash
function. Our design adopts Bitcoin’s hash-based blockchain structure, as well as the longest-chain
selection rule. However, contrary to previous analyses of this type of protocols [30, 48, 5] in the RO
model, iterative hardness provides no guarantee that blocks are “non-malleable,” in the sense that it
may be easy to mine multiple blocks on the same height of the chain once you have mined the first one.
Our solution is to instead construct a PoW that is malleable, and leverage it to show a reduction that
breaks the underlying iterated hardness assumption given a common-prefix attack to the blockchain
protocol. In order to achieve this, we also have to hide the block witnesses by taking advantage of NIZK
proofs with efficient simulation, thus managing to efficiently extract a sequence of iterated witnesses
despite the fact that the attacker may not produce consecutive blocks.

In order to describe and analyze the protocol modularly, we put forth a new class of search prob-
lems, which we call iterated search problems (ISP). Taking advantage of ISPs one can produce concise
and modular specifications of blockchain protocols, as evidenced by the description of our protocol
(Section 4.3); as such, ISPs can be of independent interest.

In a nutshell, an ISP instance is defined by a problem statement set X, a witness set W and a
relation R that determines when a witness satisfies the problem statement. The ISP is also equipped
with a successor algorithm S that given a statement x and a witness w, can produce a successor
problem statement x′; a solving algorithm M which given an initial problem statement x can find a
sequence of witnesses; and a verification algorithm V that takes a problem statement x and witness w
and outpus 1 if (x,w) ∈ R, and 0 otherwise. Each witness corresponds to the next statement defined
by algorithm S on input the previous statement and witness, starting from x. The iterated hardness
property of the ISP asks that if the solving algorithm takes t steps to solve k instances iteratively, no
alternative algorithm can substantially speed this process up and produce k iterative solutions with
non-negligible probability.

We perform our analysis in the static-adversary setting with synchronous rounds as in [30], and
prove that our protocol can thwart adversaries and environments that roughly take less than half the
computational steps the honest parties collectively are allowed per round. To our knowledge this is
the first work that achieves such a result in the permissionless setting without idealized assumptions
and no PKI (see related work). In principle we can extend our results to the ∆-synchronous setting
of [48], following the techniques found in Section 7 of [31]; we leave the details to the full version of
the paper. Further, we leave as an open question the extension of our results to the dynamic setting
of [32], as well as matching the (less than) 50% threshold on adversarial computational power of the
Bitcoin blockchain which can be shown in the RO model.

Related work. A related but distinct notion of hardness is sequential (i.e., non-parallelizable) iterated
hardness. This notion has been considered as early as [50], mainly in the domains of timed-release
cryptography [15] and protocol fairness [35], and recently formalized in [14] under the term iterated
sequential functions (ISF) in the context of Verifiable Delay Functions (VDFs). In addition, a number
of candidate hard problems have been proposed, including squaring a group element of composite-
modulus groups [50], hashing, and computing the modular square root of an element on a prime order
group [43]. Nevertheless, we observe that if we base the Bitcoin protocol on an ISF (or VDF for that

1Refer to Section 3 for further discussion on this assumption.

3



matter) it will be insecure. The fundamental issue is that it does not allow for parallelization, which
is crucial for proving the security of any (Bitcoin-like) blockchain protocol. Indeed, an attacker with a
single processor whose sequential speed is slightly faster than that of honest parties, can outperform
potentially hundreds of them and mine longer chains first.

Another notion related to iterative hardness is the notion of “correlation intractability” (CI) [18].
The difference is that while CI only bounds the success probability in solving a single challenge, ISP
fundamentally requires multiple instances. Further, while CI talks about any sparse relation, the
iterative hardness definition is concerned with a specific non-sparse relation.

Finally, another related work focusing on sufficient conditions for the consensus problem in the
permissionless setting (and no PKI, while matching the less than 50% threshold on adversarial com-
putational power) is [34], which introduced the concept of signatures of work (SoW) as the basic
underlying assumption. The only known implementation of SoWs however is in the RO model, hence
it is unknown (and an interesting open question) whether SoWs can be realized under non-idealized
hash function assumptions like the ones we consider here.

Organization of the paper. The basic computational model, definitions and cryptographic building
blocks used by our constructions are presented in Section 2. The three hash-function properties that
the security of our blockchain protocol is going to be based on are presented in Section 3. Section 4 is
dedicated to the new blockchain protocol realizing a transaction ledger. The presentation of the protocol
is modularized by first presenting ISP (Section 4.1) and then a high-level technical summary of the rest
of the paper (Section 4.2). Details follow, namely, an ISP-based blockchain protocol (Section 4.3) and
a security notion for ISPs and showing it sufficient to prove our protocol secure (Sections 4.4 and 4.5,
resp.). The construction of a secure ISP based on the hash-function properties presented in Section 3
is given in Section 4.6. Finally, the necessity of iterated hardness to prove the Bitcoin protocol secure
is presented in Section 5.

2 Preliminaries

In this section we present basic notation and definitions that we will use in the rest of the paper.
For k ∈ N+, [k] denotes the set {1, . . . , k}. For strings x, z, x||z is the concatenation of x and z, and

|x| denotes the length of x. We denote sequences by (ai)i∈I , where I is the index set which will always
be countable. For a set X, x ← X denotes sampling a uniform element from X. For a distribution
U over a set X, x ← U denotes sampling an element of X according to U . By Um we denote the
uniform distribution over {0, 1}m. For random variable X, we denote by H∞(X) the min-entropy of
X. We denote the statistical distance between two random variables X,Z with range U by ∆[X,Y ],
i.e., ∆[X,Z] = 1

2

∑
v∈U |Pr[X = v]−Pr[Z = v]|. A random variable ensemble (Xi)i∈I , is a sequence of

random variables indexed by I. By (Xi)i ≈ (Yi)i (resp.
c≈) we denote that two ensembles are statistical

(resp. computational) indistinguishable. We let Îť denote the security parameter.

Protocol execution and security model. In this paper we will follow a more concrete approach [8,
11, 35, 12] to security evaluation. We will use functions t, Îľ, whose range is N,R, respectively, and have
possibly many different arguments, to denote concrete bounds on the running time (number of steps)
and probability of adversarial success of an algorithm in some given computational model, respectively.
When we speak about running time this will include the execution time plus the length of the code
(cf. [12]; note also that we will be considering uniform machines). We will always assume that t is a
polynomial in the security parameter Îť, although we will sometimes omit this dependency for brevity.

Instead of using interactive Turing machines (ITMs) as the underlying model of distributed com-
putation, we will use (interactive) RAMs. The reason is that we need a model where subroutine access

4



and simulation do not incur a significant overhead. ITMs are not suitable for this purpose, since one
needs to account for the additional steps to go back-and-forth all the way to the place where the
subroutine is stored. A similar choice was made by Garay et al. [35]; refer to [35] for details on using
interactive RAMs in a UC-like framework. Given a RAM M , we will denote by StepsM (1Îť, x) the
random variable that corresponds to the number of steps taken by M given input 1Îť and x. We will
say that M is t-bounded if it holds that Pr[StepsM (1λ, x) ≤ t(λ)] = 1.

Finally, we remark that in our analyses there will be asymptotic terms of the form negl(Îť) and
concrete terms; throughout the paper, we will assume that Îť is large enough to render the asymptotic
terms insignificant compared to the concrete terms.

The Bitcoin backbone model. In this section, we give an overview of the security model that we
are going to use throughout this work, introduced in [34]. This model is a variant of the synchronous
model presented in [30] for the analysis of the Bitcoin backbone protocol, extended to accommodate
a standard-model analysis of PoW-based blockchain protocols. In turn the model of [30] is based on
Canetti’s formulation of “real world” execution for multi-party cryptographic protocols [16, 17].

An execution of some protocol Π is defined with respect to an “environment” program Z, a “control”
program C, and an “adversary” program A. At a high level, Z is responsible for providing inputs to
and obtaining outputs from different instances of Π, C is responsible for supervising the spawning
and communication of all these programs, and A aims to disrupt the goals set by the protocol. The
programs in question can be thought of as “interactive RAMs” communicating through registers in a
well-defined manner.

We consider executions where the set of of parties {P1, ..., Pn} running Π is fixed and hardcoded to
C. Moreover, we consider a “hybrid” model of computation [19], where the adversary A as well as all
parties in the execution can access a number of “ideal” functionalities as subroutines; the functionalities
are also modeled as RAMs and are presented later in detail. Initially Z is activated. Z can make special
requests that result in the spawning of different parties and A. In turn, A can corrupt different parties
by sending messages of the form (Corrupt, Pi) to C, with the limitation that the total number of
parties corrupted should be at most t; t is a parameter of the execution. We assume an active static
adversary.

We are working on the synchronous setting of computation, where the current round is known to
all parties, and messages sent at one round are received at the beginning of the next one. The influence
of the adversary in the network is going to be actively malicious following standard cryptographic
practice. While we assume the adversary to be rushing and communication not to be authenticated,
messages sent by honest parties are guaranteed to reach their destination.

All the above concerns are captured by the diffusion functionality Fdiff . The functionality maintains
a Receive string defined for each party Pi. A party is allowed at any moment to fetch the messages
sent to it at the previous round that are contained in its personal Receive string. Moreover, when
the functionality receives an instruction to diffuse a message m from party Pi, it marks the party as
complete for the current round, and forwards the message to the adversary; note that m is allowed to
be empty. At any moment, the adversary A is allowed to specify the contents of the Receive string for
each party Pi. The adversary has to specify when it is complete for the current round. When all parties
are complete for the current round, the functionality inspects the contents of all Receive tapes and
includes any messages that were diffused by the parties in the current round but not contributed by the
adversary to the Receive tapes. The variable round is then incremented. In the protocol description,
we will use Diffuse as the message transmission command.

In addition, we assume the existence of a common reference string (CRS) functionality that samples
the CRS in a trusted manner from a known efficiently samplable distribution, and is available for all
parties to fetch at the start of the execution. Note, that from our modeling it is implicit that the

5



adversary and the honest parties get access to the CRS at the same round.
Based on the above, we denote by {viewP,t,n

Π,A,Z(z)}z∈{0,1}∗ the random variable ensemble that
corresponds to the view of party P at the end of an execution where Z takes z as input. We will consider
stand-alone executions, hence z will always be of the form 1Ν, for Ν ∈ N. For simplicity, to denote this
random variable ensemble we will use viewP,t,n

Π,A,Z . By viewt,n
Π,A,Z we denote the concatenation of the

views of all parties. The probability space where these variables are defined depends on the coins of
all honest parties, A, Z and the CRS generation procedure.

Furthermore, we are going to define a predicate on executions and prove our properties in disjunction
with this predicate, i.e., either the property holds or the execution is not good.

Definition 1. Let (tA, θ)-good be a predicate defined on executions in the hybrid setting described
above. Then E is (tA, θ)-good, where E is one such execution, if

the total number of steps taken by A and Z per round is no more than tA;2

the adversary sends at most θ messages per round.

Definition 2. Given a predicate Q and bounds tA, θ, t, n ∈ N, with t < n, we say that protocol Π
satisfies property Q for n parties assuming the number of corruptions is bounded by t, provided that for
all PPT Z,A, the probability that Q(viewt,n

Π,A,Z) is false and the execution is (tA, θ)-good is negligible
in Îť.

Cryptographic primitives and building blocks. We will make use of the following cryptographic
primitives: Cryptographic hash functions, (computational) randomness extractors [47, 22], robust non-
interactive zero-knowledge (NIZK) [51], and iterated sequential functions [14].

Randomness extractors. We make use of the notion of weak computational randomness extractors,
as formalized in [22].

Definition 3. An extractor is a family of functions Ext = {Extλ : {0, 1}n(λ)×{0, 1}d(λ) → {0, 1}m(λ)}λ∈N,
where n(¡), d(¡) and m(¡) are polynomials. The extractor is called weak k(¡)-computational if ExtΝ is
PPT, and for all efficiently samplable probability ensembles {XÎť}Îť with min-entropy k(Îť):

(ExtΝ(XΝ, Ud(Ν)))Ν∈N
c≈ (Um(λ))λ∈N

where computational indistinguishability is defined w.r.t. a non-uniform distinguisher.

Robust non-interactive zero-knowledge. We make use of the following composable notion of
non-interactive zero-knowledge, introduced in [51].

Definition 4. Given an NP relation R, let L = {x : ∃w s.t. R(x,w) = 1}. Π = (q, P, V, S =
(S1, S2), E)) is a robust NIZK argument for L, if P, V, S,E ∈ PPT and q(¡) is a polynomial such that
the following conditions hold:
1. Completeness. For all x ∈ L of length λ, all w such that R(x,w) = 1, and all Ω ∈ {0, 1}q(λ),

V(Ω, x,P(Ω, w, x))] = 1.

2. Multi-Theorem Zero-knowledge. For all PPT adversaries A, we have that Real(λ) ≈ Sim(λ),
where

Real(λ) = {Ω← {0, 1}q(λ); out← AP(Ω,·,·)(Ω);Output out},
Sim(λ) = {(Ω, tk)← S1(1λ); out← AS′2(Ω,·,·,tk)(Ω);Output out},

and S′2(Ω, x, w, tk)
def
= S2(Ω, x, tk) if (x,w) ∈ R, and outputs failure if (x,w) 6∈ R.

2The adversary cannot use the running time of honest parties that it has corrupted; it is activated instead of them
during their turn.

6



3. Extractability. There exists a PPT algorithm E such that, for all PPT A,

Pr

[
(Ω, tk)← S1(1λ); (x, π)← AS2(Ω,·,tk)(Ω);w ← E(Ω, (x, π), tk) :

R(x,w) 6= 1 ∧ (x, π) 6∈ Q ∧ V(Ω, x, π) = 1

]
≤ negl(λ)

where Q contains the successful pairs (xi, πi) that A has queried to S2.

As in [28], we also require that the proof system supports labels. That is, algorithms P,V, S,E take
as input a label φ, and the completeness, zero-knowledge and extractability properties are updated
accordingly. This can be achieved by adding the label φ to the statement x. In particular, we write
Pφ(Ω, x, w) and Vφ(Ω, x, π) for the prover and the verifier, and Sφ2 (Ω, x, tk) and Eφ(Ω, (x, π), tk) for the
simulator and the extractor.

Theorem 5 ([51]). Assuming trapdoor permutations and a dense cryptosystem exist, robust NIZK
arguments exist for all languages in NP.

Iterated sequential functions. We recite the hardness definition introduced in [14]:

Definition 6. f : X → Y is a (t, ε)-sequential function for λ = O(log(|X|)), if the following conditions
hold:
1. There exists an algorithm that for all x ∈ X evaluates f in parallel time t using poly(log(t), Ν)

processors.

2. For all A that run in parallel time strictly less than (1− ε) · t with poly(t, λ) processors:

Pr[yA = f(x)|yA ← A(λ, x), x← X] < negl(λ).

Definition 7. Let g : X → X be a function which satisfies (t, ε)-sequentiality. A function f : N×X →
X defined as f(k, x) = g(k)(x) = g ◦ g ◦ . . . ◦ g is called an iterated sequential function (with round
function g), if for all k = 2o(λ), the function h : X → X such that h(x) = f(k, x) is (kt, ε)-sequential.

Robust public transaction ledgers. Our work is concerned with necessary and sufficient conditions
to implement a public transaction ledger. Next, we give the transaction ledger definition introduced
in [30], with Liveness slightly strengthened, as in [48].

A public transaction ledger is defined with respect to a set of valid ledgers L and a set of valid
transactions T , each one possessing an efficient membership test. A ledger x ∈ L is a vector of
sequences of transactions tx ∈ T . Ledgers correspond to chains of blocks in the Bitcoin protocol. It is
possible for the adversary to create two transactions that are conflicting; valid ledgers must not contain
conflicting transactions. Moreover, it is assumed that in the protocol execution there also exists an
oracle Txgen that generates valid transactions, and is unambiguous, i.e., the adversary cannot create
transactions that come in ‘conflict’ with the transactions generated by the oracle. A transaction is
called neutral if there does not exist any transactions that come in conflict with it. Any ledger that
contains neutral or non-conflicting transactions is considered to be valid.

Definition 8. A protocol Π implements a robust public transaction ledger if it organizes the ledger as
a chain of blocks of transactions and it satisfies the following two properties:

Consistency (parameterized by the “depth” parameter k ∈ N): If in a certain round an honest
player reports a ledger that contains a transaction tx in a block more than k blocks away from the
end of the ledger, where k ∈ N is the “depth” parameter (such transactions are called stable), then
tx will be reported as stable and in the same position in the ledger by any honest player from this
round on.

7



Liveness (parameterized by k, u ∈ N—the “depth” and “wait time” parameters, resp.): For every u
consecutive rounds, there exists a round and an honest party, such that the transactions given as
input to that party at this round that are either (i) issued by Txgen or (ii) neutral, will be reported
by all honest parties as stable at the end of this round interval.

3 Hash Functions Properties for Blockchain Security

In this section we describe the three falsifiable hash function properties that the security of our protocol
is going to be based on. Two of these properties, namely, collision resistance [23] and weak computa-
tional randomness extraction [22], have been extensively studied in the hash function literature. The
third one is new, and has to do with the moderate hardness of computing sequences of small hashes.
We proceed to discuss each of the properties in detail.

We start with collision resistance. Most known blockchain protocols make use of a collision-resistant
hash function in order to establish basic structural properties, e.g., that the adversary cannot create a
blockchain that contains a cycle. That is exactly the way we are going to use this property here. We
will use the following security definition [37].3

Definition 9. Let H = {{Hk : {0, 1}∗ → {0, 1}λ}k∈K(λ)}λ∈N be a hash-function family, and A be
a PPT adversary. Then H is collision resistant if and only if for any Ν ∈ N and corresponding
{Hk}k∈K in H,

Pr
k←K

[(m,m′)← A(1λ, k) : (m 6= m′) ∧ (Hk(m) = Hk(m
′))] ≤ negl(λ).

Our second security assumption has to do with the existence of a fixed-length-input hash function
family that is a weak computational randomness extractor. As explained in [22], this assumption
is weaker than assuming a fixed-length-input pseudorandom function family (FI-PRF), a common
assumption in the hash function literature [7, 25, 42]. We adapt the definition of a weak computational
randomness extractor (Definition 3) to the context of a hash function family.

Definition 10. Let H = {{Hk : {0, 1}dλ → {0, 1}λ}k∈K(λ)}λ∈N, for some d ∈ N, d > 1, be a fixed-
length input hash-function family. H is a computational randomness extracting (CRE) hash
function family if for some c ∈ N+, c < d, the function family E = {Eλ : {0, 1}(c+1)λ×{0, 1}(d−c−1)λ →
{0, 1}Îť}Îť, where EÎť(x, i)

def
= Hk(x||i), is a weak (cÎť)-computational extractor (Definition 3), for any

k ∈ K(Ν).

This property will be useful in our protocol for two reasons. First, to ensure that the distributions of
blocks generated by honest parties are identical and independent. Second, to establish that the blocks
generated by honest parties, and which the adversary has the choice to mine on, look sufficiently
random and hence the moderate hardness of the underlying problem is preserved.

Our third assumption about hash functions has to do with the hardness of finding sequences of
small hashes in the hash-based PoW construction proposed for Bitcoin. In more detail, given the hash
x of some block, computing a valid PoW for this construction consists of finding witnesses w1, w2 such
that Hk(Hk(x||w1)||w2) < T . In turn, our hardness property requires that any adversary should take
a number of steps proportional to the number of PoWs computed, when these PoWs form a sequence
starting from a uniformly random string x. The property is parameterized by t, the number of steps
the adversary takes to generate each PoW on average.

3Throughout our exposition for simplicity we will assume that H takes one step to be evaluated. We note that our
results can be generalized to the case where H takes more time.

8



Definition 11. Let H = {{Hk : {0, 1}dλ → {0, 1}λ}k∈K(λ)}λ∈N, for some d ∈ N, d > 1, be a fixed-
length input hash-function family, and let T be some hardness parameter. H is t-iteratively hard iff
there exists a polynomial k0(·), such that for any PPT RAM (A1,A2), λ ∈ N, and k ≥ k0(λ), it holds
that:

Pr
σ←K(λ);
x0←[0,T ]

 st← A1(1λ, σ); (wi, w
′
i)i∈[k] ← A2(1λ, st, x0) :

∀i ∈ [k] : xi := Hσ(Hσ(xi−1||wi)||w′i) < T

∧ StepsA2
(st, x0) < k ¡ t

 ≤ negl(λ)

Our choice to base the security of our protocol on the iterated hardness of Bitcoin’s PoW construc-
tion is not accidental. The fact that any attack on iterated hardness implies an attack on Bitcoin,
as we show in Section 5, as well as the fact that no attacks have been publicly disclosed in the last
ten years that this construction has been actively used in Bitcoin, constitute empirical evidence in its
favor. Note that this would not necessarily be the case if we based security on a stronger hardness
property that was not necessary to prove Bitcoin secure, as it would then be possible that an attack
against the property is known and the adversary does not have any incentive to reveal/deploy it, as it
does not affect the security of the protocol in any way.4

We note that to prove the security of our protocol both properties in Definitions 10 and 11 should
hold for the same hash function and for suitable parameters 5, which we discuss in the next section;
coll";"""date"",""2020-06-01T21:30:40Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2020-06-01T21:30:40Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016) kpathsea version 6.2.2""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2020-06-01T21:30:40Z""
""created"",""2020-06-01T21:30:40Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-06-01T21:30:40Z""
""resourceName"",""garay2019iterated.pdf""
""Author"",""""
""producer"",""pdfTeX-1.40.17""
""pdf:docinfo:producer"",""pdfTeX-1.40.17""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""2"",""1"",""2"",""0"",""3"",""8"",""4"",""2"",""1"",""3"",""0"",""15"",""26"",""36"",""5"",""11"",""20"",""19"",""26"",""64"",""20"",""6"",""42"",""12"",""6"",""10"",""0"",""21"",""29"",""29"",""11"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2020-06-01T21:30:40Z""
""Last-Modified"",""2020-06-01T21:30:40Z""
""dcterms:modified"",""2020-06-01T21:30:40Z""
""title"",""""
""Last-Save-Date"",""2020-06-01T21:30:40Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2020-06-01T21:30:40Z""
""meta:save-date"",""2020-06-01T21:30:40Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016) kpathsea version 6.2.2""
""Content-Length"",""779540""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""34""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""2614"",""3749"",""3737"",""3460"",""3632"",""2624"",""2725"",""2971"",""3193"",""3113"",""2929"",""3625"",""3299"",""1437"",""1671"",""2615"",""3131"",""2585"",""2824"",""3519"",""2442"",""2961"",""3319"",""1883"",""2883"",""2525"",""2770"",""2987"",""2932"",""3284"",""2655"",""3018"",""2943"",""2937""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-06-01T21:30:40Z""
";https://scholar.google.ch/scholar?start=580&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098738-41;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Inclusăo digital e blockchain como instrumentos para o desenvolvimento econômico: Digital inclusion and blockchain as instruments for economic development;DB Friedrich, JHM Philippi ; International Journal of Digital …, 2020  journal.nuped.com.br;;"… International Journal of Digital Law, Belo Horizonte, ano 1, n. 1, p. 97-115, jan./abr. 2020 97

Inclusăo digital e blockchain como instrumentos para o desenvolvimento econômico Digital

inclusion and blockchain as instruments for economic development …";Cité 2 fois;;[PDF] nuped.com.br;https://journal.nuped.com.br/index.php/revista/article/download/7/6;"
INTERNATIONAL JOURNAL OF DIGITAL LAW ! IJDL
ano 01 . n. 01 . janeiro/abril 2020 - Publicação quadrimestral 

DOI: 10.47975/digital.law.vol.1.n.1

01
ISSN 2675-7087

International Journal of  
DIGITAL LAW

IJDL



Todos os direitos reservados. É proibida a reprodução total ou parcial, de qualquer forma ou por qualquer meio eletrônico ou mecânico, 
inclusive atravÊs de processos xerogråficos, de fotocópias ou de gravação, sem permissão por escrito do possuidor dos direitos de cópias 
(Lei nÂş 9.610, de 19.02.1998).

LuĂ­s ClĂĄudio Rodrigues Ferreira
Presidente e Editor

Av. Afonso Pena, 2770 – 15º andar – Savassi – CEP 30130-012 – Belo Horizonte/MG – Brasil – Tel.: 0800 704 3737
www.editoraforum.com.br  /  E-mail: editoraforum@editoraforum.com.br

Impressa no Brasil / Printed in Brazil / DistribuĂ­da em todo o TerritĂłrio Nacional

Os conceitos e opiniĂľes expressas nos trabalhos assinados sĂŁo de responsabilidade exclusiva de seus autores.

Editor-Chefe
Prof. Dr. Emerson Gabardo, PontifĂ­cia Universidade CatĂłlica do ParanĂĄ e 

Universidade Federal do Paraná, Curitiba – PR, Brasil
 

Editores Associados
Prof. Dr. Alexandre Godoy Dotta, Instituto de Direito Romeu Felipe Bacellar, Curitiba – PR, Brasil

Prof. Dr. Juan Gustavo CorvalĂĄn, Universidad de Buenos Aires, Buenos Aires, Argentina
 

Editores Adjuntos
Me. Fábio de Sousa Santos, Faculdade Católica de Rondônia, Porto Velho – RO, Brasil

Me. Iggor Gomes Rocha, Universidade Federal do Maranhão, São Luís – MA, Brasil
Me. Lucas Bossoni Saikali, Pontifícia Universidade Católica do Paraná, Curitiba – PR, Brasil

 
Presidente do Conselho Editorial

Profa. Dra. Sofia Ranchordas, University of Groningen, Groningen, Holanda

 Conselho Editorial
Prof. Dr. AndrĂŠ Saddy, Universidade Federal Fluminense, NiterĂłi, Brasil

Profa. Dra. Annappa Nagarathna, National Law School of India, Bangalore, Índia
Profa. Dra. Cristiana Fortini, Universidade Federal de Minas Gerais, Belo Horizonte, Brasil

Prof. Dr. Daniel Wunder Hachem, PontifĂ­cia Universidade CatĂłlica do ParanĂĄ e Universidade Federal do ParanĂĄ, Curitiba, Brasil
Profa. Dra. Diana Carolina Valencia Tello, Universidad del Rosario, BogotĂĄ, ColĂ´mbia

Prof. Dr. Endrius Cocciolo, Universitat Rovira i Virgili, Tarragona, Espanha
Profa. Dra. Eneida Desiree Salgado, Universidade Federal do ParanĂĄ, Brasil

Profa. Dra. Irene Bouhadana, UniversitÊ Paris 1 PanthÊon-Sorbonne, Paris, França
Prof. Dr. JosĂŠ SĂŠrgio da Silva CristĂłvam, Universidade Federal de Santa Catarina, FlorianĂłpolis, Brasil

Prof. Dr. Mohamed Arafa, Alexandria University, Alexandria, Egito
Prof. Dra. Obdulia Taboadela Álvarez, Universidad de A Coruùa, A Coruùa, Espanha

Profa. Dra. Vivian Cristina Lima Lopez Valle, PontifĂ­cia Universidade CatĂłlica do ParanĂĄ, Curitiba, Brasil
Prof. Dr. William Gilles, UniversitÊ Paris 1 PanthÊon-Sorbonne, Paris, França

Profa. Dra. Lyria Bennett Moses, University of New South Wales, Kensington, AustrĂĄlia

IN61 International Journal of Digital Law – IJDL. – ano 1, n. 1 
(abr. 2020) –.– Belo Horizonte: Fórum, 2020-.

Quadrimestral; Publicação eletrônica
ISSN: 2675-7087
 
1. Direito. 2. Direito Digital. 3.Teoria do Direito. I. FĂłrum.

CDD: 340.0285
CDU: 34.004

IJDL – INTERNATIONAL JOURNAL OF DIGITAL LAW

Coordenação editorial: Leonardo Euståquio Siqueira Araújo
 Aline Sobreira
Capa: Igor Jamur 
Projeto grĂĄfico: Walter Santos



International Journal of Digital Law, Belo Horizonte, ano 1, n. 1, p. 97-115, jan./abr. 2020 97

InclusĂŁo digital e blockchain como 
instrumentos para o desenvolvimento 
econĂ´mico

Digital inclusion and blockchain as 
instruments for economic development

Denise Bittencourt Friedrich*

Universidade de Santa Cruz Sul (Santa Cruz Sul, Rio Grande do Sul, Brasil)
d-friedrich@hotmail.com

https://orcid.org/0000-0002-7612-2667

Juliana Horn Machado Philippi**

PontifĂ­cia Universidade CatĂłlica do ParanĂĄ (Curitiba, ParanĂĄ, Brasil)
julianahmachado@gmail.com

https://orcid.org/0000-0003-4453-3565

Recebido/Received: 06.03.2020/ March 6th, 2020

Aprovado/Approved: 18.04.2020/ April 18th, 2020

Resumo: A partir do mĂŠtodo hipotĂŠtico-dedutivo, mediante pesquisa bibliogrĂĄfica, o presente artigo tem 
como objetivo principal o estudo da possibilidade de a inclusĂŁo digital e os usos de blockchain servirem 
como instrumentos para o desenvolvimento, considerando-se nĂŁo apenas a liberdade, mas tambĂŠm 
a igualdade e a busca pela felicidade do povo. No primeiro momento, analisa-se o desenvolvimento, 
com ĂŞnfase para a visĂŁo de Amartya Sen, no sentido de que o desenvolvimento nĂŁo se baseia apenas 
em indicadores econĂ´micos, sendo medido tambĂŠm de acordo com o desenvolvimento humano, com 
plenitude das liberdades. No entanto, pondera-se que nĂŁo ĂŠ suficiente atrelar o desenvolvimento 
apenas Ă s liberdades, devendo-se primar tambĂŠm pela igualdade e felicidade. No segundo tĂłpico, 
considera-se o avanço das tecnologias de informação e comunicação (TICs) na sociedade atual, com o 
entendimento de que a inclusĂŁo digital tem sido considerada como um direito fundamental, por estar 

1  2

Como citar este artigo/How to cite this article: FRIEDRICH, Denise Bittencourt; PHILIPPI, Juliana Horn 
Machado. InclusĂŁo digital e blockchain como instrumentos para o desenvolvimento econĂ´mico. 
International Journal of Digital Law, Belo Horizonte, ano 1, n. 1, p. 97-115, jan./abr. 2020.

*  Professora do PPGD/UNISC (Santa Cruz Sul, Rio Grande do Sul, Brasil). Doutora em Direito Mestra em 
Direito – Políticas Públicas de Inclusão Social – pela UNISC. Especialista em Direito Constitucional – 
ĂŞnfase em Direito Municipal pela Universidade Luterana do Brasil.

** Mestranda em Direito EconĂ´mico e Desenvolvimento pela PontifĂ­cia Universidade CatĂłlica do ParanĂĄ 
(Curitiba, ParanĂĄ, Brasil). Membro do NĂşcleo de Desenvolvimento em PolĂ­ticas PĂşblicas e Desenvolvimento 
Humano da PUCPR. Advogada.

DOI: 10.47975/IJDL/1friedrich



International Journal of Digital Law, Belo Horizonte, ano 1, n. 1, p. 97-115, jan./abr. 202098

DENISE BITTENCOURT FRIEDRICH, JULIANA HORN MACHADO PHILIPPI

intimamente relacionada à dignidade da pessoa humana, mínimo existencial e melhoria das condiçþes 
de vida. No terceiro momento, tem-se uma visĂŁo geral acerca das redes de blockchain, passando por 
seus principais usos, com destaque para a possibilidade de seu uso para fins humanitĂĄrios, como a 
realização de identidades digitais, o que tem beneficiado especialmente os refugiados e comunidades 
carentes. Com isso, conclui-se que a inclusĂŁo digital e as redes de blockchain podem ser importantes 
ferramentas para o desenvolvimento, pois seus usos podem refletir na melhoria da qualidade de vida, 
na dignidade das pessoas, bem como nas liberdades e igualdade.

Palavras-chave: Desenvolvimento. Tecnologia. Dignidade. InclusĂŁo digital. Blockchain.

Abstract: Based on the hypothetical-deductive method, through bibliographic research, this article has 
as main objective the study of the possibility of digital inclusion and the uses of blockchain serving 
as instruments for development, considering not only freedom, but also equality and the search for 
people’s happiness. In the first moment, development is analyzed, with emphasis on Amartya Sen’s 
view, in the sense that development is not based only on economic indicators, but is also measured 
according to human development, with full freedoms. However, it is considered that it is not enough 
to tie development only to freedoms, because equality and happiness should also be emphasized. 
The second topic considers the advancement of information and communication technologies (ICTs) in 
the current society, with the understanding that digital inclusion has been considered a fundamental 
right, as it is closely related to the dignity of the human person, existential minimum and improving 
living conditions. In the third moment, there is an overview about blockchain networks, going through 
their main uses, with emphasis on the possibility of their use for humanitarian purposes, such as the 
realization of digital identities, which has especially benefited refugees and communities needy. Thus, 
it is concluded that digital inclusion and blockchain networks can be important tools for development, 
as their uses can reflect in improving the quality of life, in the dignity of people, as well as in freedoms 
and equality.

Keywords: Development. Technology. Dignity. Digital inclusion. Blockchain.

Sumário: 1 Introdução – 2 Desenvolvimento em razão das liberdades, da igualdade e da felicidade – 3 
O direito fundamental à inclusão social – 4 Possíveis usos da blockchain para impulsionar a dignidade 
da pessoa humana – 5 Considerações finais – Referências

1 Introdução

As tecnologias de informação e comunicação (TICs) estão tão presentes na 

vida das pessoas, especialmente com o uso da internet, se mostrando cada vez 

mais ubĂ­qua com os smartphones, smartwatches, internet das coisas (internet of 

things – IoT),1 inteligência artificial, machine learning, e-commerce, entre outros. A 

digitalização e a virtualização são realidades no mundo atual, e não se resumem às 

mĂ­dias e Ă s redes sociais, mas notadamente por meio da possibilidade de trabalho 

remoto, ensino à distância, internet banking, e tambÊm os criptoativos.

Para enfrentar o problema de pesquisa, consistente na indagação quanto à 

possibilidade de se entender que a inclusĂŁo digital e a blockchain ser consideradas 

como instrumentos para o desenvolvimento, estrutura-se o raciocĂ­nio com anĂĄlise 

da doutrina especĂ­fica sobre desenvolvimento, tendo como referenciais teĂłricos 

Amartya Sen e Emerson Gabardo, com a consideração de que o desenvolvimento 

1 FORNASIER, Mateus de Oliveira. The applicability…, p. 297.



International Journal of Digital Law, Belo Horizonte, ano 1, n. 1, p. 97-115, jan./abr. 2020 99

INCLUSĂŁO DIGITAL E BLOCKCHAIN COMO INSTRUMENTOS PARA O DESENvOLvIMENTO ECONĂ´MICO

nĂŁo se limita Ă  parte econĂ´mica, haja vista que engloba tambĂŠm as liberdades e a 

promoção da igualdade e da felicidade do povo. No segundo momento, estuda-se 

a inclusĂŁo digital, calcada no acesso Ă  internet e considerada como um direito 

fundamental, passando-se, apĂłs, para o exame dos aspectos gerias da blockchain 

e a seus possĂ­veis usos, especialmente humanitĂĄrios.

A hipĂłtese do presente estudo ĂŠ a possibilidade de melhorias na qualidade 

de vida das pessoas em razĂŁo da inclusĂŁo digital, ou seja, o acesso Ă  internet 

pelos cidadĂŁos, bem como pelo emprego de blockchain, com impactos positivos 

no desenvolvimento. A pesquisa foi feita pelo mĂŠtodo hipotĂŠtico-dedutivo, mediante 

pesquisa bibliogrĂĄfica, com o objetivo de verificar o enquadramento da inclusĂŁo 

digital e da blockchain como instrumentos para o desenvolvimento.

2 Desenvolvimento em razĂŁo das liberdades, da igualdade 
e da felicidade

A palavra “desenvolvimento” é um tanto quanto vaga e pode apresentar 

diversos significados. Refere-se nĂŁo a um estado, mas sim a um processo, tratando 

de fenômeno dinâmico, na busca pelo estado desenvolvido. Comumente o termo 

desenvolvimento ĂŠ associado ao crescimento econĂ´mico, tendo como nĂşcleos 

critĂŠrios quantitativos, referentes a crescimento e renda per capita, por exemplo, 

numa visĂŁo gradualista.2

Nessa visĂŁo, de acordo com Joseph Alois Schumpeter, o desenvolvimento 

econômico decorre do processo de destruição e reconstrução resultantes das 

inovaçþes no sistema econômico, com a realização de mudanças e descontínuas, 

com novas combinaçþes. Englobando cinco situaçþes, com introdução de: a) um 

novo produto que os consumidores não conheçam, ou uma nova qualidade; b) novo 

mÊtodo de produção; c) novo mercado; d) nova fonte de matÊria-prima ou de bens 

semimanufaturados; e) nova organização de qualquer indústria, seja por meio de 

monopólio ou fragmentação de uma posição de monopólio.3

HĂĄ de se diferenciar que o crescimento ĂŠ uma das etapas do desenvolvimento 

econĂ´mico, nĂŁo se confundindo com este. O crescimento ĂŠ imanente ao 

desenvolvimento econĂ´mico, em especial na economia industrial, em que o 

empresårio precisa reinvestir seus lucros para aperfeiçoar os mÊtodos de produção e, 

assim, possibilitar o crescimento e o desenvolvimento. Em contraponto, na economia 

comercial, apenas uma parte da renda ĂŠ reinvertida pelo comerciante, que poderĂĄ 

expandir seus negĂłcios e tambĂŠm realizar inversĂľes improdutivas com artigos de 

2 COSTA, JosĂŠ Augusto Fontoura; SOLA, Fernanda. Desenvolvimento..., p. 287.
3 SCHUMPETER, Joseph Alois. Teoria..., p. 76.



International Journal of Digital Law, Belo Horizonte, ano 1, n. 1, p. 97-115, jan./abr. 2020100

DENISE BITTENCOURT FRIEDRICH, JULIANA HORN MACHADO PHILIPPI

luxo. Em suma, o lucro do comerciante ĂŠ monetizado e, independentemente da 

sua reinversĂŁo, o sistema continuarĂĄ a operar.4

Especificamente quanto ao desenvolvimento econĂ´mico sustentĂĄvel, cabe 

dizer que o direito Ê um dos instrumentos para a sua promoção, visto que as leis e 

instituiçþes jurídicas não são determinantes para o desenvolvimento econômico de 

um paĂ­s, sendo necessĂĄrio o reconhecimento da propriedade privada e cumprimento 

dos contratos por meio de mecanismos informais, sendo estes substitutos mais 

eficazes às leis e instituiçþes jurídicas.5 No entanto, o direito (especialmente a 

“importação” do direito dos países desenvolvidos) não deve ser tomado isoladamente, 

mas sempre considerando a trajetória daquele país e as instituiçþes informais, 

visto que a premissa de que one size fits all, em termos de aplicação do direito 

dos paĂ­ses desenvolvidos costuma falhar, em especial porque essa tentativa de 

generalização não leva em consideração a trajetória pregressa, o path deppendance 

daquele país que se busca desenvolver.6. Os prejuízos decorrentes desta importação 

decorrem do fato de ignorar que o direito, enquanto ciĂŞncias sĂłcias aplicadas, nĂŁo 

pode desconsiderar a realidade social na qual foi desenvolvido. Tal anĂĄlise conjunta 

entre o direito, a trajetória local e as instituiçþes informais, Ê imprescindível para 

a elaboração de reformas mais eficazes para a promoção do desenvolvimento 

econĂ´mico sustentĂĄvel.

Mas nĂŁo se pode descurar que o conceito atual de desenvolvimento nĂŁo 

se limita à dimensão econômica, pois leva em consideração outros fatores, com 

interdependência em relação à esfera humana e social. Em outras palavras, 

apesar de pressupor o crescimento econĂ´mico, o desenvolvimento nĂŁo se limita 

a este, e muito menos apenas à modernização. É necessária a implementação 

de transformaçþes estruturais socioeconômicas para a melhora da qualidade de 

vida dos cidadĂŁos, tendo em vista o bem-estar social.7 E ainda, para Boaventura 

de Sousa Santos, todo conhecimento desenvolvido pela ciĂŞncia sĂł se justifica 

na medida em que possa ser revertido em benefĂ­cio da sociedade, defendendo o 

“paradigma de um conhecimento prudente para uma vida decente”.8

A discussĂŁo quanto ao direito ao desenvolvimento e direitos humanos nĂŁo 

Ê recente: a Comissão de Direitos Humanos da ONU foi a primeira instância 

internacional a reconhecer oficialmente o direito ao desenvolvimento como um 

direito humano fundamental, na Resolução nº 4 (XXXIII), de 1977, reafirmada pela 

Resolução nº 5 (XXXV), em 1979. AlÊm disso, outros atos posteriores da Comissão 

de Direitos Humanos da ONU afirmam a existĂŞncia do direito humano fundamental 

4 FURTADO, Celso. Desenvolvimento..., p. 138-143.
5 DAVIS, Kevin E; TREBILCOCK, Michael J. A relação... p. 245.
6 SCHAPIRO, MĂĄrio Gomes. Repensando..., p. 243.
7 HACHEM, Daniel Wunder. A maximização..., p. 382-383.
8 SANTOS, Boaventura de Sousa. Um discurso..., p. 60.



International Journal of Digital Law, Belo Horizonte, ano 1, n. 1, p. 97-115, jan./abr. 2020 101

INCLUSĂŁO DIGITAL E BLOCKCHAIN COMO INSTRUMENTOS PARA O DESENvOLvIMENTO ECONĂ´MICO

ao desenvolvimento, com a consequente necessidade de institucionalização mais 

abrangente e sistemĂĄtica deste direito.9

ApĂłs longo debate, em 4 de dezembro de 1986 a Assembleia Geral da ONU 

aprovou proposta para a institucionalização do direito ao desenvolvimento, que foi 

materializada por meio da Resolução nº 41/128 da Assembleia Geral das Naçþes 

Unidas, denominada como “Declaração sobre o Direito ao Desenvolvimento”. O 

processo de elaboração do direito ao desenvolvimento continuou na Declaração 

do Rio sobre Meio Ambiente e Desenvolvimento, na convenção realizada no Rio de 

Janeiro em 1992, com destaque para o direito ao desenvolvimento sustentĂĄvel, com 

açþes direcionadas à vida saudåvel e produtiva, mas em harmonia com a natureza. 

Houve a inclusão da proteção ambiental no processo de desenvolvimento, com o 

exercĂ­cio do direito ao desenvolvimento por todos de forma equilibrada, para garantir 

as necessidades das presentes e futuras geraçþes. E, ainda, a Declaração e Plano 

de Ação de Viena, de 1993, consagrou o direito ao desenvolvimento como um direito 

humano universal. Com este status, o direito ao desenvolvimento tem fortalecidos 

seus vĂ­nculos de interdependĂŞncia, devendo ser reconhecido e respeitado por toda 

a sociedade internacional, de forma justa e solidĂĄria, fundamental para possibilitar 

aos povos dos países perifÊricos a construção de um mundo melhor.10

O desenvolvimento social e humano tem por objeto a satisfação das necessidades 

båsicas dos cidadãos, o bem-estar social, o que demanda a implementação atravÊs 

de políticas públicas voltadas à observância e concretização dos direitos sociais, 

incluindo-se neste rol os direitos à educação, saúde, moradia, alimentação, entre 

outros.11

Os direitos sociais, assim como os econômicos, proporcionam condiçþes 

materiais mĂ­nimas para o exercĂ­cio dos direitos individuais, civis e polĂ­ticos. Nesta 

relação se insere a dignidade da pessoa humana, matriz do constitucionalismo 

contemporâneo que atrai o conteúdo dos direitos fundamentais.12 No Brasil, a 

dignidade da pessoa humana estå presente nas Constituiçþes desde 1934 e estå 

fortemente vinculada com o mĂ­nimo existencial, para garantia de uma vida digna.13 

Da dignidade da pessoa humana derivam a obrigação de não violação e o dever 

de promoção e proteção dos direitos fundamentais, sendo o mínimo existencial o 

seu nĂşcleo material.14

Feitas essas consideraçþes a respeito dos direitos sociais, dignidade da pessoa 

humana, mínimo existencial, bem como da breve exposição acerca do direito ao 

9 BEDIN, Gilmar AntĂ´nio. Direitos Humanos..., p. 133-134.
10 BEDIN, Gilmar AntĂ´nio. Direitos Humanos..., p. 139-140.
11 HACHEM, Daniel Wunder. A maximização..., p. 387.
12 HACHEM, Daniel Wunder. MĂ­nimo..., p. 210-211.
13 SARLET, Ingo Wolfgang; ZOCKUN, Carolina Zancaner. Notas sobre..., p. 119.
14 HACHEM, Daniel Wunder. MĂ­nimo..., p. 210-211.



International Journal of Digital Law, Belo Horizonte, ano 1, n. 1, p. 97-115, jan./abr. 2020102

DENISE BITTENCOURT FRIEDRICH, JULIANA HORN MACHADO PHILIPPI

desenvolvimento, não se pode deixar de mencionar o Índice de Desenvolvimento 

Humano (IDH). Referido Ă­ndice foi desenvolvido por Amartya Sen e Gustav Ranis, 

a pedido do PNUD,15 e engloba quatro indicadores: o produto interno bruto (PIB); a 

mÊdia da expectativa de vida; escolaridade obrigatória; e os índices de alfabetização 

dos adultos.16 Assim, alĂŠm da parte econĂ´mica, o desenvolvimento envolve tambĂŠm 

a satisfação dos direitos sociais,17 estando, portanto, intimamente relacionados.

A título de conhecimento, a teoria da justiça de Amartya Sen tem por objeto a 

ampliação das liberdades, com a superação das injustiças e a implementação do 

princípio da prevenção nas políticas públicas para o afastamento, gestão e mitigação 

das inaptidĂľes, ao invĂŠs da infindĂĄvel busca por uma sociedade perfeitamente 

justa.18 Desse modo, ĂŠ menos abstrata e se contrapĂľe Ă  teoria de John Rawls, que 

relaciona o utilitarismo clåssico à posição dominante19 e rechaça a possibilidade 

de um indivíduo optar pelo utilitarismo quando desconhecer sua posição original, 

isto é, sob o “véu da ignorância”,20 21 especialmente para aqueles que pertencerem 

a uma minoria ĂŠtnica ou religiosa, diante do risco de serem oprimidos, ainda que 

para satisfazer uma maioria. Em outras palavras, na justiça como eficiência (isto 

ĂŠ, utilitarismo), hĂĄ risco de ofensa a direitos fundamentais das minorias, e atĂŠ 

mesmo perseguição, se forem minorias Êtnicas ou religiosas. Por isso, os direitos 

e garantias fundamentais correm risco de serem sacrificados em prol de benefĂ­cios 

sociais ou econĂ´micos.22

De acordo com Amartya Sen, o desenvolvimento extrapola a acumulação de 

riqueza e do crescimento do PIB, ou de variĂĄveis relacionadas Ă  renda, ou seja, vai 

além do desenvolvimento econômico. É necessário relacionar o desenvolvimento 

com a melhora na vida das pessoas, como seres sociais completos, com expansĂŁo 

e desfruto das liberdades.23

Ademais, outra dimensão do desenvolvimento econômico Ê a segurança 

econômica, intimamente relacionada à presença dos direitos e liberdades 

democrĂĄticas, visto que a ausĂŞncia de liberdades democrĂĄticas pode ser refletida 

15 PNUD Ê o Programa das Naçþes Unidas para o Desenvolvimento, ou United Nations Development 
Programme (UNDP).

16 COSTA, JosĂŠ Augusto Fontoura; SOLA, Fernanda. Desenvolvimento... p. 288.
17 HACHEM, Daniel Wunder. A maximização..., p. 388.
18 WEDY, Gabriel de Jesus Tedesco. Desenvolvimento..., p. 353.
19 RAWLS, John. Justice as fairness…, p. 248.
20 John Rawls utiliza a expressão “véu da ignorância” (veil of ignorance) em seu livro Theory of Justice, 

para explicar a sua ideia de posição originária. Sob o “véu da ignorância”, as partes desconhecem suas 
posiçþes originårias, isto Ê, não sabem o seu lugar na sociedade e suas condiçþes pessoais e, desse 
modo, nĂŁo sabem quais alternativas as prejudicarĂŁo ou beneficiarĂŁo. Desse modo, as partes se verĂŁo 
obrigadas a avaliar as situações com base em considerações gerais. (RAWLS, John. Theory of…, p. 
136-137).

21 RAWLS, John. Justice as fairness..., p. 235-239.
22 SANDEL, Michael J. Justiça…, p. 189.
23 SEN, Amartya. Desenvolvimento..., p. 28-29.



International Journal of Digital Law, Belo Horizonte, ano 1, n. 1, p. 97-115, jan./abr. 2020 103

INCLUSĂŁO DIGITAL E BLOCKCHAIN COMO INSTRUMENTOS PARA O DESENvOLvIMENTO ECONĂ´MICO

em insegurança econômica. Nessa seara, os direitos civis e as liberdades políticas, 

como elementos constitutivos da liberdade humana, têm suma importância no 

exame do papel dos direitos humanos no desenvolvimento, sendo dispensĂĄvel a 

justificação destas liberdades com base em seus reflexos diretos sobre a economia.24

No entanto, hĂĄ de se destacar que, ao se considerar as liberdades para 

avaliação do desenvolvimento, não hå um critÊrio único para classificar e comparar 

as diferentes experiencias de desenvolvimento. Isto porque, hĂĄ heterogeneidade 

nos elementos constitutivos das liberdades, bem como a necessidade de se levar 

em consideração as diversas liberdades de diferentes pessoas. Para tanto, Amartya 

Sen, ao clamar pela ideia de “desenvolvimento como liberdade”, chama a atenção 

para aspectos importantes do processo de desenvolvimento, sem necessariamente 

fazer uma ordenação de todos os seus estados, posto que tem aplicaçþes muito 

abrangentes nĂŁo sĂł para os objetivos do desenvolvimento, mas tambĂŠm para o 

respeito dos necessĂĄrios processos e procedimentos.25

Hå uma crença de que o desenvolvimento humano somente pode ser alcançado 

pelos paĂ­ses ricos, que podem custeĂĄ-lo. Por outro lado, seria inatingĂ­vel aos 

países em desenvolvimento em razão de limitaçþes financeiras, com consequente 

comedimento nas polĂ­ticas pĂşblicas. No entanto, o crescimento econĂ´mico e 

desenvolvimento humano caminham lado a lado visto que a primazia de investimento 

em saúde e educação, reflete na melhoria da qualidade de vida da população, 

influenciando tambĂŠm na produtividade das pessoas e, consequentemente, em 

avanços econômicos.26 Assim, nos países em desenvolvimento Ê necessåria a 

implementação de políticas públicas engajadas com o desenvolvimento para a 

criação de oportunidades sociais e com responsabilidade ambiental.27

Para o desenvolvimento, nĂŁo se trata apenas de liberdade, tendo o Estado 

papel imprescindĂ­vel como promotor da igualdade. No ponto, Daniel Wunder Hachem 

destaca limitação da teoria de Amartya Sen, por entender que a concepção de que o 

desenvolvimento demandaria apenas liberdade nĂŁo reflete a verdadeira abordagem 

da teoria deste, que somente identifica desenvolvimento com a ideia de liberdade 

mediante a extensão de sua noção. Assim, inserem-se como liberdades algumas 

garantias tradicionalmente nĂŁo vistas como liberdades, sendo imprescindĂ­vel associar 

a liberdade Ă  busca da igualdade para fins de desenvolvimento.28

Cabe mencionar, ainda, que Emerson Gabardo considera que a posição 

de Amartya Sen, de privilegiar a liberdade e nĂŁo a igualdade, ĂŠ uma teoria 

desenvolvimentista consistente em liberalismo fraco, pois ignora a satisfação da 

24 SEN, Amartya. Desenvolvimento..., p. 30-31.
25 SEN, Amartya. Desenvolvimento..., p. 51-52.
26 SEN, Amartya. Desenvolvimento..., p. 190-191.
27 WEDY, Gabriel de Jesus Tedesco. Desenvolvimento... p. 359.
28 HACHEM, Daniel Wunder. A maximização..., p. 388.



International Journal of Digital Law, Belo Horizonte, ano 1, n. 1, p. 97-115, jan./abr. 2020104

DENISE BITTENCOURT FRIEDRICH, JULIANA HORN MACHADO PHILIPPI

felicidade. A seu turno, a felicidade nĂŁo se confunde com a ideia consequencialista 

do utilitarismo, mas sim um fim estabelecido por princĂ­pio, sendo visada no rol 

de garantias e direitos fundamentais da Constituição Federal e incompatível com 

a ideia de subsidiariedade do Estado. Referido autor defende que a restrição do 

desenvolvimento Ă  ideia da dignidade nĂŁo se coaduna com o Estado do bem-estar 

social, por ser o ponto de partida para a justificação dos fins do Estado, enquanto 

o desenvolvimento da personalidade ĂŠ o ponto de chegada, tomando-se por base 

o art. 22 da Declaração Universal dos Direitos do Homem de 1948.29

Desse modo, a busca do desenvolvimento, compatibilizado com as normas 

constitucionais brasileiras, ĂŠ o ponto de partida das polĂ­ticas estatais, alĂŠm de, 

como direito fundamental, impor necessidade de promoção e tutela de/por/para 

todos os cidadãos, fazendo-se necessåria a atualização constante dos termos em 

que serĂĄ praticado.

3 O direito fundamental Ă  inclusĂŁo social

Os primeiros computadores foram concebidos durante a Segunda Guerra 

Mundial e efetivamente criados apenas em 1946, na FiladĂŠlfia. O primeiro 

computador eletrĂ´nico pesava cerca de 30 toneladas e tinha dimensĂľes gigantescas 

em comparação com os que conhecemos atualmente. Com o passar do tempo e 

desenvolvimento das tecnologias, sugiram os primeiros microcomputadores, como 

o Altair, Apple I e Apple II, o Computador Pessoal (PC) da IBM e, posteriormente, 

o Macintosh da Apple, este o primeiro microcomputador de fåcil utilização. Para 

tanto, foi imprescindĂ­vel o desenvolvimento de softwares, bem como o aumento 

da capacidade dos chips e, consequentemente, dos microcomputadores, inclusive 

com redução do preço mÊdio para o processamento das informaçþes.30

Os computadores de uso pessoal e a redução dos custos foram extremamente 

importantes para a propagação das novas tecnologias, observando-se, sobretudo, 

o fenômeno da “virtualização”, que transformou a realidade social e laborativa nas 

últimas dÊcadas. A virtualização não Ê uma desmaterialização ou transformação 

da realidade, mas sim uma mudança na identidade, marcada por uma espÊcie de 

desterritorialização, desprendimento do aqui e agora.

Considere-se, por exemplo, uma empresa, que pode ser virtualizada com o 

teletrabalho, realidade laboral inquestionavelmente impulsionada pela pandemia 

de covid-19, substituindo a presença física dos funcionårios com a participação 

por meio de reunião eletrônica e programas que favoreçam a cooperação. Hå uma 

mudança no centro de gravidade daquela empresa, que deixa de ser o prÊdio físico 

29 GABARDO, Emerson. Interesse..., p. 330-331.
30 CASTELLS, Manuel. A Sociedade..., p. 97-99.



International Journal of Digital Law, Belo Horizonte, ano 1, n. 1, p. 97-115, jan./abr. 2020 105

INCLUSĂŁO DIGITAL E BLOCKCHAIN COMO INSTRUMENTOS PARA O DESENvOLvIMENTO ECONĂ´MICO

onde se localizam os escritórios e os postos de trabalho, com redistribuição das 

coordenadas do trabalho de cada um de seus membros no espaço e no tempo.31 

Observa-se a virtualização da sociedade, com a saída da “presença”, que acarreta 

a multiplicação contemporânea dos espaços e o aumento da comunicação e 

transmissão das informaçþes.32

Diante de toda essa evolução tecnológica, cabe mencionar que, de acordo com 

Klaus Schwab, estå em curso a quarta revolução industrial, baseada na revolução 

digital, marcada pela internet mais ubĂ­qua e mĂłvel, aumento na capacidade de 

armazenamento de dados e inteligĂŞncia artificial. HĂĄ fusĂŁo das novas tecnologias 

e interação entre os domínios físicos, digitais e biológicos, e a quarta revolução 

ĂŠ marcada pela difusĂŁo muito mais rĂĄpida e ampla das tecnologias emergentes e 

inovaçþes generalizadas. 33

Com a explosão das informaçþes e dos dados, hå um fluxo constante de 

informaçþes que as transforma, com crescimento exponencial da sociedade do 

conhecimento. Assim, alĂŠm dos clĂĄssicos desafios quanto aos direitos, devem ser 

acrescentados outros relacionados Ă  era digital, a exemplo da garantia da dignidade 

digital como parte da autodeterminação e dignidade humana. Desse modo, a 

proteção da identidade digital assume um papel central na sociedade e no Direito.34

As novas tecnologias sĂŁo importantes para o exercĂ­cio dos direitos de liberdade 

de expressão e informação pelos cidadãos, bem como para o desenvolvimento 

econĂ´mico, industrial e tecnolĂłgico. AlĂŠm disso, sĂŁo consideradas como instrumentos 

para o aumento da produtividade, criação de novos empregos e para melhorar a 

qualidade de vida de todos os cidadĂŁos.

No âmbito das novas tecnologias da quarta revolução industrial, hå de se 

ponderar que podem existir reflexos negativos, sobretudo nas relaçþes de trabalho, 

diante da possibilidade de alargamento das jornadas laborais, sobreposição entre 

trabalho e vida pessoal, bem como a possibilidade de substituição do trabalho 

humano por robĂ´s e outras tecnologias.35

De todo modo, o acesso Ă  internet pelos cidadĂŁos, isto ĂŠ, a inclusĂŁo digital, 

pode ser considerado como um direito fundamental,36 e inclusive como direito 

31 LEVY, Pierre. O que ĂŠ virtual..., p. 17-19.
32 LEVY, Pierre. O que ĂŠ virtual..., p. 23.
33 Para sintetizar as revoluçþes anteriores: a primeira revolução industrial ocorreu entre 1760 e 1840, 

provocada pela construção das ferrovias e invenção da måquina a vapor, que deu início à produção 
mecânica; a segunda revolução industrial aconteceu entre o final do sÊculo XIX e o começo do sÊculo 
XX, resultante da eletricidade e da linha de montagem, que possibilitou a produção em massa; a 
terceira revolução industrial veio no final da dÊcada de 1960, impulsionada pelo desenvolvimento dos 
semicondutores, da computação e da internet. SCHWAB, Klaus. A Quarta..., p. 16.

34 CORVALÁN, Juan Gustavo. Digital…, p. 56-57; CORVALÁN, Juan Gustavo. Administración…, p. 26-66.
35 BELTRAMELLI NETO, Silvio; COSTA, Leandro Faria. Apontamentos..., p. 258-259.
36 Nesse sentido: GONÇALVES, Victor Hugo Pereira. Inclusão...



International Journal of Digital Law, Belo Horizonte, ano 1, n. 1, p. 97-115, jan./abr. 2020106

DENISE BITTENCOURT FRIEDRICH, JULIANA HORN MACHADO PHILIPPI

fundamental social, visto que estĂĄ intimamente relacionado Ă  garantia de dignidade 

da pessoa humana e de suas condiçþes de vida.37

As";"""date"",""2020-11-23T18:01:06Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.3""
""xmp:CreatorTool"",""Adobe InDesign 16.0 (Windows)""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dcterms:created"",""2020-11-23T17:47:45Z""
""language"",""pt""
""Last-Modified"",""2020-11-23T18:01:06Z""
""dcterms:modified"",""2020-11-23T18:01:06Z""
""dc:format"",""application/pdf; version=1.3""
""xmpMM:DocumentID"",""xmp.id:2179bb28-52ba-3345-96d9-09311353a35e""
""Last-Save-Date"",""2020-11-23T18:01:06Z""
""pdf:docinfo:creator_tool"",""Adobe InDesign 16.0 (Windows)""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2020-11-23T18:01:06Z""
""meta:save-date"",""2020-11-23T18:01:06Z""
""pdf:encrypted"",""false""
""xmp:CreateDate"",""2020-11-20T14:44:51Z""
""modified"",""2020-11-23T18:01:06Z""
""Content-Length"",""620068""
""pdf:hasMarkedContent"",""true""
""Content-Type"",""application/pdf""
""xmp:ModifyDate"",""2020-11-20T14:45:03Z""
""xmp:MetadataDate"",""2020-11-20T14:45:03Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""pdf:producer"",""Adobe PDF Library 15.0""
""meta:creation-date"",""2020-11-23T17:47:45Z""
""created"",""2020-11-23T17:47:45Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""28""
""Creation-Date"",""2020-11-23T17:47:45Z""
""resourceName"",""6""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""198"",""3059"",""2460"",""3771"",""2727"",""3060"",""3029"",""3267"",""3096"",""2831"",""3245"",""3113"",""3195"",""2725"",""3504"",""3008"",""2613"",""2893"",""3493"",""3515"",""2286"",""3522"",""3439"",""1911"",""2658"",""1022"",""2779"",""606""
""access_permission:extract_content"",""true""
""xmpMM:DerivedFrom:DocumentID"",""xmp.did:ce9dc56b-f775-2e4b-9f21-d6a166df081c""
""access_permission:can_print"",""true""
""xmpMM:DerivedFrom:InstanceID"",""xmp.iid:7524e484-ccbb-f148-8238-30cca8b7120c""
""producer"",""macOS Versão 11.0.1 (Compilação 20B29) Quartz PDFContext, AppendMode 1.1""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""macOS Versão 11.0.1 (Compilação 20B29) Quartz PDFContext, AppendMode 1.1""
""pdf:docinfo:created"",""2020-11-23T17:47:45Z""
";https://scholar.google.ch/scholar?start=590&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098756-89;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Truver: a blockchain for verifying credentials: poster;A Taha, A Zakaria ; Proceedings of the 35th Annual ACM Symposium on …, 2020  dl.acm.org;;"… contract via its application binary interface (ABI JSON file) and the contract's Ethereum address,

and (c) allows the cus- tomer's address to run the oracle3. A transaction retrieval script is

developed to be used by the verifier to extract the hashes stored on the blockchain. 1 2 5 10 …";Cité 2 fois;;null;;;;https://scholar.google.ch/scholar?start=630&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098870-342;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Lower bounds for leakage-resilient secret sharing;JB Nielsen, M Simkin ; Annual International Conference on the Theory and …, 2020  Springer;;"… (CRYPTO'18), who ask to what extend existing regular secret sharing schemes already … construct

a leakage-resilient secret sharing scheme in the random oracle model that … Independent Research

Fund Denmark project BETHE and the Concordium Blockchain Research Center …";Cité 12 fois;Les 2 versions;[PDF] iacr.org;https://eprint.iacr.org/2019/181.pdf;"
Lower Bounds for Leakage-Resilient Secret Sharing

Jesper Buus Nielsen? and Mark Simkin??

Aarhus University, Denmark
{jbn, simkin}@cs.au.dk

Abstract. Threshold secret sharing allows a dealer to split a secret into n shares such that any
authorized subset of cardinality at least t of those shares efficiently reveals the secret, while at the
same time any unauthorized subset of cardinality less than t contains no information about the secret.
Leakage-resilience additionally requires that the secret remains hidden even if one is given a bounded
amount of additional leakage from every share.

In this work, we study leakage-resilient secret sharing schemes and prove a lower bound on the share
size and the required amount of randomness of any information-theoretically secure scheme. We prove
that for any information-theoretically secure leakage-resilient secret sharing scheme either the amount of
randomness across all shares or the share size has to be linear in n. More concretely, for a secret sharing
scheme with p-bit long shares, `-bit leakage per share, where t̂ shares uniquely define the remaining
n− t̂ shares, it has to hold that

p ≥ `(n− t)
t̂

.

We use this lower bound to gain further insights into a question that was recently posed by Benhamouda
et al. (CRYPTO’18), who ask to what extend existing regular secret sharing schemes already provide
protection against leakage. The authors proved that Shamir’s secret sharing is 1-bit leakage-resilient for
reconstruction thresholds t ≥ 0.85n and conjectured that it is also 1-bit leakage-resilient for any other
threshold that is a constant fraction of the total number of shares. We do not disprove their conjecture,
but show that it is the best one could possibly hope for. Concretely, we show that for large enough n
and any constant 0 < c < 1 it holds that Shamir’s secret sharing scheme is not leakage-resilient for
t ≤ cn/logn.

In contrast to the setting with information-theoretic security, we show that our lower bound does not
hold in the computational setting. That is, we show how to construct a leakage-resilient secret sharing
scheme in the random oracle model that is secure against computationally bounded adversaries and
violates the lower bound stated above.

1 Introduction

Threshold secret sharing, introduced by Shamir [Sha79] and Blakley [Bla79], is a fundamental building block
in modern cryptography. It allows a dealer to split a secret into n shares such that any subset of cardinality
at least t of those shares efficiently reveals the secret, while at the same time any subset of cardinality less
than t contains no information about the secret in the information theoretic sense. Due to its computational
simplicity, its strong privacy guarantees, and its information-theoretic security, it has found applications in
various areas of cryptography ranging from secure multiparty computation [BGW88, CCD88, RB89] over
threshold cryptography [Des88, DF90, Sho00] to attribute-based encryption [GPSW06, Wat11]. Stronger
notions, like robust [RB89] and verifiable secret sharing [CGMA85] address the lack of authenticity in the
original definition and prevent the participants or the dealer from tampering with the shares. All these
classical notions of secret sharing have in common that they assume that any share is either fully corrupted
or completely hidden from the adversary.

? Supported by the Independent Research Fund Denmark project BETHE and the Concordium Blockchain Research
Center, Aarhus University, Denmark.

?? Supported by the European Unions’s Horizon 2020 research and innovation program under grant agreement No
669255 (MPCPRO) and No 731583 (SODA).



In contrast to these notions, a recent line of works [DP07, BGK14, GK18a, GK18b, ADN+18, KMS18,
SV18, BS18] considers secret sharing in the context of side-channel attacks, where an adversary gets some
form of restricted access to all shares. Generally, these works consider two types of adversaries. Active ad-
versaries that may tamper with all shares and passive adversaries that may leak some bounded amount
of information from each share. Constructing secret sharing schemes that remain secure in the presence of
such powerful adversaries is a challenging task and, unsurprisingly, existing constructions are less efficient
than regular secret sharing schemes in one way or another. Understanding what price one has to pay for
such strong security guarantees is a foundational theoretical question and of significant practical impor-
tance when real-world resources are limited. While the efficiency of regular threshold secret sharing is well
understood [BGK16], little is known about the price of additional security against side-channel attacks.

In this work, we focus on leakage-resilient secret sharing and we measure efficiency in terms of share size
and the amount of randomness needed for secret sharing a value. The share size is an important measure to
optimize, since it directly affects the efficiency of cryptographic primitives, like multiparty computation pro-
tocols, that are built on top of secret sharing. The celebrated BGW protocol [BGW88] for secure multiparty
computation, for instance, exhibits a one-to-one correspondence between share size of the underlying secret
sharing scheme and overall communication complexity of the protocol. That is, an increase of the share size
by a factor of 2 directly translates to an increase of the overall communication complexity of the protocol by
the same factor. The amount of randomness that cryptographic primitives require is an important measure
to optimize for real-world applications. In research, it is often assumed that randomness is simply there
when needed it, yet in reality it turns out to be a precious resource with limited availability. Generating
good randomness is difficult and cryptographic primitives that required more randomness than what was
available have led to devastating large-scale attacks [HDWH12].

1.1 Our Contribution

We prove that for any leakage-resilient secret sharing scheme with information-theoretic security either the
amount of randomness across all shares or the share size has to be large.

Theorem 1 (Informal). Let S be a t-out-of-n secret sharing scheme, let p be the bit length of each share,
and let ` be the number of bits leaked from each share. If S is leakage-resilient against a computationally
unbounded adversary and t̂ shares uniquely define the remaining n− t̂ shares, then

p ≥ `(n− t)
t̂

For instance, for a O(1)-out-of-n secret sharing scheme with 1-bit leakage, where O(1) shares uniquely
define the remaining shares, the theorem tells us that the share size has to be linear in the number of shares.
On the other hand, if we want the share size to be o(n), then the theorem tells us that virtually all shares
have to contain some independent, yet meaningful information1.

We prove our lower bound by presenting a conceptually simple generic adversary, who breaks the leakage-
resilience of any secret sharing scheme that violates our bound. More concretely, the adversary is given leakage
from each share and its goal is to determine the secret value. The high-level idea behind our attack is to apply
one separate uniformly random leakage function to each share. By correctness of a secret sharing scheme, we
know that any two vectors of secret shares corresponding to two different secrets will always differ in at least
n− t+ 1 positions. If the output of each leakage function is ` bits long, then two different shares produce the
same leakage with probability 2−`. The smaller the threshold t, the larger the number of differing shares.
The main observation behind our lower bound is that, with an increasing n, we quickly reach a point, where
the leakage excludes all but one of the secrets that could have produced the given leakage.

We use our lower bound to gain further insights into an intriguing question that was recently posed by
Benhamouda et al. [BDIR18], who ask to what extent existing regular secret sharing schemes already provide
protection against leakage. Among other results, the authors show that Shamir’s secret sharing scheme over

1 We will precise define what we mean by meaningful information in Section 3.1

2



Threshold

Leakage

log q

log q
2

log q
4

1

n

n−O(log n)

cn/logn n/5 n/32
L

em
m

a
2

Lem
m

a
3

[B
D

IR
1
8
]

[BDIR18]
Conjecture

Fig. 1. Overview of our results on the leakage-resilience of Shamir’s secret sharing over a prime order field Fq for an
arbitrary number of parties n. The y-axis depicts the leakage per share in bits, the x-axis shows the reconstruction
threshold. The red area indicates parameter ranges in which it is not leakage-resilient. The green area indicates
parameter ranges where it is. The white area indicates parameter ranges, where we do not know anything. n is the
number of parties, log q is the number of bits per share, and 0 < c < 1 is an arbitrary, but fixed constant.

a field F2k with small characteristic is not leakage-resilient. Specifically, the authors present an attack, which
obtains one bit of the secret shared value from 1-bit leakage from each share. On the positive side, the authors
show that t-out-of-n Shamir secret sharing over a prime order field Fq is 1-bit leakage-resilient if t ≥ 0.85n.
The authors leave it open to prove or disprove the leakage-resilience of Shamir secret sharing over Fq for
other parameter ranges and conjecture:

Conjecture 1 ([BDIR18]) Let 0 < c ≤ 1 be a constant and let q ≈ n be a prime. For large enough n, it
holds that cn-out-of-n Shamir secret sharing over Fq is 1-bit leakage-resilient.

We do not disprove their conjecture, but show that it is basically the best one could hope for. More
concretely, we show that for a large enough n and any constant 0 < c < 1 it holds that Shamir’s secret
sharing scheme is not leakage-resilient for t ≤ cn/ log n. Our results regarding the leakage-resilience of
Shamir’s secret sharing scheme are illustrated in Figure 1. Whereas the negative results above crucially rely
on a computationally unbounded adversary, we also show that for the specific case of 2-out-of-n Shamir
secret sharing there exists a computationally efficient attack.

Given the lower bound for information-theoretically secure secret sharing schemes, it may be natural to
hope the same bound may apply to schemes that only need to be sure against a computationally bounded
adversary. We show that this is not the case by presenting a leakage-resilient secret sharing scheme in the
random oracle model that has a share size of p = O (n+ Îť+ `) and is secure against any computationally
bounded adversary that runs in time poly(Îť). By setting, for instance, ` > n one can see that such a scheme
violates our lower bound from above for sufficiently large n.

2 Preliminaries

For random variables V and W we use V ≈ε W to denote that the distributions of V and W are at most ε
apart in L1 distance.

Our definition of threshold secret sharing follows the definition of Beimel [Bei11]. We additionally define
a full reconstruction threshold t̂, which defines how many shares are needed to reconstruct all shares of a
particular secret sharing. In other words, the full reconstruction threshold t̂ can also be seen as an upper
bound on the total entropy among all shares of a secret sharing. In our definition and the remainder of the

3



paper we assume perfectly correct secret sharing schemes. This is done for the sake of simplicity and all
proofs easily extend to the case, where the reconstruction may fail with some probability.

Definition 1 (Threshold Secret Sharing Scheme). Let Share : {0, 1}k → ({0, 1}p)n be an efficient
randomized algorithm mapping k bit secrets into n shares each of length p. Let Rec : ({0, 1}p)n → {0, 1}k
be a deterministic algorithm that maps a collection of t shares back to a secret. The notion generalises in a
straight forward manner to schemes Share : {0, 1}k →

∏n
i=1{0, 1}pi , where the shares possibly have different

length. The pair (Share,Rec) is called a t-out-of-n secret sharing if:

1. Perfect Correctness: Any t-out-of-n shares can be used to reconstruct the secret correctly. For any
x ∈ {0, 1}k, for any set T ⊆ [n] with |T | ≥ t,

Pr[Rec(Share(x)T ) = x] = 1

where the probability is taken over the randomness of the sharing function and Share(x)T denotes the
restriction of the n shares produced by Share(x) to the ones identified by the set T .

2. Perfect Privacy: Less than t shares reveal no information about the underlying secret. More for-
mally, for any two x, y ∈ {0, 1}k, any set T ⊆ [n] with |T | < t, Share(x)T is identically distributed
to Share(y)T .

3. Full Reconstruction: A secret sharing scheme has t̂-full-reconstruction if Share(x) can be computed
from any subset Share(x)T with |T | ≥ t̂.

The notion of Full Reconstruction is non-standard, but essential to our study. Leakage-resilient secret
sharing schemes like [SV18] with very high leakage resilience all seem to use some notion of non-trivial
correlated randomness which makes the full reconstruction threshold larger than the reconstruction threshold.
To some extend our results will explain why this is the case. If you have a scheme with low full reconstruction
threshold you get poor leakage resilience. So if you have a scheme with a low reconstruction threshold
and good leakage resilience, then the full reconstruction threshold must be larger than the reconstruction
threshold.

To model leakage-resilient secret sharing, we use the local leakage model as defined by Goyal and Ku-
mar [GK18a] and Benhamouda et al. [BDIR18]. Intuitively, it allows the adversary to compute arbitrary
independent leakage functions on all shares, which are only restricted in the size of their leakage output.
For the sake of exposition, we split the definition in weak and regular local leakage-resilience. In weak local
leakage-resilience the adversary is only given the output of the leakage functions. In regular local leakage-
resilience, it is additionally given θ full shares. As such weak local leakage-resilience is a special case of regular
local leakage-resilience for θ = 0.

Definition 2 (Leakage Function). We call Leak = (Leak1, . . . ,Leakn) an `-leakage function for (Share,
Rec) if Share : {0, 1}k →

∏n
i=1{0, 1}pi and Leaki : {0, 1}pi → {0, 1}`. For (sh1, . . . , shn)← Share(s) we

define (b1, . . . , bn) = Leak(sh1, . . . , shn) by bi = Leaki(shi).

Definition 3 (Weak Local Leakage-Resilience). A secret sharing scheme (Share,Rec) is said to be
(Îľ, `)-weakly-local-leakage-resilient (W-IND-LLR) if for every `-leakage function vector Leak and every pair
of secrets x, y ∈ {0, 1}k it holds that

Leak(Share(x)) ≈ε Leak(Share(y)).

We also define leakage-resilience against a class of adversaries. Let B be a possibly randomized interactive
algorithm. First the adversary outputs a pair of secrets (x0, x1) and a leakage function Leak. Then the game
flips a uniformly random challenge bit c and inputs Leak(Share(xc)) to B. Then run B to get a guess
g ∈ {0, 1}. Let AdvB = 2|Pr[g = c] − 1/2|. We say that (Share,Rec) is (ε, `)-weakly-local-leakage-resilient
for a class B of adversaries if for all B ∈ B it holds that

AdvB ≤ ε .

4



Definition 4 (Local Leakage-Resilience). A secret sharing scheme (Share,Rec) is said to be (ξ, `, θ)-
local-leakage-resilient (IND-LLR) if for every `-leakage function vector Leak, for any set T ⊆ [n] with
|T | < θ, and every pair of secrets x, y ∈ {0, 1}k it holds that

(Share(x)T ,Leak(Share(x))) ≈ε (Share(y)T ,Leak(Share(y))) .

We also add a one-way notion, which we will use for proving our lower bound. We will make the notion
as weak as possible while still being meaningful, which makes our lower bound as strong as possible.

Definition 5 (Weak One-Way Local Leakage-Resilience). We define what it means for a secret shar-
ing scheme (Share,Rec) to be `-weakly one-way local-leakage-resilient (WOW-LLR). Let A be a possibly
randomized interactive algorithm. Let x ∈ {0, 1}k be a secret. The game WOWA(x) proceeds as follows. First
the adversary outputs a leakage function Leak. Then the game samples (sh1, . . . , shn)← Share(x) and we
input Leak(Share(x)) to A, who outputs a guess y ∈ {0, 1}k ∪ {⊥}. The output of WOWA(x) is 1 if and
only if y = x. We call A admissible if it always holds for all x that y = x or y = ⊥. We require that for all
admissible A there exist x for which Pr[WOWA(x) = 1] < 1/2.

Note that one-wayness is a very weak security notion, it only requires that all of the secret cannot be learned.
Requiring that the adversary must only make guesses it knows are correct further weakens the notion, as it
limits the set of adversaries, which in turn makes it easier to be WOW-LLR. We also weaken the notion by
requiring only that Pr[WOWA(x) = 1] < 1/2, as opposed to requiring that Pr[WOWA(x) = 1] is negligible.
And finally we only require that (Share,Rec) hides one x from the adversary, meaning that it might in
principle be possible for A to recover almost all x with certainty. It seems hard to meaningfully further weaken
the notion. Not surprisingly, W-IND-LLR implies WOW-LLR, but for completeness we prove a technical
lemma to this effect.

Lemma 1. Let (Share,Rec) be a secret sharing scheme. If (Share,Rec) is (1/2, `)-W-IND-LLR then
(Share,Rec) is `-WOW-LLR.

Proof. Assume that (Share,Rec) is not WOW-LLR. This means that there exists an admissible A such
that

Pr[WOWA(x) = 1] > 1/2

for all x. Now let B be W-IND-LLR adversary which first runs as follows. First pick x0 and x1 to be any
distinct secrets. Run A to get a leakage function Leak. Output (x0, x1) and Leak. Get back

(b1, . . . , bn) = Leak(Share(xc)) .

Input (b1, . . . , bn) to A and get back a guess y. If y = ⊥, then output a uniform random guess g. Otherwise,
since A is admissible we know that y = xc for c = 0 or c = 1. In that case, output g = c. We know that the
probability that A guesses xc is larger than 1/2. So, clearly

AdvB = 2|Pr[g = c]− 1/2|
≥ 2(1 · Pr[y 6= ⊥] + 1/2 · Pr[y = ⊥]− 1/2)

> 2(1 · 1/2 + 1/2 · 1/2− 1/2)

= 1/2.

This implies that (Share,Rec) is not (1/2, `)-W-IND-LLR.

2.1 Shamir’s Secret Sharing

In t-out-of-n Shamir secret sharing [Sha79] the secrets and the shares come from a field Fq, where q is usually
chosen to be the smallest prime larger than n. Let ι1, . . . , ιn ∈ Fq be distinct non-zero elements known to

5



all parties. To share a secret s ∈ Fq, the dealer picks a uniformly random polynomial P of degree t− 1 with
p(0) = s. The share of party i is shi = P (Îąi).

To reconstruct the secret, a sufficiently large subset of parties interpolates the polynomial P from their
shares and evaluates the interpolated polynomial at position 0. Correctness follows from the fact that, in a
field, any t points uniquely define a polynomial of degree t − 1. Privacy follows from the fact that for any
t− 1 points any secret s is still possible and all secrets are equally likely.

3 Lower Bound

In this section we prove our main result.

Theorem 2. Let S = (Share,Rec) be a t-out-of-n secret sharing scheme with t̂-full-reconstruction. If S is
`-WOW-LLR and ` ≥ 1, then

p ≥ `(n− t)
t̂

.

Proof. We prove the theorem by exhibiting an explicit admissible adversary that breaks `-WOW-LLR of
any secret sharing scheme with a share size p < `(n−t)/t̂. We provide an inefficient, randomized algorithm A
that exactly recovers the secret shared value from the given leakage with probability at least 1/2. Note that
throughout the paper we give attacks succeeding with constant probability. It with be enough to present
attacks succeeding with non-negligible probability. However, this does not seem to allow to strengthen our
lower bounds.

The algorithm A proceeds as follows. Pick a random Leak = (Leak1, . . . ,Leakn) where each Leaki :
{0, 1}p → {0, 1}` is an independent, uniformly random function mapping p-bit strings to `-bit strings. Submit
it to the leakage game and get back

(b1, . . . , bn) = (Leak1(sh1), . . . ,Leakn(shn)) ,

where

(sh1, . . . , shn)← Share(s; r)

is a secret sharing of the secret s that the algorithm should try to recover. Now iterate over all secrets s′ and
randomizers r′ and compute

(sh′1, . . . , sh
′
n)← Share(s′; r′) .

Let

S = {s′ | ∃r : (b1, . . . , bn) = (Leak1(sh′1), . . . ,Leakn(sh′n))} .

This is the set of secrets s′ which are consistent with the leakage (b1, . . . , bm). If |S| > 1, then output ⊥.
Otherwise, let {s} = S and output s. Let succ be the event that the output is not ⊥.

It is trivial to see that s ∈ S. Hence if |S| = 1, then indeed S = {s}. So when A does not output ⊥, it
outputs the correct secret s. Hence A is admissible.

We now prove that Pr[succ] ≥ 1/2. Let (sh1, . . . , shn) ← Share(s; r) be the secret sharing of the secret
that A is trying to guess and denote by bi ← Leaki(shi) the leakage from the i-th share. Let (sh′1, . . . , sh

′
n)←

Share(s′; r′) be the secret sharing of some arbitrary but fixed secret s′ with s 6= s′ and let b′i ← Leaki(sh
′
i)

be the corresponding leakage. By correctness of the secret sharing scheme, it is guaranteed that there exists
a set I ⊆ [n] with |I| ≥ n− t+ 1 such that shi 6= sh′i for all i ∈ I. So it clearly holds that

Pr
Leak

[(b1, . . . , bn) = (b′1, . . . , b
′
n)] ≤ 2−`(n−t+1),

where the randomness is taken over a random Leak.
Since each share is p bits long and since t̂ shares uniquely define any particular secret sharing, it follows

that there exists at most a total of 2pt̂ possible secret sharings.

6



Let coll be the event that there exists any (s′, r′) with s′ 6= s such that (b1, . . . , bn) = (Leak1(sh′1), . . . ,
Leakn(sh′n)) when (sh′1, . . . , sh

′
n)← Share(s′; r′). By a union bound we get that

Pr[coll] ≤ 2pt̂−`(n−t+1)

Pr[¬coll] ≥ 1− 2pt̂−`(n−t+1) .

Observe that the event succ = ¬coll. If all secret sharings of all values s′ 6= s are inconsistent with the
given leakage, then we can conclude that the secret shared value is s. For the probability of ÂŹcoll to be larger
than 1/2, it suffices that

1− 2pt̂−`(n−t+1) > 1/2

2pt̂−`(n−t+1) < 1/2

pt̂− `(n− t+ 1) < −1

`(n− t+ 1)− 1 > pt̂

`(n− t+ 1)− 1

t̂
> p

To prevent the attack described above, we therefore need that

`(n− t+ 1)− 1

t̂
≤ p

has to hold. Finally, we observe that when ` ≥ 1, then `(n− t+ 1)− 1 ≥ `(n− t).

ďż˝

As an immediate corollary of the theorem it follows that any secret sharing scheme, which only requires
a constant number of shares for full reconstruction, has to have a share size that is linear in the number of
shares if it wants to be leakage-resilient.

Corollary 1. Let S = (Share,Rec) be a t-out-of-n secret sharing scheme with t̂-full-reconstruction, where
t and t̂ are constants. If S is (1/2, 1)-W-IND-LLR, then its share size p is in Ω(n).

When given some complete shares in addition to the leakage, then we obtain the following bound:

Theorem 3. Let S = (Share,Rec) be a t-out-of-n secret sharing scheme with t̂-full-reconstruction. If S is
(1/2, `, θ)-IND-LLR, and ` ≥ 1, then

p ≥ `(n− t)
t̂− θ

.

Proof. The proof here is almost identical to the proof of Theorem 2. In addition to the leakage, we are now
given θ complete shares. As before, let (b1, . . . , bn) and (b′1, . . . , b

′
n) be the leakage of some arbitrary, but

fixed secret sharings a = Share(s; r) and a′ = Share(s′; r′) with s 6= s′. Let T ⊆ [n] with |T | < θ be the
subset of indices of shares that we get to see in addition to the leakage. We have already established that

Pr[(b1, . . . , bn) = (b′1, . . . , b
′
n)] ≤ 2−`(n−t+1),

which implies

Pr[(b1, . . . , bn, aT ) = (b′1, . . . , b
′
n, a
′
T )] ≤ 2−`(n−t+1).

7



Let us now consider the event coll that, for an arbitrary but fixed (s, r), there exists any (s′, r′) with

s′ 6= s such that (b1, . . . , bn, aT ) = (b′1, . . . , b
′
n, a
′
T ). There are at most 2pt̂ possible secret sharings and at

most 2p(t̂−θ) possible secret sharings that match the shares aT at the indices T . By a union bound we have

Pr[¬coll] ≥ 1− 2p(t̂−θ)−`(n−t+1).

For the probability of ÂŹcoll to be larger than 1/2 it thus suffices that

`(n− t+ 1)− 1

t̂− θ
> p.

To prevent the attack described above it must therefore hold that

`(n− t+ 1)− 1

t̂− θ
≤ p,

which for ` ≥ 1 is true if

`(n− t)
t̂− θ

≤ p.

ďż˝

3.1 A Lower Bound via Randomness Complexity

In this section we prove a lower bound via randomness complexity. To motivate it, consider the bound in
Theorem 2 for the case t = o(n). In this case we have that

p ≥ `n

t̂
.

So, if we consider the relative leakage, then we have that

`

p
≤ t̂

n
.

This means that to have a constant leakage rate2, one still needs t̂ ∈ Ω(n). That is, after having enough
shares to reconstruct, there still needs to be randomness left in many of the other remaining shares. This
explains existing constructions of leakage-resilient secret sharing schemes, where shares contain a lot more
randomness than what is actually needed to get privacy against t− 1 parties.

However, the above theorem does not give a quantitative enough handle on this phenomenon. One could
trivially get t̂ = n by adding an unused uniformly random bit to each share. But intuitively, this should not
help against leakage-resilience. These bits are trivial in the sense that they could just be deleted. Neither
should it help if we added a little bit of non-trivial randomness to the shares, as it could just be leaked.
Below we prove a theorem which gets a better quantative handle of how much randomness there must be in
the shares.

The following definition will be helpful in removing trivial randomness from consideration.

2 The leakage rate is defined as the ratio between the number of bits leaked per share and the share size in bits.

8



Definition 6. Let S = (Share,Rec) be a t-out-of-n secret sharing scheme where share number i has length
pi. We call comp = (comp1, . . . , compn) a compression of S if it holds for i = 1, . . . , n that compi : {0, 1}pi →
{0, 1}qi and qi ≤ pi. Define Sharecomp by

(sh′1, . . . , sh
′
n) = Sharecomp(s; r)

where
(sh1, . . . , shn) = Share(s; r)

and
(sh′1, . . . , sh

′
n) = (comp1(sh1), . . . , compn(shn)) .

We call a compression a correct compression of S if for some Rec′ it holds that Scomp = (Sharecomp,Rec′)
is again a t-out-of-n secret sharing scheme.

We now introduce a crude measure of the randomness complexity.

Definition 7. Let S = (Share,Rec) be a t-out-of-n secret sharing scheme. Let

sizeS = |{Share(s; r)|s ∈ {0, 1}k, r ∈ {0, 1}∗}| .

Let
ranS = log min

comp
sizeScomp ,

where the minimum is taken over all correct compressions of S. We call a correct compression comp for S
for which it holds that log2 sizeScomp = ranS a max-compression of comp.

Notice that the above measure is via max-entropy. This is a very crude notion of randomness, but for
illustrating the phenomenon that a lot of randomness is left in each share, it works well and allows for a
significantly simpler proof.

Notice that if you secret share a random secret s using a random r, then you will hit all possible secret
sharings with non-zero probability. So, the length of the random s and r must be at least ranS. So, if we
can lower bound ranS, we also lower bounded the amount of randomness needed to sample a secret sharing.

To connect the randomness complexity to the above theorems, notice that if a secret sharing scheme S
has share size p, then ranS ≤ t̂p.

Theorem 4. Let S = (Share,Rec) be a t-out-of-n secret sharing scheme with t̂-full-reconstruction. If S is
(1/2, `)-weakly-leakage-resilient and ` ≥ 1, then

ranS ≥ `(n− t) .

Proof. We prove the theorem by showing a generic attack that breaks `-WOW-LLR of any secret sharing
scheme with ranS < `(n− t). The adversary A proceeds as follows.

1. Let comp = (comp1, . . . , compn) be a max-compression for S = (Share,Rec), where compi : {0, 1}pi →
{0, 1}qi .

2. For i = 1, . . . , n, pick a uniformly random Leaki : {0, 1}qi → {0, 1}`.
3. For i = 1, . . . , n, let Leak′i = Leaki ◦ compi.
4. Submit Leak′ = (Leak′1, . . . ,Leak

′
n) to the WOW-LLR.

5. Get back (b1, . . . , bn) = (Leak1(comp1(sh1)), . . . ,Leakn(compn(shn))) where (sh1, . . . , shn)← Share(s; r)
is a secret sharing of the secret s that the algorithm should try to recover.

6. Call s′ ∈ {0, 1}k consistent with (b1, . . . , bn) if there exists r′ such that

(b1, . . . , bn) = (Leak1(sh′1), . . . ,Leakn(sh′n))

when
(sh′1, . . . , sh

′
n)← Sharecomp(s′; r′) .

Compute
S = {s′ ∈ {0, 1}k | s′ is consistent with (b1, . . . , bn)} .

9



7. If |S| > 1, then output ⊥. Otherwise, let {s} = S and output s.

Let succ be the event that the output is not ⊥. It is trivial to see that s ∈ S. Hence if |S| = 1, then
indeed S = {s}. So when A does not output ⊥, it outputs the correct secret s and wins the WOW-LLR. We
conclude the theorem by proving that Pr[succ] ≥ 1/2.

Let (sh1, . . . , shn)← Share(s; r) be the secret sharing of the secret that A is trying to guess and denote
by

bi ← Leaki(compi(shi))

the leakage from the i-th share. Let

(sh′1, . . . , sh
′
n)← Sharecomp(s′; r′)

be the secret sharing of some arbitrary but fixed secret s′ with s 6= s′ and let b′i ← Leaki(sh
′
i) be the

corresponding leakage. By correctness of comp we have that (Sharecomp,Rec) is correct. This guarantees
that there exists a set I ⊆ [n] with |I| ≥ n− t+ 1 such that shi 6= sh′i for all i ∈ I. So it clearly holds that

Pr
Leak

[(b1, . . . , bn) = (b′1, . . . , b
′
n)] ≤ 2−`(n−t+1),

where the randomness is taken over a the random (Leak1, . . . ,Leakn).
Let coll be the event that there exists any (s′, r′) with s′ 6= s such that (b1, . . . , bn) = (Leak1(sh′1), . . . ,

Leakn(sh′n)) when (sh′1, . . . , sh
′
n)← Sharecomp(s′; r′). Observe that succ = ¬coll. By definition there are at

most 2ranS possible secret sharings. So, by a union bound we get that

Pr[coll] ≤ 2ranS−`(n−t+1)

Pr[¬coll] ≥ 1− 2ranS−`(n−t+1)

1− 2ranS−`(n−t+1) > 1/2

2ranS−`(n−t+1) < 1/2

ranS − `(n− t+ 1) < −1

`(n− t+ 1)− 1 > ranS

To prevent the attack described above, we therefore need that

ranS ≥ `(n− t+ 1)− 1 = `(n− t) + `− 1 ≥ `(n− t) ,

where we used that ` ≥ 1.

ďż˝

To illustrate the theorem, consider a secret sharing scheme with constant threshold t, share size p, which
tolerates leakage ` = (1− o(1))p. The theorem tells us that it must be the case that

ranS ≥ p(n− 2) ≈ pn .

So on average there are p bits of randomness in each share. In particular, after learning the constant number
of shares needed to reconstruct, there is still about p bits of randomness left in each share that was not used
for reconstructing. This quantifies that almost all randomness goes into achieving leakage-resilient and not
into privacy of the secret sharing.

As another example, consider a secret sharing scheme with t < cn for a constant c < 1/2 and ` = dp for
a constant d. We get that

ranS ≥ `(1− c)n .

We have that
n− t = (1− c)n

10



and thus
`(n− t) = dp(1− c)n .

So after learning t shares of length p the average number of bits of randomness left per share is at least

dp(1− c)n− tp
n− t

=
dp(1− c)n− cnp

(1− c)n
= p

d(1− c)− c
(1− c)

= p

(
d− c

(1− c)

)
.

So if
d >

c

(1− c)
there is still randomness left in the shares.

4 Leakage-Resilience of Shamir’s Secret Sharing

Benhamouda et al. [BDIR18] investigate the local leakage-resilience of Shamir’s secret sharing. Among other
results, the authors show that Shamir’s scheme is not leakage-resilient if either the number of parties is
constant or the secret sharing is done over a field with small characteristic. Using Fourier analytic techniques
and additive combinatorics they show that t-out-of-n Shamir secret sharing is (negl(n), blog q/4c)-W-IND-
LLR in prime order fields Fq, whenever t = n−O(log n). In the recently published full version of the same
paper3, the authors further show that it is 1-bit leakage-resilient for t ≈ 0.85n. They leave it open to find
other parameter ranges in which local leakage-resilience does or does not hold and postulate Conjecture 1,
which was already stated in the introduction.";"""date"",""2019-11-01T14:30:36Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2019-11-01T14:30:36Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.19 (TeX Live 2018) kpathsea version 6.3.0""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2019-11-01T14:30:36Z""
""created"",""2019-11-01T14:30:36Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-11-01T14:30:36Z""
""resourceName"",""181.pdf""
""Author"",""""
""producer"",""pdfTeX-1.40.19""
""pdf:docinfo:producer"",""pdfTeX-1.40.19""
""pdf:unmappedUnicodeCharsPerPage"",""11"",""7"",""6"",""13"",""9"",""36"",""53"",""25"",""28"",""39"",""5"",""6"",""1"",""37"",""36"",""15"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2019-11-01T14:30:36Z""
""Last-Modified"",""2019-11-01T14:30:36Z""
""dcterms:modified"",""2019-11-01T14:30:36Z""
""title"",""""
""Last-Save-Date"",""2019-11-01T14:30:36Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2019-11-01T14:30:36Z""
""meta:save-date"",""2019-11-01T14:30:36Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.19 (TeX Live 2018) kpathsea version 6.3.0""
""Content-Length"",""396052""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""17""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""3085"",""3823"",""2549"",""3153"",""2547"",""2474"",""1640"",""1656"",""2177"",""1855"",""2174"",""2001"",""3022"",""2356"",""2794"",""3341"",""2489""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-11-01T14:30:36Z""
";https://scholar.google.ch/scholar?start=890&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098747-62;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Die Verheißungen der Blockchain-Technologie—Autonome elektronische mehrwertsteuerrechtliche Sachverhaltsbeurteilung am Beispiel von grenzüberschreitenden …;R Müller ; UmsatzsteuerRundschau, 2020  degruyter.com;;"… Oracles … 21st Conference on Business Informatics (CBI), 1 f., 8 f. 34 In diesem Sinne: Wüst/Gervais

in IEEE Computer Society Conference Publishing Services (Hrsg.), 2018 Crypto Valley Conference

on Block- chain Technology (2018) Do you Need a Blockchain …";;null;null;;;;https://scholar.google.ch/scholar?start=610&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098888-388;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Anonymous proof-of-asset transactions using designated blind signatures;N Sharma, RA Sahu, V Saraswat… ; arXiv preprint arXiv …, 2020  arxiv.org;;"… In the realm of blockchain cryptocurrencies (ie, bitcoin-like digital cash schemes), the

aforementioned situation may appear in the so-called proof-of-asset transactions … A may obtain

responses from B, acting as a random oracle … Efficient blind signatures without random oracles …";Autres articles;;[PDF] arxiv.org;https://arxiv.org/pdf/2009.13978;"
ar
X

iv
:2

00
9.

13
97

8v
2 

 [
cs

.C
R

] 
 2

6 
O

ct
 2

02
0

Anonymous proof-of-asset transactions

using designated blind signatures

N. Sharma1, R. Anand-Sahu2, V. Saraswat3, J. Garcia-Alfaro4

1 Pt. Ravishankar Shukla University, India
2 University of Luxembourg, Luxembourg.

3 Robert Bosch Engineering & Business Solutions Pvt. Ltd., India.
4 Institut Polytechnique de Paris, Télécom SudParis, France.

Abstract. We propose a scheme to preserve the anonymity of users in proof-
of-asset transactions. We assume bitcoin-like cryptocurrency systems in which
a user must prove the strength of its assets (i.e., solvency), prior conducting
further transactions. The traditional way of addressing such a problem is the
use of blind signatures, i.e., a kind of digital signature whose properties satisfy
the anonymity of the signer. Our work focuses on the use of a designated verifier
signature scheme that limits to only a single authorized party (within a group
of signature requesters) to verify the correctness of the transaction.

Keywords: Blind signature schemes, Anonymity, Designated verification, Cryp-
tocurrencies, Identity-based Cryptography, Bilinear pairings.

1 Introduction

Blind signature schemes offer a practical way of handling privacy constraints in cryp-
tocurrencry transactions [3]. A blind signature construction is essentially an interactive
two-party protocol between the signer of a message and a group of signature requesters.
The signer disguises the contents of the message, before signing it. This way, the signa-
ture requesters can verify the correctness of the operation, without learning anything
about the message that has been signed. However, the validity of the signature can be
verified by anyone within the group of requesters. There may be situations in which
a particular signer wants to designate that just one entity in the group of receivers
must able to verify the signature (and not the others). This is the objective of DVS
(Designated Verifier Signature) schemes [9,13] addressed in this paper.

In the realm of blockchain cryptocurrencies (i.e., bitcoin-like digital cash schemes),
the aforementioned situation may appear in the so-called proof-of-asset transactions,
in which users must prove their solvency prior getting access to online services such as
cryptocurrency exchange markets. In other words, situations in which users must prove
that they control a given amount of assets (i.e., bitcoins) but without releasing the
specific amount they owe. In addition, we assume situations in which the users want to
uniquely designate who can verify those proof-of-asset transactions, e.g., to avoid that
a leakage of the proof is used by other parties (i.e., advertisement services, gambling
platforms, etc.).

We address the aforementioned challenges and present a designated verifier blind
signature (DVS) construction using pairing-based cryptography. The security of our
scheme relies on the hardness of the computational and the decisional bilinear Diffie-
Hellman problem (cf. Section 3.1). We analyze the security of the approach and perform
an efficiency comparison w.r.t. other existing similar approaches.

Paper Organization — Section 2 surveys related work. Section 3 provides some
preliminaries. Section 4 presents our construction and discusses about the security and
efficiency of our approach. Section 5 concludes the paper.

http://arxiv.org/abs/2009.13978v2


2 Related Work

Following seminal work by Chaum [3], Boldyreva [1] demonstrated and formalized the
concept of blind signature schemes under the random oracle model and the computa-
tional Diffie-Hellman assumptions. Work by Chow et al. [5] proved, as well, unlinkability
properties of blind signatures. Camenisch et al. [2] proposed new constructions with-
out random oracle constraints, without achieving proofs against strong unforgeability.
Liao et al. [11] provide new schemes under the hardness of strong Diffie-Hellman as-
sumptions. Zhang and Kim [18], followed by Huang et al. [8], proposed identity-based
blind signatures, achieving unlinkability. Zhang et al. [19] uncovered linkability attacks
in [8] (signers being traced back under valid message-signature pairs). Pointcheval and
Stern [12] settled fundamental security properties of blind signatures. Schröder et al. [14]
offer fair guidelines for the security of blind signatures. They revisit the definition of
unforgeability in [12] and propose a new unforgeability definition to avoid adversaries
repeating a message for more than one signature.

The public verifiability of a signature is undesirable when a signature shares sensitive
information between the signer and the verifier. To deal with this situation, the signer
requires to sign the document for a fixed receiver with control on its verification. For
this purpose, the idea of undeniable signature [4] was suggested by Chaum and Van
Antwerpen. Desmedt and Yung reported in [7] some weaknesses in the aforementioned
approach. Jakobsson et al. [9] proposed a non-interactive designated verifier proof which
enables the signer to produce transfer-resistant signatures for a designated verifier. In
other words, the verifier does not possess the capability to transfer the proof of origin
of the signature to third parties. Jakobsson et al. [9] also suggested the necessity of
keeping the anonymity of signers. A concrete construction satisfying such constraints
(i.e., impossibility of transfer to third parties and signer anonymity) was provided by
Saeednia et al. in [13]. Identity-based versions inspired by the previous approach were
presented by Susilo et al. in [15], and later by Zhang and Wen in [20]. Limitations in [20]
include the lack of proofs for unverifiability, non-transferability and strongness, and the
possibility of a signer with direct access to the original message to blind and unblind
messages and signatures, hence not fulfilling the standard definition settled in [3,12,14].
The construction presented in this paper addresses such shortcomings.

Bitcoin-like transaction anonymity has been addressed by Yi et al. proposing schemes
achieving blindness and unforgeability [17]. More recently, Wang et al. in [16] has pro-
posed the application of designated verifier blind signatures for bitcoin proof-of-asset
transactions. When a vendor requires to an anonymous buyer to provide a proof of
solvency prior enabling an online service (e.g., a certain amount of bitcoins), the buyer
provides a proof about it in designated manner. Hence, only the specific vendor re-
questing solvency to the user can process the signature. The vendor cannot further use
this proof with any other third party. Our new construction addresses the same prob-
lem, offering a more compact construction over pairings, improving the efficiency of the
identity-based construction by Zhang and Wen in [20], and satisfying unverifiability,
non-transferability and strongness properties (cf. Section 3 and citations thereof).

3 Preliminaries

3.1 Identity-Based Cryptography

A probabilistic polynomial time (PPT) algorithm is a probabilistic random algorithm

that runs in time polynomial in the length of input. y
$

← A(x) denotes a randomized

2



algorithm A(x) with input x and output y. For X being a set v
$

← X stands for a
random selection of v from X . A function f : N → [0, 1] is said to be negligible in n
if for any polynomial p and for sufficiently large n, the relation f(n) < 1/p(n) holds.
For an element g ∈ G, where G is a set, we denote the group G = 〈g〉 if g generates or
spans G.

Definition 1 (Bilinear Map). Let G1 and G2 be two cyclic groups with a prime
order q, where G1 is additive and G2 is multiplicative. Let P be the generator of G1.
Then a map e : G1 × G1 → G2 is said to be a cryptographic bilinear map if it fulfils
the below conditions.

Bilinearity: For all integers x, y ∈ Z∗
q , e(xA, yA) = e(A,A)xy, or equivalently, for all

A,B,C ∈ G1, e(A+B,C) = e(A,C)e(B,C) and e(A,B + C) = e(A,B)e(A,C).
Non-Degeneracy: The points A,B ∈ G1 with e(A,B) 6= 1. As G1 and G2 are prime
ordered groups this property is equivalent to have g := e(A,A) 6= 1, or in other words
g := e(A,A) is a generator of G2.
Computability: The map e(A,B) ∈ G2 can be computes efficiently for all A,B ∈ G1.

Definition 2 (Bilinear Map Parameter Generator). A bilinear map parameter
generator B is a PPT algorithm that takes as input security parameter Îť and outputs
a tuple

〈q, e : G1 ×G1 → G2, P, g〉 ← B(λ) (1)

where q, G1, G2, e, P and g are as in Definition 1.

Definition 3 (Bilinear Diffie-Hellman Problem). Given a security parameter Îť,
let

〈q, e, P, g〉 ← B(λ) .

Let BDH : G1 ×G1 ×G1 → G2 be a map defined by BDH(X,Y, Z) = ω where

X = xP, Y = yP, Z = zP and ω = e(P, P )xyz .

The bilinear Diffie-Hellman problem (BDHP) is to evaluateBDH(X,Y, Z) givenX,Y, Z
$

←
G1. (Without the knowledge of x, y, z ∈ Zq — obtaining x ∈ Zq, given P,X ∈ G1 is
solving the discrete logarithm problem (DLP)).

Definition 4 (BDHP Parameter Generator). A BDHP parameter generator C is
a PPT algorithm that takes as input security parameter Îť and outputs a tuple

〈q, e : G1 ×G1 → G2, P, g,X, Y, Z〉 ← C(λ) (2)

where q, G1, G2, e, P , g, X , Y and Z are as in Definition 3.

Definition 5 (Bilinear Diffie-Hellman Assumption). Given a security parameter
Îť, let

〈q, e, P, g,X, Y, Z〉 ← C(λ) .

. The bilinear Diffie-Hellman assumption (BDHA) states that for any PPT algorithm
A which attempts to solve BDHP, its advantage AdvC(Îť), defined as

Pr[A(q, e, P, g,X, Y, Z) = BDH(X,Y, Z)] ,

is negligible in Îť.

3



Definition 6 (Decisional BDHP). Given a security parameter Îť, let

〈q, e, P, g,X, Y, Z〉 ← C(λ) .

Let ω
$

← G2. The decisional bilinear Diffie-Hellman problem (DBDHP) is to decide if

ω = BDH(X,Y, Z) .

That is, if X = xP, Y = yP, Z = zP , for some x, y, z ∈ Zq, then the DBDHP is to
decide if

ω = e(P, P )xyz .

(Without the knowledge of x, y, z ∈ Zq — obtaining x ∈ Zq, given P,X ∈ G1 is solving
the discrete logarithm problem (DLP)).

Definition 7 (DBDHP Parameter Generator). A DBDHP parameter generator
D is a PPT algorithm that takes as input security parameter Îť and outputs a tuple

〈q, e : G1 ×G1 → G2, P, g,X, Y, Z, ω〉 ← D(λ) (3)

where q, G1, G2, e, P , g, X , Y , Z and ω are as in Definition 6.

Definition 8 (Decisional BDHA). Given a security parameter Îť, let

〈q, e, P, g,X, Y, Z, ω〉 ← D(λ) .

The bilinear Diffie-Hellman assumption (DBDHA) states that, for any PPT algorithm
A which attempts to solve DBDHP, its advantage AdvD(Îť), defined as

[
Pr[adva(q, e, P, g,X, Y, Z, ω) = 1]−
Pr[A(q, e, P, g,X, Y, Z,BDH(X,Y, Z)) = 1]

]
, (4)

is negligible in Îť.

3.2 Identity-based Strong Designated Verifier Blind Signatures

In this section, we provide formal definitions related with the construction of identity-
based strong designated verifier blind signature (hereinafter, ID-SDVBS) schemes [20].
In such schemes, a signer with identity IDS intends to send a signed message to a
designated verifier with identity IDV such that no one other than the designated verifier
can verify the signature. The scheme consists of the five algorithms described next:

1. params ← Setup(λ): Executed by the Private Key Generator (PKG), taking a se-
curity parameter Îť as input and producing, as output, the master secret s and the
public parameters (params) of the system. The remaining algorithms listed below
receive all the values of params as implicit inputs.

2. (QID, SID) ← Key Extract(ID): The PKG takes as input an identity ID and pro-
duces, as output, a public and private key pair (QID, SID).

3. σ ← DVBSig(SIDS
, QIDV

,m): Signer and user run this interactive process. Inputs
include the signer’s public and secret key (QIDS

, SIDS
), the designated verifier’s public

key QIDV
and a message m. Signer and user stop this process in polynomial time,

producing either a signature σ of m, or false (in case an error happens).

4



4. b ← DVBVer(SIDV
, QIDS

,m, σ): Run by the verifier, taking as inputs SIDV
(secret

key of the verifier), QIDS
(public key of the signer), a message m and a signature σ.

It returns a bit b which is 1 if the signature is valid (otherwise, it returns 0 if the
signature is invalid).

5. σ̂ ← DVBSim(QIDS
, SIDV

,m): Run by the verifier, it takes as inputs SIDV
(verifier’s

secret key), QIDS
and QIDV

(public keys of the signer and the designated verifier),
and a message m. It generates a signature σ̂ as output.

Next, we provide definitions about the properties we aim to satisfy.

Definition 9 (Correctness). If the signature σ on a messagem is correctly computed
by a signer IDS , then the designated verifier IDV must be able to verify the correctness
of the message-signature pair (m,σ). That is,

Pr
[
1← DVBVer

(
SIDV

, QIDS
,m,

DVBSig(QIDV
, SIDS

,m)

)]
= 1 .

Definition 10 (Unforgeability). An ID-SDVBS scheme is said to be strong existen-
tial unforgeable against adaptive chosen message and adaptive chosen identities attack
if for any security parameter Îť, no probabilistic polynomial time adversary A(Îť, t, Îľ,
qH1

, qH2
, qE , qS , qV ), which runs in time t, has a non-negligible advantage

Îľ := AdvSEUF-CID2-CMA2
ID-SDVBS,A (Îť)

:= Pr[1← DVBVer(SIDV ∗ , QIDS∗ ,m
∗, σ∗)]

against the challenger B in the following game:

1. Setup: The challenger B generates the systems public parameter params for security
parameter Îť.
2. Query Phase: – The adversary A may request upto qH1

hash queries on its adap-
tively chosen identities and upto and qH2

hash queries on its adaptively chosen mes-
sages and obtain responses from B acting as a random oracle.

– A may request upto qE key extraction queries on its adaptively chosen identities and
obtain the corresponding private keys.

– A may request upto qS signature queries on its adaptively chosen messages and
adaptively chosen identities for the signer and the designated verifier and obtain a
valid strong designated verifier signature.

– A may request upto qV verification queries on signatures on its adaptively chosen
messages m and adaptively chosen identities for the signer and the designated verifier
and obtain the verification result 1 if it is valid and 0 if invalid.

3. Output : Finally, A outputs a (message, signature) pair (m∗, σ∗) for identities ID∗

S of
the signer and ID∗

V of the designated verifier such that:

– A has never submitted ID∗

S or ID∗

V during the key extraction queries.
– σ∗ was never given as a response to a signature query on the message m∗ with the
signer’s identity ID∗

S , and the designated verifier’s identity ID∗

V ;
– σ∗ is a valid signature on the message m∗ from a signer with identity ID∗

S for a
designated verifier with identity ID∗

V .

Definition 11 (Unverifiability). An ID-SDVBS scheme is said to be existential
designated unverifiabile against adaptive chosen message and adaptive chosen identities
attack if for any security parameter Îť, no probabilistic polynomial time adversary A(Îť,

5



t, Îľ, qH1
, qH2

, qE , qS , qV ) which runs in time t has a non-negligible advantage

Îľ := AdvEDV-CID2-CMA2
ID-SDVBS,A (Îť)

:=
∣∣Pr[A(QIDS∗ , QIDV ∗ ,m

∗, σ∗) = 1]−

Pr[A(QIDS∗,QIDV ∗,m
∗,DVBSig(SIDS∗,QIDV ∗,m

∗))=1]
∣∣

against the challenger B’s response σ∗ in the following game:

1. Setup: Challenger B generates the system public parameters params from Îť.
2. Query Phase 1 : – AdversaryAmay request up to qH1

hash queries on its adaptively
chosen identities; and up to qH2

hash queries on its adaptively chosen messages. A
may obtain responses from B, acting as a random oracle.

– A may request upto qE key extraction queries on its adaptively chosen identities and
obtain the corresponding private keys.

– A may request upto qS signature queries on its adaptively chosen messages and
adaptively chosen identities for the signer and the designated verifier and obtain a
valid strong designated verifier signature.

– A may request upto qV verification queries on signatures on its adaptively chosen
messages m and adaptively chosen identities for the signer and the designated verifier
and obtain the verification result 1 if it is valid and 0 if invalid.

3. Challenge: At some point, A outputs a message m∗ and identitie ID∗

S of the signer
and ID∗

V of the designated verifier on which it wishes to be challenged such that A
has never submitted ID∗

S or ID∗

V during the key extraction queries. The challenger B
responds with a “signature” σ∗ and challenges A to verify if it is valid or not.
4. Query Phase 2 : A continues its queries as in Query Phase 1 with an additional
restriction that now it cannot submit a verification query on σ∗.
5. Output : A outputs a bit b∗ which is 1 if the signature is valid and 0 if invalid.

Definition 12 (Non-transferability). An ID-SDVBS scheme is said to achieve non-
transferability if the signature generated by the signer is computationally indistinguish-
able from that generated by the designated verifier, that is,

σ←DVBSig(QIDV
, SIDS

,m) ≈ σ̂←DVBSim(QIDS
, SIDV

,m).

Definition 13 (Strongness). An ID-SDVBS scheme is said to be strong designated
if given σ ← DVBSig(SIDS

, QIDV
,m), anyone, say V ∗, other than the designated verifier

V can produce identically distributed transcripts that are indistinguishable from those
of σ from someone, say S∗, except the signer S. That is,

σ←DVBSig(QIDV
, SIDS

,m) ≈ σ̂←DVBSim(QIDS∗ , SIDV ∗ ,m).

Definition 14 (Blindness). An ID-SDVBS scheme must ensure the fact that the
signer knows nothing about the message she signs. In other way, after producing sig-
natures on different messages, the signer cannot relate that which message corresponds
to which signature. More precisely, if signer has made a list of certain messages, and
the requests for signatures have been placed by the user by picking messages randomly
from that list, then after looking all the signatures together, the signer cannot make a
list of corresponding (messages, signature) pairs. Our security model for the blindness
is motivated by the models considered in [10,18]. Let A be a probabilistic polynomial
time adversary/algorithm which has control over the malicious signer. Let U1 and U2
be two honest users who interact with the signer in the following attack game.

1. A is provided responses to it’sKey extraction queries (QID, SID)← Key Extract(ID)
as in the security game for unforgeability.

6



2. A outputs messages m0,m1.
3. b ∈ {0, 1} is defined to be a bit. User U1 and U2 randomly selects a bit b and pick m

and m′ as their random input taps. Here m is corresponding to bit b and so as m′

corresponding to (b− 1).
4. A communicates with users U1 and U2 in the random order during the signature

issuing protocol.
5. If the user U1 does not fail and posses a signature σm and also user U2 does not fail

and posses signature σm′ , then A is provided these additional information σm and
σm′ , which are outputs essentially based on the bit b and (b− 1), the actual value of
the bit depends upon the value of b of-course. The game does not abort, and continue,
even if either of the users fails but the other does not, and the corresponding output
is forwarded to A in that case.

6. Finally, A outputs a bit b′ ∈ {0, 1} which is 1 if b′ = b.

We define advantage of the adversary A in the above game, by following

AdvBlind
A = (2× Pr[b′ = b])− 1

It is straightforward that A can always output a true bit with probability 1
2 . But, in

this case the advantage is clearly 0. A signature is said to satisfying blindness, if there
is no probabilistic polynomial-time algorithm/adversary A who wins the above game
with non-negligible advantage.

4 Proposed Construction

Find below the algorithms of our construction (Setup, Key Extract, Designated Blind
Signature DVBSig, Designated VerificationDVBVer and Transcript SimulationDVBSim):

– Setup – In this algorithm, on input security parameter λ PKG outputs the master
private key s ∈ Z∗

q and the public parameters

params = (1Îť, G1, G2, q, e,H1, H2, P, Ppub) ,

where G1 is an additive cyclic group of prime order q with generator P , G2 is a
multiplicative cyclic group of prime order q, and H1 : {0, 1}∗ → G1, H2 : {0, 1}∗ ×
G1 → Z∗

q are two cryptographic secure collision resistant hash functions, and Ppub =
sP ∈ G1 is system’s public key, e : G1 ×G1 → G2 is a bilinear map (cf. Section 3.1).

– Key Extract – On input identity IDi ∈ {0, 1}
∗, the PKG computes public key as

QIDi
= H1(IDi) ∈ G1 and private key as SIDi

= sQIDi
∈ G1, for this identity.

– DVBSig – Signs message m ∈ {0, 1}∗ (it can be verified by a designated verifier V ).

1. Signer S selects a random r
$

← Z∗
q and calculates:

- U = rQIDS
∈ G1;

2. As commitment, the signer sends the calculated value U to the user.
3. Blinding Phase: In this algorithm, user selects x, y ∈R Z∗

q as blinding factors.
Then calculates

- U ′ = xU + xyQIDS
;

- h = H2(m,U ′) ∈ Z∗
q ;

- h1 = x−1h+ y;
4. User sends this calculated value h1 to the signer.
5. Signing Phase: After receiving h1, the signer calculates

- V = (r + h1)SIDS
∈ G1; and sends back the user the value V .

7



6. Unblinding Phase: Then, the user calculates
- V ′ = xV
- σ = e(V ′, QIDV

). (U ′, σ) ∈ G1 ×G2 is the strong designated verifier blind signa-
ture on the message m.

– DVBVer – After receiving signature (U ′, σ) on a message m, a verifier computes
h = H2(m,U ′) ∈ Z∗

q and accepts the signature if σ = e(U ′ + hQIDS
, SIDV

).
– DVBSim – The designated verifier V can produce the same signature σ̂ intended for

itself, by performing this algorithm: chooses an integer r̂, x̂, ŷ
$

← Z∗
q and computes:

- Û = r̂QIDS
∈ G1;

- Û ′ = x̂U + x̂ŷQIDS
∈ G1;

- ĥ = H2(m, Û ′) ∈ Z∗
q ;

- ĥ1 = x̂−1ĥ+ ŷ;

- V̂ = (r̂ + ĥ1)QIDS
∈ G1;

- V̂ ′ = x̂V̂ ; and

- σ̂ = e(V̂ ′, SIDV
).

4.1 Security Analysis

The verification of our proposed scheme is as follows. If the generated signature (U ′, σ)
on a message m from a signer with identity IDS for a designated verifier with identity
IDV , then the proposed scheme follows:

e(U ′ + hQIDS
, SIDV

) = e(xU + xyQIDS
+ hQIDS

, SIDV
)

= e(xU + xyQIDS
+ hQIDS

, sQIDV
)

= e(xrQIDS
+ xyQIDS

+ hQIDS
, sQIDV

)

= e(x(rQIDS
+ yQIDS + x−1hQIDS

), sQIDV
)

= e(x(rSIDS
+ ySIDS

+ x−1hSIDS
), QIDV

)

= e(x(r + (x−1h+ y))SIDS
, QIDV

)

= e(x(r + h1)SIDS
, QIDV

)

= e(xV,QIDV
)

= e(V ′, QIDV
)

= σ .

Next, we discuss the achievement of the following security properties: (1) unforgeability,
(2) unverifiability, (3) non-transferability, (4) strongness and (5) blindness.

Theorem 1. (Unforgeability) Given a security parameter Îť, if there exists a PPT ad-
versary A(Îť, t, Îľ, qH1

, qH2
, qE , qS , qV ) which breaks the unforgeability of the proposed ID-

SDVBS scheme in time t with success probability Îľ, then there exists a PPT adversary
B(λ, t′, ε′) which solves BDHP with success probability at least

ε′ ≥
(
1−

1

q2

)(
1−

2

qH1

)qE+qV

(
1−

2

qH1
(qH1

− 1)

)qS( 2

qH1
(qH1

− 1)

)
Îľ

8



in time at most

t′ ≤(qH1
+ qE + 3qS + qV )SG1

+ (qS + qV )Pe + qSOG1
+OG2

+ SG2
+ t

where SG1
(resp. SG2

) is the time taken for one scalar multiplication in G1 (resp. G2),
OG1

(resp. OG2
) is the time taken for one group operation in G1 (resp. G2), and Pe is

the time taken for one pairing computation.

Proof of Theorem 1: Let for a security parameter Îť, B is challenged to solve the
BDHP for

〈q, e,G1, G2, P, aP, bP, cP 〉

where G1 is an additive cyclic group of prime order q with generator P , G2 is a multi-
plicative cyclic group of prime order q with generator e(P, P ), and e : G1 × G1 → G2

is a cryptographic bilinear map (cf. Section 3.1). a, b, c
$

← Z∗
q are unknown to B. The

goal of B is to solve BDHP by computing e(P, P )abc ∈ G2 using A, the adversary who
claims to forge our proposed ID-SDVBS scheme. B simulates the security game for
unfogeability with A as follows.

Setup: B generates the systems public parameter

params = 〈q, e : G1 ×G1 → G2, P, Ppub := cP,H1, H2〉

for security parameter Îť where the hash functions H1 and H2 behave as random oracles
and responds to A’s queries as below.
H1-queries : To respond to the H1 queries, B maintains a list

LH1
= {(IDi ∈ {0, 1}

∗, ri ∈ Z
∗
q , Ri ∈ G1)

qH1

i=1}

which is initially empty. B randomly chooses two indices ι, β ∈ [1, qH1
] and sets i = 0.

When A makes an H1-query for an identity ID ∈ {0, 1}∗ B proceeds as follows.
1. If the query ID already appears in LH1

in some tuple (IDi, ri, Ri) then B responds
to A with H1(ID) = Ri ∈ G1;

2. otherwise B sets i = i+ 1 and
– if i = α, B sets ri =⊥ and Ri = aP ;
– if i = β, B sets ri =⊥ and Ri = bP ;

– if i 6= α, β, B chooses ri
$

← Z
∗
q and sets Ri = riP ;

3. Finally, B adds the tuple (IDi := ID, ri, Ri) to LH1
and responds to A with H1(ID) =

Ri.
H2-queries : For response of H2 queries, B maintains a list

LH2
= {((m,U ′) ∈ {0, 1}∗ ×G1, h ∈ Z

∗
q)}

initially which is empty. When A queries the oracleH2 at (m,U ′), B responds as follows.
1. If the query (m,U ′) already appears in the H2-list in the tuple (m,U ′, h) then B

respond with H2(m,U ′) = h ∈ Z∗
q .

2. Otherwise B picks a random h ∈ Z
∗
q and adds the tuple (m,U ′, h) to the H2-list and

responds to A with H2(m,U ′) = h.
Key extraction queries : When A makes a private key query on identity ID, B proceeds
as follows.
1. Runs the above algorithm for responding to H1-query for identity ID and obtains

H1(ID) = Ri.

9



2. If i = ι or β, B reports failure and halts.
3. If i 6= ι, β, B responds to A with the private key SID := riPpub on the identity ID.
It can be verified that the provided private key SID = riPpub is a valid private key for
the user with identity IDi := ID since

riPpub = ricP = criP = cH1(ID) .

Note that B aborts the security game during a key extraction query with probability
2

qH1

.

Signature queries : To respond to the signature queries, B maintains a list

LS = {(mℓ ∈ {0, 1}
∗, IDSℓ ∈ {0, 1}

∗, IDV ℓ ∈ {0, 1}
∗,

xℓ ∈ Z
∗
q , U

′
ℓ ∈ G1, σℓ ∈ G2)

qS
ℓ=1}

which is initially empty with ℓ = 0. When A queries the signature on a message m
from a signer with identity IDS for a designated verifier with identity IDV , B proceeds
as follows.
1. If the query (m, IDS , IDV) already appears in LS in some tuple (mℓ, IDSℓ, IDV ℓ, xℓ, U

′
ℓ,

σℓ) then B responds to A with the signature (U ′
ℓ, σℓ).

2. Otherwise B sets ℓ = ℓ+1 and for responding to H1-query for identities IDS and IDV

runs the above algorithm and obtains H1(IDS) = Ri and H1(IDV) = Rj .
3. If {i, j} = {ι, β}, B reports failure and halts.
4. If i 6= ι, β, then B computes the private key for IDS , SIDS

= riPpub and proceeds as
follows.
– randomly chooses xℓ ∈ Z∗

q ;
– sets U ′

ℓ = xℓP ∈ G1;
– runs the H2-query algorithm to obtain hℓ = H2(m,U ′

ℓ) ∈ Z∗
q ;

– sets V ′
ℓ = xℓPpub + hℓSIDS

∈ G1;
– computes σℓ = e(V ′

ℓ , QIDj
= Rj).

5. Otherwise if j 6= ι, β, then B computes the private key IDV , SIDV
= rjPpub and

proceeds as follows.
– randomly chooses xℓ ∈ Z

∗
q ;

– sets U ′
ℓ = xℓP ∈ G1;

– runs the H2-query algorithm to obtain hℓ = H2(m,U ′
ℓ) ∈ Z∗

q ;
– sets V ′

ℓ = xℓPpub + hℓSIDV
∈ G1;

– computes σℓ = e(V ′
ℓ , QIDi

= Ri).
6. Finally, B adds the tuple (mℓ, IDSℓ, IDVℓ, xℓ, U

′
ℓ, σℓ) to LS and responds to A with

the signature (U ′
ℓ, σℓ).

Note that B aborts the security game during a signature query with probability 2
qH1

(qH1
−1) .

Verification queries : When A makes a verification query on the signature (U ′, σ) on a
message m from a signer with identity IDS for a designated verifier with identity IDV ,
B proceeds as follows.
1. B runs the above algorithm for responding to H1-query for identities IDS and IDV

and obtains H1(IDS) = Ri and H1(IDV) = Rj .
2. If j ∈ {ι, β}, B reports failure and halts.
3. If j 6= α, β, then B computes IDV ’s private key, SIDV

= rjPpub , and proceeds as in the
verification of the proposed scheme and responds to A accordingly.

Note that B aborts the security game during a verification query with probability 2
qH1

.

Output : After A has made its queries, it finally outputs a valid signature (U
′
∗, σ∗) on

a message m∗ from a signer with identity ID∗

S for a designated verifier with identity ID∗

V

with a non-negligible probability Îľ such that:

10



– A has never submitted ID∗

S or ID∗

V during the key extraction queries;

– (U
′
∗, σ∗) was never given as a response to a signature query on the message m∗ with

the signer’s identity ID∗

S , and the designated verifier’s identity ID∗

V ; and

– σ∗ = e(U
′
∗ + h∗QIDS

, SIDV
).

If A did not make H1-query for the identities ID∗

S and ID∗

V , then the probability
that verification equality holds is less than 1/q2. Thus, with probability greater than
1 − 1/q2, both the public keys were computed using H1-oracle and there exist indices
i, j ∈ [1, qH1

] such that ID∗

S = IDi and ID∗

V = IDj . If {i, j} 6= {ι, β}, then B reports
failure and terminates.

Solution to BDHP: Otherwise, as in the forking lemma, B repeats the game with the
same random tape for xℓ but with different choices of a random set for H2-queries
to obtain another forgery (U∗, σ′) on the message m∗ with h′ such that h∗ 6= h′ and
σ∗ 6= σ′. Then,

σ∗

σ′
=

e(U
′
∗ + h∗QIDS

, SIDV
)

e(U ′∗ + h′QIDS
, SIDV

)

=
e(h∗QIDS

, SIDV
)

e(h′QIDS
, SIDV

)

=
e(QIDS

, SIDV
)h

∗

e(QIDS
, SIDV

)h′
(5)

= e(QIDS
, SIDV

)(h
∗
−h′)

= e(aP, bcP )(h
∗
−h′)

= (e(P, P )abc)(h
∗
−h′) . (6)

Let (h∗−h′)−1 mod q = ĥ. Then, from the above equation, B solves the BDHP by
computing

e(P, P )abc = (σ∗/σ′)ĥ (7)

Probability calculation: If B does not abort during the simulation then A’s view is
identical to its view in the real attack. The responses to H1-queries and H2-queries are
as in the real attack, since each response is uniformly and independently distributed
in G1 and Z∗

q respectively. The key extraction, signature and verification queries are
answered as in the real attack.

The probability that B does not abort during the simulation is

(
1−

2

qH1

)qE+qV (
1−

2

qH1
(qH1

− 1)

)qS

. (8)

The probability that A did H1-query for the identities ID∗

S and ID∗

V and that
{ID∗

S , ID
∗

V} = {IDι, IDβ} is

(
1−

1

q2

)( 2

qH1
(qH1

− 1)

)
. (9)

Clearly B’s advantage ε′ for solving the BDHP, that is, the total probability that
B succeeds to solve BDHP, is the product of A’s advantage ε of forging the proposed

11



ID-SDVBS and the above two probabilities. Hence

ε′ ≥
(
1−

1

q2

)(
1−

2

qH1

)qE+qV

(
1−

2

qH1
(qH1

− 1)

)qS( 2

qH1
(qH1

− 1)

)
Îľ .

Time calculation: It can be observed that running time of the algorithm B is same
as that of A plus time taken to respond to the hash queries, key extraction queries,
signature queries and verification queries, qH1

+qH2
+qE+qS+qV . Hence the maximum

running time required by B to solve the BDHP is

t′ ≤(qH1
+ qE + 3qS + qV )SG1

+ (qS + qV )Pe

+ qSOG1
+OG2

+ SG2
+ t

as B requires to compute one scalar multiplication in G1 to respond to H1 hash query,
one scalar multiplication in G1 to respond to key extraction query, three scalar multipli-
cations in G1 to respond to signature query, one scalar multiplication in G1 to respond
to verification query; one pairing computation to respond to signature query, one pair-
ing computation to respond to verification query, one group operation in G1 to respond
to signature query, and, one group operation in G2 and one scalar multiplication in G2

to output a solution of BDHP. ⊓⊔

Theorem 2. (Unverifiability) Given a security parameter Îť, if there exists a PPT
adversary A(Îť, t, Îľ, qH1

, qH2
, qE , qS , qV ) which breaks the designated unverifiability of

the proposed ID-SDVBS scheme in time t with success probability Îľ, then there exists a
PPT adversary B(Îť, tâ";"""date"",""2020-10-27T04:22:32Z""
""pdf:PDFVersion"",""1.4""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.4""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""xmp:CreateDate"",""2020-10-27T00:22:32Z""
""modified"",""2020-10-27T04:22:32Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""xmp:ModifyDate"",""2020-10-27T00:22:32Z""
""pdf:docinfo:creator"",""""
""meta:author"",""""
""meta:creation-date"",""2020-10-27T04:22:32Z""
""created"",""2020-10-27T04:22:32Z""
""xmp:About"",""uuid:94ea2b5d-5028-11f6-0000-f381c807914a""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-10-27T04:22:32Z""
""resourceName"",""2009.13978""
""Author"",""""
""producer"",""dvips + GPL Ghostscript GIT PRERELEASE 9.22""
""pdf:docinfo:producer"",""dvips + GPL Ghostscript GIT PRERELEASE 9.22""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""12"",""8"",""6"",""6"",""0"",""32"",""5"",""4"",""11"",""18"",""9"",""28"",""0"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2020-10-27T04:22:32Z""
""Last-Modified"",""2020-10-27T04:22:32Z""
""dcterms:modified"",""2020-10-27T04:22:32Z""
""title"",""""
""xmpMM:DocumentID"",""uuid:94ea2b5d-5028-11f6-0000-f381c807914a""
""Last-Save-Date"",""2020-10-27T04:22:32Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2020-10-27T04:22:32Z""
""meta:save-date"",""2020-10-27T04:22:32Z""
""Content-Length"",""249870""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""17""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""2868"",""3185"",""1826"",""1871"",""2448"",""2780"",""2136"",""1410"",""1862"",""2152"",""1631"",""2045"",""1496"",""2107"",""2088"",""3074"",""2424""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-10-27T04:22:32Z""
";https://scholar.google.ch/scholar?start=930&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098831-256;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;A Holistic Systems Security Approach Featuring Thin Secure Elements for Resilient IoT Deployments;S Ramalingam, H Gan, G Epiphaniou, E Mistretta ; Sensors, 2020  mdpi.com;;"… It benefits from low power demand and small footprint as a crypto processor as well as is

compatible with IoT requirements. Subsequently, a key agreement based on an asymmetric

cryptographic scheme, namely B-SPEKE was used to validate and authenticate the source …";Autres articles;;[PDF] mdpi.com;https://www.mdpi.com/1424-8220/20/18/5252/pdf;;;https://scholar.google.ch/scholar?start=800&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098888-389;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Pixel: Multi-signatures for consensus;M Drijvers, S Gorbunov, G Neven, H Wee ; 29th {USENIX} Security …, 2020  usenix.org;;"… savings for stor- age, bandwidth, and block verification time from using Pixel on the Algorand

PoS blockchain … the public key pk to the adversary A. The adversary is given access to the following

oracles … time period t (initially set to t = 1) is less than T, then this oracle updates the …";Cité 10 fois;Les 4 versions;[PDF] usenix.org;https://www.usenix.org/system/files/sec20summer_drijvers_prepub_0.pdf;"
Pixel: Multi-signatures for Consensus

Manu Drijvers
DFINITY

Sergey Gorbunov
Algorand and University of Waterloo

Gregory Neven
DFINITY

Hoeteck Wee∗

Algorand and CNRS, ENS, PSL

Abstract
In Proof-of-Stake (PoS) and permissioned blockchains, a com-
mittee of verifiers agrees and sign every new block of trans-
actions. These blocks are validated, propagated, and stored
by all users in the network. However, posterior corruptions
pose a common threat to these designs, because the adversary
can corrupt committee verifiers after they certified a block
and use their signing keys to certify a different block. De-
signing efficient and secure digital signatures for use in PoS
blockchains can substantially reduce bandwidth, storage and
computing requirements from nodes, thereby enabling more
efficient applications.

We present Pixel, a pairing-based forward-secure multi-
signature scheme optimized for use in blockchains, that
achieves substantial savings in bandwidth, storage require-
ments, and verification effort. Pixel signatures consist of two
group elements, regardless of the number of signers, can be
verified using three pairings and one exponentiation, and sup-
port non-interactive aggregation of individual signatures into
a multi-signature. Pixel signatures are also forward-secure
and let signers evolve their keys over time, such that new keys
cannot be used to sign on old blocks, protecting against pos-
terior corruptions attacks on blockchains. We show how to
integrate Pixel into any PoS blockchain. Next, we evaluate
Pixel in a real-world PoS blockchain implementation, show-
ing that it yields notable savings in storage, bandwidth, and
block verification time. In particular, Pixel signatures reduce
the size of blocks with 1500 transactions by 35% and reduce
block verification time by 38%.

1 Introduction

Blockchain technologies are quickly gaining popularity for
payments, financial applications, and other distributed appli-
cations. A blockchain is an append-only public ledger that is
maintained and verified by distributed nodes. At the core of
the blockchain is a consensus mechanism that allows nodes
∗Authors are listed alphabetically.

to agree on changes to the ledger, while ensuring that changes
once confirmed cannot be altered.

In the first generation of blockchain implementations, such
as Bitcoin, Ethereum, Litecoin, the nodes with the largest
computational resources choose the next block. These im-
plementations suffer from many known inefficiencies, low
throughput, and high transaction latency [17, 27, 49]. To over-
come these problems, the current generation of blockchain im-
plementations such as Algorand, Cardano, Ethereum Casper,
and Dfinity turn to proofs of stake (PoS), where nodes with
larger stakes in the system —as measured, for instance, by the
amount of money in their account— are more likely to partic-
ipate in choosing the next block [21,24,29,32,34,39,47]. Per-
missioned blockchains such as Ripple [54] and Hyperledger
Fabric [4] take yet another approach, sacrificing openness
for efficiency by limiting participation in the network to a
selected set of nodes.

All PoS-based blockchains, as well as permissioned ones,
have a common structure where the nodes run a consensus
sub-protocol to agree on the next block to be added to the
ledger. Such a consensus protocol usually requires nodes
to inspect block proposals and express their agreement by
digitally signing acceptable proposals. When a node sees
sufficiently many signatures from other nodes on a particular
block, it appends the block to its view of the ledger.

Because the consensus protocol often involves thousands
of nodes working together to reach consensus, efficiency of
the signature scheme is of paramount importance. Moreover,
to enable outsiders to efficiently verify the validity of the
chain, signatures should be compact to transmit and fast to
verify. Multi-signatures [35] have been found particularly
useful for this task, as they enable many signers to create
a compact and efficiently verifiable signature on a common
message [15, 40, 58, 59].

The Problem of Posterior Corruptions. Chain integrity
in a PoS blockchain relies on the assumption that the adver-
sary controls less than a certain threshold (e.g., a third) of the
total stake; an adversary controlling more than that fraction



may be able to fork the chain, i.e., present two different but
equally valid versions of the ledger. Because the distribution
of stake changes over time, however, the real assumption be-
hind chain integrity is not just that the adversary currently
controls less than a threshold of the stake, but that he never
did so at any time in the past.

This assumption becomes particularly problematic if stake
control is demonstrated through possession of signature keys,
as is the case in many PoS and permissioned blockchains.
Indeed, one could expect current stakeholders to properly
protect their stake-holding keys, but they may not continue to
do so forever, especially after selling their stake. Nevertheless,
without additional precautions, an adversary who obtains keys
that represent a substantial fraction of stake at some point in
the past can compromise the ledger at any point in the future.
The problem is further aggravated in efficient blockchains that
delegate signing rights to a small committee of stakeholders,
because the adversary can gain control of the chain after
corrupting a majority of the committee members.

Referred to by different authors as long-range attacks [20],
costless simulation [52], and posterior corruptions [12], this
problem is best addressed through the use of forward-secure
signatures [3,9,41,46]. Here, each signature is associated with
the current time period, and a user’s secret key can be updated
in such a way that it can only be used to sign messages for
future time periods, not previous ones. An adversary that cor-
rupts an honest node can therefore not use the compromised
key material to create forks in the past of the chain.

1.1 Our Results

We present the Pixel signature scheme, which is a pairing-
based forward-secure multi-signature scheme for use in PoS-
based blockchains that achieves substantial savings in band-
width and storage requirements. To support a total of T
time periods and a committee of size N, the multi-signature
comprises just two group elements and verification requires
only three pairings, one exponentiation, and N−1 multipli-
cations. Pixel signatures are almost as efficient as BLS multi-
signatures, as depicted in Figure 1, but also satisfy forward-
security; moreover, like in BLS multi-signatures, anybody
can non-interactively aggregate individual signatures into a
multi-signature.

Our construction builds on prior forward-secure signatures
based on hierarchical identity-based encryption (HIBE) [14,
18,22,26] and adds the ability to securely aggregate signatures
on the same message as well as to generate public parameters
without trusted set-up.

We achieve security in the random oracle model under a
variant of the bilinear Diffie-Hellman inversion assumption
[11, 14]. At a very high level, the use of HIBE techniques
allows us to compress O(logT ) group elements in a tree-
based forward-secure signature into two group elements, and
secure aggregation allows us to compress N signatures under

N public keys into a single multi-signature of the same size
as a single signature.

To validate Pixel’s design, we compared the performance
of a Rust implementation [1] of Pixel with previous forward-
secure tree-based solutions. We show how to integrate Pixel
into any PoS blockchain. Next, we evaluate Pixel on the Al-
gorand blockchain, showing that it yields notable savings in
storage, bandwidth, and block verification time. Our exper-
imental results show that Pixel is efficient as a stand-alone
primitive and in use in blockchains. For instance, compared
to a set of N = 1500 tree-based forward-secure signatures
(for T = 232) at 128-bit security level, a single Pixel signature
that can authenticate the entire set is 2667x smaller and can
be verified 40x faster (c.f. Tables 1 and 3). Pixel signatures
reduce the size of Algorand blocks with 1500 transactions
by ≈ 35% and reduce block verification time by ≈ 38% (c.f.
Figures 3 and 4).

1.2 Related Work

Multi-signatures can be used to generate a single short sig-
nature validates that a message m was signed by N different
parties [6,10,13,31,35,43,44,48,50], Multi-signatures based
on the BLS signature scheme [13, 15, 16, 53] are particularly
well-suited to the distributed setting of PoS blockchains as
no communication is required between the signers; anybody
can aggregate individual signatures into a multi-signature.
However, these signatures are not forward-secure.

Tree-based forward-secure signatures [9, 36, 41, 46] can be
used to meet the security requirements, but they are not very
efficient in an N-signer setting because all existing construc-
tions have signature size at least O(N logT ) group elements,
where T is an upper bound on the number of time periods.
Some schemes derived from hierarchical identity-based en-
cryption (HIBE) [14, 18, 22] can bring that down to O(N)
group elements, which is still linear in the number of signers.

The only forward-secure multi-signature schemes that ap-
peared in the literature so far have public key length linear
in the number of time periods T [45] or require interaction
between the signers to produce a multi-signature [55], neither
of which is desirable in a blockchain scenario. The forward-
secure multi-signature scheme of Yu et al. [61] has signature
length linear in the number of signers, so is not really a multi-
signature scheme.

Combining the generic tree-based forward-secure signature
scheme of Bellare-Miner [9] with BLS multi-signatures [13,
16] gives some savings, but still requires O(T ) “certificates”
to be included in each multi-signature. Batch verification [8]
can be used to speed up verification of the certificates to some
extent, but does not give us any space savings. Compared with
existing tree-based forward-secure signatures in [9,36,41,46],
our savings are two-fold:

• we reduce the size of the signature set for N commit-



scheme key update sign verify |σ| |pk| |sk| forward security
BLS multi-signatures [13, 15, 53] – 1 exp 2 pair 1 1 O(1) no
Pixel multi-signatures (this work) 2 exp 4 exp 3 pair + 1 exp 2 1 O((logT )2) yes

Figure 1: Comparing our scheme with BLS signatures. Here, “exp” and “pair” refer to number of exponentiations and pairings
respectively. T denotes the maximum number of time periods. We omit additive overheads of O(logT ) multiplications. The
column “key update” refers to amortized cost of updating the key for time t to t +1. The columns |σ|, |pk|, and |sk| denote the
sizes of signatures, public keys, and secret keys, respectively, in terms of group elements. Aggregate verification for N signatures
requires an additional N−1 multiplications over basic verification.

tee members from O(N logT ) group elements1 to O(1)
group elements; and

• we reduce the verification time from O(N) exponentia-
tions to O(1) exponentiation and O(N) multiplications.

1.3 Paper Organization

The rest of this paper is organized as follows:

• In Section 2, we give a high level technical description
of our new pairing-based forward-secure multi-signature
scheme.

• In Sections 4 and 5, we describe the scheme in details.
We prove the security of the construction in the random
oracle model under a variant of a bilinear Diffie-Hellman
inversion problem.

• In Section 6, we explain how to apply Pixel to PoS
blockchains to solve posterior corruptions.

• In Section 7, we evaluate the efficiency savings for stor-
age, bandwidth, and block verification time from using
Pixel on the Algorand PoS blockchain.

2 Technical Overview

Our construction builds on prior forward-secure signatures
based on hierarchical identity-based encryption (HIBE) [14,
18,22,26] and adds the ability to securely aggregate signatures
on the same message as well as to generate public parameters
without trusted set-up.

Overview of our scheme. Starting with a bilinear group
(G1,G2,Gt) with e : G1 ×G2 → Gt of prime order q and
generators g1,g2 for G1,G2 respectively, a signature on M ∈
Zq at time t under public key gx

2 is of the form:

σ = (σ′,σ′′) = (hx ·F(t,M)r,gr
2) ∈G1×G2

1 Each tree-based signature comprise O(logT ) group elements corre-
sponding to a path in a tree of depth logT (see Section 7 for details), and
there are N such signatures, one for which committee member.

where the function F(t,M) can be computed with some public
parameters (two group elements in G1 in addition to h ∈G1)
and r is fresh randomness used for signing. Verification relies
on the relation:

e(σ′,g2) = e(h,y) · e(F(t,M),σ′′)

and completeness follows directly:

e(σ′,g2) = e(hx ·F(t,M)r,g2)

= e(hx,g2) ¡ e(F(t,M)r,g2)

= e(h,gx
2) ¡ e(F(t,M),gr

2)

= e(h,y) · e(F(t,M),σ′′) .

Note that e(h,y) can be precomputed to save verification
computation.

Given N signatures σ1, . . . ,σN ∈ G1 ×G2 on the same
message M at time t under N public keys gx1

2 , . . . ,gxN
2 , we

can produce a multi-signature ÎŁ on M by computing the
coordinate-wise product of σ1, . . . ,σN . Concretely, if σi =
(hxi ¡F(t,M)ri ,gri

2 ), then

Σ = (hx1+···+xN ·F(t,M)r′ ,gr′
2 )

where r′ = r1+ · · ·+rN . To verify Σ, we first compute a single
aggregate public key that is a compressed version of all N
individual public keys

apk← y1 · . . . · yN ,

and verify ÎŁ against apk using the standard verification equa-
tion.

How to generate and update keys. To complete this
overview, we describe a simplified version of the secret keys
and update mechanism, where the secret keys are of size O(T )
instead of O((logT )2). The construction exploits the fact that
the function F satisfies

F(t,M) = F(t,0) ·F ′M

for some constant F ′. This means that in order to sign mes-
sages at time t, it suffices to know

s̃kt = {hx ·F(t,0)r,F ′r,gr
2}



from which we can compute (hx ¡F(t,M)r,gr
2).

The secret key skt for time t is given by:

s̃kt , s̃kt+1, ¡ ¡ ¡ , s̃kT

generated using independent randomness. To update from
the key skt to skt+1, we simply erase s̃kt . Forward security
follows from the fact that an adversary who corrupts a signer
at time t only learns skt and, in particular, does not learn s̃kt ′

for t ′ < t, and is unable to create signatures for past time slots.
To compress the secret keys down to O((logT )2) without

increasing the signature size, we combine the tree-based ap-
proach in [22] with the compact HIBE in [14]. Roughly speak-
ing, each skt now contains logT sub-keys, each of which con-
tains O(logT ) group elements and looks like an “expanded”
version of s̃kt . (In the simplified scheme, each skt contains
T − t +1 sub-keys, each of which contains three group ele-
ments.)

Security against rogue-key attacks. The design of multi-
signature schemes must take into account rogue-key attacks,
where an adversary forges a multi-signature by providing
specially crafted public keys that are correlated with the public
keys of the honest parties. We achieve security against rogue-
key attacks by having users provide a proof of possession
of their secret key [13, 53]; it suffices here for each user to
provide a standard BLS signature y′ on its public key y (cf.
the proof π in the key generation and verification algorithms
in Section 5.2).

Avoiding trusted set-up. Note that the common parame-
ters contain uniformly random group elements h,h0, . . . ,hlogT
in G2 which are used to define the function F . These elements
can be generated using a indifferentiable hash-to-curve algo-
rithm [19,60] evaluated on some fixed sequence of inputs (e.g.
determined by the digits of pi), thereby avoiding any trusted
set-up.

2.1 Discussion
Related works. The use of HIBE schemes for forward se-
crecy originates in the context of encryption [22] and has
been used in signatures [18,26], key exchange [33] and proxy
re-encryption [30]. Our signature scheme is quite similar
to the forward-secure signatures of Boyen et al. [18] and
achieves the same asymptotic complexity; their construction
is more complex in order to achieve security against untrusted
updates. The way we achieve aggregation is similar to the
multi-signatures in [43].

Alternative approaches to posterior security. There are
two variants of the posterior attack: (i) a short-range vari-
ant, where an adversary tries to corrupt a committee mem-
ber prior to completion of the consensus sub-protocol, and

(ii) a long-range variant as explained earlier. Dfinity [34],
Ouroboros [39] and Casper [21] cope with the short-range
attacks by assuming a delay in attacks that is longer than the
running time of the consensus sub-protocol. For long-range
attacks, Casper adopts a fork choice rule to never revert a final-
ized block, and in addition, assumes that clients log on with
sufficient regularity to gain a complete update-to-date view of
the chain. We note that forward-secure signatures provide a
clean solution against both attacks, without the need for fork
choice rules or additional assumptions about the adversary
and the clients.

Application to permissioned blockchains. Consensus
protocols, such as PBFT, are also at the core of many per-
missioned blockchains (e.g. Hyperledger), where only ap-
proved parties may join the network. Our signature scheme
can similarly be applied to this setting to achieve forward
secrecy, reduce communication bandwidth, and produce com-
pact block certificates.

3 Preliminaries

Let G1,G2,Gt be multiplicative groups of prime order q with
a non-degenerate pairing function e : G1×G2→Gt. Let g1
and g2 be generators of G1 and G2, respectively.

In analogy with the weak bilinear Diffie-Hellman inver-
sion problem `-wBDHI∗ [14], which was originally defined
for Type-1 pairings (i.e., symmetric pairings where we have
G1 =G2), we define the following variant for Type-3 pairings
denoted `-wBDHI∗3.

Input: A1 = gÎą
1 , A2 = g(Îą

2)
1 , . . . , A` = g(Îą

`)
1 ,

B1 = gÎą
2 , B2 = g(Îą

2)
2 , . . . , B` = g(Îą

`)
2 ,

C1 = gÎł

1 , C2 = gÎł

2

for α,γ←$ Zq

Compute: e(g1,g2)
(γ¡ι`+1)

The advantage Adv`-wBDHI∗3
G1×G2

(A) of an adversary A is defined
as its probability in solving this problem.

As shown in [14], the assumption holds in the generic bi-
linear group model, with a lower bound of Ω(

√
q/`) (with

a matching attack in [25]). Concretely, for the BLS12-381
pairing-friendly curve with `= 32, the best attack has com-
plexity roughly 2125.

Alternatively, our scheme could be proved secure under a
variant of the above assumption where the adversary has to

output g(Îą
`+1)

1 given as input A1, . . . ,A`,B1, . . . ,B` and given
access to an oracle ψ : gx

2 7→ gx
1. Because of the ψ oracle,

this assumption is incomparable to the `-wBDHI assumption
described above.



4 Forward-Secure Signatures

We begin by describing a forward-secure signature scheme,
and then extend the construction to a multi-signature scheme
in Section 5.

4.1 Definition
We use the Bellare-Miner model [9] to define syntax and
security of a forward-secure signature scheme. A forward-
secure signature scheme FS for a message spaceM consists
of the following algorithms:

Setup: pp←$ Setup(T ). All parties agree on the public pa-
rameters pp. The setup algorithm mainly fixes the distribu-
tion of the parameters given the maximum number of time
periods T . The parameters may be generated by a trusted
third party, through a distributed protocol, or set to “nothing-
up-my-sleeve” numbers. The public parameters are taken to
be an implicit input to all of the following algorithms.

Key generation: (pk,sk1)←$ Kg. The signer runs the key
generation algorithm on input the maximum number of time
periods T to generate a public verification key pk and an
initial secret signing key sk1 for the first time period.

Key update: skt+1←$ Upd(skt). The signer updates its secret
key skt for time period t to skt+1 for the next period using
the key update algorithm. The scheme could also offer a
“fast-forward” update algorithm skt ′ ←$ Upd′(skt , t ′) for any
t ′ > t that is more efficient than repetitively applying Upd.

Signing: σ←$ Sign(skt ,M). On input the current signing key
skt and message M ∈M, the signer uses this algorithm to
compute a signature σ.

Verification. b← Vf(pk, t,M,σ). Anyone can verify a sig-
nature σ for on message M for time period t under public
key pk by running the verification algorithm, which returns 1
to indicate that the signature is valid and 0 otherwise.

Correctness.

Correctness requires that for all messages M ∈M and for all
time periods t ∈ [T ] it holds that

Pr[Vf(pk, t,M,Sign(skt ,M)) = 1] = 1

where the coin tosses are over pp←$ Setup(T ), (pk,sk1)←$

Kg, and ski← Upd(ski−1) for i = 2, . . . , t.
Moreover, if the scheme has a fast-forward update algo-

rithm, then the keys it produces must be distributed identically
to those produced by repetitive application of the regular up-
date algorithm. Meaning, for all t, t ′ ∈ [T ] with t < t ′ ≤ T
and for all skt it holds that sk′t ′ ←$ Upd′(skt , t ′) follows the
same distribution as skt produced as ski ←$ Upd(ski−1) for
i = t +1, . . . , t ′.

Security.

Unforgeability under chosen-message attack for forward-
secure signatures is defined through the following game. The
experiment generates a fresh key pair (pk,sk1) and hands the
public key pk to the adversary A. The adversary is given
access to the following oracles:

Key update. If the current time period t (initially set to t = 1)
is less than T , then this oracle updates the key skt to skt+1
and increases t.

Signing. On input a message M, this oracle runs the signing
oracle with the current secret key skt and message M, and
returns the resulting signature σ.

Break in. The experiment records the break-in time t̄ ← t
and hands the current signing key skt̄ to the adversary. This
oracle can only be queried once, and after it has been queried,
the adversary can make no further queries to the key update
or signing oracles.

At the end of the game, the adversary outputs its forgery
(t∗,M∗,σ∗). It wins the game if σ∗ verifies correctly under
pk for time period t∗ and message M∗, if it never queried the
signing oracle on M∗ during time period t∗, and if it queried
the break-in oracle, then it did so in a time period t̄ > t∗.
We define A’s advantage Advfu-cma

FS (A) as its probability in
winning the above game.

We also define a selective variant of the above notion, re-
ferred to as sfu-cma, where the adversary first has to commit
to t̄, t∗, and M∗. More specifically, A first outputs (t̄, t∗,M∗),
then receives the public key pk, is allowed to make signature
and key update queries until time period t = t̄ is reached, at
which point it is given skt̄ and outputs its forgery σ∗.

4.2 Encoding time periods

Following [22], we associate time periods with all nodes of
the tree according to a pre-order traversal. Prior tree-based
forward-secure signatures [9, 46] associate time periods with
the only leaf nodes; using all nodes allows us to reduce the
amortized complexity of key updates from O(logT ) exponen-
tiations to O(1) exponentiations.

Recall that a tree of depth `− 1 has 2`− 1 nodes, which
then correspond to time periods in [2`−1]. We will identify
the nodes of the tree of depth `−1 with strings in {1,2}≤`−1

where 1 denotes taking the left branch and 2 denotes taking
the right branch. We work with {1,2} instead of {0,1} for
technical reasons: roughly speaking, in the scheme, we need
to work with strings of length exactly `−1, which we obtain
by padding strings in {1,2}≤`−1 with zeroes.

We can also describe the association explicitly as a bijec-
tion between t = t1‖t2‖ . . . ∈ {1,2}≤`−1 and t ∈ [2`− 1] for



any integer ` given by

t(t) = 1+
|t|

∑
i=1

(1+2`−i(ti−1)) .

For instance, for ` = 3, this maps Îľ,1,11,12,2,21,22 to
1,2,3,4,5,6,7. The inverse of the bijection can be described
as

t(1) = Îľ

t(t) = t(t−1)‖1 if |t(t−1)|< `−1
t(t) = t̄‖2 if |t(t−1)|= `−1

where t̄ is the longest string such that t̄‖1 is a prefix of t(t−1).
The bijection induces a natural precedence relation over

{1,2}≤`−1 where t� t′ iff either t is a prefix of t′ or exists t̄
s.t. t̄‖1 is a prefix of t and t̄‖2 is a prefix of t′. We also write
t, t+1 corresponding to t, t +1.

Next, we associate any t ∈ {1,2}≤`−1 with a set Γt ⊂
{1,2}≤`−1 given by

Γt :=
{

t
}
∪
{

t̄‖2 : t̄‖1 prefix of t
}

that corresponds to the set containing t and all the right-hand
siblings of nodes on the path from t to the root, which also
happens to be the smallest set of nodes that includes a prefix
of all t′ � t. For instance, for `= 3, we have

Γ1 = {1,2},Γ11 = {11,12,2},Γ12 = {12,2} .

The sets Γt satisfy the following properties:

• t′ � t iff there exists u ∈ Γt s.t. u is a prefix of t′;
• For all t, we have Γt+1 = Γt \{t} if |t|= `−1 or Γt+1 =
(Γt \{t})∪{ t‖1, t‖2} otherwise;

• For all t′ � t, we have that for all u′ ∈ Γt′ , there exists
u ∈ Γt such that u is a prefix of u′.

The first property is used for verification and for reasoning
about security; the second and third properties are used for
key updates.

4.3 Construction
We assume the bound T is of the form 2` − 1. We use
the above bijection so that the algorithms take input t ∈
{1,2}≤`−1 instead of t ∈ [T ]. The following scheme is roughly
the result of applying the Canetti-Halevi-Katz technique to
obtain forward security from hierarchical identity-based en-
cryption (HIBE) [23] to the signature scheme determined by
the key structure of the Boneh-Boyen-Goh HIBE scheme [14];
we describe the differences at the end of this subsection.

Setup. LetM be the message space of the scheme and let
Hq :M→ {0,1}κ be a hash function that maps messages

to bit strings of length Îş such that 2Îş < q. Apart from the
description of the groups, the common system parameters
also contain the maximum number of time slots T = 2`−1
and random group elements h,h0, . . . ,h` ←$ G1. These pa-
rameters could, for example, be generated as the output of a
hash function modeled as a random oracle.

Key generation. Each signer chooses x←$ Zq and computes
y← gx

2. It sets its public to pk = y and computes its initial
secret key sk1←{s̃kε} where s̃kε =

(
gr

2 , hxhr
0 , hr

1, . . . ,h
r
`

)
for r←$ Zq.

Key update. We associate with each w ∈ {1,2}k with k ≤
`−1 a key s̃kw of the form

s̃kw = (c,d,ek+1, . . . ,e`)

=

(
gr

2 , hx(h0

k

∏
j=1

h
w j
j )r , hr

k+1 , . . . , hr
`

)
(1)

for r←$ Zq. Given s̃kw, one can derive a key for any w′ ∈
{1,2}k′ which contains w as a prefix as

(c′,d′,e′k′+1, . . . ,e
′
`) =

(
c ·gr′

2 , d ¡
k′

∏
j=k+1

e
w j
j ¡(h0

k′

∏
j=1

h
w j
j )r′ ,

ek′+1 ·hr′
k′+1 , . . . , e` ·hr′

`

)
(2)

for r′←$ Zq.

The secret key skt at time period t is given by

skt = {s̃kw : w ∈ Γt} ,

which, by the first property of Γt, contains a key s̃kw for a
prefix w of all nodes t′ � t.
To perform a regular update of skt to skt+1, the signer users
the second property of Γt. Namely, if |t| < `− 1, then the
signer looks up s̃kt = (c,d,e|t|+1, . . . ,e`) ∈ skt, computes

s̃kt‖1← (c,d · e|t|+1,e|t|+2, . . . ,e`) ,

and derives s̃kt‖2 from s̃kt using Equation (2). The signer
then sets skt+1 ← (skt \ s̃kt)∪ {s̃kt‖1, s̃kt‖2} and securely
deletes skt as well as the re-randomization exponent r′ used
in the derivation of s̃kt‖2.

If |t|= `−1, then the signer simply sets skt+1← skt \{s̃kt}
and securely deletes skt.

To perform a fast-forward update of its key to any time t′ � t,
the signer derives keys s̃kw′ for all nodes w′ ∈ Γt′ \Γt by
applying Equation (2) to the key s̃kw ∈ skt such that w is a
prefix of w′, which must exist due to the third property of
Γt. The signer then sets skt′←{s̃kw′ : w′ ∈ Γt′} and securely
deletes skt as well as all re-randomization exponents used in
the key derivations.



Signing. To generate a signature on message M ∈ M
in time period t ∈ {1,2}≤`−1, the signer looks up s̃kt =
(c,d,e|t|+1, . . . ,e`) ∈ skt , chooses r′←$ Zq, and outputs

(σ1,σ2) =

(
d ¡ eHq(M)

` ¡
(
h0 ¡

|t|

∏
j=1

h
t j
j ¡h

Hq(M)
`

)r′
, c ·gr′

2

)
.

Verification. Anyone can verify a signature (σ1,σ2) ∈G1×
G2 on message M under public key pk = y in time period t
by checking whether

e(σ1,g2) = e(h,y) ¡ e
(
h0 ¡

|t|

∏
j=1

h
t j
j ¡h

Hq(M)
` , σ2

)
.

Note that the pairing e(h,y) can be pre-computed from the
public key ahead of time, so that verification only requires
two pairing computations.

Differences from prior works. We highlight the differ-
ences between our scheme and those in [14,18,22], assuming
some familiarity with these prior constructions.

• We rely on asymmetric bilinear groups for efficiency, and
our signature sits in G2×G1 instead of G2

2. This way, it
is sufficient to give out the public parameters h0, . . . ,h` in
G1 (which we can then instantiate using hash-to-curve
without trusted set-up) instead of having to generate
“consistent” public parameters (hi,h′i)= (gxi

1 ,g
xi
2 )∈G1×

G2.

• Our key-generation algorithm also deviates from that in
the Boneh-Boyen-Goh HIBE, which would set

pk = e(g1,g2)
x,h = g1, s̃kξ =

(
gr

2,g
x
1hr

0,h
r
1, . . . ,h

r
`

)
.

In our scheme, pk = gx
2 lies in G2 instead of Gt and is

therefore smaller. Setting h to be random instead of g1
also allows us to achieve security under weaker assump-
tions. In fact, setting h = g1 and pk = gx

2 would yield
an insecure scheme in symmetric pairing groups where
g1 = g2, since hx = gx

1 = gx
2 = pk.

4.4 Correctness
We say that a secret key skt for time period t is well-formed
if skt = {s̃kw : w ∈ Γt}, where each s̃kw is of the form of
Equation (1) for an independent uniformly distributed expo-
nent r←$ Zq. We first show that all honestly generated and
updated secret keys are well-formed, and then proceed to the
verification of signatures.

The key skt is trivially well-formed for t = 1, i.e., t = Îľ, as
can be seen from the key generation algorithm. We now show
that skt is also well-formed after a regular update from time t
to t+1 and after a fast-forward update from t to t′ � t.

In a regular update, assume that skt is well-formed. If
|t|= `−1, then the update procedure sets skt+1← skt \{s̃kt},
which by the second property of Γt and the induction hy-
pothesis means that skt+1 is also well-formed. If |t|< `−1,
the update procedure adds keys s̃kt‖1 and s̃kt‖2 and re-
moves s̃kt from skt, which by the second property of Γt
indeed corresponds to {w : w ∈ Γt+1}. Moreover, s̃kt‖1 is
derived from s̃kt = s̃kt‖1 ← (c,d,e|t|+1, . . . ,e`) as s̃kt‖1 ←
(c,d ¡ e|t|+1,e|t|+2, . . . ,e`), which satisfies Equation (1) with
randomness r that is independent from all other keys in skt+1
because s̃kt 6∈ skt+1. Similarly, s̃kt‖2 satisfies Equation (1)
because it is generated as

c′ = c ·gr′
2 = gr+r′

2

d′ = d · ek+1 · (h0

k

∏
j=1

h
t j
j ¡h

wk+1
k+1 )r′

= hx(h0

k

∏
j=1

h
t j
j ¡h

2
k+1)

r+r′

e′k+2 = ek+2 ·hr′
k+2 = hr+r′

k+2

...

e′` = e` ·hr′
` = hr+r′

`

satisfying Equation (1) with randomness r+ r′, which is inde-
pendent of the randomness of other keys in skt+1 due to the
uniform choice of r′.

For the fast-forward update procedure, one can see that if
skt is well-formed, then the updated key skt′ for t′ � t is well-
formed as well. Indeed, by adding the keys for nodes in Γt′ \Γt
and removing those for Γt\Γt′ , we have that skt′ contains keys
s̃kw for all w ∈ Γt′ . The randomness independence is guar-
anteed by the random choice of r′ in Equation (2). In the
optimized variant, all keys still have independent randomness
because one key s̃kw′ ∈ skt′ will have the same randomness
r as some key s̃kw ∈ skt where w is a prefix of w′. That ran-
domness is independent from all other keys in skt′ , however,
because the key s̃kw does not occur in skt′ . Indeed, by the
definition of Γt′ , one can see that Γt′ cannot have elements
w 6= w′ with w a prefix of";"""date"",""2019-12-03T02:00:55Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""16"",""25"",""22"",""111"",""88"",""23"",""13"",""2"",""0"",""0"",""0"",""0"",""0"",""54"",""96"",""52""
""pdf:PDFVersion"",""1.5""
""xmp:CreatorTool"",""TeX""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dcterms:created"",""2019-12-03T02:00:55Z""
""language"",""en""
""Last-Modified"",""2019-12-03T02:00:55Z""
""dcterms:modified"",""2019-12-03T02:00:55Z""
""dc:format"",""application/pdf; version=1.5""
""Last-Save-Date"",""2019-12-03T02:00:55Z""
""pdf:docinfo:creator_tool"",""TeX""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2019-12-03T02:00:55Z""
""meta:save-date"",""2019-12-03T02:00:55Z""
""pdf:encrypted"",""false""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017) kpathsea version 6.2.3""
""modified"",""2019-12-03T02:00:55Z""
""Content-Length"",""272908""
""pdf:hasMarkedContent"",""false""
""Content-Type"",""application/pdf""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017) kpathsea version 6.2.3""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""trapped"",""False""
""meta:creation-date"",""2019-12-03T02:00:55Z""
""created"",""2019-12-03T02:00:55Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""18""
""Creation-Date"",""2019-12-03T02:00:55Z""
""resourceName"",""sec20summer_drijvers_prepub_0.pdf""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""3667"",""4942"",""3079"",""4002"",""3997"",""3149"",""3314"",""3556"",""3981"",""4473"",""3978"",""3494"",""3355"",""3904"",""3841"",""3152"",""2479"",""2944""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""producer"",""pdfTeX-1.40.18""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""pdfTeX-1.40.18""
""pdf:docinfo:created"",""2019-12-03T02:00:55Z""
";https://scholar.google.ch/scholar?start=930&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098795-173;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;[HTML][HTML] ??????????? ????????? HYPERLEDGER ? ?????? ???????? ?? ????-????? HYPERLEDGER FABRIC;?? ??????, ?? ?????? ; Vojnotehni?ki glasnik, 2020  cyberleninka.ru;;"… an emphasis on highly secure solutions, a token-based approach without a native cryptocurrency,

and the … Crypto Abstraction - Allows you to replace different crypto algorithms or modules … Identity

Services - Allows you to establish trust roots during Blockchain instance setup …";Autres articles;En cache;[HTML] cyberleninka.ru;https://cyberleninka.ru/article/n/programmnaya-platforma-hyperledger-s-osobym-aktsentom-na-blok-shemu-hyperledger-fabric;"
    

    


    
      
        



  [image: Научная статья на тему 'Программная платформа Hyperledger с особым акцентом на блок-схему Hyperledger Fabric'][image: ]



  Программная платформа Hyperledger с особым акцентом на блок-схему Hyperledger Fabric Текст научной статьи по специальности «Компьютерные и информационные науки»

  
    

    
    
      [image: ]CC BY

    
    
      [image: ]60
[image: ]2

    

  


  
    
    

  


	
  
    
      
        
          

        

        
          

        

        

      

    

  

  
  
    
       
         i
         Надоели баннеры? Вы всегда можете 
           отключить рекламу.
       

    

  


	

  
    
			
      Журнал[image: ]

      Vojnotehnički glasnik
      
	      2020

        
  

      

    

    
      Область наук

      	Компьютерные и информационные науки


    

  


  
  
    
      Ключевые слова

      
        
          BLOCKCHAIN / 
        
          HYPERLEDGER / 
        
          HYPERLEDGER FABRIC
        
      
    

  

  

  
  
    
      Аннотация научной статьи по компьютерным и информационным наукам, автор научной работы — Крстич Мария С., Крстич Лазар Й.

      Введение/цель: Развивающийся рынок блокчейнов с каждым днем становится все интереснее для многих отраслей, которые вследствие изменения условий ведения бизнеса, стали лучше понимать насколько важно иметь и пользоваться блокчейнами. После вступительного ознакомления с концепцией Blockchain в статье представлены проекты в рамках инициативы компании Linux Foundation, с особым акцентом на деятельность Hyperledger Fabric ее концепциях, архитектуре, организационной направленности, частных каналах и умных-контрактах, а также на потоке транзакций в сети Hyperledger Fabric. В последней практической части статьи представлены бизнес-симуляция и разработанное простое приложение для обмена денежных средств с помощью системы Hyperledger Fabric. Целью данной статьи является представление рабочих условий Hyperledger и выявление всех деталей Hyperledger Fabric, для того чтобы можно было понять насколько применение системы Hyperledger на практике является обоснованным. Методы: В работе применялись основные методы (анализ, синтез, дедукция, индукция, конкретизация, обобщение), а также общенаучные методы (аналитико-дедуктивный и сравнительный). Результаты: Были рассмотрены все релевантные характеристики Hyperledger Fabric, создана бизнес-сеть блокчейнов и разработано приложение для обмена денежных средств в сети. Выводы: Hyperledger Fabric - это самая масштабная и гибкая Hyperledger программная платформа с наибольшим количеством пользователей.

    

  

  

	
	
		
			
			        
					

				

			        
					

				

			

		

	

  
  
    
       
         i
         Надоели баннеры? Вы всегда можете 
           отключить рекламу.
       

    

  


	

	
    
      Похожие темы научных работ по компьютерным и информационным наукам , автор научной работы — Крстич Мария С., Крстич Лазар Й.

      	Профессиональный библиограф составит и оформит по ГОСТ список литературы для вашей работы
Подбор литературы
	
          
             evaluating a blockchain-based network performance for the intrusion detection system

            2020 / I. A. Burmaka, V. V. Lytvynov, I. S. Skiter, S. V. Lytvyn
          
        
	
          
            Применение технологии блокчейна для обеспечения защиты и контроля узлов беспроводной сенсорной сети

            2018 / Городничев Михаил Геннадьевич, Махров Станислав Станиславович, Денисова Елена Николаевна, Булдин Илья Дмитриевич
          
        
	
          
            Технология blockchain и возможности ее использования

            2020 / Захаров Вадим Владимирович, Рыбак Вадим Львович
          
        
	
          
            Возможности и вызовы для блокчейн в новой индустриализации

            2019 / Липницкий Денис Владимирович
          
        
	
          
            Digital registry of professional competences of the population drawing on distributed registries and smart contracts technologies

            2018 / Sergey P. Novikov, Olga V. Mikheenko, Natalia A. Kulagina, Oleg D. Kazakov
          
        


    

  


  
    
       iНе можете найти то, что вам нужно? Попробуйте сервис подбора литературы.

    

  


  
    

  


	
  
    
      
        
          

        

        
          

        

      

    

  

  
  
    
       
         i
         Надоели баннеры? Вы всегда можете 
           отключить рекламу.
       

    

  


	

  
  
    
      HYPERLEDGER FRAMEWORKS WITH A SPECIAL FOCUS ON HYPERLEDGER FABRIC

      Introduction/purpose: The Blockchain market is a developing market, and many industries are increasingly aware of the importance of having and implementing Blockchain due to changing business conditions. After an introductory consideration of the Blockchain concept, the article focuses on the projects under the Linux Hyperledger Initiative, with particular reference to Hyperledger Fabric, notably on the concepts, architecture, organizational focus, private channels and smart contracts, as well as flow of transactions in the Hyperledger Fabric network. In the last, practical part of the paper, we presented a simulation of a business network and created a simple application for money exchange using the Hyperledger Fabric framework. The aim of the paper is to present the Hyperledger frameworks and highlight all the details of Hyperledger Fabric in order to determine whether its application in practice is justified. Methods: Basic methods (analysis, synthesis, deduction, induction, concretization, generalization) as well as general-scientific methods (analytical-deductive and comparative) were used. Results: All relevant features of Hyperledger Fabric were considered, a blockchain business network based on it was built, and an application for cash exchange through the network was created. Conclusion: Hyperledger Fabric is the most comprehensive and the most flexible Hyperledger framework with the largest number of use cases.

    

  

  
  
    
      Текст научной работы на тему «Программная платформа Hyperledger с особым акцентом на блок-схему Hyperledger Fabric»

      
				
        
          

        

				
        
        ďťżHYPERLEDGER FRAMEWORKS WITH A SPECIAL FOCUS ON HYPERLEDGER FABRIC

         
        
        Marija S. Krstica, Lazar J. Krsticb

         
         
         
        
        Academy of Vocational Studies Southern Serbia, Department of Business Studies, Leskovac, Republic of Serbia

         
         
         
        
        a e-mail: krstic.marija@vpsle.edu.rs, corresponding author, ORCID iD: https://orcid.org/0000-0003-3009-8400

         
         
         
        
        b e-mail: krstic.lazar@vpsle.edu.rs, ORCID iD: https://orcid.org/0000-0001-9131-6876

         
         
         
        
        DOI: 10.5937/vojtehg68-26206; https://doi.org/10.5937/vojtehg68-26206

         
         
         
        
        FIELD: IT

         
         
         
        
        ARTICLE TYPE: Professional Paper Abstract:

         
         
         
        
        Introduction/purpose: The Blockchain market is a developing market, and many industries are increasingly aware of the importance of having and implementing Blockchain due to changing business conditions. After an introductory consideration of the Blockchain concept, the article focuses on the projects under the Linux Hyperledger Initiative, with particular reference to Hyperledger Fabric, notably on the concepts, architecture, organizational focus, private channels and smart contracts, as well as flow of transactions in the Hyperledger Fabric network. In the last, practical part of the paper, we presented a simulation of a business network and created a simple application for money exchange using the Hyperledger Fabric framework. The aim of the paper is to present the Hyperledger frameworks and highlight all the details of Hyperledger Fabric in order to determine whether its application in practice is justified.

         
         
         
        
        Methods: Basic methods (analysis, synthesis, deduction, induction,

         
         
         
        
        concretization, generalization) as well as general-scientific methods

         
         
         
        
        (analytical-deductive and comparative) were used.

         
         
         
        
        Results: All relevant features of Hyperledger Fabric were considered, a

         
         
         
        
        blockchain business network based on it was built, and an application

         
         
         
        
        for cash exchange through the network was created.

         
         
         
        
        Conclusion: Hyperledger Fabric is the most comprehensive and the

         
         
           iНе можете найти то, что вам нужно? Попробуйте сервис подбора литературы.

         
         
        
        most flexible Hyperledger framework with the largest number of use

         
         
         
        
        cases.

         
         
         
        
        Key words: Blockchain, Hyperledger, Hyperledger Fabric.

         
         
         
        
        3 6

         
         
         
        
        -6 93 .6

         
         
         
        
        p. p

         
         
         
        
        ic,

         
         
         
        
        br

         
         
         
        
        a F

         
         
         
        
        re g

         
         
         
        
        d le

         
         
         
        
        er p

         
         
         
        
        y

         
         
         
        
        x

         
         
         
        
        o </)

         
         
           iНе можете найти то, что вам нужно? Попробуйте сервис подбора литературы.

         
         
        
        o ÂŁ

         
         
         
        
        ia ci

         
         
         
        
        e p

         
         
         
        
        s a

         
         
         
        
        5

         
         
         
        
        o

         
         
         
        
        CD

         
         
         
        
        E

         
         
         
        
        CO

         
         
         
        
        e g

         
         
         
        
        d

         
         
         
        
        el

         
         
         
        
        er p

         
         
         
        
        y

         
         
         
        
        X

         
         
           iНе можете найти то, что вам нужно? Попробуйте сервис подбора литературы.

         
         
        
        CO

         
         
         
        
        t

         
         
         
        
        CD

         
         
         
        
        ti

         
         
         
        
        CO ÂŁ

         
         
         
        
        00 CD

         
         
         
        
        ""o

         
         
         
        
        >

         
         
         
        
        o~ CM o CM

         
         
         
        
        of

         
         
         
        
        UJ

         
         
         
        
        a.

         
         
         
        
        Z)

         
         
         
        
        o

         
         
         
        
        o <

         
         
           iНе можете найти то, что вам нужно? Попробуйте сервис подбора литературы.

         
         
        
        o

         
         
         
        
        X

         
         
         
        
        o

         
         
         
        
        LU

         
         
         
        
        H

         
         
         
        
        ^

         
         
         
        
        OH <

         
         
         
        
        H

         
         
         
        
        <

         
         
         
        
        CD >Q

         
         
         
        
        X LU H

         
         
         
        
        O

         
         
         
        
        O >

         
         
         
        
        &

         
         
         
        
        Introduction

         
         
           iНе можете найти то, что вам нужно? Попробуйте сервис подбора литературы.

         
         
        
        Blockchain technology is considered a suitable catalyst for transformation and has the potential to become a digital trend in the near future. This modern technology provides data duplication on all devices participating in the network. Blockchain is suitable for end users because the data cannot be changed after storage in a chain of blocks. Namely, each data update is correctly recorded, which facilitates the process of recording transactions and tracking assets in the business network.

         
         
         
        
        Using open source tools, we strive to create Blockchain techniques available to a wide range of people. One such tool is Hyperledger, a set of technologies used to create new blockchains. The application of Hyperledger Blockchain technologies in business processes improves transparency, enhances accountability and algorithmically guarantees trust between business partners. The technologies created within the Hyperledger projects are increasingly called Third Generation Blockchain systems, where the first generation is considered to be Bitcoin, and the second Ethereum.

         
         
         
        
        The paper presents research on the topic of Hyperledger projects with special reference to Hyperledger Fabric. The first part is an introduction to the basic concepts and principles of Blockchain technology, which enables a decentralized way of data storage. After giving the basics of the Blockchain technology, the research continues in the direction of the Hyperledger initiative of the Linux Foundation in the second part of the paper. The third part is dedicated to Hyperledger Fabric, i.e. concepts, architecture, organizational focus, private channels, smart contracts and transactions in the Hyperledger Fabric network. In the last, practical part of the paper, a simulation of a business network is given and a simple application for money exchange is created, with the aim of a simpler understanding of the Hyperledger Fabric working principle.

         
         
         
        
        Blockchain technology

         
         
         
        
        Blockchain technology is a distributed replicated database. It is organized in the form of a single-linked list (chain), where nodes are blocks with data on transactions, protected by cryptographic methods after grouping. Hence the name Blockchain. It is a system that enables the realization of digital transactions without intermediaries. It is based on the P2P architecture, where the nodes that participate in the implementation of the service have a copy of all records, and constantly communicate with each other and synchronize records (Minovic, 2017).

         
         
         
        
        To support consistent updating of information and to enable a full range of functions in the general ledger (transactions, queries, etc.), the Blockchain network uses smart contracts to provide controlled access to the ledger. Smart contracts are not only a key mechanism for encapsulating information and maintaining online simplicity, but can also be drawn up to allow participants to automatically execute certain aspects of transactions. The process by which general ledger transactions are synchronized online, to ensure that the general ledger is updated only when the transactions are approved by the respective participants and that the transactions remain in the same order when updating the general ledger, is called consensus.

         
         
         
        
        The consensus mechanism can be said to represent a predefined cryptographic validation method that ensures the correct sequencing of transactions on Blockchain. The consensus algorithm defines the rules, i.e. the ways in which network participants can reach an agreement on transaction validation. The most commonly used algorithms are Proof of Work (PoW) and Proof of Stake (PoS).

         
         
         
        
        Proof of Work is the most widespread way of reaching consensus, which is based on mining. To validate a transaction, each node must perform a complex mathematical calculation. That is why the device consumes certain resources: electricity and processing power. On the other hand, for successful validation, a node (miner) is rewarded with a certain monetary value in cryptocurrency. The more processing power it has, the faster the node will complete the mathematical calculation and get the reward, that is, will earn more. Proof of Stake does not involve mining, some nodes validate transactions and others confirm them, and everyone keeps part of their money in a virtual safe and whoever tries to cheat the system loses money (Pavlovic, 2018).

         
         
         
        
        Blockchain can be classified into three types: public, private and allowed Blockchain. The classification is based on the node's ability to access or add a new block to the network. Public blockchain networks are widely available, any node can join the network, participate in transactions and create blocks. The examples of public blockchain are Bitcoin, Ethereum, Dash and Litecoin. On the other hand, with private Blockchain networks, only invited members are allowed to join the network and there is no anonymity of participants, as with public networks. The identity of each participant is known and cryptographically authenticated, on the basis of which the execution of transactions is monitored. Access rights to executed transactions may be granted to anyone or restricted in some way. The examples of private Blockchain

         
         
         
        
        3 6

         
         
         
        
        -6 93 .6

         
         
         
        
        p. p

         
         
         
        
        ic,

         
         
         
        
        br

         
         
         
        
        a F

         
         
           iНе можете найти то, что вам нужно? Попробуйте сервис подбора литературы.

         
         
        
        re g

         
         
         
        
        d le

         
         
         
        
        er p

         
         
         
        
        y

         
         
         
        
        X

         
         
         
        
        o </) o

         
         
         
        
        ia ci

         
         
         
        
        e p

         
         
         
        
        s a

         
         
         
        
        5

         
         
         
        
        o

         
         
         
        
        CD

         
         
         
        
        E

         
         
         
        
        CO

         
         
         
        
        e g

         
         
           iНе можете найти то, что вам нужно? Попробуйте сервис подбора литературы.

         
         
        
        d

         
         
         
        
        el

         
         
         
        
        er p

         
         
         
        
        y

         
         
         
        
        X

         
         
         
        
        CO

         
         
         
        
        t

         
         
         
        
        C1J

         
         
         
        
        ti

         
         
         
        
        tr> ÂŁ

         
         
         
        
        00 CD

         
         
         
        
        ""o

         
         
         
        
        >

         
         
         
        
        o~ CM o CM

         
         
         
        
        of

         
         
           iНе можете найти то, что вам нужно? Попробуйте сервис подбора литературы.

         
         
        
        UJ

         
         
         
        
        a.

         
         
         
        
        Z)

         
         
         
        
        o

         
         
         
        
        o <

         
         
         
        
        o

         
         
         
        
        X

         
         
         
        
        o

         
         
         
        
        UJ

         
         
         
        
        H

         
         
         
        
        ^

         
         
         
        
        OH <

         
         
         
        
        H

         
         
         
        
        <

         
         
         
        
        CD >Q

         
         
           iНе можете найти то, что вам нужно? Попробуйте сервис подбора литературы.

         
         
        
        X UJ H

         
         
         
        
        O

         
         
         
        
        O >

         
         
         
        
        &

         
         
         
        
        are Hydrachain Ripple, Monaco and Multichain. The third type of Blockchain, which is the middle ground between private and public Blockchain, is known as a consortium or allowed Blockchain. In this type of blockchain, the network is controlled by a group of nodes. The examples of the consortium Blockchain network are Hyperledger Fabric and Corda (Nasir et al, 2018).

         
         
         
        
        Blockchain can also be said to be a collaborative data registry. Each time the data is accessed and modified, the change is recorded and confirmed, followed by encryption that cannot be subsequently edited. All changes are saved and added to the total record, and each subsequent change requires a repetition of the entire process, with the data being stored in a new block that is encrypted and attached to the previous block. Blockchain requires a lot of processing power due to the complex cryptography that computers have to solve in order to enable storage and access to data. Six basic qualities of Blockchain can be singled out, which together form a functional system (Piljan et al, 2018):

         
         
         
        
        -	Decentralization: Blockchain is a distributed database located on all users' computers around the planet, i.e. on the Internet. Thus, there is no central database that can be attacked, hacked or forged. Also, there is no need for an intermediary - information, money, securities or something else can be sent without the need for a broker or a third party (PayPal, Western Union).

         
         
         
        
        -	Encryption: Blockchain is encrypted, it uses an advanced encryption technique using private and public keys providing virtually complete security in the authenticity of the transmitted data.

         
         
         
        
        -	Transparency: Blockchain is public. All users have access to the database and no one can hide an individual transaction.

         
         
         
        
        -	Inclusiveness: Blockchain does not require special technical preconditions for participation, the protocol is designed in such a way that it can be implemented on practically any computer or mobile device, thus providing the possibility of use to practically the entire Internet population.

         
         
         
        
        -	Immutability: after a transaction has been executed, verified and placed in a block, it is linked to the previous transaction or block. This structure is marked with a unique code and timestamp, which prevents the possibility of subsequent changes.

         
         
         
        
        -	Historicity: there is no way to steal a transaction or data about a block, because that would mean rewriting the entire Blockchain, or all transactions ever performed in it. This means that Blockchain at all times contains all transactions that have been executed since the chain was created.

         
         
         
        
        Hyperledger

         
         
         
        
        Hyperledger is an open source project founded by the Linux Foundation. The initiative was launched in December 2015 in order to advance and promote Blockchain technologies and expand the possibilities of their application in the business world. Members of the Hyperledger initiative are many of the world's leading companies in the fields of information and high technologies, finance and banking, production and distribution of products (supply chain), such as: Intel, IBM, Cisco, Airbus, Daimler, JP Morgan, American Express, Deloitte, PWC, BNP Paribas, Baidu, SAP, Huawei, as well as many others, including the domestic company GameCredits (Gajic, 2018).

         
         
         
        
        Hyperledger is not a unique Blockchain technology, but a collection of technologies included by member companies. Although there is a long-term goal of greater integration between projects, most Hyperledger projects still operate independently. Hyperledger has never issued its cryptocurrency, and according to its founders, it will continue to do so in the future. Concrete technologies can be said to be explicitly designed and built for enterprise use cases, not for public markets.

         
         
           iНе можете найти то, что вам нужно? Попробуйте сервис подбора литературы.

         
         
        
        The active development of Hyperledger projects took place at the beginning of 2016, and it implies the development of a larger number of frameworks and tools. Hyperledger frameworks, i.e. distributed ledger technology (DLT) technologies include Fabric, Sawtooth, Iroha, Indy and Burrow, while tools are being developed from Composer, Cello and Explorer (Dhillon et al, 2017).

         
         
         
        
        Each of the Hyperledger technologies has its own specific advantages in certain applications. Some of the mentioned technologies have advanced in the development phases and are actively applied (Fabric, Sawtooth, Iroha), while others are still in the incubation phase (Burrow, Indy). As far as tools are concerned, the most developed is Composer.

         
         
         
        
        Hyperledger projects follow a design philosophy that includes a modular extensible approach, interoperability, an emphasis on highly secure solutions, a token-based approach without a native cryptocurrency, and the development of a rich and simple application user interface. The modular approach allows developers to experiment with creating different types of components. They can create components that can be combined, in order to develop distributed general ledger solutions that meet different requirements. Hyperledger recognizes that security is a fundamental aspect of distributed general ledgers, as many

         
         
         
        
        3 6

         
         
         
        
        -6 93 .6

         
         
         
        
        p. p

         
         
         
        
        ic,

         
         
         
        
        br

         
         
         
        
        a F

         
         
         
        
        re g

         
         
         
        
        d le

         
         
         
        
        er p

         
         
         
        
        y

         
         
         
        
        X

         
         
         
        
        o </)

         
         
           iНе можете найти то, что вам нужно? Попробуйте сервис подбора литературы.

         
         
        
        o ÂŁ

         
         
         
        
        ia ci

         
         
         
        
        e p

         
         
         
        
        s a

         
         
         
        
        5

         
         
         
        
        o

         
         
         
        
        CD

         
         
         
        
        E

         
         
         
        
        CO

         
         
         
        
        e g

         
         
         
        
        d

         
         
         
        
        el

         
         
         
        
        er p

         
         
         
        
        y

         
         
         
        
        X

         
         
           iНе можете найти то, что вам нужно? Попробуйте сервис подбора литературы.

         
         
        
        CO

         
         
         
        
        t

         
         
         
        
        C1J

         
         
         
        
        ti

         
         
         
        
        tr> ÂŁ

         
         
         
        
        00 CD

         
         
         
        
        ""o

         
         
         
        
        >

         
         
         
        
        o~ CM o CM

         
         
         
        
        of

         
         
         
        
        UJ

         
         
         
        
        a.

         
         
         
        
        Z)

         
         
         
        
        o

         
         
         
        
        o <

         
         
           iНе можете найти то, что ваП нуМнО? Попробуйте сервис подбора литĐ";"""citation_keywords"",""BLOCKCHAIN, HYPERLEDGER, HYPERLEDGER FABRIC""
""og:image"",""https://cyberleninka.ru/article/n/programmnaya-platforma-hyperledger-s-osobym-aktsentom-na-blok-shemu-hyperledger-fabric/og""
""og:image:width"",""1074""
""twitter:card"",""summary_large_image""
""eprints.ispublished"",""pub""
""og:site_name"",""КиберЛенинка""
""keywords"",""научная статья бесплатно на тему Программная платформа Hyperledger с особым акцентом на блок-схему Hyperledger Fabric текст научной работы по компьютерным и информационным наукам из научного журнала Vojnotehnički glasnik. BLOCKCHAIN, HYPERLEDGER, HYPERLEDGER FABRIC""
""eprints.pagerange"",""639-663""
""citation_journal_title"",""Vojnotehnički glasnik""
""eprints.publication"",""Vojnotehnički glasnik""
""language"",""en""
""og:description"",""Введение/цель: Развивающийся рынок блокчейнов с каждым днем становится все интереснее для многих отраслей, которые вследствие изменения условий ведения бизнеса, стали лучше понимать насколько важно иметь и пользоваться блокчейнами. После вступительного ознакомления с концепцией Blockchain в статье представлены проекты в рамках инициативы компании Linux Foundation, с особым акцентом на деятельность Hyperledger Fabric ее концепциях, архитектуре, организационной направленности, частных каналах и умных-контрактах, а также на потоке транзакций в сети Hyperledger Fabric. В последней практической части статьи представлены бизнес-симуляция и разработанное простое приложение для обмена денежных средств с помощью системы Hyperledger Fabric. Целью данной статьи является представление рабочих условий Hyperledger и выявление всех деталей Hyperledger Fabric, для того чтобы можно было понять насколько применение системы Hyperledger на практике является обоснованным. Методы: В работе применялись основные методы (анализ, синтез, дедукция, индукция, конкретизация, обобщение), а также общенаучные методы (аналитико-дедуктивный и сравнительный). Результаты: Были рассмотрены все релевантные характеристики Hyperledger Fabric, создана бизнес-сеть блокчейнов и разработано приложение для обмена денежных средств в сети. Выводы: Hyperledger Fabric - это самая масштабная и гибкая Hyperledger программная платформа с наибольшим количеством пользователей.""
""eprints.full_text_status"",""public""
""citation_issn"",""0042-8469""
""dc:title"",""Программная платформа Hyperledger с особым акцентом на блок-схему Hyperledger Fabric – тема научной статьи по компьютерным и информационным наукам читайте бесплатно текст научно-исследовательской работы в электронной библиотеке КиберЛенинка""
""eprints.place_of_pub"",""Сербия, Белград""
""Content-Encoding"",""UTF-8""
""citation_pdf_url"",""https://cyberleninka.ru/article/n/programmnaya-platforma-hyperledger-s-osobym-aktsentom-na-blok-shemu-hyperledger-fabric/pdf""
""robots"",""NOODP"",""noyaca""
""eprints.volume"",""68""
""eprints.citation"",""Крстич Мария С., Крстич Лазар Й. Программная платформа Hyperledger с особым акцентом на блок-схему Hyperledger Fabric // Vojnotehnički glasnik. 2020. Выпуск номер 3 том 68, С.639-663""
""eprints.number"",""3""
""citation_author"",""Крстич Мария С."",""Крстич Лазар Й.""
""resourceName"",""programmnaya-platforma-hyperledger-s-osobym-aktsentom-na-blok-shemu-hyperledger-fabric""
""citation_abstract_html_url"",""https://cyberleninka.ru/article/n/programmnaya-platforma-hyperledger-s-osobym-aktsentom-na-blok-shemu-hyperledger-fabric""
""citation_issue"",""3""
""eprints.abstract"",""Introduction/purpose: The Blockchain market is a developing market, and many industries are increasingly aware of the importance of having and implementing Blockchain due to changing business conditions. After an introductory consideration of the Blockchain concept, the article focuses on the projects under the Linux Hyperledger Initiative, with particular reference to Hyperledger Fabric, notably on the concepts, architecture, organizational focus, private channels and smart contracts, as well as flow of transactions in the Hyperledger Fabric network. In the last, practical part of the paper, we presented a simulation of a business network and created a simple application for money exchange using the Hyperledger Fabric framework. The aim of the paper is to present the Hyperledger frameworks and highlight all the details of Hyperledger Fabric in order to determine whether its application in practice is justified. Methods: Basic methods (analysis, synthesis, deduction, induction, concretization, generalization) as well as general-scientific methods (analytical-deductive and comparative) were used. Results: All relevant features of Hyperledger Fabric were considered, a blockchain business network based on it was built, and an application for cash exchange through the network was created. Conclusion: Hyperledger Fabric is the most comprehensive and the most flexible Hyperledger framework with the largest number of use cases."",""Введение/цель: Развивающийся рынок блокчейнов с каждым днем становится все интереснее для многих отраслей, которые вследствие изменения условий ведения бизнеса, стали лучше понимать насколько важно иметь и пользоваться блокчейнами. После вступительного ознакомления с концепцией Blockchain в статье представлены проекты в рамках инициативы компании Linux Foundation, с особым акцентом на деятельность Hyperledger Fabric ее концепциях, архитектуре, организационной направленности, частных каналах и умных-контрактах, а также на потоке транзакций в сети Hyperledger Fabric. В последней практической части статьи представлены бизнес-симуляция и разработанное простое приложение для обмена денежных средств с помощью системы Hyperledger Fabric. Целью данной статьи является представление рабочих условий Hyperledger и выявление всех деталей Hyperledger Fabric, для того чтобы можно было понять насколько применение системы Hyperledger на практике является обоснованным. Методы: В работе применялись основные методы (анализ, синтез, дедукция, индукция, конкретизация, обобщение), а также общенаучные методы (аналитико-дедуктивный и сравнительный). Результаты: Были рассмотрены все релевантные характеристики Hyperledger Fabric, создана бизнес-сеть блокчейнов и разработано приложение для обмена денежных средств в сети. Выводы: Hyperledger Fabric - это самая масштабная и гибкая Hyperledger программная платформа с наибольшим количеством пользователей.""
""eprints.eissn"",""2217-4753""
""citation_volume"",""68""
""format-detection"",""telephone=no""
""citation_publication_date"",""2020""
""citation_title"",""Программная платформа Hyperledger с особым акцентом на блок-схему Hyperledger Fabric""
""eprints.date"",""2020""
""citation_publisher"",""Гачеша Небойша Николаевич""
""eprints.type"",""article""
""description"",""Введение/цель: Развивающийся рынок блокчейнов с каждым днем становится все интереснее для многих отраслей, которые вследствие изменения условий ведения бизнеса, стали лучше понимать насколько важно иметь и пользоваться блокчейнами. После вступительного ознакомления с концепцией Blockchain в статье представлены проекты в рамках инициативы компании Linux Foundation, с особым акцентом на деятельность Hyperledger Fabric ее концепциях, архитектуре, организационной направленности, частных каналах и умных-контрактах, а также на потоке транзакций в сети Hyperledger Fabric. В последней практической части статьи представлены бизнес-симуляция и разработанное простое приложение для обмена денежных средств с помощью системы Hyperledger Fabric. Целью данной статьи является представление рабочих условий Hyperledger и выявление всех деталей Hyperledger Fabric, для того чтобы можно было понять насколько применение системы Hyperledger на практике является обоснованным. Методы: В работе применялись основные методы (анализ, синтез, дедукция, индукция, конкретизация, обобщение), а также общенаучные методы (аналитико-дедуктивный и сравнительный). Результаты: Были рассмотрены все релевантные характеристики Hyperledger Fabric, создана бизнес-сеть блокчейнов и разработано приложение для обмена денежных средств в сети. Выводы: Hyperledger Fabric - это самая масштабная и гибкая Hyperledger программная платформа с наибольшим количеством пользователей.""
""title"",""Программная платформа Hyperledger с особым акцентом на блок-схему Hyperledger Fabric – тема научной статьи по компьютерным и информационным наукам читайте бесплатно текст научно-исследовательской работы в электронной библиотеке КиберЛенинка""
""eprints.document_url"",""https://cyberleninka.ru/article/n/programmnaya-platforma-hyperledger-s-osobym-aktsentom-na-blok-shemu-hyperledger-fabric""
""twitter:site"",""@CyberLeninka""
""citation_fulltext_html_url"",""https://cyberleninka.ru/article/n/programmnaya-platforma-hyperledger-s-osobym-aktsentom-na-blok-shemu-hyperledger-fabric""
""eprints.keywords"",""BLOCKCHAIN, HYPERLEDGER, HYPERLEDGER FABRIC""
""Content-Type-Hint"",""text/html; charset=utf-8""
""eprints.publisher"",""Гачеша Небойша Николаевич""
""Content-Type"",""text/html; charset=UTF-8""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""og:type"",""article""
""eprints.title"",""Программная платформа Hyperledger с особым акцентом на блок-схему Hyperledger Fabric""
""og:title"",""Программная платформа Hyperledger с особым акцентом на блок-схему Hyperledger Fabric""
""og:image:height"",""480""
""eprints.creators_name"",""Крстич Мария С."",""Крстич Лазар Й.""
""eprints.date_type"",""published""
""viewport"",""width=device-width, initial-scale=1""
""apple-mobile-web-app-capable"",""yes""
""og:url"",""https://cyberleninka.ru/article/n/programmnaya-platforma-hyperledger-s-osobym-aktsentom-na-blok-shemu-hyperledger-fabric""
""citation_eissn"",""2217-4753""
""eprints.metadata_visibility"",""show""
""eprints.refereed"",""TRUE""
""eprints.issn"",""0042-8469""
";https://scholar.google.ch/scholar?start=720&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098787-158;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Measure-rewind-measure: tighter quantum random oracle model proofs for one-way to hiding and CCA security;V Kuchta, A Sakzad, D Stehlé, R Steinfeld… ; … Conference on the …, 2020  Springer;;"… Adv}({\mathcal {A}}^{O}_\text {O2H}) \le 2 \cdot \sqrt{\mathsf {Adv}({\mathcal {B}}_\text

{OW}^{G,H})}\) Here \(\mathcal {B}_\text {OW}^{G,H}(z)\) is a quantum attacker against the

one-wayness of \(\mathsf {enc}\), which is given oracle access for both G and H (these oracles …";Cité 13 fois;Les 7 versions;[PDF] iacr.org;https://eprint.iacr.org/2021/454.pdf;"
Measure-Rewind-Measure: Tighter Quantum
Random Oracle Model Proofs for One-Way to

Hiding and CCA Security?

Veronika Kuchta1, Amin Sakzad1, Damien StehlĂŠ2,3, Ron Steinfeld1,
and Shi-Feng Sun1,4

1 Faculty of Information Technology, Monash University, Australia
2 Univ. Lyon, EnsL, UCBL, CNRS, Inria, LIP, F-69342 Lyon Cedex 07, France.

3 Institut Universitaire de France.
4 Data61, CSIRO, Australia

Abstract. We introduce a new technique called ‘Measure-Rewind-
Measure’ (MRM) to achieve tighter security proofs in the quantum ran-
dom oracle model (QROM). We first apply our MRM technique to derive
a new security proof for a variant of the ‘double-sided’ quantum One-
Way to Hiding Lemma (O2H) of Bindel et al. [TCC 2019] which, for the
first time, avoids the square-root advantage loss in the security proof. In
particular, it bypasses a previous ‘impossibility result’ of Jiang, Zhang
and Ma [IACR eprint 2019]. We then apply our new O2H Lemma to
give a new tighter security proof for the Fujisaki-Okamoto transform for
constructing a strong (IND-CCA) Key Encapsulation Mechanism (KEM)
from a weak (IND-CPA) public-key encryption scheme satisfying a mild
injectivity assumption.
Keywords. QROM, security proof, public-key encryption.

1 Introduction

Background. Correctly selecting secure parameters for quantum-
resistant cryptosystems requires understanding both the concrete quan-
tum cost of attacks against the underlying intractability assumption (e.g.,
LWE [19]), as well as the concrete quantum cost of attacks against the
cryptosystem itself. Ideally, one would like a cryptosystem whose secu-
rity is tightly related via a security proof (or security reduction) to the
intractability of a well-studied problem, so that attacks against the cryp-
tosystem of lower cost than those against the problem are ruled out.
Such tight proofs give confidence in the concrete security of practical
parameter choices based on the best known attacks against the under-
lying problem. Unfortunately, due to existing gaps in the understanding

? This is the full version of the EUROCRYPT 2020 conference paper.



of security proofs in the context of quantum adversaries, there are many
practical post-quantum cryptosystem candidates that lack such tight se-
curity proofs.

A case in point is the Fujisaki-Okamoto (FO) CCA transform [9],
which is commonly applied in the design of practical public-key cryptosys-
tems to strengthen their security from chosen-plaintext security (IND-CPA)
to chosen-ciphertext security (IND-CCA), assuming the random oracle
model (ROM) for the underlying cryptographic hash functions. This trans-
form and its variants [8, 21, 10, 20] are used in all public-key encryption
schemes and key-establishment algorithms of the second round of the
NIST PQC standardisation process [18]. Tight security proofs are known
for FO variants against classical adversaries (in the classical ROM), mean-
ing that an adversary breaking the FO-transformed scheme in time T and
advantage ε can be used to break the underlying scheme in time ≈ T and
advantage ≈ ε. Oppositely, no such tight security proof for an all-purpose
FO transform is known against quantum attacks in the quantum random
oracle model [6]. In the QROM, the adversary is given quantum access
to those hash functions modeled by random oracles. Note that [20, 25]
described a transform from a deterministic encryption scheme that enjoys
a so-called disjoint simulatability property, to an IND-CCA public-key en-
cryption scheme, which is tight in the QROM. The assumptions for this
tight QROM transform are more stringent than those of the all-purpose
FO transform: only 2.5 out of 17 second round NIST proposals for public-
key encryption schemes claim that it is applicable to them [3, 7, 4],1 and
at the cost of additional assumptions.

Although a series of works [21, 10, 11, 12, 15, 13, 5] have provided im-
proved analyses of the FO transform, the existing QROM reductions are
still not tight. The state-of-the-art reductions essentially preserve the run-
time, but the advantage degradation only satisfies Adv(ACCA) ≤ O(qc ·
(Adv(BCPA))δ), where (c, δ) = (1/2, 1/2) (versus the ideal tight result
(c, δ) = (0, 1) that one could hope for), where Adv(ACCA) and Adv(BCPA)
respectively denote the distinguishing advantages of the IND-CCA attack
against the FO-transformed scheme and IND-CPA attack against the orig-
inal scheme, and q denotes the number of QROM queries made by the
attacker A. We note that previous techniques have mainly improved the
value of c, reducing it gradually from c = 3/2 down to c = 1/2. Re-
garding δ, while it has been improved from 1/4 to 1/2, going further

1 In the case of [4], this holds for Streamlined NTRU Prime, but not for NTRU
LPRime.

2



towards δ = 1 has seemed challenging. Recently, it has even been conjec-
tured infeasible, based on an ‘impossibility result’ [14].

At the heart of these prior results has been the use of the ‘One-
way to Hiding’ (O2H) lemma, first given in [23]. All its versions so far
inherently lead to a ‘square-root advantage’ loss in the proofs of the
FO transforms. The O2H lemma can be formulated informally as fol-
lows. A quantum distinguisher AO2H is given quantum access to an or-
acle O that implements either a random oracle H : X → Y or a mod-
ified random oracle G : X → Y , where H and G are identical on all
except a single secret point x ∈ X: we have H(x′) = G(x′) for all
x′ 6= x and H(x) = yH and G(x) = yG where yH , yG are indepen-
dent uniformly chosen random strings. The distinguisher is also given
z = (zx = enc(x), zH = yH , zG = yG), where enc is a one-way function (a
deterministic encryption scheme in the FO scenario).2 The goal of AO2H
is to distinguish whether the oracle O implements G or H, while making
up to q queries to O with depth at most d (where a depth of d means
that AO2H splits its queries into d bunches and all queries within each
bunch are queried in parallel, so queries in each bunch may depend on
the answer to d − 1 previous query bunches, and the total number of
queries over all d bunches is at most q). An algorithm that computes x
from zx (by breaking the one-wayness of enc), queries O(x) and compares
the result to zH achieves an advantage Adv(AOO2H) negligibly close to 1.
In the case of a classical access to O, no algorithm can do better. In the
quantum access case, all variants of the O2H lemma known so far suffer
from a square-root advantage loss. For example, the recent [5, Lemma 5]
states that Adv(AOO2H) ≤ 2 ·

√
Adv(BG,HOW ). Here BG,HOW (z) is a quantum

attacker against the one-wayness of enc, which is given oracle access for
both G and H (these oracles can be simulated given zx, and thus such
an attacker implies an attacker against the one-wayness of enc). The one-
wayness attacker BG,HOW constructed in the proof of this O2H lemma (and
all prior variants thereof) ‘only’ runs AO2H and measures its queries. In
particular, it does not ‘rewind’ AO2H to an earlier state. Rewinding the
state of an attacker to an earlier state is often considered tricky in the
quantum setting, due to the fact that measurement operations are not
reversible. The ‘impossibility result’ of [14] states that any O2H lemma
based on a one-wayness attacker that runs the distinguisher only once and

2 We use this definition of z for simplicity in this introduction. The actual formulation
of most prior O2H lemmas, as well as our new one, is more general and allows z to
have an arbitrary joint distribution with G,H, x, as well as allowing a set S of any
number of x’s on which G and H may differ, rather than just one.

3



Table 1. Comparison of security bounds and features of our new O2H lemma with
earlier variants of the O2H lemma. The ‘Bound’ column shows the dependence of the
upper bound on the distinguisher advantage Adv(A) in terms of the One-Wayness
attacker advantage ε and A’s oracle query depth d ≤ q (where q is the total number of
queries). The ‘|S|’ column indicates the number of points on which G and H may differ,
the ‘BOW must know’ column shows the oracles available to the one-wayness attacker,
and the ‘Event’ column indicates the type of event used to define A’s advantage. Here
H \ S (resp. G \ S) refers to the restriction of H (resp. G) to the complementary set
of S, and 1S refers to the indicator function of S.

O2H variant Bound |S| BOW must know Event

Original [23, 1] 2dÎľ1/2 Arbitrary H or G Arbitrary

Semi-classical [1] 2d1/2Îľ1/2 Arbitrary (H \ S or G \ S) Arbitrary
and 1S

Double-sided [5] 2Îľ1/2 One H and G Arbitrary

This work 4dÎľ Arbitrary H and G Efficiently checkable

involves no rewinding, must incur a square-root advantage loss. Thus, it
has been suggested in [5, 14] that the square-root advantage loss in the
O2H lemma may be unavoidable in the quantum setting.

Contributions. We present a novel quantum O2H lemma that, for the
first time, does not suffer from the square-root advantage loss in the
reduction. Concretely, we obtain a security bound of the form Adv(A) ≤ 4·
d ¡Adv(BG,H), where B is the one-wayness attacker against the underlying
one-way function enc.

To circumvent the ‘impossibility result’ of [14], we introduce a Measure-
Rewind-Measure (MRM) proof technique, which provides a new way to
extract the one-wayness secret x from the distinguisher. Rather than ex-
tracting x directly by measuring the oracle queries of the distinguisher
(as in prior works), the MRM technique may also extract x from the
distinguishing measurement of the distinguisher. The latter distinguish-
ing measurement knowledge extraction is achieved by letting the distin-
guisher perform its distinguishing measurement, and then rewinding the
collapsed measured state back to the state of the oracle query stage, to
perform a second measurement and extract x. A comparison of our O2H
lemma security bounds and features with earlier O2H lemma variants is
provided in Table 1.

Compared to prior O2H lemmas, our variant is the first to avoid
the square-root advantage loss. On the other hand, it constructs a one-
wayness attacker which in general requires oracle accesses to both G

4



and H. Therefore, our lemma is in the same setting as the ‘double-sided’
O2H lemma of [5], which makes it less general than the semi-classical or
original O2H lemmas. Nevertheless, it still suffices for important applica-
tions (see below). Compared to the ‘double-sided’ O2H lemma in [5], our
variant is slightly less general in one respect and more general in another.
On the one hand, the classical event distinguished by the O2H attacker A
in [5] can be arbitrary, while we assume this event to be efficiently check-
able by A. ‘Efficiently checkable’ means that the distinguishing advantage
in the definition of the O2H Lemma is defined as the advantage of A in
the usual way, i.e., Adv(A) = |Pr[1 ← AG(z)]− Pr[1 ← AH(z)]|. This is
in contrast to the more general definition used in [5], which uses the ad-
vantage |Pr[Ev : AG(z)]− Pr[Ev : AH(z)]| for any classical event Ev over
the view of A. There may not exist a computationally efficient algorithm
to check whether Ev has occurred. On the other hand, our O2H variant
allows |S| (the number of points on which G and H may differ) to be
arbitrary, while in [5] it must contain a single point.

As an important application of our O2H lemma, we present the first
security proof for the FO transform in the QROM which does not suffer
from a ‘square-root’ advantage loss for non-deterministic schemes, i.e., it
has the form Adv(ACCA) ≤ O(qc · Adv(BCPA)δ), where δ = 1 rather than
δ = 1/2 as in previous results (on the other hand, our proof currently gives
a larger value of c compared to earlier works, see below). A comparison
of our FO security proof bounds with earlier ones starting from IND-CPA
non-deterministic weak schemes is provided in Table 2. The ‘Security loss’
column of that table shows the number of extra bits of security required
for the ‘weak scheme’ in order to guarantee (via the security proof bound)
a desired bit security of Îť for the FO-transformed scheme. To obtain the
‘security loss’ L, we define the indistinguishability bit security of a scheme
(against distinguishers that never output ⊥, which is the class of attacks
considered here) [16] as Îť if the time to squared (conditional) advantage
ratio T/ε2 of any attack with time T ≤ 2λ is ≥ 2λ.3 We then choose the
smallest bit security Sweak of the ‘weak scheme’ so that the CCA security
bound for the CCA scheme implies a CCA bit security of the FO scheme
to be ≥ λ, and define the ‘security loss’ as L := Sweak − λ. We remark
that our bit security loss estimates in Table 2 assume that the classical
bit security definitions in [16] are appropriate in the quantum setting, as
we are not aware of any research on bit security notions in the quantum
setting. Note also that this latter assumption does not impact the security

3 We note that [16] calls ε the ‘conditional advantage’ while ε2 is referred to as the
‘advantage’; we always refer to ‘conditional advantage’ ε as ‘advantage’.

5



bounds we prove in this paper (which do not depend on this assumption);
it only affects their interpretation in Table 2 in terms of bit security. We
refer the reader to Appendix B for the security loss computation details
for the entries of Table 2.

We make the following remarks about Table 2. Whereas all previous
proofs for FO applied to non-deterministic IND-CPA weak schemes in-
curred at least a Îť bit security loss (due to the square-root advantage
loss in the CCA bound), our proof removes this Îť bit overhead, and in-
stead incurs a loss 4 log d that depends only on the query depth d of the
CCA distinguisher. In particular, this means that our security proof is
nearly tight for low query depth attacks (i.e., when log d is much smaller
than Îť), its loss is less than Îť bits for log d < Îť/4.The case of (relatively)
low query depth attacks ruled out by our proof tends to be of high prac-
tical interest, since it corresponds, for instance, to massively parallelized
attacks, which are the standard approach to deal with high computation
costs in practical cryptanalyses. An additional requirement of our scheme
is injectivity, but it turns out that it is commonly satisfied by many prac-
tical weak schemes, as argued in [5]. We leave a detailed investigation
of injectivity of the second round PQC NIST KEM candidates [18] to
future work (see [5, Appendix D] for a short discussion). We also remark
that although our work and [5] need the extra injectiveness assumption, it
gives a better bound than prior works for modular FO proofs (those that
decompose into a composition of two proofs: one for the T transform and
one for the U transform). The prior works in Table 2 can get the same
bound overall for FO but only via a direct proof for whole FO transform
(combining the T and U transforms). The reason we do not adapt prior
FO proofs that do not rely on the injectiveness property is that those
proofs also seem to require an O2H Lemma where the extractor works
with single-sided oracles for either G or H, rather than the G and H
requirement we (and [5]) have in our ‘double-sided’ O2H Lemma.

Techniques. To explain our MRM security proof technique, we consider
the following example and explain the difficulty encountered by previous
O2H proofs, and then our observations leading to our MRM technique
for resolving this difficulty.

Consider the following O2H distinguisher AO that makes 1 query
(with depth 1) to its quantum oracle and makes a measurement on the
resulting state to distinguish whether O = H or O = G. The oracle input
(first) and output (second) registers are denoted by in and out. Given
z = (enc(x), H(x)), the distinguisher AO prepares in the input register
in a superposition of the form

∑
x′∈X

√
px′ |x′〉 and queries O to get the

6



Table 2. Comparison of security bounds for FO-type non-deterministic IND-CPA to
IND-CCA transforms in the QROM. The ‘CCA bound’ column shows the dependence
of the upper bound on CCA attacker advantage Adv(A) against the FO-transformed
scheme in terms of the attacker advantage Îľ against the weak scheme transformed by
FO, and A’s oracle query depth d ≤ q (where q is the total number of random oracle
queries). For simplicity, in this table, we only take into account the dependence in Îľ,
and neglect other additive terms and (small) multiplicative constants. In all cases listed,
the run-time of the weak scheme attacker is within a constant factor of the run-time of
the CCA scheme. The required weak scheme security notion is shown in column ‘Weak
scheme’. The ‘Security loss’ column indicates the bit security loss of the CCA bound
(see text). Note that all the weak schemes are not required to enjoy perfect correctness
of decryption.

CCA bound Security loss Weak scheme

[10] q3/2 ¡ ξ1/4 3Ν+ 9 log q IND-CPA

[11, 15, 13] d1/2 ¡ ξ1/2 Ν+ log d IND-CPA

[5] d1/2 ¡ ξ1/2 Ν+ log d IND-CPA
injective

This work d2 ¡ ξ 4 log d IND-CPA
injective

state

|ψO〉 =
∑
x′∈X

√
px′ |x′, O(x′)〉 = √px|x,O(x)〉+

∑
x′ 6=x

√
px′ |x′, O(x′)〉,

where
∑
x′∈X px′ = 1. Let |ψ6=x〉 :=

∑
x′ 6=x

√
px′

1−px
|x′, H(x′)〉. Recalling

that G and H differ only on x, we are in one of the following two cases:

|ψH〉 = √px|ψHx 〉+
√

1− px|ψ 6=x〉 and |ψG〉 = √px|ψGx 〉+
√

1− px|ψ6=x〉,

with |ψHx 〉 := |x,H(x)〉 and |ψGx 〉 := |x,G(x)〉.
Since the amplitude of in = |x〉 in |ψH〉 is √px, measuring the input

register in forA’s query would give the secret x with probability Adv(B) =
Pr[Min=|x〉|ψO〉] = px. This is in fact the strategy of the one-wayness
adversary B constructed from A in prior O2H security proofs.

On the other hand, as observed in [14], the trace distance between
|ψG〉 and |ψH〉 is

√
1− (|ψG〉, |ψH〉)2 =

√
1− (1− px)2 =

√
(2− px)px

and therefore there exists a projective measurement MV = (MV , I−MV )
(whereMV is a projector on a subspace V of the state space)4 that A can

4 Here, we assume that A outputs 1 when the result of measurement space is a state
in subspace V .

7



perform on |ψO〉 to distinguish the case O = H from O = G with distin-
guishing advantage Adv(A) = ‖MV |ψH〉‖2 − ‖MV |ψG〉‖2 =

√
(2− px)px

(see [17, Chapter 9]). The existence of such a distinguisher with a square
root advantage ≈

√
2px led the authors of [14, 5] to the suggestion that

removing the square-root loss from the O2H security reduction may be
impossible in the quantum setting.

Let us exhibit such the worst-case MV that A could use. Consider
MV = |v〉〈v| that projects the state on a single unit vector |v〉, with |v〉 de-
fined as lying on the plane spanned by |ψG〉 and |ψH〉, and at angle π/4+
θ/2 from |ψG〉 if |ψH〉 is at angle θ from |ψG〉. Then Adv(A) = cos2(π/4+
θ/2)− cos2(π/4− θ/2) = sin θ =

√
1− (1− px)2 =

√
(2− px)px ≈

√
2px.

Our MRM technique for resolving the above conundrum stems from
the observation that to achieve its high ≈

√
2px advantage, the above

example distinguisher A uses a measurement MV that itself encodes the
secret x. Indeed, in the measurement vector |v〉 the state in = |x〉 has
amplitude ≈ 1/

√
2 when px is small. Hence, as A can measure along |v〉,

it must somehow store it and we should be able to extract x from A with
high probability by simply measuring in of |v〉 in the computational basis.

The above idea raises the question of how to set up the system state to
be |v〉. The answer is simply to let A perform its distinguishing measure-
ment MV on |ψH〉.5 If the measurement is MV , the state collapses to the
state MV |ψH〉/‖MV |ψH〉‖. In the above example, this is |v〉 with prob-
ability ≈ 1/2 when px is small. In the standard quantum computational
model, since A’s measurement MV is not performed with respect to the
computational basis (note that |v〉 is a superposition of computational
basis vectors), applying MV to the oracle output state is implemented by
A as a composition of a unitary UV followed by a computational basis
measurement Mβ of a qubit register β corresponding to A’s output bit
(where UV is designed so that it maps the state |v〉 to a state with β = 1).
Then, setting up the system state to be |v〉 actually consists in running
A with oracle H to obtain the state |ψH〉, applying UV followed by A’s
output qubit measurement Mβ, and if the result of the latter measure-
ment is β = 1, then rewinding the collapsed output state of A to the step
before the measurement by applying the inverse unitary U−1

V (so that
effectively the measurement projector MV = U−1

V Mβ=|1〉UV is applied on
the state |ψH〉).

Overall, we obtain an efficient MRM-based quantum algorithm C to
extract x from A that works as follows for q = d = 1: run AH and query

5 Our actual general reduction applies it to a uniform superposition 1
2 (|ψH〉+ |ψG〉);

see below.

8



theH oracle to set up the state |ψH〉, continue runningA until it performs
its measurement MβUV and, if the result is β = |1〉, rewind A back to
just after the query by running U−1

V and apply measurement Min on the
in register to extract x, achieving overall success probability ≈ 1/4 for
the above example distinguisher A when px is small.

In our new O2H security proof, we show that (a slight variant of) the
above MRM extraction technique works for q = d = 1 in the case where
MV is a general measurement. More precisely, we show that the advan-
tage of any distinguisher A cannot exceed 4 ¡max(Adv(B),Adv(C)), where
Adv(C) is the probability that our MRM-based extractor recovers x, and
Adv(B) = px is the probability that the direct query measurement algo-
rithm B recovers x. Our actual extraction algorithm D therefore runs A
twice: in the first run of A, algorithm D runs the direct query measure-
ment algorithm B to attempt to compute x, and in the second run of A,
algorithm D runs our MRM-based algorithm C to attempt to compute x.
By the above bound, the advantage of A is at most 4 times the success
probability of D.

The proof of our new O2H bound is based on re-writing Adv(A) :=
|‖MV |ψG〉‖2 − ‖MV |ψH〉‖2| as an inner product of the form

Adv(A) ≤
∣∣∣(|ψG〉 − |ψH〉,MV (|ψG〉+ |ψH〉)

)∣∣∣ .
At this point, we use the crucial fact that since G and H differ only on x,
|ψG〉−|ψH〉 = |ψGx 〉+ |ψHx 〉 is a vector in the subspace E|x〉 of vectors with
in = |x〉, so it is unchanged by applying a projection Min=|x〉 onto E|x〉.
Consequently, the inner-product above can be rewritten as

Adv(A) ≤
∣∣∣(Min=|x〉(|ψG〉 − |ψH〉),Min=|x〉MV (|ψG〉+ |ψH〉)

)∣∣∣ .
Now, we observe that the norm ‖Min=|x〉(|ψG〉 − |ψH〉)‖ of the vector on
the left of the inner-product is (up to a factor of 2) the square-root of the
advantage px of the direct measurement extraction algorithm B, whereas
the norm

‖Min=|x〉MV (|ψG〉+ |ψH〉)‖ = ‖Min=|x〉U
−1
V Mβ=|1〉UV (|ψG〉+ |ψH〉)‖

of the vector on the right of the inner-product is (up to a factor of 2) the
square-root of the advantage of a variant of the MRM-based extraction
algorithm C. Applying the Cauchy-Schwarz inequality gives our bound

Adv(A) ≤ 4 ·
√

Adv(B) ¡
√

Adv(C) ≤ 4 ·max(Adv(B),Adv(C)),

9



for q = d = 1. We extend our O2H security proof to the case of any depth
d ≥ 1 by applying a standard hybrid argument over d hybrid distributions
in which the oracle O is used only to answer the i-th depth of A, which
leads to an additional loss of a factor d in our bound on Adv(A).

We apply the new O2H lemma to the FO transform, by showing that
a slight variant of the proof of security for the FO 6⊥ (‘implicit rejection’)
variant based on the ‘double-sided’ O2H lemma from [5] suffices for use
with our new O2H lemma, without any significant reduction cost. The
reason we cannot directly plug in our new ‘double-sided’ O2H lemma
in the FO security proof of [5] is the limitation of our new O2H lemma
to ‘efficiently checkable’ events for the definition of distinguisher A. Our
modified proof applies the lemma with the event ‘A outputs 1’ instead.
By the general tight equivalence results of [5, Theorem 5], we also obtain
an improved security proof for other variants FO⊥ (‘explicit rejection’)
and FO 6⊥m (key derived from message only).

Open problems. Our new O2H security proof for q = d = 1 oracle
queries crucially makes use of the fact that |ψG〉−|ψH〉 is in the subspace
of vectors with in = |x〉. This property may no longer be satisfied after
q > 1 queries, and currently, we handle this difficulty via a hybrid argu-
ment that loses a factor q in the advantage (in the presentation of our
reduction we actually only lose a factor d ≤ q that is the query depth, but
in the worst-case we have d = q). The security proofs of [1, 5] make use
of semi-classical oracles or a variant of Zhandry’s quantum query record-
ing technique [26] to reduce (or even eliminate) the loss factor q in the
advantage, but they do not seem to be easily compatible with our MRM
technique. An interesting open problem is to find an even tighter secu-
rity proof that combines our MRM technique with those techniques to
give a fully tight reduction for O2H in the quantum setting. Relaxing the
‘double-sided’ aspect of our O2H Lemma to a ‘single-sided’ variant (like
the original O2H Lemma [23]) is also left as an interesting question. Re-
moving the injectivity assumption and finding other applications for our
O2H Lemma and the underlying MRM technique are further questions
left open by our work.

Additional related work. To the best of our knowledge, the use of
quantum circuit rewinding is novel in the context of the O2H Lemma, but
there is a body of work using different forms of quantum circuit rewinding
in other applications, notably in the analysis of quantum security of zero-
knowledge protocols. Watrous [24] presented a quantum rewinding lemma,
which is a procedure involving multiple ‘measure-rewind’ iterations with

10



interleaved unitary gates, in order to approximate a desired collapsed
measured state with any desired fidelity. The procedure assumes a near
independence of the measurement probabilities on the input state, which
suffices to prove the zero-knowledge property of certain protocols. Our
MRM technique does not make such near independence assumptions (in-
deed the measurement distribution of the distinguisher may strongly de-
pend on the input state), but only applies one ‘measure-rewind-measure’
iteration. Unruh [22] presented a form of rewinding extraction technique
for proving soundness of zero-knowledge proof of knowledge protocols
against quantum attacks. However, the purpose of rewinding there is to
approximate the previous state of the attacker while minimising the dis-
turbance of the measurement, whereas in our MRM technique, we actually
want the measurement to disturb the state in order to extract knowl-
edge from the measurement vector. Later work by Ambianis et al. [2]
showed the necessity of restrictions of Unruh’s rewinding in the context
of quantum-secure proofs of knowledge.

2 Preliminaries

For a finite set H, we denote by H
$← H the sampling of a uniformly

random element H from H. If A is an algorithm, we denote by b← A(z)
the assignment to b of the output of A run on input z.

Let C denote the set of complex numbers. For z ∈ C, we denote the
absolute value of z by |z| and the complex conjugate of z by z̄. The
(complex) inner product between two vectors |u〉 = (u0, . . . , un−1) and
|v〉 = (v0, . . . , vn−1) in Cn is denoted by (|u〉, |v〉) :=

∑
i ūi · vi. Let |v〉 ∈

Cn, then ‖|v〉‖ =
√

(|v〉, |v〉) denotes its Euclidean norm. For a linear
transformation M , the Hermitian (adjoint) operation on M is denoted
by M †.

2.1 Quantum Computations
A qubit is a quantum system defined over {0, 1}. Given two orthonormal
vectors |0〉, |1〉, let S be the state space of a single qubit, namely

S =
{
α0|0〉+ α1|1〉 : |α0|2 + |α1|2 = 1, α0, α1 ∈ C

}
.

For an integer N ≥ 1, the state space of a quantum system (register) of
N qubits is the N -fold tensor product of S and is denoted by

S⊗N =

 ∑
in∈{0,1}N

αin|in1〉 · · · |inN 〉 :
∑

in∈{0,1}N

|ιin|2 = 1, ιin ∈ C

 .
11



For x = (x1, . . . , xN ) ∈ {0, 1}N , the associated computational basis
vector of S⊗N is x = |x1〉|x2〉 · · · |xN 〉, and is denoted by |x〉. The set
of all 2N computational basis states {|x〉} forms an orthonormal basis
for S⊗N . A linear combination |φ〉 =

∑
x∈{0,1}N αx|x〉 of computational

basis states |x〉 is referred to as a superposition of computational basis
states. We refer to the weight αx as the amplitude of |x〉 in state |φ〉.

Given the state |φin〉 ∈ S⊗N of an N -qubit register in and a value
y ∈ {0, 1}N , we denote by Min=|y〉 : S⊗N → S⊗N the operator that
applies the projection |y〉〈y| map to the state |φin〉 of register in to get
the new state |y〉〈y||φin〉. This projector can be generalized to a projector
MEV

onto a subspace EV = {
∑
in∈V αin|in〉 : αin ∈ C} defined by a

subset V ⊆ {0, 1}N , which applies the projection map
∑
y∈V |y〉〈y| to

a state |φin〉 ∈ S⊗N . For example, for a subset S ⊆ {0, 1}N , we define
S⊕n := {in ∈ ({0, 1}N )n : ∃ i with ini ∈ S}, and then MES⊕n is the
projector onto subspace ES⊕n := {

∑
in∈S⊕n αin|in〉 : αin ∈ C}. We use

the same notation for operators and projectors even if they are applied
to non-normalized vectors in CN . It can be checked that any projector
operator MEV

is Hermitian (i.e., we have M † = M) and idempotent (i.e.,
we have M2 = M).

A measurement in the computational basis on a register in that is
in state |φin〉 ∈ S⊗N returns the measurement result y ∈ {0, 1}N with
probability P = ‖Min=|y〉|φin〉‖2 and changes (‘collapses’) the state of
in to |φ′in〉 = Min=|y〉|φin〉

‖Min=|y〉|φin〉‖ . Such a measurement of register in is denoted
byMin. A general projective measurement is defined by a set of projection
operators {M1, . . . ,Mn} where Mi’s project onto subspaces Vi that are
mutually orthogonal and whose sum is the whole state space. For exam-
ple, for any subspace V of S⊗N , we can define the projective measurement
MV = (MV , I −MV ) where MV is the projector onto V and I −MV is
the projector onto the orthogonal complement of V . Any general projec-
tive measurement can be implemented by composing a unitary operation
followed by a measurement in computational basis. Each measurement
costs one time unit.

A quantum algorithm executes a sequence of unitary gate operations
for a fixed set F containing Hadamard, phase, CNOT and π/8 gates.
Each gate is also counted as one unit of time. The overall time taken to
perform a quantum algorithm A is denoted by TA. An efficient quantum
algorithm runs a polynomial-time (in N) sequence of gate operations or
measurements.

Given a function H : X → Y = {0, 1}N , a quantum-accessible or-
acle O of H is modeled by a unitary transformation UH operating on

12



two registers in, out with state spaces S⊗N , in which |x, y〉 is mapped to
|x, y ⊕H(x)〉, where ⊕ denotes XOR group operation on Y . A quantum
algorithm with quantum random oracle O performs a mix of classical
and quantum unitary algorithms. This can be efficiently converted, up
to a constant factor overhead and same number of oracle queries [17],
to a purely unitary algorithm that applies a unitary followed by a fi-
nal set of measurements. A purely unitary algorithm making q oracle
queries to O is denoted by (OUi)qi=1, where Ui is a unitary operation
applied before the i-th call to oracle O. Following [5], we model a quan-
tum algorithm A making parallel queries to a quantum oracle O as a
quantum algorithm making d ≤ q queries to an oracle O⊗n consisting
of n = q/d parallel copies of oracle O. Given an input state of n pairs
of in/out registers |x1〉|y1〉 · · · |xn〉|yn〉, the oracle of O⊗n maps it to the
state |x1〉|y1⊕O(x1)〉 · · · |xn〉|yn⊕O(xn)〉. We call d the algorithm’s query
depth, n the parallelization factor, and q = n ¡d the total number of oracle
";"""date"",""2021-04-07T07:20:48Z""
""pdf:unmappedUnicodeCharsPerPage"",""2"",""0"",""5"",""0"",""0"",""5"",""53"",""38"",""60"",""5"",""22"",""40"",""15"",""35"",""41"",""34"",""105"",""113"",""63"",""18"",""3"",""6"",""17"",""6"",""16"",""5"",""30"",""25"",""6"",""0"",""7"",""10"",""20"",""0""
""pdf:PDFVersion"",""1.5""
""xmp:CreatorTool"",""TeX""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dcterms:created"",""2021-04-07T07:20:48Z""
""language"",""en""
""Last-Modified"",""2021-04-07T07:20:48Z""
""dcterms:modified"",""2021-04-07T07:20:48Z""
""dc:format"",""application/pdf; version=1.5""
""Last-Save-Date"",""2021-04-07T07:20:48Z""
""pdf:docinfo:creator_tool"",""TeX""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2021-04-07T07:20:48Z""
""meta:save-date"",""2021-04-07T07:20:48Z""
""pdf:encrypted"",""false""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.21 (TeX Live 2020) kpathsea version 6.3.2""
""modified"",""2021-04-07T07:20:48Z""
""Content-Length"",""573243""
""pdf:hasMarkedContent"",""false""
""Content-Type"",""application/pdf""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.21 (TeX Live 2020) kpathsea version 6.3.2""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""trapped"",""False""
""meta:creation-date"",""2021-04-07T07:20:48Z""
""created"",""2021-04-07T07:20:48Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""34""
""Creation-Date"",""2021-04-07T07:20:48Z""
""resourceName"",""454.pdf""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""1788"",""2214"",""2316"",""2068"",""2388"",""2274"",""1734"",""2184"",""1807"",""2229"",""1781"",""2143"",""1654"",""1154"",""1725"",""1902"",""1154"",""1215"",""1164"",""1172"",""1397"",""1677"",""1645"",""1729"",""1760"",""1764"",""1011"",""1218"",""2210"",""2533"",""1284"",""1247"",""1246"",""936""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""producer"",""pdfTeX-1.40.21""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""pdfTeX-1.40.21""
""pdf:docinfo:created"",""2021-04-07T07:20:48Z""
";https://scholar.google.ch/scholar?start=700&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098800-187;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;MPSign: a signature from small-secret middle-product learning with errors;S Bai, D Das, R Hiromasa, M Rosca, A Sakzad… ; … Conference on Public …, 2020  Springer;;"… a_i\) is uniform in \(\mathbb {Z}_q[x]/f\), \(e_i \in \mathbb {Z}[x]/f\) has random coefficients of small

magnitudes, and the so-called secret \(s\in \mathbb {Z}_q[x]/f\) is uniformly sampled but identical

across all oracle calls. The goal is to distinguish between the two types of oracles …";Cité 2 fois;Les 7 versions;[HTML] monash.edu;https://research.monash.edu/en/publications/mpsign-a-signature-from-small-secret-middle-product-learning-with;"






    	
            Skip to main navigation
        
	
                Skip to search
            
	
            Skip to main content

            
        










    
        
            
                
                
                    
                        [image: Monash University Logo]
                    
                
                
                    	
                                
                                    
                                    Help & FAQ
                                
                            


                
                
                
            

        

        
        
            
                
                    
                        
                            	
                                    Home
                                
	
                                        Profiles
                                    
	
                                        Research Units
                                    
	
                                        Equipment
                                    
	
                                        Projects
                                    
	
                                        Research output
                                    
	
                                        Prizes
                                    
	
                                        Activities
                                    
	
                                        Press / Media
                                    


                        
                        
                            
                                


    
        
            
                
                    Search by expertise, name or affiliation
                    
                


                
                    
                        
                    
                

            

        

    




                            

                        
                    

                

            

        
    

    
        
    

        
        
        
         
            
        



    
        
            MPSign: a signature from small-secret middle-product learning with errors


            Shi Bai, Dipayan Das, Ryo Hiromasa, Miruna Rosca, Amin Sakzad, Damien StehlĂŠ, Ron Steinfeld, Zhenfei Zhang


            	Department of Software Systems & Cybersecurity



            Research output: Chapter in Book/Report/Conference proceeding › Conference Paper › Research › peer-review


        


        











    
        
            
                
                
                    
                        

                        
                            
                                
                                    

                                
                            

                        
                    

                
            

        
    


    





    
    
        
            	
                    
                        
                        Overview
                    
                


        
    

    




    
        

        
            
        
            
                
                    
                        
                        
                            Abstract

                        We describe a digital signature scheme, whose security relies on the conjectured hardness of the Polynomial Learning With Errors problem for at least one defining polynomial within an exponential-size family (as a function of the security parameter). The proposed signature scheme follows the Fiat-Shamir framework and can be viewed as the Learning With Errors counterpart of the signature scheme described by Lyubashevsky at Asiacrypt 2016, whose security relies on the conjectured hardness of the Polynomial Short Integer Solution problem for at least one defining polynomial within an exponential-size family. As opposed to the latter, enjoys a security proof from that is tight in the quantum-access random oracle model. The main ingredient is a reduction from for an arbitrary defining polynomial among exponentially many, to a variant of the Middle-Product Learning with Errors problem that allows for secrets that are small compared to the working modulus. We present concrete parameters for using such small secrets, and show that they lead to significant savings in signature length over Lyubashevsky’s Asiacrypt 2016 scheme (which uses larger secrets) at typical security levels. As an additional small contribution, and in contrast to (or), we present an efficient key-recovery attack against Lyubashevsky’s scheme (or the inhomogeneous problem), when it is used with sufficiently small secrets, showing the necessity of a lower bound on secret size for the security of that scheme.



                        	Original language	English
	Title of host publication	Public-Key Cryptography – PKC 2020 
	Subtitle of host publication	23rd IACR International Conference on Practice and Theory of Public-Key Cryptography Edinburgh, UK, May 4–7, 2020 Proceedings, Part II
	Editors	Aggelos Kiayias, Markulf Kohlweiss, Petros Wallden, Vassilis Zikas
	Place of Publication	Cham Switzerland
	Publisher	Springer
	Pages	66-93
	Number of pages	28
	ISBN (Electronic)	9783030453886
	ISBN (Print)	9783030453879
	DOIs		https://doi.org/10.1007/978-3-030-45388-6_3 


	Publication status	Published - 2020
	Event	International Conference/Workshop on Practice and Theory in Public Key Cryptography 2020 - Online
Duration: 1 Jun 2020 → 4 Jun 2020
Conference number: 23rd
https://link.springer.com/book/10.1007/978-3-030-45388-6 (Proceedings)
https://pkc.iacr.org/2020/ (Website)


Publication series
	Name	Lecture Notes in Computer Science 
	Publisher	Springer
	Volume	12111 
	ISSN (Print)	0302-9743
	ISSN (Electronic)	1611-3349


Conference
	Conference	International Conference/Workshop on Practice and Theory in Public Key Cryptography 2020
	Abbreviated title	PKC 2020
	Period	1/06/20 → 4/06/20
	Internet address		https://link.springer.com/book/10.1007/978-3-030-45388-6 (Proceedings)
	https://pkc.iacr.org/2020/ (Website)





                        


                        

                    


                    
                        
                        
                            Access to Document

                        	10.1007/978-3-030-45388-6_3


	Link to publication in Scopus





                        

                        

                        


                    

                

            

        
        

        
            
        
            
        
            
        
            
        
            
        
        
            
                
    Cite this

    	
                APA
            
	
                Author
            
	
                BIBTEX
            
	
                Harvard
            
	
                Standard
            
	
                RIS
            
	
                Vancouver
            


    
        
            
                Bai, S., Das, D., Hiromasa, R., Rosca, M., Sakzad, A., Stehlé, D., Steinfeld, R., & Zhang, Z. (2020). MPSign: a signature from small-secret middle-product learning with errors. In A. Kiayias, M. Kohlweiss, P. Wallden, & V. Zikas (Eds.), Public-Key Cryptography – PKC 2020 : 23rd IACR International Conference on Practice and Theory of Public-Key Cryptography Edinburgh, UK, May 4–7, 2020 Proceedings, Part II (pp. 66-93). (Lecture Notes in Computer Science ; Vol. 12111 ). Springer. https://doi.org/10.1007/978-3-030-45388-6_3

            

        
            
                Bai, Shi ; Das, Dipayan ; Hiromasa, Ryo ; Rosca, Miruna  ; Sakzad, Amin ; Stehlé, Damien  ; Steinfeld, Ron ; Zhang, Zhenfei. / MPSign : a signature from small-secret middle-product learning with errors. Public-Key Cryptography – PKC 2020 : 23rd IACR International Conference on Practice and Theory of Public-Key Cryptography Edinburgh, UK, May 4–7, 2020 Proceedings, Part II. editor / Aggelos Kiayias ; Markulf Kohlweiss ; Petros Wallden ; Vassilis Zikas. Cham Switzerland : Springer, 2020. pp. 66-93 (Lecture Notes in Computer Science ).

            

        
            
                @inproceedings{0d40db6b26dc4384bbebf9d52d60a7e6,
  title     = ""MPSign: a signature from small-secret middle-product learning with errors"",
  abstract  = ""We describe a digital signature scheme, whose security relies on the conjectured hardness of the Polynomial Learning With Errors problem for at least one defining polynomial within an exponential-size family (as a function of the security parameter). The proposed signature scheme follows the Fiat-Shamir framework and can be viewed as the Learning With Errors counterpart of the signature scheme described by Lyubashevsky at Asiacrypt 2016, whose security relies on the conjectured hardness of the Polynomial Short Integer Solution problem for at least one defining polynomial within an exponential-size family. As opposed to the latter, enjoys a security proof from that is tight in the quantum-access random oracle model. The main ingredient is a reduction from for an arbitrary defining polynomial among exponentially many, to a variant of the Middle-Product Learning with Errors problem that allows for secrets that are small compared to the working modulus. We present concrete parameters for using such small secrets, and show that they lead to significant savings in signature length over Lyubashevsky{\textquoteright}s Asiacrypt 2016 scheme (which uses larger secrets) at typical security levels. As an additional small contribution, and in contrast to (or), we present an efficient key-recovery attack against Lyubashevsky{\textquoteright}s scheme (or the inhomogeneous problem), when it is used with sufficiently small secrets, showing the necessity of a lower bound on secret size for the security of that scheme."",
  author    = ""Shi Bai and Dipayan Das and Ryo Hiromasa and Miruna Rosca and Amin Sakzad and Damien Stehl{\'e} and Ron Steinfeld and Zhenfei Zhang"",
  year      = ""2020"",
  doi       = ""10.1007/978-3-030-45388-6_3"",
  language  = ""English"",
  isbn      = ""9783030453879"",
  series    = ""Lecture Notes in Computer Science "",
  publisher = ""Springer"",
  pages     = ""66--93"",
  editor    = ""Aggelos Kiayias and Markulf Kohlweiss and Petros Wallden and Vassilis Zikas"",
  booktitle = ""Public-Key Cryptography – PKC 2020"",
  note      = ""International Conference/Workshop on Practice and Theory in Public Key Cryptography 2020, PKC 2020 ; Conference date: 01-06-2020 Through 04-06-2020"",
  url       = ""https://link.springer.com/book/10.1007/978-3-030-45388-6, https://pkc.iacr.org/2020/"",
}


            

        
            
                Bai, S, Das, D, Hiromasa, R, Rosca, M, Sakzad, A, Stehlé, D, Steinfeld, R & Zhang, Z 2020, MPSign: a signature from small-secret middle-product learning with errors. in A Kiayias, M Kohlweiss, P Wallden & V Zikas (eds), Public-Key Cryptography – PKC 2020 : 23rd IACR International Conference on Practice and Theory of Public-Key Cryptography Edinburgh, UK, May 4–7, 2020 Proceedings, Part II. Lecture Notes in Computer Science , vol. 12111 , Springer, Cham Switzerland, pp. 66-93, International Conference/Workshop on Practice and Theory in Public Key Cryptography 2020, 1/06/20. https://doi.org/10.1007/978-3-030-45388-6_3

            

        
            
                MPSign : a signature from small-secret middle-product learning with errors. / Bai, Shi; Das, Dipayan; Hiromasa, Ryo; Rosca, Miruna; Sakzad, Amin; StehlĂŠ, Damien; Steinfeld, Ron; Zhang, Zhenfei.
 Public-Key Cryptography – PKC 2020 : 23rd IACR International Conference on Practice and Theory of Public-Key Cryptography Edinburgh, UK, May 4–7, 2020 Proceedings, Part II. ed. / Aggelos Kiayias; Markulf Kohlweiss; Petros Wallden; Vassilis Zikas. Cham Switzerland : Springer, 2020. p. 66-93 (Lecture Notes in Computer Science ; Vol. 12111 ).Research output: Chapter in Book/Report/Conference proceeding › Conference Paper › Research › peer-review


            

        
            
                TY  - GEN
T1  - MPSign
T2  - International Conference/Workshop on Practice and Theory in Public Key Cryptography 2020
AU  - Bai, Shi
AU  - Das, Dipayan
AU  - Hiromasa, Ryo
AU  - Rosca, Miruna
AU  - Sakzad, Amin
AU  - StehlĂŠ, Damien
AU  - Steinfeld, Ron
AU  - Zhang, Zhenfei
N1  - Conference code: 23rd
PY  - 2020
Y1  - 2020
N2  - We describe a digital signature scheme, whose security relies on the conjectured hardness of the Polynomial Learning With Errors problem for at least one defining polynomial within an exponential-size family (as a function of the security parameter). The proposed signature scheme follows the Fiat-Shamir framework and can be viewed as the Learning With Errors counterpart of the signature scheme described by Lyubashevsky at Asiacrypt 2016, whose security relies on the conjectured hardness of the Polynomial Short Integer Solution problem for at least one defining polynomial within an exponential-size family. As opposed to the latter, enjoys a security proof from that is tight in the quantum-access random oracle model. The main ingredient is a reduction from for an arbitrary defining polynomial among exponentially many, to a variant of the Middle-Product Learning with Errors problem that allows for secrets that are small compared to the working modulus. We present concrete parameters for using such small secrets, and show that they lead to significant savings in signature length over Lyubashevsky’s Asiacrypt 2016 scheme (which uses larger secrets) at typical security levels. As an additional small contribution, and in contrast to (or), we present an efficient key-recovery attack against Lyubashevsky’s scheme (or the inhomogeneous problem), when it is used with sufficiently small secrets, showing the necessity of a lower bound on secret size for the security of that scheme.
AB  - We describe a digital signature scheme, whose security relies on the conjectured hardness of the Polynomial Learning With Errors problem for at least one defining polynomial within an exponential-size family (as a function of the security parameter). The proposed signature scheme follows the Fiat-Shamir framework and can be viewed as the Learning With Errors counterpart of the signature scheme described by Lyubashevsky at Asiacrypt 2016, whose security relies on the conjectured hardness of the Polynomial Short Integer Solution problem for at least one defining polynomial within an exponential-size family. As opposed to the latter, enjoys a security proof from that is tight in the quantum-access random oracle model. The main ingredient is a reduction from for an arbitrary defining polynomial among exponentially many, to a variant of the Middle-Product Learning with Errors problem that allows for secrets that are small compared to the working modulus. We present concrete parameters for using such small secrets, and show that they lead to significant savings in signature length over Lyubashevsky’s Asiacrypt 2016 scheme (which uses larger secrets) at typical security levels. As an additional small contribution, and in contrast to (or), we present an efficient key-recovery attack against Lyubashevsky’s scheme (or the inhomogeneous problem), when it is used with sufficiently small secrets, showing the necessity of a lower bound on secret size for the security of that scheme.
UR  - http://www.scopus.com/inward/record.url?scp=85090009307&partnerID=8YFLogxK
U2  - 10.1007/978-3-030-45388-6_3
DO  - 10.1007/978-3-030-45388-6_3
M3  - Conference Paper
AN  - SCOPUS:85090009307
SN  - 9783030453879
T3  - Lecture Notes in Computer Science 
SP  - 66
EP  - 93
BT  - Public-Key Cryptography – PKC 2020
A2  - Kiayias, Aggelos
A2  - Kohlweiss, Markulf
A2  - Wallden, Petros
A2  - Zikas, Vassilis
PB  - Springer
CY  - Cham Switzerland
Y2  - 1 June 2020 through 4 June 2020
ER  - 


            

        
            
                Bai S, Das D, Hiromasa R, Rosca M, Sakzad A, Stehlé D et al. MPSign: a signature from small-secret middle-product learning with errors. In Kiayias A, Kohlweiss M, Wallden P, Zikas V, editors, Public-Key Cryptography – PKC 2020 : 23rd IACR International Conference on Practice and Theory of Public-Key Cryptography Edinburgh, UK, May 4–7, 2020 Proceedings, Part II. Cham Switzerland: Springer. 2020. p. 66-93. (Lecture Notes in Computer Science ). https://doi.org/10.1007/978-3-030-45388-6_3

            

        

        
    



            

        
        
        
        



    
    
    
    
    
    

    
        
        
        
    
    
        	
	
	
	
	


    





    
        

    


    

    
    

    
        
            
                
                    
                        
                        
                            
                                Powered by Pure, Scopus & Elsevier Fingerprint Engine™ © 2021 Elsevier B.V.
                            


                            We use cookies to help provide and enhance our service and tailor content. By continuing you agree to the use of cookies

                            
                            
                        


                        
                            
                            About web accessibility

                            
                                
                            

                            
                                
                            

                        


                        
                            
                                
                                    
                                        Monash University  contact form

                                    
                                

                            

                        

                    

                
            

        

    

    
        
    



    


    

    

    

    
    


";"""citation_author_orcid"",""0000-0003-4569-3384"",""0000-0003-1745-4183""
""og:image"",""https://research.monash.edu/skin/headerImage/""
""citation_publication_date"",""2020""
""citation_title"",""MPSign: a signature from small-secret middle-product learning with errors""
""citation_author_institution"",""Florida Atlantic University"",""National Institute of Technology Durgapur"",""Mitsubishi Electric"",""École Normale Supérieure de Lyon"",""Bitdefender"",""Dept of Software Systems & Cybersecurity"",""École Normale Supérieure de Lyon"",""Institut Universitaire de France"",""Dept of Software Systems & Cybersecurity"",""Algorand""
""og:site_name"",""Monash University""
""citation_publisher"",""Springer""
""language"",""en""
""title"",""MPSign: a signature from small-secret middle-product learning with errors
     — Monash University""
""citation_author_email"",""Amin.Sakzad@monash.edu"",""Ron.Steinfeld@monash.edu""
""dc:title"",""MPSign: a signature from small-secret middle-product learning with errors
     — Monash University""
""citation_language"",""English""
""Content-Encoding"",""UTF-8""
""citation_lastpage"",""93""
""Content-Type"",""text/html; charset=UTF-8""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""og:type"",""article""
""og:title"",""MPSign: a signature from small-secret middle-product learning with errors""
""citation_inbook_title"",""Public-Key Cryptography – PKC 2020 : 23rd IACR International Conference on Practice and Theory of Public-Key Cryptography Edinburgh, UK, May 4–7, 2020 Proceedings, Part II""
""citation_author"",""Shi Bai"",""Dipayan Das"",""Ryo Hiromasa"",""Miruna Rosca"",""Amin Sakzad"",""Damien StehlĂŠ"",""Ron Steinfeld"",""Zhenfei Zhang""
""resourceName"",""mpsign-a-signature-from-small-secret-middle-product-learning-with""
""X-UA-Compatible"",""IE=edge""
""citation_firstpage"",""66""
""viewport"",""width=device-width, initial-scale=1""
""citation_doi"",""10.1007/978-3-030-45388-6_3""
""og:locale"",""en_GB""
""citation_conference_title"",""International Conference/Workshop on Practice and Theory in Public Key Cryptography 2020""
""og:url"",""https://research.monash.edu/en/publications/mpsign-a-signature-from-small-secret-middle-product-learning-with""
""Content-Language"",""en""
";https://scholar.google.ch/scholar?start=730&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098791-163;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;AuthSC: Mind the Gap between Web and Smart Contracts;U Gallersdörfer, F Matthes ; arXiv preprint arXiv:2004.14033, 2020  arxiv.org;;"… Our approach combines on-chain identity assertion utilizing signatures from the respective

certificate and off-chain au- thentication of the Smart Contract stored on the Blockchain … Index

Terms—blockchain, authentication, smart contracts, ethereum, certificates 1. Introduction …";Cité 1 fois;Les 3 versions;[PDF] arxiv.org;https://arxiv.org/pdf/2004.14033;"
AuthSC: Mind the Gap between Web and Smart Contracts

Ulrich Gallersdörfer and Florian Matthes
Technical University Munich

Munich, Germany
{ulrich.gallersdoerfer,matthes}@tum.de

Abstract—Although almost all information about Smart Con-
tract addresses is shared via websites, emails, or other forms
of digital communication, Blockchains and distributed ledger
technology are unable to establish secure bindings between
websites and corresponding Smart Contracts. For a user, it
is impossible to differentiate whether a website links to a
legitimate Smart Contract set up by owners of a business or
to an illicit contract aiming to steal users’ funds. Surpris-
ingly, current attempts to solve this issue mostly comprise of
information redundancy, e.g., displaying contract addresses
multiple times in varying forms of images and texts. These
processes are burdensome, as the user is responsible for
verifying the correctness of an address. More importantly,
they do not address the core issue, as the contract itself
does not contain information about its authenticity. To solve
current issues for these applications and increase security, we
propose a solution that facilitates publicly issued SSL/TLS-
certificates of Fully-Qualified Domain Names (FQDN) to
ensure the authenticity of Smart Contracts and their owners.
Our approach combines on-chain identity assertion utilizing
signatures from the respective certificate and off-chain au-
thentication of the Smart Contract stored on the Blockchain.
This approach allows to tackle the aforementioned issue and
further enables applications such as the identification of
consortia members in permissioned networks. The system
is open and transparent, as the only requirement for usage
is ownership of an SSL/TLS-certificate. To enable privacy-
preserving authenticated Smart Contracts, we allow one-way
and two-way binding between website and contract. Further,
low creation and maintenance costs, a widely accepted public
key infrastructure and user empowerment will drive poten-
tial adaption of Ethereum Authenticated Smart Contracts
(AuthSC).

Index Terms—blockchain, authentication, smart contracts,
ethereum, certificates

1. Introduction

Users in publicly available Blockchain-based systems
face a highly dangerous and hostile environment, as at-
tackers have high incentives to steal users’ funds. Al-
though the underlying ledger provides immutable Smart
Contracts, decentralized key management, and resistant
consensus mechanisms, fraud, hacks, impersonation, and
other malicious activities are to be encountered on a daily
basis. Resolving issues of Smart Contract engineering, the
formal verification of Contracts or the design of secure
programming languages are subject to active research.

However, an often ignored issue is the weak link to the in-
formation stored on Blockchains: The user needs to know
the exact location of the Smart Contract or the externally
owned account to interact with. As these addresses consist
of random characters, e.g., in Ethereum 64 hexadecimal
characters [1], users rely on the web and a clipboard to
copy and paste address information. The called address or
Smart Contract contains no further information to verify
whether the user interacts with the intended Contract or
not.

The approach of just sharing addresses on web pages
without any further connection between the business and
the Smart Contract is prone to errors and can be exploited
by attackers. The Coindash ICO is an example of such an
attack [2]. At the height of Token Sales in 2017, Coindash
conducted an Initial Coin Offering (ICO), selling their
newly created token to interested investors in return for
Ether (the currency of the Ethereum Blockchain). To
advertise their token sale, the founders set up a website.
The website contained all relevant information on how to
invest their company, including the address of the Smart
Contract. The sale started and many people participated;
several million USD were sent in the first few hours; un-
fortunately, not to the intended token Smart Contract, but
to a different Smart Contract set up by malicious actors,
collecting all the investment funds. These malicious actors
had previously hacked the website and quietly replaced the
original contract address with their own, resulting in the
loss of over 7 million USD. While the Wordpress content
management system was compromised, the underlying
web server remained intact.

To solve the issue of loose coupling between web-
site and Smart Contract, we propose Ethereum authenti-
cated Smart Contracts (AuthSC). AuthSC allows endors-
ing Smart Contracts with a private/public key pair of a
TLS-certificate issued by a certificate authority (CA). This
approach enables wallets or other software, which directly
interact with Smart Contracts, to verify their authenticity
and binding to the respective website.

AuthSC contains three crucial components: the au-
thenticated Smart Contract, which stores information
about the endorsement, an off-chain verifier, which au-
thenticates the Smart Contract as well as the AuthSC
registry, which prevents downgrade-attacks and offers a
discovery service.

Our approach considers privacy-preserving authenti-
cated Smart Contracts: Entities might decide to endorse
Smart Contracts, however, do not want other parties to
retrieve their endorsement by crawling the respective
Blockchain. We expand the system to allow for an explicit

ar
X

iv
:2

00
4.

14
03

3v
1 

 [
cs

.C
R

] 
 2

9 
A

pr
 2

02
0



discovery of such contracts: In case the user journey is not
started at the website, but at the Smart Contract itself, the
user is still able to authenticate this Smart Contract. This
allows for varying applications, which we cover in Section
4. Furthermore, we discuss associated risks and potential
attacks and countermeasures.

To structure our work, we organize our paper as fol-
lows: In Section 2, we introduce the system architecture
and the methodologies to assert and authenticate Smart
Contracts. We discuss privacy, risks, and attacks in Section
3. Section 4 gives an overview of the applicability of the
proposed artifact. We discuss the limitations and advan-
tages of our approach in Section 5. We give an overview
of related work in Section 6 and end in Section 7 with a
conclusion and potential future work.

2. System Architecture

In this Section, we introduce the general approach and
give an overview of the architecture, the single compo-
nents, and the structure of the Smart Contracts. We further
display processes of the system and design considerations.

Our goal is to establish a binding between Smart Con-
tracts and websites using common SSL/TLS-certificates
which ensure the authenticity of web servers, the privacy,
and integrity of messages between browser and server.
The owner of a certificate endorses a Smart Contract by
signing the respective address and storing it within the
respective Smart Contract. Later, other parties can retrieve
the certificate from the Blockchain and validate it against
their trusted certificate authority servers, thereby authen-
ticating the contract. Afterward, they can engage with the
specific Smart Contract or further evaluate data stored
in the Smart Contract, aware of the actual identity of
the counterparty. A reference interface is available online
in [3], using Solidity for Ethereum. In theory, AuthSC
is Blockchain-independent; any other network can profit
from this methodology.

To enable identity assertion and authentication, our
system consists of three components:

• The On-Chain Authenticated Smart Contract
contains methods for storing and updating sig-
nature information. This functionality is provided
as a library and therefore independent from the
actual Smart Contract (e.g., token contract or other
purposes).

• The Off-Chain Verifier is an application that
runs outside of the Blockchain. It is responsible
for verifying on-chain assertions. It retrieves data
from the certificate issuer, the website owner, the
Blockchain, and potential certificate authorities.
With this information, it enables authentication of
on-chain information in the context of the user-
defined environment.

• The Authenticated Smart Contract Registry
prevents downgrade-attacks by providing a list of
Smart Contracts for domains. Further, it option-
ally allows for easy discovery of Smart Contracts
which implement this library. It manages a list
of existing Smart Contracts and their respective
domains such that interested parties can find these
Smart Contracts.

Figure 1 depicts the overall structure of the proposed
architecture. The On-Chain Authenticated Smart Contract
(AuthSC) is placed within the Blockchain system and
referred to by the Authenticated Smart Contract Registry.
The Off-Chain Verifier accesses the AuthSC, the DNS,
and the PKI to verify the correctness of all obtained data
and to authenticate the specific Smart Contract.

In the remainder of this Section, we analyze the
responsibilities and methodologies of the single compo-
nents.

2.1. On-Chain Authenticated Smart Contract

An entity asserts its identity to a Smart Contract by
binding it to a public domain. To allow such identity
assertion, the contract has to store the following data for
authentication:

• the fully qualified domain name for later identifi-
cation (optional)

• the signature information (the address of the Smart
Contract signed by the private key)

Additional information required for the authentication
of the Smart Contract is retrieved from external data
sources. This identity assertion functionality can be em-
bedded in an arbitrary Smart Contract, allowing AuthSC
to be used in any on-chain environment. The interface a
Smart Contract has to implement to adhere to AuthSC
is depicted in Listing 1. Please note that an FQDN is
provided as an array, e.g., hq.example.org translates to
[""org"", ""example"", ""hq""]. This approach allows
for easy access to parts of the FQDN.

1 interface ERCXXX /* is ERC165 */{
2
3 // @dev Event is emitted when the FQDN

changes
4 event FQDNChanged(string[] indexed FQDN);
5
6 // @dev Event is emitted when the signature

changes
7 event SignatureChanged(string signature);
8
9 // @dev Returns the domain for the given SC

10 function getFQDN() external view returns (
string[] memory);

11
12 // @dev Returns the signature for the given

SC
13 function getSignature() external view

returns (string memory);
14
15 // @dev Allows to set the FQDN
16 function setFQDN(string[] calldata _FQDN)

external;
17
18 // @notice Sets the signature (containing

the SC address)
19 function setSignature(string calldata

_signature) external;
20 }

Listing 1. On-Chain Smart Contract Interface in Solidity

Three steps are required to enable authentication of
the Smart Contract: Smart Contract creation, signature
generation, and signature upload. For simplicity, we omit
intermediate or supporting activities such as creating wal-
let addresses, funding the accounts, and including the
library in the respective Smart Contract.



Figure 1. High-Level Structure.

1) Smart Contract Creation: As it is impossible to
update previously existing Smart Contracts, one
has to create a new Smart Contract upfront. A
contract has to be instantiated with information
on the address of the owner of the Smart Contract
and optionally the domain to which the owner has
access to (e.g., the domain or any subdomain). If
a domain is not provided, two-way binding is not
supported, which we discuss in Section 3.
After the first step, the Smart Contract is set up
on the Blockchain.

2) Signature Generation: The signature is still
missing in the Smart Contract and thus, the SS-
L/TLS certificate has not endorsed this Smart
Contract, as any party can execute the first step
for any domain. The entity retrieves the unique
contract address and signs this string with its
private key of the SSL/TLS-certificate. As the
signature contains only one specific Smart Con-
tract address, other Smart Contracts cannot use
this information to pretend to be also endorsed
by this domain.

3) Signature Upload: The signature created in the
previous step is transmitted to the Smart Con-
tract as part of a regular transaction calling the
method setSignature. The contract validates
that the transaction is indeed created by the orig-
inal owner of the Smart Contract, as the contract
itself is not able to verify if the provided data is
correct. If the owner issued the transaction, the
payload is stored in the respective field of the
Smart Contract, awaiting later retrieval.

It is possible to reduce the process to two steps, as it is
possible to sign the address of the contract before its ini-
tialization, providing the signature alongside the domain
name. This is possible as the addresses of to-be generated
Smart Contracts are deterministic. For simplicity and to
remove possible interference with other transactions is-

sued from the same address, we decided to first upload
the contract and then actually submit the signature data,
preventing that an incorrect address is signed.

2.2. Off-Chain Verifier

Smart Contract computations must be deterministic.
Thus, a Smart Contract cannot request external data like
lists of CAs or web servers, as a recurring calculation
(e.g., in another full node in the network) might lead to
a different result. Therefore, we move the authentication
process of the endorsement stored within a Smart Contract
off-chain. The software itself needs to access the following
data sources:

• The address of the relevant Smart Contract, which
is obtained via the web or is obtained by the Au-
thenticated Smart Contract Registry or proprietary
discovery services.

• The contents of this Smart Contract, e.g., option-
ally the domain name and the signature

• The signed certificate, its public key alongside
the information of the certificate authority, ob-
tained by requesting the domain and retrieving the
SSL/TLS-certificate

• The list of trusted CAs of the user

It is possible to store the entire SSL/TLS-certificate in
the Blockchain, rendering the request to the web server
unnecessary. However, as these certificates take additional
space, we oppose to storing them on-chain for cost rea-
sons. If decentralized storage systems such as the Inter-
planetary File System (IPFS) [4] gain practical relevance,
it becomes cost-efficient to store complete certificates in
decentralized systems, no longer relying on web servers
of the respective owners. As long as such systems remain
in an early stage, we continue to request the certificate
from the respective servers.

The list of trusted certificate authorities is defined by
the user, either directly by providing a list themselves or



by the certificate authority list stored in her/his computer
or browser.

Smart Contract authentication involves four steps.
Again, we omit intermediate steps and assume a fully ac-
cessible system, also we assume that the contract address
is known.

1) Smart Contract Information Retrieval: The
application first retrieves all relevant information
for later authentication. It collects the domain and
signature data from the Smart Contract.

2) Certificate Retrieval: Afterwards, it connects to
the respective domain given in the Smart Contract
(or previously known by the website) and obtains
the certificate.

3) Smart Contract Signature Verification: The
software validates if the Smart Contract address
is signed by the private key of the certificate. As
the certificate has to belong to the website, no
additional check is required. If the signature is
correct, the software proceeds with step 4, other-
wise it aborts the identity authentication with an
error.

4) Certificate trust: After the successful verifica-
tion of the signature, the software checks whether
a trusted certificate authority has (indirectly)
signed or issued the certificate found in the Smart
Contract and the web server. If the certificate and
its public key is signed by a trusted CA, then
the identity is successfully validated, otherwise,
the program aborts with an error. It executes the
certification path validation algorithm as defined
in RFC 5280 [5].

Figure 2 depicts the steps involved in the authentica-
tion process in detail. The definitions for digital signature
methods are well established [3]. For this algorithm, we
assume that the Smart Contract address is previously
known.

2.3. Authenticated Smart Contract Registry

The previously described on-chain architecture is com-
prised of a single type of Smart Contract. A set of
such Smart Contracts is sufficient to create and manage
identities. However, it is relevant to know 1) whether a
contract exists for a given domain and 2) under which
address it is deployed. To find such contracts or check
if contracts exist, we propose extending this architecture
by introducing an Authenticated Smart Contract Registry,
which allows to quickly lookup all domains registered
on the Blockchain. This registry lists all contracts which
adhere to this interface standard and claim to be the
identity contract for a specific domain. We need to modify
such a registry for two reasons: 1) Our on-chain data does
not converge to a single truth, but allows creating different
perceptions of reality. 2) A company can decide to offer
multiple Smart Contracts, providing various services, with
their identity tied to them. We, thus, allow that multiple
Authenticated Smart Contracts can exist for the same
domain. Even though it is possible to search the complete
Blockchain for such contracts [3] [6], it is easier and faster
to use an on-chain Smart Contract.

The registry Smart Contract is in place to map domains
to Smart Contract addresses by a) storing SHA3-hashes of
domains with respective Smart Contracts and b) domains
with respective Smart Contracts for reasons we discuss in
Section 3. The usage of such contract is as follows.

1) Insertion of Contract Information: All parties
controlling authenticated Smart Contracts submit
information about their contract and optionally
the respective domain to the discovery service
Smart Contract.

2) Domain Lookup: If a user searches for a do-
main, s/he queries the registry Smart Contract and
asks for all contracts which are assigned to that
specific domain or the hash of that domain. The
contract returns all relevant contract addresses.

3) Contract authentication: The client can execute
the previously described authentication method
for each of the returned contracts, ensuring that
the correct Smart Contract, if it exists, is found.

This Registry Smart Contract relies on owners sub-
mitting their created contracts. Thus, 1) ideally every
authenticated contract is added and 2) the amount of
incorrect data is minimized. First, the entities creating
contracts have a strong incentive to be found, as they
want users and other parties to interact with their Smart
Contract, otherwise they would not have deployed it on
the Blockchain. The discovery service Smart Contract
allows them to advertise their service and enable users to
find them. Second, malicious entities which do not own
the respective TLS/SSL-certificate are discouraged from
linking respective contracts as it costs money to add the
information, the authentication of these contracts will fail
and the users will not even notice the existence of such
contracts, as modern computation power is sufficient to
process hundreds of such contracts in milliseconds. Given
this (dis)incentive structure, we allow every entity in the
network to add data to the Authenticated Smart Contract
Registry.

3. Privacy Concerns, Risks and Attacks

In this Section we discuss privacy considerations, one-
way and two-way bindings, key management risks and
downgrade-attacks on AuthSC.

3.1. Privacy Considerations

The design goal of open and transparent Blockchains
are inherently contrary to the goal of privacy of user
activity in such networks, as all transactions, messages and
deployed code is available to every node in the system. We
are aware that it is possible to crawl all Smart Contracts
stored in a Blockchain and also identify Authenticated
Smart Contracts. We acknowledge that some parties might
want to use the functionality provided by AuthSC, but do
not want to publicly state that this is the case. For that, we
introduce one-way and two-way binding between FQDN
and Smart Contract.

• One-way binding means that only the website
links to the Smart Contract; the contract itself does
not link to the website. Without knowledge about



Verifier v Smart Contract sc www

getFQDN()

return domain

getSignature()

return signature

Step 1Step 1 Verifier fetches data from sc

getCertificate(domain)

return certificate

Step 2Step 2 Verifier retrieves certificate from domain

verify(certificate.pk, sc.address, sc.signature)

return result

Step 3Step 3 Verifier checks signature

certificatePathValidation(certificate, rootCAList)

return result

Step 4Step 4 Verifier checks if certificate was signed (indirectly) by trusted CAs

Figure 2. Authentication of a Smart Contract attributed identity

the domain, the Smart Contract itself cannot be
authenticated, because it is unclear against which
domain it should be authenticated. This allows for
a privacy-preserving authenticated Smart Contract,
resulting in a contract that is findable on-chain,
however, cannot be attributed to a domain (and
therefore an owner). To enable one-way binding,
the Smart Contract itself does not store the domain
information. Nonetheless, to prevent downgrade-
attacks, it is recommended to store the address and
the hash of the domain within the registry Smart
Contract as outlined in Section 3.3.

• Two-way binding results in Smart Contracts which
can be authenticated by only knowing the re-
spective Smart Contract address. In this case, the
Smart Contract stores the FQDN within the Smart
Contract, allowing to resolve the certificate which
signed the Smart Contract address. In this case, it
is also advised to store the hash of the domain (to
prevent downgrade-attacks) as well as the domain
itself (to enable discovery) within the Authenti-

cated Smart Contract registry.

3.2. Key Management Risks

The key material in TLS/SSL-certificates faces the
following risks:

• Key Material Expiration: Key material in X.509
certificates expires regularly. Public key and signa-
ture information have to be updated, otherwise, the
verifying entity cannot assert the correctness of the
authenticated contract. To update the Smart Con-
tract, steps 2 and 3 of the assertion process have
to be executed again with the new certificate. This
procedure ensures that the previously submitted
information stored in the contract remains valid. If
an entity wants to invalidate her/his contract, s/he
updates the respective SSL/TLS-certificate, thus
invalidating the signature stored in the contract.

• Certificate Key Revocation: Key revocation be-
comes mandatory if key material gets compro-
mised. Such key material could be used to create



authenticated Smart Contracts, potentially tricking
users into believing that the new Smart Contract
does indeed belong to the compromised entity.
However, as our approach relies on the public key
of the web server, an replacement of the keys
stored on the server will also render potential
deceiving Smart Contracts invalid. The software
is not able to verify Smart Contracts with old
keys. Further, the software could also evaluate
whether the to-be verified certificates are included
in so-called certificate revocation lists (CRL). This
becomes relevant when the complete credential is
stored on-chain, as the additional check with the
web server is omitted.

3.3. Downgrade-Attacks

We found that AuthSC might be vulnerable to
downgrade-attacks.

In a downgrade-attack, an adversary tricks a party in a
communication protocol to assume that the other party is
incapable of adhering to newer (and more secure) versions
of the communication protocol, leading to the usage of
an older (and less secure) version of the protocol. As
an older version is susceptible to further attacks or has
no protection at all (e.g., plain text), an adversary can
further exploit the communication. The same is also true
for AuthSC. Looking at the base case and our introductory
example of CoinDash, it becomes apparent that the user
needs to know that a website uses AuthSC to protect their
users from sending transactions to malicious contracts.
However, we cannot expect a user to know whether the
counterparty actually implements AuthSC and in case of
CoinDash, an address swap is still possible without any
further mechanisms in place.

Therefore, the Off-Chain Verifier (or other software
implementing the authentication mechanism) needs to
know whether a contract exists for a given domain. If
the verifier obtains a contract-address from a website, it
checks if this contract supports the AuthSC interface and,
if that is not the case, another Smart Contract exists for
that domain and further if that Smart Contract can be
verified. This verification is necessary to prevent Denial
of Service attacks, as otherwise attackers could register
Smart Contracts for any domain and harm the commu-
nication between the website and their users. If such a
contract is encountered without the current Smart Contract
adhering to the interface standard, a warning is emitted to
the user, stating that the current contract has no additional
protection against impersonation and that other contracts
with such protection exist.

The Authenticated Smart Contract Registry is asked
about already existing Smart Contracts for a domain. If
the original and authenticated Smart Contract is registered
within this registry, downgrade-attacks can be prevented.

4. Applicability

In this Section, we briefly introduce potential usages
for AuthSC, allowing further usages for authenticated
Smart Contracts.

4.1. Consortia Member Identification

Companies and other entities often opt for permis-
sioned settings concerning Blockchain systems: Either
they preselect nodes that are allowed to produce blocks
in the network (public permissioned Blockchains) or they
limit the accounts which are allowed to interact with a
given Smart Contract architecture [7]. Often, these enti-
ties (Smart Contracts or externally owned accounts) are
white-listed after an off-chain proof; usually, teams from
different companies communicate their account informa-
tion outside of the Blockchain network. However, this
process is expensive, as for every new connection trust
has to be established. To enhance this process, proofs
can be generated with AuthSC that endorse accounts
and Smart Contracts, allowing the ”administrative” party
to automatically add new entities to the network after
sufficient proof. This not only reduces costs but allows
for novel filtering, e.g., any domain with a TLD from e.g.,
Sweden is allowed to participate in the network. Proofs
can be stored in public permissionless Blockchains (e.g.,
the Ethereum Mainnet) and used in private Blockchains,
allowing an even further adoption of SSL/TLS-certificates
within these networks.

4.2. Information attribution and authentication
in public Blockchains

The properties of immutability, transparency, and
longevity of data and information are often used as ar-
guments for Blockchain technology, as many companies
value such properties for their use cases, e.g. reduce fraud
or increase transparency towards their users. Data stored
on Blockchains with the intention of transparency, how-
ever, lack the attribution or the connection to the company,
such that a proof that data comes from a company or
institution is bothersome, as prior communication is re-
quired as evidence. For these companies, it is much easier
to authenticate this Smart Contract, store their data in it,
and let other parties validate the stored data alongside au-
thenticating the Smart Contract. To give an example, this
approach could be used for allowing online-authentication
of digital certificates, e.g. degrees or references. Hashes of
such documents are stored on the Blockchain, similar to
other Blockchain-based approaches [8]. The authenticated
Smart Contract ensures the correctness of the identity of
the issuer. Third parties (e.g., potential employers) can
compare the hashes of received documents to the hashes
contained in the Smart Contract. This software addition-
ally authenticates the Smart Contract and validates the
asserted identity. With such a solution in place, software
can automatically scan if uploaded documents by the
applicant are valid or not.

5. Discussion
In this Section, we discuss the limitations and advan-

tages of our approach to better understand the implications
when using this artifact.

5.1. Limitations

To start with, this approach only supports the authenti-
cation of domain owners with certificates, e.g., businesses



or users with own websites, but not private persons or any
other parties without such certificates. This is a caveat,
as other parties, e.g., users, are also interested in having
authenticated addresses or Smart Contracts. Sending funds
to other parties or friends should involve some form of
authentication, unfortunately, our approach is not suitable
for this. Solving the issue for regular users would also
result in reduced onboarding costs if the authenticity
of the user is required, e.g., in financial transactions or
products. However, identity providers could use AuthSC
to authenticate their contracts to later assert identities to
their users, such that they can use authenticated addresses
later on with other service providers.

The AuthSC approach relies on SSL/TLS-certificates
issued by certificate authorities. The utilization of such
certificates implies that these institutions are trustworthy
and that limitations of this hierarchical public-key infras-
tructure also apply to AuthSC regards to centralization.
However, the transparent storage of signatures of Smart
Contract addresses can lead to increased trust in the
infrastructure, as outlined in Section 7. Furthermore, as
the basis of information is the web (which is deemed to
be trustworthy), we provide similar security.

Blockchain and Smart Contract technology is a grow-
ing area of business and research, and a lot of different
solutions compete for users, companies, and funds. At the
current stage of development, it is impossible to predict
which authentication or identity solution will prevail in the
long run and even if such technologies will have relevance
in the future at all, and this also applies for AuthSC.
However, if the usage of Blockchain technology increases,
such solutions will be required or even enable such usage
increase.

The system is designed such that different entities
can reach different conclusions about the validity of on-
chain data. Consequently, users verify data off-chain, not
resulting in absolute truth on-chain. It is possible to have
different perceptions of reality. Further, an entity may not
want to engage with another entity, even if it knows its
true identity.

Our presented approach requires rewriting existing
contracts to adhere to AuthSC’s interface, potentially im-
posing barriers to companies. Furthermore, access to the
SSL/TLS-certificate is required. Every company that uses
the AuthSC-approach has to follow the setup process,
incurring costs up-front. As many businesses rely on web
hosting companies, access might not be trivial, as leakage
of the certificate must be prevented.

5.2. Advantages

Our system uses, in contrast to all other approaches
outlined in Section 6, existing signature, and certificate au-
thority schemes. This has a two-fold benefit: First, there is
a straightforward onboarding process in place, as existing
structures are used. Entities do not have to go through
additional Know-Your-Customer-processes (KYC) to au-
thenticate their Smart Contract, it is inherently existent
if they own a domain with an SSL/TLS-certificate. No
entity is the gatekeeper of this approach and any entity
worldwide can immediately use this approach, enabling
a completely open system. Second, the system itself does

not need a bootstrapping process or the persuasion of other
entities to join and create the desired network-effect.

SSL/TLS-certificates are a passive form of authenti-
cation. A user requests a website and this website re-
turns the data with the respective certificate. The web
server cannot use its certificate in communication as the
initiating party, e.g., contacting another web server and
being authenticated by the TLS/SSL certificate. With our
approach, the SSL/TLS-certificates can be used actively,
as other Sma";"""date"",""2020-04-30T01:24:35Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2020-04-30T01:24:35Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016) kpathsea version 6.2.2""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2020-04-30T01:24:35Z""
""created"",""2020-04-30T01:24:35Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-04-30T01:24:35Z""
""resourceName"",""2004.14033""
""Author"",""""
""producer"",""pdfTeX-1.40.17""
""pdf:docinfo:producer"",""pdfTeX-1.40.17""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2020-04-30T01:24:35Z""
""Last-Modified"",""2020-04-30T01:24:35Z""
""dcterms:modified"",""2020-04-30T01:24:35Z""
""title"",""""
""Last-Save-Date"",""2020-04-30T01:24:35Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2020-04-30T01:24:35Z""
""meta:save-date"",""2020-04-30T01:24:35Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016) kpathsea version 6.2.2""
""Content-Length"",""243634""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""10""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""4670"",""4653"",""3061"",""4862"",""2086"",""4966"",""5591"",""4580"",""5257"",""990""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-04-30T01:24:35Z""
";https://scholar.google.ch/scholar?start=710&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098839-276;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;[PDF][PDF] An efficient authenticated key exchange from random self-reducibility on CSIDH;T Kawashima, K Takashima, Y Aikawa, T Takagi ;2020 eprint.iacr.org;;"… a CSIDH-based AKE with small security loss, fol- lowing the construction of Cohn-Gordon et

al.in CRYPTO 2019, as an … to the proof of Proposition 7. The only difference is that we have to

simulate the decision oracles but we have only to pass the query to the original oracle …";Cité 1 fois;;[PDF] iacr.org;https://eprint.iacr.org/2020/1178.pdf;"
An Efficient Authenticated Key Exchange from
Random Self-Reducibility on CSIDH

Tomoki Kawashima1, Katsuyuki Takashima2, Yusuke Aikawa2, and Tsuyoshi
Takagi1

1 Department of Mathematical Informatics, The University of Tokyo, Tokyo, Japan
{tomoki kawashima, takagi}@mist.i.u-tokyo.ac.jp
2 Mitsubishi Electric Corporation, Kanagawa, Japan

Takashima.Katsuyuki@aj.MitsubishiElectric.co.jp,

Aikawa.Yusuke@bc.MitsubishiElectric.co.jp

Abstract. SIDH and CSIDH are key exchange protocols based on iso-
genies and conjectured to be quantum-resistant. Since the protocols are
similar to the classical Diffie–Hellman, they are vulnerable to the man-
in-the-middle attack. A key exchange which is resistant to such an attack
is called an authenticated key exchange (AKE), and many isogeny-based
AKEs have been proposed. However, the parameter sizes of the existing
schemes should be large since they all have relatively large security losses
in security proofs. This is partially because the random self-reducibility
of isogeny-based decisional problems has not been proved yet.

In this paper, we show that the computational problem and the gap
problem of CSIDH are random self-reducible. A gap problem is a com-
putational problem given access to the corresponding decision oracle.
Moreover, we propose a CSIDH-based AKE with small security loss, fol-
lowing the construction of Cohn-Gordon et al. in CRYPTO 2019, as an
application of the random self-reducibility of the gap problem of CSIDH.
Our AKE is proved to be the fastest CSIDH-based AKE when we aim
at 110-bit security level.

Keywords: post-quantum ¡ tight security ¡ authenticated key exchange
¡ isogeny-based cryptography ¡ CSIDH

1 Introduction

1.1 Backgrounds

Most of the public key cryptosystems currently used depend on the difficulty
of Discrete Logarithm Problem (DLP) or factorization, so will be broken by
Shor’s algorithm [22] with quantum computers. To prepare for the appearance
of quantum computers, quantum-resistant cryptosystems are needed. Isogeny-
based cryptosystems, such as SIDH [16] and CSIDH [5], are expected to be
quantum-resistant. CSIDH can be considered to be an instantiation of Hard
Homogeneous Spaces (HHS) proposed in [8], and its protocol is similar to the



2 T. Kawashima et al.

classical Diffie–Hellman. SIDH also has a very similar protocol to the classical
Diffie–Hellman, but we cannot regard it as an instantiation of HHS.

Since SIDH and CSIDH are subject to the man-in-the-middle attack, we can-
not use them under insecure channels. Although the classical Diffie–Hellman is
also vulnerable to the man-in-the-middle attack, there are many Diffie–Hellman-
based key exchange protocols which are secure under insecure channels, e.g.,
[18,17]. Such key exchange protocols are called authenticated key exchanges
(AKE).

As for isogeny-based cryptosystems, there are several SIDH-based AKEs
[14,19,23]. There also exist CSIDH-based AKEs [13], though [13] mainly focuses
on a group AKE. However, these existing isogeny-based AKEs are not so efficient
in that they all have large security losses. When we have a small security loss,
we can use smaller parameters to achieve a specific security level, e.g., 110-bit
security, which means the protocol becomes faster.

To achieve an AKE with a small security loss, “random self-reducibility” of
the underlying problem is useful. Informally, we say that a problem is random
self-reducible when we can produce multiple independent instances from a single
instance such that we can restore the original answer from the answer of any one
of the generated instances. In other words, a problem is random self-reducible if
we can reduce the problem tightly to the corresponding multi-instance problem.
It is well-known that the decisional Diffie–Hellman (DDH) problem and the
computational Diffie–Hellman (CDH) problem are random self-reducible, see
the left part of the Figure 1.

Since the security of an AKE is often defined in the decisional game, it is plau-
sible to use a decisional problem for the security proof. However, even though
the (classical) DDH problem is random self-reducible, the decisional problem
of SIDH and that of CSIDH (denoted as SI-DDH and CSI-DDH respectively)
have not been proved so, see the middle and right part of the Figure 1. Thus it
seems difficult to construct an AKE with a small security loss from the decisional
isogeny-based problems. Here, the next candidates are isogeny-based computa-
tional problems. However, the security proof of an AKE from a computational
problem is often difficult, since we have to reduce the computational problem to
the decisional game. Thus, other kinds of problems are needed to construct an
AKE with a small security loss.

For that reason, we use gap problems introduced by Okamoto and Pointcheval
[21]. A gap problem is a problem to solve a computational problem given access
to the corresponding decisional oracle, and often used in the security proof of
an AKE [18,13]. Though not quantum-resistant, the gap problem of the classical
Diffie–Hellman (the GDH problem in short) is also random self-reducible, see
the left part of the Figure 1. As for SIDH, no gap problem which is suitable for
cryptosystems has been found. Related discussions are in [15,10]. So we put our
hope on the gap problem of CSIDH, CSI-GDH problem.

Following the discussion above, a natural question which arises is:

Can we construct a (almost) tightly secure quantum-resistant key exchange
which is secure against man-in-the-middle attack from isogenies?



An Efficient AKE from Random Self-Reducibility on CSIDH 3

1.2 Contributions

Random Self-Reducibility of the Gap Problem of CSIDH Our first
contribution is that we prove the random self-reducibility of the CSI-GDH prob-
lem. Though the classical Diffie–Hellman, CSIDH, and SIDH have very similar
structures, the situations about random self-reducibility are different. As for the
classical Diffie–Hellman, the decisional problem and the gap problem are both
random self-reducible (see the left part of the Figure 1). On the contrary, nei-
ther the decisional problem and the gap problem of SIDH has been proved to
be random self-reducible (see the right part of the Figure 1). Here, our contri-
bution is that we prove that the gap problem of CSIDH, CSI-GDH problem, is
random self-reducible (see the middle part of the Figure 1). So, among the clas-
sical Diffie–Hellman, SIDH, and CSIDH, CSIDH is the only quantum-resistant
cryptosystem which has random self-reducibility.

Fig. 1. The comparison of our result with existing result. We prove that the random
self-reducibility of the CSI-GDH problem. As for the gap problems of SIDH, no suitable
problems has been proposed, see the section 3.2 for more details.

Efficient CSIDH-based AKE Our second contribution is that we construct
a quantum-resistant efficient AKE based on CSIDH, following the construction
of Cohn-Gordon et al. [7]. Our AKE has a security loss of O(Âľ), where Âľ is
the number of users and Cohn-Gordon et al. showed that it is optimal among
“simple” reductions.3 So, even though the loss of O(µ) is not tight, i.e., the
security loss is not constant, it is optimally tight, and our AKE is efficient in this
sense. Moreover, since our AKE is based on CSIDH, it is quantum-resistant. As
far as we know, our AKE has the smallest security loss among isogeny-based
AKEs as shown in Table 1.

We also compare our AKE with other existing CSIDH-based AKEs. As far
as we know, [13] is the only study that proposes other CSIDH-based AKEs. [13]

3 Informally, a reduction is simple if the reduction runs the adversary only once.



4 T. Kawashima et al.

proposes two CSIDH-based AKEs and we show that our AKE is faster than
these two AKEs if we aim at 110-bit security.

Table 1. AKEs proposed in the literature. “Assumption” shows which problem is
assumed to be hard and “Model” represents which AKE security model was used. The
number of hash queries and RevealSessKey are denoted as h and q. Also, l and ns denote
the maximum number of sessions per user and the number of sessions activated by the
adversary.

Protocol Assumption Model Loss

the classical Diffie–Hellman-based

HMQV [17] CDH CK Âľ2l2

NAXOS [18] GDH strong AKE Âľ2l2

Protocol Π [7] stDH CCGJJ ¾

SIDH-based

SIDH UM [12] SI-DDH CK Âľl
SIDH-AKE [14] SI-CDH CK Âľ2l2

SIGMA-SIDH [19] SI-DDH SK Âľns

SIAKE2 [23] SI-DDH CK+ Âľ2lq
SIAKE3 [23] 1-OSIDH CK+ Âľ2lq

CSIDH-based

CSIDH UM [13] 2DDH G-CK Âľns(h+ q)2

CSIDH Biclique [13] 2GDH G-CK+ max(Âľ2, n2
s)

Proposed Protocol CSI-stDH CCGJJ Âľ

1.3 Key Techniques

Relationship between AKE and Random Self-Reducibility The security
of an AKE is defined with the following game between a challenger C and an
adversary A. First, C gives public information of the AKE to A, such as public
keys of users and public parameters. Second, A carries out some attacks allowed
in the security model. Finally, A chooses some sessions to get each person’s
shared keys or random keys. Such sessions are called test sessions. Here, a session
is a single execution of the protocol. If A cannot decide whether the given keys
are real-or-random with noticeable advantage, we say the AKE is secure. For
further details, see Appendix A.

When we want to prove the security of an AKE from the difficulty of a
problem, we construct a simulator of the game above. Given an instance of
the problem, the simulator embeds the instance to the AKE. For example, the
simulator sets a user’s public key to the instance. The simulator embeds the
problem deliberately so that if the adversary wins the game, then the simulator
can answer the problem with high probability. In this case, the security loss is



An Efficient AKE from Random Self-Reducibility on CSIDH 5

often equal to the reciprocal of the probability of the event that the adversary
chooses one of the embedded sessions as a test session.

To lower the security loss, embedding the instance of the underlying problem
to multiple sessions is helpful. This is because the probability that A “hits” the
embedded sessions becomes higher and the security loss becomes smaller. In this
case, the simulator has to embed instances so that the simulator can solve the
underlying problem if the adversary hits the embedded sessions. However, while
embedding the instance to AKE-settings, the simulator has to set the embedded
keys independently. So, the simulator must generate multiple keys independently
while the embedded keys are related to the original (single) instance.

Though it sounds difficult, we can do it easily if the underlying problem
is random self-reducible. In the proof of the random self-reducibility, we make
multiple and independent instances from one instance, which is analogous to the
proof technique in AKE above.

Difference between the Classical Diffie–Hellman and Isogeny-Based
Cryptosystems As for the classical Diffie–Hellman, the DDH problem and the
CDH problem are both random self-reducible. The random self-reducibility of
the GDH problem follows from that of the CDH problem.

Here, we describe the proof technique. Let G be a cyclic group of prime order
p. Given (X = gx, Y = gy, Z = gz), the DDH problem is to decide whether Z =
gxy, where g is a generator of G. In the proof of the random self-reducibility of the
DDH problem, we take random elements ui, vi, wi ∈ Z/pZ and generate random
instances (Xi, Yi, Zi) = (Xwigui , Y gvi , ZwiXviwiY uiguivi) for i = 1, 2, ¡ ¡ ¡ . Note
that in this rerandomization, we use the operations in Z/pZ and G. In other
words, we use the operations in the set of secret keys and the set of public keys.
On the contrary, in CDH case, we only use the operation in Z/pZ, the set of
secret keys as discussed in Section 3.1.

As for SIDH, the key exchange is modeled as a random walk in isogeny
graphs. Thus, we have poor algebraic structure. For example, the set of secret
keys and public keys are the set of torsion points and the set of isomorphism
classes of supersingular elliptic curves, respectively. So, we cannot transfer the
proof of the classical Diffie–Hellman case to SIDH. This is the main reason why
the random self-reducibilities of SIDH-related problems have not been proved
yet.

In contrast, as for CSIDH, we have algebraic structure, i.e., we use the action
of the ideal class group Cℓ(Z[

√
−p]) on the set of isomorphic classes of supersin-

gular elliptic curves Eℓℓp(Z[
√
−p]), where p is a prime such that p ≡ 3 mod 4.

Since we still have no operations in Eℓℓp(Z[
√
−p]), we cannot transfer the proof

of DDH case to CSIDH. However, in CSIDH, the set of secret keys is Cℓ(Z[
√
−p]),

the ideal class “group” of an order Z[
√
−p]. So, we have an operation in the set

of secret keys and it is homomorphic to the action. This operation enables us to
transfer the proof of the CDH-case to CSIDH, which is our main contribution.



6 T. Kawashima et al.

Related Works In an independent work, de Kock et al. [9] proposed exactly
the same optimally-tight CSI-GDH based (thus post-quantum) AKE, while the
main focus of their study is not the random self-reducibility itself.

Moreover, Brendel et al. [2] introduced an interesting notion of split KEM,
and they suggest that the CSI-GDH problem seems to be helpful to construct a
post-quantum split KEM.

2 Hard Homogeneous Spaces and CSIDH

Commutative Supersingular Isogeny-based Diffie–Hellman, CSIDH, is one of the
candidates for post-quantum cryptosystems, proposed by Castryck et al. in 2018
[5]. CSIDH realizes Hard Homogeneous Space (HHS), formulated by Couveignes
[8], using elliptic curves and isogenies. We briefly introduce CSIDH here. More
detailed description of CSIDH is in Appendix B.

2.1 Hard Homogeneous Space

First, we give an informal definition of HHS. See [8] for more details.

Definition 1 (Homogeneous Space). Let G be a finite abelian group and
X be a finite set. (G, X) is called homogeneous space if G acts on X simply
transitively, i.e., for every x ∈ X, a map G → X such that g 7→ gx is bijective.

Here, we consider two problems in a homogeneous space. The first one is
the vectorization, which is to invert the group action, i.e., given x1, x2 ∈ X,
find g ∈ G such that x2 = gx1. The second one is the parallelization, which is,
given x1, x2, x3, compute gx3, where g ∈ G is the unique element in G which
enjoys x2 = gx1. We say (G, X) is a hard homogeneous space (HHS) if these two
problems are hard.

2.2 CSIDH

Let p be a large prime such that p ≡ 3 mod 4. It is a well known fact that
Cℓ(Z[

√
−p]), the ideal class group of an order Z[

√
−p] acts simply transitively

on Eℓℓ(Z[
√
−p]), the set of Fp-isomorphic classes of supersingular elliptic curves

whose Fp-endomorphism ring is isomorphic to Z[
√
−p]. It is believed that this

action is hard to invert even for quantum computers, and thus we can regard
(Cℓ(Z[

√
−p]), Eℓℓp(Z[

√
−p])) as a quantum-resistant HHS.

Remark 2. A recent study [4] proposes a protocol similar to CSIDH and slightly
faster than CSIDH. This protocol is called CSURF, CSIDH on the surface. Since
CSURF is also an instantiation of HHS, our result is also applicable to CSURF.



An Efficient AKE from Random Self-Reducibility on CSIDH 7

2.3 Key Exchanges based on HHS

We can construct a Diffie–Hellman type key exchange protocol from HHS as
shown in [8]. For a HHS (G, X), the key exchange between Alice and Bob pro-
ceeds as follows:

1. Alice and Bob share a public parameter x0 ∈ X beforehand.
2. Alice chooses a random element a ∈ G and sends ax0 to Bob as a public key.

Bob sends bx0 to Alice in the same way.
3. On receiving Bob’s public key bx0, Alice computes KA = a(bx0) = abx0.

Bob computes KB = b(ax0) = bax0 in the same way.

It is easy to see that KA = KB because G is an abelian group. CSIDH is a
Diffie–Hellman-like key exchange of this form. As mentioned above, CSIDH is
conjectured to be a quantum-resistant key exchange protocol. For more details,
see appendix B and [5].

Note that this kind of key exchange is vulnerable to the man-in-the-middle
attack. Let Charlie be an attacker who conducts the man-in-the-middle attack.
Charlie intercepts Bob’s message bx0 and sends C = cx0 to Alice instead, where
c ∈ G is chosen by Charlie. Then, receiving altered message C, Alice computes
her shared key aC = (ac)x0. Here, Charlie can compute this key with cA =
(ca)x0. So, we cannot use this kind of key exchange in insecure channels.

3 Random Self-Reducibility of Isogeny-Based Problems

In this section, we discuss the random self-reducibility of isogeny-based problems.
First, we review the classical Diffie–Hellman-based problems in section 3.1 to see
what kinds of techniques are used to prove the random self-reducibility. Then,
we move on to isogeny-based problems such as SIDH-based ones (section 3.2)
and CSIDH-based ones (section 3.3). Our main contribution, the random self-
reducibility of the gap problem of CSIDH, is in section 3.3.

We first define the random self-reducibility:

Definition 3 (Random Self-Reducibility). Let f be a function f : X → Y .
For a problem P , which is to evaluate f(x) for randomly chosen x ∈ X, we
say P is k-random self-reducible when we can generate x1, . . . , xk in polynomial
time such that (1) x1, . . . , xk independently follow the same distribution which x
follows and (2) given any one of (1, f(x1)), . . . , (k, f(xk)), we can compute f(x)
efficiently with high probability. Moreover, if the solver of P whose instance is
x′ is given the access to the oracle Ox′ , then P is k-random self-reducible if we
can simulate Oy perfectly for all generated instances y with or without the help
of Ox.

If the problem P is k-random self-reducible for arbitrary positive integer k,
we say P is random self-reducible.

3.1 The Classical Diffie–Hellman-Related Problems

Firstly, we will review Diffie–Hellman based problems in this subsection.



8 T. Kawashima et al.

Decisional Problems of the Classical Diffie–Hellman Now, we will de-
scribe the random self-reducibility of the DDH problem. We start with the def-
inition of the DDH problem.

Problem 4 (Decisional Diffie–Hellman (DDH) Problem). Let p be a large prime,
G be a cyclic group of prime order p, and g be a generator of G. Furthermore, a
random bit b ∈ { 0, 1 } is taken uniformly. For uniformly sampled x, y, z ∈ Z/pZ,
(X,Y, Z) = (gx, gy, gxy) if b = 1 and (X,Y, Z) = (gx, gy, gz) otherwise. Here,
the problem is to guess b, given p,G, g, (X,Y, Z).

Here, for an adversary A whose guess is b′, the advantage is defined as

AdvADDH(Îť) =

∣∣∣∣∣Pr[b′ = b]−
1

2

∣∣∣∣∣.
Note that even when b = 0, Z happens to be equal to gxy. However, since

this event happens only with negligible probability, we can ignore such a case to
avoid pathologies. In other words, we assume that Z = gxy if and only if b = 1
throughout this paper.

It is a well-known fact that the DDH problem is random self-reducible.

Proposition 5. The DDH problem is random self-reducible.

Proof. For an instance (X,Y, Z) of the DDH problem, we generate independent
exponents ui, vi, wi ∈ Z/pZ for all i = 1, 2, . . . . Then, we generate instances of
the DDH problem as

(Xi, Yi, Zi) = (Xwigui , Y gvi , ZwiXviwiY uiguivi). (1)

Finally, given j-th answer (j, bj), we answer bj to the original problem.
Here, we check that (Xi, Yi, Zi) are distributed uniformity and independently,

and that b = bj , where b denotes the correct answer of the original problem. Let
(X,Y, Z) = (gx, gy, gz) and (Xi, Yi, Zi) = (gxi , gyi , gzi). Then, we have xi =
wix+ui, yi = y+vi, zi = xiyi+wi(z−xy). Since ui and vi are independent and
uniform, we can easily check that Xi and Yi are uniform and independent. When
b = 1, z = xy, thus zj = xjyj , which means that bj = 1. Otherwise, z − xy 6= 0,
so uj , vj , wj(z − xy) distribute independently and uniformly. 4 Then, Xj , Yj , Zj

are uniform and independent, so bj = 0. ut

Note that we use two actions of Z/pZ on G in this proof. One is the “additive
action”, which maps (x, h) ∈ Z/pZ×G to h·gx. This action is additive in that we
regard Z/pZ as an additive group. The other is the “multiplicative action”, which
maps (x, h) ∈ Z/pZ × G to hx. We regard (Z/pZ)× as a multiplicative group
in this case. Both actions are necessary to maintain independency of generated
instances. Here, we remark that the additive action cannot be used to construct
HHS because we can compute h ¡ gx+y from g, h, h ¡ gx, h ¡ gy easily, which means
that the parallelization is easy. However, the multiplicative action is considered
to form HHS, and the classical Diffie–Hellman utilizes this action to achieve a
secure key exchange.

4 As mentioned above, we assume that z = xy if and only if b = 1 to avoid pathology.



An Efficient AKE from Random Self-Reducibility on CSIDH 9

Computational Problems of the Classical Diffie–Hellman Here, we dis-
cuss the random self-reducibility of the CDH problem. As above, we start with
the definition of problem.

Problem 6 (Computational Diffie–Hellman (CDH) Problem). Let p be a large
prime, G be a cyclic group of prime order, and g be a generator of G. For
uniformly sampled x, y ∈ Z/pZ, the CDH problem is to compute gxy given p, g,
and (gx, gy).

Here, for an adversary A whose output is Z, the advantage is defined as
AdvACDH(Îť) = Pr[Z = gxy].

Note that we can prove the random self-reducibility of the CDH problem in
the same way as the DDH problem.

Proposition 7. The CDH problem is random self-reducible.

Proof. Given a CDH instance (X,Y ) = (gx, gy), we generate instances of the
CDH problem (Xi, Yi) = (Xui , Y vi), where ui and vi are chosen independently

and uniformly. Then, given j-th answer Zj , we answer Z
(vjuj)

−1

j to the original
problem. Here, independency and uniformness are checked in a similar way to
Proposition 5. As for correctness, let (Xi, Yi) = (gxi , gyi). Then we have xiyi =

xuiyvi, so Z
(vjuj)

−1

j = (gxujyvj )(vjuj)
−1

= gxy. ut

On the contrary to the DDH-case, we use only multiplicative action in this
proof. This difference enables us to prove the random self-reducibility of the
computational problem of CSIDH as discussed later in 3.3.

Gap Problems of the Classical Diffie–Hellman Now, we see the GDH
problem, the gap Diffie–Hellman problem. The GDH problem is defined as fol-
lows:

Problem 8 (Gap Diffie–Hellman (GDH) problem). Notation as in Problem 6.
The GDH problem is to compute gxy, given access to the decision oracle DDH,
which solves the DDH problem, i.e., DDH(ga, gb, gc) = true if and only if c = ab.

Here, for an adversary A whose output is Z, the advantage is defined as
AdvAGDH(Îť) = Pr[Z = gxy].

Note that if the DDH problem is solved, we have to consider the CDH problem
as the GDH problem. In other words, the GDH problem is the CDH problem
where the DDH problem is solved. Note that the GDH problem is also random
self-reducible. The proof is almost identical to the proof of Proposition 7. The
only difference is that we have to simulate the decision oracles but we have only
to pass the query to the original oracle.



10 T. Kawashima et al.

3.2 SIDH-Related Problems

Secondly, we discuss the problems related to SIDH, Supersingular Isogeny Diffie–
Hellman. SIDH is one of the most major isogeny-based cryptosystems proposed
in [16], so we cannot ignore SIDH if we try to construct an isogeny-based AKE.
However, our conclusion is that it is difficult to construct a SIDH-based AKE
with small security loss since there is no suitable problem assumed to be hard.

Decisional and Computational Problems of SIDH SIDH is a key exchange
protocol which can be modeled as random walks on the isogeny graphs. Thus,
SIDH has a very pour algebraic structure. See [16] for the detailed protocol.
Note that neither the decisional nor the computational problem of SIDH has
been proved to be random self-reducible. Poor algebraic structure is one of the
reason for this. Thus we cannot transfer the proof of the classical Diffie–Hellman
case naively.

Since SIDH is subject to the man-in-the-middle attack, a lof of SIDH-based
AKEs have been proposed [12,19,23]. Most of them are based on the difficulty
of decisional problems, and have relatively large security loss, which indicates
that the decisional problem of SIDH is not random self-reducible. To the best of
our knowledge, no AKE based on the computational problem of SIDH has been
proposed.

As a summary, it seems difficult to construct an AKE with small security
loss from the decisional or the computational problem of SIDH.

Gap Problems of SIDH Gap problems are very helpful to prove the security
of AKE in the random oracle model, because we can capture the hash query of an
adversary and check if the query contains the correct answer of the problem with
the decision oracle. However, as for SIDH, it is hopeless at present as discussed
below.

As pointed out in [14], gap assumptions related to SIDH sometimes do not
hold, that is, there are cases that we can solve the gap problems efficiently, see
[15]. So, it is risky to use a gap type problem for a security proof of SIDH-
based schemes. As a result, the security of almost all existing SIDH-based AKE
schemes [14,19,23] are proved without using gap problems contrary to the utility
of gap problems in security proofs for the classical Diffie–Hellman setting. This
is one of the biggest obstruction to construct SIDH-based AKE schemes.

On the other hand, there is an attempt to overcome this obstruction. The
gap problem which proved to be easy has a restriction on the degree of isogenies,
which is essential condition for Galbraith-Vercauteren attack [15] work. So, in
order to avoid this attack, removing the condition on the degree of isogenies,
Fujioka et al. propose a new gap problem, the degree-insensitive SI-GDH prob-
lem, see [12] §4. They use such a gap problem in the security proof of their AKE
protocol. However, in [10], it is conjectured with an evidence that public keys in
the degree-insensitive version are uniformly distributed. This conjecture shows
that the degree-insensitive SI-GDH problem no longer makes sense. Here, we



An Efficient AKE from Random Self-Reducibility on CSIDH 11

note that this does not mean that the AKE scheme in [12] is broken and only
that its security is not supported by the computational assumption used in [12],
for more detail, see [10].

Summary As discussed above, since the mechanism of SIDH is modeled as
random walks in the isogeny graph, formulating a well-defined gap problem in
SIDH setting is difficult. So, in order to construct AKE from SIDH, we have
to employ decisional problems. However, the random self-reducibility of SIDH-
related decisional problems has not been proved yet. In conclusion, constructing
tightly secure AKE schemes in SIDH setting is seems to be difficult currently.

3.3 CSIDH-Related Problems

Finally, we move on to CSIDH. Though the decisional problem of CSIDH is still
likely not to be random self-reducible, we show that the computational and the
gap problems are random self-reducible.

Decisional Problem of CSIDH The decisional problem of CSIDH, CSI-DDH
problem, seems not to be random self-reducible. In this subsection, we will com-
pare the CSI-DDH problem with the DDH problem and discuss what prevents
the random self-reducibility of the CSI-DDH problem.

First, we define the CSI-DDH problem.

Problem 9 (Commutative Supersingular Isogeny Decisional Diffie–Hellman (CSI-
DDH) Problem). Let p be a large prime such that p ≡ 3 mod 4 and E be a super-
singular elliptic curve in Eℓℓ(Z[

√
−p]). Then, given (E1, E2, E

′) = ([x]E, [y]E,E′)
for uniformly chosen [x], [y] ∈ Cl(Z[

√
−p]), guess whether E′ ' [xy]E or not.

Here, for an adversary A, the advantage is defined as AdvACSI-DDH(λ) =∣∣∣∣∣Pr[guess is correct]− 1

2

∣∣∣∣∣.
One may imagine that the CSI-DDH problem is also random self-reducible

since CSIDH and the classical Diffie–Hellman have very similar structures. How-
ever, to the best of our knowledge, we have not succeeded in proving so. For
example, a recent study [11] leaves it as an open problem.

Here, we discuss the difference between the classical Diffie–Hellman and
CSIDH, i.e., why we cannot prove the random self-reducibility of the CSI-DDH
problem in the same way for the DDH problem. As for the classical Diffie–
Hellman case, we use both additive action and multiplicative action to prove the
random self-reducibility of the decisional problem. In CSIDH case, we have only
one action, so it seems difficult to transfer the proof to the CSIDH settings. How-
ever, this lack of operation is inevitable to achieve quantum-resistance because
of Shor’s algorithm [22].



12 T. Kawashima et al.

Remark 10. A recent study of the DDH assumption [6] shows that we can solve
the DDH problem of HHS from ideal-class group action under certain circum-
stances. That is, if p ≡ 1 mod 4, we can solve the CSI-DDH problem efficiently.
This is not the case here because we restrict p ≡ 3 mod 4 and in this case we
cannot use this result directly. However, some modification may be required in
the future even when p ≡ 3 mod 4.

Computational Problems of CSIDH Now, we will show that the computa-
tional problem of CSIDH is random self-reducible.

First, we define the CSI-CDH problem. It is defined in an analogous way to
the classical Diffie–Hellman.

Problem 11 (Commutative Supersingular Isogeny-Computational Diffie-Hellman
(CSI-CDH) Problem). Let p be a large prime such that p ≡ 3 mod 4 and E be a
supersingular elliptic curve in Eℓℓ(Z[

√
−p]). Then, given (E1, E2) = ([x]E, [y]E)

for uniformly chosen [x], [y] ∈ Cl(Z[
√
−p]), compute [xy]E.

Here, for an adversary A whose output is E′, the advantage is defined as
AdvACSI-CDH(λ) = Pr[E′ = [xy]E].

Here, we probe the random self-reducibility of the CSI-CDH problem.

Theorem 12. The CSI-CDH problem is random self-reducible.

Proof. For an instance (EA, EB) of the CSI-CDH problem, we generate random
ideal classes [ρi], [ηi] ∈ Cℓ(O). Then, we generate instances as ([ρi]EA, [ηi]EB).
Then, given (j, Ej) for some j, we answer [Ρj ]

−1[ρj ]
−1Ej to the original problem.

Since the action is simply transitive, the independency and uniformity of these
generated elliptic curves are assured. Here, since Ej = [ρi][Ρi]E, [Ρj ]

−1[ρj ]
−1Ej =

[xy]E, we complete the proof. ut

In this proof, we use almost the same technique as in Theorem 7, the CDH
case, while it is impossible in the decisional case. This is mainly because the proof
of the random self-reducibility of the CDH problem uses only one operation,
whereas we use two operations in the decisional case. In the CDH problem case,
as discussed above, we use only the multiplicative action to prove the random
self-reducibility. Since only the multiplicative action forms HHS in the classical
DH case, the action in CSIDH corresponds to the multiplicative action of the
classical DH, so it is plausible that we can transfer the proof to CSIDH settings
in this case.

Gap Problems of CSIDH As a corollary of Theorem 12, we can prove that
the gap problem of CSIDH, CSI-GDH problem, is also random self-reducible.
We start with the definition of the problem:

Problem 13 (Commutative Supersingular Isogeny Gap Diffie–Hellman problem
(CSI-GDH problem)). Notation as in Problem 11. The CSI-GDH problem is to
compute [xy]E, given access to the decision oracle CSI-DDH, which solves the



An Efficient AKE from Random Self-Reducibility on CSIDH 13

corresponding CSI-DDH problem, i.e., given ([a]E, [b]E,E′), CSI-DDH returns
true if and only if E′ = [ab]E.

Here, for an adversary A whose output is E′, the advantage is defined as
AdvACSI-GDH(λ) = Pr[E′ = [xy]E].

Here, we can prove that the CSI-GDH problem is also random self-reducible:

Corollary 14. The CSI-GDH problem is random self-reducible.

Proof. The only difference from the CSI-CDH case (Proposition 7) is that there
exists a decision oracle, but we don’t need special treatment since we have only
to pass every query to the original oracle. ut

Moreover, we will consider the CSI-stDH problem, which is a CSIDH-version
of strong DH problem used in [7]. This problem is also random self-reducible, and
we will construct an AKE which is secure under the difficulty of this problem in
the following section. The proof of the random self-reducibility of the CSI-stDH
problem is in Appendix C.

Problem 15 (strong Diffie–Hellman (stDH) Problem). Notation as in Problem";"""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""1"",""0"",""13"",""2"",""0"",""11"",""2"",""2"",""0"",""0"",""2"",""0"",""0"",""0"",""1"",""8"",""0"",""2"",""5"",""3"",""3""
""pdf:PDFVersion"",""1.5""
""xmp:CreatorTool"","" TeX output 2020.11.14:1051""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dcterms:created"",""2020-11-14T01:51:43Z""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"","" TeX output 2020.11.14:1051""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""Content-Length"",""547947""
""pdf:hasMarkedContent"",""false""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""meta:creation-date"",""2020-11-14T01:51:43Z""
""created"",""2020-11-14T01:51:43Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""26""
""Creation-Date"",""2020-11-14T01:51:43Z""
""resourceName"",""1178.pdf""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""1911"",""2749"",""1725"",""1678"",""2589"",""1834"",""2217"",""2245"",""1863"",""2515"",""2098"",""2223"",""2155"",""1709"",""2200"",""2561"",""1989"",""2678"",""2320"",""2371"",""1708"",""1741"",""1774"",""1509"",""2177"",""2288""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""producer"",""dvipdfmx (20190225)""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""dvipdfmx (20190225)""
""pdf:docinfo:created"",""2020-11-14T01:51:43Z""
";https://scholar.google.ch/scholar?start=820&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098734-39;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Decentralized cloud manufacturing-as-a-service (CMaaS) platform architecture with configurable digital assets;M Hasan, B Starly ; Journal of Manufacturing Systems, 2020  Elsevier;;"… A layered middleware architecture stack through web browsers and blockchain systems. • …

In the second middleware, clients can track the data provenance generated in a blockchain

based decentralized architecture across a manufacturing system …";Cité 9 fois;Les 3 versions;null;;;;https://scholar.google.ch/scholar?start=580&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098848-296;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Addressing new challenges in public-key cryptography;Z Yu ;2020 theses.lib.polyu.edu.hk;;"… In this way, we identify a safe mode to use public-key cryptographic schemes in a

blockchain-based cryptocurrency. • We present the first lattice-based universal accumulator secure

against … the 39th Annual International Cryptology Conference (CRYPTO 2019) …";Les 2 versions;Version HTML;[PDF] polyu.edu.hk;https://theses.lib.polyu.edu.hk/bitstream/200/10435/1/991022379157803411.pdf;"
 

 

 
Copyright Undertaking 

 

This thesis is protected by copyright, with all rights reserved.  

By reading and using the thesis, the reader understands and agrees to the following terms: 

1. The reader will abide by the rules and legal ordinances governing copyright regarding the 
use of the thesis. 

2. The reader will use the thesis for the purpose of research or private study only and not for 
distribution or further reproduction or any other purpose. 

3. The reader agrees to indemnify and hold the University harmless from and against any loss, 
damage, cost, liability or expenses arising from copyright infringement or unauthorized 
usage. 

 

 

IMPORTANT 

If you have reasons to believe that any materials in this thesis are deemed not suitable to be 
distributed in this form, or a copyright owner having difficulty with the material being included in 
our database, please contact lbsys@polyu.edu.hk providing details.  The Library will look into 
your claim and consider taking remedial action upon receipt of the written requests. 

 

 

 

 

 

Pao Yue-kong Library, The Hong Kong Polytechnic University, Hung Hom, Kowloon, Hong Kong 

http://www.lib.polyu.edu.hk 



ADDRESSING NEW
CHALLENGES IN PUBLIC-KEY

CRYPTOGRAPHY

ZUOXIA YU

PhD

The Hong Kong Polytechnic University

2020



The Hong Kong Polytechnic University

Department of Computing

Addressing New Challenges in
Public-Key Cryptography

Zuoxia Yu

A thesis submitted in partial fulfillment of the

requirements for the degree of Doctor of Philosophy

September 2019



ii

CERTIFICATE OF ORIGINALITY

I hereby declare that this thesis is my own work and that,

to the best of my knowledge and belief, it reproduces no mate-

rial previously published or written, nor material that has been

accepted for the award of any other degree or diploma, except

where due acknowledgement has been made in the text.

Signed:

Name: Zuoxia Yu



iii

Abstract
Public-key cryptography, introduced by Diffie and Hellman in 1976, has
found numerous applications in reality. After years of development, public-
key cryptography has been well-studied and is gradually becoming mature.
However, the emerging of several exciting technologies in computer sci-
ence, while bringing convenience to our daily life, also imposes new chal-
lenges to current public-key cryptographic systems deployed in practical
applications. In this thesis, we focus on addressing some new challenges in
two well-known representatives of public-key cryptography, namely, public-
key encryption and digital signature. In particular, we aim at designing
an encryption scheme suitable for flexible and efficient data-sharing in the
cloud as well as enhancing its resilience against side-channel attacks. In
addition, we investigate the real-world applicability of signature scheme
in blockchain-based cryptocurrencies and explore how to strengthen the
signature component of blockchain-based cryptocurrencies to be quantum
safe.

More precisely, we present the following results:

• We present a new variant of public-key encryption named as cross-
system proxy re-encryption, which could make data-sharing in the
cloud flexible and efficient. It allows one to transform ciphertext of a
large class of attribute-based encryption schemes (a variant of public-
key encryption that supports fine-grained control over the decryption
ability) into ciphertext of any public-key encryption scheme.

• We present a general framework for constructing attribute-based en-
cryption schemes secure against side-channel attacks.

• We present the best possible statistical attack for tracing payers’ iden-
tity in transactions of privacy-preserving blockchain-based cryptocur-
rencies based on ring signature. We also find that if some natural con-
ditions are satisfied, our attack will not compromise security of the
cryptocurrency. In this way, we identify a safe mode to use public-key
cryptographic schemes in a blockchain-based cryptocurrency.

• We present the first lattice-based universal accumulator secure against
quantum attacks. This primitive can be used to construct quantum
safe dynamic group signature, a widely-used variant of digital signa-
ture that can be used to protect signers’ identity.





v

Publications
Conference Paper

1. Rupeng Yang, Man Ho Au, Junzuo Lai, Qiuliang Xu, and Zuoxia Yu. Col-
lusion Resistant Watermarking Schemes for Cryptographic Functionali-
ties. In Proceedings of the 25th Annual International Conference on the
Theory and Application of Cryptology and Information Security (Asi-
acrypt 2019), pages 371–398. Springer (2019).

2. Rupeng Yang, Man Ho Au, Zhenfei Zhang, Qiuliang Xu, Zuoxia Yu,
William Whyte: Efficient Lattice-Based Zero-Knowledge Arguments with
Standard Soundness: Construction and Applications. In Proceedings of
the 39th Annual International Cryptology Conference (CRYPTO 2019),
pages147-175. Springer (2019).

3. Zuoxia Yu, Man Ho Au, Jiangshan Yu, Rupeng Yang, Qiuliang Xu, and
Wang Fat Lau. New Empirical Traceability Analysis of Cryptonote-style
Blockchains. In Proceedings of the Financial Cryptography and Data Se-
curity 2019 (FC 2019), pages 133–149. Springer (2019).

4. Zuoxia Yu, Man Ho Au, Rupeng Yang, Junzuo Lai, Qiuliang Xu: Lattice-
Based Universal Accumulator with Nonmembership Arguments. In Pro-
ceedings of the 23rd Australasian Conference on Information Security
and Privacy (ACISP 2018), pages 502–519. Springer (2018).

5. Rupeng Yang, Man Ho Au, Qiuliang Xu, Zuoxia Yu: Decentralized Black-
listable Anonymous Credentials with Reputation. In Proceedings of the
23rd Australasian Conference on Information Security and Privacy (ACISP
2018), pages 720–738. Springer (2018).

6. Zuoxia Yu, Man Ho Au, Rupeng Yang, Junzuo Lai, Qiuliang Xu: Achiev-
ing Flexibility for ABE with Outsourcing via Proxy Re-Encryption. In
Proceedings of the 2018 on Asia Conference on Computer and Commu-
nications Security (ASIACCS 2018), pages 659–672. ACM (2018).

7. Rupeng Yang, Man Ho Au, Junzuo Lai, Qiuliang Xu, Zuoxia Yu: Un-
forgeable Watermarking Schemes with Public Extraction. In Proceedings
of the 11th International Conference on Security and Cryptography for
Networks (SCN 2018), pages 63–80. Springer (2018).



vi

8. Zuoxia Yu, Man Ho Au, Qiuliang Xu, Rupeng Yang, Jinguang Han: Leakage-
Resilient Functional Encryption via Pair Encodings. In Proceedings of
the 21st Australasian Conference on Information Security and Privacy
(ACISP 2016), pages 443–460. Springer (2016).

Journal Paper

1. Rupeng Yang, Man Ho Au, Qiuliang Xu, Zuoxia Yu: Decentralized Black-
listable Anonymous Credentials with Reputation. Computers & Security
85: 353-371. Elsevier (2019).

2. Zuoxia Yu, Man Ho Au, Qiuliang Xu, Rupeng Yang, Jinguang Han: To-
wards Leakage-Resilient Fine-Grained Access Control in Fog Comput-
ing. Future Generation Computer Systems, 78:763–777. Elsevier (2018).

3. Rupeng Yang, Qiuliang Xu, Man Ho Au, Zuoxia Yu, Hao Wang, Lu
Zhou: Position Based Cryptography with Location Privacy: A Step for
Fog Computing. Future Generation Computer Systems, 78:799–806. El-
sevier (2018).

Book Chapter

1. Zuoxia Yu, Man Ho Au, Rupeng Yang: Accountable Anonymous Cre-
dentials. Advances in Cyber Security: Principles, Techniques, and Appli-
cations, pages 49-68. Springer (2019).



vii

Acknowledgements
Studying at the Hong Kong Polytechnic University is such a valuable and
unforgettable experience.

First and foremost, I would like to thank my supervisor, Prof. Man Ho Au,
for teaching me how to do research. I appreciate the countless discussions,
helpful instructions as well as priceless suggestions, which help me on the
right track of research. I have always admired his attitude and determina-
tion in discovering and solving problems, and have always tried to learnt
from his ability of accurately abstracting the way of understanding the re-
sults. I am grateful for the freedom he gave me to explore my own research
interests, and the opportunities he offered to participate at numerous con-
ference, winter schools and research seminars. Besides research, his views
on life really taught me a lot.

I would like to express my sincere thanks to the cryptography group at
the Hong Kong Polytechnic University, including postgraduate students,
Xingye Lu, Kang Li, Xiao Yang, Borui Gong, together with all previous and
current post-docs, research assistants and project engineers. It is a plea-
sure to work with all of them, and thank them for making my work joyful,
let alone those happy gatherings. I also thank my kind office mates, Jiaxin
Chen and Kang Li, for those unexpected happiness in our daily life.

I wish to take this opportunity to express my heartful thanks to my master
supervisor, Prof. Qiuliang Xu, who takes me to the field of cryptography.
The results of this thesis emerged from the joint works with Prof. Man Ho
Au, Prof. Qiuliang Xu, Prof. Junzuo Lai, Dr. Jiangshan Yu, Dr. Rupeng
Yang, Wang Fat Lau and Dr. Jinguang Han. I thank them for all the won-
derful discussions and for all of their kind help.

I would like to give the sincerest appreciation and gratitude to my dearest
parents for their endless love, support, encouragement, and for everything.
Without them, I would not be where I am today.

Last, but certainly not least, to my husband, Rupeng, thanks for always
being there.





ix

Table of Contents

Abstract iii

Publications v

Acknowledgements vii

1 Introduction 1
1.1 Flexible ABE With Outsourcing . . . . . . . . . . . . . . . . . . 5
1.2 Leakage-Resilient Attribute-Based Encryption . . . . . . . . . 6
1.3 Applicability of Cryptographic Primitives in Blockchain . . . 6
1.4 Quantum Safe Universal Accumulator . . . . . . . . . . . . . . 7
1.5 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.6 Sources and Organization of The Thesis . . . . . . . . . . . . . 14

2 Preliminaries 15
2.1 Notations and Cryptographic Assumptions . . . . . . . . . . . 15

2.1.1 Notations and Conventions . . . . . . . . . . . . . . . . 15
2.1.2 Composite-Order Bilinear Groups . . . . . . . . . . . . 16
2.1.3 Assumptions . . . . . . . . . . . . . . . . . . . . . . . . 16

2.2 Attribute-Based Encryptions . . . . . . . . . . . . . . . . . . . . 17
2.3 Secure ABE In CML Model . . . . . . . . . . . . . . . . . . . . 19

2.3.1 Security Definition . . . . . . . . . . . . . . . . . . . . . 19
2.3.2 A Lemma for Leakage-Resilient Analysis . . . . . . . . 21

2.4 The Pair Encoding Framework . . . . . . . . . . . . . . . . . . 21
2.5 CryptoNote-Style Cryptocurrencies . . . . . . . . . . . . . . . 24
2.6 Universal Accumulator . . . . . . . . . . . . . . . . . . . . . . . 25

2.6.1 Accumulator For Nonmembership . . . . . . . . . . . . 26
2.7 Zero-Knowledge Arguments of Knowledge . . . . . . . . . . . 28

2.7.1 Abstract Stern’s Protocol . . . . . . . . . . . . . . . . . 29

3 Cross-System Proxy Re-Encryption 31
3.1 Our Contribution in Constructing CS-PRE . . . . . . . . . . . . 32
3.2 Syntax of CS-PRE . . . . . . . . . . . . . . . . . . . . . . . . . . 35



x

3.2.1 Security Notion . . . . . . . . . . . . . . . . . . . . . . . 35
3.3 Our Construction . . . . . . . . . . . . . . . . . . . . . . . . . . 37

3.3.1 Overview of Our Construction . . . . . . . . . . . . . . 37
3.3.2 Our Construction of CS-PRE . . . . . . . . . . . . . . . 38
3.3.3 Security Analysis . . . . . . . . . . . . . . . . . . . . . . 39

3.4 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

4 Leakage-Resilient Attribute-Based Encryption 45
4.1 Our Contributions in Constructing LR-ABE . . . . . . . . . . . 45
4.2 Leakage-Resilient Pair Encoding Scheme . . . . . . . . . . . . 46

4.2.1 Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.2.2 Security Definitions . . . . . . . . . . . . . . . . . . . . 49

4.3 From Leakage-Resilient Pair Encoding to LR-ABE . . . . . . . 50
4.3.1 Generic construction . . . . . . . . . . . . . . . . . . . . 50
4.3.2 Security Proof of Our Generic Construction . . . . . . . 52

4.4 From Pair Encoding to Leakage-Resilient Encoding . . . . . . 54
4.4.1 Extending the Definition of Attrapadung’s Pair En-

coding to Support Encoding of Empty Attribute . . . . 54
4.4.2 Generic Transformation of Pair Encodings to Leakage-

Resilient Pair Encodings . . . . . . . . . . . . . . . . . . 55
4.5 Instantiations of Our Framework . . . . . . . . . . . . . . . . . 59

5 Traceability Analysis of CryptoNote-Style Blockchains 61
5.1 Our Contributions . . . . . . . . . . . . . . . . . . . . . . . . . 63
5.2 Closed Set Attack . . . . . . . . . . . . . . . . . . . . . . . . . . 64

5.2.1 Brute-Force Attack . . . . . . . . . . . . . . . . . . . . . 65
5.2.2 Our Attack . . . . . . . . . . . . . . . . . . . . . . . . . . 66
5.2.3 On The Existence of Closed Set: A Theoretical Per-

spective . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
5.3 Our Clustering Algorithm . . . . . . . . . . . . . . . . . . . . . 78
5.4 Experiment Result . . . . . . . . . . . . . . . . . . . . . . . . . 83

5.4.1 Analysis of Monero . . . . . . . . . . . . . . . . . . . . . 84
5.4.2 Analysis of Bytecoin . . . . . . . . . . . . . . . . . . . . 85
5.4.3 Analysis of DigitalNote . . . . . . . . . . . . . . . . . . 86

5.5 Observations and Recommendations . . . . . . . . . . . . . . . 87

6 Lattice-Based Universal Accumulator 89
6.1 Our Contribution and Overview of Our Idea . . . . . . . . . . 90
6.2 Lattice-Based Universal Accumulator . . . . . . . . . . . . . . 91



xi

6.2.1 Our Construction of Accumulator for Nonmembership 91
6.2.2 Zero-Knowledge Argument of Knowledge of Nonmem-

bership Witness . . . . . . . . . . . . . . . . . . . . . . . 95
6.3 Application of Our Accumulator . . . . . . . . . . . . . . . . . 99

6.3.1 Definition of Fully Dynamic Group Signature . . . . . 100
6.3.2 Our Construction . . . . . . . . . . . . . . . . . . . . . . 102

7 Conclusion 109

A Proofs of Theorems 111
A.1 Proof of Theorem 3.3.1 . . . . . . . . . . . . . . . . . . . . . . . 111
A.2 Proof for Theorem 4.3.1 . . . . . . . . . . . . . . . . . . . . . . . 122

Bibliography 135





xiii

List of Figures

2.1 A General CryptoNote transaction . . . . . . . . . . . . . . . . 25
2.2 Abstract Stern’s protocol . . . . . . . . . . . . . . . . . . . . . . 30

3.1 Workflow of our construction . . . . . . . . . . . . . . . . . . . 33
3.2 Use Case 1 of our CS-PRE . . . . . . . . . . . . . . . . . . . . . 34
3.3 Use Case 2 of our CS-PRE . . . . . . . . . . . . . . . . . . . . . 34

4.1 Main results of our paper . . . . . . . . . . . . . . . . . . . . . 46

5.1 Frequency of number of mixins of anonymous inputs . . . . . 86

6.1 A Merkle-tree Illustration . . . . . . . . . . . . . . . . . . . . . 93
6.2 Illustration of Correctness . . . . . . . . . . . . . . . . . . . . . 94

A.1 Proof Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . 113





xv

List of Tables

1.1 Attribute-based PREs . . . . . . . . . . . . . . . . . . . . . . . . 10

4.1 New schemes/constructions from our Framework . . . . . . . 59

5.1 Experiment Results . . . . . . . . . . . . . . . . . . . . . . . . . 64
5.2 Our Analysis Results on Monero . . . . . . . . . . . . . . . . . 85
5.3 Our Analysis Results on Bytecoin . . . . . . . . . . . . . . . . 87
5.4 Our Analysis Results on DigitalNote . . . . . . . . . . . . . . . 87





xvii

List of Abbreviations

PKE Public-Key Encryption
ABE Attribute-based Encryption
KP-ABE Key-Policy Attribute-based Encryption
CP-ABE Ciphertext-Policy Attribute-based Encryption
IBE Identity-based Encryption
LR-ABE Leakage-Resilient Attribute-based Encryption
DFA Deterministic Finite Automata
SE Spatial Encryption
DSE Doubly Spatial Encryption
KP-DSE Key-Policy Doubly Spatial Encryption
HIBE Hierarchical Identity-Based Encryption
IPE Inner Product Encryption
FE Functional Encryption
COM Commitment Scheme
FDGS Fully Dynamic Group Signature
GM Group Manager
TM Tracing Manager
CH Chameleon Hash Function
PE Pair Encoding
LR-PE Leakage-Resilient Pair Encoding
PMH Perfectly Master-Key Hiding Property
SMH Selectively Master-Key Hiding Property
CMH Co-Selectively Master-Key Hiding Property
ZKAoK Zero-Knowledge Arguments of Knowledge
NIZK Non-Interactive Zero-Knowledge System
CML Continuous Memory Leakage Model
LRC Leakage-Resilient Cryptography
LR Leakage-Resilient Property
PRE Proxy Re-Encryption
CS-PRE Cross-System Proxy Re-Encryption
RKG Re-Encryption Key Generator
PKG Public-Key Generator



xviii

RingCT Ring Confidential Transaction
NM Non-Membership
Acc Accumulator
PPT Probabilistic Polynomial Time
NP Nondeterministic Polynomial Time
SIS Short Integer Solution Problem
LWE Learning With Error Problem
SD Subgroup Decision Assumption
SD1 Subgroup Decision Assumption 1
SD2 Subgroup Decision Assumption 2
SD3 Subgroup Decision Assumption 3
IND-CPA Chosen Plaintext Indistinguishability
IND-CCA Chosen Ciphertext Indistinguishability
CPA Chosen Plaintext Attack
CCA Chosen Ciphertext Attack
C.S. Closed Set



1

Chapter 1

Introduction

Public-key cryptography, introduced by Diffie and Hellman in [DH76], has
been widely employed. Roughly speaking, it refers to the kind of cryp-
tographic systems consisting of a pair of keys, i.e., public key and private
key, where public key is disseminated publicly and private key is known
only to the owner. Typical public-key cryptographic schemes mainly in-
clude public-key encryption (PKE) scheme and digital signature scheme.
They almost appear everywhere in our daily life. For example, when you
surf on the Internet, entering a link with prefix “https”, public-key encryp-
tion schemes are used to encrypt all transcripts between you and the server.
Another example, which appears recently, is that when you would like to
transform some bitcoin to another user, you should use a signature scheme
to identify your identity and authorize the validity of the transaction. In
this thesis, we focus on some research issues raised recently in the area of
public-key encryption and digital signature.

Public-Key Encryption. As a typical representative of public-key cryptog-
raphy, public-key encryption scheme is introduced to ensure data confiden-
tiality. It allows anyone to send some information to a receiver. Moreover,
security of the PKE scheme ensures that no one except the designated re-
ceiver could obtain any information from the communication. Traditional
PKE scheme only allows one designated receiver for each communication
and a variant, called attribute-based encryption (ABE), supports multiple
receivers. Roughly, in an ABE scheme, each user is assigned to some at-
tributes and each message is encrypted under a policy. The functionality of
ABE allows one to obtain the message if his attributes satisfy the policy and
its security prevents one from learning any information about the message
if his attributes do not satisfy the policy.

One important application of ABE schemes is to provide secure and fine-
grained data sharing in the scenario of cloud computing. In a nutshell, cloud



2 Chapter 1. Introduction

computing allows people to use remote servers, aka “cloud”, to complete
their computation or storage tasks. In this way, users of cloud computing
services can conduct (heavy) computation tasks or store and share (mas-
sive) data in a flexible and economical way. To use an ABE scheme to share
data, one first encrypts the data under some “policy”, then he puts the en-
crypted data on the cloud. Next, any one with the valid attributes is able
to retrieve the data. A (usually overlooked) problem in an ABE-based data
sharing system is ""how to forward the data to others"". At first glance, this
requirement can be trivially satisfied via letting the user to download the
ciphertext, decrypt it and send the plaintext to the target. However, as now
people will outsource heavy computation and storage tasks to the cloud,
they usually use a light device, e.g., a mobile phone, to deal with their data,
which may be too resource-constrained to fully decrypt and store the data.
Therefore, a better way to share data is to leave the encrypted data on the
cloud, but transform them into a ciphertext under the public-key of the tar-
get user. In this way, we need an ABE scheme that allows transformation of
its ciphertexts (e.g., from one policy to another) in a public way.

Besides, the development of technology enhances the adversary with
new attack means to the security of pubic-key encryption schemes. Among
them, side-channel attacks appear as a result of our ability in better control-
ling the hardware, including timing attacks [Koc96], power attacks [KJJ99],
cold-boot attacks [HSH+09], etc, all of which will attempt to steal the in-
ternal (secret) state of a computation procedure. Recall that, cryptographic
schemes were proved secure under the assumption that secret keys are per-
fectly protected against attackers. However, via launching side-channel at-
tacks, partial information about the secret key will be revealed to the at-
tacker and thus the previous proof will not be applicable. Even worse,
many cryptographic schemes secure in traditional model are indeed broken
by side-channel attacks. Hence, to enhance security of existing public-key
encryption scheme, we also investigate the construction of ABE schemes se-
cure against side-channel attacks.

Digital Signature. Digital signature scheme is proposed to guarantee the
authenticity of a message, where secret key is employed to sign a message
and generate a signature, associated public-key is used to verify the valid-
ity of a signature on a message. Since its introduction, signature scheme



Chapter 1. Introduction 3

has found numerous applications in practice. One of its famous applica-
tions proposed recently is blockchain-based cryptocurrencies, such as Bit-
coin, Ethereum, etc. For instance, in each transaction of Bitcoin, signa-
ture is generated by the sender to authorize the validity of that transac-
tion. While in some cases, one may hope that identities of users could
also be hidden and to achieve this, the digital signature scheme used in
Bitcoin should be replaced with a suitable privacy-preserving primitive,
such as signature scheme supporting anonymity. As one of the well-known
privacy-preserving primitives, ring signature [RST01, LSW06] is the signa-
ture scheme that allows a user to anonymously sign a message on behalf of a
group of users. In light of this, Cryptonote protocol as well as those variants
based on it, e.g., Monero, Bytecoin, etc., are designed to achieve anonymity
through utilizing ring signature. Since ring signature scheme is provably se-
cure, hence Cryptonote protocol as well as its variants, could provide good
privacy. However, as shown in some recent works [MSH+18, KFTS17], most
transactions in Monero, which use a linkable ring signature scheme to pro-
tect the payers’ identity, are easy to trace. Hence, a question arises: why
provably secure public-key cryptographic schemes fail to protect security
of real-world applications and is there a safe mode to use linkable ring sig-
nature scheme in Monero?

In addition, the emergence of quantum computer raises new threats to
those current cryptographic schemes based on traditional number theoreti-
cal assumptions. A quantum computer is referred to the kind of computer
which performs computations utilizing the quantum-mechanical phenom-
ena. The study of quantum computing can be dated back to 1980s when
Feynman [Fey82] first expressed the idea of simulating quantum mecha-
nism on computers. Since then, researchers have made great efforts in ex-
ploring both its existence and its usability. Especially, in 1994, Shor [Sho94]
finds that it is able to solve both the factoring problem and the discrete log-
arithm problem efficiently by using a quantum computer. Besides, there are
many breakthroughs towards implementing quantum computers in recent
years, and it is estimated that practical quantum computers are likely to
appear in a few decades.

It is widely known that modern public-key cryptography is built on the
hardness of the factoring problem and that of the discrete logarithm prob-
lem. So, if practical quantum computers are realised, most existing cryp-
tographic primitives based on traditional number theoretical assumptions
will be totally broken. As a result, it is an urgent task to develop schemes



4 Chapter 1. Introduction

secure against quantum attacks. In this thesis, we also investigate how to
enhance signature component used in cryptocurrency to be quantum safe.
Specifically, we will focus on lattice-based cryptography and particularly,
we will try to construct efficient privacy-preserving primitives (as just men-
tioned, they are variants of digital signature schemes) from lattice.

In summary, this thesis seeks to address the following questions:

• How to achieve flexible and efficient data sharing in the cloud.

• How to design secure public-key cryptographic primitives secure against
side-channel attacks.

• Why provably secure public-key cryptographic schemes fail to protect se-
curity of real-world applications and is there a safe mode to use linkable
ring signature scheme in Monero?

• How to enhance signature component used in cryptocurrency to be quan-
tum safe.

We give answers to the foregoing questions. Specifically,

• To support efficient and flexible data sharing over cloud, we formalize
the definition of cross-system proxy re-encryption, and propose a con-
struction supporting transform the ciphertext of various ABE schemes to
any target public-key encryption schemes.

• On addressing side-channel attacks, we introduce the first generic con-
struction of ABE schemes secure against continuous memory leakage.

• To clarify under what condition privacy-preserving primitives can be safely
used to protect users’ privacy in a blockchain-based cryptocurrency, we
present a new statistical attack for Monero (as an example). We prove that
this attack is the best possible attack an adversary can launch (without at-
tacking the underlying cryptographic primitives) and show that if some
condition is satisfied, our attack will not compromise users’ privacy. In
this way, we identify a safe mode to use privacy-preserving primitives in
a blockchain-based cryptocurrency.

• On addressing quantum attacks, we propose the first construction of uni-
versal accumulator in the lattice setting, which is a basic component for
constructing many advanced privacy-preserving primitive, such as fully
dynamic group signature.



1.1. Flexible ABE With Outsourcing 5

Next, we elaborate the background and the contribution of each result
from Section 1.1 to Section 1.4 and give the related works in Section 1.5.

1.1 Flexible ABE With Outsourcing

Outsourcing the decryption of ABE ciphertext is a promising method to
tackle the question about how users can decrypt it efficiently. However,
existing solutions require the type of the target ciphertext is determined at
the setup phase of the outsourcing scheme. Accordingly, a remaining issue
appears, namely, how to make the target cryptosystems (or the clients) to
be versatile. Here the problem we wish to tackle is to transform an ABE

ciphertext to any client who is using the same, or possibly different, public-
key encryption system with the sender. The problem is of practical interest
since it is hard to require all clients to use the same PKE, especially in the
case of remote and cross-system data sharing. In addition, we also consider
whether robust client-side decryption scheme can be adopted. This feature
is not supported in the existing ABE with outsourcing.

We introduce cross-system proxy re-encryptions (CS-PRE), which is a
new re-encryption paradigm in which a semi-trusted proxy converts a ci-
phertext of a source cryptosystem (Π0) into a ciphertext of a target cryp-
tosystem (Π). We formalize CS-PRE and present a construction that per-
forms well in the following aspects. (1)Versatility: Π0 can be any attribute-
based encryption (ABE) within Attrapadung’s pair encoding framework. Π
can be any public-key encryption. Furthermore, the keys and public param-
eters can be generated independently. (2) Compatibility: CS-PRE does not
modify the public parameters and keys of Π0 and Π. Besides, input for the
conversion is an ordinary ciphertext of Π0. (3) Efficiency: The computational
cost for re-encryption (resp. decryption) of the re-encrypted ciphertext is
roughly the same as a decryption in Π0 (resp. Π).

We prove that the construction is fully secure assuming Π0 is secure in
Attrapadung’s framework and Π is IND-CPA secure. Furthermore, it re-
mains secure when there are multiple target cryptosystems. As with other
proxy re-encryption, CS-PRE enables flexible sharing of cloud data, as the
owner can instruct the cloud server to re-encrypt his ciphertext to those for
the intended recipient. In addition, it allows lightweight devices to enjoy
access to remote data encrypted under powerful but possibly costly encryp-
tion, such as functional encryption, by utilizing the server’s power in con-
verting the ciphertext to a simpler encryption, such as RSA-OAEP. Finally,



6 Chapter 1. Introduction

instances of CS-PRE can be viewed as new proxy re-encryption schemes,
such as a PRE supporting ABE for regular language to Hierarchical IBE or
Doubly Spatial Encryption to lattice-based encryptions (e.g. NTRUCCA).

1.2 Leakage-Resilient Attribute-Based Encryption

On proposing construction of leakage-resilient cryptographic primitives, we
introduce the first adaptively secure attribute-based encryption schemes in
continual memory leakage model, which is a model that allows continuous
leakage on both user and master secret keys.

The proposed generic framework for constructing leakage-resilient fully
secure ABEs (LR-ABEs) results from leakage-resilient pair encoding, which is
an extension of pair encoding presented in the recent work of Attrapadung.
In this way, our framework simplifies the design and analysis of LR-ABEs
into the design and analysis of predicate encodings.Moreover, we discover
new adaptively secure LR-ABEs, including FE for regular languages, ABE for
large universe and ABE with short ciphertext. Above all, leakage-resilient
adaptively secure attribute-based encryption schemes can equip fog com-
puting with higher security and fine-grained access control.

1.3 Applicability of Cryptographic Primitives in

Blockchain

While the cascade effect attacks [MSH+18] on the untraceability of Monero
are circumvented by two approaches. The first one is to increase the mini-
mum ring size of each input, from 3 (version 0.9.0) to 7 in the latest update
(version 0.12.0). The second approach is introducing the ring confidential
transactions with enhanced privacy guarantee. However, so far, no formal
analysis has been conducted on the level of anonymity provided by the new
countermeasures in Monero. In addition, since Monero is only an example
of leading CryptoNote-style blockchains, the actual privacy guarantee pro-
vided by other similar blockchains in the wild remains unknown.

We propose a more sophisticated statistical analysis on CryptoNote-style
cryptocurrencies. In particular, we introduce a new attack on the transac-
tion untraceability, which we call closed set attack. We prove that our attack
is optimal assuming that no additional information is given. In other words,
in terms of the result, closed set attack is equivalent to the brute-force attack,



1.4. Quantum Safe Universal Accumulator 7

which exhausts all possible input choices and removes those that are impos-
sible given the constraints imposed by the mixins of each transaction.

To verify the impact of our attack in reality, we conduct experiments on
the top 3 CryptoNote-style cryptocurrencies, namely, Monero, Bytecoin and
DigitalNote, according to their market capitalization. Since the computa-
tional cost of performing closed set attack is prohibitively expensive, we pro-
pose an efficient algorithm, called clustering algorithm, to (approximately)
implement closed set attack. For Monero, out of the total of 23164745 trans-
action inputs (up to block 1541236), our clustering algorithm can further
identify the real payer of 5752 transaction inputs. Indeed, by combining our
clustering method with the cascade attack, we are able to identify the real
coin spent in 16334967 transaction inputs, and reduce the mixin set (so the
anonymity) of 1736530 inputs. Last but not least, through our combined
attack, we are able to identify the real coin being spent in 74.25% Bytecoin
inputs, and in 91.56% DigitalNote inputs.

In addition, we provide a the";"""date"",""2020-05-22T03:49:51Z""
""pdf:PDFVersion"",""1.6""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:docinfo:title"",""""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.6""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""xmp:CreateDate"",""2020-02-26T16:26:36Z""
""modified"",""2020-05-22T03:49:51Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""xmp:ModifyDate"",""2020-05-22T11:49:51Z""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016) kpathsea version 6.2.2""
""trapped"",""False""
""meta:creation-date"",""2020-02-26T08:26:36Z""
""created"",""2020-02-26T08:26:36Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-02-26T08:26:36Z""
""resourceName"",""991022379157803411.pdf""
""producer"",""pdfTeX-1.40.17""
""pdf:docinfo:producer"",""pdfTeX-1.40.17""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""54"",""0"",""0"",""0"",""0"",""0"",""9"",""2"",""0"",""4"",""16"",""18"",""35"",""47"",""0"",""1"",""0"",""0"",""0"",""5"",""5"",""0"",""0"",""0"",""0"",""4"",""3"",""6"",""17"",""18"",""54"",""6"",""0"",""0"",""0"",""0"",""0"",""44"",""11"",""1"",""4"",""5"",""4"",""0"",""4"",""31"",""31"",""58"",""40"",""15"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""19"",""1"",""5"",""0"",""11"",""6"",""29"",""19"",""0"",""1"",""0"",""4"",""2"",""4"",""0"",""0"",""3"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""6"",""23"",""13"",""40"",""22"",""18"",""44"",""100"",""0"",""2"",""2"",""7"",""23"",""5"",""11"",""14"",""12"",""0"",""0"",""0"",""0"",""11"",""0"",""24"",""34"",""25"",""21"",""38"",""16"",""35"",""18"",""0"",""2"",""0"",""2"",""5"",""1"",""2"",""4"",""0"",""2"",""2"",""2"",""4"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""1"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dcterms:created"",""2020-02-26T08:26:36Z""
""Last-Modified"",""2020-05-22T03:49:51Z""
""dcterms:modified"",""2020-05-22T03:49:51Z""
""title"",""""
""xmpMM:DocumentID"",""uuid:8588156b-504f-4b38-8431-ce8da349f5ac""
""Last-Save-Date"",""2020-05-22T03:49:51Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2020-05-22T03:49:51Z""
""meta:save-date"",""2020-05-22T03:49:51Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016) kpathsea version 6.2.2""
""Content-Length"",""957063""
""Content-Type"",""application/pdf""
""xmp:MetadataDate"",""2020-05-22T11:49:51Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""pdf:producer"",""pdfTeX-1.40.17""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""167""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""1149"",""94"",""205"",""294"",""1981"",""0"",""1687"",""904"",""1693"",""0"",""1190"",""1679"",""429"",""0"",""502"",""0"",""309"",""0"",""979"",""451"",""1718"",""2176"",""2312"",""1823"",""2210"",""1979"",""2175"",""2014"",""1849"",""1151"",""2218"",""2176"",""2310"",""1330"",""1377"",""1369"",""1451"",""1510"",""1482"",""1554"",""1443"",""1350"",""1211"",""2005"",""1575"",""1324"",""1575"",""1464"",""1572"",""1142"",""1557"",""2027"",""1815"",""526"",""1648"",""1387"",""1267"",""1435"",""1391"",""1436"",""1689"",""1989"",""738"",""0"",""1493"",""1458"",""1329"",""1167"",""1359"",""1263"",""1380"",""1733"",""1346"",""1554"",""1253"",""1009"",""1824"",""1698"",""685"",""0"",""1592"",""1996"",""2060"",""1905"",""1752"",""2001"",""1604"",""1973"",""1502"",""868"",""1383"",""1504"",""1688"",""1291"",""1412"",""1788"",""2003"",""1838"",""1775"",""2032"",""1574"",""2343"",""1835"",""2027"",""1779"",""1157"",""1337"",""1731"",""1635"",""1810"",""1559"",""1282"",""1474"",""1962"",""1406"",""1568"",""1346"",""1515"",""1670"",""1941"",""1795"",""1936"",""1402"",""1679"",""1524"",""1160"",""1238"",""1217"",""1506"",""886"",""1154"",""1358"",""1230"",""1544"",""1351"",""1364"",""1201"",""1184"",""1474"",""1500"",""1161"",""1615"",""1455"",""1440"",""1241"",""1336"",""1588"",""1483"",""1465"",""1185"",""1332"",""1292"",""1556"",""1383"",""1436"",""1531"",""1532"",""1488"",""1700"",""1658"",""1526"",""1696"",""1657"",""1536"",""1478"",""1570"",""1457""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-02-26T08:26:36Z""
";https://scholar.google.ch/scholar?start=840&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098804-194;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;[CITATION][C] Unforgeability in the quantum world.;M Arapinis, M Delavar, M Doosti, E Kashefi ; IACR Cryptol. ePrint Arch., 2020;;null;Cité 1 fois;;null;;;;https://scholar.google.ch/scholar?start=740&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098853-303;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;A Conceptual Framework for Digital-Asset Securities: Tokens and Coins as Debt and Equity;Y Guseva ; Md. L. Rev., 2020  HeinOnline;;"… AROUND THE WORLD (2018), https://www.loc.gov/law/help/cryptocurrency/cryptocurrency-world-

survey … See also Del Wright Jr., Quadratic Voting and Blockchain Governance, 88 UMKC L. REV …

note 9, at 470-85; Philipp Hacker & Chris Thomale, Crypto- Securities Regulation …";Cité 2 fois;;[PDF] umaryland.edu;https://digitalcommons.law.umaryland.edu/cgi/viewcontent.cgi?article=3878&context=mlr;"
Maryland Law Review Maryland Law Review 

Volume 80 Issue 1 Article 7 

A Conceptual Framework for Digital-Asset Securities: Tokens and A Conceptual Framework for Digital-Asset Securities: Tokens and 

Coins as Debt and Equity Coins as Debt and Equity 

Yuliya Guseva 

Follow this and additional works at: https://digitalcommons.law.umaryland.edu/mlr 

 Part of the Securities Law Commons 

Recommended Citation Recommended Citation 
Yuliya Guseva, A Conceptual Framework for Digital-Asset Securities: Tokens and Coins as Debt and 
Equity, 80 Md. L. Rev. 166 (2021) 
Available at: https://digitalcommons.law.umaryland.edu/mlr/vol80/iss1/7 

This Article is brought to you for free and open access by the Academic Journals at DigitalCommons@UM Carey 
Law. It has been accepted for inclusion in Maryland Law Review by an authorized editor of DigitalCommons@UM 
Carey Law. For more information, please contact smccarty@law.umaryland.edu. 

https://digitalcommons.law.umaryland.edu/mlr
https://digitalcommons.law.umaryland.edu/mlr/vol80
https://digitalcommons.law.umaryland.edu/mlr/vol80/iss1
https://digitalcommons.law.umaryland.edu/mlr/vol80/iss1/7
https://digitalcommons.law.umaryland.edu/mlr?utm_source=digitalcommons.law.umaryland.edu%2Fmlr%2Fvol80%2Fiss1%2F7&utm_medium=PDF&utm_campaign=PDFCoverPages
http://network.bepress.com/hgg/discipline/619?utm_source=digitalcommons.law.umaryland.edu%2Fmlr%2Fvol80%2Fiss1%2F7&utm_medium=PDF&utm_campaign=PDFCoverPages
mailto:smccarty@law.umaryland.edu


 

 

166 

A CONCEPTUAL FRAMEWORK FOR DIGITAL-ASSET 
SECURITIES: TOKENS AND COINS AS DEBT AND EQUITY 

YULIYA GUSEVA* 

A. INTRODUCTION ......................................................................................167 
B. AN OVERVIEW OF TOKENS ....................................................................175 

1. Token Taxonomy .....................................................................175 
1.1. Native and Non-native Tokens ....................................175 
1.2. Functional and Regulatory Classifications ..................176 
1.3. Fungible and Non-Fungible Tokens ............................177 

2. The Two Stages of Digital Asset Markets ...............................179 
3.  Howey and Bonds ....................................................................184 

C. EXAMINING THE TELEGRAM CASE .........................................................188 
1. Facts and History .....................................................................188 
2.  Distribution, Grams & “Scheme” ............................................189 
3. The Two-Stage Process ............................................................191 
4. Contract Interpretation and Bond Maturity ..............................193 

D. KIK INTERACTIVE, DAPPS, AND NON-NATIVE TOKENS ..........................197 
1. Dapps .......................................................................................197 
2. The Case of Kik Interactive: Blurring the Boundaries of the 

Two-Stage Token Distribution ................................................200 
E. THE SPECIAL CASE OF EQUITY ..............................................................201 

1. The DAO ..................................................................................203 
2. MakerDAO ..............................................................................205 
3.  The Transformation of Equity and the Williamson Test ..........207 

F. THE IMPORTANCE OF SECURITIES LAW IN STAGE ONE .........................209 
 

Š 2020 Yuliya Guseva. 
* Professor of Law, Rutgers Law School, yg235@law.rutgers.edu.  I am grateful to many 
commentators for their criticisms and comments on several drafts and various sections of this 
Article.  My gratitude goes to Brian Avello, Matthew Bruckner, Lewis Cohen, Douglas Eakeley, 
Edward Greene, Chrystin Ondersma, Jeff Schwartz, Aaron Wright, and David Yermack.  I also 
would like to thank the participants of the following workshops and conferences for their comments 
and critiques on various drafts of this Article: the 2020 Maryland Law Review Symposium; the 30th 
Anniversary of SASE Meeting, Fathomless Futures: Algorithmic and Imagined; the 2019 and 2020 
National Business Law Scholars Conferences; the 2019 Law and Society Association Annual 
Meeting; the 2019 Governance of Emerging Technologies and Science at Sandra Day O’Connor 
College of Law; the Junior Faculty Forum at the University of Richmond School of Law; and the 
2019 and 2020 Rutgers Faculty Workshops.  Many thanks to Leo Choi, Jonathan Garfield, Katarina 
Gonzalez, and Brent McDonough for their research assistance. 



  

2020]   A CONCEPTUAL FRAMEWORK FOR DIGITAL-ASSET SECURITIES 167 

G. CONCLUSION .........................................................................................212 

 

A. INTRODUCTION 

Blockchain technology,1 fintech,2 and cryptoassets (also called “digital 
assets”)3 have become universal economic phenomena.  Capital markets have 
witnessed sales of digital assets in the form of digital securities, tokens, and 
coins distributed by private entities and even by the World Bank.4  The 
importance of cryptoassets and blockchain technology is hard to 

 
 1. A blockchain is “a cryptographically-secured digital ledger, and a blockchain’s protocol is 
the software that governs rules, operations, and communications between computers interacting 
with the blockchain.”  Simply Vital Health, Inc., Exchange Act Release No. 10671, at 2 (Aug. 12, 
2019), https://www.sec.gov/litigation/admin/2019/33-10671.pdf.  A “distributed ledger” (which is 
the underlying feature of “distributed ledger technology” or “DLT”) can be described as “a large, 
decentralized database that is maintained on a network of computers rather than a single server, and 
that is updated in real-time.”  Hilary J. Allen, $=€=Bitcoin?, 76 MD. L. REV. 877, 886 (2017).  See 
also Carla L. Reyes, Conceptualizing Cryptolaw, 96 NEB. L. REV. 384, 390–91 (2017) [hereinafter 
Reyes, Conceptualizing Cryptolaw]; Angela Walch, The Bitcoin Blockchain as Financial Market 
Infrastructure: A Consideration of Operational Risk, 18 N.Y.U. J. LEGIS. & PUB. POL’Y 837, 843–
44 (2015).  
 2. “Fintech” refers to the integration of financial services and technology.  See, e.g., Chris 
Brummer & Yesha Yadav, Fintech and the Innovation Trilemma, 107 GEO. L.J. 235, 241 n.18 
(2019) (defining the “broad definition of fintech” as “the use of digital technologies in finance”); 
U.S. GOVERNMENT ACCOUNTABILITY OFFICE, FINANCIAL TECHNOLOGY: INFORMATION ON 
SUBSECTORS AND REGULATORY OVERSIGHT 1 (2017), 
https://www.gao.gov/assets/690/684187.pdf (noting that “[f]intech products and services include 
small business financing, education refinancing, mobile wallets, virtual currencies, and platforms 
to connect investors and start-ups”). 
 3. The term “refers to an asset that is issued and transferred using distributed ledger or 
blockchain technology, including, but not limited to, so-called ‘virtual currencies,’ ‘coins,’ and 
‘tokens.’” SEC, FRAMEWORK FOR “INVESTMENT CONTRACT” ANALYSIS OF DIGITAL ASSETS (last 
modified Apr. 3, 2019), https://www.sec.gov/files/dlt-framework.pdf [hereinafter THE SEC 
FRAMEWORK].  Cryptoassets are “an entry in a ledger that specifies that a particular user 
[can] . . . exercise a discrete set of powers.”  Shaanan Cohney, David Hoffman, Jeremy Sklaroff & 
David Wishnick, Coin-Operated Capitalism, 119 COLUM. L. REV. 591, 602 (2019).  
 4. See infra Section B; Steven Gatti, David Adams, Peter Chapman, Laura Nixon, Paul 
Landless, Jack Hardman & Brian Harley, Fintech in 2019, Five Trends to Watch, NYU: PROGRAM 
ON CORP. COMPLIANCE & ENF’T (Feb. 7, 2019), 
https://wp.nyu.edu/compliance_enforcement/2019/02/07/fintech-in-2019-five-trends-to-watch/. 



  

168 MARYLAND LAW REVIEW [VOL. 80:166 

overestimate.5  These innovations have been closely watched by foreign6 and 
U.S. regulators.7  2019 and the first three quarters of 2020 produced as many 
as five bills in Congress and one major proposal—Rule 195—by an SEC 
Commissioner who is a leading expert on technology and digital assets.8  In 
turn, legal scholarship has examined how to fit blockchain-based entities and 
digital assets within the corporate and securities law frameworks.9   

 
 5. Among other things, blockchain technology can reduce compliance and contracting costs 
and improve transaction verification mechanisms, record keeping, shareholder voting, contract 
performance, and title transfers, although it also poses a series of risks.  See, e.g., Carla L. Reyes, If 
Rockefeller Were a Coder, 87 GEO. WASH. L. Rev. 373, 379–88 (2019) [hereinafter Reyes, 
Rockefeller]; Hilary J. Allen, Driverless Finance, 10 HARV. BUS. L. REV. 157, 158–161 (2020); 
David Yermack, Corporate Governance and Blockchains, 21 REV. OF FIN. 7, 7–8 (2017); Joshua 
A.T. Fairfield, Bitproperty, 88 S. CAL. L. REV. 805, 808–09 (2015); Federico Panisi, Ross P. 
Buckley & Douglas W. Arner, Blockchain and Public Companies: A Revolution in Share 
Ownership Transparency, Proxy Voting and Corporate Governance?, 2 STAN. J. BLOCKCHAIN L. 
& POL’Y 1, 2-4 (2019); Brummer & Yadav, supra note 2, at 272; Letter from Trey Hollingsworth, 
Darren Soto, Bill Foster, Tom Emmer, Ted Budd, Josh Gottheimer & David Schweikert, Members, 
U.S. House of Representatives, to Lawrence Kudlow, Dir., Nat’l Econ. Council (May 24, 2019), 
https://hollingsworth.house.gov/uploadedfiles/hollingsworth_soto_blockchain_letter.pdf. 
 6. See, e.g., AMERICAN BAR ASSOCIATION, DIGITAL AND DIGITIZED ASSETS: FEDERAL AND 
STATE JURISDICTIONAL ISSUES 39–200, 227–29, 236–80 (2019), 
https://www.americanbar.org/content/dam/aba/administrative/business_law/buslaw/committees/C
L620000pub/digital_assets.pdf [hereinafter ABA, DIGITAL ASSETS]; Brief for Chamber of Digital 
Commerce as Amici Curiae Supporting Plaintiff, SEC v. Telegram Inc. & Ton Issuer Inc., No. 1:19-
cv-09439-PKC, 2020 WL 61528, at *5 n.10 (Jan. 21, 2020) [hereinafter Chamber’s Brief]. 
 7. See, e.g., U.S. DEPARTMENT OF JUSTICE, CRYPTOCURRENCY ENFORCEMENT FRAMEWORK 
(2020), https://www.justice.gov/ag/page/file/1326061/download; FINANCIAL STABILITY BOARD, 
ADDRESSING THE REGULATORY, SUPERVISORY AND OVERSIGHT CHALLENGES RAISED BY 
“GLOBAL STABLECOIN” ARRANGEMENTS: CONSULTATIVE DOCUMENT (2020), 
https://www.fsb.org/2020/04/addressing-the-regulatory-supervisory-and-oversight-challenges-
raised-by-global-stablecoin-arrangements-consultative-document/.  See generally Yuliya Guseva, 
The SEC, Digital Assets, and Game Theory, J. CORP. L. (forthcoming 2021) [hereinafter Guseva, 
Game Theory]. 
 8. Securities Clarity Act, H.R. 8378, 116th Cong. (2020), 
https://emmer.house.gov/_cache/files/d/e/de97d89a-a652-42e9-a436-
b36fd541933f/E5FEB0CE89638FF4E5C649E1AC916FC5.emmer-041-xml.pdf; Keep Big Tech 
Out of Finance Act, H.R. 4813, 116th Cong. (2019); Token Taxonomy Act of 2019, H.R. 2144, 
116th Cong. (2019); Crypto-Currency Act of 2020, H.R. 6154, 116th Cong. (2020); Managed 
Stablecoins are Securities Act of 2019, H.R. 5197, 116th Cong. (2019); Hester M. Peirce, Comm’r, 
SEC, Running on Empty: A Proposal to Fill the Gap Between Regulation and Decentralization (Feb. 
6, 2020), https://www.sec.gov/news/speech/peirce-remarks-blockress-2020-02-06 [hereinafter 
Peirce Speech and Proposal] (proposing Rule 195).  
 9. The following is by no means an exhaustive list of scholarly publications on these issues.  
See, e.g., Reyes, Conceptualizing Cryptolaw, supra note 1; Usha R. Rodrigues, Law and the 
Blockchain, 104 IOWA L. REV. 679 (2019) (discussing the incomplete nature of new smart contracts 
and applying it to business organizations law); Eric C. Chaffee, Securities Regulation in Virtual 
Space, 74 WASH. & LEE L. REV. 1387 (2017); Brummer & Yadav, supra note 2; Lewis Rinaudo 
Cohen, Ain’t Misbehavin’: An Examination of Broadway Tickets and Blockchain Tokens, 65 
WAYNE L. REV. 81 (2019); Panisi et al., supra note 5; William Magnuson, Regulating Fintech, 71 
VAND. L. REV. 1167 (2018) (reviewing fintech challenges from the perspective of financial 
regulation and Dodd-Frank in particular); Shlomit Azgad-Tromer, Crypto Securities: On the Risks 
of Investments in Blockchain-Based Assets and the Dilemmas of Securities Regulation, 68 AM. U. 



  

2020]   A CONCEPTUAL FRAMEWORK FOR DIGITAL-ASSET SECURITIES 169 

This Article contributes to the growing literature on crypto and fintech 
and discusses two distinct stages in cryptoasset capital raising.  Securities law 
is crucial in the first stage but essentially irrelevant in the second stage.  
Academic commentary has either missed or misinterpreted when this second 
stage begins and what the rights and obligations of the affected parties are.  
Most importantly, two recent judicial decisions—Telegram10 and Kik11—
suggest that federal district courts struggle with distinguishing and 
conceptualizing the discrete stages in the development of crypto projects.  

The first stage (“Stage One”) is mainly about raising capital: Firms 
acting as issuers offer and sell securities to investors, often on the promise to 
deliver a functioning and marketable product, i.e., digital assets, as a form of 
return.12  With the exception of the financial instruments issued by 
decentralized autonomous organizations (“DAOs”) and certain governance 
tokens,13 many digital assets do not confer voting rights or other equity-like 
rights with respect to issuers, nor do they trigger fiduciary duties typically 
associated with equity.14  

 
L. REV. 69 (2018); Wulf A. Kaal, Initial Coin Offerings: The Top 25 Jurisdictions and Their 
Comparative Regulatory Responses (as of May 2018), 1 STAN. J. BLOCKCHAIN L. & POL’Y 41 
(2018); Kevin Werbach, Trust, but Verify: Why the Blockchain Needs the Law, 33 BERKELEY TECH. 
L.J. 487 (2018); Aaron Wright & Primavera De Filippi, Decentralized Blockchain Technology and 
the Rise of Lex Cryptographia 1 (Mar. 20, 2015) (unpublished manuscript), 
https://papers.ssrn.com/sol3/papers.cfm?abstract_id=2580664 (presenting one of the first accounts 
on decentralized autonomous organizations and smart contracts); Kelsey Bolin, Decentralized 
Public Ledger Systems and Securities Law: New Applications of Blockchain Technology and the 
Revitalization of Sections 11 and 12(A)(2) of the Securities Act of 1933, 95 WASH. U. L. REV. 955, 
955 (2018) (reviewing the federal and state law); Dmitri Boreiko, Guido Ferrarini & Paolo Giudici., 
Blockchain Startups and Prospectus Regulation, 20 EUR. BUS. ORG. L. REV. 665 (2019); J. Brad 
Bernthal, The Evolution of Entrepreneurial Finance: A New Typology, 2018 BYU L. REV. 773, 
773–74 (2018) (discussing emerging forms of startup financing and the decreasing role of corporate 
law and proposing a new typology of financial instruments that are outside the debt-equity divide); 
Jonathan Rohr & Aaron Wright, Blockchain-Based Token Sales, Initial Coin Offerings, and the 
Democratization of Public Capital Markets, 70 HASTING L.J. 463, 470–85 (2019); Carol Goforth, 
Securities Treatment of Tokenized Offerings Under U.S. Law, 46 PEPP. L. REV. 405, 416–17 (2019) 
[hereinafter Goforth, Securities Treatment of Tokenized Offerings]; Carol R. Goforth, How 
Blockchain Could Increase the Need for and Availability of Contractual Ordering for Companies 
and Their Investors, 94 N.D. L. REV. 1, 1 (2019) [hereinafter Goforth, Contractual Ordering]. 
 10. SEC v. Telegram Group, Inc., No. 19-cv-9439 (PKC), 2020 U.S. Dist. LEXIS 53846 
(S.D.N.Y. Mar. 23, 2020) [hereinafter Court Order]. 
 11. SEC v. Kik Interactive, No. 19 Civ. 5244 (AKH), 2020 WL 5819770, at *8 (S.D.N.Y. 
2020). 
 12. See infra Sections B & C. 
 13. An example of governance tokens is the tokens recently issued by decentralized finance 
protocol Uniswap.  Paddy Baker, Uniswap’s Newly Launched UNI Token Has Already Doubled in 
Price, COINDESK (Sept. 18, 2020), https://www.coindesk.com/uniswap-uni-token-price. For a 
discussion of DAOs, see infra Section E. 
 14. See infra Section E (discussing DAOs); Section B.1 (examining token classifications); see 
also infra note 285 and accompanying text.  Some scholars discuss various financial tokens under 
a broad heading of “equity tokens.”  See, e.g., Dirk A. Zetzsche, Ross P. Buckley, Douglas W. Arner 



  

170 MARYLAND LAW REVIEW [VOL. 80:166 

If we narrow down the capital structure of all firms and projects to only 
two general categories of debt and equity, many digital assets in Stage One 
will default to debt securities such as bonds or unsecured debentures.15  Both 
are commonly combined under the umbrella term of “bonds”—diverse and 
variegated debt securities that are creatures of contract16 and a subclass of 
financial instruments.17  Viewed in this light, offering documents—including 
whitepapers and, in some cases, purchase agreements for future tokens along 
the lines of the “SAFT” framework18—may be examined as de facto bond 
indentures, prospectuses, and offering memoranda.  

As developed further in this Article, the key parties in Stage One are the 
initial purchasers (the “Initial Investors” or “Initial Token-Holders”) of future 
tokens and the developer (or “issuer-developer”)19 with its intra-firm 
governance mechanisms.  It is logical that the Initial Token-Holders 
providing debt financing are investors giving (1) their capital (2) to a 

 
& Linus Föhr, The ICO Gold Rush: It’s a Scam, It’s a Bubble, It’s a Super Challenge for Regulators, 
60 HARV. INT’L L.J. 267, 275 (2019) (“Currency tokens are characterized by a token reflecting a 
right in another currency, whether crypto or otherwise.  Equity tokens represent the right to a share 
in a cash flow generated by some underlying asset.  Among the equity tokens, some ICOs confer 
participation of token holders in an asset pool in a non-segregated manner, while in other cases the 
token allows participation in one single asset, separable from other assets.”).  This Article examines 
only decentralized autonomous organizations’ tokens as equity-like financial instruments.  These 
tokens give token-holders the rights to, inter alia, vote and receive income directly tied to the 
operations of a DAO.  
 15. ALAN S. GUTTERMAN, BUSINESS TRANSACTIONS SOLUTIONS § 155:79 (2020) 
(“Debentures are generally ‘unsecured’ and the indebtedness of the corporation evidenced by a 
debenture is backed solely by the overall financial condition and creditworthiness of the 
corporation.”). 
 16. RICHARD A. BREALEY, STEWART C. MYERS & FRANKLIN ALLEN, PRINCIPLES OF 
CORPORATE FINANCE 351–53 (10th ed. 2011).  
 17. MERRITT B. FOX, LAWRENCE R. GLOSTEN & GABRIEL V. RAUTERBERG, THE NEW STOCK 
MARKET: LAW, ECONOMICS, AND POLICY 11 (2019) (“A financial instrument . . . is essentially a 
contract that provides the contract holder with some kind of claim to the cash flows and/or control 
of a business.”). 
 18. See, e.g., Thomas Bourveau, Emmanuel T. De George, Atif Ellahie & Daniele Macciocchi, 
Initial Coin Offerings: Early Evidence on the Role of Disclosure in the Unregulated Crypto Market 
3 (July 2018) (unpublished manuscript), https://www.marshall.usc.edu/sites/default/files/2019-
03/thomas_bourveau_icos.pdf (explaining that a whitepaper is “an unaudited marketing document 
that might contain information such as the business proposition for the crypto-token, addressable 
market opportunity, technology, proof-of-concept case studies, expected progress timeline, identity 
and background of the team, ICO process and platform, token distribution, vesting restrictions, use 
of proceeds, etc.”); JUAN BATIZ-BENET, MARCO SANTORI & JESSE CLAYBURGH , THE SAFT 
PROJECT: TOWARD A COMPLIANT TOKEN SALE FRAMEWORK (2017), 
https://saftproject.com/static/SAFT-Project-Whitepaper.pdf. 
 19. I use the terms “developer,” “issuer-developer” and “firm-developer” interchangeably and 
primarily to describe promoters of crypto-projects.  After an open-source project’s launch, however, 
these original firm-developers may join the community of other developers, i.e., third-party 
developers.  For a review of relevant parties in open-source decentralized projects, see Carla L. 
Reyes, (Un)Corporate Crypto-Governance, 88 FORDHAM L. REV. 1875, 1886–88 (2020) 
[hereinafter Reyes, (Un)Corporate Crypto-Governance]. 



  

2020]   A CONCEPTUAL FRAMEWORK FOR DIGITAL-ASSET SECURITIES 171 

common enterprise (3) with the expectation to earn profit (4) from the efforts 
of the developer.  These four characteristics are the backbone of the Supreme 
Court’s Howey test, which is typically applied by the Securities and 
Exchange Commission (“SEC”) to digital assets that are deemed “investment 
contracts” and, therefore, securities.20  This Article will examine digital assets 
as new types of bonds, apply the Howey test to these instruments, and show 
why and how securities law is crucial in Stage One but not in Stage Two of 
cryptoasset projects.  

The second stage (“Stage Two”) begins with the launch of a 
decentralized platform, DAO, or decentralized application (“Dapp”) and the 
delivery of fully functional digital assets.  At this point, the status of token-
holders and the nature of the assets, as well as the need for and applicability 
of securities law, become less clear.  The facts in Telegram underscore these 
dilemmas and the discreteness of the two-stage process.  

Had Telegram been allowed to distribute its tokens and launch the new 
blockchain, anyone would be able to build on the platform (viz., it was open 
source), the code underlying the assets could not be unilaterally changed by 
the original promoter-developer (i.e., Telegram), and the promoter would not 
have the means to singlehandedly impact the platform and the assets, 
including their supply, demand, and valuation.21  These factors infer that 
project governance would effectively metamorphose into a decentralized and 
autonomous system.  This point of metamorphosis (provided it is 
discernable)22 should work as the cutoff point where conventional securities 
law becomes largely irrelevant as crypto-market mechanisms take over.  

At the same time, as this Article will demonstrate, this cutoff point does 
not either alter the rights of the Initial Investors or destroy the original 
“indenture.”23  The root cause is that neither token delivery nor platform 
launch is determinative of the expiration or maturity of the original bonds.  
Determining the bonds’ term to maturity becomes key to understanding the 
nature of the transactions, the Initial Investors’ rights, and the firm-
developer’s obligations.24   

The term to maturity does three things.  First, bonds are securities.  Their 
continuous existence in both Stages One and Two, i.e., even after fully-

 
 20. SEC v. W. J. Howey Co., 328 U.S. 293 (1946).  For the most recent application of the test, 
see SEC v. Kik Interactive, No. 19 Civ. 5244 (AKH), 2020 WL 5819770, at *5–8 (S.D.N.Y. 2020).  
 21. See infra Sections B & C. 
 22. In Kik, for instance, Stages One and Two were obscure because the developer conducted 
both a private placement of bonds and a public distribution of the digital assets (called “Kin”) 
approximately at the same time and, as the district court concluded, for the same purposes of 
developing the Kin Ecosystem leading to an integration of the offerings.  Kik Interactive, No. 19 
Civ. 5244 (AKH) at *6–8 (S.D.N.Y. 2020).  
 23. See infra Sections B & C. 
 24. Id.  



  

172 MARYLAND LAW REVIEW [VOL. 80:166 

functional tokens are delivered and platforms are launched, extends the 
application of the Supreme Court’s Howey test25 and thus the U.S. federal 
securities law post-launch and post-asset-delivery.  Second, it points toward 
two distinct and separate types of assets—a non-security-token (or coin) and 
a bond—simultaneously circulating after the project has been deployed and 
tokens distributed. 

Third, the two groups of asset purchasers—the Initial Investors who 
own tokens post-delivery and post-platform-launch and the subsequent token 
purchasers (“Public Token-Holders” or “Subsequent Token-Holders”)—
exist concurrently.  These two cohorts of market participants have completely 
divergent expectations concerning the role of the issuer in the operation of a 
platform or a Dapp and the valuation of digital assets.  The issuer-developer, 
on its part, has different obligations to each.  Only the bondholders can bring 
claims under securities law against the issuer in Stage Two.26   

This conceptual framework both differs from and contributes to the 
previous scholarship in the following way.  Some commentators have 
examined the hybrid nature of digital assets, which simultaneously present 
securities and non-securities attributes.27  Another notable view was 
expressed by Director Hinman in his consequential speech on digital assets, 
as well as by SEC Chairman Clayton: a digital-asset security can evolve into 
a non-security.28  It is also possible that because transactions are typically 

 
 25. SEC v. W. J. Howey Co., 328 U.S. 293 (1946).  See also Reves v. Ernst & Young, 494 U.S. 
56, 61 (1990); SEC v. Edwards, 540 U.S. 389, 393 (2004); H.R. REP. NO. 73–85, at 11 (1933). 
 26. See infra Section B. 
 27. Boreiko et al., supra note 9; Rohr & Wright, supra note 9, at 488.  A “token could be 
deemed both a security and a means of payment.”  AMERICAN BAR ASSOCIATION, supra note 6, at 
252.  APOLLINE BLANDIN, ANN SOFIE CLOOTS, HATIM HUSSAIN, MICHEL RAUCHS, RASHEED 
SALEUDDIN, JASON GRANT ALLEN, BRYAN ZHANG & KATHERINE CLOUD, GLOBAL CRYPTOASSET 
REGULATORY LANDSCAPE STUDY 21 (2019), https://www.jbs.cam.ac.uk/fileadmin/ 
user_upload/research/centres/alternative-finance/downloads/2019-04-ccaf-global-cryptoasset-
regulatory-landscape-study.pdf (describing “cryptoasset” as “an umbrella term to describe an array 
of tokens that exhibit a wide range of characteristics”).  Hybrid financial instruments are a known 
quantity in securities law and typically call for case-by-case analysis.  See, e.g., United States v. 
Leonard, 529 F.3d 83, 88–89 (2d Cir. 2008) (citing Reves, 494 U.S. at 62) (discussing a need for a 
case-by-case analysis of hybrids, such as diverse interests in LLCs, under Howey). 
 28. William Hinman, Dir., Div. of Corp. Fin., SEC, Digital Asset Transactions: When Howey 
Met Gary (Plastic) (June 14, 2018), https://www.sec.gov/news/speech/speech-hinman-061418 
[hereinafter Hinman Speech] (“[T]he analysis of whether something is a security is not static and 
does not strictly inhere to the instrument.”); Nikhilesh De & Mahishan Gnanaseharan, SEC Chief 
Touts Benefits of Crypto Regulation, COINDESK (Apr. 5, 2018, 4:16 PM), 
https://www.coindesk.com/sec-chief-not-icos-bad; Cohen, supra note 9, at 102–06; Joseph H. 
Nesler, When it Comes to Analyzing Utility Tokens, the SEC Staff’s “Framework for ‘Investment 
Contract’ Analysis of Digital Assets” May Be the Emperor Without Clothes (Or, Sometimes an 
Orange Is Just an Orange) (Part I), WINSTON & STRAWN LLP: CRYPTO LAW CORNER (Oct. 28, 
2019), https://www.winston.com/en/crypto-law-corner/index.html.  See also REGULATING 
BLOCKCHAIN: TECHNO-SOCIAL AND LEGAL CHALLENGES 253 (Phillip Hacker, Ioannis Lianos, 



  

2020]   A CONCEPTUAL FRAMEWORK FOR DIGITAL-ASSET SECURITIES 173 

“evaluated on the basis of the content of the instruments in question, the 
purposes intended to be served, and the factual setting,”29 a project that 
started off as an investment could be reevaluated and transform into a non-
security.  In that case, some elements of the Howey test would no longer apply 
to a project or platform.30   

The U.S. District Court for the Southern District of New York 
elaborated on the third view in SEC v. Telegram Group, Inc.31  This March 
2020 decision, which granted a preliminary injunction at the SEC’s request, 
held that the same security can be distributed to the Public Token-Holders by 
the Initial Investors acting as “underwriters.”32  The affiliated hypothesis is 
that there is a single financial instrument—a digital token—that is sold 
throughout this securities distribution scheme.  Similarly, in Kik Interactive, 
the Southern District of New York articulated a somewhat similar position 
by suggesting that 

Purchasers in the two sales [, a private placement of securities and 
a public sale of tokens,] received the same class of securities, 
fungible Kin that were equal in value.  It is true that they received 
them via different instruments with different rights.  However, the 
ultimate result was distribution of identical assets.33  
This Article seeks to resolve these issues by offering a workable 

framework that can assist factfinders, regulators, and market participants in 
determining when a relationship involving securities ends and commodity 
trading and use begins, as well as the parties involved.  Whereas digital assets 
can be securities, they also may be commodities or something else entirely.34  
Investment contracts are not cryptocurrency-commodities;35 and 

 
Georgios Dimitropoulos & Stefan Eich, eds., 1st ed. 2019) (comparing the Hinman Speech and the 
SAFT approach). 
 29. Marine Bank v. Weaver, 455 U.S. 551, 560 n.11 (1982) (“Each transaction must be 
analyzed and evaluated on the basis of the content of the instruments in question, the purposes 
intended to be served, and the factual setting as a whole.”). 
 30. See, e.g., THE SEC FRAMEWORK, supra note 3, at 5 (listing, inter alia, the following 
questions: “Whether or not the efforts of an AP, including any successor AP, continue to be 
important to the value of an investment in the digital asset.  Whether the network on which the 
digital asset is to function operates in such a manner that purchasers would no longer reasonably 
expect an AP to carry out essential managerial or entrepreneurial efforts.  Whether the efforts of an 
AP are no longer affecting the enterprise’s success.”). 
 31. Court Order, supra note 10. 
 32. See id. at *3; 15 U.S.C. § 77b(a)(11).  
 33.  SEC v. Kik Interactive, No. 19 Civ. 5244 (AKH), 2020 WL 5819770, at *8 (S.D.N.Y. 
2020). 
 34. See Chamber’s Brief, supra note 6, at 9 (“Because a digital asset is merely an electronic 
record, the digital asset may be data that represents a security, a commodity, or something else.”); 
see also infra Section B. 
 35. See, e.g., SEC v. Koscot Interplanetary, Inc., 497 F.2d 473, 475 (5th Cir. 1974); Sinva, Inc. 
v. Merrill, Lynch, Pierce, Fenner & Smith, Inc., 253 F. Supp. 359, 367 (S.D.N.Y. 1966).  



  

174 MARYLAND LAW REVIEW [VOL. 80:166 

cryptocurrencies native to open source decentralized blockchains, similar to 
the one at issue in Telegram, are typically considered commodities, not 
securities.36  Conflating distinct asset classes—commodities and 
securities37—may entail doctrinal inconsistencies and adverse market 
consequences, such as restricting beneficial innovation,38 as well as blur the 
jurisdictional boundaries between the SEC’s regulation of securities and the 
Commodity Futures Trading Commission’s (“CFTC”) oversight of 
commodity markets.39   

This Article develops as follows.  Section B reviews the taxonomy of 
digital assets and offerings.40  It also lays out the two-stage process implicated 
by cryptoasset capital raising.  Section C examines an example of the two-
stage process—the Telegram case.41  Section D applies the two-stage 
framework to other examples of non-native and native tokens.42  Section E 
discusses equity-like crypto-instruments used in decentralized autonomous 
organizations, including The DAO and MakerDAO.43  Section F emphasizes 
the major concerns inherent during the project development phase and makes 

 
 36. Court Order, supra note 30, at *3–4 (“In the abstract, an investment of money in a 
cryptocurrency utilized by members of a decentralized community connected via blockchain 
technology, which itself is administered by this community of users rather than by a common 
enterprise, is not likely to be deemed a security under the familiar test laid out in S.E.C. v. W.J. 
Howey Co. . . . .  The SEC, for example, does not contend that Bitcoins transferred on the Bitcoin 
blockchain are securities.”); Press Release, Commodity Futures Trading Commission, Release 
Number 8051-19 (Oct. 10, 2019), https://www.cftc.gov/PressRoom/PressReleases/8051-19; see 
also Commodity ";"""date"",""2021-01-14T00:26:47Z""
""pdf:PDFVersion"",""1.7""
""xmp:CreatorTool"",""Appligent pdfHarmony 2.0""
""pdf:docinfo:title"",""A Conceptual Framework for Digital-Asset Securities: Tokens and Coins as Debt and Equity""
""Appligent"",""pdfHarmony 2.0 Linux Kernel 2.6 64bit Mar 13 2012 Library 9.0.1""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""Digital Assests"",""Digital Assests""
""language"",""en""
""dc:format"",""application/pdf; version=1.7""
""pdf:docinfo:creator_tool"",""Appligent pdfHarmony 2.0""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""A Conceptual Framework for Digital-Asset Securities: Tokens and Coins as Debt and Equity""
""xmp:CreateDate"",""2021-01-13T16:26:47Z""
""modified"",""2021-01-14T00:26:47Z""
""pdf:hasMarkedContent"",""true""
""xmp:ModifyDate"",""2021-01-13T16:26:47Z""
""pdf:docinfo:creator"",""Yuliya Guseva""
""meta:author"",""Yuliya Guseva""
""meta:creation-date"",""2021-01-14T00:26:47Z""
""created"",""2021-01-14T00:26:47Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2021-01-14T00:26:47Z""
""resourceName"",""viewcontent.cgi""
""Author"",""Yuliya Guseva""
""producer"",""Prince 12.5 (www.princexml.com)""
""pdf:docinfo:producer"",""Prince 12.5 (www.princexml.com)""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""Keywords"",""Digital Assests"",""Digital Assests""
""access_permission:modify_annotations"",""true""
""dc:creator"",""Yuliya Guseva""
""dcterms:created"",""2021-01-14T00:26:47Z""
""Last-Modified"",""2021-01-14T00:26:47Z""
""dcterms:modified"",""2021-01-14T00:26:47Z""
""pdf:docinfo:custom:Appligent"",""pdfHarmony 2.0 Linux Kernel 2.6 64bit Mar 13 2012 Library 9.0.1""
""title"",""A Conceptual Framework for Digital-Asset Securities: Tokens and Coins as Debt and Equity""
""xmpMM:DocumentID"",""uuid:6844920e-b04d-11b2-0a00-90b254010000""
""Last-Save-Date"",""2021-01-14T00:26:47Z""
""pdf:docinfo:keywords"",""Digital Assests""
""pdf:docinfo:modified"",""2021-01-14T00:26:47Z""
""meta:save-date"",""2021-01-14T00:26:47Z""
""Content-Length"",""851561""
""Content-Type"",""application/pdf""
""xmp:MetadataDate"",""2021-01-13T16:26:47Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Yuliya Guseva""
""dc:language"",""en""
""pdf:producer"",""Prince 12.5 (www.princexml.com)""
""dc:subject"",""Digital Assests"",""Digital Assests""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""49""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""914"",""3086"",""3117"",""4441"",""3954"",""3946"",""3098"",""3714"",""3255"",""3491"",""2727"",""3004"",""3091"",""3064"",""3118"",""4058"",""3414"",""3438"",""3863"",""3164"",""3448"",""2894"",""2502"",""3003"",""2953"",""4088"",""3087"",""3745"",""2710"",""3544"",""3566"",""3341"",""2789"",""2966"",""2749"",""2912"",""2827"",""3194"",""3097"",""2915"",""3059"",""3246"",""2936"",""3177"",""3396"",""3601"",""3292"",""3228"",""216""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""meta:keyword"",""Digital Assests"",""Digital Assests""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2021-01-14T00:26:47Z""
";https://scholar.google.ch/scholar?start=850&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098809-207;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Guest editorial: Blockchain and the multinational enterprise: Progress, challenges and future research avenues;R Torres de Oliveira, M Indulska… ; Review of International …, 2020  eprints.qut.edu.au;;"… In China alone, by the end of March 2020, a total of 35 MNEs (including Microsoft, Oracle,

Mastercard, Sony, Intel and Walmart) … of technological expertise in blockchain) … cryptocurrency,

enabling peer-to-peer transactions without intermediaries (commercial …";Cité 1 fois;;[PDF] qut.edu.au;https://eprints.qut.edu.au/205605/1/Blockchain_and_the_multinational_enterprise.pdf;"
This may be the author’s version of a work that was submitted/accepted
for publication in the following source:

Torres de Oliveira, Rui, Indulska, Marta, & Zalan, Tatiana
(2020)
Blockchain and the multinational enterprise: Progress, challenges and fu-
ture research avenues.
Review of International Business and Strategy, 30(2), pp. 145-161.

This file was downloaded from: https://eprints.qut.edu.au/205605/

cŠ Emerald Publishing Limited 2020

This work is covered by copyright. Unless the document is being made available under a
Creative Commons Licence, you must assume that re-use is limited to personal use and
that permission from the copyright owner must be obtained for all other uses. If the docu-
ment is available under a Creative Commons License (or other specified license) then refer
to the Licence for details of permitted re-use. It is a condition of access that users recog-
nise and abide by the legal requirements associated with these rights. If you believe that
this work infringes copyright please provide details by email to qut.copyright@qut.edu.au

License: Creative Commons: Attribution-Noncommercial 4.0

Notice: Please note that this document may not be the Version of Record
(i.e. published version) of the work. Author manuscript versions (as Sub-
mitted for peer review or as Accepted for publication after peer review) can
be identified by an absence of publisher branding and/or typeset appear-
ance. If there is any doubt, please refer to the published source.

https://doi.org/10.1108/RIBS-06-2020-153

https://eprints.qut.edu.au/view/person/Torres_de_Oliveira,_Rui.html
https://eprints.qut.edu.au/205605/
https://doi.org/10.1108/RIBS-06-2020-153


1 

Blockchain and the multinational enterprise: Progress, challenges, and future research 

avenues 

Purpose: Blockchain technology has the potential to significantly impact, both in positive 

and negative terms, the way business operates. While it is still considered to be in the 

relatively early stages of adoption, numerous applications of the technology have been 

adopted in a variety of fields, from finance to agriculture. Yet, little attention has been paid to 

this technology in the international business literature – despite its potential impacts. Thus, 

the purpose of this paper is to introduce the topic of blockchain and explain how the 

implications on international business, namely to online transactions, micropayments and 

cryptocurrencies, privacy and anonymity, trust, and business processes and business models. 

Furthermore, we introduce the contributions to the special issue and push forward a research 

agenda. 

Design/methodologies/approach: The paper is an introduction to a special issue and 

provides a viewpoint based on the authors’ research and reflection on the intersection 

between international business and blockchain technology. 

Findings: In this paper, we outline some of the critical implications of blockchain technology 

for the international business research field, introduce the three core contributions of this 

special issue, and present a research agenda to shape future research, namely in terms of 

future of global payments; future of global finance; future of the MNE; global value chain; 

United Nations Sustainable Development Goals and the multinationals; ecosystem 

development; deinstitutionalisation. 

Originality: We argue that it is time for international business scholars to take note of the 

technology and study its implications and uses. 

Keywords: Multinational Enterprise; Blockchains; International Business; Decentralised 

Ledger; Trust; Cryptocurrencies; Business Models.  



2 

Introduction 

In the last two decades, digital technologies have substantially changed the ways in which 

individuals and firms communicate and transfer knowledge, with wide-ranging implications 

for organisations and institutions. From an organisational perspective, the emergence of 

digital technologies has enhanced the materialisation of new business models (Foss and 

Saebi, 2017; Rachinger et al., 2019), the personalisation of products and services (Cenamor 

et al., 2017), the relation of trust between market agents and asymmetries of information 

(Urena et al.,  2019), new products and services (Matt et al.,  2015), and the pace of product 

life-cycles (Seetharaman et al., 2018), to name a few.  This digital transformation has far-

reaching implications for organisations but is particularly important to multinational 

enterprises (MNEs) as it allows them to reduce the liability of foreignness (Johanson and 

Vahlne, 2009), enhance knowledge creation and improve knowledge transfer and learning 

(Gaur et al., 2019), augment trust-building (Monaghan et al., 2020), build agile global value 

chains (Kano et al., 2020), and improve the speed of internationalisation (Oviatt and 

McDougall, 1994). All this results in a reduction of uncertainties, and thus lowers the risk 

perception (Clarke and Liesch, 2017), which impels international commitment decisions. 

An important new technology with potential for significant and wide-ranging impacts 

is blockchain. With this technology it is now possible to, for example, transfer the ownership 

of physical assets, such as cars and real estate, stocks, bonds and money over the Internet 

through digital contracts (Andreesen, 2014). The changes that blockchain technology brings 

about leave academics, businesses and governments grappling with the consequences. 

Academic research has focussed on the economics of blockchains (e.g., Evans, 2014; 

Davidson et al., 2016) and blockchain use cases, especially in the financial, information and 

communications technology, and public sectors (BĂśhme et al., 2015; Friedlmaier et al., 2017; 

Tapscott and Tapscott, 2016). Because blockchain has multiple barriers to widespread 



3 

adoption (Iansiti and Lakhani, 2017), researchers have explored regulatory barriers to the 

adoption of cryptocurrencies and smart contracts (Caytas, 2017; Werbach and Cornell, 2017) 

as well as technical barriers, such as scalability, interoperability, performance and data 

privacy (Hileman and Rauchs, 2017; for a review see Yli-Huumo et al., 2016). Tapscott and 

Tapscott (2016) argue that blockchain constitutes an institutional innovation, the 

‘cryptoeconomy’ – an economic system not defined by geographic location, political 

structure or legal system, but which uses cryptographic techniques to incentivise appropriate 

behaviour of participants in place of using trusted third parties (Pilkington, 2016). From this 

perspective, blockchains are platforms for building economic coordination using distributed 

ledgers augmented with computational features, such as money (cryptocurrencies), 

programmable contracts (e.g., smart contracts) and organisations made of software (DAOs, or 

distributed autonomous organisations). Thus, blockchain technology is not only innovative 

but is also a building block for new forms of economic governance and socio-political order 

(Davidson et al., 2016). 

Despite the critical importance of digital technologies, such as blockchain, and 

organisations’ digital transformations, the international business (IB) literature has been slow 

to unpack the implications for organisations’ internationalisation motivations and processes.  

Furthermore, and more recently, the emergence of fully digital organisations, such as digital 

platforms (Uber or Airbnb), social media (Facebook or Twitter), e-commerce (Taobao) or 

financial services (TransferWise), are still very much a black box to IB literature. 

With this special issue, we aimed to uncover a small part of the necessary 

embracement that the IB field needs to achieve to be prepared to perform their societal role of 

informing managers, entrepreneurs, officials and other agents of change.  To do so, we look 

specifically at the implications of blockchain technology in the IB field.  While IB literature  

is lagging behind in the study of blockchain, MNEs are – and have been for some time – 



4 

actively exploring blockchain’s potential, particularly in the financial (Böhme et al., 2015), 

compliance (Anjum et al., 2017), healthcare (Mettler, 2016), data protection (Finck, 2018) 

and logistics (Hackius and Petersen, 2017) contexts.  In China alone, by the end of March 

2020, a total of 35 MNEs (including Microsoft, Oracle, Mastercard, Sony, Intel and Walmart) 

applied for 212 blockchain-related patents (Global Times, 2020).  As explained elsewhere 

(Finextra, 2017), banking and finance now account for some 30% of blockchain use cases, 

and nearly 70% of central banks are experimenting with blockchain technology.  

Entrepreneurial start-ups and initial coin offerings – a form of crowdfunding made possible 

because of blockchain (see Kastelein, 2017) – have been the drivers behind an unprecedented 

surge of innovation, ranging from new, competing protocols (e.g., Tezos and EOS) to smart 

contracts on Ethereum, decentralised applications (e.g., Telegram), and new currencies with 

unique features (e.g., monero and zcash) (Vereckey, 2018).  Thus, and more than ever, we 

need to push the blockchain agenda and investigate its implications for IB. In the following 

sub-sections, we outline the key implications of blockchain technology in the context of IB.  

 

Blockchain and its implications for international business 

Online transactions, micropayments and cryptocurrencies 

One of the most obvious implications of blockchain adoption in IB transactions is lowering 

transaction costs and facilitating cross-border transactions at unprecedented speed (see Cao et 

al., 2017) without the need for intermediaries. Indeed, one of the most recent technological 

developments, the Baseline protocol (a consortium between Microsoft, EY and ConsenSys), 

built on the Ethereum Mainnet, allows transactions to be settled in minutes instead of weeks.  

Micropayments (small amounts of money transferred electronically) are an integral 

part of a variety of industries in the modern global digital economy.  Mobile apps, 

subscription services, e-commerce stores and the Internet of Things (IoT) are just a few 



5 

examples of products and technologies that benefit from micropayment-enabling 

technologies (Rhodes, 2019; Lundqvist et al., 2017; Clohessy, 2019).  Although some MNEs 

are already using micropayments, it is generally considered more difficult to establish a 

sustainable business model when relying on these types of transactions because of high 

transaction costs. However, micropayments are a particularly attractive alternative in relation 

to collecting royalties for musicians and artists for work distributed online (Wright and De 

Filippi, 2015; Clohessy et al., 2019).  In addition, payments in the IoT-era using the 

traditional centralised payment approach do not work (IBM, 2015) – cryptocurrencies are a 

promising alternative to such micropayment applications.  

Cryptocurrencies also appear to be a viable alternative to fiat currencies in developing 

and troubled economies, such as Argentina and Venezuela, with implications for MNEs from 

or operating there. These economies, like others in emerging markets, suffer from high 

inflation rates, financial instability and overregulation of the economy (Haesly, 2016; 

Cifuentes, 2019).  In addition, there are increased risks that make currency control by 

governments or central banks more hazardous because of the spread of local corruption 

(Clegg, 2014). Cryptocurrencies open a door as a complementary structure to conventional 

finance that permits rational individuals to escape the consequences of political volatility.  

Moreover, cryptocurrencies may provide communities in developing countries with access to 

a micro and local financial infrastructure that would otherwise be inaccessible (Cifuentes, 

2019). 

 

Privacy and anonymity 

MNEs looking to leverage the peer-to-peer trustless structure of blockchain technology are 

often confronted with the difficult trade-off between transparency of transactions via public 

(permissioned) blockchains, such as Bitcoin and Ethereum, and privacy (ConsenSys, 2020). 



6 

One common argument against public blockchains is that enterprises, particularly those in 

highly regulated industries such as banking and health care, will face difficulty in complying 

with regulations.  New technologies (e.g., advanced cryptography using zero-knowledge 

proofs or ZKP) are being developed to allow institutions to transact on public blockchains 

while still protecting sensitive customer data (Amico, 2019). For example, the current 

COVID-19 global crisis has led many privacy advocates to point to blockchains as a solution 

to the privacy problem in relation to individual health data (e.g., patient geolocation and 

medical test data). As cryptography is the backbone of blockchain technology, a sophisticated 

encryption protocol (e.g., ZKP) is expected to address the problem of public blockchain 

privacy and security. Easily implementable protocols for smart contracts pooling transactions 

together to anonymise transactions can also help address privacy concerns.  

Privacy and anonymity will enhance the use of blockchains for compliance and 

auditing. Indeed, if institutions allow the adoption of blockchain technology for compliance 

and auditing purposes, MNEs can create a technological base that can be used across 

different markets with relevant savings and risk mitigation. Compliance and auditing are 

increasing challenges for MNEs due to the complex structures of crisscrossing intercompany 

transactions in cross-country jurisdictions (Zhang et al., 2018), and are two of the main risks 

that senior managers point to (KPMG, 2020).  However, there are advanced blockchain 

solutions that can help solve the compliance and audit problem for MNEs, which work across 

multiple jurisdictions (Zhang et al., 2018) and that, when privacy and anonymity are secured, 

can be widely implemented. 

 

Trust 

Trust is fundamental to achieving efficient mechanisms in market exchanges or transactions. 

Institutional trust – the legal, political and social systems that support the monitoring and 



7 

sanctioning of human behaviour – is perhaps the most important element of trust (Zucker, 

1986). The modern global economy is built on compounding layers of trust: we trust tech 

giants, banks, insurance companies and governments (Samani, 2019). Enormous resources 

currently go into generating trust, which makes trust-based systems rather expensive 

(Fairfield, 2014). Given global complexity, detecting abuses of trust has become more 

difficult than ever (e.g., recall the Facebook and Cambridge Analytica data privacy breach). 

For the first time in human history, by using open networks bound by cryptography and free-

market economics, specific human behaviours can be incentivised without creating new trust 

assumptions (Samani, 2019) or relying on expensive trust-based systems. 

The magic of blockchain technology is to make certain activities trustworthy without 

the need to trust anyone in particular (Fairfield, 2014) – creating “trustless trust” and 

dispensing with costly intermediation and legal enforcement (Werbach, 2018).  Instead of 

trusting banks, courts and governments, it is possible to trust math and computation in the 

form of open-source cryptographic protocols (see Werbach, 2018).  Blockchain design will 

provide individuals with a sense of security and protection from hacking so that trust is 

implicitly provided (Vaz and Brown, 2018). 

Furthermore, all global systemic risk (for example, the risk of an entire financial 

system collapsing) is built on trust. Systemic risk and the potential for catastrophic failure 

appear to be, unfortunately, a feature of the large-scale systems enabling modern life. Apart 

from the systemic financial risks, other systemic risk systems include epidemics, species 

extinction, power grids and global communication. By creating a world with fewer trust 

assumptions, particularly compliance with multiple jurisdictions for MNEs, through the use 

of blockchain, we can reduce systemic risk and ultimately create healthier and more 

productive economies and societies (Samani, 2019). For example, in the current COVID-19 

crisis, if the World Health Organisation had a blockchain where any authorised health worker 



8 

could deposit information on a new virus, disease or other potential critical hazards to 

populations, this information would be stored and could be used to more easily and at greater 

speed to trace not only the origins but also to help understand the potential risks of high 

spread.   

 

Business processes and business models  

MNE business processes, such as new product development and knowledge management, can 

be a source of competitive advantage (see Buckley and Carter, 1999), and several MNEs are 

today using blockchain to improve their intra- and inter-organisational business processes. 

For example, global firms routinely spend hundreds of millions of dollars on customer 

relationship management, enterprise resource planning and supply chain management 

systems, as well as on other internal record systems. In an effort to drive operational 

efficiencies, existing processes are simplified and costs are taken out of existing processes by 

removing intermediaries or the administrative effort of record-keeping and transaction 

reconciliation (Carson et al., 2018). Other business process improvements include 

standardisation, increased efficiency and transparency, and eliminating errors, fraud, 

duplication and waste. For example, TradeLens, the global blockchain shipping platform (a 

consortium which includes IBM, Maersk Line and Standard Chartered), seeks to provide its 

users with a secure and real-time exchange of supply chain data and paperwork. Initiatives 

such as these are bound to redefine the nature of the international trade ecosystem, 

characterised by complex processes, slow turnaround times, manual documentation, mistrust 

between agents and limited connectivity between the various parties involved (Huillet, 2020). 

Even more importantly, blockchain (combined with machine learning) can power new 

digital business models built on the Internet. While the Internet started as an open, 

decentralised network, over time, we saw large centralised digital companies – particularly 



9 

Google, Apple, Facebook and Amazon – emerge to dominate the Internet landscape (Dixon, 

2018; Evans, 2019). However, while customers gained access to path-breaking technologies, 

this stifled innovation and created broad societal tension (e.g., with fake news and state-

sponsored bots) (Dixon, 2018). We are now starting to see the rise of novel business models 

(community-governed, decentralised digital ecosystems powered by tokens); decentralised 

finance (DeFi), decentralised computation and decentralised storage are some examples. 

These tokens, the fifth protocol of the Internet, will be used to exchange value, verify 

contracts, and track identity and reputation, among other things (Ravikant, 2014). It is likely 

that we will see a rise of a new breed of MNEs that may co-exist with centralised platforms. 

 

Contributions to the special issue 

We now turn our attention to the three papers that constitute this special issue. Blockchain is, 

in itself, an emerging topic for firms and business academia.  A search of the Financial 

Times’ top journals on April 14, 2020, with the word blockchain resulted in only 54 items, 

the large majority being in information systems (17) journals and Harvard Business Review 

(14), with only five manuscripts in academic management journals and none in the IB field.  

For context, a truncated artificial intelligence search resulted in 1,035 items.  The relative 

lack of blockchain research in these journals motivated us to organise this special issue. We 

were very fortunate with the range of articles we received, and the three papers accepted 

cover a wide range of perspectives at the intersection of IB and blockchain technology. 

Before we explore the underlying themes and highlight the future avenues that result from the 

articles, we first summarise each article’s contribution. 

Hasan and colleagues (2020) draw on panel data from the Shanghai, Shenzhen and 

Hong Kong stock exchanges between 2014 and 2018 to evaluate the effect that blockchain 

technology has had on firms’ operational efficiency. Grounding their study in transactional 



10 

cost analysis (Williamson, 1975) and the problems associated with contracting and the 

asymmetry of information, the authors were interested in how blockchain could be used to 

decrease operational costs and, thus, increase operational efficiency, and how an incremental 

versus big bang approach to blockchain implementation changes the operational efficiency.  

Their results show that blockchain implementation has a positive and significant impact on 

improving firms’ operational efficiency and that an incremental implementation approach to 

blockchain has better operational efficiency when compared with a big bang approach.  

These results, and the fact that younger and smaller firms have better operational efficiency 

results when implementing blockchain technology in their operations compared with older 

and larger ones, indicates that blockchains require time and openness to new approaches and 

are easier to implement in less complex organisations.  

Hooper and HoltbrĂźgge (2020) used a multitude of sources to build case studies that 

exemplify how blockchain is being used in MNEs and the main challenges and implications 

for global governance associated with such blockchain implementation.  They were 

particularly interested in international finance, banking and insurance, international supply 

chain management and logistics, and international marketing and advertising.  Using the 

functions of global governance as their lens to understand the effect of blockchain application 

on MNEs, the authors uncovered some intriguing phenomena.  The case studies explain how 

blockchains can be used to improve property rights and data privacy and, at the same time, be 

used for recordkeeping and reporting. The ability of blockchain technology to impact social 

welfare, namely by improving consumers’ trust and satisfaction, is another positive result.  

The authors’ results also explain that smart contracts might prevent monopolistic power, 

which is particularly important for IB literature because multinationals – frequently large and 

well-resourced – often work with local small and medium enterprises (SMEs) in a non-even 

power relationship (Buckley, 2009).  Regardless of the advantages of blockchain technology, 



11 

the authors caution against the dark side of blockchain applications and usage.  The lack of 

blockchain standards among industries or networks, energy consumption, and the fact that 

blockchains can serve to cover up illicit operations should carry weight in global governance 

decisions. To this end, the important distinction between public and private blockchain 

technology emerges as it has important implications and considerations for the potential use 

of blockchains for unethical and illegal operations. 

In the final article of this special issue, Tsiulin and colleagues (2020) build a 

conceptual framework following a systematic review of the academic and grey literature 

along with project reviews in shipping and port management.  The authors found three main 

contexts where blockchain is being used: document workflow management, device 

connectivity and financial processes.  For workflow management, the authors found that due 

to the overall and well-known constraints that global value chains (GVCs) face (namely in 

terms of lack of trust, miscommunication, information security and data falsification), 

blockchain technology is indeed a feasible and interesting solution that is already being 

adopted by several companies.  Furthermore, the authors explain that even for internal 

handling of documents in ports, blockchains can be used to improve trailer and container 

security and flow, and port gate queuing, among others.  For financial processes, the authors 

discuss the usage of cryptocurrency and the benefits to the industry but also the constraints 

that they face from institutions.  Finally, the authors discuss the implementation of IoT on 

containers, for example, and how blockchains can be used to trace and improve the security 

of goods.  However, and interestingly, none of the projects analysed used all three contexts.  

The authors also found that the academic literature, particularly when using blockchains to 

solve GVC problems, is falling behind industry creation and implementation of blockchain 

solutions, inviting us to look ahead and explore how academic guidance can be used to 

inform practitioners and policymakers.   



12 

Some common themes emerged from the three papers accepted to this special issue. 

We used them to frame our next section, which considers future research, as well as to 

complement the discussion and contributions from each individual manuscript. 

Before we move towards a research agenda, it is worth noting that these three articles 

reflect a multitude of methodological approaches that span from longitudinal panel data, to 

case studies, and systematic literature and project reviews.  This methodological diversity, 

even within three papers, indicates the broad epistemological approach that blockchain 

technology is having in the managerial field of academia, which represents an expansion 

from a very technical field to a broader nature that welcomes qualitative research and 

abstractive reasoning that might lead to new theories or even fields, as we further discuss 

below. 

 

International business and blockchain: Towards a research agenda 

Future of global payments  

In 1999, Nobel Prize winner Milton Friedman remarked in an interview that the Internet was 

poised to become one of the major forces reducing the role of government (Friedman, 1999). 

The only thing missing, but which would soon be developed, was reliable e-cash, a method 

whereby one could transfer funds from A to B on the Internet without A knowing B or B 

knowing A. Nakamoto’s invention in 2008 made this idea possible. Today, many remain 

sceptical about digital currencies, citing large energy needs, technological limitations (e.g., 

scalability, cross-platform integration and security) and regulatory hurdles. Yet, if the growth 

in blockchain-wallet users continues to mirror that of Internet users then, by the end of the 

decade, they will number some 200 million – quadruple the current level. This growth will be 

encouraged by governments, banks, corporates and payment providers who all stand to 

benefit from the digitalisation of payments (Deutsche Bank, 2020).  As Bitcoin and other 



13 

freely floating cryptocurrencies continue to exhibit extreme volatility relative to fiat 

currencies, there has been a much greater focus on stablecoins (i.e., price-stable coins) – a 

coin pegged to another cryptocurrency, a fiat currency or a commodity – designed to 

minimise these price fluctuations (J.P. Morgan, 2020).  In late 2019, the Chinese Government 

stated that the People’s Bank of China would be launching a PBoC digital currency, possibly 

by the end of 2020, thus becoming the first major economy to use a fully government-backed 

digital currency (which will most likely be a cryptocurrency, given China’s interest and depth 

of technological expertise in blockchain). Other central banks may follow to adopt a 

cryptocurrency, enabling peer-to-peer transactions without intermediaries (commercial 

banks) and in the absence of trust. In addition, many central banks have started to seriously 

examine a supranational multi-currency-backed token as a replacement global reserve asset 

(J.P. Morgan, 2020).  

Stablecoins, in particular, seem to be gaining traction, and not just for speedy transfers 

between exchanges but for business transactions by e-commerce marketplaces, advertising 

networks, luxury goods producers, recruiting platforms, digital content markets and software 

firms. This implies significant global demand from SMEs seeking the safety and utility of 

digital dollars (De, 2020). Factors that facilitate or hinder adoption of digital and 

cryptocurrencies as well as stablecoins – nationally and globally – will continue to be a 

fascinating topic for further research in IB.  

 

Future of global finance 

Centralised finance cannot be truly borderless as it is tied to specific geographic locations 

with specific fiat currencies, so moving capital and value across borders often encounters 

friction and delay (Chen and Bellavitis, 2020). In contrast, DeFi – access to financial 

applications in a truly decentralised and censorship-resistant environment – is inherently 



14 

borderless; hence, transferring value across the globe may become as easy as sending an 

email (Chen and Bellavitis, 2020).  DeFi, at its core, includes infrastructure, markets, 

technology, methods and applications, enabling the decentralised provision of financial 

services (Zetzsche et al., 2020). More specifically, it includes open protocols, public smart 

contract platforms (such as the Ethereum blockchain), decentralised exchanges, stablecoins 

and decentralised applications (dApps) (Schar, 2020). It is still a niche market (compared to 

traditional finance) with relatively low volumes, but the value of the market (i.e., reserves 

locked into smart contracts) has been growing rapidly.  

DeFi has unleashed a wave of innovation in the form of trustless versions of 

traditional financial instruments as well as entirely new financial instruments (e.g., atomic 

swaps, autonomous liquidity pools, flash loans) built on public blockchains (mostly 

Ethereum).  Schar (2020) believes that DeFi constitutes a paradigm shift in the financial 

industry and could potentially contribute towards a more robust and transparent financial 

infrastructure. While neobanks and fintech firms are offering customers more control of their 

assets, they remain intermediaries to be trusted; by contrast, DeFi infrastructure offers full 

control of assets due to decentralisation inherent in blockchain technology.  

If the promise of DeFi materialises, then worldwide participation (regardless of social 

status) will be possible. A particularly exciting topic for IB researchers would be to explore 

the socio-economic implications of DeFi for the global financial system.  

 

Future of the MNE  

Today, the vast majority of economic activity is conducted via corporations – inventions 

from the 1400s. Back then, they were joint-stock companies, and innovations such as capital 

structures and limited liability followed. The world’s first MNEs started to appear in the early 

1600s and, yet, the fundamental premise of the corporation as the facilitator of economic 



15 

activity remains largely unchanged (Samani, 2020). Nakamoto’s Bitcoin invention was not 

only a significant technological breakthrough but also an institutional innovation. It became 

feasible to organise large-scale economic activity and coordinate human behaviour without 

the need for a centralised corporation (unlike other digital platforms such as Uber or Airbnb). 

Such collaboration in a trustless environment is possible because of the encoding of 

consensus mechanisms, incentives (and disincentives) and contracts built into software (Allen 

et al., 2020; Samani, 2020).  

Indeed, many scholars (Davidson et al., 2018; De Filippi and Loveluck, 2016; Allen 

et al., 2020) consider public blockchains (such as Bitcoin or Ethereum) an institutional 

technology where management and governance are distributed across a large number of 

token holders, block validators and developers. The primary effects of institutional 

technologies such as blockchain are, according to Allen et al. (2020), transaction costs of 

economic coordination and governance within a network of economic agents.  

Decentralised networks built on blockchain can and will provide a wide variety of 

digital services (e.g., storage, computation, ap";"""date"",""2021-04-21T07:28:22Z""
""pdf:unmappedUnicodeCharsPerPage"",""1"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.5""
""xmp:CreatorTool"",""pdftk 2.02 - www.pdftk.com""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dcterms:created"",""2021-04-21T07:28:22Z""
""language"",""en""
""Last-Modified"",""2021-04-21T07:28:22Z""
""dcterms:modified"",""2021-04-21T07:28:22Z""
""dc:format"",""application/pdf; version=1.5""
""Last-Save-Date"",""2021-04-21T07:28:22Z""
""pdf:docinfo:creator_tool"",""pdftk 2.02 - www.pdftk.com""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2021-04-21T07:28:22Z""
""meta:save-date"",""2021-04-21T07:28:22Z""
""pdf:encrypted"",""false""
""modified"",""2021-04-21T07:28:22Z""
""Content-Length"",""355153""
""pdf:hasMarkedContent"",""false""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""meta:creation-date"",""2021-04-21T07:28:22Z""
""created"",""2021-04-21T07:28:22Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""35""
""Creation-Date"",""2021-04-21T07:28:22Z""
""resourceName"",""Blockchain_and_the_multinational_enterprise.pdf""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""1302"",""1923"",""2163"",""2179"",""2102"",""1967"",""2006"",""2167"",""2003"",""2087"",""2225"",""2160"",""1968"",""1993"",""2044"",""2095"",""1985"",""2109"",""2043"",""1847"",""1977"",""2069"",""1755"",""657"",""1587"",""1727"",""1581"",""1707"",""1609"",""1648"",""1810"",""1642"",""1721"",""1570"",""1286""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""producer"",""itext-paulo-155 (itextpdf.sf.net-lowagie.com)""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""itext-paulo-155 (itextpdf.sf.net-lowagie.com)""
""pdf:docinfo:created"",""2021-04-21T07:28:22Z""
";https://scholar.google.ch/scholar?start=750&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098826-249;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;[HTML][HTML] Minimizing Key Materials: The Even–Mansour Cipher Revisited and Its Application to Lightweight Authenticated Encryption;P Zhang, Q Yuan ; Security and Communication Networks, 2020  hindawi.com;United Kingdom;"The Even–Mansour cipher has been widely used in block ciphers and lightweight

symmetric-key ciphers because of its simple structure and strict provable security. Its research

has been a hot topic in cryptography. This paper focuses on the problem to minimize the key …";Autres articles;;[HTML] hindawi.com;https://www.hindawi.com/journals/scn/2020/4180139/;"[image: logo]
	Journals
	Publish with us
	Publishing partnerships
	About us
	Blog




Security and Communication Networks
+Journal Menu
[image:  ]PDF[image:  ] 
    
     Icons/Arrow Right White
     Created with Sketch.
     
         
    
     
         
             
                 
                     
                         
                             
                                 
                            
                             
                             
                                 
                            
                        
                    
                
            
        
    



Journal overview
For authorsFor reviewersFor editorsTable of ContentsSpecial Issues
[image:  ]         

Submit






Security and Communication Networks / 2020 / Article
Article SectionsOn this page
AbstractIntroductionPreliminariesConclusionsData AvailabilityConflicts of InterestAcknowledgmentsReferencesCopyright


Special IssueTheoretical Aspects of Cryptography and Their Applications for Data Protection in Emerging 5G Systems
View this Special Issue

Research Article | Open Access
Volume 2020 |Article ID 4180139 | https://doi.org/10.1155/2020/4180139
Ping Zhang, Qian Yuan, ""Minimizing Key Materials: The Even–Mansour Cipher Revisited and Its Application to Lightweight Authenticated Encryption"", Security and Communication Networks, vol. 2020, Article ID 4180139, 6   pages, 2020. https://doi.org/10.1155/2020/4180139

Show citation
Minimizing Key Materials: The Even–Mansour Cipher Revisited and Its Application to Lightweight Authenticated Encryption


Ping Zhang[image:  ]   .cls-1{fill:#a6ce39;}.cls-2{fill:#fff;}.cls-3{fill:none;} orchid     

1 and Qian Yuan21School of Computer Science, Nanjing University of Posts and Telecommunications, Nanjing 210023, China
2School of Economics and Management, Southeast University, Nanjing 211189, China

Show more
Academic Editor: Andrea Visconti
Received12 Dec 2019
Accepted07 Feb 2020
Published10 Mar 2020


Abstract
The Even–Mansour cipher has been widely used in block ciphers and lightweight symmetric-key ciphers because of its simple structure and strict provable security. Its research has been a hot topic in cryptography. This paper focuses on the problem to minimize the key material of the Even–Mansour cipher while its security bound remains essentially the same. We introduce four structures of the Even–Mansour cipher with a short key and derive their security by Patarin’s H-coefficients technique. These four structures are proven secure up to  adversarial queries, where k is the bit length of the key material and μ is the maximal multiplicity. Then, we apply them to lightweight authenticated encryption modes and prove their security up to about -bit adversarial queries, where b is the size of the permutation and c is the capacity of the permutation. Finally, we leave it as an open problem to settle the security of the t-round iterated Even–Mansour cipher with short keys.
1. Introduction
In recent years, more and more attention has been paid to lightweight cryptography as smart home, Internet of things (IoT), smart transportation, and 5G/B5G networks are proposed. These new technologies brought convenience to our lives but have introduced a powerful security threat, such as the leakage of the private data in our smart phone. Lightweight cryptography is an effective countermeasure against the security threats in order to achieve the privacy and integrity protections of the sensitive data. Lightweight cryptography is mainly used in resource-constrained devices. The block cipher has become a very vital lightweight symmetric-key cryptography, due to its fast speed, easy implementation, and easy standardization on these devices. It is often used to implement sensitive data encryption, digital signature, message authentication, and key encapsulation schemes in the field of information security and network communication security.
The t-round iterated Even–Mansour cipher is simply described as a pure permutation-based block cipher:where  is a sequence of n-bit round keys which are usually derived from some master key and  is a sequence of t public random permutations. This iterated Even–Mansour cipher, also known as key-alternating ciphers, is of great significance in the design of block ciphers and is also favored in the design of lightweight cryptography. The security of the iterated Even–Mansour ciphers is based on the random permutation model (RPM). In RPM, all permutations are modeled as public random permutation oracles, in other words, anyone can query these permutations and obtain the corresponding responses. The related research includes [1–9].
This paper focuses on the case . Even and Mansour [10] did pioneering work in 1997 and proved that it is birthday-bound secure. That is where the name “Even–Mansour cipher” comes from. The Even–Mansour cipher has some very nice properties, such as simplest structure and strict provable security. Although the research of the Even–Mansour cipher went unnoticed for years, Gold will always shine. Fortunately, it has been a very hot topic in cryptography. In 2012, Dunkelman et al. [11] pointed out that the Even–Mansour cipher is minimal, i.e., any component (either one of the keys or the permutation) is removed; the Even–Mansour cipher becomes trivially breakable. In 2015, Cogliati et al. [12] introduced the tweakable Even–Mansour (TEM) cipher combined by the Even–Mansour cipher and a tweak, and proved its security. Meanwhile, Mouha and Luykx [13] revisited the Even–Mansour cipher and analyzed the multikey security. do Nascimento and Xexeo [14] applied the Even–Mansour cipher to the Internet of Things (IoT) environments and presented a flexible lightweight authenticated encryption mode in 2017. It follows that Cho et al. [15] presented a new family of white-box block ciphers based on the Even–Mansour cipher WEM which achieves balances between performance and security. Farshim et al. [16] analyzed the security of the Even–Mansour cipher under key-dependent messages. In 2018, we described a generalized tweakable Even–Mansour cipher and applied it to authentication and authenticated encryption modes [17].
In the lightweight devices, the storage resources are limited. Therefore, a vital issue is the minimalism and agility of the key material in the design of lightweight ciphers. In this paper, we revisit the Even–Mansour cipher and consider as problem whether we can use the least key material to achieve the same security bound. The Even–Mansour cipher is proven security up to approximately  adversarial queries, where k is the bit-length of the key material. Can we decrease the key material and achieve the same security bound (this bound must be beyond-birthday-bound)?
We answer positively to the question in this paper. We introduce four structures of the Even–Mansour cipher with a short key and present the provable security results. More concretely, we derive their security up to  adversarial queries using Patarin’s H-coefficients technique, where k is the bit-length of the reducing key material and μ is the maximal multiplicity. The Even–Mansour cipher with a short key has many good advantages, such as calculating on-the-fly, avoiding the key schedule, and minimizing the key material. Therefore, it can be widely applied to resource-constrained lightweight devices. Then, we apply its four structures to lightweight authenticated encryption (AE) modes and prove their security up to about -bit adversarial queries, where  is the size of the permutation and c (resp. r) is the capacity (resp. rate) of the permutation. Finally, we leave it as an open problem to settle the security of the t-round iterated Even–Mansour cipher with short keys.
The rest of this paper is organized as follows. In Section 2, we introduce some preliminaries. In Section 3, we prove the security of the Even–Mansour cipher with a short key. Section 4 describes lightweight AE modes based on four structures of the Even–Mansour cipher with a short key. Section 5 ends up with this paper.
2. Preliminaries
Let  be the set of binary strings of length b and . For two strings X and Y, let  or  be the concatenation of X and Y. Given a string X, we utilize  to denote the length in bits of X. Given a nonempty set X, let  denote an element x drawing from X uniformly at random and  be the cardinality of X. Let  stand for the set of permutations on . Let  be an event that an adversary  outputs 1 after interacting with the oracle O. Here,  never makes a query for which the response is obviously known. Let  be the probability that the event  occurs.
2.1. Multiplicity
Let  be a set of N evaluations of a permutation P, where , . We introduce the total maximal multiplicity as  inspired by [18], where
2.2. H-Coefficients Technique
H-coefficients technique introduced by Patarin [19] is a very important analytical method in the symmetric-key cryptography. We briefly summarize this technique as follows. Consider an information-theoretic adversary , whose goal is to distinguish a real world X and an ideal world Y and denote the distinguishing advantage of  as
Without loss of generality, we can assume that  is a deterministic adversary. The interaction with any of the two worlds X or Y is summarized in a transcript τ. Denote by  the probability distribution of transcripts when interacting with X, and similarly,  the distribution of transcripts when interacting with Y. A transcript τ is attainable if , meaning that it can occur during interaction with Y. Let  be the set of attainable transcripts. We denote  as a set of good transcripts when interacting with X (Y). Let  be a set of bad transcripts such that the probability to obtain any  is small in the ideal world .
Lemma 1 (H-coefficients lemma [19]). Fix a deterministic adversary . Let  be a partition of the set of attainable transcripts. Assume that there exists  such that for any , one hasand that there exists  such that
Then, the advantage of the adversary  is
3. The Even–Mansour Cipher with a Short Key
Fix a public permutation  and integers , such that  and . Let . The Even–Mansour cipher with a short key, called  for short, is described in Figure 1.  takes a uniform random key  and a plaintext  as inputs and outputs the ciphertext . Let  and . The four structures of EM are, respectively, shown as follows:
[image: (a)]
(a)
[image: (b)]
(b)
[image: (c)]
(c)
[image: (d)]
(d)

[image: (a)]
(a)[image: (b)]
(b)[image: (c)]
(c)[image: (d)]
(d)


Figure 1 
Four structures of EM.


We consider the security of the Even–Mansour cipher with a short key and obtain the following theorem.
Theorem 1. For  with  and , we have
The proof of Theorem 1 utilizes the H-coefficients technique. We consider an adversary  which can interact with  in the real world or  in the ideal world, where  are uniform random and independent permutations and K is a (dummy) key. We assume that the adversary  makes at most  construction queries and at most  primitive queries. The transcripts can be expressed as this form , where  and . We start by defining bad transcripts.
Definition 1. We define an attainable transcript  as bad if one of the two following conditions is fulfilled.  :  and , such that  :  and , such thatOtherwise we say that τ is good. We denote , resp.  the set of good, resp. bad transcripts, and .
In the real world X, a bad transcript implies that two invocations to P exist with the same input: one directly from querying the primitive oracle P and another one indirectly from querying the construction oracle , while all tuples in  uniquely determine an input-output pair of P for a good transcript. In the ideal world Y, the abovementioned result is clearly established for a bad transcript, while it is not for a good transcript.
We first upper bound the probability of bad transcripts in the ideal world Y by the following lemma.
Lemma 2. 
Proof. In the ideal world Y,  is an attainable transcript with a dummy uniform random key .
Here, we assume that an adversary  makes at most  construction queries and at most  primitive queries. For each  and each , we obtain at most  (resp. ) tuples  such that  for structures (a) and (b) or  for structures (c) and (d) (resp.  for structures (a) and (d) or  for structures (b) and (c)) from the property of multiplicity.
It follows that  and . Hence, the probability of bad transcripts in the ideal world Y is at most , where .
We then analyze good transcripts and lower bound the ratio .
Lemma 3. For any good transcript τ, one has
Proof. Consider a good transcript . Let  be a nonempty set of all possible oracles in the real world X and  be a nonempty set of all possible oracles in the ideal world Y. Therefore, the cardinalities of sets  and  are, respectively,  and . Let  and  be the two sets of oracles compatible with transcript τ. The probabilities appearing in Lemma 1 can be evaluated as follows:First, we calculate . As  consists of  query tuples and any query tuple in τ fixes exactly one input-output pair of the underlying permutation oracle, the number of possible oracles in the real world X equals .
Second, we calculate . The number of possible oracles in the ideal world Y equals , as P and Q are uniform random and independent permutations.
It follows thatTherefore, we have .
Combining Lemmas 1–3, we can obtain the result of Theorem 1.
4. Application to Lightweight Authenticated Encryption
With the rises of the smart home, IoT, and 5G/B5G networks, lightweight authenticated encryption (AE) modes are attracting more and more attentions [20–22]. A lightweight AE mode is a lightweight symmetric-key cipher which supports the services of privacy and authenticity of the sensitive data in the devices.
The Even–Mansour cipher with a short key can be directly applied to a lightweight AE mode, which is shown in Figure 2. It consists of an encryption algorithm E and a decryption algorithm D. The encryption algorithm E takes a plaintext M and a key K as inputs and returns a ciphertext C and an authentication tag T, i.e., . The decryption algorithm D takes a key K, a ciphertext C, and an authentication tag T as inputs and returns a plaintext M or a reject symbol , i.e., . If the last c-bit of the EM decryption is 0, then the decryption algorithm D returns M. Otherwise, the decryption algorithm D returns .
[image: (a)]
(a)
[image: (b)]
(b)
[image: (c)]
(c)
[image: (d)]
(d)

[image: (a)]
(a)[image: (b)]
(b)[image: (c)]
(c)[image: (d)]
(d)


Figure 2 
Lightweight authenticated encryption modes.


Let  stand for our lightweight AE modes. We introduce the AE-security model as follows.
Definition 2. (AE security). Let P be a public random permutation. Let  be a P-based AE scheme. Let  be an adversary which interacts with  in the real world or  in the ideal world. Let . Then, the AE-security of  is defined as follows:where q is the number of queries to the encryption oracle E or the decryption oracle D, p is the number of queries to the random permutation P or its inverse ,  is a random function which always returns a fresh and random response for each query, and  is a symbol which stands for the failure of the decryption oracles.
Theorem 2. Let  and . Then,
Proof Sketch. Let  be an adversary with access to the encryption oracle E, the decryption oracle D, and the random permutation P or its inverse .  can be represented as an EM scheme. We replace the EM modular structure to the random permutation Q. According to Theorem 1, we have
It follows thatwhere  obtained by the PRP-PRF Switch Lemma [23] and  is from the fact that the successful probability of the adversary is  for each forgery attempt.
Combining equations (19) and (20), it is easy to draw the result of Theorem 2.
According to Theorem 2, we can find that these lightweight AE modes ensure about -bit AE-security.
5. Conclusions
The key material is crucial for the secure implementation of cryptographic schemes. Most of devices widely used in smart home, smart transportation, and Internet of Things (IoT) environments are resource constrained. Therefore, in the design of lightweight ciphers, a vital issue is the minimalism and agility of the key material.
In this paper, we revisit the Even–Mansour cipher and discuss this problem whether we can use the least key material to achieve the same (even beyond conventional) security bound in the Even–Mansour cipher. We introduce four structures of the Even–Mansour cipher with a short key and derive security up to  adversarial queries, where k is the bits of the key material and μ is the maximal multiplicity, using Patarin’s H-coefficients technique. Then, we apply them to lightweight authenticated encryption modes and prove their security up to about -bit adversarial queries, where  is the size of the permutation and c is the capacity of the permutation. Finally, we leave it as an open problem to settle the security of the t-round iterated Even–Mansour cipher with short keys. The Even–Mansour cipher with a short key is proven -bit security. It is natural to consider whether our result can be generalized to the t-round iterated Even–Mansour cipher. But the situation of the t-round iterated Even–Mansour cipher with short keys is more complicated. Therefore, it is regarded as an open problem to attract scholars to discuss and analyze it in detail. The Even–Mansour cipher with a short key has many good advantages, such as calculating on-the-fly, avoiding the key schedule, and minimizing the area of the hardware implementation and the key material. Therefore, it can be widely applied to the data security of smart home, Internet of Things, and some lightweight devices.
Data Availability
The data used to support the findings of the study are available within the article.
Conflicts of Interest
The authors declare that they have no conflicts of interest.
Acknowledgments
This work was supported by the Research Fund of International Young Scientists (Grant no. 61902195), Natural Science Fund for Colleges and Universities in Jiangsu Province (General Program, Grant no. 19KJB520045), and NUPTSF (Grant no. NY219131).

References
	E. Andreeva, A. Bogdanov, Y. Dodis, B. Mennink, and J. P. Steinberger, “On the indifferentiability of key-alternating ciphers,” in Advances in Cryptology–CRYPTO 2013, Lecture Notes in Computer Science, R. Canetti and J. A. Garay, Eds., vol. 8042, pp. 531–550, Springer, Berlin, Germany, 2013. View at: Publisher Site | Google Scholar
	A. Bogdanov, L. R. Knudsen, G. Leander, FX. Standaert, J. Steinberger, and E. Tischhauser, “Key-alternating ciphers in a provable setting: encryption using a small number of public permutations,” in Advances in Cryptology–EUROCRYPT 2012, Lecture Notes in Computer Science, D. Pointcheval and T. Johansson, Eds., vol. 7237, pp. 45–62, Springer, Berlin, Germany, 2012. View at: Publisher Site | Google Scholar
	S. Chen, R. Lampe, J. Lee, Y. Seurin, and J. Steinberger, “Minimizing the two-round Even-Mansour cipher,” Journal of Cryptology, vol. 31, no. 4, pp. 1064–1119, 2018. View at: Publisher Site | Google Scholar
	S. Chen and J. Steinberger, “Tight security bounds for key-alternating ciphers,” in Advances in Cryptology–EUROCRYPT 2014, Lecture Notes in Computer Science, P. Q. Nguyen and E. Oswald, Eds., vol. 8441, pp. 327–350, Springer, Berlin, Germany, 2014. View at: Publisher Site | Google Scholar
	B. Cogliati and Y. Seurin, “On the provable security of the iterated Even-Mansour cipher against related-key and chosen-key attacks,” in Advances in Cryptology–EUROCRYPT 2015, Lecture Notes in Computer Science, E. Oswald and M. Fischlin, Eds., vol. 9056, pp. 584–613, Springer, Berlin, Germany, 2015. View at: Publisher Site | Google Scholar
	P. Farshim and G. Procter, “The related-key security of iterated Even-Mansour ciphers,” in Fast Software Encryption–FSE 2015, Lecture Notes in Computer Science, G. Leander, Ed., vol. 9054, pp. 342–363, Springer, Berlin, Germany, 2015. View at: Publisher Site | Google Scholar
	A. Hosoyamada and K. Aoki, “On quantum related-key attacks on iterated Even-Mansour ciphers,” IEICE Transactions on Fundamentals of Electronics, Communications and Computer Sciences, vol. E102.A, no. 1, pp. 27–34, 2019. View at: Publisher Site | Google Scholar
	T. Isobe and K. Shibutani, “Meet-in-the-middle key recovery attacks on a single-key two-round Even-Mansour cipher,” IEICE Transactions on Fundamentals of Electronics, Communications and Computer Sciences, vol. E102.A, no. 1, pp. 17–26, 2019. View at: Publisher Site | Google Scholar
	R. Lampe, J. Patarin, and Y. Seurin, “An asymptotically tight security analysis of the iterated Even-Mansour cipher,” in Advances in Cryptology–ASIACRYPT 2012, Lecture Notes in Computer Science, X. Wang and K. Sako, Eds., vol. 7658, pp. 278–295, Springer, Berlin, Germany, 2012. View at: Publisher Site | Google Scholar
	S. Even and Y. Mansour, “A construction of a cipher from a single pseudorandom permutation,” Journal of Cryptology, vol. 10, no. 3, pp. 151–161, 1997. View at: Publisher Site | Google Scholar
	O. Dunkelman, N. Keller, and A. Shamir, “Minimalism in cryptography: the Even-Mansour scheme revisited,” in Advances in Cryptology–EUROCRYPT 2012, Lecture Notes in Computer Science, D. Pointcheval and T. Johansson, Eds., vol. 7237, pp. 336–354, Springer, Berlin, Germany, 2012. View at: Publisher Site | Google Scholar
	B. Cogliati, R. Lampe, and Y. Seurin, “Tweaking even-mansour ciphers,” in Advances in Cryptology–CRYPTO 2015, Lecture Notes in Computer Science, R. Gennaro and M. Robshaw, Eds., vol. 9215, pp. 189–208, Springer, Berlin, Germany, 2015. View at: Publisher Site | Google Scholar
	N. Mouha and A. Luykx, “Multi-key security: the Even-Mansour construction revisited,” in Advances in Cryptology–CRYPTO 2015, Lecture Notes in Computer Science, R. Gennaro and M. Robshaw, Eds., vol. 9215, pp. 209–223, Springer, Berlin, Germany, 2015. View at: Publisher Site | Google Scholar
	E. M. do Nascimento and J. A. M. Xexeo, “A flexible authenticated lightweight cipher using Even-Mansour construction,” in Proceedings of the IEEE International Conference on Communications–ICC 2017, pp. 1–6, IEEE, Paris, France, May 2017. View at: Publisher Site | Google Scholar
	J. Cho, K. Y. Choi, I. Dinur et al., “WEM: a new family of white-box block ciphers based on the Even-Mansour construction,” in Cryptographers’ Track at the RSA Conference–CT-RSA 2017, Lecture Notes in Computer Science, H. Handschuh, Ed., vol. 10159, pp. 293–308, Springer, Berlin, Germany, 2017. View at: Publisher Site | Google Scholar
	P. Farshim, L. Khati, and D. Vergnaud, “Security of Even-Mansour ciphers under key-dependent messages,” The IACR Transactions on Symmetric Cryptology, vol. 2017, no. 2, pp. 84–104, 2017. View at: Google Scholar
	P. Zhang and H.-G. Hu, “Generalized tweakable Even-Mansour cipher and its applications,” Journal of Computer Science and Technology, vol. 33, no. 6, pp. 1261–1277, 2018. View at: Publisher Site | Google Scholar
	G. Bertoni, J. Daemen, M. Peeters, and G. Van Assche, “Sponge-based pseudo-random number generators,” in Cryptographic Hardware and Embedded Systems–CHES 2010, Lecture Notes in Computer Science, S. Mangard and FX. Standaert, Eds., vol. 6225, pp. 33–47, Springer, Berlin, Germany, 2010. View at: Publisher Site | Google Scholar
	J. Patarin, “The “coefficients H” technique,” in Selected Areas in Cryptography–SAC 2008, Lecture Notes in Computer Science, R. M. Avanzi, L. Keliher, and F. Sica, Eds., vol. 5381, pp. 328–345, Springer, Berlin, Germany, 2008. View at: Google Scholar
	A. Chakraborti, N. Datta, M. Nandi, and K. Yasuda, “Beetle family of lightweight and secure authenticated encryption ciphers,” IACR Transactions on Cryptographic Hardware and Embedded Systems, vol. 2018, no. 2, pp. 218–241, 2018. View at: Google Scholar
	G. Hatzivasilis, G. Floros, I. Papaefstathiou, and C. Manifavas, “Lightweight authenticated encryption for embedded on-chip systems,” Information Security Journal: A Global Perspective, vol. 25, no. 4–6, pp. 151–161, 2016. View at: Publisher Site | Google Scholar
	Y. Sasaki and K. Yasuda, “Optimizing online permutation-based AE schemes for lightweight applications,” IEICE Transactions on Fundamentals of Electronics, Communications and Computer Sciences, vol. E102.A, no. 1, pp. 35–47, 2019. View at: Publisher Site | Google Scholar
	M. Bellare and P. Rogaway, “The security of triple encryption and a framework for code-based game-playing proofs,” in Advances in Cryptology–EUROCRYPT 2006, Lecture Notes in Computer Science, S. Vaudenay, Ed., vol. 4004, pp. 409–426, Springer, Berlin, Germany, 2006. View at: Publisher Site | Google Scholar


Copyright
Copyright Š 2020 Ping Zhang and Qian Yuan. This is an open access article distributed under the   Creative Commons Attribution License, which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited.






More related articles




[image:  ]PDF[image:  ]         

Download Citation[image:  ]         

Citation

[image:  ]         

Download other formatsMore
ePub
[image:  ] 
    
     chevron-down copy 3
     Created with Sketch.
     
         
    
     
         
             
                 
                     
                         
                             
                                 
                            
                             
                             
                                 
                            
                        
                    
                
            
        
    


XML
[image:  ] 
    
     chevron-down copy 3
     Created with Sketch.
     
         
    
     
         
             
                 
                     
                         
                             
                                 
                            
                             
                             
                                 
                            
                        
                    
                
            
        
    



[image:  ] 
    
     align-left
     Created with Sketch.
     
         
    
     
         
             
                 
                     
                         
                             
                                 
                            
                             
                             
                                 
                            
                        
                    
                
            
        
    


Order printed copiesOrderViews346
Downloads368

Citations


Share Post
	[image:  ] 
    
     Twitter_Social_Icon_Circle_Color
     Created with Sketch.
     
         
             
                 
            
             
                 
            
        
    



	[image:  ]
	[image:  ]
	[image:  ]    




	[image:  ]        






Related articles






Follow us:[image:  ]  

[image:  ]  

[image:  ]   

[image:  ]  


	About us
	Contact us
	Partnerships
	Blog

	Journals
	Article Processing Charges
	Print editions

	Authors
	Editors
	Reviewers

	Hindawi XML Corpus
	Open Archives Initiative
	Fraud prevention

Follow us:[image:  ]  

[image:  ]  

[image:  ]   

[image:  ]  



Privacy Policy   |  Terms of Service   |  Responsible Disclosure Policy   |  Cookie Policy   |  Copyright 



        

";"""dc.publisher"",""Hindawi""
""og:image"",""https://images.hindawi.com/journals/scn/scn.banner.jpg""
""og:image:width"",""600""
""twitter:card"",""summary_large_image""
""citation_journal_title"",""Security and Communication Networks""
""language"",""en""
""og:description"",""The Even–Mansour cipher has been widely used in block ciphers and lightweight symmetric-key ciphers because of its simple structure and strict provable security. Its research has been a hot topic in cryptography. This paper focuses on the problem to minimize the key material of the Even–Mansour cipher while its security bound remains essentially the same. We introduce four structures of the Even–Mansour cipher with a short key and derive their security by Patarin’s H-coefficients technique. These four structures are proven secure up to <span class=""""inline_break""""><svg xmlns:xlink=""""http://www.w3.org/1999/xlink"""" xmlns=""""http://www.w3.org/2000/svg"""" width=""""30.663pt"""" style=""""vertical-align:-3.4294pt"""" id=""""M1"""" height=""""15.6876pt"""" version=""""1.1"""" viewBox=""""-0.0498162 -12.2582 30.663 15.6876""""><g transform=""""matrix(.013,0,0,-0.013,1.005,-2.897)""""><path id=""""g119-113"""" d=""""M658 624L641 649C599 612 554 595 493 595C444 595 402 603 342 615C268 634 232 641 184 641C129 641 57 621 0 557L17 532C67 566 113 586 176 586C230 586 265 577 316 565C380 550 430 540 482 540C540 540 611 558 658 624Z""""/></g><g transform=""""matrix(.013,0,0,-0.013,0,0)""""><path id=""""g113-80"""" d=""""M699 369C699 549 575 666 407 666C186 666 23 488 23 278C23 101 145 -16 312 -16C535 -16 699 153 699 369ZM600 373C600 210 500 19 321 19C186 19 120 129 120 272C120 450 232 631 399 631C541 631 600 522 600 373Z""""/></g><g transform=""""matrix(.013,0,0,-0.013,9.421,0)""""><path id=""""g113-41"""" d=""""M300 -147C201 -63 143 98 143 270S200 602 300 686L282 710C136 610 70 450 70 271V270C70 89 136 -72 282 -170L300 -147Z""""/></g><g transform=""""matrix(.013,0,0,-0.013,13.919,0)""""><path id=""""g113-51"""" d=""""M412 140C382 77 369 73 315 73H129L270 222C362 320 402 379 402 466C402 571 322 635 234 635C177 635 130 609 99 576L42 495L64 475C90 514 133 568 201 568C274 568 318 519 318 435C318 349 255 267 193 193C144 135 87 78 32 23V0H405C417 45 427 89 440 131L412 140Z""""/></g><g transform=""""matrix(.0091,0,0,-0.0091,20.159,-5.741)""""><path id=""""g50-108"""" d=""""M485 418C485 434 469 451 441 451C389 451 312 387 255 335C221 304 194 278 159 242H157L259 678C264 698 264 710 255 710C242 710 183 681 96 673L90 643L128 642C165 641 171 640 162 602L24 -5L31 -12C51 -4 81 4 110 9L145 181C154 195 180 220 205 242C233 170 263 106 291 53C318 1 335 -12 360 -12C383 -12 425 0 483 82L463 105C437 79 411 57 400 57C388 57 378 68 355 110C329 156 288 244 268 298C299 333 355 376 405 376C426 376 440 373 448 368C453 365 465 368 468 373C477 386 485 405 485 418Z""""/></g><g transform=""""matrix(.013,0,0,-0.013,25.307,0)""""><path id=""""g113-48"""" d=""""M368 703H309L44 -163H104L368 703Z""""/></g></svg><span class=""""isep""""/><svg xmlns:xlink=""""http://www.w3.org/1999/xlink"""" xmlns=""""http://www.w3.org/2000/svg"""" width=""""11.714pt"""" style=""""vertical-align:-3.4294pt"""" height=""""15.6876pt"""" version=""""1.1"""" viewBox=""""30.6181838 -12.2582 11.714 15.6876""""><g transform=""""matrix(.013,0,0,-0.013,30.668,0)""""><path id=""""g113-234"""" d=""""M538 96L524 119C492 88 454 63 446 63C439 63 434 70 440 101C463 223 491 341 518 448H508L433 422L401 276C355 192 240 56 188 56C163 56 154 89 163 133C184 233 207 338 235 443L230 448L152 424L58 17C40 -60 23 -143 23 -185C23 -241 42 -261 63 -261C92 -261 117 -241 125 -227L124 -221C109 -209 89 -165 89 -103C89 -55 96 -13 105 26H107C121 -3 134 -12 151 -12C172 -12 194 -5 221 16C279 61 330 124 384 194H386C381 159 377 141 368 105C343 3 363 -12 383 -12C416 -12 486 35 538 96Z""""/></g><g transform=""""matrix(.013,0,0,-0.013,37.884,0)""""><path id=""""g113-42"""" d=""""M275 270C275 450 212 609 64 710L45 686C145 604 203 442 203 270S147 -63 45 -147L64 -170C213 -68 275 89 275 270Z""""/></g></svg></span> adversarial queries, where <i>k</i> is the bit length of the key material and <i>μ</i> is the maximal multiplicity. Then, we apply them to lightweight authenticated encryption modes and prove their security up to about <span class=""""inline_break""""><svg xmlns:xlink=""""http://www.w3.org/1999/xlink"""" xmlns=""""http://www.w3.org/2000/svg"""" width=""""37.29pt"""" style=""""vertical-align:-3.429399pt"""" id=""""M2"""" height=""""12.7373pt"""" version=""""1.1"""" viewBox=""""-0.0498162 -9.3079 37.29 12.7373""""><g transform=""""matrix(.013,0,0,-0.013,0,0)""""><path id=""""g190-110"""" d=""""M797 0V26C739 32 732 36 732 103V296C732 394 682 449 605 449C576 449 550 437 529 423C504 407 475 389 446 366C425 418 382 449 334 449C303 449 279 437 253 421C222 403 201 385 180 371V452C135 432 85 419 41 411V388C99 379 102 374 102 310V103C102 38 93 32 27 26V0H238V26C189 32 180 38 180 103V338C210 363 250 390 289 390C351 390 377 348 377 275V103C377 37 368 32 306 26V0H520V26C465 32 456 38 456 101V296C456 314 455 326 453 338C491 369 529 390 565 390C628 390 653 345 653 274V107C653 36 642 32 583 26V0H797Z""""/></g><g transform=""""matrix(.013,0,0,-0.013,10.647,0)""""><path id=""""g190-106"""" d=""""M135 536C164 536 186 560 186 587C186 617 164 639 136 639C109 639 85 617 85 587C85 560 109 536 135 536ZM252 0V26C188 32 181 38 181 106V451C138 433 90 420 39 412V388C99 379 102 374 102 312V106C102 38 95 32 32 26V0H252Z""""/></g><g transform=""""matrix(.013,0,0,-0.013,14.131,0)""""><path id=""""g190-111"""" d=""""M524 0V26C466 32 460 36 460 104V297C460 393 411 449 331 449C302 449 276 437 248 419C223 402 201 387 181 372V451C137 432 90 420 42 411V388C96 378 102 374 102 310V104C102 38 97 33 29 26V0H246V26C187 32 181 36 181 104V339C211 365 250 390 290 390C357 390 381 345 381 276V109C381 40 374 32 315 26V0H524Z""""/></g><g transform=""""matrix(.013,0,0,-0.013,21.322,0)""""><path id=""""g113-124"""" d=""""M293 -169V-141C218 -131 209 -90 209 -44C209 19 222 85 222 152C222 207 198 255 139 269V273C199 286 222 334 222 388C222 454 209 523 209 588C209 632 218 671 293 681V709C234 709 148 695 148 577C147 513 155 438 155 372C155 337 152 291 64 285V256C152 250 155 204 155 169C156 105 148 31 148 -41C148 -157 234 -169 293 -169Z""""/></g><g transform=""""matrix(.013,0,0,-0.013,25.833,0)""""><path id=""""g113-99"""" d=""""M452 333C452 398 425 448 375 448C329 448 235 404 140 292H138L229 683C233 701 234 712 225 712C208 712 149 686 66 677L64 652H97C135 652 140 651 129 598L38 167C23 96 29 57 44 33C60 7 98 -12 132 -12C169 -12 232 3 290 41C383 102 452 223 452 333ZM365 316C365 199 308 87 239 49C221 39 200 35 183 35C137 35 99 70 112 163C116 191 123 215 129 233C190 316 290 392 330 392C348 392 365 372 365 316Z""""/></g><g transform=""""matrix(.013,0,0,-0.013,31.934,0)""""><use xlink:href=""""#g113-48""""/></g></svg><span class=""""isep""""/><svg xmlns:xlink=""""http://www.w3.org/1999/xlink"""" xmlns=""""http://www.w3.org/2000/svg"""" width=""""9.204pt"""" style=""""vertical-align:-3.429399pt"""" height=""""12.7373pt"""" version=""""1.1"""" viewBox=""""37.2451838 -9.3079 9.204 12.7373""""><g transform=""""matrix(.013,0,0,-0.013,37.295,0)""""><use xlink:href=""""#g113-51""""/></g><g transform=""""matrix(.013,0,0,-0.013,43.535,0)""""><path id=""""g113-45"""" d=""""M95 130C70 130 46 113 46 88C46 72 54 64 59 64C93 55 121 33 121 -3C121 -41 93 -68 44 -88L55 -117C117 -98 186 -56 186 22C186 91 131 130 95 130Z""""/></g></svg><span class=""""ipunc""""></span><svg xmlns:xlink=""""http://www.w3.org/1999/xlink"""" xmlns=""""http://www.w3.org/2000/svg"""" width=""""8.246pt"""" style=""""vertical-align:-3.429399pt"""" height=""""12.7373pt"""" version=""""1.1"""" viewBox=""""48.628183799999995 -9.3079 8.246 12.7373""""><g transform=""""matrix(.013,0,0,-0.013,48.678,0)""""><path id=""""g113-100"""" d=""""M383 397C383 424 344 448 299 448C244 448 172 409 132 375C66 319 23 227 23 146C23 42 74 -12 146 -12C208 -12 298 30 359 103L343 124C315 95 248 48 192 48C145 48 111 85 111 163C111 228 129 294 151 330C171 363 201 401 241 401C275 401 302 384 325 356C332 347 339 344 348 348C373 360 383 381 383 397Z""""/></g><g transform=""""matrix(.013,0,0,-0.013,53.96,0)""""><use xlink:href=""""#g113-45""""/></g></svg><span class=""""ipunc""""></span><span class=""""nowrap""""><svg xmlns:xlink=""""http://www.w3.org/1999/xlink"""" xmlns=""""http://www.w3.org/2000/svg"""" width=""""50.254pt"""" style=""""vertical-align:-3.429399pt"""" height=""""12.7373pt"""" version=""""1.1"""" viewBox=""""59.0531838 -9.3079 50.254 12.7373""""><g transform=""""matrix(.013,0,0,-0.013,59.103,0)""""><path id=""""g113-108"""" d=""""M480 416C480 431 465 448 438 448C388 448 312 383 252 330C217 299 188 273 155 237H153L257 680C262 700 263 712 253 712C240 712 183 684 97 674L92 648L126 647C166 646 172 645 163 606L23 -6L29 -12C51 -5 77 2 107 8C115 62 130 128 142 180C153 193 179 220 204 241C231 170 259 106 288 54C317 0 336 -12 358 -12C381 -12 423 2 477 80L460 100C434 74 408 54 398 54C385 54 374 65 351 107C326 154 282 241 263 299C296 332 351 377 403 377C424 377 436 372 445 368C449 366 456 368 462 375C472 386 480 402 480 416Z""""/></g><g transform=""""matrix(.013,0,0,-0.013,68.548,0)""""><path id=""""g117-33"""" d=""""M535 230V280H52V230H535Z""""/></g><g transform=""""matrix(.013,0,0,-0.013,79.084,0)""""><path id=""""g190-109"""" d=""""M238 0V26C174 32 166 38 166 104V712C132 700 70 683 18 677V653C81 647 87 645 87 577V104C87 38 78 32 15 26V0H238Z""""/></g><g transform=""""matrix(.013,0,0,-0.013,82.374,0)""""><path id=""""g190-112"""" d=""""M257 449C165 449 37 374 37 209C37 98 119 -12 256 -12C355 -12 473 65 473 226C473 349 381 449 257 449ZM244 416C333 416 380 320 380 204C380 67 329 21 267 21C184 21 130 115 130 241C130 354 184 416 244 416Z""""/></g><g transform=""""matrix(.013,0,0,-0.013,89.004,0)""""><path id=""""g190-104"""" d=""""M463 437C426 431 375 425 327 422C297 440 264 449 231 449H230C153 449 51 396 51 283C51 215 94 168 139 149C123 129 91 103 51 88C50 78 53 60 62 46C75 25 100 2 136 -9C112 -28 73 -59 53 -79C38 -94 29 -113 29 -135C30 -192 91 -257 203 -257C336 -257 452 -160 452 -59C452 39 371 59 309 59C275 59 240 58 203 58C158 58 140 77 140 96C140 110 157 129 170 138C186 135 205 133 221 133C306 133 396 185 396 293C396 328 384 360 366 381L423 378C439 387 459 413 468 429L463 437ZM219 418C277 418 314 362 314 284C314 205 275 166 231 165C176 165 137 221 137 299C137 376 177 418 219 418ZM241 -11C285 -11 314 -14 339 -24C367 -36 384 -61 384 -95C384 -157 335 -206 240 -206C166 -206 108 -165 108 -110C108 -82 128 -54 154 -32C172 -17 195 -11 241 -11Z""""/></g><g transform=""""matrix(.013,0,0,-0.013,97.323,0)""""><use xlink:href=""""#g113-234""""/></g><g transform=""""matrix(.013,0,0,-0.013,104.539,0)""""><path id=""""g113-126"""" d=""""M283 255V284C195 290 192 337 192 375C192 436 200 508 200 580C200 696 116 709 54 709V681C127 671 139 634 139 588C138 524 125 452 125 387C125 333 149 286 209 272V268C148 253 125 206 125 151C126 87 139 16 139 -47C139 -92 127 -131 54 -141V-169C115 -169 200 -152 200 -41C200 32 192 104 192 164C192 202 195 249 283 255Z""""/></g></svg>-</span></span>bit adversarial queries, where <i>b</i> is the size of the permutation and <i>c</i> is the capacity of the permutation. Finally, we leave it as an open problem to settle the security of the <i>t</i>-round iterated Even–Mansour cipher with short keys.""
""prism.issn"",""1939-0114""
""citation_issn"",""1939-0114""
""dc:title"",""Minimizing Key Materials: The Even–Mansour Cipher Revisited and Its Application to Lightweight Authenticated Encryption""
""Content-Encoding"",""UTF-8""
""citation_pdf_url"",""https://downloads.hindawi.com/journals/scn/2020/4180139.pdf""
""robots"",""index""
""google-site-verification"",""AxEuDsL7vXGOxRe53-uFhOk2ODN0bbXMeuBy6Pfq4ww""
""citation_author"",""Zhang, Ping"",""Yuan, Qian""
""dc.date"",""2020/03/10""
""prism.volume"",""2020""
""citation_doi"",""https://doi.org/10.1155/2020/4180139""
""prism.publicationName"",""Security and Communication Networks""
""dc.title"",""Minimizing Key Materials: The Even–Mansour Cipher Revisited and Its Application to Lightweight Authenticated Encryption""
""Author"",""Hindawi""
""citation_volume"",""2020""
""dc.language"",""en""
""Content-Language"",""en""
""authors"",""Ping Zhang | Qian Yuan""
""citation_title"",""Minimizing Key Materials: The Even–Mansour Cipher Revisited and Its Application to Lightweight Authenticated Encryption""
""citation_year"",""2020""
""citation_publisher"",""Hindawi""
""dc.format"",""text/html""
""description"",""The Even–Mansour cipher has been widely used in block ciphers and lightweight symmetric-key ciphers because of its simple structure and strict provable security. Its research has been a hot topic in cryptography. This paper focuses on the problem to minimize the key material of the Even–Mansour cipher while its security bound remains essentially the same. We introduce four structures of the Even–Mansour cipher with a short key and derive their security by Patarin’s H-coefficients technique. These four structures are proven secure up to <span class=""""inline_break""""><svg xmlns:xlink=""""http://www.w3.org/1999/xlink"""" xmlns=""""http://www.w3.org/2000/svg"""" width=""""30.663pt"""" style=""""vertical-align:-3.4294pt"""" id=""""M1"""" height=""""15.6876pt"""" version=""""1.1"""" viewBox=""""-0.0498162 -12.2582 30.663 15.6876""""><g transform=""""matrix(.013,0,0,-0.013,1.005,-2.897)""""><path id=""""g119-113"""" d=""""M658 624L641 649C599 612 554 595 493 595C444 595 402 603 342 615C268 634 232 641 184 641C129 641 57 621 0 557L17 532C67 566 113 586 176 586C230 586 265 577 316 565C380 550 430 540 482 540C540 540 611 558 658 624Z""""/></g><g transform=""""matrix(.013,0,0,-0.013,0,0)""""><path id=""""g113-80"""" d=""""M699 369C699 549 575 666 407 666C186 666 23 488 23 278C23 101 145 -16 312 -16C535 -16 699 153 699 369ZM600 373C600 210 500 19 321 19C186 19 120 129 120 272C120 450 232 631 399 631C541 631 600 522 600 373Z""""/></g><g transform=""""matrix(.013,0,0,-0.013,9.421,0)""""><path id=""""g113-41"""" d=""""M300 -147C201 -63 143 98 143 270S200 602 300 686L282 710C136 610 70 450 70 271V270C70 89 136 -72 282 -170L300 -147Z""""/></g><g transform=""""matrix(.013,0,0,-0.013,13.919,0)""""><path id=""""g113-51"""" d=""""M412 140C382 77 369 73 315 73H129L270 222C362 320 402 379 402 466C402 571 322 635 234 635C177 635 130 609 99 576L42 495L64 475C90 514 133 568 201 568C274 568 318 519 318 435C318 349 255 267 193 193C144 135 87 78 32 23V0H405C417 45 427 89 440 131L412 140Z""""/></g><g transform=""""matrix(.0091,0,0,-0.0091,20.159,-5.741)""""><path id=""""g50-108"""" d=""""M485 418C485 434 469 451 441 451C389 451 312 387 255 335C221 304 194 278 159 242H157L259 678C264 698 264 710 255 710C242 710 183 681 96 673L90 643L128 642C165 641 171 640 162 602L24 -5L31 -12C51 -4 81 4 110 9L145 181C154 195 180 220 205 242C233 170 263 106 291 53C318 1 335 -12 360 -12C383 -12 425 0 483 82L463 105C437 79 411 57 400 57C388 57 378 68 355 110C329 156 288 244 268 298C299 333 355 376 405 376C426 376 440 373 448 368C453 365 465 368 468 373C477 386 485 405 485 418Z""""/></g><g transform=""""matrix(.013,0,0,-0.013,25.307,0)""""><path id=""""g113-48"""" d=""""M368 703H309L44 -163H104L368 703Z""""/></g></svg><span class=""""isep""""/><svg xmlns:xlink=""""http://www.w3.org/1999/xlink"""" xmlns=""""http://www.w3.org/2000/svg"""" width=""""11.714pt"""" style=""""vertical-align:-3.4294pt"""" height=""""15.6876pt"""" version=""""1.1"""" viewBox=""""30.6181838 -12.2582 11.714 15.6876""""><g transform=""""matrix(.013,0,0,-0.013,30.668,0)""""><path id=""""g113-234"""" d=""""M538 96L524 119C492 88 454 63 446 63C439 63 434 70 440 101C463 223 491 341 518 448H508L433 422L401 276C355 192 240 56 188 56C163 56 154 89 163 133C184 233 207 338 235 443L230 448L152 424L58 17C40 -60 23 -143 23 -185C23 -241 42 -261 63 -261C92 -261 117 -241 125 -227L124 -221C109 -209 89 -165 89 -103C89 -55 96 -13 105 26H107C121 -3 134 -12 151 -12C172 -12 194 -5 221 16C279 61 330 124 384 194H386C381 159 377 141 368 105C343 3 363 -12 383 -12C416 -12 486 35 538 96Z""""/></g><g transform=""""matrix(.013,0,0,-0.013,37.884,0)""""><path id=""""g113-42"""" d=""""M275 270C275 450 212 609 64 710L45 686C145 604 203 442 203 270S147 -63 45 -147L64 -170C213 -68 275 89 275 270Z""""/></g></svg></span> adversarial queries, where <i>k</i> is the bit length of the key material and <i>μ</i> is the maximal multiplicity. Then, we apply them to lightweight authenticated encryption modes and prove their security up to about <span class=""""inline_break""""><svg xmlns:xlink=""""http://www.w3.org/1999/xlink"""" xmlns=""""http://www.w3.org/2000/svg"""" width=""""37.29pt"""" style=""""vertical-align:-3.429399pt"""" id=""""M2"""" height=""""12.7373pt"""" version=""""1.1"""" viewBox=""""-0.0498162 -9.3079 37.29 12.7373""""><g transform=""""matrix(.013,0,0,-0.013,0,0)""""><path id=""""g190-110"""" d=""""M797 0V26C739 32 732 36 732 103V296C732 394 682 449 605 449C576 449 550 437 529 423C504 407 475 389 446 366C425 418 382 449 334 449C303 449 279 437 253 421C222 403 201 385 180 371V452C135 432 85 419 41 411V388C99 379 102 374 102 310V103C102 38 93 32 27 26V0H238V26C189 32 180 38 180 103V338C210 363 250 390 289 390C351 390 377 348 377 275V103C377 37 368 32 306 26V0H520V26C465 32 456 38 456 101V296C456 314 455 326 453 338C491 369 529 390 565 390C628 390 653 345 653 274V107C653 36 642 32 583 26V0H797Z""""/></g><g transform=""""matrix(.013,0,0,-0.013,10.647,0)""""><path id=""""g190-106"""" d=""""M135 536C164 536 186 560 186 587C186 617 164 639 136 639C109 639 85 617 85 587C85 560 109 536 135 536ZM252 0V26C188 32 181 38 181 106V451C138 433 90 420 39 412V388C99 379 102 374 102 312V106C102 38 95 32 32 26V0H252Z""""/></g><g transform=""""matrix(.013,0,0,-0.013,14.131,0)""""><path id=""""g190-111"""" d=""""M524 0V26C466 32 460 36 460 104V297C460 393 411 449 331 449C302 449 276 437 248 419C223 402 201 387 181 372V451C137 432 90 420 42 411V388C96 378 102 374 102 310V104C102 38 97 33 29 26V0H246V26C187 32 181 36 181 104V339C211 365 250 390 290 390C357 390 381 345 381 276V109C381 40 374 32 315 26V0H524Z""""/></g><g transform=""""matrix(.013,0,0,-0.013,21.322,0)""""><path id=""""g113-124"""" d=""""M293 -169V-141C218 -131 209 -90 209 -44C209 19 222 85 222 152C222 207 198 255 139 269V273C199 286 222 334 222 388C222 454 209 523 209 588C209 632 218 671 293 681V709C234 709 148 695 148 577C147 513 155 438 155 372C155 337 152 291 64 285V256C152 250 155 204 155 169C156 105 148 31 148 -41C148 -157 234 -169 293 -169Z""""/></g><g transform=""""matrix(.013,0,0,-0.013,25.833,0)""""><path id=""""g113-99"""" d=""""M452 333C452 398 425 448 375 448C329 448 235 404 140 292H138L229 683C233 701 234 712 225 712C208 712 149 686 66 677L64 652H97C135 652 140 651 129 598L38 167C23 96 29 57 44 33C60 7 98 -12 132 -12C169 -12 232 3 290 41C383 102 452 223 452 333ZM365 316C365 199 308 87 239 49C221 39 200 35 183 35C137 35 99 70 112 163C116 191 123 215 129 233C190 316 290 392 330 392C348 392 365 372 365 316Z""""/></g><g transform=""""matrix(.013,0,0,-0.013,31.934,0)""""><use xlink:href=""""#g113-48""""/></g></svg><span class=""""isep""""/><svg xmlns:xlink=""""http://www.w3.org/1999/xlink"""" xmlns=""""http://www.w3.org/2000/svg"""" width=""""9.204pt"""" style=""""vertical-align:-3.429399pt"""" height=""""12.7373pt"""" version=""""1.1"""" viewBox=""""37.2451838 -9.3079 9.204 12.7373""""><g transform=""""matrix(.013,0,0,-0.013,37.295,0)""""><use xlink:href=""""#g113-51""""/></g><g transform=""""matrix(.013,0,0,-0.013,43.535,0)""""><path id=""""g113-45"""" d=""""M95 130C70 130 46 113 46 88C46 72 54 64 59 64C93 55 121 33 121 -3C121 -41 93 -68 44 -88L55 -117C117 -98 186 -56 186 22C186 91 131 130 95 130Z""""/></g></svg><span class=""""ipunc""""></span><svg xmlns:xlink=""""http://www.w3.org/1999/xlink"""" xmlns=""""http://www.w3.org/2000/svg"""" width=""""8.246pt"""" style=""""vertical-align:-3.429399pt"""" height=""""12.7373pt"""" version=""""1.1"""" viewBox=""""48.628183799999995 -9.3079 8.246 12.7373""""><g transform=""""matrix(.013,0,0,-0.013,48.678,0)""""><path id=""""g113-100"""" d=""""M383 397C383 424 344 448 299 448C244 448 172 409 132 375C66 319 23 227 23 146C23 42 74 -12 146 -12C208 -12 298 30 359 103L343 124C315 95 248 48 192 48C145 48 111 85 111 163C111 228 129 294 151 330C171 363 201 401 241 401C275 401 302 384 325 356C332 347 339 344 348 348C373 360 383 381 383 397Z""""/></g><g transform=""""matrix(.013,0,0,-0.013,53.96,0)""""><use xlink:href=""""#g113-45""""/></g></svg><span class=""""ipunc""""></span><span class=""""nowrap""""><svg xmlns:xlink=""""http://www.w3.org/1999/xlink"""" xmlns=""""http://www.w3.org/2000/svg"""" width=""""50.254pt"""" style=""""vertical-align:-3.429399pt"""" height=""""12.7373pt"""" version=""""1.1"""" viewBox=""""59.0531838 -9.3079 50.254 12.7373""""><g transform=""""matrix(.013,0,0,-0.013,59.103,0)""""><path id=""""g113-108"""" d=""""M480 416C480 431 465 448 438 448C388 448 312 383 252 330C217 299 188 273 155 237H153L257 680C262 700 263 712 253 712C240 712 183 684 97 674L92 648L126 647C166 646 172 645 163 606L23 -6L29 -12C51 -5 77 2 107 8C115 62 130 128 142 180C153 193 179 220 204 241C231 170 259 106 288 54C317 0 336 -12 358 -12C381 -12 423 2 477 80L460 100C434 74 408 54 398 54C385 54 374 65 351 107C326 154 282 241 263 299C296 332 351 377 403 377C424 377 436 372 445 368C449 366 456 368 462 375C472 386 480 402 480 416Z""""/></g><g transform=""""matrix(.013,0,0,-0.013,68.548,0)""""><path id=""""g117-33"""" d=""""M535 230V280H52V230H535Z""""/></g><g transform=""""matrix(.013,0,0,-0.013,79.084,0)""""><path id=""""g190-109"""" d=""""M238 0V26C174 32 166 38 166 104V712C132 700 70 683 18 677V653C81 647 87 645 87 577V104C87 38 78 32 15 26V0H238Z""""/></g><g transform=""""matrix(.013,0,0,-0.013,82.374,0)""""><path id=""""g190-112"""" d=""""M257 449C165 449 37 374 37 209C37 98 119 -12 256 -12C355 -12 473 65 473 226C473 349 381 449 257 449ZM244 416C333 416 380 320 380 204C380 67 329 21 267 21C184 21 130 115 130 241C130 354 184 416 244 416Z""""/></g><g transform=""""matrix(.013,0,0,-0.013,89.004,0)""""><path id=""""g190-104"""" d=""""M463 437C426 431 375 425 327 422C297 440 264 449 231 449H230C153 449 51 396 51 283C51 215 94 168 139 149C123 129 91 103 51 88C50 78 53 60 62 46C75 25 100 2 136 -9C112 -28 73 -59 53 -79C38 -94 29 -113 29 -135C30 -192 91 -257 203 -257C336 -257 452 -160 452 -59C452 39 371 59 309 59C275 59 240 58 203 58C158 58 140 77 140 96C140 110 157 129 170 138C186 135 205 133 221 133C306 133 396 185 396 293C396 328 384 360 366 381L423 378C439 387 459 413 468 429L463 437ZM219 418C277 418 314 362 314 284C314 205 275 166 231 165C176 165 137 221 137 299C137 376 177 418 219 418ZM241 -11C285 -11 314 -14 339 -24C367 -36 384 -61 384 -95C384 -157 335 -206 240 -206C166 -206 108 -165 108 -110C108 -82 128 -54 154 -32C172 -17 195 -11 241 -11Z""""/></g><g transform=""""matrix(.013,0,0,-0.013,97.323,0)""""><use xlink:href=""""#g113-234""""/></g><g transform=""""matrix(.013,0,0,-0.013,104.539,0)""""><path id=""""g113-126"""" d=""""M283 255V284C195 290 192 337 192 375C192 436 200 508 200 580C200 696 116 709 54 709V681C127 671 139 634 139 588C138 524 125 452 125 387C125 333 149 286 209 272V268C148 253 125 206 125 151C126 87 139 16 139 -47C139 -92 127 -131 54 -141V-169C115 -169 200 -152 200 -41C200 32 192 104 192 164C192 202 195 249 283 255Z""""/></g></svg>-</span></span>bit adversarial queries, where <i>b</i> is the size of the permutation and <i>c</i> is the capacity of the permutation. Finally, we leave it as an open problem to settle the security of the <i>t</i>-round iterated Even–Mansour cipher with short keys.""
""og:image:type"",""image/jpeg""
""citation_date"",""2020/03/10""
""title"",""Minimizing Key Materials: The Even–Mansour Cipher Revisited and Its Application to Lightweight Authenticated Encryption"",""Minimizing Key Materials: The Even–Mansour Cipher Revisited and Its Application to Lightweight Authenticated Encryption""
""twitter:image"",""https://images.hindawi.com/journals/scn/scn.banner.jpg""
""citation_online_date"",""2020/03/10""
""twitter:site"",""website""
""dc.type"",""Research Article""
""dc.source"",""Security and Communication Networks""
""dc.creator"",""Zhang, Ping"",""Yuan, Qian""
""citation_fulltext_html_url"",""https://www.hindawi.com/journals/scn/2020/4180139/""
""prism.publicationDate"",""2020/03/10""
""Content-Length"",""1106693""
""citation_xml_url"",""https://downloads.hindawi.com/journals/scn/2020/4180139.xml""
""Content-Type"",""text/html; charset=UTF-8""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""og:type"",""website""
""twitter:title"",""Minimizing Key Materials: The Even–Mansour Cipher Revisited and Its Application to Lightweight Authenticated Encryption""
""dc.description"",""The Even–Mansour cipher has been widely used in block ciphers and lightweight symmetric-key ciphers because of its simple structure and strict provable security. Its research has been a hot topic in cryptography. This paper focuses on the problem to minimize the key material of the Even–Mansour cipher while its security bound remains essentially the same. We introduce four structures of the Even–Mansour cipher with a short key and derive their security by Patarin’s H-coefficients technique. These four structures are proven secure up to <span class=""""inline_break""""><svg xmlns:xlink=""""http://www.w3.org/1999/xlink"""" xmlns=""""http://www.w3.org/2000/svg"""" width=""""30.663pt"""" style=""""vertical-align:-3.4294pt"""" id=""""M1"""" height=""""15.6876pt"""" version=""""1.1"""" viewBox=""""-0.0498162 -12.2582 30.663 15.6876""""><g transform=""""matrix(.013,0,0,-0.013,1.005,-2.897)""""><path id=""""g119-113"""" d=""""M658 624L641 649C599 612 554 595 493 595C444 595 402 603 342 615C268 634 232 641 184 641C129 641 57 621 0 557L17 532C67 566 113 586 176 586C230 586 265 577 316 565C380 550 430 540 482 540C540 540 611 558 658 624Z""""/></g><g transform=""""matrix(.013,0,0,-0.013,0,0)""""><path id=""""g113-80"""" d=""""M699 369C699 549 575 666 407 666C186 666 23 488 23 278C23 101 145 -16 312 -16C535 -16 699 153 699 369ZM600 373C600 210 500 19 321 19C186 19 120 129 120 272C120 450 232 631 399 631C541 631 600 522 600 373Z""""/></g><g transform=""""matrix(.013,0,0,-0.013,9.421,0)""""><path id=""""g113-41"""" d=""""M300 -147C201 -63 143 98 143 270S200 602 300 686L282 710C136 610 70 450 70 271V270C70 89 136 -72 282 -170L300 -147Z""""/></g><g transform=""""matrix(.013,0,0,-0.013,13.919,0)""""><path id=""""g113-51"""" d=""""M412 140C382 77 369 73 315 73H129L270 222C362 320 402 379 402 466C402 571 322 635 234 635C177 635 130 609 99 576L42 495L64 475C90 514 133 568 201 568C274 568 318 519 318 435C318 349 255 267 193 193C144 135 87 78 32 23V0H405C417 45 427 89 440 131L412 140Z""""/></g><g transform=""""matrix(.0091,0,0,-0.0091,20.159,-5.741)""""><path id=""""g50-108"""" d=""""M485 418C485 434 469 451 441 451C389 451 312 387 255 335C221 304 194 278 159 242H157L259 678C264 698 264 710 255 710C242 710 183 681 96 673L90 643L128 642C165 641 171 640 162 602L24 -5L31 -12C51 -4 81 4 110 9L145 181C154 195 180 220 205 242C233 170 263 106 291 53C318 1 335 -12 360 -12C383 -12 425 0 483 82L463 105C437 79 411 57 400 57C388 57 378 68 355 110C329 156 288 244 268 298C299 333 355 376 405 376C426 376 440 373 448 368C453 365 465 368 468 373C477 386 485 405 485 418Z""""/></g><g transform=""""matrix(.013,0,0,-0.013,25.307,0)""""><path id=""""g113-48"""" d=""""M368 703H309L44 -163H104L368 703Z""""/></g></svg><span class=""""isep""""/><svg xmlns:xlink=""""http://www.w3.org/1999/xlink"""" xmlns=""""http://www.w3.org/2000/svg"""" width=""""11.714pt"""" style=""""vertical-align:-3.4294pt"""" height=""""15.6876pt"""" version=""""1.1"""" viewBox=""""30.6181838 -12.2582 11.714 15.6876""""><g transform=""""matrix(.013,0,0,-0.013,30.668,0)""""><path id=""""g113-234"""" d=""""M538 96L524 119C492 88 454 63 446 63C439 63 434 70 440 101C463 223 491 341 518 448H508L433 422L401 276C355 192 240 56 188 56C163 56 154 89 163 133C184 233 207 338 235 443L230 448L152 424L58 17C40 -60 23 -143 23 -185C23 -241 42 -261 63 -261C92 -261 117 -241 125 -227L124 -221C109 -209 89 -165 89 -103C89 -55 96 -13 105 26H107C121 -3 134 -12 151 -12C172 -12 194 -5 221 16C279 61 330 124 384 194H386C381 159 377 141 368 105C343 3 363 -12 383 -12C416 -12 486 35 538 96Z""""/></g><g transform=""""matrix(.013,0,0,-0.013,37.884,0)""""><path id=""""g113-42"""" d=""""M275 270C275 450 212 609 64 710L45 686C145 604 203 442 203 270S147 -63 45 -147L64 -170C213 -68 275 89 275 270Z""""/></g></svg></span> adversarial queries, where <i>k</i> is the bit length of the key material and <i>μ</i> is the maximal multiplicity. Then, we apply them to lightweight authenticated encryption modes and prove their security up to about <span class=""""inline_break""""><svg xmlns:xlink=""""http://www.w3.org/1999/xlink"""" xmlns=""""http://www.w3.org/2000/svg"""" width=""""37.29pt"""" style=""""vertical-align:-3.429399pt"""" id=""""M2"""" height=""""12.7373pt"""" version=""""1.1"""" viewBox=""""-0.0498162 -9.3079 37.29 12.7373""""><g transform=""""matrix(.013,0,0,-0.013,0,0)""""><path id=""""g190-110"""" d=""""M797 0V26C739 32 732 36 732 103V296C732 394 682 449 605 449C576 449 550 437 529 423C504 407 475 389 446 366C425 418 382 449 334 449C303 449 279 437 253 421C222 403 201 385 180 371V452C135 432 85 419 41 411V388C99 379 102 374 102 310V103C102 38 93 32 27 26V0H238V26C189 32 180 38 180 103V338C210 363 250 390 289 390C351 390 377 348 377 275V103C377 37 368 32 306 26V0H520V26C465 32 456 38 456 101V296C456 314 455 326 453 338C491 369 529 390 565 390C628 390 653 345 653 274V107C653 36 642 32 583 26V0H797Z""""/></g><g transform=""""matrix(.013,0,0,-0.013,10.647,0)""""><path id=""""g190-106"""" d=""""M135 536C164 536 186 560 186 587C186 617 164 639 136 639C109 639 85 617 85 587C85 560 109 536 135 536ZM252 0V26C188 32 181 38 181 106V451C138 433 90 420 39 412V388C99 379 102 374 102 312V106C102 38 95 32 32 26V0H252Z""""/></g><g transform=""""matrix(.013,0,0,-0.013,14.131,0)""""><path id=""""g190-111"""" d=""""M524 0V26C466 32 460 36 460 104V297C460 393 411 449 331 449C302 449 276 437 248 419C223 402 201 387 181 372V451C137 432 90 420 42 411V388C96 378 102 374 102 310V104C102 38 97 33 29 26V0H246V26C187 32 181 36 181 104V339C211 365 250 390 290 390C357 390 381 345 381 276V109C381 40 374 32 315 26V0H524Z""""/></g><g transform=""""matrix(.013,0,0,-0.013,21.322,0)""""><path id=""""g113-124"""" d=""""M293 -169V-141C218 -131 209 -90 209 -44C209 19 222 85 222 152C222 207 198 255 139 269V273C199 286 222 334 222 388C222 454 209 523 209 588C209 632 218 671 293 681V709C234 709 148 695 148 577C147 513 155 438 155 372C155 337 152 291 64 285V256C152 250 155 204 155 169C156 105 148 31 148 -41C148 -157 234 -169 293 -169Z""""/></g><g transform=""""matrix(.013,0,0,-0.013,25.833,0)""""><path id=""""g113-99"""" d=""""M452 333C452 398 425 448 375 448C329 448 235 404 140 292H138L229 683C233 701 234 712 225 712C208 712 149 686 66 677L64 652H97C135 652 140 651 129 598L38 167C23 96 29 57 44 33C60 7 98 -12 132 -12C169 -12 232 3 290 41C383 102 452 223 452 333ZM365 316C365 199 308 87 239 49C221 39 200 35 183 35C137 35 99 70 112 163C116 191 123 215 129 233C190 316 290 392 330 392C348 392 365 372 365 316Z""""/></g><g transform=""""matrix(.013,0,0,-0.013,31.934,0)""""><use xlink:href=""""#g113-48""""/></g></svg><span class=""""isep""""/><svg xmlns:xlink=""""http://www.w3.org/1999/xlink"""" xmlns=""""http://www.w3.org/2000/svg"""" width=""""9.204pt"""" style=""""vertical-align:-3.429399pt"""" height=""""12.7373pt"""" version=""""1.1"""" viewBox=""""37.2451838 -9.3079 9.204 12.7373""""><g transform=""""matrix(.013,0,0,-0.013,37.295,0)""""><use xlink:href=""""#g113-51""""/></g><g transform=""""matrix(.013,0,0,-0.013,43.535,0)""""><path id=""""g113-45"""" d=""""M95 130C70 130 46 113 46 88C46 72 54 64 59 64C93 55 121 33 121 -3C121 -41 93 -68 44 -88L55 -117C117 -98 186 -56 186 22C186 91 131 130 95 130Z""""/></g></svg><span class=""""ipunc""""></span><svg xmlns:xlink=""""http://www.w3.org/1999/xlink"""" xmlns=""""http://www.w3.org/2000/svg"""" width=""""8.246pt"""" style=""""vertical-align:-3.429399pt"""" height=""""12.7373pt"""" version=""""1.1"""" viewBox=""""48.628183799999995 -9.3079 8.246 12.7373""""><g transform=""""matrix(.013,0,0,-0.013,48.678,0)""""><path id=""""g113-100"""" d=""""M383 397C383 424 344 448 299 448C244 448 172 409 132 375C66 319 23 227 23 146C23 42 74 -12 146 -12C208 -12 298 30 359 103L343 124C315 95 248 48 192 48C145 48 111 85 111 163C111 228 129 294 151 330C171 363 201 401 241 401C275 401 302 384 325 356C332 347 339 344 348 348C373 360 383 381 383 397Z""""/></g><g transform=""""matrix(.013,0,0,-0.013,53.96,0)""""><use xlink:href=""""#g113-45""""/></g></svg><span class=""""ipunc""""></span><span class=""""nowrap""""><svg xmlns:xlink=""""http://www.w3.org/1999/xlink"""" xmlns=""""http://www.w3.org/2000/svg"""" width=""""50.254pt"""" style=""""vertical-align:-3.429399pt"""" height=""""12.7373pt"""" version=""""1.1"""" viewBox=""""59.0531838 -9.3079 50.254 12.7373""""><g transform=""""matrix(.013,0,0,-0.013,59.103,0)""""><path id=""""g113-108"""" d=""""M480 416C480 431 465 448 438 448C388 448 312 383 252 330C217 299 188 273 155 237H153L257 680C262 700 263 712 253 712C240 712 183 684 97 674L92 648L126 647C166 646 172 645 163 606L23 -6L29 -12C51 -5 77 2 107 8C115 62 130 128 142 180C153 193 179 220 204 241C231 170 259 106 288 54C317 0 336 -12 358 -12C381 -12 423 2 477 80L460 100C434 74 408 54 398 54C385 54 374 65 351 107C326 154 282 241 263 299C296 332 351 377 403 377C424 377 436 372 445 368C449 366 456 368 462 375C472 386 480 402 480 416Z""""/></g><g transform=""""matrix(.013,0,0,-0.013,68.548,0)""""><path id=""""g117-33"""" d=""""M535 230V280H52V230H535Z""""/></g><g transform=""""matrix(.013,0,0,-0.013,79.084,0)""""><path id=""""g190-109"""" d=""""M238 0V26C174 32 166 38 166 104V712C132 700 70 683 18 677V653C81 647 87 645 87 577V104C87 38 78 32 15 26V0H238Z""""/></g><g transform=""""matrix(.013,0,0,-0.013,82.374,0)""""><path id=""""g190-112"""" d=""""M257 449C165 449 37 374 37 209C37 98 119 -12 256 -12C355 -12 473 65 473 226C473 349 381 449 257 449ZM244 416C333 416 380 320 380 204C380 67 329 21 267 21C184 21 130 115 130 241C130 354 184 416 244 416Z""""/></g><g transform=""""matrix(.013,0,0,-0";https://scholar.google.ch/scholar?start=790&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098751-80;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Neural Distributed Ledger;C Velasco, R Colomo;Palacios, R Cano  IEEE Software, 2020  ieeexplore.ieee.org;;"… appeared back in 2008 designed by Nakamoto, when the famous Bitcoin cryptocurrency

implemented this … to connect to other networks and with the Broker and Oracle behaviors. This

makes the extensibility of blockchain networks just dependent on configuration under this …";Cité 1 fois;Les 4 versions;[PDF] rcolomo.com;http://www.rcolomo.com/papers/373.pdf;"
  

Neural Distributed Ledger 

Carlos Velasco 

ByEvolution Creative Factory 

Ricardo Colomo-Palacios. 

Østfold University College 

RamĂłn Cano 

ByEvolution Creative Factory 

 

 

 

 

Abstract— In this paper, authors present a suite of solutions to both build and interconnect blockchain 

networks in big data environments authors call Neural Distributed Ledger (NDL) given its similarities to 

neurons aggregation. The solution presented here adopts a ledger-of-ledgers approach to perform the 

interconnection of multiple ledgers. Beyond interledger operability, it also enables the development of own 

blockchain-based solutions providing controlled costs and scalability while retaining decentralization and 

security. This solution has been tested in real environments with promising results. 

Keywords: Blockchain, Interledger 

 

 INTRODUCTION 

Blockchain is evolving towards maturity and wider 

applicability. This distributed ledger technology 

(DLT) supports collaborative processes by means of a 

shared, distributed and trusted dataset. Blockchain 

appeared back in 2008 designed by Nakamoto, when 

the famous Bitcoin cryptocurrency implemented this 

technology to be able to track and store transactions in 

a decentralized way. The implementation is based on a 

list of records of transactions sustained by means of a 

distributed consensus mechanism (Proof of Stake, 

Byzantine Fault Tolerance Algorithm, Proof of 

Work…) implemented over a peer-to-peer network. 

Nowadays this technology has been applied in 

various domains, industries and problem spaces [1], 

[2] with remarkable success. Recent studies also 

underline the crucial impact of this technology by 

granting a transformational role across most industries 

within five to 10 years [3].  

Blockchain now presents a variety of platforms 

(Ethereum, IBM Blockchain, Hyperledger Sawtooth, 

OpenChain, Hyperledger Fabric, Quorum …) that are 

considered the second generation of blockchain [4]. 

These platforms are playing a crucial role in 

blockchain adoption allowing software practitioners to 

develop blockchain apps with ease. Developers adopt 

these platforms based on standard factors like 

previous experience, supported language, cost of 

operation, popularity, type of network or support. The 

result of this variety of platforms is the fact that 

diverse blockchains are operating in parallel and some 

more will appear in the arena to complicate even more 

the current panorama. In this scenario, interconnecting 

blockchains in a secure and efficient way is key in 

order to guarantee a universal, unified, and non-

segregated realm for distributed ledgers [5]. The so-

called, third generation of blockchain solutions is 

 

 



 

2  

 

 

aimed to improve the known flaws of previous 

generations, e.g. interoperability and network speed. 

In this paper, authors present a suite of solutions to 

both build and interconnect blockchain networks in 

big data environments authors call NDL given its 

similarities to neurons aggregation in the creation of 

interconnected subsets. The solution presented here 

adopts a ledger-of-ledgers approach to perform the 

interconnection of multiple ledgers. However, beyond 

interledger operability, by means of a suite of 

products, the technology also enables the development 

of own scalable blockchain-based solutions while 

retaining decentralization and security. 

THE APPROACH 

Information silos are traditional problems in 

information systems from the very beginning of 

computing [6]. In recent times, fragmentation and lack 

of interoperability are major issues in several 

scenarios including DLT-based solutions. According 

to a recent paper [5], blockchain interledger 

approaches can be divided into the following 

categories: 

1.Atomic cross-chain transactions. This is normally 

performed by means of atomic swaps that, in a 

nutshell, encompasses launching transactions in the 

different blockchains ensuring atomicity through 

hash-locks and time-locks without the need to trust a 

third party.  

2.Transactions across a network: Lightning and 

Raiden. Both solutions are based on the 

interconnection of micropayment channels, the first 

depending on the Segwit Bitcoin extension and the 

second on the Raiden Network.  

3.Layered value transfer protocols (World Wide 

Web Consortium Interledger Protocol, ILP). W3C 

issued a generic and open protocol intentionally 

limited in scope to deliver the aspects necessary to 

perform a payment from a source to a destination over 

an interconnected system of ledgers 

4.Bridging approaches. These approaches entail 

modules running on the nodes of the two 

interconnected chains considered hierarchically equal. 

Examples of these implementations are Blocknet, 

Wanchain or ARK. 

5.Sidechains. Normally used to move assets from 

one main blockchain to other sidechain. The reasons 

behind this decision are lower transaction costs, 

different functionalities and the most common one, 

better confirmation times. There are different 

implementations of sidechains including Cardano, 

Liquid or Plasma. 

6.Ledger-of-ledgers approaches. This approach is 

based on the introduction of a super-ledger acting as 

the intermediary when two ledgers need to 

communicate. Adopting this solution will provide 

same previously reported benefits but also entails a 

high complexity. Implementations include Cosmos, 

Uberledger and Polkadot. 

The latter is the approach adopted in the solution 

presented in this paper that includes two different 

components designed to work together. Firstly, a new 

implementation of blockchain designed to be applied 

in massive environments (NDL Retis) and, on the top 

of it, a blockchain network adopting a ledger of 

ledgers approach aimed to connect different 

blockchains (NDL Integra). In what follows, a 

description of the solution is provided.  

Firstly, it is proposed a multidimensional and 

collaborative blockchain environments (NDL Retis) 

designed to work in massive environments. 

Specifically, it presents the following features: 

•The network is divided into interconnected 

subsets of groups working in parallel, allowing to 

process as many blocks as working groups per unit of 

time, thus, maximizing the number of transactions in 

the network. 

•Intersections between sets or working groups 

protect the network in a similar way to what a block 

protects the previous ones in the traditional 

blockchain. 

•It is possible to scale vertically by adding new 

nodes to the different work groups. 

•Scales horizontally by adding new sets of nodes 

without compromising network performance. 

•Allows programmed obsolescence of information 

in the network but also provides mechanisms to store 

relevant information by means of policies. 

•A rise in the number of nodes increases the 

storage capacity of the network. 

•Distributes the information in domains and 

fragments along the network. 

•A node does not have all the information records 

in the database (security). 

•Implements two different consensus algorithms, 

one that rules the working group and one for the entire 

network, aimed to merge information present in 

different working groups. 

•It is designed to work just in private networks. 



 3 

 

 

As a consequence of these features, Retis presents 

the following advantages compared to traditional 

blockchains: 

•Work is segmented among working groups 

leading to better throughput and scalability. Apart 

from that, in cases in which data to handle by the 

blockchain is heavy (e.g. documents, video…), 

traditional blockchains could collapse after just some 

transactions. 

•Given the structure of working groups, when the 

network increases in number of nodes, the overall 

throughput is higher, confronting with first generation 

blockchains. 

•Not all nodes present the same information and 

information is distributed among nodes so average 

storage capacity of the network is not “the minimum 

storage capacity of the nodes”. Moreover, 

actualization or addition of new nodes does not 

require high bandwidth and update time.  

•There is a policy-based mechanism to set 

obsolescence to certain data including the storage of 

such obsolete data into specific storage nodes, so there 

is not a need to build another blockchain network 

when the current is collapsed given the impossibility 

to erase data (traditional blockchain is append-only). 

The second component of the solution is NDL 

Integra. Integra makes possible to connect different 

blockchain networks in a transparent, certified, secure, 

auditable and fully traceable way by means of a 

ledger-of-ledgers approach. By means of an API, 

Integra is capable of providing a set of standardized 

actions in the network including update, composition, 

decomposition, transfer, erase or history. In a NDL 

Integra network, each node collaborates to maintain 

the global register of actions applied to all stored 

value object (GVL - Global Value Ledger) while 

connecting as a client to one or more DLT networks. 

By connecting to a NDL Integra network, each 

node acts as a delegation broker, which allows users 

to operate on objects hosted on that network, even if 

they do not have their own access and operation 

certificates. Thus, the node receives the order to act on 

an object and executes the operation whenever the 

minimum security requirements stipulated by the 

network that hosts it are fulfilled, recording the result 

of the operation in the GVL. 

In the network, each node also acts as a certified 

oracle that facilitates the automated incorporation of 

data in the client network. A node in an integrated 

environment is a normal blockchain node (NDL Retis 

node) enriched with features to connect to other 

networks and with the Broker and Oracle behaviors. 

This makes the extensibility of blockchain networks 

just dependent on configuration under this schema. In 

other words, Integra is a specialization of Retis with 

the purpose of interledger connection. 

In sum, by means of Retis and Integra, it is 

possible to build a cluster of blockchain networks to 

get advantage of the following benefits and 

contributions: 

•Greater ability to serve clients in parallel. 

•Decrease in the average registration latency. Each 

network in the cluster writes in its internal ledger one 

block in each turn. 

•Network storage scaling.  

•The negative impact on consensus latency is 

minimized by adding new signatory nodes, as these 

can be distributed among the different networks of the 

cluster. 

THE BUSINESS ROADMAP 

In spite of the importance of Blockchain and its 

increased number of implementations, this technology 

is not applicable everywhere every time. In a nutshell, 

Blockchains are a good fit for ecosystems but not 

necessarily for single entities. Scriber [2] presented a 

framework for determining blockchain applicability. 

In this work, ten architecture or blockchains’ 

characteristics are assessed and weighted through an 

evaluation matrix to determine blockchain`s level of 

fit. These characteristics are: Immutability, 

Transparency, Trust, Identity, Distribution, Workflow, 

Transactions, Historical record, Ecosystem and 

Inefficiency. However, this framework is intended to 

be adopted by software architects and, in our 

experience, business factors also must be considered 

in the assessment of blockchain applicability. Another 

recent effort to evaluate the need of a blockchain in 

smart factories is presented in [7]. In this case, authors 

present a flow diagram assessing several business and 

technological aspects. However, the applicability of 

the proposal outside smart factories environments is 

limited. 

Following an action research approach [2], authors 

present a set of assumptions that lead to a rapid and 

business-oriented DLT applicability assessment. In 

order to define which environments are suitable for 

DLT, seven different aspects must collide in the 

project: 

I.There are different and independent entities 

involved in the use case 

II.These entities need to share parts of information 

in order to participate in the system 

III.Information exchanges must be regulated by 

formal procedures 



 

4  

 

 

IV.Information exchange traceability must be 

certified 

V.Transparency is required among actors 

VI.Process automation is key for the system 

VII.Information fragments shared among players 

must be valuable 

This simplified set of questions could lead to a first 

and swift decision to pursue a Blockchain project. In 

our experience, some C suite workers blinded by the 

blockchain supernova, push CIOs or CTOs towards 

DLTs solutions without a previous evaluation of the 

applicability of the technology. These seven questions 

could be the tool for software practitioners and their 

technical managers to tackle the hype problem many 

professionals are facing in their jobs. 

THE TESTING 

When needed, blockchain has been applied to 

ensure data integrity while transferring sensible data 

[8]. However, as the demand of computing power rose 

because of the use of Blockchain-based solutions, 

challenges on performance and operability began to 

appear. In scenarios in which computing power is 

limited e.g. Internet of things (IoT), these challenges 

are more tangible.  

In this section, we present results of a case study 

on the adoption of NDL in an IoT environment. 

As a proof of concept, NDL nodes were embedded 

within electric vehicle charging devices implemented 

over Raspberry Pi III Model B nodes. Initial tests 

installing some commercial blockchain nodes in such 

devices reported high temperatures and loss of 

performance and operability. The testing setup 

includes a Retis network with complete physical 

nodes implemented on virtual machines (10 nodes) 

and a Retis network with experimental nodes 

specifically designed for Raspberry Pi III devices. 

Both networks were interconnected with a 3-node 

NDL Integra Network implemented on virtual 

machines in an environment independent of the other 

two networks. 

In order to validate the applicability of NDL, we 

tested three of these devices during three weeks 

measuring device temperature and CPU usage (%). 

This setup was tested with different latencies, namely 

10, 5, 1 and 0.2 seconds. The three devices were 

encapsulated in solid cases without ventilation, in a 

cool and dry environment with an ambient 

temperature of 21ÂşC. Software installed in the three 

devices is a NDL node and connector developed in 

J2SE. Connectors worked as follows: 

THREAD1 

While True 

Calculate sending data 

Apply RSA 512 on data 

Select 10 nodes in the network with less latency 

For each Node 

Throw a new thread 

Encrypt the data with the peer public key 

If Connection 

Send data to peer 

Obtain answer 

Calculate peer new latency 

Update peers file (new latency) 

Close connection 

Else 

Update peer (maximum latency) 

End  

End 

Hold 10000ms 

End 

 

THREAD2 

While True 

Select 10 nodes in the network with less lag 

For each Node 

Throw a new thread 

If Connection 

Send request to peer of its known peers 

Obtain answer 

Calculate peer new latency 

Update peers file (new latency) 

Add new nodes (zero latency) 

Close connection 

Else 

Update peer (maximum latency) 

End  

End 

Hold 30000ms 

End 

Results presented in Figure 1, show the averages of 

temperature and CPU usage (%) in the four scenarios 

(10, 5, 1 and 0.2 seconds latencies) measured in 24 

periods of 12 hours. Temperature is pictured in the 

primary axis (vertical left). In the secondary axis 

(vertical right), CPU usage is coded.

 



 5 

 

 

 

Figure 1. Graph on the measurements of the experiment (Temperature and CPU consumption) 

 

Results show a very low CPU usage reaching to 

1% only in few cases, just the ones with lower 

latency. Regarding temperature, in general, higher 

temperatures are measured in cases of lower latency 

too. There is also a light correlation of high 

temperature with CPU usage. There were no 

significant differences among the three devices. 

Moreover, there are not significant differences 

between the behavior of the three devices with the 

installed software and the average operating values set 

by the manufacturer (peak temperatures of 66 Celsius 

in stress-test settings). 

In sum, we can conclude that NDL is capable of 

working in this environment without compromising 

performance and operability. 

CONCLUSIONS 

In this paper authors present NDL, a Blockchain 

platform that is aimed to tackle some of the known 

problems of distributed ledgers solutions: 

interoperability, network speed and storage problems. 

The presented technology is able to be deployed as a 

single blockchain network (Retis) but also, by means 

of configuration, to act as a ledger-of-ledgers in the 

connection with different blockchain networks 

(Integra). In sum, this can be considered a third 

generation blockchain network, being this the main 

contribution of the work.  

NDL is currently in the commercialization phase and 

authors are currently working in the extension of the 

features of the suite, but also in the creation of 

customized solutions to different sectors and 

customers. 

 REFERENCES 
[1] N. Kshetri, “Blockchains and International Business,” IT 

Prof., vol. 21, no. 4, pp. 8–13, Jul. 2019. 

[2] B. A. Scriber, “A Framework for Determining 

Blockchain Applicability,” IEEE Softw., vol. 35, no. 4, pp. 

70–77, Jul. 2018. 

[3] Gartner, “Gartner 2019 Hype Cycle for Blockchain 

Business Shows Blockchain Will Have a Transformational 

Impact across Industries in Five to 10 Years,” Gartner, 

2019. [Online]. Available: 

https://www.gartner.com/en/newsroom/press-

releases/2019-09-12-gartner-2019-hype-cycle-for-

blockchain-business-shows. [Accessed: 04-Nov-2019]. 

[4] W. Chen, Z. Zheng, E. C.-H. Ngai, P. Zheng, and Y. 

Zhou, “Exploiting Blockchain Data to Detect Smart Ponzi 

Schemes on Ethereum,” IEEE Access, vol. 7, pp. 37575–

37586, 2019. 

[5] V. A. Siris, P. Nikander, S. Voulgaris, N. Fotiou, D. 

Lagutin, and G. C. Polyzos, “Interledger Approaches,” 

IEEE Access, vol. 7, pp. 89948–89966, 2019. 



 

6  

 

 

[6] R. L. Nolan, “Managing the Computer Resource: A 

Stage Hypothesis,” Commun ACM, vol. 16, no. 7, pp. 399–

405, Jul. 1973. 

[7] T. M. Fernández-Caramés and P. Fraga-Lamas, “A 

Review on the Application of Blockchain to the Next 

Generation of Cybersecure Industry 4.0 Smart Factories,” 

IEEE Access, vol. 7, pp. 45201–45218, 2019. 

[8] S. Tuli, R. Mahmud, S. Tuli, and R. Buyya, “FogBus: A 

Blockchain-based Lightweight Framework for Edge and 

Fog Computing,” J. Syst. Softw., vol. 154, pp. 22–36, Aug. 

2019. 

 

Carlos Velasco is CIO at ByEvolution Creative Factory. 

He got her bachelor in Computing from Universidad 

Castilla-La Mancha and has been working as software 

engineer in the last fifteen years. Contact him at 

carlos.velasco@byevolution.com  

 

Ricardo Colomo-Palacios, IEEE Senior Member, is a full 

professor in the Computer Science Department at Østfold 

University College. Colomo-Palacios received a PhD in 

computer science from the Universidad PolitĂŠcnica of 

Madrid. Contact him at ricardo.colomo-palacios@hiof.no  

RamĂłn Cano is CEO at ByEvolution Creative Factory. 

With more than 30 years of experience in IT Consultancy 

in companies like Nixdorf and Indra, he started 

ByEvolution two years ago. His research interests 

include quantum computing, blockchain technology and 

intelligent organizations. Contact him at 

ramon.cano@byevolution.com 

  


";"""date"",""2020-05-08T16:07:24Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.5""
""xmp:CreatorTool"",""MicrosoftÂŽ Word 2016""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dc:creator"",""Devendra Kumar""
""language"",""en""
""dcterms:created"",""2020-05-08T16:07:24Z""
""Last-Modified"",""2020-05-08T16:07:24Z""
""dcterms:modified"",""2020-05-08T16:07:24Z""
""dc:format"",""application/pdf; version=1.5""
""Last-Save-Date"",""2020-05-08T16:07:24Z""
""pdf:docinfo:creator_tool"",""MicrosoftÂŽ Word 2016""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2020-05-08T16:07:24Z""
""meta:save-date"",""2020-05-08T16:07:24Z""
""pdf:encrypted"",""false""
""modified"",""2020-05-08T16:07:24Z""
""Content-Length"",""570160""
""pdf:hasMarkedContent"",""true""
""Content-Type"",""application/pdf""
""pdf:docinfo:creator"",""Devendra Kumar""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Devendra Kumar""
""dc:language"",""en-US""
""meta:author"",""Devendra Kumar""
""meta:creation-date"",""2020-05-08T16:07:24Z""
""created"",""2020-05-08T16:07:24Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""6""
""Creation-Date"",""2020-05-08T16:07:24Z""
""resourceName"",""373.pdf""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""2653"",""4419"",""4845"",""3290"",""2455"",""1353""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""Author"",""Devendra Kumar""
""producer"",""MicrosoftÂŽ Word 2016""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""MicrosoftÂŽ Word 2016""
""pdf:docinfo:created"",""2020-05-08T16:07:24Z""
";https://scholar.google.ch/scholar?start=620&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098888-385;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Constant-size ring signature scheme using multilinear maps;X Zhang, Z Liu, XA Wang… ; International Journal of …, 2020  inderscienceonline.com;;"… constant, but linear, sub-linear or logarithmic to the number of ring members as shown in Table

1. At the same time, many ring schemes are proven secure by using the random oracles, which

are heuristic and insecure when any real function is substituted for the random oracle …";Autres articles;;null;;;;https://scholar.google.ch/scholar?start=930&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098804-198;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;[PDF][PDF] Unifying Presampling via Concentration Bounds;S Guo, Q Li, Q Liu, J Zhang ; eprint.iacr.org;;"… (EUROCRYPT' 18) and Coretti et al. (CRYPTO' 18) … Definition 1 (Algorithm with Advice). An (S,

T) (query) classical/quantum algorithm A = (A1, A2) with (oracle-dependent) advice consists of

two proce- dures: – let H, ˜H be two oracles accessed by A1, A2 respectively in the …";Autres articles;Version HTML;[PDF] iacr.org;https://eprint.iacr.org/2020/1589.pdf;"
Unifying Presampling via Concentration Bounds

Siyao Guo1, Qian Li2, Qipeng Liu3 and Jiapeng Zhang4

1 New York University Shanghai
2 Shenzhen Institute of Computing Sciences

3 Princeton University
4 University of Southern California

Abstract. Auxiliary-input idealized models, such as the auxiliary-input
random oracle model and the auxiliary-input random permutation model,
play a critical role in assessing non-uniform security of symmetric-key
and hash-function constructions. However, obtaining security bounds in
these models are often much more challenging than in traditional ideal-
ized models.
The presampling technique, introduced by Unruh (CRYPTO’ 07), gener-
ically reduces security proofs in the auxiliary-input models to a much
simpler bit-fixing models. This technique has been further optimized by
Coretti, Dodis, Guo, Steinberger (EUROCRYPT’ 18), and generalized
by Coretti, Dodis, Guo (CRYPTO’ 18), resulting in powerful tools for
proving non-uniform security bounds in various idealized models, includ-
ing random oracle models (ROM), random permutation models (RPM),
ideal cipher models (ICM) and generic group models (GGM).
We study the possibility of unifying and leveraging the presampling tech-
nique to the quantum world. To this end,

– We show that such leveraging will resolve a major open problem
in quantum computing, which is closely related with the famous
Aaronson-Ambainis conjecture (ITCS’ 11).

– Faced with this barrier, we give a new but equivalent bit-fixing model
and a simple proof of presampling techniques for arbitrary oracle
distribution and access in the classical setting, including AI-ROM
and AI-RPM. Our security loss matches the security loss of the best
known presampling technique by Coretti et al. (EUROCRYPT’ 18)
for both indistinguishability and unpredictability applications. Our
new proof unifies previous results by Coretti et al. (EUROCRYPT’
18) and Coretti et al. (CRYPTO’ 18).

– We leverage our new classical presampling techniques to a novel
“quantum bit-fixing version” of presampling. The security loss of our
quantum bit-fixing presampling also matches the optimal security
loss of the classical presampling. Using our techniques, we give the
first post-quantum non-uniform security bounds for salted Merkle-
Damg̊ard hash functions.



1 Introduction

Practical symmetric-key and hash-function constructions are typically designed
and analyzed in idealized models, such as random oracle model (ROM), random
permutation model (RPM) and ideal-cipher model (ICM). Since most construc-
tions of block ciphers and hash functions lack of solid theoretical foundations
from the point of view of provable security, security bounds in idealized mod-
els provide an essential (heuristic) justification for their security. In particular,
the exact security bounds obtained in such idealized models are often viewed
as guidelines for both designers and cryptanalysis in terms of the best possible
security level that can be achieved in the standard model.

Though idealized models capture all attacks that do not exploit the structure
of a particular instantiation of the underlying primitive, they fail to capture
preprocessing attacks. The obtained bounds in idealized model are inaccurate or
not applicable at all once preprocessing is allowed. For example, Hellman [Hel80]
showed a preprocessing attack that takes S bits of advice and makes T queries
to a permutation f : [N ] → [N ] and inverts a random element of [N ] with
probability roughly ST/N . Hence, a permutation cannot be one-way against
attacks beyond S = T = N1/2. However, it is easy to derive in RPM that
a random permutation is invertible with probability at most T/N , suggesting
security against attacks up to size N . Notice that the gap between N and N1/2

matters for practical constructions. For example, while N suggests a 128-bit level
security for 128-bit block cipher (e.g., 128-bit AES), N1/2 only suggests 64-bit
security.

Auxiliary-input models. To address the mismatch between idealized models and
preprocessing attacks, auxiliary-input extensions of idealized models have been
proposed, such as auxiliary-input random oracle model (AI-ROM), auxiliary-
input random permutation model (AI-RPM) and auxiliary-input ideal cipher
model (AI-ICM) [Unr07,DGK17,CDGS18,CDG18]. In AI models, an attacker
is allowed to obtain arbitrary S bits of leakage about the idealized primitive
before attacking the system, then use additional T queries to the primitive.
Similar as that in the idealized models, security bounds obtained in AI models
become the main source of justification and guidelines of the security level against
preprocessing attacks (or more generally non-uniform attacks).

While AI models are simple extensions of well studied idealized models, they
often do not offer simple and intuitive way to prove security bounds. Moreover,
it becomes much more challenging to prove exact security bounds, which are
demanded by practical relevance. For example, it is not straightforward how we
should analyze inverting a random permutation f : [N ]→ [N ] given S-bit advice
(even for S = 1) and T queries in AI-RPM, let alone proving a ST/N bound,
matching Hellman’s attack.

The compression technique. For the specific question of permutation inver-
sion, an optimal ST/N bound was first proved [DTT10] via the “compres-
sion paradigm”, as introduced by Yao [Yao90], Gennaro and Trevisan [GT00]

2



(and later adopted by [Wee05]). The main idea is to argue if an attacker suc-
ceeds with “high probability” in inverting a random permutation, then we can
use this attacker to build a shorter representation of (i.e., compress) the ran-
dom permutation than what is possible from an information-theoretical point
of view. Compression paradigm is a general technique which can be applied to
different problems in auxiliary-input models. In fact, compression paradigm has
been successfully applied to (auxiliary-input) random oracle models by Dodis
et al. [DGK17], and (auxiliary-input) generic group model (GGM) by Corrigan-
Gibbs and Kogan [CK18]. While compression based proofs often lead to optimal
bounds, they are usually quite laborious. For every cryptographic construction
to be analyzed, we need to carefully examine the property of the construction
together with its security definition in order to compress the idealized primi-
tive. Moreover, compression based proofs seem inapplicable to computationally
secure applications. This limits the usage of this technique for analyzing more
sophisticated constructions or practical constructions based on computational
assumptions.

The presampling technique. A much simpler and intuitive proof for permuta-
tion inversion has been given by Coretti et al. [CDG18], by adapting the “pre-
sampling” approach taken by Coretti et al. [CDGS18] (and first introduced
by [Unr07]) in the random oracle model. The presampling technique can be
viewed as a general reduction from AI models to a much simpler bit-fixing model
(BF) model, where the oracle can be arbitrarily fixed on some P coordinates cho-
sen by the attacker, for some parameter P , but then the remaining coordinates
are chosen at random and independently of the fixed coordinates. Importantly,
the online attacker only knows the fixed coordinates. This makes BF models
particularly easier to work with, because most proofs techniques for idealized
models can be applied as long as we avoid the fixed coordinates.

Specifically, Coretti et al. [CDG18] and Coretti et al. [CDGS18] show that any
attack with S-bit advice and T oracle queries in AI-ROM/RPM/ICM/GGM will
have similar advantage in their corresponding P -BF models for an appropriately
chosen P , up to an additive loss of δ(S, T, P ) = ST/P (which is optimal shown
by Dodis et al. [DGK17]). Moreover, for the special case of unpredictability
applications (such as one-way function), one can set P to be roughly ST and
achieve a multiplicative factor of 2 in the exact security.

This results in a general way for proving security in AI models. For a cryp-
tographic application in an AI-model, we first analyze its security in the cor-
responding P -BF model and obtain security bounds Îľ(S, T, P ), then choose P
to optimize δ(S, T, P ) + ξ(S, T, P ). For an unpredictability application, its se-
curity in the AI model is just roughly 2 ¡ ξ(S, T, ST ), i.e., twice of its security
in the (ST )-BF model. As an example, in the (ST )-BF-RPM, it can be easily
shown that a random permutation f : [N ]→ [N ] is invertible with probability at

3



most O(ST/N) 5. Therefore it immediately gives the optimal O(ST/N) bound
(matching Hellman’s attack) in AI-RPM.

The presampling technique offers a much simpler approach for proving secu-
rity bounds in AI models than the compression technique. By presampling tech-
niques, Coretti et al. [CDG18] and Coretti et al. [CDG18] using simpler proofs
recover the AI-ROM/RPM/GGM security bounds obtained by the compression
technique [DTT10,DGK17,CK18], and give the first non-uniform bounds for
a number of important practical applications (which compression appears in-
tractable), such as (salted) Merkle-Dam̊gard hash functions (MDHF). Chung et
al. [CLMP13] study the effects of salting in the collision-resistant hash functions
and argues that salting defeats preprocessing in this case.

We remark that the optimal additive loss and multiplicative version of pre-
sampling techniques in [CDG18,CDGS18] are crucial for obtaining exact bounds.
As shown by Dodis et al. [DGK17], the presampling technique by Unruh [Unr07]
with security loss

√
ST/P yields sub-optimal bounds for many applications.

Moreover, even with optimal additive loss, the indistinguishability version of
presampling only yields

√
ST/N security bounds (therefore useless for obtain-

ing optimal bounds) for one-way functions.

A new challenge: quantum adversaries. Quantum algorithms can efficiently break
many widely used assumptions for public key cryptography (such as factoring).
Can they break practical symmetric-key and hash function constructions? How
much security these constructions have to compromise for quantum adversaries?
What if preprocessing is allowed?

To capture quantum adversaries, quantum extensions of idealized models
have been considered such as the quantum random oracle model (QROM) [BDF+11],
in which the attacker makes T superposition queries to the idealized primi-
tive. Very recently, demanded by assessing post-quantum non-uniform security
of symmetric-key and hash function, quantum versions of AI models have been
proposed and studied [NABT15,HXY19,CLQ19,CGLQ20], in which the adver-
sary is allowed to obtain S (qu)-bit precomputed advice about the idealized
primitive.

By leveraging classical compression proofs, [NABT15,HXY19,CLQ19] obtain
many security bounds. However, they only manage to analyze very basic appli-
cations such as one-way functions. Even for the basic question like inverting a
random permutation with S-bit (classical) advice and T quantum queries, com-
pression proofs give a sub-optimal bound ST 2/N . The success of presampling
techniques in the classical setting motivates the main questions we study in this
paper:

Can we leverage presampling techniques to the quantum setting?

5 If the challenge f(x) doesn’t come from the fixed coordinates, then a proof by stan-
dard techniques bounds the probability of f(x) by O(T/N). The probability that
f(x) comes from the fixed coordinates is at most ST/N when x is uniformly chosen
from [N ]. Therefore, the overall probability of inverting f(x) is O(ST/N)

4



Specifically, we hope to reduce the AI quantum models to simpler BF quan-
tum models, then export similar proofs from quantum idealized models. More-
over, we hope to leverage security proofs proven using classical presampling
techniques to the quantum setting.

Recently, Chung et al. [CGLQ20] give a new general technique for ana-
lyzing AI models for quantum adversaries. This technique reduces (Q)AI se-
curity against attackers with (quantum) advice to analyzing a multi-instance
(MI) security against attackers without advice. They use this technique to prove
ST/N + T 2/N bound for inverting random functions in the AI-QROM model.
Although the new technique is quite general and easier to use than compression,
it inherently requires a proof of direct product type statement, to show the se-
curity of multiple-instance has an exponential decay in the number of instances.
For practical symmetric key and hash function constructions, proving such state-
ments may be challenging. On the contrast, analyzing a single-instance in the
BF-model is considerably simpler.

1.1 Our Results

One natural attempt to develop quantum presampling is to leverage the opti-
mal presampling lemma of Coretti et al. [CDGS18] for ROM (which has been
exported to ICM/RPM/GGM by Coretti et al. [CDG18]).

Barriers for leveraging presampling to the quantum setting. In Section
3, we show that such leveraging has a technical barrier: it resolves a major open
problem in quantum computing [AA11], namely Conjecture 1, which asserts
that any quantum algorithm can be approximated on most inputs by a classical
algorithm which is at most polynomially slower in terms of query complexity.
This open problem, dating back to (according to [AA11]) 1999 or earlier, was
included twice in Aaronson’s list of “ten semi-grand challenges for quantum
computing theory” [Aar05b,Aar10].

In [AA11], Aaronson and Ambainis proposed an approach, which became
well-known as the Aaronson-Ambainis conjecture, towards this open problem
via analysis of Boolean function. In specific, Aaronson-Ambainis conjecture as-
serts that any bounded low-degree function on the discrete cube has a vari-
able with influence poly(Var[f ]/ deg(f)) (see Conjecture 2). Despite much effort
[DFKO06,Bac12,OY16,MA12,KK19], this open problem and the closely related
Aaronson-Ambainis conjecture seem still quite open: only some special functions
are confirmed [Bac12,OSSS05,MA12], and the best-known bound for general
functions is still exponentially far from the conjectured bound [DFKO06,OY16,DMP17].

Unifying presampling via concentration bounds. Facing with this barrier,
we revisit the presampling techniques in the classical setting. To this end, with
only standard concentration bounds, we give a simpler and unified proof for
the classical presampling theorems of both ROM [CDGS18] and RPM [CDG18],
using an equivalent characterization of P -BF-ROM/P -BF-RPM.

5



Instead of viewing P -BF-ROM as a random function/oracle with at most
P prefixed inputs/outputs, we define it by a classical randomized algorithm f
making at most P queries. The random function is sampled in the following
way: sample a random H, compute fH ; restart the whole procedure (including
sampling a random function H) if the output of fH is not 1. In other words,
it defines a distribution over all functions conditioned on fH outputs 1. The
security game then is under the oracle access to the function H.

With the concentration bounds and the alternative definition, we show a
unified proof for the classical presampling theorems. The proof is much simpler
than the original proof [CDGS18], as the original proof needs to first decompose
a random oracle distribution H with advice into dense distributions (a technique
used in the area of communication complexity [GLM+16]), and then argue indis-
tinguishability between a dense distribution and a uniform distribution. With
almost no additional effort, the proof can be used to achieve the theorem for
AI-RPM, in [CDG18]. Note that the proof is optimal, as it matches the theorem
in [CDGS18], which is known to be optimal. Again the small additive security
loss and the multiplicative version are particularly appealing for obtaining exact
bounds.

Quantum presampling and applications to quantum random oracles.
With the new definition, it is natural to adapt the definition of P -BF-ROM
to P -BF-QROM. P -BF-QROM is defined by a P -query quantum algorithm f
making superposition queries. Similarly, the random function is sampled in the
following way: sample a random H, compute fH ; restart the whole procedure
(including sampling a random function H) if the output of fH is not 1.

Using the same proof for classical presampling, we obtain the quantum pre-
sampling.

Theorem 1. For any P ∈ N and every γ > 0, if a security game G is ξ(T )-
secure in the P -BF-QROM, then it is (S, T, ε′)-secure in the AI-QROM, for
some ε′ such that,

ε′(S, T ) ≤ ε(T ) +
(S + log γ−1)T comb

P
+ Îł.

If G is ε(T )-secure in the P -BF-QROM for P ≥ (S + log γ−1)T comb, then it is
(S, T, ε′)-secure in the AI-QROM, for some ε′ such that,

ε′(S, T ) ≤ 2 · ε(T ) + γ.

T comb = T + TVer is the combined query complexity and TVer is the query com-
plexity for the challenger .

Note that it is optimal in the sense that it exactly matches the classical
presampling theorem, which is optimal.

Therefore, to obtain security in the AI-QROM, one needs to obtain its secu-
rity in the P -BF-QROM. We show Zhandry’s compressed oracle [Zha19] would

6



be a useful tool for deriving bounds in the P -BF-QROM, by presenting the
first non-trivial security analysis of (salted) Merkle-Dam̊gard Hash Functions
(MDHF) in the P -BF-QROM and AI-QROM.

Theorem 2. GMDHF is ξ(S, T ) = Õ(ST 3/M)-secure in the AI-QROM.

In the classical setting, Coretti et al. [CDGS18] show an attack with ad-
vantage Ω(ST 2/M) (which is optimal), and Akshima et al. [ACDW20] show an
attack for 2-block MDHF with advantage Ω((ST+T 2)/M). We observe that the
attack by Akshima et al. [ACDW20] can be extended to the quantum setting,
and yield an attack with advantage ST 2/M + T 3/M . However, it is not clear if
the attack of Coretti et al. [CDGS18] can be extended to the quantum setting
because of the usage of function iteration in the attack. Our bound suggests that,
the speedup of quantum adversaries is limited to a factor T . Further closing this
gap is an intriguing question.

1.2 Open Problems

Optimal Presampling for Quantum Advice. While our work provides a frame-
work for the presampling technique for classical advice, we are not able to give
presampling techniques for quantum advice. The difficulty comes from the fact
that quantum advice would be completely destroyed once a single round of on-
line computation was done. Note that the barrier would be overcome using the
similar idea in [CGLQ20], by boosting the succeeding probability and apply-
ing Gentle Measurement Lemma [Aar05a]. However, we suspect the resulting
statement may not be optimal.

Bit-Fixing Security of One-Way Permutations. While P -BF-QRPM (quantum
random permutation model) is well defined following our definition for P -BF-
QROM, it is not clear how to prove the security in this model. We hope one
of the following two approaches would work: (1) analyzing the probability dis-
tribution of the permutations in P -BF-QRPM, and using one-way to hiding
lemma [AHU19] to derive the bound for the online computation; (2) with “com-
pressed permutation” techniques similar to Zhandry’s compressed oracle tech-
niques, a similar proof to that in the P -BF-QROM would be possible.

Closing the gap for MDHF. As discussed in the previous section, closing the gap
for the security of MDHF in the AI-QROM is also an intriguing question.

2 Preliminaries

For any n ∈ N, we denote [n] to be the set {1, 2, ..., n}. We denote Z/nZ =
{0, 1, ..., n − 1} as the ring of integers modulo n, and F2 = {0, 1} as the binary
finite field. For a complex vector x ∈ Cn, we denote the L2-norm |x| = |x|2 =√∑

i∈[n] xixi. In algorithms, we denote a ←$ A to be taking a as a uniformly

independently sampled element of A.
Next, we recall some basic facts about quantum computation, and review the

relevant literature on the quantum random oracle model.

7



2.1 Quantum Computation

A quantum system Q is defined over a finite set B of classical states. A pure
state over Q is a unit vector in C|B|, which assigns a complex number to each
element in B. In other words, let |φ〉 be a pure state in Q, we can write |φ〉 as a
column vector:

|φ〉 =
∑
x∈B

αx|x〉

where
∑
x∈B |αx|2 = 1 and {|x〉}x∈B is called the “computational basis” of C|B|.

The computational basis forms an orthonormal basis of C|B|. We define 〈φ| to
be the row vector that is the conjugate of |φ〉.

Given two quantum systems Q1 over B1 and Q2 over B2, we can define a
product quantum system Q1 ⊗ Q2 over the set B1 × B2. Given |φ1〉 ∈ Q1 and
|φ2〉 ∈ Q2, we can define the product state |φ1〉 ⊗ |φ2〉 ∈ Q1 ⊗Q2.

We say |φ〉 ∈ Q1 ⊗ Q2 is entangled if there does not exist |φ1〉 ∈ Q1 and
|φ2〉 ∈ Q2 such that |φ〉 = |φ1〉 ⊗ |φ2〉. For example, consider B1 = B2 = {0, 1}
and Q1 = Q2 = C2, |φ〉 = |00〉+|11〉√

2
is entangled. Otherwise, we say |φ〉 is

unentangled.
A state |φ〉 ∈ Q can be manipulated by a unitary operator U ∈ C|B|×|B|. The

resulting state |φ′〉 = U |φ〉. We denote the trace norm ‖U‖tr to be 1
2 Tr
√
U†U .

We extract classical information from a quantum state |φ〉 by performing a
measurement. A measurement is specified by an orthonormal basis, typically the
computational basis, and the probability of getting result x is |〈x|φ〉|2. After the
measurement, |φ〉 “collapses” to the state |x〉 if the result is x.

For example, given the pure state |φ〉 = 3
5 |0〉+

4
5 |1〉 measured under {|0〉, |1〉},

with probability 9/25 the result is 0 and |φ〉 collapses to |0〉; with probability
16/25 the result is 1 and |φ〉 collapses to |1〉.

We assume quantum circuits can implement any unitary transformation (by
using these basic gates, Hadamard, phase, CNOT and π

8 gates), in particular
the following two unitary transformations:

– Classical Computation: Given a function f : X → Y , one can im-
plement a unitary Uf over C|X|·|Y | → C|X|·|Y | such that for any |φ〉 =∑
x∈X,y∈Y αx,y|x, y〉,

Uf |φ〉 =
∑

x∈X,y∈Y
αx,y|x, y ⊕ f(x)〉

Here, ⊕ is a commutative group operation defined over Y . In particular, if
f is given as a classical circuit C, there exists an efficient implementation of
the unitary Uf using |C| ancillas, and each gate is evaluated at most twice.

– Quantum Fourier Transform: For every n ∈ N, the quantum Fourier
transform QFTn is a unitary operation, that is given a quantum state |φ〉 =∑
j∈Z/nZ xj |j〉, outputs |ψ〉 =

∑
k∈Z/nZ yk|k〉 where the sequence {yk}k is

the Fourier transform to the sequence {xj}j , i.e.

yk =
1√
n

∑
j∈Z/nZ

ωjkn xj

8



where ωn = e2πi/n, and i is the imaginary unit.

2.2 Quantum Random Oracle Model

Here, for the completeness of the paper, we recall the background of quantum
random oracle model and the compressed oracle technique introduced by [Zha19].
This section is taken verbatim from Section 2.2 of [CGLQ20].

An oracle-aided quantum algorithm can perform quantum computation as
well as quantum oracle query. A quantum oracle query for an oracle f : [N ] →
[M ] is modeled as a unitary Uf : |x〉 |u〉 = |x〉 |u+ f(x)〉, where + denotes
addition in integer ring Z/MZ (we take the natural bijection that M ' 0, but
any bijection [M ]↔ Z/MZ suffices for our purposes).

A random oracle is a random function H : [N ]→ [M ]. The random function
H is chosen at the beginning. A quantum algorithm making T oracle queries
to H can be modeled as the following: it has three registers |x〉 , |u〉 , |z〉, where
x ∈ [N ], u ∈ Z/MZ and z is the algorithm’s internal working memory; it starts
with some input state |0〉 |0〉 |ψ〉, then it applies a sequence of unitary to the state:
U0, UH , U1, UH , · · · , UT−1, UH , UT and a final measurement over computational
basis. Each UH is the quantum oracle query unitary: UH |x〉 |u〉 = |x〉 |u+H(x)〉
and Ui is the local quantum computation that is independent of H. We can
always assume there is only one measurement which is a measurement on com-
putational basis and applied at the last step of the algorithm.

2.3 Compressed Oracle

Here we briefly recall some backgrounds about compressed oracle techniques,
first introduced in [Zha19]. More details are provided in Appendix A.

Intuitively, compressed oracle is an analogy of classical lazy sampling method.
To simulate a random oracle, one can sample H(x) for all inputs x and store
everything in quantum accessible registers. Instead of recording all the informa-
tion of H in the registers, Zhandry provides a solution which is useful to argue
the amount of the information an algorithm knows about the random oracle.

The oracle register records a database/list that contains the output on each
input x, the output is an element in Z/MZ ∪ {⊥}, where ⊥ is a special symbol
denoting that the value is “uninitialized”. The database is initialized as an empty
list D0 of length N , in other words, it is initialized as the pure state |∅〉 :=
|⊥,⊥, · · · ,⊥〉. Let |D| denote the number of entries in D that are not ⊥. Define
D(x) to be the x-th entry. Intuitively, D(x) can be seen as the output of the
oracle on x if D(x) 6= ⊥; otherwise, the oracle’s output on x is still undetermined.

For any D and x such that D(x) = ⊥, we define D∪(x, u) to be the database
D′, such that for every x′ 6= x, D′(x′) = D(x) and at the input x, D′(x) = u.

The compressed standard oracle is the unitary CStO := StdDecomp ◦CStO′ ◦
StdDecomp operating on the joint system of the algorithm’s registers and oracle’s
registers, where

9



– CStO′ |x, u〉|D〉 = |x, u+D(x)〉|D〉 when D(x) 6= ⊥, which writes the output
of x defined in D to the u register. This operator will never be applied on
an x,D where D(x) = ⊥.

– StdDecomp(|x〉⊗|D〉) := |x〉⊗StdDecompx |D〉, where StdDecompx |D〉 works
on the x-th register of the database D(x). Intuitively, it swaps a uniform
superposition 1√

M

∑
y |y〉 with |⊥〉 on the x-th register. Formally,

• If D(x) = ⊥, StdDecompx maps |⊥〉 to 1√
M

∑
y |y〉, or equivalently,

StdDecompx|D〉 = 1√
M

∑
y |D ∪ (x, y)〉. Intuitively, if the database does

not contain information about x, it samples a fresh y as the output of x.

• If D(x) 6= ⊥, StdDecompx works on the x-th register, and it is an iden-
tity on 1√

M

∑
y ω

uy
M |y〉 for all u 6= 0; it maps the uniform superposition

1√
M

∑
y |y〉 to |⊥〉.

More formally, for a D′ such that D′(x) = ⊥,

StdDecompx
1√
M

∑
y

ωuyM |D
′ ∪ (x, y)〉 =

1√
M

∑
y

ωuyM |D
′ ∪ (x, y)〉 for any u 6= 0,

and,

StdDecompx
1√
M

∑
y

|D′ ∪ (x, y)〉 = |D′〉.

Since all 1√
M

∑
y ω

uy
M |y〉 and |⊥〉 form a basis, these requirements define a

unique unitary operation.

A quantum algorithm making T oracle queries to a compressed oracle can be
modeled as the following: the algorithm has three registers |x〉 , |u〉 , |z〉, where
x ∈ [N ], u ∈ Z/MZ and z is the algorithm’s internal working memory; it starts
with some input state |0〉 |0〉 |ψ〉; the joint state of the algorithm and the com-
pressed oracle is |0〉 |0〉 |ψ〉 ⊗ |∅〉. It then applies a sequence of unitary to the
state: U0, CStO, U1, CStO, · · · , UT−1, CStO, UT and a final measurement over
computational basis.

Zhandry proves that, the quantum random oracle model and the compressed
standard oracle model are perfectly indistinguishable by any unbounded quantum
algorithm.

In this work, we only consider query complexity, and thus simulation effi-
ciency is irrelevant to us. Looking ahead, we simulate a random oracle as a
compressed standard oracle to help us analyze security games with the help
from the following lemmas. Both lemmas are proven in [Zha19,CGLQ20].

The first lemma gives a general formulation of the overall state of A and
the compressed standard oracle after A makes T queries, even conditioned on
arbitrary measurement results. Looking ahead, it gives a characterization of P -
BF-QROM (defined in Section 4.1) if the oracle is simulated as a compressed
standard oracle.

10



Lemma 1. If A makes at most T queries to a compressed standard oracle, as-
suming the overall state of A and the compressed standard oracle is

∑
z,D αz,D |z〉A|D〉H

where |z〉 is A’s registers and |D〉 is the oracle’s registers, then it only has sup-
port on all D such that |D| ≤ T . In other words, the overall state can be written
as, ∑

z,D:|D|≤T

αz,D |z〉A ⊗ |D〉H .

Moreover, it is true even if the state is conditioned on arbitrary outcomes (with
non-zero probability) of A’s intermediate measurements.

The second lemma provides a quantum analogue of lazy sampling in the
classical ROM.

Lemma 2 (Lemma 5 in [Zha19]). Let H be a random oracle from [N ]→
[M ]. Consider a quantum algorithm A making queries to the standard oracle
and outputting tuples (x1, ¡ ¡ ¡ , xk, y1, ¡ ¡ ¡ , yk, z). Supposed the random function
H is measured after A produces its output. Let R be an arbitrary set of such
tuples. Suppose with probability p, A outputs a tuple such that (1) the tuple is
in R and (2) H(xi) = yi for all i. Now consider running A with the compressed
standard oracle CStO, and suppose the database D is measured after A produces
its output. Let p′ be the probability that (1) the tuple is in R and (2) D(xi) = yi
(in particular, D(xi) 6= ⊥) for all i. Then

√
p ≤
√
p′ +

√
k/M .

Moreover, it is true even if it is conditioned on arbitrary outcomes (with
non-zero probability) of A’s intermediate measurements.

2.4 Security Game with Classical Advice

In this paper, we only focus on the case where advice is classical. Therefore in the
rest of the presentation, “advice” simply means “classical advice”. The following
definitions are defined in [CGLQ20].

Definition 1 (Algorithm with Advice). An (S, T ) (query) classical/quantum
algorithm A = (A1,A2) with (oracle-dependent) advice consists of two proce-
dures:

– let H, H̃ be two oracles accessed by A1,A2 respectively in the offline and
online phases;

– α ← A1(H), which is an arbitrary (unbounded) function of H, and outputs
an S-bit Îą;

– |ans〉 ← AH̃2 (α, ch), which is an unbounded algorithm that takes advice α, a
challenge ch, makes at most T (classical or quantum respectively) queries to
H̃, and outputs an answer, which we measure in the computational basis to
obtain the classical answer ans.

11



Note that we do not need to distinguish if A1 is classical or quantum because
as long as A1 is unbounded, they have the same computational power. We say
A is quantum if A2 makes quantum queries and otherwise A is classical. In this
work, we will mainly focus on A being quantum and the case of A being classical
will be provided mainly in the preliminary Section 2.5.

Below, we will use the words “adversary” and “algorithm” interchangeably,
especially when we consider interactive security games shortly after.

Definition 2 (Security Game). Let H be a random oracle [N ] → [M ].
A (non-interactive) security game G = (C) is specified by a challenger C =
(Samp,Query,Ver), where:

1. ch ← SampH(r) is a classical algorithm that takes randomness r ∈ R as
input, and outputs a challenge ch.

2. QueryH(r, ¡) is a deterministic classical algorithm that hardcodes the ran-
domness r and provides adversary’s online queries6.

3. b ← VerH(r, ans) is a deterministic classical algorithm that takes the input
ans and outputs a decision b indicating whether the game is won.

For every algorithm with advice, i.e. A = (A1,A2) , we define

A ⇐⇒ C(H) := VerH
(
r,AH̃2 (A1(H),SampH(r))

)
to be the binary variable indicating whether A successfully makes the challenger
output 1, or equivalently if A wins the security game, where H̃(¡) := QueryH(r, ¡).
Additionally, we define TVer be the query complexity of computing VerH .

Definition 3 (Security in the AI-ROM/AI-QROM). We define the secu-
rity in the AI-ROM/AI-QROM of a security game G = (C) to be

δ = δ(S, T ) := sup
A

Pr
H,r,A

[A ⇐⇒ C(H) = 1] ,

where A in the probability denotes the randomness of the algorithm, and supre-
mum is taken over all classical or quantum (S, T ) algorithm A in the AI-ROM
or AI-QROM respectively.

Additionally, we say a security game G is δ-secure if its security is at most δ.

Definition 4. We call the security game a decision game if ans ∈ {0, 1}.

Definition 5 (Advantage against Decision Games). We define the advan-
tage of A for a";"""date"",""2020-12-19T17:20:54Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""2"",""0"",""6"",""2"",""56"",""25"",""54"",""13"",""2"",""12"",""6"",""14"",""27"",""18"",""55"",""1"",""8"",""7"",""14"",""13"",""12"",""12"",""62"",""54"",""4"",""0"",""3"",""7"",""65"",""47"",""38"",""17"",""24"",""8"",""28"",""7""
""pdf:PDFVersion"",""1.5""
""xmp:CreatorTool"",""TeX""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dcterms:created"",""2020-12-19T17:20:54Z""
""language"",""en""
""Last-Modified"",""2020-12-19T17:20:54Z""
""dcterms:modified"",""2020-12-19T17:20:54Z""
""dc:format"",""application/pdf; version=1.5""
""Last-Save-Date"",""2020-12-19T17:20:54Z""
""pdf:docinfo:creator_tool"",""TeX""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2020-12-19T17:20:54Z""
""meta:save-date"",""2020-12-19T17:20:54Z""
""pdf:encrypted"",""false""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.20 (TeX Live 2019) kpathsea version 6.3.1""
""modified"",""2020-12-19T17:20:54Z""
""Content-Length"",""469739""
""pdf:hasMarkedContent"",""false""
""Content-Type"",""application/pdf""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.20 (TeX Live 2019) kpathsea version 6.3.1""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""trapped"",""False""
""meta:creation-date"",""2020-12-19T17:20:54Z""
""created"",""2020-12-19T17:20:54Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""39""
""Creation-Date"",""2020-12-19T17:20:54Z""
""resourceName"",""1589.pdf""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""1960"",""2638"",""2591"",""2582"",""2474"",""2109"",""2255"",""2027"",""2329"",""1885"",""1836"",""1914"",""1764"",""1792"",""1951"",""872"",""1481"",""1829"",""2060"",""1917"",""1734"",""1327"",""1478"",""1990"",""1739"",""1808"",""1585"",""1995"",""2756"",""2753"",""2445"",""1715"",""2364"",""1708"",""1768"",""1617"",""1731"",""1337"",""1964""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""producer"",""pdfTeX-1.40.20""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""pdfTeX-1.40.20""
""pdf:docinfo:created"",""2020-12-19T17:20:54Z""
";https://scholar.google.ch/scholar?start=740&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098835-262;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;An airdrop that preserves recipient privacy;RS Wahby, D Boneh, C Jeffrey, J Poon ; International Conference on …, 2020  Springer;;"… Any verifier \(\mathcal {V}\) (ie, other blockchain stakeholders) can verify this signature using

the token, and does not learn the … The algorithm can query two generic group oracles … When

\(\mathcal {L}\) has size q, the second oracle \(\mathcal {O}_2(i,j,\pm )\) takes two indices \(i,j …";Cité 1 fois;Les 5 versions;[PDF] iacr.org;https://eprint.iacr.org/2020/676.pdf;"
An airdrop that preserves recipient privacy

Riad S. Wahby? Dan Boneh? Christopher Jeffrey◦ Joseph Poon†

?Stanford University ◦Purse.io †Unaffiliated

Abstract. A common approach to bootstrapping a new cryptocurrency
is an airdrop, an arrangement in which existing users give away currency
to entice new users to join. But current airdrops offer no recipient privacy:
they leak which recipients have claimed the funds, and this information
is easily linked to off-chain identities.
In this work, we address this issue by defining a private airdrop and de-
scribing concrete schemes for widely-used user credentials, such as those
based on ECDSA and RSA. Our private airdrop for RSA builds upon
a new zero-knowledge argument of knowledge of the factorization of a
committed secret integer, which may be of independent interest. We also
design a private genesis airdrop that efficiently sends private airdrops to
millions of users at once. Finally, we implement and evaluate. Our fastest
implementation takes 40–180 ms to generate and 3.7–10 ms to verify an
RSA private airdrop signature. Signatures are 1.8–3.3 kiB depending on
the security parameter.

Keywords: Cryptocurrency ¡ Airdrop ¡ User privacy ¡ Zero-knowledge
proof of knowledge of factorization of an RSA modulus

1 Introduction

Newly-created cryptocurrencies face a chicken-and-egg problem: users appear
to prefer currencies that already have a thriving ecosystem [64]. For general-
purpose cryptocurrencies, this might entail a healthy transaction volume. For
currencies supporting distributed applications, it could mean having a critical
mass of clients already using the provided functionality. In both cases, the bottom
line is: to attract users, you must already have some.

This problem is well known in practice. One response is an airdrop, an ar-
rangement in which the existing users of a cryptocurrency give value in their
currency to non-users, at no cost, to entice them to become users. Airdrops
have become increasingly popular [2,23,25,83], with recent high-profile examples
including Stellar [131] and OmiseGO [111].

As the name implies, an airdrop is designed to transfer value to passive recip-
ients. To be most effective at recruiting new users, an airdrop should not require
recipients to enroll ahead of time—or, in the best case, even to know about the
airdrop in advance. This is effected by leveraging existing cryptographic infras-
tructure. Commonly, recipients claim their airdropped value on a new blockchain
by reusing their identities from some other, well-established blockchain.



While airdrops to existing blockchains are convenient, using other crypto-
graphic infrastructure may be more effective at recruiting desirable users. A
very interesting example is GitHub, since it has tens of millions of users [70],
many of whom use SSH keys to access repositories and PGP keys to sign com-
mits. GitHub publishes users’ public keys [71,72], which allows cryptocurrencies
to design airdrops intended for developers by allowing them to claim airdropped
funds using keys from GitHub. The PGP web of trust [116], Keybase [88], Git-
Lab [73], and the X.509 PKI [46] are interesting for similar reasons.

Yet, no matter the infrastructure they target, airdrops have a serious flaw:
they offer no privacy to their recipients. This means that an observer can easily
learn whether or not any given recipient has claimed her airdropped value. Even
cryptocurrencies that provide anonymity mechanisms for on-chain transactions
(e.g., [30,16]; §8) do not prevent this leakage, because a recipient must first use
her existing identity to claim the airdropped funds. And using cryptographic
infrastructure like GitHub exacerbates this privacy leak since GitHub accounts,
PGP keys, etc., are often tied to software projects and professional activities. All
told, these issues act as a disincentive for privacy-conscious recipients to redeem
their awards, which reduces the airdrop’s effectiveness in recruiting new users.

Existing solutions fall short of addressing this issue. The simplest possible
approach—sending each recipient a fresh secret key for claiming her funds—
carries an even stronger disincentive: it requires recipients to trust the sender.
Both the sender and recipient know the secret key, so either can take the funds,
but neither can prove who did. Meanwhile, a dishonest sender might garner free
publicity with an airdrop, only to claw back the funds; or an incompetent one
might accidentally disclose the secret keys. To avoid this trust requirement, a
workable solution must allow only the recipient to withdraw the funds.

A more plausible approach is to have recipients claim airdrop funds by prov-
ing their identities in zero knowledge. Concretely, a recipient proves that she
knows the secret key for some pre-existing public key (say, the RSA public key of
her GitHub credential), and that no prior airdrop claim has used this public key.
To preserve her privacy, she must do so without revealing which public key she is
using. But proving knowledge of one secret key among a large list of RSA keys us-
ing general-purpose zero-knowledge proof systems [37,137,3,39,69,31,20,114,15]
is too expensive: infeasible computational cost, enormous proofs, and/or a setup
phase whose incorrect execution allows proving false statements (see §8).

Meanwhile, infrastructures like GitHub are primarily based on RSA because
it is, anecdotally, the most widely-supported key type for both SSH [130] and
PGP [77]. This means that taking advantage of these infrastructures effectively
requires support for airdrops to RSA keys.

Our contributions. This work builds an efficient and practical private airdrop
system using special-purpose zero-knowledge proofs designed for this task.

First, we define precisely the required functionality and security properties
for a private airdrop scheme (§2.1). Second, we exhibit practical private airdrop
schemes designed to work with ECDSA (§3) and RSA (§4) credentials. Our
ECDSA scheme extends in a straightforward way to Schnorr [127], EdDSA [21],

2



and similar credentials. To construct our RSA scheme, we devise a new succinct
zero-knowledge proof of knowledge (ZKPK) of the factorization of a committed
secret integer, which we prove secure in the generic group model for groups of
unknown order [128,50]. This new ZKPK may be of independent interest.

Third, we carefully describe how to use private airdrops to bootstrap a new
cryptocurrency, a scheme we call a private genesis airdrop (§5). This scheme is
designed to handle millions of recipients, each of whom has hundreds of keys of
mixed types (some RSA, some ECDSA, etc.) and who may potentially have lost
one or more of their keys. The scheme lets the airdrop’s sender prove the total
value of the airdrop, while enabling airdrop recipients to prove non-payment in
case the sender was dishonest.

Fourth, we implement and evaluate our schemes (§6). Our evaluation focuses
on the private airdrop scheme for RSA (which is more costly than the one for
ECDSA) and the private genesis airdrop. Depending on the security parameter,
our fastest implementation takes 40–180 ms for an airdrop recipient to generate
an RSA-based private airdrop signature comprising 1.8–3.3 kiB. The signature
takes miners 3.7–10 ms to verify. The scheme requires a trusted setup to gener-
ate one global RSA modulus with an unknown factorization. Eliminating trusted
setup, by using class groups of unknown order, increases signing and verifying
times by 9–13× in our reference implementation. Compared with a private air-
drop to one recipient, a private genesis airdrop to one million users, each with
one thousand public keys, increases signature size by less than 1.8× in the worst
case. Our reference implementation is available as open source (§6).

2 Background and definitions

[`] denotes the set of integers {0, 1, . . . , ` − 1}. λ is a security parameter (e.g.,
Îť = 128); we generally leave Îť implicit. Primes(2Îť) is the set of the smallest 22Îť

odd primes; this is roughly the primes up to 2Îť+ log(2Îť) bits in length.
Detailed knowledge of blockchains and cryptocurrencies is not required to

understand this work. For now, we regard a blockchain simply as an append-
only log of transactions. We give slightly more detail in Section 5; curious readers
should consult the survey of Bonneau et al. [29] for further information.

2.1 Private airdrop scheme

High-level description. In a private airdrop, a sender S creates a token and a
secret for a recipient R whose public key is pk . The sender sends the secret to
R1 and records the token in a blockchain transaction. To claim the airdrop, R
uses the token, the secret, and her secret key sk (i.e., corresponding to pk) to
sign a new transaction. Any verifier V (i.e., other blockchain stakeholders) can
verify this signature using the token, and does not learn the recipient’s pk .

1 This is usually accomplished by encrypting the secret to the recipient’s pk and
publishing the resulting ciphertext, so no explicit private channel is necessary.

3



Syntax. Let SIG := (genSIG, signSIG, verifySIG) be a signature scheme secure against
existential forgery under a chosen message attack. The derived private airdrop
scheme PAD with implicit security parameter Îť is a tuple of four algorithms:
setup(1λ)→R pp: Output pp, which is an implicit input to the other algorithms.
send(pk)→R (c, s): Compute and output token c and secret s for public key pk ,
where (pk , sk) ←R genSIG(). Here c is a public airdrop token that can later be
claimed by a recipient whose public key is pk . The element s is a secret that
the recipient will use, along with sk , to claim the token c.
sign(sk , (c, s),msg)→R sig: Sign message msg ∈ {0, 1}? under token-secret pair
(c, s) using secret key sk , where (pk , sk)←R genSIG() and (c, s)←R send(pk). An
airdrop recipient uses this algorithm to claim the airdrop token c.
verify(c,msg , sig)→ {OK,⊥}: OK if sig is valid for msg and token c, else ⊥.
This algorithm is used to verify a claim for the token c.

PAD may also be validatable, in which case it has an additional algorithm:
validate(pk , (c, s))→ {OK,⊥}: This algorithm outputs OK if token c with se-
cret s granted to public key pk is valid, else it outputs ⊥.

For schemes that are not validatable, we let validate(¡, ¡) output OK for all inputs.

Functionality. We require that, for all messages msg ∈ {0, 1}?,

Pr

 verify(c,msg , sig) = OK ∧ validate(pk , (c, s)) = OK
where pp ←R setup(1λ) (pk , sk) ←R genSIG()

(c, s) ←R send(pk) sig ←R sign(sk , (c, s),msg)

 ≥ 1− negl(λ)

Security. PAD is secure if it is anonymous, unforgeable, and orthogonal to SIG.
Anonymity means, informally, that c and sig reveal nothing about pk or sk , other
than a well-defined leakage given by a function Λ. This ensures that claiming a
token c does not reveal the claimant’s identity, as required for privacy.

Definition 1. PAD is Λ-anonymous if there is a leakage function Λ such that
for all PPT adversaries A there exists a simulator Sim such that the following
two distributions are statistically indistinguishable, letting pp←R setup(1λ):

Dr =


(pk , sk) ←R genSIG()

(c, s) ←R send(pk)
(msg , st) ←R A(c)

sig ←R sign(sk , (c, s),msg)

output (pk , c,msg , sig , st)

 ; Ds =


(pk , sk) ←R genSIG()

H ←R Λ(pk , sk)
(c,msg , sig , st) ←R Sim(H)

output (pk , c,msg , sig , st)


Remark 1. Sim sees only H (not pk), yet simulates (c,msg , sig , st). This means
that this 4-tuple reveals nothing about the challenge pk except the leakage H =
Λ(pk , sk). A does not learn s because in an airdrop only the sender and recipient
do, and the goal is to keep other parties from learning the recipient’s identity.

Remark 2. Sim appears to forge a valid signature (see Def. 2), but this does not
result in a real-world attack on our private airdrop schemes (§3, §4). The reason
for this is that we instantiate these schemes in the random oracle model [12],
and Sim is allowed to program the random oracle.

4



Remark 3. A slightly stronger definition of anonymity also includes sk in the
output of both distributions. Anonymity under this definition implies, roughly
speaking, that even knowledge of the key sk corresponding to a token c is not
sufficient to connect sig to pk . The schemes in the following sections meet this
stronger notion, but it does not appear necessary in practice.

Unforgeability means, roughly speaking, that without sk one cannot generate
a valid PAD signature for any message, even given valid PAD signatures for
other messages and valid signatures in the underlying SIG for arbitrary messages.
Consider Forge, a game between adversary A and challenger C:
Setup: C sets pp←R setup(1λ), (pk , sk)←R genSIG(), and (c, s)←R send(pk), then
sends pk , (c, s) to A.
Query: A makes any number of queries of type Q1 and Q2, in any interleaving.
Q1: A sends msgSIG

i to C, who replies with sigSIG
i ←R signSIG(sk ,msgSIG

i ).
Q2: A sends msgj to C, who replies with sigj ←R sign(sk , (c, s),msgj).
Forge: A outputs (m̂, ŝ), winning if verify(c, m̂, ŝ)=OK ∧

∧
j m̂6=msgj .

Definition 2. Let adversary A’s advantage in Forge be AdvForge
A = Pr [A wins].

PAD is unforgeable if, for any PPT A, AdvForge
A ≤ negl(λ).

Orthogonality means, informally, that PAD signatures do not help to create a SIG
forgery. In other words, the airdrop scheme does not weaken the user’s credential
(e.g., for authenticating to GitHub). Consider Ortho, a game between adversary
A and challenger C:
Setup: C sets pp←R setup(1λ) and (pk , sk)←R genSIG(), then sends pk to A, who
chooses (c, s) and sends them to C. Finally, C aborts if validate(pk , (c, s)) = ⊥.
Query: A makes any number of queries of type Q1 and Q2, in any interleaving.
Q1: A sends msg i to C, who replies with sig i ←R signSIG(sk ,msg i).
Q2: A sends msgPAD

j to C, who replies with sigPAD
j ←R sign(sk , (c, s),msgPAD

j ).
Forge: A outputs (m̂, ŝ), winning if verifySIG(pk , m̂, ŝ)=OK ∧

∧
i m̂6=msg i.

The game wkOrtho is similar, but further requires
∧
j m̂6=msgPAD

j for A to win.

Definition 3. Let adversary A’s advantage in Ortho be AdvOrtho
A = Pr [A wins].

PAD is orthogonal to SIG if, for any PPT adversary A, AdvOrtho
A ≤ negl(λ).

PAD is weakly orthogonal if Ortho is replaced with wkOrtho in this definition.

Remark 4. The PAD scheme of Section 4 gives orthogonality, while the scheme of
Section 3 gives only weak orthogonality. In practice, weak orthogonality suffices
as long as messages signed in the PAD scheme cannot be confused with messages
signed in the SIG scheme; this appears to be true in our applications.

2.2 Zero-knowledge proofs in generic groups

In this section we briefly review the notion of a generic group of unknown order
and zero-knowledge proof systems with respect to such groups, following [27].

5



Generic groups. We use the generic group model for groups of unknown order
as defined by DamgĂĽrd and Koprowski [50]. The group is parameterized by two
integer public parameters A,B. The order of the group is sampled uniformly from
[A,B]. The group G is defined by a random injective function σ : Z|G| → {0, 1}`,
for some ` where 2` � |G|. The group elements are σ(0), σ(1), . . . , σ(|G| − 1). A
generic group algorithm A is a probabilistic algorithm. Let L be a list that is
initialized with the encodings given to A as input. The algorithm can query two
generic group oracles:
• O1 samples a random r ∈ Z|G| and returns σ(r), which is appended to the

list of encodings L.
• When L has size q, the second oracle O2(i, j,±) takes two indices i, j ∈
{1, . . . , q} and a sign bit, and returns σ(xi ¹ xj), which is appended to L.

Note that unlike Shoup’s generic group model [128], the algorithm is not given
|G|, the order of the group G.

The representation extraction lemma. Let A be an algorithm that outputs a
generic group element u ∈ G. The following lemma from [57] shows that there is
an extractor that can extract from A an integer representation of u relative to a
supplied set of group generators. Moreover, this integer representation is unique.

Lemma 1 (Unique representation extraction in generic groups). Let G
be a generic group of unknown order where |B − A| is super-polynomial in λ.
Let A1,A2 be two randomized algorithms that interact with group oracles for G
and make at most a polynomial in Îť queries to these oracles. Suppose that each
algorithm makes at most q type-1 queries and let g1, . . . , gq ∈ G be the returned
random group elements. Each of A1 and A2 eventually outputs some ui ∈ G.

Then there is an extractor B that emulates the generic group oracles for Ai
i ∈ {1, 2} such that when B interacts with Ai the following holds with overwhelm-
ing probability: if Ai outputs ui ∈ G then the extractor Bi outputs a representa-
tion ιi,1, . . . , ιi,q ∈ Z such that ui = g

Îąi,1

1 ¡ ¡ ¡ gιi,q
q . Moreover, if u1 = u2 then

the two representations are the same, namely Îą1,j = Îą2,j for j = 1, . . . , q.

Argument systems. An argument system for a relation R ⊂ X ×W is a triple
of randomized polynomial time algorithms (Pgen,P,V), where Pgen takes an
implicit security parameter Îť and outputs a common reference string (crs) pp.
If the setup algorithm uses only public randomness we say that the setup is
transparent and that the crs is unstructured. The prover P takes as input a
statement x ∈ X , a witness w ∈ W, and the crs pp. The verifier V takes as
input pp and x and after interaction with P outputs 0 or 1. We denote the
transcript between the prover and verifier by 〈V(pp, x),P(pp, x, w)〉 and write
〈V(pp, x),P(pp, x, w)〉 = 1 to indicate that the verifier accepted the transcript.
If V uses only public randomness we say that the protocol is public coin.

Definition 4 (Completeness). An argument system (Pgen,P,V) for a rela-
tion R is complete if for all (x,w) ∈ R:

Pr
[
〈V(pp, x),P(pp, x, w)〉 = 1 : pp←R Pgen(1λ)

]
= 1.

6



We now define soundness and knowledge extraction for our protocols. The ad-
versary is modeled as two algorithms A0 and A1, where A0 outputs the instance
x ∈ X after Pgen is run, and A1 runs the interactive protocol with the verifier
using a state output by A0. In slight deviation from the soundness definition
used in statistically sound proof systems, we do not universally quantify over
the instance x (i.e. we do not require security to hold for all input instances x).
This is due to the fact that in the computationally-sound setting the instance
itself may encode a trapdoor of the crs pp (e.g. the order of a group of unknown
order), which can enable the adversary to fool a verifier. Requiring that an ef-
ficient adversary A0 outputs the instance x prevents this. For soundness, no
efficient adversary A1 can make the verifier accept when no witness for x exists.
For an argument of knowledge, there should be an extractor that can extract a
valid witness whenever A1 is convincing.

Definition 5 (Arguments (of Knowledge)). An argument system (Pgen,P,V)
is sound if for all PPT adversaries A = (A0,A1):

Pr

[
〈V(pp, x),A1(pp, x, state)〉 = 1 ∧ @w (x,w) ∈ R

where pp←R Pgen(1λ), (x, state)←R A0(pp)

]
≤ negl.

Additionally, the argument system is an argument of knowledge if for all
PPT adversaries A1 there exists a PPT extractor Ext such that for all PPT
adversaries A0:

Pr


〈V(pp, x),A1(pp, x, state)〉 = 1 ∧ (x,w′) 6∈ R

where pp ←R Pgen(1λ)
(x, state) ←R A0(pp)

w′ ←R Ext(pp, x, state)

 ≤ negl.

Any argument of knowledge is also sound. In some cases we may further
restrict A in the security analysis, in which case we would say the system is an
argument of knowledge for a restricted class of adversaries. For example, in this
work we construct argument systems for relations that depend on a group G of
unknown order. In the analysis we replace G with a generic group and restrict A
to a generic group algorithm that interacts with the oracles for this group. We
say that the protocol is an argument of knowledge in the generic group model.

Definition 6 (Zero Knowledge). We say an argument system (Pgen,P,V)
for R has statistical zero-knowledge if there exists a PPT simulator Sim such
that for (x,w) ∈ R the following distribution are statistically indistinguishable:

Dreal =

{
〈P(pp, x, w),V(pp, x)〉
where pp←R Pgen(1λ)

}
; Dsim =

{
Sim(pp, x,V(pp, x))
where pp←R Pgen(1λ)

}
Definition 7 (Non interactive arguments). A non-interactive argument
system is an argument system where the interaction between P and V consists
of only a single round. We write the prover P as P(pp, x, w)→ π and the verifier
as V(pp, x, π)→ {0, 1}.

7



The Fiat-Shamir heuristic [54] and its multi-round generalization [19] transform
public coin arguments into non-interactive ones, in the random oracle model [12].

3 Warm-up: A private airdrop to ECDSA keys

Let H with generator ĝ be a cyclic group of prime order q̂. Let the ECDSA
signature scheme inH be the triple (genDSA

H ()→R (pk , sk), signDSA
H (sk ,msg)→R sig ,

verifyDSA
H (pk ,msg , sig)→ {OK,⊥}); (pk , sk) = (ĝx, x) is an ECDSA key pair.

We now define PAD-DSA, a private airdrop scheme to ECDSA keys. Intuitively,
the token c in this scheme is a fresh ECDSA public key derived from an existing
key, such that only that key’s owner can compute the corresponding secret. In
particular, PAD-DSA leverages the fact that c = pks = ĝx·s ∈ H is an ECDSA
public key whose corresponding secret key is sk · s = x · s ∈ Zq̂. Further, if s is
chosen at random, pks is independent of pk , so c reveals nothing about pk .

Thus, PAD-DSA is the validatable private airdrop scheme given by:

setup(1λ)→ pp: Output ⊥; this scheme uses no public parameters.
send(pk)→R (c, s): Choose s←R [q̂] \ {0}, set c← pks ∈ H, and output (c, s).
sign(sk , (c, s),msg)→R sig: Output signDSA

H (sk · s ∈ Zq̂, (c,msg)).
verify(c,msg , sig)→ {OK,⊥} : Output verifyDSA

H (c, (c,msg), sig).
validate(pk , (c, s))→ {OK,⊥}: OK if s ∈ [q̂] \ {0} ∧ c = pks ∈ H, else ⊥.

Theorem 1. PAD-DSA is anonymous (Def. 1), with no leakage.

Proof. Let ΛDSA(·, ·) := ⊥. For an adversary A, the simulator SimDSA
A (¡), which

ignores its input, works as follows: (1) compute (pk ′, sk ′)←R genDSA
H (), (2) run the

adversaryA on input pk ′ to obtain (msg , st), (3) compute sig ←R signDSA
H (sk ,msg),

and (4) output (pk ′,msg , sig , st). (Notice that pk ′ plays the role of the token c.)
We now show that SimDSA

A (¡) induces a distribution Dsim that is statistically
indistinguishable from Dreal. By inspection, pk has the same distribution in both
views. In the real view, s is uniform in {1, . . . , q̂ − 1}, so (c = ĝx·s, x · s) in the
real view is a uniformly random ECDSA key. This is also true of (pk ′, sk ′) in
simulation, so c, msg , and st are all statistically indistinguishable. Finally, sig is
valid and identically distributed in both views by the definition of signDSA

H . ut

Definition 8 (Idealized ECDSA [35,52]). The triple (genDSA
H , signDSA

H , verifyDSA
H )

is the idealized ECDSA algorithm if the two hash functions called as subrou-
tines by signDSA

H and verifyDSA
H are modeled as random oracles.

Theorem 2. PAD-DSA is unforgeable (Def. 2) when (genDSA
H , signDSA

H , verifyDSA
H )

is modeled as the idealized ECDSA algorithm.

Theorem 3. PAD-DSA is weakly orthogonal to ECDSA in H (Def. 3) when
(genDSA

H , signDSA
H , verifyDSA

H ) is modeled as the idealized ECDSA algorithm.

8



Dauterman et al. [52, Thm. 5, Appx. C] prove a statement equivalent to
Theorem 2. PAD-DSA is, in effect, a signature under a related key; Theorem 3
captures the required security against related-key attacks. Morita et al. [105,
Thm. 2] prove a statement equivalent to this theorem, and also suggest a tweak
to DSA whose use would give full (rather than weak) orthogonality for PAD-DSA.

An alternative to the above scheme is to use c = pk · ĝs = ĝx+s, with signing
key x + s ∈ Zq̂, similarly to hierarchical deterministic wallets [139]. PAD-DSA
also extends naturally to Schnorr [127], EdDSA [21], and related schemes.

4 A private airdrop to RSA keys

Let G be a group of unknown order (§2.2) with generators g, h having unknown
discrete-log relation. Let H be an auxiliary cyclic group of known prime order
q̂ with generators ĝ, ĥ having unknown discrete-log relation. Let n ∈ [N ] be
a secret integer where N is a public upper bound on n and N > |G| ¡ 2Ν. Let
c := gn · hs ∈ G be a Pedersen commitment to n with opening s←R [N ].

In this section we construct a private airdrop to RSA keys. We proceed in
two steps: we first construct an interactive zero-knowledge proof of knowledge
(ZKPK) of the factorization of an RSA modulus n ∈ Z given a public Pedersen
commitment [115] to this n (see §4.1 and §4.2). We then make this protocol non-
interactive via the Fiat-Shamir heuristic [54], yielding a private airdrop (§4.3).

One way to prove knowledge of the factorization of a committed n is for the
prover to commit to integers p and q, and then prove that they are nontrivial
factors of n. We instantiate this approach in Section 4.1, but verifying the proof
is costly: it requires an exponentiation by a several thousand–bit exponent.

To address this, in Section 4.2 we describe a second ZKPK that reduces the
verifier’s work by roughly 5× and gives ≈13–49% shorter proofs. The resulting
protocol leaks a small amount of information about n: at most two bits, This
can be reduced to just one leaked bit under a mild assumption (Cor. 1, §4.3).

Remark 5. The protocols of this section are insecure if the group G contains
a non-identity element of known order. In the group Z×m the element −1 has
order 2, and hence this group is unsuitable for our protocols. Instead, we work in
the quotient group G := Z×m/{±1}, where elements are represented as integers in
the interval [1,m/2] and the product of x and y is defined as x ·y = min(z,m−z)
where z = (x · y mod m). In this group −1 is the same as 1, and presumably
there are no other known elements of known order other than the identity. We
discuss the group G further in Section 7.

4.1 PoKF1: ZKPK of factorization of a committed integer

To prove knowledge of the factorization of n, the prover establishes the relation

R′g,h :=

{ (
c ∈ G, (n, p, q, s) ∈ [N ]× Z3

)
, where

c = gn ¡ hs, p ¡ q = n, p 6∈ {¹1,¹n}

}
(1)

9



where c is the statement and (n, p, q, s) is the witness. At a high level, the proof
works as follows: the prover P sends the verifier V two Pedersen commitments
cp and cq to p and q, respectively, then proves that p ¡ q = n and p /∈ {¹1,¹n}.
For this purpose, we combine folklore sigma protocols [127,41,110,49,8,96] with
recent work extending such protocols to generic groups of unknown order [27].

To efficiently prove that p /∈ {¹1,¹n} we make use of the auxiliary group H.
Recall that V has commitments to p and n, and could therefore prove that
p /∈ {±1,±n} by proving that (p2 − 1)(p2 − n2) 6= 0 as integers. However, this
requires a relatively large proof containing multiple elements of G.

To sidestep this issue, we take a different approach: rather than execute the
proof in G, our P and V execute it in a much smaller group H of known prime
order (say, an elliptic curve group). For RSA moduli at practical security levels
the order of H is all but certainly coprime to p, pÂą 1, and pÂą n, so this suffices
to convince V that p /∈ {¹1,¹n} in Z for essentially any n.

The prover P provides a commitment ĉp2 ∈ H to p2, from which V can
compute a commitment to p2 − 1 as ĉp2/ĝ ∈ H. To do the same for p2 − n2

the verifier V needs a commitment ĉn2 ∈ H to n2. Fortunately, in the airdrop
context this is easy to arrange, by requiring the sender S to compute the token
as (c, ĉn2) with corresponding secret (s, s2). This gives the modified relation

R′′
g,h,ĝ,ĥ

:=


(

(c, ĉn2) ∈ G×H, (n, p, q, s, s2) ∈ [N ]× Z3 × [q̂]
)
,

where c = gn · hs, ĉn2 = ĝ(n
2) · ĥs2 ,

p · q = n, p 6∈ {±1,±n} mod q̂

 (2)

for statement (c, ĉn2) and witness (n, p, q, s, s2). We now give an interactive
ZKPK for the above relation. This protocol uses three sub-protocols, ProdG,
ProdH, and Square, which we describe in Appendix B.

Protocol PoKF1 for relation (2) between prover P and verifier V works as
follows. V’s input is (c, ĉn2) ∈ G×H, and P’s input is (n, p, q, s, s2) ∈ [N ]4× [q̂].
(1) P sends V the following commitments:

• cp, cq ∈ G to p and q,
• ĉp, ĉp2 ∈ H to p and p2, and
• ĉp1′ , ĉpn′ ∈ H to (p2 − 1)−1 mod q̂ and (p2 − n2)−1 mod q̂.
V then computes ĉp1 = ĉp2 · ĝ−1 ∈ H and ĉpn = ĉp2 · ĉ−1n2 ∈ H, which are
commitments to p2 − 1 = (p− 1)(p+ 1) and p2 − n2 = (p− n)(p+ n).

(2) P and V execute ProdG (Appx. B.2) on (cq, cp, c), which convinces V that
p ¡ q = n and P can open cq and c.

(3) P and V execute Square (Appx. B.3) on (cp, ĉp, ĉp2), which convinces V that
ĉp commits to p, ĉp2 commits to p2, and P can open all three commitments.

(4) P and V execute two instances of ProdH (Appx. B.1), one on (ĉp1′ , ĉp1, ĝ)
and one on (ĉpn′ , ĉpn, ĝ). (Note that ĝ is a commitment to 1 with opening
0.) This convinces V that p2 − 1 and p2 − n2 are invertible mod q̂ (i.e., that
they are nonzero) and that P can open ĉp1′ , ĉpn′ , and ĉn2 .

10



Soundness and zero knowledge of PoKF1 follow from the properties of the
sub-protocols (Appx. B). Verification cost is dominated by Square, which entails
an exponentiation in G with an exponent of size λ + log q̂ + logN bits. Recall
that N is an upper bound on n; typically N ≈ 24096 so that n can be a 4096-
bit RSA modulus, so this exponentiation is very expensive. One could instead
prove relation (1) directly via five invocations of ProdG (one to establish that
p ¡ q = n and four more to establish that p /∈ {¹1,¹n}). Roughly speaking,
this would trade a reduction in verification cost for a commensurate increase in
communication cost. We discuss costs in more detail in Appendix B.4.

4.2 PoKF2: reducing costs by allowing (1-bit) leakage

As discussed above, PoKF1 suffers from high verification cost. In this section, we
give a protocol that reduces both verification and communication cost compared
to PoKF1, but leaks one bit about n. As we discuss in Section 7, this leakage is
acceptable in the private airdrop application.

To prove knowledge of factorization of n, the prover establishes the following
relation for w ∈ [N ] where w2 ≡ t (mod n) and t ∈ Z is prime, 2 ≤ t < λ.
(Recall that computing square roots modulo n is equivalent to factoring n).

Rg,h :=


(

(c, t) ∈ G×[λ], (n, s, w, a) ∈ [N ]4
)
, where

c = gn · hs ∈ G, w2 = t+ a · n ∈ Z, 2 ≤ t < λ a prime

 (3)

Here (c, t) is the statement and (n, s, w, a) is the witness. The integer relation
w2 = t+ a · n proves that w2 ≡ t (mod n), as required.

Remark 6. Common hardware security tokens for RSA keys (e.g., [141]) imple-
ment a signing oracle abstraction. This means that the device’s owner has access
to (at best) an eth root in Zn for (n, e) = pk—and not to the factorization of n.
Furthermore, these security tokens often fix e = 65537. In principle, it is possible
to adapt our ZKPK to a relation analogous to (3) for w? a 65537th root of t. This
proof would be an order of magnitude longer, but would eliminate the leakage
about n, and support security tokens. We leave to future work the problem of
devising a concretely small ZKPK supporting these security tokens.

We now give an interactive ZKPK for Relation (3), building on the results
of Boneh et al. [27]. This relation leaks that t ∈ Z is a quadratic residue modulo
the committed n. As discussed below (Cor. 1, §4.3), this leakage amounts to one
bit under a standard cryptographic assumption.

Protocol PoKF2 for relation (3) between prover P and verifier V works as
follows. V’s input is (c, t) ∈ G×[λ] with t prime, and P’s input is (c, t, n, s, w, a) ∈
G × [N ]5. To start, P chooses two random integers s1, s2 ←R [N ] and computes
c1 ← gw · hs1 ∈ G and c2 ← ";"""date"",""2020-06-06T00:13:50Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2020-06-06T00:13:50Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.20 (TeX Live 2019/Arch Linux) kpathsea version 6.3.1""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2020-06-06T00:13:50Z""
""created"",""2020-06-06T00:13:50Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-06-06T00:13:50Z""
""resourceName"",""676.pdf""
""Author"",""""
""producer"",""pdfTeX-1.40.20""
""pdf:docinfo:producer"",""pdfTeX-1.40.20""
""pdf:unmappedUnicodeCharsPerPage"",""3"",""0"",""2"",""2"",""6"",""12"",""16"",""9"",""6"",""12"",""7"",""35"",""28"",""29"",""37"",""27"",""0"",""0"",""0"",""0"",""1"",""0"",""4"",""4"",""1"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""49"",""62"",""27"",""16"",""70"",""43"",""23""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2020-06-06T00:13:50Z""
""Last-Modified"",""2020-06-06T00:13:50Z""
""dcterms:modified"",""2020-06-06T00:13:50Z""
""title"",""""
""Last-Save-Date"",""2020-06-06T00:13:50Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2020-06-06T00:13:50Z""
""meta:save-date"",""2020-06-06T00:13:50Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.20 (TeX Live 2019/Arch Linux) kpathsea version 6.3.1""
""Content-Length"",""866851""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""44""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""2170"",""2962"",""2490"",""2399"",""2279"",""2456"",""2167"",""2233"",""2330"",""2263"",""2316"",""2233"",""2103"",""2369"",""2601"",""2704"",""2423"",""2629"",""2722"",""2623"",""2661"",""2329"",""2575"",""2407"",""2595"",""2664"",""2873"",""2887"",""2375"",""2561"",""2682"",""2779"",""2519"",""2568"",""1851"",""1731"",""1628"",""2087"",""2139"",""2069"",""2386"",""2432"",""1472"",""1185""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-06-06T00:13:50Z""
";https://scholar.google.ch/scholar?start=810&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098769-118;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Deep Reinforcement Learning for the Management of Software-Defined Networks and Network Function Virtualization in an Edge-IoT Architecture;RS Alonso, I Sittón;Candanedo, R CasadoVara…  Sustainability, 2020  mdpi.com;;"… The first of these architectures is FAR-Edge [34]. One of the aspects taken by GECA

from FAR-Edge is that both incorporate blockchain functionalities. However, in the case

of FAR-Edge the blockchain is incorporated in its intermediate …";Cité 2 fois;Les 7 versions;[PDF] mdpi.com;https://www.mdpi.com/2071-1050/12/14/5706/pdf;;;https://scholar.google.ch/scholar?start=660&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098844-287;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;[PDF][PDF] A Generalized Formal Semantic Framework for Smart Contracts.;J Jiao, SW Lin, J Sun ; FASE, 2020  library.oapen.org;;"… A set of test oracles is defined in [26, 45] to detect security vulnerabilities on EVM … and data (its

state) that resides at a specific address on the Ethereum blockchain [7]. Fig. 1 shows an example

of Solidity smart contracts, named Coin, implementing a very simple cryptocurrency …";Cité 2 fois;Les 9 versions;[PDF] oapen.org;https://library.oapen.org/bitstream/handle/20.500.12657/37725/2020_Book_FundamentalApproachesToSoftwar.pdf?sequence=1#page=86;"
23rd International Conference, FASE 2020
Held as Part of the European Joint Conferences
on Theory and Practice of Software, ETAPS 2020
Dublin, Ireland, April 25–30, 2020, Proceedings

Fundamental Approaches 
to Software EngineeringLN

CS
 1

20
76

AR
Co

SS
Heike Wehrheim
Jordi Cabot (Eds.)



Lecture Notes in Computer Science 12076

Editorial Board Members

Elisa Bertino, USA
Wen Gao, China
Bernhard Steffen , Germany

Gerhard Woeginger , Germany
Moti Yung, USA

Advanced Research in Computing and Software Science
Subline of Lecture Notes in Computer Science

Subline Series Editors

Giorgio Ausiello, University of Rome ‘La Sapienza’, Italy

Vladimiro Sassone, University of Southampton, UK

Subline Advisory Board

Susanne Albers, TU Munich, Germany
Benjamin C. Pierce, University of Pennsylvania, USA
Bernhard Steffen , University of Dortmund, Germany
Deng Xiaotie, Peking University, Beijing, China
Jeannette M. Wing, Microsoft Research, Redmond, WA, USA

Founding Editors

Gerhard Goos, Germany
Juris Hartmanis, USA



More information about this series at http://www.springer.com/series/7407



Heike Wehrheim • Jordi Cabot (Eds.)

Fundamental Approaches
to Software Engineering
23rd International Conference, FASE 2020
Held as Part of the European Joint Conferences
on Theory and Practice of Software, ETAPS 2020
Dublin, Ireland, April 25–30, 2020
Proceedings



Editors
Heike Wehrheim
University of Paderborn
Paderborn, Germany

Jordi Cabot
ICREA
Open University of Catalonia
Barcelona, Spain

ISSN 0302-9743 ISSN 1611-3349 (electronic)
Lecture Notes in Computer Science
ISBN 978-3-030-45233-9 ISBN 978-3-030-45234-6 (eBook)
https://doi.org/10.1007/978-3-030-45234-6

LNCS Sublibrary: SL1 – Theoretical Computer Science and General Issues

Š The Editor(s) (if applicable) and The Author(s) 2020. This book is an open access publication.
Open Access This book is licensed under the terms of the Creative Commons Attribution 4.0 International
License (http://creativecommons.org/licenses/by/4.0/), which permits use, sharing, adaptation, distribution
and reproduction in any medium or format, as long as you give appropriate credit to the original author(s) and
the source, provide a link to the Creative Commons license and indicate if changes were made.
The images or other third party material in this book are included in the book’s Creative Commons license,
unless indicated otherwise in a credit line to the material. If material is not included in the book’s Creative
Commons license and your intended use is not permitted by statutory regulation or exceeds the permitted use,
you will need to obtain permission directly from the copyright holder.
The use of general descriptive names, registered names, trademarks, service marks, etc. in this publication
does not imply, even in the absence of a specific statement, that such names are exempt from the relevant
protective laws and regulations and therefore free for general use.
The publisher, the authors and the editors are safe to assume that the advice and information in this book are
believed to be true and accurate at the date of publication. Neither the publisher nor the authors or the editors
give a warranty, expressed or implied, with respect to the material contained herein or for any errors or
omissions that may have been made. The publisher remains neutral with regard to jurisdictional claims in
published maps and institutional affiliations.

This Springer imprint is published by the registered company Springer Nature Switzerland AG
The registered company address is: Gewerbestrasse 11, 6330 Cham, Switzerland



ETAPS Foreword

Welcome to the 23rd ETAPS! This is the first time that ETAPS took place in Ireland in
its beautiful capital Dublin.

ETAPS 2020 was the 23rd instance of the European Joint Conferences on Theory
and Practice of Software. ETAPS is an annual federated conference established in
1998, and consists of four conferences: ESOP, FASE, FoSSaCS, and TACAS. Each
conference has its own Program Committee (PC) and its own Steering Committee
(SC). The conferences cover various aspects of software systems, ranging from
theoretical computer science to foundations of programming language developments,
analysis tools, and formal approaches to software engineering. Organizing these
conferences in a coherent, highly synchronized conference program enables researchers
to participate in an exciting event, having the possibility to meet many colleagues
working in different directions in the field, and to easily attend talks of different
conferences. On the weekend before the main conference, numerous satellite
workshops took place that attracted many researchers from all over the globe. Also, for
the second time, an ETAPS Mentoring Workshop was organized. This workshop is
intended to help students early in the program with advice on research, career, and life
in the fields of computing that are covered by the ETAPS conference.

ETAPS 2020 received 424 submissions in total, 129 of which were accepted,
yielding an overall acceptance rate of 30.4%. I thank all the authors for their interest in
ETAPS, all the reviewers for their reviewing efforts, the PC members for their
contributions, and in particular the PC (co-)chairs for their hard work in running this
entire intensive process. Last but not least, my congratulations to all authors of the
accepted papers!

ETAPS 2020 featured the unifying invited speakers Scott Smolka (Stony Brook
University) and Jane Hillston (University of Edinburgh) and the conference-specific
invited speakers (ESOP) Işıl Dillig (University of Texas at Austin) and (FASE) Willem
Visser (Stellenbosch University). Invited tutorials were provided by Erika Ábrahåm
(RWTH Aachen University) on the analysis of hybrid systems and Madhusudan
Parthasarathy (University of Illinois at Urbana-Champaign) on combining Machine
Learning and Formal Methods. On behalf of the ETAPS 2020 attendants, I thank all the
speakers for their inspiring and interesting talks!

ETAPS 2020 took place in Dublin, Ireland, and was organized by the University of
Limerick and Lero. ETAPS 2020 is further supported by the following associations and
societies: ETAPS e.V., EATCS (European Association for Theoretical Computer
Science), EAPLS (European Association for Programming Languages and Systems),
and EASST (European Association of Software Science and Technology). The local
organization team consisted of Tiziana Margaria (general chair, UL and Lero),
Vasileios Koutavas (Lero@UCD), Anila Mjeda (Lero@UL), Anthony Ventresque
(Lero@UCD), and Petros Stratis (Easy Conferences).



The ETAPS Steering Committee (SC) consists of an Executive Board, and
representatives of the individual ETAPS conferences, as well as representatives of
EATCS, EAPLS, and EASST. The Executive Board consists of Holger Hermanns
(SaarbrĂźcken), Marieke Huisman (chair, Twente), Joost-Pieter Katoen (Aachen and
Twente), Jan Kofron (Prague), Gerald LĂźttgen (Bamberg), Tarmo Uustalu (Reykjavik
and Tallinn), Caterina Urban (Inria, Paris), and Lenore Zuck (Chicago).

Other members of the SC are: Armin Biere (Linz), Jordi Cabot (Barcelona), Jean
Goubault-Larrecq (Cachan), Jan-Friso Groote (Eindhoven), Esther Guerra (Madrid),
Jurriaan Hage (Utrecht), Reiko Heckel (Leicester), Panagiotis Katsaros (Thessaloniki),
Stefan Kiefer (Oxford), Barbara KĂśnig (Duisburg), Fabrice Kordon (Paris), Jan
Kretinsky (Munich), Kim G. Larsen (Aalborg), Tiziana Margaria (Limerick), Peter
MĂźller (Zurich), Catuscia Palamidessi (Palaiseau), Dave Parker (Birmingham),
Andrew M. Pitts (Cambridge), Peter Ryan (Luxembourg), Don Sannella (Edinburgh),
Bernhard Steffen (Dortmund), MariĂŤlle Stoelinga (Twente), Gabriele Taentzer
(Marburg), Christine Tasson (Paris), Peter Thiemann (Freiburg), Jan Vitek (Prague),
Heike Wehrheim (Paderborn), Anton Wijs (Eindhoven), and Nobuko Yoshida
(London).

I would like to take this opportunity to thank all speakers, attendants, organizers
of the satellite workshops, and Springer for their support. I hope you all enjoyed
ETAPS 2020. Finally, a big thanks to Tiziana and her local organization team for all
their enormous efforts enabling a fantastic ETAPS in Dublin!

February 2020 Marieke Huisman
ETAPS SC Chair

ETAPS e.V. President

vi ETAPS Foreword



Preface

This volume contains the papers presented at the 23rd International Conference on
Fundamental Approaches to Software Engineering (FASE 2020) held during
April 25–30, 2020, in Dublin, Ireland. FASE 2020 was organized as part of the annual
European Joint Conferences on Theory and Practice of Software (ETAPS 2020).

FASE is concerned with the foundations on which software engineering is built. The
papers submitted covered topics such as requirements engineering, software architec-
tures, specification, software quality, validation, verification of functional and
non-functional properties, model-driven development and model transformation, soft-
ware processes, security, and software evolution. In particular, the 2020 edition of
FASE saw an increased number of papers with empirical studies.

FASE 2020 had no separate abstract submission deadline and we received 81
submissions on the paper deadline with 5 tool papers, 4 empirical evaluation papers and
72 research papers. The submissions came from the following countries (in alphabetical
order): Argentina, Australia, Austria, Belgium, Canada, China, Colombia, Denmark,
Estonia, Finland, France, Germany, Greece, Hungary, India, Iran, Italy, Japan,
Luxembourg, Macedonia, Netherlands, New Zealand, Norway, Portugal, Russia,
Singapore, South Korea, Spain, Sweden, Switzerland, the UK, and the USA. Out
of these submissions, we accepted 23 papers (28% acceptance rate) after the review and
discussion phases with the Program Committee (PC) members plus 63 additional
external reviewers. FASE again used a double-blind reviewing process. We thank the
PC members and reviewers for doing an excellent job!

This volume also contains an invited paper by our keynote speaker Willem Visser. It
complements his talk on “The Magic of Analyzing Programs”.

For the first time, FASE hosted the International Competition on Software Testing
(Test-Comp 2020), chaired and organized by Dirk Beyer. Test-Comp 2020 is the
second edition of an annual competition for testing tools providing a comparative
evaluation of different tools. This edition contained 10 participating tools, from aca-
demia and industry. These proceedings contain papers of six tools, having participated
in the competition, as well as a summary by the competition organizer Dirk Beyer. The
tool papers were reviewed and selected by a separate PC: the Test-Comp 2020 jury.
Each Test-Comp paper was assessed by at least three reviewers.

We thank the ETAPS 2020 organizers, in particular, Tiziana Margaria, the general
chair, and Vasileios Koutavas, Anila Mjeda, Anthony Ventresque, and Petros Stratis.
We also thank Marieke Huisman, the ETAPS Steering Committee (SC) chair, for
managing the whole process, and Gabriele Taentzer, the FASE SC chair, for swift
feedback on several questions.

We hope that you will enjoy reading this volume.

February 2020 Jordi Cabot
Heike Wehrheim



Organization

FASE – Program Committee

Amel Bennaceur The Open University, UK
Jordi Cabot ICREA - UOC (Internet Interdisciplinary Institute),

Spain
Yu-Fang Chen Academia Sinica, Taiwan
Maria Christakis MPI SWS, Germany
Vittorio Cortellessa Universita’ dell’Aquila, Italy
Jin Song Dong National University of Singapore, Singapore
Neil Ernst University of Victoria, Canada
Esther Guerra Universidad AutĂłnoma de Madrid, Spain
Reiko Heckel University of Leicester, UK
Soichiro Hidaka Hosei University, Japan
Rob Hierons The University of Sheffield, UK
Jennifer Horkoff Chalmers and the University of Gothenburg, Sweden
Marieke Huisman University of Twente, The Netherlands
Reiner Hähnle TU Darmstadt, Germany
Marie-Christine Jakobs TU Darmstadt, Germany
Einar Broch Johnsen University of Oslo, Norway
Marjan Mernik University of Maribor, Slovenia
Arend Rensink University of Twente, The Netherlands
Augusto Sampaio Federal University of Pernambuco, Brazil
Ina Schaefer TU Braunschweig, Germany
Ana Sokolova University of Salzburg, Austria
Perdita Stevens The University of Edinburgh, UK
Marielle Stoelinga University of Twente, The Netherlands
Gabriele Taentzer Philipps-Universität Marburg, Germany
Wil van der Aalst RWTH Aachen University, Germany
Heike Wehrheim Paderborn University, Germany
Manuel Wimmer Johannes Kepler University Linz, Austria
Tao Yue Nanjing University of Aeronautics and Astronautics

and Simula Research Laboratory, China

Test-Comp – Program Committee and Jury

Dirk Beyer (Chair) LMU Munich, Germany
Marie-Christine Jakobs

(CoVeriTest)
TU Darmstadt, Germany

Lucas Cordeiro (ESBMC) University of Manchester, UK
Sebastian Ruland

(HybridTiger)
TU Darmstadt, Germany



Martin Nowack (KLEE) Imperial College London, UK
Gidon Ernst (Legion) LMU Munich, Germany
Hoang M. Le (LibKluzzer) University of Bremen, Germany
Thomas Lemberger

(PRTest)
LMU Munich, Germany

Marek Chalupa (Symbiotic) Masaryk University, Czech Republic
Joxan Jaffar (Tracer-X) National University of Singapore, Singapore
Raveendra Kumar

Medicherla (VeriFuzz)
Tata Consultancy Service, India

Additional Reviewers

Ahrendt, Wolfgang
Alqahtani, Abdullah Q. F.
Antonino, Pedro
Bacci, Giorgio
Bankhammer, Gregor
Barros, Flavia
Basciani, Francesco
Berardinelli, Luca
Bill, Robert
Bliudze, Simon
Bride, Hadrien
Bubel, Richard
Cerna, David
Di Pompeo, Daniele
Dillmann, Stefan
Dong, Naipeng
Fila, Barbara
Franzago, Mirco
Gerhold, Marcus
Ghaffari Saadat, Maryam
Gheyi, Rohit
Haas, Andreas
Heydari Tabar, Asmae
Hoare, Suchismita
JankĹŻ, Petr
Kamburjan, Eduard
Katsaros, Panagiotis
Klikovits, Stefan
KnĂźppel, Alexander
KĂśnighofer, Bettina
Le, Hoang M.
Leroy, Dorian

Lima, Lucas
Lin, Hsin-Hung
Lin, Shang-Wei
Lin, Yun
Lombardi, Tiziano
Lukina, Anna
Mauro, Jacopo
Nieke, Michael
Ölveczky, Peter
Pierantonio, Alfonso
Ponce De LeĂłn, HernĂĄn
Pun, Ka I.
Quanqi, Ye
Resmerita, Stefan
Ruijters, Enno
Runge, Tobias
Rutle, Adrian
Saivasan, Prakash
Sanan, David
Steffen, Martin
SteinhĂśfel, Dominic
Stolz, Volker
Summers, Alexander J.
Tapia Tarifa, Silvia Lizeth
Teixeira, Leopoldo
ThĂźm, Thomas
Tucci, Michele
Turrini, Andrea
van der Wal, Djurre
Wally, Bernhard
Wasser, Nathan
Wolny, Sabine

x Organization



Contents

Invited Talk

Improving Symbolic Automata Learning with Concolic Execution . . . . . . . . 3
Donato Clun, Phillip van Heerden, Antonio Filieri,
and Willem Visser

FASE Contributions

Platinum: Reusing Constraint Solutions in Bounded Analysis
of Relational Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

Guolong Zheng, Hamid Bagheri, Gregg Rothermel, and Jianghao Wang

Integrating Topological Proofs with Model Checking to Instrument
Iterative Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

Claudio Menghi, Alessandro Maria Rizzi, and Anna Bernasconi

A Generalized Formal Semantic Framework for Smart Contracts. . . . . . . . . . 75
Jiao Jiao, Shang-Wei Lin, and Jun Sun

An Empirical Study on the Use and Misuse of Java 8 Streams . . . . . . . . . . . 97
Raffi Khatchadourian, Yiming Tang, Mehdi Bagherzadeh,
and Baishakhi Ray

Extracting Semantics from Question-Answering Services
for Snippet Reuse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

Themistoklis Diamantopoulos, Nikolaos Oikonomou,
and Andreas Symeonidis

Global Reproducibility Through Local Control for Distributed
Active Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140

Lars Tveito, Einar Broch Johnsen, and Rudolf Schlatte

Multi-level Model Product Lines: Open and Closed Variability
for Modelling Language Families . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161

Juan de Lara and Esther Guerra

Computing Program Reliability Using Forward-Backward Precondition
Analysis and Model Counting. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182

Aleksandar S. Dimovski and Axel Legay



Skill-Based Verification of Cyber-Physical Systems. . . . . . . . . . . . . . . . . . . 203
Alexander KnĂźppel, Inga Jatzkowski, Marcus Nolte, Thomas ThĂźm,
Tobias Runge, and Ina Schaefer

Generating Large EMF Models Efficiently: A Rule-Based,
Configurable Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224

Nebras Nassar, Jens Kosiol, Timo Kehrer, and Gabriele Taentzer

Family-Based SPL Model Checking Using Parity Games with Variability . . . 245
Maurice H. ter Beek, Sjef van Loo, Erik P. de Vink,
and Tim A. C. Willemse

Model-Based Tool Support for Service Design . . . . . . . . . . . . . . . . . . . . . . 266
Francisco J. PĂŠrez-Blanco, Juan M. Vara, Cristian GĂłmez,
Valeria De Castro, and Esperanza Marcos

Incremental Concurrent Model Synchronization using Triple
Graph Grammars. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273

Fernando Orejas, Elvira Pino, and Marisa Navarro

Statistical Model Checking for Variability-Intensive Systems . . . . . . . . . . . . 294
Maxime Cordy, Mike Papadakis, and Axel Legay

Schema Compliant Consistency Management via Triple Graph Grammars
and Integer Linear Programming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315

Nils Weidmann and Anthony Anjorin

Towards Multiple Model Synchronization with Comprehensive Systems . . . . 335
Patrick StĂźnkel, Harald KĂśnig, Yngve Lamo, and Adrian Rutle

Analysis and Refactoring of Software Systems Using Performance
Antipattern Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357

Radu Calinescu, Vittorio Cortellessa, Ioannis Stefanakos,
and Catia Trubiani

Business Process Compliance Using Reference Models of Law. . . . . . . . . . . 378
Hugo A. López, Søren Debois, Tijs Slaats, and Thomas T. Hildebrandt

Algorithmic Analysis of Blockchain Efficiency with Communication Delay . . . 400
Carlos PinzĂłn, Camilo Rocha, and Jorge Finke

Holistic Specifications for Robust Programs . . . . . . . . . . . . . . . . . . . . . . . . 420
Sophia Drossopoulou, James Noble, Julian Mackay,
and Susan Eisenbach

Automated Generation of Consistent Graph Models with First-Order Logic
Theorem Provers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 441

Aren A. Babikian, OszkĂĄr SemerĂĄth, and DĂĄniel VarrĂł

xii Contents



Combining Partial Specifications using Alternating Interface Automata . . . . . 462
Ramon Janssen

Revisiting Semantics of Interactions for Trace Validity Analysis . . . . . . . . . . 482
Erwan Mahe, Christophe Gaston, and Pascale Le Gall

Test-Comp Contributions

Second Competition on Software Testing: Test-Comp 2020 . . . . . . . . . . . . . 505
Dirk Beyer

HybridTiger: Hybrid Model Checking and Domination-based Partitioning
for Efficient Multi-Goal Test-Suite Generation (Competition Contribution) . . . 520

Sebastian Ruland, Malte Lochau, and Marie-Christine Jakobs

ESBMC: Scalable and Precise Test Generation based on the Floating-Point
Theory (Competition Contribution) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 525

Mikhail R. Gadelha, Rafael Menezes, Felipe R. Monteiro,
Lucas C. Cordeiro, and Denis Nicole

TracerX: Dynamic Symbolic Execution with Interpolation
(Competition Contribution). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 530

Joxan Jaffar, Rasool Maghareh, Sangharatna Godboley,
and Xuan-Linh Ha

LLVM-based Hybrid Fuzzing with LibKluzzer (Competition Contribution) . . . . 535
Hoang M. Le

CoVeriTest with Dynamic Partitioning of the Iteration Time Limit
(Competition Contribution). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 540

Marie-Christine Jakobs

LEGION: Best-First Concolic Testing (Competition Contribution) . . . . . . . . . . 545
Dongge Liu, Gidon Ernst, Toby Murray, and Benjamin I. P. Rubinstein

Author Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 551

Contents xiii



Invited Talk



Improving symbolic automata learning
with concolic execution ďż˝

Donato Clun1 , Phillip van Heerden2 , Antonio Filieri1 , and Willem
Visser2

1 Imperial College London
2 Stellenbosch University

Abstract. Inferring the input grammar accepted by a program is cen-
tral for a variety of software engineering problems, including parsers
verification, grammar-based fuzzing, communication protocol inference,
and documentation. Sound and complete active learning techniques have
been developed for several classes of languages and the corresponding au-
tomaton representation, however there are outstanding challenges that
are limiting their effective application to the inference of input grammars.
We focus on active learning techniques based on L∗ and propose two ex-
tensions of the Minimally Adequate Teacher framework that allow the
efficient learning of the input language of a program in the form of sym-
bolic automata, leveraging the additional information that can extracted
from concolic execution. Upon these extensions we develop two learning
algorithms that reduce significantly the number of queries required to
converge to the correct hypothesis.

1 Introduction

Inferring the input grammar of a program from its implementation is central
for a variety of software engineering activities, including automated documenta-
tion, compiler analyses, and grammar-based fuzzing.

Several learning algorithms have been investigated for inferring a grammar
from examples of accepted and rejected input words, with active learning ap-
proaches achieving the highest data-efficiency and strong convergence guaran-
tees. Active learning is a theoretical framework enabling a learner to gather
information about a target language by interacting with a teacher [1]. A mini-
mally adequate teacher that can guarantee the convergence of an active language
learning procedure for regular language is an oracle that can answer membership
and equivalence queries. Membership queries check whether a word indicated by
the learner is accepted by the target language and equivalence queries can con-
firm that a hypothesis language proposed by the learner is equivalent to the
target language, or provide a counterexample word otherwise.

ďż˝ This work has been partially supported by the EPSRC HiPEDS Centre for Doc-
toral Training (EP/L016796/1), the DSI-NRF Centre of Excellence in Mathematical
and Statistical Sciences (CoE-MaSS), and a Royal Society Newton Mobility Grant
(NMG\R2 \170142).

cŠ The Author(s) 2020
H. Wehrheim and J. Cabot (Eds.): FASE 2020, LNCS 12076, pp. 3–26, 2020.
https://doi.org/10.1007/978-3-030-45234-6_1

http://orcid.org/0000-0001-5190-8957
http://orcid.org/0000-0002-1801-2996
http://orcid.org/0000-0001-9646-646X
http://orcid.org/0000-0002-0913-3091
http://crossmark.crossref.org/dialog/?doi=10.1007/978-3-030-45234-6_1&domain=pdf


However, when learning the input language accepted by a program from its
code implementation, it is unrealistic to assume the availability of a complete
equivalence oracle, because such an oracle would need to check the equivalence
between the hypothesis language and arbitrary software code.

In this paper, we explore the use of concolic execution to design active learn-
ing procedures for inferring the input grammar of a program in the form of a
symbolic finite automaton. In particular, we extend two state of the art active
learning frameworks for symbolic learning by enabling the teacher to 1) provide
more informative answers for membership queries by pairing the accept/reject
outcome with a path condition describing all the input words that would result in
the same execution as the word indicated by the learner, and 2) provide a partial
equivalence oracle that may produce counterexamples for the learner hypothe-
sis. The partial equivalence oracle would rely on the exploration capabilities of
the concolic execution engine to identify input words for which the acceptance
outcome differs between the target program and the learner’s hypothesis. To
guarantee the termination of the concolic execution for equivalence queries, we
set a bound on the length of the inputs the engine can generate during its ex-
ploration. While necessarily incomplete, such equivalence oracle may effectively
guide the learning process and guarantee the correctness of the learned language
for inputs up to the set input bound. Finally, we propose a new class of symbolic
membership queries that build on the constraint solving capabilities of the con-
colic engine to directly infer complete information about the transitions between
states of the hypothesis language.

In our preliminary evaluation based on Java implementations of parsers for
regular languages from the Automatark benchmark suite, the new active learning
algorithms enabled by concolic execution learned the correct input language
for 76% of the subject, despite the lack of a complete equivalence oracle and
achieving a reduction of up to 96% of the number of membership and equivalence
queries produced by the learner.

The remaining of the paper is structured as follows: Section 2 introduces
background concepts and definitions concerning symbolic finite state automata,
active learning, and concolic execution. Section 3 describes in details the data
structures and learning algorithms of two state of the art approaches – Λ∗ [11]
and MAT* [3] – that will be the base for active learning strategies based on
concolic execution formalized in Section 4. Section 5 will report on our prelim-
inary experiments on the effectiveness and query-efficiency capabilities of the
new strategies. Finally, Section 6 discusses related work and Section 7 presents
our concluding remarks.

2 Preliminaries

2.1 Symbolic finite state automata

Symbolic finite state automata (SFA) are an extension of finite state au-
tomata where a transitions can be labeled with a predicate identifying a subset
of the input alphabet [28]. The set of predicates allowed on SFA transitions
should constitute an effective Boolean algebra [3], which guarantees closure with
respect to boolean operations according to the following definition:

4 D. Clun et al.



Improving symbolic automata learning with concolic execution 5

Definition 1. Effective Boolean algebra [3]. An effective Boolean algebra A is a
tuple (D, Ψ, � �,⊥,�,∨,∧,¬) where D is the set of domain elements; Ψ is the set
of predicates, including ⊥ and �; � � : Ψ → 2D is a denotation function such that
�⊥� = ∅, ��� = D, and for all φ, ψ ∈ Ψ , �φ∨ψ� = �φ�∪ �ψ�, �φ∧ψ� = �φ�∩ �ψ�,
and �¬φ� = D \ �φ�.

Given an effective Boolean algebra A, an SFA is formally defined as:

Definition 2. Symbolic Finite Automaton (SFA) [3]. A symbolic finite automa-
ton M is a tuple (A, Q, qinit, F,Δ) where A is an effective Boolean algebra, called
the alphabet; Q is a finite set of states; qinit ∈ Q is the initial state; F ⊆ Q is
the set of final states; and Δ ⊆ Q×ΨA ×Q is the transition relation consisting
of a finite set of moves or transitions.

Given a linearly ordered finite alphabet ÎŁ, through the rest of the paper we
will assume A to be the Boolean algebra over the union of intervals over ÎŁ, with
the canonical interpretations of union, intersection, and negation operators. With
an abuse of notation, we will write ψ ∈ A to refer to a predicate ψ in the set Ψ of
A. A word is a finite sequence of alphabet symbols (characters) w = w0w1 . . . wn

(wi ∈ Σ), whose length len(w) = n − 1. We indicate with w[: i] the prefix of
w up to the i element excluded, and with w[i :] the suffix of w starting from
element i. We will use the notation wi and w[i] interchangeably. The language
accepted by an SFA M will be indicated as LM, or only L when the SFA M can
be inferred by the context. For an SFA M and a word w, M(w) = true if M
accepts w; false otherwise.

Similarly to finite state automata, SFAs are closed under language inter-
section, union, and complement, and admit a minimal form [3]. Compared to
non-symbolic automata, SFAs can produce more compact representations over
large alphabets (e.g., Unicode), allowing a single transition predicate to account
for a possibly large set of characters, instead of explicitly enumerating all of
them.

2.2 Active learning and minimally adequate teachers

Active learning encompasses a set of techniques enabling a learning algo-
rithm to gather information interacting with a suitable oracle, referred to as
teacher. Angluin [1] proposed an exact, active learning algorithm for a regular
language L named L∗. In L∗ the learner can ask the oracle two types of queries,
namely membership and equivalence queries. In a membership query, the learner
selects a word w ∈ Σ∗ and the oracle answers whether the w ∈ L (formally, the
membership oracle is a function Om : Σ∗ → B, where B = {true, false}). In
an equivalence query, the learner selects an hypothesis finite state automaton
(FSA) H and asks the oracle whether LH ≡ L; if LH 
≡ L, the oracle returns a
counterexample, i.e., a word w in which L differs from LH (formally, the equiv-
alence oracle is a function Oe : FSA → Σ∗ ∪ {true}). A teacher providing both
Om and Oe, and able to produce a counter example as result from Oe is called
a minimally adequate teacher. Given a minimally adequate teacher, L∗ is guar-
anteed to learn the target language L with a number of queries polynomial in
the number of states of a minimal deterministic automaton accepting L and in
the size of the largest counterexample returned by the teacher [1].



Discovering FSA states. Consider an FSA M. Given two words u and v such
that M(u) 
= M(v) (i.e., one accepted and one rejected), it can be concluded
that u and v reach different states of M. Moreover, if u and v share a suffix
s (i.e., u = a.s and v = b.s with a, b, s ∈ Σ∗ and the dot representing word
concatenation), a and b necessarily reach two different states qa and qb ofM. The
suffix s is a discriminator suffix for the two states because its parsing starting
from qa and qb leads to difference acceptance outcomes. The words a and b are
instead access words of qa and qb, respectively, because their parsing from the
initial state reaches qa and qb. This observation can be generalized to a set of
words by considering all the unordered pairs of words in the set. Because M is a
finite state automaton, there can be only a finite number of discriminable words
in Σ∗ and, correspondingly, a finite number of distinct access string identifying
the automaton’s states.
State reached parsing a word. For a word w, consider a known discriminator
suffix s and access word a. If Om(w.s) 
= Om(a.s), the state reached parsing w
cannot be the one identified by a. Throughout the learning process, it is possible
that none of the already discovered access words identifies the state reached by
w. In this case, w would be a suitable candidate for discovering a new FSA state
as described in the previous paragraph.
Discovering FSA transitions. For each access string a and symbol σ ∈ Σ, a
transition should exist between the states reached parsing a and a.σ, respectively.

2.3 Concolic execution

Concolic execution [14,27] combines concrete and symbolic execution of a
program, allowing to extract for a given concrete input a set of constraints on
the input space that uniquely characterize the corresponding execution path. To
this end, the target program is instrumented to pair each program input with a
symbolic input variable and to record along an execution path the constraints
on the symbolic inputs induced by the encountered conditional branches. The
conjunction of the constraints recorded during the execution of the instrumented
program on a concrete input is called path condition and characterize the equiv-
alence class of all the inputs that would follow the same execution path (in this
paper, we focus on sequential program, whose execution is uniquely determined
by the program inputs).

Explored path conditions can be stored in a prefix tree (symbolic execution
tree), which captures all the paths already covered by at least one executed in-
put. A concolic engine can traverse the symbolic execution tree to find branches
not yet explored. The path condition corresponding to the selected unexplored
branch is then solved using a constraint solver (e.g., an SMT solver [26]) gen-
erating a concrete inp";"""date"",""2020-04-18T04:35:35Z""
""pdf:PDFVersion"",""1.4""
""xmp:CreatorTool"",""Adobe Acrobat Pro 10.1.1""
""pdf:docinfo:title"",""""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""pdfa:PDFVersion"",""A-2b""
""xmpMM:History:Action"",""converted"",""converted"",""converted"",""converted"",""converted"",""converted"",""converted"",""converted"",""converted"",""converted"",""converted"",""converted""
""language"",""en""
""dc:format"",""application/pdf; version=""""A-2b"""""",""application/pdf; version=1.4""
""pdf:docinfo:creator_tool"",""Adobe Acrobat Pro 10.1.1""
""access_permission:fill_in_form"",""true""
""xmpMM:History:When"",""2020-04-10T15:39:38Z"",""2020-04-10T16:41:16Z"",""2020-04-10T17:01:07Z"",""2020-04-15T19:31:48Z"",""2020-04-16T06:43:55Z"",""2020-04-16T19:04:38Z"",""2020-04-16T19:14:56Z"",""2020-04-18T09:06:38Z"",""2020-04-18T09:14:48Z"",""2020-04-18T09:26:29Z"",""2020-04-18T09:29:28Z"",""2020-04-18T09:56:51Z""
""pdf:encrypted"",""false""
""dc:title"",""""
""xmp:CreateDate"",""2020-04-17T11:59:37Z""
""modified"",""2020-04-18T04:35:35Z""
""xmpMM:History:SoftwareAgent"",""pdfToolbox"",""pdfToolbox"",""pdfToolbox"",""pdfToolbox"",""pdfToolbox"",""pdfToolbox"",""pdfToolbox"",""pdfToolbox"",""pdfToolbox"",""pdfToolbox"",""pdfToolbox"",""pdfToolbox""
""pdf:hasMarkedContent"",""false""
""xmpMM:History:InstanceID"",""uuid:86a2e15a-431c-400f-8edf-fa4f2ce6cb19"",""uuid:398c384f-8f4f-4d21-b62c-86efb0d45485"",""uuid:b3f6248d-b976-49cf-85e8-25df21c2414b"",""uuid:3462d50e-f60b-47fb-8d47-89aa964f9042"",""uuid:53eeae43-23c8-43bc-bd11-fb942b770bc8"",""uuid:6ff2c645-249b-4630-a3fa-b27fa7774214"",""uuid:9a7c425b-15c5-4b55-b029-03609c292469"",""uuid:e5e5e45d-e627-4f2a-8483-65ac07425c9d"",""uuid:5b4cc568-b118-4870-8fdb-27ef45f05856"",""uuid:32e2f10c-8b43-4cd5-9abf-0c0aefd98b64"",""uuid:8512dbe7-fed8-4f8a-af10-86dfa53312da"",""uuid:8d705e49-4b95-4425-939a-05b2627be1ba""
""xmp:ModifyDate"",""2020-04-18T10:05:35Z""
""meta:creation-date"",""2020-04-17T06:29:37Z""
""created"",""2020-04-17T06:29:37Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-04-17T06:29:37Z""
""resourceName"",""2020_Book_FundamentalApproachesToSoftwar.pdf""
""pdfaid:part"",""2""
""producer"",""Adobe Acrobat Pro 10.1.1""
""pdf:docinfo:producer"",""Adobe Acrobat Pro 10.1.1""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""3"",""0"",""28"",""2"",""0"",""6"",""4"",""11"",""2"",""4"",""2"",""4"",""2"",""1"",""5"",""3"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""1"",""0"",""0"",""0"",""0"",""2"",""0"",""2"",""6"",""1"",""5"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""1"",""0"",""0"",""37"",""1"",""84"",""21"",""25"",""68"",""51"",""26"",""37"",""70"",""86"",""15"",""79"",""1"",""0"",""0"",""0"",""0"",""0"",""2"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""2"",""0"",""0"",""0"",""4"",""1"",""0"",""3"",""0"",""0"",""0"",""0"",""0"",""0"",""1"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""1"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""1"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""1"",""0"",""0"",""1"",""2"",""0"",""12"",""11"",""1"",""1"",""17"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""1"",""0"",""0"",""0"",""0"",""6"",""37"",""2"",""19"",""6"",""13"",""9"",""20"",""0"",""0"",""0"",""14"",""80"",""0"",""0"",""0"",""1"",""0"",""0"",""9"",""17"",""29"",""54"",""42"",""6"",""8"",""11"",""41"",""2"",""2"",""6"",""9"",""0"",""0"",""0"",""0"",""0"",""1"",""0"",""0"",""0"",""4"",""5"",""22"",""10"",""12"",""21"",""10"",""37"",""2"",""0"",""0"",""3"",""0"",""0"",""0"",""0"",""0"",""4"",""0"",""0"",""0"",""0"",""0"",""0"",""2"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""1"",""0"",""0"",""0"",""0"",""1"",""0"",""6"",""5"",""11"",""20"",""5"",""4"",""9"",""43"",""39"",""44"",""62"",""36"",""18"",""0"",""0"",""0"",""0"",""0"",""0"",""1"",""0"",""0"",""0"",""0"",""0"",""0"",""3"",""0"",""15"",""1"",""17"",""11"",""41"",""5"",""9"",""28"",""15"",""31"",""22"",""9"",""15"",""16"",""1"",""0"",""0"",""0"",""0"",""1"",""2"",""0"",""7"",""3"",""0"",""14"",""3"",""2"",""6"",""9"",""0"",""99"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""1"",""0"",""0"",""0"",""0"",""0"",""0"",""20"",""7"",""5"",""15"",""8"",""11"",""25"",""23"",""0"",""0"",""0"",""0"",""0"",""1"",""0"",""3"",""0"",""0"",""0"",""0"",""0"",""0"",""4"",""32"",""1"",""9"",""6"",""9"",""11"",""22"",""2"",""0"",""0"",""0"",""0"",""3"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""1"",""0"",""0"",""0"",""0"",""7"",""2"",""0"",""19"",""62"",""15"",""7"",""13"",""10"",""5"",""1"",""0"",""0"",""0"",""0"",""0"",""0"",""1"",""0"",""0"",""0"",""48"",""3"",""7"",""0"",""8"",""15"",""3"",""26"",""4"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""1"",""10"",""0"",""0"",""51"",""0"",""51"",""50"",""31"",""21"",""51"",""73"",""42"",""106"",""26"",""1"",""2"",""0"",""0"",""0"",""0"",""1"",""0"",""0"",""2"",""2"",""0"",""0"",""10"",""6"",""4"",""5"",""5"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""3"",""0"",""0"",""2"",""17"",""5"",""27"",""28"",""19"",""40"",""21"",""11"",""20"",""20"",""34"",""0"",""22"",""2"",""0"",""0"",""1"",""3"",""2"",""13"",""27"",""13"",""12"",""15"",""19"",""4"",""31"",""12"",""21"",""11"",""18"",""4"",""6"",""1"",""0"",""0"",""0"",""1"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""31"",""0"",""0"",""0"",""0"",""0"",""0"",""1"",""0"",""0"",""0"",""0"",""3"",""0"",""0"",""0"",""0"",""1"",""1"",""64"",""0"",""0"",""1"",""0"",""0"",""0"",""0"",""7"",""0"",""0"",""0"",""0"",""7"",""0"",""0"",""0"",""0"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dcterms:created"",""2020-04-17T06:29:37Z""
""Last-Modified"",""2020-04-18T04:35:35Z""
""dcterms:modified"",""2020-04-18T04:35:35Z""
""title"",""""
""xmpMM:DocumentID"",""uuid:f2ae530e-d63a-409a-8de7-5a1248ee0ffa""
""Last-Save-Date"",""2020-04-18T04:35:35Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2020-04-18T04:35:35Z""
""meta:save-date"",""2020-04-18T04:35:35Z""
""Content-Length"",""28011639""
""Content-Type"",""application/pdf""
""xmp:MetadataDate"",""2020-04-18T10:05:35Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""pdfaid:conformance"",""B""
""dc:language"",""EN""
""pdf:producer"",""Adobe Acrobat Pro 10.1.1""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""560""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""273"",""619"",""67"",""227"",""1890"",""2551"",""1437"",""2474"",""1461"",""1282"",""1340"",""1826"",""1272"",""11"",""2232"",""2771"",""2693"",""2755"",""2128"",""2721"",""2430"",""2173"",""2107"",""2937"",""2018"",""2871"",""1748"",""1982"",""2137"",""2032"",""2780"",""2487"",""2345"",""2627"",""2674"",""2644"",""3029"",""1781"",""17"",""2855"",""3142"",""2787"",""2855"",""2854"",""1780"",""2671"",""2715"",""2501"",""2584"",""3007"",""2709"",""2047"",""1907"",""2878"",""1540"",""2987"",""2740"",""2672"",""2704"",""2844"",""2764"",""2282"",""721"",""2284"",""2795"",""2641"",""2101"",""2171"",""2195"",""2219"",""2235"",""2251"",""2032"",""1826"",""2143"",""2273"",""2122"",""2072"",""2390"",""2632"",""2576"",""2730"",""2835"",""2870"",""2558"",""2263"",""3040"",""3096"",""2586"",""2299"",""2418"",""2131"",""2348"",""2135"",""2325"",""2296"",""2786"",""2260"",""2822"",""2751"",""2331"",""2406"",""2560"",""2966"",""3047"",""2928"",""1714"",""2207"",""2984"",""2882"",""2834"",""2579"",""2716"",""2774"",""2735"",""84"",""2737"",""2797"",""2767"",""1426"",""2373"",""2806"",""2826"",""2745"",""2762"",""2975"",""3052"",""3151"",""2476"",""2151"",""2723"",""3019"",""2939"",""1848"",""1927"",""1170"",""2525"",""2655"",""1977"",""2473"",""2064"",""1968"",""1156"",""1866"",""1916"",""1672"",""2398"",""2857"",""2991"",""2643"",""2338"",""3014"",""1968"",""2339"",""2650"",""1857"",""1798"",""2194"",""2103"",""2631"",""1920"",""2692"",""2289"",""2668"",""2686"",""1144"",""1897"",""2735"",""2809"",""3049"",""1938"",""2521"",""2514"",""1933"",""1900"",""2442"",""2340"",""2461"",""1151"",""2609"",""1839"",""2156"",""2100"",""1942"",""1584"",""2854"",""3072"",""2515"",""2036"",""2939"",""3031"",""1314"",""2251"",""3101"",""2657"",""2185"",""2449"",""2500"",""2127"",""2467"",""2515"",""2134"",""2542"",""2482"",""2253"",""2715"",""2214"",""2131"",""3028"",""2761"",""2899"",""2685"",""729"",""2185"",""2359"",""3011"",""1919"",""2445"",""2479"",""2058"",""2196"",""2314"",""2038"",""2074"",""2121"",""1947"",""2242"",""2342"",""2234"",""2149"",""2729"",""2647"",""2676"",""752"",""2229"",""2884"",""2158"",""2737"",""1920"",""1602"",""2488"",""2285"",""1190"",""1716"",""1230"",""2023"",""1576"",""2619"",""2436"",""2221"",""1833"",""2376"",""2823"",""2267"",""720"",""2372"",""3080"",""2310"",""2625"",""2241"",""1638"",""2222"",""2522"",""2243"",""1890"",""2437"",""1706"",""2491"",""2767"",""1529"",""2248"",""2129"",""2869"",""2714"",""2904"",""1588"",""124"",""41"",""25"",""41"",""25"",""41"",""25"",""2420"",""2598"",""2779"",""2120"",""1591"",""2855"",""2610"",""2718"",""1510"",""2818"",""2792"",""1609"",""1868"",""1174"",""1985"",""2680"",""2560"",""2865"",""3013"",""3078"",""749"",""2259"",""2953"",""2628"",""2586"",""1740"",""2415"",""1827"",""2717"",""2341"",""1969"",""2335"",""2416"",""2367"",""958"",""2534"",""1935"",""850"",""2394"",""3032"",""3107"",""2553"",""2166"",""2998"",""1775"",""1768"",""2756"",""1407"",""2968"",""2284"",""2259"",""2025"",""2221"",""1876"",""1872"",""2122"",""2259"",""2806"",""2114"",""2219"",""2959"",""2637"",""2314"",""2637"",""2386"",""1606"",""2550"",""2919"",""1919"",""1869"",""2602"",""2309"",""1467"",""2420"",""2516"",""2198"",""2094"",""2454"",""2235"",""2655"",""3028"",""2657"",""2844"",""847"",""2211"",""2663"",""1983"",""2152"",""2390"",""1991"",""2510"",""2294"",""2254"",""2240"",""2677"",""1813"",""1484"",""2076"",""2083"",""1870"",""2820"",""2612"",""2951"",""2612"",""769"",""2141"",""2897"",""2939"",""2737"",""1213"",""2048"",""2859"",""1513"",""2325"",""1959"",""2107"",""2744"",""2299"",""2059"",""2242"",""2332"",""2762"",""2778"",""2924"",""3023"",""2896"",""757"",""2327"",""2986"",""2740"",""2794"",""2086"",""2018"",""2677"",""2347"",""2702"",""1063"",""1838"",""1588"",""1667"",""1855"",""1728"",""1948"",""3007"",""2710"",""2765"",""1847"",""2386"",""1980"",""2367"",""2795"",""2582"",""1889"",""2208"",""2555"",""2403"",""2521"",""1790"",""2045"",""2325"",""2554"",""1883"",""2892"",""3142"",""2657"",""2787"",""3131"",""1816"",""2234"",""2813"",""1888"",""2106"",""1890"",""2200"",""2573"",""2094"",""2001"",""1544"",""2438"",""1998"",""2051"",""2863"",""1821"",""1947"",""2575"",""2750"",""2904"",""3024"",""1882"",""2255"",""2065"",""2103"",""2168"",""1940"",""1748"",""1976"",""1277"",""1679"",""1821"",""2014"",""1344"",""1896"",""2326"",""1593"",""1111"",""2013"",""1660"",""2835"",""1065"",""2131"",""2623"",""2375"",""2468"",""2138"",""1933"",""2103"",""1999"",""2563"",""1931"",""2390"",""2819"",""1971"",""2147"",""2410"",""2066"",""2907"",""2527"",""2901"",""2674"",""22"",""2237"",""2718"",""2626"",""1723"",""2376"",""260"",""1941"",""2081"",""1414"",""1691"",""736"",""1970"",""2797"",""2809"",""1665"",""2081"",""1838"",""1667"",""1826"",""1490"",""2086"",""2795"",""2476"",""2276"",""2215"",""2219"",""1926"",""2316"",""2456"",""2177"",""1958"",""2354"",""2347"",""1953"",""1332"",""2143"",""1940"",""2711"",""2183"",""1473"",""2231"",""2382"",""2556"",""2794"",""1049"",""1264"",""436""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-04-17T06:29:37Z""
";https://scholar.google.ch/scholar?start=830&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098743-54;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;An intelligent Edge-IoT platform for monitoring livestock and crops in a dairy farming scenario;RS Alonso, I Sittón;Candanedo, Ó García, J Prieto…  Ad Hoc Networks, 2020  Elsevier;;"… A set of agents called oracles are found in the GECA IoT layer, they act as intermediaries

between the data coming from IoT devices and the blockchain [58]. The process starts

when the IoT devices send the data to the oracles for verification …";Cité 49 fois;Les 2 versions;null;;;;https://scholar.google.ch/scholar?start=600&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098809-206;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;The smart contract revolution: a solution for the holdup problem?;O Meier, A Sannajust ; Small Business Economics, 2020  Springer;;"… This means that entrepreneurs have to deal with incomplete contracts. Blockchain was born in

1994 (Satoshi Nakamoto), alongside the emer- gence of smart contracts (Nick Szabo) … Keywords

Blockchain . Smart contracts . Opportunism . Information asymmetry …";Cité 2 fois;Les 5 versions;null;;;;https://scholar.google.ch/scholar?start=750&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098892-391;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Integrating Blockchain with Local Public Service System;VA Bharadi, PP Ghag, SR Chavan, SS Gawas, A Kazi ; ICBCT 2019, 2020  Springer;;"… Satoshi Nakamoto invents a blockchain in 2008 to serve the public transaction ledger of the

cryptocurrency bitcoin [3]. Blockchain technology can collect multiple … At Infosys, they implemented

the blockchain protocol with a three-layer architecture, based on Oracle and SAP at …";Cité 1 fois;Les 3 versions;null;;;;https://scholar.google.ch/scholar?start=940&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098818-226;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Scalable ciphertext compression techniques for post-quantum KEMs and their applications;S Katsumata, K Kwiatkowski, F Pintore… ; … Conference on the Theory …, 2020  Springer;;"… In Fig. 2, \(\mathsf {G}_1, \mathsf {G}_2,\mathsf {H}, \mathsf {H}'\) are hash functions

modeled as random oracles in the security proof. They can be simulated by a single

random oracle by using appropriate domain separation …";Cité 2 fois;Les 2 versions;[PDF] iacr.org;https://eprint.iacr.org/2020/1107.pdf;"
Scalable Ciphertext Compression Techniques for Post-Quantum

KEMs and their Applications

Shuichi Katsumata1, Kris Kwiatkowski2, Federico Pintore3, Thomas Prest2

1National Institute of Advanced Industrial Science and Technology (AIST), JP

shuichi.katsumata@aist.go.jp
2PQShield, UK

kris.kwiatkowski, thomas.prest@pqshield.com
3Mathematical Institute, University of Oxford, UK

federico.pintore@maths.ox.ac.uk

December 2, 2020

Abstract

A multi-recipient key encapsulation mechanism, or mKEM, provides a scalable solution to securely
communicating to a large group, and offers savings in both bandwidth and computational cost compared
to the trivial solution of communicating with each member individually. All prior works on mKEM are
only limited to classical assumptions and, although some generic constructions are known, they all require
specific properties that are not shared by most post-quantum schemes. In this work, we first provide a
simple and efficient generic construction of mKEM that can be instantiated from versatile assumptions,
including post-quantum ones. We then study these mKEM instantiations at a practical level using 8
post-quantum KEMs (which are lattice and isogeny-based NIST candidates), and CSIDH, and show that
compared to the trivial solution, our mKEM offers savings of at least one order of magnitude in the
bandwidth, and make encryption time shorter by a factor ranging from 1.92 to 35. Additionally, we show
that by combining mKEM with the TreeKEM protocol used by MLS – an IETF draft for secure group
messaging – we obtain significant bandwidth savings.

1 Introduction

Secure communication within a system of several users is becoming indispensable in our everyday lives. One
leading example is the recent trend in secure group messaging (Zoom, Signal, WhatsApp, and so on) to
handle large groups – up to 50 000 users according to the IETF draft of the Message Layer Security (MLS)
architecture [OBR+20, Section 3.1]. The scenario is that users in a system, each holding their public and
secret key, frequently exchange messages with a group of users. More than often, the solution adopted is
the trivial approach of individually encrypting the same message M using the public keys associated with
the respective recipients in the group.1 However, this trivial approach makes the required bandwidth and
computational costs grow by a factor N (where N is the number of recipients), compared to sending a
message to a single recipient. Therefore, as the number of recipients increases, this trivial solution has poor
scalability.

An additional motivation for lowering the bandwidth and computational costs is the current phase of
gradual transition towards post-quantum cryptography — a type of cryptography that is known to be resilient

1To be more precise, it is common to rely on the KEM/DEM framework [CS03, Den03] to lower the reliance on the more
inefficient public key cryptography.

1



against quantum adversaries. Most, if not all, post-quantum secure schemes are known to incur bandwidth
and/or computational overheads compared to classical schemes. For example, all key encapsulation mecha-
nisms (KEMs) still considered for standardization by NIST require an order of magnitude more bandwidth
than ECDH [BCR+] at a comparable classical security level. Therefore, lowering the cost of communication
with multiple recipients even when the number of recipients N is only moderately large, say N ≥ 10, will
already be of value.

Multi-Recipient Key Encapsulation Mechanism (mKEM), coined by Smart [Sma05]2, is a primitive
designed with the above motivations in mind. On a high level, an mKEM is like a standard KEM that securely
sends the same session key K to a group of recipients. Subsequently, the sender transmits a single ciphertext
to all the recipients by encrypting the message M using K as a secret key for a secret-key encryption scheme.
The latter procedure corresponds to the standard DEM. The main requirement that makes mKEM appealing
is that the bandwidth and computational resources required to send the session key K are less than those
required when individually encrypting K using the recipients’ public keys. To be precise, we can trivially
construct an mKEM from any public-key encryption (PKE) scheme by encrypting the same session key K
with respect to all the recipients’ public keys. However, this trivial construction will be as inefficient as
the aforementioned trivial solution (modulo the efficient DEM component), and therefore, the main goal for
mKEM is to offer a more efficient alternative.

Due to its practically appealing and theoretically interesting nature, the study of mKEM has attracted
much attention, e.g., [Kur02,BF07,HK07,HTAS09,MH13,Yan15]. Also, similar variants of mKEM, such as
multi-message multi-recipient public-key encryption [BBM00, BPS00, Kur02, BBS03], have been considered
prior to mKEM with similar motivations in mind, and have illustrated the importance of investigating the
multi-recipient settings. As a consequence, by now many exciting results regarding mKEMs have appeared.
However, we like to point out three unsatisfactory issues remaining with burdening the current state of
affairs. First, to the best of our knowledge, all the literature on mKEMs is based on classical assumptions
(e.g., Diffie-Hellman type assumptions) which are believed to not endure quantum adversaries. We are
aware of one recent work [CLQY18] that claims the construction of an IND-CCA secure mKEM from the
learning parity with noise (LPN) assumption, which is believed to be quantumly secure. However, while
going over their results, we noticed that their scheme is insecure since there is a trivial break in their claimed
IND-CCA security. In particular, the ciphertexts are easily malleable. See Appendix A for more detail.
Second, earlier works such as [BF07, HTAS09, MH13] provide a somewhat generic construction of mKEM
from a (single-recipient) PKE, but require the underlying PKE to satisfy rather specific properties that seems
somewhat tailored to classical Diffie-Hellman type assumptions. For instance, [BF07] requires a notion of
weak reproducibility, which informally states that there is an efficient procedure to re-randomize a ciphertext
under a certain public key to a ciphertext under another public key. Unfortunately, such properties are not
known to exist for post-quantum assumptions, such as lattice-based assumptions. Therefore, we still do not
have a truly general framework for constructing mKEMs from standard building blocks. Here, “standard”
building blocks mean blocks that are potentially instantiable from many hardness assumptions.

Summarizing thus far, the first question we are interested in this work is:

(Theoretical Question) Are there any simple and efficient generic constructions of mKEM that
can be based on versatile assumptions, including post-quantum assumptions?

The third issue, which is orthogonal to the above concerns, is that all previous works on mKEM do not come
with any implementations. Notably, most literature only points out the efficiency gain in a rather theoretical
manner and does not provide comparisons with the trivial solution (i.e., running KEM in parallel). Since
these gains depend on the concrete mKEM implementation and also on the choice of KEM used in the trivial
solution, the benefit of using an mKEM is unclear without proper comparison. Considering the practical
oriented nature of mKEM, we believe understanding the concrete gain of using an mKEM instead of using
the trivial solution would help in illustrating the practical relevance of this primitive and in providing insight
on when to use an mKEM.

2We note that very similar variants of mKEM have been considered prior to this work [BBM00,BPS00,Kur02,BBS03]. More
details follow.

2



Therefore, the second question we are interested in this work is:

(Practical Question) What is the concrete gain of using an mKEM compared to the trivial solu-
tion? What are the concrete applications of mKEMs?

1.1 Our Contributions and Techniques

Theoretical Contribution. We provide a new simple and efficient generic construction of an IND-CCA secure
multi-recipient KEM (mKEM) from any IND-CPA secure multi-recipient PKE (mPKE).3 The construction is
proven secure in the classical and quantum random oracle model ((Q)ROM). Here, mPKE is a variant of
mKEM where a user can encrypt any same message M (rather than a random session key K) to multiple
recipients. We then show that IND-CPA secure mPKEs can be constructed very easily from most assumptions
known to imply standard PKEs (including classical Diffie-Hellman type assumptions). The construction of
an IND-CPA secure mPKE is in most cases a simple modification of a standard IND-CPA secure PKE to
the multi-recipient setting. Concretely, we show how to construct mPKEs based on lattices and isogenies.
Compared to previous works [BF07, HTAS09, MH13] which provide some types of generic constructions of
mKEM, ours require an mPKE whereas they only require a single-recipient PKE. However, we only require
very natural properties from the underlying mPKE, such as IND-CPA. Considering that our mPKE can be
instantiated with diverse assumptions (including but not limited to post-quantum assumptions) in a very
natural way from standard PKEs, we believe our generic construction to be more versatile and handy than
previous ones.

Moreover, we introduce a new notion of recipient anonymity which we believe to be of independent
interest. The notion captures the fact that the ciphertext does not leak the set of intended group members
or recipients. We provide a mild additional property for the underlying IND-CPA secure mPKE, under which
our above generic construction naturally implies a recipient-anonymous IND-CCA secure mKEM. Our lattice
and isogeny-based instantiations satisfy the extra property without any modification. An overview of our
generic construction is provided in the following section.

Practical Contribution. An immediate consequence of our theoretical contribution is that it opens the door
to a large number of post-quantum instantiations of mKEM. A natural next step is to study these mKEM
instantiations at a practical level and compare them to the trivial solution of running standard KEMs in
parallel. Doing this work is precisely one of our practical contributions. As it turns out, at least 9 post-
quantum schemes are compatible with our construction of mKEM: 7 lattice-based NIST candidates, the
only isogeny-based NIST candidate SIKE, and the CSIDH scheme. We performed a systematic study of
the bandwidth efficiency and found that for all of these schemes, our mKEM variants are more compact
than the trivial solution with the original schemes by at least one order of magnitude (for a clearly defined
metric). In addition, for a subset of these 9 schemes (CSIDH, FrodoKEM, Kyber, SIKE), we implemented
their mKEM counterparts and compared their performance (cycle count). We found our mKEM variants to
be (asymptotically) faster than the trivial solution with original schemes by factors ranging from 1.92 to
more than 35.

Additionally, we show that we can use the mKEM primitive for the TreeKEM protocol obtaining significant
bandwidth savings. To give some context, the importance of TreeKEM could be best understood by looking at
its parent protocol, MLS [OBR+20,BBM+20], an IETF draft for secure (group) messaging. MLS has gained
considerable industrial traction and has attracted a fair amount of academic scrutiny. TreeKEM constitutes
the cryptographic backbone of MLS, as well as its main bottleneck in bandwidth and computational efficiency.
Indeed, given N users, it requires each of them to compute and send O(logN) ciphertexts at regular intervals.
We highlight a simple but powerful interplay between TreeKEM and mKEM, and show that by applying our
technique we can reduce communication cost by a factor between 1.8 and 4.2 compared to using standard
KEMs.

3As standard in practice, we consider indistinguishability under chosen ciphertext attacks (IND-CCA) to be the default
security requirement on our resulting scheme.

3



1.1.1 Our Techniques: Generic Construction of IND-CCA secure mKEM.

On a high level, our generic construction can be seen as a generalization of the Fujisaki-Okamoto (FO)
transform [FO99]. The FO transform (roughly) converts any IND-CPA secure PKE into an IND-CCA secure
KEM. There are several variants of the FO transform and most of the variants are secure in the ROM
[OP01,CHJ+02,Den03,HHK17] and/or QROM [TU16,HHK17,SXY18,JZC+18,JZM19b,JZM19a,BHH+19,
Zha19,KSS+]. The high-level construction is as follows: to encrypt, we sample a random message M←M
and derive randomness for the underlying encryption algorithm of the PKE by hashing M with a hash function
G modeled as a (Q)RO. That is, ct ← PKE.Enc(pk,M;G(M)). The session key is then set as K := H(M),
where H is another hash function modeled as a (Q)RO. To decrypt, we first decrypt M′ ← PKE.Dec(sk, ct)
and then only accept K = H(M′) if M′ re-encrypts back to ct, that is, we check ct = PKE.Enc(pk,M′;G(M′)).
Although the actual proof is rather complicated, intuitively, it achieves IND-CCA security since the adversary
must have queried message M to G to have constructed a valid ciphertext ct for message M. Therefore, in
the ROM, to answer a decapsulation-oracle query, the simulator runs through all the messages that have
been queried to G to check if any of them re-encrypts to ct. Since the simulator no longer requires sk to
simulate the decapsulation oracle, we can invoke the IND-CPA security of the underlying PKE.

Our idea is to generalize the FO transform to the mPKE/mKEM setting. At first glance, this may seem
to not work. Indeed, an mPKE typically comes with a multi -encryption algorithm with the following syntax:
mEnc(pp, (pki)i∈[N ],M; r) → ~ct, where ~ct is targeted to the set of N recipients with public keys (pki)i∈[N ].

There is also an extraction algorithm mExt which takes as input an index i ∈ [N ] and ~ct, and outputs the
ciphertext component cti targeted to the i-th recipient, say Ri, holding pki. Recipient Ri can then run the
decryption algorithm on cti using its secret key ski. The reason why the FO transform cannot be directly
applied to mPKE becomes clear. Assume r = G(M) and that recipient Ri decrypted to M. Then, to check
validity of cti, Ri must re-encrypt the entire ciphertext ~ct by running mEnc(pp, (pki)i∈[N ],M; r). Therefore,
the decapsulation time will depend on N , which is highly undesirable.

To get around this issue, in this work we consider a slight variant of mPKE with a decomposable flavor. In-
formally, a decomposable multi-encryption algorithm mEnc takes randomness of the form r = (r0, r1, ¡ ¡ ¡ , rN )
as input, and creates a public-key-independent ciphertext ct0 ← mEnci(r0) and public-key-dependent cipher-
texts ĉti ← mEncd(pki,M; r0, ri). The resulting ciphertext for recipient Ri is then cti = (ct0, ĉti). We view
this as a natural formalization of mPKE as it is satisfied by all the mPKE constructions that we are aware
of. Moreover, this feature is desirable in practice as it allows to parallelize part of the encryption algorithm.
Now, to perform the FO transform, we derive r0 = G(M) and ri = G(pki,M). It is evident that Ri can
re-encrypt and check the validity of its ciphertext. Notably, the decapsulation time is now independent of
N . With this new formalization, the proof in the (classical) ROM follows in a straightforward manner (with
minor modification) from the standard FO transform [HHK17].

The security proof of our mKEM in the quantum ROM (QROM) requires slight more work. Prior proof
strategies in the QROM for standard IND-CCA secure KEMs based on the FO transform – which fix the
description of the QROM at the outset of the game [TU16, HHK17, SXY18, JZC+18, JZM19b, JZM19a,
BHH+19] – seem to be an ill fit for mPKE. This is because in the multi-recipient setting, the decapsulation
oracle is required to output an identical session key K when the ciphertext is valid, while it is required to
output different rejection values for each users when the ciphertext is invalid. Due to this discrepancy between
valid and invalid ciphertexts (i.e., the former requires to output an identical random value, whereas the latter
requires to output different random values), previous proof techniques that always output random values
fail. Note that in the single-user setting, regardless of the ciphertext being valid or invalid, the decapsulation
oracle could always output random values without being detected by the adversary, and hence, this obstacle
was absent. To overcome this, we use the recently introduced compressed oracles technique [Zha19]. This
allows the simulator to perform lazy sampling and to check the validity of the ciphertext submitted to the
decapsulation oracle without interfering with the adversary’s state. Although the high-level structure of the
proof is similar to the classical case, much subtle care is required in the QROM case as the simulator must
not disturb the adversary’s state. We note that Zhandry [Zha19] showed security of one variant of the FO
transform which converts a perfectly correct IND-CPA secure PKE to an IND-CCA secure PKE.

4



2 Preliminaries

2.1 Hard Problems for Lattices

For any natural number d and q, let Rq denote the ring Z[X]/(q,Xd + 1). The learning with errors (LWE)
problem is defined below.

Definition 2.1 (Learning with Errors (LWE)). Let d, q, n1, n2, n3 be natural numbers, and Ds and De be
distributions over Rq. We say that the advantage of algorithm A in solving the (decisional) LWEn1,n2,n3

problem over the ring Rq is

AdvLWE
n1,n2,n3

(A) := | Pr[A← Rn1×n2
q ,S← Dn2×n3

s ,E← Dn1×n3
e : 1← A(A,AS + E)]

− Pr[A← Rn1×n2
q ,B← Rn1×n3

q : 1← A(A,B)]
∣∣ .

We say the LWEn1,n2,n3
problem is hard if, for any (possibly quantum) efficient adversary A, its advantage

is negligible.

Roughly, when d = 1 and n1 = n2 ≥ 1 (with an appropriate choice of distributions Ds, De), the above
corresponds to the standard LWE [Reg05], and when d ≥ 1 and n1 = n2 = 1, the above corresponds to the ring
LWE (Ring-LWE) problem [LPR10, LPR13]. We can parametrize d, n1, n2, n3 to achieve a tradeoff between
space and security, where the general case can be casted as the module LWE (Module-LWE) problem [LS15].
In practice, distributions Ds and De are chosen for instance from the discrete Gaussian distribution or from
the uniform distribution (with possibly a fixed weight) over some small interval.

We also consider a variant of the LWE problem, called learning with rounding (LWR) problem [BPR12],
where the least significant bits are removed. The benefit of this variant is that we no longer require to
sample the noise, as it is removed. Below the function b·ep : Zq → Zp, where q > p ≥ 2, is defined as
bxep = b(p/q) ¡ xe mod p. The definition of the LWR problem follows.

Definition 2.2 (Learning with Rounding (LWR)). Let d, p, q, n1, n2, n3 be natural numbers such that q > p,
and Ds a distributions over Rq. We say that the advantage of algorithm A in solving the (decisional)
LWRn1,n2,n3 problem over the rings Rp and Rq is

AdvLWR
n1,n2,n3

(A) := | Pr[A← Rn1×n2
q ,S← Dn2×n3

s : 1← A(A, bASep)]
− Pr[A← Rn1×n2

q ,B← Rn1×n3
p : 1← A(A,B)]

∣∣ .
We say the LWRn1,n2,n3

problem is hard if, for any (possibly quantum) efficient adversary A, its advantage
is negligible.

2.2 Hard Problems for Isogenies

In the following sections we propose two different isogeny-based schemes: one stemming from the SIDH
key exchange [DFJP14] and the other from the CSIDH key exchange [CLM+18]. Both key exchanges
share common mathematical tools, but several technical differences make them, and their descendants,
substantially different. As a consequence, schemes in the SIDH family rely on hardness assumptions different
from those used for schemes in the CSIDH family. Our schemes make no exception, as they use distinct
security assumptions.

SIDH-based assumption. Let p be an odd prime of the form 2e23e3 − 1, with e2, e3 ∈ N and 2e2 ≈ 3e3 .
For a supersingular elliptic curve E over Fp2 we will denote by B2 = {P2, Q2} and B3 = {P3, Q3} bases
for E[2e2 ] and E[3e3 ], respectively. Under the hypothesis that |E(Fp2)| = (2e23e3)2, both torsion subgroups
E[2e2 ] and E[3e3 ] are contained in E(Fp2). Given the curve E and s ∈ Z2e2 , by pk2(s) we denote the
tuple (E/ 〈R2 = P2 + [s]Q2〉 , φ〈R2〉(P3), φ〈R2〉(Q3)), where φ〈R2〉 is the isogeny from E having kernel 〈R2〉.
Analogously, for r ∈ Z3e3 we define pk3(r) as (E/ 〈R3 = P3 + [r]Q3〉 , φ〈R3〉(P2), φ〈R3〉(Q2)).

The security of our scheme relies on a decisional variant, named SSDDH [DFJP14], of the SSCDH as-
sumption. The latter is used by one of NIST second-round candidate KEMs, called SIKE [JAC+19], which
is deduced from the key exchange SIDH.

5



Definition 2.3 (Supersingular Decisional Diffie-Hellman (SSDDH)). Let E be a supersingular elliptic curve
over Fp2 such that |E(Fp2)| = (2e23e3)2. We say that the advantage of algorithm A in solving the SSDDHp,E,B2,B3

problem is

AdvSSDDH
p,E,B2,B3

(A) := | Pr[s← Z2e2 , r ← Z3e3 :

1← A(pk2(s), pk3(r), E/ 〈P2 + [s]Q2, P3 + [r]Q3〉)]
− Pr[(s, s′)← (Z2e2 )2, (r, r′)← (Z3e3 )2 :

1← A(pk2(s), pk3(r), E/ 〈P2 + [s′]Q2, P3 + [r′]Q3〉)]| .

We say the SSDDHp,E,B2,B3 problem is hard if, for any (possibly quantum) efficient adversary A, its advan-
tage is negligible.

CSIDH-based assumption. Let p be an odd prime of the form 4`1`2 · · · `t−1, where `1, . . . , `t are small odd
primes. E``p(O, π) is the set containing all supersingular elliptic curves E over Fp - modulo isomorphisms
over Fp - such that there exists an isomorphism between the order O ⊆ Q(

√
−p) and Endp(E) mapping√

−p ∈ O into the Frobenius endomorphism (x, y) 7→ (xp, yp). We note that |E``p(O, π)| ≈ √p. We consider
O equal to Z[

√
−p] = {m+n

√
−p | m,n ∈ Z} in which case, provided that p ≡ 3 (mod 8), each isomorphism

class in E``p(O, π) can be uniquely represented by a single element of Fp [CLM+18]. The ideal class group
C`(O) acts freely and transitively on E``p(O, π) via the group action ?. A special integral ideal I`i ⊂ O
corresponds to each prime `i. These ideals allow an easy computation of the group action. In particular,
the action of I`i on a curve E ∈ E``p(O, π) is determined by an isogeny having as kernel the unique rational
`i-torsion subgroup of E.

In the following we restrict our attention to the case where C`(O) is cyclic and generated by g ∈ {[I`i ]|i =
1, . . . , t}. The security of the CSIDH-based scheme we introduce in Section 5.2 relies on the decisional variant,
recently exploited in [EKP20,CS20], of the best-known GAIP assumption [CLM+18].

Definition 2.4 (Decisional CSIDH (dCSIDH)). Let p be a prime of the form 4`1`2 · · · `t−1 and g a generator
of the ideal class group C`(O) having order N , where O = Z[

√
−p]. We say that the advantage of algorithm

A in solving the dCSIDHp,g
4 problem is

AdvdCSIDH
p,g (A) := | Pr[E ← E``p(O, π), (a, b)← (ZN )2 :

1← A(E, ga ? E, gb ? E, ga ? (gb ? E))]

− Pr[E ← E``p(O, π), (a, b, c)← (ZN )3 :

1← A(E, ga ? E, gb ? E, gc ? E, )]
∣∣ .

We say the dCSIDHp,g problem is hard if for any (possibly quantum) efficient adversary A, its advantage is
negligible.

Three sets of CSIDH parameters have been proposed so far, namely CSIDH-512, CSIDH-1024 and CSIDH-
1792. Only for CSIDH-512 the structure of the group G is know, and it adheres to the assumption made
above, i.e. G cyclic and generated by g ∈ {[I`i ]|i = 1, . . . , t}. For the other two sets of parameters, efficiency
reasons dictate to restrict to elements of G of the form Iei`i ¡ ¡ ¡ I

et
`t

, with the integers ei satisfying the bound
|ei| ≤ B, where B is a suitable (small) natural number. Sampling uniformly from the set {Iei`i · · · I

et
`t
| |ei| ≤ B}

determines a distribution DB over G and, fixing E0 ∈ E``p(O, π), a distribution DE0
over E``p(O, π) itself.

The distribution DB is heuristically assumed to be close to the uniform distribution over G. The dCSIDH
(and the GAIP) problem is (are) believed to be hard also in this more general case. However, its formulation
requires to be slightly modified. Indeed, fixed a curve E0 in E``p(O, π), the curve E is sampled from DE0 ,
while elements sampled from DB replace the powers of g.

4We intentionally put d in dCSIDH so as not to confuse the CSIDH key exchange protocol [CLM+18] with the assumption.

6



2.3 Randomness Extraction

The min-entropy of a random variable X is defined as H∞(X) = − log2(maxx Pr[X = x]). We recall the
definition of family of universal hash functions.

Definition 2.5 (Universal Hash Functions). A family of functions H = {Hk : X → D}k∈K is called a family
of universal hash functions, if for all x, x′ ∈ X with x 6= x′, we have PrH←H[H(x) = H(x′)] ≤ 1

|D| .

It is well known that one can extract uniform random bits from a high min-entropy source using universal
hash functions [HILL99].

Lemma 2.6 (Leftover Hash Lemma). Let H = {Hk : X → D}k∈K be a family of universal hash functions.
Let H be sampled uniformly from H, X be a random variable independent of H and with values in X , and
U(D) be the uniform distribution over D. Then, the following holds

∆
(
(H,H(X)), (H, U(D))

)
≤ 1

2
¡
√

2−H∞(X) · |D|.

3 Multi-Recipient PKE and KEM

3.1 Decomposable Multi-Recipient Public Key Encryption

Definition 3.1 (Decomposable Multi-Recipient Public Key Encryption). A (single-message) decomposable
multi-recipient public key encryption (mPKE) over a message space M and ciphertext spaces C and Csingle
consists of the following five algorithms mPKE = (mSetup,mGen,mEnc,mExt,mDec) :

• mSetup(1κ)→ pp : The setup algorithm on input the security parameter 1κ outputs a public parameter
pp.

• mGen(pp) → (pk, sk) : The key generation algorithm on input a public parameter pp outputs a pair of
public key and secret key (pk, sk).

• mEnc(pp, (pki)i∈[N ],M; r0, r1, · · · , rN ) → ~ct = (ct0, (ĉti)i∈[N ]) : The (decomposable) encryption algo-

rithm running with randomness (r0, r1, ¡ ¡ ¡ , rN ), splits into a pair of algorithms (mEnci,mEncd) :

– mEnci(pp; r0)→ ct0 : On input a public parameter pp and randomness r0, it outputs a (public key
Independent) ciphertext ct0.

– mEncd(pp, pki,M; r0, ri) → ĉti : On input a public parameter pp, a public key pki, a message
M ∈M, and randomness (r0, ri), it outputs a (public key Dependent) ciphertext ĉti.

• mExt(i, ~ct) → cti = (ct0, ĉti) or ⊥ : The deterministic extraction algorithm on input an index i ∈ N
and a (multi-recipient) ciphertext ~ct ∈ C, outputs either a (single-recipient) ciphertext cti = (ct0, ĉti) ∈
Csingle or a special symbol ⊥Ext indicating extraction failure.

• mDec(sk, cti) → M or ⊥ : The deterministic decryption algorithm on input a secret key sk and a
ciphertext cti ∈ Csingle, outputs either M ∈M or a special symbol ⊥ 6∈ M.

Although we can consider non-decomposable multi-recipient PKEs, we only focus on decomposable
schemes as they are compatible with the Fujisaki-Okamoto (FO) transform [FO99]. Informally, the FO
transform relies on the recipient being able to recover the encryption randomness from the ciphertext and
to check validity of the ciphertext by re-encrypting with the recovered randomness. Therefore, in the multi-
recipient setting, if we do not impose decomposable encryption, then the recipient may require all the public
keys that were used in constructing ~ct to be able to re-encrypt. However, this is clearly undesirable since
the decryption time may now depend on the number of public keys used to encrypt, and furthermore, the
size of the ciphertext will grow by appending all the public keys used. Therefore, in this paper, when we say
mPKE, we always assume it is decomposable. We require the following properties from a mPKE.

7



Definition 3.2 (Correctness). A mPKE is δ-correct if

δ ≥ E
[

max
M∈M

Pr

[
ct0 ← mEnci(pp), ĉt← mEncd(pp, pk,M) :

M 6= mDec(sk, (ct0, ĉt))

]]
, (1)

where the expectation is taken over pp← mSetup(1κ) and (pk, sk)← mGen(pp).5

We also define the notion of well-spreadness [FO99] which states informally that the ciphertext has high
min-entropy.

Definition 3.3 (Îł-Spreadness). Let mPKE be a decomposable multi-recipient PKE with message space M
and ciphertext spaces C and Csingle. For all pp ∈ Setup(1κ), and (pk, sk) ∈ Gen(pp), define

γ(pp, pk) := − log2

(
max

ct∈Csingle,M∈M
Pr
r0,r

[
ct =

(
mEnci(pp; r0),mEncd(pp, pk,M; r0, r)

)])
.

We call mPKE γ-spread if E[γ(pp, pk)] ≥ γ, where the expectation is taken over pp ← mSetup(1κ) and
(pk, sk)← mGen(pp).

Finally, we define the notion of indistinguishability of chosen plaintext attacks (IND-CPA) for mPKE.

Definition 3.4 (IND-CPA). Let mPKE be a decomposable multi-recipient PKE with message space M and
ciphertext space C. We define IND-CPA by a game illustrated in Figure 1 and say the (possibly quantum)
adversary A = (A1,A2) wins if the game outputs 1. We define the advantage of A against IND-CPA security
of mPKE parameterized by N ∈ N as

AdvIND-CPA
mPKE,N (A) = |Pr[A wins]− 1/2| .

Remark 3.5 (Insider corruption). We point out that insider corruptions for mPKE are not considered [Sma05,
BF07]. This is because if an adversary obtains a secret key corresponding to any of the public keys used to
encrypt, then it can trivially recover the encrypted message.

Remark 3.6 (Inefficient mPKE from any standard (single-recipient) PKE). Our definition of mPKE captures
the trivial solution of sending different ciphertexts obtained with a standard single-recipient PKE to multiple
recipients. That is, independently encrypting the same message to all recipients using their respective
public keys. In the above syntax of mPKE, this amounts to setting mEnci as a null function and setting
r0 as an empty string. Also, mExt will simply pick the relevant ciphertext component for the particular
recipient. Therefore, in the context of ciphertext compression, the goal is to obtain a mPKE with better
efficiency/ciphertext-size compared to this trivial method.

Remark 3.7 (Number of recipients). In general, the number of recipients N = poly(Îş) can be chosen arbitrary
by the sender (or adversary). Some schemes may require an upper bound on N since the concrete provably-
secure parameters may have a dependance on N , e.g., the reduction loss degrades by a factor of 1/N . Our
proposal does not require such an upper bound since N only shows up in a statistical manner, and so we
can handle large N , say N = 215, without having any large impact on the concrete parameter choice.

3.2 Multi-Recipient Key Encapsulation Mechanism

Definition 3.8 (Multi-Recipient Key Encapsulation Mechanism). A (single-message) multi-recipient key
encapsulation mechanism (mKEM) over a key space K and ciphertext space C consists of the following five
algorithms mKEM = (mSetup,mGen,mEncaps,mExt,mDecaps) :

• mSetup(1κ) → pp : The setup algorithm on input the security parameter 1κ outputs a public parame-
ter pp.

5We could have defined correctness with respect to N -recipients as we do for mKEM (see Definition 3.9), however, we use
this single recipient definition since it is more easier to handle during in the security proof.

8



GAME IND-CPA

1: pp← mSetup(1κ)
2: for i ∈ [N ] do
3: (pki, ski)← mGen(pp)

4: (M∗0,M
∗
1, state)← A1(pp, (pki)i∈[N ])

5: b← {0, 1}
6: ~ct

∗ ← mEnc(pp, (pki)i∈[N ],M
∗
b)

7: b′ ← A2(pp, (pki)i∈[N ], ~ct
∗
, state)

8: return [b = b′]

GAME IND-CCA

1: pp← mSetup(1κ)
2: for i ∈ [N ] do
3: (pki, ski)← mGen(pp)

4: (K∗0, ~ct
∗
)← mEncaps(pp, (pki)i∈[N ])

5: K∗1 ← K
6: b← {0, 1}
7: b′ ← AD(pp, (pki)i∈[N ], ~ct

∗
,K∗b)

8: return [b = b′]

Decapsulation Oracle D(i, ct)

1: ct∗i := mExt(i, ~ct
∗
)

2: if ct = ct∗i then
3: return ⊥
4: K := mDecaps(ski, ct)
5: return K

Figure 1: IND-CPA of mPKE and IND-CCA of mKEM.

• mGen(pp) → (pk, sk) : The key generation algorithm on input a public parameter pp outputs a pair of
public key and secret key (pk, sk).

• mEncaps(pp, (pki)i∈[N ]) → (K, ~ct) : The encapsulation algorithm on input a public parameter pp, and

Npublic keys (pki)i∈[N ], outputs a key K and a ciphertext ~ct.

• mExt(i, ~ct)→ cti : The deterministic extraction algorit";"""date"",""2020-12-02T00:37:49Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2020-12-02T00:37:49Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.19 (TeX Live 2018) kpathsea version 6.3.0""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2020-12-02T00:37:49Z""
""created"",""2020-12-02T00:37:49Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-12-02T00:37:49Z""
""resourceName"",""1107.pdf""
""Author"",""""
""producer"",""pdfTeX-1.40.19""
""pdf:docinfo:producer"",""pdfTeX-1.40.19""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""11"",""28"",""60"",""17"",""13"",""18"",""14"",""25"",""40"",""26"",""39"",""3"",""26"",""18"",""45"",""31"",""26"",""9"",""4"",""1"",""2"",""7"",""15"",""15"",""0"",""0"",""0"",""0"",""0"",""31"",""28"",""20"",""34"",""87"",""49"",""20"",""2"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2020-12-02T00:37:49Z""
""Last-Modified"",""2020-12-02T00:37:49Z""
""dcterms:modified"",""2020-12-02T00:37:49Z""
""title"",""""
""Last-Save-Date"",""2020-12-02T00:37:49Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2020-12-02T00:37:49Z""
""meta:save-date"",""2020-12-02T00:37:49Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.19 (TeX Live 2018) kpathsea version 6.3.0""
""Content-Length"",""714201""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""42""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""2479"",""4114"",""3649"",""4268"",""2894"",""2859"",""2760"",""2792"",""2034"",""2250"",""2332"",""3441"",""2437"",""2323"",""3285"",""2153"",""3245"",""2000"",""2899"",""2316"",""2614"",""3477"",""1234"",""2286"",""3255"",""2367"",""2516"",""535"",""3024"",""2943"",""2808"",""2782"",""3359"",""3816"",""3213"",""2638"",""2987"",""3155"",""3233"",""2375"",""718"",""1697""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-12-02T00:37:49Z""
";https://scholar.google.ch/scholar?start=770&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098738-47;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;[PDF][PDF] Transactional Scripts in Contract Stacks;DA Cohney Hoffman ;2020 scholarship.law.umn.edu;;"… 351 C. Oracles ..... 354 III … three quarters of 2018, blockchain and crypto companies have raised

nearly 3.9Bn through traditional VC—280% more [than] last year . . . .” Page 8 …";;null;[PDF] umn.edu;https://scholarship.law.umn.edu/cgi/viewcontent.cgi?article=4274&context=mlr;"
University of Minnesota Law School University of Minnesota Law School 

Scholarship Repository Scholarship Repository 

Minnesota Law Review 

2020 

Transactional Scripts in Contract Stacks Transactional Scripts in Contract Stacks 

Shaanan Cohney Hoffman, David A. 

Follow this and additional works at: https://scholarship.law.umn.edu/mlr 

 Part of the Law Commons 

Recommended Citation Recommended Citation 
Cohney, Shaanan Hoffman, David A., ""Transactional Scripts in Contract Stacks"" (2020). Minnesota Law 
Review. 3226. 
https://scholarship.law.umn.edu/mlr/3226 

This Article is brought to you for free and open access by the University of Minnesota Law School. It has been 
accepted for inclusion in Minnesota Law Review collection by an authorized administrator of the Scholarship 
Repository. For more information, please contact lenzx009@umn.edu. 

https://scholarship.law.umn.edu/
https://scholarship.law.umn.edu/mlr
https://scholarship.law.umn.edu/mlr?utm_source=scholarship.law.umn.edu%2Fmlr%2F3226&utm_medium=PDF&utm_campaign=PDFCoverPages
http://network.bepress.com/hgg/discipline/578?utm_source=scholarship.law.umn.edu%2Fmlr%2F3226&utm_medium=PDF&utm_campaign=PDFCoverPages
https://scholarship.law.umn.edu/mlr/3226?utm_source=scholarship.law.umn.edu%2Fmlr%2F3226&utm_medium=PDF&utm_campaign=PDFCoverPages
mailto:lenzx009@umn.edu


 

	

319	

Article	

Transactional	Scripts	in	Contract	Stacks	

Shaanan	Cohney†	and	David	A.	Hoffman††	

Introduction		............................................................................................................	320 
I.		Designing	Expensive,	Buggy	Scripts		........................................................	328 

A. How	(Commercial)	Coding	Works		...............................................	328 
B. An	Introduction	to	the	Blockchain	Platform		............................	331 
C. Ethereum	and	Scripting		....................................................................	335 
D. Coding	on	Ethereum		...........................................................................	341 
E. Summary		.................................................................................................	346 

II.		Transactional	Scripts	in	the	Real	World		..............................................	348 
A. Tokens		......................................................................................................	348 
B. Exchanges		...............................................................................................	351 
C. Oracles		......................................................................................................	354 

III.		Scripts	and	Stacks		.........................................................................................	358 
A. The	Canonical	Stack		............................................................................	362 
B. Tensions	Within	the	Stack		...............................................................	368 
C. Recapitulating	the	Canons:	Quoine	and	Non-Public		

Scripts		.......................................................................................................	385 
IV.		The	Future	of	the	Contract	Stack		...........................................................	386 

 

†	 	 Ph.D.,	 Postdoctoral	 Research	Associate,	 Center	 for	 Information	Technology	
Policy,	Princeton	University.	Copyright	Š	2020	by	Shaanan	Cohney.	

††	 	Professor	of	Law,	University	of	Pennsylvania	Law	School.	We	thank	Alexander	
Altieri	 and	Chrissy	Pak	 for	 research	assistance,	 and	Yonathan	Arbel,	Bridget	Fahey,	
James	 Grimmelmann,	 Greg	 Klass,	 Raina	 Haque,	 Bob	 Hillman,	 Drew	 Hinkes,	 Cathy	
Hwang,	Gabe	Kaptchuk,	Max	Raskin,	Elizabeth	Pollman,	Gabe	Shapiro,	Jeremy	Sklaroff,	
Tim	Swanson,	Andrea	Tosato,	Alec	Webley,	Kevin	Werbach,	Tal	Zarsky,	Eyal	Zamir,	and	
participants	at	workshops	at	Alabama,	Penn,	and	Utah	for	comments.	This	work	was	
supported	in	part	by	grants	from	the	Ripple	Research	Fund	at	the	Wharton	School	and	
at	the	Princeton	Center	for	IT	Policy.	Copyright	Š	2020	by	David	A.	Hoffman.	



 

320	 MINNESOTA	LAW	REVIEW	 [105:319	

	

		INTRODUCTION			
In	early	2019,	a	group	of	people	founded	Edgeware,	a	blockchain-

based	 platform	designed	 to	 host	 software	 development.1	Edgeware	
made	potential	users	a	deal:	if	they	agreed	to	temporarily	sequester	
some	cryptocurrency	(essentially,	placing	an	initial	investment	in	es-
crow),	they’d	gain	governance	rights	over	the	platform	at	a	later	date.2	
The	mechanism	for	that	investment	was	a	piece	of	carefully-audited	
software,	 called	 “Lockdrop,”	which	was	 deployed	 on	 a	 blockchain.3	
Lockdrop	seemed	to	embody	and	constitute	a	novel	contracting	tech-
nology,	written	in	a	programming	language	(Solidity)	that	didn’t	even	
exist	a	decade	ago.4	

By	July	of	2019,	investors	committed	nearly	$300,000,000	to	the	
project	using	Lockdrop.5	Then	someone	looked	with	particular	care	at	
the	following	piece	of	code:6		

	
assert(address(lockAddr).balance	==	msg.value);	
	
As	it	turns	out,	this	line	was	susceptible	to	a	software	hack	that	

would	have	permanently	impounded	investor	assets.7	Luckily,	the	er-
ror	was	discovered	before	it	caused	harm.	But,	as	the	coder	who	dis-
covered	the	vulnerability	put	it,	“smart	contracts	are	software.	Even	
carefully	audited,	well	 tested	 software	will	 (almost	always)	 contain	
bugs.	Therefore,	and	despite	our	best	efforts	.	.	.	Smart	contracts	will	

 

	 1.	 COMMONWEALTH	LABS,	EDGEWARE:	AN	ADAPTIVE	SMART-CONTRACT	BLOCKCHAIN	1	
(2019)	[hereinafter	EDGEWARE	WHITEPAPER],	https://arena-attachments.s3	
.amazonaws.com/3850782/1928e31873075de95992d4987eb14a2e.pdf?15524	
32633	[https://perma.cc/J3GP-ERC4].	
	 2.	 See	id.	at	5	(“EDG	entitles	holders	both	staking	and	voting	rights	.	.	.	.”).	For	an	
introduction	to	cryptocurrencies,	see	Shaanan	Cohney,	David	Hoffman,	Jeremy	Sklaroff	
&	David	Wishnick,	Coin-Operated	Capitalism,	119	COLUM.	L.	REV.	591,	603–05	(2019).	
See	also	DAVID	FOX	&	SARAH	GREEN,	CRYPTOCURRENCIES	IN	PUBLIC	AND	PRIVATE	LAW	(2019).	
	 3.	 Certificate	 of	 Smart	 Contract	Audit	 for	 Edge-Lockdrop,	QUANTSTAMP	 (Apr.	 8,	
2019),	 https://arena-attachments.s3.amazonaws.com/4282493/a155dc84aa1dfba4	
cfd3dc6be1e1ebdc.pdf?1557965252	[https://perma.cc/UPC5-ZUPT].	
	 4.	 Id.	(noting	that	Lockdrop	used	Solidity	programming	language).	
	 5.	 Neil	McLaren,	Gridlock	(A	Smart	Contract	Bug),	MEDIUM	(July	1,	2019),	https://	
medium.com/@nmcl/gridlock-a-smart-contract-bug-73b8310608a9	 [https://perma	
.cc/V2G2-WT9L]	(“Edgeware’s	Lockdrop	smart	contract	has	processed	over	$900	mil-
lion	of	ETH	and	locked	up	over	$290	million.”).	
	 6.	 Id.	
	 7.	 If	the	attacker	designated	cryptocurrency	to	the	next	lock	address,	the	total	
balance	would	exceed	 the	amount	 sent	by	Lockdrop,	 causing	 the	 check	 to	 fail.	This	
would	freeze	the	sequestering	process	permanently	in	place.	



 

2020]	 TRANSACTIONAL	SCRIPTS	 321	

	

(almost	always)	contain	bugs!”8	The	question	we	ask	in	this	paper	is	
simple:	can	contract	 law	make	sense	of	 intractable	bugs	 in	 transac-
tional	code?	The	answer	is	likewise	simple:	yes.	

But	to	their	promoters,	even	buggy	“smart	contracts”	like	Lock-
drop	are	the	vanguard	of	a	revolution,	heralding	an	age	in	which	code	
will	depose	both	contract	theory	and	practice.9	Enthusiasts	argue	that	
when	 contracts	 are	 embodied	 and	 performed	 by	 code,	 contracting	
costs	(like	negotiation,	monitoring,	and	performance)	will	fall.	Better	
still,	parties	won’t	need	to	trust	each	other,	or	courts,	to	be	assured	
that	they’ll	get	what	they	bargained	for.	The	result:	“smart	contracts”	
are	offered	as	a	potential	solution	to	an	astounding	variety	of	business	
and	social	problems.	They	may	transform	insurance,10	financial	deriv-
atives,11	consumer	protection,12	corporate	governance,13	tax	 filing,14	
voting, 15 	supply	 chain	 management, 16 	bankruptcy, 17 	property	

 

	 8.	 McLaren,	supra	note	5.	
	 9.	 Cf.	Primavera	De	Filippi	&	Samer	Hassan,	Blockchain	Technology	as	a	Regula-
tory	Technology:	From	Code	Is	Law	to	Law	Is	Code,	FIRST	MONDAY	(Dec.	5,	2016),	https://	
firstmonday.org/ojs/index.php/fm/article/view/7113/5657	[https://perma.cc/	
2PX9-8C4K]	 (“What	makes	 the	blockchain	different	 from	other	 technologies	 is	 that	
smart	contracts	are	actually	meant	to	replace	legal	contracts.”);	Mark	Verstraete,	The	
Stakes	of	Smart	Contracts,	50	LOY.	U.	CHI.	L.J.	743,	743	(2019)	(“The	most	ardent	sup-
porters	of	smart	contracts	.	.	.	claim	that	smart	contracts	might	replace	large	swaths	of	
the	traditional	contract	system.”).	
	 10.	 Smart	Contracts:	10	Use	Cases	for	Business,	AMBISAFE,	https://ambisafe.com/	
blog/smart-contracts-10-use-cases-business	[https://perma.cc/S9WA-FHMM].	
	 11.	 See	generally	INT’L	SWAPS	&	DERIVATIVES	ASS’N,	LEGAL	GUIDELINES	FOR	SMART	DE-
RIVATIVES	 CONTRACTS:	 INTRODUCTION	 (2019),	 https://www.isda.org/a/MhgME/Legal-
Guidelines-for-Smart-Derivatives-Contracts-Introduction.pdf	[https://perma.cc/	
N5XN-J5KQ].	
	 12.	 See	 generally	 Joshua	 Fairfield,	Smart	 Contracts,	 Bitcoin	 Bots,	 and	 Consumer	
Protection,	71	WASH.	&	LEE	L.	REV.	ONLINE	35	(2014).	
	 13.	 Fiammetta	S.	Piazza,	Bitcoin	and	the	Blockchain	as	Possible	Corporate	Govern-
ance	Tools:	Strengths	and	Weaknesses,	5	PA.	ST.	J.L.	&	INT’L	AFFS.	262,	282–86	(2017).	
	 14.	 Valentine	P.	Vishnevsky	&	Viktoriia	D.	Chekina,	Robot	vs.	Tax	Inspector	or	How	
the	Fourth	Industrial	Revolution	Will	Change	the	Tax	System:	A	Review	of	Problems	and	
Solutions,	4	J.	TAX	REFORM	6,	20	(2018).	
	 15.	 See	Tsui	S.	Ng,	Blockchain	and	Beyond:	Smart	Contracts,	A.B.A.	BUS.	L.	TODAY	
(Sept.	28,	2017),	https://www.americanbar.org/groups/business_law/publications/	
blt/2017/09/09_ng	 [https://perma.cc/MD66-A7V4]	 (“Governments	may	 use	 smart	
contracts	to	manage	.	.	.	e-voting.”).	
	 16.	 See	generally	Horst	Treiblmaier,	The	Impact	of	the	Blockchain	on	the	Supply	
Chain:	 A	 Theory-Based	 Research	 Framework	 and	 a	 Call	 for	 Action,	 23	 SUPPLY	CHAIN	
MGMT.	INT’L	J.	545	(2018).	
	 17.	 See	generally	Alan	Rosenberg,	Automatic	Contracts	and	the	Automatic	Stay:	A	
Primer	on	“Smart	Contracts”	in	Bankruptcy,	38	AM.	BANKR.	INST.	J.	18	(2019).	



 

322	 MINNESOTA	LAW	REVIEW	 [105:319	

	

rights,18	and	repossession	through	the	internet	of	things.19	But	there’s	
more.	Jurisprudence—in	the	sense	of	the	fundamental	utility	of	con-
tract	doctrine—is	on	the	chopping	block.20	For	many,	smart	contracts	
are	the	first	transformative	legal	innovation	of	the	millennium.21	

Perhaps	 inevitably,	 “smart	 contracts,”	 a	 term	 that	 connotes	
money,	 computers,	 and	modernity,	 has	 invited	 a	 stampede	 of	 com-
mentators	to	speculate	about	a	wide	variety	of	possible	contracting	
technologies.22	Many	marvel	at	the	innovation	as	some	kind	of	utopian	
simulacra: 23 	an	 immutable, 24 	transparent	 exchange, 25 	occurring	

 

	 18.	 See,	e.g.,	Michael	Casey,	Could	Blockchain	Technology	Help	the	World’s	Poor?,	
WORLD	ECON.	F.	AGENDA	(Mar.	9,	2016),	https://www.weforum.org/agenda/2016/03/	
could-blockchain-technology-help-the-worlds-poor	[https://perma.cc/4U9N-4S2F].	
	 19.	 For	the	canonical	description,	see	Jeremy	M.	Sklaroff,	Comment,	Smart	Con-
tracts	and	the	Cost	of	Inflexibility,	166	U.	PA.	L.	REV.	263,	271–78	(2017).	
	 20.	 For	a	 lucid	review,	see	generally	Marco	Dell’Erba,	Demystifying	Technology:	
Do	Smart	Contracts	Require	a	New	Legal	Framework?	Regulatory	Fragmentation,	Self-
Regulation,	Public	Regulation,	U.	PA.	J.L.	&	PUB.	AFFS.	(forthcoming	2020),	https://pa-
pers.ssrn.com/sol3/papers.cfm?abstract_id=3228445	[https://perma.cc./48NP	
-CWX7].	
	 21.	 See,	e.g.,	Alexander	Savelyev,	Contract	Law	2.0:	“Smart”	Contracts	as	the	Begin-
ning	of	the	End	of	Classic	Contract	Law,	26	INFO.	&	COMMC’N	TECH.	L.	116	(2017);	see	also	
What	is	Ethereum?,	ETHERSCRIPTER,	https://etherscripter.com/what_is_ethereum.html	
[https://perma.cc/LV8P-6BJD]	 (describing	 popular	 smart	 contract	 Ethereum	 as	 “a	
new	kind	of	law”	that	can	be	“perfectly	observed	and	enforced”).	
	 22.	 The	fish	rots	from	the	head.	See	NICK	SZABO,	SMART	CONTRACTS:	BUILDING	BLOCKS	
FOR	 DIGITAL	 MARKETS	 1	 (1996),	 http://www.truevaluemetrics.org/DBpdfs/Block-
Chain/Nick-Szabo-Smart-Contracts-Building-Blocks-for-Digital-Markets-1996-14591	
.pdf	 [https://perma.cc/6BAR-V45A]	(defining	smart	contracts	as	“a	set	of	promises,	
specified	in	digital	form,	including	protocols	within	which	the	parties	perform	on	these	
promises”).	In	recent	years,	Szabo	has	vociferously	defended	the	term.	See,	e.g.,	Nick	
Szabo	 (@NickSzabo4),	 TWITTER	 (Oct.	 14,	 2018,	 6:38	 PM),	 https://twitter.com/	
NickSzabo4/status/1051603179526270976	[https://perma.cc/5HC7-D95Z]	(“‘Smart	
contract’	is	a	very	useful	concept	&	phrase.	‘Smart’	as	in	‘smart	phone’	(shorthand	for	
computerized	phone),	‘contract’	meaning	it	does	some	important	things	we	previously	
relied	on	contracts	to	do	for	our	deals,	especially	controlling	assets	&	incentivizing	per-
formance.”).	
	 23.	 Frank	Pasquale,	A	Rule	of	Persons,	Not	Machines:	The	Limits	of	Legal	Automa-
tion,	87	GEO.	WASH.	L.	REV.	1,	24–25	(2019).	
	 24.	 Jeffrey	M.	Lipshaw,	The	Persistence	of	“Dumb”	Contracts,	2	STAN.	J.	BLOCKCHAIN	
L.	&	POL’Y	1,	24	(2019)	(stating	that	the	key	characteristics	of	smart	contracts,	“in	ad-
dition	to	consensus,	include	immutability	and	finality	from	the	time	they	are	created	
and	going	forward”).	
	 25.	 Adam	J.	Kolber,	Not-So-Smart	Blockchain	Contracts	and	Artificial	Responsibil-
ity,	21	STAN.	TECH.	L.	REV.	198,	208	(2018)	(“Since	Ethereum	smart	contracts	consist	of	
particular	computer	code	on	a	decentralized	blockchain,	it	is	easy	to	verify	program	
execution.”).	



 

2020]	 TRANSACTIONAL	SCRIPTS	 323	

	

through	“consensus,”	that	is	“self-executing”26	or	“automated.”27	With	
that	capacious	definition	in	mind,	is	the	chip	in	your	Visa	Card	part	of	
a	smart	contract	network?	The	code	comprising	the	Venmo	App?	Your	
Metrocard?28	If	we	can’t	understand	 the	scope	of	 this	phenomenon,	
how	can	we	fairly	evaluate	the	risk	it	poses,	or	the	benefits	it	promises,	
to	our	commercial	and	social	life?	

Smart	contracts’	flabby	meaning	is	not	this	Article’s	precise	tar-
get.29	Rather	we	offer	a	focused	description	of	the	most	celebrated	as-
pect	of	the	underlying	technology	and	its	relationship	to	legal	order.	
We’ll	 start	by	 introducing	 a	new	 term	 that	we	 think	 captures	what	
most	people	in	this	field	think	of	when	they	consider	“smart	contracts”	
as	 they	are	currently	deployed.	We	name	and	describe	 the	 transac-
tional	 script.30	Here	 is	 a	 parsimonious	 definition	 (that	we’ll	 unpack	
later):31	

A	transactional	script	is	a	persistent	piece	of	software	residing	on	
a	public	blockchain.	When	executed	as	a	part	of	an	exchange,	the	code	
effectuates	a	consensus	change	to	the	state	of	a	ledger.	

 

	 26.	 Professors	Kevin	Werbach	and	Nicolas	Cornell	argue	that	smart	contracts	are	
distinctive	because	“juridical	forums	are	powerless	to	stop	the	execution	of	smart	con-
tracts—there	 is	no	 room	 to	bring	an	action	 for	breach	when	breach	 is	 impossible.”	
Kevin	Werbach	&	Nicolas	Cornell,	Contracts	Ex	Machina,	67	DUKE	L.J.	313,	332	(2017);	
see	also	Amy	 J.	 Schmitz	&	Colin	Rule,	Online	Dispute	Resolution	 for	 Smart	Contracts,	
2019	J.	DISP.	RESOL.	103,	106,	107,	113	(describing	smart	contracts	as	“self-enforcing,”	
“self-governing,”	and	with	“no	ambiguity	around	the	parties’	obligations”).	
	 27.	 Christopher	D.	 Clack,	Vikram	A.	 Bakshi	&	 Lee	Braine,	 Smart	 Contract	 Tem-
plates:	Foundations,	Design	Landscape	and	Research	Directions	2	(Mar.	15,	2017)	(un-
published	manuscript),	ARXIV:	1608.00771;	see	also	Max	Raskin,	The	Law	and	Legality	
of	Smart	Contracts,	1	GEO.	L.	TECH.	REV.	305,	309	(2017)	(“A	smart	contract	is	an	agree-
ment	whose	execution	is	automated.”).	
	 28.	 See	Kolber,	supra	note	25.	
	 29.	 Cf.	 Ed	 Felten,	 Smart	 Contracts:	 Neither	 Smart	 nor	 Contracts?,	 FREEDOM	 TO	
TINKER	(Feb.	20,	2017),	https://freedom-to-tinker.com/2017/02/20/smart-contracts	
-neither-smart-not-contracts	[https://perma.cc/NZ2Q-GFHE].	
	 30.	 For	a	definition	of	smart	contracts	that	tracks	with	our	transactional	script,	
see	 Carla	 L.	 Reyes,	 If	 Rockefeller	Were	 a	 Coder,	 87	 GEO.	WASH.	L.	REV.	 373,	 383–84	
(2019),	which	states	that:		

The	term	“smart	contract”	refers	to	decentralized	computer	code	that	runs	
on	a	DLT	protocol	and	manifests	some	combination	of	the	following	charac-
teristics:	exerts	some	control	over	assets	digitally	recorded	on	a	DLT	proto-
col,	takes	some	action	upon	receipt	of	specified	data,	is	often,	but	not	always,	
part	of	a	DLT-based	application,	guarantees	execution,	and	writes	the	result-
ing	 state	 change	 from	 the	 operation	 of	 the	 smart	 contract	 into	 the	 DLT’s	
ledger.	

	 31.	 Cf.	Peter	G.L.	Hunn,	Smart	Contracts	as	Techno-Legal	Regulation,	7	J.	ICT	STAND-
ARDIZATION	269,	275	(2019)	(focusing	on	“a	deterministic	state	machine”	and	a	“con-
sensus	protocol”	that	provides	agreement	“on	the	same	sequence	of	operations”).	



 

324	 MINNESOTA	LAW	REVIEW	 [105:319	

	

We	stress	that	our	focus—for	the	moment—is	narrower	than	all	
digitized	exchanges,32	or	even	all	deals	accomplished	through	block-
chain-style	ledgers.33	That	is,	transactional	scripts	sit	at	the	core	of	the	
rapidly	expanding	group	of	things	called	“smart	contracts,”	but	do	not	
encompass	 the	 whole	 field.	 Crucially,	 transactional	 scripts	 are	 ex-
changes	that	operate	in	public—indeed,	they	are	valuable	in	large	part	
because	their	resolution	must	be	agreed	to	by	multiple	different	enti-
ties,	jointly	operating	on	an	operating	system	with	fixed	and	translu-
cent	rules.	

Transactional	scripts	are	a	striking	legal	innovation	and	much	of	
the	current	interest	in	smart	contracts	in	fact	regards	them.34	But	law	
(and	lawyers’)	role	in	the	creation	and	execution	of	scripts	is	unclear.	
Even	 apart	 from	 the	 performative	 techno-libertarian	 claims	 about	
law’s	abnegation,	many	scripting	projects	are	missing	many	of	the	ac-
coutrements	 of	 transactional	 law.	 More	 plainly	 put,	 currently	 de-
ployed	transactional	scripts—those	that	are	exposing	real	people	to	
financial	and	personal	risks—often	rely	on	the	code	alone	as	their	pri-
mary	risk-allocation	mechanism.	And	the	code	errs.	

In	the	Edgeware	project,	none	of	the	governance	promises	were	
expressed	 in	 a	 natural	 language	 “contract”	 as	 we	 understand	 that	
term,	even	in	the	digital	sphere,	as	 in	a	click-wrap	agreement.	They	
existed	rather	in	a	“white	paper”—a	self-published	document	with	no	

 

	 32.	 For	a	tremendous	survey	of	digitized	exchanges,	see	Harry	Surden,	Computa-
ble	Contracts,	46	U.C.	DAVIS	L.	REV.	629	(2012).	Surden	discusses	“autonomous	comput-
able	contracting”	only	briefly.	Id.	at	694–95.	
	 33.	 The	 reader	 would	 benefit	 from	 reading	 the	 following	 excellent	 works	 on	
scripts	 (broadly	 defined):	 Sklaroff,	 supra	 note	 19;	 J.G.	 Allen,	Wrapped	 and	 Stacked:	
“Smart	Contracts”	and	the	 Interaction	of	Natural	and	Formal	Language,	14	EUR.	REV.	
CONT.	L.	307	(2018);	Werbach	&	Cornell,	supra	note	26;	Karen	E.C.	Levy,	Book-Smart,	
Not	Street-Smart:	Blockchain-Based	Smart	Contracts	and	the	Social	Workings	of	Law,	3	
ENGAGING	SCI.	TECH.	&	SOC’Y	1	(2017);	James	Grimmelmann,	All	Smart	Contracts	Are	Am-
biguous,	2	 J.L.	&	INNOVATION	1	 (2019);	PRIMAVERA	DE	FILIPPI	&	AARON	WRIGHT,	BLOCK-
CHAIN	AND	THE	LAW:	THE	RULE	OF	CODE	(2018);	Jonathan	Rohr,	Smart	Contracts	in	Tradi-
tional	Contract	Law,	or:	The	Law	of	the	Vending	Machine,	67	CLEV.	ST.	L.	REV.	67	(2019);	
Edmund	Schuster,	Cloud	Crypto	Land,	MOD.	L.	REV.	(forthcoming	2020)	(manuscript	at	
23–25),	https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3476678	[http://	
perma.cc/YAY3-TA63].	
	 34.	 See	Global	Smart	Contracts	Market,	MKT.	RSCH.	FUTURE,	https://www.market-
researchfuture.com/reports/smart-contracts-market-4588	[https://perma.cc/F3DN-
L98D]	(“The	global	smart	contracts	market	 is	expected	 to	reach	approximately	300	
USD	Million	by	the	end	of	2023	.	.	.	.”);	cf.	Venture	Capital	Firms	Go	Deep	and	Wide	with	
Blockchain	 Investments,	 DIAR	 (Oct.	 1,	 2018),	 https://diar.co/volume-2-issue-39	
[https://perma.cc/V6Q2-ZLVR]	(“[I]n	just	.	.	.	three	quarters	of	2018,	blockchain	and	
crypto	 companies	 have	 raised	 nearly	 3.9Bn	 through	 traditional	 VC—280%	 more	
[than]	last	year	.	.	.	.”).	



 

2020]	 TRANSACTIONAL	SCRIPTS	 325	

	

standard	form	and	untested	legal	effect.35	That	white	paper	states	that	
users	will	receive	“[d]ownside	protection”	in	the	case	of	a	“malicious	
attack	 or	 exploit,”	 and	describes	 the	 lockdrop	 contract	 as	 a	 failsafe	
technique.36	Moreover,	the	promoters	suggest	that	it	would	be	impos-
sible	 to	 falsely	 claim	 ownership	 for	 an	 address.37 	Needless	 to	 say,	
these	representations	do	not	match	the	reality	of	what	the	buggy	code	
delivered.	But,	equally	obviously,	since	the	code	was	public,	its	latent	
errors	 were	 also	 theoretically	 knowable,	 at	 least	 to	 sophisticated	
counterparties.	

Other	examples	of	coding	errors	and	oversights	abound—includ-
ing	the	now	infamous	DAO	hack,	which	we	will	discuss	later.38	In	many	
cases,	the	losers	of	coding	errors	have	paid	off	the	winners	to	undo	
transactions.39	Such	settlements	occur	in	the	very	indistinct	shadow	
of	law:	there	isn’t	a	body	of	cases	that	directly	address	the	question	of	
what	happens	when	transactional	scripts	go	wrong.40	The	academic	
literature	too	has	largely	downplayed	the	role	and	capabilities	of	law	
in	resolving	transactional	scripts	gone	wrong.41		

Even	the	most	sophisticated	treatments	in	the	literature	largely	
focus	 on	 what	 happens	 when	 scripts	 accomplish	 their	 promised	
aims.42	Some	argue	that	the	technology	is	simply	incapable	of	the	sorts	

 

	 35.	 EDGEWARE	WHITEPAPER,	supra	note	1,	at	9–15.	
	 36.	 Id.	at	6–7.	
	 37.	 Id.	at	11–12	(“Upon	inspection	[of	the	transaction	hash],	a	verifier	should	have	
enough	proof	that	if	the	owner	of	the	.	.	.	account	did	not	also	own	the	recipient	Edge-
ware	account	(represented	as	the	target	address	.	.	.	),	then	they	would	not	issue	such	
a	transaction.”).	
	 38.	 See	infra	text	accompanying	notes	276–79.	
	 39.	 The	 literature	has	noted	 that	often	 firms	price	bug	bounties	 too	 low	when	
compared	with	their	after-market	(and	illegitimate)	use.	Lorenz	Breidenbach,	Philip	
Daian,	Florian	Tramer	&	Ari	Juels,	Enter	the	Hydra:	Towards	Principled	Bug	Bounties	
and	Exploit-Resistant	Smart	Contracts,	27	PROC.	USENIX	SEC.	SYMP.	1335,	1335	(2018).	
It	 is	difficult	to	know	how	common	self-help	is	 in	the	world	of	transactional	scripts.	
Victims	have	little	incentive	to	publicize	their	failure	to	write	better	code,	while	suc-
cessful	attackers	may	wish	to	avoid	public	renown	(if	not	the	tax	authorities).	
	 40.	 See,	 e.g.,	 Lauren	Henry	Scholz,	Algorithmic	Contracts,	 20	STAN.	TECH.	L.	REV.	
128,	141	(2017)	(discussing	the	application	of	contract	and	agency	law	to	algorithmic	
contracts	and	noting	lack	of	caselaw).	
	 41.	 Cf.	Dell’Erba,	supra	note	20	(manuscript	at	21)	(“It	could	be	that	there	may	be	
a	bug	in	the	code	or	that	the	parties	may	reconsider	what	they	want.”).	
	 42.	 Compare	Werbach	&	Cornell,	 supra	note	26,	at	350–64	(things	going	well),	
with	id.	at	365–67	(not	as	well).	



 

326	 MINNESOTA	LAW	REVIEW	 [105:319	

	

of	error	that	law	cares	about:	the	“[c]ode	typically	entails	no	ambigu-
ity,	and	no	variant	interpretation	is	possible.”43	Others	lament	that	be-
cause	the	blockchain	code	is	self-contained,	it	contains	no	place	within	
it	for	“default	law”	to	exist.44	Worse,	even	if	there	are	places	for	law’s	
tools	to	have	purchase,	jurists	“may	not	be	able	to	hypothesize	a	rea-
sonable	human’s	interpretation	of	a	given	smart	contract.”45	

Such	handwaving	is	an	unwarranted,	and	ultimately	unworkable,	
surrender	of	the	law’s	role	in	adjudicating	disputes.	Code	that	embod-
ies	 commercially-significant	 scripts	will	 inevitably	 contain	ambigui-
ties,	and	disappointed	parties	will	ask	judges	to	adjudicate	their	rights.	
At	the	basic	level,	as	James	Grimmelmann	has	recently	observed,	the	
“meaning	of	any	specific	program	rests	on	a	foundation	of	some	prior	
agreement	about	how	to	interpret	some	larger	class	of	programs.”46	
He	concludes	that	while	there	may	be	fewer	superficial	examples	of	
interpretative	gaps	in	formal	code,	“when	the	bottom	drops	out,	it	can	
really	drop	out.”47	It’s	then	that	law	will	be	asked	to	step	in	and	pro-
vide	rational	and	predictable	solutions,	which	will	almost	certainly	be	
developed	by	analogy	to	off-chain	exchanges.	

But	analogies	can	deceive.	Whereas	scholars	and	jurists	who	con-
front	questions	about	ordinary	written	contracts	have	a	deep	working	
knowledge	of	how	such	exchanges	function,	transactional	scripts	are	
functionally	innovative	and	the	legal	community	has	yet	to	coalesce	
around	even	a	basic	understanding	of	what	they	are,	 let	alone	what	
they	do.	What’s	needed,	then,	is	a	working	knowledge	of	the	ways	in	
which	the	vocabulary	and	functioning	of	the	code	itself	can	create	dis-
connects	 between	 the	 intent	 of	 the	 humans	 coding	 transactional	
scripts	 and	 the	 code’s	 function.48	Describing	 the	 plumbing	 of	 these	
phenomena	is	the	first	contribution	of	this	Article,	and	occupies	Part	
I.	We	make	two	fundamental	observations.		

 

	 43.	 Wulf	A.	Kaal	&	Craig	Calcaterra,	Crypto	Transaction	Dispute	Resolution,	73	BUS.	
LAW.	109,	136	n.94	(2017–2018).	
	 44.	 Usha	R.	Rodrigues,	Law	and	the	Blockchain,	104	IOWA	L.	REV.	679,	682	(2019)	
(“Because	the	smart	‘contract’	is	code	alone,	there	is	no	gap,	in	the	sense	of	an	entry	
point,	for	the	law	to	step	in	to	fill.”).	
	 45.	 Kaal	&	Calcaterra,	supra	note	43,	at	136;	Schmitz	&	Rule,	supra	note	26,	at	103	
(“Those	with	 no	 coding	 background	 cannot	 easily	 interpret	 a	 smart	 contract	 in	 its	
rawest	form.”).	
	 46.	 Grimmelmann,	supra	note	33,	at	12.	
	 47.	 Id.	at	20	(“The	relevant	community	can	redefine	the	programming	language	
in	a	way	that	radically	alters	the	meaning	of	programs	written	in	it.”).	
	 48.	 On	the	problems	caused	by	blockchain	jargon,	see	Angela	Walch,	Blockchain’s	
Treacherous	Vocabulary:	One	More	Challenge	for	Regulators,	J.	INTERNET	L.,	Aug.	2017,	
at	1.	



 

2020]	 TRANSACTIONAL	SCRIPTS	 327	

	

First,	the	software	language	development	environment	of	almost	
all	extant	 transactional	scripts	has	 features	 (and	entails	uncommon	
practices)	which	make	coding	errors,	and	gaps	between	coders’	intent	
and	expression,	both	likely	to	occur	and	difficult	to	resolve.49	Second,	
the	 dominant	 platform	 for	 scripts—Ethereum—assesses	 a	 tax	 on	
complex	programs.	This	fee	makes	transactional	scripts	unsuited	for	
many	knotty	contracting	problems,	unless	their	drafters	make	parts	
of	the	code	non-public,	thus	stripping	scripts	of	much	of	what	makes	
them	an	elegant	solution	to	problems	of	trust	in	exchange.	

With	a	better	grasp	of	how	scripts	operate,	Part	II	uses	case	ex-
amples	 to	 argue—contrary	 to	 the	 dominant	 account—that	 these	
scripts	 fail	 in	ways	that	are	 legible	to	traditional	contractual	 frame-
works.	Put	simply,	they	fail	to	accomplish	their	parties’	intent.	Those	
examples	start	with	“tokens”	issued	in	“initial	coin	offerings,”	continue	
with	decentralized	exchanges,	and	finally	consider	so-called	“oracles.”	
We	describe	both	the	coded	and	natural	language	promises	accompa-
nying	 these	projects.	Each	such	category	of	 transactional	 script	has	
been	 touted	 as	 a	 revolutionary	 financial	 innovation.	 Each,	 as	 we’ll	
show,	have	already	produced	errors	with	real	legal	consequences.		

In	Part	III,	we	ask	how	law	ought	to	respond	to	the	sorts	of	prob-
lems	occasioned	by	such	systematic	failures	of	transactional	scripts.	
We	 argue	 that	 the	 layering	 of	 transactional	 script	 and	 natural	 lan-
guage	promise	is	best	understood	as	producing	a	contract	stack.	Con-
tract	stacks	are	inevitable	when	parties	come	together	to	accomplish	
commercial	ends,	even	if	they	try	their	hardest	to	make	the	code	the	
final	 answer	 to	 all	 their	 problems.	 Collecting	 the	 meager	 extant	
caselaw,	and	deploying	old	fashioned	rules	of	interpretation,	we	offer	
a	novel	framework	through	which	courts	ought	to	compile	such	stacks	
and	thus	make	sense	of	these	new	forms	of	commercial	exchange.		

The	framework	we	offer,	though	focused	on	the	scripted	ecosys-
tem	of	the	moment,	has	general	application.	Future	iterations	of	digit-
ized	 transactions,	whether	using	blockchain	or	 other	 forms	of	 soft-
ware,	 will	 require	 courts	 to	 make	 sense	 of	 gaps	 between	 natural	
language	 promises	 and	 coded	 executions.	 Our	 approach	 brings	 old	
principles	of	common	law	to	bear	on	the	problems	that	the	next	gen-
eration	of	contract	practitioners	and	academics	will	face.	

 

	 49.	 See	Elaine	Ou,	Blockchain	Is	Littered	with	‘Smart’	Contracts	Gone	Bad:	Opinion,	
INS.	 J.	 (Nov.	 16,	 2017),	 https://www.insurancejournal.com/news/international/	
2017/11/16/471387.htm	[https://perma.cc/P5MF-67N3].	



 

328	 MINNESOTA	LAW	REVIEW	 [105:319	

	

I.		DESIGNING	EXPENSIVE,	BUGGY	SCRIPTS			
We	begin	with	a	precise	account	of	the	creation	and	function	of	

transactional	scripts.	To	the	extent	that	the	discussion	requires	strug-
gling	with	new	jargon,	our	petard	has	been	well-hoisted.50	Our	goal	is	
not	merely	to	demystify	this	technology,	but	also	the	world	and	social	
practices	of	coders	whose	work	increasingly	matters	to	law	and	trans-
actional	practice.	We	make	two	primary	contributions.	First,	we	try	to	
explain	why	code	is	intrinsically	buggy.	Second,	we	offer	some	reasons	
to	 be	 skeptical	 about	 scripts’	 innate	 ability	 to	 simultaneously	 solve	
problems	of	trust,	complexity	and	automation	of	deals.	

	We	 start	with	 the	 functional	 question	of	how	coders	 go	 about	
their	work.	

A. HOW	(COMMERCIAL)	CODING	WORKS	
The	process	of	taking	a	programmer’s	intent	from	code	to	execu-

tion	involves	multiple	steps,	each	of	which	can	and	does	introduce	er-
ror.	Just	as	when	law	firms	draft	contracts,	programming	progresses	
in	 pieces	 and	 through	 teams. 51 	Programming	 teams	 typically	 start	
with	a	human-driven	goal.	They	then	choose	a	language	in	which	to	
code.	Typically,	coders	will	choose	a	high-level	language	that	abstracts	
away	the	details	of	the	machine’s	hardware	and	allows	programming	
in	syntax	closer	to	natural	language.	

Transactional	 scripts	 are	 commonly	 coded	 in	 Solidity,	 the	 lan-
guage	conceived	alongside	of,	and	for	use	on,	Ethereum,	the	platform	
on	which	most	scripts	operate.52	It	is	syntactically	similar	to	the	pop-
ular,	web-development	language,	Javascript	and	thus	looks	familiar	to	
many	non-smart-contract	coders.	To	create	a	transactional	script	 in	
Solidity,	a	coder	creates	a	text	file	with	contents	that	conform	to	the	
publicly	available	specification	of	the	Solidity	language,	and	that	cap-
ture	in	programmatic	form	the	design	goal.53	

 

	 50.	 Cf.	ELIZABETH	MERTZ,	THE	LANGUAGE	OF	LAW	SCHOOL:	LEARNING	TO	“THINK	LIKE	A	
LAWYER”	(2007)	(providing	the	classic	text	on	how	law	students	are	taught	to	think	and	
argue	in	distinctive	ways).	
	 51.	 On	“flexible	standardization”	and	the	production	of	contracts	in	law	firms,	see	
Matthew	Jennejohn,	The	Architecture	of	Contract	Innovation,	59	B.C.	L.	REV.	71	(2018).	
	 52.	 For	a	good	overview	of	 the	coding	ecosystem,	 see	Raina	S.	Haque,	Rodrigo	
Seira	Silva-Herzog,	Brent	A.	Plummer	&	Nelson	M.	Rosario,	Blockchain	Development	
and	Fiduciary	Duty,	2	STAN.	J.	BLOCKCHAIN	L.	&	POL’Y	1,	16–17	(2019).	
	 53.	 For	more	on	the	process	of	open	source	development	in	blockchain	generally,	
see	Angela	Walch,	Open-Source	Operational	Risk:	Should	Public	Blockchains	Serve	as	Fi-
nancial	Market	Infrastructures?,	in	2	HANDBOOK	OF	BLOCKCHAIN,	DIGITAL	FINANCE,	AND	IN-
CLUSION	252–54	(David	Lee	Kuo	Chuen	&	Robert	Deng	eds.,	2017).	



 

2020]	 TRANSACTIONAL	SCRIPTS	 329	

	

Like	traditional	contract	drafters,	transactional	script	developers	
freely	 use	 boilerplate.	 A	 significant	 fraction	 of	 code	 in	 open	 source	
software	projects	 is	copied.54	This	practice	 is	also	prominent	within	
the	transactional	scripts	world,	with	one	study	finding	in	95%	of	im-
plementations	 that	performed	a	common	function,	coders	had	used	
identical	 syntax.55	Reusing	or	 retrofitting	 code	 for	new	en";"""date"",""2021-04-02T14:58:21Z""
""pdf:PDFVersion"",""1.7""
""xmp:CreatorTool"",""Appligent pdfHarmony 2.0""
""pdf:docinfo:title"",""Transactional Scripts in Contract Stacks""
""Appligent"",""pdfHarmony 2.0 Linux Kernel 2.6 64bit Mar 13 2012 Library 9.0.1""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""language"",""en""
""dc:format"",""application/pdf; version=1.7""
""pdf:docinfo:creator_tool"",""Appligent pdfHarmony 2.0""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""Transactional Scripts in Contract Stacks""
""xmp:CreateDate"",""2021-04-02T07:58:21Z""
""modified"",""2021-04-02T14:58:21Z""
""pdf:hasMarkedContent"",""true""
""xmp:ModifyDate"",""2021-04-02T07:58:21Z""
""pdf:docinfo:creator"",""Shaanan Cohney Hoffman, David A.""
""meta:author"",""Shaanan Cohney Hoffman, David A.""
""meta:creation-date"",""2021-04-02T14:58:21Z""
""created"",""2021-04-02T14:58:21Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2021-04-02T14:58:21Z""
""resourceName"",""viewcontent.cgi""
""Author"",""Shaanan Cohney Hoffman, David A.""
""producer"",""Prince 12.5 (www.princexml.com)""
""pdf:docinfo:producer"",""Prince 12.5 (www.princexml.com)""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""access_permission:modify_annotations"",""true""
""dc:creator"",""Shaanan Cohney Hoffman, David A.""
""dcterms:created"",""2021-04-02T14:58:21Z""
""Last-Modified"",""2021-04-02T14:58:21Z""
""dcterms:modified"",""2021-04-02T14:58:21Z""
""pdf:docinfo:custom:Appligent"",""pdfHarmony 2.0 Linux Kernel 2.6 64bit Mar 13 2012 Library 9.0.1""
""title"",""Transactional Scripts in Contract Stacks""
""xmpMM:DocumentID"",""uuid:88b9dfb9-b0eb-11b2-0a00-206224020000""
""Last-Save-Date"",""2021-04-02T14:58:21Z""
""pdf:docinfo:modified"",""2021-04-02T14:58:21Z""
""meta:save-date"",""2021-04-02T14:58:21Z""
""Content-Length"",""1830729""
""Content-Type"",""application/pdf""
""xmp:MetadataDate"",""2021-04-02T07:58:21Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Shaanan Cohney Hoffman, David A.""
""dc:language"",""en""
""pdf:producer"",""Prince 12.5 (www.princexml.com)""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""71""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""838"",""2643"",""2701"",""3165"",""3365"",""3220"",""3207"",""2795"",""2861"",""2660"",""2750"",""3133"",""2714"",""3172"",""2687"",""3018"",""2569"",""3604"",""3076"",""2937"",""2709"",""3169"",""3253"",""1014"",""621"",""2169"",""2887"",""3180"",""2852"",""2760"",""1997"",""2407"",""2618"",""2871"",""2994"",""2672"",""2814"",""1867"",""3165"",""3105"",""2252"",""2423"",""2688"",""2394"",""2460"",""2814"",""2327"",""2925"",""3038"",""2839"",""2722"",""2663"",""2864"",""2639"",""2982"",""3038"",""3409"",""1120"",""820"",""2966"",""2958"",""2525"",""3253"",""1711"",""2723"",""2673"",""2947"",""2626"",""2858"",""2934"",""1604""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2021-04-02T14:58:21Z""
";https://scholar.google.ch/scholar?start=590&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098765-109;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Utilizing Pre-validation, Hybrid-trusted Parties and Multiple Milestone Payment Systems in Improving Blockchain Transaction Security and Efficiency;A Alruwaili ;2020 search.proquest.com;;"… that is called Delegated Proof of Stake (DPoS) to maintain agreements across a blockchain

network. The stake is another word of a cryptocurrency. When someone has staked some

cryptocurrency, that means that person holds these cryptocurrencies.";Autres articles;;null;;;;https://scholar.google.ch/scholar?start=650&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098760-98;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;[PDF][PDF] A Decentralized Resource Allocation System;Y Cai, Y Li, Z Yang, S Wu, R Zhu ;2020 researchgate.net;;"… It processes peer-to-peer contracts by a decentralized Ethernet virtual machine through its

dedicated cryptocurrency Ethernet coin (Ether, referred to as ”ETH”) … Currently the

state-of-the-art solution is to use an ”oracle” [7] outside of blockchain to generate random …";Autres articles;Version HTML;[PDF] researchgate.net;https://www.researchgate.net/profile/Ruiqi_Zhu6/publication/340398222_A_Decentralized_Resource_Allocation_System_-_DLC_Group_Project/links/5e86ffdd92851c2f5277c88c/A-Decentralized-Resource-Allocation-System-DLC-Group-Project.pdf;;;https://scholar.google.ch/scholar?start=640&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098879-366;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Performance Evaluation of Blockchain Systems: A Systematic Survey;C Fan, S Ghaemi, H Khazaei, P Musilek ; IEEE Access, 2020  ieeexplore.ieee.org;;"… In the Oracle blockchain guidance book [46], the authors defined five lay- ers to display the general

architecture of blockchain, includ- ing the … Other examples include the wallet to manage

cryptocurrency, smart contracts, and all kinds of decentralized applications (DApps) …";Cité 16 fois;Les 3 versions;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/6287639/8948470/09129732.pdf;"
		
	";"""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""dc:title"",""IEEE Xplore Full-Text PDF:""
""Content-Encoding"",""UTF-8""
""resourceName"",""09129732.pdf""
""language"",""es""
""Content-Length"",""2565""
""title"",""IEEE Xplore Full-Text PDF:""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";https://scholar.google.ch/scholar?start=910&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098765-103;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;[PDF][PDF] CanDID: Can-Do Decentralized Identity with Legacy Compatibility, Sybil-Resistance, and Accountability;D Maram, H Malvai, F Zhang, N Jean;Louis, A Frolov… 2020 arijuels.com;;"… XI). II. BACKGROUND: ORACLES CanDID relies on a blockchain-style oracle system

[23], [84], [56], [83] for credential issuance and key recovery, al- though CanDID does

not require use of the oracle to interface with a blockchain …";Cité 4 fois;Les 4 versions;[PDF] arijuels.com;http://www.arijuels.com/wp-content/uploads/2020/07/Candid.pdf;"
1

CanDID: Can-Do Decentralized Identity with Legacy Compatibility, Sybil-Resistance,
and Accountability

Deepak Maram∗¶, Harjasleen Malvai†¶, Fan Zhang∗¶, Nerla Jean-Louis‡¶, Alexander Frolov†¶, Tyler Kell∗¶,
Tyrone Lobban§, Christine Moy§, Ari Juels∗¶, Andrew Miller‡¶

∗Cornell Tech, †Cornell University, ‡UIUC, §J. P. Morgan, ¶IC3, The Initiative for CryptoCurrencies & Contracts

Abstract—We present CanDID, a platform for practical, user-
friendly realization of decentralized identity, the idea of empow-
ering end users with management of their own credentials.

While decentralized identity promises to give users greater
control over their private data, it burdens users with management
of private keys, creating a significant risk of key loss. Existing and
proposed approaches also presume the spontaneous availability
of a credential-issuance ecosystem, creating a bootstrapping
problem. They also omit essential functionality, like resistance to
Sybil attacks and the ability to detect misbehaving or sanctioned
users while preserving user privacy.

CanDID addresses these challenges by issuing credentials
in a user-friendly way that draws securely and privately on
data from existing, unmodified web service providers. Such
legacy compatibility similarly enables CanDID users to leverage
their existing online accounts for recovery of lost keys. Using
a decentralized committee of nodes, CanDID provides strong
confidentiality for user’s keys, real-world identities, and data,
yet prevents users from spawning multiple identities and allows
identification (and blacklisting) of sanctioned users.

We present the CanDID architecture and its technical inno-
vations and report on experiments demonstrating its practical
performance.

I. INTRODUCTION

Identity management lies at the heart of any user-facing
system, be it a social media platform, online game, or col-
laborative tool. Backlash against the handling of personal
information by large tech firms [3], [4] has recently spawned
a new approach to identity management called decentralized
identity—a.k.a. self-sovereign identity [8], [10], [28], [71].

Decentralized identity systems allow users to gather and
manage their own credentials under the banner of self-created
decentralized identifiers (DIDs). By controlling private keys
associated with DIDs, users are empowered to disclose or
withhold their credentials as desired in online interactions.
Enterprises also benefit by limiting the liability associated with
storage of sensitive user data [45].

The most commonly cited use cases for DIDs involve
users authorizing release of personal credentials from user
devices to websites [58]. For example, an online job applicant
might release a digitally signed credential from her university
showing that she has received a bachelor’s degree and a proof
of residency in the country in which she is applying. Initiatives
such as the Decentralized Identity Foundation [28] and Decen-
tralized Identifiers (DID) working group of W3C [71] are de-
veloping standards and use cases to support such transactions.
They largely fail, however, to address four main technical and
usability goals that we target in this work. Specifically, these
goals are especially challenging to achieve, as we seek to do,
in a privacy-preserving way:

1) Legacy compatibility: Most proposed decentralized identity
systems presume the existence of a community of issuers
of digitally signed credentials. But such issuers may not
arise—and existing credential issuers may not begin to
issue digitally signed variants of existing credentials—until
decentralized identity infrastructure sees use. The result is a
bootstrapping problem. A big impediment to DID adoption
is the inability of proposed systems to leverage the rich data
on users available in existing web services that do not issue
signed attestations.

2) Sybil-resistance: Proposed decentralized identity systems
do not deduplicate user identities. Unique per-user iden-
tities are critical, though, in many systems: anonymous
voting, fair currency distribution (“airdrops”), etc.

3) Accountability: It is challenging both to provide user pri-
vacy, i.e., conceal users’ real-world identities, and achieve
compliance with regulations such as Know-Your-Customer
(KYC) / Anti-Money-Laundering (AML). Particularly im-
portant is an ability to screen users of the system, i.e.,
identify and bar identified misbehaving or criminal users.

4) Key recovery: In decentralized identity systems, users bear
the burden of managing their own private keys. Key recov-
ery is potentially the Achilles’ heel of such systems, as it is
well known that users regularly lose valuable keys. Billions
of dollars of cryptocurrency are known to have vanished
because of lost keys [57].

Proposed solutions to these problems are problematic in
various ways. For example, for key management / recovery,
users can delegate or escrow their private keys with an online
service (like Coinbase for cryptocurrency [5])—but would then
effectively re-centralize identity management. W3C proposes
a quorum of trusted parties to enable key recovery, but omits
details [71]; Microsoft plans to unveil a new approach, but
details remain forthcoming at the time of writing [50].

The other three enumerated challenges, legacy compat-
ibility, Sybil-resistance, and (privacy-preserving) sanctions
screening, have seen little or no treatment in proposed decen-
tralized identity systems, and treatment relevant to such sys-
tems in only a few works in the research literature, e.g., [17],
[18], [22], [24], [34], [79].

A. CanDID

In this paper, we present CanDID1, a decentralized-identity
system that aims to address the four major challenges high-
lighted above, while providing strong privacy properties. Can-

1The name means “honestly presenting information”; we also use it to
signify that users “can do decentralized identities (DIDs)”.



2

DID can act as a freestanding service or can be coupled
with other decentralized identity systems. It is decentralized
in the sense that it relies on a committee of nodes, which may
represent distinct entities.

CanDID consists of two subsystems: An identity system for
issuing and managing credentials, and a key recovery system.

1) Identity system: CanDID leverages an oracle—
specifically, either DECO [84] or Town Crier [83]—to port
identities and credentials securely from existing web services.
These services can be social media platforms, online bank
accounts, e-mail accounts, etc. The oracles used by CanDID
allow it to scrape websites in order to construct trustworthy
credentials without providers needing to explicitly create
DID-compatible credentials or even be aware of CanDID,
easing the way for ecosystem bootstrapping.

Credential privacy: In support of its strong privacy ob-
jectives, CanDID allows users to construct credentials that
reveal information selectively via zero-knowledge arguments.
For instance, a user can construct a credential proving that
she is at least 18 years of age. In doing so, she need not
reveal her actual birthdate either to committee nodes or to
entities to which she presents the credential. Second, CanDID
provides strong membership privacy. Committee nodes and
web-identity providers not only cannot learn users’ real-world
identities, but cannot learn user membership, i.e., whether a
given real-world user is active in CanDID.

As in other DID schemes, e.g., [10], [28], [71], CanDID
supports the use of pairwise credentials. That is, it permits
users to generate credentials unique to each user-service rela-
tionship and unlinkable to those used in other relationships.
CanDID can in principle alternatively support fully anonymous
credentials. Conversely, CanDID is compatible with models in
which users register pseudonymous decentralized identifiers
(DIDs) on a blockchain or other distributed ledger.

Novel capabilities: Beyond credential issuance, which is
fundamental to any decentralized identity system, CanDID’s
identity system includes two new and distinctive capabilities:
Sybil-resistance and sanctions screening.

a) Sybil-resistance: CanDID deduplicates identities, en-
abling relying parties to achieve high assurance that users are
presenting credentials that are unique to them, and that a single
user does not spawn multiple identities. CanDID supports
deduplication of identities with respect to unique numerical
identifiers like Social Security Numbers. It uses a special-
purpose MPC protocol that is privacy-preserving, meaning
values of attributes used for deduplication are hidden even
from committee nodes.

b) Accountability: The CanDID committee can screen
users of the system so as to identify the credentials of
suspect users or known malefactors. This operation is privacy-
preserving: the committee learns nothing about users not on
the list. Lists of users banned from participation in financial
systems, i.e., sanctions lists, in practice identify individuals
based on attributes such as name / address represented as
strings, not unique numerical identifiers [69]. Thus CanDID
supports fuzzy matching, i.e., tolerance of small edit-distance
variances. The CanDID committee can create a public revo-

❷
Deduplication

Legacy 
identity 
providers

❶ Port identities ❶ Port identities

❸ DID Issuance

❚ Use DID
CanDID committee

(a) High-level credential-issuance workflow.

❷Verify proofs
❶ Obtain an 
authentication proof

Backup DID key & set 
authenticator to P

❶ Obtain an 
authentication proof

Legacy 
authenticator 

P

❸ Release DID key

CanDID committee❚ Use DID key

(b) Key backup and recovery workflow.

Fig. 1: CanDID architecture overview and workflow.

cation list of credentials identified by the screening process.
CanDID performs privacy-preserving fuzzy matching using

secure multiparty computation (MPC), a technically chal-
lenging goal. We explore a range of performance-optimizing
techniques, including different data structures for representing
user attributes in secret-shared form in the system.

We show the basic workflow for credential issuance (without
sanctions screening) in Fig. 1a.

2) Key-recovery system: To enable users to back up and
recover private keys in a secure, user-friendly way, CanDID
uses a oracle-based workflow like that for credential issuance.

This approach allows users to leverage existing web au-
thentication schemes and engage in a familiar, user-friendly
workflow to recover their keys. Users may store their private
keys on whatever devices, e.g., mobile phones, they choose
for regular use. Users can back up their private keys with
the CanDID committee (privately, via secret-sharing) and
prespecify recovery accounts on web services of their choice,
along with a recovery policy (e.g., successful authentication
for 2-out-of-3 accounts). To recover her key, a user proves
successful logins under her chosen policy.

Fig. 1b shows CanDID’s key-recovery workflow.

Key-recovery privacy: CanDID’s use of oracles allows a user
to prove she was successful in logging into a preselected
account, but without revealing account information to com-
mittee nodes or CanDID use to web service providers. NaĹ̈ve
approaches, e.g., use of OAuth, would leak such information.

B. Contributions and Paper Organization

To summarize, CanDID offers a practical approach to de-
centralized identity management that overcomes a number of
significant challenges.

In what follows, we present brief background on oracles
(Sec. II), followed by an overview of CanDID (Sec. III) and
its system and security models (Sec. IV).

Our main technical contributions are:



3

• Legacy-compatible credential issuance: CanDID leverages
oracle systems to construct user’s credentials based on data
with existing, unmodified web services (Sec. V).

• Sybil-resistance: CanDID enforces deduplication of identi-
ties, meaning that it issues credentials in a manner that is
unique per user (Sec. V).

• Accountability: The CanDID committee can identify creden-
tials associated with users who should be prevented from
using the system, e.g., appearing on a sanctions list, for
further action such as blacklisting. This process involves
privacy-preserving fuzzy matching of identifier strings using
new techniques in an MPC setting (Sec. VI).

• Key recovery: CanDID allows a user to store her key with
the CanDID committee to facilitate recovery, should a user
lose her private key. She may leverage existing online
accounts according to any policy she desires in order to
recover her key in an manner that provides privacy for
account identifiers (Sec. VII).

• Implementation and evaluation: We describe and report on
the performance of a basic implementation of CanDID. We
also report on experiments on the most computationally de-
manding system component: MPC-based privacy-preserving
fuzzy matching for sanctions screening (Sec. VIII).
We describe several example applications of CanDID

(Sec. IX), and discuss related work (Sec. X) before concluding
with a discussion of future research directions (Sec. XI).

II. BACKGROUND: ORACLES

CanDID relies on a blockchain-style oracle system [23],
[84], [56], [83] for credential issuance and key recovery, al-
though CanDID does not require use of the oracle to interface
with a blockchain.

An oracle relays and provides assurance around the authen-
ticity of data retrieved from authoritative sources—typically
web servers accessed via a secure channel such as TLS.
Specifically, it allows a prover to prove (publicly or to a
particular verifier) that a piece of data originates with a
particular source (e.g., as identified by its TLS certificate)—
and optionally prove arbitrary statements about the data.

CanDID uses an oracle system to allow users to import
identities securely from existing systems. For example, Alice
can use the profile page of her Social Security Administration
(SSA) account to generate a credential attesting to her Social
Security Number (SSN). The idea is for Alice to execute an or-
acle protocol—as the prover—to prove that a web page fetched
from the SSA site contains a string SSN: 123-45-6789 in
the appropriate context.

Currently, the only oracle protocols that provide privacy for
user data and are legacy-compatible, i.e., require no modifi-
cation of data sources, are DECO [84] and Town Crier [83].
DECO is a three-party protocol between a prover P , verifier
V , and TLS server S. It allows P to convince V that a piece
of data—possibly private to P—retrieved from S satisfies
a predicate Pred. DECO relies on Multi-Party Computation
(MPC) to protect data privacy and authenticity, and zero-
knowledge proofs (ZKPs) to prove a predicate is satisfied.
Having multiple verifiers decentralizes the protocol.

Town Crier accomplishes a similar goal. It relies, though,
on Trusted Execution Environments (TEEs), Intel SGX in
particular, to attest to the authenticity of TLS sessions and
prove statements about TLS plaintexts.

In general, Town Crier is faster than DECO, and can effi-
ciently handle much more complicated predicates than DECO.
Town Crier proofs are also publicly verifiable, while DECO
proofs are designated-verifier. Town Crier does, however,
introduce trust assumptions around TEEs called into question
by recent attacks (see, e.g., [51] for a survey).

CanDID can use either DECO or Town Crier, depending on
the desired trust model.

III. CANDID SYSTEM OVERVIEW

CanDID is a framework for issuing and managing creden-
tials. It is composed of two sub-systems: an identity system
that supports credential issuance and a key recovery system to
recover lost keys associated with credentials.

The key recovery system can be used for storage of any
secret, but we integrate it into CanDID for two reasons:
(1) Good key recovery is critical to safe use of CanDID
credentials; and (2) The key recovery system architecture
leverages the same tools as the credential issuance system.

The system goals common to the two sub-systems are:
1) Use of legacy credentials: Allow users to leverage cre-

dentials from existing systems.
2) Decentralization: Expose no single point of failure.
3) Membership privacy: Provide membership privacy, mean-

ing concealment of users’ real-world identities.
CanDID relies on a decentralized set of nodes, called the

CanDID committee. We assume the same committee for both
subsystems for convenience, but they can be overlapping or
distinct if desired.

We now review each sub-system in turn, specifying its goals
and explaining how we meet them.

A. Identity System

Fig. 2 is a visual overview of the key components and
workflows of CanDID’s identity subsystem. We refer to it
throughout our discussion in this subsection.

Goal: The overarching goal of CanDID’s identity system is
to convert commonly used legacy data to application-ready
decentralized credentials. While different applications con-
suming CanDID credentials may have different requirements,
they usually share common requirements, including:
1) Uniqueness: Include provisions to deduplicate user iden-

tities useful for applications like voting.
2) Non-transferability: Include preventive measures discour-

aging users from transferring their credentials.
3) Accountability: Provide a mechanism to trace and revoke

user identities based on their known real-world identities.
4) Pairwise privacy: Allow users to generate pairwise

DIDs [72], i.e., a distinct DID for each application—to
prevent identity correlation across services.

To achieve these goals, CanDID relies on decentralized
oracle schemes like DECO and Town Crier to port data from



4

Pre-
credentials

Master 
credential

Context-
based 

credential

Legacy 
data

Port

Deduplicate 
and Issue

Link 
and Issue

Revoke

Revocation 
Request

Updated 
Revocation 

List

Credential 
Bootstrapping

Credential Issuance
Credential 
Revocation

Fig. 2: Identity System overview through the lifecycle of a credential. Green indicates Sybil-resistant credentials, the final state.

legacy web accounts to create credentials—e.g., on Alice’s
SSN, as in the example above. The CanDID committee nodes
act as verifiers in the porting protocol as needed. (For instance,
DECO relies on verifiers, but Town Crier doesn’t.)

a) Uniqueness and Non-Transferability: Even with se-
curely created credentials, meeting our goals of uniqueness
and non-transferability still presents a challenge. Achieving
uniqueness is difficult because, given that credential attributes
are private, and thus hidden from the CanDID committee, there
is no inherent obstacle to a user invoking the porting process
to generate an arbitrary number of credentials. Lack of per-
user credential uniqueness can be problematic in a number of
settings, e.g., in anonymous voting systems.

Non-transferability is challenging because there is no tech-
nical obstacle to a user revealing private keys to a colluding
party. This is already a serious problem, with credentials regu-
larly sold in underground online markets [36], yet current DID
proposals do not address it. Non-transferability is important for
a range of applications, e.g., for video-streaming services to
prevent sharing or gray-market sale of content among users.

CanDID addresses both challenges—uniqueness and non-
transferability—by making the system Sybil-resistant. Sybil-
resistance is achieved by deduplicating based on one or more
attributes. For example, Social Security Number (SSN)-based
deduplication would ensure the existence of at most one
pseudonym with associated SSN attribute “123-45-6789.”

To perform deduplication, committee nodes maintain a
secret-shared table of the target user attributes, e.g., SSNs.
A new user joining the system presents one or more pre-
credentials asserting various attributes. A pre-credential in
CanDID is any credential that has not yet been been dedu-
plicated. Given pre-credentials for the attributes over which
deduplication takes place (e.g., SSN), the committee performs
a privacy-preserving MPC deduplication protocol to check the
table for the existence of these attributes in an already-issued
credential. Only on confirming a user’s asserted attributes are
unique does the system issue her a fresh Sybil-resistant cre-
dential called a master credential. Fig. 2 depicts this process.

Making the system Sybil-resistant helps discourage creden-
tial transfer. Each user can obtain only one master credential
CanDID, disincentivizing sale or transfer. Other deterrents
such as temporary revocation of misused credentials can be
effective for the same reason.

A key design question is which attributes to deduplicate
over. Our main focus here is on truly unique identifiers, like
Social Security Numbers (SSN) in the United States, for dedu-
plication. The use of unique identifiers allows efficient MPC
deduplication protocols, making this approach very practical.

Most, but not all of the world’s population, has such
identifiers. The MPC techniques we introduce in Sec. VI can in
principle be adapted instead for deduplication over commonly
used identifiers, like name and address, which are “fuzzy,” i.e.,
error prone. This approach is very computationally intensive,
though, making practicality a subject of future work.

The master credential issued after deduplication often does
not contain all the attributes a user will want to use in
interactions with application providers. For example, to vote,
an age credential is required. The CanDID committee can
subsequently issue context-based credentials for this purpose.
As shown in Fig. 2, a user presents pre-credentials (say, about
“age”) and her master credential to obtain this desired creden-
tial. The challenge in this step is to ensure that pre-credentials
belong to the same person holding the master credential.
Otherwise, users might buy cheap stolen accounts [52] to
prove arbitrary claims. The CanDID committee checks that a
common attribute like name is same across the pre-credentials
and the master credential. This linking operation is privacy-
preserving, so committee nodes never learn user attributes.

b) Accountability: CanDID enables identification of sus-
pect users or known malefactors based on their real-world
identities, and permits subsequent listing of such users on a
committee-maintained, public revocation list, as seen in Fig. 2.
Any verifying party can check this list to ensure that a shown
credential is not revoked.

One common way to identify misbehaving users in financial
systems, for example, is through sanctions lists. Sanctions lists
include individuals, e.g., terrorists and narcotics traffickers, as
well as organizations whose assets have been frozen or blocked
by government agencies. An example of such a list is the
Specially Designation Nationals and Blocked Person (SDN)
list published by the Office of Foreign Assets Control (OFAC)
within the U.S. Department of the Treasury. U.S. financial
institutions may not open accounts for individuals on the SDN
list, and regulators typically require that financial institutions
conduct periodic sanctions screening of their customers [32].

CanDID can support revocation of users identifies on a tar-



5

get sanctions list or otherwise with known real-world identities
in a privacy-preserving fashion. For example, in the case of
a sanctions list, users must prove that they are not on the
sanctions list in order to obtain a credential. But CanDID must
additionally determine if an existing CanDID credential was
issued to a person newly added to a sanctions list. CanDID can
enforce accountability of this kind using a privacy-preserving
MPC matching protocol discussed in Sec. VI.

CanDID can also support user-initiated revocation for lost
or stolen credentials and identity theft.

c) Privacy: CanDID aims at strong privacy notions. Not
only are users’ attributes hidden from committee nodes, but
CanDID achieves attribute-membership privacy. This means
that committee nodes cannot determine, for a particular at-
tribute value, whether the system contains a credential with
that attribute value. We formalize our privacy definitions
in Sec. IV.

Supporting revocation based on real-world identities while
maintaining attribute privacy is one of the major technical
challenges in the design of CanDID. The reason is that in
many cases, e.g., with sanctions lists, misbehaving individuals
are typically identified by means of attributes like names and
addresses, and not always by unique identifiers like Social
Security numbers (particularly as these lists may include for-
eign nationals). Matching is an inexact process, as names may
be misspelled, inconsistently transliterated, etc. Consequently,
CanDID stores target attributes in secret-shared form and does
sanctions-screening searches by means of privacy-preserving
string matching. Specifically, CanDID uses a newly developed
MPC-based fuzzy matching technique optimized to scale in a
practical way. We give details in Sec. VI.

Credential issuance in CanDID provides pseudonymity by
means of pairwise DIDs, as is common in DID proposals; see,
e.g., [72]. Users can use different pseudonyms with different
applications. Even collusion among all application providers
is insufficient to link different user pseudonyms.

B. Key Recovery System

Goal: The goal of the key recovery system in CanDID is
simply to prevent identity loss. Since identities are controlled
through keys, CanDID aims to provide a secure, user-friendly
key recovery solution. (CanDID does not address key theft.)

Like many other systems, CanDID envisages users storing
their private keys securely on personal devices, such as mobile
phones. Key backup / recovery is the Achilles’ heel of these
systems. Cryptocurrency wallets require secure physical stor-
age of printed word lists, an unfamiliar and onerous process
for most users. CanDID, in contrast, allows users to recover
their keys using existing legacy web authentication schemes.
CanDID thus provides users with a familiar and convenient
user experience during key recovery.

As shown in Fig. 3, a user enrolls in the key recovery
service in CanDID by providing their keys along with a
recovery policy. The CanDID committee stores a user’s key
in a secret-shared fashion, releasing it only upon the user
meeting the criteria specified in her policy. CanDID supports

Enrolled 
DID key

RecoverEnroll

Authentication 
Policy and Proofs

Authentication 
Proofs

❶ ❷

Committee

User

DID key

Fig. 3: CanDID Key Recovery System overview in terms of
the lifecycle of a DID key.

flexible authentication policies that can combine several ex-
isting authentication schemes. An example policy is 2-out-of-
3 threshold authentication involving Facebook, Google, and
Twitter accounts. Users can plug in any provider they like.
To authenticate, a user provides committee nodes with corre-
sopnding privacy-preserving proofs of account ownership. We
give details on CanDID’s key recovery system in Sec. VII.

While the CanDID key recovery system is meant for Can-
DID private keys—DID keys—it can in principle be used to
back up any desired secrets.

IV. SYSTEM AND SECURITY MODELS

We formalize our presentation of CanDID by presenting
our system and security models, along with notation and
discussion of key security properties.

A. System Model

The CanDID system involves three types of parties: users,
credential issuers, and credential verifiers.

Let U denote a user. Each user creates a public / private
key pair (pkU , skU ). For simplicity of exposition, and by
analogy with practice in cryptocurrencies, we use and refer
to the public key itself as a user identifier or pseudonym in
CanDID. CanDID supports the use of decentralized identifiers
(DID) by relying on a PKI-like infrastructure that stores the
mapping between DIDs and public keys. We will therefore
also use the terms DIDs and public keys interchangeably.

The committee in CanDID acts as the credential issuer.2

We assume a permissioned model for selecting committee
nodes. Let C denote the committee, which consists of n
nodes, {Ci}ni=1. The committee nodes store a secret key skC

jointly, used to issue credentials. The corresponding public
key pkC serves to verify credentials. Any party (e.g., CanDID
applications, committee nodes) can act as a credential verifier.

Credential: We adopt the definition of a credential from the
W3C Verifiable Credentials specification [78]. A credential is
defined as a set of claims made by an issuer, where each claim
is a statement about the user whose form is explained below.

2Note that in the traditional view of DIDs, the role of an issuer is fulfilled
by legacy providers themselves. In contrast, CanDID uses DECO and Town
Crier to port data and issue credentials in a legacy-provider-oblivious way.



6

Notation Description

U User
C Committee
P Legacy provider

pkU User identifier
ctx Context
claim Claim
cred Credential

TABLE I: Notation

Each credential also contains a context, used to indicate the
circumstances of its use.

Concretely, in CanDID, a credential contains a user iden-
tifier, context, one or more claims and a signature over the
credential body, as follows.
1) User identifier (pkU ): The pseudonymous identifier of the

subject of the credential. Also referred to as a pseudonym.
2) Context (ctx): A string denoting the circumstances for

credential use, e.g., “Voting at Company A.”
3) Claims ({claimi}): Each claimi = {ai, vi, Pi} contains an

attribute, value, and provider, as follows:
a) Attribute (a): A string denoting what the claim is about,

e.g., “Name.”
b) Value (v): The value of the attribute. A value is either

a plaintext string (e.g., “Alice”) or a commitment to it.
(The need for a commitment is explained later.)

c) Provider (P ): A string denoting the legacy web provider
used to source the claim, e.g., “ssa.gov.” This field is
optional.

We denote a set of claims by CS = {claimi}.
4) Signature (σ): The signature by the issuer over the user

identifier, context and claims.
We tabulate our notation in Table I. If there are k claims

in total, i.e., CS = {claimi}ki=1 then the signature of the
committee is, σ = SigskC ({pkU , ctx, CS}). A credential looks
like cred = {pkU , ctx, CS, σ}. See Fig. 4 for an example
credential. (CanDID credentials are represented using JSON
format in our figures.) Note that CanDID achieves pairwise
pseudonymity by allowing users to choose different identifiers
for their different credentials.

Our notation largely follows the W3C spec. The main
difference is the introduction of an optional “Provider” field
in each claim, necessitated by our approach of sourcing
claims from existing providers. Additional metadata such as
credential expiry dates and porting protocol (e.g., DECO /
Town Crier) can also easily be supported.

To reflect CanDID’s deduplication process over a set of
attributes Attr, all CanDID credentials contain a claim with
attribute “dedupOver” and value Attr, amongst other claims.

B. Security Model

We define the security properties of CanDID in terms of
a set of game-based security definitions. We defer the formal
definitions to App. A due to lack of space. First we define our
model.
Adversarial model: We allow the adversary to statically and
actively corrupt up to t of the n committee nodes, for t < n/3.

In addition, the adversary can corrupt any number of external
entities, such as users and applications.

We assume that CanDID committee nodes hold a (t, n)-
Shamir secret sharing [62] of a private key skC , with corre-
sponding public key pkC .
Communication model: We assume that communication
channels are asynchronous. We note, however, that the dis-
tributed key generation protocol [40] used upon system ini-
tialization to generate (skC , pkC) requires weak synchrony for
liveness, although not for safety.
Security Properties: CanDID aims to satisfy the follow-
ing properties in the adversarial model described above. We
present the properties informally here and more formally in
their respective sections in the paper.
• Sybil-resistance (Def. 1): An adversary cannot obtain cre-

dentials associated with a larger number of distinct identities
than the number of users the adversary controls.

• Unforgeability (Def. 2): An adversary cannot forge the
credentials of honest users or otherwise impersonate them.

• Privacy: Credential-issuance and key-recovery (Def. 3
and Def. 4): It is infeasible for an adversary to learn user
attributes from observation of the credential-issuance and
key-recovery protocols respectively.

• Credential validity (De";"""date"",""2020-07-29T14:06:35Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2020-07-29T14:06:35Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.20 (TeX Live 2019) kpathsea version 6.3.1""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2020-07-29T14:06:35Z""
""created"",""2020-07-29T14:06:35Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-07-29T14:06:35Z""
""resourceName"",""Candid.pdf""
""Author"",""""
""producer"",""pdfTeX-1.40.20""
""pdf:docinfo:producer"",""pdfTeX-1.40.20""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""6"",""9"",""7"",""1"",""0"",""0"",""2"",""0"",""0"",""0"",""20"",""15"",""24"",""15"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2020-07-29T14:06:35Z""
""Last-Modified"",""2020-07-29T14:06:35Z""
""dcterms:modified"",""2020-07-29T14:06:35Z""
""title"",""""
""Last-Save-Date"",""2020-07-29T14:06:35Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2020-07-29T14:06:35Z""
""meta:save-date"",""2020-07-29T14:06:35Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.20 (TeX Live 2019) kpathsea version 6.3.1""
""Content-Length"",""1105023""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""21""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""5044"",""4843"",""5021"",""4707"",""4708"",""4617"",""5421"",""4794"",""5320"",""5144"",""5132"",""4572"",""4674"",""5375"",""6325"",""7615"",""5340"",""5013"",""4376"",""4801"",""3985""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-07-29T14:06:35Z""
";https://scholar.google.ch/scholar?start=650&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098818-225;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Outsourced privacy-aware task allocation with flexible expressions in crowdsourcing;J Xu, B Cui, R Shi, Q Feng ; Future Generation Computer Systems, 2020  Elsevier;;"… and privacy. Also the popularity of blockchain has promoted researchers to construct

decentralized privacy protection protocols [29], [30] to avoid the disadvantage of

centralized solutions. Inner-Product Encryption. In Functional …";Autres articles;;null;;;;https://scholar.google.ch/scholar?start=770&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098861-323;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Blockchain?based cyber physical trust systems;A Beckmann, A Milne, JJ Razafindrakoto… ; IoT Security …, 2020  Wiley Online Library;;"… objects without being destroyed, and which are enabled with suitable crypto- graphic primitives …

on adaptively chosen messages and identity attack under the random oracle model.

Lewison-Corella propose a blockchain-based distributed database to store data securely [12] …";Cité 2 fois;Les 4 versions;null;;;;https://scholar.google.ch/scholar?start=870&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098809-203;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;CCA-Secure (Puncturable) KEMs from Encryption With Non-Negligible Decryption Errors;V Cini, S Ramacher, D Slamanig, C Striecks ; International Conference on …, 2020  Springer;;"… M} \) and outputs \(M '\); if \(M =M '\), then the experiment outputs 1. For PKE-OW-PCA security,

\(A\) additionally has access to a plaintext checking oracle \(\textsc {Pco}(M,C … where n is the

number of public keys and \(A \) makes at most q queries to any of its n challenge oracles …";Cité 1 fois;Les 3 versions;[PDF] iacr.org;https://eprint.iacr.org/2020/1548.pdf;"
CCA-Secure (Puncturable) KEMs from
Encryption With Non-Negligible Decryption

Errors

Valerio Cini, Sebastian Ramacher, Daniel Slamanig, and Christoph Striecks

AIT Austrian Institute of Technology, Vienna, Austria
{firstname.lastname}@ait.ac.at

Abstract. Public-key encryption (PKE) schemes or key-encapsulation
mechanisms (KEMs) are fundamental cryptographic building blocks to
realize secure communication protocols. There are several known trans-
formations that generically turn weakly secure schemes into strongly (i.e.,
IND-CCA) secure ones. While most of these transformations require the
weakly secure scheme to provide perfect correctness, Hofheinz, HĂśvel-
manns, and Kiltz (HHK) (TCC 2017) have recently shown that variants
of the Fujisaki-Okamoto (FO) transform can work with schemes that
have negligible correctness error in the (quantum) random oracle model
(QROM). Many recent schemes in the NIST post-quantum competition
(PQC) use variants of these transformations. Some of their CPA-secure
versions even have a non-negligible correctness error and so the tech-
niques of HHK cannot be applied.
In this work, we study the setting of generically transforming PKE
schemes with potentially large, i.e., non-negligible, correctness error to
ones having negligible correctness error. While there have been previ-
ous treatments in an asymptotic setting by Dwork, Naor, and Reingold
(EUROCRYPT 2004), our goal is to come up with practically efficient
compilers in a concrete setting and apply them in two different contexts.
Firstly, we show how to generically transform weakly secure determinis-
tic or randomized PKEs into CCA-secure KEMs in the (Q)ROM using
variants of HHK. This applies to essentially all candidates to the NIST
PQC based on lattices and codes with non-negligible error for which we
provide an extensive analysis. We thereby show that it improves some
of the code-based candidates. Secondly, we study puncturable KEMs
in terms of the Bloom Filter KEM (BFKEM) proposed by Derler et al.
(EUROCRYPT 2018) which inherently have a non-negligible correctness
error. BFKEMs are a building block to construct fully forward-secret
zero round-trip time (0-RTT) key-exchange protocols. In particular, we
show the first approach towards post-quantum secure BFKEMs generi-
cally from lattices and codes by applying our techniques to identity-based
encryption (IBE) schemes with (non-)negligible correctness error.

This is the full version of a paper which appears in Advances in Cryptology - ASI-
ACRYPT 2020 - 26th International Conference on the Theory and Application of
Cryptology and Information Security. The proceedings version is available online at:
https://doi.org/10.1007/978-3-030-64837-4_6

https://doi.org/10.1007/978-3-030-64837-4_6


1 Introduction

Public-key encryption (PKE) schemes or key-encapsulation mechanisms (KEMs)
are fundamental cryptographic building blocks to realize secure communica-
tion protocols. The security property considered standard nowadays is security
against chosen-ciphertext attacks (IND-CCA security). This is important to avoid
pitfalls and attacks in the practical deployments of such schemes, e.g., padding-
oracle attacks as demonstrated by Bleichenbacher [Ble98] and still showing up
very frequently [JSS12, ASS+16, BSY18, RGG+19]. Also, for key exchange
protocols that achieve the desirable forward-secrecy property, formal analysis
shows that security against active attacks is required (cf. [JKSS12, KPW13,
DFGS15, PST20]). This equally holds for recent proposals for fully forward-
secret zero round-trip time (0-RTT) key-exchange protocols from puncturable
KEMs [GHJL17, DJSS18, DGJ+18] and even for ephemeral KEM keys for a
post-quantum secure TLS handshake without signatures [SSW20].

In the literature, various different ways of obtaining CCA security generically
from weaker encryption schemes providing only chosen-plaintext (IND-CPA) or
one-way (OW-CPA) security are known. These can be in the standard model us-
ing the double-encryption paradigm due to Naor and Yung [NY90], the compiler
from selectively secure identity-based encryption (IBE) due to Canetti, Halevi
and Katz [CHK04], or the more recent works due to Koppula and Waters [KW19]
based on so called hinting pseudo-random generators and Hohenberger, Koppula,
and Waters [HKW20] from injective trapdoor functions. In the random oracle
model (ROM), CCA security can be generically obtained via the well-known
and widely-used Fujisaki-Okamoto (FO) transform [FO99, FO13] yielding par-
ticularly practical efficiency.

Perfect correctness and (non-)negligible correctness error. A property
common to many compilers is the requirement for the underlying encryption
schemes to provide perfect correctness, i.e., there are no valid ciphertexts where
the decryption algorithm fails when used with honestly generated keys. Recently,
Hofheinz, HĂśvelmanns, and Kiltz (HHK) [HHK17a] investigated different vari-
ants of the FO transform also in a setting where the underlying encryption
scheme has non-perfect correctness and in particular decryption errors may oc-
cur with a negligible probability in the security parameter. This is interesting
since many PKE schemes or KEMs based on conjectured quantum-safe assump-
tions and in particular assumptions on lattices and codes do not provide per-
fect correctness. Even worse, some of the candidates submitted to the NIST
post-quantum competition (PQC) suffer from a non-negligible correctness er-
ror and so the FO transforms of HHK cannot be applied. Ad-hoc approaches
to overcome this problem that are usually chosen by existing constructions in
practice — if the problem is considered at all — is to increase the parame-
ters to obtain a suitably small decryption error, applying an error correcting
code on top or implementing more complex decoders. In practice, these ad-hoc
methods come with drawbacks. Notably, LAC, which is a Learning With Errors
(LWE) based IND-CCA secure KEM in the 2nd round of the NIST PQC that

2



applies an error correcting code, is susceptible to a key-recovery attack recently
proposed by Guo et al. [GJY19]. Also, code-based schemes have a history of
attacks [GJS16, SSPB19, FHS+17] due to decoding errors. Recently, Bindel and
Schanck [BS20] proposed a failure boosting attack for lattice-based schemes with
a non-zero correctness error. For some code-based schemes, the analysis of the
decoding error is a non-trivial task as it specifically depends on the decoder.
For instance, the analysis of BIKE’s decoder, another 2nd round NIST PQC
candidate, has recently been updated [SV19].

Consequently, it would be interesting to have rigorous and simple approaches
to remove decryption errors (to a certain degree) from PKE schemes and KEMs.
Immunizing encryption schemes. The study of “immunizing” encryp-
tion schemes from decryption errors is not new. Goldreich, Goldwasser, and
Halevi [GGH97] studied the reduction or removal of decryption errors in the
Ajtai-Dwork encryption scheme as well as Howgrave-Graham et al. [HNP+03]
in context of NTRU. The first comprehensive and formal treatment has been
given by Dwork, Naor, and Reingold [DNR04] who study different amplification
techniques in the standard and random oracle model to achieve non-malleable
(IND-CCA secure) schemes. One very intuitive compiler is the direct product
compiler Enc⊗` which encrypts a messageM under a PKE Π = (KGen,Enc,Dec)
with a certain decryption error δ under ` independent public keys from KGen,
i.e,. pk′ := (pk1, . . . , pk`) as Enc′(pk′,M) := (Enc(pk1,M), . . . ,Enc(pk`,M)).
Dec′, given C ′ = (C1, . . . , C`) tries to decrypt Ci, 1 ≤ i ≤ `, and returns the
result of a majority vote among all decrypted messages, yielding an encryption
scheme with some error δ′ ≤ δ. Their asymptotic analysis, however, and
limitation to PKEs with a binary message space does not make it immediate
what this would mean in a concrete setting and in particular how to choose `
for practically interesting values of δ and δ′. For turning a so-obtained amplified
scheme with negligible correctness error into a CCA-secure one in the ROM,
they provide a transform using similar ideas, but more involved than the FO
transform. Bitansky and Vaikuntanathan [BV17] go a step further and turn
encryption schemes with a correctness error into perfectly correct ones, whereas
they even consider getting completely rid of bad keys (if they exist) and, thus,
completely immunize encryption schemes. They build upon the direct product
compiler of Dwork et al. and then apply reverse randomization [Nao90] and
Nisan-Wigderson style derandomization [NW94]. Thereby, they partition the
randomness space into good and bad randomness, and ensure that only good
randomness is used for encryption and key generation.

Our goals. In this work, we are specifically interested in transformations that
lift weaker schemes with non-negligible correctness error into CCA-secure ones
with negligible error. Thereby, our focus is on modular ways of achieving this
and can be seen as a concrete treatment of ideas that have also be discussed by
Dwork et al. [DNR04], who, however, treat their approaches in an asymptotic
setting only. We show that the direct product compiler can be used with
variants of the standard FO transform considered by HHK [HHK17a] (in the
ROM) as well as Bindel et al. [BHH+19] and Jiang et al. [JZM19] (in the

3



quantum ROM (QROM) [BDF+11]). They are used by many candidates of the
NIST PQC, when starting from PKE schemes having non-negligible correctness
error generically. As we are particularly interested in practical compilers in a
concrete setting to obtain CCA security for KEMs in the (Q)ROM, we analyze
the concrete overhead of this compiler and its use with widely used variants
of the transforms from HHK. Moreover, we provide a rigorous treatment of
non-black-box applications of these ideas and show that they yield better
concrete results than the direct application of the direct product compiler.
Importantly, it gives a generic way to deal with the error from weaker schemes
(e.g., IND-CPA secure ones with non-negligible error) which are easier to design.
An interesting question that we will study is how does increasing from one to
` ciphertexts compare to increasing the parameters at comparable resulting
decryption errors for existing round-two submissions in the NIST PQC. As it
turns out, our approach performs well in context of code-based schemes but
gives less advantage for lattice-based schemes.

We also study our approach beyond conventional PKE schemes and KEMs.
In particular, a class of KEMs that have recently found interest especially in con-
text of full forward-secrecy for zero round-trip time (0-RTT) key-exchange (KE)
protocols are so-called puncturable KEMs [GM15, GHJL17, DJSS18, SSS+20]
and, in particular, Bloom Filter KEMs (BFKEMs) [DJSS18, DGJ+18]. BFKEMs
schemes are CCA-secure KEMs that inherently have non-negligible correctness
error. Interestingly, however, the non-negligible correctness error comes from
the Bloom filter layer and the underlying IBE scheme (specifically, the Boneh-
Franklin [BF01] instantiation in [DJSS18]) is required to provide perfect correct-
ness. Thus, as all post-quantum IBEs have at least negligible correctness error,
there are no known post-quantum BFKEMs.

1.1 Contribution

Our contributions on a more technical level can be summarized as follows:

Generic transform. We revisit the ideas of the direct product compiler of
Dwork et al. [DNR04] (dubbed Cp,r and Cp,d for randomized and deterministic
PKEs, respectively) in the context of the modular framework of HHK [HHK17a].
In particular, we present a generic transform dubbed T? that, given any random-
ized PKE scheme with non-negligible correctness error, produces a derandomized
PKE scheme with negligible correctness error. We analyze the transform both in
the ROM and QROM and give a tight reduction in the ROM and compare it to
a generic application of the direct product compiler. The transform naturally fits
into the modular framework of HHK [HHK17a], and, thus, by applying the U 6⊥

transform, gives rise to an IND-CCA-secure KEM. For the analysis in the QROM,
we follow the work of Bindel et al. [BHH+19]. We show that the T? transform
also fits into their framework. Hence, given the additional injectivity assumption,
we also obtain a tight proof for U6⊥. But even if this assumption does not hold,
the non-tight proofs of Jiang et al. [JZM19] and HĂśvelmanns et al. [HKSU20]
still apply. Compared to the analysis of the T transform that is used in the

4



nn-rPKE
IND-CPA

dPKE
OW-PCA

KEM
IND-CCA

rPKE
IND-CPA

nn-dPKE
OW-CPA

dPKE
OW-CPA

T?

Theorem 7 U6⊥

[HHK17a] Thm. 3.4T
[HHK17a] Thm. 3.1

Cp,r

Corollary 1

Cp,d/C?
p,d

Corollary 1

U6⊥m
[HHK17a] Thm. 3.6

Fig. 1. Overview of the transformations in the ROM with the results related to T?

highlighted in blue. rPKE denotes a randomized PKE. dPKE denotes a deterministic
PKE. The prefix nn indicates encryption schemes with non-negligible correctness error.

nn-rPKE
IND-CPA

dPKE
OW-CPA

KEM
IND-CCA

nn-rPKE
Îľ-injective

dPKE
FFC

rPKE
IND-CPA

nn-rPKE
DS + IND-CPA

nn-dPKE
OW-CPA

T?

Theorem 8

T?

Lemma 2

U 6⊥

[JZM19] Thm. 6

U6⊥

[KSS+20] Thm. 4.6

T [BHH+19] Thm. 1

Cp,r

Corollary 1

Corollary 1

Cp,d/C?
p,d

U6⊥m ◦ T?

[HKSU20] Thm. 3.2†

Fig. 2. Overview of the transformations in the QROM using the notation from Figure 1.
A dashed arrow denotes a non-tight reduction. DS denotes disjoint simulatability.
†: Obtained by applying the modifications from Theorems 7 and 8 to [HKSU20, Thm
3.2].

modular frameworks, our reductions lose a factor of `, i.e., the number of paral-
lel ciphertexts required to reach a negligible correctness error, in the ROM and
a factor of `2 in the QROM. For concrete schemes, this number is small (e.g.,
≤ 5) and, thus, does not impose a significant loss. An overview of the trans-
formations and how our transform fits into the modular frameworks is given in
Figure 1 (ROM) and Figure 2 (QROM). Furthermore, using ideas similar to T?,
we discuss a modified version of the deterministic direct product compiler Cp,d

which we denote by C?p,d, that compared to the original one allows to reduce the
number of parallel repetitions needed to achieve negligible correctness error.
Evaluation. We evaluate T? based on its application to code- and lattice-based
second-round candidates in the NIST PQC. In particular, we focus on schemes
that offer IND-CPA secure versions with non-negligible correctness error such
as ROLLO [ABD+19], BIKE [ABB+19], and Round5 [GZB+19]. We compare
their IND-CCA variants with our transform applied to the IND-CPA schemes. In
particular, for the code-based schemes such as ROLLO we can observe improve-
ments in the combined size of public keys and ciphertexts, a metric important
when used in protocols such as TLS, as well as its runtime efficiency. We also ar-
gue the ease of implementing our so-obtained schemes which can rely on simpler
decoders. For lattice-based constructions, we find that the use of the transform
results in an increase in the sum of ciphertext and public-key size of 30% even in
the best case scenario, i.e., for an IND-CPA version of KEM Round5 [GZB+19].
Nevertheless, it offers easier constant-time implementations and the opportunity

5



of decreasing the correctness error without changing the underlying parameter
set and, thus, the possibility to focus on analyzing and implementing one pa-
rameter set for both, IND-CPA and IND-CCA security.

Bloom Filter KEMs. Finally, we revisit puncturable KEMs from Bloom fil-
ter KEMs (BFKEMs) [DJSS18, DGJ+18], a recent primitive to realize 0-RTT
key exchange protocols with full forward-secrecy [GHJL17]. Currently, it is un-
clear how to instantiate BFKEMs generically from IBE and, in particular, from
conjectured post-quantum assumptions due to the correctness error of the re-
spective IBE schemes. We show that one can construct BFKEMs generically
from any IBE and even base it upon IBEs with a (non-)negligible correctness
error. Consequently, our results allow BFKEMs to be instantiated from lattice-
and code-based IBEs and, thereby, we obtain candidates for post-quantum CCA-
secure BFKEMs.

On the progress in the NIST PQC. We note that our work has been done
during the second round of the NIST PQC. Meanwhile, NIST has announced
the third-round candidates and from the schemes that are suitable for our com-
pilers, BIKE [ABB+19] and FrodoKEM [NAB+19] still remain as alternate can-
didates in the competition. Moreover, we concretely analyze the submissions to
the second round and want to note that meanwhile there are additional results
on the cryptanalysis of some relevant second round schemes, i.e., for ROLLO
in [BBC+20] as well as for LEDAcrypt in [APRS20]. These results might require
a change in the parameters compared to the versions that we use in this work.

2 Preliminaries

Notation. For n ∈ N, let [n] := {1, . . . , n}, and let Ν ∈ N be the security
parameter. For a finite set S, we denote by s←$S the process of sampling
s uniformly from S. For an algorithm A, let y ← A(λ, x) be the process of
running A on input (Îť, x) with access to uniformly random coins and assigning
the result to y (we may assume that all algorithms take Îť as input). To make the
random coins r explicit, we write A(x; r). We say an algorithm A is probabilistic
polynomial time (PPT) if the running time of A is polynomial in Îť. A function
f is negligible if its absolute value is smaller than the inverse of any polynomial,
i.e., if ∀c ∃k0 s.t. ∀λ ≥ k0 : |f(λ)| < 1/λc.

2.1 Public-Key Encryption and Key-Encapsulation Mechanisms

Public-key encryption. A public-key encryption (PKE) scheme Π with mes-
sage spaceM consists of the three PPT algorithms (KGen,Enc,Dec): KGen(Îť), on
input security parameter Îť, outputs public and secret keys (pk, sk). Enc(pk,M),
on input pk and message M ∈M, outputs a ciphertext C. Dec(sk, C), on input
sk and C, outputs M ∈M∪{⊥}. We may assume that pk is implicitly available
in Dec.

6



Exp. Exppke-ind-cpa
Π,A (Ν)

(pk, sk)← KGen(λ)

(M0,M1)← A(pk)

b←$ {0, 1}
C∗ ← Enc(pk,Mb)

b′ ← A(C∗)

if b = b′ then return 1
else return 0

Exp. Exppke-ow-cpa
Π,A (Ν)

(pk, sk)← KGen(λ)

M ←$M
C∗ ← Enc(pk,M)

M ′ ← A(pk, C∗)

if M = M ′ then return
1 else return 0

Exp. Exppke-ow-pca
Π,A (Ν)

(pk, sk)← KGen(λ)

M ←$M
C∗ ← Enc(pk,M)

M ′ ← APco(·,·)(pk, C∗)

if M = M ′ then return 1
else return 0

Fig. 3. PKE-x-y security with x ∈ {OW, IND}, y ∈ {CPA,PCA} for Π.

Correctness. We recall the definition of δ-correctness of [HHK17a]. A PKE Π
is δ-correct if

E

[
max
M∈M

Pr[c← Enc(pk,M) : Dec(sk, C) 6=M ]

]
≤ δ,

where the expected value is taken over all (pk, sk)← KGen(λ).
PKE-IND-CPA, PKE-OW-CPA, and PKE-OW-PCA security. We say
a PKE Π is PKE-IND-CPA-secure if and only if any PPT adversary A has
only negligible advantage in the following security experiment. First, A gets an
honestly generated public key pk. A outputs equal-length messages (M0,M1)
and, in return, gets C∗b ← Enc(pk,Mb), for b←$ {0, 1}. Eventually, A outputs a
guess b′. If b = b′, then the experiment outputs 1. For PKE-OW-CPA security,
A does not receive a ciphertext for A-chosen messages, but only a ciphertext
C∗ ← Enc(pk,M) forM ←$M and outputsM ′; ifM =M ′, then the experiment
outputs 1. For PKE-OW-PCA security, A additionally has access to a plaintext
checking oracle Pco(M,C) returning 1 if M = Dec(sk, C) and 0 otherwise.

Definition 1. For any PPT adversary A the advantage function

Advpke-ind-cpa
Π,A (Ν) :=

∣∣∣∣Pr[Exppke-ind-cpa
Π,A (Ν) = 1

]
− 1

2

∣∣∣∣,
is negligible in Îť, where the experiment Exppke-ind-cpa

Π,A (Ν) is given in Figure 3 and
Π is a PKE as above.

Definition 2. For any PPT adversary A, and y ∈ {CPA,PCA} the advantage
function

Exppke-OW-y
Π,A (Ν) := Pr

[
Exppke-OW-y

Π,A (Ν) = 1
]
,

is negligible in Îť, where the experiments Exppke-ow-cpa
Π,A (Ν) and Exppke-ow-pca

Π,A (Ν) are
given in Figure 3 and Π is a PKE as above.

We recall a well known lemma below:

Lemma 1. For any adversary B there exists an adversary A with the same
running time as that of B such that

Advpke-ow-cpa
Π,B (λ) ≤ Advpke-ind-cpa

Π,A (Ν) +
1

|M|
.

7



Exp. Exppke-ffc
Π,A (Ν)

(pk, sk)← KGen(λ)

L← A(pk)

if exists C ∈ L with M ∈ M such that Enc(pk,M) = C and Dec(sk, C) 6= M
then return 1 else return 0

Fig. 4. Finding-failing-ciphertext experiment for Π.

We note that Lemma 1 equivalently holds for the `-IND-CPA notion below.
Multi-challenge setting. We recall some basic observations from [BBM00]
regarding the multi-challenge security of PKE schemes. In particular, for our
construction we need the relation between OW-CPA/IND-CPA security in the
conventional single-challenge and single-user setting and n-OW-CPA/n-IND-CPA
respectively, which represents the multi-challenge and multi-user setting. In par-
ticular, latter means that the adversary is allowed to obtain multiple challenges
under multiple different public keys.

Theorem 1 (Th. 4.1 [BBM00]). Let Π = (KGen,Enc,Dec) be a PKE scheme
that provides x-CPA security with x ∈ {OW, IND}. Then, it holds that:

Advpke-x-cpa
Π,A (λ) ≥ 1

q ¡ n
¡ Advn-pke-x-cpa

Π,A (Ν),

where n is the number of public keys and A makes at most q queries to any of
its n challenge oracles.

Although the loss imposed by the reduction in Theorem 1 can be significant
when used in a general multi-challenge and multi-user setting, in our application
we only have cases where n = 1 and small q (q = 5 at most), or vice versa (i.e.,
q = 1 and n = 5 at most) thus tightness in a concrete setting is preserved.
Finding failing ciphertexts and injectivity. For the QROM security proof
we will need the following two definitions from [BHH+19].

Definition 3 (ξ-injectivity). A PKE Π is called ξ-injective if

– Π is deterministic and

Pr[(pk, sk)← KGen(λ) :M 7→ Enc(pk,M) is not injective ] ≤ ε.

– Π is non-deterministic with randomness space R and

Pr

[
(pk, sk)← KGen(λ),

M,M ′←$M, r, r′←$R
: Enc(pk,M ; r) = Enc(pk,M ′; r′)

]
≤ ε.

Definition 4 (Finding failing ciphertexts). For a deterministic PKE, the
FFC-advantage of an adversary A is defined as

Advpke-ffc
Π,A (Ν) := Pr

[
Exppke-ffc

Π,A (Ν) = 1
]
,

where the experiment Exppke-ffc
Π,A is given in Figure 4.

8



Exp. Expkem-ind-cca
KEM,A (Îť)

(pk, sk)← KGen(λ)

(C∗, k0)← Encaps(pk), k1 ←$K
b←$ {0, 1}
b′ ← ADecaps(sk,·)(pk, C∗, kb)

if b = b′ then return 1 else return 0

Fig. 5. KEM-IND-CCA security experiment for KEM.

Key-encapsulation mechanism. A key-encapsulation mechanism (KEM)
scheme KEM with key space K consists of the three PPT algorithms
(KGen,Encaps,Decaps): KGen(Îť), on input security parameter Îť, outputs public
and secret keys (pk, sk). Encaps(pk), on input pk, outputs a ciphertext C and
key k. Decaps(sk, C), on input sk and C, outputs k or {⊥}.
Correctness of KEM.We call a KEM δ-correct if for all λ ∈ N, for all (pk, sk)←
KGen(λ), for all (C, k)← Enc(pk), we have that

Pr[Dec(sk, C) 6= k ] ≤ δ.

KEM-IND-CCA security. We say a KEM KEM is KEM-IND-CCA-secure if
and only if any PPT adversary A has only negligible advantage in the following
security experiment. First, A gets an honestly generated public key pk as well
as a ciphertext-key pair (C∗, kb), for (C∗, k0) ← Encaps(pk), for k1←$K, and
for b←$ {0, 1}. A has access to a decapsulation oracle Dec(sk, ·) and we require
that A never queries Decaps(sk, C∗). Eventually, A outputs a guess b′. Finally,
if b = b′, then the experiment outputs 1.

Definition 5. For any PPT adversary A, the advantage functions

Advkem-ind-cca
KEM,A (Îť) :=

∣∣∣∣Pr[Expkem-ind-cca
KEM,A (Îť) = 1

]
− 1

2

∣∣∣∣,
is negligible in Îť, where the experiment Expkem-ind-cca

KEM,A (Îť) is given in Figure 5 and
KEM is a KEM as above.

2.2 Identity-Based Encryption

An identity-based encryption (IBE) scheme IBE with identity space ID and mes-
sage spaceM consists of the PPT algorithms (KGen,Ext,Enc,Dec): KGen(Îť) on
input security parameter Îť, outputs main public and secret keys (mpk,msk).
Ext(msk, id) on input identity id ∈ ID, outputs an identity secret key skid .
Enc(mpk, id ,M) on input mpk, id ∈ ID, and message M ∈ M, outputs a ci-
phertext C. Dec(skid , C) on input skid and C, outputs M ∈M∪ {⊥}.
Correctness of IBE. Analogous to [HHK17a] we define δ-correctness of an IBE
IBE for any id ∈ ID as

E

[
max
M∈M

Pr[C ← Enc(mpk, id ,M) : Dec(skid , C) 6=M ]

]
≤ δ(λ),

9



where the expected value is taken over all (mpk,msk) ← KGen(λ) and skid ←
Ext(msk, id).

IBE-sIND-CPA security of IBE. We say an IBE scheme IBE is IBE-sIND-
CPA-secure if and only if any PPT adversary A has only negligible advantage
in the following security experiment. First, A outputs the target identity id∗

and, subsequently, gets an honestly generated main public key mpk. During the
experiment, but after providing id∗, A has access to a secret-key extraction
oracle Ext(msk, ¡) where we require that A never queries an identity secret key
for id∗. At some point, A outputs equal-length messages (M0,M1) and receives
a challenge ciphertext C∗ ← Enc(mpk, id∗,Mb), for b←$ {0, 1}. Eventually, A
outputs a guess b′; if b = b′, then the experiment outputs 1. The experiment is
depicted in Figure 6.

Definition 6. For any PPT adversary A, the advantage function

Advibe-sind-cpa
IBE,B (Îť) :=

∣∣∣∣Pr[Expibe-sind-cpa
IBE,A (Îť) = 1

]
− 1

2

∣∣∣∣ ,
is negligible in Îť, where the experiment Expibe-sind-cpa

IBE,A (Îť) is given in Figure 6 and
IBE is an IBE scheme.

Exp. Expibe-sind-cpa
IBE,A (Îť)

id∗ ← A(λ)

(mpk,msk)← KGen(λ)

(M0,M1)← AExt(msk,·)(mpk)

b←$ {0, 1}
C∗ ← Enc(mpk, id∗,Mb)

b′ ← AExt(msk,·)(C∗)

if b = b′ then return 1 else return 0

Fig. 6. IBE-sIND-CPA experiment for IBE scheme IBE.

Îł-spreadness of IBE. In order to prove our Bloom filter KEM CCA-secure in
Section 5, we need an additionally property of the underlying IBE scheme which
essentially guarantees that honestly generated IBE ciphertexts have large-enough
min-entropy.

Definition 7 (γ-Spreadness of IBE). For all Ν ∈ N, an IBE scheme IBE is γ-
spread, if for any (mpk, ·)← KGen(λ), any identity id ∈ ID, any message M ∈
M, any C ∈ C, and r←$R, where C and R are the ciphertext and randomness
spaces of IBE, respectively, we have that Pr[C = Enc(mpk, id ,M ; r)] ≤ 2−γ holds,
where the probability is taken over the random coins of KGen.

10



3 CCA Security from Non-Negligible Correctness Errors

In this section, we present our approaches to generically achieve CCA secure
KEMs in the (Q)ROM with negligible correctness error when starting from an
OW-CPA or IND-CPA secure PKE with non-negligible correctness error. We start
by discussing the definitions of correctness errors of PKE and KEMs. Then,
we present a generic transform based on the direct product compiler of Dwork
et al. [DNR04] and revisit certain FO transformation variants from [HHK17a]
(in particular the T and U transformations), their considerations in the
QROM [BHH+19] and their application with the direct product compiler. As a
better alternative, we analyze the non-black-box use of the previous technique
yielding transformation T?, that combines the direct product compiler with the
T transformation. Finally, we provide a comprehensive comparison of the two
approaches.

3.1 On the Correctness Error

In this work, we use the δ-correctness for PKEs given by HHK in [HHK17a]. With
this definition, particularly bad keys in terms of correctness error only contribute
a fraction to the overall correctness error as it averages the error probability over
all key pairs: if there are negligible many keys with a higher correctness error,
then those keys do not really contribute to the overall correctness error. At the
same time this definition is tailored, via maxing over all possible messages, to the
security proofs of the FO-transforms where an adversary could actively search
for the worst possible message, in order to trigger decryption failure. As also
done by Dwork et al. [DNR04], we explicitly write the correctness error as a
function in the security parameter:

Definition 8. A PKE Π is δ(¡)-correct if

E

[
max
M∈M

Pr[C ← Enc(pk,M) : Dec(sk, C) 6=M ]

]
≤ δ(λ),

where the expected value is taken over all (pk, sk)← KGen(λ).

It will be important for our transform to make explicit that the correctness error
depends on the security level, as this allows us to chose a function `(¡) such that
δ(λ)`(λ) ≤ 2−λ. We will often just write δ = δ(λ) and ` = `(λ) for simplicity.

An alternative but equivalent definition, as used in [HHK17a], can be given
in the following form: a PKE Π is called δ(¡)-correct if we have for all (possibly
unbounded) adversaries A that

Advcor
Π,A(Ν) = Pr

[
Expcor

Π,A(Ν) = 1
]
≤ δ(λ),

where the experiment is given in Figure 7. If Π is defined relative to a random
oracle H, then the adversary is given access to the random oracle and δ is ad-
ditionally a function in the number of queries qH, i.e., the bound is given by

11



Exp. Expcor
Π,A(Ν)

(pk, sk)← KGen(λ)

M ← A(pk, sk)

if M 6= Dec(sk,Enc(pk,M)) then return 1 else return 0

Fig. 7. Correctness experiment for PKE.

≤ δ(λ, qH). We note that in [BS20] an alternative definition of correctness was
proposed, where the adversary does not get access to sk and the adversary’s
runtime is bounded. With this change, it can be run as part of the IND-CCA
experiment which does not change the power of the IND-CCA adversary and ad-
ditionaly removes a factor qH from the correctness error and advantage analysis.
In particular, one can obtain an upper bound for IND-CCA security of a scheme
via the correctness error.

We recall, for completeness, the definition of correctness error, here denoted
as DNR-δ-correctness (from Dwork-Naor-Reingold), used by Dwork et al.:

Definition 9 (Def. 2, Def. 3 [DNR04]). A PKE Π is

– DNR-δ(·)-correct if we have that

Pr[Dec(sk,Enc(pk,M)) 6=M ] ≤ δ(λ),

where the probability is taken over the choice of key pairs (pk, sk)← KGen(λ),
M ∈M and over the random coins of Enc and Dec.

– DNR-(almost-)all-keys δ(·)-correct if for all (but negligible many) keys
(pk, sk)← KGen(λ), we have that

Pr[Dec(sk,Enc(pk,M)) 6=M ] ≤ δ(λ),

where the probability is taken over the choice ofM ∈M and over the random
coins of Enc and Dec.

Correctness error in this sense still allows bad key pairs that potentially have an
even worse error but it is not suited for our security proofs as the probability
is also taken over M ←$M. Recently Drucker et al. [DGKP20] introduced the
notion of message agnostic PKE and showed that all the versions of BIKE, a
2nd round candidate in the NIST PQC, are message-agnostic: in such a PKE,
the probability that, given (sk, pk), the encryption of a message M ∈ M cor-
rectly decrypts is independent of the message M ∈M itself. For such PKEs the
definitions of δ-correctness and DNR-δ-correctness coincide (Cor. 1 [DGKP20]).

3.2 Compiler for Immunizing Decryption Errors

Now we present two variants of a compiler Cp denoted Cp,d (for deterministic
schemes) and Cp,r (for randomized schemes) which is based on the direct prod-
uct compiler by Dwork et al. [DNR04]. We recall that the idea is to take a PKE

12



Π ′.KGen′(λ, `)

// if Cp,r

return Π.KGen(Ν)

// if Cp,d

for i ∈ [`]

(pki, ski)← Π.KGen(λ)

pk := (pk1, . . . , pk`)

sk := (sk1, . . . , sk`)

return (pk, sk)

Π ′.Enc′(pk,M)

for i ∈ [`]

// if Cp,r

ri ←$Π.R
Ci ← Π.Enc(pk,M ; ri)

// if Cp,d

Ci ← Π.Enc(pki,M)

C := (C1. . . . , C`)

return C

Π ′.Dec′(sk, C)

C := (C1. . . . , C`)

for i ∈ [`]

// if Cp,r

M ′i := Π.Dec(sk, Ci)

// if Cp,d

M ′i := Π.Dec(ski, Ci)

return maj(M ′1, . . . ,M
′
`)

Fig. 8. Compilers Cp,d and Cp,r.

scheme Π = (KGen,Enc,Dec) with non-negligible correctness error δ (and ran-
domness space R in case of randomized schemes) and output a PKE scheme
Π ′ = (KGen′,Enc′,Dec′) with negligible correctness error δ′ (and randomness
space R′ := R`, for some ` ∈ N, in case of a randomized schemes). We present a
precise description of the compilers in Figure 8. Note that in Dec′, the message
that is returned most often by Dec is returned";"""date"",""2020-12-11T15:54:12Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2020-12-11T15:54:12Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.21 (TeX Live 2020) kpathsea version 6.3.2""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2020-12-11T15:54:12Z""
""created"",""2020-12-11T15:54:12Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-12-11T15:54:12Z""
""resourceName"",""1548.pdf""
""Author"",""""
""producer"",""pdfTeX-1.40.21""
""pdf:docinfo:producer"",""pdfTeX-1.40.21""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""14"",""5"",""17"",""0"",""25"",""11"",""18"",""14"",""10"",""3"",""44"",""20"",""25"",""43"",""19"",""38"",""31"",""41"",""5"",""3"",""4"",""12"",""12"",""28"",""38"",""33"",""7"",""10"",""11"",""24"",""2"",""0"",""0"",""0"",""0"",""0"",""0"",""7"",""43"",""35"",""47"",""59"",""52"",""49"",""32"",""14"",""1"",""1"",""20"",""13"",""13"",""23"",""0"",""19"",""10""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2020-12-11T15:54:12Z""
""Last-Modified"",""2020-12-11T15:54:12Z""
""dcterms:modified"",""2020-12-11T15:54:12Z""
""title"",""""
""Last-Save-Date"",""2020-12-11T15:54:12Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2020-12-11T15:54:12Z""
""meta:save-date"",""2020-12-11T15:54:12Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.21 (TeX Live 2020) kpathsea version 6.3.2""
""Content-Length"",""864823""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""57""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""2332"",""2769"",""2837"",""2689"",""2251"",""2261"",""1709"",""1674"",""1719"",""1570"",""2145"",""1797"",""2384"",""1921"",""1831"",""1880"",""2521"",""1975"",""2190"",""2221"",""2140"",""2683"",""2521"",""2017"",""2012"",""1962"",""1769"",""2167"",""2176"",""1930"",""2212"",""2481"",""2199"",""2597"",""2706"",""2702"",""2811"",""2788"",""2826"",""2124"",""1370"",""1834"",""1972"",""1562"",""1297"",""1438"",""2210"",""2285"",""2575"",""433"",""1070"",""766"",""775"",""1454"",""1886"",""1411"",""762""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-12-11T15:54:12Z""
";https://scholar.google.ch/scholar?start=750&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098743-59;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Smart contracts are likely to have limited application;Oxford Analytica ; Emerald Expert Briefings, 2020  emerald.com;;"… and international laws. Since the external data required are not published on the

blockchain itself, the smart contract cannot be activated in some cases. 'Oracles'

have been introduced to address this problem. These are data …";;null;null;;;;https://scholar.google.ch/scholar?start=600&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098848-297;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;A hierarchical identity-based security for delay tolerant networks using lattice-based cryptography;G Srivastava, R Agrawal, K Singh, R Tripathi… ; PeertoPeer Networking …, 2020  Springer;;"… In Crypto 84 conference, Adi Shamir pioneered the idea of identity-based cryptosystem [13 … Many

other HIBC based security schemes were proposed for different networks based on

computationally hard problems on bilinear maps, with and without random oracle models [18 …";Cité 1 fois;Les 3 versions;null;;;;https://scholar.google.ch/scholar?start=840&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098848-300;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Attribute-Based Access Control for Smart Cities: A Smart Contract-Driven Framework;Y Zhang, M Yutaka, M Sasabe… ; IEEE Internet of Things …, 2020  ieeexplore.ieee.org;;"… types. The authors in [31] also proposed a CapBAC- like scheme to manage access

control for data sharing in IoT systems, where oracles are used to connect blockchain,

data hosts, and users for data accessing. Another CapBAC …";Cité 2 fois;Les 3 versions;[PDF] arxiv.org;https://arxiv.org/pdf/2009.02933;"
1

Attribute-Based Access Control for Smart Cities: A
Smart Contract-Driven Framework

Yuanyu Zhang, Member, IEEE, Mirei Yutaka, Masahiro Sasabe, Member, IEEE, and Shoji Kasahara, Member,
IEEE

Abstract—Efficient and reliable access control in smart cities
is critical for the protection of various resources for decision
making and task execution. Existing centralized access control
schemes suffer from the limitations of single point of failure, low
reliability and poor scalability. This paper therefore proposes a
distributed and reliable access control framework for smart cities
by combining the blockchain smart contract technology and the
Attribute-Based Access Control (ABAC) model. The framework
consists of one Policy Management Contract (PMC) for managing
the ABAC policies, one Subject Attribute Management Contract
(SAMC) for managing the attributes of subjects (i.e., entities
accessing resources), one Object Attribute Management Contract
(OAMC) for managing the attributes of objects (i.e., resources
being accessed), and one Access Control Contract (ACC) for
performing the access control. To show the feasibility of the
proposed framework, we construct a local private Ethereum
blockchain system to implement the four smart contracts and
also conduct experiments to evaluate the monetary cost as well
as to compare the proposed framework with an existing Access
Control List (ACL)-based scheme. The experimental results show
that although the proposed scheme consumes more money than
the ACL-based scheme at the deployment stage, it introduces less
monetary cost during the system running especially for large-
scale smart cities.

Index Terms—Smart cities, attribute-based access control,
blockchain, smart contract.

I. INTRODUCTION

A. Research Problem

THANKS to the rapid development of communication and
manufacturing technologies, the Internet of Things (IoT)

has been expanding at an unprecedented speed in last decades
[2]. Smart city, which brings intelligence to various aspects of
our life such as healthcare, logistic and transportation, has been
recognized as a representative IoT application. To actualize
the vision of smart cities, a huge amount of resources (e.g.,
sensors, actuators and data) need to be deployed in cities to
facilitate decision making and task execution. These resources
help make our life increasingly intelligent and convenient,
while their vulnerability to unauthorized access puts our
property and safety in danger [3]–[5].

Access control has been regarded as an effective solution
to prevent unauthorized resource access and has found var-
ious applications in smart cities [6], [7]. One typical and
specific example is the access control in smart healthcare,

A preliminary version of this paper appeared in [1], presented at the
IEEE Global Communications Conference (GLOBECOM), Hawaii, USA, in
2019.

Y. Zhang, M. Yutaka, M. Sasabe and S. Kasahara are with the Graduate
School of Science and Technology, Nara Institute of Science and Technology,
Ikoma, Nara, Japan. E-mail:yutaka.mirei.yj7@is.naist.jp, {yy90zhang, m-
sasabe,kasahara}@ieee.org.

where access to electronic health records of citizens is strictly
controlled to avoid leakage and misuse of private information
[8]. Another example is the access control in smart building,
where electronic locks and keys form a smart access control
system [9]. Each smart key stores permissions to open a list of
locks. Apart from smart healthcare and smart building, access
control has also found applications in other systems, like smart
parking and logistics [10]. To summarize, access control plays
a significantly important role in securing various aspects of
smart cities.

Each sub-system in smart cities, like health, education and
transportation, has its own access control system. As a result,
it is extremely difficult to implement conventional centralized
and unified access control in smart cities, as the centralized
access control server can easily become a bottleneck [11]–
[16]. Also, the server itself turns out to be a single point of
failure and would sabotage the whole access control system
once it is destroyed by man-made or natural disasters. More
importantly, centralization renders the access control system
vulnerable to attacks, since attackers may easily compromise
the whole system by attacking the server only. As per above,
access control in smart cities needs to be decentralized and
trustworthy (i.e., robust to attacks) to cope with the large-scale
and distributed nature.

Apart from being decentralized and trustworthy, access con-
trol in smart cities also needs to be dynamic. This means that
access control systems should be able to automatically adapt
to the dynamically changing access context information, like
time, location and situations. For example, normally permitted
access to a smart building should be prohibited when the
building is in a fire accident. Access to an electronic health
record should be restricted to requests from only a certain IP
address scope. If the IP address is beyond the scope, the access
request must be denied.

Another critical requirement of access control in smart cities
is that it must be sufficiently fine-grained to achieve high
flexibility and accuracy. For example, in a smart healthcare
scenario, a general policy may be ”Doctors can view the
record of Patient A.” However, this policy is too coarse
to accurately control the access requests, because there are
different types of doctors and maybe only a certain type
(e.g., psychiatrists) is allowed to view the record, or even
more strictly, only the psychiatrists in charge of Patient A can
view the record. Smart cities usually contain various objects
(i.e., resources to be accessed) with different access control
requirements and subjects (i.e., entities sending access request)
with different attributes. Thus, fine-grained is one of the must-
satisfy requirements for the access control in smart cities.

ar
X

iv
:2

00
9.

02
93

3v
1 

 [
cs

.C
R

] 
 7

 S
ep

 2
02

0



2

In light of the above, this paper aims to design a decen-
tralized, trustworthy, dynamic and fine-grained access control
scheme to prevent unauthorized access to IoT resources in
smart cities.

B. Research Methods

Although traditional distributed access control schemes
(e.g., [17] and [18]) are able to meet the distributed require-
ment, they can hardly guarantee the trustworthiness. This
motivates researchers to apply the highly promising blockchain
technology for decentralized and trustworthy access control
[1], [19]–[36]. Blockchain, at its core, is a distributed database
managed over a Peer-to-Peer (P2P) network [37], [38]. The
integrity and authenticity of data are verified by the majority
of the network nodes, thus creating a tamper-resistant database.
Current blockchain realizations like Ethereum [38] also sup-
port distributed and tamper-resistant computing through the
introduction of smart contract functionality. Thus, by storing
access control policies and implementing access control logic
on the blockchain, we can achieve decentralized and trustwor-
thy access control for smart cities.

Classical access control models mainly include Access
Control List (ACL), Role-Based Access Control (RBAC),
Capability-Based Access Control (CapBAC) and Attribute-
Based Access Control (ABAC), among which ABAC is the
most promising one to achieve dynamic and fine-grained
access control. This is because ABAC introduces context
information and also the attributes of subject and objects into
its access control policies. By adding more subject attributes,
object attributes and context information into policies, we can
greatly improve the dynamicity and granularity of ABAC.
In addition to dynamicity and fine granularity, ABAC offers
several other advantages in smart cities. First, ABAC enables
more accurate access control in smart cities than other mod-
els by including sufficient attributes. Second, ABAC enables
access control from a larger set of subjects to a larger set
of objects without specifying individual relationships between
each subject and each object. Third, ABAC reduces the burden
of maintenance, as access policies can be changed by simply
changing the attribute values without the need to change the
underlying subject-object relationships.

Motivated by the benefits of the blockchain technology and
ABAC model, we propose a novel blockchain-based ABAC
framework in this paper. Each ABAC policy is responsible
for the access control between a set of objects and a set
of subjects, i.e., many-to-many access control. The core idea
of the proposed framework is to store the attributes, policies
and access control logic in smart contracts. More specifically,
the proposed framework consists of one Policy Management
Contract (PMC), one Subject Attribute Management Contract
(SAMC), one Object Attribute Management Contract (OAMC)
and one Access Control Contract (ACC). The SAMC, OAMC
and PMC are used to store and manage (e.g., update, add and
delete) the attributes of subjects, the attributes of objects and
the ABAC policies, respectively. When receiving the access
request from a subject, the ACC retrieves the corresponding
policy, subject attributes and object attributes from the PMC,

SAMC and OAMC, respectively, to perform the access control.
A prototype system on a local private Ethereum blockchain
network was constructed to demonstrate the feasibility of the
proposed framework. Extensive experiments were conducted
to evaluate the monetary cost of the proposed framework.
Comparisons with the existing ACL-based framework in [26]
are also conducted to show the superiority of our framework.

C. Contributions and Innovation
Some recent work has been done to investigate blockchain-

based ABAC. The authors in [19] proposed a smart contract-
based ABAC scheme, which stores the URLs of policies on the
blockchain while leaving the policies themselves in external
databases. To access an object, subjects send the URL of the
corresponding policy to a smart contract, which then retrieves
the policy from the external databases and performs the access
control. Although the storage overhead can be reduced to some
extent by storing only the policy URLs on the blockchain,
the policies face a high risk of being falsified, which may
result in untrustworthy access control. Besides, the authors
provided no implementations to verify the feasibility of the
scheme. To address this issue, the authors in [20] proposed a
new ABAC scheme, which stores the policies and attributes
in smart contracts to achieve trustworthy access control. In
[21], instead of storing policies in smart contracts, the authors
transfer each policy into a smart contract. Although these
two schemes demonstrate the feasibility of blockchain-based
ABAC schemes, they follow the same idea of one-to-many
access control, i.e., each policy is associated with one object
and responsible for the access requests of many subjects. This
may incur a huge burden of policy management, especially in
large-scale IoT systems like smart cities.

Compared with existing blockchain-based ABAC schemes,
the proposed ABAC framework have the following major
contributions and innovation.
• Compared with [19], the proposed ABAC framework can

greatly improve the trustworthiness by storing ABAC
policies and attributes instead of their URLs on the
blockchain. In addition, the proposed ABAC framework
follows the standard XACML architecture [39], while
the framework in [19] does not. More importantly, we
provide implementations and experiments to illustrate the
feasibility and performances of the proposed framework.

• The idea of the proposed ABAC framework differs
greatly from the one in [21], where each policy has to
be hardcoded into a smart contract. This incurs a huge
burden of coding when a large number of policies need
to be added. In our framework, this can be easily realized
by simply adding the policies into the blockchain without
any coding.

• The most relevant framework is the one in [20], which
also follows the idea of storing policies, attributes and
logic on the blockchain. The main difference is that each
policy in [20] enables only one-to-many access control,
while our policies enables many-to-many access control.
This can greatly reduce the burden of policy management
and also storage cost, especially in smart cities with a
huge amount of subjects and objects.



3

The remainder of the paper is organized as follows. Sec-
tion II introduces the related work and Section III presents
the proposed framework. We provide the implementation in
Section IV, the monetary cost evaluation in Section V and
finally conclude this paper in Section VI.

II. RELATED WORK

A. Blockchain Technology

The blockchain technology, the core of modern cryptocur-
rency systems like the Bitcoin [37], is essentially a distributed
database managed over a Peer-to-Peer (P2P) network. All
peers in the network maintain the same copy of the blockchain
and synchronize to update the blockchain. A blockchain con-
sists of a sequence of blocks, each containing a collection of
transactions recording the remittance information (e.g., sender,
receiver and amount). These blocks are chained together by
each storing the cryptographic hash of its previous block. The
hash of a block is generated by a process called mining, which
requires a huge amount of calculations. Suppose an attacker
manages to tamper with the transactions in a certain block, he
has to re-calculate the hash values of this block and also its
subsequent blocks. This is considered impossible in general
and thus makes blockchain a tamper-resistant database.

Although originally developed as a distributed database,
blockchain has currently advanced to a distributed computing
platform thanks to the emergence of a new functionality called
smart contract. The most representative realization of such
novel blockchain is the Ethereum [38]. An Ethereum smart
contract is an executable program, which, like transactions, is
also stored (indirectly) on the blockchain. A smart contract
consists of variables as its states and functions called Appli-
cation Binary Interfaces (ABIs) to view and change the states
[40]. To execute a smart contract, a transaction needs to be
fired and broadcast to the P2P network. All peers receiving
this transaction will execute the smart contract to ensure the
validity of execution results. Thus, by implementing the smart
contract functionality, the blockchain technology can further
achieve distributed and tamper-resistant computing.

B. Blockchain-based Access Control

To deal with the access control issue in a smart home, a
Bitcoin-like blockchain was adopted in [22] to design an ACL-
based access control scheme. A blockchain was implemented
locally in each home to maintain an ACL, where each entry
corresponds to an internal object and records the allowed
access rights of a subject (internal or external). The access
control inside each home is performed by an internal miner,
which acts as the gateway to receive access requests from
subjects. However, the existence of the miner results in cen-
tralized access control inside each home. Besides, the mining
process is eliminated by the miner, which makes tampering
with the ACL possible and thus results in untrustworthy access
control. Based on the Bitcoin blockchain, the authors in [23]
proposed an ABAC scheme, which stores ABAC policies in
Bitcoin transactions and serves as a policy repository for
existing ABAC solutions. To update the policy inside a certain
transaction, administrators can append to the transaction a new

transaction with updated information. In addition, administra-
tors can simply spend the coins contained in a transaction
to delete the policy inside the transaction. The authors in
[24] proposed a similar Bitcoin-based ABAC scheme, while
the policies are encrypted for privacy and security, which is
different from [23]. A Bitcoin-based CapBAC scheme was
designed in [25], which stores capability tokens (i.e., special
data structures that record the assigned access rights of a
certain subject to one or more objects) in Bitcoin transactions.
A subject can transfer his/her capability token to another
subject through transactions, which is similar to the transfer
of bitcoins. When accessing an object, subjects must prove
their ownership of the corresponding capability tokens (i.e.,
the access rights) to the object owner.

The above schemes are all based on the Bitcoin-like
blockchains, while smart contract-based access control has
attracted more attention recently. For example, the authors in
[26] applied Ethereum smart contracts to store ACLs in order
to propose an ACL-based access control framework. In the
framework, each subject-object pair uses one smart contract
to implement the related access control. When accessing an
object, a subject sends a transaction, which contains the
required access information, to execute the corresponding
smart contract. After the execution, the smart contract will
automatically return the results (denial or permission) to
both the subject and object. However, since one contract
is responsible for the access control of only one subject-
object pair, this scheme suffers from heavy monetary cost
of deploying contracts, especially in large-scale IoT systems.
The authors in [27] extended the above framework with slight
modification. The authors in [28] proposed a CapBAC scheme,
which applies a smart contract to store the capability tokens
and capability delegation tokens that record the delegation
information among the subjects. These tokens are managed in
a tree form and serve as tamper-resistant references to help
object owners decide whether a subject has certain access
rights. This scheme was extended in [29], where the authors
used a delegation graph to replace the delegation tree in [28].
In addition, the authors designed only one type of tokens rather
than two types. The authors in [30] also proposed a CapBAC-
like scheme to manage access control for data sharing in
IoT systems, where oracles are used to connect blockchain,
data hosts, and users for data accessing. Another CapBAC-
like scheme was proposed in [31] for handling the access
control in information-centric networks. In [32], an RBAC
scheme was designed, where a smart contract was deployed to
maintain the roles assigned to each user in an RBAC model,
such that any service provider can verify the users’ ownership
of roles when providing services. An ABAC scheme was
proposed in [19], where the URL links of ABAC policies
are stored on the blockchain. In addition, a smart contract
is deployed to receive access requests from the subjects and
then perform the access control. However, the main limitation
of this scheme is storing the policies and attributes in external
databases, which makes them vulnerable to tampering attacks.
As a result, the trustworthiness of the policies and the attributes
cannot be guaranteed. Besides, the authors did not provide
implementations, and thus the feasibility of the proposed



4

PMC

SAMCOAMC

ACC

Subject[0x3d03…]
Name: Alice
Org.: NAIST
Dep.: IS
Role: Student

Object [0x272a…]
Name: Camera
Org.: NAIST
Dep.: IS
Place: Room1

Policy[1]

Subject
Name: “”

Org.: NAIST

Dep.: IS
Role: Student

Object
Name: “”

Org.: NAIST

Dep.: IS
Place: “”

Action
Read: True

Write: False

Execute:

False

Context
Mode: 1
startTime: 
endTime: 

Fig. 1. The proposed ABAC framework.

scheme is not clear. Another ABAC scheme was also proposed
in [33], while the object attributes were not considered and
only one-to-many access control was realized. Other ABAC
schemes were also proposed in [1], [20], [21] as introduced
in Section I.

Access control schemes based on other blockchain real-
izations have also been designed. For example, an ABAC
framework based on the permissioned Hyperledger Fabric
blockchain was proposed in [34], while, different from the
schemes in [1], [20], only the attributes are stored on the
blockchain and no smart contracts are used for processing
access requests. The authors in [35] combined attribute-based
encryption and blockchain to propose another ABAC-like
scheme based on a multi-layer blockchain architecture. In [36],
a conceptual design of blockchain-based ABAC was provided,
while the authors provided no implementations.

III. PROPOSED ABAC FRAMEWORK

A. Smart Contract System

Fig. 1 illustrates the proposed ABAC framework, which is
composed of four smart contracts, i.e., SAMC, OAMC, PMC
and ACC. The SAMC, OAMC and PMC are used to store and
manage (e.g., update, add and delete) the attributes of subjects,
the attributes of objects and the ABAC policies, respectively.
The ACC performs the access control by interacting with the
other three smart contracts. This paper considers a smart cam-
pus scenario as part of a smart city. Note that the application
of the framework is not limited to smart campus but can be
extended to the whole smart city by properly defining the
policies and attributes. We introduce the details of the four
smart contracts in what follows.

1) Subject Attribute Management Contract (SAMC): The
SAMC is responsible for the storage and management of the
subject attributes in the smart campus. The SAMC is usually
deployed by the administrators of subjects on the blockchain
and only the administrators have permissions to execute it.
In the case of a smart campus, the administrators can be the
executive office if the subjects are students and staffs, while

TABLE I
EXAMPLES OF SUBJECT AND OBJECT ATTRIBUTES

SubjectList[0x3d03...] ObjectList[0x272a...]
Name:“Alice” Name: “Camera”
Org.: “NAIST” Org. “NAIST”
Dep.: “IS” Dep.: “IS”
Lab.: “LSM” Lab.: “LSM”
Role: “student” Place: “Room1”
Others: “” Others: “”

if the subjects are IoT devices, the administrators can be their
owners. To distinguish between different subjects in the sys-
tem, each of them is assigned a unique identifier (i.e., ID). In
addition, each ID is linked with multiple attributes to indicate
that the subject with that ID possesses those attributes. We use
Ethereum account addresses (e.g., the 0x3d03... in Table I) as
such ID information throughout this paper. Table I shows some
examples of the subject attributes, such as the organization
Org. (e.g., Nara Institute of Science and Technology: NAIST),
department Dep. (e.g., Information Science: IS) and laboratory
Lab. (e.g., Large-scale Systems Management: LSM) to which
the subject belongs as well as the Role (e.g., student and
staff) of the subject. In addition to the storage of the subject
attributes, the ABIs of subjectAdd() and subjectDelete() are
also provided to add/update and delete the subject attributes,
respectively.

2) Object Attribute Management Contract (OAMC): Sim-
ilar to the SAMC, the role of the OAMC is storing and
managing the attributes of the objects, which can be ex-
ecuted only by the object administrators. Each object also
has multiple attributes linked with its ID, i.e., an Ethereum
account address (e.g., the 0x272a... in Table I) in this paper.
This paper considers some examples of the object attributes
in Table I, including the organization Org. (e.g., NAIST),
department Dep. (e.g., IS) and laboratory Lab. (e.g., LSM) to
which the object belongs as well as the Place (e.g., Room1)
where the object is placed. In addition to the storage of the
object attributes, the ABIs of objectAdd() and objectDelete()
are also provided to add/update and delete the object attributes,
respectively.

3) Policy Management Contract (PMC): The PMC is re-
sponsible for the storage and management of the ABAC
policies defined in this paper. Similar to the SAMC and
OAMC, only the administrators (e.g., the object owners) of
the policies have permissions to execute the PMC. A policy
is a combination of a set SA of subject attributes, a set
OA of object attributes, a set A of actions and a set C of
context information. This combination states that the subjects
with attributes in SA can perform the actions in A on the
objects with attributes in OA under the context in C. For
simplicity, we adopt time as the simple context information for
dynamic access control in this paper. We use three parameters
to represent time, which are Mode, startTime and endTime. The
Mode parameter indicates whether dynamic access control is
used. If the Mode is set to 0, dynamic access control is not
applied. If the Mode is set to 1, dynamic access control is
applied and the parameters startTime and endTime need to be



5

TABLE II
EXAMPLE OF AN ABAC POLICY.

Subject Attributes Object Attributes Action Context
Name: “” Name: “” Read: True Mode: 1
Org.: “NAIST” Org.: “NAIST” Write: True startTime:
Dep.: “IS” Dep.: “IS” Execute: False 1563206776
Lab.: “LSM” Lab.: “LSM” endTime:
Role: “Student” Place: “” 1575483330

further specified to indicate the start time and end time of the
allowed access session. That is, access is allowed only if it is
during the period between the startTime and endTime.

Table II shows an example of the ABAC policy defined
in our framework with SA = {Org.: NAIST, Dep.: IS, Lab.:
LSM, Role: Student}, OA = {Org.: NAIST, Dep.: IS, Lab.:
LSM}, A = {Read, Write} and C = {Mode: 1, startTime:
1563206776, endTime: 1575483330}. Note that the startTime
and endTime are expressed in unixtime format in this example,
which correspond to 5/24/2019 12 : 00 and 5/31/2019 11 :
59, respectively. The policy states that any student belonging
to the LSM laboratory of the IS department of the NAIST
organization can read and write any object at any place of
the same laboratory of the same department and organization
for a specified period of time between 5/24/2019 12 : 00 and
5/31/2019 11 : 59. Unlike the policies in [20], the policies
in our framework are not associated with certain subjects
or objects. Thus, each policy can handle the access control
between multiple objects and multiple subjects, achieving
many-to-many access control. As a result, policy search is
required for the processing of access requests from subjects.

The policies are stored as a list structure in the PMC
and managed by the ABIs of policyAdd(), policyDelete() and
policyUpdate(), respectively. In addition, the ABIs of findEx-
actMatchPolicy() and findMatchPolicy() are also provided for
searching policies. We will introduce these two types of policy
search in Section III-B2 in greater details.

4) Access Control Contract (ACC): The core of the access
control system is the ACC, which is responsible for controlling
the access requests from the subjects to the objects. To execute
the ACC, a transaction that contains the required request
information (e.g., subject ID, object ID and actions) must be
sent to the accessControl() ABI. When the ACC receives the
transaction, it will retrieve the corresponding subject attributes,
object attributes and the policy from the SAMC, OAMC and
PMC, respectively. Based on the attributes and policy, the ACC
decides if the subject is allowed to perform the requested
actions on the object. Finally, such decision results will be
returned to both the subject and object for reference. We will
introduce the access control flow in Section III-B4 in greater
details.

B. Main Functions of the Framework

The proposed ABAC framework provides the following
main functions.

1) Adding, Updating and Deleting Subject/Object At-
tributes: As mentioned in Section III-A, the basic functions
provided by the proposed ABAC framework are adding,
updating and deleting the attributes of the subjects/objects.

For example, to add/update the attributes of a subject, the
subject administrator can send a transaction, which contains
the subject’s ID and the attributes to add/update, to the
subjectAdd() ABI of the SAMC. If the ABI finds a matched
entry for the presented subject ID in the subject list, it will
update the attributes of the subject. Otherwise, the ABI will
create a new entry for the subject ID in the subject list. When
deleting some attributes of a subject, the subject administrator
can send another transaction, which contains the subject’s ID
and attributes to delete, to the subjectDelete() ABI. Examples
of adding, updating and deleting the attributes of an object are
quite similar to the above ones and are thus omitted here.

2) Searching Policies: Because the PMC stores the poli-
cies as a list (i.e., array), we need policy search to delete,
update and retrieve a certain policy. The proposed ABAC
framework provides the ABIs of findExactMatchPolicy() and
findMatchPolicy() to implement two patterns of policy search,
respectively, i.e., search by complete match and search by
partial match.

• Search by Complete Match: This policy search pattern
returns the policies with subject and object attributes
exactly matching the subject and object attributes pro-
vided by the transaction sender. For example, when a
transaction sender searches for the policy as illustrated
in Table II, he/she needs to provide exactly the same
attribute information as listed in Table II. This search
pattern is mainly used for deleting policies.

• Search by Partial Match: Differing from the previous
policy search pattern, this pattern returns a list of indices
of the policies, in which the subject and object attributes
are subsets of those provided by the transaction sender.
Suppose a transaction sender executes this search by
offering a set SA of subject attributes and a set OA of
object attributes. Taking SA and OA as inputs, the search
will return any policy whose subject attribute set SA′ and
object attribute set OA′ satisfy the conditions SA′ ⊆ SA
and OA′ ⊆ OA. The reason is that any found policy can
handle the access request from the subjects with attribute
set SA to the objects with attribute set OA. This search
pattern is mainly used for adding/updating policies and
access control by the ACC.

3) Adding, Updating and Deleting Policies: A policy is
defined as a logical combination of subject attributes, object
attributes, actions and contexts. In general, policy administra-
tors can define more fine-grained policies by including more
attributes, thus achieving more flexible and dynamic access
control. Similar to the attribute management, this framework
also provides functions for policy management, including
adding, updating and deleting policies. When adding a new
policy, the policy administrator first needs to execute the policy
search by partial match (i.e., findMatchPolicy()) to find the
similar policies. When any similar policies are returned, the
administrator then needs to ensure that the new policy to add
does not conflict with any of the returned similar policies. Any
possible conflicts must be resolved by the administrator. After
the conflict resolution, the policy is finally added to the policy
list by the administrator through the policyAdd() ABI of the



6

Block HeaderBlock HeaderBlock Header

SAMC

OAMC

PMCACC
Policy[1]

Subject

Name：

Org.: NAIST

Dep.: IS

Role: Student

Object

Name：

Org.: NAIST

Dep.: IS

Place：

Action
Read: True
Write: False

Execute: False

Object [0x272a…]
Name: Camera
Org.: NAIST
Dep.: IS
Place: Room1

Subject [0x5589…]
Name: Alice
Org.: NAIST
Dep.: IS
Role: Student

1. Send access request 
“Read the camera at 
Room 1@IS@NAIST”

2-1. Get the 
subject’s attributes

3-1. Return the 
subject’s attributes

2-2. Get the 
object’s attributes

3-2. Return the 
object’s attributes

4. Get the policy

5. Return the 
policy

6. Access 
control: 

validating 
access rights

7. Return access 
result

Context
Mode: 1

startTime: …
endTime: … 

Fig. 2. Access control process.

PMC.
Similarly, to update a policy, the administrator also needs

to apply the search by partial match to find the target policy.
Note that other similar policies will also be returned by the
search as well. Conflicts (if any) between the new policy
used for update and the similar policies must be resolved,
after which the target policy is then replaced by the new
one through the policyUpdate() ABI. Note that when existing
policies cover the new ones to add/update, adding/updating
policies is not required, which can reduce the monetary cost
and the storage overhead of the framework. Different from
adding/updating policies, the policy administrator needs to
apply the policy search by complete match to find the target
policy, when deleting a policy. If the target policy is found, the
administrator then deletes it from the policy list by executing
the policyDelete() ABI.

4) Access Control: Access control is the co";"""date"",""2020-09-08T00:50:09Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2020-09-08T00:50:09Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016) kpathsea version 6.2.2""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2020-09-08T00:50:09Z""
""created"",""2020-09-08T00:50:09Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-09-08T00:50:09Z""
""resourceName"",""2009.02933""
""Author"",""""
""producer"",""pdfTeX-1.40.17""
""pdf:docinfo:producer"",""pdfTeX-1.40.17""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""4"",""0"",""0"",""5"",""8"",""0"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2020-09-08T00:50:09Z""
""Last-Modified"",""2020-09-08T00:50:09Z""
""dcterms:modified"",""2020-09-08T00:50:09Z""
""title"",""""
""Last-Save-Date"",""2020-09-08T00:50:09Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2020-09-08T00:50:09Z""
""meta:save-date"",""2020-09-08T00:50:09Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016) kpathsea version 6.2.2""
""Content-Length"",""907849""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""12""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""5094"",""5428"",""5626"",""4567"",""5290"",""4113"",""4137"",""3767"",""4136"",""3247"",""4828"",""7419""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-09-08T00:50:09Z""
";https://scholar.google.ch/scholar?start=840&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098756-90;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Implementation of a strongly robust identity-based encryption scheme over type-3 pairings;H Okano, K Emura, T Ishibashi, T Ohigashi… ; International Journal of …, 2020  jstage.jst.go.jp;;"Page 1. Page 2. International Journal of Networking and Computing 1 Introduction

1.1 Background Public-key encryption (PKE) is an important mechanism for maintaining

security in several organizations. Identity-based encryption …";Autres articles;;[PDF] jst.go.jp;https://www.jstage.jst.go.jp/article/ijnc/10/2/10_174/_pdf;"
International Journal of Networking and Computing – www.ijnc.org, ISSN 2185-2847
Volume 10, Number 2, pages 174–188, July 2020

Implementation of a Strongly Robust Identity-Based Encryption Scheme over Type-3 Pairings

Hiroshi Okano

Tokai University, Japan.

Keita Emura

National Institute of Information and Communications Technology (NICT), Japan.

Takuya Ishibashi

Tokai University, Japan.
National Institute of Information and Communications Technology (NICT), Japan.

Toshihiro Ohigashi

Tokai University, Japan.
National Institute of Information and Communications Technology (NICT), Japan.

Tatsuya Suzuki

University of Tsukuba, Japan.

Received: January 9, 2020
Revised: April 28, 2020
Accepted: June 9, 2020

Communicated by Yasuyuki Nogami

Abstract

Identity-based encryption (IBE) is a powerful mechanism for maintaining security. However, sys-
tems based on IBE are unpopular when compared with those of the public-key encryption (PKE). In
our opinion, one of the reasons is a gap between theory and practice. For example, a generic transfor-
mation of weakly/strongly robust IBE from any IBE has been proposed by Abdalla et al., no robust
IBE scheme is explicitly given. This means that, theoretically, anyone can construct a weakly/strongly
robust IBE scheme by employing this transformation. However, this seems not easily applicable to non-
cryptographers. In this paper, we first introduce the Gentry IBE scheme constructed over Type-3 pairings
by employing the transformation proposed by Abe et al., and second we explicitly give strongly/weakly
robust Gentry IBE schemes by employing the Abdalla et al. transformation. Finally, we show its imple-
mentation result and show that we can add strong robustness to the Gentry IBE scheme with a very few
additional costs. We employ the mcl library to support a Barreto-Naehrig curve defined over the 462-bit
prime. The encryption requires about 5 ms, whereas the decryption requires about 9 ms.

Keywords: Identity-Based Encryption, Implementation, Robustness, Asymmetric Pairings

1This work was done when the fifth author, Tatsuya Suzuki, was a master student at the Tokai University, Japan, and was
a research assistant at the National Institute of Information and Communications Technology (NICT), Japan. He is supported
by a JSPS Research Fellowship for Young Scientists.

174



International Journal of Networking and Computing

1 Introduction

1.1 Background

Public-key encryption (PKE) is an important mechanism for maintaining security in several organizations.
Identity-based encryption (IBE) [52] is an extension of PKE in which an arbitrary string, such as email,
location information, and biometrics information, is considered to be a public key, and is standardized by
the ISO/IEC 18033-5 and IEEE P1363.3. The conventional PKE requires public-key infrastructure systems,
whereas IBE does not require such systems. However, IBE can offer secure systems, which are not achievable
using PKE. For example, IBE can maintain IoT security as revealed by [2,8,40,50]. Micro Focus [41] launched
a secure email service based on IBE and insisted that “IBE can be used to build security systems that are
more dynamic, lightweight, and scalable”.

Further, the security systems based on IBE are not popular when compared with PKE-based systems.
A gap between theory and practice is one of the reasons for the non-universal applicability of IBE. Re-
gardless, several IBE security definitions are proposed, which include indistinguishability against plain-
text/ciphertext attacks (IND-CPA/CCA) [17], selective/adaptive security [15], anonymity against chosen
plaintext/ciphertext attacks (ANON-CPA/CCA) [18], and weak/strong robustness [4,5]. However, software
engineers face challenges while implementing the IBE schemes integrated into the security systems since
these security properties are not easily selected according to the functionalities or models of the systems if
engineers are not familiar with cryptography.

For example, Abdalla et al. [4, 5] introduced robustness which seems attractive to be employed in such
systems. Informally, robustness guarantees that a ciphertext C of a plaintext M encrypted by an identity
ID is not decrypted by a secret key of a different identity ID′ (ID 6= ID′). This causes a problem when the
underlying IBE scheme is anonymous. Here, anonymity indicates that the ID information is not revealed from
C. Although a receiver’s privacy is protected in an anonymous IBE, nobody can recognize the decryption
keys that are to be used, even the corresponding receiver. We remark that, “C is not decrypted” contains
the situation that the decryption algorithm outputs a plaintext M ′ where M 6= M ′. Thus, if a random
string such as password is encrypted, then one may receive M ′ as own password. If the underlying IBE
scheme is robust, then the decryption algorithm outputs a special rejection symbol ⊥ if an inaccurate secret
key is used. Abdalla et al. defined two notions of robustness, weak robustness and strong robustness.
Refer to Section 4 for details. Although robustness seems naturally holds in usual IBE schemes, this it not
true, and is not guaranteed in usual IBE schemes in general. Thus, Abdalla et al. proposed the generic
transformation of weakly/strongly robust IBE from any IBE. That is, anyone can theoretically construct
a weakly/strongly robust IBE scheme by employing this transformation. However, this seems not easily
applicable to non-cryptographers. In addition, no robust IBE scheme is explicitly given in their paper.2

Moreover, it is difficult to select which parameters, e.g., elliptic curves, should be used for implementation
based on a state-of-the-art method for solving the discrete logarithm (DL) problem [12,39] or based on the
type of pairings. These situations may prevent the applicability of IBE.3

1.2 Our Contribution

In this paper, we focus on the robustness [4,5] because no concrete IBE scheme offers robustness. We explicitly
present strongly/weakly robust IBE schemes. Moreover, inspired by [49], we present the implementation
results.

We employ the Gentry IBE scheme [32] as the underlying IBE, which is adaptively IND/ANON-CCA
secure. Because the Abdalla et al. transformation preserves CCA security and anonymity, we can add
weak/strong robustness of the Gentry IBE scheme without detracting the CCA security and anonymity.
Unfortunately, the original Gentry IBE scheme is constructed over Type-1 pairings although the construction
of schemes over Type-3 pairings is the most efficient (refer to Section 2 for details). Thus, we employ the
transformation proposed by Abe et al. [6, 7] to the original Gentry IBE scheme, constructed over Type-3
pairings. Then, we employ the transformation proposed by Abdalla et al. Figure 1 reveals an overview of
the transformations.

2As a remark, they explicitly gave a strongly robust CCA secure Cramer-Shoup PKE scheme in their paper.
3Aoki [9] mentioned that majority of the cryptographic algorithms that guarantee security require assumptions, but it is

sometimes not clearly written.

175



Implementation of a Strongly Robust Identity-Based Encryption Scheme over Type-3 Pairings

The original Gentry IBE scheme

• Type 1
• Adaptively CCA secure
• Adaptively Anonymous

The Gentry IBE scheme (Sec. 4.3)

• Strongly Robust
• Type 3
• Adaptively CCA secure
• Adaptively Anonymous

The Gentry IBE scheme (Sec. 3)

• Type 3
• Adaptively CCA secure
• Adaptively Anonymous

The Gentry IBE scheme (Sec. 4.2)

• Weakly Robust
• Type 3
• Adaptively CCA secure
• Adaptively Anonymous

Abe et al. Transformation

Abdalla et al. Transformation
(For strong robustness)

Abdalla et al. Transformation
(For weak robustness)

Figure 1: Overview of the Transformations

For the implementation of the strongly robust Gentry IBE scheme over Type-3 pairings, we employ the
mcl library [42] that supports Type-3 pairings with the parameters that have been selected by considering
the state-of-the-art for solving discrete logarithm problem [12, 39]. The encryption requires about 5 ms,
whereas the decryption requires about 9 ms.

1.3 Differences from Proceedings Version

An extended abstract appears in the Seventh International Symposium on Computing and Networking
(CANDAR 2019) [45]. After publishing the conference version, the mcl library v1.00 (released on September
30, 2019) supports functions for computing multi-scalar multiplications (mclBnG1 mulVec, mclBnG2 mulVec,
and mclBnGT powVec) that were not employed in our implementation. In this version, we employed these
functions and re-implement IBE schemes (Section 5). In addition to this, we found that our encodings given
in [45] do not work well (See Appendix), and thus we employ the KEM/DEM framework where KEM stands
for key encapsulation mechanism and DEM stands for data encapsulation mechanism. For the DEM part,
we employ AES-GCM and gave new implementation results due to this modification. Moreover, we add an
application of robust IBEs to searchable encryption (Section 6).

2 Bilinear Groups

In this section, we define bilinear groups and types as follows:

Definition 1 (Bilinear Groups) Let p be a λ-bit prime, G1,G2 and GT be the groups of order p; e : G1×
G2 → GT is a bilinear map, and g1 and g2 are generators of G1 and G2, respectively. We require bilinearlity:
for all h1 ∈ G1, h2 ∈ G2, and a, b ∈ Zp, e(ha1 , h

b
2) = e(h1, h2)ab, and non-degeneracy: e(g1, g2) 6= 1 hold.

If G1 = G2, the map e is called symmetric, and we call the setting Type 1. If G1 6= G2, the map e is
called asymmetric. If there is an efficient computable isomorphism ψ : G2 → G1, we call the setting Type
2 (e.g., Miyaji-Nakabayashi-Takano (MNT) curves [43]). If no efficient isomorphism is known between G1

and G2, we call the setting Type 3 (e.g., Barreto-Naehrig (BN) curves [14] or Barreto-Lynn-Scott (BLS)
curves [13]). Alternatively, we use the terms Type-i pairings/curves or Type-i bilinear groups for i = 1, 2, 3.

176



International Journal of Networking and Computing

Currently, constructing schemes in the Type-3 setting is the most efficient. Refer to [31] for details.
From the implementation point of view, Type-3 curves are the most reasonable choice unless there is a
specific reason, e.g., employing symmetric curves as Gap-DH groups [36]. The mcl library implements
a BN curve [14] defined over the 462-bit prime r(z) := 36z4 + 36z3 + 24z2 + 6z + 1 and has the order
p(z) = 36z4 + 36z3 + 18z2 + 6z + 1 where z = 2114 + 2101 − 214 − 1. Currently, this curve is believed to
provide 128-bit security, denoted as BN462 in this paper.

Remark. The symmetric pairing is known as a decisional Diffie-Hellman (DDH) solver. That is, for a tuple
(g, ga, gb, gc) ∈ G4

1, one can check whether c = ab or not by checking whether e(ga, gb) = e(g, gc). However,
in the computational Diffie-Hellman (CDH) problem, computing gab from (g, ga, gb) ∈ G3

1 is still believed to
be difficult. Further, the DDH assumption holds in case of both G1 and G2 in Type-3 bilinear groups, which
we call the symmetric external Diffie-Hellman (SXDH) assumption. We also state that the DDH assumption
holds in G1 and does not hold in G2 in the Type-2 setting, which we call the external Diffie-Hellman (XDH)
assumption.

3 The Gentry IBE scheme over Type-3 Pairings

As mentioned in the previous section, Type-3 pairings are better from an efficiency point of view. Un-
fortunately, the original Gentry IBE scheme is constructed in Type-1 pairings. Thus, in this section, we
introduce the Gentry IBE scheme constructed over Type-3 pairings that is obtained by employing the Abe
et al. transformation [6, 7] to the original Gentry IBE scheme. Before giving that, we define the syntax of
IBE as follows.

Definition 2 (Syntax of IBE) An IBE scheme IBE consists of the following four algorithms, IBE.Setup,
IBE.KeyGen, IBE.Enc and IBE.Dec:

• IBE.Setup(1λ): The setup algorithm takes as an input a security parameter λ ∈ N, and returns a public
parameter params and a master key msk.

• IBE.KeyGen(params,msk, ID): The key extract algorithm takes as input an identity ID and msk, and
returns a secret key skID corresponding to ID.

• IBE.Enc(params, ID,M): The encryption algorithm takes as input params, ID, a plaintext M , and
returns a ciphertext C.

• IBE.Dec(params, skID, C): The decryption algorithm takes as input params, skID, and C, and returns a
plaintext M or a reject symbol ⊥.

Next, we introduce the Gentry IBE scheme over Type-3 pairings as follows. In the construction, public
parameters h1, h2, and h3, and secret keys (hID,1, hID,2, hID,3) are elements on G2 whereas these are elements
on G1 in the original construction.

The Gentry IBE Scheme over Type-3 Pairings:

• IBE.Setup(1λ): Choose a Type-3 bilinear group (G1,G2,GT , e, g1, g2) with λ-bit prime p where g1 and

g2 are generators of G1 and G2, respectively. Choose Îą
$←− Zp and h1, h2, h3

$←− G2, compute g′1 = gα1 ,
and output params = (g1, g

′
1, g2, h1, h2, h3, H) where H : {0, 1}∗ → Zp is a universal one-way hash

function, and msk = Îą.

• IBE.KeyGen(params,msk, ID): For identity ID ∈ Zp, for i = 1, 2, 3 choose rID,i
$←− Zp, compute hID,i =

(hig
rID,i

2 )1/(α−ID) ∈ G2, and output skID = (rID,i, hID,i)
3
i=1.

• IBE.Enc(params, ID,M): Let M ∈ GT be a plaintext to be encrypted. Choose s
$←− Zp, compute

C1 = g′1
s
g−sID1 , C2 = e(g1, g2)s, C3 = Me(g1, h1)−s, β = H(C1, C2, C3), and C4 = e(g1, h2)se(g1, h3)sβ ,

and output C = (C1, C2, C3, C4).

177



Implementation of a Strongly Robust Identity-Based Encryption Scheme over Type-3 Pairings

• IBE.Dec(params, skID, C): Compute β = H(C1, C2, C3). If C4 6= e(C1, hID,2h
β
ID,3)C

rID,2+rID,3β
2 , then

output ⊥. Otherwise, compute M = C3e(C1, hID,1)C
rID,1

2 and output M .

The security of original Gentry IBE scheme relies on the truncated q-ABDHE assumption where ABDHE
stands for augmented bilinear Diffie-Hellman exponent. Since the assumption is defined over Type-1 settings,
we also need to duplicate the assumption via the Abe et al. transformation as follows. Interestingly, we do
not have to duplicate not all elements. We duplicate generators and (gÎą1 , g

Îą
2 ) only.

Definition 3 (The truncated q-ABDHE Assumption over Type-3 Pairings) Let (G1,G2,GT ) be a

Type-3 bilinear groups with Îť-bit prime order p. Let g1, g
′
1 ∈ G1 and g2, g

′
2 ∈ G2 be generators, ι

$←− Zp,

and Z
$←− GT . For all probabilistic polynomial-time adversaries A, we define the advantage AdvABDHE

A (Îť) :=

Pr[A(g1, g
′
1, g2, g

′
2, g

Îą
1 , g

Îą
2 , g

Îą2

2 , . . . , gÎą
q

2 , g′1
Îąq+2

, e(gÎą
q+1

1 , g′2))]−Pr[A(g1, g
′
1, g2, g

′
2, g

Îą
1 , g

Îą
2 , g

Îą2

2 , . . . , gÎą
q

2 , g′1
Îąq+2

, Z)].
We say that the truncated q-ABDHE assumption holds if AdvABDHE

A (Îť) is negligible.

4 Robust Gentry IBE Schemes

In this section, we employ the Abdalla et al. transformation [4, 5] to the Gentry IBE scheme given in
Section 3.

4.1 Two Robustness Notions

Abdalla et al. defined two notions of robustness, weak robustness and strong robustness. Weak robustness en-
sures that M ′ 6=⊥ holds with negligible probability where M ′ is defined as M ′ := IBE.Dec(params, skID′ , CID)
where skID′ := IBE.KeyGen(params,msk, ID′) and CID := IBE.Enc(params, ID,M). Here, (M, ID, ID′) is se-
lected by an adversary with the condition M 6=⊥ and ID 6= ID′. Further, we remark that the ciphertext of ID
on M is honestly computed. Strong robustness ensures that M 6=⊥ and M ′ 6=⊥ hold with negligible prob-
ability where M and M ′ are defined as M := IBE.Dec(params, skID, C) and M ′ := IBE.Dec(params, skID′ , C)
where skID := IBE.KeyGen(params,msk, ID) and skID′ := IBE.KeyGen(params,msk, ID′). Here, (C, ID, ID′) is
selected by an adversary with the condition ID 6= ID′. We remark that the ciphertext C is adversarially
computed.

4.2 Weakly Robust Gentry IBE Scheme

First, we denote a weakly robust Gentry IBE scheme. We employ the Abdalla et al. transformation for

weak robustness. Intuitively, the auxiliary information K
$←− {0, 1}λ is chosen and is contained in public

parameters. The encryption algorithm encrypts the plaintext M ||K, and the decryption algorithm checks
whether K is appropriately recovered. We remark that M ||K is not an element of GT since K ∈ {0, 1}Ν.
Thus, we need to consider an encoding for K and how to recover M and K from the decryption result.
Thus, we employ the KEM/DEM framework and M ||K is encrypted by AES-GCM. Let AES.Enc(¡, ¡) and
AES.Dec(¡, ¡) be encryption and decryption algorithms whose the first input is a key and the second input is
either a plaintext or a ciphertext.

Weakly Robust Gentry IBE Scheme:

• IBE.Setup(1λ): Choose a Type-3 bilinear group (G1,G2,GT , e, g1, g2) with λ-bit prime order p where g1

and g2 are generators of G1 and G2, respectively. Choose K
$←− {0, 1}λ, α

$←− Zp, and h1, h2, h3
$←− G2,

compute g′1 = gα1 , and output params = (K, g1, g
′
1, g2, h1, h2, h3, H,HAES) where H : {0, 1}∗ → Zp is

a universal one-way hash function, HAES : GT → {0, 1}256 be a collision resistant hash function, and
msk = Îą.

• IBE.KeyGen(params,msk, ID): For identity ID ∈ Zp, for i = 1, 2, 3 choose rID,i
$←− Zp, compute hID,i =

(hig
rID,i

2 )1/(α−ID) ∈ G2, and output skID = (rID,i, hID,i)
3
i=1.

178



International Journal of Networking and Computing

• IBE.Enc(params, ID,M): Choose s
$←− Zp, compute C1 = g′1

s
g−sID1 , C2 = e(g1, g2)s, KAES = HAES(e(g1, h1)−s),

C3 = AES.Enc(KAES,M ||K), β = H(C1, C2, C3), and C4 = e(g1, h2)se(g1, h3)sβ , and output C =
(C1, C2, C3, C4).

• IBE.Dec(params, skID, C): Compute β = H(C1, C2, C3). If C4 6= e(C1, hID,2h
β
ID,3)C

rID,2+rID,3β
2 , then

output ⊥. Otherwise, compute M ||K ′ = AES.Dec(HAES((e(C1, hID,1)C
rID,1

2 )−1), C3). Output ⊥ if
K ′ 6= K, and output M , otherwise.

4.3 Strongly Robust Gentry IBE Scheme

Next, we denote a strongly robust Gentry IBE scheme. We employ the Abdalla et al. transformation to
the weakly robust Gentry IBE scheme as the building block. The transformation additionally introduces a
commitment scheme CMT = (CPG,Com,Ver). The parameter generation algorithm CPG takes as input a
security parameter, and outputs the public parameter cpar. The committal algorithm Com takes as input
cpar and data x, and outputs a commitment com and a decommittal key dec. The verification algorithm
Ver takes as input (cpar, x, com, dec), and outputs 1 or 0. We employ the Pedersen commitment scheme [46].

Let G1 be a group with a prime order p. The CPG algorithm chooses g′, h′
$←− G1. The Com algorithm

chooses dec
$←− Zp and computes com = g′

x
h′
dec

. The Ver algorithm outputs 1 if com = g′
x
h′
dec

and 0
otherwise. The Pedersen commitment scheme is perfectly hiding, and is computationally binding under the
DL assumption. Since we do not have to assume the hardness of the DDH problem, we implement the
scheme on G1 regardless of types of pairings.

In the scheme, a public key ID is committed. The encryption algorithm encrypts a plaintext M ||dec
and the commitment com is contained in the ciphertext. Because the weakly robust IBE scheme is used
as the building block, the encryption algorithm encrypts a plaintext M ||K||dec in the actual scheme. The
decryption algorithm checks whether com is a commitment of ID or not. As in the weak one, we remark
that M ||K||dec is not an element of GT and thus we employed the KEM/DEM framework.

Strongly Robust Gentry IBE Scheme:

• IBE.Setup(1λ): Choose a Type-3 bilinear group (G1,G2,GT , e, g1, g2) with λ-bit prime order p where

g1 and g2 are generators of G1 and G2, respectively. Choose K
$←− {0, 1}λ, g′, h′

$←− G1, α
$←− Zp,

and h1, h2, h3
$←− G2, compute g′1 = gα1 , and output params = (K, g′, h′, g1, g

′
1, g2, h1, h2, h3, H,HAES))

where H : {0, 1}∗ → Zp is a universal one-way hash function, HAES : GT → {0, 1}256 be a collision
resistant hash function, and msk = Îą.

• IBE.KeyGen(params,msk, ID): For identity ID ∈ Zp, for i = 1, 2, 3 choose rID,i
$←− Zp, compute hID,i =

(hig
rID,i

2 )1/(α−ID) ∈ G2, and output skID = (ID, (rID,i, hID,i)
3
i=1).

• IBE.Enc(params, ID,M): Choose dec
$←− Zp and compute com = g′

ID
h′
dec

. Choose s
$←− Zp, compute

C1 = g′1
s
g−sID1 , C2 = e(g1, g2)s, KAES = HAES(e(g1, h1)−s), C3 = AES.Enc(KAES,M ||K||dec), β =

H(C1, C2, C3), and C4 = e(g1, h2)se(g1, h3)sβ , and output C = (com,C1, C2, C3, C4).

• IBE.Dec(params, skID, C): Compute β = H(C1, C2, C3). If C4 6= e(C1, hID,2h
β
ID,3)C

rID,2+rID,3β
2 , then

output ⊥. Otherwise, compute M ||K ′||dec = AES.Dec(HAES((e(C1, hID,1)C
rID,1

2 )−1), C3). Output ⊥ if

K ′ 6= K. Otherwise, output ⊥ if com 6= g′
ID
h′
dec

, and output M , otherwise.

Remark. To the best of our knowledge, the strongest notion among several robustnesses is complete
robustness defined by Farshim et al. [29].4 They also showed that the transformation from weakly robust
IBE to strongly robust IBE, employed in this paper, is already powerful enough to construct completely
robust IBE. Thus, the strongly robust Gentry IBE scheme given in this paper provides complete robustness
in the strict sense.

4As another robustnesses notions, Mohassel [44] defined robustness for key-encapsulation mechanisms, Farshim et al. [30]
defined robustness for symmetric primitives (authenticated-encryption, message-authentication codes and pseudo-random func-
tions), and Géraud et al. [33] defined robustness for functional encryption and digital signatures.

179



Implementation of a Strongly Robust Identity-Based Encryption Scheme over Type-3 Pairings

Table 1: Comparison among Gentry IBE Schemes over Type-3 Pairings (millisec)
Normal (Sec. III) Weakly Robust (Sec. IV) Strongly Robust (Sec. IV)

IBE.Setup 14.66 14.63 15.39
IBE.KeyGen 4.54 4.54 4.49
IBE.Enc 4.66 4.63 5.19
IBE.Dec 8.49 8.46 9.00

Table 2: Comparison of Strongly Robust Gentry IBE Schemes among Pairing Libraries (millisec)
PBC (Type-1) PBC (Type-3) mcl (Type-3)

IBE.Setup 83.85 317.69 15.39
IBE.KeyGen 42.08 33.32 4.49
IBE.Enc 21.99 62.13 5.19
IBE.Dec 34.83 181.69 9.00

5 Implementation

In this section, we give our implementation results.

5.1 Implementation Results

Our implementation environment includes CPU: Intel(R) Core(TM) i7-6950X (3.00GHz), gcc 4.9.2, openssl
1.0.1t, and mcl v1.00. First, we denote a comparison among the Gentry IBE schemes over Type-3 pairings
in Table 1. All the schemes are implemented using the mcl library and BN462. We add e(g1, g2), e(g1, h1),
e(g1, h2), and e(g1, h3) to params in case of all the implementations. Then, no pairing computation is required
in the encryption algorithm at the expense of the pre-computation costs on the setup algorithm. As presented
in Table 1, the efficiencies of all the schemes are almost the same, revealing a strong robustness with little
additional costs.

In Table 2, we compare the running times of the strongly robust Gentry IBE schemes to denote the
effectiveness of the Type-3 curves. Here, PBC stands for the PBC library [1] (we employ pbc-0.5.14). We
use the effective security system because the PBC library offers no support to elliptic curves that provide
128-bit security by default. For PBC (Type-1), we generate parameters for a symmetric bilinear group (Type
A curve in PBC), defined over 1536-bit prime r using the PairingParametersGenerator API supported by
jPBC [22]. Here, GT is a subgroup of F∗r2 . For additional information, we generate parameters for a BN
curve (Type F curve in PBC) defined over 462-bit prime using the same API. The implementation results
are presented in the PBC (Type-3) column. Moreover, we employ the element pow2 mpz function supported
by PBC and the mclBnG1 mulVec, the mclBnG2 mulVec, and the mclBnGT powVec functions supported by
the mcl library that compute gxhy directly from g, h, x, and y, which is generally faster than performing
two separate exponentiations (i.e., compute gx and hy separately, and compute gxhy). We employ them to

compute C1 = g′1
s
g−sID1 , com = g′

x
h′
dec

, and C4 = e(g1, h2)se(g1, h3)sβ in the encryption algorithm.

In Table 3, we show the benchmarks. Here, MulExp is the running time of multi-scalar multiplications
with the length 2, i.e, compute gxhy directly as mentioned above. For the mcl library, MulExp. on G1 (resp.
G2) is the running time of the mclBnG1 mulVec function (resp. the mclBnG2 mulVec function), and Exp. on
GT is the running time of the mclBnGT powVec function. With respect to the exponentiations of G1, Type-3
curves is faster than that of Type-1 curves regardless of the library. This is a reasonable result because
we set the order of G1 is 462-bit prime in Type-3 settings and that is 1536-bit prime in Type-1 settings.
More precisely, that of mcl (Type-3) is almost 20 times faster than that of PBC (Type-1). However, that
of PBC (Type-3) is just two times faster than that of PBC (Type-1). PBC (Type-1) is more efficient than
mcl (Type-3) with respect to the exponentiations of GT . This is also a reasonable result. In PBC (Type-1),
GT is a subgroup of F∗r2 where r is a 1536-bit prime. In mcl (Type-3), GT is a subgroup of F∗r12 where r is
a 462-bit prime. In terms of the element size of GT , PBC (Type-1) is more efficient than mcl (Type-3) with
respect to the exponentiations of GT . More precisely, that of PBC (Type-1) is almost 1.5 times faster than

180



International Journal of Networking and Computing

that of mcl (Type-3), and that of PBC (Type-3) is much slower among them. Although the same type is
used in mcl (Type-3) and PBC (Type-3), there is a significant difference from the running time point of view.
It seems the reason behind is that the parameter employed in mcl (Type-3) is optimized but that of PBC
(Type-3) is randomly generated by the API. The dominant computations in IBE schemes are (Mul)Exp.
on G1 and GT since almost pairings are pre-computed in our implementations. As a reslut, PBC (Type-1)
provides a more efficient implementation than that provided by PBC (Type-3). In total, mcl (Type-3) yields
the most efficient implementation result due to the efficency of (Mul)Exp. on G1 and pairing computations,
and Exp. on GT is comparable to that of PBC (Type-1).

Table 3: Benchmarks (millisec)
PBC (Type-1) PBC (Type-3) mcl (Type-3)

Exp. on G1 6.84 3.22 0.35
MulExp. on G1 9.38 4.50 0.50

Exp. on G2 – 5.37 0.75
MulExp. on G2 – 7.40 1.19

Exp. on GT 0.77 15.65 1.14
MulExp. on GT 1.43 21.71 1.75

Pairing 8.50 70.70 2.70

6 Application to Searchable Encryption

Although robustness itself is already an attractive property, in this section we introduce an application
of robust IBE to searchable encryption. Before giving the application, we introduce the relation between
consistency of searchable encryption and robustness as follows. As a well known result, public key encryption
with keyword search (PEKS) [16] can be constructed from anonymous IBE [3]. Intuitively, a keyword ω to
be searched is regarded as an identity of an IBE scheme, and a random plaintext R is encrypted by using
ω. A secret key skω is regarded as a trapdoor, and one (typically a server that has a role of searching) can
check whether a ciphertext is associated to ω or not by checking the decryption result of the ciphertext using
the trapdoor is R. Due to the anonymity, no information of keyword is revealed from the ciphertext.5 We
remark that the original paper [16] indicated the fixed R = 0|Ν| (for a security parameter Ν ∈ N), but as
mentioned in [3] the construction does not guarantee (wrong keyword) consistency where a ciphertext of ω
may be searched by a trapdoor skω′ with ω 6= ω′. As an application of robustness, Abdalla et al. [4,5] showed
that if the underlying IBE is robust, then this original construction above provides consistency. This result
fits the following intuition where robustness guarantees that the decryption result of a ciphertext encrypted
by ω is ⊥ when skω′ with ω 6= ω′ is used.

Suzuki et al. [53,54] showed that secure-channel free PEKS with public key encryption (SCF-PEKS/PKE),
which is explained later more clearly, can be constructed from anonymous IBE with a certain robustness,
which they call unrestricted strong collision-freeness. Since unrestricted strong collision-freeness is weaker
than complete robustness [29], and the transformation from weakly robust IBE to strongly robust IBE,
employed in this paper, is already powerful enough to construct completely robust IBE. Thus, the strongly
robust Gentry IBE scheme given in this paper provides unrestricted strong collision-freeness in the strict
sense, and it can be employed as an underlying IBE scheme. So, in this section we explicitly present a
SCF-PEKS/PKE scheme based on the strongly robust Gentry IBE scheme. Before giving the construction,
we explain SCF-PEKS/PKE as follows. In PEKS, a trapdoor needs to be sent to the server via a secure
channel since anyone can run the test algorithm if they obtain the trapdoor. We call secure-channel free if no

5We remark that we just consider whether information of keyword is revealed from the “ciphertext” or not as a standard
security requirement of PEKS. Thus, the server may obtain information of keyword when it runs the test algorithm. Especially,
in some schemes (e.g., PEKS-STAT [3]) a keyword to be searched is directly contained in a trapdoor. Then, obviously the server
can know what keyword is searched. Our SCF-PEKS/PKE instantiation also follows this structure due to strong robustness.
More concretely, the IBE decryption algorithm needs to know the identity for checking the validity of the commitment contained
in the ciphertext. How to prevent the information leakage, i.e., preventing keyword guessing attacks [28], is left as a future
work.

181



Implementation of a Strongly Robust Identity-Based Encryption Scheme over Type-3 Pairings

secure channel is required for sending trapdoors to the server. To add the functionality, the server also has a
public key and a secret key, and a ciphertext is generated both a keyword and the server public key. The test
algorithm requires both a trapdoor and the server secret key. Such schemes, SCF-PEKS (which is also called
designated tester PEKS), have been proposed in [11, 23, 24, 26, 27, 35, 37, 47, 48, 55]. In addition, PEKS does
not provide a decryption functionality as PKE. Thus, schemes with both PEKS and PKE functionalities,
which we call PEKS/PKE, have been proposed in [10, 19, 20, 51, 56]. SCF-PKES/PKE provides both these
functionalities. Here there are three entities, a receiver, an encryptor, and the server. The receiver has a
public key and a master secret key, generates a trapdoor for searching using the masker secret key, and sends
the trapdoor to the server via a public channel. An encryptor generates a ciphertext of both a keyword and
a plaintext, and sends the ciphertext to the server. The server that has a trapdoor searches a ciphertext by
using the trapdoor, and sends the ciphertext to the receiver. Finally, the decrptor decrypts the ciphertext,
and obtain the plaintext. We introduce the syntax of SCF-PEKS/PKE as follows. Let K be the keyword
space and M be the message space.

Definition 4 (Syntax of SCF-PEKS/PKE [53,54]) A SCF-PEKS/PKE scheme SCF-PEKS/PKE con-
sists of the following six algorithms, KeyGenS, KeyGenR, Trapdoor, Enc, Dec and Test:

• KeyGenS(1λ): The server key generation algorithm takes as input the security parameter λ ∈ N, and
returns a server public key pkS and a server secret key skS.

• KeyGenR(1λ): The receiver key generation algorithm takes as input the security parameter λ ∈ N, and
returns a receiver public key pkR and a receiver secret key skR.

• Trapdoor(pkR, skR, ω): The trapdoor generation algorithm takes as input pkR, skR, and a keyword
ω ∈ K, and returns a trapdoor tω corresponding to keyword ω.

• Enc(pkS, pkR, ω,M): The encryption algorithm takes as input pkR, pkS, ω, and a message M ∈ M,
and returns a ciphertext CT.

• Dec(pkR, skR,CT): The decryption algorithm takes as input pkR, skR, and CT, and returns a message
M or a reject symbol ⊥.

• Test(pkS, skS, pkR, tω,CT): The test algorithm takes as input pkS, skS, pkR, tω, and CT, and returns
1 if ω = ω′, where ω′ is the keyword which was used for computing CT, and 0 otherwise.

Suzuki et al. gave a generic construction of SCF-PEKS/PKE by extend";"""date"",""2020-06-27T05:19:40Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""Implementation of a Strongly Robust Identity-Based Encryption Scheme over Type-3 Pairings
""
""xmp:CreatorTool"",""TeX""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""TeX""
""access_permission:fill_in_form"",""false""
""pdf:encrypted"",""true""
""dc:title"",""Implementation of a Strongly Robust Identity-Based Encryption Scheme over Type-3 Pairings
""
""modified"",""2020-06-27T05:19:40Z""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""IJNC Editorial Committee""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.20 (TeX Live 2019) kpathsea version 6.3.1""
""meta:author"",""IJNC Editorial Committee""
""trapped"",""False""
""meta:creation-date"",""2020-06-27T05:19:40Z""
""created"",""2020-06-27T05:19:40Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-06-27T05:19:40Z""
""resourceName"",""_pdf""
""Author"",""IJNC Editorial Committee""
""producer"",""pdfTeX-1.40.20""
""pdf:docinfo:producer"",""pdfTeX-1.40.20""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""7"",""2"",""3"",""34"",""27"",""3"",""6"",""5"",""22"",""41"",""0"",""0"",""3"",""1""
""access_permission:modify_annotations"",""false""
""dc:creator"",""IJNC Editorial Committee""
""dcterms:created"",""2020-06-27T05:19:40Z""
""Last-Modified"",""2020-06-27T05:19:40Z""
""dcterms:modified"",""2020-06-27T05:19:40Z""
""title"",""Implementation of a Strongly Robust Identity-Based Encryption Scheme over Type-3 Pairings
""
""Last-Save-Date"",""2020-06-27T05:19:40Z""
""pdf:docinfo:modified"",""2020-06-27T05:19:40Z""
""meta:save-date"",""2020-06-27T05:19:40Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.20 (TeX Live 2019) kpathsea version 6.3.1""
""Content-Length"",""466927""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""IJNC Editorial Committee""
""access_permission:assemble_document"",""false""
""xmpTPg:NPages"",""15""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""1992"",""4009"",""2426"",""2826"",""2999"",""3380"",""3193"",""3638"",""3777"",""3599"",""2761"",""2756"",""2845"",""3192"",""274""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""access_permission:can_modify"",""false""
""pdf:docinfo:created"",""2020-06-27T05:19:40Z""
";https://scholar.google.ch/scholar?start=630&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098795-176;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;A privacy-preserving and scalable authentication protocol for the internet of vehicles;MN Aman, U Javaid, B Sikdar ; IEEE Internet of Things Journal, 2020  ieeexplore.ieee.org;;"… Similar to [22], they also use blockchain for their key management protocol … 4) The vehicle verifies

I3 and updates its crypto-identity by storing the new crypto-identity nonce N2 … Lemma 2. The

proposed protocol's secrets remain safe even after calling the Reveal oracle. Proof …";Cité 5 fois;;null;;;;https://scholar.google.ch/scholar?start=720&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098774-127;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;[PS][PS] A Note on Using Random Oracles for Obfuscation;GN Rothblum ; cs.columbia.edu;;"… [3] Ran Canetti. Towards Realizing Random Oracles: Hash Functions That Hide All Partial In-

formation. CRYPTO 1997: 455-469 9 Page 10. [4] Ran Canetti, Oded Goldreich, Shai Halevi.

The random oracle methodology, revisited. Journal of the ACM 51(4): 557-594 (2004) …";Autres articles;Version HTML;[PS] columbia.edu;http://www1.cs.columbia.edu/~atw12/downloads/opf.ps;;"""X-Parsed-By"",""org.apache.tika.parser.EmptyParser""
""resourceName"",""opf.ps""
""language"",""""
""Content-Length"",""280743""
""Content-Type"",""application/postscript""
";https://scholar.google.ch/scholar?start=670&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098743-56;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;On the impossibility of probabilistic proofs in relativized worlds;A Chiesa, S Liu ; 11th Innovations in Theoretical Computer …, 2020  drops.dagstuhl.de;;"… Funding This research was supported in part by: the Berkeley Haas Blockchain Initiative, and

donations from the Ethereum Foundation and the Interchain Foundation … 2.1 Oracles An oracle

is a collection of distributions over functions, with one distribution per input length …";Cité 4 fois;Les 5 versions;[PDF] dagstuhl.de;https://drops.dagstuhl.de/opus/volltexte/2020/11742/pdf/LIPIcs-ITCS-2020-57.pdf;"
On the Impossibility of Probabilistic Proofs in
Relativized Worlds
Alessandro Chiesa
UC Berkeley, CA, USA
alexch@berkeley.edu

Siqi Liu
UC Berkeley, CA, USA
sliu18@berkeley.edu

Abstract
We initiate the systematic study of probabilistic proofs in relativized worlds, where the goal is to
understand, for a given oracle, the possibility of “non-trivial” proof systems for deterministic or
nondeterministic computations that make queries to the oracle.

This question is intimately related to a recent line of work that seeks to improve the efficiency of
probabilistic proofs for computations that use functionalities such as cryptographic hash functions and
digital signatures, by instantiating them via constructions that are “friendly” to known constructions
of probabilistic proofs. Informally, negative results about probabilistic proofs in relativized worlds
provide evidence that this line of work is inherent and, conversely, positive results provide a way to
bypass it.

We prove several impossibility results for probabilistic proofs relative to natural oracles. Our
results provide strong evidence that tailoring certain natural functionalities to known probabilistic
proofs is inherent.

2012 ACM Subject Classification Theory of computation → Computational complexity and cryp-
tography

Keywords and phrases probabilistically checkable proofs, relativization

Digital Object Identifier 10.4230/LIPIcs.ITCS.2020.57

Related Version A full version of the paper is available at https://ia.cr/2019/1430.

Funding This research was supported in part by: the Berkeley Haas Blockchain Initiative, and
donations from the Ethereum Foundation and the Interchain Foundation.

1 Introduction

The study of relativized complexity classes originally aspired to shed light on the structural
relationships between unrelativized complexity classes. However, it was soon realized that
many interesting complexity classes have contradictory relativization results. For instance,
Baker et al. [9] showed that there exist oracles A and B such that PA = NPA and PB 6= NPB .

Subsequent works sought to circumvent this difficulty by considering relativized worlds
where the oracle is sampled from a “natural” distribution, and thereby avoid specially-crafted
oracles that can force an equality/inequality on the complexity classes being compared. For
instance, Bennett and Gill [20] proved that, with probability 1 over a random oracle R, it
holds that PR 6= NPR 6= co-NPR and PR = BPPR. Since these relativization results agreed
with what people believed to be true in the unrelativized case, Bennett and Gill proposed the
Random Oracle Hypothesis, which states that structural relationships between complexity
classes that hold with probability 1 over a random oracle also hold in the unrelativized case.
However, this hypothesis was later disproved by Chang et al. [22], who showed that, with
probability 1 over a random oracle R, IPR 6= PSPACER. (We know that, without oracles,
IP = PSPACE [34, 41].)

Š Alessandro Chiesa and Siqi Liu;
licensed under Creative Commons License CC-BY

11th Innovations in Theoretical Computer Science Conference (ITCS 2020).
Editor: Thomas Vidick; Article No. 57; pp. 57:1–57:30

Leibniz International Proceedings in Informatics
Schloss Dagstuhl – Leibniz-Zentrum für Informatik, Dagstuhl Publishing, Germany

mailto:alexch@berkeley.edu
mailto:sliu18@berkeley.edu
https://doi.org/10.4230/LIPIcs.ITCS.2020.57
https://ia.cr/2019/1430
https://creativecommons.org/licenses/by/3.0/
https://www.dagstuhl.de/lipics/
https://www.dagstuhl.de


57:2 On the Impossibility of Probabilistic Proofs in Relativized Worlds

These works indicate that, in general, relativization results are not helpful for under-
standing the relationships between unrelativized complexity classes. At best they provide us
with relativization barriers, which nowadays are not considered so strong since we know of
non-relativizing techniques.

1.1 New motivation: the efficiency of probabilistic proofs
We revisit relativization with a new motivation: the efficiency of probabilistic proofs. Super-
ficially, relativization and probabilistic proofs seem unrelated. Yet they are deeply connected,
as we explain.

Probabilistic proofs such as interactive proofs [28] and probabilistically checkable proofs [8]
have played important roles in the study of hardness of approximation since the seminal work
of [25]. In recent years, they became the subject of intense study due to their application to
constructing highly-efficient cryptographic proofs (such as succinct arguments), and a major
research goal today is to improve the efficiency of probabilistic proofs. We now illustrate,
via an example, how relativization results tell us important facts about the efficiency of
probabilistic proofs.

I Example 1. Let H = {Hs : {0, 1}|s| → {0, 1}|s|}s∈{0,1}∗ be a family of “hash functions”
(the precise security property in this discussion is unimportant), and consider the following
NP language:

Ls = {(n, y) ∈ N× {0, 1}|s| | ∃x ∈ {0, 1}|s| s.t. Hn
s (x) = y} .

The efficiency measures (proof length, randomness complexity, query complexity, and
others) of a PCP for the language Ls typically depend on the size of an arithmetic circuit
that iteratively applies Hs, for n times, to a candidate witness x and checks if the result is y.
The size of such a circuit is Ω(n |Hs|), i.e., it depends on the size of a circuit for expressing
the computation of Hs. Since there are many NP languages of interest to practitioners that
involve cryptographic computations such as hash functions, researchers have been designing
specialized families of hash functions that can be represented via small arithmetic circuits
[6, 2, 29, 4, 3, 30].

We ask: is optimizing the arithmetic circuit complexity of hash functions necessary?
We now explain why the answer to this question is connected to relativization statements

about probabilistic proofs. Informally, suppose that for any family of hash functions H
it holds that NPH ⊆ PCPH. In other words, every language that can be decided by a
nondeterministic polynomial-time machine that makes oracle calls to a hash function has a
PCP verifier that may make oracle calls to the same hash function. Now the “oracle language”
L = {Ls}s∈{0,1}∗ , which is in the relativized complexity class NPH, can be decided via a
computation that involves n calls to the hash function but does not depend on the complexity
of the hash function itself (as this computation happens inside the oracle). Hence, since we
assumed that NPH ⊆ PCPH, we can obtain a probabilistic proof for L whose efficiency does
not depend on the complexity of the hash function (which is wonderful).

In sum, probabilistic proofs that “relativize with respect to hash functions” obviate
the need to design hash functions with small complexity and, conversely, negative results
about such relativizations provide strong evidence that efforts to design “PCP-friendly” hash
functions are inherent.

The above example illustrates a general connection. On the one hand, constructing
probabilisitic proofs in relativized worlds could provide drastic efficiency improvements to
probabilistic proofs. On the other hand, ruling out probabilistic proofs in relativized worlds



A. Chiesa and S. Liu 57:3

would provide a complexity-theoretic justification for why practitioners may be “stuck” with
the task of designing “PCP-friendly” realizations of various functionalities (hash functions,
signatures, encryption, and so on).

1.2 Our question: are there PCPs for computations in relativized
worlds?

We initiate the systematic study of probabilistic proofs for relativized computations.
In this work an oracle is a collection A = {An}n∈N where each An is a distribution over

functions on n-bit inputs. A sample from A is a function A : {0, 1}∗ → {0, 1}∗ obtained by
sampling a function fn from each An and then setting A to equal fn for n-bit inputs. (See
Section 2.1 for definitions.)

We wish to understand for what oracles A there are probabilistically checkable proofs
(PCPs) in a relativized world where all machines have oracle access to a sample from A. Below
we make this question more precise, distinguishing between the case of PCPs for relativized
nondeterministic computations (“do PCPs provide any savings in witness length?”) and the
case of PCPs for relativized deterministic computations (“do PCPs provide any savings in
computation length?”).

The complexity classes that we study are the natural relativized extensions of DTIME,
NTIME, and PCP. Note that complexity classes relative to an oracle A are sets of oracle
languages (see Definition 11) rather than sets of languages, because the sample from A affects
whether a particular instance is in the language or not. The informal definitions below are
made precise in Section 2.4.

DTIME(t(n))A oracle languages that are decidable by a deterministic machine that
runs in time O(t(n)) and has oracle access to a sample from A

NTIME(t(n))A oracle languages that are decidable by a nondeterministic machine that
runs in time O(t(n)) and has oracle access to a sample from A

PCP(t(n), q(n))A
oracle languages that are decidable by a PCP verifier that runs in time
O(t(n)), makes O(q(n)) queries to a proof string, and has oracle access
to a sample from A

We introduce two incomparable questions, which concern the (im)possibility of “non-
trivial” PCPs for relativized nondeterministic computations and for relativized deterministic
computations.
1. PCPs for NTIME. For every oracle A it holds that NTIME(t(n))A ⊆ PCP(t(n), t(n))A

because a PCP verifier can read in full a witness provided in the PCP proof, and then
run the nondeterministic decider on the witness. We ask: for what oracles A can we
have any non-trivial improvement on this trivial inclusion? Namely, we consider PCP
verifiers that may make o(t(n)) queries to the PCP proof, which in general prevents the
PCP verifier from reading a witness from the PCP proof. We additionally allow the PCP
verifier to incur a polynomial blow-up in running time: it may run in time poly(t(n)),
and in particular can make poly(t(n)) queries to the sample from A. (The queries to the
PCP proof are still o(t(n)).) This amounts to asking:

Given an oracle A, is it the case that NTIME(t(n))A ⊆ PCP(poly(t(n)), o(t(n)))A?
We will say that an oracle A separates NTIME and PCP if the answer to this question is
negative.

2. PCPs for DTIME. For every oracle A it holds that DTIME(t(n))A ⊆ PCP(t(n), 0)A
because a PCP verifier can simply run the deterministic decider. We similarly ask: for
what oracles A can we have any non-trivial improvement on this trivial inclusion? Namely,

ITCS 2020



57:4 On the Impossibility of Probabilistic Proofs in Relativized Worlds

we consider PCP verifiers that run in time o(t(n)), which in general prevents a PCP
verifier from simply running the deterministic decider. We additionally allow the PCP
verifier to ask any number of queries to the proof or to the sample from A (as bounded
by its running time). This amounts to asking:

Given an oracle A, is it the case that DTIME(t(n))A ⊆ PCP(o(t(n)), o(t(n)))A?
We will say that an oracle A separates DTIME and PCP if the answer to this question is
negative.

What is known? Recall that, for unrelativized complexity classes, we have excellent PCPs.
All nondeterministic computations have a constant-query PCP verifier that runs in polylogar-
ithmic time: NTIME(t(n)) ⊆ PCP(poly(n, log t(n)), O(1)) [24, 19, 37]. In particular, PCPs
simultaneously provide exponential savings in witness length and in computation length.

However, for relativized complexity classes, known relativization results tell us very little.
The main relevant prior work is by Hartmanis et al. [31], who claim that, with probability
1 over a random function R : {0, 1}∗ → {0, 1}, NPR 6⊆ PCP(poly(n), logn)R. This provides
a negative result for the special case where A is a “random oracle”, t(n) is polynomially
bounded, and the PCP verifier makes O(logn) queries to the PCP proof. (In Section 1.4 we
discuss other related work.)

However, even for the case of a random oracle, our goal is to rule out any non-trivial
PCP for any nondeterministic computation (ruling out any savings in witness length), and
also for any deterministic computation (ruling out any savings in computation length, even
if there is no witness).

More generally, we are interested to answer these questions for oracles beyond random
oracles.

Some intuition. If the PCP verifier could “learn” the oracle in a small number of queries,
then we may be able to rely on known techniques to construct PCPs for unrelativized
computations because each oracle call could be replaced by a subroutine that simulates the
learned oracle. Conversely, if the oracle is “hard” to learn, then known techniques do not
seem to apply because it is not clear how they could deal with oracle calls, and so we may
expect that non-trivial PCPs in this case are impossible. Our goal will be to show that, for
hard-enough oracles, non-trivial PCPs are indeed impossible (regardless of the techniques
that could be used to construct the PCPs).

Beyond PCPs. There are several models of probabilistic proofs beyond PCPs, such as
interactive proofs (IPs) [28], interactive PCPs (IPCPs) [33], and interactive oracle proofs
(IOPs) [18, 39]. One may ask: why do we focus only on PCPs in our presentation? The
answer is that, for the goals of this paper, the PCP model is equivalent to the IOP model
(see Remark 6), and the IOP model subsumes the other models as special cases. So, for the
goals of this paper, it suffices to study PCPs. All results in Section 1.3 directly translate to
IPs, IPCPs, and IOPs.

1.3 Our results
We prove that, for several oracles of cryptographic interest, non-trivial PCPs for relativized
computations do not exist – this holds both for deterministic computations (DTIME) and for
nondeterministic computations (NTIME). Moreover, we establish several structural results
about “hard oracles” for PCPs. These initial results provide us with valuable insights into the
efficiency limitations of PCPs, and provide a useful starting point for further investigations
into this new direction.



A. Chiesa and S. Liu 57:5

We now summarize our results in more detail.

(1) Random functions. We begin with the oracle that intuition suggests is the “hardest”
oracle for PCPs because it is “maximally unlearnable”, the random oracle. Namely, we
consider the oracle R = {Rn}n∈N where each Rn is the uniform distribution over all functions
Rn : {0, 1}n → {0, 1}.1 Our first result shows that the intuition is correct, i.e., we prove that
the oracle R separates DTIME and PCP and also separates NTIME and PCP.

I Theorem 2 (informal). Let R be the random oracle. For any t : N→ N,

DTIME(t)R 6⊆ PCP(o(t), o(t))R and NTIME(t)R 6⊆ PCP(poly(t), o(t))R .

The above theorem tells us that we cannot, in general, expect to construct PCPs for
cryptographic computations that involve random oracles, such as Fiat–Shamir signatures
[26]. The natural alternative would be to somehow instantiate the random oracle, and incur,
within the PCP, the cost of the hash function used in place of the random oracle. This
is indeed what Valiant [43] did in his construction of incrementally verifiable computation
(IVC): Valiant needed to construct a PCP for the computation of a SNARK verifier that
uses random oracles and, lacking suitable PCPs for this relativized computation, considered
instead the SNARK verifier obtained by instantiating the random oracle. Our Theorem 2
rules out PCPs for computations that use random oracles, and in particular gives strong
evidence that Valiant’s approach was in some sense justified.

One may argue that, while they give us useful insights, random oracles do not tell us much
about other oracles because they are too special in that they have no structure. We now
consider two oracles with structure: one with group structure and another with low-degree
structure.

(2) Random generic groups. Many group-based cryptographic primitives are stated (and
sometimes also analyzed) with respect to a generic group. This means that the primitive
relies only on the fact that a certain prime-order group is available but does not rely on
whether the group is instantiated, say, with a multiplicative subgroup of a finite field or an
elliptic curve group. This motivates the question of whether there are PCPs with respect
to a random (generic) group oracle, which is the oracle O = {On}n∈N where each On is a
random presentation of a group of order n. We prove that the answer is negative, i.e., that
the oracle O separates NTIME and PCP.

I Theorem 3 (informal). Let O be the random group oracle. For any t : N→ N,

NTIME(t)O 6⊆ PCP(poly(t), o(t))O .

The above theorem tells us that, in general, the representation of a group matters to a
PCP. For example, if we return to the iterative hash computation of Example 1 and set the
hash function to be the Pedersen hash function (a function that is collision resistant over
any group where extracting discrete logarithms is hard), we should pick a group tailored to
the PCP at hand. This is consistent with the fact that applied cryptographers working with
probabilistic proofs have had to carefully design group instantiations for such computations.

1 More generally, we consider the uniform distribution over functions Rn : {0, 1}n → {0, 1}`(n) for some
`(n).

ITCS 2020



57:6 On the Impossibility of Probabilistic Proofs in Relativized Worlds

E.g., Jubjub [44] is an elliptic curve in the Zcash cryptocurrency that is used to instantiate
a Pedersen hash function in a way that is “friendly” to probabilistic proofs. Our theorem
provides strong evidence that these efforts are necessary.

(3) Random low-degree functions. Probabilistic proofs are typically achieved by relying
on low-degree functions that encode information associated to the computation being checked.
This fact extends to relativized complexity classes in the sense that results such as IP =
PSPACE algebrize with respect to every oracle [1]. In the language of this paper, this means
that for every oracle A, it holds that PSPACEA ⊆ IP where  is the low-degree extension
of A (each sample in A is replaced with some low-degree extension of it).

However in this paper we are interested to understand relativization results, not algebriz-
ation results, and the above discussion raises the question of what happens when we compare
DTIME/NTIME and PCP in a relativized world where the oracle is a random low-degree
function. Namely, we consider the oracle P = {Pn}n∈N where Pn is the uniform distribution
over all low-degree polynomials on n variables (for given field and degree parameters). Note
that P can be viewed as a low-degree extension of the random oracle R.

We prove that P separates NTIME and PCP.

I Theorem 4 (informal). Let P be the random low-degree oracle. For any t : N→ N,

NTIME(t)P 6⊆ PCP(poly(t), o(t))P .

Interlude on separation types. We have so far considered relativized complexity classes in
which a single machine is granted oracle access to a sample A : {0, 1}∗ → {0, 1}∗ from the
oracle A, and is required to “work” for the language defined by A with probability 1 over
the choice of A. For example, DTIME(t)A is the class of all oracle languages L = {LA}A∈A
for which there exists a deterministic machine M , which runs in time O(t(n)), such that

Pr
A←A

[
MA decides the language LA

]
= 1 .

We use analogous definitions for NTIME and PCP, as discussed in Section 2.4. We consider
these definitions to be the natural ones to use for the goals of this paper. We sometimes
refer to separations between these complexity classes as uniform separations, to distinguish
them from those below.

We could alternatively study separations where all machines are allowed to non-uniformly
depend on A, thereby granting all machines more power. In this direction, there are two
natural definitions.

Somewhere separation. We say that A provides a somewhere separation for DTIME and
PCP if there exists A ∈ A such that DTIME(t)A 6⊆ PCP(o(t), o(t))A. And similarly for
NTIME.
Almost-everywhere separation. We say that A provides an almost-everywhere separation
for DTIME and PCP if DTIME(t)A 6⊆ PCP(o(t), o(t))A holds with probability 1 over a
random choice of sample A← A. (Note that this leaves open the possibility that there is
no separation for a set of functions of measure 0 in A.) And similarly for NTIME.

An almost-everywhere separation is, in general, strictly stronger than an a somewhere
separation. However, the relation between these and uniform separations is not a priori clear.

We provide clarity on this comparison: in the full version we prove that uniform separations
are equivalent to somewhere separations, at least when comparing DTIME/NTIME and
PCP. Namely, we prove that, for any oracle A, DTIME(t)A 6⊆ PCP(o(t), o(t))A if and only
if there exists a function A in A such that DTIME(t)A 6⊆ PCP(o(t), o(t))A. And similarly
for NTIME.



A. Chiesa and S. Liu 57:7

Almost-everywhere separation for random functions. For the random oracle R, we streng-
then the separations in Theorem 2 to almost-everywhere separations (via a different, longer
proof). We learn that the random oracle R is particularly “hard” for PCPs.

I Theorem 5 (informal). Let R be the random oracle. For any t : N→ N,

Pr
R←R

[
DTIME(t)R 6⊆ PCP(o(t), o(t))R

]
= 1

and Pr
R←R

[
NTIME(t)R 6⊆ PCP(poly(t), o(t))R

]
= 1 .

The above theorem also directly improves on the classical work of Hartmanis et al. [31],
who showed that PrR←R[ NPR 6⊆ PCP(poly(n), logn)R ] = 1. The improvement is that our
result rules out any non-trivial PCP for any nondeterministic computation, and also rules
out any non-trivial PCP for any deterministic computation.

We prove Theorem 5 by building on techniques of Chang et al. [22] that were used to
prove that PrR←R[ IPR 6= PSPACER ] = 1. These techniques rely on the fact that every
function R in R has many other functions in R that are close to it in all but finitely many
points.

We do not know how to extend these techniques to oracles such as the random group
oracle O or the random low-degree oracle P, because in these cases any two samples are far
from one another. In this light, we view the techniques that we use to prove Theorems 2
to 4 as more flexible. Moreover, we consider the separations proved in these theorems as
sufficient for our motivations.

Structural results: beyond R, O, P. Our results thus far concern separations for specific
oracles of interest. There are other oracles of interest that demand understanding (e.g.,
pseudorandom functions) and, more generally, the study of separations could benefit from
general statements. In Section 3 we prove several useful structural results about oracles that
are “hard” for PCPs.
1. Robustness. We prove that the separating property is “robust” with respect to small pertur-

bations. In more detail, we prove that for every oracle A that separates DTIME/NTIME
and PCP there exists a distance function Îľ such that any other oracle that is Îľ-close
to A also separates DTIME/NTIME and PCP. This statement can also be viewed as
telling us that the set of separating oracles is open with respect to statistical distance
(see Definition 8).
We can apply the above result to any of the separations that we have proved. For example,
if apply it to Theorem 2 then we learn that all oracles that are “almost” uniformly random
(close enough to the random oracle R) separate DTIME/NTIME and PCP. In fact, in
the full version, we use additional techniques to quantify (a bound on) this distance
threshold, proving that all oracles that are 1

3e -close to uniformly random separate NTIME
and PCP.

2. Monotonicity. We prove that the separating property is “monotone” in that, for every
oracle A that separates DTIME/NTIME and PCP, if another oracle B contains A as a
marginal distribution then B also separates DTIME/NTIME and PCP. I.e., B inherits
the hardness of A.
We rely on monotonicity in the proof of Theorem 4, where we reduce the problem
of showing separation for random low-degree polynomials to the problem of showing
separation for random multilinear polynomials (which we then solve).

ITCS 2020



57:8 On the Impossibility of Probabilistic Proofs in Relativized Worlds

3. Conditioning. We prove that the separating property is preserved by (finite) conditioning.
Namely, given an oracle A and a function f : D → {0, 1}∗ over a finite domain D, we
denote by AD,f the oracle where samples are conditioned to equal f on D. We prove that
if A separates DTIME/NTIME and PCP then AD,f also separates DTIME/NTIME and
PCP.

I Remark 6 (beyond PCPs). Research in the last few years has shown that using known
PCPs is not the best choice for constructing efficient succinct arguments. Instead, it
is better to construct succinct arguments from IOPs [18, 39], which are a multi-round
generalization of PCPs that enables significant improvements in asymptotic and concrete
efficiency [15, 14, 13, 10, 12, 11, 17, 16, 40]. So the reader may rightfully ask: why did we
prove all of our results for PCPs instead of IOPs, if these latter are more powerful?

The answer is that all of our results extend, in a generic way, to IOPs as well. This
is because our results about PCPs only consider the PCP verifier’s time complexity and
query complexity, and IOPs do not provide any benefits over PCPs when only considering
these complexity measures. Indeed, any IOP can be “unrolled” into a PCP, possibly of
exponentially larger size, while preserving the verifier’s time complexity and query complexity,
regardless of oracle. In particular, for every oracle A, the complexity class IOP(T, q)A (oracle
languages for A decidable by an IOP verifier with time complexity T and query complexity q)
equals the complexity class PCP(T, q)A (oracle languages for A decidable by a PCP verifier
with time complexity T and query complexity q).

Finally, we additionally obtain analogous impossibility results for interactive proofs (IPs)
[28] and interactive PCPs (IPCPs) [33], as both are special cases of IOPs.

1.4 Related work

NP vs. PCP in relativized worlds. Fortnow [27] uses diagonalization to obtain a function
R : {0, 1}∗ → {0, 1} such that, for every k ∈ N, NPR 6⊆ PCP(poly(n), nk)R. Hartmanis et al.
[31] report a stronger result: with probability 1 over a random function R : {0, 1}∗ → {0, 1},
NPR 6⊆ PCP(poly(n), logn)R. We do not know of a version of [31] that contains a proof of
this result, so we cannot comment on the techniques used to prove it. As already discussed,
our Theorem 5 strengthens this latter result to hold for any non-trivial PCP.

Barriers for relativization and others. PCP constructions involve the use of non-relativizing
techniques. A line of works [27, 5, 1, 32, 7] has developed frameworks that seek to capture
the class of such techniques, along with other non-relativizing ones, within formal models, in
order to prove barriers for these techniques (e.g., to show that they do not suffice to resolve
the P vs. NP question or other difficult questions in complexity theory).

The emphasis and techniques in this work are complementary to the foregoing line of works.
Our emphasis is on establishing impossibility results for PCPs regardless of techniques

used, as opposed to proving barriers for the PCP techniques that are known today.
Moreover, the axiomatic approaches employed in some of the works cited above cannot

be used to even formulate questions that involve PCP verifiers with specific running times or
query complexities. E.g., they rely on Cobham’s axiomatization of the notion of polynomial
time [23], so cannot express exact running times. This means that we would not be able to
phrase questions about non-trivial PCPs (as we do in Section 1.2).



A. Chiesa and S. Liu 57:9

1.5 Open problems
The separations that we prove in this paper are for “information-theoretic” oracles A. What
can be said about hard “cryptographic” oracles A? E.g., if A is a pseudo-random function,
then must it be the case that A separates DTIME/NTIME and PCP? What about if A is a
decryption oracle?

More generally, the holy grail in this research direction would be to distill a crisp, and
operationally useful, criterion that gives sufficient and necessary condition for an oracle A
that separates DTIME/NTIME and PCP.

2 Definitions

2.1 Oracles
An oracle is a collection of distributions over functions, with one distribution per input
length.

I Definition 7. An oracle with output length ` : N → N (with `(n) > 0 for every n ∈ N)
is a collection A = {An}n∈N where each An is a distribution over functions f : {0, 1}n →
{0, 1}`(n).

We can obtain a sample A : {0, 1}∗ → {0, 1}∗ from A by sampling a function fn from
each An and then setting A to equal fn for inputs of size n. We write “A← A” to denote
that A is a sample that follows this distribution, and “A ∈ A” to denote that A is in the
support of this distribution. We denote by supp(A) the support of A.

An oracle A induces a corresponding probability measure ÂľA over the space of functions
from binary strings to binary strings: given a subset S ⊆ {0, 1}∗ and a set X of functions
from S to {0, 1}∗, µA(X) is the probability that the restriction to S of a sample A from A
belongs to X.

I Definition 8. Two oracles A = {An}n∈N and B = {Bn}n∈N have (statistical) distance
ε : N→ N if, for every n ∈ N, the statistical distance between the distributions An and Bn is
at most Îľ(n).

We write “g ← A≤n” to denote that g is a function on {0, 1}≤n that is sampled from the
distribution A≤n := A1 × · · · × An. We write “g ∈ A≤n” to denote that g is in the support
of this distribution, and denote by supp(A≤n) the support of A≤n.

I Definition 9. An oracle B contains an oracle A if for all n ∈ N it holds that
µB(supp(A≤n)) > 0 and, for every f ∈ supp(A≤n), µB(f) = µB(supp(A≤n)) · µA(f).

The definition below provides an operation to condition an oracle to take known values.

I Definition 10. Fix a subset D ⊆ {0, 1}∗ and function f : D → {0, 1}∗.
Given a function A : {0, 1}∗ → {0, 1}∗, we define AD,f : {0, 1}∗ → {0, 1}∗ to be the
function obtained by setting the values of A on D to f:

AD,f =
{
f(x) if x ∈ D
A(x) if x 6∈ D

.

Given an oracle A = {An}n∈N (such that there exists some A ∈ supp(A) agreeing with f

on D), we define AD,f = {AD,fn }n∈N to be the oracle where samples are conditioned to
equal f on D. In more detail, each distribution AD,fn equals the distribution An conditioned
on the event that the sampled function agrees with f on D ∊ {0, 1}n.

ITCS 2020



57:10 On the Impossibility of Probabilistic Proofs in Relativized Worlds

2.2 Languages and oracle languages
A language L is a subset of {0, 1}∗. We denote by L(x) the bit that specifies whether a
string x ∈ {0, 1}∗ is in L (L(x) = 1) or not (L(x) = 0).

We also consider oracle languages because we study relativized complexity classes.

I Definition 11. Let U := {F : {0, 1}∗ → {0, 1}∗} be the set of all functions on binary
strings. An oracle language L is a collection of languages indexed by functions F ∈ U ,
namely, L = {LF }F∈U where each LF is a subset of {0, 1}∗.

A language L can be viewed as a special case of an oracle language {LF }F∈U where each
LF = L.

I Definition 12. Let ` : N→ N be a computable function. An oracle language L = {LF }F∈U
is `-bounded if, for all functions F ∈ U and inputs x ∈ {0, 1}∗, whether x ∈ LF only
depends on F ’s values at locations of size at most `(|x|). Namely, LF (x) = LF ′(x) for every
F ′ that agrees with F on the set

⋃
1≤i≤`(|x|){0, 1}i.

2.3 Machines that query oracles
We consider several notions of (Turing) machines that query oracles, as defined below.
Informally, an oracle machine is given black-box access to a function A : {0, 1}∗ → {0, 1}∗,
which the machine can query, any number of times, at any input of its choice. Each query
costs the machine a single computational step, regardless of the function A. In more detail,
we consider the following definition.

I Definition 13. An oracle machine M is a machine that has two special tapes called
oracle query tape and oracle answer tape, and two special states called Query and Answer.
The special tapes are in addition to the machine’s regular read/write tapes (of wh";"""date"",""2019-12-12T10:33:54Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""On the Impossibility of Probabilistic Proofs in Relativized Worlds""
""xmp:CreatorTool"",""LaTeX with lipics-v2019.cls and hyperref.sty""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""LIPIcs, Vol.151, ITCS 2020; Copyright (C) Alessandro Chiesa and Siqi Liu; licensed under Creative Commons License CC-BY""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with lipics-v2019.cls and hyperref.sty""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""On the Impossibility of Probabilistic Proofs in Relativized Worlds""
""modified"",""2019-12-12T10:33:54Z""
""cp:subject"",""LIPIcs, Vol.151, ITCS 2020; Copyright (C) Alessandro Chiesa and Siqi Liu; licensed under Creative Commons License CC-BY""
""pdf:docinfo:subject"",""LIPIcs, Vol.151, ITCS 2020; Copyright (C) Alessandro Chiesa and Siqi Liu; licensed under Creative Commons License CC-BY""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""Alessandro Chiesa, Siqi Liu""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.20 (TeX Live 2019) kpathsea version 6.3.1""
""meta:author"",""Alessandro Chiesa, Siqi Liu""
""trapped"",""False""
""meta:creation-date"",""2019-12-12T10:33:54Z""
""created"",""2019-12-12T10:33:54Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-12-12T10:33:54Z""
""resourceName"",""LIPIcs-ITCS-2020-57.pdf""
""Author"",""Alessandro Chiesa, Siqi Liu""
""producer"",""pdfTeX-1.40.20""
""pdf:docinfo:producer"",""pdfTeX-1.40.20""
""pdf:unmappedUnicodeCharsPerPage"",""4"",""1"",""0"",""1"",""7"",""8"",""11"",""3"",""11"",""23"",""18"",""24"",""49"",""35"",""33"",""41"",""35"",""24"",""21"",""40"",""40"",""29"",""38"",""37"",""33"",""37"",""38"",""7"",""2"",""0""
""Keywords"",""probabilistically checkable proofs, relativization""
""access_permission:modify_annotations"",""true""
""dc:creator"",""Alessandro Chiesa, Siqi Liu""
""dcterms:created"",""2019-12-12T10:33:54Z""
""Last-Modified"",""2019-12-12T10:33:54Z""
""dcterms:modified"",""2019-12-12T10:33:54Z""
""title"",""On the Impossibility of Probabilistic Proofs in Relativized Worlds""
""Last-Save-Date"",""2019-12-12T10:33:54Z""
""pdf:docinfo:keywords"",""probabilistically checkable proofs, relativization""
""pdf:docinfo:modified"",""2019-12-12T10:33:54Z""
""meta:save-date"",""2019-12-12T10:33:54Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.20 (TeX Live 2019) kpathsea version 6.3.1""
""Content-Length"",""739300""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Alessandro Chiesa, Siqi Liu""
""dc:subject"",""probabilistically checkable proofs, relativization""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""30""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""2840"",""3090"",""2848"",""2937"",""2675"",""2965"",""2659"",""2955"",""2191"",""2718"",""2470"",""2299"",""2543"",""2470"",""2138"",""2338"",""2490"",""2143"",""2117"",""2365"",""1415"",""1762"",""2033"",""1575"",""2023"",""1865"",""1716"",""2553"",""3313"",""2233""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""probabilistically checkable proofs, relativization""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-12-12T10:33:54Z""
";https://scholar.google.ch/scholar?start=600&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098892-394;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;ECDSA weak randomness in Bitcoin;Z Wang, H Yu, Z Zhang, J Piao, J Liu ; Future Generation Computer …, 2020  Elsevier;;"… Bitcoin, introduced in October 2008 by Nakamoto [1], is a decentralized cryptocurrency … a complete

computation process to warn that private key leakage is possible in a public blockchain … adaptive

chosen message attack if the hash function is modeled as a random oracle [11] …";Cité 5 fois;Les 3 versions;[PDF] researchgate.net;https://www.researchgate.net/profile/Zongyang_Zhang/publication/335577495_ECDSA_weak_randomness_in_Bitcoin/links/5efc0d1ca6fdcc4ca4408bce/ECDSA-weak-randomness-in-Bitcoin.pdf;;;https://scholar.google.ch/scholar?start=940&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098888-390;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;On the cryptographic hardness of local search;N Bitansky, I Gerichter ; 11th Innovations in Theoretical Computer …, 2020  drops.dagstuhl.de;;"… ours comes from recent advancements in proofs of sequential work motivated by blockchain

applications [40 … that TFNP hard instances constructed in a black box way from random oracles

(or some … of solutions (which is indeed the case in our result in the random oracle model) …";Cité 8 fois;Les 5 versions;[PDF] dagstuhl.de;https://drops.dagstuhl.de/opus/volltexte/2020/11691/pdf/LIPIcs-ITCS-2020-6.pdf;"
On the Cryptographic Hardness of Local Search
Nir Bitansky1

Tel Aviv University, Israel
nirbitan@tau.ac.il

Idan Gerichter
Tel Aviv University, Israel
idangerichter@gmail.com

Abstract
We show new hardness results for the class of Polynomial Local Search problems (PLS):

Hardness of PLS based on a falsifiable assumption on bilinear groups introduced by Kalai, Paneth,
and Yang (STOC 2019), and the Exponential Time Hypothesis for randomized algorithms.
Previous standard model constructions relied on non-falsifiable and non-standard assumptions.
Hardness of PLS relative to random oracles. The construction is essentially different than previous
constructions, and in particular is unconditionally secure. The construction also demonstrates
the hardness of parallelizing local search.

The core observation behind the results is that the unique proofs property of incrementally-verifiable
computations previously used to demonstrate hardness in PLS can be traded with a simple incremental
completeness property.

2012 ACM Subject Classification Theory of computation → Computational complexity and cryp-
tography

Keywords and phrases Cryptography, PLS, Lower Bounds, Incremental Computation

Digital Object Identifier 10.4230/LIPIcs.ITCS.2020.6

Funding This work was supported in part by ISF grant 18/484, and by Len Blavatnik and the
Blavatnik Family Foundation.
Nir Bitansky: Supported by the Alon Young Faculty Fellowship.

1 Introduction

Local search is a well known approach for tackling optimization problems. Local search
algorithms seek solutions that are locally optimal – they commonly try to improve on a given
solution by considering small perturbations of it, called neighbors, and testing whether they
are better according to some value function. Indeed, many algorithms use this approach with
empirical success, for instance, the Simplex linear programming algorithm, the Lin-Kernighan
TSP algorithm, and various machine learning algorithms [43, 38, 31]. Nevertheless, the
approach has its limitations and many natural local search problems are not known to admit
polynomial-time algorithms.

Aiming to characterize the computational complexity of local search, Johnson, Papadim-
itriou, and Yannakakis [33] introduced the class Polynomial Local Search (PLS). The class
is defined by its canonical complete problem Local-Search (LS) [33, 29]. Here the input
consists of two polynomial-size circuits: a successor circuit S : {0, 1}n → {0, 1}n, which
given a string x outputs a string x′, and a value circuit F , which given a string x outputs
an integer value. The goal is to find a string x which is locally optimal in the sense that
F(x) ≥ F(S(x)). Here strings correspond to solutions, with a value assigned by F , and the

1 Member of the Check Point Institute of Information Security.

Š Nir Bitansky and Idan Gerichter;
licensed under Creative Commons License CC-BY

11th Innovations in Theoretical Computer Science Conference (ITCS 2020).
Editor: Thomas Vidick; Article No. 6; pp. 6:1–6:29

Leibniz International Proceedings in Informatics
Schloss Dagstuhl – Leibniz-Zentrum für Informatik, Dagstuhl Publishing, Germany

https://orcid.org/0000-0001-8361-6035
mailto:nirbitan@tau.ac.il
mailto:idangerichter@gmail.com
https://doi.org/10.4230/LIPIcs.ITCS.2020.6
https://creativecommons.org/licenses/by/3.0/
https://www.dagstuhl.de/lipics/
https://www.dagstuhl.de


6:2 On the Cryptographic Hardness of Local Search

successor assigned by S represents “the best” neighbor. Important problems that are known
to be PLS complete include finding a locally optimal max-cut [49] and finding pure Nash
equilibrium in congestion games [22].

As observed in [33], PLS belongs to the class TFNP of total search problems in NP; namely,
a local optimal solution always exists (and can be efficiently verified). As a result, it is
unlikely that PLS contains NP-hard problems, as this would imply that NP = coNP [33, 41].
This barrier is shared of course by other prominent subclasses of TFNP, perhaps the most
famous example being the class PPAD that captures the hardness of finding Nash equilibrium
in bimatrix games [18, 14]. Accordingly, researchers have turned to seek for alternative
evidence of hardness.

One natural place to look for such evidence is cryptography. Indeed, cryptography
typically relies on problems closer to the boundary of P than to NP hard problems. For
some subclasses of TFNP (such as PPP, PPA, and Ramsey) evidence of hardness has been
shown based on standard cryptographic assumptions [45, 12, 32, 36, 50]. Establishing the
hardness of PLS (and PPAD), however, has been far more elusive. Hubác̆ek and Yogev [29],
building on [7, 23], demonstrated a hard problem in PLS∊PPAD based on indistinguishability
obfuscation [4], a strong cryptographic primitive, yet to be constructed under standard
assumptions.2 Similar hardness was then shown by Choudhuri et al. [16] assuming hardness
of #SAT and the soundness of the Fiat-Shamir transform for the sumcheck protocol, which in
turn can be based on optimally-secure fully-homomorphic encryption against quasi-polynomial
attackers [13]. More recently, the same has been shown based on the hardness of iterated
squaring and soundness of Fiat-Shamir for the iterated-squaring protocol of Pietrzak [46] by
both Choudhuri et al. [15] and Ephraim et al. [21].

Basing the hardness of PLS (or PPAD) on standard assumptions remains an open problem.

1.1 Our Results
We provide new results regarding the hardness of PLS. Our first result shows worst-case
hardness of PLS based on the KPY assumption on bilinear groups and the randomized
Exponential Time Hypothesis (ETH). The KPY assumption was introduced recently by Kalai,
Paneth, and Yang [34] toward the construction of publicly-verifiable delegation schemes. The
assumption is similar in spirit to previous standard assumptions that generalize Decisional
Diffie Hellman (e.g., [8, 9]). It is polynomially falsifiable and holds in the generic group model.
Randomized ETH postulates that solving SAT in the worst case requires exponential-time
even for randomized algorithms [30].

I Theorem 1 (Informal). Under the KPY assumption on bilinear groups and randomized
ETH, PLS is hard in the worst case.

The result is, in fact, more general and shows a reduction of PLS hardness to a certain type
of incrementally-verifiable computation schemes (IVC) [51]. We then derive the required
IVC from the work of [34]. We can also show average-case hardness at the cost of assuming
superpolynomial hardness of the KPY assumption and average-case randomized ETH. See
further details in the technical overview.

Our second result is a construction of PLS instances that are unconditionally hard in the
random oracle model.

2 More accurately, they show a hard problem in the class Continuous Local Search (CLS), which is known
to be in PLS ∊ PPAD [19].



N. Bitansky and I. Gerichter 6:3

I Theorem 2 (Informal). Relative to a random oracle, Local-Search is unconditionally
hard-on-average.

Previously, Choudhuri et al. [16] showed hardness of CLS ⊆ PLS ∩ PPAD relative to a
random oracle, but their result is conditioned on hardness of #SAT (the construction
does not relativize with respect to this hardness and hence it cannot be derived from the
random oracle itself). Indeed, our construction is quite different from theirs. Whereas their
construction is based on the sum-check protocol [39] (which explains the non-black-box
reliance on #SAT hardness), ours comes from recent advancements in proofs of sequential
work motivated by blockchain applications [40, 17, 20].

The reliance on proofs of sequential work, in fact, translates to a result on the hardness of
parallelizing local search. Such hardness, in the random oracle model, was recently shown for
CLS (and in particular for both PLS and PPAD) by Ephraim et al. [21] further assuming that
repeated squaring modulo a composite is hard to parallelize [47]. Specifically, they construct
CLS instances that can be solved in some tuneable sequential polynomial time, but cannot be
solved much faster by parallel algorithms. Our result gives a similar kind of hardness for PLS
in the random oracle model, without relying on any unproven computational assumptions.
We elaborate on this in the technical overview below.

2 Technical Overview

To motivate our approach, we start by recalling previous approaches taken toward proving
PLS (or rather CLS) hardness.

2.1 Hardness via Incremental Computation
So far, the common approach toward arguing cryptographic hardness of PLS went through
an intermediate problem called Sink-of-Verifiable-Line (SVL) [1, 7]. An instance of SVL
consists of a successor circuit S and a verifier circuit V . The successor S implicitly defines a
step-by-step (or, incremental) computation st+1 := S(st) starting from a canonical source s0
and ending at a sink sT , for some superpolynomial T :

s0
S−→ . . .

S−→ sT

The verifier V(s∗, t) is promised to accept any s∗ as the t-th state if and only if it is correct,
namely s∗ = S(t)(s0). The goal is to find the sink sT = S(T )(s0), given (S,V).

It is not hard to see that solving SVL can be reduced to solving a local search problem in
PLS [29], and thus it is sufficient to prove the hardness of SVL.

Valiant’s Incrementally-Verifiable Computation and Uniqueness. A natural way to ap-
proach SVL hardness is Valiant’s notion of incrementally-verifiable computation (IVC) [51].
According to this notion, we can take a Turing machine computation given by a machine M
and input x with a configuration graph:

M0
x −→ . . . −→MT

x ,

and associate with each intermediate configuration M t
x a short proof πt, attesting to its

correctness. The proofs are incremental – the next proof πt+1 can be efficiently computed
from πt.

ITCS 2020



6:4 On the Cryptographic Hardness of Local Search

At first glance, this general notion seems to directly yield SVL hardness. Indeed, we can
take any polynomial-space machine M solving some hard search problem R on input x and
consider the corresponding incrementally-verifiable computation:

(M0
x , π0) S−→ . . .

S−→ (MT
x , πT ) .

Here the successor simply advances the computation of M and incrementally computes the
corresponding proofs. The SVL verifier is derived directly from the IVC verifier.

The reason that the above simple transformation does not work is that the IVC proofs
may not be unique. In particular, a correct intermediate configuration may have many
different accepting proofs attesting to its correctness, whereas SVL requires that only a
single string can be accepted as the t-th node (for any t). Choudhuri et al. [16] show that
the SVL uniqueness requirement can be somewhat relaxed and traded with computational
uniqueness meaning that it is computationally hard to find more than a single proof for any
given statement (even if such proofs exist).

So far, however, incrementally-verifiable computation with (even computational) unique-
ness has not been achieved under standard assumptions. This is, in fact, the case even for
specific (hard) computations, let alone for general ones.

2.2 Incremental Completeness
We show that the hardness of PLS does not require SVL hardness nor IVC with unique proof.
Rather, we observe that IVC with a conceptually simple incremental completeness property
suffices. Then we derive such IVC for polynomially-long computations from the delegation
scheme construction of Kalai, Paneth, Yang [34] and combine it with ETH to obtain PLS
hardness. We next explain the notion of incremental completeness and why it suffices. In
the next subsection, we explain how it is obtained.

Incremental-Complete IVC and PLS Hardness. An incremental complete IVC has the
property that given any accepting proof π for an intermediate state M t

x of the computation,
running the prover results in an accepting proof π′ for the next state M t+1

x . This differs
from Valiant’s original formulation where completeness is only guaranteed for the prescribed
proof generated by iteratively applying the prover t times.

Let us now describe how to construct hard Local-Search instances from incrementally-
complete IVC. Once again, we start from some hard computation given by a polynomial-space
machine M and instance x. Rather than considering a verifiable computation chain, we shall
consider a DAG with nodes of the form (t, C, π), where t is a timestamp, C is an alleged
configuration of M(x) at time t, and π is an IVC proof. We call such a node valid if the
corresponding proof is accepting. For simplicity, we assume for now that the IVC is also
perfectly sound, meaning that valid nodes are always such that C is the correct configuration
M t
x. Note that for every time t, there may very well be multiple corresponding valid nodes.

We can visualize this as multiple “parallel universes”, which the verifiable computation lives
in simultaneously. Incremental completeness says that in every such universe, as time moves
forward, the computation may proceed. In particular, by induction, we always reach a sink
of the form (T,MT

x , π) that contains the last state of the computation.
This naturally gives an LS instance. Valid nodes (t,M t

x, π) are given value t and are always
succeeded by another valid node (t+ 1,M t+1

x , π′) derived by advancing the computation and
incrementing the IVC proof. Invalid nodes are given value −1 and are succeeded by some
canonical source in the DAG (0,M0

x , Îľ), where Îľ is the empty proof, which by convention is



N. Bitansky and I. Gerichter 6:5

accepted as a proof forM0
x . The local maximums of the corresponding instance are exactly the

sinks of the DAG, which by incremental completeness are of the form (T,MT
x , π), containing

the last state. Therefore, finding a local-maximum reduce to solving the underlying hard
computational task given by the computation M(x).

Our actual construction does not assume perfect soundness of the IVC, but only compu-
tational soundness. There may exist so called fooling nodes (t, C∗, π∗) that pass verification
although C∗ is not the correct configuration M t

x. These nodes may be local maximums and
finding them may not reduce to solving the underlying problem. Nonetheless, finding fooling
local maximum corresponds to breaking the soundness of the IVC, which is computationally
infeasible.

2.3 Obtaining IVC with Incremental Completeness
Valiant [51] put forth a general approach toward constructing IVC by recursive proof
composition. Oversimplifying, the basic idea is that to move from the t-th configuration
C = M t

x and proof πt to the next configuration C ′ = M t+1
x and proof πt+1, the new proof

πt+1 asserts that:
1. There exists a proof π that passes IVC verification as a valid proof that C = M t

x (this
part is recursive in the sense that it relies on IVC verification for smaller times stamps),

2. C ′ is obtained from C by applying Mx’s transition function.
For this to be feasible, each “single-step proof” is computed using a succinct non-interactive
NP proof system where verification time (and in particular, the size of the proof) is fixed and
is not affected by the complexity of the NP relation. We observe that any IVC construction
following the above blueprint is incrementally complete by definition as long as the succinct
NP proof system used has perfect completeness.

Succinct Proof Systems. Succinct proofs for NP with unconditional soundness are unlikely
to exist [26, 27]. Accordingly, Valiant suggested to instantiate the blueprint using computa-
tionally sound succinct arguments. This brings about some extra complications in following
the blueprint. For once, proving that a previous proof exists is meaningless in the case of
computational soundness. Rather we need the guarantee that a proof exists and can be
efficiently found. Such systems are known as succinct non-interactive arguments of knowledge
(SNARKs) and admit an efficient knowledge extractor that can efficiently extract a witness
from a convincing prover.

Using such SNARKs enables the construction of IVC for arbitrary poly-time computa-
tions (or superpolynomial ones, if the SNARK is superpolynomially secure) [51, 5], and the
corresponding constructions are incrementally complete by the fact that the underlying
SNARKs are perfectly complete. (The actual constructions are somewhat different from the
described blueprint; in particular, to deal with issues such as blowup in knowledge extraction
complexity, they aggregate proofs in a tree-like fashion rather than a chain, in order to reduce
the depth of the recursion. Incremental completeness holds just the same.)

Following the above, we can obtain an incrementally-complete IVC, and thus PLS hardness
from SNARKs. However, the existence of SNARKs is a strong non-falsifiable assumption. It is
only known under non-standard knowledge assumptions and its construction from standard
assumptions is subject to barriers [24, 6].

Incrementally-Complete IVC from Weaker Succinct Arguments. In a recent work, Kalai,
Paneth, and Yang [34] considered a relaxation of SNARKs called quasi-arguments that instead
of standard knowledge extraction only requires a certain weaker no-signaling extraction

ITCS 2020



6:6 On the Cryptographic Hardness of Local Search

requirement. Unlike SNARKs, such arguments are not subject to any known lower bounds,
and were in fact constructed from the learning with errors assumption in their privately-
verifiable form [35, 44, 11, 3] and recently also in their publicly-verifiable form based on the
so called KPY assumption in bilinear groups [34].

Furthermore, Kalai, Paneth, and Yang show that similarly to SNARKs such quasi-
arguments can, in fact, be recursively composed toward verifying a long computation,
provided that the computation is deterministic. Their explicit goal was not to construct
IVC but rather to bootstrap quasi-arguments with a long common reference string (CRS)
to succinct arguments with a short CRS. However, this is done by implicitly constructing
an IVC (this connection is also apparent in previous constructions of SNARKs with a short
CRS from ones with a long CRS [5]). The resulting IVC, like other IVCs based on recursive
composition, is incrementally complete.

The Class of Supported Computations and the Reliance on ETH. In its native form, the
IVC derived from the KPY construction supports computations of arbitrary polynomial
length T = ÎťO(1) in the security parameter Îť, with fixed prover-verifier running time (say,
Îť). However, as explained earlier, to get PLS hardness, we would like to apply the IVC for a
hard (and thus superpolynomial) computation.

To circumvent this difficulty, we employ a fine-grained reduction. The idea is to construct
instances which are tailor-made to be hard for LS algorithms of a specific polynomial running
time. Fix any constant c > 0 and nc-time algorithm A that supposedly solve LS (here n is
the size of the LS instance (S,F)). Consider a search problem R and a Turing machine M
that solves it in polynomial time T (Îť), while no randomized algorithm can solve it in time
T δ for constant δ < 1. If we can bound the blowup of the IVC reduction by at most T δ/c,
we can use A to construct a randomized adversary A′ that solves R in time T δ and get a
contradiction.

The blowup of the IVC reduction is polynomially related to (a) the input size, (b) the
space used by M , and (c) the efficiency of the IVC scheme. Accordingly, we require a
computation where there is an arbitrarily large (polynomial) gap between the space used and
the hardness of the underlying problem. To this end, we use the randomized ETH assumption.
By appropriately choosing the size of the underlying SAT instance, we get computations
that can be solved using fixed-space and some polynomial time via brute-force but not in
much faster polynomial time, even by randomized algorithms. To bound the blowup due to
the IVC efficiency, we follow the efficiency analysis by [34] and adapt it to the incremental
setting. (In the body, we show the above in the non-uniform setting: assuming non-uniform
ETH and using standard non-uniform derandomization techniques while taking special care
to bound the associated blowup.)

We note that the above only gives worst-case hardness. That is, we do not show a
single distribution that is hard for all polynomial-time algorithms. Assuming slight super-
polynomial security of the KPY assumption and average-case randomized ETH, we can get
average-case PLS hardness by essentially the same reduction (in fact, we can slightly weaken
average-case ETH to a slightly subexponential time hypothesis).

2.4 Unconditional Hardness in the Random Oracle Model
Our second result, in the random model, is based on recent advancements in proofs of
sequential work (PoSW) [40]. Roughly speaking, in a PoSW, the prover is given a statement
χ and a time parameter T , and can generate a corresponding proof π by making T sequential
steps. The soundness requirement is that provers that make ďż˝ T sequential steps, will fail to



N. Bitansky and I. Gerichter 6:7

generate a valid proof for χ, except with negligible probability (namely, proof computation is
not parallelizable). The construction we present relies on the PoSW of Cohen and Pietrzak
[17] and its extension by DĂśttling, Lai, and Malavolta [20] to so called incremental proof
of sequential work; both are proven sound in the random oracle model. We now move to
recalling how these systems work, and explain how we derive from them hard PLS instances
relative to random oracles.

The CP PoSW. To construct a PoSW, Cohen and Pietrzak [17] suggest an elegant tree
labeling procedure that is inherently sequential. They consider a binary tree whose edges are
directed from the leaves toward the root. In addition, they add directed edges from every
node ` having a sibling r on the right, to all the leaves in the tree rooted at r. We call this
the CP graph (see Figure 1 in Section 6 for an illustration). The nodes of the CP graph are
then given random labels as follows: the label of any given node is obtained by applying a
random oracle Hχ = H(χ, ·) to the labels of its incoming nodes (the oracle is seeded with χ
to guarantee an independent oracle for every statement). Intuitively, the added edges enforce
that in order to compute the labels of some subtree rooted at some r, it is first necessary to
compute the labels of its left sibling `; in this sense, labeling must be done sequentially.

To turn this into an actual proof of sequential work π for χ, the prover publishes the
label of the root of the entire tree. The verifier then responds with random challenge leaves
to which the prover answers by providing all the labels in the corresponding paths toward
the root along with the labels of the siblings along the path, as in standard Merkle tree
authentication (indeed here the tree serves both the purpose of of a commitment and of
enforcing the sequential nature). Finally, they make the proof non interactive by using the
Fiat-Shamir transform. Cohen and Pietrzak prove that to successfully compute an accepting
proof, a prover must sequentially call the random oracle ≈ T times, where T is the size of
the tree.

Incremental PoSW and the DLM Construction. Cohen and Piertzak further show that
the standard streaming algorithm for Merkle commitments [42], can also be applied to their
labeling procedure. That is, one can keep track of a small amount of nodes (about log T ),
each a root of some tree in a gradually growing forest, and when needed, merging two
nodes on the same level. In other words, the CP labeling can be done by an incremental
computation with small space.

One thing that is of course missing toward getting PLS hardness is verifiability of the
corresponding intermediate states. One NaĂŻve idea toward such local verifiability is to apply
the CP proof strategy for each subtree in the incremetal labeling process. Indeed, each such
subtree is, in fact, CP labeled on its own, so we can use Fiat-Shamir to compute random
challenges for that particular subtree. While this is a step in the right direction it is still
not enough for the goal of PLS hardness, since the intermediate proofs themselves are not
computed incrementally – computing each local proof may take time proportional the size of
the corresponding subtree.

DĂśttling, Lai, and Malavolta [20] suggested a neat idea to make the CP proofs incremen-
tally computable.3 Roughly speaking rather than sampling fresh challenges for each subtree,
they suggested to derive them at random from the previously computed challenges of this
subtree. In a bit more detail, whenever merging two subtrees rooted at ` and r into a new

3 They were motivated by blockhains and aimed to make PoSW a process that can be advanced in a
distributed fashion by different parties.

ITCS 2020



6:8 On the Cryptographic Hardness of Local Search

(taller) subtree, we assume by induction that each of the two already has a set of correspond-
ing challenges S` and Sr, where say the size of each one is some parameter k. Then, for the
new subtree, rooted at their parent v, we choose a new set Sv of k challenges by choosing k
challenges at random from the 2k challenges in S` ∪ Sr (this is again done non-interactive
using Fiat-Shamir). Each of the challenges is again just a Merkle authentication path, which
can be easily augmented to an authentication path for v. They prove that this choice of
challenges guarantees, for every intermediate state, essentially the same soundness as the
original CP construction guarantees for the final state.

Incremental Completeness and PLS Hardness. What we get from the DLM incremental
PoSW (in the random oracle) is somewhat analogous to an IVC system in the standard
model. However, while in the standard model we applied general IVC over some long (hard)
computation, here there is no such underlying hardness. Rather, the difficulty is only in
computing the accepting proofs themselves. Similarly to our standard model approach, here
too we can address the concept of incremental completeness. Indeed, we observe that merging
two accepting proofs in the DLM construction always yields an accepting proof. From
here incremental completeness follows. Formally, we need to slightly augment the DLM
construction to enforce consistency among different subtrees in a forest to guarantee such
incremental completeness (see Section 6 for the details).

Choosing the parameters appropriately, yields problems in PLS relative to a random
oracle which are exponentially hard-on-average. This translates to sub-exponential hardness
of the canonical LS probalem (due to polynomial blowup of the reduction). Also, by choosing
the size of the tree to be a polynomial of our choice, we get search problems in PLS which
are moderately hard but “depth-robust” in the sense that they cannot be solved much faster
by parallel algorithms [21]. This follows from the sequential hardness of DLM.

2.5 More Related Work on Total Search Problems
The class TFNP was introduced by Megiddo and Papadimitriou [41]. They observed that
TFNP is unlikely to include NP hard problems as this would imply that NP = coNP.
Furthermore, it is strongly believed that TFNP does not have complete problems (see for
instance discussion in [25]). Toward understanding of the complexity of total search problems,
Papadimitriou [45] introduced several “syntactic” subclasses of TFNP that cluster problems
according to the mathematical argument used to establish their totality. Recently, Goldberg
and Papadimitriou [25] presented a subclass called provable TFNP that contains previously
defined subclasses (and can be seen as generalizing them) and admits complete problems.

A long line of works have investigated the complexity of TFNP and its subclasses, searching
for efficient algorithms on one hand and evidence of hardness on the other. As explained
earlier in the intro, cryptography is a natural place to look for such evidence. Indeed,
basing the hardness of TFNP or its subclasses, on standard cryptographic assumptions, has
been successful in several cases. For example, Papadimitriou [45] observed that PPP is
hard assuming one-way permutations or collision-resistant hash functions, and Jeřábek [32],
building on the work of Buresh-Oppenheim [12], demonstrated the hardness of PPA assuming
factoring is hard. Hubáček, Naor and Yogev [28] showed TFNP-hardness assuming any
average-case hard NP language exists (in particular one-way functions) and derandomization
assumptions. Komargodski, Naor, and Yogev [37] showed that hardness of the class Ramsey
is equivalent to the existence of multi-collision resistant hash functions.

As discussed earlier, demonstrating hardness for PPAD and PLS has been more challenging
and so far only achieved under non-standard cryptographic assumptions. Trying to explain
our failure so far to base such hardness on standard cryptographic primitives, Rosen, Segev



N. Bitansky and I. Gerichter 6:9

and Shahaf [48] show that TFNP hard instances constructed in a black box way from random
oracles (or some variants thereof) must have a nearly exponential number of solutions (which
is indeed the case in our result in the random oracle model).

Finally, we note that in the smooth complexity setting, several PLS complete problems,
with natural noise distributions, have been shown to be solvable in smooth polynomial-time.
This include finding locally optimal Max-Cut [2] and finding pure Nash equilibrium in
network coordination games [10]. These algorithms suggest an explanation of why local
search may be empirically easy, while hard instances exist under reasonable assumptions and
can be sampled.

Organization

In Section 3, we recall some preliminaries including the definition of PLS. In Section 4, we
construct a computational reduction from a search problem having an incremental complete
IVC to LS. In Section 5, we instantiate the computational reduction under the KPY
assumption and ETH to demonstrate PLS hardness in the plain model. In Section 6, we
argue the hardness of PLS relative to a random oracle.

3 Preliminaries

Notation. Throughout, Îť will denote security parameters. When the input size is not the
security parameter, we denote it by n. For a ≤ b integers we denote by [a, b] the set {a, ..., b}
and by [a] the set [1, a].

3.1 PLS Definition

The complexity class polynomial local search (PLS) consists of all TFNP search problems
polynomial-time reducible to the Local-Search problem [33, 29] we denote by LS.

I Definition 3 (Local-Search). The search problem LS is the following: given two
polynomial-size circuits S : {0, 1}n → {0, 1}n and F : {0, 1}n → N, find a string v ∈ {0, 1}n
such that F(S(v)) ≤ F(v).

We refer to S as the successor circuit and to F as the value circuit. Intuitively, the circuits
S and F could be seen as representing an implicit DAG over {0, 1}n. In this graph, a node
v is connected to u = S(v) if and only if F(u) > F(w). This is a DAG since F induce
a topological ordering. Notice also that every sink corresponds to a local maximum with
respect to F . With this perspective, the totality of LS follows from the fact every finite DAG
has a sink.

Oracle aided PLS. We denote by CO = {COÎť } an oracle aided circuit family. That is a
circuit family with oracle gates to Oλ : {0, 1}r(λ) → {0, 1}`(λ). The complexity class PLSO

relative to an oracle O, is naturally defined as all TFNPO search problem polynomial-time
reducible to LSO.

I Definition 4 (Oracle Aided Local-Search). The search problem LSO is the following:
given two polynomial-size, oracle aided, circuits SO : {0, 1}n → {0, 1}n and FO : {0, 1}n → N,
find a string v ∈ {0, 1}n such that FO(SO(v)) ≤ FO(v).

ITCS 2020



6:10 On the Cryptographic Hardness of Local Search

4 PLS Hardness from IVC

In this section, we give a computational reduction from search problems having an IVC with
incremental completeness to LS. This, in turn, establishes that any (worst/average-case)
hard search problem, having an IVC with incremental completeness, implies the hardness
of PLS (in the worst/average-case, respectively). We start by formally defining IVC with
incremental completeness.

4.1 IVC with Incremental Completeness
Conventions. Let M be a Turing machine with T = T (Îť) and S = S(Îť) bounds on its run
time and space, respectively, for input of length Îť. Throughout, we assume w.l.o.g that M
always makes exactly T steps and the size of a configuration is exactly S. Let x ∈ {0, 1}Ν be
an input to M , we denote by M t

x ∈ {0, 1";"""date"",""2019-12-13T17:22:29Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""On the Cryptographic Hardness of Local Search""
""xmp:CreatorTool"",""LaTeX with lipics-v2019.cls and hyperref.sty""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""LIPIcs, Vol.151, ITCS 2020; Copyright (C) Nir Bitansky and Idan Gerichter; licensed under Creative Commons License CC-BY""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with lipics-v2019.cls and hyperref.sty""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""On the Cryptographic Hardness of Local Search""
""modified"",""2019-12-13T17:22:29Z""
""cp:subject"",""LIPIcs, Vol.151, ITCS 2020; Copyright (C) Nir Bitansky and Idan Gerichter; licensed under Creative Commons License CC-BY""
""pdf:docinfo:subject"",""LIPIcs, Vol.151, ITCS 2020; Copyright (C) Nir Bitansky and Idan Gerichter; licensed under Creative Commons License CC-BY""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""Nir Bitansky, Idan Gerichter""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.20 (TeX Live 2019) kpathsea version 6.3.1""
""meta:author"",""Nir Bitansky, Idan Gerichter""
""trapped"",""False""
""meta:creation-date"",""2019-12-13T17:22:29Z""
""created"",""2019-12-13T17:22:29Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2019-12-13T17:22:29Z""
""resourceName"",""LIPIcs-ITCS-2020-6.pdf""
""Author"",""Nir Bitansky, Idan Gerichter""
""producer"",""pdfTeX-1.40.20""
""pdf:docinfo:producer"",""pdfTeX-1.40.20""
""pdf:unmappedUnicodeCharsPerPage"",""1"",""1"",""1"",""2"",""2"",""2"",""3"",""2"",""3"",""21"",""44"",""10"",""29"",""16"",""11"",""22"",""18"",""10"",""22"",""17"",""14"",""30"",""28"",""16"",""20"",""10"",""0"",""0"",""0""
""Keywords"",""Cryptography, PLS, Lower Bounds, Incremental Computation""
""access_permission:modify_annotations"",""true""
""dc:creator"",""Nir Bitansky, Idan Gerichter""
""dcterms:created"",""2019-12-13T17:22:29Z""
""Last-Modified"",""2019-12-13T17:22:29Z""
""dcterms:modified"",""2019-12-13T17:22:29Z""
""title"",""On the Cryptographic Hardness of Local Search""
""Last-Save-Date"",""2019-12-13T17:22:29Z""
""pdf:docinfo:keywords"",""Cryptography, PLS, Lower Bounds, Incremental Computation""
""pdf:docinfo:modified"",""2019-12-13T17:22:29Z""
""meta:save-date"",""2019-12-13T17:22:29Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.20 (TeX Live 2019) kpathsea version 6.3.1""
""Content-Length"",""696641""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Nir Bitansky, Idan Gerichter""
""dc:subject"",""Cryptography, PLS, Lower Bounds, Incremental Computation""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""29""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""2673"",""2914"",""2411"",""3065"",""3096"",""3174"",""3138"",""3470"",""2266"",""2269"",""2094"",""1853"",""2413"",""2064"",""2386"",""2532"",""1813"",""1604"",""2471"",""1689"",""1978"",""2329"",""1910"",""2076"",""1983"",""2701"",""3503"",""3322"",""1377""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""Cryptography, PLS, Lower Bounds, Incremental Computation""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2019-12-13T17:22:29Z""
";https://scholar.google.ch/scholar?start=930&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098747-69;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;IT Governance Considerations for Permissioned BlockchainsIT Governance Considerations for Permissioned Blockchains;J Lineros ; Journal of Emerging Technologies in …, 2020  meridian.allenpress.com;;"… inter-network operability (Hearn 2016). Oracles (real-world Internet of Things [IOT]

monitoring devices … 2016). With this functionality, Corda and Quorum represent the

permissioned blockchain leaders in cryptocurrency. Quorum. Based …";Autres articles;;null;;;;https://scholar.google.ch/scholar?start=610&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098870-350;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;[PDF][PDF] A Penalty-Aware Cloud Monitoring System based on Blockchains;C Dienbauer, B Pittl, W Mach, E Schikuta ;2020 iiwas.org;;"… investigates in incentive-based blockchains to provide data quality [2]. When a blockchain needs

to … The capabilities of oracles slightly differ: For example, Ethereum5 prohibits that smart contracts

can … contract with the injected data can then be used as an oracle and queried by …";Autres articles;;[PDF] iiwas.org;http://www.iiwas.org/conferences/momm2020/proceedings/iiwas-papers/p154-dienbauer.pdf;"
A Penalty-Aware Cloud Monitoring System based on
Blockchains

Christian Dienbauer
a1026759@univie.ac.at
University of Vienna

Vienna, Austria

Benedikt Pittl
benedikt.pittl@univie.ac.at

University of Vienna
Vienna, Austria

Werner Mach
werner.mach@univie.ac.at

University of Vienna
Vienna, Austria

Erich Schikuta
erich.schikuta@univie.ac.at

University of Vienna
Vienna, Austria

ABSTRACT
Today, traded cloud services are described by service level agree-
ments that specify the obligations of providers such as availability
or reliability. Violations of service level agreements lead to penalty
payments. The recent development of prominent cloud platforms
such as the re-design of Amazon’s spot marketspace underpins a
trend towards dynamic cloud markets where consumers migrate
their services continuously to different marketspaces and providers
to reach a cost-optimum. This leads to a heterogeneous IT infrastruc-
ture and consequently aggravates the monitoring of the delivered
service quality. Hence, there is a need for a transparent penalty
management system, which ensures that consumers automatically
get penalty payments from providers in case of service violations.

In the paper at hand, we present a cloud monitoring system that
is able to execute penalty payments autonomously. In this regard,
we revert to smart contracts hosted on blockchains. They contin-
uously monitor cloud services and trigger penalty payments to
consumers in case of service violations. We implemented the pre-
sented approach with the IBM Hyperledger Fabric framework and
created a use case with Amazon’s cloud services as well as Azures
cloud services to illustrate the universal design of the introduced
approach.

CCS CONCEPTS
• Information systems→ Information systems applications;
• Computer systems organization→ Architectures.

KEYWORDS
Cloud Monitoring, Smart Contracts, Cloud Computing
ACM Reference Format:
Christian Dienbauer, Benedikt Pittl, Werner Mach, and Erich Schikuta. 2020.
A Penalty-Aware Cloud Monitoring System based on Blockchains. In The
22nd International Conference on Information Integration and Web-based

Permission to make digital or hard copies of all or part of this work for personal or
classroom use is granted without fee provided that copies are not made or distributed
for profit or commercial advantage and that copies bear this notice and the full citation
on the first page. Copyrights for components of this work owned by others than ACM
must be honored. Abstracting with credit is permitted. To copy otherwise, or republish,
to post on servers or to redistribute to lists, requires prior specific permission and/or a
fee. Request permissions from permissions@acm.org.
iiWAS ’20, November 30-December 2, 2020, Chiang Mai, Thailand
Š 2020 Association for Computing Machinery.
ACM ISBN 978-1-4503-8922-8/20/11. . . $15.00
https://doi.org/10.1145/3428757.3429130

Applications & Services (iiWAS ’20), November 30-December 2, 2020, Chiang
Mai, Thailand. ACM, New York, NY, USA, 9 pages. https://doi.org/10.1145/
3428757.3429130

1 INTRODUCTION
Cloud providers such as Amazon and Azure sell their datacenter
resources in the form of services. For the description of the services,
so-called Service Level Agreements (SLAs) are used [17]. They are
specifications that define, inter alia, details about the offered service
such as availability and reliability. Violations of SLAs lead to penalty
payments, and so consumers are interested in monitoring the ser-
vice performance. Therefore, cloud providers such as Amazons offer
monitoring platforms like Amazon Cloudwatch that provide APIs to
query the performance metrics of the service. Besides, several third-
party cloud monitoring platforms are existing such as dynatrace1,
datadog2 or AppDynamics3. The vision of a monitoring platform
that also manages penalty payments is still unrivaled [13]. For the
establishment of such a platform in industry not only machine-
readable SLAs such as described in [13] are necessary, but also the
transparent management of penalty payments has to be ensured.
Hence, in the last years, neutral third parties were introduced that
are responsible for confirming service violations and transferring
penalty payments to consumers [11, 28]. Even such neutral third
party approaches have structural weaknesses as Robert Sams sum-
marizes with three sins [12]: sin of commission, sin of deletion and
sin of omission. Nowadays, the scientific community reverts to neu-
tral consensus finding approaches among untrusted participants
which are technically realized by the blockchain technology. For
example, the authors of [21] introduced an approach for managing
and modifying SLA terms with blockchains - penalty management
for SLA violations was neglected.

The paper at hand focuses on the development of a blockchain-
based, penalty-aware cloud monitoring platform. Thereby we apply
so-called smart contracts, which are programs executed on the
blockchain. A first step towards such systems was introduced in
the short paper [15] where a pure provider-centric smart contract
was introduced - see related work. In contrast to that, the approach
introduced in that paper treats a smart contract as a bilateral agree-
ment between consumers and providers. Therefore, consumers and

1https://www.dynatrace.com
2https://www.datadoghq.com/
3https://www.appdynamics.com/

https://doi.org/10.1145/3428757.3429130
https://doi.org/10.1145/3428757.3429130
https://doi.org/10.1145/3428757.3429130


iiWAS ’20, November 30-December 2, 2020, Chiang Mai, Thailand Dienbauer et al.

providers have to register the SLAs of the traded cloud services in
a smart contract, including corresponding commonly trusted cloud
monitoring authorities. The smart contract uses them to monitor
the performance of the cloud services and automatically transfers
penalties to the consumer in case of SLA violations. This ensures
that consumers get penalties immediately for service violations
while providers can profit from a clear and transparent monitoring
approach. The technical feasibility of our approach is demonstrated
by a smart contract deployed on theHyperledger Fabric Blockchain4
that uses arbitrary monitoring services for detecting SLA violations
and consequently executing penalty payments. Within this paper,
we use cloud services as well as monitoring APIs both fromAmazon
and from Azure.

The remainder of the paper is structured as follows: Founda-
tions and related work are introduced in Section 2. The concept
of the penalty-aware cloud monitoring platform is presented in
Section 3, followed by an introduction of our implementation with
the IBM Hyperledger Fabric Blockchain, Amazon EC2, and Azure
in Section 4. A discussion about the presented concept is given in
Section 5. The paper closes with a conclusion in Section 6.

2 FOUNDATIONS AND RELATEDWORK
This section is structured along two parts. The first part describes
foundations of the blockchain technology. In the second part, re-
lated cloud monitoring approaches are introduced.

With the rising popularity of the Bitcoin in mid-2017, the under-
lying blockchain technology gained in attraction. This technology
is not limited to cryptocurrencies and so organizations from various
domains started to identify reliable business models enabled by the
blockchain [5]. A typology of emerging blockchain applications
with regards to the domains where they are applied is presented
in [8, 29]. Due to the decentralized nature with no need for inter-
mediaries, the blockchain technology can handle transactions in
different markets and consequently reduces friction costs [5, 6].
An Economist article, The Trust Machine, considers the blockchain
technology as a solution for establishing trust and the antecedents
of trust including confidence, integrity, reliability, responsibility
and predictability [5]. While sometimes blockchains are described
as trust-less [2], other authors such as [10] state that there is a shift
of trust from current intermediaries to the technical implementa-
tion of blockchain systems. Limitations of the blockchain such as
scalability, energy usage, and growing complexity are summarized
in [24]. While data once stored within a blockchain is immutable,
it does not mean that this data is always valid. Therefore, current
research investigates in incentive-based blockchains to provide data
quality [2]. When a blockchain needs to query data from the outside
world, it uses so-called oracles. The capabilities of oracles slightly
differ: For example, Ethereum5 prohibits that smart contracts can
query external sources, and so the data needs to be stored within a
smart contract first [3]. The smart contract with the injected data
can then be used as an oracle and queried by other smart contracts.
Hyperledger Fabric, as a contrary example, uses general-purpose
programming languages and allows that data can be retrieved from
anywhere. Important thereby is, that no matter by whom this data

4https://www.ibm.com/blockchain/hyperledger
5https://ethereum.org/

is queried and regardless of time, the results need to be the same to
ensure a deterministic behavior of the blockchain.

Today, most of the monitoring platforms are cloud provider-
specific, limiting the monitoring of heterogeneous IT infrastruc-
tures, as can be found in smart city architectures and industry 4.0 [4].
This can enable data-driven applications that require reliable com-
munication models to operate more efficiently [9]. Complex cloud
service compositions are currently hard to monitor with existing
monitoring platforms, and so in [16] a generic framework to moni-
tor the performance of services deployed on different providers is
presented. To collect data from the services, the framework suggests
a client-server approach, where agents are deployed together with
the service that should be monitored: Those agents can be accessed
by a centralized monitoring platform to retrieve data of a monitored
service. A similar approach in the context of edge computing is
presented in [4]. There, an architecture divided into management
and worker layer is suggested. The management layer provides
functionalities to measure the activities of the edge nodes in the
network to distribute workloads based on different algorithms.

An approach for monitoring data streams in distributed systems
with the focus on communication-efficiency and data privacy can
be found in [19]. The system collects information about different
components and sets the granularity based on a given threshold by
a centralized monitoring unit. Such centralized monitoring systems
suffer from a single point of failure and therefore a distributed
agent-based monitoring system to handle multi-tenant service-
based systems can be used [27]. As a challenge of servicemonitoring
is the system overhead of monitoring tools and so that the collection
of data should be done in a resource-effective manner [23].

To foster the quality of services and the reliability business pro-
cesses that are based on those, Service Level Agreements (SLAs)
between a service provider and consumer are defined [7]. As SLAs
are legally binding contracts, they should be audited by an in-
stance that is trusted by all participants. While conventional SLA
trust models are centrally configured, deployed, and maintained,
approaches to define SLAs using smart contracts can be found
in [1, 7, 14, 18, 20, 25]. A conceptual blockchain-based framework for
SLA management is presented in [1] that gives a general overview
of this topic and addresses the challenge of trust between all par-
ticipants and argues that no single party should have control over
the SLA lifecycle. While in traditional SLA approaches service con-
sumer need to detect abnormalities and check SLA violations this
leads to an extensive manual process including personnel and cap-
ital resources [1, 14]. An approach for automated compensation
of SLAs based on smart contracts can be found in [18] and com-
pare their approach to existing solutions with regards to human-
computer interaction. A system architecture in the context of fog
computing can be found in [7] that provides IoT client devices
with the means to explore the best-suited fog nodes via smart con-
tracts by considering the reputation and credibility based on SLA
requirements.

Current approaches try to address today’s requirements of het-
erogeneous and decentralized infrastructures by agent-based sys-
tems with either a centralized unit or a wholly distributed approach
and mention the challenges of data privacy and communication
efficiency. Those approaches are usually isolated systems as the
data is subject to a single entity with a lack of transparency. It is



A Penalty-Aware Cloud Monitoring System based on Blockchains iiWAS ’20, November 30-December 2, 2020, Chiang Mai, Thailand

hard for organizations to get reliable information about the cur-
rent and past state of their IT infrastructure [22]. Consequently,
consumers are forced to implement systems to gather information,
which results in additional costs and the burden of proofing the
lack of quality [1, 14].

While approaches exist to define Service Level Agreements us-
ing smart contracts without the need to rely on a single party and
automate the way to identify SLA violations, these approaches are
either conceptual or lack the implementation of a penalty mech-
anism. Approaches mentioned in [1, 18] would use Ethereum as
the underlying blockchain technology but miss the part on how to
inject service metrics into smart contracts to trigger events while
preserving a deterministic behavior of the blockchain. Our goal was
to implement a monitoring system for a multiple service provider
where SLA can be defined. Compared to reviewed approaches we
implemented a mechanism to define SLAs and trigger penalties
if those are violated. The authors of [15] introduce a concept of
a blockchain based cloud monitoring system without a concrete
implementation. Thereby, the provider creates a smart contract
that manages a list of consumers - in case of a service violation ser-
vice coins are transferred to consumers. Motivated by the vision of
billing consumers with smart contracts, the role of the consumer
is neglected: it neither has to acknowledge the smart contract nor
does it acknowledge the used monitoring services.

3 CLOUD MONITORINGWITH SMART
CONTRACT

A traditional cloud monitoring scenario is presented in Figure 1a.
First, the consumer purchases a service from a provider (1) then
both, consumer and provider use services to monitor the perfor-
mance of traded service (2). As soon as the consumer observes a
service violation, it claims a penalty payment from the provider
(3). Finally, the provider transfers the penalty payments to the con-
sumers’ bank (4). The traditional monitoring scenario comes with
two drawbacks: First, the identification of a service violation can
lead to contradictions results as both, the consumer and the provider
could use separate monitoring services. Second, the scenario re-
quires a trusted third party such as the bank which is responsible
transferring penalty payments.

To tackle those issues the paper introduces a cloud monitoring
system based on blockchains. It uses smart contracts that are respon-
sible for processing data from monitoring services and executing
penalty payments in case of identified cloud service violations. The
following two parts are essential for such a smart contract.

• Monitoring Service.
A smart contract cannot monitor the cloud service directly.
Therefore, it has to make use of a monitoring service that
returns performance metrics. Such services are offered by
cloud providers such as Amazon6 but also by independent
monitoring service providers such as datadoghq7. Both, the
consumer and the provider have to agree on the selected
monitoring service. Even multiple monitoring services could
be used in parallel, whereby the smart contract has to decide
which value is used in the case of contradictory results. In

6https://aws.amazon.com/de/cloudwatch/
7https://www.datadoghq.com

the rest of the paper, the monitoring services are explicitly
referred to as monitoring services to distinguish them from
the traded cloud service, which is termed service.

• Wallet.
The smart contract is a neutral entity that is trusted by both,
consumer and provider. To guarantee transparent and fast
penalty payments, the smart contract needs a wallet. In-
stead of directly transferring the service fee to the provider,
the consumer has to pay it by transferring tokens8 to the
smart contract. Those tokens are stored in the wallet of the
smart contract. In the case of service violations, tokens are
transferred back to the consumer. The remaining tokens are
transferred to the provider after the contract period expired.

Figure 1b introduces an exemplary scenario in which a cloud
provider hosts the service used by the consumer. The numbers in
the following enumeration refer to the numbers in the figure.

(1) A consumer decided to use a cloud service from a provider
for a certain period of time. For the autonomous penalty
management, the consumer and the provider create a smart
contract. The provider adds endpoints of the used monitor-
ing services to it. They are used by the smart contract for
monitoring the service performance. The consumer agrees
to use the service by transferring the service fee in the form
of tokens to the smart contract. They are stored in the smart
contract’s wallet.

(2) The consumer uses the service. The service is monitored by
the monitoring services defined in the smart contract.

(3) Service violations detected by the monitoring service are
accessible for the smart contract. If multiple monitoring
services are used, the smart contract has to resolve contra-
dictory results to determine if a service violation occurred.
This conflict resolution is part of the smart contract, so both
the consumer and the provider are aware of it.

(4) If the smart contract detects a service violation, it automati-
cally transfers penalty payments from its wallet to the con-
sumer. After the contract period between consumers and
providers expired, the remaining tokens in the wallet of the
smart contract are transferred to the provider. If no service
violations occur, all tokens representing the service fee are
transferred to the provider.

The introduced approach has several benefits over approaches
where non-blockchain based software solutions are employed for
penalty management. (i) First of all, smart contracts are deployed
and executed on the blockchain and consequently on a neutral plat-
form while typical software solutions have to be hosted on a server.
There, the availability, as well as the execution, are not guaranteed.
(ii) Further, smart contracts are participants of the blockchains,
which means that they can send and receive tokens such as money.
For the realization of non-blockchain based software, a trusted
third party such as a bank would be necessary. (iii) Trusted third
parties charge fees and require time for executing payments. On the
blockchain, these fees for trusted third parties are not relevant. The
consumer gets penalty payments automatically and immediately
on detected service violations. (iv) Smart contracts are immutable,
which means that the code cannot be modified after it is deployed
8tokens could be money but also other trade-able entities



iiWAS ’20, November 30-December 2, 2020, Chiang Mai, Thailand Dienbauer et al.

(a) Traditional cloud monitoring scenario (b) Blockchain-based cloud monitoring scenario

Figure 1: Cloud monitoring scenarios

and so the approach is appropriate for untrusted consumers and
providers.

The consumers have to transfer the service fee upfront to the
smart contract. This implies that the consumer has to pre-pay the
complete service fee while the provider gets the remaining service
fee at the end of the contract period. Especially for high service fees
or long contract periods, this might cause financial embarrassment.
In such cases, the consumer and the provider could agree to transfer
only parts of the payments to the smart contract.

4 IMPLEMENTATION
This section introduces the implementation of the scenario that is
shown in Figure 2. It distinguishes between three organizations:
two cloud service providers and one consumer. In the scenario, one
service provider is Amazon, the other service provider is Microsoft
Azure. The consumer uses a virtual machine, which represents the
traded cloud service, from both providers. For each cloud service, a
smart contract is instantiated. It has access to a monitoring service
that is hosted by the corresponding provider. Those monitoring ser-
vices act as oracles for the smart contract and enable a deterministic
behavior of the states in the blockchain.

Different blockchain technologies can be used for the implemen-
tation of the scenario. For the selection of appropriate blockchain
technology to implement the envisioned penalty-aware cloud mon-
itoring platform, we considered the blockchain-selection guide-
line [26]. As the participants’ identities will be established before
purchasing a service and data of services does not need to be pub-
licly verified, we decided to use a private permissioned blockchain.
A private permissioned blockchain will guarantee that service data
will only be accessible for the users specified in an endorsement
policy: In the implemented scenario these are the service provider
and the consumer. Transaction fees for processing data are not
relevant for private blockchains. For the presented use-case we
used the Hyperledger Fabric framework9, which supports the us-
age of general-purpose programming language for writing smart
contracts, or chaincode as they call them, to implement any con-
ceivable logic.

Figure 3 shows the technical architecture of the implemented
scenario. It consists of the smart contracts, monitoring service
integration code and the core environment, which are described in
the following section.

9https://www.hyperledger.org/use/fabric

Peer Nodes, or short peers, are a fundamental part of a blockchain
network and inherit a cryptographic identity given by a certificate
authority. With this identity, peers can be authenticated in the
network and, with regards to the endorsement policy, join certain
channels. A channel is a sub-net of the blockchain network and
enables private communication between peers. Members of the
channel share a distributed ledger to store confidential transactions.
Smart contracts are deployed on channels and can be executed by
its peers to interact with the ledger. In our example, the service con-
sumer shares a separate ledger with each provider. Each participant
deploys a graphical user interface and an API via a docker-compose
file in its environment. Communication with the participants of the
network is only done via smart contracts.

• Smart Contract.
For the implementation of the smart contracts we decided
to use JavaScript, as Hyperledger Fabric officially supports
an SDK for Node.js. If a consumer would consume multiple
services from a provider, one smart contract is sufficient as
it can handle multiple services of the same type by linking
the measurements to a single instance via a unique service
key. In Listing 1 an excerpt of a smart contract is shown
for retrieving measurements. The credentials are stored in
the ledger and will be used for querying the Amazon EC2
Oracle.

Listing 1: Retrieve data from oracle based on service key
async updateService(ctx, serviceKey, startTime, endTime) {

const serviceAsBytes = await ctx.stub.getState(serviceKey);
if (!serviceAsBytes || serviceAsBytes.length === 0) {

throw new Error(`${serviceKey} does not exist`);
}
let service = JSON.parse(serviceAsBytes.toString());
...
// query the oracle
service.data = await this.getMetricsDataEC2(

service.accessKeyId,
service.secretAccessKey,
service.region,
service.dimensionName,
service.dimensionValue,
startTime,



A Penalty-Aware Cloud Monitoring System based on Blockchains iiWAS ’20, November 30-December 2, 2020, Chiang Mai, Thailand

Figure 2: Scenario of the cloud monitoring system

Figure 3: Technical architecture of the cloud monitoring system

endTime
);
// calculate availability
if (service.cpuUtilization >= 0) {

service.timesAvailable += 1;
console.log(""Connection good"");

} else {
service.timesNotAvailable += 1;
console.log(""No connection"");

}
...

// give credit if availability is to low
if (currentAvailability < service.promisedAvailability) {

service.credit += PENALTY_AMOUNT;
}
await ctx.stub.putState(

service.name,
Buffer.from(JSON.stringify(service)));

• Monitoring Service Integration.
The smart contracts require access to the monitoring ser-
vices. In blockchain-environments, accessing such external
services is technically challenging: TheNode.js SDK provided
by Amazon is used to retrieve metrics of the service form



iiWAS ’20, November 30-December 2, 2020, Chiang Mai, Thailand Dienbauer et al.

their monitoring tool Cloudwatch. When a service is regis-
tered to our monitoring system, an unique service key with
all the necessary information to retrieve metrics from Cloud-
watch, is stored within the ledger. This enables retrieving
information from Cloudwatch and storing the information
into the ledger running purely inside a smart contract by
just passing the service key for identification.
An update function is used to retrieve the information about
the service metrics of the latest time interval. At the regis-
tration of a service, in our system, the availability promised
by the service provider is passed as a parameter and stored
together with the credentials and information of the service
in the ledger. As the update function queries the informa-
tion about the service from Cloudwatch we see from the
response if a service is available or not. Within the smart
contract we mark this requested interval as either available
or unavailable and compare it to the total run-time of the
service. If a service’s downtime exceeds the promised avail-
ability of a service provider, the customer will receive a
certain amount of credit for this service. This credit can then
be used as an offset during settlement. As smart contracts
are not self-executable programs, the update function needs
to be requested from outside of the network. To prevent a
user from requesting the service’s status for the same time
interval twice, the smart contracts check at each request of
the update function if the time of the last state in the ledger
will not overlap with the times in the request.
The same logic is used for the implementation of the smart
contract for Azure VM services.

• Core Environment.
To provide users of the system a convenient way to register
services and explore their current and past state together
with actual availability and possible credits, we created a
graphical user interface with React. We developed a REST
API which uses the SDK to interact with the blockchain
network and provides endpoints that can be requested by
the React application. This API has another advantage as it
can be used by a cron job, to automatically query the latest
states of a registered service.

A reference to the complete script to reproduce the created setup
can be found on GitHub10.The most important contents of the script
are as follows:

(1) Generate x.509 certificates,
(2) Configuration of the channels,
(3) Creation of the peer nodes,
(4) Joining the peers to the channels, and
(5) Instantiating the smart contracts in the channels
The current implementation of the monitoring service is capable

of retrieving information about two service types of two different
service providers. To proof the feasibility of integrating service
level agreement we started with the implementation of the promised
availability that is passed to the system on the registration process.
Though, as this logic is deployed via smart contracts the system
can be extended in a modular manner to support additional service
10https://github.com/dieni/blockchain-based-cloud-monitoring

types as well as a variety of service metrics that are provided by the
oracles. All this information can then be used to define SLAs via
the monitoring system. If an SLA agreement is violated, the current
approach will trigger a penalty by increasing the credit of variables
within the ledger that is shared between the service provider and
the consumer. To change the value of this variable a predefined
logic within the smart contract is used that considers all the past
states of service as well as the promised availability passed on the
registration of the service in the system. As smart contracts are not
self-executable programs, the process of retrieving new states of a
service needs to be started by the user. Currently, this is done via
a button in the user interface but can be automated using a cron
job. For this purpose, we created a RESt API as it was necessary to
implement the JavaScript SDK to interact with the smart contracts.
The first attempt of using the SDK within the React application led
to importing errors as the JavaScript standard used by React (ES6)
did not match with the standard used by the SDK (ES5). In listing 2
shows the endpoint of the API that is used by the frontend, or a cron
job, to query the smart contract to retrieve new states of service.
The user interface is deployed locally without any direct connection
to the internet. All the information that is shown is retrieved from
the blockchain network by using smart contracts. In Figure 4 a
form can be seen to register new services to the system. As in our
scenario, Univie has used services from Amazon and Microsoft, and
can choose between two registration forms. This form contains
information for authentication to the oracles as well as information
about the SLA. If the entered information is correct, the credentials
will be stored in a smart contract. Underneath the form, a list of all
registered services of a provider can be seen. When clicking on the
services, the details page of the service 5 opens: Here a user can
see information about the retrieved measurements of the service.
By clicking on the button, new measurements can be retrieved. If
the service is more often unreachable than promised, the customer
will receive a credit.

Listing 2: API that implements the application SDK for in-
teracting with the smart meters

app.put('/aws/services/:serviceKey', async (req, res) => {
console.log(req.body)
let serviceKey = JSON.parse(req.params.serviceKey)

const gateway = new Gateway()

try {
console.log('CONNECT TO NETWORK')
await gateway.connect(connectionProfile, connectionOptions)
const network = await gateway.getNetwork('channel−aws')
const contract = network.getContract('ec2contract')

const endTime = new Date()
const startTime = new Date(endTime.getTime() − 30 ∗ 60000)

await contract.submitTransaction(
'updateService',



A Penalty-Aware Cloud Monitoring System based on Blockchains iiWAS ’20, November 30-December 2, 2020, Chiang Mai, Thailand

serviceKey,
startTime.toISOString(),
endTime.toISOString()

)

console.log('SERVICE UPDATED')
} finally {
// Disconnect from the gateway
console.log('Disconnect from Fabric gateway.')
gateway.disconnect()

}
})

5 DISCUSSION AND FUTUREWORK
This paper is part of a research project aiming on using blockchain
technology for monitoring services of different service providers.
Thereby, we aim on a decentralized architecture to enable penalty
payments if service level agreements are violated. This concept was
realized with the presented implementation, where for each service
type a smart contract was deployed in a self hosted Hyplerledger
Fabric network and shared between service provider and consumer
via private channels. However, the design of the implemented ap-
proach would work for any other provider as long as an API is
existing that returns the required service performance metrics.

• Hyperledger Fabric Network.
The network was created using the CLI tools provided by
Hyperledger and deployed locally running the components
within docker containers. Hyperledger provides via docker
hub the containers for all necessary components to run a net-
work. Though, the configuration of the network can be quite
difficult as documentation about different settings and oper-
ations is quite rare. A recommended approach for a future
project is to use Blockchain as a service. Service providers
like Amazon AWS, Microsoft Azure, or IBM provide man-
aged Blockchains to set up a network within a short amount
of time.

• Smart Contracts.
With";"""date"",""2020-10-16T11:35:51Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""A Penalty-Aware Cloud Monitoring System based on Blockchains""
""xmp:CreatorTool"",""LaTeX with acmart 2020/04/30 v1.71 Typesetting articles for the Association for Computing Machinery and hyperref 2020-05-15 v7.00e Hypertext links for LaTeX""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""-  Information systems  ->  Information systems applications.-  Computer systems organization  ->  Architectures.""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with acmart 2020/04/30 v1.71 Typesetting articles for the Association for Computing Machinery and hyperref 2020-05-15 v7.00e Hypertext links for LaTeX""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""A Penalty-Aware Cloud Monitoring System based on Blockchains""
""modified"",""2020-10-16T11:35:51Z""
""cp:subject"",""-  Information systems  ->  Information systems applications.-  Computer systems organization  ->  Architectures.""
""pdf:docinfo:subject"",""-  Information systems  ->  Information systems applications.-  Computer systems organization  ->  Architectures.""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""Christian Dienbauer, Benedikt Pittl, Werner Mach, and Erich Schikuta""
""PTEX.Fullbanner"",""This is MiKTeX-pdfTeX 2.9.7439 (1.40.21)""
""meta:author"",""Christian Dienbauer, Benedikt Pittl, Werner Mach, and Erich Schikuta""
""trapped"",""False""
""meta:creation-date"",""2020-10-16T11:35:51Z""
""created"",""2020-10-16T11:35:51Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-10-16T11:35:51Z""
""resourceName"",""p154-dienbauer.pdf""
""Author"",""Christian Dienbauer, Benedikt Pittl, Werner Mach, and Erich Schikuta""
""producer"",""MiKTeX pdfTeX-1.40.21""
""pdf:docinfo:producer"",""MiKTeX pdfTeX-1.40.21""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""2"",""0"",""0"",""0"",""0"",""0""
""Keywords"",""Cloud Monitoring, Smart Contracts, Cloud Computing""
""access_permission:modify_annotations"",""true""
""dc:creator"",""Christian Dienbauer, Benedikt Pittl, Werner Mach, and Erich Schikuta""
""dcterms:created"",""2020-10-16T11:35:51Z""
""Last-Modified"",""2020-10-16T11:35:51Z""
""dcterms:modified"",""2020-10-16T11:35:51Z""
""title"",""A Penalty-Aware Cloud Monitoring System based on Blockchains""
""Last-Save-Date"",""2020-10-16T11:35:51Z""
""pdf:docinfo:keywords"",""Cloud Monitoring, Smart Contracts, Cloud Computing""
""pdf:docinfo:modified"",""2020-10-16T11:35:51Z""
""meta:save-date"",""2020-10-16T11:35:51Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is MiKTeX-pdfTeX 2.9.7439 (1.40.21)""
""Content-Length"",""846118""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Christian Dienbauer, Benedikt Pittl, Werner Mach, and Erich Schikuta""
""dc:language"",""en""
""dc:subject"",""Cloud Monitoring, Smart Contracts, Cloud Computing""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""9""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""4591"",""6117"",""5647"",""3892"",""812"",""5040"",""4779"",""301"",""7937""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""Cloud Monitoring, Smart Contracts, Cloud Computing""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-10-16T11:35:51Z""
";https://scholar.google.ch/scholar?start=890&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098892-400;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Právní aspekty kryptom?n;J Hospodka ;2020 dspace.cuni.cz;;"… úprav?.16 Skute?nost, že v základu fungování ale stojí technologie blockchain, a? již ta bitcoinová,

nebo jiná, je spole?ná všem altcoin?m … Singapur: Master The Crypto [cit … Dostupné z:

https://masterthecrypto.com/differences-between-cryptocurrency-coins- and-tokens …";Autres articles;Version HTML;[PDF] cuni.cz;https://dspace.cuni.cz/bitstream/handle/20.500.11956/121179/120366810.pdf?sequence=1;"
UNIVERZITA KARLOVA  
PrĂĄvnickĂĄ fakulta 

 

 

 
Jakub Hospodka 

 

 

Právní aspekty kryptoměn 
 

DiplomovĂĄ prĂĄce 

 

 

 

 

 
VedoucĂ­ diplomovĂŠ prĂĄce: JUDr. Petr KotĂĄb, Ph.D. 

Katedra: Katedra finančního práva a finanční vědy 

Datum vypracování práce (uzavření rukopisu): 30. 06. 2020 
 
 
 
 



 

 

 

 

 
 
 
 
 
 
 
 
 
Prohlašuji, že jsem předkládanou diplomovou práci vypracoval samostatně, že všechny 

použité zdroje byly řádně uvedeny a že práce nebyla využita k získání jiného nebo stejného titulu. 
 
Dále prohlašuji, že vlastní text této práce včetně poznámek pod čarou má 154.135 znaků 

včetně mezer.  
 
 
       
 
       Jakub Hospodka 
 
 
 
V Praze dne 30.06.2020 

  



 

 

 

 

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Poděkování 
 
Tímto bych rád poděkoval panu JUDr. Petru Kotábovi, Ph.D., za veškerou pomoc, kterou 

mi poskytl při vypracování této práce. Zároveň bych chtěl poděkovat své manželce a rodině za 
veškerou podporu, kterou mi poskytli během doby studia.  



 

 

 

 

1 Obsah 
Úvod .................................................................................................................................... 6 

1 Historie .......................................................................................................................... 8 

1.1 Cyberbucks a společnost DigiCash ....................................................................... 8 

1.2 E-gold .................................................................................................................... 9 

1.3 Bitcoin ................................................................................................................. 10 

2 Pojem kryptoměna ...................................................................................................... 12 

2.1 Kategorizace kryptoměny .................................................................................... 14 

2.1.1 Prostředek směny ............................................................................................ 15 

2.1.2 Uchovatel hodnoty .......................................................................................... 16 

2.1.3 Zúčtovací jednotka ......................................................................................... 16 

2.2 Virtuální měna/digitální měna ............................................................................. 17 

2.3 Členění virtuálních měn ....................................................................................... 21 

2.4 Kryptografie ......................................................................................................... 23 

2.5 Virtuální měny v Českém právu .......................................................................... 24 

2.5.1 Kryptoměny jako cenný papír ........................................................................ 24 

2.5.2 Kryptoměny z pohledu boje proti legalizaci výnosů z trestné činnosti .......... 27 

2.5.3 Postoj ČNB ..................................................................................................... 29 

3 Blockchain a DLT ....................................................................................................... 32 

3.1 Technologie distribuovaného účetního deníku – DLT ........................................ 32 

3.2 Druhy DLT .......................................................................................................... 34 

3.2.1 Veřejné systémy DLT ..................................................................................... 34 

3.2.2 SoukromĂŠ systĂŠmy DLT ................................................................................. 34 

3.3 Blockchain ........................................................................................................... 35 

3.3.1 Těžba .............................................................................................................. 35 

3.3.2 Těžba v poolu ................................................................................................. 36 

3.4 Smart Contracts ................................................................................................... 36 



 

 

 

 

3.4.1 Pohled českého práva ..................................................................................... 39 

4 Kryptoměny a daň z příjmů fyzických osob ............................................................... 42 

4.1 Příjmy ze samostatné činnosti / ostatní příjmy .................................................... 44 

4.2 Osvobozené příjmy .............................................................................................. 46 

4.3 Základ daně .......................................................................................................... 47 

4.4 Sazba daně ........................................................................................................... 49 

4.5 ShrnutĂ­ a Ăşvahy de lege ferenda .......................................................................... 50 

5 Daň z příjmů právnických osob .................................................................................. 51 

5.1 Kryptoměny a účetnictví ..................................................................................... 51 

5.1.1 Alternativní řešení .......................................................................................... 54 

6 Daň z přidané hodnoty ................................................................................................ 57 

6.1 Předmět daně ....................................................................................................... 57 

6.2 Dodání zboží, poskytnutí služby za kryptoměnu ................................................. 59 

6.2.1 Ručení ............................................................................................................. 60 

6.3 Směna kryptoměny za tradiční měnu .................................................................. 60 

6.4 Těžba kryptoměny ............................................................................................... 63 

6.4.1 Individuální těžba ........................................................................................... 63 

6.4.2 Těžba v poolu ................................................................................................. 64 

7 Závěr ........................................................................................................................... 66 

Seznam pouŞitých zkratek ................................................................................................. 70 

Seznam pouŞitých zdrojů .................................................................................................. 72 

 

  



 

 

 

 

Úvod 

V posledních letech bylo možné na světové scéně zaznamenat obrovský nárust popularity 

kryptoměn. Tento nárůst byl doprovázen i obecným nadšením, kdy veřejnost získala dojem, že její 

koupí se stává součástí něčeho nadnárodního a státní mocí neregulovatelného. Důkazem toho, jak 

málo o podstatě kryptoměn, a tudíž i související problematice, ale veřejnost věděla, může být 

například i statistika společnosti Google za rok 2018. Ta ukazuje, co bylo ve Spojených státech 

amerických a Spojeném království v roce 2018 nejvyhledávanějším spojením uvozeným „What 

is“ – a to sice: „What is Bitcoin?“.1 Pod pojem kryptoměna můžeme dnes zařadit již stovky až 

tisíce projektů, které se snaží získat popularitu mezi veřejností. Pro účely této práce byla nicméně 

vybrána pouze primárně jedna z nich, a to konkrétně kryptoměna bitcoin, která dosáhla ke dni 6. 

3. 2019 tržní kapitalizace ve výši 68 miliard dolarů.2 Proti druhé nejznámější kryptoměně Etherum 

je to necelý pětinásobek, což bitcoinu dává poměrně výrazný náskok, a tudíž i význam oproti 

ostatním kryptoměnám.3 

V souvislosti s tímto obrovským nárustem na popularitě nicméně ruku v ruce vzniká 

problém nejasné právní regulace tohoto odvětví. Motivace k regulaci může mít svůj původ 

v mnoha oblastech, jako je například ochrana spotřebitele proti klamavým praktikám obchodníků, 

boj proti legalizaci výnosů z trestné činnosti a praní špinavých peněz, jakožto i financování 

terorismu. Vedle toho mají nicméně operace s kryptoměnou dopad například do daňových 

povinnostĂ­ jejich vlastnĂ­kĹŻ a obchodnĂ­kĹŻ s nimi. Vzhledem k tomu, Ĺže prĂĄvnĂ­ch oblastĂ­, ve kterĂŠ 

je existenci kryptoměn nutno rozebrat, je poměrně široká řada a neexistuje v tuto chvíli komplexní 

literatura, je cílem této práce poskytnout právní rozbor jednotlivých oblastí, kde s nimi lze přijít 

do kontaktu. Jako dílčí cíle si poté tato práce klade (i) definovat a kategorizovat termín kryptoměna 

z právního pohledu, (ii) popsat technologii blockchain a právně posoudit závaznost tzv. smart 

kontraktů, a (iii) analyzovat právní úpravu v oblasti zdanění kryptoměn z pohledu daně z příjmů 

fyzických osob, pråvnických osob a DPH.  

První kapitolu tvoří historický základ dnešních kryptoměn, který má za cíl vytvořit 

referenční období a přiblížit skutečnost, že kryptoměny se ve světě v určité formě objevují již 

poměrně delší dobu. Druhá kapitola si klade za cíl vypořádat se právním ukotvením pojmů 

 
1 MICKY NEWS. ""What is Bitcoin” tops google search list for 2018. Micky [online]. [cit. 2019-04-08]. Dostupné z: 

https://micky.com.au/what-is-bitcoin-tops-google-search-list-for-2018/. 
2 CoinMarketCap [online]. [cit. 2019-04-08]. DostupnĂŠ z: https://coinmarketcap.com. 
3 TamtĂŠĹž. 



 

 

 

 

kryptoměna, virtuální měna a digitální měna, které často bývají označovány za synonyma. Ke 

správné analýze jednotlivých pojmů je využíváno především dokumentů mezinárodních 

finančních institucí. Dále je věnován prostor i kategorizaci virtuálních měn a odlišujícím prvkům 

kryptoměn. V neposlední řadě je poté součástí i podkapitola, která se zabývá postavením 

kryptoměn v českém právním řádu, jak z pohledu soukromého práva, kdy je zkoumána právní 

povaha kryptoměny, tak z pohledu veřejného práva optikou boje proti praní špinavých peněz 

a legalizace výnosů z trestné činnosti. V neposlední řadě pak tato část obsahuje i podkapitolu 

věnující se pohledu regulačního úřadu, kterým je Česká národní banka. Třetí kapitola je věnována 

popisu technologie blockchain, její kategorizaci a nastínění jejích základních vlastností. Cílem této 

kapitoly je pak především analýza právního aspektu blockchainu, respektive závaznosti tzv. smart 

kontraktů, které lze pomocí technologie blockchain uzavírat. Čtvrtá, pátá a šestá kapitola obsahují 

rozbor právní úpravy vztahující se k dani z příjmů fyzických osob, právnických osob a DPH. 

Cílem těchto kapitol je poskytnout odpovědi na otázku správného postupu pro daňový subjekt, 

který provádí operace s kryptoměnami nebo jejich těžbu, a rozebrat některé související problémy. 



8 

 

1 Historie 

Současné kryptoměny jako bitcoin, etherum, ripple a další nejsou prvními kryptoměnami 

takového typu. Historie zná spoustu případů malých „start-upových“ projektů, které se snažily 

vytvořit svojí tehdejší verzi virtuálních měn či kryptoměn. Většina z nich skončila buď u soudu, 

nebo rychlým krachem. Existuje ale pár případů, které se dokázaly alespoň na nějakou dobu dostat 

na světlo širšího světa a vzbudit poměrně velký zájem veřejnosti nebo investorů. Některé z nich 

pak pravděpodobně položily i výrazné stavební kameny, na kterých dnešní kryptoměny stojí.  

1.1 Cyberbucks a společnost DigiCash 

První historicky významnou kryptoměnou byla kryptoměna cyberbucks od společnosti 

DigiCash. V čele společnosti stál na počátku průkopník virtuálních měn David Chaum. Ten se již 

během svých let na Californské univerzitě věnoval anonymitě platebních transakcí prováděných 

prostřednictvím internetu. Především ho znepokojoval přístup finančních institucí k údajům 

o jednotlivých transakcích a dalším osobním údajům o uživatelích těchto platebních metod.4 Proto 

v roce 1989 založil společnosti DigiCash, která si kladla za cíl zajistit anonymitu právě na poli 

těchto běžných plateb. Základem měny bylo využívání veřejného a soukromého klíče, který 

využívají i dnešní kryptoměny. Veřejný klíč každého uživatele je veřejně dostupný a odesílatel 

zašifruje transakci pomocí veřejného klíče příjemce. Ten následně využije svůj soukromý klíč 

k tomu, aby transakci dešifroval. Tím, že by v ideálním případě měl soukromý klíč mít k dispozici 

pouze oprávněný příjemce transakce, je zajištěna její bezpečnost a anonymita, neboť nikdo jiný 

zprávu dešifrovat nedokáže. Dalším využitím klíčů pak může být například podpis odesílatele, 

který zprávu ještě zašifruje pomocí svého soukromého klíče a příjemce jí následně dešifruje 

pomocí veřejného klíče odesílatele, čímž je zajištěna i autenticita zprávy.5 

DigiCash ve své snaze uplatnit svůj systém eCash na běžné transakce nicméně nebyl příliš 

úspěšný. Důvodem bylo především to, že společnost byla závislá na bankovních domech  

a obchodnících, kteří museli umožnit svým zákazníkům platby a převody skrze systém eCash. Jen 

díky tomu by mohli běžní občané provádět platby obchodníkům za zboží a služby a systém reálně 

využívat. Takto prorazit se ale společnosti nepodařilo. Někteří autoři tvrdí, že důvodem byla 

 
4 CHAUM, David. DigiCash. Chaum [online]. [cit. 2019-04-07]. DostupnĂŠ z: https://www.chaum.com/ecash/. 
5 Public-key cryptography. Wikipedia, the free encyclopedia [online]. San Francisco: Wikimedia Foundation, Inc., 

2001 [cit. 2019-04-07]. DostupnĂŠ z: https://en.wikipedia.org/wiki/Public-key_cryptography. 



 

9 

 

 

Chaumova přehnaná snaha o co největší anonymitu.6  Důkazem toho může být i to, že odmítl 

integraci systému společnosti DigiCash do operačních systémů Windows 95, za což mu Bill Gates 

byl údajně ochoten nabídnout až sto milionů dolarů, právě z důvodu nedostatečné anonymity 

uživatelů.7 Choum nicméně situaci označil za začarovaný kruh, ve kterém instituce neměly důvod 

systém adoptovat, když jej využívalo pouze malé procento obyvatelstva, a lidé naopak neměli 

moŞnost systÊm vyuŞít, protoŞe jej podporovalo pouze pår bankovních domů.8 Celå situace vedla 

až k vnitřním rozporům ve společnosti DigiCash, kdy se zaměstnanci postavili proti vedení. Sám 

Chaum proto společnost v roce 1997 opustil a dva roky poté DigiCash vyhlásil bankrot. Nicméně 

stojí za zmínku, že systém během doby existence přijaly, nebo alespoň pracovaly na jeho 

implementaci, banky jako Deutsche Bank, Norske Bank a Bank Austria. 9 

1.2 E-gold  

Výrazněji se do historie zapsala i kryptoměna e-Gold, kterou v roce 1996 vytvořila 

společnost Gold & Silver Reserve Inc. Princip této „měny“ spočíval v tom, že společnost 

nakoupila určité množství zlata, které uložila do bezpečnostních schránek a úschoven, a následně 

na toto zlato emitovala „měnu“ e-gold. Celá tato emise tak byla kryta zlatem, v čemž spočíval  

i obchodní model společnosti, která prezentovala e-gold jako bezpečnou, zlatem jištěnou měnu.10 

V tomto ohledu je nutno podotknout, že sám zakladatel společnosti Doug Jackson považoval 

vytvoření měny, která by byla kryta zlatem, jako nutný předpoklad pro záchranu světové 

ekonomiky. Jeho vizí bylo vytvoření nadnárodní směnné jednotky, která by cirkulovala bez 

možnosti provádění státních zásahů a jejím přesným poměrem ke zlatu by byla i relativně 

zafixována její hodnota.11 e-Gold poměrně rychle nabral na vysoké popularitě, v roce 2000 ho 

využívalo až milion lidí a v roce 2008 dokonce až pět milionů lidí. V praxi byl přijímán  

 
6 STROUKAL, Dominik a Jan SKALICKÝ. Bitcoin. Praha: Ludwig von Mises Institut CZ&SK, 2015. ISBN 978-

80-87733-26-4. s.26. 
7 CHAUM, David. DigiCash. Chaum [online]. [cit. 2019-04-07]. DostupnĂŠ z: https://www.chaum.com/ecash/ 
8 FRANKENFIELD, Jake. DigiCash. Investopedia [online]. Dotdash publishing, 2018 [cit. 2019-04-07]. DostupnĂŠ 

z: https://www.investopedia.com/terms/d/digicash.asp. 
9 CHAUM, David. DigiCash. Chaum [online]. [cit. 2019-04-07]. DostupnĂŠ z: https://www.chaum.com/ecash/ 
10 ZACHARY. DigiCash and e-gold, the Cryptocurrencies That Failed Before Bitcoin Was Born. Bitcoinnews.com 

[online]. 2018 [cit. 2019-04-07]. DostupnĂŠ z: https://bitcoinnews.com/digicash-and-e-gold-the-

cryptocurrencies-that-failed-before-bitcoin-was-born/. 
11 ZETTER, Kim. Bullion and Bandits: The Improbable Rise and Fall of E-Gold. Wired.com [online]. Boone [cit. 

2020-05-19]. DostupnĂŠ z: https://www.wired.com/2009/06/e-gold/. 



 

10 

 

 

u obchodníků, vznikaly směnárny, které umožňovaly jeho směnu na další zahraniční měny, 

a v roce 2006 služba společnosti Gold & Silver Reserve Inc. zprostředkovala obchodní transakce 

v hodnotě dvou miliard dolarů a disponovala rezervou o velikosti necelých čtyř tun zlata. Takovýto 

nárůst na jedné straně přitahoval úroky hackerských skupin, kterým se skutečně podařilo část 

uživatelů okrást o nakoupené E-Goldy, především ale přitáhl pozornost amerických regulátorů. 

Jejich pozornost si E-Gold získal již v roce 2003, kdy americké bezpečností složky začaly 

monitorovat zneuŞívåní amerických platebních karet skupinou z východní Evropy. Ta vyuŞívala 

E-Gold k anonymnímu přesunu nelegálně získaných prostředků, jelikož platforma zajišťovala 

plnou anonymitu. Po útoku na budovy světového obchodního centra v New Yorku v roce 2001 

a přijetím Patriot Act došlo ke zpřísnění boje proti praní špinavých peněz, a postupný zánik 

platformy tak byl již pouze otázkou času.12  

Jak lze na dvou předchozích případech vidět, tak hlavním úskalím, na které kryptoměny 

narážely, byly buď firemní struktura zakladatelské společnosti, a tudíž i centralizovaný systém, 

nebo přílišný dohled regulátora a problematika boje proti praní špinavých peněz. Možná i z toho 

důvodu se k současně nejpopulárnější kryptoměně bitcoin její autor nikdy veřejně nepřihlásil 

a celá spočívá na decentralizované síti. Oprávněná obava ze zneužívání k praní špinavých peněz 

z důvodu anonymity nicméně zůstává přítomná i u ní.   

1.3 Bitcoin 

Kryptoměna bitcoin spatřila světlo světa v roce 2009 skrze práci vývojáře jménem Satoshi 

Nakamoto. Ten ve své „bílé knize“ (z anglického „white paper“) vysvětluje důvod vzniku měny 

jako snahu vytvořit mechanismus, který by byl, místo na důvěře ve finanční instituce, postaven na 

důvěře v kryptografické vlastnosti měny. Ve finančních systémech, provozovaných institucemi, 

vidí zbytečné náklady a nadbytek shromažďovaných informací, které musí být získány, aby 

instituce mohla poskytnout uživatelům dostatečnou jistotu bezpečí a autentičnosti transakcí.13  

Z počátku byla popularita bitcoinu poměrně nevýznamná, nicméně zejména v posledních 

letech bylo možné zaznamenat její raketový nárůst a následně opět poměrně strmý pokles. Tento 

postupnĂ˝ proces ilustruje graf 1. Vzhledem k tomu, Ĺže na vrcholu dosahovala cena za jeden bitcoin 

 
12 E-Gold. Wikipedia, the free encyclopedia [online]. San Francisco: Wikimedia Foundation, Inc., 2001 [cit. 2019-

04-07]. DostupnĂŠ z: https://en.wikipedia.org/wiki/E-gold. 
13 NAKAMATO, Satoshi. Bitcoin: A Peer-to-Peer Electronic Cash System [online]. 2008 [cit. 2020-05-23]. 

DostupnĂŠ z: https://bitcoin.org/bitcoin.pdf. 



 

11 

 

 

necelých 20 tisíc dolarů, není velkým překvapením, že právě bitcoin je středem pozornosti 

regulátorů a i veřejnosti.  

Graf 1 Prodejní cena bitcoinu v letech 2014–2019 (V USD) 

 

Zdroj: vlastnĂ­ zpracovĂĄnĂ­ dle dat z bitcoinity.org14 

  

 
14 Bitcoinity.org/markets. Bitcoinity.org [online]. [cit. 2019-05-28]. DostupnĂŠ z: https://bitcoinity.org/markets. 

0

5000

10000

15000

20000

25000

16.11.2014 16.11.2015 16.11.2016 16.11.2017 16.11.2018

coinbase



 

12 

 

 

2 Pojem kryptoměna 

V publikacích se často můžeme setkat s vícero označeními pro pojem kryptoměna. Jedním 

z nich, vyuŞívaným zejmÊna v odborných textech, kterÊ nepovaŞují za vhodnÊ vyuŞívat termín 

měna, je často termín krypto-aktiva. To, že se nejedná o synonyma, nýbrž spíše o nadřazené, 

respektive podřazené pojmy, dobře ilustruje taxonomie vydaná Evropským orgánem pro 

bankovnictví (dále jen „EBA“), který krypto-aktiva rozdělil následovně (tabulka 1).  

Tabulka 1 Rozdělení krypto-aktiv 

Platební/směnitelné/měnové 

tokeny 

Investiční tokeny Užitkové tokeny 

• často označované jako 

virtuální měny nebo 

kryptoměny; 

• vlastníkovi neposkytují 

prĂĄva, ale majĂ­ slouĹžit jako 

prostředek směny. (Tedy 

k nåkupu a prodeji zboŞí a 

služeb) nebo jako investiční 

nĂĄstroj pro uchovĂĄnĂ­ 

hodnoty; 

• např. bitcoin; 

• typicky přinášejí 

vlastníkovi práva – 

např. ve formě 

nĂĄroku na 

dividendu. 

Nejčastěji je 

moĹžnĂŠ se s nimi 

setkat skrze tzv. 

ICOs, kdy 

společnosti emitují 

krypto-aktiva proti 

zåkonnými 

prostředkům, aby 

získali počáteční 

kapitĂĄl; 

• např. bankera;  

• umožňují přístup 

k určité službě 

nebo produktu, ale 

nejsou přijímaný 

jako platebnĂ­ 

prostředek za jiné 

služby či zboží; 

• využívá se 

například 

v cloudových 

sluĹžbĂĄch; 

V některých případech ale může být konkrétní krypto-aktivum vlastnosti ze všech tří 

skupin. Takovým příkladem je dle EBA například Ether.  

Zdroj: VlastnĂ­ zpracovĂĄnĂ­ dle EBA 15 

 
15 EUROPEAN BANKING AUTHORITY. Report with advice for the European Commission [online]. Londýn: 

EBA, 2019 [cit. 2020-05-23]. DostupnĂŠ z: 

https://eba.europa.eu/documents/10180/2545547/EBA+Report+on+crypto+assets.pdf. s.7. 



 

13 

 

 

Důvodem uvedení tohoto dělení hned v úvodu práce je skutečnost, že tam, kde se 

v následujícím textu objevuje termín kryptoměna, rozumí se tím právě první kategorie, tedy tokeny 

určené jako prostředek směny.  

Alternativou k tomuto dělení je dělení kryptoměn mezi tokeny a tzv. altcoiny. Altcoinem 

rozumíme jakoukoliv kryptoměnu, která má za cíl fungovat jako platidlo, respektive prostředek 

směny. Výraz altcoin vychází ze slov „alternative to bitcoin“ a to převážně z toho důvodu, že velká 

část altcoinů stojí v základech na stejném open source protokolu jako bitcoin, případně jeho lehké 

úpravě.16 Skutečnost, že v základu fungování ale stojí technologie blockchain, ať již ta bitcoinová, 

nebo jiná, je společná všem altcoinům. Proces odštěpení, respektive úpravy základního kódu 

blockchainu se označuje termínem „forking“ neboli větvení. Pro účely větší přehlednosti tohoto 

dělení pak bude pod termínem altcoin chápana i kryptoměna bitcoin, který je v často považován 

za samostatnou kategorii, z dĹŻvodu jeho prvenstvĂ­.  

V užším smyslu lze výraz altcoin použít pro ty typy kryptoměn, jejichž technologie je od 

bitcoinu odvozena, či přímo pracuje na téže technologii. Příkladem takové kryptoměny jsou 

kryptoměny litecoin nebo peercoin.  V širším smyslu lze termínem altcoin označit i ty kryptoměny, 

které stojí na kompletně vlastní technologii blockchainu, respektive vlastních protokolech, jako je 

například kryptoměna ripple. Výraz altcoin proto lze považovat za synonymum 

platebním/směnitelným/ měnovým tokenům z tabulky výše, a tedy i kryptoměně ve smyslu, jakým 

jej chĂĄpe tato prĂĄce.  

Pojem token se v oblasti kryptoměn využívá k označení všech typů kryptoaktiv. Pro lepší 

orientaci bude ale v tomto textu využíván pouze pro zbylé dvě kategorie z dělení EBA, tedy 

k označení takových kryptoměn, jejichž cílem je poskytnutí buď investiční příležitosti do 

vznikající společnosti, nebo jako odměnu za využívání určité služby či způsob, jak danou službu 

využívat.17  Toto dělení zobrazuje tabulka 2. 

 
16 AZIZ. Coins, Tokens & Altcoins: What’s the Difference?. Master the Crypto [online]. Singapur: Master The 

Crypto [cit. 2019-04-27]. DostupnĂŠ z: https://masterthecrypto.com/differences-between-cryptocurrency-coins-

and-tokens/. 
17 TamtĂŠĹž. 



 

14 

 

 

Tabulka 2 Kategorizace pojmů krypto-aktiva, kryptoměna, altcoin, token 

Krypto-aktiva 

Platební/směnitelné/měnové tokeny – 

kryptoměny 
Investiční tokeny 

UĹžitkovĂŠ tokeny 
ZaloĹženĂŠ na 

BTC – altcoin 

v uŞťím smyslu 

NezaloĹženĂŠ na 

BTC – altcoin 

v ĹĄirĹĄĂ­m smyslu 

• namecoin 

• litecoin 

• peercoin 

• auroracoin 

• dogecoin 

• Ripple 

• Omni 

• NXT 

cryptocurrency 

 

 

• Medipedia point Rewards 

• Bankera 

 

Zdroj: VlastnĂ­ zpracovĂĄnĂ­ 

 

2.1 Kategorizace kryptoměny  

Definovat kryptoměnu není ten nejlehčí z úkolů. Většina významných světových institucí 

se přímé definici kryptoměny vysloveně vyhýbá a pouze kryptoměny kategorizuje v rámci pojmů 

digitální měna či virtuální měna. Následují text se z toho důvodu věnuje vysvětlení vztahů pojmy 

elektronické peníze, digitální měna, virtuální měna a kryptoměna.  

Předně je nutné upozornit na skutečnost, že i přesto, že se v následujícím textu poměrně 

často objevuje termín měna, nelze kryptoměny, resp. virtuální měny chápat v právním smyslu 

slova měna. Pojem měna je totiž v rámci právní teorie vymezen jakožto peněžní soustava, která je 

uznána státem, případně mezinárodními dohodami, a příslušnými zákonnými předpisy jsou 

stanoveny její konkrétní pravidla a náležitosti, jako je základní jednotka, dělení, emise, nástroje 

pro její ochranu apod.18 V tuto chvíli žádná kryptoměna není právním řádem upravena, co se jejích 

pravidel a vlastností týče, z toho důvodu ji nelze označit za měnu v právním slova smyslu. Je 

vhodné uvést, že jediný stát, který alespoň uvažoval o zavedení určité formy státní kryptoměny, 

 
18 BAKEŠ, Milan, Marie KARFÍKOVÁ, Petr KOTÁB a Hana MARKOVÁ. Finanční právo. 6., upr. vyd. V Praze: 

C.H. Beck, 2012. Beckovy právnické učebnice. ISBN 978-80-7400-440-7. s. 336.  



 

15 

 

 

bylo svého času Estonsko.19 Nicméně i to v posledních letech změnilo postoj, a naopak přistoupilo 

k jejich přísnější regulaci.20 

Vedle měny často bývají kryptoměny označovány za peníze, toto označení je přinejmenším 

problematické, neboť v teorii uznávané znaky peněz, jako je prostředek směny, uchovatel hodnoty 

a zúčtovací jednotka stále, dle mého názoru, nesplňují.  

2.1.1 Prostředek směny 

Holman definuje prostředek směny jako něco, co lidé chtějí kdykoliv přijmout, protože ví, 

že i ostatní lidé to chtějí kdykoliv přijmout.21  Historicky tuto funkci plnily drahé kovy, které 

především díky své dlouhodobé vzácnosti mohli dobře fungovat jako peníze, jelikož jejich 

hodnotu představoval podíl vzácného kovu v dané minci. Postupem času nicméně byli nahrazeny 

papírovými bankovkami, které již sami o sobě žádnou materiální hodnotu nepředstavují. Jejich 

hodnota je naopak odvozena od důvěry obyvatel v centrální banky, příslušné zákony a v to, že 

bankovky budou všeobecně přijímány neboli jak říká Holman: „Důvěra v tyto bankovky už není 

založena na zlatě. Je založena na důvěře v zákon a ve státní moc“.22 U kryptoměny jako je bitcoin 

je ovšem důvěra postavena pouze na důvěře v ostatní subjekty, technologii a jakákoliv důvěra 

v zákon a stát absentuje. Částečně ovšem bitcoin funkci prostředku směny naplňuje, neboť 

základna obchodníků, která jej přijímá jako platidlo se relativně rozšířila. Pro běžnou populaci  

a každodenní život zůstává nicméně stále víceméně nepoužitelný z důvodu nízké míry akceptace, 

jakožto i relativně vysokým poplatkům za jednu transakci. 23 Dalším důvodem pro nesplnění této 

podmínky je i absentující povinnost obchodníka jakoukoliv virtuální měnu přijímat, na rozdíl od 

zåkonných platidel. 

 
19 Estonsko zvažuje zavedení vlastní kryptoměny. Novinky.cz [online]. Praha: Seznam.cz, a.s., 2017 [cit. 2019-04-

07]. DostupnĂŠ z: https://www.novinky.cz/internet-a-pc/458955-estonsko-zvazuje-zavedeni-vlastni-

kryptomeny.html. 
20 TASSEV, Lubomir. Estonia to Tighten Rules for Licensed Crypto Companies. Bitcoin.com [online]. 2018 [cit. 

2019-04-07]. DostupnĂŠ z: https://news.bitcoin.com/estonia-to-tighten-rules-for-licensed-crypto-companies/. 
21 HOLMAN, Robert. Ekonomie. 4., aktualiz. vyd. Praha: C.H. Beck, 2005. Beckovy ekonomické učebnice. ISBN 

80-717-9891-6. s. 459. 
22 TamtĂŠĹž s. 461. 
23 Bitcoin Transaction Fees [online]. [cit. 2019-04-07]. DostupnĂŠ z: https://bitcoinfees.info. 



 

16 

 

 

2.1.2 Uchovatel hodnoty 

Častým využitím peněz je jejich ukládání pro budoucí spotřebu, tedy spotřebu odloženou, 

v takovém případě pak peníze plní funkci uchovatele hodnoty. Stejnou funkci plní i v případě 

platby u obchodníka, který vyměňuje zboží nebo služby za peněžní prostředky, které pak může 

držet a v budoucnu se stát kupujícím jiného zboží nebo služby. Rozhodně nelze tvrdit, že by 

jediným uchovatelem hodnoty v ekonomice byly právě peníze. Dalším příkladem mohou být 

například akcie, nemovitosti, Mankiw zmiňuje dokonce i hokejové kartičky.24 Nabízí se tedy 

samozřejmě i otázka, zdali tuto funkci nemohou plnit i kryptoměny.  V důsledku nízké regulace  

a vysoké volatility jeho hodnoty, způsobené zejména spekulačními obchody, je tato funkce  

u kryptoměn, respektive bitcoinu výrazně omezena, jelikož v tuto chvíli nelze s jistotou říct, zda 

hodnota kryptoměny bude uchována a umožní tedy v budoucnu spotřebu. Toto omezení lze 

demonstrovat na volatilitě ceny bitcoinu (Graf 2).  Graf zobrazuje mezi denní volatilitu prodejní 

ceny bitcoinu v procentech na burze Coinbase za obdobĂ­ 6. 5. 2019- 4. 11. 2019.  

Graf 2 Volatilita prodejní ceny bitcoinu na jednotlivých burzåch v % 

 

Zdroj: VlastnĂ­ zpracovĂĄnĂ­ dle dat z bitcoinity.org25 

2.1.3 Zúčtovací jednotka  

Tato funkce peněz slouží především k vyjadřování cen jednotlivého zboží a vytvoření 

vzåjemných vztahů mezi jednotlivými statky, coŞ umoŞňuje vznik cenovÊ hladiny. Mankiw tuto 

 
24 MANKIW, Gregory. ZĂĄsady ekonomie. Praha: Grada, 1999. ProfesionĂĄl. ISBN 80-716-9891-1. s. 572. 
25 Bitcoinity.org/markets. Bitcoinity.org [online]. [cit. 2019-05-28]. DostupnĂŠ z: https://bitcoinity.org/markets. 

0

10

20

30

40

50

60

70

80

06.05.2019 06.06.2019 06.07.2019 06.08.2019 06.09.2019 06.10.2019

coinbase



 

17 

 

 

funkci pojmenovává jako: „standard, který lidé používají k oznamování cen a zaznamenávání 

dluhů.“.26 Ani tato funkce není, dle mého názoru, u kryptoměn splněna. Zejména v důsledku 

zmíněné nízké míry uplatnění u jednotlivých obchodníků, a tedy i absence srovnání jednotlivých 

statků a služeb a zároveň i vysoké volatilitě. Byť je nutné zmínit, že bitcoin se často využívá 

k vyjádření cen jiných kryptoměn a v rámci tohoto segmentu pak určitým způsobem funkci 

zúčtovacĂ";"""date"",""2020-06-30T20:31:35Z""
""pdf:PDFVersion"",""1.5""
""xmp:CreatorTool"",""Acrobat PDFMaker 11 pro Word""
""pdf:docinfo:title"",""""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""pdfa:PDFVersion"",""A-1b""
""xmpMM:History:Action"",""converted""
""language"",""cs""
""dc:format"",""application/pdf; version=""""A-1b"""""",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""Acrobat PDFMaker 11 pro Word""
""access_permission:fill_in_form"",""true""
""xmpMM:History:When"",""2020-06-30T22:31:32Z""
""pdf:encrypted"",""false""
""dc:title"",""""
""xmp:CreateDate"",""2020-06-30T22:29:12Z""
""modified"",""2020-06-30T20:31:35Z""
""xmpMM:History:SoftwareAgent"",""Preflight""
""pdf:hasMarkedContent"",""true""
""xmpMM:History:InstanceID"",""uuid:a0ff8d4e-1130-42bd-84a5-d20e882ee354""
""xmp:ModifyDate"",""2020-06-30T22:31:35Z""
""pdf:docinfo:creator"",""User""
""meta:author"",""User""
""meta:creation-date"",""2020-06-30T20:29:12Z""
""created"",""2020-06-30T20:29:12Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-06-30T20:29:12Z""
""resourceName"",""120366810.pdf""
""pdfaid:part"",""1""
""Author"",""User""
""producer"",""Adobe PDF Library 11.0""
""pdf:docinfo:producer"",""Adobe PDF Library 11.0""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""access_permission:modify_annotations"",""true""
""dc:creator"",""User""
""dcterms:created"",""2020-06-30T20:29:12Z""
""Last-Modified"",""2020-06-30T20:31:35Z""
""dcterms:modified"",""2020-06-30T20:31:35Z""
""title"",""""
""xmpMM:DocumentID"",""uuid:864db731-26d3-4d99-a431-6a667e1ee7f3""
""Last-Save-Date"",""2020-06-30T20:31:35Z""
""pdf:docinfo:modified"",""2020-06-30T20:31:35Z""
""meta:save-date"",""2020-06-30T20:31:35Z""
""Content-Length"",""1131214""
""Content-Type"",""application/pdf""
""xmp:MetadataDate"",""2020-06-30T22:31:35Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""User""
""pdfaid:conformance"",""B""
""dc:language"",""CS""
""pdf:producer"",""Adobe PDF Library 11.0""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""82""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""266"",""359"",""288"",""3118"",""2514"",""2688"",""1312"",""2662"",""2829"",""2656"",""436"",""1611"",""2247"",""1719"",""2410"",""1743"",""2864"",""2849"",""2887"",""2583"",""1867"",""2135"",""2784"",""2491"",""2996"",""2933"",""2828"",""2907"",""2855"",""2526"",""534"",""2720"",""2152"",""2078"",""2377"",""2571"",""2690"",""2872"",""2799"",""2771"",""928"",""2555"",""3060"",""2540"",""2687"",""2585"",""2725"",""2902"",""2667"",""2733"",""2560"",""2614"",""2565"",""2206"",""2728"",""1767"",""2357"",""2523"",""2400"",""2796"",""2546"",""2422"",""1840"",""2756"",""2151"",""2722"",""2984"",""2901"",""1535"",""1295"",""1242"",""1897"",""2094"",""2126"",""2289"",""2057"",""2215"",""2132"",""1992"",""669"",""2209"",""2509""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-06-30T20:29:12Z""
";https://scholar.google.ch/scholar?start=940&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098769-117;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Traceable ring signatures with post-quantum security;H Feng, J Liu, Q Wu, YN Li ; Cryptographers' Track at the RSA Conference, 2020  Springer;;"… that some classical security proof techniques are not available in the quantum world [8]. The most

notable example is the random oracle model (ROM), in which hash functions are treated as truly

random functions and can only be evaluated through querying random oracles …";Cité 4 fois;;null;;;;https://scholar.google.ch/scholar?start=660&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098729-24;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Unchain or Block the Hype?: Decision Drivers, Success Factors, and Perspectives for Blockchain Adoption;C Pautasso, O Zimmermann, L Zhu, T Bocek… ; IEEE …, 2020  ieeexplore.ieee.org;;"… For example, contactless crypto payments should not require more than waving a near- field

communication credit card … Liming: The oracle introduces the state of external systems into the

closed blockchain execution en- vironment, while with the reverse- oracle, off …";Autres articles;;null;;;;https://scholar.google.ch/scholar?start=570&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098866-331;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;On instantiating the algebraic group model from falsifiable assumptions;T Agrikola, D Hofheinz, J Kastner ; … on the Theory and Applications of …, 2020  Springer;;"… D. Hofheinz—Supported by ERC Project PREP-CRYPTO 724307, and by DFG project GZ HO …

is a cryptographic primitive which can be used to replace random oracles in several … linear maps

or indistinguishability obfuscation to transport proofs from the random oracle model to …";Cité 5 fois;Les 4 versions;[PDF] ethz.ch;https://people.inf.ethz.ch/dhofheinz/pdf/conf/eurocrypt/AgrikolaHK20.pdf;"
On Instantiating the Algebraic Group Model from
Falsifiable Assumptions

Thomas Agrikola1,?, Dennis Hofheinz2,??, and Julia Kastner2,?

1 Karlsruhe Institute of Technology, Karlsruhe, Germany
2 ETH Zurich, Switzerland

Work done while all authors were at Karlsruhe Institute of Technology.

Abstract. We provide a standard-model implementation (of a relaxation) of the algebraic group model
(AGM, [Fuchsbauer, Kiltz, Loss, CRYPTO 2018]). Specifically, we show that every algorithm that uses
our group is algebraic, and hence “must know” a representation of its output group elements in terms
of its input group elements. Here, “must know” means that a suitable extractor can extract such a
representation efficiently. We stress that our implementation relies only on falsifiable assumptions in the
standard model, and in particular does not use any knowledge assumptions.
As a consequence, our group allows to transport a number of results obtained in the AGM into
the standard model, under falsifiable assumptions. For instance, we show that in our group, several
Diffie-Hellman-like assumptions (including computational Diffie-Hellman) are equivalent to the discrete
logarithm assumption. Furthermore, we show that our group allows to prove the Schnorr signature
scheme tightly secure in the random oracle model.
Our construction relies on indistinguishability obfuscation, and hence should not be considered as a
practical group itself. However, our results show that the AGM is a realistic computational model (since
it can be instantiated in the standard model), and that results obtained in the AGM are also possible
with standard-model groups.

Keywords: indistinguishability obfuscation, algebraic group model, Schnorr signatures

Table of Contents
1 Introduction 2

1.1 Technical overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2 Related work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2 Preliminaries 6
2.1 Subset membership problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2 Dual-mode NIWI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3 Probabilistic indistinguishability obfuscation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.4 Re-randomizable and fully homomorphic encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

3 Statistically correct input expanding pIO 9
3.1 Puncturable PRFs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.2 Construction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

4 How to simulate extraction – Algebraic Wrappers 14
4.1 Group schemes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.2 An algebraic wrapper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.3 Construction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

5 How to use Algebraic Wrappers – Implementing proofs from the AGM 24
5.1 Diffie-Hellman Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
5.2 Schnorr Signatures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
5.3 Signed ElGamal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

? Supported by ERC Project PREP-CRYPTO 724307.
?? Supported by ERC Project PREP-CRYPTO 724307, and by DFG project GZ HO 4534/4-2.



1 Introduction

The generic group model. In order to analyze the plausibility and relative strength of computational
assumptions in cyclic groups, Shoup [Sho97] and Maurer [Mau05] have proposed the generic group model
(GGM). In the GGM, any adversary can only interact with the modeled group through an oracle. In particular,
all computations in that group must be explicitly expressed in terms of the group operation. To prevent
an adversary from locally performing computations, that adversary gets to see only truly random strings
(in [Sho97]) or independent handles (in [Mau05]) as representations of group elements.3

The discrete logarithm and even many Diffie-Hellman-style problems are hard generically (i.e., when
restricting group operations in the above way) [Sho97; MW98]. Hence, the only way to break such a generically
hard assumption in a concrete group is to use the underlying group representation in a nontrivial way. In that
sense, the GGM can be very useful as a sanity check for the validity of a given assumption, or even the security
of a given cryptographic scheme. However, generic groups cannot be implemented: there exist cryptographic
schemes that are secure in the GGM, but insecure when instantiated with any concrete group [Den02].

The algebraic group model. The algebraic group model (AGM, [FKL18]) is a relaxation of the GGM that
tries to avoid impossibilities as in [Den02] while preserving the GGM’s usefulness. Specifically, the AGM only
considers algebraic (rather than generic) adversaries. An algebraic adversary A can make arbitrary use of
the representation of group elements, but must supply an explicit decomposition for any of its output group
elements in terms of input group elements. In other words, A must also output an explanation of how any
group element in its output was computed from its input using the group operation.

Now [FKL18] show that many GGM proofs only use this type of algebraicity of an adversary, and carry over
to the AGM. At the same time, GGM impossibilities like [Den02] do not apply to the AGM, since algebraic
adversaries are able to work with the actual group (and not only with random or abstract representations of
group elements).

The AGM and knowledge assumptions. The AGM is closely related to the notions of knowledge assumptions
and extractability. To illustrate, assume that for any (possibly non-algebraic) adversary A, we can find an
extractor E that manages to extract from A a decomposition of A’s output in terms of A’s input. Then,
composing E and A yields an algebraic adversary Aalg. In this situation, we can then say that without loss of
generality, any adversary can be assumed to be algebraic.4 Conversely, any algebraic adversary by definition
yields the results of such an extraction in its output.

This observation also provides a blueprint to instantiating the AGM: simply prove that any adversary
A can be replaced by an algebraic adversary Aalg, possibly using an extraction process as above. If this
extraction requires A’s code and randomness but no other trapdoor, we obtain an AGM instantiation
based on a knowledge assumption such as the knowledge of exponent assumption [Dam92]. Indeed, this was
recently done by [KP19] under a very strong generalized version of the knowledge of exponent assumption.
Unfortunately, such knowledge assumptions are not falsifiable in the sense of Naor [Nao03]. It is thus not
entirely clear how to assess the plausibility of such a universal and strong knowledge assumption. Naturally,
the question arises whether an AGM implementation inherently requires such strong and non-falsifiable
assumptions. Or, more generally:

Can we achieve knowledge-type properties
from falsifiable assumptions?

Note that in the AGM, the discrete logarithm assumption implies the existence of extractable one-way
functions (EOWFs) with unbounded auxiliary input. The existence of such EOWFs, however, conflicts with
the existence of indistinguishability obfuscation, [Bit+14]. Due to this barrier, we can only hope for an
instantiation of some suitably relaxed variant of the AGM from falsifiable assumptions.

3 Other black-box abstractions of groups with similar ramifications exist [Nec94; BL96].
4 This observation about algebraic adversaries has already been made in [BV98; PV05]. Also, similar but more specific

knowledge assumptions have been used to prove concrete cryptographic constructions secure, e.g., [Dam92; HT98;
BP04; Den06].

2



Our strategy: private extraction. There is also another way to instantiate the AGM: show that it is possible
to extract a decomposition of A’s outputs from these outputs and a suitable (secret) extraction trapdoor. In
other words, our idea is to avoid non-falsifiable knowledge assumptions by assuming that extraction requires
a special trapdoor that can be generated alongside the public parameters of the group. This entails a number
of technical difficulties (see below), but allows us to rely entirely on falsifiable assumptions.

Specifically, our main result is an algebraic wrapper that transforms a given cyclic group into a new one
which allows for an extraction of representations. More specifically, an element of the new group carries an
encrypted representation of this group element relative to a fixed basis (i.e., set of group elements). Upon
group operations, this representation is updated, and a special trapdoor (generated alongside the public
parameters) allows to extract it.

Our results. Our strategy allows us to retrieve several AGM results (from [FKL18; FPS19]) in the standard
model, in the sense that the group can be concretely implemented from falsifiable assumptions.5 In particular,
we show that in our group,

– the discrete logarithm assumption, the computational Diffie-Hellman assumption, the square Diffie-Hellman
assumption, and the linear-combination Diffie-Hellman assumption (see [FKL18]) are all equivalent,

– the security of the Schnorr signature scheme [Sch91] can be tightly reduced to the discrete logarithm
assumption escaping impossibility results due to [FJS19]. Similarly, Schnorr-signed ElGamal can be shown
tightly IND-CCA2 secure.6

While, on a technical level, the AGM proofs from [FKL18; FPS19] need to be adapted, the general AGM
proof strategies (that rely on extraction) can be replicated.

Limitations. We note that not all known AGM proofs can be transported to the standard model. For instance,
[FKL18] also prove the Boneh-Lynn-Shacham [BLS04] signature scheme tightly secure in the AGM. Their
reduction relies on the fact that the view of a signature forger is statistically independent of how simulated
signatures are prepared by the reduction. However, with our algebraic wrapper, group elements (and thus
BLS signatures) always carry an encrypted representation of how they were generated. In this case, our
private extraction strategy also reveals additional (statistical, computationally hidden) information to an
adversary. This additional information is problematic in the AGM-based BLS proof of [FKL18]. We believe it
is an interesting open problem to obtain a tight security proof for the BLS scheme with our group.7

Furthermore, as we will detail below, the amount of information we can extract from a group element is
limited by the size of that group element. In particular, in settings in which no a-priori bound on the size of
a desired algebraic representation is known, our techniques do not apply. This can be problematic, e.g., for
constructions that depend on q-type assumptions.

Our assumptions. We stress that our algebraic wrapper relies on a strong (but falsifiable) computational as-
sumption: the existence of subexponentially strong indistinguishability obfuscation (subexp-iO).8 Additionally,
we assume a re-randomizable encryption scheme. Together with subexp-iO, this implies a number of other
strong primitives that we use: a variant of probabilistic iO (see [Can+15]), fully homomorphic encryption
(see [Can+15]), and dual-mode non-interactive zero-knowledge (see [HU19]).

Interpretation. Due to their inefficiency, we view algebraic wrappers not as a tool to obtain practical
cryptographic primitives. Rather, we believe that algebraic wrappers show that the AGM is a useful and

5 Note that by “standard model”, we mean that the group itself is formulated without idealizations and can be
concretely implemented. While our construction itself does not rely on the ROM, we still can transfer some ROM
proofs in the AGM to ROM proofs using our concrete group instantiation. We stress that a standard model
instantiation of the (full-fledged) AGM from very strong non-falsifiable assumptions is already known due to [KP19].

6 Tight security reductions provide a tight relation between the security of cryptographic schemes and the hardness of
computational problems. Apart from their theoretical importance, tight reductions are also beneficial for practice,
since they allow smaller keylength recommendations.

7 We note that impossibility results for tight reductions of schemes like BLS (e.g., [Cor00]) do not apply in our case,
as the representation of our group elements is not unique.

8 We note that iO and knowledge assumptions contradict each other [Bit+14]. However, we stress that the notion of
private extractability we obtain does not contradict iO.

3



realistic abstraction and not merely an idealized model which heuristically captures known adversaries: we
show that AGM proofs can be replicated in the standard model, and even without resorting to knowledge
assumptions.

On implementing idealized models. Replacing idealized (heuristic) models with concrete standard-model
implementations is a widely studied intriguing problem. A well-known example for this is the line of work on
programmable hash functions. A programmable hash function due to [HK12] is a cryptographic primitive
which can be used to replace random oracles in several cryptographic schemes. Following their introduction,
a line of work [Fre+13; HSW13; HSW14] leveraged multi-linear maps or indistinguishability obfuscation to
transport proofs from the random oracle model to the standard model. Our results can be interpreted as
following this endeavor by leveraging indistinguishability obfuscation to replace the AGM with a standard
model implementation (from falsifiable assumptions). From this angle, our algebraic wrapper relates to the
AGM as programmable hash functions relate to the ROM.

1.1 Technical overview

Algebraic wrappers. In the following, we speak of group schemes ([Alb+16], also called encoding schemes
in [GGH13]) as a generalization of groups with potentially non-unique encodings of group elements. This
implies that a dedicated algorithm is required to determine if two given group elements are equal.9 Our
algebraic wrapping process takes a group G (which we call “base group”) as input, and outputs a new group

scheme H which allows for an efficient extraction process. Concretely, every H-element ĥ can be viewed as a
G-element h ∈ G, plus auxiliary information aux .

Intuitively, aux carries (encrypted) information that allows to express h as a linear combination of fixed
base elements b1, . . . , bn ∈ G. The corresponding decryption key (generated alongside the group parameters)
allows to extract this information, and essentially yields the information any algebraic adversary (in the
sense of the AGM) would have to provide for any output group element. However, we are facing a number of
technical problems:
(a) The group operation algorithm should update aux (in the sense that the linear combinations encrypted

in the input elements should be added).
(b) Validity of aux should be ensured (so that no adversary can produce an H-element from which no valid

linear combination can be extracted from aux ).
(c) It should be possible to switch the basis elements b1, . . . , bn to an application-dependent basis. (For

instance, to prove a signature scheme like Schnorr’s [Sch91] secure, one would desire to set the basis
vectors to elements from an externally given computational challenge.)

(d) To preserve tightness of reductions from the AGM (which is necessary in some of our applications), it
should be possible to re-randomize group element encodings statistically.

Our solution largely follows the group scheme from [Alb+16]. In particular, (a) will be solved by encrypting
the coefficients z1, . . . , zn with h =

∑
i b
zi
i using a homomorphic encryption scheme in aux . Hence, such

coefficient vectors can be added homomorphically during the group operation. For (b), we will add a suitable
non-interactive zero-knowledge proof of consistency in aux .10 For (c), we adapt a “switching” lemma from
[Alb+16]. In [Alb+16], that lemma allows to switch between two different representations of the same group
element, but under a fixed basis. In our case, we show that similar techniques allow to also switch the
group elements that form this basis. This switching property already implies a notion of computational
re-randomizability. Finally, for (d), we introduce a re-randomization lemma using techniques from (c) in
conjunction with a novel notion for probabilistic iO.

At this point, one main conceptual difference to the line of work [Alb+16; AH18; Far+18] is that the basis
elements b1, . . . , bn appear as part of the functionality of the new group scheme H, not only in a proof. In
particular, our construction must be able to deal with arbitrary bi that are not necessarily randomly chosen.
This issue is dealt with by additional linear randomization of the base group elements.

9 That is, formally, the group is defined as the quotient set of all well-formed bitstrings modulo the equivalence
relation induced by the equality test.

10 Note that this approach is related to [BSW12] in the sense that we restrict the homomorphic operations an adversary
can perform on encodings by requiring a consistency proof.

4



Another main conceptual difference to [Alb+16; AH18; Far+18] is the notion of statistical re-randomiz-
ability of group elements. The group schemes from [Alb+16; AH18; Far+18] do not satisfy this property.
This will be resolved by developing a stronger notion of statistically correct probabilistic iO which may be of
independent interest.

We note, however, that our techniques are inherently limited in the following sense: our extraction can
only extract as much information as contained in (the auxiliary information of) group elements. Technically
speaking, we cannot treat settings in which the size of the basis b1, . . . , bn is not known in advance (e.g., in
case of constructions based on q-type assumptions).

Applications. The applications we consider have already been considered for the AGM in [FKL18; FPS19].
Hence, in this description, we focus on the technical differences that our extraction approach entails for these
proofs.

First, recall that in the AGM by [FKL18], an adversary outputs an algebraic representation of each
output group element to the basis of its input group elements. Therefore, this basis depends also on the
respective security game. On the other hand, in security proofs with our algebraic wrapper, a reduction needs
to select such a basis in advance. The appropriate selection of such a basis is one of the main challenges when
transferring proofs from the AGM to our setting. Namely, even though the basis as well as the representation
of each group element is hidden, the choice of representations will still be information-theoretically known
to the adversary. Therefore, security games that are identically distributed in the AGM might only be
computationally indistinguishable in the wrapper, depending on the choice of a basis.

When transferring proofs from the AGM to our new group scheme, we thus use a technique we call
symmetrization to extend the basis in such a way that security games are identically distributed in the
relevant situations. In a nutshell, symmetrization achieves a uniform way to express challenge elements across
most games of a security proof, and yields statistical security guarantees.

Another challenge is the implementation of tight security reductions in the wrapper. In some security
reductions, the basis of the group and the algebraic representations of oracle responses need to be switched in
order to be able to extract a useful algebraic representation. However, as we only achieve computationally
indistinguishable group element representations, switching the representations of q oracle responses would
lead to a q-fold computational loss, compromising the tightness of the reduction.

We show that it is possible to circumvent this loss by constructing oracle responses via the group operation
from so-called origin elements, reducing the number of elements whose representation gets switched to a
constant. In a nutshell, we derive many coordinated oracle answers from just few group elements (the “origin
elements”), such that switching these origin elements affects (and changes) all oracle answers.

1.2 Related work

This work builds upon the line of work [Alb+16; AH18; Far+18] who build group schemes from iO. [Alb+16]
lays the conceptual foundations for the construction of group schemes with non-unique encodings from iO
and uses this framework to equip groups with multilinear maps. [Far+18] extends this approach by allowing
partial evaluations of the multilinear map yielding a graded encoding scheme. In contrast to [Alb+16; Far+18],
[AH18] does not extend the functionality of an underlying group, but builds a group scheme with reduced
functionality (group elements lack a unique representation). The resulting group scheme allows to mimic
commonly used proof techniques from the generic group model. This is demonstrated by proving the validity
of an adaptive variant of the Uber assumption family [Boy08] in the constructed group scheme. Our results
can hence be viewed as an extension of [AH18].

[KP19] make a first step towards instantiating the AGM. The authors identify an equivalence between the
AGM and a very strong generalized version of the knowledge of exponent assumption [Dam92], thus giving
rise to the first instantiation of the AGM.

Acknowledgments

We would like to thank the anonymous reviewers of EC20 for many helpful comments and for pointing out
an error in previous versions of Lemmas 9 and 10.

5



2 Preliminaries

Notation

Throughout this paper Ν denotes the security parameter. For a natural number n ∈ N, [n] denotes the
set {1, . . . , n}. A function negl : N → R is negligible in λ if for every constant c ∈ N, there exists a bound
nc ∈ R, such that for all n ≥ nc, |negl(n)| ≤ n−c. Given a finite set S, the notation x← S means a uniformly
random assignment of an element of S to the variable x. Given an algorithm A, the notation y ← A(x) means
evaluation of A on input of x with fresh random coins and assignment to the variable y. The notation AO
indicates that the algorithm A is given oracle access to O. Given a random variable B, supp(B) denotes the
support of B.

Let G be a finite cyclic group with generator g and order p. For x ∈ Zp, the notation [x]G denotes the
group element gx. Note that using this notation does not imply knowledge of x. Let K be a field and V be a
vector space over K of finite dimension n. For i ∈ [n], ei denotes the vector which carries 1 in its i-th entry
and 0 in all other entries.

In game based proofs, out i denotes the output of game Gi. Further, we will use this notation to highlight
differences to previous hybrids.

2.1 Subset membership problem

Let L = (Lλ)λ∈N be a family of families of languages L ⊆ Xλ in a universe Xλ = X. Further, let R be an
efficiently computable witness relation, such that x ∈ L if and only if there exists a witness w ∈ {0, 1}poly(|x|)
with R(x,w) = 1 (for a fixed polynomial poly). We assume that we are able to efficiently and uniformly sample
elements from L together with a corresponding witness, and that we are able to efficiently and uniformly
sample elements from X \ L.

Definition 1 (Subset membership problem, [CS02]). A subset membership problem L ⊆ X is hard,
if for any PPT adversary A, the advantage

Advsmp
L,A (λ) := Pr[x← L : A(1λ, x) = 1]− Pr[x← X \ L : A(1λ, x) = 1]

is negligible in Îť.

We additionally require that for every L and every x ∈ L, there exists exactly one witness r ∈ {0, 1}∗
with R(x,w) = 1. Note that given a cyclic group G of prime order p in which DDH is assumed to hold, the
Diffie-Hellman language L[(1,x)]G

:= {[(y, xy)]G | y ∈ Zp} (for randomly chosen generators [1]G , [x]G) satisfies
this definition. Another instantiation of Definition 1 is the language containing all commitments to a fixed
value using a perfectly binding commitment scheme with unique opening.

2.2 Dual-mode NIWI

A dual-mode NIWI proof system is a variant of NIWI proofs [FS90] offering two computationally indis-
tinguishable modes to setup the common reference string (CRS). A binding mode CRS provides perfect
soundness guarantees whereas a hiding mode CRS provides perfect witness indistinguishability guarantees.

Note that there are instantiations of NIWI proof systems without common reference string [BP15].
These instantiations, however, do not satisfy perfect soundness and perfect witness-indistinguishability
simultaneously.

Definition 2 (Dual-mode NIWI proof system, [GS08; Alb+16]). A dual mode non-interactive
witness-indistinguishable (NIWI) proof system for a relation R is a tuple of PPT algorithms Π = (Setup,
HSetup,Prove,Verify,Ext).

Setup(1Îť). On input of 1Îť, Setup outputs a perfectly binding common reference string crs and a corresponding
extraction trapdoor td ext.

HSetup(1Îť). On input of 1Îť, HSetup outputs a perfectly hiding common reference string crs.

6



Prove(crs, x, w). On input of the CRS crs, a statement x and a corresponding witness w, Prove produces a
proof π.

Verify(crs, x, π). On of the CRS crs, a statement x and a proof π, Verify outputs 1 if the proof is valid and 0
otherwise.

Ext(td ext, x, π). On input the extraction trapdoor td ext, a statement x and a proof π, Ext outputs a witness w.

We require Π to satisfy the following properties.

CRS indistinguishability. For all PPT adversaries A,

Advcrs-ind
Π,A (Ν) :=

∣∣Pr[(crs, td ext)← Setup(1λ) : A(1λ, crs) = 1]

− Pr[crs← HSetup(1λ) : A(1λ, crs) = 1]
∣∣

is negligible.
Perfect completeness. For all Ν ∈ N, all (crs, ¡) ∈ supp(Setup(1Ν)), all (x,w) such that (x,w) ∈ R, and

all π ∈ supp(Prove(crs, x, w)), Verify(crs, x, π) = 1. The same holds for all crs ∈ supp(HSetup(1λ)).
Perfect soundness under Setup. For all Ν ∈ N, all (crs, ¡) ∈ supp(Setup(1Ν)), all statements x such that

there exists no witness w with (x,w) ∈ R and all π ∈ {0, 1}∗, Verify(crs, x, π) = 0.
Perfect extractability under Setup. For all λ ∈ N, all tuples (crs, td ext) ∈ supp(Setup(1λ)), all (x, π) such

that Verify(crs, x, π) = 1 and for all w ∈ supp(Ext(td ext, x, π)), w is a satisfying witness for the statement
x, that is (x,w) ∈ R.

Perfect witness-indistinguishability under HSetup. For every Ν ∈ N, all crs ∈ supp(HSetup(1Ν)), all
(x,w0) and (x,w1) with (x,w0), (x,w1) ∈ R, the output distributions of Prove(crs, x, w0) and of Prove(crs,
x, w1) are identical.

There are several instantiations of dual-mode NIWI proof systems satisfying the above definition. The
construction [GS08] relies on pairing-friendly groups where either the pairing is asymmetric and the SXDH
assumption holds, or the pairing is symmetric and the DLin assumption holds. [PS19] build a (statistically
secure, statistically extractable and statistically zero-knowledge) dual-mode NIZK from the plain learning with
errors assumption. The recent paper [HU19] proposes an instantiation of (a statistically secure, statistically
extractable and statistically witness-indistinguishable) dual-mode NIWI proof system based on strong but
unstructured assumptions, namely, sub-exponentially secure indistinguishability obfuscation, sub-exponentially
secure one-way functions and a secure lossy encryption scheme.

2.3 Probabilistic indistinguishability obfuscation

Let C = (CΝ)Ν∈N be a family of sets CΝ of probabilistic circuits. The set CΝ contains circuits of polynomial size
in Îť with input length n(Îť) expecting (at most) m(Îť) random bits. A circuit sampler for C is defined as a
family of (efficiently samplable) distributions S = (SΝ)Ν∈N, where SΝ is a distribution over triplets (C0, C1, z)
with C0, C1 ∈ CΝ such that C0 and C1 take inputs of the same length and z ∈ {0, 1}poly(Ν). We write S(1Ν)
to denote efficient sampling according to SÎť.

Definition 3 (X-ind sampler, [Can+15]). Let X(Îť) be a function upper bounded by 2Îť. The class SX-ind

of X-ind samplers for a circuit family C contains all circuit samplers S = (SΝ)Ν∈N for C such that for all
λ ∈ N, there exists a set Xλ ⊆ {0, 1}∗ with |X | ≤ X(λ), such that

X-differing inputs. With overwhelming probability over the choice of (C0, C1, z)← Sλ, for every x 6∈ Xλ,
for all r ∈ {0, 1}m(Ν), C0(x; r) = C1(x; r).

X-indistinguishability. For all (non-uniform) adversaries A, the advantage

X(Ν) ¡
(

Pr[Expsel-ind
S,A (λ) = 1]− 1

2

)
is negligible, where Expsel-ind

S,A (Îť) is defined in Figure 1.

7



Expsel-ind
S,A (Îť)

(x, st)← A(1λ)
(C0, C1, z)← S(1λ)
b← {0, 1}
y ← Cb(x)
b′ ← A(st, (C0, C1, z), y)
return b = b′

Fig. 1: Description of the game Expsel-ind
S,A (Îť).

Definition 4 (Probabilistic indistinguishability obfuscation for a class of samplers S, [Can+15]).
A probabilistic indistinguishability obfuscator for a class of samplers S over the probabilistic circuit family
C = (CΝ)Ν∈N is a uniform PPT algorithm piO, such that the following properties hold.

Correctness. For every PPT adversary A, every C ∈ CΝ, the advantage of A, given the description of the
circuit C, to distinguish oracle access to the original randomized circuit C from oracle access to piO(C) is
negligible. Note that A is not allowed to query the oracle more than once on the same input.

Security with respect to S. For all circuit samplers S ∈ S, for all PPT adversaries A, the advantage

Advpio-ind
piO,S,A (Ν) :=∣∣∣Pr
[
(C0, C1, z)← S(1λ) : A(1λ, C0, C1, z, piO(1λ, C0)) = 1

]
−Pr

[
(C0, C1, z)← S(1λ) : A(1λ, C0, C1, z, piO(1λ, C1)) = 1

] ∣∣∣
is negligible.

[Can+15] present the to date only known construction of pIO for X-ind samplers over the family of all
polynomial sized probabilistic circuits. Given a probabilistic circuit C with size at most Îť, piO(C) samples a
PRF key K and obfuscates the deterministic circuit C which on input of x evaluates the deterministic circuit
C(x;F (K,x)). Furthermore, this construction respects the support of the original randomized circuit, i.e. for
all circuits C ∈ Cλ, all inputs x ∈ {0, 1}∗ (of matching length), all Λ ∈ supp(piO(C)), Λ(x) ∈ supp(C(x)).

2.4 Re-randomizable and fully homomorphic encryption

Definition 5 (Public-key encryption (PKE), [Gam85]). An IND-CPA secure public-key encryption
scheme for message spaceM is a tuple of algorithms PKE = (KGen,Enc,Dec) such that the following properties
are satisfied.

Perfect correctness. For all (pk , sk) ∈ supp(KGen(1Ν)), all m ∈M,

Pr
[
Dec(sk ,Enc(pk ,m)) = m

]
= 1.

IND-CPA security. For all legitimate PPT adversaries A,

Advind-cpa
PKE,A (Îť) :=

∣∣∣∣∣Pr

 (pk , sk)← KGen(1λ)
(m0,m1, st)← A(pk)

c∗ ← Enc(pk ,m0)
: A(pk , c∗, st) = 1



−Pr

 (pk , sk)← KGen(1λ)
(m0,m1, st)← A(pk)

c∗ ← Enc(pk ,m1)
: A(pk , c∗, st) = 1


∣∣∣∣∣

is negligible, where legitimate means that A always outputs two messages m0,m1 ∈M of identical length.

Without loss of generality, we assume that sk is the random tape used for key generation. Therefore,
making the random tape of KGen explicit, we write (pk , sk) = KGen(1Îť; sk).

A re-randomizable public-key encryption scheme allows to perfectly re-randomize any ciphertext.

8



Definition 6 (Perfectly re-randomizable public-key encryption, [PR07]). A perfectly re-random-
izable public-key encryption scheme with message space {0, 1}∗ is a tuple of PPT algorithms E = (KGen,Enc,
Dec,Rerand) such that (KGen,Enc,Dec) is a perfectly correct PKE scheme such t";"""date"",""2020-12-23T20:00:59Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2020-12-23T20:00:59Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.21 (TeX Live 2020/Alpine Linux) kpathsea version 6.3.2""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2020-12-23T20:00:59Z""
""created"",""2020-12-23T20:00:59Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-12-23T20:00:59Z""
""resourceName"",""AgrikolaHK20.pdf""
""Author"",""""
""producer"",""pdfTeX-1.40.21""
""pdf:docinfo:producer"",""pdfTeX-1.40.21""
""pdf:unmappedUnicodeCharsPerPage"",""7"",""0"",""0"",""2"",""0"",""0"",""7"",""24"",""4"",""80"",""53"",""32"",""61"",""50"",""1"",""38"",""54"",""42"",""56"",""25"",""34"",""53"",""53"",""56"",""0"",""27"",""21"",""24"",""44"",""57"",""49"",""37"",""124"",""136"",""129"",""110"",""80"",""0"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2020-12-23T20:00:59Z""
""Last-Modified"",""2020-12-23T20:00:59Z""
""dcterms:modified"",""2020-12-23T20:00:59Z""
""title"",""""
""Last-Save-Date"",""2020-12-23T20:00:59Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2020-12-23T20:00:59Z""
""meta:save-date"",""2020-12-23T20:00:59Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.21 (TeX Live 2020/Alpine Linux) kpathsea version 6.3.2""
""Content-Length"",""720223""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""40""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""2974"",""3759"",""4103"",""3846"",""3727"",""2753"",""2820"",""2146"",""3706"",""3596"",""2206"",""2504"",""2782"",""2725"",""3621"",""3709"",""2792"",""2520"",""3433"",""2637"",""4121"",""2786"",""3245"",""3313"",""4096"",""2752"",""2040"",""2440"",""2502"",""3345"",""2320"",""2981"",""2737"",""2611"",""3043"",""1811"",""3010"",""3619"",""3511"",""1802""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-12-23T20:00:59Z""
";https://scholar.google.ch/scholar?start=880&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098774-126;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;A federated society of bots for smart contract testing;E Viglianisi, M Ceccato, P Tonella ; Journal of Systems and Software, 2020  Elsevier;;"… SoCRATES supports oracle specification taking the form of contract invariants … A contract account

has also an internal storage, stored in the blockchain, to save additional persistent information …

the society of bots and the set of invariants that can be used as testing oracles …";Cité 3 fois;Les 2 versions;null;;;;https://scholar.google.ch/scholar?start=670&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098813-220;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;[PDF][PDF] Scaling-out Blockchains with Sharding: An extensive survey;G Yu, X Wang, K Yu, W Ni, JA Zhang… ; Blockchains for Network …  researchgate.net;;"… Working as distributed, incorruptible, and tamper-resistant ledgers, Blockchain tech- nology has

shown its great potential to tackle critical security and trust challenges in various applications,

eg, cryptocurrency, Internet-of-Things, and edge comput- ing [1]-[3]. Running over a …";Autres articles;Version HTML;[PDF] researchgate.net;https://www.researchgate.net/profile/Guangsheng_Yu/publication/347284313_Scaling-out_blockchains_with_sharding_an_extensive_survey/links/5ffe46b945851553a03d5cbf/Scaling-out-blockchains-with-sharding-an-extensive-survey.pdf;;;https://scholar.google.ch/scholar?start=760&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098738-43;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;JE LI BLOCKCHAIN TEHNOLOGIJA BUDU?NOST DIGITALIZACIJE ZEMLJIŠNIH KNJIGA?;J Deši?, K Lenac ; Zbornik Pravnog fakulteta Sveu?ilišta u Rijeci, 2020  hrcak.srce.hr;;"… 7 Narayanan i dr., Bitcoin and cryptocurrency technologies, 27-38 8 Narayanan i dr., Bitcoin and

cryptocurrency technologies, 27-38 9 Jacques Vos, Blockchain-based land registry: Panacea …

oracles) koji analiziraju podatke vanjskog svijeta i pohranjuju ih u blockchain …";Autres articles;;[PDF] srce.hr;https://hrcak.srce.hr/ojs/index.php/zpfsr/article/download/12206/5997/;"
J. DEŠIĆ, K. LENAC, Je li blockchain tehnologija budućnost digitalizacije...
Zbornik Pravnog fakulteta Sveučilišta u Rijeci, vol. 41, br. 2, 609-630 (2020) 609

JE LI BLOCKCHAIN TEHNOLOGIJA BUDUĆNOST 
DIGITALIZACIJE ZEMLJIĹ NIH KNJIGA?

Josip Dešić, mag. iur.* UDK: 349.418:004.3/.4004.738.5:34 
Izv. prof. dr. sc. Kristijan Lenac** https://doi.org/10.30925/zpfsr.41.2.9
 Ur.: 26. svibnja 2020.
 Pr.: 21. lipnja 2020.
 Pregledni rad

SaĹžetak

U radu se daje prikaz osnovnih značajki blockchain tehnologije i analizira 
mogućnost njezine primjene u radu zemljišnih registara. Razmatra se kako 
blockchain moĹže unaprijediti sigurnost i transparentnost registra nekretnina, 
osigurati integritet podataka, ubrzati i olakĹĄati prijenos prava na nekretninama 
i postupak upisa. Navode se primjeri Estonije, koja je najdalje odmakla u 
primjeni blockchain tehnologije u javnoj upravi i uspostavila digitalno druĹĄtvo, 
kao i primjer Švedske, u kojoj je 2018. dovršena treća etapa pilot projekta o 
primjeni blockchain tehnologije u radu zemljiĹĄnoga registra. Navode se i primjeri 
Brazila, Hondurasa, Gruzije i Dubaija. Zaključno se razmatra opravdanost 
uvođenja blockchain tehnologije u hrvatski zemljišnoknjižni sustav.

Ključne riječi: digitalizacija zemljišnih knjiga; blockchain tehnologija; 
pametni ugovori.

1. UVOD

ZemljiĹĄni registri jedni su od najvaĹžnijih javnih registara. Iz zemljiĹĄnih registara 
vidljivi su pravni status nekretnina, narav nekretnina, nositelji prava na nekretninama, 
ograničenja prava vlasništva i drugi podatci relevantni za pravni promet nekretnina. 
Uređeni zemljišni registri iznimno su važni za upravljanje nekretninama, prostorno 
planiranje i zaštitu okoliša. Iako se zemljišni registri i njihovo pravno uređenje 
razlikuju od države do države, njihov je cilj isti, omogućiti siguran pravni promet 
nekretninama.1

U modernizaciji zemljiĹĄnih registara veliku ulogu imaju suvremene tehnologije. 
Priliku za unaprjeđenje svoga registra nekretnina mnogi vide u blockchainu, 
decentraliziranoj digitalnoj knjizi, mjestu za pohranu zapisa, koju pokreće mreža 
računala, od kojih svako računalo sadrži stalno ažuriranu kopiju cijelog blockchaina. 

* Josip Dešić, mag. iur., asistent, Sveučilište u Rijeci, Pravni fakultet; jdesic@pravri.hr.
** Dr. sc. Kristijan Lenac, izvanredni profesor, Sveučilište u Rijeci, Tehnički fakultet; kristijan.

lenac@riteh.hr.
1 Benjamin Verheye, „Real estate publicity in a blockchain world: a critical assessment“, 

European property law journal 6, br. 3 (2017): 441-477.



J. DEŠIĆ, K. LENAC, Je li blockchain tehnologija budućnost digitalizacije...
Zbornik Pravnog fakulteta Sveučilišta u Rijeci, vol. 41, br. 2, 609-630 (2020)610

Njegove karakteristike poput decentralizacije, pouzdanosti i sigurnosti otvaraju ĹĄirok 
spektar inovativnih mogućnosti. Pored visoke razine sigurnosti i transparentnosti, 
jedan je od glavnih motiva za uvođenje blockchain tehnologije u rad zemljišnih 
registara i mogućnost automatizacije procesa kako bi se  skratilo vrijeme i smanjio 
broj radnji potrebnih za upis. U klasičnom sustavu, može proteći i do nekoliko mjeseci 
od podnošenja prijedloga za upis i upisa promjena u registar, međutim primjenom 
blockchaina, cjelokupni se postupak upisa moĹže pojednostavniti i time skratiti vrijeme 
i smanjiti troĹĄkove upisa.2

Iako su i ranije neke drĹžave informatizirale svoje zemljiĹĄne registre, ta je 
informatizacija obuhvaćala prijenos ručno vođenih podataka u digitalni oblik, ali 
ne i elektroničku obradu digitalnih informacija. Tek su posljednja dva desetljeća 
dovela do provedbe ideje o elektroničkom prijenosu prava na nekretninama prema 
kojoj se prijedlog za upis elektronički obrađuje od etape podnošenja prijedloga, pa 
čak i sklapanja ugovora, do etape konačnog upisa. Ponajprije valja istaknuti primjere 
Estonije i Ĺ vedske, koje su do sada postigle najbolje rezultate u digitalizaciji i 
elektroničkoj obradi podataka u zemljišnim registrima (o čemu detaljnije u nastavku 
rada).3

Sve veći broj država diljem svijeta razmatra mogućnost uvođenja blockchain 
tehnologije u rad registra nekretnina. S jedne strane, postojeći i dobro funkcionirajući 
zemljišni registri testiraju blockchain tehnologiju kako bi postali učinkovitiji, sigurniji, 
pristupačniji i transparentniji (npr. Estonija, Švedska), dok se s druge, blockchain 
tehnologija primjenjuje kako bi se tek stvorio zemljiĹĄni registar u zemljama u kojima 
on danas ne postoji, ili ako postoji, funkcionira na loĹĄoj razini (npr. Gana).4

2. BLOCKCHAIN TEHNOLOGIJA I NJEZINE TEMELJNE 
ZNAČAJKE

Blockchain je distribuirana elektronička knjiga zapisa koja ne zahtijeva 
centralno mjerodavno tijelo da bi jamčila vjerodostojnost pohranjenih podataka. Takva 
se tehnologija počela koristiti s bitcoin kriptovalutom kako bi omogućila prijenos 
digitalne bitcoin valute bez potrebe za pouzdanim posrednikom. Međutim, blockchain 
tehnologija ubrzo je nadrasla bitcoin te je proĹĄirila svoju primjenu na mnoga druga 
područja (bankarstvo, osiguranje, intelektualno vlasništvo, elektroničko glasovanje, 
zdravstvo, računovodstvo, e-uprava, zemljišni registri, promet robe itd.).5

Ideja je blockchaina jednostavna: izbjeći potrebu za posrednikom korištenjem 
distribuirane knjige zapisa s čijim se sadržajem svi slažu. Umjesto povjerenja da 
će neko mjerodavno tijelo ili posrednik jamčiti autentičnost i sigurnost sadržaja, 
povjerenje se prebacuje na programski kod. No, iako je ideja jednostavna, njezina je 
implementacija dosta složena. Blockchain održava i pokreće mreža računala koji se 

2 Verheye, Real estate publicity in a blockchain world.
3 Tako i Haim Sandberg, „Real estate e-conveyancing: vision and risks“, Information & 

communications technology law 19, br. 2 (2010): 101–114.
4 Verheye, Real estate publicity in a blockchain world.
5 Laurence Leloup, Blockchain - La revolution de la confiance (Paris: Eyrolles, 2018.), 129.



J. DEŠIĆ, K. LENAC, Je li blockchain tehnologija budućnost digitalizacije...
Zbornik Pravnog fakulteta Sveučilišta u Rijeci, vol. 41, br. 2, 609-630 (2020) 611

nazivaju čvorovi (engl. nodes), a svako računalo sadrži istovjetnu kopiju cijele baze 
podataka tako da nema jedinstvene točke kvara (engl. single point of failure). Čvorovi 
koriste decentralizirani peer-to-peer (P2P) model komunikacije u kojemu čvorovi 
međusobno komuniciraju s ostalim čvorovima u mreži. Čvorovi su uvijek spremni 
prihvaćati zahtjeve od ostalih čvorova ili korisnika iste blockchain mreže.6

Svi podatci koji se ĹĄalju na pohranu u blockchain mreĹžu kodirani su i digitalno 
potpisani privatnim ključem pošiljatelja. Čvor koji primi zahtjev provjerava potpis 
i valjanost podataka te, ako je sve u redu, grupira te podatke s drugim zahtjevima u 
novi blok podataka. Novi se blok potom slijedno veže na prethodni blok s pomoću 
kriptografskih tehnika te tako nastaju lanci blokova koji predstavljaju kontinuirano 
proĹĄirivu knjigu zapisa kroz vrijeme. Jednom kada su podatci zapisani i prihvate 
ih čvorovi u mreži, promjene i brisanja više nisu moguća što blockchain čini 
neizmjenjivim i trajnim.7

Problem koji se uspio riješiti pri uvođenju bitcoin kriptovalute je da je navedeno 
ostvarivo čak i ako je u blockchain mreži dio čvorova maliciozan i ne prati pravila. 
Uveden je Proof-of-Work protokol kojim se postiže konsenzus među svim čvorovima 
u mreži koji je sljedeći validan blok koji će se dodati u lanac.8 Kako tekst ovoga rada 
ne bi bio previše opsežan opis Proof-of-Work protokola, kao i drugih inačica protokola 
za postizanje konsenzusa koje su kasnije predložene, neće se prikazivati.

Ono što je važno znati je da postizanjem konsenzusa među većinom poštenih 
čvorova znači da se svi slažu oko sadržaja i stanja baze. Informacije pohranjene 
u blokovima otporne su na zloupotrebe, čak i onih koji pohranjuju i obrađuju te 
informacije. To pak znači da prijevare nisu moguće i da više nema potrebe za nekom 
pouzdanom strankom u koju treba imati povjerenje. Jednom kad se sva računala u 
sustavu suglase oko informacije u lancu, podatke više nije moguće mijenjati, a da 
to ne registriraju drugi sudionici iste blockchain mreĹže.9 Svaki pokuĹĄaj manipulacije 
podatcima lako se otkriva. Važno je naglasiti da blockchain ne može spriječiti 
protuzakonitu aktivnost, međutim on je 100 % učinkovit u njezinu otkrivanju. Svi su 
podatci digitalno potpisani i provjerljivi svim sudionicima blockchain mreĹže. Sve to 
stvara visoku razinu povjerenja među korisnicima.10 

2.1. Javni i privatni blockchain

Blockchain mreĹže mogu biti javne ili privatne ovisno o razini otvorenosti 
sustava prema sudionicima.

Javni blockchain (knjiga otvorena svima) karakterizira potpuna otvorenost 
i decentralizacija, svatko moĹže pristupiti transakcijama i svatko moĹže sudjelovati 

6 Arvind Narayanan i dr., Bitcoin and cryptocurrency technologies: a comprehensive introduction 
(Princeton: Princeton University Press, 2016.), 27-38.

7 Narayanan i dr., Bitcoin and cryptocurrency technologies, 27-38 
8 Narayanan i dr., Bitcoin and cryptocurrency technologies, 27-38
9 Jacques Vos, Blockchain-based land registry: Panacea, illusion or something in between?, 

pristup 17. studenog 2019., www.elra.eu/wp-content/uploads/2017/02/10.-Jacques-Vos-
Blockchain-based-Land-Registry.pdf.

10 Vos, Blockchain-based land registry, 1-26.



J. DEŠIĆ, K. LENAC, Je li blockchain tehnologija budućnost digitalizacije...
Zbornik Pravnog fakulteta Sveučilišta u Rijeci, vol. 41, br. 2, 609-630 (2020)612

u procesu konsenzusa. Javni blockhain po prirodi je potpuno decentraliziran te ne 
postoji centralni autoritet ili pouzdana treća strana koja ga nadzire. Programski kod 
blockchaina i pravila ukodirana u njemu otvoreni su i transparentni. Primjeri javnih 
blockchaina na otvorenim peer-to-peer mreĹžama su Ethereum i Bitcoin.11

Privatni blockchain je i dalje peer-to-peer mreža gdje svaki čvor sadrži usklađenu 
istovjetnu kopiju baze koja se ne može mijenjati. Međutim, privatni blockchaini imaju 
jedinstveno odgovorno tijelo, administratora, koje upravlja mrežom i odlučuje koji će 
podatci biti zapisani u blockchain mreži, što je zapravo suprotno temeljnom načelu 
blockchaina. Mreža se sastoji od jednog ili više čvorova koje izvršava administrator 
i ostali sudionici koji su dobili pravo na to od administratora. Svi sudionici moraju 
vjerovati administratoru. Zbog toga se model privatnoga blockchaina ne razlikuje 
mnogo od distribuirane baze podataka u oblaku.12 

Kompleksni protokoli za postizanje konsenzusa viĹĄe nisu potrebni da bi se 
postigao konsenzus oko transakcija koje će biti dodane u blok. To čini privatne 
blockchain mreže učinkovitijima i bržima što je važno u nekim primjenama. Kod 
privatnog blockchaina u pravilu je broj čvorova mreže manji, pravila je ovjere 
lakĹĄe prilagoditi i sustav je fleksibilniji. Primjeri projekata koji pruĹžaju programsku 
podrĹĄku za privatne blockchain mreĹže su Hyperledger Fabric13 i Multichain.14 Kada 
grupa vlasnika zajednički administrira privatnu blockchain mrežu, ona se još naziva i 
konzorcijska ili federirana blockchain mreĹža.15

3. PAMETNI UGOVORI

Pametni su ugovori računalni protokoli namijenjeni digitalnom izvršenju 
ugovora.16 U blockchainu pametni ugovori su računalni programi koji automatski 
izvrĹĄavaju transakcije na blockchainu, odnosno klauzule ugovora, kada se dogodi 
neki zadani događaj ili ispune određeni uvjeti. Izvršavanje je automatsko, bez potrebe 
za ljudskom intervencijom ili trećom stranom.17 Događaj na koje pametni ugovor 
reagira moĹže biti unutar same blockchain mreĹže, primjerice pojavljivanje transakcije 
određenih svojstava ili može ovisiti o vanjskim pružateljima usluga (engl. oracles) 
koji analiziraju podatke vanjskog svijeta i pohranjuju ih u blockchain. Pametni ugovori 
omogućavaju izravno nadziranje i izvršavanje složenih sporazuma među strankama 
bez potrebe za ljudskom intervencijom.18

11 Laurence Leloup, Blockchain - La revolution de la confiance (Paris: Eyrolles, 2018.), 29. et seq.
12 Leloup, Blockchain - La revolution de la confiance, 93 et seq. 
13 Detaljnije o projektu Hyperledger Fabric v. na https://www.hyperledger.org/projects/fabric, 

pristup 20. travnja 2020.
14 Detaljnije o projektu Multichain enterprise blockchain v. na https://www.multichain.com/, 

pristup 20. travnja 2020.
15 Vos, Blockchain-based land registry, 15-17.
16 Nick Szabo, “Formalizing and securing relationships on public networks,” First Monday  2, br. 

9 (1997), https://doi.org/10.5210/fm.v2i9.548.
17 Vitalik Buterin, „A Next Generation Smart Contract & Decentralized Application Platform“, 

Ethereum White Paper (2015), pristup 20. travnja 2020., dostupno na https://github.com/
ethereum/wiki/wiki/White-Paper.

18 Buterin, A Next Generation Smart Contract & Decentralized Application Platform.



J. DEŠIĆ, K. LENAC, Je li blockchain tehnologija budućnost digitalizacije...
Zbornik Pravnog fakulteta Sveučilišta u Rijeci, vol. 41, br. 2, 609-630 (2020) 613

Pametni su ugovori jedna od mogućih nadogradnji na koncept blockchaina, gdje 
se kao vrsta podataka, u blockchain upisuje programski kod. Oni, u biti, nisu ugovori, 
nego način izvršenja ugovora. Vrlo je malo propisa o pametnim ugovorima, međutim, 
to ne znači da se postojeće ugovorno pravo i opća načela prava ne mogu primijeniti i 
na njih ili da su u potpunosti neuređeni.19

4. BLOCKCHAIN I ZEMLJIĹ NI REGISTRI

Među prednostima blockchain tehnologije u radu zemljišnih registara navode se: 
povećana učinkovitost obrade transakcija i smanjenje troškova, smanjenje pogrešaka 
tijekom procesa upisa, sprječavanje prijevara, dodatne razine sigurnosti, transparentnost 
i integritet podataka te niĹža razina ranjivosti na prirodne nepogode ili nepogode 
prouzročene ljudskim faktorom.20 Blockchain može uz osiguranje transparentnost i 
integriteta podataka putem, tzv. pametnih ugovora ubrzati transakciju nekretninom. 
Međutim, ustrojstvo zemljišnih registara u različitim pravnim sustavima nije jednako 
pa će blockchain tehnologija u svakome od njih imati različitu ulogu. Uvođenjem 
blockchaina u zemljišne registre nemoguće je odgovoriti na svu problematiku s 
kojom se pojedini registarski sustavi suočavaju, npr. što učiniti kada nekretninu otuđi 
osoba koja nije vlasnik, ako je pravni posao koji je temelj za stjecanje prava vlasniĹĄtva 
nekretnine ništetan ili pobojan i sl., pa će u tim će slučajevima odluku morati donijeti 
sud u parničnom ili izvanparničnom postupku.21

Prednost blockchaina, kao digitalnog registra, je i ta ĹĄto se digitalnom 
tehnologijom, razlika između sustava realnih i sustava personalnih folija može 
lako prevladati. Pri uspostavi digitalnoga registra nije nimalo teško omogućiti da se 
rezultati pretraĹživanja rangiraju i prema samim nekretninama (realne folije) ili pak po 
titularima stvarnih prava (personalne folije).22 Transakcija u blockchainu, moĹže biti 
bilo koji predmet: bitcoin transakcije predstavljaju euro, dolare ili druge kripto valute, 
dok je predmet transakcije s nekretninom pojedinačna nekretnina u koju su uključena 
i prava na njoj. Ove predmete u blockchainu  moĹžemo vizualizirati kao digitalni 
paket koji sadrĹži informacije koje su kodirane u cjelini i koje se nakon toga dodaju u 
pojedini blok u blockchainu. Pretraživanje takve baze prema osobama prikazat će sve 
nekretnine na kojima određena osoba polaže pravo vlasništva ili neko drugo pravo, 
dok će pretraga prema određenoj nekretnini pokazati tko je njezin vlasnik, odnosno 
nositelj nekog prava na njoj.23

Transakcije u blockchainu mogu uključivati sve vrste informacija, uključujući 
geografske granice ili brojeve čestica i identitet vlasnika (pisani opis svake parcele, 

19 Laurent Leloup, Blockchain - La revolution de la confiance, 79. et seq.; Marcelo Corrales, Mark 
Fenwick i Helena Haapio, Legal Tech, Smart Contracts and Blockchain (Singapore: Springer, 
2019.), 5.

20 Victoria Lemieux, „Evaluating the Use of Blockchain in Land Transactions: An Archival 
Science Perspective“, European property law journal 6 br. 3 (2017): 392-440.

21 Benjamin Verheye, Real estate publicity in a blockchain world, European property law journal 
6, br. 3 (2017), 474.

22 Verheye, Real estate publicity in a blockchain world, 455.
23 Verheye, Real estate publicity in a blockchain world, 457.



J. DEŠIĆ, K. LENAC, Je li blockchain tehnologija budućnost digitalizacije...
Zbornik Pravnog fakulteta Sveučilišta u Rijeci, vol. 41, br. 2, 609-630 (2020)614

GPS koordinate graničnih točaka i satelitske snimke, fotografije i sl.).24

U primjeni blockchain tehnologije u drĹžavnoj upravi i registrima najdalje je 
odmakla Estonija. Blockchain tehnologiju u sustav zemljiĹĄnih registara, uvela je i 
Ĺ vedska, uspjeĹĄni su projekti u tijeku u Brazilu, Dubai uvodi blockchain u cjelokupni 
sustav državne uprave, uređujući baze podataka i međusobno ih povezujući. Gruzija 
i Ukrajina također testiraju blockchain u radu zemljišnih registara, kao i pojedine 
afričke države (npr. Gana). Stoga će se u daljnjem tekstu rada detaljnije opisati 
navedeni projekti. 

5. BLOCKCHAIN TEHNOLOGIJA I ZEMLJIĹ NI REGISTAR U 
ESTONIJI

5.1. Pravni izvori zemljiĹĄnoknjiĹžnog prava 

Postupak vođenja zemljišne knjige, sastav i zemljišnoknjižni postupak regulirani 
su ponajprije Zakonom o zemljiĹĄnim knjigama. Uz njega relevantni su propisi i 
Opći dio estonskoga građanskog zakonika, Zakon o vlasništvu, Zakon o vlasništvu 
na stanovima, Zakon o obveznim odnosima, Zakon o katastru zemljiĹĄta te zakoni o 
planiranju i gradnji. Zakon o parničnom postupku utvrđuje opća pravila postupka 
upisa. Zakon o vlasniĹĄtvu definira stvarna prava, njihov sadrĹžaj, osnivanje i prestanak. 
Postupak izmjere i upisa u katastar, uključujući razmjenu podataka između katastra 
i zemljiĹĄnoknjiĹžnog odjela, propisan je Zakonom o katastru zemljiĹĄta. Organizacija 
rada zemljiĹĄnoknjiĹžnog odjela i detaljnija pravila za upis u zemljiĹĄnu knjigu propisana 
su Sudskim poslovnikom, koji donosi ministar pravosuđa.25

5.2. Sustav zemljiĹĄnih knjiga u Estoniji

Prava na nekretninama nastaju, mijenjaju se i prestaju upisom u zemljiĹĄne 
knjige.  Stvarna prava na nekretninama publiciraju se putem zemljiĹĄne knjige i nitko 
se ne moĹže pozvati na nepoznavanje podataka iz zemljiĹĄne knjige. ZemljiĹĄna knjiga 
generira sve podatke o nekretnini iz katastra zemljiĹĄta putem informacijskog sustava 
i ta dva sustava međusobno su povezana i razmjenjuju podatke. Sva se zemljišta u 
Estoniji upisuju u zemljiĹĄnu knjigu, a cjelokupni zemljiĹĄni registar dostupan je online 
i svi su dijelovi registra valjani u elektroničkom obliku. Estonija je usvojila njemački 
model zemljiĹĄnih knjiga. ZemljiĹĄne knjige vode zemljiĹĄnoknjiĹžni odjeli okruĹžnih 
(prvostupanjskih) sudova.26

24 Nir Kshetri, Blockchain-Based Property Registries May Help Lift Poor People Out of Poverty, 
pristup 12. studenog 2019., https://www.govtech.com/computing/Blockchain-Based-Property-
Registries-May-Help-Lift-Poor-People-Out-of-Poverty.html.

25 Publikacija Centra za registre i informacijske sustave Tehnički opis estonskih zemljišnih knjiga, 
Kinnistusraamatu tehniline kirjeldus, pristup 12. studenog 2019., https://www.riha.ee/api/v1/
systems/kr/files/bbc8b460-a526-c746-d91c-fc7e63a8a560. 

26 Ingmar Vali, Kadri Laud, Loori Paadik, Electronic land register which forcefully eliminates real 
estate fraud and corruption, Tallinn 2014., pristup 12. prosinca 2019.,  www.rik.ee/sites/www.
rik.ee/files/elfinder/article_files/Electronic%20land%20register%20which % 20forcefully%20



J. DEŠIĆ, K. LENAC, Je li blockchain tehnologija budućnost digitalizacije...
Zbornik Pravnog fakulteta Sveučilišta u Rijeci, vol. 41, br. 2, 609-630 (2020) 615

Zemljišnu knjigu čini: 1.) registar, 2.) zemljišnoknjižni dnevnik i 3.) 
zemljišnoknjižni spis.27 Registarski dio ima naslov i četiri dijela. U prvi se dio upisuju 
katastarski podatci: identifikacijska oznaka, površina, adresa, područje, namjena 
zemljišta, u drugi dio informacije o vlasniku, postoji li zajedničko vlasništvo i veličinu 
udjela suvlasnika (ako je riječ o suvlasništvu), treći dio obuhvaća informacije o teretima 
i ograničenjima vlasništva, dok četvrti dio obuhvaća informacije o hipotekama. 
Zemljišnoknjižni spis čine: 1.) preslika registarskog dijela i 2.) dokumentacija 
priložena uz prijedlog. U zemljišnoknjižni dnevnik (upisnik) upisuje se činjenica da 
je sudu pristigao prijedlog za upis, datum donoĹĄenja odluke o prijedlogu, datum unosa 
upisa, potpis osobe koja obavlja upis, vrijednost transakcije i drĹžavna pristojba.28

Estonski zemljišni registar uređen je po sustavu realnih folija te se pretraga 
putem interneta moĹže izvrĹĄiti jedino prema identifikatoru nekretnine. Podatci iz 
spisa, dnevnika i arhiva, odnosno detaljniji podatci o nekretnini, mogu se dobiti 
jedino ako osoba dokaĹže pravni interes ili uz pristanak vlasnika nekretnine. Usluge 
se naručuju digitalnim putem, putem javnog bilježnika ili sustava e-usluga, za što 
se plaća naknada. Korisnik se pritom mora identificirati putem osobne iskaznice ili 
internetskoga bankarstva.29

5.3. Postupak prijenosa prava vlasniĹĄtva i zemljiĹĄnoknjiĹžni postupak u 
Estoniji

Javni biljeĹžnici u Estoniji imaju ekskluzivitet kod sastavljanja isprava o 
prijenosu vlasniĹĄtva na nekretninama. Tako se ugovor o kupoprodaji nekretnine 
između prodavatelja i kupca zaključuje u obliku javnobilježničkog akta. Isprava o 
prijenosu prava vlasniĹĄtva na nekretnini koju bi sastavile stranke, a potvrdio javni 
bilježnik ništetna je. Javnobilježnički akt mora obuhvaćati sve relevantne odredbe 
i uvjete te prava i obveze ugovornih strana. Nadalje, javni biljeĹžnik osigurava da se 
prijenos vlasniĹĄtva odvija u skladu sa zakonom, i prije nego izradi akt o prijenosu 
prava vlasništva obvezan je provjeriti zemljišnoknjižno stanje.30 Time se sprječava, 
tzv. dvostruka prodaja nekretnina.

Pri sastavljanju isprava, javni je biljeĹžnik obvezan ĹĄtititi interese obje stranke, 
utvrditi jesu li ispunjene sve pretpostavke za sklapanje ugovora i njegov upis u 
zemljišne knjige, jesu li stranke sposobne sklopiti ugovor, je li nekretnina opterećena 
hipotekama ili drugim teretima i sl. Prijenos vlasniĹĄtva na nekretnini vrĹĄi se upisom 
u zemljišnu knjigu. Prijedlog za upis zemljišnoknjižnom sudu dostavlja se isključivo 
putem javnog biljeĹžnika koji je sastavio akt o prijenosu prava na nekretnini. Dostava 

eliminates%20real%20estate%20fraud%20a%20%20%20.pdf.
27 V. § 10. Zakona o zemljiťnim knjigama na  www.riigiteataja.ee/en/eli/529012015011/consolide, 

pristup 15. sječnja 2020.
28 Zakon o zemljiťnim knjigama, Republika Estonija, § 13-20.
29 Publikacija Centra za registre i informacijske sustave Tehnički opis estonskih zemljišnih knjiga, 

Kinnistusraamatu tehniline kirjeldus, pristup 12. studenog 2019., https://www.riha.ee/api/v1/
systems/kr/files/bbc8b460-a526-c746-d91c-fc7e63a8a560.

30 § 9-13. Notariaadiseadus (Zakon o javnim biljeŞnicima) od 6. prosinca 2000., pristup 21. 
travnja 2020., https://www.riigiteataja.ee/en/eli/ee/511112013002/consolide/current.



J. DEŠIĆ, K. LENAC, Je li blockchain tehnologija budućnost digitalizacije...
Zbornik Pravnog fakulteta Sveučilišta u Rijeci, vol. 41, br. 2, 609-630 (2020)616

se obavlja putem elektroničkog informacijskog sustava e-Notar. Nakon podnošenja 
prijedloga za upis, u elektroničkom se registru odmah pojavljuje oznaka koja ukazuje 
na podneseni prijedlog.31

U situacijama u kojima u financiranju kupoprodaje sudjeluje banka i ona 
neposredno komunicira s javnim biljeĹžnikom radi upisa tereta na nekretnini. 
Komunikacija javnog biljeĹžnika i zemljiĹĄnoknjiĹžnog suda od 2007. odvija se 
elektronički (putem sustava e-Notar).32 Komunikacija je potpuno elektronička u oba 
smjera, tako da javni biljeĹžnik zemljiĹĄnoknjiĹžnom sudu dostavlja prijedlog i akte o 
osnivanju, prijenosu, prestanku prava na nekretninama u obliku elektroničke isprave i 
povratno dobiva sudsko rješenje u elektroničkom obliku.33

Javni biljeĹžnik duĹžan je utvrditi identitet obje ugovorne strane i odbiti sastaviti 
akt o prijenosu prava na nekretninama ako utvrdi da jedna od stranaka nema potrebnu 
poslovnu sposobnost ili sposobnost biti punomoćnikom ili pravnim zastupnikom. 
Javni biljeĹžnik u Estoniji duĹžan je objema stranama ugovora pojasniti njegove 
učinke, čime kao neovisni stručnjak pomaže u sprječavanju nepromišljenih postupaka 
i povrede prava stranaka kod prometa nekretnina.34

Blockchain tehnologija ne moĹže zamijeniti sve funkcije koje javni biljeĹžnik 
ima u prometu nekretnina, npr. blockchain tehnologija sama po sebi ne omogućuje 
utvrđivanje je li osoba poslovno sposobna i razumije li sve posljedice i rizike povezane 
sa sklapanjem pravnoga posla. Stoga je estonsko Ministarstvo pravosuđa, još uvijek 
miĹĄljenja da nije razumno ukloniti javne biljeĹžnike kao kontrolni mehanizam kod 
sklapanja pravnih poslova povezanih s nekretninama.35

Nakon ĹĄto su dokumenti potpisani, javni biljeĹžnik dostavlja prijedlog za upis 
zemljiĹĄnoknjiĹžnom odjelu suda. Od 1. lipnja 2007. javni biljeĹžnici dostavljaju 
zemljišnoknjižnom uredu prijave za upis isključivo putem sustava e-Notar. Nakon 
potpisivanja transakcije, bilježnik prosljeđuje dokumente i prijavu za registraciju 
putem sloja sigurne razmjene podataka  X-Road, u informacijski sustav zemljiĹĄnog 
registra. Vrlo je vaĹžan redoslijed zaprimanja prijave za registraciju. Referenti 
u zemljišnoknjižnim uredima suda započinju obradu zahtjeva. Cijeli je proces 
digitaliziran i automatiziran. To znači da se u sustav ne unose dodatni podatci iz 
dokumenata, jer je njih već upisao javni bilježnik, a upis koji je nastao kao rezultat 
postupka pripremljen je u informacijskom sustavu registra nekretnina. Donesene odluke 
ili unosi dostupni su na javnom web sučelju zemljišnog registra odmah nakon što ih 
je verificirao referent. Nakon verifikacije upisa u informacijskom sustavu zemljiĹĄnog 
registra, obavijest o upisu dostavlja se strankama automatski putem e-poĹĄte. Stranke 

31 Real estate guide Estonia, pristup 5. studenog 2019., http://www.gencs.eu/uploads/VG_REG_
EE.pdf. 

32 Prema Tatjana Josipović i Hano Ernst, „Javni bilježnici i javni registri“, Zbornik Pravnog 
fakulteta u Zagrebu 59, br. 6 (2009): 1117-1152. 

33 Josipović, Ernst, Javni bilježnici i javni registri, 1128. 
34 Jelizaveta Rastorgujeva, Real estate transaction using blockchain technology, pristup 11. 

studenog 2019., https://www.njordlaw.com/njord-estonia-real-estate-transaction-using-block-
chain-technology/.

35 Rastorgujeva, Real estate transaction using blockchain technology



J. DEŠIĆ, K. LENAC, Je li blockchain tehnologija budućnost digitalizacije...
Zbornik Pravnog fakulteta Sveučilišta u Rijeci, vol. 41, br. 2, 609-630 (2020) 617

mogu pristupiti odluci putem interneta, a sustav registrira je li obavijest zaprimljena.36

Kako bi se pripremio akt, javni biljeĹžnik koristi informacijski sustav e-Notar za 
sve potrebne upite. Izvornik je potpisan na papiru, ali se u zemljiĹĄni registar dostavlja 
elektronička kopija. Svi se procesi registracije odvijaju elektroničkim putem. 
ZemljiĹĄnoknjiĹžni referent pregledava dokumente bez njihovog ispisa. Odluka se 
donosi elektroničkim putem, a ako stranke imaju elektroničku poštu, sva komunikacija 
nakon upisa u zemljišne knjige obavlja se i elektroničkim putem.37

Prijedlozi za upis rjeĹĄavaju se redoslijedom podnoĹĄenja. Odluku o upisu donose 
referenti koji su neovisni u svom radu. Referent moĹže proslijediti odluku sucu: ako 
se primjenjuje pravo druge drĹžave, ako referent Ĺželi odstupiti od prakse suca koja mu 
je poznata ili ako je prema miĹĄljenju referenta odredba koja se primjenjuje suprotna 
Ustavu.38

Registarski dijelovi i zemljišnoknjižni dnevnik čuvaju se elektronički. 
Cjelokupni postupak registracije podržava računalni program za digitalne zemljišne 
knjige. Mnoge su rutinske aktivnosti poluautomatske, što proces čini učinkovitijim. 
Tekstovi unosa automatski se sastavljaju iz predloĹžaka. Zbog toga su rokovi 
postupka smanjeni s tri mjeseca na približno deset dana, a broj tehničkih radnika 
u zemljišnoknjižnim odjelima smanjen je za oko 20 %. Zahvaljujući digitalnoj 
strukturiranoj razmjeni podataka s drugim osnovnim registrima kao ĹĄto su ZemljiĹĄni 
katastar, Trgovački registar, Registar stanovništva, javlja se manje pogrješaka i bitno 
je smanjena papirologija.39

Dokumenti koji se dostavljaju zemljišnoknjižnom odjelu elektroničkim putem 
moraju biti digitalno potpisani. Početkom 2015., zbog zahtjeva sigurnosnoga standarda 
ISKE, u zemljiĹĄnu se knjigu uvodi digitalno potpisivanje, hash chaining i vremensko 
pečaćenje upisa kako bi se osigurao integritet podataka i spriječilo neovlašteno 
mijenjanje i uniĹĄtavanje podataka.40

Zemljišna knjiga u potpunosti je elektronički registar, što znači da se podatci 
pohranjuju i obrađuju isključivo u elektroničkom obliku. U slučaju papirnatih 
dokumenata koji se ne moraju predati digitalno, izdaju se njihove ovjerene digitalne 
kopije. Ako elektronički unos nije moguć, zakon dopušta i uporabu knjižice za 
zamjenu papira, koja se mora digitalizirati što je prije moguće.41

Stranke u zemljiĹĄnoknjiĹžnom postupku primaju obavijest o odluci, a stjecatelju 

36 Vali, Laud, Paadik, Electronic land register which forcefully eliminates real estate fraud and 
corruption, 3. Pristup 10. kolovoza 2020., https://www.rik.ee/sites/www.rik.ee/files/elfinder/
article_files/Electronic%20land%20register%20which%20forcefully%20eliminates%20
real%20estate%20fraud%20a%20%20%20.pdf

37 Vali, Laud i Paadik, Electronic land register which forcefully eliminates real estate fraud and 
corruption, 4. 

38 Process of registration in Estonia, European Land Registry Association, pristup 11. prosinca 
2019. https://www.elra.eu/contact-point-contribution/estonia/process-of-registration-6/

39 Ingmar Vali, Estonian Land Register, 12. ppt. prezentacija, pristup 12. studenog 2019., https://
www.elra.eu/wp-content/uploads/2016/10/Estonian-land-registerIngmar-2011GA.ppt.

40 Vali, Laud i Paadik, Electronic land register which forcefully eliminates real estate fraud and 
corruption, 12.

41 Vali, Laud i Paadik, Electronic land register which forcefully eliminates real estate fraud and 
corruption, 4.



J. DEŠIĆ, K. LENAC, Je li blockchain tehnologija budućnost digitalizacije...
Zbornik Pravnog fakulteta Sveučilišta u Rijeci, vol. 41, br. 2, 609-630 (2020)618

prava vlasništva nakon provedenog upisa omogućuje se uvid u sve podatke i datoteke 
koje se vode vezano za nekretninu koju je stekao. Javni biljeĹžnik koji je ovjerio ugovor 
također prima obavijest o upisu. Razmjena podataka među različitim registrima u 
državi odvija se putem sigurnoga sloja za razmjenu podataka X-Road, koji omogućuje 
provjeru ispravnosti podataka i činjenica u stvarnom vremenu. Ako se podatci traže 
putem X-Roada, nema potrebe za dostavljanjem dodatnih dokaza (potvrda i sl.). 
X-Road je pokrenut 2001. kao tehničko i organizacijsko okruženje koje omogućuje 
digitalnu i sigurnu razmjenu podataka između državnih informacijskih sustava.42

Sustav elektroničke obrade predmeta onemogućuje povredu reda prvenstva 
upisa. Naime, od 1. lipnja 2007. javni su biljeĹžnici obvezni podnijeti sve prijave 
za registraciju elektroničkim putem, a od 1. lipnja 2011. dodjela predmeta 
zemljišnoknjižnim referentima je automatska i predmeti se obrađuju isključivo prema 
redoslijedu zaprimanja. Sve naknadne promjene u nalogu za obradu mogu se pratiti 
u informacijskom sustavu, a samo voditelj zemljiĹĄnoknjiĹžnog odjela moĹže dodijeliti 
predmet drugom referentu. Time sustav osigurava transparentnost i sprječava 
zloupotrebe.43

Estonskoj zemljiĹĄnoj knjizi (svim dokumentima i datotekama) moĹže se 
pristupiti isključivo putem interneta, za što se plaća naknada. Svatko tko želi pristupiti 
zemljišnoknjižnoj datoteci mora dokazati pravni interes da to učini.44 Jedini koji nisu 
duĹžni navesti razlog za pretragu datoteka su vlasnici nekretnina, javni biljeĹžnici, 
sudovi i druga tijela vlasti. Vlasnici mogu ovlastiti pojedine osobe (npr. buduće 
kupce) da pretražuju određenu zemljišnoknjižnu dokumentaciju. Dokumenti se 
mogu pregledavati uz provjeru elektroničkog id";"""date"",""2020-09-24T08:34:06Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.4""
""xmp:CreatorTool"",""Adobe InDesign CS6 (Windows)""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dcterms:created"",""2020-09-24T08:34:05Z""
""language"",""hr""
""Last-Modified"",""2020-09-24T08:34:06Z""
""dcterms:modified"",""2020-09-24T08:34:06Z""
""dc:format"",""application/pdf; version=1.4""
""xmpMM:DocumentID"",""xmp.id:CC6CF0A940FEEA11BE87AE60768F6F0B""
""Last-Save-Date"",""2020-09-24T08:34:06Z""
""pdf:docinfo:creator_tool"",""Adobe InDesign CS6 (Windows)""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2020-09-24T08:34:06Z""
""meta:save-date"",""2020-09-24T08:34:06Z""
""pdf:encrypted"",""false""
""xmp:CreateDate"",""2020-09-24T10:34:05Z""
""modified"",""2020-09-24T08:34:06Z""
""Content-Length"",""419761""
""pdf:hasMarkedContent"",""true""
""Content-Type"",""application/pdf""
""xmp:ModifyDate"",""2020-09-24T10:34:06Z""
""xmp:MetadataDate"",""2020-09-24T10:34:06Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""pdf:producer"",""Adobe PDF Library 10.0.1""
""trapped"",""False""
""meta:creation-date"",""2020-09-24T08:34:05Z""
""created"",""2020-09-24T08:34:05Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""22""
""Creation-Date"",""2020-09-24T08:34:05Z""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""2484"",""3316"",""3346"",""3407"",""3421"",""3141"",""3453"",""3440"",""3579"",""3271"",""3531"",""3450"",""2923"",""3484"",""3477"",""3275"",""3281"",""3324"",""3464"",""3173"",""2282"",""1682""
""access_permission:extract_content"",""true""
""xmpMM:DerivedFrom:DocumentID"",""xmp.did:BE11CB148DF6EA11B890FB8295BDA1B0""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""xmpMM:DerivedFrom:InstanceID"",""xmp.iid:61B08A0C3EFEEA11BE87AE60768F6F0B""
""producer"",""Adobe PDF Library 10.0.1""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""Adobe PDF Library 10.0.1""
""pdf:docinfo:created"",""2020-09-24T08:34:05Z""
";https://scholar.google.ch/scholar?start=590&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098791-167;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Challenges and emerging solutions for public blockchains;V Holotescu, R Vasiu ; … . Broad Research in Artificial Intelligence and …, 2020  brain.edusoft.ro;;"… to fix the problems of Bitcoin and Ethereum, along with other DLTs (The Crypto Oracle, 2019 … for

improving inter alia, the scalability, in exchange for the security the blockchain can offer … This

process will cut out the single point of failure from today?s cryptocurrency exchanges and …";Cité 7 fois;Les 10 versions;[PDF] edusoft.ro;https://brain.edusoft.ro/index.php/brain/article/download/990/1157;"
BRAIN. Broad Research in Artificial Intelligence and Neuroscience 
ISSN: 2068-0473  |  e-ISSN: 2067-3957 
Covered in: PubMed.gov; IndexCopernicus; The Linguist List; Google Academic; Ulrichs; getCITED; Genamics 

JournalSeek; J-Gate; SHERPA/RoMEO; Dayang Journal System; Public Knowledge Project; BIUM; NewJour; 

ArticleReach Direct; Link+; CSB; CiteSeerX; Socolar; KVK; WorldCat; CrossRef; Ideas RePeC; Econpapers; Socionet. 

 

2020, Volume 11, Issue 1, pages: 58-83 | https://doi.org/10.18662/brain/11.1/15  

 

Challenges and 
Emerging Solutions 
for Public 
Blockchains 

Victor HOLOTESCUš,  
Radu VASIU2 

1 Politehnica University of Timisoara, 
Romania, victor.holotescu@yahoo.ro  

2 Politehnica University of Timisoara, 
Romania, radu.vasiu@cm.upt.ro  

 

Abstract: With the interest and attention that the Blockchain and the 
Distributed Ledger Technologies (DLTs) have recently demanded, the 
technology is advancing at a very high rate. With investors and 
applications in a wide variety of fields, a lot of funding and efforts are 
being driven into bringing the technology to everyday use. The community 
and companies are coming up with new ways to collaborate, which makes 
the blockchain ecosystem evolve at full tilt. Consequently, this paper’s aim 
is to review the academic and grey literature and to provide readers with 
information about the evolution, benefits and challenges of the Public 
Distributed Ledger Technologies and to discuss the latest solutions, which 
are being developed for bringing decentralization closer to the mainstream. 
The paper reviews the Directed Acyclic Graph (DAG) structured 
distributed ledgers with focus on the Hedera Hashgraph, a novelty DLT 
bringing a unique consensus algorithm with new use-cases enabled by new 
cryptoeconomic mechanisms, as well as vital services, such as Solidity 
smart contracts and distributed file storage. Then, we are going to explore 
second-layer network protocols, a major topic for solving scalability issues 
and for decentralizing cryptocurrency exchanges. The article tries also to 
identify the particularities of these technologies and how they bring specific 
answers to the blockchain trilemma, consisting in three themes - 
scalability, interoperability and sustainability. 
 

Keywords: Blockchain; distributed ledger technology; blockchain 
trilemma; scalability; interoperability; sustainability. 
 
How to cite: Holotescu, V., & Vasiu, R. (2020). Challenges 
and Emerging Solutions for Public Blockchains. BRAIN. 
Broad Research in Artificial Intelligence and Neuroscience, 11(1), 58-
83. https://doi.org/10.18662/brain/11.1/15  

https://doi.org/10.18662/brain/11.1/15
mailto:victor.holotescu@yahoo.ro
mailto:radu.vasiu@cm.upt.ro
https://doi.org/10.18662/brain/11.1/15


BRAIN. Broad Research in                                                                    March, 2020 
Artificial Intelligence and Neuroscience                                      Volume 11, Issue 1 

 

59 

1. Introduction 

Since Satoshi Nakamoto published the paper about Bitcoin 
(Nakamoto, 2008), a trustless peer-to-peer network, in 2008, and since he 
has turned on the blockchain by mining the genesis block one year later, the 
technology has proven to stand out, making it possible to disrupt the future 
of many fields. The blockchain benefits brought by its distributed, 
transparent and immutable nature make possible use cases from Finance, 
Banking, Business and Supply Chain to Education, Media and Health 
(Deshpande et al., 2017; Chaum et al., 2000). 

During this period, blockchain projects have been very well funded, 
with $22.5B in Initial Coin Offerings (ICOs) by the end of 2018 (CoinDesk, 
2019), which have been proven to have a high risk of participation, with 
many international initiatives meant to accelerate the adoption and 
awareness of Distributed Ledger Technology and Digital Currency (O„Brien, 
2019; Virmani, 2018; MIT Digital Currency Initiative, 2020; EUBlockchain, 
2020) and with trusted launchpads for funding new promising blockchain 
solutions through Initial Exchange Offerings (IEOs). With all the attention 
that blockchain technology has received, it still hasn‟t overcome its biggest 
hurdles in order to be ready for mass adoption, making its shortcoming 
widely debated, resulting in new solutions to be developed and explored. 

In this paper, we are going to introduce the blockchain technology, 
talking about its history and know-abouts. The first subject to be discussed 
is related to the limitations of public blockchain technologies and why trying 
to improve on any of the characteristics of scalability, interoperability and 
sustainability, referred to as the blockchain trilemma, will affect the true 
value and the benefits of the blockchain (Ometoruwa, 2018). The next topic 
examined will be the Directed Acyclic Graphs (DAGs), an alternative 
structure for blockchain, where we are aiming to introduce and provide 
insights on the different solutions using this kind of DLT, concentrating on 
Hedera Hashgraph, a unique patented network, which has to offer the whole 
set of decentralized services and new cryptoeconomic mechanisms, that 
bring a new level of fairness, speed and security to the decentralized space. 
Ultimately, the paper will review the second-layer networks aiming to scale 
blockchains, exploring upon others the Lightning Network. This is an off-
chain protocol, starting as a Bitcoin Improvement Proposal (BIP) (Croman 
et al., 2016) which is implemented by using Hash Timelock Contracts 
(HTLC) and which can be extended on blockchains with time-locks and 
multi-sig capabilities, providing interoperability solutions as well. 



Challenges and Emerging Solutions for Public Blockchains 
Victor HOLOTESCU, Radu VASIU 

 

60 

Throughout the paper we are going to see the types of Decentralized 
Applications (DApps) that are being developed on Hedera Hashgraph and 
the Lightning Applications (LApps) built on the Lightning Network. By the 
end, we are going to identify the next steps for moving forward with the 
technology, finishing up with the conclusions raised throughout the paper. 

The paper is a literature review realized by analyzing academic 
journals, conference papers and grey literature (online articles, videos, 
newsletters, forums, e-mail archives, etc.) with the aim of encompassing the 
decentralized ecosystem, from the formal academic perspective and also 
from the more approachable means where the blockchain has its roots.  

2. Concepts 

2.1. Definitions 

There are many ways in which the Distributed Ledger Technologies 
(DLTs) and the Blockchain have been defined, so as to suit different levels 
of knowledge and understanding and also to better encapsulate the essence 
of technology and its capabilities. 

A concept existing from 1982, Distributed Ledger Technology 
(DLT) designates multi-party systems being able to withstand environmental 
adversaries, meaning that the network of independent participants can 
continue to work correctly with no central operator or authority, despite 
unreliable or malicious parties (Rauchs et al., 2018). 

The Blockchain is a type of DLT, an append-only chain-like data 
structure, made out of signed and timestamped blocks that contain the 
transactions. Nodes called miners are participating in a consensus 
mechanism, and are responsible for validating transactions, with which new 
blocks are created. A transaction may involve the transfer of tangible or 
digital assets, or the completion of a task. Blocks are identified through a 
cryptographic hash, each of them containing its own hash and the hash of 
the previous block, creating the chronologically ordered blockchain structure 
(Casino et al., 2019). 

The Distributed Ledger Technologies create a robust, auditable, 
secured and efficient environment, while establishing the self-sovereignty 
and eliminating the third party control (Dabbagh et al., 2019).  

2.2. History 

The blockchain technology came to life by bringing together 
technologies that have been proposed and published in different papers over 
the last 40 years. During the 1980s, David Chaum defined blind signatures 



BRAIN. Broad Research in                                                                    March, 2020 
Artificial Intelligence and Neuroscience                                      Volume 11, Issue 1 

 

61 

(Chaum, 1983) and the first electronic cash protocol (Chaum et al., 2000) 
which solved the anonymity and double spending problem in a centralized 
matter. In 1997, Adam Back introduced Hashcash (Nakamoto, 2008), where, 
as a security measure for sending spam mail, the attackers had to solve a 
computational puzzle that was easy to verify, but hard to generate. This is 
the main concept of the Proof-of-Work protocol, which was first proposed 
by Wei Dai, when he discussed B-money (Dai, 1998). The mechanism he 
described was lacking node interaction in the consensus and security. Nick 
Szabo (2008), with his proposals on Bit gold, improved the mechanisms‟ 
security by adding the difficulty of the computational puzzle to be solved. 

In 1999, Tomas Sander and Amnon Ta-Shma (Sander & Ta-Shma, 
1999) brought the Merkle tree structures and Zero-Knowledge Proofs, while 
in 2004 Hal Finney (Chohan, 2017) defined what he called the Reusable-
Proof-of-Work (RPOW) consensus mechanism by incorporating Hashcash. 
What the whole infrastructure was missing from what we know today as 
blockchain is the peer-to-peer network, the last piece of the puzzle, which 
was added by a person with the alias Satoshi Nakamoto, in the form of 
Bitcoin, the peer-to-peer electronic-cash system (Nakamoto, 2008). 

2.3. Blockchain Types 

The Blockchain has evolved into different categories, each of them 
having its benefits and downsides.  

Private or consortium blockchains are those in which the nodes 
maintaining the ledger are permissioned to participate in the consensus, 
either by being centralized inside the entity running the blockchain or by 
going through Know Your Customer (KYC) and Anti-Money Laundering 
(AML) processes. Thus these blockchains are semi or fully centralized and 
are useful for auditability. Private and consortium blockchains have 
restricted access, with fewer and known upfront nodes participating in the 
consensus, these protocols for closed sets being faster than those for open 
networks. At the same time, being in a closed environment, some private 
blockchains will have issues interoperating with other networks, so the 
benefits are minimal (Lyons et al., 2018). 

Another type of blockchain are the public permissionless 
blockchains, which are run by thousands of nodes, anyone being able to set 
up a node and start participating in the consensus process. While it is likely 
for bad actors to join in, it is practically impossible for them to take over 
these blockchains, as that would require a huge financial investment. That is 
why public blockchains are considered to be tamper-proof (Deshpande et 
al., 2017). Bitcoin or Ethereum are the best-known blockchains in these 



Challenges and Emerging Solutions for Public Blockchains 
Victor HOLOTESCU, Radu VASIU 

 

62 

category, examples of public blockchains being mainly discussed in the 
paper. 

Hybrid (or federated) blockchains started to be developed as they 
can integrate the security of the public blockchains with the privacy and 
speeds of the private or consortium blockchains (Casino et al., 2019). 

2.4. Consensus mechanisms 

The blockchain is run by a consensus protocol meant to solve the 
Byzantine Generals Problem (Lamport et al., 1982), where nodes need to 
make the right decision, given that there might be malicious actors 
participating in the process. Nodes are incentivized to run these consensus 
mechanisms, being rewarded whenever they validate the transactions and 
add a new block, while also being heavily penalized whenever they try to add 
an invalid transaction to the blockchain. With all the mechanisms set into 
place, the consensus protocol is the main point of failure of a blockchain, as 
its failure compromises the ledger. 

There are multiple types of protocols which have been developed to 
run in different scenarios for public and private blockchains and also for 
other types of DLTs. The ones used successfully by the major public 
blockchains are Proof-of-Work, Proof-of-Stake and Delegated-Proof-of-
Stake(Casino et al., 2019). 

Proof-of-Work (PoW) is the consensus mechanism which runs on 
Bitcoin and Ethereum, with different implementations called Hashcash and 
Ethash respectively. This protocol has proven to be the best solution for 
solving the Byzantine Generals Problem, making it the most secure 
consensus mechanism. 

The nodes, called miners, participating in the consensus have to 
solve a computational problem of a certain difficulty. Whichever miner 
solves the computational problem first will add the next block to the 
blockchain. The computational problem refers to the generation of the hash 
identifier of a block, where the difficulty dictates the condition under which 
the hash is valid. Regularly, this means the hash has to be lower than a 
certain number and, thus, be preceded by a certain number of zeros. When 
the block is added to the blockchain and broadcasted to the network, the 
node that solved the problem is creating a new transaction, which transfers 
the mining reward to its address (Baliga, 2017). 

In order to gain control over a blockchain maintained with a PoW 
consensus mechanism, a malicious attacker has to take over more than half 
of the nodes participating, in a 51% attack, thus making the PoW the most 
secure consensus protocol ever developed. 



BRAIN. Broad Research in                                                                    March, 2020 
Artificial Intelligence and Neuroscience                                      Volume 11, Issue 1 

 

63 

Proof-of-Stake (PoS) has been developed as a solution for the high 
volume of energy consumed in the process of PoW and it is based on nodes 
proving ownership over their tokens to generate blocks. The most common 
practice for PoS is for the system to choose a random leader, based on its 
stake in the network, which creates the block. The mechanism works 
because having more currency makes it less likely for a node to be malicious. 
All malicious nodes trying to alter the state of the blockchain are penalized 
by having their tokens taken.  

Delegated-Proof-of-Stake is the protocol used by EOS, Steem, 
Bitshares, Ark or Lisk, the first two blockchains having lately become very 
popular for building decentralized applications.  Blocks are created by block 
producers and validated by block validators. Block producers are elected 
every round by the nodes inside the network, based on their stakes. While 
block producers can also fine-tune their block creation intervals and the 
block size, having a smaller pool of block producers allows a higher 
transaction throughput, while it is considered to be more centralized 
compared to the other consensus mechanisms (Konstantopoulos, 2018). 

Nowadays people are using Distributed Ledger Technology and 
Blockchain interchangeably even if DLTs represent different technologies, 
one of which is the Blockchain. 

Although the two technologies are solving the same problem and 
trying to bring the same amount of benefits, of providing decentralization by 
potentially reducing the most important regulatory role of being a 
middleman in our society (Dabbagh et al., 2019), the term of DLT has 
started to gain more popularity because of the new technologies developed 
for overcoming the limitations of Blockchain. We will present these 
technologies in the section on the Directed Acyclic Graph (DAG), where we 
are going to discuss the unique Hashgraph algorithm developed at Swirlds.  

3. Challenges 

With blockchain becoming so popular, and with everybody trying to 
build the decentralized applications which will turn the technology 
mainstream, there are still many challenges for public blockchains, aside 
from the fact that the blockchain should be integrated in the current legacy 
centralized system. The challenges of the public blockchains are related to 
Scalability, Interoperability and Sustainability, coined in 2018 as the 
blockchain trilemma by Vitalik Buterin, the creator of Ethereum, referring to 
the difficulty of creating a blockchain with the three characteristics at the 
same time (Ethereum, 2018). Currently, there is no fully working blockchain 



Challenges and Emerging Solutions for Public Blockchains 
Victor HOLOTESCU, Radu VASIU 

 

64 

to have solved all these issues and it is considered that you can only address 
two of them by giving up the other one (Lyons et al., 2019). That is why 
multiple blockchain platforms exist: to offer the best possible solutions for 
specific use-cases. In what follows, we are going to talk about these three 
challenges, while later on we are going to see possible solutions to them.  

3.1. Scalability 

A public blockchain should respond to the critical challenge of 
scalability, which means to achieve the consensus of the distributed 
computing nodes in a scalable and efficient manner. 

In the blockchain, all the nodes are involved in creating blocks that 
can be added to the ledger and they decide whatever unconfirmed 
transactions they want to include in the block they are working on. The node 
which calculates the first valid hash in PoW or the declared leader in PoS or 
other consensus mechanisms is going to forge the new block and then the 
block needs to be broadcasted to the whole network. A new block of 1MB 
for Bitcoin is propagated every 10 minutes, giving it a throughput of 7 
transactions per second (tps), while Ethereum can confirm 20 tps (Lyons et 
al., 2019).  

Small adjustments have been brought to the blockchain in order to 
address scalability issues, such as increasing the block size of Bitcoin, which 
is 1MB, to 4 or 8MB. A hard fork in the main Bitcoin blockchain has been 
created, called Bitcoin Cash, having an 8MB block (Bashir, 2018). While this 
adjustment can increase the number of transactions that can be stored on a 
block, the block will take longer to propagate in the network, as nodes 
require better internet connection with larger bandwidth.  

In the case of maintaining the size of the blocks, transactions with 
higher fees are validated faster, as miners have the ability to choose the 
transactions they want to mine, in order to gain higher rewards. This will 
unfairly cause the neglect of low fee value transactions, as the blockchain 
might not follow a first come first served rule. A solution for scalability is 
the SegWit (Segregated Witnesses), another fork in the Bitcoin, which 
eliminates different signatures from the blocks, thus allowing the addition of 
more transactions (Bashir, 2018). 

To gain a better performance in scaling the blockchain, research has 
been conducted to address the problem by creating new data structures, 
such as Directed Acyclic Graphs (DAGs), or more efficient consensus 
algorithms, or to move transactions and computations from the blockchain 
to a second-layer protocol. 



BRAIN. Broad Research in                                                                    March, 2020 
Artificial Intelligence and Neuroscience                                      Volume 11, Issue 1 

 

65 

While looking for solutions for replacing the computation puzzles in 
PoW with more useful ones, many blockchains are trying to replace PoW 
with PoS, or to integrate PoS with PoW. The Ethereum team has been 
talking about replacing PoW with PoS since 2014, and wanted to replace 
Ethash with Casper protocol, which we currently see integrated in Ethereum 
2.0 (Serenity), an early version of Ethereum, built from scratch, using the 
PoS. For this new version of Ethereum, Vitalik Buterin states that it will 
validate transactions with 1% of the energy consumed by PoW (Zamfir, 
2016).  

3.2. Interoperability 

With the persisting problems of scalability and the variety of 
approaches to solve them, the market has got up to more than 2700 
cryptocurrencies in September 2019 (CoinLore, 2019). The problem raised is 
that, with so many different implementations, and with many of them 
having their own adopters, blockchains will have to be able to share 
information with each other. This means that transactions could span 
multiple blockchains and information on a blockchain could be retrieved 
and validated through a transaction on another blockchain (Yaga et al., 
2018). In Hardjono et al. (2018), Hardjono et al. talks about what 
blockchains should look like in order to achieve interoperability, referring to 
the main goals of the Internet architecture and how they should be applied 
on the blockchain. One of the examples built with the Internet architecture 
goals premise is MIT Tradecoin. Another project proposes the Digital Trade 
Coin (Lipton et al., 2018), a cryptocurrency to replace cash money with a 
worldwide stable digital token, serving as a “blueprint” for an 
interoperability model between blockchains. 

3.3. Sustainability 

Sustainability refers to the ability of public blockchains to remain a 
viable solution over time. A blockchain has to be environmentally friendly, 
efficient, while its entities should be able to govern over the blockchain in a 
decentralized manner, in order to take actions in case unlawful acts are being 
committed (Lyons et al., 2019). 

As blockchains are mostly open-source and maintained by 
communities of programmers and advisors, in order to be successful and 
sustainable, Decentralized Autonomous Organizations (DAOs) or 
Decentralized Organizations (DOs) can integrate the ways in which a 
blockchain should be maintained and governed, keeping the blockchain up-
to-date, secured and running for the good of the system.  



Challenges and Emerging Solutions for Public Blockchains 
Victor HOLOTESCU, Radu VASIU 

 

66 

Many of the current blockchain projects are implemented by 
companies and corporations that make the decentralized public blockchain 
mostly centralized, due to the fact that these companies are deciding the 
roadmaps of the implementations. 

Blockchain protocols are actively improved and nodes have always 
been incentivized to participate in the consensus, but the community and 
developers have been trying to find ways to improve the system in their own 
time. New business rules need to be applied to decentralize companies and 
corporations and also to govern a blockchain like Bitcoin, to reward the 
individuals proposing enhancements and developing them towards 
improving the system. A DAO can dictate the economy that incentivizes 
community participation, which can speed up the implementation of new 
technology. 

Even if many blockchains are better than Bitcoin in some ways, 
besides not being the first coin to have ever come out, they are not 
community-driven and thus, despite the decentralized technology they have 
to offer, they still remain somehow centralized. 

Nodes have to keep the ledger with the full history of the 
transactions. In Ethereum, nodes are holding smart contracts data, and 
smart contracts transactions need to be run by every node in the network. In 
September 2019, the size of the Bitcoin ledger was 240GB (Blockchain, 
n.d.), while the Ethereum full-history ledger was 3.1TB (Etherscan, n.d.).  

On top of this, Bitcoin has proven since its appearance that PoW 
works best in achieving consensus, even if it wastes a lot of energy. With 
that being said, at the moment of writing this paper, there are four mining 
companies which make a majority in the consensus of Bitcoin (Blockchain, 
n.d.), and the only way is to become more centralized. 

Another downside of the PoW protocol is that a lot of energy is 
wasted. Bitcoin has an estimated annual consumption of 54.6TWh 
(Digiconomist, n.d.), it consumes more energy than countries such as 
Romania or Bangladesh. At the same time, the profit of miners is well 
beyond $1B. 

This shows that current consensus mechanism implementations are 
causing big sustainability issues. Eventually, if we envisage a long-lasting life 
for blockchains, and a better behavior than Visa which has 24000tps (Raul, 
2018), keeping a copy of the whole blockchain on each node might not be 
the best solution, as Bitcoin‟s ledger is gaining 50GB per year. If this 
technology will be used by people, this number will only increase. Solutions 
have been proposed, such as MimbleWimble by Tom Elvis Jedusor 
(Jedusor, 2016), which can be built on top of Bitcoin and, besides the extra 



BRAIN. Broad Research in                                                                    March, 2020 
Artificial Intelligence and Neuroscience                                      Volume 11, Issue 1 

 

67 

privacy of the account balances, it doesn‟t maintain the whole blockchain 
history; therefore, the implementation would reduce the size of the ledger 
from 80GB, the size of Bitcoin in 2016, to 30GB. There are currently 2 
separate implementations that build a new blockchain based on 
MimbleWimble: Grin, community driven, and Beam, which is financed and 
run by a company (Wheeler, 2019). Other implementations involve 
lightweight clients, where old transactions are removed from the ledger and 
nodes hold reference only to non-empty addresses (Zheng et al., 2017). In 
the next section we are going to talk about how DAGs and Hedera 
Hashgraph have addressed this problem, and why DAGs might be superior 
and the best choice for moving forward. 

4. Solutions to overcome blockchain trilemma 

4.1. Directed Acyclic Graphs 

Directed Acyclic Graphs, also known as DAGs, are a type of DLT 
meant to solve the trilemma issues of the blockchain. A DAG is a structure 
composed of vertices and edges that grows in only one direction, edges not 
referencing previous ones, thus being acyclic El Ioini & Pahl, 2018). A type 
of DAG in a technical scenario is a git repository, where new branches or 
merges can be made, this way creating an acyclic graph.  

DAGs can accommodate new consensus mechanisms, other than 
the ones we can find in the blockchain, which can equally lead to solving the 
energy consumption problem of PoW.  

There are already some implementations of DAGs in an 
experimental state, as they didn‟t have the time to prove their security. The 
most known implementation is the Tangle (Popov, 2015) developed by 
IOTA, which is designed to overcome the scalability of blockchains and acts 
as a great candidate for IoT applications. Each node making a transaction or 
a so-called site, needs to validate two other transactions, called tips, which 
haven‟t been confirmed yet. IOTA is a lightweight solution, as nodes do not 
need to have a full copy of the ledger. On top of this, the more transactions 
made on the IOTA protocol, the faster the confirmations are. Bramas (2018) 
proposes a model to analyze the scalability and security of the Tangle, 
suggesting that double spending transactions can be done on the DAG, with 
more hashing power by the byzantine node. Moreover, the model talks 
about the coordinator node which is part of the current IOTA 
implementations. Without the coordinator node, since nodes can validate 
transactions only by knowing a part of the ledger, called a sub-DAG, a 



Challenges and Emerging Solutions for Public Blockchains 
Victor HOLOTESCU, Radu VASIU 

 

68 

byzantine node can create a sub-DAG that is afterwards accepted in the 
main DAG and validated by others.  

Another implementation is Byteball (Churyumov, 2016), a DAG 
which emphasizes 12 witnesses, represented by trusted companies selected 
by users. Witnesses have to consistently make transactions on the so-called 
Main Chain, where they post units sequentially. The token is called byte, and 
a byte is equal to 1 byte of permanent storage on the DAG. 

Holochain (Holochain, n.d.) is another solution to replace 
blockchains, where different nodes, called agents, hold the state of their own 
transactions in a personal ledger and at the same time broadcast them 
through a Distributed Hash Table (DHT) to its neighbors. It is made of 
multiple shards of DHT, so whenever your agent is offline, other agents may 
retrieve the transactions you have made through the DHT, similar to 
BitTorrent. Agents run the so-called DNA, a file containing the validations 
rules; whenever a new transaction shows up in the DHT, the agents can 
validate the transaction through their DNA; if the results do not match, the 
transaction will be shared with the network as being malicious. Holochain is 
a framework for building decentralized applications and also blockchains, by 
changing the DNA. Like the other solutions, Holochain is lightweight and 
can also run on mobile devices. 

It is a common assumption that DAGs rely on the fact that, with 
time, the value of the DLT will increase, in which point the network will 
become tamper-proof, meaning that a node needs an unrealistic amount of 
value and hashing power to tamper the structure. At this point, the 
mechanisms put into place by this implementation at the early stage can be 
removed, making the system work independently without being centralized. 
IOTA proposes to eliminate the coordinator node in the future and Hedera 
Hashgraph, the DLT addressed in the following section, also has some 
limitations which will be removed with time. 

4.2. Hedera Hashgraph 

Hedera Hashgraph is designed by Leemon Baird and is an efficient 
consensus mechanism that makes transactions reach finality very fast, while 
keeping the time and order of transactions fair, with no security tradeoffs 
(Baird, 2016). The patented algorithm is the first Asynchronous Byzantine 
Fault Tolerant consensus mechanism, designed and delivered by Swirlds, 
Inc. and it has been mathematically proven through Coq, a proof 
management system developed at INRIA (The Coq Proof Assistant, n.d.). 

The system is a DAG running a Proof-of-Stake consensus 
mechanism, where nodes are gossiping events to each other, during rounds, 



BRAIN. Broad Research in                                                                    March, 2020 
Artificial Intelligence and Neuroscience                                      Volume 11, Issue 1 

 

69 

at the end of which virtual voting is done to validate the transactions. The 
network runs a so-called gossip-about-gossip with virtual voting algorithm, 
that allows every member of the network to be part of the consensus 
through proxy staking. 

Hedera provides services such as cryptocurrency, smart contracts 
written in Solidity and a file storage, where files of any size can be appended 
to the ledger. 

By gossiping events to each other, every node will find out what the 
other node know. Nodes hold an image of the same hashgraph history, 
containing all the confirmed events and transactions, while also knowing 
which events have been gossiped, to whom and when. By gossiping events 
to another node, the same transaction will be doubled and contained in 
another event of another node. When the virtual voting round is over and 
transactions are confirmed, the time of the transactions, the consensus 
timestamp, will be defined not by the average timestamp, but by the 
timestamp situated in the middle of the whole timestamp list for a specific 
transaction. In this way, Hedera Hashgraph assures a fair timestamp 
ordering of the transactions. 

Timestamps are given by the clock on each computer running the 
nodes, which assures that if more than two thirds of the network have 
reliable clocks, the ordering of the transactions is fair. 

In Figure 1, each circle is an event, containing the digital signature of 
the node that has created it, transactions, the consensus timestamp when the 
event was created, the hash of the node‟s previous event and the hash of the 
received event. 

To explain how the Hashgraph works, witnesses are the first event 
of a node in a round, and a new round starts whenever witnesses are seen by 
a majority of the nodes. A witness is famous whenever more than a third of 
the nodes have received this event at the start of the next round. Figure 1 
shows a sequence of rounds in which D2 is decided as a famous witness by 
A4, meaning that every previous event, tracing back from D2, will reach 
finality. D2 can be seen by A3 through the previous Alpha event and the 
event which was gossiped by Delta. By B3, D2 is seen through Bravo‟s 
previous eve";"""date"",""2020-03-16T06:49:03Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.4""
""xmp:CreatorTool"",""MicrosoftÂŽ Word 2010""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""pdfa:PDFVersion"",""A-1b""
""language"",""en""
""dcterms:created"",""2020-03-16T06:48:50Z""
""dc:format"",""application/pdf; version=""""A-1b"""""",""application/pdf; version=1.4""
""Last-Modified"",""2020-03-16T06:49:03Z""
""dcterms:modified"",""2020-03-16T06:49:03Z""
""xmpMM:DocumentID"",""FD86DCF9-A548-4793-A93F-560E9C4C8F65""
""Last-Save-Date"",""2020-03-16T06:49:03Z""
""pdf:docinfo:creator_tool"",""MicrosoftÂŽ Word 2010""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2020-03-16T06:49:03Z""
""meta:save-date"",""2020-03-16T06:49:03Z""
""pdf:encrypted"",""false""
""xmp:CreateDate"",""2020-03-16T08:48:50Z""
""modified"",""2020-03-16T06:49:03Z""
""Content-Length"",""537256""
""pdf:hasMarkedContent"",""true""
""Content-Type"",""application/pdf""
""xmp:ModifyDate"",""2020-03-16T08:48:50Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""pdfaid:conformance"",""B""
""dc:language"",""ro-RO""
""pdf:producer"",""MicrosoftÂŽ Word 2010""
""meta:creation-date"",""2020-03-16T06:48:50Z""
""created"",""2020-03-16T06:48:50Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""26""
""Creation-Date"",""2020-03-16T06:48:50Z""
""resourceName"",""1157""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""2578"",""2878"",""2448"",""2881"",""2584"",""2802"",""2634"",""2661"",""2717"",""2689"",""2707"",""2808"",""1062"",""2607"",""2801"",""2707"",""2644"",""2826"",""2724"",""1927"",""2187"",""2403"",""2646"",""2743"",""2636"",""2713""
""access_permission:extract_content"",""true""
""pdfaid:part"",""1""
""access_permission:can_print"",""true""
""producer"",""MicrosoftÂŽ Word 2010""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""MicrosoftÂŽ Word 2010""
""pdf:docinfo:created"",""2020-03-16T06:48:50Z""
";https://scholar.google.ch/scholar?start=710&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098720-8;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Are managers ready for HRM 4.0?: the potential role of blockchain technology in HRM;AU Constantinide ;2020 repositorio.iscteiul.pt;;"… Crypto-currencies, but BT is the technology that assures security, confidentiality and the … nowadays,

I aim going to show the evolution of these terms and how blockchain will be in benefit for them …

Ethereum cryptocurrency was the landmark for smart contracts (Zain et al., 2019) …";;;[PDF] iscte-iul.pt;https://repositorio.iscte-iul.pt/bitstream/10071/21426/1/master_alexandra_ulrica_constantinide.pdf;"
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

ARE MANAGERS READY FOR HRM 4.0? THE POTENTIAL ROLE OF 
BLOCKCHAIN TECHNOLOGY IN HRM 

 
 
 
 
 

Alexandra Ulrica Constantinide 
 
 
 
 
 

Master in Human Resources Management and Organizational Consulting 
 
 
 
 
 

Supervisor: 
Dr. Aristides Ferreira, Associate Professor,  
ISCTE Business School 
 

  
 
 
 
 
 
 
 
 

 

 
 
 
November, 2020





 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

 
Department of Human Resources and Organizational Behavior 

 
 
 
 
 

ARE MANAGERS READY FOR HRM 4.0? THE POTENTIAL ROLE OF 
BLOCKCHAIN TECHNOLOGY IN HRM 

 
 
 
 
 
 

Alexandra Ulrica Constantinide 
 
 
 
 
 

Master in Human Resources Management and Organizational Consulting 
 
 
 
 
 

Supervisor: 
Dr. Aristides Ferreira, Associate Professor, 
ISCTE Business School 
 
 

  
 
 
 
 
 
 
 

November, 2020





 

i 

 

 

Acknowledgements  
I would like to dedicate this paper to my family and friends. Special thanks to Grazi and Elena 

whose help got me through this. Lastly, I would like to thank two people who help me at the 

end, Romana and Adamantini. 



ii 

 

 Abstract  
 

As most professions, the field of Human Resources, henceforth HR, has changed 

considerably over time. To the best of my knowledge, no previous research has been made 

about the effects of blockchain technology into the HR field, from the perspective of ethics. 

This research will therefore aim to contribute to the existing literature about blockchain 

technology and HR by exploring whether managers are ready for new technological 

implementations, along with a broad matter of ethics behind the implementation.  

A qualitative and exploratory research design using semi-structured interviews was 

adopted in order to gain more knowledge with respect to this topic. The paper uses a model 

from scratch that Business Ethics is the umbrella, due to the reason that ethics have the main 

role when talking about HR. The research provides insights into the synthesis of blockchain 

technology and HR managers and how their tasks may threaten the privacy, confidentiality or 

security of the organisation or the people working in it.  

The main findings of this paper were that managers are thrilled that an existing 

technology could help them automate some steps that need more time. However, at the same 

time, they are not willing to compromise the security, confidentiality and privacy. Therefore, 

the implementation of blockchain is going to be a rather slow process. It is hoped that the 

findings of this research will further contribute to the field of HR. 

 

 

Keywords: Blockchain technology, E-HR, CV scanning, Cambridge Analytica, Business 

ethics 

 

 

 

 

 

 

 

 

 

 

 



 

iii 

 

Table of Contents 

Introduction .................................................................................................................... 1 

Theoretical framework .................................................................................................... 3 

2.1 Business Ethics ................................................................................................................... 3 
1.1.1 Business ethics: Brief Feedback of earliest technologies ................................................................5 
1.1.2 Ecosystem, digitalize ecosystem ......................................................................................................6 
1.1.3 Business Ethics, Smart Contracts, CV scanning at the age of Blockchain Technology ....................8 
1.1.4 Smart Contract .................................................................................................................................9 
1.1.5 Recruitment and Selection (R&S) .................................................................................................. 11 
1.1.6 CV scanning ................................................................................................................................... 13 
1.1.7 Scope of Human Resources in Business Ethics ............................................................................. 14 
1.1.8 E-HR with Blockchain Technology ................................................................................................. 15 
1.1.9 Cambridge Analytica: The act of Business Ethics. How blockchain technology could prevent a 
scandal 17 

Security & Confidentiality of Personal Data, Digital Data.................................................20 

1.2 How tech issues challenges and trends are affecting confidentiality and security ......... 22 

Blockchain ......................................................................................................................23 

1.3 Blockchain Technology and Human Resources: A glance of Blockchain Technology into 
the world of HR ...................................................................................................................... 23 

1.4 Law Regulation about Blockchain Technology into the HR ........................................... 24 

1.5 Importance of confidentiality, privacy, and security in HRM ........................................ 25 

Blending HRM with Blockchain technology......................................................................26 

1.6 General Data Protection Regulation (GDPR) ................................................................ 26 

Methodology ..................................................................................................................30 

Research Design .............................................................................................................30 

Research Setting .............................................................................................................30 

Data collection methods .................................................................................................32 

Data Analysis Process .....................................................................................................32 

Results ...........................................................................................................................34 

Discussion.......................................................................................................................49 

Conclusion ......................................................................................................................51 

Limitations .....................................................................................................................51 

Future implications .........................................................................................................51 

References ......................................................................................................................53 

Annex A ..........................................................................................................................60 

Annex B ..........................................................................................................................61 

Annex C ..........................................................................................................................62 

 





 

1 

 

Introduction 

Being a Social Policy graduate, I was always intrigued by the fact that even though 

technology is undoubtedly in every aspect of our lives nowadays, it was never included as a 

topic during my studies. Upon the completion of my last internship, I was rather surprised by 

the fact that the organization was implementing a new technology which I have never heard 

before. So taking into consideration that any company that would like to be in the high-way of 

opportunities and development, it should follow a fast-changing aspect, which is technology 

(Lumineau et al., 2020). This is what triggered my interest to study more and to finally decide 

to explore a possible connection between HR and technology. 

Human Resources is a field that represents the employees/people and at the same time it 

has to follow all the revolutions that are happening every moment, therefore it is a fact that HR 

and technology should blend smoothly together (Broderick et al., 1991). To the best of my 

knowledge, research that explores HR and technology is still scarce. Therefore, this study will 

aim to add to the existing gap in the literature by exploring how blockchain and HR can 

complement each other for the benefit of the organisation and the employees. The research 

problem is going to be focused on the concept of how blockchain can affect any aspects of the 

Human Resources Management (HRM). This study will aim to understand the impact of the 

latest technologies in general but more specifically on how Blockchain Technology can be 

applied into the HRM. 

Thus, my main goal is trying to understand the potential of using Blockchain Technology 

via managers into the HRMS. As Xu et al (2019) mentioned, most businesses can use 

blockchain to store data where in the next chapters you can realise the importance of personal 

data and digital data, thus blockchain can improve the transparency and security of the data, 

and prevent the data from being tampered with (Xu et al., 2019). As mentioned before, there 

has been limited research on this topic given the novelty of this technology and its limited 

implementation. Therefore, a gap occurs in terms of blockchain and HR. In order to contribute 

a small part of this gap, this study will address the following research questions: 

 

a) Are managers accepting this technology?  

b) How strong is the part of ethics in technological implementations in HR? 

 

This thesis is organised into 9 chapters. In the next chapter, I discuss in more detail the 

theoretical framework underpinning this study focusing on ethics and I review relevant studies 



2 

 

in the field. In chapter 3, I delve more into the topic of security and confidentiality of personal 

and digital data. Following that, in chapter 4, I explain the basic concept of blockchain and 

continue to analyse how HRM is blended with blockchain technology in chapter 5. In chapter 

6, I discuss the research methods that were used to collect the data as well as the methodological 

framework that was followed to analyse the data. Following that, the results are presented and 

in chapter 7 and further discussed in chapter 8. Finally, chapter 5 summarises the study and the 

main findings, the main implications as well as the limitations of the study. At the end 

suggestions are made for future research.  

Figure 1 below show the model that was created for this thesis. In this figure you can 

find the model of usage that shows the connectivity and the roles between the key aspects of 

this thesis. Business ethics is the main veil that covers all the other vital elements. After 

business ethics, security has a main role that was separated from the scope of blockchain and 

HR. At the end the, connectivity yields the main domain of blockchain into the HR. 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Figure 1: Thesis Model 



 

3 

 

Theoretical framework 

2.1 Business Ethics  
 

Business Ethics in any technology has a crucial role since no-one is able to estimate the 

possible impact of technology in the future, from the burst of blockchain it was very hard to 

imagine where it could be implemented (Dierksmeier & Seele, 2020). Like most technologies, 

the creators most likely did not take into consideration how the contribution of their technology 

can enforce or affect other technologies. An example of such a case is the internet which started 

from the U.S. Department of Defense, ARPANET which used packet switching to allow 

multiple computers to communicate on a single network (Hauben, 2007). In the last decade, 

the internet is starting to become a need and a tremendous part of our life (Melcherts, 2017). 

Blockchain is not only cryptocurrencies, but much more. Now blockchain technology is being 

implemented from banking systems to gun tracking, from voting to advertisement. It is 

ineluctable to think that it will not affect the HR domain (Miscione et al., 2018). EU not only 

is enforcing this technology by financing various projects, but it is trying to educate the people 

about this technology.  

The European forum of Blockchain recognises that blockchain is an important tool that 

could assist initiatives that their goal is social impact, thus as speaking for today there are 

numerous organizations worldwide looking to implement blockchain (EuBlockchain, 2020). It 

is crucial to add that since blockchain has a bright future in various aspects, that the business 

ethics has a role of a supervisor regarding this technology, where it has to have  an extensive 

and critical role, not only during the implementation process but more efficiently after the 

implementation process (Dierksmeier & Seele, 2019). The ethical ambivalence of the usage of 

blockchain is being eliminated in the article by Dierksmeier and Seele (2019) which mentions 

the blockchain applications in the role of trust, job platforms and the impact on privacy and 

secrecy. 

The biggest dilemma is how business ethics can affect any parts of this technology since 

blockchain is eliminating the participation of third parties (Nakamoto, 2019). Blockchain 

created a new decentralized and independent peer-to-peer transactions that can bypass 

important third parties. Hence, conflicts from enormous organisations and governments were 

something to be expected (Lu, 2019). But as mentioned before, if all the opponents take 

advantage of this technology first and dive into blockchain, then the quality of work that 

business ethics can provide will be extraordinary. In such a way that they will be the winners 

in this new modern fight (Lapointe & Fishbane, 2019). 



4 

 

When talking about Blockchain technology we are talking about a new-born technology 

that is now on the highway of evolution. Notably, blockchain created a new era where it is 

erupting and aims to develop each and every sector in an organization, from the workforce 

going all the way up to the CEOs.  (Lim et al., 2018). Blockchain is a technology that became 

very famous through Bitcoin, but blockchain is not the Bitcoin nor the only technology of the 

Crypto-currencies, but BT is the technology that assures security, confidentiality and the 

transparency that nowadays everybody needs (Nakamoto, 2019). The Association of Chartered 

Certified Accountants (ACCA) implies in one article of Douglas and Book (2019) that at these 

times that the humanity is crossing, people are in the midst of a sea with the changes in business 

ethics. The growth of the digital economy is giving the chance for new types of business risks 

as well as a rise in ethical challenges. Political, economic, and social norms are being 

conformed and those challenges are amplified by mass digital social engagement (Douglas & 

Book, 2019). 

The main issue faced by Big Data (enormous datasets), is information security (Chong 

& Shi, 2015). Blockchain became the tool to solve the issues that arise from big data, where in 

a world that big data are escalating day by day, a technology amongst them is vital to reassure 

data integrity and reliability (Chong & Shi, 2015). But the most important aspect of blockchain 

is that it can stabilize information systems due to the lack of a single point of failure, as 

blockchain is a decentralized technology, in other words the authority is delegated away from 

a central authority (Myeong & Jung, 2019).  

It is a de facto that any kind of technology that had been developed or is on the path to 

be developed must face the consequences of the unknown. Any new-born technology has to 

prove its morality.  Business ethics must follow the law regulations and set that as a priority. 

Some studies such as (Klarin, 2020; Xu et al., 2019) research from the angle of information 

technology, computer science, and network theory. Although it is a new technology, it has 

managed to be regulated by EU legislation in a very short time, and this shows the recognition 

of new technologies by the EU authorities. It is a fact that the EU has predicted the flow that 

blockchain technology was going to have and so it has a website 

(https://www.eublockchainforum.eu/) that it is contributed only for blockchain..  

On the 29th of October in 2019, a conference took place in Athens regarding the topic of 

Decentralization. Eva Kaili, who was elected Member of the European Parliament in July 2014 

with the Panhellenic Socialist Movement - Olive Tree and Head of the Hellenic S&D 

(Socialists & Democrats, 2014) delegation, said that blockchain managed to be regulated by 

EU legislation in a very short time. As Kaili (2019) said on the Decentralized Event in Athens 

https://www.eublockchainforum.eu/


 

5 

 

2019, EU is trying to achieve a solid relationship between the citizens and public with the usage 

of blockchain technology (Strengthening European Communities with Blockchain 

Decentralized, 2019). (See Annex B, (i)) 

Setting a key example that blockchain is becoming part of our daily life, various projects 

take place where blockchain is the protagonist such as “Decentralized Qualifications' 

Verification and Management for Learner Empowerment, Education Reengineering and Public 

Sector Transformation”. This project is an element and a fact that day by day blockchain 

technology is becoming a part of our lives. Taking a closer look on this project anyone can 

realise that there are multiple objectives where one of those is to provide HR consultancy and 

competency management services (Kontzinos et al., 2020). 

 

 

1.1.1 Business ethics: Brief Feedback of earliest technologies  
 

It is a fact that Business Ethics existed way before the appearance of blockchain 

technology. Notably, business ethics is not something that is tangible, it aims to the ethical 

behaviour from organization to the employees. So, it is appropriate to mention how business 

ethics reacted from their corresponding institutes when new technologies appeared. It is 

impossible to mention all technologies and the behaviours that business ethics had 

(Dierksmeier & Seele, 2019). However, it is clear that the literature review of blockchain and 

its impact on several areas are still ambiguous (Dierksmeier & Seele, 2019). This thesis is 

addressing the issue that, to the best of our knowledge, was not addressed before, and as based 

on the preliminary research, it gives advanced indications of how these two concepts will work 

in synergism in the nearest future, and what challenges are foreseen at this point in time. On a 

paper at the 2017 IEEE 6th International Congress on Big Data, a paper was published that 

made it clear that blockchain technology will face obstacles, mentioning challenges of this 

technology such as scalability and security problems waiting to be overcome (Zheng et al., 

2017).   

Any feedback that we could get from historical events of any invention whether it was a 

technological invention or any other type, business ethics always took place. An example of 

that is the nuclear energy (atomic energy) that nowadays is restricted into different levels of 

usage, of what history taught us (DeBoer, 2013). This nuclear energy can be used as feedback 

from technological achievements that must be taken into consideration. As the example 

mentioned before, the scale runs from a zero event with no safety significance to 7 for a “major 

accident” such as Chernobyl, this data is based on the website of  word nuclear association 



6 

 

(ENSREG, 2020). Business ethics was the moderator to implement regulations of control and 

law, such as the European Nuclear Safety Regulators Group (ENSREG) which exists to 

regulate and control most aspects of this intention (ENSREG, 2020). This is an example of 

how Business ethics treats technologies that should follow a specific order of the 

implementation process.  

 

1.1.2 Ecosystem, digitalize ecosystem  
 

An ecosystem in the simplest form of definition is the network of organizations 

(Peltoniemi et al., 2005). Moore in 2003 introduced the term where the author explained that 

an ecosystem includes the suppliers, distributors, customers, competitors and government 

agencies. A business ecosystem is “a dynamic structure which consists of an interconnected 

population of organisations. Business ecosystem develops through self-organisation, 

emergence, and co-evolution, which help it to acquire adaptability. In a business ecosystem 

there is both competition and cooperation present simultaneously” (Peltoniemi et al., 2005, pp. 

11-14).  

Figures 2 and 3 below show the characteristics of a business ecosystem and the 

characteristics of a digitalised business ecosystem, respectively. Comparing the two figures 

below, the difference between an ecosystem and a digitalized ecosystem is obvious. The 

complexity that appears in a digital ecosystem is far more intricacy rather than the traditional 

ecosystem.  

 

 



 

7 

 

 
Figure 2: Characteristics of a business ecosystem (Peltoniemi et al., 2005) 

 

 

 
Figure 3: Characteristics of a digitalized business ecosystem from McKinsey (Kasser et al., 2018, p. 3) 



8 

 

 As shown in the two figures above, the main difference between an ecosystem and a 

digitalized ecosystem is that a digital ecosystem became part of an organisation in the eruption 

of the digital era (Kopalle et al., 2020). 

With the interconnected information, technology resources can function as a unit. 

Creating a digital ecosystem map is a key to establish a strong ecosystem where the digital 

ecosystem map is a visual diagram of all digital tools and platforms used within 

the organization (Kopalle et al., 2020). It is important to distinguish the difference, thus, Weill 

& Woerner (2015) showed that digitalized ecosystems had 50% more revenue and the 

understanding evolved.  

Bearing in mind the differences between the two types of digitalization, it is clear that 

digitalized ecosystems can be complicated in various ways. Thus, it is expected that in the era 

of digitalized aspects, blockchain is akin within this era where this technology is reassuring the 

smooth flow of the organisation (Lu, 2018). Along with the transition between the usage from 

a non-technological time to the adoption of modern digital technologies erupted in the growing 

pervasiveness, such as smartphones, cloud connectivity, Internet of Things (IoT), Big Data etc. 

Where it is realistic to assure that in the future there will be further enrichment and expansion 

of the scale and scope of these interdependencies. Not surprisingly, the term “digital 

ecosystems” is gaining ground both in academic and business lexicons (Kopalle et al., 2020). 

Kopalle et al (2020) defines that digitalized ecosystems are business environments framed by 

networks of interdependencies specifically generated through digital technologies (Kopalle et 

al., 2020). 

 

 

1.1.3 Business Ethics, Smart Contracts, CV scanning at the age of 

Blockchain Technology 
 

HR managers are spending a part of their time introducing the contracts, reviewing CVs 

and more tasks that are time-consuming, their routine requires these tasks to be made (Mitchell, 

2013). A lot of tasks that are required for HR managers to operate are severe time-consuming 

(Panayotopoulou et al., 2007). Thus, the understanding that technology could help to spend 

less time for these tasks could be helpful, on one hand less time and on the other hand more 

efficient  (Lepak et al., 1998). 

How secure and trustworthy is a degree from a university, or a diploma of 

accomplishment? One may come to an idea that the cyber security is questionable in 2020, and 

that a number of certificates/personal documents can be falsified by using the means of modern 



 

9 

 

apps. Back in 1991 was the first time that the term of timestamp was introduced on a digital 

document (Haber et al., 1990). Concerns such as scams, or phony about certification and 

whether they are original or cannot be copied was a matter that was an issue. Digital 

timestamping was first introduced in the paper of Haber where the importance of privacy and 

security was introduced (Haber et al., 1990).  

The main issue of organisations nowadays, is finding candidates that could fit the 

requirements of the announced positions, by matching their education and professional 

background (Rani & Venkatraman, 2020). In an era where competition has gone higher more 

than ever, the process of hiring an employee needs to touch the expectations and use technology 

that nowadays  most of individuals use or even more upgraded, in order for an organisation to 

be competitive (Manolescu, 2008). Blockchain is the manna from heaven, thus, it is a 

technology that can certify security, privacy, and confidentiality more than any other type of 

technology (Kamboj & Yang, 2018). Focusing on the terms that HR managers are using 

nowadays, I aim going to show the evolution of these terms and how blockchain will be in 

benefit for them. In the next chapter, I will explain these terms and the effect of this technology. 

 

1.1.4 Smart Contract 
 

A smart contract can be explained in numerous ways and terms but the most simplified 

and comprehensive term is that most steps that are automated describe a smart contract as an 

automatable and enforceable agreement, which covers both operational and non-operational 

aspects and describes templates and agreements for legally-enforceable smart contracts, based 

on legal documents (Clack et al., 2016). 

Mentioning the technicalities of how a smart contract is being programmed is beyond the 

scope of this study. But further details about it could be seen in the article of Nick Szabo that 

introduced this concept in 1994 and defined a smart contract as ‘‘a computerized transaction 

protocol that executes the terms of a contract” (Christidis & Devetsikiotis, 

2016, p.2296).  Ethereum cryptocurrency was the landmark for smart contracts (Zain et al., 

2019). The importance of this type of contract is also highlighted by (Buterin, 2013). A smart 

contract has a very simple coding, thus programming it is not an issue for smart contract. 

However, the concern of a smart contract is to set the appropriate pillars and objectives of a 

contract that the program will count on. Hence, the main challenge is that a smart contract 

requires to have as a reference all the law and law regulations and the external price ticker 

(Buterin, 2013). A smart contract is a type of software that contains rules and regulations for 



10 

 

negotiating the terms of a contract. It automatically verifies the contract and then executes the 

agreed upon terms. In the case of Ethereum, a smart contract’s centralized code is made 

decentralized for execution purposes on the Ethereum blockchain, it becomes 

a smarter contract. Coding and executing smart contracts on the Ethereum blockchain makes 

them immutable and independent from centralization (Buterin, 2013). Figure 4 below shows 

the simplest explanation of the difference between a traditional contract and a smart contract.  

 

 

 
 

 

 

 

 

 

 

Figure 4: Main differences of Traditional contracts to Smart contracts (Faisal, 2018) 

 

 

Next it is important to understand the role of a smart contract in the HR domain. Doing 

the aftermath of the bureaucracy that monopolize most of the time of the HR managers, it is 

significant to implement a technology that will reduce these issues (Tyson, 2014). Remarkably, 

having the potential to use smart contracts to manage better aspects of HR and in a more 

optimized manner would be beneficial for both parties. For instance, pay attention to the 

Blockchain and smart contracts about paying the staff’s salary; in the Blockchain network and 

with the help of these  type of contracts and the payroll of the human resources will be easily 

distributed among the staff and there will be no fraud or delay in it too (Koncheva et al., 2019). 

Using smart contracts in paying wages and controlling the salaries of employees in every 

business group can be highly effective and accurate (Koncheva et al., 2019). Smart contracts 

replace the trusted third parties; that is, the intermediaries between contract members. They 

leverage this with the help of automatic code execution that is distributed and verified by the 

network nodes in a decentralised blockchain network (Macrinici, 2018). They also enable 

transactions between untrusted parties without any intermediary commission fees, the third-

party dependence, and the need of mutual interaction directly of the counterparties (Swan, 

2017). 



 

11 

 

In the paper by Zheng  (2020), the role of smart contract had been developed and 

improved in order to have as a key aspect the security and immutability. In a part of their paper, 

they mentioned that smart contracts can guarantee the appropriate access control and the 

enforcement of the contract. The developers can assign permission for each service that occurs 

in the contract (Zheng et al., 2020). Once the specific part of the smart contract is fullfield, then 

it will automatically execute in order of the specific manner (Zheng et al., 2020). As shown in 

figure 4, the main benefits are time, automation, less costs, no need for a third party and virtual 

presence is replacing the physical one (Faisal, 2018). 

Ending this section, the main core of a contract has to be clarified. A traditional contract 

was good, but the main issues with that was the burden into the administrative issues that 

already existed in the hands of HR managers (Tarraga et al., 2019). Other small matters that 

still exist are that traditional contracts are suffering from lack of clarity, they are too wordy. 

That is the result of a technological absent. As a result of blockchain, there are some challenges 

for its use, but nevertheless those challenges have to do with Law regulations mostly, and the 

evolution of this technology that until today we are still learning a lot for its potential 

(Koncheva et al., 2019). 

 

1.1.5 Recruitment and Selection (R&S)  
 

Recruitment and selection (R&S) is without a question one of the most cost-full 

procedures in a company. It is the momentum time, when a company chooses the people they 

will employ and who will represent the company in the working environment. R&S is 

expensive and time-consuming (Gopalia, 2012). Thus, it is expected that a technology would 

come along to change some aspects. On one hand the cost, and on the other hand the time are 

a vicious part of an organization and various research evidences show that online recruitments 

have become an easy way to save costs and valuable time of firms (Hart et al., 2000). The 

emergence of e-recruitment as a strategy of cost and time saving mechanism coincide with the 

introduction of New Public Management (NPM) in the public sector geared towards addressing 

institutional and structural problems afflicting public bureaucracies in both developing and 

developed countries (Snell et al, 2002). 

In 2016, the Society for Human Resource Management (SHRM) made a survey about 

the average Cost-per-Hire for Companies (SHRM, 2016). The survey had 2,048 respondents. 

The result of the survey showed that the average time it takes to fill an open position is 42 days, 



12 

 

where after a five-month mark the organisation can expect a new hire to reach full productivity 

(SHRM, 2016) (See Annex B, (ii)). 

Imagine an organisation hires the wrong person twice for a certain job position. Almost 

one year without the productivity of that position and certainly spending an extraordinary 

amount of money for the requirements of the R&S. But now, let us imagine, a technology that 

helps you, a technology that aims to emerge from this swamp and the benefits of it create 

automation in the level that the organisation requires. Alongside the process of R&S could be 

less time consuming if taking advantage of blockchain technology (Salah et al., 2020). A fact 

that characterizes the HR managers know from hand how hard it is to find time and as Milan 

Kundera (1984, p. 111) said “Human time does not turn in a circle; it runs ahe";"""date"",""2021-01-21T12:03:58Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.7""
""xmp:CreatorTool"",""Microsoft Word""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dc:creator"",""Microsoft Office User""
""language"",""en""
""dcterms:created"",""2020-11-09T21:37:01Z""
""Last-Modified"",""2021-01-21T12:03:58Z""
""dcterms:modified"",""2021-01-21T12:03:58Z""
""dc:format"",""application/pdf; version=1.7""
""xmpMM:DocumentID"",""uuid:B8939986-BF92-47F3-A55F-91028E5DF451""
""Last-Save-Date"",""2021-01-21T12:03:58Z""
""pdf:docinfo:creator_tool"",""Microsoft Word""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2021-01-21T12:03:58Z""
""meta:save-date"",""2021-01-21T12:03:58Z""
""pdf:encrypted"",""false""
""xmp:CreateDate"",""2020-11-09T21:37:01Z""
""modified"",""2021-01-21T12:03:58Z""
""Content-Length"",""1605276""
""pdf:hasMarkedContent"",""true""
""Content-Type"",""application/pdf""
""xmp:ModifyDate"",""2021-01-21T12:03:58Z""
""pdf:docinfo:creator"",""Microsoft Office User""
""xmp:MetadataDate"",""2021-01-21T12:03:58Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Microsoft Office User""
""dc:language"",""en-US""
""meta:author"",""Microsoft Office User""
""meta:creation-date"",""2020-11-09T21:37:01Z""
""created"",""2020-11-09T21:37:01Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""100""
""Creation-Date"",""2020-11-09T21:37:01Z""
""resourceName"",""master_alexandra_ulrica_constantinide.pdf""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""326"",""0"",""382"",""0"",""239"",""1569"",""4452"",""0"",""2592"",""1204"",""2713"",""2963"",""2727"",""1419"",""188"",""2579"",""2745"",""2032"",""2653"",""2521"",""1172"",""2789"",""2647"",""1355"",""2795"",""2947"",""70"",""1900"",""2913"",""2294"",""1756"",""874"",""1108"",""2437"",""3051"",""1529"",""208"",""2366"",""2566"",""2472"",""1647"",""1642"",""1560"",""2147"",""1828"",""2172"",""1592"",""2136"",""2132"",""1769"",""1784"",""1643"",""1595"",""1964"",""1793"",""36"",""2789"",""747"",""2324"",""1957"",""2844"",""3047"",""3033"",""3169"",""3262"",""3212"",""1149"",""2562"",""2371"",""3627"",""4448"",""4236"",""3823"",""3783"",""4157"",""4056"",""3530"",""3816"",""3898"",""4451"",""4262"",""4108"",""4355"",""3530"",""3943"",""3159"",""3234"",""3781"",""3822"",""3680"",""4303"",""3560"",""4364"",""3568"",""3915"",""3176"",""3562"",""3962"",""4360"",""3122""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""Author"",""Microsoft Office User""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-11-09T21:37:01Z""
";
1619098800-181;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;[PDF][PDF] TinyEVM: Off-Chain Smart Contracts on Low-Power IoT;C Profentzas, M Almgren, O Landsiedel ; core.ac.uk;;"… The EVM is a Quasi-Turing complete machine [3] to execute state-transitions in the blockchain …

For a smart contract to include sensor data, current solutions use services such as Oracles [4].

Oracles act as a third-party information source, and supply verified data from Internet …";Autres articles;Version HTML;[PDF] core.ac.uk;https://core.ac.uk/download/pdf/326728395.pdf;;;https://scholar.google.ch/scholar?start=730&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098804-200;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;The New Money: The utility of Cryptocurrencies and the need for a New Monetary Policy;DKC Lee, EGS Teo ; Available at SSRN, 2020  papers.ssrn.com;;"… Many investors in the cryptocurrency market buy cryptocurrencies or crypto-tokens not for the

functions, but for speculative purpose. One of the notable earliest use cases for issuance of tokens

was for fundraising. Projects (usually with a blockchain angle) would issue tokens to …";Cité 2 fois;Les 2 versions;[PDF] sussblockchain.com;https://sussblockchain.com/wp-content/uploads/2020/06/SSRN-id3608752.pdf;"
1 

The New Money: The utility of Cryptocurrencies 

and the need for a New Monetary Policy 

 

David K. C. Lee* and Ernie G. S. Teo# 

*Singapore University of Social Sciences, National University of Singapore and Shanghai University 

of Finance and Economics 

#
National University of Singapore and Blockchain Association of Singapore 

  

Abstract 

Since its inception in 2008, cryptocurrencies are gaining adoption globally. Even though its utility may 

vary, the primary purpose of cryptocurrencies is to provide some form of payment (or medium of 

exchange) in the digital world. As more use cases arise from the industry, cryptocurrencies and 

blockchain are no longer a niche topic. Educational institutions are introducing it into their curriculum, 

and governments are talking about it in parliament. In particular, governments are keen to determine if 

the underlying technologies can form the fundamentals to issue a Central Bank issued Digital Currency 

(CBDC). Will these forms of currency become the “New Money”? This paper sets out to explore the 

utility of cryptocurrencies and CBDC, their implications on the economy and the government’s ability 

to use monetary policy. We examine and compare the approaches to CBDCs suggested by various 

governments. 

 

Keywords: Central Bank Digital Currency, Cryptocurrency, Payment System, Distributed Ledger 

Technology, Monetary Policy, DCEP, Libra. 

  

  



2 

1. Introduction: From digital payments to digital cash 

  

The rise of the Internet, PC, and companies like Amazon and Alibaba for the past 20 years has made e-

commerce a part of everyday life. As new technologies emerge, we are entering a digital era with 

numerous digital footprints and digital payments, playing an increasingly important role. Traditional 

digital banking and payment technologies have been successful in the past, but perhaps not in the future. 

These electronic payment systems were dependent on bank deposits, credit cards or stored-value 

facilities; these payment intermediaries increased the costs and complexity of electronic payments, 

making it inefficient and expensive. 

  

To support the growing e-commerce sector, make full use of the digital footprints and increase payment 

efficiency, truly digital cash is in high demand. Digital cash shall serve as the digital replacement of 

physical cash, meaning that it should fulfil criteria such as to provide a store of value, a unit of account, 

a medium of exchange, as well as anonymity and transferability to the users, but it is more than that – 

digital cash should also be able to handle small transactions efficiently. On a technical level, digital 

cash needs to address the double-spending problem, the risk that it can be spent twice. These criteria 

are hard to satisfy, and the compromise usually results in high overheads, making the digital payment 

method inefficient and expensive. Many digital payments methods also do not meet the criteria of 

anonymity, and most forms of digital payments are traceable. 

  

The invention of Bitcoin in 2008 seems to provide a potential solution, or at least a direction. It is truly 

peer-to-peer and offers built-in pseudo-anonymity1. Decentralisation allows Bitcoin to remove the need 

to trust centralised middlemen and have no single point of failure. Incentive mechanisms were then 

incorporated to ensure that the interests of the participating economic agents of Bitcoin are aligned. 

Most importantly, ensuring transactions are correct and valid. The creation of Bitcoin also pioneered a 

new category termed “cryptocurrencies”. 

 

As the world gets more digital and financial institutions adopting technology to innovate on financial 

services, cryptocurrencies (and blockchain) are becoming mainstream and widely recognised. While 

searching for new and sustainable growth areas, governments have included blockchain into various 

national initiatives. In Kshetri and Voas (2018), the authors explain how the US-based platform for real-

estate registration, Bitland, uses a blockchain-based land registry system in Ghana, where 78 per cent 

of land is unregistered, and how the platform is expected to guarantee property rights and reduce corrupt 

practices. Geospatial applications involving blockchain can potentially unlock economic values. 

 
1 Bitcoin is anonymous by design such that owners’ identities are unknown to other network users unless they 

choose to reveal it. However, the patterns of usage or other information may reveal the identity through modern 

tracing using AI algorithms or via links with third parties. 



3 

Similarly, in China, the use of fake export invoices to disguise cross-border capital flows has been 

pervasive. The government is relying on provenance, traceability, and transparency characteristics of 

blockchain-based systems to thwart such scandals and assist financial institutions in battles against fraud, 

money laundering and illegal activities. Governments (such as Kenya in Africa, China in Asia and 

Argentina in Latin America among many others) have also discussed issuing digital currencies of their 

own using blockchain technology to facilitate lower cross-border transactions, financial inclusion, 

reliable and provided end-to-end traceability with smart contracts (Raskin & Yermack, 2018). Could 

cryptocurrencies or national digital currencies become the “New Money”? Will we see the end of paper 

money? This paper will explore this topic and discuss the implications on monetary policy and the 

issuance of Central Bank Digital Currency (CBDC). But first, we start by providing a brief introduction 

to cryptocurrencies and its economics. 

  

2. Cryptocurrencies 

 

2.1. What are cryptocurrencies? 

  

As the name implies, cryptocurrencies are currencies based on cryptography. Most cryptocurrencies 

consist of a distributed network of validators where each validator holds a replicated copy of the ledger 

of transactions. Tokens (or currency) are minted via entries in the ledger, and this can be done with 

rules embedded in the code for validation (such as Bitcoin mining) or on a one-off or ad-hoc basis. The 

ledger (or blockchain) is constructed using cryptography to make it almost impossible or very costly to 

change or reverse entries.  

 

Bitcoin is the first cryptocurrency of such kind and it introduces the idea of blockchain. Features of 

decentralisation and immutability allow it to be a form of digital cash which can be moved peer-to-peer 

without an intermediary and will enable it to have no central control. These features also make it 

different from current digital payments, and many consider it to be the chief ingredient to create the 

future of the digital (crypto-token2 and sharing3) economy. 

  

Tokens in the Bitcoin network are represented by ledger entries, since there are no physical bitcoins. 

The token creation mechanism was designed to create a capped money supply (a fixed increase in its 

amount until the cap is reached). This mechanism is built into the code and cannot be changed without 

the agreement of a majority of the network. There had been various attempts to change this code and 

 
2 Token Economy refers to the system of incentives based on cryptocurrencies that reinforce and build desirable 

behaviours the in blockchain ecosystem. 
3 An economic system in which assets or services are shared between private individuals, either free or for a fee, 

typically by means of the Internet. 



4 

this led to hard forks (derivative currencies) as majority consensus cannot be reached (Atik & Gerro, 

2018). There are also instances that offline governance was heavily influenced by core developers that 

we saw community rolling back to an earlier version of the network voluntarily such as the 2013 Bitcoin 

fork from version 0.8 back to 0.7 (Narayanan, 2015). 

 

Since the inception of Bitcoin, various forms of cryptocurrencies were introduced4 - some have differing 

designs from Bitcoin such as the methods to create the money supply, and some offer alternative 

technologies that claim to work better. Cryptocurrencies or crypto-tokens can be grouped into five 

general categories, (1) Transactional, (2) Utility, (3) Platform, (4) Application, (5) Asset-backed. 

  

Transactional cryptocurrencies function like Bitcoin, and their main aim is to provide a form of 

payment. Newer versions have enhanced privacy features and can scale better than Bitcoin. One such 

example is Dash5, a cryptocurrency based on Bitcoin but with built-in privacy functions that include 

those providing privacy of the transactions with shielded ledgers. Its tamper-proof instant transactions, 

accompanied by a well incentivised secondary peer-to-peer network, make it a stable medium of 

exchange (Duffield & Diaz, 2018).  

 

Utility cryptocurrencies are tokens designed to facilitate transactions for custom blockchain networks. 

These can be purpose-built blockchain networks such as those for supply chain traceability or 

decentralised finance.  

 

Platform cryptocurrencies facilitate the operations of smart contract enabled blockchains. Such 

blockchain allows users to create smart contracts that form the basis for decentralised applications.  

 

Application cryptocurrencies are used for decentralised application use cases, which are built on 

blockchain smart contract platforms.  

 

Asset-backed cryptocurrencies are linked to real-world or virtual assets such as gold, fiat currency or 

property. These can be used to create a fractionalised investment for assets that may require a large 

outlay. They can also be used to provide a stable medium of exchange which can then be used for 

payments.  

 

 
4 As of February 2020, around 5000 of such cryptocurrencies exist 
5 Dash is an open source cryptocurrency forked from the Bitcoin protocol and also a decentralized autonomous 

organization (DAO) run by a subset of its users, which are called ""masternodes"". Other privacy coins are Zcash 

(ZEC), Zcoin (XZC), Monero (XMR), TeleCoin (TELE), Incognito (PRV), and PivX(PIVX). 



5 

Many investors in the cryptocurrency market buy cryptocurrencies or crypto-tokens not for the 

functions, but for speculative purpose. One of the notable earliest use cases for issuance of tokens was 

for fundraising. Projects (usually with a blockchain angle) would issue tokens to investors in return for 

funds (usually in the form of other cryptocurrencies). These tokens would eventually get listed on a 

cryptocurrency exchange. These are known as ICOs (Initial Crypto-Token Offerings). The success of 

such projects depends largely on its perceived value. Being speculative in nature, there were many ICO 

scams wherein the fundraisers had no intention of bringing the project to fruition. This prompted many 

governments to impose regulation or even outright banning this form of fundraising. We will discuss 

more about the economics, finance, and challenges of cryptocurrencies in the following sections.  

 

2.2. The economics and finance of cryptocurrency: Network, Incentives and Markets 

 

Unlike a centralised system where there is one sole authority that decides what is stored in the database, 

distributed networks are made up of multiple connected computers/digital devices (or nodes) working 

towards a common goal. In the case of cryptocurrencies such as Bitcoin, the distributed network needs 

to synchronise6, validate token transactions and record them in a replicated database. The key challenge 

of such a distributed network is to get the nodes to agree on the transactions that they are recording. The 

creators of Bitcoin designed incentives in the distributed network such that the network can achieve 

consensus on the validity of the cryptocurrencies transactions that are broadcasted and recorded onto 

the blockchain (or distributed ledger). In distributed networks, such incentive mechanisms are known 

as consensus protocols. The best-known example in cryptocurrencies is Proof of Work (PoW), which 

is also known as Bitcoin mining.  

 

In Bitcoin mining, servers on the network commit computational resources to solve a cryptographic 

puzzle which is related to the set of transactions that are being verified as discussed in Nakamoto (2008). 

In return, the first server to find the answer to the puzzle wins a mining reward. Bitcoin mining is 

probabilistic in nature and the change of winning increases with the computational power committed. 

Servers have an incentive to ensure that the transactions are valid if they want to keep the reward they 

win. This type of consensus protocol has a few problems.  

 

First, as the network grows and becomes more competitive, it consumes large amounts of electricity 

making it harmful to the environment. According to Stoll, Klaaßen and Gallersdörfer (2019), electricity 

consumption required by Bitcoin is more than the entire country of Jordan. Amassing computational 

power also leads to incremental chances of winning the mining reward, and this results in 65% market 

 
6 The internet is inherently asynchronous in the sense that there is no global clock and each nodes may receive 

messages that carries transactions’ information in different sequence. This has been a major research topic in the 

area of distributed network involving network engineering and fault tolerance. 



6 

share being held by major mining companies such as Bitmain, Ebang and Canaan and only 8% of the 

market held by small scale miners. Second, since one can accumulate computation power (or machines) 

to gain an unfair advantage in bitcoin mining, this leads to less decentralisation and ultimately results 

in strategic mining behaviour where miners with high computation power game the outcomes to their 

advantage. 

 

The decentralised nature of cryptocurrency networks means that such consensus protocols are necessary 

as the servers that participate in the network are untrusted. Incentive mechanisms need to be in place 

such that the servers will act in the best interest of the network. Other than PoW, there are a plethora of 

other consensus protocols which are designed to address some of the issues with PoW. One popular 

alternative to PoW is Proof of Stake (PoS). PoS requires the servers to stake cryptocurrencies (“freeze” 

the coins in a wallet) for a chance to be selected as the verifier/miner. It trades computer resources in 

exchange for the time value of the cryptocurrency stake. Proof of Stake was first introduced in Peercoin, 

and is designed to be better in terms of energy consumption and it also better aligns the incentives 

between stakeholders (Ren, 2014). Chepurnoy, Duong, Fan and Zhou (2017) discuss Twinscoin, a 

cryptocurrency that uses both PoW and PoS.  Each time a new protocol is introduced, there will a trade-

off and another weakness, and the design thinking is to ensure that whichever consensus is used, it will 

provide safety7 and liveness8 for the distributed network.  

 

Consensus protocols control the creation of new cryptocurrency. In Bitcoin, new coins are created on 

the blockchain with each new block to provide for the mining reward. Bitcoin mining rewards started 

with 50 bitcoins and are halved every four years. In May 2020, rewards were reduced to 6.25. This 

halving will continue until a cap of 21 million coins is reached, as discussed in Nakamoto (2008). This 

is a conscious effort by Bitcoin’s creators to “hard code” the coin supply and prevent any central 

authority from changing it. Essentially, in most cryptocurrency networks, code controls the supply. It 

is difficult to change the programming, as the entire network needs to agree to upgrade code. This pre-

programmed supply and cap create scarcity.  

 

However, this is only one determinant of the market supply. Even though the creation of coins is pre-

programmed, the circulation of coins is in the hands of human beings. The built-in coin creation and 

cap creates an expectation of future scarcity, and this causes hoarding of coins in anticipation of a higher 

price. This drives prices up and encourages further hoarding, making cryptocurrency mining a lucrative 

industry. Some coins take this further by offering “dividends” to coin holders. The choice of consensus 

 
7 Safety means that the consensus must never achieve agreement on a state of the ledger when nodes have not 

actually agreed on that given state to ensure the integrity of the ledger. 
8 Liveness means that consensus cannot stall, even in case of a tie, the consensus algorithm must always make 

progress 



7 

protocol may also amplify this, for example, Proof of Stake coins organically controls supply with its 

staking requirements. In other cases, the creators of the cryptocurrency network pre-create or pre-mine 

the cryptocurrencies, essentially making them the majority owners and controllers of the coins in 

circulation. 

 

One of the major challenges faced by cryptocurrencies is price volatility as current use cases are 

speculative in nature. Many buy and hoard cryptocurrencies in anticipation of higher future value. Athey, 

Parashkevov, Sarukkai and Xia (2016) find that Bitcoin is mostly used for investing (or store of value), 

and its value is linked to beliefs about the future rather than exchange rates to current fundamentals. 

Demand for cryptocurrencies is largely speculative in nature. Sovbetov (2018) finds that (for five major 

cryptocurrencies) the cryptocurrency market beta, trading volume and volatility are significant both the 

short- and long-run. Liu, Tsyvinski and Wu (2019) also find that cryptocurrency market size and 

momentum capture the cross-sectional expected cryptocurrency returns. During bull runs, the 

cryptocurrency market is very attractive as it is much more volatile as compared to traditional 

investments.  

 

The cryptocurrency exchange industry is a fragmented one, and there are more than 250 cryptocurrency 

exchanges that are tracked on CoinMarketCap (a cryptocurrency tracking platform). These exchanges 

operate in a number of markets and offer exchange of fiat currencies to cryptocurrencies and also among 

cryptocurrencies. This increases arbitrage opportunities and the speculativeness of the market. 

Cryptocurrencies are also commonly thought of as alternative investments, providing a hedge against 

the market (Lee et al., 2018)). Dyhrberg (2016) suggests that cryptos and gold have similar hedging 

capabilities and can be used to hedge against the FTSE index. Chan, Le and Wu (2019) examine the 

hedging capabilities of Bitcoin, and demonstrate that while it does provide a hedge against the market, 

the actual amount of that hedge depends on the index and time period studied. Bouri, Gupta and Vo 

(2020) show that various cryptocurrencies respond to geopolitical risk, and during periods of heightened 

geopolitical uncertainty, investors can move to Bitcoin as a shelter. In regions prone to political 

instability and hyperinflation, cryptocurrencies are being adopted as the currency of choice for payroll 

and payments.  

 

When the trust in the financial system is low, the demand for cryptocurrencies increases, leading to 

higher prices. In 2015, with harsh capital controls restricting the flow of bank deposits, Greeks were 

looking to turn physical cash into stores of value. That change in perception that fiat currency was not 

as reliable as previously thought, enticed a rally of 37% in bitcoin price with the thesis that bitcoin was 

a store of value, could be purchased with cash and had similar properties to money.  

 



8 

In another episode during the 2018 Venezuela hyperinflation, the volume of transactions increased with 

many crypto exchanges, crypto wallet and gift cards. Aid flowed in via alternative crypto payment 

system. Though the actual size relative to the population of both countries are small, it still attracted the 

attention of international organisations in viewing underlying technology, not necessarily 

cryptocurrency, to be of benefits during a financial crisis caused by a loss of confidence or trust. Clearly, 

the collapse in the Letter of Credit services among banks during the 2008 Global Financial Crisis that 

led to more than 30pc drop in international trade disrupting the supply chain is still fresh in the central 

bankers’ mind. 

 

Another determinant of a cryptocurrency’s demand is its utility. Bitcoin’s main utility is for payments 

(and its use to pay for transaction fees), other cryptocurrencies like Ethereum are used to fuel the 

processing of smart contracts. Blockchain networks with well-defined use cases (such as supply chain) 

can provide strong utility for its cryptocurrency, forming a strong internal demand which supports the 

cryptocurrency price and makes it more stable. Supply-demand fundamentals such as the total number 

of bitcoins and the number of unique bitcoin addresses used per day have a significant impact on bitcoin 

price (Ciaian, Rajcaniova & Kancs, 2016). Cryptocurrency prices could also be determined by its cost 

of production. As found in Hayes (2016) & Hayes (2019), the marginal cost of production (mining and 

consumption of electric power) plays an important role in explaining bitcoin prices. The pricing model 

leads us to expect that during periods of excess demand (aka a price bubble), either the market price 

will fall and/or the mining difficulty will increase to resolve the discrepancy. 

 

Market sentiment about the cryptocurrency and its associated blockchain networks also play a role. The 

trustworthiness of the cryptocurrency’s blockchain and the adoption of the blockchain drive prices in 

the long run (using data for five major cryptocurrencies) (Bhambhwani, Delikouras, & Korniotis, 2019). 

Bitcoin returns were found to be driven primarily by its popularity (Google search & number of 

newspaper articles), the sentiment (tone) expressed in newspaper reports on the cryptocurrency, and the 

total number of transactions (Polasik et al., 2015). 

 

Incentives, social scalability9, consensus, utility, and governance of the network have deep implications 

on the price of a cryptocurrency. When designing a cryptocurrency, one needs to consider the purpose 

of the coin and what best fits that purpose. Every choice can affect the volatility of the cryptocurrency 

 
9 According to Szabo (2017), “Social scalability is about the ways and extents to which participants can think 

about and respond to institutions and fellow participants as the variety and numbers of participants in those 

institutions or relationships grow.  It's about human limitations, not about technological limitations or physical 

resource constraints. One way to estimate the social scalability of an institutional technology is by the number 

of people who can beneficially participate in the institution. Another way to estimate social scalability is by the 

extra benefits and harms an institution bestows or imposes on participants, before, for cognitive or behavioral 

reasons, the expected costs and other harms of participating in an institution grow faster than its benefits.” 



9 

price. One may argue that private entities (designing and creating the coin) may not have interests that 

are aligned to the users of the coin. Lai and Lee (2018) described the design thinking, tradeoffs and 

implementation and adoption of a blockchain system. 

 

For example, the issues in the Bitcoin blockchain sparkles lots of discussions. In fact, over the decade 

since the Satoshi paper in 2008, various schools of thought have emerged in the cryptocurrency and 

blockchain space. These range from the Bitcoin purists to believers of the Permissioned Enterprise 

Blockchain10. However, we also see a convergence in these schools, as experimentations with different 

applications reveal certain requirements. Hybrid solutions are a key emerging trend in blockchain 

applications where permissioned blockchain networks rely on a large public blockchain to provide data 

immutability and security. Many now agree that there will be multiple blockchain networks in operation 

and the ability to interoperate is key for a blockchain-based world. These requirements also prompted 

technology to evolve in an attempt to address the problems with the original Bitcoin design. The main 

issues with the technology revolve around scalability, interoperability and privacy. Projects such as 

Ethereum 2.0, EOS, Hedera Hashgraph, Zcash and Monero (just to name a few) aim to address these 

issues. 

 

DeFi (or Decentralized Finance) is an emerging trend in blockchain/fintech, and the term was coined to 

refer to the class of tools and applications built on blockchain to facilitate a financial ecosystem. DeFi 

tools can come in the form of digital assets, protocols, smart contracts, and dApps (decentralised 

applications). Applications can be found in the area of asset tokenisation, stablecoins, decentralised 

exchanges, alternative savings, lending and payments, and more. The aim of DeFi is to create an open 

financial ecosystem where one can build financial tools and services on top of this ecosystem by 

combining, modifying and integrating current applications. Cryptocurrencies will facilitate the DeFi 

ecosystem, and this will have implications on the real-world economy as the applications grow.  

 

However, at the current stage of maturity in the industry, real-world use cases have yet to see mass 

adoption beyond spurts of financial speculation and fundraising activities such as token creations, Initial 

Token Offerings (ITO) 11 , DAOs and DAICOs 12  using smart contracts. Many of these adoptions 

 
10 What sets enterprise blockchains apart from public blockchains is the permission required to participate in the 

network and interact with it. Unlike Open Blockchain, a node must be specifically permissioned to join the 

Permissioned Enterprise Blockchain. 
11 Includes Initial Crypto-Token Offering (ICO), Initial Exchange Offering (IEO), Security Token Offering 

(STO), Initial Mining Offering (IMO). 
12 DAICO is a word association between the Decentralized Autonomous Organization (DAO) and the Initial 

Coin Offerings (ICO). A DAICO puts in place more stringent management rules and constraints for ICO 

projects to avoid certain risks for investors. 



10 

eventually led to frauds, scams and bugs that dampened the initial enthusiasm, clogging of the network, 

and with colossal volatility measured in fiat currency13.  

 

This also makes the original intended use case of payments infeasible, and to address this a solution 

generally known as stable coins has been proposed by the industry. For example, Berentsen and Schär 

(2019) discuss crypto-assets that are developed with the aim of minimising price volatility by 

embedding a stability mechanism. In general, three methods are now used to create stable coins: Fiat-

collateralized, crypto-collateralised and non-collateralized. Fiat-collateralised stable coins refer to 

asset-backed tokens. These assets such as fiat currency or precious metals need to be centrally held and 

managed by a trusted authority. Custodian costs would be incurred in this situation and there is a need 

for regular audits to ensure full collateralisation. There are two modes of fiat-collateralisation. The first 

is single asset-backed, this is usually in the form of currencies like the USD or gold. This means that 

the operational costs cannot be recovered from asset appreciation and needs to be provided through 

other means. The second is multi asset-backed, this is usually a basket of interest-bearing assets that are 

selected to cover the operational costs. These assets will need to be managed by professionals, which 

leads to a further increase in costs. Crypto-collateralised stable tokens are backed by another 

cryptocurrency. To handle the volatility of the cryptocurrency, usually this type of coin is over-

collateralised. This requires the collateralising cryptocurrency to maintain a certain value and also 

creates a large opportunity cost to the issuer. Non-collateralized stable coins generally use algorithms 

(smart contracts) to manage the supply of the token (by issuing or destroying coins) which in turn keeps 

the price stable. Al-Naji, Chen and Diao (2017) show how Basis, an algorithmic stablecoin, actually 

implements price stability using expansion and contraction in its three-token system. This is similar to 

central bank operations but decentralised. There must be perceived value and a demand-side for such 

methods to work.  

 

The methods mentioned are used by private entities for the issuance of stable coins. A derivative of Fiat 

is Libra Coin to be created by Facebook-led project involving 100 Libra Association members14. Libra 

has proposed to create a stable coin backed by a basket of currencies in its initial proposal and floated 

the idea of single-currency-backed Libra in the revised white paper15. Governments have also been 

exploring the possibility of issuing similar digital currencies - these are also known as Central Bank 

Digital Currencies or CBDC.  

  

 
13 In the crypto economy, volatility and stability can be measured using a benchmark based on highly traded 

cryptocurrencies such as bitcoin and ether, rather than fiat currencies. 
14 Libra White Paper retrieved from https://libra.org/en-US/white-paper/   
15 A white paper in cryptocurrency is a document which includes an outline of a problem that the project is 

seeking to solve, the solution to that problem as well as a detailed description of their product, its architecture 

and its interaction with users. 

https://libra.org/en-US/white-paper/


11 

Cryptocurrencies are usually deployed on open and public networks where anyone can join as a node 

on the network. These networks are also known as permissionless, as no permission is required to join. 

In such networks, specially designed incentive mechanisms in the form of consensus protocols such as 

Proof of Work are required as the network participants are not trusted (or known). Permissioned 

blockchain networks on the other hand are controlled, and only known parties that are given permission 

can join the network. Every participant in this sort of network needs to be trusted and agree on the 

governance of the network. This sort of network is a popular choice for CBDC. The central bank can 

have control over the supply and the parties that form the network. Thus, one can manage monetary and 

government policies using CBDCs and this will be explored next.  

 

2.3. Monetary policy considerations in the presence of non-sovereign cryptocurrencies 

 

As cryptocurrencies creep into everyday life and are used for digital payments, governments inevitably 

need to consider how it would affect the circulation of central bank issued money and the effectiveness 

of monetary policy. Money has existed in digital or electronic form for a few decades now, and those 

technologies have not reduced the effectiveness of monetary policy. Would cryptocurrencies be any 

different? 

 

The main difference to note is that a cryptocurrency has its own price and can be used in replacement 

of a national currency. Oh (2018) suggests that if a new cryptocurrency becomes commonly used in a 

country, it can cause a rise in the money supply, a fall in the interest rate and an overall rise in the 

exchange rate. Cryptocurrencies have demonstrated their potential for capital mobility in countries with 

capital restrictions, thus providing a cheap currency substitute. Relatively stable currencies such as the 

USD, JPY and CHF have been traditionally used as a currency substitute, and cryptocurrencies now 

present an alternative. Engel (2019) presents a framework for foreign exchange to examine the impact 

of the cryptocurrencies. In the paper, Engel suggests that the digital currency market is not a major 

concern for monetary policy currently as their holdings are small relative to other forms of liquid assets 

(in August, 2019, the market capitalisation of digital currencies was approximately $260 billion, which 

by comparison is less than 2 per cent of U.S. Treasury debt held by the public). He also discusses the 

problem of currency substitution and where consumer prices are set in the new currency, and 

transactions that take place using";"""date"",""2020-05-23T13:56:22Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.7""
""xmp:CreatorTool"",""MicrosoftÂŽ Word for Microsoft 365""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""language"",""en""
""dcterms:created"",""2020-05-23T13:56:22Z""
""Last-Modified"",""2020-05-23T13:56:22Z""
""dcterms:modified"",""2020-05-23T13:56:22Z""
""dc:format"",""application/pdf; version=1.7""
""xmpMM:DocumentID"",""uuid:60119C65-3CD8-488E-8CF1-060BFE1B32B1""
""Last-Save-Date"",""2020-05-23T13:56:22Z""
""pdf:docinfo:creator_tool"",""MicrosoftÂŽ Word for Microsoft 365""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2020-05-23T13:56:22Z""
""meta:save-date"",""2020-05-23T13:56:22Z""
""pdf:encrypted"",""false""
""xmp:CreateDate"",""2020-05-23T21:56:22Z""
""modified"",""2020-05-23T13:56:22Z""
""Content-Length"",""876476""
""pdf:hasMarkedContent"",""true""
""Content-Type"",""application/pdf""
""xmp:ModifyDate"",""2020-05-23T21:56:22Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""dc:language"",""en-US""
""pdf:producer"",""MicrosoftÂŽ Word for Microsoft 365""
""meta:creation-date"",""2020-05-23T13:56:22Z""
""created"",""2020-05-23T13:56:22Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""57""
""Creation-Date"",""2020-05-23T13:56:22Z""
""resourceName"",""SSRN-id3608752.pdf""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""1386"",""3141"",""2833"",""2546"",""3232"",""3178"",""2971"",""3506"",""3141"",""3289"",""3157"",""2634"",""3342"",""2803"",""2251"",""2543"",""2934"",""2912"",""3631"",""3151"",""3126"",""3073"",""3043"",""1702"",""1873"",""1138"",""2475"",""2443"",""1490"",""1772"",""2894"",""2685"",""3295"",""2949"",""2631"",""3013"",""3124"",""3049"",""2959"",""3150"",""1146"",""1508"",""1079"",""1140"",""1058"",""702"",""1113"",""1586"",""1573"",""2594"",""1827"",""2356"",""1370"",""2498"",""2689"",""2587"",""823""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""producer"",""MicrosoftÂŽ Word for Microsoft 365""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""MicrosoftÂŽ Word for Microsoft 365""
""pdf:docinfo:created"",""2020-05-23T13:56:22Z""
";https://scholar.google.ch/scholar?start=740&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098888-384;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Separating Symmetric and Asymmetric Password-Authenticated Key Exchange;J Hesse ; International Conference on Security and Cryptography …, 2020  Springer;;"… protocol [15], which was recently selected as recommended asymmetric PAKE protocol by the

Crypto Forum Research Group … Extending Theorem 1 to variants of random oracles. Since in the

above attack the oracle \(\mathcal {O}\) is not queried before \(\mathcal {S} ^\mathcal {O …";Cité 1 fois;Les 3 versions;[PDF] iacr.org;https://eprint.iacr.org/2019/1064.pdf;"
Separating Symmetric and Asymmetric

Password-Authenticated Key Exchange

Julia Hesse

IBM Research, Zurich, Switzerland
jhs@zurich.ibm.com

Abstract

Password-Authenticated Key Exchange (PAKE) is a method to establish cryptographic keys
between two users sharing a low-entropy password. In its asymmetric version, one of the users
acts as a server and only stores some function of the password, e.g., a hash. Upon server compro-
mise, the adversary learns H(pw). Depending on the strength of the password, the attacker now
has to invest more or less work to reconstruct pw from H(pw). Intuitively, asymmetric PAKE
seems more challenging than symmetric PAKE since the latter is not supposed to protect the
password upon compromise. In this paper, we provide three contributions:

• Separating symmetric and asymmetric PAKE. We prove that a strong assumption
like a programmable random oracle is necessary to achieve security of asymmetric PAKE
in the Universal Composability (UC) framework. For symmetric PAKE, programmability
is not required. Our results also rule out the existence of UC-secure asymmetric PAKE in
the CRS model.

• Revising the security definition. We identify and close some gaps in the UC security
definition of 2-party asymmetric PAKE given by Gentry, MacKenzie and Ramzan (Crypto
2006). For this, we specify a natural corruption model for server compromise attacks.
We further remove an undesirable weakness that lets parties wrongly believe in security
of compromised session keys. We demonstrate usefulness by proving that the Ω-method
proposed by Gentry et al. satisfies our new security notion for asymmetric PAKE. To our
knowledge, this is the first formal security proof of the Ω-method in the literature.

• Composable multi-party asymmetric PAKE. We showcase how our revisited security
notion for 2-party asymmetric PAKE can be used to obtain asymmetric PAKE protocols
in the multi-user setting and discuss important aspects for implementing such a protocol.

Keywords: Asymmetric Password-Authenticated Key Exchange, Universal Composability

1 Introduction

Establishing secure communication channels in untrusted environments is an important measure to
ensure privacy, authenticity or integrity on the internet. An important cryptographic building block
for securing channels are key exchange protocols. The exchanged keys can be used to, e.g., encrypt
messages using a symmetric cipher, or to authenticate users. Password-authenticated key exchange
(PAKE), introduced by Bellovin and Merrit [BM92a], is a method to establish cryptographic keys
between two users sharing a password. A PAKE manages to “convert” this possibly low-entropy
password into a random-looking key with high entropy, which is the same for both users if and only
if they both used the same password. What makes these schemes interesting for practice is that
they tie authentication solely to passwords, while other methods such as password-over-TLS involve
more authentication material such as a certificate. The probably most prominent implementation



Reference Type Sec. notion Model

[BPR00] symmetric BPR non-prog. RO
[GL01, KOY01, BCL+11, KV11] symmetric BPR standard

[BP13] asymmetric BPR non-prog. RO & GGM
[PW17] asymmetric BPR GGM

[CHK+05, KV11, BBC+13] symmetric UC standard
[GMR06] asymmetric UC progr. RO

[JR16] asymmetric UC limited progr. RO
[HL18] asymmetric UC progr. RO

[JKX18] asymmetric UC, strong progr. RO
[BJX19] asymmetric UC, strong non-prog. RO & GGM

Table 1: Comparison of static security of different PAKE and aPAKE schemes, where ”strong”
denotes schemes that prevent precomputation of password files (e.g., via precomputing hash tables).
RO means random oracle and GGM means generic group model.

of PAKE is the TLS-SRP ciphersuite (specified in RFCs 2945 and 5054), which is used by GnuTLS,
OpenSSL and Apache.

In most applications, users of a PAKE actually take quite different roles. Namely, some may
act as servers, maintaining sessions with various clients, and storing passwords of clients in a file.
For better security, it seems reasonable to not write the password to the file system in the clear,
but store, e.g., a hash of the password. A PAKE protocol that lets users take the roles of a client
or a server is called asymmetric PAKE (aPAKE) (sometimes also augmented or verifier-based in
the literature). To emphasize that we talk about a PAKE protocol without different roles, we write
symmetric PAKE.

Security of PAKE. Since a password is potentially of low entropy, an attacker can always engage
in a PAKE execution with another user by just trying a password, resulting in key agreement with
non-negligible probability. Such an attack is called an on-line dictionary attack since the attacker
only has one password guess per run of the protocol. A security requirement for symmetric PAKE is
that an on-line dictionary attack is the “worst the adversary can do”. Especially, the attacker should
not be able to mount off-line dictionary attacks on the password, e.g., by deriving information about
the password by just looking at the transcript. For an asymmetric PAKE, we can require more:
if an attacker gets his hands on a password file, in which case the server is called compromised,
the attacker should not learn the password directly. At least, some computation such as hashing
password guesses is required.

Is asymmetric PAKE harder than symmetric PAKE? Intuitively, asymmetric PAKE seems
more challenging than symmetric PAKE, since asymmetric PAKE protocols provide a guarantee
on top: they are supposed to protect passwords whenever the storage of a server is leaked to the
adversary. This claim has evidence in the literature: there are symmetric PAKE schemes that are
BPR-secure (BPR is the most widely used game-based notion for PAKE, introduced by Bellare
et al. [BPR00]) in the standard model, while current aPAKE schemes satisfying the asymmetric
variant of BPR security are only proven in an idealized model such as the non-programmable
random oracle or the generic group model. The situation is similar when considering PAKE/aPAKE
in the Universal Composability (UC) framework of Canetti [Can01]. UC-secure PAKE protocols
exist in the non-programmable random oracle model and even in the standard model, while proofs
of current aPAKE schemes additionally rely on some form of programmability of the random oracle
or the generic group model (GGM). See Table 1 for a comparison.

To our knowledge, in none of the aforementioned models there exist any formal proof of asym-
metric PAKE being harder to achieve than symmetric PAKE. A close look at Table 1 reveals that
the “gap” in the assumption is much bigger in case of UC security. Can we make this gap as small

2



as for BPR secure schemes? For sure we would like to answer this question in the affirmative, since
for asymmetric PAKE, UC-security has two notable advantages over BPR security: it comes with
a composability guarantee, and it considers adversarially-chosen passwords.

1.1 Our Contributions

In this paper, we rule out the existence of UC-secure aPAKE protocols from assumptions that are
enough to obtain (even adaptively) UC-secure symmetric PAKE. Namely, we show that aPAKE
is impossible to achieve w.r.t a non-programmable random oracle. To our knowledge, this is the
first formal evidence that universally composable asymmetric PAKE is harder to achieve than
symmetric PAKE. Interestingly, our impossibility result directly extends to a setting where parties,
additionally to the non-programmable random oracle, have access to a common reference string
(CRS). Although such a CRS offers a limited form of programmability, we can show that this is
not enough to obtain UC-secure asymmetric PAKE.

In preparation of this formal result, and as a separate contribution, we revisit the ideal function-
ality FapwKE for asymmetric PAKE of Gentry, MacKenzie and Ramzan [GMR06]. Our changes
summarize as follows:

• We show that FapwKE is not realizable due to an incorrect modeling of server compromise
attacks. We fix this by formally viewing server compromise as partial corruption of the
server. This was already proposed but not enforced by Gentry et al. [GMR06].

• We show that FapwKE allows attacks on explicit authentication. In a PAKE protocol with
explicit authentication, parties are informed whether the other party held the same password
and thus computed the same session key. However, FapwKE allows the adversary to make
parties believe in the security of adversarially chosen session keys. This is clearly devastating
for applications such as secure channels. In our revisited functionality FaPAKE we exclude
such attacks by introducing a proper modeling of explicit authentication.

We argue plausibility of our revisited functionality FaPAKE by showing that it is realized by an
asymmetric PAKE protocol called the Ω-method, introduced by Gentry et al. [GMR06]. To our
knowledge, this is the first proof of security of the Ω-method in the literature. Not surprisingly, the
original publication of the Ω-method did not include a proof but only a claim of security, which is
invalidated with our findings of their functionality being impossible to realize. Finally, we showcase
how our 2-party functionality FaPAKE can be used to obtain multi-user asymmetric PAKE protocols.
We highlight a specific artifact of UC-security that has to be considered when implementing such
a scheme. Let us now explain our results in more detail.

Separating symmetric and asymmetric PAKE. As already mentioned, asymmetric PAKE
protocols are supposed to provide some protection of the password in case of a server compromise.
Essentially, in case of a security breach where account data of users are leaked to the adversary,
we want that the adversary does not obtain all user passwords in the clear. Formally, this attack
is modeled via a partial leakage of the internal state of the server who already stored the user’s
account data. The adversary is however not allowed to control the behaviour of the compromised
server, which distinguishes compromising a server from corrupting a server. Nevertheless, a server
compromise allows the attacker to mount an adaptive attack.

In simulation-based security notions such as ones stated in the UC model, adaptive attacks often
impose a problem. Such problems are often referred to as “commitment problem”: they require the
simulator to explain how, e.g., a transcript that he committed to in the beginning of the protocol
matches certain secrets of honest participants that are revealed only later. The first mentioning of
such a commitment problem is the work of Nielsen [Nie02], who showed that a non-programmable

3



random oracle (NPRO) is not enough to obtain non-committing encryption. One contribution of
the paper is to formalize non-programmable random oracles. In a nutshell, an NPRO is modeled as
an external oracle that informs the adversary about all queries, but chooses values truly at random,
especially not letting the adversary in any way influence the outputs of the oracle.

Inspired by the work of Nielsen, we obtain the following result: UC-secure asymmetric PAKE
is impossible to achieve in the NPRO model. The intuition is as follows: due to the adaptive
nature of the server compromise attack, the simulator needs to commit to a password file without
knowing the password that the file contains. The attacker can now test whether some password
is contained in the simulated file. Since accessing the external oracle is sufficient to compute this
test, the simulator merely learns the tested password but cannot influence the outcome of the test.

While the result itself is not very surprising, we stress that the techniques to prove it are actually
completely different from the techniques used by Nielsen [Nie02]. For non-committing encryption,
their strategy is to let the simulator commit to “too many” ciphertexts such that there simply
does not exist a secret key of reasonable size to explain all these ciphertexts later. However, in
asymmetric PAKE there exists only one password file at the server. And indeed, there is a bit
more hope for a simulator of asymmetric PAKE to actually find a good password file if he only
guesses the password correctly. Our formal argument thus heavily relies on the fact that, in the
UC model, the simulator does not have an arbitrary amount of runtime to simulate the password
file. We formally prove that, with high probability, he will exhaust before finding a good file.

We further investigate how our proof technique extends to more setup assumptions. We find
that our impossibility result directly extends to the NPRO model where parties can access an ideal
common reference string (CRS). While the CRS can be ”programmed” in the simulation, it does
not resolve the simulator’s commitment issue: neither does usage of the CRS provide the simulator
with any information about the server’s password prior to simulating the file, nor does determining
the CRS let the simulator influence the aforementioned test. We can thus rule out the existence of
UC-secure asymmetric PAKE protocols plain CRS as well as the NPRO+CRS model.

Opposed to our findings for asymmetric PAKE, it is known from the literature that UC-
secure symmetric PAKE can be constructed in the NPRO model and even in the standard model
[ACCP08, CHK+05, KV11, DHP+18]. We note that, while also the NPRO model suffers from the
uninstantiability results of Canetti et al. [CGH98], requiring programmability of a random oracle
is crucially strengthening the model. In a security proof w.r.t an NPRO, the reduction does not
need to determine any output values and thus could use, e.g., a hash function like SHA-3 to answer
random oracle queries. This is not possible for a reduction that makes use of the programmabil-
ity property of the random oracle. Thus, our results indicate that, while going from symmetric
to asymmetric PAKE in the UC model, we are forced to move further away from realistic setup
assumptions.

Modeling server compromise. Towards separating symmetric and asymmetric PAKE, we first
carefully revisit the ideal functionality FapwKE (cf. Figure 1) for asymmetric PAKE of Gentry et
al. [GMR06], which adopts the ideal functionality for symmetric PAKE [CHK+05] to the asym-
metric case. For the reader not familiar with FapwKE, we provide the functionality and a thorough
introduction to it in Appendix C. For providing an overview of our contributions, we first focus on
how server compromise attacks are modeled by FapwKE. After learning about a server compromise
attack, FapwKE enables the adversary to (a) make off-line password guesses against the file and (b)
impersonate the server using the file. FapwKE only allows the adversary to compromise and make
password guesses upon getting instructions from the distinguisher Z.

We show that it is necessary to revisit FapwKE by proving that restricting the adversary to only
submit off-line password guesses upon instructions from Z results in FapwKE being impossible to
realize. By this, we invalidate the claimed security of the Ω-method [GMR06]. We also observe
that putting restrictions such as “only ask query x if Z tells you” on the adversary is not conform

4



with the UC framework and invalidates important properties of the framework such as simulation
with respect to the dummy adversary.

Towards a better modeling, and towards resolving the now-open question which security guar-
antees the Ω-method fulfils, we revisit FapwKE and propose our own ideal functionality FaPAKE. The
changes are as follows: we lift the aforementioned restriction on the adversary regarding off-line
password guesses and argue why the resulting security notion captures what we expect from an
asymmetric PAKE. We further propose a UC-conform modeling of server compromise attacks as
“partial” corruption queries which, in the real execution of the protocol, partly leak the internal
state of an honest party to the adversary (i.e., the password file).

We call our revisited functionality for asymmetric PAKE FaPAKE. It however differs in another
aspect from FapwKE, which we will now explain in more detail.

Modeling explicit authentication. A protocol is said to have explicit authentication if the
parties can learn whether the key agreement was successful or not, in which case they might opt
for, e.g., reporting failure. FapwKE features a TestAbort interface which allows the adversary to
obtain information about the authentication status and also to decide whether parties should abort
if their computed session keys do not match. The idea behind modeling explicit authentication
via an interface that the adversary may or may not decide to use is to keep FapwKE flexible: both
protocols with or without explicit authentication can be proven to realize it. However, we show that
this results in FapwKE providing very weak security guarantees regarding explicit authentication.
One property that a protocol with authentication should have is that parties reliably abort if they
detect authentication failure. However, FapwKE does not enforce this property since the adversary
can simply decide not to use the TestAbort interface. We propose a stronger version of FaPAKE

that enforces explicit authentication within the functionality.
To demonstrate usefulness of our revisited functionality FaPAKE, we show that the Ω-method

UC-realizes it. To our knowledge, this is the first full proof of security for the Ω-method.

From 2-party aPAKE to multi-party aPAKE. FapwKE as well as our FaPAKE are two-party
functionalities running with one client and one server. But realistic scenarios for PAKE comprise
thousands of users and hundreds of servers all using the same protocol to establish secure com-
munication channels or to authenticate clients. This however is usually not a problem: the UC
framework comes with a composition theorem, which allows to instantiate an arbitrary number of
instances of the two-party functionality with its realization. Each client would invoke an instance
of FaPAKE, and a server can participates in arbitrarily many of them. To avoid that all instances
use their “own” setup, which would require a server to use, e.g., a different hash function for each
client, all functionalities could share their setups. This can be achieved by transforming the setup,
e.g., a random oracle FRO to a multi-party functionality F̂RO that acts as a wrapper for multiple
copies of FRO. This approach is widely used and called UC with joint state (JUC) [CR03].

We showcase this transformation to the multi-user setting for the Ω-method. Interestingly, a
client in the multi-user Ω-method is now required to remember which is ”her” copy of the random
oracle. We demonstrate that this does not hinder practicality of the scheme since we can identify
a party’s random oracle by information that this party, in any implementation, has to remember
anyway (e.g., the server’s URL and her own username).

Related work. Canetti et al. [CHK+05] show impossibility of FapwKE in the plain model. Gentry
et al. [GMR06] show how to transform a UC-secure PAKE into a UC-secure asymmetric PAKE
(the opposite direction is trivial). However, as we will show while proving security of their resulting
aPAKE, their transformation seem to require a strong assumption such as a programmable random
oracle. Thus, this does not contradict our separation result.

Assumption-wise, there is a gap between non-programmable and programmable random ora-
cles. Fischlin et al. [FLR+10] introduce models that are in between both: random oracles with

5



“limited programmability”. In a nutshell, such a random oracle allows the adversary to influence
the mapping between queries and outputs, but the outputs are always randomly chosen. As our
proof of security of the Ω-method demonstrates, for aPAKE influencing the mapping is sufficient.
This means that our impossibility result for NPRO cannot be broadened to hold also for random
oracles with limited programmability. And indeed, Jutla and Roy [JR16] propose an aPAKE that
is secure w.r.t a limited programmability random oracle.

Canetti and Krawczyk [CK02] analyze multi-session security of UC-secure key exchange proto-
cols. Similar to us, they apply the JUC composition theorem and methods to leverage single-session
security to multi-party security. However, in their work, a session refers to an exchange of a sin-
gle key, while in UC notions of PAKE a session refers to a pair of users. And indeed, all PAKE
functionalities already enable exchange of multiple keys via the use of subsession identifiers. On
the other hand, PAKE functionalities handle only two users, while the KE functionality treated by
Canetti and Krawczyk [CK02] can deal with many users from the start. While the goal of their and
our work is the same, namely achieving ”multi-party + multi-session” UC security, the starting
points are different.

Roadmap. Section 2 gives details on how to model server compromise as partial corruption and
states our revisited functionality FaPAKE. Section 3 shows our separation result. In Section 4
we use our new model to make a stronger security statement of the Ω-method. In Section 5 we
discuss composable multi-party security of asymmetric PAKE schemes. The appendix recalls ideal
functionalities, gives some technical details of the UC model and contains the full proofs of security.

2 The aPAKE Security Model, revisited

The notion of universally composable asymmetric PAKE was introduced in 2006 by Gentry, MacKen-
zie and Ramzan ([GMR06]). Their two-party functionality FapwKE augments the functionality for
(symmetric) PAKE by Canetti et al. [CHK+05] by adding an interface for server compromise
attacks. The presentation is slightly more involved due to the different roles that the two partic-
ipating users can take in the asymmetric version of PAKE: while the client can initiate multiple
key exchange sessions by providing a fresh password each time, the server has to register a pass-
word file once which is then used in every key exchange session with the client. We recall FapwKE

in Figure 1 and refer the reader not familiar to it to Appendix B for a thorough introduction to
the functionality. To model a server compromise attack, FapwKE provides three interfaces called
StealPwdFile, OfflineTestPwd and Impersonate, which we now describe in more detail.

• StealPwdFile initiates a server compromise attack. The output is a bit, depending on
whether the server already registered a password file or not, and the query can only be made
by the simulator if Z gives the instruction for it.

• OfflineTestPwd enables an off-line dictionary attack: the adversary can test whether some
password is contained in the password file. The answer is a bit, depending on whether the
guess was correct or not. The attack is called “off-line” since it can be mounted by the
adversary without interacting with the client. Like StealPwdFile, this attack can only be
mounted by the simulator if Z instructs him to do so. The adversary gets confirmation on a
correct guess only after a StealPwdFile query happened.

• Impersonate can be used by the adversary after StealPwdFile was issued by Z. This
interface enables the adversary to engage in a key exchange session with the client, using
the stolen password file as authenticating data. This interface is necessary since a server
compromise attack (i.e., StealPwdFile query) does not allow the adversary in any way to
control the behavior of the server. Nonetheless, a network attacker is able to engage in a
session with the client using the stolen password file, which he can do via Impersonate.

6



7

The functionality FapwKE is parameterized with a security parameter Îť. It interacts with an
adversary S, a client PC and a server PS via the following queries:

Password Registration

• On (StorePwdFile, sid,PC , pw) from PS , if this is the first StorePwdFile message,
record (file,PC ,PS , pw) and mark it uncompromised.

Stealing Password Data

• On (StealPwdFile, sid) from S, if there is no record (file,PC ,PS , pw), return “no pass-

word file” to S. Otherwise, if the record is marked uncompromised, mark it compromised;
regardless,
ďż˝ If there is a record (offline, pw), send pw to S.
� Else, return “password file stolen” to S.

• On (OfflineTestPwd, sid, pw′) from S, do:

� If there is a record (file,PC ,PS , pw) marked compromised, do: if pw = pw′, return
“correct guess” to S; else, return “wrong guess”.

� Else, record (offline, pw′).

Password Authentication

• On (UsrSession, sid, ssid,PS , pw′) from PC , send (UsrSession, sid, ssid,PC ,PS) to S. Also,
if this is the first UsrSession message for ssid, record (ssid,PC ,PS , pw′) and mark it fresh.
• On (SrvSession, sid, ssid) from PS , ignore the query if there is no record (file,PC ,PS , pw).

Else send (SrvSession, sid, ssid,PC ,PS) to S and, if this is the first SrvSession message
for ssid, record (ssid,PS ,PC , pw) and mark it fresh.

Active Session Attacks

• On (TestPwd, sid, ssid,P, pw′) from S, if there is a record (ssid,P,P ′, pw) marked fresh, do:
if pw′ = pw, mark it compromised and return “correct guess” to S; else, mark it interrupted
and return “wrong guess” to S.
• On (Impersonate, sid, ssid) from S, if there is a record (ssid,PC ,PS , pw′) marked fresh,

do: if there is a record (file,PC ,PS , pw) marked compromised and pw′ = pw, mark
(ssid,PC ,PS , pw′) compromised and return “correct guess” to S; else, mark it interrupted

and return “wrong guess” to S.

Key Generation and Authentication

• On (NewKey, sid, ssid,P,K) from S where |key| = λ, if there is a record (ssid,P,P ′, pw) not
marked completed, do:
� If the record is marked compromised, or either P or P ′ is corrupted, send (sid, ssid,K)

to P.
� Else, if the record is marked fresh, (sid, ssid,K′) was sent to P ′, and at that time there

was a record (ssid,P ′,P, pw′) marked fresh, send (sid, ssid,K′) to P.

� Else, pick K′′
$← {0, 1}λ and send (sid, ssid,K′′) to P.

Finally, mark (ssid,P,P ′, pw) completed.
• On (TestAbort, sid, ssid,P) from S, if there is a record (ssid,P,P ′, pw) not marked
completed, do:
� If it is marked fresh and record (ssid,P ′,P, pw) exists, send “success” to S.
� Else, send “fail” to S and (abort, sid, ssid) to P, and mark (ssid,P,P ′, pw) completed.

Figure 1: Ideal functionality FapwKE for asymmetric PAKE from [GMR06], but phrased as in
[JKX18] with slight notational changes to avoid confusion between the adversary (S) and server

(PS). Framed queries can only be asked upon getting instructions from Z.



Definitional issues with StealPwdFile and OfflineTestPwd interfaces of FapwKE.
Let us make two observations about these interfaces. Firstly, the restriction of letting the adversary
ask specific queries only upon receiving them from Z constitutes a change of the UC framework
(Gentry et al. [GMR06] propose to change the control function of the UC framework to enforce it).
This needs to be done carefully to not invalidate important properties of the framework such as
the composition theorem and emulation w.r.t the dummy adversary. Without further restrictions,
at least the latter does not hold anymore. To provide an example, consider an environment Z
that asks an “encoded” StealPwdFile query, e.g., (ask-StealPwdFile-query, sid) and sends it
to the adversary. A real-world adversary A can easily decode this query and perform the desired
attack, while the simulator in the ideal world cannot accomplish the corruption at FaPAKE due to
the wrong message format. This way, Z can keep the simulator from using his interfaces, leaving
him with no leverage to presume his simulation. Clearly, such an ”intelligent” real-world adversary
is worse than a dummy adversary, who would just relay the message without any effect. To get a
meaningful definition that inherits all properties of the UC framework, such environments would
have to be excluded.

Our second observation concerns the real execution of the protocol, where A obtains StealP-
wdFile and OfflineTestPwd queries from Z. Gentry et al. [GMR06] assume that A now
mounts a server-compromise attack and does not behave as the dummy adversary, as usually as-
sumed in the UC framework (see [Can20], Section 4.3.1). Let us explain why this underspecification
is problematic. In the UC framework, the real-world adversary A only has influence on the com-
munication channel and corrupted parties, and none of this helps him to steal a password file from
the server. For analyzing UC security of a protocol with respect to FapwKE, it is however crucial to
formally specify the outputs of A upon these queries, since A’s output has to be simulated by S.
This requirement of adding explanation of the real-world adversary A to obtain a security notion
usually does not occur in the UC framework as long as Z does not expect meaningful output from
queries other than (a) modifying/introducing messages on communication tapes or (b) acting on
behalf of corrupted parties and (c) messages to hybrid ideal functionalities (such as FRO used in
this paper) that Z accesses through A. The StealPwdFile and OfflineTestPwd queries are
not of any of these three types.

2.1 Fix no.1: Defining the Corruption Model

To address the aforementioned issues, we first define server compromise to be party corruption.
This possibility was already pointed out by Gentry et al. [GMR06]. Modeling server compromise
via corruption offers the following advantages:

• It captures the intuition that compromising the server, like Byzantine party corruption, con-
stitutes an attack that the environment Z can mount to distinguish real and ideal execution.

• It takes care of definitional issues by using the special properties of corruption queries in UC,
e.g., that they can only be asked by S and A if Z instructs them to do so. As a consequence,
there is no need to adjust the control function or to put restrictions on the environment, nor
to consider adversaries other than the dummy adversary.

• It lets us flexibly define the effect of server compromise in the real world w.r.t internal state of
the server. For example, one can choose whether upon compromising the server the adversary
merely learns that a password file exists or even leak the whole file to him. We note that this
leads to a UC-conform modeling since arbitrary corruption models can be integrated into the
UC framework (cf. [Can20], section 7.1).

Formally, besides Byzantine party corruption that is usually modeled via a query (corrupt,P, sid)
from Z to A, we allow Z to issue an additional corruption query (StealPwdFile, sid). To for-

8



malize what happens upon this query in the ideal world, we adopt the conventions for corruption
queries from the UC framework [Can20] (cf. Section 7.1) and let dummy parties in the ideal world
ignore corruption messages. Instead, these queries are handeled by the ideal functionality, who
receives them directly from S. We now detail the effect of the two types of corruption queries that
we allow Z to ask.

Byzantine corruption
Real world: Upon receiving a message (corrupt,P, sid) from Z, A delivers the message to P
who immediately sends its internal state to A and, from that point on, is completely controlled by
A.
Ideal world: Upon receiving a message (corrupt,P, sid) from Z, S delivers the message to
FapwKE, who marks P as corrupted. If FapwKE already received input from P or sent output to it,
it sends all these values to S. FapwKE further notifies S of all future inputs and outputs of P and
lets S modify P’s input values.

Server compromise
Real world: Let f : {0, 1}∗ → {0, 1}∗ be an efficiently computable function. We denote the
internal state of PS with state, consisting of all messages received by and sent to the server ITI,
its random coins and current program’s state. Upon receiving a message (StealPwdFile, sid)
from Z, A delivers the message to PS , who immediately sends f(state) to A. This definition of
corruption resembles what Canetti [Can20] describes as physical “side channel” attacks since it
results in leaking a function of the internal state of a party. A natural choice is f(state) = file, with
file being the variable in the server’s code storing the password file, which we will use in this work.
Ideal world: Upon (StealPwdFile, sid) from Z, S sends this message to FapwKE. FapwKE marks
PS as compromised. If there are records (file,PC ,PS , pw) (”ser";"""date"",""2020-04-16T21:55:41Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2020-04-16T21:55:41Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is MiKTeX-pdfTeX 2.9.7029 (1.40.20)""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2020-04-16T21:55:41Z""
""created"",""2020-04-16T21:55:41Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-04-16T21:55:41Z""
""resourceName"",""1064.pdf""
""Author"",""""
""producer"",""pdfTeX-1.40.20""
""pdf:docinfo:producer"",""pdfTeX-1.40.20""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""35"",""0"",""0"",""0"",""34"",""0"",""2"",""0"",""34"",""0"",""0"",""0"",""0"",""1"",""0"",""0"",""0"",""2"",""26"",""0"",""4"",""10"",""11"",""14"",""25"",""3"",""3"",""7"",""4"",""5"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2020-04-16T21:55:41Z""
""Last-Modified"",""2020-04-16T21:55:41Z""
""dcterms:modified"",""2020-04-16T21:55:41Z""
""title"",""""
""Last-Save-Date"",""2020-04-16T21:55:41Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2020-04-16T21:55:41Z""
""meta:save-date"",""2020-04-16T21:55:41Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is MiKTeX-pdfTeX 2.9.7029 (1.40.20)""
""Content-Length"",""668496""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""37""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""2595"",""3067"",""3328"",""3786"",""3675"",""3399"",""2357"",""3371"",""3246"",""3515"",""2342"",""3483"",""3281"",""3349"",""1551"",""3154"",""3575"",""2628"",""3068"",""2865"",""2369"",""2500"",""2791"",""2410"",""2036"",""3742"",""2983"",""3178"",""1388"",""2873"",""2798"",""2889"",""3078"",""2018"",""1217"",""2270"",""1510""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-04-16T21:55:41Z""
";https://scholar.google.ch/scholar?start=930&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098892-397;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;[PDF][PDF] artikel ICIC;FN Khasanah ; repository.ubharajaya.ac.id;;"… Noriaki Kamiyama 259-266 Converging Artificial Intelligence and Blockchain

Technology using Oracle Contract in Ethereum Blockchain Platform 38 Richard,

Mahenda Metta Surya, Avenia Clarissa Wibowo 267-272 The Role …";Autres articles;;[PDF] ubharajaya.ac.id;http://repository.ubharajaya.ac.id/6416/1/Paper%20ICIC-Fata%20Nidaul%20Khasanah.pdf;"
APTIKOM

The 5th International Conference
on Informatics and Computing (ICIC) 2020 81

INDONESIA SECTION

NOVEMBER 3 - 4, 2020

o
https:l/icic-aptikom.org/2020/



ii 

2020 Fifth International Conference on 
Informatics and Computing (ICIC) 

 

Jakarta, Indonesia  

(Virtual Conference) 

 
 

November 3-4, 2020 
 
 
 
 
 

 
 
 
 
 
 
 
 
 



iii 

 

2020 Fifth International Conference on Informatics 
and Computing (ICIC) 
 
 
Jakarta, Indonesia (Virtual)  

Phone: +6281384175979 

Email: contact@icic-aptikom.org 

Website: https://icic-aptikom.org 

November 3-4, 2020 
 
 
 
 
 
 
 

 



iv 

 
 

2020 Fifth International Conference on Informatics 
and Computing (ICIC) 
 
Copyright Š2020 by the Institute of Electrical and Electronics Engineers, Inc. All rights 

reserved. 

 

Copyright and Reprint Permission 

Abstracting is permitted with credit to the source. Libraries are permitted to photocopy beyond 

the limit of U.S. copyright law, for private use of patrons, those articles in this volume that carry 

a code at the bottom of the first page, provided that the per-copy fee indicated in the code is 

paid through the Copyright Clearance Center, 222 Rosewood Drive, Danvers, MA 01923. 

 

Other copying, reprint, or reproduction requests should be addressed to IEEE Copyrights 

Manager, IEEE Service Center, 445 Hoes Lane, P.O. Box 1331, Piscataway, NJ 08855-1331. 

 

 

 

Additional copies of this publication are available from 

Curran Associates, Inc. 

57 Morehouse Lane 

Red Hook, NY 12571 USA 

+1 845 758 0400 

+1 845 758 2633 (FAX) 



v 
 

PREFACE 
 
 

It is my great pleasure to warmly welcome you to the Fifth International 
Conference on Informatics and Computing (ICIC 2020) held for the first time, 
ONLINE. The ICIC is a conference series which is conducted annually by 
APTIKOM, the Indonesian Association of Higher Education in Informatics and 
Computing. This year the main theme of the conference is “Towards Smart 
Society 5.0 Through Accelerating Digital Transformation Using Pervasive 
Technology in Industrial Revolution 4.0”, with an intension to bring up more 
awareness in our society on the importance of pervasive technology in the 
current era and beyond. 

The ICIC conference series as a flagship conference of APTIKOM serves as an arena for academicians 
and their students, experts and practitioners from the industry to meet, present, and have fruitful 
discussions on their research works, ideas, and papers in the wide areas of Computing which covers 
Computer Science, Information Systems, Information Technology, Software Engineering, and 
Computer Engineering. The conference is set to provide opportunities for participants from both 
academia and industry to share and exchange knowledge as well as the cutting-edge development in 
the computing field. It is expected that the ICIC participants will be able to take away new thinking 
and horizon from this conferential meeting to further their works in the area. 

Initially, ICIC2020 would be held in Last October offline in beautiful city of GORONTALO.  However, 
due to Pandemic Covid-19. After getting approval from IEEE HQ, this conference has been rescheduled 
in this November today n by tomorrow (3-4 November 2020) by VIRTUAL Conference, and it is a part 
of Annual Coordination Meeting (RAKORNAS) of APTIKOM 

There are 246 papers submission and only 127 papers are accepted which is around 52% 
acceptance rate only. The accepted papers will be presented in one of the 6 regular parallel and tracks 
sessions and will be published in the conference proceedings volume. The diversity of authors come 
from 6 different countries.  

All accepted papers are submitted to IEEE Xplore. IEEE Conference Number: #50835. Catalog 
Number: CFP20G52-ART, ISBN: 978-1-7281-8047-2. 

On behalf of the ICIC 2020 organizers, we wish to extend our warm welcome and would like to 
thank for all Keynote Speakers, Reviewers, Authors, and Committees, for their effort, guidance, 
contribution and valuable support. We would like to also extend our gratitude to IEEE Indonesia 
Section for technically co-sponsored this event. 

I wish you all a most wonderful, enjoyable, and productive conference in this ICIC 2020. 

Thank you. 

Wa billahi taufiq wal hidaayah.  
Wallahul muwaffiq ila aqwamit-tharieq.  
Wasalaamu ‘alaykum warahmatullahi wabarakaatuh. 

 

Yusuf Durachman 

General Organizing Chair 

 



vi 
 

THE REVIEWER OF ICIC 2020 
 

 

Achmad Nizar Hidayanto, University of Indonesia 

Retantyo Wardoyo, Universitas Gadjah Mada 

Yusuf Durachman, Syarif Hidayatullah State Islamic University Jakarta 

Didi Rosiyadi, Indonesian Institute of Sciences 

Husni Teja Sukmana, Syarif Hidayatullah State Islamic University Jakarta 

Bambang Krismono, Bumigora University 

Joko Santoso, University of Atma Jaya Yogyakarta 

Budi Irmawati, Nara Institute Science of Technology 

Leon Andretti Abdillah, Bina Darma University 

Dwiza Riana, STMIK Nusa Mandiri 

Doni Purnama Alamsyah, Bina Nusantara University 

Dian Syafitri, Bumigora University 

Ismail Khalil, Johannes Kepler University, Linz, Austria  

Eri Prasetyo, Gunadarma University 

Rahmadya Handayanto, Universitas Islam 45 

Aries Susanto, Syarif Hidayatullah State Islamic University Jakarta 

Yana Aditia Gerhana, UIN Sunan Gunung Djati Bandung 

Indra Budi, University of Indonesia 

Widya Cholil, Universitas Bina Darma 

Dedy Syamsuar, Universitas Bina Darma 

Mohammad Syafrullah, Universitas Budi Luhur 

Untung Rahardja, Universitas Raharja 

Amil Ahmad Ilham, Hasanuddin University 

Ahmad Nurul Fajar, Bina Nusantara University 

Norhaslinda Kamaruddin, MARA University of Technology, Malaysia 

Andrew Tanny Liem, Universitas Klabat 

Syaifuddin Dr., STIE Sebelas April 



vii 
 

Achmad Benny Mutiara, Gunadarma University 

Muhammad Izman Herdiansyah, Universitas Bina Darma 

Said Hasibuan, IBI Darmajaya 

Robby Kurniawan Harahap, Gunadarma University 

Lintang Yuniar Banowosari, Gunadarma University 

Meyliana Meyliana, Bina Nusantara University 

Edi Surya Negara, Universitas Bina Darma 

Henderi Henderi, Universitas Raharja 

Tri Handhika, Gunadarma University 

Abdullah Alkalbani University of Buraimi, Sultanate of Oman  

Bharanidharan Shanmugam, University of Darwin, Australia 

Mohammad Iqbal, Universite de Bourgogne, France 

Sunny Arief, STMIK Jakarta STI&K 

 Ernastuti, Gunadarma University 

Prihandoko Prihandoko, Universitas Gunadarma 

Sandy Kosasi, STMIK Pontianak 

Taqwa Hariguna, STMIK AMIKOM Purwokerto 

Dedi Iskandar Inan, University of Technology, Sydney 

Sarif Madenda, Gunadarma University 

Cecilia Nugraheni, Parahyangan Catholic University 

Andree E. Widjaja, Universitas Pelita Harapan 

Okfalisa Okfalisa, UIN Suska, Riau 

Rizal Munadi, Syiah Kuala University 

Nashrul Hakiem, Universitas Islam Negeri Syarif Hidayatullah 

Sardjoeni Moedjiono, Universitas Budi Luhur 

Paulus Insap Santosa, Gadjah Mada University 

Darmawan Napitupulu, University of Indonesia 

Muhammad Yusuf, University of Trunojoyo, Madura 

Tri Kuntoro Priyambodo, Universitas Gadjah Mada 

M. Agni Catur Bhakti, Sampoerna University 



viii 
 

Tubagus Maulana, Universitas Gunadarma 

Mochamad Wahyudi, BSI University 

Friska Natalia, Universitas Multimedia Nusantara 

Wendi Usino, Universitas Budi Luhur 

Dyah Susilowati, Universitas Bumigora 

 

 

 



ix 
 

 TABLE OF CONTENT 
 

 FRONT MATTER ii-iv 

 PREFACE v 

 LIST OF REVIEWER vi-viii 

 TABLE OF CONTENT ix-xix 

 Energy Efficient Routing Protocol AOMDV  on MANET (Mobile Ad-Hoc Network) with 
Malicious Node 

 

1 Siti Ummi Masruroh, Angga Zain Sauqy Perdana, Hendra Bayu Suseno, Andrew 
Fiade, Dewi Khairani, Husni Teja Sukmana 

1-5

  
 City Health Prediction Model Using Random Forest Classification Method 
2 Prihandoko Prihandoko, Bertalya Bertalya, Lilis Setyowati 6-11
  
 Segmentation for embryonated Egg Images Detection using the K-means Algorithm 

in Image Processing 
3 Shoffan Saifullah 12-19
  
 Minimizing Toll Payment Queue using GPS-Based Mobile Applications 
4 Danang Dismantoro, Istas Pratomo, Surya Sumpeno 20-27

  
 An Evaluation of Internet Addiction Test (IAT) 
5 Heru Nugroho, Maria Irmina, Rini Wijayanti 28-34

  
 Handling of Mathematical Expression on Latin-to-Balinese Script Transliteration 

Method on Mobile Computing 
6 Gede Indrawan, Gede Rasben Dantes, Kadek Yota Ernanda Aryanto, I Ketut 

Paramarta 
35-40

  
 Case-Based Reasoning System to Determine the Types of Fish Farming Based on 

Water Quality 
7 Hindayati Mustafidah, Suwarsito, Ekky Puspitasari 41-46

  
 Design and Implementation of Work Training Certificate Verification Based On 

Public Blockchain Platform 
8 Irawan Afrianto, Yayan Heryanto 47-55

  
 Study and Research on the Identification of the Leaves of Indonesian Herbal 

Medicines Using Manhattan Distance and Neural Network Algorithms 
9 Trinugi Wira Harjanti, Sarifuddin Madenda, Johan Harlan, Lussiana E.T.P 56-62

  
 The Best Classification Algorithm for Identification Beef Quality Based on Marbling 



x 
 

10 Hanny Hikmayanti Handayani, Sarifuddin Madenda, Eri Prasetyo Wibowo, Tubagus 
Maulana Kusuma, Sigit Widiyanto, Anis Fitri Nur Masruriyah

63-67

  
 Sentiment Analysis of Indonesian Movie Trailer on YouTube Using Delta TF-IDF 

and SVM 
11 Muhammad Alkaff, Andreyan Rizky Baskara, Yohanes Hendro Wicaksono 68-73
  
 Health Information Adoption Influencing Factors in Social Online Community 

12 Ave Adriana Pinem, Achmad Nizar Hidayanto, Awalia Mitha Syaninda, Ernest 
Anderson, Hera Mentari Putri, Yudistira Ramadhan, Rahmat Mustafa Samik Ibrahim

74-80

  
 Does System based on Artificial Intelligence need Software Engineering Method? 

Systematic Review 
13 Irdina Wanda Syahputri, Ridi Ferdiana, Sri Suning Kusumawardani 81-87
  
 An Improvement of LED Lighting System Accuracy With Voltage Control System

14 Maman Abdurohman, Ramdhan Nugraha, Aji Gautama Putrada 88-93
  
 Webqual and Importance Performance Analysis Method: The Evaluation of Tegal 

City's Public Service Information System Web Quality 
15 Warjiyono Warjiyono, Amin Nur Rais, Fandhilah Fandhilah, Wati Erawati, Nurdiana 

Handayani, Hendra Mayatopani 
94-101

  
 Mobile-based Smart District Holistic Values And Social Dimensions: a Citizen-

centric Perspective 
16 Aang Kisnu Darmawan, Daniel Oranova Siahaan, Tony Dwi Susanto, Hoiriyah, Busro 

Akramul Umam, Miftahul Walid, Betty Dewi Puspasari, A’ang Subiyakto, Achmad 
Nizar Hidayanto 

102-109

  
 Modeling and Analysis of Three Phase Active Power Filter Integrated Photovoltaic 

as a Reactive Power Compensator Using the Simulink Matlab Tool 
17 Setiyono, Sunny Arief Sudiro, Eri Prasetyo Wibowo 110-118

  
 The Community Readiness Measurement in Implementing Smart City in Banyuasin 

Regency 
18 Darius Antoni, Atika Arpan, Edi Supratman 119-125

  
 Improving Indoor Positioning Systems Accuracy in Closed Buildings with Kalman 

Filter and Feedback Filter 
19 Muhammad Andika Satrugna Mahardhika, Aji Gautama Putrada, Maman 

Abdurohman 
126-134

  
 Weighted Majority Voting by Statistical Performance Analysis on Ensemble 

Multiclassifier 
20 Retantyo Wardoyo, Aina Musdhlifah, Gede Angga Pradipta, I Nyoman Hariyasa 

Sanjaya 
135-143

  
 Unveiling Purchase Intention for .id Domain using e-WOM Adoption on Social 

Media 
21 Mieke Eka Putri, Yudho Giri Sucahyo, Arfive Gandhi 144-151



xi 
 

  
 Examining GOJEK Drivers’ Loyalty: The Influence of GOJEK’s Partnership 

Mechanism and Service Quality 
22 Fatimah Azzahro, Muhammad Aulia Adil, Arya Fathurrahman, Athifah Fidelia 

Sectianri, Nabila Laili Halimah, Achmad Nizar Hidayanto, Adhi Yuniarto Laurentius 
Yohanes 

152-157

  
 Design of a Robot to Control Agricultural Soil Conditions using ESP-NOW Protocol 

23 R Rizal Isnanto, Yudi Eko Windarto, Jonathan Gloriawan, Faiz Cesara 158-164
  
 Basic Knowledge Construction Technique to Reduce The Volume of Low-

Dimensional Big Data 
24 Gede Karya, Benhard Sitohang, Saiful Akbar, Veronica S. Moertini 165-173
  
 Detection of Fingerprint Authenticity Based on Deep Learning Using Image Pixel 

Value 
25 Hariyanto, Sunny Arief Sudiro, Tubagus Maulana Kusuma, Sarifuddin Madenda, 

Laode M. Rasdi Rere 
174-180

  
 The Antecedents of Trust and Their Influence on M-Health Adoption 

26 Widia Resti Fitriani, Arief Fadli Wicaksono, Danang Gagastama Joewono, 
Muhammad Zidane Zaffar, Reza Akbar Shahputra, Zieggy Ronnavelly, Achmad 
Nizar Hidayanto, Lim Yohanes Stefanus

181-187

  
 Detection and Simulation of Vacant Parking Lot Space Using EAST Algorithm and 

Haar Cascade
27 Rizki Alfarizi Harahap, Eri Prasetyo Wibowo, Robby Kurniawan Harahap 188-193

  
 Classification of Rice Leaf using Fuzzy Logic and Hue Saturation Value (HSV) to 

Determine Fertilizer Dosage 
28 Yuslena Sari, Muhammad Alkaff, Muti'a Maulida 194-200

  

 The effect of the perceived mobility and the provider reputation towards the usage 
continuance of the personal cloud storage

29 Ratna Juita, Aulia Hafiz Nur Rahman, Ifdhal Suharmitan, Kenny Reida Dharmawan, 
Muhammad Rafiando Gabhira, Rima Indriani, Achmad Nizar Hidayanto, Dedi I. Inan

201-207

  

 Double Layered Text Encryption using Beaufort and Hill Cipher Techniques 
30 Muhammad Fadlan, Suprianto, Muhammad, Yusni Amaliah 208-214

  

 Detection of Blackhole Attack in Wireless Sensor Network Using Enhanced Check 
Agent 

31 Riko Saputra, Julpri Andika, Mudrik Alaydrus 215-219
  

 Trust and Distrust: The Antecedents of Intention to Donate in Digital Donation 
Platform 

32 Adyanissa Farsya Kirana, Fatimah Azzahro, Putu Wuri Handayani, Widia Resti 
Fitriani 

220-226

  



xii 
 

 Rocky Roads towards Smart Tourism: A Multi-Dimensional Challenges Review 
33 Hafizh Rafizal Adnan, Achmad Nizar Hidayanto, Betty Purwandari, Bobby Achirul 

Awal Nazief, Solikin 
227-234

  

 Retrieval Information Using Generalized Vector Space Models And Sentiment 
Analysis Using NaĂŻve Bayes Classifier For Evaluation Of Lecturers By Students

34 Suprianto, Muhammad Fadlan, Muhammad, Yusni Amaliah, Mussallimah 235-242
  

 Chest X-Ray Image Analysis to Augment the Decision Making in Diagnosing 
Pneumonia using Convolutional Neural Networks Algorithm

35 Cynthia Hayat, Enggalwiguno Rahardja, Noviyanti Tm Sagala 243-249
  

 Gamification of the Lecturer Career Promotion System with a Recommender System
36 Tubagus Mohammad Akhriza, Indah Dwi Mumpuni 250-258

  

 Comparison of Migration Approaches of ICN/NDN on IP Networks 
37 Feri Fahrianto, Noriaki Kamiyama 259-266

  

 Converging Artificial Intelligence and Blockchain Technology using Oracle Contract 
in Ethereum Blockchain Platform

38 Richard, Mahenda Metta Surya, Avenia Clarissa Wibowo 267-272
  

 The Role of Blockchain Technology in E-Government Capability: Literature Review
39 Febriansyah, Darius Antoni, Endang Lestari 273-278

  

 Area of Mangrove Forests Calculated by Color Image Segmentation Using k-Means 
Clustering and Region Growing

40 R Rizal Isnanto, Oky Dwi Nurhayati, Tyas Panorama Nan Cerah 279-288
  
 Educating Farmers Using Participatory Rural Appraisal Construct 

41 Giandari Maulani, Untung Rahardja, Marviola Hardini, Ria Dwi I’zzaty, Qurotul Aini 289-297
  

 Factors Influencing of Online Forums Effectiveness as Knowledge Sharing Media in 
Increasing Knowledge and Cooking Performance 

42 Rafif Iqbal Shaputra, Achmad Nizar Hidayanto, Purwo Aji Fahmi Akmal, Ismail Al 
Ghani, Muhammad Arief Wibowo, Annisa Monicha Sari 

298-303

  

 A Hybrid Approach with Balanced Score Card and Fuzzy Topsis Method for 
Identifying Critical Factors Affecting Smart Regency Development 

43 Aang Kisnu Darmawan, Daniel Oranova Siahaan, Tony Dwi Susanto, Hoiriyah, Busro 
Akramul Umam, Tony Yulianto, Miftahul Walid,Betty Dewi Puspasari, Achmad Nizar 
Hidayanto 

304-312

  

 The Importance of Bounding Box in Motion Detection
44 Ahmad Fauzi, Sarifuddin Madenda, Ernastuti Ernastuti, Eri Prasetyo Wibowo, Anis 

Fitri Nur Masruriyah 
313-318

  



xiii 
 

 Socio Economic Perspective: Mitigate Covid-19 Impact on Education 
45 Mustofa Kamil, Po Abas Sunarya, Untung Rahardja, Nuke Puji Lestari Santoso, 

Qurotul Aini 
319-326

  

 Big Data Integration Design for General Election in Indonesia
46 Gede Karya, Wikan Danar Sunindyo, Benhard Sitohang, Saiful Akbar, Adi Mulyanto 327-334

  

 Optimization of K-NN Classification in Human Gait Recognition
47 Fandy Indra Pratama, Avira Budianita 335-340

  

 Taekwondo Sports Test and Training Data Management Using Blockchain 
48 Untung Rahardja, Marviola Hardini, Aditiya Lityanian Al Nasir, Qurotul Aini, Nuke Puji 

Lestari Santoso 
341-347

  

 Data Mining for Student Assessment in e-Learning: A Survey
49 Wenty Dwi Yuniarti, Edi Winarko, Aina Musdholifah 348-354

  

 Adoption of upcoming blockchain revolution in higher education: its potential in 
validating certificates 

50 Tuti Nurhaeni, Indri Handayani, Frizca Budiarty, Desy Apriani, Po Abas Sunarya 355-360
   
 Blockchain Family Deed Certificate For Privacy And Data Security  

51 Po Abas Sunarya, Henderi, Sulistiawati, Alfiah Khoirunisa, Pipit Nursaputri 361-365
   
 The Determinant Factors in Utilizing Electronic Signature Using the TAM and TOE 

Framework 
 

52 Budi Haryanto, Arfive Gandhi, Yudho Giri Sucahyo 366-374
   
 Predicting the Selling Price of Cars Using Business Intelligence with the Feed-

forward Backpropagation Algorithms
 

53 Nur Oktavin Idris, Aspian Achban, Siti Andini Utiarahman, Jorry Karim, Fuad Pontoiyo 375-381
   
 Drivers and Barriers to IT Service Management Adoption in Indonesian Start-up 

Based on the Diffusion of Innovation Theory
 

54 Rini Juliana Sipahutar, Achmad Nizar Hidayanto, Solikin, Untung Rahardja,Kongkiti 
Phusavat 

382-390

   
 Managing Service Level for Academic Information System Help Desk for XYZ 

University Based on ITIL V3 Framework 
 

55 Yuyun Tri Wiranti, Hendy M. J. Saputra,Dorce Berkat Tandirau, Tegar Palyus Fiqar, 
M. Gilvy Langgawan P, Eidelwiana Ramadhani, Amalia I. N. F. Abdullah 

391-397

   
 Sentiment Analysis and Topic Detection of Mobile Banking Application Review  

56 Majesty Eksa Permana, Handoko Ramadhan,Indra Budi, Aris Budi Santoso,Prabu 
Kresna Putra 

398-404

   
 Deep Learning for Assessing Unhealthy Lettuce Hydroponic Using Convolutional 

Neural Network based on Faster R-CNN with Inception V2 
 



xiv 
 

57 Ichsan Yudha Pratama, Abdi Wahab,Mudrik Alaydrus 405-411
   
 Knowledge Management System Design of the Security Command Center in A 

Financial and Banking Company with Contingency Factors and Sprint Design 
Methodology 

 

58 Figur Humani, Hilman Wisnu, Adyan Pamungkas Ganefi, Dana Indra 
Sensuse,Jonathan Sofian Lusa,Damayanti Elisabeth

412-418

   
 Investigating the Impact of System and Service Qualities on Customer Loyalty in 

Acceptance of E-Marketplace 
 

59 Fx Hendra Prasetya, Bernardinus Harnadi, Agus Nugroho, Achmad Nizar Hidayanto, 
Albertus Widiantoro 

419-425

   
 Data Mining Classification Approach To Predict The Duration Of Contraceptive Use  

60 Yudhi Dwi Fajar Maulana, Yova Ruldeviyani, Dana Indra Sensuse 426-432
   
 Design of Disaster Recovery Plan: State University in Indonesia  

61 Andri Setyawan, Yudho Giri Sucahyo,Arfive Gandhi 433-438
   
 Analysis of User Reviews for the PeduliLindungi Application on Google Play Using 

the Support Vector Machine and Naive Bayes Algorithm Based on Particle Swarm 
Optimization 

 

62 Ali Mustopa, Hermanto, Anna, Eri Bayu Pratama, Ade Hendini, Deni Risdiansyah 439-446
   
 Competency Evaluation of Project Manager Performance in Network Construction 

Projects 
 

63 Yohanes Fajar Sitohang, Devi Pratami, Achmad Fuad Bay 447-455
   
 Developing a Quality Metric in Controlling the Project Task  

64 Indriana Novitiara, Devi Pratami, Achmad Fuad Bay 456-463
   
 Data Analytics of Students' Profiles and Activities in a Full Online Learning Context  

65 Tuti Purwoningsih, Harry B. Santoso, Zainal A. Hasibuan 464-472
   
 Factors Influencing User Intention in Opening Personal Data on Social Media  

66 Kevin Sutarno, Brian Estadimas, Amira Taliya,Damar Wardoyo, Ika Chandra 
Hapsari, Achmad Nizar Hidayanto, Bobby A.A. Nazief 

473-480

   
 Ontology-based Approach for Dynamic E-Learning Personalization  

67 Kusuma Ayu Laksitowening, Zainal Arifin Hasibuan, Harry Budi Santoso 481-486
   
 Implementation The Convolutional Neural Network Method For Classification The 

Draw-A-Person Test 
 

68 Jhordy Wong Abuhasan, Sigit Widiyanto 487-493
   
 Implementation Of Convolutional Neural Network Method For Classification Of Baum 

Test 
 

69 Irvan Setiawan, Hafizh Nurhady, Tristyanti Yusnitasari, Noor Vika Hizviani 494-500



xv 
 

   
 Maturity Grading of Oil Palm Fresh Fruit Bunches Based on a Machine Learning 

Approach 
 

70 Anindita Septiarini, Heliza Rahmania Hatta, Hamdani Hamdani, Ana Oktavia, Anita 
Ahmad Kasim, Suyanto Suyanto 

501-505

   
 Measurement of Information Security Awareness Level: A Case Study of Mobile 

Banking (M-Banking) Users 
 

71 Khairunnisa Firsty Arisya, Yova Ruldeviyani, Rahardi Prakoso, Amanda Lailatul 
Fadhilah 

506-511

   
 Mobile-based Fish Quality Detection System Using K-Nearest Neighbors Method  

72 Suhadi Suhadi, Prima Dina Atika, Sugiyatno Sugiyatno, Ahmad Panogari, Rahmadya 
Trias Handayanto, Herlawati Herlawati 

512-517

   
 Developing Name Entity Recognition for Structured and Unstructured Text 

Formatting Dataset 
 

73 Nadhia Salsabila Azzahra, Muhammad Okky Ibrohim, Junaedi Fahmi, Bagus Fajar 
Apriyanto, Oskar Riandi 

518-525

   
 Foreign Exchange Prediction using CEEMDAN and Improved FA-LSTM  

74 Mustika Ulina, Ronsen Purba, Arwin Halim 526-532
   
 Social Media User Acceptance on Instagram Health Information Recommendation: 

A Transactive Memory System Perspective
 

75 Hafizh Rafizal Adnan, Achmad Nizar Hidayanto, Christie Vithasa Immanuel 
Kassan,Albert Christian Bagun, Ilham Pamungkas Nasution, Samuel, Ervi Cofryanti 

533-540

   
 Human Activity Recognition using Reduced Kernel Extreme Learning Machine for 

Body Weight Management 
 

76 Arwin Halim, Erick Kwantan, Silfi Langie, Vinson Chandra, Hernawati Gohzali 541-546
   
 Prediction of Student Graduation With Naive Bayes Algorithm  

77 Hartatik, Kusrini Kusrini, Agung Budi Prasetio 547-552
   
 Purchasing New Smartphones among University Students: The Role of Domain-

Specific Innovativeness (DSI) and Technology Product Characteristics 
 

78 Karina Lia Meirita Uloa, Aldi Firmansyah, Astari Dwi Rahmanisa, Athifa Michela, 
Deana Almira Putri, Hauri Silmi Zafirah, Achmad Nizar Hidayanto,Ferdian Aditya 
Pratama 

553-557

   
 Task Design for Indonesian Cultural Heritage Data Collection with Crowdsourcing  

79 Winangsari Pradani, Zainal Arifin Hasibuan 558-565
   
 Speech Emotion Recognition on Indonesian YouTube Web Series Using Deep 

Learning Approach 
 

80 Hanina Nuralifa Zahra, Muhammad Okky Ibrohim, Junaedi Fahmi, Rike Adelia, 
Fandy Akhmad Nur Febryanto, Oskar Riandi 

566-572

   



xvi 
 

 Learning Optimization Using Genetic Algorithm in Post-Stroke EEG Signal 
Classification 

 

81 Esmeralda Contessa Djamal, Mita Amara,Daswara Djajasasmita, Sandy Lesmana 
Liem Limanjaya 

573-578

   
 What Do Affect Customers to Use Mobile Payment Continually? A Systematic 

Literature Review 
 

82 Mutia Fadhila Putri, Betty Purwandari, Achmad Nizar Hidayanto 579-585
   
 The Crowdsourcing Method to Normalize ”Bahasa Alay”, a Case of Indonesian 

Corpus 
 

83 Rianto, Achmad Benny Mutiara, Eri Prasetyo Wibowo, P. Insap Santosa 586-591
   
 Gabor Filter Methods to Analyze the Influence of Geographic Distance and Folk Song 

in Java Indonesia 
 

84 Clara Tania, Wella, Yustinus Soelistio 592-597
   
 Diagnosis of Feline Skin Disease Using C4.5 Algorithm  

85 Triyanna Widiyaningtyas, I Made Wirawan, Sabilla Halimatus Mahmud 598-603
   
 Affordable Mobile Virtual Reality Earthquake Simulation  

86 Peter Liuwandy, Suryasari, Wella 604-609
   
 Aspect Oriented Programming Approach for Variability Feature Implementation in 

Software Product Line Engineering
 

87 Ni Made Satvika Iswari, Eko K. Budiardjo, Zainal A. Hasibuan 610-615
   
 Deep Neural Network Method to Classify Empon-Empon Herb Based on E-Nose  

88 Maimunah, Mukhtar Hanafi, Bayu Agustian 616-620
   
 Survey of Data Mining Techniques for Intrusion Detection Systems  

89 Aditya Nur Cahyo, Edi Winarko, Aina Musdholifah 621-629
   
 Indonesian Tweets Hate Speech Target Classification using Machine Learning  

90 Sandy Kurniawan, Indra Budi 630-635
   
 Usability Evaluation and User Interface Design of University Staffing Information 

System 
 

91 Bryanza Novirahman, Harry Budi Santoso, R. Yugo Kartono Isal 636-644
   
 Dew Computing: Concept and Its Implementation Strategy  

92 Prayudi Utomo, Falahah 645-651
   
 Decision Support System For Student Scholarship Recipients Using Simple Additive 

Weighting Method with Sensitivity Analysis
 

93 Fata Nidaul Khasanah, Rahmadya Trias Handayanto, Herlawati Herlawati, Djuni 
Thamrin, Prasojo Prasojo, Erik Saut H Hutahaean 

652-658



xvii 
 

   
 Improving the Quality of AES S-box by Modifications Irreducible Polynomial and 

Affine Matrix 
 

94 Alamsyah 659-665
   
 Factors Affecting Acceptance of E-marketplace Based On Hybrid Model of Modified 

TAM-TRI 
 

95 Kadek Cahya Dewi, Ni Wayan Dewinta Ayuni 666-674
   
 A Model of Requirements Engineering on Agriculture Mobile Learning System Using 

Goal-Oriented Approach 
 

96 Rosa Delima, Argo Wibowo, Antonius Rachmat Chrismanto, Halim Budi Santoso 675-683
   
 Finding Preeminence: A Systematic Literature Review of e-Service Success Factors  

97 Andy Syahrizal, Assaf Arief, Dana Indra Sensuse 684-690
   
 Information Security Risk Management Planning of Digital Certificate Management 

Case Study: Balai Sertifikasi Elektronik 
 

98 Dana Indra Sensuse, Andy Syahrizal, Faizan Aditya, Muhammad Nazri 691-698
   
 PenalViz: A Web-Based Visualization Tool for The Indonesian Penal Code  

99 Mubarik Ahmad, Roha Di Oloan Tampubolon, Kukuh Fadli Prasetyo 699-703
   
 A Comparison of Supervised Text Classification and Resampling Techniques for 

User Feedback in Bahasa Indonesia 
 

100 Dhammajoti, Julio Christian Young, Andre Rusli 704-710
   
 Spatial Intelligent Decision Support System for Coconut Agroindustry Downstream 

Development: An Overview 
 

101 Siti Wardah, Marimin, Mohammad Yani, Taufik Djatna 711-717
   
 Conceptualizing Smart Government Implementation in Smart City Context: A 

Systematic Review 
 

102 Dhena Kamalia Fu'adi, Assaf Arief, Dana Indra Sensuse, Andy Syahrizal 718-725
   
 Augmented Reality Development for Supporting Cultural Education Role in SMB II 

Museum During Covid-19 Pandemic
 

103 Shinta Puspasari, Nazori Suhandi, Jaya Nur Iman 726-732
   
 Driving Simulator Software for Evaluation of Safety Driving  

104 Mohammad Iqbal, Karmilasari, Kemal Ade Sekarwati, Dian Kemala Putri 733-742
   
 Twitter Scrapping for Profiling Education Staff  

105 Herlawati Herlawati, Rahmadya Trias Handayanto, Inna Ekawati, Kardinah Indrianna 
Meutia, Jelita Asian, Umar Aditiawarman 

743-749

   
 Decision Support System with Fuzzy Multi-Attribute Decision Making (FMADM) and 

Simple Additive Weighting (SAW) In Laptop Vendor Selection 
 



xviii 
 

106 Anita Diana, Achmad Solichin 750-757
   
 News Sentiment Analysis in Forex Trading Using R-CNN on Deep Recurrent Q-

Network 
 

107 Kevin Chantona, Ronsen Purba, Arwin Halim 758-765
   
 Framework With An Approach To The User As An Evaluation For The Recommender 

Systems 
 

108 Zen Munawar, Nanna Suryana, Zurina binti Sa’aya, Yudi Herdiana 766-771
   
 Combination of LSTM and CNN for Article-Level Propaganda Detection in News 

Articles 
 

109 Dimas Sony Dewantara, Indra Budi 772-776
   
 Analysis of Higher Education Performance Measurement Using Academic Scorecard 

and Analytical Hierarchy Process
 

110 Titus Kristanto, Walid Maulana Hadiansyah, Muhammad Nasrullah 777-783
   
 Learning Progress Modeling for Monitoring Student  

111 Ria Arafiyah, Zainal A. Hasibuan, Harry Budi Santoso 784-790
   
 Indonesia’s News Topic Discussion about Covid-19 Outbreak using Latent Dirichlet 

Allocation 
 

112 Razief Perucha Fauzie Afidh, Zainal A. Hasibuan 791-797
   
 Improving Value-Based E-Government Towards the Achievement of Smart 

Government 
 

113 Agus Hermanto, Rosziati Binti Ibrahim, Geri Kusnanto 798-805
   
 The Facial Emotion Recognition (FER2013) Dataset for Prediction System of Micro-

Expressions Face Using the Convolutional Neural Network (CNN) Algorithm based 
Raspberry Pi 

 

114 Lutfiah Zahara, Purnawarman Musa, Eri Prasetyo Wibowo, Irwan Karim, Saiful Bahri 
Musa 

806-815

   
 IT Implementation of Customer Relationship Management  

115 Nina Kurnia Hikmawati, Doni Purnama Alamsyah, Ahmad Setiadi 816-820
   
 Mapping fMRI voxel activations to CNN feature space for ease of categorization  

116 Bhargav Krishnamurthy, Dr.Sudha Subramanian 821-827
   
 GIS-Based MCDM for Central Business Suitability in a Small City  

117 Herlawati Herlawati, Edi Abdurachman, Yaya Heryadi, Haryono Soeparno 828-833
   
 Support Vector Machine And Neural Network Algorithm Approach to Classifying 

Facial Expression Recognition 
 

118 Muhamad Fatchan, Mauridhi Hery Purnomo, Affandy, Ahmad Zainul Fanani, Linda 
Marlinda 

834-839

   



xix 
 

 Research Spectrum Framework in the Field of Educational Technology  
119 Richardus Eko Indrajit, Basuki Wibawa, Atwi Suparman 840-844

   
 Portrait of Higher Education in the Covid-19 Period in a Digital Literacy Perspective: 

A Reflection on the Online Lecture Process Experience 
 

120 Richardus Eko Indrajit, Basuki Wibawa 845-850
   
 AUTHOR INDEX 851-859 
   

 



XXX-X-XXXX-XXXX-X/XX/$XX.00 Š20XX IEEE 

Decision Support System For Student Scholarship 
Recipients Using Simple Additive Weighting 

Method with Sensitivity Analysis 
1st Fata Nidaul Khasanah  
Informatics Engineering                       

Universitas Bhayangkara Jakarta Raya 
Bekasi, Indonesia 17121 
fatanidaul@gmail.com 

 
4th Djuni Thamrin 

Management 
Universitas Bhayangkara Jakarta Raya 

Bekasi, Indonesia 17121 
djuni.thamrin@ubharajaya.ac.id 

  

2nd Rahmadya Trias Handayanto 
Computer Engineering                       

Universitas Islam 45 Bekasi 
 Bekasi, Indonesia 17113 

rahmadya.trias@gmail.com 
 

5th Prasojo Prasojo 
Communication Science 

Universitas Bhayangkara Jakarta Raya 
Bekasi, Indonesia 17121 

prasojo@dsn.ubharajaya.ac.id 
  

3rd Herlawati Herlawati 
Informatics Engineering                       

Universitas Bhayangkara Jakarta Raya 
Bekasi, Indonesia 17121 

herlawati@ubharajaya.ac.id 
 

6th Erik Saut H Hutahaean 
Psychology 

  Universitas Bhayangkara Jakarta Raya 
Bekasi, Indonesia 17121 

erik.saut@dsn.ubharajaya.ac.id

Abstract — The scholarship recipients should ideally be 
given to the appropriate students. Many methods have been 
widely used to assist the school management in deciding the 
scholarship recipients. However, such methods do not give the 
additional information and other methods comparison. The 
purpose of this research is to provide systematic and objective 
scholarship selection recommendation system and using 
sensitivity analysis to compare between the two decision support 
methods used, i.e. the Simple Additive Weighting and the 
Weighted Product methods. The Simple Additive Weighting 
method provides the highest assessment results, namely 
alternatives with a preference value of 13.27. The Weighted 
Product method provides the highest assessment results, namely 
alternatives with a preference value of 0.046. The results of the 
sensitivity analysis show that the total change value of the 
Simple Additive Weighting method was 6%, while in the 
Weighted Product method the total change value was 0.2%. 
Therefore, the sensitivity analysis showed that the Simple 
Additive Weighting method better than Weighted Product in 
determining the scholarship recipient recommendation because 
it has a greater total change value. 

Keywords—scholarship recommendation system, simple 
additive weighting, sensitivity analysis, weighted product 

I. INTRODUCTION  

Scholarships are a form of grant in the form of money 
given to students to be used for tuition fees and other costs [1]. 
Some countries provide scholarship, for example in Indonesia, 
every citizen has the right to receive instruction, which is 
stipulated in the 1945 Constitution Article 31 (1). The 
scholarship program has been carried out by every educational 
institution in Indonesia, from elementary school to middle and 
higher school level. For higher level educat";"""date"",""2020-12-30T04:37:36Z""
""pdf:docinfo:custom:Meeting Starting Date"",""3 Nov. 2020""
""pdf:PDFVersion"",""1.7""
""pdf:docinfo:title"",""Front Cover""
""xmp:CreatorTool"",""Adobe Acrobat 8.1""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""2020 Fifth International Conference on Informatics and Computing (ICIC);2020; ; ;10.1109/ICIC50835.2020.9288537""
""language"",""en""
""dc:format"",""application/pdf; version=1.7""
""pdf:docinfo:creator_tool"",""Adobe Acrobat 8.1""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""Front Cover""
""modified"",""2020-12-30T04:37:36Z""
""Meeting Starting Date"",""3 Nov. 2020""
""cp:subject"",""2020 Fifth International Conference on Informatics and Computing (ICIC);2020; ; ;10.1109/ICIC50835.2020.9288537""
""pdf:docinfo:subject"",""2020 Fifth International Conference on Informatics and Computing (ICIC);2020; ; ;10.1109/ICIC50835.2020.9288537""
""pdf:hasMarkedContent"",""true""
""xmp:ModifyDate"",""2020-12-30T11:37:36Z""
""meta:creation-date"",""2020-12-11T04:54:59Z""
""created"",""2020-12-11T04:54:59Z""
""pdf:docinfo:custom:IEEE Publication ID"",""9288361""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-12-11T04:54:59Z""
""resourceName"",""Paper%20ICIC-Fata%20Nidaul%20Khasanah.pdf""
""pdf:docinfo:custom:Meeting Ending Date"",""4 Nov. 2020""
""producer"",""Adobe Acrobat 8.1 Paper Capture Plug-in; modified using iTextŽ 7.1.1 Š2000-2018 iText Group NV (AGPL-version)""
""pdf:docinfo:producer"",""Adobe Acrobat 8.1 Paper Capture Plug-in; modified using iTextŽ 7.1.1 Š2000-2018 iText Group NV (AGPL-version)""
""IEEE Publication ID"",""9288361""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""53"",""54"",""58"",""0"",""0"",""0"",""0"",""0""
""dc:description"",""2020 Fifth International Conference on Informatics and Computing (ICIC);2020; ; ;10.1109/ICIC50835.2020.9288537""
""access_permission:modify_annotations"",""true""
""description"",""2020 Fifth International Conference on Informatics and Computing (ICIC);2020; ; ;10.1109/ICIC50835.2020.9288537""
""dcterms:created"",""2020-12-11T04:54:59Z""
""Last-Modified"",""2020-12-30T04:37:36Z""
""dcterms:modified"",""2020-12-30T04:37:36Z""
""title"",""Front Cover""
""Last-Save-Date"",""2020-12-30T04:37:36Z""
""IEEE Article ID"",""9288537""
""pdf:docinfo:modified"",""2020-12-30T04:37:36Z""
""meta:save-date"",""2020-12-30T04:37:36Z""
""pdf:docinfo:custom:IEEE Article ID"",""9288537""
""Content-Length"",""1628734""
""pdf:docinfo:custom:IEEE Issue ID"",""9288512""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""28""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""136"",""152"",""224"",""929"",""2790"",""1283"",""1319"",""204"",""1607"",""2252"",""2161"",""2263"",""2279"",""2238"",""2228"",""1996"",""2117"",""1993"",""362"",""5977"",""5173"",""3884"",""3017"",""4175"",""2161"",""0"",""0"",""0""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-12-11T04:54:59Z""
""IEEE Issue ID"",""9288512""
""Meeting Ending Date"",""4 Nov. 2020""
";https://scholar.google.ch/scholar?start=940&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098791-164;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Memory-tight reductions for practical key encapsulation mechanisms;R Bhattacharyya ; IACR International Conference on PublicKey …, 2020  Springer;;"… In CRYPTO 2017, Auerbach et al … mathcal {A}\) on input x. \(\mathcal {A}^\mathcal {O}\) denotes

that \(\mathcal {A}\) has access to \(\mathcal {O}\) as an oracle. The oracles in this paper may

be stateful; \(st_\mathcal {O}\) denotes the state of the RAM \(\mathcal {O}\). As followed in …";Cité 1 fois;Les 3 versions;[PDF] iacr.org;https://eprint.iacr.org/2020/075.pdf;"
Memory-Tight Reductions for Practical
Key Encapsulation Mechanisms

Rishiraj Bhattacharyya

NISER, HBNI, India.
rishiraj.bhattacharyya@gmail.com

Abstract. The efficiency of a black-box reduction is an important goal
of modern cryptography. Traditionally, the time complexity and the suc-
cess probability were considered as the main aspects of efficiency mea-
surements. In CRYPTO 2017, Auerbach et al introduced the notion of
memory-tightness in cryptographic reductions and showed a memory-
tight reduction of the existential unforgeability of the RSA-FDH signa-
ture scheme. Unfortunately, their techniques do not extend directly to
the reductions involving intricate RO-programming. The problem seems
to be inherent as all the other existing results on memory-tightness are
lower bounds and impossibility results. In fact, Auerbach et al conjec-
tured that a memory-tight reduction for IND-CCA security of Hashed-
ElGamal KEM is impossible.

– We refute the above conjecture. Using a simple RO simulation tech-
nique, we provide memory-tight reductions of IND-CCA security of
the Cramer-Shoup and the ECIES version of Hashed-ElGamal KEM.

– We prove memory-tight reductions for different variants of Fujisaki-
Okamoto Transformation. We analyze the modular transformations
introduced by Hofheinz, Hövermanns and Kiltz (TCC 2017). In ad-
dition to the constructions involving implicit rejection, we present
a memory-tight reduction for the IND-CCA security of the trans-
formation QFO⊥m . Our techniques can withstand correctness-errors,
and applicable to several lattice-based KEM candidates.

Keywords: Memory-tight Reduction; Hashed-ElGamal; FO transfor-
mation

1 Introduction

Memory Efficiency of Black-box Reductions Black-box reduction is an im-
perative tool in modern cryptography. The security of any scheme S is typically
argued by an algorithm R. Given an adversary, AS against S, R with black-box
access to A is shown to solve some underlying hard problem P. The efficiency of
a black-box reduction is measured by the resources R uses, typically in terms of
A. Traditionally the reductions aimed at optimizing the time complexity and/or
the success probability [5,4,10]. However, Auerbach et al [3] observed that some
reductions which are tight in success probability and time complexity, require a



large amount of memory. If the underlying problem is memory sensitive (easier to
solve with larger memory), then a memory loose reduction does not rule out the
existence of an efficient adversary. They noted further that many of the standard
assumptions including LPN, SVP, Discrete Logarithm Problem in prime fields,
factoring are memory sensitive. Hence it is imperative to find memory-efficient
reductions when the security is based on the hardness of these problems.

Unfortunately, most of the existing results on memory-tight reductions are
lower bounds. In [3], authors ruled out memory-tight, restricted black-box re-
ductions for the security of multi-signatures from unique signatures, and mul-
ticollision resistance from collision resistance. In [21], Wang et al showed lower
bounds for a larger class of black-box reductions including the security of public-
key encryption and signature schemes in the multi-user setting. In [13], Demay
et al considered the indifferentiability notion in the memory restricted setting,
and proved the impossibility of domain extension of hash functions (even by one
bit).

On the other hand, to the best of our knowledge, the only positive result
so far is the memory-efficient reduction for RSA FDH in the Random Oracle
model [3]. The authors introduced new techniques for the random oracle model
and showed, using pseudo-random functions and the power of rewinding the
adversary once, one can prove a memory-tight reduction of the existential un-
forgeability of RSA-FDH from RSA assumption. Their technique seems to be
generally applicable for hash and sign paradigm, where the domain of the under-
lying trapdoor permutation enjoys some form of homomorphism (required for
applying Coron’s technique [11]).
Key Encapsulation Mechanisms. A Key Encapsulation Mechanism (KEM)
is a fundamental primitive to construct efficient public-key cryptosystem. Re-
search in KEM design has been rejuvenated in the last few years due to the on-
going effort to standardize post-quantum cryptographic algorithms. While con-
structions of IND-CCAsecure KEM in the “classical” setting have been known
for years (see [14] for a comprehensive treatment), the reductions were non-
tight, and required perfect correctness from the underlying public-key encryp-
tion scheme. There are numerous recent works on KEM in the quantum setting
[9,20,16,19,17]. However, not much progress has been made in the classical setting
until the work of Hofheinz, Hövermanns and Kiltz [16]. HHK revisited the KEM
version of Fujisaki Okamoto transformations and presented a modular analysis
of multiple variants. Their results, notably include, tight reduction (traditional
sense) even when underlying public-key encryption scheme has some correctness
error.

1.1 Our Contributions

In this paper, we present memory-efficient reductions of the IND-CCA security
of hashed-ElGamal and other variants of Fujisaki-Okamoto transformations.

Memory-tight Reduction for Hashed-ElGamal Our starting point is the
following conjecture of Auerbach et al [3].

2



Conjecture 1 [3] Memory-tight Reduction for Hashed-ElGamal does not exist.

In this paper, we refute the above conjecture. We introduce a simple “map-
then-prf” technique to simulate the random oracle in a memory-efficient way.
Our technique programs the Random Oracle non-adaptively, avoiding the need
to tabulate the Random Oracle queries. We consider two versions of Hashed-
ElGamal KEM, ECIES [1,2] and HEG[12]. We summarize these results in the
following two informal theorems.

Theorem 2 (Informal). Let G be a prime-order cyclic group. Let F : {0, 1}λ+1×
G×G→ K be a prf. There exists a memory-tight reduction, in the random ora-
cle model, of the IND-CCA security of HEG over G and K from the gap-Diffie-
Hellman problem over G.

Theorem 3 (Informal). Let G,GT be prime-order cyclic groups and ê : G ×
G → GT be a bilinear map. Let F : {0, 1}λ × GT → K be a prf. There exists a
memory-tight reduction, in the random oracle model, of the IND-CCA security
of ECIES over G and K from the Computational-Diffie-Hellman problem over
G.

Memory-tight reduction for variants of Fujisaki-Okamoto Transforma-
tions. Fujisaki-Okamoto transformation and other related KEM constructions
have gained particular importance in recent years for their applications in con-
structing post-quantum KEM schemes. In particular, the modular analysis in
[16] has been applied widely in constructing lattice-based candidates. In this
paper, we prove memory-tight reduction for three variants of Fujisaki-Okamoto
transformations (described in Table 1).

We revisit the analysis in [16] and show techniques for memory-tight reduc-
tions for all the modules, even withstanding the correctness errors. We summa-
rize the results below.

– Transformations U 6⊥,U 6⊥m,U
⊥,U⊥m. In [16], the authors presented four closely

related modules to construct an IND-CCA secure KEM from a public-key
encryption scheme PKE. The security requirement from PKE depends on the
specific variant of U. In this paper, we show new RO simulation techniques
for all the four variants to convert corresponding the reductions in [16] into
memory-tight ones.

– Preprocessing Module T . In [16], the transformation T was presented as
the preprocessing module to convert (with a tight reduction) an IND-CPA se-
cure public-key encryption scheme PKE to a deterministic OW-PCVA secure
public-key encryption scheme. We observe that the RO simulation technique
of Auerbach et al [3], is sufficient for a memory-tight reduction for OW-PCA
security of T [PKE]. When applied with the new reductions for U6⊥ and U 6⊥,
this gives a memory-tight reduction for the IND-CCA security of KEM 6⊥ and
KEM6⊥m respectively.

– A new intermediate module V . The modules with explicit reject, (namely
U⊥m and U⊥) require security relative to a ciphertext verification oracle. Un-
fortunately, our technique only proves OW-PCA security of T . To bridge

3



the gap, we present a transformation V to convert a OW-PCA determinis-
tic public-key encryption scheme to a OW-PCVA deterministic public-key
encryption scheme via a memory-efficient reduction. When applied with T
and U⊥m, we get a memory efficient reduction (in the classical setting) for
the scheme QKEM⊥m of [16] (Table 4 in [14]).

Constructions Encap(pk) Decap(sk′, c)

KEM6⊥ = U 6⊥
[
T [PKE, G], H

]
m

$←−M
c = Enc(pk,m, G(m))
K = H(m, c)

m′ = Dec(sk, c)
if m′ 6=⊥ ∧c = Enc(pk,m′, G(m′)) then K = H(m′, c)
else K = H(s, c)

KEM6⊥m = U 6⊥m
[
T [PKE, G], H

]
m

$←−M
c = Enc(pk,m, G(m))
K = H(m)

m′ = Dec(sk, c)
if m′ 6=⊥ ∧c = Enc(pk,m′, G(m′)) then K = H(m′)
else K = H(s, c)

QKEM⊥m
= U⊥m

[
V
[
T [PKE, G], H′

]
, H
] m

$←−M
c1 = Enc(pk,m, G(m))
c2 = H′(m)
c = c1||c2
K = H(m)

Parse c = c1||c2, m′ = Dec(sk, c1)
if m′ 6=⊥ ∧c1 = Enc(pk,m′, G(m′)) ∧ c2 = H′(m′)

K = H(m′)
else

K =⊥
Table 1. Considered variants of Fujisaki-Okamoto Transformations. PKE =
(Keygen, Enc, Dec) is an IND-CPA secure public-key encryption scheme. In the column
Decap, s is a random string, sk′ = sk||s.

Other Implications. Besides memory efficiency, we found two additional im-
plications of our work. This result refutes the folklore idea that the additional
hash present in the QKEM⊥m transformation is redundant in the classical setting
[14,16,17]. The second implication is that V composed with T gives a OW-PCVA
secure encryption scheme from an IND-CPA secure encryption scheme without
the Îł-spread requirement of [16].

Concurrent Related Work In a concurrent and independent work, Ghoshal
and Tessaro [15] prove a memory-efficiency lower bound for ECIES in the generic
group model where the pairing is not available. To the best of our knowledge, this
work is the first in proving memory lower bound for any particular construction.
Interestingly, the authors develop new techniques for proving memory-efficiency
lower bounds. We remind the reader that our reduction for ECIES works on
pairing friendly groups and does not contradict their results.

1.2 Overview of our Techniques.

Challenges with existing technique The memory-efficient technique to sim-
ulate an RO in [3] (and later suggested in [8] in the context of KEM) is to
evaluate a PRF on the input. However, in the IND-CCA security reduction for
key encapsulation mechanisms, the reduction often needs to adaptively program

4



the output of the RO. Evaluating the prf directly on the query input does not
provide the required programming capability.
For example, consider the basic construction of a Key Encapsulation Mecha-
nism from a deterministic public-key encryption scheme PKE = (Gen, Enc, Dec).
The public-key, secret-key of the KEM would be a key pair (pk, sk)← Gen. An
encapsulation involves choosing a random message m, and computing

c = Enc(pk,m), k = H(m, c).

The output of the encapsulation is (c, k). A traditional security proof assuming
H to be a random oracle would be to maintain a table containing the queries and
corresponding responses of H queries. Whenever the adversary makes a decap-
sulation query on ĉ, the reduction will check the table whether it contains an
entry (m̂, ĉ, ĥ) such that Enc(pk, m̂) returns ĉ. If such an entry exists, the answer

to the decapsulation query would be ĥ. Otherwise the reduction would return a
randomly sampled element ĥ′, and save (−, ĉ, ĥ′) in the list. The first entry will
be filled up when, in a future hash query, the adversary submits (m̂, ĉ) where
ĉ = Enc(pk, m̂).

Now consider a memory-efficient reduction where simulation of H is performed
using a prf F (k, .). A hash query on (m̂, ĉ) is returned with F (k, m̂, ĉ). The
problem arises when simulating the decapsulation query ĉ. As the entries are no
longer saved in a table, the reduction cannot find the required m̂ to complete the
prf evaluation! One may attempt to solve the issue by answering the hash query
with F (k, ĉ). In that case, the decapsulation queries can be answered. However,
two hash queries with the same ĉ but different m̂ would result in a collision!
Hence, this idea fails as well.
Core of our Idea: “injectively map and prf”. Our method originates from
the following observation. Let us call (m̂, ĉ) a good pair if ĉ = Enc(pk, m̂). In the
IND-CCA security game, the answer to a decapsulation query ĉ needs to match
with the response of a hash query (m̂, ĉ) only when (m̂, ĉ) is a good pair. When
answering hash queries on a good pair (m̂, ĉ), we can “program” the output to
be F (k,m0, ĉ) ( m0 being any fixed message). For pairs which are not good, we
can query an independent prf F ′(k, m̂, ĉ) to compute the responses. Answer to
a decapsulation query on (a valid ciphertext) ĉ will simply be F (k,m0, ĉ). The
idea can be generalized as “ Apply an appropriate injective function φ on the
input, and then apply the prf”. As the composition of an injective function with
a prf results into a prf, we can use the arguments of [3]. This basic technique
can readily be applied to the Cramer-Shoup version of Hashed-ElGamal, as well
as the modules U6⊥, and U⊥.
Technique for U6⊥m,U

⊥
m. In these cases, the hash function is evaluated only

on m. Thus, the above idea is not applicable directly. However, as PKE is de-
terministic, the reduction can still construct a good pair by simply computing
ĉ = Enc(pk, m̂), and respond a hash query on m̂ by F (k, ĉ). We no longer need
to use the independent prf F ′, as the hash query only contains the message.

Interestingly, the technique works even if PKE has amall correctness errors.
Although, Enc(pk, .) is no longer injective, finding a collision in the output of

5



Enc(pk, .) implies finding a correctness error. Conditioned on no collision in the
output of Enc(pk, .), the argument of [3] goes through. However, one needs to be
careful here, as pointed out in [8]. In some definition of deterministic encryption,
it is easy to come up with a scheme where a ciphertext decrypts to a message
which in turn encrypts to a different ciphertext. To solve the issue, we require
that for every message m̂ there exists a single ciphertext ĉ that decrypts to m̂.
Our definition of deterministic encryption is carefully considered to maintain
this property. Moreover, the schemes generated by the transformation T of [16]
satisfies the definition.
Technique for ECIES. In the case of ECIES, we have a group G of prime
order q with a generator g ∈ G. A public-key is a random element X with
the corresponding secret-key x such that X = gx. The encapsulation involves

choosing a random y
$←− Zq and computing

Y = gy Z = Y x k = H(Z)

The output of the encapsulation is (Y, k). While ECIES is analogous to U 6⊥m, we
cannot find Y from Z! Hence, we cannot “map to ciphertext space” and apply
F .

Fortunately, the “map-then-prf” technique is not limited to mapping to the
ciphertext space. We note, when ECIES is implemented using a pairing friendly
curve, there exists a bilinear map ê : G × G → GT for some GT . Moreover,
by the bilinear property, ê(gx, gy) = ê(g, gxy). We simulate the random oracle
using F (k, ê(g, .)). The decapsulation oracle can maintain consistency by using
F (k, ê(X, .)).

2 Notations and Preliminaries

If S is a set |S| denotes the size of S. x
$←− S denotes the process of choosing

x uniformly at random from S. [n] denotes the set of first n natural numbers.
Composition of two functions is denoted by ◦. If F̂ = F ◦φ, then F̂ (x) = F (φ(x)).
Algorithms and Security Games. The algorithms and complexities consid-
ered in the papers are in the RAM model. The algorithms have access to memory
and constant number of registers, each having size of one word. For a determin-

istic (resp. probabilistic) algorithm A, y = A(x) (resp y
$←−A(x)) denotes y is

the (resp. uniformly sampled) output of A on input x. AO denotes that A has
access to O as an oracle. The oracles in this paper may be stateful ; stO denotes
the state of the RAM O. As followed in [3], A with oracle access to O cannot
access stO.
Security Games The results are proven in the framework of code based games
of [6]. A game G consists an algorithm consists of a main oracle, and zero or more
stateful oracles O1, O2, ¡ ¡ ¡ , On. If a game G is implemented using a function f ,
we write G[f ] to denote the game.

Complexity Measures. In this paper, we consider the following three com-
plexity measures of an algorithm.

6



Success Probability. The success probability of an algorithm A in game G

is defined by SuccA,G
def
= Prob[GA = 1].

Time Complexity. The time complexity of an algorithmA, denoted by TimeÎť(A),
is the number of computation steps performed by A in the worst case over all
possible input of size Îť. When A plays a security game G, the time complexity
of the game, denoted by LocalTimeÎť(GA), is the time complexity of A plus the
number of queries A makes to the oracle. 1

Memory Complexity. Following [3,21], we define the memory complexity of
an algorithm A to be the size of the code plus the worst-case number of registers
used in memory at any step in computation, over all possible input of size Îť and
random coins. LocalMemÎť(GA) denotes the memory complexity of A (not the
oracles) in the security game G.
Reductions and Efficiency. We follow the definition of black-box reductions
proposed in [18]. A cryptographic primitive P is a family of efficiently com-
putable functions f : {0, 1}∗ → {0, 1}∗. Security of P is described using a game
G. An adversary A is said to P-break f with probability Îľ, if

SuccA,G[f ] = Îľ.

We follow the following definition of a cryptographic reduction.

Definition 1. Let P,Q be cryptographic primitives and GP and GQ be the cor-
responding security games respectively. A reduction from P to Q is a pair of
algorithms C, R such that

– Cf ∈ Q for all f ∈ P
– For all f ∈ P, for all adversary A that Q-breaks Cf , the algorithm RA P-

breaks f .

Memory-Tight Reductions. Following [3,21], we define memory-tight reduc-
tions as follows.

Definition 2. A Cryptographic reduction (C, R) from P to Q is called memory-
tight, if for all f ∈ P,

SuccA,GQ[Cf ] ≈SuccRA,GP [f ]

LocalTimeλ(RA) ≈LocalTimeλ(A)

LocalMemλ(RA) ≈LocalMemλ(A)

Hardness Assumptions The security proofs of Hashed-ElGamal variants are
reduced from the Computational Diffie-Hellman and gap-Diffie-Hellman assump-
tion. Consider the CDH game described in figure 1.

1 In [3], authors defined the local time of the game only by the number of computations
of A. In this paper we explicitly include the number of queries made to the oracle.

7



Game CDH(q, g,G)

1 : x
$←− Z∗q

2 : y
$←− Z∗q

3 : z ← A(gx, gy)

4 : if z = gxy return 1

5 : else return 0

Oracle DDH(X,Y, Z)

1 : if ∃y such that Y = gy and Z = Xy

2 : return 1

3 : else

4 : return 0

Fig. 1. CDH game and gap-DH game. In gap-DH game, A has oracle access to DDH(¡, ¡, ¡)

Definition 3. (gap-Diffie-Hellman Assumption) Let q be a prime. Let G = 〈g〉
be a cyclic group of order q. The (t, Âľ, Îľ) gap-Diffie-Hellman (gap-DH) assump-
tion states that for all adversary A that runs in times t and uses Âľ bites of
memory,

SuccADDH,CDH ≤ ε

The Computational Diffie-Hellman assumption is defined in the same way, except
the condition that A has no access to the DDH oracle.

Key Encapsulation Mechanism A key encapsulation mechanism KEM con-
sists of three algorithms; Gen, Encap, Decap. The key generation algorithm Gen

takes a security parameter 1Îť as input and outputs a public key pk and a se-
cret key sk. The encapsulation algorithm Encap, on input pk, outputs a key-
ciphertext pair (c,K), where K ∈ K for some non-empty set K. c is said to be
the encapsulation of K. The deterministic decapsulation algorithm Decap takes
an encapsulation c as input along with sk, and outputs a key K ∈ K. A KEM is
called δ-correct if

Prob[Decap(sk, c) 6= K|(pk, sk)← Gen; (c,K)← Encap(pk)] ≤ δ

IND-CCA security of a Key Encapsulation Mechanism We recall the
IND-CCA security game for a Key Encapsulation Mechanism in Figure 2.
The IND-CCA advantage of an adversary A against KEM is defined as

AdvIND-CCA
A,KEM

def
=

∣∣∣∣SuccA,IND-CCA −
1

2

∣∣∣∣ .

Public-Key Encryption A public-key encryption scheme consists of three
algorithms, PKE = (Gen, Enc, Dec). There are three sets associated with PKE,
the message spaceM, the randomness space R, and the ciphertext space C. The
key generation algorithm takes the security parameter as input and outputs a
public-key, secret-key pair (pk, sk). The encryption algorithm takes the public

key pk, and a message m ∈ M as input, samples a random string r
$←− R, and

outputs a ciphertext.c← Enc(pk,m, r). The decryption algorithm Dec, on input

8



Game IND-CCA

1 : (pk, sk)← Gen(1λ)

2 : b
$←− {0, 1}

3 : (c∗,K∗0 )← Encap(pk)

4 : K∗1
$←− K

5 : b′ ← ADecap(c∗,K∗b )

6 : if b = b′ return 1

7 : else return 0

Oracle Decap(c)

1 : if c = c∗return ⊥
2 : K ← Decap(sk, c)

3 : return K

Fig. 2. IND-CCA game for KEM

Game COR

1 : (pk, sk)← Gen(1λ)

2 : m← A(pk, sk)

3 : c← Enc(pk,m)

4 : if m 6= Dec(sk, c) return 1

5 : else return 0

Fig. 3. Correctness
game for PKE

sk and a ciphertext c, outputs a message m = Dec(sk, c) ∈ M or a special
symbol ⊥/∈M. We say, c is an invalid ciphertext, if Dec(sk, c) =⊥.
Deterministic Public Key Encryption. We call a public-key encryption
scheme PKE deterministic, if the algorithm Enc is deterministic and for every
message m ∈M, there exists a unique c ∈ C such that Dec(sk, c) = m. We write
c← Enc(pk,m) for deterministic encryption.
Correctness. Following [16], we define the correctness of a public-key encryp-
tion scheme by the security game COR in Figure 3.

Definition 4. Let δ : N → [0, 1] be an increasing function. Consider the game
COR in Figure 3. A public-key encryption scheme PKE is called δ-correct, if for
all adversary A with running time bounded by t,

SuccA,COR[PKE] ≤ δ(t)

where the probability is taken over the randomness of Gen and A. Moreover, we
say PKE is strongly δ correct, if ∀ t, δ(t) ≤ δ.

Game OW-PCVA

1 : (pk, sk)← Gen(1λ)

2 : m
$←−M

3 : c← Enc(pk,m)

4 : m′ ← APCO,CVO(pk, c)

5 : if m′ = Dec(sk, c) return 1

6 : else return 0

Procedure PCO(m, c)

1 : if m = Dec(sk, c) return 1

2 : else return 0

Procedure CVO(c)

1 : m← Dec(sk, c)

2 : if m ∈M return 1

3 : else return 0

Fig. 4. Game OW-PCVA. In the game OW-PCA (resp. OW-VA), A has oracle access
to only PCO (resp. CVO).

Security. Following [16], we define three security games for a public-key en-
cryption scheme, OW-PCA, OW-VA, and OW-PCVA in Figure 4. In OW-PCA

9



game, the adversary has oracle access to PCO. In the OW-VA game, the adversary
has oracle access to CVO. In OW-PCVA game, the adversary has oracle access to
both PCO and CVO. For ATK ∈ {PCA,VA,PCVA}, we define the corresponding
advantages of an adversary A against PKE as

AdvOW-ATK
A,PKE

def
= Prob[OW-ATK[PKE]A = 1]

Random Oracles. An (idealized) function F :; {0, 1}δ → {0, 1}ρ is said to be
a Random Oracle, if for all x ∈ {0, 1}δ, the output F(x) is independently and
uniformly distributed over {0, 1}ρ.

Pseudo-random Functions

Definition 5. Let F : {0, 1}λ × {0, 1}δ → {0, 1}ρ be a deterministic algorithm
and let A be an algorithm. The prf advantage of A is defined as

Advprf
A,F

def
= |Succ(RealA)− Succ(RandomA)|.

F is said to implement a family of (t, d, Îľ)-pseudo-random functions if for all
adversary A that runs in time t and uses memory d,

Advprf
A,F ≤ ε

Simulating Random Oracle using PRF. If a game G is defined in the
random oracle model, then one procedure of the game defines the random oracle
H : {0, 1}δ → {0, 1}ρ. The standard technique to implement the random oracle
procedure is via lazy sampling. However, the lazy sampling technique requires
O(qh ¡ Ν) additional memory where qh is the number of H queries made by the
adversary. In [3], the authors formalized the technique, originally suggested in
[7], of simulating the Random Oracle using a prf. Let G[H] be a game where H

is a random oracle used in G. Let G[F ] be the same game where the random
oracle is implemented using a prf F . Specifically, the oracle H is implemented
using F (k, .) for a randomly sampled key k.

Lemma 1 (RO simulation using prf [3]). For all adversary A against G
making at most qh queries to the random oracle, there exists a BF against F in
the prf game such that∣∣SuccAH,G[H] − SuccAH,G[F ]

∣∣ ≤ Advprf
BF ,F

Moreover, it holds that

LocalTime(BF ) = LocalTime(A) + LocalTime(G) + qh

LocalMem(BF ) = LocalMem(A) + LocalMem(G)

10



Game Real

Procedure main

1 : k
$←− {0, 1}λ

2 : b← AOF

3 : if b = 0

4 : return 1

5 : else

6 : return 0

7 : endif

Procedure OF (x)

1 : return F (k, x)

Game Random

Procedure main

1 : b← AOF

2 : if b = 0

3 : return 1

4 : else

5 : return 0

6 : endif

Procedure OF (x)

1 : y
$←− {0, 1}ρ

2 : return y

Fig. 5. PRF security game

RO simulation by
lazy sampling

Procedure main

Procedure H(x)

1 : if H(x) =⊥

2 : H(x)
$←− {0, 1}ρ

3 : endif

4 : return H(x)

RO simulation using PRF

Procedure main

1 : k
$←− {0, 1}κ

Procedure H(x)

1 : return F (k, x)

Fig. 6. Memory Efficient simulation of
Random Oracle

Procedure Gen(1Îť)

1 : (q, g,G)← DH(1λ)

2 : x
$←− Z∗q

3 : pk = (g, gx)

4 : sk = x

5 : return (pk, sk)

Procedure Encap(pk)

1 : (g, h) = pk

2 : y
$←− Z∗q

3 : Y = gy

4 : Z = hy

5 : K = H(Y,Z)

6 : return (Y,K)

Procedure Decap(sk, Y )

1 : x = sk

2 : Z = Y x

3 : K = H(Y,Z)

4 : return K

Fig. 7. HEG: Cramer-Shoup Version of Hashed-ElGamal KEM. H : G × G → K is a
cryptographic hash function

3 Memory-tight Reductions for Hashed-ElGamal

3.1 Cramer-Shoup Variant

In this section we present a memory-tight reduction of Cramer-Shoup version of
hashed-ElGamal Key Encapsulation mechanism [12]. We describe the scheme in
Figure 7. G is a cyclic group of prime order q. Let H : G × G → K be a hash
function. Our main result in this section is the following theorem.

Theorem 4. Let q be a prime and G be any gap group of order q. Let DDH be
the Decisional Diffie Hellman oracle on G. Let DH be the Diffie Hellman instance
generation algorithm over G. Let F : {0, 1}λ ×{0, 1}×G×G→ K be a prf. Let
Π be the HEG KEM scheme over G and K, with security parameter Ν.

Let A be any adversary in the IND-CCAgame of Π. Suppose A makes qH
hash queries and qD decapsulation queries. Then, in the random oracle model,
there exists an adversary BDH in the gap-DH game, and an adversary BF such
that

11



AdvIND-CCA
A,Π ≤ Advgap-DH

BDH ,G + Advprf
BF ,F

Moreover, it holds that

LocalTime(BDH) ≈LocalTime(A) + (qH + qD) · LocalTime(F ) + qH

LocalMem(BDH) ≈LocalMem(A) + LocalMem(F ) + 7λ+ 1

LocalTime(BF ) ≈LocalTime(A) + LocalTime(DH) + (qH + qD)

LocalMem(BF ) ≈LocalMem(A) + LocalMem(DH) + 11λ+ 2

Before proving the Theorem 4, we construct a prf F̂ : {0, 1}λ×G×G→ K that
we shall use in the proof.

Construction of F̂ . Let DDH be the decisional Diffie-Hellman oracle such that
DDH(X,Y, Z) = 1, if (X,Y, Z) is a valid Diffie-Hellman tuple.

Construction 5 Let G be a group of prime order q and let g be a generator
of G. Fix X ∈ G. Let F : {0, 1}λ × {0, 1} × G × G → K. We define F̂X :
{0, 1}λ ×G×G→ K as follows

F̂X(k, Y, Z) =

{
F (k, 0, Y, Z) if DDH(X,Y, Z) = 0
F (k, 1, Y, g) if DDH(X,Y, Z) = 1

In order to use the map then prf technique, we need the following lemma.

Lemma 2. If F is a prf, then F̂X is a prf. Moreover, for every adversary BF̂
against F̂X , there exists a BF against F such that,

Advprf
BF ,F = Advprf

BF̂ ,F̂

LocalTime(BF ) = LocalTime(BF̂ ) + q

LocalMem(BF ) = LocalMem(BF̂ ) + 2λ.

where q is the number of queries made by BF̂ .

Proof. Fix X ∈ G. Note that for every Y ∈ G, there exists a unique Z ∈ G such
that DDH(X,Y, Z) = 1. We define ψX : G×G→ {0, 1} ×G×G as

ψX(Y, Z) =

{
(0, Y, Z) if DDH(X,Y, Z) = 0
(1, Y, 0Îť) if DDH(X,Y, Z) = 1

It is easy to verify that ψX is an injective function. Moreover, F̂X = F ◦ ψX .
Let O be the oracle of BF . BF chooses x ∈ Z∗q , set X = gx and invokes BF̂ .

For every query (Y, Z) of BF̂ , BF checks whether Y x = Z, computes ψX(Y, Z)

12



accordingly and queries O. The response of the oracle is passed to BF̂ . When BF̂
outputs a bit b, BF outputs b. This perfectly simulates the prf game of F̂X .

We assume the computation time of ψX is constant. In order to simulate the
prf game of F̂X , BF needs to compute ψX for q many times. Moreover, BF needs
store x and a temporary variable for passing the values. The lemma follows. ut

The Reduction. Theorem 4 is proven via a sequence of games. Formal descrip-
tion of the games are given in Figure 8, and Figure 9.

G0 G1

1 : (pk, sk)← Gen(1λ)

2 : Parse pk = (g,X)

3 : Parse sk = x

4 : y∗
$←− Z∗q

5 : b
$←− {0, 1}

6 : Y ∗ = gy
∗

7 : Z∗ = Y ∗
x

8 : K∗0 = H(Y ∗, Z∗) K∗0
$←− K

9 : K∗1
$←− K

10 : b∗ ← ADecap,H(pk, Y ∗,K∗b )

11 : if b = b∗return 1

12 : else return 0

13 : endif

Procedure H(Y,Z) in G0

1 : if H(Y,Z) is undefined

2 : H(Y,Z)
$←− K

3 : endif

4 : return H(Y,Z)

Procedure Decap(Y ) in G0,G1

1 : if Y = Y ∗return ⊥
2 : Z = Y x

3 : K = H(Y,Z)

4 : return K

Procedure H(Y,Z) in G1

1 : if Z = Y x ∧ Y = Y ∗

2 : return K∗0

3 : else

4 : if H(Y,Z) is undefined

5 : H(Y,Z)
$←− K

6 : endif

7 : return H(Y,Z)

8 : endif

Fig. 8. The games G0 and G1. In game G1, Line 8 in replaced by the boxed statement

Game G0. The game G0 is the original IND-CCA game.

AdvIND-CCA
A,Π

def
=

∣∣∣∣Prob[GA0 = 1]− 1

2

∣∣∣∣ .
Game G1: We predefine K∗0 = H(Y ∗, Z∗) by sampling a random element from the
keyspace K. Y ∗ is the challenge ciphertext sent in the KEM game and Z∗ = Y ∗x.
The hash oracle is modified to return K∗0 for the input (Y ∗, Z∗). As K∗0 is still
uniformly chosen at random, and the hash oracle output is consistent, there is
no change in the distribution of adversary’s view.

Prob[GA0 = 1] = Prob[GA1 = 1]

Game G2. In this game the oracles H and Decap are changed. We replace the
random oracle by a prf F̂X : {0, 1}λ×G×G→ K. By Lemma 1, there exists an
adversary BF̂ such that∣∣Prob[GA1 = 1]− Prob[GA2 = 1]

∣∣ ≤ Advprf

BF̂ ,F̂X

13



Game G3. We rewrite the prf evaluation of F̂X using a prf F as defined in
Construction 5. In the procedure Decap of the game G2, Step 2 (Z = Y x)
ensures that F̂X(k, Y, Z) in that procedure always evaluates to F (k, 1, Y, g). As
the view of the adversary remains unchanged,

Prob[GA2 = 1] = Prob[GA3 = 1]

Game G4: In this game, we set a flag Flag and abort on the event that A queries
H on (Y ∗, Z∗) where Y ∗ is the challenge in the KEM game and (X,Y ∗, Z∗) is a
valid diffie hellman tuple. By the fundamental lemma of game playing proofs∣∣Prob[GA3 = 1]− Prob[GA4 = 1]

∣∣ ≤ Prob[Flag = 1].

In the game G4, the adversary A is unable to compute H(Y ∗, Z∗) using either
the hash oracle or the decapsulation oracle. The decapsulation oracle outputs
⊥ whenever the input Y is equal to Y ∗. The hash oracle aborts for the input
(Y ∗, Z∗). This implies that the bit b is independent from the adversary’s view.
Hence

Prob[GA3 ] =
1

2
.

To bound Prob[Flag = 1], we construct an algorithm BDH against the
gap-DH security of G. BDH simulates game G4 for A.

gap-DH adversary BDH . Formal code of BDH is given in Figure 10. BDH
simulates G4. In order to execute line 1 of the game G4, BDH uses the DDH oracle.
By the definition of gap-DH game, X and Y ∗ are uniformly and independently
distributed. Hence the simulation of G4 is perfect. Flag = 1 implies that A
queried H(Y, Z) where Y = Y ∗ and DDH(X,Y ∗, Z) = 1. BDH returns that Z and
wins the gap-DH game. Hence,

Prob[Flag = 1] = Advgap-DH
BDH ,G

Collecting the probabilities, we get

AdvIND-CCA
A,Π ≤ Advgap-DH

BDH ,G + Advprf

BF̂ ,F̂

Efficiency of BDH . BDH runs A, queries DDH oracle for qH many times, com";"""date"",""2020-07-19T07:19:48Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2020-07-19T07:19:48Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.19 (TeX Live 2019/dev/Debian) kpathsea version 6.3.1/dev""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2020-07-19T07:19:48Z""
""created"",""2020-07-19T07:19:48Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-07-19T07:19:48Z""
""resourceName"",""075.pdf""
""Author"",""""
""producer"",""pdfTeX-1.40.19""
""pdf:docinfo:producer"",""pdfTeX-1.40.19""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""6"",""36"",""6"",""1"",""2"",""13"",""5"",""6"",""0"",""2"",""14"",""4"",""0"",""2"",""0"",""2"",""15"",""24"",""41"",""83"",""23"",""56"",""57"",""49"",""18"",""29"",""4"",""0"",""0"",""4"",""7"",""16"",""0"",""2"",""14"",""21"",""3"",""2"",""15"",""8"",""7"",""9"",""3""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2020-07-19T07:19:48Z""
""Last-Modified"",""2020-07-19T07:19:48Z""
""dcterms:modified"",""2020-07-19T07:19:48Z""
""title"",""""
""Last-Save-Date"",""2020-07-19T07:19:48Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2020-07-19T07:19:48Z""
""meta:save-date"",""2020-07-19T07:19:48Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.19 (TeX Live 2019/dev/Debian) kpathsea version 6.3.1/dev""
""Content-Length"",""648082""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""45""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""1971"",""2592"",""2410"",""1934"",""2657"",""2222"",""1738"",""1679"",""1443"",""1572"",""1438"",""1230"",""1486"",""1534"",""1297"",""1105"",""1177"",""1422"",""1455"",""1382"",""1391"",""1410"",""1731"",""1220"",""1593"",""1386"",""1491"",""1342"",""1142"",""2262"",""2619"",""1231"",""1093"",""1859"",""1373"",""957"",""1198"",""1526"",""1217"",""1264"",""1391"",""1684"",""1349"",""1071"",""858""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-07-19T07:19:48Z""
";https://scholar.google.ch/scholar?start=710&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098795-175;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;[PDF][PDF] Design and research of a smart monitoring system for 2019-nCoV infection-contact isolated people based on blockchain and Internet of things technology;L Zheng, C Xiao, F Chen, Y Xiao ;2020 researchsquare.com;;"… 12. Victor F, Zickau S. Geofences on the Blockchain: Enabling Decentralized

Location-based Services[C]//2018 IEEE International Conference on Data Mining

Workshops (ICDMW). IEEE, 2018: 97-104. 13 … 14. Consensys, A visit to the oracle …";Cité 4 fois;;[PDF] researchsquare.com;https://www.researchsquare.com/article/rs-18678/latest.pdf;;;https://scholar.google.ch/scholar?start=720&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098782-146;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;An Adaptively Secure Functional Encryption for Randomized Functions;M Liu, P Zhang ; The Computer Journal, 2020  academic.oup.com;;"… For the indistinguishability-based security, the adversary can query the key generation oracle

for the function |$f$| with the restriction |$f(m_0)=f(m_1)$|? … [12]. In their definition, it allows

the adversary to query the decryption oracle for multiple ciphertexts …";Autres articles;;null;;;;https://scholar.google.ch/scholar?start=690&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098765-108;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;The Long and Winding Path to Secure Implementation of GlobalPlatform SCP10;DDA Braga, PA Fouque, M Sabt ; IACR Transactions on …, 2020  tches.iacr.org;;"… work is to provide pertinent analysis to the GP community, so that their Crypto Sub-Task … Given

this list, we can define oracles strength using a five-character code, each position corresponding …

For instance, a TTTTT oracle will only check if the decrypted message begins with 00 …";Autres articles;;[PDF] iacr.org;https://tches.iacr.org/index.php/TCHES/article/download/8588/8155;"
IACR Transactions on Cryptographic Hardware and Embedded Systems
ISSN 2569-2925, Vol. 2020, No. 3, pp. 196–218. DOI:10.13154/tches.v2020.i3.196-218

The Long and Winding Path to Secure
Implementation of GlobalPlatform SCP10

Daniel De Almeida Braga, Pierre-Alain Fouque and Mohamed Sabt

Univ Rennes, CNRS, IRISA, Rennes, France, first-name.last-name@irisa.fr

Abstract. GlobalPlatform (GP) card specifications are defined for smart cards
regarding rigorous security requirements. The increasingly more powerful cards
within an open ecosystem of multiple players stipulate that asymmetric-key protocols
become necessary. In this paper, we analyze SCP10, which is the Secure Channel
Protocol (SCP) that relies on RSA for key exchange and authentication. Our findings
are twofold. First, we demonstrate several flaws in the design of SCP10. We
discuss the scope of the identified flaws by presenting several attack scenarios in
which a malicious attacker can recover all the messages protected by SCP10. We
provide a full implementation of these attacks. For instance, an attacker can get
the freshly generated session keys in less than three hours. Second, we propose a
secure implementation of SCP10 and discuss how it can mitigate the discovered flaws.
Finally, we measure the overhead incurred by the implemented countermeasures.
Keywords: SCP10 ¡ Java card ¡ Bleichenbacher ¡ Coppersmith

1 Introduction
Smart cards are increasingly used to provide secure services: in communication as SIM
cards 1, in banking as payment cards and in authentication systems as hardware tokens.
This is due to the fact that they are highly certified (a Common Criteria 4+ and above
certification). Nevertheless, smart cards are not resilient to attacks. In particular, a
popular attack vector is their communication system.

Smart cards communicate with external entities via a logical channel called Application
Protocol Data Unit (APDU), which is equivalent to the TCP/IP protocol for the Internet.
Similar to TCP/IP, the APDUs were not intended to be a secure protocol in the beginning
despite its applications in a security-centric ecosystem. Subsequent standards for smart
cards amend this misstep by proposing the Secure Channel Protocol (SCP) [Tec18]. As its
name indicates, SCP channels prevent communication with the card from being observed
or tampered. SCP01, SCP02, and SCP03 (which are respectively version 1, 2 and 3 of
SCP) are symmetric keyed ciphering mechanisms using DES (in SCP01), TDES with two
keys (in SCP02) and AES (in SCP03). Despite its recent deprecation, many cards still use
by default SCP02 with TDES-based CBC block ciphering mode.

As the related ecosystem evolves, multiple parties are being increasingly involved, and
thus symmetric ciphers requiring shared secrets are becoming less relevant. Therefore,
the GlobalPlatform organization defines two SCP channels relying on asymmetric-key
cryptography: SCP10 and SCP11. Asymmetric cryptography usually leverages on wrapping
symmetric session keys with asymmetric encryption or key negotiation. There are two
main advantages of using SCP10/SCP11 over SCP03: (1) keys management is more
straightforward, since no secret keys are ever shared, and (2) Forward Secrecy is more

1reaching 5.6 billion shipped cards in 2018 according to SIMalliance [SIM19]

Licensed under Creative Commons License CC-BY 4.0.
Received: 2020-01-15 Accepted: 2019-03-15 Published: 2020-06-19

https://doi.org/10.13154/tches.v2020.i3.196-218
mailto:first-name.last-name@irisa.fr
http://creativecommons.org/licenses/by/4.0/


Daniel De Almeida Braga, Pierre-Alain Fouque and Mohamed Sabt 197

easily enforced. More importantly, SCP02 and SCP03 ensure the generation of new session
keys by maintaining a counter within the key derivation process. For instance, the counter
is only 2-byte long. This means that after 216 sessions, the long-term secret key must be
changed. In SCP10, no counter is required, as the process of key generation/derivation
only uses freshly generated random bytes without maintaining any stateful information.

Despite its advantages, SCP10 has not yet been publicly deployed in the market. This
is mainly due to technical reasons regarding RSA. Indeed, for a long time, RSA has not
been available on all smart cards [JCA19]. In addition, it is slower compared to faster
symmetric-key ciphers. However, the trend is changing and RSA is finding more support,
benefiting from an overhead reduction brought by cryptographic co-processors that cards
already possess. We believed that the current absence of public implementation of SCP10
is because smart cards are slow to develop any modification: SCP03 required almost 8
years for its first implementation despite its similarities to the widely deployed SCP02.

In spite of the existence of an elliptic curve based variant (SCP11), we argue that
SCP10 may find adoption within the near future. Indeed, in the last version of the
specification [Tec18], GlobalPlatform revised the family of secure channel protocols: the
document removes the deprecated SCP01 and deprecates SCP02 after successful attacks
caused by padding attacks and CBC-encryption with constant IV. However, no modification
was made to SCP10, and SCP11 is still defined only as an Amendment. Besides, some
patents using SCP10 have been filled by both Huawei and the China Construction Bank
in 2018, reflecting its foreseeable adoption.

Our Contribution
In this paper, we scrutinize the specifications of SCP10. The interest of our study is that
SCP10 is becoming more relevant than ever because of an ecosystem increasingly open,
but not yet implemented. The stringent requirements of smart cards about security make
them so slow to change. In addition, many of their systems cannot be updated once they
are deployed. This explains why, notwithstanding its deprecation, SCP02 is still widely
used in the wild. Much to our surprise, we find that SCP10 is vulnerable to well-known
security flaws caused by deterministic padding for RSA encryption.

Indeed, we first note that SCP10 encrypts the random data used for the process of key
derivation using RSA without any random padding. Although the specifications claim
the use of PKCS#1 v1.5 for data encryption, the underlying technical details mandate a
constant padding concatenated after the 0x0002 string. Then, we exploit this observation
by two means. First, the rigid messages format of GlobalPlatform SCP makes the major
part of the encrypted message constant in a discernible way: a big known part and a much
smaller unknown part. Here, we apply the Coppersmith attack that solves univariate
modular equations to decrypt the whole message. Second, we apply the Bleichenbacher
attack that leverages a format oracle to compute modular exponentiation of an arbitrary
value over the private exponent without any knowledge of the private key. Attackers
can take advantage of this attack in twofold ways: decryption of sensitive messages and
signatures forgery to impersonate smart cards.

Our contributions can be summarized as follows:

• We identify various design flaws in the SCP10 specifications that allow attackers to
mount practical attacks.

• We implement SCP10 with JavaCard and evaluate the complexity of our attacks on
real smart cards.

• We propose a secure implementation of SCP10 and evaluate its overhead. Our
implementation complies with the latest NIST recommendation in terms of Key
Agreement [BCR+19].



198 The Long and Winding Path to Secure Implementation of GlobalPlatform SCP10

The goal of our work is to provide pertinent analysis to the GP community, so that
their Crypto Sub-Task force can take informed decisions when deciding how to fix the
identified problems with SCP10. Of independent interest, our work underlines the fact
that security in standards undergone rigorous verification is still vulnerable to well-known
attacks. It is worth mentioning that SCP10 still complies with the NIST recommendations
with respect to RSA: PKCS#1 v1.5 is disallowed starting from 2024, and the defined
key-transport and key-agreement are disallowed starting from 2021 [BR19]. We encourage
the adoption of provable secure cryptosystems that we propose in our amendments, such
as RSA OAEP, that make SCP10 more resilient to such attacks.

Attack Scenario. Smart cards are embedded into connected devices, such as smartphones.
Service providers transmit some sensitive data to clients smart cards. Very often, this
communication occurs remotely over-the-internet or another non-secure channel. We
suppose that there are some attackers who can intercept and manipulate the exchanged
messages between the service provider and the smart card; otherwise there is no need to
the SCP standards. The goal of the attackers is to put their hands on the transmitted
sensitive data. This includes PIN codes, proprietary applications or personal identification
credentials.

Leveraging the vulnerabilities described in this paper, attackers can accomplish their
goal in two ways. First, they can recover the freshly generated session keys by decrypting
the messages wrapping them. Here, Coppersmith and Bleichenbacher attacks apply.
Second, attackers can forge a certificate allowing them to impersonate valid smart cards.
Thus, service providers might successfully initiate an SCP10 channel with an attacker
who will receive all the messages intended to valid cards. Here, Bleichenbacher alongside
key reuse make this attack practical. Our evaluation shows that recovering session keys
is much faster than forging certificates. Nevertheless, the former compromises only one
session, while the latter would still work across multiple sessions.

Responsible Disclosure. Our findings have been timely reported to GlobalPlatform
following their responsible disclosure process. The GlobalPlatform Security Task Force
was quite responsive and acknowledged our results. They also organized several meetings
in order to present the identified vulnerabilities to their concerned industrial partners. We
have shared a draft of this paper as well as our PoC code with the interested partners. We
also provide our support, so that most of our countermeasures are taken into account in a
fix of SCP10 to be rolled out.

Related Work
GlobalPlatform Secure Channel Protocol. The family of SCP protocols is mainly de-
ployed on smart cards, most of which are a subject of rigorous certification defined by
Common Criteria (CC). A popular certification process for smart cards is EAL4+, which
is a high certification level required for sensitive applications. Despite their importance,
the SCP protocols have been overlooked in the literature for a long time. To the best of
our knowledge, Sabt et al. in [ST16] provided the first cryptanalysis for both SCP02 and
SCP03. In their work, they showed a theoretical attack against SCP02 due to misuse of
Initialization Vector (IV) in CBC mode. More importantly, they highlighted the limit of
the enterprise of certification compared to using provably-secure cryptographic schemes,
since SCP02 is the most widely deployed within the SCP family. In addition, they proved
that SCP03 provides stronger security guarantees by preventing Algorithm Substitution
Attack (ASA) [BJK15]. In [AF18], Avoine et al. showed more practical attack against
SCP02 in which they exploit CBC padding oracles in order to recover some secret data.
Consequently, SCP02 was officially deprecated by GlobalPlatform.



Daniel De Almeida Braga, Pierre-Alain Fouque and Mohamed Sabt 199

Coppersmith Short Pad Attack. In order to avoid the problems related to deterministic
encryption, some random padding is often appended to the message before encryption.
Coppersmith pointed out the danger of such approach of padding by improving the
Franklin-Reiter Related Message Attack [CFPR96]. Indeed, an attacker can decrypt the
message if the constant unknown part of the message is big enough with regard to the
random part. However, we only recover the constant part and we do not get the random
padding. This attack is not applicable in the context of SCP10 due to its special padding.
Indeed, SCP10 uses some constant string for padding to encrypt some random data, namely
the session keys. Loosely speaking, this is equivalent to the previous case. Nevertheless, the
difference here is that we also require to recover the random data. Therefore, we implement
the Coppersmith’s Algorithm in [Cop97] that allows us to recover the whole encrypted
message. In ACM CCS 2017, Nemec et al. in [NSS+17] discovered a critical vulnerability
in deployed smart cards by recovering their RSA private keys using an optimized version
of the Coppersmith’s method in [Cop96]. This work is out of scope of our paper, since we
do not focus on the generation of the RSA keys.

Bleichenbacher Attack and Key Reuse. Strangely, the seminal work of Daniel Bleichen-
bacher in [Ble98] has not discouraged implementers and protocols designers to continue
using RSA with PKCS#1 v1.5 padding. Indeed, even NIST does not strongly inhibit it in
their latest recommendation [BR19]: PKCS#1 v1.5 is disallowed only starting from 2021.
Thus, Bleichenbacher attack is still unfortunately applicable to various applications and de-
ployed systems: myriad of cryptographic libraties (OpenSSL, BoringSSL, etc.) [RGG+19],
TLS 1.3 and QUIC [JSS15], JSSE (Java Secure Socket Extension) [MSW+14], XML en-
cryption [JSS12], and many web servers including Facebook and PayPal [BSY18]. To the
best of our knowledge, our paper is the first work to apply the Bleichenbacher attack in the
context of smart cards and GlobalPlatform protocols. Moreover, we demonstrate that key
reuse across multiple usage extends the attack by allowing attackers to forge signatures.
Similar approaches can be found in [FGS+18, DLP+12].

2 Background
In this section, we briefly introduce some basic notions of the RSA cryptosystem. In
addition, we also present both Coppersmith and Bleichenbacher attacks. For more details,
please refer to [Cop97, Ble98]. Further background is presented in Appendix A.

All byte values are written as 5B. 5Bi denotes the string made of i bytes of value 5B.
The symbol || denotes concatenation. Unless specified otherwise, (n, e) corresponds to an
RSA-1024 public key, and d to the corresponding private key. This key can be used to
produce a ciphertext c corresponding to a padded message m.

2.1 The RSA Cryptosystem
The Size of the Public Exponent e. For efficiency reasons, e is chosen to be small,
which leads to fast encryption and fast signature verification. The NIST recommends
the use of 216 < e < 2256 [Nat13]. However, the European Payment Council only warns
about e = 3 if the encrypted message is shared among at least three users and sees no
objection otherwise [Eur18]. This means that protocols between two parties can use smaller
exponents, which is the case of most card protocols and their related payment systems.

Padding. The naive RSA, also called Textbook RSA, is not secure due to two undesirable
properties: malleability and determinism. Thus, a very common practice for encrypting
or signing a message m is to first apply an encoding scheme x = Âľ(m) during encryp-
tion/signing and to apply a decoding scheme after decryption/verification. Very often, this



200 The Long and Winding Path to Secure Implementation of GlobalPlatform SCP10

process of encoding is called padding. The PKCS#1 standard incorporates several padding
schemes. In smart cards, the most widely supported one is PKCS#1 v1.5 for encryption
and signing. Indeed, according to [JCA19], 97% of the tested cards supports it, while only
23% supports OAEP for encryption and 29% supports PSS for signing. Moreover, SCP10
relies on (a variant of) PKCS#1 v1.5 padding. Given a message m, we briefly describe the
padding scheme (encoding) as follows:

Encryption: EM(m) = 0x00 || 0x02 || PS || 0x00 || m

Signing: EM(m) = 0x00 || 0x01 || 0xFF...FF || 0x00 || m,

where PS is a random string of length at least 8 bytes.
After decryption/verification, the padding is verified. For decryption, for instance, the

result is verified to start with 0x00 0x02, followed by at least 8 non-null bytes that ends
with 0x00. If the decoding does not comply, the decryption function fails.

2.2 Coppersmith’s Attack
In his groundbreaking work, Coppersmith [Cop97] proposed a method to find small solutions
of univariate modular equations with modulus having an unknown factorization. This
method allows a passive attacker intercepting an RSA ciphertext to decrypt it providing
the size of the secret data is small enough. Indeed, let m be a message consisting of two
parts: a known part k and a secret one s: m = k + s. Each part must be consecutive.
Suppose c = (k + s)e mod n, the attacker can build the modular polynomial equation
f(x) = (k + s)e − c mod n and recover s as long as |s| < n1/e.

The main idea of the algorithm is to find a polynomial h with small norm having the
same roots as f . The polynomial h can be constructed by looking for an integer linear
combination of the polynomials gu,v(x) = nm−vxuf(x)v, for some integer m and varying
values for u and v. The short vectors of the Lattice L spanned by gu,v yield the small
roots we are looking for. The LLL algorithm [LLL82] is used to find such short vectors. A
simplified approach is given by Howgrave-Graham in [HG97].

2.3 Bleichenbacher’s Attack
Bad padding causes decryption failure. In practice, numerous systems prefer to report
such an error to the user. Bleichenbacher [Ble98] showed that this error message has severe
consequences against PKCS#1 v1.5: chosen-ciphertext attackers can decrypt an arbitrary
ciphertext. The attack is not limited to decryption; forging signatures is possible. Indeed,
the Bleichenbacher’s attack allows computing modular exponentiation of an arbitrary value
over the private exponent without any knowledge of the private key. There are two steps:
Blinding and range reducing. We note that Blinding is the most time-consuming step.
We also note that Bardou et al. [BFK+12] described performance improvements. The
optimization is applicable in our case, and we will describe them later in Section 4.3.3.

The broad range of attack exploiting this vulnerability shows the diversity in which such
an oracle occurs, from error code ([BSY18]) to subtle side-channel leakage ([RGG+19]).
In Appendix A, we give an overview of the original attack [Ble98].

3 SCP10 (Secure Channel Protocol 10)
GlobalPlatform card specification [Tec18] defines a set of standards relating to the de-
ployment and management of applications on smart cards. Within the GP architecture,
the security domain (SD) is the entity that supports various cryptographic operations,
including secure communication with an off-card entity (OCE) that might be the card
issuer or an application provider. GP defines a family of protocols called secure channel



Daniel De Almeida Braga, Pierre-Alain Fouque and Mohamed Sabt 201

protocol (SCPs) to provide secure communication. Here, we are solely interested in SCP10,
as the security analysis of SCP02 and SCP03 has been done in [ST16, AF18].

Similar to many secure communication channels, SCP10 executes two steps whenever a
secure session is required: (1) initialization involving key exchange and entities authenti-
cation; and (2) secure transmission in which data are protected during communication
using the generated sessions keys. The security of the first step is crucial, since com-
promising the sessions keys undermines the security of any subsequent communication
in the established session. The particularity of SCP10 is that it leverages asymmetric
cryptography. Indeed, unlike SCP02 and SCP03, it relies on RSA for the initialization
step. In follows, we summarize the fundamentals of SCP10 that are relevant to our paper.

3.1 Keys Management
We recall that any SCP is established between an OCE and an SD. Each entity stores its
own RSA key pair. In addition, any OCE is expected to store the public key of the security
domain. In case an OCE does not know the SD’s public key, it can issue the Get Data
[certificate] command. As for the SD, it holds the public keys of all the previously validated
OCEs, sent by the command Perform Security Operation [verify certificate]. This
command supplies a chain of certificates for verification. Only one public key is active at a
time. As a result, before starting an SCP10 connection, the communicating OCE shall
ensure that the SD would use the proper key. Otherwise, it asks the use of a different
public key with the Manage Security Environment command. This command, noted
MSE, can be sent by anyone in order to indicate the setup configurations of SCP10.

3.2 Initialization
The purpose of this step is to establish a secure authenticated channel by generating
session keys and authenticating the communicating entities (i.e. the OCE and the SD).
To this end, SCP10 leverages on wrapping symmetric sessions keys with RSA encryption.
The specifications define two modes (chosen by the MSE command): (1) Key Transport
in which the OCE forces the keys onto the SD, or (2) Key Agreement where both sides
work together to come out with half of the random bytes and perform some operations on
the random bytes to derive session keys. If Key Agreement shines as the best mode in
terms of security, Key Transport allows better performance for the card. Given the long
history of efficiency/security trade-off in the the smart card industry, it is fair to assume
that Key Transport would be implemented and used in some cases.

Figure 1 summarizes the SCP10 flow. Optional APDUs are represented in grey, and dou-
ble arrows indicate that SD has to perform some computation instead of simply processing
the input and return an error code. As mentioned in the specification [Tec18] (Appendix
F, chapter 1.4), one of the firsts commands, called Perform Security Operation
[decipher], contains the key material to be used in the subsequent communication. Confi-
dentiality is protected by encrypting the data with the SD’s public key. This command
can be ignored in Key Agreement. Then, the OCE issues the External Authenticate
command in order to prove its identity to the SD. Here, the OCE computes the hash of
some data concatenated to the card challenge obtained by the Get Challenge command.
A signature is computed over the hash using the OCE’s private key. In Key Agreement, the
signature is performed over the hash and the random bytes used to derive the session keys.
Therefore, only in this mode, the signature is encrypted with SD’s public key. Finally, the
Internal Authenticate command is sent to verify the SD. It works as follows: the
OCE sends a challenge to the SD that computes a hash of the challenge and the exchanged
session keys. This hash is then signed by the SD’s private key. In Key Agreement, the
signature is performed over the hash and the other half of the random bytes used to derive
the keys. Therefore, the signature is also encrypted with the OCE’s public key.



202 The Long and Winding Path to Secure Implementation of GlobalPlatform SCP10

(a) Key Transport mode (b) Key Agreement mode

Figure 1: SCP10 initialization flow in both key exchange mode

It is important to note that SCP10 uses the same set of RSA keys for both modes
and for encryption/signing. Highly relevant to our paper, we describe, for each mode, the
message formats and the used paddings.

3.2.1 Key Transport Padding

We note (pubKOCE, privKOCE) (resp. (pubKSD, privKSD)) the OCE’s (resp. SD’s) RSA key
pair. We refer by params all values whose confidentiality is not needed, including the
security level and some algorithms ID (e.g. hash functions). Out of scope of this paper,
we do not detail the data used to compute the hash values.
• Perform Security Operation [decipher] (encrypted by pubKSD):

0x0002 || 0xFF..FF || 0x00 || params || session keys.
• External Authenticate (signed by privKOCE):

0x0001 || 0xFF..FF || 0x00 || params || hash(data).
• Internal Authenticate (signed by privKSD):

0x0001 || 0xFF..FF || 0x00 || params || hash(data).

3.2.2 Key Agreement Padding

We use the same notations as in the previous subsection. In addition, we refer by PS
random padding bytes of a certain length.
• External Authenticate (signed by privKOCE, then encrypted by pubKSD):

0x6A || PS || params || OCE Secret || hash(data) || 0xBC.
• Internal Authenticate (signed by privKSD, then encrypted by pubKOCE):

0x6A || PS || Card Secret || hash(data) || 0xBC.

3.3 Secure Transmission
Once the channel is established, confidentiality is ensured using 3DES in CBC mode. As
for integrity, it is protected through DES Retail MAC. If both are mandated, data is first
encrypted, and then the MAC is calculated over the ciphertext (Encrypt-then-MAC).

We underline that the specifications instruct to always set the encryption IV (Initializa-
tion Vector) to zero for encryption. This raises a known vulnerability described in [ST16].
Since we do not focus on this part, we skip the details that can be found in [Tec18].



Daniel De Almeida Braga, Pierre-Alain Fouque and Mohamed Sabt 203

4 Design flaws
In this section, we scrutinize the specifications of SCP10 looking for exploitable flaws. We
find that SCP10 is vulnerable to various security flaws mainly caused by its underlying
cryptographic mechanisms. We first note that SCP10 encrypts the exchanged keys session
using PKCS#1 v1.5 RSA with no random padding. In addition, the same RSA key pair is
used for both confidentiality and authentication purposes in the two defined modes. This
results in attackers recovering session keys and forging certificates to impersonate cards.

One may argue about the interest to study SCP10 for which there is no public
implementation. We claim that SCP10 is becoming more relevant because of the ecosystem
that is getting increasingly open. Moreover, smart cards cannot update their running
system once they are deployed; they are so slow to integrate fixes, and therefore security
analysis should be anticipated. For instance, SCP02 is still widely used in the wild despite
its deprecation. Our purpose of this paper is to avoid the deployment of a security protocol
with a compromised design that can lead to broken implementations. Furthermore, SCP10
relies on cryptographic schemes that will be disallowed soon enough, so that they shall not
be implemented in smart cards: key establishment in 2021 and PKCS#1 v1.5 in 2024.

Below, we outline the identified flaws, present related attack scenario, and define
practical realization.

4.1 Threat Model
In order to leverage the identified design flaws, the attacker requires three capabilities:

• Initiate an SCP10 channel with an SD. This does not mean that the triggered
initialization will end successfully.

• Intercept, read and modify plaintext messages that are transmitted between a
legitimate OCE and the card.

• Measure the time needed by the card to perform several operations.

A concrete attack scenario we consider in this work is recovering the exchanged session
keys despite being encrypted by an 1024-bit key. To this end, the attacker does not require
to have a physical access to the smart card (i.e. no physical side-channel capabilities).
Instead, remote attacks are possible if the attacker obtains a network man-in-the-middle
position. However, we stress that she cannot break the used cryptographic protection (e.g.
directly decrypting messages or forging signatures).

4.2 Deterministic RSA Encryption Padding
As mentioned previously, in Key Transport mode, the message meant to transmit session
keys is encrypted using the SD’s public key. The keys are embedded into a data structure
called Control Reference Template (CRT), and the padding in Section 3.2 is applied.

Strangely, this padding is once referred as ""PKCS#1 v1.5 padding"" in [Tec18] section
B.3.1.2, but it does not correspond to any padding described in the aforementioned standard.
In fact, it seems to be a mix of both encryption (the two leading bytes) and signature
paddings (the constant string 0xFF || ¡ ¡ ¡ || 0xFF). This implies that the encryption
is deterministic, and therefore if an OCE sends the same message twice, the resulting
ciphertext will be the same. Such a property is unfortunate and can be exploited to mount
dictionary or Meet-in-the-Middle attacks to recover the encrypted message (extending the
method described in [BJN00] to a deterministic padding).

Nevertheless, in this particular context, determinism is only a theoretical vulnerability
since it would be unlikely that the same session keys (the variable data within Perform
Security Operation [decipher]) would be sent more than once. Moreover, the outcome



204 The Long and Winding Path to Secure Implementation of GlobalPlatform SCP10

would be limited: the attacker would only recognize previously session keys. This is
because a dictionary attack would have a tremendous memory complexity, as for a Meet-
in-the-Middle attack due to the high number of unknown bits (even if the latter is a far
better alternative). These options are not discussed in further details through this paper.

A more important consequence of this particular padding is the known structure of the
message. Indeed, the biggest part of the messages is constant and publicly known. This
allows adversaries to recover the unknown part (i.e. the session keys) by performing the
Coppersmith attack as described in [Cop97] and reminded in Section 2.2.

4.2.1 Exacerbating Specifications

Deterministic RSA encryption is a bad practice, and we think it shall be mended indepen-
dently from any attack scenario. However, we go further and show how an attacker can
take an advantage of it. Once again, SCP10 is yet to be deployed, and therefore we only
highlight the part in the specifications that can result in practical attacks. We note that
all the future implementations are not necessarily vulnerable, but the lax specifications do
not rule out the implementation choices that we present below.

Small public exponent. The specifications do not exclude that SD might use small public
exponent. In addition, the European Payment Council in its last report in 2018 [Eur18]
does not proscribe that use neither in the context of two-party communication.

Small amount of unknown data. Enough bits of the encrypted message of Perform
Security Operation [decipher] must be known to the attacker. For instance, for a
1024-bit modulus and e = 3, the unknown part must be at most

⌈
log2(n 1

3 )
⌉

= 341 bits
long. This holds if at most 42 bytes need to be sent (prior to padding). Given the format
of a CRT (described in [Tec18], section F.3.1.2), this corresponds to the transmission of
a single CRT. A naive way to proceed, which complies to the specification, would be to
encrypt each CRT independently, and to transmit them in different APDU packets.

We noted that in order to reduce the size of the unknown part of the message, an
attacker can generate all possible CRT headers and apply the attack to each candidate,
reducing the unknown part to the trailing couple formed by the key and the IV. Doing so,
the bound allowing the attack would be met for the transmission of two CRTs if no IV are
added. This generation can be pre-computed once and for all, and stored in memory.

4.2.2 Attack Description

Given an encrypted Perform Security Operation [decipher] message (intercepted
by any means), the attacker can recover the session keys using the pseudo-code given
in Algorithm 1. The function CoppersmithAttack corresponds to the original attack
presented in [Cop97]. An overview of the concept is described in Section 2.2. No queries
are needed. Thus the attacker can just intercept the messages of a secure session, and then
recover the session keys offline in order to be able to read the exchanged messages.

We noted that using the bivariate modular form of Coppersmith’s attack ([Cop97]), an
attacker could recover up to two sessions keys by considering the following polynomial :

f(x, y) = (p+ x+ 2ky)e − c mod n,

with x and y the unknown sessions keys (and potential IV), k the size of a CRT header and
x in bits, and p the known bytes of the padding and CRTs headers. However, due to the
complexity of this variant and the small size of a CRT header, combining the univariate
form with some exhaustive search of the remaining bits yield better results in practice.



Daniel De Almeida Braga, Pierre-Alain Fouque and Mohamed Sabt 205

Algorithm 1 Coppersmith attack over Perform Security Operation [decipher]
Input:

headers : Possible CRT headers
(n, e) : SD’s RSA public key

Output:
r : The decrypte";"""date"",""2020-06-18T12:53:43Z""
""pdf:PDFVersion"",""1.5""
""xmp:CreatorTool"",""LaTeX with hyperref""
""pdf:docinfo:title"",""The Long and Winding Path to Secure Implementation of GlobalPlatform SCP10""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""IACR Transactions on Cryptographic Hardware and Embedded Systems, DOI:10.13154/tches.v2020.i3.196-218""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""The Long and Winding Path to Secure Implementation of GlobalPlatform SCP10""
""xmp:CreateDate"",""2020-06-18T12:53:43Z""
""modified"",""2020-06-18T12:53:43Z""
""cp:subject"",""IACR Transactions on Cryptographic Hardware and Embedded Systems, DOI:10.13154/tches.v2020.i3.196-218""
""pdf:docinfo:subject"",""IACR Transactions on Cryptographic Hardware and Embedded Systems, DOI:10.13154/tches.v2020.i3.196-218""
""pdf:hasMarkedContent"",""false""
""xmp:ModifyDate"",""2020-06-18T12:53:43Z""
""pdf:docinfo:creator"",""Daniel De Almeida Braga, Pierre-Alain Fouque and Mohamed Sabt""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.19 (TeX Live 2019/dev/Debian) kpathsea version 6.3.1/dev""
""meta:author"",""Daniel De Almeida Braga"",""Pierre-Alain Fouque and Mohamed Sabt""
""trapped"",""False""
""meta:creation-date"",""2020-06-18T12:53:43Z""
""created"",""2020-06-18T12:53:43Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-06-18T12:53:43Z""
""resourceName"",""8155""
""Author"",""Daniel De Almeida Braga"",""Pierre-Alain Fouque and Mohamed Sabt""
""producer"",""pdfTeX-1.40.19""
""pdf:docinfo:producer"",""pdfTeX-1.40.19""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""2"",""0"",""0"",""0"",""0"",""6"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""3""
""dc:description"",""IACR Transactions on Cryptographic Hardware and Embedded Systems, DOI:10.13154/tches.v2020.i3.196-218""
""Keywords"",""SCP10, Java card, Bleichenbacher, Coppersmith"",""SCP10, Java card, Bleichenbacher, Coppersmith""
""access_permission:modify_annotations"",""true""
""dc:creator"",""Daniel De Almeida Braga"",""Pierre-Alain Fouque and Mohamed Sabt""
""description"",""IACR Transactions on Cryptographic Hardware and Embedded Systems, DOI:10.13154/tches.v2020.i3.196-218""
""dcterms:created"",""2020-06-18T12:53:43Z""
""Last-Modified"",""2020-06-18T12:53:43Z""
""dcterms:modified"",""2020-06-18T12:53:43Z""
""title"",""The Long and Winding Path to Secure Implementation of GlobalPlatform SCP10""
""xmpMM:DocumentID"",""uuid:8d7a8d18-d754-4188-9cea-3e4c9595959b""
""Last-Save-Date"",""2020-06-18T12:53:43Z""
""pdf:docinfo:keywords"",""SCP10, Java card, Bleichenbacher, Coppersmith""
""pdf:docinfo:modified"",""2020-06-18T12:53:43Z""
""meta:save-date"",""2020-06-18T12:53:43Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.19 (TeX Live 2019/dev/Debian) kpathsea version 6.3.1/dev""
""Content-Length"",""581325""
""Content-Type"",""application/pdf""
""xmp:MetadataDate"",""2020-06-18T12:53:43Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Daniel De Almeida Braga"",""Pierre-Alain Fouque and Mohamed Sabt""
""pdf:producer"",""pdfTeX-1.40.19""
""dc:subject"",""SCP10, Java card, Bleichenbacher, Coppersmith"",""SCP10, Java card, Bleichenbacher, Coppersmith""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""23""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""2917"",""3263"",""3381"",""3205"",""3004"",""3431"",""1679"",""3064"",""3052"",""2186"",""3232"",""2494"",""1443"",""2914"",""3153"",""2531"",""1800"",""3131"",""2785"",""2450"",""2370"",""2424"",""2490""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""SCP10, Java card, Bleichenbacher, Coppersmith"",""SCP10, Java card, Bleichenbacher, Coppersmith""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-06-18T12:53:43Z""
";https://scholar.google.ch/scholar?start=650&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098778-134;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;On the Hardness of Massively Parallel Computation;KM Chung, KY Ho, X Sun ; Proceedings of the 32nd ACM Symposium …, 2020  dl.acm.org;;"… and for each i ? [T], the values of next node i + 1 is obtained by using ?i to select an input x?i

and query the oracle on (i … Specifically, in our proof, we enumerate all the oracles with dif- ferent

sequences of k consecutive ?'s, say ?i , ..., ?i+k , and run the machine on these oracles …";Autres articles;;[PDF] arxiv.org;https://arxiv.org/pdf/2008.06554;"
On the Hardness of Massively Parallel Computation

Kai-Min Chung
Academia Sinica

kmchung@iis.sinica.edu.tw

Kuan-Yi Ho
University of Texas at Austin

kyho@cs.utexas.edu

Xiaorui Sun
University of Illinois at Chicago

xiaorui@uic.edu

Abstract

We investigate whether there are inherent limits of parallelization in the (randomized) mas-
sively parallel computation (MPC) model by comparing it with the (sequential) RAM model.
As our main result, we show the existence of hard functions that are essentially not paralleliz-
able in the MPC model. Based on the widely-used random oracle methodology in cryptography
with a cryptographic hash function h : {0, 1}n → {0, 1}n computable in time th, we show that
there exists a function that can be computed in time O(T ¡ th) and space S by a RAM algo-
rithm, but any MPC algorithm with local memory size s < S/c for some c > 1 requires at least
Ω̃(T )1 rounds to compute the function, even in the average case, for a wide range of param-

eters n ≤ S ≤ T ≤ 2n
1/4

. Our result is almost optimal in the sense that by taking T to be
much larger than th, e.g., T to be sub-exponential in th, to compute the function, the round
complexity of any MPC algorithm with small local memory size is asymptotically the same
(up to a polylogarithmic factor) as the time complexity of the RAM algorithm. Our result is
obtained by adapting the so-called compression argument from the data structure lower bounds
and cryptography literature to the context of massively parallel computation.

1Throughout the paper, we use the convention Ω̃(T ) = Ω(T/polylog(T )) and Õ(T ) = O(T · polylog(T ))

ar
X

iv
:2

00
8.

06
55

4v
1 

 [
cs

.D
S]

  1
4 

A
ug

 2
02

0



1 Introduction

In the last decade, there has been significant development of parallel computation. Modern parallel
computation frameworks such as MapReduce, Hadoop, and Spark are designed to manipulate large-
scale data sets and share a number of common properties. Modeling and analyzing these frameworks
algorithmically help us confirm the practical success theoretically and the new ideas created in the
process may also be adapted to enhance the performance of these practical frameworks. To this
end, much effort has been made to model the essential properties behind these frameworks and
explore the power of the developed model.

The first theoretic model capturing the modern parallel computation frameworks has been pro-
posed by Karloff, Suri, and Vassilvitskii [47]. Ever since then, the theoretical study of these frame-
works started to increase rapidly and several refinements of the model along with new algorithms
have been proposed [7, 32, 46, 47, 48, 51, 55, 64].

The Massively Parallel Computation (MPC) model consists of m machines and each of them
has local memory of size s. The input is partitioned arbitrarily across all the machines and the
computation proceeds in synchronized rounds. In each round, each machine is able to do any
computation on its own memory. After the computation is done, each machine computes a set of
messages. Then, the underlying system will direct the messages to the corresponding machine. As,
in practice, most costs come from the network communication, the goal is to minimize the round
complexity. Also, to rule out the trivial algorithm, common constraints require that given input of
size N , ms = Θ(N) and N ε ≤ m ≤ N1−ε for some constant ε > 0.

Many computational problems, such as graph problems [2, 7, 8, 9, 10, 11, 13, 14, 15, 20, 21,
27, 30, 32, 41, 44, 40, 49, 51, 59, 63], clustering [16, 18, 36, 43, 65] and submodular function
optimization [33, 37, 48, 56], have been studied in this model, with an emphasis on developing
algorithms that minimize the number of communication rounds. For example, recently, [46] showed
that massively parallel computation can simulate dynamic programming algorithms admitting two
properties, i.e. monotonicity and decomposability. This shows the power of massively parallel
computation since the process of dynamic programming typically requires large memory space and
is considered inherently sequential.

Limitation of Massively Parallel Computation. In this work, we investigate whether there
are inherent limits in the massively parallel computation model. Namely, whether there are func-
tions that are hard to parallelize in the MPC model. Towards this, we compare it with the (se-
quential) RAM model of computation. Suppose we have a function that can be computed by a
RAM algorithm with time complexity T and space complexity S (assume the input size N ≤ S).
It is easy to see that an MPC algorithm can compute the function in T rounds by emulating the
RAM computation step by step, even when each machine has O(logS) local memory size. Also, if
each machine has local memory size S, then trivially the function can be computed in one round.
Therefore, to show such a limitation, ideally, we would like to show the existence of a function
computable in time T and space S in the RAM model but it requires Ω(T ) rounds to compute for
any MPC algorithms with local memory size s < S. We refer to this as the best-possible hardness
for the MPC model.

The hardness of the MPC model has been investigated by the seminal work of Roughgarden,
Vassilvitskii, and Wang [64], who showed that there are functions requiring Ω(logsN) rounds to
compute in the MPC model2. This gives a logarithmic lower bound when the local memory size
s = O(1), but only a constant lower bound for the typical settings where s is polynomial in N .

2In fact, the lower bound holds in a stronger model called s-shuffle circuits

1



Nevertheless, [64] showed that an ω(logsN) round complexity lower bound in the MPC model
for any problems in P implies P 6= NC1, which is beyond the reach of the current techniques in
complexity theory. Thus, the Ω(logsN) lower bound is essentially the best we can hope for given
the status of complexity theory if we look for unconditional lower bounds.

To circumvent the barrier in complexity theory, we borrow ideas from cryptography. Specifically,
we investigate the hardness of the MPC model in the Random Oracle (RO) model based on the
widely used random oracle methodology in cryptography, which we briefly review as follows.

Random Oracle Methodology. This is a popular methodology for designing cryptographic
constructions, which consists of the following two steps. First, we consider the Random Oracle
(RO) model where all parties have oracle access to a truly random function RO : {0, 1}n → {0, 1}n.
We design and prove the security for a cryptographic construction in the (idealized) RO model.
Next, we replace the random oracle by a “good cryptographic hashing function” h (such as SHA3)
to obtain a concrete construction, and assume that the construction has the same security as the
“ideal” one analyzed in the RO model. This methodology is widely used in both practice and
theory to obtain more efficient and simpler constructions [24, 25, 38, 52] or to achieve stronger
security and new feasibility results [26, 23, 60]. Of course, replacing the oracle by a hash function
is merely a heuristic. The validity of such heuristic has been investigated in the literature, where
several counterexamples (i.e., constructions that are proven secure in the RO model but become
insecure when the RO is instantiated by any concrete hash functions) are known [22, 28, 29, 45, 53,
58]. However, these counterexamples are contrived in the sense that they are constructed for this
purpose, instead of obtaining a useful cryptographic construction. For all natural constructions, the
heuristic holds so far and sometimes the proved security in the RO model matches the best-known
attacks [31, 34, 35]. Indeed, the random oracle methodology is well-accepted in practice where
many RO-based constructions (e.g., RSA-OAEP) have been used for years as part of the standard
in practical cryptographic systems [5, 25].

1.1 Our Results and Techniques

We demonstrate a limitation of the MPC model by establishing a nearly best-possible hardness
result in the Random Oracle model. Let RO : {0, 1}n → {0, 1}n be a random oracle where making
a query to RO takes O(n) time. Specifically, in the following theorem, we show the existence of a
function in the RO model that can be computed in time O(T ¡n) and space S by a RAM algorithm
such that any MPC algorithm with local memory size s ≤ O(S) requires at least Ω̃(T ) rounds to
compute the function, even in the average case, for a wide range of parameters T and S.

Theorem 1.1 (Nearly Best-Possible Hardness in the RO Model). There exists a universal constant

c > 1 such that for any sufficiently large n > 0, the following holds. For any n ≤ S < 2O(n1/4),
S ≤ T < 2O(n1/4), there is an oracle function fRO : {0, 1}S → {0, 1}n such that it can be computed
using memory of size O(S) in O(T ¡n) time by a RAM computation with access to RO, but for any

(potentially randomized) massively parallel computation algorithm ARO with m < 2O(n1/4) machines,
local memory of size s where s ≤ S/c, and the number of local queries per round q < 2n/4 to RO, the
probability that ARO computes fRO correctly in o(T/ log2 T ) rounds is at most 1/3 over the random
choice of RO and input.

In particular, for any parameters T and S, by setting n = polylog(T ), Theorem 1.1 shows the
existence of an oracle function computable in time Õ(T ) and space O(S) by a RAM algorithm
where any MPC algorithm with local memory size sufficiently smaller than S requires Ω̃(T ) rounds

2



to compute the function. As discussed above, this is the best-possible hardness up to a poly-
logarithmic factor. Furthermore, following the random oracle methodology, we can instantiate the
random oracle with a good cryptographic hash function h with time complexity th = poly(n). We
then obtain a concrete hard function fh : {0, 1}S → {0, 1}n that can be computed in time Õ(T )
and space O(S) by a RAM algorithm, yet assuming the validity of the random oracle methodology,
fh is hard to compute for any (randomized) MPC algorithm with local memory of size s ≤ S/c
for some constant c > 1.3 This is the best-possible hardness up to a poly-logarithmic factor. Note
that the hardness holds even when the total memory size msďż˝ S as long as the local memory size
is bounded.

We remark that the way our hard function fRO makes use of the random oracle is quite standard
and analogous to several existing cryptographic constructions (e.g., [4, 5, 52]), so it is unlikely that
the random oracle methodology fails to apply to our hard function fRO (see more discussion in
Section 1.2). Thus, one way to interpret our result is that either fh indeed shows a fundamental
limitation of parallelization in the MPC model, or gives a natural counter-example for the random
oracle methodology (which would be surprising).

In the following, we describe the hard function we consider and explain the intuition of its
hardness. To help illustrate the idea, let us start with a warm-up (hard) function, which we analyze
formally in Appendix A for the sake of completeness. Let RO : {0, 1}n → {0, 1}n be a random
oracle and let T, u, v be the parameters specified later. Consider the function SimLineROn,T,u,v

4 :
{0, 1}uv → {0, 1}n defined as follows. The input is parsed as v strings xi ∈ {0, 1}u for all i ∈ [v].
On input x = x1, x2, ..., xv, the output of SimLineROn,T,u,v(x) is defined by iteratively applying RO
as follows. Let r1 = 0u, and

(ri+1, zi+1) := RO(xi mod v, ri, 0
∗), ∀i ∈ [T ],

the output of SimLineROn,T,u,v(x) is defined as the answer to the last query, (rT+1, zT+1). In other
words, we can view SimLinen,T,u,v as defined by a line of T nodes, where the first node is associated
with initial values r1 = 0u, and for each i ∈ [w], the values of next node i+1 is obtained by querying
the oracle on (xi mod v, ri, 0

∗).
To get some intuition of the hardness, first note that since the oracle is random, intuitively,

the only way to learn the output (rT+1, zT+1) is to make queries to learn the value of each node
(i.e., (ri, zi)) in order, which requires to know the corresponding input xi mod v. However, since
the local memory of each machine is bounded by s, intuitively, a machine can only store at most
s/u inputs xi’s. Thus, in each round, the machines can only learn the value of at most s/u new
nodes. Therefore, a MPC algorithm with local space s would need Ω(Tu/s) rounds to compute
SimLineROn,T,u,v(x).

Formalizing the above intuition, however, is non-trivial, since the algorithm may encode the
inputs arbitrarily and also the machines may collaborate in an arbitrary way. Thus, it would be
difficult to formalize what information is stored in the machine’s memory and how much the algo-
rithm learns about the line directly. For the warm-up case of SimLineROn,T,u,v, we can formalize this
intuition by a rather standard use of the so-called “compression argument”, a powerful technique for
establishing lower bounds in both data structure and cryptography literature [5, 6, 35, 34, 50, 61].
To give some intuition about the argument, consider an MPC algorithm computing the function
one by one along the line. For each round, the queries of a machine must contain the corresponding
input xi mod v in order to proceed along the line. Thus, by examining the queries of this machine,

3For this conclusion we would need to set n = polylog(T ) and requires h to have sub-exponential hardness. While
such assumption is strong, it is commonly assumed in practical RO-based cryptographic systems.

4The name SimLine stands for “simple-line,” which is in contrast to the hard function Line we introduce below.

3



we can infer which part of the input is stored in the local memory. Now, if a machine learns too
many nodes in one round, it reveals that it stores many xi’s in its small local memory. The key
of the compression argument is to show that this would allow us to compress the input x and the
random oracle RO beyond the information-theoretic limit, which is a contradiction. We defer the
formal analysis of SimLineROn,T,u,v to Appendix A.

Note that SimLineROn,T,u,v can be computed in time O(Tn) by a RAM program, but above we

only argue a Ω(Tu/s), instead of Ω̃(T ), lower bound for the round complexity of MPC algorithms.
To prove the desired hardness result, we make the function harder by letting each node take a
random input x`i instead of xi mod v, where the index `i is specified by the random oracle (like ri).

More precisely, we now describe our hard function LineROn,T,u,v : {0, 1}uv → {0, 1}n as follows
(see Figure 1 for a pictorial illustration). The input is parsed as v strings xi ∈ {0, 1}u for i ∈ [v].
On input x = x1, x2, ..., xv, the output of LineROn,T,u,v(x) is defined by iteratively applying RO as
follows. Let `1 = 1 and r1 = 0u, and

(`i+1, ri+1, zi+1) := RO(i, x`i , ri, 0
∗), ∀i ∈ [T ],

the output of LineROn,w,u,v(x) is defined as the answer to the last correct query (`T+1, rT+1, zT+1).
Similarly, we can view Linen,T,u,v as defined by a line of T nodes, where the first node is associated
with initial values `1 = 1 and r1 = 0u, and for each i ∈ [T ], the values of next node i+1 is obtained
by using `i to select an input x`i and query the oracle on (i, x`i , ri, 0

∗). Clearly, the function can
be evaluated with O(uv) space and O(Tn) time by following the evaluation over the line. Thus, for
given parameters S and T , we can set v = S/u to get a function with RAM complexity specified
in Theorem 1.1.

Now, intuitively, since s ≤ S/c for a constant c, a machine can only store a constant fraction
of xi’s, and since `i’s are random, the probability that a machine can learn the value of k new
nodes should decay exponentially in k. Thus, “with high probability,” a MPC algorithm can learn
at most, say, log2 T new nodes, and hence it would require Ω̃(T ) rounds to compute LineROn,T,u,v,
which gives us the desired hardness.

However, as above, formalizing this intuition is tricky, since a-priori there is no independence
between the information stored by a machine and the indices `i, and thus it is not clear whether
the probability of learning k new nodes decays exponentially in k. Roughly, we capture this
intuition of exponential probability decay indirectly by a novel tweak to the compression argument.
Specifically, in our proof, we enumerate all the oracles with different sequences of k consecutive `’s,
say `i, ..., `i+k, and run the machine on these oracles. By considering all the queries obtained this
way, we can formalize such exponential probability decay in the compression argument provided
that k is not too large, which allows us to show that a MPC algorithm can learn at most log2 T
new nodes each round and hence require Ω̃(T ) rounds to compute LineROn,T,u,v. As the argument is
more involved, we defer a more detailed technical overview and the formal proof to Section 3.

1.2 Related Work

Massively Parallel Computation Model (a.k.a MapReduce Model) was proposed in [47], and has
been refined and extended in [19, 7, 64]. Many algorithmic techniques and problems have been stud-
ied in MPC model such as greedy algorithms [48], dynamic programming [17, 46], linear program-
ming [12], graph algorithms [2, 7, 8, 9, 10, 11, 13, 14, 15, 20, 21, 27, 30, 32, 41, 44, 40, 49, 51, 59, 63],
clustering [16, 18, 36, 43, 65], submodular function optimization [33, 37, 48, 56], and query opti-
mization [19].

The tradeoffs between space (total memory), communication and the number of communica-
tion rounds in MPC model have been studied. Pietracaprina et al. [62] studied the space-round

4



tradeoffs for certain kinds of matrix multiplication algorithm. Afrati et al. [1] investigated the
space-communication tradeoffs for single round algorithms. Beame et al. [19] studied the tradeoff
between the amount of communication and the number of rounds.

Roughgarden et al. [64] proved an blogs nc round unconditional lower bounds. When local
memory per machine s is polynomially related to n, which is usually assumed in the MPC model,
this gives a constant round lower bound. Fish et al. [39] proved hierarchy theorems with respect
to the computation time per processor.

Conditioned on the conjecture that graph connectivity cannot be solved in o(log n) commu-
nication rounds for memory per machine sublinear in the number of vertices, Ghaffari et al. [42]
showed that constant approximation of maximum matching, vertex cover, and maximum indepen-
dent set cannot be solved in o(log log n) rounds, and the Lovász Local Lemma problem cannot be
solved in o(log log log n) rounds. Under the same conjecture, Yaroslavtsev et al. [65] showed that
single-linkage clustering cannot be approximated by constant factor in o(log n) rounds. Recently,
Nanongkai and Scquizzato showed that this conjecture is equivalent to the conjecture that log-
space complete problem can not be solved in o(log n) rounds, and consequently, a large class of
graph problems, such as single source shortest path, minimum cut, and planarity testing, require
asymptotically the same number of rounds under these assumptions [57].

Another well-studied parallel computation model is the PRAM model. In this model, there
is a polynomial number of processors and a shared memory. In each time (synchronized round),
each processor can read a constant number of memory cells from the shared memory, do some local
computation, and write to a memory cell in the shared memory. Similar to the MPC model, it is
known that super-logarithmic lower bound on the parallel time in the PRAM model implies strong
circuit lower bounds. Therefore, some assumptions are needed in order to prove stronger lower
bounds. To our knowledge, PRAM lower bound does not imply MPC lower bound in a trivial way,
due to the local computation of MPC in every single round. For example, Miltersen [54] showed
a strong lower bound in the random oracle model using a certain pointer jumping problem for
PRAM. However, we note that the problem considered in [54] is not hard in the MPC model. The
reason is that in the MPC model, a local machine can make an arbitrary number of queries to the
oracle in one round, and thus solve the problem considered in [54] in one round.

The way that our hard function uses the random oracle is analogous to several existing crypto-
graphic constructions; in particular, the line of research in memory hard functions (MHFs) [3, 4,
5, 6]. MHFs are hash functions whose evaluation cost is dominated by memory cost. MHFs found
widespread applications such as password hashing, key derivation, and proofs-of-work, and some
important candidates, e.g., scrypt, are described in the RFC standard. The security (i.e., lower
bounds on the so-called “cumulative memory complexity”) of MHFs is analyzed in the RO model
based on the random oracle methodology. As our construction uses RO in an analogous way as
practically-used MHFs (both rely on sequential queries to the oracle), in our eyes, it would be quite
surprising that our hard function becomes a counterexample to the random oracle methodology.

Technically, our analysis is inspired by the analysis of MHFs, which also relies on the compression
argument. However, we stress that the models are quite different and we cannot directly rely on
the analysis of MHFs to establish the hardness of the MPC model. The main reason is that in the
MPC model, the machines can make an arbitrary number of adaptive queries to the oracle for free
in one round, whereas the need of adaptive queries is the source of hardness for high cumulative
memory complexity. Hence, our LineROn,T,u,v function relies on a different reason (specifically, the
fact that each machine is space bounded) to get hardness, and requires a different analysis from
the MHFs.

The rest of the paper is organized as follow. We define the massively parallel computation
model in both the plain and the RO model in Section 2. In Section 3, we state and prove our main

5



theorem on the best-possible hardness for the MPC model.

2 The Massively Parallel Computation Model

Let [n] = {1, 2, ..., n}. We adopt the Massively Parallel Computation Model (also known as MapRe-
duce Model) according to [47]. In this model, we are given a set of machines with a fixed size of
local memory. The input data is distributed across machines arbitrarily. The computation proceeds
in rounds. During a round, each machine runs a polynomial time algorithm on the data assigned
to the machine. No communication between machines is allowed during a round. Between rounds,
machines are allowed to communicate so long as each machine receives no more communication
than its memory. Any data output from a machine must be computed locally from the data residing
on the machine.

Formally, we define the (randomized) massively parallel computation with following parameters.

s: the local memory size for each machine
m: the number of machines
N : the size of the input

Table 1: Parameters of massively parallel computation

Definition 2.1 (Massively Parallel Computation). A massively parallel computation consists of
m machines, local memory of size s for each machine, and a shared, read-only, and multiple access
tape T containing an arbitrarily long random bit string. The computation proceeds by round and
starts from round 0. Let Mk

i ∈ {0, 1}s be the local memory (input) of machine i at the beginning
of round k. Initially, the given input x ∈ {0, 1}N is arbitrarily split and distributed among all the
machines, i.e. each M0

i is assigned with an arbitrary partition of x.
In each round k, each machine i runs a polynomial time algorithm Aki based on its local memory

Mk
i and the shared tape T , and outputs Mk

i,j to machine j for all the j ∈ [m].
⋃
j∈[m]M

k
j,i is the

input of machine i of (k + 1)-th round.

Note that in the above definition, it is required that the size of
⋃
j∈[m]M

k
j,i is smaller than s,

the size of local memory. We refer to a MPC computation terminated at the end of round R as a
R-round MPC computation.

We consider the massively parallel computation with a random oracle.

Definition 2.2 (Massively Parallel Computation with Oracle). A massively parallel computation
consists of m machines, local memory of size s for each machine, a shared, read-only, and multiple
access tape T containing an arbitrarily long random bit string, and a random oracle RO : {0, 1}h →
{0, 1}c which is uniformly drawn from all possible functions before the computation begins.

The computation proceeds by round and starts from round 0. Let Mk
i ∈ {0, 1}s be the local

memory (input) of machine i at the beginning of round k. Initially, the given input x ∈ {0, 1}N is
arbitrarily split and distributed among all the machines, i.e. each M0

i is assigned with an arbitrary
partition of x.

In each round k, each machine i runs a polynomial time algorithm Aki based on its local memory
Mk
i , the shared tape T and the (adaptive) queries of the random oracle, and outputsMk

i,j to machine

j for all the j ∈ [m].
⋃
j∈[m]M

k
j,i is the input of machine i of (k + 1)-th round.

6



Remark 2.3. As a standard observation, in random oracle model, without loss of generality, we
can consider only deterministic MPC algorithm since the algorithm can use the randomness from
the random oracle. In more detail, we can use a random oracle with a larger input domain and a
deterministic MPC can simulate a randomized MPC by obtaining random bits from querying those
extra oracle entries that are not used by the randomized MPC. Therefore, to establish a lower
bound for the randomized MPC model, it suffices to consider deterministic MPC algorithms.

Definition 2.4 (Worst Case Correctness). We say that a randomized R-round MPC computation
(with random oracle) successfully computes a (oracle) function f in worst case if for any input
x ∈ {0, 1}N which is arbitrarily distributed among the machines, the union of outputs of all the
machines at the end of round R is f(x) with probability at least 1

3 over the randomness of the MPC
computation (and the random oracle).

We also consider average case correctness.

Definition 2.5 (Average Case Correctness). We say that a randomized R-round MPC computation
(with random oracle) successfully computes a (oracle) function f in average case if given an input
x ∈ {0, 1}N which is drawn uniformly and arbitrarily distributed among the machines, the union
of outputs of all the machines at the end of round R is f(x) with probability at least 1

3 over the
randomness of the input, the MPC computation (and the random oracle).

3 Main Theorem

In this section, we state our main theorem.

Theorem 3.1. There exists a universal constant c > 1 such that for any sufficiently large n > 0,

let RO : {0, 1}n → {0, 1}n be a random oracle and for any memory size n ≤ S < 2O(n
1
4 ), and

running time S ≤ T < 2O(n
1
4 ), there is an oracle function fRO : {0, 1}S → {0, 1}n such that it

can be computed in time O(T ¡ n) using memory size O(S) by a RAM algorithm in random oracle

model. On the other hand, let AO be a randomized massively parallel computation with m < 2O(n
1
4 )

machines, local memory of size s ≤ S/c and the number of local queries q < 2n/4 to random oracle
per round. Then, in random oracle model, ARO needs at least Ω̃(T ) rounds to compute fRO even
in average case.

The parameters are summarized in Table 2.

n: the size of input and output of the random oracle

S: the memory size used by the RAM algorithm such that n ≤ S < 2O(n1/4)

T : the number of random oracle queries used by RAM algorithm S ≤ T < 2O(n1/4)

q: the upper bound on the number of random oracle queries for every machine in each
round such that q = 2O(n)

Table 2: Parameters of Theorem 3.1

As we discussed in the introduction, for any parameters T and S, by setting n = polylog(T )
and instantiating the random oracle with a cryptographic hash function h with sub-exponential
hardness, we obtain a concrete hard function fh : {0, 1}S → {0, 1}n that can be computed in
time Ω̃(T ) and space O(S) by a RAM algorithm, yet assuming the validity of the random oracle

7



u: the size of each xi such that u = n/3. u is assumed to be large enough as otherwise,
machine may guess it locally with non-trivial probability
v: the number of xi’s in the input such that v = S/u

w: the number of iterations of the random oracle for the LineRO function such that w = T
`i: dlog ve bits of output of (i − 1)-th iteration of the random oracle, which is used to
specify the x`i which is part of the input of i-th iteration of the random oracle
ri: u bits of the output of (i− 1)-th iteration of the random oracle, which is used as part
of the input of i-th iteration
zi: redundant output of (i− 1)-th iteration

Table 3: Parameters of LineRO function given input x1, x2, . . . , xv

!""

#
$%
$&
$'…

…

$(

1, $ℓ,, -%, 0∗

ℓ&, -&, 0&

!""

2, $ℓ2, -&, 0∗

ℓ', -', 0'

!""

3, $ℓ4, -', 0∗

ℓ5, -5, 05

…… !""

6, $ℓ7, -8, 0∗

ℓ89%, -89%, 089%

Figure 1: an illustration on how the LineRO is formed (suppose `2 = 3). Each RO box represents
a correct random oracle query. Note that each machine is not able to store the entire X.

methodology, fh is hard to compute for any (randomized) MPC algorithm with local memory of
size s ≤ S/c for some constant c > 1.

Now we formally define the oracle function. The parameters are summarized in Table 3. Let
LineROn,w,u,v : {0, 1}uv → {0, 1}n be defined as follows: Given input x = x1, x2, ..., xv such that
xi ∈ {0, 1}u for all i ∈ [v] and a random oracle RO : {0, 1}n → {0, 1}n, let r1 = 0u, `1 = 1, and

(`i+1, ri+1, zi+1) := RO(i, x`i , ri, 0
∗), ∀i ∈ [w],

the output of LineROn,w,u,v(x) is defined as the answer to the last correct query, (`w+1, rw+1, zw+1).
See Figure 1 for an illustration. Given the parameters S, T in Theorem 3.1, we set the parameters
of LineRO as described in Table 1. The obvious RAM algorithm already achieves the required
performance on memory size and running time. As the standard observation in Remark 2.3, without
loss of generality, we can assume the MPC computation is deterministic. Thus, Theorem 3.1 follows
from the following lemma.

Lemma 3.2. There exists a universal constant c > 1 such that for any sufficiently large n > 0,

let RO : {0, 1}n → {0, 1}n be a random oracle and for any n ≤ S < 2O(n
1
4 ) and S ≤ T < 2O(n

1
4 ),

consider the function LineROn,w,u,v : {0, 1}uv → {0, 1}n where w = T , v = S/u and u = n/3. Let ARO

be a deterministic massively parallel computation with m < 2O(n
1
4 ) machines, local memory of size

s ≤ S/c and a number of at most q < 2n/4 random oracle queries per round per machine. Then, in
random oracle model, ARO needs at least R ≥ w

log2 w
= Ω̃(T ) rounds to compute LineROn,w,u,v even in

average case.

8



As discussed in Section 1.1, intuitively, the only way to learn (`w+1, rw+1, zw+1) is to make
queries to learn the value of each node (i.e. (`w+1, rw+1, zw+1)) one by one. However, since s ≤ S/c
for some constant c, intuitively, a machine can only store a constant fraction of xi’s, and since
`i’s are random, the probability that a machine can learn the value of p new nodes should decay
exponentially in p. To formalize the above intuition, however, there are three issues. First, we need
to argue that indeed the algorithm can only query on the LineRO in the given order. Second, in
general, an MPC algorithm is not restricted to store xi’s in the most naive way; instead, it may
encode them arbitrarily. Third, an MPC algorithm can query random oracle arbitrarily and thus
the set of xi’s stored would correlate with random oracle (in particular, `i) arbitrarily. The first
issue can be solved readily by a standard argument. To resolve the second issue, we employ the
compression argument which helps us extract the information about xi’s from the queries. Note
that although the use of compression argument is inspired by the analysis of MHFs, we stress that
the models are quite different and we cannot rely on the analysis of MHFs. The reason is that in
MPC model, the machines can make an arbitrary number of adaptive queries in one round, whereas
the need of adaptive queries is the source of hardness for MHFs.

Now we give an overview of our technique. Observe that since computing LineRO requires
the MPC algorithm to query on the LineRO in the given order, the queries of a machine must
contain the corresponding x`i−1

to get `i and ri and this leaks which xi’s a local machine stores.
Thus, those xi";"""date"",""2020-08-18T00:49:47Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2020-08-18T00:49:47Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016) kpathsea version 6.2.2""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2020-08-18T00:49:47Z""
""created"",""2020-08-18T00:49:47Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-08-18T00:49:47Z""
""resourceName"",""2008.06554""
""Author"",""""
""producer"",""pdfTeX-1.40.17""
""pdf:docinfo:producer"",""pdfTeX-1.40.17""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""3"",""1"",""1"",""15"",""2"",""3"",""0"",""9"",""31"",""16"",""9"",""12"",""45"",""35"",""0"",""0"",""1"",""1"",""1"",""0"",""12"",""7"",""12"",""1"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2020-08-18T00:49:47Z""
""Last-Modified"",""2020-08-18T00:49:47Z""
""dcterms:modified"",""2020-08-18T00:49:47Z""
""title"",""""
""Last-Save-Date"",""2020-08-18T00:49:47Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2020-08-18T00:49:47Z""
""meta:save-date"",""2020-08-18T00:49:47Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016) kpathsea version 6.2.2""
""Content-Length"",""525508""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""26""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""1378"",""3247"",""3214"",""3381"",""3217"",""3630"",""2533"",""2429"",""2072"",""3284"",""2203"",""1968"",""1155"",""1350"",""1736"",""2668"",""2662"",""2779"",""2588"",""2414"",""2872"",""1593"",""1076"",""2272"",""1578"",""335""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-08-18T00:49:47Z""
";https://scholar.google.ch/scholar?start=680&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098813-217;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Groupchain: A Blockchain Model with Privacy-preservation and Supervision;C Li, L Wang, Q Xu, D Li, P Liu, X Li ; Proceedings of the 2020 4th …, 2020  dl.acm.org;;"… the global ledger posted on the blockchain network. In the random oracle model,

we demonstrate that the blockchain global ledger is anonymous from a public

perspective. If necessary, the regulatory authorities (such as the …";Autres articles;;null;;;;https://scholar.google.ch/scholar?start=760&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098795-174;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;[PDF][PDF] Strong Authentication without Tamper-Resistant Hardware and Application to Federated Identities;Z Zhang, Y Wang, K Yang ; ndsssymposium.org;;"… Chinese Academy of Sciences 2University of Chinese Academy of Sciences 3The Joint Academy

of Blockchain Innovation 4State … were revealed; Q is the set of queries made by the adversary

to the SIGN oracle. Let n be the number of users, the oracles are defined as follows …";Autres articles;;[PDF] ndss-symposium.org;https://www.ndss-symposium.org/wp-content/uploads/2020/02/24462-paper.pdf;;;https://scholar.google.ch/scholar?start=720&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098729-28;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Semantic Definition of Anonymity in Identity-Based Encryption and Its Relation to Indistinguishability-Based Definition;G Hanaoka, M Komatsu, K Ohara, Y Sakai… ; … on Research in …, 2020  Springer;;"… work immediately in our setting due to the difference between the semantics of identities and

messages and the existence of the key extraction oracles … For PPT algorithm A, \(A^\mathcal

{O}\) denotes that A has access to the oracle \(\mathcal {O}\). \bot \) is a symbol that means …";Autres articles;;null;;;;https://scholar.google.ch/scholar?start=570&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098760-94;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Uso de contratos inteligentes en la comercialización de energía eléctrica en Colombia bajo la tecnología Blockchain;OA Arias;Villa  repositorio.unal.edu.co;;"… en Colombia bajo la tecnología Blockchain Smart contracts for electrical energy commercialization

in Colombia using Blockchain technology … Blockchain Smart contracts for electrical energy

commercialization in Colombia using Blockchain technology Oscar Alberto Arias Villa …";Autres articles;Version HTML;[PDF] unal.edu.co;https://repositorio.unal.edu.co/bitstream/handle/unal/77489/1152688998.2019.pdf?sequence=4;"
 
 

Uso de contratos inteligentes en la 
comercializaciĂłn de energĂ­a elĂŠctrica 

en Colombia bajo la tecnologĂ­a 
Blockchain 

 
 

Smart contracts for electrical energy commercialization 
in Colombia using Blockchain technology 

 
 

 
 

Oscar Alberto Arias Villa 
 
 
 
 
 
 

Universidad Nacional de Colombia 

Facultad de Minas, Departamento de ingenierĂ­a elĂŠctrica y automĂĄtica 

MedellĂ­n, Colombia 

2019





Uso de contratos inteligentes en la 
comercializaciĂłn de energĂ­a elĂŠctrica 

en Colombia bajo la tecnologĂ­a 
Blockchain 

 

Smart contracts for electrical energy commercialization 
in Colombia using Blockchain technology 

 
 

Oscar Alberto Arias Villa 

 
 
 
 

Trabajo final de maestrĂ­a en perfil de profundizaciĂłn presentado como requisito parcial 

para optar al tĂ­tulo de: 

Magister en Ingeniería – Ingeniería Eléctrica 

 
 
 

Director (a): 

Ph.D. GermĂĄn Zapata Madrigal 

 
 
 
 
 

LĂ­nea de InvestigaciĂłn: 

Sistemas ElĂŠctricos de Potencia 

 
 
 

Universidad Nacional de Colombia 

Facultad de Minas, Departamento de energĂ­a elĂŠctrica y automĂĄtica 

MedellĂ­n, Colombia 

2019





Resumen y Abstract  V 

 

Resumen 

La comercializaciĂłn de energĂ­a elĂŠctrica en Colombia presenta una diversidad de 

mecanismos contractuales y escenarios de negociaciĂłn en los que se realizan acuerdos 

como los contratos de energĂ­a real y financieros. Los mecanismos que soportan los 

acuerdos, aunque vĂĄlidos, se encuentra limitados para gestionar de manera activa la 

comercializaciĂłn de la electricidad y no cuentan con la capacidad de establecerse como 

una plataforma para futuras aplicaciones. En este trabajo se analizan los principales 

esquemas transaccionales del sistema comercial elĂŠctrico colombiano, evidenciando 

diferentes fallas de mercado y algunas carencias normativas, entre las que se encuentran 

la baja cobertura de riesgos, los bajos Ă­ndices de fluidez y profundidad, la monopolizaciĂłn 

de los clientes, la inexistencia de un mercado de opciones y de un mercado de contratos 

anĂłnimos estandarizados, la baja penetraciĂłn del mercado de futuros, entre otros. Se 

seleccionaron un conjunto de contratos tĂ­picos de energĂ­a, de liquidaciĂłn del mercado 

elĂŠctrico mayorista y de mercados de futuros y opciones, sobre los cuales se desarrollaron 

contratos inteligentes en el lenguaje de programaciĂłn Solidity y se verificĂł su 

funcionamiento en la red REMIX, enfocada a la prueba de contratos inteligentes en la 

Blockchain Ethereum. Se identifica que las propiedades inherentes de las Blockchain 

estĂĄn alineadas a los principios rectores y caracterĂ­sticas propuestas por la ComisiĂłn de 

RegulaciĂłn de EnergĂ­a y Gas para la creaciĂłn de los mecanismos transaccionales, lo cual 

la viabiliza como una plataforma de interĂŠs para la administraciĂłn de la estructura 

transaccional que necesita el sistema en sus diferentes submercados. 

Palabras clave: Mercados de energĂ­a, contratos inteligentes, Blockchain, sistemas 

distribuidos, modernizaciĂłn de la red.  

  



VI Uso de contratos inteligentes en la comercializaciĂłn de energĂ­a elĂŠctrica en 
Colombia bajo la tecnologĂ­a Blockchain 

 
 

Abstract 

The electricity commercialization in Colombia presents a variety of contractual mechanisms 

and negotiation scenarios where the agreements such as real and financial energy 

contracts are made. The mechanisms that support the agreements, although valid, are 

limited to actively manage the commercialization of electricity and are not able to establish 

themselves as a platform for future applications. In this work, the main transactional 

schemes of the Colombian electricity commercial system are analyzed. Different market 

failures and some regulatory deficiencies are evidenced, such as low risk coverage, low 

flow index and low depth index, customer monopolization, lack of market of options and a 

lack of market of standardized anonymous contracts, low penetration of the forwards 

market, among others. A set of typical energy contracts, liquidation of the wholesale 

electricity market and forwards and options markets were selected to develop for each one 

a smart contract using the Solidity programming language. Its operation was verified in the 

REMIX network, created for testing smart contracts in the Blockchain Ethereum. It is 

identified that the inherent properties of the Blockchain are aligned with the guiding 

principles and characteristics proposed by the ComisiĂłn de RegulaciĂłn de EnergĂ­a y Gas 

for the creation of transactional mechanisms. It makes it viable as a platform of interest for 

the administration of the transactional structure that the system needs in its different 

submarkets. 

Keywords: Energy markets, smart contracts, Blockchain, distributed systems, grid 

modernization. 

 



Contenido  VII 

 

Contenido 

 

Lista de figuras .............................................................................................................. IX 

Lista de tablas .............................................................................................................. 10 

IntroducciĂłn ................................................................................................................. 13 

1. Marco teĂłrico ......................................................................................................... 21 

1.1 Mercado mayorista de energĂ­a elĂŠctrica en Colombia................................. 21 

1.2 Blockchain ...................................................................................................... 25 

1.3 Contratos inteligentes ................................................................................... 28 

1.3.1 Ejemplos de aplicaciones actuales ............................................................ 30 

2. Condiciones normativas y regulatorias .................................................................. 33 

2.1 Contratos bilaterales en el mercado elĂŠctrico mayorista ............................ 33 

2.1.1 Contratos tradicionales .............................................................................. 33 

2.1.2 Otros tipos de contrato .............................................................................. 34 

2.1.3 Riesgos del Mercado ElĂŠctrico Mayorista (MEM) ...................................... 35 

2.2 Limitaciones en el mercado de excedentes de energĂ­a elĂŠctrica de usuarios 

regulados .................................................................................................................. 47 

2.2.1 Alternativas de entrega de los excedentes de AGPE ................................ 47 

2.2.2 Reconocimiento de los excedentes de AGPE ........................................... 48 

2.3 Propuesta de creaciĂłn de un mercado de contratos anĂłnimos 

estandarizados en el Mercado ElĂŠctrico Mayorista ................................................ 50 

2.3.1 Mercado Primario ...................................................................................... 50 

2.3.2 Mercado secundario. ................................................................................. 51 

2.3.3 Limitaciones legales .................................................................................. 51 

2.4 Mercados de futuros y opciones ................................................................... 51 

2.4.1 Ganancia en los mercados de opciones .................................................... 52 



VIII Uso de contratos inteligentes en la comercializaciĂłn de energĂ­a elĂŠctrica en 
Colombia bajo la tecnologĂ­a Blockchain 

 
2.4.2 Beneficios de las opciones financieras ...................................................... 52 

2.4.3 Costos de la operaciĂłn .............................................................................. 53 

3 AutomatizaciĂłn de contratos ................................................................................ 55 

3.1 Contratos tradicionales de energĂ­a ............................................................... 55 

3.1.1 Contratos “pague lo contratado” ................................................................ 55 

3.1.2 Contratos “pague lo demandado” .............................................................. 58 

3.1.3 Contratos “pague lo contratado- condicionado” ......................................... 60 

3.2 Sistemas automĂĄticos de liquidaciĂłn del Mercado ElĂŠctrico Mayorista .... 62 

3.2.1 Sistema automĂĄtico de liquidaciĂłn del Mercado ElĂŠctrico Mayorista - 

Comercializador ...................................................................................................... 63 

3.2.2 Sistema automĂĄtico de liquidaciĂłn de contratos MEM-Generador ............. 66 

3.3 Mercado de Futuros y opciones .................................................................... 69 

3.3.1 Contrato de futuros .................................................................................... 69 

3.3.2 Contrato de opciones ................................................................................ 71 

4 Comparativa entre los esquemas tradicionales y el modelo basado en contratos 

inteligentes ................................................................................................................... 75 

4.1 Criterios de comparaciĂłn .............................................................................. 75 

4.2 ComparaciĂłn .................................................................................................. 77 

4.3 Beneficios y limitaciones de un sistema de intercambios minorista ......... 82 

5 Conclusiones y recomendaciones ........................................................................... 87 

5.1 Conclusiones .................................................................................................. 87 

5.2 Recomendaciones .......................................................................................... 88 

6 Referencias ............................................................................................................ 91 

 

 

 

 

 

 

 

 



Contenido  IX 

 

Lista de figuras 

Figura 1.1-1: Esquema de formaciĂłn del precio de bolsa horario. [13]. ......................... 22 

Figura 1.1-2: ParticipaciĂłn de las ventas por tipo de cliente (Regulado-No Regulado) 

Tomado de [14]. ............................................................................................................. 24 

Figura 1.1-3: Esquema de mercado colombiano. Tomado de [15]. ................................ 25 

Figura 1.2-1: Estructura tĂ­pica de una Blockchain. Tomado de [16]. .............................. 27 

Figura 1.3-1: Comparativa conceptual entre un contrato tĂ­pico y un contrato inteligente. 

Tomada de [21] .............................................................................................................. 29 

Figura 1.3-2: Chainlink- Aplicativo para conectar Blockchains con APIS y otras 

aplicaciones externas. Tomada de [23] .......................................................................... 30 

Figura 2.1-1: Compra de energĂ­a en bolsa como porcentaje de la demanda por 

comercializador y promedio general 2014-2016. Tomado de [24]. ................................. 36 

Figura 2.1-2: Diferencia precios de contratos a Usuarios Regulados y Usuarios No 

regulados.-Variaciones porcentuales AĂąos 2014-2017. Tomado de [24]. ....................... 38 

Figura 2.1-3: Diferencia precios de contratos a Usuarios Regulados y Usuarios No 

regulados.-Variaciones porcentuales AĂąos 2003-2016. Tomado de [14]. ....................... 38 

Figura 2.1-4: Histograma de diferencia porcentual de precios entre contratos tratos a 

usuarios regulados y usuarios no regulados. Tomado de [14]. ....................................... 39 

Figura 2.1-5: Volumen mensual de electricidad negociada en los mercados europeos mĂĄs 

lĂ­quidos. Tomado de [32]. ............................................................................................... 40 

Figura 2.1-6: Indicador de profundidad Mercados elĂŠctricos Europeos -Primer trimestre de 

2019. Tomado de [32]. ................................................................................................... 41 

Figura 2.1-7: Indicador de profundidad del mercado elĂŠctrico colombiano aĂąos 2003-2016 

Tomado de [14]. ............................................................................................................. 41 

Figura 2.1-8: NĂşmero de contratos ELM transados a travĂŠs de Derivex 2011-2016. 

Tomado de [34]. ............................................................................................................. 43 

Figura 2.1-9: ComparaciĂłn de los volĂşmenes comercializados de electricidad en algunos 

mercados importantes diarios, futuros y OTC, primer trimestre de 2019. Tomado de [32].

 ....................................................................................................................................... 44 

Figura 2.1-10: Cantidad de agentes por tipo de integraciĂłn. Tomado de [14]. ............... 46 

Figura 2.1-11: ParticipaciĂłn en ventas por tipo de integraciĂłn entre agentes. Tomado de 

[14]. ................................................................................................................................ 46 

 

 



Lista de tablas 

Tabla 2-1: Principales caracterĂ­sticas contratos ELM y ELS de Derivex [33]. ................. 42 

Tabla 2-2: RelaciĂłn entre la energĂ­a transada en contratos ELM y la demanda total por 

aĂąo. Tomado de [34]. ..................................................................................................... 43 

Tabla 2-3: Porcentaje de participaciĂłn de los mayores comercializadores en el mercado 

elĂŠctrico colombiano aĂąo 2016. Tomado de [14]............................................................. 45 

Tabla 4-1. ComparaciĂłn de la eficiencia entre los esquemas tradicionales y los esquemas 

con uso de contratos inteligentes. ElaboraciĂłn propia. ................................................... 77 

Tabla 4-2. ComparaciĂłn de la transparencia entre los esquemas tradicionales y los 

esquemas con uso de contratos inteligentes. ElaboraciĂłn propia. .................................. 78 

Tabla 4-3. ComparaciĂłn de la igualdad / neutralidad entre los esquemas tradicionales y 

los esquemas con uso de contratos inteligentes. ElaboraciĂłn propia. ............................ 78 

Tabla 4-4. ComparaciĂłn de la centralizaciĂłn entre los esquemas tradicionales y los 

esquemas con uso de contratos inteligentes. ElaboraciĂłn propia. .................................. 79 

Tabla 4-5. ComparaciĂłn del anonimato entre los esquemas tradicionales y los esquemas 

con uso de contratos inteligentes. ElaboraciĂłn propia. ................................................... 79 

Tabla 4-6. ComparaciĂłn de la seguridad entre los esquemas tradicionales y los esquemas 

con uso de contratos inteligentes. ElaboraciĂłn propia. ................................................... 80 

Tabla 4-7. ComparaciĂłn de la independencia entre los esquemas tradicionales y los 

esquemas con uso de contratos inteligentes. ElaboraciĂłn propia. .................................. 80 

Tabla 4-8. ComparaciĂłn de la acreditaciĂłn entre los esquemas tradicionales y los 

esquemas con uso de contratos inteligentes. ElaboraciĂłn propia. .................................. 81 

Tabla 4-9. ComparaciĂłn de la liquidez entre los esquemas tradicionales y los esquemas 

con uso de contratos inteligentes. ElaboraciĂłn propia. ................................................... 81 

Tabla 4-10. ComparaciĂłn de la gestiĂłn eficiente del riesgo entre los esquemas 

tradicionales y los esquemas con uso de contratos inteligentes. ElaboraciĂłn propia. ..... 82 

Tabla 4-11. ComparaciĂłn de los reportes de informaciĂłn entre los esquemas tradicionales 

y los esquemas con uso de contratos inteligentes. ElaboraciĂłn propia. .......................... 82 

 

 

  



Contenido  11 

 

 

Lista abreviaturas 

 

Abreviaturas 
 
Abreviatura TĂŠrmino 

AGPE Autogenerador a pequeĂąa escala 
API Application Programming Interface 
CND Centro Nacional de Despacho 
CREG ComisiĂłn de RegulaciĂłn de EnergĂ­a y Gas 
CU Costo Unitario de prestaciĂłn del servicio 
ELM Contrato Futuro de Electricidad Mensual 
ELS Contrato Mini de Futuro de Electricidad Mensual 
EVM Ethereum Virtual Machine 
FNCER Fuentes No Convencionales de EnergĂ­a Renovable 
GD Generador Distribuido 
kWh Kilovatio hora 
MAE Mercado AnĂłnimo Estandarizado 
MEM Mercado ElĂŠctrico Mayorista 
MWh Megavatio hora 
OR Operador de Red 
OTC Over The Counter 
P2P Peer to Peer 
SIC Sistema de Intercambios Comerciales 
SIN Sistema Interconectado Nacional 
SUI Sistema Único de Información 

URF 
Unidad de ProyecciĂłn Normativa y Estudios de 
RegulaciĂłn Financiera 

  
  
 

 





IntroducciĂłn 

 
JUSTIFICACIÓN  
 

El sector elĂŠctrico se caracteriza por presentar un gran volumen de relaciones entre partes, 

que se materializan tĂ­picamente a travĂŠs de contratos especialmente en la gestiĂłn de la 

comercializaciĂłn de la energĂ­a elĂŠctrica. Dada la naturaleza de la actividad de la 

comercializaciĂłn se presenta una diversidad de mecanismos contractuales, ya que existen 

diferentes tipos de servicios, precios, condiciones y plazos. Tanto los contratos como los 

mecanismos que soportan los acuerdos, aunque vĂĄlidos, no tienen un desarrollo a la par 

de los adelantos recientes del sector y se establecen bĂĄsicamente como un medio pasivo 

donde se consigna un pacto, limitados en su funcionalidad para gestionar de manera activa 

la comercializaciĂłn de la electricidad y sin la capacidad de establecerse como una 

plataforma para futuras aplicaciones [1]–[3].  

 

En Colombia la progresiva instalaciĂłn de dispositivos inteligentes, sistemas de mediciĂłn, 

la penetraciĂłn de fuentes renovables alternativas, la implementaciĂłn de redes y ciudades 

inteligentes y los nuevos roles de los usuarios abren la puerta para la implementaciĂłn de 

nuevas formas de negocio, que ameritan una estructura digital con la capacidad de 

soportar adecuadamente el creciente nĂşmero de aplicaciones con las que el sector espera 

contar. A partir de la ley 1715 de 2014 [4] en la que se busca promover el desarrollo y la 

utilizaciĂłn de las fuentes no convencionales de energĂ­a, y posteriormente con la resoluciĂłn 

CREG 030 de 2018 que regula las actividades de autogeneraciĂłn a pequeĂąa escala y de 

generaciĂłn distribuida en el sistema interconectado Nacional [5], se establecen las bases 

normativas y regulatorias necesarias para que el sector responda y permita el despliegue 

de nuevos sistemas digitales. 

 



14 Uso de contratos inteligentes en la comercializaciĂłn de energĂ­a elĂŠctrica en 
Colombia bajo la tecnologĂ­a Blockchain 

 
Una de las soluciones planteadas para atender este problema es la tecnologĂ­a Blockchain, 

la cual es una estructura de datos que ofrece bajo un entorno criptogrĂĄfico un registro 

confiable, seguro, inmutable, distribuido y descentralizado. Esta tecnologĂ­a se basa en una 

cadena de bloques de informaciĂłn, en donde cada bloque se encuentra vinculado 

criptogrĂĄficamente al anterior. Esta cadena se distribuye a todos los integrantes de la red 

quienes mediante un mĂŠtodo de consenso validan dicha informaciĂłn, evitando la 

participaciĂłn de una tercera parte o intermediario de confianza y por ende reduciendo los 

costos de las transacciones y los tiempos implĂ­citos en estas [6], [7]. La tecnologĂ­a 

Blockchain no sĂłlo permite el intercambio de activos mediante transacciones virtuales, 

sino que ademĂĄs establece un marco sobre el cual se pueden desarrollar contratos 

inteligentes, los cuales son mĂĄquinas de estado finito con la capacidad de ejecutar 

instrucciones establecidas cuando se cumplen condiciones predefinidas o se han llevado 

a cabo acciones especĂ­ficas. Dichos contratos brindan la oportunidad de crear estructuras 

relacionales mĂĄs complejas y profundas entre los participantes de la Blockchain [7], [8].  

 

ANTECEDENTES 
 

Desde su implementaciĂłn en criptomonedas, como es el caso del protocolo Bitcoin [8], 

esta tecnologĂ­a ha atraĂ­do a diferentes sectores por sus caracterĂ­sticas y sus posibles 

aplicaciones. Diversos autores han visualizado las Blockchain como estructuras de soporte 

para el sector financiero, bancario, de servicios pĂşblicos o bienes inmuebles, ademĂĄs de 

plataformas para el sector gubernamental y de la salud, el Internet de las cosas, la industria 

4.0, entre otros [6], [8]. Aplicaciones que sĂłlo podĂ­an ejecutarse a travĂŠs de un 

intermediario confiable, ahora pueden operar de forma distribuida, sin una autoridad 

central, y lograr la misma funcionalidad.  

 

Aunque todavĂ­a se encuentra en fases experimentales en ciertas aplicaciones, ya es 

posible encontrar algunos casos exitosos de implementaciĂłn de esta tecnologĂ­a. En el 

sector del internet de las cosas, en los intercambios vehĂ­culo-red o en la gestiĂłn de las 

micro redes se ha avanzado en el tema, pues se han establecido diferentes protocolos de 

consenso y se han atacado diferentes problemĂĄticas inherentes a la manera en que se 

despliegan las Blockchains. En [9] por ejemplo, se enmarcĂł un escenario tĂ­pico unificado 

para las Blockchain de energĂ­a elĂŠctrica, basĂĄndose en una estrategia de optimizaciĂłn de 

precio que facilita el intercambio de energĂ­a a bajos costos. En dicho trabajo, como 



IntroducciĂłn  15 

 

elemento diferenciador los autores propusieron una distribuciĂłn basada en agregadores 

de energĂ­a que funcionan como mandos medios entre los dispositivos finales y la red 

Blockchain. AdemĂĄs, definieron una estructura de crĂŠditos con la cual se logra atender el 

sistema sorteando los retrasos en la red causados por el proceso de verificaciĂłn de los 

bloques.  

 

Ante el creciente interĂŠs acadĂŠmico y empresarial se han desarrollado mĂşltiples tipos de 

Blockchain, razĂłn por la que se hace necesario identificar las ventajas y desventajas de 

cada una de estas. Algunos autores han investigado mĂşltiples Blockchain y las han 

evaluado en diferentes niveles, sometiĂŠndolas a pruebas estandarizadas que permiten 

evidenciar las limitaciones prĂĄcticas de cada una y han entregado informaciĂłn tabulada 

que permite la toma de decisiones a los usuarios.  

 

En [7] se analizĂł la capacidad de procesar informaciĂłn de las Blockchains comparando 

las Blockchains pĂşblicas y privadas. Los resultados demuestran que las redes privadas 

soportan de mejor manera el desarrollo de contratos inteligentes con transacciones lĂłgicas 

mĂĄs complejas, lo que las hace especialmente atractivas para el sector financiero y 

bancario. Por su parte, las redes pĂşblicas por sus caracterĂ­sticas distribuidas y nodos con 

acceso sin restricciones permiten el desarrollo de grandes redes. 

 

En [10] se comparĂł un esquema Blockchain para el monitoreo de la red frente a otros 

esquemas propuestos en la literatura y se concluye que la tecnologĂ­a Blockchain permite 

agrupar en una sola tecnologĂ­a mĂşltiples caracterĂ­sticas que han sido perfeccionadas de 

manera aislada en otros desarrollos. La capacidad de compartir informaciĂłn, mantener 

dicha informaciĂłn abierta a los usuarios para su gestiĂłn, permitir un sistema auditable, 

confidencial y confiable, la convierten en un esquema completo y flexible para tener en 

cuenta en futuros desarrollos.  

 

En [1] se ampliĂł el concepto de los contratos inteligentes y se describieron mĂşltiples 

aplicaciones como los intercambios electrĂłnicos de informaciĂłn, manejo de inventarios, 

compras y recepciĂłn, crĂŠditos, facturaciĂłn. Sin embargo, para la ĂŠpoca se carecĂ­a de una 

plataforma que sustentara los requerimientos criptogrĂĄficos y de seguridad necesarios 

para la formalizaciĂłn de este tipo de contratos. Con el perfeccionamiento de la tecnologĂ­a 



16 Uso de contratos inteligentes en la comercializaciĂłn de energĂ­a elĂŠctrica en 
Colombia bajo la tecnologĂ­a Blockchain 

 
Blockchain, los contratos inteligentes encuentran una estructura ideal que permite sortear 

las diferentes preocupaciones para su despliegue masivo.  

 

En [2] y [3] convergen en que los procesos de estandarizaciĂłn del lenguaje, la confiabilidad 

de los datos de entrada y la atenciĂłn de las inflexibilidades impondrĂĄn costos mĂĄs severos 

que aquellos que buscan mitigar, restringiendo asĂ­ la escalabilidad de los contratos 

inteligentes. A su vez sugieren que cuando ya existan fuertes relaciones de confianza, en 

donde las partes prefieran evitar acuerdos detallados, el monitoreo del contrato pueda ser 

costoso y especialmente en donde exista baja incertidumbre, las relaciones se podrĂ­an 

traducir en contratos inteligentes. 

 

Desde hace ya varias dĂŠcadas se ha desarrollado el concepto de contrato inteligente, en 

el cual distintos tipos de clĂĄusulas contractuales pueden ser embebidas 

computacionalmente a travĂŠs de la combinaciĂłn de diferentes protocolos e interfaces de 

usuario, facilitando todos los pasos en un proceso contractual: bĂşsqueda, negociaciĂłn, 

compromiso, desempeĂąo y adjudicaciĂłn. Con los contratos inteligentes se busca la 

digitalizaciĂłn de las leyes y procedimientos con el objetivo de formalizar ciertas 

instituciones digitales capaces de reducir costos mentales y transaccionales de las partes. 

Autores mĂĄs enfocados en los cuestionamientos legales han investigado sobre las 

dificultades de implementar los contratos inteligentes en aplicaciones reales. 

 

Algunos autores ya han implementado Blockchains y contratos inteligentes enfocados a 

las redes elĂŠctricas. En [11] simularon una red Blockchain privada, en donde se automatizĂł 

la negociaciĂłn, asignaciĂłn y el pago del suministro de energĂ­a elĂŠctrica a mĂĄs de 1000 

usuarios simulados mediante contratos inteligentes desarrollados en el lenguaje de 

programaciĂłn Solidity. Los autores incluyeron dentro del programa factores de 

compensaciĂłn para recompensar a aquellos nodos que asumen las cargas o potencia de 

aquellos que se desajustaban del programa propuesto. Al igual que en otros trabajos [10], 

[12] se concluye que estas tecnologĂ­as abren la oportunidad a las empresas prestadoras 

del servicio de energĂ­a elĂŠctrica de automatizar sus reglas de negocio y permiten que los 

usuarios finales evolucionen en la manera en que interactĂşan con el sistemas elĂŠctrico, 

brindĂĄndoles a travĂŠs de convenios inteligentes la informaciĂłn que pueden utilizar para 

beneficiarse de la red. 

 



IntroducciĂłn  17 

 

Otros autores han tomado nota de estos beneficios y han llevado la tecnologĂ­a Blockchain 

a las redes inteligentes [6] en donde gracias a sus caracterĂ­sticas se han realizado 

transacciones de energĂ­a descentralizadas sin necesidad de una tercera parte. Al utilizar 

pruebas de trabajo inmunes a ataques bizantinos, esquemas multi-firma, mensajes 

anĂłnimos encriptados y distribuyendo la informaciĂłn entre todos los nodos que se 

encuentren activos, han logrado realizar transacciones Peer to Peer (P2P) resistentes a 

diversos tipos de ataques, manteniendo las transacciones, perfiles e informaciĂłn financiera 

seguras. 

 

PLANTEAMIENTO DEL PROBLEMA 

 

En la comercializaciĂłn de energĂ­a elĂŠctrica en Colombia, se presentan una diversidad de 

modalidades de contrataciĂłn bilaterales, indexados a diferentes variables y con diferentes 

plazos entre comercializadores y usuarios no regulados, en los cuales se dificulta realizar 

seguimientos y homologaciones por su naturaleza variable. Por su parte, para los usuarios 

regulados se establece un contrato de mandato en donde las partes estĂĄn acotadas por 

un contrato inflexible, dejĂĄndolos sin la capacidad de negociaciĂłn necesaria para 

aprovechar las posibilidades que la normatividad les abre para transar con la energĂ­a que 

producen o dejen de consumir. 

Los procesos de facturaciĂłn representan a su vez un punto susceptible de mejora, pues 

toman una gran cantidad de recursos y tiempo por parte de los comercializadores. 

Adicionalmente, con la llegada de la movilidad elĂŠctrica y la evaluaciĂłn de los costos del 

kWh, este tipo de relaciones evolucionarĂĄn rĂĄpidamente aumentando su complejidad, por 

lo que amerita una herramienta de gestiĂłn mĂĄs avanzada. 

 

Diversos autores concuerdan en la existencia de una gama de sectores y aplicaciones 

donde la implementaciĂłn de la tecnologĂ­a Blockchain podrĂ­a ser significativa [6], [8], [11], 

especialmente si se combina con el uso de contratos inteligentes. Con lo mencionado 

anteriormente y producto de los recientes cambios normativos y regulatorios dados en 

respuesta a la penetraciĂłn de energĂ­as renovables distribuidas y de las redes inteligentes, 

el sector elĂŠctrico colombiano se identifica como un marco idĂłneo para implementar 

nuevas estructuras transaccionales, que aumenten las funcionalidades de los contratos de 

comercializaciĂłn de la energĂ­a elĂŠctrica y ayuden a disminuir los impactos de las 

limitaciones en el proceso.  



18 Uso de contratos inteligentes en la comercializaciĂłn de energĂ­a elĂŠctrica en 
Colombia bajo la tecnologĂ­a Blockchain 

 
 

Aunque se han realizado algunos trabajos a nivel teĂłrico y experimental como los 

desarrollados en [9]–[12], no se ha tratado en detalle el tema de los contratos inteligentes 

en la comercializaciĂłn de energĂ­a elĂŠctrica. Debido a esto, en este trabajo se propondrĂĄn 

mecanismos transaccionales bajo la tecnologĂ­a Blockchain que permitan aumentar la 

funcionalidad de los contratos con los que se gestiona la comercializaciĂłn de energĂ­a 

elĂŠctrica en Colombia. Esto ayudarĂ­a a reducir los costos asociados a facturaciĂłn, a la 

implementaciĂłn de la facturaciĂłn en tiempo real, a evitar los fraudes comerciales, a 

implementar sistemas auditables y a crear nuevos y novedosos esquemas de negocio. Lo 

que se traducirĂ­a finalmente en la reducciĂłn del precio de la energĂ­a elĂŠctrica y en la 

posible creaciĂłn de un esquema de transacciones con mayor liquidez y participantes. 

 

OBJETIVOS 
 

OBJETIVO GENERAL 
 

Desarrollar un conjunto de mecanismos transaccionales para la comercializaciĂłn de 

energĂ­a elĂŠctrica en Colombia basado en contratos inteligentes que permitan aumentar la 

funcionalidad de los contratos actuales entre comercializadores y usuarios. 

 

OBJETIVOS ESPECÍFICOS  
 

▪ Identificar las condiciones normativas y regulatorias de las relaciones comerciales 

en el sector elĂŠctrico colombiano que sean susceptibles a tratar mediante contratos 

inteligentes. 

 

▪ Proponer un conjunto de contratos inteligentes desarrollados en una plataforma 

Blockchain que brinden un mecanismo transaccional para la comercializaciĂłn de 

energĂ­a elĂŠctrica en Colombia. 

 

▪ Probar el desempeño de los contratos inteligentes desarrollados frente a los 

contratos tradicionales. 

 



IntroducciĂłn  19 

 

METODOLOGÍA A UTILIZAR 

 

Para alcanzar los objetivos planteados se recurrirĂĄ en primer lugar a una revisiĂłn 

bibliogrĂĄfica de la normatividad vigente para el sector elĂŠctrico colombiano, enfocado 

principalmente en la comercializaciĂłn de energĂ­a elĂŠctrica, en donde se identificarĂĄn y 

seleccionarĂĄn los casos que serĂĄn sujetos a dinamizar mediante contratos inteligentes. 

Posteriormente, se procederĂĄ a simular contratos inteligentes en una plataforma 

Blockchain de prueba que soporte este tipo de aplicaciones. Por Ăşltimo, se realizarĂĄ una 

comparaciĂłn directa de los contratos desarrollados frente a los contratos actuales. 

 

ALCANCES DEL TRABAJO 
 

▪ Documentar el marco normativo asociado a la comercialización de electricidad en 

Colombia, identificando los mecanismos de transacciĂłn actuales que sean 

susceptibles de flexibilizaciĂłn mediante contratos inteligentes y sus limitaciones frente 

a las nuevas propuestas regulatorias. 

▪ Simular los contratos inteligentes que se desarrollarán bajo tecnología Blockchain que 

permitan corregir las limitaciones presentes en los contratos actuales. 

▪ Comparar los resultados obtenidos mediante contratos inteligentes frente a los 

contratos tradicionales, estableciendo las ventajas y desventajas de cada uno en los 

casos de estudios propuestos. 

▪ Como la orientación de este trabajo se dará entorno a los mecanismos transaccionales 

por medio de los contratos inteligentes, se harĂĄ uso de una ";"""date"",""2020-05-07T03:21:42Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.7""
""xmp:CreatorTool"",""MicrosoftÂŽ Word 2016""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dc:creator"",""Oscar""
""language"",""es""
""dcterms:created"",""2020-05-07T03:21:42Z""
""Last-Modified"",""2020-05-07T03:21:42Z""
""dcterms:modified"",""2020-05-07T03:21:42Z""
""dc:format"",""application/pdf; version=1.7""
""xmpMM:DocumentID"",""uuid:B0DC8A50-8120-4F3E-AEF2-50EC68A97ED6""
""Last-Save-Date"",""2020-05-07T03:21:42Z""
""pdf:docinfo:creator_tool"",""MicrosoftÂŽ Word 2016""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2020-05-07T03:21:42Z""
""meta:save-date"",""2020-05-07T03:21:42Z""
""pdf:encrypted"",""false""
""xmp:CreateDate"",""2020-05-06T22:21:42Z""
""modified"",""2020-05-07T03:21:42Z""
""Content-Length"",""1783450""
""pdf:hasMarkedContent"",""true""
""Content-Type"",""application/pdf""
""xmp:ModifyDate"",""2020-05-06T22:21:42Z""
""pdf:docinfo:creator"",""Oscar""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Oscar""
""dc:language"",""es-CO""
""meta:author"",""Oscar""
""pdf:producer"",""MicrosoftÂŽ Word 2016""
""meta:creation-date"",""2020-05-07T03:21:42Z""
""created"",""2020-05-07T03:21:42Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""94""
""Creation-Date"",""2020-05-07T03:21:42Z""
""resourceName"",""1152688998.2019.pdf""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""377"",""0"",""636"",""0"",""1852"",""1734"",""2592"",""2555"",""3154"",""2593"",""816"",""0"",""1784"",""2699"",""2360"",""2568"",""2431"",""1765"",""1488"",""0"",""2000"",""1454"",""2232"",""1241"",""1249"",""2730"",""2139"",""2380"",""1319"",""1435"",""1382"",""0"",""1692"",""2293"",""2485"",""1644"",""2578"",""951"",""1891"",""1592"",""878"",""1784"",""1164"",""1733"",""1741"",""978"",""2276"",""2211"",""2480"",""2225"",""2015"",""2435"",""642"",""0"",""1846"",""1985"",""2351"",""1944"",""1866"",""2265"",""1599"",""1651"",""2407"",""1913"",""2093"",""2251"",""1797"",""2121"",""1924"",""1737"",""1878"",""1936"",""2146"",""1146"",""1520"",""2122"",""1406"",""1570"",""1648"",""1393"",""1888"",""2121"",""2344"",""2406"",""310"",""0"",""2201"",""2591"",""546"",""0"",""1428"",""1975"",""1666"",""424""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""Author"",""Oscar""
""producer"",""MicrosoftÂŽ Word 2016""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""MicrosoftÂŽ Word 2016""
""pdf:docinfo:created"",""2020-05-07T03:21:42Z""
";https://scholar.google.ch/scholar?start=640&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098738-45;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Blockchain y periodismo: cómo la cadena de bloques cambiará a los media;J Marqués;Pascual, M SintesOlivella  Blockchain y periodismo, 2020  torrossa.com;;"… Page 3. Joaquín Marqués-Pascual Marçal Sintes-Olivella (coords.) BLOCKCHAIN Y PERIODISMO

CÓMO LA CADENA DE BLOQUES CAMBIARÁ LOS MEDIA Prólogo de Josep Lluís Micó … Page

23. 23 1 Tecnología blockchain: hacia un cambio disruptivo en la información …";Cité 1 fois;;null;;;;https://scholar.google.ch/scholar?start=590&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098804-193;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;The Rise of Supply Chain Viability–Digital Solutions as a Boosting Role;E Hofmann, D Langner ;2020 alexandria.unisg.ch;;"… Eg Volvo uses Oracle cloud solutions and blockchain technology to establish global traceability

of cobalt used in its batteries … Retrieved from https://www.oracle.com/connect/volvo-mines-

blockchain-to-keep-ethical-sourcing-promise.html [17] Cordon, C., & Buatois, E. (2020) …";Cité 3 fois;Les 3 versions;[PDF] unisg.ch;https://www.alexandria.unisg.ch/261668/1/Hofmann%2C%20Langner%20%282020%29_Supply_Chain_Viability%20%28White%20Paper%29.pdf;"
The Rise of Supply Chain Viability
– Digital Solutions as a Boosting Role
White Paper

Erik Hofmann
Daniel Langner



Better is the enemy of good – A flood of triggers 
questions today’s supply chains

For years, global supply chains have been lulled into a sense of
complacency, prioritizing cost containment and efficiency, leading
to a continuously increasing degree of complexity, rigidity and loss
of control by outsourcing and globalization.1 Supply chains were
striving for pure efficiency with its objectives to squeeze out costs,
keep inventories at a low level and to transport goods with
exceptional efficiency to distant markets. That was suitable for a
long time, but in a globalized and outsourced world as of today, an
organization’s success is no longer dependent on its efforts only.
The success of an organization depends largely on how effectively
it can orchestrate a vast, global network of supply chain partners to
deliver goods and services that meet the needs of individual con-
sumers.

Today's supply chains are experiencing high levels of change in
terms of both, internal and external pressures described by
PESTELE factors.2 Supply chain disruptions are not new, but
shocks are increasing in frequency and severity. Companies have
been reluctant to invest in resilience, believing that the benefit was
not worth the cost. Recently, the COVID-19 crisis has revealed
structural flaws in supply chains that lead to increasing
uncertainties and vulnerabilities - leading to fundamentally
scrutinize the dominant supply chain narrative of cost reduction
and responsiveness.3 Thus, the crisis has changed the momentum
and supply chains realized they have to step up and contribute.

Even harder, today's supply chains are more and more confronted
by ecological and social imperatives, driven by customer advocacy,
with an unprecedented speed.4 For instance, with the European
Green Deal politics and supply chain law initiatives actively inter-
vene in the change by directly impelling supply chains to act.5 The
current situation provides every reason to believe, that the pace of
change will accelerate and that future supply chains will be in a
constant state of flux.

Political
• Politicization of society
• Carbon tax

Economic
• Shift in value creation
• Individualization

Social
• Change of lifestyle
• Health orientation

Technological
• Digitalization
• Connectivity

Environmental
• Climate change
• Circular economy

Legal
• Supply chain law
• Change of legal systems

Ethical
• Responsibility initiatives
• Sense of responsibility

ÂŤThe increasing emergence of disruptions, 
the shift of ecological, social and ethical 

imperatives, and customer advocacy force 
traditional supply chains to changeÂť

2Š ISCM-HSG 2020



88%
of swiss supply chain 
managers confirm the

ecological and 
social orientation as of 
highest importance for 

sustainability 
implementation 

ÂŤFuture supply 
chains need to 

become 
sustainable, 

resilient, and 
digitalized to 

achieve viability 
and beyondÂť

The fundamental shift of relevance and the recognition of vulnera-
bility and rigidity by supply chains leads us to the assumption, that
decision-makers must change and evolve their companies and
supply chains now, to be able to survive on the market in the long-
term. Particularly, since the principle “survival of the fittest supply
chains” is more dominant than ever before.5 Here, the Schumpe-
terian law of creative destruction gains a new meaning – compa-
nies must abandon the old principles of how they designed and
orchestrated their supply chains. Only with the new and the better,
the flood of challenges affecting companies` supply chains can be
countered.

The new arena of challenges – Future supply 
chains need to evolve to master the VUCA 
world 

The impact of altering triggers over time constantly forces supply
chains to keep up with the changes and evolve.6 As supply chains
look for ways to compete in such a VUCA world (with high levels
of volatility, uncertainty, complexity and ambiguity), leaders will
need to master supply chain evolution and make it a distinctive
competitive advantage. In the past, supply chains were con-
tinuously striving to become more efficient by squeezing out
costs in the best way possible in the short-term. But this does not
necessarily guarantee effectiveness by meeting the demands of the
various shareholders in the long-term. In recent history, com-
panies have been increasingly extradited to external shocks such
as natural disasters. The COVID-19 crisis has then triggered com-
panies to fundamentally reassess their structural flaws. To handle
past, current and future emerging crises and disruptions supply
chains are in need to become resilient by gaining a clear view of
supply chain risk and implement measures from an array of reme-
dies, like scenario planning, back up inventory, safety stock, flex
production or components re-routing, when necessary.6

To be able to exist in the long-term, only being resilient will not
lead to a survivable supply chain. Figure 1 illustrates how supply
chains will need to evolve and which factors play a key role on the
respective level. Thus, the evolution of sustainability and
digitalization have a significant bearing by driving next-generation
supply chains.7 The progress of sustainability is mostly shaped by
the shifting relevance and interpretation of the triple bottom line
dimensions of sustainability, from being economic focused to
become ecological and social-oriented and finally ecological and
ethical dominated in the future. Current supply chains are still far
away from a comprehensive sustainability implementation. To
survive in the long run, it is crucial to manage generating corporate
and social added value across the entire supply chain and, at the
same time, to understand that sustainability will become the norm
across everything they do.4

3Š ISCM-HSG 2020



While digitalization and sustainability have evolved separately so far, they will once gradually
converge by collaterally shaping the future vision of supply chains. Because digital solutions
conquer the market, ready to be adapted to supply chains, the evolution will continue to bio-
intelligent* and autonomous solutions to take account of the rising dominance of neo-ecological
imperatives with social responsibility.7

However, the concept of resilience, sustainability, and digitalization as being individually
resolved, will not lead to viable supply chains. Rather an integrated dynamic framework is
required by combining digitalization and sustainability implementation with an extension to master
risks and disruptions affecting all perspectives.8 To achieve viability, supply chains need to manage
this change to survive as one of the fittest.

The increasing dominance of ecological and social focus of objectives will even force future supply
chains to increasingly merge sustainability and digitalization development beyond viability. This
leads to a construct we call supply chain livability, focusing on direct affection for the people in a
society, in terms of aspects such as economic development, affordability, public health, social equity,
and pollution exposure.

The evolution of supply chains and the shift of relevance and imperatives is accompanied by an evo-
lution of financial focus and objectives, too.6 While cost cutting and budget restrictions were promi-
nent in the past, cash flow orientation, liquidity stability, value-adding and decentralized funding
will allow supply chains to be viable and will need to adapt to the rising social and ethical focus by
gratuitous use and public benefits in the far future.

Gratuitous use 
and public benefit

today tomorrow

Supply Chain 
Livability

Supply Chain 
Efficiency

Supply Chain 
Resilience

Focus Goals

yesterday

Sustainability 
oriented

Sustainability
dominated

Sustainability
implemented

Information systems
and semi-automated 

solutions

Bio-intelligent
and autonomous

solutions

Digital and fully 
automated solutions

D
eg

re
e 

o
f 

S
u

p
p

ly
 C

h
a

in
 E

v
o

lu
ti

o
n

Budget restrictions 
and cost cutting

Self-
concentrated

Planet and society-
focused

after tomorrow

Value adding and 
decentralized funding

4Š ISCM-HSG 2020

Figure 1: Levels of supply chain evolution and its key factors

Supply Chain 
Viability

Supply 
chain- oriented

Cash flow orientation and 
liquidity stability

Fully supply chain
collaborating



ÂŤEcological and 
social-driven 
demand for 

sustainability
and the ability to 

dynamically 
adapt to maintain 

itself,
and to agilely re-
act to changes to 
ensure resilience 

drive future 
supply chainsÂť

The supply chain evolution also comes along with a shift of busi-
ness focus, impact, and objectives. Supply chains need to move
from self-concentrated company focus to open boundaries, to
establish collaboration along and across supply chains to become
viable.9

To become livable and justify a future business existence, supply
chains of the future will need to focus on adding value and
creating a direct positive impact on society. Moreover, the
preservation of the planet with its biodiversity will have to become
a major condition for supply chains as well.4 Sooner or later, the
current VUCA world with a pure economic narrative will be
replaced by a VUCA world dominated by social and ecological
factors. Decision-makers should be aware of this new prospective
arena of challenges.

The principal goal – On the road to supply chain 
viability 

The evolution of supply chains seeks to achieve livability as its ulti-
mate objective in the far future, but the principal goal today is seen
in the supply chain viability as the next necessary step in the evolu-
tion. Supply chain viability focuses on the implementation of sus-
tainability, following social and ecological imperatives, to survive
in a constantly changing market and environment on a long-term
basis and at the same time to have the ability of a dynamically
adaptable network to maintain itself and be able to react agilely to
changes through increasing resilience.11 Supply chain viability is
characterized by a fully collaborating perspective of the value
creation with business partners. The boundaries of the company
have been overcome.12 Together with customers and suppliers,
companies are looking for solutions to upcoming problems. This
includes the joint use of resources and capacities. The supply chain
actors are open and willing to do this collaborative form of
cooperation – also because precautions are taken to ensure that
their data and trust are not abused.12

To get closer to supply chain viability, companies must provide the
necessary agility by ensuring end-to-end flexibility and proactivi-
ty along and across supply chains to react, survive and recover du-
ring and after disruptions and changing conditions.13

*Bio-intelligent solutions are defined as a systematic application of the
knowledge of nature and/or natural processes aiming at optimizing a
manufacturing system regarding its societal and business challenges by
seeking a convergence of bio- and technosphere.10

75%
of swiss supply 

chain managers set 
future management 
focus on long-term 
sustainability and 

adaptability for 
reaction, to 
disruptions 

5Š ISCM-HSG 2020



The increasing economic-driven demand for resilience and ecological and social-driven demand for
sustainability forces supply chains to apply transparency.14 By ensuring end-to-end visibility and
traceability within and across supply chain networks, risks and changing conditions can be predicted
and detected and at the same time the increasing ecological, social, and ethical imperatives for
sustainability and reliability of supply chains can be satisfied.15 Viable supply chains are
characterized by decentralized decisions that take into account local conditions adequately.

E.g. Volvo uses Oracle cloud solutions and blockchain technology to establish global traceability of 
cobalt used in its batteries. This enables Volvo to achieve end-to-end transparency for ensuring 
adherence to ecological, social and ethical imperatives of raw material sourcing and at the same 
time ensuring agility to react to unforeseeable events.16

However, the implementation of supply chain viability to meet these goals requires a holistic change,
driven by a various set of triggers and enablers, which should be tackled with an integrated
approach.

Move the chessmen into position – Various enablers foster supply chain 
viability  

The set of triggers forcing supply chains to evolve is almost endless and attack supply chains from
every angle. Following the changing internal and external conditions, the characteristics and compo-
nents of enablers change and adapt in line and need to be constantly reviewed, reassessed and re-
evaluated.14

Therefore, the isolated implementation of concepts, characteristics and technologies is not target-
oriented and effective to achieve wide-ranging supply chain viability. Figure 2 illustrates the
comprehensive dynamic approach of change along supply chains that is indispensable to achieve
sustainability and resilience within and across supply chains to transform the vision of viability and
beyond.7

Performance & 
Financials

• Comprehensive cost 
consideration

• Value adding and 
decentralized funding

• ESG investments
• Polluter pay principle

Tasks & Processes
• Predictive analytics
• Proactive risk management
• Comprehensive planning, 

monitoring and execution
• Alignment along and 

across the supply chain

People, Culture & 
Ethics

• Ecological and ethical 
oriented decision-making

• Environmental conservation
• Corp. social responsibility
• Customer orientation
• Cultural change

• Application of digital and 
fully automated solutions

• Change and extension of 
interoperable flat architectures

• Knowledge acquisition from 
data and behavior

Digitalization &
Technology

Supply Chain Viability

(Inter)-Organizational
Structures & Relationships
• Decentralized, diversified, 

regionalized supply chains
• Long-term intra- and inter-

supply chain collaboration
• Formation of ecosystems 

and networks

• Data capturing and processing
• Data consistency 
• Information & data sharing

Data & Information

6Š ISCM-HSG 2020

Figure 2: Enabler categories to achieve supply chain viability



ÂŤTo achieve 
supply chain 

viability, a various 
set of enablers 

must be 
considered using 
a comprehensive 

approachÂť

Current supply chains have rigid and convoluted (inter)-organi-
zational structures and relationships that need to be rethought to
respond quickly to and overcome volatility and disruptions with a
long-term sustainability orientation.17

The increasing complexity and connectivity of supply chains and
networks require the highest amount of alignment and
collaboration on a long-term basis. To establish comprehensive
visibility and traceability and to ensure the ability to react to
changing environments, tasks and processes must trans-
form significantly and adapt to predominant, rapidly changing
conditions.8

The rise of business ecosystems, connectivity and collaboration ex-
tends the amount and variety of data and information created and
stored at a rapid pace. The ability to capture and analyze data is
better than ever before and supply chains need to seize the oppor-
tunity to become real-time.15 The central tower idea must be over-
come. The “big brother is watching you” principle is replaced by a
decentralized variant, in which the data belongs to the entering and
causing actors, following a democratic idea.

As crises arise on the agenda, constrained supply chains, slow
sales, and reduced margins will combine to add even more pre-
ssure on performance and financials.6 Supply chains will need a
strong dose of realism, so that they can free up cash and secure
sustainable liquidity in terms of disruptions and investing in the
change for a sustainable future.18 Green funds and ESG
investments will play a crucial role.

Ecological, social, and ethical triggers are on the move, likely to
become dominant in the future and become the new normal, for-
cing supply chains to a fundamental change in people, culture,
and ethics.8 True to the motto “people matter most”, also the
employees must be involved in the transformation towards supply
chain viability. New knowledge and skills must be considered as
well as the creation of completely new functions and roles (e.g., the
viability manager, who is responsible to integrate ecological and
ethical dimensions into corporate decision-making and to imple-
ment dynamic adaptability against disruptions).

The key enabler in accelerating the realization of those compo-
nents is seen in the digitalization and technology on the road
to supply chain viability and beyond.7 Like in a game of chess -
decision-makers must concentrate not only on one piece. Every
figure has its right to exist – no matter how modest its properties.
However, some sacrifices may be necessary to get closer to the
vision of supply chain viability.

93%
of swiss supply chain 

managers see 
technological 

innovation as a key 
enabler to improve 

sustainability  

7Š ISCM-HSG 2020



ÂŤDigital 
transformation
enables supply 

chains to become 
viable, with cloud 

solutions being 
the most 

promising 
technology to 

achieve supply 
chain viability.Âť

Pull the king maker – Digitalization 
and technology is key for supply chain viability

Supply chain complexity has grown exponentially and the drive for
supply chain transparency is likewise greater than ever. With tech-
nologies allowing companies to create better forecasts, streamline
operations, and break down departmental silos, organizations can
no longer consider digital transformation as optional.19 Not cash,
but data is king. The digitalization and use of technologies is
arguably the most important business trend of our time.

Figure 3 illustrates, that the variety of digital and fully automated
solutions is enormous and steadily enhancing.6 Cloud solutions,
blockchain, and automation reached market readiness and
innovations such as quantum computing and bio-intelligence are
already in the pipeline under development. Now it is about the
implementation and fit of technology in the right position
to unfold its full potential.6

Almost every supply chain of today heavily relates to on-premise
supply chain management systems to handle the daily operative
activities efficiently. Thus, in a data-driven world, cloud solutions
enable the migration of information in this supply chain systems.20

It allows supply chains with the ability to monitor, connect, and
collaborate across the entire supply chain with an end-to-end
connection of products, processes, services and assets with

employees, partners and customers.21

Tetra Pak for example just launched an Oracle cloud solution-based 
project to implement real-time visibility and traceability, to provide 
transparency, and reliability for their customers.22

Digital Twin

Internet of Things

Blockchain

Big Data

Digital Solutions

Artificial Intelligence

Digital-Physical Solutions

Autonomous Transportation

Automation

Robotics

Human Enhancement

Augmented & 
Virtual Reality

Additive Manufacturing

Enabling Digital Solution

Process Mining

Cloud Solutions
Cloud Solutions

Monitor, 
connect, 

and 
collaborate 
across the 

entire 
supply 
chain

End-to-end 
connection 

of products, 
services and 
assets, with 
employees, 

partners and 
customers

Consistency 
in informa-

tion, reduced 
degree of 

uncertainty 
and 

integrated 
interactive 
processes

8Š ISCM-HSG 2020

Figure 3: Digitalization and technology as a key enabler to achieve supply chain viability



To fully automate and digitize viable supply chains, cloud solutions build the basis to integrate inter-
operable flat architectures, to transfer real-world assets and ensure consistency between disparate
systems, which are addable, removable and interchangeable, following a plug- and play principle.23

of swiss supply chain managers grant cloud 
solutions a significant increase of relevance 

and positive impact for supply chains   
84%

Despite the ample opportunities for digital solutions as cloud solutions provide, figure 4 illustrates
various barriers that hinder supply chains to adapt and integrate technologies. Most supply chains
tend to stick to existing legacies, which are currently appropriate, but will not fulfil its purpose in the
long-term future.21 Supply chains need to overcome the fear of change, be aware of the necessity and
opportunities digital solutions and automation provide, and break up legacies to unfold its full

potential.20 Even though it takes time to gain value in the short-term, on a long-term basis it is
indispensable to apply technologies like cloud solutions to enable supply chain viability.

Functional

• Data collection
• Security mechanisms
• Data consistency
• Avoid data 

redundancies
• Data sharing
• Meaningful 

information extraction
• Task-technology fit

• Break up legacy 
structures and 
processes

• Investments
• Top-management 

commitment
• Digital capabilities 

and expertise
• Openness for sharing

• Data privacy
• Information theft
• Data transfer from 

legacy systems
• Integration of 

complex, customized 
tasks

• Time for planning 
and  implementation

• Fear of change
• Time-to-value 

achievement
• Sticking to existing 

legacies
• Costs of 

implementation
• Dependencies (e.g., 

product owner)

• Break up legacy 
systems and 
architectures

• Interoperability
• Accessibility
• Useability
• Scalability
• Extensibility
• Flexibility

• Clear 
responsibilities and 
governance

• Alignment with 
supply chain 
direction

• Supply chain 
network integration

• Authorizations
• Backup solutions

• Data extraction of 
legacy systems

• Access to sensible 
and confidential 
data and 
information

• System integration 
and interfaces

• Maintenance and 
development

• Awareness of 
necessity

• Acceptance
• Change of currently 

working processes
Non-

Functional

Requirements Barriers

A successful implementation for supply chain viability should be well aligned with long-term object-
tives.7 The consideration of various functional and non-functional requirements is indispensable. Only
if the barriers are conquered and the requirements are considered, technology will enable supply
chains to achieve viability and accelerate its implementation driven by the increasing sustainability
dominance in economies and society.

9Š ISCM-HSG 2020

Figure 4: Overview of requirements and barriers for digital and technological solutions



The early bird catches the worm – Getting started in time with supply 
chain viability

The time for change is more prominent than ever before. Supply chains need to master the compre-
hensive evolution to achieve viability and beyond along and across the entire supply chains with the
usage of digitalization and sustainability implementation.24 It is time to start the journey into the new
realms of supply chain viability. Technology enables and accelerates the evolution to supply chain
viability. But to truly optimize the supply chains, companies must get the correct technology in place
first. How to approach the comprehensive evolution to digital transformation, sustainability
implementation and supply chain viability achievement of an entire supply chain is the most
prominent question. The following four levels of action serve as a very first guideline to begin
the transformation to next-gen supply chains.

Starting: The awareness of the PESTELE triggers and the analysis of its influences on the supply
chain and networks must be prioritized. The progress of sustainability implementation requires a rea-
listic and comprehensive assessment to derive and prioritize decisions, which are aligned with both,
short-term actions and long-term objectives. The assessment and decision prioritization should also
comprise digitalization and technology as an enabler to implement sustainability and having
the ability to agilely act against disruptions.

Doing: The derivation and prioritization of decisions and actions need to be transformed into concrete
sustainability and resilience measures, based on the long-term objectives. New digital opportunities
should be undergone a profound task-technology-fit to realize its full potential in the supply chain.

Reviewing: As environments and society are constantly changing and technologies rise with a rapid
pace, observation, and analysis of changing conditions, influences and impact on the supply chain, as
well as digital advancements are indispensable. Constant reassessment and re-evaluation of decisions
and actions are inevitable to have the ability to adapt and to reprioritize supply chain viability
initiatives.

Improving: Only with a constant reviewing, supply chains will be able to adapt and to reprioritize
decisions and actions for long-term objective achievement of supply chain viability. The
environmental and social change, as well as rising and changing enabler should be continuously
considered, evaluated and implemented to ensure the continuous improvement towards the long-
term objectives of supply chains.

But since supply chain viability is more a philosophy, there will be no finish line. Environments will
continue to change, customer advocacy will rise, leading to a focus on tailored, agile, trustworthy and
innovative characteristics.25 Further, sustainable and social aspects will reach dominance and new
possibilities like the developing field of bio-intelligence and autonomous solutions will encourage
supply chains to further evolve beyond viability, seeking to become livable.

10Š ISCM-HSG 2020



11Š ISCM-HSG 2020

References

[1]    Aylor, B., Datta, B., DeFauw, M., Gilbert, M., Knizek, C., & McAdoo, M. (2020). Designing resilience into global 
supply chains. Retrieved from https://www.bcg.com/publications/2020/resilience-in-global-supply-chains

[2]     Ellingrud, K. (2020). Reimagining supply chain resilience. Retrieved from 
https://www.mckinsey.com/mgi/overview/in-the-news/reimagining-supply-chain-resilience

[3]     Wieland, A. (2020). Dancing the supply chain: Toward transformative supply chain management. Journal of Supply 
Chain Management, 57(1), 1–32. 

[4]     Walter, G., Knizek, C., von Koeller, E., O’Brien, C., Hardin, E. M., Young, D., Orimo, M., & Cordes, F. (2020). Your 
supply chain needs a sustainability strategy. Retrieved from https://www.bcg.com/publications/2020/supply-
chain-needs-sustainability-strategy

[5]     Rio, P., PeĂąasco, C., & Mir-Artigues, P. (2018) An overview of drivers and barriers to concentrated solar power in the
European Union. Renewable and Sustainable Energy Reviews, 81(3), 1019-1029.

[6]     Lund, S., Manyika, J., Woetzel, J., Barriball, E., Krishnan, M., Alicke, K., Birshan, M., George, K., Smit, S., Swan,
D., & Hutzler, K. (2020). Risk, resilience, and rebalancing in global value chains. Retrieved from
https://www.mckinsey.com/business-functions/operations/our-insights/risk-resilience-and-rebalancing-in
-global-value-chains

[7]     StĂślzle, W., Roeck, D., Langner, D., & Hofmann, E. (Forthcoming 2021). Information systems as enabler for next
generation supply chains : The vision of bio-dominant supply chain viability. In: Proceedings HICSS-54.

[8]     Ivanova, V., Rogge, Lauren. (2016). The state of sustainable supply chains – Building
responsible and resilient supply chains. Retrieved from https://ey.com/the-state/of-sustainable-supply-chains

[9]     Ferrari, B. B. (2020). New rules for supply chain insights, collaboration and overall resiliency. Retrieved from 
https://www.oracle.com/a/ocom/docs/ferrari-research-advisory-supply-chain.pdf

[10]   Miehe, R., Bauernhansl, T., Schwarz, O., Traube, A., Lorenzoni, A., Waltersmann, L., Sauer, A. (2018). The
biological transformation of the manufacturing industry–envisioning biointelligent value adding. Procedia 
CIRP, 72(2), 739–743.

[11]   Ivanov, D., & Dolgui, A. (2020). Viability of intertwined supply networks: Extending the supply chain resilience
angles towards survivability. A position paper motivated by COVID-19 outbreak. International Journal of
Production Research, 58(10), 2904–2915. 

[12]   Oracle. (2020). Drive supply chain performance with insight and collaboration. Retrieved from 
https://www.oracle.com/a/ocom/docs/scm-drive-performance-report.pdf

[13]   Tucker, R. (2020). What is supply chain resilience?. Retrieved from https://www.mixmove.io/blog/what-is-supply
chain-resilience

[14]   Bonanni, L., & Bateman, A. (2019). What supply chain transparency really means. Harvard Business Review.
(August). Retrieved from https://hbr.org/2019/08/what-supply-chain-transparency-really-means

[15]   Saenz, B. H., Stephan, J., Terino, J., Bysong, T., & Gnamm, J. (2020). How to trace a path to resilient,
sustainable supply chains. Retrieved from https://www.bain.com/insights/resilient-sustainable-supply-chains/

[16]   Banks-Louie, S. (2020). Volvo mines blockchain to keep ethical sourcing promise. Retrieved from 
https://www.oracle.com/connect/volvo-mines-blockchain-to-keep-ethical-sourcing-promise.html

[17]   Cordon, C., & Buatois, E. (2020). A post COVID-19 outlook: The future of the supply chain. Retrieved from 
https://www.imd.org/research-knowledge/articles/A-post-COVID-19-outlook-The-future-of-the-supply-chain/

[18]   Ebinger, F., & Omondi, B. (2020). Leveraging digital approaches for transparency in sustainable supply chains: A
conceptual paper. Sustainability, 12(15). 502-512. 



12Š ISCM-HSG 2020

List of figures

Figure 1: Levels of supply chain evolution and its key factors…………………………………………………………….…. 4

Figure 2: Enabler categories to achieve supply chain viability………………………………………………….……………. 6

Figure 3: Digitalization and technology as a key enabler to achieve supply chain viability…………………….………… 8

Figure 4: Overview of requirements and barriers for digital and technological solutions …………………….………….. 9

[19]   Schrauf, S., & Berttram, P. (2016). Industry 4.0 - How digitization makes the supply chain more efficient, agile, and
customer-focused. Retrieved from https://www.strategyand.pwc.com/gx/en/insights/2016/digitization-more
efficient.html

[20]   Regan, D. (2019). 6 Ways to future-proof your supply chain. Retrieved from https://blogs.oracle.com/japac/6-ways-
to-future-proof-your-supply-chain-v3

[21]   Oracle. (2018). Oracle logistics cloud. Retrieved from https://www.oracle.com/a/ocom/docs/applications/supply-
chain-management/oracle-logistics-cloud-ebook.pdf

[22]   Lennartsson, E., Cozza, R., Regan, D., Senpere, D., & RG, S. (2020). How Tetra Pak is turning predictive
shipment visibility into a competitive advantage. Retrieved from https://www.inspirage.com/event/how-
industry-leader-tetra-pak-is-turning-predictive-shipment-visibility-into-a-competitive-advantage/

[23]   Brown, R. G. (2020). The five ingredients of blockchain interoperability. Retrieved from 
https://www.forbes.com/sites/richardgendalbrown/2020/02/13/the-five-ingredients-of-blockchain-
interoperability/?sh=4382aa6c58a1

[24]   Schmidpeter, P. D. R., & Funk, C. (2020). Mit CSR zu profitablem Wachstum. Retrieved from 
https://www.springerprofessional.de/globalisierung/corporate-social-responsibility/mit-csr-zu-profitablem-
wachstum/18506906 

[25]   Pedersen, M., Pitts, B., Reiss, M., & Simmons, S. (2020). The four characteristics of a customer centric supply
chain. CSCMP’s Supply Chain Quarterly, 14(3).



13Š ISCM-HSG 2020

Acknowledgement

Prof. Dr. Erik Hofmann
Erik Hofmann is Director at the Institute of Supply Chain 
Management at the University of St. Gallen (ISCM-HSG). His 
research and teaching focuses on innovations in purchasing and 
SCM as well as on supply chain finance.

Daniel Langner M.Sc.
Daniel Langner is a research assistant at the Institute of Supply 
Chain Management at the University of St. Gallen (ISCM-HSG). His 
research activities focus on trends in logistics and SCM.

Authors

We would like to thank Oracle Corporation for their financial support in implementing this project as
well as Steffen Zitzmann and Dominic Regan for their continued support with inspirations and
knowledge.



14Š ISCM-HSG 2020

in collaboration with

The Rise of Supply Chain";"""date"",""2020-12-09T17:46:20Z""
""pdf:PDFVersion"",""1.7""
""xmp:CreatorTool"",""MicrosoftÂŽ PowerPointÂŽ for Office 365""
""pdf:docinfo:title"",""""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""language"",""en""
""dc:format"",""application/pdf; version=1.7""
""pdf:docinfo:creator_tool"",""MicrosoftÂŽ PowerPointÂŽ for Office 365""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""xmp:CreateDate"",""2020-12-09T18:46:20Z""
""modified"",""2020-12-09T17:46:20Z""
""pdf:hasMarkedContent"",""true""
""xmp:ModifyDate"",""2020-12-09T18:46:20Z""
""pdf:docinfo:creator"",""Langner, Daniel""
""meta:author"",""Langner, Daniel""
""meta:creation-date"",""2020-12-09T17:46:20Z""
""created"",""2020-12-09T17:46:20Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-12-09T17:46:20Z""
""resourceName"",""Hofmann%2C%20Langner%20%282020%29_Supply_Chain_Viability%20%28White%20Paper%29.pdf""
""Author"",""Langner, Daniel""
""producer"",""MicrosoftÂŽ PowerPointÂŽ for Office 365""
""pdf:docinfo:producer"",""MicrosoftÂŽ PowerPointÂŽ for Office 365""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""access_permission:modify_annotations"",""true""
""dc:creator"",""Langner, Daniel""
""dcterms:created"",""2020-12-09T17:46:20Z""
""Last-Modified"",""2020-12-09T17:46:20Z""
""dcterms:modified"",""2020-12-09T17:46:20Z""
""title"",""""
""xmpMM:DocumentID"",""uuid:93D4DC2A-EBB7-497F-A79C-4D2652E43F71""
""Last-Save-Date"",""2020-12-09T17:46:20Z""
""pdf:docinfo:modified"",""2020-12-09T17:46:20Z""
""meta:save-date"",""2020-12-09T17:46:20Z""
""Content-Length"",""797079""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Langner, Daniel""
""dc:language"",""en-US""
""pdf:producer"",""MicrosoftÂŽ PowerPointÂŽ for Office 365""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""14""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""108"",""2274"",""2690"",""2167"",""2425"",""2722"",""2418"",""2218"",""2541"",""2658"",""3800"",""1895"",""663"",""831""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-12-09T17:46:20Z""
";https://scholar.google.ch/scholar?start=740&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098774-125;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Data Quality in a Decentralized Environment;A Bogdanov, A Degtyarev, N Shchegoleva… ; … Science and Its …, 2020  Springer;;"… segments that have the direct impact on overall data quality. The proposed approach

provides the result thanks to a special platform architecture similar to the blockchain

and built-in artificial intelligence agents - oracles. Keywords …";Cité 1 fois;Les 2 versions;[HTML] nih.gov;https://www.ncbi.nlm.nih.gov/pmc/articles/PMC7974849/;;;https://scholar.google.ch/scholar?start=670&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098861-327;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;The memory-tightness of authenticated encryption;A Ghoshal, J Jaeger, S Tessaro ; Annual International Cryptology …, 2020  Springer;;"… to only imposing a constant memory overhead as in earlier works (Auerbach et al., CRYPTO

'17 … Note that while these exclude the time and memory used within whatever oracles the adversary

may call, we do include the time and memory used to write down an oracle query and …";Cité 3 fois;Les 5 versions;[PDF] iacr.org;https://eprint.iacr.org/2020/785.pdf;"
The Memory-Tightness of Authenticated Encryption‹

Ashrujit Ghoshal, Joseph Jaeger, and Stefano Tessaro

Paul G. Allen School of Computer Science & Engineering
University of Washington, Seattle, US

{ashrujit,jsjaeger,tessaro}@cs.washington.edu

Abstract. This paper initiates the study of the provable security of authenticated encryption (AE)
in the memory-bounded setting. Recent works – Tessaro and Thiruvengadam (TCC ’18), Jaeger and
Tessaro (EUROCRYPT ’19), and Dinur (EUROCRYPT ’20) – focus on confidentiality, and look at
schemes for which trade-offs between the attacker’s memory and its data complexity are inherent. Here,
we ask whether these results and techniques can be lifted to the full AE setting, which additionally
asks for integrity.

We show both positive and negative results. On the positive side, we provide tight memory-sensitive
bounds for the security of GCM and its generalization, CAU (Bellare and Tackmann, CRYPTO ’16).
Our bounds apply to a restricted case of AE security which abstracts the deployment within protocols
like TLS, and rely on a new memory-tight reduction to corresponding restricted notions of confiden-
tiality and integrity. In particular, our reduction uses an amount of memory which linearly depends
on that of the given adversary, as opposed to only imposing a constant memory overhead as in earlier
works (Auerbach et al., CRYPTO ’17).

On the negative side, we show that a large class of black-box reductions cannot generically lift confi-
dentiality and integrity security to a joint definition of AE security in a memory-tight way.

Keywords: Provable security, symmetric cryptography, time-memory trade-offs, memory-tightness

1 Introduction

Cryptographic attacks aim to use as little memory as possible. While some attacks are memoryless (e.g.,
for collision finding), others are subject to a trade-off – as the available memory decreases, the time and
data complexities increase. A security proof (especially one in the spirit of concrete security) should tell
us precisely how memory affects other complexity metrics. However, this is technically challenging, and
consequently, security proofs ignored memory until recently.

This paper continues an ongoing line of works introducing memory limitations in provable security,
and initiates the study of (nonce-based) authenticated encryption (AE) in the memory-bounded setting.
Recent works [17,11,7] have shown memory-sensitive proofs of security for symmetric encryption, showing
that trade-offs between memory and data complexities are inherent. These results, however, only deal with
confidentiality of encryption – and one of the main contributions of this paper is to highlight the challenges
of lifting them to the more complex setting of AE.

We discuss definitional aspects, and then shift our focus to memory-tight reductions [1] in the AE setting.
We prove both positive and negative results. We introduce a new technique for memory-tight reductions to
obtain tight memory-sensitive bounds for the AE-security of GCM in a setting that corresponds to its usage
for establishing a secure channel. We also show that restricting AE security to specific settings is inherent for
memory-tight reductions – indeed, we show that the common approach of lifting confidentiality and integrity
guarantees into a combined notion of AE security (or of CCA security) fails in its most general form, at least
with respect to a broad class of security reductions.

‹ A preliminary version of this paper appears in the proceedings of CRYPTO 2020. This is the full version.



1.1 Context: Time-memory Trade-offs for AE

Let us start by setting the context and highlighting some of the challenges. First off, existing results [11,7]
can be combined to analyze the INDR security1 of nonce-based encryption. For example, consider a toy
scheme2 SE based on a block cipher E with block length n which encrypts M P t0, 1un with key K as

SE.EpK,N,Mq “ EKpNq ‘M .

Here, N is the nonce and INDR security should hold as long as no two messages are encrypted with the
same nonce. One can show that for every adversary A with time, data, and memory complexities t, q, and
S, respectively,

AdvindrSE pAq ď O

ˆ

q ¨ S ¨ logpqq

2n

˙

` AdvprpE pBq , (1)

where B is an adversary against the security of E as a pseudorandom permutation (PRP), which has time
and memory complexities (roughly) t and S, respectively, and makes q queries. In particular, if S ă 2n{2,
then SE achieves beyond-birthday security q ą 2n{2 with respect to data complexity.

Our goal, in more detail. However, INDR security is rarely sufficient on its own – we want fully secure
AE schemes which also satisfy (ciphertext) integrity (or CTXT security, for short). Following [16], we adopt
a single AE security definition that incorporates both INDR and CTXT, by measuring indistinguishability
of two oracle pairs pEncb,Decbq for b P t0, 1u. For b “ 1, Enc1 returns real ciphertexts, and Dec1 decrypts
properly. For b “ 0, instead, Enc0 returns random ciphertexts, and Dec0 decrypts only previous outputs
from Enc0. It is important to use a combined definition, as it captures settings such as chosen-ciphertext
attacks and padding-oracle attacks [18], which use a decryption oracle to break confidentiality.3

Lifting trade-offs. We want to prove a bound analogous to that of (1) for AE security, preserving in
particular the existing space-time trade-off. The usual approach is to prove INDR and CTXT individually,
and then combine them to show AE security. This makes sense because (1) we know how to prove tight
trade-offs for INDR security, and (2) we may be able to prove stronger bounds on CTXT easily, even
without memory restrictions. The classical statement (originally in [16]) is that for every adversary A,

AdvaeSEpAq ď AdvindrSE pBq ` AdvctxtSE pCq ,

for suitable adversaries B and C, with similar time and query complexities as those of A. However, this is only
helpful towards our goal if the reduction is memory-tight, in the sense Auerbach et al. (ACKF) [1], i.e., B and
C’s memory costs must not noticeably exceed those of A. This is fundamental to preserve a time-memory
trade-off like the one from (1).

Unfortunately, the standard proof is not memory-tight with respect to the INDR adversary B, as it needs
to simulate Dec0 which requires remembering prior ciphertexts. In a nutshell, we will show that the lack of
memory-tightness is inherent, but the definition can be restricted enough for interesting deployment scenarios
to actually allow for a memory-tight reduction.

Definitional issues. Several “without loss of generality” definitional equivalences are false in the memory-
bounded setting. For example, INDR security holds as long as nonces do not repeat, but there are options
to formalize this, e.g.: (A) The game enforces this by answering encryption queries repeating a nonce with
K, unless the same message is re-encrypted, or (B) The adversary never repeats a nonce. If we do not care
about memory, these two definitions are indeed equivalent, but if we do, then they are not. Indeed, the bound
in (1) for our toy scheme can only be true for (B) – it is not hard to see that otherwise we can mount a
memory-less distinguishing attack with q ÂŤ 2n{2 queries. (The attack also works if K is returned even if we
re-encrypt the same message.) We discuss definitions in detail in Section 3.

1 Which measures the indistinguishability of ciphertexts from truly random ones.
2 Our discussion can easily be extended to many schemes following the format of counter-mode encryption.
3 While we target such a single definition of AE, we stress that our results would extend to considering CCA security

as a target.

2



1.2 Positive Results

We provide a novel memory-tight reduction for the common case where AE is used to establish a secure
communication channel, as in TLS. The key point is that in this setting, only certain restricted adversarial
interactions can occur in the AE security game, i.e.:

(1) Nonces are implicit – they are incremented as a counter.
(2) The receiver aborts upon the first decryption failure. In particular, messages need to be delivered in the

same order as they are encrypted.

Our memory-tight reduction is for an abstraction of this setting we refer to as a channel. (Although, for this
introduction, we stick with the more conventional language of AE.) We apply our reduction to prove (tight)
memory-sensitive bounds for a channel instantiated with the CAU scheme by Bellare and Tackmann [4], an
abstraction of GCM [12].

The security game.When restricting AE security to this setting, we can assume that the adversary A can
encrypt messages M1,M2, . . . and obtains ciphertexts C1, C2, . . . via an encryption oracle Encb, for b P t0, 1u.
When b “ 1, the Ci’s are actual encryptions of the Mi’s (with increasing nonces), whereas when b “ 0, they
are truly random ciphertexts. The adversary is also given access to a decryption oracle Decb. If b “ 1, this
just applies the decryption algorithm of the AE scheme, using increasing nonces. If decryption fails, Decb
responds to this and any future queries with K. For b “ 0, the oracle responds with M1,M2, . . . as long as it
is supplied the ciphertexts C1, C2, . . . in the order they have been produced by Enc0. If the ciphertexts come
in the wrong order, Dec0 responds to this and any future queries with K. The goal here is to distinguish
pEnc0,Dec0q and pEnc1,Dec1q.

Proof idea. In this channel setting, to obtain a memory-tight reduction from AE security to CTXT and
INDR security, we first use CTXT security to replace the oracles pEnc1,Dec1q with pEnc1,Dec0q. (This
step is easily seen to be memory-tight.) Next, we aim to use INDR security to replace Enc1 with Enc0. The
catch here is that when doing so, we need to simulate the Dec0 oracle in the INDR security game (which does
not provide one). Again, this seems to require remembering all prior ciphertexts, thus preventing memory-
tightness.

A key observation, however, is that ciphertexts are only accepted when arriving with the right order.
For this reason, we will show (via an information-theoretic argument) that our reduction only needs to store
the δ oldest ciphertexts which have not been delivered yet, for some δ – the key point here is that δ can be
chosen to depend (roughly linearly) on the memory of the adversary used by the reduction, so the overall
memory of the constructed adversary is of the same magnitude of that of the AE adversary.

This is in contrast to existing memory-tight reductions in the literature which are (near) “memory-less”,
i.e., the reduction adds a small memory overhead, independent of the memory of the adversary. Our reduction
is the first example where the reduction uses memory in addition to that of the adversary, but the size of
this memory is bounded in terms of the adversary’s memory complexity.

Application to CAU. We apply our memory-tight reduction to show bounds for CAU (and hence GCM)
in the communication channel setting. We refer to the resulting channel as NCH, and it is based on a block
cipher E. We show that for every adversary A, there exists B such that

Advch-aeNCH pAq ď 4 ¨ AdvprpE pBq `O
ˆ

pqS

2n

˙

, (2)

where Op¨q hides a small constant, q and S are the data and memory complexities of A, and p is an upper
bound on the length of ciphertexts. Further, B makes q ¨p queries, and has time complexity similar to that of
A. Instrumental to our result here is Dinur’s Switching Lemma [7]. The main challenge is to prove a bound
for CTXT security – our proof relies once again on similar techniques to our memory-tight reduction.

1.3 Negative Results

A meaningful question is whether we can give a memory-tight reduction beyond the setting of channels,
and reduce AE security to INDR and CTXT security in the most general sense. Here, we show that this is
unlikely by giving impossibility results for black-box reductions.

3



We consider reductions to INDR and CTXT which are restricted, but note that all prior impossibility
results on memory-tight reductions [1,19,9] make similar or stronger restrictions. In particular, we require
the reductions to simulate their encryption oracles “faithfully” to an AE adversary, i.e., if they answer an
encryption query with a ciphertext C, the same query (1) has been asked to the encryption oracle available
to the reduction and (2) it has returned C. This restriction is natural, and we are not aware of any reductions
evading it.

Straightline reductions. Our first result builds an (inefficient) adversary A against AE security which
no straightline reduction can use to (1) break CTXT security (regardless of the memory available to the
reduction) or, more importantly, to (2) break INDR security (unless the reduction uses an amount of memory
proportional to the query complexity of the adversary). Moreover, A uses little memory, and thus our result
implies impossibility even for “weakly memory-tight reductions” which adapt their memory usage (such as
the one we give in this paper). This is unlike recent works [19,9], which only rule out reductions with memory
independent of that of the adversary.

At a high level, A forces the reduction to complete a memory-hard task before being useful. If the
reduction succeeds, A executes an (inefficient) procedure to break INDR security. (And importantly, this
procedure does not help in breaking CTXT security!) More in detail, the first part of A’s execution consists
of challenge rounds. In each of these rounds, A encrypts random plaintexts M1, . . . ,Mu, which result in
ciphertexts C1, . . . , Cu, and also picks a random index i˚ P rus. It then asks for the decryption of Ci˚ , and
checks whether the response equals Mi˚ . If so, it moves to the next round, if not it aborts by doing something
useless. Only if all rounds are successful A proceeds to break INDR security. We use techniques borrowed
from the setting of random oracles with auxiliary input (AI-ROM) [5] to prove that the probability that all
rounds are successful decays exponentially as long as the reduction’s memory does not fit all of M1, . . . ,Mu.

Full Rewinding.The restriction to straightline reductions seem too restrictive: After all, a reduction could
(1) wait for a decryption query Ci˚ , then (2) rewind the adversary to re-ask M1,M2, . . . until Mi˚ is asked.
The caveat is that our definition of INDR security does not allow for re-asking encryption queries (again, as
pointed out above, such a notion would prevent us from using the results of [11,7]). Therefore, if we assume
that all the reduction can do is remember (say) S plaintext-ciphertext pairs, the above adversary A will fail
to pass a challenge round with probability at least 1´ S{u.

Still, this does not mean that rewinding cannot help when allowing more general adversarial strategies.
While handling arbitrary rewinding appears to be out of reach, we make partial progress by extending our
proof (and our construction of A) to show that “full” rewinding (i.e., re-running A from the beginning) does
not help. This is the same rewinding model considered in prior memory-tightness lower bounds [1]. However,
in those results, one obtains a rewinding-memory trade-offs (in that reducing memory would require more
rewinding). Here, our result is absolute, in the sense that if memory is too small, no amount of rewinding
can help.

Paper overview. In Section 2, we introduce our notation, basic definitions and cover some cryptographic
background necessary for the paper. In Section 3, we recall the standard definitions for the security notions of
nonce-based encryption. We point out several nuances while defining security in the memory bounded setting.
We conclude the section by giving a time-memory tradeoff for the INDR security of CAU. In Section 4, we
show that memory-tight reductions can be given for the combined confidentiality and integrity security of
cryptographic channels. Using the result from Section 3, we prove the security of a channel based on CAU.
The resulting channel can be viewed as (a simplification of) the channel obtained when using GCM in TLS
1.3. In Section 5, we give impossibility results (for a natural restricted class of black-box reductions) for
giving a memory-tight reduction from AE security to INDR and CTXT security. This establishes that our
move to the channel setting for Section 4 was necessary for our positive result.

2 Definitions

Let N “ t0, 1, 2, . . . u. For D P N, let rDs “ t1, 2, . . . , Du. If S and S1 are finite sets, then FcspS, S1q denotes
the set of all functions F : S Ñ S1 and PermpSq denotes the set of all permutations on S. Picking an element

4



uniformly at random from S and assigning it to s is denoted by sÐ$ S. The set of finite vectors with entries
in S is S˚ or pSq˚. Thus t0, 1u˚ is the set of finite length strings.

If x P t0, 1u˚ is a string, then |x| denotes its bitlength. If n P N and x P t0, 1u˚, then |x|n “ maxt1, r|x|{nsu.
We let x1 . . . x` Ðn x denote setting `Ð |x|n and parsing x into ` blocks of length n (except x` which may
have |x`| ă n). We let xr: ns denote the first n bits of x and xri : ns denote the i-th (exclusive) through n-th
(inclusive) bits of x. We adopt the convention that if |x| ă |x1| then x‘ x1 “ x‘ x1r: |x|s. The empty string
is Îľ.

We will make use of queues which operate in first-in, first-out order. If Q is a queue then Q.addpMq
adds M to the back of the queue and M Ð Q.dqpq removes the first element of the queue and assigns it to
M . If the queue is empty, then M is assigned the value K R t0, 1u˚ which is used to represent rejection or
uninitialized values.

Algorithms are randomized when not specified otherwise. If A is an algorithm, then y Ð AO1,...px1, . . . ; rq
denotes running A on inputs x1, . . . with coins r and access to the oracles O1, . . . to produce output y.
Performing this execution with a random r is denoted yÐ$ AO1,...px1, . . . q. The set of all possible outputs
of A when run with inputs x1, . . . is rApx1, . . . qs. The notation y Ð Opx1, . . . q is used for calling oracle
O with inputs x1, . . . and assigning its output to y. (Note, the code run by the oracle is not necessarily
deterministic.)

We make regular use of pseudocode games inspired by the code-based framework of [3]. Examples of
games can be found in Fig. 1. We let PrrGs denote the probability that a game G outputs true. Booleans
are implicitly initialized to false, integers to 0, and all other types to K.

Complexity conventions. When measuring the efficiency of an adversary we follow the standard con-
vention used in studying memory-tightness [1] on measuring the local complexity of an adversary and not
included the complexity of whatever game it interacts with. We primarily focus on the worst-case runtime
(i.e. how much computation it performs in between making oracle queries) and memory complexity (i.e. how
many bits of state it stores for local computation) of adversaries. Note that while these exclude the time and
memory used within whatever oracles the adversary may call, we do include the time and memory used to
write down an oracle query and receive the response.

2.1 Cryptographic Background

Function family.A function family is an efficiently computable function F : AˆB Ñ C, where A, B, and
C are sets. A hash function is a family of functions. We often write FKp¨q in place of F pK, ¨q.

Pseudorandom function/permutation. Let E : t0, 1uk ˆ t0, 1un Ñ t0, 1um be a function family. If
n “ m and EKp¨q is a permutation for each K P t0, 1uk, then we say that E is a block-cipher. The primary
security notions of interest for such functions are PRF and PRP security. The former is typically more useful
in applications, but when E is a block-cipher we prefer to assume PRP security and use that to deduce PRF
security.

These security notions are defined by games shown in Fig. 1. In Gprp, the adversary is given access to
either EKp¨q for a random key or a random permutation P : t0, 1un Ñ t0, 1un. Game Gprf is defined similarly
except a random function F : t0, 1un Ñ t0, 1um is used in place of the permutation. For x P tprp, prfu, we
define the advantage of A by AdvxEpAq “ PrrGxE,1pAqs ´ PrrGxE,0pAqs.
Switching Lemma. A classic result in cryptography is the “switching lemma” which bounds how well
an adversary can distinguish between a random function and a random permutation. Consider the game
Gsl
D,b shown in Fig. 1. In it, the adversary is given oracle access to either a random function or a random

permutation with domain/range rDs and is trying to figure out which. We define AdvslDpAq “ PrrGsl
D,bpAqs ´

PrrGsl
D,bpAqs.

The classic switching lemma shows AdvslDpAq P Opq2{Dq where q is the number of queries made by
A. In general, bounding the memory-complexity of the attacker cannot be used to meaningfully improve
this bound because a low-memory collision-finding attack (e.g., using Pollard’s ρ-method [13,14]) achieves
advantage AdvslDpAq P Ωpq2{Dq. However, as originally observed by Jaeger and Tessaro we can obtain better
results when restricting attention to adversaries that never repeat any queries.

5



Game Gprp
E,bpAq

KÐ$ t0, 1uk

P Ð$ Permpt0, 1unq
b1Ð$ AEvalb

Return b1 “ 1

Oracle Evalbpxq
y1 Ð EKpxq
y0 Ð P pxq
Return yb

Game Gprf
E,bpAq

KÐ$ t0, 1uk

F Ð$ Fcspt0, 1un, t0, 1umq
b1Ð$ AEvalb

Return b1 “ 1

Oracle Evalbpxq
y1 Ð EKpxq
y0 Ð F pxq
Return yb

Game Gsl
D,bpAq

F Ð$ FcsprDs, rDsq
P Ð$ PermprDsq
b1Ð$ AEvalb

Return b1 “ 1

Oracle Evalbpxq
y1 Ð F pxq
y0 Ð P pxq
Return yb

Fig. 1. Security games for PRF and PRP security of E and the switching lemma.

Game Gaxu
H pX q

ppA1, C1q, pA2, C2q, Zq Ð$ X
LÐ$ t0, 1uk

If pA1, C1q “ pA2, C2q then return false

Return HLpA1, C1q ‘HLpA2, C2q “ Z

Fig. 2. Security game for AXU security of H.

Let AdvslDpq, Sq denote the maximal value of AdvslDpAq for all A that are S-bounded and make q non-
repeating queries to their oracle. Jaeger and Tessaro [11] showed that AdvslDpq, Sq ď

a

Sq{D under a combi-

natorial conjecture. Later, Dinur [7] improved this to show that AdvslDpq, Sq P OpSq logpqq{Dq.
An immediate application of the switching lemma is that if A is an S-bounded adversary which makes q

non-repeating queries to its oracle, then |AdvprfE pAq ´AdvprpE pAq| ď AdvslDpq, Sq for any block-cipher E whose
range has size D.

AXU hash function. Let H : t0, 1uk ˆ pt0, 1u˚ ˆ t0, 1u˚q Ñ t0, 1un be a hash function. Its almost XOR-
universal (AXU) security is defined by the game Gaxu

H shown in Fig. 2. In it, an adversary X attempts to guess
the xor of the output of H on two distinct inputs of its choosing for a random key L. We define AdvaxuH pX q “
PrrGaxu

H pX qs. Typically one makes use of a c-AXU hash which for all X satisfy AdvaxuH pX q ď c ¨ pN1`N2q{2
n

where N1 (resp. N2) is the maximum block length of any A (resp. C) output by X . Note this is unconditional,
so we will not have to worry about memory complexity when reducing to AXU security.

3 Nonce-based Encryption and Memory-boundedness

In this section we recall known definitions and results for nonce-based encryption [15]. We carefully consider
how these change when we move to the memory-bounded setting. For example, as was previously noted by
Auerbach, et al. [1], definitions which are tightly equivalent when the memory usage of adversaries is not
bounded do not necessarily remain so with bounds on memory. So we will consider several variants of the
definitions we are recalling and try to reason about which is the “correct” one to use. We additionally note
some results which can be extended to give appealing time-memory tradeoffs in the memory-bounded setting
and some for which this does not seem to be possible.

In Section 3.1, we discuss INDR security which measures the indistinguishability of ciphertexts from
truly random ones. This security notion requires that the adversary be disallowed from repeating nonces. We
discuss three conventions for capturing this which are tightly equivalent when ignoring memory restrictions,
but observe they are no longer tightly equivalent with these restrictions. Based on these discussions, the rest
of the paper focuses on the restricted class of adversaries that will never repeat nonces in their queries to
encryption oracles. In Section 3.2, we discuss CTXT (integrity of ciphertexts) and AE security (combined
INDR and CTXT) security. For these, the adversary must be disallowed from trivially winning by forwarding

6



ciphertexts from its encryption oracle to its decryption oracle. Again we discuss several conventions for this
which are tightly equivalent when ignoring memory restrictions. Based on these discussions, the rest of the
paper will use the convention that if an adversary queries pN,Cq to its decryption oracle after receiving
C from an encryption query for pN,Mq, the oracle will respond with M . With our chosen conventions, it
does not appear to be possible to prove that AE security is implied by INDR and CTXT security with a
memory-tight reduction. The rest of the paper will focus on this (im)possibility. Section 4 shows it is possible
in the restricted setting of secure channels while Section 5 shows it is not possible for general nonce-based
encryption if the reduction behaves in a black-box manner.

Finally, in Section 3.3 we recall the CAU scheme by Bellare and Tackmann [4], an abstraction of GCM [12].
Following existing proofs [4,10,12] and using [11,7], we show that INDR security of CAU can be proven by a
memory-tight reduction to PRP security with an appealing time-memory tradeoff and we informally discuss
why such reductions seem impossible for CTXT or AE security.

Syntax and correctness.A (nonce-based) encryption scheme NE is defined by algorithms NE.Kg, NE.D,
and NE.E. Additionally it is associated with message space NE.M Ď t0, 1u˚ and nonce space NE.N.

The syntax of the algorithms is shown in Fig. 3. The key generation algorithm NE.Kg takes no input
and returns key K. The encryption algorithm NE.E takes key K, nonce N P NE.N, and message M P NE.M.
It returns ciphertext C. The decryption algorithm NE.D takes key K, nonce N P NE.N, and ciphertext

NE Syntax
KÐ$ NE.Kg
C Ð NE.EpK,N,Mq
M Ð NE.DpK,N,Cq

Fig. 3. Syntax of nonce-based
encryption scheme.

C. It returns message M P NE.M Y tKu. When M “ K, the ciphertext is
rejected as invalid.

We additionally assume there is a ciphertext-length function NE.cl : NÑ
N such that for any K P rNE.Kgs, N P NE.N, and M P NE.M we have
|C| “ NE.clp|M |q whenever C Ð NE.EpK,N,Mq. Typically, a nonce-based
encryption scheme also takes associated data as input which is authenticated
during encryption. Associated data does not meaningfully effect our results,
so we have omitted it for simplicity of notation.

Correctness of an encryption scheme requires for all K P rNE.Kgs, N P

NE.N, and M P NE.M that NE.DpK,N,NE.EpK,N,Mqq “M .

3.1 Indistinguishability From Random (INDR) Security

The first security notion we will consider requires that ciphertexts output
by the encryption scheme cannot be distinguished from ciphertexts chosen at random.

Definitions.Consider the game Gindr
NE,b shown in Fig. 4. Here an adversary A is given access to an encryption

oracle Enc to which it can query a pair pN,Mq and receive back either the encryption of message M with
nonce N (b “ 1) or a random string of the appropriate length (b “ 0). The adversary outputs a bit trying
to guess which of these two views it was given. We define AdvindrNE pAq “ PrrGindr

NE,1pAqs ´ PrrGindr
NE,0pAqs.

In defining security we must address how to handle the possibility of A making multiple queries with
the same nonce. Encryption schemes are typically designed under the assumption that the same nonce will
not be used multiple times and may become completely insecure in the face of such nonce repetition. The
primary convention we will adopt is to restrict attention to adversaries that will never repeat nonces in their
encryption queries. We use the phrase “nonce-respecting INDR” to refer to security with respect to such
adversaries.

An alternate approach would be to modify the code of the game to respond appropriately to queries
where nonces repeat. One version of this, which we will refer to as INDR-R, would restrict attention to
adversaries that will only repeat nonces when they also repeat the message queried to encryption. For this
the game would be modified to keep track of all encryption queries that have been made so far. When it
receives a repeated pN,Mq pair, it simply returns the same C that it returned last time it saw that pair. A
second version of this, which we will refer to as INDR-B, makes no restriction on the queries of the adversary.
Instead, the game is modified to return K whenever the adversary makes a query with a nonce it has already
used.

7



Game Gindr
NE,bpAq

KÐ$ NE.Kg
b1 Ð AEncb

Return b1 “ 1

Oracle EncbpN,Mq
C1 Ð NE.EpK,N,Mq
C0 Ð$ t0, 1uNE.clp|M |q

M rN,Cbs ÐM
Return Cb

Game Gctxt-w
NE,b pAq

KÐ$ NE.Kg
b1 Ð AEnc1,Decwb

Return b1 “ 1

Game Gae-w
NE,b pAq

KÐ$ NE.Kg
b1 Ð AEncb,Decwb

Return b1 “ 1

Oracle Decwb pN,Cq
If M rN,Cs ‰ K then

Return M rN,Cs if w “ 1
Return ˛ if w “ 2
Return K if w “ 3

M1 Ð NE.DpK,N,Cq
M0 Ð K

Return Mb

Fig. 4. Games defining INDR, CTXT-w, and AE-w security of NE for w P t1, 2, 3u.

Discussion. When memory is not an issue, all of these variants would be equivalent. Proving this follows
by noting that an adversary can just remember all prior queries it has made and thus never need to repeat.
This proof strategy is no longer available to us when we want to preserve the memory usage of adversaries.
We focus on nonce-respecting INDR because it hits the sweet spot of being strong enough for common
applications, yet weak enough that we know how to give provable time-memory trade-offs.

Because nonce-respecting INDR considers a strictly smaller class of adversaries than the other two and
all of the games behave identically for this class of adversary it is tightly implied by the others. In fact, using
ideas from [11,7] we can see that nonce-respecting INDR is strictly weaker. The toy encryption scheme SE
considered in the introduction built from a block-cipher with block length n is vulnerable to low-memory
collision-finding attacks with advantage Ωpq2{2nq in the INDR-R and INDR-B settings, but no attacks
can have advantage better than Opqs{2nq in the nonce-respecting INDR setting. Here q and s refer to the
number of queries and amount of memory used by the attackers, respectively. This underlies why the ideas
of Jaeger and Tessaro [11] can be used to prove nonce-respecting INDR (but not INDR-R or INDR-B) time-
memory trade-offs for natural counter-mode based encryption schemes. In most common uses of nonce-based
encryption the nonces are incremented as a counter or picked uniformly at random. In the former case,
nonces clearly never repeat so nonce-respecting INDR suffices (we will see this formally in Section 4). Nonces
may repeat in the latter case, but we can follow [11,7] here and replace the uniform random values with
random, non-repeating values so again nonce-respecting INDR suffices.

3.2 Security Beyond Confidentiality

INDR security only guarantees confidentiality of the messages against passive attackers. However, in practice,
attackers may actively modify ciphertexts in transit. As such, it is important to consider security definition
that take this into account. We will consider integrity definitions and authenticated encryption definitions
which simultaneously asked for integrity and confidentiality.

Definitions.Consider the other two games shown in Fig. 4. We will first focus on Gae-w
NE,b which defines three

variants of authenticated encryption security parameterized by w P t1, 2, 3u. In this game, the adversary is
given access to an encryption oracle and a decryption oracle. Its goal is to distinguish between a “real” and
“ideal” world. In the real world (b “ 1) the oracles uses NE to encrypt messages and decrypt ciphertexts. In
the ideal world (b “ 0) encryption returns random messages of the appropriate length and decryption returns
K. For simplicity, we will restrict attention nonce-respecting adversaries which do not repeat nonces across
encryption queries (as in nonce-respecting INDR security). Note there is no restriction placed on nonces used
for decryption queries. Integrity of ciphertext security is defined by Gctxt-w

NE,b which behaves similarly except
the adver";"""date"",""2020-06-24T16:11:22Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""The Memory-Tightness of Authenticated Encryption""
""xmp:CreatorTool"",""LaTeX with hyperref""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""The Memory-Tightness of Authenticated Encryption""
""modified"",""2020-06-24T16:11:22Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""Ashrujit Ghoshal, Joseph Jaeger, Stefano Tessaro""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.20 (TeX Live 2019) kpathsea version 6.3.1""
""meta:author"",""Ashrujit Ghoshal, Joseph Jaeger, Stefano Tessaro""
""trapped"",""False""
""meta:creation-date"",""2020-06-24T16:11:22Z""
""created"",""2020-06-24T16:11:22Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-06-24T16:11:22Z""
""resourceName"",""785.pdf""
""Author"",""Ashrujit Ghoshal, Joseph Jaeger, Stefano Tessaro""
""producer"",""pdfTeX-1.40.20""
""pdf:docinfo:producer"",""pdfTeX-1.40.20""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""5"",""0"",""0"",""0"",""0"",""8"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""6"",""4"",""3"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""Ashrujit Ghoshal, Joseph Jaeger, Stefano Tessaro""
""dcterms:created"",""2020-06-24T16:11:22Z""
""Last-Modified"",""2020-06-24T16:11:22Z""
""dcterms:modified"",""2020-06-24T16:11:22Z""
""title"",""The Memory-Tightness of Authenticated Encryption""
""Last-Save-Date"",""2020-06-24T16:11:22Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2020-06-24T16:11:22Z""
""meta:save-date"",""2020-06-24T16:11:22Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.20 (TeX Live 2019) kpathsea version 6.3.1""
""Content-Length"",""568235""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Ashrujit Ghoshal, Joseph Jaeger, Stefano Tessaro""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""35""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""3019"",""3402"",""3477"",""3917"",""3601"",""2690"",""3585"",""3404"",""3677"",""2916"",""2975"",""2866"",""3254"",""2740"",""2712"",""2893"",""2758"",""2193"",""2623"",""2273"",""2607"",""2776"",""3590"",""2629"",""2119"",""2186"",""2259"",""1709"",""1728"",""2255"",""2247"",""2561"",""2538"",""2225"",""1175""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-06-24T16:11:22Z""
";https://scholar.google.ch/scholar?start=870&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098720-7;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;DeFi and the Future of Finance;CR Harvey, A Ramachandran… ; Available at SSRN …, 2020  papers.ssrn.com;;"… We discuss the oracle problem later in more depth … Oracles are surely an open design question

and challenge for DeFi to achieve utility beyond its own isolated chain … exposure to the returns

of an off-chain asset if the target asset is not native to the underlying blockchain (eg, gold …";Cité 5 fois;;[PDF] duke.edu;https://faculty.fuqua.duke.edu/~charvey/Teaching/697_2021/Public_Presentations_697/DeFi_2021_5_Deep_697.pdf;"
DeFi and the Future of Finance:
5. DeFi Deep Dive

Campbell R. Harvey
Duke University and NBER



Outline

• Credit/Lending 
• MakerDAO; Compound; Aave

• Decentralized Exchange 
• Uniswap

• Derivatives 
• Yield protocol, dYdX, Sythetix

• Tokenization
• Set protocol, wBTC

Campbell R. Harvey 2021 3



Credit/Lending: MakerDAO

Background
• As the name suggests, MakerDAO is a decentralized autonomous 

organization. 
• The primary value-add is the creation of a crypto-collateralized

stablecoin, pegged to USD called DAI. This means the system can
run completely from within the Ethereum blockchain without
relying on outside centralized institutions to back, vault and audit
the stablecoin.

• Two token model: DAI = stablecoin and MKR = governance token

Campbell R. Harvey 2021 4
https://makerdao.com/whitepaper/White%20Paper%20-The%20Maker%20Protocol_%20MakerDAO%E2%80%99s%20Multi-Collateral%20Dai%20(MCD)%20System-FINAL-%20021720.pdf

https://makerdao.com/whitepaper/White%20Paper%20-The%20Maker%20Protocol_%20MakerDAO%E2%80%99s%20Multi-Collateral%20Dai%20(MCD)%20System-FINAL-%20021720.pdf


Credit/Lending: MakerDAO

Mechanics of DAI
• DAI is generated as follows. A user can deposit ETH or other 

supported ERC-20 assets into a Vault. 
• A Vault is a smart contract that escrows collateral and keeps track 

of the USD-denominated value of the collateral. 
• The user can then mint DAI up to a certain collateralization ratio 

on their assets. 
• This creates a “debt” in DAI that must be paid back by the Vault 

holder. 
Campbell R. Harvey 2021 5



Credit/Lending: MakerDAO

Mechanics of DAI
• The DAI is the corresponding asset that can be used any way the 

Vault holder wishes. 
• Example 1: user can sell the DAI for cash 
• Example 2: use can use DAI to buy more of the collateral asset, and 

repeat the process, to create a levered position. 
• Due to the volatility of ETH and most collateral types, the 

collateralization requirement is far in excess of 100% and usually 
in the 150-200% range. 

Campbell R. Harvey 2021 6



Credit/Lending: MakerDAO

Collateralized debt position (CDP)
• The basic idea is not new; a homeowner in need of some liquidity 

can pledge their house as collateral to a bank and receive a 
mortgage loan structured to include a cash takeout. 

• The price volatility of ETH is much greater than for a house and, as 
such, collateralization ratios for the ETH-DAI contract are higher. 

• In addition, no centralized institution is necessary as everything 
happens within the Ethereum blockchain. 

Campbell R. Harvey 2021 7



Credit/Lending: MakerDAO

Example
• Suppose an ETH owner needs liquidity but does not want to sell 

her ETH because she thinks it will appreciate. 
• The situation is analogous to the homeowner who needs liquidity 

but does not want to sell her house. 

Campbell R. Harvey 2021 8



Credit/Lending: MakerDAO

Example
• Let’s say an investor has 5 ETH at a market price of $200 (total 

value of $1,000). 
• If the collateralization requirement is 150%, then the investor can 

mint up to 667 DAI ($1,000/1.5 with rounding). 
• The collateralization ratio is set high to reduce the probability that 

the loan debt exceeds the collateral value, and for the DAI token 
to be credibly pegged to the USD, the system needs to avoid the 
risk that the collateral is worth less than $1=1 DAI.

Campbell R. Harvey 2021 9



Credit/Lending: MakerDAO

Example
• Given the collateralization ratio of 1.5, it would be unwise to mint 

the 667 DAI because if the ETH ever dropped below $200, the 
contract would be undercollateralized, the equivalent of a 
“margin call”. 

• We are using traditional finance parlance, but in DeFi there is no 
communication from your broker about the need to post 
additional margin or to liquidate the position and also no grace 
period. 

• Liquidation can happen immediately. 

Campbell R. Harvey 2021 10



Credit/Lending: 
MakerDAO

Campbell R. Harvey 2021 11



Credit/Lending: 
MakerDAO

Campbell R. Harvey 2021 12

• Suppose ETH rises by 
50% so collateral is 
worth $1,500. 

• The investor can increase 
the size of her loan. 

• To maintain the 
collateralization of 200%, 
the investor can mint an 
extra 250 DAI.



Credit/Lending: 
MakerDAO

Campbell R. Harvey 2021 13

• Suppose the value of the 
ETH drops by 25% from 
$200 to $150. 

• In this case, the value of 
the collateral drops to 
$750 and the 
collateralization ratio 
drops to 1.5 ($750/1.5 = 
500).  



Credit/Lending: MakerDAO

Example
Suppose the value of the ETH drops by 25% from $200 to $150. 
• The Vault holder faces three scenarios. 

1. She can increase the amount of collateral in the contract (by, for 
example, adding 1 ETH). 

2. She can use the 500 DAI to pay back the loan and repatriate the 5 ETH. 
These ETH are now worth $250 less, but the depreciation in value 
would have happened irrespective of the loan. 

3. The loan is liquidated by a keeper (any external actor). 

Campbell R. Harvey 2021 14



Credit/Lending: MakerDAO

Campbell R. Harvey 2021 15

• The keeper auctions the ETH for enough DAI to pay off the loan. 
• 3.33 ETH are sold and 1.47 ETH returned to the Vault holder. 
• Keeper gets incentive fee of 0.2 ETH
• Vault holder has 500 DAI worth $500 and 1.47 ETH worth $220. 



Credit/Lending: MakerDAO

Stability forces
• Two forces in this process reinforce the stability of DAI. 

1. Overcollateralization. 
2. Market actions. In the liquidation, ETH are sold and DAI are purchased, 

which exerts positive price pressure on DAI. 

Campbell R. Harvey 2021 16



Credit/Lending: MakerDAO

Maintaining the Peg
• The viability of the MakerDAO ecosystem critically depends on 

DAI maintaining a 1:1 peg to the USD. 
• Various mechanisms are in place to incentivize demand and 

supply in order to drive the price toward the peg. 
• The primary mechanisms are: the debt ceiling, stability fee, and 

DAI Savings Rate (DSR). 
• These parameters are controlled by holders of the governance 

token Maker (MKR) and MakerDAO governance.
Campbell R. Harvey 2021 17



Credit/Lending: MakerDAO

Stability fee
• The Stability Fee is a variable interest rate paid in DAI by Vault 

holders on any DAI debt they generate. 
• The interest rate can be raised or lowered (even to a negative 

value) to incentivize the generation or repayment of DAI to drive 
its price toward the peg. 

Campbell R. Harvey 2021 18



Credit/Lending: MakerDAO

DAI Savings Rate (DSR)
• The Stability Fee funds the DSR, a variable rate any DAI holder can 

earn on their DAI deposit. 
• The DSR compounds on a per-block basis. The Stability Fee, which 

must always be greater or equal to the DSR, is enforced by the 
smart contracts powering the platform. 

Campbell R. Harvey 2021 19



Credit/Lending: MakerDAO

DAI Debt Ceiling
• Lastly, a smart contract–enforced DAI debt ceiling can be adjusted 

to allow for more or less supply to meet the current level of 
demand. 

• If the protocol is at the debt ceiling, no new DAI is able to be 
minted in new Vaults until the old debt is paid or the ceiling is 
raised.

Campbell R. Harvey 2021 20



Credit/Lending: MakerDAO

Liquidation
• When a position is deemed to be under the liquidation ratio, a 

keeper can initiate an auction (sell some of the ETH collateral) to 
liquidate the position and close the Vault holder’s debt. 

• The Liquidation Penalty is calculated as a percentage of the debt 
and is deducted from the collateral in addition to the amount 
needed to close the position.

Campbell R. Harvey 2021 21



Credit/Lending: MakerDAO

Large drops in the value of collateral
• If the collateral drops so far in value that the DAI debt cannot be 

fully repaid, the position is closed, and the protocol accrues what 
is known as Protocol Debt. 

• A buffer pool of DAI exists to cover Protocol Debt, but in certain 
circumstances the debt can be too great for even the buffer pool 
to cover. 

• The solution involves the governance token MKR and the 
governance system.

Campbell R. Harvey 2021 22



Credit/Lending: MakerDAO

Governance
• The MKR token controls MakerDAO. 
• Holders of the token have the right to vote on protocol upgrades, 

including supporting new collateral types and tweaking 
parameters such as collateralization ratios. 

• MKR holders are expected to make decisions in the best financial 
interest of the platform. 

• Their incentive is that a healthy platform should increase the 
value of their share in the platform's governance.

Campbell R. Harvey 2021 23



Credit/Lending: MakerDAO

Global settlement
• For example, poor governance could lead to a situation where the 

buffer pool is not sufficient to pay back the Protocol Debt. 
• In this case, newly minted MKR tokens are auctioned off in 

exchange for DAI and the DAI are used to pay back the Protocol 
Debt. 

• This process is Global Settlement, a safety mechanism intended 
for use only when all other measures have failed. 

• Global Settlement dilutes the MKR share, which is why 
stakeholders are incentivized to avoid it and keep Protocol Debt to 
a minimum.

Campbell R. Harvey 2021 24



Credit/Lending: MakerDAO

Decisions of MKR holders
• Votes by the MKR holders can change any of the parameters 

available on the platform, e.g., supporting new collateral types for 
Vaults 

• MKR holders could also vote to pay themselves a dividend funded 
by the spread between the interest payments paid by Vault 
holders and the DAI Savings Rate. 

• The reward of receiving this dividend would need to be weighed 
against any negative community response that might decrease the 
value of the protocol and the MKR token.

Campbell R. Harvey 2021 25



Credit/Lending: MakerDAO

Why DAI is attractive
• Importantly, users can purchase and utilize DAI without having to 

go through the process of generating it in a Vault—they can 
simply purchase DAI on an exchange. 

• Therefore, users do not need to know the underlying mechanics 
of how DAI are created. 

Campbell R. Harvey 2021 26



Credit/Lending: MakerDAO

Why DAI is attractive
• Holders can easily earn the DAI Savings Rate by using the 

protocol. 
• More technologically and financially sophisticated users can use 

the MakerDAO web portal to generate Vaults and create DAI to 
get liquidity from their assets without having to sell them. 

• It is easy to sell DAI and purchase an additional amount of the 
collateral asset to get leverage.

Campbell R. Harvey 2021 27



Credit/Lending: MakerDAO

Drawback of DAI
• DAI supply is always constrained by demand for ETH-collateralized debt. 
• No clear arbitrage loop exists to maintain the peg. 
• For example, the stablecoin USDC is always redeemable by Coinbase for 

$1, with no fees. Arbitrageurs have a guaranteed (assuming solvency of 
Coinbase) strategy in which they can buy USDC at a discount or sell it at 
a premium elsewhere and redeem on Coinbase. 

• This is not true for DAI. Irrespective of any drawbacks, the simplicity of 
DAI makes it an essential building block for other DeFi applications.

Campbell R. Harvey 2021 28



Credit/Lending: MakerDAO

29

Traditional Finance Problem MakerDAO Solution 

Centralized Control: Interest rates are 
influenced by the US Federal Reserve and 
access to loan products controlled by 
regulation and institutional policies. 

MakerDAO platform is openly controlled by 
the MKR holders. 

Limited Access: Obtaining loans is difficult 
for a large majority of the population. 

Open ability to take out DAI liquidity against 
an overcollateralized position in any 
supported ERC-20 token. Access to a 
competitive USD-denominated return in the 
DSR. 

Inefficiency: Acquiring a loan involves costs 
of time and money. 

Instant liquidity at the push of a button with 
minimal transaction costs. 

Lack of Interoperability: Cannot trustlessly 
use USD or USD-collateralized token in smart 
contract agreements. 

Issuance of DAI, a permissionless USD-
tracking stablecoin backed by cryptocurrency. 
DAI can be used in any smart contract or 
DeFi application. 

Opacity: Unclear collateralization of lending 
institutions. 

Transparent collateralization ratios of vaults 
visible to entire ecosystem. 

 



Credit/Lending: Compound

What is Compound?
• Compound is a lending market that offers several different ERC-20 

assets for borrowing and lending. 
• All the tokens in a single market are pooled together so every 

lender earns the same variable rate and every borrower pays the 
same variable rate.

Campbell R. Harvey 2021 30



Credit/Lending: Compound

Overcollateralization
• The concept of a credit rating is irrelevant, and because Ethereum

accounts are pseudonymous, enforcing repayment in the event of a 
loan default is virtually impossible. 

• For this reason, all loans are overcollateralized in a collateral asset 
different from the one being borrowed. 

• If a borrower falls below their collateralization ratio, their position is 
liquidated to pay back their debt. 

• The debt can be liquidated by a keeper. The keeper receives a 
bonus. Campbell R. Harvey 2021 31



Credit/Lending: Compound

Collateralization ratios and factors
• The collateralization ratio is calculated via a collateral factor.
• Each ERC-20 asset on the platform has its own collateral factor 

ranging from zero to 90. 
• A collateral factor of zero means an asset cannot be used as 

collateral. 
• The required collateralization ratio for a single collateral type is 

calculated as 100 divided by the collateral factor. 

Campbell R. Harvey 2021 32



Credit/Lending: Compound

Collateralization ratios and factors
• Volatile assets generally have lower collateral factors, which 

mandate higher collateralization ratios due to increased risk of a 
price movement that could lead to undercollateralization. 

• An account can use multiple collateral types at once, in which case 
the collateralization ratio is calculated as 100 divided by the 
weighted average of the collateral types by their relative sizes 
(denominated in a common currency) in the portfolio.

Campbell R. Harvey 2021 33



Credit/Lending: Compound

Collateralization ratio is like a reserve multiplier
• The collateralization ratio is similar to a reserve multiplier in 

traditional banking, constraining the amount of “borrowed” dollars 
that can be in the system relative to the “real” supply. 

• For instance, there is occasionally more DAI in Compound than is 
actually supplied by MakerDAO, because users are borrowing and 
resupplying or selling to others who resupply. 

• Importantly, all MakerDAO supply is ultimately backed by real 
collateral and there is no way to borrow more collateral value than 
has been supplied.

Campbell R. Harvey 2021 34



Credit/Lending: Compound

Example
• An investor deposits 100 DAI with a collateral factor of 90. 
• This transaction alone corresponds to a required collateralization 

ratio of 111%. 
• Assuming 1 DAI = $1, the investor can borrow up to $90 worth of 

any other asset in Compound. 

Campbell R. Harvey 2021 35



Credit/Lending: Compound

Example
• If she borrows the maximum, and the price of the borrowed asset 

increases at all, the position is subject to liquidation. 
• Suppose she also deposits two ETH with a collateral factor of 60 and 

a price of $200/ETH. 
• The total supply balance is now $500, with 80% being ETH and 20% 

being DAI. The required collateralization ratio is 100/(0.8*60 + 
0.2*90) = 151%. 

Campbell R. Harvey 2021 36



Credit/Lending: Compound

Campbell R. Harvey 2021 37



Credit/Lending: Compound

Supply and borrow rates
• The supply and borrow interest rates are compounded every block 

(approximately 15 seconds on Ethereum producing approximately 
continuous compounding) and are determined by the utilization 
percentage in the market. 

• Utilization is calculated as total borrow/total supply. 
• The utilization rate is used as an input parameter to a formula that 

determines the interest rates. 
• The remaining parameters are set by Compound Governance.

Campbell R. Harvey 2021 38



Credit/Lending: Compound

Borrow rate formula
• The formula for the borrow rate generally is an increasing linear 

function with a y-intercept known as the base rate that represents 
the borrow rate at 0% borrow demand and a slope representing the 
rate of change of the rates. 

• These parameters are different for each ERC-20 asset supported by 
the platforms. 

Campbell R. Harvey 2021 39



Credit/Lending: Compound

Borrow rate formula
• Some markets have more advanced formulas that include a kink. A 

kink is a utilization ratio beyond which the slope steepens. 
• These formulas can be used to reduce the cost of borrowing up to 

the kink and then increase the cost of borrowing after the kink to 
incentivize a minimum level of liquidity. 

Campbell R. Harvey 2021 40



Credit/Lending: Compound

Supply interest rate formula
• Supply interest rate = (borrow interest rate x utilization ratio)           

so borrow payments can fully cover the supplier rates. 
• The reserve factor is a percentage of the borrow payments not given 

to the suppliers and instead set aside in a reserve pool that acts as 
insurance in that case a borrower defaults. 

• In an extreme price movement, many positions may become 
undercollateralized in that they have insufficient funds to repay the 
suppliers. In the event of such a scenario, the suppliers would be 
repaid using the assets in the reserve pool.

Campbell R. Harvey 2021 41



Credit/Lending: Compound

Example
• In the DAI market, 100 million is supplied and 50 million is 

borrowed. 
• Suppose the base rate is 1% and the slope is 10%. 
• At 50 million borrowed, utilization is 50%. 
• The borrow interest rate is then calculated to be 0.5*0.1 + 0.01 = 

0.06 or 6%. 
• The maximum supply rate (assuming a reserve factor of zero) would 

simply be 0.5*0.06 = 0.03 or 3%. 
Campbell R. Harvey 2021 42



Credit/Lending: Compound

Example
• The borrow rate is not a marginal rate – it is a rate for all borrowers.
• For example, suppose an initial borrower does $25 million. The rate 

would be .25*0.1 + 0.01 = 3.5%. 
• Then suppose another borrower enters the market with another 

$25 million loan.
• The rate increases to 6% for all borrowers.

Campbell R. Harvey 2021 43



Credit/Lending: Compound

Example
• If the reserve factor is set to 10, then 10% of the borrow interest is 

diverted to a DAI reserve pool, lowering the supply interest rate to 
2.7%. 0.5*0.06*(1-0.10) = 0.027 or 2.7%. 

Campbell R. Harvey 2021 44



Credit/Lending: Compound

Example
• Another way to think about the supply interest rate is that the 6% 

borrow interest of 50 million is equal to 3 million of borrow 
payments. 

• Distributing 3 million of payments to 100 million of suppliers implies 
a 3% interest rate to all suppliers. With 10% diverted (300,000), then 
there is on 2.7 million of payments

Campbell R. Harvey 2021 45



Credit/Lending: Compound

Example with kink
• Suppose 100 million DAI is supplied and 90 million DAI is borrowed, 

a 90% utilization. 
• The kink is at 80% utilization, before which the slope is 10% and 

after which the slope is 40%, which implies the borrow rate will be 
much higher if the 80% utilization is exceeded. 

Campbell R. Harvey 2021 46



Credit/Lending: Compound

Example with kink
• The base rate remains at 1%. 
• The borrow interest rate = 0.01 (base) + 0.8*0.1 (pre-kink) + 0.1*0.4 

(post-kink) = 13%. 
• The supply rate (assuming a reserve factor of zero) is 0.9*0.13 = 

11.7%.

Campbell R. Harvey 2021 47



Credit/Lending: Compound

Advantages of Compound
• Unlock value of asset without selling it – like a HELOC
• Easily engineer levered long or short positions
• Suppose you are bearish on price of ETH

• Deposit stablecoin like USDC or DAI
• Borrow ETH
• Sell ETH for stablecoin
• If price of ETH falls, you can use your stablecoin to buy (cheap) ETH to pay 

off debt 

Campbell R. Harvey 2021 48



Credit/Lending: Compound

Advantages of Compound
• Levered positions are possible too
• Suppose you are bearish on price of ETH

• Deposit stablecoin like USDC or DAI
• Borrow ETH
• Sell ETH for stablecoin
• Deposit additional stablecoin from your sale
• Borrow more ETH
• Sell additional ETH for stablecoin
• If price of ETH falls, you can use your stablecoin to buy (cheap) ETH to pay 

off debt Campbell R. Harvey 2021 49



Credit/Lending: Compound

cTokens
• The Compound protocol must escrow tokens as a depositor in order 

to maintain that liquidity for the platform itself and to keep track of 
each person’s ownership stake in each market. 

• A naive approach would be to keep track of the number inside a 
contract. 

• A better approach would be to tokenize the user's share. 
• Compound does this using a cToken, and this is one of the platform’s 

important innovations.
Campbell R. Harvey 2021 50



Credit/Lending: Compound

cTokens are minted and burned
• Compound’s cToken is an ERC-20 in its own right that represents an 

ownership stake in the underlying Compound market. 
• For example, cDAI corresponds to the Compound DAI market and 

cETH corresponds to the Compound ETH market. 
• Both tokens are minted and burned in proportion to the funds 

added and removed from the underlying market as a means to track 
the amount belonging to a specific investor.

Campbell R. Harvey 2021 51



Credit/Lending: Compound

cTokens can be traded
• Given interest payments continually accrue to suppliers, these 

tokens are always worth more than the underlying asset. 
• cTokens can be traded on their own like a normal ERC-20 asset. 
• Other protocols can seamlessly integrate with Compound simply by 

holding cTokens and allows users to deploy their cTokens directly 
into other opportunities, such as using a cToken as collateral for a 
MakerDAO Vault. 

• Instead of using ETH only as collateral, an investor can use cETH and 
earn lending interest on the ETH collateral.Campbell R. Harvey 2021 52



Credit/Lending: Compound

Example
• Assume there are 2,000 DAI in the Compound DAI market and a 

total 500 cDAI represents the ownership in the market; this ratio of 
cDAI to DAI is not determinative and could just as easily be 500,000 
cDAI. 

Campbell R. Harvey 2021 53



Credit/Lending: Compound

Example
• If a trader comes in and deposits 1,000 DAI, the supply increases by 

50% (and Compound mints 50% or 250 cDAI)

Campbell R. Harvey 2021 54



Credit/Lending: Compound

Example
• Currently, 1 cDAI = 4 DAI, but after interest accrues the ratio will change. Let 

interest = 10%, at year end, 3,300 DAI. Trader redeems 250 cDAI for 1,100 DAI

Campbell R. Harvey 2021 55



Credit/Lending: Compound

Example
• Note that the trader can deploy cDAI in the place of DAI so the DAI is 

not sitting idle but earning interest via the Compound pool. 
• For example, the trader could deploy cDAI as the necessary 

collateral to open a perpetual futures position on dYdX or she could 
market make on Uniswap using a cDAI trading pair (discussed later). 

Campbell R. Harvey 2021 56



Credit/Lending: Compound

Governance parameters
• The many different parameters of Compound’s functionality, such as 

the collateral factor, reserve factor, base rate, slope, and kink, can all 
be tuned. 

• The entity capable of tuning these parameters is Compound 
Governance. 

• Compound Governance has the power to change parameters, add 
new markets, freeze the ability to initiate new deposits or borrows 
in a market, and even upgrade some of the contract code itself.

Campbell R. Harvey 2021 57



Credit/Lending: Compound

Governance 
• Importantly, Compound Governance cannot steal funds or prevent 

users from withdrawing. 
• In the early stages of Compound's growth, governance was 

controlled by developer admins, similar to any tech startup. 
• Technically, this meant that the first version of Compound was not 

fully decentralized

Campbell R. Harvey 2021 58



Credit/Lending: Compound

Governance parameters
• A strong development goal of Compound, as with most DeFi

protocols, was to remove developer admin access and release the 
protocol to the leadership of a DAO via a governance token. 

• The token allowed shareholders and community members to 
collectively become Compound Governance and propose upgrades 
or parameter tuning. 

• A quorum agreement is required for any change to be implemented.
• The quorum rule is a majority of users each of whom holds with a 

minimum of 400,000 COMP (~4% of total eventual supply)Campbell R. Harvey 2021 59



Credit/Lending: Compound

COMP token
• Compound implemented this new governance system in May 2020 

via the COMP token. 
• COMP is used to vote on protocol updates such as parameter 

tuning, adding new asset support, and functionality upgrades 
(similar to MKR for MakerDAO). 

• On June 15, 2020, the 7th governance proposal passed which 
provided for distributing COMP tokens to users of the platform 
based on the borrow volume per market. 

Campbell R. Harvey 2021 60

https://compound.finance/governance/proposals/7


Credit/Lending: Compound

COMP token
• The proposal offered an experience akin to a tech company giving its 

own stock to its users. 
• The COMP token is distributed to both suppliers and borrowers, and 

acts as a subsidization of rates. 

Campbell R. Harvey 2021 61



Credit/Lending: Compound

COMP token
• With the release of the token on public markets, COMP’s market cap 

spiked to over $2 billion. 
• The price point of the distribution rate is so high that borrowing in 

most markets turned out to be profitable. 
• This arbitrage opportunity attracted considerable volume to the 

platform, and the community governance has made and passed 
several proposals to help manage the usage.

Campbell R. Harvey 2021 62



Credit/Lending: Compound

Other platforms use Compound
• The Compound protocol can no longer be turned off and will exist 

on Ethereum as long as Ethereum exists. 
• Other platforms can easily escrow funds in Compound to provide 

additional value to their users or enable novel business models. 
• Easy, instant access to yield or borrow liquidity on different 

Ethereum tokens makes Compound an important platform in DeFi.

Campbell R. Harvey 2021 63



Credit/Lending: Compound

Fair lotteries
• PoolTogether is a no-loss lottery that deposits all user's funds into 

Compound, but pays the entire pool’s earned interest to a single 
random depositor at fixed intervals. 

• In most lotteries, 30-50% of the lottery sales are tagged for 
administrative costs and government or charitable use; hence, the 
expected value of investing $1.00 in a lottery is $0.50-$0.70. 

• In a no-loss lottery, all sales are paid out and the expected value is 
$1.00. 

Campbell R. Harvey 2021 64

https://www.pooltogether.com/


Credit/Lending: Compound

Campbell R. Harvey 2021 65

Traditional Finance Problem Compound Solution 

Centralized Control: Borrowing and lending 
rates are controlled by institutions. 

Compound rates are determined 
algorithmically and gives control of market 
parameters to COMP stakeholders 
incentivized to provide value to users. 

Limited Access: Difficulty in accessing high-
yield USD investment opportunities or 
competitive borrowing. 

Open ability to borrow or lend any supported 
assets at competitive algorithmically 
determined rates (temporarily subsidized by 
COMP distribution). 

Inefficiency: Suboptimal rates for borrowing 
and lending due to inflated costs. 

Algorithmically pooled and optimized interest 
rates. 

Lack of Interoperability: Cannot repurpose 
supplied positions for other investment 
opportunities. 

Tokenized positions via cTokens can be used 
to turn static assets into yield-generating 
assets. 

Opacity: Unclear collateralization of lending 
institutions. 

Transparent collateralization ratios of 
borrowers visible to entire ecosystem. 

 



Credit/Lending: Aave

What is Aave?
• Aave, launched in 2017, is a lending protocol similar to Compound.
• More tokens to supply and borrow are offered
• Importantly, the Aave lending and variable borrowing rates are more 

predictable, because unlike the volatile COMP token in Compound, 
no subsidy is involved.

Campbell R. Harvey 2021 66



Credit/Lending: Aave

Two markets
• The first is for more-conventional ERC-20 tokens similar to those of 

Compound, supporting assets such as ETH, USDC, and DAI. 
• The second is specific to Uniswap UNI LP tokens (discussed later). 
• For example, when a user deposits collateral into a Uniswap market, 

she receives an LP token as a Liquidity Provider that represents her 
ownership in the market. 

• The LP tokens can be deposited in the Uniswap market on Aave to 
generate additional returns.

Campbell R. Harvey 2021 67



Credit/Lending: Aave

Flash loans
• Aave charges a fee of 9 basis points (bps) on the loan amount to 

execute a flash loan. 
• The fee is paid to the asset pool and provides an additional return 

on investment to suppliers, because they each own a pro rata share 
of the pool. 

• An important use case for flash loans is that they allow users quick 
access to capital as a means to refinance positions. 

Campbell R. Harvey 2021 68



Credit/Lending: Aave

Example
• Assume the price of ETH is 200 DAI. 
• A user supplies 100 ETH in Compound and borrows 10,000 DAI to 

lever up and purchase an additional 50 ETH, which the user also 
supplies to Compound. 

• Suppose the borrow interest rate in DAI on Compound is 15% on 
Aave is 5%. 

• The goal is to refinance the borrowing to take advantage of the 
lower rate offered on Aave, which is analogous to refinancing a 
mortgage, a long and costly process in centralized finance.Campbell R. Harvey 2021 69



Credit/Lending: Aave

Example
• One option is to manually unwind each trade on Compound and re-

do both trades on Aave to reconstruct the levered position, but this 
option is wasteful in terms of exchange fees and gas fees.

• A flash loan provides an attractive alternative 

Campbell R. Harvey 2021 70



Credit/Lending: Aave

Example
• Take out a flash loan from Aave for 10,000 DAI, 
• Use it to pay the debt on Compound, 
• Withdraw the full 150 ETH from Compound 
• Resupply to Aave, and (at 5% APR) against that collateral to repay 

the flash loan. 
• The latter approach effectively skips the steps of exchanging ETH for 

DAI to unwind and rewind the leverage.

Campbell R. Harvey 2021 71



Credit/Lending: Aave

Example
• The flash loan is a single 

transaction
• A flash loan used to 

refinance a position allows 
for DeFi client applications 
that let users migrate a 
levered position from one 
dApp to another with the 
single push of a button.

72



Credit/Lending: Aave

Stable loan rate
• An Aave innovation (and as of this writing only available on Aave) is 

a “stable” rate loan. 
• The choice of “stable” intentionally avoids the use of “fixed rate.” 
• A borrower has the option to switch between the variable rate and 

the current stable rate. 

Campbell R. Harvey 2021 73



Credit/Lending: Aave

Supply rate is not stable
• The supply rate is always variable, because under certain 

circumstances, such as if all borrowers left the market, it would be 
impossible to fund a fixed supply rate. 

• The suppliers always collectively earn the sum of the stable and 
variable borrow interest payments minus any fees to the platform.

Campbell R. Harvey 2021 74



Credit/Lending: Aave

Stable rate is not a fixed rate
• The stable rate is not a fixed rate, because the rate is adjustable in 

extreme liquidity crunches and can be refinanced to a lower rate if 
market conditions allow. 

• Also, some constraints exist around how much liquidity can be 
removed at a specific stable rate. 

• Algorithmic stable borrowing rates provide value to risk-averse 
investors who wish to take on leverage without the uncertainty of a 
variable-rate position.

Campbell R. Harvey 2021 75



Credit/Lending: Aave

Credit delegation
• Aave is developing a Credit Delegation feature in which users can 

allocate collateral to potential borrowers who can use it to borrow a 
desired asset. 

• The process is unsecured and relies on trust. 
• This process allows for";"""date"",""2021-03-08T21:19:38Z""
""pdf:PDFVersion"",""1.5""
""xmp:CreatorTool"",""Acrobat PDFMaker 11 for PowerPoint""
""pdf:docinfo:title"",""Rethinking Performance Evaluation""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""Acrobat PDFMaker 11 for PowerPoint""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""Rethinking Performance Evaluation""
""xmp:CreateDate"",""2021-03-08T16:19:14Z""
""modified"",""2021-03-08T21:19:38Z""
""pdf:hasMarkedContent"",""true""
""xmp:ModifyDate"",""2021-03-08T16:19:38Z""
""pdf:docinfo:creator"",""cam.harvey@duke.edu""
""meta:author"",""cam.harvey@duke.edu""
""meta:creation-date"",""2021-03-08T21:19:14Z""
""created"",""2021-03-08T21:19:14Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2021-03-08T21:19:14Z""
""resourceName"",""DeFi_2021_5_Deep_697.pdf""
""Author"",""cam.harvey@duke.edu""
""producer"",""Adobe PDF Library 11.0""
""pdf:docinfo:producer"",""Adobe PDF Library 11.0""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""access_permission:modify_annotations"",""true""
""dc:creator"",""cam.harvey@duke.edu""
""dcterms:created"",""2021-03-08T21:19:14Z""
""Last-Modified"",""2021-03-08T21:19:38Z""
""dcterms:modified"",""2021-03-08T21:19:38Z""
""title"",""Rethinking Performance Evaluation""
""xmpMM:DocumentID"",""uuid:1757beaa-7cb7-4093-b7c2-290188220181""
""Last-Save-Date"",""2021-03-08T21:19:38Z""
""pdf:docinfo:modified"",""2021-03-08T21:19:38Z""
""meta:save-date"",""2021-03-08T21:19:38Z""
""Content-Length"",""2931328""
""Content-Type"",""application/pdf""
""xmp:MetadataDate"",""2021-03-08T16:19:38Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""cam.harvey@duke.edu""
""dc:language"",""EN-US""
""pdf:producer"",""Adobe PDF Library 11.0""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""210""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""88"",""180"",""582"",""440"",""463"",""506"",""268"",""510"",""491"",""49"",""238"",""232"",""494"",""275"",""269"",""471"",""325"",""335"",""342"",""407"",""468"",""466"",""569"",""533"",""320"",""424"",""592"",""1072"",""314"",""532"",""438"",""524"",""616"",""295"",""417"",""49"",""501"",""377"",""369"",""627"",""404"",""345"",""238"",""374"",""337"",""259"",""370"",""397"",""464"",""471"",""579"",""259"",""166"",""213"",""381"",""486"",""354"",""575"",""452"",""255"",""434"",""434"",""506"",""1042"",""326"",""502"",""415"",""499"",""291"",""371"",""245"",""315"",""369"",""495"",""524"",""525"",""357"",""379"",""421"",""882"",""534"",""368"",""236"",""245"",""295"",""243"",""537"",""511"",""541"",""352"",""500"",""458"",""473"",""504"",""435"",""496"",""522"",""260"",""557"",""538"",""470"",""414"",""310"",""564"",""133"",""316"",""509"",""93"",""519"",""1102"",""503"",""521"",""309"",""308"",""571"",""442"",""569"",""346"",""416"",""621"",""523"",""457"",""422"",""448"",""424"",""487"",""479"",""516"",""100"",""131"",""129"",""362"",""450"",""547"",""301"",""642"",""416"",""1090"",""306"",""479"",""361"",""336"",""356"",""277"",""591"",""441"",""341"",""369"",""43"",""352"",""453"",""306"",""471"",""524"",""418"",""567"",""293"",""329"",""376"",""371"",""488"",""375"",""433"",""386"",""401"",""366"",""427"",""442"",""80"",""90"",""92"",""337"",""1247"",""441"",""433"",""254"",""389"",""521"",""488"",""589"",""292"",""351"",""199"",""474"",""495"",""455"",""776"",""74"",""116"",""487"",""513"",""420"",""335"",""438"",""448"",""403"",""502"",""427"",""370"",""471"",""1083"",""503"",""497"",""371"",""447"",""552"",""302"",""452"",""205"",""205""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2021-03-08T21:19:14Z""
";
1619098725-14;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Smart grid data access control scheme based on blockchain;L Zhang, J Li, F Hu, Y Huang… ; Computational …, 2020  Wiley Online Library;;"… verifies the user's data access request, the database will accept the user's request for data if the

verification is passed, and that will be broadcasted on the entire network and uploaded to the

blockchain. The security of the scheme is analyzed by using a random oracle model …";Cité 1 fois;;null;;;;https://scholar.google.ch/scholar?start=560&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098804-191;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;[PDF][PDF] Time, Consensus and Governance by Design for Blockchain and DLT;S Caporali ;2020 dapp.orvium.io;;"… This authors give the example of a software package that manages invoicing, which needs to

read information or ask questions in the blockchain via an oracle. However, there is no natural

synchronization between the internal time in the blockchain and the external time …";Autres articles;Version HTML;[PDF] orvium.io;https://dapp.orvium.io/api/v1/deposits/5fd4a2b1961bb60008101a0c/files/Time,%20Consensus%20and%20Governance%20by%20Design%20for%20Blockchain%20and%20DLT.pdf;"
Time, Consensus and Governance by Design for

Blockchain and DLT

Stéphane Caporali,
Caporali Conseil

December 24, 2020

Abstract

For blockchain governance, data is an asset, and the time parameter
is strategic and sensitive. This document aims to explore this issue for
blockchain. It analyses the issues related to two properties associated
with the parameter time : the ability to measure time (timestamp), and
the guarantee of the ordering between events and proposes an innovative
approach promoting blockchain technology as an infinite state machine.
It is illustrated by the concept of simultaneous states to take into account
uncertainty as a transition between two states. After recalling the mech-
anisms of the consensus algorithm in the case of the PoW, and analyzing
the associated issues, this document proposes two data governance func-
tions that can be derived from the notion of time between two blocks :
the alert, and the control loop. This paper proposes the abstract concept
of temporal structure, understood as the four functions derived from time
parameter in support of the data governance strategy for blockchain in an
industrial context, and governance by design the resulting approach.

Keywords— Time, blockchain, consensus algorithm, state machine, governance.

1 Introduction

The starting point for the creation of this document has been, since the introduction
of the proof of work (PoW) in the Satoshi Nakamoto’s founding document [1], the
observation of the plurality of different consensus mechanisms in blockchain. There is
a risk of fragmentation due to the absence of a technical framework that unifies the
whole. Little by little, the idea was born that a level of governance : a governance
of the consensus mechanism, is able to bring together all the blockchains despite the
differences in the consensus mechanisms. The idea is therefore not that a governance
of the consensus mechanism can exist, but that this governance must exist because
we need it. In the implementation phase of a blockchain project, a classification of
algorithms is a tool that can help support governance. In termination phase, there
might be a strategy to terminate a blockchain project, for example the creation of a
fork. In the operational phase, finding an approach to governance of the consensus
mechanisms is not easy, but something has to be found. This document is an attempt
to answer to these questions and make the subject grow in maturity.

1



2 Time and governance by data

The governance principles must improve the use of data in a more efficient way, for
the different operations involved in a system. The operation requires the coordination
of the different participating ecosystems in a distributed approach. Time parameter
is a sensitive and strategic data. Specifics methods and concepts must be organized
around this parameter in order to allow a good governance.

3 Function of timestamp

The representation of time is standardized by ISO (2019)[2] where time is defined as a
mark attributed to an instant or a time interval. By extension, associating a measure to
a mark does not seem to pose a problem. However, in distributed environment, without
a center, problems arise such as for example the choice of the position of the clock. On
this subject, Ladleif and Weske (2020) [3] explain that an industrial process needs to
dialogue with the blockchain. This authors give the example of a software package that
manages invoicing, which needs to read information or ask questions in the blockchain
via an oracle. However, there is no natural synchronization between the internal time
in the blockchain and the external time. A service that updates a distributed ledger
using data from outside of the distributed ledger system called oracle [4] is necessary
to allow the transition between off-ledger and on-ledger requests because, according
to the authors, blockchain is a closed-world environment without access to global
timing information. Thus the measure of time poses important questions described in
the document of Jan Ladleif and Mathias Weske beyond the scope of this document
and especially the absence of a natural notion of measuring time. However, time
measurement is a function associated with time.

4 Function of trust

4.1 Two abstracts point of view of time

Lamport (1978) [5] writes that there are two points of view of time, and gives the ex-
ample of special relativity where we use a space-time diagram with coordinate diagram
where the position of time t is located on the y-axis rather than on the x-axis. This
point of view allows to consider the parameter t as a simple label for an event. This
suggests that there may be different abstract views of time. As an illustration, imagine
that Event is the value associated with an event: for example a consensus has been
made and that a value that we call Event is associated with this consensus. Figure 1

Event

time

Figure 1: Case F (time) = Event

is the usual representation where a measure of the event is under the prerequisite of

2



time

Event

Figure 2: Case F (Event) = time

the measure of time. In reverse, in figure 2, t is located on the y-axis rather than on
the x-axis. In this second point of view, the measure of the chronology is just a label
in the properties of the event.

4.2 Blockchain participants as an ecosystem of partici-
pants in finite numbers, with an infinity of possible
transactions

Characteristics of a participant In this document, we are interested in blockchain
participants. For example a miner is a blockchain participant. The participants are
not only constituted by the miners but others entities participating in blockchain oper-
ations. A participant can be a machine with computational capabilities : for example
a smart contract or a script, but it is not necessary and it can be a human being. The
question of knowing which entities constitute the participants is open in this document,
in particular that can concern on-ledger but also off-ledger entities.

Choice of participants in the blockchain rather than the blockchain
as a system for modeling the state machine

Strategic importance of the community of participants Shorish (2018)
[6] asks the question of what we mean by strategic in a blockchain, and considers by
strategic the consideration by blockchain participants of the actions of other partic-
ipants. A blockchain is a decentralized ledger, constituted of different parts : a de-
centralized network, a consensus algorithm, the cryptographic tools especially for the
chain structure. For this reason, blockchain technology is the combination of different
techniques. For specific functions, describe later in this document, the participants
could in addition be described as a state machine. This means that if a participant
is a computer which is a turing machine, it could be associated with both an infinite
state machine for the same computer system. Blockchain can be seen as the commu-
nity of participants, with the participants being responsible for the operation of the
blockchain and associated with the role of the governance or simply users. Behind one
participant there is an entity : for example a system, a process, a device or a human.
This link between the participants is a form of trust. However, a technical prerequisite
is that participants are entities synchronized with the same ”clock”, as mentioned in
section 3.

An event-centric approach Faced with the problem of the infinity of pos-
sibles values in the time scale, an idea is to introduce a number of agents which is
finite : the description of the system will focus on the interactions between agents at a
precise moment. The future and the past are in this case projections from the present.

3



This is just an approach to how things can be implemented. The interactions between
agents are in theory in number infinite but finite in a practical way. This approach
conforms to the second case of section 4.1.

4.3 Presentation of the computational model of the infi-
nite state machine

General characteristics of a state machine By computation I mean the act
or process of calculating an answer or amount by using a machine [7]. By consequent
it is not necessary an amount, it can be an answer. The theory of computation is the
basis of computing theory. A state machine is a model of computation, characterized
by the fact that a state is modified by an event. For example, an elevator, where
pressing the button of a given floor starts moving the elevator to that floor.A state
machine, in its simplest form, is without memory (memoryless) : the last event (for
example the previous movement of the elevator) is not stored : it is not not because
the precedent user wanted to go to the second floor, that the next user has more chance
of choosing the second floor, in principle. Keeping the previous operation in memory
is useless. The state machine is reactive to the event.

Association between blockchain and state machine : a counter-intuitive
choice ? The association of blockchain with the state machine seems a paradox, be-
cause computational model of the state machine is memoryless, but on the contrary
blockchain has the property of immutability that ISO (2020) [8] indicates as the prop-
erty wherein ledger records cannot be modified or removed once added. However,
blockchain is, in a way, in its description, in accordance with the fundamental proper-
ties of the state machine. Blockchain is often described as a particular database, with
a write mode, or a read mode but not a modify mode : once written in the chain, a
value cannot be deleted. Blockchain is a particular, distributed register, in the sense
of accounting where an accounting register is used. However, at least in the case of the
proof of work, described later in the document, blockchain is, as the state machine,
memoryless : the fact for a minor to be the entity that won the previous challenge
does not give more chance to be the next winner [9].

Application to blockchain Brooks (2017) [10] in his blog considers blockchains
to be, fundamentally, systems for managing valid state transitions. Petri net is a mode
of representation well adapted to distributed environment in the case of discrete events
system. These are are the following notation used with Petri net :

• circle is related to an event.

• rectangle is related to a state.

state
t+ ∆tstate t Transition

Figure 3: The state machine computational model can be associated with each
blockchain participant

An event represents a certain situation occurring at a given point in time. Note that
in the context of industrial control system, an event is defined as a change of state or
value detected for processing and/or reporting [11].

4



4.4 The muti-state machine

Problem of uncertainty in the time interval between two blocks It is
called a multi-state machine, a state machine whose records can be in multiple states
at the same time, which seems contradictory to the work of a deterministic state
machine. However we can adopt this representation as an abstract model. We assume
at this stage that the time interval between two blocks is constant. For example, 10
minutes for bitcoin. Shorish (2018) [6] explains that if a state machine representation
is possible, it must handle the associated uncertainty. The uncertainty could be related
to the difficulty of predicting an accurate value of the time interval between two blocks
but we agree that we consider the value constant at this stage of the document even
though we will go further in paragraph 5 about this question. But even with a precise
value, we can consider that the transition is characterized by its inherent uncertainty
: in fact the transition is the not yet something and already not something else. To
illustrate this fact, I propose that a state machine can have two states at the same
time. The originality is that we assume that these states are contradictory : it is only
a representation to illustrate the state of incertitude.

Representation of the uncertainty The state/event table, the state diagram,
and usual mathematical models used with state machine representation are adapted to
finite state machine. In the case of an infinite state machine, form of representations
are to be developed. We can however explain what could represent the state of the
machine. One event is no more, and another is not yet : We will say that the previous
event is no more and that the next event is not yet at the same time: these is a state
of uncertainty . A state is only a transition between two events. This conception that
highlights the event is in agreement with the second view of time presented in figure
2. There are two options for representing a state :

• First option : two separate events at the same time

• Second option : one event with two values at the same time

4.5 The ordering between events

Definition ISO (2019) [2] defines that a unit of time is the time interval part of
the time axis limited by two instants. The ability to generate a unit of time can be
described by the function :

f(t) =

{
t+ 1 if t > 0

0 if t = 0

as a minimal recursive function.

Comparison between blockchain and clock ISO (2019) [2] specifies that a
clock is a time scale suited for intra-day time measurements. Trubetskoy (2018) [9] in
his blog develops the idea of a blockchain comparable to a clock, which is imprecise
but generates trust, and in a way plays a role in the community of participants because
it generates trust. The author uses the word universal clock, and compares the state
of the chain to the ticks of a clock. This analogy with a tick suggests that a clock
prints a rhythm, before the measurement of the time parameter. Pérez-Marco (2018)
[12] expresses the same idea, that of a universal clock, which has the property of being
untamperable and unfalsifiable. He also uses the term tick and identifies the timing
of the tick when a new block is validated, which in this case could be compared to
the event that precedes a new state. This makes it possible to see more clearly in
the modeling of the state machine, and the differentiation between the event (the
consensus) and the state (a new unit of time, a new tick) Swann (2015) [13] compares

5



the time between two blocks to a feature. This point is important, because the arises
of knowing how to define the time between two blocks, is it a property, a function ?
The author explains that the time between two blocks is a privilege function in order
to specify a model based on event conditions and states change. This approach is in
accordance with the approach developed in this document.

Duality discrete/continuous time In another work, Swann (2016) develops
the idea that time can be both discrete and continuous [14]. First of all, in this
document we consider time not as a phenomenon, but as a parameter, because the
objective is to describe a digital system. A machine does not perceive time in the sense
that it has a sense of time, that of a flow. However a machine considers the parameter
t as a mark on a scale. Despite this, the parameter time can thus be differentiated
from two points of view, depending on whether a given event is considered in a flow
of time, or whether the measurement is associated with the event. The second case is
linked to the discrete conception of time, that is to say to case number two described
in section 4.1.It has an affinity with the model of the state machine described in this
document. We note that the conception of a discrete time is not incompatible with
the ISO definition (2019) [2] which states that time is defined as a mark attributed to
an instant or a time interval.

The generation of trust Bonnet, et al. [15] consider that the distributed ledger
is a data structure. This approach is interesting, because it leads to the concept of
data approach, described in the introduction. Data is not just the content of the
transaction. The expression time instant is used to qualify a new unit of time. The
state transition function is described as the result of the current state, the events, and
the network containing all the nodes. This emphasizes the idea that blockchain can
be described from the behavior of all the participants. In summary, blockchain has
the property of a clock. This implies, by extension, the ability to measure time on a
time scale. The problem developed in section 1 consists in the difficulty of developing
a governance of consensus algorithms during the operational phase of a blockchain
project. We will see in the next section how the state machine model can be the
basis for the development of a technical and terminological framework that supports
governance functions of alert and control.

5 Function of alert

5.1 The infinite probabilistic state machine

The introduction of the consensus The last section provides a first level of
interpretation with the property of ordering between events, illustrated by the model
of the state machine. In his work, Shorish (2018) [6] presents the model of the state
machine for blockchain and reinforces the idea that formalizing the interpretation of
the state machine is a challenge. To go further in this interpretation, we can ask what
is the nature of the event that precedes a new state. This cannot be resumed by the
generation of a unit of time. But what could this formalization be ? The idea in this
section is that the association with state machine (without memory) and blockchain
is not obvious, but in fact the states of a machine could be compared to the unit of
time, and the event (transition) to the consensus.

• circle is related to an event condition. The condition is that the consensus has
been made.

• square is related to a state change

Figure 4 show the case of a state machine that is dedicated to manage the state
transition : the event is constituted by the consensus.

6



state
t+ 1state t Consensus

Figure 4: The consensus is the condition of the event

The probabilist component of the state machine Shorish (2018) [6] con-
siders that a transition function between the states of a blockchain is probabilistic by
nature. This point is important and shows that the process of consensus introduces
a new component into the state machine : its probabilistic component. However, not
all the consensus algorithms are probabilistic by nature. But this property illustrates
a function which is the alert function. To better understand, the following paragraph
recalls the important principles of the proof of work, which is the consensus algorithm
taken as an example in this document.

5.2 The consensus algorithm

Clarifications concerning the notion of consensus With blockchain, the
consensus algorithm is often confused with other forms of validations, as it is a spe-
cific form of the consensus mechanism. For example with smart contracts, there are
verification mechanisms, which involves forms of consensus. To see more clearly, we
can wonder what precisely is the consensus for blockchain technology. ISO (2020) [8]
defines consensus as the agreement between DLT nodes that a transaction is validated
and that the distributed ledger contains a consistent set and ordering of validated
transactions. It is the function of ordering that is discussed in this document through
the example of the proof of work.

The Byzantine Generals’ Problem Nakamoto (2008) [1] in its founding doc-
ument introduces the proof of work (PoW) as a consensus algorithm. To fully under-
stand Proof of work, it is necessary to understand the Byzantine Generals problem.
The problem known as man-in-the-middle attack in network security and theorized
with the Two Generals Problem argues that it has been proved unsolvable theoreti-
cally that a channel between two points can be trusted. A pragmatic approach is to
accept the uncertainty of the communication channel. Generalization with more than
two generals is the Byzantine Generals’ Problem. This is the principle : the Byzantine
army must attack a city at a given time. The generals must communicate to agree
on what time to attack the city, messengers can be intercepted and the message tam-
pered. The problem is how to successfully trust the channel and obtain a consensus
on the precise date when the Byzantine army will attack the city.

The proof of work In the case of proof of work is introduced a nonce which is
a arbitrary number from which if we take the hash of the nonce and the message, we
get a hash that starts with five zeros. You do this by guessing a large number of tries.
This imply to increase the value of the nonce with each attempt. There is no way to
find the nonce efficiency, the only way is to guess (the process is memoryless). This
is what we call proof of work. The hard part is finding the nonce, but to hash the
string is very easy. If the message is tampered and not the nonce, the resulting hash
will not start with five zero. Modifying the message means calculating a new nonce.
A series of messages is combined into a block and a high number of zero associated
with the nonce. If a message is intercepted, it is considered practicably impossible to
find the nonce, since all the computing power of all the Byzantine army represented

7



an important amount of calculation. There might be a traitor in the group of generals
who can give false time attack information. There are a large number of generals. In
the case of proof of work, each general must solve a problem to send the message.
If a general is the traitor, he has a weak probability to solve the messages twice
consecutively. This description is based on the Ivan Liljeqvist youtube channel[16]
which clearly describes the concept. Nakamoto (2008) [17] says in a mail written to
the Cryptography Mailing List that the proof of work is a probabilistic response to the
Byzantine Generals’ Problem. Main innovation brought by the blockchain, the proof
of work makes it possible to validate a transaction in a distributed environment by
solving a cryptographic puzzle. The first of the miners to solve the puzzle wins the
challenge. But it is related both to the hash power and to pure luck. The proof of work
is a major innovation of blockchain because it introduces chance, structurally in the
process of determination of the consensus. Previously, work on consensus algorithms in
a distributed environment trying to solve the Byzantine generals problem was generally
oriented towards a deterministic approach. With proof of work, once the puzzle has
been solved, the block is broadcast in the network and verified in order to validate it.
In case of conflict, the longest chain wins : it is the rule of the longest chain. Many
others forms of consensus are developed, for example proof of stake. But the object
of the consensus algorithm remains to validate the ordering between two transactions.
It is a function of notarization.

5.3 Time between two blocks

Genesis of the time interval between two blocks In its founding document,
Nakamoto (2008) [1] says that ten minutes is the reason of blocktime and that it is
for storage reasons : the author estimates, on the one hand, the quantity of memory
per year needed for the storage of the chain, and the storage capabilities of computer
systems on the other hand, the duration of the block time of 10 minutes being only a
reasonable value according to the constraints related to the storage. We can wonder if
it is no a part of arbitrary reason in the choice of this parameters. It is a compromise
between different things. Nakamoto talks about time between the generation of two
blocks, and not only the time of mining. Another interest is that this time is enough
longer to take time to recreate a chain in the case of a fork. This is particularly true
if the chain is long and this is a protection against a fifty-one percent attack. For
this reason a long chain is more secure. Another choice is made for example by the
blockchain Ethereum. Siriwardena (2017) [18] explains that the primary motivation of
the blockchain Ethereum was to diminish the value of this parameter, in order to make
faster the time between two transactions. It is true that for bitcoin and the proof of
work, the important time of ten minutes slows down the speed of the transaction and
imply scalability issues. When designing a blockchain, there is the choice of the type
of consensus algorithm, and another important part is the choice of the value of a time
between the generation of two blocks. This shows how important this parameter is.

Terminology We may wonder how to name the time between two consecutive
blocks. It is important to emphasize that we find different words for same or simi-
lar meaning.

Blocktime Swann and De Filippi (2017) [19] use the term blocktime and give
the description of blocktime as the time over which a certain number of blocks will
have confirmed and consider it as a notion of time specific to the blockchain.

Block produce time On their side, Zhang and Ma (2020) [20] use the expres-
sion : ”block produce time”.

8



Average Seconds Between Blocks Küfeoğlu Özkuran (2019 [21] differen-
tiate according to the unity of time used and used the terms Average Seconds Between
Blocks (ASBB) and Average Hours Between Blocks (AHBB).

Mining time Siriwardena (2017) [18] uses the expression block time and says
that block time defines the time it takes to mine a block. Consequently, the meaning
is that of mining time.

Block time Ladleif and Weske (2020) [3] specify that the time between two
blocks and mining time are two different things and use the word block time for the
time between two blocks. The authors integrate into the time interval between two
blocks a delay between the initial creation of the transaction and the work of mining
through the interesting analysis of the timeline along the blockchain-based execution
of a business process.

Expected and average block time Siriwardena (2017) [18] says that there
is an expected block time, and an average block time. The differences between the two
concepts is important. The expected block time is the value of block time in theory,
for a given blockchain, for example ten minutes for bitcoin. The average block time,
according to the author, is what we find after a small number of block generated. And
this is different.

Cycle time Cycle time is the standardized definition given by ISO (2004) [11]
to the time associated with one complete operation of a repetitive process but in the
context of industrial control systems. The choice in this document is to use the term
cycle time as far as possible to express the interval of time between two consecutive
blocks because the terminology is not yet stabilized.

5.4 Interest of the historical chart

Chosen approach To better understand the value of analyzing the time between
two blocks, it is possible to consult the historical graph of the variation of the cycle
time over time. We find on the internet the possibility of seeing the mining time [22]
and in another site the block time [23], which corresponds to the time between two
blocks that it is called in this document cycle time. Both can have their interest, it is
chosen to show the second to fully understand the problem associated with figure 5

Difficulty of interpretation Blocktime corresponds here to what we call cycle
time. However, the value is that of the average block time. We see that there is a peak
during the fall of 2018 of 14 minutes followed at the same period by an unusually low
value of 8 minutes. How to interpret this? Chance is partly responsible of theses small
variations on time scale because we have seen that the proof of work is a probabilistic
process. However, on larger time scale, there are significant variations linked to other
phenomena. Cycle time can be used as a summary parameter in the operation of
supervision or management of the blockchain, and this is an idea of this document.

An investigation from the symptoms As we see with the history, the varia-
tions of block time are not easy to interpret but it is a symptom that something has
happened. The idea is to accept that while expected block time is useful in designing
a clock, the average value of the block time gives us an indication that something has
happened. It could be an alert parameter, comparable to a symptom, which calls for
additional investigations. Beyond that, additional work is needed to analyze in more
depth how to exploit this parameter.

9



Figure 5: Bitcoin Cycle Time historical chart

6 Function of control

6.1 Blocktime and difficulty parameter

In the previous paragraph, we show the behavior of the variation of the cycle time
over time. However, the question arises whether it is possible to have control over
this parameter ? Contrary to what one might think, the difficulty in solving the
cryptographic puzzle (find the nonce) is not constant, due to the increased performance
of the specialized integrated circuit (Asic) used by the minor to calculate, and the
mathematical property of the algorithm. There is a mathematical relationship between
difficulty D, the hash rate, and the time between two blocks. The hash rate is the unit
of the processing power of the minor’s hardware, in other words the computational
speed expressed in hash/second, and depends on the hardware device used. Zhang and
Ma (2020) [20] propose a formulation which takes into account the delay of propagation
:

τk =
Dk

hk
+ tpk =

Dk

Hk

with :

• the block produce time Tk

• the expected block produce time τk

• Dk is the block difficulty

• hk is the actual real-time network hash rate

• tk is the overall delay which includes the propagation delay among peers and
the delay for peers to verify the block

The authors propose the nominal hash rate Hk, which offers more convenience for
analysis. This formula expresses the mathematical relationship that maintains the
block time constant. Küfeoğlu and Özkuran (2019) [21] study the issue of the hash
rate readjustment delay and estimate the need to update the difficulty at 14 days.
Now that we understand the mechanism, the question arises whether this behavior
can be described within a larger theoretical framework.

6.2 Control loop and blockchain

Notion of control loop In many industrial applications, it is necessary to main-
tain physical measurements despite the disturbances that can influence theses mea-
surements. We design systems where the output is aligned whatever the environment.
To propose an approach from the field of control theory, we illustrate by the example
of a feedback control loop, whose principle is to regulate the variation of an output
signal by a readjustment of the input signal according to the variations of the output
signal.

1. The observation is related to the measure to control.

10



2. The reflection determine the difference between the measure we observe and
what we want.

3. Function of the difference, an action is to be taken

Reflection Action System

Observation

What we desire Measure to control

−

What we really measure

Figure 6: Functional structure of a control loop

Adaptation to the case of PoW If we adapt to the case of blockchain, this
gives the result of figure 7. ∆t in input corresponds to the expected time between
two block and δt is the variation of this difference. However, in a practical terms, a
corrective action by adjusting the difficulty D is required almost 15 days, and not at
each time a new block is created.

Difficulty D Consensus

Participants

Average block time value

∆t = cycle time

−

∆t+ δt

Figure 7: The adjustment of the difficulty allows to keep constant the time
interval between two blocks.

Adaptation to others types of consensus The main idea is that something
(the input) must remain constant. This is not necessary ∆t and the idea of the
adjustment parameter D as a parameter necessarily intrinsic to the protocol can be
discussed. An adaption to others forms of consensus algorithms must be made from
the foundations of the model.

Governance by design The control loop is a general principle that can give
birth to new research ideas in order to develop the field of control system with the
integration of the blockchain case, and vice versa. We must not forget that blockchain
is a technology that must allow high-level mechanisms of self-governance. As we say
that blockchain is secure by design, we can say that blockchain is (or should be)
governable by design : it is by building on the properties of the protocol that control
mechanisms could be put in place.

11



7 Industrial requirements and possibles actions

In the blockchain li";"""date"",""2020-12-24T14:25:40Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2020-12-24T14:25:40Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.21 (TeX Live 2020) kpathsea version 6.3.2""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2020-12-24T14:25:40Z""
""created"",""2020-12-24T14:25:40Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-12-24T14:25:40Z""
""resourceName"",""Time,%20Consensus%20and%20Governance%20by%20Design%20for%20Blockchain%20and%20DLT.pdf""
""Author"",""""
""producer"",""pdfTeX-1.40.21""
""pdf:docinfo:producer"",""pdfTeX-1.40.21""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""1"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2020-12-24T14:25:40Z""
""Last-Modified"",""2020-12-24T14:25:40Z""
""dcterms:modified"",""2020-12-24T14:25:40Z""
""title"",""""
""Last-Save-Date"",""2020-12-24T14:25:40Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2020-12-24T14:25:40Z""
""meta:save-date"",""2020-12-24T14:25:40Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.21 (TeX Live 2020) kpathsea version 6.3.2""
""Content-Length"",""312158""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""14""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""2070"",""2136"",""2244"",""2470"",""2871"",""2992"",""2763"",""3144"",""2821"",""1920"",""1418"",""2453"",""2250"",""286""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-12-24T14:25:40Z""
";https://scholar.google.ch/scholar?start=740&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098884-371;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Cryptocurrencies asset pricing via machine learning;Q Wang ; 2020 IEEE 7th International Conference on Data …, 2020  ieeexplore.ieee.org;;"… The blockchain builds on the algorithms of crypto, revealing a … 0.572 Lasso+H R2 0.666 0.449

0.236 0.572 Ridge R2 0.526 0.456 0.26 0.55 Ridge+H R2 0.526 0.456 0.26 0.55 Enet R2 0.666

0.449 0.236 0.571 Enet+H R2 0.666 0.449 0.236 0.571 Oracle R2 0.699 …";Autres articles;;null;;;;https://scholar.google.ch/scholar?start=920&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098879-363;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;A fair selection protocol for committee-based permissionless blockchains;Y Liu, J Liu, Z Zhang, H Yu ; Computers & Security, 2020  Elsevier;;"… In each time step, any node can only make at most one query to the oracle H . As for the verification

oracle H . ver , the number of queries is unbounded … In this section, we first give the basic operations

of a committee-based permissionless blockchain consensus protocol …";Cité 6 fois;Les 2 versions;[PDF] researchgate.net;https://www.researchgate.net/profile/Yizhong_Liu3/publication/338618000_A_Fair_Selection_Protocol_for_Committee-based_Permissionless_Blockchains/links/5f15651892851c1eff218753/A-Fair-Selection-Protocol-for-Committee-based-Permissionless-Blockchains.pdf;;;https://scholar.google.ch/scholar?start=910&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098879-362;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Ligero++: A New Optimized Sublinear IOP;R Bhadauria, Z Fang, C Hazay… ; Proceedings of the …, 2020  dl.acm.org;;"… In each round i, V sends a message ???? and P generates ????. Here the V has oracle access to

{??1,??2,...,???? }. We can express ?? = (??1,??2,...,???? ). Based on the queries from these oracles,

V accepts or rejects. • Completeness: If (??,??)?R then, Pr[(P(??,??), V ?? (??)) = 1] = 1 …";Cité 4 fois;;null;;;;https://scholar.google.ch/scholar?start=910&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098853-301;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Reasons to Be Cheerful: The Benevolent Market Power of Decentralised Blockchains;C Pike, G Carovano ; Available at SSRN 3680600, 2020  papers.ssrn.com;;"… 10 Additional hardware developers, software developers, application developers, exchanges,

oracles, etc. may also strengthen the platform … 11 See Stylianou, K. (2019). What can the first

blockchain antitrust case teach us about the crypto economy, Jolt Digest, available …";;null;null;;;;https://scholar.google.ch/scholar?start=850&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098760-100;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;ACE: Asynchronous and Concurrent Execution of Complex Smart Contracts;K Wüst, S Matetic, S Egli, K Kostiainen… ; Proceedings of the 2020 …, 2020  dl.acm.org;;"… More complex applications, such as decentralized blockchain oracles [28], quickly become

infeasible … Assumptions We consider clients fully untrusted, similar to most permissionless

blockchain systems … If an Ethereum contract receives input from, eg, an oracle or another contract …";Cité 5 fois;Les 3 versions;[PDF] iacr.org;https://eprint.iacr.org/2019/835.pdf;"
ACE: Asynchronous and Concurrent Execution
of Complex Smart Contracts
Karl WĂźst

Department of Computer Science
ETH Zurich

Sinisa Matetic
Department of Computer Science

ETH Zurich

Silvan Egli
Department of Computer Science

ETH Zurich

Kari Kostiainen
Department of Computer Science

ETH Zurich

Srdjan Capkun
Department of Computer Science

ETH Zurich

ABSTRACT

Smart contracts are programmable, decentralized and transparent
financial applications. Because smart contract platforms typically
support Turing-complete programming languages, such systems
are often said to enable arbitrary applications. However, the current
permissionless smart contract systems impose heavy restrictions
on the types of computations that can be implemented. For example,
the globally-replicated and sequential execution model of Ethereum
requires low gas limits that make many computations infeasible.

In this paper, we propose a novel system called ACE whose main
goal is to enable more complex smart contracts on permissionless
blockchains. ACE is based on an off-chain execution model where
the contract issuers appoint a set of service providers to execute the
contract code independent from the consensus layer. The primary
advantage of ACE over previous solutions is that it allows one con-
tract to safely call another contract that is executed by a different
set of service providers. Thus, ACE is the first solution to enable off-
chain execution of interactive smart contracts with flexible trust as-
sumptions. Our evaluation shows thatACE enables several orders of
magnitude more complex smart contracts than standard Ethereum.

1 INTRODUCTION

After Bitcoin [23] became the first permissionless cryptocurrency
and popularized Blockchain technology, Ethereum [31] extended
this concept to smart contracts. Smart contracts are programs that
allow contract participants to load blockchain-based currency to a
contract-controlled account. The contract’s code defines rules and
conditions under which its funds will then be transferred out of
the contract, typically to one of the contract participants.

It is commonly argued that smart contracts provide significant
advantages over traditional financial instruments. One advantage
is their generality: since smart contracts are programmable, they
should enable arbitrary financial applications on blockchains. The
second is improved transparency: smart contract code and execu-
tion is verifiable by anyone from the public blockchain, unlike in
traditional business applications. And the third is strong liveness:
contract execution is not controlled by one or few entities, but
rather by a large permissionless system.

While these properties are indeed an attractive offering for build-
ing novel financial applications, the currently available smart con-
tract systems fail to realize them fully. For example, Ethereum, in
principle, allows arbitrary contracts through a Turing complete
language, but in practice it heavily limits contract complexity. Such
limits are necessary, because Ethereum is based on a sequential and

globally-replicated execution model, where every miner should exe-
cute all contract calls of the latest block before finding the next. Due
to this high degree of replication, the computational complexity of
contracts is inherently limited.

To prevent excessive delays, Ethereum uses a metric called gas

to measure execution complexity. If a contract call surpasses a
specified limit, its execution is aborted which effectively limits the
types of computation that can be implemented. For example, the
simple task of sorting 256 integers with selection sort requires 17M
gas while the current limit for each block is 8M. Quick sort hits
the limit after 2,000 elements. More complex applications, such as
decentralized blockchain oracles [28], quickly become infeasible.

Our main goal is to increase these per-block execution limits
and to enable safe execution of more complex smart contracts for per-
missionless blockchain systems like Ethereum, while maintaining
transparency and good liveness.

Previous work. Because Ethereum’s execution model is both ex-
pensive and slow, recent research has explored alternative ways to
execute contracts on permissionless blockchains.

YODA [10] proposes a randomly-sampled model that supports
asynchronous execution of contract calls. For each contract call, a
subset of miners is chosen randomly to execute the contract code
independently of the mining process and return the results in form
of a new transaction. Arbitrum [17] suggests a model where the
contract creator appoints a small set of verifiers who should check
execution integrity off-chain. Thus, Arbitrum replaces the sequen-
tial and globally-replicated execution model of Ethereum with one
where different contracts can be executed (and thus verified) asyn-
chronously by only few parties who may have an interest in the
contract’s integrity. Ekiden [8] uses Trusted Execution Environ-
ments (TEEs), namely SGX enclaves, to execute smart contracts.
The main motivation of Ekiden is to enable confidential contracts,
rather than complex ones, but since execution is decoupled from
consensus, Ekiden can serve this purpose as well.

To draw an analogy to distributed database systems, in the above
solutions, contract calls are transactions that are executed in sep-
arate partitions, chosen based on random sampling or by appoint-
ment. However, none of the above works addresses safe and con-
current execution of transactions that cross partitions, i.e., cases
where a contract executed in one partition calls a contract managed
by another partition.

Many current Ethereum contracts call other contracts and change
their state. Executing such contracts without concurrency control

can leave the contracts in an inconsistent state, as is well-known
1



from distributed databases [3]. Thus, none of the previous solutions
enable safe execution of many current Ethereum contracts.

Our solution. In this paper, we propose a novel system that we
call ACE (for Asynchronous and Concurrent Execution of Complex

Smart Contracts). ACE combines elements from previous systems
with an efficient concurrency control mechanism and a flexible
trust model. As in YODA, ACE executes contracts asynchronously
off-chain, decoupled from the consensus process. And similar to
Arbitrum, execution is performed by a set of service providers that
are appointed by the contract’s issuer.

Such a model allows execution of complex contracts without
slowing down the consensus process and enables flexible trust as-
sumptions and liveness guarantees. Contract issuers can choose
an appropriate set of service providers for each contract separately
and users are free to choose which service providers they trust for
contract safety and liveness. This execution model allows the use
of a digital currency provided by a permissionless blockchain, with
its transparency and integrity guarantees, while benefiting from
higher efficiency and more flexibility from the off-chain execution.

ACE also has noteworthy differences to previous systems. Un-
like Arbitrum, where service providers must reach unanimous
agreement on the execution results (or the system falls back to
an expensive on-chain verification), we enable more flexible ver-
ification, where execution results are accepted if at least q out of
n service providers report the same result. That is, ACE supports
a trust model where safety is ensured as long as fewer than q of
the appointed service providers are Byzantine faulty. In contrast
to Ekiden, ACE does not require a TEE that is fully trusted for
integrity (compromise of SGX platforms has been shown to be a
relevant threat [6, 7]). And finally, unlike previous solutions, ACE
supports cross-partition transactions (i.e. transactions that involve
contracts handled by different sets of service providers), and thus
enables safe and efficient execution of contracts that interact across
service provider boundaries. The integrity of such cross-partition
transactions is guaranteed even if faulty partitions are involved.

Concurrency control has been studied extensively in the context
of database systems. Classical solutions include two-phase lock-
ing [12] and optimistic concurrency control [20]. Recent research
has proposed deterministic alternatives [30], where transactions are
pre-ordered before execution. The main benefit of such systems is
that they avoid the need for expensive distributed commit proto-
cols that require multiple rounds of communication between the
involved partitions. Our observation is that the deterministic ap-
proach provides a good basis for off-chain smart contract execution
and we tailor this approach for our purpose.

In particular, we augment the typical block structure with sepa-
rate ordering and result sections. When a miner creates a new block,
it pre-orders transactions for execution. Service providers exam-
ine new blocks and if the ordering section contains transactions
with calls to their contracts, they execute them off-chain. Typically,
concurrency control solutions require expensive synchronization
between partitions, like distributed commit protocols. We avoid
this cost by leveraging the pre-assigned order and broadcasting
not yet committed transaction execution results to the peer-to-peer
network. Once a transaction is fully executed, service providers
sign a state-change transaction. Miners accept state changes signed

by at least q service providers and include it in the result section
of one of the next blocks which commits the transaction.

ACE speeds up transaction processing by allowing service providers
to use tentative contract states (previous execution results) that are
not yet part of the chain. A common problem in such systems is
that the same transaction may obtain q signatures for two contra-
dicting results, if different tentative states were used. In ACE, each
execution result includes a reference to the previous contract state
and miners only include results that refer the latest on-chain state.
This ensures that only the correct result is included and allows
flexible trust models where q can safely be less than n/2.

Main results. The primary goal of ACE is to enable more complex
contracts. To evaluate this aspect, we simulated the asynchronous
off-chain execution of ACE and the sequential execution model
(used in Ethereum). Our results show that ACE enables contract
calls that take several orders of magnitude longer to execute (e.g.,
minutes instead of milliseconds) with similar throughput in terms of
transactions per second. Thus,ACE significantly improves the main
advantage of smart contracts, the ability to implement arbitrary
financial applications based on cryptocurrencies.

The other two common advantages of smart contracts are im-
proved transparency and liveness. ACE preserves the transparency,
since contract execution results are publicly recorded on the chain.
Naturally, ACE cannot provide the same liveness guarantees as
Ethereum, since its contracts are executed by a set of pre-named
entities instead of a permissionless network which makes Denial-
of-Service attacks on specific contracts easier. However, ACE still
provides strong and adjustable liveness guarantees, where contract
calls are guaranteed to complete, as long as at least q honest service
providers are available.

Contributions. To summarize, this paper makes the following
contributions:

• ACE system.We propose a novel system called ACE for off-
chain execution of complex smart contracts on permission-
less blockchains. The key features of ACE are its flexible
trust model and safe concurrency control protocol.

• Evaluation.We show thatACE enables several orders of mag-
nitude more complex contract calls compared to Ethereum.

The rest of this paper is organized as follows. Section 2 explains
our problem. Section 3 gives an overview of ACE and Section 4
explains it in detail. Section 5 contains the security analysis and
Section 6 evaluates the performance of ACE. Section 7 provides
discussion and Section 8 concludes the paper.

2 PROBLEM STATEMENT

In this section, we motivate our work, define our main goal and
discuss limitations of previous solutions.

2.1 Motivation and Main Goal

In Ethereum, all contracts are executed sequentially by all miners
that participate in the consensus process. Such a sequential and
globally-replicated execution model, combined with the PoW-based
consensus mechanism, provides execution integrity and strict se-
rializability [24] for transactions. Such a model also ensures the
integrity of the blockchain’s state (that includes the state of all

2



contracts), assuming that the trust assumptions of Ethereum’s con-
sensus mechanism hold. For further background on Ethereum’s
execution and trust model, see Appendix A.1.

Ethereum can ensure transaction execution integrity only when
all (honest) miners re-execute each transaction code to verify the
correctness of the result. This has two main problems. First, it
represents a high cost for the miners in terms of both the power
consumption and time.1 Second, it inherently limits the achievable
throughput of the system and the types of contracts that can be
implemented. To provide good throughput, the block interval must
be kept small, and therefore the execution time of Ethereum con-
tracts is limited. Such time limits have a direct effect on the allowed
computational complexity of contracts.

Currently, the gas limit for each Ethereum block is approximately
8M gas. To put this into perspective, even the simple task of sort-
ing 256 integers using insertion sort requires twice as much. Thus,
although Ethereum is based on a Turing-complete language that in
principle allows the execution of arbitrary smart contracts, the “ar-
bitrary” part is severely limited in practice. For example, contracts
that perform heavy cryptographic operations (e.g., for data feeds
like TLS-N [28]) or use machine learning models are infeasible.

Our main goal in this paper is to provide a solution that allows
safe execution of more complex smart contracts in permissionless
blockchain systems like Ethereum. With “complex” we mean con-
tracts where a single call may take seconds or minutes to complete,
in contrast to Ethereum where calls can take few milliseconds at
most. We argue that this would enable various new types of con-
tracts, such as ones that perform cryptographic operations that are
not natively supported by EVM. We assume that heavier compu-
tations that take hours or days to complete, are rarely needed in
smart contracts.

2.2 Limitations of Previous Solutions

Recent research has explored alternative ways to execute smart
contracts. In this section we summarize the main limitations of
these approaches. Section 7 discusses additional related work.
Alternative execution models. In YODA [10] a subset of consen-
sus participants is randomly sampled to execute and thus verify
each contract call. The main limitation of systems like YODA is
that each smart contract call needs multiple rounds of execution by
separate subsets and the sampled subsets need to be relatively large
(e.g., hundreds of nodes) to reduce the probability of cheating. Such
approaches can reduce the required degree of execution replication
compared to standard Ethereum (e.g., from thousands of nodes to
hundreds), but they still require a great amount of redundancy, a
multi-round execution process, large communication overhead, and
the probability of integrity violation is not negligible. In addition,
systems like YODA require an unbiased and distributed random
beacon. State-of-the-art beacon protocols, like RandHound [29],
require highly expensive initialization routines (that need to be
repeated when new participants join or leave) and significant com-
munication for every periodic random value.

1Miners could spend the same time mining a new block and acquire monetary benefits.
The only direct benefit verification is “the common good"" of the cryptosystem
itself, and therefore miners are often tempted to skip the execution and verification,
accepting the result as given, which is often referred to as “Verifier’s Dilemma” [21].

In Arbitrum [17] the execution of smart contracts is performed
asynchronously off-chain by a set of managers that are appointed
by the contract creator. Execution results are accepted by miners, if
all appointed managers signed the same results. If fewer managers
sign results, the transaction does not immediately get accepted and
a challenge period is entered instead. The signing managers and the
disputing challenger are required to post a deposit and then one of
them proves correctness of his results using a protocol that is log-
arithmic in the length of the execution trace. During the challenge
period the contract cannot make progress. Cross-partition calls are
handled by storing messages on chain that are equivalent to a new
transaction, i.e., call-chains are not executed atomically, serializabil-
ity is not guaranteed, and a long call-chain creates a high latency.

Ekiden [8] provides confidentiality for smart contracts and de-
couples contract execution from the consensus process by executing
contract off-chain in SGX enclaves. While this approach also en-
ables execution of more complex contracts, Ekiden requires that all
enclaves are trusted, since compromising one enclave enables the
adversary violate contract integrity arbitrarily. Recent research has
shown that TEE compromise is a practical threat [5, 6, 13, 15, 22, 33].

Using distributed database terminology, each of the above solu-
tions executes contracts in separate partitions. However, none of the
solutions supports safe cross-partition transactions, i.e., contract
calls from one execution partition to another. Since many Ethereum
contracts make calls that write to another contract, these solutions
therefore cannot execute them safely.

Sharding schemes. Sharding is a common approach to increase
blockchain transaction throughput. One example scheme is called
Chainspace [2] where the backbone infrastructure is divided into
shards (partitions) and every smart contract author can designate a
trusted shard to execute its smart contract, thus parallelizing execu-
tion. However, to maintain integrity across cross-shard executions
all shards need to be honest and have mutual trust.

Omniledger [19] is another sharding scheme that supports cross-
shard transactions. Shards are selected using random sampling,
similar to YODA [10]. This method requires large shard sizes (in the
order of hundreds to thousands) to reduce the probability of cheat-
ing given this random selection. Thus, systems like Omniledger still
have significant redundancy. In addition, Omniledger is designed
for Bitcoin-style transactions and requires modifications to securely
work for a smart contract system.

Transaction splitting. Another method to execute computation-
ally complex contracts on Ethereum is to split the execution up
into multiple transactions. However, splitting up contracts requires
additional mechanisms to keep contract calls atomic, such as adding
locks and timeouts within the contract (and is prone to subtle pro-
gramming errors). Most importantly, splitting up contracts only
works for a few individual cases, not for widespread use of com-
putationally complex contracts. This approach cannot increase the
average execution time per contract, since such contract calls are
still limited by sequential execution.

3 ACE OVERVIEW

In this section, we provide an overview of our solution that is called
ACE. The main goal of ACE is to enable safe execution of complex

3



P2P Network

Service
Providers

Miners

Clients

Figure 1: ACE system model. Clients deploy and call

contracts by broadcasting transactions. Miners organize

transactions into blocks. Service Providers execute contracts

and post results to miners that will add them to new blocks.

smart contracts in permissionless blockchains and to address the
limitations of the previous solutions reviewed above.

3.1 System Model

Figure 1 shows our system model. ACE is based on a permissionless
setting where any entity can freely take one of the following roles.

Clients are equivalent to users in systems like Ethereum. Clients
can call smart contracts by broadcasting a signed transaction that
specifies the called contract. Client identities are pseudonyms,
which in principle can be arbitrary, but in practice consist of their
public key. In addition to calling contracts, clients can also deploy
new smart contracts as contract creators by broadcasting a trans-
action that contains the contract code and its specification. The
specification defines the service providers who should execute con-
tract calls and acceptance criteria for execution results.

Miners are responsible for collecting and ordering transactions in
blocks, similar to systems like Ethereum.2 The primary difference
between ACE miners and Ethereum miners is that the former do
not execute contract calls. Instead, they only perform basic validity
checks for transactions and simple state-dependency checks for
execution results before adding them to new blocks (see Section 3.5
for details).

Service providers are responsible for executing contract calls. Af-
ter execution is complete, service providers communicate the ex-
ecution results through the network. The identity of each service
provider is their public key. Service providers must make this pub-
lic key available to potential clients before they can execute smart
contracts (e.g. by publishing it on a website or on the blockchain
itself). Service providers can be incentivized through fees based on
the execution complexity (see Section 7).

Network. We assume that the above entities communicate over a
peer-to-peer network similar to existing blockchains such as Bitcoin
and Ethereum.

2We focus on Ethereum that uses Proof-of-Work consensus. Therefore, we use the
term miner to refer to a consensus participant, although our solution is orthogonal
to the used consensus scheme. ACE could be used also with other permissionless
consensus schemes like Proof of Stake.

3.2 Execution Model

The starting point of our solution is an off-chain contract execution
model similar to Arbitrum [17]. At the time of deploying a new con-
tract, the contract creator appoints n service providers responsible
for contract execution, called the executing set. The contract creator
specifies the identities (public keys) of these service providers in
a transaction that creates the contract.

Instead of requiring that all service providers have to agree on
the execution results, we follow a different approach and allow
the contract creator to define a quorum of q service providers that
are required for acceptable execution result. The identities of the
n service providers and the security parameter q together define
the trust level of the contract.

When a contract call is executed, if at least q out of the speci-
fied n service providers report the same execution result, the state
change will be accepted by the miners. Contract calls involving
multiple contracts need to be executed by the executing sets of all
involved contracts, but do not require contract participants to trust
executing sets of other contracts (see Section 3.4 for details).

Comparison to Ethereum. It may seem counterintuitive to allow
the contract creator to choose the trust level for each contract sep-
arately. However, we emphasize that this design decision is in line
with the existing trust model of Ethereum. For contract execution,
Ethereum’s trust model is contract-specific, i.e., users can freely
choose which contracts they decide to trust. For example, if a user
decides to send money to a particular smart contract, then with
this action the user implicitly agrees with the contract specification,
i.e., the conditions and the logic specified in that contract’s code. A
user that decides to trust one contract does not have to trust other
contracts that run in the same system.

In ACE, this specification additionally includes the identities of n
service providers and the quorum size q. Similar to Ethereum, any
party that does not use a particular ACE contract is not affected by
any results of that contract.

More generally, our execution model can be seen as a hybrid

of permissionless and permissioned systems. Both models have
shown wide acceptance and ACE explores the space in between
them (permissionless cryptocurrency, permissioned contracts). We
argue that it is valuable to understand what kind of improvements
that are possible with moderate trust model changes.

In particular, the decoupled off-chain execution provides more
efficiency and allows for a flexible trust model in which a permis-
sioned set of validators is appointed for each contract separately.
The smart contracts that are executed off-chain can directly utilize
the underlying digital currency that is implemented by the per-
missionless blockchain which provides transparency and double-
spending protection. The trust model is flexible as it allows various
applications with separate security requirements to co-exist in the
same system. For example, even if all validators of one contract are
fully compromised, only the funds of that contract are affected and
the integrity of the currency and other contracts are still guaranteed
for all other parties. Additionally, using a public blockchain to con-
nect clients to service providers enables simple service discovery.

4



3.3 Trust Assumptions

We consider clients fully untrusted, similar to most permissionless
blockchain systems. Regardingminers, we follow the standard trust
assumptions of Ethereum and other PoW systems. Any individ-
ual miner can be malicious, but miners are collectively trusted for
consensus (honest majority of the mining power) and forks in the
chain remain shallow.

Service providers can be reputable entities such as well-known
companies who run contracts in exchange for a small service fee or
non-profit organizations who run contracts for public good. We as-
sume that some service providers may get compromised and behave
arbitrarily (in contrast to systems like Ekiden). Each contract creator
appoints an executing set and defines the security parameter q for
the deployed contract. We say that a contract has an honest quorum,
when there are ≥ q non-faulty service providers in the set. With ≥ q
Byzantine faults, we say that the contract has a faulty quorum. Note
that a contract may have both an honest and a faulty quorum, since
q can be < n/2. The integrity of the underlying cryptocurrency (e.g.
money creation, double-spending) is independent of the contract ex-
ecution and does not rely on any of the appointed service providers.

3.4 Requirements

Next, we define informal requirements for our solution. Section 5
provides more detailed definitions and proofs.
Requirement 1: Safety. The main safety requirement of ACE is
that it should enable safe cross-partition calls without having to
assume all partitions trusted. More precisely, our solution should
guarantee execution integrity and strict serializability for all the
transactions of a contract that does not have a faulty quorum (i.e.,
it has < q Byzantine faulty service providers) even if the con-
tract interacts with other contracts that have faulty quorums (≥ q
faults). This requirement sets ACE apart from previous solutions
like YODA, Arbitrum and Ekiden, as none of them supports such
safe cross-partition calls.

Strict serializability [24] is a common isolation property for dis-
tributed database systems. It ensures that the outcome of transac-
tions executed in parallel (in separate partitions) is equal to one
in which the transactions had been executed atomically and se-
quentially in the order apparent to an external observer. For further
background on concurrency control, see Appendix A.2.

Execution integrity, in our context, means that the code of the
contract is executed correctly given all inputs that the contract
receives. If the execution of one contract depends on an input from
another contract, two options are possible. The first option is that
the contract’s logic needs to treat such inputs as untrusted data and
use them accordingly. The second option is to consider such inputs
as trusted data which means that clients should use the contract
only if they are willing to trust the source contract (and its trust
level) as well. In both options, a faulty source cannot violate the
integrity of the main contract’s execution.

Note that this is similar to contracts in Ethereum today. If an
Ethereum contract receives input from, e.g., an oracle or another
contract, this input either needs to be treated as untrusted by the
main contract’s code or alternatively the oracle or the input source
contract code needs to be considered trusted by the users of the
main contract.

Requirement 2: Liveness. For liveness, we consider two prop-
erties. The first is called contract liveness which means that any
contract with an honest quorum (≥ q non-faulty service providers)
stays responsive, even if it interacts with other contracts that do not
have honest quorums or have faulty quorums. When we say that
a contract is “responsive”, we mean that it is able to complete all
transactions either by successfully executing them or by returning
an abort message, and then move on to processing the next transac-
tion. The main benefit of such a liveness property is that interaction
with another potentially faulty or non-responsive contract cannot
halt the main contract.

The second liveness property that we consider is transaction
liveness which means that a transaction will eventually be executed
successfully. In Section 5.2 we show that ACE provides transaction
liveness when each contract involved in a transaction has an honest
quorum and none of them has a faulty quorum.

Requirement 3: Performance. The main performance require-
ment of ACE is efficient concurrent control. In distributed systems,
the entities that execute transaction need to agree on the order of
execution and whether execution was successfully completed on
all nodes before committing the final results. Classical distributed
commit protocols like two-phase locking [12] guarantee strict seri-
alizability, but require multiple rounds of communication between
all involved entities (see Appendix A.2).

ACE should minimize such concurrency control overhead for
transactions that are executed within one contract and across mul-
tiple contracts. In particular, we want to optimize the common and
benign case, so that safe transaction execution has minimal com-
munication overhead in the absence of errors and attacks (while
recovery from error conditions can be more expensive).

3.5 Contract Execution Overview

Next, we provide an overview of contract execution in ACE. Sim-
ilar to Ethereum, clients broadcast transactions to the peer-to-peer
network. We assume that every ACE transaction contains at least
one write operation, as read-only computations are possible simply
by examining the blockchain without issuing a new transaction.
The broadcasted transactions are ordered and collected into blocks
by miners. If a transaction does not include any contract call (i.e.,
it only transfers money from one account to another), the miners
immediately execute the transaction on-chain and record it in the
result section of the block.

If a transaction calls a contract, the miners perform basic checks
(e.g., correct transaction format) and then include the transaction in
the ordering section of a block, but importantly do not execute the
contract call. The new block is broadcast to the network. Once the
service providers appointed for this contract receive it, they execute
the contract call code. After executing the call, service providers
sign so called state change transactions and broadcast them back to
the network. Once the miners receive signatures from a quorum q
of the appointed service providers on the same set of state changes,
they check state-dependency, meaning that the state changes refer
to the hash of the previous state, and then include the state changes
and the corresponding signatures in the result section of a future
(not necessarily the next) block. The state-dependency check en-
sures that no conflicting results from two separate quorums within

5



the same execution set can be included and that results cannot be
replayed in different contexts (e.g. if another fork of the blockchain
becomes the canonical chain).
Safe and efficient commits. In distributed sys";"""date"",""2020-06-02T09:26:12Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""ACE: Asynchronous and Concurrent Execution  of Complex Smart Contracts""
""xmp:CreatorTool"",""LaTeX with acmart 2018/02/07 v1.50 Typesetting articles for the Association for Computing Machinery and hyperref 2018/02/06 v6.86b Hypertext links for LaTeX""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with acmart 2018/02/07 v1.50 Typesetting articles for the Association for Computing Machinery and hyperref 2018/02/06 v6.86b Hypertext links for LaTeX""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""ACE: Asynchronous and Concurrent Execution  of Complex Smart Contracts""
""modified"",""2020-06-02T09:26:12Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""Karl WĂźst, Sinisa Matetic, Silvan Egli, Kari Kostiainen, and Srdjan Capkun""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017/Debian) kpathsea version 6.2.3""
""meta:author"",""Karl WĂźst, Sinisa Matetic, Silvan Egli, Kari Kostiainen, and Srdjan Capkun""
""trapped"",""False""
""meta:creation-date"",""2020-06-02T09:26:12Z""
""created"",""2020-06-02T09:26:12Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-06-02T09:26:12Z""
""resourceName"",""835.pdf""
""Author"",""Karl WĂźst, Sinisa Matetic, Silvan Egli, Kari Kostiainen, and Srdjan Capkun""
""producer"",""pdfTeX-1.40.18""
""pdf:docinfo:producer"",""pdfTeX-1.40.18""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""Karl WĂźst, Sinisa Matetic, Silvan Egli, Kari Kostiainen, and Srdjan Capkun""
""dcterms:created"",""2020-06-02T09:26:12Z""
""Last-Modified"",""2020-06-02T09:26:12Z""
""dcterms:modified"",""2020-06-02T09:26:12Z""
""title"",""ACE: Asynchronous and Concurrent Execution  of Complex Smart Contracts""
""Last-Save-Date"",""2020-06-02T09:26:12Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2020-06-02T09:26:12Z""
""meta:save-date"",""2020-06-02T09:26:12Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017/Debian) kpathsea version 6.2.3""
""Content-Length"",""946616""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Karl WĂźst, Sinisa Matetic, Silvan Egli, Kari Kostiainen, and Srdjan Capkun""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""14""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""4950"",""5779"",""5932"",""4940"",""5779"",""5353"",""4589"",""4841"",""5577"",""5415"",""4105"",""5249"",""6657"",""4271""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-06-02T09:26:12Z""
";https://scholar.google.ch/scholar?start=640&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098831-258;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Private set intersection in the internet setting from lightweight oblivious PRF;M Chase, P Miao ; Annual International Cryptology Conference, 2020  Springer;;"… in CRYPTO 2019) to run the protocol on a cloud computing service, our protocol also … their security

proof, a pseudorandom function used in their protocol is modeled as a random oracle … to achieve

the best efficiency, we only model hash functions as random oracles and assume …";Cité 8 fois;Les 3 versions;[PDF] iacr.org;https://eprint.iacr.org/2020/729.pdf;"
Private Set Intersection in the Internet Setting From Lightweight

Oblivious PRF

Melissa Chase

Microsoft Research

melissac@microsoft.com

Peihan Miao∗

Visa Research

pemiao@visa.com

Abstract

We present a new protocol for two-party private set intersection (PSI) with semi-honest
security in the plain model and one-sided malicious security in the random oracle model. Our
protocol achieves a better balance between computation and communication than existing PSI
protocols. Specifically, our protocol is the fastest in networks with moderate bandwidth (e.g.,
30− 100 Mbps). Considering the monetary cost (proposed by Pinkas et al. in CRYPTO 2019)
to run the protocol on a cloud computing service, our protocol also compares favorably.

Underlying our PSI protocol is a new lightweight multi-point oblivious pesudorandom func-
tion (OPRF) protocol based on oblivious transfer (OT) extension. We believe this new protocol
may be of independent interest.

1 Introduction

Private set intersection (PSI) enables two parties, each holding a private set of elements, to com-
pute the intersection of the two sets while revealing nothing more than the intersection itself.
PSI has found many applications including privacy-preserving location sharing [NTL+11], pri-
vate contact discovery [CLR17, RA17, DRRT18], DNA testing and pattern matching [TPKC07],
testing of fully sequenced human genomes [BBDC+11], collaborative botnet detection [NMH+10],
and measuring the effectiveness of online advertising [IKN+17]. In the past several years PSI
has been extensively studied and has become truly practical with extremely fast implementa-
tions [HFH99, FNP04, DSMRY09, DCKT10, ADCT11, DCGT12, HEK12, DCW13, PSZ14, PSSZ15,
KKRT16,RR17a,RR17b,CLR17,RA17,DRRT18,FNO18,PSWW18,GN19,PRTY19,PRTY20].

When measuring the efficiency of a PSI protocol, there are two major aspects usually considered.
First, the computation cost, which is the amount of computing time necessary to run the protocol.
Optimizing the computation cost is especially important in practice because of limited computa-
tional resources. The state-of-the-art computationally efficient semi-honest PSI protocol [KKRT16]
uses only oblivious transfer (OT) [Rab05], a cryptographic hash function, symmetric-key crypto-
graphic operations, and bitwise operations. It can privately compute the intersection of two million-
size sets in about 4 seconds. This is because OT itself has been heavily optimized, and in particular
because of work on OT extension [IKNP03,ALSZ13], which allows many oblivious transfers to be
performed using only a small number of public key operations and a combination of symmetric
primitives (hash functions/AES) and bitwise operations.

∗Part of the work done while visiting Microsoft Research.

1



The second aspect in the measurement is the communication cost, which refers to the total
amount of communication in the protocol. Minimizing the communication cost is also crucial in
practice due to limited network bandwidth, which is often a shared resource for multiple applica-
tions. The communication-optimal PSI protocol [ADCT11] requires communication that is only
marginally more than a näĹve and insecure protocol (where one party simply sends hash of its
elements to the other party), but the protocol is computationally too expensive to be adopted in
practice.

On the more practical side, Pinkas et al. [PRTY19] achieve communication that is half that
of [KKRT16] and roughly 8 times the näĹve approach at the cost of more expensive operations based
on finite field arithmetic.1 The result is roughly a 6-7 times overhead compared to [KKRT16]. This
leaves open the question of whether reducing the communication cost of [KKRT16] requires more
expensive computational tools, or whether it could be achieved with significantly lower computa-
tional overhead.

Can we achieve the best of both computation and communication?

When we look at tradeoffs between communication and computation, one valuable metric is
the total running time of the protocol, which includes both the computation time and the time to
transmit and receive the necessary messages. Of course this time will vary depending on the network
bandwidth, and different protocols may perform better in different network settings. Viewed in this
light, [KKRT16] can be viewed as a protocol optimized for the LAN setting, where bandwidth is not
a bottleneck, while [PRTY19] is targeted at very low bandwidth settings. However, we argue that
it is valuable to design optimized protocols for the full range of settings, and that the middle range
(e.g. 30-100 Mbps) is in fact very important. During Q2-Q3 2018, the average download speed over
fixed broadband in the U.S. was 95.25 Mbps and average upload speed was 32.88 Mbps [LLC18].
For example, the Comcast Standard business internet package includes 75 Mbps; larger businesses
might have higher bandwidth but would not want to devote all of it to a single protocol. Thus,
this seems like a very valuable range to consider.

In the work of Pinkas et al. [PRTY19], they propose an alternative efficiency metric — the
monetary cost to run the protocol on a cloud computing service. This new metric takes both com-
putation cost and communication cost into consideration. The PSI protocols proposed in [PRTY19]
have much less communication compared to the computation-optimized protocol [KKRT16] and
much faster running time compared to the communication-optimized protocol [ADCT11]. As a
result, they achieve a better balance between computation and communication and have the least
monetary cost. We can ask though, whether they achieve the best balance.

1.1 Our Contribution

In this work, we make positive progress on the aforementioned questions by presenting a new PSI
protocol that achieves a better balance between computation and communication.

A New PSI. We present a new PSI construction which we believe achieves better computation/-
communication tradeoffs. This protocol is based only on oblivious transfer, hashing, symmetric-key

1The work [PRTY19] describes two protocols, one optimized for speed (spot-fast) and one optimized for commu-
nication cost (spot-low). Here the comparison is for their fast protocol because the communication optimized one is
significantly slower.

2



and bitwise operations, and as such it has favorable computation; at the same time its communica-
tion is almost as small as [PRTY19]. In particular, our protocol is 2.53−3.65× faster than spot-fast
and 19.4 − 28.7× faster than spot-low [PRTY19] in computation and requires 1.46 − 1.69× lower
communication than [KKRT16]. Overall, our protocol is the fastest in a network with moderate
bandwidth (e.g., 30 − 100 Mbps). In addition, we theoretically and experimentally analyze the
monetary cost according to the metric from [PRTY19] and show that it compares very favorably.

Efficient Multi-Point OPRF. The PSI protocol of [PRTY19] is based on a multi-point obliv-
ious PRF (OPRF) protocol that requires polynomial interpolation over a large field, which is
computationally significantly more expensive than the symmetric-key and bitwise operations in the
single-point OPRF of [KKRT16]. We propose a new multi-point OPRF protocol that is based on
OT extension that again relies only on symmetric-key and bitwise operations and hashing. It is
conceptually very simple to understand and easy to implement. Additionally, our protocol is more
flexible in that it allows for tuning parameters to achieve better computation or better communi-
cation. We believe this protocol may be of independent interest.

Security Against Malicious Sender. In most of this work, we focus on the semi-honest security
model, where both parties follow the PSI protocol description honestly while trying to extract more
information about the other party’s input set, and aim to achieve the optimal practical efficiency.
However, we can show that our protocol also achieves security in the random oracle model when
one of the parties is malicious, in particular if we refer to the parties as sender and receiver where
the receiver is the party who receives the output, then we protect against the malicious sender. In
the previous work [KKRT16, PRTY19], only the spot-low variant of [PRTY19] achieves one-sided
malicious security. As will be shown in Section 5, our protocol is much more efficient in running
time and cheaper in monetary cost than spot-low.

We note that this sort of asymmetric guarantee is very appropriate in settings where the com-
putation is between a large established company and a small business or a consumer. A large
company may have a reputation to maintain and more policies and procedures in place to protect
against misbehaviour, so assuming semi-honest security may be more reasonable. On the other
hand, if the protocol is run with many different consumers or small businesses it may be hard to
ensure that all of them are sufficiently trustworthy to assume semi-honest security.

In light of this, when we consider our efficiency metrics we also consider an asymmetric setting
where the sender runs on a cloud service like AWS while the receiver has its own internet service;
this should capture the example of a small business who does not have its own dedicated servers
but would instead outsource its computations to the cloud. We see that in this setting our protocol
is even more advantageous, achieving 5.01 − 6.48× lower monetary cost than spot-low [PRTY19]
in all of the settings we consider.

1.2 Technical Overview

Conceptually speaking, our PSI protocol leverages a primitive called an oblivious pseudorandom
function (OPRF) [FIPR05], which allows a sender to learn a PRF key k and a receiver to learn the
PRF output OPRFk(y1), . . . ,OPRFk(yn) on its inputs y1, . . . , yn ∈ Y . Nothing about the receiver’s
inputs is revealed to the sender and nothing more about the key k is revealed to the receiver.
If the sender additionally computes OPRFk(x1), . . . ,OPRFk(xn) on its inputs x1, . . . , xn ∈ X and
sends them to the receiver, then the receiver can identify the intersecting PRF values and the

3



corresponding set intersection. In this section we describe how to construct an efficient OPRF
protocol based on OT extension.

Our starting point is the computationally most efficient PSI protocol [KKRT16], which can be
conceptually viewed as evaluating n single-point OPRFs, where the sender learns a PRF key k
while the receiver can only obliviously evaluate on a single input y. We first describe their protocol
at a high level and then elaborate how to extend the single-point OPRF to a multi-point OPRF
while still only using the efficient OT extension and symmetric-key operations.

Single-Point OPRF. The single-point OPRF realized in [KKRT16] is evaluated as follows. Let
the PRF key k consist of two bit-strings q, s ∈ {0, 1}Ν. Let F (¡) be a pseudorandom code that
produces a pseudorandom string and let H be a hash function. The pseudorandom function is
computed as

OPRFk(x) = H(q ⊕ [F (x) · s]),

where · denotes bitwise-AND and ⊕ denotes bitwise-XOR. For a randomly generated s, if F (x) has
enough Hamming weight then the function OPRFk(x) is pseudorandom assuming the hash function
H is correlation robust.

To evaluate this single-point OPRF on the receiver’s input y, the receiver first samples a random

string r0
$← {0, 1}λ and computes r1 = r0 ⊕ F (y). The sender also samples a random string

s
$← {0, 1}λ. Then the two parties execute λ oblivious transfers where the sender acts as a receiver

in the OT and inputs Îť choice bits s[1], s[2], . . . , s[Îť] while the receiver acts as a sender in the OT
and inputs Ν pairs of messages {r0[i], r1[i]}i∈[Ν] (each message is a single bit). At the end of the
OT, the sender receives λ bits {rs[i][i]}i∈λ. Now the sender simply sets q = rs[1][1]‖ . . . ‖rs[λ][λ] and
lets the PRF key be k = (q, s). The PRF value on y learned by the receiver is H(r0). Correctness
can easily be checked, namely q ⊕ [F (x) · s] = r0 if x = y.

PSI From Single-Point OPRF. Given the above construction of single-point OPRF, [KKRT16]
built a PSI protocol as follows. They first use Cuckoo hashing [PR04] to assign the receiver’s
elements into b bins such that each bin contains at most one element. Then the sender and receiver
run the single-point OPRF for each bin so that the sender obtains b PRF keys and the receiver
learns b PRF values. Now for each bin, the sender computes the PRF for that bin on all the possible
elements in that bin, and sends all the PRF values to the receiver.

In the above single-point OPRF, the only heavy cryptographic tool needed is OT, which requires
public-key operations. Since the same choice bits can be used for all the n instances of OPRF, all
the OTs can be done via Îť instances of string OTs, which can be efficiently instantiated by OT
extension.

In this protocol, each element on the sender’s side is evaluated on multiple PRFs (the number
of hash functions plus the the stash size in Cuckoo hashing), which incurs a constant overhead
in communication from the sender to the receiver. We get rid of this overhead by constructing a
multi-point ORPF so that every element is only evaluated once.

Extending to Multi-Point OPRF. In the single-point OPRF construction, there are 2Îť possi-
ble choices of s and different resulting PRF keys k that the sender will receive. However, no matter
which s is chosen, OPRFk(y) = H(r0). We extend this idea to multi-point OPRF.

4



Our new PRF key contains a matrix M of size m × w. To evaluate the PRF on input x, we
again need a hash function H, and we evaluate a pseudorandom code F (x) which produces a vector
in v ∈ [m]w. Let Mi denote the i-th column of M . The pseudorandom function is computed as

OPRFM (x) = H (M1[v[1]]‖ . . . ‖Mw[v[w]]) .

The sender picks a random string s ∈ {0, 1}w. The receiver prepares two sets of column vectors
A1, . . . , Aw ∈ {0, 1}m and B1, . . . , Bw ∈ {0, 1}m. The two parties run w number of OTs where the
sender behaves as a receiver and the receiver behaves as the sender. At the end of the protocol, the
sender obtains w column vectors, which will form the PRF key M . On the other hand, the receiver
forms an m×w matrix A = [A1 . . . Aw] and computes the OPRF on its values by OPRFA(y). At a
high level, the receiver prepares the two sets of column vectors {A1, . . . , Aw} and {B1, . . . , Bw} such
that no matter what s is chosen, OPRFM (x) = OPRFA(x) for every x ∈ Y . The parameters m,w are
carefully chosen such that OPRFM (x) is pseudorandom to the receiver for every x /∈ Y . Preparing
the column vectors takes the receiver linear time in n and only involves cheap symmetric-key and
bitwise operations. The OTs can be instantiated by the efficient OT extension.

Multi-Point OPRF From [PRTY19]. We note that [PRTY19] takes a different approach to
achieving multi-point OPRF by high-degree polynomial interpolation and evaluation over a large
field. Their computation complexity is asymptotically O(n log2 n) while ours is O(n). For concrete
efficiency, our protocol only relies on efficient OT extension and AES operations. More details on
performance comparison can be found in Section 5.

One-Sided Malicious Security. We further prove our protocol is secure against a malicious
sender. We note that [PRTY19] also proves one-sided malicious security for spot-low. In their
security proof, a pseudorandom function used in their protocol is modeled as a random oracle.
Since the malicious party knows the PRF key, the PRF cannot be instantiated by efficient block
ciphers like AES. Instantiating it using a hash function makes the protocol much less efficient than
the semi-honest secure protocol. In our protocol, the pseudorandom code F (¡) is instantiated by a
pseudorandom function Fk(¡) and both parties know the PRF key, hence the same problem arises.
In order to achieve the best efficiency, we only model hash functions as random oracles and assume
F is a PRF, which makes our security proof more involved.

1.3 Related Work

In this work we primarily compare with [KKRT16] and [PRTY19] since as discussed above they
currently provide the best tradeoffs between computation and communication. [PSZ14, PSSZ15]
provide a good overview and performance comparison of a variety of approaches to PSI. To briefly
mention a few, generic MPC based PSI [HEK12] incurs higher comunication and computation costs,
and Diffie-Hellman based PSI (e.g. [IKN+17]) has relatively small communication (comparable to
[PRTY19]) but incurs significantly higher computation costs. There are protocols based on garbled
circuit-based OPRFs which can be competitive when the set sizes are very unequal [KRS+19].
There have also been other works based on OT extension [PSSZ15,PSZ18], which can achieves the
best performance for very short elements and small set sizes.

There have also been several other works which followed up on the [KKRT16] approach, notably
[FNO18]. They describe a scheme which replaces the Cuckoo hash table with another algorithm for

5



Parameters: P1’s input set size n1 and P2’s input set size n2.

Inputs: Party P1 inputs a set of elements X = {x1, . . . , xn1} where xi ∈ {0, 1}∗. Party P2 inputs
a set of elements Y = {y1, . . . , yn2} where yi ∈ {0, 1}∗.
Output: Party P2 receives the set intersection I = X ∊ Y .

Figure 1: Ideal functionality for PSI FPSI.

assigning elements to table rows which is more complex to compute but allows for a slightly smaller
table and removes the stash. They do not provide an implementation, but they claim that for
most set sizes their scheme achieves a 10-15% improvement in communication costs over [KKRT16]
whereas we achieve a 30-40% improvement in communication with what we would expect to be
much lighter computational overhead.

2 Preliminaries

2.1 Notation

We use Ν, σ to denote the computational and statistical security parameters, respectively. We use
[n] to denote the set {1, 2, . . . , n}. For a vector v of length `, we use v[i] to denote the i-th element
of the vector. For a matrix M of dimension n × m, we use Mi to denote its i-th column vector
(i ∈ [n]). We use ‖x‖H to denote the hamming weight of a binary string x. By negl(λ) we denote
a negligible function, i.e., a function f such that f(Ν) < 1/p(Ν) holds for any polynomial p(¡) and
sufficiently large Îť.

2.2 Security Model

Private Set Intersection (PSI) is a special case of secure two-party computation. We follow the
standard security definitions for secure two-party computation in this work. The ideal functionality
of PSI is defined in Figure 1.

Semi-honest security. Let viewΠ
1 (X,Y ) and viewΠ

2 (X,Y ) be the view of P1 and P2 in the proto-
col Π, respectively. Let outΠ(X,Y ) be the output of P2 in the protocol. Let f(X,Y ) be the output
of P2 in the ideal functionality. The protocol Π is semi-honest secure if there exists PPT simulators
S1 and S2 such that for all inputs X,Y ,(

viewΠ
1 (X,Y ), outΠ(X,Y )

) c
≈
(
S1(1Îť, X, n2), f(X,Y )

)
;

viewΠ
2 (X,Y )

c
≈ S2(1λ, Y, n1, f(X,Y )).

Malicious security against P1. The protocol Π is secure against a malicious P1 if for any PPT
adversary A in the real world (acting as P1) that could arbitrarily deviate from the protocol, there
exists a PPT adversary S in the ideal world (acting as P1) that could change its input to the ideal
functionality and abort the output, such that for all inputs X,Y ,

RealΠA(X,Y )
c
≈ IdealFS (X,Y ),

6



Parameters: Message length L.

Inputs: The receiver inputs a choice bit b ∈ {0, 1} and the sender inputs nothing.

Output: Sample m0,m1
$← {0, 1}L. Output (m0,m1) to the sender and mb to the receiver.

Figure 2: Ideal functionality for Random Oblivious Transfer FROT.

where RealΠA(X,Y ) is the output of A and P2 in the real world, IdealFS (X,Y ) is the output of S and
P2 in the ideal world.

2.3 Oblivious Transfer

Oblivious Transfer (OT), introduced by Rabin [Rab05], is a central cryptographic primitive in the
area of secure computation. 1-out-of-2 OT refers to the setting where a sender has two input strings
(m0,m1) and a receiver has an input choice bit b ∈ {0, 1}. As the result of the OT protocol, the
receiver learns mb without learning anything about m1−b while the sender learns nothing about
b. This primitive requires expensive public-key operations. Ishai et al. [IKNP03] introduced a
technique called OT extension that allows for a large number of OT executions at the cost of
computing a small number of public-key operations. In Random OT (ROT), the sender’s OT
inputs (m0,m1) are randomly chosen, which allows the protocol itself to produce these random
values. Hence a random OT protocol requires much less communication especially from the sender
to the receiver. In this work we only need the weaker primitive of random OT, whose functionality
is defined in Figure 2.

2.4 Correlation Robustness

Our PSI construction is proven secure under a correlation robustness assumption on the on the
underlying hash function, which was introduced for OT extension [IKNP03] and later generalized
in [KK13,KKRT16,PRTY19] to the version we use in this work.

Definition 2.1 (Hamming Correlation Robustness). Let H be a hash function with input length n.
Then H is d-Hamming correlation robust if, for any a1, . . . , am, b1, . . . , bm ∈ {0, 1}n with ‖bi‖H ≥
d for each i ∈ [m], the following distribution, induced by random sampling of s

$← {0, 1}n, is
pseudorandom. Namely,

(H(a1 ⊕ [b1 · s]), . . . ,H(am ⊕ [bm · s]))
c
≈ (F (a1 ⊕ [b1 · s]), . . . , F (am ⊕ [bm · s])) ,

where · denotes bitwise-AND and ⊕ denotes bitwise-XOR, F is a random function.

The IKNP protocol uses this assumption with n = d = Îť. In that case, the only valid choice for
bi is 1λ and the distribution simplifies to H(a1⊕ s), . . . ,H(am⊕ s). In our case, we use n > d = λ,
so other choices for the bi values are possible.

3 Our PSI Protocol

In this section we describe our protocol and prove its semi-honest security in the plain model and
malicious security against P1 in the random oracle model.

7



3.1 Construction

We describe our PSI protocol in Figure 3. During the protocol in Step 2 the two parties need to
run an OT protocol. Since the matrix A is randomly sampled by P2, this step can be instantiated
efficiently using random OT as shown in Figure 4.

At a high level, P2 constructs two matrices A and B of special form from its input elements.
Note that for each y ∈ Y , let v = Fk(H1(y)), the matrices A and B are constructed such that
Di[v[i]] = 0 for all i ∈ [w], and hence Ai[v[i]] = Bi[v[i]] = Ci[v[i]] for all i ∈ [w]. That means, if
P1’s element x = y for some y ∈ Y (i.e., x is in the intersection), then its input to the hash function
in Step 3 will be the same as y’s input to the hash function. On the other hand, if x is not in
the intersection, then its input to the hash function would be significantly different from any y’s
input to the hash function, and the PRF output would be pseudorandom to P2. Note that the hash
function H1(·) is not necessary for semi-honest security, but is applied for extracting P1’s inputs in
the malicious case.

The parameters m,w in our protocol are chosen such that if F is a random function and H1(x)
is different for each x ∈ X ∪ Y , then for each x ∈ X \ I and v = F (H1(x)), there are at least
d 1’s in D1[v[1]], . . . , Dw[v[w]] with all but negligible probability. We discuss how to choose these
parameters in Section 3.3.

3.2 Security Proof

Theorem 3.1. If F is a PRF, H1 is a collision resistant hash function, and H2 is a d-Hamming
correlation robust hash function, then the protocol in Figure 3 securely realizes FPSI in the semi-
honest model when parameters m,w, `1, `2 are chosen as described in Section 3.3 .

Security against corrupt P1. We construct S1 as follows. It is given P1’s input set X. S1 runs
the honest P1 protocol to generate its view with the following exceptions: For the oblivious transfer,

S1 generates P1’s random string s
$← {0, 1}w honestly and chooses a random matrix C ∈ {0, 1}m×w,

and runs the OT simulator to simulate the view for an OT receiver with inputs s[1], . . . , s[w] and
outputs C1, . . . , Cw. In Step 3a, S1 sends a uniformly random PRF key k to P1. Finally S1 outputs

P1’s view. We prove
(
viewΠ

1 (X,Y ), outΠ(X,Y )
) c
≈
(
S1(1Îť, X, n2), f(X,Y )

)
via the following hybrid

argument:

Hyb0 P1’s view and P2’s output in the real protocol.

Hyb1 Same as Hyb0 except that on P2’s side, for each i ∈ [w], if s[i] = 0, then sample Ai
$← {0, 1}m

and compute Bi = Ai⊕Di; otherwise sample Bi
$← {0, 1}m and compute Ai = Bi⊕Di. This

hybrid is identical to Hyb0.

Hyb2 Same as Hyb1 except that S1 (instead of P2) chooses the random PRF key k. This hybrid is
statistically identical to Hyb1.

Hyb3 Same as Hyb2 but the protocol aborts if there exists x, y ∈ X ∪ Y, x 6= y such that H1(x) =
H1(y). The aborting probability is negligible because H1 is collision resistant.

Hyb4 Same as Hyb3 but the protocol also aborts if there exists x ∈ X \ I such that, for v =
Fk(H1(x)), there are fewer than d 1’s in D1[v[1]], . . . , Dw[v[w]]. The parameters m,w are

8



0. P1 and P2 agree on security parameters Ν, σ, protocol parameters m,w, `1, `2, two hash
functions H1 : {0, 1}∗ → {0, 1}`1 and H2 : {0, 1}w → {0, 1}`2 , pseudorandom function
F : {0, 1}λ × {0, 1}`1 → [m]w.

1. Precomputation

• P1 samples a random string s
$← {0, 1}w.

• P2 does the following:

(a) Initialize an m × w binary matrix D to all 1’s. Denote its column vectors by
D1, . . . , Dw. Then D1 = ¡ ¡ ¡ = Dw = 1m.

(b) Sample a uniformly random PRF key k
$← {0, 1}λ.

(c) For each y ∈ Y , compute v = Fk(H1(y)). Set Di[v[i]] = 0 for all i ∈ [w].

2. Oblivious Transfer

(a) P2 randomly samples an m × w binary matrix A
$← {0, 1}m×w. Compute matrix B =

A⊕D.

(b) P1 and P2 run w oblivious transfers where P2 is the sender with inputs {Ai, Bi}i∈[w] and
P1 is the receiver with inputs s[1], . . . , s[w]. As a result P1 obtains w number of m-bit
strings as the column vectors of matrix C (with dimension m× w).

3. OPRF Evaluation

(a) P2 sends the PRF key k to P1.

(b) For each x ∈ X, P1 computes v = Fk(H1(x)) and its OPRF value ψ =
H2(C1[v[1]]‖ . . . ‖Cw[v[w]]) and sends ψ to P2.

(c) Let Ψ be the set of OPRF values received from P1. For each y ∈ Y , P2 computes
v = Fk(H1(y)) and its OPRF value ψ = H2(A1[v[1]]‖ . . . ‖Aw[v[w]]) and outputs y iff
ψ ∈ Ψ.

Figure 3: Our private set intersection protocol.

chosen such that if F is a random function and H1(x) is different for each x ∈ X∪Y , then the
aborting probability is negligible. If the aborting probability in Hyb4 is non-negligible, then
we can construct a PPT adversary A to break the security of PRF. In particular, given the
sets X and Y , A constructs the matrix D as in Hyb4 except that whenever it needs to compute
Fk, A queries the PRF challenger for the output. Finally, if there exists x ∈ X \ I such that,
for v = Fk(H1(x)), there are fewer than d 1’s in D1[v[1]], . . . , Dw[v[w]], namely the protocol
aborts, then A guesses PRF, otherwise A guesses random function. A guesses correctly with
probability 1

2 + non-negl. Therefore, the protocol aborts with negligible probability in Hyb4.

Hyb5 Same as Hyb4 but party P2’s output is replaced by f(X,Y ) (i.e., the intersection I = X ∩Y ).
This hybrid changes P2’s output if and only if there exists x ∈ X, y ∈ Y, x 6= y such that,
for v = Fk(H1(x)), u = Fk(H1(y)), H2(C1[v[1]]‖ . . . ‖Cw[v[w]]) = H2(A1[u[1]]‖ . . . ‖Aw[u[w]]).
This happens with negligible probability as H2(C1[v[1]]‖ . . . ‖Cw[v[w]]) is pseudorandom by
the correlation robustness of H2, so for sufficiently large `2 this probability will be negligible.

9



1. P1 and P2 perform w random OTs with message length m, where P1 is the receiver with inputs

choice bits s[1], . . . , s[w]. As a result, P2 gets w pairs of random messages {r(0)
i , r

(1)
i }i∈[w] and

P1 gets w messages {ri}i∈[w] where ri = r
(s[i])
i .

2. P2 does the following:

(a) Let {r(0)
i }i∈[w] form the column vectors of the matrix A and compute the matrix B =

A⊕D.

(b) Compute ∆i = Bi ⊕ r(1)
i for all i ∈ [w] and send to P1.

3. P1 computes the matrix C as follows: if s[i] = 0 then set Ci = ri; otherwise set Ci = ri ⊕∆i.

Figure 4: Step 2 of our PSI protocol instantiated using random OT.

Specifically, for each xi ∈ X \ I, let vi = Fk(H1(x)), ai = A1[vi[1]]‖ . . . ‖Aw[vi[w]], and bi =
D1[vi[1]]‖ . . . ‖Dw[vi[w]]. Then xi’s input to the hash function H2 is C1[vi[1]]‖ . . . ‖Cw[vi[w]],
which is ai ⊕ [bi · s]. Additionally we have the guarantee that ‖bi‖H ≥ d. Since s is randomly
sampled, by the d-Hamming correlation robustness of H2, the outputs of H2(C1[vi[1]]‖ . . .
‖Cw[vi[w]]) are pseudorandom.

If the outputs of H2(C1[vi[1]]‖ . . . ‖Cw[vi[w]]) are truly random, then a collision of H2(C1[v[1]]‖
. . . ‖Cw[v[w]]) = H2(A1[u[1]]‖ . . . ‖Aw[u[w]]) happens with negligible probability. If the col-
lision in this hybrid happens with non-negligible probability, then we can construct a PPT
adversary A to break the correlation robustness of H2. In particular, given the sets X and
Y , A constructs the matrix A as in this hybrid and H2(A1[ui[1]]‖ . . . ‖Aw[ui[w]]) for each
yi ∈ Y . A can also compute the matrix D as in this hybrid and (ai, bi) for each xi ∈ X \ I.
As we explained above, H2(C1[vi[1]]‖ . . . ‖Cw[vi[w]]) = H2(ai ⊕ [bi · s]). A queries the oracle
for the outputs of H2(ai ⊕ [bi · s]). If a collision happens, then A guesses the hash function;
otherwise A guesses random function. A guesses correctly with probability 1

2 + non-negl.
Therefore, the probability of collision is negligible by our choice of `2 for semi-honest security
in Section 3.3.

Hyb6 Same as Hyb5 but the protocol does not abort. The indistinguishability of Hyb6 and Hyb5

follows from the collision resistance of H1 and the pseudorandomness of Fk by the same
arguments as above.

Hyb7 The simulated view of S1 and f(X,Y ). The only difference from Hyb6 is that S1 samples the
matrix C and runs the OT simulator to simulate the view of an OT receiver for P1. This
hybrid is computationally indistinguishable from Hyb6 by security of the OT protocol.

Security against corrupt P2. We construct S2 as follows. It is given as input P2’s set Y ,
the size of P1’s set n1, and the intersection I = f(X,Y ). S2 runs the honest P2 protocol with
the following exceptions: For the oblivious transfer, S2 computes the matrices A and B honestly
and run the OT simulator to produce a simulated view for the OT sender. For each x ∈ I,
it computes v = Fk(H1(x)) and the OPRF value ψ = H2(A1[v[1]]‖ . . . ‖Aw[v[w]]). Let this set
of OPRF values be ΨI . Choose n1 − |I| random `2-bit strings and let this set be Ψrand. Send

10



Ψ = ΨI ∪ Ψrand to P2 in Step 3b. Finally S2 outputs P2’s view in this invocation. We argue

viewΠ
2 (X,Y )

c
≈ S2(1λ, Y, n1, f(X,Y )) through the following hybrids:

Hyb0 P2’s view in the real protocol.

Hyb1 Same as Hyb0 but the protocol aborts if there exists x, y ∈ X ∪ Y, x 6= y such that H1(x) =
H1(y). The aborting probability is negligible because H1 is collision resistant for sufficiently
large `1 chosen in Section 3.3.

Hyb2 Same as Hyb1 except that the protocol aborts if there exists x ∈ X \ I such that, for v =
Fk(H1(x)), there are fewer than d 1’s in D1[v[1]], . . . , Dw[v[w]]. The parameters m,w are
chosen such that if F is a random function and H1(x) is different for each x ∈ X∪Y , then the
aborting probability is negligible. If the aborting probability in Hyb2 is non-negligible, then
we can construct a PPT adversary A to break the security of PRF. In particular, given the
sets X and Y , A constructs the matrix D as in Hyb2 except that whenever it needs to compute
Fk, A queries the PRF challenger for the output. Finally, if there exists x ∈ X \ I such that,
for v = Fk(H1(x)), there are fewer than d 1’s in D1[v[1]], . . . , Dw[v[w]], namely the protocol
aborts, then A guesses PRF, otherwise A guesses random function. A guesses correctly with
probability 1

2 + non-negl. Therefore, the protocol aborts with negligible probability in Hyb2.

Hyb3 Same as Hyb2 except that S2 runs the OT simulator to produce a simulated view of an OT
sender for P2. This hybrid is computationally indistinguishable to Hyb2 by security of the
OT protocol.

Hyb4 Same";"""date"",""2020-08-11T13:26:53Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2020-08-11T13:26:53Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016) kpathsea version 6.2.2""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2020-08-11T13:26:53Z""
""created"",""2020-08-11T13:26:53Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-08-11T13:26:53Z""
""resourceName"",""729.pdf""
""Author"",""""
""producer"",""pdfTeX-1.40.17""
""pdf:docinfo:producer"",""pdfTeX-1.40.17""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""2"",""2"",""7"",""2"",""7"",""17"",""24"",""16"",""13"",""29"",""12"",""20"",""6"",""13"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""32"",""22""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2020-08-11T13:26:53Z""
""Last-Modified"",""2020-08-11T13:26:53Z""
""dcterms:modified"",""2020-08-11T13:26:53Z""
""title"",""""
""Last-Save-Date"",""2020-08-11T13:26:53Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2020-08-11T13:26:53Z""
""meta:save-date"",""2020-08-11T13:26:53Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016) kpathsea version 6.2.2""
""Content-Length"",""443961""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""28""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""2376"",""2957"",""3176"",""2736"",""2918"",""1915"",""2108"",""2435"",""2015"",""2422"",""2733"",""2328"",""2667"",""2573"",""1681"",""1548"",""2304"",""2659"",""1821"",""1229"",""2703"",""2054"",""1972"",""2265"",""2299"",""974"",""1949"",""1996""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-08-11T13:26:53Z""
";https://scholar.google.ch/scholar?start=800&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098813-219;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Why Stake When You Can Borrow?;T Chitra, A Evans ; Available at SSRN 3629988, 2020  papers.ssrn.com;;"… agents rebalance their portfolios based on information that is endogenous to the blockchain itself …

possible to replace the final condition with the existence of a decentralized oracle [35] instead …

Firstly note that decentralized oracles such as Augur [35] or Chainlink/DECO [36] rely …";Autres articles;;[PDF] arxiv.org;https://arxiv.org/pdf/2006.11156;"
Why Stake When You Can Borrow?

Tarun Chitra1 and Alex Evans2

1Gauntlet Networks, Inc. tarun@gauntlet.network
2Placeholder alex@placeholder.vc

Abstract

As smart contract platforms autonomously manage billions of dollars of capital, quantifying the
portfolio risk that investors engender in these systems is increasingly important. Recent work illustrates
that Proof of Stake (PoS) is vulnerable to financial attacks arising from on-chain lending and has worse
capital efficiency than Proof of Work (PoW) [1]. Numerous methods for improving capital efficiency
have been proposed that allow stakers to create fungible derivative claims on their staked assets. In
this paper, we construct a unifying model for studying the security risks of these proposals. This model
combines birth-death Pólya processes and risk models adapted from the credit derivatives literature to
assess token inequality and return profiles. We find that there is a sharp transition between ‘safe’ and
‘unsafe’ derivative usage. Surprisingly, we find that contrary to [2] there exist conditions where derivatives
can reduce concentration of wealth in these networks. This model also applies to Decentralized Finance
(DeFi) protocols where staked assets are used as insurance. Our theoretical results are validated using
agent-based simulation.

Introduction

Proof of Stake (PoS) is a Sybil resistance mechanism that aims to replace the scarce physical resource usage
of Proof of Work (PoW) by using consensus-enforced scarcity of a digital asset. Moving from PoW to
PoS has promised to reduce mining’s energy usage, increase scalability, and improve network participation.
PoS achieves this by minting cryptographically-secured tokens according to a fixed monetary policy. Token
holders receive a pro-rata portion of inflation by staking, or locking up their tokens in a smart contract,
which lets them validate transactions that the network processes. If the entire token supply is staked, the
cost of performing a double-spend attack becomes proportional to 33% (Byzantine Fault Tolerant, BFT) or
51% (longest-chain) of the token supply. Therefore, if the value of a PoS token (relative to a numéraire) is
large and a large fraction of the outstanding tokens are staked, the network is safe against adversaries with
capital proportional to the token’s market capitalization [1].

PoS’s threat model is, however, more complex than that of PoW as the usage of capital as a scarce
resource leads to novel financial attacks that do not exist in PoW [2, 3]. First, the compounding effects of
PoS assets, which do not exist in PoW, make it difficult to design incentive compatible monetary policies [2].
Moreover, as PoS assets require both market capitalization and staking participation to be high for security,
scenarios that keep the market capitalization high, while staking participation remains low can be dangerous
to these networks. The attacks of [3] arise in such a scenario, which occur when the system’s users and
validators are rational profit seeking agents. One enters this scenario when alternative yields (e.g. lending)
exceed PoS returns. In such scenarios, rational actors unstake their assets and migrate them to alternative
vehicles to maximize individual profit, while reducing network security. This behavior also leads to capital
flight and can cause deflationary spirals [4].

The time value of capital that is lost from locking up an inflationary monetary instrument in a smart
contract can be significant, which disincentivizes staking when there exist alternative yield-generating oppor-
tunities. In order to incentivize validator participation, staking protocols have proposed staking derivatives,

1

ar
X

iv
:2

00
6.

11
15

6v
1 

 [
q-

fi
n.

G
N

] 
 1

6 
Ju

n 
20

20



which allow validators to borrow against their staked assets [5, 6, 7, 8]. This borrowing, which resembles
secured lending from fiat finance such as home equity loans, provides a mechanism for validators to gain
partial liquidity on their staked capital. By having the protocol provide lending services (in the form of
staking derivatives), one can potentially mitigate the capital flight issues of [3]. For instance, a validator
with 1000 tokens of a digital asset X locked in a staking contract can use a staking derivative to mint 750
tokens of a synthetic asset Y , representing a borrow of 75% of stake. At the beginning of the lien, the
synthetic asset could be redeemed one-to-one for the underlying asset. However, if the validator is slashed,
the synthetic asset will redeem for less. In this case, if the validator is slashed and loses 50 tokens, then they
may only be able to redeem 1 Y for 0.5 X.

In practice, validators share default risk with other borrowers, which is typically the case when a PoS
protocol issues fungible derivative assets, i.e. when all borrowing obligations are denominated in a common
asset. Such constructions involve issuing staking derivatives backed by the collective obligations of the
validator base. Similar aggregations are also common to DeFi lending protocols. In the MakerDAO [9]
protocol, loans are denominated in a single fungible asset, Dai, whose value depends on a pool of non-
fungible loans called “Vaults.” Similarly, lenders in Compound [10] are issued tokens (called “cTokens”) that
entitle holders to a proportional share of the interest generated by all borrowers (for example, lenders of Dai
would be issued “cDai,” whose redemption price depends on the interest accrued from all Dai-denominated
loans originated by Compound). In both PoS and DeFi, we argue that aggregating obligations from a
heterogeneous pool of borrowers into a single asset can be analogized to securitization [11]. The analogy is
more than skin-deep, as shown in §1.1 where we consider the options available to PoS protocols for creating
fungible assets representing pools of validator liens.

Unsurprisingly, as the security of a PoS system depends on the total amount of staked assets and their
relative value to a numéraire (such as US dollars or Bitcoin), this type of borrowing will decrease the
security of the PoS system. Moreover, as illustrated in [2], PoS protocols with improperly chosen monetary
policies can lead to concentration of stake in the hands of a few, further reducing network security. But
how do we quantify this decrease in security? The above description has numerous parameters, such as
how overcollateralized a validator’s loan needs to be, what is the interest rate to charge, and how is the
redemption pricing curve constructed. To fully evaluate the safety of the system, one needs to model how
the underlying PoS asset, the synthetic derivative asset, and other lending opportunities interact with one
another. In this paper, we will construct a risk model for a broad class of staking derivatives. This model
will be analyzed through two lenses:

1. Inequality : We extend the specialized Pólya urn model of [2] to a generalized process that represents
derivatives. Recent advances in probability allow us to analytically estimate how derivatives impact
inequality.

2. Returns and Portfolio Optimization: Under the assumption of rational validators, we study the returns
on portfolios of staked, lent, and derivative assets. We liken staking derivatives to secured loans whose
returns depend on staking yields and provide intuition via existing models from quantitative finance.

We will also evaluate these models via numerical simulation and agent-based modeling.

Agent-Based Model

We extend the agent-based framework of [3] to consider rational actors who hold portfolios of staked, lent, and
derivative assets. Participants rebalance their portfolios by maximizing a utility function, which represents
the best portfolio that one can hold given current market prices and yields. Each participant has a different
risk preference leading to non-trivial dynamics as riskier borrowers will rebalance their portfolios to be
derivative heavy, whereas risk-averse borrowers will have their portfolios be staking coin heavy. Note that
adding a derivative instrument, which represents a leveraged long claim on the underlying PoS token, adds
novel risks for validators. In particular, validators begin to default on these liens when they are slashed for
activities that are antithetical to consensus. Constructing such an instrument involves having the consensus
algorithm be aware of the current value of a validator’s debt when adjusting the monetary policy of the

2



network. This is different than the situation of [3], where the lending rates are independent of the consensus
algorithm used for the PoS asset.

The main machinery that we add to allow consensus to keep track of debt prices and positions is a
constant function market maker (CFMM) [12, 13]. CFMMs are smart contracts that act as an exchange for
the staked coin and the derivative asset. The usage of CFMMs in cryptocurrencies began with Uniswap [13],
which was used for token-to-token exchanges mediated by a CFMM. Uniswap has had close to $75 million
of digital assets locked in it, demonstrating practical CFMM viability. However, CFMMs have also been
used for other financial applications such as portfolio rebalancing [14], margin trading [15], and stablecoins
[16, 17]. These simple and versatile mechanisms are parametrized by a convex function that maps asset
quantities to an implied price. This also allows them to be utilized in consensus sensitive matters. Celo [17]
incorporates a Uniswap-style CFMM in consensus to adjust the PoS protocol’s monetary policy based on
transaction demand and money velocity. When the main venue for trading a PoS asset against a lien is an
on-chain CFMM, a PoS protocol can adjust its monetary policy and execute margin calls on overleveraged
validators. Ideally, the lending activity related to a PoS token mainly comprises of validators borrowing
against their staked assets, allowing consensus to intervene and avoid the scenarios posed in [3].

If there are a number of defaults in the synthetic asset — validators borrow against their staked quantity,
but cannot repay their loans — then synthetic asset holders often share the default risk pro-rata. As a simple
example, suppose that we have 10 validators with an equal staked quantity and all of them have borrowed
against their stake. If 20% of validators default on their loans, then the remaining 80% have their borrowed
assets get 25% more expensive to close in order to cover the losses of the defaulted loan. This means that
if at time t0, the synthetic asset and the PoS asset have the same price in a CFMM, then at time tdefault,
when both defaults happen, the prices of the synthetic asset should be 75% that of the PoS asset. Thus,
the exchange rate between the underlying coin and the derivative asset should represent the expected future
defaults that the derivative will have to absorb.

We model on-chain lending in the same manner as [3] by using the Compound protocol [18]. On-chain
lending pools, where lenders share default risk pro-rata, are common in cryptocurrency financial products
such as Compound [18], Uniswap [13], and in PoS itself [3]. Such protocols rely on cryptographic properties
of smart contracts to ensure that participants are incentivized to avoid malicious behavior. This model uses
a scoring rule to price the interest rate for borrowing one cryptoasset in exchange for another as collateral
based on supply and demand. If St and Dt are the supply and demand (in tokens) for borrowing a token
at time t, these mechanisms furnish a function f : R+ × R+ → [0, 1] such that f(St, Dt) is the interest rate
changed to borrowers. The loans are overcollateralized, like home-equity loans, and the demand is driven by
crypto-asset holders who want to borrow fiat currency against their cryptocurrencies for liquidity. The largest
on-chain lending pools on Ethereum are MakerDAO [19] and Compound [18], growing to hold hundreds of
millions of dollars by early 2020. These pools have proven to be resilient and provide arbitrageurs with ample
opportunity to provide price discovery between lent assets as well as for swaps between pairs of assets.

By combining CFMMs with on-chain lending pools, we are able to focus on how rational agents rebalance
their portfolios based on information that is endogenous to the blockchain itself. Our usage of CFMMs implies
that as long as one rational arbitrageur exists, on-chain prices will match external prices [12]. Moreover,
the usage of on-chain lending pools implies that all participants can see the same rates for borrowing versus
those of staking, allowing for a direct optimization problem to be constructed. As CFMMs are parametrized
by their scoring function φ, it is instructive to consider whether such systems exist in practice.

Staking Derivatives outside of PoS

Existing research on staking primarily focuses on its use as a Sybil resistance mechanism in consensus.
However, Decentralized Finance (DeFi) applications have found novel ways to use staking outside of PoS.
DeFi applications utilize staked capital as ‘insurance funds’ and ‘security pools’ for algorithmic stablecoins,
on-chain lending, and margin trading.

Algorithmic Stablecoins are tokens with dynamic monetary policies that adjust to maintain a peg to
another asset, such as the US dollar. These assets increase their token issuance when the synthetic asset is
above the peg and decrease it by buying back the stable asset and destroying it (‘burning’). Protocols such

3



as Celo [16] and Terra [20] utilize a staking token that represents both on-chain transaction fees as well as
a debt instrument. In these protocols, stakers earn interest for transaction validation, but can have their
assets diluted in order to buy back the stable asset when it is trading below its peg. Celo [16] and Terra [21]
use CFMMs to handle this dilution process. This usage of CFMMs to enforce protocol constraints fits into
the framework presented in §1.

On-chain lending protocols, such as Aave [22] and Compound [23, 18], have insurance funds that take
a fraction of earned interest and hold it in escrow. This earned interest is used to pay back lenders when
external market conditions cause failure modes such as cascading liquidations [18]. These failure modes
represent edge cases where a decentralized lending protocol is unable to sell assets to cover liabilities due to
market volatility. MakerDAO’s ‘Black Thursday’ events on March 12, 2020 represent a realized instance of
this situation [24]. As lending protocols aim to decentralize their ownership, new token models from Aave [25]
and Compound [26] require staking for participation in both the governance and insurance functions of the
system. In this use case, the insurance fund pays out stakers from received interest and dilutes the staking
token when mass defaults happen. The lending contract effectively securitizes the insurance fund via this
mechanism, allowing for a larger pool of capital to back the algorithmic loans issued. These mechanisms
resemble reinsurance and can also be analyzed using the staking derivatives framework.

Margin trading protocols such as Synthetix [27] and UMA [28] utilize a staking token that acts akin to
an exchange seat at the CME. When this token is staked in Synthetix, it is eligible for both staking rewards
and can be used as collateral for a synthetic asset. If a user wants to mint a synthetic version of the S&P
500, they need to provide a price feed and collateral (in the staking asset). Once minted, users can place
pairwise margin trading bets on whether the S&P 500 will go up or down, with the shorts paying the longs if
the asset moves up. These synthetic assets have risks that arise when the collateral value falls precipitously,
leaving the system unable to pay the winning side of a margin trade. Thus, similar to the on-chain lending
case, the staking token allows investors to earn interest when trades are settled, but possibly absorb losses
when the system is unable to pay out as expected. This is another form of a staking derivative that falls
within the framework of §1.

Finally, we note that Tezos’s ‘virtual baker’ mechanism [29] as well as the stochastic model of MakerDAO
[19] both fit into our framework, with different choices of CFMM. We will map these various uses of staking
derivatives to a CFMM pricing function in §2.1. The variety of uses of staking derivatives in PoS and DeFi
suggest that a pricing model that covers known use cases and is simple to interpret will be valuable for the
evolution of these systems. The remainder of this paper will describe the assumptions and model used to
characterize staking derivatives. We will prove some properties about this model and use numerical simula-
tion to check that these transitions exist. Finally, we conclude with a discussion about how to instantiate
the different models discussed in this section via choices of the CFMM pricing function φ.

Takeaways for PoS & DeFi protocol designers

We highlight the main results that are relevant for DeFi and PoS protocol designers. First, the results of §3
show that one can reduce inequality amongst stakers by adding staking derivatives. However, the portfolio
returns estimated in §4.5.2 show that this inequality comes at the cost of burning a significant fraction of
the money supply. These two results describe a trade-off between the number of liquidations of a derivative
position and the amount of inequality in the system. The phase transitions estimated via simulation in
these sections suggest that there is a small region of parameter space where one can balance these trade-offs
optimally. In this ‘optimal region,’ one can use a staking derivative to be the dominant form of borrowing
in the system, so that the on-chain lending attacks of [3] are ineffective. This optimal region is the portion
of the ‘safe’ regime that is closest to the phase transition boundary (see Figures 3, 5 for examples). Thus
for staking systems that admit significant leverage (e.g. Synthetix [30]), it can be crucial to ensure that
the system stays within this region. While the analytical results of §3 and §4.5.2 provide bounds on these
transitions, the precise boundary between the ‘safe’ and ‘unsafe’ region which is optimal can only be explored
via simulation. Figures 6b, 7b illustrates how the size of a validator’s slashed bond affects the size of the
optimal region.

The risk models used in §4 for the ‘safe’ derivative region are analogues of models used to analyze credit

4



derivatives, such as mortgage-backed securities (MBS). In the MBS literature, one considers derivative
securities with ‘embedded options.’ These options correspond to homeowners deciding to prepay their
mortgage (leading to a loss of interest) or refinancing their mortgage. Accurately pricing MBSs relies on
including the value at risk to an investor when these options are exercised. Staking derivative loans can
also be thought to have embedded options that are granted to the lender (the PoS protocol) instead of the
borrower. These may involve default protections such as penalizing validators whose derivative is deemed
overleveraged, or otherwise adjusting the derivative pricing function φ on a per-user basis. Designers can
embed a notion of a ‘credit score’ in φ that allows for borrowers with good borrowing histories to mint
derivatives with lower fees. Given that a number of DeFi protocols have proposed including similar benefits
to active participants [31, 32], it is important to correctly value these embedded options when choosing
pricing curves. Claim 5 provides a technique for a wide class of staking derivatives (including all proposals in
DeFi and PoS known to the authors) for approximating the risks associates with such options. The results
of §4.3 extend credit derivative risk measures [33, Ch. 6] to staking derivatives and can be used to choose φ.

Outline

The remainder of the paper will focus on describing the staking derivatives framework. We note that
mathematical notation and details about the assumptions made about the Proof of Stake model, based on
those from [3], can be found in Appendices A and B. The main new mathematical object introduced in this
paper, the derivative pricing function φ for CFMMs, will be introduced in §1. We construct derivative pricing
functions for both PoS networks and for DeFi protocols that utilize staking mechanisms. The main difference
is that DeFi protocols rely on different boundary conditions than those of PoS networks. Subsequently, we
will construct two models that utilize φ to price derivatives: an urn model and a portfolio risk model.

The urn model of §3 will provide a way to measure concentration of wealth and inequality in the stake
distribution. In this section, we will use theoretical results on continuous-time embeddings of urn models
to measure how derivatives affect concentration of wealth. Surprisingly, our main result is that there exist
scenarios where the existence of derivatives lowers the amount of inequality in the system. We illustrate
this result theoretically by using a proxy for the Gini coefficient, the ratio of L2 to L1 norms of the stake
distribution. Subsequently, we use a simulated agent-based model to numerically verify this result under
more realistic conditions and verify that the Gini coefficient indicates a less concentrated stake distribution.

Portfolio risk is assessed in §4.1. The main results that we find are that there are ‘safe’ and ‘unsafe’
regimes for both of these systems, which are characterized by features of φ and the monetary policy of the
network. When in the safe regime, we show that this model can be interpreted in a manner similar to credit
derivatives with embedded options. This interpretation allows for us to compute the expected returns for
both the validator and the protocol, as they hold portfolios of staked and borrowed assets. We further show
that in the safe region, the results of [3] on capital flight due to lending still hold.

1 Derivative Pricing Function

The main object of study in this paper is the derivative pricing function for validator i, denoted ϕi. This
function allows for pricing synthetically minted assets in terms of an underlying asset. In order to understand
how to construct ϕi, we will first need to study the function of staking derivatives.

1.1 Staking Derivatives

Consider the Tezos PoS network [34], which has been live since 2018 and whose XTZ token is the largest
PoS coin by market capitalization. Suppose that Tezos validators were allowed to borrow up to 75% of
their staked assets in the form of a synthetic XTZ, sXTZ, with value equal to the market price of XTZ at
inception. In order for a validator to recover their stake and earned block rewards, they need to buy back
their XTZ with sXTZ. Such a synthetic asset is known as a staking derivative, as it represents a lien against

5



Figure 1: ϕi constructed from φ(s) = 1
sk
∧ 1 for different exponents k. The x-axis is the ratio πstake(h)

πstake(hissued)
.

This ratio only decreases when a validator is slashed in PoS or if a price moves against a direction in DeFi
(e.g. sUSD/SNX price goes down, even though a staker is long). The dotted line represents a collateral factor
of ci = 0.75. The loan is liquidated, represented by φ(ciπstake(hissued)) = ∞. The steepness in the changes
in φ from the different exponents control how leveraged a validator is as they are increasingly slashed.

staked assets [5]. Unlike other on-chain liens,1 this liability is known to the consensus protocol, which can
ensure that if a validator has less stake than what they borrowed, they lose their assets. Note that validators
who use such liens to gain liquidity are taking leveraged long positions on the underlying asset (e.g. XTZ),
akin to a “Vault” in MakerDAO [19].

For example, suppose that a validator has 10,000 XTZ staked in the network with a collateral factor of
75%, meaning they can borrow up to 7,500 XTZ worth of sXTZ. If the current price of sXTZ is 1.01 XTZ,
then a validator borrowing maximally against 1,000 XTZ would receive 1, 000× 1.01× 0.75 = 757.5 sXTZ.
The borrowing validator can use the sXTZ as a normal token and sell it (e.g. for a stablecoin or Bitcoin),
allowing them to have increased capital efficiency and liquidity. However, in order for the borrowing validator
to reclaim their staked XTZ, they have to repurchase their stake using sXTZ. If the validator borrowed 1,010
sXTZ but was slashed, the price in sXTZ that they have to pay the network to reclaim his collateral is higher
than 1,010 sXTZ. Moreover, if the validator is slashed by 2,500 sXTZ (e.g. they have less staked than their
7,500 limit), then their loan is defaulted on and the network reclaims 1,010 sXTZ. On the other hand, if the
validator’s stake upon repaying the borrowed asset is greater than or equal to the quantity staked when the
loan was taken out, the borrower’s price remains 1,010 sXTZ. These constraints ensure that the PoS network
penalizes validators who borrow against their staked assets and perform a malicious activity (that leads to
slashing).

Let hissued be the block height that validator i minted a staking derivative against their stake at that
time πstake(hissued)i and let hclosed be the block height they closed their loan. Moreover, let ci ∈ [0, 1] be
the ith validator’s collateral factor. This represents the fraction of stake that can be borrowed against, e.g.
ciπstake(h) is the fraction allowed to be borrowed. For a staking derivative to be economically sound or
solvent, the following properties are necessary:

Property 1. Default if overleveraged. If a validator borrows at block height hissued, but at height
h′ > hissued, πstake(h

′)i < ciπstake(hissued)i, then the network can reclaim the validator’s stake and redistribute
it as fit.

1In MakerDAO, Compound, and Synthetix, the protocol pays liquidators to buy defaulted liens, whereas a PoS currency
can simply burn a validator’s stake

6



Property 2. Repayment amount bounded below. If a validator mints x sXTZ at block height hissued
then no matter what, they will always at least pay x sXTZ to regain their collateral. This ensures that the
sXTZ/XTZ price will be greater than or equal to 1, meaning that the synthetic will never be worth more than
the underlying asset.

Property 3. Monotonically increasing payment. Suppose a validator borrows x sXTZ at block height
hissued. Suppose they have to pay back x(i) sXTZ if they are slashed i times. The borrowing mechanism is
said to be monotonic in payment if x(i) is increasing in i — the more you are slashed, the more you have
to repay.

Property 4. There exists an on-chain synthetic-to-real market. In the previous example, we require
the sXTZ to XTZ price to mark the loan and to figure out much a validator needs to repay. In order for the
consensus algorithm to execute a default, it needs this market price. Moreover, borrowers need access to this
market to purchase sXTZ to close their liens.

These conditions ensure that the protocol mints derivatives that are always solvent. Note that these
conditions are analogous to those required by over-collateralized lending contracts [18] and by debt-driven
algorithmic stablecoins [4, 19]. The first condition ensures that the system’s assets (e.g. the staked coins)
are always greater than net liabilities (e.g. the derivative). The second condition ensures that there is no
economic abstraction of the underlying asset by the synthetic asset. In particular, this implies that market
will never find sXTZ to be more valuable than XTZ, which could lead stakers to borrow sXTZ against
their staked XTZ and then default. Monotonically increasing payments ensure that bad borrowers (e.g.
validators who are repeatedly slashed) have to pay the network more to borrow against their stake, as they
are providing riskier collateral to the network. Finally, the last condition ensures that borrowers can easily
buy sXTZ to repay their debt and ensures that the protocol can correctly adjust the monetary supply upon
realizing a default.

Note that while it is possible to replace the final condition with the existence of a decentralized oracle
[35] instead of an on-chain market, we argue that this is not feasible for staking derivatives. Firstly note
that decentralized oracles such as Augur [35] or Chainlink/DECO [36] rely on smart contract protocols for
their execution. Since staking derivatives are used for the base protocol’s staking asset, the smart contract
would need to run on the same network, which would cause a variety of issues. For instance, the oracle
contract could be censored by validators who have large liens that are in default, which is a form of ’miner
extractable value’ [37]. Moreover, if an oracle were used, the PoS consensus protocol would be subject to
manipulation from this oracle, as it will have security under a different threat model. Finally, we note that
while CFMMs can be manipulated, it is expensive to do so. The cost of manipulating a CFMM is linear in
the size of the liquidity pool, whereas oracle manipulation has a constant cost [13, Appendix E].

How can we enforce these constraints within the protocol? Constant function market makers (CFMM) [13,
12] provide on-chain mechanisms for pricing baskets of assets based on quantities deposited by participants.
These mechanisms rely on two principal agents: liquidity providers (LPs) and traders. Liquidity providers
lend their assets to a smart contract and upon each trade executed by a trader, receive a pro-rata share of
transaction fees. The main parameter needed to configure a CFMM is a scoring rule Φ : Rk+ → R+ that
maps a vector of quantities of assets q ∈ Rk+ to an invariant. Provided that Ό is closed and convex, one can
compute the prices of any pairs of assets. For staking derivatives, we require a function ÎŚ : R2

+ → R that
can provide the price of the synthetic asset relative to the underlying asset (e.g. sXTZ/XTZ) and satisfy the
above constraints. We note that when constructing two-asset CFMMs, it is sufficient to provide a pricing
curve ϕ : R+ → R+ to construct a CFMM Φ [13]. We provide an explicit example of such a construction in
the sequel.

2 Constructing ϕ

Before constructing ϕ, let us first look at how it is used to close out liens. Suppose that we have a validator
who has staked assets πstake(h)i at block height h, then the validator is allowed to use ϕ to mint up to

7



ciπstake(h)i in synthetic assets. Therefore, each validator can be thought of as holding a portfolio Π(i, h) =
(πstake(h)i,−δi) of staked assets at block height h πstake(h)i and synthetic borrowed assets δi. In order to
close out the −δi(h) position, the validator has to pay the borrowing contract ϕ(πstake(h)i). The first three
conditions from the previous section are represented as follows:

• Default if overleveraged: If ϕ(πstake(h))i < ciϕ(πstake(hissued))i then Π(i, h) = (0, 0)

• Repayment bounded below: For all h > hissued ϕ(πstake(h)i) ≥ δi

• Monotonically increasing payment: If for h, h′ > hissued we have πstake(h)i < πstake(h
′)i then

ϕ(πstake(h)i) ≥ ϕ(πstake(h
′)i)

Recall that in Assumptions 3 and 4, we assume that each validator has their own collateral factor ci and
probability of being slashed pi. This means that each validator should have a pricing function ϕi that depends
on their collateral factor and likelihood of being slashed. To make the borrowed asset fungible (e.g. similar to
Compound’s wrapped tokens, such as cDAI), we will need to construct ϕ as an aggregation of individual val-
idator’s pricing functions ϕi. Note that this is analogous to the ‘non-fungible’ CDPs in MakerDAO which give
rise to a ‘fungible’ synthetic token Dai. The precise form of the aggregation, such as the bounded mean aggre-
gation ϕ(πstake(t)) = 1

n

∑
i(ϕi(πstake(t)i)∧ϕmax) or ϕ(πstake(t) = Median(ϕ1(πstake(t)1), . . . , ϕn(πstake(t)n)),

does not affect our results2 and for the remainder of the paper we will focus on dealing with ϕi.
We can think of the synthetic asset as “shares” collateralized by the assets staked in the network. These

shares, which are tradeable against the underlying staked asset provide the validator with liquidity that
depends on their collateralization ratio ci and their current stake. Thus, ϕi takes in a validator’s current
stake and the stake they had when they bo";"""date"",""2020-06-22T00:26:21Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2020-06-22T00:26:21Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016) kpathsea version 6.2.2""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2020-06-22T00:26:21Z""
""created"",""2020-06-22T00:26:21Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-06-22T00:26:21Z""
""resourceName"",""2006.11156""
""Author"",""""
""producer"",""pdfTeX-1.40.17""
""pdf:docinfo:producer"",""pdfTeX-1.40.17""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""2"",""0"",""6"",""0"",""0"",""13"",""1"",""30"",""19"",""0"",""0"",""16"",""27"",""15"",""5"",""1"",""0"",""0"",""0"",""0"",""0"",""0"",""10"",""4"",""11"",""1"",""7"",""10"",""9"",""24"",""66"",""91""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2020-06-22T00:26:21Z""
""Last-Modified"",""2020-06-22T00:26:21Z""
""dcterms:modified"",""2020-06-22T00:26:21Z""
""title"",""""
""Last-Save-Date"",""2020-06-22T00:26:21Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2020-06-22T00:26:21Z""
""meta:save-date"",""2020-06-22T00:26:21Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016) kpathsea version 6.2.2""
""Content-Length"",""1274539""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""37""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""3170"",""3984"",""4207"",""4189"",""3659"",""2561"",""3700"",""3319"",""3738"",""2585"",""3725"",""3424"",""2916"",""1617"",""3691"",""3443"",""3030"",""3136"",""2770"",""2810"",""527"",""614"",""3237"",""2590"",""2797"",""2578"",""2511"",""1957"",""2209"",""1462"",""507"",""1639"",""1582"",""1658"",""2417"",""1178"",""780""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-06-22T00:26:21Z""
";https://scholar.google.ch/scholar?start=760&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098813-216;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Lossy CSI-FiSh: Efficient signature scheme with tight reduction to decisional CSIDH-512;A El Kaafarani, S Katsumata, F Pintore ;2020 ora.ox.ac.uk;;"… 2.4 Fiat-Shamir Transformation The original Fiat-Shamir transformation [1,18] turns a (not

necessarily lossy) identification protocol ID into a digital signature scheme by means of a crypto-

graphic hash function H : {0, 1}? ? ChSet modeled as a classical random oracle (RO) …";Autres articles;Version HTML;[PDF] ox.ac.uk;https://ora.ox.ac.uk/objects/uuid:24940de5-15fc-4973-ad91-54799c215b7d/download_file?safe_filename=Kaafarani%2520et%2520al%2520Lossy%2520CSI-FiSh.pdf&type_of_work=Conference+item;"
Lossy CSI-FiSh: Efficient Signature Scheme with
Tight Reduction to Decisional CSIDH-512

Ali El Kaafarani1,2, Shuichi Katsumata3, Federico Pintore1

1 Mathematical Institute, University of Oxford, UK
federico.pintore@maths.ox.ac.uk

2 PQShield, UK
elkaafarani@pqshield.com

3 National Institute of Advanced Industrial Science and Technology (AIST), JP
shuichi.katsumata@aist.go.jp

Abstract. Recently, Beullens, Kleinjung, and Vercauteren (Asiacrypt’19)
provided the first practical isogeny-based digital signature, obtained from
the Fiat-Shamir (FS) paradigm. They worked with the CSIDH-512 pa-
rameters and passed through a new record class group computation.
However, as with all standard FS signatures, the security proof is highly
non-tight and the concrete parameters are set under the heuristic that
the only way to attack the scheme is by finding collisions for a hash
function.
In this paper, we propose an FS-style signature scheme, called Lossy
CSI-FiSh, constructed using the CSIDH-512 parameters and with a se-
curity proof based on the “Lossy Keys” technique introduced by Kiltz,
Lyubashevsky and Schaffner (Eurocrypt’18). Lossy CSI-FiSh is provably
secure under the same assumption which underlies the security of the
key exchange protocol CSIDH (Castryck et al. (Asiacrypt’18)) and is
almost as efficient as CSI-FiSh. For instance, aiming for small signature
size, our scheme is expected to take around ≈ 800ms to sign/verify while
producing signatures of size ≈ 280 bytes. This is only twice slower than
CSI-FiSh while having similar signature size for the same parameter set.
As an additional benefit, our scheme is by construction secure both in
the classical and quantum random oracle model.

1 Introduction

1.1 Background

Isogeny-based cryptography is one of the promising candidates for post-quantum
cryptography. While isogeny problems offer simple and efficient solutions to en-
cryption schemes (or equivalently, key-exchange protocols) [8, 25], they turned
out to be rather elusive to use for constructing signature schemes.

At the highest level, all isogeny-based signatures we know thus far are based
on the Fiat-Shamir paradigm [1, 18]: prepare a hard relation R based on an
isogeny problem, construct an identification protocol (or sigma protocol) for R,
and use a cryptographic hash function to compile the identification protocol



2 A. El Kaafarani et al.

into a signature scheme in the random oracle model (ROM). Both the two cen-
tral isogeny problems — the computational supersingular isogeny (CSSI) prob-
lem [13] and the group action inverse problem (GAIP) [8] — have been the basis
for constructing signatures. Those based on CSSI, proposed in [21, 42], produce
signatures of size at least 12KB even in the most optimized variant [21]. On the
other hand, relying on GAIP and employing the Fiat-Shamir with aborts strat-
egy [31], De Feo and Galbraith introduced a compact isogeny-based signature
named SeaSign [12]. Despite the inefficiency in the signature generation and
verification, SeaSign provides signatures of a remarkably small size (less than
1 kilobyte at the 128-bit security level).

Very recently, a new record class group computation has allowed Beullens,
Kleinjung and Vercauteren [6] to improve SeaSign and obtain the first practical
isogeny-based signature scheme, named CSI-FiSh. Their computation has shed
light on the structure of the ideal class group determined by a specific set of
CSIDH parameters, named CSIDH-512 [8]. This granted a proper uniform sam-
pling from the ideal class group, and canonical representation of its elements,
which enabled to overcome the costly remedy made by SeaSign. That is, the
adoption of a redundant representation of class group elements and performing
rejection sampling. The result is practical efficiency in both signature generation
and verification while maintaining the short signature size offered by SeaSign.
However, one important remark is that, since CSI-FiSh is specific to the spe-
cial set of parameters CSIDH-512, it can offer at most the same security level
provided by a hard problem defined over the CSIDH-512 parameters. Specifi-
cally, CSI-FiSh relies on the GAIP problem, which is believed to have 128-bits
of classical and (at most) 64-bits of quantum security over the CSIDH-512 pa-
rameters [8, 34].

Tight Security. Fiat-Shamir (FS) signatures [1,18] admit an intuitive and sim-
ple construction in the ROM, however, they are notorious for having a very
loose reduction. Since a loose reduction forces for a stronger hardness assump-
tion, and consequently a less efficient scheme, it has been the focus of several
works to tighten the reduction loss, e.g., [3, 19,22,26,32,33,37].

To give a more precise perception of the security loss, assume we had a FS
signature that is secure based on the hardness of a particular hard problem Π.
Then, the security proof of FS signatures in the classical ROM dictates that the
reduction algorithm can break the underlying problemΠ with advantageQ−1·ε2,
where Q is the number of hash evaluations an adversary can perform and Îľ is the
advantage of an adversary breaking the security of the FS signature. Therefore,
if we want to instantiate the FS signature with provably secure parameters, we
must assume the hardness of the problem Π for a security level that is much
higher than expected. For instance, if we aim for 128-bits of security for the
FS signature (i.e., ε = 2−128), then assuming a modest Q ≈ 240, we require at
least 296-bits of security for the hard problem Π. Since a hard problem with a
higher level of security must necessitate larger parameters, this leads to inefficient
schemes.



Lossy CSI-FiSh: Efficient and Tightly Secure Signature Scheme 3

This undesirable loss in security and efficiency is common to all standard FS
signatures and CSI-FiSh is no exception. However, one large difference between
CSI-FiSh and other FS signatures is that CSI-FiSh relies on a hard problem
defined for a specific security level — the GAIP problem over the CSIDH-512
parameters. For the time being, no other parameter sets are known to provide
the nice algebraic structure required for CSI-FiSh. This is in sharp contrast
with FS signatures based on other hardness assumptions since most hardness
assumptions can “absorb” the reduction loss by setting the parameters larger.
Since GAIP over the CSIDH-512 parameters only offers 128-bits of classical
security, we cannot argue any notion of provable security for CSI-FiSh if we
aim for 128-bits of security. Concretely, if we plug in Q ≈ 240 as above, we can
only provably argue 44-bits of security for CSI-FiSh. Moreover, if we aim for
quantum security, the situation is worse since the reduction algorithm can break
the underlying problem Π with only advantage Q−6 ·ε3 [16,30]. We note that the
currently available resources would probably allow other record computations for
bigger parameters for which GAIP is believed to have a much higher security
level; however, the benefit of having a higher security level would likely be beaten
by the significant slow-down in efficiency.

In practice, this inconvenient reduction loss in FS signatures is usually over-
looked or simply ignored, and the parameters are set assuming that the best
attack against the FS signature is (roughly) finding a collision in the hash func-
tion. In [6], the parameters for CSI-FiSh are set under this simplified assumption
as well. Considering this undesirable gap between practice and theory, a natural
question which arises is:

Can we design an isogeny-based signature scheme as efficient as CSI-
FiSh with provable secure parameters?

1.2 Our Contribution

In this work, we provide a partial answer to the above problem and propose a
new signature scheme, Lossy CSI-FiSh, with the following features:

– It is tightly secure under a natural hardness assumption over the CSIDH-512
parameters, that is, the decisional CSIDH (D-CSIDH) assumption.
We note D-CSIDH is not a new assumption introduced in this paper, as it
was originally defined by Stolbunov in his PhD thesis [39, Problem 2.2] and
implicitly underlies the security of the key exchange protocol CSIDH [8].4

– It is almost as efficient as CSI-FiSh. Compared to CSI-FiSh, the signature
size is the same, the public key is only twice as large, and the runtime of the
signature generation and verification is estimated to be (at most) twice as
slow. For instance, aiming for small signature size, our scheme is expected
to take around ≈ 800ms to sign/verify while producing signatures of size

4 Roughly, this is parallel to the relation between the Diffie-Hellman (DH) protocol
and the decisional DH assumption [15]. For a more formal discussion, we refer to
Section 3.1.



4 A. El Kaafarani et al.

≈ 280 bytes. This is still 150 times faster and around 3 times smaller than
an optimized version of SeaSign for the same parameter set.

– It is secure both in the classical and quantum ROM (QROM). In particular,
we do not require a separate construction using the Unruh transform [40] to
achieve security in the QROM.

We obtain our results by following the line of work that constructs lossy
identification protocols to obtain tightly secure FS signatures [2, 26, 27, 41]. A
lossy identification protocol comes with an additional lossy statement generator
that produces lossy statements which are computationally indistinguishable from
honestly generated statements for the hard relation R induced by some hardness
assumption. Moreover, relative to the lossy statements, the protocol admits sta-
tistical soundness. That is, not even a computationally unbounded adversary can
successfully impersonate a prover. Using the result of Kiltz, Lyubashevsky, and
Schaffner [27] (see Theorem 2.1), a lossy identification protocol directly provides
us an FS signature with a tight reduction in the classical and quantum ROM.

The idea to use a lossy identification protocol to achieve tight security for
isogeny-based FS signatures was also considered by De Feo and Galbraith for
SeaSign [12, Section 8]. In particular, they proposed to take a very large ideal
class group (determined by a big prime p) and then only a small subset as the
space of possible private keys (that results in valid public keys being chosen from
a set of roughly the same cardinality). The signature generation and verification
processes are not altered from the standard SeaSign scheme. The result is that
the lossy variant inherits the inefficiency of the main scheme, with the increment
of the prime p further aggravating the issue. It is evident that the above approach
does not extend to the current version of CSI-FiSh, which requires the specific
CSIDH-512 parameter set.

The lossy identification protocol proposed in this work — which arises from
the observation that the D-CSIDH relation over the CSIDH-512 parameters nat-
urally admits a lossy mode — appears to be much simpler and it smoothly leads
to a practical signature scheme. Our identification protocol enjoys the same opti-
mizations used in [12] and [6]. Using D-CSIDH instead of GAIP as the underlying
assumption, we encounter an obstacle that stems from the fact that D-CSIDH
does not provide natural random self-reducibility properties. However, we dis-
cuss that this issue does not have much of a big impact on the concrete choice
of parameters.

Related Works. There are only a handful of efficient signature schemes that
are tightly and provably secure in the (Q)ROM that we are aware of. The
lattice-based Gentry-Peikert-Vaikuntanathan (GPV) signature [23] or its much-
optimized successor FALCON [20] have tight security in the (Q)ROM. One no-
table feature is that the construction natively supports tight security in both clas-
sical and quantum ROM without incurring any overhead. Dilithium [17], which
is a lattice-based FS-type signature, also has tight security in the (Q)ROM [27].
To achieve tight security, they must modify the public key of their non-tightly
secure scheme to obtain a lossy mode. Unfortunately, when using a lattice-based
hard problem (that is, the learning with errors problem), this comes at the cost



Lossy CSI-FiSh: Efficient and Tightly Secure Signature Scheme 5

of making the public key size at least 5 times larger and the signature size at least
2 times larger, e.g., public key and signature size grows from (1472, 2701) bytes
up to (7712, 5690) bytes. As we mentioned above, SeaSign [12] goes through
the lossy argument as well. They require to use of a non-standard variant of the
GAIP problem and makes it difficult to assess the increase in signature and pub-
lic key sizes. We like to highlight that although we go through the same paradigm
of lossy arguments, Lossy CSI-FiSh is based on a standard assumption and does
not incur a large blow up in size; the public key is only 2 times larger and the
signature size remains the same compared to the non-tight variant CSI-FiSh.
Finally, the hash-based signature SPHINCS+ [4] also enjoys tight security in the
(Q)ROM under several heuristic assumptions on the underlying cryptographic
hash function.

Roadmap. The rest of the paper is organized as follows. In Section 2 we give a
brief preliminary on identification protocols and class group actions. In Section 3
and 4 we introduce the new lossy identification protocol and we adapt it using the
optimizations proposed in [6,12] to enlarge the challenge space. In Section 5 we
describe the signature scheme obtained through the Fiat-Shamir transform, and
we compare it to CSI-FiSh in terms of bandwidth and computational complexity.
In Section 6 we report concluding remarks.

2 Preliminaries

2.1 Identification Protocols

Given two sets X and Y, a subset R ⊂ X × Y is a polynomially computable
binary relation on X × Y if, given (X,W) ∈ X × Y , we can check (X,W) ∈ R in
time poly(|X|). The language LR corresponding to R is the set {X ∈ X | ∃W ∈
Y : (X,W) ∈ R}, where we call W a witness for the statement X ∈ LR.

An identification protocol ID for a relation R is a three-move interactive pro-
tocol between a prover and a verifier. Informally, a prover holding a statement-
witness pair (X,W) ∈ R can prove to the verifier that they indeed possess a valid
witness W without revealing any more than the mere fact that they know W.

Definition 2.1 (Identification Protocol). An identification protocol ID for
a relation R consists of four PPT algorithms (IGen,P = (P1,P2),V), where V is
deterministic and we assume P1 and P2 share states. Let ComSet, ChSet, and
ResSet be the commitment space, challenge space, and response space, respec-
tively. Then, an identification protocol is defined in the following way.

– The key generation algorithm IGen takes the security parameter 1λ as input,
and outputs a statement-witness pair (X,W) ∈ R.

– The prover, on input (X,W), first executes com← P1(X,W), and then sends
the commitment com to the verifier.

– The verifier chooses a random challenge ch ← ChSet and sends ch to the
prover.



6 A. El Kaafarani et al.

– The prover, given ch, runs resp← P2(X,W, com, ch) and returns a response
resp to the verifier. Finally, the verifier runs V(X, com, ch, resp) and outputs
1 if they accept, 0 otherwise.

The protocol transcript (com, ch, resp) ∈ ComSet × ChSet × ResSet is said to be
valid in case V(X, com, ch, resp) outputs 1.

We require the following properties from an identification protocol ID. Some of
them may seem non-standard, however, they are all necessary to argue security
of the Fiat-Shamir transform in the (quantum) random oracle model. We note
that some of the properties are simplified and stronger than those in [27], e.g.
we ignore negligible correctness errors. This is done without loss of generality,
since our proposed identification protocol satisfies all the stronger properties.

Correctness. The following holds for all (X,W) ∈ R:

Pr

V(X, com, ch, resp) = 1

∣∣∣∣∣∣
com← P1(X,W),

ch← ChSet,
resp← P2(X,W, com, ch)

 = 1.

(Perfect) Honest-Verifier Zero-Knowledge (HVZK). There exists a PPT simu-
lator algorithm Sim that takes as inputs a statement X ∈ LR and a challenge
ch ∈ ChSet, and outputs a commitment com and a response resp such that
(com, ch, resp) is a valid transcript for X. Moreover, the output distribution of
Sim on input (X, ch) is equal to the distribution of those outputs generated via
an honest execution conditioned on the verifier using ch as the challenge. We
note we can consider relaxed variants of HVZK where the distributions are only
required to be computationally indistinguishable.

Min-Entropy. The identification protocol ID has Îą bits of min-entropy if

Pr
(X,W)←IGen(1λ)

[
min-entropy(com | com← P1(X,W)) ≥ α)

]
≥ 1− 2−α.

(Optional) Perfect Unique Response. With overwhelming probability over the

random choice of (X,W) ← IGen(1λ), for any com ∈ ComSet and ch ∈ ChSet,
there exists a unique response resp ∈ ResSet that leads to a valid transcript
(com, ch, resp). This property is required when aiming for strong unforgeabil-
ity (i.e., su-cma) of the FS signature scheme. As we will see, our identification
protocol supports this property by default.

(Optional) Commitment Revocability. With overwhelming probability over the

random choice of (X,W) ← IGen(1λ), for any ch ∈ ChSet and resp ∈ ResSet,
there exists a unique commitment com ∈ ComSet that makes (com, ch, resp) a
valid transcript. Such a commitment can be publicly computed by means of an
algorithm taking (X, ch, resp) as input. This property is unnecessary from a secu-
rity stand point and only allows for shorter signatures. Again, our identification
protocol supports this property by default.



Lossy CSI-FiSh: Efficient and Tightly Secure Signature Scheme 7

To achieve a tight security proof for Fiat-Shamir signatures (formally defined
later), we further require the identification protocol to satisfy some notion of
lossiness defined below.

Definition 2.2 (Lossy Identification Protocol). An identification protocol
ID is called lossy - and denoted by IDls - if it admits an extra PPT algorithm
LossyIGen, named lossy key generation algorithm, that on input 1Ν outputs Xls ∈
X \ LR.

We require a lossy identification protocol IDls to satisfy the following two prop-
erties.

Indistinguishability of Lossy Statements. We ask that a statement generated with
the lossy key generation algorithm is indistinguishable from a statement gener-
ated by the real key generation algorithm. Let us define the following advantage
for an adversary A:

AdvlossyA (λ) :=|Pr[A(Xls) = 1 | Xls ← LossyIGen(1λ)]−
Pr[A(X) = 1 | (X,W)← IGen(1λ)]|

We say the lossy identification protocol satisfies indistinguishability of lossy
statements if for any PPT (or quantum PT) adversary we have AdvlossyA (Îť) =
negl(Îť).

Statistical Lossy Soundness. The definition of statistical lossy soundness relies on
the following game, named lossy impersonation game, played by an adversary A
and a challenger.

Setup: The challenger runs Xls ← LossyIGen(1λ) and provides the adversary A
the lossy statement Xls.

Commitment and challenge selection: On input Xls the adversaryA selects
a commitment com ∈ ComSet and sends it to the challenger. The challenger
responds by returning a random challenge ch ∈ ChSet.

Output: A outputs a response resp ∈ ResSet. The adversary A wins the game
if (com, ch, resp) is a valid transcript for Xls.

We say IDls is Îľls-lossy sound if for any unbounded (possibly quantum) adversary
A the winning probability in the above game is less than Îľls.

2.2 Digital Signature Schemes

Here we introduce the definition of standard signature schemes.

Definition 2.3. A signature scheme ΠS consists of three PPT algorithms
(S.KeyGen,S.Sign,S.Vrfy) such that:

– S.KeyGen(1λ)→ (vk, sk): On input a security parameter 1λ, the key genera-
tion algorithm outputs a pair of verification and signing keys (vk, sk);



8 A. El Kaafarani et al.

– S.Sign(sk,M)→ σ: On input a signing key sk and a message M, the signing
algorithm outputs a signature σ;

– S.Vrfy(vk,M, σ) → 1/0: On input a verification key vk, a message M and a
signature σ, the verification key outputs 1 (accept) or 0 (reject).

We require a signature scheme ΠS to satisfy the following two properties.

Correctness. For every security parameter 1Ν, with Ν ∈ N, and every message M
the following holds:

Pr

[
S.Vrfy(vk,M, σ) = 1

∣∣∣∣ (vk, sk)← S.KeyGen(1λ),
σ ← S.Sign(sk,M)

]
= 1.

Unforgeability. We define the strong unforgeability under chosen message attack
su-cma by the following game played by an adversary A and a challenger.

Setup: The challenger runs (vk, sk)← S.KeyGen(1λ) and provides the adversary
A the verification key vk. It also prepares an empty set S = ∅.

Signing Queries: The adversary A may adaptively submit messages M to the
challenger. The challenger responds by returning σ ← S.Sign(sk,M) to A. It
then updates the set S ← S ∪ {(M, σ)}.

Output: Finally, A outputs a forgery (M∗, σ∗). We say the adversary A wins if
(M∗, σ∗) 6∈ S and S.Vrfy(vk,M∗, σ∗) = 1.

We define the advantage of A as the probability it wins the above game, that is,
Advsu-cma

A (1Îť) := Pr[A wins].

Definition 2.4 (Su-cma Security). We say a signature scheme ΠS is su-cma
secure if for all PPT adversaries A, we have Advsu-cma

A (Îť) = negl(Îť).

2.3 Pseudorandom Functions

Consider a mapping PRF : K×X → Y, where K is a key space. We say PRF is a
pseudorandom function if for all PPT (or quantum) adversaries, their advantage
defined below is negligible:

AdvPRFA (Îť) :=
∣∣∣Pr[APRF(K,·)(1λ) = 1 | K ← K]− Pr[ARF(·)(1λ) = 1]

∣∣∣ ,
where RF : X → Y is a perfect random function. In practice, any standard hash
function (e.g., SHA-3) is believed to be a (quantumly) secure PRF.

2.4 Fiat-Shamir Transformation

The original Fiat-Shamir transformation [1, 18] turns a (not necessarily lossy)
identification protocol ID into a digital signature scheme by means of a crypto-
graphic hash function H : {0, 1}∗ → ChSet modeled as a classical random oracle
(RO). For each parallel execution of ID, the challenge is obtained as H(com,M),
where M is the message to sign. Then the resulting digital signature σ is a t-tuple



Lossy CSI-FiSh: Efficient and Tightly Secure Signature Scheme 9

composed by t commitments and the corresponding responses, where t is set in
such a way that |ChSet|t is exponentially large. Recently, the Fiat-Shamir trans-
formation has been extended to the quantum random oracle model (QROM) as
well [16, 27,30].

In this work, we will be interested in Fiat-Shamir transformations for a spe-
cific type of identification protocol (namely, lossy identification protocol) which
admits tight security proofs. For a general identification protocol, it is well-known
that the Fiat-Shamir signature incurs a prohibitively large reduction loss: the
advantage of breaking the underlying hard problem degrades as O(Q−1 · ε2) in
the classical ROM and as O(Q−6 · ε3) in the quantum ROM, where Q is the
number or random oracle queries made by the adversary and Îľ is the advantage
against the Fiat-Shamir signature scheme.

The following result is taken from the recent work of Kiltz, Lyubashevsky,
and Schaffner [27].

Theorem 2.1. Assume the identification protocol ID is lossy, perfect HVZK,
has Îą bits of min-entropy, has perfect unique response, and is Îľls-lossy sound.
The Fiat-Shamir transformation provides a signature scheme such that, for any
quantum adversary A against su-cma security that issues at most QH queries to
the quantum random oracle, there exists quantum adversaries B and D such that

Advsu-cma
A (λ) ≤ AdvlossyB (λ) + 8(QH + 1)2 · εls + 2−α+1 + AdvPRFD (λ),

and Time(B) = Time(D) = Time(A) +QH ≈ Time(A).
In the classical setting, the only difference is that the bound depends linearly

on QH instead of quadratically.

The above theorem is obtained by derandomizing the Fiat-Shamir signature
by a pseudorandom function PRF and plugging it in Theorem 3.1 of [27]. We
note that some simplification to Theorem 3.1 of [27] is made since our proposed
lossy identification protocol achieves perfect HVZK and perfect unique response.

2.5 Class Group Actions and Hardness Assumption

The action of ideal class groups on elliptic curves was firstly proposed for crypto-
graphic purposes by Couveignes [9], and Rostovtsev and Stolbunov [35,38]. Their
approach was then revised by De Feo, Kieffer and Smith [14], who were unable to
turn it intro practicality despite the introduction of remarkable mathematically-
driven speed-ups. The efficiency issues were overcome by Castryck et al. [8], that
introduced the CSIDH key-exchange protocol restricting to supersingular elliptic
curves. In the following, we will give a brief background on ideal class groups and
their action on supersingular curves. For a more detailed overview we suggest
the consultation of [8] and Cox’s book [10].

Let Fp denote a prime field, with p being an odd prime. Given two elliptic
curves E,E′ defined over Fp, an isogeny ϕ : E → E′ is a non-constant mor-
phism mapping 0E to 0′E . Hence each coordinate of ϕ(x, y) can be expressed



10 A. El Kaafarani et al.

as a fraction of two polynomials belonging to Fp[x, y]. If their coefficients are
contained in Fp, then we say that ϕ is defined over Fp. A separable isogeny
(it induces a separable extension of function fields) having {0E} as kernel is an
isomorphism; an isogeny having the same domain and range is an endomorphism.

The set of all endomorphisms of an elliptic curve E, together with the zero map,
form a ring under pointwise addition and composition. Such a ring is called the
endomorphism ring of E and it is denoted by End(E). If End(E) is abelian, the
curve is said to be ordinary, otherwise it is said to be supersingular. The re-
striction Endp(E) to the endomorphisms defined over Fp constitutes a subring,
which is isomorphic to an order in the quadratic field K = Q(

√
−p). An order

is a subring of Q(
√
−p) which is also a finitely-generated Z-module containing

a basis of K as a Q-vector space. The set Z[
√
−p] = {m + n

√
−p | m,n ∈ Z}

satisfies the above three conditions and we will denote it by O. We then con-
sider the set E``p(O, π) containing all supersingular curves E defined over Fp -
modulo isomorphisms defined over Fp - such that there exists an isomorphism
between O and Endp(E) mapping

√
−p ∈ O into the Frobenius endomorphism

(x, y) 7→ (xp, yp). As shown in [8], each isomorphism class in E``p(O, π) can be
uniquely represented by a single element of Fp if p ≥ 5 is a prime such that p ≡ 3
(mod 8).

A fractional ideal a of O is a finitely generated O-submodule of K. When a is
contained in O, it is said to be integral; when a = ιO for some ι ∈ K, it is said
to be principal; when there exists another fractional ideal b such that ab = O, it
is called invertible. The invertible fractional ideals of O form an abelian group.
Its quotient by the subgroup composed by principal fractional ideals is a finite
group called ideal class group of O, usually denoted by C`(O). Its cardinality is
the class number of O.

The ideal class group C`(O) acts freely and transitively on the set E``p(O, π)
via the group action ?:

? : C`(O)× E``p(O, π)→ E``p(O, π)

(a, E) 7→ a ? E.

For simplicity, we will use representatives instead of equivalence classes to
denote elements of C`(O) and E``p(O, π). When p is of the form 4`1`2 · · · `s− 1,
whith `1, . . . , `s small odd primes, a special integral ideal I`i ⊂ O corresponds
to each prime `i. These ideals allow an easy computation of the group action.
In particular, the action of I`i on a curve E ∈ E``p(O, π) is determined by an
isogeny having as kernel the unique rational `i-torsion subgroup of E.

The general variant of the CSIDH key-exchange scheme relies on the heuris-
tic that the equivalence classes of the ideals I`1 , . . . ,I`s , together with their
inverses, generate the entire ideal class group C`(O). In [8], Castryck et al. pro-



Lossy CSI-FiSh: Efficient and Tightly Secure Signature Scheme 11

pose different sets of parameters for CSIDH, each of them supposedly achieving
a specific quantum security level. For the smallest5 set of parameters, named
CSIDH-512 since p ' 2512, the class group structure of C`(O) has been recently
computed by Beullens et al. [6]. They showed that C`(O) is a cyclic group of
odd order N , where N ' 2257.1 and C`(O) = 〈I3〉. As a consequence, this group
admits a canonical representation (as ZN ) and an efficient uniform sampling of
its elements. For simplicity, in the following we will denote by g the generator
I3.

Hardness Assumption. The group action inverse problem (GAIP) is the hard-
ness assumption originally introduced by [8], which underlies the security of both
SeaSign [12] and CSI-FiSh [6]. Although we will not directly use GAIP in our
construction, we provide it as a base point to compare the assumption we intro-
duce.

Definition 2.5 (Group Action Inverse Problem (GAIP)). Given two su-
persingular elliptic curves, E,E1 ∈ E``p(O, π), find an element a ∈ C`(O) such
that a ? E = E1.

3 Base Lossy Identification Protocol from CSIDH-512

The CSI-FiSh signature is obtained by applying the Fiat-Shamir transformation
to an identification protocol originally sketched by Couveignes [9] and Stolbunov
[39]. In this section, we introduce our base lossy identification protocol for any
set of CSIDH parameters for which the ideal class group C`(O) is cyclic, with a
known order N and generator g. We further discuss the corresponding hardness
assumption on which its security relies. Such a scheme considers an exponent
a ∈ ZN , the private key, and two pairs of curves, where the second pair, the
public key, is determined by the action of ga on the first pair. For the concrete
instantiation in Section 5, we use the CSIDH-512 parameters.

3.1 Hardness Assumption: Decisional CSIDH

We construct a lossy identification protocol based on the decisional CSIDH (D-
CSIDH) problem, originally defined by Stolbunov in his PhD thesis [39, Problem
2.2].

Definition 3.1 (Decisional CSIDH Problem). Given the set E``p(O, π) and
the ideal class group C`(O), the decisional CSIDH (D-CSIDH) problem asks to
distinguish between the following two distributions:

– (E,H, a?E, a?H), where the supersingular elliptic curves E and H are sam-
pled uniformly from E``p(O, π), while a is sampled uniformly from C`(O);

– (E,H,E′, H ′) where E,H,E′, H ′ are supersingular elliptic curves sampled
uniformly from E``p(O, π).

5 The parameter set having the smallest value for the prime p.



12 A. El Kaafarani et al.

We denote by AdvD-CSIDH
A (Îť) the advantage of an adversary A distinguishing the

two distributions. We say that the D-CSIDH assumption holds if for every PPT
(or possibly quantum) adversary A, AdvD-CSIDH

A (Îť) is negligible.

The D-CSIDH assumption forms the foundation of the security of the key
exchange protocol proposed by [8], called CSIDH. However, to be completely
accurate, the security of CSIDH not always is equivalent to the D-CSIDH prob-
lem we defined above. The reason for this is that when the structure of the ideal
class group is not known, we cannot properly sample a uniform ideal from C`(O)
(and hence a uniform elliptic curve from the set E``p(O, π)). Namely, in that
case, a party will sample an ideal that is heuristically shown to be close to uni-
formly random over C`(O). Then, to show security of CSIDH, we must assume
the hardness of D-CSIDH for that particular heuristically uniform distribution.
Notably, we do not get a reduction from the above D-CSIDH assumption defined
for truly uniform samples over C`(O). Hence, for the D-CSIDH assumption to be
useful both in a theoretical and practical sense, it is desirable to have an efficient
uniform sampler from the ideal class group C`(O). In this case, the security of
CSIDH will indeed be equivalent to the D-CSIDH assumption.

As for the definition of D-CSIDH, we would like to simply keep it agnostic to
the existence of an efficient sampler from the ideal class group C`(O). However,
throughout the paper, we will always consider a cyclic class group C`(O) with
known order and generator (i.e., the one derived from the CSIDH-512 parame-
ters) so as to be able to efficiently sample uniformly over C`(O).

3.2 Construction of Base Lossy Identification Protocol

The base lossy identification protocol we are going to describe requires ";"""date"",""2020-02-05T16:18:39Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""Lossy CSI-FiSh: Efficient Signature Scheme with Tight Reduction to Decisional CSIDH-512""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""Lossy CSI-FiSh: Efficient Signature Scheme with Tight Reduction to Decisional CSIDH-512""
""modified"",""2020-02-05T16:18:39Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""No Author Given""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.16 (TeX Live 2015) kpathsea version 6.2.1""
""meta:author"",""No Author Given""
""trapped"",""False""
""meta:creation-date"",""2020-02-05T16:18:39Z""
""created"",""2020-02-05T16:18:39Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-02-05T16:18:39Z""
""resourceName"",""download_file""
""Author"",""No Author Given""
""producer"",""pdfTeX-1.40.16""
""pdf:docinfo:producer"",""pdfTeX-1.40.16""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""3"",""1"",""0"",""0"",""8"",""2"",""13"",""8"",""35"",""26"",""21"",""20"",""31"",""13"",""30"",""20"",""21"",""45"",""14"",""46"",""15"",""11"",""11"",""10"",""13"",""1"",""0"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""No Author Given""
""dcterms:created"",""2020-02-05T16:18:39Z""
""Last-Modified"",""2020-02-05T16:18:39Z""
""dcterms:modified"",""2020-02-05T16:18:39Z""
""title"",""Lossy CSI-FiSh: Efficient Signature Scheme with Tight Reduction to Decisional CSIDH-512""
""Last-Save-Date"",""2020-02-05T16:18:39Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2020-02-05T16:18:39Z""
""meta:save-date"",""2020-02-05T16:18:39Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.16 (TeX Live 2015) kpathsea version 6.2.1""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""No Author Given""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""30""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""2004"",""2748"",""2548"",""2844"",""2323"",""2181"",""1833"",""1836"",""2419"",""2282"",""2137"",""2382"",""1517"",""2163"",""2037"",""2223"",""2195"",""2076"",""1742"",""2268"",""1675"",""2194"",""1374"",""2025"",""1823"",""2134"",""2297"",""2436"",""2794"",""1940""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-02-05T16:18:39Z""
";https://scholar.google.ch/scholar?start=760&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098818-228;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;An Efficient Blind Signature Scheme with Untraceability for Data Privacy in Smart Grid;W Zhang, C Lin, Z Lyu, C Cen, M Luo ; International Conference on …, 2020  Springer;;"… Denote the times of \(\mathcal {A}_{unf}\) invoking the above oracles as \(n_{s1 … m^*, (h_2^*, s_2^*))\

via restarting the above simulation with setting the random oracle as \(h_2 … D., Bhuiyan, MZA, Lee,

I.-Y.: An anonymous protocol for member privacy in a consortium blockchain …";;null;null;;;;https://scholar.google.ch/scholar?start=770&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098826-247;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Triptych: logarithmic-sized linkable ring signatures with applications;S Noether, B Goodell ; … Management, Cryptocurrencies and Blockchain …, 2020  Springer;;"… signatures are typically included in a public distributed data structure like a blockchain, there

is a … In the random oracle model, extraction of a witness of the form \(r_0 + \sum … A., Katz, J.,

Morselli, R.: Ring signatures: stronger definitions, and constructions without random oracles …";Cité 4 fois;Les 2 versions;[PDF] iacr.org;https://eprint.iacr.org/2020/018.pdf;"
Triptych: logarithmic-sized linkable ring signatures with

applications

Sarang Noether and Brandon Goodell
Monero Research Lab

{sarang,surae}.noether@protonmail.com

August 26, 2020

Abstract

Ring signatures are a common construction used to provide signer ambiguity among a non-interactive
set of public keys specified at the time of signing. Unlike early approaches where signature size is linear
in the size of the signer anonymity set, current optimal solutions either require centralized trusted setups
or produce signatures logarithmic in size. However, few also provide linkability, a property used to
determine whether the signer of a message has signed any previous message, possibly with restrictions on
the anonymity set choice. Here we introduce Triptych, a family of linkable ring signatures without trusted
setup that is based on generalizations of zero-knowledge proofs of knowledge of commitment openings to
zero. We demonstrate applications of Triptych in signer-ambiguous transaction protocols by extending
the construction to openings of parallel commitments in independent anonymity sets. Signatures are
logarithmic in the anonymity set size and, while verification complexity is linear, collections of proofs
can be efficiently verified in batches. We show that for anonymity set sizes practical for use in distributed
protocols, Triptych offers competitive performance with a straightforward construction.

1 Introduction

First introduced in [21] with respect to RSA groups, ring signatures permit the signing of messages using
public key sets not fixed in advance, without the need of a trusted group manager. Earlier constructions
lacked such flexibility, requiring either centralized key setup or the establishment of fixed signing sets.
Later work [2] established more robust security models for unforgeability and anonymity, capturing realistic
threat models where an adversary is permitted to corrupt keys, convince honest signers to include malicious
anonymity set members, or obtain signatures in advance.

Since a ring signature has an anonymity set of public keys, one of which is the true signer, the detection
of signing by the same key requires an additional property, linkability. A linkable ring signature [16] enables
verifiers to determine whether the (unknown) signer of a message has signed other messages. Such a construc-
tion was proposed for election applications, where it is necessary to ensure that votes are anonymous, but
voters are permitted to vote only once on a particular issue. The construction in [16], with a hash-trapdoor
structure similar to that of [22], is of particular interest due to potential flexibility in linking; while its linking
is limited to signer-selected but unchanging signer anonymity sets, it permits linking on a per-issue basis.
Additional recent work in [1] introduces the property of linkable anonymity, using sets of signatures and
establishing restrictions on key corruption. Other related interesting properties like traceability [9, 8] imply
stronger capabilities, where an attempt to sign two messages with the same key permits verifiers to identify
the signer.

Linkable ring signatures have seen particular applications in signer-ambiguous transaction protocols. In
such an application, transactions are authorized by a ring signature whose signing anonymity set consists
of previously-generated transaction outputs. A signature demonstrates that the signer controls the private
key of one such output without revealing which is the signer, and linkability is used to assure verifiers that
output has not been used in another signature (signifying a double-spend attempt).

A practical consideration for the use of linkable ring signatures in transaction protocols is how signature
size and verification time scale with the size of the anonymity set. In common applied constructions like

1



[19, 10], signature size and verification time scale linearly with the size of the signing ambiguity set; since such
signatures are typically included in a public distributed data structure like a blockchain, there is a balance
between the size of the anonymity set and the requirements for storage and verification. Recent protocol
work in this area mitigates the size restriction. For example, in [24], the authors introduce a confidential
transaction protocol based on a proving system whose size scales logarithmically with the anonymity set
size, and which includes a method for demonstrating amount balance; amount commitment range proving
is offloaded to other constructions like [4]. In [15], the authors use a more general proving technique to
accomplish a similar goal; however, the protocol offers further size benefits by integrating commitment range
proofs into the proof structure directly, taking advantage of the logarithmic proof size.

Other signer-ambiguous transaction protocols not based on linkable ring signatures offer more competitive
performance. For example, protocols like [13] produce maximal theoretical signer ambiguity through the use
of zero-knowledge Merkle proofs (among others) that offer extremely small proofs with low verification time,
but at the cost of a trusted structured setup process that arises from the underlying proving system [11]. Like
this work, [14] is a transaction protocol also based on [12]; however, it is intended to operate on commitments
similar to those used in [18] but with the inclusion of amounts, and has limitations on addressing and sender
tracing.

1.1 Our contribution

We produce a family of linkable ring signatures, which we call Triptych. The constructions are a linkable
generalization of Groth’s one-of-many commitment-to-zero proving system [12], with optimizations from
Bootle [3] applied for improvements to proof size and verification complexity. In the simplest version of
Triptych, the prover shows that it knows the opening of a commitment to zero within a commitment set,
and also that it has constructed a linking tag using the same opening, producing a linkable ring signature
construction. We then modify Groth’s ring signature definitions to include linkability and a related property,
non-frameability.

In an extension of Triptych, we include multiple independent sets of commitments. Here, the prover
proceeds as before to show its knowledge of an opening to a commitment in one set, as well as the construction
of the linking tag. However, the proof also shows that the prover knows an opening of a commitment at
the same position in all other sets. This construction has immediate application; in some signer-ambiguous
confidential transaction protocols, transaction inputs are commitments to zero, for which the signer shows
it knows the opening. Each commitment comes equipped with another commitment to the amount of the
input; by offsetting these commitments homomorphically and carefully choosing commitment randomness,
the prover can show that a particular transaction balances.

We show that Triptych produces signatures with competitive performance to other modern linkable ring
signatures for limited anonymity set sizes. We note that similar constructions also require linear verification
time, meaning that the size of anonymity set used in practice is likely to be limited for performance reasons.

2 Preliminaries

2.1 Public parameters

Let G be a cyclic group in which the discrete logarithm problem is hard, and let F be the scalar field of G. Let
H : {0, 1}∗ → F be a cryptographic hash function. Let G and H be generators of G with unknown discrete
logarithm relationship. Let N = nm be a size parameter, where n > 1 and m > 1. Let {Gj,i}m−1,n−1j,i=0 be
a set of generators of G with unknown discrete logarithm relationship to each other, to G, and to H. Let
U be a generator of G. Note that all generators may be produced using public randomness; for example,
the use of a suitable hash function with domain separation may be appropriate. All such public parameters
are assumed to comprise a global reference string known to all players; in particular, we exclude them from
algorithm definitions and Fiat-Shamir transcript hashes for readability.

2



2.2 Pedersen commitment

Let Com be a homomorphic commitment scheme that is perfectly hiding and computationally binding. In
this work, we assume use of the Pedersen commitment scheme: for x, r ∈ F, define Com(x, r) ≡ xG + rH
to be the commitment of the value x with randomness r. This can be trivially extended to support matrix
values; for {xj,i}, r ∈ F, define Com(x, r) ≡ rH +

∑
j,i xj,iGj,i. Note in particular that Pedersen matrix

commitments are similarly homomorphic.

2.3 Other notation

For integers or field elements i, j, the Kronecker delta function δ(i, j) evaluates to 1 if i = j and 0 otherwise,
where the output is taken to be in the appropriate set.

We sometimes use index subscript notation of the form ij to indicate the j digit of i, where such a
decomposition of i is taken base n with padded length m:

m∑
j=0

ijn
j = i

This notation will be specified explicitly where confusion may occur.

3 Protocol: linkable one-of-many commitment

We wish to build a linkable ring signature construction, where a signer who knows the opening of a commit-
ment may sign messages using an anonymity set containing other commitments for which the signer does
not know openings. Included with the proof of knowledge, the signer also provides a linking tag that is the
image of the signing commitment’s opening under a verifiable pseudorandom function, using the method of
[6] that has previously appeared in [15, 24]. Part of the soundness of the proving system relies on the proper
construction of this linking tag. Upon receipt, a verifier can check whether the linking tag has previously
appeared in any other valid proof; if it has not, injectivity assures the verifier that no other signature has
been produced by the (unknown) signer.

More specifically, we modify the construction of Bootle [3], which itself is a generalization of a construction
by Groth [12]. We produce a sigma protocol for the following relation:

Rlink =
{
{Mi}N−1i=0 ⊂ G, J ∈ G; (l ∈ Z, r ∈ F) : Ml = rG and U = rJ

}
Figures 1 and 2 describe the protocol.

Observe that this protocol can be made non-interactive using the Fiat-Shamir heuristic, where the verifier
challenge is produced using a collision-resistant hash function (modeling a random oracle) and the proof
transcript [7].

We will show that the sigma protocol is complete, sound, and zero-knowledge, the precise definitions of
which are common and found in [12]. Informally, we require the protocol be:

• Perfectly complete: Given knowledge of a witness to a statement in the proof relation, an honest prover
can always convince an honest verifier of the validity of the witness.

• Special sound : Given a statement in the proof relation, if a prover can answer multiple verifier challenges
correctly, then it is possible to extract a witness for this statement.

• Special honest-verifier zero knowledge: Given any statement and verifier challenge, it is possible to
simulate a transcript that is accepted by an honest verifier without knowledge of a corresponding
witness.

Theorem 1. The protocol in Figures 1 and 2 is perfectly complete, special honest-verifier zero knowledge,
and (m+ 1)-special sound.

3



Plink({Mi}, J ; (l, r)) :

• Select random rA ∈ F and {aj,i}n−1,m−1i=1,j=0 ⊂ F. Set

{aj,0}m−1j=0 ≡ −
n−1∑
i=1

aj,i

and define A ≡ Com(a, rA).

• Define {σj,i}n−1,j−1i,j=0 ⊂ F such that σj,i ≡ δ (lj , i) (using our decomposition notation), and choose

random rB ∈ F. Define B ≡ Com(σ, rB).

• Select random rC ∈ F, and define C ≡ Com(a(1− 2σ), rC).

• Select random rD ∈ F, and define D ≡ Com(−a2, rD).

• Define coefficients {pk,j}N−1,m−1k,j=0 such that

pk(x) ≡
m−1∏
j=0

(σj,kx+ aj,k) = δ (l, k)xm +

m−1∑
j=0

pk,jx
j

for all k ∈ [0, N) (using our decomposition notation).

• Select random {ρj}m−1j=0 ⊂ F.

• Define {Xj}m−1j=0 ⊂ G such that:

Xj ≡
N−1∑
k=0

pk,jMk + ρjG

• Define {Yj}m−1j=0 ⊂ G such that:

Yj ≡ U
N−1∑
k=0

pk,j + ρjJ

P → V :
A,B,C,D, {Xj}, {Yj}

V → P :
ξ ∈ {0, 1}∗

P(Ξ) :

• Define {fj,i}n−1,m−1i=1,j such that fj,i ≡ σj,iξ + aj,i.

• Define zA ≡ rA + ξrB and zC ≡ ξrC + rD.

• Define z ≡ rξm −
∑m−1
j=0 ρjΞ

j .

P → V :
{fj,i}m−1,n−1j=0,i=1 , zA, zC , z

Figure 1: Sigma protocol for Rlink

4



Vlink({Mi}, J) :

• For 0 ≤ j < m, let fj,0 ≡ ξ −
∑n−1
i=1 fj,i.

• Accept if and only if:

A+ ΞB = Com(f, zA) (1)

ξC +D = Com(f(ξ − f), zC) (2)

N−1∑
k=0

Mk

m−1∏
j=0

fj,kj

− m−1∑
j=0

ξjXj − zG = 0 (3)

U

N−1∑
k=0

m−1∏
j=0

fj,kj

− m−1∑
j=0

ξjYj − zJ = 0 (4)

Figure 2: Sigma protocol for Rlink (continued)

Proof. The proof follows similarly to that of [3].
We first show perfect completeness. Suppose the verifier receives a proof generated by an honest prover.

Equation 1 holds using the identity
n−1∑
i=0

σj,i = 1

for all 0 ≤ j < m. Equation 2 follows similarly, using the identity

(σj,i)
2

= σj,i

for all 0 ≤ j < m. To show Equation 3 holds:

N−1∑
k=0

Mk

m−1∏
j=0

fj,kj

− m−1∑
j=0

ξjXj − zG

=

N−1∑
k=0

Mkpk(ξ)−
m−1∑
j=0

Ξj

(
N−1∑
k=0

pk,jMk + ρjG

)
− zG

=

N−1∑
k=0

Mk

pk(ξ)−
m−1∑
j=0

Ξjpk,j

− m−1∑
j=0

ξjρjG− zG

=

N−1∑
k=0

MkΞ
mδ(l, k)−

m−1∑
j=0

ξjρjG−

rξm − m−1∑
j=0

ρjΞ
j

G

= ξmrG−
m−1∑
j=0

ξjρjG− ξmrG+

m−1∑
j=0

ΞjρjG

= 0

5



Equation 4 follows similarly:

U

N−1∑
k=0

m−1∏
j=0

fj,kj

− m−1∑
j=0

ξjYj − zJ

= U

N−1∑
k=0

pk(ξ)−
m−1∑
j=0

Ξj

(
U

N−1∑
k=0

pk,j + ρjJ

)
− zJ

= U

N−1∑
k=0

pk(ξ)−
m−1∑
j=0

Ξjpk,j

− m−1∑
j=0

ξjρjJ − zJ

= U

N−1∑
k=0

ξmδ(l, k)−
m−1∑
j=0

ξjρjJ −

rξm − m−1∑
j=0

ρjΞ
j

 J

= ξmU −
m−1∑
j=0

ξjρjG− ξmrJ +

m−1∑
j=0

ΞjρjG

= 0

since J = r−1U in a valid proof. Hence the protocol is perfectly complete.
We next show that the protocol is special honest-verifier zero knowledge. To do so, we construct a

simulator that, given a random verifier challenge Ξ, can construct a proof transcript with identical distribution
to a valid proof.

First, observe that the simulator presented in the proof of Lemma 1 in [3] translates identically to our
setting. If the simulator chooses B ∈ G uniformly at random, the cited lemma assures us a valid simulation

of the proof elements A,C,D, zA, zC , {f (u)j,i 6=0}; we may compute each f
(u)
j,0 from this. Further, in a valid proof,

B is independent and uniformly distributed as well.
The proof elements {Xj}m−1j=1 and {Yj}m−1j=1 are independent and uniformly distributed in a valid proof

since the set {ρj} is random and the discrete logarithm problem in G is hard, so the simulator may choose
these uniformly at random. The verification checks require that X0 and Y0 be uniquely determined by the
other elements in the corresponding sets in both real proofs and by the simulator.

Finally, z is uniformly distributed in valid proofs given random Ξ, so the simulator may choose it uniformly
at random. Hence the construction is special honest verifier zero-knowledge.

It remains to show that the protocol is (m+1)-special sound, where m > 1. To show this, we construct an
extractor that, given m+1 valid responses to m+1 distinct verifier challenges for the same initial statement,
produces a valid witness.

Suppose that for a given statement, we have a set ofm+1 distinct verifier challenges {Ξe}me=0 corresponding
to unique valid responses of this form: {

{f (e)j,i }, {ze}
}m
e=0

From the 3-special soundness in [3] and m > 1 we have valid extractions {σj,i}m−1,n−1j,i=0 and {aj,i}m−1,n−1j,i=0 ,
and the Pedersen binding property ensures that (with high probability) we have:

f
(e)
j,i = σj,iΞe + aj,i

for all e ∈ [0,m]. Using the extracted values, compute

pk(ξ) ≡
m−1∏
j=0

(σj,kΞ + aj,k)

for all k ∈ [0, N). Extraction of {σj,i}m−1,n−1j,i=0 immediately yields the signing index l.

We have seen that pk is of degree m only when k = l. Hence there exist coefficients {Xj , Y j}m−1j=0 ,
computed uniquely from the statement and extracted values, such that Equations 3 and 4 are of the following

6



form:

ΞmMl +

m−1∑
j=0

ΞjXj = zG

ΞmU +

m−1∑
j=0

ΞjY j = zJ

Construct a Vandermonde matrix V where the e row is the vector (1, Ξe, . . . , Ξ
m
e ). Since all Ξe are distinct,

the rows of V span Fm+1; hence there exist weights {θe}me=0 such that the resulting linear combination of
rows produces the vector (0, . . . , 0, 1). That is,

∑m
e=0 θeΞ

j
e = δ(j,m).

For each of the previous two equations, we can therefore build a linear combination over e. For the first:

Ml =

m∑
e=0

θeΞ
m
e Ml +

m∑
e=0

θe

m−1∑
j=0

ΞjeXj

 =

(
m∑
e=0

θeze

)
G

Hence we extract r ≡
∑m
e=0 θeze. For the second:

U =

m∑
e=0

θeΞ
m
e U +

m∑
e=0

θe

m−1∑
j=0

ΞjeXj

 =

(
m∑
e=0

θeze

)
J

This implies that rJ = U , as required. Hence the protocol is (m + 1)-special sound, which completes the
proof.

4 Security: linkable ring signature

Informally, a linkable ring signature is a construction permitting signatures on messages using a signer-
selected anonymity set (called a ring) of possible signers. A valid signature convinces a verifier that the
signer knows (at least) one of the private keys to a ring member. The construction is linkable if it is
possible to determine whether two signatures were generated using the same private key, regardless of the
ring members used.

We use the security definitions in [12] as a starting point, directly adopting definitions for correctness and
unforgeability that also appear in more recent work like [1]. However, we modify the definition of anonymity
to account for linking tags, such that the adversary is required to differentiate between at least two possible
honest signers that the adversary has not corrupted. To account for the linking properties desired in our
construction, we use the clever linkability definition from [1], which uses a set-theoretic approach. We use a
straightforward definition for non-frameability, where the adversary produces a target signature on an honest
key after receiving signing and corruption oracle access, and must then produce a new signature that links.

More formally, a linkable ring signature (LRS) construction is a set of algorithms KeyGen, Sign, Verify,
and Link satisfying certain properties. A set of public parameters is assumed to be available to each algo-
rithm.

• KeyGen(r) → (x,X): Generates a secret key x and corresponding public key X, optionally using
randomness r; if not specified, the secret key is sampled uniformly at random.

• Sign(x,M,R) → σ: Generates a signature σ on a message M ∈ {0, 1}∗ with respect to the ring
R = {X1, . . . , Xn}, provided that x is a secret key corresponding to some Xi ∈ R generated by
KeyGen.

• Verify(σ,M,R)→ {0, 1}: Verifies a signature σ on a message M with respect to the ring R. Outputs
0 is the signature is rejected, and 1 if accepted.

7



• Link(σ, σ′)→ {0, 1}: Determines if signatures σ and σ′ were signed using the same private key. Outputs
0 if the signatures were signed using different private keys, and 1 if they were signed using the same
private key.

We require that an LRS have the properties of correctness, anonymity, unforgeability, linkability, and
non-frameability.

Correctness requires that a signature generated honestly will always verify.

Definition 1 (Correctness). Consider this game between a challenger and a probabilistic polynomial-time
adversary A:

• The challenger runs KeyGen→ (x,X) and supplies the keys to A.

• The adversary A chooses a ring such that X ∈ R and a message M ∈ {0, 1}∗, and sends them to the
challenger.

• The challenger signs the message with Sign(x,M,R)→ σ.

If Pr[Verify(σ,M,R) = 1] = 1, we say that the LRS is perfectly correct.

Note that we do not require any ring members (except for X) to have been generated by KeyGen. How-
ever, distributed applications may in practice place additional restrictions on public keys used in anonymity
sets. This allows for the possibility that A maliciously chooses ring members.

Unforgeability requires that an adversary who does not control the private key to a ring member cannot
generate a valid signature on any message using that ring.

Definition 2 (Unforgeability). Consider this game between a challenger and a probabilistic polynomial-time
adversary A:

• The adversary A is granted access to a public-key oracle GenOracle that (on the ith invocation) runs
KeyGen→ (xi, Xi) and returns Xi to A.

• The adversary A is granted access to a corruption oracle CorruptOracle(i) that returns xi if it corre-
sponds to a query to GenOracle.

• The adversary A is granted access to a signing oracle SignOracle(X,M,R) that runs Sign(x,M,R)→ σ
and returns σ to A, provided that X corresponds to a query to GenOracle and X ∈ R.

• Then, A outputs (σ,M,R) such that SignOracle was not queried with (−,M,R), all keys in R were
generated by queries to GenOracle, and no key in R was corrupted by CorruptOracle.

If Pr[Verify(σ,M,R) = 1] ≈ 0, we say that the LRS is unforgeable with respect to insider corruption.

Anonymity requires that as long as a ring contains at least two members that have not been corrupted,
an adversary can do no better than guessing at determining the signer of an honest signature.

Definition 3 (Anonymity). Consider this game between a challenger and a probabilistic polynomial-time
adversary A:

• The adversary A is granted access to the public-key oracle GenOracle and the corruption oracle
CorruptOracle.

• The adversary A chooses a message M ∈ {0, 1}∗, a ring R, and indices i0 and i1, and sends them to the
challenger. We require that Xi0 , Xi1 ∈ R such that both keys were generated by queries to GenOracle,
and neither key was queried to CorruptOracle.

• The challenger selects a uniformly random bit b ∈ {0, 1}, generates the signature Sign(xib ,M,R)→ σ,
and sends it to A.

• The adversary A chooses a bit b′ ∈ {0, 1}.

8



If Pr[b′ = b] ≈ 1/2 and A did not make any corruption queries after receiving the challenge bit, we say that
the LRS is anonymous.

We observe that this definition permits the adversary to have corrupted or maliciously generated all but
two keys in the ring. Some definitions allow the adversary to corrupt more keys, but we will see that this is
inconsistent with our linkability construction, where an adversary in control of a ring member’s private key
can trivially determine if it was the signer by examining the linking tag associated to a signature.

Linkability requires that an adversary be unable to produce k + 1 non-linked signatures on a combined
anonymity set of k public keys.

Definition 4 (Linkability). Consider the following game between a challenger and a probabilistic polynomial-
time adversary A:

• For i ∈ [0, k − 1], the adversary A produces a public key Xi, message Mi, ring Ri, and signature σi.

• The adversary A produces another message M, ring R, and signature σ.

• All tuples (Xi,Mi, Ri, σi) and (M,R, σ) are sent to the challenger.

• The challenger checks the following:

– |V | = k, where V ≡
⋃k−1
i=0 Ri.

– Each Xi ∈ V .

– Each Ri ⊂ V .

– Verify(σi,Mi, Ri) = 1 for all i.

– Verify(σ,M,R) = 1.

– For all i 6= j, we have Link(σi, σj) = Link(σi, σ) = 0.

• If all checks pass, A wins.

If A wins with only negligible probability for all k, we say the LRS is linkable.

Non-frameability requires that an adversary be unable to generate a signature that links with an honest
signature.

Definition 5 (Non-frameability). Consider also the following game between a challenger and a probabilistic
polynomial-time adversary A:

• The adversary A is granted access to the public-key oracle GenOracle.

• The adversary A is granted access to the corruption oracle CorruptOracle.

• The adversary A is granted access to the signing oracle SignOracle.

• The adversary A chooses a public key X that was generated by a query to GenOracle, but was not
presented as a query to CorruptOracle. It selects a message M ∈ {0, 1}∗ and ring R such that X ∈ R.
It queries SignOracle(X,M,R)→ σ.

• The adversary A then produces a tuple (M ′, R′, σ′) and sends (M ′, R′, σ′) to the challenger, along with
(X,M,R, σ).

• If Verify(σ′,M ′, R′) = 0 or if σ′ was produced using a query to SignOracle, the challenger aborts.

If Pr[Link(σ, σ′) = 1 ≈ 0, we say that the LRS is non-frameable.

9



KeyGen(r) :

• If not specified, select r ∈ F uniformly at random.

• Compute R = rG.

• Return (x,X) = (r,R).

Sign(x,M,R) :

• Let R = {X0, . . . , XN−1} such that Xl = xlG.

• Compute J ≡ x−1l U .

• Run Plink(R, J ; (l, xl))→ a (up to the verifier challenge).

• Set ξ ≡ H(M,R, a).

• Run Plink(ξ)→ z (after the verifier challenge).

• Return σ = (a, z, J).

Verify(σ,M,R) :

• Let R = {X0, . . . , XN−1} such that Xl − xlG.

• Let σ = (a, z, J).

• Set ξ ≡ H(M,R, a).

• Return Vlink(R, J, a, z).

Link(σ, σ′) :

• We implicitly assume that σ and σ′ have been previously verified.

• Let σ = (a, z, J) and σ′ = (a′, z′, J ′).

• If J = J ′, return 1. Otherwise, return 0.

Figure 3: Linkable ring signature using Rlink

10



5 Application: linkable ring signature

The constructions in [12, 3] describe how to use a similar sigma protocol to construct a simple ring signature
scheme. Using our modifications, we can easily extend this to account for linkability and non-frameability.
We briefly show how to do so.

Theorem 2. The protocol in Figure 3 is a linkable ring signature construction.

Proof. Perfect correctness follows immediately from the perfect completeness of the proving system forRlink.
Similarly, anonymity follows since the proving system is special honest-verifier zero knowledge, and

therefore witness indistinguishable [5]. Any adversarial advantage in breaking anonymity must therefore
arise from distinguishing either input commitments or linking tags in signatures. Since honestly-generated
input Pedersen commitments are perfectly hiding, they are indistinguishable from elements of G selected
uniformly at random; we assume by definition that at least two such commitments are present in such a
signature. Further, honestly-generated linking tags are generated from a one-way pseudorandom function,
and therefore in the random oracle model are independently uniformly distributed from other proof elements
and input commitments.

The proof for unforgeability in [12] relies on the (special) soundness of the underlying sigma protocol; it
applies directly to our modification for Rlink, and is not repeated here.

To show linkability, observe first that Link simply compares linking tags, so two signatures link if and only
if they share a common linking tag. Suppose an adversary can win the linkability game with non-negligible
probability for some k > 1. Since all provided signatures verify, soundness implies extraction of a witness
xi from signature σi for all i, and of a witness x from σ. Note that all {xi} and x are distinct. If xi = xj
for i 6= j, then the corresponding linking tags Ji and Jj are such that xiJi = xjJj = U ; then Ji = Jj ,
which contradicts Link(σi, σj) = 0. The same reasoning holds to show x is similarly distinct. Soundness
also implies that for all i, there exists Xi ∈ Ri such that xiG = Xi; similarly, there exists X ∈ R such that
xG = X. By assumption we have

{X0, . . . , Xk−1, X} ⊂

(
k−1⋃
i=0

Ri

)
∪R ⊂ V.

However, note that |{X0, . . . , Xk−1, X}| = k + 1, but that |V | = k, a contradiction.
Finally, we show non-frameability and assume an adversary has a non-negligible advantage in breaking

this property. Because we have Verify(σ′,M ′, R′) = 1, soundness implies extraction of a witness x′ ∈ F such
that x′G ∈ R′; we also have a witness x such that xG ∈ R from the known signature σ. Since Link(σ, σ′) = 1,
the corresponding linking tags J and J ′ are equal by definition; hence by soundness xJ = x′J ′ = U , giving
x = x′. However, the adversary did not query CorruptOracle with X, meaning it breaks the discrete
logarithm problem non-negligibly.

6 Protocol: parallel linkable one-of-many commitment

In this section, we describe a modification of the sigma protocol for Rlink that permits us to prove knowledge
of multiple commitments in d > 1 separate sets at the same index position, while retaining the linking
property in the first commitment set only. This forms a version of Triptych with the same functionality as
the d-linkable ring signature construction in [10], although the precise security model is a bit different. We
later show how to apply such a construction to a signer-ambiguous transaction protocol that can demonstrate
balance preservation.

We wish to produce a sigma protocol for the following relation, for some given vector dimension d > 1.

Rpar =
{
{Mi,α}N−1,d−1i,α=0 ⊂ Gd, J ∈ G;

(
l, {rα}d−1α=0

)
: {Ml,α = rαG}d−1α=0 and U = r0J

}
This requires only minor modifications to the protocol for Rlink, so we document only the modified proof
elements constructed and verified in Figure 4. All other proof elements are generated and verified identically.

Theorem 3. The protocol in Figure 4 is perfectly complete, special honest-verifier zero knowledge, and
(m+ 1)-special sound.

11



Ppar ({Mi,Îą}, J ; (l, {rÎą})) :

• Define Kα ≡ rαJ for α ∈ (0, d).

• Define µα ≡ H (α, {Mi,α}, J, {Kα}) for α ∈ (0, d).

• Define {Xj}m−1j=0 ⊂ G such that:

Xj ≡
N−1∑
k=0

pk,j

(
Mk,0 +

d−1∑
Îą=1

¾ιMk,ι

)
+ ρjG

• Define {Yj}m−1j=0 ⊂ G such that:

Yj ≡

(
U +

d−1∑
Îą=1

¾ιKι

)
N−1∑
k=0

pk,j + ρjG

P → V :
{KÎą}, {Xj}, {Yj}

V → P :
ξ ∈ {0, 1}∗

P(Ξ) :

• Define z ≡
(
r0 +

∑d−1
ι=1 ¾ιrι

)
ξm −

∑m−1
j=0 ρjΞ

j .

P → V :
z

Vpar({Mi,Îą}, J) :

• Define µα ≡ H (α, {Mi,α}, J, {Kα}) for α ∈ (0, d).

• Accept if and only if:

N−1∑
k=0

(
Mk,0 +

d−1∑
Îą=1

¾ιMk,ι

)m−1∏
j=0

fj,kj

− m−1∑
j=0

ξjXj − zG = 0

(
U +

d−1∑
Îą=1

¾ιKι

)
N−1∑
k=0

m−1∏
j=0

fj,kj

− m−1∑
j=0

ξjYj − zJ = 0

Figure 4: Sigma protocol (abbreviated) for Rpar

12



Proof. In the random oracle model, extraction of a witness of the form r0 +
∑
ι ¾ιrι implies knowledge of

all {rÎą} such that rÎąG = Ml,Îą, similarly to the key-aggregation arguments in [17]. The same extraction
shows that (r0 +

∑
ι ¾ιrι) J = U +

∑
ι ¾ιKι, which implies in particular that r0J = U , as required.

The rest of the proof follows with only trivial modifications from the proof for Rlink.

7 Application: signer-ambiguous transaction protocol

The parallel construction described in Figure 4 can be used with d = 2 in a signer-ambiguous transaction
protocol.

Suppose a user wishes to generate a transaction consuming W previously-generated outputs and gener-
ating T fresh outputs. The user shuffles the consumed outputs within a larger list of N outputs {Mk,0}N−1k=0 ,

such that there exist indices {lu}W−1u=0 where each Mlu,0 = ru for some known private key ru. Further, assume
each Mlu,0 comes equipped with an amount commitment of the form Mlu,1 ≡ Com(au, su) for amount au
and mask su. (All other Mk,0 also come equipped with a corresponding Mk,1, but the structure of these
points is not relevant here.)

The user generates W auxiliary commitments P ′u ≡ Com(au, s
′
u) to the same amounts, but with different

masks {s′u} chosen uniformly at random from F. Then, the user generates W spend proofs, each using the
following prover inputs for u ∈ [0,W ):

Ppar({Mk,0}N−1k=0 , {Mk,1 − P ′u}N−1k=0 , r
−1
u U ; (lu, ru, su − s′u))

For j ∈ [0, T ), the user generates a fresh output of the form Qj ≡ Com(bj , tj) for amount bj and mask
tj . The masks are chosen such that for j ∈ [1, T ), we have tj chosen uniformly at random from F. We then
choose

t0 ≡
W−1∑
u=0

s′u −";"""date"",""2020-08-26T19:25:01Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2020-08-26T19:25:01Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.19 (TeX Live 2018) kpathsea version 6.3.0""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2020-08-26T19:25:01Z""
""created"",""2020-08-26T19:25:01Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-08-26T19:25:01Z""
""resourceName"",""018.pdf""
""Author"",""""
""producer"",""pdfTeX-1.40.19""
""pdf:docinfo:producer"",""pdfTeX-1.40.19""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""4"",""6"",""24"",""20"",""16"",""3"",""14"",""7"",""19"",""24"",""15"",""0"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2020-08-26T19:25:01Z""
""Last-Modified"",""2020-08-26T19:25:01Z""
""dcterms:modified"",""2020-08-26T19:25:01Z""
""title"",""""
""Last-Save-Date"",""2020-08-26T19:25:01Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2020-08-26T19:25:01Z""
""meta:save-date"",""2020-08-26T19:25:01Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.19 (TeX Live 2018) kpathsea version 6.3.0""
""Content-Length"",""312384""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""16""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""3295"",""3573"",""2594"",""764"",""731"",""2147"",""2244"",""2475"",""1936"",""538"",""3346"",""519"",""3035"",""2004"",""2939"",""1726""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-08-26T19:25:01Z""
";https://scholar.google.ch/scholar?start=790&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098756-83;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;[PDF][PDF] ???????????? ???????????? ?????????? ?? ????? blockchain;?? ?????? ;2020 dspace.lib.ntua.gr;;"… ???????????? ???????????? ?????????? ?? ????? Blockchain ??????????? ???????

??????-????? ?????? ????????? : ????????? ??????? … ???????????? ????????????

?????????? ?? ????? Blockchain ??????????? ??????? ??????-????? ?????? …";Autres articles;Version HTML;[PDF] ntua.gr;https://dspace.lib.ntua.gr/xmlui/bitstream/handle/123456789/52495/diploma_thesis_Alyzia_Konsta.pdf?sequence=1;;;https://scholar.google.ch/scholar?start=630&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098760-95;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Automated Planning for Software Architectural Migration;N Chondamrongkul, J Sun… ; 2020 25th International …, 2020  ieeexplore.ieee.org;;"… patient records. The patient records can be queried through Patient, which serves

as a blockchain's reverse-oracle component, instead of a repository that stores data

in itself in the current design. • Change #7 - PatientOracle …";Les 2 versions;;null;;;;https://scholar.google.ch/scholar?start=640&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098765-101;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;A blockchain-based service payment system;B Fawaz, Z Li ; … of Artificial Intelligence Technologies in Computation …, 2020  World Scientific;;"… aspects of new business models. In the context of blockchains, an oracle is an agent

that finds and verifies real-world occurrences and submits this information to the

blockchain to be used by smart contracts. The data could be the …";Autres articles;;null;;;;https://scholar.google.ch/scholar?start=650&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098875-357;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Optimización de la trazabilidad del aceite de palma por medio de blockchain y IoT;D Soto Sedano ;2020 pirhua.udep.edu.pe;;"Page 1. Optimización de la trazabilidad del aceite de palma por medio de blockchain y IoT Trabajo

de Investigación para optar el Grado de Máster en Dirección de Empresas … iii Resumen ejecutivo

Este trabajo de investigación está centrado en explicar la tecnología Blockchain …";Autres articles;Version HTML;[PDF] udep.edu.pe;https://pirhua.udep.edu.pe/bitstream/handle/11042/4368/MDE_1950.pdf?sequence=2;"
 

 

 

 

 

OptimizaciĂłn de la trazabilidad del aceite de palma por 
medio de blockchain y IoT 

 
 

Trabajo de InvestigaciĂłn para optar el Grado de 
MĂĄster en DirecciĂłn de Empresas 

 
David Soto Sedano 

 
Asesor: Mtr. Eduardo Emilio Linares SamamĂŠ 

 
Lima, octubre de 2019 

 



 

 
 

 



 

iii 
 

Resumen ejecutivo 

Este trabajo de investigaciĂłn estĂĄ centrado en explicar la tecnologĂ­a Blockchain. EmpezarĂŠ 

exponiendo la situaciĂłn actual del sector de la agricultura y del subsector del cultivo del aceite de 

palma. 

Posteriormente explicarĂŠ el funcionamiento de Blockchain genĂŠrico y aplicado al aceite de palma, 

donde principalmente conseguirĂĄ aumentar la confianza y transparencia en el proceso para permitir 

sustentar la sostenibilidad del mismo y dando una mayor visibilidad de toda la cadena al auditar la 

trazabilidad de toda la cadena de suministro del producto, desde el campo hasta el consumidor. 

AdemĂĄs, expondrĂŠ como se pueden ver beneficiados todos los actores de la cadena, desde los 

palmicultores a los consumidores finales, pasando por productores, empresas logĂ­sticas y 

distribuidores. 

DarĂŠ una imagen clara de todos los pasos indicando las bonanzas del sistema en cada uno de ellos, 

clarificando el tipo de informaciĂłn que deberĂ­amos de incluir en funciĂłn de los involucrados y el 

estadio del producto. 

TambiĂŠn mostrarĂŠ los beneficios de enriquecer la informaciĂłn incorporando datos adicionales al 

sistema de bloques que obtendremos de dispositivos conectados a internet, tambiĂŠn llamado Internet 

de las Cosas (del inglĂŠs Internet of Things Ăł IoT). 

FinalizarĂŠ el trabajo con conclusiones y anexos que den mayor detalle tĂŠcnico. 

Palabras clave: blockchain; cadena de suministro; aceite de palma; auditorĂ­a; eficiencia



 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

  



 

v 
 

Abstract 

This research work is focused on explaining the Blockchain technology. I will begin by exposing the 

current situation of the agriculture sector and the palm oil cultivation subsector. 

Later, I will explain how does Blockchain work in general and applied to palm oil, where it will 

mainly increase trust and transparency in the process supporting its sustainability and giving greater 

visibility of the entire chain by auditing the traceability of the entire supply chain, from the field to the 

consumer. 

In addition, I will explain how all the actors in the chain can benefit from it, from palm growers to 

final consumers, through producers, logistics companies and distributors. 

I will give a clear picture of all the steps showing the benefits of the system in each one of them, 

clarifying the type of information we should include depending on those involved and the stage of the 

product. 

I will also show the benefits of enriching the information by incorporating additional data to the 

blockchain that we will obtain from devices connected to the Internet, also called Internet of Things 

(IoT). 

I will finish the work with conclusions and annexes giving more technical detail. 

Keywords: blockchain; supply chain; palm oil; audit; efficiency 

 



 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

  



 

vii 
 

Tabla de contenido 

 

Resumen ejecutivo ................................................................................................................. iii 

Abstract ........  .......................................................................................................................... v 

Tabla de contenido ................................................................................................................ vii 

Índice de tablas ...................................................................................................................... ix 

Índice de figuras .................................................................................................................... xi 

IntroducciĂłn .  .......................................................................................................................... 1 

CapĂ­tulo 1. ... DescripciĂłn del sector agrĂ­cola y del aceite de palma ...................................... 3 

1.1. Sector del aceite de palma ....................................................................................... 4 

1.2. Retos actuales del sector .......................................................................................... 5 

1.2.1. DeforestaciĂłn ............................................................................................ 5 

1.2.2. Trazabilidad de la calidad ......................................................................... 6 

1.3. Participantes en el proceso ...................................................................................... 7 

1.4. Palmicultores ........................................................................................................... 7 

1.5. Procesadores de aceite / Productores / Cooperativas / Distribuidores .................... 8 

1.6. Proveedores de materias primas ............................................................................ 10 

1.7. Empresas logĂ­sticas ............................................................................................... 10 

1.8. Multinacionales de alimentos ................................................................................ 11 

1.9. Supermercados / Detallistas / Venta online ........................................................... 11 

1.10. Consumidores finales .......................................................................................... 11 

CapĂ­tulo 2. PresentaciĂłn de la tecnologĂ­a Blockchain ......................................................... 13 

2.1. Funcionamiento de Blockchain ............................................................................. 14 

2.2. Ventajas de Blockchain ......................................................................................... 14 

2.2.1. Seguridad ................................................................................................ 15 

2.2.2. Transparencia .......................................................................................... 15



 

viii 
 

 

2.2.3. Confianza ................................................................................................ 15 

2.2.4. Ahorro en costos ..................................................................................... 15 

CapĂ­tulo 3. Propuesta del proyecto de implementaciĂłn ....................................................... 17 

3.1. Proceso .................................................................................................................. 18 

3.2. Puntos de generaciĂłn de informaciĂłn: .................................................................. 19 

3.2.1. Entrega del fruto fresco .......................................................................... 19 

3.2.2. Entrada en planta .................................................................................... 21 

3.2.3. Salida de planta ....................................................................................... 22 

3.2.4. Entrega a transporte ................................................................................ 25 

3.2.5. Entrega a distribuidor ............................................................................. 29 

3.2.6. ComercializaciĂłn .................................................................................... 29 

3.3. ExplotaciĂłn de informaciĂłn .................................................................................. 29 

CapĂ­tulo 4. Business Case de la implementaciĂłn ................................................................. 31 

4.1. Hacer uso de un servicio ya desarrollado .............................................................. 31 

4.2. Crear un Blockchain propio de cero ...................................................................... 34 

4.3. Ejemplo de Business Case para trazabilidad del aceite de palma ......................... 36 

4.4. Ahorros generados ................................................................................................. 37 

CapĂ­tulo 5. ComplementaciĂłn del sistema por medio de Internet de las Cosas (IoT) ......... 39 

Conclusiones  ........................................................................................................................ 43 

BibliografĂ­a ..  ........................................................................................................................ 45 

Anexos .........  ........................................................................................................................ 47 

           Anexo 1. Estructura de datos de Blockchain ................................................................. 47 

 

 



 

ix 
 

Índice de tablas 

Tabla 1. Exportaciones por grupo de productos ......................................................................... 3 

Tabla 2. ProducciĂłn agropecuaria por principales productos .................................................... 4 

Tabla 3.  Exportaciones de productos agropecuarios con alto crecimiento ............................... 5 

Tabla 4. Detalle del nĂşmero de hectĂĄreas de palmicultores versus el nĂşmero de empresas 

privadas ...................................................................................................................................... 8 

Tabla 5. Capacidad instalada por cada regiĂłn .......................................................................... 10 

 



 

 
 



 

xi 
 

Índice de figuras 

Figura 1. UbicaciĂłn de plantas de procesamiento de palma aceitera ......................................... 9 

Figura 2. RepresentaciĂłn de bloques de blockchain ................................................................ 14 

Figura 3. Detalle del proceso de producciĂłn del aceite de palma ............................................ 18 

Figura 4. 8 principios de RSPO ................................................................................................ 19 

Figura 5. Certificado de RSPO ................................................................................................. 20 

Figura 6. Certificado de calidad ............................................................................................... 23 

Figura 7. Informe de calidad de laboratorio ............................................................................. 24 

Figura 8. Certificado de apto para consumo humano ............................................................... 26 

Figura 9. Conocimiento de embarque ...................................................................................... 28 

Figura 10. Ejemplo de cĂłdigo QR escaneable ......................................................................... 30 

Figura 11. IBM Food Trust ...................................................................................................... 32 

Figura 12. IBM Food Trust Pricing .......................................................................................... 32 

Figura 13. AgriDigital .............................................................................................................. 33 

Figura 14. Bext360 ................................................................................................................... 33 

Figura 15. ComparaciĂłn de protocolos Ethereum, Hyperledger y Corda R3 .......................... 35 

Figura 16. RepresentaciĂłn de IoT en el sector agrĂ­cola ........................................................... 39 

 



 

 
 

 



 

1 
 

IntroducciĂłn 

El principal motivo de desarrollar este trabajo de investigaciĂłn es el poder demostrar 

cuales son los beneficios que se pueden conseguir en el proceso de producciĂłn y distribuciĂłn 

del aceite de palma con el uso de tecnologĂ­as Blockchain y IoT, ya que podrĂ­a llegar a afectar 

de forma positivo a agricultores, productores, transportistas, distribuidores y consumidores 

finales, en un entorno y una sociedad de consumo en la que cada vez se demanda mĂĄs 

informaciĂłn y de fuentes mĂĄs contrastadas y seguras. 

El objetivo principal es dar una imagen clara de los beneficios que puede aportar la 

tecnologĂ­a, quĂŠ pasos se deben seguir para conseguirlo y porque puede tener un gran impacto 

en concreto en el sector del aceite de palma debido a la necesidad acuciante de demostrar el 

origen del producto. 

Las principales hipĂłtesis a probar en este trabajo son las de cerciorar que el subsector 

del aceite de palma pueda adoptar tecnologĂ­as que a priori pueden parecer pensadas para 

sectores digitalmente mĂĄs maduros, y comprobar si los beneficios pueden aportar a cumplir 

los principales retos que estarĂĄ afrontando el sector durante los prĂłximos aĂąos. 

Con ese fin, en primer lugar, harĂŠ una revisiĂłn del estado del sector agrĂ­cola en el PerĂş, 

y con un mayor foco en el subsector de la palma para poder entender bien su casuĂ­stica y los 

principales problemas que tienen en la actualidad. 

Una vez entendido darĂŠ un repaso sobre la tecnologĂ­a de Blockchain en sĂ­ y en cĂłmo 

puede beneficiar a la producciĂłn y comercio del aceite de palma, con una visiĂłn global de 

cĂłmo implementarla y los costos que puede tener asociados. 

Como resumen podemos concluir que Blockchain puede ser una herramienta muy Ăştil 

para las empresas manufactureras de alimentos, y en concreto del aceite de palma, porque no 

solo permite seguir trabajando con los paĂ­ses mĂĄs estrictos en materia de sostenibilidad, si no 

que pone en valor toda la cadena productiva pudiendo aĂąadir valor a todo el proceso. Es 

importante dentro de ese proceso que se consiga incorporar al sistema a los diferentes 

intervinientes, ya que en caso contrario no se podrĂĄ enriquecer la informaciĂłn grabada, y se 

perderĂĄ parte de los beneficios de la tecnologĂ­a.



 

 

 



 

3 
 

CapĂ­tulo 1. DescripciĂłn del sector agrĂ­cola y del aceite de palma 

El sector agrĂ­cola en PerĂş es uno de los motores mĂĄs importantes del paĂ­s, junto con la 

pesca y la minerĂ­a. Durante el 2018 han crecido ampliamente algunos productos como la 

quinua, la palta y el arĂĄndano gracias a la demanda internacional y la apertura de nuevos 

mercados en Asia. AdemĂĄs, el sector en sĂ­ ha crecido un 9% principalmente gracias a la 

mejora productiva de algunos de los productos como son el arroz, la aceituna, la papa, el cafĂŠ 

y el cacao. 

Si vemos el Ăşltimo reporte del Banco Central de Reserva del PerĂş [BCRP] (2019), el 

sector agrĂ­cola constituye un 1% del total de exportaciones del paĂ­s (datos entre enero y 

febrero de 2019), en comparaciĂłn con la minerĂ­a que es el sector mĂĄs fuerte del paĂ­s y que 

constituye un 56% de todo lo exportado por el paĂ­s como podemos apreciar en el siguiente 

cuadro. (p. 2). 

Tabla 1. Exportaciones por grupo de productos 

 

Fuente: Banco Central de Reserva del PerĂş [BCRP] (2019) 

 

 



 

4 
 

1.1. Sector del aceite de palma 

En PerĂş hay registradas cerca de 60.000 hectĂĄreas de palma aceitera sembradas 

principalmente en la selva, ademĂĄs de haber proyectos industriales en trĂĄmite por otras 

113.000 hectĂĄreas mĂĄs. 

El aceite de palma es una industria muy fuerte que no sĂłlo ofrece como producto el 

aceite de palma en sĂ­, sino que tambiĂŠn genera toda una lĂ­nea de productos derivados como 

son los detergentes, jabones y suavizantes.  

Esta industria en PerĂş tiene ademĂĄs del carĂĄcter econĂłmico, un carĂĄcter social muy 

fuerte, ya que estĂĄ asociada al desarrollo de las poblaciones que rodean las plantaciones, 

permitiĂŠndoles desarrollar una microeconomĂ­a basada en el cultivo de la palma y sectores 

asociados. 

La producciĂłn de palma aceitera ha sufrido un fuerte crecimiento durante los Ăşltimos 

aĂąos, teniendo un crecimiento de mĂĄs de 225% entre los aĂąos 2008 y 2017, como podemos 

observar en el siguiente cuadro extraĂ­do de la memoria anual de 2017 publicada por el BCRP   

Tabla 2. Producción agropecuaria por principales productos PRODUCCIÓN AGROPECUARIA POR PRINCIPALES PRODUCTOS

(Miles de toneladas mĂŠtricas)

2008 2009 2010 2011 2012 2013 2014 2015 2016 2017

1/ 1/ 1/

AGRÍCOLA

Agroindustria

MaĂ­z amarillo duro 1,232 1,274 1,284 1,260 1,393 1,365 1,228 1,439 1,232 1,248

CaĂąa de azĂşcar 9,396 9,937 9,858 9,885 10,369 10,992 11,390 10,212 9,833 9,401

Palma aceitera 246 268 292 360 518 566 618 684 736 806

AlgodĂłn rama 167 96 64 122 111 83 92 70 45 23

1/ Preliminar.

Fuente: Ministerio de Agricultura y Riego.

ElaboraciĂłn: Gerencia Central de Estudios EconĂłmicos.

 

Fuente:  Banco Central de Reserva del PerĂş [BCRP] (2017) 

En el siguiente cuadro del Banco Central de Reserva del PerĂş [BCRP] (2019) podemos 

ver que las exportaciones del aceite de palma del 2104 al 2018 han tenido una variaciĂłn 

promedio anual de 130.8%, poniĂŠndolo en a la cabeza de productos agropecuarios con mayor 

crecimiento de exportaciĂłn, tan sĂłlo por debajo de la pimienta sin triturar ni pulverizar 

(476.1%), la manteca de cacao de alta acidez (262.9%), los cubos de durazno en jugo de fruta 

(235,0%) y otros aguardientes de vino (230.8%).  



 

5 
 

Tabla 3.  Exportaciones de productos agropecuarios con alto crecimiento 

 

Fuente: Banco Central de Reserva del PerĂş [BCRP] (2019) 

1.2. Retos actuales del sector 

El sector del aceite de palma estĂĄ pasando actualmente por varios retos que vienen 

principalmente generados por las nuevas normativas que se estĂĄn aplicando tanto en Europa 

como en Estados Unidos. 

Los principales retos son: 

1.2.1. DeforestaciĂłn 

El principal reto es evitar la deforestaciĂłn, y para ello lo importante es poder probar que 

el origen de los frutos no viene de un terreno que ha sido deforestado. Es por ese motivo que 

en Europa y Estados Unidos todas las grandes empresas que compran aceite de palma de PerĂş 

exigen que el aceite venga de cultivos sostenibles.  

Los cultivos sostenibles son aquellos que justifican el origen de dicho aceite 

certificando que viene de palmas que estĂĄn en terrenos no deforestados, para poder mantener 

la sostenibilidad del planeta. AdemĂĄs, hay que poder certificar la trazabilidad de toda la 

cadena (tema que trataremos a continuaciĂłn) y que no ha habido trabajadores explotados 

durante el proceso. 



 

6 
 

En el pasado dicha prĂĄctica estuvo muy extendida tanto entre las grandes empresas 

como entre los pequeĂąos palmicultores que iban ganando terreno a los bosques amazĂłnicos en 

pro de seguir aumentando sus hectĂĄreas cultivadas. A dĂ­a de hoy esta prĂĄctica estĂĄ 

disminuyendo ademĂĄs de estar penalizada por el estado peruano. 

De hecho, según podemos ver en el último informe “El 74%del aceite de palma 

utilizado por la industria alimentaria en Europa está certificado como sostenible por RSPO” 

(6 de marzo de 2019): 

La FundaciĂłn EspaĂąola del Aceite de Palma Sostenible ha colaborado con ESPO 

(European Sustainable Palm Oil) en la elaboración del nuevo informe ‘Choosing 

sustainable palm oil – Progress report on the import and use of sustainable palm oil in 

Europe’. Esta revisión analiza el progreso en la importación y utilización de aceite de 

palma sostenible en Europa, asĂ­ como las iniciativas nacionales para impulsar esta 

modalidad de aceite. 

SegĂşn los datos publicados por ESPO en su informe, el 74% del aceite de 

palma utilizado por la industria alimentaria en Europa estĂĄ certificado como sostenible 

por la Roundtable on Sustainable Palm Oil (RSPO). El contexto actual permite seĂąalar 

que el 99% del aceite de palma que entra en Europa es rastreable hasta el molino o 

almazara, y mĂĄs del 84% del aceite de palma importado a Europa estĂĄ cubierto por las 

políticas de sostenibilidad de las empresas ‘No Deforestación, No siembra en 

humedales (peatlands) y No explotación de los trabajadores’. 

En tĂŠrminos absolutos, Europa importĂł 7,2 millones de toneladas de aceite de 

palma en 2017, el 12% de la importaciĂłn mundial, segĂşn Oil World 2018. De esta 

importaciĂłn, 3,8 millones de toneladas fueron utilizadas para la industria alimentaria, 

mientras que el resto, 3,4 millones de toneladas, fueron dirigidos al sector energĂŠtico. 

El total de la importaciĂłn dirigida a biocombustibles en Europa debe cumplir con la 

Renewable Energy Directive (RED), que tiene su propio sistema obligatorio de 

certificaciĂłn de sostenibilidad. (p. 1). 

1.2.2. Trazabilidad de la calidad 

Otra de las mayores exigencias que hay por parte de las grandes empresas 

internacionales es la justificaciĂłn de la trazabilidad del aceite comprado en toda la cadena, 

desde el palmicultor hasta la estanterĂ­a en el comercio. 



 

7 
 

AdemĂĄs de la trazabilidad se requiere que se puedan probar tanto las buenas prĂĄcticas 

utilizadas en cada interacciĂłn del proceso, asĂ­ como todas las certificaciones que posee cada 

uno de los intervinientes en el proceso, desde los palmicultores hasta las empresas logĂ­sticas 

que mueven el fruto fresco hasta las instalaciones del cliente.  

1.3. Participantes en el proceso 

En el proceso del procesamiento del aceite de palma intervienen diferentes participantes 

que se van incorporando a la cadena de suministro segĂşn el proceso lo va requiriendo. Los 

principales actores son, por orden de apariciĂłn en el proceso: 

1.4. Palmicultores 

En una inmensa mayorĂ­a las grandes empresas productoras de aceite de palma tienen 

que recurrir a palmicultores externos que les ayuden a completar el nĂşmero de toneladas 

requeridas para llegar a la cuota anual establecida. Uno de los motivos por los que requieren 

comprar el fruto fresco a terceros es por las leyes en contra de la deforestaciĂłn que se comenta 

en el punto anterior y que les impide seguir creciendo en campos propios. 

Los palmicultores son pequeĂąos empresarios de las zonas cercanas a la planta de 

procesado que viven exclusivamente del cultivo de la palma. En muchas ocasiones trabajan 

agrupĂĄndose en cooperativas que les ayudan tanto con temas tĂŠcnicos, como en generar 

sinergias en centrales de compra y solicitudes de crĂŠdito. 

En su gran mayorĂ­a vienen de un entorno socioeconĂłmico bajo y con bajo conocimiento 

de gestiĂłn, por lo que muchos de ellos viven en el dĂ­a a dĂ­a sin tener un gran conocimiento del 

volumen de negocio que mueven o los beneficios que podrĂ­an tener con un mayor dominio de 

la informaciĂłn que hay alrededor de su plantaciĂłn asĂ­ como con una planificaciĂłn mĂĄs 

detallada de los insumos y recursos necesarios. 

Otro factor que tambiĂŠn ha incrementado el nĂşmero de palmicultores fue el programa 

que lanzĂł el gobierno peruano en 2014 para reconvertir hectĂĄreas de sembrĂ­os de hoja de coca 

en palma aceitera. En concreto se comenzĂł con las regiones de Ucayali y San MartĂ­n para 

poder dar alternativas a los productores cocaleros y apoyar a la disminuciĂłn de dicho cultivo. 

Dentro del programa inicial el gobierno coordinĂł con algunas instituciones financieras para 

facilitar el acceso crĂŠditos a los palmicultores con una opciĂłn inicial de $3,000 por hectĂĄrea y 

a devolver en 3 aĂąos. AdemĂĄs, en algunos casos llegaron incluso a asegurarles la compra del 

fruto por parte de alguna de las productoras de la zona. 



 

8 
 

Entre los principales retos de los palmicultores estĂĄ su profesionalizaciĂłn dentro del 

sector, permitiĂŠndoles tener un mayor conocimiento de las mejores prĂĄcticas en el cultivo de 

la palma y en la gestiĂłn del proceso de distribuciĂłn, conocimientos bĂĄsicos de finanzas y 

conocer los nĂşmeros que rodean su negocio (hectĂĄreas cosechadas, toneladas producidas, 

margen neto de la producciĂłn, etc.). 

Tabla 4. Detalle del nĂşmero de hectĂĄreas de palmicultores versus el nĂşmero de empresas 

privadas 

 

Fuente: Ministerio de Agricultura [Minagri] (2012) 

1.5. Procesadores de aceite / Productores / Cooperativas / Distribuidores 

En este caso son todas grandes empresas que puede que tengan hectĂĄreas propias o no, 

pero tienen la capacidad de procesado del fruto fresco y embotellado y distribuciĂłn del aceite 

de palma. 

Los productores tienen varias dificultades dentro de su cadena de suministro. Una de las 

principales es la de garantizar el volumen suficiente de fruto fresco para que la fĂĄbrica de 

procesado pueda estar trabajando al mĂĄximo de su capacidad todo el tiempo. Normalmente 

para conseguirlo deben tener una combinaciĂłn de producciĂłn propia y de terceros, ya que 



 

9 
 

debido a las normativas que limitan la deforestaciĂłn no se pueden generar nuevas hectĂĄreas de 

plantaciĂłn donde hay bosques amazĂłnicos.  

Por otro lado deben de ser capaces de mantener una trazabilidad del producto desde el 

lugar donde ha sido recolectado hasta el cliente que se lo compra, ya que dentro de la cadena 

son el que produce el producto final y el vĂ­nculo de uniĂłn entre agricultores y multinacionales 

de alimentos. 

En la siguiente grĂĄfica podemos encontrar la distribuciĂłn en el paĂ­s de las plantas de 

procesamiento o extractoras incluyendo la capacidad de procesamiento que tienen y el tipo de 

producto que elaboran: 

Figura 1. UbicaciĂłn de plantas de procesamiento de palma aceitera 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Fuente: Ministerio de Agricultura [Minagri](2012) 

Y para terminar de tener una idea clara de su capacidad, el siguiente cuadro nos muestra 

la capacidad instalada por cada una de ellas: 



 

10 
 

Tabla 5. Capacidad instalada por cada regiĂłn 

 

Fuente: Ministerio de Agricultura[Minagri] (2012) 

1.6. Proveedores de materias primas  

Una parte tambiĂŠn importante de mencionar dentro de la cadena de sostenibilidad del 

aceite de palma son todos los productos que intervienen en el proceso del cultivo y cuidado de 

las palmas. Si bien no entra dentro de la categorĂ­a de sostenible, ya que para eso sĂłlo se 

requiere asegurar que el aceite no venga de terreno deforestado, que se pueda hacer 

seguimiento del proceso y que en el mismo no haya trabajadores explotados, la calidad de los 

insumos como puede ser los fertilizantes y pesticidas, contribuirĂĄ a la calidad del producto 

terminado. 

Dentro de las materias primas, especialmente cuando hablamos de los fertilizantes y los 

agroquĂ­micos, estĂĄ demostrado que algunos de ellos pueden llegar a producir efectos nocivos 

en la salud, por lo que serĂĄ importante el poder justificar a todos los participantes de la cadena 

que las materias primas utilizadas en todo el proceso cumplen con todos los estĂĄndares 

establecidos. 

1.7. Empresas logĂ­sticas 

Las empresas logĂ­sticas son las que se encargan de llevar el aceite de palma en sus 

diferentes formatos a las multinacionales de alimentos. En pocas ocasiones los productores 

tienen capacidad logĂ­stica para llevar a cabo los envĂ­os ellos mismos, por lo que deben contar 

con empresas logĂ­sticas que hagan el trabajo. AdemĂĄs los principales clientes suelen estar en 

Europa y Estados Unidos por lo que la complejidad de los envĂ­os hace que se requiera de 

empresas especializadas. 



 

11 
 

Dentro de sus obligaciones estĂĄ la de mantener las condiciones necesarias para que el 

producto no pierda sus propiedades, y no romper la trazabilidad del producto. 

1.8. Multinacionales de alimentos 

Las multinacionales de alimentos, como pueden ser NestlĂŠ o Procter & Gamble, son los 

principales clientes de las productoras de aceite de palma.  

Desde hace unos aĂąos la tendencia y el foco dentro de las multinacionales de alimentos 

es el poder tener una trazabilidad completa de punto a punto de los alimentos. AdemĂĄs en el 

caso del aceite de palma, la presiĂłn es todavĂ­a mayor y se requiere no sĂłlo el saber de quĂŠ 

agricultor viene y cuĂĄl fue todo el proceso de producciĂłn y distribuciĂłn, si no que se solicita a 

los proveedores de aceite que faciliten tambiĂŠn informaciĂłn de los diferentes certificados que 

tienen todos los intervinientes en el proceso, que se garantice que ninguna botella de aceite 

viene de una hectĂĄrea deforestada, y que las condiciones de transporte y almacenamiento han 

cumplido con los estĂĄndares requeridos. 

1.9. Supermercados / Detallistas / Venta online 

Es el punto final de la cadena antes de llegar al consumidor final. Dada su posiciĂłn no 

tienen un gran poder dentro de la cadena, ya que su labor es cubrir las necesidades de los 

consumidores finales y para ello deben disponer de las opciones que ponen en el mercado las 

grandes multinacionales de alimentos. 

En el caso de haber presiones por el aceite de palma, dichas presiones pasan 

directamente a los eslabones anteriores que serĂĄn los responsables de dar una respuesta a las 

necesidades del mercado y de las legislaciones vigentes. 

1.10. Consumidores finales 

Los consumidores finales son los que cada vez meten mĂĄs presiĂłn a toda la cadena de 

producciĂłn, desde el agricultor al supermercado, ya que la tendencia es que cada vez se 

preocupen mĂĄs por su salud y por el origen de todos los alimentos que compran.  

Hay una tendencia en el mercado que critica mucho el uso del aceite de palma, 

especialmente en 2 lĂ­neas: por un lado todos los productos que no explicitan el uso del aceite 

de palma dentro de sus ingredientes, y por otro el del uso del aceite de palma que no tenga un 

origen sostenible y que no pueda justificar que no proviene de hectĂĄreas que han generado 

deforestaciĂłn de bosque amazĂłnico.  



 

12 
 

Dichas tendencias vienen generadas por la presiĂłn de los consumidores finales que 

decanta en presiĂłn al retail y finalmente al origen de la cadena, afectando a palmicultores y 

productores de aceite de palma.  

El mercado estĂĄ moviĂŠndose rĂĄpidamente para dar una respuesta a dichas inquietudes y 

de hecho asĂ­ lo indican las cifras que llegan desde Europa y Estados Unidos, como veĂ­amos 

en la reseĂąa de la FundaciĂłn EspaĂąola del Aceite de Palma Sostenible en el punto anterior de 

deforestaciĂłn. 
 

 

 



 

13 
 

CapĂ­tulo 2. PresentaciĂłn de la tecnologĂ­a Blockchain 

Blockchain, o también llamada en su traducción en español “cadena de bloques”, es un 

sistema descentralizado de registros Ăşnicos, que se rigen bajo un consenso y que se 

distribuyen en varios nodos bajo una misma red. AdemĂĄs no existen entidades que funcionen 

como propietarias o autoridad sobre la misma, por lo que una de sus principales propiedades 

es la independencia. 

El intercambio de informaciĂłn dentro del sistema Blockchain se hace por medio de 

bloques. Cada bloque contiene la informaciĂłn que se estĂĄ enviando, que puede ser cualquier 

tipo de contenido digital: un registro de una transacciĂłn, una fecha, un documento, etc., 

ademĂĄs de tener informaciĂłn del propio bloque a modo de identificador, y la vinculaciĂłn de 

dicho bloque con el bloque anterior y el siguiente, denominado Hash. 

Por ese motivo cada vez que se envĂ­a un bloque con informaciĂłn, dicho bloque se 

anexarĂĄ a la cadena de bloques, y tendrĂĄ un lugar en la cadena que serĂĄ inamovible ya que 

estarĂĄ precedido por los bloques anteriores y seguido por los bloques que se sigan generando 

en el sistema. 

AdemĂĄs dicha informaciĂłn, es decir, la cadena completa se almacena en cada uno de los 

nodos que compongan el sistema, por lo que la informaciĂłn estarĂĄ replicada en todos ellos, 

siendo estos otros de los grandes beneficios que tiene Blockchain, como son la 

incorruptibilidad e inmutabilidad, ya que si bien en un sistema normal alguien podrĂ­a entrar 

en la base de datos para cambiar un registro, en este caso no es factible ya que tendrĂ­a que 

entrar a cambiar todas las cadenas replicadas en cada uno de los nodos del sistema.  

Para hacer un sĂ­mil sencillo de entender, se podrĂ­a considerar el sistema Blockchain 

como si fuera un libro de cuentas, y las diferentes transacciones que en nuestro caso generan 

bloques se irĂ­an registrando en el debe y en el haber de nuestro libro, es decir, cuando yo 

envĂ­e informaciĂłn a travĂŠs de Blockchain, dicha transacciĂłn quedarĂĄ registrada en el libro de 

cuentas, que ademĂĄs estarĂĄ replicado en todos los participantes que haya en nuestra red. 



 

14 
 

Figura 2. RepresentaciĂłn de bloques de blockchain 

 

Fuente: elaboraciĂłn propia 

2.1. Funcionamiento de Blockchain 

Todas las transacciones deben pasar un proceso de consenso para poder ser aprobadas y 

pasar a formar parte de la cadena de bloques";"""date"",""2019-11-06T17:29:48Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""Trabajo InvestigaciĂłn - David Soto Sedano""
""xmp:CreatorTool"",""MicrosoftÂŽ Word 2016""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dc:creator"",""David Soto Sedano""
""language"",""es""
""dcterms:created"",""2019-11-06T17:29:48Z""
""Last-Modified"",""2019-11-06T17:29:48Z""
""dcterms:modified"",""2019-11-06T17:29:48Z""
""dc:format"",""application/pdf; version=1.5""
""title"",""Trabajo InvestigaciĂłn - David Soto Sedano""
""Last-Save-Date"",""2019-11-06T17:29:48Z""
""pdf:docinfo:creator_tool"",""MicrosoftÂŽ Word 2016""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2019-11-06T17:29:48Z""
""meta:save-date"",""2019-11-06T17:29:48Z""
""pdf:encrypted"",""false""
""dc:title"",""Trabajo InvestigaciĂłn - David Soto Sedano""
""modified"",""2019-11-06T17:29:48Z""
""Content-Length"",""2932799""
""pdf:hasMarkedContent"",""true""
""Content-Type"",""application/pdf""
""pdf:docinfo:creator"",""David Soto Sedano""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""David Soto Sedano""
""dc:language"",""es-PE""
""meta:author"",""David Soto Sedano""
""meta:creation-date"",""2019-11-06T17:29:48Z""
""created"",""2019-11-06T17:29:48Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""65""
""Creation-Date"",""2019-11-06T17:29:48Z""
""resourceName"",""MDE_1950.pdf""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""256"",""4"",""1441"",""19"",""1260"",""17"",""2962"",""2587"",""721"",""3"",""1998"",""4"",""2212"",""3"",""1002"",""2059"",""1107"",""2291"",""2485"",""1167"",""903"",""1571"",""2297"",""500"",""2111"",""1414"",""2207"",""135"",""2348"",""789"",""786"",""84"",""932"",""928"",""82"",""111"",""607"",""107"",""1284"",""339"",""1700"",""1750"",""2338"",""773"",""1544"",""563"",""927"",""2135"",""2029"",""146"",""1654"",""2383"",""1275"",""6"",""2344"",""2"",""2253"",""453"",""2440"",""1712"",""1109"",""2495"",""1079"",""2265"",""1490""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""Author"",""David Soto Sedano""
""producer"",""MicrosoftÂŽ Word 2016""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""MicrosoftÂŽ Word 2016""
""pdf:docinfo:created"",""2019-11-06T17:29:48Z""
";https://scholar.google.ch/scholar?start=900&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098751-78;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Securing e-health records using keyless signature infrastructure blockchain technology in the cloud;G Nagasubramanian, RK Sakthivel, R Patan… ; Neural Computing and …, 2020  Springer;;"… Smart contract risks. Business processes, legal, and other financial details are bound to the

blockchain, which depends on the external Oracle base for its operation. Therefore, any attack

on the Oracle base will be a significant issue. Value transfer risks …";Cité 44 fois;;null;;;;https://scholar.google.ch/scholar?start=620&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098826-245;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Crypto?economy and new sustainable business models: Reflections and projections using a case study analysis;M Massaro, F Dal Mas… ; Corporate Social …, 2020  Wiley Online Library;;"… are writing exceeds 230 USD billions only considering cryptocurrencies and crypto?tokens.1 …

According to Mary Hall, director of the Oracle Blockchain Product Market “While it's … Permissioned

blockchains don't typically involve cryptocurrency mining.”2 2 Permissioned blockchain …";Cité 8 fois;Les 4 versions;null;;;;https://scholar.google.ch/scholar?start=790&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098791-165;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Simulating, off-chain and on-chain: Agent-based simulations in cross-organizational business processes;T Kampik, A Najjar ; Information, 2020  mdpi.com;;"… potential facilitator of (semi)-autonomous cross-organizational business process execution; in

particular, so-called consortium blockchains can be considered as promising enablers in this

context, as they do not require the use of cryptocurrency-based blockchain technology, as …";Cité 5 fois;Les 4 versions;[PDF] mdpi.com;https://www.mdpi.com/2078-2489/11/1/34/pdf;;;https://scholar.google.ch/scholar?start=710&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098720-1;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;[PDF][PDF] Designing a local electricity market using blockchain technology;SY Kement ; researchgate.net;;"… means, smart contracts define how the transaction takes place in a blockchain [21]. In many

situations, smart contracts need to interact with real-world information to operate. However, smart

contracts cannot access data from outside of their network without the use of oracles …";Les 2 versions;Version HTML;[PDF] researchgate.net;https://www.researchgate.net/profile/Sanem-Kement/publication/344567774_Designing_a_local_electricity_market_using_blockchain_technology/links/5fbeb87fa6fdcc6cc6691412/Designing-a-local-electricity-market-using-blockchain-technology.pdf;;;
1619098884-376;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;[CITATION][C] A Simpler and Modular Construction of Linkable Ring Signature.;W Li, Y Wang, L Chen, X Lai, X Zhang, J Xin ; IACR Cryptol. ePrint Arch., 2020;;null;Autres articles;;null;;;;https://scholar.google.ch/scholar?start=920&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098844-285;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;[PDF][PDF] Kirti: Decentralized Reputation and SLA Enforcement for Cybersecurity;A Charlé ; files.ifi.uzh.ch;;"… Although using a digital currency ether, Ethereum is not intended to be merely a cryptocurrency

such as Bitcoin, whose sole intentional use case is to transfer value … These measurements are

then feed to an oracle which in turn inserts the data into the blockchain, enabling the …";Autres articles;Version HTML;[PDF] uzh.ch;https://files.ifi.uzh.ch/CSG/staff/franco/extern/theses/BA-A-Charle.pdf;"
Kirti: Decentralized Reputation and
SLA Enforcement for Cybersecurity

Amadeo CharlĂŠ
ZĂźrich, Switzerland

Student ID: 14-943-708

Supervisor: Muriel Franco, Bruno Rodrigues
Date of Submission: September 17, 2020

University of Zurich
Department of Informatics (IFI)
BinzmĂźhlestrasse 14, CH-8050 ZĂźrich, Switzerland ifi

B
A

C
H

E
LO

R
T

H
E

S
IS

–
C

om
m

un
ic

at
io

n
S

ys
te

m
s

G
ro

up
,P

ro
f.

D
r.

B
ur

kh
ar

d
S

til
le

r



Bachelor Thesis
Communication Systems Group (CSG)
Department of Informatics (IFI)
University of Zurich
BinzmĂźhlestrasse 14, CH-8050 ZĂźrich, Switzerland
URL: http://www.csg.uzh.ch/



Abstract

The cybersecurity industry is growing at a rapid pace, with innumerable protection ser-
vices available through a multitude of online marketplaces. To secure customer’s trust in
the offered protection services, platform operators offer reputation systems through which
customers may rate said services. However these reputation systems are implemented in
a centralized manner and thus platform owners have full control over reputation data [1].
As reputation data is stored in private databases, this paradigm is lacking transparency
and verifiability.

This thesis breaks with the mentioned approach by implementing a decentralized repu-
tation system utilizing peer-to-peer databases and blockchain technology. Additionally,
the proposed solution combines the reputation system with automated SLA enforcement
through smart contracts on Ethereum1. To handle automated SLA execution the pro-
posed solution Kirti allows external monitoring solutions to report violations to the SLA
terms via a RESTful API. While the practical feasibility of the proposed solution is clearly
demonstrated, an evaluation shows that the implemented reputation system cannot fully
mitigate fraudulent ratings. Further, the incurred costs during deployment and run time
of the utilized smart contracts have been shown to be highly unpredictable to to large
market swings of both ether and gas prices within the Ethereum network.

1https://ethereum.org/

i



ii



Acknowledgments

Firstly I would like to express my gratitude to my supervisors, especially Muriel Franco
who has continuously inspired me with his enthusiastic assistance and unwavering support
in the process of writing this thesis.

Thanks be to Prof. Stiller whose Communication Systems Group provided the organiza-
tional frame and offered the opportunity to write this thesis.

iii



iv



Contents

Abstract i

Acknowledgments iii

1 Introduction 1

1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 Description of Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.3 Thesis Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 Background 5

2.1 Cybersecurity Market . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.1.1 Services and Providers . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.1.2 Reputation Mechanisms . . . . . . . . . . . . . . . . . . . . . . . . 6

2.1.3 Service Level Agreements . . . . . . . . . . . . . . . . . . . . . . . 7

2.2 Blockchain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.2.1 Ethereum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.2.2 Smart Contracts . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.3 InterPlanetary File System (IPFS) . . . . . . . . . . . . . . . . . . . . . . 9

2.3.1 OrbitDB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3 Related Work 11

3.1 Reputation Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.2 SLA Enforcement on Blockchain . . . . . . . . . . . . . . . . . . . . . . . . 12

3.3 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

v



vi CONTENTS

4 Solution 15

4.1 Architecture Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

4.2 User Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

4.3 IPFS Data Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

4.4 Blockchain and SLA Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

4.5 API Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

5 Prototype Implementation 21

5.1 User Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

5.1.1 Service Upload . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

5.1.2 Service Purchase . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

5.1.3 Ratings Upload . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

5.2 Blockchain Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

5.2.1 Data Registration Smart Contract . . . . . . . . . . . . . . . . . . . 25

5.2.2 SLA Smart Contract . . . . . . . . . . . . . . . . . . . . . . . . . . 25

5.3 IPFS Data Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

5.3.1 Rating Upload . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

5.4 API Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

6 Evaluation 33

6.1 Case Study . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

6.2 Costs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

6.3 Decentralization and Limitations . . . . . . . . . . . . . . . . . . . . . . . 37

6.4 A Word on Rating Fraud . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

7 Conclusions and Future Work 39

Abbreviations 45

List of Figures 45



CONTENTS vii

List of Tables 47

A Installation Guidelines 51

A.1 Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

A.2 Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

B Contents of the CD 55



viii CONTENTS



Chapter 1

Introduction

In any commercial transaction of two or more parties, trust is a key factor. Only if there
is a certain level of trust, individuals will engage in any kind of business relationship. In
the setting of a cybersecurity marketplace, this trust is twofold: (i) trust of the buyer that
the seller will deliver the product or service as promised and (ii) trust of the seller that
the buyer will pay him appropriately for the delivered product. To enhance a customer’s
trust, online marketplaces have long relied on reputation systems in which buyers can
rate sellers or service providers and thus sellers can boast a certain reputation visible to
potential customers. In regards to the majority of today’s reputation systems the following
limitations and concerns can be observed however:

• Truthfulness: The reputation scores may not reflect the actual reputation of a
seller, as some raters may leave biased, personally motivated ratings to promote
their own reputation or defame their competition with an unfairly low rating.

• Traceability: On most e-commerce platforms anyone can leave a rating with a
product or service, without actually having purchased said product or service. There
exists a need to verify that only verified customers may leave a rating

• Centralization: Reputation is managed by platforms using a centralized system
architecture. As a seller’s reputation is linked to an account on an e-commerce
platform, he is completely dependent on said platform and its existence. Further, the
platform’s operators may at any time alter one’s reputation as all such information
is stored in a private database.

1.1 Motivation

Reputation systems in general have been shown to enhance customers’ trust and thus make
for more sales on an online market place [2, 3]. In the jungle of cybersecurity solutions,
marketplaces exist that implement a reputation system, however all such marketplaces
make use of a centralized reputation system, as do all major online marketplaces [1], in
which the reputation data is fully managed by the platform administrators. As such,

1



2 CHAPTER 1. INTRODUCTION

the storage, calculation and distribution of reputation data is liable to manipulation by
potentially malicious platform operators.

Reputation systems built on a blockchain have been envisioned in the literature due to its
inherent properties of security, immutability and decentralization of data [4, 5]. Such a
system would for sure provide value for the cybersecurity market as both service providers
and customers could profit from the mentioned characteristics.

In contrast with centralized systems, a reputation system which is decoupled from a
marketplace in a decentralized manner, could allow protection service providers to build
a reputation cross-platform, enabling especially new and less established players in the
industry to build up a reputation and customers’ trust, without being at the whims
of a particular cybersecurity marketplace. In such a decentralized system reputation
scores would ideally be immune to rating fraud and illicit modification. As regards rating
fraud, blockchain based systems have been shown to effectively prevent certain attacks
by design [6]. As a consequence, customers would have more confidence in the validity
of a service’s reputation and are more likely to purchase a solution which is satisfactory.
Additionally, stakeholders entering the cybersecurity market would not have to develop
their own reputation system but could simply integrated with an already existing system
as has been proposed in the literature [5]. Further, a decentralized reputation system
could be of relevance to protection service recommender systems such as MENTOR [7] to
include a provider’s reputation in their recommendation process.

Besides reputation systems, Service Level Agreements (SLAs), which provide agreed-upon
performance targets of an IT solution [8] are used in the cybersecurity industry to enhance
customers’ trust in a protection service. An SLA is an agreement between a customer
and a service provider defining the technical performance for a service as well as the
responsibilities of the involved parties [9]. As such, the SLA of a cybersecurity protection
service may include the details regarding a financial compensation for the customer in case
the service performs below the benchmarks as specified in the SLA. While SLAs provide
a well-defined catalogue of targets and responsibilities, in their practical application SLAs
may add a lot of overhead for customers.

As such, the customer is usually required to file violation reports himself which raises
the need for contracting a monitoring solution. A service provider may further make the
process for reporting violations intentionally time and resource intensive, thus entirely
discouraging a customer from filing claims. Additionally, a service provider may ignore
the claims of the customer and not reward him accordingly. These issues which can
currently be identified in the cybersecurity industry motivate the need for an automated
SLA enforcement. Smart Contracts (SCs) as implemented by the Ethereum blockchain
allow for automatic execution of arbitrary business logic and can thus also be applied
to handle the automatic execution of SLA terms. In this way the compensation scheme
and payment of the underlying service of an SLA can be handled in a transparent and
decentralized manner, curbing the need for a trusted third party.



1.2. DESCRIPTION OF WORK 3

1.2 Description of Work

The main goal of this thesis is the design and prototypical development of a blockchain-
based reputation system with application to the cybersecurity market, including auto-
mated SLA enforcement. In an initial stage, the thesis demands that relevant literature
concerning existing reputation systems, especially those in relation to blockchain technol-
ogy be assimilated. This research is to be undertaken with the aim of evaluating which
characteristics a resilient reputation system must fulfill as per the requirements of the
cybersecurity market. It is to be investigated if solutions proposed in the literature may
be incorporated in the design stage of the thesis. Upon having gained sufficient insight
into the current state of reputation systems and SLA enforcement using blockchain tech-
nology, the main use case scenarios shall be identified in order to appropriately address
the nuances of the cybersecurity market. To showcase the system’s usefulness in practice,
a simple marketplace shall be developed, which allows service providers to upload pro-
tection services and customers to buy and rate said services. The underlying reputation
system shall be designed under consideration of different attack vectors in regards to rat-
ing fraud. The SLA details of all services uploaded by providers shall be automatically
encoded into SCs which handle the payment, compensation and termination of the under-
lying protection service. Further, the system shall allow for the integration with external
parties such as MENTOR [7] by exposing reputation data via a RESTful API. Lastly a
concluding section shall evaluate and discuss the efficacy of the proposed solution.

1.3 Thesis Outline

Chapter 2 provides a background of the relevant concepts and employed technologies
necessary to fully understand the design and implementation decisions which led up to
the final solution.

Chapter 3 examines the current state of related work in the academia with respect to
reputation systems as well as SLA enforcement. It closes with a discussion and compares
the proposed solution with other related works.

Chapter 4 presents an overview of the proposed system architecture first and after-
wards examines each functional layer in more depth. It furthermore sheds light on design
consideration and discusses how the components of the architecture are interconnected.

Chapter 5 showcases the implementation details of each of the components of the system
architecture

Chapter 6 demonstrates the practicality of the proposed solution by means of a case
study and follows up with a discussion on costs, decentralization and rating fraud

Chapter 7 concludes the thesis and hints at future work



4 CHAPTER 1. INTRODUCTION



Chapter 2

Background

This chapter introduces the relevant concepts and technologies forming the foundation of
the proposed solution of the thesis. Firstly, the Cybersecurity Market and its providers
are introduced, followed up by a brief discussion about reputation mechanisms. Next, the
fundamental concepts of blockchain and SCs are discussed. Lastly, the InterPlanetary
File System (IPFS) is introduced as a solid approach for decentralized storage to be used
in the prototype implementation.

2.1 Cybersecurity Market

The digital revolution has found its way into virtually all aspects of our everyday life.
Tools and technologies that were unheard of even a decade ago, now seem indispensable
for most people. On a cautionary note however, with an increase in digitalization also
comes an enhanced risk of cyber attacks. The cybersecurity market as a whole seeks to
offer security minded corporations and individuals relief from the risk of falling victim
to said attacks. The size of the cybersecurity market has been estimated to be in the
billions of dollars [10], accordingly the number of service providers and protection services
is enormous.

While other markets, such as the one for commercial flights, offer a fairly homogeneous
product, the same can in no way be said of the cybersecurity market. The multitude
of protection services for different kinds of cyber attacks and technology stacks available
seems endless. As such, although a large number of flight comparison websites exist, one
is hard pressed to find an equivalent online resource to compare different cybersecurity
solutions.

2.1.1 Services and Providers

Recently, efforts have been made to bring clarity to customers in light of the jungle-like
vastness of available cybersecurity providers and services. Solutions such as MENTOR [7]

5



6 CHAPTER 2. BACKGROUND

seek to facilitate decision-making in selecting an appropriate protection service. MENTOR
allows a customer to enter details about budget constraints and the type of required service
needed. With the help of its custom recommendation process, the customer is presented
with those protection services which are most befitting his or her needs. Further, in an
effort to bundle service providers, cybersecurity directories such as Cybertango [11] have
appeared in recent years. Currently Cybertango displays a catalogue of more than 1300
different cybersecurity providers. It allows to filter cybersecurity providers by location
and by category such as Big Data Protection or DDoS Protection.

2.1.2 Reputation Mechanisms

In many online interactions, the interacting parties don’t have a history of mutual ex-
change and thus generally no foundation of mutual trust is in place. In commercial
transactions in which money and resources are at stake, this raises the risk of uncertainty.
This general observation holds even more true in case of the cybersecurity market, in
which additionally a customer has no guarantee that any protection service will deliver
the promised protection.

In the setting of online commercial transactions, reputation systems seek to close this
gap of trust and uncertainty by introducing reputation scores. A reputation mechanism’s
main objective can be summarized as helping potential customers to evaluate sellers’
trustworthiness and thus minimizing the risk of engaging in a transaction with a fraudulent
seller [12]. Digital reputation mechanisms thus seek to attribute a reputation score to
a target user, based on a collective opinion of its past behavior [13]. The issue with
the majority of reputation systems in cybersecurity nowadays is that reputation data is
centrally stored by the platform administrators who have full control over the data [14].
This empowers the platform owners to potentially manipulate reputation data.

In order to implement an effective reputation system, one must consider that a reputa-
tion system should be resilient against adversarial behavior in order to build a system
which actually accomplishes the goal of increasing customer’s trust [13]. The sore spot
of reputation system is what the literature terms as rating fraud. Rating fraud is of two
kinds [15]: Ballot Stuffing and Bad Mouthing. Ballot Stuffing means to provide unfairly
high ratings while Bad Mouthing means injecting unfairly low ratings. Thus, in order
to design a resilient system, both types of attack have to be taken into consideration.
Due to its inherent properties, which shall be discussed in the next section, blockchain
technology has been proposed in the literature to be used as an effective way to counter
certain attacks such as Bad Mouthing [12] by design. In order to prevent rating fraud in
traditional systems for instance, a customer’s review may be marked as ”verified”, imply-
ing that he or she indeed purchased the service and is thus eligible to leave a rating for
the service. In blockchain based systems however, it is trivially possible to ensure that
only reviews by real customers are stored in the system, thus making the system more
resilient to illegitimate reviews [6].



2.2. BLOCKCHAIN 7

2.1.3 Service Level Agreements

SLAs are formal contracts between customers and service providers aimed at guaranteeing
that customer expectations are met [16]. They may include various information about
a service’s technical performance levels as well as a compensation scheme, in case the
service doesn’t deliver the promised performance.

In the context of the cyber security market, SLAs give prospective customers a certain
level of confidence in purchasing a protection service. Although they are no guarantee
that the protection service will perform as promised, they act as a warrant that a customer
may at least get a financial compensation in case the agreement’s terms were violated.

2.2 Blockchain

A blockchain is a distributed ledger of records such as public transactions and other
events executed by participating parties [17]. It derives its name by collecting network
transactions in ”blocks”, which are linked to one another via cryptographic hashes, thus
forming a ”chain” [18].

Its core feature is that it enables untrusted peers to exchange transactions of monetary
value in a secure peer-to-peer way without relying on an external trusted party [19].

Blockchain technology has attracted public and academic attention due to its inherent
properties of ...

1. Immutability Once a block has been permanently added to the network, it is
computationally infeasible to revert it.

2. Decentralization The blockchain network is not run by a central server, but instead
by a multitude of nodes - programs that can validate network transactions and may
be run by anyone in a permissionless way.

3. Smart Consensus Reaching a consensus in a distributed system is a challenge,
however different consensus algorithms exist which guarantee that network peers
reach an agreement about the current state of the blockchain [20].

2.2.1 Ethereum

Ethereum is a blockchain including a turing-complete language [21], allowing for the
creation of SCs. Although using a digital currency ether, Ethereum is not intended to
be merely a cryptocurrency such as Bitcoin, whose sole intentional use case is to transfer
value between peers. Instead it has been envisioned to be a programmable blockchain,
able to run arbitrarily complex code [22].

Ethereum features a set of high-level programming languages which allow anyone to de-



8 CHAPTER 2. BACKGROUND

velop applications on top of the Ethereum Virtual Machine (EVM). While multiple pro-
gramming languages are available, Solidity has gained wide-spread popularity amongst
Ethereum developers. It is an object-oriented statically-typed programming language
which has been influenced by C++, JavaScript and Python [23]. It supports inheritance,
use of libraries and user defined types, making it the the programming language of choice
for Ethereum developers [22].

In Ethereum, there exist two kinds of accounts, both of which are associated with an
Ethereum address [22]:

• Externally Owned Accounts (EOAs): controlled by real-world users

• Contract Accounts: controlled by code executed by the Ethereum Virtual Ma-
chine (EVM).

The majority of accounts are user-controlled EOAs. They simply enable users to store
ether and send it to other EOAs or Contract Accounts. In case ether is transfered to
a Contract Account, the associated code controlling that account may be triggered, in
which case it executes its logic in the context of the EVM. Such code controlling Contract
Accounts constitutes what is more commonly know as a SC.

2.2.2 Smart Contracts

Work on SCs has already been done in the 1990s [24], however at that time no technology
had been envisioned for their implementation. In more pragmatic terms, SCs allow for
the automatic execution and enforcement of the terms of an arbitrary agreement once the
specified conditions are met [19]. In theory, this allows for lower overall business costs by
reducing the need for a trusted third party as would be required in a traditional business
setting.

An Ethereum smart contract has the following properties [25]:

1. It is triggered by transaction which may or not include any amount of ether

2. It is publicly visible as it is included in the blockchain

3. It is deterministic, meaning that the same input will always result in the same
output

This property of being deterministic is what makes SC so attractive: The outcome of
any input is entirely predictable. Arbitrary contract logic may thus be encoded into self-
executing smart contracts without requiring a trusted third party. SCs on Ethereum can
thus also receive and send ether according to the rules of the the underlying code. Based on
those properties and benefits, SCs have been applied to various realms including financial
services, healthcare and voting amongst others [26]. Still, there are many challenges and
opportunities to explore the concept of SCs in regards to societal, economical and technical
dimensions.



2.3. INTERPLANETARY FILE SYSTEM (IPFS) 9

2.3 InterPlanetary File System (IPFS)

IPFS (InterPlanetaryFileSystem) is a file system allowing for decentralized storage and
access of files, applications and other data. It combines and extends upon established
technologies such as Distributed Hash Tables, BitTorrent and Git [27]. Further, it aims
to outdo HTTP as the information transfer protocol to build a better World Wide Web
(WWW). In IPFS files are downloaded from peers who have bits and pieces of the re-
quested resource, while in HTTP content is downloaded from a single server. Peer-to-peer
systems have been shown to account for significant bandwidth savings as in the case of a
Video Delivery Network [28].

A striking difference between IPFS and HTTP is how data is accessed, which shall be
illustrated below. Suppose a user wants to research information about aardvarks - a
peculiar African animal fond of digging in the ground - and thus enters the following URL
in his or her browser [29]:

https://en.wikipedia.org/wiki/Aardvark

When quering the WWW using an HTTP URL as in this case, the host server (Wikipedia)
is asked to retrieve the requested resource (the page about Aardvarks), thus the location
of the content to be retrieved is of primary importance.

The user could however also view the same content using IPFS via the following URL:

/ipfs/QmXoypizjW3WknFiJnKLwHCnL72vedxjQkDDP1mXWo6uco/wiki/Aardvark.html

In the above URL, the string beginning with QmXo... is called a content identifier (CID)
[30]. CIDs are generated by cryptographically hashing the contents of a file when it is
uploaded to IPFS. Files on IPFS can again be retrieved via the CID.

Thus in IPFS, not the location of a file is relevant for its retrieval, but its contents.
The nature of the underlying most commonly used crypographic hash function sha2-256
is such that if the contents of a file change even minutely, its CID will be completely
different [30]. Note that this is vastly different from location-based content retrieval as
compared to HTTP URLs and file paths, where the address of a file is uncorrelated with
its content.

2.3.1 OrbitDB

OrbitDB is built on top of IPFS and allows for the creation of distributed peer-to-peer
databases [31]. OrbitDB breaks with the relational model so common in traditional
database systems and instead provides the following kinds of database implementations
[32]:

• log: an immutable (append-only) log with traversable history



10 CHAPTER 2. BACKGROUND

• feed: a mutable log with traversable history

• keyvalue: a key-value database

• docs: a document database to which JSON documents can be stored and indexed
by a specified key

• counter: Useful for counting events separate from log/feed data

The concept of structuring data as envisioned in OrbitDB might appear non-intuitive: In
an application resembling twitter for instance, ”tweets” would not be stored in a single
massive database storing tweets of all users, but instead, one is advised to generate a
dedicated database for each user and his tweets [33]. Each tweet in and of itself may
again have its own database, storing the comments left by other users for instance. In
such an approach, one may freely combine and nest the above mentioned database.

All of the above databases implement ipfs-log [34], a Conflict-free Replicated Data Type
(CRDT). As OrbitDB is a peer-to-peer network which enables peers to replicate another’s
database (assuming respective permissions), the question arises how to ensure synchro-
nization between databases in a peer-to-peer distributed paradigm. CRDTs are the answer
to this question. They have been formally shown to satisfy the property of Strong Even-
tual Consistency, which implies that ”[...] replicas eventually reach the same final value
if clients stop submitting updates”, i.e ”[...] correct replicas that have delivered the same
updates have equivalent state [35].”

OrbitDB makes use of this convenient property of CRDTs in its implementation of ipfs-
log, in which entries to the log are stored in IPFS and chained together by pointing to the
previous entry, thus forming a graph [34].



Chapter 3

Related Work

In this chapter an overview of work related to this thesis shall be given. Section 3.1
discusses previous efforts of different kinds in the realm of reputation systems. In section
3.2, an overview of papers dealing with systems of SLA generation and enforcement is
given. Lastly, section 3.3 shows how the system envisioned in this thesis related to previous
works in the academia.

3.1 Reputation Systems

With the gain of popularity of peer-to-peer networks such as Gnutella and BitTorrent,
significant research efforts were made to investigate the requirements and particulars of
said systems. Pioneering work was done by Kamvar et. al in 2003, by presenting a
method which may reduce the effect of malicious peers on the overall system by assigning
trust values to peers [36]. These research efforts lay the foundation for further research.
Followup work included the improvement of the trust model - how trustworthiness of a
peer can be quantitatively measured [37], as well as the application of statistical methods
to calculate trust scores and endeavors to increase scalability of the overall system [38].
Introducing reputation scores in a peer-to-peer network incentivizes peers to contribute to
the networking by sharing resources [38]. By sharing resources with others peers increase
their reputation, while peers who solely engage in ”freeriding” - downloading files without
contributing resources to the network - most likely incur a lower reputation score than
their resource sharing peers.

Further the issue of anonymity in reputation systems has been raised in the literature
in recent years[12, 39, 13]. The rationale behind considering the topic of anonymity is
that a dissatisfied customer might incur disadvantages in future transactions by leaving
a low review with a service provider. Most notably, Schaub et. al [12] describe a truly
anonymous reputation system applicable to e-commerce settings. When paying a service
provider in said system, a customer obtains a token from the service provider, which
later acts as the proof of eligibility when leaving a review with the service provider.
Cryptographic methods ensure that the service provider has no means to link tokens to
transactions and thus customer reviews.

11



12 CHAPTER 3. RELATED WORK

With the arrival and gain in popularity of blockchains, various systems built on blockchain
technology have been envisioned. Dennis et al. propose a blockchain meant to record
transactions of reputation, with the goal of both creating a system with an increased re-
silience to attacks as well as providing the basis of a generic reputation system which can
be used in various kinds of networks [1]. Instead of contriving an entirely new blockchain,
efforts were made to use the Bitcoin protocol as basis for a reputation system [40, 41]. In
2015, Carboni [40] proposed a most simplistic feedback system based on Bitcoin transac-
tions in which a customer can signal that he was satisfied with a producer’s product.

3.2 SLA Enforcement on Blockchain

While the concept of enforcing SLAs may not be novel, until very recently the technical
means to do so in a decentralized manner were not available. This changed with the
arrival of SCs which are capable of reliably executing terms as defined in a contract-like
document, SLAs being no exception. A number of works use SCs deployed to Ethereum
to enforce SLAs in a distributed manner [42, 43, 44]. The concept of encoding the terms
of an SLA into a SC is common amongst all of the cited works. The papers differ however
in their approach as how to ensure that the SC is aware of the current state of the SLA,
especially whether its terms have been violated or not.

Uriarte et al. [42] propose a solution in which auditors monitor a service and reach
consensus on the measurements by a consensus algorithm. These measurements are then
feed to an oracle which in turn inserts the data into the blockchain, enabling the SLA SC
to know the current state of the service. Zhou et al. [43] introduce a different concept to
monitor the solution: They suggest that in a first step a witness committee of N blockchain
users shall be formed. This N is initially agreed upon by both the service p";"""date"",""2020-09-16T10:23:06Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2020-09-16T10:23:06Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.20 (TeX Live 2019) kpathsea version 6.3.1""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2020-09-16T10:23:06Z""
""created"",""2020-09-16T10:23:06Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-09-16T10:23:06Z""
""resourceName"",""BA-A-Charle.pdf""
""Author"",""""
""producer"",""pdfTeX-1.40.20""
""pdf:docinfo:producer"",""pdfTeX-1.40.20""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""24"",""0"",""0"",""0"",""0"",""2"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2020-09-16T10:23:06Z""
""Last-Modified"",""2020-09-16T10:23:06Z""
""dcterms:modified"",""2020-09-16T10:23:06Z""
""title"",""""
""Last-Save-Date"",""2020-09-16T10:23:06Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2020-09-16T10:23:06Z""
""meta:save-date"",""2020-09-16T10:23:06Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.20 (TeX Live 2019) kpathsea version 6.3.1""
""Content-Length"",""1422315""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""65""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""340"",""160"",""1235"",""2"",""326"",""2"",""835"",""1081"",""167"",""12"",""1761"",""2859"",""2316"",""22"",""1530"",""2746"",""1976"",""2153"",""2064"",""1400"",""1905"",""2590"",""1592"",""22"",""1887"",""1506"",""2317"",""2230"",""1411"",""19"",""1515"",""2535"",""561"",""959"",""2347"",""2388"",""1683"",""2039"",""1657"",""2331"",""1946"",""34"",""1558"",""2301"",""1671"",""1791"",""2770"",""21"",""1902"",""35"",""1715"",""2233"",""2041"",""1684"",""289"",""14"",""331"",""15"",""491"",""14"",""851"",""1625"",""624"",""34"",""103""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-09-16T10:23:06Z""
";https://scholar.google.ch/scholar?start=830&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098844-289;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Public key encryption with equality test in the standard model;HT Lee, S Ling, JH Seo, H Wang, TY Youn ; Information Sciences, 2020  Elsevier;;"… However, to the best of our knowledge, all the existing proposals are proven secure only

under the hardness of number-theoretic problems and/or the random oracle heuristics … First,

our construction does not rely on the random oracle heuristics …";Cité 27 fois;Les 5 versions;[PDF] chainnews.com;https://img.chainnews.com/paper/ad656dcbcac16a1697471f08e7c8d315.pdf;"
Public Key Encryption with Equality Test
in the Standard Model

Hyung Tae Lee1, San Ling1, Jae Hong Seo2,
Huaxiong Wang1, and Taek-Young Youn3

1 Division of Mathematical Sciences,
School of Physical and Mathematical Sciences,
Nanyang Technological University, Singapore
{hyungtaelee,lingsan,hxwxang}@ntu.edu.sg

2 Myongji University, Korea
jaehongseo@mju.ac.kr

3 Electonics and Telecommunications Research Institute, Korea
taekyoung@etri.re.kr

Abstract. Public key encryption with equality test (PKEET) is a cryp-
tosystem that allows a tester who has trapdoors issued by one or more
users Ui to perform equality tests on ciphertexts encrypted using public
key(s) of Ui. Since this feature has a lot of practical applications in-
cluding search on encrypted data, several PKEET schemes have been
proposed so far. However, to the best of our knowledge, all the existing
proposals are proven secure only under the hardness of number-theoretic
problems and the random oracle heuristics.

In this paper, we show that this primitive can be achieved not only
generically from well-established other primitives but also even with-
out relying on the random oracle heuristics. More precisely, our generic
construction for PKEET employs a two-level hierarchical identity-based
encryption scheme, which is selectively secure against chosen plaintext
attacks, a strongly unforgeable one-time signature scheme and a cryp-
tographic hash function. Our generic approach toward PKEET has sev-
eral advantages over all the previous works; it directly leads the first
standard model construction and also directly implies the first lattice-
based construction. Finally, we show how to extend our approach to the
identity-based setting.

Keywords: Public key encryption with equality test, identity-based en-
cryption with equality test, standard model

1 Introduction

Public key encryption with equality test (PKEET), which was first introduced
by Yang et al. [23], is a public key encryption (PKE) scheme that allows to
perform an equality test on encrypted data using different public keys as well
as the same public key. In PKEET schemes, each user issues a trapdoor for
equality tests to a tester, and henceforth the tester is able to check the equality



between ciphertexts of users who issued the trapdoor to him.4 This property is of
use in various practical applications, such as keyword search on encrypted data,
encrypted data partitioning for efficient encrypted data management, personal
health record systems, and so on.

As a very similar primitive to PKEET, we may recall public key encryption
with keyword search (PKEKS) due to Boneh et al. [6]. In PKEKS schemes, each
user issues a token for a keyword to the tester using his/her private key, and
henceforth the tester is able to perform an equality test between a message in
a ciphertext of the user and the keyword in the issued token. Hence, it can be
utilized to check the equality between ciphertexts of the same user. However,
the most important feature of PKEET beyond PKEKS is to support equality
tests on ciphertexts between different users.

Let us consider more concrete application scenario of PKEET to elaborate
advantages of PKEET over PKEKS. In an email service, suppose each user
stores his/her emails to the server as encrypted. To support keyword search over
encrypted emails efficiently, encrypted keywords are appended to stored emails.
The server needs to monitor stored emails to maintain the security of the system.
To this end, the server may need to test equality among encrypted keywords. If
the system exploits PKEKS for this functionality, the server can perform equality
tests on encrypted keywords by using a token for a keyword, issued by the owner
of ciphertexts. However, the server needs a different token for each user and each
keyword and so it should interact with each user whenever it has a new keyword
to be monitored. On the contrary, if the system exploits PKEET, the server can
generate a ciphertext of a keyword by himself and perform equality tests.

To support equality tests on encrypted data required for the above scenario,
one may consider to exploit other types of encryption schemes, such as deter-
ministic encryption and fully homomorphic encryption, to name a few. However,
they are faced with the obstacles that PKEKS has. We will discuss more about
relations of PKEET to other primitives including PKEKS in Section 1.2. On
the other hand, apart from the above scenario, PKEET can also be utilized
as a building block to design advanced cryptographic constructions, e.g., group
signatures with controllable linkability [19].

Due to its wide applicability, since Yang et al. proposed the first PKEET
realization, various subsequent constructions [20, 22, 17, 16, 11, 15, 14, 12] have
been proposed to improve performance or to support advanced functionality.
We note that, however, all the existing proposals are proven secure only un-
der the hardness of specific number-theoretic problems and the random oracle
heuristics. There is a lot of literature discussing the limitations of the random
oracle model (e.g., [8, 10, 13]) and thus, it is highly desirable to achieve each
primitive (PKEET in our case) without relying on the random oracle heuristics
from both theoretical and practical standpoints.

4 While Yang et al.’s construction [23] allows anyone to perform equality tests on
ciphertexts, all subsequent works consider the existence of the tester.

2



1.1 Our Contribution

In this paper, our main contribution is a proposal for PKEET schemes. The
proposed construction has several advantages over all the previous PKEET con-
structions. First, our construction does not rely on the random oracle heuristics.
Second, our construction does not rely on underlying mathematical structures
in the sense that we do not require any number-theoretic assumptions for the
security of the proposed construction. More precisely, we employ a 2-level hi-
erarchical identity-based encryption (HIBE) scheme, which is selectively secure
against the chosen-plaintext attacks, a strongly unforgeable one-time signature
scheme and a cryptographic hash function. Finally, our construction can be eas-
ily extended to the identity-based setting since it already employs HIBE as a
building block. As a result, we also obtain the first identity-based encryption
with equality test (IBEET) in the standard model.

As direct applications of our generic construction, we can obtain PKEET
constructions that are proven secure under various types of assumptions, such
as pairing-based, lattice-based, and RSA-based ones. In particular, for example,
we may obtain a PKEET construction from lattices by exploiting a strongly
unforgeable lattice-based signature scheme (e.g., [18]) and a 2-level lattice-based
HIBE scheme (e.g., [2, 3]), which satisfies the indistinguishability under selective
identity, chosen plaintext attacks (IND-sID-CPA). To the best of our knowledge,
it is the first PKEET scheme whose underlying assumptions are solely lattice-
based.

There exists a very recent work by Lee et al. [12] that has a similar goal to
ours. We clearly note that Lee et al.’s approach is not completely generic in the
sense that it essentially uses the computation Diffie-Hellman (CDH) assumption.
Furthermore, Lee et al. proved the security of their scheme only in the random
oracle model.

Overview of Our Generic Construction. Let us explain a high level intuition
for our generic PKEET construction. We begin with a trivial insecure construc-
tion and then modify it subsequently. Suppose that each user has a 2-level HIBE
scheme HIBE = (Setup,KeyExt, Enc,Dec). To generate a ciphertext of a mes-
sage M , we design an encryption algorithm that performs the following steps. It
first selects a random string str from a set {0, 1}∗ as a second level identity and
generates two ciphertexts

C0 = Enc(mpk, [0.str],M) and C1 = Enc(mpk, [1.str], H(M))

where mpk is a master public key of HIBE , H is a hash function, and [ID1.ID2]
denotes an identity whose i-th level identity is IDi for i = 1, 2. This process
outputs (str, C0, C1) as a ciphertext of the message M . The decryption algorithm
is straightforward; it first generates the secret keys related to str, decrypts C0

and C1 by using generated secret keys, and outputs Dec(C0) if H(Dec(C0)) =
Dec(C1).

Once a trapdoor algorithm issues a secret key of the identity 1 to the tester,
he can generate a secret key of the identity [1.str] by himself. Using this, he

3



may perform an equality test by decrypting C1 parts of ciphertexts and then
comparing H(M) values. On the other hand, the user who has the master secret
key of HIBE as his/her secret key, can generate a secret key of the identity [0.str]
and obtain the correct message by using it to decrypt C0. However, the above
construction does not satisfy the security against adaptive chosen ciphertext
attacks (CCA2). Although C0 and C1 are linked by str and there is a process
to check the link between C0 and C1 during the execution of the decryption
algorithm, it is not enough to prevent chosen ciphertext attacks. In fact, the
adversary can obtain the message in C0 by requesting a query on a modified
ciphertext (str, C0, ¡) to the decryption oracle in the security game. To prevent
such a chosen ciphertext attack, almost all previous PKEET constructions in
the random oracle model (including the semi-generic one [12]) have embedded
an instance of the CDH problem.

To achieve the CCA2 security in a generic way, we borrow an idea of the
Canetti, Halevi, and Katz (CHK) transformation to obtain a CCA2 secure PKE
scheme from an IND-sID-CPA secure identity-based encryption (IBE) scheme
using a strongly unforgeable one-time signature scheme in the standard model.
We first assign a signature scheme to each user. By adapting their technique, we
modify our encryption algorithm so that it first generates a pair of a signing key
and a verification key (sks, vks) and uses the verification key vks as the second
level identity, instead of a random string str. After generating two ciphertexts,

C0 = Enc(mpk, [0.vks],M) and C1 = Enc(mpk, [1.vks], H(M)),

it additionally generates a signature σ on the ciphertexts C0 and C1 using a
signing key sks. Thereafter, it outputs

(vks, C0, C1, σ)

as a ciphertext.
Informally, we can regard that an adversary has to succeed in forging a

signature on some message with respect to the verification key in the chal-
lenge ciphertext, in order to receive the correct response from a decryption
oracle query on a ciphertext obtained by modifying the challenge ciphertext.
We show that our construction achieves one-wayness under adaptive chosen ci-
phertext attacks (OW-CCA2) against Type-I adversaries, who have a trapdoor
for equality tests, and the indistinguishability under adaptive chosen ciphertext
attacks (IND-CCA2) against Type-II adversaries, who do not have a trapdoor, if
the exploited HIBE scheme is IND-sID-CPA secure and the exploited signature
scheme is strongly unforgeable in the standard model. As a result, we obtain the
first PKEET construction in the standard model.

Finally, we discuss an extension of our construction to the identity-based set-
ting by replacing a 2-level HIBE scheme with a 3-level one. In our modification,
the first level of the employed 3-level HIBE scheme is reserved for an identity,
while its second and third levels play the same roles as the first and second lev-
els of our PKEET construction, respectively. The derived outcome is the first
IBEET construction in the standard model as well.

4



1.2 Related Works

In this subsection, we look at some primitives related to PKEET. We also intro-
duce existing works related to the technique used in our construction.

PKE/IBE with Equality Test. Yang et al. [23] first introduced the concept
of PKEET, which allows anyone to check whether two ciphertexts contain the
same message or not, under different public keys as well as the same public
key. Following their work, Tang [22] proposed a variant, so called all-or-nothing
PKEET, which allows only testers authorized by two users to perform equality
tests on all ciphertexts of those users. Subsequently, there have been proposed
various PKEET constructions [20, 21, 17, 16, 11, 14, 12] to improve performance
or to support advanced functionality.

In the identity-based setting, Ma [15] proposed a system model for IBEET,
which is an identity-based version of Tang’s all-or-nothing PKEET model, and
presented an instantiation of IBEET. Later, Lee et al. [12] showed that their
semi-generic construction for PKEET can be extended to the identity-based
setting and the derived outcome achieves better security than Ma’s scheme.

On the other hand, all existing PKEET/IBEET schemes are constructed
in the random oracle model. Moreover, all previous proposals rely on specific
number-theoretic assumptions.

PKE/IBE with Keyword Search. PKE with keyword search (PKEKS) is a
PKE scheme that supports the functionality to perform an equality test between
a keyword embedded in a tag and a message in a ciphertext [6]. It is quite similar
to PKEET in the sense that both are able to check the equality on encrypted
data. However, the main difference between the two schemes is that PKEKS
allows tests on ciphertexts under only a fixed public key related to the issued
tag, whereas PKEET allows equality tests on ciphertexts under different public
keys as well as the same public key.

Abdalla et al. [1] considered an extension of PKEKS to the identity-based
setting, which has similar features to those of IBEET. As similar with the relation
between PKEKS and PKEET, IBE with keyword search (IBEKS) also allows
to perform equality tests on ciphertexts under a fixed identity related to the
issued tag, whereas IBEET allows equality tests on ciphertexts under different
identities as well as the same identity.

Deterministic Encryption. The notion of deterministic encryption was first
initiated by Bellare et al. [4]. For testers, PKEET has the very similar feature to
deterministic encryption in the sense that it supports equality tests on cipher-
texts, although PKEET is a probabilistic encryption. Hence, PKEET can be
exploited to many applications of deterministic encryption. On the other hand,
in the view of others who do not have a trapdoor, PKEET works just like tradi-
tional PKE schemes and so it is expected that PKEET achieves better security
than deterministic encryption. Further, as the same as PKEKS, deterministic
encryption supports equality tests between ciphertexts of the same user only.

Transformation from (H)IBE to Other Primitives. In our construction,
we borrow the strategy of the CHK transformation that obtains a CCA2 secure

5



PKE scheme from an IND-sID-CPA secure IBE scheme with exploiting strongly
unforgeable one-time signatures. We note that there is a generic transforma-
tion to obtain a PKEKS scheme using an IBE scheme. In [1], Abdalla et al.
provided a transformation of an anonymous IBE scheme to a secure PKEKS
scheme. Further, as similar to ours, they also extended their transformation to
the identity-based setting by replacing the underlying IBE scheme with an HIBE
one. However, its design principle is quite different from ours: For example, while
our construction uses a verification key of the underlying signature scheme as
an identity and encrypts a message using it, their transformation generates a
random message and encrypts it with a keyword in PKEKS as an identity.

1.3 Organization of the Paper

Section 2 presents basic definitions of several components exploited in our con-
structions. In Section 3, we introduce syntax and the security model of PKEET.
Section 4 provides our PKEET scheme and Section 5 analyzes its security. We
discuss about extensions of our construction in Section 6 and give concluding
remarks in Section 7. The details about formal definitions of IBEET and our
IBEET construction are given in Appendices.

2 Preliminaries

In this section, we look at basic definitions of components that will be exploited
to design our PKEET schemes.

Notation. Throughout the paper, Îť denotes a security parameter. For an algo-
rithm A, A→ a and A 6→ a denote that A outputs a and A does not, respectively.
A function ν : N → R is negligible in λ if for all positive polynomials p(·) and
sufficiently large λ, ν(λ) ≤ 1

p(Îť) . negl(Îť) represents a negligible function in Îť.

Hierarchical Identity-Based Encryption. We begin with presenting the def-
inition of HIBE and its security notion, which will be utilized as a building block
of our generic construction for PKEET schemes.

Definition 1 (Hierarchical Identity-Based Encryption). A hierarchical
identity-based encryption (HIBE) scheme consists of the following four proba-
bilistic polynomial-time (PPT) algorithms:

– Setup(λ): On input a security parameter λ, it outputs a pair of a master pub-
lic key and a master secret key (mpk,msk). It is assumed that mpk contains
the message space M and the identity space I.

– KeyExt(skID, ID′): It takes a secret key skID of an identity ID and ID’s
descendant ID′ (that is, ID is a prefix of ID′) as inputs and outputs a secret
key skID′ of the identity ID′. If ID′ is a first-level user, then skID should be
the master secret key msk.

6



– Enc(mpk, ID,M): It takes mpk, a recipient’s identity ID, and a message
M ∈M as inputs and outputs a ciphertext ct.

– Dec(skID, ct): It takes a secret key skID of an identity ID and a ciphertext ct
as inputs and outputs a message M ′.

We say an HIBE scheme is correct if for any output (mpk,msk) of Setup(Îť),
message M ∈ M, identity ID′ ∈ I, and output skID′ of KeyExt(skID, ID′) with
any ID′’s ancestor ID, it holds

Pr[Dec(skID′ , Enc(mpk, ID′,M))→M ] = 1,

where the probability goes over all randomness values used in all corresponding
algorithms. Furthermore, we require that for any identity ID, its delegated secret
keys obtained from its any ancestor have the same distribution. We remark that
an IBE scheme is an HIBE scheme where all identities are at level 1.

For our construction, we need a selective identity secure HIBE scheme against
chosen plaintext attacks.

Definition 2 (IND-sID-CPA). An IBE or HIBE scheme E = (Setup,KeyExt,
Enc,Dec) is IND-sID-CPA secure if for any PPT adversary A, the advantage
of the following game between the adversary A and the challenger C is negligible
in the security parameter Îť:

1. Init: A outputs a target identity ID∗.

2. Setup: C runs Setup(λ)→ (mpk,msk), forwards the master public key mpk
to A, and keeps the master secret key msk private.

3. Phase 1: A may issue private key queries on IDi, which is neither ID∗

nor an ancestor of ID∗, polynomially many times. To respond to queries, C
runs the KeyExt algorithm to generate a secret key skIDi

of the requested
identity IDi and returns skIDi

to A.

4. Challenge: A outputs two messages M0,M1 of the same length and forwards
C them. C selects a random bit b ∈ {0, 1}, runs Enc(mpk, ID∗,Mb) → ct∗b ,
and passes ct∗b as the challenge ciphertext to A.

5. Phase 2: A may issue private key queries on IDi, which is neither ID∗ nor
an ancestor of ID∗, polynomially many times. C responds as in Phase 1.

6. Guess: A outputs b′ ∈ {0, 1}.

We say A wins if b = b′ and the advantage of A in the above game is defined to

AdvIND-sID-CPA
A,E (Îť) :=

∣∣∣∣Pr[b = b′]− 1

2

∣∣∣∣ .
We remark that in the above game, if A sends a target identity ID∗ together

with two messages M0, M1 at the challenge step, not at the beginning of the
game, then we say that a scheme E is IND-ID-CPA secure.

Signatures. To achieve the CCA2 security of our PKEET construction, we will
borrow the strategy of the CHK transformation [9] that was originally proposed

7



to convert IND-sID-CPA secure IBE schemes into CCA2 secure PKE schemes
with employing a strongly unforgeable one-time signature scheme in the standard
model. Here, we describe the formal definition of signature schemes and provide
its security notion required for our construction.

Definition 3 (Digital Signature Scheme). A digital signature scheme con-
sists of the following three PPT algorithms:

– G(λ) : It takes a security parameter λ as an input and outputs a pair of a
verification key and a signing key (vks, sks).

– S(sks,M) : On input the singing key sks and a message M , it outputs a
signature σ.

– V(vks,M, σ) : It takes the verification key vks, a message M , and a signa-
ture σ as inputs, and returns 1 or 0.

We say that a digital signature scheme is correct if for any output (vks, sks)
of G(Îť) and any message M , it holds

Pr[V(vks,M, S(sks,M))→ 1] = 1,

where the probability goes over all randomness values used in all corresponding
algorithms. We also say that a digital signature is one-time if for each verification
key the signing algorithm runs only once; that is, in the following security model,
we may assume that the adversary attacking a one-time signature scheme can
issue a signing query only once.

Definition 4 (Strong Unforgeability). A signature scheme Sig = (G,S,V)
is strongly unforgeable under an adaptive chosen message attack if for any PPT
adversary A, the probability that the adversary wins in the following game with
the challenger C is negligible in the security parameter Îť:

1. Setup: C runs G(λ) → (vks, sks), passes the verification key vks to A, and
keeps the signing key sks private.

2. Signature Queries: A issues signing queries on messages Mi polynomially
many times. For each Mi, C runs S(sks,Mi)→ σi and sends σi to A. These
queries may be requested adaptively so that each query may depend on the
replies to the previous queries.

3. Output: A outputs a pair (M,σ).

The adversary wins if V(vks,M, σ) → 1 and (M,σ) is not generated during the
signature query phase.

Properties of Hash Functions. To show the correctness and security of our
construction, we will exploit the following properties of hash functions.

Definition 5 (One-way Functions). A function H is one-way if the following
two conditions hold:

1. There exists a polynomial-time algorithm to compute H.

8



2. For any PPT algorithm A, it holds that

Pr[A(λ,H, y)→ x such that H(x) = y] ≤ negl(λ)

where y = H(x′) for a randomly chosen x′ from the domain.

Definition 6 (Collision Resistant Hash Functions). A family of hash func-
tions {Hs} is collision resistant if the following three conditions hold:

1. There exists a PPT algorithm Gen(Îť) that outputs an index s.

2. There exists a polynomial-time algorithm to compute Hs.

3. For any PPT algorithm A, it holds that

Pr[Gen(λ)→ s,A(s)→ (x, x′) such that x 6= x′ and Hs(x) = Hs(x
′)] ≤ negl(λ).

3 Syntax and Security Model

In this section, we review the concept of PKEET and its security model. There
have been several types of definitions of PKEET with slight differences. Among
them, our system model follows the concept of all-or-nothing PKEET scheme,
proposed by Tang [22].

3.1 Syntax

System Model for Our PKEET. Our PKEET system consists of users (e.g.,
senders and receivers) and testers (e.g., the server): In the system, a sender
encrypts a data using a receiver’s public key and sends a ciphertext to the re-
ceiver. The receiver may decrypt his/her ciphertexts using his/her secret key
and/or store ciphertexts at the server. Once the receiver wants to delegate the
test capability for all of his/her ciphertexts, he/she issues a trapdoor for equality
tests to a tester who can access to the server that stores encrypted data. Here-
after, the tester is able to perform equality tests on ciphertexts under the public
key of the receiver who delegated the test authority for his/her ciphertexts to
the tester.

Definitions of PKEET. Before giving a definition of PKEET, we first note
that PKEET is a multi-user setting and we assume that each user is assigned
an index i for 1 ≤ i ≤ N , where N is the number of users in the system. We
use Ui to denote the i-th user. Furthermore, for notational convenience, we use
a subscripted index to indicate keys and ciphertexts for each user, e.g., pki is a
public key for user Ui.

Definition 7 (Public Key Encryption with Equality Test). A public key
encryption with equality test (PKEET) consists of six polynomial-time algo-
rithms (Setup,KeyGen,Enc,Dec,Td,Test), specified as follows.

9



– Setup(λ): On input a security parameter λ, it outputs a system parame-
ter params, which includes the message spaceM. It is assumed that all other
algorithms take params as an input implicitly, though it is not stated.

– KeyGen(params): It takes params as an input and outputs a pair of user’s
public and secret keys (pk, sk).

– Enc(pk,M): It takes pk and a message M ∈ M as inputs, and outputs a
ciphertext ct.

– Dec(sk, ct): It takes sk and a ciphertext ct as inputs, and outputs a mes-
sage M ′ or ⊥.

– Td(ski): On input a secret key ski of a user Ui, it outputs a trapdoor tdi.

– Test(tdi, cti, tdj , ctj): It takes two ciphertexts cti and ctj and two trapdoors
tdi and tdj as inputs, and outputs 0 or 1.

Correctness. Basically, PKEET is a PKE scheme, so that we require that for
any Setup(λ) → params and KeyGen(params) → (pki, ski) and for any message
M ∈M and index i, Dec(ski,Enc(pki,M)) = M always holds. For the function-
ality of Td and Test algorithms, we require the following two additional condi-
tions to be satisfied. For any Setup(λ) → params, KeyGen(params) → (pki, ski),
KeyGen(params)→ (pkj , skj), Td(ski)→ tdi, Td(skj)→ tdj , Enc(pki,Mi)→ cti,
and Enc(pkj ,Mj)→ ctj with Mi,Mj ∈M,

1. Pr
[
Test(tdi, cti, tdj , ctj) → 1

]
= 1 if Mi = Mj , regardless of whether i = j

or i 6= j;

2. Pr[Test(tdi, cti, tdj , ctj)→ 1] is negligible in the security parameter λ for any
ciphertexts ct′i and ct′j such that Dec(ski, ct

′
i) 6= Dec(skj , ct

′
j).

3.2 Security Model

For the security of PKEET, we consider two different scenarios according to
whether the adversary has a trapdoor for the target user or not. In case where
the adversary has the trapdoor for the equality test, we cannot expect the
indistinguishability-based security notion for PKEET, and, probably, the one-
wayness is the best achievable security. Otherwise, we can define the indistin-
guishability security notion for PKEET.

More precisely, we consider the following two types of adversaries for our
PKEET system model.

– Type-I adversary: This type of adversaries has the trapdoor for the target
user’s ciphertexts and so the adversary can perform an equality test with
the challenge ciphertext. Hence, we consider that the aim of the adversary
is to reveal the message contained in the challenge ciphertext.

– Type-II adversary: This type of adversaries has no trapdoor for the target
user’s ciphertexts and so the adversary cannot perform an equality test with
the challenge ciphertext. Hence, we consider that the aim of the adversary
is to distinguish whether the challenge ciphertext contains which message
between two candidates.

10



We first provide the formal security definition for PKEET constructions
against Type-I adversaries below.

Definition 8 (OW-CCA2 against Type-I Adversaries). A PKEET scheme
is OW-CCA2 secure against Type-I adversaries if for any PPT adversary A, the
success probability of A in the following game with the challenger C is negligible
in the security parameter Îť: Let Ut be the target user.

1. Setup: C runs Setup(λ) → params and sends the system parameter params
to A. Then, C runs KeyGen(params) → (pki, ski) for 1 ≤ i ≤ N and passes
all pki’s to A.

2. Phase 1: A may query the following oracles polynomially many times adap-
tively and in any order. The constraint is that an index t cannot be queried
to the key extraction oracle Osk.
– Osk : an oracle that on input an index i, returns the Ui’s secret key ski.

– ODec : an oracle that on input a pair of an index i and a ciphertext cti,
returns the output of Dec(ski, cti) using the Ui’s secret key ski.

– OTd : an oracle that on input an index i, returns tdi by running Td(ski)→
tdi with the Ui’s secret key ski.

3. Challenge: C chooses a random message M from the message space M,
runs Enc(pkt,M)→ ct∗t , and sends ct∗t to A.

4. Phase 2: For A’s queries, C responds as in Phase 1. The constraints for
A’s queries are that
(a) the index t cannot be queried to the key extraction oracle Osk;

(b) the pair of the index t and the ciphertext ct∗t cannot be queried to the
decryption oracle ODec.

5. Guess: A outputs M ′.

The adversary A wins in the above game if M = M ′ and the success probability
of A is defined to

AdvOW-CCA2
A,PKEET (λ) := Pr[M = M ′].

Remark 1. (Constraint on the message space) If the size of the message space
is polynomial in the security parameter or the min-entropy of the message dis-
tribution is much lower than the security parameter, a Type-I adversary who
has a trapdoor for the challenge ciphertext, can reveal the message in the chal-
lenge ciphertext in polynomial time or sufficiently small exponential time in the
security parameter, by performing equality tests with the challenge ciphertext
and other ciphertexts of all messages, generated by himself. To prevent these
trivial attacks, it is assumed that the size of the message space is exponential
in the security parameter and the min-entropy of the message distribution is
sufficiently higher than the security parameter.

Now, we present the formal security definition for PKEET constructions
against Type-II adversaries.

11



Definition 9 (IND-CCA2 against Type-II Adversaries). A PKEET scheme
is IND-CCA2 secure against Type-II adversaries if for any PPT adversary A,
the advantage of A in the following game with the challenger C is negligible in
the security parameter Îť: Let Ut be the target user.

1. Setup: This step is the same as that of the OW-CCA2 security game in
Definition 8.

2. Phase 1: This step is almost the same as that of the OW-CCA2 security
game in Definition 8, except that the constraint is that an index t cannot be
queried to the trapdoor extraction oracle OTd as well as the key extraction
oracle Osk.

3. Challenge: A chooses two message M0,M1 ∈ M of the same length and
passes C them. C selects a random bit b ∈ {0, 1}, runs Enc(pkt,Mb)→ ct∗t,b,
and sends ct∗t,b to A.

4. Phase 2: For A’s queries, C responds as in Phase 1. The constraints for
A’s queries are that
(a) the index t cannot be queried to the key extraction oracle Osk and the

trapdoor extraction oracle OTd;

(b) the pair of the index t and the ciphertext ct∗t,b cannot be queried to the

decryption oracle ODec.

5. Guess: A outputs b′.

The adversary A wins in the above game if b = b′ and the advantage of A is
defined to

AdvIND-CCA2
A,PKEET (Îť) :=

∣∣∣∣Pr[b = b′]− 1

2

∣∣∣∣ .
3.3 Extension to Identity-Based Settings

One can easily extend the definition of PKEET to the identity-based setting. Let
us briefly point out differences only. (Refer to Appendix A for formal definitions
of IBEET.) The setup algorithm Setup outputs a pair of a master public key mpk
and a master secret key msk, instead of a system parameter params. The key
generation algorithm KeyGen takes mpk and an identity ID, and outputs a secret
key of the identity ID, skID. All other algorithms are almost the same as the
public key setting, except a slight adjustment for an identity instead of a public
key.

In the security model, there is a small but important difference. In the
PKEET setting, the number of all possible users are N and all corresponding
public keys should be sent to the adversary. Here, we implicitly assume that N
is polynomially bounded in Îť. However, in the identity-based setting, we do not
restrict which identities will be joined in the system among exponentially many
candidates. That is, the adversary can decide who will join in by asking a secret
key of an identity to the corresponding oracle during the security game. The rest

12



part in the security model remains almost unchanged, except a fine-tuning for
an identity instead of a public key. We note that such a small difference between
the numbers of manipulable users in systems should be carefully handled in the
security proof. Hence, in the security proof for PKEET, one may assume that
the simulator knows the target public key pkt in advance at the beginning of
the simulation, at the price of polynomial reduction loss. However, in the se-
curity proof for IBEET, if one would like to make a construction that ac";"""date"",""2016-12-28T08:29:40Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""7"",""18"",""0"",""6"",""9"",""3"",""11"",""2"",""7"",""21"",""9"",""46"",""7"",""55"",""10"",""42"",""78"",""7"",""0"",""0"",""0"",""3"",""5"",""9"",""13"",""15"",""3"",""6"",""7"",""6""
""pdf:PDFVersion"",""1.5""
""xmp:CreatorTool"",""TeX""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dcterms:created"",""2016-12-28T08:29:40Z""
""language"",""en""
""Last-Modified"",""2016-12-28T08:29:40Z""
""dcterms:modified"",""2016-12-28T08:29:40Z""
""dc:format"",""application/pdf; version=1.5""
""Last-Save-Date"",""2016-12-28T08:29:40Z""
""pdf:docinfo:creator_tool"",""TeX""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2016-12-28T08:29:40Z""
""meta:save-date"",""2016-12-28T08:29:40Z""
""pdf:encrypted"",""false""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.15 (TeX Live 2014) kpathsea version 6.2.0""
""modified"",""2016-12-28T08:29:40Z""
""Content-Length"",""431606""
""pdf:hasMarkedContent"",""false""
""Content-Type"",""application/pdf""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.15 (TeX Live 2014) kpathsea version 6.2.0""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""trapped"",""False""
""meta:creation-date"",""2016-12-28T08:29:40Z""
""created"",""2016-12-28T08:29:40Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""35""
""Creation-Date"",""2016-12-28T08:29:40Z""
""resourceName"",""ad656dcbcac16a1697471f08e7c8d315.pdf""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""1902"",""2692"",""2545"",""2558"",""2644"",""2107"",""1977"",""1916"",""1798"",""2157"",""2018"",""1956"",""2667"",""1610"",""1730"",""2073"",""1895"",""2169"",""1516"",""1802"",""2306"",""1687"",""2019"",""2177"",""2771"",""2464"",""1827"",""1592"",""1381"",""1386"",""2145"",""2245"",""2125"",""2074"",""866""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""producer"",""pdfTeX-1.40.15""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""pdfTeX-1.40.15""
""pdf:docinfo:created"",""2016-12-28T08:29:40Z""
";https://scholar.google.ch/scholar?start=830&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098809-208;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;[PDF][PDF] Confidential Assets on MimbleWimble;Y Zheng, H Ye, P Dai, T Sun, V Gelfer ; rin, 2020  eprint.iacr.org;;"… arbitrary bit string to a point on an elliptic curve but also are indifferentiable from random oracles …

someone deliberately chooses a mes- sage difficult to hash and sends it to the blockchain, plenty

of … We use an extension of [11] as a random oracle for users to generate asset tags …";Cité 1 fois;Les 2 versions;[PDF] iacr.org;https://eprint.iacr.org/2019/1435.pdf;"
Confidential Assets on MimbleWimble

Yi Zheng1, Howard Ye1, Patrick Dai1,
Tongcheng Sun2, and Vladislav Gelfer3

1 Qtum Chain Foundation, zhengyi@qtum.info
2 Peking University, suntongcheng@pku.edu.cn

3 Beam Foundation, valdo@beam.mw

January 16, 2020

Abstract. This paper proposes a solution for implementing Confiden-
tial Assets on MimbleWimble, which allows users to issue and transfer
multiple assets on a blockchain without showing transaction addresses,
amounts, and asset types. We first introduce the basic principles of Mim-
bleWimble and then describe the implementation in detail.

Keywords: Confidential Assets ¡ MimbleWimble ¡ Blockchain privacy.

1 Introduction

MimbleWimble [1] is a blockchain solution that enables Confidential Transac-
tions, where the transaction addresses and amounts are hidden, providing a high
level of privacy for blockchain users. Validators in MimbleWimble only store Un-
spent Transaction Outputs (UTXOs) instead of the entire transaction history
for the blockchain, enabling space savings and faster sync. The design of Mim-
bleWimble relies on Elliptic Curve Cryptography, which is easy to understand
and audit. Currently this solution is used in Grin [2] and Beam [3] projects.

The concept of Confidential Assets is from [4], which proposes to use a single
blockchain to track multiple types of assets while keeping their privacy. This
technology hides both transaction amounts and asset types, improving the pri-
vacy and fungibility of all assets. With Confidential Assets, users can issue their
own assets on the blockchain for privacy-related applications. Until now, only
the Elements [5] project has implemented it.

In this paper, we propose an implementation of Confidential Assets based
on MimbleWimble. It can hide transaction addresses, amounts, and asset types,
achieving the highest privacy. We first introduce the basic principles of Mim-
bleWimble and then describe the implementation in detail.

2 MimbleWimble

This section presents the main parts of MimbleWimble as an introduction to
our work. Other parts, like the transaction fee, multi-signature, transaction ag-
gregation, cut-through, and details of Bulletproofs, are beyond the scope of this



paper. You can refer to Grin [2] and Beam [3] projects for more information
about them.

2.1 Pedersen commitments

In MimbleWimble, each input or output of a transaction is expressed by a Ped-
ersen commitment:

C = rG+ aH (1)

where C denotes the commitment, and a is the amount. G and H are two
points randomly selected from the elliptic curve E and keep constant for all
transactions. r is a private key chosen by the owner of the input/output, also
called the blinding factor; it stands for the ownership, and makes the value of a
hard to be calculated from the commitment. Through the Pedersen commitment,
the amount and address of each input and output are hidden.

2.2 Signature

We can find that for a transaction with M inputs {Cin,m}Mm=1 and N outputs
{Cout,n}Nn=1, the following equation holds:

N∑
n=1

Cout,n −
M∑

m=1

Cin,m

=

N∑
n=1

(rout,nG+ aout,nH)−
M∑

m=1

(rin,mG+ ain,mH)

=

(
N∑

n=1

rout,n −
M∑

m=1

rin,m

)
G+

(
N∑

n=1

aout,n −
M∑

m=1

ain,m

)
H

= eG

(2)

in which

N∑
n=1

aout,n −
M∑

m=1

ain,m = 0 (3)

N∑
n=1

rout,n −
M∑

m=1

rin,m = e (4)

since a transaction would not create new funds. e is called the excess value.
G and H are random elliptic curve points whose discrete logarithms with

respect to each other are unknown (the “elliptic curve discrete logarithm prob-
lem”). Therefore, the transaction creator can generate a signature sig using e
obtained through Eq. (4) as the private key. Here, the transaction creator refers
to all senders and receivers of the transaction for simplicity, since the transaction



creation process in MimbleWimble requires their participation to complete. The
signature is later verified by the blockchain verifier using eG obtained through
Eq. (2) as the public key. In this way, the creator proves to the verifier that:

– Balance of amounts. The left side of Eq. (2) is a valid public key on the
elliptic curve using the generator point G. That is to say, Eq. (3) holds.

– Ownership of inputs. The transaction creator knows the private key e.
Combined with Eq. (4) and Bulletproofs introduced below, it can be further

proved that the sum input blinding factors
∑M

m=1 rin,m are known.

2.3 Bulletproofs

Bulletproofs [6] are introduced for the transaction creator to demonstrate that
all hidden output amounts are positive. Besides, they prove the ownership of
inputs together with the signature.

The Bulletproof technology is a non-interactive zero-knowledge proof proto-
col with very short proofs and without a trusted setup. For a Pedersen commit-
ment like Eq. (1), the proof system would convince the verifier that a ∈ [0, 2n−1]
without revealing a and r. The transaction creator needs to generate a proof π
for each output commitment C with the knowledge of a, r. Later, π is verified
by the verifier with C but without a, r. The proof generation and verification
algorithms can be expressed as:

π ← Generate(r, a,G,H, n)

{true, false} ← Verify(C,G,H, n)
(5)

Since the knowledge of r is necessary for the proof generation algorithm,
the transaction creator must know all output blinding factors {rout,n}Nn=1 to
generate proofs for all outputs. Combined with Eq. (4) and the fact that the
creator knows e demonstrated by the signature, it proves that the sum of input
blinding factors

∑M
m=1 rin,m are known to the creator; that is, the creator owns

the inputs.

2.4 Putting it all together

Overall, a transaction in MimbleWimble consists of the following three parts:

Input : Cin,1, ..., Cin,M

Output : (Cout,1, π1), ..., (Cout,N , πN )

Kernel : sig

3 Confidential Assets

This section introduces the technology of Confidential Assets to MimbleWimble,
which further allows users to issue and transfer multiple assets on the blockchain.



3.1 Mutiple assets

For Eq. (1), different assets can be assigned with different Hs. Suppose there are
total I assets, the Pedersen commitment for the i-th asset is expressed as:

Ci = rG+ aHi (6)

where i ∈ {1, ..., I} and Hi is called the asset tag.
We should ensure that each asset tag is selected randomly, whose discrete

logarithm is not known with respect to G and any other asset tags. So when
issuing a new asset, a random oracle is needed to map the issuance query to a
random and fixed point on the elliptic curve as its asset tag, which is detailed
in the next subsection.

Signature Eq. (2) can be extended to the case of multiple assets. Suppose a
transaction has inputs and outputs from I assets. For the i-th asset, there are Mi

inputs {Cin,i,m}Mi
m=1 and Ni outputs {Cout,i,n}Ni

n=1. Then the following equation
holds:

I∑
i=1

Ni∑
n=1

Cout,i,n −
I∑

i=1

Mi∑
m=1

Cin,i,m

=

I∑
i=1

Ni∑
n=1

(rout,i,nG+ aout,i,nHi)−
I∑

i=1

Mi∑
m=1

(rin,i,mG+ ain,i,mHi)

=

I∑
i=1

(
Ni∑
n=1

rout,i,n −
Mi∑
m=1

rin,i,m

)
G+

I∑
i=1

(
Ni∑
n=1

aout,i,n −
Mi∑
m=1

ain,i,m

)
Hi

= eG

(7)

in which

I∑
i=1

(
Ni∑
n=1

aout,i,n −
Mi∑
m=1

ain,i,m

)
= 0 for i ∈ {1, ..., I} (8)

I∑
i=1

(
Ni∑
n=1

rout,i,n −
Mi∑
m=1

rin,i,m

)
= e (9)

since no new funds would be created for each asset. It is evident that the excess
value e, public key eG, balance of amounts, and ownership of inputs still follow
the same relationship as Eq. (2) (3) (4). So the signature is also valid for multiple
assets.

Bulletproofs Changing the value of H would not affect the calculation of
Bulletproofs since H is one of the input parameters to the proof generation and
verification algorithms in Eq. (5). But the changed value needs to be publicly
recorded in the output for the verifier to use. As a result, the output is expanded
to the form of (C, π,H).



3.2 Generating asset tags

There has been a lot of research [7] on hash functions that not only can map an
arbitrary bit string to a point on an elliptic curve but also are indifferentiable
from random oracles. Such functions can be used in several places, for example,
in BLS signature [8], the message needs to be hashed to a point in a prime-order
subgroup of a pairing-friendly elliptic curve.

The initial solution is from [9] called MapToGroup. It simply tries hashing
several times by attaching a number to the message and incrementing it on fail.
Let the message be m. Then if hash(0||m) is not the x-coordinate of a rational
point on the elliptic curve, try hash(1||m), hash(2||m) and so on until finally
get one that matches. The probability of success for each try is about 1/2.

However, this solution has an obvious drawback: it cannot execute in con-
stant time, that is, time independent of the hash input. For the blockchain, a
constant-time hash function is necessary. If someone deliberately chooses a mes-
sage difficult to hash and sends it to the blockchain, plenty of time would be
wasted for nodes to verify it.

Several methods have solved the problem of constant-time mapping. Shallue
and van de Woestijne [10] describe a mapping that is computable in deterministic
polynomial time. Fouque and Tibouchi [11] give a concrete set of parameters for
this mapping geared toward BN curves.

We use an extension of [11] as a random oracle for users to generate asset
tags. First, the user needs to create a private key for the new asset. Then, the
corresponding public key and other information for the issuance, such as the
supply, are combined, as the issuance query m. At last, a hash function H(m)
uses m as its input and outputs a point on the elliptic curve E(Fq) as the asset
tag (Fq is the finite field with q elements). The user should also use the private
key to generate a signature sig′ for the issuance query m to demonstrate m is
valid, and the issuance is authorized.

Here, the hash function H(m) is expressed as:

H(m) = f(h1(m)) + f(h2(m)) (10)

where h1(m), h2(m) are independent hash functions as random oracles to Fq,
and f(t) is a mapping from Fq to E. h1(m), h2(m) can be realized by SHA256
as following:

hi(m) = SHA256(i||m) mod q, i ∈ {1, 2}

The results produced by this method have some bias from the uniform random
distribution, but this bias is negligible for most elliptic curves.

Fouque and Tibouchi provide an implementation of f(t) on the elliptic curve
of the form:

E : y2 = g(x) = x3 + b, b 6= −1



over field Fq with q ≡ 7 (mod 12). They prove that at least one of the three
values:

x1 =
−1 +

√
−3

2
−
√
−3 · t2

1 + b+ t2

x2 =
−1−

√
−3

2
+

√
−3 · t2

1 + b+ t2

x3 = 1−
(
1 + b+ t2

)2
3t2

is the x-coordinate of a point on E, denoted xi; that is, g(xi) is a square over
Fq. Then f(t) can be expressed as:

f(t) =
(
xi, χq(t) ·

√
g (xi)

)
, for t ∈ F∗q

where χq(t) is the sign of t which is used as the sign for the y-coordinate. F∗q =
Fq\{0}, and f(0) can be assigned an arbitrary point. They also prove that f(t)
reaches about 9/16ths of all points on the curve.

3.3 Blinding asset tags

The asset tag H in each output can be hidden by replacing it with an asset
commitment A of the form:

A = H + sG

where s is a secret value randomly selected by the output owner and used to
blind the asset tag. Thus, the asset tag of the output is only known to its owner,
which further improves the privacy of assets.

Signature On this basis, the Pedersen commitment for the i-th asset in Eq. (6)
can be derived as:

Ci = rG+ aAi

= rG+ a(Hi + sG)

= (r + as)G+ aHi

where i ∈ {1, ..., I}. It is equivalent to Eq. (6), because only the blinding factor
r is replaced by another secret value (r + as), and other parameters remain un-
changed. With this replacement, Eq. (7) (8) (9) can still hold, and the signature
continues to work.

Bulletproofs A is also a point on the elliptic curve, so that it can replace H as
the input to the proof generation and verification algorithms. Thus, the output
should be recorded as (C, π,A).



Asset surjection proofs Since the asset tag is hidden, the legitimacy of the
tag cannot be guaranteed. Malicious users can use illegal tags to attack the
blockchain, especially tags whose discrete logarithms are known. For example,
consider the asset tag −H and its asset commitment A′ = −H+sG. Any amount
of asset A′ would actually correspond to a negative amount of asset A, thereby
increasing the supply of A.

To solve this problem, we introduce the ASP (Asset Surjection Proof) [4]
technology. It generates a cryptographic proof for an asset commitment A and
a set of asset commitments {Ai}Ji=1, proving that A has the same asset tag H
as a commitment AK in the set, without exposing H and AK to the verifier. In
MimbleWimble, the proof can be generated for A and a subset of all issued asset
tags {Hi}Ji=1. In this way, it proves H ∈ {Hi}Ji=1 without revealing the value of
H, and thus demonstrates the legitimacy of A.

The ASP technology works as follows. The prover first computes a set of
elliptic curve points {Pi}Ji=1 by

Pi = A−Hi =

{
H + sG−Hi, i 6= K

sG, i = K

where only PK is a point whose discrete logarithm to G is known due to H = HK .
Then the prover uses {Pi}Ji=1, s, and G to generate an AOS (Abe-Ohkubo-
Suzuki) ring signature [12]. The signature proves to the verifier that the discrete
logarithm of one of the points in {Pi}Ji=1 is known to the prover. This statement

holds only when H ∈ {Hi}Ji=1. Thus the ASP can be written as (H, σ), where
H stands for {Hi}Ji=1 and σ is the ring signature.

Now, fields in the output are expanded to (C, π,A,H, σ), significantly in-
creasing the storage space of the output. The size of H is proportional to J , and
the size of σ is proportional to J + 1 in AOS. If we choose a small J , although
the sizes of H and σ can be reduced, the value of H is easy to be exposed due
to being mixed with a small asset set.

In order to reduce the size of H while keeping the value of J unchanged, a
compact representation of H can be adopted. First, we store all issued asset tags
in an append-only list. Then, one can select tags within an interval of the list
by specifying the start and end positions of the interval. Finally, H consists of
the start and end positions of multiple intervals, representing a set of asset tags
in these intervals.

We consider a more efficient ring signature algorithm for reducing the size of
σ. Suppose in the elliptic curve, the size of a point is X, and the size of a scalar
is Y . The size of σ is (J + 1)Y in AOS, which grows linearly with the size of the
ring. A logarithmic size ring signature algorithm based on the Sigma-protocol is
provided by [13]. Its size is (4 log J)X + (3 log J + 1)Y , which costs less storage
space for large rings. The verification time is still linear. But when the same
ring is used many times, or there is a significant overlap between different rings,
the cost of verification can be further reduced by batching the verification of
many signatures. This situation would be common when users select asset tags
through the compact representation of H.



3.4 Putting it all together

Overall, a transaction for Confidential Assets on MimbleWimble is shown as
follows. Note that there are two types of Kernel to choose from: sig for ordinary
transactions and (sig, sig′,m) for asset issuances.

Input : Cin,1, ..., Cin,M

Output : (Cout,1, π1, A1,H1, σ1), ..., (Cout,N , πN , AN ,HN , σN )

Kernel : sig or (sig, sig′,m)

4 Future Work

We would like to realize some parts of the proposed solution and conduct several
experiments on them to evaluate the performance. These parts may include
generating asset tags, blinding asset tags, and ASP. The issuance query needs to
be further designed. On the one hand, it can be considered to charge a certain
amount of fee or lock some funds as a condition for issuing new assets. On the
other hand, re-issuance and destruction mechanisms can be added to increase
the functionality of issued assets.

References

1. Introduction to MimbleWimble and Grin. https://github.com/mimblewimble/

grin/blob/master/doc/intro.md.
2. The Grin project. https://github.com/mimblewimble/grin.
3. The Beam project. https://github.com/BeamMW/beam.
4. Andrew Poelstra, Adam Back, Mark Friedenbach, Gregory Maxwell, and Pieter

Wuille. Confidential assets. In International Conference on Financial Cryptography
and Data Security, pages 43–63. Springer, 2018.

5. The Elements project. https://github.com/ElementsProject/elements.
6. Benedikt Bünz, Jonathan Bootle, Dan Boneh, Andrew Poelstra, Pieter Wuille, and

Greg Maxwell. Bulletproofs: Short proofs for confidential transactions and more.
In 2018 IEEE Symposium on Security and Privacy (SP), pages 315–334. IEEE,
2018.

7. Hashing to elliptic curves. https://tools.ietf.org/html/

draft-irtf-cfrg-hash-to-curve-04.
8. Riad S Wahby and Dan Boneh. Fast and simple constant-time hashing to the

bls12-381 elliptic curve. IACR Cryptology ePrint Archive, 2019:403, 2019.
9. Dan Boneh, Ben Lynn, and Hovav Shacham. Short signatures from the weil pair-

ing. In International Conference on the Theory and Application of Cryptology and
Information Security, pages 514–532. Springer, 2001.

10. Andrew Shallue and Christiaan E van de Woestijne. Construction of rational points
on elliptic curves over finite fields. In International Algorithmic Number Theory
Symposium, pages 510–524. Springer, 2006.

11. Pierre-Alain Fouque and Mehdi Tibouchi. Indifferentiable hashing to barreto–
naehrig curves. In International Conference on Cryptology and Information Secu-
rity in Latin America, pages 1–17. Springer, 2012.

https://github.com/mimblewimble/grin/blob/master/doc/intro.md
https://github.com/mimblewimble/grin/blob/master/doc/intro.md
https://github.com/mimblewimble/grin
https://github.com/BeamMW/beam
https://github.com/ElementsProject/elements
https://tools.ietf.org/html/draft-irtf-cfrg-hash-to-curve-04
https://tools.ietf.org/html/draft-irtf-cfrg-hash-to-curve-04


12. Gregory Maxwell and Andrew Poelstra. Borromean ring signatures, 2015.
13. Jens Groth and Markulf Kohlweiss. One-out-of-many proofs: Or how to leak a

secret and spend a coin. In Annual International Conference on the Theory and
Applications of Cryptographic Techniques, pages 253–280. Springer, 2015.


	Confidential Assets on MimbleWimble

";"""date"",""2020-01-16T12:10:02Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2020-01-16T12:10:02Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.20 (TeX Live 2019) kpathsea version 6.3.1""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2020-01-16T12:10:02Z""
""created"",""2020-01-16T12:10:02Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-01-16T12:10:02Z""
""resourceName"",""1435.pdf""
""Author"",""""
""producer"",""pdfTeX-1.40.20""
""pdf:docinfo:producer"",""pdfTeX-1.40.20""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""16"",""2"",""28"",""2"",""5"",""4"",""2"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2020-01-16T12:10:02Z""
""Last-Modified"",""2020-01-16T12:10:02Z""
""dcterms:modified"",""2020-01-16T12:10:02Z""
""title"",""""
""Last-Save-Date"",""2020-01-16T12:10:02Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2020-01-16T12:10:02Z""
""meta:save-date"",""2020-01-16T12:10:02Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.20 (TeX Live 2019) kpathsea version 6.3.1""
""Content-Length"",""221200""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""9""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""1878"",""1245"",""1791"",""1449"",""2083"",""1182"",""2482"",""2147"",""260""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-01-16T12:10:02Z""
";https://scholar.google.ch/scholar?start=750&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098892-392;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;[PDF][PDF] Blockchain: The White Man's Burden;D Golumbia ;2020 academia.edu;;"… which is coyly known in the blockchain universe as “the oracle problem” and is in … While the

blockchain startups Pierce and others advocate for seem intended to … Thus, Crandall goes on,

other crypto-proponents have found a way to form a right-libertarian enclave …";Autres articles;Version HTML;[PDF] academia.edu;https://www.academia.edu/download/62162808/blockchain-white-mans-burden-talk20200221-117574-rh3z3.pdf;;;https://scholar.google.ch/scholar?start=940&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098822-236;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Practical Secure Two-Party EdDSA Signature Generation with Key Protection and Applications in Cryptocurrency;Q Feng, D He, M Luo, Z Li… ; 2020 IEEE 19th …, 2020  ieeexplore.ieee.org;;"… apply the standard Sigma protocol [27] for this, which can be easily compiled into non-interactive

zero-knowledge by Fiat- Shamir paradigm [28] in random oracle model … The remaining steps

are identical to a general cryptocurrency transaction, ie, the blockchain peers verify …";Les 2 versions;;null;;;;https://scholar.google.ch/scholar?start=780&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098897-407;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;[PDF][PDF] Supply Chain 4.0–Perspectivas globales y situación en Uruguay;S Kraiselburd, M Tanco, JA Topolansky, A Rodríguez… ; siteanii.anii.org.uy;;"… Estas son, sin ningún orden en particular: blockchain, impresión 3D, internet de las cosas, big

data, inteligencia artificial, vehículos autónomos, robótica y automatización, realidad aumentada

y cloud computing … Page 11. 8 Blockchain Conceptos relevantes Blockchain …";Autres articles;;[PDF] anii.org.uy;https://siteanii.anii.org.uy/upcms/files/listado-documentos/documentos/informe-sobre-tendencia-l.pdf;"
   

 

 

  

                                               

 

Supply Chain 4.0 – Perspectivas globales  

y situaciĂłn en Uruguay 

Estudio de brechas de conocimiento  

en soluciones digitales para el sector logĂ­stico 

Montevideo, abril 2020 

Santiago Kraiselburd 

MartĂ­n Tanco 

Juan AndrĂŠs Topolansky 

AgustĂ­n RodrĂ­guez 

Justino Romano 



   

 

 

Resumen ejecutivo 
Si bien el concepto de Industria 4.0 (del que deriva Supply Chain 4.0) no ha sido aĂşn definido 

de forma rigurosa a nivel acadĂŠmico, en informes de distintas autoridades existen referencias 

recurrentes a una serie de tecnologĂ­as de punta con capacidad de disrumpir el paradigma 

actual de la cadena de suministro. La tendencia de implementaciĂłn de dichas tecnologĂ­as 

para potenciar la eficiencia de la cadena serĂ­a el fenĂłmeno caracterizado como Supply Chain 

4.0. 

El presente documento se enmarca dentro de la consultoría “Estudio de brechas de 

conocimiento en soluciones digitales para el sector logístico”, contratada por ANII. Su objetivo 

es introducir y resumir los principales casos de aplicaciĂłn de las tecnologĂ­as relacionadas a 

la Supply Chain 4.0 a nivel internacional, y brindar un panorama de la situaciĂłn nacional de 

adopciĂłn de dichas soluciones digitales. Finalmente se plantean recomendaciones para el 

desarrollo de un centro de demostraciĂłn de innovaciĂłn digital logĂ­stica. 

Se propone, a efectos de este informe, una lista de las tecnologĂ­as 4.0 mĂĄs mencionadas en 

los documentos consultados. Estas son, sin ningĂşn orden en particular: blockchain, impresiĂłn 

3D, internet de las cosas, big data, inteligencia artificial, vehĂ­culos autĂłnomos, robĂłtica y 

automatizaciĂłn, realidad aumentada y cloud computing. Los casos exitosos de aplicaciĂłn 

referenciados en la literatura y resumidos en este informe son asignados a alguna de las 

tecnologĂ­as mencionadas a efectos de estructurar el estudio. Sin embargo, hay que destacar 

que los casos de estudio no son puros: varias de las tecnologĂ­as son complementarias o se 

superponen en sus definiciones. TambiĂŠn se presenta, para cada tecnologĂ­a, una estimaciĂłn 

de magnitud del impacto econĂłmico en base a proyecciones de distintas autoridades. 

Se incluye tambiĂŠn, para cada una de las tecnologĂ­as, un estado de situaciĂłn de Uruguay, 

basado en artĂ­culos de prensa, otras fuentes de acceso pĂşblico y los resultados de una 

encuesta de diagnĂłstico del nivel de adopciĂłn de herramientas tecnolĂłgicas por parte de la 

cadena de suministro nacional, respondida por mĂĄs de 200 empresas del sector. Si bien no 

se trata de un relevamiento exhaustivo sirve para entender, a grandes rasgos, dĂłnde estĂĄ 

parada el sector logĂ­stico nacional respecto a la adopciĂłn de soluciones digitales.  

En la secciĂłn final del informe se plantean recomendaciones para la implementaciĂłn de un 

centro de demostraciĂłn de soluciones digitales para logĂ­stica, que tambiĂŠn forma parte del 

presente programa de ANII. Las sugerencias son realizadas en base a las brechas 

identificadas en la encuesta de diagnĂłstico e incluyen tanto tecnologĂ­as fĂ­sicas como digitales. 

La redacciĂłn del presente informe coincide con una ĂŠpoca de inmensa incertidumbre a nivel 

mundial, a causa del COVID-19, cuyas consecuencias no han sido ni serĂĄn ajenas al sector 

productivo uruguayo. Diversos estudios internacionales muestran como la digitalizaciĂłn 

sufrirĂĄ una aceleraciĂłn, que permitirĂĄ a algunas empresas recuperarse mĂĄs rĂĄpido y mejor.  

El presente informe actĂşa como una introducciĂłn general al estado de la supply chain 4.0 en 

el mundo y en Uruguay. Investigaciones futuras permitirĂĄn profundizar en la temĂĄtica y 

analizar las barreras de adopciĂłn de tecnologĂ­a que experimentan las empresas nacionales. 

TambiĂŠn se plantea como futura lĂ­nea de investigaciĂłn el estudio detallado de casos exitosos 

de transformaciĂłn digital en empresas del sector productivo uruguayo. El informe 

complementario al presente, parte del mismo proyecto, presenta los resultados detallados de 

la encuesta ya mencionada.  



   

 

 

Resumen ejecutivo 1 

Antecedentes 1 

Marco conceptual 5 

Blockchain 8 

ImpresiĂłn 3D 12 

Internet de las cosas 16 

AnĂĄlisis Big Data 21 

Inteligencia artificial 25 

VehĂ­culos autĂłnomos 29 

RobĂłtica y automatizaciĂłn 33 

Realidad aumentada 37 

ComputaciĂłn en la nube (Cloud) 40 

DigitalizaciĂłn: ÂżdĂłnde empezar? 43 

Conclusiones 49 

Referencias 50 



   

1 

 

Antecedentes 

IntroducciĂłn y objetivos 

El presente informe forma parte del Programa de Soluciones Digitales Innovadoras para el 

sector LogĂ­stico, desarrollado por la Agencia Nacional de InvestigaciĂłn e InnovaciĂłn (ANII) 

junto al BID LAB. Se enmarca dentro de la consultorĂ­a de estudio de brechas de conocimiento 

en soluciones digitales para el sector logĂ­stico, contratada por ANII. 

Uruguay es reconocido en la regiĂłn como uno de los paĂ­ses mĂĄs avanzados en desarrollo de 

software. Sin embargo, el nivel de adopciĂłn de tecnologĂ­as digitales por parte de las 

pequeĂąas y medianas empresas (PyMEs) es muy bajo. La escasa incorporaciĂłn de 

innovaciones digitales trae consecuencias sobre la pĂŠrdida de oportunidades de negocio, la 

falta de modernizaciĂłn para transformar las empresas hacia modelos de mayor valorizaciĂłn, 

eficiencia y menor costo. 

En el escenario de desarrollo para 2050, la OPP (2020) [1] visualiza una cadena de suministro 

eficiente e integrada verticalmente, donde la informaciĂłn tiene un alto nivel de visibilidad y, al 

mismo tiempo, se encuentra asegurada mediante sistemas como blockchain. TambiĂŠn 

imagina una Red Digital Global de Puertos, transporte de paquetes con drones y nano-tiendas 

sin necesidad de stock. Este panorama, aĂşn en el plano de las hipĂłtesis, coincide con la 

visiĂłn que existe a nivel global sobre la logĂ­stica del futuro.  

Para comenzar a reducir la brecha que nos separa del escenario 2050, el Programa de 

Soluciones Digitales Innovadoras para el sector logĂ­stico tiene como objetivo incrementar la 

innovaciĂłn en digitalizaciĂłn en las empresas del sector logĂ­stico de Uruguay. Para ello, uno 

de los mecanismos previsto es promover un mayor conocimiento de las soluciones digitales 

en las empresas del sector logĂ­stico, adecuadas a las necesidades del sector. 

En particular, los objetivos del presente informe son: 

o Mapear las Ăşltimas soluciones tecnolĂłgicas utilizadas en el sector logĂ­stico 
internacional y su aplicaciĂłn, junto con casos de uso en la cadena de suministro 
nacional. 

o Estimar un orden de magnitud para el impacto econĂłmico de cada una de estas 
soluciones tecnolĂłgicas. 

o Presentar los principales resultados obtenidos a partir de la encuesta de diagnĂłstico 
de soluciones tecnolĂłgicas en la cadena de suministro uruguaya, llevada a cabo como 
parte del mismo proyecto. 

o Realizar sugerencias para ser consideradas en el desarrollo de un centro de 
demostraciĂłn de innovaciĂłn digital logĂ­stica, que forma parte del programa. 

La informaciĂłn incluida en este informe se obtuvo principalmente de reportes generados por 

organismos internacionales especializados en el sector logĂ­stico, y tambiĂŠn de artĂ­culos 

acadĂŠmicos publicados sobre la temĂĄtica. A su vez, en el marco de este proyecto se realizĂł 

una encuesta a mĂĄs de 200 empresas del sector logĂ­stico uruguayo, para evaluar su nivel de 

adopciĂłn de tecnologĂ­as en sus procesos. Esta encuesta representĂł una fuente de 

informaciĂłn relevante, aunque se presenta de manera extensiva en un documento 

complementario del presente informe. 



   

2 

 

La digitalizaciĂłn como herramienta para incrementar la 

resiliencia 

Como quedarĂĄ evidenciado por los casos de aplicaciĂłn descritos en los siguientes capĂ­tulos, 

prĂĄcticamente la totalidad de la innovaciĂłn en tecnologĂ­as de la supply chain 4.0 acontece en 

el mundo desarrollado. Esta realidad no deberĂ­a sorprender, ya que liderar (o al menos no 

rezagarse de) la transformaciĂłn digital requiere de una extraordinaria capacidad tĂŠcnica, 

financiera y capital humano. [2]  

Ya hace varias dĂŠcadas que nuestra regiĂłn viene quedando excluida de dichas condiciones, 

con grandes dificultades para competir dentro de los grandes mercados de punta de EEUU, 

Europa y las potencias asiĂĄticas. Uruguay, pese a no ser una excepciĂłn, presenta algunos 

factores favorables: ser un productor y exportador de software per cĂĄpita de clase mundial, 

poseer una economĂ­a estable y una solidez institucional envidiable, y ser un paĂ­s atractivo 

para desarrollarse como hub logĂ­stico y polo de servicios globales.  

Otra observaciĂłn relevante es que los avances tecnolĂłgicos suelen ser llevados a cabo por 

dos clases de empresas. Por un lado, se encuentran las gigantes multinacionales, con un 

poder econĂłmico y tĂŠcnico que les permite ser pioneras en sus respectivas industrias. Al tener 

operaciones alrededor del mundo, sus desarrollos tecnolĂłgicos tarde o temprano terminarĂĄn 

arribando a las economĂ­as en desarrollo, aunque siempre con cierto retraso que aumenta la 

brecha de competitividad. AdemĂĄs, los beneficios del avance tecnolĂłgico no solo son las 

eficiencias que logra, sino tambiĂŠn al valor agregado de la industria de la investigaciĂłn y 

desarrollo, que se da principalmente en el primer mundo. 

Por otro lado, las startups (microempresas ĂĄgiles de tecnologĂ­a, fundadas y financiadas de 

forma independiente) cuentan con la flexibilidad y mentalidad necesaria para incursionar en 

ĂĄreas poco exploradas y llevar al lĂ­mite la innovaciĂłn y la creatividad, creando nuevos 

productos y modelos de negocio. Sus bajos requisitos de capital las hacen viables en casi 

cualquier economĂ­a, incluso aquellas subdesarrolladas. Las startups son, probablemente, el 

mayor foco de oportunidad de los paĂ­ses en desarrollo en cuanto a transformaciĂłn digital, 

aunque para fomentar su surgimiento es necesario diseĂąar polĂ­ticas pĂşblicas adecuadas de 

financiamiento y difusiĂłn. 

Pero lo cierto es que todo lo anteriormente mencionado se encuentra dentro del horizonte de 

la especulaciĂłn. A lo largo de las siguientes secciones, ademĂĄs de los casos de referencia a 

nivel internacional, serĂĄ caracterizada la realidad actual de nuestro paĂ­s a partir de 

informaciĂłn disponible en informes, prensa y otros medios de acceso pĂşblico, y los resultados 

de la encuesta llevada a cabo como parte del presente proyecto.  

La redacciĂłn del presente informe coincide con una ĂŠpoca de inmensa incertidumbre a nivel 

mundial, cuyas consecuencias no han sido ni serĂĄn ajenas al sector productivo uruguayo. 

Debido al veloz surgimiento y extensiĂłn del virus COVID-19 en la regiĂłn y el mundo entero, 

la economĂ­a estĂĄ sufriendo un shock sin precedentes. Sectores enteros han sido paralizados 

completamente: la educaciĂłn bĂĄsica, el entretenimiento y el turismo. Otros, como la industria 

alimenticia o farmacĂŠutica, continĂşan funcionando forzadamente por su naturaleza 



   

3 

 

indispensable, aunque ninguna ha salido ilesa de esta crisis. Por ejemplo, los ingresos por 

exportaciĂłn uruguaya de carne en marzo cayeron cerca de 40% respecto a 2019.1 

Diversos estudios internacionales muestran como la digitalizaciĂłn sufrirĂĄ una aceleraciĂłn23, 

que permitirĂĄ a algunas empresas recuperarse mĂĄs rĂĄpido y mejor y probablemente generĂŠ 

un aumento de la brecha digital4. Mientras tanto la tecnologĂ­a ha surgido como protagonista 

en empresas con avanzada digitalizaciĂłn. Varias de ellas (con actividades de oficina) han 

implementado el trabajo remoto (home office) como alternativa para continuar operando sin 

aglomerar personas en un mismo ambiente, al igual que algunas instituciones de educaciĂłn 

terciaria. Otras, principalmente supermercados, han potenciado sus sistemas de delivery, 

mientras que plataformas digitales como PedidosYa ofrecen envĂ­os sin cargo para sostener 

su nivel de ventas. Incluso las ferias de alimentos desarrollaron una aplicaciĂłn para coordinar 

entregas a domicilio. 

La RAE define “crisis” como “cambio profundo y de consecuencias importantes”. Una 

mentalidad flexible permite interpretar dicha definiciĂłn como una oportunidad, y despojar la 

connotaciĂłn negativa que suele acompaĂąar al tĂŠrmino. SerĂ­a una consecuencia muy positiva 

de la presente situaciĂłn que la cadena de suministro nacional observe los beneficios y 

posibilidades que ofrece la digitalizaciĂłn y cambie su paradigma, y las motive a innovar en 

herramientas digitales durante las ĂŠpocas favorables. Varios expertos en tecnologĂ­a coinciden 

en la necesidad imperiosa de que, a partir de ahora, todas las empresas se vuelvan digitales. 

MĂĄs allĂĄ de Uruguay, es probable que el mundo cambie permanentemente. Con optimismo, 

el prĂłximo gran shock que acontezca encontrarĂĄ al sector productivo mĂĄs preparado y 

resiliente, probablemente de la mano de la tecnologĂ­a. 

Estructura del informe 

El siguiente informe se encuentra estructurado de la siguiente manera: 

a. Marco conceptual, donde se adoptarĂĄn definiciones de algunos de los principales 
tĂŠrminos utilizados, asĂ­ como la presentaciĂłn de las tecnologĂ­as a desarrollar en este 
informe. 

b. Desarrollo de cada tecnologĂ­a, que cubre los casos internacionales de aplicaciĂłn o 
potencial aplicaciĂłn de dichas tecnologĂ­as en los procesos logĂ­sticos que 
correspondan, junto con las estimaciones econĂłmicas pertinentes para cada una de 
ellas y un estado de situaciĂłn de Uruguay. 

c. PresentaciĂłn de principales resultados obtenidos en la encuesta en relaciĂłn al nivel 
de adopciĂłn de soluciones tecnolĂłgicas en la cadena de suministro uruguaya. 

d. Recomendaciones para el desarrollo del centro de demonstraciĂłn a partir de los 
resultados y conclusiones del presente proyecto. 

e. Comentarios finales 

                                                

1 www.inac.uy/innovaportal/v/16962/10/innova.front/exportaciones - Último acceso en marzo de 2020 

2 Fitzpatrick et al. (2020) The digital-led recovery from COVID-19: Five question for CEOs, McKinsey 
article 

3 Lesser, Reeves (2020) Leading out of adversity, Boston Consulting group article 

4 Milanesi (2020) Digital Transformation and Digital divide post covid-19, Forbes, 11 de Mayo. 



   

4 

 

Encuesta de diagnĂłstico 

En el marco de este proyecto se realizĂł una encuesta a mĂĄs de 200 empresas pertenecientes 

a la supply chain para evaluar su grado de adopciĂłn de tecnologĂ­as en sus procesos. A partir 

del anĂĄlisis de sus resultados se obtuvo una visiĂłn general del nivel de digitalizaciĂłn de la 

cadena de suministro en Uruguay. El anĂĄlisis completo y las conclusiones extraĂ­das se 

encuentran desarrollados en un informe complementario que serĂĄ publicado junto al presente. 

Igualmente, se considerĂł pertinente incluir algunos resultados generales para caracterizar la 

situaciĂłn nacional respecto a la supply chain 4.0. 

Como serĂĄ definido en la prĂłxima secciĂłn, dicho concepto hace referencia a una cuarta 

revoluciĂłn industrial, posiblemente caracterizada por un aumento en la productividad y 

disminuciĂłn de la mano de obra empleada. SegĂşn los resultados de la encuesta el 43% de 

las empresas encuestadas disminuyĂł la cantidad de personas empleadas en los Ăşltimos tres 

aĂąos y la rentabilidad cayĂł para el 59% de los casos en el mismo perĂ­odo. Esta evidencia, en 

una primera instancia, serĂ­a contraria al acontecimiento de una nueva revoluciĂłn en el sector, 

panorama que coincide con lo reportado a nivel regional por el informe del BID (2019) [3]. 

Dado este contexto recesivo, un aspecto muy relevante que se observĂł es que la gran 

mayorĂ­a de las empresas no ven a la falta de digitalizaciĂłn como un problema que afecte 

seriamente su supervivencia (sĂłlo un 5% lo ve asĂ­). En otras palabras, las empresas no 

consideran la evoluciĂłn tecnolĂłgica como una posible soluciĂłn a sus problemas de 

efectividad y rentabilidad decreciente. En contraste con esto, la mayorĂ­a de los encuestados 

planea aumentar su inversiĂłn en tecnologĂ­a en los prĂłximos dos aĂąos. Aparentemente las 

empresas de la cadena de suministro nacional entienden la necesidad de avanzar en su 

transformaciĂłn digital, si bien aĂşn no identifican encontrarse rezagadas tecnolĂłgicamente 

como uno de sus problemas mĂĄs importantes. 

Los puntajes de digitalizaciĂłn, sobre un total de 5 puntos en los procesos obtenidos por cada 

tamaĂąo de empresa fueron de 1.6, 2.1 y 2.7 para microempresas, PYMES y grandes 

empresas respectivamente. Esto muestra diferencias significativas entre distintos tamaĂąos, 

siendo un nivel bajo para las microempresas, medio-bajo para las PYMES y medio para las 

grandes empresas. 

Los resultados en la implementaciĂłn de tecnologĂ­as logĂ­sticas especĂ­ficas reflejan la misma 

tendencia. SĂłlo un 14% de las microempresas tiene implementada por lo menos una de las 

tecnologĂ­as incluidas en las preguntas para almacenes (como RFID, sistemas de picking, 

cĂłdigos de barras, entre otras), mientras que en las PYMES y en las grandes empresas este 

porcentaje asciende a 52% y 93% respectivamente. En las tecnologĂ­as de transporte 

consideradas (como GPS, energĂ­as limpias y cĂĄmaras dentro de la cabina), un 31% de las 

microempresas tiene por lo menos una tecnologĂ­a implementada, contra un 67% de las 

PYMES y un 58% de las grandes empresas. Esta superioridad de las PYMES frente a las 

grandes empresas se explica considerando que gran parte de las empresas de transporte 

carretero encuestadas son PYMES y varias de ellas alcanzan mayores grados de 

actualizaciĂłn en sus flotas por dedicarse exclusivamente a la actividad de transporte. 

  



   

5 

 

Marco conceptual 

Supply Chain 

El Council of Supply Chain Management Professionals (CSCMP) define supply chain como 

“los intercambios materiales y de información en el proceso logístico, abarcando desde la 

adquisición de materia prima a la entrega de productos terminados a un usuario final”. La 

cadena conecta a vendedores, proveedores de servicios y clientes. [4] En espaĂąol, suelen 

usarse diversos tĂŠrminos dependiendo de la regiĂłn, tales como cadena de suministros, 

cadena de abastecimiento o cadena de abasto. 

Los eslabones de la cadena, segĂşn World Economic Forum (2019), pueden clasificarse en 

cinco grandes grupos [5]: 

a) Proveedores 
b) Industria manufacturera, que incluye la logĂ­stica de llegada y de salida 
c) Canales de distribuciĂłn: tiendas, mayoristas y plataformas de e-commerce 
d) Facilitadores: proveedores de servicios logĂ­sticos, transportistas, aduanas, 

proveedores de tecnologĂ­a y agentes financieros 
e) Clientes y usuarios finales 

Del presente estudio se excluirĂĄ al Ăşltimo grupo, ya que el interĂŠs es diagnosticar el grado de 

digitalizaciĂłn de los procesos relacionados a logĂ­stica en las empresas, sin que ello implique 

perder el foco hacia el cliente final.  

Supply Chain 4.0 

Definido el concepto de supply chain, ha surgido en los Ăşltimos aĂąos interĂŠs por un fenĂłmeno 

conocido como “Supply Chain 4.0”. Este puede explicarse como “la re-organización de las 

supply chains […] mediante el uso de tecnologías de la industria 4.0. Estas tecnologías, que 

emergieron en el siglo XXI, son mayoritariamente implementadas por empresas que se 

encuentran en la frontera del supply chain management, en países de altos ingresos” [6] 

Dado este concepto, es necesario definir Industria 4.0, del que surge el nombre “Supply Chain 

4.0”. Según Lasi et al. (2014) [7] el término fue acuñado en Alemania para designar una 

inminente cuarta RevoluciĂłn Industrial. Esta se caracteriza por un cambio de paradigma en 

la producciĂłn manufacturera, en base a una digitalizaciĂłn avanzada en las fĂĄbricas y 

tecnologías inalámbricas en el contexto de “objetos inteligentes”. Según los autores, la visión 

futura de la industria consiste en sistemas de producciĂłn modulares y eficientes, que permiten 

la fabricaciĂłn de bienes en lotes individuales, pero manteniendo las condiciones econĂłmicas 

de la producciĂłn en masa. 

Si bien esta es una de las posibles caracterizaciones del fenĂłmeno, el BID (2019) [3] sugiere 

que, al ser una transformaciĂłn aĂşn en desarrollo, estĂĄ definida de manera amplia por carecer 

de la perspectiva histĂłrica, y la literatura aĂşn no ha logrado documentarla de forma abarcativa. 

TambiĂŠn faltan indicadores economĂŠtricos que claramente muestren el impacto de esta 

cuarta revoluciĂłn. De hecho, si el denominador comĂşn de las revoluciones industriales a lo 

largo de la historia fueron la aceleraciĂłn de la productividad y el aumento del desempleo, 

todavĂ­a no hay evidencia de una cuarta revoluciĂłn a escala mundial, por lo menos no en 

forma agregada. Sin embargo, es posible que algunas industrias estĂŠn desarrollando sus 

propias revoluciones, y que esto estĂŠ ocurriendo en diferentes partes del planeta. 



   

6 

 

Adicionalmente, es posible que la evoluciĂłn hacia la cuarta revoluciĂłn industrial tome formas 

diferentes en cada industria: si bien se espera siempre de una revoluciĂłn industrial un 

aumento en la productividad, la caĂ­da del empleo no ha sido una consecuencia en todos los 

casos. Las revoluciones industriales tambiĂŠn han creado nuevos empleos gracias al uso de 

nuevas tecnologĂ­as (por ejemplo, con la tercera revoluciĂłn industrial llegĂł la internet, y se 

crearon empleos antes inexistentes como diseĂąo de pĂĄginas web) y hasta nuevas industrias 

(por ejemplo, la segunda revoluciĂłn industrial fue catastrĂłfica para los fabricantes de carros 

tirados por caballos, pero creo la industria automotriz). 

A continuaciĂłn, listaremos las principales tecnologĂ­as relevantes para supply chain 4.0, 

resumiendo en quĂŠ consisten, su estado del arte a nivel mundial, y potencial impacto.  Una 

complicaciĂłn a la hora de evaluar cada tecnologĂ­a por separado es que su impacto depende 

a menudo de la aplicaciĂłn de otras tecnologĂ­as complementarias. Esto hace que su impacto 

ceteris paribus pueda ser nulo, pero muy importante cuando se implementan conjuntos de 

varias tecnologĂ­as a la vez. Por ejemplo, un sistema de verificaciĂłn de la veracidad de la 

información basado en “blockchain” debe ser alimentado por esta información online, lo que 

puede requerir de internet de las cosas. Como es muy difĂ­cil adelantarse a todos los usos y 

complementariedades posibles, recurriremos a ejemplos de implementaciones exitosas que 

demuestran la factibilidad de la idea, y a algunas estimaciones preliminares de impacto 

potencial basadas, en estos ejemplos y, a veces, en el tamaĂąo del problema que estas 

tecnologĂ­as puedan eliminar o disminuir significativamente. 

TecnologĂ­as incluidas en el informe 

Como se explicĂł anteriormente, Supply Chain 4.0 hace referencia a un conjunto de nuevas 

tecnologĂ­as que caracterizan la transformaciĂłn de las empresas lĂ­deres en el sector. En base 

a documentos de referencia, se seleccionaron aquellas mĂĄs frecuentemente mencionadas 

para el sector logĂ­stico. 

A su vez, estas tecnologĂ­as se pueden clasificar segĂşn su impacto potencial en la industria y 

la ventana de tiempo en la cual se proyecta su implementaciĂłn. La multinacional alemana 

DHL (DHL, 2019) realizĂł un radar de tendencias en donde se mapean las tecnologĂ­as segĂşn 

estos criterios. 

La lista de tecnologĂ­as escogidas se presenta en la Tabla 1, junto con la calificaciĂłn del radar 

de tendencias logĂ­sticas de DHL en cuanto a nivel de disrupciĂłn y ventana de tiempo en la 

cual cada tecnologĂ­a adquirirĂ­a relevancia. [8] Casos de uso internacionales de estas 

tecnologĂ­as serĂĄn desarrolladas individualmente en las prĂłximas secciones de este informe. 

AdemĂĄs, para cada una de ellas, se indicarĂĄn las ĂĄreas de mayor probabilidad de impacto 

dentro de la cadena de suministro. Las ĂĄreas escogidas fueron: Sector primario, transporte, 

almacenamiento, producciĂłn, planificaciĂłn y diseĂąo, y retail, por considerarse como los 

eslabones clave de la cadena donde las tecnologĂ­as 4.0. muestran potencial de agregar valor. 

Como fue mencionado anteriormente, las implementaciones no son puras, suelen abarcar 

mĂĄs de un tipo de tecnologĂ­a, y algunas veces no son fĂĄciles de encasillar bajo el nombre de 

una sola. Al fin y al cabo, los desarrollos tecnolĂłgicos se apoyan en sus predecesores. Por 

ejemplo, Blockchain no tendrĂ­a sentido sin la computaciĂłn en la nube (Cloud). A su vez, la 

robĂłtica solamente existe gracias a dĂŠcadas de desarrollo de la inteligencia artificial, que 

permite a las mĂĄquinas tomar decisiones en base a un raciocinio similar al humano. 

Finalmente, el internet de las cosas y el Big Data son necesariamente complementarios, ya 



   

7 

 

que de poco servirĂ­a que los dispositivos conectados recolectaran grandes volĂşmenes de 

datos si no existiera la capacidad de procesarlos y analizarlos en tiempo real. 

TecnologĂ­a Impacto Ventana de tiempo 

Blockchain Medio >5 aĂąos 

ImpresiĂłn 3D Alto >5 aĂąos 

Internet de las cosas (IoT) Alto <5 aĂąos 

AnĂĄlisis Big Data Alto <5 aĂąos 

Inteligencia artificial Alto >5 aĂąos 

VehĂ­culos autĂłnomos  Alto >5 aĂąos 

RobĂłtica y automatizaciĂłn Alto <5 aĂąos 

ComputaciĂłn en la nube 
(Cloud) 

Alto <5 aĂąos 

Realidad aumentada (AR) Medio <5 aĂąos 

Tabla 1: TecnologĂ­as incluidas en el informe 

Por lo discutido anteriormente se presenta el siguiente diagrama cuyo objetivo es ilustrar de 

forma bĂĄsica las relaciones entre las distintas tecnologĂ­as 4.0 abarcadas en este informe, 

principalmente como referencia para aquellos lectores menos interiorizados en la temĂĄtica. 

En el diagrama, las flechas simples indican una relaciĂłn de dependencia: parten de una 

tecnologĂ­a que se basa en otra, o que no podrĂ­a alcanzar su mĂĄximo potencial en la supply 

chain sin la otra. Las flechas dobles representan tecnologĂ­as complementarias o cuyas 

definiciones se superponen. 

 

Figura 1: Relaciones entre tecnologĂ­as 4.0 (autorĂ­a propia) 
En color azul se indican las tecnologĂ­as fĂ­sicas y en verde las digitales 

  

Inteligencia 

artificial 

Big Data 

Cloud Blockchain 

ImpresiĂłn 

3D 

Realidad 

aumentada 
RobĂłtica y 

automatizaciĂłn 

Drones 
VehĂ­culos 

con 

autonomĂ­a 

Internet de las 

cosas (IoT) 



   

8 

 

Blockchain 

Conceptos relevantes 

Blockchain 

Es una tecnologĂ­a que permite registrar transacciones de forma 
permanente y segura, en una red descentralizada de computadoras, 
reemplazando la necesidad de confiar en un intermediario que las 
registre y verifique [9]. 

Contrato inteligente 
(smart contract) 

Nombre que se le da a una serie de clĂĄusulas de ejecuciĂłn 
automĂĄtica que se incorporan a un blockchain para garantizar su 
seguridad y proporcionar un entorno adecuado para su 
procesamiento cuando se cumplan condiciones acordadas 
previamente por las partes [10]. 

Blockchain as a 
service (BaaS) 

Son servicios en la nube, que permiten a empresas de mĂşltiples 
rubros adoptar soluciones basadas en blockchain sin necesidad de 
invertir en hardware ni realizar desarrollo propio [10]. 

Redes pĂşblicas, 
privadas y federadas 

Tipos de blockchain. En las redes pĂşblicas, cualquier interesado 
puede unirse y no existe un administrador central. Las privadas y 
federadas tienen acceso mĂĄs restringido, y ofrecen mayor control a 
las entidades dueĂąas de la red [10]. 

Origen 

En 2008 fue propuesta Bitcoin [11] como primera aplicaciĂłn de una red distribuida de bloques 

encadenados, con una estructura tal que los datos almacenados se encuentren seguros 

frente a un intento maligno de modificaciĂłn de los registros sin la autorizaciĂłn de la mayorĂ­a 

de los miembros de la red. El ĂŠxito de Bitcoin fomentĂł el surgimiento de nuevas 

criptomonedas, pero tambiĂŠn se han venido estudiando usos de blockchain para mĂşltiples 

aplicaciones en distintos campos, entre ellos la logĂ­stica.  

Áreas de impacto 

Sector primario Transporte Almacenamiento 

ProducciĂłn PlanificaciĂłn y diseĂąo Retail 

Casos de aplicaciĂłn 

a) Aduanas y transporte internacional 

Blockchain puede usarse para realizar el seguimiento de cargamentos comerciales. Mediante 

dispositivos conectados a internet se pueden registrar automĂĄticamente las condiciones de 

un contenedor: temperatura, posiciĂłn, humedad, si fue abierto en algĂşn momento de la 

travesĂ­a, etc. La informaciĂłn se registra en una red blockchain, junto con las notificaciones de 

recepciĂłn, pago y otros eventos relevantes. Los beneficios consisten en la eliminaciĂłn del 



   

9 

 

papeleo y la seguridad de que los controles y certificados emitidos no pueden ser alterados 

unilateralmente [10]. Por ejemplo, una terminal de contenedores y vehĂ­culos de Argentina se 

encuentra evaluando iniciativas de blockchain para integrarse mejor con las aduanas y 

mejorar los procesos de control.  

La naviera Maersk e IBM se asociaron para proveer una plataforma blockchain para 

digitalizaciĂłn y seguimiento del comercio internacional, diseĂąada para ser usada por todo el 

sector. Se destacan la seguridad e infalibilidad en el intercambio de informaciĂłn y la 

eliminaciĂłn de la documentaciĂłn en papel. IBM tambiĂŠn participĂł en una prueba junto a una 

empresa de transporte marĂ­timo y una operadora portuaria para seguimiento y gestiĂłn de 

carga entre China y Singapur, que fue declarada exitosa [12]. Por otra parte, la naviera ZIM 

realizĂł un piloto para digitalizar un bill of landing, y la empresa Accenture tambiĂŠn se 

encuentra experimentando con un sistema basado en blockchain para el mismo documento 

[9]. Se puede ver que el potencial de blockchain para facilitar el comercio internacional es 

reconocido y estĂĄ siendo explorado por empresas relevantes. 

b) Trazabilidad de productos 

Otro posible uso de blockchain es la trazabilidad de productos de alto valor. La startup 

Everledger se dedica a registrar datos sobre el origen y autenticidad de diamantes, que de 

otra forma pueden ser falsificados o haber sido minados en zonas de guerra. Otro caso de 

posible aplicaciĂłn serĂ­a la industria de los medicamentos, ofreciendo transparencia en la 

cadena y certezas sobre la autenticidad de medicamentos de alta relevancia. [13] 

En otra aplicaciĂłn parecida, se implementĂł un piloto para transparentar las cadenas de 

suministro de prendas de vestir, fomentando que los consumidores y tiendas adquieran 

prendas fabricadas a partir de materiales obtenidos de forma ĂŠtica y sostenible. [9] 

En la industria alimenticia, Walmart se asociĂł con IBM en 2016 con el objetivo de mejorar los 

sistemas de informaciĂłn de los miembros de la cadena de suministro para garantizar la 

trazabilidad de los alimentos. Esto es Ăştil en el caso del surgimiento de una enfermedad 

transmitida por alimento, ya que la red blockchain descentralizada almacena nĂşmeros de lote, 

datos de producciĂłn, fechas de expiraciĂłn y detalles de envĂ­o, permitiendo hallar el origen de 

cualquier alimento en cuestiĂłn de segundos [13]. La empresa ShipChain tambiĂŠn ha 

experimentado con una aplicaciĂłn para trazabilidad de productos combinando contratos 

inteligentes y una moneda digital propia, en una base de datos blockchain. [9] 

c) Gemelos digitales para activos fĂ­sicos 

En la industria automotriz, aunque tambiĂŠn aplicable a otros activos fĂ­sicos como propiedades 

inmobiliarias, existe un concepto conocido como “gemelos digitales” (digital twins). Un gemelo 

digital es una representaciĂłn digital de un objeto fĂ­sico que permite almacenar informaciĂłn 

sobre su ciclo de vida. Blockchain puede usarse para asegurar la veracidad de la informaciĂłn 

registrada. Renault, junto con Microsoft y VISEO, experimentĂł con gemelos digitales de 

automĂłviles para guardar y transferir su historial de mantenimiento incluso cuando el vehĂ­culo 

cambia de dueĂąo. Por otra parte, Bosch y una autoridad alemana de certificaciĂłn usan la 

misma idea para prevenir la manipulaciĂłn de odĂłmetros. [9] 



   

10 

 

Oportunidades y dificultades 

 

Altos niveles de confianza, ya que 
la informaciĂłn no se modifica sin 
consenso  

LegislaciĂłn y regulaciĂłn deben 
desarrollarse para cubrir disputas 

 

Cadenas de suministro 
transparentes  

Anonimato y privacidad de los 
datos 

 

Contratos inteligentes pueden 
aumentar eficiencia y elimina";"""date"",""2020-07-24T22:35:59Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.5""
""xmp:CreatorTool"",""MicrosoftÂŽ Word 2016""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dc:creator"",""Juan AndrĂŠs Topolansky""
""language"",""es""
""dcterms:created"",""2020-07-24T22:35:59Z""
""Last-Modified"",""2020-07-24T22:35:59Z""
""dcterms:modified"",""2020-07-24T22:35:59Z""
""dc:format"",""application/pdf; version=1.5""
""Last-Save-Date"",""2020-07-24T22:35:59Z""
""pdf:docinfo:creator_tool"",""MicrosoftÂŽ Word 2016""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2020-07-24T22:35:59Z""
""meta:save-date"",""2020-07-24T22:35:59Z""
""pdf:encrypted"",""false""
""modified"",""2020-07-24T22:35:59Z""
""Content-Length"",""1503457""
""pdf:hasMarkedContent"",""true""
""Content-Type"",""application/pdf""
""pdf:docinfo:creator"",""Juan AndrĂŠs Topolansky""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Juan AndrĂŠs Topolansky""
""dc:language"",""es-UY""
""meta:author"",""Juan AndrĂŠs Topolansky""
""meta:creation-date"",""2020-07-24T22:35:59Z""
""created"",""2020-07-24T22:35:59Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""55""
""Creation-Date"",""2020-07-24T22:35:59Z""
""resourceName"",""informe-sobre-tendencia-l.pdf""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""318"",""3626"",""335"",""3040"",""3306"",""3175"",""3310"",""3124"",""3709"",""1441"",""2174"",""3341"",""2178"",""1834"",""1953"",""2816"",""2839"",""1202"",""2019"",""3504"",""2152"",""3603"",""428"",""2085"",""3223"",""2320"",""1803"",""1867"",""2871"",""2630"",""1908"",""1982"",""2504"",""3078"",""2900"",""1903"",""2440"",""3023"",""746"",""1733"",""2311"",""1885"",""1975"",""2714"",""2692"",""3574"",""3373"",""3162"",""3364"",""3501"",""879"",""2923"",""2175"",""2582"",""2184""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""Author"",""Juan AndrĂŠs Topolansky""
""producer"",""MicrosoftÂŽ Word 2016""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""MicrosoftÂŽ Word 2016""
""pdf:docinfo:created"",""2020-07-24T22:35:59Z""
";https://scholar.google.ch/scholar?start=950&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098897-406;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Resumen de tesis. Arquitectura inteligente Edge Computing para entornos IoT;IX Sitton Candanedo ;2020 gredos.usal.es;;"… tiempo y coste de un operador de aplicaciones en ese punto. Blockchain Es una estructura de

datos en la que la información contenida se agrupa en conjuntos (bloques) a los que se les

a˜nade … EC Edge Computing BC Blockchain IoT Internet of Things CC Cloud Computing …";Autres articles;Version HTML;[PDF] usal.es;https://gredos.usal.es/bitstream/handle/10366/143827/REDUCIDA_SittonI.pdf?sequence=1;"
Universidad de Salamanca

Departamento de Informática y Automática

Facultad de Ciencias

Tesis Doctoral

Arquitectura Inteligente Edge Computing para
entornos IoT

Autora:

Inés Sittón Candanedo

Director:

Dr. Juan Manuel Corchado RodŕĹguez

Codirectora:

Dra. Sara RodŕĹguez González

Salamanca, 2020





Papá, mamá, esto es por y para ustedes...
A mi abuela Idalina, la mujer más fuerte que he conocido...

iii









Resumen

El Internet de las Cosas es una de las tecnoloǵĹas disruptivas que mayor interés ha

generado en los últimos años, no solo en el ámbito de la investigación cient́Ĺfica, sino

también en el sector gubernamental y empresarial. Su incorporación a todos los entornos

de actividad humana y social como: los servicios públicos, agricultura, industria,

economĹ́a, educación o salud, permite obtener datos desde cualquier dispositivo

conectado a una red.

El principal problema de la acelerada integración de Internet de las Cosas es la gestión

del gran volumen de datos generados constantemente por los dispositivos conectados, es

decir, su procesamiento, distribución y almacenamiento, para que posteriormente sean

utilizados a modo de información en los procesos de inteligencia de negocios.

La tesis doctoral que se presenta propone una solución tecnológica que consiste en el

diseño de una arquitectura global que integra tecnoloǵĹas del Edge Computing (EC) y

el Internet de las Cosas (IoT), que permita su implementación en una diversidad de

escenarios.

La arquitectura propuesta en esta investigación se denomina Global Edge Computing

Architecture (GECA) y contribuye a un procesamiento eficiente de los datos que son

generados por el creciente número de dispositivos IoT, que actualmente forman parte de

nuestro entorno.

En este trabajo se presenta la descripción conceptual y técnica de la arquitectura

propuesta, aśĹ como el componente experimental del estudio, que consistió en la ejecución

de pruebas de la arquitectura GECA en entornos reales. Para lograrlo se establecieron

dos escenarios de prueba mediante la integración de dispositivos IoT con la tecnoloǵĹa

EC.

El primero es un caso de estudio del sector Smart Farming, en una granja mixta de

producción de leche, ubicada en la provincia de Zamora, Comunidad Autónoma de

Castilla y León. El segundo se realizó en las instalaciones del Grupo de Investigación

BISITE de la Universidad de Salamanca, incorporando al análisis experimental un

escenario Smart Energy.

Ambos casos de estudio están orientados a lograr maximizar los beneficios y aportes para

la gestión eficiente y segura de los datos en las organizaciones. Las capas que componen

la arquitectura propuesta han sido diseñadas para gestionar en el Edge la información

que es recibida de la red de sensores inteligentes instalada.



Para la realización de diagnósticos y presentación de resultados se proponen técnicas de

Data Analytics y Machine Learning. La seguridad en la arquitectura propuesta inicia

en la capa base con el cifrado los datos generados por los sensores para procesarlos

posteriormente en la capa Edge. Adicionalmente se incluye una descripción de la

implementación de GECA en sistemas basados en otros framework como es el caso

del CAFCLA.

Finalmente, hemos evaluado la viabilidad de la capa Edge y los beneficios que se pueden

obtener al reducir los costes asociados con el consumo de ancho de banda, transferencia

y almacenamiento de datos en el Cloud.



Abstract

The Internet of Things is a disruptive technology that has, in recent years, attracted

much attention of the scientific community, the government and the business sector. The

incorporation of IoT into all areas of human and social activity, such as public services,

agriculture, industry, economy, education or health, will make it possible to obtain data

from any network-connected device.

However, the rapid implementation of the Internet of Things is being hindered by limited

data management i.e. the lack of capacity to process, distribute and store large volumes

of data. IoT-connected devices generate data constantly but the IoT paradigm will not

be effective if it is not possible to extract valuable information and apply it in business

intelligence processes.

This doctoral thesis proposes an effective technological solution to this problem through

the development of an architecture called the Global Edge Computing Architecture

(GECA). GECA integrates Edge Computing (EC) and Internet of Things (IoT)

technologies for the efficient processing of the data generated by the ever-increasing

number of IoT devices in our environment.

This research presents the conceptual and technical description of the proposed

architecture, it also details the experimental phase, which consisted in the testing of

the GECA architecture in two scenarios in real environments.

The first one is a case study of the Smart Farming sector, conducted on a mixed

dairy production farm, located in the province of Zamora, Castilla y León Autonomous

Community. The second one was carried out at the facilities of the BISITE Research

Group of the University of Salamanca, in which the experimental analysis involved a

Smart Energy scenario.

Both case studies have been conducted with the aim of maximizing the benefits and

contributions of GECA to the efficient and safe management of data in organizations.

The layers that make up the proposed architecture have been designed to manage the

information that is received from the deployed smart sensor network.

The base layer of the proposed architecture ensures security through the encryption of

the data obtained from sensors. Encrypted data are processed at a later stage in the

edge layer. Additionally, GECA’s performance has also been studied in systems based on



other frameworks, such as CAFCLA. Data Analytics and Machine Learning techniques

are proposed as tools for diagnoses and the outcomes are presented.

Finally, we have evaluated the feasibility of the Edge layer and the benefits that can be

obtained from reducing the costs associated with bandwidth consumption and with the

transfer and storage of data in the Cloud.



Agradecimientos

Al finalizar una etapa más en el camino, inicio agradeciendo a mis directores:

Juan Manuel y Sara, porque quizá sin imaginarlo me han acompañado desde

el 2015, primero en la distancia y luego al incorporarme al Grupo BISITE,

gracias a ambos por vuestra confianza y apoyo durante estos años. A Juan

Manuel mi admiración y respeto por su trabajo, visión de futuro e ideas que lo

cambian todo y llegan siempre en el mejor momento.

Sara, hoy y siempre GRACIAS por indicarme el camino a seguir, por soportar

la carga de correos que van y vienen. Por tu infinita paciencia para guiarme,

por las revisiones, los cafés y las risas; sin tu apoyo no lo habŕĹa logrado.

Mamá, papá, habéis tenido una vida llena de esfuerzos y privaciones para

darnos a mi hermano y a mĹ́ todo lo que estaba a vuestro alcance para

educarnos. Gracias por todo, llegar hasta aqúĹ no habŕĹa sido posible sin

vosotros. Que la vida nos permita recuperar estos años que la distancia y

este proyecto les han arrebatado.

Yen, gracias por tu apoyo, cariño y motivación para ir siempre a por más.

Este trabajo también es el resultado de tu esfuerzo.

Sof́Ĺa, mia principessa per sempre, posiblemente en este momento no

comprendas mis palabras. Hija, gracias por ser la mejor compañera en este

viaje, por tu eterna sonrisa y tus abrazos infinitos que hacen los d́Ĺas más

cortos y las cargas más livianas.

A mi hermano, que quizá sin saberlo, me ha enseñado que no importa lo dif́Ĺcil

que sea el camino, o cuanto peso lleves sobre los hombros, siempre es necesario

encontrar un motivo para réĹr.

Gracias a mis t́Ĺos Fernando y Vilma, aśĹ como a Deyka, quienes nos

extendieron su mano y confianza para la obtención de esta beca. Mi cariño

y gratitud por todo vuestro apoyo incondicional.

Ricardo y Óscar, “edgecolegas” gracias por las trasnochadas, las correcciones,

los consejos, los ánimos y todo el esfuerzo que habéis realizado durante este

último año de trabajo en equipo. Sin café panameño, gif, emojis y buen humor

la inspiración no llega.

Elena y Sara (en Salamanca) Deyka y Margareth (en la distancia), estos años

me han acompañado haciendo ruido o en silencio, con risas o lágrimas, cada

d́Ĺa bueno o malo, pero siempre ah́Ĺ. Gracias por sus interminables consejos,

xv



habéis sido amigas, maestras de la vida, soporte y compañ́Ĺa. ¥Que sean muchos

años más aśĹ!

A mis Abuelos y Aura, gracias por cuidar de mĹ́, ser ejemplo de dedicación,

trabajo y amor. Mi agradecimiento a todos los t́Ĺos, primos, sobrinos o amigos,

que en su d́Ĺa a d́Ĺa han acompañado y cuidado de mis padres en momentos

complicados, y también se han hecho presentes mediante sus mensajes. Mi

gratitud a todo el equipo BISITE, no sólo por recibirme, sino también por

las enseñanzas, el tiempo, los cafés, las risas y los momentos que siempre

permanecerán en mi recuerdo.

Finalmente, al Programa de Becas IFARHU-SENACYT por permitirme

completar una etapa más de formación.



Tabla de Contenido

Autorización del Director v

Aceptación escrita de los coautores de los art́Ĺculos presentados v

Aceptación escrita de los coautores de los art́Ĺculos presentados v

Aceptación escrita de los coautores de los art́Ĺculos presentados v

Resumen xi

Abstract xiii

Agradecimientos xv

Glosario xxi

Siglas y acrónimos xxiii

1 Introducción 1

1.1 Planteamiento del Problema . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.2 Motivación e hipótesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.3 MetodoloǵĹa de Investigación . . . . . . . . . . . . . . . . . . . . . . . . . 8

1.4 Estructura de la memoria . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2 Estado del Arte 13

2.1 Edge Computing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.2 Escenarios Edge Computing . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.2.1 Industria 4.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.2.2 Smart Farming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

2.2.3 Smart Energy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

2.3 Arquitecturas de Referencia Edge Computing . . . . . . . . . . . . . . . . 24

2.3.1 FAR-Edge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

2.3.2 Edge Computing 2.0. . . . . . . . . . . . . . . . . . . . . . . . . . . 27

2.3.3 Industrial Internet Consortium . . . . . . . . . . . . . . . . . . . . 30

xvii



Tabla de Contenido xviii

2.3.4 INTEL-SAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

2.4 Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

3 Contribuciones 35

3.1 Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

3.2 Arquitectura propuesta . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

3.3 Descripción técnica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

3.3.1 IoT-Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

3.3.2 Edge Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

3.3.3 Business Solution Layer . . . . . . . . . . . . . . . . . . . . . . . . 47

3.4 GECA en un escenario de Smart Farming . . . . . . . . . . . . . . . . . . 49

3.4.1 Experimentación y resultados . . . . . . . . . . . . . . . . . . . . . 50

3.5 GECA para Smart Energy . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

3.5.1 Un Estudio de Mapeo Sistemático de la Literatura . . . . . . . . . 54

3.5.1.1 Experimentación y resultados . . . . . . . . . . . . . . . . 55

3.5.2 GECA aplicado a un escenario smart energy . . . . . . . . . . . . 60

3.5.2.1 Descripción . . . . . . . . . . . . . . . . . . . . . . . . . . 60

3.5.2.2 Experimentación y resultados . . . . . . . . . . . . . . . . 62

3.6 Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

4 Publicaciones acreditativas de la investigación realizada 67

4.1 A Review of Edge Computing Reference Architectures and a New Global
Edge Proposal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

4.1.1 Información de la publicación . . . . . . . . . . . . . . . . . . . . . 69

4.1.2 Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

4.1.3 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

4.1.4 Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

4.1.5 Publicación Original . . . . . . . . . . . . . . . . . . . . . . . . . . 71

4.2 A Review on Edge Computing in Smart Energy by means of a Systematic
Mapping Study. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

4.2.1 Información de la publicación . . . . . . . . . . . . . . . . . . . . . 89

4.2.2 Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

4.2.3 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

4.2.4 Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

4.2.5 Publicación Original . . . . . . . . . . . . . . . . . . . . . . . . . . 91

4.3 Edge computing, IoT and Social Computing in Smart Energy Scenarios . 125

4.3.1 Información de la publicación . . . . . . . . . . . . . . . . . . . . . 125

4.3.2 Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125

4.3.3 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126

4.3.4 Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127

4.3.5 Publicación Original . . . . . . . . . . . . . . . . . . . . . . . . . . 127

5 Evidencias y Resultados 149

5.1 Publicaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151

5.1.1 Publicaciones en revistas cient́Ĺficas internacionales . . . . . . . . . 151

5.1.2 Publicaciones en congresos internacionales y workshops . . . . . . 152

5.2 Proyectos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153



Tabla de Contenido xix

6 Conclusiones 155

6.1 Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157

6.2 Trabajo futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162

Bibliograf́Ĺa 165





Glosario

Internet of Things La ITU (International Telecommunication Union) y el IERC

(Internet of Things European Research Cluster), lo definen

como: “una infraestructura de Red Global y dinámica con la

auto-configuración de las capacidades basadas en protocolos de

comunicación estándar e inter-operables, donde “cosas” f́ısicas

y virtuales tienen identidad, atributos f́Ĺsicos, personalidades

virtuales y utilizan interfaces inteligentes que se integran a la

perfección en la red de información”.

Cloud Computing Un sistema para proporcionar acceso bajo demanda a un conjunto

compartido de recursos informáticos, incluyendo servidores de red,

almacenamiento y servicios de computación.

Edge Computing Plataforma abierta distribuida en el borde de la red, cerca de las

cosas o fuentes de datos, e integrando las capacidades de redes,

almacenamiento y aplicaciones.

Edge devices Dispositivo para recopilar y procesar los datos. También puede

utilizar la capacidad limitada de almacenamiento de datos y

computación de dispositivos de usuario tales como teléfonos

inteligentes, ordenadores portátiles y sensores para procesar cargas

de trabajo de computación de borde.

Edge Node Un nodo de cálculo, como un servidor individual u otro conjunto de

recursos informáticos, operado como parte de una infraestructura

Edge Computing.

Centro de Datos Se refiere a un nodo de cálculo y almacenamiento de datos en

algunos contextos. VaŕĹa en escala entre un centro de datos

centralizado, un centro de datos regional y un centro de datos

de extremo.

xxi



Glosario xxii

Latencia En el contexto de la transmisión de datos en red, el tiempo que

tarda una unidad de datos (normalmente una trama o un paquete)

en viajar desde su dispositivo de origen hasta su destino previsto.

Medido en términos de mili-segundos en puntos únicos o repetidos

en el tiempo entre dos o más puntos finales.

Orquestación El proceso de determinar dónde y cómo se debe procesar una

carga de trabajo de aplicaciones en el gradiente de n-niveles de

los recursos de computación, almacenamiento de datos y red

proporcionados por el edge. En la mayoŕĹa de los casos, la

orquestación de la carga de trabajo se realiza mediante un sistema

automatizado que tiene en cuenta los requisitos de rendimiento,

tiempo y coste de un operador de aplicaciones en ese punto.

Blockchain Es una estructura de datos en la que la información contenida

se agrupa en conjuntos (bloques) a los que se les añade

metainformaciones relativas a otro bloque de la cadena anterior

en una ĺĹnea temporal, de manera que gracias a técnicas

criptográficas, la información contenida en un bloque solo puede

ser repudiada o editada modificando todos los bloques posteriores.



Siglas y acrónimos

EC Edge Computing

BC Blockchain

IoT Internet of Things

CC Cloud Computing

MQTT Message Query Telemetry Transport

RA Reference Architecture

ECC Edge Computing Consortium

ICC Industrial Internet Consortium

GECA Global Edge Computing Architecture

M2M Machine 2 (to) Machine

BLE Bluetooth Low Energy

ML Machine Learning

LoRa Long Range

WiFi Wireless Fidelity

UNB Ultra Narrow Band

SMP Systematic Mapping Study

GPRS General Packet Radio Service

CAFCLA Context Aware Framework for Collaborative

Learning Activities

xxiii



Siglas y acrónimos xxiv

CS Cloud Services

SE Smart Energy

SF Smart Farming

EN Edge Nodes

SoC System on a Chip

JSON Java Script Object Notation

API Application Pprogramming Interface

HTTP HTyperText Transfer Protocol

XML eXtensible Markup Lenguage

SOAP Simple Object Access Protocol



CaṕĹtulo 1

Introducción





CaṕĹtulo 1

Introducción

1.1 Planteamiento del Problema

Las actividades que se desarrollan actualmente a nivel tecnológico, empresarial e

industrial, se basan cada d́Ĺa más en los datos que producen los dispositivos de Internert

de las Cosas (Internet of Things, por sus siglas en inglés IoT). En consecuencia,

las organizaciones enfrentan un crecimiento del IoT, impulsado por el volumen de

dispositivos que forman parte de su entorno: sensores, actuadores, teléfonos inteligentes,

monitores portátiles de actividad f́Ĺsica, por mencionar sólo algunos. Todos estos equipos

tienen en común su capacidad para generar, monitorizar, enviar, recibir e incluso analizar

grandes cantidades de datos [Capra et al., 2019] .

El paradigma IoT ha revolucionado los modelos de negocios y la vida de los usuarios,

debido a la disminución de los costes de producción de dispositivos y el incremento de

la demanda. Una tendencia que como se observa en la Figura 1.1, se ha incrementado

rápidamente con el avance de los años, aśĹ lo afirman Yang et al. [2019] que utilizan los

datos de Gartner 1 (empresa de investigación y asesoramiento empresarial) y señalan que

en 2020 se espera una producción de dispositivos IoT aproximadamente de 30 billones

de unidades.

Esta evolución del IoT genera una gama de oportunidades de negocios, pero también

un conjunto de requisitos como: aplicaciones que demandan una retroalimentación o

respuesta constante, donde los datos generados (la mayoŕĹa sólo útiles por un peŕĹodo

de tiempo), se procesen, almacenen y analicen en tiempo real. En consecuencia, los

modelos tradicionales basados en el CC, en cuyo esquema el flujo de datos es único

desde su fuente de origen hasta el Cloud, no tienen la capacidad de gestionar grandes

1Gartner Website. Available online: http://www.gartner.com



4 CaṕĹtulo 1. Introducción

Fig. 1.1: Evolución de dispositivos IoT, basado en el trabajo de Capra et al. [2019]

volúmenes de datos, sin incrementar la latencia de la red, el consumo y los costes

inherentes al ancho de banda y los centros de almacenamientos públicos o privados

[BOSCH, 2018]. Adicionalmente, Damianou et al. [2019] plantean otro de los problemas

de los modelos basados en CC: la vulnerabilidades de seguridad y privacidad. En este

sentido, los entornos IoT se enfrentan a un creciente número de ataques, producto de la

heterogeneidad de las soluciones.

Para encontrar una solución a los requerimientos de IoT, los investigadores han centrado

su interés en un nuevo paradigma: la computación de borde o Edge Computing (EC).

El propósito de este enfoque es mitigar la latencia y los costes asociados al CC, pero sin

excluirlo de las soluciones para los entornos IoT [BOSCH, 2018, Capra et al., 2019].

Abordar los desaf́Ĺos del IoT descritos anteriormente, requiere una solución más compleja

que integre EC con métodos y tecnoloǵĹas de seguridad cibernética. Por esta razón en

este trabajo se considera la aplicación del Blockchain para mitigar los problemas de

seguridad.

La integración de EC con Blockchain para entornos IoT, puede proporcionar: (i) accesos

y controles seguros a la red; (ii) procesamiento y almacenamiento seguro de los datos; y

(iii) escalabilidad, computación distribuida y gestión de los recursos desde el borde de

la red [Yang et al., 2019]



Arquitectura Inteligente Edge Computing para entornos IoT 5

Debido al panorama tecnológico descrito, esta tesis doctoral aborda los desaf́Ĺos de IoT y

sus entornos heterogéneos al proponer una Arquitectura Inteligente Edge Computing que

integra la tecnoloǵĹa Blockchain desde el primer nivel, es decir, a partir de la fuente que

genera los datos. La memoria que se presenta esta basada en el modelo de compendio

de art́Ĺculos y se estructura en caṕĹtulos. El primero es una Introducción en la que

se explica la motivación, hipótesis y objetivos de la investigación. Posteriormente el

CaṕĹtulo 2 presenta un estado del arte de las tecnoloǵĹas aplicadas (EC y Blockchain)

y los escenarios en los que previamente se han validado. El CaṕĹtulo 3 profundiza en el

planteamiento del problema y describe la Arquitectura propuesta como solución.

Para evidenciar los resultados obtenidos, en el CaṕĹtulo 4 se incluyen las publicaciones

que se han realizado en revistas, congresos y workshops, relacionadas con esta tesis

doctoral, aśĹ como los proyectos que han sustentado el desarrollo de la investigación. En

el CaṕĹtulo 5 se presentan las publicaciones originales que soportan está memoria en el

formato de compendio de art́Ĺculos, cada uno de ellos precedido por una introducción,

objetivos y los resultados obtenidos. Finalmente, las conclusiones y trabajo futuro de

investigación que se han generado a ráĹz de esta tesis doctoral se detallan en el CaṕĹtulo

6.

1.2 Motivación e hipótesis

El Cloud Computing (CC), es una tecnoloǵĹa que ha permitido incrementar la capacidad

de computo y la prestación de servicios a través de Internet, durante los últimos

años ha sido de considerable interés tanto para el mundo académico como para las

organizaciones [De la Prieta and Corchado, 2016, Wang et al., 2015], sin embargo, los

datos masivos procedentes de los entornos IoT plantean un desaf́Ĺo importante para las

actuales soluciones del CC.

Una adecuada comprensión de las limitaciones del CC ante los rendimientos del IoT

como: usuarios que buscan respuestas en tiempo real, gran variedad de tipos de

datos, diferentes protocolos de comunicación, entre otros; ha originado nuevas ĺĹneas

de investigación para encontrar soluciones h́Ĺbridas [Larkin et al., 2014, Wells et al.,

2014].



6 CaṕĹtulo 1. Introducción

Estas caracteŕĹsticas del IoT añaden más carga a las redes, lo que resulta en un aumento

de la latencia y del almacenamiento y altos costes de ancho de banda [Ai et al., 2018].

Otros desaf́Ĺos que no puede solucionar una arquitectura basada CC para IoT, los define

Ai et al. [2018]:

• Seguridad e integridad de los datos: los dispositivos periféricos IoT actuales en su

mayoŕĹa tienen una capacidad de procesamiento limitada, pequeñas cantidades de

memoria y un sistema operativo restringido. En consecuencia, el dispositivo no es

apto para implementar los mecanismos de seguridad y protección de los flujos de

datos, que demanda una conexión constante a Internet.

• Heterogeneidad de dispositivos IoT: la gran diversidad de sensores, actuadores,

teléfonos inteligentes, tabletas, pulseras inteligentes, ordenadores portátiles, etc.,

con diferentes protocolos y estándares, provoca incompatibilidades y problemas

en procesos básicos como la comunicación y la transmisión de los datos desde su

origen hasta el cloud.

• Solicitudes de servicio y respuestas: muchas aplicaciones de IoT (coches

autónomos, aplicaciones de salud, de ciudades inteligentes o comunicaciones con

control táctil en diversos sectores), requieren una respuesta en tiempo real y con

baja latencia. Por lo tanto, el procesamiento remoto de los datos que se utiliza

en el esquema CC tradicional, ocasiona una elevada latencia en la transmisión a

larga distancia y un incremento en el consumo de ancho de banda.

Estas caracteŕĹsticas forman parte de la motivación para las investigaciones que proponen

el Edge Computing como una alternativa que permita procesar y filtrar grandes

cantidades de datos en el borde de la red antes de transmitirlos al cloud; los beneficios de

esto incluyen la reducción de los costes de ancho de banda, almacenamiento y consumo

de enerǵĹa [Shi and Schahram, 2016]. Por lo tanto, al integrar una arquitectura EC con

IoT, las aplicaciones y los servicios proporcionan a los usuarios respuestas más rápidas,

eficientes y seguras [Ai et al., 2018].

El término Edge Computing no es nuevo, su origen se remonta a los años 90, cuando

Akami Technologies lo acuñó para referirse a las redes de entrega de contenido (CDN, por

sus siglas en inglés ”Content Delivery Networks”). Posteriormente, en 2016, es cuando



Arquitectura Inteligente Edge Computing para entornos IoT 7

el término empieza a despertar el interés de organizaciones, gobiernos, universidades e

investigadores por su potencial para facilitar el despliegue de IoT.

Uno de los primeros escenarios en los que se ha validado la utilidad del Edge Computing

ha sido la Industria 4.0., donde organizaciones como INTEL, SAP o el Edge Computing

Consortium, lo han presentado como una alternativa para solventar los problemas que

generan los grandes flujos de datos generados por los dispositivos IoT y permitir que se

optimicen los procesos de cómputo al no depender del CC para la ejecución de los mismos

[Edge Computing Consortium and Alliance of Industrial Internet, 2017, FAR-EDGE,

2017, INTEL-SAP, 2018].

En el caso de Blockchain, basado en procesos de mineŕĹa, permite la validación de

transacciones mediante un ledger (se asocia al concepto de libro contable) con una lista

verificada y segura de información. La mineŕıa inicia cuando ”los mineros” requieren

verificar las transacciones. Para ejecutar el proceso se utilizan mecanismos de consenso,

es decir, cada bloque de la cadena se identifica con un valor Hash de cabecera, más la

información que contiene [Yang et al., 2019]. Las funciones Hash se utilizan en BC para

comprimir datos heterogéneos con longitudes variables o e-bits [Liang et al., 2018].

Las ventajas de aplicar BC sobre IoT se han presentado anteriormente, por ejemplo en

Dorri et al. [2017a,b], se describen arquitecturas que se basan en BC y servicios CC,

indicando que la capacidad de los dispositivos IoT es limitada en cuanto a procesamiento

y/o almacenamiento de datos. Como alternativa, los autores proponen utilizar el CC

para almacenar los registros de todas las transacciones que se realizan. Para Damianou

et al. [2019], la opción de implementar directamente BC no es una solución eficiente para

los escenarios en tiempo real, por el tiempo que consumen los procesos y lo que tardan

en dar respuesta al usuario final.

En este sentido, la integración de BC y EC permitiŕĹa que la seguridad de la red,

la integridad de los datos y la validez de los cálculos de un sistema mejorasen

considerablemente. Por otro lado, esta unión dotaŕĹa a los sistemas de mayores recursos

computacionales, almacenamiento distribuidos desde el borde de la red y escalabilidad

Liu et al. [2017], Samaniego and Deters [2017], Sharma et al. [2017]. Para efectos de

esta investigación se ha establecido como hipótesis de partida que: mediante el diseño

de una arquitectura modular basada en Edge Computing es posible la gestión inteligente

y segura de soluciones dirigidas a entornos IoT.



8 CaṕĹtulo 1. Introducción

El estado actual de las soluciones existentes orientadas a entornos IoT y el desarrollo de

nuevas tecnoloǵĹas como el EC, figuran como la principal motivación que ha impulsado

la realización de esta investigación. En este sentido, como objetivo principal se propone:

el establecimiento de una nueva arquitectura basada en un diseño modular y escalonado,

denominada Global Edge Computing Architecture (GECA), que permita gestionar

soluciones complejas dirigidas a una amplia gama de entornos de IoT, mediante la

incorporación de Edge Computing y Blockchain para ofrecer datos, aplicaciones y

servicios más seguros.

Para alcanzar el objetivo principal, es necesario definir un listado de objetivos espećĹficos,

que se describen en el siguiente orden:

• (OB1) Realizar un estudio del estado del arte de Edge Computing, las tendencias

y desaf́Ĺos de esta tecnoloǵĹa disruptiva.

• (OB2) Identificar los requerimientos existentes en los entornos IoT y que se pueden

robustecer a través de soluciones basadas en Edge Computing.

• (OB3) Revisar las arquitecturas de referencia existentes en las que el Edge

Computing es el eje principal.

• (OB4) Desarrollar un estudio de mapeo sistemático de la literatura para identificar

si existen soluciones Edge Computing aplicadas a Smart Energy y qué ĺĹneas

futuras de investigación se pueden definir en este contexto.

• (OB5) Diseñar una arquitectura modular y escalonada para entornos del IoT.

• (OB6) Proporcionar un conjunto de tecnoloǵıas asociadas que se integren con el

Edge Computing y el IoT de forma sencilla y a bajo coste.

• (OB7) Desplegar la arquitectura propuesta en casos de estudio que permitan su

validación y evaluación en escenarios reales.

1.3 MetodoloǵĹa de Investigación

La metodoloǵĹa Action-Research (acción-investigación) ha ganado importancia en los

proyectos de IngenieŕĹa de Software, donde por sus caracteŕĹsticas, su aplicación



Arquitectura Inteligente Edge Computing para entornos IoT 9

resulta beneficiosa para la investigación en el campo, ya que simultáneamente permite

la realización de investigaciones y acciones. La acción generalmente se asocia con

una transformación en una determinada comunidad, organización o proyecto, y la

investigación se distingue por una amplia comprensión de un fenómeno de cambio por

parte del investigador (comunidad investigadora), persona (cliente), o ambos. Baskerville

et al. [1999] han indicado que la MetodoloǵĹa de Investigación - Acción es el tipo de

estudio donde se encuentra el escenario de mayor realismo al involucrar un contexto real

para investigar los resultados de acciones concretas.

De acuerdo con Baskerville et al. [1999], citado por Tüzün et al. [2019], los estudios

desarrollados bajo esta metodoloǵĹa comparten cuatro caracteŕĹsticas comunes: (1) Una

orientación a la acción y al cambio; (2) Un enfoque del problema; (3) Un proceso

orgánico que implica etapas sistemáticas y a veces iterativas; (4) Colaboración entre

los participantes. En general, la investigación-acción consta de cinco fases [Eden and

Ackermann, 2018, Pinzon-Trejos, 2010, Tüzün et ";"""date"",""2020-08-27T10:19:41Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""1"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.6""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dcterms:created"",""2020-08-27T10:16:34Z""
""language"",""es""
""Last-Modified"",""2020-08-27T10:19:41Z""
""dcterms:modified"",""2020-08-27T10:19:41Z""
""dc:format"",""application/pdf; version=1.6""
""xmpMM:DocumentID"",""uuid:d42f1ce8-95d4-4257-9b42-2afd818953c1""
""Last-Save-Date"",""2020-08-27T10:19:41Z""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2020-08-27T10:19:41Z""
""meta:save-date"",""2020-08-27T10:19:41Z""
""pdf:encrypted"",""false""
""xmp:CreateDate"",""2020-08-27T12:16:34Z""
""modified"",""2020-08-27T10:19:41Z""
""Content-Length"",""3525817""
""pdf:hasMarkedContent"",""false""
""Content-Type"",""application/pdf""
""xmp:ModifyDate"",""2020-08-27T12:19:41Z""
""xmp:MetadataDate"",""2020-08-27T12:19:41Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""pdf:producer"",""www.ilovepdf.com""
""meta:creation-date"",""2020-08-27T10:16:34Z""
""created"",""2020-08-27T10:16:34Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""114""
""Creation-Date"",""2020-08-27T10:16:34Z""
""resourceName"",""REDUCIDA_SittonI.pdf""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""263"",""0"",""89"",""0"",""0"",""0"",""2027"",""545"",""1951"",""307"",""1898"",""575"",""1003"",""2283"",""155"",""0"",""1329"",""977"",""459"",""240"",""23"",""0"",""1550"",""1261"",""1955"",""1988"",""2242"",""1652"",""2175"",""1906"",""385"",""0"",""23"",""0"",""1465"",""2119"",""2865"",""1884"",""1994"",""2236"",""2093"",""2095"",""2075"",""2119"",""1875"",""1370"",""1921"",""426"",""182"",""1471"",""125"",""1810"",""130"",""1764"",""24"",""0"",""1634"",""1805"",""543"",""93"",""2128"",""1760"",""2012"",""1722"",""1194"",""1799"",""2031"",""1990"",""1860"",""2012"",""1743"",""2226"",""2135"",""1492"",""1520"",""1392"",""753"",""1790"",""158"",""1937"",""2192"",""886"",""1115"",""1752"",""1381"",""731"",""0"",""31"",""0"",""1185"",""1802"",""1575"",""1145"",""22"",""0"",""1359"",""1954"",""1994"",""2137"",""1806"",""1862"",""1385"",""0"",""1392"",""1712"",""1623"",""1825"",""1732"",""1711"",""1733"",""1607"",""1735"",""1758"",""1447""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""producer"",""www.ilovepdf.com""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""www.ilovepdf.com""
""pdf:docinfo:created"",""2020-08-27T10:16:34Z""
";https://scholar.google.ch/scholar?start=950&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098782-150;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Anwendungsoptionen;HG Fill, A Meier ; Blockchain kompakt, 2020  Springer;;"… Sogenannte „Oracles“ bieten einen Lösungsansatz, um dennoch mit Daten ausserhalb

der Blockchain zu interagieren. Zentrale Idee dabei ist, dass von einem Smart Contract

eine Anfrage an einen speziellen Oracle-Contract gesendet wird …";Autres articles;;null;;;;https://scholar.google.ch/scholar?start=690&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098870-348;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Qma-hardness of consistency of local density matrices with applications to quantum zero-knowledge;A Broadbent, AB Grilo ; 2020 IEEE 61st Annual Symposium on …, 2020  ieeexplore.ieee.org;;"… in QMA and that it is QMA-hard under Turing reductions, ie, a deterministic polynomial time

algorithm with access to an oracle that solves … that the prover randomly permutes the colours to

obtain colouring c, and produces a list (vi, commit(c(vi))), using a crypto- graphic primitive …";Cité 4 fois;;[PDF] uni-muenchen.de;https://indico.physik.uni-muenchen.de/event/84/attachments/243/396/S2.BredariolGrilo.abstract.pdf;"
QMA-hardness of Consistency of Local Density Matrices
with Applications to Quantum Zero-Knowledge

Anne Broadbent ∗ Alex B. Grilo †

Abstract

We provide several advances to the understanding of the class of Quantum Merlin-Arthur proof sys-
tems (QMA), the quantum analogue of NP. Our central contribution is proving a longstanding conjecture
that the Consistency of Local Density Matrices (CLDM) problem is QMA-hard under Karp reductions. The input of
CLDM consists of local reduced density matrices on sets of at most k qubits, and the problem asks if there is an
n-qubit global quantum state that is locally consistent with all of the k-qubit local density matrices. The contain-
ment of CLDM in QMA and the QMA-hardness under Turing reductions were proved by Liu [APPROX-RANDOM
2006]. Liu also conjectured that CLDM is QMA-hard under Karp reductions, which is desirable for applications,
and we finally prove this conjecture. We establish this result using the techniques of simulatable codes of Grilo,
Slofstra, and Yuen [FOCS 2019], simplifying their proofs and tailoring them to the context of QMA.

In order to develop applications of CLDM, we propose a framework that we call locally simulatable proofs
for QMA: this provides QMA proofs that can be efficiently verified by probing only k qubits and, furthermore,
the reduced density matrix of any k-qubit subsystem of a good witness can be computed in polynomial time,
independently of the witness. Within this framework, we show several advances in zero-knowledge in the
quantum setting. We show for the first time a commit-and-open computational zero-knowledge proof system for
all of QMA, as a quantum analogue of a “sigma” protocol. We then define a Proof of Quantum Knowledge, which
guarantees that a prover is effectively in possession of a quantum witness in an interactive proof, and show that
our zero-knowledge proof system satisfies this definition. Finally, we show that our proof system can be used to
establish that QMA has a quantum non-interactive zero-knowledge proof system in the secret parameter setting.
Full version available at: arxiv:1911.077821

In a QMA proof system, an all-powerful prover produces a quantum proof that is verified by a quantum
polynomially-bounded verifier. Given the probabilistic nature of quantum computation, we require that for
true statements, there exists a quantum proof that makes the verifier accept with high probability (this is
called completeness), whereas all “proofs” for false statements are rejected with high probability (which is called
soundness). On top of being the generalization of one of the most important complexity classes, the importance
of QMA from a physical perspective comes from the fact that Kitaev also proved that a problem very relevant to
physics, the local Hamiltonian problem, is QMA-complete. Much follow-up work focused on understanding the
complete problems for QMA, mostly by improving the parameters of the QMA-hard Local Hamiltonian problem,
or making it closer to models more physically relevant, e.g. [7,14,16].

Despite the importance of this class, relatively few QMA-complete problems are known. In 2014, a survey of
QMA-complete languages [2] contained a list of 21 problems that are known to be QMA-complete2, and since
then, the situation has not drastically changed. This contrasts with the development of NP, where only a few years
after the developments surrounding 3–SAT, hundreds of NP-complete problems were known [10,15].

The Consistency of Local Density matrices problem (CLDM), is a related and conceptually interesting problem,
and is defined as follows. Given the classical description of local density matrices ρ1, ..., ρm, each on a set of at
most k qubits and for a global system of n qubits, is there a state τ that is consistent with such reduced states?
Liu [18] showed that this problem is in QMA and that it is QMA-hard under Turing reductions, i.e., a deterministic
polynomial-time algorithm with access to an oracle that solves CLDM in unit time can solve any problem in QMA;
however, Liu left as open problem to determine if CLDM is also QMA-complete under standard Karp reductions,
i.e., to show an efficient mapping between yes- and no-instances of any QMA problem to yes- and no-instances
of CLDM, respectively. We remark that Turing reductions are rather troublesome for QMA, since the class is not
∗University of Ottawa, Department of Mathematics and Statistics abroadbe@uottawa.ca
†Sorbonne Université, CNRS, LIP6 Alex.Bredariol-Grilo@lip6.fr
1An extended abstract is to appear in the Proceedings of FOCS (2020).
2We remark that these problems can be clustered as variations of a handful of base problems.

1

https://arxiv.org/abs/1911.07782


known (nor expected) to be closed under complement, i.e., it is widely believed that QMA 6= coQMA. If this is
indeed the case, then Turing reductions do not allow a black-box generalization of results regarding the CLDM
problem to all problems in QMA, and this highlights the importance of Karp reductions.

The main result of our work is to show that the CLDM problem is QMA-hard under Karp reductions, solving
the 14-year-old problem proposed by Liu [18].

Result 1. The CLDM problem is QMA-complete under Karp reductions.

To prove this result, we build on a tool developed in [13] called locally simulatable codes. Roughly, a code is
s-simulatable if there is a classical algorithm (the simulator), that can compute the reduced density matrix of the
encoding of some n-qubit state ρ on any set of at most s qubits of the encoding. Moreover, we also require that we
can compute the density matrices of the computation on encoded state.3 Importantly, the simulator must run in
time poly(n, 2s).4

In [13], the authors show that the concatenated Steane code is a locally simulatable code, using extensive
calculations with the stabilizers of such a code. A conceptual contribution of our work is to provide a simpler proof
of this fact, using solely the connections between quantum error correcting codes and secret sharing protocols [5].

We first recall the quantum Cook-Levin theorem proved by Kitaev [17]. In his proof, Kitaev uses the
circuit-to-Hamiltonian construction [8], mapping an arbitrary QMA verification circuit V = UT ...U1 to a local
Hamiltonian HV that enforces that low energy states are history states of the computation, i.e., a superposition of
the snapshots of V for every timestep 0 ≤ t ≤ T :

|Φ〉 =
1√
T + 1

∑
t=0...T+1

|t〉 ⊗ Ut . . . U1|ψinit〉. (1)

In the above, the first register is called the clock register, and it encodes the timestep of the computation, while the
second register contains the snapshot of the computation at time t, i.e., the quantum gates U1, ..., Ut applied to the
initial state |ψinit〉 = |φ〉|0〉⊗A, that consists of the quantum witness and auxiliary qubits. The Hamiltonian HV

also guarantees that |ψinit〉 has the correct form at t = 0, and that the final step accepts, i.e., the output qubit is
close to |1〉.

The solution is to consider a different verification algorithm V ′ that implements V on encoded data, much like
in the theory of fault-tolerant quantum computing. In more details, for a fixed locally simulatable code, V ′ expects
the encoding of the original witness Enc(|φ〉) and then, with her raw auxiliary states, she creates encodings of
auxiliary states Enc(|0〉) and magic states Enc(|MS〉), and then performs the computation V through transversal
gates and magic state gadgets, and finally decodes the output qubit. This gives rise to a new history state:

|Φ′〉 =
1√

T ′ + 1

∑
t=0...T ′+1

|t〉 ⊗ U ′t . . . U ′1|ψ′init〉, (2)

where |ψ′init〉 = Enc(|φ〉)|0〉⊗A′ and U ′1, ..., UT ′ are the gates of V ′ described above. Using the techniques from [13],
we can show that from the properties of the locally simulatable codes, the reduced density matrix on every set of 5
qubits of |Φ′〉 can be efficiently computed. In this work, we prove that these reduced density matrices are in fact
QMA-hard instances of CLDM. More concretely, we show that these reduced density matrices of a hypothetical
history state of an accepting QMA-verification can always be computed, and there exists a global state (namely the
history state) consistent with these reduced density matrices if and only if the original QMA verification accepts
with overwhelming probability (and therefore we are in the case of a yes-instance).

Applications to Zero-Knowledge Protocols

Intuitively, a proof system (such as QMA) is said to be zero-knowledge if the verifier does not learn anything from
interacting with the prover. This property is formalized by showing the existence of an efficient simulator, which is

3 This is reminiscent of the theory of fault-tolerant quantum computation, according to which some quantum error-correcting codes
allow computations over encoded data by using “transversal” gates and encoded magic states.

4Note that a straightforward classical simulation of a computation would lead to a runtime O(2n) and our simulation exponentially
improves on the dependency on n.

2



able to reproduce (i.e., simulate) the output of any given verifier on a yes instance (without having direct access to
the actual prover or witness). As paradoxical as it sounds, statistical zero-knowledge interactive proof systems are
known to be possible for a host of languages; their impact is profound and applicable to multiple areas, including
cryptography [11] and complexity theory [20].

Zero-Knowledge Proofs for QMA. There has been a recent effort to devise efficient and simpler zero-knowledge
protocols for QMA. We point out that Liu [18] observed very early on that the CLDM problem could admit a
simple zero-knowledge proof system following the “commit-and-open” approach, as in the 3-COL protocol (this is
called a ÎŁ-protocol). Inspired by this observation, recent progress has established the existence of zero-knowledge
protocols for all of QMA [3]. We note that although the proof system used there is reminiscent of a ÎŁ-protocol,
there are a number of reasons why it is not a “natural” quantum analogue of a Σ protocol (which we call a Ξ
protocol). These include: (i) the use of a coin-flipping protocol, increasing the communication cost; (ii) the
verifier’s message is not a random challenge; and (iii) the final answer is not restricted to the opening of some
committed values. In our work, we finally show a simple Ξ protocol for QMA via our hardness result for CLDM.

Result 2. All problems in QMA admit a computational zero-knowledge Ξ-proof system.

Zero-Knowledge Proofs of Knowledge (PoK). In a zero-knowledge proof, the verifier becomes convinced of the
existence of a witness, but this a priori has no bearing on the prover actually having in her possession such a
witness. In some circumstances, it is important to guarantee that the prover actually has a witness. This is the
realm of a zero-knowledge proof of knowledge (PoK) [1,12].

We give an example to depict this subtlety. Let us consider the task of anonymous credentials [4]. In this
setting, Alice wants to authenticate into some online service using her private credentials. In order to protect
her credentials, she could engage in a zero-knowledge proof; this, however would be unsatisfactory, since the
verifier in this scenario would be become convinced of the existence of accepting credentials, which does not
necessarily translate to Alice actually being in the possession of these credentials. To remedy this situation, the PoK
property establishes an “if-and-only-if” situation: if the verifier accepts, then we can guarantee that the prover
actually knows a witness. This notion is formally defined by requiring the existence of an extractor, which is a
polynomial-time process K that outputs a valid witness when given oracle access to some prover P ∗ that makes
the verifier accept with high enough probability.

In the quantum case, there has been some positive results in terms of the security of classical proofs of
knowledge for NP against quantum adversaries [19]. However, in the fully quantum case (that is, proofs of
quantum knowledge for QMA), no scheme has been proposed. One of the possible reasons why no such proof of
quantum knowledge protocols was proposed is the lack of a simple zero-knowledge proof for QMA.

We provide the definition of a Proof of Quantum Knowledge (PoQ).5 In short, we say that a proof system is
a PoQ if there exists a quantum polynomial-time extractor K that has oracle access to a quantum prover which
makes the verifier accept with high enough probability, and the extractor is able to output a sufficiently good
witness for a “QMA-relation”. We note that this definition for a PoQ is not a straightforward adaptation of the
classical definition; this is because NP has many properties such as perfect completeness, perfect soundness and
even that proofs can be copied, that are not expected to hold in the QMA case. We are then able to show that our
Ξ protocols for QMA described in Result 2 is a PoQ. This is the first proof of knowledge for QMA.6

Result 3. All problems in QMA admit a zero-knowledge proof of quantum knowledge proof system.

We remark that using techniques for post-hoc delegation of quantum computation [9], our PoQ for QMA may
be understood as a proof-of-work for quantum computations, since it could be used to convince a verifier that the
prover has indeed created the history state of some pre-defined computation. This is very relevant in the scenario
of testing small-scale quantum computers in the most adversarial model possible: the zero-knowledge property
ensures that the verifier learns nothing but the truth of the statement, while the PoQ property means that the
prover has indeed prepared a ground state with the given properties.

Remark 1. We note that in our work, we also present other results concerning the concept of locally simulatable
proofs, statistical zero-knowledge arguments and non-interactive zero-knowledge protocols in the secret parameters
scenario. Given that these contributions easily follow from the ones presented here, we omit them in this abstract.

5This definition is joint work with Coladangelo, Vidick and Zhang [6].
6See also independent and concurrent work by Coladangelo, Vidick and Zhang [6].

3



References

[1] M. Bellare and O. Goldreich. On defining proofs of knowledge. In CRYPTO 1992, pages 390–420, 1993.
DOI: 10.1007/3-540-48071-4 28.

[2] A. D. Bookatz. QMA-complete problems. Quant. Inf. Comp., 14(5&6):361–383, 2014.

[3] A. Broadbent, Z. Ji, F. Song, and J. Watrous. Zero-knowledge proof systems for QMA. SIAM J. Comp.,
49(2):245–283, 2020. DOI: 10.1137/18M1193530.

[4] D. Chaum. Blind signatures for untraceable payments. In CRYPTO 1983, pages 199–203, 1983.
DOI: 10.1007/978-1-4757-0602-4 18.

[5] R. Cleve, D. Gottesman, and H.-K. Lo. How to share a quantum secret. Phys. Rev. Lett., 83(3):648–651, 1999.
DOI: 10.1103/PhysRevLett.83.648.

[6] A. Coladangelo, T. Vidick, and T. Zhang. Non-interactive zero-knowledge arguments for QMA, with
preprocessing. In CRYPTO 2020, pages 799–828, 2020. DOI: 10.1007/978-3-030-56877-1 28.

[7] T. S. Cubitt and A. Montanaro. Complexity classification of local Hamiltonian problems. In FOCS 2014,
pages 120–129, 2014. DOI: 10.1109/FOCS.2014.21.

[8] R. P. Feynman. Simulating physics with computers. Internat. J. Theoret. Phys., 21(6):467–488, 1982.
DOI: 10.1007/BF02650179.

[9] J. F. Fitzsimons, M. Hajdušek, and T. Morimae. Post hoc verification of quantum computation. Phys. Rev.
Lett., 120(4):040501, 2018. DOI: PhysRevLett.120.040501.

[10] M. R. Garey and D. S. Johnson. Computers and Intractability; A Guide to the Theory of NP-Completeness. W.
H. Freeman & Co., 1990.

[11] O. Goldreich, S. Micali, and A. Wigderson. How to play any mental game. In STOC 1987, pages 218–229,
1987. DOI: 10.1145/28395.28420.

[12] S. Goldwasser, S. Micali, and C. Rackoff. The knowledge complexity of interactive proof systems. SIAM J.
Comp., 18(1):186–208, 1989. DOI: 10.1137/0218012.

[13] A. B. Grilo, W. Slofstra, and H. Yuen. Perfect zero knowledge for quantum multiprover interactive proofs. In
FOCS 2019, pages 611–635, 2019. DOI: 10.1109/FOCS.2019.00044.

[14] S. Hallgren, D. Nagaj, and S. Narayanaswami. The local Hamiltonian problem on a line with eight states is
QMA-complete. Quant. Inf. Comp., 13(9&10):721–750, 2013.

[15] R. M. Karp. Reducibility among combinatorial problems. In Complexity of Computer Computations, pages
85–103, 1972. DOI: 10.1007/978-1-4684-2001-2 9.

[16] J. Kempe, A. Kitaev, and O. Regev. The complexity of the local Hamiltonian problem. SIAM J. Comp.,
35(5):1070–1097, 2006. DOI: 10.1137/S0097539704445226.

[17] A. Y. Kitaev, A. Shen, and M. N. Vyalyi. Classical and Quantum Computation. American Mathematical Society,
2002.

[18] Y. Liu. Consistency of local density matrices is QMA-complete. In APPROX/RANDOM 2006, pages 438–449,
2006. DOI: 10.1007/11830924 40.

[19] D. Unruh. Quantum proofs of knowledge. In EUROCRYPT 2012, pages 135–152, 2012.
DOI: 10.1007/978-3-642-29011-4 10.

[20] S. Vadhan. The complexity of zero knowledge. In FSTTCS 2007, pages 52–70, 2007.
DOI: 10.1007/978-3-540-77050-3 5.

4

http://dx.doi.org/10.1007/3-540-48071-4_28
http://dx.doi.org/10.1137/18M1193530
http://dx.doi.org/10.1007/978-1-4757-0602-4_18
http://dx.doi.org/10.1103/PhysRevLett.83.648
http://dx.doi.org/10.1007/978-3-030-56877-1_28
http://dx.doi.org/10.1109/FOCS.2014.21
http://dx.doi.org/10.1007/BF02650179
http://dx.doi.org/PhysRevLett.120.040501
http://dx.doi.org/10.1145/28395.28420
http://dx.doi.org/10.1137/0218012
http://dx.doi.org/10.1109/FOCS.2019.00044
http://dx.doi.org/10.1007/978-1-4684-2001-2_9
http://dx.doi.org/10.1137/S0097539704445226
http://dx.doi.org/10.1007/11830924_40
http://dx.doi.org/10.1007/978-3-642-29011-4_10
http://dx.doi.org/10.1007/978-3-540-77050-3_5

";"""date"",""2020-11-17T09:31:20Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2020-11-17T09:31:20Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017/Debian) kpathsea version 6.2.3""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2020-11-17T09:31:20Z""
""created"",""2020-11-17T09:31:20Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-11-17T09:31:20Z""
""resourceName"",""S2.BredariolGrilo.abstract.pdf""
""Author"",""""
""producer"",""pdfTeX-1.40.18""
""pdf:docinfo:producer"",""pdfTeX-1.40.18""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""35"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2020-11-17T09:31:20Z""
""Last-Modified"",""2020-11-17T09:31:20Z""
""dcterms:modified"",""2020-11-17T09:31:20Z""
""title"",""""
""Last-Save-Date"",""2020-11-17T09:31:20Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2020-11-17T09:31:20Z""
""meta:save-date"",""2020-11-17T09:31:20Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017/Debian) kpathsea version 6.2.3""
""Content-Length"",""195362""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""4""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""3945"",""3583"",""4340"",""2466""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-11-17T09:31:20Z""
";https://scholar.google.ch/scholar?start=890&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098875-358;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;The measure-and-reprogram technique 2.0: multi-round Fiat-Shamir and more;J Don, S Fehr, C Majenz ; Annual International Cryptology Conference, 2020  Springer;;"… CRYPTO 2020: Advances in Cryptology – CRYPTO 2020 pp 602-631 | Cite as … works by Don,

Fehr, Majenz and Schaffner and by Liu and Zhandry on the security of the Fiat-Shamir (FS)

transformation of \(\varSigma \)-protocols in the quantum random oracle model (QROM) …";Cité 14 fois;Les 6 versions;[PDF] arxiv.org;https://arxiv.org/pdf/2003.05207;"
ar
X

iv
:2

00
3.

05
20

7v
2 

 [
cs

.C
R

] 
 2

7 
Ju

l 2
02

0

The Measure-and-Reprogram Technique 2.0: Multi-Round

Fiat-Shamir and More

Jelle Don1, Serge Fehr1,2, and Christian Majenz1,3

1 Centrum Wiskunde & Informatica (CWI), Amsterdam, Netherlands
2 Mathematical Institute, Leiden University, Netherlands

3 QuSoft, Amsterdam, Netherlands
jelle.don@cwi.nl, serge.fehr@cwi.nl, c.majenz@uva.nl

Abstract. We revisit recent works by Don, Fehr, Majenz and Schaffner and by Liu and
Zhandry on the security of the Fiat-Shamir transformation of ÎŁ-protocols in the quantum
random oracle model (QROM). Two natural questions that arise in this context are: (1)
whether the results extend to the Fiat-Shamir transformation of multi-round interactive
proofs, and (2) whether Don et al.’s O(q2) loss in security is optimal.
Firstly, we answer question (1) in the affirmative. As a byproduct of solving a technical
difficulty in proving this result, we slightly improve the result of Don et al., equipping it
with a cleaner bound and an even simpler proof. We apply our result to digital signature
schemes showing that it can be used to prove strong security for schemes like MQDSS in the
QROM. As another application we prove QROM-security of a non-interactive OR proof by
Liu, Wei and Wong.
As for question (2), we show via a Grover-search based attack that Don et al.’s quadratic
security loss for the Fiat-Shamir transformation of ÎŁ-protocols is optimal up to a small
constant factor. This extends to our new multi-round result, proving it tight up to a factor
that depends on the number of rounds only, i.e. is constant for any constant-round interactive
proof.

1 Introduction

Reprogramming the quantum random oracle. We reconsider the recent work of Don, Fehr,
Majenz and Schaffner [DFMS19] on the quantum random oracle model (QROM). On a technical
level, they showed how to reprogram the QROM adaptively at one input. More precisely, for any
oracle quantum algorithm AH , making q calls to a random oracle H and outputting a pair (x, z)
so that some predicate V (x,H(x), z) is satisfied, they showed existence of a “simulator” S that
mimics the random oracle, extracts x from AH by measuring one of the oracle queries to H , and
then reprograms H(x) to a given value Θ so that z output by AH now satisfies V (x,Θ, z), except
with a multiplicative O(q2) loss in probability (plus a negligible additive loss). We emphasize that
the challenging aspect of this problem is that AH ’s queries to H may be in quantum superposition,
and thus measuring such a query disturbs the state and thus the behavior of AH . Still, Don et
al. managed to control this disturbance sufficiently. In independent work and using very different
techniques, Liu and Zhandry [LZ19] showed a similar kind of result, but with a O(q9) loss.

As an immediate application of this technique, it is then concluded that the Fiat-Shamir trans-
formation of a ÎŁ-protocol is as secure (in the QROM) as the original ÎŁ-protocol (in the standard
model), up to a O(q2) loss, i.e., any of the typically considered security notions is preserved under
the Fiat-Shamir transformation, even in the quantum setting. In combination with prior work on
simulating signature queries [Unr17, KLS18], security (in the QROM) of Fiat-Shamir signatures
that arise from ordinary ÎŁ-protocols then follows as a corollary.

Given important examples of multi-round public-coin interactive proofs, used in, e.g., MQDSS
[CHR+16] and for Bulletproofs [BBB+18]1, a natural question that arises is whether these tech-
niques and results extend to the reprogrammability of the QROM at multiple inputs and the
security of the Fiat-Shamir transformation (in the QROM) of multi-round public-coin interactive
proofs. Another question is whether the O(q2) loss (for the original ÎŁ-protocols) is optimal, or
whether one might hope for a linear loss as in the classical case.

In this work, we provide answers to both these natural questions — and more.

1 The security of the original Bulletproofs protocol relies on the hardness of discrete-log; however, work
in progress considers post-quantum secure versions [Boo].

http://arxiv.org/abs/2003.05207v2


A technical hurdle for generalizing [DFMS19] to multi-round Fiat-Shamir. To start
with, we observe that the naive approach of applying the original result of [DFMS19] inductively
so as to reprogram multiple inputs one by one does not work. This is due to a subtle technical
issue that has to do with the precise statement of the original result. In more detail, the statement
involves an additive error term εx ≥ 0 that depends on the particular choice of the point x, which
is (adaptively) chosen to be the input on which the random oracle (RO) is reprogrammed. The
guarantee provided by [DFMS19] is that this error term stays negligible even when summed over
all x’s, i.e.,

∑

x εx = negl. The formulation of the result for individual x’s with control over
∑

x Îľx
is important for the later applications to the Fiat-Shamir transformation. However, when applying
the result twice in a row, with the goal being to reprogram the RO at two inputs x1, x2, then we
end up with two error terms Îľx1 and Îľx1

x2
(with the second one depending on x1), where the first

one stays negligible when summed over x1 and the second one stays negligible when summed over
x2 (for any x1); but it is unclear that the sum Îľx1,x2 := Îľx1 + Îľx1

x2
stays negligible when summed

over x1 and x2, which is what we would need to get the corresponding generalized statement.

Our results As a first contribution, we revise the original result from [DFMS19] of reprogram-
ming the QROM at one input by showing an improved version that has no additive error term,
but only the original multiplicative O(q2) loss. For typical direct cryptographic applications, this
improvement makes no big quantitative difference due to the error term being negligible, but: (1) it
makes the statement cleaner and easier to formulate, (2) somewhat surprisingly, the proof is simpler
than that of the original result in [DFMS19], and (3) most importantly, it removes the technical
hurdle to extend to multiple inputs. Indeed, we then get the desired multi-input reprogrammability
result by means of a not too difficult, though somewhat tedious, induction argument.

Building on our multi-input reprogrammability result above, our next goal then is to show the
security of the Fiat-Shamir transformation (in the QROM) of multi-round public-coin interactive
proofs. In contrast to the original result in [DFMS19] for the Fiat-Shamir transformation of ÎŁ-
protocols some additional work is needed here, to deal with the order of the messages extracted
from the Fiat-Shamir adversary. Thus, as a stepping stone, we consider and analyze a variant of
the above multi-input reprogrammability result, which enforces the right order of the extracted
messages. As a simple corollary of this, we then obtain the desired security of multi-round Fiat-
Shamir. Here, the multiplicative loss becomes O(q2n) for a (2n+ 1)-round public-coin interactive
proof with constant n.

In the context of digital signatures, the original motivation for the Fiat-Shamir transformation,
we extend previous results by Unruh [Unr17] and Don et al. [DFMS19] to show that Fiat-Shamir
signature schemes based on a multi-round, honest-verifier zero knowledge public-coin interactive
quantum proof of knowledge have standard signature security (existential unforgeability under
chosen message attacks, UF-CMA) in the QROM. Assuming the additional collision-resistance-
like property of computationally unique responses, they are even strongly unforgeable. We go on
to apply this result to the signature scheme MQDSS [CHR+16], a candidate in the ongoing NIST
standardization process for post-quantum cryptographic schemes [NIS], providing its first QROM
proof.

Another application of our multi-round Fiat-Shamir result would for instance be to Bullet-
proofs [BBB+18].

As a second application of our multi-input reprogrammability result, we show security (in the
QROM) of the non-interactive OR-proof introduced by Liu, Wei and Wong [LWW04], further an-
alyzed by Fischlin, Harasser and Janson [FHJ20]. While the well-known (interactive) OR-proof by
Cramer, DamgĂĽrd and Schoenmakers [CDS94] is a ÎŁ-protocol and thus the results from [DFMS19]
apply, the inherently non-interactive OR-proof by Liu et al. does not follow this blueprint of being
obtained as the Fiat-Shamir transformation of a Σ-protocol (though in some sense it is “close” to
being of this form). We show here how the 2-input version of our multi-input reprogrammability
result implies security of this OR-proof in the QROM.

Our last contribution is a lower bound that shows that the multiplicative O(q2) loss in the
security argument of the Fiat-Shamir transformation of ÎŁ-protocols is tight (up to a factor 4).
Thus, the O(q2) loss is unavoidable in general. Furthermore, we extend this lower bound to the
Fiat-Shamir transformation of multi-round interactive proofs as considered in this work, and we
show that also here to obtained loss O(q2n) is in general optimal, up to a constant that depends
on n only.

2



Related work Before the recently obtained reduction [DFMS19, LZ19] was available, the Fiat-
Shamir tranform in the QROM was studied in a number of works [Unr17, DFG13, KLS18], where
weaker security properties were shown. In addition, Unruh developed an alternative transform
[Unr15] that provided QROM security at the expense of an increased proof size. The Unruh trans-
form was later generalized to apply to 5-round public coin interactive proof systems [CHR+18].

2 Notation

Up to some modifications, we follow closely the notation used in [DFMS19]. We consider a (purified)
oracle quantum algorithm A that makes q queries to an oracle, i.e., an unspecified function H :
X → Y with finite non-empty sets X ,Y. Formally, A is described by a sequence of unitaries
A1, . . . , Aq and an initial state |φ0〉.

2 For technical reasons that will become clear later, we actually
allow (some of) the Ai’s to be a projection followed by a unitary (or vice versa). One can think
of such a projection as a measurement performed by the algorithm, with the algorithm aborting
except in case of a particular measurement outcome.

For any concrete choice of H : X → Y, the algorithm A computes the state

|φH
q 〉 := A

H |φ0〉 := AqO
H ¡ ¡ ¡A1O

H |φ0〉 ,

where OH is the unitary defined by OH : |c〉|x〉|y〉 7→ |c〉|x〉|y ⊕ c·H(x)〉 for any triple c ∈ {0, 1},
x ∈ X and y ∈ Y, with OH acting on appropriate registers. We emphasize that we allow controlled
queries to H . Per se, this gives the algorithm more power, and thus will make our result only
stronger, but it is easy to see that such controlled queries to the standard quantum oracle for
a function can always be simulated by means of ordinary queries, at the price of one additional
query.3 The final state AH |φ0〉 is considered to be a state over registers X = X1 . . .Xn, Z and E.

Following [DFMS19], we introduce the following notation. For 0 ≤ i, j ≤ q we set

AH
i→j := AjO

H ¡ ¡ ¡Ai+1O
H ,

where, by convention, AH
i→j is set to 1 if j ≤ i. Furthermore, we let

|φH
i 〉 :=

(

AH
0→i

)

|φ0〉

be the state of A after the i-th step but right before the (i+ 1)-st query, which is consistent with
|φH

q 〉 above.

For a given function H : X → Y and for fixed x ∈ X and Θ ∈ Y, we define the reprogrammed
function H∗Θx : X → Y that coincides with H on X \ {x} but maps x to Θ. With this notation
at hand, we can then write

(

AH∗Θx
i→q

) (

AH
0→i

)

|φ0〉 =
(

AH∗Θx
i→q

)

|φH
i 〉

for an execution of A where the oracle is reprogrammed at a given point x after the i-th query.
We stress that (AH∗Θx

i→q )(AH
0→i) can again be considered to be an oracle quantum algorithm B,

which depends on Θ ∈ Y, that makes q queries to (the unprogrammed) function H . Indeed, the
(controlled) queries to the reprogrammed oracle H ∗Θx can be simulated by means of controlled
queries to H (using one additional “work qubit”).4 Exploiting that, in addition to unitaries, we allow
projections as elementary operations, we can also understand (AH∗Θx

i→q )X(AH
0→i) to be an oracle

quantum algorithm again that makes oracle queries to H , where X is the projection X = |x〉〈x|,
acting on the corresponding query register to the oracle.

2 Alternatively, we may regard |φ0〉, as an additional input given to A.
3 Allowing controlled queries to the random oracle is also the more natural model compared to restricting

to plain access to the unitary. After all, the motivation for the QROM is that in the real world, an
attacker can implement the modeled hash function on their quantum computer, so they can definitely
implement the controlled version as well.

4 Here it is crucial that we allow controlled queries to H .

3



More generally, for any x = (x1, . . . , xn) ∈ X
n without duplicate entries, i.e., xi 6= xj for i 6= j,

and for any Θ ∈ Yn, we define

H ∗Θx = H ∗Θ1x1 ∗ · · · ∗Θnxn : X → Y

x 7→

{

Θi if x = xi for some i ∈ {1, . . . , n}

H(x) otherwise.

This will then allow us to consider (AH∗Θ1x1∗Θ2x2

i2→q )X2(A
H∗Θ1x1

i1→i2
)X1(A

H
0→i1

) as an oracle quantum
algorithm with oracle queries to H , etc.

Eventually, we are interested in the probability that after the execution of the original algorithm
AH , and upon measuring register X in the computational basis to obtain x = (x1, . . . , xn) ∈ X

n,
the state of register Z is of a certain form dependent on x and H(x) = (H(x1), . . . , H(xn)). Such
a requirement (for a fixed x) is captured by a projection

GH
x

= |x〉〈x| ⊗Πx,H(x) ,

where {Πx,Θ}x,Θ is a family of projections with x ∈ Xn and Θ ∈ Yn, and with the understanding
that |x〉〈x| acts on X and Πx,H(x) on register Z. We refer to such a family of projections as a
quantum predicate. We use GΘ

x as a short hand for GH∗Θx
x , and we write GH

x and GΘ
x with x ∈ X

and Θ ∈ Y for the case n = 1.
For an arbitrary but fixed x◦ ∈ X

n, we are then interested in the probability

Pr
[

x=x◦ ∧ V (x, H(x), z) : (x, z)← AH
]

=
∼

∼GH
x◦
|φH

q 〉
∼

∼

2

2
.

where the left hand side is our notation for this probability, where we understand AH to be an
algorithm that outputs the measured x together with the quantum state z in register Z, and V
to be the quantum predicate specified by the projections Πx,Θ. Correspondingly, Pr

[

x = x◦ ∧

V (x,H(x), z) : (x, z)← AH
]

= ‖GH
x◦
|φH

q 〉‖
2
2 for the n = 1 case.

3 An improved single-input reprogramming result

For the case n = 1, Don et al. [DFMS19] show the existence of a black-box simulator S such that
for any oracle quantum algorithm A as considered above with oracle access to a uniformly random
H , it holds that

Pr
Θ

[

x=x◦ ∧ V (x,Θ, z) : (x, z)← 〈SA, Θ〉
]

≥
1

2(q+1)(2q+3)
Pr
H

[

x=x◦ ∧ V (x,H(x), z) : (x, z)← AH
]

− εx◦ ,
(1)

for any x◦ ∈ X , where the εx◦ ’s are non-negative and their sum over x◦ ∈ X is bounded by
1/(2q|Y|), i.e., negligible whenever |Y| is superpolynomial. The notation (x, z)← 〈SA, Θ〉 is to be
understood in that in a first stage SA outputs x, and then on input Θ it outputs z. At the core,
Equation (1) follows from Lemma 1 of [DFMS19] which shows that

E
Θ,i,b

[

∼

∥(|x〉〈x| ⊗Πx,Θ)
(

AH∗Θx
i+b→q

)(

AH
i→i+b

)

X |φH
i 〉

∼

∼

2

2

]

≥
EΘ

[

∼

∥(|x〉〈x| ⊗Πx,Θ)|φ
H∗Θx
q 〉

∼

∼

2

2

]

2(q + 1)(2q + 3)
−

∼

∥X |φH
q 〉

∼

∼

2

2

2(q + 1)|Y|
,

(2)

and from which the construction of S can be extracted. The bound (1) on the “success probability”
of S then follows from the observation that S can simulate the calls to H and to H∗Θx by means of
a 2(q+1)-wise independent hash function, and that H and H∗Θx are indistinguishable for random
H and Θ.

In this section we show an improved variant of Equation (1), which avoids the additive error term
εx◦ . While having negligible quantitative effect in typcial situations, it makes the statement simpler.
In addition, as explained in the introduction, it circumvents a technical issue one encounters when

4



trying to extend to the multi-input case. Furthermore, our improved version comes with a simpler
proof.5

The approach is to avoid the additive error term in Equation (2). We achieve this by slightly
tweaking the simulator S. From the technical perspective, while on the left hand side of Equation
(2) the expectation is over a random i ∈ {0, . . . , q}, selecting one of the q + 1 queries of A at
random (where the X register of the output state is considered to be a final query), and a random
b ∈ {0, 1}, our new version has syntactically the same left hand side, but with the expectation over
a random pair (i, b) ∈ ({0, . . . , q91}×{0, 1})∪{(q, 0)} instead. This allows us to absorb the additive
error term into the success probability of the simulator. Furthermore, it holds for any fixed choice
of Θ (and not only on average for a random choice).

Lemma 1 Let A be a q-query oracle quantum algorithm. Then, for any function H : X → Y, any
x ∈ X and Θ ∈ Y, and any projection Πx,Θ, it holds that

E
i,b

[

∼

∥(|x〉〈x| ⊗Πx,Θ)
(

AH∗Θx
i+b→q

)(

AH
i→i+b

)

X |φH
i 〉

∼

∼

2

2

]

≥

∼

∥(|x〉〈x| ⊗Πx,Θ)|φ
H∗Θx
q 〉

∼

∼

2

2

(2q + 1)2
,

where the expectation is over uniform (i, b) ∈ ({0, . . . , q91} × {0, 1})∪ {(q, 0)}.

This new version of Equation (2) translates to a simulator S that works by running A, but with
the following modifications. First, one of the q + 1 queries of A (also counting the final output in
register X) is measured, and the measurement outcome x is output by (the first stage of) S. We
emphasize that the crucial difference to [DFMS19] is that each of the q actual queries is picked
with probability 2

2q+1 , while the final output is picked with probability 1
2q+1 . Then, very much as in

[DFMS19], this very query of A is answered either using the original H or using the reprogrammed
oracle H ∗Θx, with the choice being made at random6, while all the remaining queries of A are
answered using oracle H∗Θx. Finally, (the second stage of) S outputs whatever A outputs.

In line with Theorem 1 in [DFMS19], i.e. Equation (1) above, we obtain the following result
from Lemma 1.

Theorem 2 (Measure-and-reprogram, single input) Let X and Y be finite non-empty sets.
There exists a black-box two-stage quantum algorithm S with the following property. Let A be an
arbitrary oracle quantum algorithm that makes q queries to a uniformly random H : X → Y and
that outputs some x ∈ X and a (possibly quantum) output z. Then, the two-stage algorithm SA

outputs some x ∈ X in the first stage and, upon a random Θ ∈ Y as input to the second stage, a
(possibly quantum) output z, so that for any x◦ ∈ X and any (possibly quantum) predicate V :

Pr
Θ

[

x=x◦ ∧ V (x,Θ, z) : (x, z)← 〈SA, Θ〉
]

≥
1

(2q + 1)2
Pr
H

[

x=x◦ ∧ V (x,H(x), z) : (x, z)← AH
]

.

Furthermore, S runs in time polynomial in q, log |X | and log |Y|.

The proof of Lemma 1 follows closely the proof of Equation (1) in [DFMS19], but the streamlined
statement and simulator allow to cut some corners.

Proof (of Lemma 1). For any 0 ≤ i ≤ q, inserting a resolution of the identity and exploiting that
(

AH∗Θx
i+1→q

)(

AH
i→i+1

)(

1−X
)

|φH
i 〉 =

(

AH∗Θx
i→q

)(

1−X
)

|φH
i 〉 ,

we can write
(

AH∗Θx
i+1→q+1

)

|φH
i+1〉

=
(

AH∗Θx
i+1→q+1

)(

AH
i→i+1

)(

1−X
)

|φH
i 〉 +

(

AH∗Θx
i+1→q+1

)(

AH
i→i+1

)

X |φH
i 〉

=
(

AH∗Θx
i→q+1

)(

1−X
)

|φH
i 〉 +

(

AH∗Θx
i+1→q+1

)(

AH
i→i+1

)

X |φH
i 〉

=
(

AH∗Θx
i→q+1

)

|φH
i 〉 −

(

AH∗Θx
i→q+1

)

X |φH
i 〉 +

(

AH∗Θx
i+1→q+1

)(

AH
i→i+1

)

X |φH
i 〉

5 We thank Dominique Unruh for the idea that it might be possible to avoid the additive error term,
and for proposing an argument for achieving that, which inspired us to find the simpler argument we
eventually used.

6 If it is the final output that is measured then there is nothing left to reprogram, so no choice has to be
made.

5



Rearranging terms, applying GΘ
x = (|x〉〈x| ⊗ Πx,Θ) and using the triangle equality, we can thus

bound
∼

∼GΘ
x

(

AH∗Θx
i→q

)

|φH
i 〉

∼

∼

2
≤

∼

∼GΘ
x

(

AH∗Θx
i+1→q

)

|φH
i+1〉

∼

∼

2

+
∼

∼GΘ
x

(

AH∗Θx
i→q

)

X |φH
i 〉

∼

∼

2

+
∼

∼GΘ
x

(

AH∗Θx
i+1→q

)(

AH
i→i+1

)

X |φH
i 〉

∼

∼

2
.

Summing up the respective sides of the inequality over i = 0, . . . , q − 1, we get

∼

∼GΘ
x |φ

H∗Θx
q 〉

∼

∼

2
≤

∼

∼GΘ
x |φ

H
q 〉

∼

∼

2
+

∑

0≤i<q
b∈{0,1}

∼

∼GΘ
x

(

AH∗Θx
i+b→q

)(

AH
i→i+b

)

X |φH
i 〉

∼

∼

2
.

By squaring both sides, dividing by 2q + 1 (i.e., the number of terms on the right hand side), and
using Jensen’s inequality on the right hand side, we obtain

∼

∼GΘ
x |φ

H∗Θx
q 〉

∼

∼

2

2

2q + 1
≤

∼

∼GΘ
x |φ

H
q 〉

∼

∼

2

2
+

∑

0≤i<q
b∈{0,1}

∼

∼GΘ
x

(

AH∗Θx
i+b→q

)(

AH
i→i+b

)

X |φH
i 〉

∼

∼

2

2

and thus, noting that we can write
∼

∼GΘ
x |φ

H
q 〉

∼

∼

2

2
as

∼

∼GΘ
x

(

AH∗Θx
i+b→q+1

)(

AH
i→i+b

)

X |φH
i 〉

∼

∼

2

2

with i = q and b = 0,

∼

∼GΘ
x |φ

H∗Θx
q 〉

∼

∼

2

2

(2q + 1)2
≤ E

i,b

[

∼

∼GΘ
x

(

AH∗Θx
i+b→q

)(

AH
i→i+b

)

X |φH
i 〉

∼

∼

2

2

]

.

⊓⊔

For completeness, let us spell out how Theorem 8 of [DFMS19] on the generic security of the
Fiat-Shamir transformation (in the QROM) can now be re-phrased, avoiding the negligible error
term present in [DFMS19]. We refer to [DFMS19] or to our later Section 5 for the details on the
Fiat-Shamir transformation.

Theorem 3 There exists a black-box quantum polynomial-time two-stage quantum algorithm S
such that for any adaptive Fiat-Shamir adversary A, making q queries to a uniformly random
function H with appropriate domain and range, and for any x◦ ∈ X :

Pr
[

x=x◦ ∧ v = accept : (x, v)← 〈SA,V〉
]

≥
1

(2q + 1)2
Pr
H

[

x=x◦ ∧ V H
FS(x, π) : (x, π)← A

H
]

.

4 Multi-input reprogrammability

In this section, we extend our (improved) results on adaptively reprogramming the quantum ran-
dom oracle at one point x ∈ X to multiple points x1, . . . , xn ∈ X . This in turn will allow us to
extend the results on the security of the Fiat-Shamir transformation to multi-round protocols. We
point out again that the improvement of Lemma 1 over Lemma 1 in [DFMS19] plays a crucial
role here, in that it circumvents the trouble with the negligible error term that occurs when trying
to extend the result from [DFMS19] to the setting considered here.

The starting point is the following generalized version of the problem considered in Section 3.
We assume an oracle quantum algorithm AH that makes q queries to a random oracle H : X → Y
and then produces an output of the form (x1, . . . , xn, z), where z may be quantum, such that a
certain (quantum) predicate V (x1, H(x1), . . . , xn, H(xn), z) is satisfied with some probability. The
goal then is to turn such an AH into a multi-stage quantum algorithm S (the simulator) that,
stage by stage, outputs the xi’s and takes corresponding Θi’s as input, and eventually outputs
a (possibly quantum) z with the property that V (x1, Θ1, . . . , xn, Θn, z) is satisfied with similar
probability.

6



4.1 The general case

Naively, one might hope for an S that outputs x1 in the first stage (obtained by measuring one of
the queries of AH), and then on input Θ1 proceeds by outputting x2 in the second stage (obtained
by measuring one of the subsequent queries of AH), etc. However, since AH may query the hashes
of x1, . . . , xn in an arbitrary order, we cannot hope for this to work. Therefore, we have to allow
S to produce x1, . . . , xn in an arbitrary order as well.7 Formally, we consider S with the following
syntactic behavior: in the first stage it outputs a permutation π together with xπ(1) and takes
as input Θπ(1), and then for every subsequent stage 1 < i ≤ n it outputs xπ(i) and takes as
input Θπ(i); eventually, in the final stage (labeled by n + 1) it outputs z. In line with earlier
notation, but taking this additional complication into account, we denote such an execution of S
as (π, π(x), z)← 〈SA, π(Θ)〉.

A final issue is that if xi = xj then H(xi) = H(xj) as well, whereas Θi and Θj may well be
different. Thus, we can only expect S to work well when x1, . . . xn has no duplicates.

For us to be able to mathematically reason about the simulator described above, we introduce
some additional notation. For the basic simulator from Lemma 1 we write, using r1 = (b1, i1), as

SH,A
Θ1,x1,r1

:= SH,A,Θ1,x1,r1 :=
(

AH∗Θ1x1

i1+b1→q

)(

AH
i1→i1+b1

)

X1

(

AH
0→i1

)

.

This can be recursively extended by applying it to AH now being SH,A
Θ1,x1,r1

so as to obtain

SH,A
Θ1,2,x1,2,r1,2

:=
(

SH∗Θ2x2,A,Θ1,x1,r1
i2+b2→q

)(

SH,A,Θ1,x1,r1
i2→i2+b2

)

X2

(

SH,A,Θ1,x1,r1
0→i2

)

.

In general, we can consider the following operator, which simulates A and performs n measure-
ments:

SH,A
Θ,x,r :=

(

SH∗Θnxn,A,Θ,x,r
in+bn→q

)(

SH,A,Θ,x,r
in→in+bn

)

Xn

(

SH,A,Θ,x,r
0→in

)

.

where, for arbitrary but fixed n and Θ = (Θ1, . . . , Θn) ∈ Y
n, the notation Θ is understood

as Θ = (Θ1, . . . , Θn−1) ∈ Y
n−1, and correspondingly for x etc. Finally, when considering fixed

Θ ∈ Yn and x ∈ Xn, we write
SH
r (A) := SH,A

Θ,x,r .

At the core of our multi-round result will be the following technical lemma, which generalizes
Lemma 1.

Lemma 4 Let A be a q-query oracle quantum algorithm. Then, for any function H : X → Y, any
x ∈ Xn and Θ

n ∈ Yn, and any projection Πx,Θ, it holds that

∼

∼

(

|x〉〈x| ⊗Πx,Θ

)

AH∗Θx|φ0〉
∼

∼

2

2

(2q + 1)2n
≤ E

r

[

∼

∼

(

|x〉〈x|A ⊗Πx,Θ

)

SH
r
(A)|φ0〉

∼

∼

2

2

]

.

Proof. The proof is by induction on n, where the base case is given by Lemma 1.
For the induction step we first apply the base case, substituting xn for x1, Θn for Θ1, rn for

r1, H∗Θx for H , and Π̂xn,Θn
for Πx1,Θ1 , where

Π̂xn,Θn
= |x1〉〈x1| ⊗ . . .⊗ |xn91〉〈xn91| ⊗Πx,Θ

to obtain
∼

∼

(

|xn〉〈xn| ⊗ Π̂xn,Θn

)

A(H∗Θx)∗Θnxn |φ0〉
∼

∼

2

2

(2q + 1)2

≤ E
rn

[

∼

∼

(

|xn〉〈xn|A ⊗ Π̂xn,Θn

)

SH∗Θx

rn
(A)|φ0〉

∼

∼

2

2

]

which we can write as

∼

∼

(

|x〉〈x| ⊗Πx,Θ

)

AH∗Θx|φ0〉
∼

∼

2

2

(2q + 1)2n
≤

Ern

[

∼

∼

(

|x〉〈x| ⊗Πx,Θ

)

SH∗Θx
rn

(A)|φ0〉
∼

∼

2

2

]

(2q + 1)2(n91)
(3)

7 Looking ahead, in Section 4.2 we will force AH to query, and thus S to extract, x1, . . . , xn in the right
order by requiring x2 to contain H(x1) as a substring, x3 to contain H(x2) as a substring, etc. This will
be important for the the multi-round Fiat-Shamir application.

7



dividing both sides by (2q + 1)2(n91) and swapping registers appropriately (to make sure that the
register which contains xn comes after the others).

Now fix rn. We define
Π̂

x,Θ := |xn〉〈xn| ⊗Πx,Θ.

and apply the induction hypothesis for n−1, substituting SH∗Θx
rn

(A) for AH∗Θx, and Π̂
x,Θ for

Π
x,Θ, in order to derive

∼

∼

(

|x〉〈x| ⊗Πx,Θ

)

SH∗Θx
rn

(A)|φ0〉
∼

∼

2

2

(2q + 1)2(n91)
=

∼

∼

(

|x〉〈x| ⊗ Π̂
x,Θ

)

SH∗Θx
rn

(A)|φ0〉
∼

∼

2

2

(2q + 1)2(n91)

≤ E
r

[

∼

∼

(

|x〉〈x| ⊗ Π̂
x,Θ

)

SH
r
(Srn(A))|φ0〉

∼

∼

2

2

]

= E
r

[

∼

∼

(

|x〉〈x| ⊗Πx,Θ

)

SH
r
(A)|φ0〉

∼

∼

2

2

]

.

Since this inequality holds for any fixed rn, it also holds in expectation over rn. Substituting it in
Equation 3, we retrieve the statement of the lemma. ⊓⊔

Remark 5 In case of x = (x1, . . . , xn) ∈ X
n without duplicate entries, it follows from the resulting

mutual orthogonality of the projections Xj and the definition of SH
r
(A) that the following holds.

The term in the expectation Er in the inequality of Lemma 4 vanishes for any r = (i,b) for
which there exist two distinct coordinates j 6= k with ij = ik. As such, we may well understand
this expectation to be over r = (i,b) for which ij 6= ik whenever j 6= k; this only increases the
expectation.8 In other words, we may assume that random distinct queries are measured in order
to extract x1, . . . , xn.

Theorem 6 (Measure-and-reprogram, multiple inputs) Let n be a positive integer, and let
X ,Y be finite non-empty sets. There exists a black-box polynomial-time (n+1)-stage quantum
algorithm S with the syntax as outlined at the start of this section, satisfying the following property.
Let A be an arbitrary oracle quantum algorithm that makes q queries to a uniformly random
H : X → Y and that outputs a tuple x ∈ Xn and a (possibly quantum) output z. Then, for any
x
◦ ∈ Xn without duplicate entries and for any predicate V :

Pr
Θ

[

x=x
◦ ∧ V (x,Θ, z) : (π, π(x), z)← 〈SA, π(Θ)〉

]

≥
1

(q + 1)2n
Pr
H

[

x=x
◦ ∧ V (x, H(x), z) : (x, z)← AH

]

.

Proof. We consider the inequality of Lemma 4 with the expectation over r understood as in Re-
mark 5. Additionally taking the expectation over H and Θ on both sides, we obtain

E
H,Θ

[
∼

∼

(

|x〉〈x| ⊗Πx,Θ

)

AH∗Θx|φ0〉
∼

∼

2

2

(2q + 1)2n

]

≤ E
H,Θ,r

[

∼

∼

(

|x〉〈x| ⊗Πx,Θ

)

SHr (A)|φ0〉
∼

∼

2

2

]

and note that this is equivalent to

E
H

[
∼

∼

(

|x〉〈x| ⊗Πx,H(x)

)

AH |φ0〉
∼

∼

2

2

(2q + 1)2n

]

≤ E
H,Θ,r

[

∼

∼

(

|x〉〈x| ⊗Πx,Θ

)

SH
r
(A)|φ0〉

∼

∼

2

2

]

.

since all values Θj and H(xj) have the same distribution. The term SH
r
(A)|φ0〉 = SH,A

Θ,x,r|φ0〉
corresponds to the output of the simulator that uses oracle access to H to run A on an initial state
|φ0〉, while measuring queries ij (finding xj as the outcome) and reprogramming the oracle at xj

to Θj from the (ij + bj)-th query onwards, with (ij, bj) = rj .
Next, we note that the value of the right hand side does not change [Zha12] when instead

of giving S oracle access to H , we let it choose a random instance from a family of 2q-wise9

8 One might try to exploit this actual improvement in the bound; however, for typical choices of parame-
ters, with n a small constant and q large, this is insignificant.

9 It is easy to see that the result of [Zha12] also holds for controlled-query algorithms. Alternatively, the
q controlled queries can be simulated using q+1 plain queries, and a 2(q+1)-wise independent function
can be used.

8



independent hash functions to simulate A on. The choice of r uniquely determines the permutation
π with the property iπ(1) < · · · < iπ(n); by definition of SH,A

Θ,x,r, the values x = (x1, . . . , xn) are then
extracted from the adversary’s queries in the order π(x) = (xπ(1), . . . , xπ(n)). Since S chooses this
r itself, we can assume that it includes π in its output. Likewise, the simulator takes as input
to every stage — from the second to the (n+1)-st— a fresh random value, in the order given by
π(Θ). However, by definition of Πx,Θ the final output of the simulator satisfies the predicate V
with respect to the given order (without π), i.e. such that V (x,Θ, z) = 1, as is the claim of the
theorem. ⊓⊔

4.2 The time-ordered case

In some applications, like the multi-round version of the Fiat-Shamir transformation, we need
that the simulator extracts the messages in the right order. This can be achieved by replacing
the hash list H(x) =

(

H(x1), . . . , H(xn)
)

, consisting of individual hashes, by a hash chain, where
subsequent hashes depend on previous hashes. Intuitively, this enforces A to query the oracle in
the given order.

Formally, considering a function H : (X0 ∪ Y)×X → Y and given a tuple x = (x0, x1, . . . , xn)

in X0 ×X
n, we define the hash chain h

H,x =
(

hH,x
1 , . . . , hH,x

n

)

given by

hH,x
1 = H(x0, x1) and hH,x

i := H
(

hH,x
i−1 , xi

)

for 2 ≤ i ≤ n.

Theorem 7 (Me";"""date"",""2020-07-28T04:15:13Z""
""pdf:PDFVersion"",""1.4""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.4""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""xmp:CreateDate"",""2020-07-28T00:15:13Z""
""modified"",""2020-07-28T04:15:13Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""xmp:ModifyDate"",""2020-07-28T00:15:13Z""
""pdf:docinfo:creator"",""""
""meta:author"",""""
""meta:creation-date"",""2020-07-28T04:15:13Z""
""created"",""2020-07-28T04:15:13Z""
""xmp:About"",""uuid:7ba7a2b9-08a5-11f6-0000-94d9df9b0c94""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-07-28T04:15:13Z""
""resourceName"",""2003.05207""
""Author"",""""
""producer"",""dvips + GPL Ghostscript GIT PRERELEASE 9.22""
""pdf:docinfo:producer"",""dvips + GPL Ghostscript GIT PRERELEASE 9.22""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""2"",""28"",""55"",""76"",""108"",""87"",""101"",""31"",""61"",""0"",""6"",""7"",""32"",""16"",""1"",""1"",""3"",""6"",""10"",""2"",""6""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2020-07-28T04:15:13Z""
""Last-Modified"",""2020-07-28T04:15:13Z""
""dcterms:modified"",""2020-07-28T04:15:13Z""
""title"",""""
""xmpMM:DocumentID"",""uuid:7ba7a2b9-08a5-11f6-0000-94d9df9b0c94""
""Last-Save-Date"",""2020-07-28T04:15:13Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2020-07-28T04:15:13Z""
""meta:save-date"",""2020-07-28T04:15:13Z""
""Content-Length"",""405783""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""22""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""3450"",""4188"",""2919"",""2421"",""2980"",""2291"",""2537"",""2651"",""2709"",""1792"",""2514"",""3249"",""3574"",""1719"",""1525"",""3013"",""3254"",""3075"",""3612"",""3154"",""3698"",""3425""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-07-28T04:15:13Z""
";https://scholar.google.ch/scholar?start=900&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098778-135;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Distributed ledger technology;A Sunyaev ; Internet Computing, 2020  Springer;;"… of cryptocurrencies (eg, Bitcoin) was one of the main drivers of blockchain and DLT's … A

crypto-anarchy involves a government's permanent absence and postulates anonymity and

censorship … Payments should be made by using cryptographically secured cryptocurrency tokens …";Cité 14 fois;;null;;;;https://scholar.google.ch/scholar?start=680&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098818-230;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;Non-interactive classical verification of quantum computation;G Alagic, AM Childs, AB Grilo, SH Hung ; Theory of Cryptography …, 2020  Springer;;"… Specifically, our protocols are secure in the Quantum Random Oracle Model, under the

assumption that Learning with Errors is quantumly hard. The NIZK construction also requires

circuit-private FHE … Our security proofs hold in the Quantum Random Oracle Model (QROM) [11] …";Cité 10 fois;Les 16 versions;[PDF] arxiv.org;https://arxiv.org/pdf/1911.08101;"
ar
X

iv
:1

91
1.

08
10

1v
2 

 [
qu

an
t-

ph
] 

 9
 M

ar
 2

02
0

Non-interactive classical verification
of quantum computation

Gorjan Alagic1,2,3 Andrew M. Childs1,3,4 Alex B. Grilo5,6 Shih-Han Hung1,3,4

1Joint Center for Quantum Information and Computer Science, University of Maryland
2National Institute of Standards and Technology, Gaithersburg, Maryland

3Institute for Advanced Computer Studies, University of Maryland
4Department of Computer Science, University of Maryland

5CWI, Amsterdam
6QuSoft, Amsterdam

Abstract

In a recent breakthrough, Mahadev constructed an interactive protocol that enables a
purely classical party to delegate any quantum computation to an untrusted quantum prover.
In this work, we show that this same task can in fact be performed non-interactively and in
zero-knowledge.

Our protocols result from a sequence of significant improvements to the original four-
message protocol of Mahadev. We begin by making the first message instance-independent
and moving it to an offline setup phase. We then establish a parallel repetition theorem for
the resulting three-message protocol, with an asymptotically optimal rate. This, in turn, en-
ables an application of the Fiat-Shamir heuristic, eliminating the second message and giving a
non-interactive protocol. Finally, we employ classical non-interactive zero-knowledge (NIZK)
arguments and classical fully homomorphic encryption (FHE) to give a zero-knowledge vari-
ant of this construction. This yields the first purely classical NIZK argument system for QMA,
a quantum analogue of NP.

We establish the security of our protocols under standard assumptions in quantum-secure
cryptography. Specifically, our protocols are secure in the Quantum Random Oracle Model,
under the assumption that Learning with Errors is quantumly hard. The NIZK construction
also requires circuit-private FHE.

1 Introduction

Quantum computing devices are expected to solve problems that are infeasible for classical com-
puters. However, as significant progress is made toward constructing quantum computers, it is
challenging to verify that they work correctly. This becomes particularly difficult when devices
reach scales that rule out direct classical simulation.

This problem has been considered in various models, such as with multiple entangled quan-
tum provers [RUV13,McK16,GKW15,HPDF15,FH15,NV17,CGJV19,Gri19] or with verifiers who
have limited quantum resources [BFK09, Bro18, MF16, ABOEM17]. Such solutions are not ideal

1

http://arxiv.org/abs/1911.08101v2


since they require assumptions about the ability of the provers to communicate or require the
verifier to have some quantum abilities.

In a major breakthrough, Mahadev recently described the first secure protocol enabling a
purely classical verifier to certify the quantum computations of a single untrusted quantum
prover [Mah18]. The Mahadev protocol uses a quantum-secure cryptographic assumption to
give the classical verifier leverage over the quantum prover. Specifically, the protocol is sound
under the assumption that the Learning with Errors (LWE) problem does not admit a polynomial-
time quantum algorithm. This assumption is widely accepted, and underlies some of the most
promising candidates for quantum-secure cryptography [AASA+19].

The Mahadev protocol. Mahadev’s result settled a major open question concerning the power
of quantum-prover interactive arguments (QPIAs). In a QPIA, two computationally-bounded parties
(a quantum prover P and a classical verifier V) interact with the goal of solving a decision
problem. Mahadev’s result showed that there is a four-round1 QPIA for BQP with negligible
completeness error and constant soundness error δ ≈ 3/4. The goal of the protocol is for the
verifier to decide whether an input Hamiltonian H from a certain class (which is BQP-complete)
has a ground state energy that is low (YES) or high (NO).

The protocol has a high-level structure analogous to classical ÎŁ-protocols [Dam02]:

1. V generates a private-public key pair (pk, sk) and sends pk to P ;

2. P prepares the ground state of H and then coherently evaluates a certain classical function
fpk. This yields a state of the form

∑
x

αx|x〉X | fpk(x)〉Y , (1)

where the ground state is in a subregister of register X. P measures the output register Y

and sends the result y to V . Note that P now holds a superposition over the preimages of
y.

3. V replies with a uniformly random challenge bit c ∈ {0, 1}.

4. If c = 0 (“test round”), P measures the X register in the computational basis and sends the
outcome. If c = 1 (“Hadamard round”), P measures X in the Hadamard basis and sends
the outcome.

After the four message rounds above are completed, the verifier uses their knowledge of H and
the secret key sk to either accept or reject the instance H.

Our results. In this work, we show that the Mahadev protocol can be transformed into pro-
tocols with significantly more favorable parameters, and with additional properties of interest.
Specifically, we show how to build non-interactive protocols (with setup) for the same task, with
negligible completeness and soundness errors. One of our protocols enables a verifier to publish
a single public “setup” string and then receive arbitrarily many proofs from different provers,

1We take one round to mean a single one-way message from the prover to the verifier, or vice-versa. The Mahadev
protocol involves four such messages.

2



each for a different instance. We also construct a non-interactive protocol that satisfies the zero-
knowledge property [BFM88].

In principle, one could ask for a slightly less interactive protocol: one where the prover
and the verifier both receive the instance from some third party, and then the prover simply
sends a proof to the verifier, with no setup required. While we cannot rule such a protocol out,
constructing it seems like a major challenge (and may even be impossible). In such a setting, the
proof must be independent of the secret randomness of the verifier, making it difficult to apply
the “cryptographic leash” technique of Mahadev. On the other hand, without cryptographic
assumptions, such a protocol would result in the unlikely inclusion BQP ⊆ MA [Aar10].

All of our results are conditioned on the hardness of the LWE problem for quantum comput-
ers; we call this the LWE assumption. This assumption is inherited from the Mahadev protocol.
For the zero-knowledge protocol, we also require fully-homomorphic encryption (FHE) with
circuit privacy [OPCPC14]. Our security proofs hold in the Quantum Random Oracle Model
(QROM) [BDF+11]. For simplicity, in our exposition we assume that the relevant security param-
eters are polynomial in the input BQP instance size n, so that efficient algorithms run in time
poly(n) and errors are (ideally) negligible in n.

Warmup: A non-interactive test of quantumness. To explain our approach, we first briefly
describe how to make the “cryptographic test of quantumness” (CTQ) of [BCM+18] into a non-
interactive protocol (with setup.) This is a significantly simplified version of the Mahadev pro-
tocol: there is no ground state, and the initial state (1) is simply in uniform superposition over
X. The soundness error is 1/2, meaning that a classical prover can convince the verifier to accept
with probability at most 1/2 [BCM+18]. A quantum prover can easily answer both challenges,
so the completeness is 1.

To reduce the interaction in this protocol, we perform two transformations. First, we repeat
the protocol independently in parallel k times, with the verifier accepting if and only if all k

copies accept. We then remove Round 3 via the Fiat-Shamir transform [FS86]: the prover com-
putes the challenges c = (c1, c2, . . . , ck) := H(y1, . . . , yk) themselves via a public hash function
H. This allows the prover to go directly to Round 4, i.e., measuring the X registers. The verifier
then performs the k-fold accept/reject verdict calculations, using coins c computed in the same
manner. The result is a two-message protocol. Moreover, since the keys are drawn from a fixed
distribution, we can give the pkj to the prover and the skj to the verifier in an offline setup phase,
so that the protocol only requires one message in the online phase. We refer to this protocol as
NI-CTQ.

Since the soundness experiment of NI-CTQ only involves classical provers, and the verifier
is also classical, soundness can be deduced from existing classical results. Specifically, stan-
dard parallel repetition2 theorems [Hai09, HPWP10, BHT19] combined with soundness of Fiat-
Shamir [BR93,FS86,PS00] yield the fact that NI-CTQ has negligible soundness and completeness
errors, in the Random Oracle Model (ROM).

Transforming the Mahadev protocol. Similar to NI-CTQ above, we will apply various transfor-
mations to the Mahadev verification protocol itself:

2A subtlety is that this is a private-coin protocol. However, the c = 0 branch is publicly simulable so [HPWP10]
applies. Alternatively, one can apply the techniques of [Hai09].

3



1. making the first message instance-independent (i.e., moving it to an offline setup phase);

2. applying parallel repetition, via a new parallel repetition theorem;

3. adding zero-knowledge, by means of classical NIZKs and classical FHE; and

4. applying Fiat-Shamir (in the QROM [BDF+11]).

Unlike with NI-CTQ, however, establishing that these transformations satisfy desirable properties
is much more challenging. For instance, since cheating provers can now be quantum, classical
parallel repetition theorems do not apply.

Instance-independent setup. The first transformation is relatively simple to describe, at a high
level. In the Mahadev protocol, the initial message depends on a sequence of basis choices (X or
Z) for measuring the ground state of a ZX Hamiltonian. These choices need to be consistent with
a particular two-local term drawn from some distribution D. Clearly, a random choice is correct
with probability 1/4. Now, if we consider multiple copies of the ground state, and each copy
is assigned both a random choice of bases and a random term from D, then about 1/4 of the
copies get a consistent assignment. We can then make the initial message instance-independent
by increasing the number of copies of the ground state in the Mahadev protocol by a constant
factor. We establish this fact3 in Lemma 3.1 below. We refer to the result as “the three-round
Mahadev protocol,” and denote it by M.

Parallel repetition. The k-fold sequential repetition of a protocol is a simple way of decreasing
the original soundness error δ to δk, at the cost of multiplying the number of interaction rounds by
k. Parallel repetition is much more desirable because it does not increase the number of rounds.
However, even in the case of purely classical protocols, proving that parallel repetition reduces
soundness error is often quite difficult, and may require adapting the protocol itself [BIN97,
Hai09].

Does parallel repetition work for quantum-prover interactive arguments? The Mahadev pro-
tocol is a natural case to consider since it already exhibits the full decisional power of QPIAs,
namely BQP. However, several complications arise when attempting to establish parallel repeti-
tion using classical techniques. First, the Mahadev protocol is clearly private-coin, precisely the
category that is challenging even classically [BIN97, Hai09]. Second, classical proofs of parallel
repetition typically involve constructing a prover (for the single-copy protocol) that uses many
rounds of nested rejection sampling. The quantum analogue of such a procedure is quantum
rewinding, which can only be applied in special circumstances [Wat09, ARU14] and seems diffi-
cult to apply to parallel repetition.

In this work, we establish a new parallel repetition theorem with alternative techniques,
suited specifically for the Mahadev protocol. We show that, for NO instances, the accepting
paths of the verifier for the two different challenges (c = 0 and c = 1) correspond to two nearly
(computationally) orthogonal projectors. We also establish that this persists in k-fold parallel rep-
etition, meaning that each pair of distinct challenge strings c, c′ ∈ {0, 1}k corresponds to nearly
orthogonal projectors. From there, a straightforward argument shows that the prover cannot

3More precisely, we apply this transformation at the level of the Morimae-Fitzsimons protocol [MF16], an important
building block of the Mahadev protocol.

4



succeed for more than a non-negligible fraction of challenge strings. Our result shows that k-fold
parallel repetition yields the same optimal soundness error δk as sequential repetition.

Taken together with the first transformation, the result is a three-round QPIA (with offline
setup) for verifying BQP, with negligible completeness and soundness errors. We denote this
protocol by Mk.

Theorem 1.1. Under the LWE assumption, the k-fold parallel repetition Mk of the three-round Mahadev

protocol M is a three-round protocol (with offline setup) for verifying BQP with completeness 1− negl(n)
and soundness error 2−k + negl(n).

Zero-knowledge. Zero-knowledge is a very useful cryptographic property of proof systems.
Roughly, a protocol is zero-knowledge if the verifier “learns nothing” from the interaction with
the honest prover, besides the fact that the relevant instance is indeed a “yes” instance. This
notion is formalized by requiring an efficient simulator whose output distribution is indistin-
guishable from the distribution of the outcomes of the protocol.

In our next result, we show how to modify the protocol Mk of Theorem 1.1 to achieve zero-
knowledge against arbitrary classical verifiers. Our approach is similar to that of [CVZ19], but
uses a purely classical verifier. Instead of the prover providing the outcomes of the measurements
to be checked by the verifier (as in Mk), a classical non-interactive zero-knowledge proof (NIZK)
is provided. However, the NP statement “the measurements will pass verification” depends on
the inversion trapdoor of the verifier, which must remain secret from the prover. To overcome this
obstacle, we use classical fully homomorphic encryption (FHE). In the setup phase, an encryption
of the verifier’s secret keys is provided to the prover, enabling the prover to later compute the
NIZK homomorphically. To establish the zero-knowledge property, we require the FHE scheme
to have circuit privacy, which means that the verifier cannot learn the evaluated circuit from the

ciphertext provided by the prover. To prove the zero-knowledge property, we also need the extra
assumption that the setup phase is performed by a trusted third party, since we cannot rely on
the verifier to perform it honestly anymore.

In classical zero-knowledge arguments, it is common to consider efficient provers who are
provided an NP-witness of the statement to prove. In the quantum setting, if we assume that
the quantum polynomial-time prover has access to a quantum proof of a QMA statement,4 we
achieve the following.

Theorem 1.2 (informal). Under the LWE assumption, if circuit-private FHE exists, then there exists

a three-round zero-knowledge argument for QMA (with trusted setup) with negligible completeness and

soundness error.

Fiat-Shamir transformation. Note that in the protocols discussed above (both Mk and its ZK-
variant), the second message of the verifier to the prover is a uniformly random c ∈ {0, 1}k. In the
final transformation, we eliminate this “challenge” round. This is done via the well-known Fiat-
Shamir transform [FS86]: we ask the prover to generate the challenge bits c ∈ {0, 1}k themselves
by evaluating a public hash function H on the transcript of the protocol thus far. In our case,
recalling (1), this means that the prover selects c := H(H, pk, y). Note that pk and y are now both

4QMA is a decision problem class which is a quantum analogue of NP. In QMA, an untrusted quantum proof is
provided to a quantum poly-time verifier.

5



k-tuples, since we are transforming k-fold parallel-repeated protocols. Of course, the verifier also
needs to adapt their actions at the verdict stage, using c = H(H, pk, y) when deciding whether to
accept or reject. The resulting protocols now only have a setup phase and a single message from
the prover to the verifier.

A standard approach with Fiat-Shamir (FS) is to establish security in the Random Oracle
Model, in the sense that FS preserves soundness up to a loss that is negligible provided H has a
superpolynomially-large range [BR93, PS00]. It is straightforward to see that this last condition
is required; it is also the reason that we applied parallel repetition prior to FS. A well-known
complication in the quantum setting is that quantum computers can evaluate any public classical
function H in superposition via the unitary operator UH : |x〉|y〉 7→ |x〉|y ⊕H(x)〉. This means
that we must work in the Quantum Random Oracle Model (QROM) [BDF+11], which grants
all parties oracle access to UH. Proving the security of transformations like FS in the QROM
is the subject of recent research, and newly developed techniques have largely shown that FS
in the QROM preserves soundness for so-called ÎŁ-protocols [DFMS19, LZ19]. Extending those
results to our protocols is relatively straightforward. Applying FS to the three-round verification
protocol from Theorem 1.1 then yields the following.

Theorem 1.3. Let k = ω(log n), and let FS(Mk) denote the protocol resulting from applying Fiat-

Shamir to the k-fold parallel repetition of the three-round Mahadev protocol. Under the LWE assumption,

in the QROM, FS(Mk) is a non-interactive protocol (with offline setup) for verifying BQP with negligible

completeness and soundness errors.

If we instead apply the Fiat-Shamir transform to the zero-knowledge protocol from Theorem 1.2,
we achieve the following.

Theorem 1.4 (informal). Under the LWE assumption, in the QROM, there exists a classical non-

interactive zero-knowledge argument (with trusted offline setup) for QMA, with negligible completeness

and soundness errors.

Related results. Broadbent, Ji, Song, and Watrous [BJSW16] presented the first quantum zero-
knowledge proofs for QMA with efficient provers. Vidick and Zhang [VZ19] combined this
protocol with the Mahadev protocol [Mah18] to make the communication classical. Broadbent
and Grilo [BG19] showed a “quantum Σ” zero-knowledge proof for QMA (with a quantum ver-
ifier). In the non-interactive setting, Coladangelo, Vidick, and Zhang [CVZ19] constructed a
non-interactive zero-knowledge argument with quantum setup and Broadbent and Grilo [BG19]
showed a quantum statistical zero-knowledge proof in the secret parameter model.

We remark that Radian and Sattath [RS19] recently established what they call “a parallel rep-
etition theorem for NTCFs,” which are the functions fpk in the Mahadev protocol. However, the
context of [RS19] is very different from that of our Theorem 1.1. They work with 1-of-2 puzzles,
not BQP verification; in particular, their soundness experiment is quite different. Moreover, their
parallel repetition theorem follows from a purely classical result.

After an initial version of our work was made public, showing how the Mahadev protocol can
be reduced to four rounds using parallel repetition and the Fiat-Shamir transform, Chia, Chung,
and Yamakawa posted a preprint [CCY19] describing the same result, with an alternative proof
of parallel repetition. They also showed how to make the verifier run in time polylogarithmic in
the instance size using indistinguishability obfuscation. Our work was performed independently,

6



and we subsequently improved our result to make the protocol non-interactive with setup and
zero-knowledge.

Open problems. This work raises several natural open questions. First, is it possible to prove
the soundness of our protocol when the oracle H is instantiated with a concrete (e.g., correlation-
intractable [PS19]) hash function? Our current analysis only applies in an idealized model.

It is also natural to study parallel repetition for general QPIAs. Natural examples include
the protocols of [GV19, VZ19, BCM+18]. It is known that parallel repetition does not reduce the
soundness error even for all classical private-coin protocols [BIN97]. However, if the classical
protocol is slightly modified to to include “random terminations” with low probability, then
parallel repetition is in fact possible [Hai09, HPWP10, BHT19]. It is an open question whether
similar mild relaxations can enable a parallel repetition theorem for any QPIA.

Finally, we remark that a classical NIZK protocol (in the Random Oracle Model with setup)
could also be achieved using the techniques of locally simulatable codes/proofs [GSY19, BG19].
We leave as an open problem understanding whether such a protocol could give us useful prop-
erties that are not achieved with our current approach.

Organization. The remainder of the paper is organized as follows. In Section 2, we introduce
QPIAs, the local Hamiltonian problem as it relates to BQP verification, the Mahadev protocol,
and non-interactive zero knowledge. In Section 3, we explain how to make the initial step of
the protocol instance-independent. In Section 4, we show that parallel repetition reduces the
soundness error of the Mahadev protocol at the optimal rate. In Section 5, we describe how to
make the protocol zero-knowledge. Finally, in Section 6, we show that under the Fiat-Shamir
transformation, a generalization of ÎŁ-protocols (which includes the protocols of interest to us)
remains secure in the QROM, and we use this to establish non-interactive protocols (with offline
setup) for verifying BQP and for zero-knowledge verification of QMA.

2 Preliminaries

2.1 Notation and conventions

Most algorithms we consider are efficient, meaning that they run in time polynomial in both the
input size (typically n) and the security parameter (typically Îť). We assume that n and Îť are
polynomially-related. The two main classes of algorithms of interest are PPT (probabilistic poly-
time) and QPT (quantum poly-time). We say that f = negl(n) if f = o(n−c) for every constant c.
We denote by U f the efficient map that coherently implements a classical function f : {0, 1}n →
{0, 1}m , i.e., U f |x〉|y〉 = |x〉|y ⊕ f (x)〉, when there exists an efficient deterministic circuit that
computes f . We make use of commitment schemes and fully-homomorphic encryption; for
completeness we define them in Appendix A.

2.2 Quantum-prover interactive arguments

A quantum-prover interactive argument (QPIA) is an interactive protocol between two polynomially-
bounded parties, a quantum prover and a classical verifier, interacting over a classical channel.

7



A QPIA is described by a pair of algorithms: the PPT algorithm of the honest verifier V , and the
QPT algorithm of the honest prover P .

Definition 2.1. Fix a language L ⊆ {0, 1}∗ and a QPIA (P ,V). We say that (P ,V) is a QPIA for L

with completeness c and soundness error s if

• for all x ∈ L, Pr[P and V accept x] ≥ c.

• for all x /∈ L and for all QPT algorithms P ′, Pr[P ′ and V accept x] ≤ s.

The completeness error is 1− c and the soundness is 1− s.

As discussed above, the soundness of a QPIA can be amplified via sequential repetition, and
in some cases also with parallel repetition.

2.3 The local Hamiltonian problem and verification for BQP

Any promise problem L = (Lyes, Lno) ∈ QMA can be reduced to the local Hamiltonian problem
such that for x ∈ Lyes, the Hamiltonian Hx has a low-energy ground state |ψx〉, and for x ∈ Lno,
all quantum states have large energy [KSV02]. While the quantum witness |ψx〉 may be hard
to prepare for general L ∈ QMA, it can be prepared efficiently if L ∈ BQP. Furthermore, the
problem remains QMA-complete even with a Hamiltonian that can be measured by performing
standard (Z) and Hadamard (X) basis measurements [BL08, CM16].

Problem 1 (The 2-local ZX-Hamiltonian problem [BL08,CM16,MF16]). The 2-local ZX-Hamiltonian

promise problem zx = (zxyes, zxno), with parameters a, b ∈ R, b > a and gap (b− a) > poly(n)−1, is

defined as follows. An instance is a local Hamiltonian

H = ∑
i<j

Jij(XiXj + ZiZj)

where each Jij is a real number such that 2 ∑i<j |Jij| = 1 and each Xi (resp. Zi) is a Pauli X (resp. Pauli Z)

gate acting on the ith qubit. For H ∈ zxyes, the smallest eigenvalue of H is at most a, while if H ∈ zxno,

the smallest eigenvalue of H is at least b.

Note that given the normalization factors, we can see that each term (XiXj or ZiZj) is asso-
ciated with the probability Jij. We denote the 2-local ZX-Hamiltonian problem with parameters
a, b ∈ R by zxa,b.

When working with Hamiltonian terms S, we overload the notation for convenience. First,
we write Sj to denote the Pauli operator assigned by S to qubit j, so that S =

⊗
j Sj. Second, we

write i ∈ S to indicate that i is a qubit index for which S does not act as the identity, i.e., Si 6= 1.

Morimae and Fitzsimons present a protocol (the “MF protocol”) with a quantum prover and
a limited verifier who only needs the ability to perform single-qubit X and Z basis measurements
[MF16]. The prover P prepares the ground state of the Hamiltonian and sends it to V , who then
samples a term S with probability pS and performs the corresponding measurement. Notice that
to estimate the energy of term S, only Z or X basis measurements are necessary. In the original
protocol of [MF16], the qubits are sent individually; in the variant below, we simply have the
prover send the entire state all at once.

8



Protocol 1 (A variant of the MF protocol).

Setup. P and V receive an instance of Problem 1, namely a Hamiltonian Hx = ∑S pS
1+mSS

2 ,

where each S is a tensor product of X, Z,1 and mS ∈ {¹1}.
Round 1. P prepares a quantum state ρ and sends it to V .

Verdict. V samples a term S with probability pS and performs the measurement {M1 = 1+S
2 , M−1 =

1−S
2 } on ρ, getting an outcome e. V accepts if e = −mS.

Since MmS
= 1+mSS

2 = 1−M−mS
and Hx = ∑S pS MmS

, the success probability of the protocol
with input state ρ is

∑
S

pS tr(M−mS
ρ) = 1−∑

s

pS tr(Mmsρ) = 1− tr(Hxρ).

Since b− a > poly(|x|)−1, the error in the MF protocol can be made negligible by parallel repeti-
tion: V receives T copies of the ground state of H and performs an independent test on each copy.
By accepting if at least (2− a− b)T/4 copies accept, both the completeness and soundness errors
are suppressed to negligible with polynomial T(|x|) (cf. [Mah18, Theorem 8.4]). For a detailed
proof of QMA gap amplification, see [VW16, Section 3].

In the following discussion, the term S is encoded by an n-bit string h(S): for each qubit i ∈ S,
set hi = 0 for a Z basis measurement and hi = 1 for an X basis measurement. For other qubits,
the choice is irrelevant but we set hi = 0 for concreteness. We let αh,ρ := tr(M−mS

ρ) denote the
success probability with ρ when h = h(S) is sampled in Protocol 1.

2.4 The Mahadev protocol for BQP verification

Required primitives. The protocol relies crucially on two special classes of functions: Noisy
Trapdoor Claw-free Functions (NTCFs) F and Noisy Trapdoor Injective Functions (NTIFs) G.
Both classes of functions are constructed based on the presumed hardness of the Learning with
Errors (LWE) problem [BCM+18,Mah18]. We now sketch the properties of these function families.
For complete details, and for the LWE construction, see [BCM+18]. Let Îť be a security parameter
and let q ≥ 2 be prime. Choose parameters ℓ = poly(λ), n = Ω(ℓ log q), and m = Ω(n log q).

The NTCF family F = { fpk}pk∈KF is a family of keyed functions

fpk : {0, 1} × X → DY

which, on input a public key pk ∈ KF := Z
m×n
q × Z

m
q , a bit b, and x ∈ X := Z

n
q , outputs a

distribution fpk(b, x) over Y := Z
m
q . Each function fpk ∈ F satisfies the injective pair property:

there exists a perfect matching Rpk ⊂ X × X such that fpk(0, x0) = fpk(1, x1) if and only if
(x0, x1) ∈ Rpk.

The NTCF family is equipped with the following polynomial-time algorithms:

1. GenF , on input 1Îť, outputs a secret-public key pair (pk, sk).

2. ChkF is a deterministic algorithm for checking if (b, x) and y form a preimage-image pair
of fpk. On input b, x, y, ChkF outputs 1 iff y ∈ supp ( fpk(b, x)).

9



3. InvF is a deterministic algorithm for inverting the function fpk. On input secret key sk, bit
b, and image y, InvF returns the preimage xb,y such that y ∈ supp ( fpk(b, xb,y)), or outputs
reject if no such preimage exists.

4. SampF is an efficient quantum process which, on input pk and b ∈ {0, 1}, returns a quantum
state negligibly close to

1
|X |1/2 ∑

x∈X
|b〉|x〉|ψ fpk(b,x)〉, (2)

where |ψp〉 := ∑y∈Y
√

p(y)|y〉 for distribution p. By the injective pair property, we have
〈ψ fpk(b,x)|ψ fpk(b′,x′)〉 = 1 if (b, x) = (b′, x′), or there exists (x0, x1) ∈ Rpk such that (b, x, b′, x′) =
(0, x0, 1, x1) or (1, x1, 0, x0). This implies that the states in {|ψ fpk(b,x)〉} can be perfectly distin-
guished by performing a standard basis measurement. Thus, intuitively, we may consider
an ideal version of these functions, i.e., the distribution p is concentrated at a single point.

Similarly, the NTIF family G = {gpk}pk∈KG is a family of keyed functions

gpk : {0, 1} × X → DY

which, on input a public key pk ∈ KG , a bit b, and x ∈ X , outputs a distribution gpk(b, x) over
Y . Instead of the injective pair property of NTCFs, NTIFs satisfy an injectivity property: for
all (x, b) 6= (x′, b′), supp gpk(b, x) ∩ supp gpk(b

′, x′) = ∅. An NTIF family is also equipped with
a tuple of four polynomial-time algorithms (GenG ,ChkG , InvG , SampG), defined exactly as in the
NTCF case (but with g in place of f , and G instead of F .)

We remark that the states (2) prepared by SampF and SampG should be contrasted with the
“idealized” state described in (1) in our sketch of the protocol.

The protocol. The Mahadev protocol [Mah18] for BQP verification allows V to request an X

or Z basis measurement outcome without revealing the basis to P . The aim of the protocol is
to verify that the prover’s response, when appropriately decoded, is close to the measurement
outcomes of some n-qubit quantum state ρ. Crucially, this guarantee holds simultaneously for
all basis choices h ∈ {0, 1}n , where 0 denotes a Z basis measurement and 1 denotes an X basis
measurement. With this guarantee, the verifier can then apply the verification procedure of the
MF protocol to the decoded responses of the prover, knowing that this will correctly decide
whether the instance should be accepted or rejected.

In the following protocol, for each qubit, if V requests a Z basis measurement, then an NTIF
key is sent; if V requests an X basis measurement, then an NTCF key is sent. Since ChkF and
ChkG are identical, we denote them by Chk. Similarly, SampF and SampG are identical, so we
denote them by Samp. We let Gen(1λ, h) for h ∈ {0, 1}∗ denote the following key generation
algorithm: for every bit i of h, run (pki, ski) ← GenG(1λ) if hi = 0 and (pki, ski) ← GenF (1λ) if
hi = 1. Set pk = (pki)i and sk = (ski)i and output the key pairs (pk, sk).

We now the describe the protocol when V and P are honest.

Protocol 2 (Mahadev protocol).

Setup. Choose a security parameter λ ≥ n. Both P and V receive an instance of Problem 1, namely

H = ∑S pS
1+mSS

2 .

10



Round V1. V samples r terms S = (S1, . . . , Sr) and computes h = h(S). V generates the key pair

(pk, sk) ← Gen(1λ, h) and sends pk to P .

Round P1. P prepares r copies of the n-qubit ground state |φ〉⊗r = ∑b∈{0,1}n φb|b〉W of H in register

W. For j ∈ [r], ℓ ∈ [n] and each qubit Wjℓ in W, P performs Samp on input the key pki

coherently and yields a quantum state negligibly close to

1
|X |n/2 ∑

x∈X n
∑

b∈{0,1}nr

φb|b〉W |x〉X |ψ fpk(b,x)〉Y .

Next, P measures Y and sends the outcome y to V .

Round V2. V responds with a uniformly random “challenge” bit c ∈ {0, 1}. We call c = 0 “test

round” and c = 1 “Hadamard round,” and set labels t = 0 and h = 1.

Round P2. If c = t, P measures WX in the computational basis. If c = h, P measures WX in the

Hadamard basis. In either case, P sends the measurement outcome (w, t) to V ;

Verdict. In a test round, V accepts if
∧

j∈[r],ℓ∈[n] Chk(pkjℓ, wjℓ, tjℓ, yjℓ) = 1.

In";"""date"",""2020-03-10T00:56:33Z""
""pdf:PDFVersion"",""1.4""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.4""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""xmp:CreateDate"",""2020-03-09T20:56:33Z""
""modified"",""2020-03-10T00:56:33Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""xmp:ModifyDate"",""2020-03-09T20:56:33Z""
""pdf:docinfo:creator"",""""
""meta:author"",""""
""meta:creation-date"",""2020-03-10T00:56:33Z""
""created"",""2020-03-10T00:56:33Z""
""xmp:About"",""uuid:88f121c1-9a86-11f5-0000-4ea83f686bd8""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-03-10T00:56:33Z""
""resourceName"",""1911.08101""
""Author"",""""
""producer"",""dvips + GPL Ghostscript GIT PRERELEASE 9.22""
""pdf:docinfo:producer"",""dvips + GPL Ghostscript GIT PRERELEASE 9.22""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""2"",""0"",""0"",""0"",""5"",""4"",""5"",""6"",""11"",""6"",""15"",""3"",""6"",""9"",""24"",""20"",""38"",""2"",""2"",""1"",""0"",""15"",""5"",""4"",""6"",""0"",""0"",""7"",""20"",""19"",""33"",""28"",""58"",""0"",""5"",""17""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2020-03-10T00:56:33Z""
""Last-Modified"",""2020-03-10T00:56:33Z""
""dcterms:modified"",""2020-03-10T00:56:33Z""
""title"",""""
""xmpMM:DocumentID"",""uuid:88f121c1-9a86-11f5-0000-4ea83f686bd8""
""Last-Save-Date"",""2020-03-10T00:56:33Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2020-03-10T00:56:33Z""
""meta:save-date"",""2020-03-10T00:56:33Z""
""Content-Length"",""415441""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""37""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""2128"",""2415"",""2998"",""2906"",""2939"",""3070"",""2608"",""2265"",""2133"",""2447"",""1833"",""1841"",""2629"",""2782"",""2455"",""2615"",""2944"",""1773"",""2212"",""2241"",""1562"",""2040"",""2581"",""1848"",""1783"",""2304"",""3018"",""3236"",""1776"",""1664"",""1383"",""1957"",""1656"",""1028"",""2210"",""2123"",""1408""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-03-10T00:56:33Z""
";https://scholar.google.ch/scholar?start=770&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098795-178;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;[PDF][PDF] Enhanced Retrieval of Secure Data Over Attribute-Based Document Collection Hierarchical Encryption Scheme in Cloud Computing;K SANDEEPUKUMAR, K SEERAPU ; shabdbooks.com;;"… 440-456. [5]X. Boyen, B. Waters, “Anonymous hierarchical identity-based encryption(without

random oracles),”inProc.CRYPTO, Santa Barbara, California, USA, August.2006, pp. 290-307.

[6]B. Waters, “Dual system encryption: Realizing fully secure IBE and HIBE under simple …";Autres articles;Version HTML;[PDF] shabdbooks.com;http://shabdbooks.com/gallery/96-sep2020.pdf;"
Enhanced Retrieval of Secure Data Over Attribute-Based Document 

Collection Hierarchical Encryption Scheme in Cloud Computing  

 

       KORLAM SANDEEPUKUMAR #1, KESAVARAO SEERAPU #2  
 

#1 M.Tech Student, Department of Computer Science and Engineering, 

Avanthi Institute of Engineering & Technology, Cherukupally (P),Bhogapuram (M),  

Near Tagarapuvalasa, NH16, Kotabhogapuram, Andhra Pradesh 535006. 

 
#2

 Assistant Professor, 

Department of Computer Science and Engineering, 

Avanthi Institute of Engineering & Technology, Cherukupally (P),Bhogapuram (M),  

Near Tagarapuvalasa, NH16, Kotabhogapuram, Andhra Pradesh 535006 

 
ABSTRACT  

 

 In current day’s secure document storage and retrieval is one of the hottest research 

directions in cloud computing. Although many searchable encryption schemes have been 

proposed, few of them support efficient retrieval over the documents which are encrypted based 

on their attributes.In this paper, we propose a practical Ciphertext-Policy Attribute-Based 

Hierarchical document collection Encryption scheme named CP-ABHE. In general we can 

clearly identify that CP-ABHE is more efficient in both computation and storage space without 

sacrificing data security. In CP-ABHE, we first construct a set of integrated access trees based on 

the documents' attribute sets. We employ the greedy strategy to build the trees incrementally and 

grow the trees dynamically by combining the small ones. Here we try to integrate a new concept 

like CA(Certificate Authority) in which the CA will take the responsibility of verifying the user 

request to and from the cloud server and then grant permissions for the data users. Those who got 

permission from the CA can able to access the data in a plain text manner and remaining users 

can be able to access the data only in cipher manner. A thorough analysis and a series of 

experiments are performed to illustrate the security and efficiency of the proposed scheme. 

 

Key Words:   

 Ciphertext-Policy Attribute-Based Hierarchical, Certificate Authority, Encryption, Cloud 

Computing. 

Mukt Shabd Journal

Volume IX, Issue IX, SEPTEMBER/2020

ISSN NO : 2347-3150

Page No : 951



1. Introduction 
 

 Cloud computing, a rising innovation was first proposed in Quite a while 2006(Search 

Engine Strategies 2006) by San Jose and characterized by NIST(National Institute of Standards 

and Technology).Since it was proposed distributed computing has pulled in more noteworthy 

consideration from various areas of society. Distributed computing can gather and rearrange an 

enormous measure of information and obviously, the cloud workers can give safer and adaptable, 

monetary and customized administrations contrasted and the neighborhood workers. As cloud 

administrations have gotten more well-known, requests for figuring information in the cloud 

have expanded. Regardless of the benefits of cloud administrations, releasing the delicate data, 

for example, individual data to the general population is a major danger to the information 

proprietors. What's more, to utilize the information on the cloud, the information clients need to 

get to them deftly and proficiently. A natural methodology is to encode the archives first and 

afterward transferring them to the cloud[1].  

 

CLOUD SERVICE MODELS  

 Cloud Computing includes three distinctive help models, to be specific Infrastructure-as-

a-Service (IaaS), Platform-as-a-Service (PaaS), and Software-as-a-Service (SaaS). The three help 

models or layer are finished by an end client layer that epitomizes the end client point of view on 

cloud administrations. The model is appeared in figure beneath[2]. On the off chance that a cloud 

client gets to administrations on the foundation layer, for example, she can run her own 

applications on the assets of a cloud framework and stay answerable for the help, upkeep, and 

security of these applications herself. In the event that she gets to an assistance on the application 

layer, these assignments are typically dealt with by the cloud specialist organization[3].  

 

DATABASE-AS-A-SERVICE (DBAAS)  

 In our plan, we use DataBase-as-a-Service (DBaaS) administration model, which is a 

distributed computing administration model that furnishes clients with some type of access to a 

database without the requirement for setting up physical equipment, introducing programming or 

designing for execution. The entirety of the regulatory undertakings and support are dealt with 

by the specialist organization so the clients or application proprietors should simply utilize the 

database[4]. 

Mukt Shabd Journal

Volume IX, Issue IX, SEPTEMBER/2020

ISSN NO : 2347-3150

Page No : 952



 

Figure 1.Denote the Flow  of Database as a Service(DaaS) Model 

2. BACKGROUND WORK 

 

In this section we will mainly discuss about the background work that is carried out in 

order to prove the performance of our proposed approach for retrieving secure documents from 

the cloud server using hierarchal attribute based encryption technique[5]. 

 

MOTIVATION 

 

 The term CP-ABE is mainly evolved from AES algorithm and it is extremely 

complicated mathematically. The proposed CP-ABE algorithm [6] is not only used for 

encrypting the data with a secret key but also has an additional advantage like it will try to 

embed the corresponding access policy and try to store the data with some access restrictions. 

This access policy greatly help the end users to restrict the un-authorized users not to access the 

secure data in illegal manner. In current days the CP-ABE is affected with some limitations 

which are mainly disturbing the data security, this is because if any user changes the access 

Mukt Shabd Journal

Volume IX, Issue IX, SEPTEMBER/2020

ISSN NO : 2347-3150

Page No : 953



policy the overall decryption process is also extremely complicated, therefore one of the major 

issue. 

 

1. ACCESS POLICY MANAGEMENT: This is one of the issues in which whole design 

the access policy for individual this is more secure, if the same access policy need to set 

for multiple users or group of users at a time this is having some complications in 

generating the group keys and managing the access policies[7]. 

 

2. ATTACK PREVENTION: This is one more limitation in current CP-ABE algorithm, 

where if anyone wants to decrypt the data they need the secret key or private key to 

access the file but if the same key is known to the un-authorized user. The data can be 

accessed illegally by that end user and hence it is not able to prevent under attack case. 

 

3. BANDWIDTH AND LATENCY MANAGEMENT: If we take example of medical 

data to store into the system, if the medical company wants to process the medical data 

and store into the cloud server, then it is required to store the data with a lot of processing 

overhead, which is one of the main limitations in the current systems[8]-[10]. 

 

3. PROPOSED  CP-ABHE  ALGORITHM 

 

In this section we mainly define about the proposed Ciphertext-Policy Attribute-Based 

Hierarchical document collection Encryption (CP-ABHE) algorithm for providing more security 

for the retrieval of sensitive documents from the cloud server. 

 

PRELIMINARY KNOWLEDGE 

 
 The system  model  comprise  of  four  components:  

1. Data  Owner,   

2. Data  User,   

3. Certificate Authority (CA) Center &  

4. The Cloud Server.  

Mukt Shabd Journal

Volume IX, Issue IX, SEPTEMBER/2020

ISSN NO : 2347-3150

Page No : 954



 The file owner/Data Owner one who is mainly used for collecting a set of documents or 

files from the information centers and then it is assigned with a proper attributes to store all those 

information into the cloud server. The files are encrypted in two different stages[11].  

 

 In the initial stage , every file Fi is encrypted  using  a  symmetric  encryption  technique  

using  a  distinct  content  key cki.   

 

 In the next stage,  the  entire  content  keys  of  the  file  F  are  encrypted  by  using  the  

ABE schemes. Both the encrypted file and the content keys are outsourced on the server.  

 

 The certificate authority (CA) is the main attribute among all the attributes which is used 

to collect all the files information and then try to collect the user information and this will now 

assign the access policies for the files corresponding to that users. 

 

Figure 2. Represent the Proposed CP-ABHE Algorithm  

 

Mukt Shabd Journal

Volume IX, Issue IX, SEPTEMBER/2020

ISSN NO : 2347-3150

Page No : 955



 These access policies are almost hidden and the data users cannot able to break these 

access policies for every individual files. In our proposed application we try to set access policies 

in hierarchal manner where a group of files and group of users are shared with common 

privileges to secure the data. 

 

 The cloud server use a search engine to find the encrypted file from the file collection to 

obtain  the  corresponding  CT  to  the  query.  On receiving the CT  and  CK, the  file user 

decrypt the CK using his\her attribute related hidden key and then use the CK to decrypt. 

 

ALGORITHM  PROCEDURE 

 

The following is the algorithm procedure in which we can able to describe the step by 

step procedure for the current application. 

 

STEP 1:  

Initially the data owner or file owner and file user need to register into the application 

with all their basic details including bio metric authentication like finger print images. This is 

mainly used to authenticate the user accurately at the time of file accessing and file downloading. 

 

STEP 2:  

Now the cloud server will try to activate the owner and user who are registered and try to 

provide access for file uploading or file download from the cloud server in a secure manner. 

 

STEP 3 :  

The data owner need to upload the file in  a secure manner by encrypting the file and then 

try to provide access preferences for the individual or group of files and users in a single attempt. 

 

STEP 4:  

Now the data user try to search for the set of files which are present in the cloud server 

and then try to access the same file in a plain text manner. For decrypting the file the data user 

need to verify its identity with the certificate authority and then request for the decryption key. 

Once the decryption key is received by the end user then only the data can be accessed. 

Mukt Shabd Journal

Volume IX, Issue IX, SEPTEMBER/2020

ISSN NO : 2347-3150

Page No : 956



STEP 5:  

The certificate authority (CA) try to receive the user request and then it will verify the 

identity of user who requested that file and then try to grant the secret key and allow access for 

the end user who want to download the file in a plain text manner. 

 

Here the same file may be requested by the multiple authorities at a time and the CA will 

try to either allow or deny the access of that file based on his own interest and those who is 

accepted for decryption will be decrypt the file and those who don’t have permission cannot able 

to access the file. 

 

STEP 6:  

The data user will now receive the decryption key from the CA and now they can able to 

access the file in a plain text manner. 

 

4. IMPLEMENTATION PHASE 
 

Implementation is the stage where the theoretical design is converted into 

programmatically manner. In this stage we will divide the application into a number of modules 

and then coded for deployment. The front end of the application takes JSP,HTML and  Java 

Beans and as a  Back-End Data base we took My SQL data base. The application is divided 

mainly into following 4 modules. They are as follows: 

1) DATA  OWNER  MODULE 

 In this module, initially the data owner has to register to the cloud server and get 

authorized. After the authorization from cloud  data owner will encrypt  and add file to the cloud 

server where in after the addition of file data owner View All Uploaded Files, View All 

Transactions. 

2) CLOUD  SERVER  MODULE 

 The cloud server manages a cloud to provide data storage service. Data owners encrypt 

their data files and store them in the cloud for sharing with cloud End users and performs the 

following operations such as View All Owners and Authorize, View All Users and Authorize, 

Mukt Shabd Journal

Volume IX, Issue IX, SEPTEMBER/2020

ISSN NO : 2347-3150

Page No : 957



View All Cloud Files ,View All Transactions, View All Attackers ,View File Score Results 

,View Time Delay Results ,View Throughput Results 

 

3) CERTIFICATE AUTHORITY (CA) MODULE  

 CA generates the content key and the secret key requested by the end user and also View 

All Attackers. 

  

4) END USER MODULE 

 User has to register and login for accessing the files in the cloud. User is authorized by 

the cloud to verify the registration. User has to View All Files Download. 

 

                       5. CONCLUSION 

 
In this paper we for the first time have construct a we propose a practical Ciphertext-Policy 

Attribute-Based Hierarchical document collection Encryption scheme named CP-ABHE. In 

general we can clearly identify that CP-ABHE is more efficient in both computation and storage 

space without sacrificing data security. In CP-ABHE, we first construct a set of integrated access 

trees based on the documents' attribute sets. We employ the greedy strategy to build the trees 

incrementally and grow the trees dynamically by combining the small ones. Here we try to 

integrate a new concept like CA(Certificate Authority) in which the CA will take the 

responsibility of verifying the user request to and from the cloud server and then grant 

permissions for the data users. Those who got permission from the CA can able to access the 

data in a plain text manner and remaining users can be able to access the data only in cipher 

manner.By conducting various experiments on our proposed method we finally came to an 

conclusion that CP-ABHE algorithm is best suited to provide security for the sensitive data to 

access from the cloud server. 

                      6. REFERENCES 
 

[1]J. Horwitz,B. Lynn, “Towards hierarchicalidentity-based encryption,”inProc.EUROCRYPT, 

Amsterdam, The Netherlands, April.2002, pp.466-481. 

[2]C. Gentry, A. Silverberg, “Hierarchical ID-based cryptography,”inProc.ASIACRYPT, 

Singapore, December. 2002, pp. 548-566. 

Mukt Shabd Journal

Volume IX, Issue IX, SEPTEMBER/2020

ISSN NO : 2347-3150

Page No : 958



[3]D. Boneh, X. Boyen, “Efficient Selective-ID secure identity based encryption without random 

oracles,”inProc.EUROCRYPT, Interlaken, Switzerland, May.2004,pp. 223-238. 

 

[4]D. Boneh, X. Boyen, E. Goh, “Hierarchical identity based encryption with constant size 

ciphertext,”inProc.EUROCRYPT, Aarhus, Denmark, May.2005, pp. 440-456. 

 

[5]X. Boyen, B. Waters, “Anonymous hierarchical identity-based encryption(without random 

oracles),”inProc.CRYPTO, Santa Barbara, California, USA, August.2006, pp. 290-307. 

 

[6]B. Waters, “Dual system encryption: Realizing fully secure IBE and HIBE under simple 

assumptions,”inProc.CRYPTO,Santa Barbara, CA,August. 2009, pp.619-636. 

 

[7]A. Lewko, B. Waters, “New techniques for dual system encryption and fully secure HIBE 

with short ciphertexts,”inProc.TCC,Zurich, Switzerland, February.2010, pp. 455-579. 

 

[8]G. Wang, Q. Liu, J. Wu, “Hierarchical attribute-based encryption for fine-grained access 

control in cloud storage services,”inProc.CCS, Chicago,Illinois, USA, October.2010, pp. 735-

737. 

 

[9] G. Wang, Q. Liu, J. Wu,M. Guo, “Hierarchical attribute-based encryption and scalable user 

revocation for sharing data in cloud servers,”Computers&security, 30 (5), pp. 320-331, 

July.2011. 

 

[10]Zhiguo Wan, Jun’e Liu, Robert H. Deng, “HASBE: A Hierarchical attribute-based solution 

for flexible and scalable access control in cloud computing,”IEEE Transactions on Information 

Forensics and Security, 7(2),pp. 743-753, April.2012. 

 

[11] Q. Huang, L.Wang, Y.Yang, “DECENT: Secure and fine-grained data access controlwith 

policy updating for constrained IoT devices,”World Wide Web, 2017 (11), pp. 1-17, 2017. 

Mukt Shabd Journal

Volume IX, Issue IX, SEPTEMBER/2020

ISSN NO : 2347-3150

Page No : 959


";"""date"",""2020-09-28T04:47:28Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.4""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dcterms:created"",""2020-09-28T04:47:28Z""
""language"",""en""
""Last-Modified"",""2020-09-28T04:47:28Z""
""dcterms:modified"",""2020-09-28T04:47:28Z""
""dc:format"",""application/pdf; version=1.4""
""Last-Save-Date"",""2020-09-28T04:47:28Z""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2020-09-28T04:47:28Z""
""meta:save-date"",""2020-09-28T04:47:28Z""
""pdf:encrypted"",""false""
""modified"",""2020-09-28T04:47:28Z""
""Content-Length"",""193395""
""pdf:hasMarkedContent"",""false""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""meta:creation-date"",""2020-09-28T04:47:28Z""
""created"",""2020-09-28T04:47:28Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""9""
""Creation-Date"",""2020-09-28T04:47:28Z""
""resourceName"",""96-sep2020.pdf""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""2129"",""2474"",""1071"",""1630"",""1008"",""1908"",""1825"",""2024"",""1720""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""producer"",""PlotSoft PDFill 12.0""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""PlotSoft PDFill 12.0""
""pdf:docinfo:created"",""2020-09-28T04:47:28Z""
";https://scholar.google.ch/scholar?start=720&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098778-138;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;[HTML][HTML] Blockchain based peer-review interfaces for digital medicine;V Dhillon ; Frontiers in Blockchain, 2020  frontiersin.org;Switzerland;"… The validators can use this oracle to adjudicate any reputation conflicts that arise on the … The

argument for a crypto-specific space becomes relevant in the context of memory leaks … A blockchain

based social media platform called Steem is creating a space where content creators …";Cité 2 fois;Les 2 versions;[HTML] frontiersin.org;https://www.frontiersin.org/articles/10.3389/fbloc.2020.00008/full?utm_source=S-TWT&utm_medium=SNET&utm_campaign=ECO_FBLOC_XXXXXXXX_auto-dlvrit;"
    
    
        
    

    

        

        

    


    

    

    
        



            
            
                
                    Your research can change the world
More on impact ›

                

            

        

    
        	
                        
                            
                                Frontiers in Blockchain
                            
                        

                    	
                            
                                
                                    Blockchain for Science


                                
                            

                        




        
     





    
    
        
            
                
                    
                        
                        
                            Toggle navigation
                            
                                
                                
                                
                            
                            Section
                        
                        
                        
                            	
                                    (current)Section
                                
	
                                    About
                                
	
                                    Articles
                                
	
                                    Research topics
                                
	
                                    For authors 
                                    	Why submit?
	Fees
	Article types
	Author guidelines
	Review guidelines
	Submission checklist
	Contact editorial office
	Submit your manuscript


                                
	
                                    Editorial board
                                


                        

                        	
                                
                                    
                                
                            
	
                                
                                    
                                
                            
	
                                
                                    Article alerts
                                
                            



                    
                

            

        

    







    
        
            
                    
                        
                            
                                
                                    This article is part of the Research Topic
                                

                                
                                   
                                        Blockchain for Distributed Research
                                        
                                            View all

                                                    5
                                                
                                            Articles 
                                        

                                   
                                

                            

                        
                    

            

            
                
                     Articles
                
            
        

    






    
                
                    Edited by

                    
                        [image:  ]
                        Dean KoroĹĄak

                    
                    

                    University of Maribor, Slovenia

                
                
                     Reviewed by

                            
                                [image:  ]
                                Jonathan M. Fuchs, FACHE

                            
                            

                        Independent researcher, United States

                            
                                [image:  ]
                                Erika Beerbower

                            
                            

                        Independent researcher, United States

                    The editor and reviewers' affiliations are the latest provided on their Loop research profiles and may not reflect their situation at the time of review.

                
    

    
            TABLE OF CONTENTS

            	
	Abstract
	Introduction
	Discussion
	Author Contributions
	Conflict of Interest
	References


                


    




    
            
                [image: ]


Suggest a Research Topic >

            

        

            

        
            
        
    
        
    
        
            	
                        
                            
                            Download Article
                        
                        	
                                    
                                        Download PDF
                                    
                                
	
                                    
                                        ReadCube
                                    
                                
	
                                    
                                        EPUB
                                    
                                
	
                                    
                                        XML (NLM)
                                    
                                
	

                                        
                                            Supplementary
                                            

                                            Material
                                        

                                


                    
	
                    
                        
                        Export citation
                    
                    	
                                
                                    EndNote
                                
                            
	
                                
                                    Reference Manager
                                
                            
	
                                
                                    Simple TEXT file
                                
                            
	
                                
                                    BibTex
                                
                            


                


        

            
            	
                    
                    total views
                
	
                    
                        

                    

                


                
                     View Article Impact
                
        

            
            [image: ]


Suggest a Research Topic >

        

    
        SHARE ON

        	
                
                    
                

                
            
	
                
                    
                

                
            
	
                
                    
                

                
            
	
                
                    
                

                
            


    




            

    
        
            
                
                
                    
                        
                        
                        [image: ]
                        
                            
                            
                        

                                       

                        
                                
                                    PERSPECTIVE article
                                

                        

                
                    Front. Blockchain, 05 March 2020
                             | https://doi.org/10.3389/fbloc.2020.00008
                

                

                

[bookmark: h1]Blockchain Based Peer-Review Interfaces for Digital Medicine


[image: ]Vikram Dhillon*

	College of Osteopathic Medicine, Nova Southeastern University, Fort Lauderdale, FL, United States


Over the last decade, strong evidence is emerging from multiple disciplines of scientific inquiry ranging from behavioral psychology to clinical medicine that many published scientific studies are not reproducible. The best-known retrospective analyses from psychology (Rahal and Open Science Collaboration, 2015) and cancer biology (Begley and Ellis, 2012) report staggeringly low replication rates of 40 and 20%, respectively. This has led to the phenomenon of a “reproducibility crisis” where a significant amount of funding, research effort and even public policy has come to depend on non-reproducible research (Goodman et al., 2016). In this perspective article, I outline how the blockchain can be used to power a decentralized peer-review system for digital health applications. This is followed by a discussion of how such a system impacts the broader issue of scientific reproducibility, and how existing blockchain protocols can help alleviate the barriers to reproducibility.






[bookmark: h2]Introduction

In 2005, Dr. John Ioannidis of Stanford University published a report in PLoS Medicine titled “Why Most Published Research Findings Are False,” which eventually became a cornerstone of discussion regarding interpretation of statistical significance testing and the value it provides to the claims of a report (Ioannidis, 2005). In 2011, the Center of Open Sciences launched a project to replicate 100 different studies that were published in 2008 from the field of psychology (Rahal and Open Science Collaboration, 2015). The results of this initiative were published in 2015, and demonstrated that even though 97% of the original results claimed statistically significance, this was only recapitulated in 36% of the replication attempts (Rahal and Open Science Collaboration, 2015). This theme of non-replication was also brought to light by Dr. Lee Ellis from MD Anderson who wrote a similar article in 2012 on cancer biology titled “Raise standards for preclinical cancer research” reporting that only 10% of published preclinical studies could be validated to enter clinical trials (Begley and Ellis, 2012). Clinical data is a particularly sensitive instrument in the sense that it is prone to perturbations and noise introduced by a variety of sources ranging from investigator bias or errors related to experimental design and statistical analysis of the collected data. To that end, digital medicine provides robust statistical tools that subject the current research processes to intensive scrutiny, and allow for earlier interventions into the data-collection process. In addition, next generation digital health technologies, particularly distributed ledgers can offer a solution (in the form of audit trails and data quality control through smart contracts) needed to address reproducibility problems and the peer-review process – given sufficient funding and regulatory support. However, this cannot be accomplished by replicating the current research processes and just transforming them from paper to digital form. Rather, a complete re-thinking and re-engineering of the peer-review process with a focus on reproducibility using blockchain protocols is needed (Goodman et al., 2016). Here, I present a digital medicine use-case where machine learning powers a clinical application, and discuss how a new type of blockchain-based peer-review system that can help reduce the burden of reproducibility.

In a recent study, TomaĹĄev et al. (2019) reported the use of a machine learning approach called recurrent neural networks to identify impending acute kidney injury, 1 or 2 days in advance of the diagnosis made using the standard of care clinical tests. The authors applied this methodology to data collected from more than 700,000 adults treated in hospitals and outpatient clinics run by the United States Department of Veterans Affairs and published their results. However, the codebase used to develop the trained recurrent neural network was not made open-source due to use of proprietary libraries and licensing. Instead, the authors provided extensive data from testing their machine learning model against training data in the supplementary information (TomaĹĄev et al., 2019). This data provided insights into the framework behind the neural network, the training phases, results from supervised learning, prediction capabilities in the final model, and the kind of test data used for training (TomaĹĄev et al., 2019). Ultimately, the data was used as a surrogate for sharing the code behind the network, and the quality control of validation was on the shoulders of the authors.

Increased use of machine learning models for clinical decision support has brought about a paradigm shift in handling the immense amounts of data generated by quantitative and qualitative measurements of physiological parameters. The two areas in evidence-based medicine that may benefit heavily from the application of machine learning techniques are diagnosis and outcome prediction (Kononenko, 2001; Darcy et al., 2016; Beam and Kohane, 2018; Zhang, 2019). A common end-point for machine learning algorithms in diagnostic medicine is to build a classifier: a predictive function that can map variables from an input stream onto discrete output categories. Classifiers can aid a highly skilled worker in the decision-making processes, for instance triaging a data-set containing new actionable observations (Kononenko, 2001; Beam and Kohane, 2018). However, the development and validation (peer-review) of machine learning classifiers for clinical applications require a few special considerations in order to help increase the chances of eventually having patient contact and improving patient outcomes (Darcy et al., 2016; Beam and Kohane, 2018; Zhang, 2019). The opportunities for monetization of classifiers built on top of private libraries are off-set by the cost of “black-boxing” parameters that are hidden and therefore not replicated and verified rigorously. We need to approach this problem in the context of burden of reproducibility – a standardized mechanism for peer-review of digital medicine apps and proprietary machine learning tools is needed. More precisely, one that involves authors of the study, provides a public interface for testing the tools in a secure environment with new data, and reports the final recommendations back to a public forum.

A constant pressure to publish high-impact work, selective reporting of results, poor use of statistics [including p-hacking (Head et al., 2015)], and unsophisticated protocols can all contribute to reducing overall replication potential of an experiment. Researchers can also be hampered by the technical difficulties involved in replicating a complex experiment that requires multiple difficult lab techniques, poorly described methods and incompletely reported setbacks from data (Head et al., 2015). Funding agencies and publishers are stepping in to reduce these problems. Funding agencies such as the National Science Foundation (NSF) and the National Institutes of Health (NIH) have changed grant requirements and have awarded grants to design classes aimed at improving statistical literacy (Stodden et al., 2014). Journals are designing policies that help address inadequate documentation and supporting technologies that facilitate data-sharing (Stodden et al., 2014). In addition, many high-impact journals are raising the data-standards by requesting authors to deposit more experimental data, and making it publicly available. Presently, the use of commercial machine learning applications is nascent in clinical medicine, private libraries can accelerate research and development by providing monetization opportunities. Any code built upon private libraries is not submitted to open-source repositories due to licensing dependencies, and this leads to a built-in assumption: if the authors of a given study provide sufficient indirect data and insight into the black-box model, the results from the study will be reproducible. There is a conscious effort from the entire scientific enterprise to increase data transparency, but the burden of reproducibility weighs heavily on the authors of a study. The broader question remains: Can we create a standardized peer-review approach where the authors of a study (in digital medicine) get involved in demonstrating the generalizability of their models?

Reproducibility crisis has become well recognized by researchers in many fields of science (Chalmers et al., 2014; Chan et al., 2014; Glasziou et al., 2014; Ioannidis et al., 2014; Macleod et al., 2014; Salman et al., 2014; Begley and Ioannidis, 2015). For our discussion, we define reproducibility of a study as the property of obtaining the same results from conducting an independent study of a published experiment, as long as the methods are closely matched to the original study (Chan et al., 2014; Glasziou et al., 2014; Ioannidis et al., 2014; Macleod et al., 2014). The burden of reproducibility increases with new computational tools as commercial development essentially limits how much of the internal operations can be divulged in an open-source format (Macleod et al., 2014). In the era of digital medicine, the usual barriers of peer-review and statistical analysis are not enough – this holds true especially for machine learning-type classifiers where the end-product is built on private libraries (Blockeel et al., 2013; Lemley, 2019; Lu, 2019; Stupple et al., 2019). The blockchain provides a unique approach to this problem by serving as an immutable recording device whereby a sandboxed container can interface with a new classifier, apply new testing data to verify this classifier, and publish the results along with the methods to a shared data layer (Stupple et al., 2019). A group of established validators can reference these published results, quantify them into numerical reputation points, and make their final recommendations available to a publicly accessible data layer. The reputation points can stratify reliability within the network (Stupple et al., 2019). Of note, the technical components necessary for this new form of peer-review have already been deployed in practice among different blockchain implementations. For instance – Quorum and the Golem Network are two distributed ledger protocols that have the operational infrastructure to support payload privacy and sandboxed off-chain computations, respectively. In this article, the salient features necessary for a blockchain based peer-review are reviewed from three protocols: a reputation system, off-chain computations, and private transaction states. The operational principles and design considerations behind these implementations are reviewed in order to highlight how peer-review can be a pertinent use-case. The article is organized as follows: I begin with an introduction to reputation systems by discussing Augur, a prediction-markets powered reputation system built on the Ethereum blockchain. This is followed by a review of sandboxing and support for off-chain computations available in the Golem Network. Finally, the article ends with a brief overview of the dual public/private transaction states in Quorum, with a focus on how the dual states can be applied to a peer-review of private classifiers. The goal throughout this article is to highlight how existing components can be repurposed for peer-review and scientific validation of digital health applications.

Augur Network: Reputation Tokens

To understand how reputation parameters embed and propagate through a blockchain network, let us begin with a brief overview of Augur. A decentralized predictions system requires four fundamental components: a platform for participating members to submit predictions for an outcome, a mechanism to reward points for accurate predictions, a consensus framework to consolidate reward points into a longer-standing parameter such as reputation, and a group of validators that maintain the integrity of the network. Augur is an ERC-20 token built on top of the Ethereum blockchain as a platform for prediction markets (Peterson et al., 2015). Augur is powered by a token called Reputation (REP), which is used by members for event reporting. By owning REP, and participating in the accurate reporting on the outcomes of events, token holding members of the network receive a portion of the settlement fees from the platform. The incentive structure is such that accurate reporting of outcomes has the highest return on investment for REP token holders (Peterson et al., 2015). The more REP a reporter owns, and reports correctly with, the more fees they will earn for their work in maintaining the integrity of the platform (Peterson et al., 2015). There is no monetary value associated with REP, these tokens only propagate reputation across the network, and act as a multiplier for return on network rewards. The market outcome settled by a majority of the reporters is validated against the canonical outcome from the external world, a consensus is reached and REP tokens are rewarded for accurate predictions (Peterson et al., 2015). Augur has an oracle that can migrate information on external events to a blockchain without having to rely on a trusted intermediary. The validators can use this oracle to adjudicate any reputation conflicts that arise on the network (Peterson et al., 2015). Over time, a record of continuous change in REP of token holders and internal validation lead to a market of reliable set of users with a high reputation and long-standing history of accurate predictions network-wide (Peterson et al., 2015). In this setting, reputation becomes the backbone of long-term reliability and users with high REP can be attached to editorial and reviewer positions.

Golem Network: Decentralized Computation Farm

Golem is a peer-to-peer network that connects providers with computing power to requestors who submit computationally heavy tasks for processing. The network functions as a Platform-as-a-Service and provides computational resources in a decentralized fashion in return for payment in tokens. Golem has three main players: the suppliers of computational resources (providers), requestors who submit tasks to be computed by the network, and finally software developers who add new features to the network (Wood, 2014; The Golem Project, 2016).

In Golem, one of the most crucial components of the decentralized ecosystem is the Application Registry. It provides developers with tools to deploy software running on the Ethereum blockchain, and toolkits to monetize use cases (Wood, 2014). The main functions of the registry include giving developers a platform to publish applications, give requestors a directory to search and request specific tools for their tasks, and to give providers a mechanism to control the code they execute for security concerns. Golem allows requesters to execute the code of an application on a host computer, but this code is sandboxed and executed with the minimal required privileges (Wood, 2014; The Golem Project, 2016). The process of off-chain computing involves running an application on a host machine linked to the blockchain, once the computational task is finished, the host machine submits the results to the blockchain along with the processing time. In order to protect the host from executing malicious code, the application runs in a sandboxed environment within a container designed to limit any external access. At present, the only application configured for off-chain computation with sandboxing is decentralized animation rendering developed by Golem, but more microservices are planned (Wood, 2014; The Golem Project, 2016).

Due to the halting problem, it remains technically infeasible to evaluate a segment of code and heuristically determine whether any malicious components are present. To that end, the Application Registry has three classes of access control: authors, validators, and providers. Authors publish applications to the registry, validators review and certify applications as trustworthy by adding them to a whitelist (The Golem Project, 2016). Now these applications are considered sanctioned, and available to a provider for execution. Providers requisition the hardware to execute a requestor’s task and are given the right to choose the applications they want to run, based on the validators they select (The Golem Project, 2016). A provider can take advantage of this mechanism, managing her own whitelist/blacklists, or simply using whitelists of validators she trusts. Payments between requesters and providers are facilitated by a transaction framework in Golem (The Golem Project, 2016). This framework along with the Application Registry make it possible to seamlessly request hardware from a computational farm, submit a task, and obtain the final results. In the future, scientific applications on Application Registry would have the potential to operate on a device-agnostic computational farm, and report on the final outcome of computations along with the methods (The Golem Project, 2016). This can be bound under a smart contract, so that no operator intervention is required from the start of computation till the end with the results submitted (The Golem Project, 2016).

Quorum: Dual Transaction States

Quorum has native support for transaction privacy, this manifests in the form of transaction states with public and private payloads on the network. Broadly speaking, the lifecycle of a private transaction on Quorum involves two components: a Quorum node and Tessera (Chase, 2016). A review of the Quorum node is provided elsewhere (Chase, 2016), the remainder of this section will focus on the design and components of Tessera, the privacy engine of Quorum. Tessera enables the encryption/decryption of payloads and propagation of private transactions on the network. It in turn has two main components: a transaction manager and an Enclave (Chase, 2016). Both are presented in the upcoming sections.

Nodes can determine if a transaction is private or public, one quick method of doing this involves looking at the header for a parameter called v-value, for instance, a higher v-value points to a private transaction (Chase, 2016). If the transaction is deemed private, a node can only process the associated payload if it has the private keys needed to decrypt and unpack the payload (Chase, 2016). Nodes who are not party to the transaction payload will simply skip the transaction, and therefore not execute the private payload. In order to support this bifurcation of transaction states, Quorum stores the public payloads in a common public state that is synchronized globally, and the private payloads are synchronized locally with the involved parties (Chase, 2016). Additionally, this model allows for granular control over modifying the state during the cross-communication between the public and private contracts. There are well-specified software locks on the state of a virtual machine to prevent sync conflicts (Chase, 2016). Here, is an example: when a private payload refers being executed makes a reference to external or public information, the virtual machine has software locks that forcibly enforce a read-only mode. In this manner, if a call derived from the public-private interaction requests a change to the internal state of virtual machine, it throws an exception. In this manner, Quorum limits the number of actors that can update the internal state, ultimately reducing friction between subsequent contracts running on the virtual machine (Chase, 2016). Next, a discussion of private payloads and the instrument used by Tessera for performing encryption and crypto-related operations is presented.

Tessera Enclave

In network security terms, an Enclave is defined as a secure computing asset that has no interactions with the remainder of the network, or any other systems. The main application of an Enclave in Quorum is to limit network access and protect information that exists inside of an Enclave from external malicious attacks (Chase, 2016). Most distributed ledger protocols rely on cryptographic techniques to maintain transaction validity, member verification, and the network state through a chain of cryptographically hashed headers. In order to achieve real-time performance enhancements for crypto-specific operations and technical isolation to create a crypto-space, much of the cryptographic work including public/private key generation and data encryption/decryption is designated to the Enclave. It holds the private keys and functions essentially as a virtual hardware security module on the Quorum network. The argument for a crypto-specific space becomes relevant in the context of memory leaks: Enclave works asynchronously with the transaction manager to help strengthen privacy by managing the encryption/decryption of operations in an isolated way (Chase, 2016). This enables sensitive operations to be handled in a single container with layers of memory protection, without any demonstrable potential for leakage into areas of execution memory that may be visible to the remainder of the network. The Enclave is designed to manage all types of key management for Quorum, as well as supporting any operations required by private payloads given that a particular node is participating in the executing the payload on a virtual machine. In the most simplistic operational model, each Enclave interacts only with the transaction manager local to that node, but there is support for more complex interactions between transaction managers from different nodes involving multiple Enclaves (Chase, 2016). Let’s briefly talk about transaction managers next.

Tessera Transaction Manager

In the lifecycle of a private transaction and payloads, the transaction manager is the central point of communication and distribution of private payloads (Chase, 2016). It interfaces with most other components of the network and manages the directional movement of private data. Transaction manager provides access to transaction data, exchanges payloads on Quorum blockchain with transaction managers of other nodes involving new participants, but does not have access to decode any sensitive data because it lacks private keys. Even though the transaction manager has database access, it utilizes the Enclave for operations involving private key cryptography. This design principle has been constituted to limit access to an attacker that may have gained access to a node or a transaction manager from reaching private keys (Chase, 2016). Additionally, two important network features of the transaction manager include forming a peer-to-peer network of transaction managers such that peer/key information can be broadcasted, and interfacing with the Enclave for cryptographic tasks even between nodes (Chase, 2016).

A network powered by Tessera that enables private payloads and dual transaction states has the potential for creating a special off-chain testing environment specifically for proprietary software acting as payloads. Only the involved parties will have access to the payload being tested, and the entire verification process can be automated by a smart contract. Once the verification begins, an isolated container can test new data, publish the results to a blockchain, and then self-destruct. This ensures no unauthorized access to payloads or any proprietary software. A panel of validators interested in proving the reproducibility and generalizability of a classifier can use the published results from an off-chain test in making final recommendations. Such a system can pave the way to development of a standardized peer-review pathway for verification of digital health applications and proprietary software leading to an overall reduction of the burden of replicability on the original developers (Chase, 2016). Figure 1 graphically summarizes this concept. A new blockchain protocol encompassing these features can lead to a new era of blockchain-enabled peer-review of scientific studies, particularly in machine learning for evidence based medicine.



FIGURE 1


[bookmark: figure1]
[image: www.frontiersin.org]
Figure 1. Use-case for blockchain as a peer-review network. The four components dictate how verification of a private payload should be carried out. The model file would have instructions for how to publish the results along with the methods used. The script will dictate how new data is provided to the classifier. The access control ";"""citation_keywords"",""Blockchain; Social good; Smart contract; Peer Review; Digital medicine""
""og:image"",""https://www.frontiersin.org/files/MyHome%20Article%20Library/513604/513604_Thumb_400.jpg""
""citation_publication_date"",""2020/03/05""
""citation_title"",""Blockchain Based Peer-Review Interfaces for Digital Medicine""
""citation_author_institution"",""College of Osteopathic Medicine, Nova Southeastern University, United States""
""Description"",""Over the last decade, strong evidence is emerging from multiple disciplines of scientific inquiry ranging from behavioral psychology to clinical medicine that many published scientific studies are not reproducible. The best-known retrospective analyses from psychology (Rahal and Open Science Collaboration, 2015) and cancer biology (Begley and Ellis, 2012) report staggeringly low replication rates of 40 and 20%, respectively. This has led to the phenomenon of a “reproducibility crisis” where a significant amount of funding, research effort and even public policy has come to depend on non-reproducible research (Goodman et al., 2016). In this perspective article, I outline how the blockchain can be used to power a decentralized peer-review system for digital health applications. This is followed by a discussion of how such a system impacts the broader issue of scientific reproducibility, and how existing blockchain protocols can help alleviate the barriers to reproducibility.""
""Keywords"",""Blockchain, Social good, Smart contract, Peer Review, Digital medicine""
""citation_publisher"",""Frontiers""
""citation_journal_title"",""Frontiers in Blockchain""
""description"",""Over the last decade, strong evidence is emerging from multiple disciplines of scientific inquiry ranging from behavioral psychology to clinical medicine that many published scientific studies are not reproducible. The best-known retrospective analyses from psychology [1] and cancer biology [2] report staggeringly low replication rates of 40% and 20%, respectively. This has led to the phenomenon of a """"reproducibility crisis"""" where a significant amount of funding, research effort and even public policy has come to depend on non-reproducible research [3]. In this perspective article, I outline how the blockchain can be used to power a decentralized peer-review system for digital health applications. This is followed by a discussion of how such a system impacts the broader issue of scientific reproducibility, and how existing blockchain protocols can help alleviate the barriers to reproducibility.""
""language"",""en""
""citation_date"",""2020""
""title"",""Frontiers | Blockchain Based Peer-Review Interfaces for Digital Medicine | Blockchain""
""citation_online_date"",""2020/02/04""
""citation_author_email"",""""
""citation_issn"",""2624-7852""
""dc:title"",""Frontiers | Blockchain Based Peer-Review Interfaces for Digital Medicine | Blockchain""
""citation_language"",""English""
""Content-Encoding"",""UTF-8""
""citation_pdf_url"",""https://www.frontiersin.org/articles/10.3389/fbloc.2020.00008/pdf""
""Content-Length"",""148614""
""Content-Type"",""text/html; charset=UTF-8""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""og:type"",""article""
""citation_journal_abbrev"",""Front. Blockchain""
""citation_abstract"",""Over the last decade, strong evidence is emerging from multiple disciplines of scientific inquiry ranging from behavioral psychology to clinical medicine that many published scientific studies are not reproducible. The best-known retrospective analyses from psychology [1] and cancer biology [2] report staggeringly low replication rates of 40% and 20%, respectively. This has led to the phenomenon of a """"reproducibility crisis"""" where a significant amount of funding, research effort and even public policy has come to depend on non-reproducible research [3]. In this perspective article, I outline how the blockchain can be used to power a decentralized peer-review system for digital health applications. This is followed by a discussion of how such a system impacts the broader issue of scientific reproducibility, and how existing blockchain protocols can help alleviate the barriers to reproducibility.""
""citation_author"",""Dhillon, Vikram""
""Title"",""Blockchain Based Peer-Review Interfaces for Digital Medicine""
""resourceName"",""full""
""citation_pages"",""8""
""url"",""https://www.frontiersin.org/article/10.3389/fbloc.2020.00008/full""
""site_name"",""Frontiers""
""X-UA-Compatible"",""IE=edge""
""frontiers:type"",""Article""
""viewport"",""width=device-width, initial-scale=1, maximum-scale=1""
""citation_doi"",""10.3389/fbloc.2020.00008""
""dc.identifier"",""doi:10.3389/fbloc.2020.00008""
""citation_volume"",""3""
""Content-Language"",""en""
";https://scholar.google.ch/scholar?start=680&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098725-19;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;[CITATION][C] Another Look at CBC Casper Consensus Protocol.;Y Wang ; IACR Cryptol. ePrint Arch., 2020;;null;Autres articles;;null;;;;https://scholar.google.ch/scholar?start=560&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619098747-70;https://scholar.google.ch/scholar?start=550&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020;[PDF][PDF] Compact Authenticated Key Exchange in the Quantum Random Oracle Model;H Xue, MH Au, R Yang, B Liang, H Jiang ; eprint.iacr.org;;"… q(pk1, pk2, Enc(pk1, pk2,m; G(m))); otherwise let h(pk1, pk2,m) = h2 q(pk1, pk2,m), where h1

q,h2 q are private oracles … distinguisher, issuing queries to quantum random oracle O1 or O2

which only differ on a set S, could distinguish them from each other, then there exists a one …";Autres articles;Version HTML;[PDF] iacr.org;https://eprint.iacr.org/2020/1282.pdf;"
Compact Authenticated Key Exchange in the
Quantum Random Oracle Model

Haiyang Xue1,2,3 ?, Man Ho Au2, Rupeng Yang2, Bei Liang4, Haodong Jiang5

1 State Key Laboratory of Information Security, Institute of Information Engineering,
Chinese Academy of Sciences, Beijing, China

haiyangxc@gmail.com
2 Department of Computer Science, The University of Hong Kong, Hong Kong

allen.au@gmail.com, orbbyrp@gmail.com
3 Data Assurance and Communications Security Research Center,

Chinese Academy of Sciences, Beijing, China
4 Chalmers University of Technology, Gothenburg, Sweden

lbei@chalmers.se
5 State Key Laboratory of Mathematical Engineering and Advanced Computing,

Zhengzhou, Henan, China
hdjiang13@gmail.com

Abstract. We propose a generic construction of two-message authenticated key
exchange (AKE) in the quantum random oracle model (QROM). It can be seen
as a QROM-secure version of X3LH-AKE [Xue et al. ASIACRYPT 2018], a
generic AKE based on double-key PKE. We prove that, with some modification,
the security of X3LH-AKE in QROM can be reduced to the one-way securi-
ty of double-key PKE. In addition to answering several open problems on the
QROM security of prior works, such as SIAKE [Xu et al. ASIACRYPT 2019],
FSXY-AKE and 2Kyber-AKE, we propose a new construction, CSIAKE, based
on commutative supersingular isogenies.
Our frame enjoys the following desirable features. First of all, it supports PKEs
with non-perfect correctness. Secondly, the security reduction is relatively tight.
In addition, the basic building block is weak and compact. Finally, the resulting
AKE achieves the security in CK+ model as strong as in X3LH-AKE, and the
transformation overhead is low.

1 Introduction

Authenticated Key exchange. Since the introduction of authenticated key exchange
(AKE), there has been a series of works, which are mainly specified in the following di-
rections, security models, provably-secure instantiations based on classical or quantum-
resistant assumptions. Among these constructions, some are explicitly authenticated
(which generally use additional primitives, i.e., signature or MAC), while some are im-
plicitly authenticated.

Recently, one of the most important and appealing directions is to construct strongly
secure AKE against quantum attacks. Although one could achieve this goal by combin-
ing quantum-secure PKE/KEM with quantum-resistant signatures [32], the resulting
explicitly authenticated schemes incur considerable overhead. An alternative approach
is to construct implicit AKE from quantum-secure PKE/KEM based on established
generic frameworks. For example, the framework of [16] yields to AKEs from IND-CCA
secure KEMs and pseudo-random functions (PRFs) in the standard model.

Recognizing the inefficiency of [16], Fujioka et al. [17] generically construct AKE
(denoted as FSXY-AKE hereafter) relying on the random oracle. Particularly, FSXY-
AKE requires an adaptively secure (OW-CCA) KEM, and a parallel execution of one

? This work was done while the author was in the Department of Computing, The Hong Kong
Polytechnic University.



OW-CCA secure KEM and one passively-secure KEM, all of which are implied by OW-
CPA secure PKE in the classical random oracle model (ROM) [16, Sec. 4]. There have
been several instantiations of FSXY-AKE. Among them, those based on Module-LWE
assumption [6] and supersingular isogeny [30] are the most attractive ones.

Another noteworthy framework is due to Xue et al. [37] (denoted as X3LH-AKE here-
after). Abstracted from many well-known ad-hoc implicit AKEs, X3LH-AKE generical-
ly devises AKE from a new primitive called adaptively secure double-key (2-key) KEM
which could be obtained from a passively secure 2-key PKE [37, Sec. 6.2]. Observing that
in FSXY the responder returns two independent ciphertexts under initiator’s static and
ephemeral public keys, Xue et al. [37] made use of a 2-key PKE to incorporate two in-
dividual encryptions to a single encryption under two public keys. They also formalized
the security requirement for the underlying 2-key PKE, namely [OW-CPA,OW-CPA].
More precisely, in the [OW-CPA, ¡] (resp. [¡,OW-CPA]) game, the adversary attempts to
invert the ciphertext of a random message which is encrypted under a pair of public
keys, where the first (resp. second) public key is generated honestly by the challenger,
while the second (resp. first) public key is chosen by adversary.

FSXY-AKE could be taken as a special case of X3LH-AKE where 2-key PKE is
the combination of two independent PKEs. The prominent advantage of X3LH-AKE
is that there are several compact constructions of 2-key PKE except for the direct
combination of two PKEs. Thus, following their framework, several compact AKEs are
given, such as 2Kyber-AKE [37] based on Module-LWE assumption and SIAKE [38]
based on supersingular isogeny. As shown in Table 1, SIAKE is more compact than that
presented in [30] by following FSXY-AKE.

The Quantum ROM. Since quantum computers could execute all the off-line primi-
tives, including hash functions, Boneh et al. [5] introduced the quantum ROM (QROM),
in which the adversary has the capability to query random oracle with arbitrary super-
positions. It is widely believed that proofs in the quantum ROM rather than classical
ROM fulfill the security requirements against quantum adversaries.

Motivation. Although X3LH-AKE (SIAKE, 2Kyber-AKE) and FSXY-AKE lead to
efficient and quantum-resistant AKEs, their security analysis are conducted in the clas-
sical ROM, leaving the studies of their securities in QROM as open problems, which
motivate us to focus on in this paper.

Hövelmanns et al. [21] proposed a modified FSXY-AKE (denoted as HKSU-AKE
hereafter) by eliminating intermediate hash and proved its QROM security. Since the 2-
key system of FSXY-AKE consists of two independent 1-key KEMs/PKEs, the challenge
falls down on the Fujisaki-Okamoto (FO, i.e., CPA PKE to CCA KEM) transformation.
Thus, several recent progresses and techniques [20,23,34,2] on QROM security of FO
could be used. Hövelmanns et al. [21] also re-examines the puncture technique in [34] by
considering decryption error and applies it to FSXY-AKE. The drawback of puncture
trick is that the underlying 1-key PKE should be IND-CPA secure (cf. OW-CPA secure
PKE is sufficient in the original FSXY-AKE).

However, HKSU’s technique can not be applied to X3LH-AKE and its compact in-
stantiations, i.e., SIAKE and 2Kyber-AKE, due to the following reasons. First, compact
instantiations of 2-key PKE, such as that used in SIAKE, provide only one-wayness
rather than IND security. Secondly, HKSU’s proof (and several others for QROM se-
curity of FO) is built indispensably on the so-called injective mapping with encryption
under fixed public key in order to decouple the decapsulation-like oracle with secret key.
However, in X3LH-AKE (specifically, when 2-key PKE is not the direct combination
of two PKEs), the adversary could query decapsulation-like oracle under many public
keys. Worse still, the adversary has the capability to choose part of the challenge public
key.

Thus, the main motivation of this work is to prove the security of X3LH-AKE (and
thus SIAKE, FSXY, and 2Kyber-AKE) in QROM and reduce their securities to a weak-

2



er (i.e., one-wayness) primitive, thus supplementing the state-of-the-art of quantum-
resistant AKEs.

1.1 Our Contributions

We prove that, with a slight modification, X3LH-AKE converts any [OW-CPA, OW-CPA]
secure 2-key PKE into a CK+ secure AKE in QROM. Our results imply that several
prior schemes, including SIAKE [38], 2Kyber-AKE [37] and FSXY [17], can be adapted
to achieve QROM security. We also propose a new AKE, namely, CSIAKE, based on
commutative supersingular isogenies [15].

To the best of our knowledge, SIAKE, CSIAKE and 2Kyber-AKE represent the most
efficient QROM-secure AKEs under their corresponding assumptions. Fig. 1 and Table
1 summarize ours and existing transformations.

– We prove that X3LH (with a slight modification) indeed transforms 2-key PKE
into an adaptively secure AKE in QROM. Our transformation is practical, not only
because it relies on a weak building block, i.e., [OW-CPA, OW-CPA] secure 2-key
PKE, which supports more compact instantiations, but also because it is as efficient
as X3LH.

– Our result answers several open problems on the securities of previous AKEs in
QROM, such as SIAKE, 2Kyber-AKE and FSXY. For FSXY, the security require-
ment of underlying PKE is the same as FSXY, i.e., OW-CPA, contrary to the results
in [21] which require IND-CPA. Furthermore, our reduction is relatively tighter than
that in HKSU [21].

– Our result also provides an alternative approach to design new post-quantum AKEs
in QROM. With such guide, CSIAKE, a new construction based on commutative
supersingular isogenies [15] is given.

– Our last contribution is the proof technique, namely, domain separation and injective
mapping with encryption under many public keys. We believe that this technique,
which is of independent interest, is useful for multi-user security of FO in QROM.

AKEs AssumptionsQROM Tool’s Security Comm. (Bytes) Computation

FSXY [17,6]

M-LWE

OW-CPA 5920

X3LH [37] [OW-CPA,OW-CPA] 5302

HKSU [21] X IND-CPA 5920

Ours X [OW-CPA,OW-CPA] 5302

FSXY [17,30]

SIDH

OW-CPA 2352 6+6 Isog.

SIAKE [38] [OW-CPA,OW-CPA] 1788 6+5 Isog.

HKSU [21] X IND-CPA 2352 6+6 Isog.

Ours X [OW-CPA,OW-CPA] 1788 6+5 Isog.

HKSU [21]
CSIDH

X IND-CPA 2688 6+6 Isog.

Ours X [OW-CPA,OW-CPA] 2028 6+5 Isog.

Table 1. Comparison of AKEs. The parameters for M-LWE and SIDH(-p751) are chosen to
have the same security as AES-256, while that for CSIDH(-5280), recommended by [11], has
the same security as AES-128. We do not count the computation under M-LWE assumption
since it is not a bottleneck. “x+ y Isog.” in the computation column means that the initiator
(resp. responder) has to perform x (resp. y) isogeny computation.

3



CK+AKE

[OW-CPA, OW-CPA]
2-key PKE

IND-CCA
KEM

CSIDH
OW-CPA
PKE

IND-CPA
PKE

SIAKE 2Kyber Kyber ¡ ¡ ¡ SIKE

This work
Sec. 3,4

[37]
X3LH [17]

FSXY13

FSXY12
[16]

HKSU20
[21]

SXY18
[34]

NoErr

trivial

JZC+18
[23]

Sec.5
Sec.5

[37] [38]

[6] [22]

Fig. 1. Illustration of existing works from probabilistic PKE and our contributions. “NoErr”
indicates the work does not consider decryption error. The dotted (resp. dashed and solid) lines
indicate works in the classical ROM (resp. QROM or standard) model. The thick solid lines
are our contributions.

1.2 Technique Overview

We first review the frame of X3LH-AKE in detail and discuss the challenges that arise
when proving its security in QROM. Then, we present our solution. We conclude with
a discussion on the applicability of our framework.

Review of X3LH-AKE and Challenges.

The core idea of X3LH-AKE from 2-key PKE6 is illustrated in the following figure. A
2-key PKE accommodates two keys in a single encryption, and its encryption algorithm
Enc takes as input the public keys pk1, pk2, plaintext m and randomness r, and outputs
ciphertext C = Enc(pk1, pk2,m; r).

Alice (pkA, skA) Bob (pkB , skB)

pk2A, CA = Enc1(pkB ,mA)

CB = Enc(pkA, pk2A,mB ; rB)

Initiator Alice, with static public key pkA, first generates an ephemeral key pk2A and
sends it to Bob. Bob returns a 2-key encryption CB to Alice. The process is somewhat
symmetric in the sense that in the first move, Alice sends to Bob a 1-key encryption

6 In [37], it is a two-step process: firstly from passively secure 2-key PKE to adaptively secure
2-key KEM, and then to X3LH-AKE.

4



under Bob’s public key, say CA = Enc1(pkB ,mA). The final session key is extracted
from KA (encapsulated in CA) and KB (encapsulated in CB) together with the session
identifier.

The [OW-CPA,OW-CPA] security of underlying 2-key PKE is defined by [OW-CPA, ¡]
and [¡,OW-CPA] games. In [OW-CPA, ¡] game, the adversary aims to recover m, where
pk1 is chosen by challenger and pk2 is chosen by adversary; while in the [¡,OW-CPA]
game, pk1 (resp. pk2) is chosen by the adversary (resp. challenger).

The AKE adversary in CK+ game could send any message he wants, and make
SessionKeyReveal query on any non-test session to obtain the corresponding session key.
For example, on receiving an ephemeral public key from the initiator, the adversary
may reply a 2-key ciphertext and query SessionKeyReveal to extract the corresponding
session key. Furthermore, in the test session, the adversary may choose the ephemeral
public key and try to guess the session key after receiving a challenge ciphertext.

To fill up the gap between CK+ secure AKE and [OW-CPA,OW-CPA] secure 2-key
PKE, two issues should be resolved in both classical ROM and QROM. First of all, how
to answer the SessionKeyReveal queries without the first secret key. Secondly, how to
decouple the challenge session key K∗ from the challenge ciphertext C∗ and claim its
randomness. To simplify the analysis, in the following we just consider the authentication
of the initiator.

Classical ROM. With the help of hash list, two issues above could be solved by setting
rB = G(mB) and KB = h(pk2A,mB). For any SessionKeyReveal query on a session in
which pk1 is the owner’s static key, pk′2 is the ephemeral public key and C ′ is chosen by
adversary, the simulator returns a session key by setting the encapsulated key either as
h′ = h(pk′2,m

′) or a random value, depending on whether there exists some (pk′2,m
′, h′)

in the hash list such that Enc(pk1, pk
′
2,m

′, G(m′)) = C ′. Secondly, if the plaintext m∗

of C∗ is in the hash list, we could solve the [OW-CPA, ·] problem; otherwise, we could
claim the randomness of K∗. This is how the original X3LH [37] does.

Quantum ROM. Although searching hash list operates very well in classical ROM, it
is not easy to employ this trick in QROM. For FO transform (i.e., 1-key PKE to KEM),
two techniques have been proposed to address similar problems. At first, encryption is
embedded into the random oracle in order to render the Decapsulation oracle simulatable
without knowledge of the secret key. Secondly, the challenge key is decoupled from the
challenge ciphertext by a query extraction argument (One Way-to-Hiding lemma).

If we limit 2-key PKE as a parallel execution of two independent PKEs, these two
techniques in FO could be directly applied, as HKSU [21] does. However, several compact
2-key PKEs in SIAKE [38], 2Kyber [37] and CSIAKE in Sec.5 do not satisfy the premise.
On the other hand, if we restrict AKE adversaries’s capability (e.g., both the static
and ephemeral public keys in the test session are honestly generated and fixed, and
SessionKeyReveal can only be queried on this fixed public key.), these techniques may
also be applicable. However, a realistic adversary not only might query SessionKeyReveal
on many public keys, but also might choose one of the challenge public keys (i.e., the
ephemeral public key in test session).

Thus, the compact structure of 2-key PKE brings in new challenges. We propose our
techniques step by step to achieve above two main targets.

Preparation for answering the SessionKeyReveal query without secret key. In
FO transform that turns 1-key PKE (KeyGen,Enc1,Dec1) into CCA KEM, randomness
used in Enc1 is replaced by G(m) and the encapsulated key is set as h(m). Introduced in
[5] and utilized by many recent works [23,34,2,7,21,28], injective mapping with encryp-
tion is a useful technique to answer decapsalution oracle without the knowledge of secret
key. As illustrated in Fig. 2, if Enc1(pk, ¡;G(¡)) is an injective mapping (with the assump-
tion of perfect correctness), h(m) could be modeled as hq◦Enc1(pk,m;G(m)) where hq is
a private oracle. Then, the decapsulation oracle could be simulated by using hq without
the help of secret key, since we have h(Dec1(sk, C)) = hq ◦ Enc1 ◦ Dec1(sk, C) = hq(C).

5



For KEM Fixed pk

m ∈M C

h(m)

h

Enc1(pk,m;G(m))

hq

For AKE pk1 ∈ D1

pk1, pk2,m pk2 ∈ D2 pk1, pk2, C

m ∈M

h(pk1, pk2,m)

h

If pk1 ∈ L1 ∧ pk2 ∈ L2

Enc(pk1, pk2,m;G(m))

h1
q

I(pk1, pk2,m)

If pk1 6∈ L1 ∨ pk2 6∈ L2

h2
q

Fig. 2. The injective mapping by Enc1 under fixed public key and the injective mapping by Enc
under many public keys. pk is a fixed public key. L1 (resp. L2) is the list of honestly generated
first public keys (resp. second public keys). I is the identical map.

Note that in the above analysis, public key should be fixed. However, in the scenario
of X3LH-AKE, the adversary could query SessionKeyReveal on many public keys. To
apply the injective mapping with encryption, public keys should be embedded in h to
specify under which public keys Enc is applied, i.e., K = h(pk1, pk2,m). However, the
adversary could query quantum random oracle h with any pk1 and pk2 it wants, which
means Enc(pk1, pk2,m;G(m)) may not be injective, i.e., several messages may map to
one ciphertext. One may come up with an idea of checking the validity of public key,
however, the validity of public key is itself a much bigger challenge [27] (e.g., lattice and
supersingular isogeny).

Our observation is that the SessionKeyReveal query applies to many but bounded
public keys, i.e., those honestly generated static public keys and ephemeral public keys.
Thus, although maintaining hash lists is not an easy task in QROM, the list of bounded
public keys could be prepared at the very beginning. Concretely, let N be the number
of users and l the number of sessions between two users. Let L1 := {(pk1,i, sk1,i)1≤i≤N}
be the list of honest static public-secret keys, and L2 := {(pkj2,i, sk

j
2,i)1≤i≤N,1≤j≤Nl}

be the list prepared for the ephemeral public-secret keys, where pkj2,i is used by Ui as
ephemeral public key in its j-th session.

With L1 and L2, the domain of h, i.e., D1×D2×M could be separated as L1×L2×M
and its complement. With such a domain separation, our technique, i.e., injective map-
ping with encryption under many public keys, is illustrated in Fig. 2. h(pk1, pk2,m)
is defined according to the domain separation. Concretely, if pk1 ∈ L1 ∧ pk2 ∈ L2,
h(pk1, pk2,m) = h1

q(pk1, pk2,Enc(pk1, pk2,m;G(m))); otherwise let h(pk1, pk2,m) =
h2
q(pk1, pk2,m), where h1

q, h
2
q are private oracles. Such defined function h(pk1, pk2,

m) is still an injective mapping when there is no decryption error. With this replace-
ment, we could answer SessionKeyReveal query on (pk1 ∈ L1, pk2 ∈ L2, C, ¡ ¡ ¡ ) by using
h1
q(pk1, pk2, C) as the key encapsulated in C, i.e., without the knowledge of secret key.

Decoupling Session Key with Challenge Ciphertext. The One Way to Hiding
(OW2H) lemma [36] and its variants play essential roles to decouple encapsulated key
from challenge ciphertext in FO. Informally, OW2H lemma states that: if a quantum

6



distinguisher, issuing queries to quantum random oracle O1 or O2 which only differ on a
set S, could distinguish them from each other, then there exists a one-wayness attacker
to find some element in S. When applying OW2H, the way of how to use the OW2H
relates to the security requirement of underlying primitive, and the choice of S is effected
by the capability and aim of the adversary.

The Method of Applying OW2H. So far, there are two effective methods of applying
OW2H, one is the puncture technique [34,21], and another is the unified oracle trick [23],
which yield different security requirements of underlying primitives. With puncture tech-
nique that removes 0 from the message space, once applying OW2H to G on m∗, chal-
lenge ciphertext C∗ can be replaced with an encryption of 0, if the underlying PKE
is IND-CPA secure, thereby decoupling C∗ with K∗. Whereas, unified oracle trick is to
take G, h as an unified oracle G× h, and apply OW2H lemma to G× h on m∗. Finding
out any element in S would render to solving the OW-CPA problem; otherwise, K∗ has
been decoupled from C∗.

Several instantiations of 2-key PKE in X3LH (such as those of SIAKE and CSIAKE
in Sec. 5) only provide one-wayness, thus, we use the unified oracle trick and take G,
h as G× h. To this end, we replace G(mB) with G(pk2A,mB) in the protocol. Looking
ahead, after the guess of the static public key in test session, say pk∗1 , any query (pk2,m)
to G could be handled as a query with (pk∗1 , pk2,m).

The Choice of S. For the 1-key encryption and fixed pk, S could be a set consisting of
a single point, i.e., the challenge message. However, in X3LH-AKE, one of the challenge
public key, i.e., ephemeral public key pk∗2 in test session is chosen by the adversary. S
should be carefully chosen to make sure that, on the one hand, it is large enough such
that pk∗2 is covered, but on the other hand, it is not too large such that the answer for
SessionKeyReveal will not be affected.

Let L2after ⊂ L2 be the list of ephemeral public keys that are prepared for those
sessions after the test one. S = {pk∗1} × D2 \ L2after × {m∗B}, where m∗B is the challenge
message, exactly is the set satisfying all requirements. 1) If ephemeral public key has high
entropy, with overwhelming probability it holds that pk∗2 ∈ D2\L2after, which satisfies the
first requirement. 2) Since m∗B is randomly chosen by simulator, any SessionKeyReveal
query before the test session meets m∗B with negligible probability. Furthermore, by the
definition of L2after, any ephemeral public key in SessionKeyReveal query after test session
will be in L2after.Thus, the second requirement is satisfied.

Putting them together and the applicability of our framework. According to
above analysis, the X3LH is modified by embedding both static and ephemeral public
keys into h and embedding ephemeral public key into G. The cost of adding public keys
into the hash function is negligible, while the gain is QROM security. To explain the
practicality of this framework, we give several intuitions on the constructions of 2-key
PKE. To illustrate the idea, we use the classical ElGamal encryption as an example.
Let g be a common parameter and (g1, h1), (g2, h2) be the public keys of two ElGamal
PKEs. A 2-key PKE of message m := m1||m2 can be generated under these two keys
using randomness r1, r2 in following three approaches.

Types Intuition Schemes
Type 1 [gr1 , hr11 ⊕m1, h

r1
2 ⊕m2] SIAKE [38],CSIAKE Sec. 5

Type 2 [gr11 , g
r2
2 , h

r1
1 h

r2
2 ⊕m] 2Kyber [37]

Type 3 [gr11 , h
r1
1 ⊕m1]||[gr22 , h

r2
2 ⊕m2] FSXY [17]

Additional information about these instantiations, SIAKE, CSIAKE, 2Kyber and
FSXY, are given in Sec. 5. We stress that the IND-like security of Type 1 scheme,
i.e., (C)SIAKE, can not be reduced to standard assumption. Compared with [21], our
transformation offers better concrete efficiency in two aspects. Firstly, the size of a 2-
key PKE ciphertext is usually smaller than double sizes of a standard PKE ciphertext.

7



Secondly, in our transformation only one-wayness is required while theirs needs IND-CPA
security.

1.3 Related Works and Open Problem

1-key PKE-to-KEM. Several works [20,23,24,34,2,7,40,28] have re-examined the FO
transform in QROM. They utilized the injective mapping or additional hash to avoid
recording queries and also proposed different variants of OW2H lemma. Please refer to
Appendix A for more details. Zhandry [40] showed a possibility for lazy-sampling and
recording queries. As he commented, his proof might be looser than those using OW2H.

Hashing with public key. The technique of hashing with public key has been used to
analyze the multi-user security of Schnorr signature [3]. Recently, several submissions for
the NIST Post-Quantum Cryptography Standardization, including Kyber [6], have also
employed such technique. The Kyber proposed heuristic analysis from the perspective
of multi-target attacks utilizing decryption failure. The necessity of putting public key
into hashing is still heavily debated [10]. Our analysis in this work shows that hashing
with public key seems necessary to prove the multi-user security of FO in QROM.

HKSU in QROM. Hövelmanns et al. [21] proposed a modular framework FOAKE, i.e.,
HKSU, from IND-CPA secure 1-key PKE in QROM. We note that when applying to
FSXY, our framework in this paper needs one more re-encryption than HKSU. We take
it as a compromise in order to include more compact instantiations. Firstly, there exist
more compact constructions of 2-key PKE except for two parallel executions of 1-key
PKEs. For example, based on (commutative) supersingular isogeny, the initiator and
responder in HKSU need 6 and 6 isogeny computation respectively, while those in ours
need 6 and 5. (A same computation comparison of SIAKE and FSXY has been given
in [38].) Secondly, our framework relies on the one-wayness, which is weaker than indis-
tinguishability that is relied by HKSU [21]. Furthermore, our technique has relatively
tighter reduction for the factors N and l, where N is the number of users, l is the number
of sessions between two users. In [21], they represent the number of sessions that the
adversary established, which is bounded by N2l, as an entirety “S” in their notation.
For decryption error, ours is N and theirs is N4l2; for the underlying scheme, ours is
N2l and theirs is N4l2; and for the entropy of public keys, ours is N2l while theirs is
N6l3.

Open Problem. However, in both [21] and our work, the reductions are not tight in a
strict sense, since the reduction loss depends on N , l, q (the number of possible queries
to random oracles), and a square root. Thus, one open problem is: does there exist
tighter reductions for compact AKEs in QROM?

The reduction loss related to N and l already exists in classical ROM. Two excep-
tions are [8][19]. However, their models are weak, and constructions rely on stronger
tools which introduce high overhead. Cohn-Gordon et al. [12] only eliminates l in their
reduction. In QROM, Jiang et al. [25] found out that the square-root advantage loss in
the OW2H is unavoidable, if the one-wayness attacker runs the distinguisher only once
and involves no rewinding. Although, recently, double-sided OW2H lemma [7] and a new
rewinding technique [28] have been proposed to reduce q and the square-root advantage
loss, the reduction algorithm needs to know both O1 and O2, which can not be satisfied
when the underlying probabilistic scheme is one-way secure.

2 Preliminary

In this section, we recall the definition of double-key PKE and the CK+ security model.
At last, preliminary knowledge of quantum random oracle model is given.

8



2.1 Double-Key PKE and Security

We revisit the definition of 2-key PKE [37]. A 2-key PKE 2PKE=(KGen1, KGen2, Enc,
Dec) is a quadruple of PPT algorithms together with two public key space Dpk1 , Dpk2 ,
a plaintext space M, a randomness space R and a ciphertext space C. We want to
highlight that the set membership problem of Dpk1 and Dpk2 is generally hard. Let D1

(resp. D2) be some extension of Dpk1 (resp. Dpk2) such that the set membership problem
of D1 (resp. D2)is easy.

– KGen1: on input security parameter, output public-secret key (pk1, sk1).

– KGen2: on input security parameter, output public-secret key (pk2, sk2).

– Enc(pk1, pk2,m; r) : on input public keys pk1, pk2, plaintextm ∈M, and randomness
r ∈ R, output the ciphertext C ∈ C. Sometimes, we eliminate the randomness r and
denote it as Enc(pk1, pk2,m) for simplicity.

– Dec(sk1, sk2, C) : on input secret keys sk1, sk2 and cipheretext C ∈ C, output a
plaintext m.

Correctness and Decryption failure. The decryption failure is defined as δ2 :=
E (maxm∈M Pr [Dec(sk1, sk2,Enc(pk1, pk2,m; r)) 6= m]), where the probability is taken
over the randomness used in Enc and the expectation is taken over (pk1, sk1)← KGen1
and (pk2, sk2)← KGen2.

Entropy of second public key. For any pk′2 ∈ D2, Pr[pk2 = pk′2|(pk2, sk2) ←
KGen2] ≤ εpk2.
One-way Security. We recall the definition of [OW-CPA,OW-CPA] security of 2-key
PKE in [37]. To define [OW-CPA,OW-CPA] security for 2PKE, two adversaries, i.e.,
A = (A1,A2) attacking pk1 and B = (B1,B2) attacking pk2, are taken into account.
The [OW-CPA, ¡] and [¡,OW-CPA] security games are shown in Fig. 3 from left to right
respectively7.

Game [OW-CPA, ¡]

1 : (pk1, sk1)← KGen1

2 : (state; pk∗2)← A1(pk1)

3 : m←M, c∗ ← Enc(pk1, pk
∗
2 ,m)

4 : m′ ← A2(state, c∗)

5 : return m′
?
= m

Game [¡,OW-CPA]

1 : (pk2, sk2)← KGen2

2 : (state; pk∗1)← B1(pk2)

3 : m←M, c∗ ← Enc(pk∗1 , pk2,m)

4 : m′ ← B2(state, c∗)

5 : return m′
?
= m

Fig. 3. The one-way security games for 2-key PKE.

The advantage of A winning in the game [OW-CPA, ¡] is

Adv
[OW-CPA,¡]
2PKE (A) = Pr

[
[OW-CPA, ·]A ⇒ 1

]
.

We say that 2PKE is [OW-CPA, ¡] secure, if for any PPT adversary A, the advantage

Adv
[OW-CPA,¡]
2PKE (A) is negligible. The advantage Adv

[¡,OW-CPA]
2PKE (B) and [¡,OW-CPA] security

can be defined in the same manner. If 2PKE is [OW-CPA, ¡] and [¡,OW-CPA] secure, we
call it is [OW-CPA,OW-CPA] secure.

7 In the original definition [37, Sec. 6.2], a list of honestly generated public-secret keys is given
to adversary. When the public key has high entropy, the definition with this list is equivalent
to that without the list.

9



1-key PKE Let PKE = (KeyGen1, Enc1,Dec1) be a 1-key PKE with randomness space
R1, message spaceM1 and ciphertext space C1. It can be taken as a special 2-key PKE
where KGen2 does nothing (such as (−,−)← KGen2), KGen1, Enc, and Dec do as what
KeyGen1,Enc1, and Dec1 do. The decryption failure for the underlying 1-key PKE is the
same as that for this 2-key PKE. The OW-CPA advantage AdvOW-CPA

PKE of PKE is exactly

the [OW-CPA, ¡] advantage Adv[OW-CPA,¡] for the specified 2-key PKE.

2.2 CK+ Security Model

Here, we recall the CK+ model introduced by [16,17], which is a modified CK model
[13] integrated with the weak PFS security, resistant to KCI and MEX attacks. Please
refer to Appendix B for a brief discussion on security models.

Ui denotes a party indexed by i, who is modeled as probabilistic polynomial time
(PPT) interactive Turing machines. We assume that each party Ui owns a static pair of
secret-public keys (sski, spki), where spki is linked to Ui’s identity such that the other
parties can verify the authentic binding between them. We do not require the well-
formedness of static public key, in particular, a corrupted party can adaptively register
any static public key of its choice.
Session. Each party can be activated to run an instance called a session. A party can be
activated to initiate the session by an incoming message of the form (Π, I, UA, UB) or
respond to an incoming message of the form (Π,R, UB , UA, XA), where Π is a pro-
tocol identifier, I and R are role identifiers corresponding to initiator and respon-
der. Activated with (Π, I, UA, UB), UA is called the session initiator. Activated with
(Π,R, UB , UA, XA), UB is called the session responder.

According to the specification of AKE, the party creates session specified randomness
which is generally called ephemeral secret key, computes and maintains a session state,
generates outgoing messages, and completes the session by outputting a session key and
erasing the session state. Here we require that the session state at least contains the
ephemeral secret key.

A session may also be aborted without generating a session key. The initiator UA
creates a session state and outputs XA, then may receive an incoming message of the
forms (Π, I, UA, UB , XA, XB) from the responder UB , then may compute the session key
SK. On the contrary, the responder UB outputs XB , and may compute the session key
SK. We state that a session is completed if its owner computes the session key.

A session is associated with its owner, a peer, and a session identifier. If UA is the ini-
tiator, the session identifier is sid = (Π, I, UA, UB , XA) or sid = (Π, I, UA, UB , XA, XB),
which denotes UA as an owner and UB as a peer. If UB is the responder, the session is
identified by sid = (Π,R, UB , UA, XA, XB), which denotes UB as an owner and UA as
a peer. The matching session of (Π, I, UA, UB , XA, XB) is (Π,R, UB , UA, XA, XB) and
vice versa.
Adversary. Adversary A is modeled as following to capture real attacks, including the
control of communication and access to some secret information.

– Send(message): A sends messages in one of the following forms: (Π, I, UA, UB),
(Π,R, UB , UA, XA), or (Π, I, UA, UB , XA, XB), and obtains the response.

– SessionKeyReveal(sid): if the session sid is completed, A obtains the session key SK
for sid.

– SessionStateReveal(sid): A obtains the session state of the owner of";"""date"",""2020-12-13T05:59:20Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2020-12-13T05:59:20Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is MiKTeX-pdfTeX 2.9.4307 (1.40.12)""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2020-12-13T05:59:20Z""
""created"",""2020-12-13T05:59:20Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-12-13T05:59:20Z""
""resourceName"",""1282.pdf""
""Author"",""""
""producer"",""pdfTeX-1.40.12""
""pdf:docinfo:producer"",""pdfTeX-1.40.12""
""pdf:unmappedUnicodeCharsPerPage"",""2"",""0"",""6"",""0"",""12"",""2"",""0"",""0"",""9"",""0"",""3"",""21"",""40"",""3"",""14"",""7"",""11"",""10"",""10"",""30"",""11"",""7"",""19"",""0"",""0"",""14"",""16"",""28"",""48""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2020-12-13T05:59:20Z""
""Last-Modified"",""2020-12-13T05:59:20Z""
""dcterms:modified"",""2020-12-13T05:59:20Z""
""title"",""""
""Last-Save-Date"",""2020-12-13T05:59:20Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2020-12-13T05:59:20Z""
""meta:save-date"",""2020-12-13T05:59:20Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is MiKTeX-pdfTeX 2.9.4307 (1.40.12)""
""Content-Length"",""757360""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""29""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""2631"",""3501"",""2224"",""1310"",""3545"",""2335"",""3271"",""3062"",""2120"",""3224"",""2371"",""2497"",""1365"",""3390"",""1953"",""2742"",""2302"",""2970"",""2333"",""2711"",""2691"",""2388"",""2558"",""2627"",""3670"",""2626"",""3079"",""2337"",""2076""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-12-13T05:59:20Z""
";https://scholar.google.ch/scholar?start=610&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2020&as_yhi=2020
1619099107-415;https://scholar.google.ch/scholar?as_ylo=2021&q=oracles+blockchain&hl=fr&as_sdt=0,5;Implementing decentralized auctions using blockchain smart contracts;IA Omar, HR Hasan, R Jayaraman, K Salah… ; … Forecasting and Social …, 2021  Elsevier;;"… Previous article in issue; Next article in issue. Keywords. Auctions. Blockchain. Ethereum smart

contracts. Decentralized storage system. Trusted oracles. 1. Introduction. Over the past decade,

online auctions have redefined consumer choices for purchasing …";Les 2 versions;;null;;;;
1619099111-419;https://scholar.google.ch/scholar?as_ylo=2021&q=oracles+blockchain&hl=fr&as_sdt=0,5;Blockchain out of the Box–Where is the Blockchain in Blockchain-as-a-Service?;A Kernahan, U Bernskov, R Beck ; Proceedings of the 54th Hawaii …, 2021  128.171.57.22;;"… 1. Introduction Blockchain became known as the underlying tech- nology behind the

cryptocurrency Bitcoin [26] … Some of the larger blockchain providers, such as Alibaba, Amazon,

Huawei, Oracle and Samsung use their platforms to provide predefined or generic …";Cité 2 fois;;[PDF] 128.171.57.22;http://128.171.57.22/bitstream/10125/71137/0421.pdf;"
Blockchain out of the Box –  

Where is the Blockchain in Blockchain-as-a-Service?  
 

 
Alan Kernahan 

IT University of Copenhagen 

apaa@itu.dk 

Ulrik Bernskov 

IT University of Copenhagen 

ulrb@itu.dk 

Roman Beck 

IT University of Copenhagen 

beck@itu.dk 

 

 

Abstract 
 

Blockchain-as-a-Service (BaaS) is increasingly dis-

cussed as a way for companies to get started with 

blockchain projects. Different BaaS offerings are 
available, but a systematic categorization of what 

BaaS comprises is missing. In this research, we ana-

lyze the service offerings of BaaS providers based on 

available online information and identify a number of 

common characteristics in the BaaS offerings related 

to the use of service types, distributed ledger technolo-

gy (DLT) systems, consensus mechanisms, and pricing 

models. These characteristics are then further analyzed 

in the light of available literature on BaaS, as well as 

conducted expert interviews. The objective of this re-

search is to provide an overview of the BaaS land-

scap,e as well as a taxonomy that provides guidance 

for researchers and practitioners alike interested in 

BaaS. 

 

 

1. Introduction  

 
Blockchain became known as the underlying tech-

nology behind the cryptocurrency Bitcoin [26]. Nowa-

days, distributed ledger technologies (DLT) are regard-

ed as high-potential platform solutions that may disrupt 

traditional business models by reengineering supply 

networks and enforcing business logics and system-

wide data integrity [6]. Initially designed to support a 

decentralized infrastructure that overcomes the need 

for central market agents, the disruptive nature of DLT 
systems swiftly garnered attention from a growing 

business community interested in applying blockchain 

technology in a range of applications and industries 

[43]. The originally permissionless, decentralized tech-

nology has been modified to support permissioned and 

distributed blockchain systems more suitable for com-

mercial applications. These blockchain systems are 

intended to help enterprises to develop digital business 

models in networks, while keeping governance and 

thus control in a distributed, but not necessarily decen-

tralized manner [4, 9, 26]. As a result, IT service pro-

viders are now offering Blockchain-as-a-Service 

(BaaS) upon which clients can develop and use block-

chain applications [24]. According to Singh & Michels 

[36], BaaS entails a service provider supplying and 

managing aspects of a DLT infrastructure to facilitate 

and bring efficiencies regarding the development, ex-

perimentation, deployment, and the ongoing manage-

ment of DLT applications. However, it remains unclear 

how a technology that mainly gains its reliability from 

decentralization can be provided by a (central) IT ser-

vice provider. 

Blockchain-as-a-Service is marketed as a way to 

make DLT systems more accessible for enterprises 

with less overhead for adoption and at reduced costs 
[36]. With the rise of BaaS and its promises, there is 

also a rise in voices fearing that BaaS providers are 

using blockchain to leverage selling digital transfor-

mation projects while creating a new dependency and 

centralization on the side of the BaaS provider [32]. In 

this research, we analyze the service offerings of BaaS 

providers and develop a taxonomy. More specifically, 

this paper will answer the following research question: 

What is Blockchain-as-a-Service, what does the cur-

rent landscape of BaaS-providers look like and how 

can an overview help practitioners and researchers to 

navigate this new and emerging field of BaaS? 

The remainder of the paper is structured as follows. 

In section two we will provide some literature back-

ground focusing on blockchain providers and BaaS 

topics related to the subject at hand. The third section 

introduces the methodological approach that we fol-
lowed for collecting and analyzing data necessary to 

build a BaaS taxonomy, which will be elaborated on in 

section four. The fifth section presents a discussion of 

our main findings, while the paper concludes with a 

summary, critical discourse of our research, and future 

research directions in section six. 

 

 

Proceedings of the 54th Hawaii International Conference on System Sciences | 2021

Page 4281
URI: https://hdl.handle.net/10125/71137
978-0-9981331-4-0
(CC BY-NC-ND 4.0)



2. Related research  

 
Blockchain can be understood as a technology that 

allows for engineering markets [29]. Notheisen, 
Hawlitschek, & Weinhardt [29] propose a blockchain 

market engineering framework that can be applied on a 

DLT or based upon community or application. The 

purpose of their framework is to provide a tool that 

allows for analyzing and subsequently designing the 

elements required for a functioning blockchain-based 

market. They distinguish between an environment lay-

er, an infrastructure layer, an application layer, and an 

agent layer to “support the identification of applica-

tions and areas, in which blockchain-based economic 

systems offer effective and efficient solutions” [29, p. 

1072]. 

The environment layer, or macro layer, of the mar-

ket framework, comprises legal, social, and economic 

constraints, based on the applications, legal require-

ments, and the objects being transacted on the block-

chain. The infrastructure layer covers both the setup of 
the protocol layer, which handles the blockchain IT-

infrastructure, as well as the underlying hardware layer 

supporting the blockchain. More specifically, the pro-

tocol layer comprises the setup of the distributed ledg-

er, the choice of consensus mechanism, as well as the 

cryptographic protocol, which enables the implementa-

tion of decentralized applications and economic tokens 

[29]. The provided blockchain market engineering 

framework provides a useful starting point to investi-

gate the services and features provided by BaaS ven-

dors.  

While the technical stack of BaaS solutions sup-

porting blockchain markets is one key area of interest, 

another is the organization and design of the governing 

body controlling BaaS solutions, as well as based upon 

markets, communities, and applications. More specifi-

cally, the distribution of decision rights, accountabili-

ties, and incentives are of interest in distributed or even 
polycentric DLT systems [39].  

Decision rights determine to what extent decision-

making power is centralized (e.g., in a small group or a 

single entity) or decentralized (e.g., dispersed over 

many entities or people). This is typically determined 

by possession or ownership rights, but in DLT systems 

ownership can be hard to determine [7]. However, in a 

BaaS environment, ownership is clearly defined on the 

infrastructure layer, as well as on the application layer.  

Accountability is enacted “specified and brought 

into force, through contracts and legal frameworks 

governed by institutions” [7, p. 1023], and enforce-

ment mechanisms are essential. While the enactment of 

governance in most DLT-systems is on-chain, where 

accountability can rest with several entities in a dis-

tributed or even decentralized system, in BaaS, ac-

countability is organized in a similar way as an out-

sourcing or cloud usage contract. 

Incentives motivate entities in a system to act in a 

desired, predetermined way. Typically, a differentia-

tion is made between pecuniary incentives, which re-

late observable agent behavior to monetary rewards 

and non-pecuniary incentives, which relate observable 

agent behavior to nonmonetary rewards, such as privi-
leges, visibility, or reputation. In the case of BaaS, the 

incentives are defined by service contracts.  

Finally, one of the most visible forms of enacted 

governance in DLT systems is forking, which can cre-

ate different DLT species, adaptations, or variations 

[3]. Here again, the question emerges if, and how fork-

ing is possible in BaaS environments. 

 

3. Research methodology  

 
3.1. Developing a taxonomy, a bricolage of dif-

ferent approaches 

  
As the area of BaaS and related service offerings is 

still at an early stage, we adopt a bottom-up approach, 

where categories emerge from inductive empirical ob-
servations. A useful taxonomy comprises a classifica-

tion of the entities analyzed, e.g., by relating them to 

each other and placing them in a wider, meaningful 

context and provides an insightful description of the 

entities (something that in biological classification 

work is called ‘diagnosis’), its main characteristics, 

how these are employed, and where.  

Methodological approaches to the development of 

taxonomies are sparse within information systems re-

search. However, we took guidance from Nickerson, 

Varshney and Muntermann [28], who present a gener-

alized method to the development of taxonomies and 

how to apply them in information systems research. 

They state that “the development of a taxonomy in-

volves determining the characteristics of the objects of 

interest. The choice of the characteristics in a taxono-

my is a central problem in taxonomy development” 
[28, p, 343]. In order to avoid choosing characteristics 

in a naĂŻve way, one has to define meta-characteristics 

in the beginning stages of a taxonomy development 

process, so that these may serve as a basis of the identi-

fication of the more general characteristics in the tax-

onomy.  

While these meta-characteristics ideally should be 

developed at the start of the development process of 

the taxonomy, Nickerson et al. found “that the meta-

characteristic sometimes does not become clear until 

part way through the taxonomy development process” 

[28, p, 343]. Thus, to mitigate the risk of choosing me-

ta-characteristics prematurely, we followed the guid-

Page 4282



ance from research on blockchain layers and market 

engineering, as well as governance structures to get 

started with our taxonomy, while still allowing for em-

pirical observations to influence the sense-making of 

them. Doing so is also in line with the chosen analysis 

approach inspired by Gerber, Baskerville, and Van der 

Merwe [16], where we continuously questioned the 

validity of the overall meta-characteristics, as the num-
ber and nature of our empirical observations increased. 

Nickerson et al. [28] postulate that because the devel-

opment of meta-characteristics is an iterative method, 

one must determine ending conditions for when this 

iterative method should cease. The next step of the 

analysis entails making a conscious choice between 

proceeding with either an “empirical-to-conceptual 

approach” or a “conceptual-to-empirical approach”, 

including the subsequent steps pertaining to that ap-

proach. We applied a hybrid-form of these two ap-

proaches in the development of our taxonomy, as it 

became clear that the model illustrating this method of 

taxonomy development would not be useful as a 

framework for our approach. However, certain aspects 

should be taken into consideration, i.e. the meta-

characteristics and some of the ending conditions de-

scribed above. 
Apart from inspirations from Gerber et al. [16] tax-

onomy of classification approaches (ToCA) and as-

pects of Nickerson et al. [28] method of taxonomy de-

velopment, we also took guidance from prior taxono-

mies on blockchain to build upon their work. More 

specifically, we were inspired by Labazova, Dehling 

and Sunyaev’s [23] taxonomy of blockchain applica-

tions, both in the incorporation, as well as in the defin-

ing of, our meta-characteristics (e.g. Consensus Mech-

anism). 

Thus, our research methodology is a bricolage of 

these methods [16, 28, 41], which is an approach that 

we regard as suitable, as it allows the combining of 

different instruments and methods in a new and emerg-

ing research field, where established best practices are 

not yet clearly defined. 

 
3.2. Data collection 

  
Because of the new and emergent nature of the 

field of BaaS, we decided to collect our empirical data 

following an online desk research approach, where we 

applied modulated searches on the Internet, following 

the recommendations provided by Bryman [10]. For 

our research on different search engines such as 

google.com and bing.com we used different keywords 

and Boolean combinations of them, e.g., “Blockchain-

as-a-Service”, “BaaS”, “service”, “service providers”, 

“blockchain services”, “DLT systems”, “DLT ser-

vices”, “blockchain cloud”, among others. After sever-

al search iterations and focus on BaaS providers and 

not on articles or blogs just discussing BaaS, we initial-

ly identified 26 BaaS providers. However, since most 

articles and blogs did not provide enough technical 

details on the BaaS solutions which we considered 

mandatory (e.g., service types, pricing models), we 

eventually settled on 15 BaaS providers in total, which 

we then analyzed further.  
In addition to our online search, we conducted two 

semi-structured interviews with the heads of block-

chain from two major consulting companies to obtain a 

greater depth of information regarding the topic at 

hand [22], and to make sure that we identified the rele-

vant BaaS providers. These interviewees were selected 

by availability and willingness to participate in our 

research, but also due to the fact that consultancies are 

exposed to many different industries, and thus have a 

more general overview of how BaaS is emerging 

across industries. The interviews also helped us in the 

formation of the meta-characteristics for our taxonomy, 

as we were able to integrate insights from the two ex-

perts regarding characteristics and strategies behind the 

different BaaS solutions into our research. From the 

interviews, we were able to identify that trust enabled 

blockchain market platform features and interoperabil-
ity as important characteristics. The interviews lasted 

about 30 minutes each and were recorded and tran-

scribed.  

 

3.3. Data analysis 

 
Due to the new and emerging nature of BaaS, no 

industry acknowledged terminology has been suffi-

ciently established yet, which is illustrated by the wide 

variety of diverging terms to explain the same con-
cepts. For example, the terms “platform”, “protocol” 

and “blockchain core” are often used interchangeably 

to describe the underlying DLT system (e.g., Ethereum 

or Hyperledger Fabric) on which the BaaS providers 

run their service, while others use the term “platform” 

to describe the software, which interacts with the un-

derlying DLT system.  

The lack of a commonly used vocabulary or de-

fined terms has been one of the motivations to develop 

a taxonomy that provides guidance and structure. Thus, 

in the first iteration of the analysis approach, we de-

fined general meta-characteristics, such as “platform” 

(at this point, we used the term platform, referring to 

the specific DLT system used), “consensus mecha-

nism”, “pricing model”, “performance”, “scalability” 

and “interoperability”. 

Additionally, we also pre-defined some categories 
based on our literature research, such as “Blockchain-

as-a-Service”, “Platform-as-a-Service” and “Infrastruc-

ture-as-a-Service”. However, over the course of several 

Page 4283



iteration cycles preluded by discussions within the re-

search group, we concluded that the categorization 

division of infrastructure-, platform-, or application-as-

a-service did not serve well to illustrate the BaaS land-

scape, as most vendors actually offered a combination 

of these, if not all three. Consequently, we converted 

these three distinct service offerings into sub-

characteristics to effectively classify the different ser-
vice types. 

Another issue in the data analysis has been the dif-

ferent levels and granularity of information provided 

by the BaaS providers. We defined a minimum re-

quirement of technical details for a provider to be in-

cluded in our overview. For example, for some provid-

ers, it was unclear from their websites or white papers, 

which service types they were offering, and as such, 

they were excluded from the analysis. However, when 

it came to the meta-characteristic of pricing models, we 

did not choose to be as stringent, and included provid-

ers who did not disclose their specific pricing model in 

our analysis. This was because even though pricing 

models are an important and interesting differentiator, 

it is not deemed as essential for the overview as the 

technical details. Another requirement was that the 

technical information needed also was available in a 
language we could understand. For example, some of 

the Chinese BaaS providers only had technical details 

available in Mandarin, which presented a challenge. 

However, even after a translation through online trans-

lation services, the translated information did not make 

enough coherent sense to be included in the taxonomy, 

whereas other translations did. Furthermore, we origi-

nally also analyzed blockchain services from consul-

tancies. However, since we were not able to find any 

tangible information on their BaaS offerings, these 

were excluded from our taxonomy as well.  

We decided to end the recurrent iterations of the 

taxonomy, based on the chosen objective ending condi-

tions of 1) having classified at least one object under 

every characteristic of every dimension, 2) that no di-

mensions or characteristics were split or merged in the 
last iteration and 3) that we had not added any new 

dimensions in the last iteration [28]. 

 

4. Taxonomy of BaaS services  

 
In this chapter, we will present the results of our 

taxonomy of BaaS service types, divided into infra-

structure layer services, protocol layer services, and 

application layer services. Subsequently, we will com-

pare the different consensus mechanisms supported by 

the different BaaS service providers before we will 

provide BaaS pricing model characteristics. While the 

concept of BaaS generally involves some sort of plat-

form from where customers will be able to make use of 

the underlying blockchain protocol, there are variations 

as to how the providers manage the infrastructure of 

the service, and which types of applications are offered 

on their platforms. 

 

4.1. Infrastructure layer service characteristics 

 
One of the infrastructure possibilities, which we 

found common for many of the providers, includes the 

offer of running the blockchain platform on hardware 

Table 1. A taxonomy of Blockchain-as-a-Service characteristics. 

Page 4284



provided by the vendor. This setup normally includes 

hosting the blockchain in a cloud solution offered by 

the provider. One more often finds such a setup offered 

by larger IT service providers, since they already have 

the cloud infrastructure in place. 

The other infrastructure possibility, which we 

found in a few of the services, is to host the BaaS on a 

third-party infrastructure. One example of this is Ka-
leido [21], who offer their customers to set up their 

platform on either Amazon or Microsoft Azure cloud. 

A few providers, such as IBM and Samsung [19, 34], 

also offer the possibility to choose between either host-

ing the blockchain in their own cloud or in a third-

party cloud. 

 

4.2. Protocol layer service characteristics 

 
Blockchains and DLTs in general are distributed 

data management systems stored on different servers or 

nodes. Generally, all full nodes in the network will 

receive a replication of all the transactions in the net-

work for storage. In permissioned BaaS systems, as-

signed validator nodes have the responsibility of ap-

pending and validating new blocks [14]. However, 

when analyzing the different BaaS solutions, we found 

that many providers offer not just one, but several DLT 

systems with different consensus properties. 

The most commonly offered DLT system is Hy-

perledger Fabric, and providers such as Huawei, Ora-

cle, and IBM are offering BaaS focusing solely on the 

use of Hyperledger Fabric as the underlying platform 

protocol [19, 31]. Hyperledger Fabric is a modular 

blockchain platform, which enables the possibility of 

using the platform in a variety of different use cases 

and industries, and it is governed by IBM and the 
Linux foundation [4]. Furthermore, Hyperledger Fabric 

operates in a permissioned public environment, which 

means that new members interested in joining the net-

work must be selected and approved in advance. Thus, 

access is restricted to approved network participants 

only. This makes it especially useful for enterprise 

blockchain solutions, as our BaaS expert interviews 

also confirmed. 

The other frequently supported DLT protocol is a 

permissioned version of Ethereum. The original ver-

sion of Ethereum is a permissionless public protocol 

that focuses on providing a platform, where anyone can 

“write smart contracts and decentralized applications, 

where they can create their own arbitrary rules for 

ownership, transaction formats and state transition 

functions” [11]. As such, the aim of Ethereum is to 

provide a generic platform for different kinds of appli-
cations and transactions. Several of the blockchain 

providers we identified are using a permissioned ver-

sion of Ethereum, called Quorum, which offers to pro-

vide data privacy to transactions and smart contracts in 

DLT networks [26]. BaaS providers focusing solely on 

the use of permissioned versions of Ethereum, include 

Microsoft Azure and Kaleido [21, 25]. 

Hyperledger Fabric and Ethereum are not the only 

DLT protocols offered for BaaS. Another protocol that 

we identified that is being offered is R3’s Corda [9], 

which is a permissioned public DLT protocol focusing 
on applications mainly in the financial services indus-

try. Some providers also offer CoinSciences’ Multi-

Chain [17], which is a fork of the Bitcoin protocol that 

aims to provide permissioned blockchains, which can 

be used by organizations for financial transactions. 

Others offer their own proprietary protocols, while also 

aiming to meet greater privacy, throughput, and re-

sponse times for customers within different areas of 

application [33, 34, 38]. The only identified providers 

offering permissionless public services are Stratis and 

Chainstack [13, 37], in addition to permissioned ver-

sions of the different protocols.  

Six of our 15 BaaS service providers offer more 

than one DLT protocol, while five support either 

Ethereum or Hyperledger Fabric, and four either 

Bitcoin, Corda R3, or something else altogether. 

Alibaba and Samsung offer the choice between one or 
two different DLT protocols, mainly Hyperledger Fab-

ric or a permissioned version of Ethereum, while Baidu 

claims to offer three different DLT protocols [1, 33, 

34]. 

A BaaS vendor that we identified as particularly in-

teresting in relation to offering support to a wide varie-

ty of DLT protocols is Chainstack. They claim to offer 

Corda R3, Quorum, MultiChain, Ethereum and the 

Bitcoin protocol. At the same time, they also offer the 

opportunity to create and maintain blockchain net-

works in Google Cloud, Amazon Cloud, Azure Cloud, 

Alibaba Cloud, and others [13]. Therefore, they are the 

only provider offering an infrastructure independent 

BaaS offering that supports more than one DLT proto-

col.  

 

4.3. Application layer service characteristics 

 
One of the main differences that we found in the 

blockchain services offered is that there is a lot of vari-

ation in the setup of the application layer. Specifically, 

the different applications that are offered and what they 

can do for the customer. Some of the larger blockchain 

providers, such as Alibaba, Amazon, Huawei, Oracle 

and Samsung use their platforms to provide predefined 

or generic applications that are ready to be used by 

their customers. Some of the offered applications in-
clude operations management, smart contract man-

agement and node management, related to managing 

the blockchain network [1, 2, 18, 34]. However, some 

Page 4285



providers also claim to offer pre-made applications 

such as supply chain tracking, digital identity authenti-

cation and cash flow tracing, amongst other services 

that can be integrated in the cloud [18, 31]. 

One commonality we identified amongst several 

service providers is that many of the platforms offer a 

variety of different applications with tools to ease the 

use of developing own applications or networks on the 
platform. This is especially the case within the IBM 

Blockchain Platform and Microsoft Azure Workbench 

[19, 25]. Other providers such as Block.one and Stratis 

provide similar application development tools, but in-

stead use their own, or the Bitcoin protocol, to run their 

platforms [8, 37]. 

Many of the larger providers, such as SAP, Aliba-

ba, Oracle, Amazon and others seem to specifically 

focus on the capability of providing the infrastructure, 

platform and applications needed in their service, as 

full-stack services. Thus, by providing a combined 

front-end and back-end solution, they offer BaaS as a 

standardized solution in extension to their existing 

cloud services on their platform [1, 2, 31, 35].  

 

4.4. BaaS consensus mechanism characteristics 

 
Since Hyperledger Fabric and permissioned ver-

sions of Ethereum are the most commonly offered 

BaaS protocols, the consensus algorithms commonly 

used for those platforms were also the ones most fre-

quently identified in our taxonomy. However, even 

though we identified every BaaS provider, except one, 

to use some form of Byzantine Fault Tolerance (BFT) 

or Crash Fault Tolerance (CFT) consensus mechanism, 

we identified that the vendors offered the use of several 

different variations of BFT and CFT [12].  
Hyperledger Fabric is a modular blockchain proto-

col, which is also the case when choosing a consensus 

mechanism. We identified that currently the most used 

consensus mechanisms for BaaS offered by Hy-

perledger Fabric are Kafka [20] and Raft [30], which 

are Crash Fault Tolerant (CFT) ordering services. In 

the CFT setup, a leader node is appointed and is as-

sumed to act honestly. Since all the other nodes will 

replicate the leader node’s entries, it is necessary to 

trust the leader. However, since the CFT consensus or 

ordering service is only used in permissioned net-

works, it is assumed that leaders can be trusted. If the 

leader crashes, a new leader will take its place [42]. 

However, the centralized concept of the CFT algorithm 

also enables increased speed in the consensus process 

by using transaction finality. We identified Alibaba, 

Amazon, Huawei, Oracle, SAP, IBM and Samsung to 
offer Kafka CFT on Hyperledger Fabric, while only 

Baidu offers Raft. MultiChain uses a similar consensus 

algorithm to Hyperledger Fabric, however, the leader 

updating the blockchain is chosen in a round-robin or 

polled fashion, depending on their historical contribu-

tions to the blockchain [17]. The MultiChain version of 

BFT is offered by SAP [35]. 

Like Hyperledger Fabric, Quorum is compatible 

with Raft, but it is also compatible with the BFT con-

sensus variant called Istanbul BFT. Different from 

CFT algorithms, which use a leader or block proposer, 
the Istanbul BFT algorithm requires validators to per-

form multiple rounds of voting for each block. With 

this approach, the network can tolerate 1/3 faulty nodes 

[42]. Thus, Istanbul BFT can be used in instances 

where competitors or other network participants cannot 

be trusted and is used by the majority of BaaS provid-

ers offering Quorum on their platforms, such as Aliba-

ba, Microsoft Azure, Samsung, Chainstack and Kalei-

do. Other providers, such as Tencent, Stratis and 

Chainstack offer the possibility of using the Bitcoin 

protocol and maintain the network using a Proof of 

Work consensus algorithm [13, 37, 38]. 

Comparable to what we identified in relation to 

BaaS service type offerings and protocol offerings, it 

seems that most of the BaaS vendors provide the pos-

sibility to choose between different consensus algo-

rithms, depending on the characteristics of the network 
that customers are seeking. Stratis, Chainstack and 

Tencent [13, 37, 38] offer very different types of con-

sensus mechanisms at the same time (such as Proof-of-

Work and BFT), while all other vendors provide varia-

tions of BFT or CFT consensus mechanisms. Clearly, 

consensus mechanisms offered by BaaS providers fo-

cus on performance and speed in permissioned public 

networks. This is done by centralizing the consensus 

finding approach within the network. 

 

4.5. BaaS pricing models 

 
One of the common pricing models that we found 

to be offered by several blockchain providers, is that 

customers can pay based on the number of instances or 

transactions per hour. This pricing model is used by 

Amazon, Huawei, Oracle and Microsoft Azure [2, 18, 

25, 31]. Another very common pricing model is to pay 

for the storage space needed, based on the number of 

peers in the network. Amazon, SAP, IBM, Microsoft 

Azure, and Chainstack [2, 13, 19, 25, 35] offer this 

pricing model with hourly rates, whereas Alibaba of-

fers a monthly fee for the storage space used.  

We also found that Amazon, Microsoft Azure and 

Chainstack charge based on the number of peer nodes 

in a network. At the same time, IBM and SAP offers 

the possibility to charge an hourly fee based on the 
CPU usage or workload of the servers, which indicates 

how frequently the blockchain networks are used. Fi-

Page 4286



nally, we also found that IBM’s pricing model includes 

a fee for IP allocation [19, 35]. 

One of the tendencies that we found in relation to 

the identified pricing models offered by BaaS provid-

ers is that almost every one of the providers offer sev-

eral different pricing model possibilities. It was mainly 

the larger enterprise BaaS providers that had readily 

available pricing models, and most of their pricing 
models are focused on the costs related to maintaining 

the infrastructure of the blockchain network in the 

cloud. As such, the identified pricing models currently 

offered for BaaS solutions are like pricing models that 

exist for other cloud services that these vendors offer. 

 

5. Discussion  

 
Based on the results of our BaaS taxonomy and re-

lated literature, we discussed our findings with two 

senior blockchain consultants from two different large 

consulting companies to find out more about the status 

of the BaaS market, the relevance of the provided 
business services, as well as critically discuss govern-

ance and decentralization aspects of BaaS service of-

ferings. 

 

5.1. Enterprise BaaS market 

 
As illustrated by the BaaS providers identified in 

our taxonomy, the current market for BaaS on an en-

terprise level is dominated by large IT service provid-

ers. Amazon, Microsoft and IBM “are the three pre-
dominant BaaS providers that are mentioned when I 

ask my customers”. (Senior blockchain consultant B) 

Our analysis revealed that the BaaS market is very 

new, and that it is characterized by providers trying to 

build their BaaS offerings on their existing cloud com-

puting business models. Companies are still struggling 

to find their footing in the emerging DLT world, and 

an offering such as BaaS is something that sounds sim-

ilar to other traditional service sourcing approaches 

such as cloud computing. Companies thus believe that 

BaaS is a potential way into blockchain. In so doing, 

enterprises do not have to build and maintain their own 

blockchain infrastructure and applications [32], at least 

that is how it appears to them. Cloud-based BaaS ser-

vice offerings by large IT providers are often regarded 

as an extension of their existing business models. This 

was also echoed in the interview with our subject mat-

ter expert: 
“If you look at SAP mainly - maybe also Microsoft 

and Oracle, but SAP they especially like to come up 

with use cases that will work in extension of their exist-

ing services”. (Senior blockchain consultant A) 

Consequently, BaaS providers are tr";"""date"",""2020-12-24T01:58:20Z""
""pdf:PDFVersion"",""1.7""
""xmp:CreatorTool"",""MicrosoftÂŽ Word fĂźr Microsoft 365""
""pdf:docinfo:title"",""Author Guidelines for 8""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""pdf:docinfo:custom:source-Producer"",""MicrosoftÂŽ Word fĂźr Microsoft 365""
""language"",""en""
""dc:format"",""application/pdf; version=1.7""
""pdf:docinfo:creator_tool"",""Hummus-Recipe (https://github.com/chunyenHuang/hummusRecipe)""
""access_permission:fill_in_form"",""true""
""source-Producer"",""MicrosoftÂŽ Word fĂźr Microsoft 365""
""pdf:encrypted"",""false""
""dc:title"",""Author Guidelines for 8""
""xmp:CreateDate"",""2020-10-15T14:53:51Z""
""modified"",""2020-12-24T01:58:20Z""
""pdf:docinfo:custom:source-ModDate"",""D:20201015145351+02'00'""
""pdf:hasMarkedContent"",""true""
""xmp:ModifyDate"",""2020-10-15T14:53:51Z""
""pdf:docinfo:creator"",""HICSS_PC""
""meta:author"",""HICSS_PC""
""meta:creation-date"",""2020-10-15T12:53:51Z""
""created"",""2020-10-15T12:53:51Z""
""source-Creator"",""MicrosoftÂŽ Word fĂźr Microsoft 365""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2020-10-15T12:53:51Z""
""resourceName"",""0421.pdf""
""pdf:docinfo:custom:source-Creator"",""MicrosoftÂŽ Word fĂźr Microsoft 365""
""Author"",""HICSS_PC""
""producer"",""MuhammaraJS (https://github.com/julianhille/MuhammaraJS)""
""pdf:docinfo:producer"",""MuhammaraJS (https://github.com/julianhille/MuhammaraJS)""
""source-ModDate"",""D:20201015145351+02'00'""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""access_permission:modify_annotations"",""true""
""dc:creator"",""HICSS_PC""
""dcterms:created"",""2020-10-15T12:53:51Z""
""Last-Modified"",""2020-12-24T01:58:20Z""
""dcterms:modified"",""2020-12-24T01:58:20Z""
""title"",""Author Guidelines for 8""
""xmpMM:DocumentID"",""uuid:147C2D32-B596-4D87-94E6-F5CB2FDAE2A4""
""Last-Save-Date"",""2020-12-24T01:58:20Z""
""pdf:docinfo:modified"",""2020-12-24T01:58:20Z""
""meta:save-date"",""2020-12-24T01:58:20Z""
""Content-Length"",""470661""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""HICSS_PC""
""dc:language"",""de-DE""
""pdf:producer"",""MicrosoftÂŽ Word fĂźr Microsoft 365""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""10""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""4264"",""5285"",""5307"",""3221"",""5379"",""5390"",""5271"",""5619"",""5015"",""4681""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2020-10-15T12:53:51Z""
";https://scholar.google.ch/scholar?start=10&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2021
1619099111-421;https://scholar.google.ch/scholar?as_ylo=2021&q=oracles+blockchain&hl=fr&as_sdt=0,5;Experimental performance evaluation on avoidance of blockchain oracle problem using collective intelligence;Y Kato, A Fujihara ;" IEICE Technical Report; IEICE Tech. Rep., 2021  ieice.org";;"(in English) Bitcoin-type blockchains have a problem called oracle problem, where 
blockchains themselves cannot prove the authenticity of external data, and must rely on 
single external source of information. In this study, we examine how to utilize collective …";;;null;;;;https://scholar.google.ch/scholar?start=10&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2021
1619099124-451;https://scholar.google.ch/scholar?as_ylo=2021&q=oracles+blockchain&hl=fr&as_sdt=0,5;The Role of Blockchain Technology in Aviation Industry;RW Ahmad, K Salah, R Jayaraman… ; IEEE Aerospace and …, 2021  ieeexplore.ieee.org;;"… DOI. No. 10.1109/MAES.2020.3043152 The Role of Blockchain Technology in Aviation Industry …

INTRODUCTION Remarkable benefits of blockchain and its suitability for adoption in aviation

have caused considerable excitement among stakeholders of the aviation industry …";Autres articles;;[PDF] researchgate.net;https://www.researchgate.net/profile/Raja_Jayaraman/publication/344900539_The_Role_of_Blockchain_Technology_in_Aviation_Industry/links/5f98129ea6fdccfd7b827cb2/The-Role-of-Blockchain-Technology-in-Aviation-Industry.pdf;;;https://scholar.google.ch/scholar?start=40&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2021
1619099107-411;https://scholar.google.ch/scholar?as_ylo=2021&q=oracles+blockchain&hl=fr&as_sdt=0,5;Integration of Blockchain and Remote Database Access Protocol-Based Database;MJ Sadeq, SR Kabir, M Akter, R Forhat… ; Proceedings of Fifth …, 2021  Springer;;"… Blockchain is an innovation for data and information security that is generally used for digital

cryptocurrency such as Bitcoin, but it … resreport, 451 Research, October 2017Google Scholar.

8. Egberts, A.: The oracle problem an analysis of how blockchain oracles undermine the …";Cité 1 fois;Les 2 versions;[PDF] researchgate.net;https://www.researchgate.net/profile/Md-Akhtaruzzaman-4/publication/344194318_Integration_of_Blockchain_and_Remote_Database_Access_Protocol-based_Database/links/60251b01a6fdcc37a81aa7c5/Integration-of-Blockchain-and-Remote-Database-Access-Protocol-based-Database.pdf;;;
1619099120-439;https://scholar.google.ch/scholar?as_ylo=2021&q=oracles+blockchain&hl=fr&as_sdt=0,5;HERMES: Fault-Tolerant Middleware for Blockchain Interoperability;R Belchior, A Vasconcelos, M Correia, T Hardjono ;2021 techrxiv.org;;"… A recent survey classifies blockchain interoperability studies in three categories:

Cryptocurrency-directed interoperability ap- proaches, Blockchain Engines, and Blockchain

Connectors [9]. Cryptocurrency-directed approaches are directed to enabling the transfer of digital …";Les 3 versions;Version HTML;[PDF] techrxiv.org;https://www.techrxiv.org/articles/preprint/HERMES_Fault-Tolerant_Middleware_for_Blockchain_Interoperability/14120291/files/26628587.pdf;"
1

HERMES: Fault-Tolerant Middleware for Blockchain
Interoperability

Rafael Belchior, André Vasconcelos, Miguel Correia, Thomas Hardjono

Abstract—Blockchain interoperability is reducing the risk of
investing in blockchain by avoiding vendor lock-in, leveraging inter-
operation, and providing migration capabilities. However, unlock-
ing the internet of blockchains requires enterprise interoperability
mechanisms that allow service providers to comply with different
regulations, e.g., data privacy regulations. Each blockchain can be
reached via a gateway, allowing to interconnect value, to provide
different services, and to enable self-sovereignty. To realize this
vision, we propose HERMES, a fault-tolerant middleware that
connects blockchain networks and is based on the Open Digital
Asset Protocol (ODAP). Hermes is crash fault-tolerant by allying
a new protocol, ODAP-2PC, with a log storage API that can
leverage blockchain to secure logs, providing them transparency,
auditability, availability, and non-repudiation. We introduce a use
case benefiting from HERMES, digital cross-jurisdiction promissory
notes. We show that cross-chain transactions can be achieved
securely with HERMES, given that gateways are complying with
legal frameworks.

I. INTRODUCTION

The interoperability of blockchains is key to the area [9].
Several works point out that a blockchain, or more generically
a Distribute Ledger Technology (DLT) system – we use the two
terms interchangeably –, can deliver more value when connected
to multiple business ecosystems and data providers [31], creating
an interconnected network of value, similarly to the rise of the
Internet [20], [38].

Recent efforts on the blockchain space are already enabling
the connection of heterogeneous (i.e., different) blockchains
(e.g., [4], [39], [27]), enabling the internet of blockchains, and
thus a multiple-blockchain approach for developing applications
(such as [25], [33], as surveyed by [9]). For instance, Hyper-
ledger Cactus allows defining business logic plugins that imple-
ment use cases connecting both public and private blockchains
[27], capable of complying with legal frameworks and regu-
lations. Although several dozens of solutions and architecture
proposals exist for interoperating blockchains, practical solu-
tions are scarce and limited [9]. In particular, current solutions
are often lacking standardization and provide interoperation
capabilities for limited use cases (e.g., asset transfers [13], [35],
[10]).

The notion of blockchain gateway (gateway for short) en-
visions each blockchain as an autonomous system, provid-
ing the emerging internet of blockchains survivability, cost-
effectiveness, and capabilities for accomodating different ser-
vices and networks [20]. Autonomous systems are able to
comply with different jurisdictions, and also hierarchically
aggregate information, providing routing capabilities for cross-
blockchain transactions (CB-Tx) with an arbitrary payload.
Examples of cross-blockchain transactions are asset transfers
and smart contract calls [25]. Gateways are autonomous systems

that deliver messages to other gateways, following the end-to-
end principle, where the application layer delegates message
delivery reliability, data encryption, and key management to a
gateway (transport layer) [19]. The client application handles
the delivered item (value layer), allowing for great flexibility.
In other words, gateways provide the infrastructure for appli-
cations issuing CB-Tx, by connecting to DLT systems (e.g.,
blockchains). Within the Internet Engineering Task Force (IETF)
there is currently ongoing work on an asset transfer protocol
that operates between two gateway devices, the Open Digital
Asset Protocol (ODAP) [22], [7]. ODAP is the first cross-chain
communication protocol handling multiple digital asset cross-
border transactions by leveraging asset profiles (the schema of
an asset) and the notion of gateways. The process of transferring
an asset among blockchains is equivalent to an atomic swap, that
locks an asset in a blockchain and creates its representation on
another.

We present HERMES, a middleware for blockchain interop-
erability that focuses on reliability. The main component of
Hermes is an extension of the ODAP protocol that we also
introduce in this paper. We denominate this protocol ODAP-
2PC as it is inspired in the two-phase commit protocol (2PC)
[11]. Hermes also leverages a log storage API that comes with
different storage options: local, cloud, or blockchain-based. By
modeling and developing this system, we expect to address three
research questions: RQ1 What is the reliability of a cross-chain
transaction issued by a gateway, i.e., how can one be sure that
a gateway can effectively deliver transactions? RQ2 What is the
trade-off between resiliency and performance of gateways? RQ3
How decentralized is HERMES, and how can it be accountable
for the transactions it manages? and RQ4 What to expect in
terms of security and privacy of gateway-based interoperability
solutions?

Our work focuses on the reliability of gateways, and thus on
ODAP-2PC, as crashes can pose severe threats to the correct
operation of gateways: what happens if a gateway initiates
a CB-Tx and then crashes? Systems that perform sensitive
operations such as virtual asset transfers among ledgers have
to possess a degree of resiliency and fault tolerance in the face
of possible crashes [30]. Since gateways handle information
transfer between parties, it is desirable that either all operations
are executed successfully or none is executed. Atomic commit-
ment protocols such as 2PC attempt at providing transaction
atomicity, where multiple parties consistently carry out a single
logical action, typically distributed. Other properties desirable
for the reliability of distributed transactions are consistency,
isolation and durability. These ACID properties are the basis
for transactional systems for more than twenty years [26], and
are discussed throughout this paper. A key component of ODAP-



2PC’s crash recovery guarantees that the source and target DLTs
are modified consistently, i.e., that assets taken from the source
DLT are persisted into the recipient DLT, and no double spend
can occur. To address this challenge, ODAP-2PC maintains logs
that enable either the gateways to resume partially completed
transfers, allowing for a gateway to recover in case of a crash
[11].

The contributions of this paper are three-fold: first, the
blockchain gateway concept is explained, from a theoretical and
practical perspective. Second, we present the HERMES fault-
tolerant middleware, instantiated with the ODAP protocol and
ODAP-2PC. Lastly, we provide a comprehensive discussion on
Hermes as a solution for blockchain interoperability, focusing
on consistency, performance, and decentralization. We also
briefly explore a use case for cross-jurisdiction asset transfers,
illustrating how one can leverage Hermes to achieve blockchain
interoperability compliant with legal and regulatory frameworks.

The rest of this paper is structured as follows: Section II
presents the background. After that, we introduce the gateway
concept and Hermes, in Section III. After, in Section IV, we
present ODAP, including the message and logging procedure, the
log storage API, and the distributed recovery protocol (Sections
IV-B, IV-C, and IV-D, respectively). Section V, presents a
use case that benefits from Hermes. Section VI presents our
discussion on gateways, ODAP, and ODAP-2PC in the light of
the presented research questions. The related work follows, in
Section VII. Finally, we conclude the paper in Section VIII.

II. BACKGROUND

This section presents the background on fault tolerance mod-
els and nomenclature both on logging and blockchain interop-
erability.

Fault Tolerance: A fault is an event that alters the expected
behavior of a system. Faults can imply the transition from a cor-
rect state of the system to an incorrect state, called errors. Errors
can provoke failures if the system deviates from its specification,
possibly causing loss of information or compromising business
logic. Nodes can experience failures where for various reasons
(e.g., power outage, network partitions, faulty components). We
consider four failure types: message loss, communication link
failure, site failure, and network partition. Albeit common, fail-
ures can be detected by different mechanisms, such as timeouts,
defined as the upper bound δt that a message is expected [11].

Fault Recovery: Typically, crash fault-tolerant (CFT) services
can tolerate n

2 nodes crashing, with n being the number of
nodes. As long as there is a majority of nodes with the latest
state, failures can be tolerated. The primary-backup model
defines a set of n hosts (or nodes) that, as a group, assures
service resiliency, thus improving availability. In this model, an
application client sends messages to a primary node P . The
primary nodes redirects the message updates to a set of replicas
(backups) B = {B1, ...,Bn}, when it receives a message. The
backup server k propagates the new incoming message to the
backup server k+1, k ≤ n, k ∈ R. Node P is then notified an
update when n-host resiliency is met, i.e., the message was at
least replicated in n nodes. Should such acknowledgment fail
to be retrieved by P , a message update request is re-sent. If
P crashes, then a new leader Pnew ∈ B is elected. If a backup
node receives a request from the application client, it redirects it

(a) Both nodes operational. P sends ping to B and gets ACK response.

(b) Node P crashes, leaving B awaiting for a ping.

(c) Node P recovers, re-establishing the connection to B.

Fig. 1: Self-healing mode with two nodes

to P , only accepting it when the latter sends the update request.
When an update is received, P sends the message update to its
right-hand neighbor, sending back an acknowledgment.

Another recovery mechanism is self-healing [11]. In self-
healing, when nodes crash, they are assumed to recover even-
tually. While this mode is cheaper than primary-backup, as
there are fewer nodes, less exchanged messages and lower
storage requirements, it comes at the expense of availability. In
particular, the protocol may block until nodes recover. Figure 1
depicts a simplified self healing protocol for two nodes. Node
P sends a ping to node B, that responds with an ACK. In case
of a crash, node B awaits for a ping.

Atomic Commit Protocols: An atomic commit protocol (ACP)
is a protocol that guarantees a set of operations being applied
as a single operation. An atomic transaction is indivisible and
irreducible: either all operations occur, or none does. ACPs
consider two roles: a Coordinator that manages the execution
of the protocol, and Participants that manage the resources that
must be kept consistent. ACPs assume stable storage with a
write-ahead log (a history of operations are persisted before
actions are executed). Example of ACPs are the two-phase
commit protocol, 2PC, the three-phase commit protocol, 3PC,
and non-blocking atomic commit protocols [11].

2PC achieves atomicity even in case of temporary system
failure, accounting for a wide adoption both in the academia
and in the industry. It has two phases: the voting phase and
the commit phase. In the voting phase, the coordinator pre-
pares all participants to take place in a distributed transaction
by inspecting each participant’s local status. Each participant
executes eventual local transactions required to complete the
distributed transaction. If those are successful, participants send
a YES response to the coordinator, and the protocol continues.
Else, if the NO response is sent, it means that the participant
chose to abort; this happens when there are problems at the
local partition. Next, in the commit phase, when the coordinator
obtains YES from all participants, a COMMIT message is sent
to the participants that voted YES. This message triggers the

2



execution of local transactions that implement the distributed
transaction. Otherwise, the coordinator sends an ABORT mes-
sage, triggering a rollback on each local partition.

Logging: A log L is a list of log entries {l1, l2, ..., ln} such
that entries have a total order, given by the time of its creation.
A log is considered shared when a set of nodes can read and
write from the log. On the other hand, a log is private (or
local) when only one node can read and write it. Logs are
associated to a process p running operations on a certain node.
We denote the nth step of process p as (n, p). We denote the
ith log entry, as li, and the log entry referring to process p
and step k as lp,k. Both i and k are monotonically increasing
positive integers. To manipulate the log, we define a set of log
primitives, that translate log entry requests from a process p
into log entries. The log primitives are writeLogEntry (writes
a log entry), getLogLength (obtains the number of log entries),
and getLogEntry(i) (retrieves a log entry li). A log entry request
typically comes from a single event in a given protocol.

A log storage API provides access to the primitives. Log entry
requests have the format <phase, step, operation,
nodes>, where the field operation corresponds to an arbitrary
command, and the field nodes to the parties involved in the pro-
tocol p. We define four operations types to provide context to the
protocol being executed. Operation type init- states the intention
of a node to execute a particular operation, and operation exec-
expresses that the node is executing the operation. The operation
type done- states when a node successfully executed a step of
the protocol, while ack- refers to when a node acknowledges a
message received from another. Conversely, we use the type fail-
to refer to when an agent fails to execute a specific step. The
field nodes contains a tuple with a node A issuing a command,
or a node A commanding a node B the execution of a command
c, if the form is A or A→ B (c may be ommitted), respectively.

Figure 2 illustrates the logging procedure of a process A that
has three steps and includes two nodes using a log storage API.
While typically each log has its own log (and log storage API),
we only represent one for simplicity. Note that nodes can also
have a common log. Log entry l1 = linit,1 corresponds to the
node’s first message to the log storage API, which on its turn
persists it on a log, using the writeLogEntry primitive. The
log storage API writes the message that is received. For instance,
in step 2 the log storage API executes writeLogEntry<Process
A, 1, init-node, Node>. Log entry l1 is created in step (2),
coming from the command issued at step 1. Conversely, writing
l2 = linit,2 (steps 4 and )) corresponds to the command that
the node issues towards node 2 (step 6), initAllNodes, which
causes node 2 to issue an init operation. Log entry linit,3

corresponds to the execution of init by Node 2 (step 9). At
step 12, getLogLength returns 3.

Blockchain Interoperability: A recent survey classifies
blockchain interoperability studies in three categories: Public
Connectors, Blockchain of Blockchains, and Hybrid Connec-
tors [9]. The survey uses the terms Cross-Chain Transaction
(CC-Tx) and Cross-Blockchain Transaction (CB-Tx) respectively
for the cases where the blockchains are homogeneous (same
technology) and heterogeneous (the opposite). Here we do not
distinguish the use and adopt the acronym CC-Tx to designate
such transactions. These transactions are implemented using
Cross-Chain Communication Protocols (CCCPs).

A recent survey classifies blockchain interoperability studies
in three categories: Cryptocurrency-directed interoperability ap-
proaches, Blockchain Engines, and Blockchain Connectors [9].
Cryptocurrency-directed approaches are directed to enabling the
transfer of digital assets (e.g., cryptocurrencies) across homo-
geneous and heterogeneous blockchains. The cryptocurrency-
directed approaches typically rely on protocols leveraging public
blockchains, as they assume that gateways are not trusted.
As a result, these approaches are difficult to integrate with
permissioned blockchains, that support with arbitrary assets
and smart contracts. The second category are the blockchain
engines, which enable creating application-specific blockchain
that can communicate with its other instances. These solu-
tions can benefit from implementing gateways, providing each
application-specific blockchain (e.g., applications running on
a parachain) self-sovereignty, regarding communications with
outter blockchains. The third category, blockchain connectors
include trusted relays, blockchain agnostic protocols, blockchain
of blockchains solutions, and blockchain migrators. Trusted
relays are software components, typically centralized, where
escrows route cross-blockchain transactions.

The same survey points out several attempts to design an
architecture for blockchain interoperability and bring about the
common vocabulary used in this context. A pair of homogeneous
blockchains are blockchains powered by the same environ-
ment (e.g., an EVM-based [42] blockchain pair). On the other
hand, heterogeneous blockchains are power by different environ-
ments (e.g., Ethereum and Hyperledger Fabric [6]). Cross-Chain
Transaction (CC-Tx) and Cross-Blockchain Transaction (CB-
Tx) are transactions across blockchains, where the blockchains
are homogeneous and heterogeneous, respectively. We do not
distinguish the terms and assume that CC-Tx can be across
heterogeneous systems for simplicity.

CC-Txs enable the Internet of Blockchains (IoB), a system
where blockchains can communicate, enabling the transfer of
value and data. By enabling an IoB, we can enable a Blockchain
of Blockchains (BoB), a set of systems that realize a business use
case by leveraging multiple blockchains. For this, Cross-Chain
Communication Protocols (CCCPs) are needed. CCCPs are
protocols allowing the communication of multiple blockchains.
For simplicity, we do not distinguish between CCCPs and
cross-blockchain communication protocols. While proper ad-
vances have been made enabling interoperation between public
blockchains, interoperability amongst private blockchains is still
an open problem.

III. THE ARCHITECTURE OF HERMES

In this section, we introduce the gateway concept, as well
as Hermes. A gateway is a DLT system node based on
an underlying DLT-based system and functionally capable of
performing CC-Tx, including asset transfers [20]. A primary
gateway is the DLT system node acting as a gateway in a CC-
Tx. Primary gateways may be supported by backup gateways
for fault tolerance. Primary gateways can be a source gateway
GS or a recipient gateway GR, depending on the role they play
in a CC-Tx. Source gateways initiate the gateway protocol, e.g.,
an asset transfer, data pushing/pulling. Gateways use machine-
resolvable addresses (e.g. URIs/URLs) in order to communicate

3



Fig. 2: Message exchange flow example. The log storage API writes the incoming message. Just one log shown for simplicity.

with other gateways, obtaining information such as public-key
certificates and protocol-specific messages.

For gateways to be crash fault-tolerant, they keep track of each
operation they do in a log (of operations). The log is a sequence
of log entries, each entry representing a step of the gateway
protocol. Each message has a schema, defining the parameters
and the payload employed in each message flow. The log data
comprises the log information retained by a gateway within a
protocol using gateways. A gateway protocol specifies the set of
messages and procedures between two gateways for their correct
functioning. The gateway protocol considered in this paper is
ODAP [22], [7].

A. Blockchain Interoperability with Hermes

HERMES is a gateway system that enables DLT interoperabil-
ity based on gateways. This system has four layers, allowing
for end-to-end communication. The gateway protocol layer
implements any standards that a specific gateway implemen-
tation needs to comply with (e.g., travel rule [19]). ODAP,
a gateway-based CCCP that realizes asset transfers, allows
realizing technical interoperability for asset transfers. It is built
on top of a distributed recovery protocol, providing reliability in
the presence of crashes. On top of the gateway protocol stands a
concrete implementation of a gateway. Jointly with the gateway
protocol, it provides support for semantic interoperability [9],
unlocking the value level. More specifically, in the value level,
the business logic is defined for clients using gateways, allowing
them to attribute value to the assets exchanged with ODAP.
The whole stack provides atomicity, consistency, isolation, and
durability of CC-Tx. Figure 3 represents HERMES’ architecture.

Our architecture is flexible and modular, as its components
are pluggable. Modularity allows building a system that can be
adapted to specific needs. In this paper, we instantiate HERMES
with the ODAP-Gateway, the ODAP CCCP, and its crash fault-
tolerant distributed recovery protocol, ODAP-2PC. The whole
stack allows a business case, gateway-to-gateway asset transfers,
providing the basis for unidirectional asset transfers, expressed
in detail in Section V. The Hermes Client allows to implement
the business logic, realizing semantic interoperability.

Fig. 3: The architecture of Hermes

B. System Model

We consider an asynchronous distributed system composed of
two types of participants: clients and gateways. Clients are in
charge of starting transactions and are connected to gateways
that are connected to blockchains. More specifically, every
gateway is a node from a DLT system authorized to act on
it (manage assets, identify participants) via, for example, smart
contracts. Gateways can communicate with other gateways and
can crash (i.e., becoming unresponsive). We assume that there
are no Byzantine or arbitrary faults. We assume blockchains are
secure, so they fail only by crashing. We consider a blockchain
secure if the data stored is immutable, transparent to all their
participants, traceable, and, generally, the consensus mechanism
cannot be subverted by malicious parties.

To recover from these crashes, gateways store in persistent
storage data about the step of their protocol. Gateways are
honest-but-curious, i.e., follow the protocol, but will attempt
to learn all possible information from legitimately. received
messages. HERMES provides the following properties:
• P1 Atomicity: Transactions either commit on all underlying

ledgers or entirely fail.
• P2 Consistency: All gateways that reach a decision on a

CC-Tx reach the same, either commit or abort. The state
of the underlying ledgers reflect that decision.

• P3 Durability: Once a transaction has been committed, it
must remain so regardless of any component crashes.

• P4 Isolation: When a transaction is issued, all the under-
lying assets are locked.

4



• P5 Auditability: Any CC-Tx executed can be inspected by
the involved parties.

• P6 Termination: If a gateway proposes a transaction, it is
eventually committed or aborted.

To satisfy these properties, HERMES leverages ODAP and
ODAP-2PC.

C. Threat Model

ODAP assumes a trusted, secure communication channel
between gateways (i.e., messages cannot be spoofed or altered
by an adversary) using TLS 1.3 or higher, i.e., the receiver of
the communication will be able to ascertain the authenticity and
validity of the communication. Each gateway has a public and
private key pair. New TLS sessions [34] are created when a
gateway crashes and then recovers. Clients connect to gateways
using a credential scheme such as OAuth2.0 [15].

The distributed recovery protocol has assumptions regarding
log management. Log entries need integrity, availability, and
confidentiality guarantees, as they are an attractive attack point
[32]. Every log entry contains a hash of its payload for guar-
anteeing integrity. If extra guarantees are needed (e.g., non-
repudiation), a log entry might be signed by the gateway creating
it (e.g., with ECDSA [23]). Availability is guaranteed using
the log storage API, which connects a gateway to dependable
storage (local, external, or DLT-based). Each underlying storage
provides different guarantees. Access control can be enforced
via the access control profile that each log can have associated
with, i.e., the profile can be resolved, indicating which client can
access the log in which condition. Access control profiles can be
implemented with access control lists for simple authorization.
The authentication of the entities accessing the logs is done at
the log storage API level (e.g., username and password authen-
tication in local storage vs. blockchain-based access control in
a DLT). We assume the log is not tampered with or lost.

While we consider both gateways to be trusted, we consider
a probabilistic, polynomial-time adversary who can corrupt any
gateway to prevent the protocol from achieving liveness. The
adversary can do this by causing a gateway crash, interrupting
an asset transfer. However, we assume that gateways do not
deviate from the protocol.

IV. OPEN DIGITAL ASSET PROTOCOL

In this section, we present the building blocks of Hermes:
ODAP, along with its messaging and logging flow, and the
distributed recovery mechanism, ODAP-2PC.

A. ODAP and Properties

The ODAP protocol is a gateway-to-gateway unidirectional
asset transfer protocol that uses gateways as the systems con-
ducting the transfer [22]. An asset transfer is represented in the
form T : G1

a,x→ G2, where a source gateway G1 transfers x
asset units from type a from a source ledger BS to a recipient
ledger BR, via a gateway G2.

The source gateway issues a transfer such that x asset units
will be unavailable at the source DLT and become available at
the target DLT. A recipient gateway is the target of an asset
transfer, i.e., follows instructions from the source gateway. Her-
mes provides as strong durability guarantees as to the underlying

durability guarantees of the chosen data store. If the datastore is
a blockchain, Hermes can be considered to achieve transaction
durability, if transactions are immutable and permanently stored
in a secure decentralized ledger.

Durability

Hermes provides the durability guarantees that the infrastruc-
ture gateways are connected to.

The transfer process is started by a client (application) that
interacts with the source gateway. The source gateway then deals
with the complexity of translating an asset transfer request to
transactions targeting both the source and target DLT systems.
The gateway also knows other gateways, either directly or via
a decentralized gateway registry. ODAP has several operating
modes, but here we solely consider the relay mode. The relay
mode realizes client-initiated gateway to gateway asset transfers.

In ODAP, a client application interacts with its local gateway
(source gateway GS) over a Type-1 API. The existence of this
API allows the client to provide instructions to GS (correspond-
ing to the source gateway) concerning the assets stored in the
source DLT and the target DLT (via the recipient gateway, GR).
It is possible that the client has complex business logic code
that triggers behavior on the gateways. Hence, ODAP allows
three flows: the transfer initiation flow, where the process is
bootstrap, and several identification procedures take place; the
lock-evidence flow, where gateways exchange proofs regarding
the status of the asset to be transferred; and the commitment
establishment flow, where the gateways commit on the asset
transfer. The schema of the messages exchanged by the ODAP
protocol is depicted in Appendix A.

Figure 4 represents ODAP. When an end-user wants to
perform an asset transfer, gateways conduct such process. In
the transfer initiation flow (Phase 1), both gateways resolve
identities, asset information (via the asset profiles) and establish
a secure channel. This verification includes verifying the asset
profile validity, the travel rule status, and the pair originator-
beneficiary of the transaction [22]. In the lock-evidence verifica-
tion flow (Phase 2), claims on the status of assets are exchanged,
and their correspondent proofs are persisted. The persistence of
asset status proof allows for non-repudiation and accountability,
proving useful in case of a dispute.

Theorem 1 (Isolation): Let there be an instance of ODAP, with
a source gateway GS and a recipient gateway GR, operating on
an asynchronous environment. Given a lock primitive LOCK that
prevents assets from being used, if there is a timeout δt (applied
to steps 2.3 and 3.3 of ODAP), then ODAP provides transaction
isolation.
Proof : In this context, transaction isolation implies that a certain
asset is locked. At various points of the protocol, both GS and
GR are waiting for messages before proceeding. In particular, in
steps 2.3 and 2.4, where the logging procedure depends on the
asset lock’s success. A trigger δt, defining an interval before an
asset is used to assure that an asset is securely locked, even in
probabilistic-based consensus blockchains. After δt counterparty
GR can produce a log entry with the asset locking proof. When
LOCK is called, assets are locked, rendering any attempt of
writing fruitless. A similar process occurs in step 3.3. Thus,

5



as assets cannot be changed up to step 3.7, ODAP guarantees
transaction isolation. ďż˝

Isolation

ODAP-2PC provides transaction isolation by pre-locking as-
sets before the commitment of an asset transfer.

Fig. 4: Simplified sequence diagram depicting ODAP. A transfer
is issued by an end-user to the gateway (G1), which then
manages on-chain resources (L1), and communicates with a
counterparty gateway (G2). The asset transfer corresponds to
the creation of L2.

Finally, at the Commitment Establishment Flow (Phase 3),
assets are escrowed. In practice, assets are locked on the source
ledger and represent those created on the target ledger. The
lock of assets prevents double-spend attacks. ODAP aims at
providing termination, a non-trivial problem when considering
distributed transactions [5]. Thus, we consider three processes
on ODAP, p1 = transfer initiation flow, p2 =lock-evidence flow,
and p3 = commitment establishment flow. Process p1 has 2
steps, p2 has 6 steps, and p3 has 6 steps. Thus, a normal end-
to-end ODAP flow would have 14 steps.

B. Message and Logging Flow

We consider the set of logging nodes N = {GS ,GR},
with log entry requests with the format <phase, step,
type-operation operation, nodes>. Within pro-
cesses, two types of operations are considered: private opera-
tions and public operations. Private operations involve only one
gateway, requiring two log entries, the intention of executing a

command and the confirmation of the execution. This serves to
handle crashes in systems with only one node. Public operations
are operations which state is known by more than one node.
Intuitively, a private operation only is only known by the node
executing it, whereas public operations involve several nodes,
and thus are perceived by more nodes than the one executing it.

The message flow generates a variable number of log entries,
depending on the situation: i) a private operation completes suc-
cessfully, generating three log entries (init-X, exec-X, done-X);
ii) a private operation fails, generating three log entries (init-X,
exec-X, fail-X); iii) a public operation completes successfully,
generating at least four log entries (init-X, exec-X, done-X, ack-
X), and iv) a public operation fails, generating four log entries
(init-X, exec-X, fail-X, ack-X). Given that a normal ODAP flow
has 14 steps, one would expect at least 42 log entries.

Fig. 5: Message flow regarding the validation operation, of
ODAP’s phase 1.

Let us consider an example where there is an asset transfer
GS

a,1→ GR. We depict a message exchange with content m
from GS to GR by GS

m→ GR. The reply from GR to GS is
represented by GR

α(m)→ GS , where α is a function that given an
operation, step, and input from a counterparty gateway, returns
the response to it. Figure 5 illustrates part of the message flow
involving the public operation p1, the ODAP’s first phase. Note
that one operation has been performed before, corresponding to
three log entries (init, exec, done), and to a GS client issuing
an asset transfer. Thus, the first log entry from p1 has index
4. In the transfer initiation flow, where GS initiates a transfer
of one asset a to GR, the first step is to resolve identities. To
fulfill step 1";"""date"",""2021-02-25T21:56:00Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""1"",""1"",""0"",""23"",""0"",""3"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.5""
""xmp:CreatorTool"",""TeX""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dcterms:created"",""2021-02-25T21:56:00Z""
""language"",""en""
""Last-Modified"",""2021-02-25T21:56:00Z""
""dcterms:modified"",""2021-02-25T21:56:00Z""
""dc:format"",""application/pdf; version=1.5""
""Last-Save-Date"",""2021-02-25T21:56:00Z""
""pdf:docinfo:creator_tool"",""TeX""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2021-02-25T21:56:00Z""
""meta:save-date"",""2021-02-25T21:56:00Z""
""pdf:encrypted"",""false""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.21 (TeX Live 2020) kpathsea version 6.3.2""
""modified"",""2021-02-25T21:56:00Z""
""Content-Length"",""551438""
""pdf:hasMarkedContent"",""false""
""Content-Type"",""application/pdf""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.21 (TeX Live 2020) kpathsea version 6.3.2""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""trapped"",""False""
""meta:creation-date"",""2021-02-25T21:56:00Z""
""created"",""2021-02-25T21:56:00Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""14""
""Creation-Date"",""2021-02-25T21:56:00Z""
""resourceName"",""26628587.pdf""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""5191"",""4980"",""5897"",""3390"",""5384"",""3426"",""4850"",""3956"",""4726"",""5234"",""5446"",""5613"",""6465"",""4169""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""producer"",""pdfTeX-1.40.21""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""pdfTeX-1.40.21""
""pdf:docinfo:created"",""2021-02-25T21:56:00Z""
";https://scholar.google.ch/scholar?start=30&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2021
1619099107-410;https://scholar.google.ch/scholar?as_ylo=2021&q=oracles+blockchain&hl=fr&as_sdt=0,5;Trust but Verify: The Oracle Paradox of Blockchain Smart ContractsTrust but Verify: The Oracle Paradoxof Smart Contracts;A Albizri, D Appelbaum ; Journal of Information Systems, 2021  meridian.allenpress.com;;"Although research shows that blockchain provides fairly immutable virtual provenance 
workflows, proof that the Blockchain accurately represents physical events lacks truly 
independent verification. This dilemma, the Oracle Paradox, challenges blockchain  …";;null;null;;;;
1619099142-492;https://scholar.google.ch/scholar?as_ylo=2021&q=oracles+blockchain&hl=fr&as_sdt=0,5;Peace engineering: The contribution of blockchain systems to the e-voting process;P Baudier, G Kondrateva, C Ammi, E Seulliet ; … Forecasting and Social …, 2021  Elsevier;;"… Peace engineering: The contribution of blockchain systems to the e-voting process …

E-voting provides benefits but also raises concerns and conflicts. • Blockchain

transparency and traceability can reduce concerns about e-voting. • …";Cité 1 fois;Les 10 versions;[HTML] nih.gov;https://www.ncbi.nlm.nih.gov/pmc/articles/PMC7554464/;;;https://scholar.google.ch/scholar?start=80&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2021
1619099124-448;https://scholar.google.ch/scholar?as_ylo=2021&q=oracles+blockchain&hl=fr&as_sdt=0,5;Blockchain for public health care in smart society;MJ Gul, B Subramanian, A Paul, J Kim ; Microprocessors and …, 2021  Elsevier;;"… In our proposed scheme, the fog layer is also responsible for holding oracle for Blockchain, data

filtering, and classification with machine learning techniques … Smart contract can be implemented

for user. Fog node, oracle, blockchain and as well as for the cloud …";Cité 2 fois;Les 2 versions;null;;;;https://scholar.google.ch/scholar?start=40&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2021
1619099129-466;https://scholar.google.ch/scholar?as_ylo=2021&q=oracles+blockchain&hl=fr&as_sdt=0,5;Scalable and redactable blockchain with update and anonymity;K Huang, X Zhang, Y Mu, F Rezaeibagha, X Du ; Information Sciences, 2021  Elsevier;;"… Reversecoin is the first crypto-currency to support transaction revocation. It allows the user to

reverse a transaction in a configurable timeout by applying off-line keys. Although this project

does not succeed, it provides valuable insight in designing redactable blockchain …";Cité 3 fois;Les 3 versions;null;;;;https://scholar.google.ch/scholar?start=50&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2021
1619099111-422;https://scholar.google.ch/scholar?as_ylo=2021&q=oracles+blockchain&hl=fr&as_sdt=0,5;BLOCKEYE: Hunting For DeFi Attacks on Blockchain;B Wang, H Liu, C Liu, Z Yang, Q Ren, H Zheng… ; arXiv preprint arXiv …, 2021  arxiv.org;;"… BLOCKEYE extended the SERAPH smart contract analyzer to perform symbolic reasoning on

oracles … we highlighted BLOCKEYE as an open platform to detect DeFi attacks on blockchain …

The key insights behind BLOCKEYE are symbolic oracle analysis and pattern-based …";Les 2 versions;Version HTML;[PDF] arxiv.org;https://arxiv.org/pdf/2103.02873;"
BLOCKEYE: Hunting For DeFi Attacks
on Blockchain

Bin Wang, Han Liu, Chao Liu, Zhiqiang Yang, Qian Ren, Huixuan Zheng, Hong Lei
Oxford-Hainan Blockchain Research Institute, Hainan, China

Abstract—Decentralized finance, i.e., DeFi, has become the
most popular type of application on many public blockchains
(e.g., Ethereum) in recent years. Compared to the traditional
finance, DeFi allows customers to flexibly participate in diverse
blockchain financial services (e.g., lending, borrowing, collateral-
izing, exchanging etc.) via smart contracts at a relatively low cost
of trust. However, the open nature of DeFi inevitably introduces
a large attack surface, which is a severe threat to the security
of participants’ funds. In this paper, we proposed BLOCKEYE,
a real-time attack detection system for DeFi projects on the
Ethereum blockchain. Key capabilities provided by BLOCKEYE
are twofold: (1) Potentially vulnerable DeFi projects are identified
based on an automatic security analysis process, which performs
symbolic reasoning on the data flow of important service states,
e.g., asset price, and checks whether they can be externally
manipulated. (2) Then, a transaction monitor is installed off-
chain for a vulnerable DeFi project. Transactions sent not only
to that project but other associated projects as well are collected
for further security analysis. A potential attack is flagged if
a violation is detected on a critical invariant configured in
BLOCKEYE, e.g., Benefit is achieved within a very short time and
way much bigger than the cost. We applied BLOCKEYE in several
popular DeFi projects and managed to discover potential security
attacks that are unreported before. A video of BLOCKEYE is
available at https://youtu.be/7DjsWBLdlQU.

Index Terms—DeFi, oracle analysis, attack monitoring

I. INTRODUCTION

Recent years have witnessed a rapid growth of decentral-
ized finance application, or DeFi application, on the public
blockchain ecosystem, e.g., Ethereum [1]. Unlike in tradi-
tional finance, DeFi applications leverage the transparency and
openness nature of decentralized network (i.e., blockchain) to
provide a diversity range of financial services, e.g., lending,
borrowing, collateralizing, exchanging etc., all without trust or
dependency on third-party intermediaries.

While DeFi has been gaining an increasing level of market
growth in terms of both popularity and liquidity, its openness
nature also leaves a large space to external attacks, which may
severely threaten the security of DeFi participants’ funds. To
elaborate on this point, consider a real-world attack (see Fig-
ure 1) on bZx project, which is a DeFi project for lending and
margin trading on Ethereum. In this case, the attacker lever-
aged an oracle dependency of bZx on other DeFi projects (i.e.,
Uniswap and Kyber) in manipulating cryptoasset exchange
rates, making net profit with a single atomic transaction.

Specifically, as shown in Figure 1, the attacker launched a
sequence of six internal transactions, consisting of borrowing
(e.g., transaction 1 and 5), exchanging (e.g., transaction 2, 3,
and 4), and paying back (e.g., transaction 6) cryptoassets (i.e.,

ETH and sUSD). Note, these transactions are packed into a single
external transaction in the exact order as in Figure 1, which
is then executed atomically by Ethereum. In its execution,
the attacker first borrowed 7, 500 ETH from bZx (transaction
1), then used 4, 417.86 borrowed ETH in exchange of sUSD

with other DeFi projects (i.e., Uniswap, Kyber, and Synthetix

in transactions 2–4). Because bZx relies on Uniswap and
Kyber for price feed oracles, which are instead susceptible to
large amount transactions, the attacker can therefore largely
skewed exchange rate of ETH/sUSD in bZx in favour of him or
herself. After that, he or she triggered transaction 5, borrowing
6, 799.27 ETH with all holding sUSD (i.e., 1, 099, 841.39),
followed by a last transaction 6 in paying back 7, 500 borrowed
ETH at the very beginning. The outcome of transactions 1–6
is thus a net profit of 2, 381.41 ETH (minus a small amount of
ETH for paying gas fee[1]), or $600K, for the attacker.

We point out the crux of this kind of arbitrage (i.e., making
profits by buying and selling goods at different prices) is
for the attacker successfully controlling exchange rates of
cryptoasset pairs, ETH/sUSD here in Figure 1, by exploiting
data dependencies of bZx on Uniswap and Kyber.

Attacker

Derivative Protocols 
bZx(Flash Loan Provider) 1. borrow 7500ETH

Dencentralized Exchange Protocols 
Uniswap

2. convert 540ETH to 92419.7sUSD

Dencentralized Exchange Protocols 
Kyber

3. convert 360ETH to 63584.09sUSD:
(convert 20ETH to X sUSD)*18, X ↓

StableCoins 
Synthetix4. deposit 3517.86ETH for 943837.59sUSD

5. borrow 6799.27ETH using 1099841.39sUSD

6. pay back 7500ETH

Fig. 1: Attack on the bZx project.

While many previous research works and tools have focused
on the security of smart contracts [2], [3], [4], [5], there
is relatively little study on the security of DeFi projects as
aforementioned. In general, detection of these attacks requires
a deep understanding on both the business nature of a DeFi
project as well as the market it is involved in, which are
missing in existing solutions to finding low-level bugs of smart
contracts. We summarized challenges in terms of addressing
security problems in DeFi projects as below.

Challenge 1: Model DeFi Dependency. Attacks on DeFi
often involve multiple projects rather than a single one. There-
fore, detection of such attacks requires an effective modeling
of critical dependencies among DeFi projects, e.g., information

ar
X

iv
:2

10
3.

02
87

3v
1 

 [
cs

.C
R

] 
 4

 M
ar

 2
02

1

https://youtu.be/7DjsWBLdlQU


Sy
m

bo
lic

 A
na

ly
sis

CFG Oracle Dependency

Smart 
Contracts

Tx
Monitor Attack Report

Feature 
Extraction

Tx 
Collection

Analysis 
Engine

Predefined 
Heuristics

End-to-End 
Analysis

0

1

k

…

DeFi Projects

Phase 1: Oracle Analysis Phase 2: Attack Monitoring

Vulnerable 
Defi

Fig. 2: The general workflow of BLOCKEYE.

flow between two DeFi. While a full analysis would introduce
too much complexity, an abstract analysis might not be able
to capture important high-level business semantics.

Challenge 2: Understand End-To-End Transactions. Fur-
thermore, whether a sequence of transactions is considered
as malicious is largely determined by end-to-end analysis,
i.e., comparing benefits and costs in the transaction sequence.
However, such insights are hard to configure and generate
based on existing analysis infrastructures for blockchains.

The BLOCKEYE Solution. To overcome above challenges,
we have designed and developed BLOCKEYE, the very first au-
tomatic attack detection platform for blockchain DeFi projects.
The key insights behind BLOCKEYE are twofold. First, a
symbolic analysis is performed in BLOCKEYE to reason on
important data flow (e.g., asset price) among associated DeFi
projects. Potentially vulnerable projects are identified in this
process. Then, BLOCKEYE installs a runtime monitor on
vulnerable DeFi projects to detect potential attacks on the fly.
Specifically, an end-to-end economic analysis is executed to
report malicious transactions based on given heuristics, e.g.,
a large amount of profits are made in a very short time. We
further applied BLOCKEYE in several popular DeFi projects
on Ethereum and managed to uncover potential attacks which
were previously unreported.

II. ATTACK DETECTION FOR DEFI

A. Overview

The general workflow of BLOCKEYE is shown in Figure
2. Specifically, BLOCKEYE works in a two-phase manner. In
the first phase, BLOCKEYE performs symbolic analysis on
smart contracts of a given DeFi project. This is realized by
extending an underlying smart contract analyzer SERAPH [6],
which is also developed by our team. Specifically, the goal of
this phase is to model the inter-DeFi oracle dependency, i.e.,
how does the oracle data provided by one DeFi affect services
of another. In cases where oracle-dependent state updates
are found, we identify the DeFi as potentially vulnerable.
Next, BLOCKEYE installs a runtime monitor in the second
phase for vulnerable DeFi projects to detect external attacks.
Specifically, BLOCKEYE uses a transaction monitor to collect

related transactions based on extracted features, e.g., address.
Then, end-to-end transactions are analyzed according to pre-
defined heuristics, e.g., a large profit is made in a short period.
Potential attacks are flagged by BLOCKEYE when an abnormal
sequence of transactions is detected. Moreover, BLOCKEYE
generates analysis report to help blockchain service providers
diagnose the found problems.

B. Oracle Analysis

As aforementioned, BLOCKEYE performs oracle analysis
to check whether a DeFi is dependent on the oracle provided
by another DeFi. Particularly, we focused on the price feed of
assets shared through oracles.

1 function calculateContinuousMintReturn(uint _amount)
2 public view returns (uint mintAmount) {
3 return CURVE.calculatePurchaseReturn(totalSupply(),
4 reserveBalance, uint32(reserveRatio), _amount);
5 }
6
7 function sell(uint _amount, uint _min) external
8 returns (uint _bought) {
9 _bought = _sell(_amount);

10 require(_bought >= _min, ""slippage"");
11 _burn(msg.sender, _amount);
12 DAI.transfer(msg.sender, _bought);
13 ...
14 }

Fig. 3: Oracle in the EMN project

An illustrative example of EMN project is given in Figure 3.
Specifically, the function call at line 9 implicitly invokes the
function from line 1–5, which receives an oracle at line 3–4.
Moreover, the payment at line 12 is dependent on the oracle
due to a data flow from line 9 to 12. That said, EMN has an
oracle-dependent state update in its smart contracts. To enable
such oracle analysis, BLOCKEYE extended the SERAPH smart
contract analyzer to perform symbolic reasoning on oracles.
Specifically, when processing a CALL instruction to a specified
oracle, BLOCKEYE starts a data flow analysis to track whether
the value retrieved from the oracle is linked to a further state
operation, e.g., payment, storage update etc.. In cases where a



feasible link is detected as in Figure 3, BLOCKEYE dumps the
data flow and identifies given DeFi as potentially vulnerable.

C. Automatic Attack Monitoring

For vulnerable DeFi projects, BLOCKEYE launches a run-
time transaction monitoring to detect external attacks. To this
end, BLOCKEYE allows users to specify targeted projects and
further performs end-to-end analysis on relevant transactions.
In general, the analysis aims at finding violations on invariant
as predefined heuristic rules.

Specifically, as in Figure 1 with associated DeFi projects
Uniswap, Synthetix and Kyber, BLOCKEYE first marks a
random transaction t0 in these platforms as a target. Moreover,
we search for other related transactions t1 ¡ ¡ ¡ tk based on the
sender address x in t0. Additionally, we filter transactions
which are not in the same block as t0 in order to find frequent
transactions, which are more likely to be involved in attacks.
With the collection of t0 ¡ ¡ ¡ tk transactions, BLOCKEYE runs
a process to calculate the benefits received by x and its
cost as well. With both numbers, BLOCKEYE is then able to
determine whether x is attacking the target DeFi by comparing
the profit made by x and a threshold value as configured.
BLOCKEYE will also dumps the malicious sequence of trans-
actions to facilitate an in-depth analysis of the potential attack.

III. DESIGN OF BLOCKEYE

A. Architecture

The BLOCKEYE is implemented as a web platform with
front and back-end services, where the back-end architecture
is shown in Figure 4. There are five functional modules in
this architecture. At the bottom, BLOCKEYE extends a smart
contract analyzer to perform oracle analysis as introduced
earlier. Z3 [7] is adopted as the SMT solver in this module.

Tx Monitor

Eventum Framework

Features

Z3 LibraryExtended Smart Contract Oracle Analyzer

EtherScan API
• get_transactions
• get_blocks
• get_logs

…

DeFi API
• get_price
• get_pairs

…

Twilio Library

Configuration

Block

Txs

Analysis Engine

Engine Core

Heuristics Analysis

…Time

Task Manager

Schedule Notify

Fig. 4: The general architecture of BLOCKEYE.

In the middle are Tx Monitor and Analysis Engine. Transac-
tions are monitored and collected via the Eventum framework,
which streams events from blockchain to BLOCKEYE. More-
over, we implemented the analysis engine to detect potential
attacks based on collected transactions and events. At the
top layer, BLOCKEYE provides a Configuration module to
allow users to specify detection criteria, e.g., in physical time
or block number. Furthermore, the Task Manager module is
designed to schedule detection tasks submitted from front-end
and send back notifications to users with the Twillo library.

B. Main Functionalities

We now describe the input and output interfaces of
BLOCKEYE with screenshots shown in Figure 5 and Figure 6.

Fig. 5: The input interface for BLOCKEYE.

As in Figure 5, BLOCKEYE expects DeFi smart contract
source code as input. Users can either type in code in the
code editor, or provide the address of a deployed DeFi project.
BLOCKEYE then will try to load corresponding source code
using Etherscan’s source code retrieving API. Once smart
contract code is available, users are free to click the START
button to launch security analysis on the given DeFi project.

Fig. 6: The output interface for BLOCKEYE.

An example output of BLOCKEYE is in Figure 6. Here, re-
sults are divided into two parts: Oracle Analysis, which shows
potential oracle dependencies found in DeFi source code, and
Attack Monitoring, that provides information of real-world at-
tack transactions which break heuristic invariants as described
in Section II-C. For example, in Figure 6, BLOCKEYE has
found an oracle dependency which spans across four smart
contract functions, with oracle contract defined in code line
154 and fired by function calculateContinuousBurnReturn

in line 168. Corresponding state access operation is in line 242
as a request to transfer DAI with dependent amount of value.
Besides, in Figure 6, BLOCKEYE shows a list of five latest
suspicious transactions, each with detailed information on its



internal operation. At last, BLOCKEYE also presents a graph
of top attackers along with their number of detected attack
transactions, which may help users in further investigations.

IV. PRELIMINARY EVALUATION

We conducted a preliminary evaluation on BLOCKEYE to
validate its effectiveness in finding oracle-dependent state
updates. Specifically, we considered eight DeFi projects on
Ethereum, i.e., bZx, DDEX, Aave, dYdX, Compound, Nuo,
Oasis, and Eminence.

In Table I, we present a comparison of BLOCKEYE with
Codefi Inspect [8] in oracle-dependent state update detection.
The results show that BLOCKEYE successively identifies all
vulnerable DeFis with no false positive or false negative
alert. Whereas, Codefi Inspect falsely ignores vulnerabilities
in DDEX, leading to a false negative (FN) result.

TABLE I: A comparison of BLOCKEYE and Codefi Inspect
in oracle-dependent state update detection. TP: True Positive;
TN: True Negative; FN: False Negative; N/A: Not Available.

DeFi Codefi Inspect BLOCKEYE

bZx TP TP
DDEX FN TP
Aave TN TN
dYdX TN TN

Compound TN TN
Nuo N/A TN
Oasis N/A TN

Eminence N/A TP

We further evaluated BLOCKEYE with real-world transac-
tions on the Ethereum mainnet. In Table II, we show detailed
results of detected arbitrage transactions in two DeFis, i.e.,
ETH/sUSD token pair on bZx and DAI/EMN on Eminence.

TABLE II: Detailed results of BLOCKEYE with two DeFis.

DeFi bZx(ETH/sUSD) Eminence(DAI/EMN)

Block 10799704 ∟ 10950575 10956504 ∟ 11031087
# Tx ≈ 7138 ≈ 1486

# Suspicious Tx
slippage > 0.05 25 slippage > 0.05 124
slippage > 0.07 23 slippage > 0.057 107
slippage > 0.1 19 slippage > 0.059 37

For example, as for bZx (ETH/sUSD), there were around
7, 138 valid transactions detected between block 10, 799, 704
and 10, 950, 575. By enforcing different slippage thresholds,
BLOCKEYE found 19 to 25 suspicious arbitrage transactions,
e.g., 19 for slippage threshold 0.1 and 25 for slippage threshold
0.05. Besides, for Eminence(DAI/EMN), the number of suspi-
cious transactions found ranged from 37 to 124 with different
slippage thresholds, where overall valid transactions detected
were 1, 486 between block 10, 956, 504 and 11, 031, 087.

V. RELATED WORK

Security problems of smart contracts have been widely
discussed in recent years [4], [5], [3], [2], [6]. Luu et al.
highlighted four types of vulnerabilities for smart contracts [2].
Tsankov et al. proposed a verification technique [3], which
transforms Ethereum smart contracts into Datalog logics [9].

Permenev et al. further presented their solution to verify smart
contracts in an inductive manner [10]. In addition to security
problems, Liu et al. proposed a statistical approach to identify
potential code smells [5]. Security of DeFi projects is relatively
less discussed in previous works. Several mathematical and
economic models were proposed to help understand risks of
DeFi in a theoretical manner [11], [12], [13], [14].

VI. CONCLUSION

In this paper, we highlighted BLOCKEYE as an open
platform to detect DeFi attacks on blockchain. Compared
to existing analyzers for smart contracts, BLOCKEYE pro-
vides important capabilities to model dependency among DeFi
projects and flag potential end-to-end attacks at real-time. The
key insights behind BLOCKEYE are symbolic oracle analysis
and pattern-based runtime transaction validation. We applied
BLOCKEYE in several popular DeFi projects on Ethereum and
managed to find potential attacks previously unreported.

VII. DATA AVAILABILITY STATEMENT

For ethical considerations, experimental data used in our
work will be publicly available after discussions with the
relevant DeFi development team.

REFERENCES

[1] G. Wood, “Ethereum: A secure decentralised generalised transaction
ledger,” Ethereum Project Yellow Paper, vol. 151, 2014.

[2] L. Luu, D.-H. Chu, H. Olickel, P. Saxena, and A. Hobor, “Making smart
contracts smarter,” in Proceedings of the 2016 ACM SIGSAC Conference
on Computer and Communications Security. ACM, 2016, pp. 254–269.

[3] P. Tsankov, A. Dan, D. D. Cohen, A. Gervais, F. Buenzli, and M. Vechev,
“Securify: Practical security analysis of smart contracts,” arXiv preprint
arXiv:1806.01143, 2018.

[4] C. Liu, H. Liu, Z. Cao, Z. Chen, B. Chen, and B. Roscoe, “Reguard:
finding reentrancy bugs in smart contracts,” in ICSE (Companion).
ACM, 2018, pp. 65–68.

[5] H. Liu, C. Liu, W. Zhao, Y. Jiang, and J. Sun, “S-gram: towards
semantic-aware security auditing for ethereum smart contracts,” in ASE.
ACM, 2018, pp. 814–819.

[6] Z. Yang, H. Liu, Y. Li, H. Zheng, L. Wang, and B. Chen, “Seraph:
enabling cross-platform security analysis for evm and wasm smart con-
tracts,” in Proceedings of the ACM/IEEE 42nd International Conference
on Software Engineering: Companion Proceedings, 2020, pp. 21–24.

[7] “Microsoft z3 smt solver,” https://z3.codeplex.com/, 2019.
[8] “Codefi inspect,” https://inspect.codefi.network/, 2020.
[9] T. Eiter, G. Gottlob, and H. Mannila, “Disjunctive datalog,” ACM

Transactions on Database Systems (TODS), vol. 22, no. 3, pp. 364–418,
1997.

[10] A. Permenev, D. Dimitrov, P. Tsankov, D. Drachsler-Cohen, and
M. Vechev, “Verx: Safety verification of smart contracts,” Security and
Privacy, vol. 2020, 2019.

[11] K. Qin, L. Zhou, B. Livshits, and A. Gervais, “Attacking the
defi ecosystem with flash loans for fun and profit,” arXiv preprint
arXiv:2003.03810, 2020.

[12] J. Kamps and B. Kleinberg, “To the moon: defining and detecting
cryptocurrency pump-and-dumps,” Crime Science, vol. 7, no. 1, p. 18,
2018.

[13] B. Liu and P. Szalachowski, “A first look into defi oracles,” arXiv
preprint arXiv:2005.04377, 2020.

[14] L. Gudgeon, D. Perez, D. Harz, A. Gervais, and B. Livshits,
“The decentralized financial crisis: Attacking defi,” arXiv preprint
arXiv:2002.08099, 2020.

https://z3.codeplex.com/
https://inspect.codefi.network/

	I Introduction
	II Attack Detection For DeFi
	II-A Overview
	II-B Oracle Analysis
	II-C Automatic Attack Monitoring

	III Design of BlockEye
	III-A Architecture
	III-B Main Functionalities

	IV Preliminary Evaluation
	V Related Work
	VI Conclusion
	VII Data Availability Statement
	References

";"""date"",""2021-03-05T02:07:52Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2021-03-05T02:07:52Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.21 (TeX Live 2020) kpathsea version 6.3.2""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2021-03-05T02:07:52Z""
""created"",""2021-03-05T02:07:52Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2021-03-05T02:07:52Z""
""resourceName"",""2103.02873""
""Author"",""""
""producer"",""pdfTeX-1.40.21""
""pdf:docinfo:producer"",""pdfTeX-1.40.21""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2021-03-05T02:07:52Z""
""Last-Modified"",""2021-03-05T02:07:52Z""
""dcterms:modified"",""2021-03-05T02:07:52Z""
""title"",""""
""Last-Save-Date"",""2021-03-05T02:07:52Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2021-03-05T02:07:52Z""
""meta:save-date"",""2021-03-05T02:07:52Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.21 (TeX Live 2020) kpathsea version 6.3.2""
""Content-Length"",""6456899""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""4""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""4825"",""3696"",""3448"",""4861""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2021-03-05T02:07:52Z""
";https://scholar.google.ch/scholar?start=10&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2021
1619099133-477;https://scholar.google.ch/scholar?as_ylo=2021&q=oracles+blockchain&hl=fr&as_sdt=0,5;Anonymity on blockchain based e-cash protocols—A survey;N Andola, VK Yadav, S Venkatesan, S Verma ; Computer Science Review, 2021  Elsevier;;"… Review article. Anonymity on blockchain based e-cash protocols—A survey. Author …

Abstract. The transactions in blockchain framework, based cryptocurrencies are publicly

available, thereby accessible to all users by design. However …";Les 2 versions;;null;;;;https://scholar.google.ch/scholar?start=60&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2021
1619099133-471;https://scholar.google.ch/scholar?as_ylo=2021&q=oracles+blockchain&hl=fr&as_sdt=0,5;Blockchain for IoT-based smart cities: Recent advances, requirements, and future challenges;U Majeed, LU Khan, I Yaqoob, SMA Kazmi… ; Journal of Network and …, 2021  Elsevier;;null;Les 4 versions;;[PDF] researchgate.net;https://www.researchgate.net/profile/Umer-Majeed/publication/348995702_Blockchain_for_IoT-based_Smart_Cities_Recent_Advances_Requirements_and_Future_Challenges/links/602b7b43299bf1cc26cb7abc/Blockchain-for-IoT-based-Smart-Cities-Recent-Advances-Requirements-and-Future-Challenges.pdf;;;https://scholar.google.ch/scholar?start=60&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2021
1619099142-490;https://scholar.google.ch/scholar?as_ylo=2021&q=oracles+blockchain&hl=fr&as_sdt=0,5;[PDF][PDF] Quantum indifferentiability of SHA-3;J Czajkowski ;2021 eprint.iacr.org;;"… To achieve our result, we generalize the compressed-oracle technique of Zhandry (Crypto'19)

by defining and proving correctness of a compressed permutation oracle … 2.2 Compressed-Oracles

Technique The compressed oracle technique was developed by Zhandry [Zha19] …";Cité 3 fois;Version HTML;[PDF] iacr.org;https://eprint.iacr.org/2021/192.pdf;"
Quantum Indifferentiability of SHA-3

Jan Czajkowski∗

QuSoft, University of Amsterdam

February 22, 2021

Abstract

In this paper we prove quantum indifferentiability of the sponge construction instanti-
ated with random (invertible) permutations. With this result we bring the post-quantum
security of the standardized SHA-3 hash function to the level matching its security against
classical adversaries. To achieve our result, we generalize the compressed-oracle technique
of Zhandry (Crypto’19) by defining and proving correctness of a compressed permutation
oracle. We believe our technique will find applications in many more cryptographic con-
structions.

Contents

1 Introduction 2

2 Preliminaries 3
2.1 Indifferentiability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2 Compressed-Oracles Technique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.3 Game-Playing Proofs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.3.1 Classical Game-Playing Proofs . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3.2 Quantum Game-Playing Proofs . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.4 Sponge Construction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

3 Compressed Oracle for Random Permutations 8
3.1 Definition of the Compressed Permutation Oracle . . . . . . . . . . . . . . . . . . 8
3.2 Indistinguishability of CPerO and PerO . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.3 Punctured Compressed Permutation Oracle . . . . . . . . . . . . . . . . . . . . . . 15

4 Indifferentiability of Sponges with Random Permutations 16
4.1 Classical Indifferentiability of Sponges with Random Permutations . . . . . . . . 16
4.2 Quantum Indifferentiability of Sponges with Random Permutations . . . . . . . . 20

References 23

A Single-query Distinguisher 26

Symbol Index 28

∗j.czajkowski@uva.nl

1



1 Introduction

With efforts to build a quantum computer on the rise, cryptography resilient to quantum at-
tackers (i.e. attackers equipped with a large-scale quantum computer) becomes a necessity.
Post-quantum cryptography [BBD09], in other words quantum-safe (classical) cryptography, is
considered to be important enough that the NIST organized the process to standardize post-
quantum cryptographic schemes [NIS17].

A prominent primitive, used in many of the submissions to the NIST standardization pro-
cess, is the SHA-3 hash function [NIS14]. The cryptographic construction used in the design
of this hash function, is the sponge construction [Ber+07]. One of the reasons the sponge con-
struction was chosen as the backbone of this standardized hash function, was the strong se-
curity guarantees offered by the proof of its indifferentiability from a random oracle [Ber+08].
Indifferentiability [MRH04] is a notion similar to the Ransom Oracle Model (ROM) [BR93]—
where we claim a hash function is a random oracle—but much better tailored to cryptographic
constructions. To prove indifferentiability, we assume the internal function called by the con-
struction to be ideal (a uniformly random function or permutation) but also give the adversary
access to it.

For five years now, the research community has worked to rigorously prove post-quantum
security of the sponge construction [Cza+18; CHS19; Cza+19; Unr21]. One of the goals of
this line of research was to match the security level guaranteed by proofs valid for classical
adversaries. In [Cza+19] the authors managed to prove quantum indifferentiability, but with
one shortcoming, they only treated uniformly random internal functions. Now is it important
to note, that SHA-3 is based on an invertible permutation, this design choice is dictated, among
other reasons, by the cryptographic practice showing that it is much easier to design secure
permutations than one-way functions. In [Unr21] Unruh claims to prove quantum collision-
resistance of SHA-3. In ourwork, we finallymanage to close the gap between classical and post-
quantum security of SHA-3: We prove quantum indifferentiability of the sponge construction
instantiated with random permutations.

The natural proof technique suitable for indifferentiability proofs is that of lazy-sampling.
In a recent work, Zhandry developed the compressed-oracle technique [Zha19], which is the
quantum version of lazy-sampling. Until now, however, the quantum techniques did not cover
lazy-sampling of random (invertible) permutations. Changing that, is the main technical con-
tribution of this paper. Basing on the quantum game-playing framework of [Cza+19], we de-
fine a quantum compressed permutation oracle. Our result introduces errors, but they are
smaller than the leading terms in the distinguishing advantage of the indifferentiability adver-
sary. Arguably, the total bound on the distinguishing advantage that we prove is tight. Al-
though we do not show an algorithmwith a matching query complexity, our bound on the dis-
tinguishing advantage1 of O(

√
q3/2c) gives rise to security of up to Ω

(
2c/3

)
queries. A generic

collision finding algorithm for the sponge construction, e.g. from [Cza+18], is expected to run
in O

(
2c/3

)
queries to the internal function. In [Unr21], Unruh also proposes a technique for

dealingwith invertible randompermutations in a quantumworld, his approach, however, is not
suitable for indifferentiability proofs, as the permutation oracle is not efficiently simulatable.

In section 2 we give more details on the methods we use to achieve our results. The com-
pressed permutation oracle is defined and proven indistinguishable from a random permu-
tation in section 3. The main result of this paper, quantum indifferentiability of the sponge
construction instantiated with random permutations, is located in section 4. A reader mostly
interested in the application of our new technique can go directly to section 4, as we provide a
high level introduction to the main ingredients of the proof.

1By distinguishing advantage, wemean the absolute value of the difference of the probabilities that the adversary
outputs 1 when interacting with the construction or a random oracle.

2



2 Preliminaries

In this section we start by going over notation used in this paper. Later we present some key
concepts that we use to achieve our results. A summary of symbols used throughout the paper
can be found in the Symbol Index.

In this paper we assume the reader has basic knowledge of quantum computing. If any
concept is not familiar though, we refer to [NC10; Wol11]. A quantum state is a unit vector in a
Hilbert space |ψ〉 ∈ Cd. We often refer to vectors of norm smaller than 1 as states aswell. Inwhat
follows we denote the Euclidean norm of a vector by ‖|ψ〉‖. The trace norm of an operator A on
a Hilbert space is defined as the trace of the absolute value of the operator: ‖A‖1 := Tr

√
A†A.

Subspaces of tensor products of several Hilbert spaces are referred to by superscripts, so if
HD =

⊗q
i=1HXi ⊗ HYi , then DX refers to

⊗q
i=1HXi , and same for Y . We write AD to denote

that A acts on register D.
We write [N ] := {0, 1, . . . , N − 1} for the set of size N . Whenever we consider sets of bits

{0, 1}n, we denote the bitwise XOR by ⊕.
To denote vectors we write ~x ∈ [N ]s. We also use set operations2 on these vectors, by

identifying them with sets with elements from ~x. We consider ~x to be always sorted in a rais-
ing fashion and contain no repetitions, so set operations are unambiguous. By ~y~x we denote
(yx1 , . . . , yxs), where s = |~x|. Vector ~y~x is sorted according to ~x.

The set of outputs of injective partial functions is denoted by

I(s | ~y) := {~y′ ∈ [N ]s : ∀i, j 6= i, y′i 6= y′j ∧ y′i 6∈ ~y}, and its size by (1)
(N)s := |I(s)| = N(N − 1) · · · (N − s+ 1), (2)

where in the definition of (N)s we use the notation I(s) := I(s | ∅).
By x ← A we denote sampling x from a distribution or getting the output of a random-

ized algorithm. By square brackets we denote (classical or quantum) oracle access to some
algorithm, we also use AH if the oracle is denoted by a more confined symbol.

An object that we make heavy use of in this paper is the random oracle:

R : {0, 1}∗ × N→ {0, 1}∗. (3)

A random oracle grants access to a function sampled from distributionR on functions {0, 1}∗×
N→ {0, 1}∗, that is defined as follows: To sample a function h← Rwe

• choose g uniformly at random from {g : {0, 1}∗ → {0, 1}∞}, where by {0, 1}∞ we denote
the set of infinitely long bitstrings,

• for each (x, `) ∈ {0, 1}∗×N set h(x, `) := bg(x)c`, that is output the first ` bits of the output
of g.

2.1 Indifferentiability

Whenever, the hash function is constructed out of a public internal function (like in the case of,
e.g., SHA-2 [NIS15] and SHA-3 [NIS14]), a security notion that includes the adversary’s access
to the internal (and publicly specified) function and aims at showing that the hash function
behaves as a uniformly random function, is indifferentiability [MRH04].

In the setting of indifferentiability the adversary is given access to two interfaces, the public
interface, denoted by “pub” and the private interface, denoted by “priv”. Indifferentiability of
a system C is phrased in terms of a distinguishing game, where the adversary distinguishes
between the real and the ideal world. In the real world, the private interface is the construc-
tion calling the internal function, denoted as Cpriv[Cpub], and the public interface is the internal

2Such as the union ∪, intersection ∊, or subtraction \.

3



function Cpub. In the ideal world, where the construction is often replaced by a random oracle,
the private interface is just Rpriv

k , but the public interface is provided by a simulator that replaces
the internal function, she is also given access to the ideal system and the interface is S[Rpub

k ]. In
case of R being a random oracle both the public and the private interfaces of R are equal and
just return outputs of a random function.

Definition 1 (Indifferentiability [MRH04]). A cryptographic system C is (q, Îľ)-indifferentiable
from R, if there is an efficient (classical or quantum) simulator S and a negligible function Îľ such that
for any efficient (classical or quantum) distinguisher D with binary output (0 or 1) the advantage∣∣∣P [1← D[Cpriv

k [Cpub
k ],Cpub

k ]
]
− P

[
1← D[Rpriv

k , S[Rpub
k ]]

]∣∣∣ ≤ ε(k) , (4)

where k is the security parameter. The distinguisher makes at most q (classical or quantum) queries.

2.2 Compressed-Oracles Technique

The compressed oracle technique was developed by Zhandry [Zha19]. The key idea of this
technique is to purify a quantum-accessible random oracle so all the randomness is kept in a
quantum register. The standard oracle for a uniformly random function is defined as:

StO|x, y〉XY
∑
f∈F

1√
|F|
|f〉F =

∑
f∈F

1√
|F|
|x, y + f(x)〉XY |f〉F , (5)

where x, y ∈ X , for X = [N ], addition is done modulo N , and f is the full truth table of the
function from F := {f : X → X}3. The update procedure StO just adds the correct row of f
to adversary’s Y register. The crucial fact is that an adversary A interacting with StO acting on
the oracle register from Eq. (5) has zero probability of distinguishing it from f

$← F .
A compressed oracle CStO is an oracle with the oracle register F compressed to register

D that just holds the outputs to queries asked by the adversary A. The update procedure in
this case is more complicated but allows to keep a superposition of small database of the form
D = ((x1, y1), . . . , (xq, yq)), where q is the bound on the maximal number of quantum queries
made by A. In the case A made s < q queries, the last q − s entries hold ⊥ in the X-type part
of the entries. More details on this technique can be found in [Zha19; LZ19; Cza+19; HI19;
Chu+20; Unr21]. Similarly to StO, the distinguishing advantage between CStO and f $← F is
0.

A change of the adversary’s basis, that can be done by applying the quantum Fourier trans-
form QFTN |y〉 := 1√

N

∑
η∈[N ] ω

Ρ¡y
N |η〉, where ωN := e

2πi
N is the N -th root of unity, gives rise to

the phase oracle:

PhO|x, η〉XY
∑
f∈F

1√
|F|
|f〉F =

∑
f∈F

1√
|F|

ω
Ρ¡f(x)
N |x, η〉XY |f〉F . (6)

Similarly, by changing the adversary’s interface to the Fourier basis, we get the compressed
phase oracle CPhO. For readers less familiar with quantum accessible oracles, we note that a
quantum query does not always increase the number of input-output pairs A has knowledge
of. SayA queries (x, Ρx) at some point. IfA later queries the same input with a different Ρ, then
she updates her knowledge of f(x). If η = −ηx then she might even “forget” the query x, or—if
she interacts with a compressed oracle—remove x from the database.

Whenever we talk about CStO and CPhO, we consider them to be oracles for the uniform
distribution. Moreover, when providing the subscript X , by CPhOX we mean that functions

3In general, the standard and compressed oracle can be defined for any set of functions.

4



are distributed uniformly from {f : X → X}. More on compressed oracles for different distri-
butions can be found in [Cza+19].

Building upon the compressed oracle technique the authors of [Cza+19] developed a quan-
tum game-playing framework. The key object of this framework, that we make heavy use of, is
the punctured compressed oracle. Puncturing is defined as performing a binary measurement
of the oracle register D of a compressed oracle after every query done by A. As long as the
probability of one of the outputs (say 0) is almost 1, the puncturing does not give the adver-
sary a major distinguishing advantage. The measurement, however, allows us to argue about
the adversary’s behavior conditioned on the database begin of some specific form.

The measurements in punctured oracles are binary projective measurement. We project
to databases that fulfill a given relation. A relation is a subset of all possible databases of size
bounded by q. An important relation, that we use in the reminder of this paper, is the collision
relation:

Rcoll :=
{
D ∈

q⋃
s=1

(X × Y)s : ∃i, j 6= i, xi 6= xj , yi = yj

}
, (7)

where D = ((x1, y1), . . . , (xs, ys)). Measuring a relation on the quantum compressed oracle
includes checking the actual size of the database, so it omits the entries starting with ⊥.

A formal definition of a compressed oracle H punctured on relation R, denoted by H \R, is
stated below. More details on the above concepts can be found in [Cza+19].

Definition 2 (Punctured compressed oracle H \ R, Definition 9 in [Cza+19]). Let H be a com-
pressed oracle and R a relation on its database. The punctured compressed oracle H \ R is equal to H,
except that R is measured after every query. By Find we denote the event that R outputs 1 at least once
among all queries.

2.3 Game-Playing Proofs

Game-playing proofs are a common framework used in cryptography. Originally developed by
Bellare and Rogaway [BR06] the main concept is that if two games—in other words, interactive
protocols—are identical until a “bad” event happens, then they are indistinguishable except for
the probability that this event occurs.

Using recently developed techniques, this reasoning can be applied to quantum interactive
protocols as well. Below, we present the classical and the quantum game-playing framework.
We use the statements from below in our indifferentiability proofs in section 4.

2.3.1 Classical Game-Playing Proofs

Two games are considered to be identical-until-bad if they are syntactically identical except for
code that follows after setting Bad to true. Bad is a special flag, we also write Bad to denote
the event “Bad set to true”. The main ingredient of the classical game-playing framework is the
fundamental game-playing lemma:

Lemma 3 (Fundamental lemma of game-playing, Lemma 2 in [BR06]). Let G and H be identical-
until-bad games and let A be an adversary that outputs a bit b. Then∣∣∣P[1← AH]− P[1← AG]

∣∣∣ ≤ P[Bad = 1 : AG]. (8)

2.3.2 Quantum Game-Playing Proofs

The quantum game-playing framework, developed in [Cza+19], makes use of two powerful
proof techniques. One being the compressed oracle technique by Zhandry [Zha19], the other

5



being theOne-wayToHiding (O2H) lemmabyUnruh [Unr14; AHU19]. The former (whichwe
described in section 2.2), together with the idea of puncturing oracles, is used to define quan-
tum games. The latter provides the quantum counterpart of the fundamental game playing
lemma.

Here we present the version of the O2H lemma from [AHU19] that was later repurposed
to treat punctured compressed oracles in [Cza+19].

Lemma 4 (Compressed oracle O2H, Theorem 10 in [Cza+19]). Let R1 and R2 be relations on the
database of a quantum oracle H. Let A be an oracle algorithm making q quantum queries, then∣∣∣P[1← AH\R1 ]− P[1← AH\R1∪R2 ]

∣∣∣ ≤ √(q + 1)P[Find : AH\R1∪R2 ], (9)

where Find is the event that measuring R1 ∪R2 succeeds.

An important comment that relates to the main subject of this work is that the above lemma
works just as well for invertible oracles, such as random permutations. Following the proof, in
[Cza+19], we notice that it relies only on measuring the database and the general interface of
compressed oracles. These aspects do not change in our definition of the compressed permu-
tation oracle. More discussion on which, can be found in section 3.

The notion of identical-until-bad games can also be brought to the world of quantum com-
pressed oracles.

Definition 5 (Almost identical oracles, Definition 11 in [Cza+19]). Let H and G be compressed
oracles andRi, i = 1, 2 relations on their databases. We call the oracles H\R1 and G\R2 almost iden-
tical if they are equal conditioned on the events ÂŹFind1 and ÂŹFind2 respectively, i.e. for any quantum
algorithm A

P[1← AH\R1 | ¬Find1] = P[1← AG\R2 | ¬Find2]. (10)

Distinguishing advantage for almost-identical oracles can be bounded using the following
lemma.

Lemma 6 (Distinguishing almost identical punctured oracles, Lemma 12 in [Cza+19]). IfH\R1
and G \R2 are almost identical according to Def.5 then for any b ∈ {0, 1}∣∣∣P[1← AH\R1 ]− P[1← AG\R2 ]

∣∣∣ ≤ 2P[Find1 : AH\R1 ] + 2P[Find2 : AG\R2 ]. (11)

2.4 Sponge Construction

The sponge construction Sponge [Ber+07] is prominently used to design the standardized hash
function SHA-3 [NIS14]. It can be instantiated with a function or a permutation f : {0, 1}r+c →
{0, 1}r+c. The construction is divided in two phases: In the absorbing phase the padded input
message is XOR-ed block by block (blocks are r-bits long) into the first r bits of the internal
state (consisting of r + c bits) of Spongef and after each block f is applied to the whole state.
In the following squeezing phase the first r bits are output and f is applied, this repeats until `
bits of output is generated. This distinction into the first r bits and the last c bits calls for special
notation. For a state s ∈ {0, 1}r+c, the first r bits are called the outer part and are denoted by s̄,
the last c bits are called the inner part and are denoted by ŝ. By pad : {0, 1}∗ → ({0, 1}r)∗ (where
by ({0, 1}r)∗wedenote the strings consisting of an arbitrary number of r-bit blocks)wedenote a
padding function. The requirements on pad in the sponge construction are that it is an efficiently
computable injection such that |pad(m)| ≥ r and that the last bit of pad(m) is never 0 (this
ensures injectivity for inputs of different lengths). The rate of the sponge is r and the capacity is
c, these key parameters, together with the internal function and the padding function give rise
to the hash function Spongef [pad, r, c] : {0, 1}∗ × N→ {0, 1}∗, where {0, 1}∗ :=

⋃∞
n=0{0, 1}∗. In

6



Algorithm 1: Spongef [pad, r, c]
Input :m ∈ {0, 1}∗, ` ≥ 0
Output: z ∈ {0, 1}`

1 p := pad(m)
2 s := (0, 0) ∈ {0, 1}r × {0, 1}c
3 for i = 1 to |p|r do // Absorbing phase
4 s := (s̄⊕cpbi, ŝ)
5 s := f(s)
6 z := s̄ // Squeezing phase
7 while |z| < ` do
8 s := f(s)
9 z := z‖s̄

10 Output z

what follows, by |p|r we denote the number of r-bit blocks in p and by cpbi we denote the i-th
r-bit block of p. The formal definition of the sponge construction is presented in Algorithm 1.

It was already noticed in [Ber+07] that one can associate a graph G = (V, E) with the in-
ternal function of a sponge. This graph is called the sponge graph and plays an important role
in indifferentiability proofs of the sponge construction [Ber+08; Cza+19]. The set of nodes of
this graph is V := {0, 1}r+c, it corresponds to all possible states of the sponge. A directed edge
connects any two nodes (s, t) whenever f(s) = t, meaning there are 2r+c edges in E . From each
node starts exactly one edge. A supernode groups the nodes with the same inner-part, thus we
have 2c supernodes and each such supernode consists of 2r nodes. Edges between nodes are
also edges between supernodes.

The initial state of any call of Sponge is the (0r, 0c) node. This node is called the root. The
first r-bit block cpb1 of the padded message p = pad(m) is then added to the outer-part of the
state and fed to the internal function f(cpb1‖0c) = s2. This evaluation of f defines the edge
(cpb1‖0c, s2) ∈ E . In the absorbing phase this operation is repeated until we run out of blocks
of p. In the squeezing phase we no longer modify the state, in other words just add 0r to the
outer part. Note that knowing just p andGwe can get to the last node traversed by Spongef (m).
This leads to the definition of a sponge path.

Definition 7 (Sponge path, Definition 3 in [Ber+08]). First, the empty string is a sponge path to
the node 0r‖0c. Then, if p is a sponge path to node s = s̄‖ŝ and there is an edge (s̄⊕a‖ŝ, t) in the sponge
graph G, p′ = p‖a is a sponge path to node t.

Given the above definition, let us say that p forms a sponge path to s, then we define a
function

SpPath(s,G) := p. (12)

Output of the above function is the input to the construction Spongef (., ` = r) that yields the
output s̄.

In indifferentiability proofs, the simulator has access to the simulator graph. The graph kept
by the simulator differs from the sponge graph discussed above by the number of edges in it.
As the simulator lazy samples the internal function f the set of edges E grows by at most one
edge per a single adversary’s query. Other than that, everything that has been said above holds.
We refer to the simulator graphG as just the (sponge) graph whenever it is clear from context.

A supernode is called rooted if there is a path (a regular path that is just a set of edges
connected by the end-start nodes) leading to it that starts in the root (the 0c-supernode). The

7



setR is the set of all rooted supernodes inG. By U we denote the set of supernodes with a node
with an outgoing edge.

A simulator graph is called saturated ifR∪U = {0, 1}c. It means that for every inner state in
{0, 1}c there is an edge in G that leads to it from 0c (the root) or leads from it to another node.
Saturation will be important in the proof of indifferentiability as the simulator wants to pick
outputs of f without colliding inner parts (so not in R) and making the path leading from 0c
to the output longer by just one edge (so not in U).

3 Compressed Oracle for Random Permutations

In this section we define the compressed oracle for invertible random permutation. Our ap-
proach is rather simple, we use a compressed oracle for the uniform distribution and puncture
it on collisions. The collision-free databases can be easily inverted and the same update proce-
dure as for the forward direction provides the backward-direction oracle.

The hard part in this section is proving that our compressed permutation oracle is in fact
indistinguishable from a full permutation oracle. The full oracle keeps a superposition of all
bijective functions and responds to both forward and backward queries.

Our approach to proving indistinguishability relies on a relatively simple auxiliary good
state. The good state is generated by the adversary interacting with the compressed oracle for
the uniform distribution, after the interaction we project the database to contain only collision-
free databases. Such state is easy to handle and we can prove its closeness of the state coming
from the full permutation oracle. We then reuse the proof from [Cza+19] to show closeness of
the good state and the compressed oracle state.

In the end of this section we also provide bounds on the probability of Find for punctured
compressed permutation oracles. These results are important for our indifferentiability proof.

3.1 Definition of the Compressed Permutation Oracle

The core of the compressed permutation oracle is a compressed oracle for the uniform distri-
bution punctured on the collision relation CPhOX \Rcoll. To allow for inverse access we define
a unitary that flips the database, so the outputs become inputs and vice versa. Then queries are
handled with the same CPhOX \Rcoll procedure.

Inmore detail, we provide access to the inverse of the permutation by flipping the database:
treat the content of DY as inputs and DX as outputs and sort by DY , we call the appropriate
unitary Flip. Note that FlipD works as anticipated only if both in DY and DX there are no
collisions; The definition of Flip can be easily extended to a full unitary by, e.g., keeping the
order unchanged within a tuple with colliding outputs. We thereby obtain a (superposition)
database where the entries (yi, xi) are sorted in a rising order according to the first value. A
more detailed description of Flip is:

1. Controlled on DY copy DX to a fresh D′Y and arrange in an increasing order according
to values of yi in DY .

2. Controlled on DX and D′Y copy DY to a fresh D′X in the new order.

3. Controlled onD′ erase the oldD: Take the smallest xi inD′Y and subtract it from the first
register of DX , also subtract the corresponding yi, and so on.

A formal definition of the compressed permutation oracle CPerOX is:

8



Definition 8. The compressed permutation oracle for permutations f : X → X is defined as the follow-
ing procedure:

CPerOX := CPhOX \Rcoll, (13)
CPerO−1

X := FlipD ◦ (CPhOX \Rcoll) ◦ FlipD, (14)

where Flip is defined above and CPhOX is the compressed phase oracle for the uniform distribution over
{f : X → X}.

3.2 Indistinguishability of CPerO and PerO

By PerO we denote the full oracle for a uniform distribution over permutations, technically it
is defined in the same way as PhO from Eq. (6) but we always use it with the oracle register
holding a superposition of permutations:

PerOX |x, η〉XY
∑
f∈P

1√
|P|
|f〉F =

∑
f∈P

1√
|P|

ω
Ρ¡f(x)
N |x, η〉XY |f〉F , (15)

whereP := {f : X → X : f is a bijection} . Themain statement of this section is the correctness
of the compressed permutation oracle.

Theorem 9 (Correctness of CPerOX ). No quantum algorithm A making at most q quantum queries
can distinguish CPerOX from the full permutation oracle PerOX except for a small error:∣∣∣P [1← APerOX

]
− P

[
1← ACPerOX

]∣∣∣ ≤ 18q5/2

N − q
, (16)

where N = |X |.

Before getting into the proof of the main statement we suggest the reader to go over the ob-
servation presented in Appendix A. The observation is a theorem stating the distinguishability
advantage of any adversary trying to discern a uniformly random function from a random per-
mutation using a single quantum query. The approach to the proof of Theorem 17 is quite
related to that from of proof of Theorem 9.

In the following three paragraphs we define and provide some useful notation on the two
important classes of quantum states that we will make heavy use of.
The permutation states First we go over the full permutation oracle. The state that results from
A interacting with the full permutation oracle PerO is

|ΨPerO〉AF :=
∑
~x,~Ρ,w

α~x,~η,w|ψ(~x, ~η, w)〉A

∑
~y~x∈I(s)

1√
(N)s

ω~η·~y~xN︸ ︷︷ ︸
(∗): effective queries

∑
~yX\~x∈I(N−s|~y~x)

|y0, y1, . . . , yN−1〉F , (17)

where registerAholds all of the adversary’s state, this includes herwork register, query register,
and any other auxiliary registers she decides to use. We denote it by ψ(~x, ~Ρ, w), where w can
be any value of finite size. In the above state ~x = (x1, . . . , xs) is the set of effective queries. As
querying a quantumoracle can result in “un-querying” a value, by ~xwedenote only the queried
values that are entangled with the oracle register after all q queries of A. For these queries we
also have ηxi 6= 0 for all xi ∈ ~x. The size of ~x is s and s ≤ q.

The permutation state is the partial trace of the above state

ρPerO := TrF |ΨPerO〉AF 〈ΨPerO| =
∑

~x,~x′,~x′′

ρPerO(~x ∪ ~x′, ~x ∪ ~x′′), (18)

9



where in the above sums we have ~x′ ∩ ~x = ∅, ~x′′ ∩ ~x = ∅, and ~x′′ ∩ ~x′ = ∅. Moreover ~x ∪ ~x′ and
~x ∪ ~x′′ range over X q. The state is defined as

ρPerO(~x ∪ ~x′, ~x ∪ ~x′′) := TrF |ΨPerO(~x ∪ ~x′)〉AF 〈ΨPerO(~x ∪ ~x′′)|, (19)

where |ΨPerO(~x ∪ ~x′)〉AF is the branch of the superposition in |ΨPerO〉 corresponding to effective
queries in ~x ∪ ~x′.

Below we define well-formed matrices. The intuition behind well-formed matrices is that
they are parts of quantum states resulting from the interaction of an adversary with the full
permutation oracle. They are natural parts of density matrices corresponding to A interacting
with PerO.

Definition 10. A vector is well-formed if it is of the form from Eq. (17). Coefficients ι~x,~Ρ,w can be
such that the overall state is sub-normalized.

A matrix iswell-formed if it is of the form from Eq. (19) with the vectors being well formed.

The good states In what follows we write ~x to denote the effective queries. The state |ΨGood〉AD
corresponds to the adversary’s state after q queries. The size of the database is s = |~x|. After
q queries s can range from 0 to q and the joint state of A and the oracle can be a superposition
over different database sizes. We denote the outputs given to A by ~y := (y1, . . . , ys). We define
the good state as:

|ΨGood〉AD :=
∑
~x,~Ρ,w

α~x,~η,w|ψ(~x, ~η, w)〉A
∑

~y∈I(s)

1√
(N)s

ω~η·~yN
∑

ys+1,...,yq∈[N ]

1√
N q−s

|(x1, y1), . . . , (xs, ys), (⊥, ys+1), . . . , (⊥, yq)〉D. (20)

The good state is also defined as running the adversary and giving her access to the compressed
standard oracle CPhOX . After q queries we project register D to collision free databases.

Inverse queries In what follows we treat elements of tuples of effective queries ~x as pairs in
{+,−}×X , where the first entry signifies the interface (forward or backward) of the permuta-
tion. We don’t write it explicitly throughout this paper because it is not necessary for the main
argument. We just note that a query value always implicitly contains the interface it was made
to.

Below we write the part corresponding to effective queries of an adversary that queries x1
in the forward direction and y2 in the backward direction:

∑
f∈P

1√
N !
ω
Ρ1f(x1)
N ω

η2f−1(y2)
N |f〉F = 1√

N !
∑

zx1∈[N ]
ω
Ρ1zx1
N |zx1〉

∑
sy2 6=x1

ω
Ρ2sy2
N |sy2〉

∑
z1 6∈{zx1 ,y2}

|z1〉
∑

~z∈I(N−2|{zx1 ,y2,z1})
|z2〉 · · · |zN−2〉, (21)

where the second line is correct only if y2 6= zx1 . The above equation exemplifies that the form
we wrote the states from Eqs. (17, 20) is suitable to capture inverse queries.

Proof of Theorem 9. We first simplify the distinguishing advantage to include interaction with
the punctured oracle conditioned on ¬Find:∣∣∣P [1← APerO

]
− P

[
1← ACPerO

]∣∣∣
≤
∣∣∣P [1← APerO

]
− P

[
1← ACPerO | ¬Find

]
P
[
ÂŹFind

]∣∣∣+ P
[
Find

]
(22)

≤
∣∣∣P [1← APerO

]
− P

[
1← ACPerO | ¬Find

]∣∣∣+ P
[
Find

]
. (23)

10



In the first step above we write down the right term as P[1 ← ACPerO] = P[1 ← ACPerO |
ÂŹFind]P

[
ÂŹFind

]
+ P[1 ← ACPerO | Find]P

[
Find

]
. Next we use the triangle inequality and

bound P[1 ← ACPerO | Find] ≤ 1. If an adversary outputs 1 with greater probability when she
interacts with PerO we instead considerA′ that operates exactly likeAwith the only difference
that she flips the output. The second inequality is";"""date"",""2021-02-22T15:09:26Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2021-02-22T15:09:26Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.20 (TeX Live 2019) kpathsea version 6.3.1""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2021-02-22T15:09:26Z""
""created"",""2021-02-22T15:09:26Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2021-02-22T15:09:26Z""
""resourceName"",""192.pdf""
""Author"",""""
""producer"",""pdfTeX-1.40.20""
""pdf:docinfo:producer"",""pdfTeX-1.40.20""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""5"",""33"",""29"",""11"",""15"",""22"",""5"",""67"",""117"",""62"",""282"",""182"",""222"",""55"",""2"",""6"",""1"",""28"",""7"",""12"",""11"",""5"",""0"",""0"",""99"",""134"",""2""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2021-02-22T15:09:26Z""
""Last-Modified"",""2021-02-22T15:09:26Z""
""dcterms:modified"",""2021-02-22T15:09:26Z""
""title"",""""
""Last-Save-Date"",""2021-02-22T15:09:26Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2021-02-22T15:09:26Z""
""meta:save-date"",""2021-02-22T15:09:26Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.20 (TeX Live 2019) kpathsea version 6.3.1""
""Content-Length"",""534349""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""28""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""1443"",""3584"",""2694"",""2759"",""2621"",""2844"",""2339"",""2729"",""2139"",""2295"",""2582"",""2064"",""2778"",""1997"",""1715"",""2781"",""2462"",""670"",""1820"",""3297"",""2159"",""904"",""2058"",""2772"",""328"",""2007"",""1491"",""1288""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2021-02-22T15:09:26Z""
";https://scholar.google.ch/scholar?start=80&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2021
1619099138-487;https://scholar.google.ch/scholar?as_ylo=2021&q=oracles+blockchain&hl=fr&as_sdt=0,5;[HTML][HTML] Big data for corporate social responsibility: blockchain use in Gioia del Colle DOP;M Giacalone, V Santarcangelo, V Donvito… ; Quality & Quantity, 2021  Springer;Kingdom of the Netherlands;"… Search SpringerLink Search. Big data for corporate social responsibility: blockchain use in Gioia

del Colle DOP. Download PDF. Download PDF. Published: 21 January 2021. Big data for

corporate social responsibility: blockchain use in Gioia del Colle DOP …";Les 5 versions;;[HTML] springer.com;https://link.springer.com/article/10.1007/s11135-021-01095-w;"
    
    
    
        
            
            
                
            

            
        
    


    
        
        

        
            
                Advertisement

                    

            

        


    
        
            
                
    
        
            
            [image: SpringerLink]
        
        
        
    


            

            
                
    
        
            
                Search
                
                    
                
            
        
        
            	
                    Log in
                


        
    

    



            

        

    

    
        
            
                
                    
                        
    
        Search SpringerLink
        
            
            
                Search
                
                    
                
            
            
                
            
            
        

    




                    

                

            

        

    



        

    
        
            
                
                
                    
                        
                            Big data for corporate social responsibility: blockchain use in Gioia del Colle DOP
                        

                        
    
        
            
                Download PDF
                
            
        
    



                    

                

            

            
                
    
        
            
                Download PDF
                
            
        
    


            


            
                
    

            



            
                
                    
                        	Published: 21 January 2021



                        
                        Big data for corporate social responsibility: blockchain use in Gioia del Colle DOP

                        	Massimiliano Giacalone 
            ORCID: orcid.org/0000-0002-4284-520X1, 
	Vito Santarcangelo2, 
	Vincenzo Donvito3, 
	Oriana Schiavone3 & 
	Emilio Massa2 


                        
                            
    Quality & Quantity

                            (2021)Cite this article
                        

                        
    

                        
                            
    
        	
                    686 Accesses

                
	
                        15 Altmetric

                    
	
                Metrics details

            


    




                        

                            
    

    

                    
                


                
                    Abstract
The traceability of the supply chain with strict compliance with the specification to demonstrate in ""transparency"" the production processes in compliance with legislation and from a corporate social responsibility perspective, represents a fundamental requirement at the basis of competitive advantage in the food industries (Patelli and Mandrioli, J Food Sci 85: 3670–3678, 2020). The purpose of this work is to illustrate the innovative method for the certification and protection of the production phases of the DOP food chain and specifically the Mozzarella DOP of Gioia del Colle produced by the company Capurso Azienda Casearia Srl. This innovative approach consists of several phases that will be described in detail in the following paper. Besides, the idea of the introduction of Blockchain technology in an industry like this is an important step. This technology, associated with more accurate and intelligent management of the data acquisition process (Big data approach), optimizes the productivity of small businesses such as the dairy company. Blockchain technology guarantees security in the management of large amounts of data as never before possible, an innovative and experimental approach that makes the entire path of the production chain more controlled and optimized (Giacalone et al. International workshop on fuzzy logic and applications. Springer, Cham, pp. 218–225, 2016).



                    
    


                    

                    

                    
                        
                            DOP dairy products: Gioia del Colle’s mozzarella cheese
Dairy goodness has always been the flagship of the south of our peninsula, and around these realities, there is an important market of raw material suppliers.
However, preserving tradition and flavors in compliance with quality standards and regulations is a primary objective to protect the image and values of the dairy company's products, in fact, more and more often producers, who fail to guarantee high standards of their products, are made way into the market thanks to misleading brands that bring to the customer's mind high-quality names (Di Vita et al. 2013).
In this regard it comes to help the protected designation of origin, better known by the acronym DOP, denomination approved the mozzarella of Gioia del Colle; however, keeping track of the quality of the entire supply chain process to remain in compliance with the DOP denomination presents some problems. With the release of Legislative Decree 231/2017 DOP of Gioia Del Colle during the year 2017, there were no platforms in the state of the art that allowed rigorous management of the advanced tracking of the product chain as represented by the US7085777B2 patent.
The platforms present in the state of the art were guided data storage systems and did not have internal modules for the interconnection of the individual phases of the supply chain via IoT and artificial intelligence modules (expert systems to support decisions) aimed at respecting the constraints envisaged by the audits and for the control of the hygienic-sanitary and qualitative production process, also in compliance with Law 231/2017.
The company Capurso Azienda Dairy, therefore, tried to find a solution following the Six Sigma methodology (DMAIC approach) applied to the workflow of the nascent supply chain through the definition, design, and experimental development of an intelligent anti-evasion system for the management of the supply chain.
The paper is structured as follows. Paragraph 2 presents the problem of transporting food with greater attention to dairy products and presents the description of DOP products showing their peculiarities and characteristics. Section 3 presents the articles of the DOP regulation for Gioia del Colle mozzarella, the starting point for the implementation of the innovative system described in the fourth paragraph, as well as the possibility of continuous improvement of the entire production chain (DMAIC approach).
In paragraph 4 introduces the DEMAIC approach through the description of its five phases: define, measure, analyze, improve, and control. Then follows, in Sect. 5, the description of the anti-elusive approach based on temporal certification through blockchain stored thanks to Big Data and the implementation of a revolutionary dynamic tracking system based on DoA technology (data over audio) alternative to the based approach on radio frequencies. All this is the demonstration of an innovative approach strongly suited to the proof of compliance with the principles of social responsibility well expressed by the ISO26000 standard.
Section 6 explains the blockchain operating process, its application in the supply chain, and the benefits it brings.
Paragraph 7 follows the definition of the excellent applications of the blockchain method also as an anti-avoidance tool. Section 8 introduces the Gioiella Filiera application the cloud software developed by SME iInformatica S.r.l.s. Last paragraph offers some conclusive remarks and final considerations. 


DOP products: the food chain
According to article 2 paragraph 1 letter A of EU regulation 510/2006, by designation of origin we mean an agricultural or food product originating from a specific region whose peculiar characteristics and qualities are given exclusively by a particular geographical environment, including natural or anthropomorphic factors, and whose production takes place in the specified geographical area (Catanzaro and Licciardo 2006). It follows that the protected designation of origin (PDO, DOP in Italian) actually presents itself as a trademark of the legal protection of the denomination of a particular agricultural or food product, this trademark is attributed by the European Union based on certain qualitative characteristics (Belletti et al. 2007). For a product to be defined as a DOP, the stages of production, transformation, and processing must take place in a geographical area determined a priori and these stages must comply with strict rules established by a specific production specification and guaranteed by a specific control body (Germanò 2009).
Increasing globalization and a growing need for the world economy to carefully monitor production and transport for this specific category of products has led to the creation of rules and procedures aimed at protecting, during production, transport, and storage, which otherwise the characteristics of the products would vary, nullifying the work of the entire supply chain, compromising the product guarantee standards (Mancini et al. 2019).
Numerous ministerial decrees, over the years, have focused on the transport dynamics of particular fresh and perishable foods capable of altering their chemical-physical properties very easily if transported incorrectly, for example the DM 14/11/96 reports that fresh meat, after post-mortem inspection, can be transported not yet refrigerated provided that the duration of the transport does not exceed two hours and that this takes place with a refrigerated vehicle with sanitary authorization, and again the Presidential Decree 187/2001 regulates the transport of fresh pasta, stating that these must be stored, from production to sale, at temperatures no higher than 4° C with a tolerance of 3° C during transport and 2 °C in other cases; during transport from the place of production to the point of sale, they must be contained in packaging not intended for the final consumer, which ensures adequate protection from external agents and which bears the words ""fresh pasta to be sold loose"".
Stabilized pasta products (i.e. containing a moisture content of not less than 20%) allow transport and storage at room temperature, while pre-packaged fresh pasta must be stored, from production to sale, at a temperature not exceeding 4 °C, with a tolerance of 2 °C. Article 43 and following of Presidential Decree, 327/80 regulate the sanitary suitability and sanitary authorization provided for the means of transport, while the circular of 21 July 1998, n.64 relates to vehicles for specific transport under the controlled temperature and by vehicles for specific transport with a tank for the transport of food liquids. Ice creams fall within the scope of Presidential Decree 54/97 and they must have microbiological requirements as set out in Annex C, Chapter II of the aforementioned Presidential Decree.
The maximum temperature for the transport of pasteurized milk is set at + 6 °C, however, the veterinary service can grant an exception regarding door-to-door delivery and authorize a tolerance of 2 °C during delivery to retailers. On the other hand, as regards frozen food products, during transport, local distribution in the refrigerated cabinets and counters for sale, a temperature rise of 3 °C is tolerated for short periods (defrosting).
Particular attention is paid to the products of the dairy chain as they are subject to important Physico-chemical alterations that could occur if transported with poor standards of attention. These products, due to their composition, production, and original origin, have high deterioration alerts that can be avoided during the transport and storage phase, if specific procedures are implemented and different standards are observed.
The DPR n. 54 of 14 January 1997 is a regulation implementing Directives 92/46 and 92/47/EEC on the production of milk and milk-based products.
The aforementioned regulation establishes the health rules for the production and marketing of raw milk, heat-treated drinking milk, intended for the manufacture of milk-based products, and milk-based products intended for human consumption. Dairy products, defined as milk-based products, are identified in all those products deriving exclusively from milk with the possible addition of the substances necessary for their realization as long as they are not used to totally or partially replace any of the constituents of the milk itself and of which milk or a dairy product is an essential part.
Vehicle loading compartments and/or containers used for the transport of food products must be kept clean and must be regularly maintained to protect food products from sources of contamination; also, if necessary, they must be designed and built in such a way as to allow adequate cleaning and disinfection. Furthermore, they must not be used to transport any material other than food products if the latter may be contaminated. If the vehicles and/or containers are used for the transport of other goods in addition to food products or of different types of food products at the same time, the various products must be effectively separated, where necessary.
The legal literature argues that the temperature of the containers in which the dairy products must be transported must fall within the range 0 °C and + 4 °C; such is the temperature range that guarantees optimal transport standards for fresh dairy products. This temperature is naturally accompanied by correct sanitation and sanitation of both the containers and the staff. As for packaged aged cheese products, the transport temperature is generally dictated by the manufacturer's instructions as it varies according to the product itself.
It thus becomes even more important to scrupulously observe all the rules, not so much to avoid sanctions, but above all, because each member of the community must now assume their share of responsibility, legally and socially relevant, in a world where technical automatisms risk to the detriment of health (Iotti and Bonazzi 2014).


DOP chain for continuous improvements
At this juncture, it is necessary to use the DMAIC approach which is indispensable within the Six Sigma management program and especially in quality management. This approach is generally used for all improvement activities of a particular type of process. The DMAIC already contains within its acronym the definition of the same, in fact, if the acronym is broken down it is possible to derive the definition as well as the phases that represent it.
This process is composed by five phases: Define, Measure, Analyze, Improve, and Control (De Mast and Lokkerbol 2012). The five stages are strongly linked to each other and each of them describes an important step for quality management aimed at improving, optimizing, and stabilizing a particular organization process.
The first phase, or ""Define"", aims to identify a specific problem to be solved as well as the resources needed to achieve the goal. The second act, “Measure”, has the specific task of collecting information that can then be used as a reference to measure subsequent improvements; the “Analyze” phase analyzes the causes and origins of a given problem. The last two phases ""Improve"" and ""Control"" respectively have the objective of identifying and implementing a solution to the problem and monitoring improvements to be maintained over time. As anticipated, DMAIC is used within the Six Sigma, which is a quality management program, based on effective control and having the purpose of making any qualitative improvement to a product or service (Pyzdek and Keller 2003).
Using the DMAIC approach (Fig. 1) for the analysis of the supply chain workflow it is necessary first of all to define (""Define"" phase) the approach itself, rigorously considering the articles in the Mozzarella of Gioia del Colle specification. By reading them it is possible to deduce all the constraints to be respected to pursue the quality requirements and compliance with the product standard (“Measure” phase). It is particularly important to pay attention to some articles which show how evident the need is for technologies that allow you to keep track of the entire supply chain process to comply with the DOP denomination (""Analyze"" phase).
Fig. 1[image: figure1]Source: Own elaboration

Description of the DMAIC process. 


Full size image

To facilitate understanding of the context, the following is an extract of some articles of the specification:
ART. 2
The ""Mozzarella of Gioia del Colle"" is a fresh stretched curd cheese, obtained from raw whole cow's milk only, possibly thermalized or pasteurized, and is characterized by a production technology based on the use of native whey-graft.
Chemical composition (values on fresh product):
	
                  lactose ≤ 0.6%;

                
	
                  lactic acid ≥ 0.20%.

                

ART. 3
The area of production, milk processing, and packaging of ""Mozzarella of Gioia del Colle"" includes the administrative territory of the following municipalities in the province of Bari, in the province of Taranto, and part of the municipality of Matera in Basilicata.
ART. 5
The milk used to produce ""Mozzarella of Gioia del Colle"" comes from farms in which lactating cows must be reared in stables that require grazing, for at least 150 (one hundred and fifty) days per year, of monophyletic or polyphite autumn grasses. -spring, composed of leguminous essences (clover, vetch, field bean, and protein pea) and cereals (oats, barley, durum wheat, soft wheat, and ryegrass), or from natural pastures of wild herbs.
The livestock feed, whose milk is used in the production, consists of grass and/or hay of polyphite grass in a percentage of at least 60% of the total dry matter. The food ration also includes cereal concentrates (corn, barley, wheat, oats), legumes (soybeans, broad beans, field beans, protein peas), and their flours/flakes, as is or in the form of complementary feeds. And again, carob and by-products of cereal processing, such as bran and small wheat bran, durum wheat in a percentage of less than 40% of the dry matter. Finally, mineral and vitamin complexes as supplements.
Of these products intended for animal feed, in order not to compromise the qualitative characteristics of the product due to the link with the territory, no less than 60% must come from the geographical area defined in Article 3.
Dairy cows cannot be fed with foods that can transmit anomalous aromas and flavors to the milk, such as to alter its chemical-physical and organoleptic characteristics; foods that represent sources of contamination or in poor condition.
Starting from the analysis of the articles, the conception, design, and implementation of the system for the management of the DOP of Capurso Azienda Casearia Srl, described below, is therefore born.


Intelligent DOP management system
The system conceived and designed in 2017 by the company Capurso Azienda Casearia Srl is based on artificial intelligence for the management of the audit process of the DOP mozzarella, burrata, and stracciatella of Gioia del Colle supply chain.
The goal is to provide an effective tool both in the audit phase of the raw material production (cow's milk) and in the analysis and incoming phase of the raw material, in the production phase of the product, in the distribution of the finished product for waste management and tracking (Fandos and Flavian 2006).
In the context, the object of the invention is essential to use a system that allows the monitoring and control of the entire chain of DOP dairy products of Gioia del Colle, starting from the control of the internet of things.
This type of use of this technology has already been tested in the agro-food sector and to improve marketing intelligence for a better approach to costumer demand. A great representative of this type of research in today's literature is the article written by Werenowska to analyze the possibilities of using the digitization factor in the customer relationship process to create a better and more personalized offer (Werenowska 2020).
This system can be used by the milk producer, by the dairy company, by third-party auditors, and by the final consumer.
The system preliminarily provides for the management of the service through web-server infrastructure. A data processing unit is then set up, connected to the internet via a WIFI access point or internet gateway.
By data processing unit we mean a common computer in which the database is contained. The database contains data relating to the knowledge base (relationships) that regulate the supply chain process, the requirements of 231 compliance and the mandatory legislation, the objects of the Internet of Things (livestock and lots), the knowledge base of the equipped responder of artificial intelligence, evaluations, coordinates for global geolocation. The user can therefore access the web-server platform using any hand-held device, for example, a common smartphone or tablet, equipped with internet connectivity. It is also possible to access the contents of the platform by framing an identification code (eg QRCODE), associated with each dairy cow registered in the supply chain system, to be monitored in compliance with the requirements of the DOP mozzarella, burrata, and stracciatella of Gioia del Colle supply chain, also with a view to health and hygiene control and compliance with 231 and mandatory legislation.
As regards the 231 compliance model, it indicates an organization and management model indicates an organizational model adopted by a legal person, or association without legal personality, to prevent the criminal liability of entities (Previtali 2009). Its definition is mainly provided in Article 6 of Legislative Decree no. 231 of 8 June 2001, from which it, in turn, derives its name: 231. According to this legislative decree, the company is responsible for crimes committed in his interest or to his advantage both by persons who hold representative or administrative functions and by persons subject to the management or supervision of one of the persons in top positions. The company, on the other hand, is not liable if the persons indicated have acted in the exclusive interest of themselves or of third parties (Ielo 2006).
The sanctions provided for by law against the company as a result of the commission or attempted commission of the specific crimes are indicated in section II of the aforementioned decree and consist of pecuniary sanctions, disqualification sanctions, disqualification from exercising the activity, the prohibition to contract with the public administration, exclusion from concessions, loans, contributions or subsidies, prohibition to advertise goods or services, confiscation of the price or profit that the company has derived from the crime, publication of the sentence that can be ordered in the event of the application of a disqualification sanction (Giacalone et al. 2018b).
The sanction of the prohibition of the exercise of the activity, the prohibition of contracting with the public administration, and the prohibition of advertising goods or services, can be applied, in serious cases, even definitively. The legislative decree n. 231 defines the content of the organization and management models, providing that they must meet the following needs:
	
                Identify the activities in which crimes may be committed;

              
	
                Prepare specific protocols aimed at planning the formation and implementation of company decisions in relation to the crimes to be prevented;

              
	
                Identify methods for managing financial resources suitable for preventing the commission of such offenses;

              
	
                Provide information obligations towards the body responsible for supervising the operation and compliance with the organizational model;

              
	
                Introduce a disciplinary system suitable for sanctioning non-compliance with the measures indicated in the organizational model.

              

Liability is excluded if the company has adopted and effectively implemented an organization, management, and control model suitable for preventing certain crimes; it is appropriate, in any case, to specify that the assessment of responsibility takes place by verifying the existence of the predicate offense and the suitability review on the organizational models adopted.
Following this approach it is possible to summarize 231 compliance (Fig. 2) as the contribution of rules, policies, and ethical code using the certification of all the transactions (using for example Internet of things and Blockchain), monitoring KPI business parameters to reach and evidence of actions on corporate social responsibility. Following this approach, the system for Gioiella DOP has been developed.
Fig. 2[image: figure2]Source: Own elaboration

Explanatory image of 231 compliance tools for companies. 


Full size image

Access to the resources associated with the object of the Internet of Things can be done by all authorized users, in possession of devices with previous technologies and appropriate credentials.
Once logged into the platform, the user who owns the dairy cow can carry out the audit using a checklist, supported by multimedia content, relating to the process of the DOP mozzarella and stracciatella supply chain. The system checks livestock in real-time, by virtue of the checklist compiled over time. The system also allows you to trace the batches of milk produced, destroyed, and delivered in their management in the plant, and the production processes of DOP dairy products of Gioia del Colle. Utilizing intelligent packaging, the system also allows the geolocation of distributed dairy products to be managed to create a map of product diffusion in the world.
The entire system also uses an artificial intelligence engine that acts as a guide regarding supply chain processes, and also performs autoresponder operations. The system also makes it possible to create a communication channel with the staff of the dairy facility and to express evaluations concerning the services used. This system is highly valid for carrying out an automatic audit of the supply chain process using an expert system, and for reconstructing and verifying the entire supply chain process for third-party auditors (Asadzadeh et al. 2014).
In fact, the system lends itself to improving the process control of the supply chain, through timely intervention with the individual players involved into it.
$$CF = \mathop \sum \limits_{i = 0}^{m} \frac{{nc_{i} \times \delta }}{{a_{i} }} + \mathop \sum \limits_{j = 0}^{t} \frac{{nc_{j} \times \delta }}{{l_{j} }} + \mathop \sum \limits_{z = 0}^{q} \frac{{nc_{p} \times \delta }}{{pf_{z} }}$$

The system is therefore able to determine supply chain compliance (CF):
This level is a time function given by the sum of three contributions. The first contribution is given by the non-conformities (nc) of each farmer (i) according to the seriousness of the non-conformity (delta), considering the total number of livestock managed (a). The second contribution considers the non-conformities of the lots, given the number of lots.
The third considers the non-conformities of the finished products, considering the number of finished products (pf). The more this value tends to zero, the better the supply chain compliance will be. Each weight (delta) also maps the type of non-compliance if of the supply chain, mandatory, ancillary, relating to the 231 organizational models.
The delta parameter is a fuzzy concept that considers this coding: level 1 low, level 2 medium, level 3 high.
The high non-conformities (nc_i) are related to an error on food purchase notes or an error on the GPS location of livestock. These non-conformities (nc_i) are serious and can lead to the termination of a contractual relationship with a breeder.
The medium non-conformities (nc_i) are related to a discontinuous or inaccurate use of the app (for example on the incomplete recording of the checklist).
Considering the farmer case study for the first test of system using the digital application developed we have noticed that 75% of medium non-conformity (nc_i) were related to the wrong use of the User Interface, particularly related to a difficult approach for a farmer to use digital tools. With the second release of UI that considers the conformity of the group of head of cattles, the medium non-conformity level is dropped up to 25%. The following table (Table 1) summarizes the concepts shown before.
Table 1 Analysis of non-conformities on first and second UI of the system. Full size table

It is also possible to carry out trends and reports of this index over time, also monitoring the non-compliance index over time for each breeder, useful for monitoring and choosing the players in the supply chain.
Considering the lots, high non-conformities (nc_j) are related to an error on fiscal documents or errors on analysis reports on lots. These non-conformities (nc_i) are serious and can lead to the termination of a contractual relationship with a laboratory or employee.
The medium non-conformities (nc_i) are related to a discontinuous or inaccurate use of the app (for example on the incomplete recording of the checklist or delay in the upload of documents/reports).
Considering the first test of the system using the digital application developed we have noticed that 75% of non-conformity (nc_j) were of low type considering the good level of digitization of operators. Medium non-conformities (25%) were related to workflow problems.
Considering the finished products, high non-conformities (nc_p) are related to an error on storage and delivery. These non-conformities (nc_p) are serious and can lead to the termination of a contractual relationship with a carrier or employee.
The medium non-conformities (nc_p) are related to a discontinuous or inaccurate use of the app (for example on the incomplete recording of the tracking checklist or delay in the upload of documents/reports).
Considering the first test of the system using the digital application developed we have noticed that 90% of non-conformity (nc_j) were of low type considering the good tracking workflows implemented in the traditional distribution chain. Medium non-conformities (10%) were related to inexperienced users.


Livestock wellness, social responsibility and biocompatibility monitoring
Underlying the mission and values of the Capurso Azienda Dairy company, represented by Filippo Capurso, are the concept of ""animal welfare"" and that of Social Responsibility. CSR (Corporate Social Responsibility) or Corporate Social Responsibility (CSR), is by definition, anticipating the concept that will then be widely discussed and analyzed, ""The voluntary integration of the social and environmental concerns of companies into their commercial operations and relations with interested parties "".
CSR is not limited to simply respecting the laws but identifies a series of practices and behaviors that a company adopts autonomously and on a voluntary basis, in the belief of obtaining results that can bring benefits and advantages to itself and more generally to the context in which the company operates.
An efficient summary of all the literature on this topic can be found in Del Baldo's article, where both the main achievements in the sector and the criticisms of visions no longer suited to the everyday needs of industries and customers are exposed (Del Baldo 2015).
The goal is, therefore, to take particular care of the relationship with its stakeholders: collaborators, suppliers, customers, and partners, carrying out concrete actions for them. This takes shape in a company policy that can reconcile the economic objectives with the social and environmental objectives of the reference area, with a view to future sustainability (McWilliams et al. 2006).
Knowledge about the use of technologies such as blockchain in the CSR theme was also fundamental, especially in understanding what was the biggest obstacle encountered today and what to focus on this research; it is in fact demonstrated through text mining analysis that the most recurring problems are food waste and customer confidence in the use of products from large companies (Goloshchapova et al. 2019).
CSR is therefore the application of several specific pr";"""dc.publisher"",""Springer""
""og:image"",""https://media.springernature.com/w200/springer-static/cover/journal/11135.jpg""
""twitter:card"",""summary""
""og:site_name"",""Quality & Quantity""
""citation_reference"",""citation_journal_title=Qual. Quant.; citation_title=Energy sources choice and environmental sustainability disputes: an evolutional graph model approach; citation_author=S Ali, H Xu, AQ Al-amin, N Ahmad; citation_volume=53; citation_issue=2; citation_publication_date=2019; citation_pages=561-581; citation_doi=10.1007/s11135-018-0775-9; citation_id=CR1"",""Armani, AM., Hurt, DE., Hwang, D., McCarthy, MC., Scholtz, A.: Low-tech solutions for the COVID-19 supply chain crisis. Nat. Rev. Mater. 1–4 (2020)"",""citation_journal_title=Qual. Quant.; citation_title=Using frailty models to account for heterogeneity in multistage manufacturing and service processes; citation_author=S Asadzadeh, A Aghaie, H Shahriari; citation_volume=48; citation_issue=2; citation_publication_date=2014; citation_pages=593-604; citation_doi=10.1007/s11135-012-9789-x; citation_id=CR3"",""citation_journal_title=Crit. Sociol; citation_title=Corporate social responsibility: the good, the bad and the ugly; citation_author=SB Banerjee; citation_volume=34; citation_issue=1; citation_publication_date=2008; citation_pages=51-79; citation_doi=10.1177/0896920507084623; citation_id=CR5"",""Belletti, G., Burgassi, T., Manco, E., Marescotti, A., Pacciani, A., Scaramuzzi, S.: The impact of geographical indications (PDO and PGI) on the internationalization process of agro-food products. In 105th EAAE Seminar “International Marketing and International Trade of Quality Food Products”, Bologna, March (pp. 8–10) (2007)"",""citation_journal_title=Sustainability; citation_title=Overcoming the blockchain oracle problem in the traceability of non-fungible products; citation_author=G Caldarelli, C Rossignoli, A Zardini; citation_volume=12; citation_issue=6; citation_publication_date=2020; citation_pages=2391; citation_doi=10.3390/su12062391; citation_id=CR7"",""Catanzaro, F., Licciardo, F.: La riforma del Regolamento (CEE) n. 2081/92 sulla protezione delle indicazioni geografiche e delle denominazioni d’origine (2006)"",""citation_journal_title=Qual. Quant.; citation_title=Tourism competitiveness of Italian municipalities; citation_author=E Conti, L Grassini, C Monicolini; citation_volume=54; citation_publication_date=2019; citation_pages=1-23; citation_id=CR9"",""citation_journal_title=Appl. Innov.; citation_title=Blockchain technology: beyond bitcoin. ; citation_author=M Crosby, P Pattanayak, S Verma, V Kalyanaraman; citation_volume=2; citation_issue=6–10; citation_publication_date=2016; citation_pages=71; citation_id=CR10"",""citation_journal_title=Int. J. Prod. Econ.; citation_title=An analysis of the Six Sigma DMAIC method from the perspective of problem solving; citation_author=J Mast, J Lokkerbol; citation_volume=139; citation_issue=2; citation_publication_date=2012; citation_pages=604-614; citation_doi=10.1016/j.ijpe.2012.05.035; citation_id=CR29"",""citation_journal_title=Qual. Quant.; citation_title=Additive-tree representations of incomplete dissimilarity data; citation_author=G Soete; citation_volume=18; citation_issue=4; citation_publication_date=1984; citation_pages=387-393; citation_doi=10.1007/BF00227594; citation_id=CR42"",""citation_title=A state of the art of corporate social responsibility diffusion in Italy limits and potentials; citation_inbook_title=Corporate social responsibility in Europe; citation_publication_date=2015; citation_pages=435-468; citation_id=CR4; citation_author=M Baldo; citation_publisher=Springer"",""citation_journal_title=Agric. Econ. Rev.; citation_title=Quality perception of PDO extra-virgin olive oil: Which attributes most influence Italian consumers?; citation_author=G Vita, M D'Amico, G Via, E Caniglia; citation_volume=14; citation_publication_date=2013; citation_pages=46-58; citation_id=CR46"",""citation_journal_title=Appl. Sci.; citation_title=Blockchain in agriculture traceability systems: a review; citation_author=K Demestichas, N Peppes, T Alexakis, E Adamopoulou; citation_volume=10; citation_issue=12; citation_publication_date=2020; citation_pages=4113; citation_doi=10.3390/app10124113; citation_id=CR11"",""citation_title=Blockchain basics; citation_publication_date=2017; citation_id=CR12; citation_author=D Drescher; citation_publisher=Apress"",""citation_journal_title=Br. Food J.; citation_title=Intrinsic and extrinsic quality attributes, loyalty and buying intention: an analysis for a PDO product; citation_author=C Fandos, C Flavian; citation_volume=108; citation_publication_date=2006; citation_pages=646-662; citation_doi=10.1108/00070700610682337; citation_id=CR13"",""citation_journal_title=J. Clean. Prod.; citation_title=Applying blockchain technology to improve agri-food traceability: a review of development methods, benefits and challenges; citation_author=H Feng, X Wang, Y Duan, J Zhang, X Zhang; citation_volume=260; citation_publication_date=2020; citation_pages=121031; citation_doi=10.1016/j.jclepro.2020.121031; citation_id=CR14"",""Germanò, A.: Le politiche europee della qualità alimentare. Rivista di diritto alimentare, (3) (2009)"",""Giacalone, M., Buondonno, A., Romano, A., & Santarcangelo, V. (2016). Innovative methods for the development of a notoriety system. In International Workshop on Fuzzy Logic and Applications, pp. 218–225. Springer, Cham"",""citation_journal_title=Inf. Sci.; citation_title=Big data and forensics: an innovative approach for a predictable jurisprudence; citation_author=M Giacalone, C Cusatelli, A Romano, A Buondonno, V Santarcangelo; citation_volume=426; citation_publication_date=2018; citation_pages=160-170; citation_doi=10.1016/j.ins.2017.10.036; citation_id=CR16"",""citation_journal_title=Big Data Res.; citation_title=Big data compliance for innovative clinical models; citation_author=M Giacalone, C Cusatelli, V Santarcangelo; citation_volume=12; citation_publication_date=2018; citation_pages=35-40; citation_doi=10.1016/j.bdr.2018.02.001; citation_id=CR17"",""Giacalone, M., Scippacercola, S.: Big data: issues and an overview in some strategic sectors. J. Appl. Quant Methods, 11(3) (2016)"",""Giacalone, M., Sinitò, D.C., Massa, E., Oddo, F., Medda, E., Santarcangelo, V.: Blockchain as a universal tool for business improvement. SIS 2019 Smart Statistics for Smart Applications. Proceedings of the Conference of the Italian Statistical Society. Book of Short Paper (2019)"",""citation_journal_title=Eur. J. Financ.; citation_title=Corporate social responsibility reports: topic analysis and big data approach; citation_author=I Goloshchapova, SH Poon, M Pritchard, P Reed; citation_volume=25; citation_issue=17; citation_publication_date=2019; citation_pages=1637-1654; citation_doi=10.1080/1351847X.2019.1572637; citation_id=CR21"",""citation_journal_title=J. Bus. Res.; citation_title=The impact of Covid-19 pandemic on corporate social responsibility and marketing philosophy; citation_author=H He, L Harris; citation_volume=116; citation_publication_date=2020; citation_pages=176-182; citation_doi=10.1016/j.jbusres.2020.05.030; citation_id=CR22"",""citation_journal_title=J. Prod. Brand Manag.; citation_title=Consequences of consumer trust in PDO food products: the role of familiarity; citation_author=CF Herrera, CF Blanco; citation_volume=20; citation_issue=4; citation_publication_date=2011; citation_pages=282-296; citation_doi=10.1108/10610421111148306; citation_id=CR23"",""Ielo, P. (2006). Compliance Programs: natura e funzione nel sistema della responsabilità degli enti. Modelli organizzativi e D. Lgs. 231/2001. La responsabilità amministrativa delle società e degli enti, 1, 99"",""citation_journal_title=Am. J. Appl. Sci.; citation_title=The application of life cycle cost (LCC) approach to quality food production: a comparative analysis in the parma PDO ham sector; citation_author=M Iotti, G Bonazzi; citation_volume=11; citation_issue=9; citation_publication_date=2014; citation_pages=1492; citation_doi=10.3844/ajassp.2014.1492.1506; citation_id=CR25"",""citation_journal_title=Int. J. Integr. Supply Manag.; citation_title=Coronavirus (COVID-19/SARS-CoV-2) and supply chain resilience: a research note; citation_author=D Ivanov, A Das; citation_volume=13; citation_issue=1; citation_publication_date=2020; citation_pages=90-102; citation_doi=10.1504/IJISM.2020.107780; citation_id=CR26"",""citation_journal_title=Int. J. Prod. Res.; citation_title=Viability of intertwined supply networks: extending the supply chain resilience angles towards survivability. A position paper motivated by COVID-19 outbreak; citation_author=D Ivanov, A Dolgui; citation_volume=58; citation_issue=10; citation_publication_date=2020; citation_pages=2904-2915; citation_doi=10.1080/00207543.2020.1750727; citation_id=CR27"",""citation_journal_title=Sustainability; citation_title=Producers’ and consumers’ perception of the sustainability of short food supply chains: the case of Parmigiano Reggiano PDO; citation_author=MC Mancini, D Menozzi, M Donati, B Biasini, M Veneziani, F Arfini; citation_volume=11; citation_issue=3; citation_publication_date=2019; citation_pages=721; citation_doi=10.3390/su11030721; citation_id=CR28"",""citation_journal_title=J. Manag. Stud.; citation_title=Corporate social responsibility: strategic implications; citation_author=A McWilliams, DS Siegel, PM Wright; citation_volume=43; citation_issue=1; citation_publication_date=2006; citation_pages=1-18; citation_doi=10.1111/j.1467-6486.2006.00580.x; citation_id=CR30"",""citation_journal_title=J. Serv. Manag.; citation_title=A transformative supply chain response to COVID-19; citation_author=DA Mollenkopf, LK Ozanne, HJ Stolze; citation_publication_date=2020; citation_doi=10.1108/JOSM-05-2020-0143; citation_id=CR31"",""citation_journal_title=Bus. Inf. Syst. Eng.; citation_title=Blockchain; citation_author=M Nofer, P Gomber, O Hinz, D Schiereck; citation_volume=59; citation_issue=3; citation_publication_date=2017; citation_pages=183-187; citation_doi=10.1007/s12599-017-0467-3; citation_id=CR32"",""citation_journal_title=Qual. Quant; citation_title=Assessment of blockchain applications in travel and tourism industry; citation_author=AI Ozdemir, IM Ar, I Erol; citation_volume=54; citation_publication_date=2019; citation_pages=1-15; citation_id=CR33"",""citation_journal_title=J. Food Sci.; citation_title=Blockchain technology and traceability in the agrifood industry; citation_author=N Patelli, M Mandrioli; citation_volume=85; citation_issue=11; citation_publication_date=2020; citation_pages=3670-3678; citation_doi=10.1111/1750-3841.15477; citation_id=CR34"",""Previtali, P. (2009). Modelli organizzativi e compliance aziendale. L'applicazione del D. Lgs. 231/2001 nelle imprese italiane (Vol. 57). Giuffrè Editore"",""citation_title=The six sigma; citation_publication_date=2003; citation_id=CR36; citation_author=T Pyzdek; citation_author=P Keller; citation_publisher=McGraw-Hill"",""citation_journal_title=Future Internet; citation_title=Leveraging the internet of things and blockchain technology in supply chain management; citation_author=A Rejeb, JG Keogh, H Treiblmaier; citation_volume=11; citation_issue=7; citation_publication_date=2019; citation_pages=161; citation_doi=10.3390/fi11070161; citation_id=CR37"",""citation_journal_title=Trends Food Sci. Technol.; citation_title=Safety of foods, food supply chain and environment within the COVID-19 pandemic; citation_author=M Rizou, IM Galanakis, TM Aldawoud, CM Galanakis; citation_volume=102; citation_publication_date=2020; citation_pages=293-299; citation_doi=10.1016/j.tifs.2020.06.008; citation_id=CR38"",""citation_title=The Sentiment of the infosphere: a sentiment analysis approach for the big conversation on the net; citation_inbook_title=Data science and social research; citation_publication_date=2017; citation_pages=215-222; citation_id=CR39; citation_author=A Ruoto; citation_author=V Santarcangelo; citation_author=D Liga; citation_author=G Oddo; citation_author=M Giacalone; citation_author=E Iorio; citation_publisher=Springer"",""citation_journal_title=Int. J. Prod Res; citation_title=Impact of COVID-19 on logistics systems and disruptions in food supply chain; citation_author=S Singh, R Kumar, R Panchal, MK Tiwari; citation_publication_date=2020; citation_doi=10.1080/00207543.2020.1792000; citation_id=CR40"",""citation_journal_title=ZENITH Int. J. Bus. Econ. Manag. Res.; citation_title=Corporate social responsibility in India; citation_author=S Sinha, AK Panda; citation_volume=8; citation_issue=4; citation_publication_date=2018; citation_pages=97-106; citation_id=CR41"",""citation_journal_title=Comput. Ind.; citation_title=Orchestrating product provenance story: when IOTA ecosystem meets electronics supply chain space; citation_author=S Suhail, R Hussain, A Khan, CS Hong; citation_volume=123; citation_publication_date=2020; citation_pages=103334; citation_doi=10.1016/j.compind.2020.103334; citation_id=CR43"",""citation_journal_title=Qual. Quant.; citation_title=Food risk communication: analysis of the media coverage of food risk on Italian online daily newspapers; citation_author=B Tiozzo, A Pinto, F Neresini, S Sbalchiero, N Parise, M Ruzza, L Ravarotto; citation_volume=53; citation_issue=6; citation_publication_date=2019; citation_pages=2843-2866; citation_doi=10.1007/s11135-019-00897-3; citation_id=CR44"",""Visser, W.: Corporate social responsibility in developing countries. In: Crane, A., McWilliams, A., Matten, D., Moon, J., Siegel, D.S. (eds.) The Oxford Handbook of Corporate Social Responsibility. Oxford University Press (2008)"",""citation_journal_title=Qual. Quant.; citation_title=Blockchain, bank credit and SME financing; citation_author=R Wang, Z Lin, H Luo; citation_volume=53; citation_issue=3; citation_publication_date=2019; citation_pages=1127-1140; citation_doi=10.1007/s11135-018-0806-6; citation_id=CR47"",""citation_journal_title=China Agric. Econ. Rev.; citation_title=COVID-19, supply chain disruption and China’s hog market: a dynamic analysis; citation_author=Y Wang, J Wang, X Wang; citation_volume=12; citation_publication_date=2020; citation_pages=427-443; citation_doi=10.1108/CAER-04-2020-0053; citation_id=CR48"",""citation_title=Big data as a key aspect of customer relationship management: an example of the restaurant industry; citation_inbook_title=Management in the era of big data: issues and challenges; citation_publication_date=2020; citation_pages=153; citation_id=CR49; citation_author=A Werenowska; citation_publisher=Auerbach Publications""
""citation_journal_title"",""Quality & Quantity""
""language"",""en""
""og:description"",""The traceability of the supply chain with strict compliance with the specification to demonstrate in """"transparency"""" the production processes in compliance with legislation and from a corporate social responsibility perspective, represents a fundamental requirement at the basis of competitive advantage in the food industries (Patelli and Mandrioli, J Food Sci 85: 3670–3678, 2020). The purpose of this work is to illustrate the innovative method for the certification and protection of the production phases of the DOP food chain and specifically the Mozzarella DOP of Gioia del Colle produced by the company Capurso Azienda Casearia Srl. This innovative approach consists of several phases that will be described in detail in the following paper. Besides, the idea of the introduction of Blockchain technology in an industry like this is an important step. This technology, associated with more accurate and intelligent management of the data acquisition process (Big data approach), optimizes the productivity of small businesses such as the dairy company. Blockchain technology guarantees security in the management of large amounts of data as never before possible, an innovative and experimental approach that makes the entire path of the production chain more controlled and optimized (Giacalone et al. International workshop on fuzzy logic and applications. Springer, Cham, pp. 218–225, 2016).""
""prism.issn"",""1573-7845""
""citation_author_email"",""massimiliano.giacalone@unina.it"",""vito@iinformatica.it"",""info@gioiellalatticini.it"",""emilio@iinformatica.it""
""twitter:image:alt"",""Content cover image""
""citation_issn"",""1573-7845""
""citation_language"",""en""
""dc:title"",""Big data for corporate social responsibility: blockchain use in Gioia del Colle DOP | SpringerLink""
""Content-Encoding"",""UTF-8""
""citation_pdf_url"",""https://link.springer.com/content/pdf/10.1007/s11135-021-01095-w.pdf""
""citation_lastpage"",""27""
""DOI"",""10.1007/s11135-021-01095-w""
""citation_fulltext_world_readable"",""""
""citation_journal_abbrev"",""Qual Quant""
""prism.rightsAgent"",""journalpermissions@springernature.com""
""citation_author"",""Massimiliano Giacalone"",""Vito Santarcangelo"",""Vincenzo Donvito"",""Oriana Schiavone"",""Emilio Massa""
""resourceName"",""s11135-021-01095-w""
""dc.date"",""2021-01-21""
""citation_springer_api_url"",""http://api.springer.com/metadata/pam?q=doi:10.1007/s11135-021-01095-w&api_key=""
""prism.publicationName"",""Quality & Quantity""
""citation_doi"",""10.1007/s11135-021-01095-w""
""dc.title"",""Big data for corporate social responsibility: blockchain use in Gioia del Colle DOP""
""prism.url"",""https://link.springer.com/article/10.1007/s11135-021-01095-w""
""dc.language"",""En""
""Content-Language"",""en""
""format-detection"",""telephone=no""
""prism.endingPage"",""27""
""citation_title"",""Big data for corporate social responsibility: blockchain use in Gioia del Colle DOP""
""citation_author_institution"",""Department of Economics and Statistics, University of Naples Federico II, Naples, Italy"",""iInformatica S.r.l.s., Trapani, Italy"",""Capurso Azienda Casearia Srl, Bari, Italy"",""Capurso Azienda Casearia Srl, Bari, Italy"",""iInformatica S.r.l.s., Trapani, Italy""
""access"",""Yes""
""citation_publisher"",""Springer Netherlands""
""applicable-device"",""pc,mobile""
""dc.format"",""text/html""
""description"",""The traceability of the supply chain with strict compliance with the specification to demonstrate in """"transparency"""" the production processes in c""
""title"",""Big data for corporate social responsibility: blockchain use in Gioia del Colle DOP | SpringerLink""
""citation_online_date"",""2021/01/21""
""twitter:site"",""@SpringerLink""
""dc.source"",""Quality & Quantity 2021""
""dc.type"",""OriginalPaper""
""dc.copyright"",""2021 The Author(s), under exclusive licence to Springer Nature B.V. part of Springer Nature""
""dc.creator"",""Massimiliano Giacalone"",""Vito Santarcangelo"",""Vincenzo Donvito"",""Oriana Schiavone"",""Emilio Massa""
""citation_fulltext_html_url"",""https://link.springer.com/article/10.1007/s11135-021-01095-w""
""prism.publicationDate"",""2021-01-21""
""Content-Type"",""text/html; charset=UTF-8""
""journal_id"",""11135""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""dc.description"",""The traceability of the supply chain with strict compliance with the specification to demonstrate in """"transparency"""" the production processes in compliance with legislation and from a corporate social responsibility perspective, represents a fundamental requirement at the basis of competitive advantage in the food industries (Patelli and Mandrioli, J Food Sci 85: 3670–3678, 2020). The purpose of this work is to illustrate the innovative method for the certification and protection of the production phases of the DOP food chain and specifically the Mozzarella DOP of Gioia del Colle produced by the company Capurso Azienda Casearia Srl. This innovative approach consists of several phases that will be described in detail in the following paper. Besides, the idea of the introduction of Blockchain technology in an industry like this is an important step. This technology, associated with more accurate and intelligent management of the data acquisition process (Big data approach), optimizes the productivity of small businesses such as the dairy company. Blockchain technology guarantees security in the management of large amounts of data as never before possible, an innovative and experimental approach that makes the entire path of the production chain more controlled and optimized (Giacalone et al. International workshop on fuzzy logic and applications. Springer, Cham, pp. 218–225, 2016).""
""og:type"",""article""
""citation_article_type"",""Article""
""og:title"",""Big data for corporate social responsibility: blockchain use in Gioia del Colle DOP""
""prism.doi"",""doi:10.1007/s11135-021-01095-w""
""X-UA-Compatible"",""IE=edge""
""citation_firstpage"",""1""
""prism.startingPage"",""1""
""viewport"",""width=device-width, initial-scale=1""
""dc.rightsAgent"",""journalpermissions@springernature.com""
""prism.section"",""OriginalPaper""
""dc.identifier"",""doi:10.1007/s11135-021-01095-w""
""dc.subject"",""Methodology of the Social Sciences"",""Social Sciences, general""
""og:url"",""https://link.springer.com/article/10.1007/s11135-021-01095-w""
""prism.copyright"",""2021 The Author(s), under exclusive licence to Springer Nature B.V. part of Springer Nature""
";https://scholar.google.ch/scholar?start=70&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2021
1619099133-476;https://scholar.google.ch/scholar?as_ylo=2021&q=oracles+blockchain&hl=fr&as_sdt=0,5;SpyChain: A Lightweight Blockchain for Authentication and Anonymous Authorization in IoD;N Andola, VK Yadav, S Venkatesan, S Verma ; Wireless Personal …, 2021  Springer;;"… SpyChain: A Lightweight Blockchain for Authentication and Anonymous Authorization in IoD.

Download PDF. Download PDF. Published: 26 February 2021. SpyChain: A Lightweight

Blockchain for Authentication and Anonymous Authorization in IoD … Need for Blockchain …";;null;null;;;;https://scholar.google.ch/scholar?start=60&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2021
1619099115-429;https://scholar.google.ch/scholar?as_ylo=2021&q=oracles+blockchain&hl=fr&as_sdt=0,5;Verifiable random oracles;LPDJ Müller;Quade  crypto.iti.kit.edu;;"Page 1. Institut für Theoretische Informatik Lehrstuhl Prof. Dr. J. Müller-Quade

crypto.iti.kit.edu Verifiable random oracles Master's Thesis The random oracle model

(ROM) is a widely used in heuristic in practice. But replacing …";;;null;;;;https://scholar.google.ch/scholar?start=20&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2021
1619099115-432;https://scholar.google.ch/scholar?as_ylo=2021&q=oracles+blockchain&hl=fr&as_sdt=0,5;Blockchain and Smart Contract: A Review;H Subramanian, R Liu ; igiglobal.com;;"… are used to determine optimum size of the network that can be served by an oracle with varying …

Meanwhile, important consequences and challenges of incorporating oracles in trusted distributed

ledger environments are presented … (2020) discuss blockchain regulations and …";;null;null;;;;https://scholar.google.ch/scholar?start=20&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2021
1619099107-414;https://scholar.google.ch/scholar?as_ylo=2021&q=oracles+blockchain&hl=fr&as_sdt=0,5;[PDF][PDF] A NOVEL BLOCKCHAIN BASED MODEL PROVIDING QUALITY VERIFICATION FOR CLOUD PROVIDERS;N Siva Bharathi, P Ragamaliga, K Sasirekha… ; irjmets.com;;"… In the blockchain environment, oracles are systems that provide information coming from the

real world to blockchain … In the real world the information coming from a third-party univocal source

whose reliability is unchallenged for all nodes: the oracle[6].In our proposed …";;;[PDF] irjmets.com;https://irjmets.com/rootaccess/forms/uploads/IRJMETS564927.pdf;"
                                                                                                     e-ISSN: 2582-5208 
International Research Journal of Modernization in Engineering Technology and Science 

 Volume:03/Issue:03/March-2021            Impact Factor- 5.354                                     www.irjmets.com                                                                                                                                                                                                                                                                                         

www.irjmets.com                              @International Research Journal of Modernization in Engineering, Technology and Science 

 [1820] 

A NOVEL BLOCKCHAIN BASED MODEL PROVIDING QUALITY 

VERIFICATION FOR CLOUD PROVIDERS 

Siva Bharathi N*1, Ragamaliga P*2, Sasirekha K*3, Saranya P*4, Karthika K*5 

*1,2,3,4UG Student, Department of Computer Science and Engineering, Anjalai Ammal Mahalingam 

Engineering College, Thiruvarur, Tamil Nadu, India 

*5Assistant Professor, Department of Computer Science and Engineering, Anjalai Ammal Mahalingam 

Engineering College, Thiruvarur, Tamil Nadu, India 

ABSTRACT 

This paper introduces a novel blockchain-based decentralized federation model that embodies quality 

verification for cloud providers and visualizes the URL from which the DDoS attack (Distributed denial-of-

service attack) originated. A cloud provider can't prevent all information (data) threats, whereas the cloud 

developers have to apply effective encryption techniques to ensure the integrity of information (data). Our 

proposed model has a single trusted oracle to perform the verification. The blockchain is a fully distributed 

structure which provides transparent administration by involving agents. To maximize the profit and optimizes 

the cost of using a third party (i.e., oracle) we propose to use stackelberg differential game. DDoS is a cloud-

specific attack in which the attack source is always more than one; multiple machines attack a user by sending 

packets with large data overhead. Such attacks make the resources unavailable to the user by immense the 

network with unwanted traffic. This paper  propose to find out the attacker and block the site from which the 

attack is made and recovery attacked URL without down the server. 

Keywords: Smart contracts, quality verification, Stackelberg differential game, DDos attack, blockchain, 

Distributed Denial of Service (DDoS) 

I. INTRODUCTION 

         SLA acts as a future foundation for supplying and keep track of services in cloud computing. Service level 

agreement (SLA) is to assure the maximum availability of services for customers with the most part of cloud 

system. The provider has to pay penalties with a violation of service level agreement. The classification task 

becomes more challenging, since the SLA violations are the infrequent event in the real world (~0.2 %). To 

alleviate the issue of unutilized and over provisioned computing assets, to maximize their profit and provide 

guaranteed Quality of Services (QoS), the cloud providers scaled their pool of resources by forming cloud 

federation [1]. In order to overcome the restrictions of the traditional federations, a new distributed 

blockchain[1]based framework to support interoperability and coopetition (i.e., cooperative competition) was 

proposed by the Cloudchain [2]  among the cloud providers. 

         To increase the transparency, visibility and reliance within its decentralized agreements we utilize smart 

contract in blockchain enabled cloud chain deployed on top of Ethereum using remix IDE. The third-party 

services like Blockchain oracles that provides the smart contracts with external information. They are the 

connections between the blockchains and the outside world. The off-chain data (data that is outside of the 

network) that cannot access blockchains and smart contracts. However, for many contractual agreements, it is 

vital to have applicable information from the exterior world to execute the agreement. This is where blockchain 

oracles come into play. It provides a link in the middle of off-chain and on-chain data. They broaden the scope 

in which smart contracts can operate because the oracles are vital within the blockchain ecosystem. Without 

Blockchain Oracles, smart contracts will have very little use as they will only access data from their networks. It 

is essential to note that a blockchain oracle is not the data source itself, but rather layer that queries, verifies, 

and authenticates external data sources and then relays that information. Oracles transmitted the data in many 

forms like – price appraise, the successful execution of a payment, or a sensor measures the temperature. Call 

the data from the exterior world, implement the smart contract and need to spend network resources. Some 

oracles not only transmit information to smart contracts deployed on blockchain but also send it to the external 

resources. 

         Our proposed model incoprates five different agents, namely the cloud service provider (provider agent 

(PA)), oracle (agent (VA)), cloud service requester (requester agent (RA)), and two smart contract agents called 

http://www.irjmets.com/


                                                                                                     e-ISSN: 2582-5208 
International Research Journal of Modernization in Engineering Technology and Science 

 Volume:03/Issue:03/March-2021            Impact Factor- 5.354                                     www.irjmets.com                                                                                                                                                                                                                                                                                         

www.irjmets.com                              @International Research Journal of Modernization in Engineering, Technology and Science 

 [1821] 

contract agents and registry-profile. These contracts are set-down in blockchain using registry-profile agent 

and are provoked by new transactions. In our situation, R.A. Creates a contract with the PA and can initiate a 

quality monitoring request from the VA at any time.VA can check the quality of service with respect to different 

attributes (e.g., availability, bandwidth, response time, etc.) and detects any misbehavior of RA or PA, then 

returns the result to the contract agent to manage the payments and apply potential punishments. Accordingly, 

the contract agent decides who should pay the monitoring cost to VA [1]. 

         Yet some important questions remain: how many times and when to ask for quality monitoring, who has to 

pay for such a service, how much should be paid and how to avoid SLA violations and its possible consequences. 

To answer the above questions and to optimize the providers’ computational resource capacity, quality 

verification requests and cost of the monitoring, we formulate a dynamic Stackelberg differential game among 

three agents seeking to maximize their revenue [1]. The basic idea of Stackelberg is that a player (leader) has 

the right to make the first move, thanks to its historical priority, size, reputation, innovation, information and 

more. Then, the other player (referred to as the follower), the less powerful it is, looks at the leader's strategy 

and decides its own things accordingly. In Stackelberg game where primary users, denoted as leaders, decide 

about the slot of bandwidth to be used for direct transmission as well as the set of secondary users they want to 

collaborate with. The secondary users, acting as followers, decide about the payment to make under the pre-

decided bandwidth slot With the goal of increasing the transfer rate without incurring large fee[3]. It is a 

Distributed Denial of Service. We can hit the DDoS attacks if we have the enough resources. But the peer to peer 

and client-server system don’t have the sufficient resources to beat them. Dynamic resource allocation plan of 

action is used to token the DDoS attacks. However cloud is still vulnerable to various attacks because cloud 

platform still runs its services in a traditional manner. To prevent DDoS attacks, filtration of attack packets is 

needed. Dynamic allocation should be done to employ the idle resources to cloud users and guarantee them 

with quality of service [4]. The most basic and effective DDoS attack strategy is to flood the network with the 

attack packets. DDoS attacks have always been a threat to individual cloud customers as they have fewer 

resources to beat such attacks.  

II. BACKGROUND 

It is essential to monitor the QoS and ensure that the conditions of SLA are met for a blockchain based 

federation. This verification is highly advantageous in view of the multi-tenancy characteristic of the services of 

cloud. In this context, to scale the economic benefits and optimize resource utilization, multiple Virtual 

Machines (VMs) are initiated on the same physical server simultaneously. The performance variation depends 

on the network load and usage peak from other tenants. Cloud providers try to balance the workloads and 

achieve the required performance with less conserved capacity, yet they might not be able to supply a 

consistent performance [1]. The payment for the services will be provided by the cloud service consumer for 

the utilization of resources. Based on the utilization of the resources, price will be modified accordingly 

(see Figure 2.1). 

 
Figure 2.1: Payment for services 

         Let us imagine cloud providers A and B are using cloudchain. First of all cloud providers register 

themselves in cloudchain. When any of the two cloud providers A or B faces a deficiency in computing 

resources, it can create a request through cloudchain. For example B faces a deficiency to encounter its end 

users' demand, it creates a request and provider A accepts the request and leases its resources to B within the 

smart contract deployed over blockchain with a specified SLA, price, terms, and conditions. We have to 

concentrate on the two issues where the cloudchain can’t handle on its own. First, provider A has to observe the 

http://www.irjmets.com/


                                                                                                     e-ISSN: 2582-5208 
International Research Journal of Modernization in Engineering Technology and Science 

 Volume:03/Issue:03/March-2021            Impact Factor- 5.354                                     www.irjmets.com                                                                                                                                                                                                                                                                                         

www.irjmets.com                              @International Research Journal of Modernization in Engineering, Technology and Science 

 [1822] 

stated SLA in the contract, but provider B wrongly claims that the provider A has violated the SLA and has to be 

punished with fine. Cloudchain is unable to communicate with the outside world of the blockchain network. 

Blockchain can only access information present in a transaction or the transaction history of the blockchain. 

Thus, we bring out oracle as a third party to perform the verification and confirm if the SLA is met. The second 

issue can arise when provider A has compromised the quality but denies the accusation and requests to receive 

the full deposit from provider B. Cloudchain calls the oracle and initiates a verification request. The oracle 

confirms that a violation has happened. At last, cloudchain distributes the money and charges the verification 

cost by considering the verification report from the oracle. 

         In addition to this, our proposed model concentrates on the security of the system. A decentralized private 

blockchain can be used for setting flow rules for fog nodes acting as SDN controllers and other devices in the 

network. Blockchain enables users to return to the previous flow rules or blocks as soon as the users finds the 

malfunctioning flow rules in the network [5]. Blockchain has come out as a truthful partner, leveraging its 

fundamental characteristics of internal and external trustless attitude, integrity, immutability, decentralization, 

verifiability, and anonymity to tackle DDoS attacks. The system architecture of our proposed model is 

illustrated in figure 2.2. 

 

Figure 2.2: System Architecture 

III. METHODOLOGY 

This section will describe the proposed modules for quality monitoring systems and the mitigation of DDoS 

attacks in the blockchain. 

3.1 Service Agreements Within Multiagent Model 

         Our proposed model has a multiagent structure, which allows us to introduce a quality verifier agent to 

ensure the cloud provider's compliance with the SLA. SLA involves five different agent the cloud service 

requester (requester agent (RA)), cloud service provider (provider agent (PA)), oracle (verifier agent (VA)), and 

two smart contract agents called a registry-profile agent (RPA) and contrast agents (CA).  Service level 

Agreement should be supported by formal assurances, ranking and verification of various service deployment 

options. This work introduces a novel Smart Contract (SC) based architecture that provides for SLA among 

relevant entities and computing environment namely Cloud service consumers and Cloud providers. It is 

embedded in computer code can be managed by a blockchain. The source code contains a set of rule and 

procedure under which the parties of that smart contract agree to interact with each other. If the predefined 

rules are satisfied then the agreement is enforced or otherwise, the agreement is remitted. Smart Contract is 

between two parties like Requester and provider, where they provide the mechanism for efficiently managing 

tokenized assets and access to them. Oracle plays a vital role among them, where it injects data that is relevant 

to the smart contract from the on-chain world into the smart contract information store. If the implementation 

is correctly held, then the smart contracts could provide transaction security superior to traditional contract 

http://www.irjmets.com/


                                                                                                     e-ISSN: 2582-5208 
International Research Journal of Modernization in Engineering Technology and Science 

 Volume:03/Issue:03/March-2021            Impact Factor- 5.354                                     www.irjmets.com                                                                                                                                                                                                                                                                                         

www.irjmets.com                              @International Research Journal of Modernization in Engineering, Technology and Science 

 [1823] 

law, thereby reducing coordination costs of auditing and enforcement of such agreements. Smart contract 

transaction cost is low of reaching an agreement by their magnitude, specially they reduce the costs of reaching 

an agreement, formalization, and enforcement. 

         Contract 1(C1) or Cloud chain Registry (CCR) is a global contract that maps cloud providers identification 

values including Name, Reputation Value, Computing Capacity, and Storage Capacity to their contract. The 

reputation values can be calculated from the customer rating given to each provider through online rating 

platforms. Schemes coded into the contract can regulate recording new providers or changing the mapping of 

the existing ones the cloud service provider registration can be cramped only to certified providers. It also 

maps identified Cloud chain Contract (CCC) address on the blockchain, where a special contract concerning 

each provider and services are recorded. 

         Contract 2 (C2) or Cloud chain Profile (CCP) It holds a list of reference to Cloud chain Contract, 

representing all the participants' previous and current contract with other nodes in the system. Providers 

should register their requests in this contract. Each transaction list stores a status variable. CCP also executes a 

functionality to permit provider notifications. This contract is essential as it stock the address of every  latest 

CCC contracts, without this contract cloud chain will lose the track of all contracts. If the transaction is newly 

established, awaiting pending updates and has or has not been completed. 

         Contract 3(C3) or Cloud chain Contract (CCC). It initiate between two nodes in the system. One node 

accepts and provides the requested service for the other node. After contract is completed or cancelled, the 

contract balance is transferred to the supplier [2]. 
 

3.1.1 Multiagent Architecture of the Cloud Service Distributed Model 

The proposed model incorporates five agents as follows  

A. Requester Agent and Provider Agent (PA)  

         Both are Requester agent and Provider agent willing to trade their computing resources. Requester makes 

a request and pays the initial deposit and the Provider agent provides a service to request one. 

B. The Registry-Profile Agent (RPA) and Contract  Agent (CA)  

         In CCR-CCP and CCC smart contracts, respectively, with a set of executable function and variables. RA and 

PA should register themselves in RPA where each registered user is assigned with a public key pair. PA maps 

identities of RA and PA to the contract agent’s (CA) address on the blockchain with a record of any SLA violation 

or compliance. When RA faces a computing resources deficiency, it submits a request for a service using RPA to 

create and deploy a CA in the blockchain. Meanwhile, providers are set by the requesters to ensure that 

qualified providers  to receive the  contract  task. The first-time reputation values are will be updated based on 

the future ratings given by RA. CA regulates the interactions between two nodes in the system where one node 

accepts and provides the requested service to the other RA is paid the deposit in advance and it is stored in the 

smart contract using CA. Once completed or cancelled, CA calculates fines to be charged if any exist and the 

remained contract's balance would be transferred to the RA or PA address respectively, and the contract status 

will be updated. Once a new block is mined with the newly linked CA, RA can initiate a quality monitoring 

request anytime to check if the provider is complying with the SLA conditions during the runtime. The request 

should be submitted to CA. 

C. Verifier Agent (VA) 

         Verifier Agent known as an oracle is an agent that verifies real-world occurrences and submits this 

information to a blockchain to be used by smart contracts.VA called by CA to check the quality of all the service 

for different attributes (e.g., availability, bandwidth, response time, etc.) and detects any misbehaviour of RA or 

PA, then returns the result to the contract agent to manage the payments and apply potential punishments. 

Accordingly, the contract agent chooses who should pay the cost of monitoring to VA. A record of the SLA 

monitoring and penalties will be kept by RPA for future reference. 

ALGORITHM 

Input: Ether Deposit; Reputation threshold; PA reputation; Cloud requester’s Ethereum address (RA); Cloud 

supplier’s Ethereum address (PA). 

Step 1: Requester Agent makes a service request in RPA and then RPA creates a CA. 

http://www.irjmets.com/


                                                                                                     e-ISSN: 2582-5208 
International Research Journal of Modernization in Engineering Technology and Science 

 Volume:03/Issue:03/March-2021            Impact Factor- 5.354                                     www.irjmets.com                                                                                                                                                                                                                                                                                         

www.irjmets.com                              @International Research Journal of Modernization in Engineering, Technology and Science 

 [1824] 

Step 2: If  CA.Availability is true then the event is created for a new request . 

Step 3: While RA requests a quality verification then CA calls VA. 

Step 4: If the result of verification process is true then positive verification is incremented. 

Step 5: Otherwise negative verification is incremented and Fine payment of PA to  RA due to SLA violation. 

Step 6: If CA.Completed then create a transaction(the fund is transferred to cloud providers). 
 

3.2 Verification Process 

         Oracle Blockchain Platform is reliable and it is the network that consists of authenticating nodes that can 

update the ledger and by executing smart contract code(the business logic that runs on the blockchain). 

Transactions are invoked by external applications or the queries are run through client SDKs or REST API calls 

which can select prompt peers to run smart contracts. After a consensus holds out on the transaction order, 

then the results are grouped into cryptographic secured, tampered proof, and send to peer nodes to be 

validated and added to the ledger. In the blockchain environment, oracles are systems that provide information 

coming from the real world to blockchain. Smart contracts do not deal with crypto exchange but deal with a 

decentralized mechanism that involving weather, stock price, or political events, a gateway from the external 

world is needed. In the real world the information coming from a third-party univocal source whose reliability 

is unchallenged for all nodes: the oracle[6].In our proposed model oracle is a verifier agent it can checks the 

quality of the service(QoS) for different attributes (e.g., availability, bandwidth, response time, etc.), detects any 

misbehavior of RA or PA and QoS at some cost, and report the SLA compliance to Cloudchain, then returns the 

validated results to the contact agent to manage payments and potential punishments. The contract agent 

decides who should pay the monitoring cost to VA(either RA or PA). The Contract agent calls the Verifier agent, 

retrieves CA terms and it monitors the cloud service between the cloud providers(PA) and cloud requesters 

(RA), and detects if any misbehavior between them. The verification depends on the Contract agent’s Service 

Level agreement [1]. The Service Level Agreement  include the service levels and metrics by which services are 

measured, duties and responsibilities of each agent, and a protocol of adding and removing metrics. It includes 

components in two areas namely services and management. The service components include conditions of 

service availability, standards such as time, responsibilities of each party, escalation procedures, and 

cost/service trade-offs. It Checks the provider's maximum capacity is less than or equal to the active capacity 

and if any misbehavior doesn’t detect, the verification result will be true. Otherwise, the verification result will 

be negative. Verifier agent calculates the Quality Monitoring Cost to charge Contract Agent. It sends to Provider 

Agent / Requester. 

 

                                             

                                             Figure 3.2: Represents the flowchart of the verification process. 

 

http://www.irjmets.com/


                                                                                                     e-ISSN: 2582-5208 
International Research Journal of Modernization in Engineering Technology and Science 

 Volume:03/Issue:03/March-2021            Impact Factor- 5.354                                     www.irjmets.com                                                                                                                                                                                                                                                                                         

www.irjmets.com                              @International Research Journal of Modernization in Engineering, Technology and Science 

 [1825] 

ALGORITHM 

Input: CA Ethereum address; M(t)(Quality Monitoring cost); VA Etheruem address (oracle). 

Output: Verification.Result 

 

Step 1: VA retrieves CA terms and monitors the cloud service. 

Step 2: VA verifies the quality of service based on CA.SLA. 

Step 3: if (Maximum capacity<= Active capacity) then verification result is true otherwise false. 

Step 4:  Calculate Quality monitoring cost.  
 

3.3 Stackelberg Differential Game 

         Stackelberg differential has two services like Leader and Followers. Leader services like share market, 

reputation and the request capacity. Followers are having low resources and parameters compared to the 

leaders. [1]. Stackelberg game model that provide the leader services in well-positioned in the market, first 

advantage to make an own preference. The payment can be represented in the form of token, or other 

equivalents. Game theory play a major role mathematical capability between leader and follower.. The upper 

level is called leader. It makes the first move and has all relevant information about the possible actions the 

follower might take in response to his own actions. Multi-agent Systems having Agent capabilities like Sensing 

the environment Interaction with the environment and other agents Taking autonomous decisions. They are 

designed to mimic human behaviour. A multi-agent system is a computerized system composed of multiple 

intelligent agents that can interact, collaborate, and act together in order to perform different tasks. Game 

Theory Three especially useful games in design type like Matching games and Stackelberg games. Matching 

games are used for Resource allocation and Task scheduling. Stackelberg games are used for Optimization of 

agent’s performance. The Game theory of this paper has resource allocation and pricing mechanisms, the 

players of this game are a leader and a follower and they compete on quantity. Where the interaction of players 

has to be taken into account. Stackelberg differential game is used to study the sequential decision making of 

cloud provider (Leader) for the optimal resource provisioning, cloud requester (Follower) for the quality 

monitoring requests, and oracle (Follower) for the monitoring Cost. In the designed game, the differential 

equation captures the dynamic competition and resource provisioning, quality monitoring requests and costs in 

continuous time. Provider Agent can choose the optimal capacity control path φ(t) to numbers of the requests 

for monitoring and maximize its payoff by observing the cost and in response to the capacity. Verifier agent sets 

an optimal price control path M(t) to charge for the quality verification by considering the given capacity which 

also affects the requests from Requester agent. Requester agent controls its verification requests N(t) to ensure 

the service quality by considering the given φ(t).  At the end for this demand and the quality monitoring 

demands are the system states of Provider agent, Verifier agent and Request agent [2]. 

Algorithm 1: Payment selection for follower 

Input: Pre-selected set of followers S, Leader’s reputation RL, Leader’s market share ML, Leader’s  capacity  CL  

Output: Optimal payment for followers P ∗ F  

  1: procedure Follower Game 

  2: for each follower F ∈ S do 

  3: Compute RL using aggregate reputation ER (L, F) 

  4: Compute ML using Aggregate market  

  5: Compute CL 

  6: Compute initial payment using RL, ML, CL 

  7: Get data about the payment of all other followers in S 

  8: Compute P ∗ F using Equilibrium  

  9: end for  

 10: end procedure. 
 

http://www.irjmets.com/


                                                                                                     e-ISSN: 2582-5208 
International Research Journal of Modernization in Engineering Technology and Science 

 Volume:03/Issue:03/March-2021            Impact Factor- 5.354                                     www.irjmets.com                                                                                                                                                                                                                                                                                         

www.irjmets.com                              @International Research Journal of Modernization in Engineering, Technology and Science 

 [1826] 

Algorithm 2: Leader’s Utility Function Game 

Input: Quota size |Q, Optimal payment for followers P ∗ F 

Output: Optimal quota of followers S ∗ 

  1: procedure LEADERPHASE  

  2: Pre-select a set of followers S 

  3: Publish market share, capacity, and reputation to S 

  4: Repeat 

  5: List all possible combinations C in S so that |C| =  |Q|  

  6: Compute RF using aggregate reputation ER (L, F) 

  7: Compute MF using Aggregate market 

  8: Compute CF capability follower 

  9: Compute utility UL(C) based on P ∗ F utility function of RL, MF, CF 

 10: Until C = argmax CUL(C)  

 11: S ∗ = C  

 12: end procedure  

 

3.4 Distributed Denial Of Service (DDos) Attack Mitigation 

         According to Moore et al. [8]  the average DDoS duration of attack approximately 5 mins, with the average 

DDoS attack rate being around 500 requests per second. Blockchain technology has already been successfully 

employed, to enhance detection systems concerning defending traditional cybersecurity attacks [9]. Blockchain  

is used  as  defense mechanism against  DDoS attacks. Generally the communication  between the Internet of 

Everything devices and servers with the instance of blockchain Ethereum. The attacks can be prevented by 

making use of the gas limit on Ethereum[10]. The major problem is DNS services against DDoS attacks is due to 

the internet unapproachable for multiple users. By using blockchain technology can produce distributed DNS 

services that are irrepressible to such attacks [11]. Blockchain DDoS Mitigation deployed on the top of 

Ethereum which is public and available technology is used to perform quick and using smart contracts DDoS 

attack is extensive [12]. For any target machine if it has sufficient resources to fulfill the attack requirements, 

then the attack will never be satisfied. Cloud providers have adequate resources to beat the DDoS attack. So the 

DDoS attack will never cause the cloud to be shut down. But the client-server or the cloud user does not have 

sufficient resources to overcome the attack [13]. To overcome this, our project proposes to find out the attacker 

and block the site from which the attack is made and recovery attacked URL without down the server. 
 

ALGORITHM 

Step I: If the IP address of Requests at time T is in the blacklist Then drop the request  

Step II: Else  If (Resource available at time T > Requested resources at time T)  

Step III: If (Requested resources < Threshold value at time T) 

Step IV: If it is true then complete the requests  

Step V: Else the request can be dropped.  

Step VI: And get resources from the providers. 

Step VII: After allocation of more resources goto II. 

 

http://www.irjmets.com/


                                                                                                     e-ISSN: 2582-5208 
International Research Journal of Modernization in Engineering Technology and Science 

 Volume:03/Issue:03/March-2021            Impact Factor- 5.354                                     www.irjmets.com                                                                                                                                                                                                                                                                                         

www.irjmets.com                              @International Research Journal of Modernization in Engineering, Technology and Science 

 [1827] 

 

 

                                                             Figure 3.4: DDoS attack miti";"""date"",""2021-03-30T05:05:54Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.7""
""xmp:CreatorTool"",""MicrosoftÂŽ Word 2016""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dc:creator"",""Rampyari""
""language"",""en""
""dcterms:created"",""2021-03-30T05:05:54Z""
""Last-Modified"",""2021-03-30T05:05:54Z""
""dcterms:modified"",""2021-03-30T05:05:54Z""
""dc:format"",""application/pdf; version=1.7""
""xmpMM:DocumentID"",""uuid:24FE9F69-8276-471D-8B51-23D900052B6A""
""Last-Save-Date"",""2021-03-30T05:05:54Z""
""pdf:docinfo:creator_tool"",""MicrosoftÂŽ Word 2016""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2021-03-30T05:05:54Z""
""meta:save-date"",""2021-03-30T05:05:54Z""
""pdf:encrypted"",""false""
""xmp:CreateDate"",""2021-03-30T10:35:54Z""
""modified"",""2021-03-30T05:05:54Z""
""Content-Length"",""417932""
""pdf:hasMarkedContent"",""true""
""Content-Type"",""application/pdf""
""xmp:ModifyDate"",""2021-03-30T10:35:54Z""
""pdf:docinfo:creator"",""Rampyari""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Rampyari""
""dc:language"",""en-IN""
""meta:author"",""Rampyari""
""pdf:producer"",""MicrosoftÂŽ Word 2016""
""meta:creation-date"",""2021-03-30T05:05:54Z""
""created"",""2021-03-30T05:05:54Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""9""
""Creation-Date"",""2021-03-30T05:05:54Z""
""resourceName"",""IRJMETS564927.pdf""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""5219"",""4954"",""4015"",""5269"",""3914"",""4296"",""3371"",""3055"",""4561""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""Author"",""Rampyari""
""producer"",""MicrosoftÂŽ Word 2016""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""MicrosoftÂŽ Word 2016""
""pdf:docinfo:created"",""2021-03-30T05:05:54Z""
";
1619099138-482;https://scholar.google.ch/scholar?as_ylo=2021&q=oracles+blockchain&hl=fr&as_sdt=0,5;Fair Outsourcing Polynomial Computation Based on the Blockchain;Y Guan, H Zheng, J Shao, R Lu… ; IEEE Transactions on …, 2021  ieeexplore.ieee.org;;"… compared to the previous schemes, our proposal supports arbitrary polynomials and dy- namic

coefficients without any complex crypto- graphic operations or … by many real-world applications

that rely on inputs from the physical world, we employ a blockchain oracle service [30 …";Les 2 versions;;null;;;;https://scholar.google.ch/scholar?start=70&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2021
1619099138-486;https://scholar.google.ch/scholar?as_ylo=2021&q=oracles+blockchain&hl=fr&as_sdt=0,5;BIDAPSCA5G: Blockchain based Internet of Things (IoT) device to device authentication protocol for smart city applications using 5G technology;M Vivekanandan, VN Sastry ; PeertoPeer Networking and Applications, 2021  Springer;;"… blockchain based revocation phase and registration of IoTDs, IoTD anonymity property at device

level. The security analysis of the proposed protocol was performed through formal security

verification using Proverif tool, formal security analysis using Random Oracle Model …";Cité 1 fois;Les 2 versions;[PDF] researchgate.net;https://www.researchgate.net/profile/U-Srinivasulu-Reddy/publication/343814125_BIDAPSCA5G_Blockchain_based_Internet_of_Things_IoT_device_to_device_authentication_protocol_for_smart_city_applications_using_5G_technology/links/5fd35c9645851553a0a94b0d/BIDAPSCA5G-Blockchain-based-Internet-of-Things-IoT-device-to-device-authentication-protocol-for-smart-city-applications-using-5G-technology.pdf;;;https://scholar.google.ch/scholar?start=70&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2021
1619099129-458;https://scholar.google.ch/scholar?as_ylo=2021&q=oracles+blockchain&hl=fr&as_sdt=0,5;Blockchain applications and architectures for port operations and logistics management;RW Ahmad, H Hasan, R Jayaraman, K Salah… ; Research in …, 2021  Elsevier;;"… Research in Transportation Business & Management. Blockchain applications and

architectures for port operations and logistics management … Highlights. • Discuss potential

application areas of blockchain technology in port logistics management. • …";Cité 3 fois;;null;;;;https://scholar.google.ch/scholar?start=50&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2021
1619099120-440;https://scholar.google.ch/scholar?as_ylo=2021&q=oracles+blockchain&hl=fr&as_sdt=0,5;Measuring the Impact of Blockchain and Smart Contract on Construction Supply Chain Visibility;H Hamledari, M Fischer ; arXiv preprint arXiv:2104.07532, 2021  arxiv.org;;"… on poorly designed oracles, blockchain-enabled information systems provide visibility into a

misrepresented view of job sites. The blockchain implementation presented in this work used

camera-mounted unmanned aerial vehicles and artificial intelligence as its oracle …";Les 2 versions;Version HTML;[PDF] arxiv.org;https://arxiv.org/pdf/2104.07532;"
 

 

 
 

 

 
 
 
 

 

Measuring the Impact of 

Blockchain and Smart Contract  

on Construction  

Supply Chain Visibility 
 
 
 
 

By 
 
 
 

Hesam Hamledari & Martin Fischer  
 
 
 
 

CIFE Technical Report #TR248 
April 2021 

 

STANFORD UNIVERSITY 
 



 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 
If you would like to contact the authors, please write to: 

 

 

c/o CIFE, Civil and Environmental Engineering Dept., 

Stanford University 

The Jerry Yang & Akiko Yamazaki Environment & Energy Building 

473 Via Ortega, Room 292, Mail Code: 4020 

Stanford, CA 94305-4020 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 



Measuring the Impact of Blockchain and Smart Contract on 

Construction Supply Chain Visibility 

 

Hesam Hamledari1, Martin Fischer2 

1 PhD Candidate, Stanford University, Department of Civil & Environmental Engineering, Stanford, CA, 

United States, hesamh@stanford.edu  

2 Kumagai Professor of Engineering & Professor in Civil & Environmental Engineering, Stanford 

University, Stanford, CA, United States, fischer@stanford.edu  

 

Abstract 

This work assesses the impact of blockchain and smart contract on the visibility of construction supply 

chain and in the context of payments (intersection of cash and product flows). It uses comparative empirical 

experiments (Charrette Test Method) to draw comparisons between the visibility of state-of-practice and 

blockchain-enabled payment systems in a commercial construction project. Comparisons were drawn 

across four levels of granularity. The findings are twofold: 1) blockchain improved information 

completeness and information accuracy respectively by an average 216% and 261% compared with the 

digital state-of-practice solution. The improvements were significantly more pronounced for inquiries that 

had higher product, trade, and temporal granularity; 2) blockchain-enabled solution was robust in the face 

of increased granularity, while the conventional solution experienced 50% and 66.7% decline respectively 

in completeness and accuracy of information. The paper concludes with a discussion of mechanisms 

contributing to visibility and technology adoption based on business objectives.  

 

 

Keywords:  

blockchain; smart contract; non-fungible token; DApp; supply chain visibility; construction; impact 

assessment 

  

mailto:hesamh@stanford.edu
mailto:fischer@stanford.edu


1. Introduction 
Increasing the visibility of the construction supply chain has long been one of the key objectives of 

supply chain management practices [1]. Supply chain partners need a shared understanding with respect to 

the flow of information, cash, and products; timely and accurate access to this data is key to achieving 

situational awareness [2] and one of the building blocks of successful project delivery [3]. This is 

particularly a challenge in the construction phase due to low transparency, fragmentation, limited 

communication, and inadequate information exchange between stakeholders such as clients, general 

contractors, and subcontractors [4].  

This lack of transparency is a weak link in the construction supply chain [5,6], and it has dire 

implications for the industry. It creates information asymmetry between project stakeholders, a major risk 

factor [7] and a source of distrust [8]. It leads to poor process orientation [9] and poor coordination between 

project members [10]. Engineers and architects spend more than 54% of their time managing information 

[11], therefore the inefficiencies caused by poor information visibility directly hurt business performance 

of projects [12].  

The blockchain technology has a potential to address these limitations; it is expected to enhance supply 

chain visibility [13] and eliminate siloed data developments [14] due to its innovative approach toward 

decentralized consensus. It allows for secure data sharing and collaboration in trust-less environments, 

creating “verifiable confidence” [15] in the data and computational systems used in construction and 

engineering projects. These potentials have led to a positive outlook from the research community, with a 

rapidly growing body of literature on the potential impact of blockchain and smart contracts for managing 

information, cash, and product flows in the construction supply chain.  

Despite this optimism, the impact of blockchain and smart contracts on the visibility of the construction 

supply chain remains to be measured in real-world applications. The research landscape has remained 

mostly theoretical [16-18] and needs yet to validate the effectiveness of the technology in real-world 

implementations [19]. It is therefore not surprising that industry practitioners remain skeptical about the 

technology’s potential and wary of its risks [20]. This technology will not see major industry adoption until 

its impact is clearly quantified [21] and contextualized with respect to current practices. 

To address this limitation, the paper assesses the impact of the blockchain and smart contracts on the 

construction supply chain visibility and in the context of payments (intersection of cash and product flows). 

This work uses the Charrette Test Method to compare the state-of-the-practice payment system, used by 

today’s industry practitioners, with a payment system based on blockchain-enabled smart contracts. The 

payments on a commercial construction project were processed and visualized using the two systems and 

for a period of three months; the two systems were contrasted in terms of the visibility of payment 

information at four levels of granularity. The tests provide insights with regard to 1) the impact of 

blockchain and smart contract on the visibility of construction supply chain; 2) the impact of increased 

granularity on the visibility of both conventional and blockchain-enabled solutions; and 3) how firms can 

adopt these technologies based on their business objectives. 

The paper first discusses the underlying problems contributing to low visibility and reviews the relevant 

work on blockchain applications that support supply chain visibility (section 2). The sections 3, 4, and 5 

respectively delve into the two research questions explored in this work, experiments designed to address 



the research questions, and the results of the experiments. The paper is concluded with a discussion of 

limitations and future work (section 6 and 7).  

2. Point of Departure 

The construction and engineering industry continues to strive toward supply chain visibility (SCV). 

The need for enhanced data sharing in the construction industry’s multidisciplinary environment motivated 

efforts on computerized product modeling [22] giving rise to building information modeling (BIM) [23,24]. 

The application of BIM promised benefits which among others included transparency via integrated 

information [25] and the creation of a single source of truth. While BIM continues to transform the industry, 

the problem of low SCV persists [26], and the industry struggles to leverage technology for communicating 

information [27]. This is despite the technological advances in virtual modeling and the introduction of data 

exchange standards such as industry foundation classes (IFC) [28].  

The industry’s current information systems “do not support the duality of product and project 

management.” [29]. The application of BIM provided a means of product communication [30], addressing 

the former objective. However, construction projects are made of social processes [31]; the management of 

projects and the dynamic collaborations introduce complexities that necessitate adaptations to the 

organization and the delivery of projects [32]. The mere availability of information does not enhance SCV 

[33]. 

It is necessary for the research efforts to go beyond product modeling and to create a collaborative 

environment for supply chain partners [34]. The individuals who benefit from a piece of information are 

typically not those who record it [27,35] nor those developing the underlying information system [36]. 

These independent stakeholders have competing business objectives which drives them into “information 

siloes” [37], hurting the integration and visibility of supply chain flows [38]. 

At its core, therefore, the problem of low SCV stems from a lack of trust between supply chain 

partners [39,40]. This problem is further exacerbated due to the industry’s reliance on third-party financial 

institutions for managing cash flow [41-43] and the high degree of fragmentation [44,45]. To achieve SCV, 

it is necessary to create trust in the integrity of protocols used for data creation (information, cash, and 

prodcut flows) [46] and those used for data sharing [47]. 

These are the very limitations that the novel governance models at the heart of blockchain and 

smart contracts aim to address, making these technologies relevant to SCV research. The following section 

reviews the relevant points of departure: the studies on the application of blockchain and smart contract for 

enhancing the transparency of supply chain flows in the construction and engineering industry. 

2.1. Blockchain and Smart Contracts for Enhancing Supply Chain Visibility 

Increased transparency has been repeatedly identified as a key benefit of blockchain technology for 

the construction and engineering industry [48-51]. This value proposition is also appealing from the 

standpoint of  practitioners [52]. Therefore, it has become a common objective for most existing studies. In 

reviewing the literature, this work employs a supply chain flow lens, categorizing the studies by their focus 

on the management of information, product, and cash flows.  



2.1.1. Information Flow 

Decentralized organizations are less resistant to the flow of information [53] and can benefit from 

increased transparency due to the higher degree of involvement from project participants [54]. This is 

crucial because the construction and engineering industry suffers from poor process transparency [55]. 

The consensus mechanisms underlying blockchains can empower decentralized models of data 

management, increasing trust in both the project information and the computational methods employed in 

project management. In managing the flow of information, the role of blockchain is not storing the data, 

but keeping an immutable record of changes to data [56]. This ability to track provenance is a key driver of 

increased transparency [57,58], providing independent parties with a quick means of verifying changes 

[59]. This is argued to foster collaboration among project stakeholders [60]. Furthermore, the application 

of blockchain can create a common information layer and promote the use of unified data definitions; the 

latter is crucial to project knowledge representation [61]. 

The blockchain technology can potentially benefit BIM workflows [62,63] which often involve 

independent parties working on a shared product model during the design, construction, and operation 

phases. Some argue that blockchain can enhance the privacy, data security, and permission management in 

BIM workflows [64]. A blockchain-based framework was proposed to address the security concerns for 

BIM-based workflows [65]. Others argue that the integration between BIM and blockchain can enable the 

decentralization of architectural design [66]. 

A framework was introduced for integrating BIM in the design and construction process using 

blockchain [67]; it focused on both the structure of interactions between project participants and the flow 

of information. Another work [68] stores the cryptographic hashes of BIMs on a blockchain to track 

changes. The log files generated by BIM-authoring solutions were categorized and used for recording the 

design events on a blockchain-based framework [69]. To streamline information sharing, a recent study 

used blockchain to authenticate data written to digital twins [70], enhancing confidence in the project data.  

A limitation of existing studies is the data redundancy, with multiple copies of BIM stored off-chain. 

To address this limitation, two studies propose that only the changes to BIM need to be recorded rather than 

entire models. CryptoBIM [71] created a granular and content-addressable modeling of building 

information data on a blockchain, recording only the incremental changes to BIM elements and their 

semantics. A semantic differential transaction approach was introduced [72] to record the local model 

changes in the form of BIM contract changes. The approach was shown to significantly reduce the storage 

requirement for BIM workflows.  

The research landscape on the management of information flow is not limited to BIM; the application 

of blockchain has been proposed for tracking the energy performance of buildings [73], estimating 

embodied carbon content [74], tracking quality information of prefabricated building elements [75,76], 

operation records for modular construction [77], data management in smart construction sites [78], and 

decentralizing the quality acceptance process  [79].  

A conceptual blockchain-based framework was proposed for managing asset information during 

operation [80]; it needs to be validated in future. It was argued that the integration between sensing 

platforms, smart contracts, and information models can enhance the tracking of maintenance and operation 

for physical assets [81]. A real-world case study application of blockchain in water infrastructure projects 

revealed that this technology reduces the effort associated with information management by 49% [82].  



2.1.2. Product Flow  

Enhancing the communications around material/product flow between suppliers, subcontractors, 

and general contractors can reduce the lead time, increasing service levels, and therefore reduce the 

construction cost [83]. The blockchain’s traceability feature can facilitate this goal. One study [84] 

separated the material traceability into two components: tracing the origins of materials and tracking them 

through the supply chain. Based on a case study of a hypothetical supply chain, it was argued that the 

technology can be more effective with the latter objective [84]. For blockchain to be successful in product 

flow applications, it must be integrated with remote sensing and reality capture technologies [84,85]. 

To address this limitation, few studies focused on connecting the physical and digital worlds on 

construction projects: one study argued that the combined use of radio-frequency identification (RFID) and 

blockchain can improve the tracking of concrete panels from production to on-site delivery [86]; however, 

it remains to be validated. The integrated use of sensor recordings, BIM, and smart contracts was shown to 

be promising for tracking the installation of building façade panels [87]. A smart contract-based solution 

[88] created an immutable and content-addressable record of construction progress on a private Inter 

Planetary File System (IPFS) network [89] with immutable links to Ethereum blockchain [90,91]. These 

studies create a link between off- and on-chain realities, a crucial step toward the integration of product 

flow with the flow of information and funds. 

2.1.3. Cash Flow 

The industry’s challenges with respect to cash flow management has motivated a move toward 

smart contracts and blockchain: 1) current payment applications and contracting practices are dependent on 

highly intermediated and manual workflows [92,93]; 2) the financial supply chain is highly fragmented and 

reliant on third-party institutions that hurt the visibility of cash flow [42,94]; 3) project participants have 

competing objectives, and therefore can exhibit opportunistic behaviors and provide incomplete or falsified 

information [95]. The resulting lack of transparency can lead to corruption [96]. 

Smart contracts can enhance transparency of cash flow by their formalization of rules and relationships 

[97,98], providing visibility regarding the performance of project participants prior and after they enter a 

contractual agreement. Automated processes can improve the financial supply chain [99], and smart 

contracts can add reliability to such automation by eliminating its single points of failure and centralized 

control mechanisms [100]. The blockchain technology, underlying smart contracts and decentralized 

applications, can be thought of as a “confidence machine” [101] that ensures the integrity and transparency 

of the underlying data used in payment processing [102]. This confidence stems from the use of 

decentralized consensus mechanisms such as Nakamoto consensus [103] and similar algorithms. 

These potentials have created optimism with respect to the application of smart contract and blockchain 

for the management of project funds and contracting [104]. The increased transparency enabled by smart 

contracts is speculated to promote collaboration [105], reduce counterfeiting and fraudulent activity [106], 

and result in time and cost savings during both the project execution [107] and the contracting phase [108].  

A framework [109] was proposed to enhance the transparency of the profit pool in integrated project 

delivery (IPD) projects, where planned and achieved profits are calculated automatically using a smart 

contract based on Hyperledger Fabric [110].  A conceptual business model [111] was developed for use by 

independent construction consultants and in the context of Swedish construction industry; the model aims 

to integrate the supply chain flows while providing transparency by its involvement of major project 



participants in its consensus mechanism. A case study of Nigeria reveals that the application of blockchain 

in public infrastructure projects creates transparency around government processes and reduces the 

possibility of corruption [112]. It was shown [113] that crypto assets (crypto currencies and crypto tokens) 

can be used to integrate a project’s cash flow with its product flow, achieving higher granularity and 

atomicity compared with today’s best practices.  

A series of studies focused on providing transparency with respect to the financial status of project 

participants and the status of payments. A smart contract-based solution was developed to improve 

transparency around the clients’ ability to pay [114]; it allowed for funds to be secured for 30 days, reducing 

the possibility of default. This can reduce the information asymmetry around the owners’ financial status, 

a key challenge in both bidding and construction phase [7]. A cryptographic key management solution [115] 

provided “selective-transparency” between project stakeholders such that the sensitive information can be 

securely shared between two contracting parties. To enhance the transparency of the payment applications, 

a semi-autonomous consensus mechanism [116] was introduced; a smart contract executes payments once 

a peer-to-peer network of project members reach agreement with regard to the accuracy of the data provided 

by contractors in their applications for payment. 

Others take a BIM-based approach toward enhancing transparency of payments. The integrated use of 

5D BIM and smart contract was proposed for automated billing [117,118], where BIM use provided 

transparency with respect to the bill of quantities and project cost information used in the valuation of the 

work. The proposed framework will be implemented and validated in future. Two studies created visibility 

with regard to the status of cash flow in relationship with the status of product flow (e.g., off-site fabrication, 

delivery, on-site installation and construction), retrieving the latter directly from BIM: a smart contract-

based framework [87] processed payments based on the delivery or installation of building façade panels; 

the approach was successfully tested in real-world, but the design of smart contract was not provided. 

Another work [88] used smart contracts to automate payments to subcontractors and general contractors 

based on the as-built status of projects documented by robotic reality capture. These studies have a potential 

to eliminate the need for intermediated payment applications and provide an integrated and transparent 

record of both product and cash flows. 

2.1.4. Gap in Knowledge 

For information management systems to be successful, their designers should think about how 

stakeholders use the information, and not just how they use the system [119]. It is necessary to go beyond 

the mere assessment of usability and to measure the impact of new technological solutions on information 

visibility via quantified value assessments [120]. Solutions based on blockchain and smart contract should 

not be an exception. 

The existing body of research has clearly shown that these technologies have potential to enhance 

the visibility of information related to construction supply chain. Despite this growing enthusiasm and 

increased clarity regarding the know-how, we lack empirical analyses of how this technology compares 

with the industry’s current best practices in their effectiveness and support of SCV.   

Section 3 elaborates the two research questions explored in this work that aim to address this gap 

in knowledge. 

 



3. Research Questions 
This work explores the impact of smart contract and blockchain on SCV in the context of construction 

payments; this domain provides a great test bed for a few reasons: first, achieving transparency regarding 

payments necessitates a clear understanding of the two flows of cash and product, along with their 

integration. This is more difficult to achieve than analyzing each flow in isolation. Second, creating a 

coherent and singular documentation of these supply chain flows is a challenge due to the industry’s reliance 

on external financial institutions in its already fragmented supply chain. 

The SCV definition used in this work is borrowed from a review of SCV literature [121]: “supply chain 

visibility is the identity, location and status of entities transiting the supply chain, captured in timely 

messages about events, along with the planned and actual dates/times for these events.” In the context of 

construction payments, these entities comprise the flows of cash and product. 

When analyzing the visibility of construction payments, it is crucial to take granularity into 

consideration; it directly affects the complexity of information retrieval [113]. Payments can be 

distinguished by their 1) temporal, 2) trade-level, and 3) product-level granularity [113]: these respectively 

correspond to the period for which a trade is compensated, the number of trades compensated in a payment, 

and the scope of valued construction work. Therefore, in its impact assessment, this work explores the 

following two research questions (RQ):  

RQ1: How does the visibility of the conventional and blockchain-enabled construction payment 

systems compare at different levels of granularity? 

RQ2: How does increased granularity (time, trade, product) affect visibility in each payment system? 

Fig. 1 shows the comparisons that are drawn for each research question. 

 

 

Fig. 1. The research questions respectively 1) draw comparison between the two processes at various levels of 

granularity, and 2) study the performance of each individual process with respect to increased granularity 

 

 

 



4. Method: Charrette Test  
The Charrette Test Method [122] was employed to answer these two questions. It uses comparative 

empirical experiments to evaluate the “effectiveness” of different tools in performing similar tasks. It is 

commonly used for rigorous validation of construction research [123]. Herein a comparison is drawn 

between 1) a payment system based on blockchain-enabled smart contracts, and 2) one based on the 

industry’s state-of-practice payment systems. These are respectively referred to as “innovative process” and 

“conventional process” in the Charrette Test Method.  

A total of 14 participants, comprising of doctoral candidates in the construction engineering and 

management program at Stanford University (USA), were assigned to either one of the two payment 

systems. All participants have proficiency in general construction management concepts. In each trial, a 

participant completed a number of tasks: they interacted with the assigned payment system to determine 

the amounts of payments made to trades under scenarios with varying levels of granularity.  

Prior to performing the tasks, participants watched an 8-minute instructional video and spent 5 minutes 

familiarizing themselves with the assigned payment system. The instructional videos were produced 

separately for the innovative and conventional processes. In both, the authors introduced payment 

workflows and demonstrated a few examples of how tasks can be completed with a given payment system.  

This resulted in 14 trials (7 for each process) which were evaluated using a series of metrics to arrive 

at a comparison of how the two processes support SCV. The following sections respectively elaborate on 

the design of blockchain-enabled and conventional processes used by Charrette test participants (section 

4.1), the design of the tasks completed by participants (section 4.2), and the metrics used in performance 

evaluation (section 4.3). The charrette test results are provided in section 5. 

4.1. Innovative and Conventional Processes 

Both processes were modeled in the form of interactive dashboards and implemented in Tableau 

software. Both dashboards display the payments corresponding to three months of indoor finishing work 

by four subcontractors at a commercial construction project in Toronto (Canada). The 3,400 m2 job site was 

inspected using a camera-equipped unmanned aerial vehicle; the robot-captured visual data was passed to 

a computer vision-based algorithm [124,125] to arrive at the state of progress for indoor partitions: 

percentages of completion were reported for framing, insulation, drywalling, plastering, and painting. 

 

Fig. 2. Progress data captured at a commercial construction site was used to generate the payment data for both 

innovative (blockchain-enabled) and conventional (state-of-practice) processes 



This progress data was passed to both the innovative and conventional processes (Fig. 2). The two 

separately arrived at the payments for the months of June, July, and August; their corresponding dashboards 

visualize the same total amounts of payments ($247k) to the same four subcontractors.  

4.1.1. Blockchain-Enabled Payment Administration  

In the innovative process, a smart contract-enabled method [88], developed by the authors, was 

used to pay the four trades. This solution stores the progress data off-chain on a private IPFS network and 

communicates the valuations to a smart contract via a JSON remote procedure call. The smart contract, 

running on the Ethereum Virtual Machine, performs on-chain payment settlements and the transfers of lien 

rights respectively using the instances of crypto currencies and ERC-721 non-fungible crypto tokens. The 

resulting 406 transactions were written to the Ethereum blockchain and used as input to the interactive 

dashboard (Fig. 3) (please consult [88,100] for the design of the smart contract algorithms).  

The dashboard used by participants in the Charrette test is illustrated in Fig. 3: the payments to the 

four trades are listed based on cost code, and a series of filters can be used to narrow down the scope of 

visualized payments (e.g., based on when the work was performed, when the payments were made, the 

element types, and the building floors where the work was performed). The dashboard is based on the 406 

transactions sitting on the blockchain; an example of transactions processed by the smart contract is shown 

in Fig. 3b 

 

 

Fig. 3. The dashboard displaying the payment data for the innovative process: a) smart contract-enabled payments 

written to the Ethereum blockchain, b) an example of a transaction compensating the framer, and c) the interactive 

dashboard based on the 406 transactions; the dashboard was used by the participants in the Charrette test 

 

 

 

 



4.1.2. State-of-Practice Payment System  

In the conventional process, general contractors (GC) prepare monthly applications for payments 

using standardized forms (e.g., AIA G702 and G703) where all scopes of work completed by trades are 

listed and submitted to owner for review. The industry still heavily relies on paper-based workflows but 

has recently started a move toward digital alternatives.  

To arrive at an accurate definition of state-of-practice, the authors conducted interviews with two 

major US-based construction firms with leading digital initiatives; two internet-based software applications 

were identified as the primary technological solutions used in the industry, both of which digitalize the 

workflows for the preparation, documentation, and visualization of valued work listed in AIA G702 and 

G703. The dashboard used in the conventional process (Fig. 4) was closely modeled after these two software 

applications to establish a fair representation of state of practice. The dashboard displays (Fig. 4) the three 

payment applications (draws) for the months of June ($82k), July ($95k), and August ($70k). Please note 

that these payments amount to the same total as the smart contract-based solution (247k) described in 

section 4.1.1. 

 

Fig. 4. The conventional process: a) the payment dashboard used by participants in the Charrette test, b) the draw 

home providing a summary of payments for that month along with supporting AIA documents, and c) an example of 

the application for payment G702 and G703 documenting payments based on the cost code, valuation, and the 

description of the work 

Participants can view each draw page (Fig. 4b) to review the supporting documents including the 

invoices submitted to the GC by the four trades and the overall invoice submitted to the owner by GC. Each 

invoice breaks down payments in terms of cost codes, their valuations, and the description of the work (Fig. 

4c). These invoices were prepared by the authors and based on the input progress data (Fig. 2). 



4.2. Tasks 

In each trial, a participant is asked to complete 12 tasks using the provided dashboard.  Each task 

asks the participant to identify the amount of payments to trades under a scenario. As previously explained, 

these scenarios are distinguished by their choices of temporal, trade-level, and product-level factors. Each 

factor can be low (L) or high (H) in its granularity (Table 1). For example, inquiring about the “payments 

made for painting” and “payments made for work on the 14th floor partitions” respectively have low and 

high product-level granularity according to Table 1. The latter describes specific instances of building 

elements (product).  

Table 1. The levels of granularity used for temporal, trade-level, and product-level factors 

Factor Granularity  Description 

Time High one week 

 Low one month 

Trade High direct payment to a subcontractor 

 Low payments to GC/few subcontractors 

Product High referring to the elements’ location, type, or cost code 

 Low describing general scopes of work (e.g., plastering) 

 

Depending on the choice of three factors, each task can have one of the four levels of granularity: lowest 

(3 L), low (2 L, 1 H), high (2 H, 1 L), and highest (3 H). Three tasks were designed for each level of 

granularity, resulting in a total of 12 tasks that will be completed by each participant; they are listed in 

Table 2. Participants either provide a written response or skip the task if they are unable to find an answer.  

Table 2. The 12 tasks performed by participants in the Charrette Test Method 

T
as

k
 

G
ra

n
u

la
ri

ty
 

T
ra

d
e,

 

T
im

e,
 

P
ro

d
u

ct
 

D
es

cr
ip

ti
o

n
 

1 lowest LLL Payments to the General Contractor (GC) made in July  

2 lowest LLL Payments to GC for the insulation work performed in June 

3 lowest LLL Payments to GC for plastering and painting performed in August 

4 low LLH Payments to GC for the work on the 14th floor’s D21 walls performed in Jul";"""date"",""2021-04-15T15:10:03Z""
""pdf:PDFVersion"",""1.4""
""xmp:CreatorTool"",""MicrosoftÂŽ Word for Microsoft 365""
""pdf:docinfo:title"",""Chapter 2""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""language"",""en""
""dc:format"",""application/pdf; version=1.4""
""pdf:docinfo:creator_tool"",""MicrosoftÂŽ Word for Microsoft 365""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""Chapter 2""
""xmp:CreateDate"",""2021-04-15T10:07:18Z""
""modified"",""2021-04-15T15:10:03Z""
""pdf:hasMarkedContent"",""true""
""xmp:ModifyDate"",""2021-04-15T15:10:03Z""
""pdf:docinfo:creator"",""Tedie Guenzer""
""meta:author"",""Tedie Guenzer""
""meta:creation-date"",""2021-04-15T15:07:18Z""
""created"",""2021-04-15T15:07:18Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2021-04-15T15:07:18Z""
""resourceName"",""2104.07532""
""Author"",""Tedie Guenzer""
""producer"",""3-Heights(TM) PDF Security Shell 4.8.25.2 (http://www.pdf-tools.com) / pdcat (www.pdf-tools.com)""
""pdf:docinfo:producer"",""3-Heights(TM) PDF Security Shell 4.8.25.2 (http://www.pdf-tools.com) / pdcat (www.pdf-tools.com)""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""access_permission:modify_annotations"",""true""
""dc:creator"",""Tedie Guenzer""
""dcterms:created"",""2021-04-15T15:07:18Z""
""Last-Modified"",""2021-04-15T15:10:03Z""
""dcterms:modified"",""2021-04-15T15:10:03Z""
""title"",""Chapter 2""
""xmpMM:DocumentID"",""uuid:AB6B8ED3-E7EE-4739-8556-D339FDC0C2F8""
""Last-Save-Date"",""2021-04-15T15:10:03Z""
""pdf:docinfo:modified"",""2021-04-15T15:10:03Z""
""meta:save-date"",""2021-04-15T15:10:03Z""
""Content-Length"",""888718""
""Content-Type"",""application/pdf""
""xmp:MetadataDate"",""2021-04-15T15:10:03Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Tedie Guenzer""
""dc:language"",""en-US""
""pdf:producer"",""3-Heights(TM) PDF Security Shell 4.8.25.2 (http://www.pdf-tools.com)""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""30""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""216"",""298"",""1663"",""3839"",""3418"",""3882"",""3995"",""3618"",""2106"",""2832"",""1928"",""2021"",""2743"",""2736"",""885"",""1237"",""1388"",""3538"",""3375"",""2170"",""3816"",""3416"",""3501"",""3635"",""3759"",""3653"",""3775"",""3489"",""3649"",""1822""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2021-04-15T15:07:18Z""
";https://scholar.google.ch/scholar?start=30&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2021
1619099124-449;https://scholar.google.ch/scholar?as_ylo=2021&q=oracles+blockchain&hl=fr&as_sdt=0,5;Blockchain and Smart Contracts: A Look at the Future of Transfer Pricing Control;C Cipollini ; Intertax, 2021  kluwerlawonline.com;;"… the concept of oracles see also H. Al-Breiki, MHU Rehman, K. Salah & D. Svetinovic, Trustworthy

Blockchain Oracles: Review, Comparison, and Open Research Challenges, 8 IEEE Access,

85675–85685 (2020); R. Van Mölken, Blockchain Across Oracle: Understand Details …";;null;null;;;;https://scholar.google.ch/scholar?start=40&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2021
1619099120-442;https://scholar.google.ch/scholar?as_ylo=2021&q=oracles+blockchain&hl=fr&as_sdt=0,5;Structuring Contract-for-Difference Instruments for Hedging Electricity Price Risks on a Blockchain-based Marketplace;O Alao, P Cuffe ;2021 techrxiv.org;;"… The challenge of designing a blockchain-based CfD arrangement is, therefore, in determining

how non-trusting or possibly … A stablecoin is a cryptocurrency that is directly pegged to a

relatively-stable fiat currency … oracle to provide external data to the smart contract [31], [32] …";Les 2 versions;Version HTML;[PDF] techrxiv.org;https://www.techrxiv.org/articles/preprint/Structuring_Contract-for-Difference_Instruments_for_Hedging_Electricity_Price_Risks_on_a_Blockchain-based_Marketplace/14140814/files/26665034.pdf;"
1

Structuring Contract-for-Difference Instruments for
Hedging Electricity Price Risks on a

Blockchain-based Marketplace
Olakunle Alao, Student Member, IEEE and Paul Cuffe, Member, IEEE

Abstract—The volatile nature of day-ahead electricity markets
means that participants often resort to some form of derivative
hedging instrument. One such derivative instrument is a Contract-
for-Difference (CfD), specifically available to renewable genera-
tors in some jurisdictions to enable them to hedge against their
price risk. CfD is a bilateral arrangement between a generator
selling into, and an offtaker buying out of, a centrally cleared
pool market for electricity. In this arrangement, the generator
subsidizes the offtaker when the spot price is high; whereas,
the offtaker subsidizes the generator when the spot price is
low. This establishes a synthetic bilateral electricity transaction,
operating in parallel to the pool market. Embracing CfD to hedge
against price risk presents new risks such as counterparty credit,
margining, third-party, and legal risks. They also incur high
costs and possess underlying process risks. Decentralized Finance
– an overarching term representing financial services built on
top of a public blockchain – seems to present particularly com-
pelling opportunities in electricity derivatives for these reasons.
Therefore, we propose a novel Decentralized Finance instrument:
a blockchain-based marketplace governed by a smart contract
to act as a mediator between stakeholders mutually enrolled
in bilateral CfD arrangements. The employed smart contract
structure autonomously and irrefutably enforces the terms of
the CfD, underpinned by a novel collateralization and settlement
mechanism. This novel approach mitigates the hedging-related
and underlying process risks of traditional CfD instruments.

Key words—Decentralized Finance, Electricity derivatives,
Blockchain, Smart contracts and Renewable electricity

I. Introduction

THE diminishing level of fossil fuels, greenhouse gas
emissions that accompany their exploitation, as well as

increasing global electricity demand, is triggering the need for
accelerated renewable electricity development [1].
In day-ahead electricity markets, generators primarily par-

ticipate in the pool market, as in Fig. 1. Here, they deliver
power physically into the grid. In return, they secure revenue
proportional to the volume of electricity they supply and the
uniform clearing price of the pool market for that trading
period [1]. The unique physical characteristics of electricity

This publication has been funded by the Sustainable Energy Authority of
Ireland under the SEAI Research, Development & Demonstration Funding
Program 2018, grant number 18/RDD/373.

O. Alao (olakunle.alao@ucdconnect.ie) and P. Cuffe are with the School of
Electrical and Electronic Engineering, University College Dublin.

Interests disclosure: The authors hold cryptographic assets.

Fig. 1. Basic structure of a notional day-ahead electricity market.

generation and distribution, reflected in day-ahead electricity
markets, makes these spot prices quite volatile [2]. Therefore,
generators could be exposed to the risk of sustained low
prices, resulting in depressed revenues. Renewable generators,
in particular, are also susceptible to volume risk [3], as the
output of wind or pv plants, for instance, are variable; and thus
liable to underperform expectations for days, weeks, months
or even years [3]. These inherent risks to the revenue stream
of prospective renewable electricity projects, amongst others,
could make mobilizing finance from traditional risk-averse
sources quite challenging [4].

For this reason, many government subsidy schemes aim to de-
risk renewable electricity development [5]. Complementary to
these, a range of specific financial derivative instruments have
emerged to stabilize revenue streams for renewable generators
[6], [7]. Overall, generators (renewable and conventional) usu-
ally resort to some form of these derivative instruments in the
financial market, parallel to the centrally cleared pool market for
electricity, as in Fig. 1 [7]. These derivatives are typically traded
over-the-counter or on organized exchanges. Classical forward
contracts on electricity prices are bilaterally traded over-the-
counter; hence, their terms are negotiable. Conversely, futures
on electricity prices are traded on organized exchanges with
standardized terms [2], [7]. In practice, generators typically hold
a balanced portfolio of these derivatives, as each instrument
possesses unique weaknesses and strengths [2], [7].

A. Contract-for-Difference
A specific financial derivative instrument that is available

in, for example, the uk and Australian day-ahead electricity



2

markets to stabilize revenue streams for renewable generators,
is the Contract-for-Difference (CfD) [5]. CfD instruments are
forward electricity derivatives that achieve revenue stability for
renewable generators and offtakers by hedging against their spot
price risk exposure. They are undertaken between a renewable
generator and a counterparty offtaker who buys out of the
same pool that the generator sells into [7]. As high spot prices
are good for the generator but bad for the offtaker, and low
spot prices are the opposite, it is mutually beneficial for these
parties to cooperate in hedging each other’s exposure to these
volatile spot prices. Importantly, a CfD does not hedge against
volume risk; hence, renewable generators maintain the volume
risk of over- or under-realizing their predicted delivery volume.

In a CfD, contracting parties receive or pay the difference
between the trading period spot price and pre-agreed strike
price per unit of electricity over a specific agreement duration
[1]. If the strike price is greater than the spot price, the generator
receives a payoff from the offtaker – the difference between
the strike price and spot price per unit of electricity (mwh).
Otherwise, the generator returns a payoff to the offtaker – the
difference between the spot price and strike price per unit of
electricity (mwh) [5]. In simple terms, CfD could be seen as a
medium-term or long-term Virtual Power Purchase Agreement
between bilateral parties that protect them from the volatile
spot price risk of the day-ahead electricity market as in Fig.
2 [8]. CfDs are Virtual Power Purchase Agreements because
they are financial instruments and hence do not involve the
delivery or evacuation of physical power [5].

Traditional CfD instruments are traded over-the-counter like
other bilateral contracts [9]. Thus, they are liable to counterparty
credit risk, resulting from the possibility that a contracting party
can incur a financial loss because of a default on settlement
payment by its bilateral counterparty [7]. They are exposed to
high margining risks because of the non-frequent settlement
times of the central intermediary that usually clear and settle
payments due to contracting parties [10]. The non-frequent
settlement times result in accumulated settlement payments.
This imposes the need for contracting parties to maintain high
margins to reflect the quantum of cash flows to be hedged and
thus introduces the risk of high margin payments [1].

Further, traditional CfDs are susceptible to third-party risks,
due to the probability that the intermediary (known as a
broker) underpinning transactions can become fraudulent or
insolvent [7]; and legal risks arising from possible contractual
disputes between contracting parties [2]. Traditional CfDs also
incur high direct (transaction-related) and indirect costs [9];
and possess underlying process risks, the probability that a
contracting party can suffer a financial loss because the process
that supports the CfD arrangement lacks operational efficiency
and reliability [9]. In the context of traditional CfDs, process
risks result from the error-susceptible manual moving parts
that slows non-transaction and transaction-related activities of
the contract.

Fig. 2. Actual trading day spot prices of a day-ahead electricity market in
Europe denominated in us$ [8].

B. Decentralized Finance
Decentralized Finance (DeFi) can be defined as financial

services running on the blockchain [11] – an immutable and
decentralized digital ledger that enables transactions between
parties to be recorded in a secure and permanent manner [12],
[13]. The operation of DeFi instruments on the blockchain
is governed by smart contracts. Smart contracts are special
computer scripts (or chaincode) that execute natively within a
blockchain in a way that cannot be impeded or interfered with
[14]. For instance, a smart contract can autonomously hold and
manage cryptographic assets based on predefined conditions.
When the appropriate conditions are met, the smart contract
can autonomously disburse funds to a particular counterparty
or token-holder [15].
DeFi principles are quite new in electricity derivatives.

The earliest work on DeFi electricity derivative products was
undertaken in [16]. Here, the main regulatory issues around
the implementation of blockchain-based electricity wholesale
trading for over-the-counter transactions were investigated.
Since then, not much work has been achieved in the blockchain
electricity derivatives space. The present authors [1] proposed
a more applied form of the earlier work in [16], where
they sketched out the basic framework for a blockchain CfD
derivative instrument in the electricity industry. Still, this
project was exploratory and intended to serve as an impetus
towards the development of advanced and robust blockchain
electricity derivatives, as our work here.
The financial industry has seen more substantial proposals

and applications of DeFi derivatives [17], [18], [19]. Here,
DeFi is proving to reduce some hedging-related and underlying
risks of traditional financial derivatives. For example, in [17],
DeFi derivative products were proposed to hedge systemic
risk in forwards over-the-counter contracts. The exposure to
systemic risk was reported to arise from the non-transparent
reporting of over-the-counter transactions to trade repositories,
tasked with monitoring these transactions [17]. In [18], [19], a
derivative market was implemented on a public blockchain
to reduce counterparty credit risk. The results here also
indicate mitigation of third-party risks since the role of
intermediaries who introduce these risks are made redundant
by the self-executing blockchain smart contracts. The trading



3

of Bitcoin futures on the Chicago Board Options Exchange
and the Chicago Mercantile Exchange represents an applied
implementation of DeFi derivative products [20].
DeFi derivative instruments could potentially be a good

fit for the electricity industry for the following reasons. First,
the presence of several non-transaction and transaction-related
manual moving parts in the electricity industry’s financial
market [2] presents compelling opportunities for blockchain
smart contracts proven to automate manual processes inherent
in traditional financial instruments [13], [21]. Most importantly,
the mature, organized and transparent setup of wholesale
electricity markets [6], [16] could allow DeFi derivative
instruments to easily synchronize with these markets. To put
this into context, we consider the implementation of a smart
contract in an opaquely-structured industry like agriculture.
Here, certain farmers might want to secure a derivative to
hedge the volume risk of their harvest; however, how can
a smart contract verify that some of these potatoes haven’t
rotted before the delivery day? Conversely, electricity is a
pure fungible commodity traded in an open and transparently-
structured market that clears and settles at a known frequency
[7]. This well-coordinated setup of electricity markets could
allow for seamless integration of blockchain smart contracts
alongside them, with little or no disruption to the existing
physical trading structure.

C. Novel contribution

The novel contribution of the present work is a functional
description of a blockchain smart contract that operates as a
mediator between stakeholders mutually enrolled in bilateral
CfD arrangements. This CfD instrument is structured as
smart contract chaincode, underpinned by a novel autonomous
collateralization and settlement mechanism. This smart contract
framework, named Blockchain Electricity Derivative (bed),
attends to the following issues, where the first two issues
concern traditional CfD instruments and the last issue pertains
to smart contract development:

1) How can we mitigate hedging-related risks introduced
by traditional CfD instruments?

2) How can we reduce costs and the underlying process
risks of traditional CfD instruments?

3) How can we mitigate some of the new exotic risks
associated with DeFi applications?

We attend to the first and second issues by leveraging a
blockchain smart contract platform. To mitigate hedging-related
risks introduced by traditional CfD instruments, we propose
the incorporation of a novel autonomous collateralization and
settlement mechanism into the smart contract. The autonomous
collateralization and settlement mechanisms underpin the smart
governance system through interconnected financial incentives
that compel off-chain actions of contracting parties that do not
have to trust or know each other. The design and implementation
of these mechanisms are detailed in Section II.

The decentralized and immutable attribute of blockchain [22],
[23] along with the process automation introduced by the smart
contract [14], [15], enables cost-reduction and addresses the
underlying process risks of traditional CfD instruments [9]. The
two components of process risk are the risks of lack of process
efficiency and process reliability [9]. Process automation attends
to the efficiency component of process risk by reducing the
typical manual moving parts inherent in traditional legalistic
CfD instruments. The consequence of process efficiency
is the elimination of some cost components of traditional
CfD instruments. These costs are usually associated with
clearing & settlement, enforcement & compliance, reporting,
adjudication processes, etc. [10]. The presence of many human
intermediaries in traditional CfD instruments also introduces
the risk of lack of process reliability [9]. This risk is addressed
in our approach because smart contracts are persisting and
function based on only the predefined conditions embedded in
them [14].
Importantly, the smart contract is designed so that it is

neither a forwards nor a futures contract. Instead, it fuses the
characteristics of both contracts – it maintains the bilateral
terms negotiability of traditional CfD instruments traded over-
the-counter, albeit within a programmable smart contract; while
also exploiting the economies of scale and liquidity provided
by the market-based futures contract. The hybrid nature of bed
should make it highly liquid and further its cost-effectiveness.

By addressing the first and second problem statements using a
DeFi application, new risks are introduced into bed. These risks
include volatility risk of the native currency of the blockchain
[24]; security risks as a result of poorly tested smart contracts or
new attack vectors and dependencies on other DeFi applications
[25], [26], [27]; account management-related risks due to user
errors and design risks due to faultily designed smart contracts
[19]. We mitigate some of these risks, firstly, by integrating
a stablecoin cryptocurrency to our smart contract to isolate
our DeFi instrument against cryptocurrency price volatility
[28]. Further, we mitigate design risk by ensuring that the core
features of traditional CfDs are maintained in bed, as will be
seen in Section II.
The rest of this paper is structured as follows. Section II

presents the design methodology of the bed financial instrument.
Section III presents the test platform used to showcase the
workings and value of bed. Section IV demonstrates the
expected functioning of bed. Section V concludes this paper.

II. Methodology
Traditional CfD instruments, while hedging generators

and offtakers against price risk, present new risks to them:
counterparty credit, margining, third-party, and legal risks.
They also incur high costs and entail underlying process risks.
In this section, we describe the structure of our DeFi CfD
instrument that addresses these issues, under the assumption
that the pool market as in Fig. 1 is maintained. Our proposed
financial instrument (see Fig. 3) resides in the financial market,



4

Fig. 3. Schematic of the bed financial instrument which enforces an enduring
on-chain bilateral CfD arrangement between numerous parties in parallel to
the pool market for electricity.

which operates alongside the pool market and is available to
market participants along with other electricity derivatives.
Developing DeFi financial instruments can be challenging

since the blockchain smart contract that underpins their
operation must retain the equivalent legal, technical, and
commercial functionalities of the traditional contract that they
replace [19]. This illustrates the importance of the business
logic, the core rules of the smart contract, where all the
asset-handling functionalities and incentive mechanisms that
encourage rational behavior are housed [1]. Central to the
embodiment of the smart contract’s business logic for our
proposed DeFi financial instrument is a novel autonomous
collateralization and settlement mechanism. Here, we will show
how these mechanisms within the smart contract incentivize
contracting parties that do not have to trust or know each other
to maintain an enduring CfD hedging arrangement.

Traditional CfD instruments can be exposed to high margin-
ing risks because of the non-frequent settlement times of the
bureaucratic clearing and settlement intermediaries that manage
CfD payoffs of contracting parties [10]. To remove the need
for a clearing and settlement intermediary, we propose a novel
autonomous settlement mechanism. This mechanism ensures
that at every trading period, the on-chain escrow account of
each contracting party is immutably updated with their CfD
payoff by the smart contract following receipt of the spot price
feed. This makes settlement more rapid and dependable and
mitigates margining risks. Moreover, the settlement calculations
are automated in a way that is immune to interference from
any party.
Counterparty credit risk is one of the main risks posed to

contracting parties in a derivative transaction: what if a party
in a particular bilateral arrangement fails or refuses to cross-
subsidize its counterparty? In traditional CfDs, the clearing
and settlement human intermediary is tasked with holding

collaterals of parties to reduce their credit risk exposure during
settlement. And in the event of a default, the counterparty
can seize these collaterals [29]. The challenge of designing a
blockchain-based CfD arrangement is, therefore, in determining
how non-trusting or possibly anonymous contracting parties
can be compelled to fulfill their bilateral cross-subsidizing
obligations without the third-party risks introduced by human
intervention.

To this end, we propose a novel autonomous collateralization
mechanism that mitigates counterparty credit risk on-chain and
in a fully autonomous way. Our collateralization mechanism
leverages financial incentives to encourage contracting parties
to secure and maintain collateral in an escrow account within
the smart contract until the end of their agreement duration.
Importantly, this escrow account is the same account where
the CfD payoff settlement due to a contracting party is credited
and debited from. Hence, contracting parties are inherently
incentivized to monitor the escrow accounts of their bilateral
counterparty and invoke a default call1 if they fall below the
minimum escrow requirement.
To hedge the cryptocurrency volatility risk inherent in

DeFi applications, we integrate a stablecoin into our smart
contract [28]. A stablecoin is a cryptocurrency that is directly
pegged to a relatively-stable fiat currency. Again, the stablecoin
service introduces an attack vector and thus exposes the smart
contract to security risks. Stablecoin services are, however,
seen as a mature technology supporting a proliferation of DeFi
applications, such as in [30]. The rest of this section presents
a more in-depth design of the proposed illustrative business
logic.

A. Autonomous settlement mechanism imposed on parties
enrolled in the bed smart contract

Traditional CfD instruments can be exposed to high margin-
ing risk, a financial risk that potential cash flows are lower
due to the payment of maintenance margins [9]. The high
margining risks prevalent in traditional CfD instruments are a
result of the non-frequent settlement times of the bureaucratic
clearing and settlement intermediaries that enforce CfD payoffs
of contracting parties [1], [5]. To remove the need for a clearing
and settlement intermediary, we propose a novel autonomous
settlement mechanism. The autonomous settlement mechanism
is directly enforced by a function within the smart contract
itself. At every trading period, this function calculates the CfD
payoff due to each contracting party based on a spot price
feed into the smart contract, as shown in Fig. 4. Thereafter,
it autonomously updates the escrow account of the respective
contracting parties based on their calculated CfD payoffs.
The CfD payoff ? for a generator 8 at every trading period
∀C ∈ ) is shown in (1) [1]. + is the contracted volume, BC is
the spot price, and  is the strike price. From (1), if the strike

1This is a function within the bed smart contract that can be called by
a contracting party when its bilateral counterparty defaults on its minimum
escrow requirement.



5

Fig. 4. Flow chart of the procedure for settlement that is irrevocably enforced
by the smart contract at every trading period.

price is greater than the spot price, the generator 8 receives a
payoff from the offtaker 9 , which is the product of the difference
between the strike price & spot price and the contracted volume
[5]. Otherwise, the generator 8 returns to the offtaker 9 a payoff
as in (2), which is the product of the difference between the
spot price & strike price and contracted volume [5].

? 9−→8 =

(
+ ×max

(
0,  − BC

))
(1)

?8−→ 9 =

(
+ ×max

(
0, BC −  

))
(2)

The strike price and contracted volume components of
the CfD are immutably pre-written into the smart contract.
However, the smart contract does not naturally have sight of
the fluctuating spot price published by the Market Operator of
the pool market at every trading period. Hence, bed needs an
oracle to provide external data to the smart contract [31], [32].
The oracle’s role here is to simply furnish the smart contract
with the spot prices of electricity traded at every period in the
pool market for electricity.
After every trading period ∀C ∈ ) , the escrow accounts

of the contracting parties are updated based on (1) and (2).
In summary, when a call is made to the function that en-
forces autonomous settlement, three processes are implemented
sequentially. First, the spot price is obtained from the oracle.
Secondly, the CfD payoff is computed within the smart contract.
Lastly, the escrow accounts of the contracting parties are
directly updated based on the calculated payoff. Contracting
parties, as they deem fit, can then make withdrawals from
their escrow account in the case of a positive CfD payoff

Algorithm 1 : Autonomous settlement mechanism
Input: BC
1: \\ For all pairs ďż˝= of enrolled contracting parties (gener-

ators 8 and offtakers 9), do the following:
2: for =←− 1 to �= do
3: \\ Check if the strike prices  ==8, 9 of the contracting

parties are greater than the spot price BC .
4: if

(
 ==8, 9 > BC

)
then

5: \\ (1) Calculate the CfD payoff ?, where +==8, 9
is the contracted volume (2) Update the escrow
accounts ďż˝==8, 9 of contracting parties (i.e. top-up the
escrow accounts of the generators ďż˝==8 with ? and
deduct ? from the escrow accounts of their bilateral
counterparties – the offtakers �== 9 ).
let ? =

(
 ==8, 9−BC

)
×+==8, 9 , �==8 =

(
ďż˝==8 + ?

)
, ďż˝== 9

=
(
ďż˝== 9 - ?

)
6: \\ Check if the strike prices  ==8, 9 of the contracting

parties are less than the spot price BC .
7: else if

(
 ==8, 9 < BC

)
then

8: \\ (1) Calculate the CfD payoff ? (2) Update the
escrow accounts ďż˝==8, 9 of contracting parties (i.e. top-
up the escrow accounts of the offtakers ďż˝== 9 with
? and deduct ? from the escrow accounts of their
bilateral counterparties – the generators �==8).

9: let ? =
(
BC −  ==8, 9

)
× +==8, 9 , �== 9 =

(
ďż˝== 9 + ?

)
,

ďż˝==8 =
(
ďż˝==8 - ?

)
10: else
11: \\ Revert transaction to the initial state
12: end if
13: end for

or make deposits to their escrow account in the case of a
negative CfD payoff. Fig. 4 and Algorithm 1 demonstrates the
sequence of execution of the autonomous settlement mechanism.
Importantly, this chaincode will irrevocably and irrefutably
execute once the smart contract is committed to the blockchain.

B. Autonomous collateralization mechanism imposed on parties
enrolled in the bed smart contract
Counterparty credit risk is one of the main risks of con-

tracting parties in a derivative transaction because a party
in a particular bilateral arrangement may not have the funds,
or the willingness, to follow through on its cross-subsidizing
obligations [9]. To derisk counterparty credit exposure on-
chain and in a fully autonomous way, we propose a novel
collateralization mechanism. Here, collaterals are held within
the smart contract on behalf of contracting parties for settlement
purposes. This approach is unlike traditional CfDs where
collaterals are held by a trusted intermediary, which exposes
the contracting parties to third-party risks [29]. It is imperative
that the collaterals held in escrow accounts within the smart
contract are sufficient to incentivize rational behavior amongst



6

contracting parties; hence, aligning with the CfD’s purpose as
an enduring hedging arrangement. For this reason, designing a
suitable collateralization mechanism is the core problem for
such a blockchain derivative instrument.
Key to collateral management is maintenance margin. The

maintenance margin of a contracting party reflects its credit
exposure to its counterparty in the smart contract at every
instance [9]. Another important aspect of collateral is termi-
nation penalty. Termination penalties are usually included in
derivative contracts that afford contracting parties the option
to leave the contract before the end of the agreement duration
[19]. The termination penalty must be adequate to discourage
contracting parties from prematurely exiting the contract [19].
To ensure that contracting parties always have sufficient

funds in their escrow accounts to make settlement payments
due to their bilateral counterparty, we propose that their
minimum maintenance margin ""<8=

∀C ∈) is equal to or greater than
maximum CfD payoff ?<0G that can be due to the generator 8
or offtaker 9 at every trading period as in (3). This requirement
is imposed in the bed smart contract because our proposed
settlement mechanism ensures autonomous CfD payoffs due
to contracting parties every trading period, which limits their
counterparty credit exposure to only a single trading period. The
maximum CfD payoff ?<0G that can be due to the generator 8
from the offtaker 9 at every trading period is represented in (4).
On the other hand, the maximum CfD payoff ?<0G that can
be due to the offtaker 9 from the generator 8 at every trading
period is shown in (5). Therefore, the minimum maintenance
margin becomes as in (6).

""<8=
∀C ∈) ≥ ?

<0G (3)

?<0G9−→8 = argmax
BC

(
+ × (BC −  )

)
(4)

?<0G8−→ 9 = argmin
BC

(
+ × ( − BC )

)
(5)

""<8=
∀C ∈) ≥ <0G

(
?<0G9−→8 , ?

<0G
8−→ 9

)
(6)

From (4) and (5), it is evident that the max and min limits of
the volatile spot price BC defines the ?<0G and thus the ""<8=

∀C ∈)
of contracting parties. Contracting parties have the liberty to
propose a suitable maintenance margin during enrollment in
a particular bilateral CfD arrangement in the smart contract.
However, we propose that their selection must satisfy (7) to
reflect the practically possible volatility band of the spot price
BC [8]. If (7) holds, then the ""<8=

∀C ∈) of the bed smart contract
becomes as in (8).

0 ≤ BC ≤ 2 (7)

""<8=
∀C ∈) ≥  ×+ (8)

Fig. 5. Management levels of collateral to be maintained by contracting parties
enrolled in the bed smart contract.

Contracting parties can exit the smart contract prematurely
(i.e., before the end of the agreement duration), either voluntar-
ily or due to a default on their minimum escrow requirement
'<8=∀C ∈) . However, to discourage them from exiting the smart con-
tract prematurely, we propose a termination penalty premium
payment. Contracting parties can offer a suitable termination
penalty ! during enrollment in a particular bilateral CfD
arrangement in the smart contract [1]. Therefore, the minimum
escrow requirement '<8=∀C ∈) that must be maintained by each
contracting party in bed is the sum of its maintenance margin
""<8=
∀C ∈) and termination penalty ! as in (9). The minimum

escrow requirement essentially ensures that each contracting
party has sufficient funds in their escrow account to reduce
their credit risk exposure to their bilateral counterparty and to
allow for termination penalty payment to their counterparty if
they prematurely exit the contract.

'<8=∀C ∈) = ""<8=
∀C ∈) + ! (9)

Collaterals held in escrow accounts of contracting parties in
the smart contract could look like Fig. 5. Contracting parties
are incentivized to watch the escrow accounts of their bilateral
counterparties in the smart contract and invoke a default call
if they fall below the minimum escrow requirement. Hence,
contracting parties are incentivized to maintain their collaterals
above the minimum escrow requirement (i.e., at the escrow
buffer region) to avoid liquidation of their escrow accounts in
the smart contract. Nonetheless, contracting parties can choose
to leave the smart contract before the end of the agreement
duration in exchange for a termination penalty payment. The
process for enrolling in, and prematurely exiting the smart
contract are detailed in Section II-C and II-D, respectively.

C. Enrolling in a particular bilateral CfD arrangement in the
bed smart contract
Parties that intend to enter bed must follow this four-stage

route: positioning, offering, staking and registering (see Fig. 6).



7

Fig. 6. Four-stage route for enrolling in a particular bilateral CfD arrangement
in the bed smart contract.

First, they indicate their interest in entering the smart contract
by defining their position (i.e., either as a generator or an
offtaker) in the contract. While defining their position in the
contract, they offer their CfD terms to the market. That is, a
strike price  per mwh, volume2 + in mwh, CfD agreement
duration * and termination penalty !. To discourage sham
registrations, we propose that parties, while enrolling in the
smart contract, place an expression of interest deposit ďż˝ as
in (10). Essentially, the ďż˝ to be lodged by contracting parties
must not be less than the minimum escrow requirement '<8=∀C ∈)
calculation of the CfD terms they have offered. Participants can
then begin observing the smart contract’s events to determine
when a counterparty with a similar strike price, volume,
termination penalty, and agreement duration has expressed
its interest to register in the contract. The ability to watch these
events is usually programmable in most public blockchains and
could be facilitated with a suitable front-end application [33].

� ≥ '<8=∀C ∈) (10)

When a participant finds a counterparty that shares similar
terms with them, they register themselves and the particular
counterparty into the smart contract as a pair ďż˝= using the next
available sequential id pair count (ďż˝= + 1). Alternatively, they
wait until a counterparty with compatible terms registers into
the smart contract as a pair. This generator-offtaker (8, 9) pair
requirement is enforced by Algorithm 2, since bed is effectively
a bilateral forward contract marketplace that requires that the
number and contracting terms of generator 8 and offtaker 9
correspond. Following registration, the express";"""date"",""2021-03-02T12:36:05Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""8"",""157"",""149"",""171"",""115"",""6"",""1"",""0"",""0""
""pdf:PDFVersion"",""1.5""
""xmp:CreatorTool"",""TeX""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dcterms:created"",""2021-03-02T12:36:05Z""
""language"",""en""
""Last-Modified"",""2021-03-02T12:36:05Z""
""dcterms:modified"",""2021-03-02T12:36:05Z""
""dc:format"",""application/pdf; version=1.5""
""Last-Save-Date"",""2021-03-02T12:36:05Z""
""pdf:docinfo:creator_tool"",""TeX""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2021-03-02T12:36:05Z""
""meta:save-date"",""2021-03-02T12:36:05Z""
""pdf:encrypted"",""false""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.21 (TeX Live 2020) kpathsea version 6.3.2""
""modified"",""2021-03-02T12:36:05Z""
""Content-Length"",""1848146""
""pdf:hasMarkedContent"",""false""
""Content-Type"",""application/pdf""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.21 (TeX Live 2020) kpathsea version 6.3.2""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""trapped"",""False""
""meta:creation-date"",""2021-03-02T12:36:05Z""
""created"",""2021-03-02T12:36:05Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""12""
""Creation-Date"",""2021-03-02T12:36:05Z""
""resourceName"",""26665034.pdf""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""4083"",""4878"",""5186"",""4477"",""3393"",""3809"",""3709"",""3653"",""2941"",""2047"",""4879"",""3831""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""producer"",""pdfTeX-1.40.21""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""pdfTeX-1.40.21""
""pdf:docinfo:created"",""2021-03-02T12:36:05Z""
";https://scholar.google.ch/scholar?start=30&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2021
1619099129-465;https://scholar.google.ch/scholar?as_ylo=2021&q=oracles+blockchain&hl=fr&as_sdt=0,5;Blockchain for Secure and Transparent Track-and-Trace in Manufacturing;E Kurniawan, D Benda, S Sun, SG Tan… ; … Industry 4.0: The Model …, 2021  books.google.com;;"… in which a distributed transaction ledger was used as base for a cryptocurrency called Bitcoin …

Membership service provider who maintains the mapping between a crypto- graphic identity … world

state of all the business objects maintained, along with the blockchain of transaction …";Les 2 versions;;null;;;;https://scholar.google.ch/scholar?start=50&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2021
1619099111-425;https://scholar.google.ch/scholar?as_ylo=2021&q=oracles+blockchain&hl=fr&as_sdt=0,5;What Blockchain Technology Can Do to Contribute to Waqf;C Vidiati, E Hendra, S Santoso… ; alAfkar, Journal For …, 2021  alafkar.com;;"… need to rely on external services, which take data from the ""real"" world (for example, from death

records) and push it to the blockchain (or vice versa), these services are referred to as

""oracles""36, taking into account the example of a tester, an oracle could examine …";Les 3 versions;Version HTML;[PDF] al-afkar.com;https://al-afkar.com/index.php/Afkar_Journal/article/download/158/91;"
       Vol. 4, No. 1,  Februari 2021 
      P-ISSN : 2614-4883;  E-ISSN : 2614-4905   
         https://al-afkar.com/index.php/Afkar_Journal/issue/view/4 

      DOI:  

53 

 

al-Afkar, Journal for Islamic Studies 
 https://al-fkar.com/index.php/Afkar_Journal/issue 
/view/4 

 

Copyright Š 2019,  al-Afkar Journal 

 
 
 
 

What Blockchain Technology Can Do to Contribute to 
Waqf 
 
Cory Vidiati 
Institut Agama Islam Bunga Bangsa Cirebon 
E-mail: coryvidiati@bungabangsacirebon.ac.id 
 
Endang Hendra 
Islamic Economics, STAI Persis Bandung 
E-mail: Endanghendra75@gmail.com 

 
Selamet Santoso 
Islamic Education, STIT Muhammadiyah Banjar 
E-mail: stoso590@gmail.com 

 
Izzul Faturrizky 
Universitas Ahmad Dahlan, Yogyakarta 
E-mail: Izzul1900016151@webmail.uad.ac.id 

 
 

Received Revised Accepted 

20 Desember 2020 05 January 2021 23 Februari 2021 

 
Abstract 
This article supports decision-makers for the use of blockchain technology in academies and 
industry in Indonesia, considering its advantages and disadvantages. Like the current Covid 
19 pandemic, it is necessary to obtain accurate data in various economic sectors. Islamic 
economic instruments such as waqf are an important sector, proven to have played a 
significant role in socio-economy throughout history, as a philanthropic tool and contribute 
to Islamic civilization. If developed, managed and utilized properly, it can create 
sustainability for the community. A method that relies on previous literature, this qualitative 
paper aims to contribute to encouraging the government to use blockchain for waqf. We 
outline terms and concepts related to how blockchain works and theoretical trust to 
investigate how blockchain affects the role of trust in waqf transactions. The results using 
the SWOT framework, we discuss what emerges from blockchain technology in waqf. The 
conclusion of this study discusses how blockchain can contribute to waqf instruments based 
on a conceptual framework. We hope to stimulate interest in theory and practice to 
encourage discussion in this area. 

 



  
 
 

 

Vol. 4, No. 1,Februari  2021 
P-ISSN : 2614-4883;  E-ISSN : 2614-4905   

  
 

al-Afkar, Journal for Islamic Studies 
 https://al-fkar.com/index.php/Afkar_Journal/issue 
/view/4 

 

 

 

54 
 

Corry Vidiaty et all 

What Blockchain Technology...... 

Keywords: waqf, blockchain, building information management, government policy, and 
sustainability. 

 
Introduction 

A few years ago the emergence of cryptocurrencies was met with great reluctance and 
the blockchain system was considered by many to be a disruptive core technology. Although 
many researchers have realized the importance of blockchain, blockchain research is still in 
its infancy.1 Blockchain is a pure electronic peer-to-peer version that allows online payments 
to be sent directly from one party to another without going through financial institutions.2 
Blockchain is a kind of distributed ledger maintained by network nodes, which records 
transactions executed between nodes (i.e., messages sent from one node to another). 
Information entered into the blockchain is public, and cannot be modified or deleted.3 
However, blockchain is not yet enabling a digital business revolution across the entire 
business ecosystem and perhaps not until at least 2028, the Gartner study expects 
blockchain to become fully technically and operationally scalable. By 20234, the blockchain 
platform will be scalable, interoperable, and will support smart contract portability and 
cross-chain functionality will also support transactions trusted personal with the necessary 
data confidentiality. 

A blockchain is a machine for creating a trust (Berkeley, 2015). Overall, these 
technological advances will be closer to the blockchain mainstream and decentralized web, 
also known as Web 3.0.5 This means that blockchain is expected to revolutionize computing 
in several areas, especially where centralization is unnatural and privacy is important.6 
Where the internet is the second communication revolution, a form of democratization of 
electronic communication and has invited more people into the knowledge process.7 

Waqf institution is one of the redistributive institutions that played a significant socio-
economic role throughout Islamic history, from the time of the Prophet (SAW) to the end of 
the nineteenth century.8 Historically, waqf institutions played a large role in financing 
almost all services needed in the Islamic world, such as the agricultural and industrial 
sectors, the education and health sector, basic infrastructure and transportation facilities, in 
addition to increasing business activities by creating self-employed and those that 
contribute to sustainable development.9 As described in the maqasid in Islamic finance, 

                                                             
1
 Xu, Chen, and Kou, ‘A Systematic Review of Blockchain’. 

2 Noorsanti, Yulianton, and Hadiono, ‘Blockchain - Teknologi Mata Uang Kripto (Crypto 
Currency)’; Saberhagen, ‘CryptoNote v 2.0’. 
3 Swan, Blockchain. 
4 Gartner, ‘Analysts to Discuss Technologies and Trends Shaping the Future of IT and 
Business at Gartner IT Symposium/Xpo 2019’. 
5 Gartner; Xu, Chen, and Kou, ‘A Systematic Review of Blockchain’. 
6 Davidson, De Filippi, and Potts, ‘Blockchains and the Economic Institutions of Capitalism’; 
Turk and Klinc, ‘Potentials of Blockchain Technology for Construction Management’. 
7
 Bagchi, ‘Factors Contributing to Global Digital Divide’; McGivern, ‘Media and Technology’; 

OECD, ‘Policy Roundtables’; Turk, ‘Communication Revolutions – How They Changed It 
All’; van Dijk and Hacker, ‘Digital Democracy’; Wekke, Demokrasi di Era Digital. 
8 Hasanah, ‘Laporan Akhir Tim Pengkajian Tentang Aspek Hukum Wakaf Uang’; 
Kementerian Hukum dan HAM 2019, ‘buku DPHN Final 2019’. 
9 Ali, Hassan, and Ali, Revitalization of Waqf for Socio-Economic Development, Volume II; 
Mohsin et al., Financing the Development of Old Waqf Properties. 



  
 
 

 

Vol. 4, No. 1,Februari  2021 
P-ISSN : 2614-4883;  E-ISSN : 2614-4905   

  
 

al-Afkar, Journal for Islamic Studies 
 https://al-fkar.com/index.php/Afkar_Journal/issue 
/view/4 

 

 

 

55 
 

Corry Vidiaty et all 

What Blockchain Technology...... 

namely circulating wealth, fair and transparent financial practices and justice at the micro 
and macro levels. To achieve this goal, sharia provides means (wasa'il) such as facilitating 
financial contracts, setting values and standards and institutionalizing social responsibility.10 
Expansion of the object and subject of waqf (waqf) increases the value of waqf, this is where 
an integrated, reliable technology system is needed, both in security and data collection 
(input-output). Inefficient distribution of asset utilization, inefficient waqf management, 
lack of governance and accountability and the liquidity nature of land assets can limit waqf11, 
therefore, blockchain has the potential to overcome some of these problems that hinder the 
industry from using BIM (building information management) such as confidentiality, origin 
tracking, disintermediation, non-repudiation, multiparty aggregation, inter-organization 
traceability of records, change tracking, data ownership, etc.12 

Blockchain has shown promising application prospects. From early cryptocurrencies 
to today's smart contracts, blockchain has been implemented in many fields.13 Blockchain 
has many benefits such as decentralization, persistence, anonymity and auditability. There 
are lots of blockchain applications ranging from cryptocurrency, financial services, risk 
management, the internet of things (IoT) to public and social services 14, such as research 
that has been carried out by the banking sector 15, studies on banking in Korea16 and India17; 
fintech18. A study of blockchain-based insurance19 that peer-to-peer insurance, blockchain 
and smart contracts could be key technologies to enable a shift to full decentralization, for 
example, supporting automated management of self-insured group funds, insurance has the 
advantage of tracking the sender of transactions and all previous transactions, reducing the 
risk of data disruption, increasing automation of existing tasks, public blockchain can be 
useful for managed (automated) payments with existing cryptocurrencies, or when there is a 
need to provide trust. Blockchain studies from the viewpoint of waqf management regarding 
movable and immovable assets can serve as a new model for management waqf.20 

This article also offers blockchain-based waqf management. The author decided to 
focus on waqf because, in this sector, blockchain technology can have a significant and 
relevant impact. In particular, combining IoT (Internet of things) in blockchain-based 
solutions and blockchain deployment levels to validate individual and asset identities.21 The 
government has considered waqf as part of economic progress by increasing participation in 
certain well-established projects to boost the economy, such as the waqf link sukuk and the 
waqf link sukuk. The hope is that the waqf blockchain can provide efficiency, transparency, 

                                                             
10 Akram Laldin and Furqani, ‘Developing Islamic Finance in the Framework of Maqasid al-
Shari’ah’. 
11 Sukmana, ‘Peluang dan Tantangan Penggunaan Blockchain dalam Perwakafan Nasional’. 
12 Turk and Klinc, ‘Potentials of Blockchain Technology for Construction Management’. 
13 Li et al., ‘A Survey on the Security of Blockchain Systems’. 
14 Wang et al., ‘Blockchain Challenges and Opportunities’. 
15 Garg et al., ‘Measuring the Perceived Benefits of Implementing Blockchain Technology in 
the Banking Sector’. 
16

 Yoo, ‘Blockchain Based Financial Case Analysis and Its Implications’. 
17 Patki and Sople, ‘Indian Banking Sector’. 
18

 Chang et al., ‘How Blockchain Can Impact Financial Services – the Overview, Challenges 
and Recommendations from Expert Interviewees’. 
19 Gatteschi et al., ‘Blockchain and Smart Contracts for Insurance’. 
20 Zulaikha and Arif Rusmita, ‘Blockchain for Waqf Management’. 
21 Kshetri, ‘Blockchain’s Roles in Meeting Key Supply Chain Management Objectives’. 



  
 
 

 

Vol. 4, No. 1,Februari  2021 
P-ISSN : 2614-4883;  E-ISSN : 2614-4905   

  
 

al-Afkar, Journal for Islamic Studies 
 https://al-fkar.com/index.php/Afkar_Journal/issue 
/view/4 

 

 

 

56 
 

Corry Vidiaty et all 

What Blockchain Technology...... 

security and consistency, can provide real-time personal social matrix analytics, can perform 
transaction tracing through smart contracts, has audit capabilities that are recorded 
sequentially and indefinitely 22 provide benefits for all parties. Nonetheless, more so than 
that government involvement signifies a stricter bureaucracy for compliance as a legal 
umbrella. The main purpose of this article is to stimulate reflection and discussion on the 
topic of waqf, leaving the reader for the final judgment on the actual benefits that can come 
from the adoption of the technology considered in a particular scenario. The writer uses 
SWOT analysis in a broader context to analyze outside the waqf domain. 
 
Results 

A cryptocurrency (or crypto or cryptocurrency for short) is a digital asset designed to 
work as a medium of exchange whereby individual coin ownership records are stored in an 
existing ledger in the form of a computerized database that uses strong cryptography for 
secure transaction records, coin generation controls addition, and to verify the transfer of 
coin ownership. These usually do not exist in physical form (such as banknotes) and are not 
usually issued by a central authority. Cryptocurrencies generally use decentralized controls 
as opposed to centralized digital currencies and central banking systems. When 
cryptocurrencies are minted or created before they are issued or issued by a single publisher, 
they are generally considered centralized. When implemented with decentralized control, 
each cryptocurrency works via distributed ledger technology, usually blockchain, which 
functions as a database of public finance transactions. 

In Indonesia itself, cryptocurrency regulations have been regulated by Bappebti. 
Through Bappebti Regulation No. 5 of 2019, cryptocurrency assets are recognized as 
commodities that can be traded on a futures exchange. This regulation makes the 
cryptocurrency industry already have a clear legal umbrella and is increasingly developing in 
Indonesia. This regulation makes the cryptocurrency industry have a clear legal umbrella 
and is increasingly developing in Indonesia. Research results23 indicate that blockchain 
technology can be regulated based on Book III of the Civil Code and ITE Law as well as the 
application of smart contracts can also be regulated based on Book III of the Civil Code and 
the ITE Law. Smart contracts are different from standard contracts stipulated in the 
Consumer Protection Law. 

Cryptocurrency or cryptocurrency has now become one of the favourite investment 
instruments in Indonesia. Not only that, but cryptocurrencies are also rapidly developing 
into alternatives to cashless transactions, such as remittances and cross-border transactions. 
This is in line with the Indonesian people who begin to become financially literate and the 
latest technological developments. Cryptocurrency uses blockchain technology that is 
decentralized, transparent, and global. Transactions using cryptocurrency on a blockchain 
network are believed to be a solution to various problems facing the conventional financial 
system. Blockchain is considered to be a potential driver of the digital economy. Blockchain 
technology exceeds the challenges associated with traditional transaction businesses that are 
regulated and regulated by trusted third parties.24 
 
 

                                                             
22 Sukmana, ‘Peluang dan Tantangan Penggunaan Blockchain dalam Perwakafan Nasional’. 
23 Serfiyani and Serfiyani, Kajian Hukum Tehnologi Blockchain dan Kontak Pintar di Industri 
Jasa Keuangan. 
24 Upadhyay, ‘Demystifying Blockchain’. 



  
 
 

 

Vol. 4, No. 1,Februari  2021 
P-ISSN : 2614-4883;  E-ISSN : 2614-4905   

  
 

al-Afkar, Journal for Islamic Studies 
 https://al-fkar.com/index.php/Afkar_Journal/issue 
/view/4 

 

 

 

57 
 

Corry Vidiaty et all 

What Blockchain Technology...... 

How Blockchain Works 
Blockchain is called blockchain research scenario introduced25 to transfer online 

payments from one party to another, without relying on intermediaries, where the 
blockchain acts as a ledger that underlies the recording of transfers and ensures trust in a 
way cryptographic operations, authentication and denial of payment. Since 2008 more than 
5400 cryptocurrencies have been created26 which are used as exchange tokens in many 
blockchain-based applications. The core concepts behind blockchain technology are as 
follows:27 
1) Transaction: every digital currency transfer from one subject to another currency is 

represented as a transaction from A to B. Cryptocurrency is neither a physical object nor 
software, but the results of incoming and outgoing transactions. For this reason, 
blockchain keeps track of all transactions occurring since its inception. 

2) Block: transactions are grouped into blocks. Each block collects all transactions that 
occur within a given time frame and stores a reference to the previous block (that's where 
the ""chain"" concept comes from). 

3) Nodes: instead of being stored in a centralized database, blockchains are spread over a 
network of computers (""nodes""), each containing a local copy of the entire blockchain. 

4) Majority consensus: since central authority does not exist, decisions on the network are 
made according to majority consensus. Each node modifies a local copy of the blockchain 
to create it reflects the status of the majority of network nodes. 

5) Mining: nodes can passively store a copy of the blockchain, or actively take part in 
maintaining the blockchain, in a process called ""mining"". During mining, nodes check 
previous transactions to verify whether the subject is entitled to spend a certain amount 
of cryptocurrency and, whenever a block has to be added to the chain, solve a complex 
computational-intensive math problem. This issue is specifically designed to limit the 
possibility of malicious entities manipulating the blockchain by faking transactions. The 
attack probability is very low because adding new (malicious) blocks or modifying 
previously added blocks to the chain would require control of the majority of network 
nodes (to make them agree to the modifications). 

6) Wallets: people transfer cryptocurrency using wallets. Cryptocurrency cannot be kept in 
physical memory; instead, it is the result of a previous transaction. Hence, the wallet only 
stores credentials (a complex and immutable combination of automatically assigned 
numbers and letters), which allows blockchain users to transfer the cryptocurrency they 
own. Each wallet is associated with one (or more) unique addresses. If a user wants to 
send a certain amount of cryptocurrency to a peer, he must specify the recipient's address 
and the desired amount, and use the credentials to validate the transaction. This aspect is 
especially important because, in the case of losing credentials, the cryptocurrency owned 
by the user will not ""disappear"", but the user will no longer be able to spend it. Moreover, 
the fact that the user validates a transaction with credentials stating that he is the real 
initiator of the transaction. 

In this sense it allows readers to become more familiar with the main characteristics of 
blockchain, which makes it a disruptive technology:28 

                                                             
25

 Nakamoto, ‘Bitcoin: A Peer-to-Peer Electronic Cash System’; Nath, ‘Bitcoin Technology: A 
Peer-to-Peer Digital Cash Transaction’. 
26 CoinMarketCap, ‘Top 100 Cryptocurrencies by Market Capitalization’. 
27 Gatteschi et al., ‘Blockchain and Smart Contracts for Insurance’. 
28 Gatteschi et al. 



  
 
 

 

Vol. 4, No. 1,Februari  2021 
P-ISSN : 2614-4883;  E-ISSN : 2614-4905   

  
 

al-Afkar, Journal for Islamic Studies 
 https://al-fkar.com/index.php/Afkar_Journal/issue 
/view/4 

 

 

 

58 
 

Corry Vidiaty et all 

What Blockchain Technology...... 

1) Data redundancy: each network node has a local copy of the blockchain, which prevents 
data loss; 

2) Data immutability: data stored on the blockchain cannot be modified or deleted; 
3) Trust: cryptography enables trust between parties because transactions that have been 

validated using user credentials cannot be rejected; 
4) Transparency: everyone can read the blockchain and the transactions stored on it. 
Other characteristics of blockchain:29 
5) Decentralized. Blockchain uses a distributed network model with a consensus algorithm 

to maintain data consistency in its network. 
6) Be persistent. It is almost impossible to delete or rollback transactions that have occurred 

on the blockchain network. Blocks containing invalid transactions can be found 
immediately. 

7) Anonymous. Each user can interact on the blockchain with the generated address, which 
does not reveal the user's real identity. This is a characteristic of the blockchain, although 
user anonymity is not always maintained due to intrinsic limitations. 

8) Can be audited. Transactions on the blockchain can be easily verified and tracked. 
Bitcoin, as an example of using blockchain, stores user data in the Unspent Transaction 
Output (UTXO) model. Each transaction must refer to previous transactions that have 
not been used. 

Given the above about cryptocurrency transfers, the possibilities for blockchain applications 
are not limited to monetary assets but can cover a wide variety of use cases. Among the early 
application scenarios explored for blockchain, it is necessary to keep in mind the context of 
the writing. Because the blockchain is immutable and publicly available, researchers are 
advised to use it for keeping public records and endorsements.30 Another domain where 
blockchain has been recognized to bring significant benefits is intellectual property 
protection. In this context, blockchain technology can be used to prove/state the existence 
of documents at a certain time.31 
 
Figure 2 Basics of how blockchain works32 

 

                                                             
29

 Arief and Sundara, ‘Studi Atas Pemanfaatan Blockchain Bagi Internet of Things (IoT)’; 
Wang et al., ‘Blockchain Challenges and Opportunities’. 
30 Swan, Blockchain. 
31 Rosa et al., A Survey of Blockchain Technologies for Open Innovation. 
32 Wild, Arnold, and Stafford, ‘Technology: Banks Seek the Key to Blockchain’. 



  
 
 

 

Vol. 4, No. 1,Februari  2021 
P-ISSN : 2614-4883;  E-ISSN : 2614-4905   

  
 

al-Afkar, Journal for Islamic Studies 
 https://al-fkar.com/index.php/Afkar_Journal/issue 
/view/4 

 

 

 

59 
 

Corry Vidiaty et all 

What Blockchain Technology...... 

Looking at the above concept, the researcher realized that blockchain could also be 
used to store other types of assets, including code snippets. It was the birth of ""smart 
contracts"", ie small programs that are stored on the blockchain and programmed to behave 
independently in certain ways when several conditions are met. The idea of smart contracts 
has been known since the 90s33 but only with blockchain technology and, in particular, with 
the Ethereum blockchain34 (perhaps the most famous blockchain after bitcoin), smart 
contracts are capable of releasing their full potential.35 With smart contracts, a person can, 
for example, encode his wishes on the blockchain on the internet in the form of a set of 
rules. 

In the case of waqf based on sharia insurance, for example, due to insurance customer 
lapse or death, the smart contract can then automatically inform the termination of wakif in 
the system because the contract agreement ends. Examiners can also provide additional 
constraints in the waqf system to obtain real-time information. Since smart contracts are 
based on data stored on the blockchain, they need to rely on external services, which take 
data from the ""real"" world (for example, from death records) and push it to the blockchain 
(or vice versa), these services are referred to as ""oracles""36, taking into account the example 
of a tester, an oracle could examine the insurance customer's lapse records/insurance 
customer's death to identify whether the person defaulted/died. If so, it can write this 
information on the blockchain (eg by changing the boolean value of the variable indicating 
whether the person is alive or not). The smart contract, then, will trigger a conditional 
statement (based on the variable value), and run the code block that initiates the 
stop/money transfer. Recently, more complex applications of smart contracts and prophecy 
have been proposed, related to the concept of Decentralized Autonomous Organizations, or 
DAOs.37 In this context, smart contracts are used to encode the rules for governing an 
organization, for example how decisions are taken on the vote weight of each member, etc. 
The advantage is that no external party is required to verify that the organization is well 
managed, and the underlying rules can be verified by the wider community, ensuring 
transparency and trust. 
 
Blockchain application for Waqf 

The dynamics of waqf development in Indonesia are increasingly diverse, starting with 
conventional waqf in the form of land that has been partially recorded in BWI (KUA at the 
regional level)38 where the potential for waqf in Indonesia is asset waqf Rp. 2,000 trillion / 
year and cash waqf of Rp. 188 trillion/year, the realization of Rp. 400 billion. Another waqf 
asset developed is cash waqf in collaboration with professional nadzir such as bank and non-

                                                             
33 Szabo, ‘Smart Contracts’; Szabo, ‘Smart Contracts: 12 Use Cases for Business & Beyond’. 
34 Baird et al., ‘The Economics of Smart Contracts’; Beck et al., Blockchain – the Gateway to 
Trust-Free Cryptographic Transactions. 
35 Sillaber et al., ‘Laying the Foundation for Smart Contract Development: An Integrated 
Engineering Process Model’. 
36

 fintech, ‘Oracle Exec: 50% Perusahaan Akan Menggunakan Teknologi Blockchain dalam 
Tiga Tahun Selanjutnya’; Mou, ‘Penjelasan Mengenai Oracle Blockchain Bagikan’; Swanson, 
‘Consensus-as-a-Service: A Brief Report on the Emergence of Permissioned, Distributed 
Ledger Systems’. 
37 Academic, ‘DAO’; Beck et al., Blockchain – the Gateway to Trust-Free Cryptographic 
Transactions; CW.Club, ‘There’s Now a DAO for Deciding Which Blockchains to Stake On’. 
38 BWI, ‘Data Tanah Wakaf Bersertifikat di Indonesia’. 



  
 
 

 

Vol. 4, No. 1,Februari  2021 
P-ISSN : 2614-4883;  E-ISSN : 2614-4905   

  
 

al-Afkar, Journal for Islamic Studies 
 https://al-fkar.com/index.php/Afkar_Journal/issue 
/view/4 

 

 

 

60 
 

Corry Vidiaty et all 

What Blockchain Technology...... 

bank financial institutions. Even waqf can directly contribute to development through share 
waqf (sukuk link waqf/wakaf link sukuk). Optimization of data collection that is still around 
individual nadzir and professional nadzir is still not optimal because each nadzir makes 
recording not integrated. There are still waqf lands that are disputed and ultimately cannot 
be managed for the public interest. There is also a need for imperative action on the data 
collection of individual nadzirs as well as professional/institutional nadzirs, both productive 
waqf and cash waqf. And many other waqf problems can be anticipated with blockchain so 
that the flow of waqf from the start to its realization can be seen as transparent, reliable and 
real-time for mauquf ālaih and sustainability of development. The following is an overview 
of waqf in Indonesia:39 

  
 
Seeing the above description, blockchain must centralize real-time national waqf data, for 
transparency of transactions in land/property waqf and cash waqf; avoiding corruption, 
money laundering; integrated property development easy to trace; crowdfunding for 
property development; liquidity in land assets. Through the tokenization system40 for waqf 
in the blockchain is described as follows:41 

                                                             
39

 Anggraito, ‘Blockchain Waqf, Usecase: Telkom Blockchain Wakaf (Kerjasama Telkom & 
BWI)’. 
40

 Davidson, De Filippi, and Potts, ‘Blockchains and the Economic Institutions of Capitalism’; 
Rosa et al., A Survey of Blockchain Technologies for Open Innovation; Swanson, ‘Consensus-
as-a-Service: A Brief Report on the Emergence of Permissioned, Distributed Ledger Systems’. 
41 Anggraito, ‘Blockchain Waqf, Usecase: Telkom Blockchain Wakaf (Kerjasama Telkom & 
BWI)’. 



  
 
 

 

Vol. 4, No. 1,Februari  2021 
P-ISSN : 2614-4883;  E-ISSN : 2614-4905   

  
 

al-Afkar, Journal for Islamic Studies 
 https://al-fkar.com/index.php/Afkar_Journal/issue 
/view/4 

 

 

 

61 
 

Corry Vidiaty et all 

What Blockchain Technology...... 

 
The description above indicates that waqf as part of an optimally managed socio-economy 
can bring benefits other than self and the ummah. Awakif's concern for waqf through nadzir 
both individuals and professional nadzir (institutions) which is managed transparently from 
data collection to distribution, produces maximum benefits for wakif and the ummah 
because the purpose of waqf is actually for the benefit which is channelled to the real sector 
and the social sector. 
 
SWOT analysis 

From the data and discussion above, it appears that there is great potential for waqf in 
Indonesia which is well managed using blockchain technology. Objectively, from the above 
explanation which is the waqf domain, it is analyzed as a strategic planning method. 

The strength of blockchain from the explanation above is related to the technological 
aspects presented, it can eliminate intermediaries, faster access, no bank transfer fees, no 
commission/fees in the transaction process because cryptocurrency is immediately 
transferred to the intended party. Blockchain offers a high level of automation. 
Transparency is guaranteed good because the blockchain can be accessed worldwide. Also, 
because everyone has the potential to write on a ledger, blockchain can be a repository of 
large amounts of information, which can be used for data analysis in various sectors (waqf, 
other economies such as zakat, insurance, finance, medicine, education, etc.). The 
underlying cryptographic mechanism ensures that data is not modified and transactions 
cannot be rejected. Finally, blockchain replication on each network node ensures that the 
blockchain will be safe from unforeseen events/abuse. 

The most relevant drawbacks of blockchain technology are related to scalability, 
energy consumption and performance. Currently, the number of transactions that can be 
handled per second is very low when compared to traditional systems (mainly because of the 
computation power required for that, new block validation). If at present, blockchain-based 
transactions are faster than traditional bank transfers (on average it takes seconds to 



  
 
 

 

Vol. 4, No. 1,Februari  2021 
P-ISSN : 2614-4883;  E-ISSN : 2614-4905   

  
 

al-Afkar, Journal for Islamic Studies 
 https://al-fkar.com/index.php/Afkar_Journal/issue 
/view/4 

 

 

 

62 
 

Corry Vidiaty et all 

What Blockchain Technology...... 

minutes instead of 1-2 days), for instant payments and other types of applications, 
performance should not be sufficient for the needs. In this regard, it should be underlined 
that some blockchain platforms are changing the process from validating blocks, reducing 
the complexity of the mathematical problems to be solved and limiting the possibility of 
mining to only a portion of the trusted nodes. Regardless of the time, space is also a 
problem, because data is replicated at each network node. Human resources that are less 
professional, it still takes time for sufficient literacy 42. There is no specific legal umbrella 
regarding blockchain for waqf. For Islamic insurance-based waqf, it is necessary to consider 
a long premium tenor, it is feared that the waqf fund will not occur at the end of the 
agreement; or when the unit-linked investment funds for waqf have not developed as 
agreed. 

Waqf blockchain opportunities, competitive advantage (if efforts to reduce/hide the 
complexity behind the blockchain are successful, or in the case of IoT diffusion); the 
possibility to overcome and potential new markets (for example, to deliver services, 
currently blockchain waqf has the potential to collaborate with the sharia fintech ecosystem, 
especially payment fintech providers, to make it easier for waqif users of fintech payment 
services to channel their waqf funds); the availability of large amounts of heterogeneous 
data, driven on the blockchain by different actors, animates other economic systems. 

Threat (may be perceived as insecure/unreliable) low adoption of external factors 
means lack of information; governments may consider blockchain and smart contracts 
""dangerous""; medium-long term investment; not suitable for all existing processes; Wakif 
still considers interactions due to lack of literacy; the abuse of blockchain technology by 
hackers because everything is done computation, still requires manual recording. 

 
Discussion  

The Internet of Things (IoT) has made it possible for a variety of devices to connect to 
existing Internet networks and be controlled remotely like any other virtual information 
asset. Various potentials can be developed with this technology, but at the same time, it also 
presents new threats to the security of devices connected to the internet. Internet of Things 
(IoT) is a global infrastructure for the information society, which allows various devices 
(devices), both physical and virtual, to connect. What is meant by objects (things) are 
objects of physical objects and the world of information (virtual) that can be identified and 
integrated into a communication network. IoT allows objects to be sensed and controlled 
remotely through an existing network infrastructure. This provides an opport";"""date"",""2021-03-08T15:02:11Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.5""
""xmp:CreatorTool"",""MicrosoftÂŽ Office Word 2007""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dc:creator"",""fai""
""language"",""en""
""dcterms:created"",""2021-03-08T15:02:11Z""
""Last-Modified"",""2021-03-08T15:02:11Z""
""dcterms:modified"",""2021-03-08T15:02:11Z""
""dc:format"",""application/pdf; version=1.5""
""Last-Save-Date"",""2021-03-08T15:02:11Z""
""pdf:docinfo:creator_tool"",""MicrosoftÂŽ Office Word 2007""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2021-03-08T15:02:11Z""
""meta:save-date"",""2021-03-08T15:02:11Z""
""pdf:encrypted"",""false""
""modified"",""2021-03-08T15:02:11Z""
""Content-Length"",""736020""
""pdf:hasMarkedContent"",""true""
""Content-Type"",""application/pdf""
""pdf:docinfo:creator"",""fai""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""fai""
""dc:language"",""id-ID""
""meta:author"",""fai""
""meta:creation-date"",""2021-03-08T15:02:11Z""
""created"",""2021-03-08T15:02:11Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""19""
""Creation-Date"",""2021-03-08T15:02:11Z""
""resourceName"",""91""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""2010"",""3864"",""4145"",""3868"",""3924"",""2627"",""3979"",""2012"",""2351"",""3477"",""3335"",""4266"",""4047"",""3280"",""3595"",""3625"",""3622"",""3521"",""1096""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""Author"",""fai""
""producer"",""MicrosoftÂŽ Office Word 2007""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""MicrosoftÂŽ Office Word 2007""
""pdf:docinfo:created"",""2021-03-08T15:02:11Z""
";https://scholar.google.ch/scholar?start=10&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2021
1619099129-462;https://scholar.google.ch/scholar?as_ylo=2021&q=oracles+blockchain&hl=fr&as_sdt=0,5;A Privacy-Aware PUFs-Based Multi-Server Authentication Protocol in Cloud-Edge IoT Systems Using Blockchain;Y Zhang, B Li, B Liu, Y Hu… ; IEEE Internet of Things …, 2021  ieeexplore.ieee.org;;"… The blockchain is leveraged to store MCs, synchronize them efficiently, and incorporate the

multi-receiver encryption to share the physical identity securely. The security of our protocol is

formally proved by a random oracle model, and security features are discussed to show …";;null;null;;;;https://scholar.google.ch/scholar?start=50&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2021
1619099120-445;https://scholar.google.ch/scholar?as_ylo=2021&q=oracles+blockchain&hl=fr&as_sdt=0,5;Design Patterns for Blockchain-Based Payment Applications;Q Lu, X Xu, HMN Bandara, S Chen, L Zhu ; arXiv preprint arXiv …, 2021  arxiv.org;;"… Blockchain, Pattern, Architecture, Payment, Token, Cryptocurrency, Escrow, Channel 1

Introduction … Further, the oracle pattern can be used to introduce the external state/data

into the blockchain execution environment, which is self-contained …";Les 3 versions;Version HTML;[PDF] arxiv.org;https://arxiv.org/pdf/2102.09810;"
Design Patterns for Blockchain-Based Payment

Applications

Qinghua Lu, Xiwei Xu, H.M.N. Dilum Bandara, Shiping Chen, Liming Zhu
Data61, CSIRO, Australia

University of New South Wales, Australia
{firstname.lastname}@data61.csiro.au

February 22, 2021

Abstract

As the killer application of blockchain technology, blockchain-based
payments have attracted extensive attention ranging from hobbyists to
corporates to regulatory bodies. Blockchain facilitates fast, secure, and
cross-border payments without the need for intermediaries such as banks.
Because the blockchain technology is still emerging, systematically organ-
ised knowledge providing a holistic and comprehensive view on design-
ing payment applications that use blockchain is yet to be established. If
such knowledge could be established in the form of a set of blockchain-
specific design patterns, architects could use those patterns in designing a
payment application that leverages blockchain. Therefore, in this paper,
we first identify a token’s lifecycle and then present 15 design patterns
that cover critical aspects in enabling the state transitions of a token in
blockchain-based payment applications. The lifecycle and the annotated
design patterns provide a payment-focused systematic view of system in-
teractions and a guide to effective use of the design patterns.

Blockchain, Pattern, Architecture, Payment, Token, Cryptocurrency,
Escrow, Channel

1 Introduction

Blockchain is an emerging distributed ledger technology that has attracted a
broad range of interests from the academia and industry to build the next
generation of trustworthy applications. A large number of projects have been
conducted to explore how to re-architect systems, and to build new applications
and business models using blockchain as a general, decentralised computing and
storage environment through the advent of smart contracts (i.e., programs on a
blockchain) [1].

Payment is considered the killer application of blockchain technology, which
executes monetary transactions for goods or services previously agreed upon by

1

ar
X

iv
:2

10
2.

09
81

0v
1 

 [
cs

.S
E

] 
 1

9 
Fe

b 
20

21



Buyer Seller

Issuer

Tokens

$$$
Rules

Tokens

$$

Product

$X
Burned
tokens

$
Fiat 

currency

Figure 1: Overview of token-based payments.

all parties involved. The “money” used on a blockchain includes both cryp-
tocurrencies and tokens. Cryptocurrencies are baked into the blockchain plat-
forms as the base currency (e.g., Bitcoin and Ether) for transactions and pro-
vide incentives for blockchain platform operations (e.g., mining). Tokens are
application-tier coins that are created and exchanged using smart contracts on
the blockchain. Tokens may represent cryptocurrencies (e.g., Binance Coin and
Uniswap) or used as a proxy for fiat currency (e.g., Tether and US Dollar Coin).

Fig. 1 illustrates an overview of token-based payments. A token issuer issues
a new token associated with a set of spending rules. One or more tokens are
allocated to a buyer. For example, in the context of food stamps the issuer is
the government agency responsible for the program and buyers are the people
classified as food insecure. The spending rules may specify eligible kinds of
food, their quantities, and sellers. A buyer then purchases food products from
a seller using the allocated tokens. A seller could be a supermarket that cashes
out multiple tokens from the government agency. However, as different food
stamps may carry different spending rules, it is in the seller’s best interest to
validate them at the time of payment. This ensures that the seller can convert
the collected tokens to fiat currency for the products it sold. Alternatively, the
buyer may also want to know the authenticity of the product and whether the
seller has the authority to sell it. Once redeemed, the issuer needs to destroy
the tokens (aka., burn token) to ensure the tokens are not reused (i.e., double
spend).

As discussed in the above example, payments are usually conditional, where
they are made subject to a set of conditions. Payment conditions could be
complicated in many environments, and could range from coupons with a des-
ignated product/service and an expiration date to insurance payouts and social

2



welfare benefits. Further, the conditions need to be specified in advance (usu-
ally with the consent of parties involved in the transaction) such that they
can be checked at the time of payment. Thus, in such use cases, the currency
need to be programmable to specify payment conditions, enable automatic val-
idation and enforcement, and support immutable record-keeping of associated
transactions. These properties are well aligned with the design of tokens re-
alised by blockchains (i.e., provides immutable record-keeping and multi-party
transactions) and smart contracts (i.e., provides programmability and automatic
enforcement).

As the blockchain technology is still emerging, systematically organised knowl-
edge providing a holistic and comprehensive view on designing blockchain-based
payment applications is yet to be established. Therefore, to form such knowl-
edge, in this paper, based on a literature review and our project experience, we
collect a set of patterns that cover the critical aspects in the design of blockchain-
based payment applications. We identify the lifecycle of a payable token, in
which the identified design patterns are associated with the state transitions
along the lifecycle. The lifecycle along with the annotated design patterns, pro-
vide a payment-focused systematic view of system interactions and a guide to
the effective usage of the design patterns. In this paper, we focus on blockchain-
based payable tokens such as the ones based on ERC-13631 standard that can be
spent to purchase products or services. We also consider native cryptocurren-
cies, fungible tokens (e.g., ERC-202), and non-fungible tokens (e.g., ERC-7213)
that are used within smart contracts to attach to a specific buyer (e.g., a voucher
given to a patient), specify payment conditions, and execute payments.

The remainder of this paper is organised as follows: Section 2 discusses
related work. The overview of payment patterns is introduced in Section 3.
Section 4 presents each pattern in details. Section 5 gives concluding remarks.

2 Related Work

Previous works have collected and adopted design patterns to design blockchain-
based applications [2, 3]. Wohrer and Zdun [4] summarised six design patterns
to improve the security of smart contracts. OriginChain [5, 6] is a supply chain
application that adopts data management design patterns and smart contract
design patterns to improve the system adaptability. uBaaS is a service platform
that encapsulates patterns as services to generate code skeletons to facilitate
the development of blockchain-based applications [7]. Bartoletti and Pompianu
[8] performed an empirical study on smart contracts by collecting hundreds of
smart contracts and classifying them into different categories: token, authori-
sation, oracle, randomness, poll, time constraint, termination, math, and fork
check. Eberhardt and Tai [9] identified five data and computation design pat-
terns for blockchain-based applications, including challenge-response, off-chain

1https://eips.ethereum.org/EIPS/eip-1363
2https://eips.ethereum.org/EIPS/eip-20
3https://eips.ethereum.org/EIPS/eip-721

3



signatures, content-addressable storage, delegated computation, and low con-
tract footprint. Zhang et al. [10] integrated object-oriented patterns to design
a blockchain-based healthcare application to increase scalability. In [11], we
proposed a decision model that assists developers and architects in selecting a
set of patterns for blockchain-based applications.

There have been significant efforts in both industry and academia to ad-
dress payment challenges using the blockchain technology. In 2018, CSIRO’s
Data61 and Commonwealth Bank of Australia (CBA) developed a proof of con-
cept app to create and manage programmable “smart money” using blockchain
technology [12] through the case study of the National Disability Insurance
Scheme (NDIS). In 2019, TietoEVRY and Kela (The Social Insurance Institu-
tion of Finland) had cooperated to develop a proof of concept prototype for
smart money [13]. Goldfeder et al. [14] studied the escrow problem for physical
products and design a set of escrow schemes for Bitcoin.

Compared with the existing works, our study focuses on the patterns in
the context of blockchain-based payments, which have not been covered before.
Although some of the patterns in this paper are already discussed in previous
work [2, 15], we adapt them in the area of payments and aim to provide a
holistic and comprehensive guide on the design of blockchain-based payment
applications.

3 Overview of Blockchain-based Payment Pat-
terns

A variety of constraints need to be satisfied while building payment applications
on a blockchain. While each application is unique, we can always learn from the
commonly recurring problems and the corresponding reusable design solutions.
Those reusable design solutions can be established as a set of design patterns.

Those payment patterns are derived from our blockchain project experience
and literature review. Although blockchain-based payments have been studied
in academic literature, design details are mostly available in grey literature, such
as white papers and blogs. Thus, we adopted a Multivocal Literature Review
(MLR) [16] as our research methodology to study blockchain-based payments
and collect related design patterns. The MLR process started with identifying
our research question, which is “What are the effective patterns for designing
a blockchain-based payment application”. We used Google Search and Google
Scholar as the source databases. The search keywords include “blockchain”,
“payment”, “smart contract”, “token”, “asset”, and their combinations. We
also used snowballing to expand the pool of source literature. We then filtered
the sources according to the predefined selection criteria, e.g., “payment must
include ownership transfer of money”. Finally, we used open and axial coding
to analyse the selected sources and derive related patterns iteratively.

Table 1 gives an overview of the collected patterns. We classify the patterns
into three categories: token design patterns, seller management patterns, and

4



T
ab

le
1:

O
v
er

v
ie

w
o
f

b
lo

ck
ch

a
in

p
ay

m
en

t
p

a
tt

er
n

s.

C
a
te

g
o
r
y

N
a
m

e
S
u
m

m
a
r
y

T
o
k
e
n

D
e
si
g
n

P
a
tt
e
r
n
s

T
o
k
en

T
em

p
la

te
T

o
k
en

s
a
re

d
es

ig
n

ed
in

a
cu

st
o
m

is
ed

w
a
y

u
si

n
g

a
to
ke
n
te
m
p
la
te

th
a
t

ca
n

b
e

ex
te

n
d

ed
o
r

in
st

a
n
ti

a
te

d
.

T
o
k
en

R
eg

is
tr

y
A

to
k
en

re
g
is

tr
y

m
a
in

ta
in

s
th

e
o
w

n
er

sh
ip

in
fo

rm
a
ti

o
n

o
f

to
k
en

s
th

ro
u

g
h

a
m

a
p

p
in

g
o
f

to
k
en

ID
a
n

d
w

a
ll
et

a
d

d
re

ss
.

P
o
li
cy

C
o
n
tr

a
ct

A
po

li
cy

co
n
tr
a
ct

sp
ec

ifi
es

th
e

p
o
li
ci

es
th

a
t

a
to

k
en

m
u

st
sa

ti
sf

y,
e.

g
.,

w
h

et
h

er
a

to
k
en

m
u

st
b

e
sp

en
t

o
n

th
e

p
ro

d
u

ct
o
r

se
rv

ic
es

su
p

p
li
ed

b
y

el
ig

ib
le

se
ll
er

s
o
r

h
o
w

m
a
n
y

to
k
en

s
ca

n
b

e
sp

en
t

in
a

tr
a
n

sa
ct

io
n

.

B
u

rn
ed

T
o
k
en

W
h

en
re

d
ee

m
ed

,
a

sp
en

t
to

k
en

is
m

a
rk

ed
a
s

u
n
u

sa
b

le
/
u

n
sp

en
d

a
b

le
(a

k
a
.,
bu

rn
ed

).

S
e
ll
e
r

M
a
n
a
g
e
m

e
n
t

P
a
tt
e
r
n
s

S
el

le
r

R
eg

is
tr

y
A

se
ll
er

re
gi
st
ry

m
a
in

ta
in

s
th

e
in

fo
rm

a
ti

o
n

o
f

el
ig

ib
le

se
ll
er

s
fr

o
m

w
h

o
m

th
e

to
k
en

ca
n

b
e

sp
en

t
to

p
u

rc
h

a
se

p
ro

d
u

ct
s

o
r

se
rv

ic
es

.

O
w

n
er

sh
ip

C
h

a
ll
en

g
e

T
o

p
ro

v
e

th
e

o
w

n
er

sh
ip

o
f

a
n

it
em

,
a

b
u

y
er

se
n

d
s

a
n
o
w
n
er
sh
ip

ch
a
ll
en

ge
to

a
se

ll
er

.
T

h
e

se
ll
er

si
g
n

s
it

w
it

h
th

e
p

ri
v
a
te

k
ey

th
a
t

o
w

n
s

th
e

it
em

,
a
n

d
th

e
b

u
y
er

ca
n

v
er

if
y

th
e

si
g
n

a
tu

re
u

si
n

g
th

e
re

sp
ec

ti
v
e

p
u

b
li
c

k
ey

.

S
el

le
r

C
re

d
en

ti
a
l

T
h

e
b

u
y
er

ca
n

v
a
li
d

a
te

th
e

se
ll
er

’s
b

u
si

n
es

s
q
u

a
li
fi

ca
ti

o
n

th
ro

u
g
h

se
ll
er

cr
ed

en
ti

a
ls

.

P
a
y
m

e
n
t

M
a
n
a
g
e
-

m
e
n
t

P
a
tt
e
r
n
s

E
sc

ro
w

B
ef

o
re

m
a
k
in

g
a

tr
a
n

sa
ct

io
n

,
to

k
en

s
a
re

tr
a
n

sf
er

re
d

to
a

th
ir

d
-p

a
rt

y
sm

a
rt

co
n
tr

a
ct

ca
ll
ed

th
e

es
cr

o
w

.
T

h
e

es
cr

o
w

h
o
ld

s
th

e
d

ep
o
si

te
d

to
k
en

s
u

n
ti

l
th

e
p

a
y
m

en
t

co
n

d
it

io
n

s
a
re

sa
ti

sfi
ed

.

P
a
y
m

en
t

C
h

a
n

n
el

A
tw

o
-w

a
y

p
a
th

w
a
y

(a
k
a
.,
pa

y
m
en

t
ch

a
n
n
el

)
is

es
ta

b
li
sh

ed
b

et
w

ee
n

tr
a
n

sa
ct

in
g

p
a
rt

ie
s

to
p

er
fo

rm
tr

a
n

sa
c-

ti
o
n

s
o
ff

-c
h

a
in

w
h

il
e

re
co

rd
in

g
o
p

en
in

g
a
n

d
fi

n
a
l

se
tt

le
m

en
t

tr
a
n

sa
ct

io
n

s
o
n

th
e

b
lo

ck
ch

a
in

.

D
ig

it
a
l-

P
h
y
si

ca
l

P
a
ri

ty
A

n
a
u

th
en

ti
c

li
n

k
a
g
e

b
et

w
ee

n
a

p
h
y
si

ca
l

p
ro

d
u

ct
a
n

d
it

s
d

ig
it

a
l

re
p

re
se

n
ta

ti
o
n

(i
.e

.,
to

k
en

)
is

es
ta

b
li
sh

ed
o
n

th
e

b
lo

ck
ch

a
in

to
p

ro
te

ct
th

e
p

h
y
si

ca
l

p
ro

d
u

ct
’s

in
te

g
ri

ty
.

S
te

a
lt

h
A

d
d

re
ss

A
st
ea
lt
h
a
d
d
re
ss

p
ro

te
ct

s
th

e
p

ri
v
a
cy

o
f

th
e

p
a
rt

ie
s

in
v
o
lv

ed
in

th
e

p
a
y
m

en
t

b
y

cr
ea

ti
n

g
a

o
n

e-
ti

m
e

a
d

d
re

ss
fo

r
th

e
tr

a
n

sa
ct

io
n

.

O
ra

cl
e

T
o

ex
a
m

in
e

th
e

fu
lfi

lm
en

t
o
f

p
a
y
m

en
t

co
n

d
it

io
n

s,
a
n
o
ra
cl
e

is
u

se
d

to
in

tr
o
d

u
ce

th
e

st
a
te

o
f

ex
te

rn
a
l

sy
st

em
s

in
to

th
e

cl
o
se

d
b

lo
ck

ch
a
in

ex
ec

u
ti

o
n

en
v
ir

o
n

m
en

t.

M
u

lt
is

ig
n

a
tu

re
G

iv
en

a
p

o
o
l

o
f
n

a
d

d
re

ss
es

th
a
t

co
u

ld
a
u

th
o
ri

se
a

p
a
y
m

en
t,

g
et

a
su

b
se

t
m

o
f

th
em

to
a
u

th
o
ri

se
a

p
a
y
m

en
t

b
y

si
g
n

in
g

th
e

re
sp

ec
ti

v
e

tr
a
n

sa
ct

io
n

(m
≤

n
).

T
o
k
en

S
w

a
p

T
o
k
en

sw
a
p

a
ll

o
w

s
u

se
rs

to
tr

a
d

e
d

ir
ec

tl
y

b
et

w
ee

n
tw

o
ty

p
es

o
f

to
k
en

s
a
s

a
n

a
to

m
ic

tr
a
n

sa
ct

io
n

.

A
u

th
o
ri

se
d

S
p

en
d

er
A

n
a
u

th
o
ri

se
d

th
ir

d
-p

a
rt

y
sp

en
d

er
is

a
ll
o
w

ed
to

sp
en

d
a

ce
rt

a
in

a
m

o
u

n
t

o
f

to
k
en

s
o
n

b
eh

a
lf

o
f

th
e

a
p

p
ro

v
er

.

5



St
at
e

St
at
e

tr
an
si
ti
on

P
at
te
rn

To
ke

n 
te

m
p

la
te

O
ra

cl
e

M
ul

ti
si

g
na

tu
re

Es
cr

ow

C
re
at
ed

R
el
ea
se
d

A
llo
ca
te
d

V
al
id
at
ed

Tr
an
sf
er
re
d

D
es
tr
o
ye
d

D
ep
o
si
te
d

Li
fe

cy
cl

e
 o

f 
a 

to
ke

n

Sa
ti
sf
ie
d

To
ke

n 
re

g
is

tr
y

St
ea

lt
h

 a
dd

re
ss

Le
ge

n
d

Se
lle

r 
re

gi
st

ry

Is
su
ed

Po
lic

y 
co

nt
ra

ct

B
ur

n
ed

 to
ke

n

O
p
en

ed
R
ec
o
rd
ed

Es
cr
ow

ed

C
ha
nn

el
ed

Pa
ym

en
t 

ch
an

n
el

Se
lle

r 
cr

ed
en

ti
a

l

O
w

ne
rs

h
ip

 
ch

a
lle

ng
e

D
ig

it
a

l-
Ph

ys
ic

a
l 

Pa
ri

ty

Pa
tt
er
n

en
ab
le
r

To
ke

n 
sw

a
p

A
ut

ho
ri

se
d

 s
p

en
d

er

Se
tt
le
d

St
ea

lt
h

 a
dd

re
ss

O
ra

cl
e

M
u

lt
is

ig
na

tu
re

Figure 2: Lifecycle of a token with the annotated design patterns.

6



payment management patterns. Fig. 2 illustrates the lifecycle of a token and
highlights the patterns associated with state transitions within the lifecycle.

The lifecycle starts with the issuance of a token. The token can be designed
in a customised way using a token template pattern which specifies necessary
details (e.g., token name, symbol, number of decimal places, and the total num-
ber of tokens supplied) and advanced features (e.g., the minting process, initial
distribution, and token burning process). A policy contract pattern stipulates
the rules for using a group of tokens, such as how many vouchers can be spent
in a transaction and whether the token must be spent on the specified prod-
ucts or services supplied by eligible sellers. A seller registry pattern is used to
maintains the information of eligible sellers from whom the token can be spent
to purchase products or services.

Once issued, the predefined number of tokens are allocated to the buyer’s
wallet addresses who are on the initial distribution list. The token registry
pattern could be used to maintain the token ownership information as a mapping
between a wallet address and the number of tokens or token identifiers associate
with it. The buyer’s wallet receives the allocated tokens and sends a notification
to the consumer that the tokens are received.

Before purchasing a product or service, a consumer’s wallet could use the
seller credential pattern to validate the seller’s business qualifications. In cyber-
physical systems, an authentic linkage between physical items and their digital
representations can be established on the blockchain through digital-physical
parity pattern. To prove the ownership of a product/item, a buyer could adopt
the ownership challenge pattern, which sends a cryptographic challenge to the
seller and the seller signs it with the private key that owns the item. The buyer
can verify the signature using the corresponding public key.

Further, the oracle pattern can be used to introduce the external state/data
into the blockchain execution environment, which is self-contained. For example,
a payment may be subject to an external state confirmed by a human (e.g.,
a truck driver confirming the collection of an item) or an IoT device (e.g.,
automatically report quality attribute of the item or its ambient conditions)
through the oracle.

Once the required transaction information is validated, the token(s) can
be transferred to the seller. The escrow pattern can be used for conditional
payments, which is suitable for high-value, infrequent payments that require
strong security guarantees. The escrow holds the deposited tokens until the
payment conditions are satisfied. Multisignature pattern can be applied to sign
transactions requiring the approval of multiple parties, e.g., to control the release
of tokens held by an escrow. Please note that Stealth address, Oracle, and
Multisignature can be enforced to a transaction with or without an escrow.

To deal with frequent, low latency, and low-value payments, a payment chan-
nel is designed to perform transactions off-chain with opening and final settle-
ment transactions recorded on-chain. The authorised spender pattern is used
to allow a third-party (e.g., a smart contract) to spend a certain amount of
tokens on behalf of the approver. Token swap pattern enables users to trade
directly between two types of tokens as an atomic swap. The stealth address

7



pattern enables a given payment to be made to a one-time account, such that
the anonymity set is only provided to the parties involved in the transaction.
Once the transaction is settled, the seller is notified that the payment has been
executed successfully.

Depending on the use case, tokens could be transferred multiple times. To-
kens might need to be redeemed in some use cases. Thus, the spent/redeemed
tokens might become burned tokens, which means the tokens are no longer us-
able.

4 Blockchain-Based Payment Patterns

In this section, we present patterns that shape the architectural elements and
their interactions in blockchain-based payment applications. Each pattern is
described following the extended pattern form in [17], which includes the pattern
name, summary, problem statement, forces that make the problem difficult to
solve, solution, consequences of applying the solution, and real-world known
uses.

4.1 Token Template

Summary: Tokens can be designed in a customised way using a token template
that can be extended or instantiated.

Context: Blockchain provides a trustworthy platform to realise tokenisation.
In a blockchain application, a token represents a programmable digital unit of
value (i.e., assets) recorded on the blockchain for a specific purpose, like buying
a particular good or service. The same application may use different tokens, a
food stamp issued for a child is usually different from an adult.

Problem: A token is usually defined as a data structure embedded in a smart
contract to represent an asset. How can developers design and develop differ-
ent types of tokens with a various features and operations defined for different
purposes?

Forces:

• Modularity. A blockchain application might support different types of tokens
with different rules.

• Interoperability and liquidity. Tokens supported by different applications
might need to be exchanged frequently.

• Vulnerabilities. Handling tokens with a high value is risky, as lost tokens
cannot be replaced/recovered on the blockchain. Further, vulnerabilities or
bugs might be introduced when developing a blockchain-based application.
Blockchain is by design an immutable data store. Hence, updating an already
deployed smart contracts could be impossible. This makes it difficult to fix
bugs by releasing new versions of a smart contract.

8



Template_X Token_X

Template_Y Token_Y

Template_Z Token_Z

On-ChainOff-Chain

$

$

$

Template_X
Source Code

Template_Y
Source Code

Template_Z
Source Code

InstantiateDeploy

Deploy

Deploy

Instantiate

Instantiate

Figure 3: Token template.

• Productivity. Blockchain is an emerging technology with limited tooling and
documentation. Thus, developers can have a steep learning curve, which
affects the development productivity of blockchain applications.

• Cost. The use of templates increases the (gas) cost.

Solution: Blockchain-based payment applications might need to issue different
types of tokens with customisation. Therefore, as shown in Fig. 3, a base token
can be defined as a smart contract template that can be either extended or
instantiated by another smart contract to issue a new token at run time. In the
token template, the user can define attributes and functions. The attributes
usually consist of essential information (e.g., token name, symbol, number of
decimal places, and type) and advanced features (e.g., minting process, initial
distribution, and burning process). The specified functions enforce rules that
govern how the tokens are minted and transferred. The template can be stored
on-chain as a factory smart contract or off-chain in a code repository. Op-
tional properties and functions in the template allow customisation. If that is
insufficient, the template smart contract can be extended by another contract
to support customised features. Once developed, the template would change
rarely. Thus, it can be thoroughly tested and certified to be free of defects.

There can be two types of tokens: cash tokens and voucher tokens. Cash
tokens are fungible tokens that are fully exchangeable with each other and can
be divided into smaller denominations for multiple transactions. In contrast,
voucher tokens are non-fungible tokens that are unique and must be spent in

9



a single transaction regardless of the price of a product or service. Both cash
tokens and voucher tokens can be considered as token templates. For example,
in the cash token template, users can define the total supply of tokens.

Consequences:

Benefits:

• Productivity and security. A token template can support developing a par-
ticular type of token by merely creating an instance of the token template.
A well-defined and tested template simplifies blockchain application develop-
ment and reduces time, and enhances security and reliability.

• Modularity. A blockchain application might support different types of to-
kens with different rules. Use of token templates in the design can improve
modularity.

• Interoperability and liquidity. As the token template can comply with a token
standard, it offers high interoperability and liquidity, such as token transfer
and token swap due to the wide-spread use of the standards.

• Simplicity. Voucher tokens are easier to manage compared to cash tokens as
they typically have a single purpose.

• Fungibility. Cash tokens are more fungible than voucher tokens.

Drawbacks:

• Cost. If a public blockchain is used, an extra cost is required to deploy
the token template contract on the blockchain and call its token instance
creation function. Further, the generalisation of the template increases the
cost of computational and storage complexity of smart contract, increasing
the transaction fees needed to manipulate it.

• Productivity. It takes time to design, develop, and test a token template
carefully. However, this is a one time process.

Related patterns: Policy contract, seller registry, token registry, and burned
token.

Known uses:

• ERC-20 and ERC-721 have emerged as the de-facto standards for imple-
menting fungible and non-fungible tokens in Ethereum and sister blockchains,
respectively, by instantiating reference implementations such as OpenZeppe-
line4.

• Lorikeet [18] is a model-driven engineering tool that provides templates for
the developers to customise fungible/non-fungible asset data schema and the
resulting contracts based on ERC-20 and ERC-721 interface definitions.

4https://docs.openzeppelin.com/contracts

10



Token Registry

On-ChainOff-Chain

Buyer 

Seller

Request 
transfer

Product

Conf irm 
transfer

Figure 4: Token Registry.

• Token Mint5 is a tool to create tokens and crowdsale contracts without coding.

• Token Launcher6 creates mintable ERC-20 tokens by setting the desired spec-
ification.

4.2 Token Registry

Summary: A token registry maintains the ownership information of tokens by
mapping the token identifier and wallet address.

Context: A buyer (i.e., token owner) needs to pay a certain number of tokens
to purchase a product or service. The payment application needs to manage a
large number of transacting parties, tokens, and transactions.

Problem: When a payment is made, the respective number of tokens’ own-
ership needs to be swapped from the buyer to the seller. Further, tracking
historical ownership of tokens is often required to ensure traceability. Thus,
it becomes challenging to track a large number of tokens, their owners, and
transactions. How can a large number of transactions be effectively tracked?

Forces:

• Dynamism. The ownership of tokens could change frequently.

• Scalability. A large number of token and their owners need to be mapped.

5https://tokenmint.io/
6https://thetokenlauncher.com/

11



Solution: As shown in Fig. 4, a token registry contract can be used to record
the ownership information of tokens by mapping token identifier (ID) to the
wallet address. Both token ID and wallet address are stored as variables in the
token registry smart contract. This registry provides the ground-through on
token ownership, as it could be manipulated only through the smart contract
by authorised parties.

Writing permission can be added through a permission control module, e.g.,
only proceed ownership transfer if the token is in the given state or when the
new owner approves. Those conditions can be checked through a method in
the smart contract receiving tokens. If the conditions are not met, the smart
contract can throw an error rather than receiving the token.

Benefits:

• Upgradability. Because the token ownership data are managed separately by
the token registry, rest of the smart contract code can be upgraded without
changing the token registry contract.

• Cost. By separating token ownership data from rest of the application code,
there is no additional cost for data migration when the application logic is
upgraded.

• Traceability. Traceability is enhanced, e.g., how much tokens are owned by
whom at what time is reflected in the registry.

Drawbacks:

• Cost. Recording ownership data in smart contract incur an additional cost if
a public blockchain is adopted.

Related patterns: Token template, burned token, and seller registry.

Known uses:

• Lorikeet [18] is a model-driven engineering tool that generates asset registry
smart contracts compliant with ERC-20 and ERC-721 standards.

• Parity Token Registry 7 enables all the registered token to be automatically
visible to all Parity wallet users.

• Codefi8 provides an ownership registry for Universal token investors.

4.3 Policy Contract

Summary: A policy contract specifies the policies that a token must satisfy,
e.g., whether a token must be spent on the product or services supplied by
eligible sellers or how many tokens can be spent in a transaction.

7https://github.com/openethereum/token-registry
8https://github.com/ConsenSys/UniversalToken

12



Policy

On-ChainOff-Chain

Buyer

Seller

Token

Bind

Transfer

Receive

Product

$

Issuer

Figure 5: Policy Contract.

Context: A payment should be settled only when specific business rules or
policies are satisfied. For example, government support programs or charitable
donations usually indicate limits and constraints regarding products/services
could be purchased, their quantities, and eligible sellers.

Problem: Some policies stipulate how to use a particular group of tokens
on blockchain-based payment applications. Preconfigured policies need to be
checked by the payment applications before allowing payment to occur.

Forces:

• Diversity. A variety of policies often governs the use of a token. They are
challenging to find and interpret in relation to one another.

• Dynamism. The policies or business rules might be dynamically attached/re-
moved to/from tokens.

Solution: As depicted in Fig. 5, a policy smart contract can be designed to
specify policies that a token must satisfy before use. For example, a policy could
indicate the attached token is spendable only on medicine, and the correspond-
ing policy check logic could check whether a given pharmacy is a registered in
the approved seller registry for that medicine. The policy check logic is im-
plemented as smart contract functions, which are invoked before the payment
function. When all the policies are satisfied, the buyer is allowed to make the

13



payment. The mapping of policy contracts can happen at the level of either a
single or group of tokens.

In some instances, policies are expected to remain the same until the token
is redeemed (or at least within a given time window). In other cases, the policies
governing the tokens may change with time (e.g., changes in service agreements).
Thus, the issuers may want to enforce the latest policy at the time of spending.
In general, a policy contract needs to be designed with a generic interface such
that it can be dynamically attached/detached to/from the token. Benefits:

• Dynamism. Policy contracts can be flexibly attached, updated, or removed
from a token.

• Diversity. Policy contracts enhance diversity. Issuers can specify a variety of
policies in policy contracts for the usage of different tokens.

• User Productivity. Multiple policies and tokens could be automatically checked
without needing buyer and seller to interpret them manually.

Drawbacks:

• Cost. If a public blockchain is used, an extra cost is required to deploy a
policy contract on blockchain and call its functions at the time of redeeming.

• Developer Productivity. Policies are challenging to codify; hence, it takes time
to design, develop, and test a policy contract carefully. However, this is a one
time process.

Related patterns: Token template, seller registry, token registry, and burned
token.

Known uses:

• Making Money Smart9[12] is a joint pilot project by the Commonwealth Bank
of Australia (CBA) and CSIRO’s Data61 that attaches policy contracts to
each pouch of tokens issued to redeem National Disability Insurance Scheme
(NDIS) benefits in Australia. The policy defines what healthcare services
could be used, their quantities, and eligible sellers.

• Smart Money10[13] is a blockchain-based payment platform jointly developed
by Kela (The Social Insurance Institution of Finland) and TietoEVRY in co-
operation with Finnish Tax Administration, Financial Supervisory Authority
of Finland, and Borenius Attorneys. Spending rules are defined as constraints
for smart money tokens, and are verified at the time of a transaction.

• CAIPY [19] is a blockchain-based car insurance policy framework. In the
design of CAIPY, policy contracts model process fragments define";"""date"",""2021-02-22T01:37:04Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.5""
""xmp:CreatorTool"",""TeX""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dcterms:created"",""2021-02-22T01:37:04Z""
""language"",""en""
""Last-Modified"",""2021-02-22T01:37:04Z""
""dcterms:modified"",""2021-02-22T01:37:04Z""
""dc:format"",""application/pdf; version=1.5""
""Last-Save-Date"",""2021-02-22T01:37:04Z""
""pdf:docinfo:creator_tool"",""TeX""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2021-02-22T01:37:04Z""
""meta:save-date"",""2021-02-22T01:37:04Z""
""pdf:encrypted"",""false""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.21 (TeX Live 2020) kpathsea version 6.3.2""
""modified"",""2021-02-22T01:37:04Z""
""Content-Length"",""8165710""
""pdf:hasMarkedContent"",""false""
""Content-Type"",""application/pdf""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.21 (TeX Live 2020) kpathsea version 6.3.2""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""trapped"",""False""
""meta:creation-date"",""2021-02-22T01:37:04Z""
""created"",""2021-02-22T01:37:04Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""40""
""Creation-Date"",""2021-02-22T01:37:04Z""
""resourceName"",""2102.09810""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""1827"",""1754"",""2690"",""2568"",""2127"",""487"",""2901"",""1973"",""1608"",""1859"",""1039"",""1798"",""1199"",""2083"",""1290"",""1365"",""1656"",""1832"",""1215"",""1769"",""1096"",""1465"",""1447"",""1682"",""1173"",""1801"",""1478"",""1696"",""1352"",""1968"",""1530"",""1536"",""1145"",""1458"",""1410"",""1334"",""946"",""1843"",""2135"",""654""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""producer"",""pdfTeX-1.40.21""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""pdfTeX-1.40.21""
""pdf:docinfo:created"",""2021-02-22T01:37:04Z""
";https://scholar.google.ch/scholar?start=30&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2021
1619099111-418;https://scholar.google.ch/scholar?as_ylo=2021&q=oracles+blockchain&hl=fr&as_sdt=0,5;Towards Blockchain-Based Federated Machine Learning: Smart Contract for Model Inference;V Drungilas, E Vai?iukynas, M Jurgelaitis, R Butkien?… ; Applied Sciences, 2021  mdpi.com;;"… Oracles introduce flexibility in blockchain-based ML implementations by enabling the usage of

virtually any programming … The experimental results can be used to determine whether the oracle

service is a viable solution to extend the possibilities of blockchain-based ML …";Les 3 versions;En cache;[PDF] mdpi.com;https://www.mdpi.com/2076-3417/11/3/1010/pdf;;;https://scholar.google.ch/scholar?start=10&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2021
1619099138-485;https://scholar.google.ch/scholar?as_ylo=2021&q=oracles+blockchain&hl=fr&as_sdt=0,5;A blockchain based secure communication framework for community interaction;R Sharma, M Wazid, P Gope ; Journal of Information Security and …, 2021  Elsevier;;"… Blockchain systems are widely used as crypto-currencies today, due to its effective

transactions recording functionality … Zheng et al. [23] presented various benefits of

blockchain in other technical environments other than the crypto-currencies …";Les 2 versions;;null;;;;https://scholar.google.ch/scholar?start=70&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2021
1619099133-470;https://scholar.google.ch/scholar?as_ylo=2021&q=oracles+blockchain&hl=fr&as_sdt=0,5;FSM Modeling of Off-Blockchain Computation;CG Liu ;2021 dalspace.library.dal.ca;;"Page 1. FSM MODELING FOR OFF-BLOCKCHAIN COMPUTATION by Christian

Gang Liu … Table 6.1 GAS Consumption on Stack, Memory, and Storage . .... 63 Table

6.2 Examples of Different Operations on Blockchain ..... 64 …";;;[PDF] dal.ca;https://dalspace.library.dal.ca/bitstream/handle/10222/80335/Christiangangliu2021.pdf?sequence=3&isAllowed=y;"
 

 

 

 

FSM MODELING FOR OFF-BLOCKCHAIN COMPUTATION 

 

 

by 

 

Christian Gang Liu 

 

 

Submitted in partial fulfilment of the requirements                                                               

for the degree of Master of Computer Science 

 

 

Dalhousie University                                                                                                    

Halifax, Nova Scotia                                                                                                          

Feb 2021 

 

 

 

 

 

Š Copyright by Christian Gang Liu, 2021 
 



ii 

 

TABLE OF CONTENTS 

 

TABLE OF CONTENTS .................................................................................................... ii 

LIST OF TABLES ............................................................................................................. iv 

LIST OF FIGURES ............................................................................................................ v 

ABSTRACT ....................................................................................................................... vi 

LIST OF ABBREVIATIONS USED ............................................................................... vii 

ACKNOWLEDGEMENTS ............................................................................................. viii 

CHAPTER 1  INTRODUCTION ................................................................................... 1 

1.1 Related Work ............................................................................................ 1 

1.2 Objectives ................................................................................................. 3 

1.3 Contributions ............................................................................................ 4 

1.4 Outline ...................................................................................................... 6 

CHAPTER 2  BACKGROUND ..................................................................................... 8 

2.1 FSM Modeling of Blockchain Applications ............................................. 8 

2.2 Off-Chaining Models and Approaches ..................................................... 9 

2.3 Hierarchical FSM ................................................................................... 10 

2.4 Smart Contract Design Patterns .............................................................. 10 

CHAPTER 3  FINDING PATTERN PROPERTIES ................................................... 13 

3.1 FSM Modeling of Smart Contracts ........................................................ 13 

3.2 Specific Patterns Considered for Processing Off-chain ......................... 15 

3.2.1 Sequence of Events ................................................................. 15 

3.2.1 Two-parties Agreement Pattern .............................................. 18 

3.2.2 Permission by Any One of N .................................................. 22 

3.2.3 Agreement of M out of N (M/N) ............................................ 25 

3.3 Properties of Subgraphs for Off-chaining .............................................. 25 

CHAPTER 4  ALGORITHM TO FIND PATTERNS ................................................. 27 

4.1 Algorithm to Find Simple-Subgraphs Patterns ....................................... 28 

4.2 Helper Functions .................................................................................... 29 

4.2.1 Algorithm to find simple subgraphs ....................................... 30 

4.3 Examples of Algorithms Utilization ....................................................... 34 

4.3.1 Example of Seller and Buyer Escrow Deposit ....................... 34 



iii 

 

4.3.2 Example: South African Real Estate Transaction .................. 35 

4.3.3 Smart Blockchain Badges for Data Science Education .......... 38 

4.4 Comments ............................................................................................... 40 

CHAPTER 5  INTERFACE BETWEEN ON AND OFF-CHAIN PROCESSING ..... 41 

5.1 Requirements for Interface Between On and Off-Chain Processing ...... 41 

5.2 On Chain to Off-Chain Transition .......................................................... 43 

5.3 Off-Chain to On-Chain Transition ......................................................... 46 

5.4 Interface Considerations for Hyperledger and Ethereum ....................... 47 

5.4.1 Interface for Ethereum ............................................................ 47 

5.4.2 Interface for Hyperledger ....................................................... 48 

5.5 Off-Chain Storage .................................................................................. 50 

5.6 Summary ................................................................................................. 52 

CHAPTER 6  DECIDING TO PROCESS A PATTERN OFF-CHAIN ...................... 53 

6.1 Decision-Making Data Requirements .................................................... 54 

6.2 Cost Estimation Model for On-chain  to Off-chain Interface ................. 58 

6.2.1 Analytical Estimation Approach of Cost Evaluation Model .. 58 

6.2.2 Cost estimation model ............................................................ 59 

6.2.3 Example of cost estimation on Ethereum network ................. 62 

6.2.4 Cost Estimation for the Escrow Deposit Simple-subgraph 

Pattern ..................................................................................... 64 

6.3 Discussion ............................................................................................... 67 

CHAPTER 7  CONCLUSIONS ................................................................................... 69 

7.1 Limitations .............................................................................................. 69 

7.2 Future works ........................................................................................... 69 

7.3 Conclusions ............................................................................................ 70 

BIBLIOGRAPHY ............................................................................................................. 72 
 



iv 

 

LIST OF TABLES 

 
Table 6.1    GAS Consumption on Stack, Memory, and Storage . ................................................ 63 

Table 6.2    Examples of Different Operations on Blockchain  ..................................................... 64 

Table 6.3    Interfaces Overhead Breakdowns ............................................................................... 66 

 

 

  



v 

 

 

LIST OF FIGURES 

 

Fig.  2.1      FSM of Blinded Auction ............................................................................................... 9 

Fig.  3.1      FSM representing a sequence of events pattern. ......................................................... 16 

Fig.  3.2      Algorithm 1 to identify the sequence of events pattern for given subgraph S' ............ 17 

Fig.  3.3      Pattern that is a minor variation of the pattern in Fig. 3.1 (a) ..................................... 18 

Fig.  3.4      FSM graph representing a two-party agreement ......................................................... 18 

Fig.  3.5      Reusable Function to Determine the Start and End Nodes ......................................... 19 

Fig.  3.6      Algorithm 2 to identify the Two-Parties pattern for given subgraph F' ...................... 21 

Fig.  3.7      Patterns for mortgage approval ................................................................................... 22 

Fig.  3.8      FSM graph representing an Any One of N Pattern ..................................................... 23 

Fig.  3.9      Algorithm 3 to identify an M out of N Pattern ............................................................ 24 

Fig.  3.10    FSM graph representing an M out of N Pattern ........................................................... 25 

Fig.  4.1      Helper function genrateAllSubgraphs to find all possible natural subsets of S .......... 29 

Fig.  4.2      Helper function isSimpleSubgraph to identify Simple Subgraph................................ 30 

Fig.  4.3      Helper function isProperSubgraph to identify subgraph S1 ....................................... 30 

Fig.  4.4     Algorithm 4 to find all simple subgraphs for a give FSM F ........................................ 31 

Fig.  4.5     FSM graph for buyer-seller interaction with escrow account in use ........................... 34 

Fig.  4.6     FSM graph for Real Estate Transaction on Blockchain .............................................. 36 

Fig.  4.7     H-FSM Graphs as Blockchain Badges for Data Science Education............................ 38 

Fig.  5.1     Interface Between On-chain and Off-chain Processing ............................................... 44 

Fig.  5.2     Ethereum Network on/off-chain data exchange .......................................................... 48 

Fig.  5.3     Hyperledger Network on/off-chain data exchange ...................................................... 49 

Fig.  5.4     Data Structure for Off-chaining Computation ............................................................. 51 

Fig.  6.1     Escrow deposit simple subgraph before and after off-chain decision ......................... 57 

Fig.  6.2     Two-party approval ..................................................................................................... 57 

Fig.  6.3     Cost Estimation Workflow Diagram ........................................................................... 60 

Fig.  6.4     The simple candidate subgraph for testing cost model ................................................ 64 

 

 

 



vi 

 

ABSTRACT 

Blockchain benefits are due to immutability, replication, and storage-and-execution of 

smart contracts on the blockchain.  However, the benefits come at increased costs due to 

the blockchain size and execution.  We address three fundamental issues that arise in 

transferring certain parts of a smart contract to be executed off-chain: (i) identifying 

which parts (patterns) of the smart contract should be considered for processing off-

chain, (ii) under which conditions should a smart-contract pattern to be processed off-

chain, and (iii) how to facilitate interaction between the computation off and on-chain.  

We use separation of concerns and FSM modeling to model a smart contract and generate 

its code. We then (i) use our algorithm to determine which parts (patterns) of the smart 

contract are to be processed off-chain; (ii) consider conditions under which to move the 

pattern off-chain; and (iii) provide model for automatically generating the interface 

between on and off-chain computation.  

 

 



vii 

 

LIST OF ABBREVIATIONS USED 

FSM Finite State Machine 

HSM Hierarchical State Machine   

EVM Ethereum Virtual Machine  

IPFS Interplanetary File System  

 

 

 
  



viii 

 

 

ACKNOWLEDGEMENTS 

First and foremost, I am grateful to my supervisors, Prof. Peter Bodorik for his invaluable 

advice, continuous support, and patience during my MCS study. His immense knowledge 

and plentiful experience have encouraged me in all the time of my academic research and 

daily life. I would also like to thank Dr. Michael McAllister for approving the research 

scholarship upon recognizing my achievements during the MCS study and research. I 

also want to thank Dr. Dawn Jutla, Dr. Qiang Ye and Dr. Vlado Keselj for their time to 

be the committees of my thesis defense. And they provided valuable feedbacks to my 

research. It is their kind help and support that have made my study and life in the 

Dalhousie a wonderful time.  

 



1 

 

CHAPTER 1  INTRODUCTION 

Blockchain may be considered an immutable and replicated database managed 

autonomously using a peer-to-peer network and a decentralized replicated virtual 

machine using distributed timestamping servers (Wikipedia 2020). Supplementarily, a 

smart contract works like a stored procedure with immutable instructions that are also 

stored on the blockchain and thus tamper-proof. In general, as the name indicates, a smart 

contract is typically used to reach and enforce an agreement between engaged parties, 

wherein that agreement can be modeled and governed by a well-known state machine 

design pattern of a smart contract (WĂśhrer & Zdun, 2018). Many industries have rapidly 

adopted smart contracts since Ethereum was created in 2015 because smart contract over 

blockchains is secure, distributed, and manageable.  However, blockchain is still 

struggling with known issues, such as storage size and scalability, not to mention the 

nowadays growing Big Data requirements for e-commerce type transactions on 

blockchains.   

1.1 RELATED WORK 

Blockchain research and software development communities have been developing 

methods, models, and design patterns to mitigate the aforementioned limitations. For 

instance, Eberhardt & Tai (2017, 2018) introduced models for off-chain computation and 

storage.  Off-chain storage is the most prevalent technique as it is easy.  Instead of storing 

large objects or documents on the blockchain itself, they are stored off-chain while their 

digital signatures are stored on the blockchain itself.  Any time an object stored off-chain 

is accessed, its signature is recalculated and checked with the object's signature stored on 

the blockchain.  Blockchain sharding is another approach to split blockchain data into 

shards and distribute them among different geographic locations to enhance scalability 

and reliability (Dang, et al. 2019).    

Off-chain computation refers to performing some of the smart contract computation off-

chain and using various techniques to verify that the computation results are trustworthy 

to the level as if they were performed on-chain.  Hybrid off-chaining refers to moving 



2 

 

both the storage and computation off-chain (Eberhardt & Tai, (2017, 2018)); however, as 

it is not clear how one can perform off-chain computation without data (which is on-

chain), from now on, unless stated otherwise, we shall use the terms ""processing off-

chain"" or ""off-chain computation"" to refer to the hybrid off-chaining in which both 

computation and storage are performed off-chain. Approaches taken to off-chain 

computation thus far, however, neither address the issue of how to determine which 

computations should be moved to off-chain, nor how to automate the process 

systemically – topics of this thesis.  

Plasma project makes off-chaining methods the basic building block for smart contract 

development (Poon & Buterin, 2017).  It allows developers to use mainstream 

programming languages for off-chain computation, of which results are verified by the 

participants and agreed to by using smart contracts executing on a blockchain.  In effect, 

the blockchain thus serves as a certifier that the distributed off-chain computation 

participants have verified the computation results and attest to such verification by 

signing the results.  

FSM modeling has been used for modeling Blockchain applications, which is not 

surprising as blockchains have been referred to as state machines. For instance, 

Asgaonkar (2018) utilized FSM modeling to introduce a dual-deposit escrow mechanism 

between Buyer and Seller; AlTawy, et al. (2019) introduced a Blockchain-based delivery 

system called Lelantos and demonstrated it with FSM modelling; Nguyen, et al. (2018) 

illustrated his digitizing Invoice system on Blockchain with FSM modeling; Bai & 

Synnes (2018) proposed an FSM-based reward system for the care of elderlies. 

Patterns have also been exploited widely in research and development of smart contracts. 

For instance, Eberhardt & Tai (2017, 2018) illustrated the Challenge-response pattern and 

Chess end-game pattern for the off-chain computation, and Mavridou & Laszka (2017) 

developed a smart contract design pattern for security issues, such as transition counts, 

locking, and cross-cutting. They used patterns in their search for creating secure smart 

contracts which were modeled using FSMs that were then transformed into smart 

contracts.  



3 

 

1.2 OBJECTIVES 

As the cost of blockchain infrastructure is high, it was quickly determined that one of the 

“low hanging fruits” in solving this problem is reduction of data stored on the blockchain 

by storing it off-chain and store on the blockchain its hash-code used to ensure data 

immutability – a simple, effective, and efficient method.  However, moving smart 

contract processing off-chain is not that simple and research on this topic is in its nascent 

stage.  Our research objectives target the three main issues that need to be resolved by a 

successful solution and that will be discussed shortly.  But before we proceed, we provide 

a few statements on our terminology.   

A smart contract is a collection of methods, which are supported by various data 

structures, that are invoked by off-blockchain systems.  To determine which part(s) of a 

smart contract should be processed off-chain, it must be determined which collection of 

methods and supporting data are to be processed off-chain.  It is clear that selecting a 

random collection of methods to be processed off-chain is likely to be less suitable for 

processing off-chain than a collection of methods that collaborate to achieve a common 

goal and we shall refer to such a collection of methods as a pattern.  Hence, when we 

refer to a pattern to be processed off-chain, we are referring to the collection of methods 

and supporting data to be processed off-chain.   

The three issues that we address are: 

1. The first issue deals with determining which pattern should be processed off-

chain – our first objective.  Is one pattern more suitable to be processed off-chain 

than another, and if so, how do we find a pattern to be processed off-chain?   

2. For a pattern to be processed off-chain, it needs to have two properties.   

a. One property deals with the issue of overhead costs.  When a pattern is 

processed off-chain, a trade-off is introduced.  A pattern is moved off-

chain to reduce the cost of processing it as, it is assumed, that the cost of 

processing a pattern off-chain is much lower than to process it on-chain.  

However, there is also overhead cost introduced due to 



4 

 

communication/interaction between on and off-chain processing – hence a 

trade-off.  

b. Processing a pattern off-chain should not diminish the beneficial 

blockchain properties, such as resilience to failures or security attacks and 

immutability of blockchain data.   

3. The final issue is how to facilitate interface automatically for interaction between 

on and off-chain processing.  

Loosely speaking, the three issues may be referred to briefly as “What”, “When”, and 

“How”, respectively: (a) What is to be processed off-chain, i.e., which pattern should be 

considered for processing off-chain; (b) When processing off-chain should be facilitated, 

i.e., which conditions need to be satisfied by a pattern to be moved off-chain; (c) and the 

third one is how to facilitate automatically the interaction between on and off-chain 

processing.   

In addition to tackling the three objectives above, an additional objective was added and 

to exploit results of (Mavridou & Laszka, 2017), which uses FSMs to model 

requirements of a smart contract and then translating the FSM model automatically into 

the smart contract code.  Our final objective is to determine if these research results can 

be used in achieving separation of concerns, when designing a smart-contract pattern that  

should utilize off-chain processing to reduce its cost:  The first concern is satisfying user 

requirements and then the second concern is processing off-chain.   

1.3 CONTRIBUTIONS 

Before we list contributions, we need to highlight that we build upon previous research 

results of Marvidou & Lazska (2017(a)(b)), in which application requirements for a smart 

contract are represented by FSM and then translated into a smart-contract method 

automatically, for two reasons:  

(i) One is that graph representation of an FSM enables us to view the 

connectivity of methods that could be used to analysis in identifying which 

patterns should be considered for processing off-chain.   



5 

 

(ii) The second is that we exploit their results in dividing our problem into two 

sub-problems  ((i) satisfying user requirements and (ii) processing off-chain)  

that are based on separation of concerns, and thus reducing the complexity in 

that the complexity of each sub-problem is simpler than when solving both 

problems at the same time.   

Our contributions are described for each of the objectives. 

1. We developed an algorithm to examine the graph representation of an FSM that 

models the user requirements in order to find patterns to be considered for 

processing off-chain: The algorithm looks for patterns that have well-defined 

goals and minimal connectivity with other patterns, where the connectivity 

represents interaction across patterns.  We applied the algorithm on a selection of 

real smart-contract use-cases and report on results of its application.  

2. We investigated variables that affect the second objective that deals with 

analyzing a given pattern to determine whether it should be processed off-chain.  

We broke the problem into two sub-problems: 

a. A pattern should be processed off-chain only if the trade-off, between the 

cost benefits/savings outweigh the overhead cost of interaction between 

the on and off-chain processing.  We develop an abstract model to analyze 

the components of overhead costs and benefits gained in order to evaluate 

the trade-off.  We also show applications of that model in the context of 

Ethereum smart contracts.   

b. Besides the benefits-overhead cost analysis, we also investigate the 

problem of ensuring how to ensure that processing off-chain includes 

mitigation of the loss of trust in the blockchain solution due to off-chain 

processing.  However, we do not offer concrete solutions as they depend 

on semantics of the application, semantics that may be obvious to 

developers but not as obvious for automatic analysis by software.  

3. We developed a model that identifies the sub-tasks to be tackled to produce 



6 

 

automatically interface between on and off-chain interaction.   

4. Using FSM modeling we successfully applied the concept of separation of 

concerns by the developer first using FSM modeling to describe the requirements 

and then producing the smart contract.  Only then does the developer, or an expert 

on processing off-chain, use our approach to determine which smart-contract 

patterns should be considered to be processed off-chain, under which conditions, 

and how the on and off-chain processing should interact.  If the developer needs 

to be concerned at the same time about application requirements and patterns to 

be process off-chain, the problem complexity increases greatly.  By using 

separation of concerns, the developer first creates the smart contract to satisfy the 

user requirements and only then tackles the issue of processing off-chain and thus 

simplifying the one complex problem into two simpler ones – albeit still difficult 

problems.   

1.4 OUTLINE 

The remainder of this paper is organized as follows. Chapter 2 reviews the background to 

lay out the context for the models and techniques that we use. Chapter 3 explains the 

FSM modelling approaches for a variety of patterns that often arise in 

business/commerce. We also develop an algorithm to find patterns for an FSM that 

represents a smart contract.  We then explore properties of an FSM graph representation 

to find graph properties that can be used to find patterns that are suitable for processing 

off-chain. We found such graph patterns and describe them and in Chapter 4 we present 

an algorithm that uses those properties to find patterns that are suitable for processing off-

chain.  

Chapter 5 investigates how interface for processing a pattern off-chain can be facilitated 

automatically.  We outline informally the protocol for the interaction between on and off-

chain processing in terms phases of such interaction and of messages with their content 

for each phase.  In Chapter 6, we address under which conditions should the off-chain 

processing of a pattern off-chain proceed from two perspectives:  One is due to the trade 

of between cost and benefits of processing a pattern off-chain, while the other is in 



7 

 

ensuring that the trust in blockchain properties is not diminished when processing of a 

pattern is off-chain.  Finally, Chapter 7 offers a summary and provides conclusions.   

 



8 

 

CHAPTER 2  BACKGROUND 

We examine the following topics as background used for our approach: 

• FSM Modeling for blockchain applications 

• Hierarchical State Machines  

• Off-chaining models and approaches 

• Smart contract design patterns  

2.1 FSM MODELING OF BLOCKCHAIN APPLICATIONS 

For stateful smart contracts, blockchain researchers frequently model smart contracts 

using FSMs by describing the blockchain application functions as state transitions. Inputs 

of the function may be viewed as inputs of FSM transitions. Typically, outputs of the 

function describe the properties of targeted states. In the blockchain-based application, 

the present active state is registered as a global variable. Overall, the blockchain 

application specification is naturally embraced by FSM modeling.   

FSM modeling, which is used frequently in many IT domains, includes the following 

steps: 

• Identify the business problem. 

• Define the use cases and use scenarios. 

• Specify requirements, including actors, states, transitions, inputs, and outputs 

definitions. 

• Identify alternative (exceptional) use cases, such as state timeouts for transitions 

timeout and system errors.  

• Draft FSM for the proposed applications. 

• Implement FSM models with smart contracts. 



9 

 

For instance, Mavridou & Laszka (2017) created an FSM model for Blind auction as an 

example for the proposed FSolidM application (Fig. 2.1).  

 
Fig.  2.1 FSM of Blind Auction (Adopted from Mavridou &Laszka (2017)) 

Mavridou & Laszka (2017) started with use-case analysis by identifying that the bidder, 

one of the actors, can be in one state from the set of states {AcceptingBlindedBids, 

RevealingBids, Finished, canceled} denoted on the Fig. 2.1 as ABB, RB, F, and C, 

respectively. Then inputs, outputs, contract data, and guards are described and used to 

convert the FSM description automatically into parameters and return values of smart 

contract methods.  With the FSM definition combined with the diagram, blockchain 

developers can easily understand the application design and implement it.  We use FSM 

modeling also to determine which portions of an FSM model can be processed off-chain. 

2.2  OFF-CHAINING MODELS AND APPROACHES 

Eberhardt & Tai (2018) categorized generic models for off-chain computation into three 

types based on whether it is for storage, computation, or a combination of the two that are 

performed off-chain.   

Off-chain storage: In this model, selected data and transition outputs are moved to off-

chain storage, while computation is still on the blockchain. As described before, data is 

stored off-chain while data's hashcode is stored on-chain, and verification occurs each 

time the data is retrieved by calculating the hashcode of the retrieved data and comparing 

it to the hashcode stored on the chain. 

Off-chain computation: In this model,  FSM pattern states and their transitions are moved 

to off-chain, while the outputs generated by off-chain computation will be stored and 

persisted on blockchain once off-chain computation completes. The verification process 

occurs when the computation moves back to on-chain and storing the results of off-chain 



10 

 

computation on the chain – the data needs to be verified by actors affected by the 

computation and approved/attested by actors as correct results of off-chain computation.     

Hybrid Off-chain storage and computation: This model combines the two approaches.  

That is, computation and data are processed/stored off-chain while results of off-chain 

computation must be verified and attested by actors.  For instance, both computation and 

storage can be delegated to the sidechain channel Lightning network, with a prudent 

verification process at the end of the off-chain computation. 

We assume that documents and objects are stored off-chain automatically using the 

hashcodes for verifications, and we concentrate on the Hybrid computation.  

2.3 HIERARCHICAL FSM 

Although FSMs are used frequently in modeling distributed applications and smart 

contracts, for complex applications, FSM modeling suffers issues of space, scalability, 

and reusability due to the FSM having only one level of states leading to the flat FSM 

structure.  If there are many states, graphical representation, which is used for ease of 

representation and understanding, suffers due to the graph's large size.  Furthermore, 

specific patterns are repeated in an application and the flat FSM structure of an FSM 

graph does not support the re-use of patterns.  Therefore, inheritance and encapsulation 

principles were incorporated into FSM modeling, leading to Hierarchical State Machines 

(HSMs), first introduced by Harel (1987) and further described and elaborated by 

Yannakakis (2001). An HSM consists of one or more compound states containing their 

own internal FSM. Depending on application complexity, designers can now create an 

internal FSM recursively within an internal state of another internal FSM while leading to 

Hierarchical FSM layers. We leverage HSM in our modeling of applications and finding 

which parts of the smart contract represented by an HSM should be performed off-chain.    

2.4 SMART CONTRACT DESIGN PATTERNS 

A smart contract is an executable program used for FSM model implementation. The 

smart contract can hold complex values, such as struct, defined as FSM properties, and 

immutable instructions representing state transitions. Design patterns have already been 



11 

 

explored for use in the design of smart contracts and a number of examples that we adopt 

for our work include ((Mavridou & Laszka, 2018), (HeartBank, 2018), (Roan, 2020)):   

State Machine: Break down the use case scenario into states to make the use cases 

transparent and controllable. Our FSM modeling approach naturally adopts this design 

pattern. 

Cross-cutting: Define the timeout modifier and assign this modifier to each state of the 

transaction because timeout could happen throughout the transaction.  

Fail early and Fail loud (HeartBank, 2018): Define failure condition as early as possible 

in a smart contract logic to prevent continuous expensive on-chain execution.  

Upgradable Registry (HeartBank, 2018): Try to separate business logic from the data as 

much as possible. It encourages Blockchain designers to consider off-chain/sidechain 

storage. Our approach will potentially maximize its effectiveness.  

Locking (Mavridou & Laszka, 2018): This pattern concept is similar to the 

synchronization mechanism of other mainstream program languages like Java. It locks 

running smart contract instructions to prevent re-entrancy vulnerability caused by 

malicious DOS/DDOS attacks. 

Transition counter (Mavridou & Laszka, 2018): It enforces transition calls in a planned 

order. It helps with overcoming transitions reordering issues reported often for 

blockchains. 

Access control (Roan, 2020): This pattern is implemented as the guard in smart contracts' 

constructor to prevent unauthorized access attempts. 

Many smart contract design patterns summarized above need ample patience and 

prudence from smart contract designers or developers. For instance, smart contract 

developers need to manually attach the defined modifiers to each required function in 

terms of the cross-cutting pattern, which might inevitably introduce human mistakes. 

Fortunately, the FSolidM tool introduced by Mavridou & Laszka (2017, 2018) can 

automatically implement those patterns as plugins. That is,";"""date"",""2021-04-05T19:17:30Z""
""pdf:PDFVersion"",""1.7""
""xmp:CreatorTool"",""MicrosoftÂŽ Word for Microsoft 365""
""pdf:docinfo:title"",""Microsoft Word - sample_thesis_format.doc""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""pdfa:PDFVersion"",""A-3b""
""language"",""en""
""dc:format"",""application/pdf; version=""""A-3b"""""",""application/pdf; version=1.7""
""pdf:docinfo:creator_tool"",""MicrosoftÂŽ Word for Microsoft 365""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""Microsoft Word - sample_thesis_format.doc""
""xmp:CreateDate"",""2021-04-05T16:17:30Z""
""modified"",""2021-04-05T19:17:30Z""
""pdf:hasMarkedContent"",""true""
""xmp:ModifyDate"",""2021-04-05T16:17:30Z""
""pdf:docinfo:creator"",""Christian Gang Liu""
""meta:author"",""Christian Gang Liu""
""meta:creation-date"",""2021-04-05T19:17:30Z""
""created"",""2021-04-05T19:17:30Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2021-04-05T19:17:30Z""
""resourceName"",""Christiangangliu2021.pdf""
""pdfaid:part"",""3""
""Author"",""Christian Gang Liu""
""producer"",""MicrosoftÂŽ Word for Microsoft 365""
""pdf:docinfo:producer"",""MicrosoftÂŽ Word for Microsoft 365""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""access_permission:modify_annotations"",""true""
""dc:creator"",""Christian Gang Liu""
""dcterms:created"",""2021-04-05T19:17:30Z""
""Last-Modified"",""2021-04-05T19:17:30Z""
""dcterms:modified"",""2021-04-05T19:17:30Z""
""title"",""Microsoft Word - sample_thesis_format.doc""
""xmpMM:DocumentID"",""uuid:89F4CC0B-53F3-4BAA-AA88-09C71C791608""
""Last-Save-Date"",""2021-04-05T19:17:30Z""
""pdf:docinfo:modified"",""2021-04-05T19:17:30Z""
""meta:save-date"",""2021-04-05T19:17:30Z""
""Content-Length"",""2166034""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Christian Gang Liu""
""pdfaid:conformance"",""B""
""dc:language"",""en-CA""
""pdf:producer"",""MicrosoftÂŽ Word for Microsoft 365""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""82""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""537"",""3103"",""2429"",""382"",""3112"",""1017"",""158"",""743"",""2160"",""2256"",""2149"",""1953"",""1977"",""2199"",""179"",""1251"",""1886"",""2265"",""2101"",""221"",""2245"",""2305"",""1679"",""1541"",""1959"",""1323"",""2248"",""1790"",""2893"",""1355"",""1385"",""2321"",""1214"",""2167"",""2219"",""2193"",""2216"",""2536"",""2247"",""2090"",""2007"",""1057"",""1998"",""981"",""1805"",""1003"",""2021"",""552"",""2191"",""2575"",""1603"",""2405"",""2362"",""2172"",""2126"",""1822"",""1864"",""2332"",""2619"",""1581"",""2415"",""2339"",""2350"",""1939"",""1964"",""2424"",""1440"",""914"",""2372"",""2293"",""1630"",""1306"",""1420"",""2211"",""2324"",""242"",""1779"",""2516"",""973"",""3369"",""3642"",""2749""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2021-04-05T19:17:30Z""
";https://scholar.google.ch/scholar?start=60&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2021
1619099115-431;https://scholar.google.ch/scholar?as_ylo=2021&q=oracles+blockchain&hl=fr&as_sdt=0,5;COVID-19 Contact Tracing using Blockchain;HR Hasan, K Salah, R Jayaraman, I Yaqoob, M Omar… ;2021 techrxiv.org;;"… Therefore, oracles are the bridges used to connect the blockchain to the outside world;

hence, named as blockchain middleware [23]. 1) The Oracle Problem: The oracle problem

is one of the common problems in the Oracle-based systems [24] …";Cité 1 fois;M Omar;[PDF] techrxiv.org;https://www.techrxiv.org/articles/preprint/COVID-19_Contact_Tracing_using_Blockchain/14052320/files/26519441.pdf;"
1

COVID-19 Contact Tracing using Blockchain
Haya R. Hasan, Khaled Salah, Raja Jayaraman, Ibrar Yaqoob, Mohammed Omar, Samer Ellahham

Abstract—Contact tracing has widely been adopted to control
the spread of Coronavirus-2019 (COVID-19). It enables to iden-
tify, assess, and manage people who have been exposed to COVID-
19, thereby preventing from its further transmission. Today’s
most of the contact tracing approaches, tools, and solutions
fall short in providing decentralized, transparent, traceable,
immutable, auditable, secure, and trustworthy features. In this
paper, we propose a decentralized blockchain-based COVID-19
contact tracing solution. Contact tracing can greatly suffice the
need for a speedy response to a pandemic. We leverage the
immutable and tamper-proof features of blockchain to enforce
trust, accountability, and transparency. Trusted and registered
oracles are used to bridge the gap between on-chain and off-chain
data. With no third parties involved or centralized servers, the
users’ medical information is not prone to invasion, hacking,
or abuse. Each user is registered using their digital medical
passports. To respect the privacy of the users, their locations
are updated with a time delay of 20 minutes. Using Ethereum
smart contracts, transactions are executed on-chain with emitted
events and immutable logs. We present details of the implemented
algorithms and their testing analysis. We evaluate the proposed
approach using security, cost, and privacy parameters to show its
effectiveness. The smart contracts code is publicly made available
on GitHub.

Index Terms—COVID-19; Blockchain; Ethereum Smart Con-
tracts; Transparency; Security Analysis; Contact Tracing

I. INTRODUCTION

The year 2020 has witnessed the spread of Coronavirus-
2019 (COVID-19) all over the world. The major surge of the
virus globally shook the foundations of the health sector which
weren’t adequately prepared and couldn’t respond with high
efficiency. Hence, the advancements in technology can help in
restoring human lives across the world. In efforts to mitigate
the unprecedented spread of COVID-19, contact tracing appli-
cations have widely been developed [1]–[3]. Contact tracing
applications are believed to be able to break the chain of
COVID-19 infections [4]. Contact tracing or proximity tracing
can be used to identify how close someone has been to other
contacts regardless of the context and one of those people
in contact is positive to the pandemic virus. Tracing back all
the possible contacts to the positive case and informing them
about the possibility of being infected is part of contact tracing.
This is essentially important to stop the further spreading of
COVID-19.

Haya R. Hasan, Khaled Salah, and Ibrar Yaqoob are with the Department of
Electrical Engineering and Computer Science, Khalifa University of Science
and Technology, Abu Dhabi 127788, United Arab Emirates.

Raja Jayaraman and Mohammed Omar are with the Department of Indus-
trial and Systems Engineering, Khalifa University of Science and Technology,
Abu Dhabi 127788, United Arab Emirates.

Samer Ellahham is with Heart & Vascular Institute, Cleveland Clinic Abu
Dhabi, Abu Dhabi, United Arab Emirates.

Corresponding author: ibraryaqoob@ieee.org

The deficits of the current contact tracing technologies and
solutions should be overcome to make contact tracing more
successful. Three main issues; namely, privacy, accountabil-
ity, and transparency must be considered when developing
contact tracing applications [5]. Privacy of the users should
be maintained where the data of users and their personal
information should not be stored on centralized servers that are
prone to hacking and abuse. On the other hand, accountability
refers to the role of the technology held accountable for the
decisions taken based on the lack of precision in proximity
measurements. Additionally, transparency is vital when trying
to communicate with the individuals of the societies. Appli-
cation users should know how their input is being used, how
it is processed, and where is the output used and distributed.
However, the current systems do not consider the privacy of
the users and are not transparent enough. Hence, users are
discouraged from using the contact tracing applications [6].

In this paper, we aim to curb the spread of COVID-19
infections through a blockchain-based contact tracing solution.
We leverage the use of the intrinsic features of blockchain
technology to deal with the contact tracing challenges. There-
fore, the implemented solution respects the privacy of its users.
It is immutable, transparent, and accountability is a built-in
feature by design. Blockchain is a distributed shared ledger
that is decentralized with tamper-proof and immutable logs [7].
It is a linked list where all nodes keep a local copy of all the
nodes [8]. Blockchain has a wide range of applications from
e-commerce, to supply chain management [9]. In the context
of the COVID-19 pandemic, blockchain has proven to be a
versatile technology that can be used in several applications
to mitigate the spread of infections [10], [11].

Contact tracing is one of the many ways that blockchain has
proved to be useful to eradicate the effects of the pandemic.
Using Ethereum blockchain with the added programmable
logic using smart contracts allows the different participants
to be transparent, accountable, and trusted. Our solution elim-
inates third-party servers, centralization, and identity abuse. It
relies on the distributed ledger’s immutable logs to enforce
transparency and trust. All transactions taking place on-chain
are signed by their creator. Hence, every on-chain participant
is held accountable for their action.

A. Related Work and Contributions

Herein, we review the existing literature available on contact
tracing applications and their integration with blockchain.

The authors in [12] presented a survey on contact tracing
applications used for COVID-19. The authors were aimed
to highlight the key differences and features of the different
applications especially in certain attributes related to the sys-
tem architecture and design, data security and privacy as well



2

as attacks and vulnerabilities. The authors outlined different
applications such as Trace Together, Covid Safe, Covid Watch,
and EpiOne. The authors concluded that each application
based on its architecture whether centralized, decentralized,
or hybrid has its pros and cons. They also emphasized on
the adoption rate between the users and how it can increase
with transparency. Decentralization in their context referred
to reducing the load on the servers and increasing it on the
user devices. They did not tackle the aspect of decentralization
using blockchain-based solutions.

The authors in [11], [13], [14] discussed that blockchain can
be used to create a decentralized contact tracing solution. Its
intrinsic features help in ensuring transparency, trust, pseudo-
anonymity, and decentralization. In [15], the authors presented
a blockchain-based contact tracing framework. They high-
lighted the privacy concerns in the available contact tracing
applications due to the use of centralized servers and suggested
a blockchain-based design that could overcome the privacy
issues of the existing solutions. Their solution does not show
any implementation details or testing results. On the other
hand, BeepTrace [16] emphasized on the importance of using
blockchain in contact tracing to add trust, transparency, and
privacy. Hence, in their solution, they introduce two types of
blockchain networks one for the tracing and the other one
for the notifications. BeepTrace shows promising results when
compared to other solutions presented by the authors in terms
of cost, security, and privacy. However, its solution depends
on using trusted third parties such as the ’Geodata solvers’
servers as well as a Public Key Infrastructure (PKI).

To overcome the use of third parties, the authors in [17] pro-
posed a blockchain network named Bychain. In the network,
they amend the fields of the used blockchain blocks to suit
their block proposal and validation scheme. Their solution also
depends on short-range communication (SRC). The testing
is done on the implemented blockchain network design to
test the messages’ latency, power consumption, computation,
and storage limitations. Their main objective is to test the
newly created Bychain which offers limited information on
results related to COVID-19 contact tracing. Moreover, the
study conducted in [18] made use of an Internet of Things
(IoT) hardware model that uses passive RFID transceivers. The
solution ensures that users remain anonymous until a user tests
positive for the COVID-19 virus. The study presents smart
contract (SC) codes, as well as hardware details. However,
the study does not present a complete architecture or design
of the proposed blockchain solution. Furthermore, the study
conducted in [19] presents a contact information sharing and
risk notification system using blockchain. Their solution uses
Bluetooth as a short-range communication technology. Their
solution concentrates on quantifying the possibility of a user
infection based on the information provided by the user or
from the shared information. The status of the user changes
based on information entered by the users. The possibility of
infection for other contacts is calculated using an equation
proposed by the authors.

Numerous research efforts have been conducted on COVID-
19 contact tracing [12]. However, most of the existing solu-
tions are based on centralized servers or third parties [20]. Fig-

ure 1 presents a basic architecture of the centralized solution
that depends on servers. The application users would send their
location information to centralized data centers. On the other
hand, the COVID-19 testing centers send the COVID-19 test
results to the centralized servers. The server would do all the
processing based on the input received by the application users
and the testing centers. The result containing the COVID-19
contacts list is then sent to the COVID-19 testing centers to
take the needed action. Hence, in such an architecture, the
users’ information is all stored in the servers. Also, there
is no transparency, and everyone involved needs to trust the
server and each other in being honest. Furthermore, such a
system is prone to being a single point of failure. Unlike the
aforementioned solutions, our solution leverages blockchain
technology and utilizes its built-in security features to present
transparent, tamper-proof, and immutable transactions between
all participating entities.

Figure 1: Centralized contact tracing applications using servers

The main contributions of this paper can be summarized as
follows:
• We showcase a blockchain-based approach to enable

and provide COVID-19 contact tracing in a manner that
is fully decentralized, transparent, traceable, immutable,
auditable, secure, and trustworthy.

• We integrate the Ethereum blockchain with on-chain reg-
istered oracles to execute the contact tracing algorithms
to put down the extra burden and save cost.

• We develop smart contracts along with algorithms to
implement functionalities and define rules regarding
COVID-19 contact tracing applications. The smart con-
tracts code is publicly made available on GitHub1.

• We perform the cost analysis to show feasibility and
affordability of the solution, and present security analysis
to show that our smart contracts are secure enough against
well-known vulnerabilities and attacks.

• Our proposed blockchain-based COVID-19 contact trac-
ing solution is generic and can be easily customized as
per the needs and requirements of various types of contact
tracing applications focusing on other diseases.

The rest of the paper is organized as follows. Section II
presents the design details of the proposed blockchain-based
solution followed by the implementation details in section
III including the smart contracts and algorithms. Section IV

1https://github.com/smartcontract694/covid19/tree/master



3

Figure 2: System diagram of the proposed blockchain-based COVID-19 contact tracing solution

presents the testing details of the proposed system followed
by section V which showcases the security and cost analysis
along with discussing the privacy and generalization aspects.
Section VI concludes the paper.

II. SYSTEM DESIGN

This section presents the system design of our proposed
blockchain-based COVID-19 contact tracing solution. Figure
2 shows the system components of the solution along with
the interacting entities. The decentralized application (DApp)
users employ their smartphones to trigger proof of locations
that are logged on-chain through the smart contracts. Conse-
quently, the registered oracles use the broadcast events and
locations in their contact tracing algorithms. On the other
hand, the COVID-19 testing centers send COVID-19 results
to the blockchain to trigger alerts as needed. The alerts issued
vary depending on the received result. Those emitted events
are alerts used to notify the registered oracles to execute the
contact tracing algorithm. The registered oracles return the list
of contacts of the possibly infected individuals to the smart
contract.

A. DApp Users

DApp users employ the downloaded contact tracing applica-
tion to trigger proof of locations. Those proof of locations have
the latitude, longitude, time, and date that are communicated
to the ’Location Tracking SC’. Communication happens when
a user is within contact with another user at a distance of
fewer than 2 meters only. This allows saving on power and
cost. Smartphones find each other through short-range com-
munication such as Bluetooth. Other means are also possible
using WiFi or mobile data. Each user’s proof of location and
contact is stored on the ledger for an immutable log that is
trusted when needed. Furthermore, to preserve the privacy of
the user there is a 20-minute delay before sending proof of
location. This is done to ensure that the current location of

the user is not known. Hence, the user’s privacy is not abused
through invasion.

The application users must be registered to use the contact
tracing application and on-chain functions. The registration is
done through the affiliated testing centers and every Ethereum
address (EA) is associated with bio-metrics data. Furthermore,
the registered users have a digital medical passport that has all
their medical information [21]. Health Passport is identified as
an emerging technology in Gartner’s 2020 Hype Cycle [22]
and this research uses the concept of the medical passport from
our previous work conducted in [21] as part of the solution.
The users’ right to convey the information included in their
medical passports to other entities is based upon their choice
[21]. All the information on-chain is stored using IPFS hashes.
The information is kept confidential until the user allows a
certain entity to get access to the information. Hence, only
then this information is disclosed to the entity authorized by
the user [21]. Therefore, authorization is needed by the users
to disclose any of their information.

B. COVID-19 Testing Centers

COVID-19 testing centers are specialized in conducting
COVID-19 tests. They would communicate the result with the
’COVID-19 Notification SC’ to issue an alert based on the
result. The COVID-19 testing centers also await a response
from the COVID-19 Notification SC. This response helps
them in finding out the people of contact that need to be
quarantined, tested, and treated if needed. The SC in response
issues yellow alerts that are based on the result of the contact
tracing algorithms run by the registered oracles. Hence, the
COVID-19 testing centers are the point of contact between
the test takers and the COVID-19 Notification SC.

C. On-chain Smart Contracts

Using the Ethereum blockchain, it is possible to execute
smart contracts that carry programmable logic. Digital assets



4

Figure 3: Oracles communication with the COVID-19 Notification SC

as well as ’Ether’ can be controlled using the logic presented
in the SC. Events are emitted in logs to ensure that the
actions taken are transparent and immutable. This establishes
trust among all the participating entities on-chain. In our
proposed solution, we have implemented in our design two
smart contracts.

1) Location Tracking SC: In the location tracking SC,
locations of the DApp users are logged. This is the main task
of the smart contract. This is a very vital step to ensure that all
contacted individuals can be traced based on their locations.
The decentralized applications communicate to the blockchain
the locations of their users through the location tracking smart
contract. The longitude, latitude, as well as time, are all sent to
be immutably logged. The smart contract, on the other hand,
can emit events that get broadcast to all the registered oracles
as well as participating entities. This ensures that the GPS
coordinates are available when needed for contact tracing.

2) COVID-19 Notification SC: The COVID-19 notification
smart contract handles COVID-19 alerts. The alerts are of
three types based on the COVID-19 test results. Red, yellow,
and green are the three colors used to identify the alert types.
The different alerts are issued by the smart contract after
the COVID-19 test results are sent by the COVID-19 testing
centers. The issued alerts are then used to update the on-chain
profiles of the users as well as alert the registered oracles of the
new updates. The registered oracles use the logged COVID-19
alerts on-chain to know whether a contact list is required. A

red or yellow alert based on the testing center results indicates
that the contact tracing algorithm must be executed. However,
it does not require to be executed in the case of a green alert.
The registered oracles execute the contact tracing algorithm
and return the list of contacts that could be infected. The
individuals’ EAs are entered into the smart contract and the
results are emitted as yellow alerts. Those alerts are used by
the testing centers as well as DApp users to notify the users
that they could be infected by the virus. The status of the users
would turn to yellow based on the contact tracing information.

D. Registered Oracles

Oracles are used to connect the blockchain to the off-chain
data and input. To maintain the deterministic nature of the
decentralized blockchain, no external calls to any APIs are
allowed. Therefore, oracles are the bridges used to connect the
blockchain to the outside world; hence, named as blockchain
middleware [23].

1) The Oracle Problem: The oracle problem is one of the
common problems in the Oracle-based systems [24]. Choosing
only one oracle as the main source of information from the
outside world leads to create dependency on a single entity
that can result in a single point of failure [25]. Furthermore,
it is hard to assume that a single oracle can be trustworthy
given the possibility that it can be hacked and depreciated.
To solve the oracle problem, a network of oracles need to
be used [26]. Hence, we used a cluster of registered oracles



5

that communicate with the Ethereum smart contracts on-chain.
This ensures that the blockchain has access to reliable secure
off-chain data. Decentralized networks of oracles are a solution
that maintains the distributed nature of blockchain at the same
time along with ensuring that the blockchain can have access
to real-world data and information.

2) Oracles Registration: Oracles need to register so that
they become authorized to access the functions in the smart
contracts. In our design, the ’Oracles SC’ is the smart contract
responsible for the services of the oracle such as registration,
awarding, and penalizing. The ’Oracles SC’ owner is an au-
thorized entity that would accept the registration of an oracle.
Once an oracle’s Ethereum address is part of the registered
oracles, it becomes authorized to execute the functions in the
COVID-19 Notification smart contract. A previously registered
oracle can also become prohibited from accessing or executing
the functions. This is also done through the ’Oracles SC’.

3) Oracles Contact Tracing Results: The registered oracles
execute the contact tracing algorithm in response to the
received red or yellow alert from the ’COVID-19 Notification
SC’. Every alert sent by the ’COVID-19 Notification SC’
possesses an ID to clearly label and identify it. The list
produced by the oracles is assembled off-chain and its hash
is computed. The list hash is then sent to the COVID-19 No-
tification SC. Each registered oracle needs to respond within
the time allocated by the smart contract. The oracle has to
send the list hash to the smart contract along with the request
ID. Once the deadline is reached the timer oracle would
then call the COVID-19 Notification SC to start comparing
the received hashes and to declare the majority hash. The
majority hash is the hash that matches at least 50 % of the
compared hashes. Figure 3 shows the communication details
between the registered oracles and the COVID-19 Notification
CS. It illustrates how the oracles execute the contact tracing
algorithm and then send the hash to the smart contract for
comparison and further computations.

4) Oracles Rewards and Penalty: The first oracle to have
submitted a hash matching the majority hash is considered
the winning oracle and is rewarded for its timely and accurate
response. Oracles should be rewarded and penalized based on
their behavior and output results [27]. This is done through
digital assets, Ether as well as reputation. The reputation
of oracles depends on how well they execute their tasks,
their honesty, and their trustworthiness. Hence, each registered
oracle is associated with a reputation that gets affected based
on its performance. The winning oracle is rewarded with Ether
to encourage other oracles to try and respond promptly.

III. IMPLEMENTATION DETAILS

This section presents the proposed algorithms along with
their implementation and coding details. The solidity code
is written and tested using the Remix IDE [28]. Further
discussion is provided in the following subsections.

A. Proof of Locations

Algorithm 1 shows the details of the
)A8664A!>20C8>=�;4AC function available in the ’Location

Tracking SC’. In this function, proof of locations of the
mobile applications users is emitted by the smart contract
based on the input received. The notification that is alerted
contains the longitude, latitude, EA of the application user as
well as the time.

B. Oracle Registration

The oracles that participate in the smart contracts must be
registered. Algorithm 2 presents the registration details of the
oracles in the ’Oracles SC’. Oracle registration is only possible
through the smart contract owner. Hence, the algorithm checks
the EA of the function caller. Then a mapping is used to
complete the registration where the EA of the oracle is mapped
with the boolean ’true’.

C. Oracle Revoking

If an oracle can no longer participate with the smart con-
tracts, then it is revoked by the Oracle SC owner. Algorithm 3
shows the details of revoking the previously registered oracle.
This is done by mapping the EA of the oracle to a boolean
value of ’false’.



6

D. Broadcast COVID-19 Test Results

In the COVID-19 Notifications SC, the COVID-19 test
results are sent by the testing centers to the smart contract.
This is done through the (4=3ďż˝>E8319)4BC'4BD;CB function.
Algorithm 4 explains the details followed in the function. The
results show three types of events either a test taker is COVID-
19 positive, or a contact, or COVID-19 negative. Those results
emit a red, yellow, or clear alert, respectively. Each result
received by the testing center and sent on chain is given an ID.
A red request ID and a yellow request ID are also maintained
for tracing back easily when needed. The timestamp on chain
as well as the request ID are stored every time a new request
is created as can be seen in algorithm 4. This algorithm can
only be executed by the smart contract owner who is the testing
center representative on chain. Therefore, a modifier is used
to restrict access to the function accordingly.

E. Return the Contact Tracing List Hash

Once an event is emitted for a red or a yellow alert, the
registered oracles’ role commences. Each of the registered
oracles should execute the contact tracing list algorithm to find
out the EAs of all the contacted people who could be infected
by the COVID-19 virus. Those EAs could be numerous.
Consequently, a hash is sent by the registered oracles using
algorithm 5. Each registered oracle calls the function using the
request ID, request timestamp, and the list hash. The function
as can be seen in the algorithm checks the EA of the oracle to
ensure the oracle is registered. Furthermore, it verifies that the
ID and timestamp match the ID and timestamp of the request
ID. In addition to those two aforementioned restrictions, the
oracle has to reply within the allocated time of 60 seconds,
otherwise, the entry is refused. Moreover, this function will
only accept entries for a particular request ID at a time. Hence,
it processes the request IDs sequentially. It first accepts all the
entries for the current request ID and then once that request’s
deadline approaches and the timer oracle ends the time for it,
this function starts accepting entries for the next request ID.
This is important to avoid making lists for each request ID at

the same time which would cost a lot more compared to the
current approach where only one list is reused every time a
new request ID is processed. Five restrictions are important
to ensure the proper execution of this function. Last but not
least, the algorithm ensures that each oracle can only execute
the function once. This is vital to ensure that it is fair for all
the registered oracles. Also, this helps in mitigating the risk
of having one oracle dominating and abusing their powers to
deny others from casting their replies. Hence, to achieve this
a unique value is stored every time an oracle submits its list



7

hash. This unique value is the :4220:256 hash of the oracle’s
EA concatenated with the request ID.

We have used a combined index to ensure the value is
unique for every entry submitted by an oracle. This com-
bined index is then mapped to a boolean value. When an
oracle returns a list for the first time, the combined index
created is mapped to CAD4. This value is checked every time
an oracle returns a list. If the value returned is true, the
check returns a 5 0;B4 and the contract state is reversed. The
:4220:256 hash is used instead of other hashes as it is the
least expensive in terms of gas cost. To be able to easily
find the hash of the oracle’s EA concatenated to the request
ID using built-in solidity functions only, the :4220:256
function of solidity accepts multiple values together if they
are padded correctly. Hence, we ensured that no padding
is done between both values when concatenated using the
built-in function 018.4=2>34%02:43. This function concate-
nates both values in a byte array in the memory without
changing their values. Consequently, in solidity we used the
following line of code to hash and concatenate as needed
:4220:256(018.4=2>34%02:43 (<B6.B4=34A, ��)).

F. Find Majority of the Contact List Hashes

Algorithm 6 describes the details of finding the most com-
mon hash (majority) of all the received list hashes. The smart
contract finds out the most repeated hash of all the hashes
submitted by the registered oracles. A maximum count is
stored in the algorithm and is swapped when a new maximum
is found. The majority value is concluded when the maximum
count is equal to or exceeds half of the number of hashes
submitted. The algorithm returns the index of the majority
value as an output.

G. Choose the Winning Oracle

In algorithm 7, the timer oracle executes a function when
the allocated time for the oracles to submit their hashes is
over. When the deadline for the oracles to submit their hashes
is reached, algorithm 6 is called from within algorithm 7. The
returned index from algorithm 6 is then used to locate the EA
of the first oracle that replied with the chosen winning hash.
A notification is emitted with the oracle’s EA and the winning
hash. Once the winning oracle is chosen, the request ID that
can now be handled by the smart contract is incremented by
1. Furthermore, all the arrays used for storing and choosing
the majority hash and winning oracle for the previous ID are
deleted to be ready for processing the new request.

H. Submit Contact Tracing List EAs

The selected winning oracle will then submit the EAs of
all the individuals in the contact tracing list. This is done one



8

by one by executing the function ďż˝=C4Aďż˝>=C02C)A028=6!8BC
in the COVID-19 Notification SC. The function executes the
algorithm described in algorithm 8 where the selected oracle
can only be allowed to call the function. Furthermore, the EAs
of the individuals are entered through the function as well as
the request ID and a boolean value. The boolean is used to
indicate if there are more function calls to be executed for the
same request. For instance, when the chosen oracle reports
the last EA, the boolean value reported would be false, unlike
the previous calls where it was true. Whenever the function is
executed, an event is emitted to issue a yellow alert introducing
the individuals of the list using their associated EAs.

IV. TESTING AND VALIDATION

In this section, we rigorously tested the proposed smart con-
tracts and presented their results. In our testing, the functions
are tested for their functionality as well as the restrictions on
them. Each function with a modifier to restrict the identity of
the executor is tested with other EAs and the result is verified.
Moreover, events and their logs are checked to ensure that they
are as expected. Each smart contract has an owner. The owner
could be a predefined EA in the smart contract or the EA of
the entity that deploys the smart contract to the blockchain.
The participating entities that interact with the smart contracts
are the Location Tracking SC owner, the Oracles SC owner,
the Notification SC owner, the registered algorithm tracing
oracles, and the timer oracle. The functions are executed using
the Remix [28] IDE and the results are shown in snapshots
that showcase the function executed along with the results.

A. Location Tracking SC: Location Alert Triggering

A function called )A8664A!>20C8>=ďż˝;4AC notifies by trig-
gering an event every time when proof of location is sent to
the blockchain. Figure 4 shows the latitude, longitude, user
EA as well as the time successfully emitted as an event to all
the participating entities as part of the immutable logs.

Figure 4: Logs showing a successful proof of location event

B. Oracle SC: Oracle Registration

Oracles need to be registered to execute functions call in the
smart contract. Hence, the '468BC4A$A02;4 function is used to
register the oracles as can be seen in figure 5. The registration
is performed using the oracle’s EA. The EA is successfully
added to the list of registered oracles mapping. Using this
method, any oracle that tries to execute a function is first
checked using an internal function in the Oracle SC to ensure
that it is registered. The internal function returns a boolean
which is the value mapped to the EA of the oracle at the time
of the registration. ’True’ is the boolean value mapped when
registering the oracle. The registration can only be done by the
owner of the Oracle SC. While testing, the Oracle SC owner
holds the EA 0G5�38�06070125685453� 5 2�03�2�875 5 561433�4
and the EA of the successfully registered oracle is
0G3�870 5 �117�4700�2��7 5 44238821�26 5 7392148 as can be seen in
figure 5.



9

Figure 5: Logs of an oracle successfully registered in the
Oracle SC

C. Oracle SC: Oracle Revoking
An oracle may no longer be trusted. Hence, a previ-

ously registered oracle with a boolean mapping of CAD4 is
revoked by changing its mapped value to 5 0;B4. Function
'4E>:4$A02;4 in the $A02;4(ďż˝ is used to do so. The
function once executed successfully changes the mapping and
revokes an oracle. Figure 6 shows a successful execution of
the function where the SC owner revoked the oracle with
the EA 0G3�870 5 �117�4700�2��7 5 44238821�26 5 7392148 from";"""date"",""2021-02-18T07:53:24Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""20"",""20"",""74"",""90"",""112"",""23"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.5""
""xmp:CreatorTool"",""TeX""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dcterms:created"",""2021-02-18T07:53:24Z""
""language"",""en""
""Last-Modified"",""2021-02-18T07:53:24Z""
""dcterms:modified"",""2021-02-18T07:53:24Z""
""dc:format"",""application/pdf; version=1.5""
""Last-Save-Date"",""2021-02-18T07:53:24Z""
""pdf:docinfo:creator_tool"",""TeX""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2021-02-18T07:53:24Z""
""meta:save-date"",""2021-02-18T07:53:24Z""
""pdf:encrypted"",""false""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.21 (TeX Live 2020) kpathsea version 6.3.2""
""modified"",""2021-02-18T07:53:24Z""
""Content-Length"",""2840834""
""pdf:hasMarkedContent"",""false""
""Content-Type"",""application/pdf""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.21 (TeX Live 2020) kpathsea version 6.3.2""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""trapped"",""False""
""meta:creation-date"",""2021-02-18T07:53:24Z""
""created"",""2021-02-18T07:53:24Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""13""
""Creation-Date"",""2021-02-18T07:53:24Z""
""resourceName"",""26519441.pdf""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""5258"",""5031"",""3303"",""2657"",""3463"",""2359"",""2182"",""2552"",""3183"",""4049"",""5357"",""5788"",""746""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""producer"",""pdfTeX-1.40.21""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""pdfTeX-1.40.21""
""pdf:docinfo:created"",""2021-02-18T07:53:24Z""
";https://scholar.google.ch/scholar?start=20&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2021
1619099111-424;https://scholar.google.ch/scholar?as_ylo=2021&q=oracles+blockchain&hl=fr&as_sdt=0,5;Blockchain-Based Reputation Systems: Implementation Challenges and Mitigation;A Battah, Y Iraqi, E Damiani ; Electronics, 2021  mdpi.com;;"… computation of the reputation in order to remove some of the load of the blockchain … is why there

needs to be a mechanism that establishes trust of the oracle results … There are several approaches

where decentralized oracles can provide results and a certain selection algorithm …";Les 6 versions;En cache;[PDF] mdpi.com;https://www.mdpi.com/2079-9292/10/3/289/pdf;;;https://scholar.google.ch/scholar?start=10&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2021
1619099107-417;https://scholar.google.ch/scholar?as_ylo=2021&q=oracles+blockchain&hl=fr&as_sdt=0,5;[PDF][PDF] A decision model for choosing patterns in blockchain-based applications;X Xu, H Bandara, Q Lu, I Weber, L Bass… ; 18th IEEE Int. Conf. on …, 2021  researchgate.net;;"… Name Summary Centralized oracle [6] Introduce external state into the blockchain through a

centralized oracle Decentralized oracle [6] Introduce external state into the blockchain through

multiple independent oracles History oracle [15] Provide historical states in addition to the …";Cité 2 fois;Version HTML;[PDF] researchgate.net;https://www.researchgate.net/profile/Xiwei-Xu-2/publication/349412778_A_Decision_Model_for_Choosing_Patterns_in_Blockchain-Based_Applications/links/602ec84da6fdcc37a83786d8/A-Decision-Model-for-Choosing-Patterns-in-Blockchain-Based-Applications.pdf;;;
1619099142-488;https://scholar.google.ch/scholar?as_ylo=2021&q=oracles+blockchain&hl=fr&as_sdt=0,5;Residential energy trading with blockchain technology;G Yun, V Zhygulin, QP Zheng ; Energy Systems, 2021  Springer;;"… both signatures are present, the proposal is submitted to the blockchain layer 2 (usually it is done

by the market taker), and the blockchain performs transaction clearance. In addition, Layer 4

can be implemented using one of the well-studied cryptocurrency protocols, integrated …";;null;null;;;;https://scholar.google.ch/scholar?start=80&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2021
1619099129-467;https://scholar.google.ch/scholar?as_ylo=2021&q=oracles+blockchain&hl=fr&as_sdt=0,5;'Lex Cryptographia,''Cloud Crypto Land'or What?–Blockchain Technology on the Legal Hype Cycle;M Schillig ; Cloud Crypto Land'or What, 2021  papers.ssrn.com;;"… 5 N Roubini, Crypto is the Mother of All Scams and (Now Busted) Bubbles While Blockchain is

the Most Over … Database, Testimony for the Hearing of the US Senate Committee on banking,

Housing and Community Affairs on “Exploring the Cryptocurrency and Blockchain …";;null;null;;;;https://scholar.google.ch/scholar?start=50&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2021
1619099142-494;https://scholar.google.ch/scholar?as_ylo=2021&q=oracles+blockchain&hl=fr&as_sdt=0,5;A Blockchain-based Trust System for Decentralised Applications: When trustless needs trust;N Truong, GM Lee, K Sun, F Guitton, Y Guo ; arXiv preprint arXiv …, 2021  arxiv.org;;"… Introduction The turn of the last decade brought us to the disruptive Blockchain technology (BC …

are different perspectives of DApps definition and system development among the cryptocurrency

space … and executed in a decentralised BC (eg, using SCs), and ( ) a crypto token is …";Les 2 versions;Version HTML;[PDF] arxiv.org;https://arxiv.org/pdf/2101.10920;"
Highlights
A Blockchain-based Trust System for Decentralised Applications: When trustless needs trust
Nguyen Truong,Gyu Myoung Lee,Kai Sun,Florian Guitton,YiKe Guo

• Introduce a novel concept and provision of a universal decentralised trust system that can be integrated into any DApps
sharing a same Blockchain platform.

• Present a decentralised trust model with theoretical analysis, algorithms, and simulations.
• Provide the whole agenda of the trust system development including technical solutions, implementation reference, as

well as performance evaluation.

ar
X

iv
:2

10
1.

10
92

0v
1 

 [
cs

.C
R

] 
 2

6 
Ja

n 
20

21



A Blockchain-based Trust System for Decentralised Applications:
When trustless needs trust
Nguyen Truonga,∗, Gyu Myoung Leeb, Kai Suna, Florian Guittona and YiKe Guoa,c
aData Science Institute, South Kensington Campus, Imperial College London, London SW7 2AZ, United Kingdom
bDepartment of Computer Science, Liverpool John Moores University, Liverpool L3 3AF, United Kingdom
cDepartment of Computer Science, Hong Kong Baptist University, Kowloon Tong, Hong Kong

ART ICLE INFO
Keywords:
Blockchain
DApps
Decentralised Ecosystem
Reputation
Trust System

Abstract
Blockchain technology has been envisaged to commence an era of decentralised applications and ser-
vices (DApps) without the need for a trusted intermediary. Such DApps open a marketplace in which
services are delivered to end-users by contributors which are then incentivised by cryptocurrencies in
an automated, peer-to-peer, and trustless fashion. However, blockchain, consolidated by smart con-
tracts, only ensures on-chain data security, autonomy and integrity of the business logic execution
defined in smart contracts. It cannot guarantee the quality of service of DApps, which entirely de-
pends on the services’ performance. Thus, there is a critical need for a trust system to reduce the risk
of dealing with fraudulent counterparts in a blockchain network. These reasons motivate us to de-
velop a fully decentralised trust framework deployed on top of a blockchain platform, operating along
with DApps in the marketplace to demoralise deceptive entities while encouraging trustworthy ones.
The trust system works as an underlying decentralised service providing a feedback mechanism for
end-users and maintaining trust relationships among them in the ecosystem accordingly. We believe
this research fortifies the DApps ecosystem by introducing an universal trust middleware for DApps
as well as shedding light on the implementation of a decentralised trust system.

1. Introduction
The turn of the last decade brought us to the disruptive

Blockchain technology (BC) that provides a trusted infras-
tructure for enabling a variety of decentralised applications
and services (DApps) without the need for an intermediary.
To actualise this vision, Smart Contracts (SCs) technology is
consolidated into the BC-based infrastructure: SCs are pro-
grammed to perform services’ business logic, compiled into
byte-code, and deployed onto a BC platform (i.e., replicated
into full-nodes in the platform) so that a user can create trans-
actions to execute the business logic implemented in the SCs
in a decentralised fashion [9]. This infrastructural BC plat-
form offers some advanced features including immutability,
transparency, trace-ability, and autonomy that are promising
to effectively implement plentiful DApps from financial ser-
vices (i.e., cryptocurrencies trading) to numerous services
such as digital asset management [1], provenance tracking
in logistics and supply-chain [14, 21], and data sharing and
processing in the Internet of Things (IoT) [28, 22].

Indeed, various DApps have already been developed and
employed into the real-world. For instance, there are over
4000 DApps deployed on top of the Ethereum, Tron, and
EOS platforms, serving about 150k active users daily in 20191.
This is a considerable ecosystem and a huge decentralised
peer-to-peer (P2P) marketplace. Although there are numer-
ous challenges due to the limitation of the current BC tech-
nology hindering the advancement of DApps, we believe

∗Corresponding author
n.truong@imperial.ac.uk (N. Truong); g.m.lee@ljmu.ac.uk (G.M.

Lee); k.sun@imperial.ac.uk (K. Sun); f.guitton@imperial.ac.uk (F.
Guitton); y.guo@imperial.ac.uk (Y. Guo)

ORCID(s):
1https://cointelegraph.com/news/report-ethereum-tron-and-eos-dominated-dapp-ecosystem-in-2019

that “everything that can be decentralized, will be decen-
tralized” - David A. Johnston2. The DApps ecosystem is
just in its preliminary state and will be the future of the next-
generation Internet.
1.1. Features of DApps

There are different perspectives of DApps definition and
system development among the cryptocurrency space. Nonethe-
less, mutual perceptions were pointed out that a DApp must
satisfy some requirements: (i) open source so that partici-
pants can audit the system, (ii) application operations and
data are recorded and executed in a decentralised BC (e.g.,
using SCs), and (iii) a crypto token is used to access the
service and to contribute to the operations (e.g., token re-
ward) [18, 8]. As of these features, ideally, DApps have the
ability to operate without human intervention and to be self-
sustaining because the participation of stakeholders is con-
tinuously strengthening the systems. According to Vitalik
Buterin, DApps generally fall into two overlay categories,
namely fully anonymous DApps and reputation-based ones
[8]. The first category is DApps which participants are es-
sentially anonymous and the whole service business logic is
autonomously executed by a series of instant atomic opera-
tions. Pure financial services such as Bitcoin are examples of
this. Another example is digital assets trading DApps such
as software license, data, and digitised properties in which
the ownership can be impeccably transferred once a contract
(defined and implemented using SCs) has been performed
[32].

The second category refers to a type of DApps which
business logic requires a reputation-like mechanism to keep

2http://www.johnstonslaw.org

Nguyen Truong et al.: Preprint submitted to Elsevier Page 1 of 14

https://cointelegraph.com/news/report-ethereum-tron-and-eos-dominated-dapp-ecosystem-in-2019
http://www.johnstonslaw.org


Empowering Blockchain-based Decentralised Applications Ecosystem

track of participants’ activities for trust-related purposes. For
instance, DApps for data storage and computation, similar
to Dropbox and Amazon AW S in the centralised space, do
require to maintain reputation-like statistic record of peers
for service quality and security-related purposes (e.g., anti-
DDoS). This requirement of trust is irrelevant to BC tech-
nology which supposedly ensures only data security (e.g, for
distributed ledgers), autonomy and integrity of the business
logic execution programmed in corresponding SCs. The qual-
ity of service (QoS) of such a DApp also depends on the ser-
vice itself (i.e., how well the service handles the business
logic defined in the SCs and caters to customers).
1.2. Necessity of a Trust System in DApps

Ecosystem
DApps usage always comes with token movement from

end-users to service contributors as a result of an incentive
scheme, which is crucial to maintaining the service. How-
ever, due to the immutable nature, it is practically impossible
to revoke any transaction once it is settled onto BC. Thus, a
DApp has to make sure that end-users are dealing with trust-
worthy counter-parties before invoking any SCs’ functions
that can lead to a token payment. Intuitively, end-users tend
to look for an indication of ’assurance’ before using any ser-
vices. Indeed, a variety of DApps share the same stance on
a challenge of lacking a unified decentralised framework to
evaluate the trustworthiness of participants (for instance, de-
centralised storage and computing (similar to cloud storage
like Dropbox and Amazon AW S), home-sharing (similar
to Airbnb), car-sharing (similar to Uber), or a hotel dis-
tribution and reservation service (similar to Booking.com)
backed by a BC platform). Consequently, a trust middleware
that supports DApps’ end-users to transact with trustworthy
counterparts is of paramount importance as it penalises de-
ceptive participants while encouraging authentic ones. As
illustrated in Fig. 1, DApps, built upon a BC platform em-
powered by a decentralised trust system, naturally build up
trust with clients and create a virtuous cycles that bolster the
whole DApps ecosystem growth.

Figure 1: A BC platform strengthened with a trust system cre-
ates a virtuous cycle sustaining the DApps ecosystem growth

1.3. Objectives and Contributions
Our objectives are to envision and develop a universal

decentralised system that operates along with any DApps to
evaluate trust relationships between entities in the ecosys-
tem. This trust system plays as middleware between a BC
platform and DApps that provides mechanisms for DApps’
end-users to build up and maintain a trust relationships net-
work among the users. Operations of the system are fully
decentralised, transparent, and accessible to all of the par-
ticipants which are autonomously and flawlessly executed in
a trustless fashion. It is also expected to effectively prevent
from reputation attacks (e.g., Sybil, White-washing, Self-
promoting, and Bad&Good-mouthing) and to dismiss mas-
querading hostile participants.

The main contributions of this paper are three-fold:
• Introduction to the concept and provision of a univer-

sal decentralised trust system that can be integrated
into any DApps sharing a same Blockchain platform.

• A decentralised trust model with theoretical analysis,
algorithms, and simulations.

• Providing the whole agenda of the real-world develop-
ment of the system including technical solutions, im-
plementation reference, as well as performance eval-
uation.

The rest of the paper is organised as follows. Section II
briefly brings up background and related work and presents
the provision and conceptual model of a decentralised trust
system. Section III describes a system design with a trust
evaluation model for the proposed system. Section IV pro-
vides the algorithms and the theoretical analysis of the trust
evaluation model. Section V is to discuss on the technical
solutions and the implementation reference for the system
development. Section VI is dedicated to the system analysis
and discussion. Section VII concludes our work along with
the future research directions.

2. Decentralised Trust System Provision for
DApps Ecosystem
To craft a BC platform into a mature DApp development

environment, fundamental elements must be incorporated
such as an Identity Management (IdM), a name registry, a
wallet, a P2P messaging for end-users, a browser, and a de-
centralised trust/reputation system [8]. These elements are
core built-in services of a BC-based infrastructure for DApps
development.
2.1. Related Work

A large number of trust management mechanisms that
have been proposed in various environments including so-
cial networks[34], P2P or ad-hoc networks [2], and IoT [37,
31, 30]. Those trust models could be adapted to different sce-
narios including BC-related environment. However, as the
emerging BC technology is in the early stage, there is lim-
ited research on trust management for DApps. Most of the

Nguyen Truong et al.: Preprint submitted to Elsevier Page 2 of 14



Empowering Blockchain-based Decentralised Applications Ecosystem

related research is to develop a trust or reputation manage-
ment platform leveraging the advantages of BC such as de-
centralisation, immutability, trace-ability, and transparency.
In this respect, researchers have proposed BC-based trust
mechanisms to fortify specific applications in various envi-
ronments including vehicular networks and intelligent trans-
portation systems [38, 12], wireless sensor networks [24,
29], or IoT [13, 20]. For instance, W. She et al. in [29] have
proposed a BC-based trust model to detect malicious nodes
in wireless sensor networks by implementing a voting mech-
anism on-chain, ensuring the trace-ability and immutability
of voting information. M. Debe et al. have developed a
reputation-based trust model built on top of Ethereum plat-
form for fog nodes in a Fog-based architectural system [6].
The idea is similar in that a reputation mechanism, compris-
ing of several SCs, is implemented on top of Ethereum plat-
form so that clients can give feedback as ratings toward a Fog
node when using a service provided by such node. The rep-
utation of a fog node is simply accumulated on-chain from
users’ ratings. Being executed on-chain, such ratings and
reputation values are immutably recorded in a decentralised
fashion, thus ensuring data integrity as well as preventing
from Denial of Service (DDoS) attack.

We, instead, look at a different angle of trust in BC-based
applications in which a trust system plays a complementary
component of the BC platform that cooperates with DApps
to empower the ecosystem built on top of the platform. We
target to develop a trust system for decentralised services in a
BC ecosystem (e.g., Ethereum) in which participants (clients
and service providers) interact with each other on-chain in a
P2P manner. Our system plays as a unified trust solution
working with any DApps. Our previous research in [32] has
presented an introductory concept of a unified trust system
to strengthen a BC platform. However, it has come without
detailed analysis, algorithm, and technical solutions for the
development of the decentralised trust system. In this pa-
per, we further explore the concept and the feasibility of a
unified trust system as middleware between a BC platform
and DApps, as well as provide a proof-of-concept of the de-
centralised trust system along with the system design, algo-
rithms, technical solutions and implementation reference.
2.2. High-level architecture of BC-based

infrastructure and Trust System
For a better understanding of the big picture of the whole

BC-based infrastructure including the proposed trust system,
we represent the high-level architecture of a full-stack IoT in-
frastructure by harmonising these components to the IoT and
Smart Cities & Communities reference model3. As can be
seen in Fig. 2, the BC platform is located in the Service Sup-
port and Application Support layer, which is a layer between
the Application and Network layers in the IoT architecture.
DApps is located in the Application layer. Unlike client-
server applications and services whose reputation/trust sys-
tems are separately developed, we envisage that DApps in

3http://itu.int/en/ITU-T/studygroups/2017-2020/20/Pages/default.
aspx

the same ecosystem could leverage a universal trust system,
which serves as a fundamental service for the BC-based in-
frastructure (Fig. 2). This trust middleware exists because
DApps’ end-users in an ecosystem are identified by the same
IdM and a name registry, and use the same cryptocurrency
(e.g., provided by a BC platform) to consume the services.

Figure 2: Functional model of a BC-based infrastructure com-
prising of a trust system and other elements in alignment with
IoT high-level architecture.

2.3. High-level Architecture of Trust System
In this sub-section, fundamental elements of a decen-

tralised trust middleware between a BC platform and DApps
are described. As can be seen in Fig. 3, the proposed system
consists of two basic components named Data Collection
& Extraction and Trust Evaluation that collect and aggre-
gate necessary trust-related information and evaluate trust
relationships, respectively. These two components are along
withNorth-bound and South-boundAPIs for providing trust-
related services to DApps and for collecting data from a BC
or applications and services, respectively.
2.3.1. Trust Evaluation Mechanism

We adopt the REK trust model proposed in [31, 30] to
the DApps ecosystem scenario in which both trustors and
trustees are end-users of DApps. In the REK model, a trust
relationship is evaluated by assembling three indicators called
Reputation (of the trustee), Experience and Knowledge (of
the trustor toward the trustee). In DApps scenarios, there is
limited availability (or difficult to obtain) of off-chain infor-
mation (i.e., information that is recorded outside BC) of end-
users for evaluating Knowledge indicator as users’ identity
is normally pseudo-anonymised and challenging to link to
outside world [23]. Instead, transactions between end-users
are immutably recorded (and publicly available) on-chain,
which can be leveraged for Experience and Reputation eval-
uations. As a result, in this paper, we employ an adoption
of the REK trust evaluation model called DER which only
utilises two indicators Experience and Reputation in decen-
tralised environment. Details of the DER trust system is de-
scribed in the next section.

Generally, after each transaction between entities in a
Nguyen Truong et al.: Preprint submitted to Elsevier Page 3 of 14

http://itu.int/en/ITU-T/studygroups/2017-2020/20/Pages/default.aspx
http://itu.int/en/ITU-T/studygroups/2017-2020/20/Pages/default.aspx


Empowering Blockchain-based Decentralised Applications Ecosystem

Figure 3: Conceptual model of the proposed trust system

DApp, the trust system enables a participant to give feedback
toward its counterpart, thus establishing and updating the
Experience relationship between the two. By doing this, the
trust system maintains an Experience network among par-
ticipants, which is publicly recorded on-chain. This Experi-
ence network is autonomously updated whenever an entity
gives feedback to the other. Reputations of all participants
are then calculated accordingly, following the idea of Google
Rage-Rank algorithm. Finally, the trust value between two
entity is calculated as composition between Experience and
Reputation.
2.3.2. Data Collection and Extraction

By nature, a BC is a record of a continuous growing list
of transactions among end-users which can be analysed to
extract a network topology of end-user interactions. Nonethe-
less, further information about QoS is required to be col-
lected and aggregated in order for the DER trust evaluation
mechanism to be performed. Therefore, a decentralised feed-
back mechanism associated with DApps in a BC platform is
required to reflect QoS once end-users (e.g., service clients)
successfully carry out transactions with their counterparts
(e.g., DApp providers). Thismechanism creates a distributed
ledger that logs users’ feedback (toward a DApps service)
alongwith the information about associated transactions (e.g.,
end-user ID (from address), counterpart ID (to address),
and timestamp). Feedback can be either implicit or explicit
which may or may not require human participation [17]. The
trust system then extracts feedback and transactions informa-
tion recorded in BCs as inputs for the DER trust evaluation
model (i.e., calculate the Experience and Reputation indica-
tors) in order to evaluate trust relationships between any two
peers in the decentralised ecosystem.

3. System Design and DER Trust Model
3.1. Use-cases

For better explanation and clarification, we scrutinise the
decentralised data storage services (DDS), in regard to some
projects being developed and implemented in the real-world

like Storj4, Sia5, and Filecoin6 (built on top of the Inter-
Planetary File System7 (IPFS)). Decentralised storage is a
promising solution to cooperate or even to take over the con-
ventional centralised cloud storage where data is split into
multiple chunks and distributed to storage nodes across a
P2P network. These storage nodes, as DDS providers, are
expected to reliably store the data as well as provided reason-
able network bandwidth with appropriate responsiveness for
data owners to retrieve their data. As a reward, such storage
nodes are incentivised by crypto tokens. It is worth noting
that end-users in DApps ecosystem can be both data own-
ers (DDS clients) and storage nodes (DDS providers). The
decentralised storage concept is similar to the legacy P2P
file sharing such as BitTorrent8 but fortified with advanced
cryptography and encryption mechanisms as well as incen-
tive schemes built upon a BC platform. It is expected to solve
the long-standing challenges of single-point-of-control and
-failure in centralised data silos, and to bring essential con-
trol of data back to the owners whilst discharging full control
of cloud server managers.

Figure 4: Decentralised storage service built on top of a BC
platform that incentivizes storage nodes with crypto tokens.

The DDS deploys necessary SCs on top of a BC platform
to execute the business agreement between DDS clients (i.e.,
data owners) and DDS providers (i.e., storage nodes) such
as storage space and period, guaranteed performance (e.g.,
availability, throughput, bandwidth, and latency), and the
Incentive scheme (i.e., Token Reward) (Fig. 4). Unfortu-
nately, such SCs are unable to ensure the QoS of the DDS
service provided by a set of storage nodes because (i) it is im-
practical for the SCs to monitor and enforce the performance
of the DDS providers, and (ii) the guaranteed performance
can only be measured once the SCs are already invoked. In
this regard, a trust system that manages the performance his-
tory of the storage nodes and ranks them in order of trustwor-
thiness (to provide high QoS) is of paramount importance.

4https://storj.io
5https://sia.tech
6https://filecoin.io
7https://ipfs.io
8https://en.wikipedia.org/wiki/BitTorrent

Nguyen Truong et al.: Preprint submitted to Elsevier Page 4 of 14

https://storj.io
https://sia.tech
https://filecoin.io
https://ipfs.io
https://en.wikipedia.org/wiki/BitTorrent


Empowering Blockchain-based Decentralised Applications Ecosystem

Table 1
NOTATIONS USED IN THE EXPERIENCE MODEL
Notation Description
Expt Experience value at time t, Exp0 is the initial

value
minExp minimum Exp value, minExp = 0 if Exp is nor-

malised in [0,1]
maxExp maximum Exp value, maxExp = 1 if Exp is

normalised in [0,1]
#t Feedback score at time t
ďż˝ Maximum increase value of Exp in two consec-

utive transactions, 0 < ďż˝ < maxExp
ďż˝ Decrease rate, ďż˝ > 1
�co Cooperative threshold for a feedback score #t.

A feedback is cooperative if #t ≥ �co
�unco Uncooperative threshold for a feedback score

#t. A feedback is uncooperative if #t ≤ �unco
ďż˝ Minimum Decay value ensuring any Experience

relationship degenerates if it is not maintained

 Decay rate controlling the amount of the decay

3.2. DER Trust Model
In the proposed DER model, trust relationship between

two entities is a compound of two elements: Experience (of
the trustor toward the trustee) andReputation (of the trustee).
This section describes the mechanisms to calculate such two
elements.
3.2.1. Experience mechanism

Experience is an asymmetric relationship from an entity
to the another which is built up from previous transactions
between the two. Experience is an indicator of trust [31].
For instance, an experience (denoted as Exp(A,B)) is con-
stituted from a DDS client (i.e., a data owner, denoted as
A) to a DDS provider (i.e., a storage node, denoted as B)
once A invokes an SC to use the storage service offered by
B. HigherExp(A,B) value represents higher degree of trust
from A to B. Essentially, Exp(A,B) increases if B pro-
vides high-quality storage service to A (which is reflected
by a feedback score #t) and vice versa. It is worth noting
that feedback can be provided by either clients (e.g., A) or
an authorised third-party who is monitoring performance of
service providers (e.g.,B). Also,Exp(A,B) gets decay if no
transactions taken place after a period of time or a transac-
tion is neutral (i.e., neither cooperative nor uncooperative).
The amount of increase, decrease and decay depends on in-
tensity of transactions, feedback scores #, and the current
value of Exp(A,B) which can be modelled by linear differ-
ence equations and a decay function as follows (notations are
denoted in Table 1) [31, 30]:

• Increase model

The current Exp(A,B) (denoted as Expt−1) increases whenthere occurs a cooperative transaction (at the time t, indi-
cated by the feedback score #t ≥ �co) that follows the linear

difference equation:

Expt = Expt−1 + #tΔExpt (1)
where ΔExpt is defined as follows:

ΔExpt = �(1 −
Expt−1
maxExp

) (2)

• Decrease model

Similarly, Exp(A,B) decreases if the transaction is uncoop-
erative (indicated by the feedback score #t ≤ �unco), follow-ing the equation:

Expt =Max(minExp, Expt−1 − �(1 − #t)ΔExpt) (3)
in which ΔExpt is specified in Equation (2). The decrease
rate ďż˝ > 1 implies that it is easier to lose the Exp(A,B)
value due to an uncooperative transaction than to gain it (by
a cooperative transaction).

• Decay model

Exp(A,B) decays if there is no transaction after a period
of time or a feedback is neutral (i.e., �unco < # < �co)and the decay rate is assumed to be inversely proportional to
the strength of the experience relationship (i.e., Expt value)[27]. Based on these observations, the Decay model is pro-
posed as follows:

Expt =Max(minExp, Expt−1 − ΔDecayt) (4)

ΔDecayt = �(1 + 
 −
Expt−2
maxExp

) (5)

3.2.2. Reputation mechanism
The reputation of an entity represents the overall percep-

tion of a community regarding the characteristic of the en-
tity such as trustworthiness. In the DApps ecosystem, the
reputation of an end-userU (denoted asRep(U )) can be cal-
culated by aggregating Exp(i, U ), ∀i are users who have al-
ready been transacted with U . To calculate the reputation of
end-users, we utilise the model proposed in [31, 30] which is
based on the standard PageRank [7] and theweighted PageR-
ank [35, 33].

LetN be the number of end-users in the DApps ecosys-
tem, an directed graph G(V ,E) is constructed in which V
is a set of N users, E ⊆ {(x, y)|(x, y) ∈ V 2 ∧ x ≠ y} is
set of edges representing experience relationship E(x, y) =
Exp(x, y). If there is no prior transaction between (x, y);
E(x, y) = 0. To enable the reputation model, G(V ,E) is di-
vided into two sub-graphs: positive experience PG(V , PE)
in which any edgePE(x, y) = Exp(x, y) satisfyingExp(x, y) >
ďż˝ and negative experience NG(V ,NE) in which any edge
NE(x, y) = Exp(x, y) satisfying Exp(x, y) < ďż˝, where ďż˝
is a predefined threshold. d parameter is a damping factor
(0 < d < 1) introduced in standard PageRank [7]. The rep-
utation for each sub-graph is then calculated as follows:

Nguyen Truong et al.: Preprint submitted to Elsevier Page 5 of 14



Empowering Blockchain-based Decentralised Applications Ecosystem

• Positive Reputation

RepPos(U ) =
1 − d
N

+d(
∑

∀i
RepPos(i)×

PE(i, U )
CPos(i)

) (6)

in which CPos(i) = ∑

∀j PE(i, j) representing the sum of all
positive experience values that the end-user i holds (toward
other end-users).

• Negative Reputation

RepNeg(U ) =
1 − d
N

+d(
∑

∀i
RepNeg(i)×

1 −NE(i, U )
CNeg(i)

)

(7)
inwhichCNeg(i) = ∑

∀j (1 −NE(i, j)) representing the sumof all complements of negative experience values (i.e., 1 −
NE(i, j)) that the end-user i holds (toward other end-users).

• Overall Reputation

Rep(U ) is the aggregation of RepPos(U ) and RepNeg(U ):
Rep(U ) = max(0, RepPos(U ) − RepNeg(U )) (8)

3.2.3. Trust Aggregation
Trust relationship between trustor A and trustee B is a

composite of Exp(A,B) and Rep(B):

T rust(A,B) = w1Rep(B) +w2Exp(A,B) (9)
in which w1 and w2 are weighting factors satisfying w1 +
w2 = 1. It is worth noting that any end-user once signing up
for a DApp is assigned a default value at bootstrap (e.g., 1N ).
IfA andB have no prior transaction thenExp(A,B) = 0. In
this case,w1 = 1 andw2 = 0; thus, T rust(A,B) = Rep(B).

4. Trust Model: Evaluation and Simulation
This section provides detailed evaluation of theDER trust

model including model equations analysis, algorithms, and
simulation of the Experience and Reputation models.
4.1. Experience Model
4.1.1. Analysis

For simplicity, Exp values and feedback score # are nor-
malised to the range (0, 1) with maxExp = 1, minExp = 0
and the initial value 0 < Exp0 < 1.
Lemma 4.1. The Increase model defined in Equation 1 is
(*) a monotonically increasing function and (**) asymptotic
to 1.

Proof. From Equation 1 and 2, with maxExp = 1, we have:
Expt = Expt−1 + (1 − Expt−1)#t � (10)

Subtracting both sides of Equation 10 from 1:
1 − Expt = 1 − (Expt−1 + (1 − Expt−1)#t �)

= (1 − Expt−1)(1 − #t �)
= (1 − Expt−2)(1 − #t �)(1 − #t−1 �)
= ...

= (1 − Exp0)
t

∏

i=1
(1 − #i �) (11)

As 0 < Exp0 < 1, 0 < ďż˝ < maxExp = 1, and 0 <
#i < 1 ∀i; from Equation 11 we have 0 < Expt < 1 ∀t.
Therefore,Expt function defined in Equation 1 is increasingas the increment value between Expt and Expt−1 is #t ×
ΔExpt where ΔExpt = �(1−Expt−1) > 0. Hence, Lemma
(*) is proven.

Furthermore, as Increase model is for cooperative trans-
actions, meaning that #i ≥ �co; ∀i ∈ {1, .., t}; from Equation
11 we have:

0 < 1 − Expt ≤ (1 − Exp0)(1 − �co �)t (12)
As �co, �, andExp0 are the three pre-defined parameters

in the range (0, 1); therefore:
lim
t→∞

(1 − Exp0)(1 − �co �)t = 0 (13)

Applying the Squeeze theorem on (12) and (13), we then
have:

lim
t→∞

(1 − Expt) = 0 (14)

In other word, the monotonically increasing Expt func-tion is asymptotic to 1; hence Lemma (**) is proven.
As the Increase model is monotonically increasing, it

is obvious that the Decrease model defined in Equation 3,
which is based on ΔExpt in Equation 2, is decreasing. The
decrements depend on the current Expt value and the unco-operative #t feedback score. The decrease rate ďż˝ depicts the
ratio of the decrements compared to the increments, which
is normally greater than 1 as the current experience Expt is
“difficult to gain but easy to loose”.

The Decay model defined in Equation 4 ensures that an
experience relationship gets weakened if there is no or neu-
tral transactions after a period of time. This is because the
decay value ΔDecayt specified in Equation 5 is always > 0
as 0 < Expt−2 < 1 ∀t ≥ 2; and it is inversely proportional
toExpt−2, implying that a strong relationship persists longer
than a weak one.
4.1.2. Algorithm and Simulation

Based on the Experience model defined in Section 3.2.1
along with the analysis, the algorithm calculates experience
valueExp(A,B) of entityA toward entityB is demonstrated
in mathematical-style pseudo-code as in Algorithm 1. It is
worth noting that the parameters controlling the Experience
model are preset for our demonstration and should be opti-
mised for specific scenarios.

For demonstration purposes, the algorithm is implemented
inMatlabwith different controlling parameters settings. As

Nguyen Truong et al.: Preprint submitted to Elsevier Page 6 of 14



Empowering Blockchain-based Decentralised Applications Ecosystem

Alg. 1: Experience Calculation Algorithm
Input : Current experience value Expt−1Previous experience value Expt−2Feedback score #t
Output: Updated experience value Expt

1 Parameters Preset
2 Exp0 = 0.5; ⊳ In case there is no prior transaction,

Expt−1 and Expt−1 are set to Exp0;
3 minExp = 0; maxExp = 1; ⊳ Experience value is

normalised in the range [0,1];
4 �co = 0.7; �unco = 0.5;
5 ďż˝ = 0.05; ďż˝ = 1.6;
6 ďż˝ = 0.005; 
 = 0.005
7 Begin
8 if #t ≥ �co then
9 ⊳ Increase Model;
10 Expt = Expt−1 + #t�(1 −

Expt−1
maxExp

)

11 else if 0 < #t ≤ �unco then
12 ⊳ Decrease Model;
13 Expt =Max(minExp, Expt−1−�(1−#t)�(1−

Expt−1
maxExp

)

14 else
15 ⊳ No transaction (#t = 0) or neutral �unco < #t < �co
16 ⊳ Decay Model;
17 Expt =Max(Exp0, Expt−1 − �(1 + 
 −

Expt−2
maxExp

)

18 Return Expt

Figure 5: Increase, Decrease, and Decay in Experience rela-
tionship

depicted in Fig. 5, two sets of parameters configuration are
taken into account in which the maximum increase value ďż˝ is
either 0.05 or 0.1, the decrease rate ďż˝ is either 1.6 or 4.0, and
the parameter pair for the decay model (ďż˝, 
) is either (0.005,
0.005) or (0.01, 0.01). The initial value is presetExp0 = 0.5.As can be seen in Fig. 5, the results show that both increase
model curves are asymptotic to 1, which is already proven
in the theoretical analysis, at different rates depending on
the controlling parameter ďż˝. The results also indicate that
stronger experience relationships require more cooperative
transactions to achieve. For instance, wi";"""date"",""2021-01-27T02:16:55Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""A Blockchain-based Trust System for Decentralised Applications: When trustless needs trust""
""xmp:CreatorTool"",""LaTeX3; cas-sc.cls; hyperref.sty""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX3; cas-sc.cls; hyperref.sty""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""A Blockchain-based Trust System for Decentralised Applications: When trustless needs trust""
""modified"",""2021-01-27T02:16:55Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.21 (TeX Live 2020) kpathsea version 6.3.2""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2021-01-27T02:16:55Z""
""created"",""2021-01-27T02:16:55Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2021-01-27T02:16:55Z""
""resourceName"",""2101.10920""
""Author"",""""
""producer"",""pdfTeX;""
""pdf:docinfo:producer"",""pdfTeX;""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""7"",""52"",""16"",""15"",""362"",""385"",""332"",""580"",""132"",""83"",""45"",""2"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2021-01-27T02:16:55Z""
""Last-Modified"",""2021-01-27T02:16:55Z""
""dcterms:modified"",""2021-01-27T02:16:55Z""
""title"",""A Blockchain-based Trust System for Decentralised Applications: When trustless needs trust""
""Last-Save-Date"",""2021-01-27T02:16:55Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2021-01-27T02:16:55Z""
""meta:save-date"",""2021-01-27T02:16:55Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.21 (TeX Live 2020) kpathsea version 6.3.2""
""Content-Length"",""16983870""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""15""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""531"",""4732"",""4349"",""4748"",""3800"",""3939"",""3367"",""3277"",""3658"",""3729"",""4807"",""4558"",""4606"",""6485"",""3329""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2021-01-27T02:16:55Z""
";https://scholar.google.ch/scholar?start=80&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2021
1619099142-489;https://scholar.google.ch/scholar?as_ylo=2021&q=oracles+blockchain&hl=fr&as_sdt=0,5;Managing change with and through blockchain in accountancy organizations: a systematic literature review;A Tiron;Tudor, D Deliu, N Farcane…  Journal of Organizational …, 2021  emerald.com;;"Managing change with and through blockchain in accountancy organizations: a systematic

literature review - Author: Adriana Tiron-Tudor, Delia Deliu, Nicoleta Farcane, Adelina Dontu.";Les 2 versions;;[PDF] researchgate.net;https://www.researchgate.net/profile/Adriana-Tiron-Tudor/publication/349028401_Managing_change_with_and_through_blockchain_in_accountancy_organizations_a_systematic_literature_review/links/602d893992851c4ed57bf229/Managing-change-with-and-through-blockchain-in-accountancy-organizations-a-systematic-literature-review.pdf;;;https://scholar.google.ch/scholar?start=80&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2021
1619099133-473;https://scholar.google.ch/scholar?as_ylo=2021&q=oracles+blockchain&hl=fr&as_sdt=0,5;An efficient identity tracing scheme for blockchain-based systems;P Li, H Xu, T Ma ; Information Sciences, 2021  Elsevier;;"… The bitcoin paid by the victims have been exchanged by Monero which is an

anonymous cryptocurrency system which is hard to trace [17] … Thus, it is important

to consider the supervision problem for blockchain-based systems …";Les 2 versions;;null;;;;https://scholar.google.ch/scholar?start=60&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2021
1619099115-437;https://scholar.google.ch/scholar?as_ylo=2021&q=oracles+blockchain&hl=fr&as_sdt=0,5;Unchaining Collective Intelligence for Science, Research and Technology Development by Blockchain-Boosted Community Participation;J Ducrée, M Etzrodt, S Bartling, R Walshe… ; … in Blockchain, 2021  ueaeprints.uea.ac.uk;;"… or even forgery, and would thus devastatingly undermine trust in blockchain controlled processes …

reporters” is thus instrumental for the implementation and acceptance of oracle-based smart … There

are different types of oracles [72]: Software and hardware oracles receive data …";Les 2 versions;Version HTML;[PDF] uea.ac.uk;https://ueaeprints.uea.ac.uk/id/eprint/79126/1/FBloc_2021_Ducr_e_et_al_Authors_accepted_version.pdf;"
 

1 
 

Unchaining Collective Intelligence for 
Science, Research and Technology 
Development by Blockchain-Boosted 
Community Participation 
Jens DucrĂŠe1, 2, SĂśnke Bartling3, Ray Walshe4, TomĂĄs Harrington5, Neslihan Wittek6, 
Sebastian Posth7, Kevin Wittek8, Andrei Ionita9, Wolfgang Prinz9,10, Dimitrios Kogias11, 
Tiago PaixĂŁo12, Iosif Peterfi13, James Lawton13 

1School of Physical Sciences, Dublin City University, Glasnevin, Dublin 9, Ireland 
2Akasha Foundation, Zug, Switzerland 
3Blockchain for Science GmbH, Berlin, Paul-Lincke-Ufer 8c, 10999 Berlin Germany 
4School of Computing, Dublin City University, Glasnevin, Dublin 9, Ireland 
5Innovation, Technology & Operations Management Group, Norwich Business School, Faculty of Social Sciences, University of East Anglia, UK 
6Faculty of Psychology, Department of Biopsychology, Ruhr University Bochum, Germany 
7Posth Werk BV, Boerhaavelaan 99, NL 2334 EG Leiden, The Netherlands 
8Institute for Internet Security, Westphalian University of Applied Sciences, Neidenburger Straße 43, 45897 Gelsenkirchen, Germany 
9Fraunhofer Institute for Applied Information Technology (FIT), Schloss Birlinghoven, Konrad-Adenauer-Straße, 53754 Sankt Augustin, Germany 
10Faculty of Electrical Engineering and Information Technology, RWTH Aachen, Mies-van-der-Rohe-Str. 15, 52074 Aachen, Germany 
11Department of Electrical & Electronics Engineering, University of West Attica, Egaleo, Greece 
12Instituto Gulbenkian de CiĂŞncia, Rua da Quinta Grande 6, 2780-156 Oeiras, Portugal 
13Max Planck Digital Library (MPDL), Max Planck Society, Amalienstr. 33, 80799 MĂźnchen, Germany  

Corresponding author: Jens DucrĂŠe (e-mail: jens.ducree@dcu.ie). 

ABSTRACT 
Since its launch just over a decade ago by the cryptocurrency Bitcoin, the distributed ledger technology 
(DLT) blockchain has followed a breathtaking trajectory into manifold application spaces. This paper 
analyses how key factors underpinning the success of this ground-breaking “internet of value” technology, 
such as staking of collateral (“skin in the game”), competitive crowdsourcing, crowdfunding, and 
prediction markets, can be applied to substantially innovate the legacy organization of science, research and 
technology development (RTD). 

Here, we elaborate a highly integrative, community-based strategy where a token-based crypto-economy 
supports finding best possible consensus, trust and truth through adding unconventional elements known 
from reputation systems, betting, secondary markets and social networking. These tokens support the 
holder’s formalized reputation, and are used in liquid-democracy style governance and arbitration within 
projects or community-driven initiatives. This participatory research model serves as a solid basis for 
comprehensively leveraging collective intelligence by effectively incentivizing contributions from the 
crowd, such as intellectual property (IP), work, validation, assessment, infrastructure, education, 
assessment, governance, publication, and promotion of projects. On the analogy of its current blockbusters 
like peer-to-peer structured decentralized finance (“DeFi”), blockchain technology can seminally enhance 
the efficiency of science and RTD initiatives, even permitting to fully stage operations as a chiefless 
Decentralised Autonomous Organization (DAOs). 

INDEX TERMS 

blockchain, distributed ledger technology, science, research, token economy, cryptoeconomy, consensus, 
reputation systems, liquid democracy, participatory research, collective intelligence, wisdom of the crowd, 
decentralization

1 INTRODUCTION 
From a bigger perspective, science, research and technology development (RTD) pursue the overarching goal 
of generating beneficial knowledge that aims to contribute to the good of mankind. Basic science is driven by 
the quest for learning and understanding as a core trait of human nature; often pursuing commercial 



 

2 
 

objectives, technology improves the quality of our lives, e.g., in terms of addressing fundamental needs in 
food, health and education, or providing convenience such as water, energy, transportation, automation, 
communication and entertainment. 

While, at least in the public eye, major breakthroughs are often linked to a single person, practically all 
historical achievements in science and RTD are deeply rooted in the foundational work of a community which 
produced the fundamental research as well as enabling methods, equipment, and infrastructure within a 
supporting culture and, last but not least, a pool of highly qualified and motivated talent stimulating 
productivity within a competitive environment. 

Generation of basic knowledge is presently, for the most part, sponsored by governmental organisations and 
foundations to address health, economic, scientific, societal, ethical, and environmental topics and issues, to 
boost prestige through high-impact publicity, or by businesses to gain a competitive edge for eventually 
enhancing their profits. Involvement of individuals in such initiatives may be motivated by a variety of 
objectives, ranging from career opportunity, reputation, social recognition, creativity, altruism and monetary 
rewards. 

Recent decades have seen a strong trend towards globalization that has been enabled by sophisticated 
networks of logistics and highly intertwined global supply chains which are meticulously coordinated by 
transnationally operating information and communication technology (ICT). With the wide-scale penetration 
of internet, ensued by the availability of cloud computing and artificial intelligence (AI), possibly accessed by 
science as a service models [1], and 5G networks for real-time applications, even in remote and economically 
disadvantaged locations, access to and creation of knowledge has already reached historically unprecedented 
levels. 

The recent past has also seen game-changing advances in ubiquitous / additive manufacturing (UM / AM), 
primarily by 3D printing [2], or open-source platforms, e.g., in software [3], electronics [4] and microsystems 
[5], virtualisation, for instance, through “digital twins” [6], open-access facilities for prototyping, 
characterization and application development [7-11] and data on demand [12]. The wide-scale availability of 
these novel resources will progressively empower individuals from the crowd, such as the “citizen scientist” 
[13, 14] or “garage entrepreneur”, to create, customize or sell many digital and physical goods from and to 
practically anywhere. In addition, the emergence of redistributed manufacture (RDM) echoes that production 
is becoming increasingly decentralised, e.g., even in the highly regulated pharmaceutical industry [15, 16] and 
aerospace [17]. 

Open science and community-based participatory research (CBPR) for socio-environmental issues is another 
area of focus [18]. Here, discovering and sharing goals that actors with different interests could tackle together 
(a ‘transcend’ method), in addition to ethical equity, fair access to data, and dialog, represent essential 
components. The constructive interplay of these strong trends set the path for a democratization of an 
inclusive science and RTD landscape where a wide range of actors, whether institutions or freelancers [19-
21], can decisively contribute and receive their fair share in value creation. 

CBPR has been regarded as the gold standard for equitable and partnered research in traditional communities 
[22]. In capturing the collaborative process between community-based organizations and academic 
investigators, CBPR models have demonstrated the potential to make research more responsive to existing 
needs, and to improve a community’s ability to address a range of common issues [23]. Such CBPR 
approaches can be enhanced by token systems  (“tokenisation”) which, on the one hand, crypto-economically 
incentivize efficient crowdsourcing of collective intelligence [24, 25], while, on the other hand, requesting 
cryptoassets as collateral (“skin in the game”) to assure good quality of contributions. 

This way such blockchain-based crypto-economical tools, possibly in tandem with the aforementioned CBPR, 
can also be key to address the notorious reproducibility crisis of science [26, 27]. The pervasive failure to 
replicate previous findings often roots in inappropriate practices of science, e.g., poor experimental design 
leading, almost unavoidably, to variability between the groups [28], hypothesizing after the results are known 
(“HARKing”) [29, 30], selective analysis and reporting [31-33], p-value hacking [34, 35], and missing raw 
data [36, 37]. Freedman et al. [38] demonstrated that in the United States, the high rate of irreproducibility, 



 

3 
 

estimated at 50% in preclinical research, induced high economical loss of approximately US$28 billion per 
annum. In addition to waste of money and time, the poor reproducibility of data tends to markedly demotivate 
the idealistic scientific community. 

 

Figure 1 Buzz words in science and RTD which directly connect to equivalent 
elements in blockchain technology. The central objective is to create blocks of trust- 
and truthful knowledge / innovation and log them a public or permissioned ledger. 
Credibility of contributions is rewarded and staked by work efforts and reputation. 
Ownership and confidentiality of results depend on the source of funding, and may 
be kept as corporate secret or made public. The construct is framed by mechanisms 
to assure quality and credibility of results on the left, and involvement of the 
community on the right-hand side. 

Furthermore, the recent shift towards open access in scientific publishing, even though widely regarded as 
worthwhile and necessary, has led to detrimental side effects; driven by profit, a slew of open access journals 
publish quasi any submission, since the costs have entirely shifted from the readers or subscribing libraries to 
the authors. This unintentional, very counterproductive development has led to a noticeable rise of such rather 
predatory journals with substandard editorial boards, peer reviewers and papers, and even to the loss of parts 
of the scientific record when their entirely profit focused publishing houses suddenly dissolve. This severe 
problem could well be addressed by increased transparency of the peer review system, as well as a robust 
identity and reputation systems of both authors, reviewers and journals, all of which can be successfully 
addressed by blockchain technologies, as described below. 

This paper proposes a radically novel decentralized concept utilizing blockchain mechanisms based on 
reputation systems, betting, secondary markets and social networking to deliver well-qualified consensus for 
(best possible) “truth” (as validated according to commonly accepted scientific procedures) on delivery and 
assessment of plans, work and forecasts, to eventually amend “blocks” of scientifically or commercially 
valuable artefacts, knowledge or know-how to the public or corporate ledger of science & RTD, respectively. 
Figure 1 lists critical modules science & RTD that can be mapped to blockchain technology to seminally 



 

4 
 

update the way science and RTD have been organized over the last centuries, to ultimately confer optimum 
benefit to people, societies, and economies. 

 

2 BLOCKCHAIN 
Beyond its foundation in computer science, cryptography and finance, blockchain technology is not 
monolithic; its sophistication and application development now involve concepts from a wide range of 
disciplines encompassing economics, game theory, banking, risk management, data science, education, law, 
administration, political science, psychology, ethics, arts and social sciences. While gaining a thorough 
understanding of blockchain tends to be somewhat challenging, its diverse contributions bear strong potential 
to produce disruptive ideas, concepts and solutions that continuously drive the evolution of the overarching 
technology. In the following sections we provide an insight into the different facets of this Distributed Ledger 
Technology (DLT) [39] to then lay the ground for substantially improving legacy organization and processes 
in science and RTD. 

2.1 A.  DIGITAL CURRENCY 
Blockchain originates from a white paper, authored by the pseudonymous person or group “Satoshi 
Nakamoto”, which launched the virtual currency “Bitcoin” in 2008/2009 [40-43]. By employing a 
computational “proof-of work” (PoW) in conjunction with incentivization for honest participation, this 
document described the world’s first realization of a peer-to-peer version of electronic cash that offers 
algorithm-enforced scarcity, solves the double-spending problem of digital assets, and allows online payments 
to be sent directly from one party to another without going through a financial institution.  

Integrity and consensus on amending new “blocks” is achieved through a clever combination of cryptography 
and a decentralised peer-to-peer network of miners to validate and nodes to store a common, tamper-free, 
immutable, and time-stamped distributed ledger (file). The protocol runs without intermediaries, e.g., a central 
bank, whose monetary policies may be directed by short-term political objectives of the ruling administration, 
rather than protecting the interest of people, especially depositors, against inflation1 and devaluation; uniquely, 
no physical goods such as bills, coins or precious metals are issued, stored, split, or transported, thus 
drastically reducing cost of ownership, security, and usage. 

Bitcoin and many other cryptocurrencies may be traded on conventional or decentralised exchanges (“DEX”), 
“hodled” [44], i.e., held on the long term (“hodled”) in the prospect of large future profit or increased utility, 
saved to protect wealth against inflation or for longer-term gains in on- or off-chain wallets or vaults, or used 
to buy real-world goods and to access services with an expanding number of merchants [45]. By the time of 
writing, Bitcoin has reached a market far above 200 billion USD, thus being ranked the world’s 6th largest 
currency (depending on the referenced category of money supply). It is followed by Ethereum (ETH) [46, 47], 
the global payment network Ripple (XRP) [48] with about 45 and 13.2 billion US$, respectively, and a host of 
further, often special purpose, “altcoins”. 

2.2 COMPUTING POWER 
Trust in Bitcoin is established through demanding PoW, i.e., staking huge computational power in a race to 
unravel a cryptographic “puzzle” (or, more accurately, by finding a partial hash collision through brute force), 
which nowadays requires designated, application-specific integrated circuits (ASICs) that frequently 
concentrate at larger-scale mining “farms”. Blockchains are commonly designed to be “Byzantine Fault 
tolerant” (BFT) [49], i.e., only an entity able to control a significant fraction (arguably specified between 1/3 
to 51% under real-world circumstances) of the so-called “hash rate” (or alternative resource) would have a 
realistic chance to manipulate and thus devastatingly compromise trust in the blockchain; such attacks are 
efficiently counteracted by attractive rewards for mining or staking. It is widely accepted that only seminal 

 

1 This philosophy is also carved into Bitcoin’s genesis block stating ""The Times 03/Jan/2009 Chancellor on 
brink of second bailout for banks."" issued in the middle of the 2008-2009 financial crisis. 



 

5 
 

enhancements of hash rates, e.g., by next-generation quantum computing, might pose a serious challenge to 
securing blockchains (more precisely: public PoW based chains that work on hash-collision based cost-
functions) in the longer-term future.   

2.3 PROGRAMMABLE MONEY 
Another milestone flanking the emergence of blockchain technology was the introduction of “smart contracts” 
which allowed the development of decentralised apps (“DApps”) that are equipped with a locally running user 
interface (UI), with the business logic executed in a decentralised fashion, e.g., on the Ethereum Virtual 
Machine (EVM) as part of a network [50]. In this “Web 3.0”2 technology launched in 2014, the execution of 
transactions on assets can be coupled to conditions represented by code that is permanently engraved and 
verified on the blockchain. Such programmability of a trusted digital currency has given DLT another 
tremendous, at times somewhat overhyped boost in the second half of the 2010s, in particular in the field of 
decentralised finance (“DeFi”) [51], which is presently spurred by hot topics like “yield farming” / “liquidity 
mining” [52-58].  

High volatility of exchange rates with fiat currencies has been addressed by stablecoins, often soft- or hard-
pegged against the US dollar [59-61]. Some companies insure against adverse events [62, 63] and 
professionally audit smart-contract constructs [64]. However, enforcement of severe regulation, e.g., around 
know-your-customer (KYC) and anti-money-laundering (“AML”) compliance policies [65] required in 
conventional financial services, is still regarded as major roadblocks for further, land-slide proliferation; while 
there is significant support for introduction of “crypto” from the corporate sector and important interest 
groups, increasing support is signaled from government agencies who would need to legally sanction certain 
steps and support integration with their work flows [66-71]. Alternative public blockchain-enabled 
cryptoassets like Bitcoin, numerous countries are seriously contemplating the introduction of Central Bank 
Digital Currencies (CBDCs). 

2.4 ORACLES 
Smart contracts may be deemed blockchain-based algorithms that deterministically trigger transactions, for 
instance, of cryptocurrencies, upon meeting well-defined conditionals on external input data, referred to as 
“oracles”. Blockchains themselves provide trust on information that can be sourced from its very own digital 
ecosystem, e.g., that a certain date has passed, or a certain amount of funds is available on a given crypto 
account. However, any real-world data feeds, e.g., on stock values, exchange rates, opinion polls or data 
obtained from the Internet of Things (IoT), to on-chain decision-making algorithms constitute potential chinks 
caused by poor quality or even forgery, and would thus devastatingly undermine trust in blockchain controlled 
processes. Access to reliable off-chain facts by properly vetted and incentivized “reporters” is thus 
instrumental for the implementation and acceptance of oracle-based smart contracts controlling transactions of 
value. 

There are different types of oracles [72]: Software and hardware oracles receive data from online sources, and 
real-world information from physical sensors, respectively. In inbound and outbound oracles, digital 
information is fed to or issued from the blockchain. Consensus-based oracles rely on verification and approval 
by a cohort of individuals or groups. A range of initiatives already provide various forms of such blockchain-
connected oracles [73-80]. Especially consensus-based oracles play an important role in this paper as they best 
reflect the well-proven trust-finding process already underpinning science and RTD. 
2.5 PREDICTION MARKETS 
Uncertainty on future events and developments remains a fundamental issue in our lives, economies, and 
societies. Examples are weather, climate, natural or manmade disasters, conflicts, health, election results, 
consumer behaviour, financial markets and economic growth from a macroscopic and corporate angle as well 
as advancements in science and technology. Undoubtedly, there is a huge value in having prior knowledge 
about upcoming events, e.g., to advise allocation of resources or to pre-emptively mitigate their expected 

 

2 Note that there various conflicting definitions exist for the terms “Web3” or “Web 3.0”. 



 

6 
 

fallout. Organisations like insurers, investors, governments, and companies rely on thorough data collection 
and analysis to have the best possible appraisal. 

While small panels of pundits may be consulted for their insights, the collective wisdom of the crowds [81-83] 
has often delivered an astonishingly reliable source for predicting the future events, e.g., the outbreak of 
pandemics [84, 85], possibly because a broad population provides a multitude of information, perspectives 
and experiences to average out individual bias. However, it is also reasonable to put higher weight on 
forecasts uttered by specialists displaying a thoroughly verified “reputation”, i.e., a proven track record, 
untarnished credibility and relevant expertise in the area under consideration for optimizing the accuracy. For 
example, artificial intelligence (AI) supported DeFi platforms have been launched, involving reputation-
staked collective intelligence of investors from the crowd to direct an open hedge fund [86]. 

Its combination of smart contract and trust without intermediaries has been a fertile ground to install several 
prediction markets on blockchains [87-92]; these next-generation platforms allow “anyone”, including 
automated market makers (AMMs), to create trade pairs and settle their “bets” at different stages prior to the 
completion of the event. As any crypto exchange, attracting sufficient liquidity is paramount for the viability 
of these platforms. 

Evidently, precise definition of possible outcomes constitutes a critical prerequisite for setting up and settling 
the market. There are outcomes that are of binary, i.e., yes-no nature, or that can be expressed in exact 
numbers. Yet, even those events may fall out of a set list of outcomes, e.g., by cancellation or changing of 
goal posts due to unforeseeable force majeure. This may be handled by declaring the bet invalid followed by 
returning deposits to all stakeholders. 

However, even such a decision may be disputable, possibly favoring certain stakeholders while leaving some 
betters feeling betrayed. In this case trust in the platform is enhanced by providing a pre-defined and fair 
arbitration process [93-95]. Such consensus finding by broadly accepted dispute resolution schemes will also 
be required for judging on more complex outcomes, e.g., if a “soft” scientific or business goal cannot be 
expressed in a simple quantitative measure. 

The main vulnerability of these blockchain-based betting portals resides in the accountability of oracles 
reporting on real-world data, i.e., they may accidently, erroneously or deliberately feed inaccurate or untimely 
information which prompt irreversible “pay outs” linked to unstoppable smart contracts. Blockchain based 
prediction markets consequently need to put particular emphasis on trustful input sources; for assuring 
credibility or “best possible trust”, staking “skin in the game” as collateral thus needs to be demanded from 
reporters, e.g., by appropriate (crypto-)assets or formalized reputation, while penalizing deviation from the 
final consensus. Mechanisms for establishing trustful oracles have been developed, e.g., in the context of IoT 
[96]. 
2.6 CURATION MARKETS 
Also in response to adverse crosswinds by regulatory agencies challenging the legitimacy of initial coin 
offerings (ICOs), so-called “token bonding curves” (TBCs) [97] have been devised to implement legally less 
controversial idea markets [98]. Tokens may be purchased and traded for proposals and ongoing projects; 
staked crypto deposits are safely stored on the blockchain to guarantee continuous liquidity. Their value is 
defined by a publicly accessible formula, for instance, with a price proportional to the number of tokens issued 
at a given point in time; in this exemplary model, investors in these curation markets [99] thus profit when 
more tokens circulate at the point of selling than at buying. Similar to conventional betting, stockbrokers or 
currency exchanges, a fraction of the revenues may be commissioned in a well-defined fashion to fund the 
project activities, and to support the creation of trustful prediction markets that can wisely inform decision 
making. 

To avoid Ponzi schemes, rules must be established for an end game when the project has reached its 
milestones, e.g., delivered commercially, for the conversion of virtual token investments into real-world value. 
As direct pecuniary remuneration may raise the ire of federal authorities who might categorize them as 
securities to which rather tight regulation would apply to, tokens might be converted into formalized 
reputation or voting rights in community-driven initiatives seeking related expertise. 

2.7 INCENTIVIZATION OF CONTRIBUTORS 



 

7 
 

The success of community-based approaches involving collective intelligence is intimately hinged on 
engagement of a critical mass of participants. The same applies to blockchain technologies themselves which 
can only thrive if a substantial number of active users and providers of independent nodes perform mining, 
maintenance, and upgrades to sustain the network. 

A variety schemes have been applied to stimulate employee participation in traditional companies; 
interestingly, it turns out that accompanying recognition and acknowledgement of quality work has a stronger 
long-term effect on employee motivation and performance than (stand-alone) bonuses and pay rises [100]. 
Incentivization or collaboration by blockchain-secured token systems has already been implemented by 
several big corporations. For instance, the Enterprise Ethereum Alliance (EEA) [101], backed by 
multinationals like Microsoft and Intel, issues reward and reputation tokens to stimulate collaboration on 
activities like editing and contributing to specifications, and adding code in software development. Penalty 
tokens may reflect lack of engagement or infringement of project delivery within target budgets, timelines and 
specifications. Spotting bugs and other flaws might be incentivized by posting bounties [102, 103], which may 
also be open to the public and may be rewarded through centralized or decentralized decision making 
mechanisms. 

2.8 TOKENIZATION OF ASSETS 
The ownership of certain unique assets such as real estate, vehicles, memorabilia, antiques, artwork [104-106] 
and other intellectual property (IP) representing intangible creations of human creativity [107] is normally 
handled by publicly sanctioned administrative entities, e.g., land registries or patent and trademark offices. 
Traditionally, the final proof of ownership is still linked to the possession or filing of a paper document that 
needs to be managed, transferred, archived, and kept accessible in a manner that is highly resilient to forgery, 
theft, disasters and physical decay over long, even historic periods of time. 

As opposed to money or commodities like precious metals or natural resources, this specific class of goods is 
not directly interchangeable, i.e., title of such assets may need to be swapped, e.g., through cumbersome 
escrow and distribution mechanisms. For instance, the deeds of a house might not be divided in as straight-
forwardly as 100 units of a fiat currency might be split into several bills or coins that can be passed out to 
individuals. Also, a trustful, uninterrupted record of previous ownership, ideally tracing back to the origin, 
minimizes chances of legal disputes and counterfeit, and thus constitutes a high value. 

The enormous potential of the distributed, unstoppable, time-stamped, cryptographically secured and thus 
inviolable public ledger to document non-repudiable ownership of this type of non-interchangeable assets in 
an “internet of value” is very evident. So-called “Non-Fungible Tokens” (NFTs, known as ERC-721 tokens 
[108] on the Ethereum blockchain) have been implemented on blockchains [109, 110]. These NFTs have first 
been utilized for trading unique digital artwork as part of online gaming [111]; by now, several blockchain 
initiatives have extended the concept of NFTs to real-world assets [106, 112-115] through digital security 
tokens. 

Other projects also target recording and providing selective access to well-verified professional and 
educational qualifications on designated blockchains [116], e.g., to facilitate admission to academic programs, 
for streamlining corporate recruitment and for optimizing human resources (HR) [117]. 

2.9 FUNDING 
In addition to conventional sponsorship by investors, foundations, public agencies, and charities through 
injection of fiat currency, blockchain technologies offer bespoke funding mechanisms which are linked to the 
trust without middlemen conferred by the decentralised, crypto-secured ledger and its smart contracts. 
Funding can, for instance, be raised by minting project-specific digital “coins”, e.g., so-called ERC-20 tokens 
[118] on Ethereum [50], which may be (pre-)mined and traded according to a transparent protocol. The value 
of these tokens is then freely determined by market dynamics. On top of their financial value, these crypto-
currencies might provide a “proof of stake” (PoS), e.g., for voting on upgrades or seats on arbitration panels, 
or for settling utility (transaction) fees charged to sustain the ecosystem of the underlying blockchain. 

Trust in such monetary seigniorage [119], i.e., the difference between the value of new money and the cost of 
their creation, is best supported best by open source release of code, proper documentation and credible 
validation of progress to avoid scams. Also “gaming” of coins and tokens by speculators poses a mission-



 

8 
 

critical risk to trust in projects, which is particularly pronounced with tiny trade volumes and limited numbers 
of independent stakeholders in the market. 

Financial authorities have frequently categorized cryptoassets issued through initial coin offerings (ICO) for 
funding blockchain projects as equivalent to securities, which would require compliance to stringent rules 
similar to initial public offerings (IPOs) of “shares” on traditional (centralised) stock exchanges. Such 
classification requires enormous efforts on compliance. Alternative models have been developed for tokens 
not representing classical assets and ownership. They may be offered in initial (security) token offerings, ITOs 
or STOs, respectively, and may then be traded in secondary markets. Also the issue of legally sound 
incorporation of businesses (“LAOs”) using crypto-economic mechanisms has been elaborated [120]. The 
attraction of such democratized decision-making organization to venture capital (VC) funding remains to be 
seen. 

2.10 ORGANIZATION 
As it has already surfaced in the previous sections, the availability of smart contracts on blockchains opens 
manifold avenues for rethinking classical approaches to the organization of projects. From a certain point of 
view, novel implementations seek to extend trust finding by decentralization, majority vote and PoW / PoS 
from the core of blockchain to the entire management structure. This applies to commercial projects, e.g., to 
direct management and investment decisions in DeFi by sourcing the wisdom of the crowd; such decentralised 
governance, e.g., as implemented by liquid (delegated) democracy [121] based establishment of consensus, 
also invigorates trust and community spirit in initiatives pursuing “Commons”, i.e., shared goals on 
advancement of blockchain technologies or for the good of mankind. 

Voting rights of stakeholders might be weighted by the amount (crypto-)assets which, in addition to purchase, 
may be earned by quality contributions to the entire gamut of the project such as work, validation, assessment, 
management, promotion, community building, forecasts, arbitration, governance, and by running 
infrastructure and further development of the underlying blockchain [122-124]. 

As the pinnacle of such developments, so-called Decentralised Autonomous Organisations [59, 122, 125-130] 
have been launched in the second half of the 2010s; these “DAOs” encode the complete organisational 
structure of a cooperative project into (a set of) smart contracts. DAOs are rapidly evolving into social tools 
and organizations that pursue a collective agenda for the benefit of the community or societies in general [123, 
131]. While some of these community-run, smart-contract constructs have exposed ma";"""date"",""2021-01-31T08:05:12Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.3""
""pdf:docinfo:title"",""Microsoft Word - Science & RTD by blockchain @ FiB_Authors accepted verion.doc""
""xmp:CreatorTool"",""Word""
""Keywords"",""""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""dcterms:created"",""2021-01-31T08:05:12Z""
""language"",""en""
""Last-Modified"",""2021-01-31T08:05:12Z""
""dcterms:modified"",""2021-01-31T08:05:12Z""
""dc:format"",""application/pdf; version=1.3""
""title"",""Microsoft Word - Science & RTD by blockchain @ FiB_Authors accepted verion.doc""
""Last-Save-Date"",""2021-01-31T08:05:12Z""
""pdf:docinfo:creator_tool"",""Word""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2021-01-31T08:05:12Z""
""meta:save-date"",""2021-01-31T08:05:12Z""
""pdf:encrypted"",""false""
""dc:title"",""Microsoft Word - Science & RTD by blockchain @ FiB_Authors accepted verion.doc""
""modified"",""2021-01-31T08:05:12Z""
""Content-Length"",""2171116""
""pdf:hasMarkedContent"",""false""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""dc:subject"",""""
""meta:creation-date"",""2021-01-31T08:05:12Z""
""created"",""2021-01-31T08:05:12Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""27""
""Creation-Date"",""2021-01-31T08:05:12Z""
""resourceName"",""FBloc_2021_Ducr_e_et_al_Authors_accepted_version.pdf""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""3867"",""4774"",""2431"",""4272"",""4388"",""4728"",""4859"",""4251"",""4553"",""4712"",""4737"",""2077"",""2308"",""2228"",""4915"",""5004"",""2861"",""4317"",""3724"",""1381"",""5687"",""5699"",""5971"",""5864"",""5908"",""5719"",""1258""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""meta:keyword"",""""
""producer"",""Mac OS X 10.13.6 Quartz PDFContext""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""Mac OS X 10.13.6 Quartz PDFContext""
""pdf:docinfo:created"",""2021-01-31T08:05:12Z""
";https://scholar.google.ch/scholar?start=20&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2021
1619099124-450;https://scholar.google.ch/scholar?as_ylo=2021&q=oracles+blockchain&hl=fr&as_sdt=0,5;Tighter security proofs for GPV-IBE in the quantum random oracle model;S Katsumata, S Yamada, T Yamakawa ; Journal of Cryptology, 2021  Springer;;"… technique and resembles the approach used in the public key encryption scheme of Cramer

and Shoup (CRYPTO, 1998) … Random Oracles in Quantum World In general, security proofs of

practical cryptographic schemes are given in the random oracle model (ROM …";Cité 10 fois;Les 6 versions;[PDF] iacr.org;https://eprint.iacr.org/2018/451.pdf;"
Tighter Security Proofs for GPV-IBE in the

Quantum Random Oracle Model

Shuichi Katsumata*†, Shota Yamada†, and Takashi Yamakawa‡

*The University of Tokyo
shuichi katsumata@it.k.u-tokyo.ac.jp

†National Institute of Advanced Industrial Science and Technology (AIST)
yamada-shota@aist.go.jp

‡NTT Secure Platform Laboratories
yamakawa.takashi@lab.ntt.co.jp

November 20, 2018

Abstract

In (STOC, 2008), Gentry, Peikert, and Vaikuntanathan proposed the first identity-based
encryption (GPV-IBE) scheme based on a post-quantum assumption, namely, the learning
with errors (LWE) assumption. Since their proof was only made in the random oracle model
(ROM) instead of the quantum random oracle model (QROM), it remained unclear whether
the scheme was truly post-quantum or not. In (CRYPTO, 2012), Zhandry developed new
techniques to be used in the QROM and proved security of GPV-IBE in the QROM, hence
answering in the affirmative that GPV-IBE is indeed post-quantum. However, since the general
technique developed by Zhandry incurred a large reduction loss, there was a wide gap between
the concrete efficiency and security level provided by GPV-IBE in the ROM and QROM.
Furthermore, regardless of being in the ROM or QROM, GPV-IBE is not known to have a
tight reduction in the multi-challenge setting. Considering that in the real-world an adversary
can obtain many ciphertexts, it is desirable to have a security proof that does not degrade
with the number of challenge ciphertext.

In this paper, we provide a much tighter proof for the GPV-IBE in the QROM in the
single-challenge setting. In addition, we also show that a slight variant of the GPV-IBE
has an almost tight reduction in the multi-challenge setting both in the ROM and QROM,
where the reduction loss is independent of the number of challenge ciphertext. Our proof
departs from the traditional partitioning technique and resembles the approach used in the
public key encryption scheme of Cramer and Shoup (CRYPTO, 1998). Our proof strategy
allows the reduction algorithm to program the random oracle the same way for all identities
and naturally fits the QROM setting where an adversary may query a superposition of all
identities in one random oracle query. Notably, our proofs are much simpler than the one by
Zhandry and conceptually much easier to follow for cryptographers not familiar with quantum
computation. Although at a high level, the techniques used for the single and multi-challenge
setting are similar, the technical details are quite different. For the multi-challenge setting,
we rely on the Katz-Wang technique (CCS, 2003) to overcome some obstacles regarding the
leftover hash lemma.

Keywords. Identity-based encryption, quantum random oracle models, LWE assumption,
tight security reduction, multi-challenge security.

1



Contents

1 Introduction 3
1.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Our Contribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3 Technical Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.4 Discussion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.5 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2 Preliminaries 10
2.1 Quantum Computation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.2 Pseudorandom Function. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.3 Identity-Based Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.4 Background on Lattices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3 Tightly Secure Single Challenge GPV-IBE 16
3.1 Construction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.2 Correctness and Parameter Selection . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.3 Security Proof in ROM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.4 Security Proof in QROM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

4 (Almost) Tightly Secure Multi-Challenge IBE 24
4.1 Randomness Extraction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.2 Construction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.3 Correctness and Parameter Selection . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.4 Security Proof in ROM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.5 Security Proof in QROM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

2



1 Introduction

1.1 Background

Shor [Sho94] in his breakthrough result showed that if a quantum computer is realized, then almost
all cryptosystems used in the real world will be broken. Since then, a significant amount of studies
have been done in the area of post-quantum cryptography, whose motivation is constructing
cryptosystems secure against quantum adversaries. Recently in 2016, the National Institute of
Standards and Technology (NIST) initiated the Post-Quantum Cryptography Standardization,
and since then post-quantum cryptography has been gathering increasingly more attention.

Random Oracles in Quantum World. In general, security proofs of practical cryptographic
schemes are given in the random oracle model (ROM) [BR93], which is an idealized model where
a hash function is modeled as a publicly accessible oracle that computes a random function.
Boneh et al. [BDF+11] pointed out that the ROM as in the classical setting is not reasonable
when considering security against quantum adversaries, since quantum adversaries may compute
hash functions over quantum superpositions of many inputs. Considering this fact, as a reasonable
model against quantum adversaries, they proposed a new model called the quantum random oracle
model (QROM), where a hash function is modeled as a quantumly accessible random oracle. As
discussed in [BDF+11], many commonly-used proof techniques in the ROM do not work in the
QROM. Therefore even if we have a security proof in the ROM, we often require new techniques
to obtain similar results in the QROM.

Identity-based Encryption in QROM. Identity-Based Encryption (IBE) is a generalization
of a public key encryption scheme where the public key of a user can be any arbitrary string
such as an e-mail address. The first IBE scheme based on a post-quantum assumption is the
one proposed by Gentry, Peikert and Vaikuntanathan (GPV-IBE) [GPV08], which is based on
the learning with errors (LWE) assumption [Reg05]. To this date, GPV-IBE is still arguably the
most efficient IBE scheme that is based on a hardness assumption that resists quantum attacks.
However, since their original security proof was made in the ROM instead of the QROM, it was
unclear if we could say the scheme is truly post-quantum. Zhandry [Zha12b] answered this in
the affirmative by proving that the GPV-IBE is indeed secure in the QROM under the LWE
assumption, hence truly post-quantum, by developing new techniques in the QROM.

Tight Security of GPV-IBE. However, if we consider the tightness of the reduction, the security
proof of the GPV-IBE by Zhandry [Zha12b] does not provide satisfactory security. Specifically,
GPV-IBE may be efficient in the ROM, but it is no longer efficient in the QROM. In general, a
cryptographic scheme is said to be tightly secure under some assumption if breaking the security
of the scheme is as hard as solving the assumption. More precisely, suppose that we proved that if
there exists an adversary breaking the security of the scheme with advantage Îľ and running time T ,
we can break the underlying assumption with advantage ε′ and running time T ′. We say that the
scheme is tightly-secure if we have ε′/T ′ ≈ ε/T . By using this notation, Zhandry gave a reduction
from the security of GPV-IBE to the LWE assumption with ε′ ≈ ε2/(QH + QID)4 and T ′ ≈
T + (QH +QID)2 ¡ poly(Ν) where QH denotes the number of hash queries, QID denotes the number
of secret key queries, Îť denotes the security parameter, and poly denotes some fixed polynomial.
Though the reduction is theoretically interesting, the meaning of the resulting security bound in
a realistic setting is unclear. For example, if we want to obtain 128-bit security for the resulting
IBE, and say we had ε = 2−128, QH = 2100, QID = 220, then even if we ignore the blowup for
the running time, we would have to start from at least a 656-bit secure LWE assumption, which
incurs a significant blowup of the parameters. Indeed, Zhandry left it as an open problem to give

3



a tighter reduction for the GPV-IBE.

Multi-Challenge Tightness. The standard security notion of IBE considers the setting where
an adversary obtains only one challenge ciphertext. This is because security against adversaries
obtaining many challenge ciphertexts can be reduced to the security in the above simplified setting.
However, as pointed out by Hofheinz and Jager [HJ12], tightness is not preserved in the above
reduction since the security degrades by the number of ciphertexts. Therefore tightly secure IBE
in the single-challenge setting does not imply tightly secure IBE in the multi-challenge setting.
On the other hand, in the real world, it is natural to assume that an adversary obtains many
ciphertexts, and thus tight security in the multi-challenge setting is desirable. However, there is
no known security proof for the GPV-IBE or its variant that does not degrade with the number
of challenge ciphertexts even in the classical setting.

1.2 Our Contribution

We provide much tighter security proofs for the GPV-IBE in the QROM in the single-challenge
setting. Furthermore, we provide a multi-challenge tight variant of GPV-IBE that is secure both
in the ROM and QROM. In the following, we describe the tightness of our security proofs by
using the same notation as in the previous section.

• In the single-challenge setting, we give a reduction from the security of GPV-IBE to the
LWE assumption with ε′ ≈ ε and T ′ = T + (QH + QID)2 · poly(λ). If we additionally
assume quantumly secure pseudorandom functions (PRFs), then we further obtain a tighter
reduction, which gives ε′ ≈ ε and T ′ = T + (QH + QID) · poly(λ). This is the first security
proof for GPV-IBE whose security bound does not degrade with QH or QID even in the
classical setting. We note that the same security bound can be achieved without assuming
PRFs in the classical ROM.

• We give a slight variant of GPV-IBE scheme whose multi-challenge security is reduced to
the LWE assumption with ε′ = ε/poly(λ) and T ′ ≈ T + (QH + QID + Qch)2 · poly(λ) where
Qch denotes the number of challenge queries. If we additionally assume quantumly secure
PRFs, then we further obtain a tighter reduction. Namely, ε′ is the same as the above, and
T ′ = T + (QH +QID +Qch) ·poly(λ). This is the first variant of the GPV-IBE scheme whose
security bound does not degrade with Qch even in the classical setting. We note that the
same security bound can be achieved without assuming PRFs in the classical ROM.

Moreover, our security proofs are much simpler than the one by Zhandry [Zha12b]. In his work, he
introduced new techniques regarding indistinguishability of oracles against quantum adversaries.
Though his techniques are general and also useful in other settings (e.g., [Zha12a]), it involves
some arguments on quantum computation, and they are hard to follow for cryptographers who
are not familiar with quantum computation. On the other hand, our proofs involve a minimal
amount of discussions about quantum computation, and our proofs are done almost similar to
the counterparts in the classical ROM.

1.3 Technical Overview

GPV-IBE. First, we briefly describe the GPV-IBE [GPV08], which is the main target of this
paper. A master public key is a matrix A ∈ Zn×mq and a master secret key is its trapdoor
TA ∈ Zm×m, which enables one to compute a short vector e ∈ Zmq such that Ae = u given an
arbitrary vector u ∈ Znq . A private key skID for an identity ID ∈ ID is a short vector e ∈ Zmq

4



such that Ae = uID where uID = H(ID) for a hash function H : ID → Znq , which is modeled as

a random oracle. A ciphertext for a message M ∈ {0, 1} consists of c0 = u>IDs + x + Mbq/2e and
c1 = A>s + x. Here s is a uniformly random vector over Znq and x,x are small “noise” terms
where each entries are sampled from some specific Gaussian distribution χ. Decryption can be
done by computing w = c0 − c>1 eID ∈ Zq and deciding if w is closer to 0 or to bq/2e modulo q.

Security Proof in Classical ROM. The above IBE relies its security on the LWE assumption,

which informally states the following: given a uniformly random matrix [A|u] ← Zn×(m+1)
q and

some vector b ∈ Zm+1
q , there is no PPT algorithm that can decide with non-negligible proba-

bility whether b is of the form [A|u]>s + x′ for some s ← Znq and x′ ← χm+1, or a uniformly
random vector over Zm+1

q , i.e., b ← Zm+1
q . Below, we briefly recall the original security proof

in the classical ROM given by Gentry et al. [GPV08] and see how the random oracle is used by
the reduction algorithm. The proof relies on a key lemma which states that we can set H(ID)
and e in the “reverse order” from the real scheme. That is, we can first sample e from some
distribution and program H(ID) := Ae so that their distributions are close to uniformly random
as in the real scheme. In the security proof, a reduction algorithm guesses i ∈ [Q] such that the
adversary’s i-th hash query is the challenge identity ID∗ where Q denotes the number of hash
queries made by the adversary. Then for all but the i-th hash query, the reduction algorithm
programs H(ID) in the above manner, and for the i-th query, it programs the output of H(ID∗)
to be the vector u contained in the LWE instance that is given as the challenge. Specifically,
the reduction algorithm sets the challenge user’s identity vector uID∗ as the random vector u
contained in the LWE instance. If the guess is correct, then it can embed the LWE instance into
the challenge ciphertexts c∗0 and c∗1; in case it is a valid LWE instance, then (c∗0, c

∗
1) is properly set

to (u>ID∗s + x+ Mbq/2e,A>s + x) as in the real scheme. Therefore, the challenge ciphertext can
be switched to random due to the LWE assumption. After this switch, M is perfectly hidden and
thus the security of GPV-IBE is reduced to the LWE assumption. Since the reduction algorithm
programs the random oracle in the same way except for the challenge identity, this type of proof
methodology is often times referred to as the “all-but-one programming”.

Security Proof in QROM in [Zha12b]. Unfortunately, the above proof cannot be simply
extended to a proof in the QROM. The reason is that in the QROM, even a single hash query
can be a superposition of all the identities. In such a case, to proceed with the above all-but-
one programming approach, the reduction algorithm would have to guess a single identity out
of all the possible identities which he hopes that would be used as the challenge identity ID∗ by
the adversary. Obviously, the probability of the reduction algorithm being right is negligible,
since the number of possible identities is exponentially large. This is in sharp contrast with the
ROM setting, where the reduction algorithm was allowed to guess the single identity out of the
polynomially many (classical) random oracle queries made by the adversary. Therefore, the all-
but-one programming as in the classical case cannot be used in the quantum case. To overcome this
barrier, Zhandry [Zha12b] introduced a useful lemma regarding what he calls the semi-constant
distribution. The semi-constant distribution with parameter 0 < p < 1 is a distribution over
functions from X to Y such that a function chosen according to the distribution gives the same
fixed value for random p-fraction of all inputs, and behaves as a random function for the rest of
the inputs. He proved that a function according to the semi-constant distribution with parameter
p and a random function cannot be distinguished by an adversary that makes Q oracle queries
with advantage greater than 8

3Q
4p2. In the security proof, the reduction algorithm partitions the

set of identities into controlled and uncontrolled sets. The uncontrolled set consists of randomly

5



chosen p-fraction of all identities, and the controlled set is the complement of it. The reduction
algorithm embeds an LWE instance into the uncontrolled set, and programs the hash values for
the controlled set so that the decryption keys for identities in the controlled set can be extracted
efficiently. Then the reduction algorithm works as long as the challenge identity falls inside the
uncontrolled set and all identities for secret key queries fall inside the controlled set (otherwise
it aborts). By appropriately setting p, we can argue that the probability that the reduction
algorithm does not abort is non-negligible, and thus the security proof is completed. Though this
technique is very general and useful, a huge reduction loss is inherent as long as we take the above
strategy because the reduction algorithm has to abort with high probability. It may be useful to
point out for readers who are familiar with IBE schemes in the standard model that the above
technique is conceptually very similar to the partitioning technique which is often used in the
context of adaptively secure IBE scheme in the standard model [Wat05, ABB10, CHKP10]. The
reason why we cannot make the proof tight is exactly the same as that for the counterparts in
the standard model.

Our Tight Security Proof in QROM. As discussed above, we cannot obtain a tight reduction
as long as we use a partitioning-like technique. Therefore we take a completely different approach,
which is rather similar to that used in the public key encryption scheme of Cramer and Shoup
[CS98], which has also been applied to the pairing-based IBE construction of Gentry [Gen06].
The idea is that we simulate in a way so that we can create exactly one valid secret key for every
identity. Note that this is opposed to the partitioning technique (and the all-but-one programming
technique) where the simulator cannot create a secret key for an identity in the uncontrolled set.
To create the challenge ciphertext, we use the one secret key we know for that challenge identity.
If the adversary can not tell which secret key the ciphertext was created from and if there are
potentially many candidates for the secret key, we can take advantage of the entropy of the secret
key to statistically hide the message.

In more detail, the main observation is that the secret key e, i.e. a short vector e such that
Ae = u, retains plenty of entropy even after fixing the public values A and u. Therefore, by
programming the hash value u of an identity, we can easily create a situation where the simulator
knows exactly one secret key out of the many possible candidates. Furthermore, the simulator
knowing a secret key eID∗ such that AeID∗ = uID∗ , can simulate the challenge ciphertext by
creating c∗0 = e>ID∗c

∗
1 + Mbq/2e and c∗1 = A>s + x. Here, the key observation is that we no

longer require the LWE instance (uID∗ ,u
>
ID∗s + x) to simulate the challenge ciphertext. Though

the distribution of c∗0 simulated as above is slightly different from that of the real ciphertext due
to the difference in the noise distributions, we ignore it in this overview. In the real proof, we
overcome this problem by using the noise rerandomization technique by Katsumata and Yamada
[KY16]. Then we use the LWE assumption to switch c∗1 to random. Finally, we argue that
e>ID∗c

∗
1 is almost uniform if the min-entropy of eID∗ is high and c∗1 is uniformly random due to the

leftover hash lemma. Therefore, all information of the message M is hidden and thus the proof is
completed.

Finally, we observe that the above proof naturally fits in the QROM setting. The crucial
difference from the partitioning technique is that in our security proof we program the random
oracle in the same way for all identities. Therefore even if an adversary queries a superposition
of all identities, the simulator can simply quantumly perform the programming procedure for the
superposition. Thus the proof in the classical ROM can be almost automatically converted into
the one in the QROM.

Tight Security in Multi-Challenge Setting. Unfortunately, the above idea does not extend
naturally to the tightly-secure multi-challenge setting. One can always prove security in the multi-

6



challenge setting starting from a scheme that is single-challenge secure via a hybrid argument,
however, as mentioned by Hofheinz and Jager [HJ12], this type of reduction does not preserve
tightness. A careful reader may think that the above programming technique can be extended
to the multi-challenge setting, hence bypassing the hybrid argument. We briefly explain why
this is not the case. Informally, in the above proof, the reduction algorithm embeds its given
LWE instance (A,A>s+x) into the challenge ciphertext by creating (c∗0 = e>ID∗c

∗
1 +Mbq/2e, c∗1 =

A>s+x), where eID∗ is the secret key of the challenge user uID∗ . Therefore, since the c∗1 component
of every ciphertext is an LWE instance for the same public matrix A, to simulate multiple challenge
ciphertexts in the above manner, the reduction algorithm must be able to prepare a special type of
LWE instance (A, {A>s(k) +x(k)}k∈[N ]), where N = poly(Ν) is the number of challenge ciphertext
queried by the adversary. It can be easily seen that this construction is tightly-secure in the multi-
challenge setting with the same efficiency as the single-challenge setting, if we assume that this
special type of LWE problem is provided to the reduction algorithm as the challenge. However,
unfortunately, we still end up losing a factor of N in the reduction when reducing the standard
LWE problem to this special LWE problem. In particular, we only shifted the burden of having
to go through the N hybrid arguments to the assumption rather than to the scheme. As one may
have noticed, there is a way to bypass the problem of going through the N hybrid arguments
by using conventional techniques (See [Reg05, Reg10]) of constructing an unlimited number of
fresh LWE instances given a fixed number of LWE instances. However, this techniques requires
the noise of the newly created LWE instances to grow proportionally to the number of created
instances. In particular, to create the above special LWE instance from a standard LWE instance,
we require the size of the noise x(k) to grow polynomially with N , where recall that N can be
an arbitrary polynomial. Hence, although we can show a tightly secure reduction in the multi-
challenge setting, for the concrete parameters of the scheme to be independent of N , we need
to assume the LWE assumption with super-polynomial modulus size to cope with the super-
polynomial noise blow up. This is far more inefficient than in the single-challenge setting where
we only had to require an LWE assumption with polynomial modulus size.

To overcome this problem, we use the “lossy mode” of the LWE problem. It is well known
that the secret vector s is uniquely defined given an LWE instance (A,A>s + x) for large enough
samples. A series of works, e.g., [GKPV10, BKPW12, AKPW13, LSSS17] have observed that if
we instead sample A from a special distribution that is computationally indistinguishable from
the uniform distribution, then (A,A>s + x) leaks almost no information of the secret s, hence
the term “lossy mode”. This idea can be leveraged to prove (almost) tight security of the above
single-challenge construction, where the reduction loss is independent of the number of challenge
ciphertext. A first attempt of using this idea is as follows: During the security proof of the GPV-
IBE, we first change the public matrix A to a lossy matrix à and generate the secret keys and
program the random oracle in the same way as before. To create the challenge ciphertexts, the
reduction algorithm honestly samples s(k), x(k), x(k) and sets (c∗0 = u>ID∗s

(k)+x(k)+M(k)bq/2e, c∗1 =

A>s(k)+x(k)). Now, it may seem that owing to the lossy mode of LWE, we can rely on the entropy
of the secret vector s(k) to argue that c∗0 is distributed uniformly random via the leftover hash
lemma. The main difference between the previous single-challenge setting is that we can rely on
the entropy of the secret vector s(k) rather than on the entropy of the secret key eID∗ . Since each
challenge ciphertext is injected with fresh entropy and we can argue statistically that a single
challenge ciphertext is not leaking any information on the message, the reduction loss will be
independent of the number of challenge ciphertext query N .

Although the above argument may seem correct at first glance, it incurs a subtle but a fatal
flaw, thus bringing us to our proposed construction. The problem of the above argument is how

7



we use the leftover hash lemma. To use the lemma correctly, the vector uID∗ viewed as a hash
function is required to be universal. This is true in case uID∗ is set as AeID∗ , where A ← Zn×mq

and eID∗ is sampled from some appropriate distribution. However, this is not true anymore once
we change A to a lossy matrix Ã, since à now lives in an exponentially small subset of Zn×mq ,

and uID∗ is no longer universal. Specifically, we can no longer rely on the entropy of s(k) to
statistically hide the message. To overcome this problem, our final idea is to use the Katz-Wang
[KW03] technique. Specifically, we slightly alter the encryption algorithm of GPV-IBE to output
the following instead:

c0 = u>ID||0s + x0 + Mbq/2e, c1 = u>ID||1s + x1 + Mbq/2e, and c2 = A>s + x,

where uID||b = H(ID||b) for b ∈ {0, 1}. During the security proof, the reduction algorithm sets
uID||0 and uID||1 so that one of them is uniformly random over Znq and the other is constructed
as AeID. Then, for the ciphertext cb corresponding to the uniformly random vector uID||b, we
can correctly use the leftover hash lemma to argue that cb statistically hides the message M. By
going through one more hybrid argument, we can change both c0, c1 into random values that are
independent of the message M. Note that instead of naively using the Katz-Wang technique, by
reusing the c2 component, the above GPV-IBE variant only requires one additional element in Zq
compared to the original GPV-IBE. Furthermore, in the actual construction, we do not require
the noise terms x0, x1 in c0, c1 since we no longer rely on the LWE assumption to change c0, c1

into random values. Our construction and security reduction does not depend on the number of
challenge ciphertext query N and in particular, can be proven under the LWE assumption with
polynomial modulus size. In addition, due to the same reason as the single-challenge setting, our
classical ROM proof can be naturally converted to a QROM proof.

1.4 Discussion.

Similar Techniques in Other Works. The idea to simulate GPV-IBE in a way so that we
can create exactly one valid secret key for every secret key query is not new. We are aware of few
works that are based on this idea. Gentry, Peikert and Vaikuntanathan [GPV08] mentioned that
by using this technique, they can prove the security of the GPV-IBE in the standard model based
on a non-standard interactive variant of the LWE (I-LWE) assumption which requires a hash
function to define. Here since the hash function is given to the adversary, a quantum adversary
may query quantum states to the hash functions on its own. Therefore, in addition with the
fact that the I-LWE assumption is made in the standard model, the statement made by [GPV08]
would hold in the QROM as well. However, they only gave a sketch of the proof, and did not give
a formal proof. Alwen et al. [ADN+10] use the idea to construct an identity-based hash proof
system (IB-HPS) based on the mechanism of GPV-IBE. We note that they assume the modulus
q to be super-polynomial. Outside the context of identity-based primitives, Applebaum et al.
[ACPS09] and Bourse et al. [BDPMW16] provide an analysis of rerandomizing LWE samples
which can be seen as a refinement of the idea mentioned in [GPV08]. [ACPS09] constructs a
KDM-secure cryptosystem based on the LWE problem and [BDPMW16] shows a simple method
for constructing circuit private fully homomorphic encryption schemes (FHE) based on the lattice-
based FHE scheme of Gentry et al. [GSW13]. Both of their analysis only requires the modulus
q to be polynomial. In summary, though similar ideas have been used, all of the previous works
are irrelevant to tight security or the security in the QROM.

On Parameter-Tightness of Our Schemes. In the above overview, we focused on the tightness
of the security proof. Here, we provide some discussions on how the parameters compare to the

8



original GPV-IBE scheme [GPV08]. For the single challenge setting, our parameters are only a
small factor worse than the GPV-IBE scheme. This is because the only difference is using the
noise rerandomization technique of [KY16], which only slightly degrades the noise-level.1 For the
multi-challenge setting, the situation is more different. In this case, the parameters are much
worse than the original (single-challenge secure) GPV-IBE scheme. This is because we have to go
through the lossy-mode of LWE which requires for larger parameters. The concrete parameters
are provided in Sec. 4.3.

Relation to CCA-Secure PKE. By applying the Canetti-Halevi-Katz transformation [CHK04]
to our single-challenge-secure IBE scheme, we obtain a public key encryption (PKE) scheme secure
against chosen ciphertext attacks (CCA) that is tightly secure in the single-challenge setting under
the LWE assumption in the QROM. We note that Saito et al. [SXY18] already proposed such
a PKE scheme in the single-challenge setting that is more efficient than the scheme obtained by
the above transformation.

On Running Time of Reductions. In the above overview, we ignore the running time of
reductions. Though it seems that the above described reductions run in nearly the same time as
the adversaries, due to a subtle problem of simulating random oracles against quantum adversaries,
there is a significant blowup by a square factor of the number of queries the adversaries make.
In the classical ROM, when we simulate a random oracle in security proofs, we usually sample
a random function in a lazy manner. That is, whenever an adversary queries a point that has
not been queried before, a reduction algorithm samples a fresh randomness and assigns it as a
hash value for that point. However, this cannot be done in the QROM because an adversary may
query a superposition of all the inputs in a single query. Therefore a reduction algorithm has to
somehow commit to the hash values of all inputs at the beginning of the simulation.

Zhandry [Zha12b] proved that an adversary that makes Q queries cannot distinguish a random
function and a 2Q-wise independent hash function via quantum oracle accesses. Therefore we can
use a 2Q-wise independent hash to simulate a random oracle. However, if we take this method,
the simulator has to evaluate a 2Q-wise independent hash function for each hash query, and this
is the reason why the running time blowups by Ω(Q2).

One possible way to avoid this huge blowup is to simulate a random oracle by a PRF secure
against quantum accessible adversaries. Since the time needed to evaluate a PRF is some fixed
polynomial in the security parameter, the blowup for the running time can be made Q ¡ poly(Ν)
which is significantly better than Ω(Q2). However, in order to use this method, we have to
additionally assume the existence of quantumly secure PRFs. Such PRFs can be constructed based
on any quantumly-secure one-way function [Zha12a], and thus they exist if the LWE assumption
holds against quantum adversaries. However, the reduction for such PRFs are non-tight and thus
we cannot rely on them in the context of tight security. Our suggestion is to use a real hash
function to implement PRFs and to assume that it is a quantumly secure PRF. We believe this
to be a natural assumption if we are willing to idealize a hash function as a random oracle. (See
also the discussion in Sec. 2.2.)

1.5 Related Work

Schemes in QROM. Boneh et al. [BDF+11] introduced the QROM, and gave security proo";"""date"",""2018-11-20T10:38:26Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2018-11-20T10:38:26Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017/W32TeX) kpathsea version 6.2.3""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2018-11-20T10:38:26Z""
""created"",""2018-11-20T10:38:26Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2018-11-20T10:38:26Z""
""resourceName"",""451.pdf""
""Author"",""""
""producer"",""pdfTeX-1.40.18""
""pdf:docinfo:producer"",""pdfTeX-1.40.18""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""13"",""15"",""14"",""6"",""12"",""7"",""0"",""15"",""14"",""32"",""14"",""16"",""37"",""6"",""47"",""2"",""44"",""46"",""26"",""44"",""51"",""19"",""32"",""40"",""45"",""31"",""79"",""61"",""24"",""74"",""88"",""47"",""0"",""0"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2018-11-20T10:38:26Z""
""Last-Modified"",""2018-11-20T10:38:26Z""
""dcterms:modified"",""2018-11-20T10:38:26Z""
""title"",""""
""Last-Save-Date"",""2018-11-20T10:38:26Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2018-11-20T10:38:26Z""
""meta:save-date"",""2018-11-20T10:38:26Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017/W32TeX) kpathsea version 6.2.3""
""Content-Length"",""504115""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""38""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""2373"",""1149"",""3322"",""2868"",""3480"",""3497"",""3668"",""3212"",""3281"",""3007"",""2751"",""2396"",""2778"",""2308"",""2296"",""2375"",""1676"",""2399"",""2812"",""2724"",""2437"",""2466"",""2860"",""1970"",""2118"",""2248"",""1870"",""2509"",""3146"",""2559"",""2417"",""2914"",""2802"",""2673"",""2114"",""2271"",""2236"",""1343""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2018-11-20T10:38:26Z""
";https://scholar.google.ch/scholar?start=40&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2021
1619099107-408;https://scholar.google.ch/scholar?as_ylo=2021&q=oracles+blockchain&hl=fr&as_sdt=0,5;On Elastic Incentives for Blockchain Oracles;RM Murimi, GG Wang ; Journal of Database Management (JDM), 2021  igiglobal.com;;"A fundamental open question for oracles in blockchain environments is a determination of 
the amount of trust to be placed in the oracle. Oracles serve as intermediaries between a 
trusted blockchain environment and the untrusted external environment from where the …";;null;null;;;;
1619099120-443;https://scholar.google.ch/scholar?as_ylo=2021&q=oracles+blockchain&hl=fr&as_sdt=0,5;… Process Engineering for Data Storing and Processing in a Collaborative Distributed Environment Based on Provenance Metadata, Smart Contracts and Blockchain …;A Demichev, A Kryukov, N Prikhod'ko ; Journal of Grid Computing, 2021  Springer;;"… inherits rather cumber- some structure of the Ethereum platform including the use of cryptocurrency

that is … In addition, this increases the risk that records in the blockchain may not fully correspond

to the actual state of the Data Lake (the so-called oracle problem, see …";;null;null;;;;https://scholar.google.ch/scholar?start=30&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2021
1619099142-493;https://scholar.google.ch/scholar?as_ylo=2021&q=oracles+blockchain&hl=fr&as_sdt=0,5;[LIVRE][B] The Theory of Hash Functions and Random Oracles: An Approach to Modern Cryptography;A Mittelbach, M Fischlin ;2021 books.google.com;;"… Preface xi techniques used with random oracles, random oracle constructions as well as examples

of real-world random oracle schemes but also limitations of random oracles and a discussion

of the random oracle controversy, the fact that uninstantiable schemes exist which …";;null;null;;;;https://scholar.google.ch/scholar?start=80&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2021
1619099129-459;https://scholar.google.ch/scholar?as_ylo=2021&q=oracles+blockchain&hl=fr&as_sdt=0,5;An efficient anti-quantum lattice-based blind signature for blockchain-enabled systems;C Li, Y Tian, X Chen, J Li ; Information Sciences, 2021  Elsevier;;"… Meanwhile, this scheme can prove to be safe in the random oracle model as it can be reduced

to the short integer solution (SIS) problem … [11] gave a simple definition of the post-quantum

blockchain (PQB), and proposed a secure lattice-based cryptocurrency scheme based …";Cité 3 fois;Les 2 versions;null;;;;https://scholar.google.ch/scholar?start=50&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2021
1619099120-447;https://scholar.google.ch/scholar?as_ylo=2021&q=oracles+blockchain&hl=fr&as_sdt=0,5;[HTML][HTML] Blockchain smart contracts: Applications, challenges, and future trends;SN Khan, F Loukil, C Ghedira;Guegan…  PeertoPeer Networking …, 2021 ;United States of America;"… In 2008, Satoshi Nakamoto introduced Bitcoin [69] that was the first proposed cryptocurrency

introducing the blockchain as a distributed infrastructural technology. It allowed users to transfer

securely crypto-currencies, known as “bitcoins” without a centralized regulator …";Les 2 versions;;[HTML] springer.com;https://link.springer.com/article/10.1007/s12083-021-01127-0;"
    
    
    
        
            
            
                
            

            
        
    


    
        
        

        
            
                Advertisement

                    

            

        


    
        
            
                
    
        
            
            [image: SpringerLink]
        
        
        
    


            

            
                
    
        
            
                Search
                
                    
                
            
        
        
            	
                    Log in
                


        
    

    



            

        

    

    
        
            
                
                    
                        
    
        Search SpringerLink
        
            
            
                Search
                
                    
                
            
            
                
            
            
        

    




                    

                

            

        

    



        

    
        
            
                
                
                    
                        
                            Blockchain smart contracts: Applications, challenges, and future trends
                        

                        
    
        
            
                Download PDF
                
            
        
    



                    

                

            

            
                
    
        
            
                Download PDF
                
            
        
    


            


            
                
    
        
            
                Associated Content

                
                    
                        
                            Part of a collection:

                            
                                Special Issue on Blockchain for Peer-to-Peer Computing
                            

                        
                    

                
            

        
    

            



            
                
                    
                        	Published: 18 April 2021



                        
                        Blockchain smart contracts: Applications, challenges, and future trends

                        	Shafaq Naheed Khan1, 
	Faiza Loukil 
            ORCID: orcid.org/0000-0003-4753-060X2, 
	Chirine Ghedira-Guegan3, 
	Elhadj Benkhelifa4 & 
	Anoud Bani-Hani1 


                        
                            
    Peer-to-Peer Networking and Applications

                            (2021)Cite this article
                        

                        
    

                        
                            
    
        	
                    189 Accesses

                
	
                Metrics details

            


    




                        

                            
    

    

                    
                


                
                    Abstract
In recent years, the rapid development of blockchain technology and cryptocurrencies has influenced the financial industry by creating a new crypto-economy. Then, next-generation decentralized applications without involving a trusted third-party have emerged thanks to the appearance of smart contracts, which are computer protocols designed to facilitate, verify, and enforce automatically the negotiation and agreement among multiple untrustworthy parties. Despite the bright side of smart contracts, several concerns continue to undermine their adoption, such as security threats, vulnerabilities, and legal issues. In this paper, we present a comprehensive survey of blockchain-enabled smart contracts from both technical and usage points of view. To do so, we present a taxonomy of existing blockchain-enabled smart contract solutions, categorize the included research papers, and discuss the existing smart contract-based studies. Based on the findings from the survey, we identify a set of challenges and open issues that need to be addressed in future studies. Finally, we identify future trends.



                    
    


                    

                    

                    
                        
                            Introduction
For more than a decade, the blockchain is established as a technology where a distributed database records all the transactions that have happened in a peer-to-peer network. It is regarded as a distributed computing paradigm that successfully overcomes the issue related to the trust of a centralized party. Thus, in a blockchain network, several nodes collaborate among them to secure and maintain a set of shared transaction records in a distributed way without relying on any trusted party. In 2008, Satoshi Nakamoto introduced Bitcoin [69] that was the first proposed cryptocurrency introducing the blockchain as a distributed infrastructural technology. It allowed users to transfer securely crypto-currencies, known as “bitcoins” without a centralized regulator. Besides, Ethereum [16], NXT [71], and Hyperledger Fabric [4] were also proposed as blockchain-based systems used for the cryptocurrency. Unlike Bitcoin, they can use smart contracts (SC). Blockchain technology overlaps traditional contracts by including the terms of agreements between two or more parties, but surpasses them thanks to smart contracts by automating the execution of agreements in a distributed environment when conditions are met.
Smart contracts are executable codes that run on top of the blockchain to facilitate, execute, and enforce an agreement between untrustworthy parties without the involvement of a trusted third-party [16]. Smart contracts gave network automation and the ability to convert paper contracts into digital contracts. Compared to traditional contracts, smart contracts enabled users to codify their agreements and trust relations by providing automated transactions without the supervision of a central authority [89]. In order to prevent contract tampering, smart contracts are copied to each node of the blockchain network. By enabling the execution of the operations by computers and services provided by blockchain platforms, human error could be reduced to avoid disputes regarding such contracts.
Although smart contracts have made progress in recent years, they still face many challenges. For instance, one infamous malicious attack took place in 2016 when the Decentralized Autonomous Organization (DAO) smart contract was manipulated to steal around 2 Million Ether Footnote 1(50 Million USD on the time) because of its re-entrancy vulnerability [103]. In addition to the vulnerability problem, smart contracts face several challenges including privacy, legal, and performance issues.
To understand current topics on smart contracts, we conduct a comprehensive survey, with the aim of better identifying and mapping research areas that need further studies. The focus of this survey is studying smart contracts from the technical point of view (e.g., codifying, security, performance issues) and the usage point of view (e.g., smart contract applications in finance, healthcare, etc). The major contributions of this paper are summarized as follows: 

	
                1.
                
                  We propose a taxonomy of studies based on blockchain-enabled smart contracts including two categories, namely SC improvement and SC usage.

                
              
	
                2.
                
                  We categorize 200 papers that we have extracted from different digital databases and discuss the existing smart contract-based studies.

                
              
	
                3.
                
                  Based on the findings from the survey, we identify a set of smart contract challenges and open issues that need to be addressed in future studies. Therefore, this survey provides a helpful reference to the researchers who want to target smart contract improvement or usage in their future studies.

                
              
	
                4.
                
                  Finally, we discuss future trends of smart contracts and explain how they provide better solutions to the open research challenges.

                
              

Considering the above contributions, the remainder of this paper is structured as follows. Section 2 discusses background information about blockchain and smart contracts technologies. Section 3 discusses existing reviews studying smart contract-based approaches. Section 4 describes the adopted survey methodology and the solution taxonomy used to categorize existing smart contract-based solutions. In Sections 5–8, we present existing advances in modeling-driven smart contract improvement, optimization-driven smart contract improvement, resource-driven smart contract usage, and cross-organizational collaboration-driven smart contract usage. Section 9 discusses the study results by introducing challenges and future trends in the studied field. Finally, Section 10 concludes the paper.


Background
As aforementioned, blockchain technology has emerged as a distributed computing paradigm that successfully overcomes the problem related to the trust of a centralized party. Thus, in a blockchain network, several nodes collaborate among them to secure and maintain a set of shared transaction records in a distributed way without relying on any trusted party. Specific nodes in the network known as miners are responsible for adding new blocks to a distributed public ledger known as the blockchain.
The first system was Bitcoin [69], which allowed users to transfer securely the currency (bitcoins) without a centralized regulator. In the blockchain network, miners are responsible for collecting transactions, solving challenging computational puzzles (proof-of-work) in order to reach consensus, and adding the transactions as blocks to the blockchain. Since then, several blockchain-based development platforms have been proposed offering the ability to host/ use smart contracts to execute automatically events and actions., namely NXT [71], Ethereum [16], Hyperledger Fabric [4], etc.
We detail below the smart contract operational process and then discuss some blockchain platforms that support the development of smart contracts.
Operational process of smart contracts
A smart contract is a common agreement between two or more parties. It stores information, processes inputs, and writes outputs thanks to its pre-defined functions [16]. For instance, the smart contract can define the constructor function that enables the smart contract creation. Hosting a new smart contract in the blockchain is enabled by invoking the constructor function through a transaction, whose sender becomes the smart contract owner. A self-destruct function is another example of the functions that can be defined in a smart contract. Usually, only the smart contract owner can destruct the contract by invoking this function.
A smart contract is likely to be a class that includes state variables, functions, function modifiers, events, and structures [16] which is intended to execute and control relevant events and actions according to the contract terms. Besides, it can even call other smart contracts. Each smart contract includes states and functions. The former are variables that hold some data or the owner’s wallet address (i.e., the address in which the smart contract is deployed). We can distinguish between two state types, namely constant states, which can never be changed, and writable states, which save states in the blockchain. The latter are pieces of code that can read or modify states. We can distinguish between two function types, namely read-only functions, which do not require gas Footnote 2 to run and write functions that require gas because the state transitions must be encoded in a new block of the blockchain. Furthermore, paying currency is required to avoid infinitely smart contract runs.
As aforementioned, a smart contract is hosted in the blockchain by invoking its constructor function through a transaction submitted to the blockchain network, then the constructor function is executed, and the final code of the smart contract is stored on the blockchain. Once deployed, the creator of the smart contract got the returned parameters (e.g., contract address), then users can invoke any available smart contract’s function by sending a transaction.
Platforms for Smart Contracts
Smart contracts can be developed and deployed in different blockchain platforms (e.g., NXT, Ethereum, and Hyperledger Fabric). Several platforms offer distinctive features for developing smart contracts including contract programming languages, contract code execution, and security levels. Some platforms support high-level programming languages to develop smart contracts. 

	
                  Bitcoin [69] is a public blockchain platform that can be used to process cryptocurrency transactions, but with a very limited computing capability. Bitcoin uses a stack-based bytecode scripting language. The ability to create a smart contract with rich logic using the Bitcoin scripting language is very limited. Major changes would need to be made to both the mining functions and the mining incentivization schemes to enable smart contracts proper on Bitcoin’s blockchain [52].

                
	
                  NXT [71] is an open-source blockchain platform that relies entirely on a proof-of-stake consensus protocol. It includes a selection of smart contracts that are currently living. However, it is not Turing-complete, meaning only the existing templates can be used and no personalized smart contract can be deployed.

                
	
                  Ethereum [16] is the first blockchain platform for developing smart contracts. It supports advanced and customized smart contracts with the help of a Turing-complete virtual machine, called the Ethereum virtual machine (EVM). EVM is the runtime environment for smart contracts, and every node in the Ethereum network runs an EVM implementation and executes the same instructions. Solidity, as a high-level programming language, is used to write smart contracts, and the contract code is compiled down to EVM bytecode and deployed on the blockchain for execution. Ethereum is currently the most popular development platform for smart contracts and can be used to design various kinds of decentralized applications (DApps) in several domains.

                
	
                  Rather than the public blockchain, such as Bitcoin and Ethereum that any party can participate in the network, Hyperledger Fabric [4] is permissioned with only a collection of business-related organizations can join in through a membership service provider, and its network is built up from the peers whose are owned and contributed by those organizations. Hyperledger Fabric is an open-source enterprise-grade distributed ledger technology platform, proposed by IBM and supports smart contracts. It offers modularity and versatility for a broad set of industry use cases. The modular architecture for Hyperledger Fabric accommodates the diversity of enterprise use cases through plug and play components.

                

Ethereum and Hyperledger Fabric smart contracts differ in multiple aspects. While Solidity is the well-known programming language used to write Ethereum smart contracts, Hyperledger Fabric supports multi-language smart contracts, such as Go, Java, and Javascript [4]. For contract code execution, the contract code in Ethereum is included in a transaction, which is propagated in the peer-to-peer network, and any miner that receives this transaction can execute it in its local virtual machine [16]. In Hyperledger Fabric, when a transaction is created by the application, the transaction is only executed and signed by specified peers (endorsing peers). After receiving the application’s transaction proposal, each of these endorsing peers independently executes it by invoking the chain-code to which the transaction refers [4]. For security, chaincode runs within a container environment (e.g., Docker) for isolation.
These blockchain-based development platforms are used in the existing studies that we detail in the following sections.


Related literature reviews/surveys
We provide a brief overview of the existing reviews that have studied blockchain-enabled smart contracts.
While several literature reviews/surveys are published in order to study the blockchain-enabled smart contracts, there are still some ongoing challenges that have not been addressed. Table 1 presents a comparative summary of the existing blockchain-enabled smart contract reviews/surveys according to six criteria, namely proposing a taxonomy, considering several blockchain platforms, considering application domains, covering smart contract improvement tools, identifying research gaps, and scope of literature review. We observe that there is a lack of taxonomy focusing on smart contract improvement (i.e., addressing smart contract security, privacy, and performance issues) and smart contract usage (i.e., addressing domain-specific issues).

Table 1 Existing smart contract Reviews/Surveys: A comparative summaryFull size table

To sum up, it can be said that the existing surveys concerning blockchain-enabled smart contracts focus on classifying the papers based on smart contract issues. Our work extends the existing surveys by studying the smart contract application domains, analyzing the smart contract challenges, and introducing some research gaps that need to be addressed in future studies.


Research Methodology and Solution Taxonomy
We describe below the adopted research methodology, such as the search strategy, filtering process, and inclusion and exclusion criteria. Besides, we present the solution taxonomy used to categorize the final set of included papers.
Systematic Literature Review
We used three existing databases, namely ScienceDirect, IEEEXplore, and ACM Digital Library to search for relevant works using the “smart contract” string keyword. In the first phase, we found 523 publications as shown in both Fig. 1a, which depicts the percentage of the acquired research paper per digital database as well as Fig. 1b, which depicts the total number of preliminary studies acquired from each digital database.

Fig. 1[image: figure1]
Publication trend


Full size image

To choose the relevant papers to be analyzed in our review, we filtered the primary studies retrieved from the databases. To do so, we defined a set of inclusion and exclusion criteria, which are summarised in Table 2. Based on the outcomes of the first phase, we applied the set of inclusion and exclusion criteria to exclude the publications considered outside the scope of this review. Thus, we only included studies that satisfy all the inclusion criteria. We excluded duplicate publications, surveys, and literature reviews by filtering studies based on the title, the abstract, and the list of keywords.

Table 2 Inclusion and exclusion criteria for relevant worksFull size table

As a result of the filtering process, we excluded 323 publications and included 200 relevant publications for this systematic review. Figure 1b depicts also the number of the relevant studies included in this research from each digital database.
Publication trends and Categorization
To examine the trend of the smart contract field in terms of the publication date, Fig. 2 depicts the number of included studies published each year from 2015 to September 2020. We observe that the total number of published papers in the studied field increases in the past few years, indicating the importance of the topic. Thus, the smart contract field is rapidly growing in recent years.

Fig. 2[image: figure2]
Included articles per year


Full size image

As a result of an in-depth analysis of the included studies in this review, a comprehensive taxonomy is constructed to provide an additional support for designers to understand the various dimensions that they have to consider when designing a smart contract. The major motivations of this survey are to identify (i) the main publications about smart contracts, (ii) the current state of research in this field, and (iii) possible gaps in the literature that could become research problems to be solved by the scientific community. Through this survey, we aspire not only to define the conceptual background of blockchain-enabled smart contracts, but also to identify research issues to be explored at new studies. Indeed, we categorize existing smart contract research into two major categories, namely smart contract improvement and smart contract usage. The former includes studies aiming at addressing the smart contract challenges, such as functionality verification, performance, vulnerabilities, and lack of trustworthy data feeding. The latter includes studies aiming at addressing domain-specific challenges using smart contracts. Figure 3 depicts the proposed taxonomy of blockchain-enabled smart contracts, including modeling-driven smart contract improvement (see Section 5), optimization-driven smart contract improvement (see Section 6), resource-driven smart contract usage (see Section 7), and cross-organizational collaboration-driven smart contract usage (see Section 8).

Fig. 3[image: figure3]
Taxonomy of blockchain-enabled smart contract based studies


Full size image



Modeling-driven smart contract improvement
Smart contracts have suffered from multiple security vulnerabilities in the past few years [8], which have resulted in both theft and gigantic financial losses. Such vulnerabilities could have been avoided with the help of formal analysis and verification of such smart contracts before deploying them on the blockchain. Since existing programming languages, such as Solidity are not built for formal verification, several researchers have proposed alternative approaches in order to improve the smart contract functionality verification. In this category, we discussed modeling-driven smart contract improvement solutions, which can be categorized into programming-centric solutions (see Table 3) and formal verification-centric solutions (see Table 4).

Table 3 Some examples of programming-centric solutionsFull size table

Table 4 Some examples of formal verification-centric solutionsFull size table

Programming-centric solutions
The essence of a smart contract is the computer code that can be executed automatically on the computer, so programming smart contracts correctly is an important research direction. Several researchers argued that developing new contract languages is an effective way to write a correct smart contract. Table 3 presents some newly proposed programming languages such as SmaCoNat [78], Flint [83], and Scilla [85]. For instance, Regnath and Steinhorst [78] proposed a human-readable, security, and executable programming language, called SmaCoNat. The authors converted programming language grammar into natural language sentences in order to improve program readability.
New contract languages promised to address the existing domain-specific language vulnerabilities. However, since they have not been put into practice, they could have their vulnerabilities. Thus, designing and implementing secure smart contracts still require adaptive software engineering technologies and expertise from multiple research domains, such as networking, programming languages, formal methods, and cryptography.

Formal verification-centric solutions
Typically, formal testing is applied to ensure that a software behaves and performs as expected in its specifications and requirements based on all possible inputs’ conditions. For smart contracts, Truffle [93], is an example of a development framework for Ethereum that enables writing formal test cases based on certain mathematical logic and rules for smart contracts written in JavaScript or Solidity languages. These test cases can be written in JavaScript and can be executed on a test network to check several properties of smart contracts. As aforementioned, formal testing can only make sure that a smart contract did what it is supposed to do based on its specification, however, it cannot help the smart contract developers to find bugs or vulnerabilities. Therefore, automated formal verification is a promising approach to detect bugs and other errors to guarantee the functional correctness of smart contracts. According to [2], formal verification can provide the highest level of confidence in the correct behavior of smart contracts. At present, the use of formal methods to verify smart contracts has been widely adopted by several researchers, and significant results have been achieved in practice. Table 4 presents some formal verification-centric solutions. For instance, Amani et al. [2] extended an existing EVM formalization in Isabelle/HOL by a sound program logic at the level of bytecode. The principle of the method is to organize the bytecode sequences into linear code blocks and create a logic program, where each block is processed as a set of instructions. Each part of the verification is validated in a single trusted logical framework from the perspective of bytecode.
Currently, formal verification tools are still in the experimental stage and have not been widely used. Therefore, the smart contract formalization research direction deserves a lot of attention, thus it provides the highest level of confidence about the correct behavior of smart contracts. Real progress in this research field can improve trust in the smart contract, especially when used to develop critical systems, such as financial, healthcare, and banking systems.


Optimization-driven smart contract improvement
Smart contracts have emerged as a new promising solution for developing fully decentralized applications without involving a trusted third-party. Despite the bright side of smart contracts, several concerns continue to undermine their adoption, namely performance issues, security threats, and privacy issues. Indeed, new smart contract applications are more demanding in terms of contract execution time, execution cost, security, and privacy fields. In this category, we discuss optimization-driven smart contract improvement solutions, which can be categorized into performance optimization-centric solutions (see Table 5) and security optimization-centric solutions (see Table 6).

Table 5 Some examples of performance optimization-centric solutionsFull size table

Table 6 Some examples of security optimization-centric solutionsFull size table

Performance optimization-centric solutions
Smart contract performance refers to the ability of smart contract systems to deliver in a reasonable response time and sustain performance when the number of contracts is increasing [1]. Table 5 presents some examples of performance optimization-centric solutions. Some performance issues in blockchain systems, not limited to, are throughput bottleneck, limited scalability, transactions latency. To overcome performance issues in smart contract systems, some researchers have proposed solutions to execute smart contracts in parallel instead of sequentially [26, 34]. For instance, Gao et al. [34] have proposed a parallel execution scheme that relies on two key techniques, namely a fair contract partition algorithm leveraging integer linear programming to partition a set of smart contracts into multiple subsets, and a random assignment protocol assigning subsets randomly to a subgroup of users. Other studies have been proposed for smart contract optimization by saving gas. In fact, if the smart contract execution exceeds an amount of gas (known as gas limit), an out-of-gas exception is raised, interrupting the current execution. For instance, GasReducer [18] is a tool for automatically detecting EVM operation sequences that can be replaced with other operations that have the same semantics but need less gas, and then replacing them with efficient code.
Security optimization-centric solutions
Security of a smart contract refers to its robustness against attacks from malicious users that exploit generally the contract security vulnerabilities to gain profit or the lack of trustworthy data feeding to inject malicious data. Table 6 presents some examples of vulnerability detection tools, transactional privacy models, and trustworthy data feeding solutions.
Vulnerability Detection
Discovering potential vulnerabilities in the execution of contracts is important to improve the security and credibility of contracts. Indeed, several studies systematically summarized the contract vulnerabilities and analyzed the security risks [8, 77, 81]. For instance, Atzei et al. [8] have provided a taxonomy of smart contract vulnerabilities of three levels, namely Solidity, EVM, and Blockchain. In recent years, the most notorious attack is the Decentralized Autonomous Organization (DAO) attack that exploited a re-entrancy vulnerability to steal around 2 Million Ether from a smart contract [103]. Another attack has happened to the SmartBillions, which presented a fully decentralized and transparent lottery system when an attacker successfully manipulated the block hash of the smart contract’s lottery function twice, and forced the result in his favor to get 400 Ether [62]. To solve the smart contract vulnerabilities, several vulnerability detection solutions have been proposed. Some studies have given solutions to common vulnerabilities, such as Oyente [59], SmartInspect [15], and ContractFuzzer [47]. Some other work focused on specific vulnerabilities, such as ReGuard [54] to detect re-entrancy bugs and EthRacer [48] to detect event-ordering bugs.
Transactional privacy
The privacy issue represents a real challenge for smart contracts to keep critical functions secret, apply cryptography, and avoid disclosing data on the blockchain to the public. The lack of transactional privacy could limit the adoption of smart contracts. To address this issue, Kosba et al. [49] have proposed Hawk, a decentralized smart contract system. Hawk is a tool allowing smart contract developers to build privacy-preserving contracts without the need for implementing any cryptography. Its compiler automatically generated an efficient cryptographic protocol where contractual parties interact with the blockchain, using cryptographic primitives such as zero-knowledge proofs.
Trustworthy data feeding
The smart contract execution requires some external data about real-world states and events from outside the blockchain. Therefore, trustworthy data feeding mechanisms (known as Oracles) are required to build a bridge between blockchain and the external world (e.g., Web API). For instance, Zhang et al. [113] have proposed Town Crier, which acted as a link between existing commonly trusted non-blockchain based websites and smart contracts to provide authenticated data to smart contracts while preserving confidentiality with encrypted parameters. However, in case of malicious code or bad data fed to a smart contract, the latter processes the input as is, producing an incorrect and unpredictable outcome. Thus, oracles retain an enormous amount of power over smart contracts in how they are executed because the data they provide determines how the smart contracts execute.
To sum up, research on improving smart contract security and performance has emerged in recent years. While running smart contracts in parallel can speed up contract execution, it faces a challenge in how to execute contracts that depend on each other at the same time. Moreover, optimizing smart contract codes can effectively reduce potential vulnerabilities in contracts and ensure efficient and secure execution of contracts. However, the existing studies are still immature, and unknown vulnerabilities or bugs cannot be detected to be replaced. Thus, the optimization of smart contracts needs further research.
After discussing the smart contract from the technical point of view, we present in the following two sections the existing solutions focusing on smart contract usage in several domains.


Resource-driven smart contract usage
As we know, smart contracts are executable code hosted in the blockchain that store information, process inputs, and write outputs thanks to their pre-defined functions. They are used to improve data handling transparency, decentralize resource-constrained device management, and enable changes of the agreement terms at runtime while running on top of a decentralized and transparent n";"""dc.publisher"",""Springer""
""og:image"",""https://media.springernature.com/w200/springer-static/cover/journal/12083.jpg""
""twitter:card"",""summary""
""og:site_name"",""Peer-to-Peer Networking and Applications""
""citation_reference"",""Alharby M, Aldweesh A, van Moorsel A (2018) Blockchain-based smart contracts: A systematic mapping study of academic research (2018). In: 2018 International Conference on Cloud Computing, Big Data and Blockchain (ICCBB), IEEE, pp 1–6"",""Amani S, Bégel M, Bortin M, Staples M (2018) Towards verifying ethereum smart contract bytecode in isabelle/hol. In: Proceedings of the 7th ACM SIGPLAN International Conference on Certified Programs and Proofs. Association for Computing Machinery, New York, pp 66–77"",""Analytics TC Ripple xrp continue to revolutionize cross border payment systems. Available online at                  https://thecurrencyanalytics.com/11696/ripple-xrp-continue-to-revolutionize-cross-border-payment-systems                                                 https://thecurrencyanalytics.com/11696/ripple-xrp-continue-to-revolutionize-cross-border-payment-systems                                 (2020). Last accessed: 2020-10-03"",""Androulaki E, Barger A, Bortnikov V, Cachin C, Christidis K, De Caro A, Enyeart D, Ferris C, Laventman G, Manevich Y et al (2018) Hyperledger fabric: A distributed operating system for permissioned blockchains. In: Proceedings of the Thirteenth EuroSys Conference, ACM, pp 30"",""Angelo MD, Salzer G (2019) A survey of tools for analyzing ethereum smart contracts. In: IEEE International Conference on Decentralized Applications and Infrastructures, DAPPCON 2019, newark, CA, USA, April 4-9, 2019, IEEE, pp 69–78"",""citation_journal_title=Procedia Manufacturing; citation_title=A case study for blockchain in manufacturing: “fabrec”: A prototype for peer-to-peer network of manufacturing nodes; citation_author=A Angrish, B Craver, M Hasan, B Starly; citation_volume=26; citation_publication_date=2018; citation_pages=1180-1192; citation_doi=10.1016/j.promfg.2018.07.154; citation_id=CR6"",""Asgaonkar A, Krishnamachari B (2019) Solving the buyer and seller’s dilemma: A dual-deposit escrow smart contract for provably cheat-proof delivery and payment for a digital good without a trusted mediator. In: 2019 IEEE International Conference on Blockchain and Cryptocurrency (ICBC)"",""Atzei N, Bartoletti M, Cimoli T (2017) A survey of attacks on ethereum smart contracts (sok). In: International Conference on Principles of Security and Trust, Springer, pp 164–186"",""Bader L, Bürger JC, Matzutt R, Wehrle K (2018) Smart contract-based car insurance policies. In: 2018 IEEE Globecom workshops (GC wkshps), pp 1–7"",""Bai X, Cheng Z, Duan Z, Hu K (2018) Formal modeling and verification of smart contracts. In: Proceedings of the 2018 7th International Conference on Software and Computer Applications. Association for Computing Machinery, New York, pp 322–326"",""Baralla G, Pinna A, Corrias G (2019) Ensure traceability in european food supply chain by using a blockchain system. In: Proceedings of the 2nd International Workshop on Emerging Trends in Software Engineering for Blockchain, IEEE Press, pp 40–47"",""Bartoletti M, Pompianu L (2017) An empirical analysis of smart contracts: Platforms, applications, and design patterns. In: International Conference on Financial Cryptography and Data Security, Springer, pp 494–509"",""Bertini T, Butkute K, Canessa F Smart flight insurance—insureth. Available online at                  http://mkvd.s3.amazonaws.com/apps/InsurEth.pdf                                 (2015). Last accessed: 2020-10-10"",""Bogner A, Chanson M, Meeuw A (2016) A decentralised sharing app running a smart contract on the ethereum blockchain. In: Proceedings of the 6th International Conference on the Internet of Things. Association for Computing Machinery, New York, pp 177–178"",""Bragagnolo S, Rocha H, Denker M, Ducasse S (2018) Smartinspect: Solidity smart contract inspector. In: 2018 International workshop on blockchain oriented software engineering (IWBOSE), pp 9–18"",""Buterin V et al (2014) A next-generation smart contract and decentralized application platform. White paper"",""citation_journal_title=Procedia Comput Sci; citation_title=How blockchain improves the supply chain: Case study alimentary supply chain; citation_author=R Casado-Vara, J Prieto, FD [la Prieta], JM Corchado; citation_volume=134; citation_publication_date=2018; citation_pages=393-398; citation_doi=10.1016/j.procs.2018.07.193; citation_id=CR17"",""Chen T, Li Z, Zhou H, Chen J, Luo X, Li X, Zhang X (2018) Towards saving money in using smart contracts. In: Proceedings of the 40th International Conference on Software Engineering: New Ideas and Emerging Results. Association for Computing Machinery, New York, pp 81–84"",""Cheng S, Shi W, Zhang H (2019) Voltimebank: A volunteer system for mutual pension based on blockchain. In: Proceedings of the 2019 International Conference on Blockchain Technology. Association for Computing Machinery, New York, pp 75–79"",""Ciocarlie G, Eldefrawy K, Lepoint T (2018) Blockcis—a blockchain-based cyber insurance system. In: Proceedings of the 2018 IEEE International Conference on Cloud Engineering (IC2E), Orlando, FL, USA, pp 17–20"",""citation_journal_title=I J Law Inform Technol; citation_title=Beyond bitcoin: An early overview on smart contracts; citation_author=P Cuccuru; citation_volume=25; citation_issue=3; citation_publication_date=2017; citation_pages=179-195; citation_doi=10.1093/ijlit/eax003; citation_id=CR21"",""citation_journal_title=Sustainable Cities and Society; citation_title=Ancile: Privacy-preserving framework for access control and interoperability of electronic health records using blockchain technology; citation_author=GG Dagher, J Mohler, M Milojkovic, PB Marella; citation_volume=39; citation_publication_date=2018; citation_pages=283-297; citation_doi=10.1016/j.scs.2018.02.014; citation_id=CR22"",""Dangl A Top trends 2020: Hyperautomation and smart contracts. Available online at                  https://www.fabasoft.com/en/news/blog/top-trends-2020-hyperautomation-and-smart-contracts                                 (2019). Last accessed: 2020-10-07"",""Dasaklis TK, Casino F, Patsakis C (2019) Defining granularity levels for supply chain traceability based on iot and blockchain. In: Proceedings of the International Conference on Omni-Layer Intelligent Systems. Association for Computing Machinery, New York, pp 184–190"",""DHarz D, Knottenbelt W (2018) Towards safer smart contracts: A survey of languages and verification methods. arXiv preprint arXiv:                 1809.09805                                "",""citation_journal_title=Distrib Comput; citation_title=Adding concurrency to smart contracts; citation_author=T Dickerson, P Gazzillo, M Herlihy, E Koskinen; citation_volume=33; citation_publication_date=2019; citation_pages=1-17; citation_id=CR26"",""Dryja T, Glasbergen G-J, Lovejoy J Layer 2 - the lightning network. Available online at                  https://dci.mit.edu/lightning-network/                                 (2019). Last accessed: 2020-10-20"",""Dziembowski S, Eckey L, Faust S (2018) Fairswap: How to fairly exchange digital goods. In: Proceedings of the 2018 ACM SIGSAC Conference on Computer and Communications Security. Association for Computing Machinery, New York, pp 967–984"",""Ellul J, Pace GJ (2018) Alkylvm: A virtual machine for smart contract blockchain connected internet of things. In: 2018 9Th IFIP International Conference on New Technologies, Mobility and Security (NTMS), pp 1–4"",""citation_journal_title=J Syst Archit; citation_title=A blockchain-based attribute-based signcryption scheme to secure data sharing in the cloud; citation_author=N Eltayieb, R Elhabob, A Hassan, F Li; citation_volume=102; citation_publication_date=2020; citation_pages=101653; citation_doi=10.1016/j.sysarc.2019.101653; citation_id=CR30"",""Fabasoft: Fabasoft contracts. Available online at                  https://www.fabasoft.com/en/products/fabasoft-contracts                                 (2020). Last accessed: 2020-10-07"",""Farooq MS, Khan M, Abid A (2020) A framework to make charity collection transparent and auditable using blockchain technology, vol 83"",""Feng X, Wang Q, Zhu X, Wen S (2019) Bug searching in smart contract. arXiv preprint arXiv:                 1905.00799                                "",""Gao Z, Xu L, Chen L, Shah N, Lu Y, Shi W (2017) Scalable blockchain based smart contract execution. In: 2017 IEEE 23Rd international conference on parallel and distributed systems (ICPADS), pp 352–359"",""citation_journal_title=Official Journal of the European Union (OJ); citation_title=Regulation (eu) 2016/679 of the european parliament and of the council of 27 april 2016 on the protection of natural persons with regard to the processing of personal data and on the free movement of such data, and repealing directive 95/46; citation_author=; citation_volume=59; citation_publication_date=2016; citation_pages=1-88; citation_id=CR35"",""Guo H, Meamari E, Shen CC (2019) Multi-authority attribute-based access control with smart contract. In: Proceedings of the 2019 International Conference on Blockchain Technology. Association for Computing Machinery, New York, pp 6–11"",""citation_journal_title=IEEE Access; citation_title=Smart contract privacy protection using ai in cyber-physical systems: Tools, techniques and challenges; citation_author=R Gupta, S Tanwar, F Al-Turjman, P Italiya, A Nauman, SW Kim; citation_volume=8; citation_publication_date=2020; citation_pages=24746-24772; citation_doi=10.1109/ACCESS.2020.2970576; citation_id=CR37"",""Han S, Xu Z, Zeng Y, Chen L (2019) Fluid: A blockchain based framework for crowdsourcing. In: Proceedings of the 2019 International Conference on Management of Data. Association for Computing Machinery, New York, pp 1921–1924"",""citation_journal_title=Comput Ind Eng; citation_title=Smart contract-based approach for efficient shipment management; citation_author=H Hasan, E AlHadhrami, A AlDhaheri, K Salah, R Jayaraman; citation_volume=136; citation_publication_date=2019; citation_pages=149-159; citation_doi=10.1016/j.cie.2019.07.022; citation_id=CR39"",""citation_journal_title=NIST special publication; citation_title=Guide to attribute based access control (abac) definition and considerations (draft); citation_author=VC Hu, D Ferraiolo, R Kuhn, AR Friedman, AJ Lang, MM Cogdell, A Schnitzer, K Sandlin, R Miller, K Scarfone; citation_volume=800; citation_issue=162; citation_publication_date=2013; citation_pages=1-54; citation_id=CR40"",""Hu Y, Liyanage M, Mansoor A, Thilakarathna K, Jourjon G, Seneviratne A (2018) Blockchain-based smart contracts-applications and challenges. arXiv preprint arXiv:                 1810.04699                                "",""Hwang GH, Tien PC, Tang YH (2020) Blockchain-based automatic indemnification mechanism based on proof of violation for cloud storage services. In: Proceedings of the 2020 The 2nd International Conference on Blockchain Technology. Association for Computing Machinery, New York, pp 90–94"",""citation_journal_title=ACM Trans. Des. Autom. Electron. Syst; citation_title=Enabling ic traceability via blockchain pegged to embedded puf; citation_author=MN Islam, S Kundu; citation_volume=24; citation_issue=3; citation_publication_date=2019; citation_pages=1-23; citation_doi=10.1145/3315669; citation_id=CR43"",""Javaid U, Aman MN, Sikdar B (2018) Blockpro: Blockchain based data provenance and integrity for secure iot environments. In: Proceedings of the 1st Workshop on Blockchain-Enabled Networked Sensor Systems. Association for Computing Machinery, New York, pp 13–18"",""Javaid U, Siang AK, Aman MN, Sikdar B (2018) Mitigating lot device based ddos attacks using blockchain. In: Proceedings of the 1st Workshop on Cryptocurrencies and Blockchains for Distributed Systems. Association for Computing Machinery, New York, pp 71–76"",""Jentzsch C (2016) Decentralized autonomous organization to automate governance. White paper"",""Jiang B, Liu Y, Chan WK (2018) Contractfuzzer: Fuzzing smart contracts for vulnerability detection. In: Proceedings of the 33rd ACM/IEEE International Conference on Automated Software Engineering. Association for Computing Machinery, New York, pp 259–269"",""Kolluri A, Nikolic I, Sergey I, Hobor A, Saxena P (2019) Exploiting the laws of order in smart contracts. In: Proceedings of the 28th ACM SIGSOFT International Symposium on Software Testing and Analysis. Association for Computing Machinery, New York, pp 363–373"",""Kosba A, Miller A, Shi E, Wen Z, Papamanthou C (2016) Hawk: The blockchain model of cryptography and privacy-preserving smart contracts. In: 2016 IEEE Symposium on security and privacy (SP), IEEE, pp 839–858"",""citation_journal_title=J Clean Prod; citation_title=Makerchain: A blockchain with chemical signature for self-organizing process in social manufacturing; citation_author=J Leng, P Jiang, K Xu, Q Liu, JL Zhao, Y Bian, R Shi; citation_volume=234; citation_publication_date=2019; citation_pages=7676778; citation_doi=10.1016/j.jclepro.2019.06.265; citation_id=CR50"",""Levi SD, Lipton AB (2018) An introduction to smart contracts and their potential and inherent limitations. In: Harvard law school forum on corporate governance & financial regulation"",""Lewis A A gentle introduction to smart contracts. Available online at                  https://bitsonblocks.net/2016/02/01/gentle-introduction-smart-contracts/                                                 https://bitsonblocks.net/2016/02/01/gentle-introduction-smart-contracts/                                 (2016). Last accessed: 2020-10-07"",""Lin J, Shen Z, Zhang A, Chai Y (2018) Blockchain and iot based food traceability for smart agriculture. In: Proceedings of the 3rd International Conference on Crowd Science and Engineering. Association for Computing Machinery, New York"",""Liu C, Liu H, Cao Z, Chen Z, Chen B, Roscoe B (2018) Reguard: Finding reentrancy bugs in smart contracts. In: Proceedings of the 40th International Conference on Software Engineering: Companion Proceeedings. Association for Computing Machinery, New York, pp 65–68"",""citation_journal_title=IEEE Access; citation_title=Electric vehicle power trading mechanism based on blockchain and smart contract in v2g network; citation_author=H Liu, Y Zhang, S Zheng, Y Li; citation_volume=7; citation_publication_date=2019; citation_pages=160546-160558; citation_doi=10.1109/ACCESS.2019.2951057; citation_id=CR55"",""citation_journal_title=IEEE Access; citation_title=A survey on security verification of blockchain smart contracts; citation_author=J Liu, Z Liu; citation_volume=7; citation_publication_date=2019; citation_pages=77894-77904; citation_doi=10.1109/ACCESS.2019.2921624; citation_id=CR56"",""citation_journal_title=Futur Gener Comput Syst; citation_title=Elastic and cost-effective data carrier architecture for smart contract in blockchain; citation_author=X Liu, K Muhammad, J Lloret, YW Chen, SM Yuan; citation_volume=100; citation_publication_date=2019; citation_pages=590-599; citation_doi=10.1016/j.future.2019.05.042; citation_id=CR57"",""Loukil F, Ghedira-Guegan C, Boukadi K, Benharkat AN (2018) Towards an end-to-end iot data privacy-preserving framework using blockchain technology. In: International Conference on Web Information Systems Engineering. Springer, Berlin, pp 68–78"",""Luu L, Chu DH, Olickel H, Saxena P, Hobor A (2016) Making smart contracts smarter. In: Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security. Association for Computing Machinery, New York, pp 254–269"",""citation_journal_title=Telematics Inform; citation_title=Smart contract applications within blockchain technology: A systematic mapping study; citation_author=D Macrinici, C Cartofeanu, S Gao; citation_volume=35; citation_issue=8; citation_publication_date=2018; citation_pages=2337-2354; citation_doi=10.1016/j.tele.2018.10.004; citation_id=CR60"",""citation_journal_title=Computers & Security; citation_title=A blockchain based approach for the definition of auditable access control systems; citation_author=DDF Maesa, P Mori, L Ricci; citation_volume=84; citation_publication_date=2019; citation_pages=93-119; citation_doi=10.1016/j.cose.2019.03.016; citation_id=CR61"",""Memoria F Smartbillions challenges hackers with 1,500 ether reward, gets hacked and pulls most of it out. Available online at                  https://www.ccn.com/smartbillions-challenges-hackers-1500-ether-reward-gets-hacked-pulls/                                                 https://www.ccn.com/smartbillions-challenges-hackers-1500-ether-reward-gets-hacked-pulls/                                 (2017). Last accessed: 2020-10-20"",""Meng W, Wang J, Wang X, Liu J, Yu Z, Li J, Zhao Y, Chow SS (2018) Position paper on blockchain technology: Smart contract and applications. In: International Conference on Network and System Security, Springer, pp 474–483"",""Meskini F, Islamic RA (2019) Multi-agent based simulation of a smart insurance using blockchain technology. In: 2019 Third International Conference on Intelligent Computing in Data Sciences (ICDS), IEEE, pp 1–6"",""Missier P, Bajoudah S, Capossele A, Gaglione A, Nati M (2017) Mind my value: A decentralized infrastructure for fair and trusted iot data trading. In: Proceedings of the Seventh International Conference on the Internet of Things. Association for Computing Machinery, New York"",""Mohanta BK, Panda SS, Jena D (2018) An overview of smart contract and use cases in blockchain technology. In: 9Th international conference on computing, communication and networking technologies, ICCCNT 2018, bengaluru, india, july 10-12, 2018, IEEE, pp 1–4"",""citation_journal_title=Int J Manag Appl Res; citation_title=The application of blockchain technology in crowdfunding: Towards financial inclusion via technology; citation_author=A Muneeza, NA Arshad, AT Arifin; citation_volume=5; citation_issue=2; citation_publication_date=2018; citation_pages=82-98; citation_doi=10.18646/2056.52.18-007; citation_id=CR67"",""Murray Y, Anisi DA (2019) Survey of formal verification methods for smart contracts on blockchain. In: 10Th IFIP international conference on new technologies, mobility and security, NTMS 2019, canary islands, spain, june 24-26, 2019, IEEE, pp 1–6"",""Nakamoto S Bitcoin: A peer-to-peer electronic cash system. Available online at                  https://bitcoin.org/bitcoin.pdf                                 (2008). Last accessed: 2020-10-20"",""citation_journal_title=Comput Electr Eng; citation_title=Decentralized document version control using ethereum blockchain and ipfs; citation_author=N Nizamuddin, K Salah, MA Azad], J Arshad, M Rehman; citation_volume=76; citation_publication_date=2019; citation_pages=183-197; citation_doi=10.1016/j.compeleceng.2019.03.014; citation_id=CR70"",""Nxt community: Nxt whitepaper. Available online at                  https://nxtdocs.jelurida.com/Nxt_Whitepaper                                 (2016). Last accessed: 2020-10-07"",""citation_journal_title=Futur Gener Comput Syst; citation_title=Privacy-friendly platform for healthcare data in cloud based on blockchain environment; citation_author=AA Omar, MZA Bhuiyan, A Basu, S Kiyomoto, MS Rahman; citation_volume=95; citation_publication_date=2019; citation_pages=511-521; citation_doi=10.1016/j.future.2018.12.044; citation_id=CR72"",""citation_journal_title=Pervasive and Mobile Computing; citation_title=Model checking smart contracts for ethereum; citation_author=T Osterland, T Rose; citation_volume=63; citation_publication_date=2020; citation_pages=101129; citation_doi=10.1016/j.pmcj.2020.101129; citation_id=CR73"",""Ouaddah A, Elkalam AA, Ouahman AA (2017) Harnessing the power of blockchain technology to solve iot security & privacy issues. In: Proceedings of the Second International Conference on Internet of Things, Data and Cloud Computing, ICC’17. Association for Computing Machinery, New York"",""citation_journal_title=IEEE Trans Eng Manag; citation_title=A smart contract system for decentralized borda count voting; citation_author=S Panja, S Bag, F Hao, B Roy; citation_volume=67; citation_issue=4; citation_publication_date=2020; citation_pages=1323-1339; citation_doi=10.1109/TEM.2020.2986371; citation_id=CR75"",""Poon J, Buterin V (2017) Plasma: Scalable autonomous smart contracts, pp 283–295"",""Praitheeshan P, Pan L, Yu J, Liu J, Doss R (2019) Security analysis methods on ethereum smart contract vulnerabilities: A survey. arXiv preprint arXiv:                 1908.08605                                "",""Regnath E, Steinhorst S (2018) Smaconat: Smart contracts in natural language. In: 2018 Forum on specification & design languages (FDL), IEEE, pp 5–16"",""citation_journal_title=Future Gener Comput Syst; citation_title=On blockchain and its integration with iot. challenges and opportunities; citation_author=A Reyna, C Martín, J Chen, E Soler, M Díaz; citation_volume=88; citation_publication_date=2018; citation_pages=173-190; citation_doi=10.1016/j.future.2018.05.046; citation_id=CR79"",""Rieth Y Payment systems: Visa vs. bitcoin. Available online at                  https://decenter.org/en/payment-systems-visa-vs-bitcoin                                 (2018). Last accessed: 2020-10-10"",""citation_journal_title=IEEE Access; citation_title=Security, performance, and applications of smart contracts: A systematic survey; citation_author=S Rouhani, R Deters; citation_volume=7; citation_publication_date=2019; citation_pages=50759-50779; citation_doi=10.1109/ACCESS.2019.2911031; citation_id=CR81"",""Saleh H, Avdoshin S, Dzhonov A (2019) Platform for tracking donations of charitable foundations based on blockchain technology. In: 2019 Actual problems of systems and software engineering (APSSE), IEEE, pp 182–187"",""Schrans F, Eisenbach S, Drossopoulou S (2018) Writing safe smart contracts in flint. In: Conference companion of the 2nd international conference on art, science, and engineering of programming, pp 218–219"",""Scoca V, Uriarte RB, De Nicola R (2017) Smart contract negotiation in cloud computing. In: 2017 IEEE 10Th international conference on cloud computing (CLOUD), pp 592–599"",""Sergey I, Nagaraj V, Johannsen J, Kumar A, Trunov A, Hao KCG (2019) Safer smart contract programming with scilla. Proc. ACM Program. Lang 3(OOPSLA)"",""Shariar A, Imran MA, Paul P, Rahman A (2020) A decentralized computational system built on blockchain for educational institutions. In: Proceedings of the International Conference on Computing Advancements, ICCA. Association for Computing Machinery, New York, p 2020"",""Shi F, Qin Z, Wu D, McCann J (2018) Mpcstoken: Smart contract enabled fault-tolerant incentivisation for mobile p2p crowd services. In: 2018 IEEE 38Th international conference on distributed computing systems (ICDCS), pp 961–971"",""Shi N, Tan L, Li W, Qi X, Yu K (2020) A blockchain-empowered aaa scheme in the large-scale hetnet. Digital Communications and Networks"",""citation_journal_title=Computers & Security; citation_title=Blockchain smart contracts formalization: Approaches and challenges to address vulnerabilities; citation_author=A Singh, RM Parizi, Q Zhang, KKR Choo, A Dehghantanha; citation_volume=88; citation_publication_date=2020; citation_pages=101654; citation_doi=10.1016/j.cose.2019.101654; citation_id=CR89"",""Singla V, Malav IK, Kaur J, Kalra S (2019) Develop leave application using blockchain smart contract. In: 2019 11Th international conference on communication systems networks (COMSNETS), pp 547–549"",""Sirisha NS, Agarwal T, Monde R, Yadav R, Hande R (2019) Proposed solution for trackable donations using blockchain. In: 2019 International conference on nascent technologies in engineering (ICNTE), IEEE, pp 1–5"",""TE-FOOD: Halal food companies are going to blockchain. Available online at                  https://cointelegraph.com/press-releases/halal-food-companies-are-going-to-blockchain                                 (2018). Last accessed: 2020-10-01"",""Team T. Truffle: Ethereum development framework. Available online at                  https://github.com/trufflesuite/truffle                                 (2016). Last accessed: 2020-10-20"",""Trotter L, Harding M, Elsden C, Davies N, Speed C (2020) A mobile platform for event-driven donations using smart contracts. In: Proceedings of the 21st International Workshop on Mobile Computing Systems and Applications. Association for Computing Machinery, New York, p 108"",""Udokwu C, Kormiltsyn A, Thangalimodzi K, Norta A (2018) The state of the art for blockchain-enabled smart-contract applications in the organization. In: 2018 Ivannikov ispras open conference (ISPRAS), IEEE, pp 137–144"",""citation_journal_title=Futur Gener Comput Syst; citation_title=Porx: A reputation incentive scheme for blockchain consensus of iiot; citation_author=EK Wang, Z Liang, CM Chen, S Kumari, MK Khan; citation_volume=102; citation_publication_date=2020; citation_pages=140-151; citation_doi=10.1016/j.future.2019.08.005; citation_id=CR96"",""citation_journal_title=Futur Gener Comput Syst; citation_title=Loc — a new financial loan management system based on smart contracts; citation_author=H Wang, C Guo, S Cheng; citation_volume=100; citation_publication_date=2019; citation_pages=648-655; citation_doi=10.1016/j.future.2019.05.040; citation_id=CR97"",""Wang P, Liu X, Chen J, Zhan Y, Jin Z (2018) Qos-aware service composition using blockchain-based smart contracts. In: Proceedings of the 40th International Conference on Software Engineering: Companion Proceeedings. Association for Computing Machinery, New York, pp 296–297"",""Wang S, Yuan Y, Wang X, Li J, Qin R, Wang F (2018) An overview of smart contract: Architecture, applications, and future trends. In: 2018 IEEE Intelligent vehicles symposium, IV 2018, changshu, suzhou, china, june 26-30, 2018, IEEE, pp 108–113"",""citation_journal_title=Energy Procedia; citation_title=Blockchain-based smart contract for energy demand management; citation_author=X Wang, W Yang, S Noor, C Chen, M Guo, KH [van Dam]; citation_volume=158; citation_publication_date=2019; citation_pages=2719-2724; citation_doi=10.1016/j.egypro.2019.02.028; citation_id=CR100"",""Watanabe H, Fujimura S, Nakadaira A, Miyazaki Y, Akutsu A, Kishigami JJ (2015) Blockchain contract: A complete consensus using blockchain. In: 2015 IEEE 4Th Global Conference on Consumer Electronics (GCCE), IEEE, pp 577–578"",""Westerkamp M, Victor F, Küpper A (2019) Tracing manufacturing processes using blockchain-based token compositions. Digital Communications and Networks"",""WIRED: A 50 million hack just showed that the DAO was all too human. Available online at                  https://www.wired.com/2016/06/50-million-hack-just-showed-dao-human/                                 (2016). Last accessed: 2020-10-20"",""Wright K, Martinez M, Chadha U, Krishnamachari B (2018) Smartedge: A smart contract for edge computing. In: 2018 IEEE International conference on internet of things (ithings) and IEEE green computing and communications (greencom) and IEEE cyber, physical and social computing (CPSCom) and IEEE smart data (smartdata), pp 1685–1690"",""Xie W, Wang B, Ye Z, Wu W, You J, Zhou Q (2019) Simulation-based blockchain design to secure biopharmaceutical supply chain. In: Proceedings of the Winter Simulation Conference, IEEE Press, pp 797–808"",""citation_journal_title=IEEE Access; citation_title=Smart contract based data trading mode using blockchain and machine learning; citation_author=W Xiong, L Xiong; citation_volume=7; citation_publication_date=2019; citation_pages=102331-102344; citation_doi=10.1109/ACCESS.2019.2928325; citation_id=CR106"",""Xu R, Lin X, Dong Q, Chen Y (2018) Constructing trustworthy and safe communities on a blockchain-enabled social credits system. In: Proceedings of the 15th EAI International Conference on Mobile and Ubiquitous Systems: Computing, Networking and Services. Association for Computing Machinery, New York, pp 449–453"",""citation_journal_title=Futur Gener Comput Syst; citation_title=Designing blockchain-based applications a case study for imported product traceability; citation_author=X Xu, Q Lu, Y Liu, L Zhu, H Yao, AV Vasilakos; citation_volume=92; citation_publication_date=2019; citation_pages=399-406; citation_doi=10.1016/j.future.2018.10.010; citation_id=CR108"",""citation_journal_title=IEEE Access; citation_title=Fether: An extensible definitional interpreter for smart-contract verifications in coq; citation_author=Z Yang, H Lei; citation_volume=7; citation_publication_date=2019; citation_pages=37770-37791; citation_doi=10.1109/ACCESS.2019.2905428; citation_id=CR109"",""citation_journal_title=IEEE Access; citation_title=A robust mobile payment scheme with smart contract-based transaction repository; citation_author=K Yeh, C Su, J Hou, W Chiu, C Chen; citation_volume=6; citation_publication_date=2018; citation_pages=59394-59404; citation_doi=10.1109/ACCESS.2018.2874021; citation_id=CR110"",""Yu K, Tan L, Shang X, Huang J, Srivastava G, Chatterjee P (2020) Efficient and privacy-preserving medical research support platform against covid-19: A blockchain-based approach. IEEE Consumer Electronics Magazine"",""Yu KP, Tan L, Aloqaily M, Yang H, Jararweh Y (2021) Blockchain-enhanced data sharing with traceable and direct revocation in iiot. IEEE Transactions on Industrial Informatics"",""Zhang F, Cecchetti E, Croman K, Juels A, Shi E (2016) Town crier: An authenticated data feed for smart contracts. In: Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security. Association for Computing Machinery, New York, pp 270–282"",""citation_journal_title=IEEE Internet of Things Journal; citation_title=Smart contract-based access control for the internet of things; citation_author=Y Zhang, S Kasahara, Y Shen, X Jiang, J Wan; citation_volume=6; citation_issue=2; citation_publication_date=2019; citation_pages=1594-1605; citation_doi=10.1109/JIOT.2018.2847705; citation_id=CR114"",""Zhao S, O’Mahony D (2018) Bmcprotector: A blockchain and smart contract based application for music copyright protection. In: Proceedings of the 2018 International Conference on Blockchain Technology and Application. Association for Computing Machinery, New York, pp 1–5"",""citation_journal_title=Journal of Parallel and Distributed Computing; citation_title=Blockchain based privacy-preserving software updates with proof-of-delivery for internet of things; citation_author=Y Zhao, Y Liu, A Tian, Y Yu, X Du; citation_volume=132; citation_publication_date=2019; citation_pages=141-149; citation_doi=10.1016/j.jpdc.2019.06.001; citation_id=CR116"",""citation_journal_title=Futur Gener Comput Syst; citation_title=An overview on smart contracts: Challenges, advances and platforms; citation_author=Z Zheng, S Xie, HN Dai, W Chen, X Chen, J Weng, M Imran; citation_volume=105; citation_publication_date=2020; citation_pages=475-491; citation_doi=10.1016/j.future.2019.12.019; citation_id=CR117"",""Zhou H, de Laat C, Zhao Z (2018) Trustworthy cloud service level agreement enforcement with blockchain based smart contract. In: 2018 IEEE International Conference on Cloud Computing Technology and Science (cloudcom), pp 255–260"",""Zichichi M, Contu M, Ferretti S, DAngelo G (2019) Likestarter: A smart-contract based social dao for crowdfunding. In: IEEE INFOCOM 2019 - IEEE Conference on Computer Communications Workshops (INFOCOM WKSHPS), pp 313–318"",""Zou W, Lo D, Kochhar PS, Le XBD, Xia X, Feng Y, Chen Z, Xu B (2019) Smart contract development: Challenges and opportunities. IEEE Transactions on Software Engineering""
""citation_journal_title"",""Peer-to-Peer Networking and Applications""
""language"",""en""
""og:description"",""In recent years, the rapid development of blockchain technology and cryptocurrencies has influenced the financial industry by creating a new crypto-economy. Then, next-generation decentralized applications without involving a trusted third-party have emerged thanks to the appearance of smart contracts, which are computer protocols designed to facilitate, verify, and enforce automatically the negotiation and agreement among multiple untrustworthy parties. Despite the bright side of smart contracts, several concerns continue to undermine their adoption, such as security threats, vulnerabilities, and legal issues. In this paper, we present a comprehensive survey of blockchain-enabled smart contracts from both technical and usage points of view. To do so, we present a taxonomy of existing blockchain-enabled smart contract solutions, categorize the included research papers, and discuss the existing smart contract-based studies. Based on the findings from the survey, we identify a set ";https://scholar.google.ch/scholar?start=30&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2021
1619099133-475;https://scholar.google.ch/scholar?as_ylo=2021&q=oracles+blockchain&hl=fr&as_sdt=0,5;Proposta de um método para avaliar a tecnologia blockchain em novos projetos da administraçăo pública;Í Freitas ;2021 bibliotecadigital.fgv.br;;"… PROPOSTA DE UM MÉTODO PARA AVALIAR A TECNOLOGIA BLOCKCHAIN EM NOVOS

PROJETOS DA ADMINISTRAÇĂO PÚBLICA … PROPOSTA DE MÉTODO PARA AVALIAR A

TECNOLOGIA BLOCKCHAIN EM NOVOS PROJETOS DA ADMINISTRAÇĂO PÚBLICA …";;;[PDF] fgv.br;https://bibliotecadigital.fgv.br/dspace/bitstream/handle/10438/30344/Trabalho%20Aplicado%20Icaro%20de%20Paula%20vers%C3%A3o%20final.pdf?sequence=1;"
 

FUNDAÇÃO GETULIO VARGAS  

ESCOLA DE ADMINISTRAÇÃO DE EMPRESAS DE SÃO PAULO  

  

ÍCARO DE PAULA FREITAS 

PROPOSTA DE UM MÉTODO PARA AVALIAR A TECNOLOGIA 

BLOCKCHAIN EM NOVOS PROJETOS DA ADMINISTRAÇÃO 

PÚBLICA 

   

  

  

  

  

  

  

  

  

  

  

  

  

SÃO PAULO  

2021 

  



 

ÍCARO DE PAULA FREITAS 

PROPOSTA DE MÉTODO PARA AVALIAR A TECNOLOGIA 

BLOCKCHAIN EM NOVOS PROJETOS DA ADMINISTRAÇÃO 

PÚBLICA 

 

 

 

  

  

Trabalho Aplicado apresentado Ă  Escola 

de Administração de Empresas de São 

Paulo da Fundação Getúlio Vargas, como 

requisito para obtenção do título de 

Mestre em GestĂŁo para a 

competitividade.  

  

Linha de Pesquisa: Tecnologia da 

Informação  

  

Orientador: Prof. Dr. Adrian Kemmer 

Cernev.   

  

  

  

  

 

SÃO PAULO  

2021  



 

 

 

 

 

 

 
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

  

Freitas, Ícaro de Paula. 
     Proposta de um mĂŠtodo para avaliar a tecnologia blockchain em novos 

projetos da administração pública / Ícaro de Paula Freitas. - 2021. 

     63 f. 

  

     Orientador: Adrian Kemmer Cernev. 
     Dissertação (mestrado profissional MPGC) – Fundação Getulio Vargas, 

Escola de Administração de Empresas de São Paulo. 

  
     1. Blockchains (Base de dados). 2. CiĂŞncia e tecnologia - Pesquisa. 3. 

Administração pública - Inovaçþes tecnológicas. I. Cernev, Adrian Kemmer. II. 
Dissertação (mestrado profissional MPGC) – Escola de Administração de 
Empresas de São Paulo. III. Fundação Getulio Vargas. IV. Título. 

  

  

CDU 353 

  

  
Ficha CatalogrĂĄfica elaborada por: Raphael Figueiredo Xavier CRB SP-009987/O 

Biblioteca Karl A. Boedecker da Fundação Getulio Vargas - SP 



 

ÍCARO DE PAULA FREITAS 

  

  

  

PROPOSTA DE UM MÉTODO PARA AVALIAR A TECNOLOGIA 

BLOCKCHAIN EM NOVOS PROJETOS DA ADMINISTRAÇÃO 

PÚBLICA 

 

 

  

  

  

Trabalho Aplicado apresentado Ă  Escola 

de Administração de Empresas de São 

Paulo da Fundação Getúlio Vargas, como 

requisito para obtenção do título de 

Mestre em GestĂŁo para a 

competitividade.  

  

Linha de Pesquisa: Tecnologia da 

Informação  

  

Data de avaliação: 25/02/2021  

  

                                      Banca Examinadora: 

  

_________________________________ 

                                                                    Prof. Dr. Adrian Kemmer Cernev - FGV   

                                                                          EAESP  
  

  

_________________________________ 
ProfÂŞ. DrÂŞ. Maria Alexandra Viegas Cortez da 

Cunha - FGV-EAESP  

  

  

_________________________________ 

Prof. Dr. Rodrigo Silva - NIC.br 

  



 

Agradecimentos 

  

Agradeço a Deus pela dådiva da vida, e por ter me proporcionado a oportunidade 

dessa jornada, nada fĂĄcil, mas que tambĂŠm nĂŁo foi impossĂ­vel.   

A minha famĂ­lia, pelo apoio incondicional e por sempre me incentivar nas minhas 

conquistas e desafios do dia a dia.  

Ao meu orientador, Prof. Dr. Adrian Kemmer Cernev pela disponibilização de seu 

tempo e seu apoio, principalmente perante as dificuldades enfrentadas devido Ă  

pandemia. 

A todos os professores do curso, pois cada disciplina me permitiu adquirir o 

conhecimento necessårio para a realização deste trabalho. 

A todos os colegas da turma, por terem sobrevivido ao desafio deste mestrado, 

tornando-o muito mais leve e alegre, alĂŠm de enriquecedor.  

 

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  



 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

“A menos que modifiquemos a nossa maneira de pensar, não seremos capazes de 

resolver os problemas causados pela forma como nos acostumamos a ver o 

mundo”.  

(Albert Einstein) 



 

RESUMO 

 

A utilização da tecnologia blockchain tem potencial para melhorar a transparência, 
aumentar a segurança e melhorar a qualidade das informaçþes nos serviços 
públicos. Essas características possibilitam a redução da burocracia, das fraudes e 
das corrupçþes, alÊm de melhorar a qualidade dos serviços prestados aos cidadãos. 
Esse estudo tem como foco auxiliar na avaliação do uso da tecnologia blockchain 
em projetos de ĂłrgĂŁos pĂşblicos, considerando a literatura e o conhecimento prĂĄtico 
de especialistas. Considera tambĂŠm normas corporativas e legislativas, no contexto 
das organizaçþes públicas, para as decisþes sobre os projetos, aferindo todos os 
pontos relacionados ao processo de escolha da tecnologia blockchain que podem 
influenciar no sucesso ou na falha do projeto. O objetivo do estudo ĂŠ desenvolver 
um artefato para auxiliar na avaliação da tecnologia blockchain de novos projetos da 
administração pública. Para desenvolvimento do artefato, foi aplicada a metodologia 
Design Science Research, e, para avaliação do artefato final, aplicou-se o mÊtodo 
cenårio. Neste processo, foram avaliados casos de implementaçþes da tecnologia 
blockchain em instituiçþes públicas de diferentes localidades, avaliando as questþes 
tĂŠcnicas, corporativas e regulatĂłrias, que inviabilizam o uso da tecnologia blockchain 
no projeto. Dessa forma, propþem-se um artefato para auxiliar na avaliação da 
tecnologia blockchain em instituiçþes públicas, buscando minimizar a possibilidade 
do uso inadequado dela. 
 

Palavras-chave: Blockchain, Administração Pública, Design Science Research.  

  

   

   

  

  

  

   

  

 

 

 

 

 



 

ABSTRACT 

 

The use of blockchain has the potential to improve transparency, increase security 

and improve the quality of information in public services. These characteristics make 

it possible to reduce bureaucracy, fraud and corruption, and improve the quality of 

services provided to citizens. This study focuses on helping to evaluate the use of the 

blockchain in projects of public agencies taking into account the literature and 

practical knowledge of experts, as well as considering corporate and legislative 

norms in the context of public organizations for decisions on projects, gauging all the 

points that are part of the process of choosing the blockchain that can influence the 

success or failure of the project. The objective of the study is to develop a model to 

assist in the evaluation of blockchain technology for new projects in public 

administration, using the Design Science Research methodology for the development 

of an artifact, and the scenario method for the evaluation of the final artifact. From the 

evaluation of blockchain implementation cases in public institutions in different 

locations, evaluating the technical, corporate and regulatory issues that make the use 

of blockchain technology in the project impossible. Thus, proposing a model to assist 

in the evaluation of blockchain technology in public institutions. This minimizing the 

possibility of inappropriate use of blockchain technology. 

 

Keywords: Blockchain, Public Administration, Design Science Research. 

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  



 

  

LISTA DE FIGURAS 

Figura 1 – Características centrais e opcionais na tecnologia blockchain ................ 15 

Figura 2 – Representação gráfica do blockchain ...................................................... 16 

Figura 3 - Cronologia do blockchain .......................................................................... 18 

Figura 4 - Categorização dos algoritmos de consenso ............................................. 19 

Figura 5 - Fluxograma para determinar qual tipo de banco de dados ĂŠ adequado ... 23 

Figura 6 - Fluxograma para determinar se um blockchain ĂŠ a tĂŠcnica apropriada .... 24 

Figura 7 - Projetos com a tecnologia blockchain no setor pĂşblico pelo mundo ......... 25 

Figura 8 - Metodologia Design Science Research – (DSR) ...................................... 33 

Figura 9 - Primeira versĂŁo do artefato proposto ........................................................ 38 

Figura 10 - Segunda versĂŁo do artefato proposto ..................................................... 40 

Figura 11 - Terceira versĂŁo do artefato proposto ...................................................... 42 

Figura 13 - Artefato do estudo de caso de Dubai ...................................................... 44 

Figura 14 - Artefato do estudo de caso da GeĂłrgia .................................................. 45 

Figura 15 - Artefato do estudo de caso do BNDES ................................................... 46 

 



 

LISTA DE TABELAS 

  

Tabela 1 - CaracterĂ­sticas identificadas na anĂĄlise quantitativa de artigos sobre a 

tecnologia blockchain ................................................................................................ 15 

 



 

LISTA DE QUADROS 

 

Quadro 1 - Publicaçþes da tecnologia blockchain no setor ....................................... 27 

Quadro 2 -MÊtodos e tÊcnicas para avaliação dos artefatos .................................... 34 

 



 

SUMÁRIO 

 

 

  

1. INTRODUÇÃO ................................................................................................ 11 

2. BLOCKCHAIN ................................................................................................ 13 

2.1  Evolução da tecnologia blockchain .................................................................. 17 

2.2    Tipos de blockchains ........................................................................................ 19 

2.4    OrĂĄculos ........................................................................................................... 21 

2.5  Usar ou nĂŁo usar a tecnologia blockchain ....................................................... 22 

2.6  Aplicação da tecnologia blockchain em serviços públicos ............................... 25 

2.6.1 Caso Dubai ...................................................................................................... 27 

2.6.2 Caso Georgia ................................................................................................... 29 

2.6.3 Caso Banco Nacional de Desenvolvimento (BNDES) ...................................... 30 

3. METODOLOGIA ............................................................................................. 31 

3.1 Método Design Science Research – (DSR) .................................................... 32 

3.2 Construção do artefato .................................................................................... 35 

3.3     Contribuição .................................................................................................... 48 

4. DISCUSSÃO E RESULTADOS ...................................................................... 49 

5. CONCLUSÃO ................................................................................................. 55 

5.1 Limitaçþes e contribuiçþes do trabalho ........................................................... 56 

6. REFERÊNCIAS ............................................................................................... 58 

 

  

  

  

 



11  

  

1. INTRODUÇÃO  

 

 Atualmente, muitos gestores públicos desejam aprimorar os serviços com a 

utilização da tecnologia blockchain, mesmo antes de conhecerem as reais 

necessidades de um determinado projeto. Muitas vezes, definem a tecnologia que 

solucionarĂĄ todos os problemas, ainda que possa haver outra tecnologia mais viĂĄvel, 

mais acessível, com melhor performance e segurança para a solução do problema. 

Para determinar se um projeto deverĂĄ utilizar realmente a tecnologia 

blockchain, ĂŠ importante usar uma estrutura para a decisĂŁo que certifique que ela ĂŠ a 

tecnologia mais adequada na resolução do problema (HOLGATE; FURLONGER; 

HOWARD, 2019). 

Comumente, isso acontece por causa da publicidade de alguns projetos que 

usam a tecnologia blockchain. Com isso, aumenta a empolgação com os benefícios 

que essa tecnologia emergente pode oferecer. Neste ponto, nĂŁo ĂŠ avaliado o custo-

benefĂ­cio de utilizar a tecnologia blockchain, portanto, esse estudo foca em auxiliar 

na avaliação do seu uso em projetos da administração pública.  

Na tecnologia blockchain as transaçþes são seguras, confiåveis, auditåveis e 

imutĂĄveis. Essas caracterĂ­sticas ajudam a reduzir a quantidade de documentos, alĂŠm 

de evitarem a duplicidade de informaçþes (UNDERWOOD, 2016). Por conta disso, 

essa tecnologia tem o potencial de auxiliar governantes e gestores pĂşblicos que tĂŞm 

interesse em utilizå-la no serviço público.  

Observa-se que outras tecnologias sĂŁo mais propĂ­cias para determinados 

projetos. Afinal, hĂĄ projetos pĂşblicos que nĂŁo podem ser transparentes e possuem, 

como premissa, a permissão de alteraçþes, terem acesso restrito, entre outros 

fatores de interesse pĂşblico. Desse modo, tendem a nĂŁo aproveitar todo o potencial 

que a utilização dessa tecnologia pode oferecer para o serviço público. 

Portanto, buscou-se reunir informaçþes com o propósito de responder a 

seguinte questĂŁo de pesquisa: como avaliar se a tecnologia blockchain ĂŠ adequada 

para projetos na administração pública?  

O objetivo deste trabalho ĂŠ desenvolver um mĂŠtodo que auxilia a avaliar o uso 

da tecnologia blockchain em projetos de ĂłrgĂŁos pĂşblicos.  

Os objetivos especĂ­ficos desse estudo sĂŁo:  

a) Apresentar alternativas viĂĄveis de procedimentos que viabilizam as 

implementaçþes da tecnologia blockchain; 



12  

  

b) Identificar quais sĂŁo os benefĂ­cios do uso da tecnologia blockchain para 

o projeto; e 

c) Auxiliar na compreensĂŁo das necessidades que pautaram a escolha da 

tecnologia blockchain nos ĂłrgĂŁos pĂşblicos. 

 

Neste estudo, serĂĄ utilizada a metodologia Design Science Research (DSR), 

que estuda, pesquisa e investiga, de maneira simulada, a compreensĂŁo do 

comportamento do artefato, tanto nas perspectivas acadĂŞmicas quanto nas das 

organizaçþes (BAYAZIT, 2004). Para isso, são aplicadas avaliaçþes do artefato, de 

forma analĂ­tica, por meio do mĂŠtodo de anĂĄlise da arquitetura, com apoio de 

especialistas, e a forma de avaliação prescritiva, por meio do mÊtodo cenårio, sendo 

utilizados casos de implementaçþes de blockchain em serviços públicos. 

Dessa forma, como resultado, serĂĄ proposto um mĂŠtodo para auxiliar na 

avaliação da tecnologia blockchain em novos projetos da administração pública. 

Assim, viabilizando a utilização de forma adequada e aderente ao projeto. 

Este trabalho estĂĄ estruturado da seguinte forma: inicia-se com a revisĂŁo da 

literatura, onde são apresentadas as definiçþes, a evolução e os diferentes tipos da 

tecnologia blockchain. Posteriormente, foca no conceito de contratos inteligentes e 

oråculos. Após isso, são apresentadas as aplicaçþes da tecnologia blockchain em 

serviços públicos de diferentes localidades. Em seguida, explica-se a metodologia 

DSR que foi aplicada no trabalho. Para finalizar, sĂŁo apresentadas as discussĂľes e 

os resultados e, por fim, as conclusĂľes do estudo. 

 



13  

  

2.  BLOCKCHAIN  

 

A tecnologia blockchain ĂŠ mais do que um banco de dados distribuĂ­do. Assim, 

a boa compreensĂŁo dela ĂŠ um importante fator para avaliar o seu potencial para os 

negĂłcios e governos. Considerada uma Distributed Ledger Technology (DLT), em 

que não hå necessidade de um mediador de confiança para validar as transaçþes, 

esta tecnologia é segura e publicamente disponível (ÇAĞLIYANGIL et al., 2020). 

A DLT e a tecnologia blockchain possuem a mesma origem conceitual, visto 

que os blocos sĂŁo compartilhados de forma distribuĂ­da pela rede, nĂŁo tendo a 

obrigatoriedade de serem compartilhados. Quando associadas, as duas tecnologias 

viabilizam o estabelecimento de um protocolo com três etapas: a) as transaçþes são 

registradas em um livro de registros (“ledger”), sendo compartilhada uma cópia em 

todos os nós de uma rede distribuída; b) as transaçþes são validadas em blocos, a 

cada intervalo de tempo, por uma regra de consenso e; c) a partir da validação, os 

blocos sĂŁo armazenados sequencialmente (CERNEV; DINIZ, 2019). 

Pode-se dizer que a tecnologia blockchain, no quesito tĂŠcnico, ĂŠ um banco de 

dados distribuído que registra todas as transaçþes abertamente e facilita as 

inspeçþes das informaçþes. No tangente ao quesito corporativo, Ê uma rede que 

viabiliza a troca de valor entre entidades e/ou pessoas. Enquanto no quesito legal, ĂŠ 

uma ferramenta que garante a validação das informaçþes e transaçþes realizadas 

sem a necessidade de um intermediårio de confiança (MOUGAYAR, 2018).  

Dessa discussĂŁo, destaca-se que conhecer tecnicamente a tecnologia 

blockchain ĂŠ fundamental, mas tambĂŠm ĂŠ imprescindĂ­vel compreender a visĂŁo 

corporativa e legal para usufruir todo o potencial existente nessa tecnologia.  

É importante destacar que a tecnologia blockchain está em amadurecimento, 

portanto, o seu uso ainda estĂĄ restrito a alguns casos, sendo que, atualmente, o 

maior deles ĂŠ o Bitcoin (TAPSCOTT; TAPSCOTT, 2016). Entretanto, projetos com a 

tecnologia blockchain podem ser interrompidos, mais em decorrĂŞncia de problemas 

no modelo de negócio e à falta de clareza dos benefícios, do que pela evolução da 

tecnologia (KANDASWAMY, 2019).  

Diante disso, para conhecer esta tecnologia, devem ser avaliados os quesitos 

corporativos, legais e tĂŠcnicos, uma vez que o sucesso do projeto depende, 

principalmente, da aderência da solução para o modelo de negócio proposto. 



14  

  

Conforme Swan (2015), a tecnologia blockchain pode ser utilizada para 

registrar, confirmar e transferir ativos financeiros, como uma propriedade ou dinheiro, 

alĂŠm de ativos intangĂ­veis, como votos ou propriedades intelectuais. Neste contexto, 

fica claro que ĂŠ possĂ­vel empregar essa tecnologia como prova da existĂŞncia de um 

ativo ou documento, sem a necessidade de se apresentar o conteĂşdo. O autor 

(2015) corrobora que a tecnologia blockchain pode ser usada para melhorar os 

serviços públicos, tornando-os descentralizados, mais baratos, mais eficientes e 

personalizados, permitindo criar um repositĂłrio universal, permanente e contĂ­nuo. 

Conforme mencionado por Mougayar (2018), a tecnologia blockchain ĂŠ uma 

ferramenta que garante a validação das informaçþes e transaçþes realizadas. Nesse 

contexto, fica claro que Swan (2015) ĂŠ mais prĂĄtico, pois aborda de forma aplicada o 

uso dessa tecnologia e demonstra que pode ser utilizada em diferentes casos. O 

mais relevante, contudo, ĂŠ constatar que Mougayar (2018) enfatiza a necessidade de 

compreender as três definiçþes, ou seja, a definição tÊcnica, corporativa e legal.  

É importante sempre estar alinhado com o modelo de negócio para aproveitar 

o maior potencial que a tecnologia tem a oferecer, assim, as decisĂľes sobre utilizar a 

tecnologia nĂŁo devem ser pautadas somente pelo critĂŠrio corporativo, tal como nĂŁo 

se deve decidir por questĂľes tĂŠcnicas e ou legais, sendo muito importante a 

avaliação dos três quesitos conjuntamente para uma solução. 

A tecnologia blockchain precisa estar alinhada com os processos da 

organização e sempre de acordo com as normas vigentes. A relevância do 

blockchain encontra-se nas caracterĂ­sticas que a tecnologia oferece, como, por 

exemplo, descentralização, transparência e imutabilidade, que são os maiores 

incentivadores para compreender melhor essa tecnologia.  

Lange et al. (2019), em uma pesquisa de publicaçþes científicas, constataram 

quais seriam as principais caracterĂ­sticas da tecnologia blockchain (Tabela 1) 

pesquisadas ou estudadas pela comunidade cientĂ­fica.  

 

 

 

 

 

 



15  

  

Tabela 1 - CaracterĂ­sticas identificadas na anĂĄlise quantitativa de artigos sobre a 

tecnologia blockchain 
Blockchain 

Characteristic                                                                                       Mentions 

Transaction based 43 

Distributed 42 

Ledger 38 

Consensus 36 

Immutable 33 

Block 28 

Cryptography 28 

Peer-to-Peer 27 

Synchronised 23 

Chained / Linkend (Blocks) 21 

Decentralized 19 

Chronological 14 

Transaprency 10 

Public 10 

Record of trans. / Database 9 

Anonymous  8 

Smart Contracts 6 

Digital ledger 5 

Fonte: Lange et al. (2019, p. 47). 

 

Lange et al. (2019) explicam que hĂĄ caraterĂ­sticas que sĂŁo consideradas 

centrais e opcionais (Figura 1), porÊm, isso não significa que as opcionais não façam 

parte das principais características da tecnologia. É importante frisar esse ponto, 

uma vez que, o modelo de negócio ou solução para um problema real pode não ter a 

necessidade de utilizar todos os recursos disponĂ­veis na tecnologia blockchain, desta 

forma, o uso de alguns recursos pode não agregar valor para a solução proposta. 

 

Figura 1 – Características centrais e opcionais na tecnologia blockchain 

 

Fonte: Lange et al. (2019, p. 47). 



16  

  

Apesar da tecnologia blockchain possuir inĂşmeros casos que demonstram o 

seu grande potencial para melhorar a vida das pessoas e governos, compreender 

como ĂŠ a estrutura da tecnologia blockchain ĂŠ essencial para entender os benefĂ­cios 

e potencial dessa tecnologia.  

O termo blockchain surgiu devido Ă  estrutura da tecnologia ser formada por 

uma cadeia de informaçþes armazenadas em blocos (CERNEV; DINIZ, 2019), sendo 

que essa cadeia de blocos deu origem ao termo blockchain. 

Para Antonopoulos (2017), o bloco funciona como um contĂŞiner que 

armazenas as informaçþes, onde cada bloco Ê constituído por um cabeçalho, 

composto por informaçþes como: timestamp, o endereço criptografado (hash) do 

bloco anterior, um endereço hash desse bloco e outras informaçþes da execução 

especĂ­fica do blockchain utilizado, e uma lista de registros. Vale salientar que cada 

implementação do blockchain pode possuir diferentes tamanhos do bloco, assim 

como metadados especĂ­ficos.  

A seguir, na Figura 2, tem-se um exemplo grĂĄfico da estrutura do blockchain. 

 

Figura 2 – Representação gráfica do blockchain 

 

Fonte: Cernev e Diniz (2019). 

 

  Para Karthik (2018), atualmente, existem seis implementaçþes Enterprise 

Blockchain que sĂŁo as mais utilizadas no mercado, sendo elas: 

a) Hyperledger;  

b) Ethereum; 

c) Multichain; 

d) Eris Industries;  



17  

  

e) R3 Corda; 

f) Openblockchain. 

 

Conforme verificado, a tecnologia blockchain possui potenciais para auxiliar 

nos processos de instituiçþes privadas ou públicas, porÊm, para poder ter o melhor 

valor agregado ao uso da tecnologia, ĂŠ necessĂĄrio um bom conhecimento dela e de 

sua estrutura; acompanhar a sua evolução e principais características; compreender 

bem o processo organizacional ao qual a tecnologia blockchain tem potencial de 

aprimorar e; por fim, compreender as normas e as leis que podem inviabilizar ou 

incentivar o uso da tecnologia. 

    

2.1 Evolução da tecnologia blockchain  

  

A história da criação do blockchain começou após a crise financeira em 2008, 

onde muitos governos imprimiram dinheiro com o intuito de incentivar o consumo. 

Como solução alternativa, foi proposta a criação de uma moeda digital, 

descentralizada e confiĂĄvel, conhecida atualmente como Bitcoin.  

Em 2008, uma pessoa, ou um possĂ­vel grupo, denominado pelo pseudĂ´nimo 

Satoshi Nakamoto publicou o White Paper Bitcoin: A Peer-To-Peer Electronic Cash 

System, sugerindo uma solução para o gasto duplo em uma rede ponto-a-ponto para 

pagamento digital sem a necessidade de uma autoridade central de confiança 

(NAKAMOTO, 2008).  

A Figura 3 apresenta uma linha do tempo dos principais pontos do 

desenvolvimento e da implantação de tecnologias no blockchain.  

 

 

 

 

 

 

 

 

 

 

 

 

 

 



18  

  

Figura 3 - Cronologia do blockchain 

 

Fonte: Jameel et al. (2020). 

 

Apesar de poucos anos, atualmente a tecnologia blockchain jĂĄ possui 

algumas versþes. Para Swan (2015), podem ser classificadas como três geraçþes de 

blockchains: 

a) O blockchain 1.0 advÊm da criação do sistema de pagamento 

eletrĂ´nico descentralizado; 

b) O blockchain 2.0 inclui os contratos inteligentes baseados em 

criptomoedas e considera a transferĂŞncia de ativos mais complexos; e 

c) O blockchain 3.0 inclui aplicaçþes de outras åreas, como governo, 

saúde, educação e internet of things, alÊm da capacidade potencial de 

contornar as limitaçþes atuais das jurisdiçþes geogråficas.  

 

Com esses poucos anos de existĂŞncia, a tecnologia blockchain ainda estĂĄ no 

processo de amadurecimento. Na literatura, ĂŠ possĂ­vel encontrar inĂşmeros casos de 

seu uso em diversas åreas distintas como: serviços financeiros (GUO; LIANG, 2016), 

educação (GRÄTHER et al., 2018), saúde (CHUKWU; GARG, 2020; NGUEWO 

NGASSAM et al., 2020), transporte e gestĂŁo da cadeia de suprimentos (CASADO-

VARA et al., 2018), mĂ­dia e entretenimento (SHRESTHA et al., 2020), turismo 

(TREIBLMAIER; ÖNDER, 2019) e, por fim, em serviços públicos (LAZUASHVILI; 



19  

  

NORTA; DRAHEIM, 2019; ALKETBI; NASIR; ABU TALIB, 2020; BOURGUIGNON; 

SANTOS ALMEIDA; MACADAR, 2020).    

 

2.2 Tipos de blockchains  

 

O processo que viabiliza a validação dos dados e status compartilhados na 

rede blockchain ĂŠ chamado de mecanismo de consenso, no qual ĂŠ utilizado um 

conjunto de algoritmos para a automatização do processo de concordância na rede 

blockchain. Dessa forma, pode-se garantir a validade dos dados. O mecanismo de 

consenso permite que a rede blockchain entre em acordo em relação a um 

status/dados compartilhado e, com o status compartilhado, consegue garantir a 

resiliĂŞncia contra falhas de nĂł da rede (FERDOUS et al., 2020). 

Os algoritmos utilizados no mecanismo de consenso sĂŁo denominados 

algoritmos de consensos. Podem ser categorizados com base em votos e em 

provas, como apresentados na Figura 4, que demonstra alguns algoritmos utilizados 

para o consenso do blockchain (CHUKWU; GARG, 2020).  

 

Figura 4 - Categorização dos algoritmos de consenso 

 

Fonte: Chukwu e Garg (2020). 

 

A importância dos mecanismos de consenso se då por este ser o responsåvel 

pela validação dos dados ou status no blockchain. AlÊm disso, ao lidar com dados, 

são necessårias algumas precauçþes sobre quais indivíduos ou corporaçþes 



20  

  

poderão ter acesso a essas informaçþes e, por sua vez, como estas serão validadas. 

Dessa forma, existem trĂŞs tipos de blockchain: os pĂşblicos, os privados e os 

consórcios. Na literatura, alguns autores utilizam o termo “permissionados” e “não 

permissionados” (TAPSCOTT; TAPSCOTT, 2016; ÇAĞLIYANGIL et al., 2020). 

Os blockchains públicos não possuem nenhuma restrição de permissão para 

visualização das informaçþes, alÊm disso, qualquer integrante da rede pode 

participar do processo de consenso, como ocorre, por exemplo, com o Bitcoin 

(ZHENG et al., 2017).  

Os blockchains privados possuem restriçþes para leitura das informaçþes, 

sendo que somente os nós de organizaçþes autorizadas podem fazer parte do 

processo de consenso, portanto, sendo considerada uma rede centralizada, pois ĂŠ 

gerenciado pela organização (ZHENG et al., 2017).  

Jå os blockchains consórcios são constituídos por inúmeras organizaçþes, 

sendo considerado como parcialmente descentralizado, apesar das restriçþes de 

acordo com a governança estabelecida no blockchain, que limitam quais 

organizaçþes participam do processo de consenso e têm acesso às informaçþes. 

(ZHENG et al., 2017).  

Cada tipo de blockchain tem suas particularidades, assim, compreender como 

funciona cada tipo Ê essencial para uma boa governança da rede blockchain. Em 

suma, conhecer os mecanismos de consensos e os tipos de blockchains existentes 

auxilia na adoção da solução adequada para o processo ou serviço. 

  

2.3 Contratos inteligentes  

 

A pesquisa de contrato digital existe muito antes do surgimento do blockchain, 

sendo que a primeira publicação sobre contratos inteligentes foi teorizada 20 anos 

antes do Bitcoin.  

O conceito de contrato inteligente surgiu em 1997, quando foi publicado por Nick 

Szabo em um artigo intitulado “Formalizing and Securing Relationships on Public 

Networks”. No entanto, foi somente com o surgimento do bitcoin e blockchain, que 

realmente foi possĂ­vel observar o potencial real e os benefĂ­cios proporcionados pelos 

contratos inteligentes (BASHIR, 2018). 

O contrato inteligente ĂŠ um programa, na forma de contrato virtual, executado 

automaticamente de acordo com as regras codificadas. O contrato nĂŁo precisa estar 



21  

  

no blockchain para ser executado. Devido à segurança existente no blockchain, este 

se tornou a plataforma padrão para execução dos contratos. 

 AlĂŠm disso, pode possuir uma regra de negĂłcio, que ĂŠ executada de acordo 

com os critérios determinados. É importante salientar que, o contrato pode ser 

executado por um participante da rede ou de forma autĂ´noma (BASHIR, 2018). 

AlĂŠm disso, os contratos inteligentes sĂŁo programas que sĂŁo executados de 

acordo com as regras estabelecidas e codificadas, podendo ser de forma autĂ´noma, 

a partir de um gatilho, ou acionamento automatizado. Uma vez especificada todas as 

clĂĄusulas, e as partes estando de acordo com o contrato, sĂŁo realizados todos os 

procedimentos prĂŠ-estabelecidos, como, por exemplo, a entrega de um produto e o 

pagamento após a confirmação de um representante da instituição. 

É importante ressaltar a existência de um aplicativo descentralizado, também 

denominado DApp, que utiliza os contratos inteligentes, por meio de uma interface 

amigĂĄvel. Neste contexto, para o usuĂĄrio final ĂŠ abstraĂ­da toda a complexidade do 

contrato, sendo possível realizar uma confirmação ou autorização, por meio de uma 

pĂĄgina da web ou um app do celular, sem ter contato direto com o contrato 

(KARAMITSOS; PAPADAKI; BARGHUTHI, 2018). 

Os contratos inteligentes tĂŞm o potencial de auxiliar de forma autĂ´noma e 

organizada inúmeros problemas de negócios existentes e melhorar a relação entre 

as partes do contrato, sem a necessidade de uma entidade certificadora.  

 

2.4 OrĂĄculos  

 

Por estarem no blockchain, os contratos não têm acesso a outras informaçþes, 

alĂŠm daquelas contidas no prĂłprio blockchain. Dessa forma, para poder acessar a 

informação de fora, o contrato inteligente utiliza os oråculos inteligentes, que têm 

acesso às informaçþes do mundo real, podendo ser acionado o contrato inteligente 

de forma autĂ´noma (MOUGAYAR, 2018).  

Por exemplo, o oråculo busca as publicaçþes de um departamento público no 

diårio oficial, onde toda publicação referente à autorização de pagamento de contrato 

ĂŠ coletada pelo orĂĄculo e compartilhada no blockchain, assim o contrato inteligente, 

por sua vez, efetiva o pagamento automaticamente, conforme prĂŠ-estabelecido, sem 

a necessidade de uma interação humana. De acordo com Beniiche (2020), hå 

diferentes tipos de orĂĄculos, enumerados a seguir: 



22  

  

a) Software; 

b) Hardware; 

c) Humanos - especialistas / habilidades especializadas; 

d) Oråculo de computação; 

e) OrĂĄculo de entrada e saĂ­da; 

f) OrĂĄculo especĂ­fico de um contrato inteligente; e 

g) OrĂĄculos baseados em consenso. 

 

A função dos oråculos para os contratos inteligentes Ê fundamental para a 

conexĂŁo com o mundo real. Sem esses mecanismos, haveria a necessidade de que 

os usuårios acionassem algum tipo de gatilho para execução do contrato e, mesmo 

esses contratos sendo autônomos, precisariam de uma confirmação, autorização ou 

informação para poder executar as clåusulas codificadas.  

 

2.5 Usar ou nĂŁo usar a tecnologia blockchain 

  

Com a popularidade da tecnologia blockchain, principalmente por causa das 

criptomoedas, muitas organizaçþes públicas e privadas iniciaram projetos sem ter o 

conhecimento prÊvio sobre a tecnologia e acreditaram ser viåvel a sua utilização. 

Devido a esse problema, alguns pesquisadores criaram algumas formas que 

permitem avaliar a decisĂŁo ou nĂŁo do uso da tecnologia blockchain em um projeto. 

  Vale Ă  pena destacar a forma ideali";"""date"",""2021-04-08T22:21:10Z""
""pdf:PDFVersion"",""1.7""
""xmp:CreatorTool"",""MicrosoftÂŽ Word para Microsoft 365""
""pdf:docinfo:title"",""Trabalho Aplicado Ă­caro de Paula""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""language"",""pt""
""dc:format"",""application/pdf; version=1.7""
""pdf:docinfo:creator_tool"",""MicrosoftÂŽ Word para Microsoft 365""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""Trabalho Aplicado Ă­caro de Paula""
""xmp:CreateDate"",""2021-04-08T19:21:10Z""
""modified"",""2021-04-08T22:21:10Z""
""pdf:hasMarkedContent"",""true""
""xmp:ModifyDate"",""2021-04-08T19:21:10Z""
""pdf:docinfo:creator"",""Ícaro de Paula Freitas""
""meta:author"",""Ícaro de Paula Freitas""
""meta:creation-date"",""2021-04-08T22:21:10Z""
""created"",""2021-04-08T22:21:10Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2021-04-08T22:21:10Z""
""resourceName"",""Trabalho%20Aplicado%20Icaro%20de%20Paula%20vers%C3%A3o%20final.pdf""
""Author"",""Ícaro de Paula Freitas""
""producer"",""MicrosoftÂŽ Word para Microsoft 365""
""pdf:docinfo:producer"",""MicrosoftÂŽ Word para Microsoft 365""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""access_permission:modify_annotations"",""true""
""dc:creator"",""Ícaro de Paula Freitas""
""dcterms:created"",""2021-04-08T22:21:10Z""
""Last-Modified"",""2021-04-08T22:21:10Z""
""dcterms:modified"",""2021-04-08T22:21:10Z""
""title"",""Trabalho Aplicado Ă­caro de Paula""
""xmpMM:DocumentID"",""uuid:A9918C57-3BCF-4CB2-A485-107B145D85E9""
""Last-Save-Date"",""2021-04-08T22:21:10Z""
""pdf:docinfo:modified"",""2021-04-08T22:21:10Z""
""meta:save-date"",""2021-04-08T22:21:10Z""
""Content-Length"",""1914787""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Ícaro de Paula Freitas""
""dc:language"",""pt-BR""
""pdf:producer"",""MicrosoftÂŽ Word para Microsoft 365""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""63""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""248"",""444"",""816"",""871"",""754"",""205"",""1607"",""1531"",""1423"",""227"",""218"",""2031"",""2268"",""1511"",""2381"",""2077"",""1165"",""1326"",""1358"",""1192"",""1244"",""2201"",""2331"",""1237"",""449"",""1142"",""1154"",""1156"",""1883"",""2048"",""2210"",""2192"",""2270"",""2072"",""1204"",""2767"",""1850"",""1787"",""1764"",""1669"",""1380"",""1938"",""1237"",""2042"",""646"",""264"",""132"",""723"",""2340"",""1170"",""2380"",""2601"",""2492"",""2604"",""2454"",""1727"",""2214"",""2300"",""1896"",""2090"",""2113"",""2227"",""1907""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2021-04-08T22:21:10Z""
";https://scholar.google.ch/scholar?start=60&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2021
1619099124-457;https://scholar.google.ch/scholar?as_ylo=2021&q=oracles+blockchain&hl=fr&as_sdt=0,5;[HTML][HTML] Cross-Department Secures Data Sharing in Food Industry via Blockchain-Cloud Fusion Scheme;Q Tao, Q Chen, H Ding, I Adnan, X Huang… ; Security and …, 2021  hindawi.com;United Kingdom;"… proposed an efficient multiauthority CP-ABE scheme based on LSSS access structure without

global authority and se- curity under the random oracle model [20]. Liu et al. proposed a security

scheme only if the number of colluding users is less than (m+1) [21]. 1.1.2. Blockchain …";Cité 1 fois;;[HTML] hindawi.com;https://www.hindawi.com/journals/scn/2021/6668339/;"[image: logo]
	Journals
	Publish with us
	Publishing partnerships
	About us
	Blog




Security and Communication Networks
+Journal Menu
[image:  ]PDF[image:  ] 
    
     Icons/Arrow Right White
     Created with Sketch.
     
         
    
     
         
             
                 
                     
                         
                             
                                 
                            
                             
                             
                                 
                            
                        
                    
                
            
        
    



Journal overview
For authorsFor reviewersFor editorsTable of ContentsSpecial Issues
[image:  ]         

Submit






Security and Communication Networks / 2021 / Article
Article SectionsOn this page
AbstractIntroductionPreliminariesConclusionData AvailabilityConflicts of InterestAcknowledgmentsReferencesCopyright


Special IssueBlockchain for Systems Management and Cybersecurity
View this Special Issue

Research Article | Open Access
Volume 2021 |Article ID 6668339 | https://doi.org/10.1155/2021/6668339
Q. Tao, Q. Chen, H. Ding, I. Adnan, X. Huang, X. Cui, ""Cross-Department Secures Data Sharing in Food Industry via Blockchain-Cloud Fusion Scheme"", Security and Communication Networks, vol. 2021, Article ID 6668339, 18   pages, 2021. https://doi.org/10.1155/2021/6668339

Show citation
Cross-Department Secures Data Sharing in Food Industry via Blockchain-Cloud Fusion Scheme


Q. Tao[image:  ]   .cls-1{fill:#a6ce39;}.cls-2{fill:#fff;}.cls-3{fill:none;} orchid     

,1 Q. Chen,2 H. Ding,1 I. Adnan[image:  ]   .cls-1{fill:#a6ce39;}.cls-2{fill:#fff;}.cls-3{fill:none;} orchid     

,1 X. Huang,3  and X. Cui[image:  ]   .cls-1{fill:#a6ce39;}.cls-2{fill:#fff;}.cls-3{fill:none;} orchid     

11Key Laboratory of Aerospace Information Security and Trusted Computing, Ministry of Education, School of Cyber Science and Engineering, Wuhan University, Wuhan 430072, China
2School of Remote Sensing and Information, Wuhan University, Wuhan 430072, China
3School of Computer Science and Technology, Southwest University of Science and Technology, Mianyang 621002, China

Show more
Academic Editor: Leandros Maglaras
Received21 Dec 2020
Revised23 Jan 2021
Accepted27 Feb 2021
Published27 Mar 2021


Abstract
The barriers of food enterprises and departments caused information asymmetry, which is the root cause of food safety incidents. Simultaneously, it is challenging to solve the information asymmetry by the existing cloud-based food supply-chain regulation system. Establishing a secure and reliable data sharing environment is an effective solution to the information island. Blockchain can construct a security network based on mathematical algorithms, eliminating the third party’s potential security risk, and realize transparently share data. In this paper, on the principle of metadata remaining in the food enterprises, we propose a blockchain-cloud fusion scheme based on Decentralized Attribute-Based Signature (DABS) to realize secure data sharing between departments. It constructs a decentralized and trusting environment for data owners to share data and achieves social co-governance of food safety based on the smart contract. It can also preserve the existing system architecture and complement the performance disadvantage of blockchain and cloud storage. The result achieved from security analysis shows that our scheme supports unconditional full anonymity and can resist collusion attacks of N-1 out of N corrupted attribute authorities.
1. Introduction
In the age of big data, the data has a tremendous potential value, and different enterprises and regulators have collected data, such as farmers can only collect the data of crop growth (seeds, fertilizers, pesticides, environment, etc.). Food producers can get the processing data (product formulation, machine, process parameters, inputs, etc.), sellers collect sales data (location, price, customer, etc.), and regulators store the sampling inspection reports and monitoring data. The data owners would not share the data with the disclosure risk of user privacy and commercial secret. It is the primary cause of information asymmetry that has led to some negative market phenomena, like “good money after bad,” “2013 horse meat scandal in the Europe,” and “2017 multistate Salmonella outbreak in the US” [1]. More than 600 million people worldwide fall ill after consuming unsafe food each year [2]. Cross-departmental data sharing in the food industry is a promising solution to food safety incidents and promotes industry development [3]. The traditional cloud-based regulatory system (as Figure 1 shown) provides a solution to share the food data and protect the food quality [4]. According to the Cisco white paper, most companies in the food supply-chain deployed the regulatory system in cloud [5]. Cloud features of pay-on-demand and elastic extension can decrease the cost [6–8]. However, the customers and data in the cloud are not in the same trusted domain, resulting in a lack of trust between customers. Cloud security incidents are frequent. More than 10000 security incidents happened in Malaysia in 2013. According to the 2013 Norton report, the total cost of cybercrime in Australia amounts to AU$1.06 billion [9]. The privacy of 368000 students in Florida Virtual School was leaked in 2018. So, some common defects in the traditional regulatory system need to be addressed: (1) the tampering and hiding of wrong information in the centralization system. (2) the risk of privacy leakage and data loss if the servers are compromised or privileged users’ rights are not adequately monitored. (3) It is difficult to verify the user’s identity, which is hard to guarantee the authenticity of shared data and track down the person responsible for the product accident. (4) The data owners are reluctant to share data due to the lack of trust between the system and food enterprises, and the enterprises would not invest heavily to rebuild their system. More than 40% viewed that food fraud is difficult to monitor by the traditional methods [2].
[image: ]


Figure 1 
Traditional food supply-chain regulation system (the barriers among enterprises and departments block information sharing in the food supply chain).


With the characteristics of tamper-proofing, decentralization, and co-governance, blockchain happens to address the above issues by constructing a trusted network based on a mathematical algorithm. The data are shared transparently by enterprises and regulators. It is immutably for the data in block chain [10]. Smart contract is an intelligent and self-executing logic code without an intermediary, reducing transaction costs and transaction time [11]. Walmart has developed a blockchain-based system to monitor the product quality by sharing information in pork and mangos industries [12]. It helps to effectively track the pork products during serval minutes compared to serval days taken in the past. There are several challenges: (1) the blockchain has the characteristic of pseudoanonymity that cannot protect the privacy information in the signature. The adversary can get the privacy information by analyzing the expenditure information of user account [13]. (2) Performance, cost, and security are the primary bottlenecks for implementing blockchain technology in the food industry.
To address the issues, we propose a blockchain-cloud fusion scheme to protect the security of shared data. The enterprises can preserve the existing system architecture and transparently share data in a trusted network without third parties. It adopts the characteristics of low cost, scalability, and high-performance in cloud computing technology to make up for blockchain's performance and cost bottleneck. The metadata remains in the existing enterprise system, and the data’s signature is shared with the blockchain network. It can reduce the storage and performance load of the blockchain network. Besides, the analysis of the signature algorithm in Table 1 shows that the Attribute-Based Signature (ABS) is an effective solution to share data with fine-grained control and protect the data owner’s privacy. To address the information leakage risk and adapt to the decentralization feature of our scheme, we propose a Decentralized Attribute-Based Signature (DABS). The enterprises and regulators have equal rights to verify employees in their respective departments. The signature of shared data is entirely secure, which encourages users to monitor food quality actively. Simultaneously, it provides a solution for regulators to track down the person responsible for public safety incidents and rumors. It is meant to promote social co-governance in the food industry.
		

	Algorithm	Features	Main application
	

	RSA signature	Algorithm security is based on large prime decomposition.	Short message signature
	The private key space is large, the encryption effect is good, but the encryption speed is slow, and it is very complex to the management of the public key authentication and certificate.
	1 : 1 communication mode.
	Blind signature	The message is blind to the signer. Even the signature is leaked by the recipient; it cannot be tracked by the signer; 1 : 1 communication mode.	Electronic cash; electronic election
	Broadcast signature	Transmit the signed messages to a group of users with an insecure channel;.	Pay-tv
	But, it is difficult to obtain the size and membership of the receiving group in time under the open mode; enumerate user identities in distributed applications can compromise user privacy.	Video conference
	Group signature	The anonymous signature is used for group sharing, and the receiver can verify the signature but cannot get the signer’s information.	Electronic bidding
	The group administrator creates the group with key distribution, which has the risk of identity escrow leakage and signature forging.	Digital copyright protection
	Attribute-based signature (ABS)	Signature and user private key associated with attributes.	Fine-grained access control; group key management
	Fine-grained noninteractive access control and 1 : n communication mode; it reduces the network bandwidth for shared data and the processing overhead for nodes.	Privacy protection
	Resist to collusive attacks, anonymous.
	





Table 1 
Signature algorithm analysis.


1.1. Related Work
1.1.1. ABS
ABS originated from fuzzy identifies encryption that was firstly proposed by Sahai and Waters [14]. It could hide user identity information and provide a solution for data owners to share with fine-grained access control. In the ABS, the users received a private key from the Attribute Authority (AA) based on their attributes and defined a shared community for sharing data with a signing predicate. Only if the users’ attributes satisfy with the signing predicate, they could get the share data, such as farmers share a file with an access control strategy of signing predicate ((manager with Level 7 in Food Processing FP1) or regulator), which means that only the manager with Level 7 in Food Processing FP1 and regulators can access the shared file. ABS scheme has a bright application prospect, such as directional broadcast and cloud storage. It has attracted many scholars and presented a lot of research results [15]. Li et al. proposed an Attribute-Based Encryption (ABE) system based on a ring signature scheme [16]. Anyone can select a set of public keys of random signers to hide its public key [17]. However, the above schemes manage the entire system attribute set by a single AA. It quickly causes performance bottlenecks and cannot satisfy the actual needs of multiple departments’ cooperation [18]. So, Chase et al. let numerous authorities manage the attribute set, but the scheme has disclosure risk of Centralized Attribute Authority (CA) because the CA could calculate any user’s private key [19]. Yang et al. proposed an efficient multiauthority CP-ABE scheme based on LSSS access structure without global authority and security under the random oracle model [20]. Liu et al. proposed a security scheme only if the number of colluding users is less than (m+1) [21].
1.1.2. Blockchain
Nakamoto firstly proposed the blockchain architecture [10]. It provided a solution to a trust and equality among different participators by a mathematical algorithm. In addition, it is an effective way to solve the single point validation based on decentralization [22]. Macrinici et al. [11] designed the smart contract to protect users’ privacy and automatic information processing. Blockchain technology has achieved great success in the financial industry [23], like Bitcoin and Ethereum. It demonstrated the application feasibility of blockchain technology. Some promising blockchain applications are being developed to address industry concerns such as medical, agriculture, energy, and food safety. In [24–28], a security data management scheme was proposed with privacy-preserving to share the medical data by encapsulating EHRs based on attribute-based encryption into the blockchain; there is no detailed application. Even in [28], it cannot resist the collusion attack between uses. In [29], it is proposed that blockchain is a solution to optimize the energy industry structure and facilitate sustainable development. Walmart developed a blockchain-based system to monitor pork and mangos from South America to the US [1], where the managers could trace down the product during several minutes compared to several days taken in the past.
1.1.3. Supply Chain and Blockchain
Data-shared barriers among the food enterprises caused information delay and asymmetry, which affected the quality of shared information [30]. Supply chain management is an important application for blockchain technology [31]. Blockchain could record entire life cycle of each product with immutable and shared information between consumers and producers. The ICT electronic agriculture system via blockchain infrastructure guaranteed the integrity of agricultural environment data, conducive to improving sustainable agrarian development [32]. In [33], it is proposed that blockchain applied in the food supply-chain not only could reduce food losses by optimizing product logistics, but it also benefits to improve regulatory efficiency. Saberi et al. explored how blockchain could help supply-chain sustainability and guide industry transformation. Clauson and Breeden discussed the supply-chain management in healthcare, and most blockchain schemes are still in the proof-of-concept or pilot stag [34]. Security and privacy are barriers to the integration of IoT and blockchain. Jangirala et al. proposed a LBRAPS protocol in mobile edge computing to protect the transmit data security [35]. In [36, 37], a AgriBlockIoT system is proposed for food supply-chain management. But, it lacks an effective solution to protect the data security.
1.2. Our Contributions
In summary, main contributions of this work are as follows:(1)This work proposes a food supply-chain regulation system based on a blockchain-cloud fusion scheme. It supports secure data sharing across departments, intelligent regulation, and social co-governance with a smart contract.(2)This work proposes a DABS scheme by combining the characteristics of ABS and ring signature. It helps to improve the safety of the food supply-chain regulation system. Besides, it provides a solution for regulators to trace down the illegal users, which is useful to prevent the spread of rumors and establish a harmonious network environment.(3)This work performs a comprehensive security analysis shows that our scheme supports unconditional full anonymity and noncollusion with strong (N-1) (resist collusion attacks of N-1 out of N corrupted Attribute Authorities). The performance evaluation shows our scheme’s performance advantage. Compared with time complexity  in traditional schemes, it supports batch-verification with .
1.3. Organization
The remainder of this work is as follows: Section 2 introduces the definitions of the bilinear map, computational assumption, access structure and LSSS, syntax, and security model of DABS. Section 3 details the blockchain-cloud fusion scheme. Section 4 describes security analysis, and Section 5 presents the performance analysis, while the conclusion is presented in Section 6.
2. Preliminaries
This section introduces the definitions of bilinear map, computational assumption and linear secret-sharing schemes. Then, we describe the framework definition of the DABS scheme and security definitions.
2.1. Bilinear Map
Let , , and  be three multiplicative groups of prime order . A bilinear map is a map e:  with the following properties:(1)Bilinearity:  (2)Nondegeneracy: (3)Computability: there is an efficient algorithm to compute 
If , then . The bilinear pairing applied in our proposed scheme is symmetric, where  =  = G.
2.2. Computational Assumption
Definition 1. Computational Diffie-Hellman problem, CDH: assume is a bilinear group of prime order .  is a generator of , bilinear map e: . Giving  for unknown  to compute . We say that the (t, )-CDH problem holds if there exists no poly(t)-time algorithm can solve the CDH problem with non-negligible advantages.
2.3. Access Structure and Linear Secret-Sharing Schemes (LSSS)
Definition 2. Access structure [38]: let U =   be a set of parties, and a collection  is called monotone if :  A monotone access structure is collection  which is a nonempty subsets of , i.e., . The set in  is called authorized set, and others is an unauthorized set.
Definition 3. Linear secret sharing scheme [39] (LSSS): a secret sharing scheme  over a set of parties U =   is LSSS only if(1)The share for each party forms a vector over .(2)There exists a share generating matrix  with  rows and  columns. For , let the function  map the row i of M to the attribute . When we consider the column vector  = , where  is the secret to be shared, and  are chosen randomly; then  is the vector which shares the secret  by function . The shared secret  belongs to the party .Suppose that  is an LSSS for the access control strategy . Let  is an authorized set, and  is defined as . If  is valid shares of any secret  by function , there exists constant  and . In [38], it is shown that these constants  can be found in polynomial time.
2.4. Syntax of Decentralized Attribute-Based Signature Scheme (DABS)
According to [40], we construct the DABS scheme that consists of five algorithms: Setup, Keygen, Sign, Verify, and Trace. Select a random security parameter λ; our scheme works as follows:(i)Setup (λ). The algorithm takes a random secure parameter λ as input, and it outputs a master key MSK, public key PK, and trace key TK, where TK is used to trace the user identity. Assume that the PK contains the universe of attributes set U, and the default attributes set W.(ii)Keygen. In this algorithm, all attribute authorities  share a pseudorandom function . It takes the user’s attribute set , MSK, and PK as input; each AA computes the attribute private key SK as output.(iii). The algorithm takes input signing predicate  and shared message M, PK, SK, and , where  is generated according to the access control strategy of the data owner,  is a share generating matrix,  is a map function as shown in Definition 3, and  is a default attribute set. The algorithm outputs a signature .(iv)Verify. The algorithm takes  and PK as input and outputs a Boolean value.(v)Trace. The algorithm takes input the signature  and trace key  and outputs the signer identity . Batch Processing. (Definition 4 [41]): giving BSetup(λ) (q, ), where q is a prime, λ is a security parameter, and  if  = , then A = .
2.5. Security Definitions
This part introduces the security definitions. The ABS scheme supports characters of anonymity and noncollusion. In terms of anonymity, it usually includes computational anonymity and unconditional full anonymity. [16] supports computational anonymity, where the adversary can access the user identity with unlimited computing power. While to the characteristic of unconditional full anonymity, giving a sufficient signature with an access control strategy; adversary Å has unlimited computing power and accesses any users’ attribute key. Still, there is no poly(t)-time algorithm  to reveal the signer’s attributes information from the signing predicate. Noncollusion means no poly(t)-time for adversaries to forge the legitimate signature with a set of complementary attributes.
2.5.1. Unconditional Full Anonymity
Our scheme supports unconditional full anonymity if no adversary Å can win the following games with non-negligible advantages.(i)Setup. An adversary Å selects a random signing predicate . The simulator  calls the algorithm Setup(.) and returns the public key PK and master key MSK to Å. Å can construct a key for any AAi.(ii)Challenge. In this phase, the Å chooses a random message  and two attribute sets , where  satisfies the signature predicate . The Å sends two tuples  and  to . The  calls the algorithm Keygen(.) and returns private keys . Then  chooses a bit, b∈{0, 1}, signs the message  as signature , and sends it to the Å.(iii)Guess. The Å outputs the guess result  of  and wins the game only if .
2.5.2. Noncollusion
Our scheme can defend against collusive attack under adaptive selective message and predicate attacks if there is no adversary Å (capable of unlimited computing power) can win the following games with the non-negligible advantages.(i)Initial.(ii)Assume  is a mini-subset of  and  = 1. Let the compromised AA group as SA =  . For the predicate  the adversary Å can forge the signature only if corrupted by another . So, the attack effect of the DABS scheme can be reducible to attack the . Assume that the simulator  chooses a default attributes set  from .(iii)Setup.(iv) calls Setup(.) and sends to adversary Å.(v)Query.(vi)Å queries the random oracle H,, SK and signature from .(vii)Challenge.(viii)The adversary Å challenges the security under a collusive attack. It chooses two random users  with the attribute set , respectively, where ,  and .(ix)The adversary Å requires to query private key of  and ;  returns the , to Å, respectively. So, the combined-key is  .(x)Forgery. Å constructs a signature  and will win the game only if(1)Verify () = true.(2)Å cannot query any private key of the attribute set  where .(3)Å cannot query any private key of the attribute set  where .
3. Cross-Department Secures Data Sharing in the Food Industry via Blockchain-Cloud Fusion Scheme
3.1. System Model
Assume the enterprises, regulators, and neutral institutions (such as food commonweal organization) in the whole food supply-chain hope to share data to promote supervision of food quality and public safety incidents. They provide a cloud server as an Attribute Authority server (AA) to store the transmitted data and verify them. Regulators and enterprise legal persons are registered with the regulator AA server, and employees register with the enterprise AA server. Assume neutral institutions’ servers are semicredible that would not eavesdrop or backup users’ registration information. The common consumers, including food enterprise employees, can enter the system by registering with any neutral institution, release supervision information anonymously based on the DABS algorithm (detailed in Section 3.3), and realize social co-governance of all links in the food supply chain. Food enterprises own the AAs, regulators, and neutral institutions independently. To standardize terms, we use data owners as the data providers in the following, including enterprises, regulators, and neutral institutions. As Figure 2 shown that our system consists of four modules: cloud network, DABS, blockchain network, and application group. The system details are as follows:(i)Cloud Network Module. It consists of AA servers’ group to support user identity verification, user management, and data storage. Each AA server is selected from the existing system architecture in the food supply chain. AA server is operated and maintained independently by data owners, which also is used as shared data services to support food quality supervision and traceability. Likely, farms can share data in the cultivation server; storage enterprise shares data with the warehouse server, etc. Processing enterprise shares data with the process server; regulators share sampling inspection reports and monitoring data with the regulator server. It uploads the shared data signature and index from food enterprises and regulators to the blockchain network. And, it shares consumers’ report data with DABS signature to the blockchain.(ii)DABS Module. It has the security characteristics of unconditional full anonymity and noncollusion (as shown in Section 4). It supports user authentication, secret key assignment, digital signature, and traceability. The AA server generates an anonymous private key for the user with the fuzzy attribute set if the registration information is authenticated. Data owners share data with access control strategy and private key (sign algorithm is detailed in Section 3.3). Furthermore, it provides a way for regulators to trace down the person responsible for rumors and incidents in the food industry (trace algorithm, as shown in Section 3.3), which is helpful to purify the system network. The DABS module is deployed in the AA servers, which works together to maintain the system’s stability and security.(iii)Blockchain Network Module. It receives the data from data owners’ server, consensus validation with PBFT [39] that more than 2/3 of the servers acknowledge the validity of data, and store the data block into the blockchain (the block structure as shown in Figure 2). Besides, it supports co-governance and traceability of food safety via smart contract (detailed in Section 3.4). If the report is useful, it will give a reward in return, conducive to motivating consumers to participate actively. With the robustness feature of PBFT, the blockchain network can resist no more than 1/3 of the server’s failure attack. This module can be deployed in AA servers to save the system development cost.(iv)Application Group Module. It composes of consumers and regulators. Any system user should register firstly by AA server. Consumers can query any quality information of food supply-chain as needed from the blockchain network. The system will then get and return the data from the data owner’s server by the data index in the data block. Besides, consumers can take part in food safety supervision. Regulators have the power of supervision to monitor the whole food supply-chain and hold responsible people, including timely warning and accountability of food safety incidents.
[image: ]


Figure 2 
The food supply-chain regulation system model based on blockchain-cloud fusion scheme. It remains the existing system architecture and industry metadata owned by data owners. Besides, it enables consumers to know the food quality information throughout the whole supply chain. It provides a safe way for any consumer to social co-governance of food safety without fear of cyber-violence. Furthermore, the regulators can track rumor-mongers.


3.2. Threat Model and Design Goal
The adversaries can eavesdrop on the public channel’s information, including signature and signing predicate. Besides, there are dishonest server groups that are allowed to collude to infer the signature’s user identity.
Based on the above threat model, the food supply-chain regulation system hopes to achieve the following goals.(1)Privacy Protection. System user privacy information can be deduced by statistical analysis [13]. So, the system should have the characteristic of unconditional full anonymity. It can resist the adversary’s statistical analysis and is secure when no more than N  1/N of the collusion servers.(2)System Availability. In this work, the system availability includes two aspects. (a) System robustness: on the one hand, it works only if no more than 1/3 servers in the blockchain network fail; on the other hand, it is Strong (N-1) for AA servers that it works as long as more than one server is honest. (b) Traceability: it provides a solution to track the person responsible for rumors and food safety incidents.
3.3. Proposed DABS Scheme
 Setup (λ). Let G and GT be two cyclic multiplication groups of composite order  and the bilinear map , where p and q are two large prime numbers. The construction also enables to work on asymmetric pairing groups, where , and . Denote  is the subgroup of order q in G. The universal set of attributes U =   are managed by the distribution Attribute Authorities Group. Each  monitors an attribute subset   and issues the corresponding attribute private key to users. Define the default attributes set  , where Wi . Select two collision-resistant cryptographic hash function H,. Select random generator , exponent ∈, and compute . Select random exponent  for each  and compute . Select random parameter for each attribute. Select generator . So, it generates the public key PK, the master key MSK for AA Group, and the trace key TK as follows: Keygen. In this algorithm, all attribute authorities  share a pseudorandom function . Assume the user  possesses an attribute set . The  calculates ,, and . For attribute , it computes . So, the anonymous private key of the user  is . In this algorithm, the signer  sets an access control strategy The access control strategy is  The algorithm constructs an LSSS access matrix  with an injective function that maps each row of the matrix S to an attribute of .(i)The algorithm randomly chooses a parameter  for every bit of   = {u[1], u[2],…, u[k]}, and ,. Define  and The is well-formed.(ii)Choose a random parameter  and a random vector . Define , where is the th row of S. Choose a constant ∈ and .(iii) and select random parameter If , calculate  If , calculate (iv)Select fuzzy factors  for user and calculate(v)Calculate(vi)So, the signature is Verify. The algorithm takes the signature  and PK as input and outputs the result. According to the equation result , if the equation is correct, this scheme accepts the signature , or reject  and output . Trace. The algorithm takes input the signature , trace key , and PK and then outputs the signer identity ID. The algorithm describes as follows:(i)Call algorithm verifies  and checks the signature  is true or not.(ii)If , it will check(iii)Return u[i] = 1 only if the both check pass, else return u[i] = 0. So, the algorithm will output the signer’s identity ID.
The effectiveness of algorithm Trace (.) has been proved in detail in [42], and the security of algorithm Trace (.) has been proved in [43], so we would not detail and analysis the algorithm in the paper. Correctness. This scheme outputs the signature for the message M. We can prove the correctness of the scheme as follows: Batch-Verification Processing. According to the scheme [13], we propose a batch-verification processing algorithm to improve the effectiveness of  to . It takes inputs the public key PK and a large number of signatures , and works as follows:
3.4. Social Co-Governance of Food Safety Based on Smart Contract
The smart contract enables to automatic execution of the agreement between the parties without an intermediary. It is helpful to improve the efficiency of information processing and social co-governance of food safety.(1)Data Intelligence Verification. When enterprise servers upload signature  to the blockchain network, it would autorun the smart contract deployed in blockchain servers and intelligent process verification of the signature, as shown in Algorithm 1.(2)Social Co-Governance of Food Safety. If the quality problem happens in the food supply-chain, any consumer can report it anonymously by the blockchain network. On one hand, smart contract helps regulators timely deal with the potential risk of food safety incidents and investigates the legal liability of the enterprises involved; on the other hand, it will warn someone who spreads rumors. The smart contracts are constructed as shown in Algorithm 2 and 3.
		 	Input: signature  and public key 
	 	Output: success or alarm
	(1)	Function: verify 
	(2)	 IfThen
	(3)	  Writeblockchain 
	(4)	  Authorize (nextstep)
	(5)	  Return Success
	(6)	 Else
	(7)	  Writeblockchain (false)
	(8)	  Return Alarm (“the sig";"""dc.publisher"",""Hindawi""
""og:image"",""https://images.hindawi.com/journals/scn/scn.banner.jpg""
""og:image:width"",""600""
""twitter:card"",""summary_large_image""
""citation_journal_title"",""Security and Communication Networks""
""language"",""en""
""og:description"",""The barriers of food enterprises and departments caused information asymmetry, which is the root cause of food safety incidents. Simultaneously, it is challenging to solve the information asymmetry by the existing cloud-based food supply-chain regulation system. Establishing a secure and reliable data sharing environment is an effective solution to the information island. Blockchain can construct a security network based on mathematical algorithms, eliminating the third party&#x2019;s potential security risk, and realize transparently share data. In this paper, on the principle of metadata remaining in the food enterprises, we propose a blockchain-cloud fusion scheme based on Decentralized Attribute-Based Signature (DABS) to realize secure data sharing between departments. It constructs a decentralized and trusting environment for data owners to share data and achieves social co-governance of food safety based on the smart contract. It can also preserve the existing system architecture and complement the performance disadvantage of blockchain and cloud storage. The result achieved from security analysis shows that our scheme supports unconditional full anonymity and can resist collusion attacks of N-1 out of N corrupted attribute authorities.""
""prism.issn"",""1939-0114""
""citation_issn"",""1939-0114""
""dc:title"",""Cross-Department Secures Data Sharing in Food Industry via Blockchain-Cloud Fusion Scheme""
""Content-Encoding"",""UTF-8""
""citation_pdf_url"",""https://downloads.hindawi.com/journals/scn/2021/6668339.pdf""
""robots"",""index""
""google-site-verification"",""AxEuDsL7vXGOxRe53-uFhOk2ODN0bbXMeuBy6Pfq4ww""
""citation_author"",""Tao, Q."",""Chen, Q."",""Ding, H."",""Adnan, I."",""Huang, X."",""Cui, X.""
""dc.date"",""2021/03/27""
""prism.volume"",""2021""
""citation_doi"",""https://doi.org/10.1155/2021/6668339""
""prism.publicationName"",""Security and Communication Networks""
""dc.title"",""Cross-Department Secures Data Sharing in Food Industry via Blockchain-Cloud Fusion Scheme""
""Author"",""Hindawi""
""citation_volume"",""2021""
""dc.language"",""en""
""Content-Language"",""en""
""authors"",""Q. Tao | Q. Chen | ... | X. Cui""
""citation_title"",""Cross-Department Secures Data Sharing in Food Industry via Blockchain-Cloud Fusion Scheme""
""citation_year"",""2021""
""citation_publisher"",""Hindawi""
""dc.format"",""text/html""
""description"",""The barriers of food enterprises and departments caused information asymmetry, which is the root cause of food safety incidents. Simultaneously, it is challenging to solve the information asymmetry by the existing cloud-based food supply-chain regulation system. Establishing a secure and reliable data sharing environment is an effective solution to the information island. Blockchain can construct a security network based on mathematical algorithms, eliminating the third party&#x2019;s potential security risk, and realize transparently share data. In this paper, on the principle of metadata remaining in the food enterprises, we propose a blockchain-cloud fusion scheme based on Decentralized Attribute-Based Signature (DABS) to realize secure data sharing between departments. It constructs a decentralized and trusting environment for data owners to share data and achieves social co-governance of food safety based on the smart contract. It can also preserve the existing system architecture and complement the performance disadvantage of blockchain and cloud storage. The result achieved from security analysis shows that our scheme supports unconditional full anonymity and can resist collusion attacks of N-1 out of N corrupted attribute authorities.""
""og:image:type"",""image/jpeg""
""citation_date"",""2021/03/27""
""title"",""Cross-Department Secures Data Sharing in Food Industry via Blockchain-Cloud Fusion Scheme"",""Cross-Department Secures Data Sharing in Food Industry via Blockchain-Cloud Fusion Scheme""
""twitter:image"",""https://images.hindawi.com/journals/scn/scn.banner.jpg""
""citation_online_date"",""2021/03/27""
""twitter:site"",""website""
""dc.type"",""Research Article""
""dc.source"",""Security and Communication Networks""
""dc.creator"",""Tao, Q."",""Chen, Q."",""Ding, H."",""Adnan, I."",""Huang, X."",""Cui, X.""
""citation_fulltext_html_url"",""https://www.hindawi.com/journals/scn/2021/6668339/""
""prism.publicationDate"",""2021/03/27""
""Content-Length"",""2661488""
""citation_xml_url"",""https://downloads.hindawi.com/journals/scn/2021/6668339.xml""
""Content-Type"",""text/html; charset=UTF-8""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""og:type"",""website""
""twitter:title"",""Cross-Department Secures Data Sharing in Food Industry via Blockchain-Cloud Fusion Scheme""
""dc.description"",""The barriers of food enterprises and departments caused information asymmetry, which is the root cause of food safety incidents. Simultaneously, it is challenging to solve the information asymmetry by the existing cloud-based food supply-chain regulation system. Establishing a secure and reliable data sharing environment is an effective solution to the information island. Blockchain can construct a security network based on mathematical algorithms, eliminating the third party&#x2019;s potential security risk, and realize transparently share data. In this paper, on the principle of metadata remaining in the food enterprises, we propose a blockchain-cloud fusion scheme based on Decentralized Attribute-Based Signature (DABS) to realize secure data sharing between departments. It constructs a decentralized and trusting environment for data owners to share data and achieves social co-governance of food safety based on the smart contract. It can also preserve the existing system architecture and complement the performance disadvantage of blockchain and cloud storage. The result achieved from security analysis shows that our scheme supports unconditional full anonymity and can resist collusion attacks of N-1 out of N corrupted attribute authorities.""
""og:title"",""Cross-Department Secures Data Sharing in Food Industry via Blockchain-Cloud Fusion Scheme""
""citation_abstract"",""The barriers of food enterprises and departments caused information asymmetry, which is the root cause of food safety incidents. Simultaneously, it is challenging to solve the information asymmetry by the existing cloud-based food supply-chain regulation system. Establishing a secure and reliable data sharing environment is an effective solution to the information island. Blockchain can construct a security network based on mathematical algorithms, eliminating the third party&#x2019;s potential security risk, and realize transparently share data. In this paper, on the principle of metadata remaining in the food enterprises, we propose a blockchain-cloud fusion scheme based on Decentralized Attribute-Based Signature (DABS) to realize secure data sharing between departments. It constructs a decentralized and trusting environment for data owners to share data and achieves social co-governance of food safety based on the smart contract. It can also preserve the existing system architecture and complement the performance disadvantage of blockchain and cloud storage. The result achieved from security analysis shows that our scheme supports unconditional full anonymity and can resist collusion attacks of N-1 out of N corrupted attribute authorities.""
""og:image:height"",""315""
""prism.doi"",""https://doi.org/10.1155/2021/6668339""
""dcterms.issued"",""2021/03/27""
""viewport"",""width=device-width, initial-scale=1""
""twitter:description"",""The barriers of food enterprises and departments caused information asymmetry, which is the root cause of food safety incidents. Simultaneously, it is challenging to solve the information asymmetry by the existing cloud-based food supply-chain regulation system. Establishing a secure and reliable data sharing environment is an effective solution to the information island. Blockchain can construct a security network based on mathematical algorithms, eliminating the third party&#x2019;s potential security risk, and realize transparently share data. In this paper, on the principle of metadata remaining in the food enterprises, we propose a blockchain-cloud fusion scheme based on Decentralized Attribute-Based Signature (DABS) to realize secure data sharing between departments. It constructs a decentralized and trusting environment for data owners to share data and achieves social co-governance of food safety based on the smart contract. It can also preserve the existing system architecture and complement the performance disadvantage of blockchain and cloud storage. The result achieved from security analysis shows that our scheme supports unconditional full anonymity and can resist collusion attacks of N-1 out of N corrupted attribute authorities.""
""dc.identifier"",""https://doi.org/10.1155/2021/6668339""
""prism.section"",""Research Article""
""og:url"",""https://www.hindawi.com/journals/scn/2021/6668339/""
";https://scholar.google.ch/scholar?start=40&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2021
1619099124-455;https://scholar.google.ch/scholar?as_ylo=2021&q=oracles+blockchain&hl=fr&as_sdt=0,5;A secure and efficient authentication and data sharing scheme for Internet of Things based on blockchain;Q Fan, J Chen, LJ Deborah, M Luo ; Journal of Systems Architecture, 2021  Elsevier;;"… Journal of Systems Architecture. A secure and efficient authentication and data sharing

scheme for Internet of Things based on blockchain? … Blockchain is a burgeoning technology

supporting for efficient authentication and secure data sharing …";Les 2 versions;;null;;;;https://scholar.google.ch/scholar?start=40&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2021
1619099120-446;https://scholar.google.ch/scholar?as_ylo=2021&q=oracles+blockchain&hl=fr&as_sdt=0,5;Blockchain: Speed, Efficiency, Decreased Costs, and Technical Challenges;A Wilkie, SS Smith ; The Emerald Handbook of Blockchain for …, 2021  emerald.com;;"… The third approach to cross-chain interoperability employs an agent, known as an oracle, to

transfer external data to a blockchain. Oracles use smart contracts to add information about

real-world events such as temperatures, prices, or other information, onto a …";Les 3 versions;;null;;;;https://scholar.google.ch/scholar?start=30&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2021
1619099120-444;https://scholar.google.ch/scholar?as_ylo=2021&q=oracles+blockchain&hl=fr&as_sdt=0,5;Bringing trust and transparency to the opaque world of waste management with blockchain: a Polkadot parathread application;I Scott, M de Castro Neto… ; Available at SSRN …, 2021  papers.ssrn.com;;"… The main difference between crypto currencies and tokens, is that crypto currencies are …

specification of the approach to data management, performance, security, oracles, and smart …

these approaches can be implemented in practice with the selected blockchain protocol using …";;null;null;;;;https://scholar.google.ch/scholar?start=30&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2021
1619099133-474;https://scholar.google.ch/scholar?as_ylo=2021&q=oracles+blockchain&hl=fr&as_sdt=0,5;Distributed auditing protocol for blockchain?based transactions using a distributed signature;S Banaeian Far, A Imani Rad ; Security and Privacy  Wiley Online Library;;"… Finally, we analyze the security of the DA?DS protocol in the random oracle (RO) model and

show that it has the security requirements has to have. Then, we evaluate it and compare it with

recently proposed blockchain?based auditing protocols and show that it is more efficient …";;null;[PDF] wiley.com;https://onlinelibrary.wiley.com/doi/pdf/10.1002/spy2.156;;;https://scholar.google.ch/scholar?start=60&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2021
1619099120-441;https://scholar.google.ch/scholar?as_ylo=2021&q=oracles+blockchain&hl=fr&as_sdt=0,5;[PDF][PDF] Decentralized Finance–The Possibilities of a Blockchain “Money Lego” System;T Katona ; enhitelintezetiszemle.mnb.hu;;"… 2020:2). Most often, such data is the real- time price feed of crypto-assets. Oracles alone do not

qualify as data sources; they represent a layer that verifies real-world events related to data on

the blockchain and submits cumulative data to smart contracts (Tiwari 2020) …";;;[PDF] mnb.hu;https://en-hitelintezetiszemle.mnb.hu/letoltes/fer-20-1-st3-katona.pdf;;;https://scholar.google.ch/scholar?start=30&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2021
1619099111-427;https://scholar.google.ch/scholar?as_ylo=2021&q=oracles+blockchain&hl=fr&as_sdt=0,5;Blockchain-as-a-Service;V Dhillon, D Metcalf, M Hooper ; Blockchain Enabled Applications, 2021  Springer;;"… Microsoft Azure Blockchain docs (https://azure.microsoft.com/en-us/solutions/blockchain/),

Blockchain AWS docs (https://aws.amazon.com/blockchain/), Oracle Platform docs

(https://www.oracle.com/application-development/cloud-services/blockchain-platform/), and …";;null;null;;;;https://scholar.google.ch/scholar?start=10&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2021
1619099124-452;https://scholar.google.ch/scholar?as_ylo=2021&q=oracles+blockchain&hl=fr&as_sdt=0,5;[PDF][PDF] La résolution des litiges blockchain;LC Ferreira ; lextechinstitute.ch;;"… edu/jcfl/2018/02/21/silk-road- the-dark-side-of-cryptocurrency/, consulté le … BUCHWALD MICHAEL,

Smart Contract Dispute Resolution : The Inescapable Flaws of Blockchain-Based Arbitration …

BUTERIN VITALIK, Endnotes on 2020 : Crypto and Beyond, 28 décembre 2020, https …";Les 2 versions;Version HTML;[PDF] lextechinstitute.ch;https://www.lextechinstitute.ch/wp-content/uploads/2021/02/Memoire_Leonel-Ferreira.pdf;"
UNIVERSITÉ DE NEUCHÂTEL – FACULTÉ DE DROIT  JANVIER 2021 

 

  

 

 

 

La rĂŠsolution des litiges blockchain 
 

Vers un arbitrage dĂŠcentralisĂŠ ? 

 

 
MĂŠmoire de Master 

 

UniversitÊ de Neuchâtel 

 

 

 

Leonel Constantino Ferreira 

 
 

 

 

Sous la direction de la Professeure Florence Guillaume 

 

 

 

 

 

 

 

 



I 

 

Table des matières 

Table des matières .................................................................................................................. I 

Bibliographie ....................................................................................................................... III 

Table des abrĂŠviations ...................................................................................................... XIV 

I. Introduction ............................................................................................................. 1 

II. La blockchain et ses litiges inĂŠvitables ................................................................... 3 

A. La technologie blockchain en quelques mots ............................................................ 3 

1. Une technologie des registres distribuĂŠs ............................................................... 3 

2. Un mĂŠcanisme de consensus ................................................................................. 4 

3. Les diffĂŠrents types de blockchain ........................................................................ 6 

B. Les smart contracts ................................................................................................... 6 

1. La notion de smart contract .................................................................................. 6 

2. Les smart contracts en tant que contrat juridique ................................................. 8 

3. Les decentralised autonomous organizations ....................................................... 9 

C. Les litiges blockchain .............................................................................................. 11 

1. L’existence des litiges blockchain ....................................................................... 11 

2. Les caractĂŠristiques des litiges blockchain .......................................................... 13 

D. Les exemples de litiges blockchain ......................................................................... 16 

1. Les litiges liés à l’utilisation de smart contracts ................................................. 16 

2. Les litiges liés aux investissements dans le cadre d’une initial coin offering ..... 17 

3. Les hacks de The DAO et Parity ......................................................................... 19 

4. Les litiges de gouvernance .................................................................................. 21 

5. Le token curated registry de Kleros .................................................................... 23 

III. À la recherche de la juridiction appropriée à la résolution des litiges 

blockchain ........................................................................................................................... 24 

A. Les limites de l’intervention étatique dans la résolution des litiges blockchain ..... 24 

1. L’étendue et l’infrastructure du réseau ................................................................ 24 

2. L’anonymat ......................................................................................................... 27 

3. L’exécution automatique et l’immutabilité ......................................................... 29 

4. Les coĂťts et la rapiditĂŠ ......................................................................................... 31 



II 

 

B. La crĂŠation de mĂŠcanismes de rĂŠsolution des litiges en ligne ................................. 32 

1. La notion de rĂŠsolution des litiges en ligne ......................................................... 32 

2. Le cadre lĂŠgal de la rĂŠsolution des litiges en ligne .............................................. 34 

3. La résolution des litiges en ligne dans l’environnement blockchain .................. 35 

IV. Les mĂŠcanismes de rĂŠsolution des litiges blockchain.......................................... 38 

A. Les exemples de mĂŠcanismes de rĂŠsolution des litiges blockchain ........................ 38 

1. Les systèmes d’escrow ........................................................................................ 38 

2. CodeLegit et JAMS ............................................................................................. 39 

3. OpenBazaar ......................................................................................................... 42 

4. Mattereum ........................................................................................................... 43 

5. Kleros et la Cour Aragon .................................................................................... 45 

B. Les caractĂŠristiques communes aux mĂŠcanismes de rĂŠsolution des litiges 

blockchain ....................................................................................................................... 52 

1. Des mĂŠcanismes consensuels de rĂŠsolution des litiges en ligne ......................... 52 

2. Des mĂŠcanismes classiques (off chain) ou disruptifs (on chain) ........................ 53 

3. Un protocole de rĂŠsolution des litiges ................................................................. 54 

C. Les critères permettant de dÊsigner le mÊcanisme de rÊsolution des litiges 

blockchain adĂŠquat .......................................................................................................... 56 

1. Le critère de la lÊgitimitÊ .................................................................................... 56 

2. Le critère de l’effectivité ..................................................................................... 57 

3. Le critère de l’utilité ............................................................................................ 59 

D. Vers un arbitrage dĂŠcentralisĂŠ ? .............................................................................. 62 

1. La qualification de Kleros en tant qu’arbitrage ................................................... 62 

2. Le champ d’application de la Convention de New York .................................... 64 

3. L’arbitrage délocalisé et la technologie blockchain ............................................ 67 

4. La validité de la convention d’arbitrage et de la sentence arbitrale .................... 69 

5. Le respect du droit à un procès Êquitable ............................................................ 73 

V. Conclusion .............................................................................................................. 77 

  



III 

 

Bibliographie 

ABRAMOWICZ MICHAEL, Cryptocurrency-Based Law, Arizona Law Review, vol. 58, 2016, 

p. 359 Ă  420. 

ADLER DANIEL, Silk Road : The Dark Side of Cryptocurrency, Fordham Journal of Corporate 

& Financial Law, 21 fĂŠvrier 2018, https://news.law.fordham.edu/jcfl/2018/02/21/silk-road-

the-dark-side-of-cryptocurrency/, consultĂŠ le 25 janvier 2021. 

ALAG ASHITA / RAMPHUL JOY, Interaction between Blockchain Technology and 

Arbitration, ADR Arbitration Chambers, 14 janvier 2020, https://www.adrarbitration.ch/bl

og/interaction-between-blockchain-technology-and-arbitration, consultĂŠ le 25 janvier 2021. 

ALLEN DARCY / LANE AARON / POBLET MARTA, The Governance of Blockchain Dispute 

Resolution, Harvard Negotiation Law Review, vol. 25, 2019, p. 75 Ă  101. 

ARAGON, The Aragon White Paper, GitHub, 18 juillet 2019, https://github.com/aragon/whi

tepaper, (citĂŠ : ARAGON, White paper). 

ASSEMBLÉE PARLEMENTAIRE DU CONSEIL DE L’EUROPE, Résolution CE 2081, L’accès à la 

justice et internet : potentiel et dĂŠfis, 27 novembre 2015 (citĂŠ : RĂŠsolution CE 2081). 

AST FEDERICO, Kleros : A Supreme Court for the Internet, in : Kleros (ĂŠdit.), Dispute 

Revolution – The Kleros Handbook of Decentralized Justice, 2e éd., avril 2020, p. 97 à 105 

(citĂŠ : AST, Supreme court). 

AST FEDERICO, Kleros Layer 2 : Decentralized Justice in the Mainstream World, in : 

Kleros (édit.), Dispute Revolution – The Kleros Handbook of Decentralized Justice, 2e éd., 

avril 2020, p. 431 Ă  439 (citĂŠ : AST, Kleros layer 2). 

AST FEDERICO / LESAEGE CLÉMENT, Kleros, a Protocol for Decentralized Justice, in : 

Kleros (édit.), Dispute Revolution – The Kleros Handbook of Decentralized Justice, 2e éd., 

avril 2020, p. 30 Ă  61. 

ATZORI MARCELLA, Blockchain Technology and Decentralized Governance : Is the State 

Still Necessary ?, Journal of Governance and Regulation, vol. 6, 2017, p. 45 Ă  62. 

AUTORITÉ FÉDÉRALE DE SURVEILLANCE DES MARCHÉS FINANCIERS (FINMA), Guide pratique 

pour les questions d’assujettissement concernant les initial coin offerings (ICO), 16 février 

2018, https://www.finma.ch/fr/news/2018/02/20180216-mm-ico-wegleitung/, consultĂŠ le 

25 janvier 2021 (citĂŠ : FINMA, Guide ICO). 

BACON JEAN et al., Blockchain Demystified : A Technical and Legal Introduction to 

Distributed and Centralised Ledgers, Richmond Journal of Law and Technology, vol. 25, 

2018, https://jolt.richmond.edu/files/2018/11/Michelsetal-Final-1.pdf, consultĂŠ le 25 janvier 

2021. 

https://news.law.fordham.edu/jcfl/2018/02/21/silk-road-the-dark-side-of-cryptocurrency/
https://news.law.fordham.edu/jcfl/2018/02/21/silk-road-the-dark-side-of-cryptocurrency/
https://www.adrarbitration.ch/blog/interaction-between-blockchain-technology-and-arbitration
https://www.adrarbitration.ch/blog/interaction-between-blockchain-technology-and-arbitration
https://github.com/aragon/whitepaper
https://github.com/aragon/whitepaper
https://www.finma.ch/fr/news/2018/02/20180216-mm-ico-wegleitung/
https://jolt.richmond.edu/files/2018/11/Michelsetal-Final-1.pdf


IV 

 

BAKER PADDY, Tezos Investors Win $25M Settlement in Court Case Over $230M ICO, 

Coindesk, 1er septembre 2020, https://www.coindesk.com/tezos-investors-win-25m-

settlement-in-court-case-over-230m-ico, consultĂŠ le 25 janvier 2021. 

BUCHER ANDREAS, art. 176, 192 et 194 LDIP, in : Bucher Andreas (ĂŠdit.), Commentaire 

romand, Loi sur le droit international privé – Convention de Lugano, Bâle 2011 (cité : 

CR LDIP, BUCHER). 

BUCHLEITNER CHRISTINA / RABL THOMAS, Blockchain und Smart Contracts – Revolution 

oder alter Wein im digitalen Schlauch ?, ecolex Fachzeitschrift fĂźr Wirtschaftsrecht, 2017, 

p. 4 Ă  17. 

BUCHWALD MICHAEL, Smart Contract Dispute Resolution : The Inescapable Flaws of 

Blockchain-Based Arbitration, University of Pennsylvania Law Review, vol. 168, 2020, 

p. 1369 Ă  1423. 

BUTERIN VITALIK, Endnotes on 2020 : Crypto and Beyond, 28 dĂŠcembre 2020, 

https://vitalik.ca/general/2020/12/28/endnotes.html, consultĂŠ le 25 janvier 2021 (citĂŠ : 

BUTERIN, Endnotes on 2020). 

BUTERIN VITALIK, Ethereum White Paper, version du 9 dĂŠcembre 2020, 

https://ethereum.org/en/whitepaper/, consultĂŠ le 25 janvier 2021 (citĂŠ : BUTERIN, Ethereum 

white paper). 

BUTERIN VITALIK, The Meaning of Decentralization, Medium, 6 fĂŠvrier 2017, 

https://medium.com/@VitalikButerin/the-meaning-of-decentralization-a0c92b76a274, 

consultĂŠ le 25 janvier 2021 (citĂŠ : BUTERIN, The meaning of decentralization). 

BUTERIN VITALIK, DAOs, DACs, DAs and More : An Incomplete Terminology Guide, 

Ethereum Blog, 6 mai 2014, https://blog.ethereum.org/2014/05/06/daos-dacs-das-and-more-

an-incomplete-terminology-guide/, consultĂŠ le 25 janvier 2021 (citĂŠ : BUTERIN, DAOs, 

DACs, DAs and more). 

BUTERIN VITALIK, Decentralized Protocol Monetization and Forks, Ethereum Blog, 30 avril 

2014, https://blog.ethereum.org/2014/04/30/decentralized-protocol-monetization-and-

forks/, consultĂŠ le 25 janvier 2021 (citĂŠ : BUTERIN, Decentralized protocol monetization and 

forks). 

CARRON BLAISE / BOTTERON VALENTIN, Le droit des obligations face aux ÂŤ contrats 

intelligents Âť : Blockchain, Smart Contracts et contrats de droit suisse, in : Carron Blaise / 

MĂźller Christoph (ĂŠdit.), 3e JournĂŠe des droits de la consommation et de la distribution : 

Blockchain et Smart Contracts, dÊfis juridiques, Bâle / Neuchâtel 2018, p. 1 à 50. 

CODELEGIT, CodeLegit White Paper on Blockchain Arbitration, https://docs.google.com/d

ocument/d/1v_AdWbMuc2Ei70ghITC1mYX4_5VQsF_28O4PsLckNM4/edit, consultĂŠ le 

25 janvier 2021 (citĂŠ : CODELEGIT, White paper). 

https://www.coindesk.com/tezos-investors-win-25m-settlement-in-court-case-over-230m-ico
https://www.coindesk.com/tezos-investors-win-25m-settlement-in-court-case-over-230m-ico
https://vitalik.ca/general/2020/12/28/endnotes.html
https://ethereum.org/en/whitepaper/
https://medium.com/@VitalikButerin/the-meaning-of-decentralization-a0c92b76a274
https://blog.ethereum.org/2014/05/06/daos-dacs-das-and-more-an-incomplete-terminology-guide/
https://blog.ethereum.org/2014/05/06/daos-dacs-das-and-more-an-incomplete-terminology-guide/
https://blog.ethereum.org/2014/04/30/decentralized-protocol-monetization-and-forks/
https://blog.ethereum.org/2014/04/30/decentralized-protocol-monetization-and-forks/
https://docs.google.com/document/d/1v_AdWbMuc2Ei70ghITC1mYX4_5VQsF_28O4PsLckNM4/edit
https://docs.google.com/document/d/1v_AdWbMuc2Ei70ghITC1mYX4_5VQsF_28O4PsLckNM4/edit


V 

 

COMMISSION DES NATIONS UNIES POUR LE DROIT COMMERCIAL INTERNATIONAL (CNUDCI), 

Guide du secrétariat de la CNUDCI sur la Convention pour la reconnaissance et l’exécution 

des sentences arbitrales Êtrangères (New York, 1958), New York 2017 (citÊ : CNUDCI, 

Guide sur la CNY). 

COMMISSION DES NATIONS UNIES POUR LE DROIT COMMERCIAL INTERNATIONAL (CNUDCI), 

Notes techniques sur le règlement des litiges en ligne, New York 2017 (citÊ : CNUDCI, 

Notes techniques ODR). 

COMMISSION DES NATIONS UNIES POUR LE DROIT COMMERCIAL INTERNATIONAL (CNUDCI), 

RĂŠsolution des litiges en ligne dans les opĂŠrations internationales de commerce ĂŠlectronique 

projet de règlement de procÊdure, A/CN.9/WG.III/WP.123, Session du 18 au 23 novembre 

2013 (citĂŠ : CNUDCI, RĂŠsolution des litiges en ligne). 

COMMISSION DES NATIONS UNIES POUR LE DROIT COMMERCIAL INTERNATIONAL (CNUDCI), 

Guide pour l’incorporation dans le droit interne de la Loi type de la CNUDCI sur le 

commerce électronique – avec le nouvel article 5bis tel qu’adopté en 1998, New York 1999 

(citĂŠ : CNUDCI, Guide de la Loi type sur le commerce ĂŠlectronique). 

CORTÉS PABLO, Online Dispute Resolution for Consumers in the European Union, 

Oxford / New York 2011. 

COUR EUROPÉENNE DES DROITS DE L’HOMME (CourEDH), Guide sur l’article 6 de la 

Convention européenne des droits de l’homme – Droit à un procès équitable (volet civil), 31 

août 2018 (cité : CourEDH, Guide sur l’art. 6 CEDH). 

DE FILIPPI PRIMAVERA / LOVELUCK BENJAMIN, The Invisible Politics of 

Bitcoin : Governance Crisis of a Decentralised Infrastructure, Internet Policy Review, 

vol. 5, 30 septembre 2016, https://policyreview.info/articles/analysis/invisible-politics-

bitcoin-governance-crisis-decentralised-infrastructure, consultĂŠ le 25 janvier 2021. 

DE FILIPPI PRIMAVERA / WRIGHT AARON, Blockchain and The Law : The Rule of Code, 

Cambridge 2018. 

DEVANESAN RUHA / ARESTY JEFFREY, ODR and Justice, in : Wahab Mohamed Abdel / Katsh 

Ethan / Rainey Daniel (ĂŠdit.), Online Dispute Resolution Theory and Practice, La Haye 

2012, p. 263 Ă  305. 

DE WERRA JACQUES / SCHULTZ THOMAS, RĂŠglementer la rĂŠsolution des litiges en ligne en 

Suisse : dĂŠfis et enseignements de la pratique, Informatica e Diritto, 2007, p. 431 Ă  475. 

DI ANNA MESSIA, Assicurazioni, la blockchain entra nell’ RC auto, Ania, 28 juin 2018, 

https://www.ania.it/documents/35135/0/Assicurazioni.+La+blockchain+entra+nella+RC+

Auto+Milano+Finanza+28.06.2018+%282%29.pdf/bc45f049-9684-e861-aa14-

3b15cef1f72b?t=1575393203941, consultĂŠ le 25 janvier 2021. 

https://policyreview.info/articles/analysis/invisible-politics-bitcoin-governance-crisis-decentralised-infrastructure
https://policyreview.info/articles/analysis/invisible-politics-bitcoin-governance-crisis-decentralised-infrastructure
https://www.ania.it/documents/35135/0/Assicurazioni.+La+blockchain+entra+nella+RC+Auto+Milano+Finanza+28.06.2018+%282%29.pdf/bc45f049-9684-e861-aa14-3b15cef1f72b?t=1575393203941
https://www.ania.it/documents/35135/0/Assicurazioni.+La+blockchain+entra+nella+RC+Auto+Milano+Finanza+28.06.2018+%282%29.pdf/bc45f049-9684-e861-aa14-3b15cef1f72b?t=1575393203941
https://www.ania.it/documents/35135/0/Assicurazioni.+La+blockchain+entra+nella+RC+Auto+Milano+Finanza+28.06.2018+%282%29.pdf/bc45f049-9684-e861-aa14-3b15cef1f72b?t=1575393203941


VI 

 

DIMOV DANIEL, Is Kleros Fair?, in : Kleros (édit.), Dispute revolution – The Kleros 

Handbook of Decentralized Justice, 2e ĂŠd., avril 2020, p. 267 Ă  273. 

EHLE BERND, art. I CNY, in : Wolff Reinmar (ĂŠdit.), New York Convention, Article-by-

article Commentary, 2e ĂŠd., Munich 2019. 

EUROPEAN UNION BLOCKCHAIN OBSERVATORY AND FORUM (EUBOF), Legal and 

Regulatory Framework of Blockchains and Smart Contracts, 27 septembre 2019, 

https://www.eublockchainforum.eu/sites/default/files/reports/report_legal_v1.0.pdf, 

consultĂŠ le 25 janvier 2021 (citĂŠ : EUBOF, Rapport thĂŠmatique). 

FINCK MICHÈLE, Blockchain Regulation and Governance in Europe, Cambridge 2019. 

FURRER ANDREAS / MÜLLER LUKA, « Funktionale Äquivalenz » digitaler Rechtsgeschäfte – 

Ein tragendes Grundprinzip fĂźr die Beurteilung der RechtsgĂźltigkeit von Rechtsinstituten 

und Rechtsgeschäften im schweizerischen Recht, Jusletter Weblaw, 18 juin 2018. 

GEORGE WILLIAM, Why Kleros Needs a Native Token : Security and Incentives in 

Decentralized Justice, in : Kleros (édit.), Dispute Revolution – The Kleros Handbook of 

Decentralized Justice, 2e ĂŠd., avril 2020, p. 128 Ă  133. 

GLARNER ANDREAS / MEYER STHEPAN, Smart Contracts in Escrow-Verhältnissen, Jusletter 

Weblaw IT, 4 dĂŠcembre 2017. 

GOFORTH CAROL, SEC vs. Ripple : A Predictable but Undesirable Development, 

Cointelegraph, 27 dĂŠcembre 2020, https://cointelegraph.com/news/sec-vs-ripple-a-

predictable-but-undesirable-development, consultĂŠ le 25 janvier 2021. 

GRIGG IAN, The Ricardian Contract, Iang, 2000, https://iang.org/papers/ricardian_contract.

html#index, consultĂŠ le 25 janvier 2021. 

GRISET ALEX, Le Bitcoin pour lutter contre l’inflation ?, Cryptoast, 16 juillet 2020, 

https://cryptoast.fr/bitcoin-lutte-inflation/, consultĂŠ le 25 janvier 2021. 

GUILLAUME FLORENCE, Blockchain : Le pont du droit international privé entre l’espace 

numérique et l’espace physique, in : Pretelli Ilaria (édit.) : Le droit international privé dans 

le labyrinthe des plateformes digitales – Acte de la 30e journée de droit international privé 

du 28 juin 2018 à Lausanne, Genève / Zurich / Bâle 2018, p. 163 à 189. 

GUPTA VINAY, Knowledge is power – Object Omniscience and Realising the Full Value of 

our Assets, Part 3, Medium, 19 novembre 2019, https://medium.com/humanizing-the-

singularity/knowledge-is-power-object-omniscience-and-realising-the-full-value-of-our-

assets-6654af5e9826, consultĂŠ le 25 janvier 2021. 

GUPTA VINAY et al., Mattereum working paper, Smart Contracts, Real Property, 3 fĂŠvrier 

2020, https://mattereum.com/wp-content/uploads/2020/02/mattereum_workingpaper.pdf, 

consultĂŠ le 25 janvier 2021 (citĂŠ : GUPTA et al., Mattereum working paper). 

https://www.eublockchainforum.eu/sites/default/files/reports/report_legal_v1.0.pdf
https://cointelegraph.com/news/sec-vs-ripple-a-predictable-but-undesirable-development
https://cointelegraph.com/news/sec-vs-ripple-a-predictable-but-undesirable-development
https://iang.org/papers/ricardian_contract.html#index
https://iang.org/papers/ricardian_contract.html#index
https://cryptoast.fr/bitcoin-lutte-inflation/
https://medium.com/humanizing-the-singularity/knowledge-is-power-object-omniscience-and-realising-the-full-value-of-our-assets-6654af5e9826
https://medium.com/humanizing-the-singularity/knowledge-is-power-object-omniscience-and-realising-the-full-value-of-our-assets-6654af5e9826
https://medium.com/humanizing-the-singularity/knowledge-is-power-object-omniscience-and-realising-the-full-value-of-our-assets-6654af5e9826
https://mattereum.com/wp-content/uploads/2020/02/mattereum_workingpaper.pdf


VII 

 

HANZL MARTIN, Handbuch Blockchain und Smart Contracts, Vienne 2020. 

HARI OLIVIER / DU PASQUIER ULYSSE, ChaĂŽne de blocs et Distributed Ledger Technology 

(DLT) : Panorama pÊdagogique technico-juridique et enjeux pour le juriste du XXIème 

siècle, Revue de Droit des Affaires Internationales, vol. 5, 2018, p. 423 à 447. 

HEETKAMP SIMON JOHANNES, Online Dispute Resolution bei grenzĂźberschreitenden 

Verbraucherverträgen, GÜttingen 2018. 

HESTER JAMES, Introducing the Mattereum Asset Passport, Medium, 19 novembre 2019, 

https://medium.com/humanizing-the-singularity/introducing-the-mattereum-asset-passport-

72f28c9ba6f1, consultĂŠ le 25 janvier 2021. 

HOLLANDER-BLUMOFF REBECCA / TYLER TOM, Procedural Justice and the Rule of Law : 

Fostering Legitimacy in Alternative Dispute Resolution, Journal of Dispute Resolution, 

2011, p. 1 Ă  19. 

IZQUIERDO JORGE / ARAGON ONE, Introducing Aragon Agreements, Blog Aragon, 5 fĂŠvrier 

2020, https://blog.aragon.one/aragon-agreements/, consultĂŠ le 25 janvier 2021. 

JAMES STUART, Handing over the Reigns – Kleros Governance Moves to Snapshot, Blog 

Kleros, 16 dĂŠcembre 2020, https://blog.kleros.io/handing-over-the-reigns-kleros-

governance-moves-to-snapshot/, consultĂŠ le 25 janvier 2021 (citĂŠ : JAMES, Governance). 

JAMES STUART, Tokens Reward Program – Securing Uniswap with Decentralized Lists, 

Blog Kleros, 10 septembre 2020, https://blog.kleros.io/tokens-by-kleros-securing-uniswap-

with-decentralized-lists/, consultĂŠ le 25 janvier 2021 (citĂŠ : JAMES, Uniswap). 

JENTZSCH CHRISTOPH, Decentralized Autonomous Organization to Automate 

Governance, LexBlog, https://lawofthelevel.lexblogplatformthree.com/wp-

content/uploads/sites/187/2017/07/WhitePaper-1.pdf, consultĂŠ le 25 janvier 2021. 

KAAL WULF / CALCATERRA CRAIG, Crypto Transaction Dispute Resolution, Business 

Lawyer, vol. 73, 2017-2018, p. 109 Ă  152. 

KÄRKI TATU, Aragon Network Jurisdiction Part 1 : Decentralized Court, Medium, 18 

juillet 2017, https://medium.com/aragondec/aragon-network-jurisdiction-part-1-

decentralized-court-c8ab2a675e82, consultĂŠ le 25 janvier 2021. 

KATSH ETHAN / RABINOVICH-EINY ORNA, Digital Justice – Technology and the Internet of 

Disputes, New York 2017. 

KELLEHER KEVIN, The gold rush days of bitcoin mining are over, and not because of the 

price, Quartz, 22 dĂŠcembre 2014, https://qz.com/316898/the-gold-rush-days-of-bitcoin-

mining-are-over-and-not-because-of-the-price/, consultĂŠ le 25 janvier 2021. 

https://medium.com/humanizing-the-singularity/introducing-the-mattereum-asset-passport-72f28c9ba6f1
https://medium.com/humanizing-the-singularity/introducing-the-mattereum-asset-passport-72f28c9ba6f1
https://blog.aragon.one/aragon-agreements/
https://blog.kleros.io/handing-over-the-reigns-kleros-governance-moves-to-snapshot/
https://blog.kleros.io/handing-over-the-reigns-kleros-governance-moves-to-snapshot/
https://blog.kleros.io/tokens-by-kleros-securing-uniswap-with-decentralized-lists/
https://blog.kleros.io/tokens-by-kleros-securing-uniswap-with-decentralized-lists/
https://lawofthelevel.lexblogplatformthree.com/wp-content/uploads/sites/187/2017/07/WhitePaper-1.pdf
https://lawofthelevel.lexblogplatformthree.com/wp-content/uploads/sites/187/2017/07/WhitePaper-1.pdf
https://medium.com/aragondec/aragon-network-jurisdiction-part-1-decentralized-court-c8ab2a675e82
https://medium.com/aragondec/aragon-network-jurisdiction-part-1-decentralized-court-c8ab2a675e82
https://qz.com/316898/the-gold-rush-days-of-bitcoin-mining-are-over-and-not-because-of-the-price/
https://qz.com/316898/the-gold-rush-days-of-bitcoin-mining-are-over-and-not-because-of-the-price/


VIII 

 

KHOKHLOV PETER / KONRADI BRIAN / DANILOV ANDREI, What to Look for in ICO Terms and 

Conditions, Coindesk, 25 fĂŠvrier 2018, https://www.coindesk.com/look-ico-terms-

conditions, consultĂŠ le 25 janvier 2021. 

KOULU RIIKKA / MARKKANEN KALLE, Conflict Management for Regulation-Averse 

Blockchains?, in : Ballardini Rosa Maria et al. (ĂŠdit.), Regulating Industrial Internet through 

IPR, Data Protection and Competition Law, Alphen-sur-le-Rhin 2019, p. 381 Ă  408. 

KREIS FALCO / KAULARTZ MARKUS, Smart Contracts and Dispute Resolution – A Chance to 

Raise Efficiency?, ASA Bulletin, vol. 37, 2019, p. 336 Ă  357. 

LAW COMMISSION OF ENGLAND AND WALES, Smart Contracts – Call for Evidence, 

dĂŠcembre 2020, https://s3-eu-west-2.amazonaws.com/lawcom-prod-storage-

11jsxou24uy7q/uploads/2020/12/201216-Smart-contracts-call-for-evidence.pdf, consultĂŠ le 

25 janvier 2021. 

LELOUP LAURENT, Blockchain – La révolution de la confiance, Paris 2017. 

LESAEGE CLÉMENT et al., A Smart Contract Arbitration Standard for Lex Cryptographia, in : 

Kleros (édit.), Dispute Revolution – The Kleros Handbook of Decentralized Justice, 2e éd., 

avril 2020, p. 343 Ă  351. 

LESAEGE CLÉMENT / AST FEDERICO / GEORGE WILLIAM, Kleros – Yellow Paper v. 1.0.0, 

mars 2020, https://kleros.io/static/yellowpaper_en-

28d8e155664f3f21578958a482f33bd1.pdf, consultĂŠ le 25 janvier 2021 (citĂŠ : 

LESAEGE / AST / GEORGE, Kleros yellow paper). 

LESAEGE CLÉMENT / AST FEDERICO / GEORGE WILLIAM, Kleros – Short paper v. 1.0.7, 

septembre 2019, https://kleros.io/static/whitepaper_en-

8bd3a0480b45c39899787e17049ded26.pdf, consultĂŠ le 25 janvier 2021 (citĂŠ : 

LESAEGE /AST / GEORGE, Kleros short paper). 

LESSIG LAWRENCE, Code – Version 2.0, New York 2006. 

MAECHLER ANDRÉA, Marchés financiers au fil du temps – Evolution dans le domaine du 

numérique : état des lieux et perspectives d’avenir, Exposé 

de la Banque nationale suisse (BNS), 5 avril 2018, https://www.snb.ch/fr/mmr/speeches/id/

ref_20180405_amr/source/ref_20180405_amr.fr.pdf, consultĂŠ le 25 janvier 2021 (citĂŠ : 

MAECHLER, Rapport de la BNS). 

MARIN-DAGANNAUD GAUTIER, Le fonctionnement de la blockchain, Annales des mines – 

RĂŠalitĂŠs Industrielles, 2017, p. 42 Ă  45, http://www.annales.org/ri/2017/ri-aout-2017/RI-

AOUT-2017-Article-MARIN-DAGANNAUD.pdf, consultĂŠ le 25 janvier 2021. 

https://www.coindesk.com/look-ico-terms-conditions
https://www.coindesk.com/look-ico-terms-conditions
https://s3-eu-west-2.amazonaws.com/lawcom-prod-storage-11jsxou24uy7q/uploads/2020/12/201216-Smart-contracts-call-for-evidence.pdf
https://s3-eu-west-2.amazonaws.com/lawcom-prod-storage-11jsxou24uy7q/uploads/2020/12/201216-Smart-contracts-call-for-evidence.pdf
https://kleros.io/static/yellowpaper_en-28d8e155664f3f21578958a482f33bd1.pdf
https://kleros.io/static/yellowpaper_en-28d8e155664f3f21578958a482f33bd1.pdf
https://kleros.io/static/whitepaper_en-8bd3a0480b45c39899787e17049ded26.pdf
https://kleros.io/static/whitepaper_en-8bd3a0480b45c39899787e17049ded26.pdf
https://www.snb.ch/fr/mmr/speeches/id/ref_20180405_amr/source/ref_20180405_amr.fr.pdf
https://www.snb.ch/fr/mmr/speeches/id/ref_20180405_amr/source/ref_20180405_amr.fr.pdf
http://www.annales.org/ri/2017/ri-aout-2017/RI-AOUT-2017-Article-MARIN-DAGANNAUD.pdf
http://www.annales.org/ri/2017/ri-aout-2017/RI-AOUT-2017-Article-MARIN-DAGANNAUD.pdf


IX 

 

MAUER MARCO / AST FEDERICO, Policies in Kleros : The Laws of Internet Courts, in : Kleros 

(édit.), Dispute Revolution – The Kleros Handbook of Decentralized Justice, 2e éd., avril 

2020, p. 140 Ă  145. 

MAYNARD SIMON / CHAN ELIZABETH, Decrypting cryptocurrencies : Why borderless 

currencies may benefit from borderless dispute resolution, Kluwer arbitration blog, 2 

novembre 2017, disponible sur : http://arbitrationblog.kluwerarbitration.com/2017/11/02/d

ecrypting-cryptocurrencies-borderless-currencies-may-benefit-borderless-dispute-resol. 

MEIER JULIA / SCHUPPLI BENEDIKT, The DAO hack and the living law of blockchain, in : Dal 

Molin-Kränzlin Alexandra et al. (édit.), Digitalisierung – Gesellschatft – Recht, Analysen 

und Perspektiven von Assistierenden des Rechtswissenschaftlichen Instituts der Universität 

Zürich, Zurich / Saint-Gall 2019, p. 27 à 43. 

METZGER JAMES, The Current Landscape of Blockchain-Based, Crowdsourced Arbitration, 

Macquarie Law Journal, vol. 19, 2019, p. 81 Ă  102 (citĂŠ : METZGER, Crowdsourced 

arbitration). 

METZGER JAMES, Decentralized Justice in the Era of Blockchain, International Journal of 

Online Dispute Resolution, vol. 5, 2018, p. 69 Ă  81 (citĂŠ : METZGER, Decentralized justice). 

MIK ELIZA, Smart Contracts : A Requiem, Journal of Contract Law (publication Ă  venir), 7 

dĂŠcembre 2019, https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3499998, consultĂŠ le 

25 janvier 2021. 

MÜLLER CHRISTOPH, Les « Smart Contracts » en droit des obligations suisse, in : Carron 

Blaise / MĂźller Christoph (ĂŠdit.), 3e JournĂŠe des droits de la consommation et de la 

distribution : Blockchain et Smart Contracts, dÊfis juridiques, Bâle / Neuchâtel 2018, p. 51 

Ă  114. 

NAKAMOTO SATOSHI, Bitcoin : A Peer-to-Peer Electronic Cash System, 2008, 

https://bitcoin.org/bitcoin.pdf, consultĂŠ le 25 janvier 2021 (citĂŠ : NAKAMOTO, Bitcoin white 

paper). 

NAROZHNY DMITRY, Is Kleros legal?, in : Kleros, Dispute revolution – The Kleros handbook 

of decentralized Justice, 2e ĂŠd., avril 2020, p. 274 Ă  277. 

NATIONAL CENTER OF TECHNOLOGY AND DISPUTE RESOLUTION (NCTDR), Ethical 

Principles for Online Dispute Resolution, 2016, http://odr.info/ethics-and-odr/, consultĂŠ le 

25 janvier 2021 (citĂŠ : NCTDR, Principes ĂŠthiques ODR). 

OETIKER CHRISTIAN, art. 194 LDIP, in : MĂźller-Chen Markus / Widmer LĂźchinger Corinne 

(édit.), Zürcher Kommentar zum IPRG – Art. 108a-200, vol. 2, 3e éd., Zurich / Genève / Bâle 

2018 (citĂŠ : ZK IPRG, OETIKER). 

http://arbitrationblog.kluwerarbitration.com/2017/11/02/decrypting-cryptocurrencies-borderless-currencies-may-benefit-borderless-dispute-resol
http://arbitrationblog.kluwerarbitration.com/2017/11/02/decrypting-cryptocurrencies-borderless-currencies-may-benefit-borderless-dispute-resol
https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3499998
https://bitcoin.org/bitcoin.pdf
http://odr.info/ethics-and-odr/


X 

 

OPENBAZAAR, What Do Moderators and Moderated Payments Do on OpenBazaar ?, Blog 

OpenBazaar, 16 mai 2018, https://openbazaar.org/blog/what-do-moderators-and-

moderated-payments-do-on-openbazaar/, consultĂŠ le 25 janvier 2021 (citĂŠ : OPENBAZAAR, 

Moderators). 

OPENBAZAAR, Verified Moderators, Medium, 11 janvier 2018, 

https://medium.com/openbazaarproject/verified-moderators-c83ea2f2c7f3, consultĂŠ le 25 

janvier 2021 (citĂŠ : OPENBAZAAR, Verified moderators). 

OPENBAZAAR, Decentralized Reputation in OpenBazaar, Blog OpenBazaar, 7 octobre 2015, 

https://openbazaar.org/blog/decentralized-reputation-in-openbazaar/, consultĂŠ le 25 janvier 

2021 (citĂŠ : OPENBAZAAR, Decentralized reputation). 

OPENBAZAAR, Why proof-of-burn, Blog OpenBazaar, 7 septembre 2014, 

https://openbazaar.org/blog/why-proof-of-burn/, consultĂŠ le 25 janvier 2021 (citĂŠ : 

OPENBAZAAR, Why proof-of-burn). 

OPENBAZAAR, Proof of burn and Reputation Pledges?, Blog OpenBazaar, 21 aoĂťt 2014, 

https://openbazaar.org/blog/proof-of-burn-and-reputation-pledges/, consultĂŠ le 25 janvier 

2021 (citĂŠ : OPENBAZAAR, Proof of burn). 

ORTOLANI PIETRO, The Impact of Blockchain Technologies and Smart Contracts on Dispute 

Resolution : Arbitration and Court Litigation at the Crossroads, Uniform Law Review, 

vol.  24, 2019, p. 430 Ă  448. 

O’SHIELDS REGGIE, Smart Contracts : Legal Agreements for the Blockchain, North Carolina 

Banking Institute, vol. 21, 2017, p. 177 Ă  194. 

OST FRANÇOIS / VAN DE KERCHOVE MICHEL, De la pyramide au réseau ? – Pour une théorie 

dialectique du droit, 2e ĂŠd., Bruxelles 2010. 

PARITY TECHNOLOGIES, On Classes of Stuck Ether and Potential Solutions, Parity Blog, 11 

dĂŠcembre 2017 : https://www.parity.io/on-classes-of-stuck-ether-and-potential-solutions/, 

consultĂŠ le 25 janvier 2021. 

PAULSSON JAN, Delocalisation of Commercial International Arbitration : When and Why it 

Matters?, The International and Comparative Law Quarterly, vol. 32, 1983, p. 53 Ă  61. 

RABINOVICH-EINY ORNA / KATSH ETHAN, Blockchain and the Inevitability of Disputes : The 

Ro";"""date"",""2021-02-07T20:48:11Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.7""
""xmp:CreatorTool"",""MicrosoftŽ Word pour Microsoft 365""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dc:creator"",""Leonel Constantino Ferreira""
""language"",""fr""
""dcterms:created"",""2021-02-07T20:48:11Z""
""Last-Modified"",""2021-02-07T20:48:11Z""
""dcterms:modified"",""2021-02-07T20:48:11Z""
""dc:format"",""application/pdf; version=1.7""
""xmpMM:DocumentID"",""uuid:7450120B-B165-41F8-A9EC-4173F283E238""
""Last-Save-Date"",""2021-02-07T20:48:11Z""
""pdf:docinfo:creator_tool"",""MicrosoftŽ Word pour Microsoft 365""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2021-02-07T20:48:11Z""
""meta:save-date"",""2021-02-07T20:48:11Z""
""pdf:encrypted"",""false""
""xmp:CreateDate"",""2021-02-07T21:48:11Z""
""modified"",""2021-02-07T20:48:11Z""
""Content-Length"",""917950""
""pdf:hasMarkedContent"",""true""
""Content-Type"",""application/pdf""
""xmp:ModifyDate"",""2021-02-07T21:48:11Z""
""pdf:docinfo:creator"",""Leonel Constantino Ferreira""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Leonel Constantino Ferreira""
""dc:language"",""fr-CH""
""meta:author"",""Leonel Constantino Ferreira""
""pdf:producer"",""MicrosoftŽ Word pour Microsoft 365""
""meta:creation-date"",""2021-02-07T20:48:11Z""
""created"",""2021-02-07T20:48:11Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""97""
""Creation-Date"",""2021-02-07T20:48:11Z""
""resourceName"",""Memoire_Leonel-Ferreira.pdf""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""277"",""3331"",""3039"",""2419"",""2478"",""2499"",""2651"",""2416"",""2276"",""2436"",""2392"",""2281"",""2416"",""1209"",""1165"",""1155"",""965"",""307"",""2507"",""2522"",""2540"",""2540"",""2765"",""2332"",""2601"",""2711"",""2664"",""2296"",""3000"",""2612"",""2551"",""2445"",""2333"",""2463"",""2404"",""3073"",""2454"",""2983"",""2714"",""2829"",""2611"",""2406"",""2822"",""2765"",""2441"",""2964"",""2746"",""2159"",""2323"",""2678"",""2622"",""2819"",""2564"",""2672"",""2488"",""2400"",""2452"",""2708"",""2661"",""2500"",""2369"",""2771"",""2266"",""2508"",""2598"",""2712"",""2709"",""2873"",""2432"",""2461"",""2333"",""2638"",""2288"",""2440"",""2537"",""2750"",""2619"",""2969"",""2877"",""2417"",""2607"",""2714"",""2692"",""2591"",""2939"",""2515"",""2243"",""2886"",""2662"",""2720"",""2600"",""2690"",""2674"",""2527"",""2576"",""2714"",""1462""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""Author"",""Leonel Constantino Ferreira""
""producer"",""MicrosoftŽ Word pour Microsoft 365""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""MicrosoftŽ Word pour Microsoft 365""
""pdf:docinfo:created"",""2021-02-07T20:48:11Z""
";https://scholar.google.ch/scholar?start=40&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2021
1619099115-434;https://scholar.google.ch/scholar?as_ylo=2021&q=oracles+blockchain&hl=fr&as_sdt=0,5;[PDF][PDF] On Sufficient Oracles for Secure Computation with Identifiable Abort;M Simkin, L Siniscalchi, S Yakoubov ; eprint.iacr.org;;"… 1 Aarhus University 2 Concordium Blockchain Research Center Abstract … Ishai, Ostrovsky, and

Zikas (Crypto 2014) show that an oracle that returns correlated randomness to all n parties is

sufficient; however, they leave open the question of whether oracles that return output …";;;[PDF] iacr.org;https://eprint.iacr.org/2021/151.pdf;"
On Sufficient Oracles for Secure Computation
with Identifiable Abort

Mark Simkin1?, Luisa Siniscalchi1,2, and Sophia Yakoubov1

1 Aarhus University
2 Concordium Blockchain Research Center

Abstract. Identifiable abort is the strongest security guarantee that is achievable for secure multi-
party computation in the dishonest majority setting. Protocols that achieve this level of security ensure
that, in case of an abort, all honest parties agree on the identity of at least one corrupt party who can
be held accountable for the abort. It is important to understand what computational primitives must
be used to obtain secure computation with identifiable abort. This can be approached by asking which
oracles can be used to build perfectly secure computation with identifiable abort. Ishai, Ostrovsky, and
Zikas (Crypto 2014) show that an oracle that returns correlated randomness to all n parties is sufficient;
however, they leave open the question of whether oracles that return output to fewer than n parties
can be used.

In this work, we show that for t ≤ n − 2 corruptions, oracles that return output to n − 1 parties
are sufficient to obtain information-theoretically secure computation with identifiable abort. Using our
construction recursively, we see that for t ≤ n − ` − 2 and ` ∈ O(1), oracles that return output to
n− `− 1 parties are sufficient.

For our construction, we introduce a new kind of secret sharing scheme which we call unanimously
identifiable secret sharing with public and private shares (UISSwPPS). In a UISSwPPS scheme, each
share holder is given a public and a private share. Only the public shares are necessary for reconstruction,
and the knowledge of a private share additionally enables the identification of at least one party who
provided an incorrect share in case reconstruction fails. The important new property of UISSwPPS is
that, even given all the public shares, an adversary should not be able to come up with a different
public share that causes reconstruction of an incorrect message, or that avoids the identification of a
cheater if reconstruction fails.

1 Introduction

In the setting of secure multiparty computation we have n parties, each with their own private input xi, that
would like to compute an arbitrary function f(x1, . . . , xn) of their inputs in the presence of an adversary,
who may actively corrupt up to t of the parties. In particular, the parties would like to compute the function
in a way that prevents the adversary from learning any unnecessary information, i.e. the corrupted parties
should learn no more than what they can deduce from their own inputs and outputs. From a correctness
point of view, we would ideally like to guarantee that the honest parties always obtain the output no matter
what the corrupted parties do, but unfortunately, such strong guarantees are unattainable when t ≥ n/2
parties are corrupt, as was shown by Cleve [Cle86].

For this reason, protocols tolerating this many corruptions usually aim for the weaker notion of active
security with unanimous abort (UA), where the honest parties either all obtain the correct output or all
unanimously output abort. The drawback of such protocols, however, is that they do not provide the honest
parties with a mechanism for determining who caused the abort in a failed execution, thus potentially
allowing an adversary to perform a denial-of-service attack on the whole computation by only corrupting
a single party. To overcome this issue, Ishai, Ostrovsky, and Zikas [IOZ14] introduced the notion of active
security with identifiable abort (IA), which enables the honest parties to always unanimously agree on at
least one corrupted party that will be held responsible for an abort.

? Supported by a DFF Sapere Aude Grant 9064-00068B.



To eventually construct efficient protocols for either notion, it is important to understand the minimal
computationally secure building blocks necessary. Towards this goal, it is convenient to study the task of
constructing information-theoretically secure protocols in a world where the parties have access to oracles
that compute certain sub-functions correctly and securely on their behalf. In such a world, the question of
finding the minimal building blocks reduces to finding the “simplest” oracles. The hope of this approach
is that simpler oracles lead to computationally less expensive solutions in an oracle-free world, where the
oracles are replaced by computationally secure protocols that often represent the main efficiency bottleneck
of the overall protocol.

For secure n-party computation with UA or IA in the presence of an adversary that corrupts less than
half of the parties, i.e. t < n/2, no oracles are needed [RB89, Bea90].3 For UA and any t ≥ n/2, oracles
are necessary and oracles that realize two-party oblivious transfer [Rab81] are sufficient [Kil88, CvT95].
In contrast to this, an impossibility result by Ishai, Ostrovsky, and Seyalioglu [IOS12] rules out secure
computation with IA from any two-party oracle for t ≥ 2n/3.4 On the positive side, the authors of [IOZ14]
show that an n-party oracle for setting up correlated randomness is sufficient for secure computation with
IA for any t. For t ≥ n/2 and oracles that realize k-party functionalities for 2 < k < n, very little is known
about the feasibility of IA. The only known (upper) bounds are due to Brandt et al. [BMMMQ20], who
show that IA with security against t corruptions can be realized from certain (t + 2)-party oracles, when
n ∈ O(log Ν/ log log Ν), where Ν is the security parameter. The authors conjecture that analogous results for
larger n are not possible unless P = NP .

1.1 Our Contribution

In this work, we make the first progress towards constructing n-party protocols with IA for any n ∈ poly(Ν)
from k-party oracles for k < n. In particular, we show the following theorem.

Theorem 1 (Informal). Any number of parties n can securely compute any function f in the presence of t
corruptions with IA and information-theoretic security, when given access to oracles that compute arbitrary
k-party functions with IA for t ≤ n− `− 1 and k = n− ` for any constant ` > 0.

Our result refutes the conjecture of Brandt et al. mentioned above. As a technical tool, which may be
of independent interest, we introduce the notion of unanimously identifiable secret sharing with public and
private shares (UISSwPPS), which is inspired by the notion of unanimously identifiable secret sharing (UISS)
of Ishai, Ostrovsky, and Seyalioglu [IOS12].

Lastly, we remark that in our work, we only focus on oracles that provide us with IA, since oracles that
realize k-party functionalities with UA are of no help. To see this, observe that in our parameter settings
every call to an oracle necessarily includes a corrupted party, thus the adversary can guarantee that all those
calls abort without the honest parties learning anything.

1.2 Technical Overview

The starting point of our work is a result of Ishai, Ostrovsky, and Zikas [IOZ14], which shows that an n-
party oracle with IA for distributing correlated randomness is sufficient for general n-party computation
with IA. An n-party oracle generating correlated randomness takes no private inputs from the parties,
computes (r1, . . . , rn) using some setup function Setup, and returns ri to party i. To solve the general secure
computation problem with IA, we can thus focus on the problem of realizing those oracles specifically from
k-party oracles for k < n. We will require that the number of corruptions t is at most k − 1 to ensure that

3 We assume that parties have access to point-to-point and broadcast channels, and we do not consider those as
explicit oracles in this paper.

4 In addition to their impossibility result, the authors of [IOZ14] also show that blackbox access to adaptively-secure
two-party oblivious transfer is sufficient for constructing protocols with IA for t > n/2. We note that assuming
blackbox access to a primitive is a stronger assumption than assuming oracle access, which is the focus of this
work.

2



every oracle call includes at least one honest party, which we need for our construction. Let us focus on the
case of k = n−1 for now, which can then be easily extended to any k = n−` for any constant ` via recursion.

From a high-level perspective, we proceed to construct functionalities of gradually increasing security
and expressiveness starting from a functionality that we have oracle access to as depicted in Figure 1.

FSetup′,n−1,x,O FSetup′,n,x FSetup,n Fn
Thm. 2 Thm. 3 Thm. 4 + [IOZ14]

Fig. 1. High-level overview of our approach. On the very left, we have an (n− 1)-party functionality FSetup′,n−1,x,O,
which we have oracle access to. On the very right, we have Fn for computing arbitrary functions among n parties
with IA.

The basic idea of our approach is to pick a party x ∈ [n] and exclude it from the computation. The
remaining n − 1 parties use their oracle access to compute a function FSetup′,n−1,x,O, which uses Setup to
generate correlated randomness, provides every party with its output and additionally secret shares the
output rx belonging to party x among the n− 1 parties. After calling the oracle, all parties send their share
of rx to party x, who reconstructs its correlated randomness. If all parties behave honestly, then everybody
receives the correct output. Privacy of the value rx is guaranteed, since at least one honest party participated
in the oracle call.

To make this approach work in the presence of an active adversary, we need to deal with malicious parties
sending incorrect shares to party x or that party itself being malicious and falsely claiming that some received
share was bad or not received at all. Through the use of an appropriate secret sharing scheme, we ensure
that any tampering of the shares is detectable during reconstruction by party x. If tampering is detected,
the excluded party x proceeds to a complain phase, which does not unanimously identify a malicious party,
but establishes conflicts between the n parties participating in the computation. After establishing those
conflicts, the parties again try to use oracle FSetup′,n−1,x,O to generate correlated randomness. The new
oracle invocation will also get a set O as input, which contains the (publicly known) indices of parties that
party x has a conflict with. Parties in the set O will not receive a share of the output of party x.

To ensure that our protocol can establish “good” conflicts during the complain phase, we rely on our
new secret sharing notion of UISSwPPS. In a nutshell, this secret sharing scheme provides every participant
with a public and a private share. The public shares are used for reconstructing the secret and allow the
excluded party to detect if some share is malformed. The private shares allow honest share holders to agree
on a set of public shares they believe to be malformed; even if the adversary outputs its public shares after
seeing all other public shares.

Now if FSetup′,n−1,x,O aborts too many times, then the parties decide to switch to a different excluded
party and start over. All those executions corresponding to one excluded party x realize a functionality
FSetup′,n,x, which does not achieve IA, but a much more relaxed version thereof. Using a combinatorial
argument, we show that the honest parties can agree on at least one malicious party, if too many invocations
of FSetup′,n,x (for different x) have not produced the output.

The approach outlined above realizes our desired functionality FSetup,n with IA for generating correlated
randomness, albeit with a still slightly weaker security notion, where the adversary can chose one of several
possible outputs or abort5. We prove that such a functionality is secure enough to be used in combination
with the approach of Ishai, Ostrovsky, and Zikas [IOZ14] for realizing secure n-party computation with IA
of arbitrary functions, i.e. functionality Fn.

1.3 Notation

We write [n] to denote the set {1, . . . , n}.
5 Note that in regular security with IA, the adversary gets to see one output and then has to decide, whether to

accept it or to abort.

3



2 Secure Multiparty Computation (MPC) Definitions

We follow the real/ideal world simulation paradigm.

An n-party protocol Π = (P1, . . . , Pn) is an n-tuple of probabilistic polynomial-time (PPT) interactive
Turing machines (ITMs), where each party Pi is initialized with input xi ∈ {0, 1}∗ and random coins ri ∈
{0, 1}∗. We let A denote a special ITM that represents the adversary and that is initialized with input that
contains the identities of the corrupt parties, their respective private inputs, and an auxiliary input. The
protocol is executed in rounds (i.e., the protocol is synchronous), where each round consists of the send phase
and the receive phase, where parties can respectively send the messages from this round to other parties and
receive messages from other parties. In every round parties can communicate either over a broadcast channel
or a fully connected point-to-point (P2P) network, where we additionally assume all communication to be
private and ideally authenticated.

During the execution of the protocol, the corrupt parties receive arbitrary instructions from the adversary
A, while the honest parties faithfully follow the instructions of the protocol. We consider the adversary A
to be rushing, i.e., during every round the adversary can see the messages the honest parties sent before
producing messages from corrupt parties.

At the end of the protocol execution, the honest parties produce output, the corrupt parties produce no
output, and the adversary outputs an arbitrary function of its view. The view of a party during the execution
consists of its input, random coins and the messages it sees during the execution.

Definition 1 (Real-world execution). Let Π = (P1, . . . , Pn) be an n-party protocol and let C ⊆ [n],
of size at most t, denote the set of indices of the parties corrupted by A. The joint execution of Π under
(A, C) in the real world, on input vector x = (x1, . . . , xn), auxiliary input aux to A and security parameter
Ν, denoted REALΠ,C,A(aux)(x, Ν), is defined as the output vector of P1, . . . , Pn and A(aux) resulting from the
protocol interaction.

Definition 2 (Ideal Computation). Let f : ({0, 1}∗)n → ({0, 1}∗)n be an n-party function and let C ⊆
[n], of size at most t, be the set of indices of the corrupt parties. Then, the joint ideal execution of f
under (S, C) on input vector x = (x1, . . . , xn), auxiliary input aux to S and security parameter Îť, denoted
IDEALf,C,S(aux)(x, Îť), is defined as the output vector of P1, . . . , Pn and S(aux) resulting from the interaction
to the ideal functionality F (Figure 2) with the simulator S and the honest parties. After interacting with F ,
the hones parties output the message received from F . The corrupt parties output nothing. The simulator S
outputs an arbitrary function of the initial inputs {xi}i∈C , the messages received by the corrupt parties from
the trusted party and its auxiliary input.

Functionality Ff,n

1. For i ∈ [n]\C receive xi from party Pi;
2. For i ∈ C receive xi from S;
3. Compute y = f(x1, . . . , xn);
4. Send y to S;
5. Receive either continue or (abort, ī) (for some ī ∈ C) from S;
6. If S sent continue: send y to each party i ∈ [n]\C;
7. If S sent (abort, ī): send (abort, ī) to each party i ∈ [n]\C.

Fig. 2. Functionality Ff,n for secure computation of function f among n parties with identifiable abort.

4



Definition 3. Let f : ({0, 1}∗)n → ({0, 1}∗)n be an n-party function. A protocol Π t-securely computes the
function f if for every real-world adversary A there exists a simulator S whose running time is polynomial
in the running time of A such that for every C ⊆ [n] of size at most t, it holds that{

REALΠ,C,A(aux)(x, Ν)
}

x∈({0,1}∗)n,λ∈N≡
{
IDEALf,C,S(aux)(x, Îť)

}
x∈({0,1}∗)n,λ∈N .

3 Unanimously Identifiable Secret Sharing with Public and Private Shares

A secret sharing schemes allows a dealer to split a message into shares such that certain authorized subsets
of those shares can be used to reconstruct the message, whereas unauthorized subsets reveal no information
about the message whatsoever.

Definition 4 (Secret Sharing Scheme). A secret sharing scheme for message space {0, 1}∗ consists of a
probabilistic polynomial-time algorithm Share and a deterministic polynomial-time algorithm LRec with the
following syntax:

Share(msg)→ (s1, . . . , sn): takes as input a message msg ∈ {0, 1}∗ and outputs shares s1, . . . , sn.
LRec(si, {sj}j∈S)→ (msg, L): takes as input a share si and a subset of shares {sj}j∈S, where i ∈ S ⊂ [n],

and outputs a reconstructed message in {0, 1}∗ ∪ {⊥} and a set of accusations L ⊂ [n].

Furthermore, (Share, LRec) should satisfy correctness (Definition 8, with appropriate syntactic modifica-
tions and ignoring the requirements on Rec, which we do not have in a regular secret sharing scheme) and
privacy (Definition 9, with appropriate syntactic modifications).

We introduce the notion of unanimously identifiable secret sharing with public and private shares (UIS-
SwPPS). In such a scheme, each share holder will receive one private and one public share. On an intuitive
level, the public shares will correspond to a secret sharing of the message shared by the dealer. The private
shares, on the other hand, will be used by the share holders to detect any tampering with public shares. In
particular, having additional private shares for each share holder allows us to satisfy a stronger notion of
local identifiability, which we define below. We show a construction of UISSwPPS in Section 5.

Definition 5 (Secret Sharing Scheme with Public and Private Shares). A secret sharing scheme
with public and private shares for message space {0, 1}∗ consists of a probabilistic polynomial-time algorithm
Share and deterministic polynomial-time algorithms Rec and LRec with the following syntax:

Share(msg)→ (spub
1 , . . . , spub

n , spriv
1 , . . . , spriv

n ): takes as input a message msg ∈ {0, 1}∗ and outputs public shares

spub
1 , . . . , spub

n and private shares spriv
1 , . . . , spriv

n .

Rec({spub
i }i∈S)→ msg/⊥: takes as input a subset of public shares {spub

i }i∈S (where S ⊂ [n]) and outputs a
value in {0, 1}∗ ∪ {⊥}.

LRec(spriv
i , {spub

j }j∈S)→ (msg, L): takes as input a private share spriv
i and a subset of public shares {spub

j }j∈S
(where S ⊂ [n]) and outputs a reconstructed message in {0, 1}∗ ∪ {⊥} and a list of accusations L ⊂ [n].

Furthermore, (Share, Rec, LRec) should satisfy correctness (Definition 8), privacy (Definition 9), adap-
tive local identifiability (Definition 10), publicly detectable failures (Definition 11), consistent failures (Def-
inition 12) and predictable failures (definitions 13 and 14).

We will use our new secret sharing scheme in combination with a new access structure that effectively
corresponds to a threshold access structure with additional observers that hold no information about the
dealer’s message. Even though these observers are not helpful for reconstructing the message, they will still
be able to verify whether other published shares are valid or not.

Definition 6 (Threshold Access Structure). For an arbitrary but fixed threshold t ∈ [n], the t-threshold
access structure is defined as An,t = {S ⊂ [n] | |S| ≥ t}.

5



Definition 7 (Threshold Access Structure with Observers). For an arbitrary but fixed threshold
t ∈ [n] and set O ⊂ {1, . . . , n}, the t-threshold access structure with observers O is defined as AOn,t = {S ⊂
{1, . . . , n} | |S \O| ≥ t}.

Definition 8 (Correctness). A secret sharing scheme with public and private shares (Share, Rec, LRec)
for access structure A is correct if for any S ∈ A, for any i ∈ S, for any message msg ∈ {0, 1}∗, there exists
a negligible function negl(¡) such that

Pr

[[
spub
1 , . . . , spub

n

spriv
1 , . . . , spriv

n

]
← Share(msg), (msg,⊥)← LRec

(
spriv
i , {spub

j }j∈S
)

: msg = msg

]
= 1− negl(λ)

and

Pr

[[
spub
1 , . . . , spub

n

spriv
1 , . . . , spriv

n

]
← Share(msg),msg← Rec

(
{spub
j }j∈S

)
: msg = msg

]
= 1− negl(λ)

where the probability is taken over the random coins of the Share algorithm.

Definition 9 (Privacy). A secret sharing scheme (Share, LRec) for access structure A is private if for
any S 6∈ A, any two messages msg,msg′ ∈ {0, 1}∗ with |msg| = |msg′|, any possible vector of shares

{(s̃pub
i , s̃priv

i )}i∈S, it holds that

Pr

[[
spub
1 , . . . , spub

n

spriv
1 , . . . , spriv

n

]
← Share(msg) : {(̃spub

i , s̃priv
i )}i∈S = {(spub

i , spriv
i )}i∈S

]
−Pr

[[
spub
1 , . . . , spub

n

spriv
1 , . . . , spriv

n

]
← Share(msg′) : {(̃spub

i , s̃priv
i )}i∈S = {(spub

i , spriv
i )}i∈S

]
≤ negl(λ) ,

where the probability is taken over the randomness of the secret sharing algorithm.

For our new notion of (adaptive) local identifiability, we consider an adversary that can see all public
shares before outputting any tampered shares.

Definition 10 (Adaptive Local Identifiability). Consider the game described in Figure 3. A secret
sharing scheme with public and private shares (Share, Rec, LRec) for access structure A has adaptive local
identifiability if for any message msg ∈ {0, 1}∗ and adversary A, there exists a negligible function negl(·)
such that

Pr[A wins gameali(A)] ≤ negl(λ)

where the probability is taken over the random coins of the C and A.

Remark 1. We will assume that local reconstruction outputs message ⊥ whenever the list of accusations is
not empty.

We require a UISSwPSS to satisfy a mild notion of error detection for outside parties that receive a set
of potentially tampered shares and attempt to reconstruct the secret.

Definition 11 (Publicly Detectable Failures). Consider the game described in Figure 4. A secret sharing
scheme with public and private shares (Share, Rec, LRec) has publicly detectable failures if for any message
msg ∈ {0, 1}∗ and adversary A, there exists a negligible function negl(·) such that

Pr[A wins gamepdf(A)] ≤ negl(λ)

where the probability is taken over the random coins of Share and A.

Finally, we require that Rec fails whenever LRec fails.

6



Game gameali(A)

A C[
spub
1 , . . . , spub

n

spriv
1 , . . . , spriv

n

]
← Share(msg)

{spub
i }i∈[n]

C ⊂ [n]

{spriv
i }i∈C

{s̃pub
i }i∈C

Define s̃pub
i := spub

i for all i ∈ [n]\C.
A wins unless for each S ∈ A with S 6⊂ C, one of the following happens:

(1) ∀i ∈ [n] : (msg,⊥) = LRec
(
spriv
i , {s̃pub

j }j∈S
)

(2) ∀i, j ∈ S \ C : ∅ 6= Li = Lj ⊂ [n],where

(msgi, Li)← LRec
(
spriv
i , {s̃pub

k }k∈S
)

and

(msgj , Lj)← LRec
(
spriv
j , {s̃pub

k }k∈S
)

Fig. 3. Security game for adaptive local identifiability.

Game gamepdf(A)

A C

C ⊂ [n]

[
spub
1 , . . . , spub

n

spriv
1 , . . . , spriv

n

]
← Share(msg)

{spub
i }i∈C

{s̃pub
i }i∈C

Define s̃pub
i = spub

i for all i ∈ [n]\C and set {s̃pub
i }i∈[n].

A wins if ∃ S ∈ A : S ∩ C 6= ∅ and Rec({s̃pub
i }i∈S) 6∈ {msg,⊥}

Fig. 4. Security game for publicly detectable failures.

7



Game gamecf(A)

A C[
spub
1 , . . . , spub

n

spriv
1 , . . . , spriv

n

]
← Share(msg)

{spub
i }i∈[n]

C ⊂ [n]

{spriv
i }i∈C

{s̃pub
i }i∈C

Define s̃pub
i = spub

i for all i ∈ [n]\C.

A wins if ∃ S ∈ A ∃ i ∈ S : Rec({s̃pub
j }j∈S) = ⊥ and

LRec(spriv
i , {s̃pub

j }j∈S) 6= (⊥, L)

Fig. 5. Security game for consistent failures.

Definition 12 (Consistent Failures). Consider the game described in Figure 5. A secret sharing scheme
with public and private shares (Share, Rec, LRec) for access structure A has consistent failures if for any
message msg ∈ {0, 1}∗ and adversary A, there exists a negligible function negl(·) such that

Pr[A wins gamecf(A)] ≤ negl(λ)

where the probability is taken over the random coins of C and A.

Definition 13 (Predictable Failures with respect to LRec). Consider the game described in Figure 6.
A secret sharing scheme (Share, LRec) for access structure A has predictable failures if there exists a prob-
abilistic polynomial-time algorithm SLRec such that for any message msg ∈ {0, 1}∗ and adversary A, there
exists a negligible function negl(¡) such that

Pr[A wins gamepflrec(A)] ≤ negl(λ)

where the probability is taken over the random coins of C and A.

Definition 14 (Predictable Failures with respect to Rec). Consider the game described in Figure 7. A
secret sharing scheme with public and private shares (Share, Rec, LRec) for access structure A has predictable
failures with respect to Rec if there exists a probabilistic polynomial-time algorithm SRec such that for any
message msg ∈ {0, 1}∗ and adversary A, there exists a negligible function negl(·) such that

Pr[A wins gamepfrec(A)] ≤ negl(λ)

where the probability is taken over the random coins of C and A.

4 Bootstrapping MPC With Identifiable Abort

In this section, we describe how to instantiate MPC with identifiable abort for n parties and t ≤ n− 2 given
MPC with identifiable abort for n − 1 parties and t ≤ n − 2. In Section 4.1, we describe the protocol. In
Section 4.2, we prove its security.

8



Game gamepflrec(A)

A C

C ⊂ [n], C /∈ A

[
spub
1 , . . . , spub

n

spriv
1 , . . . , spriv

n

]
← Share(msg)

{spub
i }i∈[n], {s

priv
i }i∈C

{s̃pub
i }i∈C , S ∈ A, S 6⊂ C and i∗ ∈ S

Define (b, L′) := SLRec(C, S, i∗, {spub
i }i∈[n], {s

priv
i }i∈C , {s̃

pub
i }i∈S∊C)

Define s̃pub
i := spub

i for all i ∈ [n]\C and (msg, L) := LRec(spriv
i∗ , {s̃

pub
j }j∈S)

A wins unless any one of the following happens:

− b = 1 and msg = msg

− b = 0 and L = L′ 6= ⊥

Fig. 6. Security game for predictable failures with respect to LRec.

Game gamepfrec(A)

A C

C ⊂ [n], C /∈ A

[
spub
1 , . . . , spub

n

spriv
1 , . . . , spriv

n

]
← Share(msg)

{spub
i }i∈[n], {s

priv
i }i∈C

{s̃pub
i }i∈C , S ∈ A and S 6⊂ C

Define b := SRec(C, S, {spub
i }i∈[n], {s

priv
i }i∈C , {s̃

pub
i }i∈S∊C)

Define s̃pub
i := spub

i for all i ∈ [n]\C and msg := Rec({s̃pub
j }j∈S)

A wins unless any one of the following happens:

− b = 1 and msg = msg

− b = 0 and msg = ⊥

Fig. 7. Security game for predictable failures with respect to Rec.

9



4.1 Protocol

Ishai et al. [IOZ14] show that given correlated randomness, it is possible to securely compute any func-
tion with any threshold t, with identifiable abort and with information-theoretic security. Let Setup() →
(r1, . . . , rn) be the randomized function that produces the appropriate correlated randomness. Setup takes no
inputs (since correlated randomness is independent of the parties’ inputs), and outputs n correlated objects,
one for each party.

We would like to make use of the availability of MPC with identifiable abort for n − 1 parties to run
Setup (for n parties). In order to do this, we define Setup′x to be Setup augmented to return shares of rx
to parties i ∈ [n]\{x}, and nothing to party x. We then expect parties i ∈ [n]\{x} to send those shares to
party x. Of course, we need to make sure that party x won’t accept incorrect shares; so, we use UISSwPPS
to authenticate the shares.

If party x is dissatisfied with the shares she receives, she broadcasts all the shares. Then, one of two
things happens. Either (1) all parties acknowledge that they sent the broadcast shares to party x, in which
case, because of the adaptive local identifiability (Definition 10) of the secret sharing, we obtain identifiable
abort among the parties who participated in the MPC; or (2) one of the parties (say, party i) claims that
party x misrepresented the share she sent, in which case we have established a conflict between parties i and
x, and can repeat the MPC excluding party i from the set of parties who hold shares of rx.

We define Setup′x,O to be the augmented correlated randomness setup function that distributes shares
of rx to parties i ∈ [n] with observers O ⊆ [n] (where x ∈ O). (We only create an observer share for party x
for ease of notation; this share is never used.) Setup′x,O is described in Figure 8.

Algorithm Setup′x,O

(r1, . . . , rn)← Setup()
{spub
i , spriv

i }i∈[n] ← Share(AOt , rx)

return {(ri, spub
i , spriv

i )}i∈[n]\{x}

Fig. 8. Algorithm Setup′x,O

Figure 9 describes the functionality FRS(k),Setup,n that computes Setup with identifiable abort; the sub-
script RS(k) signifies that we allow rejection sampling by the adversary, who is able to request fresh outputs of
Setup up to k times. Figure 13 describes the protocol ΠRS(k=n2),Setup,n that realizes FRS(k),Setup,n for k = n2.
This protocol calls upon a weaker ideal functionality FRS(k=n),Setup,n,x, which is described in Figure 10; this
ideal functionality only has identifiable abort among n− 1 of the parties (party x cannot necessarily identify
a cheater). FRS(k=n),Setup,n,x either (1) distributes the correlated randomness successfully, (2) identifiably
aborts, or (3) identifiably aborts only among [n]\{x}, in which case ΠRS(k=n2),Setup,n calls FRS(k=n),Setup,n,x

again with a different x. Figure 12 describes the protocol ΠRS(k=n),Setup,n,x that realizes FRS(k=n),Setup,n,x.
ΠRS(k=n),Setup,n,x in turn calls upon an ideal functionality FSetup′,n,x,O; this ideal functionality computes
Setup′ among n− 1 parties with identifiable abort (without rejection sampling). We do not give a protocol
realizing FSetup′,n,x,O, as we assume that secure protocols with identifiable abort exist for any (n− 1)-party
function.

Theorem 2. Protocol Π
FSetup′,n−1,x,O

RS(k=n),Setup,n,x (Figure 12) securely realizes the functionality F(k=n),Setup,n,x (Fig-

ure 10) against t ≤ n− 2 corruptions, assuming the availability of a broadcast channel and oracle access to
FSetup′,n−1,x,O.

10



Functionality FRS(k),Setup,n

1. Let ` := 1;
2. Run (r`1, . . . , r

`
n)← Setup();

3. Send {r`i}i∈C to S;
4. Receive either retry, continue or (abort, ī) (for some ī ∈ C) from S;
5. If S sent retry: increment ` by one (` := ` + 1). We only allow up to k retries, so we

never get ` > k. Restart from step 2.
6. If S sent continue: send ri to each party i ∈ [n]\C;
7. If S sent (abort, ī): send (abort, ī) to each party i ∈ [n]\C.

Fig. 9. Functionality FRS(k),Setup,n for secure computation of the correlated randomness setup function Setup among
n parties with identifiable abort, which allows the simulator to reject the output (requesting a redo) at most k times.

Functionality FRS(k),Setup,n,x

1. Let ` := 1;
2. Run (r`1, . . . , r

`
n)← Setup();

3. Send {r`i}i∈C to S;
4. Receive either retry, continue or (abort, ī) (for some ī ∈ C) from S;
5. If S sent retry: increment ` by one (` := ` + 1). We only allow up to k retries, so we

never get ` > k. Restart from step 2.
6. If S sent continue: send ri to each party i ∈ [n]\C;
7. If S sent (abort, ī):

(a) If ī = x: send (abort, x) to each party i ∈ [n]\C;
(b) If ī 6= x:

i. Send (gadgabort, ī) to each party i ∈ [n]\({x} ∪ C)
ii. Send gadgabort to party x if x /∈ C.

Fig. 10. Functionality FRS(k),Setup,n,x for secure computation of the correlated randomness setup function Setup

among n parties with identifiable abort among all the parties except for x which allows the simulator to reject the
output (requesting a redo) at most k times.

Functionality FSetup′,n−1,x,O

1. Compute {(ri, spub
i , spriv

i )}i∈[n] ← Setup′x,O();

2. Send {(ri, spub
i , spriv

i )}i∈C to S;
3. Receive either continue or (abort, ī) (for some ī ∈ C) from S;
4. If S sent continue: send (ri, s

pub
i , spriv

i ) to each party i ∈ [n]\({x} ∪ C);
5. Otherwise: send (abort, ī) to each party i ∈ [n]\({x} ∪ C).

Fig. 11. Functionality FSetup′,n−1,x,O for secure computation of function Setup′x,O with identifiable abort among n−1
parties (parties i ∈ [n]\{x}).

11



Theorem 3. Protocol Π
F(k=n),Setup,n,x

(k=n2),Setup,n (Figure 13) securely realizes the functionality F(k=n2),Setup,n (Fig-

ure 9) against t ≤ n − 2 corruptions, assuming the availability of a broadcast channel and oracle access to
F(k=n),Setup,n,x.

Theorem 4. If a protocol Π securely realizes Ff,n given a single oracle access to FSetup,n as a first action,
then Π also securel";"""date"",""2021-03-29T08:34:07Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref package""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref package""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2021-03-29T08:34:07Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.19 (TeX Live 2018) kpathsea version 6.3.0""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2021-03-29T08:34:07Z""
""created"",""2021-03-29T08:34:07Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2021-03-29T08:34:07Z""
""resourceName"",""151.pdf""
""Author"",""""
""producer"",""pdfTeX-1.40.19""
""pdf:docinfo:producer"",""pdfTeX-1.40.19""
""pdf:unmappedUnicodeCharsPerPage"",""5"",""3"",""10"",""0"",""4"",""24"",""14"",""3"",""9"",""10"",""21"",""22"",""13"",""15"",""6"",""5"",""16"",""31"",""4"",""9"",""10"",""3"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2021-03-29T08:34:07Z""
""Last-Modified"",""2021-03-29T08:34:07Z""
""dcterms:modified"",""2021-03-29T08:34:07Z""
""title"",""""
""Last-Save-Date"",""2021-03-29T08:34:07Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2021-03-29T08:34:07Z""
""meta:save-date"",""2021-03-29T08:34:07Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.19 (TeX Live 2018) kpathsea version 6.3.0""
""Content-Length"",""457115""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""23""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""3150"",""3551"",""3390"",""2756"",""3153"",""2205"",""611"",""1618"",""735"",""2907"",""1600"",""3447"",""2257"",""3032"",""2261"",""2773"",""3843"",""2765"",""2790"",""773"",""2219"",""3296"",""1487""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2021-03-29T08:34:07Z""
";https://scholar.google.ch/scholar?start=20&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2021
1619099107-409;https://scholar.google.ch/scholar?as_ylo=2021&q=oracles+blockchain&hl=fr&as_sdt=0,5;Robonomics in the 6G Era: Playing the Trust Game With On-Chaining Oracles and Persuasive Robots;A Beniiche, S Rostami, M Maier ; IEEE Access, 2021  ieeexplore.ieee.org;;"… This is why decentralized oracles are also referred to as con- sensus oracles. Various oracle

systems have been proposed, which aim at providing data to a blockchain reliably by incorporating

techniques such as advanced cryptography, trusted execution environments …";;null;[PDF] ieee.org;https://ieeexplore.ieee.org/iel7/6287639/9312710/09383225.pdf;"
		
	";"""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""dc:title"",""IEEE Xplore Full-Text PDF:""
""Content-Encoding"",""UTF-8""
""resourceName"",""09383225.pdf""
""language"",""es""
""Content-Length"",""2565""
""title"",""IEEE Xplore Full-Text PDF:""
""Content-Language"",""en-US""
""Content-Type"",""text/html; charset=UTF-8""
";
1619099129-463;https://scholar.google.ch/scholar?as_ylo=2021&q=oracles+blockchain&hl=fr&as_sdt=0,5;Design challenges of developing a blockchain-enabled smart home;K Valtanen ; 2021 Conference on Information Communications …, 2021  ieeexplore.ieee.org;;"… provide a wide range of open-source software modules for connecting to a blockchain and for …

The reliability of oracles can be improved by using several distributed, consensus-based oracles

or by … AI techniques could be used for building an intelligent oracle service which …";;null;null;;;;https://scholar.google.ch/scholar?start=50&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2021
1619099115-435;https://scholar.google.ch/scholar?as_ylo=2021&q=oracles+blockchain&hl=fr&as_sdt=0,5;[PDF][PDF] Chainlink 2.0: Next Steps in the Evolution of Decentralized Oracle Networks;L Breidenbach, C Cachin, B Chan, A Coventry, S Ellis… ;2021 research.chain.link;;"… will support the Transaction Execution Framework (TEF), which facilitates efficient integration

of DONs and thus oracles with other … 4 shows conceptually how DONs improve blockchain (smart

contract) scaling by concentrating transaction and oracle-report processing off …";;;[PDF] chain.link;https://research.chain.link/whitepaper-v2.pdf;"
Chainlink 2.0: Next Steps in the Evolution of
Decentralized Oracle Networks

Lorenz Breidenbach1 Christian Cachin2 Benedict Chan1

Alex Coventry1 Steve Ellis1 Ari Juels3 Farinaz Koushanfar4

Andrew Miller5 Brendan Magauran1 Daniel Moroz6

Sergey Nazarov1 Alexandru Topliceanu1 Florian Tramèr7

Fan Zhang8

15 April 2021
v1.0

1Chainlink Labs
2The author is a faculty member at University of Bern. He co-authored this work in his separate

capacity as an advisor to Chainlink Labs.
3The author is a faculty member at Cornell Tech. He co-authored this work in his separate capacity

as Chief Scientist at Chainlink Labs.
4The author is a faculty member at University of California, San Diego. She co-authored this work

in her separate capacity as an advisor to Chainlink Labs.
5The author is a faculty member at University of Illinois Urbana-Champaign. He co-authored this

work in his separate capacity as an advisor on Chainlink.
6The author is a PhD candidate at Harvard University. He co-authored this work while on leave

from Harvard, in his capacity as a researcher at Chainlink Labs.
7The author is a PhD candidate at Stanford University. He co-authored this work in his separate

capacity as an advisor to Chainlink Labs.
8The author will be joining the faculty of Duke University in fall 2021. He co-authored this work

in his current capacity as a researcher at Chainlink Labs.

1



Abstract

In this whitepaper, we articulate a vision for the evolution of Chainlink be-
yond its initial conception in the original Chainlink whitepaper. We foresee
an increasingly expansive role for oracle networks, one in which they comple-
ment and enhance existing and new blockchains by providing fast, reliable, and
confidentiality-preserving universal connectivity and off-chain computation for
smart contracts.

The foundation of our plan is what we call Decentralized Oracle Networks, or
DONs for short. A DON is a network maintained by a committee of Chainlink
nodes. It supports any of an unlimited range of oracle functions chosen for
deployment by the committee. A DON thus acts as a powerful abstraction layer,
offering interfaces for smart contracts to extensive off-chain resources and highly
efficient yet decentralized off-chain computing resources within the DON itself.

With DONs as a springboard, Chainlink plans to focus on advances in seven
key areas:

• Hybrid smart contracts: Offering a powerful, general framework for aug-
menting existing smart contract capabilities by securely composing on-chain
and off-chain computing resources into what we call hybrid smart contracts.

• Abstracting away complexity: Presenting developers and users with simple
functionality eliminates the need for familiarity with complex underlying
protocols and system boundaries.

• Scaling: Ensuring that oracle services achieve the latencies and throughputs
demanded by high-performance decentralized systems.

• Confidentiality: Enabling next-generation systems that combine blockchains’
innate transparency with strong new confidentiality protections for sensitive
data.

• Order-fairness for transactions: Supporting transaction sequencing in ways
that are fair for end users and prevent front-running and other attacks by
bots and exploitative miners.

• Trust-minimization: Creating a highly trustworthy layer of support for
smart contracts and other oracle-dependent systems by means of decen-
tralization, strong anchoring in high-security blockchains, cryptographic
techniques, and cryptoeconomic guarantees.

• Incentive-based (cryptoeconomic) security: Rigorously designing and ro-
bustly deploying mechanisms that ensure nodes in DONs have strong eco-
nomic incentives to behave reliably and correctly, even in the face of well-
resourced adversaries.

We present preliminary and ongoing innovations by the Chainlink community
in each of these areas, providing a picture of the broadening and increasingly
powerful capabilities planned for the Chainlink network.

2



Contents
1 Introduction 6

1.1 Decentralized Oracle Networks . . . . . . . . . . . . . . . . . . . . . . . 7
1.2 Seven Key Design Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.3 Organization of this Paper . . . . . . . . . . . . . . . . . . . . . . . . . 19

2 Security Model and Goals 19
2.1 Current Architectural Model . . . . . . . . . . . . . . . . . . . . . . . . 20
2.2 Consensus Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.3 Notation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.4 Note on Trust Models . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3 Decentralized Oracle Network Interface and Capabilities 23
3.1 Networking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.2 Computation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.3 Storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.4 Transaction-Execution Framework (TEF) . . . . . . . . . . . . . . . . . 27
3.5 Mempool Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.6 Stepping Stones: Existing Chainlink Capabilities . . . . . . . . . . . . . 29

3.6.1 Off-Chain Reporting (OCR) . . . . . . . . . . . . . . . . . . . . 29
3.6.2 DECO and Town Crier . . . . . . . . . . . . . . . . . . . . . . . 30
3.6.3 Existing On-Chain Chainlink Services . . . . . . . . . . . . . . . 31
3.6.4 Node Reputation / Performance History . . . . . . . . . . . . . 33

4 Decentralized Services Enabled by Decentralized Oracle Networks 34
4.1 Proof of Reserves . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.2 Interfacing with Enterprise / Legacy Systems . . . . . . . . . . . . . . 35
4.3 Decentralized Identity . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.4 Priority Channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.5 Confidentiality-Preserving DeFi / Mixicles . . . . . . . . . . . . . . . . 41

5 Fair Sequencing Services 43
5.1 The Front-Running Problem . . . . . . . . . . . . . . . . . . . . . . . . 45

5.1.1 Oracle Front-Running . . . . . . . . . . . . . . . . . . . . . . . 45
5.1.2 Front-Running User Transactions . . . . . . . . . . . . . . . . . 47

5.2 FSS Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
5.2.1 Transaction Processing . . . . . . . . . . . . . . . . . . . . . . . 48
5.2.2 Transaction Atomicity . . . . . . . . . . . . . . . . . . . . . . . 51

5.3 Fair Transaction Sequencing . . . . . . . . . . . . . . . . . . . . . . . . 53
5.4 Network-Layer Considerations . . . . . . . . . . . . . . . . . . . . . . . 56
5.5 Entity-Level Fairness Policies . . . . . . . . . . . . . . . . . . . . . . . 57

3



6 The DON Transaction-Execution Framework
(DON-TEF) 57
6.1 TEF Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
6.2 Transaction Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
6.3 Syncing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
6.4 Reorgs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

7 Trust Minimization 65
7.1 Data-Source Authentication . . . . . . . . . . . . . . . . . . . . . . . . 65

7.1.1 The Limitations of Authenticated Data Origination . . . . . . . 67
7.1.2 Confidentiality . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
7.1.3 Combining Source Data . . . . . . . . . . . . . . . . . . . . . . 68
7.1.4 Processing Source Data . . . . . . . . . . . . . . . . . . . . . . . 69

7.2 DON Trust Minimization . . . . . . . . . . . . . . . . . . . . . . . . . . 70
7.2.1 Failover Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
7.2.2 Minority Reports . . . . . . . . . . . . . . . . . . . . . . . . . . 70

7.3 Guard Rails . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
7.4 Trust-Minimized Governance . . . . . . . . . . . . . . . . . . . . . . . . 72
7.5 Public-Key Infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . 73

8 DON Deployment Considerations 75
8.1 Rollout Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
8.2 Dynamic DON Membership . . . . . . . . . . . . . . . . . . . . . . . . 76
8.3 DON Accountability . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

9 Economics and Cryptoeconomics 78
9.1 Staking Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
9.2 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
9.3 Modeling Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

9.3.1 First-Tier Incentive Model: Rational Actors . . . . . . . . . . . 85
9.3.2 Second-Tier Adjudication Model: Correctness by Assumption . 85
9.3.3 Adversarial Model . . . . . . . . . . . . . . . . . . . . . . . . . 86
9.3.4 How Much Cryptoeconomic Security Is Enough? . . . . . . . . . 87

9.4 Staking Mechanism: Sketch . . . . . . . . . . . . . . . . . . . . . . . . 87
9.4.1 Further Mechanism Details . . . . . . . . . . . . . . . . . . . . . 89
9.4.2 Quadratic Staking Impact . . . . . . . . . . . . . . . . . . . . . 90
9.4.3 Realization of Second Tier . . . . . . . . . . . . . . . . . . . . . 91
9.4.4 Misreporting Insurance . . . . . . . . . . . . . . . . . . . . . . . 93

9.5 Single-Round Variant . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
9.6 Implicit-Incentive Framework (IIF) . . . . . . . . . . . . . . . . . . . . 95

9.6.1 Future Fee Opportunity . . . . . . . . . . . . . . . . . . . . . . 96
9.6.2 Speculative FFO . . . . . . . . . . . . . . . . . . . . . . . . . . 97
9.6.3 External Reputation . . . . . . . . . . . . . . . . . . . . . . . . 98

4



9.6.4 Open IIF Analytics . . . . . . . . . . . . . . . . . . . . . . . . . 98
9.7 Putting It All Together: Node Operator Incentives . . . . . . . . . . . 99
9.8 The Virtuous Cycle of Economic Security . . . . . . . . . . . . . . . . . 100
9.9 Additional Factors Driving Network Growth . . . . . . . . . . . . . . . 101

10 Conclusion 102

A Glossary 116

B DON Interface: Further Details 119
B.1 Networking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

B.1.1 Integrity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
B.1.2 Confidentiality . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
B.1.3 Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122

B.2 Computation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
B.2.1 Trusted Execution Environments (TEEs) . . . . . . . . . . . . . 122
B.2.2 TEE Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
B.2.3 Secure Multi-Party Computation (MPC) . . . . . . . . . . . . . 124

B.3 Storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
B.4 Resource Pricing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125

C Adapter Examples 126
C.1 Oracle-Mediated Data-Source Access (MediatedReport) . . . . . . . . . 126
C.2 Cross-Ledger Reports (XL-Report-Read) . . . . . . . . . . . . . . . . . . 127
C.3 Confidential Switch (ConfSwitch) . . . . . . . . . . . . . . . . . . . . . 128

D Functional Signatures 129
D.1 Functional Signatures for Combining Data . . . . . . . . . . . . . . . . 130
D.2 Discretized Functional Signatures . . . . . . . . . . . . . . . . . . . . . 130

E Prospective Bribery 134

F Random vs. Committee-Based Oracle Selection 135

5



1 Introduction
Blockchain oracles are often viewed today as decentralized services with one objective:
to forward data from off-chain resources onto blockchains. It’s a short step, though,
from forwarding data to computing on it, storing it, or transmitting it bidirection-
ally. This observation justifies a much broader notion of oracles’ functionality. So too
do the growing service requirements of smart contracts and increasingly multifaceted
technologies that rely on oracle networks. In short, an oracle can and will need to
be a general-purpose, bidirectional, compute-enabled interface between and among on-
chain and off-chain systems. Oracles’ role in the blockchain ecosystem is to enhance
the performance, functionality, and interoperability of smart contracts so that they can
bring new trust models and transparency to a multiplicity of industries. This transfor-
mation will come about through broadening use of hybrid smart contracts, which fuse
blockchains’ special properties with the unique capabilities of off-chain systems such as
oracle networks and thereby achieve far greater reach and power than on-chain systems
in isolation.

In this whitepaper, we articulate a vision for what we call Chainlink 2.0, an evo-
lution of Chainlink beyond its initial conception in the original Chainlink whitepa-
per [98]. We foresee an increasingly expansive role for oracle networks, one in which
they complement and enhance existing and new blockchains by providing fast, reli-
able, and confidentiality-preserving universal connectivity and computation for hybrid
smart contracts. We believe that oracle networks will even evolve to become utilities
for exporting high-integrity blockchain-grade data to systems beyond the blockchain
ecosystem.

Today, Chainlink nodes run by a diverse set of entities come together in oracle net-
works to relay data to smart contracts in what are known as reports. We can view such
oracle nodes as a committee similar to that in a classical-consensus blockchain [72],
but with the goal of supporting existing blockchains, rather than providing freestand-
ing functionality. With verifiable random functions (VRF) and Off-Chain Reporting
(OCR), Chainlink is already evolving toward a general-purpose framework and infras-
tructure for providing the computational resources that smart contracts require for
advanced functionality.

The foundation of our plan for Chainlink 2.0 is what we call Decentralized Oracle
Networks, or DONs for short. Since we introduced the term “oracle network” in the
original Chainlink whitepaper [98], oracles have developed ever richer functionality and
breadth of application. In this paper, we offer a fresh definition of the term according
to our future vision for the Chainlink ecosystem. In this view, a DON is a network
maintained by a committee of Chainlink nodes. Rooted in a consensus protocol, it
supports any of an unlimited range of oracle functions chosen for deployment by the
committee. A DON thus acts as a blockchain abstraction layer, providing interfaces
to off-chain resources for both smart contracts and other systems. It also provides
access to highly efficient yet decentralized off-chain computing resources. In general,
a DON supports operations on a main chain. Its goal is to enable secure and flexi-

6



ble hybrid smart contracts, which combine on-chain and off-chain computation with
connection to external resources.

We emphasize that even with the use of committees in DONs, Chainlink itself
remains inherently permissionless. DONs act as the foundation of a permissionless
framework in which nodes can come together to implement custom oracle networks with
their own regimes for node inclusion, which may be permissioned or permissionless.

With DONs as a foundation, we plan to focus in Chainlink 2.0 on advances in seven
key areas: hybrid smart contracts, abstracting away complexity, scaling, confidential-
ity, order-fairness for transactions, trust minimization, and incentive-based (cryptoeco-
nomic) security. In this paper introduction, we present an overview of Decentralized
Oracle Networks in Section 1.1 and then our seven key areas of innovation in Sec-
tion 1.2. We describe the organization of the rest of this paper in Section 1.3.

1.1 Decentralized Oracle Networks
Decentralized Oracle Networks are designed to enhance and extend the capabilities
of smart contracts on a target blockchain or main chain through functions that are
not available natively. They do so by providing the three basic resources found in
computing systems: networking, storage, and computation. A DON aims to offer
these resources with strong confidentiality, integrity, and availability properties,1 as
well as accountability.

DONs are formed by committees of oracle nodes that cooperate to fulfill a specific
job or choose to establish a long-lived relationship in order to provide persistent services
to clients. DONs are designed in a blockchain-agnostic way. They promise to serve as
a powerful and flexible tool for application developers to create off-chain support for
their smart contracts on any supported main chain.

Two types of functionalities realize the capabilities of a DON: executables and
adapters. Executables are programs that run continuously and in a decentralized man-
ner on the DON. While they do not directly store main-chain assets, they have im-
portant benefits, including high performance and the ability to perform confidential
computation. Executables run autonomously on a DON and perform deterministic
operations. They work in hand with adapters that link the DON to external resources
and may be called by executables. Adapters, as we envision them for DONs, are a
generalization of the external adapters in Chainlink today. While existing adapters
typically only fetch data from data sources, adapters may operate bidirectionally; in
DONs, they may additionally leverage joint computation by DON nodes to achieve
additional features, such as encrypting reports for privacy-preserving consumption by
an executable.

To provide a sense of a DON’s basic operation, Fig. 1 shows conceptually how a
DON might be used to send reports to a blockchain and thus achieve traditional, exist-
ing oracle functionality. DONs can provide many additional features, however, beyond

1The “CIA triad” of information security [123, p. 26, §2.3.5].

7



Chainlink’s existing networks. For example, within the general structure of Fig. 1,
the executable could record fetched asset-price data on the DON, using such data to
compute, e.g., a trailing average for its reports.

Figure 1: Conceptual figure showing as an example how a Decentralized Oracle Net-
work can realize basic oracle functionality, i.e., relay off-chain data to a contract. An
executable uses adapters to fetch off-chain data, which it computes on, sending output
over another adapter to a target blockchain. (Adapters are initiated by code in the
DON, represented by small blue boxes; arrows show the direction of data flow for this
particular example.) The executable can additionally read and write to local DON
storage to keep state and/or communicate with other executables. Flexible network-
ing, computation, and storage in DONs, all represented here, enable a host of novel
applications.

A major benefit of DONs is their ability to bootstrap new blockchain services. DONs
are a vehicle by which existing oracle networks can quickly stand up service applications
that would today require the creation of purpose-built networks. We give a number of
examples of such applications in Section 4.

In Section 3, we provide more details on DONs, describing their capabilities in
terms of the interface they present to developers and users.

1.2 Seven Key Design Goals
Here we briefly review the seven key focuses enumerated above for the evolution of
Chainlink, namely:

8



Hybrid smart contracts: Central to our vision for Chainlink is the idea of securely
combining on-chain and off-chain components in smart contracts. We refer to contracts
realizing this idea as hybrid smart contracts or hybrid contracts.2

Blockchains are and will continue to play two critical roles in decentralized-service
ecosystems: They are both the loci where cryptocurrency ownership is represented
and robust anchors for decentralized services. Smart contracts must therefore be repre-
sented or executed on chain, but their on-chain capabilities are severely limited. Purely
on-chain contract code is slow, expensive, and insular, unable to benefit from real-world
data and a variety of functionalities that are inherently unachievable on chain, includ-
ing various forms of confidential computation, generation of (pseudo)randomness secure
against miner / validator manipulation, etc.

For smart contracts to realize their full potential therefore requires smart contracts
to be architected with two parts: an on-chain part (which we typically denote by SC)
and an off-chain part, an executable running on a DON (which we typically denote by
exec). The goal is to achieve a secure composition of on-chain functionality with the
multiplicity of off-chain services that DONs aim to provide. Together, the two parts
make up a hybrid contract. We present the idea conceptually in Fig. 2. Already today,
Chainlink services3 such as data feeds and VRFs are enabling otherwise unachievable
smart contract applications, ranging from DeFi to fairly generated NFTs to decentral-
ized insurance, as first steps toward a more general framework. As Chainlink services
expand and grow more performant according to our vision in this whitepaper, so too
will the power of smart contract systems across all blockchains.

Our other six key focuses in this whitepaper may be viewed as acting in the service
of the first, overarching one of hybrid contracts. These focuses involve removing visible
complexity from hybrid contracts, creating additional off-chain services that enable the
construction of ever more capable hybrid contracts, and, in the case of trust minimiza-
tion, bolstering the security properties achieved by hybrid contracts. We leave the idea
of hybrid contracts implicit throughout much of the paper, but any combination of
MAINCHAIN logic with a DON may be viewed as a hybrid contract.

Abstracting away complexity: DONs are designed to make use of decentralized
systems easy for developers and users by abstracting away the often complex machinery
behind DONs’ powerful and flexible array of services. Existing Chainlink services
already have this feature. For example, data feeds in Chainlink today present on-
chain interfaces that do not require developers to concern themselves with protocol-
level details, such as the means by which OCR enforces consensus reporting among a

2The idea of on-chain / off-chain contract composition has arisen previously in various constrained
forms, e.g., layer-2 systems, TEE-based blockchains [80], etc. Our goal is to support and generalize
these approaches and ensure that they can encompass off-chain data access and other key oracle
services.

3Chainlink services comprise a variety of decentralized services and functionality available through
the network. They are offered by the numerous node operators composed into various oracle networks
across the ecosystem.

9



Figure 2: Conceptual figure depicting on-chain / off-chain contract composition. A
hybrid smart contract 3Š consists of two complementary components: an on-chain
component SC 1Š, resident on a blockchain, and an off-chain component exec 2Š that
executes on a DON. The DON serves as a bridge between the two components as well
as connecting the hybrid contract with off-chain resources such as web services, other
blockchains, decentralized storage, etc.

decentralized set of nodes. DONs go a step further in the sense that they expand the
range of services for which Chainlink can offer developers an abstraction layer with
accompanying streamlined interfaces for high-level services.

We present several application examples in Section 4 that highlight this approach.
We envision enterprises, for instance, using DONs as a form of secure middleware to
connect their legacy systems to blockchains. (See Section 4.2.) This use of DONs ab-
stracts away the complexity of general blockchain dynamics (fees, reorgs, etc.). It also
abstracts away the features of specific blockchains, thereby enabling enterprises to con-
nect their existing systems to an ever-broadening array of blockchain systems without
a need for specialized expertise in these systems or, more generally, in decentralized-
systems development.

Ultimately, our ambition is to push the degree of abstraction achieved by Chainlink
to the point of implementing what we refer to as a decentralized metalayer. Such a layer
would abstract away the on-chain / off-chain distinction for all classes of developers
and users of DApps, allowing seamless creation and use of decentralized services.

10



To simplify the development process, developers could specify DApp functional-
ity in the metalayer as a virtual application in a unified machine model. They could
then use a decentralized-metalayer compiler to instantiate the DApp automatically as
a set of interoperating decentralized functionalities spanning blockchains, DONs, and
external services. (One of these external services could be an enterprise system, mak-
ing the metalayer useful for applications involving legacy enterprise systems.) Such
compilation is akin to how modern compilers and software-development kits (SDKs)
support generalist programmers in using the full potential of heterogeneous hardware
architectures consisting of a general-purpose CPU and specialized hardware like GPUs,
machine-learning accelerators, or trusted enclaves. Fig. 3 presents this idea at a con-
ceptual level.

Hybrid smart contracts are a first step along the way to this vision and to a con-
cept we call meta contracts. Meta contracts are applications coded on a decentralized
metalayer and implicitly encompass on-chain logic (smart contracts), as well as off-
chain computation and connectivity among various blockchains and existing off-chain
services. Given the need for language and compiler support, new security models, and
conceptual and technical harmonization of disparate technologies, however, realization
of a true decentralized metalayer is an ambitious goal to which we aspire over a long
time horizon. It is nonetheless a helpful ideal model to keep in mind while reading
this paper, not detailed here, but something we plan to focus on in our future work on
Chainlink.

Scaling: A goal of preeminent importance in our evolving designs is enabling the
Chainlink network to meet the growing scaling needs of the blockchain ecosystem.

With network congestion becoming a recurring problem in existing permissionless
blockchains [86], new and more performant blockchain designs are coming into use,
e.g., [103, 120, 203], as well as complementary layer-2 scaling technologies, e.g., [5,
12, 121, 141, 169, 186, 187]. Oracle services must achieve latencies and throughputs
that meet the performance demands of these systems while minimizing on-chain fees
(e.g., gas costs) for contract operators and ordinary users alike. With DONs, Chainlink
functionality aims to go further and deliver performance high enough for purely web-
based systems.

DONs derive much of their performance gain from their use of fast, committee-
based or permissionless consensus protocols, which they combine with the blockchains
they support. We expect many DONs with different configurations to run in paral-
lel; different DApps and users can navigate tradeoffs in underlying consensus choices
according to their application requirements.

DONs may be viewed in effect as layer-2 technologies. We expect that among
other services, DONs will support the Transaction Execution Framework (TEF), which
facilitates efficient integration of DONs and thus oracles with other high-performance
layer-2 systems—e.g., rollups, systems which bundle transactions off chain to achieve
performance improvements. We introduce the TEF in Section 6.

11



Figure 3: Conceptual figure showing ideal realization of a decentralized metalayer. For
ease of development, a developer specifies a DApp, highlighted in pink, as a virtual
application in a unified machine model. A decentralized-metalayer compiler automati-
cally generates corresponding interoperating functionalities: smart contracts (denoted
by SC), logic (denoted by exec) on DONs, adapters connecting to target external ser-
vices, and so forth, as indicated in yellow highlight.

Fig. 4 shows conceptually how DONs improve blockchain (smart contract) scaling
by concentrating transaction and oracle-report processing off chain, rather than on
chain. This shift in the main locus of computation reduces transaction latency and
fees while boosting transaction throughput.

Confidentiality: Blockchains provide unprecedented transparency for smart con-
tracts and the applications they realize. But there is a basic tension between trans-
parency and confidentiality. Today, for example, users’ decentralized exchange trans-

12



Figure 4: Conceptual figure showing how Decentralized Oracle Networks improve the
scaling of blockchain-enabled smart contracts. Figure AŠ shows a conventional oracle
architecture. Transactions are sent directly to the blockchain, as are oracle reports.
Thus the blockchain, highlighted in yellow, is the main locus for transaction process-
ing. Figure BŠ shows use of a DON to support contracts on the blockchain. A DON
executable processes transactions along with data from external systems and forwards
results—e.g., bundled transactions or contract state changes resulting from the trans-
actions’ effects—to the blockchain. The DON, highlighted in yellow, is thus the main
locus for transaction processing.

actions are recorded on chain, making it easy to monitor exchange behavior, but also
making users’ financial transactions publicly visible. Similarly, data relayed to smart
contracts remains on chain. This makes such data conveniently auditable, but acts as
a disincentive for data providers wishing to furnish smart contracts with sensitive or
proprietary data.

We believe that oracle networks will play a pivotal role in catalyzing next-generation
systems that combine blockchains’ innate transparency with new confidentiality pro-
tections. In this paper, we show how they will do so using three main approaches:

• Confidentiality-preserving adapters: Two technologies with planned deployment
in Chainlink’s networks, DECO [234] and Town Crier [233], enable oracle nodes to
retrieve data from off-chain systems in ways that protect user privacy and data
confidentiality. They will play a key role in the design of adapters for DONs.
(See Section 3.6.2 for details on these two technologies.)

• Confidential computation: DONs can simply conceal their computation from re-
lying blockchains. Using secure multi-party computation and/or trusted execu-
tion environments, stronger confidentiality is also possible in which DON nodes
compute over data into which they themselves do not have visibility.

13



• Support for confidential layer-2 systems: The TEF is designed to support a va-
riety of layer-2 systems, many of which use zero-knowledge proofs to provide
various forms of transaction confidentiality.

We discuss these approaches in Section 3 (with additional details in Section 6, Ap-
pendix B.1, and Appendix B.2).

Fig. 5 presents a conceptual view of how sensitive data might flow from exter-
nal sources to a smart contract by means of confidentiality-preserving adapters and
confidential computation in a DON.

Figure 5: Conceptual diagram of confidentiality-preserving operations in a DON on
sensitive data (highlighted in yellow). Sensitive source data (black circles) in web
servers is extracted to the DON using confidentiality-preserving adapters (blue, double-
arrowed lines). The DON receives derived data (hollow circles) from these adapters—
the result of applying either a function or, e.g., secret-sharing, to the sensitive source
data. An executable on the DON may apply confidential computation to derived data
to construct a report (double circle), which it sends over an adapter to the blockchain.

We believe that powerful tools for handling confidential data will open up a whole
range of applications. Among these are private decentralized (and centralized) fi-
nance, decentralized identity, credit-based on-chain lending, and more efficient and
user-friendly know-your-customer and accreditation protocols, as we discuss in Sec-
tion 4.

Order-fairness for transactions: Today’s blockchain designs have a dirty little
open secret: They are ephemerally centralized. Miners and validators can order trans-

14



actions however they choose. Transaction order can also be manipulated by users as
a function of the network fees they pay (e.g., gas prices in Ethereum) and to some
extent by taking advantage of fast network connections. Such manipulation can, for
example, take the form of front-running, in which a strategic actor such as a miner
observes a user’s transaction and inserts its own exploitative transaction int";"""date"",""2021-04-15T13:29:29Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2021-04-15T13:29:29Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.20 (TeX Live 2019) kpathsea version 6.3.1""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2021-04-15T13:29:29Z""
""created"",""2021-04-15T13:29:29Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2021-04-15T13:29:29Z""
""resourceName"",""whitepaper-v2.pdf""
""Author"",""""
""producer"",""pdfTeX-1.40.20""
""pdf:docinfo:producer"",""pdfTeX-1.40.20""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""3"",""0"",""0"",""2"",""0"",""9"",""0"",""0"",""1"",""0"",""0"",""2"",""0"",""0"",""0"",""1"",""8"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""5"",""1"",""3"",""0"",""0"",""4"",""0"",""8"",""0"",""0"",""0"",""0"",""0"",""2"",""0"",""0"",""0"",""0"",""0"",""2"",""0"",""0"",""0"",""1"",""0"",""0"",""0"",""4"",""0"",""0"",""1"",""4"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""4"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""1"",""1"",""0"",""0"",""0"",""0"",""0"",""2"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""2"",""4"",""2"",""14"",""3"",""7"",""23"",""5"",""1"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2021-04-15T13:29:29Z""
""Last-Modified"",""2021-04-15T13:29:29Z""
""dcterms:modified"",""2021-04-15T13:29:29Z""
""title"",""""
""Last-Save-Date"",""2021-04-15T13:29:29Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2021-04-15T13:29:29Z""
""meta:save-date"",""2021-04-15T13:29:29Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.20 (TeX Live 2019) kpathsea version 6.3.1""
""Content-Length"",""3689842""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""136""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""1157"",""2205"",""1798"",""1909"",""1183"",""2797"",""2590"",""1244"",""2895"",""1398"",""2701"",""883"",""1714"",""1380"",""2097"",""2282"",""1157"",""1202"",""2344"",""2357"",""2647"",""2411"",""2389"",""1159"",""2281"",""2388"",""2019"",""2273"",""2449"",""2541"",""2402"",""2581"",""2692"",""2523"",""2366"",""2411"",""2686"",""2608"",""2634"",""1045"",""2373"",""1844"",""2505"",""2571"",""2231"",""2760"",""2565"",""1063"",""2357"",""2418"",""2442"",""2437"",""2479"",""2582"",""2585"",""2560"",""2424"",""2021"",""854"",""2213"",""2366"",""1580"",""2752"",""2264"",""2452"",""1730"",""2150"",""2256"",""2547"",""2362"",""2338"",""2226"",""2684"",""2381"",""1826"",""2540"",""2719"",""2537"",""2893"",""2472"",""2399"",""2682"",""2741"",""2497"",""2474"",""2594"",""2255"",""1571"",""2392"",""1564"",""2407"",""2475"",""2686"",""2370"",""2491"",""2623"",""1836"",""2544"",""2125"",""2574"",""702"",""2673"",""1930"",""2587"",""2701"",""2669"",""2724"",""2734"",""2671"",""2666"",""2598"",""2688"",""2484"",""2698"",""2646"",""2384"",""2158"",""2214"",""2234"",""2627"",""2332"",""2490"",""2526"",""2811"",""2346"",""1539"",""1689"",""2043"",""1554"",""1965"",""2419"",""1866"",""2204"",""2133"",""2326"",""888""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2021-04-15T13:29:29Z""
";https://scholar.google.ch/scholar?start=20&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2021
1619099138-480;https://scholar.google.ch/scholar?as_ylo=2021&q=oracles+blockchain&hl=fr&as_sdt=0,5;What is a Blockchain? A Definition to Clarify the Role of the Blockchain in the Internet of Things;L Ghiro, F Restuccia, S D'Oro, S Basagni… ; arXiv preprint arXiv …, 2021  arxiv.org;;"… 1 Introduction The blockchain came into the limelight with the advent of the Bitcoin

cryptocurrency, by far the most successful blockchain application, which in January of 2021

set its new record of market capitalization exceeding 758 billions of US dollars …";Les 2 versions;Version HTML;[PDF] arxiv.org;https://arxiv.org/pdf/2102.03750;"
What is a Blockchain? A Definition to Clarify the Role
of the Blockchain in the Internet of Things

Lorenzo Ghiro,1 Francesco Restuccia,2 Salvatore D’Oro,2 Stefano Basagni,2

Tommaso Melodia,2 Leonardo Maccari,3 Renato Lo Cigno4

1University of Trento, Italy, 2Northeastern University, USA,
3University of Venice, Italy, 4University of Brescia, Italy

Abstract

The use of the term blockchain is documented for disparate
projects, from cryptocurrencies to applications for the Internet
of Things (IoT), and many more. The concept of blockchain
appears therefore blurred, as it is hard to believe that the same
technology can empower applications that have extremely dif-
ferent requirements and exhibit dissimilar performance and se-
curity. This position paper elaborates on the theory of dis-
tributed systems to advance a clear definition of blockchain that
allows us to clarify its role in the IoT. This definition inextri-
cably binds together three elements that, as a whole, provide
the blockchain with those unique features that distinguish it
from other distributed ledger technologies: immutability, trans-
parency and anonimity. We note however that immutability
comes at the expense of remarkable resource consumption,
transparency demands no confidentiality and anonymity pre-
vents user identification and registration. This is in stark con-
trast to the requirements of most IoT applications that are made
up of resource constrained devices, whose data need to be kept
confidential and users to be clearly known. Building on the
proposed definition, we derive new guidelines for selecting
the proper distributed ledger technology depending on appli-
cation requirements and trust models, identifying common pit-
falls leading to improper applications of the blockchain. We
finally indicate a feasible role of the blockchain for the IoT:
myriads of local, IoT transactions can be aggregated off-chain
and then be successfully recorded on an external blockchain as
a means of public accountability when required.

1 Introduction

The blockchain came into the limelight with the advent of the
Bitcoin cryptocurrency, by far the most successful blockchain
application, which in January of 2021 set its new record of
market capitalization exceeding 758 billions of US dollars.
The blockchain features observed in Bitcoin, i.e., decentral-
ization, resistance to powerful cyberattacks and preservation
of users privacy, raised the enthusiasm of many research com-
munities. This enthusiasm led to an extremely large number
of disparate proposals for using the blockchain in many dif-
ferent applications, including Supply Chain Management [1–
4], E-Voting [5–12], Smart Grid [13–20], Healthcare [21–24],
Banking [25, 26], Smart Cities [27–29], and even Vehicular and
Aerial Networks [30–48]. Surveys abound on the efforts of ap-
plying the blockchain also to the many expressions of the Inter-
net of Things (IoT) [49–57]. This vast application range makes

the blockchain seem a universal technology, no longer limited
only to cryptocurrencies but also capable to empower most IoT
applications, addressing their multiple vulnerabilities [58].

This apparent universality of the blockchain looks suspi-
cious, suggesting that the term is used with many different
meanings. Considering that the Bitcoin blockchain currently
supports the validation of less than 10 Transactions per Sec-
ond (TPS) and exhibits a power consumption similar to that of
an industrialized country such as Ireland [59], it is dubious that
it can support the millions of IoT TPS [60] and meet the typ-
ical IoT power constraints. In fact, we notice that moving to
application domains different from cryptocurrencies, the origi-
nal characteristics of the Bitcoin blockchain have been diluted,
if not completely transformed, leading to possible misunder-
standing and confusion. On the one hand, we have the per-
missionless blockchains like Bitcoin [61], celebrated for their
Proof of Work (PoW)-based cryptographical security, their de-
centralization and strict privacy defense through anonymity.
On the other hand, many proposed “blockchains” are permis-
sioned, requiring user identities to be registered with some
trusted authority (or consortium) and whose internal security
does not depend on some hard cryptographical problem like
the PoW. As a consequence, the term blockchain appears to be
overloaded, and therefore ambiguous, as it is used to indicate
ledger technologies that under the hood obtains security, per-
formance and decentralization in completely different ways.

This position paper analyzes the multiple technologies prof-
fered under the term blockchain and proposes a clear definition
of blockchain that allows us to argue about its role in the IoT.
Building on the theory of distributed systems and on the crit-
ical analysis of current blockchain applications, the definition
identifies three elements that, only when combined together,
give to blockchains their specific features of openness, decen-
tralization, security and ability to preserve user privacy. These
three elements are: relying on a STRONG DISTRIBUTED CON-
SENSUS PROTOCOL, which makes the blockchain immutable,
hence secure from tampering attacks, and further frees the sys-
tem from centralized trusted authorities (e.g., banks); maintain-
ing a FULL & PUBLIC HISTORY OF TRANSACTIONS, which
permits their distributed and completely transparent valida-
tion, and being OPEN TO ANONYMOUS USERS, thus allowing
blockchains to preserve users privacy.

A definition for blockchain based on these three elements re-
sults quite restrictive, amplifying the voice of those who also
advocate a strict definition of blockchain [62–64]. However,
clarifying the nature of the blockchain with this clear defini-
tion allows us to argue that the blockchain is not the univer-
sal and limitless technology that may seem to be. In fact, we

1

ar
X

iv
:2

10
2.

03
75

0v
1 

 [
cs

.C
R

] 
 7

 F
eb

 2
02

1



state that blockchains are beneficial only for a limited range of
applications, and that their integration into the IoT domain is
not appropriate. We substantiate these arguments drawing new
guidelines for the proper adoption of the blockchain, suggest-
ing clearly when the blockchain should not be adopted. We do
so highlighting a list of common scenarios where the applica-
tions requirements conflict with the blockchain characteristics.
For example, the use of a blockchain for storing sensitive infor-
mation is a pitfall, because the blockchain immutability would
prevent the compliance with regulations that demand user data
to be erasable upon request.

The remainder of this paper includes a review of the fun-
damental principles of the blockchain (Section 2) and of its
theoretical roots, namely, distributed consensus protocols (Sec-
tion 3). We acknowledge that the analysis proposed in this pa-
per is partial, meaning that the goal of the paper is to restrict
the meaning of blockchain, rather than building an exhaustive
list of all its possible meanings and uses, as a standard survey
would do. Still, we provide abundant academic references in
support of our definition and highlight that there are only ben-
efits —for the scientific community, industry and practition-
ers at large— to restrict and disambiguate the use of this term
and rather using different ones, inventing them if necessary, to
identify technologies and solutions that are far away from the
original use of the term. In Section 4 we condense the specific
features of blockchains into a connotative definition, based on
which we build the guidelines for the proper adoption of the
blockchain technology. We then discuss popular applications
that contrast with the proposed definition of blockchain in Sec-
tion 5, explaining which application requirements clash with
the blockchain features. In Section 6 we indicate a possible
role for blockchains in the IoT, namely, they can play as com-
plementary (external) ledger services. Final remarks are drawn
in Section 7.

2 Blockchain Fundamentals

Figure 1 is proposed to gently introduce the blockchain funda-
mentals starting from an illustration of the life-cycle of a trans-
action, which will be finally registered in a blockchain. Every-
thing starts when a transaction is issued, e.g., because a smart
device is querying a remote service and pays to access the data.
The transaction is announced in the P2P network and received
by validator nodes. These nodes run a consensus protocol to
decide about the validity of the transaction. If they reach a con-
sensus on the fact that the device really owns the resources that
is about to spend, then the transaction is considered valid. If
so, it is grouped with others recently approved, forming a new
block of transactions that will be registered in the ledger by
appending it to the blockchain. At the end, the success of the
transaction is notified to the users and the data is transferred to
the device.

At first glance, the blockchain can be defined as the plain
data structure used to record transactions. However, from a
broader perspective, a blockchain can be considered a dis-
tributed system that in general includes:

• A Peer-to-Peer (P2P) network made of all those nodes
that either read or cooperatively write transactions in the
blockchain, and

(1) A Transaction (TRX)

is submitted

(2) The TRX is broadcast

in a P2P network

(3) Nodes run a 

Consensus 

protocol to validate

the TRX

(4) If valid, the TRX is 

grouped with other 

TRXs to form a new 

block of the Ledger

(5) The new block is appended to the 

blockchain, linked to the last block(6) TRX completed!

Figure 1: Processing of a transaction before storage in the blockchain.

• a consensus protocol, namely, a set of policies agreed upon
and implemented by all nodes, which are the rules that reg-
ulate which and how new transactions can be added to the
blockchain.

A blockchain turns out to be a possible implementation
of a Shared Ledger. The group of entities allowed to write
new transactions in the Shared Ledger, appending them to the
blockchain, can vary from few selected and authenticated users
up to any anonymous user. These different writing privileges
depend on the rules of the chosen consensus protocol, which
are decisive to determine if the resulting Shared Ledger will be
public or private.

Public or Permissionless Ledger In a public (permission-
less) ledger, the record of transactions is public and the con-
sensus protocol is open to anybody. This means that i) any-
one in the world can verify the correctness of the ledger and
ii) even anonymous strangers without explicit permission can
join the network and participate in the validation process of
transactions, provided only that they comply with the consen-
sus protocol. The absence of any form of control on users,
that are not accountable as they are anonymous, is a an issue
for the security of the ledger. To counter this lack of trust and
still ensure security, the usual consensus protocol of a permis-
sionless ledger imposes stringent conditions to be met upon
proposing a new block of transactions. Such conditions are
so severe that, somehow, prove the honest commitment of the
proposer. For example, in both Bitcoin and Ethereum— the
most iconic permissionless blockchains— the proposer of a
new block of transactions must provide the so-called Proof of
Work (PoW), which is the solution to a very hard cryptograph-
ical problem. This mechanism secures the ledger discouraging
malicious users, but hampers the ledger performance as well.
Consider, for example, that the number of TPS processed by
Bitcoin and Ethereum is on average below 20 TPS, a very lim-
ited throughput if compared to the tens of thousands processed
by Visa [65]. Moreover, in the Visa platform transactions are
recorded sequentially, not in blocks. For this reason the trans-
action latency, i.e., the interval of time between submission and
recording of a transaction, can be kept down to at most a few
seconds with Visa, while in Bitcoin the same latency averages
tens of minutes and can grow up to several hours.

Private or Permissioned Ledger Private ledgers arose as
an attempt to improve performance and to have more control

2



on users. These ledgers are typically implemented by big cor-
porations or banks, so to have a common platform to share
business information among few and well known partners. A
shared and mutual level of trust can be given for granted, as
only registered (hence accountable) entities have the permis-
sion to write data into the blockchain. The security of permis-
sioned blockchains depends therefore on classical authentica-
tion mechanisms rather than on the mathematical strength of
techniques such as the PoW. The trust model resulting from per-
missions allows blockchain managers to replace the resource-
hungry consensus protocols of permissionless blockchains with
more traditional, efficient, and faster ones. Such faster consen-
sus protocols are necessary to support critical business opera-
tions, whose recording cannot tolerate the typical low transac-
tion rates and high inefficiencies of permissionless ledgers.

For the first time, permissionless ledgers free users from
trusted authorities, such as a Public Key Infrastructure (PKI) or
banks, with the added novelty that the validation process hap-
pens transparently in public, without uncovering the identity of
users. The trust required to maintain a public, permissionless
ledger open to anonymous users is given by the consensus pro-
tocol only. A permissionless blockchain can thus be considered
as a trust builder in a trustless network and the enabler of an
open, privacy-preserving, disintermediated marketplace.

2.1 The Need of the Transactions History
Validators need the history of transactions to determine who
and how many resources each user owns, an indispensable
knowledge to validate new transactions. However, building this
history in a distributed system is complicated by the double
spending problem, briefly described below.

Double Spending Problem

Two transactions that spend the same resources may be pro-
cessed in different order by distinct validators spread across a
P2P network. This is because of different propagation delays in
the network (Figure 2). At this point, it is crucial for validators
to find an agreement on the order of transactions to determine
which of the two came in first, and should be considered valid,
and which came in second and should be rejected.

5BTC from A to B 5BTC from A to C
Transmitter

RX1

RX2

RX order 1

RX order 2

Time

Figure 2: Example of how propagation delays may lead to two different
orders of reception at distinct validators. Validators need to run a con-
sensus protocol to find an agreement on the order of transactions. In
this example if A owns only 5BTC then one of the two transactions must
be rejected because it would represent a double spending.

This fundamental problem is also known as Distributed Con-
sensus Problem. An equivalent problem is the implementation
of a distributed timestamp server able to sort transactions in an

indisputable chronological order. The blockchain has been in-
troduced in 2008 by the mysterious author of Bitcoin, Satoshi
Nakamoto, exactly as a way to implement a distributed times-
tamp server that assigns timestamps to (blocks of) transactions,
this way establishing their history.

However, the history of transactions may not be enough for
a correct validation. Indeed, a malicious user can alter the con-
tent of a block to repudiate an unwanted transaction, ultimately
falsifying the validation procedure. To fend off falsification at-
tacks a blockchain must be:

• Tamper-proof : i.e., made so that is easy to verify that the
registered transactions have not been manipulated after their
recording, and it should be likewise easy to determine if
these have been actually altered in a second instance of
time.

• Immutable: a blockchain-based ledger should adequately
word off tampering attacks.

The tamper-proof property of blockchains is achieved by a
clever embedding of Cryptographic Hash Functions (CHFs)
into the blockchain data structure, as explained in Section 2.2.

2.2 The Blockchain Data Structure
CHFs are crucial to make blockchains tamper-proof. To be-
come tamper-proof, transactions must be grouped into blocks
including few other information as shown in Figure 3.

Hash of 
previous Block

Payload

Header

Block i-1

Block Hash

Transaction
…

Prev Hash

Timestamp

Nonce
Hash (                                      ) Hash of 

previous Block

Payload

Header

Block i
PAST

Transaction

Figure 3: The structure of a blockchain.

For example, in Bitcoin a block is valid if, hashing its con-
tent, the produced fixed-length digest1 exhibits a predefined
number of leading zeros. This digest is said to be the “Block
Hash.” The Block Hash must be a number lower than a given
target, a target that can be changed to adjust the difficulty [66]
of finding a valid Block Hash. Finding a valid Block Hash
can become an hard problem considering the random nature of
CHFs and the nodes strategy for generating new blocks, which
is the following.

At first, a validator groups together some recent transactions
and assigns them a timestamp. Then, to further enforce the
time dependency between blocks, it includes in the new block
the Block Hash of the last block he is aware of. The references
to previous blocks constitute the chaining of blocks. Finally,
a validator guesses a random value (the nonce), includes it in
the new block, and applies the hash function to all these infor-
mation to compute a new digest, which becomes a candidate
Block Hash. This digest can be smaller than the target, thus not
valid. A node is usually forced to retry with as many different
random nonces as possible, until it produces (via brute force) a
valid Block Hash.

1 A message digest is a fixed size numeric representation of the contents of
a message, as computed by a hash function.

3



If someone tries to tamper block i, the attack will invalidate
its Block Hash with high probability. Because of blocks chain-
ing also block i+ 1 gets invalidated and, with a domino effect,
all blocks following block i get invalidated as well. This mech-
anism makes the blockchain a tamper-proof technology.

2.3 Proof of Work (PoW)
Consider that the CHF mandated by the Bitcoin protocol is
double-SHA256, which produces digests of 256 bits and, at the
current Bitcoin difficulty level, the first 77 bits must be zero.
The probability for a random nonce to be valid can be approxi-
mately computed as a function of the required number of lead-
ing zeros, that we call Z. The set of all possible digests that
the double-SHA256 function can generate has a cardinality of
2256. Only digests that have Z leading zeros are valid, so the
cardinality of the set of valid digests is given by 2256−Z . The
probability P (n) for a random nonce to produce a valid digest
is therefore:

P (n) =
2256−Z

2256
=

1

2Z
. (1)

For Z = 77, then P (n) ≈ 6.62× 10−24.
When a node finds a valid nonce, it can show it to all other

nodes in the P2P network as a proof of work (PoW), i.e., as a
proof of the effort (computing power and ultimately energy in
this case) that this node has spent to find such nonce. By show-
ing a valid nonce, the node can claim the reward that the Bit-
coin protocol assigns to nonce discoverers, which is the right of
including a transaction that generates new Bitcoins and trans-
fers them to the discoverer digital wallet. These rewards in-
centivize nodes in the hard task of discovering the very rare
valid nonces. Those nodes that are constantly at work looking
for valid nonces are metaphorically called “miners.” Asking
miners to produce a PoW for building a valid block is an impor-
tant mechanism to control the generation interval of new blocks
(Section 2.4) and and to secure the blockchain (Section 2.5).

2.4 Block Generation Interval
The difficulty of the PoW is tuned so that, in the whole P2P net-
work of miners, a valid block is produced on average every 10
minutes. To keep a constant Block Generation Interval (BGI ),
the difficulty of the PoW must be tuned according to the min-
ers computing power, which has remarkably increased during
the years (Figure 4), reaching the record of 166 658 millions of
Tera-hash computed per second (TH/s).

The BGI must be kept high to avoid the simultaneous pro-
duction of two blocks as far as possible. Two blocks are consid-
ered “simultaneous” if the second one is generated within the
average Block Propagation time (BP ), which for any P2P over-
lay based on transactions is in the orders of seconds to maxi-
mum tens of seconds [67]. Simultaneous blocks are problem-
atic because their almost contemporaneous proposal divides
the nodes of the Bitcoin network in two parties that will ap-
pend the two different blocks to the blockchain, forming two
branches. This situation can be represented by a bifurcation
of the blockchain and is called a “fork.” When a fork occurs,
it means that there is no distributed consensus on block order
anymore, thus there is no agreement on the order of transac-
tions. Without this agreement, the system is exposed again to
Double Spending attacks.

2010
2011

2012
2013

2014
2015

2016
2017

2018
2019

2020
2021

Time

10 6

10 3

100

103

106

109

1012

M
in

er
s 

Co
m

pu
t. 

Po
w

er
 &

 B
lo

ck
 D

iff
ic

ul
ty Bitcoin Relative Difficulty

Hash Rate [Hash/sec]

Figure 4: Evolution of the Bitcoin network computing power, measured
in hash per second (shown in logarithmic scale). Over time the block
difficulty has been adjusted to keep a constant average block production
rate. Statistics are taken from blockchain.com

Usually forks are transient and are cleared as soon as another
block is presented, making one branch longer than the other.
This mechanism is called “the longest-chain rule” [68, 69], and
it is inherent to the blockchain technology, thus representing a
constraint in the design of blockchain based systems. The rule
also implies that orphan blocks that do not end up to be part of
the longest chain are not valid: these blocks are also called stale
blocks. The transactions included in the stale blocks, reward as
well, will not be considered valid. Miners do not want to waste
resources working on blocks that will not be part of the longest
chain, therefore, they immediately switch to a longer branch as
soon as they notice such one, increasing this way their chances
of winning a more secure reward [68]. This ensures that the
majority of miners always work on the longest branch.

2.5 The Security of the PoW

While block hashing and chaining make blockchains tamper-
proof, as explained in Section 2.2, the PoW is key to make
blockchains immutable. Consider a malicious user that per-
formed a transaction spending a considerable amount of cryp-
tocurrency. This transaction was included in a given block, say,
block i, and the user now wants to revoke it. One way to revoke
this transaction is to cancel it from block i, but this way block i
would get invalidated and, by hash chaining, also all the follow-
ing blocks: the tamper-proof property of blockchains defuses
this kind of attack. Another strategy exploits the longest-chain
rule and consists in generating a second and longer chain of
blocks that, starting from block i−1, would replace the current
chain that contains block i.

This attack that exploits the longest-chain rule is clearly a
daunting task. To be successful, the malicious user must beat
all the other miners that during the attack keep using their col-
lective computing resources to extend the blockchain with new
blocks. In general, the average probability pa of being the first
to create and add a new block is the fraction of the computing
resources controlled by a user, and block mining can be consid-
ered independent, so that the probability of adding N consecu-
tive blocks is pNa , as shown in Figure 5 for different computing
power ratios.2

2 For each new block, all miners start competing to find a valid nonce almost
at the same time, i.e., when the hash name of the last block is revealed and
broadcast in the peer-to-peer network. For this reason, all the “races for the
next block” can be considered independent.

4

blockchain.com


0 1 2 3 4 5 6 7 8
Block Depth

0.000
0.025
0.050
0.075
0.100

0.200

0.300

0.400

0.500

0.600
Pr

ob
ab

ilit
y 

of
 S

uc
ce

ss
fu

l A
tta

ck
Attacker Computing Power Ratio

10%
20%
30%

40%
50%
60%

Figure 5: Probability for an attacker that owns different amounts of com-
puting resources to tamper a block, as function of the block depth. The
depth of a block b is the number of blocks that have been added to the
blockchain after b. The success probability decays exponentially fast,
vanishing for blocks that are deep in the blockchain.

Some believe that owning the majority of the computing
power ensures the control of the network through the so called
“50+1% attack.” The simple analysis above shows clearly that
this is not enough, in general, to tamper any arbitrary block in-
cluded in the history of transactions. Rather, the existence of an
extremely powerful user may lead to a biased system where this
user decides with high probability which transactions should be
recorded and which others should be ignored from now on in
the future, but the immutability of the deepest blocks of the
blockchain is not harmed. In fact, Bitcoin uses block depth
as confirmation, and recommends users to consider a transac-
tion to be final only if it has been confirmed by 6 subsequent
blocks [70], a number that guarantees it is almost unassailable.

2.6 Mining Overhead and Stale Rate
The Average Mining Overhead (AMO) denotes the percentage
of the network computing power that, on average, does not con-
tribute to the growth of the main chain, but rather leads to the
generation of stale blocks.

Def. 2.1: Average Mining Overhead

AMO(R,BP ,BGI ) := (1−R)× BP

BGI

• R ∈ (0, 1] is the ratio of the collective network comput-
ing power controlled on average by a successful miner. The
complementary computing power ratio controlled by unsuc-
cessful miners is 1−R;

• BP is the average block propagation time;

• BGI is the average block generation time interval.

Definition 2.1 states that, in each block generation interval
BGI , unsuccessful miners waste their computing power (1−R)
for BP time, i.e., until they learn about the newly proposed
block. By definition, the AMO contributes to the generation of
stale blocks. Hence, it is proportional to the stale rate, trivially
defined by the ratio between the number of stale blocks and the
total number of generated blocks.

Def. 2.2: Stale Rate

#Stale Blocks
#Stale + Final Blocks

∝ AMO(R,BP ,BGI )

The stale rate (Definition 2.2) is considered an indicator of
the security level of a PoW-based blockchain, because a higher

stale rate means that a blockchain is more exposed to chain
replacement and eclipse attacks [71]. Notice also that, fixing
the other parameters (R and BP ), increasing the BGI leads
to a lower stale rate, enhancing the blockchain security. The
high BGI (in the order of several minutes) chosen by many
blockchains for cryptocurrencies [72] represents the effort of
enhancing the mining efficiency and security by trading trans-
action throughput and confirmation time. Notice also that a
higher BGI enhances the miners profits, because reducing the
mining overhead implies that investments on mining equipment
become in percentage more profitable.

2.7 Power consumption of the PoW

Section 2.6 highlighted how one can increase the security of
a blockchain extending the Block Generation Interval (BGI ).
An extension of the BGI can be immediately achieved increas-
ing the mining difficulty: this way the cryptographical puzzle
necessary to produce a valid block becomes harder, thus more
time-consuming but also power-hungry. The effort of setting
up an exceptionally secure blockchain resulted, in Bitcoin, in
a PoW that has become extraordinarily power-hungry [59, 73].
The power consumption of the Bitcoin network in 2018 were
estimated to be 2.55 GW, and forecast to reach 7.67 GW in the
future. This requirement is comparable to the energy demand
of a whole country such as Ireland [59], so it is hard to think
that a blockchain secured by the PoW could be integrated in the
constrained domain of the IoT.

3 Distributed Consensus Protocols

Section 2 posed the distributed consensus problem on the or-
der of transactions and explained how the PoW solves it. The
PoW advantages are many: it is extraordinarily secure, fully
distributed, and user-agnostic. In fact, users can participate to
a PoW-based consensus without registering their identity with
some trusted registrar or bank, but just providing some com-
puting power. Ultimately the PoW i) protects the user privacy
and ii) free users from trusted authorities. The popularity of
blockchains, above all with cryptocurrencies, is most probably
grounded in these two key aspects. However, the PoW imposes
also serious limitations in terms of transaction latency, through-
put and power consumption.

It can be observed that consensus protocols are a crucial
component for a Shared Ledger: performance, consistency,
policies of governance, security, and tolerance to failures are
all properties of a Shared Ledger that depend on the selected
consensus protocol, rather than on the data structure used to
record transactions. A question arises: Is it possible to design
a consensus protocol that preserves the PoW advantages and,
at the same time, avoids its drawbacks so to meet the typical
requirements of IoT applications?

The rest of this section revises the general limits of dis-
tributed systems, which constitute theoretical bounds for the
design of consensus protocols in general, and especially for
IoT applications. We first summarize these fundamental the-
orems valid for any distributed system (Section 3.1), then we
explore the trade-offs inherent to the blockchain technology
(Section 3.2). Finally, in Section 3.3, we briefly review con-
sensus protocols in search of alternatives to the PoW.

5



3.1 Limiting Theorems for Consensus
It is well known that it is impossible to achieve consensus in
distributed systems in the presence of faulty nodes and unreli-
able communication channels [74]. The proof is based on this
intuition: every time a consensus is close to be achieved among
distributed agents, then a node or a communication failure may
occur preventing the termination of consensus forever. This im-
possibility proof is in tight relation with another fundamental
pillar of distributed systems, i.e., the Consistency, Availability
and Partition tolerance (CAP) theorem [75]. The CAP theorem
states that whenever a system gets Partitioned, then only two
options are available: i) grant Consistency by safely blocking
the system to fix the failures; or ii) keep processing transac-
tions favoring Availability, with the risk that the two conflicting
transactions (e.g., Double Spending ones) could be recorded,
one per partition. This theorem is usually illustrated with a tri-
angle with vertexes occupied by the three properties, stating
that only two out of the three properties can be satisfied at the
same time.

Both the impossibility proof and the CAP theorem may be
considered only mildly relevant, as they are valid only for ill-
behaving systems, while in practice a system is built to work
properly for most of its lifetime. However, they are the ante-
room for the definition of two (almost equivalent) tradeoffs of
tremendous practical importance.

The first tradeoff is known as PACELC [76], which advances
the CAP theorem (shuffling the acronym) and adding: Else
Latency or Consistency. The novelty of PACELC is consid-
ering the case when the system is not partitioned, stressing on
the tradeoff that arises between latency and consistency. 3 A
corollary to PACELC restricts the tradeoff to non-commutative
transactions [77]. The observation that enables this corollary is
that if two non-conflicting (commutative) transactions are per-
formed in two different partitions, the overall consistency of
the system is not compromised. This is an important restriction
because, if transactions could be defined to be always commu-
tative (which is impossible in a partitioned system), then an
always consistent and available distributed system could be de-
signed. An interesting consequence is that, if there are only
few non-commutative transactions, all others can be exe";"""date"",""2021-02-09T02:49:18Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2021-02-09T02:49:18Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.21 (TeX Live 2020) kpathsea version 6.3.2""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2021-02-09T02:49:18Z""
""created"",""2021-02-09T02:49:18Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2021-02-09T02:49:18Z""
""resourceName"",""2102.03750""
""Author"",""""
""producer"",""pdfTeX-1.40.21""
""pdf:docinfo:producer"",""pdfTeX-1.40.21""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2021-02-09T02:49:18Z""
""Last-Modified"",""2021-02-09T02:49:18Z""
""dcterms:modified"",""2021-02-09T02:49:18Z""
""title"",""""
""Last-Save-Date"",""2021-02-09T02:49:18Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2021-02-09T02:49:18Z""
""meta:save-date"",""2021-02-09T02:49:18Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.21 (TeX Live 2020) kpathsea version 6.3.2""
""Content-Length"",""1412799""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""20""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""5042"",""5257"",""4844"",""5169"",""4867"",""5175"",""5644"",""4556"",""4867"",""5573"",""4974"",""5585"",""5986"",""5023"",""4819"",""6893"",""7667"",""7800"",""7757"",""2883""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2021-02-09T02:49:18Z""
";https://scholar.google.ch/scholar?start=70&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2021
1619099142-496;https://scholar.google.ch/scholar?as_ylo=2021&q=oracles+blockchain&hl=fr&as_sdt=0,5;Weaponising Blockchain: Military Applications of Blockchain Technology in the US, China and Russia;B Lilly, S Lilly ; The RUSI Journal, 2021  Taylor & Francis;;"… of existence (2008–18) was tied to the deployment and exchange of cryptocurrencies, with the

virtual or 'crypto assets' Bitcoin … which the PLA's current inventory system could retrofit in situ

radio-frequency identifiers to function as blockchain readers or 'oracles', such as …";Les 2 versions;;null;;;;https://scholar.google.ch/scholar?start=80&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2021
1619099129-461;https://scholar.google.ch/scholar?as_ylo=2021&q=oracles+blockchain&hl=fr&as_sdt=0,5;Blockchain Bills of Lading and Their Future Regulation;F Wang ;2021 papers.ssrn.com;;"… but for usage and transaction of the cryptocurrency known as 'Bitcoin'.28 The function

and application of blockchain have been widely recognised over the past few years;

however, there is no uniformly accepted definition of it …";Les 3 versions;;[PDF] nus.edu.sg;https://law.nus.edu.sg/wp-content/uploads/2021/04/CML-WPS-2101.pdf;"
";"""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""Content-Encoding"",""windows-1252""
""resourceName"",""CML-WPS-2101.pdf""
""language"",""""
""robots"",""noindex,nofollow""
""Content-Length"",""212""
""Content-Type"",""text/html; charset=windows-1252""
";https://scholar.google.ch/scholar?start=50&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2021
1619099138-479;https://scholar.google.ch/scholar?as_ylo=2021&q=oracles+blockchain&hl=fr&as_sdt=0,5;Two-layer Adaptive Blockchain-based Supervision model for off-site modular housing production;X Li, L Wu, R Zhao, W Lu, F Xue ; Computers in Industry, 2021  Elsevier;;"… Two-layer Adaptive Blockchain-based Supervision model for off-site modular housing

production. Author links open overlay panelXiaoLi … 3. Literature review. 3.1. Blockchain

technology. Blockchain is supported by three core components …";Les 4 versions;;[PDF] frankxue.com;https://frankxue.com/pdf/li21tabs.pdf;"
1 
 

Two-layer Adaptive Blockchain-based Supervision model for off-site modular housing production 
Xiao Li1, Liupengfei Wu2, Rui Zhao3, Weisheng Lu4, and Fan Xue5* 

This is the peer-reviewed post-print version of the paper: 
Li, X., Wu, L., Zhao, R., Lu, W., & Xue, F. (2021). Two-layer adaptive blockchain-
based supervision model for off-site modular housing production. Computers in 
Industry, 128, 103437, in press. Doi: 10.1016/j.compind.2021.103437 

The final version of this paper is available at https://doi.org/10.1016/j.compind.2021.103437.  
The use of this file must follow the Creative Commons Attribution Non-Commercial No 
Derivatives License, as required by Elsevier’s policy. 

 

Abstract 

By manufacturing housing products off-site and assembling on-site, modular construction can 
significantly improve the housing supply efficiency, particularly for high-density cities. 
However, off-site modular housing production (OMHP) supervision is currently problematic. 
The production parties are reluctant to provide detailed private data; Even worse, the 5 

submitted operation records can be easily fabricated, tampered with, or hard to trace the 
responsibility. This study develops an innovative Two-layer Adaptive Blockchain-based 
Supervision (TABS) model for OMHP. The first layer includes the adaptive private 
sidechains of participants. The second layer is the main blockchain for communication and 
‘trading’ among all participants. Benefitted from the unique adaptive two-layer structure, 10 

TABS can avoid tampering with operation records by the main blockchain and drive the 
participants to publish their operation records promptly without privacy leaks. A system 
prototype was also developed to evaluate the performance of the TABS model. The results 
indicated that the TABS model could enhance privacy and reduce storage costs at an 
acceptable latency level. This study's findings can pave the avenue for a tamper-proof and 15 

privacy-preserving supervision mechanism in the architecture, engineering, and construction 
industry. 

Keywords: Two-layer adaptive blockchain; Off-site construction; Modular construction; 
Production and quality inspection 

                                                 
1 Postdoctoral Fellow, Department of Real Estate and Construction, The University of Hong Kong, Hong Kong 

SAR. Email: xl1991@hku.hk, Tel.: (852) 5537 0842,  ORCiD: 0000-0001-9702-4153;  
2 Ph.D. student, Department of Real Estate and Construction, The University of Hong Kong, Hong Kong SAR. 

Email: u3545425@connect.hku.hk, Tel.: (852) 6930 8019,  ORCiD: 0000-0002-3768-9142  
3 Research Assistant, Department of Real Estate and Construction, The University of Hong Kong, Hong Kong 

SAR. Email: ruizhao@hku.hk, Tel.: (852) 6998 6845,  ORCiD: 0000-0003-1993-3129  
4 Professor, Department of Real Estate and Construction, The University of Hong Kong, Hong Kong SAR. Email: 

wilsonlu@hku.hk, Tel.: (852) 3917 7981,  ORCiD: 0000-0003-4674-0357;  
5 Assistant Professor, Department of Real Estate and Construction, The University of Hong Kong, Hong Kong 

SAR. Email: xuef@hku.hk, Tel.: (852) 3917 4174, Fax: (852) 2559 9457,  ORCiD: 0000-0003-2217-3693  
*: Corresponding author 

https://doi.org/10.1016/j.compind.2021.103437
https://doi.org/10.1016/j.compind.2021.103437
http://creativecommons.org/licenses/by-nc-nd/4.0/
http://creativecommons.org/licenses/by-nc-nd/4.0/
https://www.elsevier.com/about/policies/hosting
mailto:xl1991@hku.hk
https://orcid.org/0000-0001-9702-4153
mailto:ruizhao@hku.hk
mailto:wilsonlu@hku.hk
http://orcid.org/0000-0003-4674-0357
mailto:xuef@hku.hk
http://orcid.org/0000-0003-2217-3693


2 
 

1. Introduction 20 

The construction industry will continue to be one of the main driving forces leading the 
economic recovery and social development after the coronavirus lockdown (Stefani and 
Coulton, 2020; Tapsfield, 2020). With contact-restrict in the pandemic, modular construction 
involving less labor is an innovative approach that employs freestanding volumetric modules 
manufactured off-site and then transported to a construction site for assembly (Gao et al., 25 

2020). As the most value-added process of modular construction, off-site modular housing 
production (OMHP) involves various materials, participants, and steps. 

However, there are several practical concerns with quality assurance in factories for OMHP. 
For example, there is usually a lack of real-time progress information and plan display in the 
production preparation stage (Li et al., 2019a; 2019b). When entering productions, the 30 

absence of systematic records of operations (e.g., structure works, electrical and mechanic 
works, testing, and commissions) aroused construction stakeholders’ attention (Xu et al., 
2020). Manual recording (e.g., progress and inspection records) often leads to input errors, 
file loss, and even data manipulation during the production inspection (Zhong et al., 2020). 
All the issues mentioned above in the OMHP significantly hinder supervision. These issues 35 

can be further deteriorated in Hong Kong, mainly due to the coronavirus pandemic. As the 
high construction costs, aging problems, and labor shortages, the construction industry in 
Hong Kong outsources OMHP to the factories in nearby Guangdong Province, Mainland 
China. The cross-border supervision of OMHP has become a conundrum due to the travel 
restrictions during the coronavirus pandemic. Thus, there is an urgent need for technologies 40 

to build trust and promise OMHP information’s authenticity. 

Blockchain, emerging from the technology sphere recently, promises to provide the desired 
strategy to build trust in the industry. A blockchain refers to a cryptographically immutable 
distributed database within a decentralized consensus mechanism (Risius and Spohrer 2017). 
From the Institution of Civil Engineers, Penzes et al. (2018) reported blockchain technology 45 

promises, such as augmented transparency, boosted traceability, enhanced immutability, 
increased decentralization, improved privacy, and extended smartness. Many scholars are 
actively studying blockchain applications in construction: integration of Building Information 
Modeling (BIM) and blockchain (Xue and Lu, 2020), construction business processes (Yang 
et al., 2020), transaction automation with smart contracts (Hamledari and Fisher, 2020), 50 

payment in construction projects (Das et al., 2020), and immutable records of transactions, 
assets, and ownership (Zhong et al., 2020).  

A growing number of blockchain studies on the supply chain and information management 
for OMHP has also gained attention recently. These studies focused on supply chain 
traceability and quality management. For example, Wang et al. (2020) proposed a 55 

blockchain-based framework for improving supply chain traceability and information 
sharing. Similarly, Zhang et al. (2020) developed a quality traceability system for building 
components based on blockchain. Zhong et al. (2020) and Sheng et al. (2020) proposed 



3 
 

blockchain prototypes for construction quality information management. Nevertheless, the 
construction companies naturally wish to keep their business data private and, therefore, 60 

reluctant to make data accessible to all participants. Moreover, migrating historical data of all 
processes stored in traditional systems to the chain will cause high costs and require larger 
storage space. Thus, previous studies have not developed a sound solution to supervise each 
operation in OMHP while protecting related enterprises’ data privacy. 

This paper aims to present a novel blockchain-based supervision model to enhance the 65 

supervision of OMHP. This research has three specific objectives:  

1) to review and comb the current business process of OMHP;  
2) to develop a two-layer adaptive blockchain-based supervision (TABS) model for off-

site modular housing production; and  
3) to analyze the performance of the TABS model by developing a prototype system.  70 

The rest of this paper is organized as follows. Section 2 reviews and combs the current 
business process of OMHP. Section 3 is a literature review of blockchain technology. Section 
4 presents the details of TABS. Section 5 analyzes the performance of the TABS model. 
Section 6 offers our discussion, and Section 7 concludes this research. 

2. Problem Statement 75 

The current practice of OMHP in factories generally has three sub-processes, i.e., production 
preparation, production, and inspection. The scope of the OMHP process has been identified 
as follows:  

1) the entry criteria are that the project manager signs the contract to confirm the 
production;  80 

2) the input is the master plan and the design drawings;  
3) the exit criteria are that the project manager confirms the delivery order; and  
4) the output is the quality assured modular housing products.  

As shown in Fig. 1(a), the contractor coordinates with subcontractors and manufacturers to 
propose the production plan after placing an order. The manufacturer’s design department 85 

develops detailed production shop drawings after the confirmation of design drawings. Once 
the production shop drawings are ready, they should be approved by the contractor and 
owner. Upon approval, the manufacturer can make an overall production plan. The material 
list will be made based on the production execution plan. The order of 2D panels, rebar, and 
other material will be sent to the supplier by the manufacturer’s procurement department. 90 

These materials will be inspected and only be used if they pass the inspections and tests. For 
example, in the rebar inspection, results with the color are marked on the rebar. Green means 
the rebar passes the inspection, yellow means unchecked, and red means disqualification. 
After inspection, materials will be transported to the factory. The production department will 
organize the production if required material ready. 95 



4 
 

 

 
Figure 1. The business process of off-site modular housing production (Source: Authors). (a) 

Production preparation; (b) MiC standard room and bathroom production and inspection 

Fig. 1(b) shows that the standard modular room is produced by following a sequential 100 

procedure from the structure, door/window, wall, print, electrical & mechanic service to test 
& commission. Numerous inspection and test methods are involved for quality control and 
quality assurance in each hold point and witness point. For example, the check of hot-dip 
galvanized thickness, cladding sub-frame alignment, dimension, and water test for chassis 
enclosure are conducted in 3D assembly welding of structure production. Several processes 105 

are adjusted for the toilet module, such as the wet trades (e.g., bathroom wall and floor tiles 
installation, waterproof layer, and flood test) are involved. 

Blockchain has several advantages that may address the issues in the current business process 
of OMPH for supervising the information of material, production, and inspection: 

• Transparency: Current records may not be available to all stakeholders. Blockchain 110 

can require confirmation from all parties. 



5 
 

• Traceability: Current records may not be tracked in the whole OMHP process. 
Blockchain can provide the status of modular housing products with a timestamp. 

• Immutability: Current records can be modified without rigorous supervision. 
Blockchain can offer a tamper-proof solution. 115 

• Decentralization: Current records are managed in a centralized manner. Blockchain 
can prevent them entirely controlled by one party. 

• Privacy-preserve: Current records may involve privacy issues. Blockchain can 
encrypt them by using hashing algorithms. 

• Smartness: smart contracts facilitate the automatic execution process in transparency, 120 

traceability, immutability, decentralization, and privacy. 

3. Literature Review 
3.1 Blockchain Technology 

Blockchain is supported by three core components: cryptography, consensus mechanisms, 
and distributed storage (Crosby et al., 2018). Hash algorithms and Merkle trees are typical in 125 

cryptography, ensuring that the data cannot be tampered with (Kosba et al., 2016). In the 
blockchain, transaction data can be bundled into blocks, as shown in Fig. 2, and each block is 
a package data structure containing headers and transaction data (Nakamoto, 2008; Gupta, 
2017). The header contains metadata, including index, previous block hash, current block 
hash, nonce, timestamp, and Merkle root. Blocks are connected in sequence, starting with the 130 

genesis block. Hashing sequentially interlinked blocks implies that the verified transaction 
data is adopted as input to a hash algorithm that converts the data into a fixed-length string. 
As each data in the block is hashed, then united and hashed again, this process creates the 
Merkle tree and the final root hash. A hash value of a block can be regarded as a unique 
digest of the current block data. The previous block hash in the current block is used to 135 

enable the blocks to build a chain. Thus, any small alteration to data, hash values in the entire 
chain need to be altered. 

 



6 
 

Figure 2. An example of a blockchain (Adapted from Nakamoto (2008)) 

Consensus mechanisms are protocols for endorsing the order and correctness of data (Cachin 140 

and Vukolić, 2017). Only when a consensus is reached can transaction data be added to the 
blockchain as a new block. There are many consensus algorithms, among which the five most 
common are: Proof of Authority (PoA), Proof of Work (PoW), Proof of Stake (PoS), 
Delegated Proof of Stake (DPoS), and Practical Byzantine Fault Tolerance (PBFT) (Xiao et 
al., 2020).  145 

The distributed data storage of blockchain, principally constituted by ledgers, is realized 
through a decentralized network (Perera et al., 2020). The word “distributed” means that 
ledgers are scattered in many places in a shared manner to log transaction data. Nodes are 
network participants who hold copies of the ledger and/or execute smart contracts to query 
from or submit transactions to ledgers. Together, these components promise that the status of 150 

tangible assets or intangible events to be endorsed, stored, and shared with the smallest 
chance of tampering. Simply put, blockchain stores immutable, verifiable, and transparent 
information. 

Smart contracts are digital contracts that can self-execute when preset conditions are met 
(Luu et al., 2016). Smart contract scripts can indicate a blockchain’s maturity level at 2.0 or 155 

above (Angelis and da Silva, 2019). Once the smart contract is successfully installed in the 
blockchain network, no one can change the execution rules. Smart contracts can continuously 
monitor data changes on the blockchain or external data sources and automatically respond 
when conditions are met. Therefore, smart contracts can help disintermediation (e.g., banks), 
thereby reducing related costs and shifting normative trust (e.g., trust in people) to naturalistic 160 

trust (e.g., trust in coding). Fig. 3 shows the structure of smart contracts. A smart contract 
contains two key components: preset conditions and actions that need to be carried out when 
the preset conditions are met. Smart contracts can digitize and automate business processes, 
allowing the development of blockchain 3.0 decentralized applications (DApps) (Christidis 
and Devetsikiotis, 2016; Angelis and da Silva, 2019). 165 

 



7 
 

 
Figure 3. Schematic of the smart contract (Adapted from Bragagnolo et al. (2014)) 

3.2 Blockchains in the Construction Industry 

Although many industries have developed different blockchain prototypes and applications, 170 

the construction industry is only in the initial stage of blockchain implementation. The 
loosely-coupled and project-based structures in the construction industry (Dubois and Gadde, 
2002) require numerous stakeholders to communicate over time with various incentives. 
These structures' nature brings coordination difficulties such as lack of trust, poor information 
exchange, and fragmented system records (Hunhevicz and Hall, 2020). Theoretically, the 175 

promises of secured transactions that blockchain can give are in line with these coordination 
difficulties. Even so, there are few implementations of blockchain in construction. Instead, 
most literature to date provides a sketch of the potential use cases for blockchain in 
construction. For instance, early literature views the prospect of blockchain as a 
supplementary technology to BIM and Internet of Thing (IoT)  (Mathews et al., 2017) 180 

because BIM and IoT are again limited by problems of trust and liability encountered 
throughout the industry. Therefore, Ye et al. (2018) suggested using blockchain to store data 
generated by IoT in a transparent and safe environment and BIM as a tool for digital 
processing construction project data. DeLa PeĂąa and Papadonikolaki (2019) proposed that 
using the blockchain as an immutable ledger, the combination of blockchain and IoT can 185 

build trust among construction companies. 

Starting in 2017, many researchers and consulting firms have identified potential use case 
scenarios to employ blockchain in construction. Hunhevicz and Hall (2020) noted that the 
construction industry’s potential blockchain use cases mainly include seven categories. 
Blockchain can help notarize and synchronize documents in the construction administration 190 



8 
 

process (Wang et al., 2017). Combined with smart contracts, blockchain can realize 
transaction automation for payment (Hamledari and Fisher, 2020), business process and 
information integration (Yang et al., 2020), and compliance checking (Nawari and 
Ravindran, 2019). Also, blockchain can be used as immutable track-records, for example, to 
track BIM changes (Xue and Lu, 2020), quality of prefabricated construction (Li et al., 2021), 195 

semantic city objects (Xue et al., 2020; 2021), track supply chain, project progress, and 
worked hours (Wang et al., 2020). Similarly, blockchain can record assets and ownership 
(Raslan et al., 2020). Das et al. (2020) reported the use of blockchain cryptocurrency for 
payment and incentive schemes. In summary, blockchain does bring exciting opportunities to 
the construction industry. However, the use cases of using blockchain to supervise OMHP are 200 

largely unexplored. 

3.3 Blockchains for Production Supervision 

In literature, a few studies using blockchain technology have been observed for production 
supervision. Peng et al. (2020) showed that vaccine production records could be protected 
from tampering through an effective double-level blockchain method while maintaining 205 

enterprises’ privacy. Yong et al. (2020) demonstrated a “vaccine blockchain”, organizing 
production inspection records into a hash table structure with timestamps to achieve 
traceability, security, and trust. In the food industry, Tao et al. (2019) proposed a food safety 
supervision system based on a hierarchical multi-domain blockchain network with a 
secondary-check mechanism. Liang et al. (2020) designed a blockchain system architecture 210 

to supervise the production safety of special equipment (e.g., pressure vessels and elevators) 
and record the corresponding producers’ responsibilities. Blockchain-based supervision also 
covers the production quality management of textiles (ElMessiry and ElMessiry, 2018), 
agricultural products (Wang, 2019), and energy (Ferrag and Maglaras, 2019).  

Many solutions have been provided to strengthen the supervision of the OMHP. Relying on 215 

quality assurance schemes and regulations, Hong Kong’s Buildings Department requires 
authorized personnel and registered structural engineers to assign their respective quality 
control teams to supervise OMHP in assembly factories (BD, 2017). Technology adoption is 
also an essential strategic research field for OMHP supervision. BIM, as a digital 
representation of a facility’s physical and functional characteristics and a shared knowledge 220 

resource for information (Li et al., 2017), is commonly utilized for production planning and 
management (Lu et al., 2020; Li et al., 2020). Progress and quality assurance of OMHP are 
also focused on the IoT, a networked interconnection of everyday objects, often equipped 
with ubiquitous intelligence via embedded systems (Li et al., 2018). Through integration with 
the BIM and enterprise resource planning system, IoT can enhance visualization and manage 225 

production processes, thereby enabling communication and collaboration between all parties 
(Razkenari et al., 2020). Nevertheless, merely relying on BIM, IoT, or traditional information 
management systems is not enough to truly achieve trust. These technologies are susceptible 
to a single point of failure and cybersecurity issues, which blur the responsibility level 



9 
 

between different participants (Zhai et al., 2019). For example, the shared cloud BIM model 230 

and its data can be tampered with without tracing the responsibility of changes, and IoT 
sensors (e.g., RFID, GPS) may suddenly run out of power or report noises to reduce the 
quality of data.  

In construction, especially OMHP, only minimal studies have focused on the uses of 
blockchains to supervise production. To improve the transparency of information between 235 

steel production companies, logistics, and consumers, and eliminate the security issues of 
existing IoT platforms, Cao et al. (2019) claimed a quality traceability system based on 
blockchain. Zhang et al. (2020) proposed a blockchain-based quality traceability system to 
ensure the components’ quality in production, transportation, and construction. It is found 
that more research has focused on the use of blockchain to improve the traceability of the 240 

construction supply chain (e.g., Wang et al., 2020; Zhang et al., 2020) and the overall 
management of information (e.g., Sheng et al., 2020; Zhong et al., 2020).  

Nevertheless, once OMHP has flaws in the production process, it is almost impossible to 
prevent inferior housing products from reaching consumers. Besides, due to high technical, 
learning, and training costs, it is not feasible to completely replace the existing information 245 

system with a blockchain. Privacy is another major issue when implementing blockchain in 
production, as producers and related enterprises wish to keep design data and plan internally. 
In short, the existing blockchain studies have not given in-depth investigations on OMHP 
supervision, nor have they provided sufficient consideration for the privacy protection of 
production data and effective data storage. With the harness of these capacities in blockchain, 250 

the supervision process of OMPH can be enhanced. Thus, this study proposes a model to 
explain how to realize the off-site production supervision for quality assurance, progress, and 
cost efficiency. 

4. The Two-layer Adaptive Blockchain-based Supervision Model for OMHP 

This section presents a novel Two-layer Adaptive Blockchain-based Supervision (TABS) 255 

model for resolving the supervision and privacy problems encountered in OMHP. As shown 
in Fig. 4, four main participants, i.e., supplier, manufacturer, contractor, and owner, are 
involved in TABS for the OMHP business process. Suppliers first deliver the 2D panel, rebar, 
and other material to the OMHP factory by the manufacturer’s orders. Next, the manufacturer 
will schedule the production and execute it according to the due time. The contractor will also 260 

organize the inspection and test activities for each production process in every hold and 
witness point. The project owner can supervise and monitor the whole process via the timely 
information in the OMHP processes, including material information, production information, 
inspection information, and supervision information. Material information includes data for 
material ID, production, and inspection results. Production information records the detailed 265 

production processes of modular products. Inspection information contains detailed 
inspection and test results of each hold and witness point. Supervision information comprises 
primary information of material, production, and inspection for each modular product. 



10 
 

 
Figure 4. Two-layer adaptive blockchain-based supervision (TABS) model for OMHP 270 

(Source: Authors) 

In the actual supervision process, the responsibilities of quality defects, production delays, 
and cost overrun are not easily determined. TABS model allows each participant to access the 
status and records of material supply, production, and inspection with preserving the data 
privacy of material supplier, manufacturer, and contractor. Four participants are involved in 275 

the main blockchain. Each participant receives a copy of the main blockchain, facilitating 
them to supervise each transaction. In the main blockchain, each transaction indicates an 
operation, such as delivery 2D panel, structure production, concrete test, window/door 
production, and dimension check. An operation can be verified when all participants agree on 
its authenticity by reaching a consensus. The operations are stored in the supplier, 280 



11 
 

manufacturer, and contractor’s sidechains and retrieved via the main blockchain's smart 
contracts. The self-execution functions are embedded in smart contracts that can be triggered 
by the owner. The details of the TABS model are illustrated in the following sections. 

4.1 Two-Layer Adaptive Blockchain Structure 

The key to OMHP supervision is monitoring the authentic OMHP operations in the entire 285 

process, and the blockchain structure can directly affect supervision performance. However, 
in the traditional blockchain structure, there are two limitations to OMHP supervision. 
Firstly, the OMHP participants wish to keep their business data private and may be reluctant 
to make data accessible to all participants. In addition, there is a conflict between full backup 
and storage capacity in traditional blockchain for massive operation oriented OMHP. Thus, 290 

the TABS model adopts a two-layer adaptive blockchain structure, including mainchain and 
sidechain (See Fig. 4). OMHP process has numerous operations, which may vary in different 
modular products, such as standard rooms and toilets. Each operation can be treated as a 
transaction. Each transaction holds the detailed data of the operation. Thus, a particular 
modular product's specific operation can be matched to a specific transaction. The design of 295 

mapping operation with transaction ensures the two-layer adaptive blockchain structure can 
handle various modular products produced by different operations. 

Private operation transactions can be stored in each participant’s sidechain, and other 
participants in the main blockchain can not access it. The private transaction structure can be 
shown in Fig. 5. Each transaction includes a timestamp (transaction time), the signature of the 300 

person in charge, the hash, the previous hash (previous operation), and the data. The data are 
formed as a hash table, a dictionary-like data structure with unique keys and values. These 
hash tables’ keys present the operation categories, including “material,” “production,” and 
“inspection.” These hash tables’ values show in the form of an object containing the content 
of data, such as inspection operation, inspection time. With the data frame structure, the 305 

operation transactions can be format-free when uploaded into the sidechain. The sidechain 
layer consists of the material supply, module production, and inspection. These three 
sidechains are maintained by the supplier, manufacturer, and contractor, which can not only 
provide authentic operations and but also ensure their data privacy by using hashing data.  

 310 

Figure 5. Data frame structure in the sidechain (Source: Authors) 

Each block in the main blockchain comprises two parts: header and transactions. Block 
header mainly consists of the index (block number in the chain), timestamp, the signature of 
the supplier, manufacturer, contractor, owner, the hash value of the current the previous 
block. There are three types of transactions retrieved from the sidechains of the supplier, 315 

manufacturer, and contractor, as shown in Fig. 6. The project owner can access OMHP 
operation records from the main blockchain, and smart contracts are deployed into the main 



12 
 

blockchain, subscribe to the operation records from the sidechain, which can publish the 
operation records at a specific time period for modular product supervision. Compared with 
the traditional blockchain structure, the two-layer adaptive blockchain structure has 320 

significant advantages in cross-participant data privacy and flatten supervision. 

The adaptability of this blockchain structure can be reflected in two perspectives. First, the 
sidechains layer can be adaptive to full life cycle stakeholders of modular housing products, 
such as designers, logistics companies, and property management companies, to record 
information on design, transportation, and facility management. Second, the main blockchain 325 

layer can be extended to government and industry regulators and even can go public. 

 
Figure 6. Block data structure in the main blockchain (Source: Authors) 

4.2 Supervision Processes in Two-Layer Adaptive Blockchain Structure 

Once disputes, e.g., quality defects, delays, or cost overrun, occur, the TABS model can help 330 

trace whether the qualified material is manufactured in rigorous production processes with 
timely progress and consistent inspection. Similar functions can help conduct random checks 
of material supply, production, and inspection. The TABS model employs a consortium 



13 
 

blockchain architecture for the main blockchain to enable OMHP supervision in a publish-
subscribe manner. The supervision process includes registration, publish-subscribe, ordering, 335 

and consensus. Fig. 7 demonstrates the detailed supervision processes in the TABS. 

 
Figure 7. Sequence diagram of interactions in TABS (Source: Authors) 

4.2.1 Registration 

The participants’ identities should be verified through their registration request to the owner. 340 

The owner holds the certificate authority and then issue certificates for each participant to 
join the main blockchain. The registration process offers both authority and privacy to 
participants, and a participant without registration cannot participate in the sequent processes 
of publish-subscribe and consensus. After registration, the participants can get an enrollment 
certificate (e.g., ID) and a transaction certificate for signatures. 345 

4.2.2 Publish-subscribe 

The publish-subscribe mechanism is adopted to generate the transaction flow proactively. For 
example, the owner can subscribe to the supplier’s material record when the supplier starts to 
deliver the material to the manufacturer. And the supplier records and hashes each operation 
in its sidechain. The supplier then publishes the transaction hash to the owner, protecting the 350 

supplier’s data privacy. Following the same mechanism, the owner can establish this publish-
subscribe interaction patterns with the manufacturer and contractor in the off-site production 
stage.  



14 
 

4.2.3 Ordering Service 

The owner serves as the ordering node (leader), receives transactions from different 355 

participants, and conducts the ordering service to form an ordered blockchain. All 
transactions from participants during a specific period are ordered. The ordering service can 
order transactions in sequence and packages them into new blocks. However, the ordering 
service cannot access the data in these transactions and has no permission to update the 
unverified block to each participant. It can only send the ordered blocks consecutively to the 360 

participants for verification. Once participants received the blocks ordered by the owner, they 
can evaluate whether these blocks are in the right sequence by checking the current block’s 
hash value and the previous block’s hash value.  

4.2.4 Consensus Mechanism 

All participants in the main blockchain can verify the authenticity of transactions in their 365 

received blocks. Each participant can determine whether it is valid or not by signing in the 
block and holding the copy of the dat";"""date"",""2021-03-07T07:08:55Z""
""pdf:PDFVersion"",""1.4""
""xmp:CreatorTool"",""Acrobat PDFMaker 11 for Word""
""pdf:docinfo:title"",""""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""language"",""en""
""dc:format"",""application/pdf; version=1.4""
""pdf:docinfo:creator_tool"",""Acrobat PDFMaker 11 for Word""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""xmp:CreateDate"",""2021-03-07T15:08:48Z""
""modified"",""2021-03-07T07:08:55Z""
""pdf:hasMarkedContent"",""true""
""xmp:ModifyDate"",""2021-03-07T15:08:55Z""
""pdf:docinfo:creator"",""""
""meta:author"",""""
""meta:creation-date"",""2021-03-07T07:08:48Z""
""created"",""2021-03-07T07:08:48Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2021-03-07T07:08:48Z""
""resourceName"",""li21tabs.pdf""
""Author"",""""
""producer"",""Adobe PDF Library 11.0""
""pdf:docinfo:producer"",""Adobe PDF Library 11.0""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2021-03-07T07:08:48Z""
""Last-Modified"",""2021-03-07T07:08:55Z""
""dcterms:modified"",""2021-03-07T07:08:55Z""
""title"",""""
""xmpMM:DocumentID"",""uuid:6c26cca2-6b0d-4555-af00-2171e4090c76""
""Last-Save-Date"",""2021-03-07T07:08:55Z""
""pdf:docinfo:modified"",""2021-03-07T07:08:55Z""
""meta:save-date"",""2021-03-07T07:08:55Z""
""Content-Length"",""2405704""
""Content-Type"",""application/pdf""
""xmp:MetadataDate"",""2021-03-07T15:08:55Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:language"",""EN-US""
""pdf:producer"",""Adobe PDF Library 11.0""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""30""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""3173"",""3348"",""2895"",""1193"",""1978"",""2280"",""1974"",""3397"",""3379"",""934"",""3207"",""1316"",""1507"",""3201"",""3173"",""135"",""1974"",""267"",""2293"",""2002"",""2849"",""2730"",""2411"",""2460"",""2304"",""2409"",""2288"",""504"",""1662"",""2724""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2021-03-07T07:08:48Z""
";https://scholar.google.ch/scholar?start=70&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2021
1619099138-483;https://scholar.google.ch/scholar?as_ylo=2021&q=oracles+blockchain&hl=fr&as_sdt=0,5;[PDF][PDF] Process Digitalization using Blockchain: EU Parliament Elections Case Study;M Skotnica, M Apar?cio, R Pergl, S Guerreiro ;2021 scitepress.org;;"… is still under development, and it will be enhanced with the support of decentralized identity and

data oracles … Address and Address- Payable types are added to support the storage of a

blockchain actor's addresses and consequent token or cryptocurrency transfers …";;;[PDF] scitepress.org;https://www.scitepress.org/Papers/2021/102290/102290.pdf;"
Process Digitalization using Blockchain: EU Parliament Elections
Case Study

Marek Skotnica1 a, Marta AparĹ́cio2 b, Robert Pergl1 c and Sérgio Guerreiro2 d

1Faculty of Information Technology, Czech Technical University, Prague, Czech Republic
2Department of Computer Science, Instituto Superior Técnico, Lisbon, Portugal

Keywords: Blockchain, Smart Contracts, Digitalization, Elections.

Abstract: Blockchain aims to be a disruptive technology in many aspects of our lives. It attempts to disrupt the aspect of
our lives that were hard to digitize, such as democratic elections or were digitized in a centralized way, such as
the financial system or social media. Despite the initial success of blockchain platforms, many hacks, design
errors, and a lack of standards was encountered. This paper aims to provide a methodical approach to the
design of the blockchain-based systems and help to eliminate these issues. The approach is then demonstrated
in an EU parliament elections case study.

1 INTRODUCTION

The Blockchain smart contracts promise a way to dig-
itize processes where value and trust are involved.
This applies to processes in many industries, such as
supply chain management, finance, government pro-
cess automation, voting, and many others. However,
there are many challenges to overcome before es-
sential processes can be deployed to the Blockchain.
For example, after deploying a smart contract to the
Blockchain, the smart contract cannot be updated, and
possible errors cannot be fixed. The errors may result
in significant monetary or security damage. There-
fore, a methodical approach to design, validate, im-
plement, and simulate is needed to address the prob-
lem.

This paper describes a method to digitize pro-
cesses using Blockchain technology based on the
Business Process Management (BPM) method and
the Model-Driven Engineering (MDE) approach. It is
expected that by applying this method, the program-
ming errors will be reduced.

To demonstrate the functionality of the proposed
approach, a EU parliament elections case study was
created. A model of a EU parliament elections vot-
ing process running in Blockchain was modeled, a

a https://orcid.org/0000-0002-8811-3389
b https://orcid.org/0000-0002-1857-0381
c https://orcid.org/0000-0003-2980-4400
d https://orcid.org/0000-0002-8627-3338

Blockchain smart contract was generated, and finally,
a simulation of the functionality was performed.

The paper is organized as follows: In Section 2,
the research method and the research question are for-
mulated. A related research is covered in Section 3.
In Section 4, the underlying scientific foundations are
briefly discussed. An approach to digitize processes
using the Blockchain technology is introduced in Sec-
tion 5. The proposed approach is demonstrated on a
EU parliament elections case study in Section 6. In
Section 7, the current results are summarized, and fur-
ther research is proposed.

2 RESEARCH QUESTION AND
METODOLOGY

The research question is: How to digitize processes
using blockchain smart contracts in a methodi-
cal way and eliminate programming errors while
avoiding a dependency on a particular blockchain
implementation?

The design science research approach is applied
in this paper as described in (Hevner et al., 2004;
Hevner, 2007), which is shown in Figure 1. In the
first cycle, a relevance of the problem is discussed in
Section 1. The environment in which this research is
applied is model driven engineering. The challenge
is the application of the MDE to the blockchain tech-
nology. The environment in which this research is

Skotnica, M., AparĂ­cio, M., Pergl, R. and Guerreiro, S.
Process Digitalization using Blockchain: EU Parliament Elections Case Study.
DOI: 10.5220/0010229000650075
In Proceedings of the 9th International Conference on Model-Driven Engineering and Software Development (MODELSWARD 2021), pages 65-75
ISBN: 978-989-758-487-9
Copyright c© 2021 by SCITEPRESS – Science and Technology Publications, Lda. All rights reserved

65



Figure 1: Design Science Research Cycles (Hevner, 2007).

applied is electronic voting.
The second cycle is described in Section 6 and

Section 7. A complex case from the domain is mod-
elled and simulated as a blockchain smart contract.

And, finally, the relevant grounding into the ex-
isting knowledge base is in Section 5, Section 6.
The Section 3 provides an overview of existing ap-
proaches, and the Section 5 shows how to apply the
MDE approach to the blockchain technology.

3 RELATED RESEARCH

There have been attempts at raising the level of ab-
straction from Code-Centric to Model-Centric Smart
Contracts development. The different approaches
tried so far can be divided into three: the Agent-
Based Approach, the State Machine Approach, and
the Process-Based Approach (AparĹ́cio. et al., 2020).
For this research and going further into state of the art
already mentioned in (Skotnica and Pergl, 2020), di-
rectly related to this paper, the main focus will be the
Process-Based Approach.

In (Weber et al., 2016) was proposed a tool
to support inter-organizational processes through
Blockchain technology. To ensure that the joint pro-
cess is correctly executed, the control flow and busi-
ness logic of inter-organizational business processes
are compiled from the processes models into Smart
Contracts. Weber et al. developed a technique to
integrate Blockchain into the choreography of pro-
cesses to maintain trust, employing triggers and web
services. By storing the status of process execution
across all involved participants, as well as to coordi-
nate the collaborative business process execution in
the Blockchain. The validation was made against the
ability to distinguish between conforming and non-
conforming traces. (GarcĹ́a-Bañuelos et al., 2017) pre-
sented an optimization in regards to the already pre-
sented paper (Weber et al., 2016). To compile BPMN
models into a Smart Contract in Solidity Language,
the BPMN model is first translated into a reduced
Petri Net. Only after this first step, the reduced Petri
is compiled into a Solidity Smart Contract. Com-

pared to (Weber et al., 2016), (GarcĹ́a-Bañuelos et al.,
2017) managed to decrease the amount of paid re-
sources and achieve higher throughput. Caterpillar,
first presented in (Pintado, 2017) and further dis-
cussed in (López-Pintado et al., 2018), is an open-
source Business Process Management System that
runs on top of the Ethereum Blockchain. Like any
BPMS, Caterpillar supports the creation of instances
of a process model (captured in BPMN) and allows
users to track the state of process instances and to ex-
ecute tasks thereof. The specificity of Caterpillar is
that the state of each process instance is maintained on
the Ethereum Blockchain, and the workflow routing is
performed by Smart Contracts generated by a BPMN-
to-Solidity compiler. Given a BPMN model (in stan-
dard XML format), it generates a Smart Contract (in
Solidity), which encapsulates the workflow routing
logic of the process model. Specifically, the Smart
Contract contains variables to encode the state of a
process instance, and scripts to update this state when-
ever a task completes or an event occurs. (Tran et al.,
2018) presented a tool that automatically creates a
well-tested Smart Contract code from specifications
that are encoded in the business process and data reg-
istry models based on the implemented model trans-
formations. The BPMN translator can automatically
generate Smart Contracts in Solidity from BPMN
models while the registry generator creates Solidity
Smart Contract based on the registry models. The
BPMN translator takes an existing BPMN business
process model as input and outputs a Smart Contract.
This output includes the information to call registry
functions and to instantiate and execute the process
model. The registry generator takes data structure in-
formation and registry type as fields, and basic and
advanced operations as methods, from which it gen-
erates the registry Smart Contract. This work builds
upon already seen works, such as (GarcĹ́a-Bañuelos
et al., 2017; Weber et al., 2016), for the BPMN trans-
lation algorithms.

Going into further detail over the case study do-
main, highly used as a case study in research (Horcas
et al., 2014), voting is a fundamental part of demo-
cratic systems. The current voting system raises con-
cerns for those who depend on it to elect their rep-
resentative, particularly concerning integrity; secu-
rity; transparency; and accessibility, which translates
into low turnout. E-voting by itself doesn’t address
all these concerns due to requiring supervision by a
central authority. However, combining the E-voting
solution with the Blockchain technology could be a
solution, since the latter is decentralized, and dis-
tributed (Curran, 2018).

In (Dagher et al., 2018) was proposed a

MODELSWARD 2021 - 9th International Conference on Model-Driven Engineering and Software Development

66



blockchain-based voting system, named BroncoVote,
that preserves voter privacy and increases accessibil-
ity, while keeping the voting system transparent, se-
cure, and cost-effective. BroncoVote used the smart
contracts in Ethereum blockchain to keep a record
of every user in the system as well as all the bal-
lots and the information regarding them. The smart
contracts were also used to achieve access control.
Besides, integrating Paillier homomorphic encryption
into the system to preserve voter privacy. By resorting
to Ethereum’s blockchain and smart contracts, they
enabled voters administration and auditable voting
records. However, it is important to keep in mind that,
in Ethereum any computation requested has to be paid
according to a preset deterministic unit called gas,
which has a variable real-world cost. Thus reducing
the computation performed on the blockchain is im-
perative to reduce the cost of a service running off the
blockchain (Azzopardi et al., 2020). As in (Dagher
et al., 2018), (Khoury et al., 2018) also suggests the
usage of blockchain technology to solve trust issues.
It suggests a new business model for voting service
providers, where the voting service provider enables
the voting event organizers to deploy an event voting
smart contract. The event management server deploys
in the Ethereum network the voting contracts config-
ured according to the voting event customer. (Zhang
et al., 2019) presents an Ethereum based electronic
voting protocol, Ques-Chain, that may surpass the
voting domain to other fields with similar needs. This
protocol responds to problems of three entities, for
the e-voting systems tackles the threat of malicious
manipulation by hackers, for the service providers
helps to prevent and eliminate scams, given the high
costs to perform data cleaning, at last, for the voters
tackles the doubts that may arise about the integrity
of the voting procedure and anonymity failure. The
protocol presented can be divided roughly into four
stages: Setup Stage, where the organizer initialize
the e-voting; Sign Stage, where the voter will get a
signed-blinded-ballot from the organizer; Vote Stage,
where the voters vote; Count Stage, where the voters
will count legal ballots and publish the results. There
are some similarities between the last work mentioned
and (Al-Rawy and Elçi, 2018). However, the latter
divides the voting process into six phases. Both re-
sort to blockchain technology and public-private key
systems. At last, in (Bellini et al., 2018), a process-
centric blockchain-based architecture, called Hyper-
Vote, is discussed. The advantage of HyperVote over
the other papers here presented is that the first fol-
lows the business trend of cloud computing, virtually
turning it into an online service (XaaS). Meaning in a
more practical manner that HyperVote is able to sup-

port dynamic selection, deployment, and execution of
an e-voting process whose requirements are tailored
to the user needs. It is a pay-per-use configurable ap-
proach bringing on costs during the limited timeframe
of an election. This allows to optimize the allocation
of resources as the same infrastructure can serve dif-
ferent customers in different time frames. The Hy-
perVote is an XML based data structure containing
all the information required by the execution environ-
ment to deploy, execute, account, and monitor the ser-
vice. The HyperVote binds a Workflow Model with
the concrete Atomic Services (chaincode) and Hyper-
ledger Network structure and Cloud Infrastructures
that will be invoked and selected by the workflow, re-
spectively, when executed.

4 METHODOLOGIES USED

4.1 BPM

A process is a collection of events, activities, and de-
cisions that collectively lead to an outcome that brings
value to an organization’s customers. Understand-
ing and managing these processes to ensure that they
consistently produce value is critical for the effective-
ness and competitiveness of an organization. Busi-
ness Process Management is a body of principles,
methods, and tools to discover, analyze, redesign, im-
plement, and monitor business processes. Process
models and performance measures are foundational
pillars for managing processes. Since these pillars
help to achieve business goals efficiently and effec-
tively while complying with boundary requirements
for governance, risk, and compliance.

There are many languages for modeling business
processes diagrammatically, perhaps one of the old-
est are flowcharts. Nowadays, there is a widely-used
standard for process modeling, namely the Business
Process Model and Notation (BPMN). BPMN is an
industry-standard for workflow procedures, supported
by the Object Management Group (OMG).

4.2 MDE

One of the promising methods that can facilitate
the development of Smart Contracts is Model-Driven
Engineering. Through Model-Driven Engineering,
executable code can be generated for Smart Con-
tracts from a set of models that specify the pro-
cesses to be supported. For instance, (Horcas et al.,
2014) and (Mavridou and Laszka, 2018) are tool-
supported methods that allow the generation of So-
lidity (Ethereum Foundation, 2020) Smart Contracts

Process Digitalization using Blockchain: EU Parliament Elections Case Study

67



from BPMN diagrams and finite state machines, re-
spectively.

Using Model-Driven Engineering requires a set
of models to be used as input for code generation.
In particular, rather than focusing on algorithms and
the elaboration of code, it focuses on the creation of
models as representations of the software to be built.
These models are then used to be transformed into
other models or code. Key aspects of this transfor-
mational approach are that it speeds up the creation
of software, that it enhances software quality, and
that it facilitates the portability and interoperability
of software. In ”Towards a shared ledger business
collaboration language based on data-aware pro-
cesses” (Hull et al., 2016) called for the development
of a shared ledger business collaboration language,
which should be a language that business people can
understand and use in cross-organizational business
processes supported by blockchain technology.

4.3 Blockchain

(Nakamoto, 2009) described the Blockchain as an ar-
chitecture that enables participants to perform elec-
tronic transactions without relying on trust. This
makes it possible that each block contains some data,
the hash of that block, and the hash of the previous
block. The data stored in a block corresponds to mul-
tiple transactions, and each transaction has an identi-
fication for the sender, receiver, and asset. The block
also has a hash, which identifies its content and is
always unique. If something is changed within the
block, it will cause the hash value to change. This is
why hashes are useful for detecting changes in blocks.
The hash value of the previous block effectively cre-
ates a Blockchain, and it is this technology that makes
the Blockchain so secure. However, the hashing tech-
nology is far from enough, as the high computing
power that exists today, among which the computer
can calculate thousands of hashes per second. To mit-
igate this problem, the Blockchain has a consensus
mechanism called Proof-of-Work. This mechanism
slows down the creation of new blocks since if a block
is tempered, the Proof-of-Work of all the previous
blocks has to be recalculated. Therefore, the security
of Blockchain comes from its creative use of hashing
and a Proof-of-Work mechanism. Of course, its dis-
tributed nature also adds a certain degree of security
because the Blockchain does not use a central entity
to manage the chain, but uses a peer-to-peer network
that anyone can join.

As a new technology, Blockchain raises questions
regarding its viability. As (Garther, 2019) claims,
Blockchain technology is still very immature to sup-

port most of the potential use cases and is still a
tremendous amount of research, implementation, and
adoption to be done. Further, building systems on
Blockchain is non-trivial due to the steep learning
curve of the Blockchain technology. According to
a survey by (Gartner, 2018), “23 percent of [rele-
vant surveyed] CIOs said that blockchain requires the
newest skills to implement any technology area, while
18 percent said that blockchain skills are the most dif-
ficult to find.”.

4.4 Smart Contracts

Blockchain is run by machines that essentially per-
form three things: networking, consensus, and state
management. These machines must run application-
layer software responsible for updating the state. For
Blockchains like Ethereum (Vitalik Buterin, 2013),
a Turing-complete virtual machine is the application
layer. The software programs that developers deploy
to the Blockchain virtual machine are usually called
Smart Contracts. The Ethereum Blockchain was
specifically created and designed to support Smart
Contracts. Solidity is a high-level programming lan-
guage to implement Smart Contracts specially design
for the Ethereum Virtual Machine (EVM). the smart
contracts are deployed onto the blockchain in the form
of a specialized bytecode. This bytecode then runs on
each Ethereum node in EVM. Since creating smart
contracts directly in the bytecode would be too im-
practical, multiple specialized high-level languages
have been created, together with the compilers needed
to convert them into EVM bytecode.

The smart contract itself is written in any sim-
ple language, depending on which Blockchain will be
deployed, and is usually very short. Although they
are relatively short, they are extremely powerful as
they leverage the huge power of cryptography and
blockchains since they operate across organizations
and between individuals. Smart contracts can store
records of who owns what, as well as promises with-
out the need for intermediaries or exposing people to
fraud. These contracts can automatically execute in-
structions given in the past. For pure digital assets,
there is no setback, because the value to be trans-
ferred can be locked in the contract when the con-
tract is created, and automatically released when the
conditions and terms are met. In this case, fraud is
impossible because the program can truly control the
assets involved without the need for a trusted inter-
mediary. Like all algorithms, Smart Contracts may
require input values and only act if certain prede-
fined conditions are met. When a particular value is
reached, the Smart Contract changes its state and ex-

MODELSWARD 2021 - 9th International Conference on Model-Driven Engineering and Software Development

68



ecutes the functions, that are programmatically pre-
defined algorithms, automatically triggering an event
on the Blockchain. If false data is entered into the
system, then false results will be outputted.

4.5 Tokens

From what has been written throughout this paper,
the use of Blockchain technology seems the future
to manage digital assets, due to its security and im-
mutability features. In (Voshmgir, 2019) tokens are
described as ways to represent ”programmable assets
or access rights, managed by a smart contract and
an underlying distributed ledger. They are accessible
only by the person who has the private key for that ad-
dress and can only be signed using this private key.”

However, without the use of fungible tokens, this
would be impossible to do since no unique informa-
tion can be written into the token. To represent to-
kens that have to be unique and hold information in-
stead of values, non-fungible tokens are preferred. On
one hand, the fungible tokens can be exchanged to
any other token of the same type. Non-fungible to-
kens, on the other hand, cannot be replaced by other
non-fungible tokens of the same type. For these rea-
sons, the fungible tokens are uniform, meaning they
are identical to one another, where the non-fungible
tokens are unique. Fungible tokens are divisible into
smaller units, while the non-fungible tokens cannot
be divided. In this paper, the non-fungible tokens are
used to represent voter’s ballots.

Due to the need to standardize the general struc-
ture of Ethereum Blockchain tokens, Ethereum Im-
provement Proposals (Ethereum, 2020) was created.
These standards allowed for Smart Contracts running
on Ethereum to interact with tokens defined by other
Smart Contracts. One of these standards is the ERC-
20, providing a typical list of rules on how the fun-
gible tokens should be structured. That makes them
easy to trade, as there is no need to differentiate the to-
kens. To represent unique assets, however, the tokens
must be non-fungible, even if they are of the same
type. In order to facilitate these types of tokens, the
ERC-721 standard was created (Voshmgir, 2019).

4.6 Das Contract

The Das Contract (Skotnica and Pergl, 2020) is a
DSL designed to be an implementation-independent
language for specifying blockchain smart contracts.
The Das Contract specification is based on a sub-
set of BPMN 2.0 (OMG, 2011), UML class dia-
gram (OMG, 2015) and extended with concepts spe-
cific to the blockchain execution environment. The

 
 

Legal Text 
+ 

Formal
Models 

A Person

A Company

A Legal  
Authority

 
A Smart
Contract

CodeCode
Generation

A Blockchain
A Contract

Human Understanding Technical Implementation Digital Interaction

Figure 2: A proposed concept architecture of DasCon-
tract (Skotnica and Pergl, 2020).

extension allows to specify off-chain forms to interact
with the smart contract, smart contract logic, and abil-
ity to work with payments or tokens. The language is
still under development, and it will be enhanced with
the support of decentralized identity and data oracles.

According to the (Skotnica and Pergl, 2020) and
shown in Figure 2, DasContract’s approch consists of
three parts:

Human Understanding: part defines a contract be-
tween multiple parties that they need to agree on.
Such a contract is a combination of legal text
and formal ontological models. The legal text in
some form specifies the legal validity of the for-
mal model.

Technical Implementation: part specifies how for-
mal models from the contract are transformed into
a software executable code and uploaded into a
blockchain as a smart contract.

Digital Interaction: is a part where people, compa-
nies and legal authorities can interact with the
agreed upon contracts. Since the contract is in
a blockchain, the interaction is fully digital, and
thanks to cryptography can also be legally bind-
ing. Blockchain by design also provides an audit
trail of all actions performed by the parties and
ensures that the agreed upon contract is executed
correctly.

5 OUR APPROACH

Our approach was designed to answer the research
question from section 2. It adopts the BPM method-
ology to provide a methodical way of designing a
blockchain smart contract. A Model-driven engineer-
ing approach is used to generate a smart contract
source code for a particular blockchain. In this pa-
per an Ethereum smart contract platform is used, but
the approach can be generalized. An application of
our approach is shown in section 6 on a process of
EU parliament elections.

Process Digitalization using Blockchain: EU Parliament Elections Case Study

69



The BPM life-cycle in context of digitizing a process
to be used in blockchain technology is following:

1. Design - A process is designed in a DasContract
language with blockchain limitations in mind.
The major limitation compared to a traditional
software system is it’s immutability and a require-
ment that all performed actions are deterministic.

2. Modeling - A simulation of the DasContract may
be performed to ensure the correct behaviour of
the process. This may be critical because the con-
tract can’t be changed after being deployed and
it may be handling significant monetary or legal
value.

3. Execution - A smart contract source code is gener-
ated and uploaded to the blockchain. Because the
metamodel is implementation independent, any
supported blockchain platform can be chosen.

4. Monitoring - Due to the inherent blockchain ca-
pability to record all transaction history, auditing
and analysis of process execution history can be
done.

5. Optimization - The optimization is not relevant in
blockchain because once the smart contract is up-
loaded it is not possible to change it.

6. Re-engineering - Similar to the optimization, the
re-engineering is not available. A new process can
be designed and uploaded to the blockchain but
the old one will be still running.

5.1 Das Contract to Smart Contract
Transformation

The DasContract consists of three interconnected
models: process model, data model, and forms model.
The metamodel of the data and forms models is
shown on Figure 3. The highlighted parts in blue are
the recent additions to support the representation of
fungible and non-fungible tokens and enums. The to-
kens inherit from the entity, and therefore they can
have data properties to represent token metadata.

Process Model: specifies the contract’s process ac-
tivities, their execution order, property mappings, and
user roles. The model is based on an extended subset
of the BPMN 2.0 level 3 notation. The main addition
is support for blockchain tokens (described in Sec-
tion 4.5) that allows to issue and receive both fungi-
ble and non-fungible tokens. During the transforma-
tion, the process sequence is transformed into a smart
contract programming language statements such as if-
else, functions, etc. This process may vary for differ-
ent blockchain implementations.

Data Model: is a domain model of the process is
based on the UML class diagram. It allows speci-
fying entities, properties, and relationships between
them. The properties may contain primitive types
such as int, bool, and string, but arrays and enumer-
ations are supported as well. Address and Address-
Payable types are added to support the storage of a
blockchain actor’s addresses and consequent token or
cryptocurrency transfers. A blockchain token is rep-
resented as a special type of entity and supports defin-
ing both fungible and non-fungible tokens with cus-
tom properties. A transformation of the models to the
smart contract source code is straightforward because
the blockchain programming languages support such
concepts in the form of classes, structures, enums, and
properties. The support of tokens is native on some
platforms. On other platforms such as Ethereum is
added as a third-party library.

Forms Model: specifies an interface for the user
activity input. The forms model is generated into
two parts during the generation – off-chain model
and on-chain code that is similar to a web application
client-side and server-side code. The off-chain model
is interpreted by a blockchain wallet that allows the
user to interact with the smart contract. Most of the
blockchain implementations currently have no sup-
port for off-chain code inside a smart contract. The
on-chain code handles validations, user rights, and
property bindings.

6 CASE STUDY: EU ELECTION

Since 1979, occurred to date, nine Elections of the
European Parliament, once every five years according
to the universal adult suffrage. From 2020, 704 Mem-
bers of the European Parliament will be elected by
more than 400 million eligible voters from 27 mem-
ber states, for this reason it is considered the sec-
ond largest democratic elections in the world (Hare,
2015). Each member state has its own voting sys-
tem, either being by Preferential voting, Closed lists
or Single Transferable Vote, all can be combined
with Multiple Constituents. Further, each member
state has its own voting methods for citizens resi-
dent abroad and if whether or not voting is compul-
sory. Each member state has different rules determin-
ing who can vote for and run as a Member of the Eu-
ropean Parliament. Although this is not a very stan-
dardized process, the European Parliament is the only
institution in the European Union, directly elected by
the citizens. So, it is extremely important that this

MODELSWARD 2021 - 9th International Conference on Model-Driven Engineering and Software Development

70



1 0..*

1

0..*

<<Enumeration>>
PropertyDataType

Int
Uint
Bool
String
DateTime
Address
AddressPayable
Data
Byte
Reference

10..*

0..*

0..*

0..*

0..*

C
an
di
da
te
R
ol
es

1

0..*

0..*

0..*

C
an
di
da
te
U
se
rs

As
ig
ne
e

1

1

1 0..*

<<Enumeration>>
FormFieldType

Property
ComboBox
Custom0..*

1

St
ar
tF
or
m

<<Enumeration>>
PropertyType

Single
Collection
Dictionary

1

0..*

Contract

+ Id: string

+ ProcessDiagram: string

Process

ProcessUser

+ Id: string

+ Name: string

+ Description: string

UserTask

ProcessRole

+ Id: string

+ Name: string

+ Description: string

UserForm

+ Id: string

FormField

+ Id: string

+ Order: int

+ Type: FormFieldType

+ DisplayName: string

+ IsReadOnly: boolean

+ PropertyExpression: string

+ CustomConfiguration: string
StartEvent

1

0..*

ReferencedDataType

Token

+ Symbol: string

+ IsFungible: bool

+ IsIssued: bool

DataType

+ Id: string

+ Name: string

Enum

+ Values: string[]

Property

+ Id: string

+ Name: string

+ IsMandatory: boolean

+ PropertyDataType: PropertyDataType

+ Type: PropertyType

+ KeyType: PropertyDataType

Entity

Figure 3: A DasContract Data and Forms Metamodel.

is a transparent, meddle-proof, usable, authenticated,
accurate and verifiable process (Patil et al., 2013).

The development and implementation of constitu-
tional and legal provisions have been one of the en-
gineering concerns. Since for instance, the Elections
of the European Parliament have the estimated cost of
e 700 million. Blockchain has been the most promis-
ing technology when it comes to the electoral domain,
seeing that per each vote, a new transaction, if valid, is
added to the end of the blockchain and remains there
forever (Curran, 2018). For this solution, no central-
ized authority is needed to approve the votes, and ev-
eryone agrees on the final tally as they can count the
votes themselves, as anyone can verify that no votes
were tampered with and no illegitimate votes were in-

serted.
This case study shows how to digitize the EU elec-

tion process by following a method proposed in Sec-
tion 5. A simplified version of the process was de-
signed and tested on the Ethereum blockchain.

6.1 Process Design

The EU election process is very complex. The EU
issues general guidelines on how country elections
should look like, and each country then implements
its legislation to describe how the elections are done
in a particular country. This means that each of the 27
EU countries does this process differently. To avoid
this complexity, it was assumed that there is a unified

Process Digitalization using Blockchain: EU Parliament Elections Case Study

71



E
ur

o
pe

an
 P

a
rli

am
en

t E
le

ct
io

ns

Start Country
Elections

[Political Party]
Register New

Party

[Candidate]
Register

candidate

[Political
Party] Approve

and Order
Candidates

Country
Ellections

Initiate
Ellections

C
ou

nt
ry

 E
le

ct
io

ns

Assign
Privilegues to
the Elected
Candidates

Distribute  SeatsCount Votes
Send ballots to
the elegible EU

Citizens

[EU Citizen]
Vote

Figure 4: A DasContract Process Model of the EU Elections.

voting process and each country votes according to
one of the three voting systems – preferential voting,
closed lists, and single transferable vote.

The modeled process is shown on Figure 4. It
starts with an initiation of the elections where all the
countries and their voting systems are initiated in the
contract. After the initiation, political parties are able
to register until a set deadline i";"""date"",""2021-02-11T13:39:38Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2021-02-11T13:39:38Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is MiKTeX-pdfTeX 2.9.6870 (1.40.19)""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2021-02-11T13:39:38Z""
""created"",""2021-02-11T13:39:38Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2021-02-11T13:39:38Z""
""resourceName"",""102290.pdf""
""Author"",""""
""producer"",""pdfTeX-1.40.19""
""pdf:docinfo:producer"",""pdfTeX-1.40.19""
""pdf:unmappedUnicodeCharsPerPage"",""1"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2021-02-11T13:39:38Z""
""Last-Modified"",""2021-02-11T13:39:38Z""
""dcterms:modified"",""2021-02-11T13:39:38Z""
""title"",""""
""Last-Save-Date"",""2021-02-11T13:39:38Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2021-02-11T13:39:38Z""
""meta:save-date"",""2021-02-11T13:39:38Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is MiKTeX-pdfTeX 2.9.6870 (1.40.19)""
""Content-Length"",""713258""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""11""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""3418"",""4172"",""4454"",""4502"",""3863"",""4112"",""2217"",""3273"",""3093"",""3776"",""3418""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2021-02-11T13:39:38Z""
";https://scholar.google.ch/scholar?start=70&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2021
1619099124-456;https://scholar.google.ch/scholar?as_ylo=2021&q=oracles+blockchain&hl=fr&as_sdt=0,5;An Offline Delegatable Cryptocurrency System;R Li, Q Wang, X Zhang, Q Wang, D Galindo… ; arXiv preprint arXiv …, 2021  arxiv.org;;"… D may also attempt to assemble an invalid transaction or double spend the delegated coins.

We also assume the blockchain B is robust and publicly accessible. 10 Page 11 … reply Oracle

Odelegatee query reply HW Oracle Figure 2: Oracles Interaction Diagram …";Les 2 versions;Version HTML;[PDF] arxiv.org;https://arxiv.org/pdf/2103.12905;"
An Offline Delegatable Cryptocurrency System
(Full Version)∗

Rujia Li1,2†, Qin Wang3,4†, Xinrui Zhang5,
Qi Wang1‡, David Galindo2 and Yang Xiang3

1 Southern University of Science and Technology, Shenzhen, 518055, Guangdong, China
2 University of Birmingham, Edgbaston, B15 2TT, Birmingham, United Kingdom.

3 Swinburne University of Technology, Melbourne, VIC 3122, Australia.
4 CSIRO Data61, Sydney, NSW 2015, Australia.

5 Nankai University, Tianjin, 300350, China.
rxl635@bham.ac.uk,qinwang@swin.edu.au,wangqi@sustech.edu.cn

Abstract. Blockchain-based cryptocurrencies, facilitating the convenience of payment
by providing a decentralized online solution, have not been widely adopted so far due to
slow confirmation of transactions. Offline delegation offers an efficient way to exchange
coins. However, in such an approach, the coins that have been delegated confront the
risk of being spent twice since the delegator’s behaviour cannot be restricted easily on
account of the absence of effective supervision. Even if a third party can be regarded
as a judge between the delegator and delegatee to secure transactions, she still faces
the threat of being compromised or providing misleading assure. Moreover, the
approach equipped with a third party contradicts the real intention of decentralized
cryptocurrency systems. In this paper, we propose DelegaCoin, an offline delegatable
cryptocurrency system to mitigate such an issue. We exploit trusted execution
environments (TEEs) as decentralized “virtual agents” to prevent malicious delegation.
In DelegaCoin, an owner can delegate his coins through offline-transactions without
interacting with the blockchain network. A formal model and analysis, prototype
implementation and further evaluation demonstrate that our scheme is provably
secure and practically feasible.
Keywords: Cryptocurrency, Payment, Trusted Execution Environments (TEEs),
Offline Delegation

∗A preliminary version was accepted by IEEE ICBC’21 [1]. A poster version was shown in NDSS’21 [2].
†These authors contributed equally to the work.
‡Corresponding author.

ar
X

iv
:2

10
3.

12
90

5v
1 

 [
cs

.C
R

] 
 2

4 
M

ar
 2

02
1

mailto:
mailto:rxl635@bham.ac.uk, qinwang@swin.edu.au, wangqi@sustech.edu.cn


1 Introduction
The interest in decentralized cryptocurrencies has grown rapidly in recent years. Bitcoin

[3], as the first and most famous system, has attracted massive attention. Subsequently,
a handful of cryptocurrencies, such as Ethereum [4], Namecoin [5] and Litecoin [6], were
proposed. Blockchain-based cryptocurrencies significantly facilitate the convenience of
payment by providing a decentralized online solution for customers. However, merely
online processing of transactions confronts the problem of low performance and high
congestion. Offline delegation provides an alternative way to mitigate the issue by enabling
users to exchange the coin without having to connect to an online blockchain platform [7].
Unfortunately, decentralized offline delegation still confronts risks caused by unreliable
participants. The misbehaviours may easily happen due to the absence of effective
supervision. To be specific, let us start from a real scenario: imagine that Bob, the son
of Alex, a wild teenager, wants some digital currency (e.g., BTC) to buy a film ticket.
According to current decentralized cryptocurrency payment technologies [3][4], Alex has
two delegation approaches: (1) Coin-transfer. Alex asks for Bob’s BTC address, and
then transfers a specific amount of coins to Bob’s address. In such a scenario, Bob can
only spend received coins from Alex. (2) Ownership-transfer. Alex directly gives his own
private key to Bob. Then, Bob can freely spend the coins using such a private key. In this
situation, Bob obtains all coins that are saved in Alex’s address.

We observe that both approaches suffer drawbacks. For the first approach, coin-transfer
requires a global consensus of the blockchain, which makes it time-consuming [8]. For
example, a confirmed transaction in the Bitcoin [3] takes around one hour (6 blocks),
making the coin-transfer lose the essential property of real-time. For the other approach,
ownership-transfer highly relies on the honesty of the delegatee. The promise between
the delegator and delegatee depends on their trust or relationship. But it is weak and
unreliable. The delegatee may spend all coins in the address for other purposes. Back to
the example, Alex’s original intention is to give Bob 200 µBTC to buy a film ticket, but
Bob may spend all coins to purchase his favorite toys. That means Alex loses control of
the rest of coins. These two types of approaches represent most of the mainstream schemes
ever aiming to achieve a secure delegation, but neither of them provide a satisfactory
solution. This leads to the following research problem:

Is it possible to build a secure offline peer-to-peer delegatable system for
decentralized cryptocurrencies?

The answer would intuitively be “NO”. Without interacting with the online blockchain
network, the coins that have been used confront the risk of being spent twice after another
successful delegation. This is because a delegation is only witnessed by the owner and
delegatee, where no authoritative third parties perform final confirmation. The pending
status leaves a window for attacks in which a malicious coin owner could spend this
delegated transaction before the delegatee uses it. Even if a third party can be introduced
as a judge between the delegator (owner) and delegatee to secure transactions, she faces
the threat of being compromised or provided with misleading assure. Furthermore, the
approach equipped with a third party contradicts the real intention of decentralized
cryptocurrency systems.

In this paper, we propose DelegaCoin, an offline delegatable electronic cash system.
The trusted execution environments (TEEs) are utilized to play the role of virtual agent.
TEEs prevent malicious delegation of the coins (e.g. double-delegation on the same coins).
As shown in Figure.1, the proposed scheme allows the owner to delegate her coins without
interacting with the blockchain or any trusted third parties. The owner is able to directly

2



delegate specific amounts of coins to others by sending them through a secure channel.
This delegation can only be executed once under the supervision of delegation policy inside
TEEs. In a nutshell, this paper makes the following contributions.

- We propose an offline delegatable payment solution, called DelegaCoin. It employs
the trusted execution environments (TEEs) as the decentralized virtual agents to
prevent the malicious owner from delegating the same coins multiple times.

- We formally define our protocols and provide a security analysis. Designing a provably
secure system from TEEs is a non-trivial task that lays the foundation for many
upper-layer applications. The formal analysis indicates that our system is secure.

- We implement the system with Intel’s Software Guard Extensions (SGX) and conduct
a series of experiments including the time cost for each function and the used disk
space under different configurations. The evaluations demonstrate that our system
is feasible and practical.

Paper Structure. Section 2 gives the background and related studies. Section 3 provides
the preliminaries and building blocks. Section 4 outlines the general construction of our
scheme. Section 5 presents a formal model for our protocols. Section 6 provides the
corresponding security analysis. Section 7 and Section 8 show our implementation and
evaluation, respectively. Section 9 concludes our work. Appendix A provides an overview
of protocol workflow, Appendix B shows the resources availability and Appendix C presents
featured notations in this paper.

2 Related Work
Decentralized Cryptocurrency System. Blockchain-based cryptocurrencies facilitate
the convenience of payment by providing a decentralized online solution for customers.
Bitcoin [3] was the first and most popular decentralized cryptocurrency. Litecoin [6]
modified the PoW by using the Script algorithm and shortened the block confirmation
time. Namecoin [5] was the first hard fork of Bitcoin to record and transfer arbitrary names
(keys) securely. Ethereum [4] extended Bitcoin by enabling state-transited transactions.
Zcash [9] provides a privacy-preserving payment solution by utilizing zero-knowledge
proofs. CryptoNote-style schemes [10], instead, enhance the privacy by adopting ring-
signatures. However, slow confirmation of transactions retards their wide adoption from
developers and users. Current cryptocurrencies, with ten to hundreds of TPS [3, 11],
cannot rival established payment systems such as Visa or PayPal that process thousands.
Thus, various methods have been proposed for better throughput. The scaling techniques
can be categorized in two ways: (i) On-chain solutions that aim to create highly efficient
blockchain protocols, either by reconstructing structures [12], connecting chains [13] or via
sharding the blockchain [14]. However, on-chain solutions are typically not applicable to
existing blockchain systems (require a hard fork). (b) Off-chain (layer 2) solutions that
regard the blockchain merely as an underlying mechanism and process transactions offline
[7]. Off-chain solutions generally operate independently on top of the consensus layer of
blockchain systems, not changing their original designs. In this paper, we explore the
second avenue.
TEEs and Intel SGX. The Trusted Execution Environments (TEEs) provide a secure
environment for executing code to ensure the confidentiality and integrity of code and
logic [15]. State-of-the-art implementations include Intel Software Guard Extensions
(SGX) [16], ARM TrustZone [17], AMD memory encryption [18], Keystone [19], etc.
Besides, many other applications like BITE [20], Tesseract [21], Ekiden [22] and Fialka
[23] propose their TEEs-empowered schemes, but they still miss the focus of offline

3



delegation. In this paper, we utilize SGX [16] to construct the system. SGX is one of
TEEs representatives, and offers a set of instructions embedded in central processing units
(CPUs). These instructions are used for building and maintaining CPUs’ security areas. To
be specific, SGX allows to create private regions (a.k.a. enclave) of memory to protect the
inside contents. The following features are highlighted in this technique: (1) Attestation.
Attestation mechanisms are used to prove to a validator that the enclave has been correctly
instantiated, and used to establish a secure, authenticated connection to transfer sensitive
data. The attestation guarantees the secret (private key) to be provisioned to the enclave
only after a successful substantiation. (2) Runtime Isolation. Processes inside the enclave
are protectively isolated from the software running outside. Specifically, the enclave
prevents higher privilege processes and outside operating system codes from falsifying
inside executions of loaded codes. (3) Sealing identity technique. SGX offers a seal sealing
identity technique, where the enclave data is allowed to store in untrusted disk space. The
private sealing key comes from the same platform key, which enables data sharing across
different enclaves.
Payment Delegation. The payment delegation plays a crucial role in e-commercial
activities, and it has been comprehensively studied for decades. Several widely adopted
approaches are such that using credit cards (Visa, Mastercard, etc.), using reimbursement,
using third-party platforms (like PayPal [24], AliPay [25]). These schemes allow users to
delegate their cash spending capability to their own devices or other users. However, these
delegation mechanisms heavily rely on a centralized party that needs a fairly great amount
of trust. Decentralized cryptocurrencies, like Bitcoin [3] and Ethereum [4], remove the
role of trusted third parties, making the payment reliable and guaranteed by distributed
blockchain nodes. However, such payment is time-consuming since the online transactions
need to get confirmed by the majority of participated nodes. The delegation provides
the decentralized cryptocurrency with an efficient payment approach to delegate the coin
owner’s spending capability. The cryptocurrency delegation using SGX was first explored
in [26], where they only focused on the credential delegation in the fair exchange. Teechan
[27] provided a full-duplex payment channel framework that employs TEEs, in which the
parties can pay each other without interacting with the blockchain in a bounded time.
However, Teechan requires a complex setup: the parties must commit a multisig transaction
before the channel started. In contrast, our scheme is simple and more practical.

3 Preliminaries and Definitions
We make use of the following notions, definitions and assumptions to construct our

scheme. Details are shown as follows.

3.1 Notions
Let Îť denote a security parameter, negl(Îť) represent a negligible function and A refer

to an adversary. b? and c? are wildcard characters, representing the balance and the
encrypted balance, respectively. A full notion list is provided in Appendix 9.

3.2 Crypto Primitive Definitions
Semantically Secure Encryption. A semantically secure encryption SE consists of a
triple of algorithms (KGen,Enc,Dec) defined as follows.

- SE.KGen(1Îť) The algorithm takes as input security parameter 1Îť and generates a
private key sk from the key spaceM.

4



- SE.Enc(sk,msg) The algorithm takes as input a private key sk and a message msg ∈
M, and outputs a ciphertext ct.

- SE.Dec(sk, ct) The algorithm takes as input a verification key sk, a message ct, and
outputs msg.

Correctness. A semantically secure encryption scheme SE is correct if for all msg ∈M,

Pr
[
SE.Dec(sk, (SE.Enc(sk,msg))) 6= msg

∣∣sk← SE.KGen(1λ)
]
≤ negl(λ),

where negl(Îť) is a negligible function and the probability is taken over the random coins
of the algorithms SE.Enc and SE.Dec.

Definition 1 (IND-CPA security of SE). A semantically secure encryption scheme SE
achieves Indistinguishability under Chosen-Plaintext Attack(IND-CPA) if all PPT adver-
saries, there exists a negligible function negl(Ν) such that∣∣ Pr

[
GIND−CPA
A,SE (Îť) = 1

]
− 1

2
∣∣ ≤ negl(λ),

where GIND−CPA
A,SE (Îť) is defined as follows:

GIND−CPA
A,SE (Îť)

1 : sk $← SE.KGen(1λ);

2 : b $← {0, 1}

3 : m0,m1 ← ASE(·)

4 : c? ← SE.Enc(sk,mb)

5 : b
′
← ASE(·)(c?)

6 : return b = b
′

Signature Scheme. A signature scheme S consists of the following algorithms.

- S.KeyGen(1Îť) The algorithm takes as input security parameter 1Îť and generates a
private signing key sk and a public verification key vk.

- S.Sign(sk,msg) The algorithm takes as input a signing key sk and a message msg ∈M,
and outputs a signature σ.

- S.Verify(vk, σ,msg) The algorithm takes as input a verification key vk, a signature σ
and a message msg ∈M, and outputs 1 or 0.

Correctness. A signature scheme S is correct if for all msg ∈M,

Pr
[
S.Verify(vk, (S.Sign(sk,msg)),msg) 6= 1

∣∣(vk, sk)← S.KeyGen(1λ)
]
≤ negl(λ),

where negl(Îť) is a negligible function and the probability is taken over the random coins
of the algorithms S.Sign and S.Verify.

Definition 2 ((EUF-CMA security of S). A signature scheme S is called Existentially
Unforgeable under Chosen Message Attack(EUF-CMA) if all PPT adversaries, there exists
a negligible function negl(Îť) such that

Pr
[
GEUF−CMA
A,S (Îť) = 1

]
≤ negl(λ),

where GEUF−CMA
A,S (Îť) is defined as follows:

5



GIND−CPA
A,S (Îť)

1 : (sk, pk) $← S.KeyGen(1λ);
2 : L ← S.Sign(sk,m{0,...,n});

3 : (m?, σ?)← AO(sk,·)(pk)
4 : return (S.Verify(vk, σ?,m?) = 1) ∧m? /∈ L

Public Key Encryption. A public key encryption scheme PKE consists of the following
algorithms.

- PKE.KeyGen(1Îť) The algorithm takes as input security parameter 1Îť and generates
a private signing key sk and a public verification key vk.

- PKE.Enc(pk,msg) The algorithm takes as input in a public key pk and a message
msg ∈M, and outputs a ciphertext ct.

- PKE.Dec(sk, ct) The algorithm takes as input a secret key sk, a ciphertext ct, and
outputs msg or ⊥.

Correctness. A public key encryption scheme PKE is correct if for all msg ∈M,

Pr
[
SE.PKE(sk, (PKE.Enc(pk,msg))) 6= msg

∣∣(sk, pk)← PKE.KeyGen(1λ)
]
≤ negl(λ),

where negl(Îť) is a negligible function and the probability is taken over the random coins
of the algorithms PKE.KeyGen and PKE.Enc.

Definition 3 ((IND-CCA2 security of PKE). A PKE scheme PKE is said to have Indis-
tinguishability Security under Adaptively Chosen Ciphertext Attack(IND-CCA2) if all PPT
adversaries, there exists a negligible function negl(Îť) such that

Pr
[
GIND−CCA2
A,PKE (Îť) = 1

]
≤ negl(λ),

where GIND−CCA2
A,PKE (Îť) is defined as follows:

GIND−CCA2
A,PKE (Îť)

1 : (sk, pk) $← PKE.KGen(1λ);

2 : b $← {0, 1}

3 : m0,m1 ← APKE.Dec(sk,·)

4 : c? ← PKE.Enc(sk,mb)

5 : b
′
← APKE.Dec(sk,·)(c?)

6 : return b = b
′

3.3 Secure Hardware
In our scheme, parties will have access to TEEs, in which they serve as isolated

environments to guarantee the confidentiality and integrity of inside code and data. To
capture the secure functionality of TEEs, inspired by [28, 29] we define TEEs as a black-box
program that provides some interfaces exposed to users. The abstraction is given as follows.
Note that, Due to the scope of usage, we only capture the remote attestation of TEEs and
refer to [28] for a full definition.

Definition 4. A secure hardware functionality HW for a class of probabilistic polynomial
time (PPT) programs P includes the algorithms: Setup, Load, Run, RunQuote, QuoteVerify.

6



- HW.Setup(1Îť) : The algorithm takes as input a security parameter Îť, and outputs
the secret key skquote and public parameters pms.

- HW.Load(pms, P ) : The algorithm loads a stateful program P into an enclave. It
takes as input a program P ∈ P and pms, and outputs a new enclave handle hdl.

- HW.Run(hdl, in) : The algorithm runs enclave. It inputs a handle hdl that relates to
an enclave (running program P ) and an input in, and outputs execution results out.

- HW.RunQuote(hdl, in) : The algorithm executes programs in an enclave and generates
an attestation quote. It takes as input hdl and in, and executes P on in. Then, it
outputs quote = (hdl, tagP, in, out, σ), where tagP is a measurement to identify the
program running inside an enclave and σ is a corresponding signature.

- HW.QuoteVerify(pms, quote) : The algorithm verifies the quote. It firstly executes
P on in to get out. Then, it takes as input pms, quote = (hdl, tagP, in, out, σ), and
outputs 1 if the signature σ is correct. Otherwise, it outputs 0.

Correctness. The HW scheme is correct if the following properties hold: For all program
P, all input in

• Correctness of HW.Run: for any specific program P ∈ P , the output of HW.Run(hdl, in)
is deterministic.

• Correctness of RunQuote and QuoteVerify:

Pr[QuoteVerify(pms,RunQuote(hdl, in)) 6= 1] ≤ negl(λ).

Remote attestation in TEEs provides functionality for verifying the execution and
corresponding output of a certain code run inside the enclave by using a signature-based
quote. Thus, the remote attestation unforgeability security [28] is defined similarly to the
unforgeability of a signature scheme.

Definition 5 (Remote Attestation Unforgeability (RemAttUnf)). A HW scheme is Re-
mAttUnf secure if all PPT adversaries, there exists a negligible function negl(Îť) such
that

Pr
[
GRemAttUnf
A,S (Îť) = 1

]
≤ negl(λ),

where GRemAttUnf
A,HW (Îť) is defined as follows:

GRemAttUnf
A,HW (Îť)

1 : pms← HW.Setup(1λ);
2 : hdl← HW.Load(pms, P );
3 : Q ← HW.RunQuote(hdl, in{0,...,n});

4 : (in?, quote?)← AO(hdl,·)(pms)
5 : return (HW.QuoteVerify(pms, quote?) = 1) ∧ quote? /∈ Q

7



4 DelegaCoin
In DelegaCoin, three types of entities are involved: coin owner (or delegator) O, coin

delegatee D, and blockchain B (see Figure 1). The main idea behind DelegaCoin is to
exploit the TEEs as trusted agents between the coin owner and coin delegatee. TEEs
are used to maintain delegation policies and ensure faithful executions of the delegation
protocol. In particular, TEEs guarantee that the coin owner (either honest or malicious)
cannot arbitrarily spend the delegated coins. The workflow is described as follows. Firstly,
both O and D initialize and run the enclaves, and the owner O′s enclave generates an
address addr for further transactions with a private key maintained internally. Next, O
deploys delegation policies into the owner O′s enclave and deposits the coins to the address
addr. Then, O delegates the coins to D by triggering the execution of delegation inside
the enclave. Finally, D spends delegated transaction to the blockchain network B. Note
that the enclaves in our scheme are decentralized, meaning that each O and D has its
own enclave without depending on a centralized agent, which satisfies the requirements of
current cryptocurrency systems.

Figure 1: DelegaCoin Workflow

4.1 System Framework

System Setup. In this phase, the coin owner O and the delegatee D initialize their TEEs
to provide environments for the operations with respect to the further delegation.

• Negotiation. pms← ParamGen(1λ): O agrees with D for the pre-shared information.
Here, Îť is a security parameter.

• Enclave Initiation. hdlO, hdlD ← EncvInit(1λ, pms): O and D initialize the enclave
EO and ED with outputting the enclave handles hdlO and hdlD.

• Key Generation. (pkTx, skTx), (pkO, skO), keyseal ← KeyGenTEE(hdlO, 1λ) and (pkD,
skD), (vksign, sksign), r← KeyGenTEE(hdlD, 1λ): O and D run the enclaves EO and ED

8



to create their internal keys. Key pair (pkTx, skTx) is used for transaction generation.
Key pair (pkO, skO) and (pkD, skD) are used for remote assertion, while keyseal is a
sealing key used to export the state to the trusted storage. Key pair (vksign, sksign) is
used to identify a specific delegatee, while r is a private key for transaction encryption.

• Quote Generation. quote← QuoGenTEE(skO, vksign, pms): O generate a quote for
requesting an encrypted symmetric encryption key from D.

• Key Provision. ctr ← ProvisionTEE(quote, sksign, pkO, pms): O proves to D that EO
has been instantiated with a quote to request an encrypted symmetric encryption
key ctr. The symmetric encryption is used to encrypt the messages inside TEEs.

• Key Extraction. r← ExtractTEE(skO, ctr): O extracts a symmetric encryption key r
from ctr using skO.

• State Retrieval. binit = DecTEE(keyseal, cinit): Encrypted states are read back by the
enclave EO under keyseal, where binit is the initial balance and cinit is the initial
encrypted balance. This step prevents unexpected occasions that may destroy the
state in TEEs memory.

Coin Deposit. The enclave EO generates an address and its corresponding private key
pkTx for the deposit. Afterwards, O sends coins to this address in the form of fund deposits.

• Address Creation. addr← AddrGenTEE(1λ, pkTx): O calls EO to generate a transac-
tion address addr. The private key skTx of addr is secretly stored inside TEEs and is
generated by an internal pseudo-random number.

• Coin Deposit. bdeposit = UpdateB(addr, binit): O generates an arbitrary transaction
and transfers some coins to addr as the fund deposits.

Coin Delegation. In this phase, neither O nor D interacts with blockchain. O can
instantly complete the coin delegation through offline transactions.

• Balance Update. bupdate ← UpdateTEE(bdeposit, bTx): EO checks current balance to
ensure that it is enough for deduction. Then, EO updates the balance.

• Signature Generation. σTx ← TranSignTEE(skTx, addr, bTx): EO generates a valid
signature σTx.

• Transaction Generation. Tx ← TranGenTEE(addr, bTx, σTx): EO generates a transac-
tion Tx using σTx.

• Coin Delegation. cttx ← TranEncTEE(r,Tx): O sends encrypted transaction cttx to D.

• State Seal. cupdate ← EncTEE(keyseal, bupdate): Once completing the delegation, the
records cupdate are permanently stored outside the enclave. If any abort or halt
happens, a re-initiated enclave starts to reload the missing information.

All the algorithms in the step of Coin Delegation must be run as an atomic operation,
meaning that either all algorithms finish or none of them finish. A hardware Root of Trust
can guarantee this, and we refer to [16] for more detail.
Coin Spend. Tx ← TranDecTEE(r, cttx): D decrypts cttx with r, and then spends Tx by
forwarding it to blockchain network.
Correctness. The DelegaCoin scheme is correct if the following properties hold: For all Tx,
bdeposit, bupdate and bTx.

9



• Correctness of Update:

Pr [bTx 6= (bdeposit − bupdate)] ≤ negl(λ).

• Correctness of Seal:

Pr[DecTEE(keyseal,EncTEE(keyseal, binit)) 6= binit] ≤ negl(λ).

• Correctness of Delegation:

Pr[TranDecTEE(r,TranEncTEE(r,Tx)) 6= Tx] ≤ negl(λ).

4.2 Oracles for Security Definitions
We now define oracles to simulate an honest owner and delegatee for further security

definitions and proofs. Each oracle maintains a series of (initially empty) sets R1, R2
and C which will be used later. Here, we use (instruction; parameter) to denote both the
instructions and inputs of oracles.
Honest Owner Oracle Oowner : This oracle gives the adversary access to honest owners.
An adversary A can obtain newly deletgated transactions or sealed storage with his
customized inputs. The oracle provides the following interfaces.

- On input (signature creation; addr), the oracle checks whether a tuple (addr, σTx) ∈ R1
exists, where addr is an input of transactions. If successful, the oracle returns σTx to
A; otherwise, it computes σTx ← TranSignTEE(skTx, addr, bTx) and adds (addr, σTx) to
R1, and then returns σTx to A.

- On input (quote generation; vksign), the oracle checks if a tuple (vksign, quote) ∈ R2
exists. If successful, the oracle returns quote to A. Otherwise, it computes quote←
QuoGenTEE(skO, vksign, pms) and adds (vksign, quote) to R2, and then returns quote
to A.

Honest Delegatee Oracle Odelegatee : This oracle gives the adversary access to honest
delegatees. The oracle provides the following interfaces.

- On input (key provision; quote), the oracle checks whether a tuple (quote, ctr) ∈ C
exists. If successful, the oracle returns ctr to A; otherwise, it computes
ctr ← ProvisionTEE(quote, sksign, pkO, pms), adds (quote, ctr) to C, and then returns
(quote, ctr) to A.

HW Oracle: This oracle gives the adversary the access to honest hardware. The oracle
provides the interfaces as defined as in 4. Note that, to ensure that anything A sees in the
real world can be simulated ideal experiment, we require that an adversary get access to
HW Oracle through Odelegatee and Oowner rather than directly interact with HW Oracle.

4.3 Threat Model and Assumptions
As for involved entities, we assume that O attempts to delegate some coins to the

delegatee. Each party may potentially be malicious. O may maliciously delegate an
exceptional transaction, represented as sending the same transaction to multiple delegatees
or spending the delegated transactions before the D spends them. D may also attempt to
assemble an invalid transaction or double spend the delegated coins. We also assume the
blockchain B is robust and publicly accessible.

10



DelegaCoin protocol
Adversary A

Real experiment

input

output

Oracle Oowner
query

reply

Oracle Odelegateequery

reply

HW Oracle

Figure 2: Oracles Interaction Diagram

With regard to devices, we assume that TEEs are secure, which means that an adversary
cannot access the enclave runtime memory and their hardware-related keys (e.g., sealing
key or attestation key). In contrast, we do not assume the components outside TEEs
are trusted. For example, the adversary may control the operating system or high-level
privileged software.

4.4 Security Goals.
DelegaCoin aims to employ TEEs to provide a secure delegatable cryptocurrency

system. In brief, TEEs prevent malicious delegation in three aspects: (1) The private
key of a delegated transaction and the delegated transaction itself are protected against
the public. If an adversary learns any knowledge about the private key or the delegated
transaction, she may spend the coin before the delegatee uses it; (2) The delegation
executions are correctly executed. In particular, the spendable amount of delegated coins
must be less than (or equal to) original coins; (3) The delegation records are securely
stored to guarantee consistency considering accidental TEEs failures or malicious TEEs
compromises. DelegaCoin is secure if adversaries cannot learn any knowledge about the
private key, the delegated transaction, and the sealed storage.

To capture such security properties, we formalize our system through a game inspired
by [30]. In our game, a PPT adversary attempts to distinguish between a real-world and a
simulated (ideal) world. In the real world, the DelegaCoin algorithms work as defined in
the construction. The adversary is allowed to access the transaction-related secret messages
created by honest users through oracles as in Definition 4.2. Obviously, the ideal world does
not leak any useful information to the adversary. Since we model the additional information
explicitly to respond to the adversary, we construct a polynomial-time simulator S that
can fake the additional information corresponding to the real result, but with respect to
the fake TEEs. Thus, a universal oracle U(¡) in the ideal world is introduced to simulate
the corresponding answers of A called in oracles in the real world. We give a formal model
as follows, in which these two experiments begin with the same setup assumptions.

Definition 6 (Security). DelegaCoin is simulation-secure if for all PPT adversaries
A, there exists a stateful PPT simulator S and a negligible function negl(Îť) such that
the probability of that A distinguishes between Expreal

A,DelegaCoin(Îť) and Expidea
A,DelegaCoin(Îť) is

negligible, i.e.,∣∣Pr[Expreal
A,DelegaCoin(λ) = 1]− Pr[Expideal

A,DelegaCoin(Îť) = 1]
∣∣ ≤ negl(λ).

11



Expreal
A,DelegaCoin(Îť)

1 : pms← ParamGen(1λ)

2 : hdlO, hdlD ← EncvInit(1λ, pms)

3 : (pkTx, skTx), (pkO, skO), keyseal ← KeyGenTEE(hdlO, 1λ)

4 : (pkD, skD), (vksign, sksign), r← KeyGenTEE(hdlD, 1λ)
5 : quote← A(hdlO, vksign, pms)

6 : ctr ← AProvisionTEE(sksign)(hdlD, quote, pkO, pms)

7 : r← AExtractTEE(skO)(hdlO, ctr)

. . . . . . . . . . . . . . . . . . . . Setup Completed . . . . . . . . . . . . . . . . . . . .

8 : binit = DecTEE(hdlO, keyseal, cinit)

9 : addr← AddrGenTEE(1λ, pkTx)

10 : bdeposit = UpdateB(addr, binit)

11 : bupdate ← UpdateTEE(hdlO, bdeposit, bTx)

12 : σTx ← ATranSignTEE(skTx)(hdlO, addr, bTx)

13 : Tx ← TranGenTEE(hdlO, addr, bTx, σTx)

14 : cttx ← ATranEncTEE(r)(hdlO,Tx)

15 : cupdate = AEncTEE(keyseal)(hdlO, bupdate)

. . . . . . . . . . . . . . . . . . Delegation Completed . . . . . . . . . . . . . . . . . .

16 : Tx ← TranDecTEE(hdlD, r, cttx)
17 : return (Tx, cupdate)

Expideal
A,DelegaCoin(Îť)

1 : pms← ParamGen(1λ)

2 : hdl?O, hdl?D ← S(1λ, pms)

3 : (pkTx, skTx), (pkO, skO), keyseal ← KeyGenTEE(hdl?O, 1λ)

4 : (pkD, skD), (vksign, sksign), r← KeyGenTEE(hdl?D, 1λ)
5 : quote← A(hdl?O, vksign, pms)

6 : ctr ← AS
U(¡)

(hdl?D, quote, pkO, pms)

7 : r← AS
U(¡)

(hdl?O, ctr)

. . . . . . . . . . . . . . . . . . . . Setup Completed . . . . . . . . . . . . . . . . . . . .

8 : binit ← S(hdlO, keyseal, cinit)

9 : addr← S(1λ, pkTx)
10 : bdeposit = S(addr, binit)

11 : bupdate ← S(hdl?O, bdeposit, 1|bTx|)

12 : σTx ← AS
U(¡)

(hdl?O, addr, bTx)

13 : Tx ← S(hdl?O, addr, 1|bTx |, σTx)

14 : cttx ← AS
U(¡)

(hdl?O, 1|Tx|)

15 : cupdate = AS
U(¡)

(hdl?O, 1|bupdate|)

. . . . . . . . . . . . . . . . . . Delegation Completed . . . . . . . . . . . . . . . . . .

16 : Tx ← S(hdl?D, r, cttx)
17 : return (Tx, cupdate)

5 Formal Protocols
In this section, we present a formal model of our electronic cash system by utilizing the

syntax of the HW model. In particular, we model the interactions of Intel SGX enclaves as
calling to the HW functionality defined in Definition 4. The formal protocols are provide
as follows.

The owner enclave program PO is defined as follows. The value tagP is a measurement
of the program PO, and it is hardcoded in the static data of PO. Let stateO denote an
internal state variable.

PO:

• On input (“init setup”, sid, vksi";"""date"",""2021-03-25T00:33:37Z""
""pdf:PDFVersion"",""1.5""
""xmp:CreatorTool"",""LaTeX with hyperref""
""pdf:docinfo:title"",""iacrtans class documentation""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""iacrtans class documentation""
""xmp:CreateDate"",""2021-03-25T00:33:37Z""
""modified"",""2021-03-25T00:33:37Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""xmp:ModifyDate"",""2021-03-25T00:33:37Z""
""pdf:docinfo:creator"",""Rujia Li, Qin Wang, Xinrui Zhang, Qi Wang, David Galindo, Yang Xiang""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.21 (TeX Live 2020) kpathsea version 6.3.2""
""meta:author"",""Rujia Li"",""Qin Wang"",""Xinrui Zhang"",""Qi Wang"",""David Galindo"",""Yang Xiang""
""trapped"",""False""
""meta:creation-date"",""2021-03-25T00:33:37Z""
""created"",""2021-03-25T00:33:37Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2021-03-25T00:33:37Z""
""resourceName"",""2103.12905""
""Author"",""Rujia Li"",""Qin Wang"",""Xinrui Zhang"",""Qi Wang"",""David Galindo"",""Yang Xiang""
""producer"",""pdfTeX, Version 3.14159265-2.6-1.40.21 (TeX Live 2020) kpathsea version 6.3.2""
""pdf:docinfo:producer"",""pdfTeX, Version 3.14159265-2.6-1.40.21 (TeX Live 2020) kpathsea version 6.3.2""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""2"",""22"",""16"",""7"",""2"",""0"",""3"",""4"",""13"",""0"",""7"",""22"",""4"",""3"",""0"",""0"",""0"",""0"",""0"",""0""
""Keywords"",""IACR Transactions, TCHES, LaTeX"",""IACR Transactions, TCHES, LaTeX""
""access_permission:modify_annotations"",""true""
""dc:creator"",""Rujia Li"",""Qin Wang"",""Xinrui Zhang"",""Qi Wang"",""David Galindo"",""Yang Xiang""
""dcterms:created"",""2021-03-25T00:33:37Z""
""Last-Modified"",""2021-03-25T00:33:37Z""
""dcterms:modified"",""2021-03-25T00:33:37Z""
""title"",""iacrtans class documentation""
""xmpMM:DocumentID"",""uuid:00a39546-7ae4-41d7-b200-a88200a88dc4""
""Last-Save-Date"",""2021-03-25T00:33:37Z""
""pdf:docinfo:keywords"",""IACR Transactions, TCHES, LaTeX""
""pdf:docinfo:modified"",""2021-03-25T00:33:37Z""
""meta:save-date"",""2021-03-25T00:33:37Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.21 (TeX Live 2020) kpathsea version 6.3.2""
""Content-Length"",""873933""
""Content-Type"",""application/pdf""
""xmp:MetadataDate"",""2021-03-25T00:33:37Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Rujia Li"",""Qin Wang"",""Xinrui Zhang"",""Qi Wang"",""David Galindo"",""Yang Xiang""
""dc:language"",""en""
""pdf:producer"",""pdfTeX, Version 3.14159265-2.6-1.40.21 (TeX Live 2020) kpathsea version 6.3.2""
""dc:subject"",""IACR Transactions, TCHES, LaTeX"",""IACR Transactions, TCHES, LaTeX""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""23""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""1833"",""3347"",""3216"",""2962"",""1642"",""1709"",""1736"",""1541"",""2472"",""2214"",""2332"",""2386"",""1575"",""2895"",""2044"",""2710"",""2291"",""2532"",""1879"",""2509"",""1803"",""998"",""1764""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""IACR Transactions, TCHES, LaTeX"",""IACR Transactions, TCHES, LaTeX""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2021-03-25T00:33:37Z""
";https://scholar.google.ch/scholar?start=40&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2021
1619099138-481;https://scholar.google.ch/scholar?as_ylo=2021&q=oracles+blockchain&hl=fr&as_sdt=0,5;Blockchain based Smart Contracts in Automation of Shipping Ports;PS Sangeerth, KV Lakshmy ; 2021 6th International …, 2021  ieeexplore.ieee.org;;"… blockchain can be extended to non-deterministic smart contracts where data input from oracles,

sensors etc … sensor data errors occurring during real time monitoring with the help of oracle data

and … if it demands any sort of correction then the redaction of the blockchain can be …";;null;null;;;;https://scholar.google.ch/scholar?start=70&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2021
1619099115-433;https://scholar.google.ch/scholar?as_ylo=2021&q=oracles+blockchain&hl=fr&as_sdt=0,5;EASBF: An efficient authentication scheme over blockchain for fog computing-enabled internet of vehicles;MS Eddine, MA Ferrag, O Friha, L Maglaras ; Journal of Information Security …, 2021  Elsevier;;"… Secondly, we provide comprehensive security analysis using the AVISPA tool and random oracle

model to prove that the … A researcher named “Satoshi Nakamoto” has proposed and applied the

idea of the blockchain in 2008 to implement the Bitcoin crypto-currency [34] …";Cité 1 fois;;null;;;;https://scholar.google.ch/scholar?start=20&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2021
1619099129-460;https://scholar.google.ch/scholar?as_ylo=2021&q=oracles+blockchain&hl=fr&as_sdt=0,5;The Application of Blockchain for the Intellectual Property Protection;MF Mbaye ;2021 lup.lub.lu.se;;"… 14 2.3.2 Oracles and IoT 15 … It is only when the network has approved the transactions that it

will be added to the blockchain. This block will be attached to the previous one thanks to a

hash crypto code which corresponds to the code of the previous block …";Les 2 versions;Version HTML;[PDF] lu.se;https://lup.lub.lu.se/student-papers/record/9040926/file/9040927.pdf;"
   

 

   

 

 

 

FACULTY OF LAW 

Lund University 

 

 

Master European Business Law 

JAEN60 Master Thesis 

Term: Spring 2020 

 

 

Marie-Françoise Mbaye 

 

The Application of Blockchain for the 

Intellectual Property Protection 

 

 

Supervisor: Ulrika Wennersten 

 

 

 

 

  



   

 

   

 

  



   

 

   

 

CONTENTS 
 

 

SUMMARY I 

PREFACE II 

ABBREVIATIONS III 

1. INTRODUCTION 1 

1.1 BACKGROUND 1 

1.2 PURPOSE AND RESEARCH QUESTIONS 2 

1.3 METHODOLOGY AND MATERIAL 2 

1.4 DELIMITATION OF THE SUBJECT 2 

1.5 OUTLINES 3 

2. THE REVOLUTION OF BLOCKCHAIN: ADVANTAGES OR ISSUES? 4 

2.1 DESCRIPTION OF THE BLOCKCHAIN TECHNOLOGY 4 

2.1.1 Definition of the blockchain 4 

2.1.2 The characteristics of the blockchain 5 

2.1.3 The different categories of blockchains 9 

2.1.4 An example of a financial transaction with Bitcoin 11 

2.2 BUSINESS APPLICATIONS OF BLOCKCHAIN 11 

2.3 OTHER TECHNOLOGIES RELATED TO THE BLOCKCHAIN 14 

2.3.1 Smart contracts 14 

2.3.2 Oracles and IoT 15 

2.4 THE DISADVANTAGES OF THE BLOCKCHAIN 17 

2.4.1 Technical limits of the blockchain 17 

2.4.2 The expensive costs of the blockchain 18 

2.4.3 The anonymity of the network 18 

3. BLOCKCHAIN FOR THE PROTECTION OF INTELLECTUAL PROPERTY RIGHTS 20 

3.1 THE EUROPEAN IP LEGAL FRAMEWORK AND ITS CHALLENGES 20 

3.2 THE BLOCKCHAIN IN THE SERVICE OF IP 23 

3.2.1 Blockchain as an evidence of the ownership of IP rights 23 

3.2.2 Blockchain for the support and management of IP contracts with the smart 

contracts 36 

3.2.3 Blockchain as an enforcement tool of IP rights in the fight against counterfeit 44 



   

 

   

 

4. CONCLUSION 48 

BIBLIOGRAPHY 51 

1. PRIMARY SOURCES 51 

1.2 EU laws (Treaties, Regulations and Directives) 51 

1.2 National Laws and Acts 51 

2. SECONDARY SOURCES 52 

2.1 Articles 52 

2.2 Books 53 

2.3 Conferences 53 

2.4 EU communications and reports 53 

2.5 Thesis and researches papers 55 

2.6 Websites and Blogs 55 

2.7 White papers, reports and guides 57 

 



   

 

 i 

Summary 
 

With a far going protection of IP rights, the EU aims to protect the assets of companies which 

invested in innovative products. If the EU framework provides a far going mechanism of 

protection of IP rights, the complexity and the cost of this mechanism have been a barrier to the 

access of IP rights.  In additional to these structural issues, the digital revolution introduced 

new challenges for the rightsholders. Blockchain can provide solutions to the protection of 

intellectual property rights. It offers the possibility for the rightsholder to register an IP right to 

the relevant authorities, to prove the ownership of a right, to manage these rights and collected 

the licensee fees attached to them, and lastly, to fight against counterfeit goods and contents. 

Blockchain can also be used by the other stakeholders who can control the origin of the good, 

its authenticity, but also verify it its own creation does not infringed any rights. In a digital 

context where these rights are fragilized, blockchain seems to be the perfect digital solution for 

extending the scope of protection of IP rights.  

But each solution has a price. Some of the factors that explain the lack of investment in the 

blockchain technology from public and private investors are the impossibility of identifying the 

members of a public network in the event of infringement of a right, the high costs that this 

technology represents, the technical knowledge that is required to use such a technology, and 

finally, the absence of a legal framework.  

Most of the issues in the blockchain are linked to the immaturity of the technology. For this 

reason, it is important, to give time to the technology to maturate before introducing rules which 

prohibit blockchains totally.  So, if blockchain can be used the protection of IP rights, a theorical 

framework that provides a better understanding of the technology, and the potential applications 

and challenged it can raise is necessary. A better understanding in the area will contribute to 

the creation of a new legislation, and therefore, to new innovative tools for the protection of IP 

rights.1  

 
1
 Jeanne Pia Mifsud Bonnici, Melania Tudorica and Joseph A Cannataci, ‘The European Legal Framework on 

Electronic Evidence: Complex and in Need of Reform’ in MA Biasiotti and others, Handling and Exchanging 

Electronic Evidence across Europe (1st edn, Springer 2018), 196 



   

 

 ii 

Preface 
 

The wise Cicely Tyson is certainly right when she said that “challenges make you discover 

things about yourself that you never really knew. They're what make the instrument stretch — 

what makes you go beyond the norm."" 

 

These last years have been the most challenging period of my life. I have crossed several 

countries, learned different cultures, follow an intensive program, while trying to become an 

accomplished professional and women. The word “challenges” seems to be appropriate for 

describing all the emotions, experiences I have been trough.  

 

Despite this, I do not have any regrets. These challenges are part of myself. They reflect the 

battles that I fought with my soldiers in order arrive where I am at this day. 

 

Today, I would like to thank you, my soldiers, for always being on my side, even during the 

worst wars.  

 

Thank you to my beloved mom Absatou, my sisters Marie-Antoinette and Dorianne, JĂŠrĂ´me, 

Kanny, Amina, Becaye, Patricia, Ibrahima, and my family for being my constant source of 

motivation.  

 

Thank you to my friends Janis, Willy, Dianna-Laure, Koralie, Louise, Margaux, Erika, Claudia, 

Emily, Zhengmin, Adam, Alexia, Fanny, Martina, Nora, Violeta, Meeri, Unali, Sani and Babs 

who have always trusted me.  

 

Thank you to all my teachers and my supervisor Ulrika Wennersten for being my mentors in 

my journey.  

 

 

 

 

 

  



   

 

 iii 

Abbreviations 
 

AI: Artificial Intelligence 

DLT: Distributed Ledger Technologies  

eIDAS: electronic Identification, Authentication and Trust Services Regulation 

EPO: European Patent Office  

EU: European Union 

EUIPO: European Union Intellectual Property Office 

IoT: Internet of Things  

IP: Intellectual Property 

LC: Letter of Credit  

P2P: Peer to Peer 

MS: Member State 

SMEs: Small and Medium Enterprises  

TFEU: Treaty on the Functioning of the European Union  



   

 

 1 

1. Introduction  
 

1.1 Background 
 

With all its crises, the 21st century represents an age of uncertainty for economic actors but also 

a period of opportunities for the companies and the society.2 Among them, the financial crisis 

of 2007-2008 is one of the most important events which has a permanent impact on the industry. 

This crisis has mainly brought out questions regarding the capacity of the financial institutions 

protected by the States to shield the interests of the individuals. But if the financial system failed 

in their mission, how to ensure the protection of the private assets?  As a response to this new 

challenge, a mysterious individual named Satoshi Nakamato wrote the blockchain’s White 

Paper in 2008.3 Although the author's name is fictitious, the relevance of this book is evident, 

and its content led to the creation of blockchain technology. The mechanism described in it has 

been introduced as a new way to transfer financial data without relying on a centralized 

government, such as a bank or the States, which have failed to protect the interest of individuals.  

While this technology has mainly been developed for the financial sector, its application has 

been extended in several areas. Thus, despite its tragic economic effects, the financial crisis 

also led to the creation of a new technology4. 

The potential application of this technology and its creative nature can promote new business 

opportunities.  Blockchain can therefore be used in various sectors, such as finance, insurance, 

and more surprisingly, also for the Intellectual Property (IP) rights.  

The objective of IP rights is to encourage companies and people to develop new technologies 

while ensuring that they can benefit from this technology. Using blockchain for extending the 

method protection of IP rights can participate to the economic growth within the European 

Union (EU). However, we must determine if such application of the blockchain is possible or 

even desirable from the legal and technical perspective.  

 
2
 Paul Burns, Entrepreneurship and Small Business: Start-up, Growth and Maturity (4th edn, Palgrave, 2016), 

pages 3 to4.  
3
 Satoshi Nakamoto, Bitcoin: A Peer-to-Peer Electronic Cash System (Bitcoin.org, 2008) 

<https://bitcoin.org/bitcoin.pdf> accessed 4 May 2020. 
4
 Ahmed Afif Monrat, and others ‘A Survey of Blockchain From the Perspectives of Applications, Challenges, 

and Opportunities’, (2019) 7 IEEE, page 117143. 



   

 

 2 

1.2 Purpose and Research questions 
 

The objective of this thesis is to assess the benefits and challenges that blockchain can raised 

in the current EU intellectual property legal framework. This assessment will help to determine 

the impact that blockchain technology can have on the protection of EU IP rights. However, 

this thesis does not aim to offer a proposal for a new IP or blockchain laws. The results of this 

assessments can help IP rights holders, investors, the legislator or lawyers to explore the 

impacts of this technology on the IP rights and its legal framework before to make an 

amendment of the current system or to develop a blockchain. Based on this information, 

blockchains stakeholders can determine if the development of blockchain for the protection of 

IP rights is desirable or require to adopt a legislative act.  

 

1.3 Methodology and Material 
 

To assess the impact of the use of blockchain for the protection of IP rights, this thesis will 

provide concrete examples of the application of the blockchain at each stage of the lifecycle of 

IP rights. Consequently, we will analyze the application of blockchain for the creation of IP 

rights, during its development, and to finish, during its defense. For each example of application 

provided, we will assess the benefits of blockchain for the IP protection, but also the legal issues 

it can raise. 

I will use the applicable EU rules (decisions of the Court of Justice, Directives, Regulations, 

Treaties) to assess the legality of the blockchain’s application.  As a tool of interpretation of 

these legislative acts, I will use all scientific researchers’ papers, books websites, 

communication of the EU institutions, and international legislations that are relevant for the 

various analyses.  

Furthermore, due to the digital nature of the technology and the philosophy attached to it, a lot 

of technical information is described in an open source website. For these reasons, articles 

published in a blog or website related to the blockchain will be also take into account.  

 

1.4 Delimitation of the subject 
 

While this essay deals with the application of blockchain for the protection of IP rights, this 

technology has several impacts on various areas of law. Due to the restrictive time and space 



   

 

 3 

of this research, this thesis will not develop all the legal issues related to the application of 

blockchain in the IP sector. Only the most relevant areas for our discussion will be addressed.  

This analysis will focus on the applicable EU law, and therefore will exclude the specific rules 

applicable within the Member States, or in international law.  

The objective of this paper is not to present all the IP rights within the EU and their scope of 

protection, but it will rather determine how their creation, management and enforcement can be 

improved with a blockchain.  

This essay aims to describe how blockchain can be used for the protection of IP rights. The 

question of the protection of blockchains, and its patentability under EU IP law will not be 

addressed in this paper.  

 

1.5 Outlines 
 

To assess the impact of the use of blockchains for the protection of EU IP rights, this thesis will 

describe the technology of the blockchain and related technologies (2), before to analyze how 

blockchains can contribute to IP protection (3). The last section will conclude this thesis (4).  

 

  



   

 

 4 

2. The revolution of blockchain: 
advantages or issues?  

 

To understand the opportunities and challenges that occur regarding the blockchain technology 

for the IP legal framework, it is necessary to describe at first the function of this invention from 

a technical perspective (2.1). Secondly, we will describe how blockchain is a source of 

impulsion for the creation of new business opportunities (2.2) and for the development of other 

digital systems (2.3). To conclude this section, we will outline some of the criticism surrounding 

blockchains (2.4).  

 

2.1 Description of the blockchain technology 
 

After defining the technology of the blockchain (2.1.1), we will develop their characteristics 

(2.1.2), describe the different types of blockchains (2.1.3), how they can be used (2.1.4), and 

their impacts in different industries (2.1.5).   

 

2.1.1 Definition of the blockchain  
 

A blockchain, or Distributed Ledger Technologies (DLT), can be described as a decentralized 

digital database5 which allows individuals to store data in a sequence of blocks6 and execute 

some operations without the participation of a central government.7 The data stored in one block 

are linked together with other blocks. The connected blocks form a chain, hence the name 

‘blockchain’.8 In a blockchain, the transactions are validated by several entities and not only by 

a unique organization, as it can be the case in a centralized system. It is only if there is a 

consensus among the blockchain’s community that the operations will be stored in the blocks. 

Through these elements, blockchain can be defined as “a decentralized database containing 

 
5
 Michèle Finck, ‘Blockchain and the General Data Protection Regulation: Can distributed ledgers be squared with 

European data protection law?’ (Study, Panel for the Future of Science and Technology STOA, July 2019), page 

1.  
6
 Ahmed Afif Monrat, and others ‘A Survey of Blockchain From the Perspectives of Applications, Challenges, 

and Opportunities’, (2019) 7 IEEE, page 117138. 
7
 Pascal Asselot, ‘In a Nutshell: Blockchain and IP’ (European IP Helpdesk), <http://iprhelpdesk.eu/ip-

highlights/ip-special-blockchain/blockchain-in-a-nutshell> accessed 23 April 2020.  
8
 Ahmed Afif Monrat, and others ‘A Survey of Blockchain From the Perspectives of Applications, Challenges, 

and Opportunities’, (2019) 7 IEEE, page 117138. 



   

 

 5 

sequential, cryptographically linked blocks of digitally signed asset transactions, governed by 

a consensus model”.9 

 

2.1.2  The characteristics of the blockchain 
 

The innovative character of the blockchain is due to 4 essentials elements. The first 

characteristic of blockchain is the decentralized nature of the system. In the blockchain, 

contrary to centralized systems (such as banks, in which one central entity is responsible for the 

maintenance of the entire system), the system is maintained by several entities. The data is 

incorporated, maintained and monitored by a network of users connected to the systems with a 

computer.10 These users are the peers and form a peer to peer network (P2P).11 Each peer is 

connected to the system thanks to a computer, also called a node.12 Peers have the responsibility 

to control and incorporate the data in the block. As soon as a sufficient number of peers defined 

in advance have verified the information or the transaction, it can be added to the block. A copy 

of the blockchain is distributed to all the nodes of the networks.13 Based on this description, it 

appears that the decentralized characteristics of the blockchain emanates from the 

decentralization of the actors of the chains but also of the decentralization of the storage of the 

data itself. This system brings several advantages. The first advantage is link to the fact that 

each node contains a copy of the blockchain. If the information is stored in different nodes 

instead of a central place, the server will always have a copy of the data in several nodes. So, 

even in the case of a cyberattack or destruction of the storage facilities, the data will always be 

preserved.  The second advantage of this system is that it cannot be corrupted. This property is 

linked to the fact that it does not rely on a central authority, but rather on an entire network.14 

Subsequently, blockchain is more than a new innovation. Blockchain has created a new path 

 
9
 Karim Sultan and others, ‘Conceptualizing blockchains: characteristics & applications’ (11th IADIS 

International Conference on Information Systems, Lisbon, 14-16 April 2018), page 54.  
10

 Nathan Fulmer, ‘Exploring the Legal Issues of Blockchain Applications’, (2019) 52(1) Akron Law Review, 

pages 166 to 167.   
11

 Stephen Kilcommins, ‘Blockchain Basics – A deeper look’, (Medium, 21 February 2019), 

<https://medium.com/@GECKOGovernance/blockchain-basics-a-deeper-look-c34acd186ad2> accessed 23 April 

2020.  
12

 Ibid. 
13

 Ibid. 
14

 Florent Loriaux, ‘L’utilisation de la blockchain en propriété intellectuelle est-elle une évolution souhaitable ?’ 

(Master Thesis, FacultĂŠ de Droit et de Criminologie, UniversitĂŠ Catholique de Louvain, 2019), page 6.  



   

 

 6 

for individuals to execute operations and, share data by cooperating in a network without a 

central authority in which they would have to trust.15  

 

This first characteristic is also linked to the second essential element of the blockchain: the 

proof-of-work of consensus. In addition to the creation of a decentralized system, blockchain 

also creates an auto-regulated structure. Indeed, in the absence of a centralized authority which 

can verify the data stored and regulate the system if needed, the blockchains call upon the 

different users from the network to regulate the system. As described previously, when a 

transaction is requested by two users, the data is sent to all the nodes. Each data that need to be 

stored in the blockchain is transformed into a cryptographic code thanks to a hashing algorithm. 

This hashing system aims to store the data in a reduced number of bits. Most of the blockchains 

use the SHA-256 hashing algorithm, which contains 64 characters and takes 256 bits in 

memory16. Although the data was sent to the nodes to be registered in the blockchain, the 

information has to be verified by the networks for being executed.17 As outlined previously, 

the blockchain aimed to offer a decentralized mechanism which the users can trust. Since the 

protection of the integrity of the blockchains cannot be made by a central authority,18 it has to 

be realized by a decentralized mechanism on which individual can trust because it cannot be 

corrupted. In its White Paper,19 Nakamoto introduced the idea of a consensus mechanism.20 

With this process, the operations are not validated by a central authority anymore, but rather 

agreed by the network thanks to a consensus.  

In practice, not the entire network has to validate the operation.  A group of specialized users, 

called miners, verify the information sent by the two parties. It is only when the cryptographed 

 
15

 Nathan Fulmer, ‘Exploring the Legal Issues of Blockchain Applications’, (2019) 52(1) Akron Law Review, 

page 169.  
16

 Stephen Kilcommins, ‘Blockchain Basics – A deeper look’, (Medium, 21 February 2019), 

<https://medium.com/@GECKOGovernance/blockchain-basics-a-deeper-look-c34acd186ad2> accessed 23 April 

2020.  
17

 Nathan Fulmer, ‘Exploring the Legal Issues of Blockchain Applications’, (2019) 52(1) Akron Law Review, 

page 168.  
18

 Stephen Kilcommins, ‘Blockchain Basics – A deeper look’, (Medium, 21 February 2019), 

<https://medium.com/@GECKOGovernance/blockchain-basics-a-deeper-look-c34acd186ad2> accessed 23 April 

2020.  
19

 Satoshi Nakamoto, Bitcoin: A Peer-to-Peer Electronic Cash System (Bitcoin.org, 2008) 

<https://bitcoin.org/bitcoin.pdf> accessed 4 May 2020.  
20

 Ibid, pages 3 and 8.  



   

 

 7 

code is verified that they will be included in the block, and the operation will be executed.21 

Proof-of-work, therefore, refers to the fact that miners have to solve a cryptographic problem 

to validate an operation.22 Consequently, the operation needs to be controlled by the blockchain 

community in order to be validated. The community recognized the algorithm verified by the 

miners as valid, and therefore constitutes a consensus. This code recognized as legitimate 

becomes “the algorithm consensus”.23 Once this code is validated by the network, it can be 

added in the block but cannot be replaced. Consequently, a central authority, such as a bank, 

does not have the possibility to modify, change, or corrupt the information sent by the users. 

The question remains how miners are incentivized to verify the code set by the users. What are 

the interests of the miners in this operation?  

In most of the public blockchains, miners are  incentivized to verify and valid the code, and 

subsequently the operations, with the crypto-currencies, also called “tokens”.24 The miner who 

succeeds to solve the mathematical problem that consist to find the new block that need to be 

added to the chain is awarded with tokens.  This new block contains a piece of the transaction 

code that needs to be stored in the blockchain. So, such money is delivered only if they have 

found the new block that will be added to the chain. Each time a miner is the first one to control 

and insert a block in the chain, he/she receives a token. Thanks to this remuneration system, 

miners are encouraged to compete in order to find a new code to crypt.25  

 

The third characteristic of the blockchain is that the stored information is permanent and 

tamper-proof.26 Each information incorporated in a block cannot be replaced because the 

blockchain is kept in all the nodes of the community. However, the system is not infallible 

because it is possible to change the data stored.27 To modify the information, the person has to 

 
21

 Kevin Werbach, ‘Trust, but verify: why the blockchain needs the law’, (2018) 33(489) Berkeley Technology 

Law Journal, pages 503 to 504.  
22

 Nathan Fulmer, ‘Exploring the Legal Issues of Blockchain Applications’, (2019) 52(1) Akron Law Review, 

page 169.  
23

 Karim Sultan and others, ‘Conceptualizing blockchains: characteristics & applications’ (11th IADIS 

International Conference on Information Systems, Lisbon, 14-16 April 2018), page 52.  
24

 Nathan Fulmer, ‘Exploring the Legal Issues of Blockchain Applications’, (2019) 52(1) Akron Law Review, 

page 169. 
25

 Nathan Fulmer, ‘Exploring the Legal Issues of Blockchain Applications’, (2019) 52(1) Akron Law Review, 

page 168.  
26

 Karim Sultan and others, ‘Conceptualizing blockchains: characteristics & applications’ (11th IADIS 

International Conference on Information Systems, Lisbon, 14-16 April 2018), page 53.  
27

 Nathan Fulmer, ‘Exploring the Legal Issues of Blockchain Applications’, (2019) 52(1) Akron Law Review, 



   

 

 8 

remove all the information from all the nodes. Even if such operation requires lot of resources, 

it is possible to remove an information by accessing all the computers of all the users at the 

same time.  

The stored information is also permanent because each block is composed of a piece of the hash 

code from the pervious,28 creating therefore an immutable chain of information.29 If one code 

is changed it will also destroy the links between the blocks. So, if all the blocks are connected 

together with the hashing code of the previous block, the only way to alter a block is to fix all 

the “cryptographic links in the chain”30. However, such type of modification is only possible if 

there is only one copy of the blockchain in a single node, and therefore is not applicable to a 

P2P network.31  

 

The last characteristic of the blockchain is its transparency and the auditability of the 

information. Everyone can get access and control the information stored in the blockchain.32 

The advantage of such a system is that the information cannot be corrupted because all the 

information can be retraced in the system.  

 

Through this description of the different characteristics of the technology, blockchain 

represents more than a simple data center. It creates a new system where individuals do not 

have to trust in a central entity but in the code.33  

 

  

 
page 170.  
28

 Stephen Kilcommins, ‘Blockchain Basics – A deeper look’, (Medium, 21 February 2019), 

<https://medium.com/@GECKOGovernance/blockchain-basics-a-deeper-look-c34acd186ad2> accessed 23 April 

2020. 
29

 Kevin Werbach, ‘Trust, but verify: why the blockchain needs the law’, (2018) 33(489) Berkeley Technology 

Law Journal, page 505. 
30

 Stephen Kilcommins, ‘Blockchain Basics – A deeper look’, (Medium, 21 February 2019), 

<https://medium.com/@GECKOGovernance/blockchain-basics-a-deeper-look-c34acd186ad2> accessed 23 April 

2020.  
31

 Ibid. 
32

 Valentina Gatteschi and others, ‘Blockchain and Smart Contracts for Insurance: Is the Technology Mature 

Enough?’, (2018) 10(2) Future Internet, page 4.  
33

 Jean-Maxime Rivière, ‘Blockchain technology and IP – investigating benefits and acceptance in governments 

and legislations’ (2018) 3(1) Junior Management Science, page 6. 



   

 

 9 

2.1.3  The different categories of blockchains 
 

In addition to the properties described previously, blockchains can also be classified according 

to the publicity or privacy of their network.34  A public blockchain is written on an open source 

software35 publicly available.36 The blockchain does not have an owner.37 Thereby, all the 

information is accessible to all individuals, everybody is free to join the network, and maintain 

the blockchain without obtaining the authorization of a centralized authority.38 In the opposite, 

private or “permissioned” blockchains are not publicly available but are rather run on a private 

software owned by an entity, a company, or an individual.39 Only users selected by the owner 

of the blockchain, also called “consortium”, can join the network and participate in the 

maintenance of the blockchain. In this case, only a restricted number of users can read or write 

in the blockchain. 

 

Beside the creation of a classification within blockchains, each category provides some 

advantages. Even if private blockchains do not have all the characteristics of traditional public 

blockchains, they have some advantages.40  

Private blockchains have been created meanly by banks, big organizations or companies who 

want to benefit from the blockchains advantages (its security, the decentralized storage of the 

data, the immutability of the operation…),41  without necessarily adhering to Nakamoto’s 

philosophy of a decentralized data system which aims to remove the use of a middleman 

 
34

 Karim Sultan and others, ‘Conceptualizing blockchains: characteristics & applications’ (11th IADIS 

International Conference on Information Systems, Lisbon, 14-16 April 2018), page 53.  
35

 Alec Liu, ‘Who’s Building Bitcoin? An Inside Look at Bitcoin’s Open Source Development’, 

(MOTHERBOARD, 7 May 2013), <https://www.vice.com/en_us/article/9aa4ae/whos-building-bitcoin-an-inside-

look-at-bitcoins-open-source-development > accessed 4 May 2020.   
36

 Karim Sultan and others, ‘Conceptualizing blockchains: characteristics & applications’ (11th IADIS 

International Conference on Information Systems, Lisbon, 14-16 April 2018), page 53.  
37

 Ibid.  
38

 Reynier Burnaby Lautier, ‘Intellectual Property Protection Strategies for Blockchain Technology Applications’ 

(Master Thesis, Delft University of Technology, 2018), page 55.  
39

 Karim Sultan and others, ‘Conceptualizing blockchains: characteristics & applications’ (11th IADIS 

International Conference on Information Systems, Lisbon, 14-16 April 2018), page 53.  
40

 Florent Loriaux, ‘L’utilisation de la blockchain en propriété intellectuelle est-elle une évolution souhaitable ?’ 

(Master Thesis, FacultĂŠ de Droit et de Criminologie, UniversitĂŠ Catholique de Louvain, 2019), page 8.  
41

 Shermin Voshmgir, Valentin Kalinov, Blockchain: A Beginners Guide, (Blockchain Hub, 30 September 2017) 

<https://s3.eu-west-2.amazonaws.com/blockchainhub.media/Blockchain+Technology+Intro.pdf> accessed 4 May 

2020, page 14.  



   

 

 10 

completely.42  In a private blockchain, all users need to be selected by the organization before 

joining the community. With this selection the owner can identify all the users of the 

blockchain.43 This selection offers two advantages it limits the use of the system by undesirable 

individuals (such as criminals or terrorists who can used the blockchain anonymously); and 

secondly, it is easier to track the activity of the member, and therefore to do the adequate 

modification in the system in case of mistakes.44 Each transaction sent to the system has to been 

validated by a restrictive consortium.45 Consequently, illegal, suspicious, or operations 

considered unauthorized by this consortium can be rejected by the consortium.46 Lastly, since 

the operations are only validated by a restrictive number of users and only authorized users can 

join the community, the verification of a transaction is simplified, and therefore shorter.47 As a 

result, private blockchains also offer a faster solution than public blockchains.48  

 

When it comes to public blockchains, they offer the possibility for individuals to create a 

transparent network accessible to all individuals.49 In addition, all operations can be requested 

by the users, even those who are illegal since their validation does not depend on their legality 

but rather on the validity of the code.  

To conclude this section, beyond the technical differences that distinguish private and public 

blockchains, the real debate that oppose them are more ideological. Each model askes in 

essence whether we want to be regulated by an ""anonymous and decentralized” or by a 

“centralized” society.  

 

 
42

 Ibid, pages 5 to 10.  
43

 Ahmed Afif Monrat, and others ‘A Survey of Blockchain From the Perspectives of Applications, Challenges, 

and Opportunities’, (2019) 7 IEEE, page 117139. 
44

 Shermin Voshmgir, Valentin Kalinov, Blockchain: A Beginners Guide, (Blockchain Hub, 30 September 2017) 

<https://s3.eu-west-2.amazonaws.com/blockchainhub.media/Blockchain+Technology+Intro.pdf> accessed 4 May 

2020, page 14.  
45

 Ibid.  
46

 Ibid. 
47

 Valentina Gatteschi and others, ‘Blockchain and Smart Contracts for Insurance: Is the Technology Mature 

Enough?’, (2018) 10(2) Future Internet, page 25.  
48

 Florent Loriaux, ‘L’utilisation de la blockchain en propriété intellectuelle est-elle une évolution souhaitable ?’ 

(Master Thesis, FacultĂŠ de Droit et de Criminologie, UniversitĂŠ Catholique de Louvain, 2019), page 8.  
49

 Shermin Voshmgir, Valentin Kalinov, Blockchain: A Beginners Guide, (Blockchain Hub, 30 September 2017) 

<https://s3.eu-west-2.amazonaws.com/blockchainhub.media/Blockchain+Technology+Intro.pdf> accessed 4 May 

2020, pages 13 to 14.  



   

 

 11 

2.1.4  An example of a financial transaction with Bitcoin 
 

To fully understand the blockchain’s mechanism, its advantages and the issues it can raise, this 

part will illustrate a financial transaction made with Bitcoin. Bitcoin is the first public 

blockchain in the world. It has been created in 2008 by Satoshi Nakamoto, therefore, it also 

respects its philosophy of a digital society.50 To illustrate the functioning of this ledger, we will 

describe a financial transaction between two individuals, A and B, realized on the Bitcoin 

blockchain. If A decide to transfer money to B, A has to send this money on B’s account by 

entering B’s public key. To verify B’s/its identity, B has to enter its private key which must 

match the public key recei";"""date"",""2021-02-23T00:34:46Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.7""
""xmp:CreatorTool"",""Microsoft Word""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dc:creator"",""Marie-Françoise MBaye""
""language"",""en""
""dcterms:created"",""2021-02-23T00:34:46Z""
""Last-Modified"",""2021-02-23T00:34:46Z""
""dcterms:modified"",""2021-02-23T00:34:46Z""
""dc:format"",""application/pdf; version=1.7""
""xmpMM:DocumentID"",""uuid:ED0E9CB4-7E40-457B-9AC1-FE4C541D153C""
""Last-Save-Date"",""2021-02-23T00:34:46Z""
""pdf:docinfo:creator_tool"",""Microsoft Word""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2021-02-23T00:34:46Z""
""meta:save-date"",""2021-02-23T00:34:46Z""
""pdf:encrypted"",""false""
""xmp:CreateDate"",""2021-02-23T00:34:46Z""
""modified"",""2021-02-23T00:34:46Z""
""Content-Length"",""685272""
""pdf:hasMarkedContent"",""true""
""Content-Type"",""application/pdf""
""xmp:ModifyDate"",""2021-02-23T00:34:46Z""
""pdf:docinfo:creator"",""Marie-Françoise MBaye""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Marie-Françoise MBaye""
""dc:language"",""en-US""
""meta:author"",""Marie-Françoise MBaye""
""meta:creation-date"",""2021-02-23T00:34:46Z""
""created"",""2021-02-23T00:34:46Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""64""
""Creation-Date"",""2021-02-23T00:34:46Z""
""resourceName"",""9040927.pdf""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""245"",""10"",""1237"",""359"",""2417"",""1364"",""467"",""2445"",""2279"",""1104"",""2360"",""2724"",""2692"",""2981"",""2235"",""2983"",""2697"",""2461"",""2920"",""2853"",""2280"",""2143"",""2552"",""2398"",""2417"",""2459"",""2568"",""3120"",""2819"",""2169"",""3111"",""2867"",""2548"",""2517"",""2737"",""2995"",""3001"",""3066"",""3164"",""2532"",""3151"",""3195"",""2683"",""2872"",""2928"",""3159"",""2806"",""2519"",""2814"",""2626"",""2186"",""2592"",""2960"",""1896"",""2692"",""2623"",""506"",""1728"",""2105"",""1856"",""2060"",""2021"",""2295"",""1624""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""Author"",""Marie-Françoise MBaye""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2021-02-23T00:34:46Z""
";https://scholar.google.ch/scholar?start=50&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2021
1619099107-413;https://scholar.google.ch/scholar?as_ylo=2021&q=oracles+blockchain&hl=fr&as_sdt=0,5;Demystifying Pythia: A Survey of ChainLink Oracles Usage on Ethereum;M Kaleem, W Shi ; arXiv preprint arXiv:2101.06781, 2021  arxiv.org;;"… Chain.Link, https://docs.chain.link/ docs/developer-communications (August 2020)

7. Egberts, A.: The oracle problem-an analysis of how blockchain oracles undermine

the advantages of decentralized ledger systems (2017) Page 9 …";Cité 1 fois;;[PDF] arxiv.org;https://arxiv.org/pdf/2101.06781;"
Demystifying Pythia: A Survey of ChainLink
Oracles Usage on Ethereum

Mudabbir Kaleem and Weidong Shi

University of Houston, Texas, USA
{mkaleem,wshi3}@uh.edu

Abstract. Smart contracts are dependent on oracle systems for their
adoption and usability. We perform an empirical study of oracle systems’
usage trends and adoption metrics to provide better insight into the
health of the smart contract ecosystem. We collect ChainLink usage data
on the Ethereum network using a modified Ethereum client and running
a full node. We analyze the collected data and present our findings and
insights surrounding the usage trends, adoption metrics, oracle pricing
and service quality associated with ChainLink on the Ethereum network.

Keywords: Oracles ¡ DeFi ¡ Smart contracts ¡ Blockchain ¡ Ethereum ¡
ChainLink.

1 Introduction

Since the launch of the Ethereum [3] network in 2015, smart contracts [14] have
become one of the central features of blockchain-based systems. Although ini-
tially limited in usage to token control and on-chain data access, smart con-
tracts today are rapidly expanding their domain of applications [10] due to the
availability of oracles [2]. Oracles provide the interface between the blockchain’s
isolated execution environment and external off-chain data sources, enabling
smart contracts to retrieve and post real-world data and events. Consequently,
the potential utility and future mass adoption of smart contract platforms is
inextricably tied to the oracle service providers within the ecosystem.

Bearing that in mind, the motivation of this study was to survey oracle usage
in the smart contract ecosystem. Currently, different projects like ChainLink [8],
Provable [13] and Augur [12] are offering third party oracle services to smart
contracts. These projects have adapted a decentralized approach for collecting
and aggregating oracle data, thereby addressing ”the oracle problem” [7] of hav-
ing centralized point of failures in blockchain environments. For our survey, we
target ChainLink, which captures the majority share of the oracle middleware
market at the time of writing. Although ChainLink provides its oracle services
over multiple chains, we concern our study with ChainLink oracle usage on
Ethereum since it is the most widely adopted smart contract platform at this
time. We believe that ChainLink oracle usage on Ethereum represents the sig-
nificant bulk of oracle traffic on smart contract platforms. The oracle traffic

ar
X

iv
:2

10
1.

06
78

1v
1 

 [
cs

.D
C

] 
 1

7 
Ja

n 
20

21



2 M. Kaleem and W. Shi

statistics and trends provided by this survey can be used to gauge the adoption
and health of the smart contract ecosystem in general. At the time of writing,
we are not aware of any other formal study providing oracle usage insights in
the smart contract environment.

2 ChainLink Overview

ChainLink is an oracle service provider for smart contracts that is currently live
on three platforms: Ethereum, Binance Chain and the Matic Network. ChainLink
went live in May 2019 and is currently the most popular oracle service provider
for smart contracts. ChainLink maintains a decentralized oracle network and
aggregates data from multiple oracle nodes on the network to provide data feeds
that do not rely on a single oracle node or data source[4]. ChainLink employs
an ERC-20 and ERC-677 complaint token called LINK which is used by oracle
consumers to pay the oracle nodes for the data provision. ChainLink currently
provides three features for consumer smart contracts on the Ethereum mainnet.

Price Feeds: are a ChainLink feature to provide different market prices and
conversion rates data in the blockchain environment for usage by smart contracts.
ChainLink achieves this by having a decentralized price feed for each of these
data points, which is fed price data through multiple oracle nodes using different
sources. This is implemented by having an aggregator contract for each feed
on chain which is fed data by multiple oracle nodes through their interface
contracts. The feed aggregator contract then aggregates all the nodes’ answers
to provide a final answer to any consumer contract via public Solidity functions.
The ChainLink documentation lists the aggregator contract addresses for the
available price feeds[5]. The price feeds are sponsored by various projects and
currently available for public usage without any LINK token charge.

External APIs: is a ChainLink feature that allows smart contracts in the
blockchain environment to perform external API calls through ChainLink oracle
nodes. These API calls can be HTTP Get Requests on the web or other APIs
provided by the oracle node for different use cases. ChainLink API requests are
currently handled 1:1 by an oracle and ChainLink currently does not provide de-
centralization benefits by default for API calls although a user might implement
it on their own. The consumers of ChainLink’s API feature have to pay their
request servicing oracle node in LINK tokens for the service. The cost varies
depending on the node and the nature of the request but is around 0.1 LINK on
average and the highest being 1 LINK at the time of writing. Commonly used
public API endpoints are available as ”jobs” in ChainLink which allows user to
only specify the job ID and not having to specify the URL, format etc. This
makes the consumer side code more succinct and the implementation easier.



Demystifying Pythia: A Survey of ChainLink Oracles Usage on Ethereum 3

Verifiable Random Numbers (VRF): is a ChainLink feature to provide
verifiable random number generation functionality on-chain. ChainLink achieves
this by having off-chain random number verifier contracts which verify the ran-
domness of the number generated by an oracle node in response to a consumer
request. VRF feature allows for provable random numbers, which protects the
consumer from attacks even if the node servicing the request has been compro-
mised.

3 Study Design

3.1 Data Collection

For both the Price Feeds and the External APIs we collected data since the
launch of ChainLink mainnet in May 2019 up til the end of October 2020
(Ethereum block 11167816). The VRF feature data was not collected and is
not part of this study since it only went live in the end of October 2020 and the
resulting data was insufficient for a formal study.

Modified Ethereum Client: For collecting the Price Feed usage data, we
looked at the price feed addresses available on the ChainLink website [5]. There
were 88 price feed addresses at the time of writing which are proxy aggregator
addresses. ChainLink has also, since its launch, made upgrades to the aggrega-
tor contracts. The current version of aggregators are labeled as v3. We used the
wayback machine web archives [15] to retrieve old aggregator addresses and had
a total of 169 addresses for our study (88 v3, 80 v2, 1 v1). All these addresses are
provided for reference in Appendix A. The ChainLink team also later provided
us with historical addresses which we used to verify our list. For capturing the
price feed data we could not use the Web3 API since all price feed consumer re-
quests were direct call or ”internal transactions”. Hence we modified the Golang
Ethereum client code to log data when internal function calls were made to these
169 addresses. We captured the block number, calling address, opcode, value and
input data parameters for these internal calls to these addresses and stored them
in a local MySQL database.

Ethereum Full Node and Web3: For collecting data related to ChainLink
API usage we used the Web3 API with an Ethereum full node that we ran locally.
ChainLink implements the API feature using the CallAndTransfer() functional-
ity of the ERC-677 token standard. Every time a consumer requests an oracle,
it generates an ChainlinkRequest event and sends the LINK to the oracle node
along with data describing the API to fetch, the job ID, the format of the out-
put, the callback address and function which the oracle must respond and other
data if required. The oracle node interface contract generates an OracleRequest
event upon receiving the LINK and data and the external node listens to this
event. It responds with the result after some time and makes a transaction to
the callback function with the data response. The consumer contract then raises



4 M. Kaleem and W. Shi

a ChainlinkFulfilled event. We use the Web3 APIs to capture these events and
extract the required data which includes: the block number of the request, the
requesting address, the oracle node requested, the job ID specified, the callback
function and address provided, the LINK token paid, the ChainLink request ID,
the request transactions hash, any additional data provided, the response block
number, the response and the response transaction hash. We store the results in
our local MySQL database for all such oracle service request response cycles on
ChainLink.

We used Etherscan [9] to verify various samples of our collected data to
ensure that our data collection process was performed correctly.

3.2 Study Objectives

The study was aimed at providing insights into the usage of ChainLink oracles
on Ethereum. For this purpose we looked at the following five aspects:

– Oracle usage trends and demographics
– Oracle Adaption
– Oracle Pricing
– Oracle Servicing Delays

4 Results

4.1 Usage Trends and Demographics

After the data collection was completed and the required data was populated
into our MySQL server, we had quantitative information summarized in Ta-
ble 1. A total of 2,717,049 API requests were made to Oracles during the entire
duration of our study and in total 2,409,074 price feed calls were made to Chain-
Link’s public price feed contracts for fetching the market place data. Although
the numbers appear encouraging at first sight, upon further investigation, we
found that 99.75% of API requests to ChainLink oracle nodes were made by
ChainLink price feed aggregator addresses themselves. This is because prior to
the v3 aggregator release in August 2020 [6], all price feed aggregator contracts
made API requests to oracle nodes to fetch prices. After removing these API
requests, we are only left with 6634 API requests performed on ChainLink for
the entire 18 month period! We also see that the number of distinct users that
made the use of these features is very low.

Next, we take a look at the most popular price feeds with respect to the most
number of consumer calls made in Fig. 1. We represent the breakdown of the
most popular feeds according to the percentage of the historical price-feed traffic
they attracted. We also take a look at the corresponding most regular customers
for price feeds provided by ChainkLink. We grouped the most regular consumer
addresses (Top 26 addresses, which represent more than 90% of all price-feed
traffic) by their public tags available on Etherscan [9]. Our results show that
Synthetix [1], which is a blockchain-based derivatives trading platform, being



Demystifying Pythia: A Survey of ChainLink Oracles Usage on Ethereum 5

responsible for more than 47% of the historic price feed traffic. If we take out
ChainLink’s internal traffic from the numbers, Sythetix’s share of the historical
price feed traffic rises to 75%.

Table 1. Price Feeds and API: collected data summary.

Feature Total Requests
Excluding ChainLink
Internal Requests

Distinct Caller
/Consumer Addresses

Distinct Callee
Addresses (Price-
Feeds/Oracle Nodes)

Price Feeds 2409074 N/A 294 129
External APIs 2717049 6634 271 159

Fig. 1. Leaderboards: Price Feeds attracting the most traffic and projects generating
the most price feed traffic.

4.2 Oracle Adaption in the Market

To study ChainLink oracles’ adaption trends in the market, we look at the
historical data for the average number of price-feed and API requests made to
ChainLink oracles per month Fig. 2. Plotting the data, we can see that the
price-feed feature appears to be far more popular among users and has been
rapidly gaining more traffic volume. The API feature does not appear to have
a large demand among the users. We believe that this can be attributed to the
fact that most projects and use-cases are able to fulfill their data needs using
the ChainLink provided price feeds and do not have to employ a custom API.
We also show in Fig. 3 that ChainLink has continuously increased the number
price feeds being offered to users. The increase in price feed offerings has kept
up with the increase in adaption as evidenced in these figures. In contrast to the
price-feeds, Oracle nodes have not seen a marked increase in the variety of API
calls and jobs being requested.

4.3 Oracle Pricing

ChainLink is currently providing the price feeds feature to all smart contract
users on the Ethereum chain without cost. These price feeds are sponsored by



6 M. Kaleem and W. Shi

Fig. 2. Number of price feed and API requests on ChainLink by month.

Fig. 3. Number of distinct Price Feeds serviced and active Oracles by month.

various blockchain projects using these feeds in their contracts. A user does
need to pay an Oracle node in LINK token if they make a direct API request.
The current cost of ChainLink API usage varies and can be as high as 1 LINK
depending on the oracle and the data being requested. We look at the historical
price paid for running a single API request in Fig. 4. We also look at the historical
average income which the data providing oracle nodes from these requests. We
see the average LINK paid for oracle requests on ChainLink is increasing of late,
and that coupled with increase in the LINK token price is bound to discourage
the use of oracle APIs for trivial use cases.

4.4 Oracle Servicing Delays

Different smart contract use cases require their oracle service requests to be
processed within a time constraint. For the wide adoption of smart contracts it
is essential that the oracle system they host are reliable and trustworthy. We
analyze our available API data in Fig. 5 to determine the historical average
delay experience on ChainLink API requests. Due to a small number of outliers,
the average obtained was around six hundred blocks. After filtering out these
outliers and only keeping the requests that were serviced within one hundred, we
obtained the data shown in our figures. We can see that for ChainLink oracles



Demystifying Pythia: A Survey of ChainLink Oracles Usage on Ethereum 7

most API requests are serviced within the next four to five blocks with the
historical average block delay being close to four blocks.

Fig. 4. Average cost of a single API request and the Average fees collected in LINK
by oracle nodes.

Fig. 5. Average response time and response time distribution for API requests.

5 Analysis and Conclusion

Based on our analysis of the collected data, we obtained the following important
insights regarding Chainlink usage on Ethereum in particular and the trends for
Oracle systems in general:

– The number of individual users of the ChainLink platform is not very high.
Currently, it is mostly being used by DeFi(Decentralized Finance) projects
and applications to provide market prices to its contracts. This is perhaps
indicative of a trend in the smart contract ecosystem in general.



8 M. Kaleem and W. Shi

– Currently, a single DeFi project, Synthetix has been responsible for almost
75% of the historic price-feed traffic in the ChainLink network (given that we
ignore ChainLink’s self generated traffic). Synthetix uses various commodity
and currency ratio feeds on ChainLink which are among the the feeds that
have serviced the most traffic. This dominance of Synthetix related traffic
might fade with ChainLink increasingly integrating with new projects.

– The data shows that there is currently not a big market of people wanting
to use oracles to connect smart contracts to the external world for trivial use
cases. Whether it is the genuine lack of market demand for these applications
or whether high Ethereum gas prices and ChainLink API fees discourage
people from doing so will require further investigation.

– While ChainLink’s API feature has not seen increased use with the rise of
DeFi, ChainLink’s price feeds have seen increasing usage since the project’s
launch. ChainLink has also managed to provide an increasing variety of price
feeds with the increasing demand.

– The rising average API cost seen on the network might be attributed to the
increased LINK token price which forces people to only make Oracle API
usage for non-trivial cases.

– The average response time of ChainLink’s API feature is seen to remain
steady between 4 and 5 blocks which might not be good enough for time-
sensitive applications.

In conclusion, at the time of this study, the ChainLink ecosystem on the
Ethereum network appears to be driven purely by DeFi’s demand for decentral-
ized market price feeds [11]. In the coming future, it would be interesting to see
if Oracle platforms like ChainLink take initiatives to attract other segments of
users or tailor themselves more towards fulfilling the needs of the growing DeFi
market.

Acknowledgements The authors warmly thank the ChainLink team for sharing
historical price feed addresses with us for cross-verification.

References

1. Synthetix. https://www.synthetix.io (2019)
2. Al-Breiki, H., Rehman, M.H.U., Salah, K., Svetinovic, D.: Trustworthy blockchain

oracles: Review, comparison, and open research challenges. IEEE Access 8, 85675–
85685 (2020)

3. Buterin, V., et al.: Ethereum: A next-generation smart contract and decentralized
application platform. URL https://github.com/ethereum/wiki/wiki (2014)

4. ChainLink: Chainlink developer documentation. https://docs.chain.link
5. ChainLink: Ethereum price feeds. https://docs.chain.link/docs/

ethereum-addresses

6. ChainLink: Developer communications. Chain.Link, https://docs.chain.link/

docs/developer-communications (August 2020)
7. Egberts, A.: The oracle problem-an analysis of how blockchain oracles undermine

the advantages of decentralized ledger systems (2017)

https://www.synthetix.io
https://docs.chain.link
https://docs.chain.link/docs/ethereum-addresses
https://docs.chain.link/docs/ethereum-addresses
https://docs.chain.link/docs/developer-communications
https://docs.chain.link/docs/developer-communications


Demystifying Pythia: A Survey of ChainLink Oracles Usage on Ethereum 9

8. Ellis, S., Juels, A., Nazarov, S.: Chainlink: A decentralized oracle network. https:
//link.smartcontract.com/whitepaper (2017)

9. Etherscan: The ethereum block explorer (2017)
10. Kehrli, J.: Blockchain 2.0-from bitcoin transactions to smart contract

applications. Niceideas, November. Available at: https://www. niceideas.
ch/roller2/badtrash/entry/blockchain-2-0-frombitcoin (2016)

11. Liu, B., Szalachowski, P., Zhou, J.: A first look into defi oracles. arXiv preprint
arXiv:2005.04377 (2020)

12. Peterson, J., Krug, J., Zoltu, M., Williams, A.K., Alexander, S.: Augur: a decen-
tralized oracle and prediction market platform (2019)

13. Provable: https://provable.xyz, accessed on Sep. 10, 2020.
14. Szabo, N.: Formalizing and securing relationships on public networks. First Monday

(1997)
15. Wayback Machine: The internet archive. https://archive.org/web/

https://link.smartcontract.com/whitepaper
https://link.smartcontract.com/whitepaper
https://provable.xyz
https://archive.org/web/

	Demystifying Pythia: A Survey of ChainLink Oracles Usage on Ethereum

";"""date"",""2021-01-19T02:09:27Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2021-01-19T02:09:27Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.21 (TeX Live 2020) kpathsea version 6.3.2""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2021-01-19T02:09:27Z""
""created"",""2021-01-19T02:09:27Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2021-01-19T02:09:27Z""
""resourceName"",""2101.06781""
""Author"",""""
""producer"",""pdfTeX-1.40.21""
""pdf:docinfo:producer"",""pdfTeX-1.40.21""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2021-01-19T02:09:27Z""
""Last-Modified"",""2021-01-19T02:09:27Z""
""dcterms:modified"",""2021-01-19T02:09:27Z""
""title"",""""
""Last-Save-Date"",""2021-01-19T02:09:27Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2021-01-19T02:09:27Z""
""meta:save-date"",""2021-01-19T02:09:27Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.21 (TeX Live 2020) kpathsea version 6.3.2""
""Content-Length"",""719336""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""9""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""2130"",""2402"",""2426"",""2211"",""1511"",""1241"",""748"",""2376"",""816""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2021-01-19T02:09:27Z""
";
1619099111-426;https://scholar.google.ch/scholar?as_ylo=2021&q=oracles+blockchain&hl=fr&as_sdt=0,5;Blockchain adoption in the fashion sustainable supply chain: Pragmatically addressing barriers;G Caldarelli, A Zardini, C Rossignoli ; Journal of Organizational …, 2021  emerald.com;;"… Blockchain adoption in the fashion sustainable supply chain: Pragmatically addressing barriers …

This paper aims to examine and overcome the barriers to the widespread adoption of blockchain

technology, introducing a novel concept of sustainability in the fashion supply chain …";;null;null;;;;https://scholar.google.ch/scholar?start=10&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2021
1619099133-472;https://scholar.google.ch/scholar?as_ylo=2021&q=oracles+blockchain&hl=fr&as_sdt=0,5;An efficient heterogeneous blockchain-based online/offline signcryption systems for internet of vehicles;A Elkhalil, J Zhang, R Elhabob ; Cluster Computing, 2021  Springer;;"… By combining blockchain with signature and encryption benefits, the proposed protocol can

achieve more security features, such as authentication … Efficient Heterogeneous Signcryption

protocol (EHSC-IoV) is secure under the CDH and DL problems in the random oracle model …";;null;null;;;;https://scholar.google.ch/scholar?start=60&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2021
1619099107-416;https://scholar.google.ch/scholar?as_ylo=2021&q=oracles+blockchain&hl=fr&as_sdt=0,5;Blockchain for aerospace and defense: Opportunities and open research challenges;RW Ahmad, H Hasan, I Yaqoob, K Salah… ; Computers & Industrial …, 2021  Elsevier;;"… We also provide discussion into key blockchain complementary architectural

technologies such as Oracles, IPFS, and Filecoin. Furthermore, we discuss key

opportunities and roles for blockchain in aerospace and military applications …";Cité 2 fois;Les 2 versions;null;;;;
1619099115-436;https://scholar.google.ch/scholar?as_ylo=2021&q=oracles+blockchain&hl=fr&as_sdt=0,5;Cost-effective IoT devices as trustworthy data sources for a blockchain-based water management system in precision agriculture;M Pincheira, M Vecchio, R Giaffreda… ; … and Electronics in …, 2021  Elsevier;;"… analyze, and address the challenges for having sensing devices as trusted oracles in the … itself,

the information can be considered as coming from a trustworthy oracle and directly feed … systems

(Helmbrecht et al., 2017), our architecture favors a public blockchain infrastructure to …";Cité 2 fois;Les 3 versions;null;;;;https://scholar.google.ch/scholar?start=20&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2021
1619099107-412;https://scholar.google.ch/scholar?as_ylo=2021&q=oracles+blockchain&hl=fr&as_sdt=0,5;Smart Contract Data Feed Framework for Privacy-Preserving Oracle System on Blockchain;J Park, H Kim, G Kim, J Ryou ; Computers, 2021  mdpi.com;;"As blockchain-based applications and research such as cryptocurrency increase, an oracle 
problem to bring external data in the blockchain is emerging. Among the methods to solve 
the oracle problem, a method of configuring oracle based on TLS, an existing internet …";Autres articles;En cache;[PDF] mdpi.com;https://www.mdpi.com/2073-431X/10/1/7/pdf;;;
1619099111-420;https://scholar.google.ch/scholar?as_ylo=2021&q=oracles+blockchain&hl=fr&as_sdt=0,5;Modelling blockchain-based business processes: a comparative analysis of BPMN vs CMMN;F Milani, L Garcia;Banuelos, S Filipova…  Business Process …, 2021  emerald.com;;"… search. Modelling blockchain-based business processes: a comparative analysis

of BPMN vs CMMN. Fredrik … Abstract. Purpose. Blockchain technology is increasingly

positioned as a promising and disruptive technology. Such a …";;null;null;;;;https://scholar.google.ch/scholar?start=10&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2021
1619099142-495;https://scholar.google.ch/scholar?as_ylo=2021&q=oracles+blockchain&hl=fr&as_sdt=0,5;Commercially Successful Blockchain Healthcare Projects: A Scoping Review;HSA Fang ; Blockchain in Healthcare Today, 2021  blockchainhealthcaretoday.com;;"… According to its website, its mission is to make crypto- currency projects discoverable and efficient

globally … For example, NEO will be adding new capabilities such as native oracles, identity

management, and decentral- ized file storage systems to its blockchain (32 …";Les 2 versions;Version HTML;[PDF] blockchainhealthcaretoday.com;https://blockchainhealthcaretoday.com/index.php/journal/article/download/166/215;"
1

(page number not for citation purpose)

Blockchain in Healthcare Today 2021. Š 2021 The Authors. This is an Open Access article distributed under the terms of the Creative Commons Attribution-NonCommercial 4.0 International License 
(https://creativecommons.org/licenses/by-nc/4.0/), allowing third parties to copy and redistribute the material in any medium or format and to remix, transform, and build upon the material for any purpose, 
even commercially, provided the original work is properly cited and states its license. Citation: Blockchain in Healthcare Today 2021, 4: 166 - http://dx.doi.org/10.30953/bhty.v4.166

NARRATIVE/SYSTEMATIC REVIEWS/META-ANALYSIS

Commercially Successful Blockchain Healthcare Projects: 
A Scoping Review

Hao Sen Andrew Fang1,2*
1SingHealth Polyclinics, SingHealth, Singapore; 2SingHealth Duke-NUS, Singapore

Abstract

Background: The healthcare industry is the new frontier for blockchain technology. Given its properties of im-
mutability and decentralization, blockchain represents an opportunity for unprecedented level of privacy and 
security for all stakeholders by ensuring data integrity while giving patients control over their own health data. 
On a backdrop of rising interest in blockchain in general and blockchain healthcare applications in particular, 
there has been a proliferation of blockchain healthcare projects over the past few years. The aim of this review 
is to identify and understand real-world blockchain healthcare projects that have attained commercial success 
in the highly competitive blockchain market.
Methods and findings: A scoping review was performed in January 2021 on all projects in the CoinMarketCap 
database. Following a pre-defined inclusion and exclusion criteria, eligible projects were selected. A single 
reviewer then reviewed each project’s official website and whitepaper (where available) and performed data 
abstraction; 10 blockchain healthcare projects fulfilled the selection criteria. The review found that these proj-
ects made up 0.24% of the total number of actively tracked projects on CoinMarketCap. In terms of market 
capitalization, the total market capitalization for the projects was US$65,078,849, comprising less than 0.01% 
of the total market capitalization of all projects. Among the projects, the most frequent type was for personal 
health tracking.
Conclusions: This review revealed that blockchain health projects currently comprise a small fraction of the 
overall number of commercially successful blockchain projects. However, because this sub-industry is still 
in its early stages, there are reasons to be optimistic that many more blockchain health projects will emerge 
and attain commercial success in future. Findings from this review done from an entrepreneurial perspective 
should help with the identification of future projects most likely to succeed.

Keywords: blockchain; distributed ledger; healthcare; scoping review; success

Received: 27 January 2021; Accepted: 21 March 2021; Revised: 21 March 2021; Published: 16 April 2021

The global blockchain technology market size was 
valued at US$1.5 billion in 2018 and is expected to 
grow at a compound annual growth rate (CAGR) 

of 69.4% from 2019 to 2025 (1). Over the past few years, 
the rising interest in blockchain has seen a proliferation 
of promising projects leveraging the technology. Current 
estimates put the number of new projects at about 200 a 
month (2). According to the data from CoinMarketCap 
(CMC), as of January 26, 2021, an estimated 8,326 block-
chain projects have since been launched, with a total mar-
ket capitalization nearing US$1 trillion (3).

Since the core idea of Bitcoin – the first blockchain 
project – was to decentralize money, many blockchain 

projects have focused likewise on solutions for the fi-
nance industry (4). More recently, projects have creatively 
started to apply blockchain across to other industries 
such as manufacturing, media, retail, and education (5). 
The healthcare industry, which is rapidly embracing dig-
ital technologies, has been touted as the next frontier for 
blockchain technology (6). For healthcare, blockchain 
technology represents an opportunity for unprecedented 
level of privacy and security for all stakeholders by ensur-
ing data integrity while giving patients control over their 
personal health data. It comes as no surprise then that the 
blockchain healthcare market is forecasted to grow at an 
even higher CAGR of 72.0% from 2020 to 2027 (7).

*Correspondence: Hao Sen Andrew Fang. Email: andrew.fang.h.s@singhealth.com.sg

https://creativecommons.org/licenses/by-nc/4.0/
http://dx.doi.org/10.30953/bhty.v4.166
mailto:andrew.fang.h.s@singhealth.com.sg


Citation: Blockchain in Healthcare Today 2021, 4: 166 - http://dx.doi.org/10.30953/bhty.v4.1662
(page number not for citation purpose)

Hao Sen Andrew Fang

Reviews of blockchain applications in healthcare have 
been conducted to better understand developments in the 
blockchain healthcare domain. Katuwal et al. and Drosa-
tos et al. both reviewed the major use cases of blockchain 
in healthcare and found that most projects were limited 
as conceptual ideas, while a similar review by Agbo et al. 
also showed that there was a lack of real-world implemen-
tations (8–10). As these reviews have mostly been through 
the research lens, they tend to focus on projects published 
in research journals and conferences. This inherently 
excludes other projects that have not been shared in re-
search mediums due to commercial reasons for example. 
Furthermore, because the analysis of projects described 
in these reviews included the entire spectrum from con-
ceptual ideas to real-world implementations, the analyses 
of projects that actually delivered value were diluted by 
those that potentially could.

In this review, we aim to identify and understand re-
al-world blockchain healthcare projects that have been 
commercially successful in the highly competitive block-
chain market. By scoping the selection to apex projects in 
the blockchain field, this review should provide entrepre-
neurs and funders with a better understanding to judge 
the likelihood of success, novelty, and potential of future 
blockchain healthcare projects. To the best of our knowl-
edge, this is the first formal review of blockchain health-
care applications performed through an entrepreneurial 
lens. 

Methods

Study design
A scoping review was performed as the goal was to pro-
vide an overview of the successful blockchain healthcare 
projects instead of answering focused questions or to 
judge the quality of various projects. A commercially suc-
cessful blockchain project was defined as a project which 
had attained liquidity in public financial markets.

The presented review method was carried out by defin-
ing the following activities:

1. Research questions
2. Search strategy
3. Project selection
4. Data abstraction

(1) Research questions
For this review, there were two broad questions we 
aimed to address:
a.  Among commercially successful blockchain proj-

ects, how do the healthcare-related ones fare?
b.  What are the examples of commercially successful 

blockchain healthcare projects?

(2) Search strategy
A list of successful blockchain projects were obtained 
from the CMC database. The CMC developer applica-
tion programming interface (API) was used to obtain 
the list of cryptocurrency listings. CMC is the world’s 
most-referenced price-tracking website for cryptoas-
sets in the rapidly growing cryptocurrency space. 
According to its website, its mission is to make crypto-
currency projects discoverable and efficient globally by 
providing users with unbiased, high-quality, and accu-
rate information for drawing their own informed con-
clusions. Data provided from its platform have been 
cited by several major media outlets such as Forbes, 
Reuters, and The Wall Street Journal (11–13).

(3) Project selection
The following inclusion criteria were applied to select 
the suitable commercially successful healthcare proj-
ects: 1) Should be actively tracked by CMC, 2) should 
have a market capitalization of more than US$0, and 
3) should be primarily for use in healthcare industry. 
Market capitalization was derived from the multipli-
cation of the last traded token price and the number 
of circulating tokens. The market capitalization crite-
ria were used to identify projects that had attracted 
financial investment, and those with a positive value 
were deemed commercially successful. Projects which 
did not have a website and those which were listed for 
less than 2 years were excluded. The 2-year mark was 
selected as a minimum duration of existence as this is 
typically the time when most projects face cash con-
cerns, and it has been found that one-third of the new 
businesses do not make it past the first 2 years (14, 15).

The project selection was performed in a stepwise 
manner. First, the API query was configured to extract 
only projects that were actively tracked in the CMC 
database. Next, the exported JavaScript Object Nota-
tion (JSON) list was converted to comma separated 
values (CSV) format using Python. Microsoft Excel 
was used to filter projects in the CSV file with mar-
ket capitalization values of more than US$0. Finally, 
a single reviewer manually reviewed each project in the 
filtered list to identify suitable healthcare projects.

(4) Data abstraction
For data abstraction, a standardized data collection 
form was developed using Microsoft Excel. A review 
of each project’s official website and whitepaper (where 
available) was performed by a single reviewer knowl-
edgeable in blockchain and the healthcare industry. 
The World Health Organization’s ‘Classification of 
digital health interventions’ was used to classify the 
type of healthcare project (16).

http://dx.doi.org/10.30953/bhty.v4.166


Citation: Blockchain in Healthcare Today 2021, 4: 166 - http://dx.doi.org/10.30953/bhty.v4.166 3
(page number not for citation purpose)

Commercially successful blockchain healthcare projects

In total, 10 data elements were extracted for each 
project. Table 1 provides the complete list of data ele-
ments and a description of each element.

Results

Overview
As of  January 23, 2021, there were a total of  8,305 
blockchain projects in the CMC database. The results 

returned from the API query on the same date re-
turned  4,087 actively tracked blockchain projects. 
From  the project selection process, 10 projects were 
identified as successful blockchain healthcare projects 
for review. Figure 1 illustrates the selection process 
and the final list of  selected projects for review. A sum-
mary of  the successful blockchain healthcare projects 
and  the data abstracted are presented in Multimedia 
Appendix 1.

Table 1. List of data elements extracted and their description.

No. Data element Description

1 Project name Name of the blockchain project

2 Project token symbol Symbol used to represent token on CoinMarketCap (CMC)

3 Project website Official website URL of the project

4 Project rank Rank of project on CMC based on market capitalization

5 Year started Year that the project was started

6 Market capitalization Market capitalization on CMC

7 Market pairs Number of markets that the project’s token was traded on

8 Project mission Overarching mission of the project

9 Type of healthcare project Area of healthcare industry the project is mainly applied to1

10 Blockchain platform Blockchain platform used by the project’s solution

1Based on a Classification of Digital Health Interventions by the World Health Organization.

Fig. 1. Flowchart to illustrate the screening of projects and the final list of projects for review. 

http://dx.doi.org/10.30953/bhty.v4.166


Citation: Blockchain in Healthcare Today 2021, 4: 166 - http://dx.doi.org/10.30953/bhty.v4.1664
(page number not for citation purpose)

Hao Sen Andrew Fang

In terms of the number of projects, healthcare proj-
ects made up a fraction (0.24%) of the total number of 
actively tracked projects on CMC. There were no health-
care projects among the top-100 ranked cryptocurrency 
projects, while there were one and five in the top-500 and 
top-1,000, respectively. In terms of market capitalization, 
the total market capitalization for healthcare projects was 
US$65,078,849. This made up an even smaller fraction 
(<0.01%) of the total market capitalization of all projects.

Among the 10 blockchain healthcare projects, the most 
frequent type was ‘Personal health tracking’ (n = 4), while 
the others varied from health financing to supply chain 
management. The projects that fell under ‘Personal health 
tracking’ all featured a personal health records system. 
Figure 2 shows the distribution of the various types of 
healthcare projects.

Description of successful blockchain healthcare projects
The subsequent section provides a brief  description of 
each of the 10 reviewed projects.

(1) Solve.Care (17)
Solve.Care is a healthcare information technology 
company that was founded in 2017. It is building a 
platform designed to use blockchain technology for 
coordinating care, benefits, and payments between all 
healthcare stakeholders. This includes patients, doc-
tors, pharmacies, laboratories, employers, and insur-
ers. Some use cases include appointment scheduling, 
specialist referrals, and insurance claims submissions. 
Its blockchain solution adopts a dual token mecha-
nism – the SOLVE token and Care.Coin – with each 
token having distinct functionality. The SOLVE token 
is the native utility token required to participate in and 
transact on the platform. It can be utilized to pay for 
network fees, establish user accounts (Care.Wallets), 
and purchase apps (Care.Cards) from a proprietary 

marketplace (Care.Marketplace). The SOLVE token 
supply is fixed and its price is variable, as determined 
by market supply and demand. SOLVE tokens gener-
ate Care.Coins, a stable payment currency, which can 
be used for the payment of services. 

(2) MediBloc (18)
MediBloc was founded by a pair of Korean entre-
preneurs in 2017. It is developing a decentralized 
healthcare information ecosystem built on blockchain 
technology for patients, healthcare providers, and re-
searchers. It allows patients to track and record all of 
their healthcare-related details, such as doctor visits 
and health records, on its blockchain platform. Apart 
from aggregating data, it also assigns ownership of the 
data to patients. This allows patients to decide which 
MediBloc partners they wish to share their informa-
tion with. By sharing information, patients will be re-
warded with the native currency MED tokens which 
can be used to pay for MediBloc partner products and 
services such as pharmaceutical purchases and insur-
ance premiums.

(3) Dentacoin (19)
Dentacoin was started by a group of like-minded 
dentistry and digital transformation experts eager to 
reshape the dental industry by adopting blockchain 
technology. The aim of Dentacoin is for dental pa-
tients to write public reviews of the dentists they 
visit. The team has built a Trusted Reviews Platform, 
which allows patients to record their reviews on the 
blockchain, free of censorship. To ensure authentic-
ity, it plans to implement a verified reviews feature to 
indicate that the review was written by people who 
were authorized by their dentist to write a review be-
fore their treatment began. The platform will reward 
patients in the form of Dentacoins tokens (DCN) 

Fig. 2. Distribution of the types of healthcare projects among those reviewed.

http://dx.doi.org/10.30953/bhty.v4.166


Citation: Blockchain in Healthcare Today 2021, 4: 166 - http://dx.doi.org/10.30953/bhty.v4.166 5
(page number not for citation purpose)

Commercially successful blockchain healthcare projects

for participating.  The program will ultimately help 
users save money by using DCN to pay for their den-
tal treatment or to purchase dental products. In the 
long run, it envisions that dentists could potentially 
consider DCN as a financial investment. For exam-
ple, they could use it to remunerate employees or to 
pay suppliers with no middlemen and no high inter-
national transaction costs. This direct connection 
between producers and dentists will ultimately allow 
dentists to provide lower prices to patients.

(4) MediShares (20)
MediShares was created by the founders of Zhong-
topia, the largest mutual aid platform in China with 
over 10 million users. MediShares aims to combine the 
traditional mutual insurance model with blockchain 
and smart contract, which provides a low operation 
cost and guarantee of compensation for risks. It is 
developing a blockchain platform that will serve as 
a decentralized marketplace for insurance. With this, 
participants can generate insurance smart contract, 
thus making it possible for anyone to find insurance 
coverage. On the platform, insurers are expected to 
profit in the form of MediShares tokens (MDS).

(5) Lympo (21)
Lympo is an Estonian blockchain startup with a 
mission to make the world healthier by incentivizing 
people to adopt healthier lifestyles. It is developing 
a blockchain and gamification platform which re-
wards participants with LYM tokens for complet-
ing certain activities such as simple challenges. For 
example, via its app, users are required to join six 
to eight daily walking and running challenges. Once 
a challenge is accomplished, the user will receive a 
reward of  LYM tokens in the in-app wallet. These 
LYM tokens have real value and can be used to pur-
chase quality sporting goods from an online shop 
– the Lympo Shop.

(6) Doc.com (22)
Doc.com was founded in 2012 in Latin America, and it 
provides telemedicine services to patients through-
out the world. In 2018, it launched its blockchain 
platform. Essentially, Doc.com’s blockchain-based 
platform seeks to generate value from the data that 
patients and healthcare providers share by charging 
those who want to access that data. As reward to pa-
tients and healthcare providers for their contribution, 
they receive payment in the form of Medical Token 
Currency (MTC) tokens. Patients and healthcare pro-
viders can then use MTC in order to pay for services 
and for access to large volumes of encrypted data and 
valuable aggregate-level healthcare statistics.

(7) Tokes (23)
As part of the Multichain Ventures ecosystem that 
uses the Tokes token (TKS), the Tokes platform was 
founded to solve the cannabis industry’s banking 
problem via cryptocurrency payments. In addition to 
providing a payments gateway, the Tokes Platform is 
also building out a blockchain-based ‘track and trace’ 
platform for supply chain management with the capa-
bility to integrate with conventional enterprise soft-
ware via API. This holistic view of the entire supply 
chain ensures that goods can be tracked from seed to 
sale with no loss or fraudulent manipulation of data 
along the way while complying with global supply 
chain management standards.

(8) AI Doctor (24)
AI Doctor was conceived as a decentralized artificial 
intelligence (AI) virtual doctor in 2016. The platform 
aims to leverage AI to analyze patients’ data to pro-
vide real-time, personalized health advice. To further 
incentivize users to contribute their health data, they 
are rewarded with AIDOC tokens on the blockchain 
platform. The AIDOC tokens can in turn be used to 
enjoy health insurance at preferential rates. These data 
on the platform can also be used by various organi-
zations such as medical institutions, pharmaceuticals, 
and AI companies for clinical research, drug develop-
ment, and AI research, respectively.

(9) Medicalchain (25)
Founded in 2017, Medicalchain aims to use block-
chain technology to securely store health records and 
maintain a single version of the truth. Its blockchain 
platform will enable users to give conditional data 
access to different stakeholders such as doctors, hos-
pitals, laboratories, pharmacists, and health insurers. 
The team is also developing a health data marketplace 
to allow users to negotiate commercial terms with 
third parties for alternative uses or applications of 
their personal health data. For example, putting for-
ward their data to be used in medical research, its plat-
form is powered by the MTN token that can be used 
to pay for various future services on the Medicalchain 
platform, such as telemedicine consultations.

(10) Patientory (26)
Founded in 2015, and based in Atlanta, Georgia, 
Patientory was one of  the earliest healthcare proj-
ects in the blockchain space. Its key objective is to 
empower people to take charge of  their own health. 
With a HIPAA-compliant platform, it enables pa-
tients, clinicians, and healthcare organizations to 
securely access and transfer sensitive health informa-
tion while providing actionable insights to improve 

http://dx.doi.org/10.30953/bhty.v4.166
http://Doc.com
http://Doc.com
http://Doc.com


Citation: Blockchain in Healthcare Today 2021, 4: 166 - http://dx.doi.org/10.30953/bhty.v4.1666
(page number not for citation purpose)

Hao Sen Andrew Fang

health outcomes. On its platform, its cryptocurrency 
token, PTOY, is a utility token to rent space to store 
healthcare data. It ensures data quality, helps to reg-
ulate payment transactions, and ensures access to the 
Patientory platform.

Discussion

Principal findings
In this first ever review of blockchain healthcare projects 
focusing on those that have attained commercial success, 
we found that healthcare projects make up a small frac-
tion of the overall number of projects that have managed 
to penetrate the blockchain market, both in terms of 
market capitalization and number of projects. This may 
also be due to the fact that majority of projects continue 
to follow Bitcoin’s lead and target the finance industry. 
Also, ‘DeFi’ – a portmanteau of ‘decentralized finance’ 
– has become the new marketing buzzword in blockchain 
investor circles. As a result, these types of DeFi projects 
have recently attracted disproportionately large investor 
interest. On the contrary, the healthcare industry tends to 
lag in terms of adopting digital innovations, usually due 
to stricter regulations on new products and innovations. 
However on that point, it is worth noting that US national 
health spending is accelerating and is projected to account 
for almost 20% of US gross domestic product by 2028 
(27). This trend will be similar for other countries. So, if  
governments decide to push for blockchain in healthcare, 
like how electronic health records were encouraged as part 
of the US Health Information Technology for Economic 
and Clinical Health (HITECH) Act, we may see health-
care easily leapfrog other industries in the adoption of 
blockchain (28).

The use cases of the successful blockchain health-
care projects reviewed are diverse, ranging from patient 
empowerment to creating mutual aid marketplaces (20, 
21). With data privacy and ownership concerns becom-
ing more prominent, it was not surprising that personal 
health tracking was the most frequent type of blockchain 
healthcare project (18, 21, 25, 26). This is a natural fit for 
blockchain which aims to decentralize data ownership by 
putting it in the hands of the end-users, instead of cen-
tralized within health institution’s databases (29). Find-
ings from the aforementioned reviews by Katuwal et al., 
Drosatos et al. and Agbo et al. had also found that health 
data management was the most frequent use case among 
projects described in journals and conference publications 
(8–10). This indicates a healthy pipeline of projects experi-
menting in the area, and this may augur more innovations 
for the use case. This review also came across interesting 
projects that combined blockchain technology with other 
new technologies such as AI and telemedicine (22, 24). 

Another new technology that is being studied in combina-
tion with blockchain is Internet-of-Things (IoT). Outside 
this review, we researchers are also working on building 
infrastructure for data sharing on blockchain which can 
potentially integrate with IoT devices in the future (30). 
This appropriate blending of technologies may open up 
new use cases and will help blockchain projects to stand 
out and attract greater investor interest.

Ethereum was the most frequently used blockchain 
platform among the blockchain health projects. While 
Ethereum itself  is upgrading to a new version (version 
2.0) to improve scalability, other blockchain platforms 
are also rapidly building out new capabilities (31). For 
example, NEO will be adding new capabilities such as 
native oracles, identity management, and decentral-
ized file storage systems to its blockchain (32). These 
blockchain platform enhancements will likely see more 
exciting new blockchain projects in future, especially 
healthcare-related ones that target patient data manage-
ment. Separately, projects are also beginning to integrate 
multiple blockchains. Patientory, which was initially built 
on Ethereum, later integrated another blockchain plat-
form, Dash, for its payments function (33). Medicalchain 
was developed on a dual blockchain structure, using both 
Ethereum and Hyperledger Fabric (25). In future, we may 
see more of  such projects adopting multiple blockchains. 
However, more interestingly, we may expect projects to 
develop cross-chain interoperability where tokens can 
seamlessly flow from one chain to another using the same 
interface (34).

Limitations
It is acknowledged that this review has its limitations. 
First, by only including projects that were linked to cryp-
tocurrencies, it excludes other blockchain healthcare proj-
ects that did not use cryptocurrencies such as Estonia’s 
electronic health records based on blockchain technology 
(35). However, the advantage of this narrower scope al-
lowed both a qualitative and quantitative comparison 
(based on number of projects and market capitalization) 
of the various healthcare projects within and also against 
non-healthcare projects. Second, it only searched projects 
from a single database – CMC. This limitation is miti-
gated by the fact that CMC is the leading tracking ser-
vice for cryptocurrency projects, and alternative databases 
such as CoinGecko and ICOBench were comparatively 
smaller, with 6,185 and 5,728 projects, respectively, at the 
time of search. Furthermore, CMC was transparent with 
its listings criteria published on its website (36). Third, we 
recognize that there are other definitions of commercial 
success, such as revenue generated and monthly average 
users, apart from purely market capitalization. However, 
these other metrics tend to be less well reported in the pub-
lic domain and therefore were not included in this review. 

http://dx.doi.org/10.30953/bhty.v4.166


Citation: Blockchain in Healthcare Today 2021, 4: 166 - http://dx.doi.org/10.30953/bhty.v4.166 7
(page number not for citation purpose)

Commercially successful blockchain healthcare projects

Future work
This review focused on the successes. It leaves unanswered 
the proportion of total investment amount from health-
care industry and number of projects this small group 
of blockchain health projects comprise. To answer this, 
a subsequent review may look to include unsuccessful 
blockchain health projects in the analysis. Also, the sub-in-
dustry is likely at its first inning of an exciting journey of 
blockchain adoption in healthcare. It would therefore also 
be informative to continue trending its developments over 
the coming years.

Conclusion
This scoping review of the commercially successful block-
chain healthcare projects has revealed that such projects 
make up a small fraction of the overall number of projects 
that have penetrated the blockchain market. However, we 
found diverse ideas and use cases among the projects. 
On the backdrop of rising interest and innovation in 
this space, there is optimism that many more blockchain 
health projects will emerge and attain commercial success. 
Individuals with enthusiasm and knowledge in block-
chain and healthcare will play an increasingly important 
role in helping to separate the wheat from the chaff. As the 
first review done from the entrepreneurial perspective, we 
expect this review to be a useful reference for those who 
take up the role and serve as a basis for future reviews to 
track the progress of this space.

Supporting information
Multimedia Appendix 1. Summary of successful block-
chain healthcare project and the data abstracted.

Conflicts of interest and funding
The author declares no conflicts of interests. The author 
has not received any funding or benefits from industry or 
elsewhere to conduct this study.

Contributor’s contributions
The author was the sole contributor to this article. He 
would like to thank his family and work organization, 
SingHealth Polyclinics, for their support.

References

 1. Grand View Research. Global blockchain technology market size 
report, 2019–2025 [Internet]. [cited 26 January 2021]. Available 
from: https://www.grandviewresearch.com/industry-analysis/
blockchain-technology-market

 2. Raja. Blockchain Infographic: 2020 blockchain growth, use 
cases, facts [Internet]. Dot Com Infoway. 2018 [cited 26 January 
2021]. Available from: https://www.dotcominfoway.com/blog/
growth-and-facts-of-blockchain-technology/

 3. CoinMarkeyCap. Historical snapshot – 26 January 2021 [Inter-
net]. CoinMarketCap. [cited 27 January 2021]. Available from: 
https://coinmarketcap.com/historical/20210126/

 4. Nakamoto S. Bitcoin: a peer-to-peer electronic cash system. 
2008.

 5. Blockchain market share by industry 2020 [Internet]. Statista. 
[cited 26 January 2021]. Available from: https://www.statista.
com/statistics/804775/worldwide- market-share-of-blockchain-
by-sector/

 6. Brue M. Blockchain beyond Bitcoin: transforming FinTech, 
healthcare, and more [Internet]. Forbes. [cited 26 January 
2021]. Available from: https://www.forbes.com/sites/moorin-
sights/2021/01/15/blockchain-beyond-bitcoin-transforming- 
fintech-healthcare-and-more/

 7. Data Bridge Market Research. Blockchain technology in the 
healthcare market – Global industry trends and forecast to 2028 
| Data bridge market research [Internet]. [cited 26 January 2021]. 
Available from: https://www.databridgemarketresearch.com/
reports/global-blockchain-technology-in-the-healthcare-market

 8. Katuwal GJ, Pandey S, Hennessey M, Lamichhane B. Appli-
cations of blockchain in healthcare: current landscape & chal-
lenges. ArXiv181202776 Cs [Internet]. 2018 [cited 27 January 
2021]. Available from: http://arxiv.org/abs/1812.02776

 9. Drosatos G, Kaldoudi E. Blockchain applications in the bio-
medical domain: a scoping review. Comput Struct Biotechnol J 
2019; 17: 229–40. doi: 10.1016/j.csbj.2019.01.010

 10. Agbo CC, Mahmoud QH, Eklund JM. Blockchain technology 
in healthcare: a systematic review. Healthc Basel Switz 2019; 
7(2). doi: 10.3390/healthcare7020056

 11. Ponciano J. Bitcoin losses near $200 billion as JPMorgan warns 
it’s the ‘least reliable’ dollar hedge [Internet]. Forbes. [cited 26 
January 2021]. Available from: https://www.forbes.com/sites/
jonathanponciano/2021/01/21/bitcoin-losses-near-200-billion-
as-jpmorgan-warns-its-the-least-reliable-dollar-hedge/

 12. Staff  R. Crypto market cap surges above $1 trillion for 
first time [Internet]. Reuters. 2021 Jan 7 [cited 26 Janu-
ary 2021]. Available from: https://www.reuters.com/article/
crypto-currency-int-idUSKBN29C264

 13. Michaels D. BitMEX co-founders charged with U.S. rules 
violations [Internet]. Wall Street J. 2020 [cited 26 January 
2021]. Available from: https://www.wsj.com/articles/bitmex-
founders-charged-in-indictment-that-says-they-flouted-u-s-
rules-11601579782

 14. FreshBooks. How long it takes for a small business to be 
successful: a year-by-year breakdown [Internet]. Fresh-
Books. [cited 26 January 2021]. Available from: https://
www. freshbooks.com/hub/startup/how-long-does-it-take-
business-to-be-successful

 15. Petch N. Startup life: six rules for surviving the first two years 
[Internet]. Entrepreneur. 2016 [cited 26 January 2021]. Available 
from: https://www.entrepreneur.com/article/285751

 16. WHO | Classification of  digital health interventions v1.0 
[ Internet]. World Health Organization; [cited 28 January 
2021]. Available from: http://www.who.int/reproductivehealth/ 
publ i cat ions /mhea l th /c lass i f i cat i";"""date"",""2021-04-15T13:33:11Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.4""
""xmp:CreatorTool"",""Adobe InDesign 14.0 (Macintosh)""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""language"",""en""
""dcterms:created"",""2021-04-15T13:33:10Z""
""Last-Modified"",""2021-04-15T13:33:11Z""
""dcterms:modified"",""2021-04-15T13:33:11Z""
""dc:format"",""application/pdf; version=1.4""
""xmpMM:DocumentID"",""xmp.id:3e24162d-268d-425d-81a2-f2f3696c9987""
""Last-Save-Date"",""2021-04-15T13:33:11Z""
""pdf:docinfo:creator_tool"",""Adobe InDesign 14.0 (Macintosh)""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2021-04-15T13:33:11Z""
""meta:save-date"",""2021-04-15T13:33:11Z""
""pdf:encrypted"",""false""
""xmp:CreateDate"",""2021-04-15T19:03:10Z""
""modified"",""2021-04-15T13:33:11Z""
""Content-Length"",""1031163""
""pdf:hasMarkedContent"",""true""
""Content-Type"",""application/pdf""
""xmp:ModifyDate"",""2021-04-15T19:03:11Z""
""xmp:MetadataDate"",""2021-04-15T19:03:11Z""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""dc:language"",""en-US""
""pdf:producer"",""Adobe PDF Library 15.0""
""trapped"",""False""
""meta:creation-date"",""2021-04-15T13:33:10Z""
""created"",""2021-04-15T13:33:10Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""8""
""Creation-Date"",""2021-04-15T13:33:10Z""
""resourceName"",""215""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""4527"",""5017"",""1777"",""3760"",""5153"",""5749"",""6092"",""3040""
""access_permission:extract_content"",""true""
""xmpMM:DerivedFrom:DocumentID"",""xmp.did:c37499d0-fb36-4b08-bdca-07feba89d06d""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""xmpMM:DerivedFrom:InstanceID"",""xmp.iid:84948e7c-8122-44a8-beff-28a5bf10ef82""
""producer"",""Adobe PDF Library 15.0""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""Adobe PDF Library 15.0""
""pdf:docinfo:created"",""2021-04-15T13:33:10Z""
";https://scholar.google.ch/scholar?start=80&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2021
1619099142-491;https://scholar.google.ch/scholar?as_ylo=2021&q=oracles+blockchain&hl=fr&as_sdt=0,5;[LIVRE][B] Applying blockchain for climate action in agriculture: state of play and outlook;L Van Wassenaer, M van Hilten, E van Ingen… ;2021 books.google.com;;"… mitigation (CCAM) in agriculture: Findings from the literature 3.1 Key aspects of blockchain

application 3.1.1 General development of blockchain application As observed by numerous

studies, BCT is known to many as the technology underpinning the cryptocurrency Bitcoin and …";;null;[HTML] google.ch;https://books.google.ch/books?hl=fr&lr=&id=XKQlEAAAQBAJ&oi=fnd&pg=PR7&dq=oracles+blockchain&ots=uLJUN3sAHP&sig=Jb3UMybY4NSimDS4oQjebGkUCyI;"Recherche Images Maps Play YouTube ActualitĂŠs Gmail Drive Plus Âť
Connexion


[image: Les utilisateurs de lecteurs d'ĂŠcran peuvent cliquer sur ce lien pour activer le mode d'accessibilitĂŠ. Celui-ci propose les mĂŞmes fonctionnalitĂŠs principales, mais il est optimisĂŠ pour votre lecteur d'ĂŠcran.]
Livres



	Ma bibliothèque
	Aide
	Recherche AvancĂŠe de Livres
	TĂŠlĂŠcharger le PDF


Version papier du livre
Aucun e-book disponible

[bookmark: buy_anchor]
	Food and Agriculture Organization of the United Nations 
	Alapage
	Amazon France
	FNAC
	

	Trouver ce livre dans une bibliothèque
	Tous les vendeurs 



	[image: Couverture]
	 0 AvisRĂŠdiger un commentaire





Applying blockchain for climate action in agriculture: state of play and outlook
De Van Wassenaer, L., van Hilten, M., van Ingen, E., van Asseldonk, M.
 		 
	



À propos de ce livre




[image: ]Acheter des livres sur Google Play
Parcourez la librairie en ligne la plus vaste au monde et commencez dès aujourd'hui votre lecture sur le Web, votre tablette, votre tÊlÊphone ou un lecteur d'e-books.
AccÊder à Google Play 



[bookmark: pub_info_anchor]
	Pages affichÊes avec l'autorisation de Food & Agriculture Org.. Droits d'auteur. 








			
	

	



	  		


			PDF






[bookmark: page]	[image: Page suivante]









";"""og:image"",""https://books.google.ch/books/publisher/content?id=XKQlEAAAQBAJ&printsec=frontcover&img=1&zoom=1&edge=curl&imgtk=AFLRE72o2e8bZUExXL6KofpbR1WStGYvyC6PjZAPgKtBZVyYaILc-DpHBw3lp5wnlolzCSG77pO1b4oMJZMiPMH6OjtghY9vzcKZ8q_jS5_tUb3e84Zqvb0iQTX7LTtdXZmJzOT8gLET""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""og:type"",""book""
""og:site_name"",""Google Books""
""og:title"",""Applying blockchain for climate action in agriculture: state of play and outlook""
""description"",""The objective of this study is to provide insights into potentialities, steps, and best practices in applying blockchain technology (BCT) to use cases in agriculture in the context of climate change, to explore the opportunities and challenges in applying the BCT in agricultural sectors with the aims of reducing greenhouse gas emission, increasing carbon sequestration, as well as supporting farmers’ adaptation to climate change. Furthermore, this study also aims to shed light on policy options and propose policy guidance adapted to developing countries on blockchain applications.""
""resourceName"",""books""
""language"",""fr""
""title"",""Applying blockchain for climate action in agriculture: state of play and outlook - Van Wassenaer, L., van Hilten, M., van Ingen, E., van Asseldonk, M. - Google Livres"",""Applying blockchain for climate action in agriculture: state of play and outlook""
""dc:title"",""Applying blockchain for climate action in agriculture: state of play and outlook - Van Wassenaer, L., van Hilten, M., van Ingen, E., van Asseldonk, M. - Google Livres""
""Content-Encoding"",""ISO-8859-1""
""og:url"",""https://books.google.com/books/about/Applying_blockchain_for_climate_action_i.html?hl=fr&id=XKQlEAAAQBAJ""
""Content-Type"",""text/html; charset=ISO-8859-1""
";https://scholar.google.ch/scholar?start=80&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2021
1619099124-454;https://scholar.google.ch/scholar?as_ylo=2021&q=oracles+blockchain&hl=fr&as_sdt=0,5;[HTML][HTML] Blockchain as a CA: A Provably Secure Signcryption Scheme Leveraging Blockchains;TH Chen, TL Zhu, FG Jeng, CL Wang ; Security and Communication …, 2021  hindawi.com;United Kingdom;"… is a continuously appending list of blocks (see Figure 2) that are linked and secured using crypto-

graphic technologies … (3) By combining blockchain technologies with … in Section 3. Section 4

presents the formal the- oretical security proofs under the random oracle model along …";Les 3 versions;Version HTML;[HTML] hindawi.com;https://www.hindawi.com/journals/scn/2021/6637402/;"[image: logo]
	Journals
	Publish with us
	Publishing partnerships
	About us
	Blog




Security and Communication Networks
+Journal Menu
[image:  ]PDF[image:  ] 
    
     Icons/Arrow Right White
     Created with Sketch.
     
         
    
     
         
             
                 
                     
                         
                             
                                 
                            
                             
                             
                                 
                            
                        
                    
                
            
        
    



Journal overview
For authorsFor reviewersFor editorsTable of ContentsSpecial Issues
[image:  ]         

Submit






Security and Communication Networks / 2021 / Article
Article SectionsOn this page
AbstractIntroductionPreliminariesDiscussionConclusionsData AvailabilityConflicts of InterestAcknowledgmentsReferencesCopyright


Research Article | Open Access
Volume 2021 |Article ID 6637402 | https://doi.org/10.1155/2021/6637402
Tzung-Her Chen, Ting-Le Zhu, Fuh-Gwo Jeng, Chien-Lung Wang, ""Blockchain as a CA: A Provably Secure Signcryption Scheme Leveraging Blockchains"", Security and Communication Networks, vol. 2021, Article ID 6637402, 13   pages, 2021. https://doi.org/10.1155/2021/6637402

Show citation
Blockchain as a CA: A Provably Secure Signcryption Scheme Leveraging Blockchains


Tzung-Her Chen,1 Ting-Le Zhu,1 Fuh-Gwo Jeng,2  and Chien-Lung Wang[image:  ]   .cls-1{fill:#a6ce39;}.cls-2{fill:#fff;}.cls-3{fill:none;} orchid     

31Department of Computer Science and Information Engineering, National Chiayi University, Chiayi 60004, Taiwan
2Department of Applied Mathematics, National Chiayi University, Chiayi 60004, Taiwan
3Information Security Research Center, National Chung Hsing University, Taichung 40227, Taiwan

Show more
Academic Editor: Kaitai Liang
Received07 Dec 2020
Revised25 Jan 2021
Accepted09 Mar 2021
Published26 Mar 2021


Abstract
Although encryption and signatures have been two fundamental technologies for cryptosystems, they still receive considerable attention in academia due to the focus on reducing computational costs and communication overhead. In the past decade, applying certificateless signcryption schemes to solve the higher cost of maintaining the certificate chain issued by a certificate authority (CA) has been studied. With the recent increase in the interest in blockchains, signcryption is being revisited as a new possibility. The concepts of a blockchain as a CA and a transaction as a certificate proposed in this paper aim to use a blockchain without CAs or a trusted third party (TTP). The proposed provably secure signcryption scheme implements a designated recipient beforehand such that a sender can cryptographically facilitate the interoperation on the blockchain information with the designated recipient. Thus, the proposed scheme benefits from the following advantages: (1) it removes the high maintenance cost from involving CAs or a TTP, (2) it seamlessly integrates with blockchains, and (3) it provides confidential transactions. This paper also presents the theoretical security analysis and assesses the performance via the simulation results. Upon evaluating the operational cost in real currency based on Ethereum, the experimental results demonstrate that the proposed scheme only requires a small cost as a fee.
1. Introduction
With the rapid development of information and network applications, confidentiality, integrity, and nonrepudiation are the main security concerns. Thus, encryption and digital signatures have become two main fundamental technologies for any well-defined cryptosystem.
In 1997, Zheng presented the first signcryption concept that simultaneously fulfilled the functions of both the digital signature and public key encryption in a logical single step and achieved significantly lower costs than those required by “signature followed by encryption” [1]. Since then, there have been increasingly more signcryption schemes formed using either traditional public key infrastructure- (PKI-) based [1, 2], identity-based [3–7], or certificateless-based [8–17] digital signatures.
In 1984, Shamir presented a novel identity-based cryptosystem (IBC) [18] in which a random string (identity) was set as the participant’s public key, and the corresponding private key was generated by a trusted third party (TTP) called the key generation center (KGC). This design eliminated the high cost of maintaining a traditional certificate-based PKI. Later, Boneh and Franklin proposed their identity-based encryption (IBE) [19] that fully exploited Shamir’s IBC; this method significantly decreased the computational overhead by eliminating the certificate management problem in the PKI. In 2002, Malone-Lee combined the concepts of the IBC and signcryption to present an identity-based signcryption scheme [5]. Unfortunately, the identity-based signcryption schemes in Ref. [4, 5], to name a few, suffer the key escrow problem.
In 2003, Al-Riyami and Paterson proposed certificateless public key cryptography [20], in which the problems of either the utilization of certificate in PKI or the key escrow in IBC are eliminated. Consequently, Barbosa and Farshim proposed the first certificateless-based signcryption scheme [8]. A certificateless signcryption scheme consists of four phases: (1) setup—the KGC generates its key pairs; (2) key generation—a participant chooses his key pair under the assistance of the KGC; (3) signcryption; and (4) unsigncryption. Notably, the participant’s private key is partially generated by the KGC in the key generation phase and the KGC is assumed to be trusted. Furthermore, the KGC’s public key and the signer’s public key are involved in the unsigncryption phase and the authentication of the public keys is necessary. It is obvious that the certificateless signcryption schemes in Ref. [13, 16, 17], to name a few, cannot avoid the high maintenance cost of TTP.
Herein, we briefly examine a traditional certificate-based digital signature. Certificates, used to authenticate public keys prior to adoption, are chained as an ordered list containing an entity certificate, a series of intermediate certificates in the middle, and a root certificate at the end of the chain. For example, when Alice intends to use Bob’s public key, the public key will be authenticated by verifying Bob’s certificate first. Bob’s certificate, including his identity information and his public key, is protected by the certificate issuer’s signature. Obviously, it is tamper-proof and unforgeable. However, if someone intends to verify the issuer’s signature, Alice needs to take the next step to confirm the issuer’s public key by verifying the corresponding certificate that is issued by another upper issuer called the intermediate certificate authority (CA). The signatures of the certificates in the certificate chain (see Figure 1) must be verified up to the root CA certificate.
[image: ]


Figure 1 
The structure in a certificate chain.


It is clear that maintaining the certificate chain, along with the assumption of a TTP, will increase the overall computational overhead; thus, the use of a blockchain becomes more pertinent. Due to the emergence of Bitcoin [21] in 2009, Ethereum [22] in 2013, and Hyperledger Fabric [23] in 2016, blockchain technologies [21, 22], providing a trusted mechanism without a CA and TTP, have received significant attention and interest in academia and the IT industry.
The fundamental technology of blockchains, such as Bitcoin and Ethereum, has gained increasingly more attention and has begun to be applied to various fields, such as medical data access [24–26], the Internet of Things [27, 28], and privacy preservation [29–31]. However, the high cost of certificate-based public key authentication is still problematic.
A blockchain is a continuously appending list of blocks (see Figure 2) that are linked and secured using cryptographic technologies, and the chain terminates in a genesis block. Each block typically contains an external hash pointer as a link to its previous block and an internal hash of all transactions . A transaction is a group of data, which includes the messages of “” and “” and the signatures. Figure 3 illustrates an instance of a transaction  in the block number 2752 in an Ethereum test blockchain.
[image: ]


Figure 2 
The structure of two blocks with some transactions each in a blockchain.


[image: ]


Figure 3 
The structure of a transaction in the Ethereum blockchain.


Basically, an elliptic curve digital signature algorithm (ECDSA) [32] is what facilitates the blockchain concept in Bitcoin, Ethereum, and Hyperledger Fabric. The signature fields “” and “” in each transaction, as shown in Figure 3, are proven. For a user in a blockchain, his private key is regarded as his identity and security credential. It is worthwhile to note that the private key is generated and maintained by the user himself, not a trusted third party, and it is used to sign outgoing transactions. Instead of interacting with the blockchain, each user can directly interface with his blockchain node to deposit signed transactions and inspect the blockchain.
1.1. Motivation
A blockchain can be viewed as a public decentralized ledger to record all of the transactions in a publicly verifiable and permanent way. The data in  are tamper-proof and cannot be changed retroactively without altering all subsequent blocks up to the genesis one. The cryptographic advantages of a blockchain are similar to those of a certificate chain such as providing public verification and being tamper-proof. The main difference is that the blockchain is a decentralized trusty mechanism requiring no trusted third party; however, the certificate chain is a centralized trust mechanism with a series of trusted third parties.
In this paper, new cryptographic paradigms called blockchain as a CA and transaction as a certificate are investigated to implement a blockchain without a CA or TTP. Precisely, users’ public keys are extracted and authenticated directly from transactions in blockchains instead of by CAs or a TTP. This combination is named blockchain as a CA (BaaCA). BaaCA has the following advantages.(1)Avoiding the high maintenance cost of CA and TTP: for a block in the blockchain, a transaction with its ECDSA signature can be treated as certificate-like and utilized to extract the ECDSA public key such that both the public key and the transaction itself are authenticated. In this way, the concepts of a blockchain as a CA and a transaction as a certificate become intriguingly analogous to that of a certificate chain in the PKI.(2)Seamlessly integrating with blockchains: due to the success of Bitcoin and Ethereum along with the promise of blockchain technologies, it is possible and feasible to combine blockchain technologies with signcryption to achieve the goals of confidentiality, integrity, and nonrepudiation simultaneously.(3)Providing transaction confidentiality: by combining encryption with a digital signature to achieve the goal of “lower computational cost and communication cost,” a novel signcryption scheme based on a blockchain that provides more benefits is proposed in this paper.
1.2. Contribution
In view of prior work, this paper proposes a provably secure BaaCA-based signcryption scheme. The main contributions of the proposed scheme are highlighted as follows.(1)Using blockchain as a CA and transaction as a certificate to form a new signcryption scheme, it is feasible to eliminate the high maintenance cost from involving CAs or a TTP compared with the related works.(2)The theoretical security analysis is demonstrated, and the experimental results show that the proposed scheme can work and interoperate with the Ethereum blockchain. In this way, the proposed scheme does seamlessly comply with a state-of-the-art blockchain.(3)By combining blockchain technologies with signature and encryption, the proposed scheme achieves the goals of confidentiality, integrity, and nonrepudiation simultaneously. It is worth noting that the proposed scheme presents a new paradigm of providing confidentiality to transactions in the Bitcoin and Ethereum blockchains with a minor impact.
The rest of this paper is organized as follows. The related preliminaries are given in the next section. The proposed scheme with the formal system and security models are illustrated in Section 3. Section 4 presents the formal theoretical security proofs under the random oracle model along with the experimental results. The performance analysis is given in Section 5. Discussion and conclusions are given in Sections 6 and 7, respectively.
2. Preliminaries
2.1. Signature via ECDSA
The ECDSA algorithm [32] includes four phases; they are the setup, key generation, signature generation, and signature verification phases. They are briefly described below. Setup phase: Let E be the given curve with its default field and equation. Then, base point  of a prime order on the curve and the multiplicative order n of point  can be determined. A hash function is given as follows: . Key generation phase: The signer performs the following operations.(1)Choose an integer , such that , as the private key.(2)Compute  as the corresponding public key. Then, the private key is  and the public key is , . Signature generation phase: The signer signs message  by doing the following operations.(1)Compute .(2)Choose an integer  such that , where  is a cryptographically secure random number.(3)Compute the curve point .(4)Compute  and . Message  and its corresponding signatures  are sent to the recipient/verifier. Signature verification phase: The verifier performs the following operations to verify the validation of the signature of message .(1).(2)Compute , , and .(3)Compute .(4)Choose -coordinate  as .(5)Check .
If it holds, the signature of  is successfully authenticated.
2.2. Encryption via ECC
To encrypt or decrypt message  in ECC, the operations [33] are as follows. Encryption phase:(1)Choose an integer  such that , where  is a cryptographically secure random number.(2)Suppose message  maps to the curve point M.(3)Compute the curve point .(4)Compute the curve point . Send  to the recipient. Decryption phase:(1)Compute the curve point .(2)Decode point  to obtain plaintext .
3. The Proposed Signcryption Scheme
The proposed BaaCA-based signcryption scheme including its system and security models is illustrated in this section. The notations used in the proposed scheme are described first in Table 1.
		

	Symbol	Description
	

		Global security parameter
		Elliptic curve global parameters
		One-way hash function
		Sender Alice’s private/public key pairs and pseudo name
		Recipient Bob’s private/public key pairs and pseudo name
		Data sent from sender to recipient
		Public part of 
		Sensitive part of 
		ECDSA signature
		Ciphertext
		Transaction
	A	System definition
	





Table 1 
Notations of the proposed scheme.


The proposed BaaCA-based signcryption scheme includes three different entities: a sender, a recipient, and the blockchain.(1)Sender: a sender called Alice, with her private/public key pair , is sending data  to a specified recipient. First, the data  are split into two parts:  and . Note that the privacy-sensitive part of  is put into  and the other remaining part of  will be packaged into . Second, Alice executes the BaaCA-based signcryption algorithm to generate the encryption key , which is used to transform  into ciphertext  and to create the signature  at the same time. Finally, Alice posts the transaction  to the recipient via the blockchain.(2)Recipient: a recipient called Bob, with his private/public key pair , will perform the decryption and verification processes when he gets transaction  to obtain the original data . To decrypt ciphertext , Bob has to execute the signcryption algorithm first to generate the decryption key , which is the same as Alice’s encryption . Consequently, Bob uses  to decrypt  to obtain the privacy-sensitive data  and then recover the original data . When performing verification, first, Bob uses both the signature  and  to generate Alice’s public key . Therefore, Bob can use  to extract Alice’s account address and check whether the account address is the same as that in transaction . Please note that each account address is transformed from the relative public key in the blockchain. If they are the same, Bob can ensure that data  are sent by sender Alice.(3)Blockchain: the blockchain acts as a digital ledger that records all transactions that have ever happened. That is, the blockchain is treated as a CA and the tamper-proof transactions are treated as the certificates to extract the related public keys.
The proposed scheme consists of five algorithms. They are system setup, key generation, public-key extraction, signcryption, and unsigncryption. For simplicity, we denote them as , , , , and , respectively. The details are described below.(i): it is a probabilistic algorithm for generating the public parameters params of the system using a security parameter  as the input. It can be represented as .(ii): it is a probabilistic algorithm that randomly chooses private key  as its input to generate its corresponding public key  and its relative account address. It can be represented as .(iii): it is a deterministic algorithm that sets ECDSA signature  as its input and returns its relative public key . It can be represented as (iv): it is a probabilistic algorithm that takes the sender’s private key , the recipient’s public key , and data as inputs and outputs the corresponding signature , ciphertext , and nonsensitive part of data . The outputs are denoted as . It can be represented as  (v): it is a deterministic algorithm that takes the sender’s public key  the recipient’s private key , and  as inputs and outputs either the corresponding  if the signature  is valid or . It can be represented as .
3.1. Security Model
There are two security concerns about the security model of the proposed BaaCA-based signcryption scheme in this paper. They are confidentiality and unforgeability.(1)Confidentiality. The property of confidentiality in the proposed BaaCA-based signcryption scheme is essentially provided since it is only the specified recipient that knows data . The following experiment , played with the adversary IND-BaaCA-CCA denoted as  and a challenger denoted as , proves the property of confidentiality under chosen ciphertext attacks.(i)Setup:  runs this algorithm to obtain public parameters  and then distributes the public parameters to the adversary .(ii)Queries (phase 1):  makes a number of oracle queries to  and  would give some information to . In the experiment, the following queries are allowed:(a)KeyGen queries:  sends  to , and then  runs  and returns  to .(b)Signcryption queries:  sends  to , and then  runs  and returns  to .(c)Unsigncryption queries:  sends  to , and then  runs  and returns  to .(iii)Challenge: after finishing phase 1, adversary  chooses two data  and  with an arbitrary private key , which he wishes to challenge.  randomly chooses a bit  for the two challenged data and then runs signcryption queries to obtain the result . Finally,  sends it to .(iv)Queries (phase 2): after receiving , adversary  asks a number of queries similar to those in phase 1 but  will be not sent to  under unsigncryption queries.(v)Guess: finally, adversary  chooses a bit  from . The adversary is said to win this experiment if . We can define the advantage of  in this experiment as.(2)Unforgeability. In the proposed BaaCA-based signcryption scheme, unforgeability is essential to ensuring that the signature is secure against adaptively chosen message attacks. The following experiment , played with an adversary EU-BaaCA-CMA denoted as  and a challenger denoted as , proves the existential property of unforgeability under the chosen message attack.(i)Setup: it is the same as that in the experiment .(ii)Queries: it is the same as phase 1 of queries in the experiment .(iii)Output: the adversary  is said to win this experiment if  obtains the signature  together with two arbitrary private keys  and  such that(1).(2) is never sent to  as inputs for the signcryption queries, where  are the data corresponding to the forgery.
Definition 1. The proposed BaaCA-based signcryption scheme is said to be secure if there is no adversary  that wins the experiment  with a nonnegligible probability .
Definition 2. The proposed BaaCA-based signcryption scheme is said to be secure if there is no adversary  that wins the experiment  with a nonnegligible probability . The security of the proposed BaaCA-based signcryption scheme is based on the computational difficulty of some well-known hard problems defined below.
Definition 3. The elliptic curve discrete logarithm problem (ECDLP): if  is unknown, compute  by giving  and .
Definition 4. The elliptic curve computational Diffie–Hellman problem (ECCDHP): if  is unknown, compute  by giving , , and .
In this paper, the appropriate  is determined by blockchains where the ECDLP and ECCDHP are assumed to be computationally difficult.
3.2. The Proposed Scheme
According to the benefits of the blockchain as a CA concept, the proposed scheme uses a variant of the ECDSA to produce a new signcryption scheme. Since the ECDSA is the default signature algorithm in Bitcoin, Ethereum, and Hyperledger Fabric, the proposed scheme is seamlessly compliant with the blockchains.
The proposed model consists of two participants of a blockchain: Alice as a sender and Bob as a recipient. Both of the participants are external actors of the blockchain and have their relative blockchain accounts and some recorded-in-block transactions. Suppose Alice and Bob, denoted as  and , respectively, with the addresses in the fields “” or “” in Figure 3 have their private and public key pairs (, ) and (, ) in the blockchain network, respectively.
The main design comes from the method that generates the private key from the existing transactions signed by Bob and Alice in the blockchain. Herein, a transaction is regarded as a certificate of Alice or Bob.
Alice is connected with the blockchain, receives Bob’s previous signature from a transaction stored in the blockchain, and then extracts Bob’s public key. The encryption key is obtained by executing , where  is a one-time padded random number generated by Alice since Bob can extract this key by performing  when he has , where .
The proposed signcryption scheme consists of five phases: the setup phase, key generation phase, public-key extraction phase, signcryption phase, and unsigncryption phase.(i)Setup phase:(1)Determine the elliptic curve E in the finite field , where  is a prime number such that all the points on E represent a finite group, e.g., , with the prime multiplicative order n and a generator . For example, the ECDSA curve used in Bitcoin and Ethereum is secp256k1, which refers to the curve E: y2 = x3 + 7 [34] defined over the field , while the curves ECC P256 and P384 are adopted by Hyperledger Fabric.(2) and  are two collision resistant hash functions, where  and  have been described in (1).(3)The system parameters  are public.(ii)Key generation phase:(1)Suppose that Alice has her ECDSA private and public key pairs  and Bob has his key pairs  for their accounts on the blockchain, respectively.(2)The ECDSA private and public key pairs are used to specify the address, i.e.,  and . For Bitcoin, Bob’s address is computed as Base_58 (0x00||RIPEMD_160 (SHA_256 ())||. where Base_58 represents a large integer as alphanumeric text, RIPEMD_160 and SHA_256 are two well-known cryptographic hash functions, and || denotes concatenation. For Ethereum, the address is where B96…255 is denoted as the right most 160 bits of the SHA-3 hash.(iii)Public-key extraction phase: because there is no certificate chain in the Bitcoin and Ethereum blockchains, Alice must extract Bob’s public key from Bob’s transaction , where  is public verifiable and tamper-proof once stored in the blockchain. With the ECDSA signature  and the transaction data , Alice is able to extract Bob’s public key  by conducting the following operations.(1).(2), where , and .(3). . Actually, Bitcoin and Ethereum transactions require an extra parameter, i.e., the field “” in Figure 3, to identify which point is correct.(4)Check if the generated node address from  via equations (1) or (2) for Bitcoin or Ethereum, respectively, is equal to Bob’s account address. If it is,  is Bob’s public key and Bob’s transaction  in the blockchain is also authenticated.(iv)Signcryption phase: suppose Alice’s transaction is , where  are composed of two parts:  are public and  are privacy-sensitive. Alice does the following operations to generate the signature of  and the ciphertext of . Note that the signature in this algorithm is designed to be verified by the designated verifier, i.e., Bob. (1).(2).(3).   (4). (5)Return  (5)–(7) are the operations of both key agreement and encryption. Finally, Alice broadcasts the transaction  into the blockchain and discards the random number  and the encryption key .(v)Unsigncryption phase: upon interacting with the blockchain to obtain , Bob verifies the validation of the signature and simultaneously decrypts the ciphertext to obtain  by doing the following operations.(1)Find two points  and  of the same value  as the x-coordinate. The transaction practically involves an extra parameter, say  in Figure 3, to identify  and , say . (2).(3) = .(4).(5).(6)Check if the generated node address from  by equation (1) or (2) is equal to Alice’s account address.
(2)–(4) are both key agreement and decryption operations. If (7) is true, is Alice’s public key and this transaction  is also authenticated. Then, the data  are output; otherwise, we get .
3.3. Correctness of Public-Key Extraction, Encryption, and Signature
The correctness of public key extraction in the proposed protocol is derived from the precision of the hash value of the extracted public key  to the address  indicated in the transaction on the blockchain, where  represents equation (1) or (2). We have  =  =  = . Thus, the equation  holds.
The correctness of the encryption in the proposed protocol is derived from the situation . If it holds, . In the signcryption phase, Alice’s encryption key is  In addition, in the unsigncryption phase, the decryption key that Bob obtains is . Since , we have , and thus .
The correctness of the signature in the proposed protocol is derived from the same proof as that of correctness of public-key extraction. In this way, the signature  is also authenticated. Thus, the proof is omitted here.
4. Security Analysis
Two theorems are described in detail before the security analytics and proofs of the proposed BaaCA-based signcryption scheme are given.
Theorem 1. (IND-BaaCA-CCA). The proposed BaaCA-based signcryption scheme is indistinguishable against chosen ciphertext attacks when the ECDDHP problem is hard to resolve.
Proof. Assume there exists an IND-BaaCA-CCA adversary, , who wins the experiment with a nonnegligible probability  based on Definition 1. A challenger  is designed to take  as the subprogram to solve the ECCDHP problem based on Definition 4 with a nonnegligible probability. Challenger  is assigned an instance  and tries to compute the value .
At first, challenger  maintains four lists , respectively, corresponding to , signcryption, and unsigncryption query oracles. Then,  plays the following experiment with . In addition, we assume that  queries oracle   times and queries KeyGen  times.(1)Setup:  sends  , which is an instance for solving the ECCDHP problem. Two hash functions , controlled by , are regarded as random oracles.(2)Queries (phase 1):  makes a number of oracle queries to  and  should answer to give . In the experiment, the following queries are allowed.(1)Oracle : . Case 1: , return . Case 2: , choose random  add  to , and then return .(2)Oracle : . Case 1:  and return . Case 2: , choose random , add  to , and then return .(3)KeyGen queries:  Case 1: , return  Case 2: , generate public key  and account address  via equation (1) or (2), and then add  to . Finally, return (.(4)Signcryption queries: (a)Choose random .(b)Compute (c).(d)Compute .(e)Compute (f)Compute , where  is from oracle .(g)Compute .(h)Compute , where  is from oracle .(i)Compute , where  is taken from the KeyGen queries.(j)Add  to .(k)Return .(5)Unsigncryption queries: (a)Find two points  and  with the same value  as their x coordinate. The transaction practically involves an extra parameter to identify  and , say .(b)Compute .(c)Compute .(d)Compute.(e)Check whether  holds or not.(f)Return  and add  to ; otherwise, return .(1)Challenge: after finishing phase 1,  chooses two datasets and  with an arbitrary private key , which are to be challenged. Here,  with probability . Then,  randomly chooses a bit for the two challenged datasets and then runs the signcryption algorithm to obtain a result . Finally,  sends  to .(2)Queries (phase 2): after receiving , adversary  asks a number of queries that are the same as in phase 1 but  is never sent to  for unsigncryption queries.(3)Guess: adversary  produces a bit  from .  ignores the bit  produces and randomly chooses , which is stored in , as the solution for the given instance of ECCDHP problem. If  does not query oracle ,  will terminate. In contrast, if  has some advantages to produce the bit correctly, it means that the query to  is required. Therefore, there is enough information in  to help  obtain the correct  with probability  because  queries oracle   times and only one  is right. If so,  is the solution with probability  for the given instance of ECCDHP problem. This is contradictory to our hypothesis at the beginning of the security proof. Thus, this concludes the proof of Theorem 1.
Theorem 2. (EU-BaaCA-CMA). The proposed BaaCA-based signcryption scheme is existentially unforgeable against an adaptively chosen message attack when the ECDLP problem is hard to resolve.
Proof. Assume there is an EU-BaaCA-CMA adversary, who wins the defined experiment  with a nonnegligible probability . We will design a challenger  to take  as its subprogram for solving the ECDLP problem with a nonnegligible probability. The instance  of the ECDLP problem is given to challenger , and  will try to compute the value .
At first, challenger  maintains five lists , respectively, corresponding to  KeyGen, signcryption, and unsigncryption oracles. Then,  plays the following experiment  with . In addition, we assume that  queries oracle   times and queries KeyGen  times.(1)Setup:  sends  to , where is an instance of the ECDLP problem. The hash functions , controlled by , are regarded as random oracles.(2)Queries (phase 1):  makes a number of oracle queries to  and  should answer to give . In the experiment, the following queries are allowed:(1)Oracle :  Case 1:  and return . Case 2: , choose random  add  to , and then return .(2)Oracle :  Case 1:  and return . Case 2: , choose random , add  to , and then return .(3)KeyGen queries:  Case 1:  and return  Case 2: , generate the public key  and the account address  via equation (1) or (2), add  to , and then return .(4)Signcryption queries: (a)Choose random .(b)Compute (c).(d)Compute .(e)Compute (f)Compute , where  is from  oracle.(g)Compute .(h)Compute  where  is from oracle .(i)Compute  where  is taken from the KeyGen queries.(j)Add  to .(k)Return .(5)Unsigncryption queries: (a)Find two points  and  with the same value  as their x coordinate. The transaction practically involves an extra parameter to identify  and , say .(b)Compute .(c)Compute .(d)Compute .(e)Check whether  holds or not.(f)Return  and add  to ; otherwise, return .(i)Output: after finishing phase 1,  produces the signature  along with the verifier  with probability  based on Definition 2. If , will terminate the experiment. However, if  with probability,  picks the correct  from  with probability to recover . Finally,  can compute  with the probability  to solve the ECDLP problem. This is contradictory to our hypothesis at the beginning of the security proof. Thus, this concludes the proof of Theorem 2.Considering the strength of the keys, which is one of the primary factors of cryptographic algorithms, the security analysis of the key strength is further illustrated. There are three state-of-the";"""dc.publisher"",""Hindawi""
""og:image"",""https://images.hindawi.com/journals/scn/scn.banner.jpg""
""og:image:width"",""600""
""twitter:card"",""summary_large_image""
""citation_journal_title"",""Security and Communication Networks""
""language"",""en""
""og:description"",""Although encryption and signatures have been two fundamental technologies for cryptosystems, they still receive considerable attention in academia due to the focus on reducing computational costs and communication overhead. In the past decade, applying certificateless signcryption schemes to solve the higher cost of maintaining the certificate chain issued by a certificate authority (CA) has been studied. With the recent increase in the interest in blockchains, signcryption is being revisited as a new possibility. The concepts of a blockchain as a CA and a transaction as a certificate proposed in this paper aim to use a blockchain without CAs or a trusted third party (TTP). The proposed provably secure signcryption scheme implements a designated recipient beforehand such that a sender can cryptographically facilitate the interoperation on the blockchain information with the designated recipient. Thus, the proposed scheme benefits from the following advantages: (1) it removes the high maintenance cost from involving CAs or a TTP, (2) it seamlessly integrates with blockchains, and (3) it provides confidential transactions. This paper also presents the theoretical security analysis and assesses the performance via the simulation results. Upon evaluating the operational cost in real currency based on Ethereum, the experimental results demonstrate that the proposed scheme only requires a small cost as a fee.""
""prism.issn"",""1939-0114""
""citation_issn"",""1939-0114""
""dc:title"",""Blockchain as a CA: A Provably Secure Signcryption Scheme Leveraging Blockchains""
""Content-Encoding"",""UTF-8""
""citation_pdf_url"",""https://downloads.hindawi.com/journals/scn/2021/6637402.pdf""
""robots"",""index""
""google-site-verification"",""AxEuDsL7vXGOxRe53-uFhOk2ODN0bbXMeuBy6Pfq4ww""
""citation_author"",""Chen, Tzung-Her"",""Zhu, Ting-Le"",""Jeng, Fuh-Gwo"",""Wang, Chien-Lung""
""dc.date"",""2021/03/26""
""prism.volume"",""2021""
""citation_doi"",""https://doi.org/10.1155/2021/6637402""
""prism.publicationName"",""Security and Communication Networks""
""dc.title"",""Blockchain as a CA: A Provably Secure Signcryption Scheme Leveraging Blockchains""
""Author"",""Hindawi""
""citation_volume"",""2021""
""dc.language"",""en""
""Content-Language"",""en""
""authors"",""Tzung-Her Chen | Ting-Le Zhu | ... | Chien-Lung Wang""
""citation_title"",""Blockchain as a CA: A Provably Secure Signcryption Scheme Leveraging Blockchains""
""citation_year"",""2021""
""citation_publisher"",""Hindawi""
""dc.format"",""text/html""
""description"",""Although encryption and signatures have been two fundamental technologies for cryptosystems, they still receive considerable attention in academia due to the focus on reducing computational costs and communication overhead. In the past decade, applying certificateless signcryption schemes to solve the higher cost of maintaining the certificate chain issued by a certificate authority (CA) has been studied. With the recent increase in the interest in blockchains, signcryption is being revisited as a new possibility. The concepts of a blockchain as a CA and a transaction as a certificate proposed in this paper aim to use a blockchain without CAs or a trusted third party (TTP). The proposed provably secure signcryption scheme implements a designated recipient beforehand such that a sender can cryptographically facilitate the interoperation on the blockchain information with the designated recipient. Thus, the proposed scheme benefits from the following advantages: (1) it removes the high maintenance cost from involving CAs or a TTP, (2) it seamlessly integrates with blockchains, and (3) it provides confidential transactions. This paper also presents the theoretical security analysis and assesses the performance via the simulation results. Upon evaluating the operational cost in real currency based on Ethereum, the experimental results demonstrate that the proposed scheme only requires a small cost as a fee.""
""og:image:type"",""image/jpeg""
""citation_date"",""2021/03/26""
""title"",""Blockchain as a CA: A Provably Secure Signcryption Scheme Leveraging Blockchains"",""Blockchain as a CA: A Provably Secure Signcryption Scheme Leveraging Blockchains""
""twitter:image"",""https://images.hindawi.com/journals/scn/scn.banner.jpg""
""citation_online_date"",""2021/03/26""
""twitter:site"",""website""
""dc.type"",""Research Article""
""dc.source"",""Security and Communication Networks""
""dc.creator"",""Chen, Tzung-Her"",""Zhu, Ting-Le"",""Jeng, Fuh-Gwo"",""Wang, Chien-Lung""
""citation_fulltext_html_url"",""https://www.hindawi.com/journals/scn/2021/6637402/""
""prism.publicationDate"",""2021/03/26""
""Content-Length"",""2229492""
""citation_xml_url"",""https://downloads.hindawi.com/journals/scn/2021/6637402.xml""
""Content-Type"",""text/html; charset=UTF-8""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.html.HtmlParser""
""og:type"",""website""
""twitter:title"",""Blockchain as a CA: A Provably Secure Signcryption Scheme Leveraging Blockchains""
""dc.description"",""Although encryption and signatures have been two fundamental technologies for cryptosystems, they still receive considerable attention in academia due to the focus on reducing computational costs and communication overhead. In the past decade, applying certificateless signcryption schemes to solve the higher cost of maintaining the certificate chain issued by a certificate authority (CA) has been studied. With the recent increase in the interest in blockchains, signcryption is being revisited as a new possibility. The concepts of a blockchain as a CA and a transaction as a certificate proposed in this paper aim to use a blockchain without CAs or a trusted third party (TTP). The proposed provably secure signcryption scheme implements a designated recipient beforehand such that a sender can cryptographically facilitate the interoperation on the blockchain information with the designated recipient. Thus, the proposed scheme benefits from the following advantages: (1) it removes the high maintenance cost from involving CAs or a TTP, (2) it seamlessly integrates with blockchains, and (3) it provides confidential transactions. This paper also presents the theoretical security analysis and assesses the performance via the simulation results. Upon evaluating the operational cost in real currency based on Ethereum, the experimental results demonstrate that the proposed scheme only requires a small cost as a fee.""
""og:title"",""Blockchain as a CA: A Provably Secure Signcryption Scheme Leveraging Blockchains""
""citation_abstract"",""Although encryption and signatures have been two fundamental technologies for cryptosystems, they still receive considerable attention in academia due to the focus on reducing computational costs and communication overhead. In the past decade, applying certificateless signcryption schemes to solve the higher cost of maintaining the certificate chain issued by a certificate authority (CA) has been studied. With the recent increase in the interest in blockchains, signcryption is being revisited as a new possibility. The concepts of a blockchain as a CA and a transaction as a certificate proposed in this paper aim to use a blockchain without CAs or a trusted third party (TTP). The proposed provably secure signcryption scheme implements a designated recipient beforehand such that a sender can cryptographically facilitate the interoperation on the blockchain information with the designated recipient. Thus, the proposed scheme benefits from the following advantages: (1) it removes the high maintenance cost from involving CAs or a TTP, (2) it seamlessly integrates with blockchains, and (3) it provides confidential transactions. This paper also presents the theoretical security analysis and assesses the performance via the simulation results. Upon evaluating the operational cost in real currency based on Ethereum, the experimental results demonstrate that the proposed scheme only requires a small cost as a fee.""
""og:image:height"",""315""
""prism.doi"",""https://doi.org/10.1155/2021/6637402""
""dcterms.issued"",""2021/03/26""
""viewport"",""width=device-width, initial-scale=1""
""twitter:description"",""Although encryption and signatures have been two fundamental technologies for cryptosystems, they still receive considerable attention in academia due to the focus on reducing computational costs and communication overhead. In the past decade, applying certificateless signcryption schemes to solve the higher cost of maintaining the certificate chain issued by a certificate authority (CA) has been studied. With the recent increase in the interest in blockchains, signcryption is being revisited as a new possibility. The concepts of a blockchain as a CA and a transaction as a certificate proposed in this paper aim to use a blockchain without CAs or a trusted third party (TTP). The proposed provably secure signcryption scheme implements a designated recipient beforehand such that a sender can cryptographically facilitate the interoperation on the blockchain information with the designated recipient. Thus, the proposed scheme benefits from the following advantages: (1) it removes the high maintenance cost from involving CAs or a TTP, (2) it seamlessly integrates with blockchains, and (3) it provides confidential transactions. This paper also presents the theoretical security analysis and assesses the performance via the simulation results. Upon evaluating the operational cost in real currency based on Ethereum, the experimental results demonstrate that the proposed scheme only requires a small cost as a fee.""
""dc.identifier"",""https://doi.org/10.1155/2021/6637402""
""prism.section"",""Research Article""
""og:url"",""https://www.hindawi.com/journals/scn/2021/6637402/""
";https://scholar.google.ch/scholar?start=40&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2021
1619099142-497;https://scholar.google.ch/scholar?as_ylo=2021&q=oracles+blockchain&hl=fr&as_sdt=0,5;The Importance of Interoperability, Decentralization, and Choice;K Phillips ; The Emerald Handbook of Blockchain for Business, 2021  emerald.com;;"… Chainlink is blockchain agnostic and eliminates the centralized oracle single point of failure

problem … Oracles are the “data valves” for blockchains making them interoperable with legacy

systems via their … Wallets are an end point in the blockchain and cryptocurrency ecosystem …";Les 3 versions;;null;;;;https://scholar.google.ch/scholar?start=80&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2021
1619099133-468;https://scholar.google.ch/scholar?as_ylo=2021&q=oracles+blockchain&hl=fr&as_sdt=0,5;[PDF][PDF] A Time-Segmented Consortium Blockchain for Robotic Event Registration;V Lopes, M Fernandes, N Pereira, LA Alexandre ; di.ubi.pt;;"… 3.1 Tezos Blockchain Tezos is a self-amending crypto-ledger implemented in Ocaml [6]. Instead

of using a traditional genesis block, this Blockchain starts with a genesis protocol, which contains

a … Query nodes allow queries to the Blockchain and Oracles are external …";;;[PDF] ubi.pt;http://www.di.ubi.pt/~lfbaa/pubs/icbct2021.pdf;"
 
 
 
 
 
 
 
 
 
 

A Time-Segmented Consortium Blockchain for Robotic Event Registration 

 

Vasco Lopes 

NOVA LINCS, Universidade da Beira Interior, vasco.lopes@ubi.pt 

Miguel Fernandes 

INSTITUTO ITALIANO DE TECNOLOGIA, Italy, killazfern@gmail.com 

Nuno Pereira 

NOVA LINCS, Universidade da Beira Interior, nuno.pereira@ubi.pt 

LuĂ­s A. Alexandre 

NOVA LINCS, Universidade da Beira Interior, luis.alexandre@ubi.pt 

 

A blockchain, during its lifetime, records large amounts of data. In a robotics environment, the old information is useful for 

human evaluation, or to perform analysis, but it is not useful for robots that require only current information to continue their 

work. This causes a storage problem in Blockchain nodes as in the case of nodes attached to robots that are usually built 

around embedded solutions. This paper presents a time-segmentation solution for devices with limited storage capacity, 

integrated into a particular robot-directed Blockchain called RobotChain. The experiments conducted show that the goal of 

restricting each node's capacity is reached without compromising all the benefits that arise from the use of Blockchains in 

these contexts and it allows for cheap nodes to use this Blockchain, reducing storage costs and allowing faster deployment 

of new nodes. 

CCS CONCEPTS • Blockchain • Time-Segmented • RobotChain 

ACM Reference Format: 

First Author’s Name, Initials, and Last Name, Second Author’s Name, Initials, and Last Name, and Third Author’s Name, 

Initials, and Last Name. 2018. The Title of the Paper: ACM Conference Proceedings Manuscript Submission Template: This 

is the subtitle of the paper, this document both explains and embodies the submission format for authors using Word. In 

Woodstock ’18: ACM Symposium on Neural Gaze Detection, June 03–05, 2018, Woodstock, NY. ACM, New York, NY, USA, 

10 pages. NOTE: This block will be automatically generated when manuscripts are processed after acceptance. 

1 INTRODUCTION 

Blockchain has gained immense visibility and growth in recent years, due to its capability of enabling digital 

transactions to take place without the limitations of fiat currency. Blockchain allows transactions to take place 

without the need for a central authority, with total transparency, allowing transactions to be audited if the 

Blockchain is public and gives anonymity to the people involved in the transaction. But, the properties that 

Blockchain has, don't only give power to the users involved, but also provide decentralization and immutability 

of the data, and enforce that every transaction is non-repudiable by imposing that all parties must sign their 

data before sending it to the Blockchain. The advent of Blockchain is not only due to the aforementioned 

properties. The first major contribution of this technology was a way to trust a network that may have unknown 

and untrustworthy nodes - the consensus algorithm. The consensus algorithm first introduced by Bitcoin was 



2 

proof-of-work, where all the nodes of the network must solve a cryptographic puzzle in order to validate a 

transaction and earn a reward for validating it. The second major contribution was later presented with further 

development, which are the smart-contracts. Smart-contracts are pieces of software that run autonomously 

inside the Blockchain and as transactions, they are immutable, meaning that they will always perform the same 

way and that they can't be altered or tampered with. The innovation and utility of Blockchain made it a 

technology that is disrupting multiple sectors ranging from financial, to healthcare and robotics [1], [2]. 

In short, Blockchain technology enables the creation of an immutable electronic ledger of information in a 

decentralized way, where every transaction is replicated throughout the network. But, even though this 

technology presents useful properties, the amount of information stored inside it presents a challenge, since it 

continues to grow in time and is never deleted or updated meaning that systems that rely on low-capacity 

devices, such as many robot applications, can't use Blockchain on a long term, since the information to store 

will eventually surpass the capability of such devices and negatively impact the overall performance and 

scalability of the network [3]. Many methods have been proposed to solve the problem of eventually reaching a 

unfeasible Blockchain size by either pruning the blocks or by implementing off-chain protocols to reduce the 

amount of information that is inserted in the main Blockchain by only sending it important information [4]. Those 

approaches are good short to mid-term solutions, as they can reduce the amount of information inserted into 

the Blockchain and give the capability for small devices to be part of a Blockchain network. However, these 

approaches don't solve the long-term problem of Blockchain's growing size. 

In this paper, we propose a novel way to reduce Blockchain sizes - a time-segmented Blockchain approach 

that can be built over a normal Blockchain or over the aforementioned approaches to solve the presented 

issues. The proposed method was designed and evaluated in RobotChain [5], which is a Consortium Blockchain 

designed for Robots, based in the public Blockchain Tezos. The proposed method provides a way to segment 

a Blockchain into segments over time, where each segment of the network is connected to the previous segment 

by a cryptographic hash [6]. This way, the Blockchain maintains its integrity through its life span. In the new 

time-segmented Blockchain, a node can be configured to be either a compute device node, or a cold storage 

node, where a compute device node will only have the current segment, and the cold storage node will work 

with all segments belonging to the Blockchain. This idea allows small devices to participate in the Blockchain 

and also improves the performance, lowers storage costs, and supports faster new node deployment. 

2 RELATED WORK 

Although only recently Blockchain has started to be integrated with Robotics, due to its associated 

problems such as latency in validation and continuous growing size, there are promising proposals that conduct 

this integration. Ferrer [7] presents how Blockchain technology can be used as a mean to improve robot swarms 

and how it can solve occurring problems in such networks, such as data confidentiality, distributed decision 

making and dynamic environment working capacity without master control program modification. 

 In [8] it is shown a conceptualization of how it is possible to share critical information between robots 

using a Blockchain. In this, the idea is that robots insert information about their events and actions in the 

Blockchain about Human-Robot interactions and with that, other Robots improve their models. However, 

byzantine agents in the form of robots can use robotic Blockchains in order to propagate bad information or 

lead others to erroneous actions. Strobel et al. [9] propose a method to solve this problem in swarm robotics 

that use smart-contracts that forces robots to vote in order achieve consensus. Work has been conducted to 



3 

solve the problem of byzantine robots by using a reputation system [10]. With this approach, consensus can be 

achieved, and byzantine robots mitigated. Blockchain has also been successfully used to create coalitions of 

robots by sharing information between them [11]. 

The Blockchain in which we based our work - RobotChain [5], has also been the basis for multiple proposals 

that use it in conjunction with robots to enhance their capabilities. In [12], the authors show how it is possible to 

use Blockchain to safely store robot logs and then use smart-contracts to autonomously detect robot anomalies. 

In [13], is shown how RobotChain can be used to control robots and use smart-contracts to allow external 

parties to communicate with it in order to provide analytics. Last, in [14], a novel way of monitoring robot 

workspaces is proposed, that uses RobotChain to store information about the robots and sensors and then 

uses external parties to conduct image analysis and smart-contracts to adjust the robot's behaviours depending 

on the identity and location of the people surrounding the robots. 

Regarding the Blockchain scalability problem, off-chain methods have been extensively proposed. The 

most effective ones are based on storing information outside the main Blockchain, either by having traditional 

data-bases or secondary chains [15], or by improving the consensus algorithm to reduce the space it requires 

in terms of security protocols and validation time [16]. But by far, the most prominent one, as it is being 

implemented in the biggest public Blockchains, is Lightning Network [17]. The Lightning Network is a payment 

protocol that operates on top of a Blockchain-based cryptocurrency, such as Bitcoin or Ethereum. The idea of 

this protocol is to enable fast transactions between participating nodes. However, this proposals differs from the 

one we present in this paper because: 1) we do not change the consensus algorithm; 2) we do not require off-

chain protocols and 3) the proposed method can be used on different Blockchains, as it is not dependent on a 

Blockchain architecture or protocols but rather on configuring them to allow segmentation. 

3 THE UNDERLYING BLOCKCHAIN 

3.1 Tezos Blockchain 

Tezos is a self-amending crypto-ledger implemented in Ocaml [6]. Instead of using a traditional genesis 

block, this Blockchain starts with a genesis protocol, which contains a genesis block, but this block contains 

functions that allow the amending of the protocol such that it can evolve. This is the base for the main feature 

of this blockchain, which is the fact that it implements a protocol that can adapt itself without the need for a hard 

fork. These amendments work over cycles, and are suggested by submitting proposals to the chain, where 

stakeholders vote on these amendments. These amendments are considered an extremely positive point due 

to the fact that this allows the community to enact changes in the Blockchain, in order to improve it, preventing 

Blockchain hard forks, meaning that the inner features, such as the consensus algorithm, can be changed 

without the need to create a new and separate chain. 

 

3.2 RobotChain 

RobotChain contemplates the use of Blockchain technology in order to solve the problem of keeping accurate 

immutable records of robotic actions in a factory environment. A public Blockchain is not desired, since factory 

environments are private and, as such, management does not allow outside access to its internal information. 

So RobotChain is designed as a Consortium Blockchain: it has many of the advantages of a private Blockchain, 



4 

but instead of a single entity being the leader, it operates under the leadership of a group, to allow for trust to 

be developed among the factory owners and the equipment providers. We need that all the robot manufacturers 

and the factory management, trust the event records, in the case that there is any kind of accident, there is no 

way to tamper the registers. The event records, that are stored in the Blockchain, can be used for further goals 

such as understanding and improving manufacturing productivity. 

Figure 1 presents RobotChain in a schematic way, where each robot is connected to a computation module. 

This is a two-way connection in order to allow robots to send their events and logs to the Blockchain and to 

allow smart-contracts to change robot's behaviours. The use of computational modules serves two purposes: 

1) to ensure a uniform input into the Blockchain, 2) to ensure that robots are not negatively affected with 

additional software running, which could cause degraded performance or other unforeseen consequences. In 

addition, there can be query nodes connected to the Blockchain in order to query it for information or, if allowed, 

insert analytics into smart-contracts. This architecture makes it possible to detect production line bottlenecks, 

to improve management understanding of the factory without directly interfacing with the robotic units, but more 

important, is the fact that RobotChain does not impact in any form the performance of the robots. 

 

 

 

 

Figure 1: RobotChain overview. The compute modules devices serve as interface between robots and RobotChain. Cold 

storage nodes save all the segments of the Blockchain. Query nodes allow queries to the Blockchain and Oracles are 

external entities that interact with the Blockchain through smart-contracts. 

 

Due to the fact that our proposal uses compute devices instead of running its code directly on the robot, the 

embedded compute devices are limited regarding data storage. As such, it is unfeasible to maintain a copy of 

the entirety of the Blockchain on each device in the long term. This paper deals with the fact that, although 

these records are important for the managers of the factories, they are not important for the day-to-day 

processing of the robot, since the logs of what a robot did months ago are not important to its current functioning. 

So, this paper improves upon the original proposal of RobotChain [5], with the introduction of the time-

segmentation proposal. 



5 

3.3 Tezos History Mode 

As of February 2019, Tezos launched a new feature [18] - the history mode, that contains similarities with 

the proposed solution in this paper. This history mode changes how a node keeps its past data, with three 

different modes. These modes rely on the checkpoint feature present in Tezos, where the checkpoints act as a 

regular interval anchor of consensus. The three presented modes are: the archive mode, where the node keeps 

every record, which corresponds to the current Tezos default working mode; the full mode, where the node 

stores all data from the beginning of the chain, but drops information from previous checkpoints but keeping the 

headers and operations from the checkpoints; and the rolling mode, where nodes only keep the latest 

checkpoint, effectively deleting old information. These modes are a configuration parameter of a node in the 

Tezos Blockchain. 

Initialization of the nodes, regardless of the activated mode, is still based on the regular Blockchain 

synchronization method via peer-to-peer or with the new snapshot feature which consists on a file import/export. 

 

4 TIME-SEGMENTATION IMPLEMENTATION 

4.1 Overview 

Our proposal of time-segmentation of a Blockchain consists in creating linked sub-Blockchains, referred to 

as segments throughout the paper, allowing compute devices with low storage capacity, the possibility to keep 

only the latest segment instead of the entire Blockchain, while maintaining the non-modification of the chain 

itself. Non-modification is ensured via the first block on the new segment, in our case, the RobotChain protocol 

activation, containing the segment identifier (an integer) and the hash of the last block of the previous segment. 

A second block is also created at the same time, in order to re-insert the smart-contracts present on the previous 

segment. 

With this approach, three types of nodes are now introduced: the genesis node, the cold storage nodes and 

the compute device nodes. Genesis nodes are meant to serve as a bootstrap point, protocol activation and 

smart-contract initialization and cold storage of the previous segments. The cold storage type is meant to only 

store all the segments, to retrieve older segments when needed and to aid the bootstrap process. The compute 

devices nodes are the interface between the Blockchain and the robots. This solution is proposed to solve the 

storage limitation of the compute devices and the fact that the older blocks are not entirely relevant to the 

continuous processing of the robot in a factory. This allows compute devices with possibly small storage 

capacity to support a Blockchain solution for an arbitrarily long time period. Note that the number of cold storage 

nodes is typically much smaller than the number of compute device nodes and that this proposal maintains a 

chained link to the genesis block, which continues to allow amendment processes and that the cryptographic 

hash to the predecessor segment re-forces the security and the immutability of the Blockchain. 

In the new developed Blockchain, the modifications are enacted on the Tezos Blockchain version with the 

history mode and all the three types of nodes (cold storage node, genesis node and compute device node) are 

run in the archive mode that was presented earlier. But, as the modifications made are protocol agnostic, the 

Blockchain can be updated to future newer versions of Tezos or even downgraded and still work as defined. 



6 

4.2 Segment Creation Process 

The first segment, segment 1, starts the network as a regular Blockchain, with the activation block receiving 

as parameters the segment ID, and the original genesis block hash. Then, on its 𝑛 − 𝑡ℎ block, the Blockchain 

increments the segment ID on the node's configuration file and shuts down the validation and database part of 

the Blockchain but leaving the peer-to-peer interface online. Such that there is no need to rediscover peers.  

The state and validation are then reactivated with the updated configuration file, creating a new segment 

from scratch. The genesis node then activates the protocol, receiving as parameter the current segment ID, the 

predecessor segment hash and the hash from the last block of the previous segment, with the other nodes 

receiving this activation and resuming normal operations. The first block is then used to initialize smart-contracts 

present on the previous segment and other features needed. Figure 2 presents this process in a visual way. 

 

 

Figure 2: Visual representation of the time-segmentation process’s flow. The red arrows represent the use of hashes to 

allow inter-segment connectivity. Each activation block has the current segment id and the hash of the last block of the 

previous segment. In the first segment, the predecessor hash is the genesis block hash, making segment 1 the “genesis 

segment”. 

 

A new computing device node that joins the Blockchain, it will only synchronize the latest segment, the one 

that is currently running on the network. In the case that the segmentation process happens before the bootstrap 

finishes, the node receives a reboot signal sent by the genesis node that instructs the node to create the new 

segment as described previously. In the case that the new node is a cold storage node, the node will 

synchronize previous segments and keep the previous segments stored instead of deleting them. 

The presented approach has some similarities to the new Tezos history mode, where the compute device 

nodes would correspond to Tezos nodes running in the rolling mode and the cold storage nodes would work as 

the archive mode. But, there are several differences between our proposal and the Tezos history mode, such 

as node initialization, where the node has to synchronize from the genesis block up to the current information, 

or use the snapshot feature introduced. In the case of a factory fast pace environment, creating snapshots and 

waiting for new elements to catch-up in order to start operations is feasible but not practical, which is what 

Tezos history mode requires. 



7 

Our solution has the advantage of only needing to synchronize the latest segment, without the need to 

request older segment information, with the sole exception of the activation node's previous segment hash that 

is needed for protocol activation only once per segment. This advantage counterpoints the need of 

synchronizing the entirety of the Blockchain data from a snapshot generated from a full/archive node and results 

on a long-term approach to mitigate the growing size of Blockchains in small devices, as opposed to traditional 

approaches that conduct off-chain operations or compression algorithms, which can also be integrated in our 

approach. 

 

5 EXPERIMENTAL RESULTS 

5.1 Compute Device Node Storage 

Experiments were conducted to evaluate the storage requirements of our proposal, comparing the 

unsegmented Blockchain, running the three node versions (archive, full, rolling) and the proposed approach 

configured as full, to build the segmented Blockchain, segmenting Blockchain every 10 blocks. 

The tests were ran varying the total number of blocks. Random transactions were injected into the network 

up to a maximum of 32 transaction clients running simultaneously. These clients inject a transaction between 

random accounts, with value 1 and transaction description with minimum 1000 random characters. 

The storage test results are shown in Figure 3. In this, is shown that the proposed method uses an average 

size of 2282 Kilobytes per segment, having a definite hard limit for the maximum storage occupied by each 

segment, using 10 as the number of blocks per segment, which is a small number in order to force segments 

to be created often. The fact that our proposal fixes a maximum size per segment allows the Blockchain to 

increase its longevity arbitrarily. It also aids with bootstrap due to the fact that a new node won't need to obtain 

every segment from the start, needing only the latest one to work. Moreover, the size of the rolling mode is not 

only higher in each node, but the overall Blockchain size continues to heavily grow over time. 

 

 



8 

Figure 3: Storage size on each compute device node (not cold storage), for four versions of the Blockchain, as a function of 

the number of blocks. The segmented Blockchain running mode is archive. The left figure presents the results for the four 

tests. The right figure presents the results for the rolling mode and the segmentation version, for improved comparison. 

 

With the ability of creating segments limited with respect to the necessary storage space, RAM disk execution 
on the compute devices is a possibility which improves the Blockchain speed. 

5.2 Cold Storage Node 

Additional experiments were made to understand how the segmentation affected the storage capabilities of 

both the compute device nodes and the cold storage nodes, and how the network would grow with the various 

segments, considering the repeated addition of the genesis and activation blocks to each segment. The tests 

were ran for 20, 50, 100, 250 blocks per segment with a total of 1000 blocks per experiment. As with the 

previous experiment, random transactions were injected into the network up to a maximum of 32 transaction 

clients running simultaneously. The rule for these clients is to inject a transaction between random accounts, 

with a value of 1, and with a transaction description with a minimum 1000 random characters. The storage 

results are presented in Figure 4. 

The segmentation approach has a smaller running storage footprint, with cold storage space occupied similar 

to the archive node and depending on the value for the number of segments per block, the resulting space 

occupied can even be inferior to the rolling mode. As referred, our approach as the benefit of providing a definite 

hard limit for the segments, with a cold storage space occupied similar to a node running archive mode, 

considering the increased number of blocks with the added genesis and activation block. In addition, defining 

an appropriate segment value like 100, can also translate into a smaller size per segment when compared to 

other modes. This approach has also the advantage of not requiring bootstrapping the entire network and just 

needing the latest segment. 

 

Figure 4: The left figure presents the compute device storage size as a function of the number of blocks per segment for a 

total of 1000 blocks, compared with the corresponding rolling mode storage size of the Tezos Blockchain. The right figure 

presents the cold storage size as a number of blocks per segment for a total of 1000 blocks, compared with the archive 

mode of the Tezos Blockchain. Results for full mode are not presented since they are not comparable to any of the node 

types on our approach. 

 



9 

 

Finally it is important to state that both the cold storage node and the compute device node are both 

running in archive mode and that Tezos rolling mode does not guarantee a fixed maximum node memory size, 

and the memory requirements slowly grow as can be seen in Figure 3-right. This invalidates the Tezos rolling 

mode as a solution to the limited capacity of the said nodes, since the rolling mode would eventually exhaust 

the available memory and the network would stop working. 

 

6 CONCLUSION 

This paper proposes a method that improves upon the original proposal of RobotChain [5], a robotic event 

storage solution, that enables robot monitoring, control, and cooperation, with the introduction of the time-

segmentation proposal to solve problems related to small storage capacity of compute modules. This allows 

the use of cheap compute modules for the majority of network nodes (all but the cold storage ones) and makes 

the processing and connection of new nodes faster both by allowing the use of faster memory for storing the 

segment and also because only the current segment is needed for syncing the new node with the network. The 

solution presented allows the creation of a time-segmented Blockchain that has a definite hard limit on the 

segments storage capacity, that is independent of how long the Blockchain has run for, which can increase 

arbitrarily the longevity of the Blockchain. 

As future work, other features related to this time-segmentation solution can be implemented, such as 

RPC interfaces for block retrieval of previous segments, and the possibility of defining a different number of 

blocks per segment on a node-to-node basis, that could be useful for accommodating nodes with different 

capabilities. 

 

ACKNOWLEDGMENTS 

This work was partially supported by the Tezos Fundation through a grant for project Robotchain and partially 

supported by project 026653 (POCI-01-0247-FEDER-026653) INDTECH 4.0 – New technologies for smart 

manufacturing, cofinanced by the Portugal 2020 Program (PT 2020), Compete 2020 Program and the European 

Union through the European Regional Development Fund (ERDF). 

REFERENCES 

[1] I. Afanasyev, A. Kolotov, R. Rezin, K. Danilov, A. Kashevnik, and V. Jotsov, “Blockchain solutions for multiagent robotic systems:  Related 

work and open questions,” 2019. 

[2] V. Lopes and L. A. Alexandre, “An Overview of Blockchain Integration with Robotics and Artificial Intelligence,” Ledger, vol. 4, Apr 2019. 

[3] K. Salah, M. H. U. Rehman, N. Nizamuddin, and A. Al-Fuqaha, “Blockchain for ai: review and open research challenges”, IEEE Access, 

vol. 7, pp. 10 127–10 149,2019 

[4] J.  Eberhardt and S.  Tai, “On or off the blockchain? insights on off-chaining computation and data,” in European Conference on Service-

Oriented and Cloud Computing. Springer, 2017, pp. 3–15.  

[5] M. Fernandes and L. A. Alexandre, “RobotChain: Using Tezos Technology for Robot Event Management,” 2018. 

[6] L.  Goodman, “White paper:  Tezos - a self-amending crypto-ledger,” 2014. 

[7] E.  C.  Ferrer, “The blockchain:  a new framework for robotic swarm systems,” in Proceedings of the Future Technologies Conference 

Springer, 2018, pp. 1037–1058 

[8] E. C. Ferrer, O. Rudovic, T. Hardjono, and A. Pentland, “RoboChain:  A Secure Data-Sharing Framework for Human-Robot Interaction,” 



10 

feb 2018. 

[9] V. Strobel, E. Castello Ferrer, and M. Dorigo, “Managing Byzantine Robots via Blockchain Technology in a Swarm Robotics Collective 

Decision-Making Scenario,” Tech. Rep., 2018. 

[10] V. Strobel and M. Dorigo, “Blockchain technology for robot swarms: A shared knowledge and reputation management system for collective 

estimation,” in Swarm Intelligence: 11th International Conference, ANTS, 2018. 

[11] N. Teslya and A.  Smirnov, “Blockchain-based frame-work for ontology-oriented robots’ coalition formation in cyberphysical systems,” in 

MATEC Web of Conferences, vol. 161. EDP Sciences, 2018, p. 03018. 

[12] V. Lopes   and L. A. Alexandre, “Detecting Robotic Anomalies Using RobotChain,” in 2019 IEEE International Conference on Autonomous 

Robot Systems and Competitions (ICARSC), April 2019. 

[13] V. Lopes, L. A. Alexandre, and N. Pereira, “Controlling Robots using Artificial Intelligence and a Consortium Blockchain,” p. 

arXiv:1903.00660, 2019. 

[14] V.  Lopes, N. Pereira, and L. A. Alexandre, “Robot Workspace monitoring using a Blockchain-based 3D Vision Approach,” in Proceedings 

of the IEEE Conference on Computer Vision and Pattern Recognition Workshops, 2019. 

[15] 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. ACM, 2018, pp. 7–12. 

[16] Z. Zheng, S. Xie, H. Dai, X. Chen, and H. Wang, “An overview of blockchain technology: Architecture, consensus, and future trends,” in 

2017 IEEE International Congress on Big Data (BigData Congress). IEEE,2017, pp. 557–564. 

[17] J.  Poon and T.  Dryja, “The bitcoin lightning network: Scalable off-chain instant payments”, 2016. 

[18] Nomadic Labs. (2019) Introducing snapshots and his-tory modes for the tezos node. 


";"""date"",""2021-02-03T14:40:37Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.7""
""xmp:CreatorTool"",""MicrosoftÂŽ Word para Microsoft 365""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dc:creator"",""Power Edit 6.0""
""language"",""en""
""dcterms:created"",""2021-02-03T14:40:37Z""
""Last-Modified"",""2021-02-03T14:40:37Z""
""dcterms:modified"",""2021-02-03T14:40:37Z""
""dc:format"",""application/pdf; version=1.7""
""xmpMM:DocumentID"",""uuid:2EE41A7D-BE0B-4B4F-B6F2-8FC013B09802""
""Last-Save-Date"",""2021-02-03T14:40:37Z""
""pdf:docinfo:creator_tool"",""MicrosoftÂŽ Word para Microsoft 365""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2021-02-03T14:40:37Z""
""meta:save-date"",""2021-02-03T14:40:37Z""
""pdf:encrypted"",""false""
""xmp:CreateDate"",""2021-02-03T14:40:37Z""
""modified"",""2021-02-03T14:40:37Z""
""Content-Length"",""390862""
""pdf:hasMarkedContent"",""true""
""Content-Type"",""application/pdf""
""xmp:ModifyDate"",""2021-02-03T14:40:37Z""
""pdf:docinfo:creator"",""Power Edit 6.0""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Power Edit 6.0""
""dc:language"",""pt-PT""
""meta:author"",""Power Edit 6.0""
""pdf:producer"",""MicrosoftÂŽ Word para Microsoft 365""
""meta:creation-date"",""2021-02-03T14:40:37Z""
""created"",""2021-02-03T14:40:37Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""10""
""Creation-Date"",""2021-02-03T14:40:37Z""
""resourceName"",""icbct2021.pdf""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""2938"",""4158"",""3597"",""2478"",""3455"",""2590"",""2070"",""2656"",""3303"",""1826""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""Author"",""Power Edit 6.0""
""producer"",""MicrosoftÂŽ Word para Microsoft 365""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""MicrosoftÂŽ Word para Microsoft 365""
""pdf:docinfo:created"",""2021-02-03T14:40:37Z""
";https://scholar.google.ch/scholar?start=60&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2021
1619099138-484;https://scholar.google.ch/scholar?as_ylo=2021&q=oracles+blockchain&hl=fr&as_sdt=0,5;Dynamic Curves for Decentralized Autonomous Cryptocurrency Exchanges;B Krishnamachari, Q Feng, E Grippo ; arXiv preprint arXiv:2101.02778, 2021  arxiv.org;;"… and many others im- plement a liquidity pool (LP) using smart contracts on a blockchain … closing

pool and market price gap can be mitigated by incorporating reliable oracles to protect … 4]. To

protect liquidity providers, Bancor v2 integrates with Chain- link price oracle to reduce …";Cité 1 fois;Les 5 versions;[PDF] arxiv.org;https://arxiv.org/pdf/2101.02778;"
Dynamic Curves for Decentralized Autonomous
Cryptocurrency Exchanges

Bhaskar Krishnamachari, Qi Feng, Eugenio Grippo
Department of Electrical and Computer Engineering,

Viterbi School of Engineering
University of Southern California

Abstract—One of the exciting recent developments in decen-
tralized finance (DeFi) has been the development of decentralized
cryptocurrency exchanges that can autonomously handle conver-
sion between different cryptocurrencies. Decentralized exchange
protocols such as Uniswap, Curve and other types of Automated
Market Makers (AMMs) maintain a liquidity pool (LP) of two or
more assets constrained to maintain at all times a mathematical
relation to each other, defined by a given function or curve.
Examples of such functions are the constant-sum and constant-
product AMMs. Existing systems however suffer from several
challenges. They require external arbitrageurs to restore the
price of tokens in the pool to match the market price. Such
activities can potentially drain resources from the liquidity pool.
In particular dramatic market price changes can result in low
liquidity with respect to one or more of the assets and reduce the
total value of the LP. We propose in this work a new approach
to constructing the AMM by proposing the idea of dynamic
curves. It utilizes input from a market price oracle to modify
the mathematical relationship between the assets so that the pool
price continuously and automatically adjusts to be identical to the
market price. This approach eliminates arbitrage opportunities
and, as we show through simulations, maintains liquidity in the
LP for all assets and the total value of the LP over a wide range
of market prices.

I. INTRODUCTION

Since the introduction of Bitcoin as the first peer-to-peer
digital cash [1], the birth of different cryptocurrencies has
revolutionized the world of finance [2]. As of the time of
writing this article, it is estimated that the total cryptocurrency
market capitalization is more than $600 Billion, involving
thousands of different coins [3].

Traditionally, cryptocurrency exchanges, which use an order
book mechanism, are centralized. They suffer from concerns
about the concentration of financial power [4] and being
prone to a single point of failure, resulting in a potentially
significant loss of funds when attacked [5]. Additionally, they
also pose a liquidity problem for tokens with a smaller market
capitalization resulting in barriers to entry to the financial
market [4].

On the other hand, it is difficult to implement the order
book model in a decentralized manner in the form of a
blockchain smart contract [6] [5]. First, market makers will
face high gas costs to execute transactions, regardless of their
sizes [6]. Second, it will require a complex matching algorithm
to support a variety of order types [5].

Automated Market Makers such as Hanson’s logarithmic
market scoring rules (LMSRs) are widely used in traditional

prediction markets to address the problem of low liquidity
and trading volume [7], [8]. An LMSR-based AMM is also
used in decentralized prediction markets such as Gnosis [9]
and Augur [10]. Given certain similar market characteristics,
curve-based Automated Market Makers (AMM) were recently
introduced to address the challenges in a currency exchange
context. They are currently one of the areas of decentralized
finance receiving the most attention. Instead of relying on the
traditional market makers to provide liquidity, decentralized
exchanges utilizing curve-based AMMs, such as Bancor [4],
Uniswap [11], StableSwap/Curve [12] and many others im-
plement a liquidity pool (LP) using smart contracts on a
blockchain. In this model, liquidity providers supply single or
multiple types of tokens to the designated liquidity pools, and
traders exchange against the pools of tokens instead of relying
on order matching. The liquidity pool of these AMMs track
a pre-defined mathematical function (curve), thus determining
how many tokens of one type to provide to a trader in exchange
for a certain amount of another. Curve-based AMMs provide
a continuous supply of liquidity compared to the order book
model. Additionally, depending on the mathematical function
(curve) utilized, they can potentially allow for a wide range of
exchange prices. However, the token price within a liquidity
pool for a given AMM (which we refer to as the pool price)
might be different from the market price.

When such a gap occurs on a decentralized AMM-based
exchange, arbitrageurs may have the opportunity to buy or sell
tokens to set the pool price equal to the market price, restoring
equilibrium. However, in some cases, particularly when the
market price changes dramatically, the AMM-based LP could
lose liquidity with respect to one or more of the assets. We
propose in this work a new approach to constructing the AMM
by proposing the idea of dynamic curves. It utilizes input from
a market price oracle to modify the mathematical relationship
between the assets so that the pool price continuously and
automatically adjusts to be identical to the market price. This
eliminates arbitrage opportunities and, as we show through
simulations, helps the AMM-based LP maintain liquidity and
total value over a wide range of market prices.

The following are the key contributions of this work:
• We present a simple and unified mathematical and con-

ceptual framework (in section III) describing existing
curve-based AMMs and key metrics such as pool price,
slippage, divergence loss. It unifies much of what is

ar
X

iv
:2

10
1.

02
77

8v
1 

 [
q-

fi
n.

T
R

] 
 7

 J
an

 2
02

1



known about them today. We believe this section will
be of independent interest to researchers starting out in
this area.

• We focus on the liquidity problem posed by arbitrageurs
on existing AMMs, especially when the market price
for one of the assets becomes too high, causing asset
depletion and value reduction of the liquidity pool.

• We present a new dynamic curve mechanism, which is
general enough to be adapted to any monotonic func-
tion/curve used on an AMM. This mechanism relies on an
external market price oracle and eliminates arbitrageurs.
We illustrate the mechanism concretely through gen-
eralizations of both constant-sum and constant-product
models.

• We present numerical simulations showing the clear ad-
vantages of our proposed dynamic curve mechanism in
a) retaining greater liquidity in the pool to benefit small
traders, b) retaining greater total value in the liquidity
pool, and c) functioning effectively over a much larger
range of market prices.

The rest of this paper is organized as follows: we present
and discuss relevant prior work in section II. In section III
we give a unified treatment and definition of key concepts
and metrics relevant to decentralized AMMs. In section IV
we propose and describe our new dynamic AMM models. In
section V we present agent-based simulations and compare
the performance of four different AMMs, including two static
AMMs (Constant- Sum AMM, Constant-Product AMM) and
their two dynamic generalizations that we introduce in this
work. We present concluding comments in section VI.

II. RELATED WORK

Bancor was the first DEX to implement the type of AMM
called Bonding Curve, which provides continuous liquidity
[4]. In this type of AMM, there is a single token (Bancor
Network Token - BNT) used as an intermediate currency.
There are separate pools for each non-native currency to be
traded against BNT. This model is a little different from the
arbitrary two-asset curve based AMM’s that we focus on in
this paper (though there are significant connections as well).
In curve-based AMMs, any two currencies could be traded
directly against each other.

Borrowing solutions from the prediction market, Bu-
terin [13] first proposed such a curve-based AMM for a
decentralized exchange. Specifically, he proposed the Constant
Product Curve. It is a convex curve that takes the form of
x ¡ y = k, where x and y are the total supply of two tokens
in a liquidity pool and k is the product constant. It was
subsequently implemented by Adams et al. [11] to create
Uniswap.

With the shape of a downward-sloping straight line, the
Constant Sum Curve [14][15] takes the form of x+ y = k. x
and y are the total supply of two tokens in a liquidity pool, and
k is the sum constant. StableSwap/Curve [12] implemented an
AMM curve that is a blend of Constant Sum and Constant

Product to provide continuous liquidity, price stability and a
built-in pool balancing mechanism.

Wang [8] proposed the Constant Ellipse Curve AMM with
the general form of (x−a)2+(y−a)2+b·xy = C, in which a
and b are constant. One can choose between the concave and
the convex curve in the first quadrant [8]. Wang also presents
the curve corresponding to the LMSR rule.

Angeris and Chitra analyze such curve-based AMMs, which
they refer to as constant function market makers in the general
case, i.e., with arbitrarily many tokens [16]. They analyze
various mathematical properties of such AMMs, including
formulating the optimal arbitrage by traders as a convex
optimization problem.

A. Performance metrics for AMMs

Slippage and divergence loss are the two main factors
contributing to the proposal and adoption of different AMMs.
The former is directly tied to the loss of traders, while the
latter is directly connected to the liquidity providers’ returns.

Slippage is the difference between the expected and actual
trade execution price [17], and in the AMM context, it is
defined as the gap between the pool price before a trade and
the effective price obtained for the trade (see section III-C).
As long as token price changes during trade, slippage incurs.
In addition, when large trades happen compared to pool size,
slippage increases dramatically, resulting in lower trading
profits [18].

Divergence loss, sometimes called impermanent loss, incurs
when liquidity providers withdraw liquidity with the presence
of a difference in token price before and after trades [19].
If funds are pulled out during a large price swing, liquidity
providers will suffer a loss of total asset value, compared
to simply holding the assets [20]. Given trades might affect
token pool prices and hence divergence loss, it is important to
distinguish between regular and arbitrage trading. Divergence
loss due to arbitrage trading in closing pool and market price
gap can be mitigated by incorporating reliable oracles to
protect liquidity providers [21].

B. Slippage and Divergence Loss in AMMs

In Bancor, given the dynamic pool price by design, trades
experience slippage. Divergence loss incurs as the pool price
is intrinsic and relies on arbitrageurs to close price gaps [4]. To
protect liquidity providers, Bancor v2 integrates with Chain-
link price oracle to reduce divergence loss from arbitraging
[21].

In Uniswap, similar to Bancor, the pool price is inherently
unstable and the size of trades in relation to pool size affects
pool price to different extents. The larger the trades are, the
higher slippage and divergence loss can occur.

The constant-sum curve has zero slippage [14][15] and no
divergence loss (as we show in section III). However, because
it has a fixed price and finite liquidity, it is only suitable for
stablecoins and could easily be depleted of one of its pool
assets; for this reason, it is primarily of theoretical interest
[14][15]. We use it as a baseline in our work.



StableSwap/Curve introduces an invariant that allows trad-
ing on a Constant Sum shaped curve when the portfolio is
relatively balanced and switch trading to a Constant Product
shaped curve when imbalanced [12]. Such a design allows
much lower slippage and divergence loss but is only applicable
to stablecoins as the price of the desired trading range is
always close to 1.

The constant ellipse curve introduced by Wang [8] has a
fixed price range compared to that of a Constant Product Curve
and thus a fixed range of slippage and divergence loss. Wang
also concludes that the LMSR curve would not be suitable for
exchanges if the numbers of the two tokens are not balanced
in the liquidity pool.

The proposal in this paper presents an approach for AMM-
based decentralized exchanges using dynamic curves that
eliminates the possibility of arbitrage and thus any divergence
loss. Instead, as we show, depending on the chosen family of
curves, any slippage loss incurred by traders is converted to an
equivalent gain for the liquidity providers. A dynamic version
of the constant sum curve is a special case of our proposed
solution, and in that case, there is no slippage loss at all.

C. Simulation

There are two simulations conducted respectively on Sta-
bleSwap/Curve and Uniswap v1 to evaluate the DEXes perfor-
mance. Egorov [12] suggests that StableSwap/Curve generates
312% APR and 0.06% fee per trade for liquidity providers
with total liquidity of $30000 in DAI, USDC and USTD over
6 months. Angeris et al. [5] conduct an agent-based simulation
to test the hypothesis that Uniswap has a robust market mech-
anism with little arbitrage opportunities under various market
conditions. Three types of agents, including profit-maximizing
arbitrageurs, traders with exogenous motives and liquidity
providers (both active/Markowitz portfolio optimizing and
passive), interact in the Uniswap and a stochastic reference
markets. The results show that Uniswap tracks market prices
closely in different market environments, and Constant Product
Curves have the potential to be price oracles [5].

III. BACKGROUND - AMM CURVES AND KEY METRICS

Consider a liquidity pool with two coins, whose amounts are
denoted by x and y. For convenience, we will refer to these
two tokens as X and Y . The AMM will allow the exchange of
one token for another following a given function f as follows:

y = f(x) (1)

We refer to a plot of this function showing all allowed
combinations of y and x as the AMM curve. For example,
there can be a constant product curve, which is y = k

x or a
constant sum curve, which would be denoted as y = c− x. It
is generally considered reasonable for the AMM curve to be
convex and monotonically decreasing because this ensures (as
we shall see in the next section) that the price for the token
X is monotonically decreasing as a function of its availability
in the pool, as should be expected of a typical supply curve.

Fig. 1. Illustration of Price Slippage on a Trade

A. Price and Bonding Curve

Given an AMM curve, we can derive the price of the X
token as follows:

pX(x, y) = −dy
dx

(2)

For example, for the constant product curve, we would get
pX(x, y) = k

x2 and likewise for the constant sum curve, we
would get that pX(x, y) = 1.

A plot of pX(x, y) versus x shows how the price of token
X varies with its supply in the liquidity pool. Such a curve
is referred to as a bonding curve or as a price curve. Note
that if f(x) is monotonically decreasing, then the price will
always be positive, and if f(x) is convex, then the bonding
curve will be monotonically decreasing (as it should, being a
type of supply curve).

B. Value of the pool

Given the definition of price, we can also assess the value
of a given liquidity pool (measured in terms of Y ) as follows:

Vp(x, y) = pX ¡ x+ y (3)

C. Slippage

For curve-based AMM, slippage is defined as the loss
incurred by a trader due to the price mismatch between the
pool price at which the trade is initiated and the effective price
obtained during the trade. Let us consider a trader seeking to
buy ∆x units of token X when the LP is at a state (x0, y0).
Say that on the curve, the new point after the trade will be
(xn, yn), where xn = x0 − ∆x. The amount that the trader
would then need to put into the LP will be ∆y = yn − y0.
If the pool price at the original point was p0, then the buyer
would have to pay ∆y0 = p0∆x. The difference between ∆y
and ∆y0 is defined as the slippage loss S(x0, y0,∆x). This is
illustrated in figure 1.

Similarly, when the trader wishes to sell ∆x units of token
X , the gap between the ∆y0 = p0∆x that the trader would
like to receive and the ∆y = y0 − yn that he will actually
receive would be the slippage loss on the sale, which could
be expressed as S(x0, y0,−∆x).



It is easy to see that on a constant sum AMM, the slippage
loss is always 0 (because the price is constant at all points
on the curve, or, equivalently, the tangent line at any point
and the AMM curve always coincide). On any strictly convex
curve, because the tangent line is always below the curve, the
slippage loss will always be a positive quantity (i.e., the trader
always incurs a penalty). The total slippage will be higher for
a larger trade, and therefore acts as a disincentive for a trader
to make large trades with the LP.

D. Divergence Loss
In general, when a trade is made, the price may change,

as the original pair of values (xo, yo) moves to a new pair
(xn, yn) following the curve, resulting in a new price pn.
Accordingly, the value of the liquidity pool could potentially
decrease after a trade. This decrease as a relative or percentage
decrease is referred to as divergence loss δ, and can be
formally defined as follows:

δ =
Vpn

(xn, yn)− Vpn
(x0, y0)

Vpn(x0, y0)
(4)

We work out below the divergence loss for the two example
curves.

1) Divergence loss for constant-product curve: For the
constant product curve, recall that the following hold:

pn(xn, yn) =
k

x2n
=⇒ xn =

√
k
pn

(5)

yn =
k

xn
=⇒ yn =

√
k ¡ pn (6)

Similarly, we also have that xo =
√

k
po

and yo =
√
k ¡ po.

Then we can define Vpn(xn, yn) as follows:

Vpn
(xn, yn) = pn ¡ xn + yn

= pn

√
k

pn
+
√
k ¡ pn

= 2
√
k ¡ pn (7)

Likewise, we can define Vpn
(xo, yo) as follows:

Vpn(xo, yo) = pn ¡ xo + yo

= pn

√
k

po
+
√
k ¡ po

(8)

Based on the above two equations, we can calculate the
divergence loss as follows:

δ =
2
√
k · pn − pn

√
k
po

+
√
k ¡ po

pn

√
k
po

+
√
k ¡ po

(9)

Denoting by ρ the ratio of the two prices pn

po
, the divergence

loss for the constant product curve can be simplified to:

δ =
2
√
ρ− 1− ρ
1 + ρ

(10)

This result is given in [19].

2) Divergence loss for constant-sum curve: Here the price
is always 1. The two values can be written as follows:

Vpn
(xo, yo) = xo + yo = c

Vpn
(xn, yn) = xn + yn = c (11)

Since both are the same, the liquidity pool does not show
any change in value, and thus the divergence loss in this case
will be 0.

IV. DYNAMIC CURVES

In the prior work on AMMs, the curve has a fixed form and
the exact shape is determined by the initial total liquidity. E.g.,
in the constant product curve, the parameter k = xi ¡ yi where
xi, yi are the initial amounts of the two tokens. In other words,
the curve can only change if the liquidity providers add/remove
tokens from the pool, but not from trading activity.

Consider a trade that happens while the market price of
token X remains unchanged at some price pmkt. If the pool
changes from the state (xo, yo) to a new state (xn, yn), then
the pool price would potentially change from p(xo, yo) to
p(xn, yn) (assuming the curve is not the constant-sum curve
in which case there is no change in the pool price). This can
result in at least a temporary difference between the pool price
and the market price. As we do in the rest of the paper, we are
assuming here that the pool’s capitalization is a relatively small
fraction of the total market capitalization of the underlying
assets so that the market price is not determined or affected
by the pool price.

Another reason for a temporary difference between the pool
price and the market price could be that the market price
changes due to some external market conditions. In either case,
traditionally, it is expected that these temporary differences
will be erased by the action of arbitrageurs, restoring the pool
price back to the market price.

We propose a new mechanism that instead changes the curve
every time the market price changes in such a way as to ensure
that the current pool price will always equal the market price,
without requiring action by external arbitrageurs. We illustrate
below how this new mechanism would generalize the constant-
product and constant-sum curves – the same approach can be
used to generalize other smooth, decreasing, convex curves to
the dynamic setting as well.

A. Dynamic curve adjustment to generalize constant-sum

In this case, we can describe the market-price-tracking
dynamic curve as follows:

pmkt(t) · (x(t)− a(t)) + y(t) = c (12)

Here, the parameter a(t) will also be adjusted dynamically
when the market price changes, to ensure that the new linear
curve passes through the current pair of (x(t), y(t)) values. For
simplicity, say the market is initialized at some pair (x(0), y(0)
at a market price of 1. Then c could be set to be x(0) + y(0),
with the original a(0) = 0.



If the market shifts to a price of pmkt(t) at some time t and
the liquidity pool at this arbitrary time is (x(t), y(t)), then the
value of a(t) will also be adjusted as follows to match the
above dynamic curve:

a(t) = x(t)− c− y(t)

pmkt(t)
(13)

Intuitively, this dynamic curve is always a line that has the
slope corresponding to the current market price and always
passing through the current liqudity pair (x(t), y(t)).

Any trade that happens uses the current (instantaneous)
curve. This allows the constant sum AMM to flexibly support a
wider range of market prices while still providing 0 slippage
compared to the original design (which allows only a fixed
pool price and thus will not work when the market price is
dramatically different).

B. Dynamic curve adjustment to generalize constant-product

In this case, we can describe the market-price-tracking
dynamic curve as follows:

w(t) · (x(t)− a(t)) · y(t) = k (14)

Or alternatively, as:

y(t) =

k
w(t)

x(t)− a(t)
(15)

Note that in the above expressions, x(t) and y(t) must
always be strictly positive; a(t) must be constrained to be
always strictly less than x(t); and w(t) should always be
strictly positive. The instantaneous price corresponding to the
dynamic version of the constant product curve can be defined
as follows:

pX(t) =
k

w(t)
¡ 1

(x− a(t))2
(16)

When the market price changes, then both w(t) and a(t)
will have to be changed in order to (a) make sure that the new
market price pmkt(t) matches pX(t) in equation (16) and (b)
x(t),y(t) match the curve described in equation (14). Thus we
have to solve two equations and two unknowns. The solution
turns out to be the following :

a(t) = x(t)− y(t)

pmkt(t)

w(t) =
k ¡ pmkt(t)

y(t)2
(17)

We remark: the first expression above ensures the require-
ment mentioned above that a(t) will remain strictly less than
x(t) and the second expression ensures that w(t) is strictly
positive, so long as k, pmkt(t), x(t) and y(t) are all kept
strictly positive at all.

C. From divergence loss to slippage gain

As with the static setting, there is no slippage loss for traders
or divergence loss in the case of dynamic constant sum AMM.
This is because in the absence of any change in market price,
the pool price does not change during a trade.

In the case of the dynamic constant product AMM, the
traders do experience a slippage loss just like in the static
constant product AMM case. However, corresponding gain in
value is accrued entirely to the liquidity pool and could be
referred to as a slippage gain for the LP. Further, in the absence
of change in the market price, because the pool price does
not change in the dynamic constant product curve, there is no
divergence loss. Rather, the LP benefits from each trade by the
same slippage gain. Thus, the dynamic constant product AMM
provides a strict improvement from the LP’s perspective. This
result, in fact, generalizes to the dynamic version of any strictly
convex curve, as we show below.

Theorem 1. In a dynamic AMM based on a family of
monotonically decreasing y = f(x) curves that are strictly
convex, when the market price remains fixed, the LP will gain
value after each trade by an amount equivalent to the slippage
loss of the trader.

Proof. Assuming the market price does not change during
a trade, for any strictly convex curve, the trader suffers a
slippage loss at each trade. This is because the tangent to the
curve (whose slope is equal to the pool price and therefore
the market price) lies below the curve if it is strictly convex.
If the trader buys X tokens, it will therefore have to give the
pool an amount of Y tokens that exceeds what it should have
given at the current market price. Likewise, if the trader sells
X tokens, it will receive an amount of Y tokens less than what
it should have received at the current market price. The gap,
in either case, corresponds to the slippage loss. An equivalent
amount is gained by the LP (when the trader buys X tokens,
the excess Y tokens are sent to the LP; when the trader sells
X tokens, the gap corresponds to Y tokens are withheld by
the LP). There is no other source of divergence loss for the
LP because the pool price is readjusted to the market price
immediately after execution of the trade - its value increases
precisely by the amount of slippage loss experienced by the
trader.

V. SIMULATION RESULTS

We conduct a number of simulations to compare the
performance of four different AMM’s, two static AMM’s
(Constant-Sum AMM, Constant-Product AMM) and their two
dynamic generalizations that we have introduced in section IV.
Although it is not practically implemented due to its short-
comings, we nevertheless use the constant-sum AMM as a
baseline to highlight how the dynamic version of this scheme
has advantages and may be more interesting from a practical
perspective.



(a) X token holdings (b) Y token holdings (c) Total Value

(d) Market vs Pool Price (e) Collected Fees (f) Declined Trades

Fig. 2. Simulation of a Static Constant Sum AMM

A. Simulation Setup

In all our simulations, we consider the three parties in-
volved:

• The liquidity pool (LP).
• A trader (which could be viewed as a collection or

series of independent traders who are merely interested
in exchanging a relatively small amount of one of the
tokens in the LP for another).

• An arbitrageur (a profit-maximizing agent responding
specifically to any gaps in price between the pool and the
broader market; the arbitrageur in our simulation could
also be viewed as a collection or series of independent
arbitragers).

Initially, all three parties have 1000 X tokens and 1000 Y
tokens. At each time, a trader makes a random trade (buy
or sell X token) drawn from a standard normal distribution
(i.i.d. Gaussian process with zero mean and unit variance). The
relatively small standard deviation would result in relatively
light trading or profit from transaction fees collected from
trades (that are not for the purpose of arbitrage). We use the
exact same sequence of random trades in evaluating all four
AMM’s, to enable a fair comparison. We model the market
price as undergoing a linear increase from 0 to 10 over the
course of 1000 time steps.

B. Static Constant Sum AMM

Figure 2 shows the results for the baseline static constant
AMM. As shown by figure 2(d), the market price is initially
below the pool price of 1, and after 100 time steps it switches
to being above the pool price. As can be seen from figure 2
(a), (b), the arbitrageur initially sells all its X tokens to buy
up all of the Y tokens from the LP when the market price is
low, and then it buys up all the X tokens from the LP when

the market price becomes high. By draining the pool of its
liquidity in one of its assets, to the pool’s disadvantage, the
arbitrageur effectively extracts most of the total value from the
LP. Figure 2(c) shows the total value of the LP, the arbitrageur
and the trader measured in terms of the market price at the
end of the simulation (when X tokens are worth 10 Y tokens);
it shows that the LP ends up with only about a tenth of
the value it had at the beginning of the simulation. The LP
does collect some fees from the arbitrageur (per figure2(e)),
but they are relatively modest compared to the loss in value.
Although the trader doesn’t suffer slippage loss in this case, it
can be disappointed and face a rejection of its requested trade
whenever the pool lacks sufficient tokens of the type sought
by the trader (as shown in figure 2(f); this happens particularly
early on when the arbitrageur is able to cause the LP to be
nearly empty of one of its assets, then another, disrupting the
LP’s ability to serve the regular trader).

C. Static Constant Product AMM

Figure 3 shows the results for the static constant product
AMM. Here too, we can see from Figures 3(a) and (b), the
arbitrageur has a big impact on the token holdings of the LP.
Over time, as the market price goes up, the arbitrageur keeps
buying X tokens from the pool, equalizing the pool price and
the market price. Eventually the arbitrageur has no more Y
tokens available (after which point the pool prize stays below
the market price, see Figure 3(e)). As shown in figure 3(c),
the total value of the LP reduces while that of the arbitrageur
grows until the latter runs out of Y tokens. In reality, however,
a well-funded arbitrageur would keep going until all X tokens
are depleted from the LP, causing it to lose even more value.
The trader suffers some constant slippage on average in every
trade, as illustrated by the cumulative slippage showing a



(a) X token holdings (b) Y token holdings (c) Total Value

(d) Cumulative Slippage (e) Market vs Pool Price (f) Collected Fees

Fig. 3. Simulation of a Static Constant Product AMM

(a) X token holdings (b) Y token holdings (c) Total Value

(d) Market vs Pool Price (e) Collected Fees (f) Declined Trades

Fig. 4. Simulation of a Dynamic Constant Sum AMM

linear increasing trend in Figure 3(d). There are again some
collected fees from the arbitrageur and the regular trader, but
here too they pale in comparison to the loss in value caused
by the arbitrageur’s actions. It is clear that just like with the
constant sum setting, in the long term, the LP is at the mercy
of the arbitrageur in the presence of significant market price
volatility.

D. Dynamic Constant Sum AMM
Figure 4 shows the results for the dynamic constant sum

AMM. Here the arbitrageur is eliminated as the pool price
is automatically adjusted to the market price after each trade.

The total tokens of either types X or Y remain the same
and the holdings of the LP and the trader are mirror images
of each other, as shown in figures 4(a) and 4(b). The total
value of the LP doesn’t show a dramatic change other than
random fluctuation caused by stochastic trading on the pool.
In the absence of aggressive arbitrage, the collected fees are
somewhat modest. As shown by figure 4(e), the LP collects
the expected amount of fees (about 80 over 1000 trades,
corresponding to the expectation of the absolute value of a
normal random variable). A noticeable fact about the dynamic
constant sum AMM is that the LP maintains more than 85%



(a) X token holdings (b) Y token holdings (c) Total Value

(d) Cumulative Slippage (e) Collected Fees (f) Market vs Pool Price

Fig. 5. Simulation of a Dynamic Constant Product AMM

of the original amount of tokens of both types at all times
during the simulation. This is in sharp contrast to the liquidity
problems observed in the static settings (figures 2 and 3). As a
result, there are no declined trades, as evidenced by figure 4(f).
Another related comment to be made here is that there is little
incentive for large trades in this dynamic AMM because the
price is always pegged to the market price and the transaction
fees (being a constant percentage) impose a higher cost in
absolute terms on larger trades.

E. Dynamic Constant Product AMM

Finally, figure 5 shows the results for the dynamic constant
product AMM. Here too, the arbitrageur is eliminated as the
pool price is automatically adjusted to the market price after
each trade (see figure 5(f)), and the X and Y tokens held by
the trader and LP mirror each other as shown in figure 5(a)
and figure 5(b). The total value of the LP in figure 5(c) doesn’t
show a dramatic change other than the fluctuation caused by
stochastic trading on the pool and a slight increase in value for
the LP due to the slippage gain discussed earlier in this paper.
The corresponding cumulative slippage loss for the trader,
equivalent to the cumulative slippage gain for the LP, is shown
in figure 5(d), and it is this gain that results in a sligh";"""date"",""2021-01-11T01:34:09Z""
""pdf:PDFVersion"",""1.5""
""pdf:docinfo:title"",""""
""xmp:CreatorTool"",""LaTeX with hyperref""
""pdf:hasXFA"",""false""
""access_permission:can_print_degraded"",""true""
""subject"",""""
""language"",""en""
""dc:format"",""application/pdf; version=1.5""
""pdf:docinfo:creator_tool"",""LaTeX with hyperref""
""access_permission:fill_in_form"",""true""
""pdf:encrypted"",""false""
""dc:title"",""""
""modified"",""2021-01-11T01:34:09Z""
""cp:subject"",""""
""pdf:docinfo:subject"",""""
""pdf:hasMarkedContent"",""false""
""pdf:docinfo:creator"",""""
""PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.21 (TeX Live 2020) kpathsea version 6.3.2""
""meta:author"",""""
""trapped"",""False""
""meta:creation-date"",""2021-01-11T01:34:09Z""
""created"",""2021-01-11T01:34:09Z""
""access_permission:extract_for_accessibility"",""true""
""Creation-Date"",""2021-01-11T01:34:09Z""
""resourceName"",""2101.02778""
""Author"",""""
""producer"",""pdfTeX-1.40.21""
""pdf:docinfo:producer"",""pdfTeX-1.40.21""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""9"",""0"",""0"",""0"",""0"",""0""
""Keywords"",""""
""access_permission:modify_annotations"",""true""
""dc:creator"",""""
""dcterms:created"",""2021-01-11T01:34:09Z""
""Last-Modified"",""2021-01-11T01:34:09Z""
""dcterms:modified"",""2021-01-11T01:34:09Z""
""title"",""""
""Last-Save-Date"",""2021-01-11T01:34:09Z""
""pdf:docinfo:keywords"",""""
""pdf:docinfo:modified"",""2021-01-11T01:34:09Z""
""meta:save-date"",""2021-01-11T01:34:09Z""
""pdf:docinfo:custom:PTEX.Fullbanner"",""This is pdfTeX, Version 3.14159265-2.6-1.40.21 (TeX Live 2020) kpathsea version 6.3.2""
""Content-Length"",""1368269""
""Content-Type"",""application/pdf""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""""
""dc:subject"",""""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""9""
""pdf:hasXMP"",""false""
""pdf:charsPerPage"",""4721"",""4863"",""3899"",""3663"",""3970"",""3056"",""1309"",""3134"",""2318""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""pdf:docinfo:trapped"",""False""
""meta:keyword"",""""
""access_permission:can_modify"",""true""
""pdf:docinfo:created"",""2021-01-11T01:34:09Z""
";https://scholar.google.ch/scholar?start=70&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2021
1619099124-453;https://scholar.google.ch/scholar?as_ylo=2021&q=oracles+blockchain&hl=fr&as_sdt=0,5;Blockchain?based privacy?preserving valet parking for self?driving vehicles;Y Fang, Y Zhao, Y Yu, H Zhu, X Du… ; Transactions on …, 2021  Wiley Online Library;;"… Then, we demonstrate that our protocol is secure in the random oracle model … By

combining cryptographic techniques, distributed network and consensus mechanism,

the first cryptocurrency system called Bitcoin was built atop blockchain …";;null;null;;;;https://scholar.google.ch/scholar?start=40&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2021
1619099138-478;https://scholar.google.ch/scholar?as_ylo=2021&q=oracles+blockchain&hl=fr&as_sdt=0,5;[CITATION][C] A Secure Signcryption Scheme for Electronic Health Records Sharing in Blockchain;X Peng, J Zhang, S Zhang… ; COMPUTER …, 2021  TECH SCIENCE PRESS 871 …;;null;;null;null;;;;https://scholar.google.ch/scholar?start=70&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2021
1619099120-438;https://scholar.google.ch/scholar?as_ylo=2021&q=oracles+blockchain&hl=fr&as_sdt=0,5;When good blocks go bad: Managing unwanted blockchain data;A Carvalho, JW Merhout, Y Kadiyala… ; International Journal of …, 2021  Elsevier;;"… The “crypto” prefix is due to these distributed ledgers, now often called blockchain, being … Many

of the reported problems we came across were unrelated to blockchain's immutability property,

eg, several pump-and-dump schemes in the cryptocurrency space (see the …";Cité 2 fois;Les 2 versions;null;;;;https://scholar.google.ch/scholar?start=30&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2021
1619099115-430;https://scholar.google.ch/scholar?as_ylo=2021&q=oracles+blockchain&hl=fr&as_sdt=0,5;Privacy-preserving hierarchical deterministic key generation based on a lattice of rings in public blockchain;S Banupriya, K Kottursamy, AK Bashir ; PeertoPeer Networking and …, 2021  Springer;;"… method and that in [29] is based on pairing without the random oracle method … The anonymity

and likability properties of ring signatures are implemented in blockchain protocols to avoid … is

the best solution for privacy issues and is implemented in many cryptocurrency systems to …";;null;null;;;;https://scholar.google.ch/scholar?start=20&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2021
1619099115-428;https://scholar.google.ch/scholar?as_ylo=2021&q=oracles+blockchain&hl=fr&as_sdt=0,5;[HTML][HTML] Research advances on blockchain-as-a-service: architectures, applications and challenges;S Jie, P ZHANG, M ALKUBATI, BAO Yubin… ; Digital Communications …, 2021  Elsevier;;"… (4). Oracle. Oracle's BaaS system, named Oracle Blockchain Cloud Service (OBCS)

[8], is based on Hyperledger with a number of enhancements for better performance,

scalability, security, etc. Its architecture is shown in Figure …";;null;[HTML] sciencedirect.com;https://www.sciencedirect.com/science/article/pii/S2352864821000092;;;https://scholar.google.ch/scholar?start=20&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2021
1619099129-464;https://scholar.google.ch/scholar?as_ylo=2021&q=oracles+blockchain&hl=fr&as_sdt=0,5;Blockchain-based Edge Computing Data Storage Protocol Under Simplified Group Signature;Z Wang ; IEEE Transactions on Emerging Topics in Computing, 2021  ieeexplore.ieee.org;;"… However, all of the above schemes are proved in the random oracles. Gai et al … oracle model

by using Bellare et al.'s security definition for group signatures [24] … proposed a modified group

signature scheme for blockchain-based mobile-edge comput- ing architecture [30] …";;null;null;;;;https://scholar.google.ch/scholar?start=50&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2021
1619099111-423;https://scholar.google.ch/scholar?as_ylo=2021&q=oracles+blockchain&hl=fr&as_sdt=0,5;LSO: A Dynamic and Scalable Blockchain Structuring Framework;WT Tsai ; Intelligent Computing and Block Chain: First …, 2021  books.google.com;;"… Oracle computing architecture This BDL system can be supported by the LSO framework …

com/blockchain-oracles-the-key-to-scalability-and-interoper ability/# more-73 3. Tsai, WT, Blower,

R., Zhu, Y … In: 2020 IEEE International Conference on Blockchain and Cryptocurrency (ICBC …";;null;null;;;;https://scholar.google.ch/scholar?start=10&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2021
1619099133-469;https://scholar.google.ch/scholar?as_ylo=2021&q=oracles+blockchain&hl=fr&as_sdt=0,5;Using Blockchain in University Management Systems;SIM Ali ; Turkish Journal of Computer and Mathematics …, 2021  turcomat.org;;"… https://doi.org/10.47631/jareas.v1i1.17 13. H. Al Breiki, L. Al Qassem, K. Salah, M. Habib Ur

Rehman, and D. Sevtinovic, 'Decentralized access control for IoT data using blockchain and

trusted oracles', Proc. - IEEE Int. Conf. Ind. Internet Cloud, ICII 2019, pp …";;;[PDF] turcomat.org;https://turcomat.org/index.php/turkbilmat/article/download/2389/2098;"
Turkish Journal of Computer and Mathematics Education                     Vol.12 No 2(2021), 3305-3312 

                                                                                                                                         Research Article         

3305 

Using Blockchain in University Management Systems 
 

 

Sura I. Mohammed Ali1, Hussien Mohamed Sharaf2  

 
1Department of mathematics &computer applicationCollage of science Al-Muthanna University, Iraq 

suraibraheem@mu.edu.iq 
2Department of Computer ScienceFaculty of Computers and Information Suez University, Suez, Egypt 

H.Sharaf@suezuni.edu.eg 

 

Article History: Received: 11 January 2021; Accepted: 27 February 2021; Published online: 5 April 2021 

 
Abstract: lockchain stores a series of transactions in form of a sequence of linked blocks. Hence, the concept of ledger is 

easily maintained. Transactions and interactions that take place among participants accessing the distributed and 

decentralized blockchain network are holding through ledger. In a student management system (SMS), vital information can 

be highly shared and well protected at the same time. This paper proposes a model for using blockchains to implement fully 

functional SMS that maintains students’ records, course registrations record and student marks.   The proposed model adds 

more security via the use of hashing and data readily available with decentralized data storage. In addition, the use of ledger-

based system to maintain SMS data introduces reliable and highly trusted model. 

Keywords: UniversityManagement System,Blockchain, student's records 

 

1. Introduction 

Education is a corearea where development takes place on different levels of education.  

Regardless of the marked enchantment in technology, there is nonetheless a desire for creating human 

recourses via learning, and blockchain makes this easier to achieve.  Blockchain can be implemented within the 

automated management systems of individual higher education institutions or groups of educational 

institution[1].In education sections, critical of  Students’ information   are vital  plus sensitive and  to retrieval   

data of general administrative framework, learning and research  may time consuming  that cased very 

problematic[2]. In conventional education framework, there is some of the challenges are recordkeeping. For 

recordkeeping, blockchain technology gives a protected archive of such records, time-stepped can be a big assist 

for all stakeholders[3]. 

 

Blockchain technology is one of the famous popular techniques in the latest few years[3].One of the most 

important applications is securing data of student management systems (SMS).The features of blockchain are 

readiness of sharing and visibility that are essential for any SMS. The entering courses registrations and entering 

marks can be viewed as transactions similar to financial transitions; once committed to the system must never be 

removed. A transaction can only be reversed by submitting another reverse transaction.   

In the context of blockchains, data is stored in the formsequence of blocks and every block is related to the 

forming next chainof records and store all committed transactions using a public ledger[4]. Transactions and 

interactions that take place among participants accessing the distributed and decentralized blockchain network 

are holding through ledger. In SMS, a transaction could be: 

A) An admin: Adding or modifying a student’s records. 

B) A student/admin: Adding or modifying course registration record. 

C) A faculty member: Adding or modifying registration marks (Final exam, MidTerm, course work).  

 

The chain expands continuously when new blocks appended to it. Each blockincludes message,   current 

hash, previous block hash, date; block id, etc. relying on the application[1]. 

 

The first block in the blockchain is called genesis block which has no parent, shows in Figure 1. 

 
Figure1: The architecture of the blockchain 



Sura I. Mohammed Ali, Hussien Mohamed Sharaf  

 

3306 

 

All regular transactions rely onthecentralized consensus depending on the party.This offers many interesting 

features such asdecreasing transaction cost, efficiency, and security. To attain secure, fast and clean transactions, 

the idea of blockchains will be introduced. A blockchain system processes the transactions submitted by 

individuals without the need for third party intervention services.  

 

Different approaches have been presented in the domain of student management systems (SMS).  

In university context, a lot of efforts and costs are put into managing recordsfor all educational 

transactionsoccurring since the first-time students submit their papers and register courses for the first semester 

until they graduate. In this context, appeared of  challenges  are  in all transaction[5].   

 

One of the motivations for this paper is to address how student data should be collected, stored and later 

accessed. This paper proposesan approach for using blockchain to implement fully functional SMS that 

maintains students’ records, course registrations record and student marks.   

 

The proposed model adds more securityvia the use of hashing and data readily available with decentralized 

data storage. The information of blockchain that provided by the university is open to all parties that interest 

it.because of  immutability, sensitiveness,and deal with of storing the records in blockchain, helped to get good  

implementation of student management system [6].In the blockchain can record all values that include birth 

certificates, social security cards, student loans,etc. through expressed as cod it[6]. 

 

2. How Blockchain Works:  

A blockchain is sequence of blocks that contains setdata. Each block has a cryptographic hash of the previous 

block and transaction data and stores those transactions in a cryptographically secured data unit called “Blocks”. 

 

2.1 The componentsof blockchain:  

2.2  

• Node — it represented as user or computer through blockchain. 

• Block — it is network of list nodes including a set of transactions in a particular order distributed on all 

nodes. the structures of blockchain include on: 

✓ Pointers — variables that stores index information to another location of variable. 

• Linked lists — a series of blocks by a pointer every block   links to the next block. Genesis block is 

called on the first block in the blockchain, which has no parent. 

• Transaction —allowed sharing and exchange of information between nodes [7], that requested by a 

node, and by means of files containing transfer information between nodes. The blockchain updates it status after 

each transaction. 

• Chain — it means a list of blocksin a specific order. 

• Consensus— to execute operations of blockchain, it is through a combination of rules and 

arrangements. it is the most important step in the blockchain process to add his block to the blockchain in the 

following step: 

1) The hash code of a valid block is calculated as in Equation 1[8]. To generate hashing values that through 

using a mathematical functionagainst tampering. 

 

BHC=Hash (TD +P + Nonce)….(1) 

Where ‘BHC’ is the Block Hash Code, ‘TD’ is the transaction Data, ‘P ’ is the hash code of the previous 

block in the chain, ‘Nonce’ (Number only once) is an arbitrary number that can be used only once for producing 

the corresponding BHC. 

 

2) This process is done by solving a complex mathematical algorithm that associated with miner block; this 

process is called block mining. By calculating a cryptographic block hash, a process of block mining finds the 

next veracious block. 

 

Miners — in this step, each miner starts to form his block (i.e. a nominated informal block) which involves 

his selected transactions. At this moment, the selected transactions in the formed block still unconfirmed, since 

the miner should check the validity of the selected transactions.For exampleif a transaction occurs (Add New 

Block) from A, it must be verified of transaction with other public records of data by the participants (B, C, D, 

and F) through copying of data their own.After the verified the transaction, if it is valid, all peers will confirm 

and accept its validity and approve that the new block can be inserted and updated state of blockchain when 

added block completed. 

 



Using Blockchain in University Management Systems 

 

3307 

3. Blockchain for Universities: 

In the education domain, several blockchain technologiesrecently are used. The authors [9] discussed in their 

paper was that universities Nicosia and Birmingham research center have used Blockcert system. A  Blockcert 

system approves control to issue   personal official documents, academic certificates and private data.  The 

Universities of Nicosia and Woolf primarily based on blockchain architecture. A diagram of Blockcert system is 

shown in figure 2, it consist of many components that interconnections it of educational environment 

 

 

Figure 2: Blockcert system[9]. 

 

The component of university   adds hashed certificates to the blockchain to issues students’ diplomas. The 

component of employers can be verified students’ diplomas and search in this blockchain. 

 

The authors [7] discussed in their paper was that 24 universities in Jakarta have used existing McRhys model. 

McRhys is a model to record and integrate all activities in university using blockchain concept.  

 

“Distributed Open Ledger” is concept that confirm by McRhys model. Information of blockchain can be 

access by all Participants of the same interest that provided it by the university, also in this model a transaction 

validated verified before inserted it[5].McRhys Blockchain Model for University in Indonesia system shows in 

figure 3.  The objective of this model is to solve the problems: validity, transparency, reliability of data and 

access of data with ease by the employer when the concept of blockchain is applied. 

The next section discusses the varietyblockchain models that using in the universities. Diploma certificate 

forgery on university is important problem that focuses it researchers, to solve this problem which is an 

important contemporary issue therefore is used a term of university blockchain. Another challenge in education 

institutions; is data record of immutable grades.  

Figure 3.McRhys Blockchain Model [7]. 

 

Recorded grades should be unchangeable andsaved on a ledger-based system. Once a set of grades are 

recorded (added transaction), no one is allowed to modify and delete. As a topic within academic circle, we 

proposed blockchain model for university level to implement fully functional to store the student information and 

marks as student management systemin form of blocks. 

The authors in [10]proposed a new framework based on blockchain. In Figure4, records of education and 

components added to the system, and then posted to the blockchain to appear it all parties. 

Figure 4: Architecture of the Proposed Framework[10] 

 



Sura I. Mohammed Ali, Hussien Mohamed Sharaf  

 

3308 

The center of the framework includes individual node, the miner around the blockchain, and the provider 

node.Proposed framework contribute with provide the blockchain provide the privacy and security of data stored 

on it, and  functions customized access to different parties that corresponding  for the education. 

 

4. Proposed Model Design 

 

To share, verify, and learningachievements [1], a novel infrastructure of Blockchain technology is ideal for 

purpose..In this paper, we propose blockchain model for university level to implement fully functional student 

management system shown in figure 5.  We choose to focus on student marks. These are at the core of education 

area. The model is a workable prototype built to discuss the potential of blockchain for this area.  It is a model to 

record and manage all activities in a university using blockchain concept implemented as a ledger-based system.  

Each block can be store records of student and their hashthen it will use roles to retrieve original information.  

The information hashed in the blockchains; when carried the change in content of one block will invalidate 

the entire chain of blocks [11]. Each block consist of nonce, header, hash code of the previous block, hash value 

and time stamp, and each model different from application to another. The model shows data records and 

interaction of all participants in the model. 

Our model has the following functions as three cases. In all cases, both the student and the professor are 

required to be registered on the course. Figures(4, 5) are illustrating these models using activity diagram. 

In figure 4, a new blockchain addressgenerates for the student,when students enroll into the course the                   

administration issues a student ID and send these information to the student.Administration stores information 

(Student ID, Enrolled course of the student, Subject information) about student into itscentralized database.In 

figure 5 professor registration is almost the same as student. 

 

➢ Model 1: 

Professors and admins are parties of blockchain, when a student registered in the course the first block or 

""Genesis Block” generated and all parties can access the new student after registration.The model stores 

enrollment data of student course, their marks (MidTerm mark, Coursework mark, Final Exam) for each 

semester in one blockchain. Usually, the respective authority runs the mid-term exam and the final exam, for 

sake of evaluation process. After enrollment the examination, professors input the student mark on the 

blockchain created.  

The control committee of university will receive the report of the marks and test results every semester. This 

process will be repeated every semester.  

At the next stage, the respective authority units publish all students’ marks. This result determines the 

students’fitness status to receive certificates, grade copy and every student receives a unique code printed on the 

certificate.In figure 6, the student record of marks can be added to the model and posted to the blockchain, 

professors can do transaction to student accounts for assigning mark for his/her subject. On the other side, 

students can see their marks on different courses. Students’ grades are in their academic year.  



Using Blockchain in University Management Systems 

 

3309 

Figure 4: Student registers for the course 

Figure 5: Professor registers for the subjects of course 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Figure.6 Diagram for storing blocks of marks in blockchain 

 

A studentget notified it once there is any particular update in his block. By a student takes an exam, the 

professor should verify the results and sends it to the students blockchain address. The transaction is processed 

through the transaction is confirmed; the information about the grade will be saved into the ledger-based system. 

On the other side, students can see their grades on subjects of course.  



Sura I. Mohammed Ali, Hussien Mohamed Sharaf  

 

3310 

A unique course symbol for each course in each semester, would allow differentiating between duplicate 

enrollments in different semesters. The number of transactions is dependent on the number of courses and 

students in order to transact marks for students. All the transaction information will be stored in the blockchain 

model. It will not be possible to modify or delete any item. 

 

➢ Model 2: 

When students enroll into the model, the                           administration of the university issues a student ID 

and generates a new blockchain address for the student.  Administration stores following information about 

student (name, phone, address, ID, social security number) into her/his blockchain address, and stores student 

course enrollment data in separate blockchain(Marks blockchain).After a student takes an exam, professor sends 

result to the students blockchain address.  

The mark will be saved into central database. On the other side, students can see their marks blockchain that 

includes their marks on subjects.The control committee inputs ID student into the model as one of the 

requirements to take it exam in the final semester.Figure 7 illustrates a process model of the above scenario.

 

➢ Model 3: 

The model stores each transaction and logs the information of the student plus the registration data of course 

in one blockchain. All transaction will be record into the blockchain such as examination, courses, lecturer, and 

marks after process of registered completed of student, all of the transactions are inserting in one of blockchain. 

All updates and additions that be logged will be posted to all related persons. 

In this case, the student registration mechanism will be responsible for verifying the courses schedule 

provided by the university.  Therefore, the blockchain transaction list can produce marking list document.  

 

 

 

 

 

 

 

 

 

 

 

 

 Figure.7 Diagramof Student’s marks & information 

 

After students register in the all desired courses, the data of students will be submitted to the control 

committee.  After the registrationprocess, the profile student will be create by enrolled his into listing all the 

courses. After registration, all parties concerned can access the new student. Each student will have personal unit 

of transactions (ID, courses, MidTerm mark, Coursework mark, Final exam.). The transferred information is 

stored on the blockchain. Administration must upload student records (student information) and store over the 

blockchain network.  

All of the transaction of model are validated and no changeable it.Figure 8 shows all the student transactions 

in the university.Therefore the manipulation is decreases. The university employer input student information data 

and a unique hash is taken from database then adds it to the blockchain.   

  

 

 

https://hackernoon.com/tagged/blockchain


Using Blockchain in University Management Systems 

 

3311 

The administration of the university stores information (Student ID, Username, registration course of the 

student) into its centralized database.  

 

All students have unique username and password to access the model and mange his account.  As we can see 

from the previous section, everymodel has its strengths and weakness; we review this in the table 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Figure.8Diagram for storing blocks of marks in blockchain 

 

 

 

 

 

            Table1: Comparing of three models 

 

 

 

 

Feature

s 
Model 1 Model2 Model3 

Network 

size 

One 

blockchain 

supply 

demand 

networks  

multi-

blockchains 

supply demand 

networks 

 

One 

blockchain 

supply demand 

networks  

perform

ance 

Improving 

the model 

cycle time 

decrease 

order updates. 

 

more 

confirmation 

time because 

more number of 

block 

Storage data 

in one record as 

""one data""  

Changing the 

block 

continuously in 

real time . 

Security 

Flexible 

and secure 

because of 

their storage 

data is limited 

so the data is 

more reliable. 

 

verified each 

transaction  

 data is 

reliable 

storage 

capacity 

resilient, 

flexible and 

secure 

Resource 

sharing on a 

public. 



Sura I. Mohammed Ali, Hussien Mohamed Sharaf  

 

3312 

5. Conclusion 

 

Our models add more security via the use of hashing and data readily available with decentralized data 

storage. The student data can be stored by building three models based on blockchain. Using Blockchain, we 

designed of three blockchain models. The infrastructure of models are based on blockchains are well suited for 

large-scale data processing. 

Universities can deal with student management system (SMS) in a way that greatly achieves security.  

Storing and sharing data will be simpler with decentralized data storage and could be programmed into the 

blockchain. Another feature the ledger can represent as valid guide to maintain student management system 

(SMS) and introduces reliable, highly trusted model for accessing and storing data. 

 

References 

 

1. V. A. Tolbatov, ‘USING BLOCKCHAIN TECHNOLOGY FOR E-LEARNING’, "" Вимірювальна та 

обчислювальна техніка в технологічних процесах , vol. 61, no. 1, pp. 110–113, 2018. 

2. F. O. Ezeudu, N. M. Eya, and H. I. Nworgi, ‘Application of Blockchain-based Technology in Chemistry 

Education Students ’ Data Management’, Int. J. Database Theory Appl., vol. 11, no. 2, pp. 11–22, 2018. 

3. K. Palanivel, ‘Blockchain Architecture to Higher Education Systems’, Int. J. Latest Technol. Eng. Manag. 

Appl. Sci. , vol. VIII, no. Ii, pp. 124–138, 2019. 

4. K. Salah and N. Nizamuddin, ‘Blockchain for AI : Review and Open’, no. December, 2018. 

5. Y. U. Chandra, S. Surjandy, E. Fernando, and H. Prabowo, ‘DEFYING THE CERTIFICATION 

DIPLOMA FORGERY WITH BLOCKCHAIN PLATFORM : A PROPOSED MODEL DEFYING THE 

CERTIFICATION DIPLOMA FORGERY WITH BLOCKCHAIN PLATFORM : A PROPOSED 

MODEL’, no. July, 2019, doi: 10.33965/ict2019. 

6. S. M. K. V. P. Kumar, K. K. Kumar, R. S. Krishna, and P. S. G. A. Sri, ‘Incorporation of Blockchain in 

Student Management System’, Int. J. Innov. Technol. Explor. Eng., vol. 8, no. 6, pp. 664–668, 2019. 

7. V. Juričić, M. Radošević, and E. Fuzul, ‘Creating student ’ s profile using blockchain technology’, 2019 

42nd Int. Conv. Inf. Commun. Technol. Electron. Microelectron., pp. 521–525, 2019. 

8. M. Torky, T. Gaber, and A. E. Hassanien, ‘Blockchain in Space Industry - Challenges and Solutions-’, 

arXiv Prepr. arXiv2002.12878.  ,2014 . 

9. Okanya, A. ., Asogwa, J., & Onyedikachi, I. . . . (2021). Indoor Environmental Quality (IEQ) in Nigerian 

Tertiary Institutions: The Effect on Performance of Building Technology Lecturers. Middle Eastern Journal 

of Research in Education and Social Sciences, 2(1), 172-186. https://doi.org/10.47631/mejress.v2i1.143 

10. D. Tapscott and A. Tapscott, ‘THE BLOCKCHAIN REVOLUTION & Higher Education.’, vol. 52, no. 2, 

pp. 10–24, 2017, [Online]. Available: 

http://widgets.ebscohost.com/prod/customerspecific/ns000290/authentication/index.php?url=https%3A%2F

%2Fsearch.ebscohost.com%2Flogin.aspx%3Fdirect%3Dtrue%26AuthType%3Dip%2Ccookie%2Cshib%2

Cuid%26db%3Da9h%26AN%3D122453203%26amp%3Blang%3Dpt-pt%26site%3Deds-li. 

11.  A. I. B. M. Han, Z. Li , J. He , D. Wu , Y.Xie, ‘A Novel Blockchain-based Education Records 

Verification Solution’, in (In Proceedings of the 19th Annual SIG Conference on Information Technology 

Education ,2018, pp. 178–183. 

12. [Anggraeny, A. S. . (2020). The Effect of Implementing the Financial Management Information System on 

the Quality of the Presentation of the Pangkep Regency Government’s Financial Statements. Journal of 

Advanced Research in Economics and Administrative Sciences, 1(1), 32-44. 

https://doi.org/10.47631/jareas.v1i1.17 

13. H. Al Breiki, L. Al Qassem, K. Salah, M. Habib Ur Rehman, and D. Sevtinovic, ‘Decentralized access 

control for IoT data using blockchain and trusted oracles’, Proc. - IEEE Int. Conf. Ind. Internet Cloud, ICII 

2019, pp. 248–257, 2019, doi: 10.1109/ICII.2019.00051. 

 

 

 

 

 


";"""date"",""2021-04-11T06:11:05Z""
""pdf:unmappedUnicodeCharsPerPage"",""0"",""0"",""0"",""0"",""0"",""0"",""0"",""0""
""pdf:PDFVersion"",""1.7""
""xmp:CreatorTool"",""MicrosoftÂŽ Word 2019""
""pdf:hasXFA"",""false""
""access_permission:modify_annotations"",""true""
""access_permission:can_print_degraded"",""true""
""dc:creator"",""Editor""
""language"",""en""
""dcterms:created"",""2021-04-11T06:11:05Z""
""Last-Modified"",""2021-04-11T06:11:05Z""
""dcterms:modified"",""2021-04-11T06:11:05Z""
""dc:format"",""application/pdf; version=1.7""
""xmpMM:DocumentID"",""uuid:A3A61BB5-81DE-432F-84FB-A0F85CE94D00""
""Last-Save-Date"",""2021-04-11T06:11:05Z""
""pdf:docinfo:creator_tool"",""MicrosoftÂŽ Word 2019""
""access_permission:fill_in_form"",""true""
""pdf:docinfo:modified"",""2021-04-11T06:11:05Z""
""meta:save-date"",""2021-04-11T06:11:05Z""
""pdf:encrypted"",""false""
""xmp:CreateDate"",""2021-04-11T11:41:05Z""
""modified"",""2021-04-11T06:11:05Z""
""Content-Length"",""539818""
""pdf:hasMarkedContent"",""true""
""Content-Type"",""application/pdf""
""xmp:ModifyDate"",""2021-04-11T11:41:05Z""
""pdf:docinfo:creator"",""Editor""
""X-Parsed-By"",""org.apache.tika.parser.DefaultParser"",""org.apache.tika.parser.pdf.PDFParser""
""creator"",""Editor""
""dc:language"",""en-IN""
""meta:author"",""Editor""
""pdf:producer"",""MicrosoftÂŽ Word 2019""
""meta:creation-date"",""2021-04-11T06:11:05Z""
""created"",""2021-04-11T06:11:05Z""
""access_permission:extract_for_accessibility"",""true""
""access_permission:assemble_document"",""true""
""xmpTPg:NPages"",""8""
""Creation-Date"",""2021-04-11T06:11:05Z""
""resourceName"",""2098""
""pdf:hasXMP"",""true""
""pdf:charsPerPage"",""3945"",""4310"",""2627"",""3312"",""653"",""2849"",""1139"",""3794""
""access_permission:extract_content"",""true""
""access_permission:can_print"",""true""
""Author"",""Editor""
""producer"",""MicrosoftÂŽ Word 2019""
""access_permission:can_modify"",""true""
""pdf:docinfo:producer"",""MicrosoftÂŽ Word 2019""
""pdf:docinfo:created"",""2021-04-11T06:11:05Z""
";https://scholar.google.ch/scholar?start=60&q=oracles+blockchain&hl=fr&as_sdt=0,5&as_ylo=2021